舵舟Agent需求助手

解决什么问题

在 Agent 项目启动前，业务方常带着模糊想法（如“用 AI 自动处理客户工单”）找到研发，但双方存在明显的认知鸿沟。业务人员不懂 Agent、Skill 或大模型边界，技术人员不理解业务判断逻辑与隐性规则。这导致需求沟通效率低下：最终文档要么充斥着空泛的 AI 概念，要么缺失关键的验收标准与权限边界定义。本 Skill 的目标是作为沟通桥梁，将业务人员大脑中的隐性经验，转化为结构统一、可指导技术设计的正式需求文档。

核心机制与工作流

该 Skill 将访谈过程拆解为清晰的推进步骤，确保对话可控且有明确产出：

• 四种模式按需切换：

- 从零编写：针对仅有初步想法的用户，从还原真实业务任务开始逐步梳理。
- 补充完善：基于已有草稿提取信息并标记状态，只追问核心缺口，绝不重复询问。
- 需求审查：加载 references/quality-checklist.md 对现有文档进行逐项质检，输出分级报告。
- Skill候选拆分：仅在需求确认后，识别可复用的独立能力单元，输出给技术方案评审。

• 信息状态管理：严格区分“材料记载”“已确认”“合理推断”与“待确认”。文档中只写入已确认内容，推断内容必须经过用户二次确认，禁止为了填满模板而编造事实。

• 统一成文标准：采用固定的《Agent需求文档模板》。当六项核心条件（目标用户、真实任务、现行做法、业务问题、核心工作、人机边界）齐备时，产出《Agent需求文档说明书》；否则产出《Agent需求梳理稿》，并明确提示暂不具备技术设计条件。

适用边界与注意点

本 Skill 不替代产品经理的职责，也不负责具体的技术架构设计（如模型选型、接口定义、代码实现）。它的核心价值在于需求结构化与业务语言翻译。

1. 输入质量决定输出质量：如果业务方无法描述真实的业务场景与痛点，仅靠 Skill 无法凭空生成高质量需求。
2. 非技术导向：在模式一至三中，严格避免讨论 MCP、提示词或模型参数。只有在进入“Skill候选拆分”时，才会探讨业务层面的能力边界。
3. 人机边界是红线：涉及高风险、不可逆操作或系统写入时，Skill 会强制要求明确人工确认节点，不会默认 Agent 拥有完全决策权。