YingClaw 初次部署检查清单：避免 90% 的人会犯的错
营域智能在和 200+ 企业合作 YingClaw 部署时，发现一个扎心的数据：
第一次部署就"完全顺利"的客户不到 10%。剩下 90% 都踩过至少 3 个坑。
这些坑不是技术问题，是"准备不足"。多数企业低估了"上线前准备"的工作量，把 80% 时间花在选模型、写提示词上，忽略了业务梳理、权限设计、测试验证这些"脏活"。
今天这篇把 200+ 客户的踩坑经验汇总成6 大阶段 50+ 检查项。照着这个清单走，第一次部署的坑能少踩 80%。
90% 的人会犯的 5 个典型错
在讲清单前，先看 5 个真实翻车案例——你可能正要走同样的路。
错例 1：上来就写提示词，业务没梳理
某制造业客户工程师第一天就开始写"售后客服"提示词。写到一半发现：
- 不知道售后有哪些场景（退货、换货、维修、投诉、咨询...）
- 不知道每个场景的处理规则
- 不知道哪些场景必须转人工
结果：重写 3 版，返工 2 周。
错例 2：选了"大而全"数字员工
某零售客户第一个数字员工叫"客服小全能"，要求"什么客户问题都能答"。
结果：准确率 55%，啥都不精。最后拆成 4 个小数字员工（售前、售后、投诉、VIP），准确率升到 92%。
错例 3：没做权限隔离
某金融客户把所有数字员工配了"全公司数据访问权"。
结果：合规审计时被打回。重新设计权限矩阵，又花了 3 周。
错例 4：没准备测试用例就上线
某教育客户认为"提示词写好就能跑"，没准备测试用例。
结果：上线 1 周后用户反馈"AI 答非所问"，紧急回滚。花了 2 周补测试用例。
错例 5：忽视 Token 成本监控
某电商客户没设置成本预警，数字员工自动调用 API 时未做并发限制。
结果：单日跑了 50 万次调用，Token 费用超预算 3 倍。
这 5 个错，90% 的第一次部署都会遇到。 接下来讲怎么避开。
阶段 1：部署前 3 个关键准备
准备 1：环境准备
| 检查项 | 必填 | 状态 |
|---|---|---|
| 服务器（CPU/GPU/内存）配置评估 | ✅ | ☐ |
| 操作系统版本（推荐 Linux Ubuntu 22.04+） | ✅ | ☐ |
| 网络环境（公网访问 / 内网部署） | ✅ | ☐ |
| 数据库（PostgreSQL 14+） | ✅ | ☐ |
| 存储空间（模型 + 数据 ≥ 200GB） | ✅ | ☐ |
| API Key / 第三方服务授权 | ✅ | ☐ |
| 域名 + SSL 证书 | 推荐 | ☐ |
| 备份机制（自动 + 异地） | 推荐 | ☐ |
常见坑：
- 用 Windows Server 部署——支持但有性能损耗，推荐 Linux
- GPU 配置不足——大模型推理慢，影响体验
- 没规划备份——故障后数据丢失，恢复成本极高
YingClaw 提供 3 种部署方式：
- 本地部署：完全自控，适合金融/医疗/政企
- 私有云部署：阿里云/腾讯云专有版，平衡安全和成本
- SaaS 试用：营域智能官方托管，5 分钟开箱即用（试用推荐）
准备 2：团队准备
| 角色 | 必填 | 数量 | 职责 |
|---|---|---|---|
| 项目负责人 | ✅ | 1 | 整体推进、资源协调 |
| 业务专家 | ✅ | 1-2 | 业务场景梳理、SOP 输出 |
| 数字员工训练师 | ✅ | 1 | 提示词编写、调优 |
| IT 运维 | 推荐 | 1 | 环境部署、权限配置 |
| 数据标注员 | 可选 | 0.5 | 测试用例准备、效果评估 |
关键建议：
- 业务专家不能省——AI 不会懂你的业务，需要业务专家翻译
- 训练师最好内部培养——懂业务比懂技术更重要
- 不要"工程师兼职业务"——视角不同，提示词质量差 30%
准备 3：预算准备
| 项目 | 预算范围（年度） | 备注 |
|---|---|---|
| 软件许可 | 5-20 万 | 按规模/部署方式 |
| 硬件 | 2-8 万 | 一次性，摊到 3 年 |
| 实施服务 | 3-10 万 | 一次性 |
| 运维人力 | 5-15 万 | 按 0.5-1 FTE |
| Token 消耗 | 0.5-3 万 | 按使用量 |
| 培训 | 0.5-1 万 | 一次性 |
| 小计 | 15-50 万 | 中型企业基线 |
常见坑：
- 只算软件许可，忘了运维（实际 50% 成本在运维）
- 一次性预算，没留迭代经费（提示词要调，3-6 月后才知道需要多少）
- 没算培训——员工不会用，数字员工再强也白搭
阶段 2：业务场景梳理清单
80% 的部署失败源于"业务没梳理清楚"。这个阶段不能跳。
必填项 1：场景清单
列清楚要自动化的所有业务场景：
# 业务场景清单
1. 场景 A：售后客服咨询
- 触发：客户消息
- 输入：客户问题文本
- 输出：答复 / 转人工
- 频次：500 次/日
- 优先级：高
2. 场景 B：订单查询
...
要求：每个场景必须明确 4 项（触发/输入/输出/频次）。
必填项 2：SOP 文档
每个场景必须有一份 SOP 文档：
# 售后客服 SOP
1. 收到客户消息
2. 判断问题类型（退货/换货/维修/投诉/咨询）
3. 根据类型走不同流程
- 退货：核实订单 → 确认退货原因 → 引导申请
- 换货：核实订单 → 确认换货原因 → 检查库存 → 引导申请
- ...
4. 异常情况：转人工
5. 关闭：发送确认消息
要求：SOP 写得到"AI 能照着做"的颗粒度。如果人类新人需要 2 周才能学会，你的 AI 也学不会。
必填项 3：边界规则
明确"AI 做什么"和"AI 不做什么"：
## AI 做
- 回答常见问题
- 查询订单状态
- 引导申请流程
## AI 不做（必须转人工）
- 退款审批（财务权限）
- 投诉处理（情感复杂度）
- 客户信息修改（合规要求）
- 涉及金额 > 1000 元的承诺
关键：边界比范围更重要。不要"什么都能干"，要"这 5 件事能干"。
必填项 4：成功标准
必须量化：
| 指标 | 目标值 | 测量方式 |
|---|---|---|
| 首答准确率 | > 90% | 抽样 100 条人工评分 |
| 完成率 | > 80% | 1 - 转人工率 |
| 用户满意度 | > 4.2/5 | 5 分制反馈 |
| 响应时间 | < 30 秒 | 系统自动 |
| 成本 | < X 元/月 | 账单统计 |
常见坑：成功标准写"提升效率"——无法测量就等于没标准。必须量化。
必填项 5：风险预案
至少准备 3 套预案：
## 预案 1：AI 故障
- 检测：准确率 < 70% 自动告警
- 响应：30 分钟内切换到人工
- 恢复：修复后灰度上线
## 预案 2：AI 幻觉（乱答）
- 检测：用户连续 3 次反馈"答非所问"
- 响应：自动转人工 + 提示词紧急调整
- 复盘：每日 review 高错误率场景
## 预案 3：成本超支
- 检测：日 Token 消耗 > 预算 1.5 倍
- 响应：自动降级（关闭非核心数字员工）
- 复盘：每周 review 成本归因
阶段 3：数字员工选型与角色设计
选型原则
一个数字员工 = 一个核心角色。
| 反例（不要做） | 正例（推荐） |
|---|---|
| "客服小全能" | "售前小音" / "售后小美" / "投诉小核" |
| "数据机器人" | "小算·报表" / "小算·对账" |
选型流程：
- 把阶段 2 的场景清单按"职责"分组
- 每个组对应一个数字员工
- 每个数字员工只承担 1-2 个核心场景
- 复杂场景用"多 Agent 协作"
角色档案设计
每个数字员工必须有一份"员工档案"：
# 数字员工档案：小音
## 身份
- 名称：小音
- 角色：售前咨询助手
- 上线日期：____
- 负责团队：客服部
- 备份：当小音故障时，由小美临时接管售前基础查询
## 职责
### 主要
- 产品咨询（参数、价格、活动）
- 订单查询
- 引导下单
### 不做
- 售后问题
- 退款审批
- 投诉处理
## 协作
- 售前订单异常 → 转给小算（数据分析）
- 售前投诉 → 转给小核（投诉处理）
## KPI
- 首答准确率 > 90%
- 转人工率 < 20%
- 客户满意度 > 4.3
YingClaw 的"角色档案"模块直接支持这个配置——5 分钟搭一个数字员工。
阶段 4：提示词与知识库准备清单
提示词编写检查项
| 检查项 | 标准 | 状态 |
|---|---|---|
| 角色明确 | 有具体名字和身份 | ☐ |
| 职责清晰 | 列出"做什么"和"不做什么" | ☐ |
| 输入格式 | 明确接收什么数据 | ☐ |
| 输出格式 | 明确输出什么格式 | ☐ |
| 示例丰富 | ≥ 3 个正例 + ≥ 2 个反例 | ☐ |
| 兜底机制 | 未覆盖场景的默认行为 | ☐ |
| 长度控制 | 800-1500 字 | ☐ |
| 语气风格 | 符合品牌调性 | ☐ |
知识库准备检查项
| 检查项 | 必填 | 状态 |
|---|---|---|
| 知识库目录结构 | ✅ | ☐ |
| 文档来源（产品手册、FAQ、政策文件） | ✅ | ☐ |
| 文档格式（Markdown / PDF / 网页） | ✅ | ☐ |
| 文档数量（覆盖 80% 常见问题） | ✅ | ☐ |
| 文档更新机制 | ✅ | ☐ |
| 知识库权限（谁能看什么） | 推荐 | ☐ |
| 测试检索（用 10 个真实问题验证） | ✅ | ☐ |
常见坑：
- 知识库放进去就能用——不清理、不分类，AI 检索质量差
- 文档全靠 AI 自动生成——幻觉源头，AI 自己编的"知识"会污染数字员工
- 知识库从不更新——产品变了、员工不知道，AI 答过时信息
测试用例准备
上线前必须有测试用例库：
- id: TC001
scenario: 售前产品咨询
input:
user: "你们的产品 X 多少钱？"
expected:
keywords: ["产品 X", "元", "价格"]
format: "礼貌 + 准确 + 引导"
no_keywords: ["不知道", "不清楚"]
- id: TC002
scenario: 订单查询
input:
user: "我的订单 12345 到哪了？"
expected:
keywords: ["查询", "物流"]
format: "礼貌 + 引导提供订单号"
要求：测试用例 ≥ 30 条，覆盖正常场景 + 边界场景 + 异常场景。
阶段 5：权限与安全配置
权限矩阵设计
不要"全员通权限"：
## 数字员工权限
| 数字员工 | 数据范围 | 系统权限 | 时间限制 |
|---------|---------|---------|---------|
| 小音（售前） | 产品库 + 订单（只读） | CRM、ERP（只读） | 24/7 |
| 小美（售后） | 订单 + 退款记录 | CRM、ERP（读写） | 24/7 |
| 小核（投诉） | 订单 + 客户 + 投诉记录 | CRM（读写） | 工作时间 |
| 小算（数据） | 全量数据库 | BI、报表（只读） | 24/7 |
| 小财（财务） | 财务数据 | 财务系统（读写） | 工作时间 |
YingClaw 的"权限管理"模块直接支持这种矩阵化配置——可视化勾选，5 分钟完成。
安全配置检查项
| 检查项 | 必填 | 状态 |
|---|---|---|
| 数据加密（传输 + 存储） | ✅ | ☐ |
| 访问日志（谁在什么时间访问什么） | ✅ | ☐ |
| 异常行为告警 | ✅ | ☐ |
| 审计日志（保留 90+ 天） | ✅ | ☐ |
| 数据脱敏（敏感信息隐藏） | 推荐 | ☐ |
| API 限流（防滥用） | ✅ | ☐ |
| 密钥管理（不硬编码） | ✅ | ☐ |
| 备份加密 | 推荐 | ☐ |
| 二次验证（敏感操作） | 推荐 | ☐ |
关键：合规要求严格的行业（金融、医疗、政企）必须做访问日志 + 审计日志，否则过不了审计。
阶段 6：测试与上线清单
测试阶段（1-2 周）
| 测试类型 | 内容 | 通过标准 |
|---|---|---|
| 单元测试 | 测试用例库跑一遍 | 通过率 > 85% |
| 集成测试 | 数字员工 + 业务系统联调 | 关键流程通过 |
| 用户验收测试 | 业务专家真实使用 1 周 | 满意度 > 4.0 |
| 压力测试 | 模拟峰值流量 | 响应时间 < 1s |
| 安全测试 | 渗透测试 + 权限测试 | 无高危漏洞 |
| 容灾测试 | 模拟 AI 故障 | 切换人工 < 30 分钟 |
灰度上线（2-4 周）
不要"全量上线"——按以下节奏灰度：
第 1 周：10% 用户（内部员工 + VIP 客户）
├─ 通过 → 第 2 周
└─ 准确率 < 70% → 回滚调整
第 2 周：30% 用户（扩展到普通客户）
├─ 通过 → 第 3 周
└─ 投诉率 > 5% → 回滚调整
第 3 周：70% 用户
第 4 周：100% 用户
每个阶段必须有"回滚预案"——出问题能 5 分钟内回退。
上线日 checklist
- [ ] 系统运行正常（CPU/内存/磁盘）
- [ ] 所有数字员工就位
- [ ] 测试用例 100% 通过
- [ ] 备份已确认
- [ ] 监控告警已配置
- [ ] 应急联系人在场
- [ ] 客户通知已发送
- [ ] 客服团队培训完成
- [ ] 数据报表模板就位
- [ ] 回滚流程已演练
YingClaw 的"灰度发布"模块直接支持这个流程——1 分钟配置灰度比例，5 分钟回滚。
上线后 7 天必做事项
上线不是结束，上线后 7 天是"调优黄金期"。
第 1-2 天：实时监控
| 监控项 | 频率 | 处理方式 |
|---|---|---|
| 准确率 | 每小时 | < 70% 立即告警 |
| 转人工率 | 每小时 | > 30% 立即告警 |
| 响应时间 | 实时 | > 60s 立即告警 |
| Token 消耗 | 实时 | 超预算 1.5 倍告警 |
| 客户反馈 | 实时 | 负面立即 review |
第 3-5 天：错误归因
把第 1-2 天收集到的错误分类：
- 格式问题（漏问候、超长、没引导）→ 改提示词
- 边界问题（不该答的答了、该答的没答）→ 改职责定义
- 知识问题（答错、答旧）→ 补/更新知识库
- 协作问题（转错人、协作断链）→ 改协作规则
第 6-7 天：调优迭代
基于错误归因，做第一轮提示词优化：
## v1.0 → v1.1 改动
- 增加"礼貌开头"约束
- 补充 3 个边界 case 示例
- 增加"超出场景转人工"规则
- 测试用例库从 30 条扩到 60 条
- 通过率从 78% 升到 91%
关键：每改一次，跑一遍测试用例库。别凭感觉改。
第 14-30 天：稳定期
- 每天 review 50 条对话
- 每周更新一次知识库
- 每月调优一次提示词
- 每季度做一次"数字员工花名册" review
常见问题
第一次部署应该选几个数字员工？
1-2 个，不要超过 3 个。第一次的目的是"跑通流程"，不是"全面铺开"。
- 1 个：最稳，适合纯小白
- 2 个：可以测试协作（如客服 + 知识库）
- 3 个：上限，多了协调不过来
第一次跑通后，第二次再扩到 5-8 个。循序渐进。
部署周期一般是多久？
按规模和复杂度：
- SaaS 试用版：5 分钟开箱，1 天上手
- 小型本地部署（1-2 个数字员工）：1-2 周
- 中型本地部署（5-10 个）：1-2 个月
- 大型企业部署（10+ 个，复杂权限）：3-6 个月
关键里程碑：
- 第 1 周：环境 + 第一个数字员工上线
- 第 2-3 周：测试用例通过 + 灰度上线
- 第 4-6 周：稳定运行 + 第一个调优周期
- 第 7-8 周：第二个数字员工上线
部署失败的最常见原因是什么？
按概率排序：
- 业务没梳理清楚（40%）
- 提示词没迭代（25%）
- 权限设计不当（15%）
- 没准备测试用例（10%）
- 成本预算不足（5%）
- 其他（5%）
前 3 项占了 80%——这份清单正好覆盖。
需要专业培训吗？
需要，但不必是大课。推荐三步：
- 官方培训（2 小时）：营域智能提供 YingClaw 基础培训
- 内部讲师（4 小时）：培养 1-2 个内部讲师，能教业务团队
- 实战（持续）：边用边学，1-2 个月后基本都能上手
不要"全员培训"——只培训会写提示词的"训练师"和会用数字员工的"业务专家"，其他人按需。
部署后多久能"出效果"？
| 时间 | 效果 |
|---|---|
| 第 1 周 | 第一个场景跑通（"动起来"） |
| 第 1 个月 | 准确率到 80%+（"用起来"） |
| 第 3 个月 | 准确率到 90%+，扩 3-5 个数字员工（"离不开"） |
| 第 6 个月 | 全面铺开，团队熟练（"用得好"） |
不要期待"第一天就完美"——AI 数字员工是"养"出来的，不是"装"出来的。
哪些企业不适合部署数字员工？
诚实地说：
- 业务规模太小（< 10 人的团队）——ROI 太低
- 业务高度依赖人工判断（如医疗诊断）——合规风险
- 数据极度敏感 + 强合规（如军工）——除非能本地部署
- 没想清楚要自动化什么——上了也是摆设
反过来，有明确 SOP、有数据基础、愿意 2-3 月投入的企业都适合。
总结
第一次部署 YingClaw，90% 的坑都源于"准备不足"。这份清单覆盖了 6 大阶段 50+ 检查项，照着走能少踩 80% 的坑。
核心要点：
- 环境 + 团队 + 预算——3 件事先想清楚
- 业务场景 + SOP + 边界——80% 失败源于"业务没梳理"
- 数字员工选型 + 角色档案——一个萝卜一个坑
- 提示词 + 知识库 + 测试用例——上线前必齐
- 权限矩阵 + 安全配置——别等审计打回
- 测试 + 灰度 + 回滚——稳比快重要
- 上线后 7 天——调优黄金期
营域智能做 YingClaw 的核心理念是 "AI 应成为数字员工"——但数字员工不是"装上去"就好，是"养出来"的。把清单上的每项都打勾，90% 的坑就避开了。
如果你正准备第一次部署，先别急着装系统——把这份清单打印出来，逐项打勾。3 天梳理 + 1 周准备 + 1 周部署 + 2 周调优 = 7 周完成一个高质量的上线。YingClaw 的"部署助手"功能可以帮你自动检查 80% 的清单项。