一个叫 SlothOps 的项目，把"慢"写进了设计原则里。它想做的事很具体：检查代码仓库，把日常维护工作变成一份简短、可执行的报告。
过去你要手动翻 TODO、看测试输出、回忆上次改了什么。SlothOps 的设想是把这些信号收拢到一处，不用再靠脑子记。
第一版计划做几件实事：
- 找出 TODO 和 FIXME 注释
- 读取 Git 状态和最近的提交历史
- 运行用户批准的测试命令，并汇总输出
- 标出可能的维护任务，给出下一步建议
- 生成一份简洁的项目健康报告
它的目标不是让 AI 未经审查就改动代码，而是把重复的检查工作变轻，控制权仍然留在开发者手里。
检查归检查，推理归推理
这个项目最关键的设计选择，是把仓库检查和语言模型推理分开。一套可行的实现是：用 Ollama 在本地跑开源权重模型，用 Git 查看仓库状态和近期提交，用一个小型 Python 服务扫描文件、收集测试输出、拼装结构化报告，前端用 Next.js 做仪表盘和报告视图。
扫描器只收集有限且明确的一组信息，而不是把整个仓库塞进提示词。确定性的检查——比如找 TODO 注释、收集测试退出码——就该保持确定性。模型负责的是解释结果、把相关发现归组、给出合理的工作顺序。
安全上，第一版默认只读。要执行测试的命令会先展示给用户，任何代码修改建议都以 diff 形式呈现供审查，而不是自动应用。
还有一条小而重要的原则：模型不该被当成"测试是否通过""TODO 是否存在"的事实来源。这些事实来自工具。模型的工作是让收集到的证据更容易理解。这种分离让输出更可审计，也给项目提供了一种评估自身质量的办法。
本地优先，意味着什么
对开发者工具来说，源码和仓库历史都可能是敏感信息。本地优先的设计，让用户可以在不把上下文自动上传给第三方 AI 服务的前提下检查自己的项目。
开源权重模型还给了开发者几个实在的选择：
- 隐私：完整工作流配置在本地时，仓库内容可以留在用户机器上
- 选择：可以尝试不同的兼容模型，而不是被绑在单一推理服务商上
- 控制：提示词、检查项、报告格式都能查看和修改
- 成本控制：本地推理避开按请求计费的 API 账单，但仍然消耗电脑硬件和电力
- 离线潜力：模型和依赖装好之后，核心检查和兼容的本地推理可以断网运行
这些好处取决于实际实现。光有一个网页界面，并不能让产品变得本地或私密；任何可选的远程集成都应该明确披露。对 SlothOps 来说，开放创新不是 README 上的一个标签，而是开发者能查看工作流、选择模型、掌控自己的代码。
省下的时间，要拿数据说话
预期的回报很简单：少花点时间反复检查同样的地方。但作者没有编一个"节省多少时间"的数字，而是打算用一次小型的前后对比来测量：选一个已知 TODO、测试结果和近期变更的样本仓库，记录人工收集并汇总这些事实要多久，再用 SlothOps 跑同一个仓库，比较耗时、遗漏的发现和错误的建议，最后把结果连同失败和局限一起公开。
有用的工具应该省时间，同时不藏起重要细节。报告里的每条发现，都应尽可能链接回对应的文件、测试输出或提交。
下一步是把第一版做扎实：一小组确定性检查、本地模型推理、每条发现背后清晰的证据，以及一份开发者能快速行动的报告。作者的态度很明确——宁可要一个透明可用的窄工具，也不要一个承诺修好一切的自主智能体。
热门跟贴