反向拆解 · 从优秀成品里提炼可复用规律

唯一目标：看完一个好东西，不能停在「好」。要带走两样东西——能搬走的规律，和这周就能照做的第一步。 本技能是一套强制流程：把「觉得好」还原成结构与选择，再把选择分成「可迁移」和「只适合它」，最后落成动作。

定位（先认清自己只干什么）

输入是一个已经存在的具体成品，输出是面向用户自己处境的可迁移结论。 不评价好坏本身，不复述成品内容，不产出一份关于它的百科；只回答一个问题：「我想做的事，能从它身上搬什么、怎么搬、什么情况下搬了会翻车。」

触发与边界

启用：用户给出具体对象 + 学习意图，典型说法：

• 「这个页面/App/交互做得好，拆一下我们能学什么」
• 「这份方案/这套流程/这个看板好在哪，我照着做要注意什么」
• 「别人这个 prompt/技能/代码模块写得好，逆向分析一下」
• 「我也想做成这样，先帮我拆清楚它到底做对了什么」

不启用（命中即换技能或直接答）：

开工前先对齐两件事（信息缺口才问，别问满）

1. 想学走什么：同一张 Netflix 首页，想学信息架构、视觉层级，还是播放交互？目标不同，拆出的规律完全不同。用户已说明就别再问。
2. 要搬到哪去：用户自己的处境/项目/约束是什么（如设备、输入方式、团队规模、技术栈）。没有落点就没有「可迁移」的判断基准。

这两点上下文里能合理推断就直接推断并在开头一句话声明假设；只有猜错会导致整篇白拆时才问，且一次问清。用户只想「看懂它好在哪」、没有搬迁落点时照常拆解：此时把第 4 步做成「假设的成立前提」分析，第 6 步降级为「若要借鉴，先做什么」，不强行套具体项目。

拆解流程（六步，前一步喂给后一步）

不同类型对象（UI、代码、文档、Prompt）的专项检查维度见 references/teardown-checklists.md，动手前按对象类型读对应小节；下面六步对所有类型通用。

先判对象成色，再决定拆法：成品不一定真优秀。初步观察后若发现它平庸甚至有明显硬伤，不要硬凑 3 条优点——改为「可学之处 + 应避之坑」双栏，如实告诉用户它没那么值得抄。用户本来就说「帮我看看这个好不好」时同样走此路径。

1. 一句话定义它解决的问题

先用一句话说清：它为谁、在什么场景下、解决了什么问题；不是复述它有什么功能。 拿不准时区分「它宣称解决的」和「用户实际用它解决的」，两者不一致本身就是重要发现。

2. 还原结构与流程

把成品拆开摆出来：

• UI/产品：信息架构、页面层级、核心动线（用户从进入到完成目标经过几步）、状态。
• 代码/架构：模块边界、数据流向、关键抽象、扩展点、依赖方向。
• 文档/方案：论证骨架、章节如何咬合、每节承担什么推理任务。
• Prompt/技能：触发条件、输入契约、处理流程、输出契约、防呆与边界。

只描述能从对象中直接观察到的东西；看不到的内部实现标「推测」，不脑补。

取证充分性：静态截图/单页只支撑静态结论。涉及动效、转场、交互响应、操作动线时，必须看到实际运行（录屏、亲自操作，或宿主具备的视频抽帧/运行态取证能力），否则明确写「动态行为未取证」，不把想象的交互写成事实。对象是在线产品或会更新的材料时，注明观察日期或版本；「它就是这样设计的」和「它在某个版本里表现为这样」是两回事。

3. 找出拉开质量差距的关键选择

这是整套拆解的核心，不要停在罗列特征。对每个显著特征追问三层：

1. 它替代了什么更朴素的做法？（没有它的时候通常怎么做）
2. 朴素做法会在什么具体场景下出问题，而这个选择恰好解掉？
3. 这个选择额外付出了什么代价？（复杂度、成本、约束、牺牲掉的东西）

「好的选择」必然同时有收益和代价；只说得出好处说不出代价，说明没拆到位，继续挖。

代价分两级标注，不许用推测填满：可观察代价（成品里直接看得出的复杂度、多一步操作、性能/物料开销）直接写；推测代价（对其内部实现成本的猜测）标明「推测」。挖了仍看不到代价时，写「代价未在样本中暴露」，不能编一个对称的代价凑数。

4. 分离「可迁移规律」与「仅适用本案」

对每条规律做一次迁移审查，强制回答：

• 它成立依赖哪些前提条件？（用户规模、设备、团队、数据量、品牌、时代……）
• 搬到用户自己的处境，这些前提还在吗？
• 什么条件下它会失效甚至帮倒忙？

输出时必须分成两堆，不许混在一起：

• 可迁移规律：抽象到机制层、脱离本案仍成立的做法。
• 仅适用本案：由对方特有资源/约束/场景决定、搬走会水土不服的细节（如 Netflix 的定制封面图依赖其海量 A/B 实验与版权物料）。

把「仅适用本案」误报成「可迁移」是本技能最严重的错误，宁可多划几条进本案堆。

5. 提炼 3–5 条可复用规律

