DHH说手写代码落幕，Agent如何重塑软件工程与CLI工作流

1. 当 Rails 之父说“手写代码要落幕了”，他到底在说什么

DHH 这个名字在后端圈子里几乎无人不晓，Rails 框架的缔造者、Basecamp 的联合创始人、常年以“反潮流”姿态出现在技术圈舆论中心的那个人。他最近抛出的观点是：手写代码的时代正在落幕，Agent 正在重塑软件工程。这句话如果放在五年前，大概会被当成又一个技术布道者的夸张修辞，但放在今天，配合着 Codex CLI、Claude Code、各类 Agent 框架的密集落地，它更像是一个从业者对自己日常工作的真实体感总结。

我自己过去一年多的时间里，从最初把 Agent 当成“高级自动补全”，到后来把它嵌进日常的 CLI 工作流、代码审查、测试生成、甚至部署脚本的编排里，中间踩过的坑和收获的效率提升都相当具体。这篇文章不打算复述 DHH 的原话，也不打算做空洞的趋势判断，而是想从一个实际使用者的角度，把“Agent 重塑软件工程”这件事拆开来看：它到底改变了哪些环节、哪些环节其实没变、CLI 在其中扮演了什么角色、以及一个普通开发者现在应该怎么上手。

需要先明确一点：DHH 说的“手写代码时代落幕”，并不是说人不再写代码了，而是说“逐行手写”作为软件工程的主要生产方式，正在被“描述意图 + 编排 Agent + 审查产出”这种新范式稀释。这个判断对不同的岗位、不同的项目类型，冲击程度完全不同。理解这个差异，比盲目跟风重要得多。

2. Agent 到底在软件工程的哪些环节真正落了地

2.1 从“补全”到“代理”：能力边界的实质变化

早期的代码辅助工具，本质上是基于上下文的 token 预测，你写一个函数签名，它补全函数体。这个阶段的核心价值是“减少敲键盘的次数”。而 Agent 的核心差异在于它具备任务分解、工具调用、多轮自我修正的能力。你给它一个目标，比如“把这个模块的单元测试覆盖率提到 80%”，它会自己去读代码、识别未覆盖分支、生成测试、运行、看失败信息、再修改，循环直到达标或放弃。

这个变化听起来只是“自动化程度更高”，但实际影响是质变。因为软件工程里大量的工作并不是“写出一行正确的代码”，而是“在不确定的环境里反复试错直到达成目标”。Agent 恰好擅长后者。我实测下来，在测试生成、依赖升级、日志排查这三类任务上，Agent 的完成度已经能稳定超过“一个刚入职半年的工程师”。

2.2 哪些环节 Agent 已经能扛，哪些还不行

把软件工程的日常活动拆开，我自己的体感是这样的：

这张表不是绝对的，因为 Agent 的能力和模型版本、上下文长度、工具链成熟度强相关。但一个基本规律是：越是“有明确验证标准”的任务，Agent 越可靠；越是“需要权衡取舍”的任务，人越不可替代。测试能不能跑通是明确的，架构好不好是模糊的，这个差异决定了 Agent 的落地边界。

2.3 CLI 为什么成了 Agent 落地的主战场

热词里出现了大量 CLI 相关的内容：Codex CLI、GitLab CLI、Trae CLI、各种 agent 的 CLI 安装和配置问题。这不是偶然。CLI 成为 Agent 主战场有几个很实际的原因。

第一，CLI 天然是“可组合”的。一个 Agent 要完成任务，需要调用编译器、测试框架、版本控制、包管理器，这些工具几乎都有 CLI 接口。Agent 通过 CLI 调用它们，比通过 GUI 或私有 API 要通用得多。第二，CLI 的输出是文本，天然适合喂给语言模型做下一步推理。第三，CLI 运行在开发者的真实环境里，能直接访问项目文件、环境变量、本地服务，不需要额外的沙盒同步。

我自己现在的日常工作流里，Agent 基本都是以 CLI 工具的形式存在的。比如让 Agent 帮我处理一个 GitLab 上的 MR，它会调用glab（GitLab CLI）拉取 diff、读取评论、修改代码、再推送。整个过程我只需要在关键节点确认。这种“Agent 编排 CLI 工具”的模式，比任何图形化的 Agent 平台都更贴近真实开发场景。

3. 把 Agent 接进日常开发流：我的实际配置与踩坑记录

