我至今记得第一次看到 GitHub Copilot 补齐整段函数时的震撼那感觉就像自己刚学会踩自行车突然有人递过来一台摩托车。几年过去AI 写代码这事已经从“辅助补全”一路狂奔到“自主完成整个任务”而真正把这把火烧到沸点的是 DHH 的那句狠话手写代码时代落幕Agent 正重塑软件工程。这句话引来了一大堆争议有人欢呼有人骂街也有人把他的意思彻底理解歪了。作为在软件行业摸爬滚打了十来年的人我反倒觉得他说的很多点是成立的。这篇文章不打算复述 DHH 的原话而是想从一线从业者的视角把“Agent 重塑软件工程”这件事拆开揉碎它到底改变了什么、怎么落地、有什么坑以及不同角色该怎么应对。1. DHH 为什么炮轰“手写代码”先别急着站队看看他到底在说什么1.1 发声者的背景决定了他这句话的分量David Heinemeier Hansson也就是 DHH身份很特殊。他一手创造了 Ruby on Rails用一套框架改变了整个 Web 开发世界他又是 37signals 的联合创始人公司靠 Basecamp、HEY 这些产品盈利不烧钱、不融资小团队也能做出千万级用户产品。他写过《重来》《远程工作》一直鼓吹“少即是多”、“小团队碾压大公司”那套反主流理念。所以 DHH 说“手写代码时代落幕”不是某个自媒体博主的标题党也不是随便一个网红程序员拍脑袋的感慨。他背后有十几年的工程管理经验、开源社区影响力、以及真实的产品验证。你可以不同意他的结论但不能无视他说话的资格。他在 2025 年左右的多次访谈和博客里表达过一个核心观点AI 不再只是一个补全代码的玩具而是能够理解需求、编写规格、执行修改、维护运行的“软件工程师同事”。当他发现自己的团队用 AI 工具可以完成以往需要好几倍人手才能做完的事时他立刻意识到软件开发的生产方式正在发生本质变化。1.2 他说的“手写代码时代落幕”到底是指什么我看了很多围绕这句话的争论发现大部分人是既没看完他的原话也没理解他的语境。有人截图说“DHH 宣布 Ruby 死了”有人愤怒地说“AI 写出来的代码全是垃圾”其实都对不上号。DHH 的意思是那些枯燥的、重复的、拼图式的“码砖”行为将逐渐从人类手里转移到 Agent 手里。比如搭一个 CRUD 接口、配置一套路由、写一堆样板测试、把一个需求翻译成 SQL 查询这些过去占程序员日常工作 60% 以上的“体力活”以后大部分由 AI Agent 代劳。但这不等于人类不需要懂编程——恰恰相反人类需要把更多精力投向“判断做什么、为什么做、怎么验证做对了”这些更高层的问题。类比一下以前你是木匠亲手量、亲手锯、亲手刨现在你更像一个建筑师加监理给施工队Agent下指令、看效果、验收。你不会因为“不再亲手刨木头”就失业反而因为能同时指挥更多施工队而变得更有价值。前提是你得懂图纸、懂结构、懂隐患在哪。2. Agent 重塑软件工程的底层逻辑从“自己写代码”变成“指挥加审查”2.1 核心变化意图驱动开发取代逐行编程传统的软件开发流程是产品经理提需求 - 开发读需求 - 在脑子里翻译成技术方案 - 手动敲代码实现 - 跑测试 - 交付。在这个流程中人的精力大量消耗在“代码翻译”阶段。Agent 参与后的流程变成了产品经理提需求 - 你来制定技术方案和约束 - 把约束和规格喂给 Agent - Agent 产出代码和测试 - 你来审查、运行、反馈 - Agent 修复问题 - 交付。你会发现人类的核心工作从“写代码”变成了“写规格、定边界、做审查”。这也是为什么最近“Agent 开发学习路线”、“从 0 到 1 搭建 AI Agent”这类教程突然爆火的原因——工程师掌握的技能组合已经变了。刚开始很多人不习惯总觉得“让它写我不放心”。但实测一段时间后你会发现只要你把规格描述得够清楚Agent 产出的代码未必比普通中级工程师差而且它 24 小时在线、不闹情绪、不埋怨需求变了。真正的问题反倒是绝大部分人其实写不清楚规格。这恰恰是手写代码时代被忽略的能力。2.2 软件工程五大环节正在被重新定义我梳理了一下Agent 影响最深的其实是这五个环节设计环节以前我们画架构图、写设计文档是为了让人看懂现在写设计文档很大程度上是为了让 Agent 能接上上下文。文档的重要性不降反升但“读者”变了。编码环节手工敲代码的比重快速下降。很多团队已经在用 Claude Code、Cursor、Codex 这类工具直接生成业务代码程序员更多在做代码审查、性能调优、边界修补。测试环节这个变化最反直觉——测试的重要性比手写代码时代更高了。Agent 写出的代码如果没有一套健壮的自动化测试兜底你根本不敢合并。好的团队会让 Agent 自己生成单元测试和集成测试但断言逻辑必须你来把守。部署与运维环节云原生工具加 Agent 组合之后环境配置、流水线编写、排障脚本这些工作大量沉淀为智能体技能。未来“配环境”这种噩梦会被压缩到极小比例但不意味着你可以不懂网络、存储和权限。需求拆解环节过去一个需求拆成任务靠开会和人工判断现在你在 Prompt 或 Agent 的任务矩阵里把验收标准写清楚剩下的事 Agent 会去拆解执行。这逼着每个程序员把“把需求说清楚”当成头等技能。这五个环节的组合变化就是“软件工程被重塑”的具体含义。它不是一个模糊的趋势而是发生在每个仓库、每个 Pull Request、每个上线窗口里的实实在在的变化。3. 实操落地把我验证过的 Agent 开发流程告诉你3.1 工具选型主流 Agent 编程工具怎么选任何不谈落地的趋势都是空中楼阁。先说工具目前市面上主流的 Agent 编程方案可以分成几类类型代表工具特点适合场景IDE 深度集成Cursor、Copilot 编程模式与编辑器无缝结合适合边看边改个人日常开发、中小型项目终端自主执行Claude Code、OpenAI Codex能在终端里自行读代码、改文件、跑命令熟系命令行的工程师任务复杂且有明确边界全流程自主 AgentDevin 类平台自己开 issue、写代码、跑测试、提 PR探索性原型、独立模块开发、新人培训辅助企业级编排平台各类 AI Agent 开发平台连接内部系统、权限控制、审批流中大型团队、合规要求高的企业我个人的真实体验是如果你的代码库已经跑得比较顺从 IDE 深度集成开始最稳。我最初用 Cursor 时最值钱的功能不是自动补全而是“在 mr 区域里 一下代码库让它给出重构建议”。它能基于你仓库里的全部代码给出判断而不是像老版插件那样只根据你开的那一个文件猜上下文。而当任务复杂度上升到“帮我在这套 Spring Boot 服务里加一个支持分页和排序的用户查询接口并补上集成测试”时我倾向用 Claude Code 这类终端工具。因为它真的会去翻整个工程目录、找到对应的 Repository 层和已有测试风格然后按项目惯例写代码。这个“按惯例”很重要Agent 不再像外行那样随手写一份风格迥异的实现而是先观察、再动手。3.2 一个可复用的五步 Agent 开发工作流踩过不少坑之后我总结出一套目前团队里跑得最顺的工作流你可以直接套用先谈需求再谈 Prompt不要一上来就让 Agent“写一个订单系统”。先用十分钟把你的验收标准列成清单比如“需要支持优惠券叠加”“库存扣减必须原子操作”“接口响应时间低于 200ms”。这些约束Agent 在实现时会自动带上。给 Agent 划清边界明确告诉它哪些文件能改、哪些目录不能动、依赖版本能不能升。这一步非常重要。我身边发生过 Agent 顺手把整个项目从 Java 8 语法“优化”到 Java 17 的翻车案。不必要的全局重构对交付来说就是灾难。让它先出实施方案而不是直接出代码我养成了一个习惯让 Agent 先写一个简短的技术方案包括模块划分、改动文件清单、风险点。方案通过我的确认后才允许它动手写代码。这个环节阻挡了大概 50% 的无效工作。强制生成测试Prompt 里永远带上这句话“请为本次改动补充单测和必要的集成测试并在完成后运行全部测试。”这不是形式主义测试是让你晚上能睡着的保证。 Agent 生成的测试质量参差不齐但总比没有好断言逻辑你会去改的。人工 Review 聚焦业务逻辑而不是代码风格以前 Review 主要看实现细节现在有了 Agent格式化、命名、低级错误这类问题它会处理。你把审查精力集中在数据一致性、权限校验、异常分支处理这些真正要命的地方价值产出反而更高。我按这套流程跑过一个内部报表系统的重构项目三个人花了大概两周完成了过去预估六周工作量才做得完的事。中途当然也不断返工但返工主要发生在需求描述不精确的时候而不是 Agent“笨手笨脚”的时候。3.3 企业落地权限、审计与代码质量闸门如果你是团队负责人或架构师不能只看单兵作战效率。企业级落地必须考虑工程治理否则 Agent 带来的可能是混乱而非效率。第一点是权限边界。Agent 能接触到的代码库、密钥、云资源必须走统一的身份认证体系。我见过团队把生产环境的 .env 文件搁在项目目录里让 Agent 扫了一遍这种事相当吓人。正确做法是通过平台接口让 Agent 在限定 scope 内工作把敏感信息通过专门的密钥管理系统注入而不是直接裸露在仓库里。第二点是变更审计。每一行由 Agent 生成的代码都要走完整的 PR 流程记录它的任务编号、Prompt 摘要、执行过程。不是为了甩锅而是为了回溯问题。一旦线上出了 bug你要能快速定位“当时给 AI 的指令是什么、它是基于哪段上下文做出的这个判断”。没有这个过程线上问题排查会变成大海捞针。第三点是设计质量闸门。代码风格检查Lint、单元测试覆盖率、依赖安全检查这些自动化工具必须全部接入 CI 流水线。Agent 写的代码也要过一样的关卡。该卡的卡该放行的放行机器的信任是通过流程建立起来的不是拍脑袋拍出来的。4. Agent 的“失控点”安全、测试与可靠性真别忽视4.1 Agent 越强安全边界越要清楚很多人一提 Agent 就怕“哪天它自己发展出意识来”说实话这种担忧属于过度科幻。真正要担心的反而是非常现实的三件事提示注入攻击如果 Agent 读取了外部传入的内容比如一个 webpage 的正文、一封邮件、一段 issue 描述恶意方会在文本里嵌入精心构造的“指令”试图让 Agent 执行非法操作。这是最流行的 Agent 攻击手段A-MemGuard 这类研究的出现就是为了防御对 Agent 记忆和上下文的污染说明安全社区已经开始认真对待了。依赖供应链风险Agent 写代码时会自动引入第三方库这些库如果来自恶意或不安全的来源等于自己亲手把病毒放进身体。所以国内外的工程团队现在都用依赖安全扫描平台Agent 新引入的每一个包都要过一遍组件风险检查。权限逃逸问题如果 Agent 拥有太高的执行权限一条“按这个链接更新配置”的指令可能就会在部署环节造成非常大的影响。我的原则是所有 Agent 默认最小权限执行需要更高权限时必须有人类审核环节尤其是生产环境的操作。做 Agent 开发学习路线的时候很多人把精力全放在“怎么让模型更聪明”上却忽略了“怎么防止模型犯错造成大破坏”。搞安全的老哥常说一句话模型的能力越强护栏的价值就越大。这句话值得刻在墙上。4.2 测试策略Agent 写代码人类写断言谈到 Agent 时代的测试我想纠正一个常见误解很多人以为 Agent 能写代码了测试也可以全面自动化、测试工程师要失业了。实际恰恰相反因为 Agent 生成的代码量大隐藏 bug 的概率也更大测试套件反而需要更完善。我现在的策略是让 Agent 生成测试的执行骨架由人定义断言的关键逻辑。比如 Agent 生成一段“创建订单”功能的单元测试它可以自己 Mock 仓库、准备参数、构造上下文但“库存到底该扣多少”“订单状态应该呈现出什么样的流转”这类核心判定一定要人手动确认并修改。否则就会出现一种啼笑皆非的情况测试跑通全绿但测试本身就是错的你等于用一个错误的标尺量了另一把错误的尺子。另外强调一点集成测试比单测更值钱。Agent 拆解任务的能力再强它的“全局观”依然受限同一个模块它会改改完是否影响别的模块AI 自己给出的答案不一定可靠。每次 Agent 处理完跨模块改动后我都会手动触发一次完整的集成测试和冒烟测试。这套习惯救了我好几次。4.3 可观测性Agent 时代的“黑盒”焦虑我见过不少工程师在用 Agent 开发时特别焦虑因为“你根本不知道它下一步想干嘛”。这和以前看自己的代码完全是两种心态。解决办法是给 Agent 加可观测性。主流的 Agent 开发框架比如各类 Agent 框架与编排工具基本都支持日志追踪会把 Agent 每一步的推理、动作、结果记录下来。你要做的不是盯着它工作而是定期翻日志看它是否偏离了任务目标、是否做了危险的系统操作、是否在无效改动上反复横跳。给团队的建议是每个 Agent 任务必须有两个输出一个是业务交付物一个是操作轨迹。轨迹异常比交付物不完美更值得警惕因为后者只是一个 bug前者可能正在酝酿一场事故。5. Agent 时代不同角色的晋级路线5.1 资深工程师从“写代码的人”变成“定义标准的人”对资深工程师来说Agent 其实是“杠杆放大器”。以前你一天能写 300 行优质代码现在你在同样的时间里可以指导三个 Agent 各产出 500 行然后你花几个小时把它们整合、审查、修正。你产出的总价值量上升了一个量级。但前提是你得有一套自己的工程标准。我见过一个十年经验的架构师他不用自己动手写太多代码但每一项 Agent 任务都配着一条规格说明模块怎么分层、异常怎么处理、性能边界在哪。Agent 在他手里就是一只训练有素的施工队而在一个刚毕业的新人手里可能就是一台脱缰的挖掘机。差别不在工具在标准。我强烈建议每个资深工程师现在就开始积累你的“Agent 指令库”和“审查清单”。这些资产用起来就像老中医的药方同样的症状你一套经典方子下去Agent 出来的东西能保持在基准线以上还能越调越好。5.2 初级开发者与学生技能结构要变了说到学生和初级开发者可能会有点扎心。DHH 的话对你们来说并不是什么坏消息而是一份重新规划技能树的提醒。你问我“软件工程导论第六版答案”、“软件工程课程设计”、“软件工程期末复习”这些怎么用 AI 处理我的回答是用来学习别人的解题思路可以但千万别把 AI 当成代写工具基础功底一旦跳过后面整个技术大厦会摇摇晃晃。未来的初级开发者核心竞争力不再是你敲代码的手速而是三件事敢于把需求拆解清楚的逻辑力、快速读懂 AI 生成代码并找出隐患的审查力、以及用自动化测试证明代码正确性的验证力。这三样东西没有任何 AI 能替我塞进你的脑子只能靠大量练习获得。所以我对团队里新人的建议一直是第一遍必须手写第二遍可以用 AI 优化然后对比两个版本看懂 AI 好在哪、差在哪。如果你连手写一遍的过程都不敢经历那你确实是被 Agent 替代的那批人而不是驾驭 Agent 的那批人。5.3 技术管理者重新设计团队分工与考核管理者层面我观察到的一个普遍误区是还在用旧的绩效指标——写了多少行代码、改了多少个 PR——去衡量一个 Agent 驱动型团队。这样一定会适得其反因为当大家发现“用 Agent 效率越高自己显得越可有可无”时他们会偷偷抵制新工具。正确的做法是调整考核方向从“代码产出量”转向“需求交付质量”和“系统运行质量”。你团队的每个工程师现在应该像一个迷你项目负责人他们管控一个又一个 Agent对最终交付负责。小组长的能力从“自己能把代码写好”变成“能把 Agent 协调好、把结果审查好”。同时管理里要留出“工具试错”的时间。Agent 技术迭代非常快今天这个框架好用明天那个编排平台上线了新功能不给团队缓冲时间直接上 KPI 是不现实的。我一般留出每周一天的时间让大家自由试验新技术然后把好用的沉淀成内部文档。这东西带来的长期回报远大于那一天的“常规产出”。6. 常见问题速查Agent 开发过程中我踩过的那些坑我根据自己和身边团队的真实经历整理了一份问题速查表都是高频的、典型的不是从文档里抄的。现象根因我的解决策略Agent 改着改着把无关代码也改了上下文窗口过大边界描述不清晰在初始 Prompt 里明确“只允许修改哪三个目录”必要时用子 Agent 隔离任务测试跑起来全绿但业务结果却不对Agent 生成的断言逻辑不严谨单测必须人审断言核心场景上集成测试Agent 一直打转重复修改文件任务过大模型上下文遗忘把大任务拆成多个小任务每个小任务独立提交生成的代码风格和团队差太远没有给风格约束在系统 Prompt 里注入团队编码规范文档或先让 Agent 看一个参考文件Agent 引入了不安全的依赖包缺依赖安全检查在 CI 里接入依赖安全扫描工具Agent 引入的包走同样的扫描流程生产环境权限事故Agent 权限过宽全链路最小权限原则生产操作加入类审批线上 bug 无法追溯来源缺少任务日志用带审计日志的 Agent 平台确保每个 PR 能关联指令和上下文除了这张表我还要单独提醒两个细节。第一个是关于“上下文污染”的。你让 Agent 读了一堆乱七八糟的历史 issue 和旧文档后它接下来生成代码的“气质”会明显变差会开始模仿那些烂代码的写法。所以我会为关键任务单独开一个干净的会话只喂给它相关的规格说明和参考实现过滤掉陈旧上下文。这比你在一个超长会话里反复强调“别学那段坏代码”有效得多。第二个是关于“多 Agent 协作”的。很多人兴奋地搞三个 Agent 一起干一件大事结果在协同阶段疯狂内耗。目前把多个 Agent 编排起来做复杂业务工程上依然很考验架构水平。我的建议是除非你已经很懂任务分解和状态同步否则不要轻易上多 Agent先踏踏实实把一个 Agent 在一个任务上垂直做深。那种“一个写前端、一个写后端、还有一个自动对接”的场景我试下来坑比收益多而收益大的是“给一个 Agent 足够的工具和清晰的边界”。另外关于 Agent 并发能力的问题也有很多人问比如“AI Agent 怎么扛并发”。你要理解Agent 本身不是靠“多线程调用同一个模型”来扛并发的而是靠任务编排能力比如批量任务分发、异步执行、结果聚合。如果你们的业务场景是大量并行的、相互独立的 Agent 任务可以考虑用消息队列加 Worker 池的形式如果任务之间有依赖那就要做好状态管理别让两个 Agent 同时改同一个文件。并发问题本质上是分布式系统问题AI 没有魔法不会自动帮你跳过分布式系统里的经典难题。7. 最后说点我个人的真实体会做技术这么多年我经历过很多次“XX时代落幕”的预言。有人说 NoSQL 要取代关系型数据库有人说微服务要取代单体有人说低代码平台要取代程序员。回头看这些预言很多时候是过分夸张的但每一次夸张背后都确实藏着一条值得跟上的暗流。Agent 这回我判断不是暗流而是明浪。它的确在把“手工敲代码”这类工作从一个职业的核心位置挤开。但我也很确信一点软件工程这门学科不会因为 Agent 的出现而变简单只会把复杂度转移——从“编写代码”转移到“描述意图、验证结果、控制风险”上。这需要的能力更加综合、更加高级也恰恰是人类相对于机器最擅长的地方。如果你已经看到了这篇文章我建议别急着站队也别急着焦虑。找一个周末把手头一个不算太重要的任务交给 Agent严格按我前面说的五步流程走一遍亲自感受一下它的上限和下限。用完之后你再回来重新读一遍 DHH 的话大概率会有完全不一样的体会。工具永远在迭代但你对工程本质的理解才是那个不会被淘汰的核心资产。