那段激活提示词逐句拆解：它到底在要求模型做什么
在 agency-agents 这个仓库里，strategy/QUICKSTART.md 给了一段可以整段复制的激活提示词。它长得很像一条命令，于是很多人的用法就是：打开 Claude Code，粘贴，回车，然后等着看会发生什么。
先把最容易误会的一点说在前面：这段文字不是命令，NEXUS 也不是调度器。divisions.json 的 _note 写得很直白——strategy/ 目录里存放的是编排方法论（orchestration doctrine），不是可安装的 agent。整套 NEXUS 就是一堆 markdown：strategy/nexus-strategy.md 有 1110 行，playbooks/ 下七篇合计 1907 行，coordination/ 两篇 758 行。没有任何一行代码在强制执行阶段顺序，也没有任何进程在卡质量门。这段提示词唯一的作用，是把这套方法论塞进模型的上下文，让模型自己按这个结构往下推。
理解了这一点，再逐句拆它才有意义。
一、原文照抄
QUICKSTART.md 里 NEXUS-Full 的激活提示词原文：
Activate Agents Orchestrator in NEXUS-Full mode.
Project: [YOUR PROJECT NAME]
Specification: [DESCRIBE YOUR PROJECT OR LINK TO SPEC]
Execute the complete NEXUS pipeline:
- Phase 0: Discovery (Trend Researcher, Feedback Synthesizer, UX Researcher, Analytics Reporter, Legal Compliance Checker, Tool Evaluator)
- Phase 1: Strategy (Studio Producer, Senior Project Manager, Sprint Prioritizer, UX Architect, Brand Guardian, Backend Architect, Finance Tracker)
- Phase 2: Foundation (DevOps Automator, Frontend Developer, Backend Architect, UX Architect, Infrastructure Maintainer)
- Phase 3: Build (Dev↔QA loops — all engineering + Evidence Collector)
- Phase 4: Harden (Reality Checker, Performance Benchmarker, API Tester, Legal Compliance Checker)
- Phase 5: Launch (Growth Hacker, Content Creator, all marketing agents, DevOps Automator)
- Phase 6: Operate (Analytics Reporter, Infrastructure Maintainer, Support Responder, ongoing)
Quality gates between every phase. Evidence required for all assessments.
二、第一行：模式名不是修辞
Activate Agents Orchestrator in NEXUS-Full mode.
NEXUS-Full 是三个模式之一，QUICKSTART.md 与 nexus-strategy.md 里的那张表是一致的：
| 模式 | 参与 agent 数 | 适用场景 | 周期 |
|---|---|---|---|
| NEXUS-Full | All（全部） | 企业级产品发布、完整生命周期 | 12–24 周 |
| NEXUS-Sprint | 15–25 | 功能开发、MVP 构建 | 2–6 周 |
| NEXUS-Micro | 5–10 | Bug 修复、内容战役、单一交付物 | 1–5 天 |
这里的周期是文档给出的建议时间尺度，不是承诺，也不是任何实测结果。真正要注意的是第二列：写 NEXUS-Full 就等于告诉模型「全部 agent 都在场」。仓库里带 frontmatter 的 agent 一共 255 个、分布在 17 个 division，你显然不可能把 255 份提示词同时喂进去。所以这一行的实际语义更接近「按完整生命周期的框架来组织回答」，而不是「真的把 255 个角色拉进会议室」。想做的只是一个功能或一次修复，把 NEXUS-Full 换成 NEXUS-Sprint 或 NEXUS-Micro，后面那七行也要跟着删——这段提示词是给 Full 模式写的，模式名和 Phase 列表必须自洽。
Agents Orchestrator 这个名字也不是随口起的，它对应花名册里的 agents-orchestrator，注意这个 slug 没有 division 前缀。
三、中间两行：唯一需要你动手改的地方
Project: [YOUR PROJECT NAME]
Specification: [DESCRIBE YOUR PROJECT OR LINK TO SPEC]
方括号是占位符，整段提示词里只有这两处是留给你填的。Specification 那一行允许「描述」或「给链接」两种写法——如果你的项目已经有一份 spec 文档，直接指过去比在提示词里复述一遍更省上下文，后面七个阶段的产出也才有一个统一的比对基准。
四、七行 Phase：每一行都对应一份 playbook
这七行不是随手列的清单，nexus-strategy.md 的章节结构与 playbooks/ 下的七个文件一一对应：
| Phase | 名称 | playbook 文件 | 行数 |
|---|---|---|---|
| 0 | Intelligence & Discovery | phase-0-discovery.md | 178 |
| 1 | Strategy & Architecture | phase-1-strategy.md | 238 |
| 2 | Foundation & Scaffolding | phase-2-foundation.md | 278 |
| 3 | Build & Iterate | phase-3-build.md | 286 |
| 4 | Quality & Hardening | phase-4-hardening.md | 332 |
| 5 | Launch & Growth | phase-5-launch.md | 277 |
| 6 | Operate & Evolve | phase-6-operate.md | 318 |
也就是说，提示词里那一行 Phase 4: Harden (...) 背后是 332 行的 playbook。模型不会自动去读这些文件，它只是拿到了阶段名和一串角色名。如果你希望某个阶段真的按 playbook 的粒度走，得把对应的 playbooks/phase-N-*.md 一起放进上下文，而不是指望模型凭阶段名脑补。这是这段提示词最容易被高估的地方。
Phase 3 那行的 Dev↔QA loops 也值得留意：它是七行里唯一显式写了循环关系的，其余六行都是并列的角色列表。
五、最后两句：整段提示词的立场
Quality gates between every phase. Evidence required for all assessments.
这两句短，但它俩是这段提示词的设计意图所在。「每个阶段之间都有质量门」对应 nexus-strategy.md 第 12 章 Quality Gates，「所有评估都要有证据」在花名册里甚至有一个专职角色 testing-evidence-collector——Phase 3 那行末尾点名的 Evidence Collector 就是它。
同样得说清楚：这两句是要求，不是保证。没有代码会在阶段之间拦一道。模型愿不愿意在没有证据时停下来，取决于模型和你后续的追问。
六、动手前：把点到名的角色先备齐
提示词里点名了 24 个显示名。它们都能在花名册里对上真实的 agent 文件，但显示名不是 slug。install.sh 的 USAGE 段里，--agent 收的是 <slug,slug>，只有 --agents-file 写明每行可以是「一个 slug 或名字」——两个入口的接受范围不一样，混着用就容易在某一处对不上。runbooks.json 的 _note 解释过为什么内部一律引用 slug：文件名主干并不总是带 division 前缀，而显示名带前缀、还会漂移，slug 才抗改名、可测试。统一按 slug 写，是这里唯一不用记规则的选项。
几个容易拼错的例子：
| 提示词里的显示名 | 花名册 slug |
|---|---|
| Agents Orchestrator | agents-orchestrator |
| Senior Project Manager | project-manager-senior |
| Studio Producer | project-management-studio-producer |
| Trend Researcher | product-trend-researcher |
| UX Researcher | design-ux-researcher |
| Analytics Reporter | support-analytics-reporter |
| Tool Evaluator | testing-tool-evaluator |
| Evidence Collector | testing-evidence-collector |
注意 project-manager-senior 和 project-management-studio-producer 这一对：同一个 division，两个 slug 的前缀写法都不一样。凭感觉拼 slug 在这里必错。
把 Phase 0 那一组先装进 Claude Code，可以这样写：
./scripts/install.sh \
--tool claude-code \
--agent agents-orchestrator,product-trend-researcher,product-feedback-synthesizer,design-ux-researcher,support-analytics-reporter,support-legal-compliance-checker,testing-tool-evaluator \
--dry-run
每个选项为什么在这：
--tool claude-code：不加就是「装到所有检测到的工具」。你大概率只用其中一个，收窄目标能避免在别的工具目录里留下一堆没人用的文件。--agent <slug,slug>：按 slug 精确选人。不加任何选择器就是全装，255 个 agent 一次性写进全局配置目录是有代价的（上下文占用、加载、命名冲突），这里用不到的就别装。--dry-run：只打印计划、不写任何东西。往~/.claude/agents/这种共享目录批量写文件之前，先看一眼计划是最划算的一步。
角色多的时候，把 slug 一行一个写进文件、改用 --agents-file <path> 会更好维护，该参数支持 # 注释。以上为按官方参数语义组合的示例，未逐项实测，以官方文档与 ./scripts/install.sh --help 的实际输出为准。
Windows 侧注意：install.sh 是 shell 脚本，脚本注释里写的平台支持是 Linux、macOS（bash 3.2+）、Windows 的 Git Bash / WSL。在 PowerShell 或 cmd 里直接敲这条命令是跑不起来的。
七、产出物与验收
去掉 --dry-run 之后，claude-code 这条链路的落点在 tools.json 里写得很明确：installKind 是 per-agent、format 是 identity，用户级目标路径是 .claude/agents/{slug}.md。per-agent 意味着每个 agent 一个文件，identity 意味着原样输出、不做格式改写。所以验收的第一步是去目录里数文件，而不是去看模型说了什么。
四个可执行的验收动作：
- slug 是否真实存在：
./scripts/install.sh --list agents列出后退出，拿你要用的 slug 去比对。仓库里还有scripts/check-runbooks.sh，职责就是守住「每个 slug 都能解析到真实 agent 文件」。 - 文件是否落在你以为的目录：Claude Code 的用户级和项目级模板都是
.claude/agents/{slug}.md，区别只在家目录还是当前项目目录。搞混了就会出现「装了但这个项目里没有」。 - 提示词自身是否自洽：模式名改了，Phase 列表跟着改了没有；
[YOUR PROJECT NAME]和[DESCRIBE YOUR PROJECT OR LINK TO SPEC]两个方括号是不是还留着没填。 - 阶段推进有没有跳步：这一条只能靠人看。提示词写了
Quality gates between every phase，但没有任何机制在执行它。
八、什么情况别用这一段
- 你的目标工具不是
per-agent的。Aider 的产物是一个CONVENTIONS.md、Windsurf 是一个.windsurfrules，installKind都是roster，所有 agent 合并成一个文件，谈不上「只把这 7 个角色装上」；Hermes 是唯一的plugin，只能走命令行。 - 你只是要修一个 bug。仓库里有现成的
incident-responserunbook，模式是 NEXUS-Micro，always组 6 个、post-fix组 4 个。它把取证、回测、流程优化、重排优先级放在修复之后单独一组——修完不算完，这个设计比整段 Full 提示词更值得抄。 - 你期待它自己跑完。再说一遍：没有调度器。阶段顺序和质量门都得你自己盯。
- 涉及合规、法务、安全的结论。
Legal Compliance Checker在提示词里被点了两次（Phase 0 与 Phase 4），但 agent markdown 里的人设文本是写给模型的角色设定，不是法务意见，这类结论必须人工兜底。
最后一句实在话：这段提示词的真正价值不在于「粘贴进去就有一条流水线」，而在于它用十几行把一套 1110 行的方法论压缩成了一个可以复述的结构。你把它拆开看懂了，剩下的事情才好办。
延伸阅读
本文依据 agency-agents 官方仓库（github.com/msitarzewski/agency-agents）的 README、
tools.json、divisions.json、strategy/ 下的 QUICKSTART.md、nexus-strategy.md、
playbooks/、runbooks.json 与 scripts/ 下的安装与校验脚本整理，核对日 2026-08-09。
仓库元数据为 2026-08-09 快照（star 140729），star 数不代表质量或适用性。
本文内容为仓库源码与文档口径，我们没有安装或运行过其中任何 agent，也没有按 NEXUS 跑过任何一次流程。
目录、脚本与安装路径随上游更新而变动，请以仓库最新内容与 ./scripts/install.sh --help 的实际输出为准。
许可条款请以官方 LICENSE 原文为准，本文不构成法律意见。