企业的 AlphaGo Moment

做完两期 FDE 黑客松以后，我对「48 小时」有了一个更准确的理解。

在劳泰德 48 理论里，48 小时从来不是一个对外承诺的交付周期，也不是要求团队两天做完一家企业的 AI 改造。它只是第一层拆解：用一个足够短的时间窗口进入企业、理解工作流，并找到一个值得继续投入的真实证据。

这个证据最好能够制造一次企业的 AlphaGo Moment。

所谓企业的 AlphaGo Moment，是 AI 第一次在企业自己的业务里产生一个具体、可核验，而且足以改变下一步决策的结果。

它不一定是 AI 战胜了人，也不一定需要一个复杂系统。它可以只是发现一条人工记录错误，把几个小时的工作压缩到几分钟，或者第一次把结果准确地回链到原始文件。

关键不在于结果有多大，而在于企业能不能亲手验证它。

压到最短就是：Demo 的价值是证据，不是表演。

一、先做一个面，再打穿一个点

第二期 FDE 黑客松进场以后，我们没有拿着老板的一句话直接开工，而是先完成了两组访谈。

老板描述的是他看到的问题，管理者描述的是检查和责任，一线人员描述的才是每天真正发生的操作。只有把不同角色拼起来，才能看见完整工作流。

这就是「一个面」。

这个面至少要把五件事说清楚：真实输入从哪里来，中间经过哪些人，谁负责判断，出现异常时谁来处理，最终结果进入哪里。

但只做工作流梳理，会退化成咨询。企业得到一张未来蓝图，却不知道团队能不能真正做出来。

所以还需要打穿「一个点」。

这个点不能是把完整方案里的每个模块都做 20%，而应该选择一条足够窄的真实链路，把它 100% 跑通。

我们最终选择的是一种真实材料、一个具体任务和一个能够现场回查的结果。Demo 返回 OCR 结果时，同时保留原始图片和对应位置。它没有覆盖整个企业知识库，也没有试图一次解决全部业务，只是把一个最关键的判断闭环做完整。

所以「一个面＋一个点」不是一句口号。

面负责证明 FDE 理解了企业，点负责证明 FDE 能够改变企业。

只有面，会变成 PPT；只有点，会变成孤立功能。

二、真正的震撼来自证据链

那次演示里，AI 给出的结果与人工记录出现了分歧。

现场第一反应是 AI 识别错了。但沿着 Demo 返回的来源重新打开原始图片、找到对应位置以后，大家确认这一次是 AI 记录正确，人工表格反而出现了错误。

那一刻真正改变企业判断的，不是模型生成了一段漂亮答案，也不是我们做了一个多复杂的界面。

而是人和 AI 发生分歧时，系统没有要求企业「相信模型」，而是把所有人带回了原始证据。

这个结果同时满足了四个条件：

- 使用的是真实业务材料；

- 结果具体到可以判断对错；

- 每个结论能够回查原件；

- 核验以后，企业愿意继续讨论下一步。

这才是企业里的 AlphaGo Moment。

AlphaGo 让人震撼，不是因为它会介绍自己的能力，而是因为它在一个所有人都看得懂的棋盘上，走出了一步人类没有想到的棋。

企业 AI 也是一样。震撼不来自模型的自我解释，而来自一条企业能够独立复核的证据链。

所以我们后来把现场 Demo 的标准改得非常硬：结果不能回查原件，就不能算作证据。

一个能回答问题的聊天框不算，一个提前准备好的成功演示也不算。系统必须吃进真实输入，保留来源，记录人工修改，并允许失败被看见。

三、架构必须在现场以后决定

第二期黑客松还推翻了我们很多进场前的技术假设。

现场资料不是整理好的 Markdown，而是大量 PDF、图片和体积很大的项目文件。文件上传、网络速度、远程检索和原件溯源，迅速成为比模型能力更现实的问题。

这时我们才发现，架构不能靠个人偏好决定，而要由企业 Context 的形状决定。

如果企业主要是 Markdown、小文件和低数据量资料，可以先使用 Light 模式，让个人 Agent 直接读取。

如果企业有大量图片、PDF 和多 GB 项目资料，把文件和执行放在企业附近，采用托管或本地模式会更稳定。否则 48 小时可能有一半都耗在上传文件上。

