PRD 用户手册生成器

要解决的问题

PRD 是写给开发和测试看的，充斥着技术术语与实现细节；用户手册是给终端客户看的，两者受众完全不同。手动把 PRD 改写成手册，意味着大量重复劳动：把「核心痛点：计算机专业学生不擅长写代码」翻译成「让不会写代码的你也能轻松分析数据」，把「AI Agent 将自然语言转化为 SQL」改写为客户能懂的表述，再逐条落实操作步骤、按钮位置与异常场景。这个过程既耗时，又容易遗漏关键信息。

核心能力

这个技能的核心是一套 PRD → 手册的信息映射机制。它按章节定义了映射规则，例如：

• PRD §1.1 产品定义 → 手册 §1.1 产品简介（技术视角改写为客户价值视角）
• PRD §3 意图体系 → 手册 §3 功能列表（每个意图对应一个功能）
• PRD §6.7 异常侧边界 → 手册 §4.2 异常处理（每个异常改写为「检查 → 自助修复 → 联系支持」三步）

工作流分为 7 个阶段（Phase 0–6）：从定向（读取 PRD、确认基本信息）到产品概述、前置准备、核心功能操作指南、注意事项与异常处理、联系方式与版本记录，最后是全局评审。每个阶段先从 PRD 提取信息，提取不到才向用户提问；生成内容后先展示摘要确认，再写入文件。

关键约束与注意点

几个值得留意的设计：

• 三档复杂度模式：简洁 / 标准 / 详尽，决定是否包含截图占位、视频教程链接、术语表等模块
• 强制模块检查：版本修订记录、每个功能的视频教程入口、不同角色的权限说明，评审阶段缺一不可
• 输出格式规范：界面指引必须标注位置（如「左侧导航栏 → 新建文档」），而不是含糊的「点击新建按钮」
• 断点续写与增量更新：中途暂停会记录进度标记，下次可恢复；已有手册也可只补全薄弱章节

适合 PRD 结构相对规范的团队。若 PRD 缺失信息较多（联系方式、版本更新内容通常不在 PRD 里），技能会密集提问，需要人工提前备好素材。它不生成 API 文档——那是另一个交付物。