AI 写代码最快翻车的地方，是它没看见的边界
约 3 分钟1 阅读
我有一次让 AI 改个函数，改得很顺。
那是个工具函数，逻辑清楚，AI 改完我扫了一眼，没问题，提了上线。当天晚上报警——另一个模块挂了。
排查下来，那个被改的函数有个隐性约束：它的某个返回值，被另一个模块当「成功标识」用着。我让 AI 改的时候，把那个返回值的语义悄悄变了，对被改函数本身没影响，但下游那个模块的判断逻辑就失效了。
AI 改的代码完全正确。问题在于，它「看见」的只是这个函数，「看不见」的是这个函数对外承诺的契约。
看得见的代码，看不见的边界
这是 AI 写代码最容易翻车的地方，也是最难防的地方。
AI 擅长处理它上下文里有的东西——你给它一个函数，它能把这函数改对；你给它一个文件，它能按文件里的逻辑改。但它对「上下文之外」的东西一无所知。一个函数的真实影响范围，远不止它自己的几十行——还有调用方的隐性依赖、跨模块的约定、运行时的副作用。这些它看不见，就会撞坏。
人改同一个函数，凭经验会先想「这函数谁在用」，会顺手 grep 一下调用方。这是种本能的边界意识。AI 没有这个本能，它眼里只有你喂给它的那一块。你不说边界在哪，它就当没有边界。
喂上下文，而不是指望它推断
那次事故之后，我改了用 AI 写代码的习惯，核心就一条：动手前，先把它需要的边界喂给它。
具体做法很笨：让 AI 改一个函数前，我先把它的调用方、相关的类型定义、它对外承诺的契约（返回值含义、副作用）一起贴给它，明确告诉它「这些是边界，改动不能破坏它们」。
喂足上下文后，AI 翻车率明显下降。不是它变聪明了，是它从「盲改」变成了「看着边界改」。它本来就不擅长推断看不见的东西，那我就把看不见的搬到它眼前。
三个该喂的「边界」
我总结了喂上下文时最该喂的三类信息：
- 调用方。这个函数被谁用、怎么用。不喂它就不知道改动会影响谁。
- 数据契约。返回值和参数的真实语义（不只是类型）。比如「返回 null 表示没找到，不是出错」这种业务约定。
- 副作用。这个函数有没有改外部状态、触发什么副作用。AI 最容易在副作用上闯祸。
这三样，人改代码会下意识扫一眼，AI 不会。所以你要替它扫，扫完喂给它。
收尾
那次事故给我最大的教训是：别指望 AI 替你守住它看不见的边界。
它能在看得见的地方表现得非常强，让你觉得它什么都能干。但它的强是有边界的，边界就是它的上下文窗口。窗口之外的世界的契约、依赖、副作用，它一概不知，而且它会自信地当作不存在。
所以用 AI 写代码，你的角色是「把边界搬进它视野」的人。你喂的边界越全，它撞墙越少。指望它自己推断边界，就是拿生产环境赌它的猜测。
AI 不会替你关心它看不见的东西。那是你的活，永远是你的活。