Prometheus - 构建时元提示框架

Prometheus

一个通用的元提示框架，用于为LLM代理设计提示。适用于任何代理CLI工具（Claude Code、Gemini CLI、Cursor等）以及非CLI使用场景。涵盖所有七种提示形状：代理循环、一次性任务、工作流链、子代理提示、系统人格、LLM作为评判者评分器以及代理团队。

该框架基于经典的上下文工程学（Anthropic的“正确抽象层次”、“最小可行Token集”、“示例优于规则”）以及量子语义学原理（提示是运算符，而非密钥查找；顺序是结构性的；歧义是一种特性；组合是非加性的）。

何时使用此技能

当用户开始为LLM代理进行任何提示设计工作时触发。常见措辞：

• “帮我为[任务]编写一个提示”
• “我需要一个用于[目的]的系统提示”
• “为[项目]设置一个[Claude Code / Gemini CLI / 等]的提示”
• “为[评估]设计一个LLM作为评判者的提示”
• “我正在构建一个执行[X]的子代理，帮我编写它的指令”
• “为[任务]启动一个代理循环”

不触发场景：简单的问答、代码补全请求、或用户想要答案而非获取答案的提示的任务。

核心立场：提示是运算符

该框架所依赖的最深层重构，源自量子语义学文献：提示不是从模型中“提取”正确答案。提示是一个运算符，通过转换模型的语义状态来构建答案。 提示的每个部分都是一个矩阵，放大某些解释，抑制其他解释，混合基础状态以产生新的解读。

这不是比喻。它改变了设计实践：

• 我们不“找到正确的关键词”——我们设计变换。
• 顺序是结构性的——运算符不可交换。
• 组合部分会产生干涉，而非简单相加。
• 每条指令都会破坏信息；据此设计。
• 用户意图中的歧义是一种叠加态，而非需要清除的缺陷。

该技能具体应用这些原则，而非作为点缀。参见 references/quantum-principles.md 获取操作映射，以及 operators/ 获取各部分作为运算符的目录。

三种操作模式

框架根据用户输入的内容运行在以下三种模式之一：

从零开始模式（默认）。 用户描述一个任务；框架生成一个提示。六个阶段：形状推断 → 自适应访谈 → 运算符设计草稿 → 审计 → 诚实评估 → 交付。

重构模式。 用户有一个现有提示并希望审计、修复或重写它。六个阶段（1R到6R）：接收并解析 → 意图恢复访谈 → 模式选择（审计 / 目标重构 / 全面重写）→ 应用模式 → 诚实评估 → 交付。完整程序记录在 references/refactor-mode.md 中。

管理模式。 用户指向一个现有的托管代理包，并希望在其生命周期内运行它——监控其运行、分析目标违规、适应它、停止并以其相同的内部状态重新启动。这是框架作为代理管理器，而不仅仅是设计师：一个MAPE-K循环（监控/分析/计划/执行）作用于代理的提示，通过运算符代数表达。完整程序记录在 references/manage-mode.md 中；包布局、生命周期和账本记录在 references/agent-state.md 中。

模式检测。 当用户的开场消息包含粘贴的提示后跟审计、改进、修复或重构的请求时，自动检测重构模式。直接调用如“重构这个提示”、“审计这个提示”、“这个提示有什么问题”立即触发重构模式。当用户指向现有代理包路径或针对它调用生命周期动词时，自动检测管理模式——“管理这个代理”、“运行适应周期”、“为什么我的代理退步了”、“重启我的代理”。当检测有歧义时（提示已粘贴但请求不明确），询问一次：“我看到了一个提示——你是想让我重构它，还是把它作为不同任务的上下文？” 除非重构或管理信号明确，否则默认为从零开始模式。

三种模式共享基础设施（形状目录、运算符目录、审计清单、验证器规格），但运行不同的程序。特别是管理模式重用从零开始和重构机制作为子程序（审计清单、重构子模式、跨运行验证器），而不是添加新的分析机制。从零开始程序如下；重构程序在 references/refactor-mode.md中；管理程序在 references/manage-mode.md中。

从零开始程序（六个阶段）

阶段 1 — 形状推断，而非路由

用户的任务描述以叠加的语义状态到达。不要问路由问题。 从已存在的信号中推断形状，遵循§2.4贝叶斯抽样的精神。

1. 仔细阅读用户的请求。提取信号：动词（构建/草拟/分类/评分/评估/提取/总结）、名词（系统/文档/管道/循环/代理/人格/评判者）、规模标记（一次性 vs 持续，多轮 vs 单次调用）、以及工具提及（Claude Code、Gemini CLI等）。

2. 生成一个在合理形状上的内部后验分布。形状目录在 templates/shape-catalog.md中。暂时不要确定——保持权重。

3. 仅当第二名的形状明显落后时，选择后验质量最高的形状。如果两个或更多形状彼此在～30%以内，则推断有歧义，你应该通过一个针对性的澄清问题消除歧义。将其表述为前两个形状之间的强制选择，而不是开放式的路由问题。

