PinK 使用测评：一个 750×1500 的环形倒计时，烧掉 50.98 元体验金
测试对象：PinK Alpha · 0.0.1.37
模型：Gemini-3.1-Pro（中级）-> Opus 5（高级）
引擎：Cocos 4
任务：10 秒顺时针环形倒计时 + 底部计数按钮
先说结论：PinK 的 cocos-cli 在「操作场景与界面」这件事上，确实比 Codex + Cocos MCP 模式更准确、更快——这是本次测试最大的正收益。但代价也很直白：token 消耗极大，且模型对需求细节的遵从度并不稳定。一句话总结这次体感：上限很高，下限也很低，中间全是Token。
一、测试任务：简单到没有借口
我的需求：这是新游戏，分辨率为750*1500，正上方是一个圆环形状的进度条，顺时针倒计时10秒，正下方是一个按钮，每点击一次记录一次+1
我故意压到一个新手 Demo 级别的规格，目的是把变量控制在最小：不测游戏玩法，只测「界面实现 + 资源集成 + 需求遵从」这三条 PinK 的能力。
-
分辨率：750 × 1500
-
顶部：圆环形状进度条，顺时针倒计时 10 秒
-
底部：一个按钮，每点击一次记录一次
+1 -
要求模型生成缺失的图片资源
附带一个关键前提：**Cocos 里的环形进度条，标准解法是 Sprite + Fill Type = Radial（Filled）。
二、完整时间线：四个回合，一次换模型
第 1 回合 · 初跑
Gemini-3.1-Pro 中级：任务跑完了，图没生出来
一句话丢进去，Plan 自动拆解，模型开始建场景、写脚本、挂组件。流程推进得很顺，功能层面全部完成——倒计时、按钮点击 +1 都对。但美术资源这一步是空的：交付物里的图片没有的，完全没有生图，可能是模型中档原因。
第 2 回合 · 补美术
让它补完资源：出来的是「全实体图」，不可用
我要求它补齐图片。它确实画了：一张圆环进度底图、一张按钮图。问题在于无透明通道——环形进度条要的是可程序化裁剪的填充环，它给的是一整块实心图形。这种图没法做径向填充，等于白给。
这一步暴露的是生图与引擎之间的语义断层：模型知道要「一张环」，但不知道 Cocos 的 Sprite Filled 要消费的是什么形态的图。
第 3 回合 · 我下场
自己做了两张环图塞进 image，结果被当成两张装饰图
我直接给了两张圆环图丢进去，明确说「用这两张做环形进度条」。模型很听话地用了这两张图——但是用错了：它把两张环图分别做成「圆环节点」和「按钮点击效果图」，没识别出哪张是底图、哪张是进度条填充环。此时问题已经从「图对不对」升级为「它根本没理解这个控件的结构」。
第 4 回合 · 换模型
Gemini-3.1-Pro 中级 → Opus 5 高级：高级模型一眼看穿
我感觉可能模型中级确实不太行。直接拉到最高的模型，换到 Opus 5（高推理）重跑，结果几乎是立刻反转：
环形进度条应该用 Sprite 的 Filled（RADIAL）来做
——一张静态圆环底图叠加快照填充进度图，
用 FILLED + RADIAL 径向裁剪。
高级模型直接把正确架构说出来了，然后开始漫长地改场景节点、改脚本、调 Fill Center 与 Fill Amount。这个回合耗掉的时间最长，但方向从头到尾是错的这一条不存在了。
三、费用账单：最刺痛的一段
测试结束时余额 ¥49.02，全部为体验金。也就是说这一趟原型，体验金净消耗约 50.98 元。
| 阶段 | 模型 / 推理 | 结果 | 体验金消耗 |
|—|---|—|---
| 自动 Plan + 建场景 + 写脚本 | Gemini-3.1-Pro / 中级 | 
功能完成 | ≈ ¥11.00 |
| 补生成缺失图片资源 | Gemini-3.1-Pro / 中级 | 
无生图 | — |
| 生图重试（全实体、无透明） | Gemini-3.1-Pro / 中级 | 
不可用 | — |
| 改用我提供的两张环图 | Gemini-3.1-Pro / 中级 → 高 | 未区分底图 / 填充环 | — |
| 换 Opus 5 重跑并重构 | Opus 5 / 高级 | 识别 Filled + Radial 方案 | 占大头 |
| 合计 | | | ≈ ¥50.98 |
钱到底烧在哪了
-
冷启动最贵。 从零开始做 Plan、生成设计文档、创建场景，这一口气就烧掉 11 块多——这是 Agent 模式的结构性成本：它要先把整件事「想一遍」。
-
返工是放大器。 Gemini 跑偏之后换 Opus 整段重跑，前面花的 token 等于沉没成本。模型越贵，返工代价越陡。
-
高级推理是默认烧钱模式。 一旦选「高」，每一步工具调用都带着长链推理，Demo 级任务也不便宜。
四、横向对比：PinK vs Codex + Cocos MCP
我日常用 Codex + Cocos MCP 做同类事情，所以这部分结论是可比的，不是空口评价。
| 维度 | PinK（cocos-cli） | Codex + Cocos MCP |
|—|---|—|
| 操作场景 / 界面 | 
显著优势：建场景、挂组件、调节点属性，准确度和速度都更好 | 能完成，但节点操作链路更绕，容易在组件属性细节上反复 |
| 一句话冷启动 | Plan 自动拆解，端到端更快（但「快得有限」） | 需要更多手动引导，节奏可控但慢 |
| 需求遵从度 | 会漏硬指标（分辨率 750×1500 始终没改设计分辨率） | 逐条给约束，遵从度反而更稳 |
| 成本 | 高，Agent 自主跑动，token 消耗大 | 相对可控，步骤由人拆解 |
| 可解释性 / 可控性 | 弱，跑偏后只能换模型或硬纠 | 强，每步看得见、可回退 |
| 生图集成 | 有，但本次实测未产出可用图 | 无原生生图，靠外部管线 |
能力评分（AI自我评分，10 分制）
| 维度 | 评分 | 说明 |
|—|---:|—|
| 场景操作准确度 | 9.0 / 10 | 这是它最该赢、也确实赢了的一项 |
| 端到端速度 | 7.7 / 10 | 快，但快得有限 |
| 需求遵从度 | 5.2 / 10 | 硬指标会被整段忽略 |
| 成本效率 | 3.8 / 10 | 冷启动 + 返工双重消耗 |
| 生图→引擎集成 | 3.0 / 10 | 语义断层，本次未产出可用图 |
| 稳定性 / 成熟度 | 4.5 / 10 | Alpha 阶段，符合预期 |
五、那个没被修好的「设计分辨率」
本次最值得单独拎出来的一条：我明确要求 750×1500，跑完全部回合，项目设置里的设计分辨率始终没有被改。
这个坑是有官方出处的，也是我判断「属于 CLI 能力边界」的依据：
-
设计分辨率在
项目 → 项目设置 → 项目数据里设置 -
Canvas 的 Content Size 应等于设计分辨率；锚点建议 (0.5, 0.5)
-
竖屏推荐
FIXED_HEIGHT，Widget 用ON_WINDOW_RESIZE -
而
750 × 1500是非标准尺寸，比常见的 750×1334 / 720×1280 更高
归因判断：这更像「模型没把分辨率当硬约束」，而不是「CLI 改不了」。 设计分辨率本质是改项目配置文件 + 设 Canvas UITransform，对 cocos-cli 这类 Agent 工具来说是可执行操作。模型全程没有调用这一步，说明它把「750×1500」当成叙述性描述吞掉了。唯一存疑的是：PinK 当前 Alpha 版本的 CLI 对「项目级设置」这类非场景节点的操作覆盖是否完整，这点我无法确认——需要官方或更多样本验证。
可以绕开的变通做法：
让设计分辨率 = 750 × 1334，Canvas 用 FIT_HEIGHT；
倒计时环的圆心固定在上方、按钮 Widget 挂 Bottom。
把 750×1500 做成「安全区内的纵向扩展版」，
而不是硬改全局设计高度。
这是 Cocos 里更主流的适配思路。如果任务一开始这么写，大概率不会被漏掉——换句话说，把工程术语喂进去，模型遵从度会明显提高。
六、换模型这件事：结论很清晰
这次测试最有价值的产出，是拿到了一次几乎干净的对照：同一份需求、同一套资源，Gemini-3.1-Pro 中级和 Opus 5 高级的表现差异，远大于模型标称分数的差距。
| 环节 | Gemini-3.1-Pro（中级 → 高级） | Opus 5（高级） |
|—|---|—|
| 读需求 | 功能做完了，细节漏一半 | 识别到「环形进度条」是个复合控件 |
| 读资源 | 两张环图无法区分角色 | 主动提出底图 + 填充环的双层结构 |
| 技术选型 | 没提 Sprite Filled | 直接给出 FILLED + RADIAL + 径向裁剪 |
| 代价 | 便宜、快，但会整段返工 | 贵，改动量大，但方向正确 |
我的使用策略（实测后形成的）：
-
冷启动 + 宽上下文 + 成本敏感 → 用 Gemini-3.1-Pro 中级：建项目骨架、批量挂组件这类「面广、并行」的事它更划算。
-
关键控件实现 + 深度调试 + 需求陷阱 → 上 Opus 5 高级：它更不容易犯「理解错问题」这种代价最大的错误。
-
一句话总纲：别让便宜模型去做需要领域知识的关键一步。 那 11 块的冷启动费省下来，会在后面用三倍 token 还回去。
七、最终结论
PinK 值得用，但要按「原型加速器/辅助工具」而不是「自动开发工具」来用，或者要期待公测后大家贡献的SKILL让它更接近自动开发工具。
它在场景和界面操作上的优势是真实的，这也是 Cocos 官方把引擎与编辑器拆开、用 cocos-cli 做 Agent 编排层之后最该赢的地方（上层 Agent 编排 → MCP 协议层 → 引擎执行）。Codex + Cocos MCP 的模式更可控、更省钱，但那条链路里每一步都要人推；PinK 是它自己跑，代价是把不确定性交给了模型。
本次 50.98 元换来的教训很具体：
-
需求写得像工程文档，别写得像需求描述——把「Filled + Radial」「FIXED_HEIGHT」「底图 + 填充环」写进去，遵从度立刻不同。
-
关键步骤用贵模型，别让便宜模型决定架构方向，返工费远超差价。
-
默认把设计分辨率、适配策略、资源通道格式写进第一条提示，这三项是最容易被整段忽略的。
-
把它定位成原型工具：快速出可玩 Demo 是它的主场，生产级交付还为时过早。
