paper-parallel-audit

Name: paper-parallel-audit
Author: Lambenthan

19stars0forks

How to install paper-parallel-audit?

lambenthan/paper-discipline-skills/paper-parallel-audit

$npx -y skills add Lambenthan/paper-discipline-skills --skill paper-parallel-audit

Installs into the current project.

Summary

在执行 ≥ 30 条目的批量核查 / 批量修改任务（引用核查、术语一致性检查、格式统一、文献元数据补齐）时，必须采用"派多个 Agent 并行 + 每个 Agent 输出 JSON + 主进程汇总落盘 + 分批断点续跑"的标准模式，不得在主会话里串行单线程跑全量。 Use when 任务规模 ≥ 30，涉及对独立条目的同质操作（每个条目处理逻辑相同、之间无依赖）。

Files · 1

View on GitHub

SKILL.md

1	# paper-parallel-audit：大批量核查的并行 Agent 模式
2
3	## 核心理念
4
5	156 篇引用串行核查 ≈ 5 小时 + 中间挂了从头来。
6	3 个 Agent 并行 + 每个 50 篇 + JSON 落盘 ≈ 1 小时 + 任意一个挂了只重跑那一个。
7
8	> 批量任务的瓶颈不是 AI 的速度，是"挂了从头来"的恐惧。
9	> 并行 + 落盘 = 把恐惧拆成可控的小块。
10
11	---
12
13	## 触发条件
14
15	满足全部 → 触发：
16
17	- 任务规模 ≥ 30（条目 / 引用 / 文件 / 段落）
18	- 各条目之间无依赖（核查 A 的结论不影响 B 的核查）
19	- 操作是同质的（每条用的方法 / 标准都一样）
20	- 已经通过 `paper-pilot-before-batch` 跑过样本，逻辑确认无误
21
22	任意一条不满足 → 不并行，老老实实串行 + 落盘（仍然要落盘）。
23
24	---
25
26	## 标准模式（4 个组件，缺一不可）
27
28	### 组件 1：分片
29
30	```
31	total = 156 条
32	shard_size = 50（按 Agent 数倒推）
33	shards = [0:50, 50:100, 100:156]
34	```
35
36	### 组件 2：每个 Agent 独立输出 JSON
37
38	每个 Agent 处理自己的分片，输出：
39
40	```json
41	{
42	"shard_id": "0-50",
43	"total": 50,
44	"results": [
45	{"item_id": 1, "status": "pass", "issue": null},
46	{"item_id": 2, "status": "fail", "issue": "作者名拼写错误", "suggestion": "..."}
47	],
48	"completed_at": "<ISO 8601 timestamp>"
49	}
50	```
51
52	### 组件 3：主进程汇总 + 落盘
53
54	```bash
55	# 等所有 Agent 返回后
56	python merge_shards.py shard-*.json > audit_report.json
57	```
58
59	### 组件 4：断点续跑
60
61	- 每个 Agent 跑完立即落盘 JSON 到磁盘
62	- 任何一个挂了，只重跑那个分片
63	- 主进程读已有 JSON，跳过已完成
64
65	---
66
67	## 强制流程
68
69	```
70	检测到 ≥ 30 条目的同质批量任务
71	│
72	▼
73	确认已经跑过 paper-pilot-before-batch
74	│
75	▼
76	分片：N 个 Agent，每个 ≤ 50 条
77	│
78	▼
79	告诉用户：「派 N 个 Agent 并行，每个负责 [区间]，
80	各自落盘 JSON。预计 [时间]，挂了只重跑挂掉的分片。」
81	│
82	▼
83	用 Task 工具派 Agent（subagent_type 选 general-purpose）
84	单条消息里多个 Task 调用 = 真正并行
85	│
86	▼
87	等所有 Agent 返回 → 汇总 JSON → 给用户报告
88	```
89
90	---
91
92	## 派 Agent 的标准 prompt 模板
93
94	```
95	你是引用核查 Agent，负责本批 [分片区间]。
96
97	任务：核查每条引用的 [核查标准列表]。
98	输入：[引用列表 / 文件路径]
99	输出：JSON 文件，路径 `shard-<分片 ID>.json`，格式：
100	{
101	"shard_id": "...",
102	"total": N,
103	"results": [
104	{"item_id": ..., "status": "pass\|fail", "issue": "...", "suggestion": "..."}
105	],
106	"completed_at": "..."
107	}
108
109	完成后只返回一句话：「分片 X 完成，pass M 条，fail K 条，已落盘 shard-X.json」。
110	不要把详细结果写在回复里——一律只在 JSON 里。
111	```
112
113	---
114
115	## ❌ 反例（书 §10.2）
116
117	用户：「把这 156 条引用核查一遍。」
118
119	错误做法：在主会话里串行跑——
120
121	- 跑到第 80 条 rate limit 了
122	- claude --continue 接续，但中间结果在内存里没存
123	- 重跑要么从头来，要么人工记到第几条
124	- 用户的耐心已经磨没了
125
126	正确做法：分 3 片 → 派 3 个 Agent → 各自 JSON 落盘 → 主进程汇总 → 用户拿到完整报告。
127
128	---
129
130	## "不要并行" 的情况
131
132	- 条目之间有依赖（B 用 A 的结论）→ 串行 + 落盘
133	- 任务规模 < 30 → 直接串行更省心
134	- 操作不同质（每条要不同处理）→ 一个 Agent 全包
135
136	---
137
138	## Rationalization Table
139
140	\| 念头 \| 现实 \|
141	\|---\|---\|
142	\| "派 Agent 太重，自己串行更直接" \| 串行第 80 条挂掉时你会回来读这个表 \|
143	\| "我能边跑边把结果记在脑子里" \| 你不能。这是惨案 9 的根因 \|
144	\| "JSON 太麻烦，纯文本 markdown 就行" \| 汇总时要 dedupe / 排序 / filter，markdown 干不了 \|
145	\| "派 1 个 Agent 跑 156 条也是并行" \| 不是，那只是把串行搬到了子进程里，还是从头来 \|
146	\| "落盘的 JSON 占空间" \| 一个 shard JSON 几 KB，挂了能省小时级时间 \|
147
148	---
149
150	## Red Flags
151
152	- 你正打算 for 循环 156 次 Edit → 停
153	- 你想"主会话直接核查，写个 todo 记进度" → todo 不是落盘
154	- 你跑到第 N 条挂了，想凭记忆接着第 N+1 条 → 不行，从最近一次落盘点重启
155	- 多个 Task 调用分散在多条消息里 → 不是并行，重写成单消息多调用
156
157	---
158
159	## 配套 skill
160
161	- 触发前必须先 `paper-pilot-before-batch`
162	- 修改性操作还要 `paper-protect-terminology`
163	- 完成后用 `paper-verify-before-handoff` 自查报告
164
165	---
166
167	## 来源
168
169	《Claude Code 科研手记》§4.2「批量文献核查」、§10.2「引用核查的并行实战」

