这个提示词用来做什么

长任务要跨会话或跨模型接手，直接把历史全带上会撑爆上下文，随手写一段总结又会把关键分歧和未验证的结论一起抹平

提示词全文

你要为下一个接手这个任务的会话（可能是另一个模型、另一个人，或者几天后的你自己）写一份交接单，而不是写总结。

## 输入
原始任务目标：{一句话目标}
已完成的工作：{做了什么，改动了哪些文件或系统}
当前状态：{能跑通什么、卡在哪一步}

## 交接单必须包含
1）目标与验收标准：任务完成时，用什么可观察的结果来判定（命令、指标、页面表现），不要写「功能正常」这类无法验证的话。
2）已确认的事实：每条后面标注来源——是运行结果、日志、文档，还是推断。推断必须标「未验证」。
3）已排除的方案：列出试过但走不通的路，以及排除的具体理由。这一节比成功记录更省下一个人的时间。
4）当前分歧与未决问题：如果存在两种都说得通的方案，把两边的前提分别写清楚，不要替接手人做决定。
5）下一步动作：给 1 到 3 个具体的、可直接执行的动作，按优先级排序，并说明每个动作的预期耗时量级。
6）风险与地雷：哪些操作会破坏当前进度、哪些目录不要动、哪些外部依赖有时限。

## 规则
- 全文禁止出现「已完成大部分」「基本可用」这类程度形容词，只写可检验的状态。
- 不确定的地方直接写「不确定」并说明怎么确认，不要用连贯叙述掩盖空白。
- 不要复述整个对话过程，只保留影响后续判断的信息。
- 长度控制在接手人五分钟能读完的范围内；超出部分放进附录，正文只留索引。

怎么用

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

输出示例

输入「目标是让结账接口 p75 延迟降到 300ms 以下，已加了索引并改了两处序列化，当前 p75 为 410ms」后，输出会把「索引带来的收益已用压测数据确认」与「序列化改动只在本机验证过，未上预发」分成两条、分别标注证据来源，并把「换掉 ORM 与继续优化当前查询」两种方案的前提并列，最后给出「先在预发环境复现 410ms 基线」作为第一个动作。

基本信息

  • 分类：工程
  • 标签：上下文管理 · 交接摘要 · 可审计 · 长会话 · 压缩
  • 收录日期：2026-09-18

同类提示词