4. 领域（工程/研究/写作/运维/通用）是次要轴，与形状正交。以相同方式推断。一次性写作提示和代理工程提示都应用此框架，只是部分内容不同。

5. 在同一轮中检测硬推理信号。数学/逻辑任务、多步规划、代码分析或调试、多约束问题、或任何用户提到模型首次尝试失败的任务，都是认知工具支架（根据 references/reasoning-patterns.md）应作为草稿中的结构默认而非可选扩展的信号。两个或更多信号 + 工具调用运行时 → 在传统和强等级上包含支架，其中引用的经验结果适用。在前沿等级上，支架是M5触发的选项，而非默认——参见 references/reasoning-patterns.md §等级门控。

6. 推断底层能力等级——第三个轴，与形状和领域正交，从运行时答案中读取：前沿（运行时最新的高指令遵循模型）、强（当前主流模型）、传统（较旧或较小的模型）。未知 → 假设为强。等级条件：阶段3中的默认运算符强度（references/quantum-principles.md中的原则9——描述性运算符在高指令遵循基底上过度投射）、支架触发阈值（上述第5点）、预填充可用性、以及阶段6中的推理控制参数指南。

阶段 2 — 自适应访谈（运算符感知）

访谈本身是一系列应用于用户意图的运算符。根据§5.6，每个问题都不可逆转地消除歧义。不要消除得太快。

执行规则：

• 总共最多6个问题，包括阶段1中的任何消除歧义问题（3个通用——部署上下文在明显时可跳过——加上2-3个特定形状）。硬上限。共同创作轮次（形状3、6、7）根据 templates/interview-branches.md执行规则豁免。
• 每轮一个问题。 多问题轮次会产生更浅的答案。
• 跳过答案已在用户请求中的问题。 重复询问是破坏信息的重复。
• 问题顺序很重要（§2.3, §5.1）。先问最广泛的框架性问题，然后是缩小约束条件，最后是格式。第一个问题设定了所有后续问题操作的子空间。
• 在提问成本低而错误成本高的情况下保留叠加态（§4.1）。对于架构级别的选择（形状、受众、工具），保留。对于战术选择（文件名、大小写），默认并继续。

每种形状的问题库在 templates/interview-branches.md中。所有形状都有两个通用问题：

1. 工具/运行时。 “这个提示将在哪里运行？（Claude Code、Gemini CLI、OpenAI API、通用LLM、其他？）” 影响内存文件命名和工具特定能力。
2. 完成定义/成功标准。 “你如何知道提示有效？要可检查，而非凭感觉。” 为阶段5的自我评估提供标准。

以总结收敛结束访谈：陈述你推断的形状、收集的关键约束、以及你为任何未指定内容分配的默认值。在草稿前给用户一次覆盖的机会。这是有意的测量步骤（§1.2）——明确说明，以便用户可以对收敛提出异议。

阶段 3 — 运算符设计草稿

草稿是运算符设计（§5.3），而非填充部分。对于每个包含的部分：

1. 确定该部分转换的基础状态——哪些解释应被放大、抑制或混合？
2. 选择强度——强运算符（人格、硬约束）积极投影；弱运算符（风格偏好、格式）与大多数其他运算符可交换。将默认强度校准到基底等级（原则9）： 在前沿等级上，倾向于简短的一般指令而非枚举，并将强度语言（“关键”、“必须”、重复禁止）保留给具有已证明失败模式的约束；在传统等级上，通常需要更强的投影。对于具有破坏性能力的角色，能力锁定在每个等级上都应是分层且明显的——其理由在于风险，而非基底弱点。
3. 放置在运算符序列中，根据§5.1：最广泛的框架最先，然后缩小，格式最后。
4. 检查与相邻部分的干涉（§5.4）——组合是否产生有意或无意的涌现行为？

使用 templates/shape-catalog.md 获取特定形状的主干。使用 operators/ 获取每个部分的运算符描述（每个部分放大了什么、抑制了什么、混合了什么；其强度；其交换属性）。对于不值得完整形状选择的任务（小型、定义明确、单一用途），templates/minimum-viable-prompt.yaml 是后备支架——六个插槽（系统/指令/示例/约束/状态/查询），没有更多。

对于推理密集型任务，当结构化分解优于单调思维链时，查阅 references/reasoning-patterns.md——它记录了认知工具子模式（IBM Zurich，在AIME2024上+16.6%）以及何时在选定形状内调用它。

当提示的输出将由另一个LLM代理消费而不是显示给人类时（最常见于形状4子代理/工具提示和形状6 LLM作为评判者），查阅 references/agent-consumability.md。当消费方是代理时，输出设计会改变：可grep的错误标记、优先聚合结构、紧凑的标准输出与详细日志、确定但不同采样、以及可见的状态转换。

