创作者视角：为什么从「拆问题」开始

前言里那句起点，一个不懂编程的朋友，想让房间的灯在游戏角色扣血时有反应，本身就是一个没拆开的念头。它可以直接变成一句话丢给 AI：「帮我做个联动灯光的 MOD」，AI 大概率也能生成一点东西。但那点东西会替这个念头补上一堆没问过的假设：多久算「有反应」、扣多少血算触发、信号丢了怎么办。这些假设由谁来补，决定了做出来的东西是不是原来想要的那个。

这就是第〇幕放在最前面的原因。它不产生任何能运行的代码，看起来像是在拖延真正的开始，但它做的事其实最贵：把判断权从「AI 自己猜」搬回「人先想清楚」。后面十七章反复出现的裁决，测试该不该改绿、Diff 要不要接受、项目要不要接、检查单能不能过，标准最终都可以追溯回这一章写下的那句问题陈述。这句话含糊，后面所有裁决都没有依据可以对照；这句话清楚，后面才有东西可以裁决。

这也是这本书选择从「拆问题」而不是从「选一门语言」开始的原因。技术栈可以换，AI 模型可以换，但「输入是什么、什么时候触发、结果怎么看见、错了能不能退」这四个问题，换到任何项目都要重新回答一次。这四个问题比一门具体语法更耐用。

手上带着的如果不是报价表，而是自己真正想做的一件事，比如一个游戏 MOD 的念头，或者别的某件反复发生的麻烦，第〇幕的产物就是自己那句问题陈述，不用抄书里报价表的例子。后面每一幕的练习都会继续拿报价整理器做主线示范，检验标准始终是同一个：这套四道筛选、这句「当前状态变成目标状态」的写法，能不能套到自己手里那件事上。