写了一篇好文章之后，你通常会有一些「以后写文章要记得做到这些」的想法。比如：「以后要在每篇文章里加小结」、「以后要注意段落长度」、「以后要检查标题是否吸引人」。
这些想法很重要，但如果不把它们固化下来，下次写文章的时候很容易忘。人的短期记忆是不可靠的，特别是当你隔了一段时间再写的时候。等到你写下一篇文章时，你只会记得「我好像总结过一些写作标准」，但具体是什么标准——想不起来了。
13篇基准要求是什么
「13篇基准」指的是：你在写了13篇同类型文章之后，总结出来的一套「好文章应该符合的标准」。
为什么是13篇？不是12也不是14。因为在实际经验里，写不到10篇的时候，样本量太少，提炼出来的规则可能被少数几篇文章的个性特征带偏。写超过15篇之后，又要花太多时间做分析。10到13篇是一个让规则既有统计意义又不至于太庞杂的区间。当然，这个数字不是绝对的——关键在于「有足够多的样本让你看到共性」。
这13篇文章可以是你自己的文章，也可以是你研究过的别人家的文章。关键是：你认真地、一篇一篇地分析了它们为什么好，然后从这些分析里提炼出了可复现的要求。
这些要求通常是这样的：
- 每篇文章必须有清晰的单一核心论点
- 开篇必须用具体场景引入，不能上来就讲道理
- 正文必须分4到7个小节，每节有一个明确的小标题
- 段落长度不能超过5行，否则读者会疲劳
- 结尾必须给出行动建议，不能只停留在「讲清楚了」的层面
每一条要求背后，都有你在分析那13篇文章时的具体发现。所以这些要求不是「写作教条」，而是「从真实好文章里提炼出来的成功要素」。
为什么不写进代码就会慢慢退化
如果你只是把13篇基准要求记在脑子里，或者写在一个笔记文件里，那它们对你下一篇文章的约束力是很弱的。
原因是：写作是一个认知负载比较高的活动。你在写的时候，大部分注意力都放在「怎么把论点讲清楚」、「这个例子合不合适」、「下一段怎么接」这些实时决策上。你的工作记忆几乎被占满了，这时候很容易忽略「检查段落长度」或者「确认结尾有行动建议」这类「非实时」的要求。
更糟糕的是：如果你赶时间，或者这一篇的选题特别难写，你很可能会主动放弃那些「基准要求」。你会跟自己说：「这一篇先这样吧，下一篇再按基准来。」但下一篇又会有新的理由让你放弃基准。这就是「知道自己应该做什么」和「实际做到了什么」之间的鸿沟。
这条鸿沟，靠意志力填补不了——因为意志力也是会疲劳的。当你写一篇复杂文章已经用了三个小时的时候，你不可能还有额外的心力去逐条检查13条基准要求。这时候唯一靠得住的就是自动化工具。
写进代码的具体做法
「把基准要求写进代码」的意思是：编写一些自动化检查工具，在你写完文章之后自动扫描是否符合基准要求。
具体做法分三步：
第一步：把每一条基准要求翻译成可检查的指标。
比如「开篇必须用具体场景引入」这条要求，翻译成指标就是：「文章第一段必须包含具体的人名、地名、时间、或具体的事件描述」。如果第一段只是抽象论述，指标就不通过。
再比如「段落长度不能超过5行」，翻译成指标就是：「统计文章中每一段的行数，如果有超过5行的段落，标记为警告」。
翻译这一步是最关键的。它迫使你把模糊的「我觉得应该这样」变成精确的「什么情况算对、什么情况算不对」。这个过程本身就在帮你理清思路——很多时候你写完才发现，自己并不完全清楚某条基准要求到底要检查什么。
第二步：用静态检查工具实现这些指标。
如果你用Markdown写文章，可以用一个Python脚本来实现检查。这个脚本读入Markdown文件，逐条检查指标，最后输出一个检查报告。
报告格式可以是这样的：
✓ 核心论点清晰（在第二段明确出现）
✗ 开篇缺少具体场景（第一段为抽象论述）
✓ 小节数量符合要求（5个小节）
✗ 段落长度超标（第3段有8行）
✓ 结尾有行动建议
第三步：把检查脚本集成到你的写作流程里。
最轻量的集成方式是：在编辑器里配一个「保存时自动运行检查脚本」的功能，每次保存就能看到最新检查结果。如果用了Git管理文章，也可以配成Git Hook，在每次commit前自动运行——忘了某条基准要求，commit会失败，提醒你去修改。
集成之后还有一个额外的好处：你可以通过统计数据看到自己的改进趋势。本周的检查通过率是70%，下周是85%，再下周是90%——这种可视化反馈本身就是一种正向激励，而且比「我又进步了」这种模糊的自我感受具体得多。
写进代码之后的长效收益
把基准要求代码化之后，最大的好处不是「你再也不会违反这些要求了」，而是：你从「每次都要靠意志力提醒自己」变成了「有自动化工具在帮你盯着」。
这看起来只是一个工具上的改变，但实际上它改变的是你的写作习惯的形成方式。在没有自动化检查的时候，一条基准要求要从「你知道它」变成「你每次都做到它」，需要你每次写作时都付出意志力去记住它、检查它。意志力是一种有限资源，你不可能每次都记得所有13条要求。有了自动化检查之后，认知负载从「记住要求+写文章」变成了「写文章+根据检查报告修改」，明显轻了很多。
另一个好处是：你可以迭代你的基准要求。当你写了更多文章、研究了更多好文章之后，你可能会发现原来的某些要求不够准确，或者有新的要求应该加进去。有了检查脚本之后，迭代基准要求变成了「改脚本」——一个确定性的、可测试的过程。改完脚本之后，用以前写过的文章跑一下，看看新要求是不是真的能区分好文章和一般文章。如果没有脚本，迭代基准就是一个模糊的感觉过程，让你迟迟不愿去改。
什么时候不应该代码化
不是所有基准要求都适合代码化。有一些是「质感类」要求，比如「文章语气应该是温暖的、像朋友聊天一样」。这种很难翻译成可自动检查的指标。
对于这类要求，代码化的方式不是「写检查脚本」，而是「准备几篇标杆文章」。挑2到3篇你认为语气最到位的文章，存成「语气标杆库」。每次写完新文章之后，把新文章的导语和标杆文章的导语放在一起读一遍，问自己：「语气是不是差不多？」如果差得比较多，就改一改。
这种方式不是自动化的，但至少给了你一个可操作的检查方法，而不只是「我要注意语气」这种模糊的自我提醒。
从写出好文章到系统化产出的跨越
把13篇基准要求写进代码，看起来是一个技术动作，实际上是一个思维方式的变化。它意味着你不再把「写出好文章」看作一个依赖个人状态和经验的事情，而是把它看作一个可以系统化复制的过程。
这个转变具体的标志是：当你有一段时间没写文章、重新动笔的时候，你的第一反应不是「我还能不能写得跟以前一样好」，而是「跑一遍检查脚本看看有没有回退」。前者是靠信心，后者是靠系统。靠信心的问题在于：信心是波动的。状态好的时候你觉得自己什么都能写，状态不好的时候你怀疑自己是不是退步了。靠系统的好处在于：系统的判断是稳定的。同一个脚本、同一个标准，今天跑和一个月后跑，结果是一致的。
这也是为什么很多成熟的写作者会有一个「出版前检查清单」——它本质上就是一套不写进代码的基准要求。代码化只是让这个检查清单跑得更快、更一致、不依赖人在那个时刻的注意力。如果你还没有想好怎么代码化，先从一份打印出来的检查清单开始，贴在桌面上，每次写完文章用手勾一遍，效果也不会差太多。最重要的是：先有一个可以依赖的外部系统，而不是全靠大脑。
写作时间：2026-05-31，来自 jp091 深度对话 backlog 候选9。