9.2 12 周四阶段工作流

概念

12 周不是随便拍的数字。它来自一个朴素的判断：养成一个工作习惯的最短周期是 12 周，短于 12 周就是「体验」，长于 12 周客户就失去耐心了。 这 12 周切成四个阶段，每个阶段三周，有明确的里程碑和交付物：

🖼 图：twelve week timeline

这个切法遵循三条逻辑：

第一，每个阶段交付一个「可验收物」（见上表交付物列）。客户每周都能看到东西在往前走，不会出现「做了两个月不知道在干嘛」的情况。

第二，阶段的顺序由项目自然节奏决定。 任何项目都是先立项→再设计→再开发→最后收尾。你不可能先开发再立项，也不可能在没方案的情况下就写代码。所以四阶段的顺序是刚性的，不能调换。

第三，每个阶段的主力工具不同。 立项期主力是专家和立项卡技能；方案设计期主力是联网检索+可视化+PRD+连接器；开发推进期主力是 AI Coding；项目管理期主力是评审技能和知识库。其他工具照样用，只是每个阶段有个「主战场」，学员的注意力要集中在这个主战场上。

• 注意 ：12 周是基准节奏，不是铁律。有些客户项目周期只有 8 周，有些可能拉到 16 周。调整的原则是： 各阶段之间的比例保持不变 （立项期占 25%、方案设计期占 25%、开发推进期占 25%、项目管理期占 25%），而不是把某个阶段砍到 0。立项期再急也不能少于 2 周，项目管理期再忙也不能省。

用法

下面把每个阶段的「每周干什么、交付什么、用哪个工具」摊开来说。

阶段一：立项期（W1-W3）

这一阶段的目标是「识别真机会、写出站得住的立项卡」。WorkBuddy 的角色是把判断框架固化下来，让每个人问出来的问题都在同一套标准上。

W2 的关键是真需求/伪需求判断——资料不进知识库就凭空梳理，等于拍脑袋。

W3 的评审是立项期第一道 Gate——工具出初稿和初审意见，签字的是项目经理或客户。

• 注意 ：立项卡定稿的凭证含义是「通过评审、可以进入方案设计」，光填完存档不算数。如果 W3 末评审没过，W4 不能往下走，得补立项卡。这就是 Gate 的意义——挡住不成熟的项目往前冲。

阶段二：方案设计期（W4-W6）

这一阶段从「想清楚」走到「写下来、传出去」。WorkBuddy 的价值集中在检索对标、可视化出图、以及把 PRD 直接落到协作平台。

W4 的关键是让方案设计有外部参照，别自己闷头做。

W5 是方案设计期最容易失控的一周——需求膨胀靠「最小可用」标准写进专家人设来守住。

W6 是关键节点：PRD 必须单列 AI 特有章节，这三块是 AI 产品的命门。

• 注意 ：W6 末的 Gate 2 评审通过的只是「PRD 含异常/兜底/验收口径、MVP 边界清晰、开发能看懂」，不是「业务逻辑对」。业务逻辑对不对，要等开发推进期的 POC 上线后由客户来确认。

阶段三：开发推进期（W7-W9）

这一阶段的高光是 W8——用 AI Coding 从 PRD 直达可运行 Demo，这正是第 3 章工程底座（Harness / Loop）在交付阶段的延伸。但要注意，这一阶段也有明显的边界。

W7 的软件工程常识 WorkBuddy 不提供，得自己补课——专家只能帮着把 PRD 拆成任务清单建立语感。

W8 当堂一定要跑出能运行的东西——手上没跑通，方法论全是空话。

W9 是开发推进期的 Gate——评审技能给结构化意见，迭代优先级的最终决策靠人，纪要归档供下个复用。

• 注意 ：AI Coding 出活快不代表可以不做测试。每个功能点都要有对应的测试用例。没有测试的代码不予通过——这是铁律。

阶段四：项目管理期（W10-W12）

这一阶段决定了这次培训「是留下了系统，还是留下了能力」。W12 的沉淀动作，正是第 8 章讲的「把经验变成组织资产」在培训收尾的落地。

W10 的要点是自动化——管理动作不依赖某个人的记性。

W12 是整个 12 周回报最大的一步——陪跑沉淀成技能后，第二批能自助跑通 80%。

沉淀要走企业管理端，不能只存在个人客户端。成员自定义技能仅对本人可见，要让全团队复用，必须把技能上传到企业后台、把方法论回灌到企业知识库——存在你自己电脑里的，那不叫组织资产，叫个人笔记。

• 注意 ：W12 的沉淀动作不是「可选的加分项」。如果跳过 W12，这个项目就只是「完成了一个项目」，不会变成「组织资产」。

示例

假设客户是一个做供应链管理的公司，项目是「合同审查自动化」。12 周大概长这样：

• 立项期（W1-W3） ：专家带全链路认知 → 知识库梳理判真伪需求 → 立项卡技能初稿+评审初审（法务 IT 终审）。

• 方案设计期（W4-W6） ：竞品对标 → 可视化画原型守 MVP → PRD 技能写 PRD 连接器落地。

• 开发推进期（W7-W9） ：专家拆任务 → CodeBuddy 当堂跑出 POC → 评审打分（迭代优先级人定）。

• 项目管理期（W10-W12） ：里程碑+风险表 → 相关方地图 → 复盘沉淀回灌（W12 复盘会具体到「W8 差点范围蔓延加 3 个功能点」这种粒度）。

这个时间线看起来很顺，但真实项目里一定有波折。12 周节奏是一套参照系，项目偏了之后知道往回怎么找齐。按表走完不偏一天，从来都做不到，也不用做到。

• 注意 ：上面的「合同审查自动化」只是示例，不是唯一场景。12 周工作流可以套到任何需要 AI 落地的项目上——客服知识库搭建、销售话术生成、运营报表自动化，结构都是一样的：立项→设计→开发→沉淀。

注意事项

• 不要把 12 周当 Sprint 来跑 ：Sprint 的逻辑是「每两周交付一个可用的软件增量」，12 周养成计划的逻辑是「每周边交一个交付物初稿」。前者关注软件，后者关注人和流程。如果你把 12 周跑成了 6 个 Sprint，说明你只做了开发推进期，跳过了立项和沉淀。

• 阶段可以重叠但不能跳过 ：如果项目赶时间，W6 和 W7 可以稍微重叠（一边写 PRD 一边开始拆任务清单），但立项期和项目管理期不能跳过。跳过立项期 = 项目没有共识基础；跳过项目管理期 = 项目没有沉淀成资产。

• 每个阶段的 Gate 都是真的 Gate ：Gate 不是走形式，没过就得回去补。如果你发现每个 Gate 都过了，说明你的 Gate 标准太松了，需要往上调。