走出工具困境：规范驱动的AI编程工程化实践

一、困境：人人都在用 AI，团队却没有变强

过去一年多，智能编程助手几乎成为开发者的标配。团队在早期尝试中普遍收获了不错的“第一印象”：

• 短上下文场景表现良好：写一个独立函数、实现一个工具方法，AI 的产出往往超出预期；
• 碎片化提效明显：代码补全、格式化、注释生成、单元测试草稿，这些低风险、高重复的工作确实被加速了。

但当尝试从“个人提效”走向“团队规模化复用”时，问题集中爆发：

1. 生成代码质量参差不齐：同样的需求，不同人提问，得到的结果天差地别；
2. 需求理解偏离预期：模型自作主张地“脑补”，实现与设计意图南辕北辙；
3. 上下文丢失严重：跨会话、跨任务几乎没有记忆，每次都要从头解释背景；
4. 改一处坏十处：局部修改缺乏全局视角，维护成本不降反升。

更麻烦的是组织层面的问题：团队当时只有寥寥几种触发类型的规则配置；“在基础智能体之上封装专用智能体”的想法被提出过，但几个月过去，真正动手实践的人屈指可数。事后归因，存在三个缺口：

• 规范没有形成共识：每个人对“怎么用好 AI”的理解都不一样；
• 对 AI 工程化缺乏标准认知：不知道该往哪个方向努力、做到什么程度算好；
• 提示词复用习惯没有建立：好的 prompt 停留在个人经验里，没有沉淀为团队资产。

带着“有没有成熟的 AI 编程工程化方法论”这个问题，我把目光转向行业层面的实践总结，其中影响最深远的，是规范驱动开发（Spec-Driven Development，SDD）思潮。

二、方法论骨架：规范驱动开发

SDD 的吸引力在于它直击前述痛点的根源——开发过程缺乏单一事实来源。它有三条核心理念：

1. 规范即代码：规范不是写完就归档的文档，而是可以直接驱动实现的“第一公民”；
2. 权力倒置：代码服务于规范，而非规范服务于代码。当两者冲突时，先修哪一个有了明确答案；
3. 测试优先：不可协商地先写测试，让“验收标准”成为规范的组成部分。

在流程上，SDD 通常被归纳为五个阶段，每个阶段对应一次明确的产出：

Constitution ──▶ Specify ──▶ Plan ──▶ Tasks ──▶ Implement
   （宪章）        （规范）     （计划）    （任务）    （实施）

• 宪章：定义项目级的开发原则与不可妥协的约束，例如技术栈边界、代码风格底线、安全红线；
• 规范：把需求转写为结构化、可验证的规格说明，明确输入输出、边界条件与验收标准；
• 计划：基于规范产出技术实现方案，包括模块划分、依赖关系与风险点；
• 任务：拆解为可执行、可独立验收的任务清单；
• 实施：按任务逐项执行，全程以测试守护。

一个规范片段大致长这样：

# 功能规范：订单金额计算
## 输入输出
- 输入：单价（分）、数量、优惠券规则 ID
- 输出：应付金额（分），禁止浮点运算
## 约束
- 金额一律使用整数分计算
- 优惠叠加顺序以配置表为准，禁止硬编码
## 验收标准
- 覆盖边界用例：0 件、负数、优惠超上限
- 单元测试先行，覆盖率不低于既定阈值

三、二次踩坑：方法对了，为什么还是用不好

带着 SDD 的理念实践约三个月后，我一度选择了放弃。复盘下来，问题不在方法论本身，而在于我们把它当成了又一个“工具”：

1. 五阶段被简化为“五次点击”：宪章写完就没人维护，规范与实际代码成为两张皮，流程沦为形式；
2. 上下文管理缺位：规范文档确实写了，但模型执行任务时根本“看不到”它，规范与上下文是割裂的；
3. 缺少组织配套：没有评审机制、没有度量指标、没有资产沉淀，方法论的执行质量完全依赖个人自觉。

这段弯路带来的认知冲击是关键的：工具与方法论的强弱决定下限，团队能否把它们工程化地组织起来才决定上限。

四、认知重建：三个关键转变

4.1 从“提示词技巧”到“上下文工程”

真正决定模型产出质量的，不是某句“咒语”，而是模型能看到什么。上下文工程把提示词从“技巧”升级为“系统设计”：

• 分层组织：长期原则（宪章级）→ 项目规范 → 任务级上下文，各层职责清晰；
• 按需注入：执行任务时只装载与该任务相关的规范切片，避免无关信息稀释模型注意力；
• 预算意识：上下文是稀缺资源，要把最关键的信息放在最有效的位置。

4.2 从“单点对话”到“多智能体协作”

借鉴业界公开的多智能体协作范式，可以把复杂任务的组织方式重构为角色分工：

主 Agent（规划与汇总）
 ├─ 子 Agent A：实现模块 1（独立上下文）
 ├─ 子 Agent B：实现模块 2（独立上下文）
 └─ 评审 Agent：对照规范逐条检查产出

其价值在于：上下文隔离让每个子任务只承载必要的最小信息；角色分离让“实现”与“审查”互不迁就，显著降低“改一处坏十处”的概率。

4.3 从“个人经验”到“复合工程”

复合工程的核心，是让每一次任务的产出成为下一次任务的输入，形成知识复利：

• 规范模板化：新需求基于模板起草，而不是从零开始；
• 失败案例入库：返工原因、踩坑记录反哺宪章与规范的修订；
• 度量反馈闭环：用数据判断规范是否真的在起作用，而非凭感觉调整。

五、落地路线图：从个人技巧到团队体系

结合上述认知，团队可以按三步构建自己的 AI 编程工程体系：

1. 统一语言（1~2 周）：梳理术语表与规范模板，让“规范”这个词在团队内有唯一含义；
2. 建立宪章与评审（约 1 个月）：宪章明确不可妥协项；每个任务交付前，由人或评审智能体对照规范逐条检查；
3. 持续沉淀（长期）：维护提示词与规范资产库，跟踪一次通过率、返工率、规范覆盖率、资产复用率等指标，按迭代复盘。

值得强调的是，这套体系与具体使用哪一家的智能编程助手无关——无论底座模型与工具如何更换，规范、上下文、协作、沉淀这四件事都是可迁移、可复利的团队资产。

六、结语

回到最初的困境：“AI 工具明明很强，但就是用不好。”答案现在已经清晰：工具解决的是单点效率，工程体系解决的才是规模化复用。当规范成为共识、上下文被系统化管理、协作被角色化拆分、经验被持续沉淀，AI 编程才会从“少数人的技巧”变成“整个团队的能力”，边际成本递减、知识持续复利才会真正发生。