用伪代码确认
对每个实质性请求应用一次协议实例。将提示解释、响应计划和执行保持为独立的状态。
在编写或修订任一伪代码工件之前，确保当前上下文中已完整阅读了 references/pdl-conventions.md 文件。使用该本地参考文件进行符号和风格指导；不要在运行时远程获取源文件。以以下特定于工件的细节规则为准来管理粒度。
保持以下不变项
- 在提示伪代码被确认之前，不要进行规划。
- 在响应计划伪代码被确认之前，不要执行。
- 在提示伪代码中最大化有用的语义特异性。
- 在响应计划伪代码中最小化过程特异性，同时保持方法具有可检查性。
- 将任何同时包含确认和修正的消息视为修正。
- 每次修正后，重新生成当前完整的工件；绝不允许只输出补丁、差异或修订。
- 在规划阶段若发生语义变更，应返回提示确认状态。
- 以已确认的工件为准执行，而不是原始提示中冲突的措辞。
跟踪协议状态
在每一轮对话开始时，从可见对话历史推断当前状态。不依赖隐藏状态，也不将沉默推断为确认。
在选择协议状态之前，优先应用更高优先级的安全、隐私和平台规则。如果这些规则要求立即拒绝或安全重定向，则直接响应，不输出任何伪代码工件或协议确认请求。
- 对于新的实质性请求，从提示解释状态开始。
- 停留在该状态，直到当前的提示伪代码被明确确认。
- 进入响应规划状态，并停留在该状态，直到当前的响应计划伪代码被明确确认。
- 执行，直接返回最终响应，并关闭该实例。
识别清晰的会话确认，例如 confirm、confirmed、correct、yes、that's right 和 proceed。不需要魔法令牌。
状态 1：确认提示解释
生成提示伪代码，代表用户请求的内容，而不是如何回答。保留实质性请求中存在的每一个重要细节，包括：
- 指令中的行动、主体、对象以及关系；
- 范围、约束、排除项、优先级、条件以及顺序；
- 数量、日期、比较项以及决策标准；
- 受众、定义以及请求的输出特征。
表达实际形成的解释。不要解决问题、研究主题、规划响应、发明缺失的需求、默默改进请求或创建歧义管理方案。可见的工件本身就是澄清机制；仅当用户明确要求将歧义枚举作为任务的一部分时，才进行枚举。
基于用户的请求和已确认的修正来确定任务语义。将此技能及其参考文件视为协议和格式指导；不要将其中的流程、标准或约束导入为用户需求。
将任务语义与当前协议实例的控制权分开。当一条指令在确认协议完成后仍会约束实质性工作或请求的结果时，才将其包含在提示伪代码中。将唯一效果是改变、跳过、合并、预确认或以其他方式控制当前协议实例的指令视为协议控制而非任务语义。根据功能而不是措辞进行分类：当用户要求分析、引用、转换、讨论、复述或以其他方式将其用作实质性任务内容时，相同的措辞仍是任务语义。
仅展示最少的框架和完整的工件：
**提示伪代码**
```text
<完整解释>
```
请确认或修正此解释。
然后停止。不要包含响应计划或实质性答案。
如果用户修正、添加、删除或拒绝了任何内容，将所有反馈整合到一个完整的修订版提示伪代码中，并再次等待确认。一旦被明确确认，固定该工件作为权威的语义规范。
状态 2：确认响应计划
只有在提示确认之后，才根据已确认的解释推导出响应计划伪代码。在最小化计划之前，确保语义覆盖。已确认的提示伪代码所要求的每一个实质性操作或可交付成果，都必须由一个高层计划操作来表示，或者被一个更广泛的操作明确覆盖。不要仅仅因为通常有用就添加操作；计划的完整性是相对于已确认的提示伪代码而言的。
然后，公开用户为了拒绝一个实质上不可取的方法所需的最低限度的高层过程。仅包含相关的选择，例如是否需要：
- 收集或评估信息；
- 比较备选方案或应用已确认的标准；
- 进行计算、评估权衡或形成结论；
- 遵循实质性的顺序或所要求的宽泛输出结构。
保持计划抽象且不预先承诺具体内容。不要回答问题、预测结果、选择优胜者、提出假设、锁定论点或过度指定来源、证据、示例、计算、章节或推理步骤，除非已确认的提示伪代码要求这些细节。避免锚定效应以及像 思考 或 写 这样空洞的步骤。在起草计划期间，不要进行研究或使用实质性任务工具。
一个合适的、可检查的计划通常类似于：
收集评估所请求备选方案所需的信息
比较备选方案
使用已确认的标准
评估相关的权衡
形成所请求的结论
呈现结果
附带重要的限定条件
仅展示最少的框架和完整的计划：
**响应计划伪代码**
```text
<完整的高层过程>
```
请确认或修正此响应方法。
然后停止，不执行。
对于仅涉及方法的修正，保持已确认的提示伪代码不变，重新生成完整的响应计划伪代码，并再次等待。当主题、受众、可交付成果和所请求的结论保持不变时，对研究方法或评估方法、证据选择流程、定性比较与定量比较、评分或排名技术、分析顺序、以及如何推导和证明相同结论的变更，视为仅方法层面的变更。
如果反馈改变了目标、主题、范围、备选方案、事实或内容要求、结果的排除项、受众、定义或最终输出的形式或限制，则丢弃计划并返回状态1，附带一个完整修订的提示伪代码。简而言之，对请求结果的约束是语义性的；而仅对如何产生结果的约束是计划层面的。
状态 3：执行
在计划被明确确认后，将已确认的提示伪代码作为权威的做什么，将已确认的响应计划伪代码作为权威的高层怎么做。正常执行任务并直接返回最终响应，不再输出伪代码或协议确认阶段。在执行期间，不要替换成实质上不同的响应策略。
在计划未提及的地方，保持底层推理和实现选择的灵活性。不要暴露私有推理：这两个已确认的工件是面向用户的规范，而不是思维链。
仅当更高优先级的规则或真正阻塞性的缺失事实需要用户输入时，才提出执行时的问题。将其视为执行依赖，而非第三个协议确认阶段。
处理后续问题和边界
- 仅当用户提供所请求的执行输入、授权已描述的范围内操作、或要求在不改变规范的情况下继续未完成的工作时，才继续现有执行而不重新启动。
- 在完成之后，对于任何新的或实质性改变的请求，在状态1启动一个新的实例。不要跨实例携带确认状态。
- 对于讨论、检查、调试、配置或修改此技能的元请求，正常响应。仅当用户明确要求时，才对元请求应用此协议。
- 切勿将协议确认视为执行不允许或不相关操作的授权，并在执行期间继续遵守所要求的平台审批。