---
title: "文章也可以重构"
author: "Shawn Jiang"
lang: zh
date: 2026-11-02
canonical: https://tplog.dev/zh/essay/writing-can-be-refactored-too/
translations:
  en: https://tplog.dev/en/essay/writing-can-be-refactored-too/
  ja: https://tplog.dev/ja/essay/writing-can-be-refactored-too/
---

# 文章也可以重构

Tison 在[《Agentic Coding 的边界》](https://x.com/tison1096/status/2045492574945976478)里提到一个处理重复代码的习惯：第一次写一段逻辑，顺着写下来；第二次遇到类似的，先复制粘贴；第三次再考虑要不要提取公共代码。

这么做，是为了先弄清一件事：两段代码到底在表达同一个意思，还是碰巧长得像？这一点在刚动手时往往看不出来。如果只是看起来相似就急着合并，后面需求一变，就得往函数里加一堆参数和条件，再把两条路径拆开。

我觉得写作也有同样的问题。过早定下的提纲，就像过早提取的公共代码。

刚冒出一个想法时，我未必已经知道自己想说什么。念头在脑子里显得很完整，真正写下来，我才发现中间缺了一步，或者有句话怎么都解释不清。为了把这一步补上，我就得再找一个例子，或者把原本混在一起的两种情况分开。写着写着，连最初的判断也可能跟着变。

这些变化很难提前排进提纲。如果一开始把结构定得太细，后面就会变成往标题下面硬填内容；写到一半冒出更有意思的想法，还得犹豫它算不算偏题。可对还在摸索的文章来说，那个“偏题”的地方，说不定才最值得写下去。如果这时候硬要守住原来的提纲，就会像为了迁就已有的抽象而往函数里硬塞参数一样，把文章越改越别扭。

所以我更愿意先顺着写：先记下一句话、一个例子，或者对某种说法的一点不认同。

等手头有了几段具体内容，我才有东西可以放在一起比较。这时候回头看，就能分清哪两段其实在说同一件事，哪两段只是表面长得像；也能看出哪个例子撑得住观点，哪几句只是自己想说、读者其实不需要。

看清这些之后再来重构，要改的就不只是措辞，还有文章的顺序。自己顺着想明白一件事的顺序，未必是适合别人读的顺序。读者得先知道哪个前提，才能理解后面的判断；哪些内容属于同一个问题，应该合在一起，哪些又要拆开。有时候原来放在最后的一句话，反而更适合挪到开头。

现在用 AI 重新组织文字很方便，我可以随时让它给出几种顺序来比较。但在那之前，我还是想先留下那些不太顺、却确实是自己在想的话。有了这些原话做底子，再去读修改稿时，才分得清哪些修改是在帮我把意思说清楚，哪些只是把文字改得更像一篇标准文章。

当然，如果是结论已经明确的说明文，先列提纲会省事得多。我说的只是另一种时候：自己还在摸索，只是隐约觉得这里有点东西。遇到这种时候，不妨先写一会儿，等写出一些具体内容，再回头决定这篇文章该怎么讲。