writing_with_ai

上一篇讲了怎么上手 Claude Code、怎么安装配置。这篇是系列第 5 篇，Paul 进了一步，把话题转向了更难的问题：怎么用 AI 辅助写作和思考，但不把思考本身交出去。他分享了几个他自己在用的方法——构建个人写作风格指南、用 DAG 把审稿意见整理成有序修改方案、让 AI 做注释编辑而不是代写。这个核心张力，对做研究的人来说比“怎么装软件”更值得反复琢磨。

关于原作者

Paul Goldsmith-Pinkham 是耶鲁大学管理学院（Yale School of Management）金融学副教授，美国国家经济研究局（NBER）研究员，在哈佛大学获得商业经济学博士学位，研究方向涵盖消费金融、应用计量经济学和社会网络。他最知名的论文 “Bartik Instruments: What, When, Why, and How” 发表在 American Economic Review 上，被引用超过 3400 次。在学术研究之外，他是经济学界推广 AI 编程工具的标杆人物。他的 Substack 专栏 “A Causal Affair” 拥有超过 3000 名订阅者。

以下为原文的中文翻译

用 LLM 写作是个有争议、也挺复杂的话题。我打算从研究者的角度来谈——包括怎么产出研究想法、怎么表达研究成果，以及怎么把分析转化成文字。写作的用途很广，在讲具体操作之前，我想先说两个前提。

写作本身就是思考

写作往往就是我们思考和消化想法的过程。 对于写作者来说，把文字落在纸上，本身就是理清思路的方式。有一个合理的担忧是：当我们用 LLM 辅助写作时，很容易陷入所谓的认知卸载（cognitive offloading）——把思考这件事本身也外包出去。你有几个模糊的想法，扔给 LLM，让它替你做智识上的工作。这个担忧是有道理的。

从这个认识出发倒推，逻辑就清晰了。我们需要把想法想透，因为最终会有人问，我们得能说清楚。那怎么尽量避免无意识地、或者有意识地把这部分认知工作卸载给 AI？我没有完美的答案，但后面会提几个具体的策略。

语气的同质化

LLM 在体育界会被叫做“提下限的选手”——它能显著改善比较糟糕的写作。 但与此同时，确实存在一种合理的担忧：LLM 会产生一种同质化的默认腔调，读起来无聊，甚至让人尴尬。

有一种观点认为，这种同质化会拉低整体写作质量。这一方面是个社会问题——我们真的需要更多力量推动写作的统一化吗——但更个人层面，有自己的语气很重要。不，这是作为学者的人格的一部分！ 你作为学者，要有意识地认识自己的语气，并努力保留它。

在 AI 的语境下，我们会讲到写作风格指南，但说实话，要通过这些工具完美保留自己的写作语气，挑战相当大，达不到原来的效果。某些方面可能接近，但我们都是人，每天状态都不一样，输出不会稳定反映你今天想怎么写这件事。我们用来训练和校准这些工具的语料，质量取决于我们提供的信息，而我们一直在变化。今天想要的写作风格，可能和以前不一样。

枯燥但必要的写作

写作是思考的重要载体，但在工作中，我们也有大量纯粹枯燥、让人痛苦的写作。想想套话满满的邮件、备忘录总结、常规文档，甚至回归系数的初始写法。有些需要仔细处理，但第一遍草稿可以做得很快，帮你快速起步。

我的判断是，LLM 在这类工作上相当好用，省下来的时间非常有价值。真正的关键在于，找到枯燥写作和重要写作之间的那条线。你能卸载的枯燥工作越多，留给重要内容的思考时间就越多。 但如果把太多重要的部分也卸载出去，就会出问题。

输进 LLM 的是什么

第一篇文章里讲过，LLM 从根本上是一台文本机器。它读取并预测序列化文本，在上下文窗口里运作。

这对写作意味着什么？输给 LLM 的是文本。LLM 是一台在极高维空间里运行的强大文本预测机器，我们通过改变上下文窗口在这个空间里移动。改变提示词会稍微调整模型的关注点，让它以某种特定方式进行推理——也许更接近你处理问题的方式。但这不等于它一定能抓住正确的东西。

