药材谷 · 本轮战报

路线图 P1 核验 | P0 系统级修复(21 模块)| 全站标签满分 | 数据补种 43 条 | 死链归零
出具日期:2026-10-06 | 实测环境:80 端口网页端 + 8979 FastAPI(全站 196 页)
196/196全站页面 HTTP 200
33/33标签语义命中页
0死链 / 404 误配 / 空池
21P0 修复后端模块

一、本轮最重要的一件事:P0 系统级修复

!21 个后端模块集体 NameError: name 'os' is not defined

这不是页面问题,是服务端全量写操作瘫痪。第十五 / 十六轮批量生成的 admin_* 模块,_save() 里都用了 os.replace(_tmp, str(fp)) 做原子替换,但顶部 import 行漏掉了 os。后果是:任何写操作一律 HTTP 500,页面上表现为"提交了没反应 / 保存失败"。

暴露路径:补种方剂数据时 /api/admin/kb_foodherb/save 报 500,uvicorn 日志直指 admin_kb_foodherb.py:39。顺藤摸瓜,同款模板共 21 处。

受影响的 21 个模块

修复方式模块清单
_fix_os_import.py
正则补 os 导入
(合并行 + 单行两种形态)
admin_agent_service · admin_bid · admin_bulk · admin_bulk_trade_v2 · admin_expert · admin_expert_consult · admin_foodherb_kb · admin_labor · admin_live · admin_machine · admin_machine_service · admin_market · admin_message · admin_plant_weather · admin_process · admin_quality · admin_screen · admin_seed · admin_seed_mall · admin_storage_logistics · admin_warehouse

已修复 21 模块全部 py_compile 通过;/api/message/template/save、/api/message/announcement/create、/api/land/publish、/api/seedling/publish 写路径实测全部 200。

二、你点名的「合同 + 业务消息」板块 · 专项核验

你上次特别提到合同的业务消息板块有问题。这轮做了端到端核验,结论:结构完好,并且修掉了一处"B2 误配"。

2.1 合同板块(hetong.html / 合同范本库.html)

核验项实测结果判定
合同条数49 份正常
分类分布一产 13 · 二产 11 · 三产 16 · 增值服务 9吻合
标签结构全部 / 一产·种植劳务 13 / 二产·加工 11 / 三产·交易 16 / 增值服务 9标签数=分类数
筛选机制原生 data-cat + curCat 本地筛选,完好可用正常
B2 真数据注入已剥离(该页本就有真实数据,B2 反而会串数据源)已处理

说明:此前侦察兵 S1 把这两页误报为"筛选死键",根因是它只认 onFilterTag,不认原生 data-cat。已在 _scout12.py 加 native_filter 判定,误报消除。

2.2 业务消息板块(message 模块 4 接口)

接口HTTP数据判定
/api/message/stat200today_send_total:1 / unread_total:1OK
/api/message/template/list2006 条(如「合同到期提醒」)OK
/api/message/push/log2002 条(如「气象橙色预警」推送)OK
/api/message/announcement/create200anno_id:140205 落库成功写路径通
一个容易误判的点:这些写接口(template/save、announcement/create)用的是 query 参数,不是 JSON body。用 JSON body 调会报 422——看着像故障,其实是参数形态不同。前端 api() 封装会把参数转成 query string,所以页面侧完全正常,无需改动。

2.3 消息板块的跳转目标 · 死链修复

被引用页原状态处置
payment_page.html死链(message_notice_mobile.html 与 system_dict_mobile.html 两处引用)已补建 9376 字节
板块总汇.html存在 32506 字节正常

三、验证脚手架的「假故障」根因(重要)

!中文页 slug 全部塌缩成下划线 → 验证结果假报 22/33

验证脚本里 slug=re.sub(r'[^A-Za-z0-9_]','_',文件名) 会把 14 个纯中文页名全部变成一串下划线,互相覆盖块文件和数据文件。于是脚本读到的"页面数据"其实是另一个页面的 → 大量假"0 命中"。

修复:改成 slug="%03d_%s" % (序号, 基名) 加序号前缀 → 33 个唯一 slug。结果从"假 22/33"变成"真 32/33",再补齐后达到 33/33 满分。

教训沉淀:任何以中文名做文件名的批量处理,都必须用 序号+原名 或 hash 生成唯一键,绝不能只靠字符过滤。

四、全站标签语义 · 33/33 满分

起始是"假 22/33"(slug 污染)。排除污染后真值 32/33,最后 1 页补齐,达成 33 页 / 165 个标签 / 100% 命中 / 零个 0。

本轮新修 / 校准的页映射

