AI 怎么用来快速的做游戏

Zero 刘希元讲他带孩子做塔防游戏的经历：先花不少时间做 game design doc，让 Claude Code 以“游戏设计师”的身份反问——你想让游戏哪里不一样、怪走哪条路、塔能不能放在线上。孩子回答这些问题，才把设计想清楚⁠1。这说明文档里至少要有一句核心玩法和差异点，否则 AI 只能给一个通用塔防。

立正在讲 AI 产出能否直接用时的判断是：决定输出质量的不是 prompt 写得多漂亮，而是 AI 执行时看到了什么信息；项目规范、风格指南、验收标准、历史决策、约束条件都应写成 AI 可读的结构化文档，“读不到的信息就等于不存在”⁠2。他还强调指令要定义“做到什么算对”，而不是逐步遥控过程⁠2。放到设计文档里，就是除了玩法，还要写清数值基准、美术风格、哪些边界不能碰。

Zero 说拿到 game design doc 后，后面每一步都会引用它：加新塔时把整份文档作为 context 扔进去，AI 就知道已有什么、新塔该和旧塔一致；改关卡时以最早定下的塔数值为基准⁠1。加故事时也不用重新解释整个游戏，直接给文档即可⁠3。立正补充说，也要不断让 AI 帮忙更新这份 doc⁠1。这是 AI 对案例的归纳：文档的价值不在一次写全，而在被反复引用和修订。

立正把 AI 的能力边界讲得很清楚：AI 擅长处理“已经被定义过的好”，能执行设计原则、配色规范、评分标准，但它到不了标准还没形成的那一步。所以“看一眼就知道不对”的那种判断，仍然需要人在场⁠1,2。这不意味着风格无法写下来，而是说：写下来的只能是已经被你想清楚的那部分，剩下的靠人反复校准。

立正反复提到同一个诊断：AI 产出“差点意思”，不是 prompt 写得不好，而是它根本不知道你的标准——审美偏好、判断原则、过去的取舍、验收标准全在你脑子里⁠3,4。对应做法是 Document-First：把风格偏好、品牌调性、常用术语、过往案例写成 AI 可读取的结构化文档。他还指出，写这些文档的过程本身有价值，很多人是在写的时候才发现自己的“标准”从没被真正想清楚过⁠3。对美术风格来说，这一步就是把“感觉”逼成条目。

光有形容词还不够。立正提到，设计师给出的反馈不能只是“我想要更高级一点”“这个感觉不太对”，而要明确、结构化到工程师或 AI 能直接执行⁠5。在讲数据筛查时，他给了一个可迁移的结构：把人的判断标准写成 skill，持续加入成功案例和失败案例，再用 evals 量化测试，看换模型或改 prompt 后是变好还是变差⁠6。这是 AI 对上述方法的综合应用：美术 spec 可以写成“必须满足的几条 + 参考图（要的/不要的）+ 每条怎么算不合格”，让每次生成都能对照检查，而不是凭感觉打回重做。

立正在对话里说，对产品的感觉大多是在做的过程中才发生的，写 spec 没办法一下子写出完美需求；他还说人的大脑充满 hallucination，凭想象写出的需求往往残缺⁠1。Ryo Lu 也认为，设想时面对的是一个假想世界，看不到全部，所以最初的东西是残缺的⁠1。这直接决定了更新方式：风格标准的第一版只求能用来判断，不求完整；每做一个实际页面或角色，就对照它看哪里判断错了，再把修正写回去。

立正谈 landing page 时提出，最有力量的差异化是重新定义什么才算进步：先说清用户真正想取得什么进步，再让产品成为达到这种进步的路径⁠2。放到风格标准上，就是每次更新都问“这条改动让判断更准了吗”，而不是不断加配色、加动效、加参考图。Ryo Lu 评价一个作品时指出，太多颜色、太多东西在动、没有 focus，就是 AI slop 的典型表现⁠1。这类具体批评正好可以反过来写成标准里的负面条目。

立正把一次 Build 拆成作品账、故事账、商业账三本账，并提醒故事账结算最快，容易反过来决定选题⁠3。风格标准也一样：如果因为“这个版本好展示”就放宽标准，标准会越来越松。可以按他说的顺序，先做对项目真正重要的事，再把值得讲的部分讲出来⁠3。具体做法是：每次迭代后记录一条“这次实际做出来的东西，和标准哪里不符”，只改标准或只改作品，二选一，并留下理由。这是 AI 基于上述材料给出的应用建议。