SuperAPI AI 工具集
合作ENAI 行业资讯收藏
Skill 广场app-spec-packager

app-spec-packager

编程与开发

查看项目

更新于 10-16 11:03

技能介绍

用途

app-spec-packager 用于把应用程序、产品、创业想法、SaaS、移动应用、Web 应用、API、AI 产品或内部工具，转化为编码智能体可直接使用的完整、面向生产环境的规格包。其目标产出不依赖时间表、故事点、预算或冲刺规划，而是聚焦于可执行、可验证的构建规格。

默认输出

默认创建一个 Markdown 规格包文件夹，并在支持文件输出时额外创建 zip 压缩包。默认结构（除非用户另有要求）如下：

[app-slug]-spec/
  README.md
  PRODUCT_SPEC.md
  UX_FLOWS.md
  DESIGN_SYSTEM_SPEC.md
  TECH_ARCHITECTURE.md
  ADRS.md
  AI_SPEC.md                         # 仅在 AI/自动化/模型行为相关时
  SAFETY_PRIVACY_SECURITY.md
  API_AND_DATA_MODEL.md
  CLIENT_IMPLEMENTATION_SPEC.md
  BACKEND_IMPLEMENTATION_SPEC.md      # 仅在后端/API/服务端相关时
  SUBSCRIPTION_BILLING_SPEC.md        # 仅在变现/支付相关时
  ANALYTICS_OBSERVABILITY_SPEC.md
  QA_ACCEPTANCE_TESTS.md
  RELEASE_READINESS.md
  TASKS.md
  REFERENCES.md                       # 仅在使用研究或外部事实时包含

在需要搭建包结构时，可使用脚本 scripts/create_spec_package.py 生成脚手架，然后为每个文件填写针对该应用的具体内容。

核心工作流

  1. 采集应用意图、平台、目标用户、核心工作流、数据敏感度、AI 需求、变现方式、集成和发布约束。
  2. 只询问阻塞性问题。如果用户已经提供足够上下文，则继续执行并明确标注假设。
  3. 当规格依赖于最新平台规则、SDK 版本、应用商店规则、法律、支付、AI 提供商、安全要求或框架最佳实践时，研究当前事实。优先使用官方来源。将引用和来源说明放入 REFERENCES.md。
  4. 选择相关文档集。省略确实无关的文档，但生产构建需保留隐私/安全、QA 和任务文档。
  5. 将需求编写为精确、可测试的陈述，并使用稳定 ID。
  6. 将规格转换为编码智能体可执行的任务。每个任务都需要验收标准和测试。
  7. 在最终输出前，按 references/validation-checklist.md 校验规格包。

参考资料加载

按需读取以下文件：

  • references/document-blueprints.md：每个生成文档的完整章节模板。
  • references/platform-modules.md：iOS、Android、Web、后端、AI、支付、B2B 和受监管产品的平台特定关注点。
  • references/safety-privacy.md：当应用涉及账户、AI、支付、未成年人、健康、心理健康、金融/法律建议、位置、生物识别、UGC、敏感数据或安全风险时，此文件为必读。
  • references/task-taxonomy.md：编写 TASKS.md 前必读。
  • references/validation-checklist.md：最终定稿前必读。

编写规则

  • 除非明确要求，不要包含故事点、预算、时间表、甘特图、冲刺计划或人员配置计划。
  • 不要产出模糊的史诗（epic），要产出具体的构建任务。
  • 不要过度提问。在安全且可逆时使用假设。
  • 不要隐藏非目标（non-goals）。将其放在 PRODUCT_SPEC.md 顶部附近，并在 TASKS.md 中作为“不要做”约束重复关键项。
  • 不要对已知信息使用占位符。仅对真正未知的值使用占位符，并在“Open decisions”章节中列出。
  • 不要对法律、医疗、金融或应用审核作出确定性声明。应明确合规要求，并标记为需法律或平台审核。
  • 不要默认建议存储敏感内容。应最小化数据，分离本地/服务端/提供商数据，并定义保留策略。
  • 除非应用为原型且用户明确接受该风险，否则不要从客户端应用直接调用第三方 AI 提供商。
  • 除非有明确的安全/隐私要求，不要创建社区、UGC、支付、AI 记忆、位置追踪、生物识别采集或健康数据流。

需求风格

使用稳定 ID，例如：

  • REQ-PROD-001
  • REQ-UX-001
  • REQ-ARCH-001
  • REQ-AI-001
  • REQ-SEC-001
  • REQ-API-001
  • REQ-IOS-001
  • REQ-WEB-001
  • REQ-BE-001
  • REQ-QA-001

每个主要需求应回答：

  • 必须发生什么？
  • 何时发生？
  • 谁或什么触发它？
  • 状态存储在哪里？
  • 边缘情况有哪些？
  • 如何测试？
  • 绝不能发生什么？

任务风格

使用 references/task-taxonomy.md 中的任务模板。一个良好的任务包括：

  • 任务 ID
  • 标题
  • 目标
  • 上下文
  • 需求
  • 可能涉及的文件或区域
  • 验收标准
  • 测试
  • 依赖项
  • 不要做

使任务可由编码智能体以最少来回沟通实现。优先选择小型、可验证的任务，而非宽泛的史诗。

生产环境默认假设

除非用户上下文与之矛盾，使用以下默认值：

  • 当平台质量依赖深度平台集成时，优先选择原生客户端技术栈。
  • 优先使用类型化语言、明确的 API 契约、迁移和自动化测试。
  • 对于 AI、计费、速率限制和敏感集成，优先采用后端中介。
  • 对于敏感应用，优先采用本地优先或数据最小化设计。
  • 在可避免锁定时，对 AI 和支付优先采用提供商抽象。
  • 优先不进行敏感分析。跟踪产品事件时不含内容或敏感类别。
  • 包含无障碍、本地化准备、错误状态、离线状态、可观测性、删除/导出和发布就绪。

最终响应

返回生成的文件夹或 zip 的链接。简要说明创建了什么，并指出任何假设或需要法律/平台/安全审核的事项。