admin
ce8e6ceed9
回收 411 MB（470 M → 58.8 M），全部经回收站，可恢复： - 待清理/（146.2 M，含 relay 分片 128 M 与 42 项过程目录） - tmp/（32.4 M，按接续棒命名的过程临时区） - .workbuddy/tmp/（39.5 M） - 4 份 workbuddy.db 冗余副本（101 M，09-23 事故的坏副本 / 抢救产物） - tmp/im16/gw/centrifugo 二进制（63.9 M，可重下）+ 缓存残留 入库范围：常驻规则（CODEBUDDY.md / README.md / state.py）、在途接续入口与 接续包、docs/、交付物/、交接单/、归档/、scripts/、.codebuddy/、 .workbuddy/memory/；共 398 件，其中 >60 KB 的 26 件全为文档。 排除（.gitignore）：tmp/、待清理/、运行态日志与缓存、*.db 与 DB 备份整目录、 打包二进制（*.tar.gz / *.tgz）、记忆修复前备份。
61 lines
5.5 KiB
Markdown
61 lines
5.5 KiB
Markdown
# 文档无效信息审计报告（2026-09-16）
|
||
|
||
> **判据** = `dsh-knowledge-upkeep §8`（六类无效信息 + 五条"不能删"的红线）
|
||
> **范围** = `.workbuddy/memory/*.md`（31 份 / 1,325 KB）｜技能 `*.md`（12+ 份 / 348 KB）｜工作区根方案文档（23 份 / 964 KB）⇒ 合计 **66 份 / 2,643 KB**
|
||
> **方法** = 两个只读脚本机械扫描 + 人工复核（脚本在 `_中间产物_待清理/auto-continue-20260916/`，可复跑）
|
||
> **性质** = 一次性产物；读完可归档到 `_中间产物_待清理/`，⛔ 别让它自己也变成"根目录堆积"
|
||
|
||
## 一、判定
|
||
|
||
✅ **整体健康。无效信息不弥散，只集中在 2 处。**
|
||
|
||
| §8 六类检查项 | 实测结果 |
|
||
|---|---|
|
||
| ③ 同一事实多处重复 | memory **17.5 KB / 1.3%**｜技能 0.3%｜根方案 **0.0%** ⇒ **无大段重复** |
|
||
| ⑥ 只写"给人看的套话" | **0 处** |
|
||
| ④ 过程流水挤掉结论 | 日志类 0.5–0.67 **属正常**（日志本就是流水）；正式文档无异常 |
|
||
| ⑤ 中间产物混进正式文档 | 机械命中 45 处 → **人工复核真命中 0** |
|
||
| ① 与可执行体不符 ／ ② 过期结论占"生效位" | 见 §二（1 处真实问题） |
|
||
| 悬空引用（辅助项） | 机械命中 30 个 → **真命中 0** |
|
||
|
||
> ⚠️ **方法学如实说明**：第 ⑤ 类与悬空引用的机械检测器**噪声很高** —— 45 处命中全是"文档把 `_tmp_*` 当反例讲"或"点名真实的 `_verify_tsc.mjs`"，30 个悬空引用全是 `package.json`/`SKILL.md` 这类裸文件名。**六类里真正能机械判定的只有 ③ 重复、④ 流水占比、⑥ 套话**；⑤ 与引用类必须人工复核。⇒ 这类审计的价值在「定量 + 复核」，不在全自动。
|
||
|
||
## 二、真实问题（按影响排序）
|
||
|
||
**1. 工作区根 `_中间产物_待清理/sess-forensics-20260916/会话脉络_ddea70b7_20260916.md` = 589.6 KB，占根方案文档 61%**
|
||
|
||
- 类别：§8.2 第 ④/⑤ 类（过程流水 + 取证中间产物混进正式区）
|
||
- 判据（§8 唯一判据：去掉它，下一个会话会不会做错事/变慢？）：内容是「AI 为何上抛」的**会话转录摘录**，其结论已被三处吸收 —— `会话复盘_AI为何上抛_20260916.html`、`.workbuddy/memory/2026-09-16.md`、两个技能的修订 ⇒ **去掉不会导致做错事**
|
||
- **已处置（2026-09-16 修复轮）**：移入 `_中间产物_待清理/sess-forensics-20260916/`，并同步修正 3 处引用（审计报告 / 简报 / 会话复盘 HTML）；历史日志中的路径按 append-only 原则不改
|
||
- **效果**：工作区根 `.md` 由 **23 份 / 964.1 KB → 22 份 / 375.0 KB（-61%）**
|
||
|
||
**2. 每轮注入层：用户级 `E:\ProgramData\.workbuddy\MEMORY.md` 被截断（已修）**
|
||
|
||
- 实测：20,977 B / 11,712 chars；宿主 **注入上限 ≈ 4,000 chars**
|
||
- 原排序的后果：注入窗口只覆盖「钩子配置 + 环境路径」——**一条行为规则都没进去**（`Preferences` 整节在窗口外）
|
||
- 类别：这是 §8.2 第 ② 类的**变体** —— 内容没错，**排序错**；而"排在窗口外"在效果上等于"这条规则不存在"
|
||
- **已修**：分层重排（**零删除**）+ 文件头加**排序契约**（⛔ 新增内容按序插入对应小节，别追加到末尾）
|
||
|
||
## 三、"不能删"红线的分布（供后续清理避让）
|
||
|
||
五条红线（判据与阈值 / 命令原文与路径 / 反例踩坑 / 为什么 / 失效标注）在 66 份里几乎每份都有。
|
||
机械兜底已就位：`docs-shrink-guard.py` 基线覆盖 **151 个文件**（行数骤降 >30% 且 >20 行即报警）⇒ 后续任何整编都会被它抓出来。
|
||
|
||
## 四、建议（⛔ 本轮未做，留待下个会话决定）
|
||
|
||
1. ✅ **已落地（2026-09-16 修复轮）**：`dsh-knowledge-upkeep` **1.1.0 → 1.2.0**，新增 **§8.6「注入预算」维度** —— 「每轮注入有上限 ⇒ 长文件后半段等于不存在；**先重排、后删减**；文件头必须写排序契约」。md5 `6249caaa…`，**本机 / 文档库 / 镜像三处一致**。同时用户级记忆头部已写入排序契约。
|
||
2. **根目录方案文档：⛔ 不搬（结论已在修复轮修正）**。复核后实测：10 份 `覆盖网络_*.md` / 可行性评估在档案 103–112 里的**行覆盖率 98.5–99.0%**（差异 = 一级标题行），另 3 份与文档库 `archive/工作区草案/` 字节完全相同。
|
||
⚠️ **但"搬走"是净变差**：这 10 份被 **11 处引用**（含 `接续入口_覆盖网络线_20260916.md`），搬走会大面积断链 ⇒ 改为**加归档指针**（正文以档案 103–112 为准，根副本保留为工作副本）。
|
||
🔴 **本报告首版的一处错误（已修）**：首版用「归一化整串包含」判定，得出"档案未包含根文档"的假阴性（因为档案按约定删了 H1 标题行）⇒ 正确判据是**行级覆盖率**，不是整串包含。**这与本报告 §一 记的"检测器噪声"是同一类错误：机械判据必须先验证判据本身。**
|
||
3. **日志分片不需要瘦身**：`2026-09-16.md` 已 88 KB、`2026-09-下19.md` 流水占比 0.67 —— 但日志**按需读取、不进每轮上下文**，不构成水位成本。按维护规则，10 月后把 9 月日志按主题蒸馏进 `MEMORY.md` 再删旧片即可。
|
||
|
||
---
|
||
|
||
### 附：可复跑命令
|
||
|
||
```bash
|
||
cd "E:/ProgramData/AI技能/aliyun-dsh-server"
|
||
PYTHONIOENCODING=utf-8 "<managed python>" "_中间产物_待清理/auto-continue-20260916/audit_docs.py" # 六类机械扫描
|
||
PYTHONIOENCODING=utf-8 "<managed python>" "_中间产物_待清理/auto-continue-20260916/audit_pass2.py" # 重复字节定量
|
||
```
|