决策矩阵
加权决策矩阵能将“我无法决定”转化为可辩护、可检查的数字——但这个数字的价值取决于其背后的标准、权重和研究。你的工作是思考（什么重要、重要到什么程度、每个选项实际表现如何），而不仅仅是填充表格。最终的 HTML 报告是做好思考的副产品，而非练习的核心。
1. 检查决策是否适合此方法
此方法在以下场景中表现出色：有 2-8 个离散选项 且存在 多个相互冲突的标准（更便宜 vs. 更好、更快 vs. 更安全）。以下情况则过于繁琐或不适用：
- 实际上只有一个关键因素（“哪个更便宜”）——直接给出答案即可。
- 是二选一的决策，而非多个选项间的选择。
- 选项空间几乎无限（例如，尚无候选列表的“我该住在哪里”）——先帮助用户缩小候选范围，再对候选列表运行矩阵。
如果适合，简要说明并继续执行——不要让用户向你证明使用决策矩阵的合理性。
2. 一次性信息收集——不要逐个字段询问
先问“决策是什么”，再问“选项有哪些”，然后问“什么对你重要”，再逐一询问每个标准的权重——这会将原本2分钟的决策变成15条消息的拉锯战。请一次性询问决策、选项以及大致的优先顺序，并给出示例，让用户知道一个好的回答有多容易：
“您要决定什么？有哪些选项？您最看重什么？大致描述即可，我会将其转化为清晰的比较。例如：‘在3个工作邀约中做选择——Acme、Globex 以及留在当前公司 (Initech)。我最关心薪酬、成长空间以及通勤时间不要太长。’”
如果用户只给出简单的回答（仅有选项，没有优先级），也没关系——直接进入第3步，主动提出优先级建议，而不是再次询问。
3. 提出一个可编辑的草稿——标准、定义和权重一起给出
不要先收集标准，再单独收集权重。研究一下这类决策通常关注什么（工作邀约和公寓不会共享相同的标准），然后一次性返回一个完整的草稿——5-10个标准，每个标准附带一行定义和建议权重（1-10）——供用户一次性编辑，而不是从空白页面进行头脑风暴或逐一询问。如果用户自己的列表超过约10个标准，请温和地提出合并或删除重复项的建议（仍然在同一个草稿内，不要先征求意见）。
允许用户以最方便的方式回答——一个数字，或只是“高/中/低”（大致映射为 9/6/3）——并且接受诸如“看起来没问题”或“删除通勤，把薪酬调到10”这样的简短回复。发送的内容示例：
“这是一个用于比较工作邀约的草稿——可以编辑任意行、添加/删除一行，或者直接说‘看起来没问题’：
标准 含义 重要性 (1-10) 薪酬 第一年总包（薪资+奖金+股权） 9 成长 在该职位上我能学到/成长多少 8 通勤 典型工作日通勤时间 6 稳定性 两年后该职位/公司存在的可能性 7 团队与文化 同事和日常工作氛围的好坏程度 7 还需要添加什么吗？比如健康保险或远程办公的灵活性？”
草稿确认后，有两件事比人们预期的更重要：
- 保留每个标准的定义，不要让它退化为一个简单的标签。“成长”有歧义；而“成长 = 第一年在该职位上学到多少”则是可评分的。如果没有定义，你的评分会在不同选项间出现不一致。
- 注意那些实质上重复计算同一件事的标准（例如，“薪资”和“财务安全”通常可以合并为一个因素）——合并它们可以保持权重的诚实性。
4. 锁定并继续
通常一轮编辑就足够了——一旦用户确认（或没有提出异议），就将标准、定义和权重视为已锁定，直接进入第5步的研究。不要再次要求用户重新确认你已经展示过的数字；如果后来需要更改某些内容（例如，某个标准无法评分），请说明你在更改什么以及为什么，而不是重新打开整个草稿征求批准。
5. 研究并为每个选项×标准单元格评分 (1-10)
这一步是真正的工作所在，也是代理比普通模板更有价值的地方。对于每个单元格：
- 实际研究它——在评分之前，使用搜索/工具查找相关事实（价格、规格、评级、薪资数据、评论、政策）。不要凭空捏造一个听起来精确的数字。
- 在同一个标准内一致地锚定评分尺度。 在评分第一个选项之前，确定对于这个标准，1分和10分分别代表什么（例如，“10 = 这些选项中最便宜的”或“10 = 满足所有必要条件”），并在所有选项中保持这个锚点，使分数具有可比性。在每个标准的记事中写下该锚点。
- 为每个单元格提供一句理由，说明数字背后的事实或来源。这个理由能使报告值得信赖，并会在 HTML 报告的“原因”切换按钮中显示。
- 在不确定时要说明。 有些标准本质上是主观的（例如，“兴奋度”、“直觉”）或缺乏文档记录。应根据用户自己的判断来评分，并在理由中标注这是主观/未经验证的，而不是以虚假的精确性呈现。切勿捏造来源。
6. 计算加权总分
对于每个选项：加权得分 = Σ(权重_i × 分数_i) / Σ(权重_i)，一个归一化的 1-10 平均值。这使总分与输入的 1-10 尺度保持一致，便于进行合理性检查。
7. 首先提供 Markdown 表格
在构建 HTML 之前，先在聊天中显示结果，作为一个表格：选项作为行，按从最佳到最差排序；标准作为列（仅显示分数，以保持可读性）；最后一列为加权总分。随后用 2-3 句话说明最佳选项、亚军，以及区分它们的最重要因素——如果前两名非常接近以至于“赢家”实际上是并列的，请明确指出。
8. 构建交互式 HTML 报告
编写一个符合以下模式的 JSON 数据文件，然后运行：
python3 scripts/build_report.py data.json report.html
这会将你的数据注入到 assets/report_template.html 的引擎中，并写入一个独立的 report.html（无服务器、除一个 Google 字体外无外部资源——通过双击文件即可打开）。该脚本会验证数据，如果缺少内容或超出范围，则会显示具体的失败信息。
数据模式
{
"meta": {
"title": "我应该租哪套公寓？",
"subtitle": "比较同社区的 4 个房源",
"description": "一两句简短的上下文说明。显示在标题下方。",
"direction": "ltr",
"credit": "决策矩阵由 <你的名字> 生成",
"credit_url": "https://github.com/mrachny/decision-matrix-skill"
},
"criteria": [
{ "id": "rent", "label": "月租金", "description": "10 = 四个中最便宜的，1 = 最贵的。", "weight": 9 }
],
"options": [
{ "id": "optA", "label": "Elm 街公寓", "included": true }
],
"scores": { "optA": { "rent": 7 } },
"notes": { "optA": { "rent": "₪5,200/月，四个中第二便宜的 (来源：房源列表)。" } }
}
meta.direction为"ltr"或"rtl"；省略则默认为"ltr"。- 报告页脚默认显示一行小的“由决策矩阵生成”署名。
meta.credit/credit_url可覆盖其文本/链接；如果用户明确不希望有任何署名行，则将meta.credit设置为false。 criteria[].description和notes是可选的，但强烈建议提供——它们会成为报告中显示的“原因”文本。没有描述的标准或单元格将不显示理由，这对于快速草稿来说可以接受，但会削弱报告的可信度。options[].included（默认值为true）设置报告初始的静音状态。- 每个分数必须是一个 1-10 的数字。构建脚本会在写入任何内容之前检查此限制以及
criteria/options/scores之间的 ID 一致性。
告诉用户文件的位置，并说明文件可以直接在任何浏览器中打开——权重和静音切换会实时重新计算排名，数据不会发送到任何地方，除非用户保存文件，否则不会保存任何内容。
9. 邀请进行敏感性检查
最后指出，报告的目的是供用户探索，而不仅仅是阅读：如果关闭最不确定的标准或微调权重会改变胜出者，这是一个真实的信号，表明决策很接近，值得更多思考（或者差异并不重要，只需凭直觉/成本/最容易逆转的选择即可）。如果排名在这样试探下仍然稳健，那也是有用的信号。
参考文件
references/method.md— 方法背景、常见评分陷阱（相关标准、权重压缩、锚定偏移）以及如何与用户讨论平局。assets/report_template.html— 报告引擎。通常不需要手动编辑；所有可自定义的内容都通过 JSON 数据文件传递。scripts/build_report.py— 构建报告；运行python3 scripts/build_report.py --help查看上面所示的使用方式。examples/laptop-purchase.json— 一个填充好的示例数据文件，如果你想在编写自己的文件之前查看一个完整的示例。