编程开发 编辑复核
技术选型对比与决策记录
按团队真实约束比较几个候选方案，写出取舍理由、被放弃的选项和推翻条件，形成可追溯的决策记录。
PROMPT WORKBENCH
复制后替换变量
保留结构，先填真实信息，再把结果交给模型运行。
你是一名技术决策记录撰写人。请根据给定约束比较候选方案，输出一份能被后来者复核的决策记录。
先把已知事实、合理假设和待核验信息分开；资料不足时写“待验证”，不要为了完整而猜测。
请按以下结构输出：
1. 写清决策背景，包括业务目标、时间窗口、团队规模和现有技术栈
2. 把评估维度列成清单，标明哪几项是硬约束、哪几项是加分项
3. 用同一套维度逐个对比候选方案，缺少数据的格子写待验证
4. 给出结论和主要理由，明确为此接受了哪些代价
5. 记录被放弃的方案和放弃原因，便于以后翻查
6. 写明出现什么条件时需要重新评估这个决策
输入变量：
- 决策背景（{{decision_context}}）：说明要解决的问题、时间窗口和团队情况。
- 候选方案（{{candidate_options}}）：列出正在比较的方案及各自已知信息。
- 硬约束（{{hard_constraints}}）：说明预算、合规、运维能力和兼容性限制。
约束：保留原始上下文和限定条件；每个结论都说明依据；涉及个人资料、合同、财务、医疗或安全信息时先提示脱敏和人工复核。HOW TO USE
使用说明
- 先定硬约束再比较，能直接淘汰的方案不必细算。
- 对比表里不要留空格，没查到的写待验证并注明由谁去核实。
WHEN IT FITS
适用判断
适合这些情况
- 几个方案各有支持者，讨论一直收敛不了。
- 决策要向上汇报或留档给接手的人。
- 想提前写下什么情况会推翻这次选择。
换个做法更好
- 决策容易反悔且成本很低：直接试，不必写记录。
- 还不清楚需求边界：先做需求澄清。
- 只是升级现有依赖版本：走依赖升级风险评审。
FAILURE MODES
常见翻车与修正
- 对比表里的性能和价格数据是模型编的。
要求每个数字标注来源或标为待验证，并在定稿前逐项核对官方文档。
- 结论只写优点，看不出付出了什么代价。
强制补充接受的代价、放弃的能力和后续可能产生的维护成本。
ACCEPTANCE
怎么判断输出合格
- 硬约束与加分项分开列出。
- 所有候选用同一套维度对比。
- 结论写明了接受的代价和被放弃的方案。
- 未核实的数据全部标为待验证。
SAFETY BOUNDARY
使用边界
- 价格、配额、服务等级和合规资质必须以官方文档为准，模型给出的数字一律标为待验证。
- 涉及数据出境、支付资质和个人信息处理的结论要交法务或合规确认。