每次开始写一篇文章之前，我都要先把同一段话再说一遍。
是对 AI 说。说我想要什么样的开头，说段落之间应该怎么接，说哪些句子看起来漂亮但其实不能要，说结论应该从什么地方长出来。这段话我每次说得都不完全一样，但意思差不多。说到第三四次的时候，我开始意识到一件事：如果一个要求需要反复讲，那它大概不应该活在对话里，而应该活在文件里。
这个博客的每一篇文章，都是和 AI 一起写出来的。所以怎么和 AI 一起写，对我来说不是一个兴趣话题，更像一个每天都要面对的操作问题。现在这套写作系统有一部分真的在用，有一部分还没有跑通，还有一部分只是写在方案里的想法。这篇文章想把这三部分分别说清楚。
一、真正费力的地方
用 AI 写东西，真正费力的地方不在它写得好不好。
模型写得已经够顺了。麻烦在于，顺和对是两回事。它可以很顺地写出一段我完全不同意的话，也可以很顺地把一个还没想清楚的地方糊过去。于是每一次成稿，我都要重新检查一遍：开头是不是又在下定义，段落是不是并列凑出来的，结论是不是又提前跑出来了。
这些检查每篇文章都要做一遍，每次依据的都是脑子里同一套标准。而那套标准一直没有被写下来过。它存在直觉里，所以每次都要重新调用，每次调用都有损耗，也说不准哪一次会漏。
很多工具都有这个特点：功能越来越多，但"我到底要什么样的东西"这件事，始终要靠人自己反复说。
二、一个功能很多的系统，和它的目标
中间我认真研究过一个现成的写作系统。它的能力清单很长：抓热点，给 SEO 打分，生成标题，生成封面，规避 AI 检测，多平台发布，多账号矩阵管理。
单独看每一项，都像一次升级。但把它们放在一起看，会发现它们指向同一个目标：让内容获得更多分发。
这个目标本身没有错。只是它和这个博客的目标不一致。这个博客不追热点，不看点击率，也没有什么检测需要规避。它存在的理由在另一处：写作是为了把想法逼得更清晰，不是为了表达。一旦把热点和 SEO 的逻辑引进来，选题和写法就会慢慢被分发的逻辑带走，原来那个更主要的目标会被一点点稀释。
问题于是变成了：在一长串能力里，哪些服务于我的目标，哪些服务于另一个目标。
三、我保留了什么
最后留下来的只有三样。
第一样，是把风格写成文件。哪些段落算目标风格，哪些算反面示例，开头能不能下定义，引用块该用在什么地方，一条条写下来，放在一个固定的文件里。每次成稿前对照它检查。这件事看起来笨，但它把"反复说"变成了"写一次"。
第二样，是把人工修改变成规则。每篇文章成稿后我都会改不少地方，草稿和成稿都在，差异是可对比的。如果同类修改反复出现，它就不该只留在这一篇里，而应该变成下一次写作前就会被读取的约束。
第三样，是发布前的固定检查。结构有没有因果推进，开头是不是从概念出发，结论有没有来得太早，front matter 符不符合格式。每次都按同一张清单过一遍，代替每次临场判断。
不过要如实说：这三样里面，目前只有第一样真正在用。后两样现在还只是方案文档里的设计。把它们写成方案很容易，让它们真的跑起来，是另一回事。
四、我拒绝了什么
被拒绝的那份清单更长：热点选题，SEO 评分，标题点击率优化，AI 检测规避，多 persona 写作人格，微信 API 发布，视觉封面生成。
每一条单独看都有用。我没有拒绝它们是因为它们不好，而是因为它们都在服务那个分发的目标。一个系统往哪个方向长，很大程度上取决于它拒绝什么，而不是它能装下什么。装下它们不难，难的是装下之后还认得清自己在做什么。
五、现在的真实状态
这套系统此刻的真实状态，可以分成三列。
在用的：口令化的写作流程，从探索想法到确认结构再到成稿；风格文件和写作版图文件，每次成稿前都会被读取。这个博客已有的七篇文章，都是这样出来的。
没跑通的：多平台同步脚本。脚本写完了，联调没有过。日志里留着一串浏览器驱动崩溃的栈和登录页跳转的记录，到目前为止没有一次成功发布。它现在是一个写着"待解决"的东西，不是能力。
只有文档的：作者画像、修改学习、发布前检查。它们在改造方案里有完整的格式和触发方式，但对应的文件和脚本还不存在。写文章说"系统能从修改中学习"会很漂亮，可惜那是假的。
系统此刻的规则文件、状态和可检查材料，公开在主站的写作系统 Evidence 页，可以和这篇文章对照着看。
六、这套东西没有证明什么
它不证明这些文章写得好。文章好坏只能由文章自己回答。
它不证明自动化发布可行，恰恰相反，目前的证据是一串失败日志。
它也不证明这套流程适合别人。它长在我自己的写作习惯上，换一个人，清单大概要全部重列。
如果一定要说它证明了什么，也许只有一件小事：偏好被写下来之后，重复真的消失了。现在再开一个新对话，开头那段话不用说出口了。它在那里，以文件的形式，每次都被原样读到。
一个系统值不值得留，也许不看它能装下多少功能，只看它敢不敢空着那些位置。