05 软件工程综合实践：检验一个工程主张
TL;DR：本篇用一个完整案例串起全专栏方法——检验"AI 编程 Agent 能提高团队效率"这个主张。流程：论证拆解（结论/前提/推理）→ Paul-Elder 要素检查 → 认知偏差识别 → 贝叶斯更新 → 判断证据是否足够。最终产出一页"论证审阅记录"，让未参与者能复述论证逻辑、定位薄弱点、判断证据强度。
概念解释
什么是"检验一个工程主张"
不是判断"对不对"，而是系统拆解论证的三个部分（前提/推理/结论），对每个部分施加五条标准，识别偏差，判断证据强度——最终产出"这个论证的薄弱点在哪、证据够不够支撑结论"的可审阅记录。
与其他专栏综合实践的衔接
本篇是"检验判断"阶段的综合实践。软件工程综合实践：做一次可复盘的技术选型（决策与权衡）串起决策前的全流程；本篇串起决策前的论证检验——在选方案之前，先检验"方案背后的论证是否成立"。
目录
| 章节 | 说明 |
|---|---|
| 案例与主张 | Agent 提高效率 |
| 串起全流程 | 从论证拆解到证据判断 |
| 一页论证审阅记录 | 可执行的模板 |
| 验收标准 | 怎样算检验到位 |
| 适用边界 | 本篇方法不替代什么 |
案例与主张
主张："引入 AI 编程 Agent 能将团队交付效率提升 30%。"
串起全流程
| 步骤 | 方法 | 产出 |
|---|---|---|
| ① 论证拆解 | 结论/前提/推理三层 | 结论="效率提升30%"；前提1="试点提交数+30%"；推理="提交数→效率" |
| ② Paul-Elder 检查 | 八要素逐一过 | 薄弱点：目的("效率"未定义)、假设("提交数代理效率") |
| ③ 偏差识别 | 四大偏差清单 | 确认偏差(只看成功案例)、锚定(被30%锚住) |
| ④ 贝叶斯更新 | 先验×似然→后验 | 先验40%(基础率)→案例后45%→实验后70% |
| ⑤ 证据判断 | 证据强度阶梯 | 单案例不够，需实验级证据 |
串联逻辑：论证拆解（①）定位结构 → Paul-Elder（②）定位薄弱要素 → 偏差识别（③）定位系统性扭曲 → 贝叶斯更新（④）量化信念变化 → 证据判断（⑤）决定证据够不够。如果 ⑤ 判断证据不足，回到 实验设计：AB 测试、灰度与消融实验 设计验证。
一页论证审阅记录
| 字段 | 内容 |
|---|---|
| 主张 | AI Agent 能将交付效率提升 30% |
| 结论 | 效率提升 30% |
| 前提 | ① 试点提交数+30% ② 提交数代理效率 ③ 试点能代表全量 |
| 推理方式 | 归纳（从试点到一般） |
| 推理路径 | 提交数↑ → 效率↑（相关当因果+代理指标失真） |
| Paul-Elder 薄弱点 | 目的("效率"未定义)、假设(②③未验证)、推理(跳跃) |
| 认知偏差 | 确认偏差(只看成功)、锚定(30%)、幸存者(只看采纳的) |
| 贝叶斯更新 | 先验40% → 案例45% → 机制50% → 实验后70% → 护栏触发后60% |
| 证据判断 | 当前证据不足——需 A/B 测试验证因果 |
| 下一步 | 设计对照实验，控制工作复杂度和团队成熟度 |
验收标准
论证检验是否到位，看四件事：
- 三层都拆了：结论、前提、推理各被拆出并检查。
- 薄弱点被定位：不是笼统说"不太对"，而是明确哪一步失效。
- 偏差被识别：至少一个认知偏差被指出。
- 证据强度被判断：当前证据是否够支撑结论，不够该用什么实验补。
适用边界
- 不需要每个主张都完整拆解：低风险主张快速判断即可。
- 拆解不替代实验：定位薄弱点后，关键假设仍需因果验证。
- 论证审阅不是否定：它的目的是让结论可被审阅，不是否定所有技术主张。
- 一页记录可被修正：随着证据积累，审阅记录应更新。
关联笔记
- 批判性思维总览：从主张到可检验论证（三层拆解和五条标准）
- Paul-Elder 框架：思维要素与智力标准（八要素检查）
- 论证结构：前提、推理与结论（论证拆解模板）
- 认知偏差：系统性错误的模式（偏差检查清单）
- 贝叶斯更新与新证据：信念该改变多少（信念更新量）
参考资料
评论 (0)