内容自动化触发器与回执设计：用事件驱动替代按周排期

摘要：一条内容自动化流水线分三段：什么事让它开工、它生产什么、结果怎么回到它手里。绝大多数人只搭了中间那段，流水线于是拿着一张排期表，在没有任何新东西可说的那一周也照样产出一篇。所谓的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. 这篇内容的触发原因，能不能用一句业务事实说清楚？说不清的，那就是排期表在替你做决定。

开源社媒排期工具自部署之前，AGPL许可证要先核查什么？

讲完设计，再说一个偏工程、但很容易出问题的实务环节。

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

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

项目本身很活跃，这一点没有问题。需要留意的是它采用的AGPL许可证。

AGPL和MIT、Apache等常见开源许可证的关键差别

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

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

对不同使用者，后果差别很大：

• 自己一个人用：装在自己的服务器上，只有自己和团队访问，通常不涉及对外提供服务，风险低。
• 给客户做代运营：如果你改了源码，并且客户通过网络在使用这套系统，这一条就开始生效。这是很多服务商真正需要请人审一遍的地方。
• 包装成自己的SaaS出售：这正是AGPL这一条款专门针对的场景，别想着绕过去。

这并不是说这个项目不能用。作者选择AGPL，态度很明确：欢迎自用，不欢迎拿去做商业托管却不公开改动。这里要强调的是，这一项必须在部署之前核查，别等到客户合同签完之后。

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

从零搭建一条流水线，应该先做哪一段？

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

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

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

四周落地计划表

第一周的工作看起来最笨，价值却最高。手工补录三个月的历史内容时，你会亲眼看到哪几篇是被排期表逼出来的：它们的“触发事件”一栏什么都填不上。

一个实际落地案例的节奏

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

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

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

这也是我现在向客户介绍这套方法时最常说的一句话：事件触发的第一个可见效果一定是产量下降；如果产量没降，说明事件源设得太松，它实际上还是个日历。

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

反例同样值得讲，因为它比成功案例更能说明这两段之间的关系。

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

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

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

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

内容运营中哪些环节至今仍不该交给自动化流水线？

最后划一下边界。以下几类，我到现在也不建议接进流水线，原因不在于模型做不到，而在于出错的代价和发现错误的延迟不匹配。

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

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

压缩产量后腾出的产能，该投到哪里

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

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

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

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

常见问题解答

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

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

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

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

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

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

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

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

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

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

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

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

权威参考资料