AI Coding 的设计模式：从诊断到处方

上一篇文章讲了 AI Coding 的七类坏味道——它们是企业在落地过程中最常踩的坑。但光有诊断不够，还得有处方。

这篇文章讲的是 AI Coding 设计模式（Design Patterns for AI Coding）。它们不是"AI 怎么写代码"的技巧，而是"企业怎么搭建 AI Coding 体系"的架构决策。

一、意图层：让 AI 真正理解你要什么

坏味道的核心症状是"Spec 做戏"和"字段漂移"——文档有，但 AI 不按它执行。意图层的五个模式解决的就是这个问题。

Spec-First 提交（PAT-01）：每一次代码合入，必须在 PR 描述中 @ 引用对应的 Spec 条目。这不是形式主义——它强制建立了"需求→代码"的双向链接，断开了"随口说、随手写、事后补文档"的惯性。

字段对齐（PAT-02）：在 Spec → Prompt → 验收标准 → 测试用例 → 代码这五个环节中，对同一个概念使用同一个字段名。用 CI 扫描来强制检查，而不是靠人盯着。

模板门禁（PAT-03）：Spec 不是自由格式的散文。必须遵循结构化模板（14 类模板择一），pre-commit 检查不合格就驳回。这不是限制创造力，而是保证 AI 能解析。

Prompt 契约（PAT-04）：Prompt 不是"写在聊天框里的文字"，而是一个结构化契约——包含输入、输出、约束条件、拒绝条件。用 DSL 定义，用 Lint 检查。

Spec 版本化（PAT-05）：Spec 不是"写一次就完了"。每一次变更都要语义化版本号，AI 只能读取已发布的版本。你永远知道 AI 是基于哪一版 Spec 做的实现。

这五个模式的共同逻辑：意图不能被"传话"，必须被"锁定"。

二、上下文层：管理 AI 的"知识边界"

坏味道的诊断是"上下文腐蚀"和"知识孤岛"。上下文层的五个模式，把 AI 的知识管理从"个人手艺"升级为"团队工程"。

分层 AGENTS（PAT-06）：AGENTS.md 不要写成一个巨型文件。分四层——组织级（全公司通用的编码规范）、项目级（本仓库的架构约束）、模块级（当前模块的领域知识）、任务级（本次任务的特殊要求）。层级越低越具体，高层设定边界。

RAG 切片（PAT-07）：知识库不是"把文档喂进去就行"。要做语义分块，加元数据标签，设相关性阈值。不加治理的 RAG 会引入噪声，反而降低 AI 输出质量。

会话锚定（PAT-08）：在长会话中，把关键 Spec、核心约束固定在系统消息池中，确保它们不会被上下文窗口的滚动挤出。

决策账本（PAT-09）：每一次 AI 参与的关键决策——为什么选这个方案、为什么拒绝那个方案——都要记录在 AIDR（AI Decision Record）中。格式和 ADR 同源，但专门标记 AI 参与的部分。

知识版本化（PAT-10）：知识库也像代码一样打版本。AI 在引用时带版本号，审计时可以回溯"这个回答是基于哪个版本的知识生成的"。

这五个模式的共同逻辑：上下文不是越多越好，而是要分层、可信、可追溯。

三、控制层：给 Agent 装上方向盘和刹车

坏味道的诊断是"Agent 越权"和"无审查闭环"。控制层的六个模式，解决的是编排和权限问题。

工具白名单（PAT-11）：Agent 可调用的工具不是越多越好。按场景按需授予——写代码时可以调 Git，但禁生产部署；做数据分析时可以读数据库，但禁写操作。场景化的工具集远优于全局通票。

沙箱门禁（PAT-12）：所有敏感操作（生产部署、配置变更、数据迁移）先跑在沙箱里，生成变更计划，人类审批后再执行。人必须在回路中。

任务拆分（PAT-13）：大需求拆成独立可验证的小任务。每个任务有独立的检查点，上一个检查点不过，不进下一个。拆得越细，每一步越可验证，积累的风险越低。

检查点循环（PAT-14）：每一步都有一个人机交汇的验证点。它不是"AI 做完了人再看"，而是"AI 做一步，人确认一步，AI 再做下一步"。损失在第一个检查点就被截断。

成本预算（PAT-15）：给每次 Agent 调用设 Token 和时间上限。不是限制创造力，而是防止 Agent 在一个已经走偏的方向上无限消耗资源。

CLI 产品化（PAT-16）：Agent 的能力从 IDE 插件搬到 CLI 中执行。好处是：可审计（每一条指令都有日志）、可复现（同样的参数同样的结果）、可集成（CI/CD 中直接调用）。

这六个模式的共同逻辑：Agent 的能力越大，护栏就要越明确。

四、评审层：用 AI 审查 AI

坏味道的诊断是"假绿测试"和"审查疲劳"。评审层的五个模式，建立了一条专门针对 AI 输出特征的质量防线。

AI 审查链（PAT-17）：不是让一个人去看 AI 的代码，而是让一个 AI 先扫描坏味道，另一个 AI 做安全审查，最后再由人做终审。串联的自动化守门人比单个 Code Reviewer 的精力可靠得多。

坏味道扫描器（PAT-18）：把前文总结的七类坏味道做成 pre-commit 扫描规则。代码合入之前自动跑，发现特征模式就打回。人不该做机器擅长的事。

变更叙事器（PAT-19）：AI 生成的 PR 描述不再是"fix bug"或"update code"。自动生成自然语言解释——改了什么、为什么改、影响了哪些模块、有哪些风险点。Reviewer 不用猜。

回滚演练（PAT-20）：每月至少做一次有意的回滚演练，验证回滚路径是否通畅。AI 生成代码的回滚风险比人工代码高——因为改动的逻辑链路更不透明。

基线仪表盘（PAT-21）：DORA 指标（效率）+ SPACE 指标（体验）+ AI 采纳率（覆盖度），三层基线同时监控。哪个数字异常，就回查哪个维度。

这五个模式的共同逻辑：质量不是"审出来的"，而是"设计出来的"——把检查点嵌入流程，让质量问题在合入之前就被拦截。

总览：编排逻辑

四层模式之间不是并列关系，而是一条流水线：

意图层（锁定目标）    ↓上下文层（管理知识边界）    ↓控制层（给 Agent 装上护栏）    ↓评审层（自动化的质量防线）

• 意图层和上下文层是"输入质量"——源头干净，后续才可能有好的产出
• 控制层是"过程质量"——编排得当，每一步都可检查、可回滚
• 评审层是"输出质量"——用 AI 的能力去检查 AI 的弱点

记住三件事

第一，模式不是 Checklist，是架构决策。21 个模式不需要一次性全上。根据你的坏味道诊断结果，先解决最疼的那一两个维度，滚动推进。

第二，模式之间有依赖关系。意图层没做好（Spec 不结构化），上下文层的 RAG 切片效果就大打折扣。质量防线再强，源头是乱的，产出不可能干净。

第三，这套模式解决的不是"怎么写代码"，而是"怎么建体系"。AI Coding 的终极挑战不是技术问题，而是治理问题——如何让一群人和一群 AI，在可管理的复杂度下，持续产出可信任的软件。