每条规律写成一句有机制、可操作的话，不是「设计要简洁」这类正确的废话。

• 合格写法：「每屏只保留一个主动作：遥控器没有 hover，并列按钮会成倍增加焦点移动成本，次要操作收进长按或二级入口。」
• 不合格写法：「界面要简洁、注重用户体验。」

每条规律标注它来自第 3 步的哪个选择、成立前提是什么。3–5 条封顶，凑不出 3 条说明对象可能没那么值得学，如实说。

6. 落成动作：操作清单 + 一个最小练习

• 可照做的操作清单：用户在自己项目里具体怎么落地，按动作写，每条可验收（改哪个文件/调哪个参数/先做哪张草图）。
• 一个最小练习：成本最低、可逆、当天到一周内能做完的一次试做，明确「做什么 / 观察什么 / 什么结果说明搬对了 / 什么结果说明该停」。
• 若用户的处境与对象差异过大，明确给出「不建议照搬的部分」，这比硬凑清单更有价值。

红线（违反任一条 = 拆解不合格）

• 禁止夸夸体：「高级、惊艳、业界标杆」这类无信息量形容词不进结论；每个「好」必须落到具体选择和机制。
• 禁止特征罗列冒充拆解：列出 10 个页面元素不是拆解，回答「为什么是这样而不是别的样子」才是。
• 禁止无代价的优点：说不出代价的选择，标注「代价未识别」继续挖，不直接封神。
• 禁止无条件迁移：每条规律不带成立前提和失效条件，不算产出。
• 禁止脑补：内部实现、未公开数据、看不到的逻辑一律标推测或不写；需要外部背景可检索，但要标来源，且不反客为主变成调研报告。
• 禁止凭名气拆解：必须接触成品本身（界面、代码、原文），不能据「大家都说它好」、获奖记录或二手转述开工；只能拿到转述时，明说证据是转述并降级结论，拿不到任何一手材料就停。
• 单样本纪律：一个对象只能拆出「它做对了什么」，不能得出「行业都该这样」的普遍结论；要普遍结论需要更多样本或外部证据（那是 outside-view 的活）。

可感知信号（触发宣告与收口）

命中本技能并完整走流程时：

• 开头一行轻量宣告：〔思考：反向拆解〕还原这个成品的结构和关键选择，分清哪些能搬到你这、哪些不能，让用户知道是哪个技能在起作用、这轮要做什么。一句话快答或顺带提一句时不贴标签。
• 收口自检多答一句：在结论后用一句话说明"这轮让你的下一步具体改变了什么"（例如把纠结缩成一个待查事实、给出一个本周可做的动作、指出一条不该照搬的点）。读完仍不知道下一步该干嘛，视为本次失败，重做。

好坏的用户体感判别与反馈话术见仓库 docs/SKILL-QUALITY-CARD.md。

输出形态

默认对话内结构化输出，顺序固定：

一句话：它为谁解决什么问题（含我的假设，如有）
结构与核心动线（简明，可用列表/图）
关键选择（3 个左右，每个写：替代了什么 / 解掉什么问题 / 付出什么代价）
可迁移规律（3–5 条，每条带前提与失效条件）
仅适用本案、别照搬的细节
落到我处境的操作清单（可验收动作）
最小练习（做什么 / 看什么 / 继续信号 / 停止信号）

• 用户要沉淀成文档（如「存到项目里」），写成 Markdown 放进用户指定的项目目录，结构同上。
• 用户要边拆边直接改自己的东西：拆完先给规律和清单并确认，再进入改动；本技能不擅自改代码。
• 篇幅与对象匹配：一个按钮交互几百字讲透，一个完整 App 可长；但规律永远 3–5 条封顶，不靠堆料显勤奋。
• 小节允许裁剪与合并：小对象把「结构 + 关键选择」合写、无搬迁落点时把后两节合为「借鉴前提与第一步」；但「关键选择 / 可迁移 vs 仅本案 / 动作」三项核心内容不能整段省略，顺序固定。

交付前自检（逐条过，不过不交）

• 已先判对象成色：平庸对象走「可学 + 应避」双栏，没有硬凑优点。
• 一句话问题定义说的是「为谁解决什么」，不是功能清单。
• 结构来自对成品的实际观察，推测处已标注；动态行为有运行证据或已声明未取证；在线对象注明观察时间/版本。
• 每条关键选择都回答了「替代什么 / 解掉什么 / 代价是什么」，代价区分可观察与推测，没有编造。
• 可迁移与仅适用本案明确分堆，每条规律带成立前提和失效条件。
• 规律是可操作机制句，没有「要简洁/要高级」式废话；数量 3–5 条（成色不足时如实减少）。
• 无搬迁落点时已降级为「借鉴前提 + 第一步」，没有硬套项目。
• 操作清单每条可验收，最小练习带继续/停止信号。
• 明确指出了至少一个「不该照搬」的点（若确实没有，说明理由）。
• 没有超出单样本能力的普遍性断言。

参考

• references/teardown-checklists.md：四类常见对象（UI/交互、代码/架构、文档/方案、Prompt/技能）的专项拆解维度。按对象类型读对应小节，不要整篇加载。