为什么「让 AI 写 Flecs」是这块拼图里最容易被低估的一块

凌晨一点半，一个做独立游戏的朋友给我发消息：“我用 AI 把战斗系统补完了，三百多行，一次编译通过，跑起来也不崩。我是不是可以睡了？”

我说你先别睡，把场景里的实体数从两百调到五千，再看一眼帧时间。

十分钟后他回来了，说了句我今年听过最精准的话：“它没坏，它就是变慢了。”

这句话值得裱起来，挂在每个 ECS 项目的墙上。因为它是 AI 辅助开发在 ECS 领域里最典型的出错方式——不是编译报错，不是崩溃，不是逻辑跑反，而是“一切都对，只是不快”。而“不快”这件事，你在写代码的那一刻是看不见的，只有等实体数涨上去、玩家开始抱怨、你打开性能剖析工具时，才会显示出来。

放在这个系列里，这一篇的位置有点特殊。前面二十七篇讲的是“Flecs 该怎么用”：Archetype 怎么排布内存、查询有哪三层、关系怎么表达、调度怎么排序、Observer 什么时候响。这一篇讲的是另一件事：当你的队友变成一个读完了全网 Flecs 教程、但一天项目都没做过的 AI 时，你怎么保证它不把前面二十七篇的知识用错。

我不打算写“提示词大全”，也不想聊“AI 会不会取代策划”这种谁都能说两句的空话。这一篇只解决三个具体问题：LLM 在 Flecs 上到底会错在哪、怎么给它建一座版本对得上的知识库、以及怎么把它的角色从“写代码的”改成“审设计的”。

先给结论：AI 在 ECS 领域，语法正确率接近满分，架构正确率接近碰运气。而 ECS 这门手艺，恰恰是架构决定生死、语法无关紧要。这就是为什么这个话题绕不过去。

第 1 层：错误地图——LLM 在 Flecs 上到底会错在哪

想管住 AI，第一步不是写提示词，是给它画一张错误地图。你得知道它会掉进哪个坑，才知道该在坑边立什么栏杆。

我把这两年里自己用过、也帮别人看过的问题，归成五层。层数越低越容易发现，越往上越致命。

我拿三个主流模型跑过同一道题：写一套“实体按速度移动、碰边界反弹、支持一万个实例”的系统。十二次生成里，十次能直接编译，六次逻辑跑起来是对的，只有三次在八千实体下帧时间没有明显抖动。样本很小，我不拿它当科学结论，但它的分布很像我在真实项目里看到的样子——问题从来不在前十行，在第一百行之后的每一次结构变更。

L2 值得单独说两句，因为它是最隐蔽的一类。AI 特别爱写一个字段塞满的“角色”组件：生命、速度、背包、装备、对话状态，整整齐齐三十个字段。这写法在面向对象的代码里天经地义，但在 ECS 里意味着——所有角色永远待在同一个 archetype 里，你没法只对“有速度的”那批实体做移动迭代，也没法让背包数据只在打开界面时被读到。AI 之所以爱这么写，原因特别朴素：它训练语料里面向对象的代码是 ECS 代码的几十倍，它的“手感”天然往那边滑。它不是在犯错，它是在凭直觉写它见过最多的东西。

L3 我自己也犯过。早些年让 AI 帮我写一个范围伤害，它给每个被扫到的实体加一个临时标记，处理完再删掉。逻辑完全正确，代码也很干净，结果一帧里结构变更了几十次，性能数据画出来像心电图。AI 不知道你的 archetype 表在抖，因为它看不见你的表。

再说个真实案例，把 L3 的严重性讲透——《城市：天际线 2》。

Colossal Order 在 2023 年 10 月发售这款游戏时，明确选择了 Unity 的 DOTS/ECS 路线来做大规模市民模拟。这是教科书级别的选型正确：城市模拟天然是“大量同构实体 + 每帧批量计算”，正是数据导向架构的主场。但发售后，玩家社区对性能的抱怨铺天盖地——不只是帧率，还有模拟本身推进得慢。团队后来花了很长时间，一个补丁一个补丁去优化。

