企业官网建设流程全解析

claude-delegator 是一个 Claude Code 插件，可以直接把架构设计、代码审查、安全分析等复杂任务委托给 GPT（Codex）和 Gemini 专家子智能体。它的精华不仅在于"能委托"，更在于一套强制执行的7段式委托提示格式（Delegation Prompt Format）——相当于给 AI 专家写任务单的标准模板。本文带你深度拆解这 7 个段落各自的作用、如何填写，以及新手最容易踩的坑，让你学会写出专家一次就能干对的"任务单"。

为什么给AI专家写任务单，比随口吩咐更可靠？

很多人第一次使用 claude-delegator 时会问：我直接用自然语言说"帮我看看这段代码"不行吗？

问题出在专家的工作方式上。委托专家时，每次单轮调用（Single-Shot）都会开启一个全新会话，专家对你的项目一无所知。如果你的任务单里没有交代清楚背景，专家只能靠猜——猜错一次，浪费一次调用，还可能给出危险的建议。

项目文档 rules/orchestration.md 里有一条"成本意识"原则说得很直白：

一条结构良好的委托，胜过十次含糊的委托（One well-structured delegation beats multiple vague ones）。

7 段式格式本质上就是解决两件事：

1. 信息完整性：把"现状、代码、约束、禁区"一次性交齐，减少来回追问；
2. 结果可验收：提前定义"什么算成功"和"交付物长什么样"，避免拿回一堆无法落地的空话。

7段式委托格式总览：一张任务单的完整骨架

格式定义在 rules/delegation-format.md 中，被标记为MANDATORY（强制）——每一封委托提示都必须包含以下 7 段：

可以把它想象成三段式心智模型：

• 目标段（1-2）：定方向——做什么、做成什么样；
• 边界段（3-4）：定场域——现状如何、红线在哪；
• 执行段（5-7）：定验收——必做、禁做、交付格式。

下面逐段拆解每段该怎么写。

第1段 TASK：一句话、原子化、具体

1. TASK: [One sentence—atomic, specific goal]

TASK 要求一句话，且必须是"原子化"的具体目标。✅ 正确示范：TASK: 为注册接口增加输入校验；❌ 反面示范：TASK: 优化一下系统。任务越具体，专家越不容易跑偏。

第2段 EXPECTED OUTCOME：提前定义"成功"

2. EXPECTED OUTCOME: [What success looks like]

这一段的价值在于把验收标准前置。比如对 Plan Reviewer（计划评审专家），EXPECTED OUTCOME 就定义为APPROVE/REJECT verdict with specific feedback——明确告知专家：你要的不是泛泛而谈，而是一个"通过/驳回"的明确裁定加具体理由。没有这一段，你很可能收到一段正确但无用的分析。

第3段 CONTEXT：现状、代码、背景三件套

3. CONTEXT: Current state / Relevant code / Background

单轮会话意味着专家没有记忆，CONTEXT 就是它的"入职培训"。模板要求三个字段：

• Current state（当前状态）：系统现在长什么样；
• Relevant code（相关代码）：直接给出文件路径或代码片段，而不是让专家自己去翻；
• Background（背景）：为什么需要做这件事。

第4段 CONSTRAINTS：技术、惯例、限制

4. CONSTRAINTS: Technical / Patterns / Limitations

这里写的是"边界条件"：技术栈版本和依赖（Technical）、必须遵循的现有代码惯例（Patterns）、以及绝对不能触碰的部分（Limitations）。比如Must work with Node.js 18、Cannot change API response schema。这一段能防止专家引入你不想要的新依赖或破坏既有接口。

第5、6段 MUST DO / MUST NOT DO：必做与禁止清单

这两段是任务单里的"硬条款"，通常以列表形式给出。MUST DO 放硬性要求（如"提供工作量估算"、"报告所有修改过的文件"），MUST NOT DO 放红线（如"不要为假想的未来需求过度设计"、"不要改动范围外的文件"）。

正向指令 + 反向禁令组合起来，能把专家的行为收敛到一个很窄、很可控的区间里——这是提示工程里非常实用的约束技巧。

第7段 OUTPUT FORMAT：交付物的结构模板

7. OUTPUT FORMAT: [How to structure response]

最后一段规定专家怎么交作业。以 prompts/architect.md 为例，顾问模式下要求按Bottom line → Action plan → Effort estimate输出；实施模式下则要求Summary → Files modified → Verification。格式先定好，拿到结果才能直接验收、直接执行。

实战截图：一份7段式任务单长什么样？

下面这张 claude-delegator 实战截图中，可以完整看到 Claude 向 Architect 专家发起委托时发出的 7 段式任务单——TASK、EXPECTED OUTCOME、CONTEXT、CONSTRAINTS、MUST DO、MUST NOT DO、OUTPUT FORMAT 一段不少，专家据此返回了带工作量估算（Effort）和行动计划的分析报告：

这个例子也体现了整个插件的编排思路（详见 CLAUDE.md 的 Architecture 章节）：

用户请求 → Claude 识别触发信号 → 选择专家 → 组装7段式任务单 → 调用 MCP 专家 → 综合整理后回复

注意最后一步：Claude 只做"综合"（synthesize），绝不原样转发专家输出——它会替你再判断一次，这也是 claude-delegator 与简单转发工具的本质区别。

5位专家各有一份专属任务单模板

通用 7 段式格式之上，rules/delegation-format.md 还为五位专家分别准备了专属模板，把每类任务的高频要求预填好了，你可以直接照着填：

每位专家还可切换双模式：顾问模式（read-only沙箱，只分析不改代码）和实施模式（workspace-write沙箱，直接动手修改）。触发规则定义在 rules/triggers.md 中，比如你说 "is this secure" 就会自动路由到 Security Analyst。

新手避坑清单：写任务单时最常犯的6个错误

rules/orchestration.md 末尾有一张官方反模式表，把它翻译成任务单视角的"避坑清单"：

特别提醒最后一条：如果你需要专家连续干活（比如先实现再补测试），请使用多轮委托（Multi-Turn）——首次调用返回的threadId会让专家保留前几轮记忆；而单轮调用则必须把相关代码、前次尝试和报错全部写进 CONTEXT，一次给足。

小结：把"7段式"内化成你的提示习惯

claude-delegator 的 7 段式委托格式，说白了就是一套给 AI 写工作说明书的方法论：

1. TASK + EXPECTED OUTCOME——先定目标和验收标准；
2. CONTEXT + CONSTRAINTS——把局面和红线一次讲清；
3. MUST DO + MUST NOT DO + OUTPUT FORMAT——用硬条款锁定行为和交付物。

这套思路其实不限于 claude-delegator：无论你用 Codex 还是 Gemini，甚至给真人写需求文档，"目标 → 背景 → 边界 → 验收"的结构都同样奏效。想深入源码层面了解格式如何被加载执行，可以阅读 CLAUDE.md 和 config/providers.json，那里记录了专家提示与 MCP 工具的完整装配关系。