[千星开源]与其让cc通过grep翻字典，不如给他一个仓库级别的chatgpt，x上20w粉丝大v推荐，大佬李笑来贡献，借鉴deepseek-ngram思想，项目自荐

开发调优
, , ,
1

本帖使用社区开源推广，符合推广要求。我申明并遵循社区要求的以下内容：

  • 我的帖子已经打上 开源推广 标签： 是
  • 我的开源项目完整开源，无未开源部分： 是
  • 我的开源项目已链接认可 LINUX DO 社区： 是
  • 我帖子内的项目介绍，AI生成、润色内容部分已截图发出： 是
  • 以上选择我承诺是永久有效的，接受社区和佬友监督： 是

以下为项目介绍正文内容，AI生成、润色内容已使用截图方式发出

2025年末bash is all need思想的普及，包括claudecode，codex，cursor，antigravity等ai编程工具都采用了bash命令这种思想，例如，当我们让ai找一个具体的代码的时候，他会grep搜索相关的关键词，不停的翻看查找，这就有一个问题，我们刚操作ai助手的时候，他是一个比较纯洁的上下文，所以性能是最强的时候，随着上下文增多，性能越来越差，佬友们肯定感同身受。在算法层面，transform架构也面临同样的问题，deepseek-ngram（ps：有幸改了一个单词误用作为了deepseek-ngram仓库的贡献者）提出了一种解决思想，以空间为代价，换取性能上的优化，我的这个开源项目也借鉴了这种思想。

image
image1034×576 155 KB

具体的思路如图，维护一个项目知识库及agent，claudecode和codex这种工具只需要ask就可以获取项目的非常详细的细节，而不用牺牲上下文，这个方案和subagent获取信息相比，更全面，也兼顾不同架构之间的信息，同时他也不依赖最顶级的claude/gpt的编程模型，测试时，minmax2.7这个级别的模型便可以很好的完成任务。
举一个例子，以openclaw仓库为例，使用这个项目之后，会调用非常多非常多的llm（直接把所有的代码放进去，会调用很多次llm，例如代码长度30k，llm支持100k，只需要调用一次来分析，如果代码300k，，那就是10次调用来分析，（不打满上下文是为了高性能）那么就是那么直接将代码整体作为上下文给到llm，然后的话来分析出相应的md文档，再由相应的agent，专门回复cc问的问题）
同时agent.md文件用的是python的import this，这个很简洁，平时使用也一直在用为系统提示词
项目开源之后，因为运气原因，不知不觉就1.1kstar了，逛l站也很久了，也开源了一些东西，也希望分析给佬友，如果有issue或者方向的指点，感激不尽。
当前的难点也很明显，之前只规划于python项目，所以有一层import架构层，有一个issue提出go项目不能用，所以就砍掉，借鉴了另一个知识图谱的项目，然后github_trending上有一个把仓库向量搜索的解决方案，个人认为向量匹配这方面并不是很优雅的解决方案，原因是，不够简单明了。
当前方案还有一个问题是，每次refresh都要全部来形成agent.md，这个很有问题，目前正在寻找解决方案，即每次只需要刷新改动部分，和git部分就好了。
（ps：在进入l站前，项目一直停滞，虽然实习公司报销订阅费，但是一直没有api来使用，感谢各位佬的教程，反代教学，得以咸鱼30块买到质保teams，项目才能很好的推进）
如果需要项目经历，欢迎pr，非破坏性质都会合并。
欢迎star

45 个赞
利用AI开发大项目时怎么解决上下文大小限制的
对github上排名火热的AI辅助工具需要持谨慎态度
小白问一下佬们在新开的会话里面给AI提需求的时候都会先让AI熟悉项目吗
代码图谱工具
问个AI解决不了的问题，怎么提升开源项目Star数？
2

没添加开源推广标签，似乎也没链接L站，楼主修改一下，不然容易被举报

4

感谢

image
image2252×694 33.5 KB

已经link上了佬

1 个赞
5

如果把cc/codex当做人来看的话，给他一个仓库，告诉他你读取这个仓库，就相当于给人一本字典，grep就相当于一个音标，但是明显给他一个chatgpt（项目级），不论是效率还是省性能而言，可能更合理

6

还有一个想法，有佬能指导吗，是否能够沉淀下来呢，比如说以后的仓库就不是代码库，而是md文档库，每一次更新有md更新，思路还是比较混乱，欢迎佬指导

7

佬友这个项目是不是和卡帕西的那个llm-wiki原理差不多？是用llm去总结，生成md文档吗？

1 个赞
8

思想刚好撞一起了，我也给k神发过邮件，但是没有回我啊哈哈，虽然我想较于k神更早，但是在我之前已经也有很多维护这种llm知识库的了

2 个赞
9

那么问题来了，佬有没有对比过 token 的消耗啊？

就是谁的消耗更低？

1 个赞
10

grep更低，因为它只需要搜索grep，这个项目的优点在于可以用更弱的模型来做，而且精度更好，上线更高，而且对于cc/codex而言，可以把更多的上下文用来解决问题，而不是搜索上，并且对于团队而言，这个项目维护的md文档更有优势，复利价值非常高

11

不怕生坏命，就怕用错名，Antigravity…这个反重力的名字太糟心了，感觉项目火不起来80%是反重力的锅！

1 个赞
12

起步阶段这个名给了很大的贡献，也上过antigravity的谷歌开发者的社区，没想到antigravity倒了 :sweat_smile:，佬有推荐的名字吗，我改改，欢迎提出新的仓库名，采纳后麦当劳穷鬼套餐一顿

1 个赞
千星项目求新名（mdl穷鬼套餐悬赏）
13

佬有了解过 trellis 嘛 可以去看一下 应该对于解决沉淀问题有所帮助

14

有和Argument 对比过项目理解么，确实是项目理解足够，干净的上下文对plan和coding都有很大的提升，尤其是调用链路比较长的

15

就是这个，应该之前有公益的

16

感谢佬 很有价值 这个方向看的人看来也很多 :heart:

17

Plan 阶段 获取合适的项目上下文，可以省token的同时设计不遗漏，code阶段，项目上下文可以让模型代码不会写一半，review阶段对于长链调用也会方便审查。这类上下文获取又快又精准现在看很有价值

1 个赞
18

感觉这个思路和fast-context很像啊，也是用小模型来检索代码库，不过fast-context直接给出查询建议

1 个赞
19

佬，我们这个项目是在初始化时会把所有知识库的模块都用agent总结一遍吗？为什么不动态调用呢？比如用到前十个时就用字agent去总结，不用就不动。

20

佬，我这不知道算不算个小建议还是小抱怨
我是金融行业的，工作上会用到技术所以懂点技术，但和各位职业程序员没法比
在我的这个背景下，我看完你项目的解释，我真的是一头雾水，完全不知道是用来干嘛的
我这还是有点技术背景的，如果非技术背景的纯普通用户是不是更加看不懂啊？
还是普通用户完全没必要用你的项目？
要不项目介绍里加个简单的使用例子来说明是否会更好点？

当然，不排除单纯的是我菜 :rofl:

21

佬，有跟mgrep类的工具对比过吗？最近刚好在研究mgrep，grepai什么的