这个案例的教训，跟“ECS 好不好”没关系。它的教训是：哪怕是一支做过一代城市模拟、明确知道自己要什么、有引擎团队支持的老牌工作室，ECS 的性能兑现依然要靠海量的、针对自己数据规模的调优。而 AI 在这个环节上一无所知——它不知道你的城市有多少人，不知道你的路径查询有多少条并发，不知道你的系统顺序会不会让某一帧多读一遍全表。它能给你的只有“能编译的 ECS 代码”，而《城市：天际线 2》告诉我们，能编译离能用差着十万八千里。

我不是说 AI 写不了 ECS。我是说，AI 写不了“你这个项目的 ECS”。

第 2 层：为什么 ECS 是 LLM 的“高仿陷阱”

有些领域，AI 写得比人好，比如模板化的增删改查、比如格式转换。ECS 恰恰相反：它看起来简单得离谱（不就是组件加系统吗），实际上到处都是看不见的约束。这种“表面结构规整、深层约束复杂”的活儿，最容易让模型产出一种东西——高仿。远看一模一样，上手一摸，哪儿都别扭。

三个原因，我一个一个说。

第一个原因：语料又少又碎，还跨版本。Flecs 在这个星球上的代码总量，比 Unity 的 MonoBehaviour 少好几个数量级。模型不是“学会”了 Flecs，它是从有限的语料里“平均”出了 Flecs。而这个平均，天然偏向最老、最常见的写法。更糟的是 Flecs 这七八年一直在演进，从 1.x 到 4.x，很多核心概念的写法都变过。模型在训练时把这些版本混在一起，对你提的需求做一次“平滑处理”，输出一个谁都没写过、但每一段都眼熟的弗兰肯斯坦。

举个我遇到过的例子：Flecs 在 4.0 前后对查询迭代做了大改，早期那套以“项”为核心的概念，被以“字段”为核心的概念取代了。我让模型写一段遍历两个组件的系统，它语法没写错，但组织方式明显是老版本的习惯。这种错误你在单文件里几乎看不出来——因为看着“挺合理”，甚至能跑。只有当你把它和项目里其他的系统摆在一起，才发现风格对不上，像是一个用旧地图的人给你指路。

第二个原因：反馈延迟。传统业务代码写错了，当场崩，日志一打指到行号，半小时能修好。ECS 代码写错了，表现是“第 5000 个实体时帧时间翻倍”。这个反馈链条太长了，长到人的警惕心会松掉。你会想“先跑起来再说”，然后这个“再说”就再也没说过了。

第三个原因：正确的标准在代码外面。一句话你就能听明白——在 ECS 里，性能主要由两件事决定：你的组件怎么切，以及你的实体怎么流动。组件切分决定了 archetype 有多少张表，实体流动决定了这些表多久被倒腾一次。这两件事，在任何一个单独的源文件里都看不出来。AI 拿到的是几个文件片段，它当然判不了全局。

打个比方：LLM 是一个读完了全网菜谱、但从来没进过厨房的人。它知道“盐少许”，语气比你还笃定。可它不知道你的锅多大，不知道你家灶是电磁炉，也不知道你今天的菜是要端给八个人吃还是两个人吃。

再给一个正面案例，看看人类在 ECS 上做的决策，AI 有多难模仿——《Tiny Glade》。

这是一款 2024 年 9 月发售的建造类游戏，团队是瑞典的 Pounce Light，两个人。游戏用 Rust 写、跑在 Bevy 的 ECS 上，玩家在草地上随手拖一笔，就能长出一堵墙、一条路、一片废墟，全程序化生成。它的卖点不是目标，不是数值，而是那种“随便画两笔就很好看”的顺手感。

你去看他们公开聊过的东西，会发现一个关键点：ECS 在他们手里，是把“墙、路、草、窗”这些元素变成可自由组合的数据——这是 ECS 最擅长的事，天然贴合“用少数几种元素组合出无限结果”。但与此同时，他们并没有指望通用方案解决所有问题，渲染那块写了大量针对自己视觉风格的定制内容。换句话说，他们的 ECS 不是教科书上的 ECS，是在两个人的团队、特定的美术风格、特定的性能预算下长出来的 ECS。

这正是通用模型最没辙的地方。你让 AI 写“一个标准的移动系统”，它给你一份教科书答案；可《Tiny Glade》的全部价值，恰恰在教科书之外。它不是写不出能跑的代码，它是写不出你的项目该有的那种“长在一起”的代码。

