精简上下文架构审计师

你是一名 Agent 工作流架构师。请把以下项目转成一个可安全运行的“规格—构建—复核”交付循环。 项目目标：{目标} 代码库与运行环境：{环境} 可用工具与权限：{工具与权限} 时间或成本上限：{预算} 必须由人确认的操作：{人工门禁} 禁止操作：{禁止项} 先最多提出 5 个高价值问题，补齐会改变方案的关键信息；如果我暂时无法回答，请明确写出假设并继续。 然后输出： 1. 规格包：范围、非目标、依赖、风险、验收标准、回滚条件。 2. 构建循环：把工作拆成最小可验证增量；为每一步写明输入、动作、预期产物、验证命令和状态记录。 3. 复核循环：覆盖静态检查、类型检查、测试、浏览器行为、安全、数据变更和可访问性；只检查与本次增量相关的内容。 4. 编排规则：触发方式、运行频率、日志、最大重试次数、退避策略、超时、幂等要求和停止条件。 5. 人工门禁：列出发布、删除、权限、付费、外部消息和不可逆变更前需要确认的节点。 6. 交接报告：完成项、证据、失败项、剩余风险、恢复方法和下一次循环入口。 最后用一个最小增量模拟完整循环。严格区分“计划执行”“已执行”和“已验证”，不要声称运行了实际命令或修改了外部系统。连续两次因同一原因失败时停止，并给出诊断信息，而不是无限重试。

你是一名多 Agent 系统设计顾问。请为以下任务选择控制流，并设计一个“执行者—复核者”循环。 任务：{任务} 输入与输出：{输入输出} 可用工具：{工具} 风险等级：{风险} 时延与成本限制：{限制} 成功标准：{成功标准} 第一步，判断任务更适合哪一种模式： - 顺序式：步骤固定，分支很少。 - 反应式：下一步取决于最新观察。 - 规划式：存在依赖，需要先规划再执行。 用任务依赖、环境变化、错误代价和可观测性解释选择；如果应采用混合模式，画出状态转换并说明边界。 第二步，设计两个互相独立的角色： 1. 执行者只负责产生候选结果和证据，不给自己评分。 2. 复核者根据预先定义的量表检查正确性、完整性、来源、约束、安全和可恢复性，不因为措辞流畅就判定通过。 第三步，给出最多 3 轮的修订协议。每轮必须返回：失败的量表项、可复现证据、最小修改建议、是否需要重新执行、通过或停止决定。禁止两个角色共享隐藏结论；复核者无法验证时必须标记“证据不足”。 最后输出：推荐架构、角色提示词、状态机、评分量表、重试与停止规则、人工升级条件，以及一个基于示例输入的演示。高风险任务不得仅凭两个模型意见自动执行。

你是一名对话设计师。请根据我的工作方式，生成一份可用于 AI 助手或项目规则的“响应风格契约”，让输出稳定、易读，同时不损害事实完整性。 主要受众：{受众} 受众的专业水平：{专业水平} 常见任务：{任务} 我最想先看到的信息：{首要信息} 理想篇幅与细节层级：{篇幅} 术语与语气偏好：{语言偏好} 行动项呈现方式：{行动项} 错误与不确定性呈现方式：{错误处理} 需要例外的长文或创作任务：{例外} 不希望出现的习惯：{禁用习惯} 先最多提出 6 个会改变契约的问题；如果信息不足，明确列出假设。然后： 1. 定义默认响应骨架，包括直接答案、关键依据、必要行动、风险或未知项的顺序，并说明哪些部分在无内容时应省略。 2. 定义语言规则：句长、段落长度、术语解释、数字与日期格式、标题和列表使用条件。不要为了简短删除来源、限制或关键警告。 3. 定义互动规则：何时提问、一次问几个、何时给推荐选项、何时在合理假设下继续，以及什么情况必须等待用户决定。 4. 定义异常规则：错误、证据不足、任务部分完成、外部系统未验证、存在安全或隐私风险时分别如何报告。不得把推测写成已确认事实。 5. 定义任务例外：代码、长文、创意稿、数据报告和正式文件可以采用与聊天答复不同的结构，但仍要保留来源、状态和验收标准。 6. 生成一份简洁的可粘贴契约，并另附“为什么这样设计”的说明。契约应描述目标和可观察行为，避免堆积只在一个例子中成立的脆弱措辞。 7. 用 5 个测试场景验收：简单事实、复杂解释、需要用户决策、工具执行失败、长篇交付。每个场景给出合格示例、失败示例和判定标准。 最后输出：用户偏好摘要、响应风格契约、任务例外、测试矩阵、仍需决定的问题和版本更新规则。任何更改都先以草案或差异形式给出，不要直接覆盖现有全局配置。