编程工具怎么分工：补全、对话、审查各管一段

补全：在编辑器里，不打断思路

补全工具的价值是省打字，不是替你想架构。它看的是光标前后的几十行，猜你下一句要写什么。

适合的场景：写重复的样板代码、补全参数、照着已有风格写一个新方法。

不熟的库别让它补。它按最常见的用法写，版本对不上就编译不过，你还得一个个查。

判断值不值：用一周，看接受率。低于三成，要么它不懂你的项目，要么你的代码太独特。

对话式工具适合有明确边界的小改动：这个函数改成异步、这段循环改成批量、这个报错帮我定位。

它的优势是能解释。你问“为什么这么改”，它会给出理由，这个理由有时是错的，但能帮你判断它有没有理解你的意图。

用的时候把上下文给足：相关类型定义、调用方、报错全文。只给一个函数，它改出来的东西能跑，但和项目风格不搭。

审查工具不写代码，只看 diff。它擅长发现的是：空值没判、异常吞掉、日志缺上下文、循环里有查询。

这类问题人也会看，但看多了会疲劳。让机器先过一遍，人只看它标出来的和它漏掉的。

它有个固定的偏好：多提问题，少给结论，一个 diff 能提二十条。要按严重程度筛，别逐条改。

老项目有一套自己的封装：内部框架、自研工具类、十年前的写法。这些不在训练数据里，它只能猜。

表现是：它给你的代码用了不存在的 API，或者用新版本写法改老版本代码。

处理办法是喂上下文：把内部封装的用法贴两段进去，说“按这个写”。比写十句要求有效。

还有一种情况是别硬用：涉及资金、权限、并发的核心逻辑，让它写草稿，你来定稿，别反过来。

还有个成本常被忽略：审查别人用 AI 写的代码，比审查人手写的更累，因为要判断哪些地方是它猜的。

AI 写的代码要不要写测试？

要，而且要比平时更细。它的错通常在边界：空列表、超时、并发重入，这些不写测试很难发现。

能让它直接改整个仓库吗？

小范围可以，大范围不建议。它改十个文件，你要核十个文件，省的时间又还回去了。

团队要不要统一工具？

建议统一，至少统一代码规范文件。不同工具对规范的遵守程度不一样，混用会出现风格分裂。