问题所在：当你的AI代理在细节中迷失方向
你给了AI代理一个清晰的需求说明。你描述了想要构建的功能。你甚至提供了现有代码库的上下文信息。然而，工作几分钟后，代理却产出了一团乱麻——半成品的函数、缺失的错误处理，以及不符合实际需求的测试。
这种情况并不罕见。当代理在没有结构化方法的情况下处理复杂任务时，这是一种常见的失败模式。核心问题是庞大、模糊的任务压垮了代理连贯规划和执行的能力。代理可能开始实现某一部分，意识到需要另一部分，然后回溯，最终产生难以验证的混乱实现。
为什么会发生这种情况
AI代理，特别是在代码生成环境中运行的代理，具有有限的上下文窗口和推理能力。面对大型任务时，它们通常会：
- 过早进入实现阶段，没有充分理解依赖关系
- 遗漏边界情况，因为任务范围太广，无法考虑所有场景
- 创建不一致的代码，因为它们在问题的不同部分之间切换
- 产生不可测试的输出，因为没有明确定义验收标准
结果是时间浪费、调试头痛，以及对代理能力的信任丧失。你最终花在修复代理工作上的时间比自己动手做还要多。
一个好的解决方案应该改变什么
有效的方法需要将模糊的需求转化为具体的、有序的步骤。它应该：
- 强制在编码前进行明确规划——路径不清晰就不开始实现
- 将工作分解为小的、可验证的块，可以在单个专注的会话中完成
- 明确依赖关系，让代理先构建基础
- 为每个任务包含验证步骤，以便尽早发现错误
- 允许并行化，当有多个代理或会话可用时
这不是为了让代理“更聪明”——而是给它一个结构化的框架来弥补其局限性。
介绍规划与任务分解技能
解决这个问题的一个实用方案是规划与任务分解技能。这个技能提供了一种结构化的方法，用于将复杂工作分解为具有明确验收标准的可管理任务。
这个技能不是魔法解决方案——它是一种严谨的方法，迫使代理和人类在开始前都仔细思考工作。它在以下情况下特别有用：
- 你有需求说明或明确的要求，但需要将它们分解为可实现的单元
- 任务感觉太大或太模糊而无法开始
- 工作需要跨多个代理或会话并行化
- 你需要向人类传达范围
- 实现顺序不明显
这个技能不适用的情况
这个技能并非适用于所有情况。在以下情况下你可能不需要它：
- 进行范围明显的单文件更改
- 需求说明已经包含定义良好、有序的任务
- 更改很琐碎（如修复拼写错误或更新常量）
对简单任务使用它会增加不必要的开销。
技能在实践中如何工作
这个技能遵循一个五步过程，将需求转化为可执行的计划。
第1步：进入计划模式（只读分析）
在编写任何代码之前，代理以只读模式运行。它阅读需求说明和相关代码库部分，识别现有模式和约定，映射组件之间的依赖关系，并记录风险和未知因素。
关键规则： 在此阶段不编写代码。输出是计划文档，而不是实现。
第2步：识别依赖关系图
代理映射什么依赖什么。例如：
数据库模式
│
├── API模型/类型
│ │
│ ├── API端点
│ │ │
│ │ └── 前端API客户端
│ │ │
│ │ └── UI组件
│ │
│ └── 验证逻辑
│
└── 种子数据/迁移
实现顺序遵循这个图的自底向上方式：先构建基础。
第3步：垂直切片，而非水平切片
这是许多开发者（和代理）出错的地方。技能强制执行垂直切片——一次构建一个完整的功能路径，而不是先构建所有数据库，然后所有API，然后所有UI。
错误的（水平切片）：
任务1：构建整个数据库模式
任务2：构建所有API端点
任务3：构建所有UI组件
任务4：连接一切
正确的（垂直切片）：
任务1：用户可以创建账户（注册功能的模式+API+UI）
任务2：用户可以登录（认证模式+API+UI）
任务3：用户可以创建任务（任务模式+API+UI）
任务4：用户可以查看任务列表（查询+API+UI）
每个垂直切片都交付可工作、可测试的功能。
第4步：编写结构化任务
每个任务遵循特定模板：
## 任务 [N]：[简短描述性标题]
**描述：** 一段话解释这个任务完成什么。
**验收标准：**
- [ ] [具体的、可测试的条件]
- [ ] [具体的、可测试的条件]
**验证：**
- [ ] 测试通过：`npm test -- --grep "feature-name"`
- [ ] 构建成功：`npm run build`
- [ ] 手动检查：[验证内容描述]
**依赖：** [此任务依赖的任务编号，或“无”]
**可能涉及的文件：**
- `src/path/to/file.ts`
- `tests/path/to/test.ts`
**估计范围：** [小：1-2个文件 | 中：3-5个文件 | 大：5+个文件]
第5步：排序和添加检查点
任务被安排为满足依赖关系，每个任务使系统保持在工作状态，并且每2-3个任务后出现验证检查点。高风险任务被放在早期以快速失败。
显式检查点如下所示：
## 检查点：任务1-3之后
- [ ] 所有测试通过
- [ ] 应用程序构建无错误
- [ ] 核心用户流程端到端工作
- [ ] 继续前与人类审查
实际考虑因素
任务大小指南
技能提供了清晰的大小指南：
| 大小 | 文件 | 范围 | 示例 |
|---|---|---|---|
| XS | 1 | 单个函数或配置更改 | 添加验证规则 |
| S | 1-2 | 一个组件或端点 | 添加新的API端点 |
| M | 3-5 | 一个功能切片 | 用户注册流程 |
| L | 5-8 | 多组件功能 | 带过滤和分页的搜索 |
| XL | 8+ | 太大——需要进一步分解 | — |
如果任务是L或更大，应该分解为更小的任务。代理在S和M任务上表现最佳。
何时进一步分解任务：
- 需要超过一个专注的会话（大约2小时以上的代理工作）
- 你无法用3个或更少的要点描述验收标准
- 它涉及两个或更多独立子系统（例如，认证和计费）
- 你在任务标题中写了“和”（这是两个任务的标志）
并行化机会
当有多个代理或会话可用时：
- 可以安全并行化： 独立的功能切片、已实现功能的测试、文档
- 必须顺序执行： 数据库迁移、共享状态更改、依赖链
- 需要协调： 共享API契约的功能（先定义契约，然后并行化）
输出文件
技能产生两个关键文件：
- 计划文档： 保存到
tasks/plan.md - 任务列表： 保存到
tasks/todo.md
这些路径是下游工具期望的约定。
评估这个技能是否适合你的工作流程
最佳用例
这个技能在以下情况下表现出色：
- 构建新功能，跨越多个文件或组件
- 重构现有代码，需要仔细映射依赖关系
- 熟悉不熟悉的代码库，代理在更改前需要理解结构
- 协调多个代理处理相关任务
- 估计项目范围供人类在实现前审查
何时避免使用
在以下情况下不要使用这个技能：
- 更改琐碎且容易理解
- 你正在做范围明显的单文件编辑
- 需求说明已经包含完美排序、大小合适的任务
- 时间压力使规划开销不可接受（尽管这通常是虚假的节约）
设置上下文
这个技能是Addy Osmani的agent-skills仓库的一部分。它设计用于可以遵循结构化指令的AI编码代理。除了在代理的技能目录中拥有该技能外，不需要特殊安装。
安全信号
- 技能强调在实现前进行只读规划
- 它要求每个任务都有明确的验收标准
- 它包含验证步骤以尽早发现错误
- 它促进小而专注的任务，更容易审查和测试
仓库信号
agent-skills仓库有显著的社区关注度，超过76,000个星标。该技能是旨在提高代理可靠性的精选集合的一部分。仓库包含文档和示例，但与任何开源工具一样，你应该审查实现以确保它符合你的安全要求。
常见陷阱及如何避免
“我会边做边想”
这就是你最终得到混乱实现和返工的方式。十分钟的规划可以节省数小时的调试时间。
“任务很明显”
无论如何都要写下来。显式任务能揭示隐藏的依赖关系和被遗忘的边界情况。
“规划是开销”
规划就是任务。没有计划的实现只是打字。
“我都能记在脑子里”
上下文窗口是有限的。书面计划能跨越会话边界和上下文压缩而存在。
需要警惕的危险信号
如果你看到这些模式，规划过程需要改进：
- 没有书面任务列表就开始实现
- 任务说“实现功能”而没有验收标准
- 计划中没有验证步骤
- 所有任务都是XL大小
- 任务之间没有检查点
- 没有考虑依赖顺序
开始使用
如果你正在处理AI代理难以可靠完成的复杂任务，考虑检查规划与任务分解技能。从一个小型、定义良好的项目开始，看看结构化方法如何影响代理的输出质量。
这个技能不会让你的代理更聪明，但它会给它一个框架来弥补其局限性——将模糊的需求转化为具体的、可验证的步骤，从而产生更可靠的结果。