企业官网建设流程全解析

写这个标题的时候，我心里其实挺有感触的。做编码智能体相关的开发也有一段时间了，前前后后接触过不少把智能体当“结对程序员”用的团队，也见过太多人一边吐槽“智能体怎么又失忆了”，一边继续把所有历史记录硬塞给它，塞到窗口爆了才被强制压缩。结果压缩一次，智能体就像换了个人，之前说好的技术约束、目录结构、命名规范，全被它“优雅地”忘掉了。后来我开始认真研究 AutoCompact 这套机制，自己动手调参、写提示词、设计外部记忆锚点，踩了一堆坑之后才慢慢摸清楚：上下文管理这件事，核心不是“怎么省”，而是“怎么主动断舍离”。

这篇就把我实际摸索出来的 AutoCompact 用法和调优思路整理出来，给同样被上下文问题折磨的人一个参考。

1. 为什么“上下文爆了再压缩”是下下策

1.1 上下文不是无限便签，压缩本质上是一次记忆重写

很多开发者对编码智能体的上下文有一个错觉：觉得聊天框里的历史记录，就像 IDE 里的编辑历史一样，存在那里就是安全的，随时可以翻回去看。但编码智能体的上下文是一个有硬上限的连续窗口，每一次对话、每一次工具返回、每一条报错堆栈，都会往这个窗口里塞内容。窗口满了之后，系统只能做一件事：把最早的内容压缩成一段摘要，腾出空间给新内容。

问题就出在这个“压缩”上。压缩不是简单的裁剪，而是让模型对旧内容做一次“提炼转述”。模型转述时，会自动“脑补”那些记不全的细节，于是摘要里出现幻觉信息是常态，不是异常。更要命的是，压缩之后原始内容就没了，你再想追问“当时那条路径是怎么选的”，它只能从摘要里给你编一个听起来合理的答案。我把这个过程类比成：你让一个新同事接手你写满批注的笔记本，还要求他只用一页纸把重点转述清楚，他转述完之后，你把笔记本烧了。之后所有决策都只能基于他那页纸——你觉得靠谱吗？

所以把“等窗口满了再压缩”当作默认策略，本质上是把风险积累到最后一刻。压缩之前，所有细节都在；压缩之后，细节全凭运气。AutoCompact 的价值恰恰在于把这个过程从“被动爆发”改成“主动管理”，在信息还没堆到危险水位时，就按照优先级一点点做精简。

1.2 被强制压缩之后，最容易出现的三个灾难现场

我在真实项目里观察过不少次强制压缩后的表现，几乎每次都会掉进同样的几个坑里。

第一个坑是“指令漂移”。压缩前，你明确告诉过智能体“这个模块不要引入额外的依赖库”，它也遵守得很好。压缩后，它突然开始往代码里塞第三方库，问它为什么，它理直气壮地说“根据之前的需求，这样做更高效”。其实是因为摘要里把“不要引入依赖”这条约束丢了，而模型为了自洽，自动补了一个看似合理的动机。说白了，它不是在撒谎，它是在用自己的方式补全缺失的记忆。

第二个坑是“重复劳动”。压缩前已经排查过某个函数没有内存泄漏，压缩后它又花半个小时重新排查一遍，然后得出相同结论。这类重复不是智力问题，是它压根不记得前面做过什么。表面上浪费的是时间，实际上浪费的是整个会话的信任度，你会开始怀疑它每一步是不是都在做无用功。

第三个坑最隐蔽，叫“口径不一致”。同一个项目，压缩前它管数据层叫 repository，压缩后它开始叫 dao。对外接口的命名、错误码的规范、日志格式，这些约定一旦在压缩过程中被丢掉，智能体就会用一套全新的词汇重新描述旧的东西。轻则代码风格分裂，重则接口对接直接失败。这三个坑，几乎每次强制压缩都会踩中至少一个。所以我后来才下决心把 AutoCompact 的配置和提示词彻底调了一遍。

2. AutoCompact 到底在“断舍离”什么

2.1 它和普通压缩的区别：渐进式分层遗忘

AutoCompact 最核心的设计思路，不是“满了就清空旧内容”，而是“旧内容按重要程度分层处理”。你可以把它理解成一个双层的整理机制：第一层，识别哪些信息是当前任务还在用的，必须原样保留；第二层，把已经翻篇的讨论、调试过程、临时方案压缩成一句话摘要。

