每个项目都有一堆重要但不紧急的活儿。对 Wanaku 来说，这堆活儿是测试计划。

打开网易新闻 查看精彩图片

团队用 Markdown 写了数百个测试单元：建命名空间、部署 operator、调用 CLI、检查输出。人能照着做，但没人愿意每天晚上都照着做一遍。

于是他换了个做法：把想要的东西写下来，交给编码智能体，自己只保留评审和产品负责人的角色。六天后，Midnight Saci 诞生了——一个 AI 测试工程师，能对着真实环境执行 Markdown 测试计划，并为每一个判定给出证据。

名字取自巴西民间传说中的 Saci-Pererê，一个爱藏东西、打结、制造小混乱的捣蛋鬼。这个 Saci 把捣蛋用在正道上：替你找 bug。

它做什么，以及它不做什么

你像给同事写测试计划那样写：阶段、测试、命令、预期结果。Saci 一步步执行，由大模型决定做什么，一组小而受限的工具（shell、HTTP、MCP）负责动手。每次运行都有独立的隔离 worker，可以是 Podman 或 Docker 容器，也可以是 Kubernetes Job。凭据会从证据中抹去。任何兼容 OpenAI 的模型都能用，从 OpenRouter 到本地 Ollama。

关键在它不做什么：它照着计划走，不自行发明修复步骤，也不改你的代码。每个判定都把预期结果和支撑或反驳它的命令输出绑在一起，比如某条预期被标为“机械判定、证据 ev-2：输出以 status 500 结尾，而不是 201”。你审查的是推理过程，不是盲信结论。

一次运行里能看到什么

Web 控制台实时展示运行过程。在一次针对真实 Wanaku 实例的 MCP CLI 测试计划中，共 29 个单元。活动标签页是实时日志，每条 shell 命令都链接到它的证据，每次尝试都报告用了多少次模型请求和多少 token。

“计划性能”标签页回答了他最初几天最常问的问题：时间花在哪了？那次运行里，模型占了 97% 的时间，工具只占 2%。该优化哪里，一目了然，反正不是 shell。环境标签页则记录 worker 镜像、操作系统、worker 内的工具，以及确切的 Saci 构建版本——上周二那次运行为什么失败，能查到它跑在什么上面。

跑完之后的三件事

  • 结果动作：运行结束后，后端可以调用 MCP 工具开工单、发消息、发邮件。动作可以等人批准，但永远不会改变判定。
  • 调查：某个单元失败时，Saci 可以启动第二个智能体，克隆源码、阅读服务该步骤的代码，最后给出引用文件和行号的假设。它可以提 bug，也可以说明为什么不提。其他智能体还能通过 A2A 请求调查，让 Saci 嵌入更大的智能体体系。
  • 脚本运行器：saci-script-runner 把管理员定义的脚本暴露为 MCP 工具，Saci worker、Wanaku 或任何 MCP 客户端都能调用。第一个例子就是用一段普通 bash 脚本把运行结果发邮件。

和你的编码智能体配合

Wanaku 已有的数百个测试单元格式并不符合 Saci 的预期，多数把期望写在 echo "PASS ..." 里，而不是独立的预期结果段落。把这种内容转成判定标准需要判断力，纯规则转换器只能靠猜。所以转换被做成了编码智能体的技能，外加一个校验器：智能体负责转换，saci check 离线告诉它还差什么。其他技能可以启动后端、运行计划、调查失败。Saci 由智能体构建，也被设计成由智能体驱动。

一次没成功的小模型实验

测试计划里大多数步骤很简单：命令是否以 0 退出，输出里有没有这一行。每一步都问前沿模型又慢又贵。Saci 可以启用“系统一”裁判，用一个小而快的决策模型放行显而易见的步骤，其余的交回大模型。

他们试了 Julia 1，一个开源模型，由一个小型 Rust 模块通过 ONNX Runtime 提供服务。坦白说：在真实的 Wanaku 运行中它很少足够自信，几乎每一步还是由大模型判定。管道已经搭好，微调是下一个实验。把这个写出来，是因为不是每个想法第一次就能成，这没关系。

它是怎么被造出来的

仓库始于 2026 年 10 月 17 日。到 10 月 23 日，它已有约 4 万行 Rust，横跨八个 crate，外加一个 React Web 控制台、一份 OpenAPI 契约、Helm chart、多架构容器镜像，以及 130 个 issue 和 pull request。这些代码不是他写的，是编码智能体（Claude Code，跑在云端会话里）写的。他的工作是另一套，而下面这些让这套工作跑通了。

  1. 先写计划。写任何代码之前，先写系统计划：目标、原则（简单、可信、可适应）、技术基线和系统形态。智能体把它拆成工单，每个改动都能追溯到某个 issue。
  2. 把规则写下来。一个 CLAUDE.md 文件存放常驻规则：生产代码不许 unwrap 或 panic，工具不许用 Python 或 Perl，每个主要功能都要有有意义的测试，文档用简化技术英语，第二次真实使用之前不做抽象。智能体很会遵守写下来的规则，但它们不会读心。
  3. 让 CI 当裁判。make check 跑格式检查、把警告当错误的 Clippy，以及完整测试套件。智能体在他看 PR 之前先自己修好 CI 失败。他的评审关注设计，不关注 lint。
  4. 同时开多条线。每块工作有自己的智能体线程：调查设计、Julia 1 裁判、脚本运行器、控制台页面。它们并行推进，开出 PR 由他评审合并。
  5. 用产品测产品。Saci 有自己的测试计划，而且它真的在跑。
  6. 守住产品负责人。智能体问的问题很好：计划转换该做成 CLI 还是技能？裁判该跑在 worker 里还是独立服务？这些决定是他的，它们对项目的影响比任何一行代码都大。

接下来

Saci 是个新项目，这一点看得出来。有些地方还很粗糙，Julia 1 裁判需要继续打磨。但它已经在跑真实的 Wanaku 测试计划，已经在替他省时间。

更重要的是，它展示了现在能做到什么：一个人，带着清晰的计划、写下来的规则和靠谱的 CI，可以在一周内建出一个真实系统。真正重要的技能不是敲代码，而是知道自己要什么，并把它说清楚。

代码在 Midnight 的 Saci GitHub 仓库上。演示流程全部跑在一台机器上，用脚本化的模型，不需要 API key 就能试。