在一个由好几个 AI（Agent）轮流接力干活的代码仓库里，常常会出现一个让人细思极恐的问题：

上一个 AI 在某个地方吃过亏，但这个教训只写在它自己的对话记录里，等下一个 AI 接手时，手里根本没有这份避坑指南，结果又一头掉进同一个坑里。

在 Polter 这个项目（一个基于高性能终端 Ghostty 改造的项目）的开发中，就真实发生过这样一幕：

连着六个提交，系统测试显示的都是清一色的全绿，一切正常。但运行一次不带任何过滤条件的全局测试（

），就会发现早就红了，因为那条出错的穷举 

 分支，在前面那六次测试里一次都没有被编译过。

六个提交，谁都没发现，因为大家每次看到的都是绿灯。

为了解决前人踩坑、后人接着踩的问题，这个仓现在的做法是分两层放。

第一层：仓库外面的教训记忆库（记细节）

第一层记忆放在电脑里代码仓库的外面，路径是 

。规则很简单，一条教训一个 Markdown 文件，另外配一个索引文件 

截至 2026 年 9 月，这里已经攒了 240 条记忆，分三类：feedback（教训）170 条，project（项目相关）39 条，reference（参考、事实）31 条。

：给另一个终端里的 AI 发指令时，工具返回了 

。但实际上那条指令只是安安静静地停在了对方的输入框里，对方足足 32 分钟没收到。

 的意思仅仅是字打进去了，不代表提交发出了。更麻烦的是，输入框里没发出去的草稿，和一条被打断退回来的指令，在屏幕上长得一模一样，被打断的那条在历史记录里不留任何痕迹。

：发完关键指令后，去终端历史里找那条以 

 开头的原话，找不到就是没送到，别想当然地以为对方正在思考。

这样的文件每个都不长，下一个 AI 只要扫一眼第一行的摘要，就知道跟自己手上的活有没有关系，有关系再去读具体做法。

记忆库里有一个很酷的原则：结论被推翻了，文件也绝对不删。

。最早的结论说：测试过滤参数 

 不是在做过滤，而是在基线之外做叠加。因为当时测试发现，写一个什么都匹配不到的名字会报 85 个通过，写一个真名会报 86 个通过。

直到后来有人发现，如果在测试里放一个必然失败的 

，当过滤条件匹配不到时，这条测试根本就没跑，只有匹配到时它才会真正去跑并报错。旧结论就这么被推翻了。

但旧文件没删，而是在文件开头加上一行 ⛔️ 2026-09-18 推翻，把新读数写在最前面，旧读数留在后面。

 因为旧结论的实用部分依然成立，当你用一个匹配不到的过滤条件时，屏幕上照样显示 

，数字看着很正常，但你要测的东西其实一条也没跑。如果不留着这份错误档案，下一个 AI 哪天又量出 85 和 86，就会以为自己发现了新大陆，把那个老错误再犯一遍。

它只存在当前这台电脑的用户目录下，别人把代码 clone 过去，这 240 条一条都读不到。

另外也没人整理，时间久了出现了重复，比如 两边都有 ≠ 两边一样 这条出现了两次，不要动 git 暂存区 和 agent 不能碰暂存区 说的其实是一件事。

第二层直接放在代码仓库的根目录下，是个软链到 

 进仓库，谁 clone 代码，谁就能第一时间读到。

但这里的核心策略是：字数一定要少，只留最核心的红线。

这一节开头就写明了：这里列出的每一条，都必须对应在这个分支上付过代价的真实返工，不写空洞的大道理。

以前，文档里写着一条很正常的建议：全量测试太慢，平时优先用局部过滤（

AI 们很听话，两天里每一次跑测试都带着过滤。结果呢？仓里专门用来防错的三道一致性检查，因为没被过滤选中，两天里连一次都没编译过。

吃过这次亏之后，这条建议没删（写代码时用过滤是对的），但紧接着补上了一条生死线：

最终交付前，必须完整跑一次不带 filter 的全局测试，带 filter 的全绿，连这棵树能不能编译通过都证明不了。

仓里流传着一句话：绿不算证据，地板才算。

什么叫地板？就是你想知道一个检查机制灵不灵的时候，必须先故意把被测对象弄坏、亲眼看到检查报错红了，你才敢相信这个检查是管用的。

结果这个仓在这上面出过三次错：大家在拆除防卫代码时，直接把那一行代码给删了，编译器报错 

（未使用的函数参数）。系统一红，大家以为是检查机制起效了，其实代码连断言（Assertion）那一行都没跑到，红的只是编译错误。

为了填这个坑，现在的规范改成了：拆守卫时让代码照样编得过，用 

 把它空架起来，不准直接删行。

：负责装细节和过程。记录当时怎么出的错、为什么信错了、现场数据是多少。它可以很庞大，也可以随时推翻重写。

：负责装底线和红线。只留那些必须刻在骨头里、每次开工前必须知道的硬核教训。

细账记在外、红线带在身，用这种分层的办法，多个 AI 在同一棵树上轮流接力时，才能真正做到前人栽树、后人乘凉，不至于陷进重复踩同一个坑的死循环。

两百多条返工教训，怎么让下一个 agent 读到

本文介绍了一种为多 Agent 协作开发环境（以 Polter 项目为例）设计的双层经验记忆系统，旨在解决 AI 接手任务时因“经验不互通”而重复踩坑的痛点。

人工智能

职业发展

开发工具

AI接力开发中，仓库采用双层记忆机制防坑：仓外memory库存240条详细教训（含推翻记录），仓内CLAUDE.md仅存7条核心红线。关键规则：最终交付前必须跑无filter全局测试，拆守卫代码用空架代替删行，确保前人教训真正传给后继AI。

系统测试

编译器

Agent

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

两百多条返工教训，怎么让下一个 agent 读到

两百多条返工教训，怎么让下一个 agent 读到

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