实际表现上，AutoCompact 会在上下文使用率到达你设定的阈值之前，就开始渐进式整理。它不会等到窗口 100% 才动手，而是到了一定水位就触发一次小整理，把最老的内容摘要化，然后继续工作。这样每次整理的范围都很小，丢失的信息量也就被摊薄了。对比一下强制压缩：强制压缩是灾难片，一次火灾烧掉一整栋楼；AutoCompact 是日常保洁，每天擦一张桌子，桌子永远不脏。

但这里有个前提，它必须知道什么是“垃圾”，什么是“黄金”。默认情况下，AutoCompact 是根据通用经验来判断的，比如它知道文件路径、任务目标、决策结论比较重要，知道冗长的调试日志、重复的错误堆栈不那么重要。但通用经验不等于你项目的实际情况，所以需要你在提示词里主动告诉它：对你来说，哪些是绝对不能丢的，哪些是可以随手扔的。这就是我下面要说的“断舍离三原则”。

2.2 断舍离三原则：留结论、留约束、留状态

我实践下来，AutoCompact 的“舍”其实有一套很朴素的优先级，总结成三句话：

• 留“正在发生的事”，扔“已经翻篇的事”。比如“当前正在重构认证模块”是正在发生的，要留；“前三次重构失败的原因分析”是翻篇的，扔。
• 留“结论和约束”，扔“推导和过程”。比如“最终决定使用读写分离，因为写路径压力大”要留结论和约束；“当时对比了三种方案，分别分析了它们的优缺点”这些推导过程可以扔。
• 留“文件路径和当前状态”，扔“历次修改的心路历程”。比如“支付服务的主逻辑在internal/payment/service.go”要留；“支付服务先改了 A 文件又改了 B 文件后来觉得不对又改回 A”这种心路历程，扔得越干净越好。

我把这三条直接做成了一个对照表，写进了项目的提示词底座里，效果非常明显：

这个表看着简单，但你要真让智能体执行，光靠它自己悟是不行的，必须在系统提示词里把这套优先级固化下来。我后来测下来发现，只要这四类“黄金信息”不被压掉，压缩后会话质量基本能保住八成以上。

3. 实操配置与调教：让 AutoCompact 不只“会压缩”，而是“聪明地压缩”

3.1 阈值怎么设？别卡着 100% 玩火

AutoCompact 第一层可调的参数是触发水位。很多人的直觉是“窗口大，所以我可以多用点再压缩”，这个直觉在上下文管理上是错的。窗口使用率越高，单次压缩的运算量越大，摘要的失真率也越高，而且压缩的一瞬间会打断智能体的工作流，如果它正好在处理一个长文件，压缩时机很糟糕的话，甚至会丢步骤。

我给一个比较稳的通用配置：假设窗口上限是 8 万 token，把 AutoCompact 的触发水位设在 75% 到 80%，也就是 6 万到 6.4 万 token 时启动首次整理，整理目标水位设在 60% 到 65%，也就是压到 5 万 token 左右。这样做的核心逻辑是：保留一部分余量给突发输出，避免在智能体正在写一段长回复时触发压缩中断；同时压缩幅度小，摘要质量高，丢失细节少。

这里给一组我实际用过的计算参考：

• 窗口上限：80000 token
• 触发水位（80%）：64000 token，此时 AutoCompact 开始整理旧上下文
• 目标水位（62.5%）：50000 token，整理完成后新内容可写空间恢复
• 单次压缩体量：约 14000 token，压缩比接近 22%，信息失真率明显低于强制压缩

你可能会问，为什么不把触发水位设到 90%？因为你的输出和工具返回是没法精确预估的，写代码场景经常出现单次工具返回就是几千 token 的情况。如果 90% 才触发，一次大返回就可能直接冲破窗口，系统只能走强制压缩的老路。所以阈值设置的核心不是“最大化窗口利用率”，而是“给不可控因素留缓冲”。

3.2 提示词里写清楚：哪些是“锚点信息”，永远不能丢

参数只是地基，真正让 AutoCompact 变聪明的是提示词。你要在系统提示词或者项目指令里显式声明“锚点信息”清单，让它在压缩前优先保住这些内容。我常用的写法是这样的：

你是本项目的编码智能体。在整理旧对话时，必须优先保留以下“锚点信息”： 1. 当前目标：用户正在推进的任务是什么，做到哪一步了； 2. 硬性约束：明确禁止使用的依赖、必须遵守的架构分层、接口命名规则； 3. 关键决策：已经拍板的方案，以及一句话理由； 4. 活动文件：本轮修改涉及的完整文件路径和当前位置； 5. 下一步动作：压缩前用户明确要求的待办事项。 若锚点信息与旧对话冲突，以锚点信息为准；压缩时不得改写锚点信息的含义。

