1
先想一想
使用推理模型来诊断审稿人的担忧并编写计划。
Plan-Gated Paper Revision Skill
一个干净且轻微戏剧化的起源聊天，解释了如何使 AI 辅助的手稿修订受控、可追溯且不那么混乱。
用一句话表达这个想法
不要让 AI 特工同时思考、编辑、验证和解释。 首先将推理强制写入 Markdown 计划，然后让编辑代理仅执行该批准的计划。
2
门编辑
没有计划，没有手稿更改。该计划是编辑边界。
3
验证真相
编译，检查 PDF，然后使用经过验证的位置更新响应信。
4
提交历史
每个接受的工作包都会成为一个干净的 Git 步骤，可以进行审查或回滚。
清理原始聊天记录
这是原始聊天的可读、翻译和简单阐述的版本 Chen Miao 和 Feifei Robbie。无关的历史玩笑已被删除。这个有趣的类比之所以被保留，是因为它抓住了架构：战略家、执行者和人类指挥官。
Chen Miao
我曾经有一个使用 AI 修改论文的工作流程。关键是要保持流程的线性，否则整个修改就会变得混乱。
首先，将提交的版本保留为 original_main.tex。工作文件仍然被称为 main.tex。然后让agent生成 redlined_main.tex。即使没有提交红线，它对于检查发生了什么变化也非常有用。
C
R
Feifei Robbie
那么基线被冻结，当前稿件保持相同的文件名，并且红线是自动生成的？
Chen Miao
正是如此。然后请AI先起草回复信。逐个审稿人的评论。先了解响应逻辑，然后让AI制定稿件修改计划，保存为Markdown，检查后才执行。
以这种方式循环浏览所有评论。还要编写一个构建脚本，自动编译最新的稿件、最新的回复信和红线版本。
C
设计注意事项： 回复信不是事后的想法。这是修订版的逻辑图。如果无法对答复进行辩护，则手稿编辑可能尚未准备好。
Chen Miao
在每次有意义的编辑之前，创建一个 Markdown 计划。把它放在下面 references/。后来，当你想知道为什么要改变某些东西时，原因就在那里。代理还可以读取这些文件并了解历史记录。
没有计划，你只有结果，而没有思考过程。
C
R
Feifei Robbie
您的意思是每个审阅者问题一个 Markdown 文件，还是一个不断附加整个过程的文件？
Chen Miao
通常有很多文件。每个文件对应于当前的修订包。例如： reviewer1_comment1_revision1.md, figure4_caption_shorten_plan.md, 或 main_text_shorten_plan.md.
大小是动态的。一份计划可以涵盖一个小段落、一个图形标题、一个审稿人评论或一个全局缩短通行证。但计划和执行应该是一一对应的。
C
R
Feifei Robbie
所以你所说的“回合”并不是每一条微小的 Codex 消息。是我们真正让Codex执行工作包的那一刻吗？
Chen Miao
是的。这正是您交给 Codex 并说：应用这个的包。
如果代理觉得该计划很容易，就让它执行。如果看起来太困难，请将计划分成更小的计划。您通常可以从计划质量判断代理商是否陷入困境。
C
实用规则： 如果计划听起来很模糊，那么编辑也可能会变得模糊。在执行前分割，而不是在稿件损坏后分割。
R
Feifei Robbie
该计划是来自您、来自 ChatGPT 还是来自 Codex 本身？
Chen Miao
他们谁都可以制作，但最终的方案必须是我认可的。 Codex 擅长编辑文件、修复 LaTeX 和编译。但它在决定为何以及如何修改科学和措辞方面较弱。
所以我经常向ChatGPT询问修改策略，将其保存为Markdown，然后让Codex应用它。
知识：ChatGPT。技术执行：Codex。
C
R
Feifei Robbie
如果计划执行了但结果不理想，需要小幅调整怎么办？您是否为每一个微小的调整创建一个新的 Markdown 文件？
Chen Miao
没有必要。重要的是不要记录每一条微小的聊天消息。重要的是，最终执行的计划是一个好的计划。
如果计划不好，就修改它、覆盖它，或者请另一个模型来改进它。但代理人应该受到最终计划的约束。核心是控制编辑范围。
C
Chen Miao
我发现，当代理在某项任务上能力不强时，它就会开始随机编辑。编辑得越多，就越混乱。但一旦我在编辑前使用了计划，整个过程就变得可控了。
它减轻了负担。代理无需同时考虑要更改什么以及如何编辑文件。
C
R
Feifei Robbie
那么你就像Zhuge Liang设置策略一样，而Codex是Zhao Yun去战场吗？
Chen Miao
正是如此。分而治之。让战略家专注于战略，让执行者专注于执行。
C
最终翻译： 人类仍然是指挥官。代理人可以策划、编辑、审核、编译，但不应该默默地决定科学方向。
作为操作系统的工作流程
该方法之所以有效，是因为它将混乱的修订转换为一系列小的、可验证的事务。
0
冻结基线
保留 original_main.tex 不变。继续努力 main.tex。自动生成红线。
1
起草响应逻辑
在接触稿件之前先了解审稿人真正关心的问题。
2
在references/下创建计划
该计划定义了允许的文件、允许的位置、禁止的更改、理由和验证。
3
人类批准或分裂
如果计划太宽泛，请将其拆分。如果清楚了，就执行它。
4
执行者仅应用该计划
Codex 编辑允许的文件并记录执行注释。
5
构建并检查 PDF
编写手稿和回复信。在声明页或行位置之前检查实际的 PDF。
6
同步回复信
回复信必须反映真实的稿件更改，而不是计划或想象的更改。
7
提交并推动
每个接受的工作包都会成为一个干净的 Git 检查点。
reviewer comment
→ response logic
→ references/reviewer1_comment1_revision1.md
→ human approval
→ edit main.tex only within the plan
→ compile main.pdf + response_letter.pdf
→ verify PDF locations
→ update response letter
→ generate redline
→ git commit + push代理角色
单个代理可以执行所有角色，但当角色分离时，工作流程会更加清晰。
策略代理
诊断审稿人的担忧，编写计划，控制语气，并决定是否拆分任务。不应直接编辑稿件。
执行代理人
读取批准的计划，编辑文件，编译LaTeX，生成红线，并记录所做的事情。它不应该随意重新解释科学。
审计代理
检查 PDF，验证页面/行引用，检查回复信的真实性，并确保编辑没有超出计划。
人类指挥官
批准计划，决定任务粒度，判断科学方向，接受或拒绝最终修改。
认知负荷分配
粗略的概念图：工作流程将硬推理从文件编辑时刻移出。
用于快速理解的表格
问题→技能机制
| 常见故障 | 计划门控解决方案 | 实用规则 |
|---|---|---|
| 代理变动太大 | 该计划定义了确切的允许文件和位置。 | 如果计划中没有，请勿编辑。 |
| 回复信夸大其词 | 仅在 PDF 检查后添加位置声明。 | 在手稿实际修改之前，切勿写“我们修改了”。 |
| 修订历史变得不清晰 | 每个工作包都有一个计划和 Git 提交。 | 一项计划，一项执行，一项提交。 |
| 大型任务使代理超载 | 总体计划在执行前被分割。 | 模糊的计划→分裂的计划。 |
| 新会话失去上下文 | 的 references/ 目录充当外部存储器。 | 在编辑之前让代理人阅读相关计划。 |
计划文件清单
| 计划部分 | 应该回答什么 |
|---|---|
| 来源评论 | 哪个审稿人/编辑评论或内部目标触发了此问题？ |
| 诊断 | 评论背后真正关心的是什么？ |
| 适用范围 | 哪些文件和位置可以更改？ |
| 禁止的更改 | 代理人应该明确避免什么？ |
| 提议的编辑 | 具体应该做哪些改变？ |
| 验收标准 | 我们如何知道编辑已完成？ |
| 验证 | 如何检查手稿、回复信、参考文献和红线？ |
两种修订模式对比
标准Codex指令
该提示将聊天理念转变为可执行的代理指令。
You are working on an academic manuscript revision.
First read the relevant plan in references/.
Do not edit anything outside the plan.
If the plan is too broad or vague, stop and propose a smaller plan.
Apply only the approved edits.
After editing, update the plan's Execution Notes.
Run the build command.
Inspect the generated PDF if available.
Update the response letter only with verified changes.
Generate redlined_main.tex when original_main.tex is available.
Show git diff summary.
Commit and push this work package.不说
“根据审稿人的意见修改论文。”
这太宽泛并且会导致不受控制的编辑。
说代替
“读 references/reviewer2_comment6_reanalysis_plan.md。仅应用批准的编辑。如果有任何超出范围的事情就停下来。”
这为代理提供了边界和验证路径。
如何在 GitHub 存储库中使用此页面
这个 HTML 页面可以起到两个作用：技能的起源故事和新用户的视觉教程。
paper-revision-agent-skill/
README.md
SKILL.md
docs/
origin-chat.html
templates/
revision_plan.md
response_trace_audit.md
revision_task_index.md
prompts/
plan_prompt.md
apply_prompt.md
audit_prompt.md建议的 README 链接
## Origin and tutorial
The workflow was derived from a real paper-revision discussion.
For a readable visual explanation, see:
- [Origin chat and guide](docs/origin-chat.html)发布说明
本页是有意编写的，经过清理和翻译的原始叙述，而不是原始的私人记录。它保留了技术方法、有用的幽默和设计经验，同时删除了不相关的讨论。