技术方案评审
提取方案取舍、未讨论的风险与验收标准
用这个方法分析
上传录音或转写文本即可，未登录会先引导登录
产出长什么样
示例下面是一段虚构场景的示例产出，用来说明形态。真实分析会锚定你自己录音里的原话。
场景：某在线教育平台技术委员会，对“支付系统升级至微服务架构”方案进行内部评审，时长 35 分钟。
技术方案评审产出
| 评审维度 | 评分 (1-5) | 依据原话 | 缺什么 / 推断 |
|---|---|---|---|
| 方案与取舍理由 | 4 | “选择微服务架构是权衡了‘长期维护成本和团队当前能力’的结果，虽然初期复杂度高，但解决了模块耦合问题。” ——张经理 | 缺对比方案：未见对“保持单体重构”方案的量化比较。 |
| 关键风险识别 | 3 | “大家提到了性能抖动和部分接口不兼容，但未讨论新旧系统并行期间的数据同步一致性保障。” ——记录员总结 | （此为已识别风险，下一项为未讨论风险） |
| 未被讨论的风险 | N/A | 1. 合规风险：未提及新规下的支付数据存储要求变化。 |
- 历史数据兼容性：迁移后旧订单的查询性能未被评估。
- 团队技能：对前端团队学习曲线未做安排。 | 列表基于会议流程分析，非直接引用。 | | 验收与回滚标准 | 2 | “验收标准是‘系统稳定运行一周’。回滚的话，应该能切回去。” ——李老师 | 证据不足：回滚标准模糊，原文无依据说明具体操作（如数据回流机制、切换时间点）。 |
结论：方案在技术选型上逻辑清晰，核心风险已被部分识别，但执行层面的保障措施（特别是回滚与并行期管控）存在明显空白，需补充细化。最终通过的关键条件是解决“新旧系统并行期间的数据一致性”，如原文所述：“这段时间的数据不能出任何问题”。
什么时候用它
用在内部会议这类录音上。当内容里出现下面这些信号时，它最派得上用场：
架构方案讨论
输出的 4 个模块
产出形态是评分表，不是一段分析文字——有形态才能沉淀、才能被下游用。
- 1方案与取舍理由
- 2未被讨论的风险
- 3可逆性评估
- 4验收与回滚标准
它怎么保证不瞎说
亲证锚定
置信分层
证据不足时它会说「本场没有可供分析的对象，缺的是什么」，而不是编一个结论—— 这是硬要求，不是客套话。
常见问题
- 技术方案评审适合分析什么样的录音？
- 适用于内部会议。典型触发信号：架构/方案讨论。一场录音即可。
- 用技术方案评审会拿到什么？
- 产出形态是评分表，包含 4 个模块：方案与取舍理由、未被讨论的风险、可逆性评估、验收与回滚标准。
- 技术方案评审不做什么？
- 不得把单一用户的说法当成群体结论