借鉴开源 workflow 设计自己的内容生产系统——取舍与最小粒度原则

最近做了一件小事，但想清楚了一个大问题。

我有一套内容生产流水线：先用 gen-script 把文章转成口播稿，再用 gen-slides 把口播稿生成教学动画 HTML。这套东西用了一段时间，核心逻辑是稳的，但动画生成这一环一直有隐患——我自己写的动画规范（AI教学动画生成器.md）更像是一份「我希望动画长什么样」的愿望清单，而不是一套有认知科学依据的设计体系。

然后我发现了 visual-cognition-slides，一个叫「爱思考的伊伊子」的人做的开源项目。它有四个核心文件：PEDAGOGY.md、ANIMATIONS.md、STYLES.md、FORMATS.md。看完之后我意识到，对方在「认知科学驱动的动画设计」这件事上，比我深入得多。不是技术上深，是思考上深——她认真研究过信息呈现如何影响认知负荷，如何用动画节奏服务理解而不是服务好看。

我做了一个决定：把这四个文件拷贝进我的工程，替换掉我自己的动画引擎。

这件事本身不复杂，但「要不要做」「哪些换哪些不换」这两个问题，逼我想清楚了一些关于 workflow 设计的事。

借鉴的判断标准：这件事是不是你的差异化所在？

我给自己设了三个问题，用来判断某个环节该自己做还是该借鉴：

一：这是不是你区别于别人的地方？

动画规范不是。动画好不好看、认知负荷控不控制得住，这些是工程质量问题，不是我的个人表达。我的差异化在内容判断——我选什么题、怎么拆解概念、用什么语气说话。动画只是承载方式。

口播稿生成是。我的口播稿 prompt 里藏着我对「怎么解释一个概念」的理解，藏着我的节奏感和语气习惯。这个不能外包，也没办法外包——因为别人写的 prompt 生成的是别人声音的稿子。

二：对方在这个环节上是否有更深的积累？

这是最重要的一问。visual-cognition-slides 的作者在认知科学这件事上想得比我深，她的 PEDAGOGY.md 里有我没有系统化过的东西。这种情况下，我自己硬写一份「更差的版本」是没有意义的。

但如果对方的积累和我的需求有结构性错位，借鉴就会变成包袱。比如一个为大规模团队设计的内容系统，借鉴进一个人的工作流，会引入大量我不需要的复杂度。

三：借鉴的成本和自建的成本哪个更高？

这个问题经常被低估。借鉴不是免费的——你要读懂对方的设计意图，要做适配，要在对方的框架里思考，有时候这比自己从头写还费力。这次之所以值，是因为那四个文件本身写得很清晰，意图透明，几乎没有适配成本。

最小粒度原则：不要把可以透明的东西藏起来

做 workflow 的人有一个常见的错误：把东西封装得太死。觉得封装得越好越专业，其实往往是越来越难改、越来越难理解自己在做什么。

我的原则是：workflow 里的每一个判断单元，都应该是可以直接读、直接改的最小文件。

知识库取用策略不应该是「全量读取所有相关文章」，而应该是「关键词搜索 + 精选 3 篇」。前者看起来更全面，实际上是把判断权交给了检索算法，后者迫使你明确说出「我要找什么」。精选 3 篇这个动作本身就是一次内容判断。

口播稿生成器的 prompt 是一个单文件 Markdown，不是一个带配置、带模板继承的复杂系统。因为这个 prompt 是我「当下对内容生产的理解」的凝固，它需要是活的、随时可以打开改的，而不是藏在某个系统架构深处。

动画规范文件也是同理。PEDAGOGY.md 就是一个文本文件，我可以打开它、读它、不同意里面的某一条然后改掉它。这种透明度是借鉴外部工具时最需要保留的东西——你要能「看见」你在用什么。

最小粒度的本质是：保持对每一个判断的所有权。你可以用别人设计的框架，但你得知道这个框架里每一条在说什么，以及为什么你接受它。

这次融合的具体取舍

保留的：

gen-script 整个流水线，包括从文章到口播稿的 prompt 逻辑、个人知识库的集成方式（搜索策略、引用格式）、以及我的「个人声音系统」——那套关于语气、节奏、用词倾向的描述性规范。这些是我花时间才校准好的东西，换掉没有理由。

丢掉的：

自己写的 AI教学动画生成器.md。说实话有点舍不得，因为那是我第一次认真思考「动画该怎么设计」的产物。但舍不得是情感，不是判断。判断是：那份文件的质量不如 visual-cognition-slides，留着只会产生混乱。

引入的：

PEDAGOGY.md 作为动画设计的认知科学判断框架，以及另外三个文件作为具体执行规范。引入之后我做的第一件事是把每一条都读了一遍，标出我有疑问的地方。这一步不能省——借鉴不是复制粘贴，是有意识地接受某套判断。

config 作为胶水层：workflow 最值钱的设计

整个融合过程里，让我最庆幸的一个设计决定是：用 artifacts.config.json 这样的薄配置层连接各个模块，而不是把它们硬编码在一起。

这个配置文件本身很简单——它只记录「哪个环节用哪个文件」「各个模块的输入输出路径在哪里」。但正因为这一层存在，替换动画引擎这件事才能干净地完成：我只需要在 config 里更新指向，不需要去每个脚本里搜索硬编码的路径。

解耦的价值在于：它让你的 workflow 可以局部进化。你可以只换动画引擎，不动口播稿生成器；可以只更新知识库取用策略，不影响输出格式。每个部分都可以独立替换、独立迭代。

这一层越薄越好。配置文件不是用来承载逻辑的，逻辑应该在各自的模块里。配置只管「谁跟谁连接」，仅此而已。

对创作者的启示

你不需要从零搭建所有东西。

这个行业有大量优质的开源工具、设计规范、方法论框架，很多是有真正深度积累的人花了大量时间做的。如果你在某个环节上的积累不如对方，借鉴是明智的，不是偷懒。

但有两件事必须是你自己的：内容判断力和个人声音。

内容判断力是你决定讲什么、怎么拆解、对谁讲的能力。这件事没有工具可以替代，因为它依赖你对某个领域的理解深度，依赖你对受众的感知，依赖你愿不愿意为某个判断负责。

个人声音是你被认出来的方式。它不是文风那么表面的东西，是你对世界的某种看法渗透进内容里的痕迹。这个也没有 prompt 可以完全复制——你能用 prompt 描述它，但那个描述本身需要你先清楚地知道自己的声音是什么。

workflow 是工具，工具是为内容服务的。借鉴好的工具，保留自己的判断，这两件事不矛盾，也不应该混淆。

2026.03.26