工作台功能总设计 · 库库草案 v0.1

2026-09-14 · 库库 · 交星星决定,星星升级完模型前不转交
依据:Ling 9-14 四轮口述(见《构想整理 v2》)+ 附录 A(星星/拓拓/Ling 2 月设计资产盘点)+ 附录 B(微信数据平台盘点)+ 附录 C(酒店库能力盘点)。
体例:每页写「目的 / 谁用 / 主对象 / 数据来源 / 动作 / AI 参与点 / 现状缺口」。标 [Ling 定] 的是他定的;标 [建议] 的是我的;标 [未知] 的要星星或 Ling 补。
00

一句话与三个前提性发现

一句话: 一个网页工作台,四种人(销售、运营、经营、Ling)和四种 AI(行内建议、嵌入式 pi、AIOS 席位、自动规则)在同一套 API 上操作同一批对象;对象来自两个库(微信 normalize.db 只读、酒店 luxing_kb 读写),工作台自己的操作数据放进 luxing_kb 新开的 workbench schema。

三个会改写设计前提的发现(盘点后才知道):

  1. 微信侧是纯读平台,零写接口、零发送通路,回复建议表是空壳没有生产者(附录 B §B4/§C3/§D)。"一键回复微信"在今天不存在实现基础。Ling 9-14 已裁:复制发送由人自己做,沿用 2 月锁死的决策:复制进微信 = 发送 = 归档。
  2. 微信侧销售队列的三个视图在代码仓里没有 DDL,只活在活库里;生产 API 没开鉴权(附录 B §A7/§B3)。工作台接微信侧的第一件事不是画页面,是把这些视图的定义找回来写进仓库。
  3. 酒店库的读侧几乎免费:19 个视图无参带注释、inquiry_evidence_card() 现成、reject_code 自带修法;写侧只走函数。但 D5 决策明文写着"Web 界面、可视化看板不在范围内"(附录 C §H)——Ling 9-14 口述已事实解除,决策记录要补一条 D6。
01

原则(不再讨论的)

[Ling 定] 两库一 API 四消费者;AI 三层(复杂→AIOS 席位、简单→DeepSeek Flash、员工→嵌入式 pi);路由是可调的表;供给切换是配置;功能优先不做风控;数据事业部自持不经集团;聊天原文可送模型;系统不调 Anthropic API;新开独立仓;Cursor 做前端、API 与库我们自己做。 [建议保留的 2 月两条规则] AI 与人双轨;一个数据库多种维度。 [继承的设计规则](附录 A §C,全部沿用,不重新发明):色彩 = 语义;三档密度 扫/展/钻;数字牌三态 chip,裸数字不许上屏;依据角标,AI 说的每句话两下点到证据;Omnibar ⌘K 三段式且必须能执行动作;门铃三级;键盘优先;空态三句式;三栏作战屏;黄铜线 = AI 唯一标识;影子→落墨;血缘章三级;动效 ≤300ms;负面清单(不做独立 AI 页签、不做空白 chat 首屏、AI 只装配白名单组件、全站禁 emoji);假功能死罪(mock 必挂橙标);步数账(队列→复制进微信 ≤4 次交互)。 [继承的数据纪律](附录 C §A):五个不变量 I1–I5;写路径只走函数;UNKNOWN 不补;只增不改;reject_code 驱动"为什么不能比 + 怎么修"。

02

用户、角色、海拔

用户每天干什么海拔(看什么)角色(能做什么)
销售回客户、报价、追单L1 我的一天 / 主战屏 / Quote Barsales(senior/junior 两档,差别在手填估价、低利润报价权限)
运营(订房/囤房/采集)下单、囤房登记、看死线、盯采集与抢房L1 运营视图:囤房、作战、采集健康ops(囤房释放/延期/批量、授权封套只读)
财务应收应付、佣金、汇率财务页finance
经营(星星 / 克克)队列健康、漏单、漏斗、负载、建议质量L3 总览 2×2 + 周审计manager
Ling五件事、脉搏、拍板L4(飞书卡片优先,网页可看)admin
AI 席位 / pi / 规则引擎同上述人一样的动作,但不发不付agent(token 鉴权,映射到库角色 kb_reader / kb_trade,永不映射 kb_curator 之外的删除权)

[建议] 角色模型统一成上面一套(附录 A §D 指出 2 月代码里三套并存);权限点沿用 2 月 permission.ts 的 40 个点 + 囤房/作战/采集新增点;"权限点固定、角色映射可配置"照旧。[未知] 员工名单与谁是 senior:星星补。

