docs: 更新提示词

dev.md

@@ -135,7 +135,7 @@
 
 | 包                  | 层级    | 说明                                                                            |
 | ------------------- | ------- | ------------------------------------------------------------------------------- |
-| `@user/data-common  | Layer 0 | 公共层，定义 `IDataCommon` 及公共无依赖接口                                     |
+| `@user/data-common` | Layer 0 | 公共层，定义 `IDataCommon` 及公共无依赖接口                                     |
 | `@user/data-base`   | Layer 1 | 数据层，定义 `IStateBase` 及可存档游戏数据（地图、怪物、玩家属性等）            |
 | `@user/data-system` | Layer 2 | 执行层，定义 `ICoreState`，依赖数据层实现玩家控制、战斗计算等影响游戏进程的动作 |
 | `@user/data-state`  | Layer 3 | 数据端的顶层模块，一般仅用于初始化以及仅供渲染端调用的顶层模块                  |

prompt.md

@@ -7,30 +7,29 @@
 3. **以目的驱动，而非以接口驱动**：实现前先想清楚我为什么要这样设计接口、这个接口设计的目的是什么，而不是单纯地以将接口填满为目标。
 4. **遇到歧义立即提问**：若思考或实现时遇到任何问题——例如描述模糊、接口不清晰、某些地方存在歧义等——应立即向我提问，而不是按自己的想法去写。
 5. **接口缺失时停止并提问**：若完成需求所需的接口尚不存在，应立即停止实现，向我提出疑问，而不是擅自新增接口来推进。
-6. **按我说的方式重构**：若目标是重构某个接口，按照我指定的方式执行：
-    - **彻底性重构**（新旧接口完全没有重合）：按正常方式全新实现，旧代码仅作逻辑与思路上的参考。
-    - **结构性重构**（新旧接口基本一致，细节有差距）：将旧代码搬移到新接口上后进行微调。**不要**擅自新增任何参数、方法或接口，**不要**仅通过新增兼容层的方式应对重构。
-7. **不要有任何“顺手”的想法**：任何时候，都不要出现顺手的想法，包括但不限于发现了一个 bug，然后**顺手**修复、发现一处类型错误，然后**顺手**修复等，这种情况下应当遵循规则 1。
-8. **写完代码后说明修改内容**：写完代码后，必须在对话中说明自己修改了哪些内容，包括所有的文件及修改了每个文件的哪些东西。
-9. **关于 `dev.md` 中的一些补充**：为了提高代码质量和可读性，所有包含“一般不建议”或“尽量避免”等字样的，在此处要求为绝对不能使用，如果必须使用，需在使用前向我确认，`as` 关键字除外。所有包含“建议怎么做”或“最好怎么做”的内容，在此处要求为必须使用。
-10. **关于文件修改**：任何时候要进行文件修改时，务必重新阅读文件以确保上下文中的文件是最新版，因为我可能会在两次对话间修改文件。
-11. **参数最小化 / 级联获取**：不从外部传入可通过已有引用获取的对象。若对象已持有对父对象或相关对象的引用（如 `controller`），应直接通过该引用获取所需数据（如 `controller.state`），不应再单独传递参数。即“非必要不传参”。
-12. **转换下沉**：数据的格式或类型转换（如 `string` 的 id 转 `number`）应放在最终消费该值的对象中完成，而非在调用方预先转换后再传入。这样可以减少调用方的职责并避免重复转换。
-13. **通过公有接口操作，不直接赋值内部属性**：对某个对象内部状态的修改，必须通过该对象对外暴露的公有方法进行（如用 `mover.face(dir).start()` 设置朝向并发起移动），而不是通过类型断言访问其内部属性直接赋值（如 `mover.faceDirection = dir`）。
-14. **map/filter 优于 for 循环**：对数组进行数据收集或转换时（如收集 Promise），使用 `map`、`filter` 等函数式写法，比 `for` 循环 + `push` 的可读性更高。
+6. **按我说的方式重构**：重构时**不要**擅自新增任何参数、方法或接口，**不要**仅通过新增兼容层应对重构。
+    - **彻底性重构**（新旧接口完全没有重合）：按正常方式全新实现，旧代码仅作逻辑参考。
+    - **结构性重构**（新旧接口基本一致，细节有差距）：将旧代码搬移到新接口上后进行微调。
+7. **不要有任何"顺手"的想法**：任何时候，都不要出现顺手的想法，包括但不限于发现了一个 bug 然后**顺手**修复、发现一处类型错误然后**顺手**修复等，这种情况下应当遵循规则 1。
+8. **修改文件前重读文件，修改后说明内容**：修改文件前务必重新阅读以确保内容是最新版。修改后必须在对话中说明所有改动的文件及具体改动内容。在修改文件时，**不得修改**文档的 `涉及文件` 节未提及的文件。
+9. **关于 `dev.md` 的强度升级**：`dev.md` 中"一般不建议/尽量避免"的条目在此处视为**绝对禁止**；"建议/最好"的条目在此处视为**必须遵守**。`as` 关键字不受此升级约束。
+10. **参数最小化 / 级联获取**：不从外部传入可通过已有引用获取的对象。若对象已持有对父对象或相关对象的引用（如 `controller`），应直接通过该引用获取所需数据（如 `controller.state`），不应再单独传递参数。即"非必要不传参"。
+11. **转换下沉**：数据的格式或类型转换（如 `string` 的 id 转 `number`）应放在最终消费该值的对象中完成，而非在调用方预先转换后再传入。这样可以减少调用方的职责并避免重复转换。
+12. **通过公有接口操作，不直接赋值内部属性**：对某个对象内部状态的修改，必须通过该对象对外暴露的公有方法进行（如用 `mover.face(dir).start()` 设置朝向并发起移动），而不是通过类型断言访问其内部属性直接赋值（如 `mover.faceDirection = dir`）。
+13. **map/filter 优于 for 循环**：对数组进行数据收集或转换时（如收集 Promise），使用 `map`、`filter` 等函数式写法，比 `for` 循环 + `push` 的可读性更高。
+14. **渲染端永远处于被动**：任何情况下都不可能会出现数据端主动通知渲染端进行更新的场景，渲染端仅通过钩子与数据端通信，通过钩子被动获取信息，并在某些情况下影响数据端行为。
+15. **按设计实现，勿自由发挥**：我已想好功能的基本思路和代码结构，你的任务是还原它，而非自行创造。
 
 # 建议规则
 
 以下规则为建议性，尽量遵守，特殊情况下可灵活处理。
 
-1. **合理参考建议**：我有时会在对话中给出实现建议，应合理参考，切忌滥用。
+1. **参考但不盲从建议**：我给出的实现建议可作为方向参考，但不应不加思考地照搬。
 2. **以类型标注为参考依据**：实现与类型标注有冲突时，以类型标注（一般是 `types.ts`）中的内容为准。
 3. **发现接口问题时提问**：若认为类型标注中的接口设计有问题，或在实现中发现缺少某些接口，应向我提问是否添加，经我同意后方可添加。
 4. **接口设计兼顾合理性与便捷性**：设计接口时不仅要考虑合理性，还要考虑使用便捷性。罕见场景应当被支持，但不应与常见场景共用同一接口——这只会增加常见场景的使用难度。
-5. **避免多余的非空判断与类型守卫**：若某个类型已满足目标的类型约束，不应再对其添加任何判断或过滤操作。典型例子：`Promise.all` 对数组元素类型没有任何限制，传入 `(Promise<unknown> | void)[]` 完全合法，无需多此一举地写成 `Promise.all(arr.filter(v => !!v))`。
-6. **关于整个仓库的类型检查**：一般情况下**不需要**跑全仓库的类型检查，每个需求都是独立的，不会影响外部内容。只有在进行重构的时候才有此需求。
-
-**时刻谨记上述要求，避免一个需求反复修改仍无法满足预期。**
+5. **避免多余的非空判断与类型守卫**：类型已满足约束时不应再额外判断或过滤。例如 `Promise.all` 接受 `(Promise<unknown> | void)[]`，无需写成 `Promise.all(arr.filter(v => !!v))`。
+6. **关于整个仓库的类型检查**：单个需求**不需要**跑全仓库的类型检查，仅在重构时需要。
 
 # 开发流程
 
@@ -41,7 +40,12 @@
 
 ## 示例文档
 
-对于新增接口/彻底性地重构接口，按照以下格式编写，其余需求按照自己的理解去写即可。如某部分需要详细描述，可单独开设标题；若某个接口内容较多，也可以在文档中为其单独开一个章节进行讲述。我会使用引用块的形式在文档中提出建议或回答。Markdown 文档不需要刻意换行，我的编辑器有自动换行功能，正常写没有问题。文档保证简洁，不要过于啰嗦，但必须包含所有的必要信息，控制在 100-250 行，格式清晰，不要擅自修改示例文档的格式。一般情况下不需要画任何流程图，如果必须要画，使用 `mermaid` 图。不要在文档中使用引用块，因为这是我在给文档添加批注时使用的东西。
+对于新增接口/彻底性地重构接口，按照以下格式编写，其余需求自行组织。
+
+- 如有需要可单独开设标题章节详述。
+- 我会使用 `>` 引用块在文档中批注，因此**不要在文档中使用引用块**。
+- 文档控制在 100-250 行，简洁但包含所有必要信息，不擅自修改示例文档格式。
+- 一般不需要流程图；若必须画，使用 `mermaid`。
 
 ```md
 # 需求综述
