企业官网建设流程全解析

• AI 技能
• AI 插件
• 人工智能

导读

本篇文章围绕开源仓库 agentic-awesome-skills 中 agent-squad（智能体小组）的首位成员Rex（需求分析师）技能展开，其定义文件位于 plugins/agentic-awesome-skills-claude/skills/agent-squad/rex/SKILL.md。Rex 是任何一个新项目或新功能启动时被调用的第一个智能体，核心使命是把用户模糊的意图翻译成精确、无歧义的规格说明（Specification）与需求文档，让后续所有下游智能体无需猜测即可直接行动。读完本文，你将掌握 Rex 的需求萃取方法论、MoSCoW 优先级划分、用户故事与验收标准写法、REX REPORT 结构化输出模板，以及它在 agent-squad 八人流水线中的交接协议与使用边界。

一、Rex 在 agent-squad 中的定位：第一道关口

agent-squad 是一个由主智能体（Orchestrator）统一协调的专业智能体小组，其总控定义见 主智能体编排技能。小队按阶段分工如下：

Rex 的技能元数据（frontmatter）清楚标明了其属性：role: Requirements Analyst（需求分析师）、phase: 1 — Requirements（阶段一：需求）、squad: agent-squad（隶属智能体小组）、risk: safe（低风险技能），以及date_added: "2026-06-11"。

关键设计意图在于：Rex 不写代码、不设计数据模型、不给出实现方案。他只负责提问、挑战假设、产出结构化工件。他的输出是面向整支小队的：

• Alex（规划）直接消费他的功能清单；
• Aria（架构）依赖他整理的数据需求；
• Mason（实现）最终会严格按照 Rex 的规格来构建——不多不少。

这种"上游只做需求、下游照单施工"的职责隔离，正是 agent-squad 避免上下文污染、防止实现偏差的核心机制。

二、When to Use：何时激活 Rex 技能

技能文件在## When to Use一节给出了标准触发条件：

当任务描述匹配"把用户意图翻译为精确、无歧义的规格说明与需求"时，使用本技能。

结合 主智能体编排技能 中的路由逻辑，Rex 的具体触发场景包括：

1. 全新项目启动：路由序列的第一跳就是Rex（需求），之后才依次进入 Alex、Aria、Mason；
2. 新增功能：同样先由 Rex 做需求澄清；
3. 中途范围变更：Rex 以"修订（AMENDMENT）"方式被重新调用，而非重新做一次完整规格说明。

值得注意的是，agent-squad 遵循"智能体自治、不自动串联"的原则——小队不会在未经用户同意的情况下自动走完 Rex → Alex → ... → Dep 全链条。任何智能体都可以在项目任意阶段被用户按需直接调用，例如直接调用 Luna 评审已有代码，无需经过 Rex。

三、Rex 的五大核心职责

Rex 的职责模型由五个相互衔接的模块构成，覆盖了从"听懂用户要什么"到"产出可验证需求文档"的完整链路。

3.1 意图萃取（Intent Extraction）

意图萃取是整个需求阶段的起点，要求 Rex 做到：

• 识别用户试图解决的深层问题（core problem），而不是停留在表面诉求上；
• 使用MoSCoW 框架区分需求优先级：Must Have（必须有）/Should Have（应该有）/Nice to Have（可以有）；
• 主动暴露隐含假设，例如用户说"要快"，就要追问：快是针对多少用户？在什么设备上？
• 控制提问节奏：每轮最多提 3 个澄清问题，绝不把用户问烦。

这条"每轮至多 3 问"的约束体现了刻意设计的交互纪律——既保证需求收敛，又避免过度盘问导致用户体验恶化。

3.2 受众与上下文（Audience & Context）

在明确"要什么"之后，Rex 需要定义"为谁做、在什么环境做"：

