第三个月的时候，我问它"上次支付回调那个 bug 是怎么修的"，它准确地说出了修复方案和当时的讨论记录。
第一个月：一个普通的 AI 编程助手
三月初团队引入 Qoder。之前我也用过 Copilot 和 ChatGPT 写代码，体验就那样——能补补代码、回答通用问题，对业务项目帮助有限。
第一天用 Qoder，体验和预期差不多。写工具函数、生成单元测试、解释复杂正则，都做得不错。但涉及项目特有的逻辑，它就是个新人。不了解我们的模块划分，不知道编码规范，不清楚之前踩过哪些坑。
比如我让它写一个订单状态流转的处理函数，它生成了一段标准的有限状态机代码，完全没考虑我们项目中订单状态有特殊含义——"已支付"和"支付成功"在我们系统里是两个不同的状态，中间有一个异步确认的过程。
一个不了解项目的 AI，你还能指望什么呢。
然后我注意到 Qoder 接入了一个叫 ContextDB 的服务。安装时跑了一条命令：
curl -fsSL 'https://context-database-client.oss-cn-hangzhou.aliyuncs.com/install.sh' | bash -s -- --agent qoder --api-key ctxdb-xxxxxxxx
没多想，跑完继续干活。
第一周的微妙变化
到了第一周结束，我开始注意到一些细微的变化。
我让 Qoder 写一个数据库查询，它没问我用什么 ORM，直接用了 GORM。这是对的，我们项目确实用 GORM。应该是周二的时候我在对话里提了一嘴"我们的 UserRepository 用 GORM 的 Preload 做关联查询"，它记住了。
又一次，让它生成 API 的错误响应，返回的结构是 {"code": xxx, "message": "...", "data": null}。正是我们团队约定的统一响应格式。我不知道它是从哪次对话里推断出来的，但格式是对的。
这些是小事，但体验完全不同。之前的 AI 助手每次对话都像和一个新人结对编程，你得从头解释背景。Qoder 开始表现得像一个正在熟悉项目的同事。还不算熟练，但已经开始记住一些基本信息了。
第二个月：它开始懂了
四月份变化变得明显。
有一次我在排查线上问题，需要查某个接口的超时配置。随口问 Qoder："payment-service 的 HTTP 超时设置的多少？"
它的回答："根据之前的讨论记录，payment-service 对外部支付的 HTTP 超时是 10s，其中连接超时 3s，读取超时 7s。这个配置在 3 月 22 日的一次讨论中确定，当时张三提议设为 5s，李四认为考虑到第三方支付接口的响应时间建议 10s，最终采纳了李四的方案。"
我愣了几秒。去翻了一下当时的群聊记录，它说的是对的。
这已经不是简单的"记住一条信息"了。它记住了最终决策，也记住了决策过程——谁提了什么方案、为什么选了某个方案。日后做技术复盘或者新人 onboarding 的时候，这种上下文很值钱。
一个让我印象深刻的例子
四月中旬我在重构一个模块，涉及用户权限校验的逻辑。让 Qoder 帮我写权限中间件的时候，它主动提醒我：
"注意：我们项目中有两种权限校验方式。标准 API 用的是基于 RBAC 的中间件（
auth.RBACMiddleware），但管理后台的 API 用的是基于 ABAC 的自定义校验（admin.PermissionCheck），这是在 2 月份因为运营需要灵活控制权限粒度而引入的。你要改的是哪个？"
它不仅知道有两种方案，还知道为什么会有两种方案。这种深度的项目理解，通常需要一个在团队里待了至少几个月的工程师才能具备。
我开始意识到 ContextDB 在后台做了一件事：它在持续地、自动地构建和更新我们项目的知识图谱。每次对话产生的信息不是被简单地存起来了，而是被拆解、归类、关联到了已有的知识结构中。
第三个月：它比我更了解项目
五月份出现了一个标志性事件，也就是文章开头提到的那一幕。
我在处理一个新的支付相关问题，想起之前有个类似的 bug，但想不起来具体怎么修的。试着问 Qoder："上次支付回调那个 bug 是怎么修的？"
它的回答：
"4 月 8 日，工单 #20240408-015 报告了支付回调签名校验失败的问题。根因是第三方支付平台在回调中新增了
timestamp字段，但我们旧版本的签名算法没有包含这个字段，导致签名不匹配。修复方案：在
payment/callback.go的verifySignature函数中，将timestamp加入签名计算的参数列表。同时增加了签名时间戳的有效期校验（5 分钟窗口），防止重放攻击。当时讨论中还提到了是否要兼容旧版签名算法（不含 timestamp），最终决定做一个版本判断：如果回调 headers 中有
X-Payment-Version: 2.0，使用新签名算法，否则走旧逻辑。这个兼容逻辑在 5 月 1 日第三方支付全量升级后可以移除。"
我当时有点愣。这不只是"记住了"。一次完整的故障处理过程——问题描述、根因分析、修复方案、讨论过程、后续计划——全部结构化地保存了下来，并且能在需要的时候精准召回。
我自己都忘了那个兼容逻辑的存在。不是 Qoder 提醒，我可能在新代码里又踩一遍坑。
团队共享的威力
第三个月另一个明显的变化是团队协同。
我们团队 5 个人，都接入了 ContextDB。到第三个月知识库中已经积累了大量项目上下文。一个同事花了两小时让 Qoder 理解了我们的 CI/CD 流程和部署配置，这些知识自动进了共享 Workspace。第二天另一个同事调试部署问题，Qoder 已经知道我们的部署架构了。
这种效果会叠加。一个人的学习成果变成团队的知识资产，5 个人各自积累的知识相互补充，知识库的丰富度和准确度都在加速增长。
第三个月末我们做了一次非正式统计：新功能开发周期平均缩短约 30%（减少了了解背景的时间），bug 排查时间平均缩短约 40%（历史修复方案可检索），新人 onboarding 时间从 2 周缩短到 3 天（Agent 随时回答上下文问题）。
不过这些数字只是我们 5 个人的非正式统计，样本很小，不具备普遍性。不同项目类型、不同团队规模的结果可能差异很大。而且我们团队本身就比较积极地使用 AI 工具，如果团队成员很少和 Agent 对话，知识库积累会很慢，效果也会打折扣。
回过头看：为什么有效
回顾这三个月，我觉得 ContextDB 之所以有效，有两点比较关键。
它不打断工作流。我不需要额外做什么"知识管理"的动作。正常和 Qoder 对话、正常写代码、正常排查问题，它在后台自动提取、存储、整理信息。知识沉淀是工作的副产品，不是额外的工作。
它真的在理解而不只是存储。原子事实、Entity Card、Memory Graph 的三层架构让信息不是平铺在向量数据库里的碎片，而是一个有结构、有关联、有权重的知识网络。它告诉我"payment-service 的超时是 10s"的时候，同时知道这个配置的来源、背景和相关联的决策。
Token 成本方面，我一开始有点担心——Agent 每次对话都带着历史上下文，消耗会不会暴涨？实际用下来还好。它在 LOCOMO 基准测试中的 Token 成本大约是 LightRAG 方案的三分之一。原理是 Entity Card 常驻保持基本认知，按需精准检索只召回真正需要的细节，不是每次都把整个历史上下文塞进去。不过这个基准测试的结果和实际编程场景之间还是有差距的，仅供参考。
但也有让我不太满意的地方。三个月积累下来，知识库里已经有一些过时或者不太准确的信息了。虽然系统有置信度衰减机制，但有些东西不会自己"消失"——比如一个已经被废弃但没人提过的配置项，它还在那里，偶尔会被 Agent 在回答里带出来。清理这些事情挺麻烦的，知识管理这件事，果然不管有没有工具，都逃不开"积累容易维护难"的规律。
三个月后的感受
三个月前我以为 AI 编程助手的上限就是帮我写代码写得更快。现在我觉得它更值钱的地方是让 AI 理解你的项目、你的团队、你的业务。
这个理解不是一次性灌入的，是在日常工作中自然积累的。每次对话、每次 bug 修复、每次技术讨论，都在丰富 Agent 对项目的认知。到第三个月，它已经不只是一个代码生成器，而是一个了解项目的虚拟团队成员。
不过我也在想，三个月可能还在"蜜月期"。真正的考验是半年后——知识库继续膨胀、过时信息增多、冲突积累——这套机制还能不能维持现在的效果。目前还没有答案。
参考链接：ContextDB 快速入门
