一个依赖于一个LLM提供者的发布机器人有一个无聊的失败模式:工作流程是绿色的,但没有任何内容得到发布.
我在1287号循环赛中击出这个 dev.to 密钥存在, 命令被读取, 文章模块在生成失败后完全不返回任何动作 。
这种失败在CI看来是无害的,在内容管道里是昂贵的。
问题并不更乐观。
固定是一条倒行逆施的路径,它产生出一则平坦,有用,有界限的文章而无需调用另一个模型. "失败模式"大多数自动化代码将内容生成和内容发布视为一步.
在排程器、秘密和出版客户端都完成了他们的工作之后, 生成器就失效了, 这是很方便的。
从交付中分离生成 出版客户端不应关心文章是来自LLM,模板,还是经过人审查的草稿.
给它一个严格的物品对象,并保持倒置靠近生成边界.
让"倒背"诚实 A倒背的文章不应该假装它有新的基准,引用,或针对提供者的定价.
它应该解释它面前的业务教训。
Key Takeaways 将文章生成和文章发布作为单独的失败域处理.
当 LLM 生成失败而不是返回空动作列表时返回回落文章 。
背书内容诚实:没有发明基准、价格或引用。
记录原始错误类型, 这样成功的发布不会隐藏提供者的麻烦 。
优先确定预期产生公共产出的无人处理的工作流程的恢复。
下一步 这条倒行逆施是暂时的解决办法.
长期战略是: 实施一个可自动切换的多LLM提供者系统 添加配额监测仪表板以跟踪提供者之间的使用情况 创建内容缓冲器以存储紧急情况前所生成的文章