S03-A24 · 可行性的论证：怎么证明这件事能做

评审会上有一句话把讨论终结了："这个方案可行。"所有人都点了头。三个月后卡在数据上——方案假设需要的字段有三年历史，而实际只留了 90 天，方案本身没错，错在没人去证明那个假设。

"可行"是个空词：它不指向任何可核对的事实。可行性必须按维度拆开，每一维都得落到"用什么证据支持、什么条件下不成立"。这篇给拆分方式、证明强度阶梯，以及最常被跳过的那两维。

1. 把"可行"拆成五个可证伪的句子

一句话的"可行"至少要拆成五个句子，每一句都要能被证伪，否则它只是态度。

维度	要回答的具体问题	典型翻车形态	谁最容易先发现问题
技术	有没有同类系统跑在生产？官方是否支持这条路径？	把两个都未验证的组件拼在一起	实现者
数据	字段存在吗？留存量够吗？质量够吗？能合法用吗？	历史留存周期短于方案假设	数据方、业务方
性能	在目标量级与增长下还达标吗？	"应该没问题"	压测、容量负责人
成本	全生命周期花多少？谁出？	只算了资源账单	负责人、财务
组织	谁批、谁做、谁维护、谁承担失败？	上线即无人维护	团队本身

关注点不在前两行。技术可行性通常有人盯着，因为它是评审会的本能话题；最容易翻车的是数据与组织——数据问题表现为"上线后才发现"，组织问题表现为"上线后没人管"。这两个维度都不需要高深技术，只需要有人真的去查。

技术可行性的证明强度分三档，成本递增，至少要落到其中一档：

强度	证据形态	成本	覆盖了什么风险
一档：同类证据	有同类系统在生产上跑过，能问到人	最低（一次访谈）	组合可行、工具链可行
二档：最小验证	自己跑通一条最小路径	中（数天到数周）	本环境、本数据、本版本下的可行
三档：失败条件	写清什么信号出现就判定不可行	最低（但要写下）	防止"永远在验证、永远不下结论"

第三档常被忽略，它反而最便宜：任何验证都必须同时给出"否"的判据。没有否的判据，验证会无限延长，最后靠时间用尽来收场。

2. 最小验证该验什么

原则只有一条：验不确定性最大的那一环，而不是最容易的那一环。 最容易验的部分通常已经被别人验过（有同类系统跑在生产），再验一遍只是让自己安心。

选点步骤：
1) 列出方案里所有"我还不确定"的点（越具体越好）
2) 给每个点标两个值：不确定度（低/中/高）、若要返工的影响（小/中/大）
3) 取"不确定度 × 影响"最高的一到两个点，做最小验证
4) 其余点写进前提清单，不验，但登记

─── 反例：花两周调通一个官方文档齐全的 SDK 对接（不确定度低）
─── 正例：花两天确认 3000 万行规模下的分页查询能否在 2 秒内返回（不确定度高）

数据可用性是最容易被一句"数据都有"带过的维度。它需要一张检查清单，每一项都要有可执行的核对方式，而不是口头确认：

检查项	核对方式	不通过时方案怎么变
是否存在	查系统表/目录，拿到字段与表的真实名字	换数据源，或补埋点（工期 ×2 以上）
是否齐	按目标时间窗统计覆盖率、空值率	缩窗口（把方案假设改小）
质量是否够	抽样核对、去重率、异常值比例	加清洗层，代价是链路加一段
能否合规使用	确认来源与用途边界，问法务/合规方	脱敏或降级为聚合口径
有没有权限	用目标账号真跑一次查询	走授权流程，工期不可控

"有没有权限"这一项要用目标账号真跑一次，不要用管理员账号代跑。二者看到的东西经常不一样，而这个差异直到上线当天的凌晨才会暴露。

清单要落到可执行的核对，而不是"我确认过了"。下面这段可以直接照改，缺项就是缺证据：

// 数据可用性的最小核对集，每条命令的输出都要留档
psql -c "select count(*) from ORDERS where CREATED_AT > now() - interval '3 year';"
psql -c "select count(*) filter (where REFUND_AT is null) * 1.0 / count(*) from ORDERS;"
psql -c "select min(CREATED_AT), max(CREATED_AT) from ORDERS;"     // 真实留存量
psql -c "select pg_relation_size('ORDERS');"                        // 量级是否与假设相符
─── 换算比例：留存量 < 方案假设 → 方案的时间窗必须改小，不是"上线后再补数据"

同理，"性能应当没问题"是最常见的无证据陈述。它的合格替代不是一个更响亮的判断，而是压测量级与线性外推的条件：

