[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"consumer-news-detail-860":3,"consumer-news-interaction-860":38,"consumer-news-related-860":41},{"detail":4,"item":34},{"card":5,"schemaVersion":21,"fields":22,"content":28},{"id":6,"kind":7,"targetType":8,"targetId":9,"subtype":7,"typeLabel":10,"title":11,"subtitle":12,"summary":13,"coverUrl":14,"badgeText":14,"href":15,"sourceName":12,"meta":16,"metrics":18,"tags":19,"resolved":20},"NEWS_ARTICLE:860","news","NEWS_ARTICLE",860,"资讯","3句话，AI给我生成了一个galgame","博客园","demo和源码 demo地址 不支持移动端，可能需要1分钟的加载 demo仓库 plugin plugin我之前弄的时候很容易碰上路径问题，导致读取不到项目根目录下setting，如果要用的话得从Marketplace中获取后手工拷贝 agent & skills & script","","\u002Fnews\u002F860",[17],"2026",{},[],true,"consumer-content-detail-v1",{"sourceName":12,"authorName":23,"summary":13,"description":13,"publishTime":24,"updateTime":25,"sourceUrl":26,"language":27},"CrazyJinn","2026-09-01T23:29","2026-09-02T20:37:50","https:\u002F\u002Fwww.cnblogs.com\u002FCrazyJinn\u002Fp\u002F22798093","中文",{"format":29,"policy":30,"normalized":20,"html":31,"text":32,"wordCount":33,"hasBody":20},"HTML","NEWS_CONTENT_V1","\u003Ch2>demo和源码\u003C\u002Fh2>\n\u003Cp>\u003Ca href=\"https:\u002F\u002Fpub-2696736f004f4a38b974de6d3794e829.r2.dev\u002Findex.html\" target=\"_blank\" rel=\"noopener noreferrer nofollow\">demo地址\u003C\u002Fa>\u003C\u002Fp>\n\u003Cblockquote>\n \u003Cp>不支持移动端，可能需要1分钟的加载\u003C\u002Fp>\n\u003C\u002Fblockquote>\n\u003Cp>\u003Ca href=\"https:\u002F\u002Fgithub.com\u002FCrazyJinn\u002FProxyLove\" target=\"_blank\" rel=\"noopener noreferrer nofollow\">demo仓库\u003C\u002Fa>\u003C\u002Fp>\n\u003Cp>\u003Ca href=\"https:\u002F\u002Fgithub.com\u002FCrazyJinn\u002Fgame-builder\" target=\"_blank\" rel=\"noopener noreferrer nofollow\">plugin\u003C\u002Fa>\u003C\u002Fp>\n\u003Cblockquote>\n \u003Cp>plugin我之前弄的时候很容易碰上路径问题，导致读取不到项目根目录下setting，如果要用的话得从Marketplace中获取后手工拷贝 agent & skills & script 到项目目录\u003C\u002Fp>\n\u003C\u002Fblockquote>\n\u003Cp>技术栈：\u003C\u002Fp>\n\u003Ctable>\n \u003Cthead>\n  \u003Ctr>\n   \u003Cth>类型\u003C\u002Fth>\n   \u003Cth>工具\u003C\u002Fth>\n  \u003C\u002Ftr>\n \u003C\u002Fthead>\n \u003Ctbody>\n  \u003Ctr>\n   \u003Ctd>LLM\u003C\u002Ftd>\n   \u003Ctd>GLM\u003C\u002Ftd>\n  \u003C\u002Ftr>\n  \u003Ctr>\n   \u003Ctd>Harness\u003C\u002Ftd>\n   \u003Ctd>Claude Code\u003C\u002Ftd>\n  \u003C\u002Ftr>\n  \u003Ctr>\n   \u003Ctd>美术\u003C\u002Ftd>\n   \u003Ctd>GPT Image 2.0\u003C\u002Ftd>\n  \u003C\u002Ftr>\n  \u003Ctr>\n   \u003Ctd>配音\u003C\u002Ftd>\n   \u003Ctd>Qwen3-TTS\u003C\u002Ftd>\n  \u003C\u002Ftr>\n  \u003Ctr>\n   \u003Ctd>配乐\u003C\u002Ftd>\n   \u003Ctd>SeedMusic 1.0 Preview\u003C\u002Ftd>\n  \u003C\u002Ftr>\n  \u003Ctr>\n   \u003Ctd>环境音效\u003C\u002Ftd>\n   \u003Ctd>AudioFly\u003C\u002Ftd>\n  \u003C\u002Ftr>\n  \u003Ctr>\n   \u003Ctd>游戏引擎\u003C\u002Ftd>\n   \u003Ctd>Godot\u003C\u002Ftd>\n  \u003C\u002Ftr>\n  \u003Ctr>\n   \u003Ctd>图数据库\u003C\u002Ftd>\n   \u003Ctd>Neo4j\u003C\u002Ftd>\n  \u003C\u002Ftr>\n \u003C\u002Ftbody>\n\u003C\u002Ftable>\n\u003Ch2>写在前面的话\u003C\u002Fh2>\n\u003Cp>请原谅我的标题党，这篇文章真正的标题应该是：\u003C\u002Fp>\n\u003Cblockquote>\n \u003Cp>\u003Cstrong>《3句话 + 21个 Skill + 无数人工微调，AI 给我生成了一个 Galgame》\u003C\u002Fstrong>\u003C\u002Fp>\n\u003C\u002Fblockquote>\n\u003Cp>实际上，这个游戏确实几乎所有资产都是 AIGC ，但距离“3句话生成一个 Galgame”还差得很远。\u003C\u002Fp>\n\u003Cp>换句话说，AI 确实参与了绝大部分生产过程，但它距离一个可以完全自主完成游戏开发的智能体，还有相当长的距离。\u003C\u002Fp>\n\u003Ch2>LLM 真的已经无所不能了吗？\u003C\u002Fh2>\n\u003Cp>随着大语言模型的出现，网上一直充斥着各种相当乐观的声音。\u003C\u002Fp>\n\u003Cp>各种公众号、自媒体和利益相关者不断神话 LLM 的能力，似乎只要再等一段时间，AGI 就会出现，软件、游戏、小说、音乐乃至所有知识工作都会被 AI 接管。\u003C\u002Fp>\n\u003Cp>但如果暂时把宣传放到一边，只看实际生产，我认为现实要凄凉得多。\u003C\u002Fp>\n\u003Cp>LLM 目前真正表现出工业生产能力的领域，依然集中在编程相关领域。\u003C\u002Fp>\n\u003Cp>而在其他领域，普遍还是：\u003C\u002Fp>\n\u003Cblockquote>\n \u003Cp>\u003Cstrong>出个简单的 demo 可以，大规模工业化还不够。\u003C\u002Fstrong>\u003C\u002Fp>\n\u003C\u002Fblockquote>\n\u003Cp>这也是我这次尝试用 AI 做一个完整游戏后最大的感受。\u003C\u002Fp>\n\u003Cp>问题并不是 AI 不会生成。\u003C\u002Fp>\n\u003Cp>恰恰相反，现在的模型已经非常擅长生成各种东西，真正的问题是：\u003C\u002Fp>\n\u003Cblockquote>\n \u003Cp>\u003Cstrong>生成之后，怎么知道它对不对？\u003C\u002Fstrong>\u003C\u002Fp>\n\u003C\u002Fblockquote>\n\u003Ch2>为什么编程特别适合 LLM？\u003C\u002Fh2>\n\u003Cp>如果分析一下为什么 LLM 能够在编程领域率先进入相对实用的阶段，我认为主要有三个原因。\u003C\u002Fp>\n\u003Ch3>1. 编程语言相对无歧义\u003C\u002Fh3>\n\u003Cp>编程语言从设计之初就是为了让机器执行。\u003C\u002Fp>\n\u003Cpre>\u003Ccode>if (condition) {\n    doSomething();\n}\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>它的语义空间受到语言规范、类型系统和运行环境的严格限制。\u003C\u002Fp>\n\u003Cp>自然语言则完全不同，同一句话可能有很多合理解释。\u003C\u002Fp>\n\u003Cp>“一个温柔的女孩”到底有多温柔？\u003C\u002Fp>\n\u003Cp>“昏暗的房间”到底有多暗？\u003C\u002Fp>\n\u003Cp>“悲伤地说话”到底应该是什么声音？\u003C\u002Fp>\n\u003Cp>这些问题很难得到一个唯一答案。\u003C\u002Fp>\n\u003Ch3>2. 有大量高质量训练数据\u003C\u002Fh3>\n\u003Cp>开源项目、GitHub、Stack Overflow、技术文档以及大量程序代码，为模型提供了规模非常庞大的程序训练数据。\u003C\u002Fp>\n\u003Cp>更重要的是，这些数据之间存在大量重复和相似结构。\u003C\u002Fp>\n\u003Cp>一个问题通常可以找到很多已经存在的解决方案。\u003C\u002Fp>\n\u003Ch3>3. 交付物可以被快速测试\u003C\u002Fh3>\n\u003Cp>我认为第三点才是最重要的。\u003C\u002Fp>\n\u003Cp>代码写出来之后，可以立刻得到反馈：\u003C\u002Fp>\n\u003Cpre>\u003Ccode>代码 -> 编译器 -> 语法错误 \u002F 类型错误\n代码 -> Unit Test -> Integration Test -> 运行结果\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>也就是说，AI 生成的东西可以快速进入一个反馈闭环。\u003C\u002Fp>\n\u003Cp>这个闭环实际上构成了 AI 进行工业级编程开发的重要基础：\u003C\u002Fp>\n\u003Cpre>\u003Ccode>生成 -> 测试 -> 发现问题 -> 修改 -> 再次测试\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>AI 不需要一次就写对，只要错误能够被快速、明确地反馈出来，它就可以不断迭代。\u003C\u002Fp>\n\u003Ch2>游戏开发的问题恰恰相反\u003C\u002Fh2>\n\u003Cp>如果把同样的思路放到游戏开发中，就会发现事情突然变得麻烦起来。\u003C\u002Fp>\n\u003Cp>游戏开发的交付物远不止代码，还有：\u003C\u002Fp>\n\u003Cul>\n \u003Cli>剧情、台词\u003C\u002Fli>\n \u003Cli>角色设计、角色立绘\u003C\u002Fli>\n \u003Cli>场景\u003C\u002Fli>\n \u003Cli>配音、音乐、音效\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>而这些东西大多数都没有像语法检查或者单元测试一样明确的“正确答案”。例如：\u003C\u002Fp>\n\u003Cblockquote>\n \u003Cp>这张角色立绘到底好不好？\u003C\u002Fp>\n\u003C\u002Fblockquote>\n\u003Cblockquote>\n \u003Cp>这个角色的声音是否符合人物设定？\u003C\u002Fp>\n\u003C\u002Fblockquote>\n\u003Cblockquote>\n \u003Cp>这一段剧情是不是足够精彩？\u003C\u002Fp>\n\u003C\u002Fblockquote>\n\u003Cp>于是整个生产流程很容易变成：\u003C\u002Fp>\n\u003Cpre>\u003Ccode>AI 生成 -> 人工审阅 -> 觉得不对 -> 告诉 AI -> 重新生成\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>问题在于，“不对”本身就是一个非常模糊的反馈。\u003C\u002Fp>\n\u003Cp>这也是为什么我认为，AI 在游戏开发中真正的瓶颈已经不是生成能力，而是\u003Cstrong>验证能力\u003C\u002Fstrong>。\u003C\u002Fp>\n\u003Ch2>不同生产环节，难度完全不同\u003C\u002Fh2>\n\u003Cp>这次实际做下来，我对几个环节难度的体感大概是：\u003C\u002Fp>\n\u003Cpre>\u003Ccode>剧情 >>> 台词 >> 配音 > 美术 > 配乐 ≈ 程序\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>下面分别说。\u003C\u002Fp>\n\u003Ch4>剧情：目前基本没有特别好的解决方案\u003C\u002Fh4>\n\u003Cp>剧情是整个流程里最让我头疼的部分。\u003C\u002Fp>\n\u003Cp>理论上，可以把人物、地点、事件和信息全部放进知识图谱，然后使用图算法寻找图中的缺口，再让 LLM 根据这些缺口继续生成剧情。\u003C\u002Fp>\n\u003Cp>例如：\u003C\u002Fp>\n\u003Cblockquote>\n \u003Cp>角色 A 只有两个事件关联\u003C\u002Fp>\n\u003C\u002Fblockquote>\n\u003Cblockquote>\n \u003Cp>而其他核心角色已经拥有几十个事件，那么 B 就可能是一个值得继续扩展的节点。\u003C\u002Fp>\n\u003C\u002Fblockquote>\n\u003Cp>从工程角度来说，这套方案是可行的。\u003C\u002Fp>\n\u003Cp>但问题是：\u003C\u002Fp>\n\u003Cblockquote>\n \u003Cp>\u003Cstrong>能找到剧情缺口，不代表能写出好剧情。\u003C\u002Fstrong>\u003C\u002Fp>\n\u003C\u002Fblockquote>\n\u003Cp>目前 LLM 可以比较稳定地生成“合理”的剧情，但距离真正有趣、有张力、有记忆点的剧情还有明显差距。\u003C\u002Fp>\n\u003Cp>所以这次 Demo 的剧情部分，我最终还是选择了手写。\u003C\u002Fp>\n\u003Cp>图算法负责发现问题的思路我会继续做，但至少目前，它更适合作为创作辅助工具，而不是一个真正的自动编剧。\u003C\u002Fp>\n\u003Ch4>台词：最大的问题是不说人话\u003C\u002Fh4>\n\u003Cp>台词的问题和剧情不太一样。\u003C\u002Fp>\n\u003Cp>它不是完全不会写，而是经常会写出一种非常明显的\u003Cstrong>AI 味。\u003C\u002Fstrong>\u003C\u002Fp>\n\u003Cp>语言逻辑没有问题，语法也没有问题，但就是不像人在说话。\u003C\u002Fp>\n\u003Cp>例如人物明明只是表达一个很简单的情绪，AI 往往会不自觉地把句子写得过于完整、过于工整。\u003C\u002Fp>\n\u003Cp>这或多或少也和我使用的模型有关。这次主要使用的是 GLM，DeepSeek 在这方面会稍微好一些，理论上 GPT 是写作最好的选择。\u003C\u002Fp>\n\u003Cp>但我不认为换模型能够从根本上解决这个问题。\u003C\u002Fp>\n\u003Cp>我之前也专门潜伏观察过一些网文写作社区，一个比较有意思的共识是：\u003C\u002Fp>\n\u003Cblockquote>\n \u003Cp>\u003Cstrong>如果只看写作能力，现在主流 LLM 和当年的 GPT-3.5，在“说人话”这件事情上的差距，几乎没有区别，甚至更差\u003C\u002Fstrong>\u003C\u002Fp>\n\u003C\u002Fblockquote>\n\u003Cp>模型可以润色，可以改错别字，可以调整表达，可以根据要求扩写，但让它长期维持人物、世界观、叙事节奏，并持续产出真正有吸引力的内容，依然很困难。\u003C\u002Fp>\n\u003Cp>至少目前，我更愿意把它看成一个非常强的编辑和辅助创作者，而不是作者本人。\u003C\u002Fp>\n\u003Ch4>配音：情绪和音色的一致性很难同时满足\u003C\u002Fh4>\n\u003Cp>配音看起来比剧情简单得多。\u003C\u002Fp>\n\u003Cp>现在的 TTS 已经能够生成质量相当不错的人声。\u003C\u002Fp>\n\u003Cp>但真正开始施工之后，会发现这里存在两个要求：\u003C\u002Fp>\n\u003Col>\n \u003Cli>角色需要有稳定的音色。\u003C\u002Fli>\n \u003Cli>不同台词又需要有不同的情绪。\u003C\u002Fli>\n\u003C\u002Fol>\n\u003Cp>单独解决任何一个都不难。\u003C\u002Fp>\n\u003Cp>固定一个声音，然后一直念同样的东西，音色可以非常稳定。\u003C\u002Fp>\n\u003Cp>或者让模型自由发挥情绪，也可以得到很有表现力的声音。\u003C\u002Fp>\n\u003Cp>但把两件事情放在一起：\u003C\u002Fp>\n\u003Cpre>\u003Ccode>固定角色音色 + 不同情绪 + 不同语气 + 不同场景\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>事情就开始变得麻烦。\u003C\u002Fp>\n\u003Cp>同一个角色开心的时候、愤怒的时候、害怕的时候、低声说话的时候，都需要还是“这个人”。\u003C\u002Fp>\n\u003Ch4>美术：单张图片已经不是问题，统一画风才是\u003C\u002Fh4>\n\u003Cp>如果只评价单张图片，质量已经足够高。\u003C\u002Fp>\n\u003Cp>现在的问题已经不是：\u003C\u002Fp>\n\u003Cblockquote>\n \u003Cp>AI 能不能画出一张好看的图？\u003C\u002Fp>\n\u003C\u002Fblockquote>\n\u003Cp>而是：\u003C\u002Fp>\n\u003Cblockquote>\n \u003Cp>\u003Cstrong>AI 能不能连续画出 20 张不同角色、画风相同的设计图\u003C\u002Fstrong>\u003C\u002Fp>\n\u003C\u002Fblockquote>\n\u003Cp>例如我明确要求：\u003C\u002Fp>\n\u003Cblockquote>\n \u003Cp>半写实角色设计风格。\u003C\u002Fp>\n\u003C\u002Fblockquote>\n\u003Cp>对于成年人角色，模型通常可以做到。但当我要求它生成一个小女孩的三视图时，模型又很容易被自己的训练数据带偏，最后变成非常典型的日系二次元画风。\u003C\u002Fp>\n\u003Cp>这说明一个问题：\u003C\u002Fp>\n\u003Cblockquote>\n \u003Cp>\u003Cstrong>单张图片的生成能力和稳定的视觉风格控制，是两个完全不同的问题。\u003C\u002Fstrong>\u003C\u002Fp>\n\u003C\u002Fblockquote>\n\u003Ch4>配乐：问题不大\u003C\u002Fh4>\n\u003Cp>配乐是这次比较轻松的一个环节，虽然这份轻松是建立在demo场景不多的前提下的。\u003C\u002Fp>\n\u003Ch4>程序：目前反而是最简单的一环\u003C\u002Fh4>\n\u003Cp>这可能也是整个项目里最符合大家对“AI Coding”想象的部分，也恰恰是大语言模型的甜点区。\u003C\u002Fp>\n\u003Ch2>系列文章导航\u003C\u002Fh2>\n\u003Cp>\u003Ca href=\"https:\u002F\u002Fwww.cnblogs.com\u002FCrazyJinn\u002Fp\u002F22798093\" target=\"_blank\" rel=\"noopener noreferrer nofollow\">3句话，AI给我生成了一个galgame\u003C\u002Fa>\u003Cbr>\u003Ca href=\"https:\u002F\u002Fwww.cnblogs.com\u002FCrazyJinn\u002Farticles\u002F22765511\" target=\"_blank\" rel=\"noopener noreferrer nofollow\">AI-Native游戏开发(1)：为什么选择图数据库\u003C\u002Fa>\u003Cbr>\u003Ca href=\"https:\u002F\u002Fwww.cnblogs.com\u002FCrazyJinn\u002Farticles\u002F22764344\" target=\"_blank\" rel=\"noopener noreferrer nofollow\">AI-Native游戏开发(2)：角色美术生产链\u003C\u002Fa>\u003Cbr>\u003Ca href=\"https:\u002F\u002Fwww.cnblogs.com\u002FCrazyJinn\u002Farticles\u002F22765526\" target=\"_blank\" rel=\"noopener noreferrer nofollow\">AI-Native游戏开发(3)：角色声音生产链\u003C\u002Fa>\u003Cbr>\u003Ca href=\"https:\u002F\u002Fwww.cnblogs.com\u002FCrazyJinn\u002Farticles\u002F22765543\" target=\"_blank\" rel=\"noopener noreferrer nofollow\">AI-Native游戏开发(4)：场景与BGM生产链\u003C\u002Fa>\u003Cbr>\u003Ca href=\"https:\u002F\u002Fwww.cnblogs.com\u002FCrazyJinn\u002Farticles\u002F22765552\" target=\"_blank\" rel=\"noopener noreferrer nofollow\">AI-Native游戏开发(5)：剧情台词生产链\u003C\u002Fa>\u003Cbr>\u003Ca href=\"https:\u002F\u002Fwww.cnblogs.com\u002FCrazyJinn\u002Farticles\u002F22765556\" target=\"_blank\" rel=\"noopener noreferrer nofollow\">AI-Native游戏开发(6)：叙事图自增长\u003C\u002Fa>\u003C\u002Fp>","demo和源码 demo地址 不支持移动端，可能需要1分钟的加载 demo仓库 plugin plugin我之前弄的时候很容易碰上路径问题，导致读取不到项目根目录下setting，如果要用的话得从Marketplace中获取后手工拷贝 agent & skills & script 到项目目录 技术栈： 类型 工具 LLM GLM Harness Claude Code 美术 GPT Image 2.0 配音 Qwen3-TTS 配乐 SeedMusic 1.0 Preview 环境音效 AudioFly 游戏引擎 Godot 图数据库 Neo4j 写在前面的话 请原谅我的标题党，这篇文章真正的标题应该是： 《3句话 + 21个 Skill + 无数人工微调，AI 给我生成了一个 Galgame》 实际上，这个游戏确实几乎所有资产都是 AIGC ，但距离“3句话生成一个 Galgame”还差得很远。 换句话说，AI 确实参与了绝大部分生产过程，但它距离一个可以完全自主完成游戏开发的智能体，还有相当长的距离。 LLM 真的已经无所不能了吗？ 随着大语言模型的出现，网上一直充斥着各种相当乐观的声音。 各种公众号、自媒体和利益相关者不断神话 LLM 的能力，似乎只要再等一段时间，AGI 就会出现，软件、游戏、小说、音乐乃至所有知识工作都会被 AI 接管。 但如果暂时把宣传放到一边，只看实际生产，我认为现实要凄凉得多。 LLM 目前真正表现出工业生产能力的领域，依然集中在编程相关领域。 而在其他领域，普遍还是： 出个简单的 demo 可以，大规模工业化还不够。 这也是我这次尝试用 AI 做一个完整游戏后最大的感受。 问题并不是 AI 不会生成。 恰恰相反，现在的模型已经非常擅长生成各种东西，真正的问题是： 生成之后，怎么知道它对不对？ 为什么编程特别适合 LLM？ 如果分析一下为什么 LLM 能够在编程领域率先进入相对实用的阶段，我认为主要有三个原因。 1. 编程语言相对无歧义 编程语言从设计之初就是为了让机器执行。 if (condition) { doSomething(); } 它的语义空间受到语言规范、类型系统和运行环境的严格限制。 自然语言则完全不同，同一句话可能有很多合理解释。 “一个温柔的女孩”到底有多温柔？ “昏暗的房间”到底有多暗？ “悲伤地说话”到底应该是什么声音？ 这些问题很难得到一个唯一答案。 2. 有大量高质量训练数据 开源项目、GitHub、Stack Overflow、技术文档以及大量程序代码，为模型提供了规模非常庞大的程序训练数据。 更重要的是，这些数据之间存在大量重复和相似结构。 一个问题通常可以找到很多已经存在的解决方案。 3. 交付物可以被快速测试 我认为第三点才是最重要的。 代码写出来之后，可以立刻得到反馈： 代码 -> 编译器 -> 语法错误 \u002F 类型错误 代码 -> Unit Test -> Integration Test -> 运行结果 也就是说，AI 生成的东西可以快速进入一个反馈闭环。 这个闭环实际上构成了 AI 进行工业级编程开发的重要基础： 生成 -> 测试 -> 发现问题 -> 修改 -> 再次测试 AI 不需要一次就写对，只要错误能够被快速、明确地反馈出来，它就可以不断迭代。 游戏开发的问题恰恰相反 如果把同样的思路放到游戏开发中，就会发现事情突然变得麻烦起来。 游戏开发的交付物远不止代码，还有： 剧情、台词 角色设计、角色立绘 场景 配音、音乐、音效 而这些东西大多数都没有像语法检查或者单元测试一样明确的“正确答案”。例如： 这张角色立绘到底好不好？ 这个角色的声音是否符合人物设定？ 这一段剧情是不是足够精彩？ 于是整个生产流程很容易变成： AI 生成 -> 人工审阅 -> 觉得不对 -> 告诉 AI -> 重新生成 问题在于，“不对”本身就是一个非常模糊的反馈。 这也是为什么我认为，AI 在游戏开发中真正的瓶颈已经不是生成能力，而是验证能力。 不同生产环节，难度完全不同 这次实际做下来，我对几个环节难度的体感大概是： 剧情 >>> 台词 >> 配音 > 美术 > 配乐 ≈ 程序 下面分别说。 剧情：目前基本没有特别好的解决方案 剧情是整个流程里最让我头疼的部分。 理论上，可以把人物、地点、事件和信息全部放进知识图谱，然后使用图算法寻找图中的缺口，再让 LLM 根据这些缺口继续生成剧情。 例如： 角色 A 只有两个事件关联 而其他核心角色已经拥有几十个事件，那么 B 就可能是一个值得继续扩展的节点。 从工程角度来说，这套方案是可行的。 但问题是： 能找到剧情缺口，不代表能写出好剧情。 目前 LLM 可以比较稳定地生成“合理”的剧情，但距离真正有趣、有张力、有记忆点的剧情还有明显差距。 所以这次 Demo 的剧情部分，我最终还是选择了手写。 图算法负责发现问题的思路我会继续做，但至少目前，它更适合作为创作辅助工具，而不是一个真正的自动编剧。 台词：最大的问题是不说人话 台词的问题和剧情不太一样。 它不是完全不会写，而是经常会写出一种非常明显的AI 味。 语言逻辑没有问题，语法也没有问题，但就是不像人在说话。 例如人物明明只是表达一个很简单的情绪，AI 往往会不自觉地把句子写得过于完整、过于工整。 这或多或少也和我使用的模型有关。这次主要使用的是 GLM，DeepSeek 在这方面会稍微好一些，理论上 GPT 是写作最好的选择。 但我不认为换模型能够从根本上解决这个问题。 我之前也专门潜伏观察过一些网文写作社区，一个比较有意思的共识是： 如果只看写作能力，现在主流 LLM 和当年的 GPT-3.5，在“说人话”这件事情上的差距，几乎没有区别，甚至更差 模型可以润色，可以改错别字，可以调整表达，可以根据要求扩写，但让它长期维持人物、世界观、叙事节奏，并持续产出真正有吸引力的内容，依然很困难。 至少目前，我更愿意把它看成一个非常强的编辑和辅助创作者，而不是作者本人。 配音：情绪和音色的一致性很难同时满足 配音看起来比剧情简单得多。 现在的 TTS 已经能够生成质量相当不错的人声。 但真正开始施工之后，会发现这里存在两个要求： 角色需要有稳定的音色。 不同台词又需要有不同的情绪。 单独解决任何一个都不难。 固定一个声音，然后一直念同样的东西，音色可以非常稳定。 或者让模型自由发挥情绪，也可以得到很有表现力的声音。 但把两件事情放在一起： 固定角色音色 + 不同情绪 + 不同语气 + 不同场景 事情就开始变得麻烦。 同一个角色开心的时候、愤怒的时候、害怕的时候、低声说话的时候，都需要还是“这个人”。 美术：单张图片已经不是问题，统一画风才是 如果只评价单张图片，质量已经足够高。 现在的问题已经不是： AI 能不能画出一张好看的图？ 而是： AI 能不能连续画出 20 张不同角色、画风相同的设计图 例如我明确要求： 半写实角色设计风格。 对于成年人角色，模型通常可以做到。但当我要求它生成一个小女孩的三视图时，模型又很容易被自己的训练数据带偏，最后变成非常典型的日系二次元画风。 这说明一个问题： 单张图片的生成能力和稳定的视觉风格控制，是两个完全不同的问题。 配乐：问题不大 配乐是这次比较轻松的一个环节，虽然这份轻松是建立在demo场景不多的前提下的。 程序：目前反而是最简单的一环 这可能也是整个项目里最符合大家对“AI Coding”想象的部分，也恰恰是大语言模型的甜点区。 系列文章导航 3句话，AI给我生成了一个galgame AI-Native游戏开发(1)：为什么选择图数据库 AI-Native游戏开发(2)：角色美术生产链 AI-Native游戏开发(3)：角色声音生产链 AI-Native游戏开发(4)：场景与BGM生产链 AI-Native游戏开发(5)：剧情台词生产链 AI-Native游戏开发(6)：叙事图自增长",3029,{"id":6,"kind":7,"title":11,"summary":13,"image":14,"href":15,"meta":17,"badge":10,"author":12,"stats":-1,"accent":35,"coverRatio":36,"tags":37},"#2563eb","16 \u002F 10",[7,8],{"targetType":8,"targetId":9,"likedByMe":39,"likeCount":40,"commentCount":40,"contentLikeCount":40,"contentCommentCount":40,"sourceLikeCount":40,"sourceCommentCount":40},false,0,[42,51,57,64,72,79,85,92],{"id":43,"kind":7,"title":44,"summary":45,"image":46,"href":47,"meta":48,"badge":10,"author":12,"stats":-1,"accent":35,"coverRatio":36,"tags":49},"NEWS_ARTICLE:827","MHS 三部曲（下）：谁允许 AI 行动？——权力、合规与中国厂商的答卷","我们总在等待一个像 ChatGPT 那样的机器人时刻。但具身智能真正的拐点，也许先发生在更不起眼的地方：一台陌生设备，第一次能把自己的能力、状态和边界完整告诉 AI；一个 Agent，第一次能把试出来的经验固化成可验证、可复用的机器技能。","https:\u002F\u002Fimg2024.cnblogs.com\u002Fblog\u002F510\u002F202608\u002F510-20260830153745229-1536981088.jpg","\u002Fnews\u002F827","2026 · 人工智能",[50],"人工智能",{"id":52,"kind":7,"title":53,"summary":54,"image":14,"href":55,"meta":17,"badge":10,"author":12,"stats":-1,"accent":35,"coverRatio":36,"tags":56},"NEWS_ARTICLE:829","我不会美工，用 WorkBuddy 1 分钟做出 4 张海报","先说结果：下面这 4 张海报，从我发出指令到拿到图片，大约 1 分钟。 我不会美工，也没有打开 Photoshop。用的工具，是我之前用 WorkBuddy 做的一个海报生成器。这个生成器本身也没花几分钟，具体开发过程我在上一篇文章里写过。 这次我把海报生成器的网址、产品截图和要求一起发给 Work","\u002Fnews\u002F829",[7,8],{"id":58,"kind":7,"title":59,"summary":60,"image":61,"href":62,"meta":17,"badge":10,"author":12,"stats":-1,"accent":35,"coverRatio":36,"tags":63},"NEWS_ARTICLE:828","一个人抵一个团队的时代，企业级 AI Agent 还需要做什么？","对于企业而言，真正需要的，不是一个“会聊天”的 Agent，而是一套能被多用户、多场景复用，且权限清晰、过程可审计、成本可控制的 Agent 能力体系。","https:\u002F\u002Fimg2024.cnblogs.com\u002Fblog\u002F2232255\u002F202609\u002F2232255-20260902173524728-659996478.png","\u002Fnews\u002F828",[7,8],{"id":65,"kind":7,"title":66,"summary":67,"image":14,"href":68,"meta":69,"badge":10,"author":12,"stats":-1,"accent":35,"coverRatio":36,"tags":70},"NEWS_ARTICLE:832","用 runtime-async 写一个支持 async\u002Fawait 的轻量脚本引擎","起因：一个好奇 事情的开头很简单。 给 .NET 做过动态脚本的人大概都碰到过同一堵墙：表达式树也好、Reflection.Emit 也好，都很难支持 async\u002Fawait。原因不在语法，而在 await 的实现方式——C# 编译器要为每个 async 方法生成一个状态机结构体，把方法体切成若干片","\u002Fnews\u002F832","2026 · 软件开发",[71],"软件开发",{"id":73,"kind":7,"title":74,"summary":75,"image":76,"href":77,"meta":17,"badge":10,"author":12,"stats":-1,"accent":35,"coverRatio":36,"tags":78},"NEWS_ARTICLE:831","Agent Sandbox 规模化：JuiceFS 探索与实践","过去一段时间，我们在和云厂商以及 Agent 团队推进 Sandbox 落地时，除了要解决数据如何进入 Sandbox，还需要考虑任务所需的数据和执行过程中产生的数据，如何跨任务、跨阶段持续使用。Sandbox 可以随任务快速创建和销毁，但数据往往需要继续保留、共享和流转。 当 Sandbox 并发","https:\u002F\u002Fimg2024.cnblogs.com\u002Fblog\u002F2544292\u002F202609\u002F2544292-20260902171045357-1907499098.png","\u002Fnews\u002F831",[7,8],{"id":80,"kind":7,"title":81,"summary":82,"image":14,"href":83,"meta":17,"badge":10,"author":12,"stats":-1,"accent":35,"coverRatio":36,"tags":84},"NEWS_ARTICLE:830","百智云长期记忆服务：长期记忆与上下文窗口的区别","很多人在接触 AI 长期记忆时，第一反应是：「这不就是把聊天记录存起来吗？」其实这是一个很常见的误解。今天我们把「长期记忆」和「上下文窗口」这两个概念彻底讲清楚。 一、什么是上下文窗口 上下文窗口（Context Window）是模型在单次推理时能「看到」的文本上限。它像一个临时的工作台：模型只能处","\u002Fnews\u002F830",[7,8],{"id":86,"kind":7,"title":87,"summary":88,"image":89,"href":90,"meta":48,"badge":10,"author":12,"stats":-1,"accent":35,"coverRatio":36,"tags":91},"NEWS_ARTICLE:835","体验向量数据库 qdrant","作者:张富春(ahfuzhang)，转载时请注明作者和引用链接，谢谢！ cnblogs博客 zhihu Github 公众号:一本正经的瞎扯 背景 为了早点搞懂公司的百万行 C# 的祖传代码，我想在缺乏文档、缺乏帮手的情况下，先建立一个 企业知识库 来快速帮我理清头绪。 一开始，我是打算以 weav","https:\u002F\u002Fimg2022.cnblogs.com\u002Fblog\u002F1457949\u002F202202\u002F1457949-20220216153819145-1193738712.png","\u002Fnews\u002F835",[50],{"id":93,"kind":7,"title":94,"summary":95,"image":14,"href":96,"meta":17,"badge":10,"author":12,"stats":-1,"accent":35,"coverRatio":36,"tags":97},"NEWS_ARTICLE:833","如何利用AI技术实现漫画翻译","漫画作为图文结合的特色文化载体，承载着各国潮流文化与人文故事，但跨语言的文字壁垒，长期制约着漫画的传播与交流。传统漫画翻译高度依赖人工操作，需要人工框选文字、擦除原图文字、翻译文案、排版适配画风，流程繁琐、耗时费力，且极易出现排版错乱、画风违和、语义偏差等问题。 随着深度学习、计算机视觉与大模型技术","\u002Fnews\u002F833",[7,8]]