当 AI 会写代码之后，我们应该怎么“管”它？

当 AI 会写代码之后，我们应该怎么"管"它？

本文相关的工程实践与示例仓库（GitHub）：
github.com/cynthiaCh/a...

引言：AI 编程已经来了，但它有点难管

最近大家都在讨论 AI 编程工具，比如：

• Cursor
• Windsurf
• Codex
• Copilot
• Aider

这些工具都能写代码、有时还能修 bug、甚至能自己做任务规划。

但一个现实的问题是：

AI 有能力写代码，却没有"工程纪律"。

它会：

• 重构过头
• 引入不必要依赖
• 风格不一致
• 忽略业务语义
• 没办法告诉你"为什么这么改"

这意味着：

用 AI 编程，如果没有治理，它可能比人还要乱。

---

传统思路的问题：把规范写给人看

在没有 AI 的时候，工程规范是这样定义的：

• README.md
• CONTRIBUTING.md
• 代码风格规范（eslint/prettier）
• API 约定
• 文档/Wiki

这些规范是写给 人 看的。

人能理解抽象、能权衡妥协、能在审查时判断。

🎯 但 AI 却不是。

AI 需要明确、机械、可执行的指令。

这就引出了一个关键问题：

规范到底应该写给谁？
人？还是 AI？

---

当 AI 是"执行者"而不是"合作者"

大多数 AI 编程工具的核心模式是：

• 模型 + prompt → 输出代码
• 如果结合 IDE，还能读代码、写代码、甚至运行

这些工具非常强，但他们骨子里仍然存在两个问题：

1. Prompt 是一次性的，不可审计
2. 工具私有规则无法迁移到其他工具

比如 Cursor 有 500 多行 Agent Prompt，

用来告诉 AI：

• 怎么解释角色
• 怎么理解工具
• 怎么执行任务
• 怎么不犯错

但这些都是"临时提示词"，无法作为工程资产沉淀。

我的理解：AI 不该被"Prompt 驱动"，而该被"规范驱动"

基于这个思考，我做了一个开源项目：

👉 agent-engineering-playbook
github.com/cynthiaCh/a...

它不是"AI 能做什么"的说明书，

而是一个工程层面的 AI 编程治理手册。

你可以把它看成：

当 AI 会写代码之后，我们应该怎么约束它、管控它、让它在工程里稳定运行？

类似概念包括：

• Engineering Governance
• Agent Boundary Design
• AI 执行边界

核心理念：把规范写成工程资产，而不是 prompt

我们提出了几个工程治理核心原则：

✅ 1. AGENTS.md 是工程资产，不是 prompt

它是一个显性的、可版本化、可审计的规范文件。

AI 不再靠 prompt 的语义推断：

• "你必须先读取文件"
• "看到这个目录结构才回答"
• "代码要满足这些品质要求"

而是有一套真实、稳定、工程化的规则。

✅ 2. 规范不仅写要做什么，还要写不该做什么

一个真正的工程规范不是：

"请 AI 写好代码。"

而是：

"如果 AI 想写代码，要同时满足这些约束条件。"

例如：

MUST NOT introduce new dependencies unless explicitly requested.
MUST follow existing patterns first.
MUST preserve semantic meaning in code changes.

这些都是约束条件，而不是简单的任务描述。

✅ 3. Semantic Mapping（语义映射）

AI 最难搞清楚的一件事是：

业务语言应该映射到哪个工程层？

比如：

• "红色 = 风险点"
• "蓝色不够明显"
• "流程太长，需要压缩"

这些看起来是"业务话"，

真正工程化的响应是：

• 不要在页面硬编码颜色
• 修改语义映射层（semantic token / color mapping）
• 修改 workflow 的配置，而不是随便删代码逻辑

Semantic Mapping 是一种工程抽象层，

它是让 AI 区分业务意图与工程实现的重要手段。

✅ 4. Definition of Done（验收标准）

一个任务如果没有清晰的完成标准 ，

AI 很难评判"什么时候真正做好了"。

在 Playbook 中，我们要求：

• ❯ 所有变更必须通过相应测试 / build
• ❯ UI 行为必须一致（loading / empty / error）
• ❯ 不引入未授权的依赖
• ❯ 列出修改清单 + 验证步骤
• ❯ 提供潜在风险提示

这能把"工程完成判断"从模糊变得可执行。

和现有 AI 工具比起来有什么不同？

维度	Cursor / Windsurf Prompt	AGENTS.md Playbook
适用对象	某个具体工具	跨工具
绑定性	强	松
可审计性	低	高
可复用性	低	高
组织共享	难	容易
版本控制	不友好	友好

你会发现：

• Prompt 是执行层面的约束
• Playbook 是架构层面的治理

这不是更难、更复杂，

而是更稳、更工程化、可持续。

实践建议：怎么用这套 Playbook

📌 1. 把 Playbook 放入仓库

• AGENTS.md
• patterns/
• tools/

推荐只本地，不提交版本控制（或同步到主仓）。

📌 2. 在团队内部 workshop

组织一场小范围 workshop：

"当你让 AI 写代码时，它应该遵循什么规则？"

用 Playbook 做讨论模板。

📌 3. 持续迭代

随着 AI 工具演进，你的 Playbook 也应更新。

结语：AI 编程是工具，但工程治理是技能

AI 写代码只是第一步，

真正挑战不是它能写什么，而是：

它写的东西，是我们可以长期维护的吗？

这才是跨越工具、跨越模型的真正工程问题。

你可以从这个开源项目开始：

👉 github.com/cynthiaCh/a...

期待你也加入这个正在酝酿的工程实践圈子 💡

如果你对 AI 编程治理、高可靠性 AI 工程感兴趣，欢迎在评论区留下你的观点，我们一起把这件事做好。