页面问题修复
fangji.html 方剂配伍知识库数据源误配 /api/processing/list(炮制工艺池),除"饮片配方"外全部 0 命中改接 /api/mobile/kb_foodherb/list(知识库池)+ 重写标签 + 补种 10 条
jicai.html 集采招标标签是"集采招标/大宗求购",却读 /api/bulk_trade/list(已成交单)→ 0 命中改接 /api/bidding/project_list
行情资讯大屏.html缺「产地快讯」标签补:「甘肃 / 陇西 / 岷县 / 安国 / 内蒙古…」产地关键词组
集采招标专区.html / zhaobiao.html缺状态类标签补:正在招标 / 即将截止 / 已中标公示 / 历史项目
大宗集采交易专区.html分区语义未对齐补:分区:jicai / 分区:bulk 结构化分区键

语义分类器已升级为三级

另设全量快照冻结机制 window.__FILTER_ALL:首屏真数据到达时冻结快照,防止 apply() 覆盖 __REAL_DATA 造成"筛选结果随点击顺序变"。

五、全站 B1~B5 链路 · 回归盘点

链路内容状态
B1基础路由与导航骨架回归通过
B2真数据适配层(真 fetch 优先 + 种子兜底)38 页已注入
B3后台管理入口接管回归通过
B4配色收敛(国风设计语言)决策保留
B5中英副本 / 功能页保留回归通过

六、数据补种(全部走后端真实接口落库)

脚本接口新增内容
_seed_news.py/api/info_news/add6产业政策×2 / 产地灾情×2 / 行业分析×2
_seed_price.py/api/trade/market_price/add4山药 / 莲子 / 百合 / 红枣(药食同源行情)
_seed_all.py批量多接口20炮制 8 · 仓储知识 4 · 招标 2 · 供应会员 2 · 加工厂 2 · 劳务 2
_seed_fangji.py/api/admin/kb_foodherb/save10经典名方×4 / 药膳×3 / 食疗禁忌×2 / 药茶×1
_seed_bid.py/api/bidding/project/add3已中标公示×1 / 历史项目×2
合计43条真实记录

各池当前真实存量(实测)

数据池条数数据池条数
市场行情12资讯新闻9
炮制工艺9集采招标8
仓储知识8劳务工人8
供应会员7加工厂7
消息模板6采购单5
种子种苗5大宗求购3
推送日志2推送失败重试0

七、表单页真接口补接

此前 land_transfer.html / seedling.html / 种子种苗资源库.html / 土地流转撮合.html 的发布按钮是 alert() 空壳桩。本轮升级为真 fetch:

用户填表→ publishLand() / publishSeed()→ /api/land/publish · /api/seedling/publish→ 落库返回 record_id
接口实测返回
/api/land/publish200 · 土地地块信息发布成功,等待实地核验 · LAND000000004
/api/seedling/publish200 · 种子种苗档案发布成功 · SEED000000004

4 页注入后语法检查全通过。

八、12 路侦察兵 · 本轮体检

侦察兵职责结果
S1筛选死键页0
S2静态死页4(全是本报告类静态页,设计如此)
S4接口 404 误配0
S6零接口页73(约 50 个纯导航专区卡片,无需数据)
S9空池接口0
S11配色混用8(国风设计语言差异,B4 决策保留)
S12死链0

九、外部客户端代码 · 搬迁评估(维持上轮结论)

结论:现在不搬。按你的口令——"先不要往里面归纳,检查没问题了、没有 bug 了、没有其他的坑了,咱们再往里面放"。

本轮的 P0 系统级故障(21 模块 os 缺失)恰好证明了这条纪律是对的:连自家刚生成的模块都还能整批漏 os import,此时再叠加一套外部代码,故障会互相掩盖、定位成本翻倍。

入库前置条件(全绿才放):

十、下一步 · 候选清单

优先级事项说明
P0外部代码隔离验收等你提供代码包 → 静态审查 → 出合并方案(哪些合并/哪些不动/风险点)→ 你拍板
P173 个零接口页 · 二次筛选挑出"该有数据但没接"的继续补 B2(land/seedling 类已补完)
P1首页实时条扩展把行情 / 招标 / 资讯的实时数字挂到首页
P2S11 配色 8 页收敛等你确认是否要统一为国风主色系
P2S2 静态报告页归档把历轮战报移入 /reports/ 子目录,减少根目录噪音
一句话总结:本轮干的是一件"看不见但致命"的事——把 21 个后端模块的集体瘫痪修掉了(此前所有写操作全 500),顺手把验证脚手架自身的假故障根因挖了出来。全站现在 196/196 页 200、死链 0、标签 33/33 零 0、数据池全部非空。外部代码继续按你的口令隔离等待。