AI 编码的“破壁”之路：从 Vibe Coding 到渐进式 Spec 架构实战

闹纳尼

2人浏览 · 2026-03-16 10:02:18

闹纳尼 · 2026-03-16 10:02:18 发布

在 2026 年的今天，大模型的编码能力已经发生了断崖式的进化。Chatbot Arena 的数据显示，Gemini 3.1 Pro 和 Claude 4.6 等顶级模型在多轮交互的稳定性上已经能够独立处理中等复杂度的工程任务。然而，很多开发者在实际使用中依然觉得 AI “时灵时不灵”：要么是改了 A 坏了 B，要么是由于上下文丢失导致 AI 开始胡言乱语。

问题的核心不在于模型“能不能写”，而在于我们如何应对软件开发的本质复杂度。本文将基于阿里妹导读的最新实践，深度解析一套能够压缩偶然复杂度、提升 AI 编码确定性的“渐进式 Spec”实战框架。

一、认知对齐：Agent 不是魔法，是循环

在深入方法论之前，我们需要先对齐三个基础认知，这是所有 AI 编码实践的地基。

1.1 模型性能的断崖式差异

当前 T0 级模型（如 Gemini 3.1 Pro）与 T2 级模型的差距不在于“功能覆盖”，而在于“一次做对的概率”。T0 模型能主动处理边界情况并生成全链路代码，通常 3 轮交互即可解决问题；而 T2 模型可能需要 15 轮甚至更多，且容易遗漏关键逻辑。模型是地基，方法论是上层建筑。

1.2 Agent 的本质

Agent 不等于裸 LLM。Agent = While 循环 + Tool Use + 工具执行器。
它的“智能”来自模型，“能力”来自工具（如读写文件、执行 Shell），而“自主性”则来自那个不断检查状态并决定下一步行动的循环。这意味着，AI 的能力边界是由你给它的工具决定的，安全性则靠框架约束。

1.3 软件复杂度的视角

《人月神话》告诉我们，软件复杂度分为本质复杂度（业务逻辑本身）和偶然复杂度（工具和流程引入的负担）。AI Coding 的终极目标是：高效应对本质复杂度，极限压缩偶然复杂度。

二、渐进式 Spec 编码框架：拒绝“盲目对话”

直接和 AI 聊天写代码（Vibe Coding）会面临上下文膨胀、逻辑漂移和缺乏验证等工程问题。为了解决这些问题，我们提出 Spec Coding 模式。

2.1 Spec Coding 三铁律

No Spec, No Code：没有结构化文档，不准写代码。
Spec is Truth：文档与代码冲突时，错的一定是代码。
Reverse Sync：发现 Bug 或逻辑偏差，先修文档，再修代码。

这背后的逻辑是：Code is Cheap, Context is Expensive。通过增加极低成本的文档输入，减少 AI 反复试错的高昂输出成本。

2.2 核心创新：渐进式复杂度

这是本框架区别于其他方案的核心。现实中 70% 的需求是小微需求（如改个字段、修个简单 Bug），如果强制走完整的 Spec + Tasks 流程，偶然复杂度会吞噬效率。

渐进式原则：

简单需求（≤0.5人日）：仅依靠 rules/ 约束，直接对话修改。
中等需求（0.5-2人日）：编写简版 spec.md，明确变更范围。
复杂需求（>2人日）：完整流程，包含 spec.md、tasks.md 和两阶段 review。

三、框架全貌：code_copilot 目录结构

建议在项目根目录建立 code_copilot/ 文件夹，将其作为 AI 的“大脑”和“记忆库”。

code_copilot/
├── rules/          # 编码规范、安全红线、技术栈偏好
├── knowledge/      # 领域知识、架构决策、历史踩坑记录
├── changes/        # 当前正在进行的变更
│   ├── spec.md     # 需求与设计规格
│   ├── tasks.md    # 原子化任务拆解
│   └── log.md      # 执行日志与新发现的知识
└── archives/       # 已完成变更的历史归档

四、标准工作流：从提案到归档

一个完整的 AI 协作周期分为四个阶段：Propose → Apply → Review → Archive。

4.1 Propose（提案）：人主导，AI 辅助

在这一阶段，AI 的身份是“侦察兵”和“参谋”。

Research：AI 必须先扫描代码现状，每个结论必须带有文件路径和方法名。
分段确认：AI 按段输出（代码现状 -> 变更范围 -> 技术决策），每段需用户确认。
HARD-GATE：在完整 Spec 和 Tasks 生成前，严禁进入编码阶段。

4.2 Apply（执行）：AI 主导，人审查

AI 转化为“施工队”。

原子化执行：按 tasks.md 逐条执行，每完成一个 task 必须展示编译或测试证据。
零偏差原则：AI 必须像打印机一样严格执行计划。若发现计划有误，立即停止，回到 Spec 阶段进行 Reverse Sync。

4.3 Review（审查）：双阶段 Sub Agent

为了避免“既当裁判又当选手”，建议使用独立的 Sub Agent 进行审查：

阶段一：Spec Compliance。核对代码是否完整实现了 Spec 中的功能点。
阶段二：Code Quality。基于 rules/ 检查规范、安全红线和异常处理。

4.4 Archive（归档）：知识沉淀

这是形成“知识飞轮”的关键。AI 会主动识别本次开发中的隐性经验（如某个中间件的特殊坑），询问用户后沉淀到 knowledge/ 目录。

五、实战中的深度思考

5.1 人的角色转变

在 AI 时代，开发者的角色从“全干”转变为**“管和验”**：

管控：决定让 AI 看哪些上下文。
指挥：在多个方案中做决策，审批执行计划。
评价：验收结果，发现并纠正偏差。

5.2 自由度的控制

大部分人的错误在于自由度给反了：

调研/设计阶段：应给 AI 高自由度，鼓励其充分探索和想象。
执行阶段：自由度应为零。必须严格按图施工，有问题先改图纸。

5.3 真正的护城河：知识底座

Prompt 和 Agent 工作流属于偶然复杂度，容易被工具迭代所抹平。团队真正的核心资产是 knowledge/ 目录下的领域 Know-How、架构决策背景和团队隐性经验。
一个没有知识库的 AI，就像一个只背过编码规范的应届生，业务逻辑全靠猜。

六、工具选型与架构建议

6.1 编排层与执行层的分离

建议采用两层架构：

编排层：使用 Claude Opus 或 Gemini Pro 等顶级强模型，负责理解需求、生成 Spec 和决策。
执行层：使用 Sonnet 或 Kimi 等编码优化模型，负责具体的读写代码和 Shell 命令执行。
这种分层架构能同时兼顾逻辑深度与响应速度，并有效控制 Token 成本。