建设现状

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

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

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

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

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

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

此前整条链路只在内置演示样本上跑过。最近拿到一批真实的双版本数据 （每个条目两行：AI 产出一行、人工修改后一行，共 31 组、310 处修正）， 把它转成埋点格式离线灌入，闭环第一次跑在真实数据上。

注意这与上面的「接入实况」不是一回事：那批数据是从表格离线导入的， 公网埋点入口收到的真实事件仍然是 0 条。 离线导入证明了链路可用，但它是一次性的；持续的自演进仍然要靠上游接通埋点。

演示样本假设的主要问题是「AI 抓错了源」。真实数据里排在最前的全是「AI 压根没抓到」—— 外部平台编号、评分、语言版本、参与人员这几类字段，AI 大量留空由人工补齐。

产出的 9 条规则草案里，8 条是「缺失时去哪里补」，只有 1 条是「写法归一」。 这直接改变了该往哪里投入：优先要解决的不是取源准确性，是覆盖率。

这也是为什么演示样本不能替代真实数据——它只能验证链路通不通， 验证不了方向对不对。

规则提取是闭环里唯一用到模型的环节。它的质量此前只有一句 「三次里大概一次能用」的印象——真去测量，30 次真实模型调用全部通过。 那次失败早已修掉，只是从没复测，印象就留了下来。

测量本身也变成了可重复的：失败被分成四类（调用失败 / 空返回 / 形状不合 schema / 语义自测不过），因为四类的改法完全不同，混成一个「成功率」就看不出该动哪里。

真正的收获来自这次测量——30 次输出里发现一类 schema 全过却不可能有效的规则： 字段漏抓时，模型给出的补全兜底源正是那个一直漏抓的源。已补上对应拦截， 判据只有一条且不需要跑就能断定：出错的源不能当解药。

新增一页只读的运行状态：进程在不在跑、数据在哪有多少、配置是否齐全、常用命令是什么。

做这一页时最自然的想法是顺手加上「启动 / 停止」按钮。但这在结构上讲不通： 工作台就是被控制的那个服务本身。「停止」点下去，页面自己就没了； 「启动」在服务没跑的时候根本打不开。

更要紧的是第二层理由——让网页能杀进程，等于给这个服务凭空加了一条可执行系统操作的攻击面， 而换来的便利仅仅是省下切一次终端。所以启停命令以可复制的文本给出，由人在终端执行。 有一条测试断言该路由只暴露 GET，防止以后有人「顺手」加回来。

同样地，这一页只显示密钥「已配置 / 未配置」，绝不显示内容本身，两条测试分别守着接口口令与模型密钥。

编目和切片是两条独立的生产线，此前切片建任务时要人工去查一部剧的编目信息再抄进去。 本版把编目做成一个只读的智能体：下游按剧目编号发一个请求， 它从编目表里读出这部剧的记录，归一化成固定结构返回——剧名、别名、导演、主演、简介， 外加 54 列原文。永不写入，只绑本机回环地址，一次一部剧，不做模糊查询。

两端的接缝用五份「金样」文件逐字锁定，两个仓库各存一份并有测试互校—— 所以两边可以并行开发，最后一次接通。