SEVO

🌐 官网

已注册项目：exam-sprint

SEVO 是一个 Spec-to-Runtime Evidence Pipeline。

它解决的不是“代码怎么更快生成”，而是另一件更难的事：
需求写完了，代码跑起来了，谁来证明结果真的符合需求。

很多 AI Coding 流程停在 prompt loop。 模型说写完了。 日志说通过了。 提交也合进去了。 但用户真正关心的是：功能有没有跑通，验收条件有没有被满足，失败后谁负责追回证据。

SEVO 把这件事拉回 engineering loop。 每个阶段都要落状态。 每次推进都要过 gate。 每个“完成”都要附运行证据。

它在做什么

SEVO 围绕一条主线工作：

1. 从 spec 读取 FR / AC
2. 把研发过程组织成可推进、可阻塞、可修复、可追溯的状态机
3. 运行真实 CLI / Web / Library / Hook / Plugin 检查
4. 用结构化规则和 LLM 判断运行输出有没有真正满足验收条件
5. 把证据、事件、结论都留下来

最终得到的不是一句“任务完成”，而是一串可复查的运行事实。

核心设计原则

原则 1：任意入口全自动走到终局

从任何入口进入 SEVO，都要自动推进到最终验收，不需要人每一步盯着催。无论用户从 create、implement、review、fix 还是 from 入口进入，系统都要判断哪些前置阶段已经满足、哪些后续阶段还没完成，并持续推进到 implement、review、smoke、regression、deploy、verify、readme、publish 等终局链路全部有结论。Why：如果入口只处理眼前一步，Agent 很容易“修完就停”或“审完就停”，用户看到的是局部完成，实际交付没有闭环。

原则 2：任意入口先核实 Spec

从任何入口开始，第一步都先确认 Spec 存在，而且已经覆盖当前任务的 FR、AC、边界和用户视角验收。Spec 覆盖足够，才进入 Contract、Implement、Review 等后续阶段；发现当前问题暴露了 Spec 缺口，就先补齐或修正 Spec，再继续推进。Why：Spec 是后续设计、实现、审计的共同基准；不先核实 Spec，后面的代码和审计就会各说各话，最终无法证明产出满足用户原始需求。

原则 3：一致性闭环校验

每个阶段的产出都必须和 Spec 对齐，并在审计发现问题后形成 review → fix loop 闭环。系统要持续检查 Spec 内部的人群、痛点、体验流、FR、AC 是否自洽，也要检查 Spec、UX、架构、实现、审计、README 和交付证据是否说的是同一件事；任何一层不一致，都要回到对应阶段修正并复验。Why：阶段串起来不等于质量闭环；只有每次偏差都能被发现、修复、再验证，流水线才不会把错误一路带到发布。

原则 4：主动需求澄清

任何任务执行前，只要存在歧义、多义、范围不明确或目标不清晰，Agent 就要先澄清，再行动；只有任务已经极其清晰、几乎零歧义时，才可以直接推进。用户明确说“拍了”“可以了”“就这样”或给出等价确认后，才算澄清收敛。Why：Agent 如果带着猜测写 Spec、派开发或做运维，会把一开始的小误解放大成整条流水线返工；先澄清能把不确定性留在成本最低的入口处解决。

原则 5：卡好准入和准出

流水线每个阶段的设计重心是准入条件和准出标准，而不是中间过程的微管理。准入检查输入是否满足前提（如 spec 是否存在、澄清是否收敛、前置阶段是否通过），准出检查产出是否满足质量标准（如 AC 覆盖率、审计通过、import 无报错）。中间过程交给 Agent 自主决策。

spec 的 FR/AC 本质上也在定义准入和准出：FR 定义“做什么才算进入了这个能力的范围”，AC 定义“什么状态算做完了”。设计 FR 时始终围绕这两个界面思考，而不是描述中间步骤。

Why：准入和准出是 AI 与人的关键交互界面。人不可能盯着 Agent 的每一步，但可以在入口和出口做校验。卡住这两个点，中间无论 Agent 怎么走，最终质量都可控。过程微管理既不可行（Agent 有自主决策能力），也不必要（只要出口质量达标，路径差异不重要）。

原则 6：语义路由优先

所有分类、路由和准入校验必须基于 LLM 语义理解。FR/AC 中涉及判定规则时，必须用自然语言详细描述语义规则，禁止依赖关键词匹配或正则表达式冒充理解能力。LLM 始终可用（Agent 本身运行在 LLM 上），因此不存在“无 LLM 降级”的合理场景。

Why：关键词和正则只能匹配字面，无法理解意图和边界。当规则用自然语言写清楚语义、交给 LLM 判定时，路由和校验能正确处理新场景和边界 case，而不会因为表述略有不同就误判或漏判。

为什么这个问题现在更尖锐