构建写作风格指南

这个练习相当直接。我们要做的是：基于自己的写作，构建一个风格指南——本质上就是一个 Skill。它会生成一份规则清单，告诉 LLM 该如何调整输出。它不一定能完美捕捉你的语气。打个比方：你把一个复杂的、多面向的人投影到墙上，会捕捉到某些方面，但问题是捕捉的对不对。

具体怎么做：

1. 收集你满意的写作样本。 论文、备忘录、邮件——凡是你觉得“对，这就是我的风格”的东西。不需要完全有代表性——我用的是自己的论文，虽然都是合著的——但样本越丰富越好。
2. 让 LLM 分析模式。 把写作样本给它，让它找出规律：句子长度、语气、用词选择、结构，你一贯会做的事，你从不做的事。
3. 把输出整理成 writing_style.md 文件。 LLM 的分析是起点，不是成品。你需要编辑它——删掉说错的，加上遗漏的，把规则说得更精准。
4. 在提示词里引用它。 当你想让 Claude 按你的风格写作或编辑时，指向这份风格指南。

另外，Claude 其实相当了解自己的能力。如果你对某类可重复任务感兴趣，可以直接问 Claude 怎么做——比如“我想能够反复做 X、Y 或 Z”——它大概知道该怎么设置。甚至不用真的动手，问一下它就会告诉你要做什么。

实际演示是什么样的

在视频里，我用 Claude Cowork 做了现场演示。如果你记得第一篇视频，Claude 应用里有三个不同的东西：Chat、Cowork 和 Code。Cowork 是命令行版 Claude Code 的应用版本——对于写作任务，我觉得它作为第一遍处理很好用。我不想让大家觉得一定要在命令行里操作才能用上这些工具。

我把 Cowork 指向了我的个人网站仓库——里面有我的学术论文和博客文章——然后给了一个刻意写得不太精确的提示词：

我希望你读取 papers 文件夹里的论文，以及我博客上的博文，为 Claude 创建一个写作风格指南 Skill，让我能在想要的时候让 Claude 按我的风格写作。

正如我跟 Markus 说的，这是个相当糟糕的提示词——没有清楚说明我想要什么。Opus 启动了一个子智能体来读博文和论文（只读了几篇，部分原因是不想把上下文窗口撑爆），然后在 .claude/skills/paul-voice/skill.md 创建了一个 Skill 文件。

这个风格指南没什么神奇的。说实话，还有点简单粗暴？它就是一个 Markdown 文件——带标题和列表的文本文件。当你使用这个 Skill 时，这些文本就被直接塞进上下文里。本质上就是让人来总结你的写作方式。

它产出了什么

对我的写作风格，这份指南给了一个相当正面——甚至可以说是肉麻——的解读。每个人，哪怕是世界上最糟糕的研究者，都会得到一个相对正面的评价。就像人们说给下属的反馈应该是“汉堡结构”——好评、批评、好评——这里连夹心的批评都没有。你得使劲推，Claude 才肯说负面的东西。

但推着让它说负面反馈，值得吗？这取决于情况。如果你有写作上的习惯性表达，而且觉得那正是你风格的体现，那就值得保留。Nabokov 给《纽约客》编辑写信时有句话说得很好：

你可以认为那是糟糕的写作风格，但那反映了他对自己写作的期望。

写作上的某些癖好，正是我们语气的一部分。

Markus 还问：这能用在英语以外的语言吗——德语、法语？当然可以。Claude 的多语言能力相当强。我经常用法语写作，输出质量很好。不是每种语言都一样，但在很多语言里会表现得相当不错。

有无风格指南的输出对比

为了展示差别，我让 Claude 向博士生听众解释差分中差分（difference-in-differences）方法两次——一次不带风格指南，一次带上我的写作 Skill。

