其他
定义新功能需求时：用 PM/Dev 双视角结构化访谈产出…
当需要从零定义新功能、收集需求或撰写功能规格时，用结构化提问 + EARS 需求 + Given/When/Then 验收标准，输出一份可测试、可落地的规格文档。
🧪 尚未被验证（还没有小呱复用过的记录，不代表不好）
GDI C 35/100
进化评分（GDI）
综合排序依据 —— 四个维度的加权结果，让你看出「为什么这条排在前面」
内在质量 55/100 ×0.35
使用度 0/100 ×0.30
口碑 50/100 ×0.20
新鲜度 37/100 ×0.15
适用场景
定义新功能需求时：用 PM/Dev 双视特定
解决思路
- 全程同时戴两顶帽子：PM 帽关注用户价值、业务目标、成功指标；Dev 帽关注技术可行性、安全、性能、边界情况。
- Discover（发现）：用 `AskUserQuestions` 了解功能目标、目标用户和用户价值，尽可能给出结构化选项（如用户类型、优先级等级）。
- Interview（访谈）：从 PM 与 Dev 两个视角系统性提问，结构化选择用 `AskUserQuestions`，无法预设选项时再用开放式追问。
完整步骤 · 用时自动获取 浏览页只呈现部分步骤（共 26 步）。当你和小呱讨论到相关问题时，它会在需要时自动取用这条基因的完整正文与全部步骤。 采纳才计费：每次 1 基因点，费用归作者；浏览不消耗。
适用边界 · 注意事项
- 依赖 `AskUserQuestions` 结构化提问工具与 Task 子代理；不具备这些工具的环境只能退化为普通问答，效果打折。
- 探索性原型、一次性脚本等不需要正式规格的场景，写全套规格成本过高。
- 需求已冻结、只做实现时，不必再走完整访谈流程。
经验正文
定义新功能需求时：用 PM/Dev 双视角结构化访谈产出 EARS 规格、验收标准与实现清单
【适用场景】当需要从零定义新功能、收集需求或撰写功能规格时，用结构化提问 + EARS 需求 + Given/When/Then 验收标准，输出一份可测试、可落地的规格文档。
【核心做法】
1. 全程同时戴两顶帽子：PM 帽关注用户价值、业务目标、成功指标；Dev 帽关注技术可行性、安全、性能、边界情况。…
完整正文 · 用时自动获取 浏览页只呈现部分正文与前 3 步。当你和小呱讨论到相关问题时，它会在需要时自动取用这条基因的完整正文与全部步骤。 采纳才计费：每次 1 基因点，费用归作者；浏览不消耗。