世界杯淘汰赛今天打响。32 支球队，16 场比赛，一路杀到冠军。每年这个时候，朋友圈都会冒出各种预测——章鱼保罗的玄学、球评人的分析、赌徒的赔率。今年多了一种：AI 预测。你可能已经刷到过一些帖子："我问 ChatGPT 谁是冠军""DeepSeek 版世界杯预测出炉"。但绝大部分做法是这样的——打开一个 AI 对话框，输入"预测一下世界杯冠军"，等几十秒，得到一个模棱两可的答案，截图，发朋友圈。说实话，这叫玩票。真正的 AI Native 产品，不是这么做的。上周我用 WorkBuddy 搭了一个完整的"2026 世界杯 AI 分析矩阵"平台。不是打开对话框问一两个问题。而是让 5 个大模型——Hy3、GLM-5.2、MiniMax-M3、Kimi-2.6、DeepSeek-V4——以 5 种不同的分析逻辑，分别对 32 强淘汰赛的 16 场比赛进行比分预测、小组赛 72 场比赛进行胜负复盘，然后按共识投票机制，从 32 强一路级联分析到决赛冠军。全程零人工编码，纯 AI 驱动。从数据采集、模型预测生成、前端页面搭建到移动端适配，所有代码由 AI 生成。做完之后我发现，这个项目最值得聊的不是"AI 预测了谁夺冠"，而是它背后代表了什么。它是一种全新的做产品的方式。所以这篇文章，表面在讲世界杯 AI 预测，实际上想跟你聊聊：AI Native 产品到底怎么做。一、比预测结果更有趣的，是 AI 吵起来了
5 个 AI 模型对 16 场 R32 淘汰赛给出了各自的分析。我设计了一个共识投票机制——哪支球队获得了 3/5 以上的模型支持，就算"强共识晋级"。最终的结果是这样的：R32 晋级名单：South Africa、Brazil、Germany、Netherlands、Ivory Coast、France、Mexico、United States、Australia、Argentina、Colombia、Spain、England、Switzerland、Belgium、Portugal。16 支球队，大部分在意料之内。级联到冠军：R16 强共识晋级 → QF 强共识晋级 → SF：France vs Germany、Argentina vs Spain → 决赛：France vs Argentina → 冠军：Argentina（3/5 模型共识）。因为我把 5 个模型设定成了 5 种完全不同的"人格"：- Hy3 是数据科学家，只看 xG（预期进球）和统计模型；
- MiniMax-M3 是混沌理论家，专门寻找非线性因素；
- Kimi-2.6 是球星观察员，盯着关键球员状态；
- DeepSeek-V4 是历史模式控，用历届世界杯的轨迹做类比。
然后你就看到了一件很有意思的事：AI 们吵起来了。比如 Brazil 打 Japan 这场。Hy3 说"Brazil 近 5 次淘汰赛首轮 4 次零封，碾压局"。GLM-5.2 说"维尼修斯左路内切是全场最致命对位，3-1 稳了"。Kimi-2.6 说"维尼修斯状态如日中天，但三笘薫的爆破能力足以让任何右后卫夜不能寐"。DeepSeek-V4 说"日本 2022 年连克德国西班牙，拖入加时 Brazil 才艰难过关"。然后 MiniMax-M3 说话了。"别管数据了！日本去年 10 月刚以 3-2 真实击败过 Brazil，那种心理优势在淘汰赛就是核武器。巴西防线过去一年被快速反击打穿过 7 次，三笘薫加久保健英的疾风双翼将制造本届世界杯最震撼的冷门！"——预测比分：2-3，Japan 胜。我专门为这种少数派预测设计了一个"爆冷分析"系统。不是简单地把"模型分歧"标注出来，而是引入了一套球队实力分级机制——S 级（夺冠热门）、A 级（实力强队）、B 级（中游）、C 级（弱旅），只有当共识胜者（强队）被少数模型预测输给弱队时，才算真正的"爆冷"。按照这个规则，16 场 R32 中有 9 场存在爆冷分析。MiniMax-M3 成了"爆冷王"，独挑 8 场冷门预测。最夸张的是 Paraguay 对 Germany（B 级对 S 级）和 Austria 对 Spain（B 级对 S 级），它都预测弱队赢——大冷门级别。
这件事让我想起 Anthropic 在最近的《创始人手册》里反复强调的一个观点：AI 的能力上限，不取决于模型本身，取决于你给它提供了什么样的上下文。你怎么组织知识，怎么定义任务边界，怎么让多个 Agent 之间产生差异化输出——这些事情的复杂度和重要性，远超"写一个好 Prompt"。
让 5 个 AI 吵起来，比让 1 个 AI 说正确答案，信息量大了不止 5 倍。二、这个产品是怎么搭出来的
说完了结果，我们来看看这个"AI 分析矩阵"到底是怎么搭出来的。整个项目与AI讨论了37次，AI 完成全部工作。实际的对话过程，包含了大量的需求澄清、方案讨论、技术决策和反复迭代。把这个过程拆开来看，它恰好对应了 AI Native 产品开发的五个关键步骤。很多人上来就问 AI："帮我做一个世界杯预测网站"。AI 会怎么做？它会按自己的理解，搭一个中规中矩的网站出来。配色可能是青色配深色的"AI 默认美学"，内容可能是用自己训练数据里存的世界杯知识做预测。然后你拿到手一看，跟我想要的完全不一样嘛。于是你又开始提修改意见。"这里改一下""那里加个功能"。AI 继续改，你继续提。到最后你会发现，你花在跟 AI 沟通上的时间，比你自己写还多。这就是 Anthropic 在手册里说的那个警告：AI 大幅降低了开发门槛之后，创始人最容易被一件事欺骗，就是把"做出了一个能跑的 Demo"当作"市场验证通过"的铁证。AI 可以做执行，但如果你让它往错误的方向跑，它能跑得又快又好。
所以我做的第一件事，不是让 AI 直接写代码。而是跟 AI 进行了一轮深度的产品讨论——这个平台的目标用户是谁？他们想看什么？什么样的交互体验才是好的？数据从哪里来？5 个模型怎么实现差异化？在 AI Native 的开发哲学里，这叫先画图纸，再让施工队干活。很多人在谈 AI 落地的时候，注意力全在模型上。什么模型最强、参数最多、推理最快。这个预测平台需要的数据有三类：2026 世界杯的真实赛程和对阵关系、72 场小组赛的实际比分结果、以及 16 场淘汰赛的 5 模型预测。前两类通过搜索引擎从公开数据源抓取和结构化。第三类由 WorkBuddy 内置的 5 个大模型根据各自的人格设定生成。这里面有一个很容易被忽视的决策：数据嵌入方式。如果使用 fetch 异步加载 JSON，网页部署后会有跨域问题，还需要一个后端服务器。我选择了在 HTML 构建时把 JSON 数据直接嵌入为 JS 常量——数据量约 500KB，单文件，零依赖，随便扔到哪里都能跑。这个决策看起来很小，但它决定了一个产品的部署复杂度。从"需要服务器、配置域名、处理跨域"变成"一个 HTML 文件搞定"。AI Native 产品的一个核心原则就是：能省掉的环节，一个都不要多。有数据了，怎么展示？这其实是一个很经典的产品设计问题。世界杯淘汰赛的对阵结构是一个 16→8→4→2→1 的树形结构。传统做法是水平展开的 bracket 图——左边 8 场比赛，中间是 R16、QF、SF，右边是决赛。桌面端看着很爽，但手机上完全没法看。我让 AI 设计了一套方案：桌面端保持 9 列横向 bracket；移动端转成 R32 垂直列表 + 折叠面板，后几轮比赛折叠起来，想看哪轮点哪轮。通过 CSS 媒体查询和 JS 检测屏幕宽度，在两种模式之间自动切换。另外还有几个交互细节：共识可视化用绿/黄/红/灰四种颜色区分主队赢/平局/客队赢/分歧；"爆冷分析"按钮用球队分级模型过滤出真正的冷门预测；模型排行榜用小组赛 72 场比赛的真实数据计算准确率。你会发现，这些设计决策跟 AI 本身没有直接关系。它们考验的是产品经理的判断力——什么信息最重要？用户第一眼应该看到什么？怎么组织信息能让用户 3 秒看懂？AI Native 时代，最稀缺的不再是执行力，而是判断力。有了前三步打下的基础——清晰的角色定义、结构化的数据流、明确的交互设计——AI 写代码这件事变得异常高效。HTML/CSS/JavaScript 的代码生成、bug 修复、功能增减，全部通过对话完成。但这里有一个关键操作：不要一次性让 AI 生成整个代码库。我的做法是：先让 AI 搭好架构骨架——HTML 结构、CSS 变量体系、JS 函数模块划分。确认骨架没问题了，再一块一块填充功能。对阵图渲染、弹窗逻辑、组数据面板、排行榜、爆冷过滤、级联预测路径、移动端适配——每次只做一个模块，做完测试，确认没问题再做下一个。Anthropic 在创始人手册里也强调了这个原则：AI 写代码的时候容易累积技术债。架构设计、安全实践、代码审查这些环节，在 AI 快速出稿的过程里容易被跳过。MVP 阶段最重要的不是做到多快，而是搭好一个维护成本低的底子。
一个好的 AI 产品，天然就是内容生产的引擎。这个世界杯分析平台本身就是内容——5 个模型的分析理由、爆冷名单、冠军预测路径、准确率排行榜，每一个都是天然的传播素材。我在设计时就想好了一件事：这个网站上的任何一页内容，都应该可以直接截图变成朋友圈的谈资。爆冷名单卡片上的 🔥 标记、决赛卡片上的 🏆 冠军标注、5 模型对比弹窗里的分析并列——这些不是随便放的，是为了"截图即传播"。从产品第一天起就考虑内容传播，这是 AI Native 产品区别于传统软件的一个重要特征。传统软件追求功能完备，AI Native 产品追求信息密度和传播效率。三、0 人工 Coding 背后的 AI 落地框架讲完了这个项目的具体流程，我们来抽象一下。这套方法可以总结成一个 AI 落地的四层框架：AI 的能力上限，不取决于模型本身，取决于你提供了什么样的上下文。在这个项目里，上下文包括：世界杯的完整对阵数据、球队的 FIFA 实力分级、5 个模型的人格设定、每个模型的分析逻辑参考、赛博朋克暗黑电竞的视觉规范、移动端和桌面端的断点策略。这些不是 Prompt 能解决的。它需要你建立一套知识组织系统——什么东西该让 AI 知道，以什么形式让 AI 获取，在什么阶段让 AI 调用。这正好呼应了 Anthropic 在手册里反复强调的一个概念：上下文工程（Context Engineering）。AI 的能力上限，不取决于模型本身，取决于你给它提供了什么样的上下文。你怎么组织知识，怎么管理记忆，怎么定义任务边界，怎么让多个 Agent 之间不互相踩脚。这些事情的复杂度和重要性，远超"写一个好 Prompt"。
如果你的 AI 只能停在对话层面——回答几个问题、生成一段文本——那它只是一个聊天机器人。要让 AI 真正参与产品构建，它必须具备调取真实数据的能力。在这个项目里，数据流的链路是：搜索引擎抓取真实赛程 → JSON 结构化为比赛数据 → 5 个模型分别生成预测 → 嵌入 HTML 成为静态页面。全程没有人工搬运数据的环节，没有"先从 A 系统导出 Excel，再导入 B 系统"这种人类充当数据管道的操作。中国企业做 AI 落地时最容易被忽视的卡点，不是模型能力不够，是数据流不通。ERP、CRM、OA、数据库、日志系统——一大堆东西摆在那里，AI 根本调不动。系统跟系统之间不通，数据跟数据之间没打通。AI 只能停在聊天那一层，进不了真正的生产系统。这个项目里有一个很重要的实践细节——所有的技术规范，都是作为 AI 的约束条件嵌入到开发上下文里的。比如：球队名称的展示格式是 English（中文）；颜色变量统一使用 CSS 自定义属性（--accent-cyan、--accent-coral）；爆冷判定逻辑必须基于球队分级（S/A/B/C）而非简单的投票比例；预测理由默认完全展开（推理文本较短时折叠反而降低了信息密度）。这些规范不是存在 Wiki 里让人看的，而是直接变成了 AI 生成代码时的约束条件。它们被写进了对话上下文，成为 AI 的"宪法"。每次修改，AI 都会优先遵守这些规范。在更大规模的项目里，这种"规范即代码"的思路可以通过 OpenSpec 这类工具来实现——把架构规范、编码风格、业务规则都写成 AI 可读取的 spec 文件，每次 AI 生成代码前自动拉取最新的规范。确保规范和代码永不脱节。五步流程里，前三步（角色定义、数据流设计、交互设计）消耗了最多的时间和脑力。后两步（AI 生成、内容预埋）反而是执行层面的顺水推舟。这不是偶然的。AI Native 开发的核心规律就是：设计环节前置，执行环节后置。前面多花 10 分钟想清楚，后面省 2 小时返工。传统开发流程是"代码即文档"——需求写个大概，边写边想，代码才是最终的真相。AI Native 开发流程是"文档即仲裁"——需求必须想清楚，设计必须画清楚，AI 只是一个高效的执行者。这就引出了一个更深层的问题：当 AI 能替代绝大部分编码执行的时候，人的核心价值在哪里？答案是：从不写代码的人，变成了指挥 AI 写出正确代码的人。这跟 Anthropic 的说法完全一致。在 AI Native 公司里，工程师的核心竞争力已经悄悄从"写代码"变成了"设计系统、管理 Agent、组织上下文、构建工作流"。四、一些反思：AI Native 不是贴膏药说真的，我看到的市场里，很多人把"AI 转型"理解成了"多装几台电动机"。Anthropic 在《创始人手册》里有一个让我特别受触动的比喻。1880 年代，电力刚进入工厂的时候，大部分工厂做了一件看起来很合理的事——把蒸汽机拆掉，换上电动机。然后继续用原来的皮带传动系统，让一台大电机通过天轴和皮带群把动力传给每一台机器。直到亨利·福特这样的人出现，才想明白一件事：换动力来源不是关键。重新设计整个工厂的物理布局才是。把皮带传动改成每台机器独立驱动，把生产线从按机器类型分组改成按生产流程排列。生产效率直接翻了五倍。那些只换了电动机但保留了皮带传动系统的工厂，全部死掉了。不是因为它们没用电。是因为它们用电的方式错了。你看看现在有多少公司的"AI 转型"，就是买 ChatGPT Team 给全员分发下去，找个 AI 客服机器人接在前端，搞几个自动化脚本处理报表。皮带上多挂了几台新电机，仅此而已。真正的 AI Native，是在拆掉皮带传动系统本身。这个世界杯分析平台本身不是一个多了不起的产品。500KB 的单文件，5 个小时的产物，没有任何商业模式，纯 side project。它是一个完整的 AI Native 产品开发流程的缩影。从需求定义、数据流设计、多 Agent 协作、交互体验、内容传播预埋、到移动端适配，全程由 AI 驱动，人工只做决策和把关。它证明了一件事：一个产品经理 + AI，可以做到过去需要一个团队才能完成的事。而且你会发现，这个流程不是在"用 AI 提效"。效率提升只是一个副产品。真正的变化是生产关系——产品经理不再是把需求写成 PRD 交给工程师，工程师不再是等着 PRD 然后开始写代码，设计师不再是在 Figma 里画完再切图。所有人都在同一个上下文里，跟 AI 一起工作。设计、编码、测试、部署、运营——这些环节的边界在消融。我其实不知道"AI 预测世界杯"这件事的商业价值有多大。它大概率不会变成一门生意。如果你现在不开始练"AI Native"的肌肉，不积累上下文工程的经验，不建立数据和规范驱动的开发习惯，不学会"指挥 AI 而不是被 AI 指挥"——那么当真正的 AI Native 时代来临时，你会发现自己是一个保留了皮带传动系统的工厂。
夜雨聆风