3.1 环境准备阶段最容易翻车的地方

如果你现在想上手，第一步大概率是装某个 CLI 形式的 Agent 工具。这一步看起来简单，但热词里那些报错信息说明很多人卡在这里：unable to locate the codex cli binary or required runtime components、node_modules\@opencode\cli\bin\opencode.exe 与你运行的 windows 版本不兼容、internetopenurl() failed。

这些报错的共性是运行时环境不匹配。我的经验是，在装任何 Agent CLI 之前，先把这几件事确认清楚：

• Node.js 版本是否满足要求，很多 CLI 工具对 Node 版本有硬性下限，版本低了会在安装阶段静默失败
• 系统架构是否匹配，Windows 上尤其容易出现 x64 和 arm64 混装的问题
• 网络代理配置，很多 CLI 首次运行需要拉取模型配置或依赖，网络不通会报出各种看起来像“二进制缺失”的错误
• 权限问题，Linux 和 macOS 上全局安装 CLI 时，npm 的全局目录权限经常是坑

我自己的做法是，用一个独立的 Node 版本管理工具（比如 fnm 或 nvm）给 Agent 工具单独开一个环境，避免和主项目的依赖打架。这个习惯帮我省掉了至少三次“装完就崩”的麻烦。

3.2 让 Agent 真正“懂”你的项目：上下文工程

装好之后，最大的误区是直接扔一个任务给它，然后抱怨“它不懂我的项目”。Agent 不是读心术，它需要上下文。我总结下来，让 Agent 快速理解一个项目的关键动作有三个。

第一，准备一份项目级的说明文件。很多 Agent 工具会读取项目根目录下的特定文件（比如AGENTS.md或类似约定），你可以在这里写清楚项目结构、技术栈、代码规范、常用命令。这份文件相当于给 Agent 的“入职培训材料”。我实测下来，有没有这份文件，Agent 产出代码的可用率能差出一倍。

第二，把验证命令显式告诉它。比如“跑测试用pnpm test，跑 lint 用pnpm lint，构建用pnpm build”。Agent 需要知道怎么验证自己的产出，否则它只能靠猜。热词里那些“agent execution terminated due to error”的情况，很多是因为 Agent 尝试了一个错误的验证命令，然后卡死。

第三，控制单次任务的粒度。不要让它一次改十个文件。我的经验是，单次任务涉及的文件数控制在 3 到 5 个以内，成功率最高。任务太大，Agent 的上下文会被稀释，容易在中途“忘记”最初的目标。

3.3 一个真实的排查链路：Agent 跑测试跑不通怎么办

这里分享一个我上周实际遇到的场景，完整还原排查过程，因为这类问题太常见了。

现象是：我让 Agent 给一个模块补测试，它生成了测试文件，但运行时报了一堆 import 错误。第一反应是 Agent 写错了 import 路径，但我没有直接改，而是先让它自己看报错。它重新读了一遍报错，发现是测试框架的配置里有一个路径别名没有生效。

于是我让它去检查测试配置。它读了配置文件，发现别名配置确实存在，但只在构建工具的配置里，测试框架的配置里没有同步。这是一个典型的“配置漂移”问题。Agent 提出在两个配置之间共享一份别名定义，我确认后它执行了修改，测试通过。

这个链路的价值在于：我没有替 Agent 做任何诊断，只是引导它去看正确的信息。如果我一上来就手动改 import 路径，反而会掩盖真正的配置问题。这也是 Agent 使用中一个反直觉的经验：有时候“少动手”比“多动手”更有效，因为你的手动修改会污染 Agent 的上下文，让它误以为问题已经解决。

4. 并发、记忆与安全：Agent 工程化绕不开的三道坎

4.1 Agent 怎么扛并发：不是模型的问题，是编排的问题

热词里有一条“ai agent 怎么扛并发”，这个问题问得很实在。很多人以为并发能力取决于模型，其实不是。模型调用本身是无状态的，真正的瓶颈在编排层。

我做过一个实验：同时让 5 个 Agent 实例处理 5 个独立的测试生成任务。结果发现，瓶颈不在模型响应速度，而在文件系统的锁竞争和 Git 操作冲突。两个 Agent 同时想修改同一个文件，或者同时想 commit，就会互相阻塞。

