1. 这句话从我嘴里说出来之前我其实骂了半年AI我是做后端出身后来带一个十来人的小组负责公司里一块相当“臃肿”的业务系统。那个系统的历史包袱有多重呢光是把需求方常年积压的三十多个优化点理清楚产品经理就排了大约九个月的工作量。大家别笑这种九个月听起来夸张实际在传统企业里太常见了需求要排期、开发要写码、测试要一轮轮回归中间还得穿插各种紧急线上问题能把一个优化专项拖到跨季度几乎是我们这行的常态。所以我第一次看到“9个月的活AI 45分钟做完”这种说法时我的第一反应和大家一样这又是哪个自媒体编的流量标题。过去半年我一直在用各种AI编程工具AI辅助写代码确实能提速但让我相信一个顶级程序员愿意彻底把手从键盘上挪开把一堆老系统的活直接丢给机器我是不信的。直到我们组里一个刚入职的年轻人当着我的面用一套完整的AI工作流把我们规划里一个原本要做两周的模块连代码带测试在四十五分钟里全部生成出来我才意识到问题不在AI在于我一直把AI定位成了“打字加速器”而不是“能独立干活的同事”。那四十五分钟之后我花了整整三天来审查他生成的那批代码。这三天里我一边改一边想明白一件事顶级程序员不再写代码不是说这个人废了而是他把写代码的手速换成了拆任务和把关验收的脑速。这篇文章我想把这次实战的完整过程、踩坑和结论都摊开讲讲重点不是什么神话工具而是告诉你“AI代工”这件事到底哪些环节能信、哪些环节必须自己上以及一个不写代码的程序员日常到底在干什么。2. 为什么一个老项目值得“不写代码”可行性判断才是胜负手那天实习生把两周的活干完以后我们组内很快就产生了一个新话题“是不是所有需求都可以扔给AI”我的答案是绝对不行。我见过太多翻车现场有人把半套核心交易系统丢给智能体生成出来一堆看起来正常、一压测就崩的代码最后返工的时间比自己写还长。所以我一直认为真正拉开差距的不是谁更会用提示词而是谁在开工之前就知道这份活“能不能AI化”。2.1 我评估项目能不能交给AI时只看四个硬条件先给大家一个可以直接拿去用的判断框架。这四个条件是我踩过好几轮坑之后总结出来的基本能筛掉九成不适合AI代工的需求边界是否清楚。模块和外部系统的交互点少不多输入输出有明确约定需求文档里没有大片的“待确认”。结构重复度高。比如CRUD接口、标准报表、类型转化、列表页加表单页这类代码在技术栈里长得很像AI的泛化能力能直接覆盖。有可自动验证的手段。最好有现成的单元测试、接口测试或者静态检查工具能让AI生成完代码后立刻自检而不是靠人肉眼去读。依赖的上下文能被“喂”进去。老项目里那些写在不为人知文档里的潜规则AI并不知道所以前提是这些规则能写进提示或能被它读到对应代码。我那个九个月的专项被我们拆成四十多个独立小任务后真正符合这四个条件的大概占八成。剩下两成比如牵扯到老数据迁移、跨系统一致性补偿方案、历史债务改造我没让AI碰那一部分我坚持自己画架构再让AI填肉。2.2 为什么说“顶级程序员不写代码”不是装腔作势这里我想多说一句。很多人的误区是程序员不写代码等于失业或者等于变成天天写PPT的人。其实你把逻辑倒过来看就顺了一个顶级程序员的稀缺性从来不在于他敲键盘的速度比谁快而在于他知道一个系统“应该长成什么样”。当AI能把代码生成速度拉到分钟级以后这个“知道长成什么样”的本事被急剧放大因为每一个错误判断都会被AI迅速变成几千行需要返工的代码放大你的决策成本。就拿这次专项来说我自己没有动手写一行业务代码。但我在四十五分钟之前做的事情包括把四十多个任务重新拆过一遍、给每个任务规定了交付物的边界、写好了一套供智能体团队协作的上下文规范、还定下了哪些模块之间必须留人类审核断点。这些活儿如果放到半年前我说实话根本不会做这么细因为过去我脑子里想的是“等代码写到一半再调整”。现在不行因为AI跑得太快留给你纠正架构错误的时间窗口真的很短。不写代码不等于不干正事恰恰因为不写代码你才有精力去干那些代码之上、机器还干不了的事。2.3 判断失误的典型反例给想直接复制的朋友提个醒有一次我们小组曾把一个数据清洗脚本直接丢给AI代理那个任务看起来边界异常清晰从一个文件里读取数据做映射转换再写进中间表。AI生成的代码也确实跑通了看起来一切正常。结果上线后一周某张业务表里出现了几百条脏数据因为清洗规则里有一条隐藏的“同环比去重逻辑”只写在三年前的一封邮件里根本不在代码仓库内。后来我花了一个周末写补偿脚本比我自己当初干这份活还累。所以我的建议特别朴素宁可AI少干不可让它瞎干。凡是涉及核心数据、钱、合规和用户隐私的环节哪怕它生成得再快也要留出人工审查的硬断点。这不是对AI不信任是对生产环境的基本敬畏。3. 四十五分钟是怎么榨出来的智能体协作、提示词与人肉检查点现在说重点。那天实习生把两周的活四十五分钟干完其实不是“打开对话框把需求粘进去然后点生成”这么简单。那四十五分钟里他做了一整套工程化调度我个人把它拆解成三个阶段拆包、投喂、收口。3.1 拆包把一个两周的模块切到智能体一次能吃下的尺寸大任务直接丢给大模型对话窗口是现在很多人翻车的头号原因。模型窗口再大也装不下一个老模块的全部上下文强塞进去它生成的代码一定会在某个冷门分支上犯傻。真正有效的方式是先把模块拆成“智能体任务包”每个任务包满足两个要求一是内部逻辑可以被一句目标描述概括二是在代码仓库中有明确的改动范围。我们这次拆出来的任务包大概分三类。纯样板代码类比如标准增删改查接口和基础VO转换每个任务包只涉及两三个文件业务规则类比如计算回款周期、订单状态流转判断这种任务包必须把业务规则逐条写在提示词里并且要求AI生成对应单元测试跨文件联动类比如一个功能涉及前端接口调用、后端服务方法和数据库映射三层改动这种任务包我会额外给AI提供三份上下文文件路径并明确要求它先读再写。这里有个小经验任务包越小AI出错率越低但你拆包和验收的精力成本越高。我试下来觉得单次任务包最好控制在一个智能体能在五分钟内完成“读代码生成自测”的体量。太碎的话验收光靠人看也能看花眼太大又容易失控。大家可以根据自己项目的复杂度微调但原则是这个让AI以“小步快跑”的方式干活人只盯每次小步的结果。3.2 投喂一套可以让AI代码质量稳定的提示词结构很多朋友问我有没有所谓的“AI编程提示词”技巧。我水平有限不会变出什么魔法但有一套结构比较稳定基本每次都有效。我把它叫作“三段式任务卡”角色与环境。开篇告诉AI它是什么角色、在哪个技术栈里干活。例如“你现在是一名具备spring boot开发经验的中级工程师项目基于Java 17和MyBatis代码仓库路径为src/main/java下的bill模块。请严格遵循项目内已有的编码规范包括Lombok使用、统一返回结构、异常处理方式。”目标与约束。说清楚这个任务包要实现什么、不要做什么。比如“实现账单列表分页查询接口入参包括页码、页大小、账单类型、起止日期字段校验规则按BillQuery中已有的注解为准。不要修改BillServiceImpl以外的文件不要引入新的依赖不要改动数据库表结构。”验收方式。让AI知道它干完活以后会被怎么检查。比如“完成后请自查接口返回结构是否符合ApiResponse约定是否为新增代码补充单元测试请运行mvn test -DtestBillServiceTest并通过全部用例。在回复里列出你修改的文件清单和运行结果。”这第三点特别关键。很多AI生成代码一跑就报错不是因为它代码写得烂而是因为它的工作目标里根本没有“通过测试”这一项它默认只要写完就算完。你把验收方式前置等于在它脑子里装了一个质检开关。3.3 收口人肉检查点到底放在哪里才不会被无效界面的AI骗过去我前面反复讲“人肉检查点”这个概念落到实操里说白了就是你要在几个关键位置强制自己看一眼代码不能全交给AI自测。我一般设三道第一道是任务包里涉及数据库查询或状态流转的代码我会逐行看因为AI对业务状态的理解经常是“想当然”。第二道是所有对外接口的参数校验逻辑这部分如果漏了校验线上容易吃大亏。第三道是涉及金额计算的地方我不仅看代码还会拿边界样例数据跑一遍比如0元账单、大额跨天账单、重复回调这些场景AI生成的测试用例往往覆盖不到。剩下的那些样板代码比如实体类字段映射、简单的CRUD、页面表格列配置我反而不怎么看细节只要编译通过、测试通过、代码风格一致就行。这样做的好处是我的复盘时间能集中在真正值得人判断的地方而不是把四十五分钟省下的时间又浪费在逐行读模板代码上。4. 返工账单机器写出90%的代码剩下的10%是人审出来的标题说了九个月的活AI四十五分钟做完我欠大家一个真实账单。经过这几个月磨合我可以负责任地讲AI生成的代码里按行数算可能有九成能直接用但是按“需要人介入修改的问题数”算这个比例就完全不是这样了。我这里把最典型的几类问题列出来都是实战里揪出来的帮大家提前打个预防针。4.1 最坑的一类AI对业务字段含义的理解偏差为了效率我们给AI投喂了大量的代码仓库上下文它确实能读懂字段名、表名和方法名但很多隐含的业务语义它完全靠猜。举个我们实际遇到的例子账单模块里有两个字段一个叫billStatus一个叫payStatus在代码仓库里看起来都表示“是否支付”但实际业务里billStatus是整张账单的生命周期payStatus只是其中支付环节的状态。AI在生成某个查询接口时把两个字段当成同一个状态去过滤结果查出来的数据明显不对。这种错编辑器不会报编译器不会报测试用例如果没写对场景也不会报只有真正懂业务的人看一眼数据才能发现。所以我现在的规矩是凡是涉及业务状态、金额、时间的过滤条件生成完之后必须做一轮“业务语义走查”让最熟悉这块业务的人逐条对一遍条件。别嫌慢这一步省不得。4.2 让人血压升高的接口幂等与并发处理缺失这个我自己也踩过。AI生成的一个对账触发接口逻辑写得很顺但完全没考虑重复调用的问题。测试环境单线程跑一切正常生产环境调度系统重试一次直接插入了两条对账记录。后来我在每次任务卡里都加了一句硬性约束“如果该接口可能被重复调用请自行加入幂等处理并说明你的幂等实现方式。”有了这条AI翻车概率就低很多了。还有一种情况是并发更新。AI写更新语句时默认用“先查后改”的朴素写法两个请求同时进来就丢更新。这种问题靠AI自己是意识不到的因为它没有系统全局观。我的处理方式是在拆包阶段就把这些“需要并发思维”的任务单独标记成高风险不做全自动生成至少我会手写核心的更新SQL或者悲观锁/乐观锁方案再让AI补周边代码。4.3 隐藏在“测试全绿”背后的假装工作量大家可能会以为AI生成代码最怕的是跑不通其实更隐蔽的是“测试全过但其实是无效测试”。AI非常擅长写那种“测了个寂寞”的用例断言值跟着实现走、Mock掉了所有外部依赖、只测正常路径不测异常分支。有一次我们让AI给一个报表接口写测试它写了一个超大的Mock数据工厂断言报表行数等于Mock行数。看起来覆盖很全但真正跑起来SQL里一个GROUP BY字段写错了测试依然全绿因为Mock层根本没走真实SQL。从那以后我们给AI提了一个明确要求不准用Mock框架代替真实数据库查询涉及SQL的单元测试必须用嵌入式数据库或测试库跑真实语句。这个约束改完之后测试的有效性才算提上来。所以大家看到AI写“测试通过”时先别高兴你得确认它到底验证了什么而不是被那个绿色的对勾安慰到。4.4 我的返工数据统计给同样想“AI代工”的团队一个心理预期我把这几个月二十多个任务包的统计放在了下面。它不是严谨的科研数据但至少反映了真实体感大家心里有个数别拿“四十五分钟做完”去倒推全部工作量表格可以这样看AI从生成到自测确实快得离谱但人审和修边界问题的时间并没有被消灭只是从“写代码”转移到了“盯代码”上。整体算下来我的项目总工期确实压到了原来的三分之一以下这已经是巨大的胜利但“九个月变成四十五分钟”在绝大多数真实项目里是不存在的。建议大家对外宣传或对内汇报时把“AI生成”的时间和“人类验收”的时间分开说这样老板的预期才不会被你自己架到火上烤。5. 当程序员真的“不写代码”之后工作台变成什么样如果说前面几章还在讲工具和方法那这一章我想讲点更虚但更实际的东西心态和习惯。坚持了几个月不写业务代码以后我自己最大的变化不是在工具上而是在每天的时间分配上。过去我的时间是写、改、调、测现在我的时间是审、拆、教、救。这个转变不是一蹴而就的最开始几天我甚至有些焦虑总觉得不敲键盘就没在干活下班前心里空落落的。后来我才想明白这种焦虑来源是把“产出代码”和“产出价值”画了等号。5.1 AI把我的工作从“写代码”挤到了“定标准”现在我每天到公司的第一件事不是打开IDE而是看一眼昨晚AI代理生成的代码审查报告。这个报告我要求智能体统一格式包括改动文件列表、测试结果、它自己标出的“不确定项”。我处理这些报告的时间平均每天一到两个小时。剩下的时间我基本在做三件事把新需求拆成AI能理解的任务包把业务规则用文字或图表写清楚以及在团队成员遇到AI代码翻车时帮他们定位架构性问题。这套流程跑顺后我发现自己变成了团队里的“规则输出者”。以前大家是拿着我的代码范例去模仿现在是拿着我写的任务卡去喂AI。任务卡的质量直接决定了AI生成代码的质量上限。有一回我偷懒把一份需求文档原封不动丢给AI结果它把一句话里的两个歧义点理解反了一个生成的代码跑通一半就开始胡来。后来我发现一份两百字的任务卡如果我能写到让陌生同事都能照着执行那AI基本就能交出一份像样的答卷。这个“标准”的功夫比写代码的功夫更难练也更值钱。5.2 团队里的新人最先学会的是“审代码”而不是“堆代码”我们组里今年来了两个初级开发。放在以前他们的成长路线是先从抄代码开始师傅带你改一两个小需求慢慢再碰核心模块。但用上AI智能体以后新人的成长路径明显变了。我分给他们的第一个任务不是写代码而是让AI生成一个简单模块然后要求他们逐行解释每一段代码的作用再让我追问“为什么”。这个练习做下来他们为了应付我的追问不得不去读仓库里的历史代码和各种注释对系统的理解速度反而比过去填鸭式写代码快很多。当然这种事也有反面教训如果不做“逐行解释”这个动作新人很容易走进“AI生成什么就信什么”的舒适区三个月下来代码能力几乎零成长只会复制粘贴。所以我的建议是AI越强新人越要补底层的代码阅读能力和调试能力。你将来可以不手写每一行代码但你必须有胆量在AI给出一坨垃圾时指着第40行跟它说“这里写错了”。5.3 从我个人的工具箱说起哪些AI编程应用值得留这几个月我试过不少AI编程的辅助工具既有在线对话式的大模型应用也有集成在IDE里的插件还有专职跑任务的智能体。淘汰掉一批花架子之后我留下了两个组合日常写业务代码我用带代码仓库上下文理解能力的智能体开一个专用会话把任务卡贴进去让它跑快速补一段工具函数或者写测试用例我用IDE里的AI插件直接在编辑器里调效率最高。我特别想说一下这个组合的体验。智能体的优势在于它能“自己读代码、自己跑测试”基本是半个结对同事但它的启动成本高不适合处理小问题。IDE插件则相反它就在你手边选中一段代码就能解释、补全、重写但视野只在当前文件缺乏全局把控。把两者分开用代码生成这条路就顺了。很多人问我“国内哪个AI写代码最强”我一直回答别只论模型强弱要先看你的工作流是哪种形态再选哪段流程交给哪个工具。模型是发动机工作流才是底盘发动机再好底盘装错了车开着也不舒服。5.4 还有人问我以后程序员会不会消失我不敢说太远的事但从这次实践看“会写代码的人”大概率不会消失消失的是“只会写代码的人”。因为当AI把编码门槛压得足够低以后需求方会越来越期待一个人具备完整的项目掌控力懂业务、能拆解、会验证、能兜底。这套能力本质还是程序员的核心素养只是它的外显形式不再是敲代码而是指挥AI和验收AI。所以我的态度是积极的大家与其焦虑“AI替代程序员”不如把AI当作一个暴涨的生产力杠杆把自己从代码工人升级成系统负责人。6. 最后再掏心窝子几句这几个月我最大的心得就一条在AI代工这件事上真正烧时间的地方已经从“生产代码”变成了“定义任务、验收结果、兜底风险”。你如果能把这三件事做好就算完全把代码交给了AI项目的核心控制权依然在你手里。反过来如果你只会把需求原样丢给AI然后等着收代码那翻车基本上就是早晚的事。另外给想尝试的朋友一个特别具体的建议先从下一个模块开始用我前面说的“三段式任务卡”和“三道人肉检查点”把它完整跑一遍记录一下时间和返工量。四十五分钟做完九个月的活可能有点夸张但用一周时间做完过去两个月的活是我身边越来越多团队的真实战绩这个数字一点都不夸张。先跑起来再慢慢调。手放在键盘上还是键盘旁边真的没那么重要关键时刻你还能不能看懂代码在干什么才决定你的上限。
不写代码的程序员：AI智能体如何把两周开发压缩到45分钟
1. 这句话从我嘴里说出来之前我其实骂了半年AI我是做后端出身后来带一个十来人的小组负责公司里一块相当“臃肿”的业务系统。那个系统的历史包袱有多重呢光是把需求方常年积压的三十多个优化点理清楚产品经理就排了大约九个月的工作量。大家别笑这种九个月听起来夸张实际在传统企业里太常见了需求要排期、开发要写码、测试要一轮轮回归中间还得穿插各种紧急线上问题能把一个优化专项拖到跨季度几乎是我们这行的常态。所以我第一次看到“9个月的活AI 45分钟做完”这种说法时我的第一反应和大家一样这又是哪个自媒体编的流量标题。过去半年我一直在用各种AI编程工具AI辅助写代码确实能提速但让我相信一个顶级程序员愿意彻底把手从键盘上挪开把一堆老系统的活直接丢给机器我是不信的。直到我们组里一个刚入职的年轻人当着我的面用一套完整的AI工作流把我们规划里一个原本要做两周的模块连代码带测试在四十五分钟里全部生成出来我才意识到问题不在AI在于我一直把AI定位成了“打字加速器”而不是“能独立干活的同事”。那四十五分钟之后我花了整整三天来审查他生成的那批代码。这三天里我一边改一边想明白一件事顶级程序员不再写代码不是说这个人废了而是他把写代码的手速换成了拆任务和把关验收的脑速。这篇文章我想把这次实战的完整过程、踩坑和结论都摊开讲讲重点不是什么神话工具而是告诉你“AI代工”这件事到底哪些环节能信、哪些环节必须自己上以及一个不写代码的程序员日常到底在干什么。2. 为什么一个老项目值得“不写代码”可行性判断才是胜负手那天实习生把两周的活干完以后我们组内很快就产生了一个新话题“是不是所有需求都可以扔给AI”我的答案是绝对不行。我见过太多翻车现场有人把半套核心交易系统丢给智能体生成出来一堆看起来正常、一压测就崩的代码最后返工的时间比自己写还长。所以我一直认为真正拉开差距的不是谁更会用提示词而是谁在开工之前就知道这份活“能不能AI化”。2.1 我评估项目能不能交给AI时只看四个硬条件先给大家一个可以直接拿去用的判断框架。这四个条件是我踩过好几轮坑之后总结出来的基本能筛掉九成不适合AI代工的需求边界是否清楚。模块和外部系统的交互点少不多输入输出有明确约定需求文档里没有大片的“待确认”。结构重复度高。比如CRUD接口、标准报表、类型转化、列表页加表单页这类代码在技术栈里长得很像AI的泛化能力能直接覆盖。有可自动验证的手段。最好有现成的单元测试、接口测试或者静态检查工具能让AI生成完代码后立刻自检而不是靠人肉眼去读。依赖的上下文能被“喂”进去。老项目里那些写在不为人知文档里的潜规则AI并不知道所以前提是这些规则能写进提示或能被它读到对应代码。我那个九个月的专项被我们拆成四十多个独立小任务后真正符合这四个条件的大概占八成。剩下两成比如牵扯到老数据迁移、跨系统一致性补偿方案、历史债务改造我没让AI碰那一部分我坚持自己画架构再让AI填肉。2.2 为什么说“顶级程序员不写代码”不是装腔作势这里我想多说一句。很多人的误区是程序员不写代码等于失业或者等于变成天天写PPT的人。其实你把逻辑倒过来看就顺了一个顶级程序员的稀缺性从来不在于他敲键盘的速度比谁快而在于他知道一个系统“应该长成什么样”。当AI能把代码生成速度拉到分钟级以后这个“知道长成什么样”的本事被急剧放大因为每一个错误判断都会被AI迅速变成几千行需要返工的代码放大你的决策成本。就拿这次专项来说我自己没有动手写一行业务代码。但我在四十五分钟之前做的事情包括把四十多个任务重新拆过一遍、给每个任务规定了交付物的边界、写好了一套供智能体团队协作的上下文规范、还定下了哪些模块之间必须留人类审核断点。这些活儿如果放到半年前我说实话根本不会做这么细因为过去我脑子里想的是“等代码写到一半再调整”。现在不行因为AI跑得太快留给你纠正架构错误的时间窗口真的很短。不写代码不等于不干正事恰恰因为不写代码你才有精力去干那些代码之上、机器还干不了的事。2.3 判断失误的典型反例给想直接复制的朋友提个醒有一次我们小组曾把一个数据清洗脚本直接丢给AI代理那个任务看起来边界异常清晰从一个文件里读取数据做映射转换再写进中间表。AI生成的代码也确实跑通了看起来一切正常。结果上线后一周某张业务表里出现了几百条脏数据因为清洗规则里有一条隐藏的“同环比去重逻辑”只写在三年前的一封邮件里根本不在代码仓库内。后来我花了一个周末写补偿脚本比我自己当初干这份活还累。所以我的建议特别朴素宁可AI少干不可让它瞎干。凡是涉及核心数据、钱、合规和用户隐私的环节哪怕它生成得再快也要留出人工审查的硬断点。这不是对AI不信任是对生产环境的基本敬畏。3. 四十五分钟是怎么榨出来的智能体协作、提示词与人肉检查点现在说重点。那天实习生把两周的活四十五分钟干完其实不是“打开对话框把需求粘进去然后点生成”这么简单。那四十五分钟里他做了一整套工程化调度我个人把它拆解成三个阶段拆包、投喂、收口。3.1 拆包把一个两周的模块切到智能体一次能吃下的尺寸大任务直接丢给大模型对话窗口是现在很多人翻车的头号原因。模型窗口再大也装不下一个老模块的全部上下文强塞进去它生成的代码一定会在某个冷门分支上犯傻。真正有效的方式是先把模块拆成“智能体任务包”每个任务包满足两个要求一是内部逻辑可以被一句目标描述概括二是在代码仓库中有明确的改动范围。我们这次拆出来的任务包大概分三类。纯样板代码类比如标准增删改查接口和基础VO转换每个任务包只涉及两三个文件业务规则类比如计算回款周期、订单状态流转判断这种任务包必须把业务规则逐条写在提示词里并且要求AI生成对应单元测试跨文件联动类比如一个功能涉及前端接口调用、后端服务方法和数据库映射三层改动这种任务包我会额外给AI提供三份上下文文件路径并明确要求它先读再写。这里有个小经验任务包越小AI出错率越低但你拆包和验收的精力成本越高。我试下来觉得单次任务包最好控制在一个智能体能在五分钟内完成“读代码生成自测”的体量。太碎的话验收光靠人看也能看花眼太大又容易失控。大家可以根据自己项目的复杂度微调但原则是这个让AI以“小步快跑”的方式干活人只盯每次小步的结果。3.2 投喂一套可以让AI代码质量稳定的提示词结构很多朋友问我有没有所谓的“AI编程提示词”技巧。我水平有限不会变出什么魔法但有一套结构比较稳定基本每次都有效。我把它叫作“三段式任务卡”角色与环境。开篇告诉AI它是什么角色、在哪个技术栈里干活。例如“你现在是一名具备spring boot开发经验的中级工程师项目基于Java 17和MyBatis代码仓库路径为src/main/java下的bill模块。请严格遵循项目内已有的编码规范包括Lombok使用、统一返回结构、异常处理方式。”目标与约束。说清楚这个任务包要实现什么、不要做什么。比如“实现账单列表分页查询接口入参包括页码、页大小、账单类型、起止日期字段校验规则按BillQuery中已有的注解为准。不要修改BillServiceImpl以外的文件不要引入新的依赖不要改动数据库表结构。”验收方式。让AI知道它干完活以后会被怎么检查。比如“完成后请自查接口返回结构是否符合ApiResponse约定是否为新增代码补充单元测试请运行mvn test -DtestBillServiceTest并通过全部用例。在回复里列出你修改的文件清单和运行结果。”这第三点特别关键。很多AI生成代码一跑就报错不是因为它代码写得烂而是因为它的工作目标里根本没有“通过测试”这一项它默认只要写完就算完。你把验收方式前置等于在它脑子里装了一个质检开关。3.3 收口人肉检查点到底放在哪里才不会被无效界面的AI骗过去我前面反复讲“人肉检查点”这个概念落到实操里说白了就是你要在几个关键位置强制自己看一眼代码不能全交给AI自测。我一般设三道第一道是任务包里涉及数据库查询或状态流转的代码我会逐行看因为AI对业务状态的理解经常是“想当然”。第二道是所有对外接口的参数校验逻辑这部分如果漏了校验线上容易吃大亏。第三道是涉及金额计算的地方我不仅看代码还会拿边界样例数据跑一遍比如0元账单、大额跨天账单、重复回调这些场景AI生成的测试用例往往覆盖不到。剩下的那些样板代码比如实体类字段映射、简单的CRUD、页面表格列配置我反而不怎么看细节只要编译通过、测试通过、代码风格一致就行。这样做的好处是我的复盘时间能集中在真正值得人判断的地方而不是把四十五分钟省下的时间又浪费在逐行读模板代码上。4. 返工账单机器写出90%的代码剩下的10%是人审出来的标题说了九个月的活AI四十五分钟做完我欠大家一个真实账单。经过这几个月磨合我可以负责任地讲AI生成的代码里按行数算可能有九成能直接用但是按“需要人介入修改的问题数”算这个比例就完全不是这样了。我这里把最典型的几类问题列出来都是实战里揪出来的帮大家提前打个预防针。4.1 最坑的一类AI对业务字段含义的理解偏差为了效率我们给AI投喂了大量的代码仓库上下文它确实能读懂字段名、表名和方法名但很多隐含的业务语义它完全靠猜。举个我们实际遇到的例子账单模块里有两个字段一个叫billStatus一个叫payStatus在代码仓库里看起来都表示“是否支付”但实际业务里billStatus是整张账单的生命周期payStatus只是其中支付环节的状态。AI在生成某个查询接口时把两个字段当成同一个状态去过滤结果查出来的数据明显不对。这种错编辑器不会报编译器不会报测试用例如果没写对场景也不会报只有真正懂业务的人看一眼数据才能发现。所以我现在的规矩是凡是涉及业务状态、金额、时间的过滤条件生成完之后必须做一轮“业务语义走查”让最熟悉这块业务的人逐条对一遍条件。别嫌慢这一步省不得。4.2 让人血压升高的接口幂等与并发处理缺失这个我自己也踩过。AI生成的一个对账触发接口逻辑写得很顺但完全没考虑重复调用的问题。测试环境单线程跑一切正常生产环境调度系统重试一次直接插入了两条对账记录。后来我在每次任务卡里都加了一句硬性约束“如果该接口可能被重复调用请自行加入幂等处理并说明你的幂等实现方式。”有了这条AI翻车概率就低很多了。还有一种情况是并发更新。AI写更新语句时默认用“先查后改”的朴素写法两个请求同时进来就丢更新。这种问题靠AI自己是意识不到的因为它没有系统全局观。我的处理方式是在拆包阶段就把这些“需要并发思维”的任务单独标记成高风险不做全自动生成至少我会手写核心的更新SQL或者悲观锁/乐观锁方案再让AI补周边代码。4.3 隐藏在“测试全绿”背后的假装工作量大家可能会以为AI生成代码最怕的是跑不通其实更隐蔽的是“测试全过但其实是无效测试”。AI非常擅长写那种“测了个寂寞”的用例断言值跟着实现走、Mock掉了所有外部依赖、只测正常路径不测异常分支。有一次我们让AI给一个报表接口写测试它写了一个超大的Mock数据工厂断言报表行数等于Mock行数。看起来覆盖很全但真正跑起来SQL里一个GROUP BY字段写错了测试依然全绿因为Mock层根本没走真实SQL。从那以后我们给AI提了一个明确要求不准用Mock框架代替真实数据库查询涉及SQL的单元测试必须用嵌入式数据库或测试库跑真实语句。这个约束改完之后测试的有效性才算提上来。所以大家看到AI写“测试通过”时先别高兴你得确认它到底验证了什么而不是被那个绿色的对勾安慰到。4.4 我的返工数据统计给同样想“AI代工”的团队一个心理预期我把这几个月二十多个任务包的统计放在了下面。它不是严谨的科研数据但至少反映了真实体感大家心里有个数别拿“四十五分钟做完”去倒推全部工作量表格可以这样看AI从生成到自测确实快得离谱但人审和修边界问题的时间并没有被消灭只是从“写代码”转移到了“盯代码”上。整体算下来我的项目总工期确实压到了原来的三分之一以下这已经是巨大的胜利但“九个月变成四十五分钟”在绝大多数真实项目里是不存在的。建议大家对外宣传或对内汇报时把“AI生成”的时间和“人类验收”的时间分开说这样老板的预期才不会被你自己架到火上烤。5. 当程序员真的“不写代码”之后工作台变成什么样如果说前面几章还在讲工具和方法那这一章我想讲点更虚但更实际的东西心态和习惯。坚持了几个月不写业务代码以后我自己最大的变化不是在工具上而是在每天的时间分配上。过去我的时间是写、改、调、测现在我的时间是审、拆、教、救。这个转变不是一蹴而就的最开始几天我甚至有些焦虑总觉得不敲键盘就没在干活下班前心里空落落的。后来我才想明白这种焦虑来源是把“产出代码”和“产出价值”画了等号。5.1 AI把我的工作从“写代码”挤到了“定标准”现在我每天到公司的第一件事不是打开IDE而是看一眼昨晚AI代理生成的代码审查报告。这个报告我要求智能体统一格式包括改动文件列表、测试结果、它自己标出的“不确定项”。我处理这些报告的时间平均每天一到两个小时。剩下的时间我基本在做三件事把新需求拆成AI能理解的任务包把业务规则用文字或图表写清楚以及在团队成员遇到AI代码翻车时帮他们定位架构性问题。这套流程跑顺后我发现自己变成了团队里的“规则输出者”。以前大家是拿着我的代码范例去模仿现在是拿着我写的任务卡去喂AI。任务卡的质量直接决定了AI生成代码的质量上限。有一回我偷懒把一份需求文档原封不动丢给AI结果它把一句话里的两个歧义点理解反了一个生成的代码跑通一半就开始胡来。后来我发现一份两百字的任务卡如果我能写到让陌生同事都能照着执行那AI基本就能交出一份像样的答卷。这个“标准”的功夫比写代码的功夫更难练也更值钱。5.2 团队里的新人最先学会的是“审代码”而不是“堆代码”我们组里今年来了两个初级开发。放在以前他们的成长路线是先从抄代码开始师傅带你改一两个小需求慢慢再碰核心模块。但用上AI智能体以后新人的成长路径明显变了。我分给他们的第一个任务不是写代码而是让AI生成一个简单模块然后要求他们逐行解释每一段代码的作用再让我追问“为什么”。这个练习做下来他们为了应付我的追问不得不去读仓库里的历史代码和各种注释对系统的理解速度反而比过去填鸭式写代码快很多。当然这种事也有反面教训如果不做“逐行解释”这个动作新人很容易走进“AI生成什么就信什么”的舒适区三个月下来代码能力几乎零成长只会复制粘贴。所以我的建议是AI越强新人越要补底层的代码阅读能力和调试能力。你将来可以不手写每一行代码但你必须有胆量在AI给出一坨垃圾时指着第40行跟它说“这里写错了”。5.3 从我个人的工具箱说起哪些AI编程应用值得留这几个月我试过不少AI编程的辅助工具既有在线对话式的大模型应用也有集成在IDE里的插件还有专职跑任务的智能体。淘汰掉一批花架子之后我留下了两个组合日常写业务代码我用带代码仓库上下文理解能力的智能体开一个专用会话把任务卡贴进去让它跑快速补一段工具函数或者写测试用例我用IDE里的AI插件直接在编辑器里调效率最高。我特别想说一下这个组合的体验。智能体的优势在于它能“自己读代码、自己跑测试”基本是半个结对同事但它的启动成本高不适合处理小问题。IDE插件则相反它就在你手边选中一段代码就能解释、补全、重写但视野只在当前文件缺乏全局把控。把两者分开用代码生成这条路就顺了。很多人问我“国内哪个AI写代码最强”我一直回答别只论模型强弱要先看你的工作流是哪种形态再选哪段流程交给哪个工具。模型是发动机工作流才是底盘发动机再好底盘装错了车开着也不舒服。5.4 还有人问我以后程序员会不会消失我不敢说太远的事但从这次实践看“会写代码的人”大概率不会消失消失的是“只会写代码的人”。因为当AI把编码门槛压得足够低以后需求方会越来越期待一个人具备完整的项目掌控力懂业务、能拆解、会验证、能兜底。这套能力本质还是程序员的核心素养只是它的外显形式不再是敲代码而是指挥AI和验收AI。所以我的态度是积极的大家与其焦虑“AI替代程序员”不如把AI当作一个暴涨的生产力杠杆把自己从代码工人升级成系统负责人。6. 最后再掏心窝子几句这几个月我最大的心得就一条在AI代工这件事上真正烧时间的地方已经从“生产代码”变成了“定义任务、验收结果、兜底风险”。你如果能把这三件事做好就算完全把代码交给了AI项目的核心控制权依然在你手里。反过来如果你只会把需求原样丢给AI然后等着收代码那翻车基本上就是早晚的事。另外给想尝试的朋友一个特别具体的建议先从下一个模块开始用我前面说的“三段式任务卡”和“三道人肉检查点”把它完整跑一遍记录一下时间和返工量。四十五分钟做完九个月的活可能有点夸张但用一周时间做完过去两个月的活是我身边越来越多团队的真实战绩这个数字一点都不夸张。先跑起来再慢慢调。手放在键盘上还是键盘旁边真的没那么重要关键时刻你还能不能看懂代码在干什么才决定你的上限。