这一部分先定盘，不先开写#

Part 1 把认知冷启动先做完了：范式为什么变了，工具应该怎么分工，Prompt、Context、Harness 为什么最后会收束成控制面，主线项目为什么值得继续往下做。

从这里开始，项目才正式进入生命周期。

但真正危险的地方也正是在这里。
很多团队一到这个位置，就会很想立刻让 AI 开写页面、接口、目录和脚手架。表面上看，项目像是突然开始提速了；实际上，更常见的情况是版本目标还没定稳，技术底板还没收住，仓库边界和系统边界也还没立好，AI 已经先把一堆模糊判断固化成了代码事实。

所以 Part 2 要做的，不是拖慢开发，而是先把那些一旦写进仓库就会被放大的判断收住。
只有这一步做对了，后面的快才不是幻觉。

这一部分真正想解决的问题

项目从“有了一个想法”进入“开始正式开发”之间，最容易漂的那几层判断，到底该先怎么定。

定盘到底在定什么#

这里说的“定盘”，不是一上来写总架构说明书，也不是一口气把未来半年全拍死。
它更像是在项目真正开工前，先把最容易失控的五层东西定到刚刚好的粒度：

1. 当前版本到底只回答哪个问题，明确不回答什么。
2. 技术栈先定到什么程度，哪些选择现在还没有资格被拍板。
3. 仓库骨架、命令入口和协作资产先怎么摆，才能让人和 AI 都不乱跑。
4. 系统设计初稿先写到什么粒度，才足够继续拆 issue，而不会提前把结构拍死。
5. 前面收下来的这些判断，最后应该怎样外置成 Spec、Rules、Skills 这类控制面资产。

这五层一旦串起来，项目就会从“边写边猜”进入“带着边界往前推”的状态。

这 5 篇文章是怎么一篇接一篇咬合的#

Part 2 不是五篇并列的小论文，而是一条连续的推进链。

如果把这条链压成一句话，就是：

先把问题收窄，再把底板定住，再把仓库搭好，再把系统边界立起来，最后把这些判断外置成控制面资产。

读完这一部分，手里应该有什么#

Part 2 读完之后，最理想的状态不是“懂了几个概念”，而是手里真的已经多出一组能继续往下做的东西。

至少应该有这些产物：

1. 一份项目章程型总纲，能说清当前版本只回答什么、不回答什么。
2. 一组最小技术底板和延后决策清单，知道现在该定什么，不该定什么。
3. 一个能承载协作的 workspace 骨架，知道命令入口、目录职责和占位标准该怎么立。
4. 一页系统设计初稿，能写清主资产、官方路径、关键边界、已定 / 待定问题。
5. 一条从 discussion、issue、proposal、design、specs、tasks 一路收紧的控制面流程。

这时候项目才算真正进入“可以稳定开发”的状态。
后面的实现、调试、验证、交付和治理，不再需要反复回头重新定义项目到底在做什么。

下一步为什么才轮到开发#

Part 3 才会真正进入主干开发。
但那时的开发，已经不再是“给 AI 一个需求，让它开始写代码”，而是在一组已经收好的目标、边界、仓库入口、系统设计和控制面资产上继续推进。

这也是为什么 Part 2 看起来像在“做准备”，实际上却极其关键。
它决定了后面的开发到底是在放大判断，还是在放大误判。