内容自动化按周排期，就是在逼自己在没话说的那周照样发一篇

摘要：一条内容自动化流水线有三段——什么事让它开工、它生产什么、结果怎么回到它手里。绝大多数人只搭了中间那段，于是流水线拿着一张排期表，在没有任何新东西可说的那一周照样逼出一篇。所谓的AI味内容，很大一部分不是模型写不好，是排期表要求它在无话可说的时候开口。真正该先动手的是两头：把触发器从日历挪到业务事实上，再给每一件产出编一个号，让三十天后的数据能找回到它。这篇给出六类可用的事件源、一张产出回执该记哪几个字段的清单、一套按四周落地的次序，以及三个能自查的判据。顺带核了两件被广泛引用却传歪的事：AI内容的信任惩罚到底成不成立，以及开源自部署那条路上先要过的许可证关。

先讲一个我自己踩过的坑。

两年前给一个做户外炊具的独立站搭内容流水线，逻辑很朴素：每周一早上八点，定时任务拉一批关键词，喂给模型，出三篇初稿，我审一遍发出去。跑了十一周，前四周的稿子还像样，第五周开始明显掉档，到第九周我自己都读不下去。

当时的判断是模型不行，换了。换完还是那样。又怀疑提示词写得不够细，加到一千二百字，还是那样。

后来才想明白：不是模型的问题，是那条流水线在第五周就已经没有新东西可写了，而排期表还在要求它每周三篇。它只能开始注水——把同一个观点换四种说法，把一句话的结论铺成八百字。模型没有说“这周我没料了”这个选项，它只有“照着写”这一个选项。

这件事的教训不在提示词工程那一侧。它在更前面一格：谁决定了这条流水线什么时候该开工。

为什么按周排期的内容流水线，产出会一周比一周水？

把一条内容自动化流水线拆开，它其实是三段串起来的：

1. 触发段——什么事情发生了，这条线该动一次。
2. 生产段——动起来之后，它把什么变成什么。
3. 回执段——产出跑到线上之后，结果怎么回到这条线手里。

现在市面上讲内容自动化的材料，九成九讲的是第二段：怎么写提示词、怎么串工具、怎么控格式、怎么去AI味。第一段和第三段基本没人讲，因为它们看起来太简单了——触发不就是个定时任务吗，反馈不就是看一眼数据吗。

可恰恰是这两段决定了第二段能不能做好。

先说触发。定时触发有一个结构性的毛病：它是无条件的。时间到了它就发火，不管这一周你的业务里有没有发生任何值得说的事。这在有料的时候没问题，在没料的时候就变成了一台强制注水机。

更麻烦的是，注水这件事在流水线内部是完全看不见的。没有任何一个环节会报错。稿子照样生成、照样过格式校验、照样发布成功。你唯一能察觉的方式，是三个月后自己翻回去读，发现读不下去。

这不是模型能力问题，是排期表的产物

业界谈AI垃圾内容，习惯把矛头指向模型。但从流水线的角度看，那些内容的第一因往往不在模型，而在一条“不管有没有事都要发”的规则。

换个场景就很直白了：让一个真人编辑每周三必须交三篇原创，选题自己找，做满一年，他到后半年也会开始注水。这不是能力问题，是配额和素材不匹配的必然结果。你不会因为这个就说“人类写不了内容”。

那为什么换成模型就变成了模型的锅？因为模型不会抱怨。

这类走形有一个共同特征：它是静默的

站内那篇讲AI自动化不是哪天突然坏的而是从第二周就开始走形的文章，说的是同一类现象的另一个切面：一套自动化系统的退化几乎从不以报错的形式出现，它以“一切正常但结果越来越不对”的形式出现。触发器这一格是这类走形最早的发源地，因为它是整条线上唯一一个不产生任何输出的环节——它只决定要不要开工，而“开工了但不该开工”这件事在日志里长得跟正常运行一模一样。

