请开始，将AI视为你的第一读者

那段 legacy code，至今让我记忆犹新。
所有函数都堆在一个文件里，几百行逻辑从头滚到尾，嵌套的 if/else 一层又一层，变量名要么是 a、b，要么是 data1、data2。注释更是稀少，有的甚至写了也等于没写，比如“// 这里处理逻辑”。处理什么逻辑？连写的人恐怕都忘了。

我第一次试着用 Copilot 帮我写单元测试。结果生成的测试看上去很有模有样，缩进整齐，断言写得规规矩矩，可一运行就完全不对路：它居然把登录和注销放到同一个测试里，还拿错了输入参数。有的测试干脆报错在无关的函数上，像是强行拼凑出来的。

看着这些“理直气壮”的测试用例，我一度怀疑：是不是 AI 还不够聪明？是不是它只会写模板代码，真正复杂的逻辑还得人来写？

可几周之后，当我把这份代码重构完，情况却发生了翻天覆地的变化。

大函数被拆成小函数，文件划分更合理，关键逻辑补上了注释。再试一次，Copilot 给出的测试突然条理清晰，甚至还自动补上了几个我一开始没想到的边界情况。比如它会写“空输入”或“异常路径”的校验，这些往往是手工写单测时容易忽略的地方。

那一刻，我才真正意识到：AI 并不是蠢，而是它读不懂。

那个无法追问的隐形同事

在传统的软件开发里，我们写文档、写代码，心里想的都是未来的同事：
“要让新人能看懂”，“要让别人能快速上手”。

可是现在，项目里悄悄多了一个新的角色：AI agent。

它可能是写单测的 Copilot，也可能是做代码审查的 ChatGPT，甚至是帮你总结会议纪要的自动助手。
它已经在项目的不同角落出现，但大多数时候，它都不被算作“读者”。

问题在于：如果我们不把 AI 视为读者，它就只能按字面意思去理解——结果自然经常跑偏。

人类同事面对烂代码，还能停下来皱眉头，跑来问一句：“这里是不是少了个异常处理？”
AI 却不会。它不会怀疑，不会追问，不会停顿。它像一个安静坐在角落里的实习生，只会点头，然后按照你给它的上下文死板地产出。

很多人以为 AI 是“更聪明的工具”，但我的经验是：它更像一个无法追问的隐形同事。
区别只在于，这个同事没有情境推理能力，完全依赖你写下的每一个字。

问题不在AI，而在Garbage in

很多人吐槽 AI：“写出来的代码完全不能用”“生成的需求分析驴唇不对马嘴”。
但如果你仔细回头看输入，会发现问题往往不是它，而是我们自己。

AI 遵循一个最简单却最残酷的规律：garbage in，garbage out。

需求模糊，它就只能生成模糊的方案；
代码像一团乱麻，它就只能乱猜依赖；
文档没有上下文，它就只能拼凑出看似合理的废话。

人类读者会凭经验和直觉帮我们补全。产品经理写三段故事，开发还能靠脑补画出接口逻辑；代码里少写了个异常，老同事也能凭感觉加上 try-catch。
但 AI 不会。你给它什么，它就吐出什么，完全零容忍。

我自己试过：当我丢给 ChatGPT 一个模糊的问题时，它会一本正经地胡说八道，甚至还会虚构一些看似权威的解释。但当我把上下文写清楚，把边界条件标出来，它就能立刻生成让我惊讶的准确答案。

所以，把 AI 当成第一读者的第一步，就是承认它的脆弱性：输入不干净，输出就一定跑偏。

与AI沟通：四项核心原则

这些年和 AI 一起踩过坑，我慢慢摸索出几个最有用的做法。

1. 代码要有可解析性。
那次重构让我彻底明白：当大函数被拆开，边界清晰，变量命名有意义时，AI 才能真正理解上下文。
它甚至能自动生成一些我没写过的边界测试，这让我意识到：可解析性，正在成为代码质量的新维度。不仅仅是可读、可测，还要“可被机器理解”。

2. 文档要尽量结构化。
人类读者能忍受冗长的叙事，AI 却只能照本宣科。
我试过把需求写成三段描述，AI 输出的总结完全走偏。后来我换成一张表格，列清楚输入、输出和边界，结果它生成的接口定义完全符合预期。
AI 难以理解故事，但擅长解析契约：表格、字段、示例。

3. 注释里写为什么。
“做了什么”AI 能从代码里看出来，但“为什么这么做”它根本读不出。
比如：// 用 BFS 而不是 DFS，因为要保证最短路径。
这一句注释，相当于给它注入了业务上下文和设计意图，让它在重构时保持方向，而不是随意替换算法。

4. 会议纪要要明确结论。
人类能从上下文推断出行动项，AI 却需要你显式标注。
我就遇到过一次，AI 把某个同事开玩笑说的“那不如砍掉这个功能算了”当成了结论，写进了纪要里。后来我专门加上 Action Item:、Decision: 这样的标签，它才不再跑偏。

这些方法原本是“写给人看的好习惯”，但当 AI 成为第一读者后，它们的价值被成倍放大。

你的新角色：从生产者到评审者

和 AI 合作多了，我明显感到角色在变化。
过去我是主要的生产者，写代码、写文档、写注释；现在，很多草稿可以先让 AI 生成，我更多时候在做 reviewer。

一开始，这种转变让我暗暗庆幸：终于可以少干点机械活了。
可没过多久，我发现这种轻松感背后藏着风险。
AI 的输出往往格式规整、逻辑自洽，看上去挺靠谱，但仔细一查，里面可能有漏洞，甚至基于完全错误的假设。

那一刻我意识到：如果我只是轻轻一扫，失去了自己的判断力，就会被它带偏。

AI 可以是同事，可以是第一读者，但它永远不能替你拍板。
业务取舍、架构边界、何时重构，这些决定依旧需要人来做。
AI 的边界感，是建立在人类专业洞察之上的。

未来的工程师，必须学会对AI说人话

几十年来，我们在工程实践里不断学习“跨职能沟通”：
和产品沟通，和设计沟通，和市场沟通。

未来，这份清单要再加上一项：和 AI agent 沟通。

它可能不会成为你的老板，也不是你的下属。
但它已经是你的无声同事。
它会读你的代码、读你的注释、读你的文档，却从不追问、不澄清。

也许有一天，AI 写给 AI 的代码会比人类写得还多。那时我们要做的，不是比它写得更快，而是定义好规则和契约。今天我们练习“对 AI 说人话”，其实就是在练习如何对未来的世界留下清晰的约束。

所以，当你写下一行注释时，请想一想：
这不仅是写给未来的某个新人看的，也是写给无数个在后台默默运行的 AI agent。