子代理分析任务标准化指令（Standardized Subagent Analysis Instruction）#
触发场景#
当需要委派子代理执行复杂多步骤分析任务时，使用这个模式
适用于：微信文章深度分析、代码审查、文档生成、技术调研、竞品分析等需要多步骤+质量保证的子代理任务
不适用于：单步骤简单任务（直接调用工具即可）、需要主代理全程参与的任务、创意性强的任务（指令过于标准化会限制创造力）
核心做法#
指令结构标准化：按固定结构组织指令——目标URL/输入→分步骤流程(编号)→质量要求(6项)→输出格式规范
每个步骤有明确编号和标题
步骤之间有逻辑递进关系
总步骤数控制在7-9步（太少不够系统,太多难以执行）
内嵌验收标准：每个步骤明确"产出什么"，质量要求明确"达到什么标准"
每个步骤标注对应的AC（验收标准）编号
质量要求量化（如"提炼3-5个核心要点"而非"提炼核心要点"）
标注哪些是human-judgement（人工判断），哪些可程序化验证
上下文完整性：传递完整spec要求（功能需求+验收标准+非功能需求），不依赖子代理自行推断
将spec的关键FR和AC摘录到指令中
明确Non-Goals（不要做什么），防止子代理过度发挥
传递方法论参考（如"遵循内容漏斗模式"）
输出位置明确：明确指定输出是对话呈现还是文件落盘，避免歧义
对话呈现：在指令末尾说明"输出直接在回复中呈现"
文件落盘：明确指定文件路径和命名规范
注意区分"分析报告存档"与"Wiki教程创建"（前者是FR,后者是Non-Goal）
指令长度约束：标准化指令应控制在2000字以内，超过时考虑分步骤委派或提炼关键验收标准
超过2000字时，考虑拆分为2个子代理任务
或提炼为"核心验收标准清单"，省略详细步骤描述
关键质量要求不可省略，即使超出长度限制
反模式（不要这么做）#
❌ 指令省略质量要求：只说"分析这篇文章"，不说"提炼3-5个核心要点+5个方法论"——子代理产出质量不可控
❌ 输出位置模糊：未说明是否需要文件落盘，子代理按字面理解跳过存档——分析成果无法追溯
❌ 无验收标准映射：未将分析步骤与AC（验收标准）关联，无法验证产出完整性——质量门虚设
❌ 指令过长：超过2000字的指令降低子代理执行效率，关键信息被冗余描述淹没
❌ 依赖子代理自行推断：未传递完整spec要求，子代理按自身理解执行——产出与主代理预期不符
检验标准#
做完之后怎么知道做对了？
标准1（结构完整性）：指令包含目标输入、分步骤流程、质量要求、输出格式四个部分
标准2（验收可追溯）：每个步骤标注对应AC编号，可从产出反查验收标准
标准3（质量量化）：质量要求使用具体数字（如"3-5个""≥5条"），非模糊表述
标准4（长度合规）：指令总长度≤2000字，或已说明超长处理策略
标准5（输出明确）：明确指定输出是对话呈现还是文件落盘，文件落盘时含路径与命名规范
迁移示例#
这个模式还能用在什么其他场景？
场景1（代码审查子代理）：目标=代码文件→分步骤流程（结构分析/安全检查/性能评估/最佳实践对照）→质量要求（≥5条具体意见）→输出格式（Markdown报告）
场景2（文档生成子代理）：目标=主题描述→分步骤流程（大纲规划/内容编写/格式校对/链接验证）→质量要求（≥1000字,KE-4全要素）→输出格式（Markdown文件,指定路径）
场景3（技术调研子代理）：目标=技术关键词→分步骤流程（概念理解/方案对比/优劣分析/选型建议）→质量要求（≥3个方案对比）→输出格式（对话呈现+可选文件落盘）
验证案例#
案例编号 |
任务 |
验证日期 |
结果 |
|---|---|---|---|
kICrd |
Loop Engineering 14步文章分析(9步流程+6项质量要求) |
2026-07-04 |
✅ 产出质量高,5要点+5方法论+3认知模型 |
dy98 |
Orca IDE分析 |
2026-07-06 |
✅ 产出符合预期 |
3dnk |
Project N.O.M.A.D分析 |
2026-07-06 |
✅ 产出符合预期 |
配套模板#
标准化子代理分析任务指令模板见：.agents/templates/subagent-analysis-instruction-template.md
关联资源#
配套模式：双层分析报告结构
子代理交付检查清单：
.agents/templates/subagent-wiki-delivery-checklist.md