create-app

创建应用

将一个原始应用创意转化为经过验证、架构清晰的首个版本，并以可持续的节奏发布——既不过度构建尚未赢得的规模，也不写出最终僵化到不得不重写的原型。这段旅程分为 10 个阶段：每次决策前都会先提问，并将每个选择记录在 docs/ 中，方便你跨会话暂停和继续。早期阶段通常完全不会产出代码；实验验证通过、可以开始构建后，工程阶段会把真正的产品做好。

核心原则

快速验证，同时保留选择空间：尽早做出难以逆转的决策，将所有容易调整的事情推迟处理。 将稀缺的早期精力投入到少数会产生复利效应的事情上——风险最高的假设、依赖边界和领域语言——并积极避免其他方面的浪费。

这项技能负责安排各阶段、提出问题并记录决策；各个组成技能则负责具体方法。请调用它们，而不是自行臆造它们的框架。

旅程地图

阶段	技能	要回答的问题	产出物
1	lean-startup	风险最高的假设是否成立？MVP 是什么？	创建 docs/PRODUCT.md + docs/EXPERIMENTS.md
2	design-sprint	核心流程应该是什么？	创建 docs/DESIGN.md，扩展 docs/EXPERIMENTS.md — awaiting-evidence
3	clean-architecture	哪些边界能保留选择空间？	创建 docs/ARCHITECTURE.md
4	domain-driven-design	代码代表什么含义？	扩展 docs/ARCHITECTURE.md
5	clean-code	每个函数是否易于阅读并经过测试？	创建 docs/TESTING.md
6	pragmatic-programmer	哪些习惯能保持代码健康？	扩展 docs/TESTING.md + docs/TECH-DEBT.md
7	system-design	实际需要多大的规模？	扩展 docs/ARCHITECTURE.md
8	ios-hig-design	它在 iOS 上是否有原生体验？	扩展 docs/DESIGN.md — 仅限 iOS
9	37signals-way	哪些内容会发布，哪些会删减？	扩展 docs/PRODUCT.md + docs/STRATEGY.md
10	software-design-philosophy	复杂性藏在哪里？	扩展 docs/TECH-DEBT.md + docs/ARCHITECTURE.md

运行规则

1. 先恢复进度。 在进行任何操作之前，先阅读 docs/CREATE-APP-PLAN.md 和 Journey Map 中的所有材料。如果跟踪文件存在，用 3-5 行概述旅程状态，并询问要进入哪个阶段。完成条件：用户已确认进入点。存在跟踪文件的旅程应恢复，而不是重新开始。
2. 仅在首次运行时进行需求收集。 如果没有跟踪文件：先执行下方的需求收集，然后创建 docs/CREATE-APP-PLAN.md，并将每个阶段的状态设为 pending | in-progress | awaiting-evidence | done | deferred: reason | skipped: reason。完成条件：跟踪文件已创建，且用户已确认阶段计划。
3. 进入阶段。 说明该阶段的作用、需要做出的决策、产出的材料和大致工作量。提供继续／跳过／延期选项——标记为 GATE 的阶段可以延期，但不能跳过。用户选择继续后，将阶段标记为 in-progress。完成条件：用户已作出选择。
4. 调用技能与备用方案。 加载该阶段的技能并使用它：每个阶段的 Invoke 行都会通过 slug 指明技能——使用该技能执行阶段。如果技能不可用，则提供：npx skills add wondelai/skills/<slug> --global。如果用户拒绝，则根据 Brief 执行该阶段——采用最低可行方法。说明当前使用的模式。
5. 阶段内决策。 提出「与用户共同决定」下的所有问题——给出具体选项和你的建议。将选择记录在跟踪文件的 Key Decisions 中。默默作出的决策属于缺陷。
6. 结束阶段。 写入前先展示待签核的材料草稿。获批后：创建或扩展 docs/ 文件，更新跟踪文件（状态、Key Decisions、Next Actions）。完成条件：文件已写入，且阶段行显示 done。
7. 材料管理规范。 写入前先阅读；仅在文件缺失时创建，否则应扩展文件——添加或更新相应章节，并保留其他人的内容。文件名在 docs/ 中使用大写字母。每项建议都必须写成复选框或包含负责人和优先级的表格行。首次创建 docs/ 文件时，请参阅 references/artifact-templates.md；根据完整骨架创建文件（包含所有章节标题），再填写该阶段指定的章节。
8. Agent 负责准备和处理；只有人工可以与客户及测试用户交流。 起草冲刺脚本和访谈指南，并对结果进行评分，然后暂停并将状态设为 awaiting-evidence，直到用户带回笔记。ios-hig-design 阶段仅适用于要发布原生 iOS 应用的情况；否则应在需求收集时跳过。

