Pizza-Builder 法则：结构化提示词设计避免 AI 反复猜错

Pizza-Builder 法则：结构化提示词设计避免 AI 反复猜错 | 前端进阶之旅

Full translation

完整中文译文

让 AI "写篇小说"，得到的结果通常有两种，而两种都让我恼火。

它会猜测。体裁、主角、基调，全是现场发挥。你一看输出，发现跑偏了，然后浪费整整一轮生成周期，重新开始。

或者它在盘问你。一次问一个澄清问题，问到第四轮时，你打的字已经比自己写完那篇请求还要多了。

我受够了这两者，所以给 Claude 做了一个叫 pizza-builder 的 skill。一屏界面，一个菜单，搞定。

"自选构建"模式能行得通，有一个原因大多数人从没停下来想过。已经有人替你把关键决策点想清楚了（饼底、酱料、芝士、配料），而且每个选项都收窄到寥寥几个好的选择。

你不需要从零发明一个披萨。你是从一份被精心设计过的菜单里选出一个组合。

我把这个逻辑用在了 AI 请求上。结果发现，解决方案不是更好的 prompt，而是更好的结构。

让菜单生效的规则

找到真正的决策点，而不是泛泛的分类。弱："体裁：奇幻 / 科幻 / 悬疑 / 其他" 锐利："温馨小镇悬疑 / 有时间压力的硬科幻 / 关于家族秘密的文学小说 / 政治为核心史诗奇幻"

具体的选项让你能立即做出反应。泛泛的标签只是把问题原封不动地抛回来，没人曾经因此得到过帮助。

让问题的形态与实际匹配。不是每个决策都是"从四个里挑一个"。我统计过，实际会出现的共有七种形态：

Toggle（开关）：用于简单的二选一，比如这个是否需要扛住重启

Radio（单选）：用于一个短列表，选了其中一个就排除掉其余

Dropdown（下拉）：用于六个以上的选项，这样界面还能保持可扫视，而不是一面按钮墙

Skip（跳过）：用于专家可能主动反对的东西，比如"不费力加缓存"

Slider（滑块）：用于一个光谱区间，"70% 番茄酱，30% 香蒜酱"，而不是假装成连续体的虚假列表

Checkbox（多选）：用于真正具有加成性的选项

Free text（自由文本）：用于数字、名称或路径，强迫这些东西进按钮只是看起来整齐，对谁都没帮助

每个选项都要有一个真正的"你来决定"。不是耸肩，而是一个明确的选择，带着理由——就像一个好的服务员会告诉你"我给你上鱼，今天的更好"，而不是直接把决定权抛回给你。

综合，而不是总结。四个具体的选项需要产生一个没有这四个就无法存在的东西。如果输出只是把每个关键词提了一嘴，综合就失败了，不是菜单的错。

那个让我付出代价才学会的失败

我曾经做过一个日落图片选择器，生成的 prompt 里有一行写着"无地平线元素"，过了两行又说"从地平线到天顶的色带"。代码跑得好好的。按钮都能用。图片出来是纯色条纹，因为 prompt 本身在跟自己做对，没人 catch 到。

同一个选择器，另一个 bug：它生成了这么一行，直接发给用户了："Can you write me a detailed, ready-to-use prompt for this, and flag anything I should reconsider?"

每个自动化检查都通过了。语法干净，按钮可用，没有任何报错。输出的是一个抛回给提问者的问题——而这个人已经答了五个问题才走到这一步。

说实话，这一个比地平线那个 bug 更让人心痛，因为它揭示了更糟糕的东西：测试通过只能告诉你代码能跑，不能告诉你内容有任何作用。所以现在每个生成的 prompt 在发出前都要对着三种失败形态检查一遍，不只是执行一下：

Missing anchor（缺失锚点）：没有陈述任何让主体真正可识别的东西

Self-contradiction（自相矛盾）：一行悄悄削弱了另一行

Punt-back（踢回）：一个指向读者的问题，而不是一个回答

最后一种的机械测试简单到有点可笑：输出里有没有 "can you"、"write me" 或者指向用户的问题标记？如果有，那它是在要求工作而不是在做工作，我宁愿自己先 catch 到，也不想等别人来 catch。

什么时候用这个，什么时候不用

按结构来路由，而不是按主题。这一点我也是付出过代价才学会的。任何"适用领域列表"都注定会漏掉下一个领域，所以我不再维护列表了。

当存在以下情况时，考虑用这个模式：

Claude：将它添加为自定义 skill。下载文件，在 Claude 的 skill 设置中上传（或者丢进 Claude Code 的 skills 文件夹），当请求匹配时会自动触发。

ChatGPT：没有原生 skill 系统，但这个模式仍然好用。创建一个 Custom GPT 或 Project，把 SKILL.md 内容粘贴到它的指令字段里。它会遵循同样的维度与形态逻辑来构建澄清界面。

Gemini（Gems）：同样操作。创建一个 Gem，把文件粘贴到指令里，它跑同样的规则：找到真正的决策点，分类其形态，每次重新构建菜单。

这些平台都不需要完全一样的文件结构。价值在规则里，不在格式里，粘贴到模型存放持久指令的地方就行，它会保持。

这个 skill 的早期版本发的是一个固定模板，带预构建的维度渲染器。只覆盖了七种形态里的三种。每个新请求都得对照那个文件的限制来检查，而这个检查一直会被跳过——因为谁会记得去检查一个自己都不知道存在的限制？

我没有用一个更大的模板来修它。我删掉了模板。现在每个菜单都是全新构建的，基于当前规则，每次都是。没有缓存，所以在我不注意的时候不会有任何东西悄悄脱节。

如果说我从做这个 skill 里学到了一件事，那就是：一个好的澄清系统不是往一个表单上额外堆字段。它是一种习惯：每次都重新搞清楚哪些决策真正重要，以及每个决策该用什么方式来问。