不带风格指南的版本已经很不错了——Opus 写这类东西的能力真的令人惊叹。带风格指南的版本有些不同：它从实际问题出发，先建立二乘二的例子，然后才进入回归分析。这确实更接近我处理问题的方式。不过坦白说，感觉有点像对我写作风格的漫画——我觉得很多人用这类工具都有这种感受。做出来的 Skill 有你的影子，能认出来，但有点夸张。

这里要强调一点：当人们谈论 Skill 和风格指南时，一定要清楚，它就是一份规则清单。仅此而已——就是塞进上下文窗口里的文本。

Markus 随后建议我们试试让 Claude 用陀思妥耶夫斯基的风格解释差分中差分。

完全过头了，就是一幅漫画。但这正好说明了同样的事情——只是更明显而已。

更完善的风格指南长什么样

演示版只用了几篇论文来构建。我日常在用的风格指南要详细得多——因为我让 Claude Code 迭代了更多论文，做了更多工作。它有更具体的写作模式：用从句，我经常用破折号，把系数转化成美元数值来讨论经济意义。还有政策意义和经济意义的分解——这是一份比演示版大得多的规则清单。

我会把我完整的风格指南链接出来，供大家参考一个更成熟的版本。里面还有我各类段落开头的写法例子。思路和演示版一样——只是更详细。不一定完美，但对我有用。

从实践中学到的几点：

• 它更像是“规则清单”，而不是“语气捕捉”。 把风格指南理解为一组约束，把 LLM 的输出往更好的方向推，而不是对你语气的完美再现。带风格指南比不带好，但不会听起来完全像你。
• 要不断迭代。 第一版风格指南会有很多遗漏。用着用着发现问题，就回去加规则。它是一份活文档。
• 可能需要多份指南。 我有一份写论文用的，一份写社交媒体和博客用的，对应我不同的表达风格。社交媒体那份，回头读起来说实话有点肉麻。

审稿报告与战略性修改 Skill

这部分涉及两件相关的事：让 Claude 写审稿报告（针对你自己的论文，用于自我评估），以及用一个 Skill 来处理你收到的审稿意见，规划修改方案。

写审稿报告

我不是建议你让 Claude 帮你写期刊的审稿报告。我用这个 Skill 是为了评估自己的论文，或者在不是正式审稿人的情况下，想快速给朋友的论文一些反馈。在那些本来根本不会给反馈的情况下，我能更快聚焦到我通常会关注的问题上。让 Claude 先总结和评估论文，作为第一步是有帮助的。

构建审稿报告 Skill，我把 Claude 指向了我自己过去写的审稿报告文件夹：

请读取这个文件夹里所有我写的审稿报告。我想让你构建一个 Skill，能生成看起来像这些报告的反馈——重点放在我通常关注的问题类型上。

这和风格指南是同一个模式：给它你满意的输出样本，让它提取规律，把结果保存为可复用的 Skill。

Markus 问这和 Ben Golub 做的 Refine.ink 有什么区别。区别挺有用的：Refine.ink 做的是确保内部一致性——论文的论断是否与结果一致、结果是否可信。它不太涉及对论文应该长什么样的品味偏好。而审稿报告则是识别真实问题和品味偏好的混合体。

战略性修改 Skill

有一个叫做**战略性修改（strategic revision）**的 Skill，来自 Aalto 大学的 Jukka Sihvonen，我非常喜欢。它的作用是：你投了一篇论文，收到了一组审稿意见和编辑信。基于这些，如何制定修改方案？

我喜欢它的原因在于它能做到：

• 根据审稿报告生成一组需要完成的任务
• 识别这些任务的顺序、冲突和优先级

这个很有帮助，因为即使你读了审稿意见，也常常会感到不知所措——特别是有四份报告要应对的时候，到底该做什么。它把所有东西整理成一份总文档。

具体来说，这个 Skill 的描述是：“使用 NetworkX 进行计算 DAG 验证，从同行评审报告中创建严格的依赖关系图修改总计划。”翻译成人话就是：

