AI 编码助手开始真正可用后，我的开发方式变了什么
补档说明：本文属于「AI 工程落地周记」系列，计划发布时间为 2025-06-28 10:20。当前先保留为草稿，后续补充真实案例、代码片段和复盘细节后再发布。
AI 编码助手真正开始可用之后，我最大的变化不是“写代码更快”这么简单，而是工作流本身变了。以前很多开发动作天然是线性的：看需求、想实现、写代码、跑测试、再修。现在它更像一个往返过程：
- 我先定义边界
- 让 AI 生成一个初版
- 我负责验证、删减、改名、重构
- 再把更清楚的上下文喂回去
也就是说，AI 没把开发变成“自动完成”，而是把很多工作从“手打实现”转移成了“定义问题和审查结果”。
这个变化一开始会让人有点不适应，因为你会明显感觉到自己不再只是 coder，而更像 reviewer、router 和 constraint designer。但一旦进入节奏，效率提升确实是实打实的。
我以前的开发节奏是什么样
以前我写一个中等复杂度功能，通常是这样：
- 先在脑子里把实现细节过一遍
- 从入口函数开始一层层写
- 中间不断查文档和切上下文
- 最后再统一跑测试和清理细节
这套流程当然没问题，但有个明显缺点：大量时间花在“把脑子里的结构翻译成代码”。
现在变化最大的不是速度，而是“起手方式”
AI 编码助手开始真正有用后，我发现自己最明显的改变是：
- 我不再总是从空白文件起手
- 我更愿意先把接口、边界和约束写清楚
- 再让 AI 产一个不一定完美、但足够可审查的初版
这意味着我会更早地写这些东西：
- 输入输出结构
- 测试样例
- 错误分支
- 命名约束
因为这些约束写得越清楚，AI 生成的东西就越像“可用初稿”，而不是“随机代码”。
哪些环节是真的变快了
1. 样板和重复劳动
例如：
- DTO / Schema
- CRUD 边界代码
- 测试脚手架
- 一些很模式化的 glue code
这些原来就不难，但挺耗注意力。现在 AI 接管这部分之后，我的体感不是“能力增强”，而是“注意力被腾出来了”。
2. 文档和代码来回对照
以前我经常在“看文档”和“写代码”之间来回切。现在很多时候可以先让 AI 给一个基于文档语义的初版，再回头人工确认关键点。
3. 多方案对比
以前脑子里只能同时 hold 住一两个写法，现在更容易先让 AI 产出两个候选，再看哪个更接近自己真正想要的结构。
哪些环节其实没有变快，甚至更慢
这里反而是很多人最容易误判的地方。
1. 最终确认
只要代码会进主分支，最终确认一定不会省。AI 把“写”变快了，但“信任”没有自动变快。
2. 命名和边界
AI 很会生成局部合理代码，但“整个模块的边界该怎么划”“这几个名字是否在项目里长期可维护”，这些仍然要靠人拍板。
3. 风险判断
AI 很容易给出“看起来合理”的实现，但它通常不会主动告诉你这段代码在生产上最可能死在哪。
所以我现在越来越把它看成：
- 快速草稿生成器
- 文档理解加速器
- 样板劳动替代器
而不是“资深工程师替代器”。
我后来形成的一套更稳的使用方式
现在我更喜欢让 AI 参与这几类事情：
1. 先产初版
尤其是在结构清晰的模块里。
2. 先列测试点
很多时候让 AI 先帮我列边界条件，比直接让它写实现更有价值。
3. 先改小块
我不太喜欢让它直接改特别大、耦合特别深的文件。越是边界清楚的小块，收益越稳定。
4. 先做“机械工作”
比如迁移、重命名、抽取重复代码、补测试框架。
一个真实的工作流对比
现在一个常见任务更像这样：
以前：
想实现 -> 手写初版 -> 跑起来 -> 修边界 -> 测试
现在：
定义边界 -> AI 生成初版 -> 人审结构和命名 -> 补测试 -> 精修
这就是为什么我说，变化最大的其实是工作方式，而不是单纯的手速。
总结
AI 编码助手开始真正可用后，我的开发方式变了什么？最核心的变化不是“我不写代码了”，而是“我把更多精力放在定义问题、审查结果和管理边界上”。
它确实让某些阶段明显更快，但真正的长期收益不只是提速，而是把工程师从重复翻译劳动里解放出来，去做更接近设计、验证和取舍的工作。