The Boy Scouts hava a rule:「Always leave the campground cleaner than you found it.」
童子军军规:「始终保持露营地比你发现它时更干净。」
写 README 是软件开发行业的最佳实践，如果没有的话，就立即建立一个，以此持续改善项目库的软件环境。
这里很容易碰到一个问题------大模型上下文限制没法一次性对整个项目库代码有所了解，只能提取特征分析。因此第一次自动生成的 README 都像一个通用也无甚实际用处的东西。这里补充两点：
- 即使第一次生成的 README 无法概括项目全貌，依然是有必要的，按照童子军军规不断完善就能彰显工程价值
- 有针对性的提问可以得到有针对性的回答，更快掌握项目到可维护程度是至关重要的
1、从模块入手生成 ASCII 图表
直接让大模型分析所有类不切实际耗费时间，那就先从模块入手，范围缩小 README 会更准确，图表更易表达。推荐使用 ASCII 图表，不需要插件就能阅读。
比如向 Junie 提问：
markdown
分析代码库中各 module，构建模块之间的架构依赖关系图，生成 ASCII 图表，并将其添加到 README.md 文件中从 Junie 的执行计划可以看出，它只分析了各模块的 pom 文件，通过依赖关系生成了图表。这在多模块项目中用处比较大，代码继承者可以很快了解各模块的职责。
2、根据最近提交记录生成 changelog
然后，分析代码可以从代码提交记录入手，从提交历史可以看出最近改动功能有哪些，因为最近改动的功能很有可能还会再次改动。
这里也会碰到一个类似 README 的问题，就是从 commit message 无法看出提交的代码具体是做什么的。这就需要 Junie 分析每一个提交关联的代码行，最后再总结出一个提交记录结果。
比如向 Junie 提问：
markdown
分析最近的 10 次提交，阅读相关文件，了解其对用户场景的影响，生成简短扼要的摘要和 ASCII 图表（使其内容生动有趣，并可使用表情符号和图片），生成 changelog.txt 文件（或添加到 README.md 文件中）因为没有开启 Junie 的 Brave Mode（暂不建议开启），因此一些命令执行需要使用者确认。这里就是将自然语言转换成了 Git Command。
最后就得到了一份 changelog，大致能了解到这是最近做了多租户的功能改造。
3、生成代码测试覆盖率报告
遗留系统的一个重要特征就是没有单元测试，从代码测试覆盖率也可以看出代码的工程质量。
比如向 Junie 提问：
markdown
以文本文件形式提供代码覆盖率报告，如果覆盖率低于 1%，则添加控制器层（controller）测试以达到目标覆盖率这里用于演示直接取极端测试覆盖率值 1%，并优先覆盖控制器层代码，当然如果代码量很大并且没有约定好测试策略，先不要求补充测试。
这个代码测试覆盖率只能说提升空间还很大，毕竟写测试的难度不亚于实现功能的难度。
从 Junie 的执行过程可见，它找到了所有 controller 所在位置并比较是否有相应的测试生成，没有的话就去创建测试或修复测试，最后运行测试保证全部通过，再给出代码修复建议以及待添加到 Git 的类文件。
4、重建 README 的思路
重建 README 的过程也是一个规范软件工程的过程，这里重点选取了 README.md 文件、commit message、测试覆盖率三者作为代码工程质量标准，不仅是代码维护的重要参考指标同时也是大模型辅助编程的重点关注对象。
- 没有 README 就要向大模型重新介绍业务领域与项目知识，代码背景的缺失容易激发大模型幻觉
- commit message 代表代码提交是否功能相对完备、职责够清晰，太复杂没法对历史提交记录分析并生成有效改进建议，同时也没法基于细粒度功能做 cherry-pick
- 没有测试覆盖就无法确保代码修改的可靠性，也没法让大模型创造可量化的代码生成条件
所以，大模型辅助编程的质量仍然取决于工程质量。工程不可能一蹴而就，有了大模型依然需要不断迭代，就像童子军军规一样，至少不能比之前变得更差，重建 README 就是一个好的开端。