不合格：读写比大概 10:1，QPS 应该在可接受范围。
合格：在 500 万行、读写比 10:1、持续 30 分钟的条件下，
      单实例 P99 为 X 毫秒、错误率 0；数据量按每月 Y 万行增长，
      以线性外推，达到拐点约在 N 个月后，届时需要【具体动作】。
─── X 与 Y 必须是本环境实测，不能引用他处数字；拐点不能只靠外推，要有压测验证的加速度信号

注意合格写法里仍然留有不确定性——它把不确定性写成了数字与条件，而不是藏起来。

3. 成本要与全生命周期一起算，组织要落到名字

成本论证的常见错误不是算多了，而是只算了资源账单。全生命周期的清单至少包含三类：

one_time:                 // 一次性
  - 采购与许可
  - 数据迁移与回填
  - 现有代码改造（含对外接口的兼容层）
  - 培训与文档
recurring:                // 持续
  - 资源账单（按当前价目核对，不要用去年的单价）
  - 人力（按"每周多少小时"折算，含值班）
  - 对账与巡检脚本的长期维护
exit:                     // 退出
  - 数据迁出或归档
  - 旧系统下线与遗留兼容何时能删
  - 回滚到旧方案的成本

exit 一类最常被漏，也最贵：一个方案能不能被退掉，是它成本结构的一部分。如果退出成本高于继续维护成本，那这份"可行"实际是"不可退"。

组织可行性看起来软，实际只要问四个具体问题就够了——每个问题的答案必须是个名字，不能是部门：

问题	不合格的答案	合格的答案
谁批	"领导支持"	具体审批人与他要看到的材料
谁做	"研发团队"	具体排期与占用的现有工作量
谁维护	"运维会管"	值班表里的角色，以及他现在的负载
谁承担失败	"大家一起"	出事后第一个被叫的人

四个问题的答案凑不齐，方案在纸面上是可行的，在组织上是不可执行的。这类失败与技术水平无关，也无法通过加班弥补。

4. 结论的写法、留档与度量

结论不该写成"可行"，而该写成条件式：

结论模板：
在【前提 1】【前提 2】【前提 3】成立的前提下，本方案可行；
其中【前提 2】尚未验证，验证点在【时间点】，验证方式为【方式】；
若【前提 2】不成立，则方案降级为【备选形状】。

─── 前提要写成可观察的事实（"留存 90 天以上"），不要写判断（"数据没问题"）
─── 每条前提都要写清"谁来确认、什么时候确认"

否定结论同样要留档。半年后换了人，同一个方案会以另一个名字重新上桌，如果没有留下"为什么否"的记录，这一轮评审要重做一遍——可行性论证的产出物是文档，不是会议纪要。

度量	说明
论证维度覆盖数	五维里写清了几个，缺的维度要显式标注"未评估"
最小验证覆盖率	高不确定度项中有几项被真正验证过
前提失效率	上线后有几条前提没成立，这是判断力最诚实的指标
复盘时判断准确率	半年后回看：当初说"能"的确实能、说"不能"的确实不能

现象	常见原因	处理方向
评审一次通过，上线处处掣肘	数据与组织两维没被拆开问	补两张清单，其中权限项必须真跑
验证阶段无限延长	没有给出"否"的判据	补失败条件与截止时间点
压测通过、上线仍超时	少了前提：数据量、请求分布或持续时间	把三个前提写进结论，缺一不采信
成本超支集中在第二年	只算了资源账单，没算人力与对账维护	按 `recurring` 清单逐项折小时
同一方案反复被重提	否定结论没有留档	建"已否决方案"记录，附原因与作废条件

5. 边界：什么时候不需要五维论证

情况	可压缩到什么程度	理由
改造类、范围极小	一条结论 + 一条证据	不确定性集中在单点，验那一点即可
已有同类系统跑在生产	同类证据 + 差异清单	组合已被证明，只剩与本环境的差异
纯内部工具、无外部依赖	技术 + 成本两维	数据与组织风险都低到可忽略
一次性活动（用完即弃）	结论 + 退出方式	退出成本是唯一值得算的
已有预算的续期类需求	成本一维	技术路径已被历史验证

压缩不等于省略：压缩的是维度数量，不是证据形态。哪怕只写一条结论，也要跟着一条证据和一个前提；没有证据的"可行"仍然是空词。

6. 自测

五个维度里，为什么数据和组织最容易翻车？
技术可行性的三档证明强度，为什么"失败条件"这一档最便宜？
最小验证该优先验哪一环？举一个常见反例。
数据可用性清单里，为什么权限项必须用目标账号真跑？
"在什么前提下能做"这种写法比"可行"多解决了什么问题？
否定结论为什么也要留档？