顺带说一句常被混在一起的话题。眼下讲一个人加一套AI跑通整个营销团队的材料很多，站内那篇拆执行门槛塌了之后真正的门槛变成了什么的文章给的结论是：稀缺的能力从“能做多少”变成了“判断做什么”。这篇要补的正是那个判断落到系统里的位置——判断做什么，在工程上就是触发器；判断做得好不好，在工程上就是回执。

触发器挂在哪里，才不会逼你无话找话？

答案不复杂：挂在你的业务本来就在产生的事实上。

软件工程里对这件事有过一轮很仔细的辨析。Martin Fowler那篇把“事件驱动”这个词拆成四种互不相同的模式的文章，核心提醒是：大家嘴里的“事件驱动”其实混着四个东西——事件通知、事件承载状态转移、事件溯源、命令查询职责分离。它们的共同点只有一个，就是系统的动作由“某件事已经发生”触发，而不是由“到点了”触发。

把这条搬到内容这边，问题就变成了：你的独立站每天在产生哪些“某件事已经发生”？

独立站现成可用的六类事件源

这六类有一个共同的性质，也是我认为最值钱的那条判据：它们在你没有新东西的那一周不会发火。没有上新就没有新品文案要写，没有新查询词涨出来就没有答案段要补。流水线自动进入静默，不需要任何人去按暂停键。

这就是事件触发相对日历触发最实在的好处——它不是让你发得更多，是让你在该少发的时候自动少发。

事件源接进去之前，先把这三个参数定下来

“接一个事件源”听起来是一句话的事，实际有三个参数不定就会翻车，而且翻的方式各不相同。

第一个是阈值。什么程度算“发生了”。改价改了一毛钱算不算？差评里出现两次同一个词算不算？阈值定得太松，事件触发就退化成了日历触发——每天都有一堆微小变动，天天都在发火；定得太紧，流水线大半年不动一次，等于没接。我的经验起点是：先把过去九十天的历史数据倒进去回放一遍，看这个阈值在过去会触发几次。目标区间是每月三到八次，落在这个区间外就调阈值，不要凭感觉拍。

第二个是防抖窗口。同一件事在短时间内反复变动，不该反复触发。典型场景是运营在后台连续改五次价格才改到位，如果每次都触发，你会拿到五篇内容。做法是设一个静默期，比如同一个SKU的价格事件在二十四小时内只取最后一次。这一格漏掉的代价不是内容质量差，是重复内容，而重复内容的下游后果比质量差严重得多。

第三个是去重键。用什么来判断“这件事我已经处理过了”。用事件时间戳最省事也最不可靠，因为重跑一次任务就会全部重复。稳妥的做法是用业务主键加事件类型拼一个键，比如“SKU编号加价格变更加变更后的值”，处理过的键落一张表，处理前先查。这一步看着琐碎，但它是整条线能不能安心跑无人值守的分界线。

这三个参数没有通用答案，都得用自己的历史数据回放着定。不过有一个反向的检查很好用：把三个参数定完之后，用过去九十天回放一遍，如果回放出来的触发次数跟你现在的发文频率差不多，说明你的事件源根本没起到闸门作用，它只是换了个名字的排期表。

一个可以拿去用的判据

要判断一个触发器设计得对不对，只问一句话：

假设这一周我的业务里什么都没发生，这个触发器还会不会发火？

会发火的，是日历触发；不会发火的，是事件触发。这个问题不需要看代码，问一句就能分清。

站内那篇讲用工作流工具把独立站SEO四类场景串成闭环的文章里搭的几条线，我后来复盘时发现质量差别正好落在这条判据上：跑得最久、最不需要人管的那条，触发源是产品库的变更；最先被我自己关掉的那条，触发源是每周一的定时器。

日历触发是不是就一无是处？

不是。这里要诚实一点，否则就变成了另一种教条。

