办公效率 编辑复核
团队决策日志条目
用问题、选项、证据、取舍和复查时间记录决策，防止几周后只剩下“当时大家同意了”。
PROMPT WORKBENCH
复制后替换变量
保留结构，先填真实信息，再把结果交给模型运行。
你是一名团队决策记录员。请把讨论结果整理成可回溯的决策日志，保留不同意见和不确定性，不把共识伪装成证据。
先区分已知事实、合理假设和待核验信息；没有依据的内容写“待验证”，不要为了完整而猜测。
请按以下结构输出：
1. 记录日期、决策问题、负责人和截止时间
2. 列出考虑过的选项、依据、取舍和未选择原因
3. 写明决定、适用范围、执行动作和风险 owner
4. 定义复查日期、触发条件和需要重新决策的信号
输入变量：
- 决策问题（{{question}}）：说明需要决定的事项和时间压力。
- 证据（{{evidence}}）：提供数据、代码、用户反馈和来源。
- 选项（{{options}}）：列出至少两个备选和不做选项。
- 负责人（{{owners}}）：说明决策、执行和复查角色。
约束：保留用户的真实语气和业务边界；把事实、推断与建议分开；涉及日期、价格、版本、法规或安全的内容写明来源和采集时间。HOW TO USE
使用说明
- 会议结束当天写日志，避免依赖记忆补写。
- 复查时记录实际结果和决策是否需要调整。
WHEN IT FITS
适用判断
适合这些情况
- 团队做出了会影响后续的决定。
- 需要让没参与讨论的人理解决策背景。
- 未来可能有人质疑这个决定。
换个做法更好
- 你要记录的是个人决策：用《决策日志条目整理》。
- 决定随时可以改：记录的价值不大。
- 决策还在讨论：用《多方案决策备忘录》。
FAILURE MODES
常见翻车与修正
- 只记了结论，没记当时的约束条件。
脱离约束的决策看起来都很蠢。要求记录当时的时间压力、资源限制和已知信息范围。
- 记录带有事后正确性的修饰。
要求严格记录决策当时的判断，事后验证的结果单独追加，不改动原始记录。
- 没有记录反对意见和提出人。
要求记录讨论中的不同意见及其理由，这在决策出问题时是最有价值的信息。
ACCEPTANCE
怎么判断输出合格
- 记录了当时的约束条件和信息范围。
- 没有事后修饰，追加信息单独标注。
- 保留了反对意见和理由。
- 写明了重新审视的触发条件。
SAFETY BOUNDARY
使用边界
- 决策日志会长期留存并被追溯，涉及人员评价和未公开信息的内容不要写入。
- 模型会替你补出当时并未讨论过的理由，记录只写实际发生的讨论。