Agent时代：从写代码到做东西，开发者如何转型与搭建工作流

1. 从“手写代码结束”这句话说起“手写代码结束了做东西的人刚开始。”这句话第一次看到的时候我盯着它想了很久。它不是在说程序员要失业了也不是在鼓吹什么工具万能论。它说的是一件更朴素、也更扎心的事当代码的产出成本被压到接近于零真正稀缺的东西就不再是“能不能写出来”而是“到底要做什么”。过去十几年我们这行的手艺很大程度上体现在“实现”上。一个需求过来你要拆解、要设计数据结构、要选框架、要处理边界、要调性能。这些活儿有门槛也有成就感。但现在情况变了——AI agent 能在几秒钟内吐出一个能跑的 CRUD能帮你把一段 Rust 的所有权报错解释得明明白白能根据一句自然语言描述生成整个项目骨架。写代码这件事本身正在从“核心技能”退化成“基础素养”。那什么变得更重要了是判断力。是知道该做什么、不该做什么、先做什么、后做什么。是把一个模糊的想法翻译成 agent 能理解、能执行、能验证的任务序列。是当 agent 给你吐出 500 行代码时你能一眼看出哪一行会在并发场景下炸掉。这篇东西我想结合 Ruby on Rails、Rust、Claude Opus 4.5 这些关键词聊聊在这个“agent 时代”一个真正做东西的人应该怎么定位自己、怎么搭工具链、怎么把 agent 用出价值而不是被它带偏。不管你是刚入门的新手还是写了十年代码的老兵这里面的很多坑我都亲自踩过希望能帮你少走点弯路。2. Agent 到底改变了什么从“写”到“编排”的范式转移2.1 写代码的成本曲线被彻底压平了先看一个很直观的对比。以前我要做一个带用户认证、数据库、REST API 的后端服务用 Rails 的话大概是这样的流程rails new建项目配 Gemfile写 migration写 model写 controller配路由写测试调 bug。熟练工大概一两天能出一个能用的版本。用 Rust 加 Axum 或者 Actix时间只会更长因为类型系统会逼着你想清楚每一个数据流。现在呢你把需求描述清楚Claude Opus 4.5 这类模型能在几分钟内给你一个结构完整的项目。Rails 的约定优于配置它门儿清Rust 的 trait 和生命周期它也能处理。写代码这件事的边际成本正在快速趋近于零。但这里有个反直觉的点成本降低不等于价值降低。恰恰相反当所有人都能快速产出代码时代码本身的质量差异会被放大。一个架构混乱、边界不清的项目在 agent 加持下会以更快的速度变成技术债。所以“做东西的人”的价值从“写得快”转移到了“想得清”。2.2 Agent 不是自动补全它是任务执行者很多人对 agent 的理解还停留在“高级版代码补全”。这是个危险的误解。自动补全解决的是“这一行怎么写”agent 解决的是“这件事怎么做”。举个我自己的例子。我最近在做一个 Rust 写的桌面小工具用 Tauri 做壳。我需要一个功能读取本地某个目录下的所有 Markdown 文件解析出其中的待办事项汇总成一个列表。如果用传统方式我得自己写文件遍历、写 Markdown 解析、写数据结构、写 UI 绑定。但用 agent 的方式我是这样拆的先让 agent 理解我的目录结构和文件格式让它生成一个独立的 Rust 模块只负责扫描和解析单独验证这个模块的输出再让它接入 Tauri 的命令系统最后处理前端调用每一步都是一个可验证的小任务。Agent 的核心价值不是替你写代码而是替你执行“任务序列”。你负责定义任务边界和验收标准它负责填充实现细节。2.3 为什么 Ruby on Rails 和 Rust 在这个时代反而更值得关注有意思的是agent 时代并没有让框架变得不重要反而让某些框架的价值更突出了。Rails 的“约定优于配置”在 agent 场景下是个巨大优势。因为约定明确agent 生成的代码更容易符合预期你 review 起来也更快。一个 Rails 项目的目录结构、命名规范、分层逻辑都是高度标准化的agent 不需要猜。相比之下一个高度自由、什么都能塞的框架agent 生成的东西往往需要你花更多时间整理。Rust 则是另一个极端。它的类型系统和所有权模型本质上是一套“编译期的验收标准”。Agent 生成的 Rust 代码如果编译不过那就是真的有问题。这比动态语言里“跑起来看着对但暗藏 bug”要安全得多。Rust 的严格性恰好成了 agent 输出质量的天然过滤器。这也是为什么最近基于 Rust 的 agent 工具链越来越多——不是赶时髦是类型安全在自动化场景下真的省心。3. 搭一套能扛事的 Agent 工作流我的实际配置3.1 任务拆解比提示词技巧重要一百倍网上有很多“提示词工程”的教程教你用什么魔法句式让模型输出更好。我试过不少结论是在 agent 场景下任务拆解的能力远比提示词技巧重要。一个模糊的指令比如“帮我做一个用户管理系统”agent 会给你一堆看起来能用但处处是坑的东西。但如果你把它拆成第一步设计数据库 schema包含用户表、角色表、权限表给出字段和关系第二步基于 schema 生成 migration 和 model第三步生成认证相关的 controller 和路由第四步为每个接口写测试用例第五步跑测试修复失败项每一步都有明确的输入和输出agent 的执行质量会高出一个数量级。这不是提示词的功劳是任务分解的功劳。我自己的习惯是在让 agent 动手之前先用纸或者文档把任务树画出来。每个叶子节点必须是一个“可独立验证”的单元。如果一个任务没法验证那就说明它拆得还不够细。3.2 用 Rust 做 agent 的“执行沙盒”这是我踩过坑之后总结出来的一个关键实践。Agent 生成的代码尤其是涉及文件操作、网络请求、系统调用的部分绝对不能直接在你的主环境里跑。你需要一个沙盒。我的做法是用 Rust 写一个轻量的执行器把 agent 生成的代码放在隔离环境里跑。Rust 的std::process::Command配合资源限制可以很好地控制子进程的行为。为什么用 Rust 而不是 Python 或者 Node因为 Rust 编译出来的二进制没有运行时依赖启动快资源占用低而且类型安全让我在写执行器本身的时候少犯错误。具体来说这个执行器做几件事限制 CPU 时间和内存使用限制可访问的文件路径捕获标准输出和错误输出设置超时防止死循环use std::process::{Command, Stdio}; use std::time::Duration; fn run_in_sandbox(code_path: str) - ResultString, String { let output Command::new(timeout) .arg(10s) .arg(cargo) .arg(run) .arg(--manifest-path) .arg(code_path) .stdout(Stdio::piped()) .stderr(Stdio::piped()) .output() .map_err(|e| e.to_string())?; if output.status.success() { Ok(String::from_utf8_lossy(output.stdout).to_string()) } else { Err(String::from_utf8_lossy(output.stderr).to_string()) } }这段代码很简单但思路很重要永远不要信任 agent 生成的代码先让它在一个受控环境里证明自己能跑。这个习惯帮我避免了好几次因为 agent 生成的代码里有无限循环或者意外文件删除而导致的灾难。3.3 版本控制是 agent 时代的生命线Agent 会改代码而且改得很快。如果你没有严格的版本控制习惯很快就会陷入“不知道哪次改动引入了 bug”的困境。我的做法是每一次 agent 的改动都必须是一个独立的 commit。不管改动多小都要提交。commit message 写清楚这次改动的意图和验证结果。这样一来如果某个改动出了问题回滚成本极低。更进一步我会用 git 的 branch 来隔离实验性的 agent 任务。让 agent 在一个独立分支上折腾验证通过了再合并。这听起来很基础但我见过太多人让 agent 直接在 main 分支上改出了问题手忙脚乱。提示给 agent 的每一个任务都配一个独立的 git 分支任务完成后用 squash merge 合并。这样历史记录干净回滚也方便。4. 当 Agent 开始“做东西”几个真实的场景拆解4.1 场景一用 Rails 快速验证一个想法假设你有个想法做一个内部用的书签管理工具支持标签、搜索、导入导出。以前你可能要犹豫一下“值不值得花两天做”。现在不用犹豫了直接让 agent 上。我的流程是这样的先用自然语言把需求写清楚包括数据模型、页面、交互让 agent 生成 Rails 项目骨架和 migration本地跑起来看数据库结构对不对让 agent 生成 controller 和 view手动调 UI 细节这部分 agent 做得不够好让 agent 补测试整个过程大概两三个小时其中大部分时间花在“想清楚要什么”和“调 UI”上。写代码的时间被压缩到了很小一部分。这就是“做东西的人刚开始”的真实含义——你的时间从实现转移到了定义和验收。这里有个坑要注意Rails 的 agent 生成代码很容易过度使用 gem。Agent 看到“搜索”就给你装 Elasticsearch看到“导入导出”就给你装一堆解析库。我的经验是在让 agent 动手之前先明确告诉它“只用标准库和 Rails 自带功能不要引入新 gem”。这一句话能省掉后面大量的依赖管理麻烦。4.2 场景二Rust 写一个高性能的 agent 调度器如果你要做的不是 CRUD而是需要处理并发、需要高性能的东西Rust 的优势就出来了。我最近在做一个多 agent 协作的小系统核心是一个调度器负责把任务分发给不同的 agent 实例收集结果处理失败重试。这个调度器用 Rust 写核心逻辑大概两百行。为什么不用 Python因为 Python 的 GIL 在高并发场景下是个硬伤而 agent 调度天然是 IO 密集加并发密集的。Rust 的 async/await 配合 tokio能轻松处理几千个并发任务。关键设计点用tokio::sync::mpsc做任务队列每个 agent 实例是一个独立的 task用ArcMutex管理共享状态失败任务自动重试最多三次use tokio::sync::mpsc; use std::sync::Arc; use tokio::sync::Mutex; async fn dispatch_tasks( tasks: VecString, agent_count: usize, ) - VecString { let (tx, rx) mpsc::channel::String(100); let rx Arc::new(Mutex::new(rx)); let mut handles vec![]; for _ in 0..agent_count { let rx rx.clone(); let handle tokio::spawn(async move { loop { let task { let mut rx rx.lock().await; match rx.recv().await { Some(t) t, None break, } }; // 执行任务 let result execute_task(task).await; // 处理结果 } }); handles.push(handle); } for task in tasks { tx.send(task).await.unwrap(); } drop(tx); for handle in handles { handle.await.unwrap(); } vec![] }这段代码的价值不在于它多复杂而在于它展示了Rust 在 agent 基础设施层面的适用性。当你的 agent 系统需要扛并发、需要低延迟、需要长时间稳定运行时Rust 几乎是当前最好的选择。4.3 场景三Claude Opus 4.5 在代码审查中的实际表现Claude Opus 4.5 在代码理解和生成上的能力我用下来的感受是它像一个非常勤奋但偶尔会过度自信的初级工程师。它能发现很多你忽略的边界情况能给出合理的重构建议但它也会在某些时候“编造”一些不存在的 API 或者给出看似合理实则错误的方案。我的用法是让 agent 做第一轮审查把它发现的问题列出来然后我自己判断哪些是真问题、哪些是误报。这个流程能帮我抓住大概 70% 的明显问题剩下的 30% 需要我自己看。一个具体的例子我有一段 Rust 代码处理文件读取agent 指出我没有处理文件不存在的情况。这是对的我确实漏了。但它同时建议我用一个我根本没引入的 crate 里的函数这就是典型的“幻觉”。所以 agent 审查的结果必须经过人工过滤不能直接采纳。5. 那些没人告诉你但一定会踩的坑5.1 Agent 的“上下文遗忘”比你想的严重Agent 在多轮对话中会遗忘早期的约定。比如你在第一轮告诉它“所有 API 返回都用 snake_case”到第五轮它可能就给你返回 camelCase 了。这不是模型不行是上下文窗口的物理限制。我的应对方法是把关键约定写成一个“项目宪法”文件每次让 agent 干活之前先把这个文件的内容贴给它。这个文件不用长一页纸就够包含命名规范、目录结构、依赖限制、错误处理约定这些。每次任务开始前重新注入能极大减少不一致。5.2 不要用 agent 做“架构决策”Agent 很擅长在给定架构下填充实现但它不擅长做架构决策。你让它“设计一个用户系统”它会给你一个能用的方案但往往不是最适合你场景的方案。它不知道你的团队规模、不知道你的部署环境、不知道你未来半年的规划。架构决策必须由人来做。Agent 可以给你提供选项和利弊分析但拍板的是你。我见过有人让 agent 全权决定技术选型结果选了一个社区很小、文档很差的库后面维护起来苦不堪言。5.3 测试是 agent 时代的“安全带”Agent 生成的代码如果没有测试你根本不知道它是不是真的能用。而且 agent 很容易生成“看起来对”的代码——语法正确、逻辑通顺但边界情况全错。我的做法是让 agent 先写测试再写实现。测试用例由我来定义agent 负责把测试写出来。然后让 agent 写实现跑测试直到全绿。这个流程能过滤掉大部分低级错误。注意Agent 写的测试本身也可能有问题。我遇到过 agent 写的测试断言写反了导致错误的实现也能通过。所以测试写完我会快速扫一遍断言逻辑确认它测的是对的东西。5.4 性能问题往往藏在“能跑”之后Agent 生成的代码第一优先级是“能跑”性能通常不在它的考虑范围内。一个在本地跑得好好的功能上了生产环境可能因为一个 N1 查询就崩了。我的经验是在 agent 完成功能实现后专门让它做一轮性能审查。告诉它关注数据库查询、循环内的 IO、不必要的内存分配这些点。Rust 的话还可以让它检查有没有不必要的 clone。这一轮审查往往能发现不少问题。6. 做东西的人到底该把时间花在哪6.1 定义问题比解决问题更难Agent 让“解决问题”变得便宜了于是“定义问题”的价值就凸显出来了。一个清晰的问题定义包含目标是什么、约束是什么、验收标准是什么、不做什么。这四件事想清楚agent 才能干得好。我现在的习惯是在打开编辑器之前先花 20 分钟把问题写下来。写不清楚就说明还没想清楚这时候让 agent 动手只会浪费双方的时间。6.2 判断力来自“做过”Agent 可以给你建议但它不能替你承担判断的后果。而判断力这个东西没有捷径只能来自大量的实践。你做过足够多的项目踩过足够多的坑才能在 agent 给你三个方案时一眼看出哪个会在三个月后出问题。所以我的建议是不要因为 agent 能写代码就跳过动手的环节。该自己写的核心逻辑还是要自己写该自己调的 bug 还是要自己调。Agent 是杠杆但杠杆需要支点你的经验就是那个支点。6.3 保持对“手艺”的敬畏最后说点感性的。写代码这件事哪怕 agent 能做得又快又好它依然是一门手艺。手艺的价值不只在于产出还在于过程中对细节的打磨、对美的追求、对“这样做对不对”的反复追问。Agent 可以帮你写一个能用的函数但它不会因为变量命名不够优雅而纠结不会因为一个边界情况没处理好而睡不着觉。这些“纠结”和“睡不着”恰恰是区分“能跑的东西”和“好东西”的关键。“手写代码结束了做东西的人刚开始。”这句话我越琢磨越觉得对。代码会越来越便宜但把东西做好、做对、做得让人愿意用这件事永远不会便宜。Agent 把我们从重复劳动里解放出来不是让我们躺平而是让我们有机会去做那些真正需要人的判断和品味的事。我在实际使用 agent 的过程中最大的体会是它放大了我的能力也放大了我的懒惰。当我认真定义问题、严格验收结果时它让我效率翻倍当我偷懒把模糊的需求丢给它时它给我一堆需要返工的垃圾。所以最终决定产出质量的还是我自己。工具再好用工具的人得先想清楚自己要什么。