AI Agent时代，程序员从写代码到发指令的范式转移

如果问你最近一个月的工作里纯手动敲代码的时间占了多少很多程序员可能都会愣一下好像真的越来越少了。我自己的情况是自从日程里多了AI Agent这一类工具已经有一部分代码不是我“敲”出来的而是我把需求讲清楚之后它帮我生成、我再来改的。这个变化的本质不是多了一个效率插件而是一次实打实的范式转移——编程工作的重心正从“怎么写”变成“写什么、不写什么、怎么验收”。这篇文章我就结合自己最近做的实际项目拆解一下AI Agent时代编程工作到底变成了什么样包括工作流怎么搭、哪些任务适合交给Agent、Token和上下文怎么管以及我踩过的一些坑。1. 当“写代码”变成“发指令”我工作流里最先发生的变化先说我自己的背景。我写Java和Python将近十年属于那种对IDE快捷键有肌肉记忆的老程序员。去年接了一个内部管理系统升级的需求本身不复杂就是一堆增删改查页面加几个数据报表。按以前的做法这类活基本是固定的Controller、Service、Mapper、前端表单闭着眼睛都能写。但那天我用了AI Agent类工具突然发现一个事——我花在描述需求、拆解任务、验证结果上的时间和真正动手敲代码的时间已经完全不成比例了。这不是说AI把代码全写了而是“写”这个动作本身被压缩了。打个比方你以前是拿笔一笔一画写字现在是对着打字员口述。口述听起来轻松但真要把一段话说清楚、让打字员一次听懂反而比写字更考验脑子。范式转移就是从这种“口述”开始的。1.1 最先消失的不是CRUD而是“已知答案的键盘运动”我把自己的日常编程任务分过类结论是最先被Agent吃掉的一定是那些“结果能被测试锁死、边界清楚、重复度高”的活。典型的有这么几类数据库表的增删改查接口加上配套的前端表单页面对接第三方接口时按文档写请求、签名、响应解析这类胶水代码单元测试、造数脚本、临时数据迁移脚本把一种数据格式转成另一种格式的纯函数逻辑。这类代码有一个共同点它们消耗的是“键盘运动时间”不是判断力。你写的时候脑子里不需要做什么架构决策只是在翻译已经确定好的规则。AI Agent最擅长的恰恰就是这个——规则明确、示例充足、结果可验证。所以“程序员不再写代码”这句话一定要加个注解消失的是机械性的、重复性的写码动作不是编程这个职业本身。真正需要动脑子的那部分依旧牢牢攥在程序员手里。1.2 意图、上下文、验收标准成了范式转移后的三个核心词当写码变成发指令之后我每天反复权衡的其实是三件事意图、上下文、验收标准。意图就是你到底要什么。以前意图藏在代码里你写的函数名、参数类型、注释都是意图的载体。现在你把意图交给Agent必须在提示词里显式说出来否则Agent会非常礼貌地给你生成一段“看起来对实际上和需求差着两层”的代码。上下文是Agent能看到的范围。模型不是你整个代码仓库都能记住它一次只能看有限量的代码这就是后来大家常挂嘴边的Token和上下文窗口问题。你要在有限的上下文里把真正重要的信息喂进去同时把无关噪音过滤掉。验收标准更直接。以前代码靠编译和测试兜底现在Agent生成的代码也得有兜底只是你要么提前把测试写出来要么让它先补测试。这三个词基本决定了AI Agent时代编程的新工作方式后面每一章都绕不开它们。2. 一次真实的Agent驱动开发复盘我用AI Agent写Django项目的完整链路光聊概念没有用我拿最近一个实际项目举例。项目是一个内部工具的后台技术栈是Django加PostgreSQL再加一个简单的网页前端。规模不大但功能链路是完整的用户登录、数据导入、报表查询、权限控制都有。我用AI Agent辅助开发从头走了一遍流程把过程拆给你们看。2.1 从需求到第一版代码我是怎么把需求“翻译”成Agent能听懂的指令我的做法分四步不是一个“把需求丢给它”就完事先写一份“给Agent的需求描述”而不是急着打开终端。这份描述包括项目背景、技术栈、已有目录结构、目标功能、数据模型的大致设计以及“不允许做的事”清单。让Agent先给出项目结构和数据模型我审查实体关系确认模型没问题再让它往下写。每完成一个功能模块立刻让它配套写测试。测试不只是验证代码更是验证它有没有理解我的意图。人工跑一遍核心链路把报错和不符合预期的地方作为下一轮输入的修正上下文回传给Agent。举个例子需求里有一句话“管理员可以看到所有用户导入记录普通用户只能看到自己的。”这种描述不能直接丢给AI因为它涉及会话用户识别、查询集过滤、模板渲染时的显示控制好几层逻辑。我会把它拆成三条明确指令数据模型增加导入记录表字段包括文件名、导入时间、操作用户、导入行数视图层根据当前用户角色返回不同查询集管理员返回全部普通用户只返回自己创建的模板和接口输出都遵循这条规则。拆完之后每条指令Agent都能听明白。而且更重要的是我能预测它会生成什么样的代码这是后续评审的前提——你不能评审一段完全出乎自己意料的东西。2.2 上下文管理是生死线Token不是玄学是硬预算实际跑下来你会发现Agent的能力边界高度依赖上下文管理。这里先解释一个老被提到的词Token。可以把Token理解成模型处理文本时的积木块一个英文单词大约一到两个Token一个中文字大概一到两个Token。模型每次处理请求时能看到的Token总量是有限的以几千或更长为单位。你贴进对话里的代码越多留给模型思考的空间就越小一旦超过窗口上限最早的内容要么被弱化要么被截断。这个项目里我采用的方式是“小步快跑按模块喂上下文”。把项目结构拆成多个小文件每个对话只针对一个模块。比如要改视图层的权限逻辑我就只贴相关的模型文件和视图文件不把整个项目一次性塞进去。因为上下文越精准Agent跑偏的概率越低Token成本也越低。我在这个过程中记过账一个完整Django项目迭代下来大概花了上百轮对话Token消耗不少。但算上我节省下来的手动编码时间整体依然划算。至于哪些项目划算、哪些不划算下一章我说说自己的判断标准。3. 拿Codex这类付费AI编程工具算一笔账哪些任务真的值得交给Agent现在市面上Codex这类付费AI编程工具已经不算便宜了很多人在纠结到底值不值得订阅。我的答案是看你拿它干什么。用对了它能把你的时间成本打下来一截用错了你会发现自己花着钱帮模型调试它自己想象出来的需求。3.1 三类值得交给Agent的任务和实际耗时对比我长期在用的高价值场景有三类直接列个表看得更清楚任务类型手动完成平均耗时Agent辅助后耗时我的使用评价样板接口CRUD加表单半天到一天一到两小时性价比最高省的都是纯体力活非核心脚本数据清洗、批量迁移两三个小时四十分钟左右划算前提是自己要审查逻辑陌生技术栈的参考实现难以预估半小时出参考价值在于快速画出技术边界样板接口不用多说。第二类比如“把几千条JSON数据导入数据库、去重、更新已有记录”的脚本你直接用自然语言描述清楚让它用Python生成一版自己检查一下异常处理分支绝对比从零写快得多。第三类适合“接一个你没用过的框架的登录功能”这种场景AI生成的代码不一定能直接上线但它能帮你把陌生框架的调用路径、关键参数、常见坑提前展出来你再去看文档就有方向感了。3.2 不适合交给Agent的任务它们有一个共同特征不适合的任务也有一个共同特征结果没法快速验证。架构设计、核心模块的并发控制、底层方案选型这类任务AI生成的代码很难通过“跑一遍测试”确认是对的必须靠经验推理、靠取舍判断。如果硬让Agent写最后你很容易陷入“代码能跑但不敢上线”的尴尬局面。我自己的原则是越是贴近业务核心、越是被别人依赖的模块越要保留完整的人工推理痕迹。因为一旦线上出问题团队需要的是一个能讲清楚“当初为什么这么设计”的人而不是一句“AI生成的我不知道”。这种责任Agent目前接不了。4. 范式转移之后程序员的技能栈开始变成“会约束AI”既然编程工作的重心变了技能栈必然跟着变。我观察到一个现象同样用AI Agent有人生成的代码能直接进评审流程有人生成的代码一眼假、还得大改差距不在会不会用工具而在一个新基本功——约束能力。4.1 新基本功不是“会提问”而是“会拆解、会约束、会验证”很多人以为和AI对话就是把需求说得详细一点。实操之后你会发现没那么简单。这更像是和一个能力很强但缺少常识的实习生合作你得明确告诉他边界、格式、禁止假设、依赖的现有代码长什么样。我举一个自己翻过车的例子我让AI写一个导出Excel的功能指令只写了“按条件导出”结果它自己引入一个新依赖还建了一个和我项目里原有导入模块风格完全不同的工具类。代码能跑但放进去之后项目风格直接被劈成两半维护成本反而高了。后来我把指令格式固定成五块任务背景告诉它这个模块在什么项目里、服务什么角色精确目标只写可验证的结果比如“根据筛选条件返回xlsx文件”约束条件明确“不要改其他文件”“不要引入新依赖”“沿用现有代码风格”输入输出格式定义清楚参数和返回结构验收标准粘贴一段测试用例描述让它照着实现。这套东西本质上就是以前我们写项目文档的功底只不过对象从同事变成了模型。文档写作能力正在变成AI Agent时代的核心编程能力。4.2 从“代码评审”到“意图评审”我审AI生成代码的标准变了范式转移带来一个很实际的变化Code Review的重心不一样了。以前我评审看实现细节——变量命名、循环边界、SQL有没有慢查询。现在AI生成的代码我先审的是“意图还原度”这一段代码是不是忠实还原了我的指令有没有偷偷加入指令里没说的行为。AI有时会出于“补全”心理自己加一个它觉得你需要的校验、一次它认为更优雅的重构。这是最危险的。所以我现在的评审习惯是把需求和代码两栏并排看先对意图再看实现。操作上分两层先让Agent自己说明“这次改动了哪些地方、为什么改”我再逐层看关键函数。如果Agent连自己做了什么改动都说不清楚那它生成代码的质量基本就要打个问号。这跟人协作是一样的道理——上来汇报不清的多半没把活干明白。5. 我踩过的AI Agent编程的坑写给正在迁移的人任何工具用起来都有阴影AI Agent编程的坑大多不在明面上。我把自己实际踩过的几个坑总结在这里希望能帮你们少走弯路。5.1 坑一Agent把陈旧代码“优雅化”然后回归测试就红了有一次我让它优化一个遗留模块的查询逻辑指令明确写了“不要动接口签名”。它确实没动签名但它把中间一段复杂的循环改成了高级语法的一行式又顺手把另一个函数的实现重构了理由是“更优雅”。功能看起来等价可那个模块背后有一批依赖内部异常行为的调用方这一“优雅”回归测试直接红了一片。这个坑的本质是AI天然倾向于生成“看起来更好”的代码而生产环境的铁律是“稳定的旧行为比优雅的新写法更值钱”。所以现在只要涉及陈旧模块我指令里的约束写得极其具体不允许动逻辑、只准改指定函数、改动后必须贴出diff。5.2 坑二长上下文里的“隐形遗忘”Token不是内存条第二个坑是在改一个跨模块功能时踩到的。我前几轮对话里明确说过“用户名字段叫username”结果中途贴了一段旧代码进去AI在最后生成的代码里张冠李戴用了一个不存在的字段名。一看就是被后面贴进去的内容带偏了。问题就出在长上下文当材料很多时较早信息会被稀释AI不是真的“忘记”而是注意力被最新的内容带走了于是生成了看似合理、实则对不上的代码。解决办法很简单——关键约定要在每轮对话里重复。我自己现在每次开启新对话都会先加一句“重申”比如“用户表唯一标识是username权限字段叫role不要出现其他命名”。别高估模型的记忆力我们是在和一个记性好但注意力有限的人共事。5.3 怎么设护栏测试先行和差分对比踩过多次坑之后我的护栏策略固定了两条。第一条是测试先行。AI每写一段逻辑我先把对应的测试用例列给它让它照着测试去写实现而不是先写代码再补测试。测试就是验收标准也是你意图的锁。第二条是差分对比。凡是改动现有代码我要求它先给出一份改动前后对比说明每一处变化的原因我再决定是否应用。这个流程看起来多了一步实际省时间——总比你跑完整个测试链路再回头一行行找它改了什么地方要快得多。6. 范式转移没有让程序员失业但让经验换了种方式变现聊完实操回到标题那个问题程序员不再写代码那程序员还剩什么。我的个人判断是范式转移压缩的只是“写”这个动作编程里真正的价值依然在那些AI Agent做不了的事情上判断什么是好代码理解业务背后的模糊和不确定性在成本与风险之间做取舍。以前这些能力靠大量读代码、写代码来沉淀现在它变成了设计约束、审查意图、管理上下文的能力。换句话说你还是那个对系统最终价值负责的人只是手里的工具从锤子换成了施工图。6.1 不同阶段的程序员面对的是不同的变化这个变化对不同阶段的人冲击完全不同。新程序员看到的是好消息入行门槛低了重复编码的需求正在减少一个会拆需求、会写测试的新人借助AI能做出以前两三年经验才能做的功能。但坏消息是天花板也变了如果只会对着AI发指令却看不懂它生成的东西那整体能力反而容易被工具架空。有经验的程序员听到的则是另一个消息经验没有贬值只是变现方式变了。以前经验体现在你能不能在脑子里编译出整段代码现在体现在你有没有能力把一个含混的需求说清楚、有没有能力一眼看穿AI实现里的偏差。这两种能力本质上还是经验只是换了一层皮。6.2 我自己现在的固定流程先写约束再让AI干活最后分享一个我现在逢人就想推荐的固定习惯每次让Agent干活之前我会预留二十分钟把这次要做的意图、约束、验收标准写成几行文档放在项目旁边。起初觉得是多了一道流程实际用下来它帮我把返工量削掉一大半。因为AI Agent时代编程的底层逻辑说到底就是先把问题定义清楚然后让机器飞快地把定义变成现实。当结构化的意图、精准的上下文和明确的验收标准三者都到位的时候代码会越来越像是最不起眼的那个交付物。而程序员的位置更像是那个拿着图纸、盯紧方向的角色。