Agent 重塑软件工程：从手写代码到定义与验证的范式迁移

1. 当“手写代码”不再是默认选项软件工程的底层假设正在松动DHH 这个名字在 Web 开发圈子里意味着什么不用我多介绍。Rails 框架的缔造者Basecamp 的 CTO一个长期以“少即是多”“约定优于配置”为信条的实践派。他最近关于“手写代码时代落幕、Agent 正在重塑软件工程”的观点在开发者社区里炸开了锅。有人觉得这是危言耸听有人觉得终于有人说出了真相。我自己的判断是这句话如果放在三年前我会当成一句博眼球的标题但放在今天结合我最近半年在几个真实项目里用 Agent 辅助开发的体验我认为它描述的是一个正在发生的结构性变化而不是一个预测。先把话说清楚这里说的“手写代码时代落幕”不是说以后没人写代码了而是说“从零开始逐行手写”将不再是软件工程默认的、唯一的工作方式。就像当年从汇编到高级语言、从手写 SQL 到 ORM每一次抽象层级的抬升都会让一部分人恐慌但最终结果是工程效率的整体跃迁。Agent 带来的变化本质上是把“写代码”这件事从“人逐字逐句构造”变成“人定义意图、Agent 生成候选、人做判断和收敛”。这篇文章我想聊的不是“Agent 会不会取代程序员”这种已经被聊烂的话题而是更具体的东西Agent 到底在软件工程的哪些环节产生了实质性的改变这些改变背后的技术机制是什么作为一个一线开发者我现在实际怎么用 Agent踩过哪些坑以及如果你现在想认真把 Agent 纳入自己的工作流应该从哪里开始、注意什么。适合读这篇的人有实际开发经验、对 Agent 有好奇但还没系统用起来的工程师正在做技术选型、考虑要不要在团队里引入 Agent 工具的技术负责人以及那些听到“Agent 重塑软件工程”觉得是炒作、想看看具体证据的怀疑派。我会尽量用我自己的实操经历和具体场景来说话不堆概念。2. Agent 和“代码补全”根本不是一回事别把它们混为一谈2.1 从补全到执行能力边界的质变很多人第一次接触 Agent 这个概念是从代码补全工具开始的然后下意识地觉得“Agent 不就是更聪明的补全吗”。这个理解偏差会直接导致你用不好 Agent。代码补全的工作模式是你写到一个位置它根据上下文猜你接下来要写什么给你一个 token 序列的建议。它的输入是“当前文件的光标位置和上下文”输出是“一段文本”。它不执行任何东西不验证任何东西不承担任何后果。Agent 的工作模式完全不同。它的输入是“一个目标”输出是“一系列动作的执行结果”。中间它会自己决定读哪些文件、跑什么命令、改哪几行、验证结果对不对、不对就再改。这个差别不是程度上的是性质上的。补全工具是“你开车它帮你看路”Agent 是“你说去哪它开给你看你坐副驾盯着”。我用一个具体场景来说明这个差别。假设我要给一个 Rails 项目加一个“用户导出 CSV”的功能。用补全工具我需要自己新建 controller action、写查询逻辑、引入 CSV 库、处理编码、写测试补全工具在每个环节给我加速。用 Agent我可以直接说“给 User 模型加一个导出 CSV 的接口包含 name、email、created_at 三列要处理中文编码加对应的 request spec”然后它会自己去读项目结构、找到合适的文件位置、写代码、跑测试、根据报错修正。我做的事情从“写”变成了“审”和“定”。2.2 为什么“能执行”这件事如此关键能执行意味着 Agent 有了反馈闭环。这是它和补全工具最本质的区别。补全工具给出的建议对不对只有你运行了才知道反馈回路里必须有人。Agent 可以自己运行、自己看结果、自己修正反馈回路里可以暂时没有人。这个“暂时没有人”就是效率提升的来源也是风险所在。我实测下来一个设计良好的 Agent 在“有明确验证标准”的任务上比如“让这个测试通过”“让这个 lint 规则不再报错”“把这个函数的圈复杂度降到 10 以下”成功率相当高。因为验证标准是机器可判定的Agent 可以自己迭代到满足条件。但在“这个交互设计是否合理”“这个抽象是否过度”这类没有机器可判定标准的问题上Agent 的表现就很一般因为它没有反馈信号。这里有个很实用的判断原则一个任务如果能让 Agent 自己判断“做完了没有”它就适合交给 Agent如果“做完了没有”只有你能判断那 Agent 只能做辅助不能做主导。2.3 Agent 的能力来自哪里模型、工具、循环拆开看一个能工作的 Agent 需要三样东西。第一是一个足够强的模型能理解意图、能做规划、能读懂报错。第二是一组工具通常是文件读写、命令执行、搜索这几类让 Agent 能真正操作环境而不只是“说”。第三是一个循环机制让 Agent 能“行动-观察-再行动”而不是一次性输出。这三样里最容易被低估的是工具的质量。我踩过的一个坑是早期我用一个 Agent 去改一个老项目它总是改错文件因为它搜索文件的方式是模糊匹配项目里有两个同名文件在不同目录它选错了。这不是模型的问题是工具的问题——搜索工具没有给它足够精确的定位能力。后来我换了一个支持精确路径和 glob 模式的工具集同样的问题再没出现过。所以当你评估一个 Agent 工具时不要只看它背后是什么模型要看它的工具集设计得怎么样。工具集决定了 Agent 的“手脚”灵不灵活模型决定了它的“脑子”好不好使两者缺一不可。3. 我在真实项目里用 Agent 的四个场景以及每个场景的边界3.1 场景一存量项目的“考古式”修改这是我认为 Agent 价值最大的场景也是最容易被忽略的场景。什么叫考古式修改就是你要改一个你不太熟的老项目可能是半年前别人写的可能是你自己写的但早忘了。传统做法是先花时间读代码、理清调用链、找到改动点、小心翼翼地改、祈祷不要碰坏别的东西。这个过程可能占掉整个任务 70% 的时间。用 Agent 的做法是把“理清调用链”这件事交给它。我会这样描述任务“这个项目里有一个 Order 模型我要在创建订单时增加一个库存校验如果库存不足就抛异常。先帮我找到订单创建的所有入口列出调用链然后告诉我应该在哪里加校验最合适。”Agent 会去搜索、读文件、梳理然后给我一个带文件路径和行号的报告。这个场景的边界在于Agent 给你的调用链分析你需要验证。它有时候会漏掉动态调用、元编程生成的调用、或者通过字符串拼接的调用。Rails 项目里这种情况特别多比如send、method_missing、各种 DSL。我的习惯是让 Agent 分析完之后自己再 grep 一遍关键方法名确认没有遗漏。3.2 场景二测试驱动的功能开发这是 Agent 表现最稳定的场景。因为测试提供了机器可判定的反馈信号。我的工作流是这样的先自己写测试或者让 Agent 根据需求写测试然后让 Agent 去实现跑到测试全绿为止。具体操作上我会把任务拆成小步。比如“实现一个方法输入是用户 ID 列表输出是这些用户的订单总额按金额降序排列”我会先让 Agent 写测试用例包括空列表、单个用户、多个用户、有用户没有订单这几种情况。然后让它实现。它实现完跑测试如果有失败就自己修。整个过程我基本只需要在最后 review 一下代码质量。这个场景的边界在于测试本身的质量决定了 Agent 输出的质量。如果你的测试写得很水只测了 happy pathAgent 就会给你一个只处理 happy path 的实现。我见过有人抱怨“Agent 写的代码不考虑边界情况”一问才知道他的测试里根本没有边界情况的用例。Agent 不会比你更懂你的业务边界它只会满足你给出的验证标准。3.3 场景三跨文件的重构重构是 Agent 的强项因为重构的本质是“保持行为不变的前提下改变结构”而“行为不变”可以通过测试来验证。我最近做的一个重构是把一个 God Class 拆成三个职责单一的类。这个任务如果手写光是找所有引用点就够头疼的。我的做法是先让 Agent 分析这个类的所有公开方法按职责分组给出拆分方案。我 review 方案后确认然后让它执行拆分。它会自动更新所有引用点、调整 require、跑测试。中间有一次它漏改了一个通过字符串动态调用的地方测试挂了它自己根据报错找到了问题并修复。这个场景的边界在于涉及元编程、反射、动态派发的重构Agent 容易漏。因为这些东西在静态分析层面看不出来。我的经验是重构前先让 Agent 列出项目里所有可能涉及动态调用的地方人工确认一遍再让它动手。3.4 场景四从零搭建原型这是最容易被高估的场景。很多人以为 Agent 最擅长从零开始写新项目实际上恰恰相反。从零开始意味着没有既有约束、没有测试、没有明确的验证标准Agent 很容易给你一个“看起来能跑但结构一塌糊涂”的东西。我现在用 Agent 做原型的做法是先自己定好项目结构和技术选型写好最外层的骨架和几个关键接口的测试然后让 Agent 去填充实现。这样它有约束、有验证标准输出质量会高很多。完全放手让它从零开始我试过几次结果都是“能跑但我宁愿重写”。4. 那些没人告诉你的坑Agent 用起来不顺的真实原因4.1 上下文窗口不是越大越好很多人以为给 Agent 的上下文越多越好把整个项目都塞进去。实测下来这是反效果的。上下文太长会导致两个问题一是模型注意力被稀释关键信息淹没在噪音里二是成本飙升响应变慢。我的做法是分层给上下文。第一层是任务相关的文件精确指定。第二层是项目约定比如代码风格、目录结构说明用一个简短的文档描述。第三层是必要的背景比如相关的数据模型定义。这三层之外的东西让 Agent 自己按需去读而不是一次性全塞给它。4.2 Agent 会“自信地犯错”验证环节不能省这是最危险的坑。Agent 在不确定的时候不会说“我不确定”它会给你一个看起来很合理的答案但可能是错的。我踩过最惨的一次是让 Agent 改一个数据库迁移文件它“顺手”改了一个字段类型理由是“看起来更合理”。幸好我在 review 时发现了否则上线就是数据事故。所以我的铁律是Agent 产出的任何东西在进入主干之前必须经过验证。验证方式可以是测试、可以是人工 review、可以是 lint但绝不能是“看起来没问题就合并”。Agent 的效率提升是真实的但它把“写”的成本降下来之后“审”的成本占比就上去了。你得接受这个新的成本结构。4.3 任务描述的质量直接决定输出质量这一点怎么强调都不过分。我见过太多人说“Agent 不好用”一看他们的 prompt写的是“帮我优化一下这个代码”。这种描述 Agent 只能瞎猜。好的任务描述应该包含目标是什么、约束是什么、验证标准是什么、有哪些已知的坑要避开。举个例子对比一下。“帮我写个排序函数”和“写一个 Ruby 方法输入是 Order 数组按 created_at 降序排列created_at 相同的按 id 降序用非破坏性排序返回新数组加 RSpec 测试覆盖空数组和单元素情况”。后者 Agent 一次就能给对前者你得来回改好几轮。4.4 别让 Agent 碰你不懂的东西这条听起来像废话但真的有人犯。如果你自己都不懂某个模块的逻辑就不要让 Agent 去改它。因为 Agent 改完之后你没法判断对不对。Agent 是放大器它放大你的能力也放大你的无知。你懂的地方它让你更快你不懂的地方它让你更快地埋雷。5. 从 CLI 到框架Agent 工具链的选型逻辑5.1 为什么 CLI 形态的 Agent 先跑出来了观察一下现在主流的 Agent 工具很多都是 CLI 形态。这不是偶然。CLI 有几个天然优势一是它天然能访问文件系统和执行命令工具集不用额外造二是它容易集成到现有的开发流程里不改变你的编辑器、不改变你的 CI三是它的交互模式简单输入输出都是文本调试起来直观。我用 CLI 形态 Agent 的典型流程是在项目根目录启动用自然语言描述任务看它执行随时打断和纠正。这个体验很像带一个实习生你看着他干活不对就喊停。比在 IDE 里等补全要主动得多也比在网页里复制粘贴要顺畅得多。5.2 选型时要看的几个硬指标第一个指标是工具集的完备度。文件读写、命令执行、搜索这三样是基础缺一个都会让 Agent 的能力大打折扣。有些工具还支持浏览器操作、API 调用这些是加分项但非必需。第二个指标是上下文管理策略。好的 Agent 会自己决定读哪些文件、什么时候清理上下文而不是无脑塞。这个能力在大型项目里尤其重要。第三个指标是可中断性和可回滚性。Agent 执行到一半你发现方向不对能不能立刻停它改的文件能不能一键回滚这两个能力决定了你敢不敢让它做稍微大一点的任务。第四个指标是成本透明度。每次任务消耗多少 token、花多少钱要能看清楚。不然用着用着账单爆炸。5.3 框架和平台什么时候需要什么时候不需要如果你只是个人开发者想提升日常效率CLI 工具基本够了不需要上框架。框架的价值在于“编排”——当你需要多个 Agent 协作、需要复杂的任务分解、需要和现有系统深度集成时框架才有意义。我见过一些团队明明就几个人非要搭一套 Agent 编排框架结果维护成本比收益还高。我的建议是先用最简单的工具把 Agent 用起来用到你觉得“这里要是能自动化就好了”的时候再考虑上框架。不要为了用框架而用框架。6. 软件工程的重心正在从“写”向“定义”和“验证”迁移6.1 新的核心技能是什么如果 Agent 真的承担了越来越多的“写”的工作那软件工程师的核心竞争力就会向两端迁移上游的“定义问题”和下游的“验证结果”。定义问题包括把模糊的需求拆成清晰的、可验证的任务设计合理的抽象和接口预判可能出问题的地方。这些能力以前也重要但以前你可以用“我写得快”来弥补“我想得不够清楚”。Agent 时代这个弥补路径被堵死了因为写得不慢了想不清楚就直接体现为 Agent 输出质量差。验证结果包括设计有效的测试识别 Agent 输出中的微妙错误判断一个方案在长期是否可维护。这些能力以前被“写代码”这件事掩盖了现在会被放大。6.2 对团队协作的影响Agent 进入团队工作流之后代码 review 的重点会变。以前 review 主要看“写得对不对、风格好不好”以后会更多看“这个方案是不是最优的、有没有更好的抽象、边界情况考虑全了没有”。因为“写得对不对”这件事Agent 加上测试已经能挡掉大部分了。另一个影响是知识传递的方式。以前新人入职靠读代码、靠老人带。以后可能更多靠“和 Agent 对话”来理解项目——让 Agent 解释某个模块的逻辑、某个设计决策的原因。这要求项目本身有足够清晰的文档和注释否则 Agent 也解释不清楚。6.3 哪些能力反而更值钱了第一是调试能力。Agent 能写代码但遇到诡异的 bug还是得人来定位。因为调试需要的是对系统的整体理解和直觉这个 Agent 目前还差得远。第二是架构判断力。Agent 能实现一个方案但选哪个方案、怎么划分模块、怎么定接口这些还是人的活。而且因为 Agent 实现成本低了试错成本也低了架构决策的频率反而会上升。第三是领域知识。Agent 不懂你的业务不懂你的用户不懂你的行业约束。这些只有你有。Agent 越强领域知识的杠杆效应越大。7. 如果你现在想认真用起来我的实操建议7.1 从一个小而明确的任务开始不要一上来就让 Agent 做核心模块。找一个边缘的、有测试覆盖的、你完全理解的小任务比如“给这个工具类加一个方法”“修一个已知的 lint 问题”。用这个任务熟悉 Agent 的工作方式、工具集、交互节奏。跑通几个小任务之后你对它的能力边界就有感觉了。7.2 建立自己的“任务描述模板”我现在的任务描述基本遵循这个结构背景这个项目是什么、相关模块的职责、目标要达成什么、验收标准是什么、约束不能改什么、必须遵守什么约定、已知坑之前踩过什么、要注意什么。这个模板不是死的但有了它我描述任务的质量稳定了很多Agent 的输出质量也跟着稳定。7.3 把验证环节固化到流程里我的做法是Agent 改完代码先跑测试测试过了再跑 lintlint 过了我自己 review diff。这三步缺一不可。测试保证行为正确lint 保证风格一致review 保证方案合理。前两步可以自动化第三步必须人工。7.4 保持怀疑但别因噎废食Agent 会犯错而且会自信地犯错。但这不意味着不该用。任何工具都有它的边界关键是你知不知道边界在哪。我的态度是在边界内大胆用在边界外谨慎用边界不清楚的时候先小规模试。用了半年下来我的实际编码时间大概减少了四成但 review 和思考的时间增加了。总体效率是提升的但提升的方式和很多人想象的不一样。DHH 说的“手写代码时代落幕”我理解成“手写代码作为默认工作方式的时代落幕”。代码还是要写的只是写的方式、写的人的角色、写的价值分布都在变。这个变化对愿意调整的人来说是机会对固守旧方式的人来说是威胁。选择权在你自己手里。