AI 审查技术文章的实战工作流

本文是一份可复用的操作手册。当你需要审查和修复一篇或多篇技术文章时，按照本文的工作流执行即可。

0. 这个工作流解决什么问题

你写了一篇技术文章（或一个系列），但不确定内容是否准确。你需要：

• 一个审查标准来系统性地发现错误（而不是让 AI 随便看看）
• 一个防敷衍机制确保 AI 真的算过、查过（而不是编造结论）
• 一个修复流程把发现的问题分优先级处理

本文提供：审查 prompt 模板 + 两阶段工作流 + 实战踩坑经验。

核心理念：先审查，后修复。审查和修复是两个独立阶段，不要混在一起做。

1. 审查 Prompt 设计（最关键的一步）

审查质量取决于 prompt 质量。一个烂 prompt 会让 AI 敷衍了事、编造验算结果。

1.1 为什么普通 prompt 不管用

根本原因：你没有强制 AI 展示推理过程。AI 可以直接编造一个"验算结果"而不真正计算。

1.2 审查 Prompt 的 5 条核心约束

这 5 条约束是从速通AI系列教程审查实战中提炼的，每条都有具体原因：

## ⚠️ 核心约束（违反任何一条即判定审查不合格）

1. **禁止只写结论不写过程**：所有数值验算必须展示完整中间步骤，
   包括公式代入、逐行计算、最终结果。
   → 原因：编造 3 步中间过程的难度远高于编造 1 个结论。

2. **禁止跳过任何计算点**：Phase 1 表格中列出的每个编号都必须
   在 Phase 2 中逐一验证，不得省略。
   → 原因：AI 会挑简单的算、跳过复杂的。

3. **禁止凭记忆给出验算结果**：必须从文章原文提取数值，
   逐步计算，用计算器级精度验证。
   → 原因：AI 的"记忆"可能与文章实际数值不一致。

4. **不确定的内容必须标注**：使用 `[不确定]` 标记任何你无法
   100%确认的内容，并说明原因。
   → 原因：给 AI 一个诚实退出通道，比让它硬编好得多。

5. **禁止笼统评价**：每条问题必须引用文章具体位置
   （章节号 + 原文片段），不得使用"可能有问题"等模糊表述。
   → 原因：模糊评价无法指导修复。

1.3 完整审查 Prompt 模板

以下是从实战中优化的完整模板。核心设计是强制两阶段执行：先列出所有计算点（Phase 1），再逐一验算（Phase 2）。

# 技术文章审查模板（强制执行版）

## ⚠️ 核心约束
[见上文 5 条约束]

## 审查流程（Phase 1 → Phase 5，严格按顺序执行）

### Phase 1：全文扫描与计算点清单

通读全文，列出所有包含数值计算的段落，输出编号表格：

| 编号 | 位置 | 类型 | 简要描述 |
|------|------|------|----------|
| C-01 | §2.3 | Softmax | 输入 [2.0, 1.0, 0.1] 的计算 |
| C-02 | §3.1 | 梯度下降 | y=(x-3)² 的 6 步迭代 |
| ... | ... | ... | ... |

**此表格必须在验算开始前输出。未输出此表格直接开始验算的，视为不合格。**

### Phase 2：逐点验算

对 Phase 1 表格中的每一行：

> **验算 C-XX（§X.X 描述）**
> - 原文输入：...
> - 原文输出：...
> - 我的验算：
>   - 使用公式：...
>   - 第 1 步：... = ...
>   - 第 2 步：... = ...
>   - ...
> - 最终结果：...
> - 与原文对比：✅ 一致 / ❌ 不一致（差异为...）

### Phase 3：维度追踪（仅限矩阵/张量运算）

| 步骤 | 操作 | 输入维度 | 输出维度 | 是否一致 |
|------|------|----------|----------|----------|

### Phase 4：代码审查

对每个代码块：
- [ ] 变量是否在使用前定义？
- [ ] 张量维度是否匹配？
- [ ] 是否缺少 import / .to(device) / torch.no_grad()？
- [ ] 能否在干净环境中直接运行？

### Phase 5：概念、逻辑与时效性

- [ ] 核心术语定义是否与原始论文一致？
- [ ] 是否"只说优点不提局限"？
- [ ] 是否以偏概全？
- [ ] 每节是否有衔接句？
- [ ] 每个公式后是否有直觉翻译？
- [ ] 是否有数据过时？

## 输出格式

### 一、总体评价
### 二、严重问题（Must Fix）
> **§X.Y [类型]**：问题描述
> **原文引用**：精确引用
> **我的验算/分析**：完整过程
> **建议**：具体修正方案

### 三、优化建议（Nice to Have）
### 四、验算过程记录
### 五、确认无误的部分
### 六、自查清单
### 七、错误统计表

2. 两阶段工作流

flowchart LR
    A["阶段一：审查"] --> B["生成审查报告"]
    B --> C{"用户确认"}
    C -->|"合格"| D["阶段二：修复"]
    C -->|"不合格"| A
    D --> E["分类修复"]
    E --> F["完成"]

2.1 阶段一：审查（只读，不改原文）

目标：系统性发现所有问题，输出结构化审查报告。

执行方式：

• 每篇文章开一个独立会话（避免上下文溢出）
• 将审查 prompt + 文章内容一起传给 AI
• AI 输出审查报告（保存为 review-XX.md）

关键原则：

