规则扫描配合本地AI处理代码杂务

Sleepy Coder 把 AI 编程助手的目标缩小了：找出项目里积压的小问题，告诉你改哪里、怎么改，再检查有没有改好。作者试过让本地模型自动修复，最终却把手动编辑放回了流程。

这个转向值得看。它用 Gemma 3 4B 做了一次具体实验：小模型能解释问题，却未必能稳定修改文件。对维护个人项目的前端开发者来说，先找到一种可靠的协作方式，可能比追求全自动更实用。

为什么先用规则找问题，再让模型解释

Sleepy Coder 面向的是容易忘、改起来通常不复杂的杂事：重复的 <h1>、缺少 alt 的图片、遗留的 console.log，以及几周前写下的 TODO。

它先扫描本地目录，用规则检查三类问题：

• SEO：页面出现重复的 <h1>，缺少 <title> 或 <meta name="description">。
• 可访问性：图片没有 alt，链接没有可读文本，<html> 没有 lang。
• 项目维护：TODO / FIXME / HACK 注释、调试输出，以及缺少 README、LICENSE 或测试。

这些任务不需要先问模型。规则读取文件，给出文件名和行号；Gemma 接手的是解释工作。它收到问题附近带行号的代码，以及规则附带的提示，再返回包含说明、步骤和建议代码的结构化 JSON。作者会校验模型返回的内容，但没有展开校验标准。

规则负责提供可核对的位置，模型负责把修复方法讲清楚。

作者给出的实际案例来自自己的 CSS 背景图库，一个 Astro 站点。扫描发现首页有两个 <h1>：一个在 hero 区域，另一个藏在用于预览背景的模拟网站弹窗里。规则沿着 Astro 页面导入关系找到了组件，工具还提示保留 hero 中的标题。

这比逐文件搜索多走了一步：它尝试把页面和组件联系起来。不过，原文没有说明这套追踪能处理多复杂的动态渲染，也没有给出 React、Vue 等项目的同等案例。

为什么自动修复通过了安全检查，还是被关掉了

作者最初想做的是：用户批准任务后，agent 在独立分支里自动修改。

保护措施并不少。它使用隔离的 git worktree，在 sleepy/… 分支工作；用沙箱限制可修改范围，保护指定文件；修改前后运行用户提供的测试脚本，提交前再检查问题是否消失。

作者报告，这套保护没有让修改破坏项目。但 Gemma 3 4B 在笔记本上的编辑表现反复失败：要求补 alt，它却重新格式化文件；要求重写文件，它删掉了一半；改用小范围搜索替换，它又引用了文件里根本不存在的代码。

检查能拦住错误，却不能替模型完成正确修改。结果是安全地反复失败。

于是流程变成：Find tasks 找任务，How to fix 展示准确行号、Open in VS Code 按钮和修复说明，用户自己编辑，再点「I fixed it — check again」。同一条规则重新运行，问题消失后任务进入 Done。自动 agent 仍作为面向更大模型的实验选项保留，默认关闭。

能解释一个修改，不等于能可靠地执行这个修改。

这正是作者从实验中得到的边界。它针对的是这次模型、设备和任务组合，不能直接推广成所有小模型都无法编辑代码。

本地运行解决了什么，又没解决什么

Sleepy Coder 默认通过 Ollama 运行开放权重模型 Gemma 3 4B，任务建议和修复指南都由它生成。下载模型后可以离线使用，不需要云端 API key，也没有按请求计费的 API 账单。

技术栈也很明确：仪表盘使用 Astro、React islands 和普通 CSS；Fastify 提供仅监听 127.0.0.1 的小型 API；用 Node 内置的 node:sqlite 保存仓库、任务和指南；测试使用 Vitest，代码组织在 pnpm monorepo 中。

模型可以替换。按作者描述，工具可以使用 Ollama 中已有的其他模型，也能通过 SLEEPY_MODEL=… 指定。原文没有提供具体切换示例、Node 版本要求、内存占用或运行速度。

本地运行对扫描未公开仓库很有吸引力，但不会自动消除幻觉。作者就遇到过 Gemma 声称所有 SEO description 都是空字符串，实际并非如此。

为此，规则看不到的建议会标成「AI idea · verify it」。生成指南前，模型还要读取真实文件，判断问题是否存在；它可以回答「this does not apply」，随后工具提供丢弃任务的入口。

这是有用的纠错出口，但仍是模型复核自己的判断。它与重新运行一条确定规则，证据强度不同。

我的判断

我认可的是这套职责分配：用可重复执行的检查发现问题，让模型降低理解成本，再把编辑交给用户。尤其是修改很小、解释比实施更费心的任务，这种流程有实际价值。

但作者把规则描述为可靠、位置总是正确，需要拆开看。行号准确，不代表问题判断一定成立。TODO 可能是有效记录，缺少 LICENSE 可能出于项目用途；重复 <h1> 也需要结合页面结构和语义判断。原文展示了一个 Astro 案例，没有提供扫描规模、误报率或对照结果。

与 ESLint、可访问性 lint 规则、静态检查脚本相比，Sleepy Coder 的特点更接近把任务定位、解释和复查集中到一个界面里。作者没有证明它检测得更多或更准，因此这里应当把它看作产品设计经验，而不是工具效果的比较结论。

「运行不花钱」也应理解为没有付费 API 请求费用。本地设备、存储和推理仍有成本。至于更大模型能否让实验 agent 变得实用，原文没有测试结果，暂时只能保留这个问号。

能拿来做什么

• 维护 Astro 个人站点时，可以参考它的检查顺序，先排查标题、description、图片替代文本和调试残留，再逐项确认用途，避免看到提示就直接删除。
• 给现有 lint 或扫描脚本加 AI 说明时，可以把准确文件、行号、附近代码和规则提示一起传给模型，要求返回结构化 JSON，并校验返回内容。
• 使用本地小模型辅助编程时，可以先让它解释修改方案，由自己编辑，再运行原有规则验证结果；不要仅凭解释流畅就授予自动修改权限。
• 设计 AI 任务面板时，可以区分规则命中的任务与待验证的模型建议，并允许模型承认建议不适用，让误报有明确的退出路径。