03

信息架构

顶栏(黑檀,平铺):工作台 · 会话(n) · 客户 · 报价 · 行程 · 酒店 · 囤房 · 作战 · 采集 · 财务 · 管理 · 设置 | 右侧:AI 呼吸点 · ⌘K · 通知 · 头像。 全局:Omnibar ⌘K(导航 / 动作 / 意图三段);全局搜索(客户 / 酒店 / 订单 / 对话 / 囤房 / 确认号);通知中心(门铃三级);Action Feed 抽屉(agent 观测面);审计轨迹钻取(任何数字三跳到底)。 布局:L1 三栏作战屏;其余页面两栏或表格;v1 桌面优先,不做手机版(L4 走飞书卡片)。

04

页面级功能清单

4.1 工作台 · 我的一天(开屏)

目的:30 秒知道今天打什么仗。谁用:销售、运营(各看各的)。 主对象:今日必追 / 今日死线 / 昨夜新消息 三卡(可点=过滤)+ 必追清单 + 死线时间轴 + 晨报(全页唯一段落级 AI 生成物)。 数据:必追与新消息 ← 微信侧 thread_facts_v1 + lx_view_sales_response_v1 七态 bucket(附录 B §C1);死线 ← 酒店侧 v_deadlines(囤房取消日、报价失效、hold 到期,房票统一)+ 承诺回复时限(workbench.commitment,新表);晨报 ← AIOS 席位或 DeepSeek 按路由表。 动作:展开编辑 / 复制并采纳 c / 进入作战屏 / 标记已处理。 AI:晨报(路由表决定走哪层,生成失败整卡隐藏);必追草稿预生成(DeepSeek)。 缺口:v_deadlines 今天是空的(囤房没入库,M3);承诺追踪表不存在;lx_view_sales_response_v1 没被任何 API 消费且不在 migration 清单(先考古)。

4.2 会话 · 主战屏(三栏)

目的:全天驻留,回客户不翻聊天。谁用:销售。 布局:左 队列四段式(必追 / 等我 / 我在等 / 已清,每行 ≤4 信息点,j/k 上下)|中 要素卡 sticky 横贯顶部 + 对话时间线 + Composer|右 AI 草稿卡 1–3 + 客户档案 + 进行中报价 + 装配区。 数据:队列 ← /v1/lx/sales_queue / unanswered(视图先考古);时间线 ← /v1/threads/{account}/{thread_id}/messages(含 OCR/语音转写文本,附录 B §A1);要素卡 ← 从对话抽取(日期/人数/预算/在聊酒店/偏好/我方未兑现承诺)存 workbench.thread_facts_ai;草稿 ← message_reply_suggestion_v1(今天空,M5 让它活)。 动作:e 编辑 / c 复制并采纳(写采纳记录)/ x 拒绝(带原因,missing_knowledge 反哺知识库)/ 指派 / 记要素 / "把这段对话变成要素" / 开报价(Quote Bar)/ 记承诺(答应几点回)。不发送微信,复制后由人自己贴进微信发(Ling 已裁)。 AI:行内建议(DeepSeek,时刻驱动:客户问价→报价建议、犹豫→话术、含日期人数→字段抽取待确认);会话摘要预生成;囤房撞库命中 = 金色横幅(全产品唯一允许打断的元素)。 缺口:写侧全部要新建(采纳/拒绝/指派/要素/承诺);回复建议引擎按四柱设计 4 的八步实现(价格永远是 slot 占位符,绝不由模型编);两套 SLA 阈值要统一。

4.3 客户 · 列表与客户卡 360

目的:一个客户一页看全。谁用:销售、经营。 数据:列表 ← /v1/customers(tier / active / account 筛);卡 ← /v1/threads/.../workbench 复合对象(客户卡、行程、任务、建议、产物)+ lx_customer_dashboard_v1;tier ← customer_tier_final_v1(人工覆盖优先于 AI 建议);关系 ← customer_relationships_v1;备注 ← customer_notes_v1;历史报价/订单 ← 酒店侧 quotation / booking(按 global_party_id 对齐)。 动作:改 tier(人工覆盖)/ 加备注 / 加关系 / 建行程 / 看全部会话(跨账号只在 (account, party) 双键下展示,不合并身份,附录 B §D 红线)。 AI:客户画像摘要(依据角标);情绪扫(每 30min,管理面板用)。 缺口:notes / relationships / tier override 写接口不存在;workbench_customer_card_v1 悬空不能用,读 lx_customer_dashboard_v1

