Claude Code 写长文档的保存和修改方法

你在终端里随口丢了一句“帮我优化一下这篇技术笔记”。改稿读起来顺多了，可原文里谨慎写下的“本方案当前存在内存泄漏隐患，暂不建议用于生产环境”，被它热心地改成了“强烈推荐用于生产”；文中还多了三四个从没验证过的案例。

更麻烦的是，你想找回原来那句话时，终端已经往上翻了几十屏，最早的版本早被冲没了。

这是 Claude Code 输出环节最常见的两个坑：

• 长结果只留在终端里，没法逐段修改、对比和撤销；
• 一句笼统的“优化”，让它顺手改掉了事实、限定和确定程度。

两个坑都出在“结果下一步怎么用”没想清楚。短回复拷走即可，长文档要落进文件，交给编辑器去通读、预览和比较版本；让它改稿时，先说清楚哪些能动、哪些不能动，拿回改稿后先核对边界条件和否定句，再看文笔。

01 出口跟着用途走

Claude Code 的回复可能只是临时引用，也可能还要反复修改、审查和发布。怎么取出结果，取决于接下来要怎么用它：

想法或资料
  → 选择合适入口
  → Claude Code 处理
  → 选择合适出口
  → 编辑、检查或发布

比如，把长篇结果只留在终端里，就很难逐段修改。终端适合讨论和下达指令，编辑器适合排版和通读全文。

02 短结果直接复制

想拷走上一条回复，敲个 /copy 就行：

/copy

它会尽量保留原始的 Markdown 格式。想复制更早的一条，用 /copy 2 取倒数第二条。同一条回答里有好几个代码块时，会弹出选择器让你挑其中一块或整条回复；在选择器里按 w，还能把选中的内容写进文件，通过 SSH 工作时很有用。这些行为见 Claude Code 命令参考。说明文、PR 摘要、草稿或审查意见，都可以这样随手带走。

在 macOS 上，也可以让 Claude Code 调用 pbcopy，把结果直接放进剪贴板：

请把最终版 PR 描述通过 `pbcopy` 放到剪贴板。

03 长结果先写进文件

内容还要继续修改、比较或审查时，先写入文件。在终端里上下翻几十屏核对长文档，既费力，也容易遗漏。超过两屏的长内容，第一时间落盘：

请把这段 PR 描述写入 `pr-description.md`，然后打开给我检查。

写进文件后，你可以在编辑器里定位段落、预览格式，结合版本管理比较和撤销改动。长文档、代码、配置、研究结果和正式 PR 描述都适合先落成文件。VS Code 中可以用 Markdown: Open Preview 检查渲染效果。

更新远端内容前，也可以先在本地文件里改好、查好：

读取远端内容
  → 写入本地 Markdown
  → 编辑与核对
  → 确认后更新远端

这样能在远端状态变化前发现错误，也保留了修改痕迹。

开头那个“找不回原句”的问题，原因在于文档经过多轮修改后，终端缓冲区已经丢了最早的版本。把草稿写进 deploy-doc.md，再通过 Git 提交或编辑器历史保存版本，之后就能比较和恢复。反复覆盖同一个文件，Git 不会自动替你存下每一版，所以预计还要反复修改的内容，从第一版起就写进文件并及时提交。

04 终端和编辑器并排写作

Claude Code 适合整理思路、讨论结构和执行局部修改；编辑器适合通读、定位和比较整篇文档。把两者并排放，写作过程就一直看得见：

左侧：Claude Code 终端
右侧：VS Code、Cursor 或其他编辑器

一条顺手的写作路径是：

口述或输入背景
  → Claude Code 整理为 Markdown 粗稿
  → 在编辑器中通读
  → 指定段落和问题
  → Claude Code 局部修改
  → 再次核对全文

第一版先保住具体内容，结构和表达放到后面处理。想保留自己的判断时，就限制 Claude Code 的改动范围：

下面是我用语音说的一段粗稿。请只整理结构和表达，不要扩展新观点。

发现重复总结或模板句时，给出具体的修改目标：

请保留具体信息，删除重复总结，不要在每一节末尾复述前文。

技术文档、课程材料、发布说明和研究笔记都可以这样处理。在编辑器里通读，在终端里指出要改的段落，讨论内容和文档位置就对得上。

05 改稿之前先划边界

回到那篇技术笔记。动笔前要把修改边界说清楚：允许调整行文结构、润色表达、修补错别字，核心观点、业务事实和确定程度一律保持原样。

请只调整结构、润色表达、修正错别字。
保留所有事实、数字、限定条件和否定句，不新增案例，不改变结论的确定程度。
改完后列出你改动过的句子。

拿到改稿后，第一件事是核对原文中的边界条件和否定句，看有没有为了行文顺畅而删掉或改掉重要内容，文笔通不通顺放到最后再看。“暂不建议用于生产”这类句子，正是读者最需要的信息，也最容易在润色时被抹平。

06 长请求的编辑快捷键

短请求直接在输入框里改就行；请求变长后，光标移动、误删恢复和外部编辑器会显著影响操作成本。

长 prompt 可以用 Ctrl+G 在外部编辑器中打开当前输入，保存关闭后回到终端，检查一遍再发送。编辑器由 EDITOR 决定，可以写进 ~/.claude/settings.json。下面的示例用 Vim，换成自己会用、并且能等编辑结束再返回的编辑器就行：

{
  "env": {
    "EDITOR": "vim"
  }
}

多行输入最通用的方法是输入反斜杠再回车（\ + Enter），在所有终端里都有效。iTerm2、WezTerm、Ghostty、Kitty、Warp 和 Windows Terminal 原生支持 Shift+Enter；其他终端可以运行 /terminal-setup 配置，macOS 打开 Option as Meta 后也能用 Option+Enter。完整列表见 Claude Code 交互模式文档。

粘贴图片的快捷键随终端变化：

Ctrl+V      Mac / Linux
Cmd+V       iTerm2
Alt+V       Windows / WSL

快捷键没有反应时，先确认终端是否拦截了这个按键。

07 从材料到成品，先画一条路径

判断用什么出口时，先画清三点：材料从哪里来，处理后去哪里，途中必须保留什么。材料怎样完整地进入会话，可以看Claude Code 读不到网页和视频时怎么办。

例如，一份带链接的内部会议记录要交给 Claude Code 整理，再写进 PR 描述：

获准访问的富文本记录
  → 脱敏并保留链接
  → 必要时经 Notion 转成 Markdown
  → Claude Code 整理
  → 写入本地 `pr-description.md`
  → 人工检查
  → 更新 PR

保留链接是为了追溯来源，写入文件是为了通读修改，更新 PR 是检查之后的事。如果记录不允许进入 Notion，就省掉中转，在获准的工具里整理成 Markdown；如果只需引用一句话，检查后直接复制就行。PR 描述里要写进哪些审查信息，可以参考核对 AI 审查结论的做法。

高频选择可以简化为一张表：

处理任何材料时，都先想清楚结果下一步要被谁、怎样检查和修改，再选格式和工具。那篇技术笔记如果一开始就写在文件里、改稿前划好了边界，那句“暂不建议用于生产”就不会悄悄消失。