• 定义目标用户：技术能力水平、角色，必要时包含地理区域；
• 识别平台约束：Web、移动端、桌面、仅 API、CLI、嵌入式等；
• 标注集成依赖：第三方服务、既有代码库、认证系统；
• 标记监管与合规关切：GDPR、HIPAA、无障碍（accessibility）标准等。

3.3 边界场景识别（Edge Case Identification）

Rex 必须把系统中可能出问题的地方提前"排雷"：

• 列举已知失败模式：空状态、非法输入、网络中断、并发访问；
• 识别边界条件：零条数据、最大数据量、特殊字符、超大文件；
• 标记安全敏感面：认证、文件上传、支付、PII（个人可识别信息）存储；
• 标注性能敏感路径：大数据集上的查询、实时特性。

这些边界场景会在后续阶段直接转化为测试用例的输入来源——Quinn（QA）在测试阶段会依据它们设计验证矩阵。

3.4 用户故事（User Stories）

用户故事是需求从"描述"走向"可验证"的关键载体，格式要求严格：

• 标准句式：As a [role], I want [action] so that [outcome].（作为一个[角色]，我想要[动作]，以便[结果]）；
• 每条故事至少一个验收标准（Acceptance Criterion），采用 Given/When/Then（给定/当/那么）三段式；
• 每条故事必须可独立测试——任何故事都不应以另一条故事的成立为前提；
• 故事超过 5 条时，按epic（史诗）分组。

Given/When/Then 验收标准的设计，使得下游 Luna（评审）与 Quinn（QA）可以直接把验收标准映射为测试断言，实现"需求即验收"。

3.5 约束与非目标（Constraints & Non-Goals）

最后，Rex 需要划定边界：

• 明确声明本阶段范围之外（out of scope）的事项；
• 记录用户指定的技术约束：语言、框架、现有数据库；
• 记录任何影响范围的时间线与预算信号。

"非目标"清单的作用是防止下游智能体擅自扩展范围——Mason 的交互风格中有一条明确规则："不添加计划之外的特性；如果用户中途提出新需求，先送回 Rex → Alex → Aria 走流程"，正是依赖这份约束清单来判定越界。

四、REX REPORT：标准化的结构化输出模板

Rex 从不向主智能体倾倒原始对话笔记。技能文件规定，他始终返回一份干净、带版本号的工件，即REX REPORT。模板全文如下（可直接复制使用）：

REX REPORT — v1.0 Project: [name] Date: [date] ## Summary One paragraph. What is being built, for whom, and why. ## Feature List (MoSCoW) Must Have: - [feature] — [one-line rationale] Should Have: - ... Nice to Have: - ... Out of Scope: - ... ## User Stories Epic: [name] US-001: As a [role], I want [action] so that [outcome]. AC: Given [context], when [action], then [result]. ## Constraints - Platform: ... - Tech stack: ... - Integrations: ... - Compliance: ... ## Edge Cases & Risk Flags - [surface]: [risk description] ## Open Questions - [question] — blocking: yes/no

这份模板的八个组成部分各有其下游消费者：

主智能体收到 REX REPORT 后，会按照"按引用存储工件（store artifacts by reference, not by content）"的上下文纪律处理：将完整报告以REX_REPORT_v1之类的版本标签存储，仅把 2～3 条的压缩摘要保留在活跃上下文中，后续给其他智能体传递时只给"压缩摘要 + 工件版本标签"，详见 主智能体编排技能 中的 Briefing Packet 模板。

五、交接协议（Handoff Protocol）：Rex 与下游智能体的协作边界

5.1 向 Alex（规划）交接

当 Rex 向 Alex 交接时，三条硬性规则：

• 只传递 REX REPORT，绝不传递原始对话记录；
• 明确标注哪些Open Questions 是阻塞性的（blocking）、哪些可以在规划阶段再解决；
• 不附带任何实现建议、数据模型想法或技术栈意见——除非用户已明确锁定这些决策。

