Marico's space
译者按：prompt 工程这个领域，野路子太多了，真正的系统化方法论极少。这篇文章提出了「四层架构」和「自评估提示」等模式，思路值得借鉴，于是翻译分享。
尽管大语言模型进化得飞快，什么 GPT-4、Claude 3 全出来了，但很多工程师写 prompt 的方式依然是「试试这个，不行再改」。两个人解决同一个任务，能写出完全不同的 prompt，还各执己见觉得自己的更好——但说不清楚为什么。（说白了就是玄学。）
这就像在没有度量衡的情况下盖房子，全凭经验和感觉。
软件工程当年也是这样——大家各写各的，没有共同语言。后来设计模式出来了，把常见问题的通用解法沉淀下来，业界才算有了「词汇表」。
提示工程现在就在这个节骨眼上。
我在多个大语言模型系统上做了大量实验，发现高效 prompt 有一个共同特征：它们都遵循分层结构。我把这个叫做四层提示架构。
这层用毫不含糊的语言定义核心任务。模糊的意图只会换来模糊的结果，这层没做对，后面全白搭。
这层给模型提供相关知识、约束条件或者示例。比如你要让 AI 帮你写代码，就得把技术栈、项目背景一起喂进去，否则它只能「礼貌性」地回答你。（别问我怎么知道的。）
这层引入了链式思维（Chain-of-Thought）这类技术，让模型「思考」而不是直接给答案。对于复杂推理任务，这层是性能提升的关键。
这层约束输出的结构和评价标准。你要 JSON 就说 JSON，要表格就别让它给你一段话。契约越清晰，输出越可用。
我用过最有效的模式之一是自评估循环——让模型在给出答案之前，先自己审视一下自己的输出是否满足要求。这个技巧简单到不可思议，但效果拔群。
没有任何模式是万能的。理解失败模式比记住成功模式更重要。比如自评估循环在模型本身能力较弱时反而会帮倒忙——它会自信地给你一个错误答案还觉得自己很对。（这种情况我踩过不止一次。）
如果 prompt 工程要成为一门正经学科，就必须有基准测试。不然大家各说各话，没法比较谁的方案更好。这块目前还是空白，但需求很迫切。
每个设计模式都有代价。链式思维提高了质量，但增加了 token 消耗和响应时间；自评估循环提高了可靠性，但让整个流程变慢了两倍。实际项目中如何取舍，这是工程问题，不是技术问题。
提示工程现在的阶段，就相当于软件工程在设计模式出现之前的状态。混乱、野路子、直觉驱动——但正在往系统化方向走。
从「调戏 AI」到「工程化 prompt」，这不只是说法变了，是思维方式变了。把 prompt 当成随机应变的黑科技，还是当成需要设计、测试、迭代的系统，決定了你能走多远。