岗位与 AI成员实例
下一代 AI 销售系统不应该只是一段长 Prompt，也不应该让业务人员在资产包、模板、Agent、版本之间反复判断谁才是事实源。
当前系统的主路径已经收敛为：
岗位 -> 创建 AI成员 -> 绑定接待账号上线
一、为什么要用岗位
业务经验如果只写在 Prompt 里，很快会失控：
- 价格、产品、流程变了，不知道该改哪一段。
- 多个业务复制同一段 Prompt，最后版本不可控。
- 回复错了，很难判断是意图识别、字段抽取、话术候选还是知识依据出了问题。
- 销售主管、运营、实施和技术很难在同一个长文本里协作。
所以系统把业务拆成可维护的资产：
- 客户说这句话可能是什么意图。
- 需要收集哪些字段。
- 哪些事件会触发 SOP。
- 哪些 SOP 或意图会推荐哪些话术。
- 这个业务默认的客户旅程是什么。
- 从这个业务方案创建 AI成员时，默认角色和运行策略是什么。
这些共同组成岗位。
二、岗位维护什么
岗位维护两类内容。
第一类是每轮运行都会读取的基础资产：
- 意图、字段、事件和能力的业务定义。
- SOP / Playbook。
- 命中意图、字段、SOP 后的候选话术关系。
- 话术包边界。
- 状态跳转策略。
- 运行投影和质量校验。
第二类是创建 AI成员时使用的默认配置：
- 默认名称、描述和模式。
- 角色定义。
- 客户旅程阶段。
- 每个阶段的必收字段。
- 必收字段缺失时对应的跟进 SOP。
- 默认资源要求。
- 默认运行策略。
- 默认启用的话术包建议。
也就是说，岗位既是“业务资产池”，也是“新建 AI成员时的默认方案”。
三、AI成员实例维护什么
AI成员是一个具体线上现场。
创建后，它会从岗位复制默认客户旅程、角色定义、必收字段和运行策略，然后由业务人员在当前 AI成员里继续调整：
- 当前 AI成员的角色定义。
- 当前 AI成员的客户旅程和必收字段。
- 当前 AI成员的缺槽跟进 SOP。
- 绑定哪些知识库、精准问答和外部工具。
- 是否自动发送、是否需要审批、模型策略是什么。
- 是否有只影响当前 AI成员的覆盖话术。
但它不会复制岗位里的大字段。运行时仍然通过岗位 key 读取最新生效的意图、字段、事件、SOP 和候选关系。
四、改完哪里会生效
业务人员可以按这条规则判断：
改业务判断、候选关系、SOP：改岗位。
改具体话术：改话术包。
改当前 AI成员的角色、旅程、资源和运行策略：改 AI成员实例。
资产包保存生效后，绑定这个资产包的 AI成员后续运行会自动读取最新内容。
如果只改了默认客户旅程或默认运行配置，它只影响以后新建的 AI成员；已有 AI成员不会被自动覆盖，除非显式应用默认配置。
五、运行时如何使用
每一轮对话，运行态会合成两部分信息：
AI成员实例：
角色定义、当前客户旅程、必收字段、缺槽 SOP、资源绑定和运行策略。
岗位：
意图、字段、事件、SOP、候选话术关系、状态跳转策略和运行投影。
模型在这些边界内做语义判断，规则负责强信号、候选召回、安全门禁和可观测 fallback。
这让系统既能利用 LLM 的判断能力，也不会把行业规则写死在代码里。
六、最小工作流
- 在岗位里沉淀业务方案。
- 从岗位创建 AI成员。
- 在 AI成员里绑定知识库、工具、渠道和运行策略。
- 绑定接待账号上线。
- 用真实或模拟会话验证。
- 后续业务小改优先回到岗位或话术包。
这就是当前系统的核心产品模型：岗位让经验可复用，AI成员实例让现场可落地，运行态按当前资产和实例配置持续决策。