有一类内容，它的日历本身就是事件。黑五、开学季、雨季、报税期、目标市场的公众假期——这些日子的到来对你的用户来说是真实发生的事，不是你为了凑产量编出来的。这类选题用日历触发不但没问题，而且必须用日历触发，因为你得提前四到六周开始铺。

所以更准确的说法不是“别用日历”，而是这样一条分工：

让日历触发“检查”，让事件触发“生产”。

具体是这样：定时任务每周照跑，但它跑的不是生成，是巡检——去看商品库这周有没有变、有没有新查询词冒出来、工单里有没有新的重复问题。巡检完了如果一条都没命中，这一周的产出就是零，并且这个零应该被记录下来，而不是被当成故障。

我见过好几条流水线，巡检写了，但巡检的结果是“没找到素材，那就随便选一个关键词写”。这等于把闸门装上去之后又焊死在开的位置上。

零产出的那一周，本身就是一条信息

把巡检结果记下来，还有一个不太直观的好处：连续几周零产出这件事，是一个关于业务的信号，而不是关于流水线的故障。

连着三周商品库没变、没有新查询词、工单里没有重复问题——这说明这段时间业务本身处在低活跃期。这时候正确的动作不是硬造内容，是回头看看选品和推广那一侧是不是也停了。内容产量是业务活跃度的一个滞后读数，把它强行拉平，等于把体温计砸了来退烧。

反过来，某一周事件突然密集触发，同样值得看一眼：是不是上了一批新品、是不是某个渠道的流量结构变了、是不是出了什么批量问题。这些信号在日历触发的流水线里全被抹平了，因为不管发生什么，产量都是每周三篇。

产出物没有编号，流水线就没有记忆

现在说第三段，也是我认为多数团队漏得最彻底的一段。

问一个很简单的问题：你上个季度这条流水线发出去的四十篇内容里，哪五篇带来的自然流量最多？哪五篇最差？差的那五篇有什么共同点？

大部分人答不上来。不是因为数据拿不到——数据后台里全都有——而是因为没有一个键能把“产出的那一刻”和“三十天后的结果”接起来。

这件事说破了很土：给每一件产出编一个号。号可以是工单号、表格的一行、任务系统里的一张卡，形式一点都不重要。重要的是这个号同时挂着两侧的信息：生产时的输入是什么，发布后的结果是什么。

一条产出记录至少要有哪几个字段

六个字段，一张表格就装得下。真正卡住大多数人的不是字段设计，是第五行——它要求你在三十天后回来一趟。

这张表怎么跟内容管理系统接起来

字段设计完，下一个问题是这个编号怎么在两侧都存在。有三种接法，成本和可靠性依次递增。

最省事的是写进内容的自定义字段。主流的内容管理系统都支持给文章挂自定义字段，建一个存回执编号即可。好处是取数据的时候一条查询就能把编号和文章对上；代价是要动一点后台。

次省事的是编号即文件名。如果你的流水线是先生成草稿文件再由人发布，让草稿文件名带上编号，人工发布的时候把编号复制到文章的内部备注里。这个做法有一格人工，但零开发成本，适合先跑起来验证值不值得投入。

最稳的是反向登记。发布完成后由流水线回读线上地址，把地址写回回执表那一行。这样两侧的对应关系由系统维护，不依赖任何人记得复制粘贴。多数人最后都会走到这一步，但没必要一开始就做——第一个月的重点是验证这张表有没有人真的会去看。

顺带提醒一个很容易忽略的细节：编号一旦分配就不要改，哪怕文章后来改了标题、换了地址、并进了别的页面。回执表的价值全部建立在编号的稳定性上，改一次就断一次线。文章合并的时候正确做法是新增一条“已并入某编号”的记录，而不是把两条合成一条。

为什么发布后回填比发布时打分值钱得多

很多团队做了质检，但质检全部发生在发布之前：格式对不对、字数够不够、有没有敏感词、AI味重不重。这些当然要做，可它们衡量的是“这篇稿子合不合格”，不是“这篇稿子有没有用”。

