00-总纲-项目开发进度六维加权评估打分法
一、适用场景
项目中后期，被问到「这个程序开发到什么地步了」——需要一个覆盖工程全链条的整体判断，
而不是某一项的质量分（如代码质量、测试覆盖率、接口性能）。
典型触发：
- 阶段性收尾，需要向自己或他人交代「还差多少」；
- 感觉「功能都做完了却上不了线」，想弄清卡在哪一环；
- 需要在多条交付路线（如一体机 / 现役设备 / 备选机）之间排优先级。
前提：项目已有可运行的本体、有测试记录、有打包与部署尝试。纯概念阶段不适用。
二、操作步骤
- 先分清两套评分口径，别混用（最关键的一步）：
- 质量口径（如五维各 20 分的代码质量评分）回答的是「代码写得好不好」；
- 进度口径（本技能六维）回答的是「距离能用还差多少」。
两者可以一个高分一个低分，混用会得出「质量 98 分所以快完成了」这类错误结论。
锚点：.workbuddy/memory/2026-10-13.md（质量五维口径）与2026-10-20.mdL10（进度六维口径）。 - 定六维权重（和必须 = 100），本例取值与理由：
| 维度 | 权重 | 为什么是这个权重 |
|---|---|---|
| 需求与架构设计 | 15% | 骨架定生死，但一旦稳定就不再变化，不该长期占据高分位 |
| 功能实现 | 25% | 用户感知的主体，占比最高 |
| 代码质量与测试 | 20% | 决定能不能长期维护 |
| 打包交付 | 15% | 能不能变成可分发的产物 |
| 部署落地 | 15% | 能不能在目标机上跑起来 |
| 运维与知识沉淀 | 10% | 长期可用性，权重最低但不可为零 |
- 逐维打分，每维必须配「扣分主因」，且主因写成可证伪的事实（「某件事还没做成」），
不写「感觉不完善」「还需优化」这类无法判定的话。本例四条主因形态：
「SPK 主线报格式不正确已 5 天未装上」「两个 EXE 未实机验证」「三端各仅 1 个占位 txt」「异盘备份失效连续 5 次未处理」。 - 加权求和 → 总分：
95×0.15 + 88×0.25 + 98×0.20 + 68×0.15 + 30×0.15 + 88×0.10 = 79.35。 - 给阶段判定，而不只是分数：结论写成「测试期尾声 · 待部署」这类阶段名，
并配一句话定性。本例定性＝产品本体成熟（质量维度满分、功能齐备），卡在最后一公里的部署交付。
决策看阶段，不看小数位。 - 部署维必须做「本体 / 最后一公里」切分：把「产品本身没做好」和「做好了但没装上/没验证」分开。
本例部署 30 分，但扣分全部来自「未实机验证」，而非产品缺陷 —— 这一句决定了后续该补验证还是该重写。 - 产出图文报告：正文必须嵌结构化图（本例两图：六维评分条形图、三条交付路线进度图），
每图配图注「图 N 说明」；落点系统操作手册/05 测试/，文件名带版本号vX.X_YYYYMMDD。 - 登记复评触发条件：在报告里写明「哪条主因一旦解除就复评，预计区间是多少」。
本例：「主因①（SPK 装机）解除 → v1.1 复评，打包/部署两维上调，预计 79 → 85±」。 - 主因解除后真的复评一次（不是口头说一句就完）：新建 v1.1，重算总分，旧版移
_备份/，
并在新版里写明「本次上调依据」。锚点：00-总纲-前序结论证伪与产物连锁订正法。 - 报告落点若被写保护，暂存 + 记「待归位」清单（在日志里写明源路径与目标路径），
不要因为落不下去就放弃产出。锚点：04-开发-沙箱环境写文件限制规避法。
三、注意边界
- 权重之和必须等于 100；拍脑袋凑出来的权重会让总分失真，且复评时无法对齐。
- 分数只是沟通工具，阶段判定才是结论；对外表达先说阶段，再说分数。
- 每维高分都必须有可验证事实支撑，无扣分主因的高分不可信（等于没评）。
- 复评区间如实写「85±」，不要假装精确到个位；上调依据要能追溯到具体事件日期。
- 六维之外不要临时加维度；确实有新增维度就重新分配权重并升版本，保证「和 = 100」仍成立。
- 评估结论只用于排优先级，不要拿它当验收标准；验收另有口径。
- 报告中的真名、单位、金额一律降敏（U1–U4 / E1 / C1C2），评估记录本身也要能公开传阅。
四、反例避雷
- ✗ 拿质量口径去回答进度问题：2026-10-13 那套五维（各 20 分）是代码质量分，
质量 98 分与「能不能部署」毫无关系；2026-10-20 若沿用它会得出完全错误的乐观结论。 - ✗ 只给总分不给阶段判定：「79 分」无法解读——是快完成了还是刚起步？必须配阶段名。
- ✗ 扣分主因写成感觉：「打包环节还需加强」无法证伪，主因解除时也无法判定该不该加分。
- ✗ 主因解除后只在对话里说「应该能到 85」：报告停在 v1.0 的 79 分，结论与文档脱节。
本例 2026-10-20 主因①被真机装机解除，v1.1 复评仍为待办——这正是要避免的形态。 - ✗ 把「未部署」判成「产品不成熟」：本例功能 88、质量 98，本体成熟；
部署 30 分只能推出「最后一公里没走完」，不能推出「产品不行」。混淆两者会导致推倒重来的错误决策。 - ✗ 权重和不为 100 还照常出总分：算出来的 79 会随权重口径漂移，复评时无法比较。
五、代码锚点 / 实战战绩
锚点：
- .workbuddy/memory/2026-10-20.md L9-33（本次评估全过程、六维口径、四条主因、复评触发）
- .workbuddy/memory/2026-10-13.md（质量五维口径，作对照，勿混用）
- 报告产物：HFMS程序开发进度评估与打分报告_v1.0_20261020.docx（120,551 B，2 表 + 2 图，testzip 通过）
- 图产物：score_report_1020_fig/（图 1 六维评分条形图、图 2 三路线进度图）
- 附包只读体检器：scripts/progress_score_check.py
战绩：
- 2026-10-20 首跑：架构 95 / 功能 88 / 质量 98 / 打包 68 / 部署 30 / 运维 88 → 加权 79.35 ≈ 79；
阶段判定「测试期尾声 · 待部署」。
- 同日主因①（群晖 SPK 装机）由用户在异地 DS418play 真机验证解除，
验证证据三件套齐备（套件中心已安装列表 + <NAS内网IP>:8765 登录页可达 + 与并列套件同框截图），
预计 v1.1 复评总分 79 → 85±。
- 体检器实测：对内置真实评估样例 PASS（FAIL 0 / WARN 0）；
对「只给 79 分一句话」的反例正确报 FAIL×4 + WARN×1（六维缺、无权重、无阶段判定、无扣分主因）。
六、关联笔记
- 与
05-测试-QA测量环境隔离与失真排除法互补：那是测量层面的失真排除（性能分怎么测才准），
本技能是评估层面的口径设计（总分怎么算才有意义）。 - 与
00-总纲-前序结论证伪与产物连锁订正法串联：本技能第 8、9 步（复评触发 → 真的复评）就是它「影响面四类穷举」的实例——
主因解除后，受影响的产物包括评分报告、技能包战绩段、记忆日志三处。 - 与
06-成品-群晖SPK打包与格式排查法、06-成品-部署目标机硬件规格核实与参数联动法串联：
部署维与打包维的分数，直接由这两条线的实测结果提供证据。 - 与
04-开发-沙箱环境写文件限制规避法串联：报告落点被拦时的暂存与「待归位」登记。 - 与
02-技术-docx图文手册纯标准库增量改写法串联：评分报告的图文产出与升版改写。
七、版本记录
- v1.0（2026-10-21）：首版。六维权重表 + 九步操作 + 六条反例 + 十条边界。
来源是 2026-10-20 首次完整评估（79.35 分 / 阶段判定 / 四条可证伪主因 / 复评触发）的实战闭环。
