写在前面：
很多人把 Prompt Engineering 误解为一种“话术技巧”或“玄学咒语”。但在真实的生产环境中，Prompt 的本质不是“让模型更聪明”，而是如何约束一个不可解释、非确定的推理系统，使其行为可控、结果可验、失败可接受。
这是一份关于“立场”的宣言，它不关乎技巧，只关乎工程逻辑。

如何解决确定性软件工程与概率性大模型之间的结构性矛盾

---

引言：Prompt 不是“调参”，而是系统设计

在工程视角下，Prompt 不是 NLP 的边角料，而是系统工程的核心环节。

• 多写几句、加点 CoT、给几个 Few-shot，这只是手段。
• 真正的目的： 是在概率的荒原上，建立起确定性的围栏。

---

第一原则：模型永远是不确定的

宣言 1：不要假设模型“会理解你的意图”

大模型不理解目标，不理解责任，更不理解现实后果。它只是在概率空间中补全下一个 Token。

• 工程认知： 模型不能对“正确性”负责。
• 责任判定： Prompt 设计者，才是系统最终的责任人。

第二原则：Prompt 是“接口”，不是对话

宣言 2：Prompt 不是聊天，是 API Contract（接口契约）

一个成熟的工程 Prompt，必须像 API 定义一样明确：

1. 输入边界： 明确哪些数据是合法的。
2. 输出结构： 强制 JSON 或特定格式，拒绝自由发挥。
3. 非法状态与错误处理： 定义模型在遇到无法处理的情况时应返回什么。

❌ 坏 Prompt： “帮我分析一下这个问题。”
✅ 工程 Prompt： “你是一个决策支持模块。仅输出 JSON；不确定时返回 error_code；严禁任何解释性废话。”

第三原则：约束优先于能力

宣言 3：限制模型能做什么，比教它怎么思考更重要

自由度 = 风险源。在系统中，我们不仅要增强能力（CoT/Few-shot），更要显式设计：

• 任务边界： 哪些领域绝不触碰。
• 推理深度： 避免陷入无限循环或过度发散。
• 兜底策略： 什么时候模型必须保持“沉默”。

第四原则：所有推理都必须可被审计

宣言 4：不可审计的智能，不能进入负责系统

我们要求模型显式列出推理过程，不是为了“人性化”，而是为了：

• Debug： 溯源错误的起始点。
• 回溯： 在发生生产事故时有据可查。
• 问责与兜底： 区分是事实错误、逻辑错误还是幻觉。

第五原则：失败是第一等公民

宣言 5：“我不知道”是合法且高优的输出

逼迫模型给出答案，是系统崩溃的开始。安全的系统必须允许“安全失败”：

• 拒绝采样： 明确拒答的条件。
• 信息补全： 当输入不完备时，主动要求补充信息而非盲目推测。
• 路径选择： 允许模型走向“无法判断”的逻辑分支。

第六原则：不要相信单次推理

宣言 6：一次回答永远不够

推理是脆弱的，偏差是常态。工程化设计应默认：

• 多重校验： 引入自检 Prompt、反证 Prompt。
• 对抗审查： 使用多角色审查机制。
• 暴露错误： 宁可让错误在测试阶段暴露，也不要让它在置信度的伪装下上线。

第七原则：Prompt 是系统的一部分，不是孤立文本

宣言 7：Prompt 必须与上下游协同设计

Prompt 是否优秀，不取决于文本是否优雅，而取决于：

• 它是否能配合后端校验器（Validator）。
• 它是否能被规则引擎（Rule Engine）解析。
• 它在失败时是否有 Fallback（降级）方案 覆盖。

第八原则：角色不是文案，是认知先验

宣言 8：“你是一个……”不是修辞，而是概率偏置

角色设定的核心价值是缩小推理空间和预置价值排序。

• ❌ 错误示范： “你是一个很厉害的专家。”
• ✅ 工程示范： “你是一个只负责风险识别、不提供解决方案的审计模块。”

第九原则：Prompt Engineering 永远不完整

宣言 9：不存在“完美 Prompt”

模型在迭代，数据分布在演进，风险在变。

• 代码化管理： Prompt 必须有版本控制（Version Control）。
• 可回滚性： 就像代码部署一样，新 Prompt 不行就立刻回滚。
• 演化逻辑： 持续监控，持续微调，随时准备废弃。

---

结语：Prompt 的真正使命

Prompt Engineering 的最终目标，不是创造一个“看起来聪明”的 AI，而是构建一个：即使模型本身不完美，也不会闯祸的系统。

让智能归于概率，让系统归于确定。