直播实录:职业写作者如何用 AI 写作

Every 的这场直播跟随作者 Katie Parrot 和编辑 Jack，展示他们处理同一篇文章的部分过程。Katie 依赖较丰富的文件夹、指南和审阅角色，Jack 则把自己比作追求轻装的徒步者，刻意保持编辑配置简洁。他们共有的方法不是一个完美提示词，而是一连串仍由人负责的判断。

直播也坦率地说明了局限：原定第三位参与者无法加入；Jack 编辑的是预先准备的稿件，不是 Katie 现场写出的那个开头；为了控制时间，一些常规检查只是说明或假设已做。它展示的是工作过程，并非现场完成一篇从构思到发布的完整成品。

保留这个区分，反而更容易学到东西：可以观察人在哪些位置介入、模型依据哪些文件和评论，以及哪些问题尚未解决，而不把现场输出误认为全部编辑工作已经完成。

Katie 为不同专栏保留独立的起草文件夹。在 style.md 中，她说明专栏是什么、要完成什么、读者能得到什么，以及哪些结构通常有效。她的 Working Overtime 专栏从第一人称实验出发，帮助读者理解自己与 AI 共事的经历。

其中一个模式是从摩擦走向框架：先写个人遇到的困难，展开例子，再形成读者可以使用的理解方式。Katie 说，这是她让模型分析既有文章后发现的规律。它描述的是她自己的写作，而非要求所有文章都变成同一种结构。

另一个 voice.md 记录句子层面的习惯。把专栏目的与句子如何推进分开，可以提供不同类型的指导；日后出现问题，也比将一切塞进一个不分层次的指令文件更容易检查。

开始构思时，Katie 请模型一次只问一个问题。她口述了一次经历：原本可靠的写作上下文突然不再有帮助，草稿变得拥挤、平板，再多反馈也无法恢复她希望看到的形态。

访谈并不是自动驾驶。当模型追问“过度依赖”时，Katie 改变了方向。她想探讨的是原本值得信任的上下文如何变得不可靠，而不是让文章转成另一个心理主题。

即使模型找到了已有提纲，她也要求重新开始，因为现场要展示从头构思的过程。语音输入是她个人的偏好，而非必要条件。她使用的 Monologue 属于 Every 自家的产品；理解现场热情推荐时，这一关联值得说明。

Katie 将问题追溯到一个出于好意的要求：把提纲、实验、决定和反馈全部保存下来。原本可供选择的模板，逐渐融合成每篇文章似乎都必须满足的条件。故事、文化关联、框架和笑话，变成彼此竞争的义务。

截止日期压力下，她继续添加指令，反而加重冲突。最终的处理，是把旧文件夹移入历史目录，重新建立当前使用的示例、风格指南和声音指南。这是在区分工作上下文与档案，不是销毁历史记录。

Jack 后来的编辑把区别说得更清楚：一次实验的记录，不应该悄悄变成所有未来草稿的规则。Katie 如今会有意选择保存哪些检查点。她报告的恢复属于个人经历，并非证明所有大型上下文集合都会伤害写作的对照实验。

Katie 使用“10% 框架”和“30% 提纲”，名称来自她早先的内容营销工作。前者暴露工作论点与故事节点，后者进一步展开结构。这里的百分比是检查点名称，不是数学意义上的工作完成比例。

她的理由是：完整草稿已经打磨好之后，再修正错误立意，代价会很高。因此，她先读论点、考虑读者收益，再进入较长的提纲。如果已有满意的开头，她会直接提供；并不要求每一部分都由 AI 生成。

提纲还会暴露尚未解决的选择：是否应该更早展示后果？对于目标篇幅，素材是否太多？这些问题应该在修改成本较低时由作者决定，而不是让模型悄悄代为确定。

Katie 的审阅角色各自检查特定品质：陌生读者寻找缺失背景，悬念视角检查张力在哪里消散，其他角色则关注节奏或反对意见。有些角色借用了她欣赏的叙事者名字，但她明确把结果视为 AI 对相关原则的重构，而非那些作者本人的判断。

