加一个独立的评审助手

如果想获取全套课程资料，请关注微信公众号 「AI面包君」，回复 「课程资料」 即可领取。

1. 写完之后，再检查一遍

假设任务是写一条简短的技术帖子，第一稿可能出现这些问题：

• 超过要求的长度。
• 表达空泛，没有具体内容。
• 技术术语或适用条件说得不准确。

可以再请模型按要求评估草稿，指出具体问题。这类用模型参与评估的做法，常被称为 LLM-as-judge。

本章把评审放到独立的 Critic 中，让它只接收待审稿件和标准，再把反馈交回写作者：

任务 ──→ Executor 出稿 ──→ Critic 评分
                              │
                          通过│不通过
                              ↓ ↑
                          最终答案  ↑
                                ↑   │
                                └───┘ Executor 拿反馈再改

这样拆分，主要是为了让过程更容易检查：

1. 写作和评审分别使用提示词。
2. 可以明确决定 Critic 能看到哪些内容。
3. 每轮草稿、评价和修改都能留下记录。

Critic 也会误判，独立角色并不自动带来更可靠的评价。

<!-- bread-visual:start -->

图解： 创作与评审使用独立的上下文。 Critic 的判断仍可能出错；轮数上限用于避免无限改稿。

<!-- bread-visual:end -->

---

2. 跑起来

cd ch02_critic
python main.py

预期输出

=== 任务 ===
写一条不超过 140 字的中文推特，主题是 Python 的 GIL。要求风格机智、技术准确。

--- Round 1 ---
📝 Executor 草稿（138 字符）：
Python 的 GIL 就像办公室唯一的微波炉：一次只能热一个人的饭。
你以为多线程能并发？不，大家排队等饭🍱。这就是为啥 CPU 密集型还是要走 multiprocessing。

🔎 Critic 评分：7/10  通过：False
   反馈：GIL 比喻贴切但解释偏弱，可以加一句"I/O 密集型其实没问题"避免误导。

--- Round 2 ---
📝 Executor 草稿（137 字符）：
Python 的 GIL 像办公室唯一的微波炉：CPU 密集大家排队等饭🍱。
但 I/O 密集（爬虫、API 调用）反而不受影响——大家在等饭时可以同时刷手机。

🔎 Critic 评分：9/10  通过：True
   反馈：技术准确性、机智度都到位，长度合规。通过。

✅ 审查通过！

=== 最终稿 ===
Python 的 GIL 像办公室唯一的微波炉：CPU 密集大家排队等饭🍱。
但 I/O 密集（爬虫、API 调用）反而不受影响——大家在等饭时可以同时刷手机。

实际可能首轮通过，也可能经过几轮修改。对照每版稿件和评语，检查问题是否减少；不要只看评分升高，就认定质量一定改善。

---

<!-- bread-practice:start -->

实操画面对照