提示词写多长，问的其实是「颗粒度到哪一层就该停」。判断依据不是字数，而是返工出现在哪一层：如果每次生成都要回头修规则判定，说明规则层没写够；如果反复修的是动画时长、按钮位置、分数字号，说明已经写过头了。下面的做法是先把一句话版本存成基准，再逐层加长，用同一玩法对比三次生成结果，最后按返工点归类决定停在哪一层。具体产品版本的输入框长度、字段命名可能有差异，接入时以你当前使用的环境为准。
适用场景：用 AI 生成小游戏原型，反复因为「描述太泛」或「描述互相打架」返工。操作动作：先写一句话基准版，再扩成输入/规则/反馈三段，最后补失败、计分、时长、重开四类边界，同一玩法跑三个颗粒度并记录返工处。验证方式：看返工点是否从规则类转移到表现类。风险边界：规则之外的手感、数值、UI 位置建议留在生成后手工调，硬塞进描述容易让约束互相冲突。
先写下最小可用的一句话需求
先给一个只包含玩法类型和目标的单句，例如：「做一个玩家左右移动接住掉落水果、漏掉三个就结束的小游戏」。把这句话原样保存，后面所有加长版本都跟这一版对比，否则你无法判断多写的那几段到底换来了什么。
这句话通常能生成到「能动」的程度：角色能左右移动，有物品掉落，有碰撞，漏掉会结束。缺的部分也很明确——没有计分口径（接住加几分、漏接扣不扣），没有难度变化（掉落速度是否随时间加快），没有结束后的界面（是停在画面上还是弹出重开按钮），手感数值也基本靠默认。把缺什么列成清单，就是下一层要补的内容。
把玩法拆成输入、规则、反馈三段
把描述从一句话扩展成结构化的三段，每段只回答一个问题：玩家做什么、系统怎么判定、玩家看到什么。三段分开写的好处是改一处不会牵动另外两处，生成结果里规则跑偏时你能直接定位到规则那一行，而不是重写整段。
输入：玩家用左右方向键控制角色水平移动，移动范围限制在屏幕底部。
规则：水果从顶部随机位置下落，角色与水果碰撞即为接住；水果落到底部外判定为漏接；漏接累计三次结束本局。
反馈：接住时水果消失并在顶部加分数字，漏接时屏幕底部闪一次红色边框。三段的顺序建议固定，生成时也便于你一段一段加。每加一段前先只跑一次，确认上一段的判定还对，再往下写。如果发现「规则」和「反馈」里对同一件事有两种说法（比如规则说漏接三次结束、反馈说漏接就闪红并结束），就先统一口径再生成，冲突的约束通常会被随机挑一条执行。
再补状态与边界：失败条件、计分、关卡结束
生成结果最容易缺的就是收尾逻辑，因为这类描述不写也不会报错，只是玩起来没头没尾。至少补下面四类，每类一句话即可：
- 失败条件：写清触发阈值和触发后发生什么。示例：「漏接达到三次时本局结束，角色停止响应按键。」只写「会失败」通常生成不出可判断的条件。
- 计分方式：写清加减分口径，以及是否区分物品。示例：「接住普通水果加 1 分，接住金色水果加 5 分，漏接不扣分。」
- 单局时长：写清是计时制还是生命制。示例：「单局以生命耗尽为结束，不设倒计时。」两种都写会让结束条件互相覆盖。
- 结束与重开：写清结束界面上有什么、怎么回到开始。示例：「结束时显示本局得分和最高分，按空格键重开。」
补完这四类后再生成一次，重点看结束流程是否完整走通：能不能结束后真的停下来，能不能重开后分数归零。这一步的验证成本低，但能挡掉大部分「看起来能玩、其实玩不完」的结果。
用同一玩法分别试三个颗粒度并记录返工点
固定同一个玩法，分别用一句话、分模块、分状态三个颗粒度各生成一次，每次生成后记一行。记录字段建议固定成四个，方便横向对比：
颗粒度等级 | 生成轮次 | 返工处 | 返工原因
一句话 | 第 1 轮 | 结束逻辑 | 描述里没有失败与重开
分模块 | 第 2 轮 | 计分口径 | 没写漏接是否扣分
分状态 | 第 3 轮 | 难度曲线 | 写了但生成结果未体现
分状态 | 第 4 轮 | 按钮位置 | 属于可手工调整项统计时不要数总返工次数，按性质归类：规则类（判定条件、结束逻辑、计分口径）、数值类（速度、频率、分数权重）、表现类（UI 位置、动画、音效）。规则类返工在分模块之后通常就归零，说明这一层写够了；数值类和表现类在继续加长的版本里仍会反复出现，说明这两类继续往描述里塞，收益有限。判断依据是同一类返工有没有随颗粒度提升而减少，而不是描述写到了多少字。
确定自己的颗粒度上限
给自己设几条停止线，比凭感觉决定写多少更稳定：
- 描述里出现超过三层嵌套约束（比如「当 A 且 B 时，若 C 则 D，否则 E」），就拆成两次生成，先出基础玩法，再用一句补充条件。
- 同一段里两句话对同一行为给出不同结果，先合并口径，不要指望生成方替你取舍。
- 连续两轮生成后，新加的细节都只影响表现层，就停止加长，转去手工调整。
可以交给后续手工调整的细节类型包括：具体速度与频率数值、动画时长与缓动、音效、按钮和文字的位置、配色、关卡数量与难度曲线、最高分存档方式。这些内容改起来成本低、不影响玩法判定，写进描述反而会挤占规则表达的空间。反过来，判定条件、结束逻辑、计分口径、输入方式属于必须写进描述的，因为它们决定玩法能不能成立。按这个分界划一次，你大概就能确定自己在这个玩法上的颗粒度上限在哪里。