现场出现了一次有价值的冲突。读者报告希望更早展示损失，悬念报告却认为太早展示崩溃，会把悬念变成惊讶。模型也把最终选择留给 Katie。

她将报告作为反思问题：我是否同意？这里有没有自己本来会遗漏的东西？增加角色数量，并不会取消人的判断。它能把相互竞争的编辑价值显现出来，但仍需有人决定哪一种更适合这篇文章。

Katie 会克制一次生成整篇文章的冲动。即使提纲已经批准，她仍预期起草过程会带来发现，进而改变计划。她从开头开始，检查钩子、过渡、论点以及对读者的承诺。

模型写出开头后，她会逐句回应。模型试图避免的重复，也许恰好有用；一句话读起来很自然，却仍需要注明想法来自谁。草稿让她有了可以具体接受、重写或否决的对象。

接着，她决定哪个版本值得保存，再把有用文字移入 Google Docs 手动处理。逐节生成并不保证质量，但它保留了更早发现论点变化的机会，避免同一个错误扩散到整篇文章。

Jack 说，自己的常规第一遍会通读全文，先处理大方向。直播为了时间，明确假设这一步已经完成，然后展示对预备稿的评论。他通常将标题和副标题留到深入理解文章之后再定。

他的评论往往先描述问题，而不立刻给出答案：这里的“对”究竟是什么意思？新读者为什么能理解这个表达？能不能说得更直接？有些个人细节需要 Katie 自己的经历，不能由模型用貌似合理的内容替换。

他也不把“像 AI”当成机械规则。一个常与 AI 关联的词，如果放在上下文里有效，仍可以保留。编辑要判断的是句子对这位读者起什么作用，而不是用词表证明文字由谁写成。

Jack 使用浏览器里的助手读取评论，并在聊天中建议修改。选中某段文字，可以将请求限定到该段及其附属评论。如果建议改善了一个方面、却损害另一个方面，他会要求更多版本。

他逐一检查备选，决定哪些值得建议或应用。有些问题仍交回 Katie，尤其是缺少个人信息时。模型可以帮助探索表达，但不会因为评论要求更具体，就自动拥有作者的经历。

熟悉的编辑环境也很重要。Jack 看重 Google Docs 的撤销行为和评论功能，并不希望把每项活动都搬进编排界面。直播展示的是团队录制时的选择，不是对今天模型可用性或连接器行为的验证。

Jack 的压缩技能在稿件适合时，争取减少约 10% 至 15% 的字数；一旦继续删减会伤害含义、声音、节奏或必要背景，就应该停止。它先读完整篇，再寻找结构性冗余，而非一开始就缩短单句。

82:00查看原图

示例倾向于保留具体细节、明确主语和主动动词，减少抽象标签与铺垫过渡。另一个去术语技能先把技术语言改成普通表达，再压缩结果，最后重读周围文字，检查衔接。

最后一遍很关键：局部更清楚的句子，可能重复附近内容，也可能破坏过渡。因此，字数减少要服从阅读体验；更短的版本，并不自动是更好的修改。

作者与编辑修改之后，校对工具还可以发现制作环节的问题，例如复制进 CMS 时引入的换行。Jack 也介绍了 Katebench：尝试编码 Kate 反复使用的编辑偏好，在她最终通读前发现一些明显问题。

建议以修订痕迹进入文档。Jack 接受明确的改进，拒绝明显错误，把不确定的情况留给 Kate。目标是让她集中注意力处理标准和结构等更大问题，而不是宣布模拟她的偏好就能取代她的审阅。

结尾仍将现场工作称为测试案例，文章的某个版本还有待后续推出。这与展示的过程一致：AI 帮助呈现选项、执行范围明确的修改；核实背景、提供经历，以及决定何时可以发表的责任，仍然由人承担。