AI编程下一步，不是换IDE，是把TODO写成工单

我最近看到一个很典型的场景。

一个开发把需求丢给 Coding Agent：

“把这个列表页优化一下，顺便修一下搜索。”

Agent 很勤奋，改了 8 个文件，补了两段测试，还开了一个 PR。问题是，点进去一看，搜索确实能搜了，但原来那个“只搜当前项目”的业务边界被它顺手抹掉了。

这不是模型笨。

这是我们还在用“跟人聊天”的方式，给一个会直接动仓库的系统派活。

以前 TODO 写在代码里，更多是提醒自己：“这里以后再处理”。现在不一样了。GitHub Copilot cloud agent 这类异步 Coding Agent 已经可以从 Issue、VS Code Chat、TODO code action 里接任务，在自己的隔离环境里改代码、跑检查、开 draft PR，再等人审。

也就是说，TODO 不再只是便签。

它正在变成一个入口。

入口变了，写法就得变。

你以为在写备注，其实是在写派工单

很多团队第一次用异步 Coding Agent，最容易踩的坑不是“它写不出代码”，而是“它太愿意替你补脑”。

你写：

“TODO：优化查询性能。”

它可能理解成加缓存、改索引、换查询条件、甚至调整接口返回结构。每一条路都可能合理，但只有你知道哪条路不能走。

人类同事看到这种 TODO，通常会回头问一句：

“优化到什么程度？能不能动表结构？影响哪些接口？”

Agent 不一定会问。

它更可能先干。

这就是 AI 编程工作流里一个很反常识的变化：任务越小，越不能写得随便。因为小任务最容易被丢给 Agent，而 Agent 又最容易在“小修小补”里顺手改穿边界。

所以我现在看一个团队有没有进入 Agent 工作流，不看他们用 Cursor、Claude Code、Copilot 还是 Codex。

我先看他们的 Issue 和 TODO。

如果里面全是“优化一下”“修一下”“支持一下”，这个团队就算买了最贵的工具，也只是把许愿池搬进了代码库。

一张合格的 TODO 工单，至少要挡住三种误伤

我自己更愿意把 Agent 能接的任务写成“小工单”，不是写成长篇说明书。

太长，没人愿意写，也没人愿意审。

但它至少要包含三件事。

第一，改动范围。

不是“修搜索”，而是“只修改 project-search 相关逻辑，不改权限过滤、不改接口字段、不改排序规则”。

第二，完成标准。

不是“性能变好”，而是“在现有测试数据下，输入 3 个关键词时查询次数不超过 N 次；保留当前项目隔离逻辑；新增一个回归测试”。

第三，禁止事项。

这是很多人漏掉的。

给人派活时，我们默认对方懂公司的暗规则。给 Agent 派活时，默认暗规则不存在。

“不要引入新依赖。”

“不要改数据库 schema。”

“不要调整公共 API。”

“不要把失败吞掉。”

这些话看起来像废话，但它们就是 Agent 的刹车线。

我见过不少团队把提示词模板写得很漂亮：角色、语气、上下文、输出格式，一应俱全。

但一到真实仓库里，派给 Agent 的任务还是一句“帮我看看”。

这就像给外包团队发一条微信：“把系统弄快点。”

对方真弄了，你反而害怕。

PR 不是终点，是第二次派活入口

异步 Coding Agent 最有价值的地方，不是第一次就把活干对。

而是它能把“反馈—修改—再验证”这条链路接起来。

GitHub 的 Copilot coding agent 会把工作推到 draft PR，开发者可以看 session logs、看它跑了什么检查、在 PR 评论里继续要求修改。VS Code 里也能把本地对话委托给 cloud agent，让它在后台完成。

这意味着 PR 评论也开始变成一种“二次工单”。

以前我们写 PR 评论，经常是：

“这里不太对。”

“再处理下边界。”

“这个逻辑有点怪。”

给人看，可能够了。给 Agent 看，太虚。

更好的写法是：

“这里不要把 archived 项目纳入搜索结果。请保留原有过滤条件，并补一个 archived 项目不可见的测试。”

这句话里有对象、有禁止项、有验收标准。

Agent 就有机会继续干，而不是继续猜。

很多人说 Agent 让程序员变成 reviewer，我觉得只说对了一半。

更准确地说，程序员正在变成“任务切片的人”和“验收口径的人”。

不会切任务的人，用 Agent 会越来越累。

因为 Agent 每次都能交付一点东西，但每次都需要你花更大力气把方向拉回来。

哪些活适合丢给 Agent？看它能不能被验收

我现在判断一个任务能不能给 Coding Agent，不看它难不难。

我看它能不能被快速验收。

适合的任务通常长这样：

• 改动边界明确：只碰某个模块、某类文件、某条调用链。
• 成功标准可测试：能跑单测、快照、lint、接口用例或简单人工检查。
• 失败代价可控：错了最多退 PR，不会污染生产数据，不会改掉关键权限。
• 背景知识可写出来：不依赖“老员工都知道”的隐性规则。

不适合的任务也很明显：

“你帮我重新设计一下这个产品的权限体系。”

“你看看这坨代码怎么改比较好。”

“你顺便把体验优化一下。”

这些不是不能用 AI，而是不该直接丢给异步 Agent。它们应该先被人拆成更小的工单，再让 Agent 处理其中可验证的一段。

这里的分水岭，不是工具价格，也不是模型榜单。

是团队有没有能力把“模糊意图”翻译成“可执行、可回滚、可验收”的任务单元。

真正省时间的是少返工，不是少打字

很多人对 AI 编程的误会，是把它理解成“少写代码”。

但在真实项目里，代码本身往往不是最贵的部分。

最贵的是返工。

一个 Agent 花 20 分钟写出 500 行代码，不代表你赚了。你如果再花 2 个小时查它到底改了什么、为什么改、有没有穿透边界，那这 20 分钟就是幻觉收益。

所以我更建议团队从一个很土的动作开始：把常见 TODO 和 Issue 改成固定的派单格式。

比如：

任务：修复项目搜索在空关键词时返回异常的问题
范围：只修改 project-search 相关逻辑，不改权限过滤和接口字段
背景：当前接口需要保留项目隔离， archived 项目不可见
完成标准：新增空关键词测试；现有搜索测试通过；lint 通过
禁止：不引入新依赖；不改数据库 schema；不扩大返回字段

这段文字不性感。

但它比“帮我修一下搜索”值钱得多。

因为它让 Agent 少猜，也让 reviewer 少救火。

以后会写代码的人很多，会派活的人更少

我的判断是，2026 年 AI 编程真正拉开差距的，不是“谁会用哪个 Agent”。

工具会越来越像：都能读仓库，都能改文件，都能跑测试，都能开 PR。

差距会出现在更上游：

谁能把需求拆成 Agent 接得住的小任务？

谁能把隐性规则写成仓库说明、Issue 模板、PR 评论？

谁能让 Agent 的每一次输出都有验收口径？

这才是团队生产力的分水岭。

如果你还在把 TODO 当便签，Agent 进来之后，它就会把便签当命令。

如果你把 TODO 写成工单，它才可能真的变成一个能在后台干活的队友。

你们团队现在的 Issue / TODO，已经能直接派给 Coding Agent 了吗？还是说，只有人类老员工才看得懂？