这两年身边做开发的朋友聊天三句不离 AI有人担心年底绩效有人偷偷在工位上试新工具也有人干脆把简历翻出来看看外面的行情。AI 时代下码农该何去何从这个问题听起来很大落到每天的工作里其实很具体同样一个需求你是自己一行行敲还是让模型先出草稿再花时间审查、补测试、做验证这两种做法短期看只是快慢差别拉长到一年就是能力结构和岗位价值的分水岭。危机、重构、提质增效这三个词不是挂在墙上的口号而是每个开发都要面对的三道现实题。我写这篇内容不是劝谁转行也不是贩卖焦虑。焦虑不值钱能落地的判断才值钱。下面我会把 AI 对开发工作的冲击拆开讲清楚再讲能力结构该怎么重构最后给出一套可以直接照着用的工作流、指标和避坑清单。刚入行的同学可以把它当成学习路线已经带团队的人可以把它当成内部复盘材料做业务开发多年的老手也可以挑自己缺的部分补。所有例子都用虚构场景不涉及具体公司、项目和人物重点是把方法讲透。1. 先把危机看清楚AI 冲击的到底是哪一部分工作1.1 被压缩的不是“写代码”而是“低上下文重复劳动”很多人一说 AI 替代程序员脑子里想的是“机器会写代码了”。这个判断只对了一半。模型确实能写增删改查、能补正则、能生成表单校验、能写简单的单元测试甚至能把一段旧代码翻译成另一种写法。但它写出来的东西建立在它看到的上下文之上。你不给它表结构它就猜字段你不给它业务规则它就按通用常识编你不给它异常场景它就只写 happy path。最后代码能不能用不取决于它写得多快而取决于你有没有能力把问题说清楚、把结果验对。我习惯把这件事类比成装修。模型像一个手脚很快的施工队能刷墙、能铺砖、能按图打柜子但户型怎么改、承重墙能不能动、水电走线合不合理、验收标准是什么还是得有人负责。以前一个开发的价值很大一部分体现在“我会敲这段代码”现在这部分价值被压得很低因为敲代码的门槛下降了。真正被抬高的是另一部分你能不能定义问题能不能判断方案能不能在模型给出十个看似合理的答案时挑出那个真正能上线的。所以危机不是“不会写代码了”而是“只会照着需求写代码”这件事变得危险。低上下文的重复劳动最先被压缩比如样板代码、简单页面、格式转换、常规查询、重复的配置修改。这些东西以前能占掉一天里不少时间现在模型几分钟就能给出一版草稿。问题是草稿越多审查压力越大。如果一个人只会生成、不会审查他的产出会看起来很多实际返工也会很多。真正稀缺的是能把 AI 产出变成可交付结果的人。1.2 三层冲击入口、协作、交付AI 对开发工作的冲击不是单点发生的它会从三个层面同时挤进来。第一层是入口以前遇到问题先搜索、翻文档、看问答社区现在很多人第一反应是打开对话框问模型。第二层是协作代码评审、接口文档、测试用例、故障复盘这些环节都开始出现模型生成的草稿。第三层是交付需求到上线的周期被压缩产品经理和业务方会自然认为“既然有 AI为什么还要排这么久”。这三层叠加起来开发者的工作节奏会被重新定义。工作环节AI 容易接手部分人仍然必须负责的部分风险点需求理解把口语需求整理成条目判断真实目标、优先级、边界把错误理解写得很完整编码实现样板代码、简单逻辑、格式转换核心流程、事务边界、异常策略生成代码看似合理但漏条件测试验证生成用例草稿、造测试数据定义验收标准、判断覆盖是否足够用例多但不测关键风险文档协作接口说明、变更记录初稿确认口径、补充背景和取舍文档与实现不一致上线运维日志分析建议、脚本草稿变更评估、回滚方案、责任判断直接执行高风险脚本这张表不是精确统计而是我实际带项目时的经验判断。你会发现AI 最容易接手的是“有明确输入输出、容错空间较大、错了能很快发现”的环节最难接手的是“目标模糊、牵涉多方、错了代价很高”的环节。危机感应该放在后者而不是放在“它会不会写一个循环”上。把精力花在提升判断力和验证能力上比天天担心被替代有用得多。1.3 影响范围个人、团队、组织三个层面从个人层面看最直接的变化是“中间层工作量”被压缩。所谓中间层就是那些不需要太多业务判断、但又要花时间堆出来的代码和文档。以前一个初级开发可以靠这些工作积累手感、证明产出现在这些工作被模型接走一大半初级开发如果只会等任务、照着做成长速度会明显变慢。反过来愿意主动拆需求、主动写测试、主动做复盘的人会更快接触到完整链路。从团队层面看代码评审的压力会上升。以前评审主要看逻辑和风格现在还要判断“这段代码是不是模型生成的”“生成的部分有没有过时用法”“有没有把敏感配置带进去”。如果团队没有统一的验收标准和评审清单AI 用得多返工也会多。我见过一种很典型的情况每个人都在用模型生成代码但每个人都不愿意细看别人的 diff最后问题堆到测试环境才爆出来排查成本比手写还高。从组织层面看交付节奏和岗位分工会被重新调整。以前需要三个人做两周的功能现在可能两个人一周就能出第一版但上线前的验证、灰度、监控、回滚预案不能省。组织如果只看“出活快”不看“返工少”就会把 AI 当成压工期的工具最后把风险转嫁给一线。真正健康的用法是把省下来的时间投入到需求澄清、自动化测试、监控告警和知识沉淀上而不是立刻塞进下一个需求。1.4 一个现实案例同样需求两种做法假设有一个虚构的“订单查询接口改造”任务需要增加按状态筛选、分页、权限过滤并且不能影响旧接口。A 同学的做法是直接把一句话丢给模型“帮我写一个订单查询接口支持状态筛选和分页。”模型很快给出一大段代码看起来结构完整A 同学复制进项目改了两个字段名就提交了。结果测试环境发现三个问题状态参数传空时查不出数据分页页码从 0 开始还是从 1 开始和前端约定不一致权限过滤只过滤了列表没有过滤导出。返工花了大半天。B 同学的做法是先不写代码而是把验收条件列出来状态为空时返回全部页码从 1 开始每页默认 20最大 100普通用户只能看到自己有权限的订单导出复用同一套过滤条件旧接口字段不变。然后他把表结构、现有接口定义、错误码规范、两个典型请求样例一起给模型让模型先出方案再出 diff最后补测试。模型第一版方案里漏了导出复用B 同学在方案阶段就发现了改起来只花了十分钟。代码生成后他跑了单元测试和接口测试又手工验了空状态、越权、超大数据量三个场景才提交评审。这两个做法的差别不在谁用的模型更强而在谁把“验证”前置了。A 同学把模型当施工队自己当甩手掌柜B 同学把模型当实习生自己当负责人。AI 时代下码农的危机不在于模型会不会写而在于你愿不愿意承担“最后那一公里”的责任。谁能把验收条件说清楚谁就能把 AI 的产出变成自己的产出。2. 重构能力地图码农该补的六块底板2.1 问题定义与需求拆解把“一句话”变成“可验证任务”AI 最怕的不是复杂需求而是模糊需求。你告诉它“做一个好用的搜索”它只能按通用理解给你加个输入框和按钮你告诉它“搜索框支持按名称模糊匹配结果按更新时间倒序每页 20 条无结果时展示空状态输入超过 50 个字符截断”它就能给出更接近可用的东西。问题定义能力本质上就是拆解能力把一个模糊目标拆成输入、处理、输出、异常、约束五部分。我常用的拆法是“四问一表”。四问是谁在用在什么场景用输入从哪来出错时怎么办一表是验收表列出正常场景、边界场景、异常场景、权限场景。比如“导出报表”这个需求表面看只是加一个按钮拆开之后至少涉及筛选条件是否复用列表页、导出数据量上限是多少、超过上限是异步还是拒绝、文件格式是什么、文件名怎么生成、空数据导不导、权限不足怎么提示、失败重试怎么做。这些问题不提前问模型就会替你猜模型一猜返工就来了。需求拆解还有一个好处它能帮你判断哪些工作适合交给 AI。边界清晰、规则明确、可以写测试验证的部分放心交给模型目标模糊、牵涉多方、错了代价高的部分自己先想清楚再动手。你可以把 AI 当成一个反应很快的讨论对象但不要把它当成需求负责人。它不会替你背锅也不会替你判断业务优先级。2.2 代码阅读与系统设计不会读就不会审AI 生成代码越多代码阅读能力越重要。以前一个模块可能是自己写的闭着眼睛都知道逻辑在哪现在一半代码是生成的另一半是前人留下的你要是不会读评审就只能看个热闹。读代码我一般按四条线走从入口函数追调用链从数据表看字段和关系从日志看真实运行路径从异常分支看边界处理。四条线交叉一遍基本能判断这段代码有没有“看起来对、实际跑不通”的问题。系统设计能力也不能丢。模型可以帮你写一个函数但它很难替你判断事务边界、缓存一致性、幂等策略、失败重试这些系统级问题。比如一个扣减库存的操作模型可能给你写出“先查再改”的代码看起来没问题并发一上来就超卖。你要知道这里需要条件更新、需要幂等键、需要考虑失败补偿。再比如分页查询模型可能给你一个limit offset的写法数据量一大就慢你要知道什么时候该用游标、什么时候该加索引、什么时候该限制最大页数。我的建议是每接一个需求至少画一张简单的依赖图这个功能会碰到哪些表、哪些接口、哪些外部服务、哪些定时任务。画图不是为了交差而是为了让自己在让模型生成代码之前知道“改动会影响哪里”。影响范围清楚了提示词里才能写清楚约束约束清楚了模型才不容易写出“局部正确、全局添乱”的代码。2.3 数据与评测意识模型输出不稳定验收必须稳定模型输出有一个特点同样的提示词两次结果可能不一样。这不是坏事但它意味着你不能用“看起来差不多”来验收。你需要一套稳定的评测方式。后端接口用契约测试和接口测试前端页面用关键路径回归和视觉对比数据处理用固定样本集跑前后差异脚本类任务用只读环境先验证。核心思路是把“我觉得对”变成“有证据证明对”。我通常会准备三类样本正常样本、边界样本、脏样本。正常样本证明主流程能跑通边界样本测空值、最大值、临界值脏样本测重复数据、缺失字段、格式不一致。很多 AI 生成的代码正常样本能过边界样本就露馅。比如字符串截断没考虑多字节字符分页没考虑页码越界金额计算没考虑精度时间处理没考虑时区。这些问题不靠“多看两眼”发现靠的是提前准备样本。还有一点很重要不要让模型同时负责“实现”和“验收”。你自己写验收条件或者让另一个模型帮你挑毛病但不能让生成代码的那个上下文自己说“没问题”。这就像让施工队自己验收自己容易漏。比较稳的做法是先生成实现再单独开一个对话把需求、代码、测试结果贴进去让它站在评审角度找风险。两边的结论不一致时优先信测试和人工复核。2.4 工程化与交付能力AI 代码越多护栏越要硬AI 用得多代码变更的频率和体量都会上升工程化能力就成了硬门槛。静态检查、类型检查、单元测试、接口测试、构建流水线、灰度发布、监控告警、回滚预案这些东西平时看着烦关键时刻能救命。模型生成的代码最容易出的问题不是语法错误而是“能编译、能跑通、但不符合项目规范”。比如错误码乱用、日志级别不对、异常被吞掉、配置写死、依赖版本冲突。这些问题靠人眼评审很累靠自动化检查更稳。我自己的做法是把评审清单固化成几条硬规则新增接口必须有请求和响应示例涉及数据库变更必须有回滚脚本涉及权限必须有无权限用例涉及金额和时间必须有边界测试生成代码必须能通过静态检查和单元测试才能提交。规则不要多五到八条就够关键是每次都执行。团队里最怕的是“这次赶进度先放过”放过一次后面就会有第二次。另外AI 生成的代码要控制单次变更量。一次生成三百行评审的人根本看不完一次生成三十到五十行配上测试和说明评审效率高很多。大重构可以拆成多个小提交每个提交只做一件事先改接口契约再改实现再补测试最后清理旧代码。这样即使某一步出问题回滚也容易。AI 让人写得快但上线安全靠的是小步走和可回退。2.5 领域知识与业务理解模型不懂你的“规矩”通用模型懂很多编程知识但它不懂你所在业务的“规矩”。比如审批流里谁能撤销、订单什么状态能退款、库存锁定多久释放、报表口径按签收时间还是支付时间、会员等级变化后历史订单怎么算。这些规则往往不在代码注释里而在业务方脑子里、在历史工单里、在几次事故复盘里。你不懂这些模型生成得再漂亮也不敢上线。领域知识是码农在 AI 时代最实在的护城河之一。因为模型可以学通用语法但很难学你团队三年踩出来的业务规则。你要做的是把这些规则显性化写进需求文档、写进测试用例、写进代码注释、写进评审清单。你越能把业务规则说清楚模型越能帮你干活你越含糊模型越容易替你编。一个开发如果只会写技术代码不关心业务口径他的可替代性会越来越高反过来一个既懂技术又懂业务的人模型只会放大他的效率。我建议每个开发至少维护一份“业务规则笔记”不用很长按模块记录关键规则和变更历史。比如“退款金额不能超过实付金额”“优惠券分摊按商品金额比例”“导出最多十万行超过走异步”。这些东西平时看着琐碎关键时刻能帮你判断模型给的方案靠不靠谱。模型不会主动问你这些你得自己知道。2.6 沟通、写作与知识沉淀会写清楚就是生产力很多人低估了写作在 AI 时代的价值。提示词本质上是写作需求拆解是写作评审意见是写作故障复盘也是写作。你写得越清楚模型越少猜你写得越结构化团队越少来回问。以前写作好是加分项现在写作好是效率工具。一个能把问题写成“背景、目标、约束、验收、风险”五段式的人用同样的模型产出质量会明显高出一截。知识沉淀也一样。AI 可以帮你整理文档但它不知道哪些经验值得沉淀。你要主动记录这个模块为什么这么设计、那次故障根因是什么、这个接口为什么不能缓存、这个配置为什么不能改。把这些东西写下来下次让模型生成代码时直接作为上下文喂进去准确率会高很多。团队里也可以建一个共享的“踩坑记录”不用长篇大论一条问题、一条原因、一条解法就够。时间长了这就是团队自己的知识库。写作还有一个隐藏好处它能逼你把逻辑想清楚。很多需求你觉得懂了一写验收条件就发现漏洞很多方案你觉得可行一写取舍理由就发现站不住。写作不是额外负担它是思考的检查器。AI 时代码农的核心竞争力越来越像“把复杂问题讲清楚并且证明自己的解法是对的”这两件事都离不开写作。3. 把 AI 接进日常开发一套可复用的工作流3.1 任务分层哪些交给 AI哪些自己来用 AI 最怕两种极端一种是什么都自己写效率上不去一种是什么都交给模型质量守不住。我的做法是按风险分层。低风险、边界清晰、容易验证的任务大胆交给模型高风险、边界模糊、验证成本高的任务自己主导模型只做辅助。分层不是为了保守而是为了让精力花在刀刃上。任务类型适合程度原因人工把关点样板代码、重复配置高模式固定容易对比字段名、命名规范、依赖版本简单查询、格式转换高输入输出明确空值、边界值、性能单元测试草稿高可运行验证覆盖关键分支不追求数量文档初稿、变更说明高结构固定可修改口径准确、与实现一致普通业务逻辑中依赖业务规则规则是否完整、异常是否处理核心算法、并发控制中低错一点代价高边界、性能、正确性证明数据迁移、权限改造低影响面大回滚难双人评审、灰度、回滚脚本生产配置、密钥相关低风险高容易泄露不贴敏感信息走安全流程这张表可以按团队情况调整但逻辑不变越靠近核心链路、越难回滚、越涉及数据安全人工把关就要越重。模型不是不能用而是不能“直接上”。你可以让它出方案、出草稿、出测试但最后的判断必须有人负责。责任这东西模型背不了。3.2 上下文准备比提示词更重要的是“喂料”很多人抱怨模型写得不准其实是给的上下文太少。你只给一句“帮我改个接口”它不知道项目用什么框架、错误码怎么定义、日志怎么打、测试怎么写、旧接口有哪些字段不能动。它只能按通用经验编编出来的东西自然要大量修改。想让模型好用先把“料”备齐目标、约束、现有代码、数据结构、错误示例、验收标准、代码风格能给就给。我常用的任务说明模板是这样的不用长篇大论但关键信息不能少任务: 给订单查询接口增加状态筛选和分页 背景: 旧接口仍有调用方字段不能删权限过滤已有公共方法 输入: 状态参数可为空page 从 1 开始page_size 默认 20最大 100 输出: 返回列表、总数、当前页、每页条数错误码沿用现有规范 约束: 不改变旧字段导出复用同一套过滤条件不能全表扫描 验收: 空状态返回全部越权用户看不到无权限数据页码越界返回空列表最大页大小生效这个模板的好处是模型不用猜你的边界。它知道旧接口不能动知道分页参数怎么定知道权限有公共方法知道验收要看哪些场景。你给的信息越具体它生成的代码越接近可评审状态。反过来你给的信息越模糊它越容易给你一个“看起来能用、实际上全是坑”的版本。还有一个小技巧先让模型复述任务。你可以加一句“请先用五条以内复述你理解的目标、约束和验收条件确认后再给方案”。这一步花不了一分钟但能提前发现它理解偏了。很多返工不是因为模型不会写而是因为它一开始就理解错了。先对齐再动手比事后改十遍都省时间。3.3 生成、审查、验证三步不能省我把日常使用 AI 的流程固定成三步生成、审查、验证。生成阶段要求小步一次只做一件事不要一上来就让模型重写整个模块。审查阶段先看方案再看代码重点看边界、异常、权限、性能、命名、依赖。验证阶段必须跑起来静态检查、单元测试、接口测试、手工关键路径能跑的都跑。三步里任何一步偷懒后面都会加倍还回来。生成阶段我一般会要求模型先给“改动计划”包括要改哪些文件、每个文件改什么、为什么这么改、有什么风险。计划确认后再让它出 diff。这样做的好处是你能在代码还没生成时发现方向错误。比如它准备改三个文件但你知道其中一个文件是公共模块不能随便动这时就能及时拦住。直接要代码往往看起来很快实际上把评审压力后移了。审查阶段不要只看“代码像不像”要看“行为对不对”。我通常按这个顺序看输入参数有没有校验空值和越界怎么处理权限有没有过滤事务边界对不对异常有没有被吞日志能不能定位问题旧逻辑有没有被破坏测试有没有覆盖关键分支。这个顺序不是死的但比从头读到尾更有效。模型生成的代码往往结构漂亮问题藏在细节里按风险点查比按行查更快。验证阶段要区分“开发环境能跑”和“可以上线”。开发环境能跑只说明主流程通上线前还要看数据量、并发、超时、重试、回滚。涉及数据库变更的先在只读环境或影子表验证涉及接口变更的先确认旧调用方兼容涉及权限的至少用两种角色各测一遍。验证不是走形式它是你把 AI 产出变成自己产出的最后一道关。3.4 一个接口改造的实操记录还是用虚构的订单查询接口举例。第一步我先读旧代码确认入口、参数、返回结构、权限方法、数据库表。旧接口返回字段里有几个是前端已经在用的不能删权限过滤有一个公共方法但只过滤了主表没有过滤关联表。第二步我写验收条件状态为空返回全部page 从 1 开始page_size 默认 20、最大 100普通用户只能看自己有权限的订单导出复用同一套条件旧字段不变。第三步我把这些信息整理成任务说明让模型先出方案。模型第一版方案里分页用了offset page * page_size这就是典型的“看起来对、实际错”。页码从 1 开始正确写法应该是offset (page - 1) * page_size。它还漏了最大页大小限制权限过滤只加了主表条件。我没有直接让它改代码而是先把这三个问题指出来让它重新出方案。第二版方案补上了偏移量计算、页大小上限、权限过滤复用还主动加了页码越界的处理。到这一步方案才值得进入编码。编码时我要求它只改查询方法和对应的测试不要动控制器和返回结构。生成的 diff 大概四十多行我重点看了几个地方状态参数为空时有没有拼错条件页大小超过 100 时是截断还是报错权限方法传参对不对排序字段有没有走索引返回总数和列表是不是同一次查询条件。然后补了一个简单的测试def test_status_filter_and_pagination(): result query_orders(statuspaid, page1, page_size20) assert result[page] 1 assert result[page_size] 20 assert all(item[status] paid for item in result[items]) def test_page_size_limit(): result query_orders(status, page1, page_size500) assert result[page_size] 100 def test_page_out_of_range(): result query_orders(statuspaid, page9999, page_size20) assert result[items] []测试跑通后我又手工验了空状态、越权用户、页码越界、最大页大小四个场景。最后提交评审时我把方案、diff、测试结果、风险点一起贴上去评审的人不用从头猜十分钟就能看完。这套流程听起来比“直接让模型写”多几步但返工少心里踏实。AI 提效的关键不是生成得多快而是从生成到可上线这条路有多顺。3.5 提示词不是咒语三句式提问法很多人把提示词想得很玄觉得要背一堆模板。其实日常开发用不着那么复杂三句话就够背景一句任务一句验收一句。比如“这是一个旧接口改造旧字段不能删请给查询方法增加状态筛选和分页页码从 1 开始页大小最大 100验收要覆盖空状态、越权、页码越界、最大页大小四个场景”。这三句话给出去模型基本不会跑偏。如果需要它写代码再加一句“先给方案不要直接写代码”。如果需要它审查就说“站在评审角度只列风险和缺失不要夸”。如果需要它写测试就说“按正常、边界、异常、权限四类各给一个用例不要追求数量”。提示词的目标不是让模型显得聪明而是让它的输出更容易被你验证。你越清楚自己要什么越不需要花哨的咒语。还有一个实用习惯把常用的任务说明保存成片段下次改一改就能用。比如接口改造、单元测试、故障复盘、代码评审各存一个模板。模板不用多四五个就够。用的时候把项目-specific 的信息填进去比每次从零想提示词快得多。这件事听起来小但坚持一个月你会发现自己少了很多“说了半天它还是不懂”的烦躁。4. 提质增效的硬指标怎么证明自己不是瞎忙4.1 四个指标交付周期、返工率、缺陷逃逸率、变更失败率提质增效最怕自嗨。生成代码快了不代表交付快了提交多了不代表价值多了。我一般看四个指标交付周期、返工率、缺陷逃逸率、变更失败率。交付周期是从接到明确需求到可上线的时间返工率是评审或测试阶段被打回的比例缺陷逃逸率是上线后才发现的问题比例变更失败率是发布后需要回滚或紧急修复的比例。这四个指标不完美但比“我感觉快了”靠谱。指标看什么怎么记说明交付周期从明确需求到可上线按任务记录开始和完成时间不含需求反复期避免混淆返工率评审或测试打回比例统计打回次数和原因区分需求变更和实现问题缺陷逃逸率上线后发现问题比例按发布批次统计小样本看趋势不追求绝对精确变更失败率回滚或紧急修复比例按发布次数统计高风险变更单独看这些指标不需要搞得很复杂拿个表格每周记一次就行。重点不是数字多漂亮而是看趋势用了 AI 之后交付周期有没有缩短返工率有没有上升上线后问题有没有变多。如果交付快了但返工率翻倍说明省下来的时间又还回去了如果代码量涨了但缺陷逃逸率也涨了说明生成得多、验证得少。指标的作用是帮你发现这种抵消。4.2 度量方法小样本、前后对比、别自欺度量最怕两种自欺一种是只挑成功的任务记失败的假装没发生一种是只记生成时间不记审查和返工时间。我的做法是选同一类任务做前后对比比如连续两周的接口改造记录每个任务从明确需求到可上线的时间、评审打回次数、测试发现问题数。样本不用大十个左右就能看出趋势。记录的时候把“生成时间”和“验证时间”分开你会很容易发现时间到底花在哪。还有一种更简单的办法每天下班前花两分钟记一下今天让模型帮了什么、省了多少时间、后来改了多少。坚持一周你就能知道自己适合把哪些任务交给模型。有人适合用它写测试有人适合用它读旧代码有人适合用它写文档每个人的甜区不一样。别照搬别人的经验用数据找自己的甜区。4.3 反指标代码量、生成行数、对话轮数有些指标看起来热闹其实没意义。比如“今天让模型生成了一千行代码”“今天聊了五十轮对话”“今天提交了二十次”。代码量多不代表价值高可能是重复代码对话轮数多不代表效率高可能是提示词没写清楚提交次数多不代表进度快可能是小修小补。AI 时代最容易掉进的坑就是把“生成量”当成“产出量”。真正值得看的是“有效变更”解决了什么问题、影响了哪些用户、有没有引入新风险、后续维护成本高不高。一个开发如果能让系统少一百行重复代码、少一个定时任务、少一次人工操作他的价值比生成一千行样板代码大得多。提质增效的方向应该是让系统更简单、更稳、更容易维护而不是让代码库变得更臃肿。4.4 团队层面的提质增效标准、评审、沉淀个人用 AI 靠自觉团队用 AI 靠标准。团队至少要统一三件事什么任务可以交给模型生成代码怎么评审出了问题怎么回滚。第一件事避免乱用第二件事避免漏看第三件事避免扩大影响。标准不用写成长篇制度一页纸就够关键是大家都认、都执行。比如“涉及权限、金额、数据迁移的变更必须双人评审”“AI 生成代码必须通过静态检查和单元测试”“生产配置和敏感数据不得粘贴到外部工具”这些规则简单但管用。评审环节可以加一条“生成说明”提交者要写清楚哪些部分是模型生成的、自己做了哪些验证、还有哪些不确定。这不是为了追责而是为了让评审的人知道重点看哪里。全手写的代码和生成代码风险点不一样生成代码里模型容易在边界和异常上偷懒。把风险点标出来评审效率会高很多。知识沉淀也要跟上。每次踩坑记一条问题现象、根因、解法、以后怎么避免。攒上三个月就是团队自己的避坑手册。下次再遇到类似任务直接把手册片段作为上下文喂给模型准确率会明显提高。AI 不会自动积累你团队的经验得有人把经验写下来。这件事看起来慢其实是团队提质增效里回报最高的投入之一。5. 常见误区与排查表5.1 十个高频坑每个都有人踩过第一个坑把模型当搜索引擎。模型会给过时答案也会编不存在的接口涉及版本、配置、命令必须回文档或实际环境验证。第二个坑一次给太大任务。让模型重写整个模块它很难顾全拆成小任务更稳。第三个坑不给上下文。只给一句话模型只能猜猜错是必然。第四个坑不看 diff 直接提交。生成代码再漂亮也要逐行看关键逻辑。第五个坑不跑测试。模型说“应该没问题”不算验证跑起来才算。第六个坑忽略异常分支。模型很容易只写主流程空值、超时、重复提交、权限不足这些要自己补。第七个坑盲目重构。旧代码再丑只要在稳定运行就不要顺手大改要改就单独排期、单独评审。第八个坑复制过时用法。模型训练数据有滞后涉及新版本特性要确认。第九个坑把业务规则交给模型猜。金额、权限、状态流转这些规则必须自己写清楚。第十个坑没有回滚方案。涉及数据和生产配置的变更先想好怎么退。常见问题典型表现排查思路预防办法生成代码跑不通缺依赖、字段名不对先看报错再看 diff最后对接口定义提供完整上下文和示例主流程能跑边界出错空值、越界、重复数据异常补边界样本逐条验验收条件提前写正常、边界、异常用例权限漏过滤列表过滤了详情或导出没过滤按角色走一遍全链路权限变更必须双角色测试性能变差查询变慢、接口超时看执行计划、日志耗时、数据量限制页大小关键字段加索引旧功能被破坏返回字段少了、状态值变了对比旧接口契约跑回归旧字段不动变更前列兼容清单评审看不出问题diff 太大、说明太少拆小提交要求写变更说明单次变更控制在可评审范围这张表可以打印出来贴在工位上遇到问题按行查。很多坑不是技术难题而是流程偷懒。你把流程补上问题会少一大半。5.2 出问题时的排查顺序先复现再读 diff线上或测试出问题最忌讳一上来就猜。我一般按六步走第一步复现确认问题稳定出现还是偶发第二步看 diff最近改了什么有没有可疑提交第三步查输入参数、权限、数据状态对不对第四步查依赖版本、配置、外部服务有没有变第五步加日志定位到具体分支第六步必要时回滚先恢复再分析。这个顺序不新鲜但很管用因为它先控制影响再找根因。AI 生成代码出的问题有两个高发点一是“条件写反”或“边界漏判”二是“旧逻辑被覆盖”。前者靠测试和日志能快速定位后者要靠契约对比和回归。我遇到过一种情况模型改查询方法时顺手把排序字段改了主流程看起来正常但分页第二页开始重复。排查时先看 diff发现排序字段从“创建时间加主键”变成了“创建时间”加上主键后才稳定。这种问题不看 diff 很难想到。回滚也要提前演练。涉及数据库变更的回滚脚本有没有涉及配置的旧配置能不能恢复涉及接口的旧版本能不能兼容这些问题在变更前就要有答案不要等出事再想。AI 让人改得快回滚能力必须跟上否则快就是风险。5.3 团队协作里的三条硬规矩第一条AI 生成代码必须走评审。不管是谁生成的不管看起来多简单只要要合并就按正常流程评审。第二条关键路径必须有人能解释。权限、金额、状态流转、数据迁移这些地方提交者要能说清楚为什么这么改、边界在哪、怎么验证。说不清楚就说明还没真正掌握。第三条敏感信息不进外部工具。密钥、用户数据、内部地址这些不要随手粘贴需要模型帮忙分析时先脱敏或改造成虚构样例。这三条看起来基础但执行起来能挡掉大部分低级事故。团队里最怕的不是不会用 AI而是用了之后没人对结果负责。工具越强越需要规矩。规矩不是限制效率而是让效率可持续。6. 不同阶段的码农怎么走三条现实路径6.1 入门期先学会“验错”再谈“生成”刚入行的同学最容易犯的错是把模型当成“代写作业”。代码是生成了但问他为什么这么写、边界在哪、出错怎么查答不上来。这个阶段最重要的不是学多少框架而是建立“验错”能力能看懂报错、能定位到具体行、能写最小复现、能通过日志判断问题在哪。你越会验错越敢用模型你越不会验错模型越容易把你带沟里。具体怎么做第一基础语法和数据结构要手写一遍不用写到多熟但要知道常见写法。第二每让模型生成一段代码自己加两个测试一个正常一个边界。第三遇到报错先自己读三分钟再去问模型问的时候把报错、代码、输入一起给不要只贴一句“为什么报错”。第四每周挑一段旧代码读试着画出调用链。坚持三个月你的底子会比只刷教程的人扎实。6.2 成长期从“功能实现”转向“系统交付”工作两三年的人最容易卡在“会写功能但扛不了系统”。这个阶段要补的是交付能力需求怎么拆、接口怎么定、数据怎么存、异常怎么处理、上线怎么监控、出问题怎么回滚。AI 可以帮你写代码但交付链路上的判断得你自己来。你越早接触完整链路越早从“码农”变成“工程师”。我建议主动申请做一次完整的小项目从需求澄清到上线复盘全跟一遍。哪怕项目不大也能让你看到很多平时看不到的东西测试环境数据和线上不一样灰度发布要考虑流量比例监控告警要设阈值回滚脚本要提前写。这些经验模型给不了你只能自己趟。趟过一次你再让模型生成代码提示词里就会自然带上“上线约束”而不是只写“实现功能”。6.3 资深期做“问题定义者”和“质量守门人”资深开发的价值在 AI 时代不是写得更快而是定义得更准、守得更牢。你要能判断一个需求值不值得做、一个方案有没有隐患、一次变更会不会影响其他系统。模型可以给你十个方案但选哪个、为什么选、风险怎么兜底得你来。这个阶段的能力更多体现在取舍上性能和数据一致性怎么平衡开发速度和稳定性怎么平衡自研和复用怎么平衡。同时你要做质量守门人。团队里所有人都可以用模型生成代码但关键变更必须有人能兜底。你要建立评审标准、测试标准、回滚标准并且在赶进度的时候守住底线。这不是保守而是对交付负责。AI 让团队跑得更快资深开发的价值就是让团队在快的同时不翻车。6.4 一份 30 天可执行清单如果你不想看太多道理只想照着做可以试试这份 30 天清单。第一周选三个日常任务分别记录“手写用时”和“AI 辅助用时”重点记返工时间不要只记生成时间。第二周给自己常做的任务写三个说明模板接口改造、单元测试、代码评审每个模板包含背景、任务、约束、验收四部分。第三周挑一个旧模块画依赖图找出三个潜在风险点用模型帮你分析但结论自己复核。第四周做一次完整的小变更从方案到上线全流程走一遍最后写一页复盘记录哪里省了时间、哪里返了工、下次怎么改。周次重点动作产出判断标准第 1 周记录三个任务的手写与 AI 辅助用时一张时间对比表能看出时间花在生成还是验证第 2 周写三个任务说明模板三份可复用模板下次同类任务能直接填第 3 周读一个旧模块并画依赖图一张依赖图和三个风险点能说清改动会影响哪里第 4 周完整走一次小变更一页复盘能列出至少两条改进这份清单不复杂关键是执行。做完一个月你会对自己的甜区和风险点有更清楚的认识。别人的经验只能参考自己的记录才靠谱。我自己的习惯是每天下班前留十分钟把当天让模型做的事快速过一遍哪些直接用了哪些改了很多哪些最后没用上。改得多的说明提示词或上下文有问题没用上的说明任务选错了。这个习惯坚持久了你会越来越清楚什么该交给模型什么必须自己来。AI 时代下码农该何去何从答案不在别人的文章里在你每天的选择里你是把模型当替身还是当工具你是只追求生成得快还是追求交付得稳。把验收条件写好把 diff 看仔细把回滚方案备好这三件事做到了工具越强你越稳。 
长河君 · 2026/11/4 3:37:45 · 阅读 1.2k AI时代程序员能力重构：从代码生成到验收交付的提质增效路径
这两年身边做开发的朋友聊天三句不离 AI有人担心年底绩效有人偷偷在工位上试新工具也有人干脆把简历翻出来看看外面的行情。AI 时代下码农该何去何从这个问题听起来很大落到每天的工作里其实很具体同样一个需求你是自己一行行敲还是让模型先出草稿再花时间审查、补测试、做验证这两种做法短期看只是快慢差别拉长到一年就是能力结构和岗位价值的分水岭。危机、重构、提质增效这三个词不是挂在墙上的口号而是每个开发都要面对的三道现实题。我写这篇内容不是劝谁转行也不是贩卖焦虑。焦虑不值钱能落地的判断才值钱。下面我会把 AI 对开发工作的冲击拆开讲清楚再讲能力结构该怎么重构最后给出一套可以直接照着用的工作流、指标和避坑清单。刚入行的同学可以把它当成学习路线已经带团队的人可以把它当成内部复盘材料做业务开发多年的老手也可以挑自己缺的部分补。所有例子都用虚构场景不涉及具体公司、项目和人物重点是把方法讲透。1. 先把危机看清楚AI 冲击的到底是哪一部分工作1.1 被压缩的不是“写代码”而是“低上下文重复劳动”很多人一说 AI 替代程序员脑子里想的是“机器会写代码了”。这个判断只对了一半。模型确实能写增删改查、能补正则、能生成表单校验、能写简单的单元测试甚至能把一段旧代码翻译成另一种写法。但它写出来的东西建立在它看到的上下文之上。你不给它表结构它就猜字段你不给它业务规则它就按通用常识编你不给它异常场景它就只写 happy path。最后代码能不能用不取决于它写得多快而取决于你有没有能力把问题说清楚、把结果验对。我习惯把这件事类比成装修。模型像一个手脚很快的施工队能刷墙、能铺砖、能按图打柜子但户型怎么改、承重墙能不能动、水电走线合不合理、验收标准是什么还是得有人负责。以前一个开发的价值很大一部分体现在“我会敲这段代码”现在这部分价值被压得很低因为敲代码的门槛下降了。真正被抬高的是另一部分你能不能定义问题能不能判断方案能不能在模型给出十个看似合理的答案时挑出那个真正能上线的。所以危机不是“不会写代码了”而是“只会照着需求写代码”这件事变得危险。低上下文的重复劳动最先被压缩比如样板代码、简单页面、格式转换、常规查询、重复的配置修改。这些东西以前能占掉一天里不少时间现在模型几分钟就能给出一版草稿。问题是草稿越多审查压力越大。如果一个人只会生成、不会审查他的产出会看起来很多实际返工也会很多。真正稀缺的是能把 AI 产出变成可交付结果的人。1.2 三层冲击入口、协作、交付AI 对开发工作的冲击不是单点发生的它会从三个层面同时挤进来。第一层是入口以前遇到问题先搜索、翻文档、看问答社区现在很多人第一反应是打开对话框问模型。第二层是协作代码评审、接口文档、测试用例、故障复盘这些环节都开始出现模型生成的草稿。第三层是交付需求到上线的周期被压缩产品经理和业务方会自然认为“既然有 AI为什么还要排这么久”。这三层叠加起来开发者的工作节奏会被重新定义。工作环节AI 容易接手部分人仍然必须负责的部分风险点需求理解把口语需求整理成条目判断真实目标、优先级、边界把错误理解写得很完整编码实现样板代码、简单逻辑、格式转换核心流程、事务边界、异常策略生成代码看似合理但漏条件测试验证生成用例草稿、造测试数据定义验收标准、判断覆盖是否足够用例多但不测关键风险文档协作接口说明、变更记录初稿确认口径、补充背景和取舍文档与实现不一致上线运维日志分析建议、脚本草稿变更评估、回滚方案、责任判断直接执行高风险脚本这张表不是精确统计而是我实际带项目时的经验判断。你会发现AI 最容易接手的是“有明确输入输出、容错空间较大、错了能很快发现”的环节最难接手的是“目标模糊、牵涉多方、错了代价很高”的环节。危机感应该放在后者而不是放在“它会不会写一个循环”上。把精力花在提升判断力和验证能力上比天天担心被替代有用得多。1.3 影响范围个人、团队、组织三个层面从个人层面看最直接的变化是“中间层工作量”被压缩。所谓中间层就是那些不需要太多业务判断、但又要花时间堆出来的代码和文档。以前一个初级开发可以靠这些工作积累手感、证明产出现在这些工作被模型接走一大半初级开发如果只会等任务、照着做成长速度会明显变慢。反过来愿意主动拆需求、主动写测试、主动做复盘的人会更快接触到完整链路。从团队层面看代码评审的压力会上升。以前评审主要看逻辑和风格现在还要判断“这段代码是不是模型生成的”“生成的部分有没有过时用法”“有没有把敏感配置带进去”。如果团队没有统一的验收标准和评审清单AI 用得多返工也会多。我见过一种很典型的情况每个人都在用模型生成代码但每个人都不愿意细看别人的 diff最后问题堆到测试环境才爆出来排查成本比手写还高。从组织层面看交付节奏和岗位分工会被重新调整。以前需要三个人做两周的功能现在可能两个人一周就能出第一版但上线前的验证、灰度、监控、回滚预案不能省。组织如果只看“出活快”不看“返工少”就会把 AI 当成压工期的工具最后把风险转嫁给一线。真正健康的用法是把省下来的时间投入到需求澄清、自动化测试、监控告警和知识沉淀上而不是立刻塞进下一个需求。1.4 一个现实案例同样需求两种做法假设有一个虚构的“订单查询接口改造”任务需要增加按状态筛选、分页、权限过滤并且不能影响旧接口。A 同学的做法是直接把一句话丢给模型“帮我写一个订单查询接口支持状态筛选和分页。”模型很快给出一大段代码看起来结构完整A 同学复制进项目改了两个字段名就提交了。结果测试环境发现三个问题状态参数传空时查不出数据分页页码从 0 开始还是从 1 开始和前端约定不一致权限过滤只过滤了列表没有过滤导出。返工花了大半天。B 同学的做法是先不写代码而是把验收条件列出来状态为空时返回全部页码从 1 开始每页默认 20最大 100普通用户只能看到自己有权限的订单导出复用同一套过滤条件旧接口字段不变。然后他把表结构、现有接口定义、错误码规范、两个典型请求样例一起给模型让模型先出方案再出 diff最后补测试。模型第一版方案里漏了导出复用B 同学在方案阶段就发现了改起来只花了十分钟。代码生成后他跑了单元测试和接口测试又手工验了空状态、越权、超大数据量三个场景才提交评审。这两个做法的差别不在谁用的模型更强而在谁把“验证”前置了。A 同学把模型当施工队自己当甩手掌柜B 同学把模型当实习生自己当负责人。AI 时代下码农的危机不在于模型会不会写而在于你愿不愿意承担“最后那一公里”的责任。谁能把验收条件说清楚谁就能把 AI 的产出变成自己的产出。2. 重构能力地图码农该补的六块底板2.1 问题定义与需求拆解把“一句话”变成“可验证任务”AI 最怕的不是复杂需求而是模糊需求。你告诉它“做一个好用的搜索”它只能按通用理解给你加个输入框和按钮你告诉它“搜索框支持按名称模糊匹配结果按更新时间倒序每页 20 条无结果时展示空状态输入超过 50 个字符截断”它就能给出更接近可用的东西。问题定义能力本质上就是拆解能力把一个模糊目标拆成输入、处理、输出、异常、约束五部分。我常用的拆法是“四问一表”。四问是谁在用在什么场景用输入从哪来出错时怎么办一表是验收表列出正常场景、边界场景、异常场景、权限场景。比如“导出报表”这个需求表面看只是加一个按钮拆开之后至少涉及筛选条件是否复用列表页、导出数据量上限是多少、超过上限是异步还是拒绝、文件格式是什么、文件名怎么生成、空数据导不导、权限不足怎么提示、失败重试怎么做。这些问题不提前问模型就会替你猜模型一猜返工就来了。需求拆解还有一个好处它能帮你判断哪些工作适合交给 AI。边界清晰、规则明确、可以写测试验证的部分放心交给模型目标模糊、牵涉多方、错了代价高的部分自己先想清楚再动手。你可以把 AI 当成一个反应很快的讨论对象但不要把它当成需求负责人。它不会替你背锅也不会替你判断业务优先级。2.2 代码阅读与系统设计不会读就不会审AI 生成代码越多代码阅读能力越重要。以前一个模块可能是自己写的闭着眼睛都知道逻辑在哪现在一半代码是生成的另一半是前人留下的你要是不会读评审就只能看个热闹。读代码我一般按四条线走从入口函数追调用链从数据表看字段和关系从日志看真实运行路径从异常分支看边界处理。四条线交叉一遍基本能判断这段代码有没有“看起来对、实际跑不通”的问题。系统设计能力也不能丢。模型可以帮你写一个函数但它很难替你判断事务边界、缓存一致性、幂等策略、失败重试这些系统级问题。比如一个扣减库存的操作模型可能给你写出“先查再改”的代码看起来没问题并发一上来就超卖。你要知道这里需要条件更新、需要幂等键、需要考虑失败补偿。再比如分页查询模型可能给你一个limit offset的写法数据量一大就慢你要知道什么时候该用游标、什么时候该加索引、什么时候该限制最大页数。我的建议是每接一个需求至少画一张简单的依赖图这个功能会碰到哪些表、哪些接口、哪些外部服务、哪些定时任务。画图不是为了交差而是为了让自己在让模型生成代码之前知道“改动会影响哪里”。影响范围清楚了提示词里才能写清楚约束约束清楚了模型才不容易写出“局部正确、全局添乱”的代码。2.3 数据与评测意识模型输出不稳定验收必须稳定模型输出有一个特点同样的提示词两次结果可能不一样。这不是坏事但它意味着你不能用“看起来差不多”来验收。你需要一套稳定的评测方式。后端接口用契约测试和接口测试前端页面用关键路径回归和视觉对比数据处理用固定样本集跑前后差异脚本类任务用只读环境先验证。核心思路是把“我觉得对”变成“有证据证明对”。我通常会准备三类样本正常样本、边界样本、脏样本。正常样本证明主流程能跑通边界样本测空值、最大值、临界值脏样本测重复数据、缺失字段、格式不一致。很多 AI 生成的代码正常样本能过边界样本就露馅。比如字符串截断没考虑多字节字符分页没考虑页码越界金额计算没考虑精度时间处理没考虑时区。这些问题不靠“多看两眼”发现靠的是提前准备样本。还有一点很重要不要让模型同时负责“实现”和“验收”。你自己写验收条件或者让另一个模型帮你挑毛病但不能让生成代码的那个上下文自己说“没问题”。这就像让施工队自己验收自己容易漏。比较稳的做法是先生成实现再单独开一个对话把需求、代码、测试结果贴进去让它站在评审角度找风险。两边的结论不一致时优先信测试和人工复核。2.4 工程化与交付能力AI 代码越多护栏越要硬AI 用得多代码变更的频率和体量都会上升工程化能力就成了硬门槛。静态检查、类型检查、单元测试、接口测试、构建流水线、灰度发布、监控告警、回滚预案这些东西平时看着烦关键时刻能救命。模型生成的代码最容易出的问题不是语法错误而是“能编译、能跑通、但不符合项目规范”。比如错误码乱用、日志级别不对、异常被吞掉、配置写死、依赖版本冲突。这些问题靠人眼评审很累靠自动化检查更稳。我自己的做法是把评审清单固化成几条硬规则新增接口必须有请求和响应示例涉及数据库变更必须有回滚脚本涉及权限必须有无权限用例涉及金额和时间必须有边界测试生成代码必须能通过静态检查和单元测试才能提交。规则不要多五到八条就够关键是每次都执行。团队里最怕的是“这次赶进度先放过”放过一次后面就会有第二次。另外AI 生成的代码要控制单次变更量。一次生成三百行评审的人根本看不完一次生成三十到五十行配上测试和说明评审效率高很多。大重构可以拆成多个小提交每个提交只做一件事先改接口契约再改实现再补测试最后清理旧代码。这样即使某一步出问题回滚也容易。AI 让人写得快但上线安全靠的是小步走和可回退。2.5 领域知识与业务理解模型不懂你的“规矩”通用模型懂很多编程知识但它不懂你所在业务的“规矩”。比如审批流里谁能撤销、订单什么状态能退款、库存锁定多久释放、报表口径按签收时间还是支付时间、会员等级变化后历史订单怎么算。这些规则往往不在代码注释里而在业务方脑子里、在历史工单里、在几次事故复盘里。你不懂这些模型生成得再漂亮也不敢上线。领域知识是码农在 AI 时代最实在的护城河之一。因为模型可以学通用语法但很难学你团队三年踩出来的业务规则。你要做的是把这些规则显性化写进需求文档、写进测试用例、写进代码注释、写进评审清单。你越能把业务规则说清楚模型越能帮你干活你越含糊模型越容易替你编。一个开发如果只会写技术代码不关心业务口径他的可替代性会越来越高反过来一个既懂技术又懂业务的人模型只会放大他的效率。我建议每个开发至少维护一份“业务规则笔记”不用很长按模块记录关键规则和变更历史。比如“退款金额不能超过实付金额”“优惠券分摊按商品金额比例”“导出最多十万行超过走异步”。这些东西平时看着琐碎关键时刻能帮你判断模型给的方案靠不靠谱。模型不会主动问你这些你得自己知道。2.6 沟通、写作与知识沉淀会写清楚就是生产力很多人低估了写作在 AI 时代的价值。提示词本质上是写作需求拆解是写作评审意见是写作故障复盘也是写作。你写得越清楚模型越少猜你写得越结构化团队越少来回问。以前写作好是加分项现在写作好是效率工具。一个能把问题写成“背景、目标、约束、验收、风险”五段式的人用同样的模型产出质量会明显高出一截。知识沉淀也一样。AI 可以帮你整理文档但它不知道哪些经验值得沉淀。你要主动记录这个模块为什么这么设计、那次故障根因是什么、这个接口为什么不能缓存、这个配置为什么不能改。把这些东西写下来下次让模型生成代码时直接作为上下文喂进去准确率会高很多。团队里也可以建一个共享的“踩坑记录”不用长篇大论一条问题、一条原因、一条解法就够。时间长了这就是团队自己的知识库。写作还有一个隐藏好处它能逼你把逻辑想清楚。很多需求你觉得懂了一写验收条件就发现漏洞很多方案你觉得可行一写取舍理由就发现站不住。写作不是额外负担它是思考的检查器。AI 时代码农的核心竞争力越来越像“把复杂问题讲清楚并且证明自己的解法是对的”这两件事都离不开写作。3. 把 AI 接进日常开发一套可复用的工作流3.1 任务分层哪些交给 AI哪些自己来用 AI 最怕两种极端一种是什么都自己写效率上不去一种是什么都交给模型质量守不住。我的做法是按风险分层。低风险、边界清晰、容易验证的任务大胆交给模型高风险、边界模糊、验证成本高的任务自己主导模型只做辅助。分层不是为了保守而是为了让精力花在刀刃上。任务类型适合程度原因人工把关点样板代码、重复配置高模式固定容易对比字段名、命名规范、依赖版本简单查询、格式转换高输入输出明确空值、边界值、性能单元测试草稿高可运行验证覆盖关键分支不追求数量文档初稿、变更说明高结构固定可修改口径准确、与实现一致普通业务逻辑中依赖业务规则规则是否完整、异常是否处理核心算法、并发控制中低错一点代价高边界、性能、正确性证明数据迁移、权限改造低影响面大回滚难双人评审、灰度、回滚脚本生产配置、密钥相关低风险高容易泄露不贴敏感信息走安全流程这张表可以按团队情况调整但逻辑不变越靠近核心链路、越难回滚、越涉及数据安全人工把关就要越重。模型不是不能用而是不能“直接上”。你可以让它出方案、出草稿、出测试但最后的判断必须有人负责。责任这东西模型背不了。3.2 上下文准备比提示词更重要的是“喂料”很多人抱怨模型写得不准其实是给的上下文太少。你只给一句“帮我改个接口”它不知道项目用什么框架、错误码怎么定义、日志怎么打、测试怎么写、旧接口有哪些字段不能动。它只能按通用经验编编出来的东西自然要大量修改。想让模型好用先把“料”备齐目标、约束、现有代码、数据结构、错误示例、验收标准、代码风格能给就给。我常用的任务说明模板是这样的不用长篇大论但关键信息不能少任务: 给订单查询接口增加状态筛选和分页 背景: 旧接口仍有调用方字段不能删权限过滤已有公共方法 输入: 状态参数可为空page 从 1 开始page_size 默认 20最大 100 输出: 返回列表、总数、当前页、每页条数错误码沿用现有规范 约束: 不改变旧字段导出复用同一套过滤条件不能全表扫描 验收: 空状态返回全部越权用户看不到无权限数据页码越界返回空列表最大页大小生效这个模板的好处是模型不用猜你的边界。它知道旧接口不能动知道分页参数怎么定知道权限有公共方法知道验收要看哪些场景。你给的信息越具体它生成的代码越接近可评审状态。反过来你给的信息越模糊它越容易给你一个“看起来能用、实际上全是坑”的版本。还有一个小技巧先让模型复述任务。你可以加一句“请先用五条以内复述你理解的目标、约束和验收条件确认后再给方案”。这一步花不了一分钟但能提前发现它理解偏了。很多返工不是因为模型不会写而是因为它一开始就理解错了。先对齐再动手比事后改十遍都省时间。3.3 生成、审查、验证三步不能省我把日常使用 AI 的流程固定成三步生成、审查、验证。生成阶段要求小步一次只做一件事不要一上来就让模型重写整个模块。审查阶段先看方案再看代码重点看边界、异常、权限、性能、命名、依赖。验证阶段必须跑起来静态检查、单元测试、接口测试、手工关键路径能跑的都跑。三步里任何一步偷懒后面都会加倍还回来。生成阶段我一般会要求模型先给“改动计划”包括要改哪些文件、每个文件改什么、为什么这么改、有什么风险。计划确认后再让它出 diff。这样做的好处是你能在代码还没生成时发现方向错误。比如它准备改三个文件但你知道其中一个文件是公共模块不能随便动这时就能及时拦住。直接要代码往往看起来很快实际上把评审压力后移了。审查阶段不要只看“代码像不像”要看“行为对不对”。我通常按这个顺序看输入参数有没有校验空值和越界怎么处理权限有没有过滤事务边界对不对异常有没有被吞日志能不能定位问题旧逻辑有没有被破坏测试有没有覆盖关键分支。这个顺序不是死的但比从头读到尾更有效。模型生成的代码往往结构漂亮问题藏在细节里按风险点查比按行查更快。验证阶段要区分“开发环境能跑”和“可以上线”。开发环境能跑只说明主流程通上线前还要看数据量、并发、超时、重试、回滚。涉及数据库变更的先在只读环境或影子表验证涉及接口变更的先确认旧调用方兼容涉及权限的至少用两种角色各测一遍。验证不是走形式它是你把 AI 产出变成自己产出的最后一道关。3.4 一个接口改造的实操记录还是用虚构的订单查询接口举例。第一步我先读旧代码确认入口、参数、返回结构、权限方法、数据库表。旧接口返回字段里有几个是前端已经在用的不能删权限过滤有一个公共方法但只过滤了主表没有过滤关联表。第二步我写验收条件状态为空返回全部page 从 1 开始page_size 默认 20、最大 100普通用户只能看自己有权限的订单导出复用同一套条件旧字段不变。第三步我把这些信息整理成任务说明让模型先出方案。模型第一版方案里分页用了offset page * page_size这就是典型的“看起来对、实际错”。页码从 1 开始正确写法应该是offset (page - 1) * page_size。它还漏了最大页大小限制权限过滤只加了主表条件。我没有直接让它改代码而是先把这三个问题指出来让它重新出方案。第二版方案补上了偏移量计算、页大小上限、权限过滤复用还主动加了页码越界的处理。到这一步方案才值得进入编码。编码时我要求它只改查询方法和对应的测试不要动控制器和返回结构。生成的 diff 大概四十多行我重点看了几个地方状态参数为空时有没有拼错条件页大小超过 100 时是截断还是报错权限方法传参对不对排序字段有没有走索引返回总数和列表是不是同一次查询条件。然后补了一个简单的测试def test_status_filter_and_pagination(): result query_orders(statuspaid, page1, page_size20) assert result[page] 1 assert result[page_size] 20 assert all(item[status] paid for item in result[items]) def test_page_size_limit(): result query_orders(status, page1, page_size500) assert result[page_size] 100 def test_page_out_of_range(): result query_orders(statuspaid, page9999, page_size20) assert result[items] []测试跑通后我又手工验了空状态、越权用户、页码越界、最大页大小四个场景。最后提交评审时我把方案、diff、测试结果、风险点一起贴上去评审的人不用从头猜十分钟就能看完。这套流程听起来比“直接让模型写”多几步但返工少心里踏实。AI 提效的关键不是生成得多快而是从生成到可上线这条路有多顺。3.5 提示词不是咒语三句式提问法很多人把提示词想得很玄觉得要背一堆模板。其实日常开发用不着那么复杂三句话就够背景一句任务一句验收一句。比如“这是一个旧接口改造旧字段不能删请给查询方法增加状态筛选和分页页码从 1 开始页大小最大 100验收要覆盖空状态、越权、页码越界、最大页大小四个场景”。这三句话给出去模型基本不会跑偏。如果需要它写代码再加一句“先给方案不要直接写代码”。如果需要它审查就说“站在评审角度只列风险和缺失不要夸”。如果需要它写测试就说“按正常、边界、异常、权限四类各给一个用例不要追求数量”。提示词的目标不是让模型显得聪明而是让它的输出更容易被你验证。你越清楚自己要什么越不需要花哨的咒语。还有一个实用习惯把常用的任务说明保存成片段下次改一改就能用。比如接口改造、单元测试、故障复盘、代码评审各存一个模板。模板不用多四五个就够。用的时候把项目-specific 的信息填进去比每次从零想提示词快得多。这件事听起来小但坚持一个月你会发现自己少了很多“说了半天它还是不懂”的烦躁。4. 提质增效的硬指标怎么证明自己不是瞎忙4.1 四个指标交付周期、返工率、缺陷逃逸率、变更失败率提质增效最怕自嗨。生成代码快了不代表交付快了提交多了不代表价值多了。我一般看四个指标交付周期、返工率、缺陷逃逸率、变更失败率。交付周期是从接到明确需求到可上线的时间返工率是评审或测试阶段被打回的比例缺陷逃逸率是上线后才发现的问题比例变更失败率是发布后需要回滚或紧急修复的比例。这四个指标不完美但比“我感觉快了”靠谱。指标看什么怎么记说明交付周期从明确需求到可上线按任务记录开始和完成时间不含需求反复期避免混淆返工率评审或测试打回比例统计打回次数和原因区分需求变更和实现问题缺陷逃逸率上线后发现问题比例按发布批次统计小样本看趋势不追求绝对精确变更失败率回滚或紧急修复比例按发布次数统计高风险变更单独看这些指标不需要搞得很复杂拿个表格每周记一次就行。重点不是数字多漂亮而是看趋势用了 AI 之后交付周期有没有缩短返工率有没有上升上线后问题有没有变多。如果交付快了但返工率翻倍说明省下来的时间又还回去了如果代码量涨了但缺陷逃逸率也涨了说明生成得多、验证得少。指标的作用是帮你发现这种抵消。4.2 度量方法小样本、前后对比、别自欺度量最怕两种自欺一种是只挑成功的任务记失败的假装没发生一种是只记生成时间不记审查和返工时间。我的做法是选同一类任务做前后对比比如连续两周的接口改造记录每个任务从明确需求到可上线的时间、评审打回次数、测试发现问题数。样本不用大十个左右就能看出趋势。记录的时候把“生成时间”和“验证时间”分开你会很容易发现时间到底花在哪。还有一种更简单的办法每天下班前花两分钟记一下今天让模型帮了什么、省了多少时间、后来改了多少。坚持一周你就能知道自己适合把哪些任务交给模型。有人适合用它写测试有人适合用它读旧代码有人适合用它写文档每个人的甜区不一样。别照搬别人的经验用数据找自己的甜区。4.3 反指标代码量、生成行数、对话轮数有些指标看起来热闹其实没意义。比如“今天让模型生成了一千行代码”“今天聊了五十轮对话”“今天提交了二十次”。代码量多不代表价值高可能是重复代码对话轮数多不代表效率高可能是提示词没写清楚提交次数多不代表进度快可能是小修小补。AI 时代最容易掉进的坑就是把“生成量”当成“产出量”。真正值得看的是“有效变更”解决了什么问题、影响了哪些用户、有没有引入新风险、后续维护成本高不高。一个开发如果能让系统少一百行重复代码、少一个定时任务、少一次人工操作他的价值比生成一千行样板代码大得多。提质增效的方向应该是让系统更简单、更稳、更容易维护而不是让代码库变得更臃肿。4.4 团队层面的提质增效标准、评审、沉淀个人用 AI 靠自觉团队用 AI 靠标准。团队至少要统一三件事什么任务可以交给模型生成代码怎么评审出了问题怎么回滚。第一件事避免乱用第二件事避免漏看第三件事避免扩大影响。标准不用写成长篇制度一页纸就够关键是大家都认、都执行。比如“涉及权限、金额、数据迁移的变更必须双人评审”“AI 生成代码必须通过静态检查和单元测试”“生产配置和敏感数据不得粘贴到外部工具”这些规则简单但管用。评审环节可以加一条“生成说明”提交者要写清楚哪些部分是模型生成的、自己做了哪些验证、还有哪些不确定。这不是为了追责而是为了让评审的人知道重点看哪里。全手写的代码和生成代码风险点不一样生成代码里模型容易在边界和异常上偷懒。把风险点标出来评审效率会高很多。知识沉淀也要跟上。每次踩坑记一条问题现象、根因、解法、以后怎么避免。攒上三个月就是团队自己的避坑手册。下次再遇到类似任务直接把手册片段作为上下文喂给模型准确率会明显提高。AI 不会自动积累你团队的经验得有人把经验写下来。这件事看起来慢其实是团队提质增效里回报最高的投入之一。5. 常见误区与排查表5.1 十个高频坑每个都有人踩过第一个坑把模型当搜索引擎。模型会给过时答案也会编不存在的接口涉及版本、配置、命令必须回文档或实际环境验证。第二个坑一次给太大任务。让模型重写整个模块它很难顾全拆成小任务更稳。第三个坑不给上下文。只给一句话模型只能猜猜错是必然。第四个坑不看 diff 直接提交。生成代码再漂亮也要逐行看关键逻辑。第五个坑不跑测试。模型说“应该没问题”不算验证跑起来才算。第六个坑忽略异常分支。模型很容易只写主流程空值、超时、重复提交、权限不足这些要自己补。第七个坑盲目重构。旧代码再丑只要在稳定运行就不要顺手大改要改就单独排期、单独评审。第八个坑复制过时用法。模型训练数据有滞后涉及新版本特性要确认。第九个坑把业务规则交给模型猜。金额、权限、状态流转这些规则必须自己写清楚。第十个坑没有回滚方案。涉及数据和生产配置的变更先想好怎么退。常见问题典型表现排查思路预防办法生成代码跑不通缺依赖、字段名不对先看报错再看 diff最后对接口定义提供完整上下文和示例主流程能跑边界出错空值、越界、重复数据异常补边界样本逐条验验收条件提前写正常、边界、异常用例权限漏过滤列表过滤了详情或导出没过滤按角色走一遍全链路权限变更必须双角色测试性能变差查询变慢、接口超时看执行计划、日志耗时、数据量限制页大小关键字段加索引旧功能被破坏返回字段少了、状态值变了对比旧接口契约跑回归旧字段不动变更前列兼容清单评审看不出问题diff 太大、说明太少拆小提交要求写变更说明单次变更控制在可评审范围这张表可以打印出来贴在工位上遇到问题按行查。很多坑不是技术难题而是流程偷懒。你把流程补上问题会少一大半。5.2 出问题时的排查顺序先复现再读 diff线上或测试出问题最忌讳一上来就猜。我一般按六步走第一步复现确认问题稳定出现还是偶发第二步看 diff最近改了什么有没有可疑提交第三步查输入参数、权限、数据状态对不对第四步查依赖版本、配置、外部服务有没有变第五步加日志定位到具体分支第六步必要时回滚先恢复再分析。这个顺序不新鲜但很管用因为它先控制影响再找根因。AI 生成代码出的问题有两个高发点一是“条件写反”或“边界漏判”二是“旧逻辑被覆盖”。前者靠测试和日志能快速定位后者要靠契约对比和回归。我遇到过一种情况模型改查询方法时顺手把排序字段改了主流程看起来正常但分页第二页开始重复。排查时先看 diff发现排序字段从“创建时间加主键”变成了“创建时间”加上主键后才稳定。这种问题不看 diff 很难想到。回滚也要提前演练。涉及数据库变更的回滚脚本有没有涉及配置的旧配置能不能恢复涉及接口的旧版本能不能兼容这些问题在变更前就要有答案不要等出事再想。AI 让人改得快回滚能力必须跟上否则快就是风险。5.3 团队协作里的三条硬规矩第一条AI 生成代码必须走评审。不管是谁生成的不管看起来多简单只要要合并就按正常流程评审。第二条关键路径必须有人能解释。权限、金额、状态流转、数据迁移这些地方提交者要能说清楚为什么这么改、边界在哪、怎么验证。说不清楚就说明还没真正掌握。第三条敏感信息不进外部工具。密钥、用户数据、内部地址这些不要随手粘贴需要模型帮忙分析时先脱敏或改造成虚构样例。这三条看起来基础但执行起来能挡掉大部分低级事故。团队里最怕的不是不会用 AI而是用了之后没人对结果负责。工具越强越需要规矩。规矩不是限制效率而是让效率可持续。6. 不同阶段的码农怎么走三条现实路径6.1 入门期先学会“验错”再谈“生成”刚入行的同学最容易犯的错是把模型当成“代写作业”。代码是生成了但问他为什么这么写、边界在哪、出错怎么查答不上来。这个阶段最重要的不是学多少框架而是建立“验错”能力能看懂报错、能定位到具体行、能写最小复现、能通过日志判断问题在哪。你越会验错越敢用模型你越不会验错模型越容易把你带沟里。具体怎么做第一基础语法和数据结构要手写一遍不用写到多熟但要知道常见写法。第二每让模型生成一段代码自己加两个测试一个正常一个边界。第三遇到报错先自己读三分钟再去问模型问的时候把报错、代码、输入一起给不要只贴一句“为什么报错”。第四每周挑一段旧代码读试着画出调用链。坚持三个月你的底子会比只刷教程的人扎实。6.2 成长期从“功能实现”转向“系统交付”工作两三年的人最容易卡在“会写功能但扛不了系统”。这个阶段要补的是交付能力需求怎么拆、接口怎么定、数据怎么存、异常怎么处理、上线怎么监控、出问题怎么回滚。AI 可以帮你写代码但交付链路上的判断得你自己来。你越早接触完整链路越早从“码农”变成“工程师”。我建议主动申请做一次完整的小项目从需求澄清到上线复盘全跟一遍。哪怕项目不大也能让你看到很多平时看不到的东西测试环境数据和线上不一样灰度发布要考虑流量比例监控告警要设阈值回滚脚本要提前写。这些经验模型给不了你只能自己趟。趟过一次你再让模型生成代码提示词里就会自然带上“上线约束”而不是只写“实现功能”。6.3 资深期做“问题定义者”和“质量守门人”资深开发的价值在 AI 时代不是写得更快而是定义得更准、守得更牢。你要能判断一个需求值不值得做、一个方案有没有隐患、一次变更会不会影响其他系统。模型可以给你十个方案但选哪个、为什么选、风险怎么兜底得你来。这个阶段的能力更多体现在取舍上性能和数据一致性怎么平衡开发速度和稳定性怎么平衡自研和复用怎么平衡。同时你要做质量守门人。团队里所有人都可以用模型生成代码但关键变更必须有人能兜底。你要建立评审标准、测试标准、回滚标准并且在赶进度的时候守住底线。这不是保守而是对交付负责。AI 让团队跑得更快资深开发的价值就是让团队在快的同时不翻车。6.4 一份 30 天可执行清单如果你不想看太多道理只想照着做可以试试这份 30 天清单。第一周选三个日常任务分别记录“手写用时”和“AI 辅助用时”重点记返工时间不要只记生成时间。第二周给自己常做的任务写三个说明模板接口改造、单元测试、代码评审每个模板包含背景、任务、约束、验收四部分。第三周挑一个旧模块画依赖图找出三个潜在风险点用模型帮你分析但结论自己复核。第四周做一次完整的小变更从方案到上线全流程走一遍最后写一页复盘记录哪里省了时间、哪里返了工、下次怎么改。周次重点动作产出判断标准第 1 周记录三个任务的手写与 AI 辅助用时一张时间对比表能看出时间花在生成还是验证第 2 周写三个任务说明模板三份可复用模板下次同类任务能直接填第 3 周读一个旧模块并画依赖图一张依赖图和三个风险点能说清改动会影响哪里第 4 周完整走一次小变更一页复盘能列出至少两条改进这份清单不复杂关键是执行。做完一个月你会对自己的甜区和风险点有更清楚的认识。别人的经验只能参考自己的记录才靠谱。我自己的习惯是每天下班前留十分钟把当天让模型做的事快速过一遍哪些直接用了哪些改了很多哪些最后没用上。改得多的说明提示词或上下文有问题没用上的说明任务选错了。这个习惯坚持久了你会越来越清楚什么该交给模型什么必须自己来。AI 时代下码农该何去何从答案不在别人的文章里在你每天的选择里你是把模型当替身还是当工具你是只追求生成得快还是追求交付得稳。把验收条件写好把 diff 看仔细把回滚方案备好这三件事做到了工具越强你越稳。