功能提报 · 库与采集侧视角

旅行综合系统库库提交星星汇总 · 供 Ling 裁决

提报人 库库（agent-travel-kuku） 日期 2026-09-14 收件 星星（汇总）· Ling（裁决）
性质是提报，不是设计：所有条目都在既有设计之上做加法，溯源见第一节。星星资产台账的铁律已遵守——开工先读了 L-1 / L-2 / L-3 与派生件，本稿每一处"说缺 X"之前都查过。

设计早就完整，业务没跑在设计上。库有 70 张表八个域，活着的只有身份、观测、匹配三个域；交易、囤房、自动动作、POI 四个域是空壳；业务真源分裂在库、飞书表、本地 json 三处。综合系统的第一刀不是加功能，是把真源合一——从囤房开始，因为钱在那里。

01

溯源：这份提报站在哪三层之上

层件作者 · 时间地位
L-1 鹭兴国际 酒店知识库结构设计 v3.3（38 表） Ling · 2026-01-21 canonical 建库图纸。存算分离 / 报价不可变快照 / 囤房 Holds / 刷房 MonitoringTasks / 自动下单 AutoBookingRules / 77 标签
↓ 知识库 v3.4 s2 定稿（69 表 + 13 视图） 三方收敛 · 2026-08-24 · Ling 四点裁决 L-1 的演化：合并 v3.3 的 Policies 与 RatePlanTerms、三层审计改两件套、追加行程供给域（Ling 裁决"一次性搞定"）、Ops 三段式、知识断言链
↓ 生产库 luxing_kb LX01 · PostgreSQL 17 · 2026-08-24 走查 23 组场景全绿、并发无超卖、税费 5/5 官方一手来源盖章
L-2 luxuryops-frontend Ling 用 Opus 4.5 · 2026-02 管理网页的 canonical 基线。Next.js + 三角色权限；页面 Dashboard / hotels / quotations（Quote Bar）/ calendar / monitoring / auto-rules / settings。Ling 点名两条必须继承：AI 与人双轨；一个数据库多种维度
L-3 2026-01 设计基因（UI-UX-REFERENCE） Ling · 2026-01-29 顶栏导航 / 三栏作战屏 / Quote Bar 常驻 / 设计 token / 权限模型 / multi-project 组合报价
派生 星星 07-03 至 07-16 的愿望清单、UI 设计、页面原型、四柱设计包 星星 全部搁置未建。本稿不重复其内容，只标引用

本稿的加法在哪。L-1 / L-2 设计时库还是 SQLite 三表；现在库是 PG 70 表且有 40 天生产数据。本稿提的是"让 L-2 的页面接到 v3.4 的表上"以及"让业务真源从库外收回库内"，不新设计任何一张表、任何一个页面。

02

数据侧真实底账

2026-09-14 测量

2.1 八个域的落地程度

域表行数状态说明
身份property / room_type / property_alias6857 / 154 / 61活ACTIVE 69 · CANDIDATE 6786 · ARCHIVED 2
渠道观测src_listing / src_room / price_observation / channel_quote / stg_offer6868 / 452 / 18,775 / 20,237 / 687,553活21 个渠道，43 家酒店有现价
匹配判定listing_match_decision / room_match_decision6871 / 400活房型匹配是我们的真底气
治理audit_event / row_history / ingest_batch / schema_version29,197 / 7034 / 1006 / 1活每次灌数、每个判定都有痕
证据booking_ledger_evidence3409活确认函账本，成交候选
知识source_document / evidence_fragment / vocabulary / tax_rule / assertion8 / 25 / 39 / 5 / 0半空文档和片段有，断言链一条没有
交易quotation / booking / settlement / fx_rate / commission_rule全 0空壳
囤房囤票inventory_batch / inventory_hold / inventory_unit全 0空壳囤房真源在飞书表（106 行）+ 本地 json
自动动作action_intent / effect_receipt / capability_envelope / monitoring_task全 0空壳抢房链路用自己的 jsonl 工单 + kuku_auth.json，绕开了库
POI 供给poi / poi_offering / poi_quote / poi_inventory_*全 0空壳表在，采集没起
可订性availability_observation0空抢房探针的日历观测流写在 TX 本地 jsonl，没进库

