文档破破烂烂,opus缝缝补补
- 内容介绍
- 文章标签
- 相关推荐
最近在造轮子的过程中经常需要参考和调用一些第三方库。然而一些库的文档经常不够完善,要么是只讲了一些基本的用法,一些功能更丰富的 API 藏在几层链接后的某个角落里,要么是直接没有文档,甚至没有代码注释。
于是被迫让agent自己去读整个库的源码,捋清楚每个函数的功能和用法,最后再生成一份给人读的文档和 API Reference。
最开始用的是各位大佬的公益站,猛猛蹬 opus 4.6(其实是读代码是 haiku)。虽然扫描源码花了大量的 token,但是相应的产出质量是非常高的。文档内容完善、结构清晰,还会恰如其分地包含一些使用示例,极大地提升了开发效率。
然而最近公益站的服务不太稳定,时不时就访问不了。于是我又尝试了一下 codex,结果发现质量参差不齐,有些工具生成的文档内容非常简略,语言表达也不够流畅。和 opus 4.6 生成的文档相比,落差大到有些不适应。
这里放一个例子,这是 5.3 codex 生成的文档片段:
图片1249×10625 855 KB
其实效果也还可以了,列出了很多文档没有讲过的接口,也能节省我很多时间。
但是在细读的过程中,codex 没有按照从简单到复杂的逻辑顺序组织,经常会给出当前还没有定义过的内容,硬着头皮读到后面才发现 codex 没有漏说明。但也因此读起来磕磕绊绊的。
一怒之下,还是回到 opus 4.6,用同样的 prompt 再生成一个文档:
图片1260×18787 1.82 MB
突然一下那种把饭喂到嘴里的感觉又回来了。所有概念都是先定义后使用,并且是循序渐进揭露 API 的进阶参数的。不存在看 API 文档那种瞬间被大量概念和参数轰炸的感觉,读起来非常顺畅。
总之,opus 在我心理绝对是无可替代独一档的存在。
最近在造轮子的过程中经常需要参考和调用一些第三方库。然而一些库的文档经常不够完善,要么是只讲了一些基本的用法,一些功能更丰富的 API 藏在几层链接后的某个角落里,要么是直接没有文档,甚至没有代码注释。
于是被迫让agent自己去读整个库的源码,捋清楚每个函数的功能和用法,最后再生成一份给人读的文档和 API Reference。
最开始用的是各位大佬的公益站,猛猛蹬 opus 4.6(其实是读代码是 haiku)。虽然扫描源码花了大量的 token,但是相应的产出质量是非常高的。文档内容完善、结构清晰,还会恰如其分地包含一些使用示例,极大地提升了开发效率。
然而最近公益站的服务不太稳定,时不时就访问不了。于是我又尝试了一下 codex,结果发现质量参差不齐,有些工具生成的文档内容非常简略,语言表达也不够流畅。和 opus 4.6 生成的文档相比,落差大到有些不适应。
这里放一个例子,这是 5.3 codex 生成的文档片段:
图片1249×10625 855 KB
其实效果也还可以了,列出了很多文档没有讲过的接口,也能节省我很多时间。
但是在细读的过程中,codex 没有按照从简单到复杂的逻辑顺序组织,经常会给出当前还没有定义过的内容,硬着头皮读到后面才发现 codex 没有漏说明。但也因此读起来磕磕绊绊的。
一怒之下,还是回到 opus 4.6,用同样的 prompt 再生成一个文档:
图片1260×18787 1.82 MB
突然一下那种把饭喂到嘴里的感觉又回来了。所有概念都是先定义后使用,并且是循序渐进揭露 API 的进阶参数的。不存在看 API 文档那种瞬间被大量概念和参数轰炸的感觉,读起来非常顺畅。
总之,opus 在我心理绝对是无可替代独一档的存在。

