去年年底有个做精密零部件加工的客户找过来，老板开门见山：「我看大家都在做 AI Agent，我也想试一下，但我不想花一年时间最后发现是坑。你们能不能 30 天给我一个结论——值得做就继续投，不值得做就停掉。」我们花了一个多小时把他车间里的场景过了一遍，最后选了「客户询价单的初步报价测算」这一个动作作为试点切入。第 28 天的时候老板自己拍板继续投，但试点选的不是当初他最想做的「智能排产」，而是先把报价这件事做扎实。这个故事不是说我们多厉害，而是想说：AI Agent 试点的成败，从你怎么排这 30 天的节奏就已经决定了一大半。
很多企业老板被各种发布会和朋友圈刷得心痒，回头跟 IT 部门说「我们也搞个 AI Agent 试试」，然后 IT 找了个外部团队，开了几次会，半年过去什么也没落下来。这种「试一下」往往就是赌博——没有节奏、没有可交付物、没有退出机制，最后变成「投入了不甘心，继续投又怕踩坑」的死循环。真正的试点应该像一个有时间盒的项目：明确目标、明确周节奏、明确每周交什么东西出来、明确什么情况下叫停。下面把这 30 天怎么排讲清楚。
试点 30 天的核心目标：用最小投入回答一个 yes/no
把 30 天试点理解成一个加速的尽职调查更贴切。它要回答的不是「AI Agent 能不能做」——那个答案在 PPT 里已经有了——而是「在我们公司这个具体场景里，AI Agent 能不能在可接受成本下产生可衡量的价值」。这是一个 yes/no 题，不是开放题。
把目标定成 yes/no 之后，你会发现很多事情自动变简单。比如「场景要不要选大一点显得有面子」这种问题就不用纠结了，因为大场景在 30 天里根本回答不了 yes/no。再比如「要不要把全公司的数据都接进来」也不用想了，因为你只需要回答这一个场景的 yes/no，不需要接全公司。
我们一般会让客户在第一周就把 yes 和 no 的判定标准写在纸上。比如「如果 30 天后，Agent 处理同类询价的准确率能到 85% 以上，且单次处理成本低于人工 30%，就是 yes；否则就是 no」。这个标准定不下来，后面几周就会反复扯皮。判定标准里要包含三类指标：业务效果（准不准、快不快）、成本（贵不贵）、体验（业务部门愿不愿意继续用）。三个都达标才叫 yes，缺一个都要再讨论。
关于场景怎么选，我们之前写过 AI Agent 试点前的自检清单 和 AI Agent 落地路线图，建议老板在开始 30 天之前先把那两篇看一遍，能少走不少弯路。
第一周：场景排序、数据盘点、对接人确认
第一周最容易犯的错是「先把技术方案搞清楚」。技术方案在第一周其实不重要，重要的是这三件事：把候选场景排个序、把这个场景需要的数据盘清楚、把业务对接人锁定下来。
场景排序用一个简单的二维矩阵就够了：业务价值（每年能省/赚多少钱、量级即可）和实现难度（数据全不全、规则清不清、有没有现成标准）。把候选场景按这两个维度画到象限里，先做「价值高、难度低」象限里的那个。注意「价值高」不一定是金额最大的——选一个能让业务部门一线员工每天都用、能讲出「真的省了我一小时」的场景，比选一个看起来高大上但一年只触发几次的场景要好得多。
数据盘点要回答四个问题：数据在哪个系统里、谁有权限给我看、字段质量怎么样、能不能拿到一份脱敏样本。这里特别要注意权限审批走流程的时间——很多公司 IT 给你开一个数据接口的权限要走两周，第一周不启动这件事，第三周准卡住。
对接人确认比上面两件事更关键。AI Agent 试点失败最常见的原因不是技术问题，而是业务部门派来的对接人是个「随便派一个人」而不是「真正懂这个场景的人」。我们一般会要求客户在 KO 会上明确：对接人姓名、每周可投入小时数、能不能做决策。这三个不明确，后面会非常痛苦。
第一周的可交付物大概是这样：
| 序号 | 交付物 | 由谁产出 | 用途 |
|---|---|---|---|
| 1 | 试点场景一句话定义 | 业务方+服务团队 | 锁定边界 |
| 2 | yes/no 判定标准 | 老板+项目负责人 | 30 天后决策依据 |
| 3 | 数据清单与权限申请单 | 服务团队+IT | 第三周接入准备 |
| 4 | 业务对接人时间承诺表 | 业务部门 | 防止后期失联 |
| 5 | 现有人工处理流程录像/截图 | 业务对接人 | 作为基线对比 |
第 5 项很多团队会忘——没有人工基线，第四周算 ROI 的时候就只能拍脑袋。建议第一周就找业务对接人录一段「他平时怎么处理这件事」的屏幕录像，时长不用长，几分钟即可。
第二周：POC 搭建与第一次内部 demo
第二周是技术活高密度发生的一周。这一周要做的事是：基于第一周确认的场景，用脱敏样本数据搭一个能跑通主流程的 POC，并在周五做一次内部 demo。
这里强调「脱敏样本」是因为真实数据的接入要走第一周提交的权限审批流程，通常第二周还下不来。但我们不能等审批，得先用样本数据把骨架搭起来。骨架搭好之后第三周拿到真实数据直接换数据源就行。
POC 阶段技术选型不要纠结。如果客户已经在用钉钉，钉钉 AI 助理 / Wukong 体系 通常是性价比最高的起点，开通和接入都快；如果场景比较复杂、需要深度定制，再考虑外接平台或自建。对比可以看 钉钉 vs 扣子 vs 飞书 vs 文心 那篇。
第一次 demo 的核心不是炫技，是暴露问题。我们带客户做 demo 的时候，会刻意设计几个「业务部门一看就知道不对」的边界 case 让 Agent 处理，看它怎么反应。Agent 答得很好当然好，答得不好正是宝贵的反馈——它告诉你第三周要重点优化的地方在哪里。最怕的是 demo 全程跑「精挑细选的好 case」，老板看完觉得「神了」，结果第三周一上真实数据全崩。
第二周容易翻车的点：把 demo 排到周五下午，结果周三发现某个 API 还没调通，临时通宵赶工出来的 demo 质量很差。建议把 demo 时间排到周四下午，留周五一天处理 demo 上暴露的问题。
第二周可交付物大致包括：能跑通主流程的 POC 链接（或截图）、demo 录屏、demo 之后整理的问题清单（每条问题标明严重度和归属：是数据问题、还是 prompt 问题、还是流程设计问题）、下一周的优化优先级排序。
第三周：真实数据接入与试用扩展
如果说前两周还是「技术团队闭门搞」，第三周开始就要把业务部门拉进来天天用了。这一周做三件事：把第一周申请的真实数据权限落地、让 3-5 个真实业务用户开始日常使用、每天收集使用反馈。
真实数据接入是这一周最容易出意外的环节。脱敏样本跑通的流程，换上真实数据可能会因为字段名不一致、编码不规范、历史数据脏等问题大面积报错。我们的经验是预留 1-2 天专门处理「数据脏」相关问题，不要把这一周的工期排太满。
试用人数控制在 3-5 个就够了。再多的话第三周根本来不及收集和处理反馈，反而会让早期用户体验差、口碑崩盘。挑选试用人选的标准：业务流程熟悉、对新工具不抗拒、肯花时间反馈。这三条任意缺一条都会让试用效果打折。
反馈收集建议建一个小群（钉钉群、企业微信群都行），让试用用户随时把问题甩进去，技术团队当天回复、隔天修复。这种快节奏反馈循环是 30 天试点能不能成的关键——一周才修一次的节奏，反馈到第四周还没消化完。
第三周也是最容易看出对接人「靠不靠谱」的一周。如果业务对接人这一周还是「我太忙了等下周」，基本可以判断这个试点凶多吉少。这种情况下不要硬撑，立刻跟老板汇报，让老板出面要么换对接人、要么调整对接人的工作优先级。
第三周可交付物：真实数据使用记录（处理了多少条、准确率多少）、试用用户访谈纪要（每人 15 分钟）、bug 与改进清单（按优先级排序）、本周 Agent 处理成本明细（模型调用费、人工监督时长）。
第四周：ROI 数据收集与扩展评估
第四周不是「做」的一周，是「算」和「想」的一周。技术侧基本停止大的功能开发，重点把前三周的数据汇总成可以拍板的材料。
ROI 数据要算三个对比：人工处理 vs Agent 处理的耗时差、人工 vs Agent 的准确率差、Agent 全成本（包括模型费、平台费、运维时长）vs 节省的人工成本。这里要老实——很多团队为了让 ROI 好看会把「人工成本」算得很高、「Agent 成本」算得很低，这种数字老板一看就识破，反而会失去信任。建议用区间表达，比如「Agent 每条处理成本约几毛到一块多，人工每条处理时长约 X 到 Y 分钟」。
扩展评估回答两个问题：这个场景再投入两到三个月能做到什么程度，以及还有没有可以横向复制的相似场景。第二个问题特别重要——单一场景的 ROI 可能不够亮眼，但如果同类场景可以横向复制到 5-10 个，故事就完全不同了。
第四周还要做一件容易被忽略的事：给业务部门做"交接培训"。哪怕试点结束、Agent 暂时不再继续，业务对接人这一个月学到的「怎么跟 AI 协作、怎么写好 prompt、怎么评估 AI 输出」都是宝贵的资产。开一次 1-2 小时的内部分享会，让对接人讲给同部门的同事听，这件事本身就有价值。
第四周可交付物：ROI 数据汇总报告（一页）、试点期问题与解决记录（用于下一轮借鉴）、扩展路线图（下一步做什么、多久、需要什么资源）、内部分享会材料、决策建议书（建议扩、停、还是转方向）。
每周可交付物清单一表汇总
把四周的可交付物汇成一张表，方便老板和项目负责人对照检查：
| 周次 | 核心任务 | 关键可交付物 | 容易遗漏的事 |
|---|---|---|---|
| W1 | 选场景、盘数据、定人 | 场景定义、yes/no 标准、数据清单、对接人时间表、人工基线录屏 | 人工基线录屏 |
| W2 | POC 搭建 + 内部 demo | POC 链接、demo 录屏、问题清单、优化优先级 | demo 时间留余量 |
| W3 | 真实数据 + 试用扩展 | 真实数据使用记录、用户访谈、bug 清单、成本明细 | 处理脏数据预留时间 |
| W4 | ROI 汇总 + 扩展评估 | ROI 报告、扩展路线图、分享会、决策建议书 | 业务对接人交接培训 |
每周的可交付物建议都用一个共享文档（钉钉文档或飞书文档都行）维护，每周五更新一次，老板想看进度时随时打开就能看到，不用专门开汇报会。这件事看着小，但能极大降低沟通成本。
试点常见三个翻车点
第一个翻车点是场景选得太大。「我想做一个能接管整个客户服务流程的 AI Agent」——这种诉求在 30 天里跑不通，最后只会做成一个 demo 然后无疾而终。解决办法是在第一周强迫自己把场景缩小到「一个岗位的一类动作」，比如不是「客户服务」而是「售后工单的初步分类与转派」。
第二个翻车点是业务对接人不给力。前面已经讲过怎么识别，这里再补一点：很多时候业务对接人本人很愿意配合，但他的直属上级觉得「这个 AI 项目不影响我部门 KPI」，所以不愿意让对接人投入时间。这种情况要在第一周就跟老板说清楚，让老板出面跟那个部门负责人沟通——这不是技术问题，是组织问题，技术团队解决不了。
第三个翻车点是只做技术不做组织。Agent 跑得再好，业务流程不调整、KPI 不调整、培训不到位，最后还是没人用。第四周分享会、扩展路线图里的「组织配套」要写清楚——下一步要不要调整谁的工作内容、要不要新增/删减哪些岗位、要不要重新定义 KPI。这些不解决，Agent 就只是一个昂贵的玩具。这部分可以参考 AI 数字员工的能力边界 和 企业 AI 落地 8 步 两篇。
试点失败的退出机制要写在合同里
很少有人提这件事：试点开始之前，就要把「什么情况下叫停」写清楚。这件事不是悲观，而是负责任。我们一般会跟客户约定三种叫停情形：
第一种是第二周 demo 没跑通核心流程。这通常意味着场景选错或技术能力不匹配，硬撑两周也是浪费钱。这种情况下双方坐下来复盘，重新定义场景或者重新组团队，重新启动一轮试点。
第二种是第三周真实数据接入卡死超过 5 个工作日。这通常是数据质量或权限问题，硬接也接不进来。这种情况下要么先做数据治理（参考 企业数据治理第一步）再启动 AI 试点，要么换一个数据相对干净的场景。
第三种是第四周 ROI 算下来不达预期，且没有明显的优化路径。这种是最坦然的失败——证明这个场景就是不适合用 AI Agent，省了未来两年的盲目投入。
退出不丢人，硬撑才丢人。把退出机制写在合同里，双方反而都轻松，技术团队不用为了「保项目」而粉饰数据，客户不用为了「不亏」而硬上扩展。
30 天后的决策清单：扩、停、还是转
最后给一份决策清单，30 天结束的那次会议上，老板拿着这张表问自己即可：
- 业务效果：Agent 准确率/完成率达到第一周定的标准了吗？
- 成本：单次处理成本与人工对比有优势吗？区间多少？
- 体验：3-5 个试用用户里有几个说「不要再让我回去用旧方式」？
- 数据：真实数据接入是否稳定？还存在哪些治理债？
- 组织：业务部门负责人是否认同继续投入？KPI 调整方案是否清晰？
- 扩展：能横向复制到几个相似场景？复制成本如何？
六个问题里有 4-5 个明确正向，就扩——按第四周的扩展路线图继续投入； 有 2-3 个正向、其他模糊，就转——保留这次试点的产出，换一个相邻场景再做一轮 30 天； 4 个以上负向，就停——把这次学到的东西写成内部复盘，等公司业务流程或数据基础再成熟一些重新考虑。
无论结果是哪一种，30 天试点本身都不是失败——它把一个「老板心里痒、IT 心里慌、业务部门心里烦」的状态，变成了一个可以坐下来理性决策的状态。这个转变本身就是价值。
写在最后
AI Agent 试点不是一场技术秀，是一场用项目管理纪律证明商业价值的尽职调查。30 天的时间盒、清晰的周节奏、明确的可交付物、提前约定的退出机制——这些看起来「不那么 AI」的东西，恰恰决定了 AI 项目能不能在你公司活下来。技术选型有很多种，模型有很多家，但试点节奏只有一种纪律：选小、做深、量化、果断。希望这份周节奏清单能让正在排试点的老板和项目负责人少走一些我们曾经走过的弯路。
