第 01 章 | 为什么需要"AI + 规约 + 多角色"

第 1 章：为什么需要"AI + 规约 + 多角色"

学习目标

读完这一章，你能用三句话向同事讲清楚为什么不该让 Claude Code 一把梭写完整个项目。

三个真实痛点

如果你只用过原始的 AI 编程（开个对话框、让 Claude 直接写代码、拷贝、提交），大概率撞到过这三件事：

痛点 1：需求只活在聊天里

你今天跟 Claude 说："这个功能是给登录用户用的"
明天 /clear 后再跟它说："改一下登录逻辑"
→ 它不记得"必须支持登录用户"这个约束
→ 你又要重新解释一遍
→ 三个月后没人记得当初为什么这么设计

痛点 2：单 agent 既写又测又审

你让 Claude："写代码 + 写测试"
它写了一段代码 → 配套写一份"刚好让自己代码通过的测试"
测试 100% 通过，但其实测了个寂寞
你看不出来，因为它产出看起来很专业

痛点 3：权限放任

你按了一次"Always Allow Bash"
Claude 后来跑了 rm -rf node_modules
结果它解析路径时把 ~/Documents 也算进去了
你的简历视频集没了

三个对应解法

flowchart LR
    P1["痛点 1
需求活在聊天里"] --> S1["规约层
OpenSpec"]
    P2["痛点 2
单 agent 自证"] --> S2["治理层
多角色 + 制衡"]
    P3["痛点 3
权限放任"] --> S3["安全层
permission + hook"]

    S1 --> R["可对齐
可审计
可演进"]
    S2 --> R
    S3 --> R

不是"工程过度"

你可能想："这看起来比直接让 Claude 写代码复杂多了，值得吗？"

判断标准很简单：

"半年后接手这个项目的人，能知道它现在到底承诺了什么吗？"

• 答案是肯定 → 你需要这套
• 答案是否定 → 至少需要其中一部分

我们这个教程对应的项目 doc2video，就是个真实的中型项目：61 个开发任务、13 个组、4 个角色 agent。手工管这种规模的细节，记忆力会先崩溃。

你现在能做什么

• 能跟同事讲清楚 AI 编程的三个痛点
• 能判断自己的项目"该不该上规约 + 多角色"

下一章我们看具体要做的项目长什么样。