知识底座复盘

起点是 41GB 的扫描教材 PDF，终点是一套架在课标骨架上、自带质检层的知识图谱原型。教材 PDF 一页都没处理过：当初计划里用来对照的方案，最后成了主线。 代码和页面都已经有了，缺的是人工审核。

5 天

8/20 至 8/24 完成全部开发，之后停了 34 天

38,311

行 Python（pipeline、demo、tests），549 个测试全部通过

3997 / 6622

锚点 / 边，24 个学科；在用锚点 2971

经人工确认的锚点和边。数据契约把它标成 high 级问题

18 / 57

机器复核的高风险硬边里成立的（32%）；过强 32，错误 7

0 次提交

全部成果都在 worktree 里未跟踪的 research/ 目录

计划走的路，和实际走的路

左边是 8/20 写进 README 的研究路线，右边是 8/24 之后真正有数据流过的链路。虚线表示代码写了，但从没有真实数据经过。

左列的 L0 至 L3 是整个研究原本要回答的部分，它一次也没有运行。右列每一步都有真实数据经过，并留下了页面和文档。

原来的三个研究问题，答到哪了

这三个问题和决策阈值是在 8/20 开跑之前写进 README 的，约定“跑完不改”。

问题	状态	现在能说的
1. 扫描教材能否稳定清洗成结构化数据？瓶颈在哪一层？	未回答	阶段 −1（源判定，需要一册 PDF）没有开始，没有任何一页进过管线。
2. 单册真实成本是多少（token + 人工校对工时）？	未回答	同上。成本模型只停留在计划里。
3. 洗出来的数据比“直接用课标建骨架”强在哪？	反向答了一半	我们实际验证的是对照组本身：课标骨架补丁后能撑起数学、物理的按章备课（严格口径 85%、86%）。但物理 86% 是天花板，课标比教材粗一层（“欧姆定律”严格命中为 0）；生物学只有 13%。教材侧数据的价值恰好就在这些缝里，这是 ChinaTextbook 仍然可能有用的地方。

覆盖度：补丁前后

严格口径：一个锚点只算它唯一命中的那一章。每章至少 3 条相关锚点才算“可支撑备课”。

学科	补丁前	补丁后	备注
数学	8/20 · 40%	17/20 · 85%	补 74 个【内容要求】锚点
物理	2/22 · 9%	19/22 · 86%	补 137 个；86% 接近课标粒度上限
化学	6/12 · 50%	未补	方法相同，尚未执行
生物学	4/31 · 13%	未补	宽松 14/31，与严格差 10 章：检索词很糊

补丁的 211 个新锚点全部是 LLM 起草、未经人工审核；教材目录是按记忆录入的人教版，未与实体书核对。所以这里的“85%”是“检索得到”，不等于“内容正确”。

时间线

08-20 评估 ChinaTextbook
41GB、无许可证。定位为内部研究；定下 L0 至 L6 分层，以及“开跑之前定死阈值”。
08-20 至 08-22 搭框架、写计划
流水线各层代码与合成 fixture；五阶段门禁计划。第一次提部署，决定先不部署。
08-23 转向产品视角
知识图谱的产品定位图；并行子 agent 按学科机器起草本体。
08-24 上午接入 k12 数据集，上线
审计、修复、压力测试页；部署时发现独立子域被 ICP 拦截，改挂 k12.yongle.school/zhishi/；决定对大模型开放。
08-24 下午机器复核 57 条高风险边
只有 18 条成立。压力测试显示边证据的 30% 绝对阈值基本不起作用。
08-24 晚上明确“基础建设”定位，并行开发
备课、查漏补缺、检索、考试诊断、家长查看覆盖。查询层、审核日志、作品挂接、多学科目录、覆盖诊断、补丁层同晚完成。
08-25 至 09-27 停摆 34 天
没有提交，没有人工审核。
09-28 复盘
重跑测试 549 个全部通过，覆盖度数字与 8/24 一致。

做对的

L4 独立于教材

当初是为了“换教材版本不用重建”，结果连“换整个数据源”也几乎零成本：8/24 从 PDF 切到 k12 数据集，查询、掌握度、红线策略原样复用。

先定门禁，跑完不改

阈值写死在 README，所以今天能直接说 Q1、Q2 没有回答，而不是拿其他成果去顶替。

补丁层不碰原始数据

