五步提示词流水线：最强的模型该去当审稿人

r/PromptEngineering 上有人花了几个星期，搭了一条五步的 LLM 流水线，把一句话的应用想法变成给 Lovable、Claude Code 这类工具用的规格提示词。

五个步骤：分析、提问、问题检查、写作、检查。

他把过程中几个意外写了出来。

写手不擅长审自己

让写作步骤自己复核一遍，几乎没变化。单独拆出一个审查步骤，同样一个模型，换个任务，抓出来的问题明显更多。而且更强的模型放在审查位，比放在写作位更值钱。

假设就地标

不要单独列一份假设清单。模型自己选定的每个值，直接在使用的地方标上 (assumed)。比如：客户可在 24 小时前取消（assumed）。读的人一眼看到哪些是猜的，链上的下一个模型也看得到。

最糟的 bug 是自我拆台的规则

一个交易机器人的测试里，提示词写了每日亏损上限，但这个上限永远触发不了，因为机器人只在盈利时卖出。现在每条提示词都要过一遍：每个保护措施在其他规则之下，是否真的能触发。

每一步都走结构化输出

他测过的模型，无论大小，有时都会在 JSON 后面多写一段话。放在链里，下一步就断了。测试跑在普通 Claude 聊天里，输出格式没法强制。线上应用走 API 的结构化输出，能挡住。

问决策，不问技术

非技术用户答不了用哪个数据库，能答客户能不能取消、到什么时候。技术选择就变成标了 (assumed) 的假设。

这条流水线叫 CueBlu，作者正在做，目前是免费 beta。

跟帖的 AuroraAOS 把审查步骤的排序讲得更细。他的做法是规则检查放最前，针对机械属性。确定性检查不会被说服、不会累、不会跟你争，还能抓到一类判断审查容易滑过去的问题：东西压根不在。他们踩过一次坑，所有验证都通过了，因为检查只数了清单里匹配的文件，没枚举包里实际有什么。漏掉的东西不在被检查的文件里，在没人列出来的那些里。现在的规矩是：一个检查要通过对，得先枚举它的失败集合，确认为空。数通过项，就是带着绿色报告把 bug 发出去。

模型审查放第二，管判断类：缺口、矛盾、没人标的假设。这里最重要的变量跟用哪个模型审关系不大，在于审查者被允许看到什么。独立的上下文比独立的模型更有效。审查者拿到作者的摘要，就会审摘要。拿到成品本身，冷启动，带着找茬的指令，看不到写作者的推理，才能抓到真问题。推理是辩护，读了推理的审查者最后是在给论证打分，不是在给作品打分。

他还想把 (assumed) 标记再推一步：每条主张都标来源，哪个步骤产生的、从什么输入来的。这样审查发现缺口时，修提示词之外，还能知道链上哪个步骤在什么条件下会胡编。

发帖人最后问：审查步骤该用同一个模型、换一个模型，还是纯规则检查？AuroraAOS 的答案摆在上面，排序比选择更重要。