夜雨聆风说实话，我一开始是看不上 AI 编程助手的。
不就是个高级点的代码补全吗？真要写业务逻辑，还得自己来。这是去年我对它的全部印象。
后来被同事按头用了一阵子，再回头看自己写的代码——嗯，回不去了。
不是因为它替我写了多少，而是它把我从一堆「明明该做但不想做」的杂活里解放出来，让我把精力放回真正要动脑子的地方。
这篇不是来吹某个工具的。我想聊的是：上手一段时间后，我的编码方式到底哪变了，以及几条踩出来的心法。
第一阶段：从「补全」到「脚手架外挂」
最开始改变我的，不是它写业务代码多牛，而是它搭样板代码太省事。
新项目要建目录结构、写 CRUD 模板、配 CI、接日志……这些活又臭又长，但逃不掉。以前我复制粘贴旧项目，现在直接跟助手说：「按这个技术栈给我生成项目骨架，包含登录模块和基础的错误处理」，几十秒一个能跑的雏形就出来了。
我的角色从「搬砖工」变成了「验收员」：它出初稿，我扫一眼结构对不对、有没有多余依赖，不对就让改。
这一步没啥门槛，但却是大多数人第一次尝到甜头的地方——把重复劳动外包出去。
第二阶段：把「需求」当输入
习惯外包样板之后，我试着把输入从「代码片段」升级成「一小段需求」。
比如：「给这个接口加个限流，用令牌桶，超了返回 429」。它会给出实现，连带单测的雏形。
关键转折在这：我不再一行行写，而是先想清楚「我要什么」，再把这句话翻译成它懂的格式。
代价是——你得更清楚自己到底要什么。含含糊糊的需求，它就会给你含含糊糊的代码。
所以我现在写代码前，会先在脑子里（或文档里）把接口契约、边界条件、异常分支理一遍。AI 逼我把「想要什么」想得更明白，这反倒是个意外收获。
第三阶段：让 AI 进终端，当「跑腿」
再后来，我把助手从编辑器里放出来，进了终端。
它能自己跑测试、读报错、去翻相关代码、改完再跑一遍，直到绿了。我只需要看它最后交的差：改了哪几个文件、为什么这么改。
遇到诡异的运行时 bug，我以前要花半小时复现加打断点，现在把日志和堆栈甩给它，让它先猜三轮，我再判断哪个方向靠谱。
这一步最爽，但也最危险——它跑的命令、改的文件，你得有兜底。所以我一般只在「有完整测试覆盖」的分支上放它自由发挥，核心代码还是自己盯。
几条踩出来的心法
说点干货，都是交过学费的：
- 永远 review 它的输出。 尤其安全、权限、边界处理，AI 默认会往「能跑就行」靠，不会替你想攻击面。
- 上下文给够。 把相关的代码、你们团队的约定、约束条件一起喂过去，它才靠谱。瞎给一句话就指望它懂你的项目，不现实。
- 小步快跑。 别让它一次性写一整个大功能。拆成小任务，每步可验证，错了也好回滚。
- 把重复模式沉淀成规则。 你们项目里那些「必须这么做」的规矩，写成它能读的约定文件，下次它就少犯傻。
哪些活，我还是自己来
说回理性：不是所有事都该甩给 AI。
架构层面的取舍、需要深挖业务领域的设计、涉及安全核心的逻辑——这些我依然自己拍板。AI 给的往往是「平均解」，而真正值钱的是那些非平均的判断。
它也没让我变懒。相反，因为产出变快，我对「这一步对不对」的要求反而更高了。工具是放大器：你本来强，它让你更强；你糊涂，它帮你更快地糊涂。
所以回到标题——编码方式确实变了。
变的不是「写代码」这件事本身，而是我把时间重新分配了：少在样板和无脑调试里耗，多在「该往哪走」上想。
如果你还在把它当补全用，建议往上走一步试试：从一个小需求开始，当结对搭档，而不是打字机。
至于哪个工具好用，那是另一个话题了。这篇先聊到这。
