当集成从可管理变成真正的问题时<p>是系统数量、边缘案例、团队规模，还是其他因素？<p>发生了什么变化？
返回首页
最新
Cloudflare非常慷慨，几乎提供了所有服务——包括Workers、D1、CDN、KV、持久对象、Workers AI、兼容S3的存储（R2）等更多功能！
我对改进代码审查很感兴趣，因为目前的审查效果仍然很差，因此我正在研究一个可以附加到本地大型语言模型（LLMs）/ API 调用的分类层，以便进行更好的代码审查。
大多数审查工具只是将拉取请求（PR）的差异直接输入到模型中，希望它能找到错误。模型看到的是添加/删除的行、代码块头和上下文行，但它并不知道它正在查看的函数是由其他 x 个函数在 y 个文件中调用的，或者这里的类型变化会破坏三层目录之外的接口。
分类层使用树解析器将源代码解析为抽象语法树（AST），提取出语义上有意义的实体（函数、类、方法、结构体），并构建跨文件的依赖图。它根据传递的影响范围对每个更改的实体进行排名，减少了 80-90% 的审查范围，并显著提高了对错误的关注度。虽然我相信它在某些情况下可能会出现分布外的问题，但对于快速的代码审查，这种权衡是值得的。
一旦你将问题缩小到“这是这个 PR 中 n 个风险最大的实体”，你就不再需要一个前沿模型。你需要的是一个只了解你代码的模型。一个在你的代码库上进行微调的 7B 模型了解你的模式、你的约定和你常见的错误。结构性分类处理了全局推理，使得你的模型能够很好地进行判断。
命令：
- inspect diff - 实体级别的差异，带有风险评分和影响范围
- inspect predict - 显示哪些未更改的实体有可能会导致问题
- inspect review - 结构性分类 + LLM 审查
- inspect pr - 审查 GitHub PR
支持 21 种语言解析器。使用 Rust 编写。开源。
GitHub: https://github.com/Ataraxy-Labs/inspect
我们通过解锁云端未使用的计算资源，使OpenClaw的成本降至原来的1/10，打造出适合自主推理的架构。我们无缝整合了云端未使用的虚拟机和硬件用于推理。如果您希望提前体验OpenClaw在未使用的云计算资源上的应用，请联系我们：hello@openinfer.io。