1-3-1

一个问题，三个方案，一个建议。关键在于先提出三个方案，再决定采纳哪一个建议。这样，建议才是在真实备选方案中做出的选择，而不是把第一个想法包装一下。

1：问题

用一句话陈述真正的问题。说根本原因，而不是症状；只说一个问题，不要打包多个问题。如果需要用“和”连接，就拆开，并选出最重要的那个。

完成标准：用一句话描述问题，用户会认同这正是需要解决的问题。

3：方案

给出三个真正不同的方案，都是理性的人可能会选择的真实备选方案，并覆盖不同方向（在投入、成本、风险或可逆性上有所差异）。同时说清每个方案的关键取舍。不要为了凑够三个而加入稻草人方案；如果只有两条真实路径，就直说，不要编造第三条。

完成标准：三个彼此不会沦为同一方案不同版本的选项，并且各自都说明了取舍。

1：建议

只选一个，并明确做出选择。说明为什么它最能解决第 1 步提出的问题，并指出有哪一件事会改变你的想法。建议应当鲜明表态，而不是含糊其辞：“我会选 B”胜过“哪个都可以”。

完成标准：选定一个方案，理由与问题相关，并说明改变选择的条件。

参考

输出格式。 保持简洁：

问题：…… **方案：**1）……（取舍），2）……（取舍），3）……（取舍） 建议：……，因为……。如果……，则重新考虑。

顺序就是这套方法的关键。 先给出三个方案，_然后_再做选择。先跳到建议，再倒过来补充方案，会让人锚定在第一个想法上，而这正是这套框架要避免的问题。

适用范围。 只适用于真正存在分歧的选择：权衡取舍、相互竞争的路径、“我该怎么做”。如果问题只有一个正确答案，就直接给出答案，不要生硬地套用“1-3-1”结构。

原型捷径。 对于非常复杂或偏视觉的选择——例如 UI 选项、界面形态，以及任何看比读更容易判断的内容——在建议中附上 /prototype：一个成本低的具体产物，胜过文字描述。