一个具体案例是：孩子让 AI 生成僵尸割草游戏，很快得到能玩的版本，但玩腻后发现没有终点、Boss 太强、双方都打不死对方。AI 能生成“能运行的游戏”，好不好玩仍要由人判断。之后他开始改数值、让 AI 出平衡方案、保存修改记录，并具体定义终点、难度、例外和胜负条件⁠1。这说明快速做游戏的第一步不是追求完整，而是尽快拿到可玩版本，再用真实体验找问题。

另一位嘉宾刘希元讲他和孩子做塔防游戏时，把 game design doc 直接交给 AI，后续加故事、生成四格漫画都基于同一份设计，不必每次从头解释游戏是什么⁠2。立正在同一段对话里把这概括为 document first：所有东西都来自 prompt，就要把 prompt 整理好、保持上下文⁠2。他还提到，做游戏时值得先产出的中间件包括世界观、游戏参数、素材风格、角色圣经，并且要达到可用于生产的质量，再由人制定评估标准和终点线⁠3。这是 AI 对两段材料的综合：先有稳定的设计资产，AI 的多次生成才不会互相打架。

刘希元描述过一个可操作的做法：花一小时专门优化美术风格，先让 agent 找市面上的类似游戏，一起看预告片筛选，排除 3D、选定蜡笔风，再让 Claude Code 写出 art style spec，交给 coding agent 重写，画面出现很大变化⁠2。数值平衡也有更系统的做法：把资深策划的判断拆成静态规则检查和 AI 模拟上万局的动态检查，改完配表几分钟拿到诊断⁠4。立正还提出，AI 让原型变便宜后，应更早让核心玩家试玩，用反馈决定手感和关卡，而不是只让自动化测试追赶开发⁠5。对想快速做游戏的人，这意味着可以把“做出来”拆成美术、数值、试玩几个可单独推进的小任务。

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 基于上述材料给出的应用建议。