技术知识库 · 工具评测 · · 国科智飞 Gavin

SalesClaw：医药销售的语义层与 NL2SQL 实践

为医药销售建业务本体：138 张表、SQL 模板复用与三层归因推理，先让 AI 理解业务关系，再谈问答。

很多企业 AI 项目的第一反应是做个聊天框，接上大模型，再想办法让它回答业务问题。SalesClaw 的顺序反过来：先把「医生—医院—代表—产品—处方—费用」这些业务对象和关系定义清楚，做成语义层，再让模型在结构上做查询和解释。它不是一个成熟产品，但把这件事讲清楚，比大多数「AI 落地」方案更像样。

它是什么

SalesClaw（仓库 gptplusplus/salesclaw，TypeScript）是一套面向医药销售的业务本体与归因推理语义层。GitHub 仓库是演示形态：FastAPI 后端 + React/TypeScript 前端 + Tauri 桌面打包；同时以 ClawHub 技能的方式分发，核心是一个 MySQL 业务本体库，约 138 张表。代码分三层：知识层（entities、concepts、sql_templates）、推理层（structure → behavior → decision 的三层归因）、工具层（ask.py、inference.py、knowledge.py、db.py、init_mysql.py）。

能力与亮点

业务对象建模是真正的起点。 医药销售链条复杂：医院有层级，医生有科室和处方习惯，代表有辖区和指标，产品有适应症和竞品，费用有合规约束。SalesClaw 把这些定义成实体和关系，让「处方趋势」「进院情况」这类问题变成对已知结构的查询，而不是让模型凭空理解自然语言。

NL2SQL 配 SQL 模板复用。 高频问题沉淀成 sql_templates，自然语言提问先匹配模板，匹配不上再生成 SQL。这个设计很务实：企业里大量取数需求是重复的，模板保证答案稳定、口径一致；纯生成式 SQL 每次结果可能不一样，落到经营分析场景就是灾难。

三层归因比「给个数」有用。 structure → behavior → decision：先看业务结构（区域、产品、医院分级），再看行为（处方量、拜访频次、费用投入），最后给决策建议。BI 工具通常停在第一层，这里把「为什么」和「怎么办」也纳入了推理路径。

分析场景覆盖了医药销售的日常动作。 处方趋势、费用红黄灯、代表绩效、目标达成、进院情况——这些是药企经营会的常客。把它们做成预置问题，比一个通用问答框更接近真实使用场景。

诊断会话与结论沉淀。 推理步骤和结论被保留下来，可以回看当时的判断依据。对强合规行业，过程可追溯往往比答案本身更重要。

分发方式值得注意。 它更像行业语义插件而非独立 SaaS——价值沉淀在行业知识结构里，不在仓库代码量里。这种形态对垂直领域 AI 产品是个方向。

医药销售为什么特别需要语义层。 这个行业的分析问题几乎都带条件：某产品在三级医院的处方量、某代表辖区内的费用合规情况、某适应症新患者与竞品的份额变化。条件背后是实体关系——医院分级、科室归属、代表辖区、产品适应症、费用类型。这些关系不定义清楚，模型再强也只能猜。SalesClaw 把关系落到 138 张表里，本质上是先把「问什么」标准化，再让 AI 回答。这个顺序对任何数据密集行业都成立。

局限与坑

项目非常早期。 收录时约 22 star、9 fork、1 个 open issue，GitHub API 未识别到 License，也没有发布 release。仓库里仍在提交实施报告类文档，更像方案与需求记录，不是可交付产品。在 License 明确之前，不建议任何形式的商用部署或二次分发。

没有社区验证。 138 张表的业务本体是否贴合真实药企业务、归因逻辑是否经得起业务方质疑，都没有外部案例支撑。医药销售有强合规约束，数据模型和费用分析尤其敏感，缺少行业专家评审的本体很容易「看起来对、用起来错」。

NL2SQL 的稳定性依赖模板覆盖。 高频问题走模板没问题，模板未覆盖的长尾问题依然回到模型生成，SQL 正确率和口径一致性需要自己兜底；模型选型、Schema 描述质量都会直接影响效果。

演示形态与生产形态差距大。 Tauri 打包 + FastAPI + MySQL 只是骨架，真实落地要接客户的数据仓库、权限体系、合规审计，这些仓库里都没有。

本体是重资产。 138 张表意味着不低的建模与维护成本：业务口径变了、组织调整了、产品线增减了，schema 和 SQL 模板都要跟着改。没有专人维护，本体很快会与业务脱节——这是所有语义层项目的共同风险，不只是这个项目的问题，立项前要先算清这笔持续投入。

分发依赖特定生态。 以 ClawHub 技能方式分发，使用前提是接受对应的 Agent 生态；如果团队不在这个生态里，仓库演示代码的参考价值大于直接可用性。

适用场景

选型建议

把 SalesClaw 当方法论样本，不要当代码资产。值得抄的是它的顺序：业务对象 → 指标体系 → 高频问题 → SQL 模板 → 归因引擎。任何行业落地都可以套这个框架——先把业务讲清楚，再决定用不用模型。如果你的项目正卡在「接了模型但答案不可信」，通常缺的不是更强的模型，而是这一层结构。反过来，如果行业关系复杂度低、问题高度重复，直接做几张固定报表可能比语义层更划算，不必为了「AI」而 AI。真要基于它启动项目，先联系作者确认 License 和维护意向，再把本体设计拿给业务方评审，最后才谈工程实现。