构想整理 · 同步星星 · 打包 Cursor

旅行综合系统 v2Ling 口述 · 库库整理 · 2026-09-14

用途 星星汇总后交 Cursor 建造，库库与星星门审 体例 §1、§3 Ling 定的 · §2 我查证的 · §4–6 我的判断 · §7 待裁决
推倒的是 2 月的代码，不是设计基因。这份文件只定方向和边界：前端由 Cursor 建，API 与库由我们自己做，数据和决定都在旅行事业部内部。

一套接微信库、接业务库、API 先行的自有旅行系统。AI 分三层用：复杂运算交 AIOS 席位，简单建议走 DeepSeek Flash，员工个人助理用 pi 套各自的订阅。Cursor 建造，库库与星星把关。

01

Ling 已定的事

彻底重做2 月设计太简单，推倒重来。推倒的是代码；设计基因和两条规则（AI 与人双轨；一个数据库多种维度）是否保留，见 §7 第 1 问
对接两个库微信数据库（normalize.db）+ 业务数据库（luxing_kb），做整体的、我们自己的酒店旅行系统
API 先行留好接口，数据能被程序直接处理；员工用、agent 用同一套
AI 三层 复杂运算 → 我们自己背后的订阅模型，即 AIOS 载体承接的旅行工作流（星星、库库这类席位），系统里不直接调 Claude
简单建议 → 便宜 API，点名 DeepSeek V4.1 Flash，要做优化调优
员工助理 → 嵌入式 pi，跑在我们服务端，任何员工打开就能用；套订阅，账号 Ling 配。接法见 §3
建造与把关Cursor 建造（Ling 的号，月额度即将刷新：Fable 5.1 约 400 美元 + Grok 约 2000 美元）；库库与星星审内容、看走偏、指正
流程星星换完模型 → Ling 讲一遍 → 星星汇总各席提报 → 打包交 Cursor
同日二次补充客户聊天原文允许送 DeepSeek 或其他 agent，不涉及机密
本地模型路线现在不成立：本地只能给客户用 Qwen 27B，能力不够
新开独立仓，重新开始写——这是新的、非常重要的业务
系统暂不调 Anthropic API：复杂行程由网页发起、打成一个包、经类 Comm 接口送到 AIOS 席位，走订阅用顶级模型处理，按格式回传，用户可以等。接 API 成本太高，小利润的生意做不住
过渡期路由逻辑AI 层总原则。现阶段不涉及任何风控。网页里嵌的是快速回复建议，为的是客人不久等。一旦涉及行程规划、复杂报价、复杂行程任务，就按实际情况和 DeepSeek V4.1 的能力成熟度决定哪些东西路由出去、激活路由，交给我们自己的顶级模型（AIOS 席位走订阅）处理。随着在线廉价 API 不断降价、能力提升，以及我们的数据接口、处理规范、harness、采集与 skill 规范不断调优，把活一点一点留给 API。小利润生意用不起昂贵 API；等流程和库都做实、API 再降价，再考虑全面转 API。这是过渡期的理性方案
同日四次补充Cursor 趁额度把之后要做的大量活干掉（工作台前端等），省我们的 token；酒店侧 API 和库由我们自己落地和维护，不交 Cursor
微信侧对接要尽快纳入。库侧提报太窄，要做的是整个工作台的功能设计：网页展现逻辑 + 微信全面纳入。库库把能知道的功能尽可能详细列出来交星星，最终由星星决定怎么弄
现在先不转交星星，她还没升级到新模型
这些数据是旅行事业部自持的事业数据，不经集团协调——集团 AIOS 团队在重构升级、非常不稳定；集团持有的是 AIOS 系统本身，我们是独立事业部门，自己的事自己弄
02

我查证的三件事

2026-09-14

DeepSeek

官方定价页现名 deepseek-flash，版本 DeepSeek-V4.1-Flash，旧名仍认。1M 上下文，OpenAI 格式与 Anthropic 格式两个 base URL 都有。Ling 的选择成立。

每百万 token低谷高峰
输入 · 命中缓存$0.003$0.006
输入 · 未命中$0.15$0.30
输出$0.60$1.20

命中与未命中差 50 倍。调优的重点就是把系统提示做成稳定前缀、把任务拆成短上下文、批量放低谷时段。

