与 AI 协作：把想法变成可验收的功能

你的目标不是记住每个 API，而是能判断 AI 是否选对系统、交代清楚配置，并考虑了失败情况。最有效的沟通单位通常是一个小而完整的功能。

一份需求包含七件事

“做一个很爽的点击效果”缺少可检查标准。可以改为：“按下目标缩至 90%，松开后 120ms 内恢复，立即加分；连点不累积缩放；结算后不能触发；低端真机上不造成明显卡顿。”

先要求方案，再做一个闭环

让 AI 先交付节点树、状态图、脚本职责、编辑器字段和资源清单。你能解释这张图后，再让它写代码。如果连代码挂在哪个节点都不清楚，继续增加脚本只会扩大装配困难。

建议每次按这四步推进：

1. 描述：使用具体规则，明确暂不实现的范围。
2. 审方案：检查平台、状态、资源与失败分支。
3. 实现：交付完整脚本与明确编辑器步骤，避免零散片段无法组合。
4. 验证：亲手执行验收，把实际结果与日志反馈给 AI。

三种高价值检查

AI 给出的方案	追问
新增一个脚本	挂在哪个节点？依赖哪些字段？谁调用它？
新增异步操作	失败怎样恢复？退出后结果怎样处理？
新增全局模块	为什么局部组件不够？跨场景资源谁负责释放？

再检查版本混用：cc.Class、cc.Action、2.x 的尺寸/层级写法不应未经核对进入 3.8.8 代码。让 AI 链接与你版本匹配的官方 API，而不是只说“网上通常这么写”。

一次只增加一个难点

先实现本地点击与结算，再做动画；本地存档正确后，再接云进度；广告先画状态，再接平台。这样出错时，变化来源可以定位。

需求变化时，让 AI 更新当前节点树、状态图和验收清单。不要只在长对话里追加“顺便加一个”，最后没有任何一份文档能说明实际系统。

你的检查能力比提示词长度更重要

你可以用后端经验检查幂等、状态与可信边界；用本指南检查帧更新、坐标、生命周期与资源；用开发者工具和真机检查平台差异。AI 无法替你从一段浏览器日志证明微信广告资格或低端机性能。

继续：可复制模板、故障报告、来源与验证。

依据：Creator 脚本入门、3.0 升级指南。协作流程是本文实践建议。