4.4 报价 · Quote Bar + 报价单

目的:询价→报价这条最大时间黑洞压到 3 次交互。谁用:销售。 主对象:报价卡(酒店·日期·房型·价格 chip·权益·失效期)、报价单(多酒店对比 / 多项目组合)、文案(简版/详版模板)。 数据:价格 ← 酒店侧 v_price_comparable(只用 comparable 行做报价数;被拒行降为"渠道检索信号")+ inquiry_evidence_card()(证据卡:每项带采集时间与证据指针,缺项进 unknowns)+ 到店付税提醒 v_at_property_taxes + 囤房现货 v_inventory_remaining(卖囤房优先)+ 汇率 fx_rate + 加价规则;落库 ← quotation(JSONB 快照 + content_hash + 锁定后仅 status 可流转 + citations)。 动作:一句话装配("报艾迪逊 7/17-20 两大一小")→ 预览卡逐字段可改(影子态)→ 落墨 → 复制简版/详版(复制 = 创建报价单 + 标 sent + 写剪贴板,任一步失败不复制);无价则占位 + 开核价工单流转运营;对比酒店;转图版(Phase 3,后置)。 AI:装配工不是设计师,只能选白名单组件(价格卡 / 比价表 / 免责条);缺日价且无 quotation_without_price 权限 → 复制按钮禁用并显示原因。 缺口:quotation 表零写路径;报价文案模板(2 月三个内置模板可直接沿用);汇率 0.045 无真源无时效(附录 A §G-4)——[未知] 汇率牌价由谁定、多久更新。

4.5 行程 · 行程编排与行程单

目的:多日行程组装、复杂报价、客户版行程单。谁用:销售、运营。 数据:trip_v1(微信侧,status=inquiry 就是 Inquiry 对象本身,不另建平行表,附录 A §B-7)为业务对象;酒店节点 ← luxing_kb property/room_type/quotation;POI 节点 ← poi/poi_offering(今天全空,先从 booking_ledger_evidence 3409 条确认函结构化种子)。 动作:建行程 / 加酒店晚 / 加 POI / 生成客户版行程单(图/PDF 品牌模板)/ 发起复杂行程工单。 AI:复杂行程与复杂报价 = 工单交 AIOS 席位(网页打包 → 自持工单接口 → 席位用订阅顶级模型处理 → 按格式回传,异步,用户可等)。 缺口:[未知] 行程产品结构(几类节点、定价怎么合、含不含地接)由星星定;行程单模板由 Ling 定品牌样式。

4.6 酒店 · 酒店库

目的:一家酒店的全部事实一页看全,带证据。谁用:销售、运营、经营。 主对象:酒店列表(地区 Tabs、场景/风格/人群/价带/餐饮筛选、优势等级、标签)→ 酒店详情(房型、渠道价、日历、政策、知识卡、在聊客户、历史成交价带)。 数据:property(ACTIVE 69 / CANDIDATE 6786,转正是人工动作)、property_aliasbuildingroom_typeprivate_bath_onsen 三态)、src_listing/src_room(渠道视角与匹配状态)、channel_quotev_property_coverage(失去一条渠道一眼可见)、tax_rulepolicy_term(报价只许引用 CONTRACTUAL/OBSERVED)、v_citable_assertionv_booking_ledger_by_property(历史成交,cny_reference_total 不是收入)。 动作:转正 CANDIDATE→ACTIVE / 编辑基础信息与标签 / 设采集节拍 collection_interval_hours / 加别名 / 快速报价(开 Quote Bar 不跳页)/ 建刷房监控。 AI:酒店档案摘要;标签建议(人确认)。 缺口:写侧走 kb_curator 角色,需 API 层封装;标签体系 2 月有 7+4 类可沿用。

4.7 价格日历与比价

目的:看价、看房态、看"为什么不能比"。谁用:销售、运营、经营。 数据:v_price_comparable(按 comparability_key 分组)、被拒行 + reject_code(description=为什么拒,remediation=怎么修,前端不硬编码)、v_quote_unit_conflicts(非空则相关结论不可采信,红标)、availability_observation(今天 0 行)、channel.quote_ttl_hours。 动作:按酒店/渠道/住期/人数筛;点拒绝码直达修法(补匹配 → 4.11;补税则 → 4.12;重采 → 4.10);单元格异动黄铜小点 + 建议字段更新(人确认写回)。 AI:异动检测(预生成,Action Feed 可点进源头)。 缺口:可比价 231 条、跨渠道对 0(一休/雅虎服务费含否证据不足);可用性观测流没入库(M3 之后由 TX 日历观测接入)。

