本帖使用社区开源推广，符合推广要求。我申明并遵循社区要求的以下内容： 我的帖子已经打上 开源推广 标签： 是 我的开源项目完整开源，无未开源部分： 是 我的开源项目已链接认可 LINUX DO 社区： 是 我帖子内的项目介绍，AI生成、润色内容部分已截图发出： 是 以上选择我承诺是永久有效的，接受社区和佬友监督： 是 以下为项目介绍正文内容，AI生成、润色内容已使用截图方式发出 引： 我申请Jev通过了，于是进行了一些它在开发场景下的应用尝试。希望和大家分享一下。我觉得思路分享可能比单纯的项目分享要更有价值，所以文章写了自己的思路，稍微有些长，还请谅解。 Jev的能力边界是什么 我最开始尝试将 Jev 用于代码文件找 bug，我的想法很简单，它的速度非常 快 ，而且也便宜。只要在准确率 勉强够用 的情况下，做一个快速判断给模型，那么用它来找 bug 就是有意义的。 于是，一开始我开发了这样的一个工具： 它的作用是扫描项目下的文件，并给出各个方向 Bug 的可能性的判断。 但是效果非常差，不管如何优化提示词和细分 bug 它无法理解代码逻辑，它给出的这些概率值完全和代码模式本身正相关，而和它们包不包含 bug 关联性很低，尽管在提示词里已经做了非常明显的说明了。 而作为对照的正常的文本生成模型，对这些结构进行抽样检查，能轻而易举地得出结论：这些文件本身并没有什么 bug。 因此，我认为它只能去做一些简单的模式识别和判断 尽管网络上对这个模型有一些智力水平的测试，但那些测试我并不认为和我测出的这个能力边界冲突。他有一定的智力水平，但他显然无法理解代码结构的细节。 Jev 要如何应用于开发？ 我在思考这个问题的时候，想到了我自己的 AGENTS.md ，这是我对于我的一个项目的真实 AGENTS.md 的文本片段: 所有的 .vue 文件中的 CSS 代码必须拆成同目录下的同名 CSS 文件。Vue 文件里面原则上不得携带 CSS 代码。 CSS 中所有的颜色等数值必须拆分为 CSS 变量，放在项目级或者组件级 CSS 文件中。不得硬编码，如果需要硬编码，必须向用户说明，并且征得许可。 所有的 SVG 图标必须拆分。具体拆分方式是建立一个专门的 icons 文件夹。文件夹里面一个 SVG对应一个 vue 文件。其他文件通过引用该 .vue 文件导入 SVG。没有特殊理由，不得在其他页面文件或者组件文件里面自行编写 SVG。 每个文件在其顶部必须有注明文件用途的注释 每个函数必须有函数注释：对于小函数，单行注释即可；对于大函数，则需要规范的多行函数注释。 Commit 格式为：type(scope): subject. 其中 subject 必须为中文.Type 和 Scope 必须为英文.Commit的详细信息也必须用中文. 这些规则都是简单的模式识别规则。只要去识别内容中包含或者不包含某些元素即可。 所以我想，Jev 或许可以对 AGENTS.md 进行一次迭代 于是我第二个版本的工具就诞生了。它只有三个功能 1. codesafe diff : 检查项目内的改动文件是否符合规则 这个工具支持通过 YAML 注册规则。包括规则描述、规则是与否的判断逻辑等。 对于规则： 所有的 .vue 文件中的 CSS 代码必须拆成同目录下的同名 CSS 文件。Vue 文件里面原则上不得携带 CSS 代码。 示例如下： rules: - id: vue-css-split level: error files: "*.vue" text: .vue files must not contain <style> blocks; CSS goes to a sibling .css file pass: all .vue styles live in external .css files fail: a .vue file still contains an inline <style> block 运行 codesafe diff ，会自动对当前项目的 Git 改动检查所有规则，并给出通过、不通过的结论。如果不通过，会给出违反的规则。 2. code commit -m "xxx" : 检查提交信息与提交本身并自动应用建议的提交前缀 运行 code commit -m "xxx" ，首先会根据提交规则去识别提交信息是否通过。 对于规则： Commit 格式为：type(scope): subject. 其中 subject 必须主要为中文（专业名词可用英文，下同）.Type 和 Scope 必须为英文.Commit的详细信息也必须主要为中文. 示例如下： commit_rules: - id: subject-zh on: subject text: the subject must be in Chinese (technical terms may stay English) pass: the subject is primarily Chinese fail: the subject is not Chinese 除了设定规则描述等，还可以设定这个规则应用在哪一部分：是应用在前缀(prefix)，还是应用在提交信息本身(subject)。 如果不满足某个规则，那么命令会中断，并给出违反的规则。 然后它会去识别暂存区待提交的内容 它会判断暂存区待提交的内容是否满足规则，这一步和 codesafe diff 基本上是相同的 最后它会自动生成提交信息的前缀，并且应用提交 它会在上一步判断规则的同时，去判断 type 用什么、scope 用什么。然后自动给出前缀。 比方说，它根据内容判断出来，这是一次 重构 ，范围是项目的 前端 ，那么: code commit -m "添加页面A" 相当于执行 git commit -m "refactor(frontend): 添加页面A" 3. codesafe delete : 更安全的删除 运行 codesafe delete [<文件夹|文件>,] 时，程序会自动把文件夹数和文件名，以及当前项目的绝对路径发给 Jev，让其判断三个结果： 可以安全删除 需要敏感删除 危险，中断 如果判断为可以安全删除，那么命令会直接删除文件夹或者文件。 如果判断为需要敏感删除，那么命令会用移动到 /tmp/deleted 的方式来代替删除。 如果判断为危险，则会直接中断。 示例： 虽然我有自信，但是执行这个命令的时候还是有点心惊 不过，这足以证明它相对于模型直接操作删除的安全性 最后附上我的项目地址 LingyeNBird/codesafe: Fast per-file safety/bug triage via TypeSafe System One API 关于规则的共创想法 我在想，Jev 的快速判断使得它极其适合 AGENTS.md 文档的规则化。那么，我是否可以开一个规则仓库，通过佬友们提交 issues 或者在 L 站评论，然后在 L 站定期投票来筛选出好的规则，作为此项目的内置规则，以实现良好的 AI 输出？ 也希望佬友们分享将 Jev 应用于开发的一些想法和看法。鄙人愚见，还请多多指教。 1 个帖子 - 1 位参与者 阅读完整话题

  • 情报分类：开源项目与落地
  • 分类依据：内容涉及项目实践、创业、副业或变现
  • 信息来源：服务器 / LINUX DO - 最新话题
  • 发布时间：2026/9/21 10:07:25