• 审查阶段不修改原文，只输出报告
• 每篇审查报告必须包含完整的验算过程
• 用户检查报告质量后才进入修复阶段

2.2 阶段二：修复（按优先级处理）

审查报告中的问题分为三个优先级：

修复原则：

• 只修复 Must Fix，不动 Nice to Have（除非用户要求）
• 每个修复必须精确到行，使用精确文本替换
• 修复后不需要重新审查（改动是确定性的）

2.3 系列文章的特殊处理

对于系列文章（如速通AI系列教程），额外步骤：

flowchart TD
    A["准备审查 prompt 模板"] --> B["逐篇审查（独立会话）"]
    B --> C["汇总审查报告"]
    C --> D{"用户确认"}
    D -->|"全部合格"| E["逐篇修复 Must Fix"]
    D -->|"部分不合格"| F["重新审查不合格篇"]
    F --> D
    E --> G["最终确认"]

关键实践：

• 系列文章可以并行审查（每篇一个独立会话）
• 也可以逐篇审查（每篇完成后再启动下一篇）
• 修复阶段建议先审后修（统一处理，保持一致性）

3. 实战踩坑经验

以下是从速通AI系列教程审查项目中总结的真实教训。

3.1 AI 会编造验算结果

现象：AI 声称"已验算，结果正确"，但实际没有真正计算。

解决：强制要求写出完整中间步骤。编造 3 步中间过程的难度远高于编造 1 个结论。

案例：在审查 RNN 梯度链时，AI 最初给出的验算结果与原文一致（0.0），但重新独立计算后发现正确值应为 0.092。原因是公式中 h_{t-1} 应为 h_t。

3.2 审查会发现你意想不到的错误

实际发现的错误（速通AI系列教程，13 个 Must Fix）：

教训：即使是自己写的文章，也必须经过系统性审查。AI 辅助写作的最大风险不是"写得不好"，而是"写得看起来对但实际有错"。

3.3 工具链限制

Agent Manager 可能不可靠：

• session 可能卡在 pending 状态
• VS Code 面板可能找不到 session 卡片
• 备选方案：直接用 Task 工具启动子 agent

子 agent 可能没有 edit 工具：

• 子 agent 的工具权限可能与主会话不同
• 子 agent 可能无法写入文件
• 解决方案：子 agent 输出修改建议，主会话执行修改

上下文溢出：

• 大文章（>50KB）可能导致 AI 遗漏后半部分
• 解决方案：要求 AI 确认已读完最后一行
• 或者分段审查后合并报告

3.4 审查报告的验收标准

审查报告本身也需要验收。不合格的报告特征：

4. 优化阶段（补充缺失内容）

审查修复完成后，如果需要进一步提升文章质量，进入优化阶段。

4.1 优化 Prompt 模板

## Role
你是一名技术文章优化专家。你的任务是按照本指令的流程和标准，
对目标文章进行优化。

## 质量标准

### P0：硬性指标（缺一不可）
- 核心算法必须有手算数值示例（输入→中间步骤→输出→验证→解读）
- 抽象概念必须遵循「直觉→公式→数值→解读」递进
- 章节之间有逻辑衔接（问题引入 + 本节目标）

### P1：强烈建议
- 设计选择有「问题→方案→代价」分析
- 核心概念配备类比（附边界说明）
- 代码注释解释"意图"而非"操作"

### P2：锦上添花
- 每个大节末尾有模块小结表格
- 文章开头有知识依赖图

## 执行模式
等待确认（先输出优化计划，确认后再实施）。

4.2 改动策略

保留原文结构做补充的情况：

• 原文解释顺序合理，只是缺少某些部分（如手算示例、类比）
• 原文的类比和措辞很好，只是需要补充

推倒重来的情况：

• 原文直接上公式，没有直觉铺垫
• 原文核心算法缺少数值示例
• 原文逻辑严重断裂，补充会导致臃肿

原则：保留原文的好类比和好措辞，但不为保留而保留臃肿内容。

5. 验收标准

5.1 面向读者的验收

问自己：读者看完这篇文章后，能不能：

• 用自己的话解释每个核心概念？
• 手算关键算法？
• 回答"为什么用 X 不用 Y"？

5.2 面向面试的验收

列出文章涉及的核心概念，逐个检查：

• 有没有覆盖面试中可能被追问的"为什么"？
• 有没有手算示例（面试加分项）？
• 有没有"问题→方案→代价"分析（标准答题结构）？

5.3 面向系列的一致性验收

• 术语是否统一？
• 跨文章链接是否正确？
• 是否有重复展开的内容？

6. 检查清单

写作阶段

• 明确读者画像
• 每个知识点回答"是什么、为什么、怎么用"
• 抽象概念遵循"直觉→公式→数值→解读"
• 设计选择使用"问题→方案→代价"
• 类比满足"贴切、具体、有边界"
• 核心算法有手算数值示例
• 代码注释解释"意图"

审查阶段

• Phase 1 计算点清单已输出
• Phase 2 每个计算点有完整验算过程
• Phase 3 维度追踪已完成（如有矩阵运算）
• Phase 4 代码逐行检查已完成
• Phase 5 概念/逻辑/时效性检查已完成
• 所有不确定内容已标注 [不确定]
• 错误统计表已填写
• 已确认读完文章最后一行

修复阶段

• 所有 Must Fix 已修复
• 修复是精确的文本替换（未引入新错误）
• 修复后不需要重新审查（改动是确定性的）

7. 推荐补充资源