PocketFlow的作者基于PocketFlow做了一个用来给Codebase生成文档的项目，算是简化版本的DeepWiki，这里介绍一下基本思路
核心代码就在nodes.py中
看deepwiki的流程图，这里的node都是串行执行的：
- IdentifyAbstractions 是把整个codebase丢给LLM，给的格式是文件目录，文件内容的tuple
- 输出若干个abstraction，对应的解释，以及相关的文件索引
- 输出格式是YAML
- 为了避免模型输出文件路径出问题，这里是让他输出文件路径对应的index，提高推理的精度
- 这里作者用的主要是 gemini2.5，依赖了gemini的强大的上下文
- AnalyzeRelationships
- 输入abstraction，输出这些abstraction的关联。这里是把abstraction，以及对应的文件内容输入到了LLM中
- 这里还会根据这些abstraction的关系，生成一个project的high level summary，也是YAML输出
- 例子
- OrderChapters
- 用来对这些abstraction做order，目的是提高tutorial的易读性，比如先介绍xxx，后介绍xxx
- 这里只用abstraction的描述以及上面提取出来的关系作为模型输入了，没有把原始文件内容放进去
- WriteChapters
- 根据chapter order，对每一个abstraction做详细的解释
- 输入会包含当前chapter的abstraction对应的代码文件内容，以及前面总结的chapter的summary
- 这里有一些挺不错的prompt
- 比如先描述这个abstraction的high level motivation
- 如果不是第一章，来一个从上一章承上启下的句子
- 解释的时候使用例子，必要的时候用mermaid画图
- 并且还有很多口语化的解释，是一个挺不错的prompt，解释文章很不错
- CombineTutorial
- 这里会把前面生成的数据整理起来，写到md的文件中
- 分析关系那一步给的项目总结，以及核心模块调用关系会写到index.md中，同时还会生成对其他章节的超链接，方便跳转
- 剩下的每一个abstraction单独占用一章，描述具体的内容
总的来说，比较依赖模型长上下文的能力，来为codebase生成核心概念，然后单独解释。生成文章的prompt也比较不错。
这里有一个值得思考的点就是，在做codebase understanding的时候，是自顶向下，还是自底向上。直接生成abstraction的效果在一些小的项目确实不错，但是过大的codebase就比较依赖模型能力了。
* 不过其实看deepwiki可能也是类似的做法，就是分模块单独解释。但是模块划分就不确定是怎么做的了。
* 还有一个思路是根据代码的模块进行组织，而不是让模型去找核心概念。因为人在写代码的时候基本都是按照模块来划分目录的。
然后这里直接用文件的方式比较粗暴，好处是不需要考虑AST了，坏处就是不确定这种会浪费多少的上下文，以及就算是用AST来解析，使用的时候其实也不太确定怎么用的好。
* 之前一个想法是组织了AST之后，按照类似DAG的方式，递归的向上做总结。
* 然后大的模块划分，可能是通过相同目录下，或者是利用调用关系图上的聚类算法来构造。
文章评论