1. 把每条审稿意见解析成一个独立任务。 每个具体的点都被提取出来并编号。
2. 对每个任务分类。 有些是论证性的——就是要写文字。有些是实证稳健性检验。还有澄清说明和编辑决策。
3. 构建依赖图。 用 DAG（有向无环图）来搞清楚哪些任务依赖哪些。DAG 表达的是 X 影响 Y、Y 依赖 X 的关系。因为是有向图，可以用网络理论检查是否存在环——有环就意味着依赖结构搞错了。它实际上需要用 Python 跑一个验证器，如果 Skill 的依赖包不可用，Claude 会自己写一个验证器。
4. 把任务组织成执行批次。 A 批和 B 批可以并行，但 C 批需要等前两批都完成。会输出这些批次的可视化图示。
5. 识别审稿人之间的冲突。 如果有多位审稿人——Markus，你肯定遇到过——他们对该怎么改会有分歧。这个 Skill 会找出这些冲突并标记：如果你做了 X，审稿人 Y 可能会不高兴。
6. 识别附带风险。 什么依赖什么，每个改动的连锁影响是什么。

为了演示，我拿了一篇已经发表的论文（这样不用担心泄露），让 Claude 先写一份审稿报告，然后把论文和生成的审稿报告一起喂给战略性修改 Skill。

输出是一个 26 个任务的修改方案，分成五个执行批次。它识别出了关键路径、核心瓶颈，以及哪些任务可以并行。甚至提出了合著者如何分工。展示任务依赖关系按批次组织的可视化图示是我觉得最有用的部分。你基本上可以把这些任务拷贝出来说“好，现在我们需要完成这些任务”，然后把它们组织成具体的问题来处理。

有一点要说清楚：在如何使用这些东西上，你仍然需要大量自己的判断。记得我们说过，对 LLM 来说，具体和明确非常重要。有一组明确的任务——就像和 RA 合作一样——之后在各个步骤上与 LLM 合作就容易得多了。

Markus 问这对理论论文的效果和实证论文一样好吗？我两种都用过，觉得都不错。某种程度上理论论文反而更好——你知道哪个证明依赖哪个，依赖结构更清晰。实证论文涉及太多品味判断，需要更多来回权衡。

显然这不是终极解决方案。这个 Skill 还有很多可以改进的地方——我到现在只用在两篇论文上。但我最喜欢它的一点是：它努力把任务变得可操作，对任务分类，并且搞清楚依赖关系。

你可以在 Claude 应用里安装这个 Skill：进入管理 Skills，添加 Skill，上传 Markdown 文件。安装之后，在 Chat 和 Cowork 里都可以用。

让 LLM 做编辑，而不是代写

AI 的写作可能有一些奇怪的习惯表达，但它是一个不错的编辑。它不需要重写你的文字，但 LLM 能解释它为什么认为某处推理或表达有问题。这样既能防止认知卸载，又能用上 LLM 强大的推理能力。

举个例子。我拿了我的一篇博文——用博文是因为它更短、更简单，换成研究论文道理是一样的——给它这样的提示词：

请看这篇博文。我想以《纽约时报》编辑的风格对写作和表达清晰度给出修改建议。但不要直接修改我的文字。请在我论证薄弱或表达不清晰、需要改进的地方，以内嵌注释的形式添加批注。

它产出的是原始文字保持完全不变，但在特定位置插入了 Markdown HTML 注释。渲染出来看不到——它没有改任何东西。但你会得到标注，就像编辑做的那样。

我觉得这很有用，因为如果你想保留自己的语气，这正是你想要的编辑风格。如果有人把改法直接告诉你——如果你是研究生，有时你会很乐意接受——但自己的语气就更难保住了。只有注释，你就被迫主动参与到反馈里。 你读每条注释，自己决定该怎么做——重写这句话、删掉它，还是不同意就不改。¹

