【GDC 2026】天美登月项目 - 可微LLM
来源：D:\GDC2026 - 天美登月项目 - 可微LLM.mp4
提取时间：2026-03-26 13:20:03
从你提供的信息来看，构建可微分AI系统的核心在于实现连续性和可控性的结合，以解决当前大模型在处理长队列任务时遇到的挑战。以下是几个关键点和建议：
- 全局视角与数据可微：
- 为了克服传统方法中的不平滑性问题，需要建立一个全局视角的数据结构来捕捉复杂的工程信息。
- 树图异构体系可以有效地将项目知识层级化，并通过跨领域的关联表达复杂关系。这种架构能够提供实时的、原子化的数据感知能力。
- 流程可微：
- 采用范式化的内部数据结构，确保每个步骤都具有明确的操作定义。
- 引入微操级控制机制，使得AI在执行任务时可以进行细粒度调整和优化。
- 确保状态的连续性和可复用性，通过这种方式来实现端到端的任务自动化。
- 感知闭环与实时反馈：
- 为AI系统设计一套极致的工程预警机制，使其能够实时洞察代码执行后的连锁反应。这种能力类似于人类手指接触火柴时对张力和压力的即时感知。
- 构建每一步操作的感知闭环，确保在任务执行过程中可以及时调整策略。
- 可微分AI的核心理念：
- 通过引入“可微”的概念来实现系统的连续性和可控性。这不仅要求系统是连贯的（没有断崖），还意味着其变化方向是可以预测和控制的。
- 在工程实践中，这意味着要建立一套能够追踪、校正并优化任务过程的数据结构与算法。
- 技术实现细节：
- 采用超领悟技术和流程可微机制来确保系统的稳定性和有效性。这包括符号级精准捕获、跨代码库和资产库的深度关联以及执行过程中的绝对追溯性。
- 开发一套高度工程化的体系，以跳出振动编码效率陷阱，并为AI系统提供远超过简单模型累加的能力。
- 行业应用与生态集成：
- 通过兼容MCP等实操工具接入点，无缝整合外部生态系统资源，进一步增强代理能力。这有助于推动整个行业的技术进步。
- 持续进化与适应性学习：
- 基于项目架构约束和质量标准的自然选择机制来优化AI决策过程，并积累领域经验以实现真正的自主创造工具。
综上所述，构建可微分AI系统的关键在于通过全局视角、实时反馈以及高度工程化的体系设计，确保任务执行过程中连续性和可控性的结合。这不仅能够解决现有技术面临的挑战，还能为未来的复杂业务场景提供强大的支持能力。
Slide 1 — 00:00:00
📌 要点汇总
- （过渡内容，无关键要点）
为了让现场达到更好的视觉效果，我们本次演讲采用了AI语音增强技术。很高兴今天能在GDC的现场和大家分享。我来自腾讯游戏天美工作室，我的名字是木谦，专家级工程师。很高兴和大家认识。
今天的分享是由我和我的搭档玉一起完成的。他是我们工作室的客户端主程，在这个项目上，我们并肩走过了整个研发历程。但就在来GDC的前几天，因为工作上的临时变动，他未能到场。成果里有他同样重要的贡献。今天我代表他和大家分享。虽然遗憾一些，但只剩下我一个人了。
那我就只能愉快地享受这个机会了。让我们开始吧。先做一个很简单的小互动。现场有没有大型项目或直播Up的朋友？如果有，请举一下手。谢谢。
我想分享一个我们在游戏研发里都非常熟悉，也越来越尖锐的问题：生产效率在提升，但创意验证却越来越慢。研发的复杂度让我们陷入修复师的日常。如何让技术服务想法，把时间留给创意？
今天我们将分享一种全新的AI驱动的游戏实践方案，以加速复杂的大型游戏开发工程——可微分智能。今天的内容分为四个部分。
首先，我们来看看AI浪潮下游戏行业的瓶颈和突破口。AI带来了效率的大幅提升，但大家越做大项目，越会发现效率很容易失速。
第二部分是可微智能的原理，我们会从信息论的视角出发，解释为什么传统的RAG和Web编码在复杂工程中必然失控，以及可微智能是如何从根本上解决这个问题的。
第三部分，我们会深入到可微智能的具体技术实现，包括超感知、上下文感知、符号化以及树图架构等核心技术的工程实践。
最后，也是最精彩的部分。项目实战与案例，我们将展示Ignis平台是如何在真实的UE项目中实现的，从策划案输入一直到可运行成品。这里会有一个完整的演示，包括实验和第二个期待。
Slide 2 — 00:03:14
📌 要点汇总
- （过渡内容，无关键要点）
在第一章，我们先来聊聊大家每天都会面临的具体问题，以及在AI的大浪潮下，我们的行业正在经历哪些变化。
\n\n
接下来，我会简要介绍一些关键的技术趋势和挑战，这些内容对于理解当前的行业发展至关重要。\n\n
首先，我们会讨论深度学习模型的发展及其对各个领域的影响。随着计算能力的提升和数据量的增长，深度学习技术取得了显著的进步，并且在图像识别、自然语言处理等领域展现出了巨大的潜力。
\n\n
其次，我们将探讨如何利用这些先进的AI工具来解决实际问题，包括但不限于自动化流程优化、智能决策支持系统等应用案例。通过具体实例分析，希望能够帮助大家更好地理解AI技术的实际应用场景及其带来的价值。\n\n
最后，在这一部分中，我们还会讨论一些当前面临的挑战和未来的发展方向，比如模型的可解释性、数据隐私保护等问题，并展望未来的趋势和技术突破点。
（注：此处为分段示例，实际处理时应删除此行及以下内容）
Slide 3 — 00:03:29
📌 要点汇总
- 研发效率跟不上创意验证速度
- 团队规模扩大导致沟通成本上升，开发效率下降
- 高复杂度代码拖累创新和迭代
- AIGC技术压缩研发周期87%，降低bug修复成本20%
- AI接管逻辑开发面临理解偏差、文件破坏等问题
- AI编码关键问题：记忆断裂、需求定位不准、幻觉编造、死锁循环
看看这几张图，想的朋友都会心一笑：层层洼地的深度调试、缠成毛线团的逻辑，以及高度耦合的资产与系统，这完美印证了我们码农界的那句话祖训：“面对一个如山的屎山代码，只要绝对别碰它，就动一线。整个工程都可能轰然倒塔。”然而，在深入的游戏开发周期中，我们又不得不触碰它。
从前面的立项、垂直切片，到中后期的内容量产，再到测试发布，越往后拉扯我们。在项目初期，迭代速度极快，但随着系统越来越庞杂，持续集成循环变得无比沉重。任何一个小事都牵动全身。脑暴提出了一个创意只需一分钟，但要走完技术制作、功能开发，最终直到集成主干，却要花去甚至几周的时间。这就导致了我们目前前进的最大困局，也是最核心的关键瓶颈：我们的研发效率早已经追不上创意者的验证速度。
在这道深不见底的数字深渊面前，传统的堆人力和普通工程化手段已经无休止力。借这个机会做个小互动，在座各位没有人所在的团队规模超过了五百人？有的话请举手。看来有问题，谢谢。接下来，我给大家看几组关键数据。
过去的十年，核心团队规模膨胀了几十倍。当团队规模达到这个级别时，团队会立即陷入“人越多神话”陷阱，沟通呈指数级上升，开发效率急剧下降。随后而来的研发和成本飙升了近十倍。第一篇三项大型作业动量接近数亿美元的人口，意味着任何……和项目的失败都是整个工作室无法承受的。
除了财务压力，更可怕的是我们的时间分配。现在，为了团队没完没了的一天一补丁和线上事故，团队往往要耗费七十精力在维护和修改bug上，剩下可怜的三十能用来试错创新。这是因为游戏的逻辑代码规模已经到了几千行，甚至上亿级别。这让我们得出一个沉痛的结论：高度复杂的设计不仅让开发者沦为了修复大师，而这迭代与耦合的迷宫也终将拖垮创意的光芒。
信任浪潮来了，大幅尖锐的从业者正在尝试通过AI寻找逃生舱。AIGC对艺术资产的阶层已经跨越了临界点，核心价值即将把整个项目的研发周期压缩百分之八十七，这让工业化量产真正成为了现实。更核心的危机发生在Vibe编码领域的大家，Roblox 的开发者们让 UGC 增量飙升了百分之三十一，在 Triple A 的项目中节省了百分之二十的 bug 修复成本。
代码不再是阻滞创意的围墙，而是加速创意的燃料。而在 Vibe Gaming 模式下，AI 直接接管了逻辑开发。可以看右边的《Dota》2 和《暗黑破坏神》的演示，虽然还是早期的创意原型阶段，但是言出法随的说法，复杂的游戏设定和技巧逻辑才能精准实现。
我们将这种模式总结为三个核心价值：尖端创意表达节点代码语法，分钟级搭建原型，快速验证玩法。这才是技术平权的终极形态。刚才我们还在感叹Vibe编码的膨胀，但是在广大开发者的实际体验中，也真切切地普及了它在现阶段的巨大困境。大家看到这些来自开发者社区的真实反馈，很多同行应该都深有体会。
由于AI在理解时常放飞自我，导致它经常改错文件、删除关键代码，或者编造完全不掉的函数，给我们带来无尽的烦恼。正如谷歌工程主管Eddie Osmani说：“现在的AI工具往往能让人觉得他很快完成了百分之七十的工作，但为了修复他在最后百分之三十里埋下的困扰，你可能要花上双倍的时间。”这让我们陷入了痛苦的后退两步循环。
你发现一个bug让AI去修改，它不仅没修好，反而破坏了系统其他模块，导致你一整天都在处理由于引发修改的连锁反应新问题。虽然后来提出了很多增强方案，比如规范驱动、技能、技巧等，但面对复杂的三级游戏工程，如果你不具备深入的领域知识，仅仅依靠语言无脑氛围，后果往往是灾难性的。
归根结底，氛围编码翻车的关键有四点：第一是长上下文导致记忆断裂；第二是需求迫切，AI无法精准定位复杂谜题；第三是严重的幻觉编造；第四是复杂任务容易陷入死锁循环。这些问题使得传统的交互模式在重工业开发中举步维艰。
Slide 4 — 00:10:14
📌 要点汇总
- 行业误区：认为AI进步仅依赖模型能力和工具链丰富
- 简单场景下AI表现良好，复杂工程中面临挑战
- 复杂项目存在海量上下文依赖、信息孤岛和高度耦合问题
- AI难以理解跨系统数据关联，优化一处可能引发级联故障
在我们深入分析中，我想先破一个行业的认知误区：大家都习惯把AI的进步归结为模型能力的增强和外围工具链的丰富，好像只要给AI装上足够多的工具能力，它就能无所不能。但真的是这样吗？看这段演示，不知道在座有没有玩过Varebier工作室出品的著名物理俄罗斯方块游戏Tricky塔？
左边是轻量级的开发场景，就像经典的俄罗斯方块，地基加固，规则明确。在这种简单的下游环境中，AI就像在这里搭积木一样轻松，无论模型大小如何都能应对自如。
但请看右边的大型复杂工程，它好像加入了严苛的物理引擎，不仅地基在摇晃，重心同时偏移。你给AI装上一百个、一千个执行工具，如果它看不见脚下那些缝隙，建得再高，也终归轰然倒伏。
那到底是什么让重工业项目的地基这么摇晃？第一，海量的上下文依赖。真实的项目动辄将近千万行代码和十几年技术债，核心逻辑往往不在代码里，而是在策划的头脑里或早期的会议记录中。这种深度的复杂度甚至突破了AI的理解能力。
第二，信息孤岛，在AAA工程中，C++管底层，Lua写业务，蓝图连表现，Excel填数值。AI目前的视角极窄，只能看到代码碎片，却无法理解这些数据之间隐秘的关联。一旦面临跨系统调试，AI就像盲人摸象，根本无法形成全局的认知。
第三，也是最要命的，高度耦合引入的级联雪崩效应。系统之间就像蜘蛛网一样牵扯，你让AI优化一个战斗循环，它为了修复报错可能顺手改了底层接口，直接干崩了远程的网络模块。
所以，AI到底会在这片危机四伏的废墟上接得地绝妙吗？这就是我们下一步要解决的核心命题。
Slide 5 — 00:13:07
📌 要点汇总
- 大型项目管理复杂，难以全局理解
- 深度任务拆解导致错误率上升
- 商业成本限制单次执行步长，影响连贯性
- 技术快速迭代使预训练模型缺乏收敛性
- AI在复杂场景中盲目猜测路径，重复造轮子
- 人类成为代码质检员，创造力受限
- 目标是实现可信自治，让AI负责底层执行和纠错
- 人类定义战略和约束，从质检员跃迁为架构决策者
为什么最先进的大语言模型在面对游戏工业化研发时会面临重重困境呢？我们总结了它的四大痛点：
第一，庞大的项目体量导致内部管理极度复杂，即使AI也难以全局理解，并容易违反设计模式。
第二，大型任务需要极其深的拆解。但多步拆解会导致错误率不断上升，成功率急剧下降。
第三，出于商业和成本安全性的考虑，我们被迫限制了单次执行的步长，这又与复杂任务的连贯性产生了深刻的矛盾。
第四，预训练模型在技术快速迭代的领域中存在明显差异，导致方案缺乏收敛性。这四大痛点一体，催生了正确性和安全性警报。在这里，AI开始盲目猜测路径，重复造轮子，甚至缺少边界误删核心资产，导致灾难性的事故。
这个黑洞，我们必须逐步前进。现阶段，所有上产线的Vibe编码结果，最后都必须由工程师来画押签字。人肉兜底的安全性，这就带来了尴尬的陷阱：人类名义上是指挥官，实际上却变成了高度兼容的代码质检员，被死死困在验证中，创造力根本没有得到释放。
彻底破局，走向最终目标——可信自治，均匀地让人类从质检员跃迁为架构决策者。让AI负责底层的执行闭环和自我纠错，人类只需定义战略和约束。接管不再是无奈的擦屁股，而是施加影响力的最高控制权。
Slide 6 — 00:15:22
📌 要点汇总
- 市场正从简单生成阶段向下一代技术和Agentic AI发展
- NVIDIA CEO黄仁勋在其演讲中提及这一趋势变化
这些深水区的挑战，我们面临的出路究竟在哪里？我们先看看AI驱动开发的模式变迁。
大家看左边这张图，正如NVIDIA的黄仁勋在演讲中提到的，整个市场都在从简单的生成时代向下一代技术以及Agentic AI前进。
Slide 7 — 00:15:50
📌 要点汇总
- 当前Vibe模式依赖人工干预
- 未来代理需使AI自主规划和纠错
- 目标是从离散的人工驱动转向连续进化的自治系统
人类边的对比表展示了在不同模式中的定位。当前的 Vibe 模式本质上就是人类在循环的过程，在环内不断兜底抄写。这就像一个著名的梗：太阳能手电筒，要保持发光，你实际上得用另一个手电筒照着它。这也是目前过度依赖人工填写指令的真实写照。
未来的代理确实需要核心让人工智能化规划与关注错误，使人类从疲于奔命的循环中跃升为更高层次的监督者。最后，请大家看表格底部的成长模式。Vibe 是离散的、人工驱动的，但真正的自治系统目标是实现连续进化。只有涵盖这道工程化的挑战，我们才能彻底走向智能研发的新纪元。
Slide 8 — 00:16:54
📌 要点汇总
- Ignis 是一个基于智能的自动开发平台，可直接使用自然语言控制引擎进行开发
- 今年核心攻坚方向为实现全自动化游戏生产线
Ignis 是我们基于智能打造的自动开发平台，它有别于普通的 AIGC，能够直接控制引擎，用自然语言完成从代码逻辑到演员蓝图图的自动拉接。话不多说，通过一段实际演示来感受一下。
刚刚看到今年的核心攻坚方向是跑通全自动化游戏生产线。
Slide 9 — 00:17:34
（该幻灯片时间段内未检测到语音内容）
Slide 10 — 00:18:28
（该幻灯片时间段内未检测到语音内容）
Slide 11 — 00:19:13
（该幻灯片时间段内未检测到语音内容）
Slide 12 — 00:20:05
📌 要点汇总
- 未来目标：成为零门槛创作平台，解放行业创造力
- Ignis将集成各类AI能力，发展为完整自动化交付平台
未来，这套技术将下放成为零门槛的创作平台，彻底解放行业的创造力。以此为目标，作为自动化研发的生态模板，Ignis将持续集成各类AI能力，最终成为一个完整的自动化交付平台。
Slide 13 — 00:20:26
📌 要点汇总
- （过渡内容，无关键要点）
第二部分，我们深入原理层面。我们要重点回答的问题是：如何从不可控的状态，真正走向可控的局面？
（此处为空行）
这个问题涉及到许多技术细节和理论基础。首先，我们需要理解当前系统存在的问题，并分析其根源。
（此处为空行）
接着，我们将探讨一系列解决方案和技术手段，以实现系统的可控制性。这包括优化算法、调整参数以及引入新的架构设计等方法。
Slide 14 — 00:20:42
📌 要点汇总
- （过渡内容，无关键要点）
首先，让我们透过现象看本质，聊聊大模型信息感知的核心逻辑。
请大家先看大屏幕上的雕塑，这是法国当代艺术家Mathieu罗伯蒂斯的作品，他的透视变形金属丝雕塑在全球享有盛誉。通过巧妙的空间设计，同一个雕塑站在不同的角度看到的，就是截然不同的形象。这种现象简直完美地揭示了大语言模型的本质：事物的全貌就在其中，永远不会改变。关键在于你从什么角度看它。
大模型内部压缩了海量的训练预数据，而我们给它的提示词（prompt）就是那束决定投影方向的光。但是从数学的角度看，从高维向低维的每次投影都必然伴随着信息丢失，就像右下角这张图所示，从三维降到二维，再降到一维，你的视角确实越来越聚焦了，但同时周围的海量细节也被无情地抛弃了。
那么，因为这种投影而产生的信息丢失，在实际工程里会导致什么致命的问题呢？
Slide 15 — 00:22:10
📌 要点汇总
- RAG搜索流程包括识别、重组和生成三个步骤
- 依赖数学形式表达进行信息检索，基于高维投影的关键字搜索和相关性重排
- 重组阶段推理可能得出逻辑错误结论，迭代过程放大系统信息熵增加
- LLM背景下，提示词调整成为主要调试手段
- 长队列任务面临不平滑、不可控的问题导致任务链断裂
- 工程痛点包括不连续性和不可预测性，需降低对大模型的依赖并优化全局布局
我们来看一个最典型的RAG搜索流程，无非就是三个步骤：识别、重组和生成。当然，现在的AI技术一日千里，各种增强框架层出不穷。但今天要讲透的，是这些技术背后的底层原理。
当我们走向一个宏观的代码库中寻找信息时，目前主流的方法都高度依赖数学形式的表达。如果嵌入加上重新排序，说白了就是语义级别的关键字搜索和相关性重排。就像你用Google搜索一样，基于刚才高维投影的结论，搜索关键字就是你打的那束光，提示我们不到的地方信息就丢掉了。在系统里，这种遗漏和混乱称为信息熵增加。
下一步是重组，我们需要基于找回来的残缺信息进行推理和总结。因为前面的基础已经歪了，所以推理大概率会得出逻辑错误的结论。更要命的是，在LLM的背景窗口下，我们还得把这两个残缺的步骤来回迭代。每一轮迭代都在疯狂放大系统里的信息熵增加，而且由于整个过程是个黑盒，出错了你根本没法去代码里回溯调试。你唯一能做的就是改改提示词，就像自己在炼丹一样，然后闭上眼继续抽奖。
拆解完这个流程后，大家就都明白了为什么通用AI跑不通长队列的任务。我们总结了它的核心特征：不平滑、不可控。这导致任务链能够不断断裂。所以，让AI稳定工作的终极秘诀就是在长队列任务中死死抑制这个不断膨胀的熵增。
我们在工程中面临着两个至关重要的痛点。首先是不连续性，这就相当于在烂路上行驶，首先都是在拼命造轴距更长的大车，进而依赖参数更大、更智能的模型，而我们去选择修路把系统拆除解平滑，降低对模型基础智商的依赖。其次，是不可预测性。这就像开着只能看到局部最终导航的车，由于缺乏全局布局的视野，大模型在一步步深陷复杂的研发布局中时极易失去目标。但如
Slide 16 — 00:24:59
📌 要点汇总
- 通过可微分思想实现端到端自动化研发
- 构建全局视角的系统地图以支持连续和可计算的规划步骤
如果我们为AI挂载一张拥有全局视角的系统地图，让规划的每一步都连续且可计算，这便是通过可微分思想实现端到端自动化研发的理论基石。
Slide 17 — 00:25:14
📌 要点汇总
- 提出“可微分”AI理念，强调全局上下文中的连续性和可控性
- 可微概念来源于数学中函数可微特性：连续且偏导数受控
- 数据可微化负责将基础工程信息原子化和实时化，建立精准感知机制
- 测试流程修复确保每道指令透明可视并严格校验，解决黑盒AI问题
基于前两页提到的系统平滑与全局导航思考，我们正式提出了“可微分” AI 及其核心理念。从上层的文字定义而言，就是在全局上下文中保持连续、可控的任务过程，确立系统可追踪、可校正的特性。
而至于为何称为“可微”，这正是来源于微积分中“可微”的概念。在数学里，一个函数可微不仅要求它是连续的没有断崖沟壑的，同时也意味着它的偏导数变化方向是绝对被预测和受控的。将这个数学概念作为思想类比引入到系统工程中，就是为了拒绝朝鲜AI在解决复杂任务时那种不可靠存在的跳跃随机与黑盒幻觉，转而追求一种像数学里的同时回归一这样。
为了在工程架构上真正吃透它，我们将其拆解为绝对核心参数。左边是数据可微，它负责把庞杂的基础工程信息彻底原子化、实时化，从而建立一套全知视角的精准感知机制，用于解决复杂系统中的大模型里因为看不全而翻车的问题。
测试流程修复则直接将传统的黑盒黑魔法彻底割断开来，确保AI发出的每一道指令、每一次推理路径都是完全透明、可视，并被严格校验的。这用来解决我们对黑盒AI管不了的问题，相当于智能的理论全景。
Slide 18 — 00:27:18
📌 要点汇总
- 连续性和可控性结合体现进化法则
- AI通过代码提交和架构调整持续进化
- 成功经验和失败教训构建决策路径
- 项目研发90%时间用于构建可微演进核心
- 兼容MCP生态，无缝接入外部工具
- 深度工程化引入模型提升代理能力
当连续性和可控性相结合的时候，就承担了生命最深刻的法则——进化。达尔文在《物种起源》中揭示了一个伟大的真理：进化不是瞬时的飞跃，而是无数微小变异在自然选择压力下的持续积累。
这个思想，在生物界，基因突变永不停歇，这就是连续性；而自然选择提供了可控性，只有适应环境的变异才会被保留。映射到AI项目的每一次代码提交和架构调整中，AI都在持续感知和吸收信息；而项目的架构约束和质量标准则起到了自然法则的作用。
更重要的是，AI在解决问题和思考的过程中，会主动进行经验记录：成功的部分沉淀为经验，失败的部分沉淀为教训。这些经验和教训会自然而然地构建出一个决策空白名单，为AI的自主决策提供思考路径。长期适应的结果下，AI就呈现出真正的进化特征。随着项目的成长和发展，它越用越深入，自主创造工具，积累领域经验，并与项目形成正向飞轮效应。
而放眼整个行业，目前团队都在研究类似MCP实操执行工具的接入点，但我们的项目超过百分之九十的研发时间都是以工程化的方式构建这个可微演进的核心。这才是真正下一代代理所配备的定制能力，而不是之前讨论的那种太阳能手电筒。就像功夫，在练招式；而我们在练内功。
话说回来，我们的执行方式是完全兼容MCP和规模目前热火朝天的外部生态，可以无缝接入，并配合我们可进化的智能内核，获得远超工具累加的代理能力。这种能力是AI引入模型加上深度工程化之后的结果。
Slide 19 — 00:30:05
📌 要点汇总
- （过渡内容，无关键要点）
好，接下来我们进入第三部分，可微智能的具体技术实现。前两章回答了我们为什么需要以及核心原理是什么的问题，这一章我们将深入工程细节，看看可微智能是如何在最复杂的业务场景中真正落地的。
Slide 20 — 00:30:30
📌 要点汇总
- 数据可微包括符号级精准捕获、跨库深度关联及执行过程绝对可追溯与预测
- 流程可微涉及范式化内部数据结构、微操控制机制及状态复用
- 2009年瑞典科学家罗兰实验揭示感知精度决定决策正确率
- AI缺乏对工程细节的实时洞察，需构建灵敏预警和感知闭环
我们再把这两个大核心拆开来看，数据可微具体包括符号级的精准捕获、跨代码库和资产库的深度关联，以及执行过程的绝对可追溯与可预测。这套整套形成，我们统称为“超领悟技术”。而“流程可微”的围绕，则包括范式化的内部数据结构、各种微操级的控制机制，以及随时随地的可中继与状态复用。只有当这一条主线中继连接在一起，才能做出一个代理纯度系统真正稳定下来，而不是一个花架子。依靠这套高度工程化的可微体系，我们才算真正跳出了振动编码的效率陷阱。
好，铺垫好了，接下来我们就进入深度硬核的第三部分，具体的技术实现。在头扎进具体的代码和架构之前，我想先借用一个神经科学实验，帮助大家建立一个非常重要的直觉。2009年瑞典科学家罗兰做的经典实验，让心灵完成一个巧妙而简单的任务——划火柴。左边是对照组，预示完全正常的状态，动作行云流水，不到两秒，火柴就划着了。这背后隐藏的关键是什么？关键在于手指接触火柴的瞬间，他实时感知到了极微小的张力和压力反馈，大脑在几毫秒内完成了力量和方向的决策、反馈闭环。
右边是实验组，手指被局部麻醉，眼睛可见清晰，但缺乏对力量的感知。唯一解除的一点预见反馈导致动作极其笨拙，不断试探，火柴频频划不着，成像时间是对照组的十倍。这个实验刺透了一个本质规律：感知的精度决定了持续决策的正确率。
现在的AI就像被麻醉的手，模型推理能力很强，但缺乏对工程细节的实时洞察。它看得见代码，却感知不到敲下回车后会引发大规模的连锁反应。所以，我们的破局点很清晰，必须为AI打造最灵敏的工程预警，构建每一步的感知闭环。
Slide 21 — 00:33:38
📌 要点汇总
- 重构核心数据架构为树图异构体系，实现项目知识层级化理解与跨领域关联表达
- 核心API包括post、get、delete、patch和query，简化AI操作复杂工程数据
- 摘要策略选择自摘要为主，避免修改底层结构引发同步风暴导致性能崩溃
- 实现方式分三路：深度集成LSP协议、自研Unreal引擎插件、EARS规范拆解文档
- 任务召回流程包括意图识别、需求拆解、上下文分析和多维度搜索清单生成
- 召回模式分为轻度、中度和重度，适应不同复杂程度的任务需求
- 底层闭环优化确保每次召回绑定在底层symbol hash上，智能失效机制防止幻觉滋生
- 重量级论文展示零错误解决百万步LLM任务，采用极限拆解与投票机制
- 范式定义为可复用、随时调度的执行模板，核心包括数据结构和控制器运行机制
- 树结构支持并发执行和动态生长，状态机提供精确控制和追溯能力
为了赋予AI这种极致的感知力，我们重构了核心数据架构——树图异构体系。左边的树结构代表AI对项目知识的层级化理解。我们将工程切分成最小单位的符号，每个符号携带完整路径和精炼摘要。右边的图结构专门表达跨领域的关联。代码的调用栈、美术资产的互相引用、策划文档的逻辑关联，全都被这张网罗列清楚，赋予系统强大的广度搜索能力。
为什么要费力搞双区架构？因为大型游戏里C++代码、二进制资产、多语言文档关系极其复杂，只有树加图的方式才能把这些乱如麻的信息进行统一。最关键的是，这套架构对外只暴露五个核心API：post抢新符号，get深度搜索，delete级联清理，patch自动刷新摘要，query智能选择召回模式。AI操作复杂工程数据就跟调用标准RESTful API一样简单。
有了树图架构后，下一个核心问题是如何把工程数据变成可被AI检索的符号。这里关键是摘要策略的选择。我们评估了四种摘要方案：自摘要、自引用摘要、外摘要、联动摘要。最终结论是以自摘要为主，原因很现实：在千万行代码库中修改一个底层结构，如果用关联摘要，会引发整条链路的同步风暴，性能直接崩溃。克制是大型工程的最高智慧。
具体实现上分三路：代码通过深度集成LSP协议，像编译器一样精准抓取符号定义和引用关系；二进制资产通过自研Unreal引擎插件，穿透Blueprint节点映射回C++父类；自然语言文档采用EARS规范做结构化拆解，配合embedding双重索引保底。最终代码、资产、文档在这套体系下完成了统一符号化，这就是可微感知能力最坚实的数据底座。
货架有了，数据也准备好了，接下来是最关键的实战环节。Ignis在执行任务时如何精准召回上下文？左边是任务分发流程：系统先做意图识别，然后将需求拆解为子任务并排序，分析会话上下文，锁定目标知识库，最终生成一份多维度的搜索清单。这份清单被送到右边的召回引擎，最顶层是多路混合搜索。同时启用模糊匹配、向量embedding和BM25关键字检索，三管齐下，确保不遗漏关键信息。
核心是中间层的三种动态召回模式，这也是区别于传统RAG的关键所在。轻度召回是标准的检索加生成，应付简单问答；中度召回会自动扩展上下文，抓取符号周围的完整文档或class定义，合并权重后交给多路LLM并行阅读，适合跨库逻辑梳理。重度召回类似深度研究，Ignis会开启多轮沙盒推理和证据收集，拥有完整的逻辑验证链。如果证据链断裂，会自动发起新的深潜搜索，专门用于攻克复杂的技术推演和架构。
最后是底部的闭环优化，每次召回都绑定在底层的symbol hash上，系统越用越快。更关键的是智能失效机制，底层代码一旦被修改，所有依赖的缓存瞬间失效并重新计算，从物理层面杜绝幻觉的滋生。这就是连续进化，系统在使用中自我成长。
这里分享一篇重量级论文。二零二五年十一月，Cognizant AI Labs发表的用零错误解决百万步LLM任务，他们让大模型玩二十层汉诺塔，最优解超过一百零四万步，Maker系统做到了一百万步零错误。核心方法就三件事：第一，极限拆解，每个LM调用只处理一小步，让上下文极度聚焦，规避长上下文的精度衰减；第二，投票机制，每步决策启动多个agent并行计算，一旦某答案领先达到阈值就落锤，用算力冗余把概率学的不确定性坍缩成工程上的确定性。最震撼的是第三点，这篇论文根本没用最强推理模型，只用了轻量级的GPT 4.1 Mini，这直接证明了长链路任务的成功保障不是靠堆模型参数，而是来自系统级的工程架构设计。
这篇论文和Ignis的实践在底层哲学上完全共鸣。靠单点模型撞大运的Vibe Coding注定走不远，唯有通过严密的工程化架构设计，才能真正征服百万步的工业级长链路挑战。刚才我们提到的那篇百万步零错误论文，其核心架构和我们的思路完全不谋而合。实际上，我们在2025年2月就已经跑通了这套可微范式系统，这让我们对这条路有绝对的信心。
什么是范式？明确定义就是一个可复用的、随时调度的、被完全封装的任务执行模板，就像军事上的标准作战方案，不管战场是丛林还是沙漠，地图一换，作战框架依然稳固。范式的两个核心：第一是任务的数据结构，是串联的线、并联的树，还是复杂的网？结构决定任务如何拆分和重组；第二是控制器的运行机制，它负责推进每个节点，成功就切下一个，报错就自动回滚重试，甚至能在运行中动态插入新的执行链路。核心流程极少需要人工接管。
范式的终极意义，彻底终结了过去靠人写prompt让AI试错的时代，它让AI沿着人类规划好的最优路线推进系统级任务。刚刚定义了范式的两大核心：数据结构和控制器。落到工程实处，它们到底长什么样？这张幻灯片是底层解剖。
第一个核心：任务树结构。为什么用树？因为树是描述第一步干嘛、第二步干嘛最天然的层级表达。每个节点只有三个属性：data、children、parent。极简带来两个关键优势：兄弟节点天生支持并发执行，不需要写调度代码；树可以在运行时动态生长。AI执行中发现需要拆分，能实时从当前节点长出新分支，这对探索性研发任务是真正的杀手级能力。
第二个核心，三维状态机，树是地图，状态机是精密的定位系统。三维坐标，深度为锁定层级，节点为锁定当前任务，步骤为锁定当前动作，三轴交错形成带时间戳的执行坐标，每次操作全部可追溯、可回档。执行层面支持BFS广度优先和DFS深度优先，支持中断、重试和断点续传。
可微执行的核心就一句话：状态机里每一步的转换都必须极端可控且可预测，这是让机器在代码丛林中长期存活的物理基础。
Slide 22 — 00:43:44
📌 要点汇总
- 采用交叉验证机制，同时调用不同厂商和架构的多个模型进行独立推理并比对结果
- 设计系统时注重错误发现与修复能力，而非完全避免错误发生
- 实施底层隔离共享策略，确保AI无法直接接触底层资源，所有操作通过高级抽象接口沙盒物理隔离执行
- 采用Git事务机制实现隔离操作的回滚功能
有了强悍的核心后，还要直面AI时代开发者最关心的问题：性能和系统安全。正确的核心基础是交叉验证。我们不独立依赖单一模型，在系统运行时同时调用来自不同厂商、不同架构的多个模型进行独立推理，并做严格的一致性比对。
格式化的JSON输出通过程序全等比对复杂的非格式化文本，调用不同的小参数模型进行集群交叉关联审查。系统设计的最高边界不是避免犯错，而是错误发生时能够迅速发现并修复。A+模型可能会短暂出现幻觉，但当A+B+C三个完全不同底层架构的模型在同一时刻因同一个幻觉同时犯错的概率低到可以忽略不计。
在安全方面，我们的策略是从架构底层实施隔离共享，AI彻底无法直接接触底层的能力，控制台、数据库、文件系统全部不可见。所有操作只能通过我们用C++层层验权的高级抽象运行接口沙盒物理隔离进行。隔离操作由Git事务底层直接回滚。我们不教AI如何当好人，而是从物理世界直接断掉所有作恶路径，让他想干坏事都无路可走。
Slide 23 — 00:45:30
📌 要点汇总
- （过渡内容，无关键要点）
好了，到这里我们已经彻底讲透了可微智能的所有底层技术原理和架构实现。
接下来，欢迎来到第四章，我们将直接进入真实的生产系统Ignis。这绝不仅仅是停留在理论或者实验室里，而是我们在腾讯天美工作室的真实虚幻引擎商业项目中已经完全运行的自动对接平台。
Slide 24 — 00:46:03
📌 要点汇总
- Ignis实现自动化开发流程，涵盖项目录入、工具开发和交付验证三个阶段
- 自动化工具开发包括代码轨道和UX资产生成轨道，预警系统确保决策精确性
- 四层测试系统覆盖从单元到黑盒集成的全部测试，最终增量直接在引擎中运行
进入第四章，Ignis的实战。
这张图展示了Ignis完整的自动化开发流程，从需求文档出发，极少需要人工接管。第一阶段是项目录入，Ignis读取代码库、资产库和文档，完成全套符号化入库，并构建完整的工程采集。
第二阶段为自动化工具开发，启动代码轨道和UX资产生成轨道，预警系统在偏置轨道之间统一调度上下文，确保决策始终基于精确的工程采集。
第三阶段是交付与验证。四层测试系统自动接收从单元测试到黑盒集成全部覆盖的测试结果，最终增量可直接在引擎中运行完整的功能模块。\n\n
Slide 25 — 00:47:08
📌 要点汇总
- 功能需求涉及库存管理、实时物资消耗、多队伍资源共享及UI交互界面
- 基于UE5.4引擎，使用GAS技能框架，遵循Lira项目架构规范
- 验收标准：功能逻辑正确，资产无报错，测试全部通过
- 使用自然语言处理和语义分块将策划文档转换为符号节点
- 用Clang AST解析几百万行C++代码，生成精确的符号索引
- 自研虚幻引擎插件调取底层U2，实现蓝图二进制数据流统一符号化
看具体的输入，这是战地补给终端功能的完整具体说明。左边这个面板先告诉大家，该功能越来越复杂。功能需求涉及库存管理系统、实时物资消耗、多队伍资源共享以及UI交互界面。这是一个典型的跨多个工程模块的游戏功能，中等复杂度。
右边上半部分是技术约束，必须基于UE5.4引擎，必须使用GAS技能框架，并遵循Lira项目的现有架构规范。Agnes在拿到文件描述后，首先会解析这些硬约束，锁定开发边界项目。
右边下半部分是验收标准：功能逻辑正确，资产无报错，测试全部通过。从这份转换游戏设计文档（GDD）出发，Ignis接下来将完成整个开发闭环。重新获得任务蓝图，Ignis需要先理解整个工程，这就是数据共享阶段。核心是把海量的数据全部变成可AI检索的符号。
第一类，文档。Ignis自治使用耳朵规范结构自然语言，配合语义分块和嵌入索引，让策划文档里的每一条规则都变成可准确认知的符号节点。
第二类代码，U1的C++项目几乎有几百万行，我们用Clang AST从编译层面解析语法树，控制流分析和调用链构建，让每个函数、每个类都有精确的符号索引。
第三类艺术资产，U1蓝图是二进制黑盒，我们自研虚幻引擎插件调取底层U2，尺寸社会C++父类文档、代码、资产三条数据流统一符号化，构成Ignis的完整工程预处理。数据准备就绪，Agnes开始。
Slide 26 — 00:49:37
📌 要点汇总
- 开发假设分四层：L0使用UE5.4版本和气体技能框架
- L1阶段规划模块边界并分配独立任务数
- L2阶段定义API接口公共总线避免冲突
- L3阶段从变量API进行微操作优化升级
写代码。我们回到“战地补给完成”这个需求，看看它如何从零自动化实现。
屏幕上这棵疯狂触发的树是粗略实时运行的物理任务链树状图，不是地图，而是真实执行的任务状态。整个开发假设分四层：L零是不可突破的项目硬约束，必须使用UE五点四版本和气体技能框架；L一是高层设计阶段，Ignis先规划模块边界，再分配独立任务数；L二奉行契约优先原则，首先定义API接口公共总线，确保各个任务之间不会出现接口冲突；最底层的L三是微操现场，从变量API升级。
Slide 27 — 00:50:36
📌 要点汇总
- 实现订单关闭功能是自动化测试的关键步骤
- Ignis 能处理几百万行代码
明确核心逻辑到自动化测试，一个关键步骤是实现订单的关闭功能。Ignis 可以处理几百万行代码。
Slide 28 — 00:50:49
📌 要点汇总
- 实时可微分捕捉系统提供快速精准决策支持
- Ignis推送问题后几秒内返回相关上下文信息
- 系统具备第四级实时响应能力，代码变更立即更新符号索引
- 支持跨域联动查询，统一处理代码、资产和文档关联
- 提供多路要素支持，涵盖不同级别的数据处理需求
代码里的精准决策依赖于实时的可微分捕捉系统。这里我们直接展示它的工作流程。左边，Ignis快速推送问题，系统立即深入工程数据海洋，几秒内返回高度聚焦的相关上下文信息。这不是传统的全文搜索，而是基于符号图表的精确召回机制。
这套系统有四个核心特征：第一，第四级实时响应，代码一旦变更，符号索引会立即更新；第二，跨域联动，代码、资产和文档之间的关联可以在同一个图中统一查询；第三，多路要素支持，包括干燥、中度和重度不同级别的处理。
Slide 29 — 00:51:38
📌 要点汇总
- 认知模式根据任务复杂度自动切换
- 可微分认知系统是 Ignis 的中央决策核心
- 该系统支持任务规划、代码路径选择和架构决策
- 提高了 AI 在复杂工程中的正确决策能力
认知模式根据任务的复杂度自动切换。
第四，也是最关键的一点，它是 Ignis 的中央决策核心。任务规划、代码路径选择和架构决策都以系统的认知结果为基础。
总结一句话：可微分的认知系统赋予了 AI 真正的工程维度，复写眼。正是有了这样的存在，Ignis 才能在复杂工程中做出持续正确的决策。
Slide 30 — 00:52:15
📌 要点汇总
- Ignis 是双轨家具引擎，包含代码轨道和UX资产自动化生成轨道
- OmniParser v2 进行像素级空间抠图和定位，提高多模态模型精度
- 结构转换为UMG语义树，并通过可微分识别匹配已有组件库
- 自动生成引擎可用的UMG资产文件，无需手动操作
- UI交付速度提升十倍以上，代码轨道与UX轨道同步完成
Ignis 是双轨家具的引擎，其中一条是代码轨道，另一条则是 UX 资产自动化生成轨道。在实际演示中，一张设计截图被扔进系统后，在极少人工干预的情况下，U15 引擎会直接生成完整绘制、完全扫描的 UMG 资产文件。
背后的四个技术路径步骤如下：首先，OmniParser v2 进行像素级空间抠图和定位，解决多模态模型精度不足的问题；其次，将结构转换为 UMG 语义树；第三步是通过可微分识别匹配项目中的已有组件库；最后一步则是直接写出引擎可以运行的 UMG 资产文件。
从设计切图到生成引擎可用资产，全程无需手动操作。UI 的交付速度提升了十倍以上，代码轨道和 UX 轨道同时完成，两路汇聚到测试阶段。
Slide 31 — 00:53:28
📌 要点汇总
- Ignis具备自动化调试与测试体系
- 调试器检测报错后自动拉取日志、定位错误行、修改代码逻辑，重新触发测试直至通过
- 测试体系分为四层：调试层下发Tm指令并提供bug案例；白盒层进行静态分析和单元测试；灰盒层实时追踪性能指标；黑盒集成测试模拟真实玩家操作流程验证功能完整性
资产和代码都准备好了，但AI写的代码同样需要测试。Ignis有一套完整的自动化调试与测试体系。
屏幕上正在工作的Ignis调试器检测到报错后，会自动拉取日志，定位错误行，修改代码逻辑，并重新触发测试。如果发现新问题，则继续迭代，直到通过。
整套测试体系分为四层：调试层下发Tm指令并提供多个bug案例，在真实关白盒中触发失败；白盒层进行静态分析和单元测试，在代码执行前提前暴露逻辑漏洞；灰盒层实时追踪性能指标，当帧率异常或监控内存接近上限时自动采集转储文件；最外层是黑盒集成测试，模拟真实玩家的完整操作流程，验证最终的功能完整性，并探测、精准定位并自动修复bug。
这就是Ignis端到端的无人重型调试链路。
Slide 32 — 00:54:46
📌 要点汇总
- （内容过短，无关键要点）
经过这地狱般的。
Slide 33 — 00:54:50
📌 要点汇总
- （过渡内容，无关键要点）
调试与测试流程后的一切，尘埃落定。
请将目光转向大屏幕，这是 Ignis 在庞杂的 Lira 工程里跑完上述流程后所交付的实际部署场景。
Slide 34 — 00:55:05
📌 要点汇总
- （过渡内容，无关键要点）
想象一下，大家可以感受到，从最初的那份潦草的策划案，到现在在 U15 中流畅运行的功能实现，这个过程中我们并没有编写任何代码，也没有启动过游戏引擎。Agnes 就像一个桥梁，连接了这一切。
\n\n
在这个过程中，我们利用 Agnes 进行了一系列的设计和测试工作，使得最终的功能能够顺利地呈现在大家面前。
Slide 35 — 00:55:24
📌 要点汇总
- 后台调度超过一千个复杂节点
- 无人化率突破94.8%
- 模块由几十万行重度耦合代码集成而成
- 经受真实工业环境考验
隐形的幽灵团队在后台调度了超过一千个复杂节点，整个交付预设的无人化率更是空前地突破了94.8%的红线。
这个模块只是一个空壳子的演示，但它实际上是史诗级的几十万行重度耦合代码集成的产物。它承受住了真实情况下的工业洗礼仪式。
了解这些实况，无论您是震撼还是怀疑，现在让我们翻到最后，用细致的洞察和冰冷的数据做一次终极复盘。
Slide 36 — 00:56:07
📌 要点汇总
- 伊格尼斯占地补给终端功能开发数据：入库24小时内完成71个代币符号化处理，推理速度16,000 TPS
- 自动化执行耗时18小时10分钟，95个主任务，1000多个步骤，消耗令牌16兆，自动化率98%
- UX分析与构建：布局采集分析耗时90分钟，UMG资产构建32分钟，总消耗4.14兆代币
- 规划阶段架构生成耗时65分钟，TDD测试方案生成耗时120分钟，总计消耗10.18兆代币
- 上下文回收全程伴随执行，总消耗22.05兆代币，商业模型主要回顾，开源评估模型辅助验证
- 未来优化空间：工程化后时间和令牌消耗预计减半；进一步压缩五倍以上
- Ignis目标是标准化从策划方案到可玩原型的流程，构建下一代游戏生成式开发生态Sparkmore
最后用数据说话，这是伊格尼斯整个占地补给终端功能开发的实际执行数据。
第一张相当于入库，在单张H20显卡上，全量符号化处理71个代币，24小时以内完成，推理速度16,000 TPS，使用的是小鹏模型自开源部署方案。第二章自动化执行，十八小时十分钟，九十五个主任务，一千多个执行步骤，总消耗一百六兆令牌，自动化率九十八%。
第三章UX分析与构建，布局采集分析运行九十分钟左右，UMG资产只需构建三十二分钟。总令牌消耗4.14兆。
第四章规划阶段，架构生成消耗6.05兆代币，用时65分钟；TDD测试方案生成消耗4.13兆代币，两轮共120分钟。规划阶段总计10.18兆代币。
第五章上下文回收，全程高强度伴随执行。总消耗二十二点零五兆代币，商业模型负责主要回顾，开源评估模型承担辅助验证，两路良好。
未来优化空间：执行流程持续工程化后，时间和令牌消耗预计还能降一倍以上；进一步可微分降级高成本模型后，还有五倍以上的压缩空间。数字说话，这就是可微智能在工业级研发中的实际表现。
到这里，我们走完了Ignis的全部流程。我们做这件事的初心很简单：把时间还给创意。基于同一套可微感知与执行框架，Ignis的方向是布局玩法、代码和UI分区屏幕上的五个方向：角色与技能、关卡与场景、材质贴图、自产完成。
每一个都是从策划方案到可玩原型的维度标准化。这就是我们内部定义的游戏代理计划，一个具备连续、可控、进化能力的下一代游戏生成式开发生态——Sparkmore。专注于乐趣，连续可控的进化，这个核心原则，真的只适用于游戏吗？这个问题留给各位思考。
谢谢大家，这是我们的联系方式。如果您感兴趣，欢迎线上交流。