编写有效任务
一条好任务要让 Agent 知道四件事：要得到什么、可以动哪里、不能做什么、怎样证明完成。
推荐结构
目标：一句话描述最终结果。
背景：只提供影响决策的上下文。
范围：允许查看或修改的目录、模块、文件或数据。
约束：禁止的操作、兼容要求、安全要求。
验收条件：用户能观察到的行为或输出。
验证：需要运行的最小测试、需要引用的来源或需要交付的文件。示例：
目标：修复设置搜索在清空后仍保留过滤结果的问题。
范围：只修改设置导航和对应测试。
约束：不安装依赖，不重构搜索算法，不修改样式系统。
验收条件：点击清空或按 Escape 后显示全部设置，焦点留在输入框。
验证：运行最小相关测试，并给出最终 diff 和未验证项。
请先检查现状并给出方案，确认范围后再修改。把形容词换成证据
“做好”“全面”“专业”很难验收。可以改成：
- “全面分析”→“覆盖入口、数据流、错误路径和测试，并引用关键文件”；
- “写得专业”→“面向新用户，先给步骤，再解释原因，术语首次出现时定义”；
- “保证正确”→“运行指定测试，并区分已验证与未验证”；
- “找最新资料”→“核对发布日期，截至你指定的日期，优先官方来源”。
对调查和修改使用不同阶段
高风险任务建议先让 Agent 只读调查，再批准实施：
- 确认现状与影响面；
- 给出小型方案；
- 执行修改；
- 运行验证；
- 根据真实 diff 自审。
这样可以在成本最低时纠正方向。
不要过度指定实现
如果你关心的是结果，就描述接口和验收条件；如果某种实现是硬约束，再明确写出。把所有细节都提前锁死，可能阻止 Agent 利用仓库已有模式。
给失败定义行为
可以主动写明：
- 找不到证据时停止并列出缺口；
- 需要扩大目录或权限时先说明原因；
- 外部结果未知时先核对，不自动重试；
- 测试失败时区分已有失败与本次回归；
- 不得用文字声明代替文件或测试证据。
什么时候拆成多条任务
当一条任务同时包含多个独立产物、需要不同权限、会产生大量上下文，或中途有重要决策点时，应拆开。可并行的调查可以使用 Multi-Agent；有依赖的实现则按里程碑串行推进。
了解更大型的组织方式，请读管理大型项目。