tech-batch 写审分离:AI 批量写技术博文的质量控制

一、概念速查

什么是 tech-batch

tech-batch 是一个批量写技术博文的 OpenCode skill。它把一个系列的文章逐篇写→审→改→再审,严格串行推进,直到每篇都通过独立审查才进入下一篇。

核心设计

维度 设计 理由
写审分离 写 agent 和审 agent 永远不同 防止同一个人既写又审的盲区
盲审 审 agent 每次调用不带历史上下文 保证每次审查独立,不放水
无限循环 不设重试上限,直到零 blocking 质量不妥协
串行 一篇一篇过,不并发 审不过不进下一篇
断点续跑 进度文件记录每篇状态 中断后可恢复

审查五问

  1. 字数 ≥ 800?
  2. 结构完整(概念速查 + 底层原理 + 设计原则三段齐全)?
  3. Mermaid 图独立代码块、无嵌套 subgraph?
  4. 代码可复制、版本号/API 明确?
  5. 无面试八股、无博文关联、无下一篇引导?

二、底层原理

写审循环流程

写 agent 产出初稿

审 agent 盲审

全部 yes?

写 agent 逐条修改

标记 completed

下一篇

这个循环每次审 agent 都是全新的子 agent 调用。它不继承上一次审查的对话历史,审稿时不记得上次看过什么、改了什么。这意味着每次审查都是对当前版本的独立质量判断。

为什么要写审分离

让同一个人既写又审存在一个根本问题:写的时候已经对内容产生了路径依赖,审查时会下意识地接受自己写的思路。写 agent 是一套 prompt 和参考素材,审 agent 是一套标准。两套不同上下文、不同职责、不同 agent,才能形成真正的交叉验证。

为什么要盲审

带上下文的审查存在"审查疲劳":第一次发现 3 个问题,第二次看到"这次改了 2 个,还有一个没改"就会倾向于"差不多行了"。盲审切断了这条路——每次重新读文章,逐条核对五问,不会因为"之前看过"而降低标准。

审 agent 第 1 次

发现 blocking

写 agent 改

审 agent 第 2 次

全新判断,
不参考第 1 次审查

串行 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),未发现质量回溯问题。

Logo

欢迎加入 MCP 技术社区!与志同道合者携手前行,一同解锁 MCP 技术的无限可能!

更多推荐