工作流设计 / 选择第一个试点
如何选择第一条 AI 工作流？
选择一项反复发生的工作：有人负责，能拿到所需资料，结果可以检查。先决定哪里应该改善，再选择模型。
这也是前线部署工程（FDE）的起点：先看清实际工作，再构建系统。
1. 先描述工作，再讨论 AI。
观察一个人如何完成这项工作，记录触发条件、执行人、需要的信息、产出，以及谁会使用这个结果。除了顺利的流程，也记录等待、修改与例外情况。
把“我们需要一个 AI 助手”改成具体描述：“销售同事需要从已审核文档中准备产品答复，经过确认后发送，并记录跟进。”这样，试点才有起点、终点，以及实际帮助的对象。
2. 检查六个条件。
- 反复发生的问题
- 工作需要有足够的发生频率，才能持续观察。令人印象深刻的一次麻烦，未必值得建设系统。
- 明确的用户
- 找到实际执行人，让他们参与定义什么结果才算好用。有管理者支持，不能替代与用户直接交流。
- 可以合规使用的数据
- 明确来源、权限，以及谁来处理缺失或矛盾的信息。资料拿不到或不可靠时，先解决来源和权限，再考虑提示词。
- 内部负责人
- 客户侧需要有人作出决策、回答流程问题，并在试点结束后继续负责这项工作。
- 可观察的结果
- 明确如何比较现有与新流程，例如完成情况、总耗时或实际操作时间、修改次数、遗漏，或约定的质量检查。
- 清楚的范围
- 选定一项任务、一组明确用户和受控的系统范围，同时写清试点不能执行哪些操作。
必要条件缺失时，应先解决，或另选工作流。演示再精巧，也不能弥补没有负责人、拿不到数据的问题。
3. 先看更简单的办法是否够用。
先判断更清楚的流程、共享模板或已有产品能否解决问题。输入和处理结果有固定规则的步骤，可以用普通自动化处理。在理解、检索或起草有实际价值的地方考虑 AI，并检查其输出能否被评估和纠正。
定制开发需要明确理由：是否存在简单方案不能满足的集成、限制或流程要求？评估试点时，也要计入人工审核和后续维护的投入。
场景示例 · 尚未实施的试点
示例：为销售准备待审核的产品答复。
下面只展示如何界定范围，不代表已有客户部署或实测结果。
也可以查看销售、营销、客户服务和运营的业务流程示例，寻找其他起点。
- 触发条件与用户
- 销售人员收到产品问题。第一轮试点只覆盖一个已确认产品系列，以及双方约定的一小组用户。
- 输入
- 问题中去除不必要的个人或保密信息，并使用已审核的产品文档。每份资料注明负责人和版本，只使用获准进入该系统的数据。
- AI 参与部分
- 检索相关段落，起草附来源的答复。信息缺失时明确标注，不编造产品规格来填补空白。
- 人工控制
- 销售人员核对后才能发送。价格、折扣、适用性和合同承诺需要相应业务人员批准。
- 集成范围
- 先获得文档访问权限，把人工审核后的答复用于现有销售流程。权限、去重和故障恢复都经过验证后，再考虑自动向客户关系管理系统（CRM）添加记录。
- 不包含的操作
- 自动向客户发送、自主定价，以及无限制访问无关公司文档。
- 交付内容
- 可用的审核步骤、来源清单、评估样本、操作说明、备用流程和清楚的维护责任。
4. 约定测量方法，以及何时应该停止。
使用新系统前，先观察现有流程中可比较的工作。在试点中记录相同指标，也计入审核和修正输出的时间。解释结果之前，与业务负责人约定可接受质量、观察样本和周期。
以上销售示例可以设计这些检查：资料里没有答案、产品文档相互矛盾、权限被撤销、服务不可用。系统应说明具体问题，并引导用户回到约定的人工流程。这些是建议的验收检查，不代表已完成的测试。
来源无法信任、审核负担大于收益，或必需审批可以被绕过时，应暂停或缩小试点。决定不部署，也可以是有效结论。
5. 观察实际使用，再决定下一步。
帮助用户完成真实任务，并说明如何拒绝答复、纠正来源和从失败中恢复。记录他们为什么使用、回避系统，或退回旧流程。培训结束后，还要观察人们是否继续使用。
分别查看三类记录：通过部署检查的功能、日常工作中观察到的使用，以及与约定基线比较得到的结果。不要把其中一类当作另外两类的证据。
扩大范围前，明确谁负责来源更新、访问权限、技术故障与后续修改。然后决定停止、改进当前试点，还是进入正常运营。扩展范围应当以证据为依据。