这篇文章主要讲什么：从一个游戏策划的视角，串起 llm → vibe coding → agent → skill → harness 这条线，再聊到游戏开发，ai native，组织变革，社会影响。写给谁：愿意上手实践 ai 的人，特别是产品，设计，内容，管理岗。本文手工编写后由claude code优化调整。大概 10000 字，30 分钟。
最近半年，我花了大量时间在 ai 上。给团队搭工作流，拉朋友一起做实验，自己也写了一堆 skill 和 harness。我影响了一些人，也被一些人影响。
这是 ai 爆发以来我第一次手打写文章，以前的稿子大多是让 ai 写的。所以这一篇，是用我自己脑子里还没有被 ai 替代掉的部分，整理出的脉络和判断，给同样在尝试的人做参考。
最近发生了什么
简单说：llm 是大脑，agent 给了它手脚，skill 是工作手册，harness 是工作环境。
这一节梳理过去两年大致发生了什么。不一定准确，是我自己经历，感受到的。
llm 时代——大模型作为外脑
llm时代 主要的价值是它自身带来的庞大的知识量，以及它带来的基础逻辑能力。我们尝试使用很多技巧来提升我们对llm使用的能力。
启发式学习
：基于大模型超大的知识量，把大模型当作基础知识库使用。但是使用方法不是直接给出问题，而是基于目标，让大模型给出问题，来扩展你可能不足的知识面。
归纳
（逻辑学之一）：常用但非常消耗精力。让大模型帮我们归纳，寻找问题背后的”真需求”，找到第一性原理。先确定问题，这是非常重要的一步。
推演
（逻辑学之二）：演绎法是另一个重要的逻辑学方法，同样消耗精力。让大模型对已经确定的信息进行推演，过程中讨论我们关注的其他基础问题，从而得出非常有价值的结论，帮我们解决问题。
基于上面这几个方法，在 llm 时代，大模型可以成为我们的外脑，帮我们解决很多问题，给出各种 idea，建议，方案。
这些都是要基于一点，就是大模型逻辑能力的提升。但是这依然是大模型最差的能力，虽然它依然在不断提升中。
vibe coding 时代
很多大模型公司对大模型的代码能力进行了专门的训练，甚至有一些论文认为，因为大量的代码训练，让大模型本身的逻辑能力得到了巨大的提升。代码本身就是抽象度很高的精确的逻辑语言。大家开始大规模的使用llm来写代码，这个过程被称为vibe coding。我也不例外。
大约2年前，我每隔一段时间都会测试一下ai的能力，我每年都会尝试用ai尝试做一些小游戏，以测试ai的能力。大约1.5年前，我用现在被叫作 vibe coding 的方式做了 2 个样例。
可以看得出来这个非常粗制滥造。基本算不上游戏，甚至算不上 demo。几乎只能算个玩具。这些东西大概做了几个小时，就会陷入维护地狱。进一步提高游戏复杂度就会指数型的提升成本。我们还测试了一些非常简单的其他小游戏。诸如塔防，台球。虽然算不上游戏，但是在自然语言编程的情况下，一个可运行的项目，依然给我们大量的惊喜。
大约半年多前，我又尝试了一次。这次效果就提升了很多，甚至可以算得上一个demo了。下面也是大约2天内的工作量完成的demo。
第一个游戏是一个挂机桌面游戏，前后甚至有10来个子系统。带有一些矢量图来优化美术体验。这在我看来是一个巨大的提升。几乎让做独立游戏的门槛大大降低。但是这依然是在vibe coding的领域。
这是 ai 第一次让”想法”和”可运行的代码”之间的距离，短到可以无视。
agent 时代
从对话到执行：精确输出 + 长任务循环
我们不满足于一次对话解决一个小问题，我们希望它能解决更复杂的问题。于是一个非常简单的方法出现了，循环的进行，拆解问题，反复询问进度，要求 llm 继续工作。这在很多 agent 工具中的代码只有几十行，但是构成了 agent 工具的核心。让我们有机会让大模型解决稍微复杂的问题。
这就是 agent 工具最朴素的内核。简单到看一眼源码就能复刻，但是它把”对话”变成了”工作”。
在这之前，llm 虽然已经非常强大，但是依然基本上处于方案给予的层面。我们非常不知足，我们希望大模型可以帮我们做更多的事情，例如”执行”。想要完成执行，就需要衔接程序来执行，就需要非常精确的，稳定的输出，来降低执行本身带来的风险，提高实际可行性。tools 使用的训练为这个带来可能。
随着大模型的逻辑能力和输出稳定性的提升，让它稳定输出 json schema 变成了可能。一旦拥有这个能力，就相当于拥有使用 tools 的能力。这预示着 agent 时代的到来。当大模型可以稳定输出 json schema 之后，我们就可以使用程序读取这部分数据，来执行指令。
最早能执行的指令基本上是基础的文件操作，增删改查。早期的各类 ai 开发工具，比如 Cursor，实际上已经实现了这点，让大模型来增删查改代码文件。随着 tools 能力的提升，它不断扩展自己的能力边界。
从代码到现实世界：bash + mcp
精确输出让大模型有技能可以实现对 bash 指令的精确输出，从而引导程序执行 bash 指令。外加它的文件的增删改查的能力，让大模型可以生成代码，然后通过 bash 指令来执行代码。至此，它几乎可以做任何数字层面的工作。因为几乎所有的数字资产的生产，本质上都是代码的执行。几乎任何我们在电脑上进行的工作，都可以转化为，生产一段代码，然后执行这段代码。至此，大模型拥有了执行能力，就像大脑拥有了手脚。
随着这部分能力的提升，人类还是不够满足。我们发现我们大部分的工作时间，实际上是和特定的软件进行交互工作，office 系列，adobe 系列，等等。它们并不开源，不能直接通过指令来完成，但是大部分工具开放了一些 api，或者是文件系统开放了一些 api，我们可以通过一些桥接程序来完成大模型的指令来操作这些 api。为了让这些能力通用且可插拔，诞生了 MCP（Model Context Protocol，由 Anthropic 在 2024 年 11 月发布的开放协议）的概念。让不同的 agent 遵循同一套规则，就可以操作对应的软件。随着这个概念的普及，大量的软件的 mcp 被开发，分享，大量闭源软件也开始开放接口，或者提供自己的 mcp 来迎接大模型对自己的操作和使用。大模型的能力得到史诗级的提升。至此，我们可以用大模型来帮我们阅读文件，编写文件，编写表格，写程序，执行程序。
到这里，我们把拥有这些能力的程序，叫做 agent 工具。几乎每一家大模型公司都提供了自己的工具，Codex、Claude Code、Gemini CLI，也有第三方或者开源的工具层出不穷，OpenCode、CodeBuddy。agent 工具不是这个时候才诞生，而是这个时候才真正能用，并且从编码扩散到了几乎所有领域。
skill 时代
Skill 是人工作方法的蒸馏。能说清楚的方法论，ai 几乎都能替你做。
skill 本质上是对人工作方法的蒸馏。只要能说清楚方法的部分，都可以以 skill 文档的形式展现出来，它彻底改变了我们的工作方法。方法论以前是一个非常虚幻的词汇，但是在这个阶段，它是一切工作的重中之重，只要能说清楚的方法论，ai 几乎就能帮我们完成。
至此，大模型转化为了 agent，agent 就像脑子拥有了手脚，它已经可以帮我们做大量的工作。对于 ai 的爱好者来说，agent 正在一步一步的吞噬掉我们重复的工作。
我们在使用 agent 工具的时候，每次依然要一遍一遍提需求，说很多重复的话，并且在每个环节都沟通。还是太累啦。于是我们事先准备好一些工作流程文档，存下来，每次执行相同的工作的时候，就把这个文档发给它。文档中告诉大模型，要注意哪些问题，走那些步骤，按照什么样的顺序执行，这就是早期的提示词工程。
但是提示词工程依然很麻烦，我们要手动储存这些文档，手动去发。我们希望 agent 工具能够自己判断什么时候去读什么样的文档。在这个需求下，Skill 诞生了（Anthropic 于 2025 年 10 月正式发布）。
我们准备大量的提示词文档，每个文档都有名称和描述。在 agent 工具中，每次对话的时候，都把我们所有用的文档的名称和描述发过去，让 llm 自己判断是否需要加载对应的文档，这就是 skill。
这样，我们就可以提前准备好大量我们常用的工作流程，工作方法，并且整理命名。当大模型在进行这些工作的时候，发现有需要用的文档，就自主的去阅读（加载到上下文），然后按照方法执行。这就节约了大量的我们的重复劳动，我们只要说明目标，它就可以按照需求执行。
skill 的概念是非常简单的，但是理念是非常先进的。引发了所有 ai 爱好者的思考，让我们尝试尽可能的整理我们的工作方法变成文档，就像很多公司有的 km（知识管理），它其实和我们培训新人的方法非常相似。让我们和 ai 沟通，实际上就像是在教一个新人工作方法。
llm 是大脑，agent 工具是身体，而 skill 是工作手册。至此，我们可以让大模型按照我们自己的思路执行很多工作。
但是我们发现，依然有大量无法完成的，说不清楚的工作。例如蓝色好，还是红色好，是赛博朋克好，还是中世纪好。在没有足够多上下文和方法的指导下，这些问题依然要人类来完成。这部分，我们叫做”审美”注入。没错，”审美”这个词被提高到一个无比高的角度。甚至可能是人对比 ai 最后的留守地。
你那独特的 xp，可能是你这个人最有价值的部分。
Skill 归属：我的灵魂值多少钱？
这个时代的冲击非常大，舆论也非常多，诞生了很多冲突。诸如，我的 skill 是属于公司，还是属于个人，公司能不能要求我上交 skill 文件？我把我的工作方法都写成 skill 之后，公司是不是就可以把我开除？我的个人价值是什么？skill 代表着我的灵魂，公司应该出多少钱来购买我的灵魂？
同时，这部分也会诞生对人才的重新思考。什么样的人能够足够好的把自己的 skill 写清楚来引导 ai 工作？这种人应该具备什么能力？这些人是不是价值被大量的放大了，是不是应该升职加薪？这些我们后面再讨论。但是直接影响的，就是大量的执行岗位的裁员。因为越是重复工作，就越可以被 ai 替代。总之，skill 时代到来了。
harness 时代
harness 没有通用解。每个项目都得自己搭脚手架，这就是它最难的地方。
我前面说到，人类的懒惰推动着科技的进步。到了 skill 这个大爆发的时代之后，人类还是不可能满足。人们在思考一个问题，如果有足够多的 skill，是不是 ai 就可以独立完成一个非常复杂的工作？我们是否可以把整个项目，都以 skill 的方式写出来，让 ai 独立完成整个项目的开发，比如做完一整款独立游戏？
非常多人发起了尝试，我也不例外。此外我拉动了很多朋友做这方面的尝试，哪怕到今天，我们依然在尝试这部分的事情。但是我们遇到了非常多的问题。我们遇到了很多边界。
我们发现 llm 虽然拥有无人能比的知识面，但是它依然有幻觉。逻辑能力不断增强，但是依然比不过人类的智力水平。强大到可以整本书阅读，但是上下文依然不够解决最复杂的问题。
我们给 agent 提供了大量的 tools，skill，非常多的上下文，为了让它按照我们理想的方式工作，很快就遇到了上下文瓶颈。前面的 200k，现在的 1m，依然不够我们这些贪心的人类使用。如何管理上下文，就变得非常复杂。一个至关重要的理念被提出。
渐进式披露
这是为了解决上下文这种稀缺的资源的问题，我们不能一次性加载太多的内容，而是尽可能的把llm当前最需要的信息提供给它。这几乎就是提示词工程最重要的事情。为了解决这个问题人类做了很多很多工作。
subagent
首先被想到的方法是，使用子 agent 来解决。如果一个主 agent 解决不了的问题，我们能不能给 llm 进行分工，就像人类一样工作。我们不能指望老板一个人解决所有问题，我们希望老板把工作层层拆解，交给下属去执行，子 agent 不行，再拆解交给子 agent，层层嵌套，来解决上下文不足的问题。
我经常举的例子是，给你无数个大学生，但是这些大学生每 5 个小时就会失忆，你有机会用他们来盖一座摩天大楼么？你应该如何组织这些大学生工作？
采用 subagent 甚至还顺手得到了一个非常好的次级优势，就是 subagent 是可以并发的，甚至可以提高执行效率。这个方法非常有效，很快就被各种 agent 工具采用，到今天，它基本变成了基础建设。但是这依然不够。
知识库建设
我们在进行复杂的项目开发的时候，很多时候有很多重要的前置信息，我们要想办法在合适的时候把这些前置的信息传递给 agent，让它保持工作上的一致性。我们可能要建立庞大的知识库，把这个项目已经存在的，信息，方法进行传递。目前采用的方法是建立向量数据库，rag，通过语义搜索，来给 agent 提供信息。但是这个过程很麻烦，因为首先准备数据库就很麻烦。如果你恰好项目有足够的规范的文档积累，你就可以开心一下，但是你依然要小心你的文档的时效性，准确性。
随着知识库建设的另一个领域也就出现了，记忆系统。记忆系统的难点在于判断什么信息应该存储，什么信息应该读取，应该在什么时候读取，这部分甚至到现在还没有成熟的解决方案。OpenClaw、Hermes 这些项目，都是因为有了记忆系统，看起来像是有了生机活过来啦。但是最熟悉 ai 的朋友还是很清楚，依然不够好用，依然需要持续探索。
harness 工程
当我们拥有了一大堆 tools，subagent，skills，rag，我们还要教会 ai 去开发一个项目，我们要思考的最重要的就是，什么部分应该人介入，什么部分应该相信 agent，什么部分应该需要验收。这个问题就变得非常困难。因为现在我们在开发的复杂项目，人类做的都不足够好，可以说，人类也没有找出最佳实践，怎么让 ai 来做？到这个层面，我们进入了最复杂的项目问题解决。至此，我们把这个东西叫做 harness 工程。
harness 原意是挽具/马具（套在马身上拉车的整套装置），在工程语境里也常被叫作脚手架/运行环境，在这里抽象的表达是为 agent 工作提供一切必要的工作环境，runtime。harness 这个词很抽象，不过很正常，ai 领域的很多东西都是新的，vibe coding 也很抽象，我们很难从以前有的词汇表达清楚现在在做什么。
这个时候，我们就开始思考基于当前项目，我们到底有哪些重复工作，哪些审美工作，哪些重要，哪些不重要。每个项目都完全不同，harness 的重点千差万别，几乎无法找到真正共用的东西。harness 就很难成为通用工具，它更像是一个”样板房”，给其他项目做参考，但是每个项目都要建立自己的 harness。
但是在这个环境下，想要逻辑清晰的把 harness 构建起来，本身就是一个复杂的系统工程，难度就很高。很多情况下，我们构建 harness 的效率甚至不如直接开发，很容易陷入非常虚无的方法和哲学讨论中去，这部分依然没有准确的答案。
model 派说：模型还在指数级变强，等下一代出来，你今天搭的 harness 全是技术债，模型自己就可以解决了。
harness 派说：模型再强也需要环境，就像再聪明的工人也需要工具和工位。harness 和模型不冲突，是乘法关系，任何时候 harness 都能对大模型有效的增强。
我自己偏 harness 派，但是保持 model 派的警觉。我对这个东西的思考就是优先解决当前，或者即将遇到的问题，不要追求完美的框架，世界变化太快了，先把 ROI 为正的干了。除非你有非常长期的规划，或者有足够的坚信，那就按照你相信的试试。都是在猜测未来，做自己相信的事情就好。
游戏开发和 ai
我是一个游戏从业者，游戏策划。我对 ai 的所有思考和应用，都是基于游戏开发的。所以这一章来聊游戏开发中对 ai 的使用。
游戏是一个非常复杂的工程，涉及多个部门，每个部门对 ai 的使用都不太相同。我们从主要的职能来聊。
程序。ai 最早影响的是程序，vibe coding 也是最早出现的概念，所以程序的 ai 覆盖度极高。llm 几乎是为代码训练的，对程序最为友好，早期工具都面向程序。程序几乎只用到一个东西，就是 spec，定义项目开发规范，编码规范，把规范定清楚，给 llm 的输出方式束缚下来，效果就很好。服务器代码基本能完成得不错，但是客户端代码靠视觉验收，llm 对时间和空间的理解还不够，所以更麻烦，不同 llm 写出来的界面有些就是很丑，似乎都没有很好的方法。我觉得这个问题可能要在更前面的环节解决，在 ui 环节，甚至在策划环节解决。
策划。策划早期对 llm 的使用几乎是停留在 idea 支持和知识查询，agent 工具爆发之后，又陷入了各类执行，诸如填表，做 ppt 的活。但是真正的难点，是策划的设计方法，游戏策划被认为是创意要求最高的序列，大家对 llm 完全解决创意问题是不够有信心的，但是 ai 也在这个领域大规模的覆盖，虽然有很多讲不清楚的方法，但是能讲清楚的部分依然不断的在增多。游戏设计本身就没有成熟的方法论，是一个失败率极高的领域，而不同的策划对于游戏的理解完全不同，认知，看法方向也不同，互相也不一定认可，这部分很难统一。
每一个策划都有自己的 harness 工程。这就是为什么策划比程序更难被 ai 替代：没有统一的方法论可以蒸馏。
但是实际上创意的设计只是一部分。大部分的执行工作在被广泛的代替，执行的效率成倍的提高。
美术。美术领域是最困难的。美术工具链重度且复杂，往往是大型闭源工具，美术工种很多时候靠直觉和审美，无法系统讲清楚自己的设计方法，agent 的覆盖最为困难。而且美术资产种类繁多，每个资产领域几乎都要单独的大模型，做图片要图片模型，做模型要模型的模型，做动作，特效等甚至没有什么成熟的模型（有些有，没有真正行业的广泛运用），这些单独的模型，我们叫做资产模型。好在最近资产模型的迭代是很快的，持续的给出惊喜，我相信不远的未来，美术的 ai 覆盖率也会持续提高。
qa。qa 是非常重要的领域，qa 其实是两部分，一部分是自动化测试，通过单元测试，让 ai 写大量的测试代码来执行，一部分是让 agent 模拟人工操作，来进行测试。但是 agent 没有游戏体验感受，所以只能做最兜底的 bug 类测试。
但是 qa 真正的问题是，不敢只让 ai 测试。不管 ai 测试的多好，总要有人工审核，也就是真正的验收环节，是不敢交给 ai 的，未来也许可以。
ai 不能帮你背锅，不能帮你坐牢。
这才是 ai 落地的真正天花板：问责权属。再准确的 ai 测试，也得有人签字负责。所以 qa 的工作依然是繁重的，甚至是整个链路最难的，ai 只能不断提高 qa 的质量，但是不太能减少 qa 的时间。我们甚至得出来一些悲观的预期，就是未来最好的测试可能还是用先遣服的方式，或者灰度，交给玩家测试。
tdd 和 sdd
人最重要的工作是首尾——定需求，做验收。中间交给 ai。
我对 tdd 和 sdd 也有过思考，为什么这两个重要？因为这两个环节，一个是需求环节，一个是验收环节，是无法离开人类的环节。人类尽可能的要把人类工作的部分前置，不要让人来等 ai，可以让 ai 等人。人的工作时间是更宝贵的，所以人最重要的工作是首尾。
讨论完游戏开发过程中 ai 的运用后，我们就得到了这两个非常重要的概念，tdd 和 sdd。这两个概念几乎是贯穿我们的工作全部环节。TDD 是 Test-Driven Development（测试驱动开发），SDD 是 Spec-Driven Development（规范驱动开发），就是测试和规范。我们在所有的开发环节要求，规范和测试先行，没有 spec 就不要开发，没有测试，就不能验收。只有做好这两个部分，我们才敢让 ai 真正的落地到项目。但是这两个理念是一个理解起来容易，执行起来非常复杂的事情。要把对它们的认知和思考刻入骨子里，当作自己的 ai 工作法则。
ai 原生游戏
随着ai的发展，我们越来越多的工作使用ai执行，很快我们就遇到一个问题，我们是否可以把游戏内容在游戏运行时生成，是否直接基于ai来设计一款游戏？这个答案很显然是成立的。
基于大模型生产内容，基于大模型创造新的游戏规则。基于大模型创造新的游戏体验。我是否可以在游戏中实时设计我的服装， 我的地图，游戏世界？当然是可以的，这里其实我做了很多思考，但是需要另起一篇了。但是总结下来可能还是就那几个俗套的关键词：
千人千面
万物有灵
：游戏中的很多npc，元素，物品，都可以拥有灵魂，给出情感体验。
无限世界
但是我们做ai原生游戏，要考虑到ai的发展速度和情况，我们对于未来的ai的逻辑，资产质量，速度，都有乐观的预期，但是要基于价格，时间，体验，设计商业化匹配的游戏，这个任务依然是艰巨的。我相信ai游戏一定会颠覆游戏体验，但是能不能赚到钱，哪一款能最先赚到钱，我是不知道的。
ai native
在经过这些事情之后，ai native 这个词就经常出现在视野中。什么是 ai native，其实就是让我们抛弃原来的路径依赖，完全重新思考，在 ai 时代，我们应该怎么做这个事情。有很多 ai native 的案例出现。
文件的 ai native
我们的文件，现在的主要的阅读者变成了 ai，而不是人类，所以要找一个 ai 和人类都好读的文件，甚至是 ai 优先。那 md 文件这时候就变成了宠儿。而那些复杂的，ai 不方便阅读，不方便生产的文件，都变成了落后生产力。我经常说，ai 时代，office 系列都是垃圾，什么 figma 都是落后生产力——不是说 ai 完全读不进写不出，而是它们的接口不够开放，操作起来很不方便，远不如纯文本和开放格式直接。虽然我们以往有太多重资产依赖于这些文件，但是未来它们都会被淘汰。其实就是不够 native。
工具的 ai native
人类的发展其实就是工具的发展。我们大量的软件，如果没有提供足够多的 api，或者 mcp，cli 来给 agent 使用，这些工具在 ai 时代就是不够好用，我们就会寻找替代工具，那这些工具就不够 ai native。有个典型的例子，我其实是 notion 的深度用户，它很努力的提供了很多 ai 工具，提供了 mcp，但是对于 ai 来说，依然不够方便，我就快速的转向了 obsidian。ai 工作需要复杂的版本管理，svn 的方式就不够 native，那我们就尽可能转向 git。ppt 至今没有足够多的接口，我们直接使用 html 来实现模拟演示，很方便。
工作习惯的 ai native
你的工作还有多少是通过操作工具，软件，来执行，有多少直接通过 agent 来执行？你下载一个文件，是自己去网页寻找么？你进行一个操作，是去搜索引擎搜索么？都可以交给 agent 工具来执行，可以 all in one。甚至我觉得未来，社交，工具，娱乐，都应该使用 agent 来执行。
组织的 ai native
其实在这个 ai 时代，企业的架构，组织的方式是否应该调整，是否有很多岗位根本不应该存在，我们是否应该向 agent 回报？数据全部打通之后，是否可以更简单的项目管理？隐私，项目，个人的边界，权限管理在哪里，都值得思考。但是企业架构有巨大的组织惯性，所有的既得利益者都会阻止这个事情发生，从长期来说是毫无意义的。匹配 ai native 的组织架构是怎样的？我们也不知道。那是老板应该思考的问题。你们在这个时代，如何管理员工？或者是？不需要员工？
agent 即服务
如果我们可以实时生成游戏内容，那么我们也就可以实时生成几乎所有的用户体验。我们日常所有的线上服务，都可以使用 agent 进行重构。
以”刷短视频”为例。现在的抖音 b 站，是平台决定推什么，你被动消费。agent 即服务版本是什么样？甚至不一定是你告诉 agent 你今晚想看什么，而是 agent 根据你最近的工作状态，作息，情绪，主动给你提建议。它知道你这周加班太多，知道你最近在追的题材，知道你睡前 30 分钟刷视频是为了放松，于是它跨平台帮你抓取，甚至生成定制的内容流。
你甚至不需要主动提需求，agent 已经基于你的综合数据知道你想要什么。在这种重构下，平台从内容方变成了原料方。
agent 工具是否可以提供实时渲染的可视化界面，当然是可以的，我们是否可以使用 agent 工具来完成音乐播放，当然可以，是否可以使用 agent 工具来刷短视频，当然可以的，是否可以使用 agent 工具来购物（千问已经有），是否可以使用 agent 工具来启动游戏，甚至实时生成游戏？是否可以使用 agent 工具来浏览新闻？是否可以使用 agent 工具来社交沟通？我认为都是可以的而且可以提供更好的服务。
在这个阶段，agent 即服务，任何服务都可以使用 agent 重构。
在这个环境下，我们只需要重新思考一个问题，人，agent，system（代码实现的软件服务），应该以什么样的全新方式去服务？
终极愿景
当agent即服务已经完成之后，未来的世界是什么样的？
会有一个或者多个平台来提供基础agent服务，其他的所有服务，都可以”以skill的方式”提供服务，我们将会在同一个agent平台，完成我们所有的线上需求，那是一个比互联网更加丰富的ai时代。这个构想很像是 OpenClaw 的终极版本。每个人都有一个私人ai助理，而这个ai助理，将会为你提供一切服务。人人都会拥有自己的贾维斯，我们通过贾维斯来实现我们所有的服务。
甚至这个未来将会很快到来。我看到很多企业正在提供这样的服务，把自己的 服务，向agent开放。
而这个平台，也不一定依托于硬件，当我们只想听音乐的时候，耳机就是那个agent，当我们想要看视频，那眼镜，显示器就提供服务，一个不依赖硬件，不依赖场景，只有一个帐号，在所有的场景，所有的硬件上运行，这就是未来的agent os。基于云服务，llm服务的，all in one的agent平台。 我很期待这一天的到来。
ai 生态问题
很显然，电力和芯片公司将会成为最上层的基建，然后是大模型公司，然后是agent平台公司，然后是众多的服务公司。
所有的公司都应该思考，面向这样的未来，如何准备好，提供这样的服务。如何在这个愿景下，更好的服务。或者说，在这个终极愿景下，如何找到自己的生态，持续的赚钱。
基于这样的愿景，大模型公司依然会创造最大的价值，持续的投入，就是找到未来的钥匙。而如何建立agent平台，就是最终面向用户的方法，就是流量入口。所以面向 C 端的超级 agent 平台（如豆包、元宝）极有可能是最终的流量入口。
人才问题
未来将会很快到来，我们这些牛马，应该做好什么样的准备来适应这个未来？
首先，我们要主动的拥抱 ai，学习 ai。这就要求很强的主动学习能力，背后是自驱力。每周花几个小时 follow ai 进展，不是负担，是基本功。
然后是工程能力。没有工程能力，你就无法教会 ai 帮自己做事情。能把模糊需求拆成 spec，能调试 agent 的行为，能搭自己的 harness，这是上一代不需要，但是 ai 时代必须要的新通用技能。
然后是审美。审美可能最后也会被替代掉，但是可能是最晚被替代掉的能力，成为领域的审美大师，可能是未来最值钱的部分之一。在 ai 输出无限的世界里，”选对”比”做出来”更值钱。
ai 会重新洗牌企业对人才的要求，改变这部分能力是这个阶段获得高薪的弯道超车。企业如何快速建立对新型人才的招聘方式，奖惩规则，将是企业最重要的课题之一。
组织问题
ai不只是会调整对人才的需求，而且会彻底改变组织的运作方式。如何改变组织架构，重新创建ai native 组织是非常非常困难的事情，将会改变很多人的利益，一定会迎来企业阵痛，但是这个阵痛在历史的潮流下，会被逐步淹没。如何建立ai native的组织我不知道，但是肯定要完全忘掉以前的组织结构，给足够 ai native 的人足够多尝试的机会。生产力将会告诉大家，什么样的组织是ai native的。但是如果依赖当前的组织形式，肯定是会低效，被时代淘汰。
社会问题
这是最后一个问题了。ai 改变了生产力，生产力改变了生产关系，那就会重塑社会结构。贫富差距将会进一步拉大，更少的人可以完成更多的工作。会不会进一步的造成新的失业潮，引起社会稳定风险，这是政府应该考虑的事情。
但是我们看历史。每一次科技革命都引发过同样的恐慌。蒸汽机让手工业者失业，但是诞生了产业工人；电力让油灯产业消失，但是诞生了整个现代电气和家电产业；互联网让报纸式微，但是创造了我们今天大部分的新职业。从历史的潮流下，这是无法阻挡的。
ai 时代会消失的岗位，大概率是大量的执行型工作。客服，初级文员，基础设计，初级编码，重复性内容生产，这些岗位的消失会非常快。新出现的职业现在还没法准确命名，但是大概率是 skill 工程师，agent 训练师，ai 审美总监，ai 伦理审查官，这一类。
政府要做的事情也会更复杂。教育系统要重构，从教知识转向教方法和审美。再就业培训要跟上，但是培训速度大概率追不上替代速度。可能要讨论 ubi（无条件基本收入），讨论 ai 税，讨论新的劳工保护制度。新的行政方式，新的社会政策，会随之诞生。
但是说到底，这些都是宏观叙事。对个人来说，最重要的还是先把自己的位置搞清楚：你在食物链的哪一层，你最不可被替代的部分是什么，你为这个未来准备好了多少。
我没法回答你的所有问题。但是有几个问题，你最好今晚想想：
我的工作里，哪 30% 可以马上写成 skill？
夜雨聆风