@@ -50,11 +54,11 @@
 
 # 接口设计分析
 
-这是相当重要的一章。需要按接口逐一列出其方法与成员，分析每个成员和方法的预期使用频率（高 / 中 / 低）并说明判断依据；对于中频和高频成员，还需列出至少一个典型使用场景。必须认真分析频率，想明白**用户**调用的频率，而不是**引擎**调用的频率，比如战斗函数在引擎中可能是中频，但是对用户来说，用户一般会使用系统默认行为来战斗，而**不会**自己调用，因此属于低频。
+这是相当重要的一章。按接口逐一分析成员与方法的预期使用频率（高/中/低，指**用户编写此调用的频率**而非运行时频率），中高频成员需列出至少一个典型使用场景。
 
-**命名长度原则**：频率越高，成员名应越短。高频成员以一个单词为宜，最多不超过两个单词；中频成员不超过三个单词；低频成员可以稍长，但不宜过长。
+**命名长度原则**：高频 -> 一个单词；中频 -> 不超过三个单词；低频 -> 可稍长但不宜过长。
 
-**频率的定义**：此处频率指**用户编写此调用的可能性或频率**，而非运行时的调用频率。例如某成员每秒被调用千次，但整个游戏中只在一处出现过，仍属低频。
+我可能不会给完整接口设计，你需要自行分析需求补充设计，并在对话中明确指出哪些接口是你补充的。
 
 示例如下：
 
@@ -81,7 +85,7 @@
 
 ### 可能风险
 
-在任何时候，需要修改已有接口时，必须在文档中写明修改这一接口的风险。这里的已有接口指的是本次设计新增接口之外的接口，即所有已存在于代码中的接口。本章节**只写**关于修改已有接口可能导致的风险，例如导致大面积的类型污染、或部分其他接口会出现类型错误等，**不写任何关于实现的风险**，关于实现的风险应该写到最后的问题节，而不是这里。一些细小的内容不要写到这。如果没有任何风险，不要写无风险，直接跳过此章节。
+若需修改已有接口（即本次新增之外的接口），在此写明修改风险（如类型污染、其他接口出错等）。只写修改已有接口的风险，不写实现风险（实现风险放到问题节）。无风险则跳过此章节。
 
 # 实现思路