v3 小程序 · 内容与结构总稿

起草：小冈 ｜ 2026-09-28 ｜ 性质：内容与结构一揽子稿（页面文案底盘 + 内容库灌入 + 素材清单），供刘总审阅拍板

事实基线：本机 ~/dev/kailash-xiaogang @ 17329e16，文中数字均为当日实测，不掺推断。

一、现状盘点（先摸清家底）

1.1 页面与文案底盘：架构已在，9 页没收口

• app.json 注册 27 页（09-27 上线清单口径 24 页，另有 health-check / review / share-code 等；debug-gallery 已砍）。
• 文案三层结构已经落成，本次总稿不推翻、只收口：

• 读取规则（utils/content-config.ts 已实现）：L3 优先 → 取不到留空或「—」→ 禁止写死兜底（刘总铁律）。
• 9 页未接文案中心（texts 引用=0，wxml 硬编码中文实测粗估）：

1.2 内容库：稿子齐、管道通、库里是空的（最大缺口）

• 稿子本体在仓：docs/content/ 14 个正式类目 正好 142 篇（history 15 / geo 15 / kora 12 / culture 12 / practical 16 / zhidaburi 10 / routes 12 / people 10 / symbols 8 / seasons 6 / food 6 / photo 5 / about 5 / safety 5），与文案「神山脚下的 142 篇」对上；另有 content/ 24 篇辅助材料。
• ⚠️ 数字待核：093 迁移注释写「冈子 162 篇」，与 142+24=166 差 4 篇——灌入前对一次清单。
• 线上实测为空：GET /api/miniapp/guides 与 /guides/categories 均返回 0 条 → content-library 页线上空态，x2 文案「神山脚下的 142 篇」当前失真。
• 093 迁移只建字段骨架（slug / category / body_html / source_file / is_test / has_verify / cover_note），0 条 INSERT——灌入动作从未发生。
• 审校机制已内置：is_test=true 入库、审校后翻转；has_verify（正文含【核实】标注）不得作为核心卖点上线——抽查样文（如高反处置手册）标注密度较高，此纪律会实质影响哪些篇目能上前台。

1.3 商品与素材

• shop：6 件示例商品走前端兜底（刘总「示例先行、A 端配置后自动失效」口径，SAMPLE 注释在案），价格位一律「—」；A端 shop.items 配置后示例整体消失。
• 图片：AI 示例图两份登记表（09-22 首批 + 波波续册）+ 波波 32 张配图交接清单（待主会话领取）；首页 17 图槽已接真实图（v5 概念稿时 17/17 外网 200 复验）。
• COS：upload.py 代码就绪，只差 COS_SECRET_ID / COS_SECRET_KEY / COS_REGION / COS_ASSETS_BUCKET 四配置（WIP-230 链路，给了密钥须重启容器复测）。

二、结构稿

2.1 文案三层结构（定型，9 页按此收口）

• key 命名：<域>.<对象>.<字段>（如 svc.hotel.price_range、dest.pages）。
• 9 页收口时：UI 固定文案进 texts.ts 键位组；业务性内容（列表数据、字段值）走 L3；页面 t.s 兜底禁造句。
• 优先序建议：order-detail（涉钱展示）→ product-detail → profile → vouchers → shop → destination/guide-companion/voice-guide/review。

2.2 内容库栏目结构（灌入即定，后期 A 端可调）

• 14 类目 → content-library 页签按类目原序映射，展示名后配（category.banners 既有键位不动）。
• 🔴 destination 页联动约束（灌入硬条件）：DEST_TAGS 按 tag 取文——冈仁波齐=「转山/符号/地理」、芝达布里=「芝达布日/人文/温泉」。灌入时这六个词必须成为对应篇目的 tag，否则目的地页文章区为空。当前 md 正文有内容、tag 字段需要灌入脚本按类目映射补。
• 带货链路红线（波波稿拍板口径，对内容稿的落点）：
• 攻略内嵌服务方卡=纯联系卡：无价格、无「预订/下单/订单」字样，C 端唯一动作=联系；
• 带服务方的内容标「推广」；
• has_verify 篇目不进核心卖点位（首页推荐/目的地头图位）。

2.3 灌入管道（复用既有，不新造）

• 字段：093 骨架已备（slug 唯一索引 / category / body_html / source_file 留 md 路径 / cover_note 配图说明）。
• 流程：md → body_html 转换脚本（新增，纯文本转换，不动 pipeline）→ 批量 INSERT（is_test=true）→ staging 冒烟 → 审校翻转。
• 既有 tools/ali-content-pipeline（AI 抽取→交叉校对→合并→标准化）保留给路线/POI 结构化用，142 篇图文灌入不走它——稿子已是终稿正文，缺的是搬运不是生产。

三、素材清单与首灌批次建议

• 配图：每篇样图位按 assets/NN-MM.jpg 命名约定，对齐两份 AI 示例图登记表；从稿内「样图」标注自动汇总缺图补拍清单交波波/摄影。
• 7 天素材供给（冬闲拍摄任务、行程跟拍副产品）按《内容生产流程设计》§3 归口，不阻塞灌入。

四、执行顺序与验收门禁

1. 灌 P0 27 篇入 staging（tag 按 2.2 补齐）→ content-library / destination / content-article 三页冒烟。
2. 线上执行同批（生产库迁移人工执行，遵守「只增编号」）。
3. 9 页文案中心收口（可与灌入并行，分批派工）。
4. 验收门禁：GET /api/miniapp/guides 返回 ≥27 条；两个目的地页文章区非空；has_verify 篇目不出现在核心卖点位；「142 篇」文案与库内实际篇数一致后才恢复数字表述。

五、待刘总拍板

1. 首灌范围：142 全量 vs P0 27 篇先行？（建议 27 篇先行，改动面小、见效快）
2. 「142 篇」文案：灌入前是否先改中性表述（线上空态下该文案失真）？
3. 9 页文案收口排期是否与灌入并行？
4. 162 vs 166 差额 4 篇：灌入脚本跑清单核对后如实报告，短篇补写还是豁免？