AI 辅助编程一年实践：从代码补全到结对开发

从最初把它当"更聪明的自动补全"，到现在写代码全程开着对话框，工作方式确实变了。一年下来踩过坑也尝到甜头，记录一下当前稳定下来的用法。

效率翻倍的环节

样板代码和迁移类工作。把 50 个 API 调用从 axios 换成 ofetch、给老组件批量补 TypeScript 类型、按模板生成 CRUD——这类"规则明确、重复劳动"的活，AI 做起来又快又稳，以前一下午的量现在半小时。

写测试。人写测试容易偷懒只测 happy path，让 AI 补边界用例反而比我自己想得全：空值、超长输入、并发时序，列得很痛快。我的角色从"写测试"变成了"审测试用例够不够"。

读陌生代码。接手老项目时，把核心文件丢给它"讲清楚这个模块的数据流"，再追问细节，比自己逐行啃快一个量级。当然它讲的要去代码里验证，当成一个耐心无限的同事做导读。

正则、SQL、一次性脚本。这类"语法我懂但细节要查半天"的东西，直接描述需求生成，再小数据验证，效率高得离谱。

差点被坑的地方

幻觉 API 和过期知识。它信誓旦旦写的某个库的第三个参数，这个版本根本不存在。教训：涉及具体库 API 的代码，生成后必须跑一遍，官方文档仍然是唯一事实来源。

"能跑但不对"的业务逻辑。最危险的不是报错，而是逻辑微妙地错——比如边界条件处理反了、时区没考虑。这类 bug 编译和测试都可能放过。代码 review 的精力不能省，反而要更聚焦在业务语义上。

架构层面的平均主义。让它自由发挥，会产出"每处都还行但整体平庸"的结构——过度抽象和该抽象时不抽象并存。模块边界、状态放在哪这种决策，必须自己来，AI 负责在给定框架内填肉。

上下文窗口的边界。一次喂太多文件，它会在中间某处开始"忘记"前面的约束。大任务拆小步走，每步给精确的相关文件，效果天差地别。

稳定下来的工作流

1. 自己写：需求拆解 + 模块边界 + 核心数据结构设计
2. AI 写：按设计逐个实现小函数/组件，每步附最小相关上下文
3. 一起改：贴报错、贴 review 意见，让它迭代
4. 自己审：重点看业务逻辑、边界条件、和设计的偏差

和带实习生很像：需求说得越清楚，产出质量越高。模糊的"帮我写个登录"会得到一坨勉强能跑的东西；给出明确的输入输出、错误处理约定、现有代码风格，产出就能直接用。

心态变化

• 不再背 API 细节了，省下的脑力花在设计和 review 上
• 学新技术的路径变了：先看官方文档建立正确认知，再让 AI 陪练，而不是反过来
• 搜索 skill 没有贬值，只是从"搜 API 用法"变成"搜为什么这么设计"

工具越强，对使用者的要求越往上游走：判断力、拆解力、表达力。一年前担心被替代，现在的体会是——它把我从"打字员"变成了真正的"工程师"，前提是工程能力本身没落下。