Spec→实现→结晶，AI项目失控的根源与五阶段纪律框架

当工程师用AI在5分钟内生成一个MVP原型，10分钟产出一份结构完整的需求文档时，项目似乎已步入正轨。但现实是，大量AI辅助项目最终陷入‘开头热闹、中间混乱、结尾无果’的困境。问题并非技术能力不足，而是缺乏对AI工作流的纪律性约束。AI擅长展开模糊想法，却无法判断‘需求是否真已确定’‘方案是否与目标一致’‘任务是否真正完成’——这些恰恰是项目失控的核心缺口。

这一现象在工业自动化领域尤为明显。例如，有工程师尝试让AI编写CODESYS平台的ST（Structured Text）代码，结果虽能生成语法近似的文本，但因未遵循平台特有的扩展规则（如AND_THEN关键字、全局变量访问限制），导致编译报错或逻辑错误。即便代码通过编译，注释缺失、缩进混乱、命名不规范等问题仍使后续维护成本剧增。这揭示了一个深层矛盾：通用标准（如IEC 61131-3）与平台特异性规则之间存在断层，而AI若无明确指引，极易在‘看似正确’中埋下隐患。

为系统性解决该问题，一种名为Spec Pipeline的纪律框架被提出并实践验证。它不依赖新工具或复杂流程，而是通过五个严格定义的阶段与门禁机制，将AI行为纳入可控轨道。其核心理念是：不让AI跳阶段——哪怕它“自动”开始生成方案，也必须在前序条件满足后才允许推进。

第一阶段为需求收敛。常见误区是用户一句‘帮我设计XX功能’，AI立刻输出方案。但真正的起点应是界定核心对象、明确In Scope/Out of Scope、定义成功信号，并列出关键未知项。所有要素需经‘Ready Gate’判定：仅当核心定义、范围边界、可验证标准均已清晰，且待定项不阻塞骨架设计时，方可放行。此阶段的关键纪律是——Ready Gate未通过，禁止进入下一环节。

第二阶段是苏格拉底访谈。通过结构化追问（通常3–5轮，每轮2–3个关键决策点），暴露用户自身认知盲区与隐含假设。AI负责提问与整理澄清上下文（clarified_context.md），而非自行填补空白。这是防止‘假定稿’的第一道防线：若用户声称‘已想清楚’，可跳过；但绝不能以AI的推测替代真实确认。

第三阶段为摄入→门禁→起草三步闭环。首先‘摄入’所有输入（需求收敛成果、访谈记录、技术约束、参考材料），整合为标准化Context；接着‘门禁’检查：Context是否完整？是否存在矛盾？关键依赖是否确认？任一缺失即回退补充，绝不带缺口前行；最后‘起草’但需谨记：草稿仅为审阅对象，非执行定稿。一份合格草稿应包含明确边界、核心流程图、关键权衡说明及显式标记的假设部分。

第四阶段结晶（Crystallize）最易被跳过，却最关键。它不同于简单归档，而是对变更是否真正成立进行判定：

跳过结晶会导致方案‘写了不算数’、状态滞留旧版、后续接手者无所适从。其本质是将‘做完了’从主观感受转化为客观可验状态。

第五阶段验证是对结晶产物的完整性复核，确保四类验证项全部达成：文件存在性（所有规划文件已落盘）、交叉引用有效（README链接可用）、状态一致（frontmatter已更新）、可发现性（索引已注册）。仅当全部通过，项目节点才算正式闭环。

该框架已在多个实际项目中落地。例如一个内容运营工具开发：15分钟完成需求收敛（目标为Markdown一键分发至微信公众号与知乎，排除视频平台，定义‘写一篇推两平台’为成功信号）；10分钟苏格拉底访谈厘清图片处理（统一图床）、格式适配（各平台独立层）、认证方式（初期手动token）；30分钟完成摄入-门禁-起草，生成含边界说明与假设标注的方案草稿；随后进入结晶与验证，确保所有输出物可追溯、可复用。

值得注意的是，该框架与工程规范体系高度协同。如针对CODESYS ST编程，已有实践者整理出cr-st-expert——一本‘给AI看的《企业级ST标准化编程规范手册》’，涵盖八类平台特定规则（如扩展关键字、变量访问限制、枚举使用规范等），使AI在生成、修改、审查代码时有据可依。这印证了同一逻辑：AI需被置于明确规则之下，才能从‘能写’升级为‘可靠地写’。

在AI日益渗透研发全流程的当下，技术能力的提升反而放大了流程失控的风险。过去靠人工经验弥补的模糊地带，如今被AI加速暴露。Spec Pipeline的价值不在增加步骤，而在建立‘不可绕过的检查点’。它把项目管理中隐性的共识要求，转化为显性的、机器可识别的门禁条件，使AI从‘自由发挥者’转变为‘受控协作者’。

这套框架适用于各类软件开发、系统设计乃至产品策划场景，尤其适合中小型团队快速建立协作纪律。其普适性在于：不依赖特定工具链，仅需文档模板与协作意识即可实施。当‘开始太容易’成为常态，唯有用纪律为AI设定边界，才能避免项目在高效启动后迷失于无尽的修正循环中。