在构建方案时补齐被跳过的体验层（最后20%），让成品不再像…

当你规划或验收任何构建任务，需要把「体验层」像管道一样具体地定义并完成时使用。

适用场景

解决思路

1. 先写下「魔法时刻」场景：一个具体的人、真实任务、看到什么、为什么会推荐给同事；写不出场景就说明缺的正是那 20%，先补上。提出 2–3 个候选场景并给出推荐，绝不给用户留空白页。
2. 把场景逐步拆解成「场景清单」：列出魔法时刻发生所必须为真的一切（输入什么、怎么知道去哪、页面长什么样、答案为何在第一段、链接从哪来、第一天摄取未完成时看到什么）。
3. 用「场景清单减去名词清单」得到最后 20%：名词清单是拆解交付物名称得到的（摄取、鉴权、schema、API、部署），残差部分归入固定类别——内容与语气、信息架构、首次运行与空状态、有主见的默认值、黄金路径、失败体验、命名与微文案；对照 references/last-20-catalog.md 查漏。
4. 把每个场景清单项写成与「接口返回 200」同等具体的完成标准：例如「页面可读」→「每个页面开头先用 2–4 句直接回答，再展开细节；小节标题就是读者真正会问的问题；每条论断链接到来源文档」；「好的空状态」→「零结果搜索显示最接近的三个页面和一键『请求此页面』，绝不显示光秃秃的『无结果』」。
5. 当系统产出制品（wiki 页面、报告、邮件、仪表盘、生成代码）时，先手工打造最佳实例再建生成器：用真实语料、真实主题写出理想页面；该黄金制品同时充当规格、测试夹具和质量门槛。绝不在黄金制品里用 lorem ipsum 或占位内容。
6. 在构建模式中拒绝把 20% 排在最后：黄金制品先于生产它的机器；体验决策（页面类型、默认值、语气、导航）在相关管道建成时当场决定，不攒到「打磨周」；把场景清单作为「完成清单」保留在计划或追踪器中，每项带完成标准，未勾选项等同于失败测试。
7. 构建声称完成时执行「走查」：以冷启动的终端用户身份，无内部知识，字面执行魔法时刻——去 Sarah 会去的地方、输入她会输入的内容、读她会读的内容，全程走完。
8. 把走查结果对照黄金制品和完成清单，写下走查与场景之间的每个差距（读起来像填充物的页面、死气沉沉的首次运行、让用户替产品做决定的默认值），修复后再次走查。
9. 走查循环以两种状态之一结束：走查交付了魔法时刻 → 说明并展示证据（实际读过的页面、实际走过的流程）后停止；剩余差距需要人类产品决策 → 逐条列为决策并各附推荐选项后停止。
10. 计划模式：构建请求刚到时，先跑阶段 1–4 塑造计划，再在宣布完成前跑阶段 5。审计模式：方案已存在时，先从走查（阶段 5）收集证据，回填魔法时刻与场景清单（阶段 1–2），再规格化并补齐差距（阶段 3–4）后再次走查。
11. 始终带着主张：主动提出默认值、页面结构和语气并给出理由；只对真正不可逆或真正业务战略性的决策提问，且即便提问也附上推荐。
12. 把预算花在体验残差上，不要美化可用的基础设施；若某个想法不服务于魔法时刻，就放进 someday 清单，而不是加功能。
13. 允许方案通过：若走查交付了魔法时刻，就说「完成了」并停止；为显得周全而制造差距本身就是一种劣质产出。

适用边界 · 注意事项

• 需要的是扩展功能广度时——最后 20% 是核心场景的深度，加功能是披着收尾外衣的反向失败。
• 想重写可用的基础设施让它内部更漂亮时——不要对管道镀金。
• 走查已交付魔法时刻时——不要为显得周全而制造差距。