eaiadminandClaude Code
593323a934
一次性提交当天全部改动（110 个文件）。 **未按 TOP_CODING_RULES.md G14.5「一次提交只装一件事」拆分** —— 用户明确要求 单一提交，此处如实记录，不静默忽略该冲突。 提交前验证：后端 go build / go vet / go test ./... 全绿，前端 npm run build exit 0，/api/health 与管理员 login 均返回 200。 - 专员目录收敛为 6 个：下线 knowledge-operations / process-coordination / presentation-briefing / report-generation 四个专员（前后端 manifest 与 seed 同步删除），新增 general-assistant。专员的归属关系（拥有哪些技能定义、 哪些目录项、提示词与绑定从哪来）改由 specialists/core 的 ownership.go、 prompt_provider.go、binding_provider.go 统一提供，seed 与 admin_handlers 随之内置化，卸载路径统一走 uninstall.go。 - 技能：补齐 text-to-speech 的前端 manifest（后端包在 HEAD 已存在）， skillcore/ownership.go 提供与专员对称的归属查询。 - AI 路由：ai_config.json 由 OpenRouter/Ollama 切到 LMUAI / SiliconFlow / llama.cpp 本地路由，ai_secrets.example.json 与部署 env 样例同步新增 SILICONFLOW_API_KEY。 - 系统管理页重整：新增 AiAdminPage、OrganizationManagementPage，删除 AdminOverviewPage、CompanyConfigPage，SystemConfigPage 精简，nav / router / config/workbench.js 同步调整。依 G05.5，开发阶段直接收口到新结构，不留旧路由。 - 新增 internal/objectrefs：统一统计对象（专员 / 技能 / xapp）的运行时引用 （被多少 xapp、项目、任务引用），供管理页做删除前的影响面判断。 - 公众号创作专员：新增 OfficialAccountSpecialistPanel，workflow 与投递链路调整。 - XApp：考试 / 培训 Shell 扩展，XAppDirectoryPage 与 xappDefinition 同步。 - 文档：新增 GW01–GW05 工作台演进系列与 AR12 对话驱动与结构化交互架构； 同步 AR05 / SY17 / SY23 / SY25 / PL04；TOP_CODING_RULES.md 增补 G05.5。 Co-Authored-By: Claude Code <noreply@anthropic.com>
10 KiB
SY25 — 业务逻辑拆分与数字员工提取方法
版本：V1.0 | 最后更新：2026-09-19
1. 文档目的
本文用于回答两个核心问题：
- 业务逻辑应该如何拆分
- 数字员工应该如何从业务中被提取出来
本文提供 专家 / App / skill 的统一提取方法。
其目标是避免继续出现以下问题：
- 把动作误写成专家
- 把结果物误写成专家
- 把长流程环节误写成专家
- 先造对象名，再反推业务价值
本文与 docs/05_Object_Catalog/ 配合使用；如需查看更早期的产品阶段规划，可参考 History_And_Retrospectives/系统演进旧稿/SY19_通用数字员工产品规划.md：
SY25负责对象提取方法docs/05_Object_Catalog负责具体对象定义
2. 总原则
业务与对象设计统一遵守一句话：
先拆业务，不先造人；先找真实岗位，再提取数字员工。
进一步展开，有 5 条硬规则：
- 经营环节构成业务骨架
- 真实岗位是数字员工的直接来源
- xapp 承接长流程，skill 承接单点动作
- 结果物、动作、流程节点，不直接定义为专员
- 只有可数字化输入、可在线闭环的岗位部分，才适合提取为数字员工
3. 业务逻辑拆分的一级骨架
业务逻辑应先按企业经营主链拆分，再映射到页面菜单、系统模块或功能点。
当前建议统一采用从需求发现到售后服务的五大经营环节作为一级骨架：
| 环节 | 定义 | 关键结果 |
|---|---|---|
| 需求发现 | 找到潜在客户、识别机会、形成有效线索 | 有价值线索 |
| 需求确认 | 澄清客户场景、目标、约束和预算 | 清晰需求 |
| 方案与交易 | 形成解决方案、完成报价与合同、推动签约 | 可签约方案与交易条件 |
| 交付与上线 | 组织实施、培训、上线、验证可用 | 可运行、可使用 |
| 售后服务与持续经营 | 保障客户持续使用、续约、增购、反馈闭环 | 留存、续约、增长 |
这五段用于为业务搭骨架，并为后续岗位识别与对象提取提供顺序。
4. 正确的对象提取顺序
对象提取必须按以下顺序进行：
经营环节 -> 结果 -> 主责岗位 -> 对象类型 -> 具体对象
不允许倒过来，从功能点或动作列表直接拼对象名。
4.1 第一步：先画业务主链
先把业务写成完整经营链，而不是碎片化任务表。
例如销售型业务，可以先写成：
需求发现 -> 需求确认 -> 方案与交易 -> 交付与上线 -> 售后服务与持续经营
4.2 第二步：明确每段的主结果
每个经营环节都必须先回答：
这一段最后交付什么结果？
例如：
- 需求发现：有效线索
- 需求确认：清晰需求
- 方案与交易：可签约方案与合同条件
- 交付与上线：可运行可使用
- 售后服务与持续经营：续约、增购、健康客户
4.3 第三步：寻找真实主责岗位
每段都继续追问：
现实企业里，通常是谁对这个结果负责？
这一问的目的，是阻止系统继续从动作中发明假岗位。
4.4 第四步：判断该落成什么对象
找到主责后，继续判断最合适的对象类型：
- 稳定岗位责任 ->
专员 - 长流程协作空间 ->
xapp - 原子动作能力 ->
skill
4.5 第五步：最后才命名对象
命名必须服从前面四步，不允许先有名字，再找理由。
4A. 数字员工的物理边界
上面的“真实岗位”判断，还不够。
数字员工以现实员工为参考对象，同时遵守明确的物理边界。
4A.1 数字员工只能处理数字化输入
数字员工原则上只能基于以下输入工作：
- 已录入系统的数据
- 文档、表格、邮件、聊天记录、会议纪要
- 表单、工单、知识库、CRM、ERP 等结构化或半结构化信息
- 明确授权的线上连接器数据
数字员工不能默认具备以下能力：
- 实地拜访客户
- 线下面谈获取信息
- 打电话主动询问信息
- 在未接入的现实场景中自行观察和取证
- 通过人情关系、现场氛围、口头暗示完成判断
因此，一个岗位即使在企业中真实存在，如果它的核心价值高度依赖线下触达、电话沟通或现场判断，也不能直接等价提取为完整数字员工。
4A.2 先判断“岗位是否真实”，再判断“岗位是否可数字化”
专员提取必须通过两层门槛：
- 现实世界中是否有这个岗位
- 这个岗位中是否有足够多的职责，可以只依赖数字化输入在线完成
两层都满足，才适合立专员。
如果第一层满足、第二层不满足，就不应强行做成完整专员，而应降级为：
- 面向人工岗位的数字副手
- 某个流程中的工作台
xapp - 若干在线能力
skill
4A.3 数字员工擅长持续处理数字信息
数字员工更适合承接以下类型的工作：
- 信息整理
- 规则判断
- 多源信息汇总
- 状态跟踪
- 文档生成
- 风险识别
- 节点提醒
- 在线协同推进
以下工作更适合作为人工主责环节：
- 现场关系建立
- 电话破冰
- 线下陌生拜访
- 当面谈判中的临场博弈
- 现场交付中的物理操作
5. 专员、xapp、skill 的底层分工
5.1 专员：承接岗位责任
专员回答的问题是：
谁对这一段业务结果负责？
专员的本质是对某段业务结果持续负责。
因此，专员应当来自现实企业里稳定存在的岗位，例如：
- 销售专员
- 售前解决方案专员
- 商务合同专员
- 客户成功专员
5.2 xapp：承接长流程工作空间
xapp 回答的问题是：
这段业务如何被组织、推进、留痕、协作和交付？
它的重点是流程承载与协作组织。
因此，凡是“交付系统”“项目空间”“长流程工作台”这一类对象，优先落到 xapp。
5.3 skill：承接单点动作能力
skill 回答的问题是：
具体做什么动作？
例如：
- 纪要整理
- 客户画像生成
- 方案草稿生成
- 合同条款比对
- 续约风险识别
skill 是能力片段，不是岗位。
6. 一个对象能不能成为专员
一个对象要成为专员，至少要同时满足以下 6 条：
- 现实企业里存在对应真实岗位
- 这个岗位中有足够多的职责，可以只依赖数字化输入在线完成
- 这个岗位有稳定主责，而不是临时动作集合
- 它处理的是持续状态，而不是一次性任务
- 它有清晰输入、输出和判断逻辑
- 它值得长期作为独立协作对象存在
如果不满足，就不要立专员。
应分流为：
- 流程承载 ->
xapp - 单点动作 ->
skill - 结果物 -> 交付物，而不是对象
7. 三类最常见误判
7.1 把结果物当专员
错误示例：
售前方案专员
问题：
- “方案”是产物，不是岗位
正确做法：
- 回到真实岗位
售前解决方案专员
7.2 把动作当专员
错误示例：
客户跟进专员简历筛选与招聘专员
问题：
- “跟进”“筛选”都是动作，不是稳定岗位
正确做法：
- 找到这些动作背后的真实岗位，再决定是否立专员
7.3 把长流程环节当专员
错误示例：
培训交付专员
问题：
- “交付”是长流程环节
- 如果交付已经由
xapp承担，就不应再设同名专员
正确做法：
- 交付归
xapp - 专员只保留真实岗位责任
7.4 忽略数字员工的物理限制
错误示例：
- 让数字员工默认承担实地拜访
- 让数字员工通过打电话主动获取一手信息
- 把强依赖现场判断的岗位直接照搬成专员
问题：
- 这些职责不以数字化输入为前提
- 它们高度依赖现实世界接触，而不是在线数据闭环
正确做法：
- 只提取该岗位中可数字化、可在线闭环的职责部分
- 其余部分保留给真人岗位或线下流程
- 必要时把对象降为数字副手、
xapp或skill
8. 销售链路示例
以销售流程为例，按本文方法拆分后，可得到如下结果：
| 经营环节 | 主责岗位 | 建议对象 |
|---|---|---|
| 需求发现 | 销售代表 / 客户经理 / 销售顾问 | 销售专员 |
| 需求确认 | 销售 + 售前顾问 | 销售专员 + 售前解决方案专员 |
| 方案与交易 | 售前顾问 + 商务 / 合同岗位 | 售前解决方案专员 + 商务合同专员 |
| 交付与上线 | 项目 / 实施 / 交付体系 | xapp 为主，不急于立专员 |
| 售后服务与持续经营 | 客户成功 / 客户运营 | 客户成功专员 |
因此，销售型业务当前最稳的数字员工骨架是：
- 销售专员
- 售前解决方案专员
- 商务合同专员
- 客户成功专员
但需要注意：
销售专员并不等于替代真人销售去打陌生电话或跑线下拜访- 它更适合处理 CRM 线索整理、在线跟进记录、客户资料分析、推进提醒、商机判断等数字化环节
- 凡是必须依靠电话、现场、当面关系推进才能完成的部分，都不应直接算进数字员工的能力边界
而以下名字不建议继续使用：
售前方案专员客户跟进专员培训交付专员
9. 设计检查清单
后续每次新增专员前，都先过这一张清单：
- 这是经营环节、岗位、动作、还是结果物？
- 现实企业里有没有这个岗位？
- 这个岗位中，有多少职责能只依赖数字化输入在线完成？
- 它负责的是一段稳定结果，还是几个零散动作？
- 这件事更应该由专员、xapp 还是 skill 承接？
- 如果删掉这个对象，业务语义会不会更清楚？
只要前 3 问答不稳，就不要立专员。
10. 最终结论
业务逻辑拆分与数字员工提取，应统一服从以下底层逻辑：
- 经营环节是体系骨架
- 真实岗位是数字员工来源
- 数字化输入边界决定哪些岗位职责可以被提取
- 专员管责任
- xapp 管流程
- skill 管动作
- 结果物、动作、流程节点，不直接定义为专员
一句话收口：
拆业务，先看价值链；提专员，先看真实岗位，再看是否可数字化。