这段提示词看起来平平无奇，但作用非常大。它把“哪些是黄金”这件本来靠模型猜的事，变成了一个明确的检查清单。实测下来，加了这段之后，压缩恢复后的“失忆率”显著下降，智能体不再频繁反问“我们之前定了什么方案”。

另外还有一个很容易被忽略的细节：提示词里“当前目标”这一项，建议每次任务切换时手动更新一下。比如你从“实现登录接口”切到“修复登录接口的并发问题”，如果不更新目标，AutoCompact 会默认保留旧的“实现登录接口”作为锚点，压缩完它还在惦记着实现，而不是修复。

3.3 外部记忆锚点：把关键信息从上下文里搬出去

AutoCompact 再怎么优化，本质上还是在动态窗口里做修剪。但有一类信息，其实根本不应该放在上下文里，比如项目规范、API 约定、已确认的架构决策。这些东西是长期稳定的，放进上下文只会被后续的对话逐渐稀释和覆盖。我更推荐的做法是：把它们落到项目里的两个文件里，让智能体主动去读，而不是靠上下文硬记。

我维护的两个文件是docs/decisions.md和docs/current-state.md。前者记录所有已拍板的技术决策和理由，后者记录当前改动范围和下一步计划。每次开始新任务时，我会在指令里附带一句“先读 docs/current-state.md 了解当前状态”。这样，即使 AutoCompact 把对话历史压缩得只剩一个摘要，智能体依然可以通过读取文件把关键状态拉回来。外部文件就是它的第二大脑，上下文窗口只是它手里的便签纸。

这套“外部记忆锚点 + AutoCompact”的组合，我在一个模拟的跨平台同步工具项目上跑过完整流程，效果非常明显。压缩发生时，智能体会主动去读这两个文件来确认当前目标，而不是凭空靠摘要猜。你可以理解成：AutoCompact 负责整理桌面上的杂物，外部文件负责保管保险箱里的合同。桌面乱不乱无所谓，合同的完整性不受影响。

4. 实测记录：我在真实项目中的 AutoCompact 调优路径

4.1 基线场景：默认配置下的“灾难半小时”

我拿自己做的一个跨平台桌面工具项目当测试床，这个项目前后改了七八个模块，上下文压力很大。在没调优之前，我用的是默认配置：AutoCompact 运行但提示词里没写锚点清单，外部记忆文件也不存在。结果是一次较大的重构会话里，连续两次强制压缩后，智能体先是把数据库连接池的配置参数记错了，接着在没有任何提示的情况下把接口返回值从对象改成了数组，导致前端对接全部失败。

当时我记录下来的问题清单是这样的：

• 压缩后丢失了三层架构约束，开始把业务逻辑直接写进控制器；
• 错误地“回忆”出不存在的额外依赖；
• 对已经排查过的问题重复排查；
• 对话风格突变，从简洁回复变成冗长解释。

这是非常典型的“默认压缩综合征”。它的根源不是 AutoCompact 不行，而是你什么都没告诉它，它只能靠通用经验猜。

4.2 三轮调优：从“能用”到“好用”

我后来分了三轮调优，每一轮只改一个变量，效果差异非常大。第一轮只调整阈值参数，把触发水位从默认的高水位降到 80%，目标水位降到 62%。这一轮的变化是：压缩发生的频率变高了，但每次压缩都很轻，强制压缩再也没有出现过。代价是每隔一段对话就会看到一次小整理提示，稍微有点打扰，不过整体稳定性提升了。

第二轮加入锚点提示词，就是上面那段“锚点信息”清单元，并且把两个外部记忆文件建好。这一轮变化最明显：压缩后智能体对当前状态的理解几乎没丢，不再反复问“我们现在要做什么”，代码风格也保持了统一。我推测是因为“代码风格指南”被我写进了决策文件里，压缩不影响它读取。

第三轮调整的是会话使用方式。以前我喜欢一个会话从头干到尾，现在我会在完成一个明确阶段后（比如完成支付模块），主动开启新会话，并在新会话的第一条指令里贴上迁移摘要。迁移摘要不是我手写的，而是让智能体根据 docs/decisions.md 和 docs/current-state.md 自动生成。这样 AutoCompact 每次要压的东西都很少，因为会话本身就不可能太长。

三轮数据我放一个表，方便对比：

说实话，第二轮和第三轮的效果都超出了我的预期。我现在基本固定采用“低阈值 + 锚点清单 + 外部记忆文件 + 阶段迁移”的组合，上下文管理再也没成为项目瓶颈。

5. 常见问题与排查技巧实录

5.1 压缩后智能体“性格突变”，代码风格对不上