顺带说一句《守望先锋》。这个案例在本系列第一篇里展开过，这里只借它一个角度：那套 ECS 的组件切分，是被网络同步的带宽预算逼出来的，不是因为“切得漂亮”。也就是说，ECS 的组件设计从来不是审美问题，是约束问题。你没把约束告诉 AI，它就只能给你审美。

第 3 层：给 AI 一座版本锚定的 Flecs 知识库

讲完病，讲药。第一颗药不是换模型，是给它喂对的东西。检索增强这套思路大家都不陌生，但用在 Flecs 这种“版本强相关 + 语料稀缺”的技术栈上，有几个坑必须自己踩一遍才知道疼。

语料要分四层，优先级从高到低。

第四层最容易被忽略，但它才是拉开差距的地方。官方手册能告诉 AI“怎么写是对的”，只有你自己的代码能告诉它“我们这儿怎么写”。命名风格、模块划分、组件放在哪个目录、系统怎么注册——这些一致性上的小事，靠提示词说一百遍不如给它看二十个例子。

切片要按“可运行单元”切，不能按字数切。

很多人做知识库，习惯按固定字数硬切，切完检索出来的片段永远是半截的。对 ECS 来说这是灾难：一个组件定义、它的注册、以及一处使用它的系统，这三段拆开之后每一段都“看着没问题”，拼起来全是问题。我的做法是一个切片 = 一个能独立读懂的最小完整单元，大致是一次 400 到 900 个 token 的量，宁可少切几段，也别切出断头代码。

元数据里必须写版本号，检索时要先按版本过滤。

这一点是这套方案成立的关键。每条切片都打上版本标签，检索时先做一次硬过滤，只留当前主版本的语料，再做语义相似度排序。别小看这一刀，它能把 L0 那类版本混写的问题直接砍掉大半。经验是：不做版本过滤，版本混写几乎每次都会出现；做了之后，它变成一个偶发问题。

提示词里要写死三样东西：版本、项目约束、输出要求。

版本就是一句话：“本项目使用 Flecs 4.x，所有写法以 4.x 为准，不确定就说不确定。”项目约束是告诉它你的规模——“场景实体数常态两万、峰值五万，每帧预算 8 毫秒”。输出要求是让它留痕——“用到了哪几段参考资料，逐条列出来；没把握的地方标出来，不要编。”

最后那条“不确定就说不确定”，是我见过性价比最高的一句提示词。模型不是不会说这句话，是它默认不会说。你得给它这个许可。

参数表，直接抄。

说句实话：RAG 不是万能的。它能解决“事实性错误”和“版本错配”，解决不了“你的游戏该怎么做”。指望建个知识库就万事大吉的人，最后往往会失望——真正值钱的那部分，还在下一层。

第 4 层：把 AI 从“写代码的”改成“审设计的”

我这几年最大的转变，不是让 AI 写得更少，而是让它写得更少、审得更多。

原因很朴素：让 AI 生成一个完整的系统，你要验收它的全部东西，成本极高；让 AI 拿着一张清单去挑你现有设计的毛病，验收成本接近于零。而且这个岗位它干得比人好——它不累，不要面子，不怕说“这条我没把握”。

具体怎么干？三步。

第一步，人写草图。你自己定组件怎么切、实体怎么流动、哪些数据进 ECS、哪些不进。这一步不让 AI 插手，因为它没有规模感，而这一步的全部依据就是规模感。后面会讲哪些数据该留在 ECS 外面，那是本系列第 12 篇渲染、第 13 篇物理都聊过的边界问题，先记住一句话：引擎关心的数据，别全塞进组件里。

第二步，AI 按清单逐条审。给它一份固定的审查清单，让它针对每个组件、每个系统逐条回答“是 / 否 / 没把握”，并且必须给出理由。清单长这样：

注意第三行——关系。这是 Flecs 最有辨识度的东西，也是 AI 最容易写歪的地方，因为它在这块的语料更少。本系列第 8 篇专门讲关系，这里只说一句：让 AI 判断“该用关系还是组件”，它的默认答案永远是组件，因为组件它写得多、写得熟。这种时候人的一次拍板，比它一百次生成都值钱。

