w4.2动手⏱ 约 7 分钟
写审改三步:给产线雇一个“抬杠的”
学会用三步结构和立场相反的审核角色,替代不可靠的自查
🔎 最后验证 2026-08📚 来源:课程产线工作流源码 ops/course-factory/workflows/*.yaml 中的三步结构与角色配置
为什么学这个
上一节你亲眼看到了自查的样子:几条不痛不痒的建议,一次盖章式的通过。
那正确的做法长什么样?我们这条产线给出的答案是一个可以照抄的结构:产出不是终点,产出之后必有一道立场相反的审,审完必有一道逐条落实的改。
这一节讲两个相互咬合的概念:先立起"写/审/改三步结构"这个骨架,再讲装进骨架里的"换角色审核"。前者是后者的载体,拆开讲会断气口,所以合在一节。学完这节,你可以在任何 AI 对话工具里手动搭出同款流程——并和上一节的自查结果正面对比。
💡 打个比方
报社里,记者和编辑是两个人。记者的 KPI 是写出来,编辑的 KPI 是挑出刺。如果让记者自己当编辑,报纸的差错率会怎样,不用做实验也能猜到。产线要做的,就是给每个"记者"配一个专职"编辑"——而且是以苛刻著称的那种。
第一个概念:写/审/改三步结构
我们的课程产线由四个工作流组成,其中负责写稿的 write-module 和负责转站点格式的 to-mdx,流程都不是一步完成,而是三步:写(或转)→ 审 → 改。这不是转述,配置就写在产线源码 ops/course-factory/workflows/*.yaml 里,可在源码中核对。
三步结构的要点在于结构性:审不是"有空看一眼",改不是"参考一下批注"。审是流程里绕不过去的一步,改必须逐条回应审的批注。把质检写进流程,而不是写进心情。
第二个概念:换角色审核
三步里中间那步"审",有两个关键设计,同样写在 yaml 源码里:
- 换角色:写作步用的角色是 engineering-technical-writer(技术写作者),审核步用的是 testing-reality-checker(现实检验者)——两个不同的角色配置,不共享写作时的上下文。
都看到这了，打个赏呗！
接下来 · w4.3
审核的盲区:多类事故,零命中
继续读下一节 →