메뉴
产品需求分析方法论——竞品分析、用户画像、需求优先级排序、迭代层次设计、方案对比、非功能性需求分类。触发场景：(1) 讨论产品规划或功能设计，(2) 进行需求分析或竞品调研，(3) 设计迭代路径或优先级排序，(4) 用户说"PRD"、"需求文档"、"竞品分析"、"产品规划"、"需求优先级"、"迭代规划"、"方案对比"
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
归档管理——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 控制功能档位 | 用单枚举配置控制 |