复杂需求丢给 Agent最常见的失败不是「模型不够聪明」而是任务不可验收范围含糊、文件无边界、成功标准是「感觉差不多」。于是子 Agent或同会话里的分段委派开始扩写、顺手重构、漏测——主线程再花双倍 Token 收拾残局。本文是任务委派实战把需求拆成可独立红绿的子任务卡写清验收标准再交给 Cursor 的 Agent / 子 Agent或等价的「新会话 精简上下文」委派。不依赖未公开的产品内部实现细节界面名称以你当前 Cursor 版本为准。目标是委派之后仍能审计。你将得到什么一张可复制的子任务卡字段表目标/范围/禁止/验收/交付。拆分五步法从模糊需求到垂直切片。委派流水线主需求 → 拆卡 → 限权执行 → 汇总 diff。验收清单主 Agent 与人工终审共用。与 AtomGit任务卡模板可进示例仓供团队复用。委派不是甩锅好的委派是把「验收合同」写进任务卡再允许执行。坏的委派是把焦虑转述给模型「把登录相关的都弄好。」流水线建议固定为四段主需求一句话用户可见结果 明确非目标。拆卡每张卡可独立验证标出依赖与阻塞。子执行限制允许改的路径与可用工具禁止越界。汇总只合并通过验收的 diff失败卡重开不在脏上下文里加戏。若产品支持显式子 Agent / 任务委派把卡内容贴进委派说明若不支持用新 Agent 会话 必要文件模拟同一纪律——本质是上下文与权限治理不是功能开关崇拜。子任务卡字段就是护栏字段写什么反例目标一句话可测结果「优化一下登录」范围允许改的路径列表「相关的都改」禁止不可碰的文件/目录空着验收具体命令 期望「自己测测」交付diff / 摘要格式长篇聊天散文依赖前置卡 ID隐含口头约定提示词骨架可直接改你是子任务执行者只完成下列卡片不要扩展范围。 【目标】…… 【允许修改】path/a.py, path/b_test.py 【禁止】不要改 configs/、不要改无关测试、不要做格式化大扫除 【材料】path/a.py path/b_test.py 失败日志如下…… 【验收命令】pytest path/b_test.py -q 【期望】全部通过若失败先停止并报告不要继续改其他文件 【交付】只输出1) 变更文件列表 2) unified diff 摘要 3) 验收命令结果把「禁止」写进卡比事后骂「谁让你重构」有效。拆分五步法1. 写目标用户可见用验收语言「用户在关闭 MCP 写工具分组后list_tools 不再出现dangerous_*」。避免「优化 MCP 体验」。2. 列依赖数据模型变更是否阻塞 API测试夹具是否先红画一条简单依赖避免十张卡同时开工抢同一文件。3. 切垂直切片优先端到端小切片一个行为从接口到测试少按「先改全部前端再改全部后端」横切——横切卡很难单独验收委派后必合并地狱。4. 写验收每张卡至少一条可复制命令。没有自动化时写清人工检查步骤与截图点但仍优先补最小测试。5. 限权限路径白名单 工具白名单若可配置。高风险发网、删文件、改 CI 密钥单独人工卡不进自动委派。实战示例把「给项目加导出 CSV」拆开主需求「管理后台订单列表支持导出 CSV含权限校验与单测。」可能的卡卡 A权限判定纯函数 单测无 HTTP。验收pytest tests/test_export_perm.py。卡 BCSV 序列化与夹具。验收快照或字段断言。卡 C路由接线只改约定的 handler 文件。验收API 测试变绿。卡 D文档/README 一行说明与示例 curl。验收人工按文档跑通。错误拆法「卡 1 改前端卡 2 改后端卡 3 改测试」——三张卡互相不成垂直切片委派后必返工。主线程如何汇总按依赖顺序收卡失败卡新会话重跑不要在含失败幻觉的线程里继续。审 diff搜索顺手改动rename 扫射、全文件格式化。跑集成验收主需求级命令不只跑子卡单测。写 PR 描述时列出卡 ID → 文件 → 验收命令方便人工与未来的自己。常见翻车与刹车现象原因刹车子 Agent 改了一堆无关文件范围空、禁止空白名单路径测绿了但需求没满足验收命令太窄补主需求级测Token 爆了每张卡塞满历史新会话 只 材料互相覆盖并行改同一文件串行依赖或拆文件「做完了」但无 diff交付格式没写强制 diff 摘要验收清单每张子卡有独立可跑验收命令子执行输出仅限约定路径汇总 diff 无「顺手重构」失败用例先复现再改码可与 10-06 夹具文联用不可逆操作未自动执行任务卡模板已存团队库 / AtomGit与系列文的位置前接多根工作区、Rules 工程化缩小搜索与规范。后接测试夹具约束最小 diff、排障剧本委派翻车时怎么问。AtomGit把「子任务卡模板.md」放进项目模板仓比只在聊天里口口相传更可复现。主 Agent 的职责调度而不是包办主线程或主 Agent应负责维护卡表与依赖裁剪每张卡的上下文材料拒绝越界交付跑主需求级验收写交接摘要给下一会话。它不应该在同一轮里既拆卡又深改又写文档又顺手升级依赖。包办是卡住与乱改的温床。若你发现主线程自己动了子卡范围外的文件按排障剧本当「乱改」处理。上下文预算每张卡带什么建议材料包上限1 段目标与禁止24 个文件1 份失败日志或接口契约摘录0 份无关成功历史。超过就拆卡或改用文档锚点Docs/ README 片段。委派的本质是小上下文高约束不是把总仓库复制 N 份给 N 个子 Agent。并行委派何时可以仅当文件集合无交集、验收命令无互相污染、依赖图无边。否则串行。看似并行省时间合并日被冲突吃光是常态。对 AI 尤其危险——两边都「顺手」改了格式或共享工具函数。交付格式范例要求子执行返回## 变更文件 - src/foo.py - tests/test_foo.py ## Diff 摘要 - foo: 增加过期校验分支 - test_foo: 新增 expired token 用例若卡允许改测 ## 验收 $ pytest tests/test_foo.py -q 2 passed无此结构可退回重做。散文式「我已经优化了性能与可读性」一律视为未交付。把任务卡放进 AtomGit建议路径docs/agent-task-card.mddocs/cards/examples/。示例卡用假业务名避免泄露真实客户。秋季活动评审若看到「可委派的工程模板」会比只看到聊天截图更有说服力。度量委派有没有变好两周内可粗算平均每张卡重开次数越界文件次数--stat人工记主需求级一次通过率。数字不必精确到仪表盘能感觉「重开变少」就值得坚持模板。完整示例从模糊需求到三张卡模糊需求「用户希望设置页能导出个人数据注意隐私。」主目标「登录用户可在设置页导出本人资料 JSON不含他人数据有单测。」非目标「不做批量管理员导出不改计费不做新前端框架。」卡 1 — 领域纯函数目标build_export_payload(user) - dict仅含允许字段。范围src/export/payload.py,tests/test_export_payload.py禁止改路由、改模板。验收pytest tests/test_export_payload.py -q卡 2 — 鉴权与路由目标未登录 401登录返回卡 1 载荷。范围src/routes/settings_export.py,tests/test_export_route.py禁止改卡 1 已通过的纯函数语义。验收pytest tests/test_export_route.py -q卡 3 — 文档与示例目标README 增加 curl 示例与字段表。范围README.md或docs/export.md验收人工按文档跑通链到测试名。主需求级验收三张卡测全绿 手跑一次 curl。任何「顺便加 CSV」都是新需求。子 Agent 输出的质检脚本可选可用简单脚本拒绝越界读取约定白名单对比git diff --name-only有额外文件则退出码非零。把该脚本写进任务卡「验收命令」第二行委派自动化程度立刻上升。脚本进 AtomGit 示例比口头规范强。何时不要委派需求仍在争论产品语义涉及密钥轮换、生产数据删除、支付金额你无法写出任何验收命令工作区 Git 已脏到无法描述。这些情况先人工收敛再谈拆卡。委派放大器不是决策替代品。与「一题一文」创作的类比写作上的「一题一文」和工程上的「一卡一验收」同构边界清晰才可累积。系列文堆权重任务卡堆可靠交付——都是在对抗「一次性大而全」的幻觉。委派看板物理或 Markdown用最简表格跟踪卡ID状态负责人(人/Agent)验收命令阻塞A绿Agentpytest …B红人pytest …等待产品确认字段状态只用「待/跑/红/绿」不要发明十二种工作流状态。看板可以是 Issue、项目板或仓库内docs/cards/BOARD.md。目的是让委派可见而不是再引入一套重项目管理。失败卡的重开协议保留失败证据日志、--stat。新会话不沿用含错误方案的长历史。若两次仍红升级为人工设计会话Ask 模式先评再拆更小卡。禁止第三次在同一脏线程「再试一次」。重开协议写进团队公约能显著减少 Token 燃烧。安全委派也不等于授权子 Agent 提示词即使写了「可以改文件」也不自动意味着可以推送到受保护分支修改 CI 密钥对生产发请求安装未评审依赖。这些应留在人工卡。DevDay 之后谈授权边界落到委派场景就是卡上权限 ⊆ 人已授予权限。小结委派的三句口诀可验收才可委派可裁剪才可并行可回滚才可自动。把三句贴在任务卡模板页眉比再写一章理论更有用。配合同日夹具文与次日排障文你就有完整的「拆 → 约 → 修 → 救」闭环。边界与版本「子 Agent」能力与入口以 Cursor 当前版本为准无该入口时用新会话委派同一卡片纪律即可。不涉及绕过安全策略、越权访问或未授权系统操作。今晚就做选一个正在拖的需求写出主目标与非目标。拆不少于 2、不多于 5 张垂直卡每张写验收命令。只委派第一张卡强制交付 diff 摘要。把卡片模板提交到仓库docs/agent-task-card.md。可验收才可委派可委派才配叫子 Agent 工作流。