最新

当集成从可控变为真正的问题<p>是系统数量、边缘情况、团队规模，还是其他因素？<p>发生了什么变化？

Cloudflare 真是慷慨，几乎提供了所有东西——Workers、D1、CDN、KV、Durable Objects、Workers AI、S3 兼容存储（R2）等等！

我一直对改进代码审查很感兴趣，因为它们目前的效果仍然不尽如人意。因此，我开始研究一个可以附加到本地 LLM/API 调用的分诊层，以实现更好的代码审查。 大多数审查工具会将 PR 差异转储到模型中，并希望它能找到错误。模型会看到新增/删除的行、代码块头、上下文行。但它并不知道它正在查看的函数被其他 x 个文件中的 y 个函数调用，或者这里的一个类型更改会破坏三个目录之外的接口。 这个分诊层使用 tree-sitter 将源代码解析成 AST，提取语义上有意义的实体（函数、类、方法、结构体），并构建一个跨文件的依赖关系图。它根据传递性影响范围对每个更改的实体进行排名。它将审查范围缩减了 80-90%，并显著提高了对错误的关注度。现在我确信它可能会出现几次超出分布的情况，但为了快速的代码审查，这种权衡是值得的。 一旦你将问题缩小到“这是这个 PR 中风险最高的 n 个实体”，你就不再需要一个前沿模型。你需要一个只了解你代码的模型。一个在你的代码库上微调的 70 亿参数模型了解你的模式、约定和常见错误。结构化分诊处理全局推理，这使得你的模型能够很好地处理判断。 命令： - inspect diff - 实体级别的差异，带有风险评分和影响范围 - inspect predict - 显示哪些未更改的实体有损坏风险 - inspect review - 结构化分诊 + LLM 审查 - inspect pr - 审查一个 GitHub PR 21 种语言解析器。使用 Rust 编写。开源。 Github: https://github.com/Ataraxy-Labs/inspect