这是最常被吐槽的问题。症状非常直观：压缩前它的函数命名是getUserInfo，压缩后变成fetchUserData；压缩前注释很精简，压缩后变成小作文。根本原因是摘要里没有保留风格指示。解决办法有两个，二选一或都用：一是把代码风格规范写进docs/decisions.md，让智能体压缩后重新读取；二是在提示词的锚点清单里加一行“始终保持与项目现有代码一致的命名风格和注释习惯”。我实测下来，后者见效更快，前者更稳。

5.2 压缩后它反问你“我们刚才说好了要干嘛”

这个问题的本质是“当前目标”这个锚点没有保住。原因要么是锚点清单没写，要么是任务中途切换过目标但没有更新提示词。排查顺序是这样的：先检查你的系统提示词里有没有要求保留“当前目标”这一项，再检查最近一次切换任务时有没有更新目标描述。如果两个都没问题，那大概率是摘要生成时出现了幻觉，把目标改写了。遇到这种情况，最直接的手段是手动编辑压缩后的摘要，把正确目标补回去，然后用新摘要重新开启对话。AutoCompact 产生的那段摘要，你完全可以把它当成一个可编辑的文件来对待。

5.3 上下文眼看要满了，但 AutoCompact 就是不触发

这个问题我遇到过一次。排查后发现，是因为触发水位设置得太高，而某次工具返回的数据量又特别大，窗口直接从低位冲到了高位，压缩还没来得及运行就已经满了。根源还是缓冲不足。建议把触发水位调到 75%-80%，不要赌自己的输出不会突然膨胀。另外检查一下是否有任务处于“锁定”状态，有些实现里智能体在处理特定工具调用时会暂停压缩，这也是不触发的一个原因，等它完成当前调用就好。

5.4 摘要里出现了编造出来的信息

AutoCompact 压缩的过程，本质上是让模型对旧内容做一次“再创作”。只要模型参与“再创作”，就必然存在幻觉概率。区别只是概率高低。降低概率的方法，一个是压缩触发前保留足够的原始内容，也就是别等窗口太满再整理；另一个是在设计锚点清单时，要求压缩不得改写锚点信息的含义，只能原样保留。如果你发现摘要里某个细节写得很具体，但你知道项目里根本没有这个东西，说明压缩时模型补全过度了。解决方式是修正摘要并重新插入，不要试着通过追问让模型“纠正记忆”，它的记忆已经被覆盖了，你问它，它只会编得更多。

5.5 常用排查速查表

6. 三个反直觉的经验，最后分享给你

6.1 压缩不是越勤越好

AutoCompact 用起来之后，很容易走向另一个极端：恨不得每聊几句就让它整理一次，让上下文窗口永远干干净净。但我的实测结果是，压缩本身有成本。每次压缩都会打断智能体的工作流，如果你设置的水位太低，它可能正在处理一个复杂功能时，突然停下来整理旧信息，这种频繁打断会让长任务的连贯性严重受损。我的经验是：触发水位不要低于 65%，除非你的任务都是短平快类型。压缩的目的是降低风险，不是追求窗口数据量最小化。

6.2 省下来的上下文，不等于省下来的质量

很多时候，你以为压缩掉的是“没用的废话”，实际上压缩掉的可能是后续某个决策的“论证依据”。比如你之前和智能体讨论过“为什么不能用某方案，因为存在事务边界问题”，压缩后摘要里只剩“某方案不可用”，但“事务边界问题”这个理由没了。结果后面又出现一个类似场景，智能体判断不了当前情况是否也涉及事务边界，就直接套用了“不可用”的结论。这不是它变笨了，是它的推理前提被压缩掉了。所以我在提示词里对“关键决策”的要求是：保留结论 + 一句话理由，两样缺一不可。

6.3 最好的压缩，是根本不需要压缩

最后一层心得：AutoCompact 再怎么聪明，也替代不了合理的会话规划。阶段化推进、外部记忆文档、定期开新会话，这三种手段任意一种都能大幅降低上下文压力。我自己现在的工作流基本是：每个大的功能模块一个会话；每个会话开始前先读current-state.md；完成一个阶段后，让智能体更新两份文档，然后结束会话。AutoCompact 对我来说，更多是一个“最后一道防线”，而不是日常依赖。日常依赖的是工程化的记忆管理习惯。

我在实际项目中用过一段时间之后，体会到最关键的一点是：上下文管理不是智能体单方面的事，它需要你用提示词告诉它哪些信息值得珍惜。你给了它明确的断舍离清单，它才能在你需要的时候，把最重要的事情原封不动地交还给你。