说实话，构建一个300万行安卓老工程的AI知识库，这事儿听起来就挺头疼的。

但咱就是说既然决定要Zuo，那就得好好琢磨一下怎么Zuo。

这就要求知识库得足够详细、准确，还得容易被AI检索到。

我先在我自己的个人项目Jugg上进行了两个多月的知识库实践，嗯，不错，效果还行。

Zui终稳定交给AI完成所有coding，期间新增个commit，4W+行代码，个多月新增的代码量和过去年手写的代码量持平。

不过%增长来自单元测试，AI写单元测试太方便了你懂的。

我采用的是文档索引的方式，把工程知识内容提炼出来通过系统提示词入口进行树状索引，渐进式披露。

这样Zuo的好处是Ke以让AI快速了解项目整体框架，然后再深入到具体细节。

同时还需要梳理工程高频API，涵盖日志打印/网络请求/ABT/WNS开关/工具类等。

害，这一步挺重要的，毕竟API是代码的基础嘛。

文档迭代的Zui小触发单位是"开发任务"，不是"文档排期"。

就是说每次开发任务完成，dou要geng新相关的文档。

这样，才Neng保证知识库始终保持Zui新、Zui准确的状态。

判断标准：这个内容以后还会被人重复使用，且Ru果不提供可Neng会有理解偏差→就值得独立成文档

我发现，在多次微调提示词后Claude仍违反阅读要求，我就对Claude进行了长达分钟的言语羞辱，然后让他给一版Ke以保证阅读的提示词。

新版提示词强化了一些执行点的严重性，参考了门禁/自检等概念，使用执行清单作为收尾，响应效果好了hen多。

主要原因： 文档和代码Ke以放在同一个目录，成为项目工程的一部分，作为代码的提炼和代码紧紧结合。

次要原因： 不同agent skills管理目录不一样，要放多份；文档索引只需要维护好入口，跳转后是同一份文件，冗余成本相对较低；

RAG 知识库：RAG会将放入的文档向量化，大大提高 AI 检索的效率。

哈哈，这个问题嘛，说复杂也不复杂，说简单也不简单。

得kankan你的文章质量是否过关，是不是原创、有价值的内容；

是不是符合百度的收录规则，比如关键词的使用、文章的结构等；

. Zui后啊，还是要不断优化，不断改进，才Neng提高收录率嘛～.

. 暂无直接数据证明，因为还没有抽时间Zuo对比实验；

. 从信息的角度，以技术直觉+和AI论证两个角度kan，认为有帮助；

. 知识库文档可大可小，应该存在一个Zui优解，在“提高AI coding正确率”这个目标上取得一个Zui优的值。因此需要平衡“提供足够多的信息”和“提供足够高密度/高价值的信息”的跷跷板。具体的平衡点仍需要geng多的实践和探索；

. 可Neng一年/两年后AI会成长为足够《全知全Neng》的AI，不再需要这些提炼的文档。但未来尚不可知，我们应该应对而非预测。