解决思路有几个层次。最粗暴的是串行化，一个任务跑完再跑下一个，简单但慢。进阶一点的是任务分区，让每个 Agent 只碰自己负责的文件子集，从源头避免冲突。再进一步是工作区隔离，每个 Agent 在独立的 Git worktree 或容器里工作，最后再合并。我目前用的是第二种，因为实现成本低，效果也够用。

提示：如果你的 Agent 工作流涉及 Git 操作，一定要给每个 Agent 实例分配独立的分支或 worktree，否则 commit 冲突会让你怀疑人生。

4.2 Agent 记忆：为什么它总是“忘记”之前说过的话

Agent 的“记忆”问题，本质上是上下文窗口的管理问题。模型本身没有持久记忆，所有的“记得”都是因为相关信息还在上下文里。一旦对话变长，早期的信息就会被挤出窗口。

我处理这个问题的方式是外置记忆。把重要的项目约定、决策记录、常用命令写进项目里的文件，让 Agent 每次需要时去读，而不是指望它“记住”。这就像给一个健忘但很勤快的同事准备了一份随时可查的文档。热词里提到的 agent memory 相关研究，方向也是类似的思路：与其扩大窗口，不如把记忆结构化地存起来，按需检索。

具体操作上，我会在项目里维护一个docs/agent-notes.md，记录“这个项目里哪些坑踩过”“哪些命令不能用”“哪些模块有历史包袱”。每次开新任务前，让 Agent 先读这个文件。这个习惯让我的返工率明显下降。

4.3 安全边界：Agent 能碰什么，不能碰什么

Agent 安全是个被低估的话题。热词里有 agent 安全、a-memguard 这类内容，说明社区已经开始重视。我的基本立场是：默认不信任，按需授权。

具体来说，我会给 Agent 划定明确的操作边界：

• 可以读整个项目，但只能写指定的目录
• 可以运行测试和 lint，但不能运行部署脚本
• 可以访问本地服务，但不能访问生产环境的任何接口
• 涉及删除文件、修改配置、执行数据库操作时，必须人工确认

这些边界不是靠“提示词”来保证的，而是靠工具层面的权限控制。比如在容器里运行 Agent，只挂载必要的目录；或者用专门的权限配置文件限制它能调用的命令。提示词可以被绕过，权限控制不会。

5. 从“写代码的人”到“编排 Agent 的人”：能力模型怎么迁移

5.1 需求描述能力变成了第一生产力

以前我们强调“代码写得清楚”，现在更重要的可能是“需求描述得清楚”。因为 Agent 的产出质量，和你的描述质量强相关。一个模糊的需求，比如“优化一下这个接口”，Agent 只能给你一些泛泛的改动。一个清晰的需求，比如“这个接口在并发 100 时 P99 超过 500ms，请定位瓶颈并给出优化方案，优先考虑缓存和批量查询”，Agent 的产出会具体得多。

我自己的体会是，写需求描述的时候，要刻意包含这几个要素：现状、目标、约束、验证方式。现状是“现在是什么样”，目标是“要变成什么样”，约束是“不能动什么”，验证方式是“怎么确认改对了”。这四个要素齐了，Agent 的产出基本可用。

5.2 代码审查能力变得比代码编写能力更关键

当 Agent 能快速产出大量代码时，瓶颈就从“写”转移到了“审”。你需要快速判断一段代码能不能用、有没有隐患、是否符合项目规范。这个能力和“自己写代码”的能力不完全一样。自己写代码时，你对自己的思路是清楚的；审 Agent 的代码时，你需要快速重建它的思路，找出它可能忽略的边界。

我练这个能力的方式是：每次 Agent 产出代码后，先不看它的解释，自己读一遍，猜它想干什么，然后再看它的解释对不对。这个练习能快速提升对“代码意图”的敏感度。

5.3 调试能力从“改代码”转向“改上下文”

传统调试是读代码、加断点、改逻辑。Agent 时代的调试，很多时候是“Agent 为什么没做对”。这时候你要检查的不是代码，而是你给它的上下文：是不是需求描述有歧义？是不是缺少关键文件？是不是验证命令给错了？

我遇到过一次典型情况：Agent 反复修改一个函数但始终跑不通测试。我检查后发现，是我给它的测试命令指向了一个过时的测试文件，它一直在按错误的预期修改代码。修正命令后，一次就过了。这个教训是：Agent 出错时，先检查你给它的信息，再检查它的产出。

