这个提示词用来做什么

agent 的提示词越写越长，里面塞着大量本该由代码保证的固定步骤（格式校验、重试、字段映射、顺序控制），运行成本和结果波动都在涨，想迁一部分进代码又怕改坏

提示词全文

我打算把一个 agent 现有的工作流做一次「从提示词搬进代码」的重构。请先帮我做迁移判断和验收设计，不要直接重写我的提示词，也不要假设我不知道的东西。

## 输入
现有提示词：{粘贴完整提示词或其主要段落}
现状：{使用的模型、日均调用量、当前成功率与失败样例、对延迟和成本的要求}
工程条件：{能用什么语言与框架、有没有评测集、能不能灰度发布}

## 输出
1）步骤分类：把提示词里的每一步分成两类——「固定顺序、结果可校验、失败可重试」的（该搬进代码）与「需要语义判断、依赖上下文」的（该留在提示词里）。逐条给出分类结果与理由。
2）代码化方案：对每个该进代码的步骤，说明用什么方式实现（循环与重试、schema 校验、字段映射、状态机、工具调用封装），并给出最小接口契约：输入什么、输出什么、失败时抛什么。
3）提示词瘦身清单：指出可以从提示词里删掉的部分，以及删掉之后提示词需要补上哪些「为什么这么做」的说明，避免模型失去判断依据。
4）验收指标：给出 before / after 四项指标的测量方法——LLM 调用次数、任务成功率、单任务平均成本、最坏情况延迟；并给出一个「改坏了就回滚」的阈值。
5）风险提示：指出这次重构里最容易腐化的部位（例如某一步的失败判定过于宽松、重试掩盖了真实错误），以及该为它写什么测试。

不要编造我未提供的数字；任何比例或阈值都要标明是待测还是已知。

怎么用

  1. 把上面的提示词全文复制到对话窗口或工作流里。
  2. 把花括号占位符（如 {任务描述}）替换成你自己的内容。
  3. 条目越具体，产出越稳定；不需要的条目可以直接删掉。

输出示例

先把提示词里的每一步分成「固定顺序、结果可校验、失败可重试」（搬进代码）与「需要语义判断、依赖上下文」（留在提示词）两类并逐条给理由；对每个该进代码的步骤给出实现方式与最小接口契约（输入、输出、失败时抛什么）；说明提示词可删掉哪些部分、删完要补上哪些「为什么这么做」；给出 LLM 调用次数、任务成功率、单任务平均成本、最坏延迟四项指标的 before/after 测法与回滚阈值；指出最易腐化的部位（失败判定过宽、重试掩盖真实错误）及相应测试；未提供的数字一律标注为待测。

基本信息

  • 分类：工程
  • 标签：Agent · harness · 提示词工程 · 成本优化 · 重构
  • 收录日期：2026-09-27

同类提示词