建设实况 · v4.1.0 · 2026-09-01

建设现状

v4.1.0 已发布。闭环中段全部实现并被测试覆盖，左端埋点入口已上线并通过全项自检，右端规则回流的契约与上游加载器参考实现已交付。本页给出截至 2026-09-01 的实况。

1 738

行 Python · 20 个模块

113

测试 · 全绿

9 + 12

命令行命令 + HTTP 路由

6 / 8

功能件已交付

闭环全景：中段已通，两端已交付契约

实线环节已实现且有测试覆盖。左端埋点入口已上线并通过全项自检；右端的规则包契约与加载器参考实现已交付，虚线表示它尚待上游接入。两端都接上之后，这条线才真正闭合。

编号	功能	落地形态	状态
F1	修正埋点	HTTP 接收端 + 进程内接入点；校验失败进兜底队列可重放	已交付
F2	字段级差异分析	高频错误字段排行、错误模式、来源分布、置信度分箱检验	已交付
F3	规则提取	四类封闭词表的类型化规则；定类型不用模型，模型只填 schema 内参数	已交付
F4	审核与灰度	状态机跳步抛异常、审核须署名、任意状态一键回滚	已交付
F6	准确率看板	处理完成埋点提供真实分母，修正率与填充率按率口径计算	已交付
F9	规则冲突检测	入库比对同字段同条件的已生效规则并告警	已交付
F5	疑难字段专项增强	多语种检索与实体消歧，提升难字段填充率	路线图
F7	人机并行采样	同一条内容双轨跑 AI 与人工，结果自动比对入库	路线图

只记录「被人工改过的字段」，能算出的永远只是修正次数，不是修正率—— 吞吐量一变，前后就不可比，填充率更是无从谈起。

因此埋点是两条而非一条：除了字段级修正事件，还有一条处理完成事件，记录每条内容各字段是否有值、是否被人工改动。有了分母，「规则生效后修正率下降 ≥20%」「难字段填充率提升 ≥10 个百分点」这两条验收标准才真正可判定。

这个补丁牵动契约、接收端、度量口径与看板四处——它属于地基，越晚改代价越大。

闭环右端曾是断的：规则的条件与动作是自然语言，人看得懂、机器不能执行，于是「生效」之后仍要有人手工翻译成上游的代码改动。

解法不是把上游链路集成或复刻进来——那要重做的是多年踩出来的反爬突破、多级降级与写入兜底，复刻品短期内准确率追不上现网。真正需要的只是让上游能消费一个配置文件。

于是规则从自由文本变成四类封闭词表，每类对应一个模块层，参数有 schema：

类型	层	上游如何执行	对应修正原因
source_priority	L1	该字段按给定顺序取源，先到先用	来源错误
normalize	L3	对该字段的值做替换或映射	格式不符
prompt_constraint	L3	该字段的生成 prompt 追加一段约束	语义偏差 / 幻觉编造
fallback_source	L4	字段为空时按顺序去补	漏抓补全

四类不是拍脑袋定的——它们与修正原因枚举一一对应。而修正原因本就按「解法不同」划分：抓错源要改采集，编造内容要改 prompt。类型与原因对齐后，差异分析能直接决定该提哪一类规则，不必让模型自由发挥。

额外好处：结构化参数可以校验，自由文本不能。模型编出一个不存在的数据源名，入库时当场被拒，而不是等审核人肉眼发现。

生效规则渲染成版本化的规则包，上游一个加载器加四个执行分支即可消费—— 不动八阶段、不动分层、不动既有的降级与兜底逻辑。灰度由上游按比例抽样执行。

同一个服务同时承载埋点接口与服务端渲染的工作台界面；命令行是同一批领域模块的另一个入口。鉴权为共享 Token：接口走请求头，界面走登录页换签名 cookie，未配置 Token 时服务拒绝启动。

两条日志与一份规则库，都是可直接阅读的文本格式：日志是追加式 JSONL，规则库是缩进 JSON。写入用临时文件加原子替换。这是刻意的选择——可 grep、可人工审阅、可手工修复，与「白盒优于黑盒」的原则一致。规模上限也因此是明确的，面向数十人的工作台而非海量并发。

三条约束写死在代码里，不是文档约定：修正原因为空直接抛异常、规则无样本证据无法入库、状态机跳步抛异常。每条都有测试守着。

上游接入两条埋点。 入口、契约与自检脚本均已就绪，等待上游在保存字段修改时推修正事件、在每条内容处理完成时推完成事件。两条都要——缺完成事件就只有分子没分母，率的验收指标判不了。
上游接入规则加载器。 契约、参考实现与对接文档均已交付，上游侧约一天工作量。接上之后闭环才真正闭合——在此之前，前面所有环节都只是在攒数据。
补 F5 与 F7。 疑难字段专项增强直接关系到填充率验收指标；人机并行双轨采样为规则提取提供更干净的对照样本。
规则提取管线的跨场景复用。 编目的「字段级 diff」与视频切片的「候选留用/弃用/入出点微调」结构同构，管线可共用一套——这个攻坚只做一次，两条线都受益。