企业官网建设流程全解析

多智能体预调研提示词实战：用并行 Discovery 为 Feature Forge 需求规格工作坊注入技术证据

【免费下载链接】claude-skills67 Specialized Skills for Full-Stack Developers. Transform Claude Code into your expert pair programmer.项目地址: https://gitcode.com/GitHub_Trending/claud/claude-skills

导读

在 Feature Forge 需求规格工作坊开始之前，如果团队对代码库、安全约束和 API 现状一无所知，访谈很容易变成一轮又一轮的"探索式提问"，既浪费时间又依赖猜测。本仓库 docs/prompts/discovery-for-feature-forge.md 提供了一份可直接复用的多智能体预调研提示词：在访谈前并行启动多个 Task 子智能体，各自调用对应技能（architecture-designer、security-reviewer、api-designer 等）收集技术证据，再综合为结构化摘要、提炼关键决策并启动 Feature Forge 访谈。读完本文，你将掌握这套提示词的完整结构、按功能类型裁剪智能体组合的方法，以及它背后的 ReAct + 思维链设计原理，并能直接替换功能描述后投入实战。

一、为什么需要"预调研"而非直接访谈

Feature Forge 的核心工作流本身分为五个阶段：Discover（用AskUserQuestions理解目标）、Interview（系统性提问）、Document（编写 EARS 格式需求）、Validate（评审验收标准）、Plan（生成实现清单）——参见 skills/feature-forge/SKILL.md。

问题在于：当新功能跨越多个领域（认证、数据库、UI、外部服务）时，访谈者对被调研代码库的理解是空白的。此时启动访谈，只能提出泛泛的问题，无法围绕"现有的用户模型怎么设计的""当前项目的 API 遵循什么分页约定""文件上传有哪些历史安全坑"展开有依据的追问。

预调研提示词正是为此设计：它把"探索"从访谈阶段前置到访谈之前，让子智能体并行收集技术事实，访谈只聚焦"决策与取舍"。这与 Feature Forge 官方参考文档 skills/feature-forge/references/pre-discovery-subagents.md 中描述的"前置加载技术上下文"模式完全一致——其适用条件包括：功能触及 3 个以上系统层、代码库陌生或文档不足、需要先拿到具体技术事实再提问、干系人时间有限需要减少来回沟通。

二、提示词全文与逐段拆解

以下为仓库中该文档的核心提示词（可直接复制使用）：

I need to define a new feature: [FEATURE DESCRIPTION]. Before we start the Feature Forge specification workshop, run parallel discovery across the relevant domains to build technical context. Launch the following Task subagents concurrently — each should invoke its respective skill and return a focused summary: 1. Architecture Discovery — Launch a Task subagent (general-purpose) that invokes the architecture-designer skill to: - Identify which system components this feature touches - Map integration points and data flows - Flag architectural constraints or trade-offs - Recommend patterns that fit the existing system 2. Security Discovery — Launch a Task subagent (general-purpose) that invokes the security-reviewer skill to: - Identify authentication and authorization requirements - Flag data sensitivity concerns (PII, PCI, GDPR) - Surface OWASP-relevant risks for this feature type - Recommend security patterns and controls 3. Codebase Discovery — Launch a Task subagent (Explore) to: - Search for existing patterns, components, or utilities related to this feature - Identify code conventions and abstractions already in use - Find similar features that can serve as implementation templates - Note relevant test patterns and coverage expectations 4. API/Integration Discovery — Launch a Task subagent (general-purpose) that invokes the api-designer skill to: - Propose API surface area (endpoints, methods, payloads) - Identify existing API patterns to follow for consistency - Flag external service dependencies and rate limits - Recommend versioning and backwards-compatibility approach Wait for all subagents to complete, then: 1. Synthesize — Combine the findings into a structured discovery summary with sections for: Architecture, Security, Codebase Patterns, and API Surface. 2. Identify Decisions — List the key decisions that emerged from discovery (e.g., "sync vs async processing", "new table vs extend existing"). Present these as AskUserQuestions with structured options. 3. Launch Feature Forge — With the discovery context and user decisions in hand, invoke the feature-forge skill to begin the specification workshop. The interview should reference discovery findings rather than re-asking questions the subagents already answered.

2.1 四路并行的 Discovery 分工

提示词定义了四条平行的探索轨道，每条轨道对应一个子智能体与一项仓库技能：

值得注意的细节：Codebase Discovery 使用 Explore 类型的子智能体而非 general-purpose，因为它的任务是纯粹的文件系统检索（搜索现有模式、约定、模板），不需要额外的专家技能层；而另外三条轨道都明确要求"调用各自技能"，让架构、安全、API 领域的专家知识进入收集环节。

2.2 子智能体技能在仓库中的实际能力

