第一次用AI助手处理一项任务时，一段很长的对话会让人感觉很有成效。你解释项目背景，粘贴约束条件，纠正几个错误假设，最后拿到一份可用的草稿。第二次再做时，大量上下文需要重新建立。换一个对话、换一个模型、换一个同事或审阅者，对方可能并不知道上次决定了什么。工作开始变得不像委托，而更像反复重建一份共享记忆。

这种成本不只是打字时间。当任务说明只存在于一段对话里，边界很容易丢失，未经证实的信息容易被接受，或者仅仅因为读起来通顺就被当作完成，而不是因为它真正满足了原始要求。

这个问题也出现在公开技术讨论中。一位Hacker News评论者直白地指出了提示词问题：“一个糟糕的提示词可以生成毫无意义的输出。”另一位评论者描述了后续流程受到的约束：“代码审查、持续集成和分支工作流都是按人类写作速度校准的，这些关卡并没有变快。”还有一位指出了一个流畅草稿无法替我们决定的边界：“发送邮件或删除数据等有风险的操作，其批准机制需要人类审批。”

三个文件各回答一个问题

这些只是个人评论，不是调查，也不能代表普遍需求。但它们描述了一种常见的运营错配：生成工作往往比保留相关上下文、判断什么算完成、以及在结果影响他人之前进行审查更容易。

更长的提示词可能对单次运行有帮助，但它不适合存放那些每次运行都应保留的规则。对于重复性工作，一小套文件更有效，因为每个文件回答不同的问题：哪些内容应当在任务之间保持不变？一份完成的结果需要包含什么？在依赖结果之前，应该检查什么？

这里有一个实用的三文件模式。它不要求特定模型、应用或自动化框架。把文件放在工作内容旁边，放在仓库或项目文件夹里，让负责该任务的人都能读到。

用三个文件固定重复性AI工作

  1. 把持久上下文放进WORK-CONTEXT.md。这是你已经厌倦反复解释的内容：受众、范围、可信来源、需要避免的术语，以及操作边界。它应该包含事实和决定，而不是一堆过去的提示词。当某件事未知时，就标记为未知，而不是让AI去填补空白。
  2. 把完成标准写进DONE-CHECKLIST.md。在开始一次运行之前，让预期结果变得可观察。“把它做好”无法被一致地审查。“包含要求的章节，引用提供的来源，控制在800字以内，不泄露私人数据”则可以。清单还能让分歧变得更便宜。审阅者可以指出某一项未满足，而不必重新争论整份草稿。
  3. 在PRE-USE-REVIEW.md中审查结果。草稿只是开始，使用前需要有人确认它是否真的可以依赖。

这套做法的核心不是让AI更聪明，而是把那些不该随对话消失的规则固定下来。上下文、完成标准和审查要点分开存放，每次运行都能回到同一套判断依据。对于需要反复执行的任务，这比不断重新解释任务本身更省力，也更不容易出错。