27｜生成评审：让每个版本独立接受审查
黄佳
释题：生成者提交候选版本，评审者报告问题与证据，策略闸裁决当前版本。修订器产生的是一份新的候选，它还没有接受评审。
你好，我是黄佳。
上一讲，我们把反思讲成了一条结果反馈闭环：拿到已经发生的结果，对照外部证据识别偏差，在授权范围内修改，再独立验收一次。这一讲进入闭环中最靠近验收的一段。
一份薪酬月报被对账证据退回来以后，并没有结束，还有一系列问题要解决：谁负责修改？修改以后谁负责再检查？第一遍审查原稿时得到的结论，能不能直接交给修订稿使用？评审者说“建议通过”，系统是不是就应该真的放行？
看起来这些只是流程细节，实际直接影响了检查质量。
这一讲进入反思模块的第一个具体模式：生成评审（Generator–Critic）。它位于反思行、链式列。我们先沿着一个常见的版本错误拆开接口，再打开工作台，观察两遍评审怎样为两个版本留下彼此独立的结论。
评审结论必须绑定具体版本
很多生成评审流程会写成下面这样：
这段代码先生成原稿，再让评审者提出意见，根据意见修改，最后返回修改后的版本。问题在于，评审者真正看过的是 draft，系统最后发布的却是 final。
如果审查状态只挂在 task_id 上，原稿和修订稿就会共享一枚“已经审过”的徽章。日志里确实调用了 critic，也调用了 reviser，但最终准备发布的那份内容，反而没有被真正检查过。
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线笔记
复制
AI
- 深入了解
- 翻译
- 解释
- 总结
仅可试看部分内容，如需阅读全部内容，请付费购买文章所属专栏
《Agent 设计模式之美》，新⼈⾸单¥68
《Agent 设计模式之美》，新⼈⾸单¥68
立即购买
© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
登录 后留言
精选留言
由作者筛选后的优质留言将会公开显示，欢迎踊跃留言。
收起评论