编程

你是一名 AI 工作流治理架构师。请审计 {工作流程}，判断它应该继续使用一次性提示词、沉淀为可复用 Skill，还是升级为包含工具、状态与权限的 Plugin。输入包括：{使用者与受众}、{最近 5–10 次真实运行样本}、{重复解释或修正}、{依赖的数据与工具}、{错误成本}、{变化频率}、{负责人} 和 {合规/隐私边界}。 先做证据盘点： 1. 从运行样本中提取重复出现的目标、输入、步骤、判断标准、修正和失败模式；区分稳定规则与容易变化的事实。 2. 标记只存在于资深人员脑中的判断，以及每次重新解释造成的时间、质量和一致性成本。没有数据时明确写“证据不足”，不要编造节省比例。 3. 识别秘密、个人数据、付费数据、外部写入、高影响决策和必须人工批准的动作。 然后给三个选项分别评分（1–5）：复用频率、上下文稳定性、判断复杂度、工具依赖、状态需求、团队分发价值、维护成本、错误风险和可观测性。 使用以下边界： - 保留为提示词：低频或一次性任务；主要依赖当前上下文；不需要持久状态、工具编排或团队版本管理。 - 升级为 Skill：方法、判断标准和输出结构会重复；大部分步骤稳定；可通过明确触发条件、模板、示例和验证步骤复用。 - 升级为 Plugin：需要多个工具或集成、身份/权限、持久状态、外部事件、团队分发或独立版本生命周期。 输出推荐方案，并为推荐资产写一份最小规格：名称与目标、触发/不触发条件、必需输入、步骤、工具与权限、验证、失败与停止条件、人工确认点、示例、反例、版本负责人和复审周期。不要把秘密写进提示词或示例；把高频变化的事实放在可更新的外部来源中。 最后给出最小迁移计划：先实现最小资产，用 3 个代表性案例和 2 个边界案例做只读或沙盒测试；比较完成时间、返工、错误和一致性；定义回退路径。若证据不足以升级，推荐保留现状并列出下一批需要收集的运行数据。 输出格式：证据摘要、重复解释税、三方案评分表、推荐与反证、最小资产规格、测试与回退计划、维护清单。

你是一名 AI 平台架构师。请为下面的应用设计一套可解释、可测试、可逐步上线的模型路由策略，而不是默认把所有请求交给最大模型。 应用与用户场景：{应用} 主要任务类型及样例：{任务样例} 候选模型与已知能力：{模型清单} 上下文窗口与工具支持：{上下文工具} 质量与安全门槛：{质量门槛} 延迟目标：{延迟} 成本预算与计费口径：{成本} 隐私、数据驻留与合规要求：{隐私合规} 可用性、并发和限流信息：{运行约束} 允许的遥测与反馈信号：{遥测} 先核对所有随时间变化的信息。模型价格、可用区、限额、上下文长度和能力如果没有带日期的来源，标为“待验证”，不得当作当前事实。 然后输出： 1. 任务分类表：为每类任务定义复杂度、上下文、工具、隐私、准确性、延迟和成本需求，并给出正例与易混淆反例。 2. 路由决策表：按硬约束先过滤不合格模型，再按质量、延迟和成本排序。说明每条规则的理由，不以品牌或单一基准代替任务证据。 3. 升级与降级规则：何时从小模型升级，何时回退到兼容模型，超时、限流、空响应、工具失败和低置信结果如何处理。不得为了保持在线而静默降低安全或隐私要求。 4. 预算控制：设置单请求、会话和每日上限；超限时返回什么、哪些任务可询问用户后继续、哪些必须停止。 5. 评测集：为每个任务类别给出代表性样例、预期结果、评分量表、最大延迟和成本记录字段；包含多语言、长上下文和故障注入测试。 6. 上线计划：离线回放、影子路由、小流量试验、回滚阈值和监控指标。不要直接修改生产配置。 最后给出一份机器可读的伪配置和一份面向团队的简短决策说明。明确哪些结论来自提供的数据，哪些是需要实测的假设。

你是一名上下文架构审计师。请在不改变产品目标和安全边界的前提下，审计下面这套 AI 或 Agent 上下文，并提出可回滚的精简方案。 产品与任务：{产品与任务} 当前系统提示：{系统提示} 项目级规则：{项目规则} 工具及接口说明：{工具说明} Skills 或知识模块：{技能模块} 记忆与历史摘要：{记忆} 已知失败案例：{失败案例} 必须保留的合规约束：{合规约束} 可用的回归测试：{测试} 按以下顺序工作： 1. 建立清单：把每条信息标记为身份与目标、永久安全边界、任务规则、工具契约、项目知识、示例、历史记忆或临时状态，并注明当前所在位置。 2. 查找冲突与浪费：列出重复、互相矛盾、过度具体、模型可从代码直接得出、已经过期或不应默认暴露的内容。不得只按长度删除。 3. 设计分层：核心层只保留身份、目标、权限和不可突破的边界；工具行为放入对应接口说明；项目知识放入项目规则；长流程与领域知识拆为按需 Skill；示例、文件和评分标准通过明确引用渐进加载；短期事实进入有日期和来源的记忆。 4. 改写接口：为每个可按需模块给出触发条件、输入、输出、停止条件、失败回退和人工升级点。引用真实文件或数据时保留来源，不复制密钥、个人数据或无关私有内容。 5. 评估删除风险：为每项建议标注预期收益、可能损失、证据强度和恢复方法。缺少失败案例或测试证据时写“待验证”，不要把模型能力假设成事实。 6. 制定回归计划：至少覆盖正确性、工具选择、约束遵守、冲突场景、长任务、未知输入和高风险操作。给出基线、对照版本、通过阈值与回滚条件。 输出：现状地图、问题表、目标分层架构、逐项迁移清单、精简后的核心提示草案、模块接口草案、回归测试矩阵和分阶段上线计划。不要直接删除或覆盖现有配置；先提供差异与备份方案，涉及生产、权限或外部操作时保留人工门禁。

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

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