book-to-skill 这个思路最近很值得认真试一次。核心就一句话把一本书里真正有用的操作方法、代码模板和参数规则浓缩成一个 AI 能直接加载执行的 Skill然后再让这个 Skill 帮你做游戏开发。我按这个流程跑过一轮之后最明显的感受是它不能替代你读书但能把“读厚的书”变成“能直接调用的开发规范”。如果你正在用 AI 写代码但又觉得 AI 老是给出泛泛而谈的答案这篇文章就是给你准备的。下面我会按照实际动手的顺序从 Skill 的概念、环境准备、书籍蒸馏流程到游戏开发落地和常见问题排查完整拆一遍。这篇文章里出现的目录、配置和示例命令都以“本地可复现”为前提。我没有引用特定版本号因为 book-to-skill 的落地方式和你选择的 AI 编程工具关系很大。建议你照着流程走的时候先把依赖版本、工具目录和测试样例固定下来再一层层往上加功能。1. book-to-skill 到底在解决什么问题1.1 先理解 Skill 是什么Skill 在 AI 编程语境里通常不是一个魔法插件而是一份结构化的技能包。常见形式是一个目录里面至少包含SKILL.md描述这个技能解决什么问题、使用步骤、规则、参数、验收标准。scripts/存放辅助脚本比如从书里提取代码块、格式化文档。examples/存放示例项目或示例代码方便 AI 参考输出格式。assets/存放图标、模板文件等静态资源。当 AI 编程助手加载 Skill 后它会优先阅读 SKILL.md再结合目录里的示例去生成代码。你可以把它理解成给 AI 一份“刚入职时的操作手册”。写得好AI 的输出会明显贴近手册里的风格和约束写得不好就算加载了也像是没加载。book-to-skill 就是把“一本技术书”变成这样一份操作手册的过程。书架上的书是整块知识Skill 是经过筛选、压缩、结构化之后的那部分“怎么做”和“注意什么”。它不追求把所有内容都塞进去重点是把能指导实际操作的部分留下。1.2 为什么不能直接把整本书丢给 AI有人会问既然 AI 能读 PDF为什么不直接上传一本书让它边读边写问题在于上下文和噪声。一本技术书动辄几百页里面包含大量的历史背景、概念解释、过渡章节、图片说明和练习题目。直接把这些内容全部塞给 AI一方面会挤占上下文窗口导致真正关键的代码规则和参数表排得很靠后另一方面AI 在大量泛化内容中很容易迷失重点最后给你的答案不是“按这本书的规范写”而是“按所有书的通用写法写”。蒸馏的作用就是去掉噪声保留关键信息。比如一本书教你做 2D 平台游戏真正在开发时反复用到的可能只有场景树结构、节点类型、物理参数、信号连接、动画状态机和常见报错处理。这些内容加起来可能只有几十页。book-to-skill 要做的就是从几百页里把这几十页挑出来再改写成 AI 能直接照做的规则和模板。1.3 这个方案适合谁不适合谁我建议这几类人重点看正在用 Cursor、Claude Code 等 AI 编程工具但觉得回答不够具体、不够专一的开发者。想学游戏开发但暂时没有系统时间从第一章读到最后一章的入门者。读过不少技术书想把自己的笔记沉淀成可复用资产的资料整理型学习者。不适合的情况也有如果你完全没安装过开发环境连命令行都不熟悉那应该先把工具链跑通再考虑蒸馏。因为 book-to-skill 解决的是“如何让 AI 更懂这本书里的规范”不是“帮你把环境装好”。此外如果你只是想要一个通用的代码补全助手那当前方案会显得有点重。2. 环境准备跑通 book-to-skill 需要哪些前置条件2.1 硬件和软件要求我没有在一台豪华机器上跑这里给出的是普通开发机的参考条件。操作系统Windows、macOS、Linux 都行。内存建议 8GB 以上。如果蒸馏过程中还需要调用大模型16GB 会更稳。磁盘预留至少 2GB 空间主要用来放 Skill 目录、示例代码和临时文件。CPU文本处理和脚本运行对 CPU 要求不高普通办公处理器足够。GPU不是必须。只有当你选择在本地跑向量化或本地模型嵌入时GPU 才会有明显帮助。软件层面你需要准备一个能编辑 Markdown 的编辑器VS Code、Obsidian、Typora 都可以。一个命令行终端Windows 推荐 PowerShellmacOS 和 Linux 直接用自带终端。一门脚本语言Python 或 Node.js主要用于写辅助脚本。Python 更常见。一个支持加载 Skill 的 AI 编程工具Cursor、Claude Code 或其他支持自定义技能目录的工具。具体目录位置以工具官方说明为准。注意我这里没有写具体版本号。book-to-skill 本身的实现方式会随工具更新变化建议你落地前先确认工具当前版本对 Skill 目录格式的要求避免照着旧教程配置后加载失败。2.2 Skill 目录结构怎么建不管用的是哪款工具建议先按一个统一结构建好目录。以一个游戏开发 Skill 为例my-game-dev-skill/ ├── SKILL.md ├── scripts/ │ └── extract_code_blocks.py ├── examples/ │ ├── player_move.gd │ ├── enemy.gd │ └── scene_structure.md └── assets/ └── icons/ └── skill-icon.pngSKILL.md 是这个目录的灵魂必须放在第一层。scripts 和 examples 可以按需增减。假如你的书主要讲 Godot那 examples 里可以放 GDScript 代码片段和场景结构说明假如讲 Unity就放 C# 脚本和预制体建议。我一般会先把目录建好再写一个最小 SKILL.md然后让 AI 工具尝试加载一次。这一步能提前暴露路径问题。2.3 怎么验证环境已经可用不要急着拿整本书开跑。先做一个 10 分钟冒烟测试新建一个 Skill 目录SKILL.md 只写一句话“当用户要求写一个 2D 游戏时始终使用 CharacterBody2D 节点。”把目录放到 AI 工具认可的 Skill 路径。打开一个新的对话引用这个 Skill让它写一个简单的玩家移动脚本。看结果里是否出现了“CharacterBody2D”这个要求。如果 AI 的输出没有遵守这条规则先不要怀疑 AI优先检查 Skill 路径、文件名、目录格式和工具版本。很多时候不是功能不生效而是放错了目录。3. 把一本书蒸馏成 Skill 的完整流程3.1 选书与拆书先定用途再选内容蒸馏的第一原则是不要幻想把整本书都装进一个 Skill。书越厚越要有目的性地拆。我建议先回答一个问题你希望这个 Skill 将来做什么如果答案是“帮我做一个 2D 平台跳跃游戏”那你就只需要关注这本书里与平台跳跃相关的章节比如场景与节点、物理移动、碰撞检测、动画、关卡设计和简单 UI。选好书之后把目录结构先列出来。技术书通常章节清晰这时候可以做一个简单的“拆书索引”章节名核心主题是否与目标任务相关值得提取的内容类型代码模板、参数表、常见错误、操作步骤比如一本《Godot 4 游戏开发入门》可以先标记出第 3 章“场景树与节点”是必选第 5 章“2D 物理与运动”是必选第 11 章“音效与音乐”可以先跳过因为 AI 无法靠 Skill 生成音频资源。切忌跳过拆书直接全文提取否则你得到的 Skill 和原书没有本质区别还是太散。3.2 提取最有价值的四类内容从书里提取内容时不是照着原文复制。要提取对 AI 生成代码最有帮助的四类信息提取类型具体内容对 AI 的作用操作步骤创建项目、添加节点、绑定脚本的流程让 AI 按照流程生成而不是乱跳步骤代码模板玩家移动、碰撞处理、UI 更新的标准写法减少 AI 自由发挥导致的结构偏差参数表重力、速度、生命值、节点属性等数值范围让参数有依据而不是拍脑袋边界规则哪些操作不建议做、什么时候该用物理帧防止 AI 踩坑写参数表的时候要注意书里的参数可能基于特定版本例如某本书基于 Godot 4.2你实际用的是 4.3参数就不一定完全一致。所以提取后最好在 SKILL.md 里注明“来源版本”并在开发时先跑一次小样本验证。3.3 写成 SKILL.md 核心文件SKILL.md 不要写成书籍目录要写成 AI 可以执行的指令集。下面是简化的示例# 2D Platformer Game Development Skill ## 适用场景 - 使用 Godot 4.x 开发 2D 平台跳跃游戏 - 需要创建玩家角色、敌人、关卡和基础 UI ## 核心步骤 1. 创建项目时选择 Godot 4.x 模板 2. 玩家角色使用 CharacterBody2D而不是 RigidBody2D 3. 移动处理放在 _physics_process 中不要放在 _process 中 4. 碰撞体使用 CollisionShape2D并确保形状正确 5. 敌人使用 Area2D 或 CharacterBody2D根据攻击方式选择 6. 关卡场景使用 TileMapLayer 或手排放置 StaticBody2D ## 参数参考 - gravity: 980 px/s² - jump_velocity: -400 px/s - 玩家移动速度: 200-300 px/s ## 禁止事项 - 不要在 _process 中直接修改物理体位置 - 不要使用已被弃用的节点类型 - 不要在没有版本确认的情况下使用最新 API ## 验收标准 - 玩家可以左右移动 - 玩家可以跳跃并正常落地 - 碰撞体不会导致角色卡进地面 - 项目能在 Godot 4.x 中无报错运行这段只是示例具体参数以你选择的书籍和引擎版本为准。但结构可以参考适用场景、核心步骤、参数参考、禁止事项、验收标准。这五段内容对你帮助最大。3.4 用脚本提取代码示例如果书是 Markdown 格式或者能转换成 Markdown可以用脚本自动提取代码块。下面是一个简单的 Python 示例能把 Markdown 中的代码块抽取出来存到 examples 目录。import re from pathlib import Path source Path(godot_book.md) out_dir Path(examples/code_snippets) out_dir.mkdir(parentsTrue, exist_okTrue) content source.read_text(encodingutf-8) code_blocks re.findall(r(.*?), content, re.S) for i, block in enumerate(code_blocks[:20], start1): (out_dir / fsnippet_{i:02d}.md).write_text(block, encodingutf-8) print(f共找到 {len(code_blocks)} 个代码块前 20 个已写入 examples)这段脚本适合清洗程度比较高的 Markdown 文档。如果你的书是 PDF 或 EPUB需要先转换成 Markdown转换过程可能会引入格式噪声比如代码行被截断、图片位置错乱。转换后一定要抽查几个章节。3.5 测试 Skill 是否真的被“记住”了蒸馏之后不要直接进入游戏开发先做一轮测试。用一个低难度问题验证 Skill 是否真的生效。比如你刚写了一个 Godot 2D 平台跳跃 Skill可以这样问“根据 my-game-dev-skill写一个玩家移动脚本包含跳跃和重力处理。”然后看结果是否满足三件事脚本是否使用了 CharacterBody2D是否把物理处理放在了 _physics_process是否用了 SKILL.md 里的参数如果输出没有遵守就回到 SKILL.md 补“必须”和“禁止”。通常第一次测试就能发现规则写得不够具体。例如只写“使用物理帧处理”AI 可能还是会用 _process必须明确写出“不要放在 _process”。3.6 蒸馏时最容易踩的四个坑第一照抄原文太多。Skill 不是读书笔记而是操作指令。原文大段粘贴只会让 AI 抓不住重点。第二只给抽象概念不给示例。比如“优化碰撞体”这种说法AI 不知道具体改哪里。要给一个判定标准比如“碰撞体过小时使用 add_shape 调整形状”。第三把多个不相关的章节塞进同一个 Skill。物理、 UI、 AI、网络混在一起很容易互相冲突。按能力域拆分更合理。第四没有记录版本信息。书里有 API 版本如果 Skill 里没有标注遇到引擎升级或框架更新时AI 会按照旧规范生成导致报错。4. 用蒸馏出来的 Skill 开发一个游戏4.1 从需求描述到提示词假设你现在要用刚才的 Skill 开发一个 2D 平台跳跃游戏。需求本身不用写得太长但关键约束必须写清楚。一个可参考的提示词模板请使用 my-game-dev-skill 开发一个 Godot 2D 平台跳跃游戏。 要求 1. 玩家使用 CharacterBody2D支持左右移动和跳跃 2. 敌人使用 Area2D 检测玩家碰撞触碰后玩家生命值减少 3. 游戏包含一个起始场景和一个胜利条件 4. 提供 project.godot、player.gd、enemy.gd 和 level.tscn 的文件结构 5. 所有代码必须符合 SKILL.md 中的参数和禁止事项 6. 先列出项目文件结构再逐个生成文件内容这里的关键是最后两条“符合 SKILL.md 中的参数”和“先列出结构”。这样 AI 不会一上来就乱写文件而是先展示整体规划你确认后再继续。4.2 审查 AI 生成的文件结构AI 生成代码后不要直接复制进项目先审查文件结构是否符合游戏引擎的要求。以 Godot 为例正常情况下应该有project.godot项目配置player.gd玩家脚本enemy.gd敌人脚本level.tscn主场景文件可能还有 HUD 脚本和胜利检测脚本我一般会先打开 player.gd 和 level.tscn 的头部检查节点类型和路径是否匹配。比如玩家场景里是否真的挂载了 CharacterBody2D玩家脚本里引用的节点路径是否与场景中的节点名称一致。路径不一致是这个环节最常见的报错原因。4.3 按 Skill 规则做局部修正如果生成结果不够理想不要整个推翻重来按 Skill 规则做局部修正。例如移动速度异常快检查 SKILL.md 里的速度参数范围。跳跃高度太低检查 jump_velocity 是否在合理区间。控制有延迟检查是否错误使用 _process 处理输入。AI 用了不存在的 API检查版本是否与书或 Skill 标记的版本一致。修正时直接把问题反馈给 AI并引用 SKILL.md 里的规则例如“根据 SKILL.md 禁止事项不要用 _process 修改物理体位置”。这样 AI 会更明确地遵守规则。4.4 从单场景扩展到完整小游戏能跑通一个场景后再考虑扩展。扩展不是一次性让 AI 生成一个完整游戏而是分小步推进增加一个开始菜单场景。增加玩家受击后的反馈动画。增加一个终点区域玩家到达后切换到胜利场景。最后增加暂停功能。每一步都单独调用 Skill并在提示词里说明“保持现有项目结构”。这时 Skill 的作用更加明显它能保证每一次生成的代码风格和参数范围一致不会这次用 CharacterBody2D下次又换成 RigidBody2D。4.5 和版本控制、任务清单结合如果是真实项目我建议把 Skill 和版本控制结合使用。每次 AI 修改后先运行一遍确认没有报错再提交。不要频繁让 AI 在同一个提示词里改多个模块否则一旦出错你不知道是哪一步引入的问题。可以简单列一个任务清单玩家移动与跳跃碰撞与死亡判定场景切换UI 显示音效与动画AI 一次只负责一个任务完成后人工检查一次。这种做法比“一句话生成整个游戏”的可控性高很多。5. 效果判断输出质量、资源占用和边界5.1 怎么判断 Skill 是否真的被加载判断标准从来不是“AI 说加载了”而是看输出表现。你可以从三个维度观察风格一致性生成代码是否和 examples 目录里的风格接近。规则遵守度是否遵守 SKILL.md 中的“禁止事项”。参数准确性是否使用了你记录的参数范围。如果三次测试都满足说明 Skill 已经生效。如果只有一次满足大概率是提示词里偶发地引用了 Skill不代表稳定生效需要继续优化 SKILL.md 的触发条件。5.2 资源占用怎么看文本蒸馏阶段的资源占用通常不高。如果你用 Python 脚本读取整本书主要消耗的是内存和磁盘 I/O。如果书中包含大量图片CPU 转换会稍慢但很少会到卡死的程度。如果你在蒸馏时还调用本地大模型做摘要那资源占用会明显上升。这时可以这样判断任务运行中系统风扇转速明显提高说明 CPU 或 GPU 在高负载。内存占用长期接近上限说明可能需要减小文档切块大小。处理时间越来越长说明文档复杂度高建议分批处理。不要一上来就开最大并发。先用一个小章节测试耗时再决定是否并行。5.3 Skill 的边界在哪里Skill 并不能解决游戏开发的所有问题。它最擅长的是让 AI 在写代码时遵守某本书里的规则和参数。以下内容不要指望 Skill 能做生成美术资源、音效和音乐。自动完成复杂架构的全局设计。完全替代你对游戏玩法的理解。在书籍版本与当前引擎不匹配时自动纠偏。换句话说Skill 是“规则层”不是“资料层”。你仍然需要知道游戏的基本玩法、项目管理方式和美术资源怎么来。它在降低重复劳动上有明显帮助但不会把你变成一个完全不用思考的“一键生成游戏”工具。5.4 什么时候需要重新蒸馏一本书的 Skill 不是一劳永逸的。出现以下情况时可以重新蒸馏或更新 Skill引擎版本升级旧 API 大量废弃。你从 2D 游戏转向 3D 游戏原书中的 2D 知识不再适用。开发中频繁发现 Skill 规则与目标项目冲突。多次测试输出仍然不符合预期说明蒸馏内容质量不够。更新 Skill 时不需要重读整本书。只更新变化的部分比如把旧参数表替换成新参数表把弃用 API 加入“禁止事项”。5.5 多个 Skill 如何共存而不冲突如果你同时有物理开发 Skill、UI 开发 Skill、音效处理 Skill不要让它们同时加载到同一个上下文里。正确的做法是按能力域拆分用时才加载。比如开发一个 2D 游戏时如果这一轮任务是写玩家物理移动只加载物理 Skill。如果任务是做 HUD 界面只加载 UI 开发 Skill。如果任务是调试音频再加载音频 Skill。如果两个 Skill 的规则发生冲突优先在全局配置中写明公共规则比如“所有代码必须兼容 Godot 4.x”“禁止使用未确认的 API”。这样能减少冲突。注意Skill 越多AI 的注意力会被稀释。建议一个项目同时加载的 Skill 不要超过 3 个。6. 常见问题和排查链路6.1 Skill 加载了但没有效果最常见的原因不是功能失效而是路径和文件名问题。按这个顺序排查检查 Skill 目录名是否包含空格或特殊字符。检查 SKILL.md 是否放在第一层而不是子目录里。检查文件名大小写是否与工具要求一致。检查模型上下文设置是否限制了 Skill 文件夹读取。用最简单的问题测试例如“写一个 Hello World”看是否触发。如果以上都正常再怀疑工具版本兼容性。有时候 Skill 已经加载但因为上下文过长规则被放在靠后位置导致 AI 没有优先参考。此时需要精简 SKILL.md。6.2 生成代码总是出现旧版 API这是游戏开发中最常见的坑。排查链路先确认 SKILL.md 里是否明确写了版本信息。再看 examples 里的代码是否基于旧版本。如果 Skill 源自一本出版时间较早的书AI 生成的代码可能混入旧 API。解决办法在 SKILL.md 顶端加一行“仅使用 Godot 4.x API禁用 3.x 的节点和方法”然后把 examples 更新为你实际验证过的代码。不要一遇到旧 API 就让 AI 瞎改先给规则再生成。否则 AI 可能把正确的新 API 又改成另一个旧写法。6.3 蒸馏后的 Skill 回答太泛泛如果 AI 生成的内容像“通用教程”说明 SKILL.md 缺少约束条件。你需要补充三类内容“必须做”清单例如必须使用 CharacterBody2D。“禁止做”清单例如禁止在 _process 中改物理位置。“验收标准”例如玩家能正常跳跃落地、没有穿透地面。只有正向规则没有负向规则AI 很容易给出一堆模棱两可的建议。负向规则通常能把答案从“通用”拉回“特别”。6.4 AI 频繁修改项目结构这种情况往往出现在一次性提示词里AI 觉得自己可以自由重构。解决办法在提示词开头写明“保持现有项目结构只修改 player.gd”。在 SKILL.md 中加入“除非用户明确要求否则不新增或删除文件”。每次只给一个局部任务不要同时要求改玩家、敌人、 UI 和场景。我一般会把当前项目目录树直接贴进提示词并标注“只允许修改以下文件”。这样即使 AI 想重构也不会越界。6.5 资源占用异常高如果蒸馏脚本把整本书一次性读入内存再逐行正则匹配内存占用会很高。优化方向按章节切块处理不要一次性读入全书。只提取代码块和参数表不要全文生成摘要。把临时文件写入磁盘不要全部保存在内存变量中。如果合理调整后仍然卡顿降低脚本中的最大提取数量。处理几百万字的书籍时这个节点很关键。6.6 如何防止 Skill 内容过时给每个 SKILL.md 底部加一个“维护记录”区块## 维护记录 - 蒸馏日期2025-06-01 - 来源书籍Godot 4 游戏开发入门示例 - 书籍版本基于 Godot 4.2 - 最后验证2025-06-03 - 验证结果玩家移动脚本可正常运行以后每次引擎升级回来更新这条记录。再用同一套测试提示词跑一遍如果生成代码仍然符合预期说明 Skill 没失效如果不符合就更新参数表和禁止事项。book-to-skill 真正落地时最值得盯住的不是功能列表而是输入内容质量、Skill 规则是否清晰以及生成结果能不能稳定复现。先拿一本薄书或几个关键章节做试验比一上来就蒸馏整个书架要靠谱得多。把第一步跑稳了后面的游戏开发才会顺。