背景
最近让Codex调整一个Cocos Creator游戏的启动界面，需求并不复杂：启动页增加标题、状态文字、百分比和进度条。Codex很快完成了功能，界面也能正常显示。
但我Review它的代码时发现，它的做法非常狂野，直接在代码中把我原有的节点给屏蔽掉，然后用new Node()动态创建节点，再动态添加Label、Sprite和ProgressBar等组件，结果本来几个简单组件的事情，最终写了一大堆代码。
从“能不能运行”的角度看，这个功能实现了。但从Cocos项目的维护方式看，这不是我想要的方案。我希望这些固定UI直接放在Scene中，脚本只通过@property绑定组件，并通过简单的代码来更新数值。
于是我连续补了几次要求：进度条不要动态创建，状态文字不要动态创建，标题也不要动态创建。Codex最终按我要求改对了，但这个过程说明了一件事：如果项目里有明确的Cocos开发习惯，最好在任务开始前告诉Codex，不要等它写完再逐项纠正。
一、为什么Codex容易选择动态创建
因为，动态创建对AI来说有几个天然优势。
第一，所有改动都集中在一个TypeScript文件中。它不需要同时处理Scene或Prefab的序列化数据，也不需要确认节点UUID和组件引用，完成任务更直接。
第二，这种写法很像网页开发。创建节点、设置属性、挂到父节点，是一种通用的程序化思路。大模型在没有项目规范时，很容易选择这种“只靠代码就能闭环”的实现。
第三，用户说“增加一个进度条”，并不等于“在Scene中增加一个Progress节点”。如果没有明确实现边界，动态创建和静态绑定都算符合需求，Codex只能自行选择。
但是，对于固定启动页、固定弹窗、固定按钮这类UI，动态创建会带来额外成本：
- 节点尺寸、位置、字体和颜色散落在代码中；
- 美术或策划无法直接在编辑器中调整效果；
- 脚本既负责业务状态，又负责搭建界面；
- 设计分辨率变化时，代码坐标更难维护；
- 以后排查层级、Widget和遮挡问题时，编辑器里的Scene并不能反映完整结构。
这也是为什么同样能运行，我仍然要求改成静态节点。
二、把个人习惯写成项目规则
最有效的方法，不是在每次对话里提醒，而是把规则写进项目的AGENTS.md或任务开头。
例如可以增加下面这段：
## Cocos UI规则
- 固定界面节点优先在Scene或Prefab中创建。
- 脚本通过@property绑定组件，只更新状态和数据。
- 除非节点数量由运行时数据决定，否则不要使用new Node()搭建固定UI。
- 修改Scene或Prefab后，要检查序列化引用、父子关系和组件绑定。这四条并不长，却能提前影响Codex的方案选择。
规则要写得具体，不能只写“保持代码简洁”。“简洁”有多种解释：Codex可能认为只改一个脚本最简洁，而你可能认为让Scene负责结构、脚本负责逻辑才最简洁。
因此，好的项目规则应该描述可观察的行为：节点放在哪里、代码负责什么、哪些做法禁止、修改后检查什么。
三、任务描述中增加“职责边界”
一般来说，增加全局规则后基本就可以了，但难保AI有时候会出现幻觉，所以，单次任务最好再写一次成功标准。
例如启动页需求可以这样描述：
在启动场景中增加标题、状态文字、百分比和进度条。
要求：
1. 所有固定节点直接创建在Scene中，不允许运行时new Node。
2. SpriteFrame、Label和ProgressBar都使用编辑器静态绑定。
3. 脚本只更新状态文字、百分比和progress值。
4. 不改变现有启动顺序。
5. 验证Scene JSON、父子关系、组件引用和TypeScript类型。这里最关键的不是把需求写得很长，而是把容易产生不同理解的地方提前封死。
“增加进度条”只是功能目标；“Scene静态节点、脚本只更新数值”才是实现边界。后者能显著减少返工。
四、静态绑定不是绝对规则
但是，也不是所有节点都应该放进Scene或Prefab。
以下场景仍然适合动态创建：
- 数量由数据决定的背包格子、排行榜条目；
- 需要对象池管理的子弹、伤害数字和特效；
- 编辑器中无法预先确定数量的关卡元素；
- 一次性调试工具或性能采样节点。
即使是这些情况，也通常应该优先实例化Prefab，而不是在业务代码中逐个添加组件、设置颜色和坐标。
判断标准很简单：如果这个节点在每次进入界面时都存在，结构固定，而且美术可能需要调整，它就应该优先静态配置。
五、总结
有时侯任务反复修改，并不是Codex能力不足，也不是实现了不能运行，而是人和它对“正确实现”的定义不同。
Codex理解的是：把功能做出来。
开发者需要的是：按照Cocos项目的可维护方式把功能做出来。
两者之间差的，就是项目规则和验收标准。
所以想让Codex写出符合个人习惯的代码，最省事的方法是把习惯变成它一开始就能执行的规则。