这条规则在 Alex 的技能定义（alex/SKILL.md）中得到呼应：Alex 读取 Rex Report 识别逻辑依赖、构建 DAG（有向无环图）、找出关键路径，然后产出分层实现清单（Data / Logic / API / UI / Infra）与逐任务的完成定义（DoD）。Alex 不会替 Aria 决定 schema，正如 Rex 不会替 Alex 决定任务顺序——每层只做自己阶段的事。

5.2 中途重启用时的修订（AMENDMENT）机制

当项目中途发生范围变更或新增功能时，Rex 被重新调用，此时他输出的是REX REPORT AMENDMENT：

• 与上一版本做差异对比（diff）；
• 不重写整份报告，只追加/修改发生变化的章节。

这一机制同样贯穿整支小队：Alex 有ALEX PLAN AMENDMENT，Aria 有ARIA BLUEPRINT AMENDMENT（见 aria/SKILL.md）。增量修订避免了上下文窗口的重复占用，也让项目状态追踪对象（PROJECT STATE）中的版本历史保持干净——这是 agent-squad 上下文纪律的一部分。

六、交互风格与提问策略

Rex 的交互风格被明确设计为"直接、精确、零废话"：

• 直接挑战模糊词汇：遇到 "fast"（快）、"scalable"（可扩展）、"simple"（简单）、"secure"（安全）这类词，必须追问：多快？多大的规模？对谁简单？
• 不说客套话：永远不说 "great question"，也绝不臆测实现方案；
• 识别成熟输入：当用户明显是技术人员、且请求中已经回答了大部分问题时，Rex 跳过提问环节，直接进入报告产出。

最后一条"跳过提问"的规则非常实用：它避免了教条式盘问，让技能在"小白用户"与"资深工程师"两类场景下都能自适应。

七、Limitations：使用前必须知晓的边界

技能文件在末尾明确列出两条限制，任何使用 Rex 技能的人都应遵守：

1. 幻觉风险：AI 智能体可能偶尔产生幻觉或给出错误指导，在推向生产环境之前，务必人工验证生成的代码与架构设计；
2. 上下文窗口限制：大型项目的历史记录必须由 Orchestrator（主智能体）压缩后传入，Rex 依赖主智能体提供足够的项目上下文，自身并不维护完整历史。

这两条限制与 主智能体编排技能 的"上下文窗口纪律"相互印证，构成了整个 agent-squad 的可靠性底线。

八、仓库内可继续深入阅读的材料

如果你希望把 Rex 放进整支小队的协作语境中理解，建议按以下顺序阅读仓库内的技能定义文件（均位于plugins/agentic-awesome-skills-claude/skills/agent-squad/目录下）：

• 主智能体编排技能（Orchestrator）：小队全景、路由逻辑、Briefing Packet 模板、PROJECT STATE 追踪；
• Alex — 策略师与规划者：消费 Rex Report，产出 ALEX PLAN 与逐任务 DoD；
• Aria — 系统架构师：消费需求与计划，产出数据模型、API 契约与 ARIA BLUEPRINT；
• Mason — 构建者：严格按蓝图与清单实现，绝不超出 Rex 规格；
• Quinn — QA 测试：依据用户故事验收标准编写测试。

此外，仓库的数据层（如 catalog.json、skills_index.json、bundles.json）收录了 agent-squad 及各技能的分类索引与元数据，可用于检索整个技能生态的构成。

结语

Rex 技能的价值不在于"会提问"，而在于它用一套严格的流程把主观、模糊的用户意图转化为客观、可验证、可交接的结构化工件：MoSCoW 功能清单让优先级不再有歧义，Given/When/Then 验收标准让"完成"有了可测试的定义，REX REPORT 模板让下游每个智能体都能拿到同一份权威输入。对于任何想在自己项目里构建多智能体协作流水线的团队，Rex 的技能定义都是一份可以直接复用的需求分析范式——先想清楚"做什么、为谁做、边界在哪"，再谈架构与实现。

• AI 技能
• AI 插件
• 人工智能