说实话在真正用 AI Coding 之前我一度以为这玩意儿就是个高级补全插件顶多帮我写点模板代码、自动补个括号。但当我连续高强度使用了大半年回头复盘自己的实际工作状态时发现一个让我自己都吃惊的事实我写代码的时间变少了但产出反而更稳了我敲键盘的频率降低了但我说“这里应该这样做”的次数变多了。我花了很长时间才想明白这种变化的本质不是我变得懒惰而是我的角色真真切切地从“执行者”变成了“决策者”。这个转变对很多还在观望的开发者来说可能有点抽象。简单说过去我接到一个需求第一反应是“我该怎么用代码实现它”现在我的第一反应变成了“我该让 AI 帮我做哪部分、我自己把控哪部分、用什么标准来验收它”。这篇文章我不谈那些虚头巴脑的行业大势就实打实地聊聊这半年里我踩过的坑、总结出来的方法、以及从执行者到决策者这个身份变化背后到底对人的能力提出了哪些新的要求。如果你正在用 AI 辅助编程或者正准备尝试 AI Coding这篇文章里的内容应该能让你少走不少弯路。我会把工作流的变化、实操中的关键细节、以及我在真实项目中遇到的问题排查方法全都摊开来讲。1. 从“写代码的人”到“定方向的人”AI Coding半年带来的真实工作流变化1.1 我的日常敲键盘的时间少了动脑子的时间多了先说一个最直观的变化我每天的“有效编码时间”从过去的 6 到 8 小时直线下降到了 2 到 3 小时。听起来很夸张但确实是真的。不过这并不意味着我变轻松了因为省下来的时间并没有用来摸鱼而是全部转移到了另一类工作内容上——需求拆解、方案设计、任务编排、结果审查。举个例子。早前我接到一个内部管理后台的权限模块重构需求搁在以前我大致估算需要两天第一天搭数据模型和接口第二天做前端页面联调。但这次我用了完全不同的路径。我先把需求拆成了几个清晰的子任务——数据模型设计、权限校验逻辑、前端路由守卫、操作日志记录——然后逐个告诉 AI 每个子任务的上下文、输入输出、约束条件。AI 负责把每一块代码生成出来我负责检查它生成的接口是否符合既有的规范数据模型是否能支撑未来半年的业务扩展以及权限逻辑有没有绕过的漏洞。结果是我只花了一天就完成了原本两天的活。但真正让我觉得角色发生变化的瞬间是当 AI 给出了一个“能跑”但设计上并不优雅的接口方案时我没有像以前那样自己动手去改代码而是直接在对话里指出了问题所在告诉它“不要用逐条 if 判断用户角色改成基于策略模式的权限校验器”然后 AI 自动重构了那部分代码。那一刻我意识到我的价值已经不是“手写代码的能力”而是“判断代码好坏的能力”和“给 AI 指出正确方向的能力”。这两件事本质上都是决策。1.2 执行者思维与决策者思维的本质差异很多人觉得执行者和决策者的区别就是“管不管人”其实在 AI Coding 的场景下区别远比这个更微妙。执行者思维的核心是“如何把一件事做对”。我面对的是一个确定的任务比如实现一个排序算法、写一个查询接口我关注的是语法、逻辑、边界条件我会去查文档、试错、优化性能。这种思维模式下我的对象是代码本身。决策者思维的核心是“如何确定什么是该做的事以及做的标准是什么”。我在拿到需求后首先要判断 AI 的能力边界在哪里——这部分它擅长那部分它容易出错然后我要设计任务的粒度——拆得太大它容易跑偏拆得太小我又累死最后我要定义验收标准——什么叫“完成”、什么叫“合格”。用一个不太恰当的比喻过去我是一个自己搬砖自己砌墙的泥瓦匠现在我是一个给施工队下指令、检查墙砌得直不直的监工。我没有停止对结果的负责只是我的工作对象从“砖块”变成了“人和方法”。1.3 为什么说这种转变是必然的而不是我个人的选择我见过不少同行对 AI Coding 抱着抗拒态度觉得它会让自己失业或者贬值。我自己的体验是它确实会“淘汰”一部分工作但不是淘汰人而是淘汰“纯执行环节”。AI 生成的代码质量已经稳定到可以处理 80% 的常规编码任务了——CRUD 接口、数据模型定义、工具函数、单元测试模板这些在技术层面已经没有多少壁垒。如果你过去的工作主要就是这些那你确实会遇到压力。但请注意AI 解决的只是“怎么实现”它并不知道“为什么要实现这个”以及“实现成什么样才是对的”。决定“做什么”和“做成什么样”的决策权目前依然牢牢掌握在人手里而且这个决策权的重要性只会越来越大。这半年里我每天做的事就是从这一大堆能生成的代码中选择、组合、修正、把关。这不是因为我个人有多强而是因为工作流的改变使然——当你面前站着一个 24 小时在线、从不抱怨、知识面极广的程序员时你唯一需要动脑子的就是告诉他该干什么。2. 从执行者到决策者的几个关键跃迁我踩过的坑和总结出来的方法2.1 提示词不是“写作文”需求描述的三个层次刚开始用 AI Coding 的时候我犯了一个特别典型的错误把提示词写成了“作文”。我会花 20 分钟写一大段描述把自己的背景、目标、约束、甚至心情都交代一遍然后 AI 回复了一堆看似完美、实则跑题的代码。后来我总结出给 AI 下需求有三个层次从低到高分别是目标层你要做什么事情服务的对象是谁。比如“给用户模块写一个分页查询接口”。约束层有哪些硬性限制比如技术栈必须是 Spring Boot MyBatis、输入参数要带分页字段、返回格式要和既有接口保持一致。验收层什么样的代码算合格比如“要做参数校验”“要处理 null 值”“要支持排序字段”。大部分新手都停留在第一层他们给 AI 说“写一个分页查询”AI 确实写了但写出来的代码风格和项目里的祖传代码完全不搭或者缺少异常处理。我后来养成的习惯是在每次让 AI 干活之前先把约束层和验收层想清楚用列表或短句喂给它。宁可每次多花两三分钟写约束条件也不要花半小时跟它进行“拉锯战”。2.2 让 AI 干活之前先自己想清楚验收标准这一点是半年里最深刻的教训如果你自己都不知道什么算“做完了”AI 给你的永远是一个半成品。以前我自己写代码时是边写边想“先实现主流程再补充边界情况”。AI 不同它是有求必应的——你说实现主流程它就真的只给你主流程。你说补个错误处理它就补个 try-catch但 catch 之后该记日志还是该返回兜底值它不管而这些恰恰是生产环境代码里最重要的部分。所以我现在的工作习惯变成了在把任务发给 AI 之前先花 10 分钟写一个“验收清单”。比如我需要它帮我生成一个报表导出功能我清单里会明确写着数据量超过 5 万行必须用分批查询导出的 Excel 需要包含表头和日期格式化为 yyyy-MM-dd失败时要返回明确错误码而不是笼统的异常。有了这个清单AI 生成的东西基本一次到位不用来回改。这其实就是决策的体现我不是在替 AI 写代码而是在替它定义“好”的标准。2.3 代码审查才是真正的核心技能过去我总觉得代码审查就是把别人的代码看一遍找找 bug提提意见。但当你用 AI 辅助编程后代码审查的工作量会急剧增加而且难度也会上升。因为 AI 生成的代码有一个特点它表面上看起来很合理语法流畅、命名规范、逻辑结构清晰但它经常在“上下文边界”上犯错。具体说就是它不了解你项目的特殊背景——比如某个字段在其他模块里已经被填充过了你这里再赋值一次会覆盖掉或者某个方法在性能上必须用 Redis 缓存但 AI 只看到了数据库查询。我曾经被一个“看起来完全正常”的 AI 生成代码坑过它生成了一段数据同步逻辑表面上代码质量很高但它不知道为什么在某些场景下必须采用增量更新而不是全量覆盖。我审查了前三遍都没发现问题直到做数据对比测试时才发现数据被覆盖了。从那以后我养成了一种“疑罪从有”的审查心态只要是 AI 写的代码我默认它不理解上下文默认它会在边界情况下出错所以我会重点检查它与外部系统的交互、对全局状态的修改、以及对异常情况的处理。这种审查能力正是从执行者向决策者转变时最需要刻意训练的一项技能。2.4 上下文管理和小步推进避免 AI 代码翻车的不二法门很多开发者抱怨 AI 生成代码“越写越烂”我觉得根本原因不是 AI 变笨了而是对话上下文太长了。AI 的注意力窗口虽然越来越大但当一段对话里堆积了太多任务、太多无关的讨论后它很容易被“带偏”忘记最初的约束条件。我的解决方案很简单一次对话只让 AI 做一件事。一个完整的模块我会拆成 5 到 8 次独立的对话每次对话聚焦于一个子任务。比如权限模块我会分别开新的对话做“数据模型定义”“权限校验工具类”“接口层实现”“前端路由守卫”每次对话开头都会把这一个子任务的上下文说清楚。这就像你给一个外包程序员派活你不会一次性把整个项目丢给他而是一个需求一个需求地下、一个里程碑一个里程碑地验收。实际测试下来这种小步推进的方式把 AI 生成的代码返工率降低了至少 60%。这背后是一个很朴素的道理决策粒度越细对结果的掌控力就越强。3. 实操复盘一个完整需求从想法到上线的 AI Coding 工作流3.1 前置环节需求拆分和任务描述的实操细节我用一个真实例子来演示整个流程。上周我接了一个“订单列表页增加批量导出功能”的需求这个需求看起来很简单整个处理流程如下。第一步不是打开 AI 工具而是打开了文本编辑器写任务描述。我写了四个子任务子任务A后端增加批量导出接口支持按创建时间筛选、按订单状态筛选导出格式为 Excel数据量上限为 5 万行。子任务B对导出的 Excel 做列定义包括订单号、用户昵称、商品名称、实付金额、下单时间、支付时间、订单状态。子任务C前端在列表页新增“导出”按钮点击后调用导出接口并处理等待状态和错误提示。子任务D导出完成后发送一个站内通知告知用户可前往下载中心获取文件。写完后我逐一确认这些子任务是否还有其他隐藏需求结果发现了两个一开始没考虑到的问题导出文件是异步生成的所以接口需要返回一个 taskId前端需要轮询状态以及因为涉及金额导出的操作需要记录操作日志用于合规审查。这两个问题如果是在过去自己一次性写代码的过程中发现我会在调试时痛苦地找半天。但在这个流程里它们是在“决策阶段”就被我主动识别出来的因为我把需求拆开审视时每个边界都会变得更清晰。3.2 让 AI 并行“结对”而不是让它单打独斗任务拆分完毕后我并不是把一个任务从头到尾丢给 AI然后等它拿回一个成型的模块。我采用的是“结对编程”式的生成方式我负责逻辑主干AI 负责具体实现。具体到批量导出这个需求我是这样干的我先用一段伪代码把生成 Excel、异步任务、通知消息这三个环节的逻辑顺序写出来然后发给 AI让它翻译成实际的 Java 代码。这种做法的好处是AI 不会自由发挥去设计流程结构它只需要专注在“把伪代码变成符合项目规范的实现”。这其实就是我作为决策者的核心动作——把架构决策权牢牢握在自己手里只把实现细节外包出去。结果比我想象的更顺利。AI 生成的代码里异步任务部分使用了线程池Excel 生成部分用了 EasyExcel和我选用的技术栈完全吻合。我只需要做部分微调加上操作日志记录以及把订单金额去掉了精度问题导致的 Double 转换。3.3 对 AI 生成代码的审查重点和测试兜底代码生成之后我严格按照自己总结的审查清单做了四轮检查第一轮看接口参数和返回结构是否符合约定。这一步主要靠肉眼看AI 经常会把分页参数命名成 page/size而我们的项目规范是 current/limit这种问题不能让 AI 猜必须人工纠正。第二轮看异常路径是否覆盖。AI 写的方案里导出数据为空时它直接返回成功但文件为空明显不合理我改成了返回“暂无数据”的明确提示。第三轮看数据一致性和边界条件。订单金额计算是否会出现精度问题导出数据量超过 5 万行时是否分页查询并发导出时会不会因为同一个 taskId 互相覆盖这些是 AI 最容易踩雷的地方。第四轮跑完整的测试链路。这部分我基本没有依赖 AI而是用真实的测试数据跑通了批量导出流程确认 Excel 里的每个字段值都与数据库一致。做完四轮审查后这个功能我只用了不到半天就顺利上线了。过去这种需求从收到到发版我至少需要一天半。3.4 技术选型和成本不同场景下 AI Coding 的适用性评价这半年里我也测试过好几款 AI Coding 工具包括国际大厂的 Copilot、国产的各类辅助编程 IDE 插件、以及更偏对话式的 AI 编程助手。给我的主观感受是对话式的 AI 更适合做“从需求到完整代码”的生成而 IDE 里的行级补全更适合做“写代码过程中的加速”。具体怎么选我的建议是看场景。如果你是在一个成熟的代码库里做增量开发IDE 内置的补全能力已经足够它可以根据你周围的代码风格给出符合直觉的建议但如果你是要快速搭建一个新模块的原型或者要从零开始写一个功能那么对话式的 AI 能帮你更快生成整块代码。我还试过把 AI 作为代码审查工具让它帮我读一段代码并找出潜在的 bug。结果只能说差强人意——AI 能发现一些明显的空指针风险、未关闭资源的问题但对业务逻辑和时序问题的判断能力还很弱。所以我的定位是AI 帮我做第一层过滤真正的业务判断必须我自己做。4. 角色转变背后的能力模型重塑AI Coding 工程师到底算不算人工智能工程师4.1 对“AI Coding 工程师是不是人工智能工程师”这个热词的看法最近这个讨论挺热的刷到过好多帖子在问“ai coding工程师属人工智能工程师吗”。我的观点是从职业分类的角度看AI Coding 工程师本身并不是人工智能工程师。人工智能工程师的核心工作是设计模型、训练模型、调优参数、部署推理他们需要深入理解神经网络、Transformer 结构、损失函数、分布式训练等底层原理。而 AI Coding 工程师本质上还是软件工程师只是他们的开发方式从手写代码变成了使用 AI 工具生成代码。但从能力模型的角度看AI Coding 工程师确实在向“人工智能工程师”的某些特质靠拢。比如说一个合格的 AI Coding 工程师需要理解 AI 模型的输出规律、知道如何构造有效的提示词、懂得如何评估生成结果的质量这本质上是在做“人机协同”的交互设计。这确实带有一些 AI 工程化的味道但不意味着他就是人工智能工程师。我个人的理解是这个职业分类的争论本身就不是特别重要。重要的是随着 AI Coding 工具的普及软件工程师的岗位职责必然会发生迁移——从“写代码的执行者”迁移到“设计任务和验收结果的决策者”。4.2 新能力模型需求分析、架构判断与质量评估如果让我给在这个领域想转型的同行画一个能力模型图我认为三个能力维度最为关键。第一维是需求分析能力。过去需求分析是产品经理和架构师的事普通开发者拿到手的往往是一个已经拆解得很细的任务。但现在你直接面对 AI你必须自己去拆解需求否则 AI 什么也做不了。你需要学会把模糊的业务诉求翻译成清晰的、可验证的技术任务这是一个典型的“决策”而非“执行”动作。第二维是架构判断能力。AI 能生成代码碎片但拿不出系统性的架构方案。它不知道你这个模块未来会不会扩展、接口设计是否具备向后兼容性、数据模型是不是冗余。你必须能判断 AI 生成的代码是否符合整体架构的走向以及在更优解出现时是否有能力推翻 AI 的方案。第三维是质量评估能力。你不再是写完代码跑一下发现没报错就算完事而是要建立一整套“AI 生成代码的验收标准”包括它是否考虑了异常路径它是否符合安全规范它的性能是否满足要求它会引入什么新的技术债这三个能力传统开发者的成长路径里很少会系统性地锻炼到但在 AI Coding 时代它们成了核心壁垒。4.3 对团队协作和项目管理方式的影响这个转变不仅仅影响个体的工作方式也在重构整个团队的协作模式。我们团队现在已经形成了这样的默契开发组长负责把需求拆解成“AI 友好型”的任务描述普通开发负责跑 AI 生成代码、做基础审查和修修补补技术负责人则聚焦于 AI 生成代码的架构评审和核心模块的人工兜底。过去的“人人写代码”变成了“分层管代码”每一层的核心工作都是决策只是决策的粒度不同。这种模式下团队整体产出的稳定性反而更高了。因为 AI 生成的代码质量下限很高而上限由人类的决策质量来决定。只要决策者是靠谱的产出的代码基本差不了。这和我过去所见到的“团队里每个人的水平参差不齐导致代码质量波动很大”形成了鲜明对比。5. 常见问题与排查技巧实录AI Coding 半年避坑清单5.1 为什么 AI 写的代码总是“看起来对但跑不通”这是新手最常遇到的困惑也是我早期使用 AI Coding 时最头疼的问题。AI 生成的代码在它自己的训练数据里大概率是正确的但在你的项目环境里跑不通原因通常是AI 不了解你项目的依赖版本生成了和你当前 Spring Boot 版本不兼容的 APIAI 没有见过你的数据库表结构生成了错误的 SQL 字段名AI 对编译器的行为过于乐观生成的代码可能存在隐式类型转换问题。我的解决方案是在给 AI 描述任务时把一个最小化的上下文粘进对话里——比如当前项目的 Maven 依赖版本列表、目标数据库表结构、相关类的方法签名。这样能让 AI 在生成代码前有“基本认知”而不是凭空猜测。5.2 什么时候该信 AI什么时候必须自己写这是一个比较有争议的话题。我的经验是AI 适合处理那些“模式很固定、上下文不复杂、出错了修复成本也不高”的任务比如 CRUD 接口、数据校验、模板代码、简单的工具函数。但遇到下面几类情况时我坚持人工亲自写涉及核心交易链路或资金流转的代码。这个领域容错率太低AI 一旦出错损失不可接受需要和外部第三方系统深度交互的代码。外部系统的文档更新很频繁AI 的训练数据可能已经过时与历史遗留系统做集成时。遗留系统的很多“潜规则”在代码里根本看不出来AI 只能靠猜。这个选择本身也是一种决策能力它需要你对项目的理解足够深才能准确判断哪些环节可以“外包”给 AI哪些环节必须“自己上”。5.3 一些容易忽略的“软性”避坑点最后分享几个没有写在任何官方文档里、但我实际踩过的坑千万不要让 AI 直接改生产代码。我习惯让 AI 在临时分支上生成代码人工审查通过后才合并到主分支。这能避免大量无谓的返工和意外冲突。不要一次性让 AI 重构整个项目。有一次我为了“省事”把整个项目丢给 AI 让它做模块拆分结果它给了一个看起来特别合理、实际上没人能维护的分层方案。从那以后我只让 AI 做增量式的小步重构。如果你用的是对话式 AI务必给每个新话题新建一个对话并且不要在对话里往返回顾太久的修改历史。这能减少它错乱的可能性。最后保留自己的编码能力。这半年我虽然敲代码少了但每个周末我都会刻意手写一些小工具类保持对代码的敏感度。决策者的底气来自对执行的深刻理解当你彻底不写代码后你对 AI 的控制能力反而会下降。拿我自己来说从“执行者”变成“决策者”并不是我刻意追求的结果而是 AI Coding 这个工具和工作流自然塑造的方向。如果你的目标只是少写点代码、轻松点那你可能很快会失望但如果你愿意把精力投向更高价值的判断与决策AI Coding 绝对是你职业生涯里一股不可忽视的推力。 
长河君 · 2026/11/2 13:21:45 · 阅读 1.2k AI Coding半年实战：从代码执行者到决策者的关键跃迁
说实话在真正用 AI Coding 之前我一度以为这玩意儿就是个高级补全插件顶多帮我写点模板代码、自动补个括号。但当我连续高强度使用了大半年回头复盘自己的实际工作状态时发现一个让我自己都吃惊的事实我写代码的时间变少了但产出反而更稳了我敲键盘的频率降低了但我说“这里应该这样做”的次数变多了。我花了很长时间才想明白这种变化的本质不是我变得懒惰而是我的角色真真切切地从“执行者”变成了“决策者”。这个转变对很多还在观望的开发者来说可能有点抽象。简单说过去我接到一个需求第一反应是“我该怎么用代码实现它”现在我的第一反应变成了“我该让 AI 帮我做哪部分、我自己把控哪部分、用什么标准来验收它”。这篇文章我不谈那些虚头巴脑的行业大势就实打实地聊聊这半年里我踩过的坑、总结出来的方法、以及从执行者到决策者这个身份变化背后到底对人的能力提出了哪些新的要求。如果你正在用 AI 辅助编程或者正准备尝试 AI Coding这篇文章里的内容应该能让你少走不少弯路。我会把工作流的变化、实操中的关键细节、以及我在真实项目中遇到的问题排查方法全都摊开来讲。1. 从“写代码的人”到“定方向的人”AI Coding半年带来的真实工作流变化1.1 我的日常敲键盘的时间少了动脑子的时间多了先说一个最直观的变化我每天的“有效编码时间”从过去的 6 到 8 小时直线下降到了 2 到 3 小时。听起来很夸张但确实是真的。不过这并不意味着我变轻松了因为省下来的时间并没有用来摸鱼而是全部转移到了另一类工作内容上——需求拆解、方案设计、任务编排、结果审查。举个例子。早前我接到一个内部管理后台的权限模块重构需求搁在以前我大致估算需要两天第一天搭数据模型和接口第二天做前端页面联调。但这次我用了完全不同的路径。我先把需求拆成了几个清晰的子任务——数据模型设计、权限校验逻辑、前端路由守卫、操作日志记录——然后逐个告诉 AI 每个子任务的上下文、输入输出、约束条件。AI 负责把每一块代码生成出来我负责检查它生成的接口是否符合既有的规范数据模型是否能支撑未来半年的业务扩展以及权限逻辑有没有绕过的漏洞。结果是我只花了一天就完成了原本两天的活。但真正让我觉得角色发生变化的瞬间是当 AI 给出了一个“能跑”但设计上并不优雅的接口方案时我没有像以前那样自己动手去改代码而是直接在对话里指出了问题所在告诉它“不要用逐条 if 判断用户角色改成基于策略模式的权限校验器”然后 AI 自动重构了那部分代码。那一刻我意识到我的价值已经不是“手写代码的能力”而是“判断代码好坏的能力”和“给 AI 指出正确方向的能力”。这两件事本质上都是决策。1.2 执行者思维与决策者思维的本质差异很多人觉得执行者和决策者的区别就是“管不管人”其实在 AI Coding 的场景下区别远比这个更微妙。执行者思维的核心是“如何把一件事做对”。我面对的是一个确定的任务比如实现一个排序算法、写一个查询接口我关注的是语法、逻辑、边界条件我会去查文档、试错、优化性能。这种思维模式下我的对象是代码本身。决策者思维的核心是“如何确定什么是该做的事以及做的标准是什么”。我在拿到需求后首先要判断 AI 的能力边界在哪里——这部分它擅长那部分它容易出错然后我要设计任务的粒度——拆得太大它容易跑偏拆得太小我又累死最后我要定义验收标准——什么叫“完成”、什么叫“合格”。用一个不太恰当的比喻过去我是一个自己搬砖自己砌墙的泥瓦匠现在我是一个给施工队下指令、检查墙砌得直不直的监工。我没有停止对结果的负责只是我的工作对象从“砖块”变成了“人和方法”。1.3 为什么说这种转变是必然的而不是我个人的选择我见过不少同行对 AI Coding 抱着抗拒态度觉得它会让自己失业或者贬值。我自己的体验是它确实会“淘汰”一部分工作但不是淘汰人而是淘汰“纯执行环节”。AI 生成的代码质量已经稳定到可以处理 80% 的常规编码任务了——CRUD 接口、数据模型定义、工具函数、单元测试模板这些在技术层面已经没有多少壁垒。如果你过去的工作主要就是这些那你确实会遇到压力。但请注意AI 解决的只是“怎么实现”它并不知道“为什么要实现这个”以及“实现成什么样才是对的”。决定“做什么”和“做成什么样”的决策权目前依然牢牢掌握在人手里而且这个决策权的重要性只会越来越大。这半年里我每天做的事就是从这一大堆能生成的代码中选择、组合、修正、把关。这不是因为我个人有多强而是因为工作流的改变使然——当你面前站着一个 24 小时在线、从不抱怨、知识面极广的程序员时你唯一需要动脑子的就是告诉他该干什么。2. 从执行者到决策者的几个关键跃迁我踩过的坑和总结出来的方法2.1 提示词不是“写作文”需求描述的三个层次刚开始用 AI Coding 的时候我犯了一个特别典型的错误把提示词写成了“作文”。我会花 20 分钟写一大段描述把自己的背景、目标、约束、甚至心情都交代一遍然后 AI 回复了一堆看似完美、实则跑题的代码。后来我总结出给 AI 下需求有三个层次从低到高分别是目标层你要做什么事情服务的对象是谁。比如“给用户模块写一个分页查询接口”。约束层有哪些硬性限制比如技术栈必须是 Spring Boot MyBatis、输入参数要带分页字段、返回格式要和既有接口保持一致。验收层什么样的代码算合格比如“要做参数校验”“要处理 null 值”“要支持排序字段”。大部分新手都停留在第一层他们给 AI 说“写一个分页查询”AI 确实写了但写出来的代码风格和项目里的祖传代码完全不搭或者缺少异常处理。我后来养成的习惯是在每次让 AI 干活之前先把约束层和验收层想清楚用列表或短句喂给它。宁可每次多花两三分钟写约束条件也不要花半小时跟它进行“拉锯战”。2.2 让 AI 干活之前先自己想清楚验收标准这一点是半年里最深刻的教训如果你自己都不知道什么算“做完了”AI 给你的永远是一个半成品。以前我自己写代码时是边写边想“先实现主流程再补充边界情况”。AI 不同它是有求必应的——你说实现主流程它就真的只给你主流程。你说补个错误处理它就补个 try-catch但 catch 之后该记日志还是该返回兜底值它不管而这些恰恰是生产环境代码里最重要的部分。所以我现在的工作习惯变成了在把任务发给 AI 之前先花 10 分钟写一个“验收清单”。比如我需要它帮我生成一个报表导出功能我清单里会明确写着数据量超过 5 万行必须用分批查询导出的 Excel 需要包含表头和日期格式化为 yyyy-MM-dd失败时要返回明确错误码而不是笼统的异常。有了这个清单AI 生成的东西基本一次到位不用来回改。这其实就是决策的体现我不是在替 AI 写代码而是在替它定义“好”的标准。2.3 代码审查才是真正的核心技能过去我总觉得代码审查就是把别人的代码看一遍找找 bug提提意见。但当你用 AI 辅助编程后代码审查的工作量会急剧增加而且难度也会上升。因为 AI 生成的代码有一个特点它表面上看起来很合理语法流畅、命名规范、逻辑结构清晰但它经常在“上下文边界”上犯错。具体说就是它不了解你项目的特殊背景——比如某个字段在其他模块里已经被填充过了你这里再赋值一次会覆盖掉或者某个方法在性能上必须用 Redis 缓存但 AI 只看到了数据库查询。我曾经被一个“看起来完全正常”的 AI 生成代码坑过它生成了一段数据同步逻辑表面上代码质量很高但它不知道为什么在某些场景下必须采用增量更新而不是全量覆盖。我审查了前三遍都没发现问题直到做数据对比测试时才发现数据被覆盖了。从那以后我养成了一种“疑罪从有”的审查心态只要是 AI 写的代码我默认它不理解上下文默认它会在边界情况下出错所以我会重点检查它与外部系统的交互、对全局状态的修改、以及对异常情况的处理。这种审查能力正是从执行者向决策者转变时最需要刻意训练的一项技能。2.4 上下文管理和小步推进避免 AI 代码翻车的不二法门很多开发者抱怨 AI 生成代码“越写越烂”我觉得根本原因不是 AI 变笨了而是对话上下文太长了。AI 的注意力窗口虽然越来越大但当一段对话里堆积了太多任务、太多无关的讨论后它很容易被“带偏”忘记最初的约束条件。我的解决方案很简单一次对话只让 AI 做一件事。一个完整的模块我会拆成 5 到 8 次独立的对话每次对话聚焦于一个子任务。比如权限模块我会分别开新的对话做“数据模型定义”“权限校验工具类”“接口层实现”“前端路由守卫”每次对话开头都会把这一个子任务的上下文说清楚。这就像你给一个外包程序员派活你不会一次性把整个项目丢给他而是一个需求一个需求地下、一个里程碑一个里程碑地验收。实际测试下来这种小步推进的方式把 AI 生成的代码返工率降低了至少 60%。这背后是一个很朴素的道理决策粒度越细对结果的掌控力就越强。3. 实操复盘一个完整需求从想法到上线的 AI Coding 工作流3.1 前置环节需求拆分和任务描述的实操细节我用一个真实例子来演示整个流程。上周我接了一个“订单列表页增加批量导出功能”的需求这个需求看起来很简单整个处理流程如下。第一步不是打开 AI 工具而是打开了文本编辑器写任务描述。我写了四个子任务子任务A后端增加批量导出接口支持按创建时间筛选、按订单状态筛选导出格式为 Excel数据量上限为 5 万行。子任务B对导出的 Excel 做列定义包括订单号、用户昵称、商品名称、实付金额、下单时间、支付时间、订单状态。子任务C前端在列表页新增“导出”按钮点击后调用导出接口并处理等待状态和错误提示。子任务D导出完成后发送一个站内通知告知用户可前往下载中心获取文件。写完后我逐一确认这些子任务是否还有其他隐藏需求结果发现了两个一开始没考虑到的问题导出文件是异步生成的所以接口需要返回一个 taskId前端需要轮询状态以及因为涉及金额导出的操作需要记录操作日志用于合规审查。这两个问题如果是在过去自己一次性写代码的过程中发现我会在调试时痛苦地找半天。但在这个流程里它们是在“决策阶段”就被我主动识别出来的因为我把需求拆开审视时每个边界都会变得更清晰。3.2 让 AI 并行“结对”而不是让它单打独斗任务拆分完毕后我并不是把一个任务从头到尾丢给 AI然后等它拿回一个成型的模块。我采用的是“结对编程”式的生成方式我负责逻辑主干AI 负责具体实现。具体到批量导出这个需求我是这样干的我先用一段伪代码把生成 Excel、异步任务、通知消息这三个环节的逻辑顺序写出来然后发给 AI让它翻译成实际的 Java 代码。这种做法的好处是AI 不会自由发挥去设计流程结构它只需要专注在“把伪代码变成符合项目规范的实现”。这其实就是我作为决策者的核心动作——把架构决策权牢牢握在自己手里只把实现细节外包出去。结果比我想象的更顺利。AI 生成的代码里异步任务部分使用了线程池Excel 生成部分用了 EasyExcel和我选用的技术栈完全吻合。我只需要做部分微调加上操作日志记录以及把订单金额去掉了精度问题导致的 Double 转换。3.3 对 AI 生成代码的审查重点和测试兜底代码生成之后我严格按照自己总结的审查清单做了四轮检查第一轮看接口参数和返回结构是否符合约定。这一步主要靠肉眼看AI 经常会把分页参数命名成 page/size而我们的项目规范是 current/limit这种问题不能让 AI 猜必须人工纠正。第二轮看异常路径是否覆盖。AI 写的方案里导出数据为空时它直接返回成功但文件为空明显不合理我改成了返回“暂无数据”的明确提示。第三轮看数据一致性和边界条件。订单金额计算是否会出现精度问题导出数据量超过 5 万行时是否分页查询并发导出时会不会因为同一个 taskId 互相覆盖这些是 AI 最容易踩雷的地方。第四轮跑完整的测试链路。这部分我基本没有依赖 AI而是用真实的测试数据跑通了批量导出流程确认 Excel 里的每个字段值都与数据库一致。做完四轮审查后这个功能我只用了不到半天就顺利上线了。过去这种需求从收到到发版我至少需要一天半。3.4 技术选型和成本不同场景下 AI Coding 的适用性评价这半年里我也测试过好几款 AI Coding 工具包括国际大厂的 Copilot、国产的各类辅助编程 IDE 插件、以及更偏对话式的 AI 编程助手。给我的主观感受是对话式的 AI 更适合做“从需求到完整代码”的生成而 IDE 里的行级补全更适合做“写代码过程中的加速”。具体怎么选我的建议是看场景。如果你是在一个成熟的代码库里做增量开发IDE 内置的补全能力已经足够它可以根据你周围的代码风格给出符合直觉的建议但如果你是要快速搭建一个新模块的原型或者要从零开始写一个功能那么对话式的 AI 能帮你更快生成整块代码。我还试过把 AI 作为代码审查工具让它帮我读一段代码并找出潜在的 bug。结果只能说差强人意——AI 能发现一些明显的空指针风险、未关闭资源的问题但对业务逻辑和时序问题的判断能力还很弱。所以我的定位是AI 帮我做第一层过滤真正的业务判断必须我自己做。4. 角色转变背后的能力模型重塑AI Coding 工程师到底算不算人工智能工程师4.1 对“AI Coding 工程师是不是人工智能工程师”这个热词的看法最近这个讨论挺热的刷到过好多帖子在问“ai coding工程师属人工智能工程师吗”。我的观点是从职业分类的角度看AI Coding 工程师本身并不是人工智能工程师。人工智能工程师的核心工作是设计模型、训练模型、调优参数、部署推理他们需要深入理解神经网络、Transformer 结构、损失函数、分布式训练等底层原理。而 AI Coding 工程师本质上还是软件工程师只是他们的开发方式从手写代码变成了使用 AI 工具生成代码。但从能力模型的角度看AI Coding 工程师确实在向“人工智能工程师”的某些特质靠拢。比如说一个合格的 AI Coding 工程师需要理解 AI 模型的输出规律、知道如何构造有效的提示词、懂得如何评估生成结果的质量这本质上是在做“人机协同”的交互设计。这确实带有一些 AI 工程化的味道但不意味着他就是人工智能工程师。我个人的理解是这个职业分类的争论本身就不是特别重要。重要的是随着 AI Coding 工具的普及软件工程师的岗位职责必然会发生迁移——从“写代码的执行者”迁移到“设计任务和验收结果的决策者”。4.2 新能力模型需求分析、架构判断与质量评估如果让我给在这个领域想转型的同行画一个能力模型图我认为三个能力维度最为关键。第一维是需求分析能力。过去需求分析是产品经理和架构师的事普通开发者拿到手的往往是一个已经拆解得很细的任务。但现在你直接面对 AI你必须自己去拆解需求否则 AI 什么也做不了。你需要学会把模糊的业务诉求翻译成清晰的、可验证的技术任务这是一个典型的“决策”而非“执行”动作。第二维是架构判断能力。AI 能生成代码碎片但拿不出系统性的架构方案。它不知道你这个模块未来会不会扩展、接口设计是否具备向后兼容性、数据模型是不是冗余。你必须能判断 AI 生成的代码是否符合整体架构的走向以及在更优解出现时是否有能力推翻 AI 的方案。第三维是质量评估能力。你不再是写完代码跑一下发现没报错就算完事而是要建立一整套“AI 生成代码的验收标准”包括它是否考虑了异常路径它是否符合安全规范它的性能是否满足要求它会引入什么新的技术债这三个能力传统开发者的成长路径里很少会系统性地锻炼到但在 AI Coding 时代它们成了核心壁垒。4.3 对团队协作和项目管理方式的影响这个转变不仅仅影响个体的工作方式也在重构整个团队的协作模式。我们团队现在已经形成了这样的默契开发组长负责把需求拆解成“AI 友好型”的任务描述普通开发负责跑 AI 生成代码、做基础审查和修修补补技术负责人则聚焦于 AI 生成代码的架构评审和核心模块的人工兜底。过去的“人人写代码”变成了“分层管代码”每一层的核心工作都是决策只是决策的粒度不同。这种模式下团队整体产出的稳定性反而更高了。因为 AI 生成的代码质量下限很高而上限由人类的决策质量来决定。只要决策者是靠谱的产出的代码基本差不了。这和我过去所见到的“团队里每个人的水平参差不齐导致代码质量波动很大”形成了鲜明对比。5. 常见问题与排查技巧实录AI Coding 半年避坑清单5.1 为什么 AI 写的代码总是“看起来对但跑不通”这是新手最常遇到的困惑也是我早期使用 AI Coding 时最头疼的问题。AI 生成的代码在它自己的训练数据里大概率是正确的但在你的项目环境里跑不通原因通常是AI 不了解你项目的依赖版本生成了和你当前 Spring Boot 版本不兼容的 APIAI 没有见过你的数据库表结构生成了错误的 SQL 字段名AI 对编译器的行为过于乐观生成的代码可能存在隐式类型转换问题。我的解决方案是在给 AI 描述任务时把一个最小化的上下文粘进对话里——比如当前项目的 Maven 依赖版本列表、目标数据库表结构、相关类的方法签名。这样能让 AI 在生成代码前有“基本认知”而不是凭空猜测。5.2 什么时候该信 AI什么时候必须自己写这是一个比较有争议的话题。我的经验是AI 适合处理那些“模式很固定、上下文不复杂、出错了修复成本也不高”的任务比如 CRUD 接口、数据校验、模板代码、简单的工具函数。但遇到下面几类情况时我坚持人工亲自写涉及核心交易链路或资金流转的代码。这个领域容错率太低AI 一旦出错损失不可接受需要和外部第三方系统深度交互的代码。外部系统的文档更新很频繁AI 的训练数据可能已经过时与历史遗留系统做集成时。遗留系统的很多“潜规则”在代码里根本看不出来AI 只能靠猜。这个选择本身也是一种决策能力它需要你对项目的理解足够深才能准确判断哪些环节可以“外包”给 AI哪些环节必须“自己上”。5.3 一些容易忽略的“软性”避坑点最后分享几个没有写在任何官方文档里、但我实际踩过的坑千万不要让 AI 直接改生产代码。我习惯让 AI 在临时分支上生成代码人工审查通过后才合并到主分支。这能避免大量无谓的返工和意外冲突。不要一次性让 AI 重构整个项目。有一次我为了“省事”把整个项目丢给 AI 让它做模块拆分结果它给了一个看起来特别合理、实际上没人能维护的分层方案。从那以后我只让 AI 做增量式的小步重构。如果你用的是对话式 AI务必给每个新话题新建一个对话并且不要在对话里往返回顾太久的修改历史。这能减少它错乱的可能性。最后保留自己的编码能力。这半年我虽然敲代码少了但每个周末我都会刻意手写一些小工具类保持对代码的敏感度。决策者的底气来自对执行的深刻理解当你彻底不写代码后你对 AI 的控制能力反而会下降。拿我自己来说从“执行者”变成“决策者”并不是我刻意追求的结果而是 AI Coding 这个工具和工作流自然塑造的方向。如果你的目标只是少写点代码、轻松点那你可能很快会失望但如果你愿意把精力投向更高价值的判断与决策AI Coding 绝对是你职业生涯里一股不可忽视的推力。