需求收集

创建跟踪文档前，先询问以下问题：

1. 用一句话描述应用创意，以及背后风险最高的信念是什么？（决定是否进入阶段 1；如果应用要解决的工作还不明确，加入可选的待办工作阶段。）
2. 这一底层创意是否已通过行为证据验证，还是仍停留在猜想？（未经验证且风险高，则必须进入阶段 1；如果已经有付费客户，你可能选错了路线——应选择改进应用或发展应用。）
3. 当前处于什么阶段——周末原型、为发布而获得资金支持的开发，还是围绕它组建团队？（原型侧重阶段 1-3 和 10；正在组建团队时可加入灵感产品阶段。）
4. 你会发布原生 iOS 客户端吗？（会则保留阶段 8；不会则跳过。）
5. 你有可以交流的客户，还是必须先找到他们？（这决定阶段 1-2 中人工证据闭环的安排，以及是否加入可选的妈妈测试／持续发现阶段。）
6. 预计最初几个月的负载是多少——日活跃用户数和每日操作数？（为阶段 7 的容量计算提供依据，避免过早扩容。）
7. 由个人还是团队开发，谁负责发布节奏？（这决定阶段 9 的方案设计。)

阶段跳过启发：核心流程已测试或非常简单时，跳过阶段 2；除非要发布原生 iOS 应用，否则跳过阶段 8；只有在负载明显很小时才跳过阶段 7——但仍需记录预估值；对于周末原型，将阶段 3-6 合并为一次流程，但绝不跳过依赖规则。

然后根据模板创建 docs/CREATE-APP-PLAN.md，为每个阶段标注状态，并将阶段 8 标记为以 iOS 为条件。完成标准：docs/CREATE-APP-PLAN.md 已创建，每个阶段均已标注状态，且用户已确认计划。

阶段

阶段 1 — 验证风险最高的假设（精益创业）

目的： 在编写生产代码前，验证那个一旦为假就会让应用失败的信念。

简介（备用方案）： 逆向规划构建-测量-学习：你必须了解什么、如何判断，以及要弄清这一点所需的最小构建是什么。按致命程度而非测试难易程度对重大假设排序。MVP 是一种学习工具，往往很粗糙（Dropbox 用一段视频而非同步引擎完成了验证）。沿着验证阶梯逐步前进——注册的证明力较弱，付费定金的证明力较强，活跃使用的证明力最强；目标是达到行为证据等级 4-5，绝不要只问“你会用这个吗？”这样的意见。

调用： 使用 lean-startup 技能，提供创意；如果 CUSTOMER.md 存在，也提供工作陈述。要求列出按优先级排序的重大假设、能够证伪风险最高假设的单一最小实验，以及预先承诺的行为成功阈值。

与用户共同决策： 哪个假设一旦为假就会致命？选择哪种实验类型——烟雾测试（需求）、礼宾式服务（价值）还是绿野仙踪（自动化）？运行前固定的通过／转向阈值是什么？只有用户可以对真实用户运行实验；随后暂停并等待证据。

产出物： 创建包含 ## Vision 和 ## MVP Definition 的 docs/PRODUCT.md；创建包含 ## Experiment Cards（EXP-001，包含假设、指标、决策规则）和 ## Experiment Backlog 的 docs/EXPERIMENTS.md。更新跟踪文档。

