给大模型加上硬约束，AI工作流才能稳定进入真实生产
一条公众号链接自动入库，真正起作用的是背后的规则、流程和校验，不只是模型能力。
公众号和 X 这些优秀的信息平台，都很封闭。 你想把里面有用的东西稳定采进自己的知识库，不是点一下收藏就能解决的。 后来开始用 Hermes 才发现，它刚好能解决这个问题。它能在后台跑脚本，能专门做采集、整理、入库。还能通过飞书 CLI 和官方 Skills 去驱动飞书，让公众号文章或者 X 上的贴文进到飞书多维表格里。 这一下，原来最头疼的采集工作，看似能解决了。不过，能跑起来，不代表每次都跑得顺。 有时链接识别对了，字段却写错了；有时流程启动了，后面的入库又断了；还有时候大模型说已经完成了，打开表格一看，里面还是空的。 你会先怀疑模型，是不是它没听懂，是不是它判断力不够？ 时间长了你发现，真正需要大模型判断的部分其实很少。按照约定，它只要看一眼，这条消息里是不是只有一条链接？还有没有“入库”这个触发词？要分析的东西很少。 麻烦的地方，都在模型外面。
1 三层条件
采集流程要想真正跑起来，至少有三层东西要到位。 第一层是入口判断。 飞书里来了一条消息，系统要先确认它是不是一条公众号链接。如果一条消息里混了多条链接，或者文字里夹着别的指令，就不能直接往下走。这里需要模型，但它做的是很小的局部判断，不是让它临场设计整套流程。 第二层是内容抓取。 公众号原文并不是你后台大模型直接读取内容的，这一步要靠预置的脚本。脚本能不能拿到正文，失败以后怎么返回错误，返回的内容长什么样，这些都不是模型自己能凭感觉解决的。 模型再强，也不能替代一个真正能工作的抓取程序。 第三层是飞书入库。 多维表格不是喊一句“写进去”，就会自己多一条记录。要调用飞书 CLI，要知道写哪张表、哪几个字段、状态怎么标、来源怎么留。字段名一变，权限一断，命令参数一错，整个流程都会卡住。 所以这个任务说简单也简单，说复杂也复杂。 简单的是模型不需要理解整篇文章，不需要给文章打分，不需要写总结。复杂的是它必须被放进一套已经搭好的管道里。入口、脚本、表格、错误处理，每一步都要有边界。 这也是我后来意识到的关键：固定流程里，大模型最好不要承担太多自由发挥。
2 约束价值
很多人比较 AI，习惯先问哪个模型更强。 Gemini、Claude 确实强，复杂推理、长上下文、多轮协作，它们会稳很多。Deepseek、Kimi 在某些长任务里显得吃力。不吹不黑，客观讲，这是公认的认知。 但固定流程和开放任务不是一类东西。 开放任务考验模型的综合能力。 你把一堆材料交给它，让它自己判断问题、拆解任务、选择路径、组织答案，强模型当然更有优势。比如写代码、开发网站、整理你的知识库……，简单说，不是一句话、两句话说得清楚的任务，都属于这种。 固定流程考验的是另一件事：你有没有把任务拆到足够清楚，有没有不折不扣的执行到位，让模型只在该判断的地方判断，这些都是偏向于指令遵循的能力，按部就班，基本不会出错。 开篇我们说的那个入库流程。消息从哪里来，先检查什么，检查通过以后调哪个脚本，脚本返回以后写到哪张表，失败时停在哪一步，这些东西一旦提前写清楚，模型就不再需要猜。它只是在一个节点上做判断，然后把结果交给下一步。 这时候，能力差距会被流程吸收掉一部分。 不是说模型能力不重要。 模型当然重要，尤其是开放问题、复杂写作、长链路推理。可一旦任务变成固定流程，真正决定稳定性的，就会从“模型能不能临场发挥”转向“外部约束有没有写清楚”。 这套东西就是最近特别火的概念，叫做 harness。对创作者和个人工作流来说，更重要的是理解它背后的朴素事实：给模型一套明确的轨道，模型就不用每次重新发明路线。
3 写进系统
写作其实也是同一件事。 你只说一句“帮我写一篇公众号文章”，模型大概率能给你一篇完整稿。标题有，开头有，案例有，结尾也有。你读完会觉得，讲得都对，但啥也没说，而且你大概率能看到满篇的破折号、引号、无序列表，完整不等于有价值，顺滑也不等于像人写的。 它不知道你讨厌报告腔，不知道你不喜欢一串排比，不知道 intro 要用引用格式，也不知道正文不能靠空行制造节奏。判断要不要交代来源？逐字稿和文章有什么区别？ 发布前还要检查标题、摘要、标签和交付物，等等。 作为内容工作者，这些东西当然都在你脑子里，但如果只存在脑子里，你每次写稿都要重新解释。 解释得细一点，结果就好一点；解释欠缺一点，稿子又是不痛不痒的平均写法。它没有人味，会把文章写得很完整，很安全，但任何人都可以署名，并不是你的东西。 所以真正要沉淀的，不是一条更长的 prompt。 prompt 解决一次生成，reference 才开始解决长期复用。 哪些开头能用，哪些句式要警惕，什么叫自然段行文，什么情况下必须重写，三轮校验分别检查什么，这些都应该写进 reference。 schema 负责把控输出，workflow 负责确认步骤，review 负责把关质量。 SKILL.md 文件更像入口。 它告诉模型什么时候触发这个 skill，默认要读哪些 reference，要走什么工作流。 真正的灵魂不在入口里，而在那些细碎的规则和失败记录里。每一次你指出“这里太像 AI”，下一次就应该变成一条更具体的审校规则；每一次流程跑偏，下一次就应该变成一条更清楚的边界。 这件事听起来很简单，但你真的要做，很难。
4 你的真正资产
模型会变。 今天一个模型强，明天另一个模型更强，再过一阵还会有新的模型冒出来。如果你的能力只关注一套模型，模型一变，优势就很容易被抹平。 只有一套属于自己的工作流可以留下来。 你怎么判断选题，怎么拆任务，怎么调用工具，怎么审稿，怎么决定一条视频需要什么画面，怎么在发布前检查标题、摘要和标签，这些东西沉淀下来以后，就不会跟着模型版本一起消失。 不管你用千问、kimi，还是claude、gemini，都不重要，它们会变成你自己的生产系统。 对个人创作者来说，这个判断尤其重要。 我们以前很容易把 AI 使用能力理解成 prompt 能力，好像谁能写出一个厉害提示词，谁就掌握了 AI。现在我更愿意把它理解成系统建设能力，prompt 只是入口，规则是轨道，reference 是记忆，schema 是边界，校验是质量闸门。 这套系统一开始一定很粗糙。 几条规则，几个脚本，几份审校清单，几个还不稳定的流程。 但它会慢慢长出来，一个流程跑通了，就留下来；一个表达被指出不对，就写进审校；一个字段忘了填，就补进 schema；一次发布出问题，就变成下一次发布前的检查项。 这才是 AI 工作流真正进入生产的方式，它应该是逐渐迭代的。 模型提供能力，约束决定能力怎么被使用。能把约束写清楚的人，才是在把 AI 从一次性对话，变成自己的长期生产系统。 你觉得呢？
<section style="margin: 28px 0 14px 0; text-align: center; color: #d46b2c; font-size: 15px; font-weight: 700; line-height: 1.8;"> 扫码直达 </section>