我会交给 AI agent 的任务边界

我现在不会把所有开发任务都直接丢给 AI agent。

不是因为它不够强。恰恰相反，是因为它已经足够能干，才更需要清楚边界。一个只能补全几行代码的工具，最多写错几行；一个能读仓库、改文件、跑命令、修失败、甚至准备部署的 agent，如果边界不清楚，就会把“帮忙”变成“失控的热心”。

所以我越来越在意一个问题：哪些任务适合交给 AI agent，哪些任务只能让它参与，哪些任务必须由人来决定？

这个问题为什么值得写

前两篇我写了两个方向：AI 编程正在从生成代码变成远程协作，手机也可以成为 AI 开发任务的控制面板。

但只要真的把 agent 放进开发流程，就会遇到更底层的问题：任务边界怎么定？

如果边界太窄，agent 只能做一些零碎补全，无法形成真正的生产力。如果边界太宽，它又会在不该自作主张的地方做决定。很多失败不是因为 AI 不会写代码，而是因为人给了一个听起来明确、其实没有验收边界的任务。

比如“优化这个页面”就很危险。它可能改样式、换组件、调整信息架构、删掉一个它觉得多余但实际很重要的状态。相比之下，“修复 390px 宽度下这个按钮文字溢出，保持桌面布局不变，最后跑 lint、build 和移动端截图检查”就安全得多。

AI agent 需要的不是一句愿望，而是一张任务边界图。

真实背景：我真正想交出去的不是判断，而是推进

我对 AI agent 的期待，已经不是“帮我写一段代码”。那太局部了。

我更想交出去的是推进过程：读相关文件、找入口、提出可能方案、做小范围修改、运行验证、根据失败继续收窄问题、最后把证据和风险汇报回来。

这类工作很消耗注意力，但并不是每一步都需要人的创造性判断。很多时候，真正宝贵的是人对目标、边界、产品语义和最终风险的判断，而不是人亲自敲每一条命令。

问题在于，推进过程里也混着很多隐性判断。比如：

• 要不要顺手重构附近代码。
• 测试失败时，是修实现还是改测试。
• 发现需求不清时，是继续猜还是停下来问。
• 依赖缺失时，能不能直接安装。
• 页面看起来能用时，是否还需要做移动端验证。

这些地方如果不提前约定，agent 很容易把执行任务做成产品决策。

所以我会把任务拆成两层：人负责定义“什么是对的”，agent 负责推进“如何把它做出来，并证明它大概率是对的”。

我会交给 AI agent 的任务类型

我最放心交给 AI agent 的任务，通常有四个特征。

第一，目标可以被一句话说清楚。不是“把体验做得更好”，而是“让归档页按年份折叠，并保持已有文章排序不变”。

第二，修改范围能提前圈出来。比如只涉及某个页面、某个组件、某个 API handler、某个测试文件。范围越清楚，agent 越不容易扩大问题。

第三，结果可以被验证。lint、build、单元测试、浏览器截图、接口返回、RSS 输出、sitemap 是否包含某个 URL，这些都是很好的验收证据。

第四，失败可以回滚。改 CSS、补文案、调整小组件、增加测试通常可控；数据库迁移、权限策略、支付流程、删除数据就不应该轻易自动执行。

这些任务的共同点是：人不用让渡最终判断，也能让 agent 接手大量推进细节。

我不会直接交出去的任务

有些任务我会让 AI agent 参与，但不会让它独立决定。

最典型的是产品方向。比如“这个功能应该怎么设计”“这个页面应该突出什么”“这个付费策略是否合理”。agent 可以给选项、拆利弊、做原型，但最终判断必须回到人。

还有系统边界。比如认证、权限、数据删除、支付、隐私、迁移、缓存一致性。这些地方一旦错了，代价往往不是一个测试失败，而是用户信任或数据完整性的问题。

第三类是大范围重构。AI 很容易在大上下文里看见“顺手优化”的机会，但重构最怕目标不清。没有明确收益、没有回归测试、没有分阶段计划的大重构，我不会交给 agent 自己推进。

第四类是价值判断。文章观点、产品取舍、公开表达、用户承诺，这些地方 AI 可以帮忙组织语言，但不能替我决定站位。

type AgentTaskFit = {
  goalIsSpecific: boolean;
  scopeIsBounded: boolean;
  resultIsVerifiable: boolean;
  rollbackIsCheap: boolean;
  requiresProductJudgment: boolean;
  touchesSensitiveData: boolean;
};
 
function canDelegate(task: AgentTaskFit) {
  return (
    task.goalIsSpecific &&
    task.scopeIsBounded &&
    task.resultIsVerifiable &&
    task.rollbackIsCheap &&
    !task.requiresProductJudgment &&
    !task.touchesSensitiveData
  );
}

这段代码当然不是要真的写成一个规则引擎，而是表达一个朴素原则：越接近价值判断和高代价操作，越不能完全交给 agent。

一个任务适配矩阵

我会用两个维度判断任务适不适合交给 AI agent：不确定性和可验证性。

不确定性低、可验证性高的任务，最适合直接委派。比如修一个明确报错、补一个已存在模式下的新页面、把一篇文章按模板补齐配图和 metadata。