提示词引用的三个技能在本仓库中均有完整实现，可以从 skills/architecture-designer/SKILL.md、skills/security-reviewer/SKILL.md、skills/api-designer/SKILL.md 中印证各自的"必做/必不做"约束与输出模板：

• architecture-designer：以主架构师视角工作，核心工作流是"理解需求 → 匹配模式 → 设计（显式记录取舍并产出图表）→ 用 ADR 记录关键决策 → 干系人评审"。它强制要求把技术决策写成 ADR（如ADR-001: Use PostgreSQL for Order Storage，包含 Status / Context / Decision / Alternatives Considered / Consequences / Trade-offs 六段结构），并强制评估权衡而非只讲好处——这与预调研中"Flag architectural constraints or trade-offs"的要求一一对应。
• security-reviewer：其工作流是 Scope → Scan → Review → Test and classify → Report。预调研阶段子智能体需要产出的是"认证授权需求、数据敏感性、OWASP 风险"，对应它的 Scope 与 Review 阶段；而其 MUST DO 中的"Check authentication/authorization first"（先检查认证/授权）正是 Security Discovery 轨道的第一项任务。技能自带的 OWASP Top 10、CWE、CVSS 等知识参考域，为风险标注提供了标准术语支撑。
• api-designer：其工作流覆盖"建模资源 → 设计端点 → 制定契约 → Mock 验证 → 规划演进"。预调研要求"propose API surface area"（对应资源建模与端点设计）、"flag rate limits"（对应其 MUST NOT DO 中的"Omit rate limiting considerations"）、"recommend versioning"（对应其"Version APIs with clear deprecation policies"约束）。该技能还内置了 OpenAPI 3.1 可复制的端点模板与 RFC 7807 Problem Details 错误响应格式，可作为 API Surface 结论的落地骨架。

2.3 汇合后的三步收尾

提示词明确要求等待所有子智能体完成后再执行三步：

1. Synthesize：把四路结果合并为结构化的 discovery summary，固定包含 Architecture、Security、Codebase Patterns、API Surface 四个小节；
2. Identify Decisions：列出从 discovery 中涌现的关键决策（如"同步 vs 异步处理""新建表 vs 扩展现有表"），并用AskUserQuestions以结构化选项呈现给用户——这正是 Feature Forge 的 MUST DO 约束"UseAskUserQuestionstool for structured elicitation"的体现；
3. Launch Feature Forge：带着 discovery 上下文与用户决策调用feature-forge技能启动工作坊，且访谈必须引用已有发现，"不再重新问子智能体已经回答过的问题"。

三、用法：基本调用与智能体裁剪

3.1 基本调用

把[FEATURE DESCRIPTION]替换为功能一句话描述即可。原文档给出的示例：

I need to define a new feature: user-facing data export that supports CSV and JSON formats with scheduled recurring exports. Before we start the Feature Forge specification workshop, run parallel discovery...

替换后，四路子智能体将围绕"数据导出 + CSV/JSON + 定时重复导出"并行展开：架构轨道分析导出任务对现有服务、存储、调度器的影响；安全轨道排查数据导出涉及的权限与敏感数据（很可能命中 GDPR 的 data portability 需求）；代码库轨道检索项目里已有的导出工具类或相似实现；API 轨道设计导出端点、格式参数与调度接口。

3.2 按功能类型裁剪智能体组合

并非每个功能都需要全部四条轨道。原文档给出了推荐裁剪表，可直接套用：

这条表的背后逻辑是"按功能触碰的领域决定探索深度"：纯 UI 功能主要依赖代码库检索与架构影响分析，无需展开安全与 API 设计；而认证/权限功能是安全高风险区，Security 必须参与。该思路与 skills/feature-forge/references/pre-discovery-subagents.md 中的"When NOT to Use"一致——若功能被严格限定在单一领域、或团队已有深度代码库认知、或需求纯属业务/UX 层面，可以完全跳过预调研。

3.3 预期的输出流程

原文档用流程图描绘了从用户输入到最终规格文档的完整链路：

User provides feature description │ ├─→ [Parallel] Architecture Discovery ──→ Component map, constraints ├─→ [Parallel] Security Discovery ──────→ Auth reqs, data sensitivity ├─→ [Parallel] Codebase Discovery ──────→ Existing patterns, templates └─→ [Parallel] API Discovery ───────────→ Endpoint design, integrations │ ▼ Synthesized Discovery Summary │ ▼ AskUserQuestions: Key decisions from discovery │ ▼ Feature Forge Interview (informed by discovery context) │ ▼ EARS Specification Document

