企业 AI 升级不是一次工具上线，而是把一个有效结果逐步变成可重复、可治理、由组织持续运营的能力。Fellow 作为现有 ERP、OA、CRM 和数据平台之上的操作层，不要求先迁移业务主数据或替换核心系统。
了解定位与业务价值：AI Transformation
先定义要改变的业务结果
不要从“部署多少模型”或“创建多少 Agent”开始。为第一个流程定义当前基线、目标结果和验收人。
| 衡量对象 | 可记录的指标 |
|---|---|
| 周期 | 从任务进入到正式成果交付的时间 |
| 吞吐 | 同一团队每周可完成的任务量 |
| 等待 | 跨系统查询、人工转交和排队时间 |
| 返工 | 因信息遗漏、格式错误或口径不一致造成的修改 |
| 质量 | 引用完整度、规则符合率、人工可直接采用率 |
模型调用量和 Token 成本属于运行指标，不能替代业务结果。
选择第一个流程
优先选择同时满足以下条件的流程：
- 高频发生，当前人工成本和等待可测量；
- 输入与正式交付物边界清晰；
- 有明确的业务负责人和验收人；
- 初期可以使用样例数据或只读数据源；
- 成功后可以复用到相邻团队或流程。
暂缓核心交易写操作、无人负责验收、规则仍在频繁变化，或只能用主观感受判断质量的场景。
四阶段实施路径
1. 本机验证
使用 Desktop 和真实但非敏感的样例完成端到端任务。验证重点是成果，而不是对话体验：
- 是否得到约定格式的报告、清单、代码或业务材料；
- 是否能追溯来源、工具调用和关键步骤；
- 人工需要修改什么，失败后如何恢复；
- 与当前人工基线相比，周期和返工是否改善。
2. 受控试点
通过 Connectors 或 MCP 接入 1–2 个只读系统。固定权限、模型、Skill、测试样例和验收标准，让多名用户重复运行同一流程。
试点结束时应能回答：谁可以运行、可读取什么、结果保存在哪里、失败由谁处理、每次运行成本多少。
3. 生产准备
根据数据驻留、网络和运营责任选择 Cloud SaaS 或私有化部署，并建立：
- AI Gateway 的运行与访问边界；
- Console 的组织、模型、接入应用和用量管理；
- 安全与合规 中的最小权限、确认和审计要求；
- 发布、回滚、故障处理和业务连续性责任。
只有在只读闭环稳定后，才为必要操作开放受控写回。
4. 固化与扩展
把稳定方法沉淀为可复用 Skills；需要专用界面、长期状态或独立生命周期时，再固化为 Applications。
扩展顺序建议为：同一流程增加用户 → 同一数据边界增加相邻场景 → 增加新的系统连接 → 扩大写权限。每次只改变一个主要边界，保留前一阶段的回归样例。
规模化之前的治理检查
| 边界 | 必须明确 |
|---|---|
| 业务 | 流程负责人、验收标准、人工兜底和停止条件 |
| 数据 | 来源、用途、保留位置、敏感级别和删除策略 |
| 权限 | 用户、应用、工具与系统的最小 Scope |
| 模型 | 允许的提供商、凭证归属、质量与成本阈值 |
| 运行 | 监控、审计、故障响应、升级和回滚责任 |
| 价值 | 基线、试点结果、持续复盘频率和扩展门槛 |
何时进入下一阶段
只有当前阶段的结果可重复、边界可解释、负责人明确时再扩大范围。出现以下情况应暂停扩展：
- 交付质量依赖某个操作者临场修正；
- 权限范围无法用业务需要解释；
- 无法从运行记录定位失败路径；
- 成本增加但业务周期、吞吐或质量没有改善；
- 业务团队尚未接手日常验收和运营。