这个框架是一个故意设定的基线，不是一个意外的前置画面。 我要求Makeplay为一辆快递自行车的固定夜市场景提供六个摊位、三个顾客、灯笼、湿路面、招牌、箱子和蒸汽。 提示还要求它混合像素详细程度和轮廓权重。 结果给我提供了同时出现的多种不匹配的情况。 某些摊位招牌是空白的光滑方形，而其他的则密集难以阅读。 顾客图像在尺寸和轮廓上存在不一致。 蒸汽、反射、箱子、灯笼和标题都在同一帧中竞争。 我无法仅凭帧就确定哪种变体应该在清理后存活下来。 一个摊位的厚轮廓可能是有用的层次结构而不是噪音。 小顾客可能需要更多对比而不是更多像素。 还没有后图像。 目前这只是一个实际艺术过渡所必需的决策地图。 我想看看一个非常小的游戏概要会做什么，所以我写了一句话。 引导一只纸船通过浮动的闸门之前的计时器结束。 Makeplay将其转化为一个功能性的浏览器游戏，包含12个闸门、42秒时钟、多个控制选项、当前进度、计分、奖励、生成的艺术和音效。 大多数这些选择都是合理的。 没有任何一项是被要求的。 有用的教训不是工具添加了太多。 我的句子描述了一个目的地，但包含了无边界。 我将数量、控制方案、失败规则、视觉范围和反馈系统留在未定的状态，然后在心里把它们当作已经确定了。 我的无代码清单现在有两列。 第一列说什么必须发生。 第二列说什么不应该被发明。 那个第二列做了更多的工作。