与 AI Agent 协作的第二条基本规则：将大型请求拆分为更小的粒度，并在每一步之后进行验证，效果优于一个巨大的提示词。
如果你要做一个大型的新功能，最好将其拆分为较小的 Task，原因有好几个。
需要提到的最重要的一点，是软件开发成本如何随时间变化。《Code Complete》一书中有一张著名的图表，展示了修复 bug 的成本如何取决于在开发的哪个阶段发现它：在分析阶段成本几乎为零，而一旦软件在客户现场投入生产，成本就高出一个数量级甚至更多。以如今 AI 生成代码的速度，你需要更加谨慎地预先设计架构，因为重构恰恰是 AI 不太擅长的事情。最好的做法是遵循 clean-code 书籍中描述的标准，并使用成熟的模式来组织结构和业务逻辑：书籍是 AI 模型在训练期间学习正确实践的最高质量来源之一，因此它对这些内容理解得最好。对 AI 来说，即使是单体应用，也要保持代码分成清晰的层次，这一点同样重要，这样 Agent 在代码中会更容易找到方向。
回到如何正确拆分 Task。假设任务是：构建一个新的客户满意度表单。我们需要哪些阶段？
- UI：表单、其字段以及提交事件。
- 业务逻辑：表单校验、将请求关联到客户账户、请求的优先级。
- 数据结构：数据如何传到 BE 并返回 FE。
- BE：再次进行校验和业务逻辑，这次是在后端一侧。
- 数据层：从数据结构到数据库的映射。
- 数据持久化，以及从 BE 流回 FE 的相应结构。
对 AI 来说，从哪里开始其实并不重要，重要的是正确地描述每一步。对你作为用户来说，最实用的做法是从数据库或前端开始。
这样就涵盖了所有 Task。现在的问题是：一个大 Task 与若干小 Task 之间有什么区别？
对于单个 Task，优势在于各步骤共享上下文（缓存），Agent 永远不必重新查找任何东西。但随着轮次增多，这一优势会反转：在同一个上下文中停留得越久，后续每一轮要重新发送和重新处理的 token 就越多，因此每轮的成本会随上下文的大小不断增长，在一个很长、轮次很多的 Task 上，这可能累积成一笔可观的数目。
如果改为拆分 Task，AI 每次只做它那一个具体的部分，最后可以对其独立测试，在下一部分工作开始之前就发现错误。我们总体消耗的 token 更少，而且能够独立验证每一步，使我们能比在单个巨大 Task 完成之后更早地发现幻觉或对需求的偏离。较小的 Task 也不需要模型同时把注意力分配到每一个细节上。
为什么这对 AI 模型如此重要？它们同时在大量指令之间保持优先级的能力是有限的。如果你在一个提示词里写下“添加一个新功能、重构旧逻辑，并修复三个相关 bug”，模型会自行组装一套优先级顺序，而它可能与你的并不一致。结果是：一部分任务完成得很出色，一部分被敷衍，而直到在生产环境中出问题之前，没有人察觉。
这正是 AITM 将大型请求拆分为链式 Task，而不是让它们作为一次连续的过程运行的原因。
实际是什么样子：普通 AI 聊天 vs. AITM
普通 AI Agent（聊天/IDE 副驾驶）：你给它一个很长的提示词，Agent 在一个连续的上下文中开始工作。如果它在进行到 80% 时某个细节出了错，你要等到审查整个 diff 时才会发现，而与此同时，后续各点的工作仍在有缺陷的基础上继续进行。
AITM：同样的请求在 Chat 或 Brainstorm 中被拆分为带有依赖关系的、各自独立的链式 Task 调用：只有当 Task A 走完整个 Pipeline 并被合并之后，Task B 才被允许开始。如果 Task A 在 review 或 test 阶段失败，Task B 不会在有缺陷的基础上启动，而是等待。与此同时，Watchdog 自己评估 Task A 的失败：如果它能分析出错误并提出修复方案，Task 就会自动以准确描述该错误及所提议修复的提示词重新启动；如果错误不明确，或没有人为决策就无法解决，Task 就会停止，等待用户决定如何继续。此外，链中最后一个 Task 合并之后，会运行 chain-audit 步骤，这是一项确定性的（非 AI）最终检查，会重新验证整条链所影响的 Contracts。
用户看到的差别是：使用普通 Agent，最后得到的是一个庞大而不透明的 diff。使用 AITM，得到的是若干较小的、有名称的、经过独立检查的 Task，各自带有自己的历史，而且如果事情没有按计划进行，你确切知道问题出在哪里。