发布前的分数是你自己给的。发布后的分数是用户给的。前者是对流水线的自评，后者才是外部信号。一条只有发布前质检的流水线，本质上是一个自己给自己判卷的系统，它可以永远保持九十分而实际效果一路下滑。

站内那篇讲让AI批量写产品文案时怎么把“算写好了”说清楚的文章，处理的是发布前那一半——怎么把模糊的质量标准变成可判定的条目。这一节补的是另一半：判定标准本身也需要被检验，而检验它的只能是发布后的数据。

回填的周期我建议是三十天。七天太早，自然搜索的表现还没稳定；九十天太晚，等你发现问题已经又跑了两个季度。

反馈循环写进提示词，就算建好了吗？

没有。这里有一个非常容易踩的坑，而且它是静默的。

常见做法是在提示词里加一句：“参考历史表现数据，避免重复过去表现差的写法。”然后把回执表的链接或者一段摘要贴进上下文。看起来闭环建好了。

问题是你无法验证模型到底读没读、读进去多少。它不会告诉你“这段历史数据我没看”。它照样产出，照样看起来考虑过。

更靠谱的做法是把这件事从“要求模型自觉”改成“环境把料摆到它面前”。Anthropic那篇讲怎么给智能体做上下文工程的工程文章反复强调的一点是：上下文是稀缺资源，该进去的东西要由系统主动挑选好放进去，而不是指望模型自己去翻。落到回执这件事上，具体差别是：

• 弱做法：给模型一个能查历史表现的工具，指望它自己想起来查。
• 强做法：生产之前，由流水线先把“同类事件下表现最好的三条和最差的三条”查出来，作为固定字段拼进提示词。模型没有跳过的选项。

这两种做法的区别，和站内那篇讲AI运营四层架构里质检和反馈该放在哪几个节点的文章说的是同一件事的两个层次：那篇讲节点位置，这里讲节点的载体和喂法。位置对了、载体缺了，闭环照样是断的。

AI生成的内容一披露就掉信任，这个说法能当依据吗？

这条几乎已经变成常识了，但我去核了一轮，发现它比流传的版本要精细得多，而且有一处关键的限定被普遍略掉了。

能查到的最系统的一份材料，是2026年3月17日发表的一篇系统性文献综述，它筛选并纳入了2020年到2026年间的35项研究。它的结论有三层：

第一层，披露AI参与确实会削弱信任类结果，这一点在多种营销场景下都成立。

第二层，也是被略掉的那句——原文写的是这些效应“既非普遍也非一致”，并且列出了一串调节变量：内容是情感型还是理性型、消费者本身的AI素养、文化背景、拟人化线索、披露的措辞方式。

第三层，机制上，主要的中介变量是感知真实性，而“道德厌恶”是与之并行的一条情感通路，不是主路。

第二层那句限定对独立站的意义相当直接。同样是用AI写，写产品规格对比、尺码换算、清关时效说明、材质保养方法，和写品牌起源故事、创始人自述、用户情感共鸣段，风险完全不是一个量级。前者的说服力来自事实本身，谁把它组织出来不太重要；后者的说服力来自“这是一个真人的经历”，一旦被识别出是生成的，支撑它的那根柱子就塌了。

所以别问“这段内容能不能用AI写”，问“这段内容的说服力是靠事实还是靠人”。靠事实的放心写，靠人的自己写。

把这条判据落到独立站的具体页面上

“靠事实还是靠人”这句话听着抽象，落到页面类型上其实相当好分：

这张表最有用的一列其实是第三列。同样一次“被识别出来”的事件，落在规格页上读者最多耸耸肩，落在创始人故事上就是信任直接归零。做风险判断的时候看的不该是概率，是概率乘以代价，而这两个页面的代价差着两个数量级。

顺带说一句这份材料自己承认的短板

