很久没认真聊这个话题了因为我今年一直都在用 AI 辅助写代码而且是重度使用。你们可能也有同样的感觉AI 写代码确实越来越快了以前要憋一天的模块现在一个下午能出好几版VSCode 里的 AI 写代码插件也已经从“补全”进化到“对话生成整个文件”。但问题是团队的整体交付并没有像代码生成速度那样翻倍甚至还出现了新的混乱。项目烂尾的、重构到崩溃的、上线后疯狂修 bug 的我都见过。今天想从一线开发的视角把我观察到的“真正的瓶颈”拆开聊一聊。1. 瓶颈迁移从“写不出来”变成“没想清楚”大概在三年前一个功能从需求到落地最痛苦的一段是编码。尤其是那些大量 CRUD、页面表单、接口对接的活写起来纯粹是体力劳动费时间还容易出错。所以大家自然觉得只要 AI 能加速编码整个软件开发的效率就会起飞。实际情况远没这么简单。1.1 代码生成速度膨胀但需求理解没有同步膨胀我最近用 AI 辅助写一个内部运营后台从数据库表设计到接口代码再到前端页面AI 大概帮我生成了一千多行代码。我自己只写了一点胶水逻辑。听起来很爽但真正费时间的是在生成代码之前的那半天我一直抱着产品经理的文档反复追问这个“权限”到底按角色分还是按数据范围分状态下线之后历史数据怎么处理列表的排序规则是什么这些问题的答案不会出现在 AI 生成的代码里也不会因为你把提示词写得更长就自动浮现。它们是系统本身的业务约束必须由人来定。AI 能帮你把“想清楚之后的方案”快速变成代码但它没办法把“没想清楚的需求”变成“能跑的系统”。打个比方以前我们是在工地搬砖一块一块砖地砌墙所以搬砖速度决定了工程进度。现在 AI 是台自动砌墙机砖砌得飞快但地基图纸如果本来就是“大概建个三层小楼”那机器越快拆了重来的代价也越大。1.2 模糊需求在 AI 时代被成倍放大了以前需求模糊程序员在写代码的过程中会不断发现矛盾然后回头找产品经理确认。这个过程虽然痛苦但它天然形成了一个“需求校验环”。现在不一样AI 对模糊需求的容忍度很高。你给它一句话它立刻给你生成一套看起来非常完整的实现连注释都写得整整齐齐。问题在于这套代码很可能是 AI 基于它训练语料里“最常见的情况”猜出来的而不是基于你团队的真实业务规则。我团队里有个新同事接手一个老模块重构直接把原来的需求描述贴给 AI让 AI 帮他生成新版本。第 2 天他一脸困惑地跟我说“逻辑跑不通啊AI 生成的代码在处理‘优惠叠加’的时候跟财务那边的口径完全对不上。” 后来一查是需求描述里根本没写清楚“互斥优惠”和“叠加优惠”的判断优先级。也就是说瓶颈根本不是 AI 写不出来而是团队压根没把需求定义到 AI 能直接开工的颗粒度。所以现在我在团队里反复强调一句话提示词里的每一句业务逻辑都是你欠下来的技术债。需求拆得越粗AI 填的坑就越深。逼着产品、测试、开发一起把用户故事、验收标准、异常分支写在最前面这不是流程冗余这是在给 AI 时代的新开发模式铺路。2. 代码质量责任AI 负责“生产”你负责“出事后的兜底”代码生成速度上去了一个新的瓶颈浮出水面谁对代码质量负责以前代码是开发一个字一个字敲出来的虽然慢但每个变量怎么命名、每个边界条件怎么处理脑子里都有印象。AI 三分钟吐出一百行代码你真有把握这一百行全对吗2.1 阅读代码的能力变得比写代码更重要以前面试常问“你写过多少代码”现在我觉得更该问的是“你能多快读懂一段陌生代码并指出它的隐患”。因为 AI 写的代码本质上就是一个“非常自信的陌生同事”写的你不 review 就合入相当于不看合同就签字。我举一个真实例子。有次让 AI 写一个批量导入功能它确实把文件解析、数据校验、批量入库都写出来了。表面看没问题但我 review 的时候发现它在数据校验失败时会抛出异常终止整个批次。如果线上有 5 万条数据其中 3 条格式不对整个批次全部回滚用户就得等下一次全部重来。这算 bug 吗从代码逻辑上看不算但业务场景里这是完全不可接受的。这种“业务语义层面的 bug”AI 看不出来只有懂业务、懂异常流的人能在代码审查时抓出来。所以 AI 辅助开发之后代码评审从“走流程”变成了“真正的质量闸门”。我现在的评审时间比写代码时间还长。每一条合入请求我都会重点看异常分支处理了没有状态流转是不是完整有没有硬编码的魔法值外部接口调用有没有超时和重试这些恰恰是 AI 最喜欢省略、也最容易出错的地方。2.2 自信满满的“幻觉代码”最危险AI 生成代码的错误往往不是“写不出来”而是“一本正经地写出一个不存在的函数或过时的 API”。比如我遇到过它生成了一段调用某个内部工具库的代码那个方法名看起来很像真的但实际库里根本没这个方法。如果不是编译器报错这段代码就会在代码库里安静地躺很久直到某个深夜被某个服务调用时才炸出来。应对这个问题我摸索出一套比较实用的方法分享出来。每次让 AI 生成代码前明确要求它“基于项目现有的接口定义”最好是直接把对应的接口签名、实体类贴进提示词上下文生成之后不要直接信编译、跑单测、看关键路径的日志一步都不要省涉及外部服务调用的代码绝不直接上生产先用 mock 环境跑一遍完整链路。我自己还有一个习惯让 AI 同时给出“这段代码可能出现的问题”列表。虽然它列的不一定全但往往能帮我开启一个检查思路比自己干瞪眼强不少。说到底现在的 AI 就像个手速极快、但偶尔会一本正经胡说八道的实习生你必须给它设好检查点。3. 架构决策和系统集成成了新的“手工作坊”如果说代码生成算“计件工资”那架构设计和系统集成就是“整体工程”。AI 特别擅长处理一个文件、一个模块、一个函数但它对系统整体性的把握目前还是很弱。这不是提示词写得不好而是它天然缺少对全局上下文的理解。3.1 AI 看不到“整片森林”举个很常见的场景单机应用改成微服务。你让 AI 把一个本地方法调用改成 HTTP 调用它能改得很好加上超时、重试、异常处理样样俱全。但它不会问你这个接口真的应该拆出去吗拆出去之后数据一致性怎么办分布式事务的最终一致方案是什么你确定这个调用链路的超时时间不会把上游服务拖垮吗这些问题是架构层面的权衡需要结合业务的并发量、团队维护能力、部署环境、甚至是组织架构来一起判断。AI 没有“组织记忆”它不知道你们团队只有 5 个人维护不了 20 个微服务也不知道你们数据库用的是共享实例跑不了太重的统计查询。它只知道你让它写一个下单接口它就老老实实写一个下单接口。所以我现在把 AI 定位成“架构师的执行者”而不是“架构师”。做技术选型、画系统边界、定数据模型的时候我都是自己先想清楚再用 AI 去填里面的细节。后面者虽然慢但它是决定系统半年后是“很好维护”还是“重组地狱”的关键。3.2 真实世界的肮脏复杂嵌入式、PLC、老系统都教我做人的道理说了这么多 Web 开发其实在嵌入式软件开发、PLC 代码生成这些更贴近物理世界的领域瓶颈更明显。因为代码不是跑在标准服务器上而是和硬件强耦合。比如我帮人看过一个 BMS电池管理系统的学习路线咨询里面最核心的不是你会不会写 C 语言而是你懂不懂电池充放电特性、SOC 估算算法、CAN 通信协议。AI 可以帮你按模板生成底层驱动代码甚至基于 CANoe 脚本生成测试用例但它不知道你的电芯内阻曲线是怎么样的不知道你的硬件板子在第 3 路 AD 采样上有个硬件滤波电容偏小的问题。同样的PLC 代码生成这几年也热闹过一阵大家想让 AI 根据时序逻辑自动生成梯形图或结构化文本。实测下来纯逻辑控制的部分确实能省不少事但一旦涉及传感器故障诊断、安全联锁、设备的异常恢复流程AI 就容易“想当然”。因为这些领域的安全规范和边界条件通常散落在各种手册、老师傅的经验和现场调试记录里线上文本里根本没那么多高质量语料。所以说AI 真正越过不去的坎不是“不知道怎么生成代码”而是“不知道怎么和物理世界、历史包袱、组织协作打交道”。这些靠的是集成测试、联调、现场调试靠的是人类对约束条件的深刻理解。4. 测试与调试AI 生成测试容易定义“正确行为”很难做了这么多年开发我越来越觉得测试这件事的本质是把“预期行为”表达清楚。以前写单测是在表达现在让 AI 写单测也是在表达。差别在于AI 能帮你不费吹灰之力生成一百个用力的测试用例框架但那个“预期行为”得靠人来给。4.1 让 AI 生成测试的前提是你能说清“正确”我曾经试过让 AI 给一个促销计算模块写单测。它给了 20 多个用例覆盖了正常折扣、满减、优惠券叠加看起来覆盖率还挺高。结果一审查发现它测的“正确”只是它自己代码实现里的“正确”而不是需求文档里的“正确”。比如需求里明确规定“优惠券抵扣金额不能超过订单金额的 30%”AI 带的测试里完全没有这个断言因为它从代码里看不出来这种业务规则。要解决这个问题我现在的做法是先写测试描述再写实现。不是传统意义上的 TDD而是把测试用例的“业务场景”用大白话写成清单再让 AI 根据清单生成测试代码和实现代码。这相当于我们先把“已知的正确行为”锁死再让 AI 在边界内发挥。如果需求变了那就回去改清单让 AI 重新生成实现。这套流程走下来代码质量和需求一致性明显好很多。4.2 调试瓶颈AI 缺的是上下文不是推理能力还有调试。现在 AI 可以帮你解释报错、分析堆栈但它没办法直接看到你的系统状态。你问它“线上订单超时怎么办”它只能给你一些通用排查建议。真正的调试瓶颈在于你你能不能把系统当时的输入、状态、日志、调用链路组织成一段足够清晰的背景信息交给 AI。这又回到了信息差的问题。所以我现在写代码时会刻意把日志打得比过去更完整。入口参数、关键分支判断、外部调用耗时统统保留。一方面是为了自己排查方便另一方面也是为了让 AI 能在“足够多上下文”的情况下帮我分析问题。没有日志和可观测性数据AI 的调试能力就是空中楼阁。我的经验是系统可观测性做得越好AI 能帮上忙的地方就越多调试这一环才不会成为新的瓶颈。5. 团队协作与知识传递最贵的不是代码是对齐AI 让个体产能差距变小了。以前一个“能写出高质量代码”的程序员和一个普通程序员产出能差好几倍。现在有了 AI 辅助普通程序员也能在短时间内生成大量能跑的代码。那么团队里的竞争力开始从“写代码的能力”转向“对齐的能力”和“知识传递的效率”。5.1 代码 review 的文化比任何时候都重要当 AI 生成的代码大量涌入代码库如果 review 机制跟不上技术债就会像滚雪球一样越滚越大。我见过一个项目AI 把 80% 的代码写了但没人深度 review结果代码风格五花八门有的用函数式、有的用命令式同样的业务逻辑在三个模块里实现了三遍但边界处理还不一样。最后维护的人崩溃到想推倒重来。我们现在定了一个规矩AI 生成的代码只能走“建议”路径必须由一个熟悉该模块的人类工程师 review 通过后才能合入。并且 review 意见里必须写清楚“为什么这里不对”而不是简单一句“优化一下”。这个习惯很笨但能保证知识在人与人之间流动也让 AI 后续生成的代码能越写越符合团队规范。5.2 文档和注释从“可选项”变成“硬需求”以前很多程序员讨厌写文档觉得代码即文档。但 AI 时代文档是提示词上下文的一部分是 AI 理解项目背景的重要依据。一个模块的设计文档、关键接口的说明、常见的坑以前可能只在几个核心开发脑子里现在必须显式地写下来否则 AI 无法引用新人也无法传承。我现在开始要求团队成员每人维护自己负责模块的“README 典型场景 坑位记录”不要求写得多规范但必须真实、具体。用 Claude Code 或者 VSCode AI 插件创建新代码时直接把这份说明贴进上下文它生成的代码贴合度会高得惊人。说白了AI 的能力边界的上限取决于团队知识沉淀的深度。6. 实操建议AI 时代开发者的新核心能力清单聊了这么多瓶颈最后给点实操层面的建议。我把目前感觉最核心的新能力整理成一个清单都是自己踩坑踩出来的希望能帮你们少走几步弯路。6.1 写“能被 AI 高效消费”的需求以前我们写需求描述主要是给人看。现在需求描述的第一读者很可能是 AI。所以我会刻意用结构化的方式写背景、输入、输出、成功标准、异常分支、必须避免什么。比如“做一个导入功能”我会写成背景运营每天需要批量更新商品价格。输入CSV 文件必须校验表头和底色格式。输出导入结果页展示成功条数和失败原因。成功标准支持 5 万条数据在 30 秒内完成校验。异常分支文件格式错误、必填字段为空、价格超过阈值、网络中断。必须避免不要出现部分成功时全部回滚的情况。用这种格式喂给 AI它生成的代码命中率会直线上升。反过来说如果这 6 个部分你自己都写不全那你缺的根本不是 AI 工具而是思路。6.2 建立个人和团队的“AI 审查清单”别信 AI 的“我觉得没问题”。我给自己定了个 review 清单每次都对照着过一遍边界条件空值、超长值、负数、并发冲突资源释放文件句柄、数据库连接、网络连接有没有正确关闭并发安全有没有共享变量被多线程同时写依赖版本生成的代码依赖的库版本跟项目现有环境是否一致日志与监控关键路径有没有留日志安全风险SQL 注入、越权访问、敏感信息硬编码。这套清单看起来基础但真能挡住大部分 AI 生成的“低级问题”。我不追求清单多花哨只追求每个问题都有明确答案。6.3 把 AI 的上下文管理当成第一生产力很多人用 AI 写代码效率不高不是因为 AI 不行而是上下文没给够。我现在用 VSCode 里的 AI 写代码插件绝对不会只丢一句“帮我写一个订单查询接口”。我会先把对应的数据表结构、已有的服务层代码、controller 风格的示例、返回给前端的 VO 结构全都粘进去。整个过程看起来多花了两分钟但生成的代码基本能少改一大半。用 Claude Code 建新项目的时候也是一样。第一步不是让它“创建项目”而是先把项目背景、技术栈、目录结构约定、编码风格要求写在一个 MARKDOWN 里作为 memory 文件之后所有对话都基于这个文件展开。6.4 招聘和学习的侧重也要调整了如果你正在带团队或者还在找工作我强烈建议把考察重点从“能不能手写算法”转向“能不能拆解问题、审查代码、快速学习业务”。现在入门级开发者的门槛确实在降低但高阶开发者的价值反而更大了——因为 AI 写的代码越多能看懂系统、能设计系统、能在关键时刻拍板说“这里不能这样做”的人就越金贵。我自己面试新人时现在会问他一个场景类问题“如果 AI 给了一段看起来都对但你不确定对不对的代码你会怎么验证”回答能说出“补测试、看边界、查文档、问业务方”的我基本都会给高分。这就代表他已经理解了 AI 时代开发的本质。7. 避坑速查表把实战经验直接抄走下面这个表是我这段时间实战下来的一些高频坑和应对方法整理给你们可以直接抄进团队文档里。场景表面现象实际原因应对建议需求模糊时让 AI 写代码生成结果“看起来都能用”AI 猜测了不存在的业务规则先写结构化需求再写代码AI 用了不存在的 API编译或运行时报错训练数据中的过期代码生成后必须跑编译和测试边界条件处理缺失线上数据一多就出 bugAI 默认只覆盖主流程用 review 清单逐项检查并发场景生成错误偶发数据错乱AI 没意识到共享状态强调并发边界写并发测试模块间风格差异大代码库维护困难缺少统一规范上下文建立项目 memory 文件测试断言不符合业务测试全绿但功能错的测试只是“验证自己的实现”先写业务场景清单再生成测试微服务拆分不合理调用链路过长AI 只看到局部调用架构决策必须人工拍板嵌入式代码不达预期硬件行为不符缺乏硬件约束和现场参数把硬件规格和采样特性喂给 AI每一条都是我或身边同事实实在在踩过的坑。AI 是个好工具但它不能替你做价值判断、不能替你跟产品经理确认优先级、不能替你在凌晨三点去排查那一条异常日志背后到底发生了什么。软件开发的瓶颈没有消失它只是从“体力活”转移到了“脑力活”上。最后再分享一点个人的感受。我现在写代码的时间确实少了很多但思考的时间变多了思考需求合不合理、思考边界条件有哪些、思考这段代码会不会连累三个月后的自己。以前我觉得这是“磨刀不误砍柴工”现在我觉得这可能就是 AI 时代软件开发的常态——代码是 AI 写的但软件是你的。 
长河君 · 2026/9/10 17:11:35 · 阅读 1.2k AI写代码虽快，但真正的瓶颈在哪里？
很久没认真聊这个话题了因为我今年一直都在用 AI 辅助写代码而且是重度使用。你们可能也有同样的感觉AI 写代码确实越来越快了以前要憋一天的模块现在一个下午能出好几版VSCode 里的 AI 写代码插件也已经从“补全”进化到“对话生成整个文件”。但问题是团队的整体交付并没有像代码生成速度那样翻倍甚至还出现了新的混乱。项目烂尾的、重构到崩溃的、上线后疯狂修 bug 的我都见过。今天想从一线开发的视角把我观察到的“真正的瓶颈”拆开聊一聊。1. 瓶颈迁移从“写不出来”变成“没想清楚”大概在三年前一个功能从需求到落地最痛苦的一段是编码。尤其是那些大量 CRUD、页面表单、接口对接的活写起来纯粹是体力劳动费时间还容易出错。所以大家自然觉得只要 AI 能加速编码整个软件开发的效率就会起飞。实际情况远没这么简单。1.1 代码生成速度膨胀但需求理解没有同步膨胀我最近用 AI 辅助写一个内部运营后台从数据库表设计到接口代码再到前端页面AI 大概帮我生成了一千多行代码。我自己只写了一点胶水逻辑。听起来很爽但真正费时间的是在生成代码之前的那半天我一直抱着产品经理的文档反复追问这个“权限”到底按角色分还是按数据范围分状态下线之后历史数据怎么处理列表的排序规则是什么这些问题的答案不会出现在 AI 生成的代码里也不会因为你把提示词写得更长就自动浮现。它们是系统本身的业务约束必须由人来定。AI 能帮你把“想清楚之后的方案”快速变成代码但它没办法把“没想清楚的需求”变成“能跑的系统”。打个比方以前我们是在工地搬砖一块一块砖地砌墙所以搬砖速度决定了工程进度。现在 AI 是台自动砌墙机砖砌得飞快但地基图纸如果本来就是“大概建个三层小楼”那机器越快拆了重来的代价也越大。1.2 模糊需求在 AI 时代被成倍放大了以前需求模糊程序员在写代码的过程中会不断发现矛盾然后回头找产品经理确认。这个过程虽然痛苦但它天然形成了一个“需求校验环”。现在不一样AI 对模糊需求的容忍度很高。你给它一句话它立刻给你生成一套看起来非常完整的实现连注释都写得整整齐齐。问题在于这套代码很可能是 AI 基于它训练语料里“最常见的情况”猜出来的而不是基于你团队的真实业务规则。我团队里有个新同事接手一个老模块重构直接把原来的需求描述贴给 AI让 AI 帮他生成新版本。第 2 天他一脸困惑地跟我说“逻辑跑不通啊AI 生成的代码在处理‘优惠叠加’的时候跟财务那边的口径完全对不上。” 后来一查是需求描述里根本没写清楚“互斥优惠”和“叠加优惠”的判断优先级。也就是说瓶颈根本不是 AI 写不出来而是团队压根没把需求定义到 AI 能直接开工的颗粒度。所以现在我在团队里反复强调一句话提示词里的每一句业务逻辑都是你欠下来的技术债。需求拆得越粗AI 填的坑就越深。逼着产品、测试、开发一起把用户故事、验收标准、异常分支写在最前面这不是流程冗余这是在给 AI 时代的新开发模式铺路。2. 代码质量责任AI 负责“生产”你负责“出事后的兜底”代码生成速度上去了一个新的瓶颈浮出水面谁对代码质量负责以前代码是开发一个字一个字敲出来的虽然慢但每个变量怎么命名、每个边界条件怎么处理脑子里都有印象。AI 三分钟吐出一百行代码你真有把握这一百行全对吗2.1 阅读代码的能力变得比写代码更重要以前面试常问“你写过多少代码”现在我觉得更该问的是“你能多快读懂一段陌生代码并指出它的隐患”。因为 AI 写的代码本质上就是一个“非常自信的陌生同事”写的你不 review 就合入相当于不看合同就签字。我举一个真实例子。有次让 AI 写一个批量导入功能它确实把文件解析、数据校验、批量入库都写出来了。表面看没问题但我 review 的时候发现它在数据校验失败时会抛出异常终止整个批次。如果线上有 5 万条数据其中 3 条格式不对整个批次全部回滚用户就得等下一次全部重来。这算 bug 吗从代码逻辑上看不算但业务场景里这是完全不可接受的。这种“业务语义层面的 bug”AI 看不出来只有懂业务、懂异常流的人能在代码审查时抓出来。所以 AI 辅助开发之后代码评审从“走流程”变成了“真正的质量闸门”。我现在的评审时间比写代码时间还长。每一条合入请求我都会重点看异常分支处理了没有状态流转是不是完整有没有硬编码的魔法值外部接口调用有没有超时和重试这些恰恰是 AI 最喜欢省略、也最容易出错的地方。2.2 自信满满的“幻觉代码”最危险AI 生成代码的错误往往不是“写不出来”而是“一本正经地写出一个不存在的函数或过时的 API”。比如我遇到过它生成了一段调用某个内部工具库的代码那个方法名看起来很像真的但实际库里根本没这个方法。如果不是编译器报错这段代码就会在代码库里安静地躺很久直到某个深夜被某个服务调用时才炸出来。应对这个问题我摸索出一套比较实用的方法分享出来。每次让 AI 生成代码前明确要求它“基于项目现有的接口定义”最好是直接把对应的接口签名、实体类贴进提示词上下文生成之后不要直接信编译、跑单测、看关键路径的日志一步都不要省涉及外部服务调用的代码绝不直接上生产先用 mock 环境跑一遍完整链路。我自己还有一个习惯让 AI 同时给出“这段代码可能出现的问题”列表。虽然它列的不一定全但往往能帮我开启一个检查思路比自己干瞪眼强不少。说到底现在的 AI 就像个手速极快、但偶尔会一本正经胡说八道的实习生你必须给它设好检查点。3. 架构决策和系统集成成了新的“手工作坊”如果说代码生成算“计件工资”那架构设计和系统集成就是“整体工程”。AI 特别擅长处理一个文件、一个模块、一个函数但它对系统整体性的把握目前还是很弱。这不是提示词写得不好而是它天然缺少对全局上下文的理解。3.1 AI 看不到“整片森林”举个很常见的场景单机应用改成微服务。你让 AI 把一个本地方法调用改成 HTTP 调用它能改得很好加上超时、重试、异常处理样样俱全。但它不会问你这个接口真的应该拆出去吗拆出去之后数据一致性怎么办分布式事务的最终一致方案是什么你确定这个调用链路的超时时间不会把上游服务拖垮吗这些问题是架构层面的权衡需要结合业务的并发量、团队维护能力、部署环境、甚至是组织架构来一起判断。AI 没有“组织记忆”它不知道你们团队只有 5 个人维护不了 20 个微服务也不知道你们数据库用的是共享实例跑不了太重的统计查询。它只知道你让它写一个下单接口它就老老实实写一个下单接口。所以我现在把 AI 定位成“架构师的执行者”而不是“架构师”。做技术选型、画系统边界、定数据模型的时候我都是自己先想清楚再用 AI 去填里面的细节。后面者虽然慢但它是决定系统半年后是“很好维护”还是“重组地狱”的关键。3.2 真实世界的肮脏复杂嵌入式、PLC、老系统都教我做人的道理说了这么多 Web 开发其实在嵌入式软件开发、PLC 代码生成这些更贴近物理世界的领域瓶颈更明显。因为代码不是跑在标准服务器上而是和硬件强耦合。比如我帮人看过一个 BMS电池管理系统的学习路线咨询里面最核心的不是你会不会写 C 语言而是你懂不懂电池充放电特性、SOC 估算算法、CAN 通信协议。AI 可以帮你按模板生成底层驱动代码甚至基于 CANoe 脚本生成测试用例但它不知道你的电芯内阻曲线是怎么样的不知道你的硬件板子在第 3 路 AD 采样上有个硬件滤波电容偏小的问题。同样的PLC 代码生成这几年也热闹过一阵大家想让 AI 根据时序逻辑自动生成梯形图或结构化文本。实测下来纯逻辑控制的部分确实能省不少事但一旦涉及传感器故障诊断、安全联锁、设备的异常恢复流程AI 就容易“想当然”。因为这些领域的安全规范和边界条件通常散落在各种手册、老师傅的经验和现场调试记录里线上文本里根本没那么多高质量语料。所以说AI 真正越过不去的坎不是“不知道怎么生成代码”而是“不知道怎么和物理世界、历史包袱、组织协作打交道”。这些靠的是集成测试、联调、现场调试靠的是人类对约束条件的深刻理解。4. 测试与调试AI 生成测试容易定义“正确行为”很难做了这么多年开发我越来越觉得测试这件事的本质是把“预期行为”表达清楚。以前写单测是在表达现在让 AI 写单测也是在表达。差别在于AI 能帮你不费吹灰之力生成一百个用力的测试用例框架但那个“预期行为”得靠人来给。4.1 让 AI 生成测试的前提是你能说清“正确”我曾经试过让 AI 给一个促销计算模块写单测。它给了 20 多个用例覆盖了正常折扣、满减、优惠券叠加看起来覆盖率还挺高。结果一审查发现它测的“正确”只是它自己代码实现里的“正确”而不是需求文档里的“正确”。比如需求里明确规定“优惠券抵扣金额不能超过订单金额的 30%”AI 带的测试里完全没有这个断言因为它从代码里看不出来这种业务规则。要解决这个问题我现在的做法是先写测试描述再写实现。不是传统意义上的 TDD而是把测试用例的“业务场景”用大白话写成清单再让 AI 根据清单生成测试代码和实现代码。这相当于我们先把“已知的正确行为”锁死再让 AI 在边界内发挥。如果需求变了那就回去改清单让 AI 重新生成实现。这套流程走下来代码质量和需求一致性明显好很多。4.2 调试瓶颈AI 缺的是上下文不是推理能力还有调试。现在 AI 可以帮你解释报错、分析堆栈但它没办法直接看到你的系统状态。你问它“线上订单超时怎么办”它只能给你一些通用排查建议。真正的调试瓶颈在于你你能不能把系统当时的输入、状态、日志、调用链路组织成一段足够清晰的背景信息交给 AI。这又回到了信息差的问题。所以我现在写代码时会刻意把日志打得比过去更完整。入口参数、关键分支判断、外部调用耗时统统保留。一方面是为了自己排查方便另一方面也是为了让 AI 能在“足够多上下文”的情况下帮我分析问题。没有日志和可观测性数据AI 的调试能力就是空中楼阁。我的经验是系统可观测性做得越好AI 能帮上忙的地方就越多调试这一环才不会成为新的瓶颈。5. 团队协作与知识传递最贵的不是代码是对齐AI 让个体产能差距变小了。以前一个“能写出高质量代码”的程序员和一个普通程序员产出能差好几倍。现在有了 AI 辅助普通程序员也能在短时间内生成大量能跑的代码。那么团队里的竞争力开始从“写代码的能力”转向“对齐的能力”和“知识传递的效率”。5.1 代码 review 的文化比任何时候都重要当 AI 生成的代码大量涌入代码库如果 review 机制跟不上技术债就会像滚雪球一样越滚越大。我见过一个项目AI 把 80% 的代码写了但没人深度 review结果代码风格五花八门有的用函数式、有的用命令式同样的业务逻辑在三个模块里实现了三遍但边界处理还不一样。最后维护的人崩溃到想推倒重来。我们现在定了一个规矩AI 生成的代码只能走“建议”路径必须由一个熟悉该模块的人类工程师 review 通过后才能合入。并且 review 意见里必须写清楚“为什么这里不对”而不是简单一句“优化一下”。这个习惯很笨但能保证知识在人与人之间流动也让 AI 后续生成的代码能越写越符合团队规范。5.2 文档和注释从“可选项”变成“硬需求”以前很多程序员讨厌写文档觉得代码即文档。但 AI 时代文档是提示词上下文的一部分是 AI 理解项目背景的重要依据。一个模块的设计文档、关键接口的说明、常见的坑以前可能只在几个核心开发脑子里现在必须显式地写下来否则 AI 无法引用新人也无法传承。我现在开始要求团队成员每人维护自己负责模块的“README 典型场景 坑位记录”不要求写得多规范但必须真实、具体。用 Claude Code 或者 VSCode AI 插件创建新代码时直接把这份说明贴进上下文它生成的代码贴合度会高得惊人。说白了AI 的能力边界的上限取决于团队知识沉淀的深度。6. 实操建议AI 时代开发者的新核心能力清单聊了这么多瓶颈最后给点实操层面的建议。我把目前感觉最核心的新能力整理成一个清单都是自己踩坑踩出来的希望能帮你们少走几步弯路。6.1 写“能被 AI 高效消费”的需求以前我们写需求描述主要是给人看。现在需求描述的第一读者很可能是 AI。所以我会刻意用结构化的方式写背景、输入、输出、成功标准、异常分支、必须避免什么。比如“做一个导入功能”我会写成背景运营每天需要批量更新商品价格。输入CSV 文件必须校验表头和底色格式。输出导入结果页展示成功条数和失败原因。成功标准支持 5 万条数据在 30 秒内完成校验。异常分支文件格式错误、必填字段为空、价格超过阈值、网络中断。必须避免不要出现部分成功时全部回滚的情况。用这种格式喂给 AI它生成的代码命中率会直线上升。反过来说如果这 6 个部分你自己都写不全那你缺的根本不是 AI 工具而是思路。6.2 建立个人和团队的“AI 审查清单”别信 AI 的“我觉得没问题”。我给自己定了个 review 清单每次都对照着过一遍边界条件空值、超长值、负数、并发冲突资源释放文件句柄、数据库连接、网络连接有没有正确关闭并发安全有没有共享变量被多线程同时写依赖版本生成的代码依赖的库版本跟项目现有环境是否一致日志与监控关键路径有没有留日志安全风险SQL 注入、越权访问、敏感信息硬编码。这套清单看起来基础但真能挡住大部分 AI 生成的“低级问题”。我不追求清单多花哨只追求每个问题都有明确答案。6.3 把 AI 的上下文管理当成第一生产力很多人用 AI 写代码效率不高不是因为 AI 不行而是上下文没给够。我现在用 VSCode 里的 AI 写代码插件绝对不会只丢一句“帮我写一个订单查询接口”。我会先把对应的数据表结构、已有的服务层代码、controller 风格的示例、返回给前端的 VO 结构全都粘进去。整个过程看起来多花了两分钟但生成的代码基本能少改一大半。用 Claude Code 建新项目的时候也是一样。第一步不是让它“创建项目”而是先把项目背景、技术栈、目录结构约定、编码风格要求写在一个 MARKDOWN 里作为 memory 文件之后所有对话都基于这个文件展开。6.4 招聘和学习的侧重也要调整了如果你正在带团队或者还在找工作我强烈建议把考察重点从“能不能手写算法”转向“能不能拆解问题、审查代码、快速学习业务”。现在入门级开发者的门槛确实在降低但高阶开发者的价值反而更大了——因为 AI 写的代码越多能看懂系统、能设计系统、能在关键时刻拍板说“这里不能这样做”的人就越金贵。我自己面试新人时现在会问他一个场景类问题“如果 AI 给了一段看起来都对但你不确定对不对的代码你会怎么验证”回答能说出“补测试、看边界、查文档、问业务方”的我基本都会给高分。这就代表他已经理解了 AI 时代开发的本质。7. 避坑速查表把实战经验直接抄走下面这个表是我这段时间实战下来的一些高频坑和应对方法整理给你们可以直接抄进团队文档里。场景表面现象实际原因应对建议需求模糊时让 AI 写代码生成结果“看起来都能用”AI 猜测了不存在的业务规则先写结构化需求再写代码AI 用了不存在的 API编译或运行时报错训练数据中的过期代码生成后必须跑编译和测试边界条件处理缺失线上数据一多就出 bugAI 默认只覆盖主流程用 review 清单逐项检查并发场景生成错误偶发数据错乱AI 没意识到共享状态强调并发边界写并发测试模块间风格差异大代码库维护困难缺少统一规范上下文建立项目 memory 文件测试断言不符合业务测试全绿但功能错的测试只是“验证自己的实现”先写业务场景清单再生成测试微服务拆分不合理调用链路过长AI 只看到局部调用架构决策必须人工拍板嵌入式代码不达预期硬件行为不符缺乏硬件约束和现场参数把硬件规格和采样特性喂给 AI每一条都是我或身边同事实实在在踩过的坑。AI 是个好工具但它不能替你做价值判断、不能替你跟产品经理确认优先级、不能替你在凌晨三点去排查那一条异常日志背后到底发生了什么。软件开发的瓶颈没有消失它只是从“体力活”转移到了“脑力活”上。最后再分享一点个人的感受。我现在写代码的时间确实少了很多但思考的时间变多了思考需求合不合理、思考边界条件有哪些、思考这段代码会不会连累三个月后的自己。以前我觉得这是“磨刀不误砍柴工”现在我觉得这可能就是 AI 时代软件开发的常态——代码是 AI 写的但软件是你的。