AI Coding Agent 真正省下的不是写代码时间

我一开始以为 AI Coding Agent 最大的价值，是把代码写得更快。后来越看越觉得，这个判断有点偏。

真正值得关心的不是“它能不能帮我写一个函数”，而是它能不能接住那些开发者不想亲手处理、但又必须有人处理的工程杂活：读一遍旧代码、改几个边界条件、补测试、跑命令、整理 PR、根据反馈再改一轮。

OpenAI 在 Codex 的介绍里，把它定义成一个可以在云端沙箱里并行处理软件工程任务的 agent；GitHub Copilot coding agent 也已经从编辑器内的补全，走向了可以被分配 issue、提交 pull request 的异步开发角色。官方说法当然都很漂亮，但如果站在个人开发者和小团队角度，我觉得更重要的问题是：这东西现在该不该重仓？

我为什么会关注它

因为它改变的不是某个 IDE 插件，而是任务分配方式。

过去 AI 编程工具更像“副驾驶”。你坐在编辑器前，给它一个上下文，让它补代码、解释代码、生成测试。节奏还是你主导，工具只是帮你把手上的动作变快。

现在这批 coding agent 更像“临时工”。你可以把一个相对独立的任务丢出去，让它自己拉代码、读文件、改动、运行测试，然后交一个结果回来。OpenAI Codex 的云端形态强调每个任务运行在自己的 sandbox 里；GitHub Copilot coding agent 则把入口放进 issue、pull request、GitHub Mobile、CLI 这类已有协作流程里。

这件事对小团队很现实。

一个两三个人的团队，最缺的通常不是“会不会写代码”，而是同时处理很多小任务的能力。比如：

把一个旧 API 的字段名同步到前端；
给某个边缘 case 补测试；
把 README 里的过期命令改掉；
根据 lint / typecheck 报错做一轮机械修复；
把 issue 里描述清楚的小 bug 修掉。

这些任务没有多高深，但很吃上下文切换。你今天刚把支付流程调顺，突然切去改一个表单校验，再切回来时脑子里那条线就断了。

AI Coding Agent 真正可能省掉的，是这种来回切任务的损耗。

它不是替你写代码，而是替你排队处理小工单

如果把它当成“自动完成一个完整产品”的工具，大概率会失望。

但如果把它当成一个可以处理明确工单的执行者，就合理多了。这里的关键词是“明确”。

一个适合丢给 agent 的任务，通常应该长这样：

目标：修复用户导出 CSV 时中文文件名乱码的问题
范围：只改 packages/exporter 和 apps/web/src/export 相关代码
验证：npm run test -- exporter；手动检查导出的 Content-Disposition header
不要做：不要重构整个导出模块，不要改接口返回结构

这类任务不一定复杂，但边界清楚、验证方式清楚、禁止事项也清楚。Agent 就算没做完，也比较容易 review。

反过来，下面这种任务就很危险：

帮我优化一下后台管理系统，让它更好用。

这不是任务，这是愿望。

愿望交给人都容易跑偏，更不用说交给 agent。最后它可能会改一堆样式、抽几个组件、顺手换掉状态管理方式，然后你花两个小时判断它到底是在帮忙，还是在制造一个更难 review 的 diff。

真正麻烦的是权限、上下文和回滚

Demo 里最顺的部分，往往不是工程里最难的部分。

AI Coding Agent 在真实项目里要碰到几个很硬的问题。

第一个是权限。

它能不能访问私有仓库？能不能读环境变量？能不能跑测试？能不能触发 CI？能不能访问内部文档？这些权限一旦给大了，风险就上来了；给小了，它又经常做不完事。

这不是理论问题。最近围绕 Codex 名称的第三方包和应用已经出现过供应链安全风险报道，攻击目标包括认证 token 这类高价值凭据。即使不把这个事件直接归咎于官方工具，也足够提醒开发者：agent 越接近真实开发环境，凭据、插件和第三方集成就越不能随便装。

第二个是上下文。

代码库不是一堆文件，而是一堆约定。有些约定写在 README，有些写在测试里，有些只存在于“我们一直这么做”的习惯里。GitHub 后来支持 AGENTS.md 这类自定义指令，本质上就是承认：没有项目级说明，agent 很难稳定理解一个仓库。