完成标准： 已明确致命假设，EXP-001 已预先设定阈值，PRODUCT.md 已说明 MVP 范围，且用户已拿到要运行的实验。

阶段 2 —— 降低核心体验风险（design-sprint）

目的： 通过经过测试的门面，确定核心流程应是什么，再投入工程时间。

简要说明（备用方案）： 五天：周一梳理问题，周二绘制草图，周三做出决定，周四制作原型，周五与五位真实用户测试。产出是高保真门面及相关证据，而非代码。风险最高的时刻是陌生用户使用产品的前十分钟——测试他们能否理解产品，并且在没有任何解释的情况下完成核心任务。五位用户足以发现规律；你需要的是规律，而非统计显著性。绝不要解释原型；观察他们在哪里卡住。

调用： 使用 design-sprint 技能，并采用 PRODUCT.md 中的 MVP 范围。要求提供周一问题地图和「我们如何才能……」重构、获胜概念的故事板，以及一份五幕访谈脚本和记录网格（每位参与者使用勾号 / 叉号 / 波浪号）。暂停时，将获批的脚本记录在 docs/EXPERIMENTS.md 的冲刺卡片下，以便在会话中断后保留。

与用户共同决定（返回时）： 测试过的流程是否可直接使用、需要调整，还是暴露出需求问题，需要返回阶段 1？哪些困惑需要转化为修复项？

产出物： 创建 docs/DESIGN.md，并添加 ## Design Direction；在 docs/EXPERIMENTS.md 的 ## Experiment Cards 下添加冲刺测试及其结论。更新跟踪表。

完成条件： DESIGN.md 记录了方向；冲刺结果及结论已记录在 EXPERIMENTS.md 中；用户已选择继续 / 调整 / 返回。

阶段 3 —— 划定边界（clean-architecture）

目的： 隔离业务规则，让数据库、框架和服务提供方始终是可替换的细节。

简要说明（备用方案）： 源代码依赖指向内部——框架依赖用例，用例依赖实体。业务规则不得导入框架或 ORM。用例定义接口（例如 InvoiceRepository）；基础设施负责实现接口；控制器将 HTTP 请求转换为普通请求对象，并接收普通响应——任何框架类型都不得跨越边界。诊断方法：能否在不运行数据库、Web 服务器或框架的情况下测试业务规则？四个圆圈很常见，但并非必须——只在容易变化的地方划定边界。

调用： 使用 clean-architecture 技能，并采用 PRODUCT.md 中已验证的 MVP 范围。要求提供分层图、包含请求 / 响应模型的核心用例，以及其依赖的存储库接口。

与用户共同决定： 真正容易变化的边界在哪里（数据库、第三方 API、交付机制）？采用完整的四层结构，还是为小型应用合并适配器层和框架层？

产出物： 创建 docs/ARCHITECTURE.md，包含 ## System Context 和 ## Layer Map & Dependency Rule（各层、层间依赖关系、违规情况表）。更新跟踪表。

完成条件： ARCHITECTURE.md 列明各层，明确说明依赖规则的方向，并且无需任何基础设施即可测试核心业务规则。

阶段 4 — 建模领域（domain-driven-design）

目的： 让代码使用业务语言，使领域专家能够阅读代码并发现问题。

简要说明（备用）： 模型就是代码。建立统一语言——使用领域概念命名，而非技术角色（InvoiceDraft.finalize() 就优于 DataProcessor.process()）；难以命名是设计信号。限界上下文：一个词在某个边界内只表示一种含义（计费中的“客户”不必等同于支持中的“客户”）。聚合：由一个负责维护不变量的根组成的集群——保持聚合规模小，并通过 ID 引用其他聚合。避免贫血模型；将行为放入实体和值对象中。

调用： 使用 domain-driven-design 技能和 ARCHITECTURE.md 的分层图。询问统一语言、限界上下文和上下文映射，以及核心聚合及其根所维护的不变量。

