feature-teardownlisted

# Feature Teardown 一个功能想法或一句用户抱怨进来，五步之内给出结论：**抄谁 / 我们已经有了改入口就行 / 换个解法 / 真得做。** ## 边界 **管**：单个功能级别的对比。别人怎么做、为什么做、我们有没有、还能怎么做。 **不管**： - 完整竞品简报（公司定位、pricing、win/loss、battle cards、market trend）→ 装有 product-management 插件时用其 competitive-brief，否则不在本 skill 范围 - 这个需求值不值得做的 KANO/RICE 结论 → [requirement-eval](../requirement-eval/SKILL.md)（本套件内） - 方向还没定、要发散多个方向 → 推荐上游 [addyosmani/agent-skills](https://github.com/addyosmani/agent-skills) 的 idea-refine - 开源库/能抄的代码 → [prior-art](../prior-art/SKILL.md)（本套件内） ## 当前产品从上下文解析，不预设 第 4 步要盘点"我们现有能力"，"我们"指哪个产品**每次都要确认**：用户当场说的、项目文档、 项目根配置、对话上文。**没有默认产品，也不要沿用其它会话或其它任务里出现过的产品。** 缺就问一句，不猜。 如果这轮压根没有"我们"（纯个人新项目，还没有存量产品），第 4 步跳过并说明跳过了。 ## 五步 ### 1. 谁做过 分三层，别只看直接竞品： - **直接** —— 同类产品的同一功能 - **间接** —— 用完全不同的形态解决同一个问题 - **替代** —— 不用软件怎么解决：Excel、手工流程、雇个人、**或者干脆啥也不做** "啥也不做"是最容易漏的一个选项，也经常是真实答案。 ### 2. 用户路径几步 不要停在"他们有这个功能"。写出从**触发**到**拿到结果**的完整步骤： - 入口在哪（用户怎么发现的） - 中间几步、每步要用户做什么决定 - 什么时候能看到结果、失败了怎么办 **步数和入口位置本身就是结论。** 同一个功能藏在三级菜单里和挂在首屏，是两个产品决策。 ### 3. 为什么做（反推，不是事实） 从可查的东西倒推动机：改版记录 / 发布说明 / 帮助中心措辞 / 应用商店更新日志 / 社区和评论区吐槽 / 招聘 JD。 回答两个问题：**他们在服务哪类人**、**解决这类人的什么问题**。 **这一步的产出全部标成推断，不能当事实用。** 写「推测：…，依据：…」， 依据拿不出来就写「动机不明」，不要编一个合理的故事。 ### 4. 自查：我们是不是已经有了 ⟵ 早退出闸门 先把需求升维：**这个功能在第一性原理上解决的是什么问题**（"要收藏功能" → "高频内容会被历史清理冲掉"）。 拿这个问题、而不是功能名，去核当前产品——同一个问题常常已经被另一个形态的功能解决了，按功能名查永远查不到。 核对必须有证据来源，按优先级： 1. **产品知识库**：按 [PRODUCT-CONTEXT 协议](../prd-writing/PRODUCT-CONTEXT.md)登记过知识库的， 先去知识库里查现有能力和历史方案，再下结论 2. **拿升维后的问题反问用户**："现在用户遇到这个问题时是怎么解决的？有没有部分解决它的功能？" 3.