分类看记录结构，不看文件名；字段修补先校验 old，对不上就报冲突、不写入。上游重新生成时，我们的修正不会被静默冲掉。

红线写进代码

道德与法治、思想政治不评分；未声明学科默认不评分；作品与知识点的挂接类型不可哈希，无法被聚合成排名；没有“已掌握”这种挂接类型。

数据契约说实话

“0 人工确认”列为 high 级已知问题；覆盖度同时给宽松和严格两个口径，差值直接暴露检索词是否含糊。

找根因，而不是换更强的模型

覆盖缺口不是 LLM 能力问题，是抽取读错了课标段落。改读【内容要求】后，物理严格覆盖从 9% 到 86%。

我犯的错

算法层几乎没出错。错误集中在胶水代码和统计口径上，而且每一次都是靠“两个数对不上”抓到的。

错误	后果	怎么发现的
适配器把 component_of 方向接反，并把上游的 auto-confirmed 当成已确认	诊断会沿反方向归因；“已确认”数字虚高	对照上游定义逐条核对边类型
查询层又“补偿”了一次方向	适配器修好后，方向被翻回错误	两个子 agent 各自修同一问题，集成跑测试时暴露
声称 manifest 与数据不一致	误报：拿“全部”和“在用”比	复核口径；之后所有计数带 _live / _all 后缀
contentHash 把 CHANGELOG 算进了自己	哈希每次都变，无法校验	`contract --verify` 自检
用 grep 审计 CLI 的导入	漏报：run.py 实际缺多个模块	改用 AST 审计
覆盖率分母把 ok_strict 重复算入	百分比偏低	手算对账，并补测试
nginx 子 location 单独写了 add_header	安全响应头整体丢失	curl -I 检查响应头
用新建子域 zhishi 对外	大陆 HTTPS 零成功（ICP 按域名登记）	nginx 日志对照，改挂已备案主机名

过程上的问题

建设远快于验证

5 天写了 3.8 万行、549 个测试，人工确认仍然是 0。我问过 4 次谁能来审，一直没有答案。这是项目最大的结构性风险，而且不是技术问题。

研究边界漂移

README 写着“抽样不全量”“不出现在任何对外页面”，实际上线了公开站点，覆盖 24 个学科。站上是 k12 数据集的审计结果，不是教材内容，风险可控；但 README 没同步，下一个人读到的边界是错的。

全部未提交

一个 worktree 里的未跟踪目录，零次提交。worktree 一旦被清理，成果就没了。这是现在最便宜也最该先做的事。

并行需要集成返工

方向补偿做了两次，测试耦合到“音乐学科未声明”这种偶然状态。并行值得做，但集成这一步不能省。

凭据曾贴在聊天里

服务器密码和云存储密钥出现在会话记录中。我没有使用，但如果还没轮换，应当轮换。

接下来，按杠杆排序

先提交研究代码进当前分支。data/k12 与 data/k12-repaired 各 13MB，需要决定是否入库（README 原则是数据不入库）。
请一位老师审 1 小时物理 20 条补丁锚点 + 20 条硬边。这一小时第一次给出准确率基线，价值高于再写一万行代码。
决定 ChinaTextbook 的去留建议只取教材目录（数字版文本层即可，不做 OCR），用作章节主键和目录校验源；L0 至 L3 全量抽取暂停。
化学、生物学按同样方法补【内容要求】预计能把严格覆盖从 50%、13% 拉起来。这是预期，还没有实测。
同步 README 的边界让写下来的约束和实际状态一致。

需要你拍板的三件事

谁来做第一轮人工审核（一位懂物理或数学课标的老师，1 小时）
ChinaTextbook 路线：只取目录，还是继续全量抽取，还是放弃
data/k12 是否入库，README 的研究边界改成什么

数据来源：python3 -m unittest discover -s tests（549 通过）；python3 -m pipeline.run contract（锚点、边、人工确认数）； pipeline.run coverage --subject 学科 [--raw]（补丁前后覆盖度）；demo/verdicts_claude.json（57 条机器复核：correct 18 / too_strong 32 / wrong 7）； data/k12/patches/*.jsonl（74 + 137 + 178 行）；会话记录时间戳（按北京时间）；deploy/DEPLOY-zhishi.md（ICP 实测）。代码行数为 research/textbook-kb 下除 data/ 外全部 .py 文件。