第三个是回滚。

人写错代码，通常知道自己刚才为什么这么改。Agent 写错代码，经常会留下一个看似合理但动机不清的 diff。review 的难点不是“这一行有没有语法错误”，而是“它为什么要动这里”。

所以我不建议个人开发者一上来就把主仓库、生产配置、部署脚本全交出去。问题不在它能不能跑，而在出了问题谁来维护。

小团队可以试，但要换一种用法

如果我是一个个人开发者或小团队负责人，我不会第一时间重仓，也不会完全忽略。

比较稳妥的做法，是先把它放在“低风险、可验证、可回滚”的任务里。

文档同步：README、CHANGELOG、示例代码更新；
测试补全：针对已有 bug report 补回归测试；
小范围 bugfix：明确文件范围、明确复现步骤；
类型修复：TypeScript 类型报错、lint 错误、格式化问题；
迁移辅助：小批量改 API 调用，不让它顺手重构架构。

先不要让它碰这些东西：

支付、权限、登录、数据删除；
生产部署脚本；
数据库 migration；
复杂业务流程；
没有测试覆盖的核心模块。

还有一个容易被忽略的准备工作：给项目写一份 agent 说明。

# AGENTS.md

## 项目约定
- 包管理器使用 pnpm，不要生成 package-lock.json
- 后端接口类型来自 packages/api-types，不要手写重复类型
- UI 组件优先使用 apps/web/components/ui
- 修改功能后至少运行 pnpm test 和 pnpm typecheck

## 禁止事项
- 不要改动数据库 schema，除非任务明确要求
- 不要修改认证、支付、权限相关逻辑
- 不要引入新的状态管理库

## PR 要求
- 说明改了什么
- 说明如何验证
- 标出不确定的地方

这份文件不一定真的叫 AGENTS.md，具体看你用的工具支持什么。关键是要把团队约定显式化。很多时候，给 agent 写说明的过程，也是在给未来的新同事和未来的自己补文档。

被夸大的地方也很明显

我不太相信“开发者很快不需要写代码”这种说法。

至少从现在的形态看，AI Coding Agent 更像把开发者从“亲手改每一行”推向“定义任务、约束边界、审查结果”。这不是不用工作，而是工作重心变了。

以前你花 30 分钟写代码。以后你可能花 10 分钟写任务说明、5 分钟等 agent 跑、20 分钟 review diff、10 分钟补它没想到的边界。

看起来还是 45 分钟。

但区别在于：如果任务拆得好，你可以同时推进多个低风险工单，把自己的连续注意力留给更重要的设计、排查和产品判断。这才是它可能带来的效率变化。

不过，这个收益不是免费的。你需要更好的 issue 描述、更清晰的测试、更稳定的 CI、更严格的代码 review。一个原本工程纪律就很松的项目，上 agent 以后不一定更快，可能只是更快地制造混乱。

如果只花半天，我会验证什么

如果你现在想试，我建议不要从“让它做一个新功能”开始。

拿一个真实但低风险的旧 issue，给它一份明确任务说明，然后只看四件事：

它能不能找到该改的文件；
它会不会主动扩大修改范围；
它能不能跑对验证命令；
它交回来的 PR 是否容易 review。

最后一条最重要。

如果一个 agent 生成的代码看起来能跑，但 review 成本比自己写还高，那它暂时就不适合进入你的主工作流。它不是没用，只是还没到可以放心托管复杂任务的程度。

我的判断

AI Coding Agent 值得试，但不值得个人开发者现在就把工作流全部迁过去。

它最适合的角色，不是“替代开发者”，而是“处理低风险工程队列的执行者”。文档、测试、小 bug、机械迁移、明确范围的修复，这些地方可以认真试。核心业务、权限支付、生产部署、数据库变更，先别急。

真正该投入的也许不是某一个工具，而是把自己的项目整理到“能被 agent 安全理解”的状态：任务可描述，边界可约束，测试能运行，回滚路径清楚。

做到这一步，就算明天换一个 agent，你也不会白忙。

参考资料：OpenAI Introducing Codex、OpenAI Codex changelog、GitHub Copilot coding agent、GitHub AGENTS.md custom instructions。