昨天我把公众号流程又跑了一遍，突然想到一个小问题。每篇文章都要写一点背景，放一点介绍，再补几篇往期文章，看起来不大，可每次手工做都会分心。 说实话，内容系统最怕这种小动作。它们单独看都很轻，合在一起就会让人不敢改。你有没有这种感觉？越是常用的尾部，越容易变成没人愿意碰的地方。 所以这篇测试稿不谈宏大的系统，只看一个很具体的点。把开头背景，末尾介绍，二维码和历史文章抽出来，发布前再组合，原文就能保持干净。 有一说一，这个改动不是为了多做功能。它更像给写作流程留一个接口，让不同账号，不同文章类型，都能按自己的规则长出来。
模块不该住在正文里
我跟你说，正文里最应该留下的是判断和表达。背景文案可以变，二维码可以换，介绍也会调整，这些东西放进正文，后面每次都会牵动原稿。
你想想看，一篇文章已经发过草稿，突然想换一句关注介绍。如果它写死在正文里，改动就会变成重新查找，重新替换，重新确认。
讲真，这种工作没有难度，却很消耗注意力。内容团队真正需要的是确定性，知道哪些东西是文章本身，哪些东西是发布包装。
把模块拆出来以后，文章目录里可以保留一个本地配置。谁需要开头背景，谁需要二维码，谁要历史文章，都从配置里读。
这就像把厨房里的调料放回调料架。菜还是那道菜，出锅前按口味加一点，不会改变食材本身。对吧？
更重要的是，旧文章不会被突然影响。没有配置，就按原流程发布。有配置，才会在预览和推草稿时临时组合。
这个边界很重要。因为公众号流程已经跑了很久，稳定比漂亮更值钱。改动要能退出，也要能逐篇打开。
其实吧，很多自动化不是为了替人做决定，而是为了减少重复确认。原文干净，模块清楚，心里就不乱。
我发现，只要把边界划清，后面的需求就不容易互相打架。长文怎么放，小绿书怎么放，都能单独处理。
这也是这次测试的核心。不是把所有东西塞进一个模板，而是给发布前增加一个可控的组合层。
长文适合承载延伸阅读
长文的阅读节奏比较完整。读者已经花了几分钟看完观点，结尾出现往期文章和介绍，不会显得突兀。
如果历史文章能点击，就能直接跳到已发布内容。这里最关键的数据不是标题，而是发布后的链接。没有链接时，可以只展示标题。
说真的，这个体验很像文章里的延伸阅读。不是硬塞广告，而是告诉读者，如果你对这个方向有兴趣，可以继续看哪几篇。
长文里也适合放二维码图片。它作为末尾图片出现，读者读到最后再扫码，位置自然，压力也小。
不过二维码不应该跑到固定作者尾部后面。固定尾部是质量门的一部分，最好保持稳定，所以模块要插在固定尾部前。
这样发布稿看起来完整，质量门也知道自己该检查什么。原文里仍然只有正文，配置里才是介绍和二维码。
你想啊，如果以后某个账号不想放二维码，只改配置就行。如果另一个账号要换介绍，也不用碰正文。
这件事小，但它会慢慢省下很多编辑时间。不是大幅提速，而是少一点细碎的中断。
怎么说呢，写作者最珍贵的是连续感。系统能帮忙守住连续感，就已经很有价值。
这也是为什么我更愿意把它做成流程能力，而不是让每篇文章手工复制一段尾巴。
小绿书要换一种放法
小绿书就不一样。它短，文本空间很紧，不能照搬长文的链接和大段介绍。
如果把三篇历史文章都写成完整链接，正文会很难看。读者看到一串地址，也不会真的想点。
所以小绿书只适合放标题列表，或者放一句很短的引导。二维码则应该进图片栈，最好排在最后一张。
好家伙，同一个模块，到了小绿书这里就得换一套渲染方式。这不是复杂，是尊重平台形态。
图片消息的重点是图和短文，正文要轻。二维码作为图片出现，比作为文字链接更符合阅读习惯。
还真别说，这个差异如果不在流程里处理，后面就会变成编辑经验。谁记得住，谁就做对，谁忘了就出错。
系统不该依赖记忆。它应该知道文章类型，然后自动选择正确的尾部样式。
这也是模块抽象的好处。配置可以相同，但最终输出按类型分化。长文有链接，小绿书有短标题和图片栈。
你说是不是？一个规则能跑两种内容，但不强迫两种内容长得一样，这才比较舒服。
后面如果加更多账号，也可以按账号加覆盖配置，不需要把判断写进每篇文章。
预览必须和草稿一致
流程里还有一个容易被忽略的点，预览要和最终草稿一致。只在发布时插模块，预览看不到，就等于把风险留到最后。
所以这次接入的位置选在两个地方。一个是本地 HTML 预览，一个是微信上传脚本。两边都走同一个 composer。
说实在的，预览不是装饰。它是发布前最后一次肉眼确认，里面看到什么，草稿里就应该是什么。
如果历史文章在预览里还是 Markdown 原文，读者体验就判断不了。因此预览 renderer 也要支持行内链接。
链接在本地预览里能点，推到公众号后也会转成微信可识别的 HTML 链接。这样确认成本最低。
二维码图片也一样。长文里是正文图片，小绿书里是图片栈图片，预览必须提前展示。
我发现，很多发布事故不是因为逻辑难，而是因为预览和真实输出不一致。看到的是一套，发出去又是一套，人就没法放心。
这次把组合逻辑集中起来，就是为了减少这种不一致。入口不同，渲染规则相同。
当然，流程还要保留退出方式。关闭模块后，预览和发布都回到原文，不留下隐藏副作用。
这才适合放进日常写作链路。平时不用管，需要时打开，出了问题也能定位。
历史文章来自台账
历史文章默认取最近三篇已发布文章。这里不能只扫文件夹，因为文件夹里有草稿，有排期，也有本地测试稿。
更稳的来源是 registry。里面有文章状态，账号，标题，发布链接，更新时间。模块只拿已发布的记录。
如果某篇历史文章没有发布链接，长文里就只显示标题。能点击时就点击，不能点击时也不阻断发布。
这个容错很重要。发布流程不能因为尾部推荐缺一条链接就停住。尾部模块是增强，不是硬依赖。
不是我说，越靠近发布的地方，越要少做强假设。能展示就展示，拿不到就降级，主文章不能被轻易拖住。
同账号优先也合理。剑飞账号推荐剑飞历史文章，语音写作账号推荐语音写作历史文章，读者预期更一致。
如果以后想跨账号推荐，也可以把 same_account 关掉。配置表达这个选择，比在代码里写死更好。
这里还有一个细节，要排除当前文章。否则刚发布过的文章再次更新草稿时，可能把自己推荐给自己。
这种小边界看起来不起眼，但会影响最终质感。读者未必说得出来哪里奇怪，却会感觉系统很粗。
所以模块虽然小，仍然需要按正式流程处理。数据来源，排除规则，降级策略，都要明确。
这次测试看结果
这篇草稿本身就是一次流程测试。它不是为了发表观点，而是为了确认模块进草稿箱之后，视觉和点击都正常。
你打开草稿箱后，可以重点看三个地方。开头有没有背景文案，结尾有没有往期三篇，二维码有没有出现在固定尾部前。
再点一下往期链接，看它是不是跳到对应地址。这里用的是演示链接，真实流程会换成 registry 里的发布链接。
如果这几个点都顺，下一步就可以把模块配置做成账号级默认项。比如剑飞默认历史三篇，语音写作默认加社群二维码。
有意思的是，越是这种小模块，越应该先用一篇草稿试。因为它影响的是读者眼睛，不只是代码路径。
读者不会关心 composer 怎么写，只会看到开头是否啰嗦，结尾是否顺手，二维码是否抢戏。
所以我更愿意先把效果推到草稿箱，让人直接在微信后台看。后台真实，判断也真实。
如果你觉得二维码太大，可以在模块里换更克制的图。如果历史文章太多，也可以把三篇改成两篇。
流程已经把开关留出来。后面调的是内容策略，不是工程结构。
这就是我想要的状态，系统负责稳定组合，人负责判断好不好看。
放进流程后的日常用法
日常使用时，写作者不需要记住这些细节。文章照常写，配图照常进 manifest，预览照常刷新，模块只在最后组合出来。
配置文件可以很短，只写背景，介绍，二维码和历史文章数量。没有写的部分就不出现，整个行为一眼能看懂。
这对多账号尤其有用。剑飞可以偏产品和系统，语音写作可以偏训练营介绍，时间报告可以偏订阅说明。
你想想看，如果所有账号共用一段尾部，读者会觉得味道不对。如果每篇手写，又会让维护变重。
模块层正好站在中间。它给账号默认值，也允许单篇覆盖。既不僵硬，也不把编辑拖进重复劳动。
讲道理，这种能力越早固定越好。等文章数量多了，再去统一尾部，成本就会变成一场清理工作。
现在先从发布前组合做起，风险很低。原文文件没有被改写，草稿效果可以预览，关掉配置就恢复原样。
如果以后要做得更细，也可以加生效日期。比如某个二维码只在活动期间出现，过期后自动换回普通介绍。
还可以加账号画像。不同公众号的介绍文案不一样，推荐历史文章的范围也不一样，这些都适合放配置里。
我发现，内容流程一旦有了这种边界，就会越用越顺。新增需求不会马上污染正文，也不会散落在脚本里。
当然，模块不能太多。开头背景最好一两句，结尾介绍也要克制，历史文章三篇已经够用。
二维码也要注意尺寸。太大就像硬广，太小又扫不动，最好由图片本身控制留白和视觉重量。
说实话，真正要看的不是功能数量，而是读者滑到尾部时有没有压力。如果压力小，模块就合格。
后台草稿箱能帮我们判断这个点。手机里看，比在代码里想更准确，尤其是二维码和链接间距。
所以这次我选择直接推一篇草稿。你在微信后台看到的，就是未来真实发布时最接近的样子。
如果看完觉得历史文章链接太显眼，可以改成普通标题。如果觉得背景没必要，也可以默认不写。
流程只负责把可能性摆好，不替内容做最终判断。这个分工很健康，也比较适合长期维护。
有一说一，这才是我喜欢的小改动。它不轰轰烈烈，但能减少很多以后会出现的小麻烦。
等这篇草稿确认没问题，就可以把账号级配置补上。后续每篇文章刷新预览时，都能看到同样的尾部结构。
到了那一步，写文章的人只要关心内容，系统会把固定模块放到该出现的位置。这个感觉就对了。
如果团队里有两个人同时写，模块配置还能减少沟通。一个人改正文，一个人改尾部入口，两边不会互相覆盖。
这对多机同步也友好。正文，图片，模块配置都是文章目录里的文件，同步时跟着文章走，不需要额外猜状态。
预览刷新时先组合，再渲染。推草稿时也先组合，再上传。两条路径共用同一段逻辑，就不容易出现偏差。
如果 registry 里有真实发布链接，历史文章就自动可点。如果没有链接，标题仍然能展示，流程不会卡死。
这种降级策略很朴素，但很重要。尾部推荐是锦上添花，不应该让主文章发布失败。
以后还可以把点击数据接回来，看哪些历史文章适合被推荐。那时模块就不只是固定尾部，而是内容分发入口。
不过那是后话。现在先把最基本的形态跑稳，能预览，能推草稿，能关闭，能逐篇覆盖，就够用了。
再往后看，模块还可以服务复盘。每次草稿生成时记录组合结果，就能知道当时到底用了哪段介绍和哪张二维码。
这比回头猜要可靠。内容生产不是一次性动作，它会被修改，被复用，被迁移，记录越清楚，后面越轻松。
对读者来说，这些技术细节都不可见。读者只会看到文章顺不顺，结尾有没有用，链接能不能点。
所以工程目标很简单。让编辑少操心，让读者少受打扰，让每篇文章都能稳定地带上该带的信息。
这篇测试稿会留在草稿箱里，方便你直接看真实微信后台效果。看完以后，模块配置还可以继续按你的口味调。
如果哪里不顺，我们就改模块，不动主流程，继续保持稳妥可靠。
点个赞、在看、转发三连，我们下篇继续。
作者：剑飞，本文共4800字