4.8 囤房 · 现货、死线、撞库

目的:钱在这里。谁用:运营、销售(撞库)、Ling(风险)。 主对象:囤房批次(酒店×住期×房型×间数)、每间(予約番号 + 账号 SEQ + 机器 + 卡组 + 免取消截止 + 售卖状态 + 能否改名转客)、死线雷达。 数据:inventory_batch/unit/hold + v_inventory_remaining + v_deadlinesM3 囤房真源入库后才有数据;今天真源是飞书表 106 行 + 本地 json);下单证据 ← yahoo_evidence/ 目录 + effect_receipt(M5)。 动作:登记(下单器自动 + 人工补录)/ 改售卖状态(未售→锁定→已售/改名/免费取消/付费取消,写 row_history)/ 释放 / 延期 / 撞库匹配(新询单自动比对日期±1、同酒店、同房型)/ 一键到平台订单页 / 飞书表只读投影。 AI:撞库命中提示"手里有现货,毛利 X";T-3 未售提醒定价(自动规则)。 缺口:三张表 0 行;cancel_deadline 只活在飞书列;卖囤房优先的定价建议要成本 + 汇率真源。

4.9 作战 · 抢房与下单

目的:放房窗口内的作战面板,以及平时的授权与排班管理。谁用:运营、Ling(授权)。 主对象:目标房型登记(含业务理由)、授权封套(金额上限 / 单日次数 / 总次数 / 有效期 / 酒店白名单 / 住期区间 / 每酒店间数)、排班(seq ↔ 机器 ↔ 人)、工单流(TX 广播)、三机守护健康、结果回执。 数据:目标 ← kuku_room_targets.jsonmonitoring_task(M5);授权 ← kuku_auth.jsoncapability_envelope(三上限 NOT NULL,撤销级联);排班 ← machines.conf;工单 ← kuku_workorders.jsonlaction_intent;结果 ← 台账 + 证据目录 → effect_receipt(BOOKING_CREATED 必须带确认号);健康 ← 三机 kuku_autodispatch_status.json + TX 心跳 → 统一状态端点(kuku_watch_status.py --json 已是原型)。 动作:登记目标(必须写理由)/ 建或撤封套(Ling 或 admin)/ 改排班 / 一键武装或解除(arm/disarm flag)/ 看工单流与每单状态(CREATED→READY→DISPATCHED→SUCCEEDED/FAILED/UNCERTAIN)/ 假工单演练 / 对账(台账 ↔ 回执 ↔ 平台订单)。 AI:不在热链路(脑子是确定性代码);异常注入分队 AI 与网页告警同源。 缺口:今天全部在 json/jsonl 与三机状态文件里;授权到期静默失效四天的事故(9-02)要靠这页的红色状态和门铃杜绝。

4.10 采集与灌入健康

目的:任何一项失效必须红在页面上。谁用:运营、库库、搜搜。 数据:v_collection_due(作业单:饥饿度,从未采过排最前)、v_ingest_errors(失败行唯一出口)、ingest_batch(每批统计)、v_property_coverage、渠道 × 最近采集时点、TX cron 与 LX01 sync 心跳、代理出口健康、403 率、last_backup_status.json / last_mirror_status.jsonprice_observation 分区预建状态(无 DEFAULT 分区,超范围即告警)。 动作:重跑 batch / 改采集节拍 / 手动加作业单 / 看原文(evidence_ref → TX 镜像)。 AI:无(这页是确定性事实)。 缺口:今天是命令行状态板;备份 24h 内失败会挡迁移(db_migrate.sh 前提),这页要显示。

4.11 匹配裁决台

目的:把手写 SQL 的人工判定变成队列。谁用:织织、运营、Ling(存疑对)。 数据:v_match_queue(待匹配,rejected_pairs 提示已判过多少"不是")、v_match_exclusionssrc_listing/src_room 渠道原文与 facet、property/room_type 我方定义。 动作:判 SAME / NOT_SAME(酒店级)、EXACT / FAMILY / DIFFERENT / UNSURE(房型级,DIFFERENT 必须 facet_conflict 硬证据)→ 调 apply_*_decision(仅 kb_curator);判定只增不改。 AI:候选打分与证据面板(同名铁证 / facet 冲突),人裁决。 缺口:无 UI;写侧需 API 用 kb_curator 角色封装。

4.12 知识裁决台与断言录入

