文章也可以重构

发布于:2026-11-02 952 字 3 分钟阅读

Tison 在《Agentic Coding 的边界》里提到一个处理重复代码的习惯:第一次写一段逻辑,顺着写下来;第二次遇到类似的,先复制粘贴;第三次再考虑要不要提取公共代码。

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

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

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

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

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

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

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

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

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