最近总有人问我你现在还写代码吗我说写但不是以前那种写法。以前一个功能模块我能窝在工位上一口气敲几百行方法体修完 bug 还会因为一个缩进不舒服反复调整现在一天下来我亲手敲进编辑器的字符可能只有几十行剩下的大段时间全花在跟 AI 模型对话、写提示词、审代码、拆需求、重构架构这些事上。这话听起来有点凡尔赛但“重构”这两个字在当下确实有了双重含义——它不只是代码层面的重构更是工程师角色的重构。当“生成代码”这件事从人工敲键盘变成 AI 辅助生成的流水线工程师的一天就不再是“写代码的一天”而变成“理解需求、定义规范、审查质量、兜底风险”的一天。这篇文章我想聊聊我自己这两年的实操观察当工程师不再亲手写代码他们的一天到底在做什么。适合正在用 AI 辅助编程工具的开发者、被 AI“卷”到的技术管理者也想给那些刚听说“国内哪个 AI 写代码最强”“AI 写代码怎么设定规则”的朋友一个踏实的视角。1. 角色重构背后的真正变化1.1 为什么“写代码”不再是第一生产力都知道“重构”这个词在软件工程里的经典定义在不改变软件外部行为的前提下改善内部结构让它更容易理解、维护和扩展。现在工程师的角色也在经历一场类似的重构——岗位职责没变还是那批人还是那家公司但“内部结构”全变了。变化的分水岭是 AI 辅助编程工具进入日常开发。以我的团队为例一开始大家只把 AI 当搜索引擎用查个报错、问个语法。直到一次给老系统加报表接口预期两天的活我配合 GitHub Copilot、Codex 这类工具用三个小时就给出了可运行版本从那之后整个团队对“写代码”这件事的定义就开始松动。不是说我就不写代码了而是写代码的边际成本急剧下降。以前一个普通 CRUD 接口从建表、写实体、Mapper、Service 到 Controller一个晚上没了现在这类代码基本是分钟级生成。当“把需求翻译成代码”的成本趋近于零代码行数就不再是衡量产出的核心指标真正稀缺的东西变成了另外三样能说清楚“要什么”的人能判断“生成得好不好”的人能让代码在真实业务里稳定跑起来的人。这三样东西恰好落在“工程师不再写代码”之后的工作内容上。所以角色重构不是 AI 把工程师取代了而是把工程师的工作重心推到价值链的更上游和更下游。1.2 从“打字员”到“技术导演”角色被重塑我把这个过程总结成一句话以前是打字员现在是导演。导演不亲自演戏但要告诉演员演什么、怎么演、演到什么程度算收工。对应到工程师身上台词是提示词分镜是需求拆解剪辑是代码审查和重构。举个具体例子。上个月我们要重构一个订单状态流转模块原来的代码里堆满了 if-else状态一多根本改不动。按老办法我得先把状态图理出来然后手动改实体、改 Service、改测试整套下来三到五天。这次我换了个套路先花半天把需求边界、状态表、迁移策略整理成一份文档然后把“从旧状态机迁移到新状态机”拆成五个子任务每个子任务用 AI 生成第一版代码我再逐个审查、修正、重构。最后真正落到编辑器里的手写代码很少但每一个环节都有我大量的判断。这个过程里的技术含量恰恰不是“会不会写代码”而是“懂不懂业务、懂不懂架构、懂不懂怎么把一个模糊问题变成机器能执行的任务”。这才是角色重构之后工程师的护城河。2. 当工程师不再写代码一天的时间表长什么样很多人一听到“不写代码”就脑补出一整天开会摸鱼的画面实际上完全不是。真实的一天往往排得比写代码还满而且更费脑子。我拿自己一个比较典型的工作日举例。2.1 早晨需求评审与上下文搭建上午九点先开15分钟晨会。现在晨会的内容跟以前很不一样以前是“我昨天写了哪个模块今天继续写”现在是“我昨天用 AI 生成了哪个模块今天准备让 AI 接手哪个模块”。同步的重点从进度变成了信息。接下来花四十分钟做需求评审。比如业务方提了一句“要把支付成功回调的对账逻辑改一下”这句话到我这里就必须变成清晰的技术边界改哪里、不动哪里、依赖哪些表、超时怎么算、幂等怎么保证。如果这些不定清楚后面 AI 生成出来的代码大概率是“看着像那么回事一上线就出事”。晨间最后一件重要的事是给 AI 准备“上下文包”。我自己的经验是AI 辅助编程时代上下文就是新的生产资料。一个任务该用什么语言、什么框架、什么版本涉及哪些已有接口有哪些历史约束都要在动手前整理清楚。我把这些东西按项目放在一个统一的文档目录里每次生成代码前先喂给 AI。这个过程很像做饭前备菜。以前直接开火炒现在得先洗菜、切菜、配好料。备菜枯燥但决定了这道菜的下限。2.2 上午写提示词而不是写函数上午十点开始进入“写代码”环节。但我说的“写”是写提示词。比如团队需要一个“订单超时自动关闭”的服务。老手可能会直接从定时任务框架开始写但现在是先写一段结构化的提示词把问题说清楚。提示词至少包含这些要素项目背景和技术栈、任务描述、输入输出、约束条件、验收标准。我见过太多人上来就写“帮我写个订单超时关闭”AI 也能给你一版但那版通常只有最理想的路径缺乏异常处理和边界判断。你把约束写清楚了它才不敢“想当然”。写好提示词后我会把任务拆成几个小步骤分别让 AI 生成而不是一次性丢给它“帮我写个订单系统”。原因很简单AI 和外包团队一样需求越空返工越多。2.3 下午代码审查与“重构”AI 生成内容下午是我一天里最费精力的时间因为大量 AI 生成的代码会在这个时候涌到我的屏幕上。很多人以为“AI 写得快了人工就轻松了”实际不是。AI 写的代码多了审查的责任反而更重。我审查的重点一般是五条逻辑与需求是否一致特别是边界条件异常处理是否完整很多 AI 生成代码会 catch 后只打一行 log 继续往下跑是否有“幻觉 API”AI 特别喜欢编造不存在的类名或方法名命名是否好读变量名是 a、b 还是 orderId、refundId对后续维护影响巨大是否有过度设计AI 有时会为了“通用性”硬塞一堆抽象接口。这个过程我称之为“重构 AI 的产出”。比如 AI 生成一个大函数我会按团队规范拆成三四个小方法AI 把魔法数字直接写在判断里我会提成常量AI 用多层 if-else 做策略选择我会改成分发器。这个环节本质上是把人类的代码重构能力从“自己造代码”转移到了“修正 AI 代码”。以前重构是在整理自己的债务现在是在给 AI 生成的代码还债。2.4 傍晚工具调优与知识沉淀临近下班还有一类同样重要但经常被忽略的工作沉淀。我把一天里发现的问题记下来尤其是“AI 今天在哪类任务上翻车了”。比如某个版本下 AI 经常生成过时的 API我会进提示词规则库补一条“只允许使用 XX 版本以上的 API”。又比如 AI 生成代码里总忘了处理重试我会更新团队的代码评审清单。同时维护团队的提示词库。我们内部已经积累了一套针对不同业务类型的模板包括“新增接口”“重构存量模块”“编写单元测试”“解释复杂逻辑”等。每次用得好都往里补充。这套东西建起来之后团队的 AI 利用率明显提升因为大家不再从零开始摸索提示词。2.5 一张图总结工程师时间分配的变化工作内容传统工程师角色重构后依赖AI需求理解与澄清10%25%编写代码50%10%AI 交互与提示词设计0%25%代码审查与重构15%30%工具配置与知识沉淀5%10%这只是目测估算但趋势很真实代码编写的时间在压缩判断与沟通的时间在膨胀。如果你发现自己的时间结构正在朝这个方向变化说明你已经进入了角色重构的后半段。3. 核心实操提示词工程与代码重构的关键要点第二章讲的是“一天在做什么”这一章讲“具体怎么做”。不落地的道理都是空话。3.1 第一步不是写提示词而是把需求拆成原子任务我踩过最大的坑就是拿到需求直接丢给 AI效果可想而知。现在我的习惯是任何需求先拆成原子任务。什么叫原子任务就是“输入、输出、边界、依赖、验收一清二楚的小任务”。比如“订单超时关闭”我拆成五个任务定义查询超时订单的 SQL 或接口实现状态变更逻辑接入调度框架补充幂等和重试编写测试。每个任务都能独立生成、独立审查、独立测试。这样做的好处有两点。一是责任清晰哪个环节坏了一目了然二是上下文短AI 不容易“忘事”回答质量明显更高。一次性喂给 AI 一个大型业务模块它会上下文爆掉生成到一半开始胡编。3.2 一套可以直接抄作业的提示词模板给 AI 写提示词我建议按固定结构来团队内用一套模板大家都能少踩坑。下面是我常用的模板骨架【背景】 - 项目商城订单服务Java 17 Spring Boot 3.2 MyBatis-Plus MySQL - 现状已有订单表 order_info状态字段 status0待支付/1已支付/2已取消/3超时关闭 【任务】 实现一个订单超时关闭的批处理任务每5分钟执行一次关闭超过30分钟未支付的订单。 【输入输出】 - 输入无外部参数读取 order_info 表 - 输出更新符合条件的订单状态为3并记录本次处理数量与耗时日志 【约束】 - 不能删除订单只能更新状态 - 同一订单不能被重复关闭需考虑分布式锁或DB原子更新 - 日志必须包含批次号、处理数量、失败原因 - 不得使用全局静态变量 【验收标准】 - 单元测试覆盖正常关闭、已支付跳过、并发重复执行 - 代码风格遵循项目现有规范禁止引入新的大型依赖这段提示词包含了“做什么、不做什么、怎么算对”三要素。实际经验和教训是缺了“约束”和“验收标准”这两块AI 生成的代码基本都要返工。关于“AI 写代码 规则设定 提示词工程”这个热门话题其实核心就是一件事规则要写进提示词里。不要指望 AI 主动替你考虑团队规范你不说它就按最通用的风格来。3.3 代码重构的 AI 协作打法拆完任务、生成代码之后紧接着就是最考验功力的部分把 AI 代码安全地并进老系统。先说结论AI 生成的代码尽量不要直接“全选复制粘贴”到主干。正确流程应该是AI 生成 → 人工阅读理解 → 决定采用/修改/重写 → AI 辅助生成测试 → 小批量合入 → 跑完整回归。这套流程我在重构一个老模块时踩过不少坑最严重的一次是让 AI 帮忙把一个函数重构成策略模式结果它把十几种业务分支直接“优化”成了一堆泛型接口表面上漂亮一跑业务发现丢了两个状态。那次事故让我明白AI 理解不了“业务人味”它擅长语法与结构不擅长企业里那些“说不上来但就是不能动”的逻辑。所以重构时我给团队定了几条铁律重构前必须有存量测试垫底没有测试的老代码先补关键用例再谈重构一次重构只改一个维度要么改结构要么改逻辑别让 AI 同时干两件事AI 重构后逐行阅读重点看它有没有“理所当然”地删掉你以为没用的变量或方法小步提交每步都必须能编译、能跑测试。前阵子跟同行聊“机房重构”“重构版工具箱”这类话题发现大家的焦虑其实一样重构听着高级翻车率也高。而 AI 辅助重构降低了“动手改代码”的门槛却没有降低“理解业务”的门槛。越是 AI 能帮你改结构你越要对业务边界有数。3.4 当 IDE 的代码提示“不配合”时的排查方法和 AI 协作写代码最烦的不是 AI 笨而是 IDE 突然不给提示。具体可以看这几个方向。先说“vscode 写 C 没有代码提示”的情况。大部分人其实是漏装或没启用 C/C 扩展或者工作区里没有正确的编译配置。我给同事的排查顺序是先看扩展是否安装且启用再看文件语言模式是不是 C接着看 IntelliSense 配置的 includePath 是否正确。做完这三步九成以上能恢复。再说“IntelliJ IDEA 写代码时出现黄色高亮占好几行”。这不是报错是编辑器的检查提示通常是警告级问题比如未使用变量、潜在空指针、某些代码风格不符。AI 生成的代码特别喜欢出现这类提示因为它的命名和风格跟你的项目规范未必一致。我的处理办法是逐个看提示内容把“未使用变量”“未检查 null”这类真正影响质量的修掉把纯风格问题交给格式化工具统一处理。黄色高亮不是敌人无视它才是。4. 常见问题与避坑清单这一章整理了我和身边同事这段时间里遇到最频繁的问题按速查表的形式给出。4.1 AI 生成代码的质量问题与应对典型表现根因应对代码看着完整但一跑就错AI“想当然”完成逻辑强制写验收标准并补测试方法名、类名不存在训练语料里的幻觉要求 AI 注明版本并核对文档生成的代码风格与项目不符提示词缺少风格约束在规则里写明“遵循项目现有规范”用大量 if-else 实现策略AI 默认选最通用写法人工重构为策略/状态模式上下文长了之后开始胡编模型上下文窗口有限把大任务拆成原子任务逐个完成4.2 如何评估“国内哪个 AI 写代码最强”“国内哪个 AI 写代码最强”“擅长写代码的 AI 模型”是不少人最关心的问题。我的建议是别只看榜单用你自己的项目做基准测试。具体方法是抽三个典型场景一个是新增接口一个是重构老模块一个是解释一段你没看过的代码。分别用候选工具生成然后按这五个维度打分稳定性同一需求多次生成结果差异大不大代码质量是否遵守约束、异常处理是否完整迭代能力让你不满意时能否顺着对话修正IDE 集成补全、对话、代码操作是否顺手安全合规代码是否上云、数据是否出域、是否能接受。我见过不少人因为某个 AI 在某次演示里惊艳就立刻全员切换过了一周又因为上下文能力不够集体骂娘。选型这事一定要结合自己团队的代码体量和保密要求来测。4.3 如何选择“写代码比较好的智能体”现在很多团队在用“智能体”Agent而不是简单对话模型。智能体的特点是能自己读仓库、改文件、跑命令相当于给 AI 配了手和脚。评估这类智能体“一次性生成能力”反而没那么重要重点是多轮交互的稳定性让它改一个点它会不会顺手改坏别处对仓库的理解能力问它“订单模块的状态定义在哪”能不能准确找到工具调用能力能不能自己查日志、跑测试、读报错可观测性它改了哪些文件、为什么改留没留下痕迹让我审查。我的经验是智能体好用但也要看好。刚开始用的时候务必让它每次改动都生成 diff并且保留审查界面。不然它自己连续改十个文件出问题你根本不知道锅在哪。4.4 新手最容易踩的隐形坑第一个坑是“需求没澄清就开跑”。AI 跑得快是优势也是危险模糊需求生成速度快意味着错误也能快速批量产生。我现在坚持需求文档一句话讲不清的模块绝不交给 AI。第二个坑是“直接合并主干”。哪怕 AI 生成的代码质量看起来很高也应该先放分支、补测试、小步合入。一次大合入出问题时回滚的代价可能比你自己手写还高。第三个坑是“忽略代码审查”。AI 辅助编程时代审查的重要性不降反升。以前审查是挑刺现在审查是把关。没了把关人AI 生成的代码就会像没拧紧的水龙头到处漏水。第四个坑是“以为 AI 能懂上下文”。工程里的“隐性知识”——为什么这个表要加冗余字段、为什么这个状态不能随便改——AI 根本不知道。这些信息必须由工程师主动喂进去。4.5 关于角色焦虑的一点实在话最后想聊聊大家心里都有的焦虑如果 AI 越来越强工程师是不是就失业了我的看法是会被淘汰的不是“会写代码的人”而是“只会写代码的人”。“写代码”只是工程师能力的一个截面围绕代码的还有需求分析、架构设计、技术选型、质量保障、团队协作、系统运维。AI 会把这些环节的“体力活”吃掉但吃掉之后需要有人来定义问题、审查方案、兜底风险。我个人的体会是角色重构不是转行做管理而是把你的编码能力转化成判断力、表达力和把关力。判断力是知道 AI 生成的对不对表达力是把业务需求说清楚把关力是当 AI 和系统都出了状况时有人停下来承担责任。如果你现在刚开始尝试 AI 辅助编程我的建议是别急着追求“生成速度”。先花一周时间练习把你脑海里稀里糊涂的需求写成一个能让 AI 一次就懂的提示词。很多时候 AI 生成质量差不是模型弱是需求没讲清。