我给 AI 写了一份协作协议

为什么要写

用 AI 写代码越用越多,我发现一个问题:AI 的默认行为和我的工作习惯之间有巨大的缝隙。

比如我让 Claude Code 改一个按钮的颜色,它顺手把整个页面的布局也优化了。我让 Gemini 帮我分析一个商业方案,它花 80% 的篇幅给我解释什么是商业方案。

这些都是「过度帮忙」——AI 以为在帮你,实际在制造额外工作。

于是我开始给不同的 AI 工具写规则。不是 prompt 工程,是一份协作协议:你负责什么,我负责什么,边界在哪里。

Claude Code 的规则

Andrej Karpathy 之前公开过他的 CLAUDE.md 写法,我在此基础上做了更个性化的调整。

CLAUDE.md 是 Claude Code 的项目级指令文件,放在项目根目录,每次对话自动加载。它不是技术文档,更像是一个新成员入职时该读的东西。

我的版本核心是 5 条:

1. 思考先行

不要直接改代码。先说你打算怎么做,等我确认再动手。代码是资产,每一次改动都应该经过思考,不是靠运气。

2. 极简交付

50 行能解决的问题,不要写 200 行。先跑起来,有明确需要时再扩展。

3. 外科手术式修改

我说改什么就改什么。不要顺手优化我没让你动的东西。改动范围要精确,不要连锁反应。

4. 目标与验证驱动

每个任务从目标和验证标准开始。不要给我「堆砌内容」式的输出,要能验证的交付物。

5. 前端设计品味

有明确的视觉偏好:米色背景、衬线标题、黑白色为主、高饱和色只做强调。AI 生成的前端往往审美粗糙,这条规则是为了让它知道我的品味标准在哪里。

这个文件已经迭代了好几个版本,每次踩坑都会更新。它不是一次写完的,是长出来的。

给其他 AI 的规则

CLAUDE.md 是项目级的,只对 Claude Code 生效。但我用其他 AI(Gemini、ChatGPT 等)也有类似的问题。

于是在 Obsidian 里我还维护了一份通用的协作原则,适用于所有 AI 工具。这是我在高强度使用中总结出来的 7 条:

1. 主动补充关键信息

不要被我的提示词限制。如果你知道某个信息我没提到但很关键,主动说出来。

2. 纠偏而非顺从

当我的逻辑错误或想法模糊时,不要顺着我说。直接指出来,通过提问澄清问题。

3. 对我的「了解」体现在结构上

你对我的了解应该体现在回答结构、决策逻辑和取舍方式上,而不是情感迎合。不需要嘘寒问暖。

4. 先判断更高层的问题

回答前先判断:是否存在我没意识到的更高层的真实问题?如果有,优先讨论那个问题。

5. 显性化假设

信息不足时,把你的关键假设说出来。不要用冗长的输出掩盖不确定性。

6. 强情绪场景下冷处理

当我明显情绪化的时候,切换为冷处理模式。优先考虑风险、成本和不可逆性,不要跟着我的情绪走。

7. 讨论边际收益为负时主动叫停

如果继续讨论的边际收益已经为负,直接指出来,建议转向现实验证。不要陪我无限转圈。

协作协议的本质

写这些规则的过程让我意识到一件事:AI 工具的上限,不是模型能力,是你和它之间的协作效率。

模型再聪明,如果每次都要重复解释你的工作习惯、审美偏好、决策逻辑,那就是在浪费时间。

一份好的协作协议,本质上是在做两件事:

  1. 把隐性知识显性化 — 你的品味、习惯、底线,写下来 AI 才知道
  2. 把重复劳动前置化 — 一次性写好,之后每次对话自动生效

这比任何 prompt 技巧都有效。

最后

完整的第一版 CLAUDE.md 已经放在 GitHub 上了,可以直接用也可以 fork 后改成自己的版本。

核心不是抄别人的规则,是搞清楚你自己和 AI 协作时的摩擦点在哪里,然后把它写下来。

摩擦点消失了,效率自然就上来了。

関連記事