# The Enterprise AlphaGo Moment / 企业的 AlphaGo Moment

> Published 2026-08-10 · By lawted (https://x.com/lawted2) · Published on HA7CH (https://ha7ch.com)
> Canonical: https://ha7ch.com/writing/enterprise-alphago-moment

## English

After running two FDE hackathons, I have a more precise understanding of what “48 hours” means.

In Lawted’s 48 Theory, 48 hours has never been a delivery promise to the outside world, nor a demand that a team finish an enterprise AI transformation in two days. It is only the first decomposition: enter the company within a deliberately short window, understand a workflow, and find one piece of real evidence worth investing in.

Ideally, that evidence creates an AlphaGo Moment inside the company.

An enterprise AlphaGo Moment is the first time AI produces a specific, verifiable result inside the company’s own work—one strong enough to change the next decision.

AI does not have to defeat a person, and the system does not have to be complicated. It might catch one error in a human record, compress several hours of work into minutes, or link a result back to the original file for the first time.

The size of the result is not the point. The point is whether the company can verify it with its own hands.

Compressed into one line: the value of a demo is evidence, not performance.

1. Map one surface, then break through one point

When we entered the second FDE hackathon, we did not start building from a single sentence spoken by the boss. We first completed two sets of interviews.

The boss described the problem he could see. Managers described checks and accountability. Frontline workers described what actually happened every day. Only by combining those roles could we see the full workflow.

That is the “surface.”

The surface must clarify at least five things: where real inputs come from, which people they pass through, who makes the judgment, who handles exceptions, and where the final result goes.

But workflow mapping alone turns into consulting. The company gets a picture of the future without knowing whether the team can build any of it.

So we also need to break through one point.

The point should not be 20 percent of every module in the grand plan. It should be one narrow, real chain completed end to end.

We chose one kind of real material, one concrete task, and one result that could be checked on site. When the demo returned an OCR result, it also preserved the original image and exact location. It did not cover the company’s entire knowledge base or try to solve every workflow. It completed one crucial judgment loop.

So “one surface plus one point” is not a slogan.

The surface proves that the FDE understands the company. The point proves that the FDE can change it.

A surface without a point becomes a slide deck. A point without a surface becomes an isolated feature.

2. The real shock comes from the evidence chain

During that demo, the AI result disagreed with a human record.

The first reaction in the room was that the AI had made a recognition error. But after reopening the original image through the demo’s source link and locating the exact evidence, everyone confirmed that the AI record was correct and the human spreadsheet was wrong.

What changed the company’s judgment was not a beautifully generated answer or a sophisticated interface.

When the human and the AI disagreed, the system did not ask the company to “trust the model.” It took everyone back to the original evidence.

The result met four conditions:

- It used real business material;

- It was specific enough to judge right or wrong;

- Every conclusion could be traced to the original source;

- After verification, the company wanted to discuss the next step.

That is an enterprise AlphaGo Moment.

AlphaGo was shocking not because it could describe its capabilities, but because it made a move on a board everyone understood—a move humans had not imagined.

Enterprise AI is the same. The shock does not come from a model explaining itself. It comes from an evidence chain the company can independently verify.

We therefore made the standard for an on-site demo very hard: if a result cannot be traced to the original source, it does not count as evidence.

A chatbot that can answer questions is not enough. A prearranged successful demo is not enough. The system must consume real inputs, preserve sources, record human corrections, and make failures visible.

3. Architecture must be decided after entering the site

The second hackathon also overturned many of our technical assumptions.

The materials were not clean Markdown files. They were large collections of PDFs, images, and heavy project files. Upload time, network speed, remote retrieval, and source traceability quickly became more immediate constraints than model capability.

Architecture, we learned, cannot be chosen by personal preference. It must be shaped by the form of the company’s Context.

If the company mainly has Markdown, small files, and low data volume, a Light mode in which individual Agents read directly may be enough.

If the company has large volumes of images, PDFs, and multi-gigabyte project files, keeping files and execution close to the company through hosted or local deployment is more reliable. Otherwise, half of the 48-hour window can disappear into uploads.

The same logic applies to RAG.

When a single business object can be covered by direct files, structured summaries, and deterministic retrieval, there is no reason to build a second index just to appear technically complete. Reconsider RAG only when cross-project similarity search becomes necessary, one object consistently overflows context, or glossaries and summaries still cannot bridge the semantic gap.

Connecting to the company’s existing IM only solves the entry point.

Employees can start tasks from Feishu, DingTalk, or another IM, but the IM is a Gateway, not the company’s brain. Context, files, Skills, permissions, and feedback records still require a clear source of truth and execution environment.

The technical judgment from that hackathon fits in one sentence: absorb the Context first, then let the Context decide the architecture.

4. Count the people at the workflow entrance first

At another manufacturing site, we corrected another assumption.

Faced with paper forms, our initial instinct was to preserve employee habits and add OCR to structure the contents.

That looked reasonable, but further investigation showed that the people actually filling in the forms were not the whole factory. They were roughly 30 workshop supervisors.

If the real entrance consists of only 30 people, a small training session and direct submission through Feishu may be cheaper than building, maintaining, and correcting OCR over the long term.

But if the entrance includes more than 700 factory workers, asking everyone to register for a new tool, learn a new process, and change habits creates a much larger adoption cost. Preserving the paper form and adding an OCR adapter can then be the better design.

An FDE should therefore neither mechanically insist on “never changing user habits” nor demand a new workflow for everyone whenever AI appears.

The correct judgment compares total costs: the cost of changing habits versus the cost of building and maintaining an automation adapter.

That comparison is impossible until the team enters the site and counts the people who truly operate the workflow.

Thirty supervisors and seven hundred workers require entirely different product designs.

5. A hackathon is not a feature-count competition

After several field projects, we no longer judge an FDE hackathon by how many pages, models, or features appear within 48 hours.

The first stage should leave behind five things:

1. A workflow map validated through interviews with multiple roles;

2. A demo narrow enough to finish but complete enough to close the chain;

3. Real inputs and the original evidence behind every result;

4. A record of successes, failures, and human corrections;

5. One clearly defined question for the next stage.

Evaluation cannot look only at accuracy.

We also record the original task time, AI task time, usable-field rate, task completion, human correction items, traceability, and whether failure is explicitly visible.

The test set must include normal, boundary, and exceptional cases.

Normal cases validate the main path. Boundary cases test missing fields, ambiguous inputs, and oversized material. Exceptional cases test conflicting sources, permission violations, prompt injection, and tool failure.

If every test case was preselected to succeed, the demo proves only that the team can perform—not that the system can enter the company.

The most important signal is not “finished.” It is whether the company will continue to open real materials, assign real users, and enter another round of validation.

6. Forty-eight hours is only the first cut

In Lawted’s 48 Theory, 48 hours is only the first cut in an enterprise AI transformation.

In 48 hours, find one surface and one point, then establish the first verifiable piece of value evidence with real material.

In 48 days, put the demo into real use and distill employee acceptance, edits, rejection, and exceptions into enterprise Context, Skills, workflows, permissions, and Evals.

In 48 weeks, let validated Agents take on end-to-end tasks and redraw responsibilities, permissions, and risk between humans and AI, ultimately changing the organization itself.

So 48 hours is not delivery, and it does not necessarily mean a formal project has begun.

It is closer to a high-density joint investigation: the company observes whether the FDE deserves trust, while the FDE judges whether the company’s problem, materials, people, and organization deserve further investment.

The two sides are not looking for a grand blueprint. They are looking for one fact small enough to verify, real enough to matter, and strong enough to move the next step.

A company does not begin its AI transformation when the boss first understands AI or when the company first buys model accounts.

It begins when the company verifies an AI result inside its own work and is willing to act on it.

That is the enterprise 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。