停止写Prompt，与AI代理对话才是正解

你的Prompt文件夹，其实是一个问题的症状

打开你的笔记应用或代码仓库，大概率能找到这样一个文件夹：系统提示词、代码库前言、风格规则、"提交前务必跑测试"的提醒——只因为上一次Agent忘了。每个会话开始时，你重复同一套仪式：复制、粘贴、重新解释、重申规则，然后祈祷到第十轮对话时它还没跑偏。每一次往这个文件夹里加东西，感觉像是在进步。

事实恰恰相反。

brethof-brain的开发者分享了自己的亲身经历：他执行这套仪式长达数月，直到2025年12月，团队自研的Agent开始运行在一套记忆系统之上——也就是后来产品化的brethof-brain。从那以后，他再也没有粘贴过任何前言。

这篇文章拆解了这次转变的真实过程，包括一个很少有人提及的部分：你扔掉模板的第一周会很不适应，而且失败的方式是可预测的。

为什么Prompt永远不够好

Prompt的本质是一次性的、无状态会话简报。这是结构性问题，不是写作技巧问题。那些本应永久生效的规则——提交信息怎么措辞、哪些测试重要、什么方案已经试过并否决了——每次打开新会话时都要从零重新争论一遍。于是你把Prompt写得更长。然后它到达一个临界点：Agent开始略读，或者任务本身淹没了规则，或者会话还是跑偏了，你只好重来。

真正的修复方案不是学更高级的Prompt写法，而是把两个职责从Prompt中彻底剥离：

**一是自动绑定每个会话的常驻规则。**写一次，几乎每条消息都加载，永远不再重新粘贴。

**二是每次提问前自动生成的简报。**从记忆中提取与当前问题相关的内容，组合成简报。

这两者一旦就位，Prompt只需要承载任务本身。其他一切在Agent回答之前就已经在那里了。Prompt从来就不该充当记忆——它只是在没有其他选择的时候，被迫承担了这个角色。

理解这个问题的关键，在于大语言模型会话的两个技术特性。

无状态性（statelessness）：每次调用模型API，服务端并不会保留上一次对话的任何状态。你以为的"同一个会话"，实际上是客户端把历史消息按顺序重新拼成一段长文本再发过去。一旦窗口被截断或新开一个会话，之前所有约定就全部归零——这正是Prompt必须被反复粘贴的根本原因。

上下文窗口（context window）：模型单次能"看到"的Token总量是有限的，且塞得越满，位于中段的信息越容易被忽略（业界俗称"lost in the middle"）。因此把长期规则塞进Prompt会造成双重损耗：既占用本就稀缺的窗口空间，又因为规则与任务混杂而降低模型的注意力质量。记忆系统的做法是把长期规则与当前任务分通道注入，在结构上缓解了这两个限制。

对话式交互是什么体验

最直观的对比发生在一个普通的工作日早上。开发者打开会话，输入"continue"——它就真的继续了。Agent拥有上次会话停止位置的笔记和项目计划的后续内容，直接从任务中间接续。不需要回顾，不需要"这是代码库结构"，不需要以前每次会话前十分钟用来写的五点式方向说明。

第二个区别出现在需要做改动的时候。不再需要模板，只需要一句话："部署脚本应该始终先跑迁移检查。"有意地说一次，它就变成了永久规则——之后再没有重复说过。当某个Prompt触及某条规则时，规则会随Prompt一起到达；你不是在信任Agent的记忆力，简报在它开始回答之前就已经完成了。

第三个区别最能节省Token和时间：Agent不再重新提议你已经否决过的东西。被替代的旧方案记录会随Prompt到达，当它深入检索时，否决本身连同日期和你的理由都在那里。没有人会第四次争论你三月份已经做出的决定。

这就是"对话"在这里的含义。不是为聊天而聊天——它意味着Prompt不再需要充当简报，因为简报每次都被自动生成好了。

这里所说的"记忆系统"通常由三个组件协作完成，理解它们有助于判断自己是否需要这类工具：

• 写入（write）：从对话中抽取值得长期保留的事实、规则与决策，存为结构化条目。
• 检索（retrieve）：在新会话或新问题到来时，按语义相似度或关键词召回相关条目。
• 注入（inject）：把召回到的内容自动拼进系统提示词或首轮上下文中，也就是文中反复提到的"简报"。