pi

订阅登录只支持三家：Anthropic Claude Pro/Max、OpenAI ChatGPT Plus/Pro（Codex）、GitHub Copilot。有 SDK（createAgentSession）、有 RPC 模式（可被别的进程驱动）、可配自定义 OpenAI 兼容端点——DeepSeek 可以直接配进去。pi 自己的文档里没有服务条款提示。本机没装。

微信库

normalize.db 72 张表，已经有一套 API 合同和治理：LX Normalize API（12 条只读路径，Bearer 三档 scope，/v1 版本策略，生产域名已定）；隐私规范 V0.1（5 月已接受：wxid 永不进业务视图、PII 列受限、访问留痕）；治理分工拓拓 arch / 阿麦 生产写 / 星星 业务判决 / 锐锐 on-call。本机 8765 端口此刻没有应答，服务是否在跑 UNKNOWN。

7 月 roadmap 记着一条 P1 债：customer_api_safe_v1 和 workbench_customer_card_v1 两个视图引用了已删的表，一查就炸。新系统接微信库第一天就会撞上，得先修。

03

pi 的接法

Ling 已定 · 9-14 二次口述

pi 嵌入服务端，任何员工打开系统就能直接调用

这些机器架好了本来就只给员工用；账号由 Ling 配齐。员工现在用 Windows，不在他们电脑上装任何东西，不影响正常工作；后期全员换 Mac 之后再谈本地。

嵌入式，不是外挂。用 pi 的 SDK 或 RPC 模式把它装进服务端，把我们系统的 API 交给它当工具——它的能力靠我们的数据和工具放大。

  1. 两种供给方式做成一个可选项：服务端集中供给先做，试运行只做这一种；员工本地供给（自己的订阅额度嵌进系统）后期加
  2. 供给切换是配置，不是改代码：订阅登录（OpenAI Codex）→ 不好用或涉及服务条款就换 GLM 订阅（pi 原生支持智谱 Coding Plan）→ 再不行换 API key，三条路在同一个设置里切
  3. 初期力气全放在功能上，不放在风控上——Ling 原话，作为作业包原则写进去

记录：我原建议 pi 跑在员工电脑、服务端不存 token。Ling 否决，理由是 Windows 跨系统、影响员工工作、试运行麻烦，风险他用换 GLM 或换 API 兜。已按 Ling 定的改。

04

系统形态草图

定方向，不是设计

两个库、一层 API、四种消费者。

真源不合并luxing_kb（酒店 / 价格 / 囤房 / 交易，v3.4 s2 70 表）与 normalize.db（客户 / 会话 / 员工 / 报价）物理上各自为库，用统一实体（客户 global_party_id、订单号、酒店 property_id）在 API 层对齐。合不合并由旅行事业部自己定，不经集团；这轮不合并
API 层微信侧沿用 LX Normalize API 合同，不重写，按需加 endpoint；酒店侧新建一套同风格的 API（同样的版本策略、scope、错误格式）。这是这轮最大的新建件
四种消费者人（网页）、AIOS 席位（复杂任务）、嵌入式 pi（员工助理，服务端）、行内建议（DeepSeek）——走同一套 API，这就是 Ling 2 月的规则「AI 与人双轨」
复杂任务怎么交给 AIOSLing 已定形态。网页发起 → 打成一个包（工单，v3.4 的 action_intent 已有）→ 经我们自己系统里的工单接口送到 AIOS 席位（自持，不依赖集团 AIOS Comm——集团在重构、不稳定，我上一条给星星的 Comm 通知至今没有送达回执）→ 席位走订阅用顶级模型处理 → 按约定格式回传（effect_receipt + 产物）。异步，用户可以等；网页上看得见谁在做、做到哪。系统不调 Anthropic API，理由是成本
路由是一张可调的表不是写死的代码。每类任务（回复建议 / 报价组装 / 行程规划 / …）在表里指向一条路：DeepSeek 行内、嵌入式 pi、AIOS 席位。改路由改表不改码。每次路由记下走了哪条路、结果有没有被采纳，Ling 据此把分界线一点点往 API 挪
数据出口Ling 已裁。客户聊天原文可以送 DeepSeek 或其他 agent。身份标识（wxid 等）沿用微信侧现有做法，本来就不进业务视图，不用新造门。微信侧隐私规范 V0.1 把 message_content 列为 PII，要按这条裁决同步改一行，走星星那边
05