目的:每条事实能指回原文哪一行。谁用:织织、运营。 数据:source_document(authority_tier、supersedes 链)、evidence_fragmentassertion(今天 0 行)、assertion_evidencev_knowledge_conflicts / v_knowledge_polarity_conflicts(人裁决 AI 不选边)、tax_rule(税费种子全部 verified_at=NULL,待核)、policy_term。 动作:录文档 / 划片段 / 立断言(主体:酒店/馆/房型,极性 AFFIRMS/DENIES)/ 挂证据 / 裁决冲突 / 核实税则(填 verified_at 与出处)。 AI:从文档抽断言候选(人确认);回复建议 missing_knowledge 反哺这里的选题。 缺口:零工具;东京宿泊税 2027-04-01 改定率须换轨(时限事实)。

4.13 客户订单与财务

目的:订单、应收应付、佣金、汇率一处看。谁用:运营、财务、Ling。 数据:booking(渠道确认号、下单账号)、settlement(应收佣金 / 应付款 / 应收客款)、commission_rulepoints_rule(集团积分与 OTA 积分绝不同列比较)、fx_rate(汇率日表)、v_booking_ledger*(确认函账本:成交候选不是履约)、微信侧 trip_internal_v1(毛利、成本分解,Restricted)。 动作:登记客户订单(订单号 / 客户 / 酒店 / 住期 / 渠道账号 / 金额 / 免取消截止)/ 关联囤房间(改名转客)/ 记结算 / 维护汇率与手续费。 AI:确认函邮件结构化进账本(已有 3409 条);异常提醒。 缺口:全部 0 行;[未知] 结算规则、谁记账、微信侧毛利字段与酒店侧 settlement 的关系:星星 + 财务定。

4.14 管理面板(L3)

目的:经营驾驶舱,替代手跑 SQL。谁用:星星、克克。 数据:响应健康(未答队列长 / 首响中位 / 超 30min 计数;Phase 1 退出指标 中位 ≤15min)、漏单雷达(强信号未接实时列表)、成交漏斗(询价→报价→成交,报价后 48h 无跟进单列)、囤房风险面(T-3/T-2/当天)、建议质量面(采纳率 / 编辑率 / 占位率 / FATAL + miss 热度)、AI 用量与路由采纳率(每类任务走了哪条路、被采纳没有)、负载热力、周审计工作台(抽样 N=20 三格判级 + 一键回写)。 动作:一键提醒销售 / 升级 / 调路由表 / 改 SLA 阈值。 缺口:微信侧聚合视图要重建(悬空);采纳率与成交结果解耦并行追踪(附录 A §B-7 的反身性陷阱)。

4.15 Ling 层(L4)

飞书卡片优先:脉搏卡(每日 09:30,四行以外不许加行)、值得你知道的五件事(恒 5 条,"知道了"= 负反馈学口味)、D 类拍板队列(批准 / 驳回 / 找星星聊,决策自动归档)、周报(15 分钟自动生成,每句可钻)。网页可看同样内容,跨级钻取三跳到底数字全程一致。

4.16 AI 助理 · 嵌入式 pi

目的:员工打开就能用的个人助理,能力靠我们的数据和工具放大。谁用:所有员工。[Ling 定] 跑在我们服务端,账号 Ling 配,员工电脑不装东西。 形态:右栏副驾(不做独立 AI 页签):会话、scoped 问答(对当前客户/酒店/报价)、工具调用(我们的 API 全部作为工具:查证据卡、查囤房、开报价草稿、建任务、发起工单)、工单状态与产物、依据角标。 供给:pi 以 SDK 或 RPC 模式嵌入服务端;供给切换配置(OpenAI 订阅 → GLM 订阅 → API key);后期加"员工本地供给"选项。 边界:不发送、不付款、不删除;写动作走影子→落墨确认;每次调用记 ai_action_log(微信侧有表无写者,工作台自己记)。

4.17 设置

角色与权限映射(权限点固定、映射可配)· 员工账号与微信账号绑定(employee_binding_v1 只读镜像)· 渠道与下单账号(channel_agreement,凭据只存引用)· 汇率与手续费(默认 0.048 + 1.5%,需真源)· SLA 阈值(统一两套数字)· 路由表(任务类型 → DeepSeek 行内 / 嵌入式 pi / AIOS 席位)· 供给切换 · 门铃分级与响铃窗 · 采集节拍默认值 · 授权封套(仅 admin)。

4.18 全局机制

