今日速览
- DeepSeek 写代码翻车，八成不是因为模型笨，而是它在「不了解你项目」的情况下硬猜：猜错节点名、猜错 Godot 版本、猜错你已有的单例。
- 解法是上下文工程：先沉淀一份可复用的「项目说明书」（Project Brief），每次提问都贴上，模型输出的准确率会明显上台阶。
- Godot 官方目录规范（
snake_case文件名、PascalCase节点名、addons/放第三方、.gdignore忽略文件夹）正好就是这份说明书里该固定的「项目约定」。 - DeepSeek API 的上下文缓存（Context Caching）默认开启：如果把「系统提示 + 项目说明书」放在消息最前面、保持不变，重复前缀会命中缓存，既快又省 token。
- 好提示词的共同点：给角色、给上下文、给明确输出格式、给约束、并允许模型「不确定就反问」。
核心学习内容
1. 为什么”好提示词”救不了”没上下文”
我们常把提示词当咒语，其实 DeepSeek 写游戏代码的瓶颈在信息差：它不知道你的场景树长什么样、不知道你用的是 CharacterBody2D 还是 RigidBody2D、不知道你已经有 GameManager 单例。上下文缺失时，模型只能用「最可能的通用写法」补全，于是给你一段看起来对、跑起来报错的代码。
所以正确的顺序是：先给上下文，再给任务。上下文是地基，任务是墙。
2. 项目说明书（Project Brief）：一次整理，天天复用
花 30 分钟整理一份「项目说明书」，之后每次提问直接粘贴。内容建议固定这几块：
- 引擎与版本：Godot 4.7 / GDScript（不是 3.x，也不是 C#）。
- 目录与命名约定：遵循 Godot 官方规范——文件夹与文件用
snake_case，节点名用PascalCase，第三方插件统一放/addons/，素材尽量靠近使用它的场景放。 - 全局结构：Autoload 单例清单（如
GameManager、EventBus、SaveSystem）及各自职责。 - 约定与避坑：坐标手感（像素/秒）、输入映射名（
move_left/jump）、是否用信号解耦、禁用哪些 API。 - 代码风格：静态类型标注、注释语言、区间偏好。
这份说明书不用长，一页以内最好，但必须准确——它是 DeepSeek 的「项目记忆」。
3. 上下文缓存：让”贴上下文”这件事不肉疼
很多人担心”每次都贴一大段项目说明会不会很贵”。DeepSeek 的上下文缓存给了答案：缓存默认开启、无需改代码。规则很关键——缓存只匹配前缀，命中要求后来的请求和之前持久化的前缀单元对齐。实践含义就一句话：
把「固定不变的内容」（系统提示 + 项目说明书）永远放在消息最前面且一字不改，把「每次都变的任务」放在后面。
这样多轮对话里，前一轮的 A+B 会成为缓存前缀，下一轮 A+B+C 就能命中 A+B。反过来，如果你把任务写在前面、说明书写在后面，或者每次微调说明书措辞，缓存就废了。用响应里的 prompt_cache_hit_tokens 还能自检命中情况。
🎯 DeepSeek 提示词
提示词 1：生成/刷新《项目说明书》
适用场景：项目刚起步，或结构变动后想重新生成一份可复用的上下文底稿。
你是一位资深 Godot 4 游戏工程师。下面是我项目的文件树与关键脚本片段，
请帮我整理一份**《项目上下文说明书》**，供之后每次请 AI 写代码时粘贴使用。
【我的项目信息】
- 引擎：Godot 4.7，语言：GDScript
- 文件树：
<粘贴 tree 输出，或在文件系统里手动列出关键目录>
- Autoload 单例：
<粘贴 Project Settings > Autoload 里的条目>
- 关键脚本片段：
<粘贴 2-3 个核心脚本的核心部分，可省略实现细节>
【输出格式】严格按以下 Markdown 小节输出，总长度控制在 400 字以内：
1. 引擎与版本
2. 目录与命名约定（列出实际使用的约定）
3. 全局单例清单（名字 + 一句话职责）
4. 关键约定（输入映射名、坐标单位、信号解耦方式等）
5. 代码风格（类型标注、注释规范）
【约束】
- 只描述你从我给的信息中**能确认**的内容，推断项要标注「（待确认）」。
- 不要输出任何代码实现，只要说明书。
- 用中文回答。提示词 2：带上下文写一个新脚本
适用场景：给游戏新增一个功能模块（如”受伤闪烁 + 无敌帧”）。
你是资深 Godot 4 游戏工程师。请基于下面的《项目上下文说明书》写一个新脚本。
【项目上下文】
<粘贴提示词 1 生成的说明书全文>
【任务】
写一个 `HitFlash.gd`（Node 组件），挂在角色身上，实现：
- 受到伤害时角色精灵快速闪烁 3 次（0.1s 一次），随后进入 1.0s 无敌；
- 无敌期间 `is_invulnerable = true`，并用 mask modulate 半透明表示；
- 对外暴露一个方法 `take_hit(damage: int)` 和信号 `invulnerable_ended`。
【输出格式】
1. 先输出完整 GDScript 代码（一个代码块）；
2. 再输出「如何在场景树中接入」的 3 步操作说明；
3. 最后列出你用到、但说明书中未定义、需要我确认的地方。
【约束】
- 只用 Godot 4.7 真实存在的 API，禁止编造方法名；
- 使用静态类型标注；用信号而非直接引用其他单例耦合；
- 若说明书未覆盖某个决定（节点路径、组名等），**停下来提问，不要猜**。提示词 3：让 DeepSeek 先”复述理解”再改代码
适用场景：报错排查、重构，避免 AI 改错地方。
你是一位严格的代码审查员。下面是项目上下文、一段现有代码和一个问题。
【项目上下文】
<粘贴说明书>
【现有代码】
<粘贴脚本，或粘贴报错堆栈 + 相关函数>
【问题】
<粘贴 Godot 报错信息 / 或描述你想要的改动>
请严格按三步回答：
第 1 步 — 用 3 句话复述：你认为这段代码在做什么、报错/问题的根因可能是什么。
第 2 步 — 列出 1-3 个你**不确定、需要我确认**的点（如节点路径、信号连接方式）。
第 3 步 — 给出修改方案：以 `diff` 风格或整段替换的形式给出改后代码，并说明改了哪几行、为什么。
【约束】
- 不确定的地方必须提问，不允许「为保证可运行而假设」；
- 禁止编造 Godot API；若某 API 你不确定签名，请明确说「需查文档」；
- 保持我的代码风格（类型标注、命名约定）。学习心得
回到终极目标——「用 DeepSeek 做一款能上架 Steam 的游戏」。真正拉开效率差距的，不是你会不会写”高级咒语”，而是你有没有把项目沉淀成一份稳定、可复用的上下文。今天这招的本质，是把「和 AI 的临时对话」升级成「和 AI 的长期协作」：说明书是它的入职手册，缓存是它的长期记忆，而”不确定就问”是把幻觉挡在提交之前。明天就把这份说明书建起来，你会立刻感到 DeepSeek 写的代码变”懂你”了。
明日关注
- 照提示词 1，为当前项目实际生成一份《项目上下文说明书》，存成
docs/ai_brief.md并纳入版本控制。 - 用提示词 2 新增一个小功能，对比”贴上下文”前后的代码可用率差异，记录命中感受。
- 查 DeepSeek 响应里的
prompt_cache_hit_tokens，验证”固定前缀放最前”是否真的命中缓存。
本文由自动化学习流水线每日生成，坚持即学即记。
评论