DHH 说“编程进入代理时代”这话放在 2025 年再回看已经不是预言而是正在发生的现实。我在过去大半年的时间里把自己从“手写每一行代码”的状态硬生生切换到了“指挥 AI 代理写代码”的模式这条弯路走下来踩坑不少收获更大。这篇东西不打算复述 DHH 的观点而是结合我自己的项目实践把“代理时代”到底意味着什么、实际操作中怎么用、以及那些没人告诉你但一定会踩的坑掰开揉碎讲清楚。先说个背景DHH 是 Ruby on Rails 的作者也是 37signals 的 CTO他这几年在公开场合反复强调一个观点AI 编程不是帮你“补全代码”那么简单而是直接把“编程”这个动作本身变成了“委派任务给代理”。他甚至在一次访谈里说自己已经很少亲手写代码了更多时间花在“告诉 AI 代理要做什么、然后审查它做出来的东西”。这话听起来有点极端但你真把代理编程用起来之后会发现它的确戳中了要害——编程的核心正在从“如何实现”转向“如何描述需求、如何把关结果”。这篇文章的内容我分五个部分展开先拆解“代理时代”这个概念到底在说什么再对比它和传统 AI 辅助编程的本质差异接着给出一套可以直接抄的实操工作流然后整理我在项目中遇到的典型问题和排查方法最后聊聊这个变化对整个行业、个人开发者意味着什么。全程不卖课、不推工具、不夸大只讲实际操作和判断依据。适合正在观望 AI 编程、或者已经在用但总觉得不得要领的开发者无论你是写前端的、搞后端的还是做数据分析的多少都能从中找到有用的经验。1. “代理时代”到底在说什么DHH 的核心主张拆解1.1 先搞清楚这里的“代理”不是网络代理聊这个话题之前必须先做一次概念清洗因为“代理”这两个字在技术圈歧义太多了。传统意义上做后端、搞运维的同事听到“代理”第一反应是 nginx 反向代理、Fiddler 抓包代理、内网穿透代理这些东西它们解决的是“网络请求怎么转发、流量怎么路由”的问题。但如果用这层含义去理解 DHH 说的“编程进入代理时代”那就完全跑偏了。DHH 说的代理对应的是英文里的 agent也就是 AI 代理。它不是转发数据包的工具而是一个“拥有一定自主能力能接受任务、独立思考、调用工具、产出成果”的智能体。编程领域里的 AI 代理最常见的形态就是你给 Cursor、Claude 这种工具一个自然语言指令它自己去读代码、改文件、跑测试、修复报错整个过程不再像以前那样你敲一小段它补一小段而是你下达目标它负责执行路径。这种转变才是所谓“从手写时代进入代理时代”的核心。1.2 DHH 观点的三层含义编程动作、编程角色、编程分工都在变DHH 的表述看起来只是一个个人的工作方式变化但如果仔细拆解里面其实藏着三层递进的含义。第一层编程动作本身在变。过去我们写代码是逐行敲击键盘你的手指和大脑同步每一行都经过逻辑推演。代理时代代码的“生成”动作被交给 AI程序员的手从键盘上解放出来的同时脑子必须更忙——因为你不再推演语法而在推演意图、边界条件和系统的整体行为。第二层编程角色在变。传统项目里程序员既是架构师又是“打字员”你心里有一套方案然后亲手把它翻译成代码。代理时代翻译这层工作由 AI 代劳你的职责变成了“用自然语言把方案描述清楚”变成一个需求编辑者和成果审查者。DHH 的实践里他大量时间在阅读 AI 生成的代码、挑毛病、提修改意见自己的产出物从“代码”变成了“指令”和“评审意见”。第三层编程分工在变。以前一个功能可能需要两三个人一个写逻辑、一个调样式、一个测接口。现在一个人加一个 AI 代理就能覆盖前后端全部工作。这听起来像是“程序员要失业了”但实际上它更接近“能指挥代理的人一个人就是一支部队”。我自己做独立开发项目以前估算工期的单位是“人天”现在改成“我和代理来回几个回合”这个变化是很真实的。1.3 为什么是“现在”算力、模型、工具三者正好成熟DHH 强调“编程进入代理时代”意思是这不是未来趋势而是当下已经可用的状态。我自己的体验是这个“当下”有三个必要条件正好在这个时间点凑齐了。首先是模型的推理能力到了一个临界点。以前也有代码生成模型但生成的东西经常是“看起来像代码、跑起来全是错”。现在主流的模型已经不只是在“续写”而是能理解项目结构、跨文件修改、主动发现问题。没有这种推理能力代理式编程就是空中楼阁。其次是工具的集成度上来了。Cursor、Claude Code 这类产品把“读文件、改代码、跑命令、看报错”这些动作全部收进一个对话里AI 代理可以像人一样在项目里“操作”。它不只是一个聊天窗口而是一个真正有“手”的工具。这种集成度三四年前是不存在的。最后是成本门槛降下来了。现在订阅一个 AI 编程工具的价格和以前买 IDE 插件、买服务器资源比起来并不贵个人开发者承担得起。成本一旦不是阻碍代理式编程从“大厂玩具”变成“个人标配”就是必然的事。2. 代理式编程和传统 AI 辅助编程的根本差别2.1 从“补全”到“执行”能力边界完全不是一回事我用过好几代 AI 编程工具最早的是 GitHub Copilot 刚出来那会儿它的定位是“自动补全”你写下函数名它帮你填函数体你写下 if 条件它帮你猜后面的分支。这种模式的本质是“提升打字速度”它的能力边界很清晰——它是一个极其聪明的输入法不是一个能独立完成任务的工人。代理式编程完全不是这个逻辑。你给 Cursor 一个任务比如“把这个接口的鉴权逻辑重构一下抽成中间件”它会先去搜索项目里所有相关的路由定义、中间件注册文件、鉴权校验代码然后自己规划一套改法逐个文件改动再跑一遍测试如果测试挂了还会自己修。这个过程的粒度大到什么程度呢它不只是帮你“填空”而是在“做项目”。我自己有一个很直观的感受传统的 AI 补全你写完 100 行它能帮你续上 30 行整个过程是你主导代理模式下你描述清楚一个需求它能帮你改 10 个文件整个过程是它主导你负责验收。这两者的体验差异就像是“雇了一个打字速度快的助理”和“雇了一个能独立完成项目的工程师”之间的差异。2.2 生产关系的重构程序员从“作者”变成“编辑”这个变化我花了很久才适应因为它在挑战一个程序员最基本的身份认同——我是不是一个“写代码的人”。过去我们衡量一个程序员的能力看的是“代码写得好不好”。代码风格是否优雅、逻辑是否清晰、命名是否有讲究这些都是“作者思维”。但在代理式编程的工作流里这些作者层面的技能权重在急速下降。AI 生成的代码风格统一、命名工整、注释规范它不比你写得差。这时候你拿什么来体现价值答案是判断力。你的核心能力变成了第一能不能把需求描述清楚让代理理解你到底要什么第二能不能看出代理产出的代码里那些“看起来能跑但实际上是雷”的部分第三能不能在架构层面做决策而不是在语法层面做校对。这就像杂志社的总编辑你不用亲自写每一篇文章但你得知道稿子好不好、哪里有问题、怎么改。这种角色的转变一开始很别扭但适应之后效率提升非常明显。我做一个电商类的小项目后端接口、数据库表结构、管理后台的前端页面加起来几十个文件。以前至少需要两个星期的工作量现在我用代理模式严格描述需求一天半就完成了一版能跑的。质量我当然把过关但这个速度在没有代理之前是完全不敢想的。2.3 框架与技术栈的适配Rails 这类现成方案为什么更吃香这里必须提到一个 DHH 观点的独到之处。他一直强调 Ruby on Rails 这个框架在 AI 时代会有新的红利因为 Rails 的哲学是“约定优于配置”大量功能有现成的默认方案。这个特点在代理式编程下变得极其有价值——AI 代理最擅长的事情就是按照“约定”去写代码。你告诉它“按照 Rails 的习惯给用户模型加上邮箱唯一性验证”它能精准地找到 model 文件和 migration 文件用最符合框架惯例的方式加上去。因为框架的路径是定的、命名是定的、模式是定的模型学起来轻松写出来也不会跑偏。反过来如果一个项目的技术栈特别“自由”随处都是自定义架构、零注释、奇怪的模块依赖关系AI 代理的理解成本就会暴涨犯错率也会高很多。我自己用过 Django、Spring Boot也用过一些极简框架明显能感觉到约束强的框架下 AI 代理的成功率高。这和 DHH 的判断是一致的——编程进入代理时代之后“框架的规整程度”会直接变成“AI 生产力”的一部分。这点对正在选型的团队特别有参考价值。如果你打算大规模引入代理式编程别只看哪些框架生态好、文档多还要看哪些框架的“约定”强、“规矩”多。代理在这种项目里就像久经训练的士兵遇到一个纪律严明的部队战斗力能最大化发挥。3. 代理式编程的落地实操一整套可以直接照抄的工作流3.1 先说工具Cursór、Claude Code 等主流工具怎么选聊实操之前必须把工具理清楚因为很多人卡在第一步不是能力问题是选错了工具。我实际用过并持续在用的有两类主流工具一类是集成在 IDE 里的比如 Cursor另一类是跑在命令行里的比如 Claude Code 这类终端代理。两者各有适用场景。Cursor 适合“项目级重构”和“需要频繁看代码上下文”的任务因为它的图形界面让你能边看边改改完立刻看到测试结果交互反馈非常直接。Claude Code 这类命令行工具更适合“脚本化任务”和“批量文件操作”它能一口气处理整个仓库你可以给它一个任务清单它按顺序自己跑跑完给你汇报结果整个过程你甚至不需要一直盯着屏幕。我的个人建议是不要迷信某一个工具的“年度最佳”头衔而是按项目需求来配。我自己的标配是日常开发用 Cursor 写主要逻辑遇到跨文件改动量大的任务或者是重复性很强的增删改查我切到命令行工具让它批量处理。两个工具各有优势互补使用比单一依赖效率高得多。另外注意一点工具的“版本”很关键。AI 编程工具迭代极快一个月一个版本每个版本的能力提升都肉眼可见。同样一个任务同一个工具上个版本可能会卡壳下个版本就流畅了。所以建议保持关注工具的更新日志遇到复杂的代理编程需求先试最新版本别抱着旧习惯不放。3.2 任务是关键如何把需求拆成 AI 代理听得懂的话这一步是整个代理式编程的“灵魂”也是新手和高手之间差距最大的地方。很多人在用 AI 编程的时候习惯性地把需求说得很“大”比如“帮我写一个用户登录系统”然后代理给你吐出来一个模板代码最后发现要什么没什么。拆解需求的正确姿势是“把大任务拆成小任务把模糊描述变成明确约束”。同样是“用户登录系统”我会拆成几条子任务比如设计 users 表结构包含邮箱、密码哈希、创建时间实现注册接口处理邮箱重复、密码长度小于 8 位的情况实现登录接口用 bcrypt 验证密码给登录接口加上 JWT 签发逻辑过期时间设为 24 小时把鉴权逻辑抽成中间件供其它路由复用。你发现了吗这些子任务每一条都足够清晰代理不需要猜你要什么直接就能动手。而且每次只让代理做一件事它的成功率会大幅提升。你让它一口气做一个完整系统它可能某个环节理解偏差然后整个链条全崩你拆成一个一个的小任务每个任务完成度高最后拼起来反而更快。这个过程和带新人一模一样——需求越清晰执行者越不会跑偏。这里分享一个我常用的“任务描述模板”你照着写基本不会出大问题。要素包括要做什么在哪里做约束是什么验收标准是什么。举一个实际例子“在项目的 auth 目录下新建一个 JWT 工具函数输入是用户 ID 和过期时间输出是签好的 JWT 字符串默认过期时间 24 小时密钥从环境变量 JWT_SECRET 读取用 HS256 算法。写完后跑一下项目里的 auth 相关测试确认没有破坏现有功能。”你看这个描述里代理所有需要的信息都有了位置、输入、输出、参数、算法、验收方式。它怎么可能做错3.3 实操演示用代理模式实现一个带用户认证的 API 服务为了让你看得更具体我这里复盘一个小项目的完整流程。任务是用 FastAPI 写一个带用户注册、登录、获取当前用户信息三个接口的最小后端服务数据存储用 SQLite鉴权用 JWT。我先在 Cursor 里新建一个空项目然后第一条指令是“用 FastAPI 搭一个项目骨架创建 main.py、database.py、models.py、schemas.py、auth.py 这些文件结构和 FastAPI 官方推荐的工程化风格一致”。几分钟后骨架就有了main.py 里挂好了路由和数据库初始化database.py 是用 SQLAlchemy 创建的 SQLite 连接。第二条指令我把它接上第一个核心环节“在 models.py 里创建 User 模型字段包含 id、email、hashed_password、created_atemail 字段加唯一索引。同步更新数据库初始化逻辑确保启动时自动创建表。”这条指令执行完代理不仅改了模型文件还把 database.py 里的 Base.metadata.create_all 调用补上了。第三条指令是注册接口“在 auth.py 里实现一个 /register 接口接收 email 和 password密码先走 bcrypt 哈希再存入数据库。如果邮箱已存在返回 400 错误提示信息是‘邮箱已被注册’。”执行过程中代理还很贴心地引进了 bcrypt 库并且处理了重复邮箱的异常捕获。第四条指令是登录和 JWT 签发“实现 /login 接口校验邮箱和密码是否正确正确就返回一个 JWT token过期时间 24 小时密钥读环境变量。错误就返回 401。另外写一个 get_current_user 的依赖用于后续接口解析 token 并返回当前用户。”到这里代理自己在 schemas.py 里加了几个 Pydantic 模型写了 token 的生成和解析函数。最后一条指令收尾“在 main.py 里加一个 GET /me 接口使用 get_current_user 依赖返回当前登录用户的信息。然后跑一遍 pytest如果项目里没有测试就简单起服务用 curl 验证注册、登录、获取用户信息三个流程是否正常。”代理照做中途发现一个 bugtoken 解析时密钥没读上环境变量它自己补上了缺省值。整个流程跑完大概用了四十分钟其中大部分时间是在等模型响应和看它执行。这整个过程里我说的每一句话都是自然语言我没有写过一行代码但最终的项目是可运行的而且结构清晰、代码规范。这不是什么魔法而是代理时代的工作方式——把编程从“敲代码”变成了“提要求、验收结果”。3.4 不要放养代理人工审核是最后的防线讲了这么多代理多厉害但必须泼一盆冷水代理不是万能的它做出来的东西不能直接“闭眼上线”。我的习惯是代理产出代码后我至少要做三轮检查。第一轮是“跑起来看看”。不管代理说测试全通过我都会手动启动服务把关键流程走一遍。有些问题在真实运行环境才会暴露代理的测试环境并不能覆盖所有边界条件。第二轮是“安全审查”。重点看有没有明文密码、有没有硬编码密钥、有没有 SQL 注入风险。代理有时候图省事会把密钥直接写在代码里这种事我抓了好几次。第三轮是“架构一致性检查”。代理可能为了实现一个小功能绕了一大圈破坏了原有的代码组织方式我要确保它没有破坏项目整体的架构风格。这三道检查听起来麻烦但实际花的时间远比自己写代码少。更重要的是它保证了一个底线代理是提升你效率的工具不是替你承担责任的“背锅侠”。出问题的时候用户不会去找 AI只会找你。守住质量关永远是第一原则。4. 常见问题与排查实录代理式编程踩过的坑4.1 代理产出的代码质量不稳定怎么办这是大家抱怨最多的问题也是我最开始几乎每天都会遇到的。同一个代理有时候产出的代码干净利落有时候却拖泥带水甚至还出现逻辑漏洞。这种现象的根源本质上和人体一样状态会有波动。代理的“状态”取决于你对它的输入质量、上下文窗口里的有效信息量以及它内部训练的随机性。我排查后发现代码质量不稳的最常见原因是任务描述太模糊或者上下文信息不足。比如我给代理说“把这个接口优化一下”它根本不知道“优化”指的是性能、可读性还是安全性做出来的东西自然不稳定。解决办法就是把“优化”具体化说清楚“这个接口在用户量大的时候响应很慢改成异步处理并且加上缓存缓存过期时间 5 分钟”。这样代理有没有明确的目标产出的稳定性会高出很多。第二个常见的质量问题是代理“过度实现”。你让它改一个小 bug它顺手重构了你的几个文件看起来很勤快实际却引入了不必要的风险。遇到这种情况我的做法是在任务描述里加一条约束“只修改必要文件不要做额外重构”。一行字能省下大量 review 时间。4.2 上下文窗口溢出和“跑偏”是两回事代理编程用得久了你一定会碰到两个特别头疼的问题上下文窗口溢出和回答跑偏。这两个问题经常一起出现但本质不同处理方式也不一样。上下文窗口溢出通俗讲就是“代理的短期记忆不够用了”。一个大型项目动辄几十个文件每个文件的代码几百上千行全部塞进上下文里模型就“记不住”所有内容了。我遇到这个问题的典型场景是让代理做一个跨模块功能它改着改着前面文件的内容已经超出它的“记忆范围”后面的改动就会和前面的逻辑脱节。解决办法是“分而治之”——把一个跨模块的大任务拆成每个阶段只依赖少量文件的小任务让代理每一次的“工作记忆”都足够装下必要信息。跑偏的问题则是“代理理解错了意图”。它可能把你说的“把列表按时间倒序排列”理解成“按时间正序”也可能把“添加用户管理页面”理解成“添加用户注册页面”。跑偏本身不一定是代理能力差更多是你的描述有歧义。所以我的规范是遇到跑偏先不急着骂工具检查自己的指令有没有模棱两可的地方。如果确实有修正重发如果没有考虑加一个“先给我一个实现方案确认后再动手”的步骤先让代理输出方案你确认无误再让它开工避免它闷头做错一大片。4.3 安全审查代理写代码容易“顺手埋雷”最后一个大坑是安全问题这个必须格外留意。因为代理编程的本质是让一个“没有安全意识但效率极高的外包程序员”直接写项目核心代码它不会故意使坏但它对安全的理解和判断远不及一个有经验的安全工程师。特别是它会被你项目里现有的代码风格“带跑偏”如果你的老代码里有不安全写法代理大概率会模仿。我实际遇到过几次典型问题第一是硬编码密钥代理直接把一个测试用的 API key 写在代码注释里还自我感叹“为了便于测试我内置了一个 key”这种东西一旦被推到线上就是安全事故第二是没有对用户输入做充分校验代理以为“加了类型注解就万事大吉”实际传个超大字符串或者恶意 SQL 片段就能出问题第三是日志打印敏感信息代理把用户的邮箱甚至初始密码直接打在日志里为了方便排查问题。我针对这些问题的解决方案是固定一个“安全前置检查清单”代理完成任务后先自己检查一遍有没有硬编码密钥所有外部输入是否有长度、类型、格式校验日志里是否有敏感字段报错信息是否暴露了内部堆栈。每个项目我都在 README 里写清楚这份清单每次代理完成研发后我用它来快速筛查这比我逐行读代码高效得多。4.4 团队协作代理改的代码别人要怎么接代理编程在个人项目里用得爽一旦放到团队项目里协作问题就来了。最大的矛盾是代理改动代码的方式和人的习惯不一样。它会一次性改动大批文件commit 信息写得模棱两可团队成员 review 代码的时候根本不知道它为什么这么改。我踩过这个坑之后培养了一个习惯每次让代理做任务之前先和它约定好任务边界。比如一个任务里最多改几个文件非核心文件不允许动公共模块的修改必须单独说明。Agent 改完之后我不直接让代理提交代码而是先自己把改动过一遍把它的改动拆成几个有语义的 commit每个 commit 说清楚“改了什么、为什么改”。这听起来像是给代理“擦屁股”但实际上它保证了团队的 review 体验和代码历史的可读性长期来看非常值得。另外团队里如果只有一个人用代理其他人不用很容易出现团队代码风格分裂。我给团队的建议是要么统一调研、统一接入让代理编程成为团队的共同工具要么限制代理只用于生成新功能核心架构改动必须由人来操作。别让工具的分歧变成团队协作的裂痕。5. 代理时代会带来什么影响范围与深层思考5.1 对个人开发者一人公司的复利效应代理式编程对个人开发者带来的变化是最直接的因为它其实是把“人力杠杆”倍数拉高了。以前你一个人做一个产品从想法到上线流程是全栈开发、运维、测试、上线、迭代每一环都吃人力你的产能上限受制于你每天能投入的精力。代理编程打破了这种限制。你可以同时在两三个项目间切换让代理在后台跑着一个任务你专心 review 另一个任务把一个人的产能压榨到极致。我自己做独立开发这一年多最强烈的感受是“项目启动成本”降到了几乎可以忽略。以前想到一个点子估算一下开发周期如果超过一个月就劝退了。现在一个中轻量级的项目从设计到上线一到两周不是梦。对于一个全职独立开发者而言这代表着你可以用过去做一个产品的时间尝试做十个产品然后用市场反馈去筛选哪个值得深耕。这种“复利效应”在代理时代之前根本不存在。5.2 对软件行业从“写代码”到“管代理”的岗位迁移代理编程对整个软件行业的冲击是深远的。最直接的是岗位需求变化大量重复性的、模式化的“码农”工作会被代理取代而市场会更青睐那些“能定义清楚问题、能审核代码质量、能做架构决策”的人才。这不是说程序员要失业而是说程序员的技能树必须重构。过去面试考察的核心是数据结构和算法这个东西一个重要到现在但不会是你仅有的砍柴刀。新趋势下自然语言表达能力和领域知识的深度会变得越来越重要。一个懂跨境电商业务的人用代理开发一个订单管理系统会远比一个只懂代码但不了解业务的人做得更好——因为前者能给代理描述清楚“优先级”“优惠叠加规则”“库存扣减时序”后者只会说“做个订单表”。这种迁移已经在发生了我看到很多公司已经开始建立新的岗位要求熟悉提示词工程、理解代理的能力边界、有很强的代码审查能力。未来的软件团队可能不再是一大群程序员手写代码而是一小撮核心开发者指挥一大批 AI 代理像指挥官调度部队一样调度工具的产出。这听起来很科幻但说实话已经不远了。5.3 值得警惕的地方人类判断力是最后的护城河说到这可能会让人觉得代理时代太好了但也要冷静地讲一讲担忧和边界。最重要的一点是AI 代理的产出缺少“责任意识和常识判断”。它可以写出语法完全正确的东西但它不理解你的产品对用户的承诺、不理解公司的合规要求、不理解业务背后的道德底线。它只是从海量数据中学到了“这样写大概率是对的”但在真实世界里对错并不是静态的。我自己遇到过一个离奇的案例代理在实现“用户删除账号”功能时直接用了硬删除逻辑把用户的数据库记录彻底抹掉。这在技术上完全没毛病但在业务上是非常大的隐患——审计要求、用户行为轨迹、历史订单关联都需要软删除。代理不知道这些它按照规定好的需求一步一步执行需求里没提“软删除”它就选了最简单的方案。这种“知识盲区”就是人类判断力的价值所在。工具越强大越需要有人看着它告诉它什么能做、什么不该做。这也是为什么我一直强调代理时代不是“程序员不重要”了而是“程序员更重要”了——只不过重要方式变了从“自己动手”变成了“为工具的正确性负责”。这种判断力和责任意识短期内没有任何 AI 能替代。回到 DHH 的观点我认为他说的“编程进入代理时代”本质上不是技术革新那么简单而是一次软件开发模式的重构。编程的门槛在降低但编程的下限也在拉低上限却因为有大模型的参与变得更高了。它考验的是你有没有能力把隐藏在需求背后的业务逻辑、安全约束、架构原则这些“隐性知识”挖掘出来翻译成代理能听懂的话再把它产出的结果掰开揉碎地检验一遍。这不是所有人都能轻松适应的技能但适应了的人会发现自己过去引以为傲的“手速”早已不重要了真正珍贵的是脑力、判断力和对整个系统的理解力。我自己现在的体会是代理编程不是一个“要不要用”的问题而是一个“怎么用好、怎么互相配合”的问题。它特别适合一个人单打独斗的时候放大产能也适合小团队在不加人手的情况下多线并进。但不管工具多强最后拍板的人还是你自己。写代码可以交给代理写坏的风险始终得自己兜着。