从实践变成产品

经销商的一切都靠电子表格和人的记忆来管理

销售线索从多个渠道涌入（Facebook · 直接私信）· 车辆库存靠人工核对 · 跟进半途中断 · 各分店信息互不相通 · 也无法衡量哪条广告真正带来了成交客户

先写“不可违反的规则”，再写功能

Faberic OS 建立在不变规则（invariant）之上——不是指导原则，而是架构层面的硬性约束：

• LLM = Observe, Code = Decide — AI 记录信号和事实 · 销售线索评分和业务规则则交给可测试的代码
• Append-only ledgers（只追加账本） — 关键事件（信号 · 漏斗 · 使用 · 审计）只能追加，不能删除或修改——企业的历史必须始终真实
• 在基础设施层实现租户隔离 — 每个经销商的数据由数据库层的 Row-Level Security 强制隔离，而不是靠开发人员的小心谨慎
• 按租户计量成本 — 每次 AI 调用都按实际成本计量——经销商看到的 ROI 是数字，而不是感觉

Architecture is policy——靠结构强制执行的规则，永远不会像靠人记忆的规则那样被遗忘

从客户发来消息到成交的完整闭环

整条流程端到端运转：Inbox（接收 Facebook 消息 + agent 用经销商的真实数据回复，可由人工接管）→ Leads（提取信息 · 评分 · 跟踪状态）→ Funnel（把广告与预约关联）→ Outcomes（闭环验证什么真正有效）

每个经销商的 agent 都能通过限定范围的工具真实查询库存、预约时间 · 经销商的知识库以确定性方式渲染，借助 prompt cache 使每次对话的 AI 成本显著下降

自 2026 年 6 月起与首个设计合作伙伴上线运行

系统已与首个 EV 经销商设计合作伙伴实际运行——inbox 接收真实消息 · agent 真实预约 · 漏斗端到端运转 · 所有 ledger 均不可篡改。Company Brain 层（案例 02）也运行在同一基础之上

咨询可以变成产品——前提是框架足够扎实

我们用来诊断客户的 The Operating Depth Model™ 没有停留在幻灯片上——它成了每天运行的软件的结构。这正是“提建议”的顾问与真正动手构建的架构师之间的区别：好的框架必须经得起生产环境的检验