是否使用 RAG 也是同样的逻辑。

当单个业务对象可以被直接文件、结构化摘要和确定性检索覆盖时，不需要为了显得技术完整，提前建设第二套索引。只有出现跨项目相似案例检索、单个对象持续溢出上下文，或者术语表和摘要仍然无法解决的语义鸿沟时，才重新评估 RAG。

现场接入企业已有 IM，也只能解决入口问题。

员工可以从飞书、钉钉或其他 IM 发起任务，但 IM 只是 Gateway，不是公司的大脑。真正的 Context、文件、Skills、权限和反馈记录，仍然需要一个清晰的真相源和执行环境。

这场黑客松留下的技术判断可以压成一句话：先吸收 Context，再让 Context 决定架构。

四、先数清流程入口有多少人

另一次制造业现场里，我们又修正了一个原来的判断。

最开始面对纸质单据，我们倾向于不改变员工习惯，保留原来的填单方式，再通过 OCR 把内容结构化。

这个方案看起来合理，但现场进一步梳理后发现，真正填写单据的人并不是全厂员工，而是大约 30 名车间主管。

如果实际入口只有 30 人，组织一次小规模培训，让这些主管直接通过飞书提交信息，可能比长期建设、维护和纠正 OCR 更便宜。

但如果入口是全厂 700 多名工人，让所有人注册新工具、学习新流程并改变工作习惯，推广成本就会非常高。这种情况下保留原单据，再增加 OCR 适配层反而更合理。

所以 FDE 不能机械地坚持「绝不改变用户习惯」，也不能看到 AI 就要求所有人换一种工作方式。

正确的判断是比较两边的总成本：改变习惯的成本，与维护自动化适配层的成本，哪一个更低。

而这个问题只有进入现场、数清真正的流程入口人数以后才能回答。

30 名主管和 700 名工人，面对的是完全不同的产品设计。

五、黑客松不是比谁做的功能多

经过几次现场以后，我们判断一次 FDE 黑客松，不再看 48 小时内做出了多少页面、接入了多少模型或者堆了多少功能。

第一阶段真正需要留下的是五样东西：

1. 一张经过多角色访谈验证的工作流图；

2. 一个范围足够窄、但链路完整的 Demo；

3. 一套真实输入，以及结果对应的原件证据；

4. 一份成功、失败和人工修正记录；

5. 一个明确的下一阶段问题。

评测也不能只看准确率。

我们会同时记录原任务需要多长时间、AI 需要多长时间、字段可用率、任务完成率、人工修正项、依据是否可追溯，以及系统失败时是否明确暴露。

测试数据至少要包含典型、边界和异常三类。

典型用例验证主流程；边界用例检查缺字段、模糊输入和超长材料；异常用例检查资料冲突、权限越界、提示注入和工具失败。

如果测试集里全部是提前挑选的成功案例，Demo 只能证明团队会演示，不能证明系统可以进入企业。

最重要的指标也不是「做完了」，而是企业是否愿意继续开放真实材料、安排真实使用者，并进入下一轮验证。

六、48 小时只是第一刀

因此，在劳泰德 48 理论里，48 小时只是企业 AI 改造的第一刀。

48 小时，找到一个面和一个点，用真实材料建立第一条可核验的价值证据。

48 天，让 Demo 进入真实使用，从员工的接受、修改、拒绝和异常处理中，沉淀企业 Context、Skills、工作流、权限和 Evals。

48 周，让经过验证的 Agent 开始承担端到端任务，重新划分人和 AI 的责任、权限与风险，最终改变企业的组织方式。

所以 48 小时不是交付，甚至不一定代表一个项目正式成立。

它更像一次高密度的共同调查：企业在观察 FDE 是否值得信任，FDE 也在判断企业的问题、资料、人员和组织是否值得继续投入。

双方最终要找到的，不是一张宏大蓝图，而是一个足够小、足够真实、足以推动下一步的事实。

一家企业真正开始 AI 改造，并不是老板第一次听懂 AI，也不是公司第一次购买大模型账号。

而是它第一次在自己的业务里验证一个 AI 结果，并愿意根据这个结果采取行动。

这就是企业的 AlphaGo Moment。