People who liked this also viewed

6 picks

Type

paper-parallel-audit

19stars0forks

View on GitHub

How to install paper-parallel-audit?

lambenthan/paper-discipline-skills/paper-parallel-audit

$npx -y skills add Lambenthan/paper-discipline-skills --skill paper-parallel-audit

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# paper-parallel-audit：大批量核查的并行 Agent 模式
2
3	## 核心理念
4
5	156 篇引用串行核查 ≈ 5 小时 + 中间挂了从头来。
6	3 个 Agent 并行 + 每个 50 篇 + JSON 落盘 ≈ 1 小时 + 任意一个挂了只重跑那一个。
7
8	> 批量任务的瓶颈不是 AI 的速度，是"挂了从头来"的恐惧。
9	> 并行 + 落盘 = 把恐惧拆成可控的小块。
10
11	---
12
13	## 触发条件
14
15	满足全部 → 触发：
16
17	- 任务规模 ≥ 30（条目 / 引用 / 文件 / 段落）
18	- 各条目之间无依赖（核查 A 的结论不影响 B 的核查）
19	- 操作是同质的（每条用的方法 / 标准都一样）
20	- 已经通过 `paper-pilot-before-batch` 跑过样本，逻辑确认无误
21
22	任意一条不满足 → 不并行，老老实实串行 + 落盘（仍然要落盘）。
23
24	---
25
26	## 标准模式（4 个组件，缺一不可）
27
28	### 组件 1：分片
29
30	```
31	total = 156 条
32	shard_size = 50（按 Agent 数倒推）
33	shards = [0:50, 50:100, 100:156]
34	```
35
36	### 组件 2：每个 Agent 独立输出 JSON
37
38	每个 Agent 处理自己的分片，输出：
39
40	```json
41	{
42	"shard_id": "0-50",
43	"total": 50,
44	"results": [
45	{"item_id": 1, "status": "pass", "issue": null},
46	{"item_id": 2, "status": "fail", "issue": "作者名拼写错误", "suggestion": "..."}
47	],
48	"completed_at": "<ISO 8601 timestamp>"
49	}
50	```
51
52	### 组件 3：主进程汇总 + 落盘
53
54	```bash
55	# 等所有 Agent 返回后
56	python merge_shards.py shard-*.json > audit_report.json
57	```
58
59	### 组件 4：断点续跑
60
61	- 每个 Agent 跑完立即落盘 JSON 到磁盘
62	- 任何一个挂了，只重跑那个分片
63	- 主进程读已有 JSON，跳过已完成
64
65	---
66
67	## 强制流程
68
69	```
70	检测到 ≥ 30 条目的同质批量任务
71	│
72	▼
73	确认已经跑过 paper-pilot-before-batch
74	│
75	▼
76	分片：N 个 Agent，每个 ≤ 50 条
77	│
78	▼
79	告诉用户：「派 N 个 Agent 并行，每个负责 [区间]，
80	各自落盘 JSON。预计 [时间]，挂了只重跑挂掉的分片。」
81	│
82	▼
83	用 Task 工具派 Agent（subagent_type 选 general-purpose）
84	单条消息里多个 Task 调用 = 真正并行
85	│
86	▼
87	等所有 Agent 返回 → 汇总 JSON → 给用户报告
88	```
89
90	---
91
92	## 派 Agent 的标准 prompt 模板
93
94	```
95	你是引用核查 Agent，负责本批 [分片区间]。
96
97	任务：核查每条引用的 [核查标准列表]。
98	输入：[引用列表 / 文件路径]
99	输出：JSON 文件，路径 `shard-<分片 ID>.json`，格式：
100	{
101	"shard_id": "...",
102	"total": N,
103	"results": [
104	{"item_id": ..., "status": "pass\|fail", "issue": "...", "suggestion": "..."}
105	],
106	"completed_at": "..."
107	}
108
109	完成后只返回一句话：「分片 X 完成，pass M 条，fail K 条，已落盘 shard-X.json」。
110	不要把详细结果写在回复里——一律只在 JSON 里。
111	```
112
113	---
114
115	## ❌ 反例（书 §10.2）
116
117	用户：「把这 156 条引用核查一遍。」
118
119	错误做法：在主会话里串行跑——
120
121	- 跑到第 80 条 rate limit 了
122	- claude --continue 接续，但中间结果在内存里没存
123	- 重跑要么从头来，要么人工记到第几条
124	- 用户的耐心已经磨没了
125
126	正确做法：分 3 片 → 派 3 个 Agent → 各自 JSON 落盘 → 主进程汇总 → 用户拿到完整报告。
127
128	---
129
130	## "不要并行" 的情况
131
132	- 条目之间有依赖（B 用 A 的结论）→ 串行 + 落盘
133	- 任务规模 < 30 → 直接串行更省心
134	- 操作不同质（每条要不同处理）→ 一个 Agent 全包
135
136	---
137
138	## Rationalization Table
139
140	\| 念头 \| 现实 \|
141	\|---\|---\|
142	\| "派 Agent 太重，自己串行更直接" \| 串行第 80 条挂掉时你会回来读这个表 \|
143	\| "我能边跑边把结果记在脑子里" \| 你不能。这是惨案 9 的根因 \|
144	\| "JSON 太麻烦，纯文本 markdown 就行" \| 汇总时要 dedupe / 排序 / filter，markdown 干不了 \|
145	\| "派 1 个 Agent 跑 156 条也是并行" \| 不是，那只是把串行搬到了子进程里，还是从头来 \|
146	\| "落盘的 JSON 占空间" \| 一个 shard JSON 几 KB，挂了能省小时级时间 \|
147
148	---
149
150	## Red Flags
151
152	- 你正打算 for 循环 156 次 Edit → 停
153	- 你想"主会话直接核查，写个 todo 记进度" → todo 不是落盘
154	- 你跑到第 N 条挂了，想凭记忆接着第 N+1 条 → 不行，从最近一次落盘点重启
155	- 多个 Task 调用分散在多条消息里 → 不是并行，重写成单消息多调用
156
157	---
158
159	## 配套 skill
160
161	- 触发前必须先 `paper-pilot-before-batch`
162	- 修改性操作还要 `paper-protect-terminology`
163	- 完成后用 `paper-verify-before-handoff` 自查报告
164
165	---
166
167	## 来源
168
169	《Claude Code 科研手记》§4.2「批量文献核查」、§10.2「引用核查的并行实战」

People who liked this also viewed

6 picks

Type