Omnibar ⌘K(回车前先出意图确认条;涉外发/资金/删除二次确认)· 全局搜索(含确认号反查:客户的房是哪个号订的)· 通知中心(红=钱或死线 / 黄=待人工 / 蓝=机会)· Action Feed(倒序人话流水,每条可点进源头)· 审计轨迹(audit_event + row_history + 微信侧 normalize_run_v1)· 空态三句式 · 引擎降级(AI 挂了队列/时间线/要素卡照常)。

05

数据与 API

5.1 两个库怎么摆 [建议]

5.2 API 清单(M0 交付物)

微信侧(沿用):附录 B §B1/§B2 的 18 条;补:视图考古后把 lx_view_b1/b3/s2lx_view_sales_response_v1 的 DDL 写进仓库并进 migration 清单;打开 --require-authpii_access_log 接线。 酒店侧(新建,读):酒店列表/详情/房型/渠道视角;v_price_comparable + 拒绝行 + reject_codeinquiry_evidence_cardv_at_property_taxesv_inventory_remaining / v_deadlinesv_collection_due / v_ingest_errors / v_property_coverage / ingest_batchv_match_queue / v_match_exclusionsv_citable_assertion / 两个冲突视图;v_booking_ledger*v_data_dictionary(驱动自描述表单)。 酒店侧(新建,写,全部经函数或角色):判定生效(apply_*_decision,kb_curator);报价签发(quotation,kb_trade);囤房登记/状态(inventory_*,触发器保证不超卖);订单与结算(booking / settlement);授权封套与工单(capability_envelope / action_intent / effect_receipt);酒店转正与编辑(kb_curator,写 row_history);税则核实、断言录入。 工作台自有:登录与角色;采纳/拒绝/指派/要素/承诺/任务/备注;路由表与供给配置;AI 工单(创建/状态/产物);统一状态端点(三机 + TX + 备份 + 镜像)。 契约风格沿用微信侧 api-contract-policy.md:/v1 版本、Bearer 三档以上 scope、统一错误格式、只加不删。

5.3 已知底座问题(接之前必须处理)

悬空视图 customer_api_safe_v1 / workbench_customer_card_v1lx_view_* 无 DDL;生产 API 无鉴权;SLA 两套数字;飞书同步脚本"全删全建"会抹人工列(四柱设计 1 头号必修);汇率 0.045 无真源;price_observation 分区须每月预建;D5 决策待补 D6。

06

AI 层

07

分工与里程碑(对应页面)

里程碑交付页面
M0我们API 合同(§5.2)+ 假数据服务 + 视图考古 + 鉴权打开
M1Cursor工作台壳 + 4.1 我的一天 + 4.2 主战屏 + 4.3 客户卡微信侧三屏
M2Cursor4.4 报价 Quote Bar + 4.6 酒店库 + 4.8 囤房看板 + 4.7 比价酒店侧四屏
M3我们(并行)酒店侧 API 落地 + 囤房真源入库(飞书变只读投影)+ 修悬空视图 + workbench schema让 M1/M2 有真数据
M4Cursor + 我们4.16 嵌入式 pi + 路由表 + 供给切换AI 助理
M5我们自持工单接口(action_intent/effect_receipt + AI 工单)+ 回复建议引擎 v0(DeepSeek)+ 抢房链接三段式4.9 作战、4.5 行程工单
M6Cursor4.10 采集健康 + 4.11 匹配 + 4.12 知识 + 4.13 财务 + 4.14 管理 + 4.17 设置运营与经营
08

我不知道的(要星星 / Ling 补)

  1. ~~微信发送侧要不要做~~ 已裁(9-14):不做,复制发送由人自己来。
  2. 销售的真实日常流程与分工(谁接哪个账号、班次窗口)——account_shift_window_v1 无 DDL,班次规则在哪。
  3. 客户 tier 四档的判定规则与谁能改。
  4. 行程产品结构、行程单品牌模板、POI 定价怎么合。
  5. 结算与记账规则、汇率牌价真源与更新频率、加价率表。
  6. 员工名单与角色(senior/junior/ops/finance)。
  7. 飞书囤房表在 M3 之后是否继续人工录入(若是,同步方向必须单向:库→飞书)。
  8. 星星 7 月设计里 L2 板块指挥台是否仍要留位。
  9. D5 解除的正式记录(D6)由谁写。
  10. Cursor 仓名(建议 luxing-ops)与前端栈(2 月是 Next.js + AntD;拓拓概念稿要求 token 单源制,栈由星星与 Cursor 定)。

附录索引