那篇综述在结尾列了五个待研究方向，其中一条是行为测量方面的缺陷。翻译成人话：这35项研究里，绝大多数测的是受访者的态度陈述——你信不信、你愿不愿意推荐、你觉得这个品牌怎么样——而不是他实际点了没有、买了没有。

态度和行为之间隔着很宽的一条河，这在营销研究里是老问题了。所以更稳妥的读法是：把这批结论当成风险提示，别当成可以直接换算成转化率的系数。

我在别处也见过“AI内容的点击率只有0.13%”这类具体到小数点后两位的数字被反复引用，追下去往往找不到可核实的一手出处。这类数字看着比综述结论有说服力得多，恰恰因为它们精确——而精确和可靠是两回事。

谷歌那条规模化内容滥用，卡的到底是什么

还有一个被误读的地方。不少人以为搜索引擎在打击“AI写的内容”，于是把力气花在了怎么让稿子看起来不像AI写的。方向错了。

谷歌搜索中心那份垃圾内容政策里关于规模化内容滥用的条款，判定的落点是两个：内容是不是主要为了操纵搜索排名而生成，以及它对用户有没有实际帮助。是不是AI生成的，在这两条判据里都不出现。

这两条判据和这篇文章的主线接得很紧。日历触发的流水线为什么危险？因为它在没有素材的那一周，除了“为了发而发”之外没有别的动机可言——它天然就在往第一条判据上撞。事件触发的流水线为什么安全一些？因为它每一次产出背后都有一个业务事实，那个事实本身就是“对用户有帮助”的来源。

站内那篇复盘AI内容流水线导致六个站四个被降权后设的三处人工节点的文章里，有一条当时没往前追的观察：那几个翻车的站，流水线的触发源清一色是排期表。现在回头看，那可能不是巧合。

三个可以自己过一遍的问题

1. 这篇内容如果搜索引擎明天全部消失，我还会不会写？会写的，多半没问题。
2. 这篇内容里，有没有一条信息是只有我这个站能提供的？完全没有的，先别发。
3. 这篇内容的触发原因，我能不能用一句业务事实说清楚？说不清的，那就是排期表在说话。

开源自部署这条路，许可证那一关先过了吗？

讲完设计，说一个偏工程但很容易翻船的实务问题。

这类内容与社媒自动化的方案，很多人的第一反应是找一个开源项目自己部署，省订阅费。方向没错，但有一格是必须先看的，而绝大多数教程连提都不提：许可证。

拿这个领域里星标最多的开源社媒排期项目举例。我在2026年7月30日直接读了它仓库根目录的授权文件，开头三行明明白白写着GNU Affero通用公共许可证第3版，也就是AGPL-3.0。同一天从接口拿到的其它字段是：33,955颗星、6,346个分叉、222个未关问题、TypeScript、仓库创建于2023年7月8日、最后一次推送就在当天。

项目本身很活跃，这没问题。问题在AGPL这三个字母上。

AGPL和普通开源许可证差在哪一句

常见的MIT、Apache这类许可证，义务基本只在“你把软件分发出去”的时候触发。你自己部署自己用，改成什么样都没人管。

AGPL多了一条网络条款。按许可证对照站上那份AGPL-3.0的义务清单的表述，它明确要求：当用户通过网络与这套软件交互时，源代码也必须公开——包括你自己改的那部分。这一条把“通过网络提供服务”和“分发软件”放在了同一个位置上。

对不同的人，后果差别很大：

• 自己一个人用——装在自己服务器上，只有自己和团队访问，通常没有对外提供服务，风险低。
• 给客户做代运营——如果你改了源码，并且客户通过网络在用这套东西，这一条就开始起作用了。这不是理论风险，是很多服务商真正需要请人看一眼的地方。
• 包装成自己的SaaS卖——这是AGPL这条款设计出来专门针对的场景，别绕。