2.2 业务真源分裂在三处

真源装什么谁在用
luxing_kb酒店身份、房型、渠道价格观测、匹配裁决、审计采集流水线、比价视图
飞书囤房表（106 行）囤了哪些房、哪个号、免取消截止、售卖状态Ling、员工、客服
本地 json 与 TX 工单流抢房台账、分队编制、作战计划、工单流三机派单守护、下单器

后果已经发生过：囤房与账号对不上（9-07 查出机器名硬编码与姓名截断两个 bug，靠开 52 个号扫平台订单才对回来）；抢房重启回放旧工单重复下单（9-06）。这两起事故的共同根因都是真源不在库里，库里的结构约束——幂等键、封套上限、对账闸——帮不上忙。

2.3 比价的真实数字

231
可比价（拒绝码为空）
0
跨渠道可比对
43
有现价的酒店

跨渠道对为 0 的原因不变：一休 / 雅虎侧服务费含否证据不足，PARTIAL 进不了可比。这是采集侧证据问题，不是库结构问题。

2.4 业务现在靠什么跑

75 个脚本（16 抢房链 + 31 采集链 + 28 其他）、1 张飞书表、命令行状态板。没有任何一个网页。星星 7 月的工作台是另一套（微信库侧），实测零人使用。

03

功能提报

按"谁要用 × 哪个域"提。每条标：基于哪层既有设计 / 现状 / 提什么 / 为什么。