检索质量决定了体验好坏。如果召回过早或不加区分，会把无关内容一起灌进上下文，反而干扰模型；召回过晚，则规则来不及生效。文中提到的"记忆按窗口读取"，本质上就是指写入侧按对话片段做批量归纳，而不是逐句实时落库。

刚扔掉模板时会出什么问题

以下是真实的踩坑经历，因为第一周教给我们的比之后几个月都多。

**习惯性想粘贴前言。**扔掉模板后的头几个会话感觉松散。有什么东西缺失了，但你说不上来，于是你"以防万一"又把旧前言粘了回去。那时候它已经是无效负载了，常驻规则早就覆盖了那些内容。这个习惯大约在第五个会话时才真正打破。

**规则需要有意识地写一次。**记忆系统不会读心。你旧模板里的那些东西——约定、语气、禁止清单——必须被有意地写成规则，一次到位。如果跳过这一步，指望Agent自己领悟，你会有一个糟糕的第一天，然后怪错对象。预留一个小时来做这件事。

**规则会腐烂成杂物抽屉。**开发者观察到自己的规则集逐渐膨胀：近似重复的、已完成项目的过时规则、一条膨胀成三个段落的。这就是为什么他们的规则被限制在每条1000字符以内，记忆系统会指出重复项并提醒规则集是否过大——但它永远不会替你编辑或删除。你不需要照搬这个限制，但你需要某种纪律：两条规则说同一件事时，合并它们。

**记忆不是即时的。**一段对话在会话稳定下来之后才变成记录，不是你说的那一秒——记忆按窗口读取，所以它保留的是对话"沉淀"下来的内容，而非每个半成品想法。失败模式是：你在第三个会话说了某件事，以为它现在是铁律，结果第四个会话时被打了脸。解决方案：当下就重要的事，有意识地说出来；最终会重要的事，让记忆整理机制自己捕捉。分辨这两者是和一个有记忆的Agent对话的核心技能。

**规则腐烂（rule rot）**是记忆系统长期使用中最常见的退化模式，它的成因是写入成本低而清理成本高：说一句"记住这个"几乎零成本，但要发现两条规则彼此冲突、或某条规则所指的项目早已归档，则需要主动审视。随着条目增多，检索时被召回的概率分布也会被稀释，新规则的权重容易被历史冗余淹没。

因此文中提到的"1000字符上限"和"重复项提醒"并非洁癖，而是对抗熵增的必要机制。一个可操作的做法是每月做一次规则审计：把当前规则集打印出来通读一遍，合并同义项、删除失效项、把过于笼统的条目拆成可判定的具体条目。记忆系统可以帮你发现重复，但判断"这条还有没有意义"依赖的是你自己的项目语境。

如何完成切换

按顺序执行，今天就可用：

1. **先装好记忆系统。**告诉你的Agent："install brethof-brain。"这就是全部安装步骤——它会拉取客户端、接好钩子、自查。你只需要做一个人工步骤：注册、选择本地或托管、在安装器请求时于brethof.ai上批准连接。

2. **写一次常驻规则。**在删除前言文件夹之前，把里面的内容倒出来，写成明确的规则。通用的用于所有项目，项目专属的按项目分开。

3. **停止粘贴。**有意识地停止。下次打开会话时只给任务，看看简报已经覆盖了什么。你会发现它覆盖的比你预期多，而遗漏的恰好是你从未写下来的那些——这就引出了下一步。

4. **测试：**每次你发现自己又在重新解释某件事，那不是该写Prompt的信号，而是一条该保存的规则。说"记住这个"，然后继续。

Prompt堆积从来不是写作技巧问题。它是一个记忆问题，穿了一件技巧的外衣。教你的Agent一次，然后别再守着那堆模板了。

判断某件事属于"当下刻意说出"还是"留给记忆自动沉淀"，可以用一个简单的经验法则：

• 需要立刻生效的：跨会话必须遵守的约束、会反复影响判断的偏好、已经被否决的方案及理由。这类内容一旦漏说，下一次会话就可能重蹈覆辙，应当明确地用"记住这个"落库。
• 可以让其自然沉淀的：任务执行过程中的中间探索、某个文件的具体改法、一次性的排查思路。它们属于当前任务的局部状态，写进长期记忆反而会污染检索结果。

这条界线并非一开始就能拿捏准确。头一两周最常见的偏差是过度写入——把大量临时信息也当成规则保存，导致召回质量下降；接下来又容易走向另一个极端，什么都不记，于是再次退回到反复解释的老路。随着对系统行为的熟悉，这条界线会逐渐内化成本能。