C端消费 × A端录入 · 对接盘点 —— 波波 2026-09-25

义父问：「是不是应该详细看一下 C端代码，分析 A端有没有完全对接上」。

铁律是「业务数据一律 A端录入，C端只读、绝不写死」。

要验证这条铁律是不是真的成立，不能看 A端有多少页面——

得从 C端出发：它读了什么、数据存在哪、A端有没有对应的写入能力。

本报告按这个方向逐项核到底。

一、核对方法

扫 miniprogram-v2 全部 API 调用（apiGet/apiPost/...），拿到 C端消费的端点全集
对每个端点找后端实现，确认它读哪张表
反查后端有没有对应的 admin 写接口（POST/PUT/DELETE）
再确认 A端页面是否真的调了这个接口（避免"有接口没页面"或"有页面接错表"）

区分两类数据，避免误报：

业务数据（文案/商品/攻略/路线…）⇒ 必须 A端可录入
行为/交易数据（订单/消息/评价/分销/福钥）⇒ 用户产生，本就不需要录入

二、逐项对照结果

✅ 已对齐（铁律成立）

C端消费	数据源	A端录入	备注
`content/items`（文案）	`content_items`	文案字典 + 业务数据配置	3069 键目录可搜可改，改完 C端冷启动生效
`products`（商品 50 条）	`packages`	商品管理 `/products`	同一张表（`admin_backend.py:730` 也读 packages），我灌的 50 条 A端能直接编辑
`combo-cards`（首屏推荐）	`packages` + `routes` 派生	同上 + 内容资源/routes	无需单独录入
`merchant-pages/{id}`	`merchant_pages`	商户页模板	C端拉已发布 DSL 树渲染，A端配什么长什么样
`kora-trackers`	`orders` 聚合	不需要	是行为数据（进行中订单统计），非业务配置
orders / reviews / messages / distribution / key-tasks	各业务表	不需要	用户产生的数据

❌ 硬缺口：C端展示，但 A端录不进去

C端消费	数据源	现状
`guides`（攻略 10 条）	`guides` 表	后端只有读接口（`feed_demand.py`、`guides.py`），无任何 admin 写接口
`content/guide-articles`（攻略社区 20 条）	`guide_articles` 表	同上，无 admin 写接口

这两处直接违反铁律：运营想改一条攻略、下线一篇社区文章，只能找开发改库。

而且它们是游客能看到的内容，属于白标"换皮"必须要能改的范围。

⚠️ 天气：数据源早就通了，卡在 C端组件口径（此处我第一版判断错了，已更正）

第一版我写成"天气是空壳"，是错的。 义父指出"天气数据源很早之前就提供了"，

复查后确认：数据源确实早就就位并且在正常工作。

真实实现在 services/qweather.py（和风天气）+ routers/weather.py。

prod 实测 GET /api/miniapp/weather：

{"temp":"6°","desc":"阴 · 西北风3级","pass":"通行","sunrise":"08:26",
 "source":"qweather",
 "sourceMeta":{"sourceName":"中国气象局·和风天气",
               "publishedAt":"2026-09-25T12:25+08:00","pointName":"塔钦"}}

温度/天气/风力/日出/通行状态齐全，且 sourceMeta 已经把

来源机构（中国气象局·和风天气）+ 更新时间 + 观测点（塔钦） 都挂上了

——正好满足设计红线"天气须来源机构 + 更新时间双挂"。

那为什么我第一版会看错？我只看了 feed_demand.py 的 /weather/today：

# site_config 无 weather_today_default 键，返回配置零值
cfg = {}

它是空壳没错，但它不是给 C端现在用的。查 docs/structure/contracts/sources.json：

bff.weather_today 的唯一消费者是 **weather-strip 组件，而该组件为 pending

（14/15 类口径未定）⇒ 口径落地前该 source 实际不可引用，引用即 E_TYPE_PENDING**

所以准确结论是：

数据源 ✅ 早就通了（和风天气，含来源与时间双挂）
真实端点 ✅ GET /api/miniapp/weather 工作正常
真缺口：C端 v2 目前消费的 /api/miniapp/weather/today 是给未定组件的占位；

且真实端点 GET /api/miniapp/weather 需要登录，游客首屏若要免登录看天气，

还缺一个免登录的天气出口

教训（同"截断输出就下结论"一类）：我只 grep 到一处实现就断言"没接"，

没查 services/ 层、也没读 sources.json 的组件口径说明。

判断"有没有接"之前，必须确认是不是只看到了局部。

❌ 孤岛：A端能录，但 C端不看

A端页面	管的表	C端是否消费
内容管理 `/cms`（含发布/下线流程）	`cms_posts`	完全不消费（全仓无引用）

运营在这个页认真录文章、走发布下线流程，C端一个字都不显示。

这是最浪费的一类错配——流程齐全、数据沉淀，但接错了头。

⚠️ 待确认（未下定论，需归属方核）

项	疑点
场景管理 `/scenes`	库里 `scenes` 表不存在；C端只用 `POST /scenes/checkin`（打卡动作），不读场景列表 ⇒ A端该页产出疑似无人消费
故事管理 `/stories`	`dsl-sources.ts` 明确写着：stories 未登记，引用将被拒绝（`E_SOURCE_UNKNOWN`），差异已上报 P2 ⇒ C端实际不消费

三、结论

A端没有完全对接上。 按"从 C端反查"的口径：

对齐的：6 类（文案/商品/推荐/商户页 + 两类本就不需要录入的行为数据）
硬缺口 2 个：guides、guide_articles（违反铁律，游客可见，白标必须能改）

—— 已复核确认：后端 admin 层确实无任何写接口（admin_content.py 只有 POI/路线/规则/攻略知识/配置项）

天气：数据源与真实端点均正常，非空壳；真缺口是 C端 v2 消费的占位端点未接真实数据，且真实端点需登录
孤岛 1 个：cms_posts（运营白录）
待确认 2 个：scenes、stories

也就是说，A端页面数量不少，但与 C端真正消费的数据对得上的只是一部分；

最讽刺的是两头都断：能录的没人看、要看的录不了。

四、修复优先级（按"游客是否直接受影响"排）

优先级	事项	为什么
P0	天气：把 C端消费的 `/weather/today` 接上 qweather 真实数据（或让游客端改用已就绪的真实端点，并补一个免登录出口）	数据源早已就位，只差最后一米；游客首屏看不到真实天气
P0	给 `guides` / `guide_articles` 补 admin CRUD + A端录入页	违反"业务数据 A端录入"铁律；白标必须能改
P1	`cms_posts` 要么让 C端消费、要么下线该页	避免运营继续白录
P2	确认 `scenes` / `stories` 归属后处置	疑似孤岛，需归属方确认

五、备注

本次盘点只做只读核对，未改动任何 C端或他人域代码。

涉及 guides / guide_articles / cms_posts / scenes / stories 的修复，

按跨域纪律需确认归属后再动。