P0真源合一（钱在这里）
F1
囤房真源入库
基于
L-1 InventoryAllocations / Holds → v3.4 inventory_batch / inventory_hold / inventory_unit
现状
三张表 0 行。真源是飞书表 106 行，SEQ 列 9-07 刚对上 95/96
提
飞书表 → 库：一次性迁入，此后库为真源，飞书表变成库的只读投影定时同步。inventory_unit 一行 = 一个予約番号 + 一个账号（SEQ）+ 免取消截止；v_deadlines 视图已建好，入库即自动有截止雷达
为什么
囤房是公司现金占用最大的资产；SEQ 刚对齐是数据最干净的时刻；库到飞书投影可逆，库出问题飞书表还在
F2
抢房链路接 Ops 三段式
基于
L-1 AutoBookingRules → v3.4 action_intent / action_attempt / effect_receipt / capability_envelope / action_reconciliation
现状
全 0。授权在 kuku_auth.json（enabled / expires / 价帽 / 每酒店间数），台账在本地 json，工单在 TX jsonl。9-02 授权静默过期四天无人知、9-06 回放重复下单，都是绕开库的代价
提
授权文件 → capability_envelope（三上限 NOT NULL，结构上不存在无上限授权）；派单 → action_intent（幂等键防重）；下单结果 → effect_receipt（没有确认号在数据库层面就不存在这笔预订）；台账 ↔ 回执 ↔ 订单 → action_reconciliation
为什么
抢房是真金白银，事故已经发生两次；三段式的触发器和 CHECK 就是为这个场景设计的，不用等于白建
F3
可订性观测流入库
基于
v3.4 availability_observation（按月分区已建到 2027-07）
现状
0 行。TX 抢房探针每 15 秒读一次日历，结果写本地 jsonl，从没进库
提
探针命中与未命中都写 availability_observation。放房时点规律、哪家几点放、放多少，全靠这条流才能事后分析
为什么
你问过"放房时点有没有规律"，答案是"上月时刻不是规律、只有实测算证据"——证据现在散在 jsonl 里，没法查
P1管理界面 MVP（让别人也能看、能操作）
F4
囤房看板
基于
L-2 已有 Dashboard + calendar 页面骨架 · L-3 三栏作战屏
提
按 SEQ / 机器 / 酒店 / 入住日筛；免取消截止倒计时（v_deadlines）；售卖状态一键改（未售 → 已售 / 已取消，写 row_history）；订单卡片直达平台详情页
谁用
Ling、销售、客服
F5
采集与灌入健康
基于
L-2 monitoring 页面
现状
命令行状态板，只有我看
提
渠道 × 最近采集时点 × 灌入错误（v_ingest_errors）× 待匹配（v_match_queue）× 作业单饥饿（v_collection_due，现 57 家）。三机派单守护心跳、TX 探针心跳、授权到期倒计时。任何一项失效必须红在页面上——9-02 到 9-06 静默失效四天的教训
谁用
我、搜搜、星星
F6
可比价与跨渠道对
基于
L-1 ChannelPricing + 存算分离 · L-2 hotels 页
提
v_price_comparable 231 条按酒店 / 渠道 / 住期展示；被拒的按 reject_code 分组——拒绝码自带修法，页面直接显示"怎么修"；跨渠道对出现时高亮
谁用
星星（选品）、销售（报价参考）
F7
房型匹配裁决台
基于
v3.4 room_match_decision + v_match_queue
现状
裁决靠我在命令行跑 apply 函数
提
待匹配队列 → 人点 EXACT / DIFFERENT / UNSURE，带证据面板（facet 冲突 / 同名铁证）。织织供候选，人裁决，库只增
谁用
织织、Ling（KUKUNA 那类存疑对由他确认）
F8
客户订单登记
基于
L-1 → v3.4 booking / settlement / business_entity
现状
booking 0 行。真客户订单在微信库（星星侧 2878 单 / 1812 客户）和作战号的平台后台里混着
提
先手工登记入口（订单号 / 客户 / 酒店 / 住期 / 渠道账号 / 金额 / 免取消截止），settlement 挂应收应付。与星星侧微信库订单的对齐是集团合同的事，先各自成结构再谈打通
谁用
销售、财务
P2知识与扩展
F9
知识断言链录入
基于
L-1 KnowledgeChunks / 77 标签 → v3.4 assertion / assertion_evidence / policy_term / v_citable_assertion
现状
assertion 0 行。儿童政策 8 份实证入了 source_document，没形成断言
提
录入界面：选主体（酒店 / 馆 / 房型）→ 断言 → 挂证据片段 → 极性（肯定 / 否定）。报价引用只认 v_citable
为什么
知识库是公司核心数据库，"每条事实能指回原文哪一行"是它的定义
F10
B2B 净价源接入（Dida 类）
基于
v3.4 channel.profit_model / price_basis_default / commission_rule
提
channel 增"内部价 / 不对客展示"标记；报价视图对这类渠道的价只进内部定价，不进任何对客输出；费用明细（IncludedFeeList / ExcludedFeeList）按项落，不压总价；取消政策时间字段改带时区存储
为什么
Dida 问卷已填，接进来就要用；净价展示给客人 = 没利润
F11
POI 供给域启动
基于
v3.4 s2 行程供给域（Ling 裁决"一次性搞定"，表全在）
现状
全 0
提
先不采集，先从 booking_ledger_evidence 3409 条确认函里把餐厅 / 门票 / 接送的成交历史结构化进 poi / poi_offering——这是零成本的种子
谁用
星星（行程组装）
04

边界与协作

席位持有本稿哪些条目要经他 / 她
圆圆集团 canonical 数据合同、统一实体边界F1 / F2 / F8 涉及库表变更，须在她的合同下走迁移文件
搜搜外部来源接入、采集调度F3 / F5 的数据源是他的链路
织织数据质量、知识运营F7 候选由她供；F9 质量标准她定
星星端到端业务结果本稿全部条目的优先级由她汇总裁决，我不定
05

我建议的第一刀

F1 囤房真源入库

  1. 钱在这里。106 行囤房是公司现金占用最大的资产，真源在一张飞书表里，没有任何结构约束。
  2. 现在是数据最干净的时刻。9-07 刚把 SEQ 对到 95/96，再拖一个月又会漂。
  3. 可逆。库 → 飞书表投影，飞书表不删，库出问题随时切回。

F1 落地后 F4 囤房看板就有了数据源，F2 抢房接三段式就有了对账的锚点（inventory_unit ↔ effect_receipt）。这三条是一条线。

不建议第一刀做的：F11 POI（采集没起，做了也是空的）、F9 知识链（重要但不紧急，没有事故在等它）。

06

本稿引用的既有资产