Menu
产品需求分析方法论——竞品分析、用户画像、需求优先级排序、迭代层次设计、方案对比、非功能性需求分类。触发场景：(1) 讨论产品规划或功能设计，(2) 进行需求分析或竞品调研，(3) 设计迭代路径或优先级排序，(4) 用户说"PRD"、"需求文档"、"竞品分析"、"产品规划"、"需求优先级"、"迭代规划"、"方案对比"
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
归档管理——Task 归档与 Recording 物理归档的双轨机制、触发条件、手动步骤、验证清单。触发场景：(1) 终态任务数超阈值，(2) session 文件数超阈值，(3) 用户说"归档"、"archive"、"清理"
纠偏与误判排查方法论——退化信号检测、四行重写模板、止损序列、六类泛化误判排查表、与 BLOCKED 的边界判定。触发场景：(1) 出现退化信号（反复纠偏/目标漂移/证据缺失等），(2) 需要纠偏恢复，(3) 排查误判，(4) 判断是 correction 还是 BLOCKED，(5) 用户说"纠偏"、"偏了"、"不对"、"重写"、"止损"、"误判"
积木式能力验证方法论——判断「直接做 vs 先验证」、将不确定性分层隔离、沉淀可复用能力资产。触发场景：(1) 讨论技术可行性或方案选型，(2) 评估某个实现的不确定性，(3) 决定直接集成 vs 先做 Demo 验证，(4) 分析能力复用或知识沉淀策略，(5) 用户说"积木"、"Demo"、"能力验证"、"不确定性"
产品文档工具——正向（需求→文档）或逆向（代码→文档）两种模式。触发场景：(1) 为已有产品还原/补全文档，(2) 为新功能/模块编写产品文档，(3) 用户说"写文档"、"还原文档"、"doc"、"产品文档"
阶段边界决策锚点——四段式判断（启动/实施/验收/纠偏），含正例/反例/边界例。覆盖：基线失败处理、不确定性决策、入口门控、大幅度判定、执行偏差分级、并行串行选择、超前实施、Done 人工确认、blocked_by 判定、循环依赖、continuous_mode 续跑、recording 写入时机、decisions.md 写入时机。触发场景：(1) 需要做阶段边界决策，(2) 判断幅度大小，(3) 选择并行还是串行，(4) 判断是否需人工确认，(5) 用户说"判断"、"决策"、"幅度"、"并行"、"确认"
Session 记录写入方法论——文件格式模板、踩坑经验四段式记录、时间戳获取规则、最低合法答案、归档聚合指引、Stop hook 检测正则。触发场景：(1) 写 session 记录，(2) 记录踩坑经验，(3) Session 结束前整理，(4) 用户说"记录"、"recording"、"踩坑"。铁律：必须 date 命令获取时间戳。
| name | dprd |
| description | 产品需求分析方法论——竞品分析、用户画像、需求优先级排序、迭代层次设计、方案对比、非功能性需求分类。触发场景：(1) 讨论产品规划或功能设计，(2) 进行需求分析或竞品调研，(3) 设计迭代路径或优先级排序，(4) 用户说"PRD"、"需求文档"、"竞品分析"、"产品规划"、"需求优先级"、"迭代规划"、"方案对比" |
| argument-hint | [产品名] [对比维度] [目标用户] |
| context | fork |
| agent | general-purpose |
| allowed-tools | ["WebSearch","Read","Write","Edit","Grep","Glob","Bash"] |
| effort | high |
产品需求分析方法论知识库。提供竞品分析、需求分级、方案对比等可复用框架，适用于任何产品规划和需求讨论场景。
搜索竞品：使用 WebSearch，关键词组合：
"{产品类型} competitors""{核心功能} best tools {年份}""{目标用户} solutions"整理对比表：产品名称 x 核心功能维度，每格填写具体实现方式
| 产品 | 功能A | 功能B | 定价模式 | 差异点 |
|---|
差异化分析：
| 问题 | 目的 | 好的回答 | 坏的回答 |
|---|---|---|---|
| 要解决什么问题？ | 明确痛点 | "团队会议录音无法快速定位关键决策" | "提高效率" |
| 目标用户是谁？ | 圈定范围 | "每周至少 3 次团队会议的项目经理" | "所有人" |
| 核心场景是什么？ | 锚定用法 | "会后 5 分钟内找到某个议题的讨论结论" | "管理会议" |
| 层次 | 含义 | 规则 |
|---|---|---|
| Layer 0（Demo 验证） | 结果不可预期的能力验证 | Layer 0 未通过时 Layer 1 不得开始 |
| Layer 1（必须） | 核心业务，不可拆分 | 最小可用产品 |
| Layer 2（增强） | 提升体验，依赖 Layer 1 | Layer 1 完成后才开始 |
| Layer N（扩展） | 可选功能 | 优先级由业务价值决定 |
核心原则：Layer 越高依赖 Layer 越低，不可倒置。
何时需要 Layer 0（Demo）：
| 判断标准 | 可预期（直接集成） | 不可预期（需 Demo） |
|---|---|---|
| 有现成模式吗？ | 标准 REST CRUD、已有模式的 SSE | Prompt 效果、LLM 输出格式 |
| 结果可控吗？ | 输入-输出关系确定 | 依赖外部模型或不确定因素 |
名称必须体现能力而非产品功能。判断标准：换一个产品，这个 Demo 还能用吗？
hera-meeting-citation（产品特定）prompt-citation-stability（通用能力）| Demo 名称 | 验证什么不确定性 | 对应 Layer 1 功能 |
|---|
每条 Layer 0 对应一行。名称用 kebab-case，直接作为 /ddemo 的输入参数。
每条指标必须包含：
| 要素 | 说明 | 示例 |
|---|---|---|
| 口径定义 | 分子/分母 | "活跃用户 = 7 天内至少使用 1 次核心功能的注册用户" |
| 判定频率 | 多久看一次 | "周级" |
| 达标线 | 量化目标 | ">= 60%" |
不允许只写达标线不写口径。
格式：若 X 连续 N 天触发 -> 执行 Y
必须写明：
维度 x 方案 A/B/C，每格必须是具体描述：
| 维度 | 方案 A | 方案 B |
|---|---|---|
| 开发成本 | "3 人周，需新建 2 个服务" | "1 人周，复用现有网关" |
| 性能 | "P99 延迟 200ms，需缓存层" | "P99 延迟 50ms，直连数据库" |
推荐必须包含两部分：
论证方式：
五维约束识别：
| 维度 | 判断问题 | 约束类型 |
|---|---|---|
| 业务约束 | 100 年后还成立吗？ | 不随实现变化的本质规则 |
| 时序约束 | 有没有执行路径可以绕过这个规则？ | 状态转移、执行顺序 |
| 跨端约束 | 如果两个端定义不同，这是 bug 吗？ | 多端一致性要求 |
| 并发约束 | 两个线程同时做这件事会出问题吗？ | 并发安全规则 |
| 感知约束 | 超过这个阈值，用户会注意到吗？ | 用户体验底线 |
需求："用户通过蓝牙设备录音，设备断开时自动切换到手机麦克风继续录音"
识别约束：
按角色/层分组：
| 分组 | 覆盖内容 | 示例 |
|---|---|---|
| AI 行为 | 模型输出异常、超时、格式错误 | "LLM 返回空内容时显示默认提示" |
| 客户端 | 网络异常、状态不一致、UI 边界 | "离线时缓存最近 10 条记录" |
| 后端 | 服务不可用、数据一致性、限流 | "SMTP 不可用时返回 EmailServiceError" |
写作规范：
涉及"显示/隐藏"类需求时必须输出：
| 触发条件 | 阈值 | 设计依据 |
|---|
不允许留给实现方自由发挥。
@State 不能安全持有 Timer -> 必须用 @StateObject class 包装，deinit 中清理@SuppressLint("CheckResult") 是订阅泄漏的信号 -> 必须用 CompositeDisposable 管理每端一张：| 需求点 | 推荐改动文件 | 说明 / 验收 |
明确不做的事：不重构现有网络层 / 不引入新依赖管理框架 / 不修改与本需求无关的 ViewModel / Adapter
| 反模式 | 症状 | 正确做法 |
|---|---|---|
| 陈列式写作 | 段落以"这是 X"罗列，缺少因果推理 | 改为"因为 X → 所以 Y → 因此 Z"的论证式 |
| 脊梁缺失 | 核心洞察只出现一次或埋在中间章节 | 在开头立论、中段论证、结尾收束，至少 3 次 |
| 排除式论证 | "A 不行…B 不行…所以选 C" | 正向论证"选 C 因为…"，备选作切换条件 |
| 凑数字 | 量化指标无推导过程（85% 为什么不是 80%？） | 补推导过程，或标注"待验证"+验证方法 |
| 机械 diff | "继承/替换/新增"列表，无判断 | 改为"为什么保留 X"的判断论述 |
| 重复表达 | 多个表/段换角度说同一件事 | 合并为一处，选最有力的角度 |
| 零价值章节 | 删掉后文档完整性不受影响 | 删掉或合并入相邻章节 |
| 章节断裂 | 读完第 N 章不知为什么要读第 N+1 章 | 调整顺序或补充过渡 |
| 只写达标线 | 成功指标无口径定义 | 补充分子/分母和判定频率 |
| 线性路径 | 只写 Phase 1→2→3 无决策节点 | 每阶段间加量化决策门槛 |
| 模糊评价 | 方案对比用"快/慢/高/低" | 每格写具体数值或实现描述 |
| 只有 happy path | 验收条件无异常场景 | 每层至少一条边界/异常用例 |
| 产品命名 Demo | Demo 名体现产品功能而非能力 | 换产品还能用才是正确命名 |
| 多开关组合 | 多 Boolean 控制功能档位 | 用单枚举配置控制 |