一份 90 天路线图:选择用例、构建工作流、对照基线衡量,并依据证据决定是否扩展,避免临时摸索。
第 1—15 天:找到值得解决的阻碍
团队梳理重复任务、时间、数量、质量、错误、数据、系统和职责,然后优先选择一个有价值、可观察且足够聚焦的问题。汇总月报、整理简报或筛选咨询,可能比为全公司打造通用智能体更适合作为起点。基线记录当前的工作方式以及哪些方面不能变差。没有起点,任何演示都会显得很快,任何结果却都难以证实。
九十天足以把一个优先解决的阻碍转化为有依据的决策,却不足以改造整家公司。合适的路线图应记录当前流程,选择范围明确的案例,设定基线与控制措施,与真实用户共同构建,评估质量和采用情况,最后作出明确决定:扩大、修正或停止。
第 16—30 天:设计工作流及其边界
明确输入、步骤、来源、输出、用户、负责人、人工决策、例外和指标。安全与法务根据场景风险审查数据和供应商。团队在构建前选择一组有代表性的示例,并约定评价量表,也明确试点期间哪些部分仍由人工完成。架构可以简单,定义必须精确。
第 31—60 天:与实际工作者共同构建
原型在受控范围内由真实用户测试。每次迭代都检查哪些地方缺少上下文、哪些步骤造成返工,以及出现了什么例外。指令、模板和集成都进行版本管理。团队避免自动化尚未理解的环节,并保留手动路径。目标不是最大化功能数量,而是让一个完整流程产出可用、可追溯的结果。
第 61–75 天:与基线比较
评估涵盖总耗时、质量、修正、采用情况、故障、运营成本及参与人员的体验。如果速度提升却成倍增加审核工作,就未必真正创造了能力。还要测试不利情形与暂停机制。结果按任务和用户类型分别呈现,避免平均值掩盖严重故障。
第 76—90 天:决策,并将经验沉淀为系统
项目的终点不是一场试点汇报,而是基于证据的决策。如果扩大应用,应安排支持、负责人、预算、培训、控制措施和下一批参与者。如果需要调整,团队应准确说明哪个假设仍未得到验证。如果停止,应记录原因和经验。无论结果如何,流程都应留下可复用的资产:流程图、测试数据集、评分标准、政策,以及选择下一个案例的标准。
90 天,扩展规模前先作出决策
这份路线图是可调整的建议。天数代表规划窗口,并非保证的商业时间表。
| 窗口 | 交付物 | 决策 |
|---|---|---|
| 第 1–15 天 | 流程、负责人和起点 | 我们有数据和优先解决的问题吗? |
| 第 16—30 天 | 原型、评估与权限 | 是否达到最低质量标准? |
| 第 31–60 天 | 受监督的试点与错误记录 | 相较现有流程,它增加价值了吗? |
| 第 61–90 天 | 采用、支持与跟进计划 | 扩大、修正还是停止? |
依赖条件包括访问权限、获授权的数据、验证人员和预算。启动前记录每阶段的退出标准。
下载采用路线图(CSV) ↓

