石扬在访谈里给了一个很具体的判断：AI 能做出前后端分离的贪吃蛇，但直接让它做“抖音”就做不出来；复杂度越大，能力衰减越明显。他的做法是把大目标拆成上千个 task，比如“先建库表、结构是什么样”，让每个问题都降到贪吃蛇那个复杂度再问 AI⁠1。这解释了为什么提示词写得再漂亮，如果一次交给 AI 的任务本身太大，产出质量仍然会差。对游戏开发来说，可以先拆成玩法规则、数值、状态机、存档、UI 等小块，逐块让 AI 做。

石扬还指出，即使能问出好问题，过程仍会出错；有专业技能的人能一眼识别问题、换个写法就过去，没有代码经验的人则“两眼一抹黑”⁠1。他也提到 coding agent 一次可能生成极长的内容，review 远比 typing 重要，难点是怎么快速找到犯错的位置⁠1。立正在另一篇里把这类差距归为递进关系：能不能产出可用结果、能不能判断质量是基础，后面才是把完整任务交出去、把经验变成系统⁠2。所以对你来说，提示词和 skill 只是表层；更关键的是建立“能判断这段代码对不对”的机制，比如让 AI 解释改动、写测试、分步提交，而不是一次生成一大坨再整体看。

立正在一篇社区文章里说，Vibe Coding 内容最容易展示“从想法到第一版”的速度，却很少展示“从第一版到可靠系统”的漫长中段：权限、迁移、数据、异常处理、长期维护⁠3。他还提到，如果一开始描述清楚项目、和 AI 一起先做规划，理论上会更好，但也许不如自己脑子里架构清楚来得有效⁠4。这两点合起来看：规划值得试，但不能替代你自己对项目结构的把握。对策划出身的你，可以先把自己最擅长的部分——玩法规则、数值关系、玩家体验——写成清楚的规格，再让 AI 按规格实现；这是 AI 对你这处境的推演，不是原文结论。

立正把“系统性判断质量、诊断问题”列为 AI 使用者与 AI Builder 的关键差距之一：普通用户只能感觉“差不多”，出问题就换个 prompt 再试；有判断力的人则有明确验收标准，能定位根因、针对性修复⁠1。他给出的做法是 Evaluation Design：把“看起来还行”换成可执行的问题，比如是否满足某个条件、是否避免了某类错误、是否覆盖关键边界情况、是否符合预期格式与约束。标准一旦清楚，AI 就不只是生成，还能在输出前先自检⁠1。这对你的处境很关键：你不需要读懂每一行代码，但可以把“这个功能该怎样才算对”写成几条可核对的检查项，让 AI 逐条回答。

立正强调 AI 失效不是一种问题，而是几类本质不同的问题，不能用一套万能动作解决：context 缺失会导致编造，context window 饱和会丢信息，指令歧义会让方向偏，任务超出模型能力则要换模型、换工具或降低复杂度⁠1。他还提到可观测性：黑盒输出几乎不可调试，要让工具调用轨迹、阶段性产物、自检结果、失败原因和修正动作都可见，问题才能在早期暴露⁠1。应用到你身上，可以要求 AI 在改代码前先说明“你认为问题属于哪一类、依据是什么、打算改哪里”，你再用游戏策划熟悉的方式核对它的推理是否自洽。这是 AI 基于上述判断给出的应用建议。

石扬在访谈中说，vibe coder 能让 AI 做出前后端分离的贪吃蛇，但让它直接做抖音就做不出来；问题复杂度越大，能力衰减越明显。他的办法是把大任务拆成很多小任务，比如先建库表、先定结构，让每一步的复杂度接近“贪吃蛇”⁠2。他还说，过程仍会出错，有专业经验的人能一眼看出“不要这么写、换一种方式”，没有开发经验的人则无从判断⁠2。这解释了为什么你现在的反馈闭环难建立：不是你不会反馈，而是任务颗粒度太大，错误藏在一大段生成物里。把任务拆到你能用设计语言描述验收的程度，AI 的错误才会变成你能看见的具体问题。