今日速览
- 提示词工程（Prompt Engineering）是专门研究「怎么把需求说清楚」的学科，核心结论：模型能力再强，也猜不透模糊需求。
- 让 DeepSeek 写游戏代码，最大的坑不是它不会写，而是你说得太少：没有引擎、没有版本、没有输入输出、没有约束，它就自由发挥。
- 正确姿势是「需求拆解」：一个完整游戏功能 = 若干条小提示词，每条只干一件事（生成 / 重构 / 查 bug），像流水线一样推进。
- 上下文工程很关键：把 Godot 官方文档的相关片段、你的报错信息、现有代码一起贴给 DeepSeek，比干巴巴问「怎么写跳跃」准得多。
- 迭代循环是常态：生成 → 跑 → 报错 → 把报错贴回去 → 再改，AI 编程本质是「人指挥、AI 执行、人验收」。
核心学习内容
1. 为什么「帮我写个游戏」一定会翻车
GDScript 参考文档里明确写着：GDScript 是强类型与动态类型混用的语言，var a = 5 和 var typed_var: int 都合法；节点靠 extends 继承，信号靠 signal 声明…… 引擎的 API 细节多到爆炸。如果你只对 DeepSeek 说「写个 2D 平台跳跃」，它会默认一套假设：节点叫啥？跳跃用 CharacterBody2D 还是 RigidBody2D？重力多少？按键用 WASD 还是方向键？——每个假设都可能导致代码跑不起来。DAIR.AI 的提示工程指南同样指出：提示词的元素应包括指令、上下文、输入数据、输出格式，缺一个就靠模型猜。
2. 需求拆解四步法（核心方法论）
把「做一个功能」拆成四层，写进提示词：
- 角色（Role）：告诉 DeepSeek 它是谁。例：「你是一名熟悉 Godot 4 的 GDScript 游戏开发者」——这比直接下命令能显著提升代码质量和 API 正确率。
- 任务（Task）：一句话说清要什么。例：「为一个 2D 平台跳跃角色编写
CharacterBody2D的移动与跳跃脚本」。 - 输入输出（I/O）：说明给它什么、要它还你什么。例：「输入：角色移动速度 300、跳跃速度 600、重力 1200；输出：完整 GDScript 脚本 + 节点结构说明 + 关键参数注释」。
- 约束（Constraints）：圈定边界。例：「只使用 Godot 4.x 内置 API；不使用第三方插件；跳跃用
is_on_floor()检测；代码加中文注释」。
一次只拆一个功能，别让一条提示词同时干「写移动 + 写敌人 AI + 写存档」三件事——模型在长任务里容易顾此失彼，拆开反而更快。
3. 上下文工程：把「资料」喂给它
模型的知识有截止日期，Godot 4.3 之后的新 API（比如 TileMapLayer）它可能记错。对策：先抓官方文档再提问。用 web_fetch 抓取 Godot 文档对应页面，把相关段落复制进提示词：「以下是从 Godot 4.x 官方文档摘录的 API 说明：[粘贴]，请严格按此 API 编写……」。这能大幅减少「它写了、但 API 不存在」的返工。报错同理：把 Godot 编辑器控制台的完整报错（含行号）原样贴回去，让模型基于真实信息修，而不是猜。
4. 迭代式开发：一条龙工作流
推荐节奏：提示词 A 生成初版 → 跑一遍 → 报错/不符合预期 → 提示词 B（debug 模板）带着报错修 → 通过后 → 提示词 C（审查模板）让它自查性能与边界 → 人工验收合并。DeepSeek 上下文里保留着之前代码，后续提示词只需说「基于上面的脚本修改」，不用重复贴全文。
🎯 DeepSeek 提示词
模板 1：从零生成一个功能脚本（适用：移动、跳跃、拾取、对话等任意新功能）
你是一名精通 Godot 4.x 与 GDScript 的资深游戏开发者。请为我的 2D 游戏编写一个「{功能名称}」脚本。
【需求描述】
{用 2-3 句话描述功能行为，如：玩家按空格键跳跃，落地前只能跳一次，跳跃时播放动画}
【输入参数】
移动速度：{数值}；跳跃速度：{数值}；重力：{数值}
【要求】
1. 使用 CharacterBody2D 作为根节点类型，输出完整脚本；
2. 只使用 Godot 4.x 内置 API，不依赖第三方插件；
3. 用 _physics_process 处理移动，用 is_on_floor() 做落地检测；
4. 关键逻辑加中文注释，参数定义为可在编辑器调整的 @export 变量；
5. 输出格式：先列出需要创建的节点结构（树形），再给出完整代码，最后附 3 条使用注意。
【参考 API】
{可选：粘贴 Godot 官方文档相关段落}使用说明：把花括号内容替换成你的实际需求。第一次用先别贪多，只写一个功能；跑通后再用模板 3 审查。
模板 2：需求转「任务清单」——把大想法拆成可执行提示词（适用：从零构思一个系统）
你是一名游戏架构师。我只有一句话想法：「{一句话描述游戏或系统，如：做一个有血量、护盾、能量三种资源的 RPG 战斗系统}」。
请帮我把它拆解为 5-8 个独立、可逐个交给 AI 编码的模块任务，每个任务：
1. 用一句话描述该模块的功能与输入输出；
2. 注明依赖（必须先完成哪个模块）；
3. 建议使用的 Godot 节点类型与关键 API；
4. 给出我该用怎样的提示词开头去生成它（一句话提示词草稿）。
要求：模块之间边界清晰、不重复；按依赖关系排序；最后给出推荐的开发顺序。使用说明：写大系统前先跑这条，得到「开发地图」，再照着地图逐个用模板 1 落地。避免想到哪写到哪、代码互相打架。
模板 3：Debug 修复模板（适用：代码跑不起来 / 行为不对 / 报错）
你是我的 GDScript 调试助手。下面是我的代码和报错信息，请帮我定位并修复。
【引擎版本】Godot 4.{x} / GDScript
【期望行为】{功能应该做什么，如：角色按空格应跳起并播放动画}
【实际表现】{发生了什么，如：按空格没反应，控制台报错}
【完整报错信息】
{原样粘贴 Godot 输出面板的报错，含行号}
【相关代码】
{粘贴出问题的脚本全文}
【输出要求】
1. 先说明根因（1-2 句），再给出修改后的完整代码（不要只给片段）；
2. 说明改动了哪几处、为什么改；
3. 如果报错信息不足，列出你需要我补充的信息，不要瞎猜；
4. 若怀疑是节点配置而非代码问题，明确指出该检查哪些 Inspector 设置。使用说明：报错信息越完整，修得越快。养成习惯：出 bug 就把报错 + 代码 + 期望行为三段式丢给 DeepSeek，比反复试改效率高一个量级。
学习心得
以前我总想着「一句话让 AI 写出整个游戏」，今天学完才明白：AI 写代码的本质是把需求翻译成代码，翻译质量取决于需求质量。对「用 DeepSeek 做一款能上架的 Steam 游戏」来说，这意味着两件事：第一，我得先能把自己的游戏拆成一个个具体功能（这就是游戏设计能力，正好是前几天数值平衡、关卡设计积累的东西）；第二，每条提示词都要带齐角色、任务、输入输出、约束四要素，把 Godot 文档和报错喂进去。有了这套方法，DeepSeek 就从「偶尔灵光的玩具」变成「稳定的结对程序员」——每天多跑通一个小功能，游戏就真的会长出来。
明日关注
- 用模板 1 实际生成一个 Godot 小功能（如角色二段跳），记录第一次生成到跑通花了几个来回
- 对比「带 API 文档」和「不带文档」两种提示词的代码质量差异
- 收集 3 条 Godot 常见报错，准备好对应的 debug 提示词素材库
本文由自动化学习流水线每日生成，坚持即学即记。
评论