提示词与任务拆分

好的提示词不需要很长，但要明确目标、范围、约束和验收。一次只改变一个可观察结果，通常比同时要求重构、换资源和发布更可靠。

推荐模板

先给目标和边界，再用运行结果验收每个小任务

Goal: <the single observable result to change>
Context: <files, scene nodes, Inspector references, or errors>
Scope: <files you may read and edit>
Constraints: <versions, dependencies, or behavior to preserve>
Acceptance: <observable results after running the game>
Process: analyze first, present a plan, and wait for confirmation before editing.

例如，扩展 Pink Demo 时可以拆成：

1. 只解释场景组件引用和当前点击计分链路，不修改文件。
2. 只把初始目标位置改到画面中心：调整脚本的 TARGET_POSITIONS[0]，并同步场景中 Canvas/Target 的初始坐标；保持其余四个位置和动画时序不变，验证启动及重置后的目标位置。
3. 只调整场景中 Canvas/ResetButton/Label 的文字，保持脚本、节点名、组件引用和行为不变。
4. 最后统一检查场景、脚本、资源引用和构建结果。

静态文字和布局在场景中修改；分数、固定路线和重置规则在脚本中修改。resetGame() 会把目标移到 TARGET_POSITIONS[0]，因此仅修改场景中的目标坐标，会在运行时被覆盖。任务范围应包含真正决定结果的文件。

拆分原则

• 一个任务只有一个主要结果。
• 每一步都能独立运行或检查。
• 高风险操作与普通代码修改分开批准。
• 先修首个错误，再处理后续连锁错误。
• 将“构建成功”和“游戏行为正确”作为两个验收阶段。