AI 写代码最大的风险，不是它写不出来，而是你把活交给它之后，就失去了对项目的掌控。我见过太多例子：全交给 AI 跑长任务，做完之后自己都不知道代码变成什么样，出问题也定位不了；还有人拿 AI 改别人写的代码，改着改着就把一处全局变量改坏了，甚至自己都没察觉。

AI 是放大器：你自己越清楚”要什么、边界在哪、怎么验证”，它越好用；反过来，你越模糊，它就把你的模糊放大成更大的乱子。这篇讲三条原则，帮你既用上 AI、又不失控。

原则一：边界你定，内部交给 AI

把”接口契约”攥在自己手里，把”内部实现”扔给 AI。

  • 你负责定义：输入是什么、输出是什么、字段叫什么、边界规则（比如”这个值是全局变量，谁都别乱动”）。
  • AI 负责实现：在边界里面把它做出来。

这样做的好处是：即使 AI 在内部改得乱七八糟，只要边界不变，它波及不到外部。出问题你也知道问题在”内部实现”这一块，而不是”整条链路都塌了”。

反过来，如果你连边界都放任 AI 定，它一改，可能把”只有一个入口”“必须幂等”这种你默认为真的约定给打破——那才是最要命的。

原则二：小步走、可验证，别让 AI 一次改一大片

这是最容易被忽略、也最容易出事的。

  • 一次只让它改一个点，改完马上跑一下相关用例。
  • 出问题，范围很小，一眼就能定位。
  • 如果让它一次”重构整个文件/整个模块”，出错了你根本不知道是哪一步引入的，排查成本直接爆炸。

AI 帮你在每个小步里做验证（编译、跑测试、看结果），你就能随时确认”这步没问题”。小步，是可控的前提。

原则三：你保留”看懂”和”回滚”的权力

这是底线。AI 改的代码，你得能看懂，得能一键回滚。

  • 看懂：不是为了逐行读，而是为了能判断”它把什么改了”。如果 AI 悄悄改了别人的文件、改了一个你没授权的角落，你要看得出来。
  • 回滚：每一次改动都要有清晰、可回退的提交/分支。这样即使 AI 改坏了，你一条命令就能回到上一个能跑的状态，而不是在一堆混乱里手忙脚乱。

“看不到改动”是最危险的状态——你不知道它碰了哪里，自然就不知道该怎么救。

落到具体：两种”碰不得”的东西

有些东西，别让 AI 随便碰：

  • 全局变量、共享状态：这类东西牵一发而动全身，AI 常常”好心地”帮你改，结果连锁炸掉。宁可你自己手动改。
  • 别人/别处的代码：如果不是你的模块，别让 AI 去动。因为它没有你对那个模块的理解，改了很容易越界。

一句话

AI 是生产力，但它不会为你负责。你越早把”边界、验证、回滚”这三点立起来，它就越是从”帮你走捷径”变成”帮你干活”，而不是”替你做决定”。

让 AI 干活可以，但方向盘和刹车，得一直握在自己手里。