第三步，用工具验证，不信任何一方的嘴。组件切得对不对，光看代码是看不出来的，得看数据。本系列第 18 篇讲的那套诊断工具，在这里就派上用场了：跑六百帧，看 archetype 的数量是收敛的还是持续增长的。收敛，说明实体的流动是健康的；一路涨，说明某处有结构变更在漏水。这一张曲线图，比任何评审意见都硬。

我吃过一次亏，值得讲。有回我让 AI 帮我审一个敌人 AI 的组件设计，它给的结论特别漂亮：拆成“感知”“决策”“行动”三个组件，层次分明。我采纳了，跑起来也没问题。直到有一次做压力测试，场上八百个敌人，帧时间突然出现规律性的尖刺。查了半天，是那套“决策”组件在切换状态时会整体替换，每次切换都是一次结构变更，八百个敌人轮流切换，表就一直在被移动。

AI 的评审没错，它只是没算过八百这个数字。这就是我说的：AI 能当审查员，不能当架构师。审查是逐条判断，架构是全局取舍，后者需要知道锅有多大。

参数化设计工具：三张表把 AI 关进笼子

我不太喜欢“把流程写成规范”这种说法，太像大厂。但 AI 协作这件事，确实得有几张能贴墙上的表，不然每个人用法不一样，产出的代码风格能打架。

表一：AI 产出的验收打分卡。别用“看着挺好”来验收，用分数。门槛项不达标直接打回，其他项按权重累加，60 分以下不进主干。

规模表现这条权重最高，因为它是唯一一条 AI 完全无法自查的。你自己不测，就没人测。

表二：审查发现的严重度分级。AI 审出来的问题会很多，全改会被累死，所以要分诊。

表三：提示词的三段结构。别写长篇大论，三段就够，每段一句话。

这三张表的价值不在于“科学”，而在于把隐性的判断变成显性的检查。团队里最难对齐的从来不是技术，是“什么叫差不多得了”。有了打分卡，差不多就有了一条线。

双路径：今天就能用的，和值得花三个月搭的

初级路径：今晚就能用上的五件事。

一，把版本号写进每一次提问。别嫌烦，就一句话，能省掉你一半的返工。

二，贴例子比讲道理有效十倍。你要它写一个系统，就顺手贴一个你项目里已有的、风格正确的系统，说“照这个来”。模型的模仿能力远强于它的理解能力，这是它的长处，用起来。

三，让它先解释，再写。你要一段代码之前，先问一句“你打算怎么切组件、为什么”。它解释错的地方，往往就是它要写错的地方。这一步花三十秒，能省半小时。

四，小步提交。一次只让它做一个系统，别一口气要一整套战斗框架。它给的东西越长，你验收的成本涨得越快，而且是超线性地涨。

五，每次都要压测。哪怕只是在场景里刷两千个实体跑十秒。这个习惯一旦养成，你会发现有一半的 AI 产出根本过不了这一关——而这一半，本来会变成你三个月后的技术债。

进阶路径：值得搭的四个东西。

一，一个五十到一百条的小评测集。每条包含：一个提示词、一段期望的行为描述、以及一个典型的错误答案。每次换模型、换版本、改提示词，就跑一遍，看准确率是涨了还是掉了。这东西搭起来两天，用起来两年。

二，把压测挂进持续集成。AI 生成的模块合并前自动跑一次两千实体的基准，帧时间超过阈值就拦住。人是有惰性的，机器没有。

三，组件索引。把你项目里所有组件的名字、用途、创建日期做成一份可检索的清单，喂进知识库。这一招能极大减少“AI 又发明了一个和已有的几乎一样的组件”这种事。

四，迁移专用的新旧对照语料。每次框架升级，把改动前后的写法整理成对照表存起来。升级时你会发现，这份表比官方文档更贴你的项目，因为它是从你的代码里长出来的。

两条路的差别不在工具，在心态。初级路径是“把 AI 当个手脚麻利但没经验的实习生”；进阶路径是“把 AI 当个需要长期培养、但培养成本很低的同事”。前者见效快，后者天花板高。

争议与常见坑：那些“能跑”的代码

坑一：把“能跑”当成“对了”。这是所有坑里最要命的一个，因为它是心理层面的。传统代码里，“能跑”是个低标准；ECS 里，“能跑”几乎等于零信息量。一个把实体每帧重建一遍的实现也能跑得很好看，直到你把实体数乘以十。

