知识飞轮，不追求完美再启用

每个迭代的产物沉淀成下阶段输入，知识作为真实迭代的副产物。反模式只修不建，通行证是重复出现。

到这一步，你已经把 vibe coding 的整个链路跑通了。最后一件事，是让这套做法自己能生长：把每一轮攒下的知识回流成下一轮的地基，这样你不是"越做越启动"，而是越做越顺。

读完你能回答：

• 知识飞轮是怎么"转"起来的？
• 为什么"不追求完美再启用"是对的？
• 反模式怎么避免越攒越多？

知识飞轮怎么转

• 每轮沉淀：这轮解决了什么问题、得出什么结论、踩了什么坑，记下来 anthropic-sdlc
• 回流：把沉淀写回项目上下文 / 规则 / 脚本，让下一轮自动生效
• 滚动复用：下一轮直接站在上一轮的土地上，不用重新踩

轮子转起来之后，AI 每次都比上次"更懂你"。

不追求完美再启用

• 别先搭一个"完美的知识库"再开始——那通常永远开始不了
• 知识是真实迭代的副产物：每轮干出来的结论顺手沉淀，别把它当独立工程
• 先让它转，边转边补，比憋大招有效得多

反模式只修不建

• 一次问题：先修好，别急着写规则
• 重复出现：才沉淀成规则 / 脚本
• 从来没出现过：别预造，那不是指导是负担

给"建"设一道门槛：只有当同一件事反复出现，才值得固化成规则。否则规则库会越堆越臃肿，最后没人信。

人工介入即知识缺口

飞轮的输入不只来自复盘，也来自每一次你不得不接管 AI 的时刻。模型卡住或做错时，先问自己一句「我知道什么它不知道」——每次人工介入都在暴露一个知识或数据缺口，把这块上下文补进知识库，理想情况下下次不再求助。把介入当信号去收割，而不是当税去忍受。

知识飞轮的整洁

• 无限增的规则要定期删，跟代码一样会腐烂
• 只留"代码之外影响判断"的信息，别复制代码能表达的东西
• 给条目带状态/来源，读之前先判断还适不适用
• 载体按更新路径选：文件 + Git 优先——知识、代码、测试、索引进同一个 MR 一起评审、合并后共享同一版本，改完即生效；RAG / 图谱只做检索补充，代码变化后要走同步、切片、索引的长链路，更新延迟就是失效窗口 taotian-price360

把知识飞轮转起来且转得干净，vibe coding 就从一个"技巧"变成了一套"可持续"的协作方式。接下来，让它经得起换人换会话：换个人也能接得上。