指南 · 规格交付

如何交付一份 Agent 生成的技术规格

规格只有在读者能质疑假设、核对边界并确认批准的是哪一版时,才真正成为实现契约。生成它的会话本身做不到这些。

更新于 2026 年 8 月 3 日实践指南

先把规格写到可拍板

  1. 问题、用户与非目标
  2. 现状证据
  3. 拟议行为与公开契约
  4. 数据、权限和失败语义
  5. 迁移、回滚、风险与开放问题
  6. 希望评审者授予的具体权限

事实、提案与路线图分开写

读者要一眼分辨:当前系统已经如何、这份规格要改成什么、哪些只是未来可能。不要用自信语气掩盖状态差异。

把候选交给正式评审

本地校验后以 --review 发布。要求修改就回源重做,不在聊天里口头覆盖候选。

ow a2ui draft check ./spec
ow a2ui draft build ./spec
ow a2ui digest ./spec/document.mdw
ow publish ./spec/document.mdw --review --no-open --timeout 900

实现引用获批的固定版本

在任务、release evidence 或审计记录里放不可变版本。范围实质变化时,重新提交候选,旧批准不是无限授权。

常见问题

常见问题

实现应该链接 canonical 还是固定版本?

实现契约用获批固定版本;需要查看当前正式状态的读者再用 canonical。

Agent 可以批准自己生成的规格吗?

OpenWiki 的评审闭环要求明确的人类决定;Agent 必须把缺失决定视为阻塞。

使用真实工作流

把 Agent 创作的作品发表出来。

让每份报告、文档或计划拥有面向读者的页面;批注、评审决定和正式版本都从这里回到 Agent。