不确定性高、可验证性高的任务，可以让 agent 探索，但要分阶段确认。比如排查性能问题、定位线上异常、找出测试不稳定的原因。这里可以让 agent 先调查，但不要一上来就允许它大改。

不确定性低、可验证性低的任务，需要人补充验收方式。比如“让这个页面更清晰”，如果没有截图、文案标准或用户目标，agent 只能猜。

不确定性高、可验证性低的任务，不适合直接交给 agent。比如“重新设计产品定位”或“重构整个同步系统”。这些任务可以讨论，但不能自动执行。

这个矩阵的意义，不是把所有任务机械分类，而是在开始之前逼自己问一句：我到底要 agent 做执行，还是要它替我做判断？

我会怎样写任务交接

一个可以交给 AI agent 的任务，不应该只有一句标题。

我更希望它像一张小型任务卡，至少包含六件事：目标、背景、允许范围、禁止动作、验证方式、停止条件。

目标回答“做成什么样”。背景回答“为什么要做，以及已有系统是什么”。允许范围告诉 agent 可以动哪里。禁止动作告诉它不要碰哪里。验证方式告诉它怎么证明结果。停止条件告诉它什么时候不要继续猜。

我现在会更倾向于这样写任务：

目标：
修复文章页移动端目录区域在 390px 宽度下的滚动条视觉问题。
 
边界：
只允许改文章页目录相关样式，不要调整文章正文布局，不要改内容系统。
 
验证：
运行 lint 和 build。
用 390px 移动视口打开文章页，确认目录不出现突兀滚动条。
 
停止条件：
如果需要改组件结构或影响桌面目录，先停下来说明原因。

这比“优化一下目录样式”啰嗦，但它能把 agent 的行动空间压到一个可控范围内。

边界不是限制能力，而是提高吞吐

很多人会觉得边界太多，会不会让 AI agent 变笨。

我的感受相反。边界越清楚，agent 越能大胆推进。因为它知道哪些事情可以自己做，哪些事情必须问。人也更敢把任务放出去，因为即使离开电脑，也知道它不会无边界扩张。

这和团队协作很像。一个靠谱的同事，不是每一步都问你，而是知道哪些地方可以自己推进，哪些地方必须拉你确认。AI agent 也应该逐渐走向这种协作方式。

边界清楚之后，手机控制面板也才有意义。手机上展示的不是一串聊天记录，而是任务是否仍在边界内：改了哪些文件，跑了哪些验证，遇到了什么风险，现在是不是需要人批准。

关键取舍

第一，我不会追求“全自动开发”。

全自动听起来很诱人，但真实工程里很多错误不是实现错误，而是目标错误。让 agent 自动推进可以提高速度，但让它自动定义目标，会把责任推给一个没有上下文承诺的系统。

第二，我会优先交出低情绪、高机械消耗的工作。

读日志、找入口、跑命令、修 lint、整理失败原因，这些工作很重要，但很容易消耗人的注意力。把它们交出去，比把产品判断交出去更有价值。

第三，我会把验证写进任务本身。

没有验证的委派，只是在换一种方式制造不确定性。agent 完成任务时，必须带着证据回来，而不是只说“已经改好了”。

第四，我会允许 agent 提问。

一个任务如果边界不清，最好的结果不是 agent 猜对，而是它停下来问。能主动暴露不确定性，比强行继续完成更可靠。

结果与验证

这篇文章本身也可以当作一次任务边界练习。

我希望它回答的不是“AI agent 到底能不能替我开发”，而是一个更可执行的问题：我应该怎样把任务交给 agent，才既能提高效率，又不丢掉判断权？

如果用它来检查一个真实任务，我会看这些问题：

• 目标是否能在一句话里说清。
• 修改范围是否能提前列出。
• 哪些动作必须人工批准。
• 验证方式是否能在任务开始前写出来。
• agent 什么时候应该停下来问。
• 完成之后是否能给出证据，而不只是给出结论。

这些问题不复杂，但能过滤掉大量“看起来能交，其实是在让 AI 猜”的任务。

下一步

如果继续沿着 AI 工作流这条路线写，我会想把“任务边界”进一步落到两个具体设计里。

第一是任务卡片。一个 AI agent 任务卡应该如何同时给人和 agent 看？它应该包含哪些字段，哪些字段必须结构化，哪些可以保留自然语言？

第二是验收清单。不同任务类型的验证方式不一样：文章、页面、API、数据库、部署、移动端体验，各自需要什么样的最小验收？

第三是权限策略。哪些命令可以自动运行，哪些命令必须确认，哪些命令默认禁止？

这些问题听起来像流程，但它们会决定 AI agent 能不能长期进入真实工作，而不是只在 demo 里显得聪明。

收尾

我会交给 AI agent 的，不是“替我决定怎么做产品”，而是“在边界清楚的任务里替我推进工程细节”。

人仍然负责目标、约束、判断和验收。agent 负责探索、修改、验证和汇报。

边界不是为了防止 AI 发挥作用，而是为了让它的能力进入一个可长期信任的协作关系里。真正可靠的 AI 工作流，应该让人更少陷在机械推进里，同时更牢地握住判断权。