---
title: 「这活能达到什么目的」比数字更靠前 —— 数字全对也可能整件事没用
date: 2026-08-03
session: S
backlog: INFRA-F58
---

# 「这活能达到什么目的」本身是一个需要先测的声明

> 本轮接 [[INFRA-F58]] 残余② 规则三层化，最后**没做它**。四块逐块被证明不值得做。
> 值得留下的不是那个结论，是**我怎么用了三轮才到达它**。

---

## 事实：连着三轮接受继承来的框架

| 轮 | 我接受的声明 | 出处 | 怎么被推翻 |
|---|---|---|---|
| 1 | 「三层化是**最高精简杠杆**，零 owner 输入」→ 我据此排 #1 | backlog entry 自称 | 仓库自己的 [2026-07-10 scoping 报告](../../_archive/_reports/2026-07-10-f58-rule-tiering-scoping.md) **早就实测否掉**：真实可省 150-300 而非 500-700，且明写「这条不是最高精简杠杆」 |
| 2 | 「问题是**做哪几块**」→ 我给了 A/B/C 三个范围选项 + 推荐 A | 我自己（据轮 1 的错前提） | owner 问「什么依据？能达到什么目的？」→ 追到 assessment 一手源，算出**器械与目的不匹配** |
| 3 | 「AGENTS Team Comms 那块**有独立成立的用途**（省 14% 强制阅读量）」 | 我自己切出来的 | owner 问「这个是干什么的」→ 核 L-ref 表，**AGENTS 本就不是每 session 全读**，Team Comms 本就在最小集外 → **省 0** |

三轮里**每一轮都是 owner 追问才去测**。

## 关键区分：我核了数字，没核判断

这一轮我**确实**做了活源核验，而且抓得不少 —— 六处数字/判断错误全是我对活源重量出来的：

- 「R14-R23」实为 **9 对**（含我第一遍 grep 也漏掉的 `R-DISCIPLINE/M-DISCIPLINE`），且 R11/R20/R21/R22 根本不存在
- 「meta-rules(820)」实为 **826**，且 SPLIT 落点早已存在
- 「AGENTS §640-738」真实为 **613-714** —— 而**该文件总共只有 720 行，738 不存在**
- 「六段式」**全仓只命中 entry 自己**，仓库从未定义过它 = 无验收标准的任务名

**所以病根不是「没核活源」。** 我核的是「这条说有 3 处，实际有几处」这一类**可测量的事实**，而漏掉的是**「做完这件事会带来什么」这一类可测量的断言** —— 后者同样可测，只是我没把它当成需要测的东西。

三个测量就够了，而且都是十分钟内能做完的：

| 测量 | 结果 |
|---|---|
| 目标文件今天总量 vs 缺口登记时 | **7327 行**，登记以来 **+411（5.9%）** |
| 这活最好情况能改变多少 | 150-300 行 = **2-4%**，**追不上自己的增长** |
| 交付载具上真实收到什么 | `ds-bundle/reference/` 是**近逐字搬运**（2885→2867 / 1488→1470）→ 省 2-4% 到不了消费者 |

第三条是决定性的，也是最容易被跳过的：**我差点只算了前两条**（「省 2-4% 不够多」是量的判断，可以被「聊胜于无」反驳），而第三条是**性质**判断 —— 载具压根没做精简，所以再省也不改变可吃性。

## 沉淀成什么

**不要新增一条硬规则。** 已有的 [硬规则 #10（结论必须对活源验证）](../../../AGENTS.md) 与 [触发器 F（推荐自审 4 问）](../../meta-rules.md) 覆盖了「核事实」和「理由经得起反驳吗」，缺的只是把**「用途」也算作待验证的事实**这一层认识 —— 那是同一条规则的应用面扩大，不是新规则（反 [[feedback_reactive-correction-over-preemptive-rules]]）。

具体地，接手任何「已登记的待做项」时，在核数字之前先问一句：

> **这条 entry 声称做完能达到什么？那个声明本身有没有被测过？**

判定「测过」的形态就是上面那三个测量：**现状量 · 这活能改变的量 · 交付面上真实收到什么**。三者任一说不通，就先回报 owner 而不是开始设计方案。

## 反面：这轮做对的两件

分开记，别只囤教训（[[feedback_reactive-correction-over-preemptive-rules]] 的配套）。

1. **造故障拿存在性证据，而不是读代码推断。** gate-parity 那条我本可以只写「paths 不含那些文件所以不触发」——那是推断。实际做的是往一个不被任何 glob 匹配的文件里注入违例 → 看闸变红 exit 1（S6 点名到行）→ 复原 sha256 逐字节一致 → 闸回 exit 0。**这条证据让「那句注释是假的」从主张变成了事实。**
2. **改 CI 配置时先证明改动语义为零。** 纯注释改动用 js-yaml 双向解析做 JSON 全等比对（identical），并机械核 diff 无任何非注释增删行。比「我只改了注释所以没事」强，因为 YAML 的注释与结构边界不是肉眼可靠的。

## 一处该记住的边界

`audit:stale-anchors` **放过了本文件被引用时的悬空链接** —— 我在 STATUS.md 里引用本文件时它还不存在，闸仍然绿。原因是 **STATUS.md 不在它的 SCAN_FILES**（它只扫 `code-conventions` / `mockup-conventions` / `meta-rules` 等发出的链接）。这是它源码里声明过的覆盖边界、**不是漏**，但接手人容易据「stale-anchors 绿」误以为全仓链接都被校过。写 STATUS 摘要时新引入的文件路径，得自己 `ls` 一下。