AI Coding 已经能很快地产生代码。 真正拖慢交付的部分，变成了后半段：

• spec 和实现脱节
• 任务看起来完成，实际没跑通
• gate 失败后没有稳定的修复闭环
• 开发者自己宣布通过，缺少独立审计
• 团队知道要验证，但验证动作散落在脚本、聊天记录和人脑里

SEVO 把这些动作收进同一条流水线。 重点不是生成更多文本。 重点是把“验收”做成运行时事实。

核心能力

1. 持久化流水线状态机

pipeline-engine.ts 负责把流水线变成一个可恢复的执行系统。

它会：

• 用 atomic write 持久化 state.json
• 用 append-only 的 events.jsonl 记录事件
• 支持 create / load / advance / activate
• 支持 clarification blocking
• 在 gate failed 后进入 fix_pending
• 在修复完成后继续 advance / retry / rollback

这意味着流水线不是一串容易丢失上下文的 prompt。 它是一个可恢复、可追责、可检查历史分叉的状态机。

V2 自动推进进一步把 dispatch 接入流水线：dispatch 时自动创建 pipeline run，任务完成后自动推进到 review 阶段；handshake 已改为 command channel，不再泄露到用户回复。

2. 运行证据验证

l3-runtime-verifier.ts 是 SEVO 最关键的一层。

它会跑真实检查，而不是只看提交记录或模型自述。 当前支持的验证入口包括：

• CLI
• Web
• Library
• Hook
• Plugin

验证方式也不是单点判断，而是组合判断：

• exit code
• 输出 validator
• LLM meaningful 判断
• 从 spec 解析出的 FR / AC 语义核验

SEVO 关心的是：
真实运行输出，是否真的对应到了验收条件。

这也是它和普通 AI Coding 工具拉开距离的地方。 很多工具会告诉你“我写完了”。 SEVO 会继续追问：“证据呢？”

3. Gate 驱动的修复闭环

流水线不会因为某一步“看起来差不多”就继续往前走。

SEVO 有明确 gate。 没过就停。 停下后不是报错结束，而是进入可继续的修复闭环：

• 失败被记录
• 原因被定位
• 修复任务被挂起或派发
• 修完后重新验证
• 通过后再推进下一阶段

这个设计直接面向真实研发现场。 因为项目失败，通常不是失败在“不会生成代码”，而是失败在“没人把失败状态接住”。

4. 角色分离

SEVO 默认把 implementation 和 independent audit 分开。

原因很直接：

• 写代码的人天然知道自己想达成什么
• 审计的人只关心结果有没有真的达成
• 两个视角混在一起，漏检会变多

所以 SEVO 把“实现”和“证明”拆开处理。 先做，再审，再看运行证据。

5. 从 prompt loop 进入 engineering loop

SEVO 的价值，不在于多一个会写代码的 Agent。

它把 AI 生成能力嵌进一套更完整的工程回路：

• spec 明确目标
• pipeline 控制推进
• verifier 检查运行结果
• audit 负责独立质检
• evidence 形成交付依据

这样团队讨论的对象就变了。 不再围着 prompt 来回试。 开始围着需求、状态、证据和门禁推进。

SEVO 适合什么场景

• 需求和验收条件已经明确，希望压缩从 spec 到交付的距离
• 团队已经在用 AI Coding，但“写完后怎么证明”还很弱
• 一个项目里有多个 Agent、多人协作，容易出现职责混淆
• 你需要把失败、返工、复验这几步纳入正式流程
• 你不接受“模型说可以”当作完成标准

一句话理解

SEVO 让软件交付从“生成代码”前进到“提交运行证据”。

它盯住的是最后那一步： 需求写在 spec 里，结果必须在 runtime 里被证明。

和常见工具的差别

SEVO 的关注点和一般研发工具不同：

• 它把 spec 当成运行验证的输入，不只是文档
• 它把流水线当成持久化状态机，不只是任务列表
• 它把 runtime evidence 当成核心产物，不只是辅助日志
• 它把 independent audit 当成默认角色，不是可选动作

如果你要给它一个更准确的位置，最接近的说法是：

AI-native delivery operating system

重点在 delivery。 重点在 operating。 重点在 evidence。

仓库关注点

阅读这个仓库时，建议优先看这几类能力：

• spec 如何定义 FR / AC
• pipeline-engine.ts 如何持久化状态和事件
• l3-runtime-verifier.ts 如何执行真实运行检查
• gate fail 后如何进入修复闭环
• implementation 和 audit 如何分离

这些部分共同构成了 SEVO 的主价值，不是附属功能。

最后

AI 写代码已经不稀缺。 真正稀缺的是：
把需求、实现、验证、审计、修复和交付证据接成一条可靠的链。

SEVO 就是为这条链而建。