为什么AI编程越写越乱？其实，

AI 目前是概率模型。不是因果链模型，它靠概率生成内容，所以大概率会出错——不是偶尔出错。是结构性的、不可消除的出错。

这决定了用 AI 写代码的主要矛盾：AI 能快速产出大量代码，但你没法完全信任它。这篇文档梳理的就是怎么解这个矛盾——在不同项目阶段，用不同手段把 AI 的不确定性约束在可控范围内。从 Vibe Coding 的“放手跑”，到 Spec 的“写清楚再动手”，再到 Harness 的“用流程锁死”。本质上都是在回答同一个问题：怎么让 AI 出错时能被发现、被兜住。

AI 编码整体框架：三个阶段

项目从 MVP 阶段 → 初期运行 → 长期稳定运行治理手段跟着变：

• MVP 阶段少约束，让模型自由发挥跑出原型。前期最关键的是速度和验证想法。
• 初期运行引入 Spec。把意图、边界、决策沉淀成文档，让 AI 在有约束的上下文里干活。
• 长期稳定运行引入 Harness，把规范变成 AI 绕但是去的物理锁。

阶段	主要手段	约束强度	适用场景	升级信号
MVP 阶段	几乎无约束探索、验证想法，MVP 跑通要长期运行？其实，→10 Spec 文档引导，靠 AI 自觉已稳定、需长期运行 →100 Harness 流程强制。绕但是去复杂项目、关键功能不能错.

MVP 阶段 — 几乎无约束探索、验证想法 MVP 跑通要长期运行？老实说，→10 Spec 文档引导，靠 AI 自觉已稳…

阶段	主要手段	约束强度	适用场景	升级信号
MVP 阶段	几乎无约束探索 、 验证 想法，MVP 跑通 要 长期 运营?→ 10 Spec 文档 引导，靠 AI 自觉 已 稳定 、需 长期 运维 → 100 Harness 流程 强制。绕 但是 复 杂 项目 、关 键 功能 不 能 错	低	小 项目/初始 探索 / 原型 开发	当 文档 无 法 管 住 项目 时 升级 到 更 高 层 次 控 制 逻辑 与 人 工 审核…

第一部分的观点是。 MVP 阶段

Vibe Coding：放手让 AI 跑原型

痛点1的观点是，代码总是乱套，你只想快速原型，却不想先花时间写规则。

痛点2的观点是。每次新建任务都得重新教模型，让人疲惫不堪。

痛点3的观点是，团队成员之间对目标理解不一致导致返工频繁。

• 先与AI讨论清楚项目因果链：* 为什么要做这个项目？* 什么是主要功能，* 希望使用者体验如何？说起来，* 明确哪些不做。按理说，这些信息不一定写成正式文档。但必须在对话中讲清楚，让AI拥有完整认知。不过，

定义协同规范：* 遇到不确定先问还是直接给方案；改代码前是否说明改动原因；完成后是否主动跑测试并报告结果；哪些操作需要你确认才执行。将这些写进 /AGENTS.md/README.md等文件中，一旦设定好就无需每次开会话都重新教模型。这一步可大幅降低团队协作成本和误解率。

MVP之后工程化治理:先重构打地基 

不要在烂摊子上硬补规范。要先把结构拆好，再加测试骨架。其实，否则即使后面再写规范也难以纠正根本问题。

"Spec" 编码 & SDD 思路全貌

• 准确表达意图。并把意图文档化 

- 意图不仅是“做什么”，还要说明“不做什么”和“为何这么决策”。

• 控制上下文 

- 用 @Files或docs/目录只给必要知识切片，以避免长文本导致注意力弥散。

"Harness" —— 面向大型程序的最终治理层

- 缺乏硬执行会导致长任务频繁破坏现有功能；CI/CD+pre‑commit hook 是最具性价比的 harness。

---