Proposal / Review / Decision 对象化契约
在上一章中，我们将职责拆分为：
- Generate（生成）
- Review（审阅）
- Controller（控制）
但仅有角色划分是不够的。
如果没有明确的对象契约， 这些角色最终仍会退化为：
- Prompt 拼接
- 自然语言判断
- 隐式假设
本章解释 BookiAI 如何通过 对象化契约，让 AI 参与变得可治理。
为什么“对话”不适合系统
大多数 LLM 集成都依赖对话：
- Prompt
- 自然语言回复
- 解释性文本
这对人类友好， 但对系统极不友好。
对话具有以下问题：
- 难以校验
- 无法安全版本化
- 不利于审计
- 无法回放
只要 AI 的输出会影响系统状态， 它就必须是机器可验证的结构。
契约三角
BookiAI 用三个核心对象 来规范 AI 与系统的交互：
- Proposal（建议） —— AI 提出什么
- Review Report（审阅报告） —— 系统如何评估
- Decision（决策） —— 系统最终怎么做
每个对象都有：
- 明确的归属角色
- 清晰的职责边界
- 可追踪的生命周期
对象之间不能越权。
Proposal：结构化意图，而非执行指令
Proposal 是 Generate 角色的产物。
它回答：
- AI 建议做什么
- 基于哪些假设
- 存在多大不确定性
Proposal 可能包含：
- 建议的会计分录
- 科目选择
- 分类判断
- 支撑理由
但必须明确：
- Proposal 不能修改系统状态
- Proposal 必须暴露不确定性
- Proposal 本质上是“不完整的”
它是一个评估请求， 而不是执行命令。
Review Report：显式的评估结果
Review Report 由 Review 角色生成。
它回答：
- 进行了哪些校验
- 哪些规则通过或失败
- 风险与不确定性在哪里
- 是否建议继续
审阅可能包括：
- 确定性规则校验
- 策略检查
- 二次 AI 审阅
- 人工复核
审阅报告不是简单的“通过 / 不通过”， 而是一份可解释的评估结论。
此阶段不执行任何操作。
Decision：系统权力的唯一出口
Decision 由 Controller 产生。
它回答：
- 是否允许继续
- 是否需要人工确认
- 是否拒绝并记录原因
常见决策包括：
- 自动执行
- 请求用户确认
- 请求补充信息
- 明确拒绝
只有 Decision 对象 才能授权执行。
这确保了：
系统状态的改变
永远由系统本身负责
为什么对象化契约如此重要
对象化契约带来的价值包括：
- 清晰的责任边界
- 可审计的决策路径
- 可控的失败方式
- 支持回放与回滚
- AI 行为的可观测性
最关键的一点是：
没有 Decision，就没有执行
契约如何支持系统演进
由于所有交互都是显式对象：
- Prompt 可以变化
- 模型可以替换
- 校验逻辑可以升级
而不会破坏：
- 历史记录
- 审计能力
- 系统信任边界
这正是 BookiAI 能够从人工控制逐步演进到自动化的基础。
接下来
当对象契约已经明确， 下一个问题自然浮现：
如何系统性地评估
一个 AI 建议是否“足够好”？
👉 推荐可信性保障与校验机制
本文由 ChatGPT 撰写，经 BookiAI 团队审阅。