坑二：让 AI 定架构。“帮我设计一套战斗系统的 ECS 架构”——这种提问听着很爽，产出看着也很专业，分了三层、列了八个组件。但你问它“为什么是八个不是五个”，它答不上来，因为它没有你的实体规模、没有你的帧预算、没有你的团队规模。架构是取舍，取舍需要约束，约束在你手里。你把这个交出去，等于把方向盘交出去。

坑三：以为上下文越长越准。很多人喜欢把整个模块几千行全贴进去，觉得信息越全越好。实际情况往往相反：中间那一段最关键的约束被淹没了，模型开始抓错重点。我的经验是，贴三个精准的例子，胜过贴三千行代码。

坑四：拿 AI 的产出喂 AI。团队里代码生成用久了，代码库里 AI 产出的比例会越来越高。如果这些代码本身带着范式错误，下一代模型学到的就是错的。这不是危言耸听，是个管理学问题——你得保证知识库里那批“黄金样例”是真的有人签过字的。

坑五：升级框架时才发现欠了债。Flecs 从 1.x 到 4.x 的演进里，很多写法变过。你用 AI 生成的代码如果没做过版本标注，升级时会变成一团乱麻——因为你连“这段是谁写的、按哪版写的”都说不清。本系列第 2 篇聊版本演进时提过这事，在 AI 协作的场景下，它会被放大好几倍。

还有个争议我想摆到台面上：有人说，用 AI 写 ECS，会让人学不会 ECS。我部分同意。如果你从第一天起就让它写、你只负责粘贴，那你确实学不会——因为你跳过的正好是这门手艺里唯一需要动脑的部分：组件怎么切、实体怎么流动。

但反过来也成立。如果你把它当陪练，让它审你的设计、让它解释为什么这么切、让它在你的清单上逐条打勾或打叉——你的学习速度会比啃文档快得多。因为你能立刻拿到反馈，而 ECS 这门手艺最缺的就是反馈。

工具本身没有立场，用它的姿势有。

FAQ

Q1：到底哪个模型写 Flecs 写得好？

说实话，这个问题的答案三个月就过期一次，所以我给的不是名单，是判断方法：拿你自己的五道真题去测同一个模型，看它出错的方式，而不是看它答对了几道。有的模型版本混写严重，有的模型范式错位严重，有的模型特别爱编造不存在的接口。前两种可以靠提示词和知识库救，第三种很难救——因为它骗你的时候语气最自信。你更该怕的是后者。

Q2：我们项目小，值得搭知识库吗？

看规模。一个人做原型，别搭，把版本号写进提示词、每次贴两个例子，够用了。三个人以上、代码超过五万行、或者已经在用 Flecs 做正式项目了，那值得。搭的成本大概两三天，收益从第一次框架升级开始兑现。

Q3：AI 能帮我把老项目从面向对象迁到 ECS 吗？

能帮一部分，但别指望它主导。它能干的是机械活：把一堆散落的字段归类成候选组件、找出重复的数据结构、生成迁移前后的对照。它干不了的是判断：哪些状态该进 ECS、哪些该留在外面、哪些逻辑其实根本不该拆。这个判断依据是你的实体规模和更新频率，它看不见。本系列第 4 篇讲思维转型时反复强调过，转型的难点不在改写，在重新想清楚“什么是数据、什么是行为”。

Q4：让 AI 审设计，它老是挑一堆没用的毛病，怎么办？

给它分级标准。别问“这个设计有什么问题”，问“按 P0/P1/P2 三级，分别列出问题；P0 是每帧结构变更或无界创建，P1 是粒度或关系选型，P2 是命名”。一旦你把标准写死，它的输出质量会跳一个台阶——因为它不用猜你想要什么尺度了。这跟带新人是同一个道理。

Q5：怎么说服团队里抵触 AI 的人？

别说服，给他看曲线。把同一段功能手写版和 AI 版的实体数-帧时间曲线并排打出来，谁对谁错一目了然。技术争论最后都得落在数据上，尤其是 ECS 这种“对不对全看跑起来”的领域。反过来也一样：如果 AI 版真的更快，你也得认。我认过一次，那次挺不爽的，但那版确实比我写得好。