我不是在说这个项目不能用。恰恰相反，作者选AGPL是很清晰的表态：欢迎自用，不欢迎白嫖去做商业托管。要说的是这一格必须在你部署之前看，而不是在客户合同签完之后。

站内那篇讲从公开字段判断一个开源项目值不值得把工作流搬上去的文章给过一套更完整的读法，那里还提到一个更阴的坑：接口返回的许可证字段是自动检测的，检测失败或者检测偏了都不会有任何提示。所以真要下判断，别只看仓库页面上那一行标签，把授权文件本身打开读一遍。

从零搭一条，先做哪一段？

反直觉的答案：倒着做。先回执，再触发器，最后才是生成器。

大多数人的顺序正好相反——先把生成跑通，因为那一段最有成就感，一天就能看到稿子出来；触发随手加个定时任务；回执等以后有空再说。以后就没有以后了。

倒着做的理由很简单：没有回执，你没有任何依据判断生成段调得好不好；没有事件触发，你的生成段会被灌进一堆本来就不该生产的选题，把回执数据全污染掉。这两段是生成段的仪表和闸门，仪表和闸门都不装就先踩油门，跑得越久偏得越远。

四周落地表

第一周那件事看着最笨，价值最高。手工补录三个月的历史，你会在补录的过程中亲眼看到哪几篇是被排期表逼出来的——它们的“触发事件”这一格填不上任何东西。

一个真实的落地节奏

去年帮一个做宠物用品的独立站按这个次序重搭，第二周接的事件源是退货理由。他们的退货系统里有一个自由填写的原因字段，此前没人看过。

接上之后第一个月只触发了四次，产出四篇内容，全部是围绕“尺寸不合适”这一类原因写的选购与测量说明。跟此前每周三篇的产量比，掉了六成还多。

但那四篇里有两篇在三个月后成了整站自然流量前十的页面。原因不神秘：那是真实用户用真金白银投票投出来的选题，而排期表选出来的选题只是关键词工具里排名靠前的词。

这也是我现在跟客户讲这套东西时最常说的一句话：事件触发的第一个可见效果一定是产量下降，如果产量没降，说明你的事件源设得太松了，它其实还是个日历。

一个反例：只补了回执，没换触发器

反面的例子也值得说，因为它比成功案例更能说明这两段的关系。

另一个做手机配件的站，我给的建议只被采纳了一半：回执表建了、字段全、三十天回填也做了自动化，但触发器保持原样，还是每周三篇。

跑了一个季度，回执表填得整整齐齐，六十多行数据。然后卡住了——数据显示表现最差的那批内容有一个共同点：它们的“触发事件”那一栏，运营填的全是“例行更新”。

这四个字出现了二十七次。也就是说，这个季度将近一半的产出，回头去找它诞生的理由，找不到。回执表没有救回这些内容，它只是把“没有理由”这件事第一次变成了可以被数出来的数字。

这其实正是回执该干的活——它不负责让内容变好，它负责让问题变得可见。但也说明单独装回执不够：仪表把毛病照出来了，闸门不换，毛病照样每周复发三次。他们后来在第二个季度接了商品库事件，那二十七行才没有继续长。

哪些环节到今天也不该自动化？

最后画一下边界。以下这几类，我到现在也不建议接进流水线，理由不是模型做不到，是做错的代价和发现错误的延迟不匹配。

• 定价与促销幅度。错一次的代价直接是钱，而且往往要等对账才发现。
• 危机沟通。产品出问题时对外说的每一句话都要有人签字，这件事的本质是担责，不是写作。
• 法律与合规文本。条款、隐私政策、成分与标注，这些地方的幻觉代价是灾难级的。
• 一手经验的叙述。上一节说过的那条判据——说服力靠人的那部分，自己写。

