海域重启礼包码汇总 海域重启最新可用兑换码分享
2026-07-21
2026-07-21 0
这篇文章为你揭示如何让AI真正“记住”你的系统,通过知识自沉淀机制,告别重复学习,实现开发效率的指数级提升。核心内容:1. 传统开发模式下Agent“一次性记忆”的痛点与根源分析2. 从“追加式文档”到“自修正地图”的核心设计思路3. 实现知识自沉淀的三步具体改造方案

前面,我们给后端项目(23 个 Java 微服务)搭了一套 Kiro 开发体系:先是建了 9 个项目级 Skills(从 DDL 到 CRUD 到 Feign 客户端一条龙),然后用 Multi-Agent 流水线把需求分析→模块定位→代码生成串了起来。
Kiro CLI实战:接入蓝湖MCP+配置Multi-Agent流水线
跑了两个多月,效果不错——样板代码基本不用手写了,Agent 按项目规范生成,编译能过,结构对味。
但一个新问题浮出来了。
每次开需求,Agent 都很给力。但它不记得上次干了什么。
你上个月给 marketing-share 模块加了核苷酸打卡功能、建了新的 Feign 契约、跨服务调了 xxl-job 的定时任务。这些信息在那次会话里 Agent 全清楚。下次你(或同事)再来改同一个模块——Agent 一无所知。它得重新读代码,重新推断模块间关系。
这不是 Agent 笨,是因为代码是唯一的事实源,但 23 个模块几十万行代码,不可能每次全加载进上下文窗口。
Agent 需要一层「轻量的、在代码之上的模块知识」。
最朴素的想法是:每次开发完写个总结文档。
但凡维护过项目文档的人都知道,追加式文档写出来那一刻就开始过期。三个月后,文档说的和代码做的是两回事。这不是勤不勤奋的问题,是结构性矛盾。
既然追加式文档必然腐烂,那换个问法:什么样的知识载体能不过期?
推导过程:
结论出来了:我们要的不是"记录历史",而是一张随代码自我修正的地图。
原来的structure,什么都往里塞——模块树、包布局、每个模块详情。变化频率不同的东西混在一起,改一个怕碰坏另一个。
改造后:structure.md 只保留「几乎不变」的骨架(顶层模块树、标准包布局模板),加一张路由索引表——模块名→一句话职责→详情文件路径。
它是地图的目录页,全局 always-load。
在 .kiro/steering/modules/ 下,每个模块一个 md 文件。Kiro 的 frontmatter 机制让它只在你改对应模块时才被加载进上下文:
---
inclusion: fileMatch
fileMatchPattern:'modules/order/**'
---
每份文件有固定 schema(7 个字段):职责、核心表、对外接口面、出向依赖、入向契约、MQ 消息、关键业务规则。
Schema 是「写入契约」——有了它,后续无论是 Agent 还是人来更新,都知道往哪个槽位填。
关键设计:懒创建。
不提前批量生成 23 份——那是凭推测造假。只有当 hook 第一次真正触及某模块时,才依据真实 diff 创建它。
构建一个 userTriggered 类型的 Hook——开发完后在 Kiro 面板点一下「沉淀模块知识」按钮,Agent 自动执行:
我就不详细写喽(机密机密)
回到第一性原理:
越开发,地图越完整。不需要任何人额外维护文档。开发本身就是维护。
把 L2(架构决策记录/ADR)也接进来,让 Agent 在识别到非显然决策时自动追加。
登录查看剩余 70% 内容