内容生产

2.0 的标准在服务器上，执行端只放指针。这套设计在自家环境里是对的 —— 唯一源不会漂。
但它有个前提：你得先连上那台服务器。换台机器、换个人接手，第一步就要访问权，然后还得有人讲一遍「这套东西认什么」。

① 写到一半发现方向错了 —— 判断和写作都放在 X，产出是一份结构化 JSON，看完就知道这页会是什么样，不用等整页渲染。
② 同一张映射表存了两份 —— 值域只留一份，其他地方全部从它派生。派生出来的对不上，是派生坏了，不是定义坏了。
③ 出问题不知道错在哪一步 —— 每班一个目录，六步各留一份产物，哪步不对看哪份。

不是审美，是变更频率不同。定义常改（加子域、改上限），执行少改（改判据才动），记录只追加。
把常改的和少改的混在一起，是这类系统最常见的死法 —— 改一个值要动一整套逻辑。

① 只有 A 和 X 碰模型 —— 其余四个模块输入相同、输出必然相同。
② B 只渲染不判断 —— 契约里缺一块，它报错停住，不猜。
③ C 不评「写得好不好」—— 那是评审的事，不是检查器的事。
④ D 默认不真推 —— 要上线得显式开。

「找什么」是我们自己维护的判断 —— 哪些子域值得追、哪些词不对。
「怎么搜」是能力 —— 用框架自带的搜索，还是接某一家提供商的接口。
两件事的变更节奏完全不同：方向我们定，能力会换。写在一起，换一家搜索服务就得改一遍方向表。

在已经能做判断的框架里（比如带 Agent 的对话框），不需要再配一把 key —— 它跑到 X 就停，把提示词交出来，人贴给 Agent 就行。
要无人值守地跑，就得配接口自己调。
两条路共用同一份提示词模板，不是两套逻辑。

跑到一半有人改了配置，这一班该按改前的算还是改后的算？
快照让每一班的产出都能复现 —— 三个月后回看「这页为什么长这样」，答案就在那个目录里。

六个模块全链走通，已经用真页跑过整条链（扫描 → 判定 → 组装 → 检查 → 部署 → 验收）。
值域收成了单一源，X 的两条路都验证过。

块类型还是固定的几种，加一种新块要改代码 —— 应该改成「定义里加一条，代码不用动」。
覆盖面还不如 2.0，目前是能跑通，不是能替代。