终点产物是 EARS 格式的规格文档，其结构在 skills/feature-forge/references/specification-template.md 中有完整定义：Overview、Functional Requirements（EARS 格式）、Non-Functional Requirements、Acceptance Criteria（Given/When/Then）、Error Handling 表、Implementation TODO 清单、Out of Scope、Open Questions。功能需求句式的语法细节（Ubiquitous / Event-driven / State-driven / Conditional / Optional 五种模式）可参考 skills/feature-forge/references/ears-syntax.md，验收标准的 INVEST 标准与错误场景写法可参考 skills/feature-forge/references/acceptance-criteria.md。

四、设计原理：ReAct × 思维链 × 结构化启发

原文档明确指出，这份提示词应用了提示工程中经典的ReAct + Chain-of-Thought模式：

• ReAct（Reasoning + Acting）：每个子智能体都是"推理-行动"链上的一环——它调用技能（Action）、收集发现（Observation）、再向前传递结果（Feed forward）。四路子智能体互为对方的观察源，最终汇入主智能体的推理过程。
• Chain-of-Thought：Synthesize 步骤强制在主智能体进入 Feature Forge 访谈之前，显式推理"发现之间如何关联"。这一步等价于思维链中的中间推理步骤，避免"拿到零散素材就直接提问"的跳跃。
• 结构化启发（Structured Elicitation）：关键决策以AskUserQuestions的形式、携带由技术证据推导出的选项浮出水面，而不是空泛地让用户拍脑袋。例如"同步 vs 异步"这类决策，在被子智能体确认数据量级和外部服务限流之后，选项就有了依据。

这种设计的工程价值在于并行执行降低了总延迟：四条轨道并发运行，而不是针对每个领域按顺序向用户追问一轮，从而压缩了整个 pre-workshop 阶段的时间成本。从实现层面看，Feature Forge 的 Interview 阶段同样内置了多智能体预发现模式——skills/feature-forge/references/interview-questions.md 的"Multi-Agent Pre-Discovery"一节给出了同构的并行模式（general-purpose 子智能体调用 architecture-designer / security-reviewer，Explore 子智能体检索代码库），并提供了 PM Hat 与 Dev Hat 两套提问框架：PM Hat 关注问题、用户、价值、范围、成功指标、优先级；Dev Hat 关注集成、安全、性能、边界情况、数据、依赖。预调研的输出恰好填充了 Dev Hat 的大部分问题空间。

五、落地建议与工作流衔接

1. 把预调研提示词当作模板而不是脚本：优先按 3.2 节的裁剪表删除无关轨道；若功能横跨 3 个以上系统层且代码库陌生，可进一步参考 skills/feature-forge/references/pre-discovery-subagents.md 中的"用户头像上传"示例（Architecture 分析用户模型与存储、Security 排查文件上传风险、Framework Expert 查项目端点与存储方式），细化每个子智能体的任务描述。
2. 定义好"聚焦摘要"的边界：提示词要求每个子智能体"return a focused summary"，避免探索结果变成长篇报告，这能显著降低合成阶段的处理负担。
3. 与项目 Discovery 阶段的关系：本仓库的工作流中还存在独立的 docs/workflow/discovery-phase.md 研究阶段（discovery:create→discovery:synthesize→discovery:approve），面向"访谈中浮现的、需要人类调研（用户访谈、竞品分析、技术 spike）才能回答的未知项"。两者互补：本文的提示词解决的是"访谈前的代码库技术证据前置"，而 Discovery 阶段解决的是"访谈后仍存疑的业务与技术未知项"，最终都汇入规格文档与工单创建。
4. 从结果反推规格文档：Synthesize 生成的 discovery summary（Architecture / Security / Codebase Patterns / API Surface）应当被 Feature Forge 访谈"消费"而不是存档——访谈中的 Dev Hat 提问（集成、安全、性能、边界、数据、依赖）可以直接引用其中的证据，使最终产出的 EARS 规格文档 skills/feature-forge/references/specification-template.md 中每条功能需求都有代码库或安全分析背书。

六、结语

多智能体预调研提示词的核心价值在于把"猜测"替换为"证据"：在 Feature Forge 工作坊开始前，通过并行子智能体把架构影响、安全约束、代码库现状和 API 设计一次摸清，让访谈专注于真正需要人来拍板的决策点。这套模式融合了 ReAct 的行动-观察循环、思维链的显式综合与AskUserQuestions的结构化启发，并且与仓库中 architecture-designer、security-reviewer、api-designer 三个技能的约束和输出模板形成了完整的证据链。直接复制提示词、替换功能描述、按功能类型裁剪轨道，即可在当前项目中立即投入使用。

【免费下载链接】claude-skills67 Specialized Skills for Full-Stack Developers. Transform Claude Code into your expert pair programmer.项目地址: https://gitcode.com/GitHub_Trending/claud/claude-skills