照例在春节前夕坐下来回顾过去的一年，落笔写的时候发现脑子里萦绕了很多关于 AI 的事情，也确实我有很多关于 AI 的事情想要记录下来，写在回顾里多少显得有些拘束，不如就单独写下。
从我的体感来说 25 年 AI 的进步飞快，一边是新的模型发布更强的智能，更长的上下文和多模态能力，另一边是以 Claude Code 为首的大量的新的上下文工程范式的落地，AI 解决实际工程问题的能力有了巨大的跨越。虽然 Anthropic 这家公司在价值观中有很强的偏见，但其确实在 AI 工程化范式上提出了很多优秀的实践，MCP，Skill，CLI 的产品形式，确实都推进了 AI 工程化的进程。我也颇为认可 Anthropic 所表述的"代码是通用推理的终极代理"，与之相对应的是我目前认为上下文（Tools）即为 AI 能力的边界。
大概四月份，我开始做 Unreal 的 MCP，其实当时 GitHub 上已经有不少 Unreal MCP 的实现，但我觉得大多都不怎么符合游戏开发实际场景，于是自己又做了一个（大概是重复造轮子的毛病犯了），大概几天就跑通了我预期的基准功能，那时候我认为 AI 能马上落地的场景是：1. AI 提供思路参考；2. 批量任务处理；3. 策划自定义 CI。后面因为工作变动，这些实践搁置了一段时间，到了大概十月份我开始让一些非技术同学尝试使用 Agent + MCP 来解决一些实际工程问题。
得益于 Agent 本身的进步，很多场景问题解决的还不错，但更多的场景，AI 提效并不明显，其中最大的阻碍是为 AI 构造有效的上下文是一件繁琐且困难的事情，要配置哪些工具（MCP），使用什么 Agent，搭配什么样的 Prompt，如何表述问题，这在游戏开发这样一个涉及面极广的场景下就显得更为繁杂。于是我开始推进做一些上下文工程的事情，到目前为止我基本确信，未来一个项目组是否真的能广泛的使用 AI 来提效极大程度的取决于其上下文工程建设的是否良好。在写上下文工程相关的产品需求的时候我在开篇写下："核心目标是让各个职能的同学在各个场景下都有合适的 Agent 使用，让 AI 融入到工作流中"，也不知道在 26 年能达成几分。
这两年我花了不少时间折腾 AI，在折腾过程中思考最多的问题就是：
"AI 是否适合解决这个问题？"
目前为止我大体上有几个观点——
偶然复杂度这个词是我从人月神话中学来的，大体上是指解决一个问题所需要的必要流程是本质复杂度，如算法设计，业务流程，用户体验洞察，而与之相对的使用什么语言实现，使用何种编程框架，使用什么输入法来输入文本则是其偶然复杂度。AI 作为一个全才，它可以在各种形式之中自由转换，各种广泛意义上的"输入"想必都可以通过 AI 大大简化。似乎可以看到未来应该会有很多"生成式 UI"的出现。
AI 和一个工作的适配度目前大体取决于一个工作的校验成本，当一个工作的校验成本远低于其实现成本时，大概率就可以考虑交给 AI 试试，例如编码场景，如果可以通过单元测试判断是否正确的功能，那么 AI 几乎可以完美的完成，如果是需要复杂的测试流程才可以确定的，AI 使用起来则会难受许多。
这里的逻辑是当前 AI 产出很多内容实际上是通过敏捷迭代来完成的，稍微复杂点的工程代码 AI 都很难一次性完成（当然人更不可能），但是如果其产出大量的需要人来校验，人就会成为这一切的瓶颈，如果需要进行一些微调，甚至会出现还不如从头来写的情况。另外一个场景是人对最终结果的质量要求较低，例如产出一些示意图稿，可以接受瑕疵就等于降低了校验成本。
开篇所说的上下文工程即为 AI 能力的边界，如果一个工作其相关的上下文极难构造，则很难通过 AI 来改善工作流。事实上真实工程环境中的很多问题都是这样，例如整理一个排期可能要看散落在五六个系统里的七八篇文档，而且还有更多的信息在人的语言里甚至脑海中。未来应该会有很多产品来尝试解决这些问题，但大概不太能一蹴而就。如此想来飞书这个一开始就主打 All in one 的产品在 AI 时代或许会有更大的优势。
最开始了解 AI 的时候我觉得 AI 最擅长做的可能就是文档工作了，产出各种设计文档，或是总结或是整理，但这两年实践下来，我觉得可能事实是相反的，首先是文档工作的上下文很多时候是难以收集的，尤其是最初的文档，其次文档质量的校验是困难的，因为其没有标准，AI 的自校验通向的往往是似是而非的结果，而哪怕是人来读，想要指出问题也需要经过足够的思考，而最重要的是，真正重要的文档其中所包含的往往是对事物本质复杂度的描绘，这在大部分场景下更是超出了 AI 的上下文边界了。但 AI 确实也还是很擅长文档工作的，输入，润色，解释，翻译，对现在的 AI 来说简直再简单不过。
但以上也只是到现在为止的实践，也许明天就全然不同了。
我大概在 24 年初开始尝试把 AI 融入到自己的工作流中，到年中的时候基于 n8n 构建了自动的邮件、剪藏的摘要服务，开始尝试做一些自动的 RSS 的收集和自动翻译相关的工具，那时候比较明星的产品是 Coze/豆包，Dify，Cursor，我还画了一个自己 Workflow AI 化改造的示意图，希望能有一个产品在未来成为我所有（文本）工作的统一入口，那时候我认为会是豆包。当时我为自己后面可能的 AI 工作流画了一张设计图，很快图中的大部分节点就被淘汰了，但也有一些被保留下来，例如使用 Notion 作为知识中转，使用 n8n 来为我生成自动摘要，那些留下来的大多是直指我实际诉求的部分。
"人不会凭空改变行为，产品真正能做的，是让已有的意图更顺畅的发生。" — Claude 团队某人在其分享中所言
我目前利用 AI 做到的不外如是。
25 年我印象最深的 AI 产品有两个
豆包刚出的时候我就在用了，那时候豆包还是主打和 Coze 的联动，但很快我就放弃了这种产品形态，因为 Coze 本身不够好用，也因为我不太喜欢豆包的客户端，直到有一天我在排队时排在我前面的奶奶给豆包打语音咨询问题。
那个瞬间我印象极深，我虽然知道豆包的产品能力很强，也清楚他在下沉和用户体验上做的很好，但在真的看到他如何解决用户问题时我还是受到了很强的震撼。震撼于我首次如此真切的感受到 AI 早已在改变这个世界，也震撼于我发现下沉对我来说似乎已经只是一个名词了，我已经不再能准确描述其所指代的场景。
这个则比较简单，因为他确实构造了一个极其适合 AI 发挥的形态，通过构造有效的工程范式，让 AI 解决问题的能力有了飞跃。
我记忆中 GPT-3 登场，到 DeepSeek 的 RL 范式，再到 Claude Code 为首的大量工程化落地，是在转瞬之间，但实际上已是三四年的历程。AI 发展的好像很快，但天天看着的时候又觉得还不够快。AI 能解决的问题似乎很多，但真的落地时连如何用 AI 解决问题都还是个问题。
也许 AGI 时代终有一天会到来，
但至少目前在游戏开发的道路上仍需诸君多多指教。