Markus 建议说，也可以让它在注释旁边附上改法。这也行——有时它会主动这样做。但危险在于你很容易就直接接受了改写版本。有时我会把那段具体文字拷出来问“我该怎么处理这里？”我们不总是有无穷的精力思考写作，所以有选项是好事。但只有注释的方式，能让你保持更高的参与度。

一个实际注意事项：这个操作需要在 Cowork 或 Claude Code 里做，不能在 Chat 里做，因为它需要读取和编辑你电脑上的文件。你可以把文档上传到 Chat 让它做同样的事，但在 Cowork 里效果更好，因为它用的是你的本地文件系统，还能用你已经安装的所有 Skill。Chat 是在云端创建一个计算环境来完成同样的任务，文件和 LLM 之间的距离越远，问题就越多。

用 LLM 推进想法

有几个模糊的想法，很容易就扔给 LLM，让模型替你做智识上的工作。我想推荐的方式，跟第一篇文章里讲上下文窗口时类似：要有意识地做压缩和笔记，来迭代想法。

• 先把想法自己迭代，再去找 LLM 谈。 在跟 LLM 交流之前，尽量把想法自己想透，因为具体性会带来巨大价值。如果我说“嘿，我想想一个关于储蓄的生命周期模型”——你不会得到什么突破性的想法。越具体，越好。
• 加载更多上下文。 用 Claude Code 或 Cowork 而不是普通聊天窗口的一个重要原因，是你可以往 LLM 里加入更多文件和上下文。你可以说：“看，我在这个文件夹里。这是一堆和我感兴趣的话题相关的论文。这是一些笔记。这是一些幻灯片。这是和这个政策相关的一些网站。这是我们在想的东西。从这里出发。”你能给的信息越多越好。
• 也可以用“页边注”的方式。 不要问“我该写什么？”而是让 LLM 对你已经写的东西发表评论。

这又回到了开头说的“写作即思考”。目标不是避免用 LLM 做智识工作——而是在用它的同时保持自己在智识工作中的参与。 永远记住这张图，1977 年 IBM 培训手册里那张著名的图：

核心要点

1. 写作就是思考。 要有意识地区分什么可以外包，什么要自己来。检验标准是：不靠 LLM，你能深入讨论这些想法吗？
2. 风格指南有用，但不会完美。 要不断打磨、持续迭代——但永远不会完美。说到底，Skill 是对你的某种总结，在某些方面是漫画式的，但是有用的。它是一个反映你的回声板——就像以你的口吻替你开口的替身。²
3. 枯燥写作是最容易的突破口。 套话邮件、第一遍草稿、常规文档——这类帮助对个人来说真的很大。最大的价值不是让 AI 替你做，而是给你一个非常好的初稿。
4. 战略性修改 Skill 相当好用。 把一堆审稿报告变成一份有结构、有依赖关系、有优先执行批次的修改方案——还有很多其他值得探索的 Skill，但这个能把审稿意见变得可操作，而不只是令人不知所措。
5. 要注释，不要代写。 这是我找到的一种防止自己写出太多 LLM 腔的方式——在我真的想保留自己语气的场合。这是一种让你保持参与感的编辑方式。
6. 先想，再用 AI 写。 在跟 LLM 交流之前，尽量把想法自己想透。具体性带来巨大价值。加载尽可能多的上下文。

下一步

这是个很有争议的话题，但我确实认为这里有很多价值，特别是在你想推动事情进展、快速起步的时候。下一篇，我们会做更多定制化的内容——聊 Skill、容器，以及怎么在所谓的 YOLO 模式下操作，也就是让 Claude 在不需要我们确认的情况下自主运行。

原文信息

• 原文标题：Writing & Thinking with AI Assistance
• 作者：Paul Goldsmith-Pinkham
• 发布日期：2026 年 4 月 12 日
• 原文链接：https://paulgp.substack.com/p/writing-and-thinking-with-ai-assistance
• 配套视频：Markus Academy 系列视频第 5 集（链接待补充）
• 版权声明：原文版权归 Paul Goldsmith-Pinkham 所有，本译文仅供学习交流，如需转载请联系原作者获取授权。