与用户共同决定： 哪些是核心领域（你的竞争优势），哪些是通用子领域（身份验证、电子邮件、支付），应该购买或使用开源方案？同一个词在哪些上下文中确实可以表示不同含义？

产出物： 扩展 docs/ARCHITECTURE.md：添加 ## Bounded Contexts & Context Map 和 ## Domain Glossary (Ubiquitous Language)（术语 | 含义 | 代码名称）。更新跟踪文档。

完成标准： 术语表列出了核心概念，上下文及其关系已完成映射，并且仓库接口按照阶段 3 的要求位于领域层。

阶段 5 — 编写易读的代码（clean-code）

目的： 随着代码库增长，让每个函数都易于阅读和测试。

简要说明（备用）： 代码的阅读次数远多于编写次数。函数应简短、各司其职，并处于单一抽象层级；名称应清楚表达意图；不要使用标志参数（这是代码异味——函数在做两件事）；命令与查询分离；提取并命名清晰的函数胜过写注释。测试是一等公民——糟糕的测试比没有测试更糟。按照 F.I.R.S.T.（快速、独立、可重复、自我验证、及时）原则编写测试，并使用基于行为的名称，例如 shouldRejectNegativeTotal。

调用： 使用 clean-code 技能，并结合阶段 3-4 的核心模块。要求按照规则进行评分并修复问题，同时为核心用例编写整洁的单元测试（安排-执行-断言、描述性名称、构建器辅助函数）。

与用户共同决定： 哪些质量标准是提交的门槛——函数长度、名称清晰度、不吞掉异常？首批测试必须覆盖哪些成功路径和失败情形？

产出物： 创建 docs/TESTING.md，包含 ## Test Strategy（测试金字塔、工具，以及哪些检查通过才算达标）和 ## Safety Net Map（模块 | 固定行为 | 测试文件 | 缺口）。更新跟踪文档。

完成标准： TESTING.md 说明了测试策略；核心用例有通过的、名称体现行为且无需数据库的测试；提交质量门槛已记录。

阶段 6 — 引入元规范（pragmatic-programmer）

目的： 培养有助于代码库经年累月保持易于修改的习惯。

简介（备选方案）： 发射一颗追踪弹——让一个真实、精简的切片贯穿每一层（从 UI 到用例，再到数据库并返回），并将其保留下来，以便在第二天发现集成错误。DRY 只适用于知识，不适用于偶然的相似性。正交性：更换数据库不应影响 UI。可逆性：将第三方 SDK 封装在自有接口后，这样更换 Stripe 或模型提供方时无需改动业务逻辑。破窗效应：发现第一个临时修补就立即修复，或用已跟踪的工单将其围起来——绝不放任问题悄然腐烂。

调用： 使用 pragmatic-programmer 技能，并提供 ARCHITECTURE.md 和核心用例。要求设计最精简的端到端追踪弹，并为每项第三方依赖设计一个适配器接口。

与用户共同决定： 追踪弹切片是什么？破窗政策是否采取零容忍，并要求跟踪工单？哪些依赖现在就要设计适配器接口，哪些可以以后再做？

产出： 扩展 docs/TESTING.md（添加 ## CI Gates）和 docs/TECH-DEBT.md（添加 ## Debt Budget & Broken-Windows Policy 和 ## Adopted Conventions）。更新跟踪器。

完成标准： 已明确追踪弹的端到端设计，为每个提供方命名了适配器接口，并记录了破窗政策。

阶段 7 — 如实估算规模（system-design）

目的： 估算实际负载，并证明目前不需要构建哪些东西。

简介（备选方案）： 从需求出发，而非从解决方案出发。QPS = 日活跃用户数 x 每日操作数 / 86,400；峰值为平均值的 2-5 倍；存储量 = 每日记录数 x 记录大小 x 保留期限。对于几百名用户，计算结果几乎总是表明，一个索引完善的数据库加缓存就足够了。按顺序扩展：先垂直扩展，再添加只读副本，然后使用旁路缓存，最后才分片。只有在估算或实际瓶颈证明其合理时，才使用队列来吸收流量峰值，并将耗时工作（例如照片 OCR）与请求路径解耦。

