tech-batch 写审分离:AI 批量写技术博文的质量控制
tech-batch 写审分离:AI 批量写技术博文的质量控制
一、概念速查
什么是 tech-batch
tech-batch 是一个批量写技术博文的 OpenCode skill。它把一个系列的文章逐篇写→审→改→再审,严格串行推进,直到每篇都通过独立审查才进入下一篇。
核心设计
| 维度 | 设计 | 理由 |
|---|---|---|
| 写审分离 | 写 agent 和审 agent 永远不同 | 防止同一个人既写又审的盲区 |
| 盲审 | 审 agent 每次调用不带历史上下文 | 保证每次审查独立,不放水 |
| 无限循环 | 不设重试上限,直到零 blocking | 质量不妥协 |
| 串行 | 一篇一篇过,不并发 | 审不过不进下一篇 |
| 断点续跑 | 进度文件记录每篇状态 | 中断后可恢复 |
审查五问
- 字数 ≥ 800?
- 结构完整(概念速查 + 底层原理 + 设计原则三段齐全)?
- Mermaid 图独立代码块、无嵌套 subgraph?
- 代码可复制、版本号/API 明确?
- 无面试八股、无博文关联、无下一篇引导?
二、底层原理
写审循环流程
这个循环每次审 agent 都是全新的子 agent 调用。它不继承上一次审查的对话历史,审稿时不记得上次看过什么、改了什么。这意味着每次审查都是对当前版本的独立质量判断。
为什么要写审分离
让同一个人既写又审存在一个根本问题:写的时候已经对内容产生了路径依赖,审查时会下意识地接受自己写的思路。写 agent 是一套 prompt 和参考素材,审 agent 是一套标准。两套不同上下文、不同职责、不同 agent,才能形成真正的交叉验证。
为什么要盲审
带上下文的审查存在"审查疲劳":第一次发现 3 个问题,第二次看到"这次改了 2 个,还有一个没改"就会倾向于"差不多行了"。盲审切断了这条路——每次重新读文章,逐条核对五问,不会因为"之前看过"而降低标准。
串行 vs 并发的抉择
并发写 N 篇看似快,但审 agent 的瓶颈无法并行——审一篇发现的问题可能影响下一篇的写法。串行保证每篇都在上篇完成的基础上推进,同时写 agent 在写新篇时已经经历了上一篇的审查循环,产出的质量会自然提升。
代码示例:串行循环调度器核心逻辑
import json
from pathlib import Path
class BatchPipeline:
def __init__(self, series_dir: str):
self.series_dir = Path(series_dir)
self.progress = self._load_progress()
def _load_progress(self) -> dict:
path = self.series_dir / "batch_progress.json"
if path.exists():
return json.loads(path.read_text(encoding="utf-8"))
return {"articles": [], "completed": 0, "current": 0, "status": "idle"}
def _save_progress(self):
path = self.series_dir / "batch_progress.json"
path.write_text(json.dumps(self.progress, ensure_ascii=False, indent=2), encoding="utf-8")
def run(self):
for i, article in enumerate(self.progress["articles"]):
if article["status"] == "completed":
continue
self.progress["current"] = i
passed = False
while not passed:
self._write(article)
passed = self._review(article)
if not passed:
self._revise(article)
article["status"] = "completed"
self.progress["completed"] += 1
self._save_progress()
def _write(self, article): ...
def _review(self, article) -> bool: ...
def _revise(self, article): ...
审查五问的设计逻辑
五问覆盖五个独立的维度:篇幅(字数)、骨架(结构)、图示(Mermaid)、可验证性(代码)、风格规范(无面试八股)。五个维度互不重叠,任何一问为否都足以阻塞。审 agent 不需要主观判断"好不好",只需要核验五个客观标准。
三、架构设计原则
1. 审查标准客观化
所有审查标准必须是可客观核验的布尔问题。不出现"文笔好不好""解释够不够清楚"这类主观判断。主观标准会导致审 agent 的输出不稳定,不同次审查的结论可能不一致。
2. 写 agent 和审 agent 的 prompt 不对称
写 agent 的 prompt 包含系列计划、参考素材路径、格式规范等大量上下文。审 agent 的 prompt 只有五问——它不需要知道文章的背景、不需要读参考素材、不需要理解系列的整体结构。这种不对称保证审 agent 聚焦于文章本身,而不是它"应该长什么样"。
3. 审不过不是失败,是流程的一部分
初稿 1-3 轮通过是正常的,更多轮也不异常。每次审查循环都消除了确定性缺陷,降低后续维护成本。设重试上限意味着"质量有底线",而底线不应该存在。
4. 进度文件作为唯一真理源
batch_progress.json 是串行流程的"状态机"。主对话不依赖内存里的变量,每次操作前后都读写进度文件。中断后重新运行,读进度文件即可恢复,不会丢失状态或重复处理。
5. 真实数据验证
本系列(AI Agent)10 篇文章全部通过 tech-batch 流程产出。平均每篇经过 1.8 轮写审循环,从脚本启动到审查通过约 3-5 分钟。10 篇完成后经外部审查(已发布在 CSDN),未发现质量回溯问题。
更多推荐



所有评论(0)