给 Cursor 的作业包必须带的六样

铁律文件写进 .cursor/rules：绝不连生产库；凭据只存引用；luxing-kb 里 snipe_* / knt_* / nta_* 冻结基线不碰；微信 plain 目录不读；删除用 trash；活库不裸 copy
真源合同只读输入：luxing-kb schema/ddl.sql；normalize 的 schema-doc、openapi.yaml、privacy_spec_v01、api-contract-policy。库表变更由我们自己做：库库出迁移、星星裁、Ling 拍板，不经集团。Cursor 不改表、不写 API
开发环境从 ddl 建一个空 PG + 脱敏样本。Cursor 永远拿不到 luxing_kb 与 normalize.db 的凭据
里程碑与分工库库建议，待 Ling 点头
M0我们 · API 合同先行：微信侧现有 12 条 + 酒店侧新建清单写成一份 OpenAPI，配假数据服务。Cursor 开工的前置，也是我们长期维护的东西 M1Cursor · 工作台壳 + 微信侧三屏：销售队列 / 客户卡 / 会话与回复建议——员工每天用的先上 M2Cursor · 报价 Quote Bar + 酒店库 + 囤房看板 M3我们（与 M1–M2 并行）· 酒店侧 API 落地 + 囤房真源入库 + 修微信侧两个悬空视图 M4Cursor + 我们 · 嵌入式 pi 助理 + 路由表 + DeepSeek 快速回复建议 M5我们 · 自持工单接口 → AIOS 席位（复杂行程、复杂报价） M6Cursor · 财务 / 管理面板 / 设置
每个里程碑有书面验收；验收由库库 / 星星做，不由 Cursor 自证
评审门Cursor 只在分支上工作，一个里程碑一个 PR。库库审库侧（合同遵守、迁移、provenance、凭据、幂等）；星星审业务侧（微信库对接是否走隐私规范与 API、业务流程对不对、优先级）。走偏的判据先写好：新发明表或字段不走迁移；直连真库；把订阅 token 放到服务端；PII 出模型层不带分级门
仓库Ling 已定：新开独立仓，重新开始写；luxing-kb 与 normalize 只作只读依赖。仓名待定，我建议 luxing-ops（api + web 一个仓）
06

已有资产，重做也要继承

07

我的建议

待 Ling 点头
  1. 2 月两条规则都保留，升格为 v2 第一性原则。①AI 与人双轨——人和 AI 走同一套 API 操作同一批对象，这是 pi 嵌入、工单、路由表全部成立的前提；②一个数据库多种维度——两库一 API、按角色出视图，这是「工作台」和「多套系统」的分界线
  2. 里程碑按上面第 4 项的新顺序。我们先出 API 合同和假数据，Cursor 拿合同直接做整个工作台前端，微信侧三屏第一批；API 和库我们自己落地，与 Cursor 并行

已裁（同日）：pi 嵌入服务端；聊天原文可送模型；新开独立仓；系统不调 Anthropic API；数据事业部自持不经集团；API 与库我们自己维护；星星升级前不转交；微信复制发送由人自己做，系统不做发送侧。

已裁（9-14 晚，见设计 v0.3 交星星版第 0 节）：囤房、免取消、死线由后台推送给 owner；要有世界层（酒店库、日历、地图、换个角度、库存与机会，权限按人开），不让人的判断受限于 AI 的联想；保留价值镜；要有全局意识；复盘实时不在收工；库存先合适再排第一并融入报价，高溢价临期要提醒；库库只负责酒店价格线，微信线由微信数据平台同事负责；星星已准备好，本轮完成即交接。

08

下一步

库库正在做《工作台功能总设计》：把星星 7 月设计、Ling 2 月前端文档、微信库全部实体与接口、酒店库视图与工具一次读全，按页面列功能、数据来源、动作、AI 参与点，尽可能详细；压在文件里，星星升级完再转交。之后：Ling 拿这份和总设计讲一遍 → 星星决定怎么弄、汇总成 Cursor 作业包 → 库库出 M0 的 API 合同与假数据 → Cursor 开工 → 每个 PR 库库 / 星星门审。