调用： 使用 system-design 技能，并提供接收需求时收集的负载数据。要求进行粗略的 QPS 和存储量估算，并明确列出目前不需要的技术。

与用户共同决定： 根据估算，哪些扩展措施要明确暂缓？如果存在实际瓶颈，当前需要缓存或队列的依据是什么？

产出： 扩展 docs/ARCHITECTURE.md：添加 ## Data & Storage Decisions 和 ## Decision Log（日期 | 决策 | 原因 | 否决的备选方案），将每项“暂不实施”记录为一项决策。更新跟踪器。

完成标准： 已记录容量估算，明确列出了暂缓的扩展技术，并且任何缓存或队列都有数据依据。

阶段 8 — 打造原生体验（ios-hig-design）— 仅限 iOS

目的： 打造原生 iPhone 客户端体验，这是赢得 iOS 用户信任的基础。仅在交付原生 iOS 客户端时运行（在 intake 阶段决定）；否则跳过。

简介（备用方案）： 三大支柱——清晰、尊重和层次感。遵守安全区域（Dynamic Island、主屏幕指示器）；每个触控目标至少为 44x44 pt；使用语义颜色（Color(.label)、Color(.systemBackground)），自动适配深色模式；使用语义文本样式支持动态字体；采用原生导航——主要目的地使用标签栏，逐层深入时使用 NavigationStack，专注处理任务时使用工作表，绝不使用汉堡菜单。无障碍是首要考虑：每个控件都要有标签，且 VoiceOver 能完成所有任务。

调用： 使用 ios-hig-design 技能检查应用的关键屏幕。请其审查安全区域、44pt 触控目标、语义颜色和字体、原生导航以及无障碍标签。

与用户共同决定： 首次审查涵盖哪些屏幕？是否有刻意偏离平台规范的设计？这些设计是否有充分理由？

产出： 扩展 docs/DESIGN.md：添加 ## Components（组件 | 决策 | 状态）和 ## UX Audit Findings（问题 | 启发式原则 | 严重程度 0-4 | 修复方案 | 状态）。更新跟踪表。

完成条件： 每个纳入范围的屏幕都已审查，审查结果已记录并标明严重程度，无障碍方面的差距已作为修复项记录。

阶段 9 — 按固定节奏交付（37signals-way）

目的： 在固定时间内交付聚焦的 v1，抵制功能膨胀。

简介（备用方案）： 打造完整产品的一半，而不是半吊子的产品。先梳理工作再下注：粗略到保留设计自由度，完善到消除重大未知因素，并以投入意愿为界限（“这件事值得花两周”）——而不是估算工期。固定时间，精简范围以适应时间，绝不反过来。将梳理成型的方案投入固定周期；截止日期到来时，熔断机制会终止所有未完成的工作。打造有主见的软件：提供的每个偏好选项，都是一次拒绝做决定——选择合理的默认值；面对功能请求，默认回答应是尊重地说“现在不做”。

调用： 使用 37signals-way 技能，并参考 PRODUCT.md 中的 MVP 范围。请其将下一个功能整理成方案（问题、投入意愿、面包板、可能的复杂分支、明确不做的事项），并列出 v1 精简清单。

与用户共同决定： 下一个功能的投入意愿是什么？哪些 v1 功能要删减？哪些面向用户的偏好应设为有主见的默认选项？

产出： 扩展 docs/PRODUCT.md（## Outcome Roadmap）和 docs/STRATEGY.md（## No-List——明确不会做的事项）。更新跟踪表。

完成条件： 下一个功能已整理成方案并明确投入意愿；v1 精简清单已列入 STRATEGY.md 的 No-List；路线图已体现固定时间、灵活范围。

阶段 10 — 将复杂性视为敌人（software-design-philosophy）

目的： 控制每个模块的复杂性——这是审视其他所有阶段的视角。

