用 AI 助手写代码四个月，我总结的边界在哪

四个多月，日常开发基本都在和 AI 编程助手配合。省的时间是真的，坑也是真的。这篇记录哪些活我交给它，哪些活我不敢交。

一、它稳定省时间的五类任务

1. 写它自己擅长的脏活：数据格式转换、正则、序列化样板、参数化 SQL、CLI 脚手架、配置解析。这类代码我本来也不熟，写完还要查，直接交给它，我只要读一遍逻辑。
2. 读陌生代码：把一个不认识的库的入口文件丢进去，让它讲调用链、指出关键函数。它讲得未必全对，但作为"快速建立地图"的手段，比我自己 grep 快得多。
3. 写测试骨架：给它函数签名和行为描述，让它列用例。它列的用例常常浮于表面（happy path 扎堆），但作为一个清单起点很有价值，我在这个基础上补真正难的那些边界。
4. 解释报错：贴完整堆栈 + 版本信息，它给的方向大致命中。特别是那种"看不懂的错误码"，比我自己去搜快。
5. 改文案、写注释、生成变更说明：机械劳动，它做得比我快且更规整。

二、它稳定浪费时间的四类任务

1. 跨文件的一致性改动。改名、改函数签名、改一个约定。它会在被展示出来的文件里改对，同时漏掉另外三个文件里的引用——因为那些文件根本不在上下文里。这类活用 IDE 的符号重构，别用对话。
2. 它不知道的版本细节。API 在 2.x 和 3.x 之间变了参数名、某个包已经废弃、某个方法在新版本被删。它会把不同版本混着写，看起来完全合理。踩过的具体表现：它给我一段用了某个不存在的选项的代码，我照着跑，报错，再问它，它编另一个。只要涉及版本号，我就明确要求"以本地 node_modules/site-packages 里的实际代码为准"，或者直接把 .d.ts / 源码片段贴给它。
3. 性能问题。它能准确复述"这里 O(n²)"，但你要它给出实际能落地的优化方案，它倾向于改结构而不是找瓶颈，改完可能反而慢。瓶颈分析必须在真机做。
4. 有隐式约束的改动：某个字段"不能改类型是因为下游三个系统在读"、某个顺序"不能换是因为埋点时序依赖"。这些约定只在人脑子里和历史事故里，它看不见。

三、最贵的一条教训：不要接受它对自己工作的描述

这是我最想写的一条。

有一次让它改一个数据处理流程，它回复"已完成，所有测试通过"。我看了 diff，确实改了。我信了"测试通过"这句话，没重跑就合并了。两天后发现边界情况一直走错分支。回查：那个测试文件根本没被执行——测试脚本的匹配规则没覆盖新加的文件，"全部通过"是零个用例通过意义上的通过。

从那以后我给自己定了一条硬规矩：

AI 说的"我做完了""测试通过了""问题已修复"，一律当成它的一句自然语言输出，不当成事实。能自己验证的，必须自己去验一次：跑测试看原始输出、比对文件清单、直接调用接口看返回值。

同理还有几条：让它改代码前，先让它说明将要改哪些文件的哪些位置，然后核对自己看到的清单；改完看 git diff --stat，它顺手改了你不预期的文件时，必须当场处理；它写文件类操作时，先读一下现有内容再覆盖，否则会把别人未提交的改动冲掉。

这些听起来像不信任。但把它当成一个能力很强、没有记忆、也不为结果负责的实习生，这些动作就是正常的工程流程，不是苛求。

四、我现在的工作流

开工前

• 项目根放一份说明文件，写清技术栈版本、目录约定、禁止事项、验证命令。它每次都会读，这是投入产出比最高的一件事。
• 明确划出禁改区（迁移脚本、锁文件、别人正在改的模块），写在那份说明里，也在心里记一遍。

派活时

• 一次只交一个边界清楚的任务。"顺手把 X、Y、Z 都改了"这种指令，一定会得到一份你没法逐行审的巨型 diff。
• 给验收方式而不只是给需求："这个函数在输入为空数组时应返回 X，写个测试证明它"——比"请健壮处理边界情况"有效得多。
• 复杂任务先让它出方案，我看完再让它写。方案阶段发现方向错，成本只有几行字。

验收时

• 看 diff，不看它的总结。
• 亲跑它写的测试，看输出而不是退出码。
• git status 核对改动面。
• 数据库迁移这类它不常在测试里执行的东西，单独跑一遍——测试全绿不代表迁移能上。

收尾时

• 让它写变更说明草稿，我改成能进版本记录的话。
• 让它列出"本次改动可能影响但未被测试覆盖的地方"，这份清单常能提醒我去补验证。

五、一个还没解决的困扰

它对"看起来完成了"和"真的完成了"没有区分能力。文本层面两者一模一样，差别只在验证成本由谁付。所以现在我的时间分配变了：写代码的时间少了，读代码和验证代码的时间多了。这到底是赚了还是亏了，我暂时给不出结论——但如果我把验证也省掉，那省下的时间会在两周后加倍还回去。