8.0
热点
AI SCORE
编程提效2026-08-24 13:42
用OpenSpec分离AI的编码、审查与验证
dev.to · AI#AI编程#工作流#Code Review
Editor brief · 编辑速览
ithyno工具通过OpenSpec Skills将实现、审查、验证分配到独立AI session，避免单一session既写代码又自审的工作流缺陷，适合规模化使用AI编程的团队。
当一个 coding session 不再够用
本文面向将 coding agent 用于实际功能开发的开发者，不涉及自动补全或一次性提问，重点讨论无法在单个 agent session 中完成的工作。
你可能遇到过以下情形：
你可能希望一个 session 实现变更，另一个 session 审查它，第三个 session 验证它。这些 session 可以使用相同的工具和模型，也可以使用不同的工具和模型。重要的区分在于角色，而非供应商。
我为此工作流构建了 ithyno。
从一份共同约定的规格开始
在选择 agent 之前，先决定应该做什么变更。
这就是 spec-driven development 背后的理念。
聊天 prompt 不应该是需求的唯一来源。Spec-driven development 在编码开始前记录预期行为。规格成为一份共同约定。开发者和每个 agent 角色都可以阅读它。
这将工作流从：
prompt → code → hope that the result matches the intent
转变为：
agree on behavior → plan the change → implement → review → verify
目标不是为了文档而文档。目标是保留原始意图。实现细节不应取代需求。agent 不应静默地添加新的范围。
OpenSpec 提供了什么
OpenSpec 是一个用于 spec-driven development 的轻量级框架，专为 AI coding assistants 设计。开发者和 assistant 在编码开始前就变更达成一致。
OpenSpec 将当前系统行为和提议的变更保留为仓库中的文件。
openspec/specs/ 描述当前约定的行为。
openspec/changes/<change-id>/ 包含一个提议的变更。
一个变更可以包含 proposal、spec 更新、设计笔记和 tasks。
已完成的变更可以归档到 living specifications 中。
一个变更的主要文件易于检查：
openspec/changes/<change-id>/
├── proposal.md
├── design.md
├── tasks.md
└── specs/
proposal.md 解释为什么需要这个变更。tasks.md 跟踪工作。specs/ 目录记录添加或变更的行为。当实现决策需要单独解释时使用 design.md。
这些产物是普通的项目文件，不绑定于任何一个聊天 session。后来的 session 可以阅读相同的意图，无需从聊天历史中重建上下文。
要了解这些文件如何映射到项目工作流的详细对照，请参阅 OpenSpec and the ithyno Kanban model。
将一个 OpenSpec 变更转化为基于角色的工作
OpenSpec 定义变更。ithyno 将该变更分配给不同的角色。
OpenSpec change
│
├── code role → implement the tasks
├── review role → compare the result with the proposal and specs
└── verify role → run the applicable project checks
每个角色收到相同的变更，每个角色有不同的职责。
code worker 阅读 proposal、spec 变更和 tasks，实现请求的行为，同时更新任务进度。
review worker 不继续实现，而是将结果与约定的范围进行比较，记录变更是通过还是需要返工。
verify worker 运行适用于项目的检查，然后记录结果。缺少一个可选脚本与一个必需的测试失败是不同的。该角色评估可用的证据，不会盲目运行固定的命令列表。
实现、审查和验证需要不同的判断。一个长 session 会将其实现假设带入审查中。分离角色减少了这个问题。
角色并不意味着不同的供应商
"多个 agents" 可能听起来像是在混合竞争产品。基于角色的执行并不需要这种混合。
以下所有安排都是有效的：
一个 agent entry 定义一个 worker 及其职责。一个项目可以复用相同的 CLI 和模型，也可以混合使用。ithyno 为所选的 Manager 和 worker 选择支持的路由。
当前的设置指南记录了角色配置和已验证的路由：Configure role-based agent workers。
按顺序调度角色
Manager 通过所需的阶段来协调变更。
proposed → code → review → verify → merge and archive
应用为所选的 Manager 创建调度命令。该命令可以输入到它启动的终端中。你也可以复制命令并自行粘贴到该终端。
Manager CLI 然后调用已安装的 ithyno dispatch Skill。命令格式取决于 CLI。slash-command client 和 skill-name client 可能使用以下形式：
/ithy-opsx:dispatch add-session-timeout
ithy-opsx-dispatch add-session-timeout
一个变更的各个阶段保持顺序。审查在其需要检查的实现完成后开始。验证不会取代审查。当启用隔离执行时，不同的变更可以同时运行。
每个活跃的变更可以使用自己的 Git worktree 和分支。这将未提交的文件隔离开来。开发者仍然可以用常规 Git 命令检查每个结果。
Worktrees 是可选的，不是使用 ithyno 的必要条件。详见 OpenSpec worktrees。
完成必须留下证据
Agent CLI 以不同方式报告成功。一个 worker 可能以 exit code 0 退出，却没有产生请求的结果。
ithyno 不仅依赖终端输出或进程状态。审查和验证角色将结构化结果写入变更中。Manager 读取这些结果，然后继续、请求返工或停止。
review worker 可以写入这样的 review.md 文件：
---
verdict: needs-rework
summary: "The implementation is missing a required edge case."
findings:
- severity: high
file: src/auth.ts
line: 42
message: "Token expiry validation is missing."
---
这创建了一条共享的证据链：
specification → implementation diff → review result → verification result
开发者和后来的 agent session 检查相同的文件。
ithyno 不取代 OpenSpec、Git 或 agent CLI
ithyno 可作为 VS Code 扩展和 Electron 应用使用。两者使用相同的仓库文件。
ithyno 目前是一个 alpha 项目。Agent CLI 变化很快。权限、命令参数和子 agent 特性可能在版本之间发生变化。文档列出了支持的设置和已验证的路由。
阅读 installation guide。
从 Start a simple project 开始。
配置基于角色的 agent workers。
在 GitHub 上查看源代码和 releases。
你不需要另一个供应商来分离这些职责。从一份共享的规格开始，然后将规划、实现、审查和验证分配给各自的角色。
查看 architecture overview 了解更多细节。
欢迎来自实际项目的反馈。如果某个 CLI 路由失败或工作流不适合你的项目，请 open an issue。如果 ithyno 对你有帮助，考虑给仓库加星。
Disclosure: This article was edited with AI assistance and reviewed by the author.