简介（备用）： 复杂性是指结构中任何会让系统难以理解和修改的因素。优先选择深模块——以简单接口提供强大功能——而不是浅模块；评估模块时看功能与接口复杂度之比，而非代码行数。这可以纠正 Clean Code 所强调的“小”，以及 DDD 中许多概念堆叠成类泛滥（大量只有一个方法的浅类）的问题。战略优先于战术：持续投入额外的 10-20% 用于设计，因为早期走捷径造成的影响会随着团队和代码库的增长不断叠加。

调用： 使用 software-design-philosophy 技能评估阶段 3-6 中的模块。要求进行深浅模块评估，指出浅类、透传方法和跨边界的信息泄漏，并说明可合并之处。

与用户共同决定： 哪些浅模块应该合并为更深的模块？哪些战术性捷径正在累积债务，值得现在投入战略性的额外 10-20% 来偿还？

产出物： 扩展 docs/TECH-DEBT.md（## Smell Inventory：异味 | 位置 | 重构方案 | 状态）和 docs/ARCHITECTURE.md（## Decision Log）。更新跟踪表。

完成条件： 浅模块和信息泄漏已记录在 Smell Inventory 中，合并决策已记录，并就战略与战术的取舍达成一致。

可选阶段

技能	添加时机	产出物
jobs-to-be-done	应用要完成的任务模糊不清或存在争议	创建 docs/CUSTOMER.md
mom-test	需要与客户交流来验证假设，而不是听取意见	扩展 docs/CUSTOMER.md
lean-ux	团队希望采用假设驱动的 UX，而非繁重的规格说明	扩展 docs/EXPERIMENTS.md
ux-heuristics	第一个可用版本需要进行可用性检查	扩展 docs/DESIGN.md
hooked-ux	产品依赖用户养成习惯并重复使用	扩展 docs/PRODUCT.md
design-everyday-things	核心流程让测试用户感到困惑	扩展 docs/DESIGN.md
continuous-discovery	发布后需要保持每周与客户联系	扩展 docs/CUSTOMER.md
inspired-product	团队围绕产品组建，需要愿景和成果路线图	扩展 docs/PRODUCT.md

可选阶段遵循相同的执行规则——像核心阶段一样加载并使用每项列出的技能；当“添加时机”条件首次满足时插入相应阶段。

常见错误

错误	修正方法
尚未验证想法就构建架构	先执行阶段 1——验证成本低，重写成本高（lean-startup）。
把 “MVP” 当成写出垃圾代码的许可证	先交付最小可行成果以获取认知，获批后再把正式产品做好；最小不等于低质量（lean-startup）。
让框架决定架构	将框架放在外圈作为插件；不要让 ORM 类型跨越用例边界（clean-architecture）。
贫血领域模型	将行为放入实体和值对象，而不是臃肿的服务类（domain-driven-design）。
类泛滥——过度追求“小”	根据模块的深度（单位接口所承载的功能）而非代码行数来评估模块（software-design-philosophy）。
过早扩展规模	先估算；一个数据库加缓存就足以支撑大多数应用——最后再分片（system-design）。

完成整个流程

退出检查清单：

• PRODUCT.md 写明已验证的 MVP 和愿景；EXPERIMENTS.md 中有一项已执行的实验及记录的结论。
• ARCHITECTURE.md 通过依赖规则测试，并说明核心领域、上下文和容量估算。
• TESTING.md 展示核心用例在不依赖基础设施的情况下通过测试，且追踪子弹已端到端运行。
• 如果要继续发布，则需制定 STRATEGY.md 的不做清单，并设计好下一个功能。

关闭跟踪记录：每个阶段均标记为 done 或 skipped: reason，记录关键决策，并将后续行动纳入相关文档（不要留在跟踪记录中）。后续引导：

• 如果发现应用背后的想法尚未经过验证，或本质上属于商业模式问题，请继续使用 create-business 技能。
• 如果应用的发展超出了初始架构，且结构本身成了棘手问题，请继续使用 design-code-architecture 技能。