今日速览
- AI 写代码最大的债不是 bug，是”风格漂移”：DeepSeek 每次生成都自成一派，几十个脚本下来命名、缩进、空行规则全不一样，改起来比写还累。
- “审查”比”生成”更值得外包给 AI：生成要你先想清需求，审查只需要你贴代码——门槛更低、收益更稳，特别适合一个人做游戏时当”第二双眼睛”。
- Godot 官方给了现成的裁判标准：GDScript 风格指南（缩进用 Tab、函数/变量 snake_case、类名 PascalCase、常量 UPPER_SNAKE_CASE、私有成员加
_前缀、函数间空两行、数组/字典/枚举留尾逗号）。把这些喂给 DeepSeek，它就有了”尺子”。 - Godot 的对象观和普通 OOP 不一样：脚本和场景才是”可复用对象”，脚本本质是挂在引擎内置类上的 Resource（默认继承
RefCounted），所以审查时不能照搬纯 Python/PEP8 的思维。 - 审查提示词要”分级”：同一个脚本，先要一版”只列问题不动手”的体检报告，再要一版”高风险才修、低风险只标注”的补丁，避免 AI 大改把你的手感逻辑改跑偏。
核心学习内容
一、为什么”AI 代码审查”是单人开发者的刚需
用 DeepSeek 从零做 Steam 游戏，最大的陷阱是速度掩盖了混乱：一个下午能生成十几个脚本，但三周后你自己都认不出哪个 Player.gd 是最终版。这时再让 AI “重构”，它会把旧 bug 一起改坏。
正确姿势是小步审查：每完成一个小功能（一个敌人、一段 UI 逻辑），立刻把改动丢给 DeepSeek 审一遍。审查的目标不是”改写”，而是替你回答三个问题：
- 这段代码符合 Godot/GDScript 的官方惯例吗？（能不能被未来的自己一眼看懂）
- 有没有隐藏的坑？（空引用、信号重复连接、在
_process里做重活、类型不安全） - 这段逻辑该不该拆？（一个函数 80 行、一个脚本干三件事，都是”该拆”的红灯）
二、把官方风格指南变成”可执行的裁判标准”
Godot 官方 GDScript 风格指南（4.7 文档）给了非常具体的规则，摘几条最常踩的：
- 缩进用 Tab，不用空格；文件末尾留一个换行；用 UTF-8 无 BOM。
- 命名：类名
PascalCase，函数/变量snake_case，常量UPPER_SNAKE_CASE，私有成员前置_。 - 空行：函数与类定义之间空两行。
- 尾逗号：数组、字典、枚举最后一项加尾逗号，方便以后加元素、diff 更干净（单行列表不加）。
- 续行：多行函数调用用 2 级缩进区分；数组/字典/枚举续行用 1 级。
把这几条连同代码一起塞进提示词，DeepSeek 就不会”自由发挥”，输出可直接对照修改。再补上 Godot 的面向对象观——脚本和场景就是类，审查时优先看”这个逻辑放脚本里对，还是该做成一个独立场景/资源”，比只抠缩进值钱得多。
三、审查提示词的三个层次
- L1 体检（只读）：只输出问题清单 + 严重度，不改代码。用于快速判断”这坨能不能留”。
- L2 定向重构（只改高风险）：明确”红线问题才修，其余只标注”，防止 AI 顺手重写你精心调过的数值和手感逻辑。
- L3 架构体检（跨文件）：把 3–5 个相关脚本一起贴进去，问”职责划分是否重叠、信号方向是否混乱”，用于每个小系统收尾。
一个人做游戏，最有价值的产出往往不是新代码，而是每一段代码都被审过一遍。DeepSeek 免费、随时在线，把它当”每日代码审查员”，成本几乎为零，收益却是”项目三个月后还改得动”。
🎯 DeepSeek 提示词
提示词 1：GDScript 代码审查员（只列问题，不动手）
适用场景：写完一个脚本后，先做一次”体检”，看看有多少硬伤再决定改不改。
你是一位资深 Godot 4.x 游戏开发工程师，专精 GDScript 代码审查。
【任务】审查我贴出的 GDScript 脚本，只输出问题清单，不要改写代码。
【审查标准】按以下优先级：
1. 正确性：空引用、信号重复连接、在 _process 里做重活、节点路径硬编码、类型不安全。
2. 架构：单个函数是否过长（>40 行预警）、脚本是否承担了多个职责（该拆场景/资源）。
3. Godot 惯例：缩进用 Tab；类名 PascalCase、函数/变量 snake_case、常量 UPPER_SNAKE_CASE、私有成员前缀 `_`；函数/类定义间空两行；数组/字典/枚举使用尾逗号；优先 @onready + 类型标注。
4. 性能：每帧分配、频繁 get_node、字符串拼接、不必要的 process。
【输出格式】Markdown 表格，列为：行号 | 问题 | 严重度(🔴高/🟡中/🟢低) | 一句话建议。
表格后另起一段，用 3 句话总结"最该先修的 1 个问题 + 理由"。
【约束】只给建议，不要输出修改后的完整代码；不要评论我未贴出的文件。
【语言】中文。
代码如下：
（在此粘贴你的 .gd 脚本全文）使用说明：把脚本全文贴进最后位置即可。输出是”体检报告”，不改代码——你先自己判断哪些值得修，避免被 AI 带偏。
提示词 2：定向重构（只改高风险，保留手感数值）
适用场景：脚本能跑但结构乱，想让它变干净，又怕 AI 顺手改坏你调好的数值。执行前先 git commit。
你是 Godot 4.x 重构专家。请对下面的 GDScript 做"最小必要重构"。
【目标】在保证行为完全不变的前提下，提升可读性与可维护性。
【允许改动（仅限这些）】
- 拆分超过 40 行的函数；提取魔法数字为具名常量。
- 补类型标注、改 @onready 写法、统一命名与缩进到 GDScript 官方风格。
- 把硬编码节点路径改为 @export 或 @onready 引用。
【禁止改动（红线）】
- 不得修改任何数值常量的大小（伤害、速度、冷却、重力、跳跃高度等）。
- 不得改变函数签名、信号名称、节点名、导出的 @export 变量名。
- 不得删除任何既有功能，不得引入新依赖。
【输出格式】
1. 一段"改动摘要"（≤5 条）。
2. 完整重构后的脚本（用 ```gdscript 代码块）。
3. 末尾列出"我刻意没改的地方 + 原因"。
【约束】若某处不确定是否安全，宁可不改，并在第 3 部分说明。
【语言】中文注释、中文说明。
代码如下：
（在此粘贴你的 .gd 脚本全文）使用说明：红线写死”数值不改”，是防止 AI 把你要保住的游戏手感一起重构掉。产出后跑一次游戏对比手感，没问题再提交。
提示词 3：项目架构体检（跨文件职责划分）
适用场景：一个系统做完（如战斗、UI、存档），收尾时把相关脚本一起交审。
你是 Godot 项目架构评审员。我会贴出同一个系统相关的多个 GDScript 文件。
【任务】评估这个系统的职责划分与耦合情况，给出架构级建议（不逐行改代码）。
【分析维度】
1. 职责重叠：是否有两个脚本都在管同一件事（如都处理输入、都改血量）。
2. 信号方向：信号是否形成环（A 发 B、B 又发 A）？是否该用 Autoload 或显式事件总线。
3. 场景 vs 脚本：哪些逻辑更适合做成独立可复用场景（.tscn），哪些适合做成 Resource。
4. 数据与逻辑分离：数值/配置是否被硬编码在逻辑里，该不该抽到独立 Resource 或 JSON。
5. 可测试性：哪些函数可以抽成纯函数（不依赖节点树）便于单测。
【输出格式】
- 一张"模块职责表"：模块名 | 主要职责 | 疑似越界职责。
- 按 🔴🟡🟢 列出问题，每条给"最小改动方案"（一句话）。
- 最后给一个"推荐的下一次重构顺序"（3 步以内）。
【约束】不改代码，只给方案；如果整体架构已合理，就直接说"无需大改"。
【语言】中文。
文件如下：
=== file: Player.gd ===
（粘贴）
=== file: Health.gd ===
（粘贴）使用说明：一次别超过 5 个文件，否则上下文太散。它给的是”下一步怎么拆”的路线图，照着做能有效防项目膨胀失控。
学习心得
我一直在用 DeepSeek 疯狂产出代码，却很少回头审——这篇恰好补上了闭环。做一款能上架 Steam 的游戏，“写完”只是及格线，“改得动、调得顺”才决定它能不能撑到发布。 对我而言最大的启发是：把审查提示词做成固定模板存进仓库（比如 prompts/code_review.md），每完成一个小功能就 run 一遍——让 AI 审查成为流水线的一环，而不是心血来潮时的补救。这比多写十个功能更值钱。
明日关注
- 把「提示词 1 审查员」存成仓库里的固定模板文件，挑今天新写的 1 个脚本跑一遍体检。
- 给现有 GDScript 加类型标注与
@onready，对照官方风格指南统一命名与缩进一次。 - 研究 DeepSeek 对”贴报错日志 + 相关脚本”的 debug 能力，整理一版”报错定位”提示词模板。
本文由自动化学习流水线每日生成，坚持即学即记。
评论