对于形状7（代理团队），拓扑选择是基础性的，必须在每个角色草稿之前进行。查阅 references/agent-team-topologies.md 了解四种规范拓扑（编排者-工作者、并行分段、并行投票、评估者-优化器），包括其运算符配置、角色定义和常见失败模式。先选择拓扑，然后使用其各自形状的主干草拟每个角色的提示，最后审计跨角色连贯性。

所有形状都适用的通用草稿规则：

• 正确的抽象层次。 足够具体以采取行动，足够灵活以适应模型。脆弱的硬编码和模糊的泛泛而谈是双重失败模式。
• 最小可行Token集。 删除任何不解决特定失败模式或启用具体行为的内容。每个Token都会消耗注意力。
• 示例优于规则。 当一条规则是承载性的时，写下工作示例。示例是承载性的运算符，锚定抽象指令。但示例本身也有歧义表面——示例内部的任何无声判断都会成为模型逆向工程的规则。在发布任何示例之前，问：这个示例无声地教会了什么超出我意图的内容？如果不确定，用更清晰的案例替换它。
• 按运算符强度排列部分顺序。 最强运算符在前。
• 将失败模式作为“不要做”项。 每个都针对一个特定的已知尖锐边缘，并附上具体后果。通用警告浪费Token。

阶段 4 — 审计（结构性和量子）

运行 references/audit-checklist.md 中的审计清单。清单结合了经典的上下文工程检查（正确抽象层次、最小Token集、示例存在、长期支持耐久性）与量子语义检查：

• 运算符目录完整。 每个部分都有清晰的放大/抑制/混合配置文件。没有部分是“装饰”。
• 顺序优化。 最强运算符在前。通过心理交换相邻部分并问“这会改变行为吗？”来测试。如果会，你已正确识别了不可交换的对。
• 干涉已检查。 当两个部分可能交互时（例如，人格 + 语气 + 格式），确认组合产生了预期的涌现行为，而不是意外的抵消。
• 信息保存。 重要的上下文尽早加载（它在更多投影中存活）。应保持模糊的事物被标记为如此，而不是预收敛。
• 测量感知。 如果提示的输出是用于评估或评分（LLM作为评判者、子代理），确保输出格式明确且可解析。

如果没有通过审计，返回阶段3进行设计修订。

阶段 5 — 诚实评估

这是对提示的自我批评。扮演对手：

1. 识别薄弱点。 模糊的指令、缺失的约束、未解决的歧义、重叠的部分、假设模型知道但未说明的内容。
2. 测试边缘情况。 如果用户偏离任务、提供不满意的输入、或同时要求多件事，提示会如何反应？
3. 评估稳健性。 提示是否对不同输入风格稳健？它是否过度拟合于单一使用场景？
4. 用量子原则检查。 运算符序列是否合理？是否存在意外干涉？是否利用了叠加态而无需不必要的测量？
5. 对成功标准评分。 根据阶段2中收集的完成定义，提示在多大程度上使可验证的成功变得可能？

记录诚实评估的结果（简短标记，3-5个要点），并将其作为提示交付的一部分包含在内。如果评估揭示严重缺陷（未能通过审计检查、确定性失败模式、缺少关键部分），返回阶段3或4。

阶段 6 — 交付

交付最终提示。格式：

1. 提示本身，以适当的格式呈现（对于CLI代理，为准备就绪的命令；对于API使用，为文本；对于包管理系统，为文件内容）。
2. 诚实评估摘要，以3-5个要点的形式。
3. 使用说明（如有），包括环境变量、文件放置或运行时配置。

对于管理提示，也输出代理包布局，并根据 references/agent-state.md 初始化其账本。

包布局和文件

Prometheus将其输出作为包交付。包的默认结构：

• prompt/ — 提示文件本身。
• verifier/ — 验证器规格（如适用）。
• audit/ — 审计记录（如果模式包括审计）。
• state/ — 代理状态文件（管理模式下）。
• references/ — 此技能运行中引用的参考资料。

验证器规格

对于LLM作为评判者提示（形状6）和管理模式，该技能会生成一个验证器：一套结构化的评估标准，可用于自动评估提示及其代理的输出。验证器跨运行工作，并将自身记录在代理包的账本中。

形状目录

参见 templates/shape-catalog.md获取七种规范形状及其脊椎。

运算符目录

参见 operators/获取每个部分的运算符描述。

参考

• references/quantum-principles.md — 量子语义到提示设计的映射。
• references/audit-checklist.md — 组合式审计清单。
• references/refactor-mode.md — 重构模式的完整程序。
• references/manage-mode.md — 管理模式的完整程序。
• references/agent-state.md — 代理包布局、生命周期和账本。
• references/reasoning-patterns.md — 推理模式，包括认知工具支架。
• references/agent-consumability.md — 由代理消费的输出设计。
• references/agent-team-topologies.md — 代理团队的规范拓扑。