6. 这套新范式对不同岗位的实际影响

6.1 初级开发者：门槛降低了，但天花板也变了

对刚入行的人来说，Agent 确实降低了“写出能跑的代码”的门槛。你不需要记住所有 API，不需要精通所有语法，Agent 能帮你补上。但这也意味着，“会写代码”这件事本身的稀缺性在下降。

真正的问题变成了：你能不能用 Agent 解决一个完整的、有实际价值的问题？这需要的是问题拆解能力、验证能力、以及对业务的理解。我见过一些新人，用 Agent 很快搭出一个 demo，但一旦要接入真实数据、处理边界情况、保证稳定性，就卡住了。这些“卡住”的地方，恰恰是现在最值钱的能力。

6.2 资深开发者：从“产出代码”转向“产出系统”

对资深开发者来说，Agent 最大的价值是把你从重复劳动里解放出来，让你有更多时间做真正需要判断力的事：架构决策、技术选型、团队协作、业务理解。我自己的时间分配在过去一年里明显变化了：写代码的时间少了，读代码、审代码、设计流程、写文档的时间多了。

这个转变对很多人来说是不舒服的，因为“写代码”带来的即时反馈和成就感是很强的。但如果你把视角拉高，会发现“设计一个能被 Agent 高效执行的开发流程”本身就是一种更高层次的工程能力。

6.3 团队协作：Agent 产出的代码谁来负责

这是一个现实问题。Agent 写的代码出了 bug，责任算谁的？我的观点很明确：谁提交，谁负责。Agent 是工具，不是背锅侠。团队需要建立相应的规范：Agent 产出的代码必须经过人工审查才能合并，关键路径的代码必须有测试覆盖，Agent 的修改记录要可追溯。

我们团队现在的做法是，Agent 产出的 MR 会打上特定标签，审查时会更仔细地看边界处理和错误处理。这不是不信任 Agent，而是对代码质量的基本要求。

7. 我踩过的几个典型坑，以及现在的应对方式

第一个坑是过度信任 Agent 的“自信”。Agent 在不确定的时候，语气往往和确定的时候一样笃定。它可能会编造一个不存在的 API，或者给出一个看起来合理但实际跑不通的方案。我的应对是：任何涉及外部 API 的产出，必须实际运行验证，不能只看代码“像不像对的”。

第二个坑是上下文污染。如果一次对话里让 Agent 做了太多不相关的事，它会带着前面的“惯性”处理后面的任务。比如先让它改了一个 Python 文件，再让它改一个 JavaScript 文件，它可能会把 Python 的写法带到 JavaScript 里。我的应对是：不同技术栈、不同模块的任务，开新的对话。

第三个坑是验证命令的副作用。有些验证命令会修改文件、写数据库、发网络请求。如果 Agent 在你不注意的时候跑了这些命令，可能造成意外后果。我的应对是：给 Agent 的验证命令单独准备一套“安全版”，比如用内存数据库、mock 外部服务、只读模式。

第四个坑是版本漂移。Agent 工具本身更新很快，今天能用的配置，明天可能就变了。热词里那些“codex cli 如何更新”“cli 切换人格的 6 个步骤”说明大家都在面对这个问题。我的应对是：把 Agent 工具的版本固定下来，升级前先在独立环境测试，确认没问题再切主环境。

8. 现在就可以开始的具体动作

如果你读到这里，想实际动手试试，我给一个最小可行的起步路径。

先选一个你熟悉的项目，最好是测试覆盖还行的，这样 Agent 改坏了你能立刻发现。然后装一个 CLI 形式的 Agent 工具，把项目级的说明文件写好，把验证命令配好。第一个任务不要选太难的，从“给某个模块补测试”或者“修复一个已知的小 bug”开始。跑通之后，再逐步尝试更复杂的任务。

过程中最重要的是记录。记录哪些任务 Agent 做得好，哪些做得差，哪些需要人工介入。这些记录会慢慢形成你自己的“Agent 使用手册”，比任何教程都有用。

DHH 说的“手写代码时代落幕”，我理解成一种提醒：软件工程的生产方式正在变化，而这个变化的速度可能比很多人预期的快。但变化不等于颠覆，它更像是重新分配了人的注意力和能力要求。会用 Agent 的人，和不会用的人，产出效率的差距会越来越大。这个差距不是工具造成的，而是使用工具的方式造成的。