使用 AI Coding Agent 半年后，我最重要的调整是：不再把“告诉 Agent 应该怎么做”当作质量保证。行为规则只能降低出错概率，结果仍需独立验证。
早期我不断增加 Prompt 与项目规则，希望 Agent 先读代码、控制改动范围并主动测试。规则确实有用，但任务复杂后仍会出现遗漏调用方、误解边界和只验证正常路径的问题。
现在的工作流分成两层：行为约束负责减少问题发生，验证流水线负责发现已经发生的问题。
第一层：让 Agent 更少偏离
我保留三类约束，但不再把所有经验堆进一份全局说明。
| 层级 | 放什么 | 作用 |
|---|---|---|
| 全局规则 | 安全边界、Git 规则、读优先于写 | 所有任务都必须遵守 |
| 项目规则 | 架构、目录、测试和部署约定 | 让改动符合当前仓库 |
| 任务计划 | 目标、范围、验收和明确不做 | 限制本次执行边界 |
这三层解决的是“Agent 接下来倾向于怎么做”。它们不能证明改动已经正确。
规则也不是越多越好。稳定且普遍适用的内容才进入全局；项目特有约束放在仓库；只对某类任务有用的方法按需加载。这样可以避免上下文被大量低命中率指令占用。
第二层：独立验证结果
我把验证分成四个阶段：
| 阶段 | 主要问题 |
|---|---|
| 代码审查 | 实现是否符合需求、架构和调用边界 |
| 本地验证 | 格式、类型、单元测试和冒烟是否通过 |
| 边界测试 | 失败路径、并发、重试和兼容性是否被覆盖 |
| 真实环境 | 配置、依赖和外部系统是否按预期工作 |
关键点是：验证依据来自代码和运行结果，而不是 Agent 对自己工作的描述。
例如，Agent 说“已经兼容旧客户端”没有证明力。需要检查旧请求如何反序列化、新字段是否透传、默认值是否改变行为，再用真实请求验证。
同样，本地测试通过也不代表集群正确。环境变量、权限、网络和外部服务只有在目标环境中才能验证。高风险任务必须把“本地正确”和“环境正确”分开。
第三层：把方法按需加载
当某套验证流程反复使用后，我会把它整理成 Skill，而不是继续扩大全局规则。
例如 staged-verify 保存四阶段验证流程；代码审查、CI/CD 检查和跨团队联调分别使用独立 Skill。只有触发对应任务时才加载完整步骤。
判断一条经验放在哪里，我使用两个问题：
- 是否每个任务都必须遵守？如果是，进入全局规则。
- 是否只在特定场景有价值？如果是，进入 Skill。
这让约束保持简短，也让复杂流程能够被完整复用。
实践结果与适用边界
这套方法没有让 Agent 不再出错，但改变了问题出现后的处理方式：
- 需求误解更早在计划阶段暴露；
- 调用方遗漏更容易在代码审查中发现；
- 正常路径之外的失败由边界测试主动覆盖；
- 本地与集群差异有独立验证阶段；
- 有效经验能够沉淀，而不是只留在一次会话中。
我对 AI Coding 的预期也因此发生了变化：
Agent 负责提高实现速度，工程流程负责限制错误影响。不能把后者交给 Agent 的自我约束。
实践边界：什么时候不需要完整四阶段
文案、注释和局部样式修改通常只需要静态检查与页面预览；没有外部副作用的简单函数也不必部署到集群验证。
验证强度应由风险决定。涉及共享状态、并发、权限、兼容性和外部系统时，才需要完整阶段。流程的目标是提供足够证据，不是让所有改动承担同样成本。