保哥自己的分法比较土：一件事如果做错了我在五分钟内能发现，就敢交给流水线；如果要等到下个月对账、下个季度复盘才发现，那就必须留人。这条线画的不是任务复杂度，是可发现性。可发现性是关于你这套系统的属性，不是关于那个任务的属性——同一件事，装了仪表就能自动化，没装就不能。

省下来的那部分产能，该往哪儿放

还有一个问题值得提前想清楚：事件触发把产量从每周三篇压到每月四篇之后，多出来的时间去哪儿。

如果答案是“那就再找一个事件源，把产量补回去”，那这套东西的意义就丢了一半。压产量不是目的，腾出来做那些流水线做不了的事才是。站内那篇讨论内容生产成了白菜价之后靠什么向客户收费的文章里有一条判断可以直接搬过来：当执行本身不再稀缺，值钱的就只剩下判断、一手材料和责任承担这三样。

具体到内容这一侧，我给客户的建议通常是三七开：七成的腾出时间去做一手素材——实拍、实测、把客服和售后那边真实发生的事整理成可写的东西；三成去做回执的复盘。这两件事流水线都做不了，而它们恰好是流水线质量的上游。

顺着这条线往回看，本文前面那三段的关系也就清楚了：回执段是可发现性本身，触发段决定了有多少东西需要被发现，生成段只是中间那个执行器。把力气全花在执行器上，是把一台机器最不重要的零件打磨得最亮。

常见问题解答

事件触发会不会导致内容产量太低，撑不起SEO需要的更新频率？

短期一定会降，这是预期内的。但更新频率本身不是排名因素，有价值的新内容才是。真正需要担心的情况只有一种：你的业务事实确实太少——比如整个季度没有上新、没有新查询词、工单里没有重复问题。那说明问题不在内容侧，在业务侧，加大产量并不能解决它。折中做法是把事件源的阈值调松一档，同时保留静默机制，而不是退回日历触发。

回执表用什么工具做比较好？

越轻越好。表格工具就足够，一行一件产出。用任务系统的卡片也行，用代码仓库的工单也行。唯一的硬要求是每件产出有唯一编号，并且这个编号能在发布出去的内容里追溯回来——最省事的做法是把编号写进内部备注或者内容管理系统的自定义字段。选工具花的时间超过半天，基本就是在拖延真正该做的事。

已经跑了很久的日历触发流水线，要不要推倒重来？

不用推倒，按顺序加装就行。先补回执表并手工回填历史，这一步不影响现有流水线运行；然后并行接一条事件触发的线，两条一起跑一到两个月，用回执数据对比两侧的产出表现；数据说话之后再决定日历那条留多少。直接停掉的风险是你手上没有对比依据，只能凭感觉，而感觉在这件事上一向不太准。

三十天回填能不能自动化，非要人工看吗？

数据部分完全可以自动化，定时任务把流量、点击、停留、转化拉回来填进表就行。人工那部分只保留最后一栏点评，一句话即可。经验是纯自动的回执表会慢慢没人看，因为它只有数字；有一栏人写的话，回头翻的时候检索效率高得多——数字告诉你哪篇差，那句话告诉你为什么差。

用开源项目自部署，除了许可证还有哪些容易忽略的成本？

三块。一是升级维护，开源项目的接口变更节奏往往比商业产品快；二是第三方平台的授权与配额，社媒接口的密钥申请和额度限制不会因为你自部署就变宽松；三是故障响应，出问题的时候没有工单可提。判断的方法是把这三块折成人天，和订阅费放在一起比。人少的团队算下来订阅更划算的情况相当常见。

怎么判断一篇内容的差是素材差还是生成差？

看回执表里“人工改动量”这一栏的分布。如果改动集中在事实、数据、细节的补充上，是素材不够；如果改动集中在结构调整、语气重写、删冗余上，是生成段的问题。这两种改动在编辑器里长得完全不一样，审的时候顺手标一个字母就能区分，成本几乎为零，但它是整张回执表里唯一能在发布前给出信号的字段。

权威参考资料