一、引子

你有没有这样的经历？

你和 AI 配合写代码：你描述需求，它出代码，你测试，它改 bug。一上午下来，活儿干完了。你很有成就感。

然后第二天，你想加个新功能。打开昨天生成的那个文件——你懵了。所有逻辑揉在一起，没有注释，没有分层，你不知道从哪下手。你只好重新描述一遍给 AI，让它把整个文件 rewrite 一遍。

这不是 AI 的问题。这是你和 AI 之间缺少一个契约——一个关于"我们写的东西该怎么组织"的共识。

二、三位一体——一个在实践中长出来的答案

我一开始也没有这个共识。直到有一次，我让 AI 写一个脚本，它把设计背景、执行逻辑、参数说明全揉在一个文件里。

能跑。但不敢改。

跑完了，但不知道下次参数变了该改哪。

我在改那个脚本的时候，心里想的是：如果这个脚本将来要交给别人维护——或者交给我自己三个月后的自己维护——它应该长成什么样？

答案是三个东西，而不是一个：

  • 一个文档，告诉我"为什么当初这么设计"——这不是 AI 该记的东西，这是人该记的
  • 一份指南，告诉 AI “流程怎么走、碰到异常怎么办”——这不是脚本该写的，是 AI 启动任务前该读的
  • 一个脚本，老老实实干活——不要夹带设计笔记，不要写"当时为什么选这个方案"

这就是三位一体。不是理论推导出来的，是从不敢改自己代码这个教训里长出来的。

三、三层不分的后果

说说我踩过的一个坑。

有一段时间，我把脚本当作"万能盒子"。需求分析写在前几行注释里，执行参数写在中间，调试日志写在最后。AI 写的时候很顺手，但每次修改，我都要从头读一遍才能找到要改的那几行。

最痛的一次：改一个参数，结果发现同一个参数在脚本里被引用了三次，每次的默认值都不一样。因为 AI 在不同轮次对话中分批加功能，没有统一的入口。

后来我才意识到——不是 AI 写不好代码，是我没有告诉 AI"代码应该怎么分"。 三层分离的本质，不是在技术上加一层架构，而是在人和 AI 之间画三条线：这条线以内是 AI 的活，那条线以外是人来判。

四、这个思维给我带来了什么

三位一体带给我的不是"代码变干净了"——这个当然有——而是两件更大的事：

第一，我敢改了。 打开一个脚本，我知道设计决策该去哪找，执行逻辑在哪个范围，参数从哪进。不再需要先花十分钟理解整个文件才敢动一行代码。

第二，我可以信任 AI 的输出了。 因为有了契约，AI 产出的东西是可预期的——文档、指南、脚本各归其位。我不需要每条产出都全量审查，只需要检查关键节点的判断。

曾鸣教授说过：战略不是规划出来的，是长出来的。

三位一体契约也是。它不是一开始设计好的，是从具体问题里长出来的答案。每次踩坑，都让这个契约变得更清晰。

五、启示

我一直觉得，人和 AI 的最高效协作模式，不是互相替代，而是各有分工。

AI 擅长的是：快速执行、批量产出、不知疲倦地试错。

人擅长的是：判断方向、制定边界、做那个"这个参数是对的"的决定。

三位一体契约就是在人和 AI 之间画出了一组清晰的边界线。不是技术规范，是协作规则。

而且这个规则不只对写代码有用。任何需要持续维护、可能会交接给别人的产出，都值得在开始之前，先想清楚：这是给谁看的，该写成什么样。