编者按： 为什么在强化学习（RL）中，模型往往需要消耗比有监督学习多出数个数量级的计算资源，却只能换来看似微薄的性能提升，且常常陷入训练不稳定的泥潭？

本文从信息论角度出发，对比了有监督学习与强化学习在单位样本中可获取信息量的根本差异：前者通过明确的正确标签直接提供高信息密度的学习信号，而后者仅依赖二元的成功/失败反馈，其信息熵在通过率极低或极高时趋近于零。作者进一步指出，只有当模型的“通过率”处于约 50% 的“金发姑娘区”时，RL 才能高效学习，而这通常只出现在训练末期。此外，文章还剖析了 RL 中梯度估计方差巨大、容易被简单启发式策略主导、难以培养通用推理能力等深层问题，并反思了人类学习机制与当前 model-free RL 的本质差距。

这篇文章提醒我们：若想让强化学习真正释放其潜力，不能仅靠堆算力，而必须重新思考如何设计更密集、更结构化的反馈机制 —— 否则，我们可能只是在用极其昂贵的方式，重复确认一个早已写在预训练权重里的答案。

作者 | Dwarkesh Patel

编译 | 岳扬

最近，人们[1]一直在讨论[2]：在强化学习（RL）中生成单个样本所需的计算量（FLOPs）远高于有监督学习（supervised learning）。在预训练阶段，模型对每一个用于训练的 token 都能立即获得一个学习信号；而在 RL 中，必须展开一整条长达数万 tokens 的推理思维链，才能在最后得到一个奖励信号（例如，我写的代码单元测试是否通过？这道数学题的答案是否正确？等等）。

但这只是问题的一半。这里有一种简单的方法可以比较强化学习与有监督学习的学习效率：

Bits/FLOP = Samples/Flop × Bits/Sample

我还没听到有人讨论我们公式中的这一项：Bits/Sample（每个样本包含多少有用信息）。而且在训练的大部分阶段，强化学习的每一个样本所包含的“有效学习信息量”比有监督学习要低得多。

01 用大白话来说

在有监督学习（也就是预训练）中，模型只是在疯狂吸收信息（bits）。每一个 token 都像是一条线索，它不仅能帮你理解语言本身的构造，还能让你窥见创造这段语言的思维过程，以及那个思维所感知的现实世界。在训练初期，当你用一个完全随机初始化的模型时，你对这些内容都处于最大程度的不确定状态。因此，每个 token 都会让你“恍然大悟”。而且你会立刻得到一个精确的信号，知道自己对正确答案的预测错得多离谱，以及需要调整哪些参数来减少错误。

假设你从一个随机初始化的模型开始，并启动训练。如果你使用有监督学习对 “The sky is” 这个短语做 next-token-prediction，那么训练循环会这样工作：“正确答案其实是 ‘blue’。你预测 ‘blue’ 的概率只有 0.001%。现在，请大幅加强那些本该指向 ‘blue’ 的连接权重。好了，下一个 token。”

而在使用策略梯度（policy gradient）的强化学习中，你会增加所有回答正确的轨迹的权重，并降低所有回答错误的轨迹的权重。但问题是，一个还没怎么学会东西的模型，几乎不可能凭运气就答对。

如果你用 RL 来做“The sky is”的 next-token-prediction，训练循环大概会是这样：“好吧，‘halcyon’ 是错的，别再做导致输出‘halcyon’的操作了…… 好吧，‘serendipity’ 也是错的……” 然后就这样反复试错，猜错的次数差不多得有词汇表总量那么多（约 10 万次）。

02 详细分析

让我们思考一下：随着通过率（p）的变化，每个样本所能获得的最大信息量（bits/sample）会如何变化。这里的“通过率”指的是你给出正确答案的概率。 为简化起见，我们假设答案长度只有一个词元。那么，对于一个完全未经训练的模型，其通过率仅仅是 1/（词汇表大小）。

在有监督学习中，每个样本都会明确告诉你正确标签是什么。你学到的新信息量，取决于你看到正确答案时有多“惊讶” —— 你的通过率越低（即正确答案的先验概率越小），你从这个标签中学到的东西就越多。信息熵的基本公式告诉我们：在有监督学习中，你从每个样本中最多可以学到 -log(p) bits 的信息。

而在强化学习中，你只会被告知答案是否正确。你能从中提取的信息量，受限于你对这个二元结果（对/错）的不确定性。如果你几乎总是通过（p ≈ 1）或几乎总是失败（p ≈ 0），那么每次试验都很难让你感到意外。当通过的概率像抛硬币一样时（p ≈ 0.5），你学到的东西最多。 对于一个二元随机变量，其信息量的上限由熵公式给出：在 RL 中，你从每个样本中最多能学到 Entropy(p) = -p log(p) - (1-p) log(1-p)1 bits 的信息。

好，我们来画图。

看起来还不算太糟。是的，在通过率前 50% 的范围内，预训练明显更好，但在后 50% 的范围内，强化学习表现更佳。然而，这张图极具误导性。根据缩放定律（scaling laws）中的幂律关系，每当你想把“通过率”（pass rate）提升一个数量级，你都需要投入大致相同量级的计算资源。 如果你花了 X FLOPs 将通过率从 1/100,000 提升到 1/10,000，那么你也需要 X FLOPs 才能将通过率从 1/10,000 提升到 1/1,000。因此，我们应该使用对数刻度来表示通过率 —— 以便使 X 轴的每一单位增量对应于相同数量的计算开销（FLOPs）。

这张图看起来真令人沮丧。强化学习在样本信息密度上与预训练相当的区域，仅仅是训练末期的一小段，而且此时模型本身已经相当不错了。

再次强调，这一问题完全独立于另一个观点：即从强化学习中获取单个样本（也就是在得到任何信号前必须完整展开一整条推理轨迹）可能需要耗费高出数百万倍的计算量。

03 方差（variance）让实际情况甚至比这更糟

训练初期的强化学习，实际情况其实比上面描述的更为严峻。当通过率很低时，对梯度的估计会变得极其混乱且难以预测。 要么在当前 batch 生成的样本中，根本就没有采样到正确答案，在这种情况下，几乎得不到任何有用的学习信号。要么碰巧采样到了一次，然后就会得到一个巨大的梯度峰值。模型的训练过程会被剧烈地、不规则地“拉扯”（梯度忽大忽小、方向混乱），如果要追求高效、稳定的训练，这样是非常糟糕的。2

有趣的是，预训练的问题恰好相反，方差（variance）在训练末期会变得非常高。随着预训练的推进，你会逐渐耗尽那些可约损失（reducible loss，即模型实际能从数据中学到的东西）。剩下的主要都是不可约损失（irreducible loss），不可约损失指的是网络文本数据固有的不可预测性。

提示词 “Bob’s favorite color is” 应该怎么结尾？这完全取决于 Bob 是谁。对于这种问题，并不存在什么标准正确答案能让你的超级智能模型通过训练达到很高的预测准确率。但是，模型仍然会根据某人在网上留下的随机答案，获得梯度更新（gradient update）。而这种噪音，会淹没当前 batch 中少数几个真正可学习的词元为我们提供的真实信号。我不知道这是否准确，但预训练阶段末期出现的这种方差激增，似乎与为什么在预训练过程中需要增大 batch sizes 有关。

04 进入 RL 的“金发姑娘区”（Goldilocks zone）

如果 RL 在通过率远高于 1% 时效果最佳，那么这就引出了一个问题：我们该如何设计 RL 训练过程，才能让模型进入并维持在这个高效学习的状态中？

例如，在进行强化学习（RL）时，我们可以通过“预训练更多的数据”和“增加推理时的计算量（比如让模型想得更久）”这两种方式，来让模型变得更聪明、回答得更准确，提高模型的“通过率”，从而让每个样本带来更多的有效信息（bits）。

有观点指出，课程学习（curriculum learning）在预训练中作用不大[3]，但在 RL 中却常常不可或缺[4]。这完全说得通 —— 因为 RL 只有在通过率处于这个“金发姑娘区”时，每个样本才能带来有意义的信息量。因此，为了训练效果好，你必须精心安排学习内容的顺序，要保证问题的难度是随着模型能力的提升而同步加难的，不要一下子给太难的题，也不要一直做太简单的题。

作者提出的“通过率”理论可以很好地解释为什么“自我对弈”（像 AlphaGo 那样自己跟自己下棋）在强化学习历史上特别管用。因为当你跟一个水平旗鼓相当的对手比赛时，你赢的概率大约就是 50%。在这个理论中，50%是一个最佳状态，意味着每次比赛结果（输或赢）带给你的信息量是最大的，能让你学得最快。

但自我对弈并不是唯一能让训练过程中保持高通过率的方法。我们还可以设计出一种“proxy evaluation”机制，这种机制能提供更密集的反馈信息。这里的“密集”具体指以下两种情况之一：

1）Samples/FLOP 密度：通过“proxy evaluation”方法，我们可以在一个强化学习回合刚开始不久时就估算出最终的奖励，而不必真的把整个过程跑完，从而省去了后续的大量计算消耗。这种机制其实就是所谓的“价值函数”。

2）Bits/Sample 密度：我们可以设计一个比最终目标更易达成的 proxy objectives 来指导模型。我能想到的最简单例子是过程奖励模型（process-reward model），它会这样说：“嘿，这次生成的答案虽然错了，但我看得出来，它一开始的推理方向是对的。那我们就给这些早期的 token 增加一点权重。”

Deepseek R1[5] 论文的 4.2 节讨论并解释了，为什么直到现在，要为大语言模型开发出像这样好用的 proxy objectives 依然是一件很难的事情。

05 信息量虽少，但价值高

虽然在强化学习中，每单位计算量（FLOP）学到的 bits 确实少得多，但这些 bits 却非常重要，它们与预训练中获得的 bits 信息不能简单地相提并论。 这其中主要有两个关键原因：

• 预训练就像是让模型把互联网上现有的数据全记下来，但这种知识与“如何完成具有经济价值的任务”只有部分且间接的关联；而强化学习则是直接教模型怎么去解决那些真正有用、能产生价值的实际问题。
• 即使预训练语料中包含了完成某项任务的“操作说明”（比如教程、具体步骤或答案），它也缺少一种关键的东西 —— “思维轨迹”（thinking trace）。也就是说，数据里没有展示模型犯错时是怎么自我纠正的，也没有展示如何利用模型独特的、非人类的方式去组合技能来解决问题。而这些深层的思考痕迹，正是强化学习能提供的东西。

反驳的观点认为，虽然这些信息很有价值，但它们只在一个非常窄的通过率范围内（比如模型已经挺聪明了，但还没完全学会的时候）才能被获取。之所以要强调这一点，是因为在训练的大部分时间里，模型的通过率都极低（接近0），在对数尺度上看，这些低通过率的阶段占据了很大的比重，这意味着真正能高效学习的窗口期其实很短。

现在我们就能理解那些关于 RLHF/RL 仅能激发预训练模型中已有的潜在能力的说法了[6]。事实当然如此。如果预训练模型初始的通过率不够高，那么强化学习的 bits/sample 就会低得可怜，从而根本无法进行有效学习。 围棋对战中的“第 37 手”是一个非常著名的案例，它证明了强化学习确实能教给模型一种全新的、前所未有的策略。值得注意的是，AlphaGo 是通过自我对弈训练出来的（见上文关于自我对弈如何提高通过率的论述），而且以当时的标准来看[7]，其计算消耗之巨令人吃惊。

06 强化学习的不均衡

人们指出，从经验上看，RLVR（强化学习 + 可验证奖励）实际上只是让模型将某种思维模式与特定问题类型关联起来，而并未真正培养出一种更通用的策略 —— 比如先退一步，再仔细思考最佳解法。

仔细想想。怎么会有模型在国际编程竞赛中达到世界顶尖水平，却同时在代码库中留下了大量本可预见的 Bug 和技术债务？

这种奇怪的不均衡该如何解释？也许 RLVR 无法区分一条成功的推理轨迹到底是模型通过某种通用的推理能力（举一反三）做出来的，还是仅仅靠死记硬背某种特定的解题模板（“看到这个形状就用这个套路”）做出来的。因为它没法区分这两种过程，所以模型可能学会了后者（简单的套路），而不是前者（通用的能力）。

当你使用策略梯度（policy gradient）进行 rollout（即让模型生成完整的行为序列）时，那种更复杂、更具泛化能力的策略几乎不可能被采样到；而简单的启发式策略却很容易被采样到，并随着训练不断被强化，出现频率越来越高，最终完全主导模型的行为（即达到“固定”状态）。与此同时，真正的通用策略则越来越难以被观察到，逐渐从训练过程中消失。

那么问题来了，我们该如何搭建一座“短桥”，把简单的启发式解法，和那种更复杂、更具泛化能力的通用策略连接起来？而且，这座桥会不会随着任务时间跨度（time horizons）自然拉长而自动出现 —— 从而迫使模型发展出真正的泛化能力？

我担心的是，那种“先退一步、基于对世界的理解做出明智判断”的通用策略，即使在更长周期的任务中，也依然很难通过“可验证的奖励”（verifiable rewards）被有效识别和强化。因此，要解决这种不均衡问题，不能只靠扩大 RLVR 的规模，而必须设计更鲁棒的训练方法。

07 人类的学习方式

本节我们讨论的只是 model-free RL —— 也就是仅从一个强化学习周期结束时的二元结果（成功/失败）中获得的信息量（bits/sample）。但显然，人类的学习效率远高于此。想想假如有一位连续创业者，我们会说她拥有大量来之不易的智慧和经验。而这些学习成果中，极少部分真正来自上一次创业的“one bit”结果（即创业成功与否）。

目前还不清楚，在机器学习中，人类这种从经验中学习的方式对应的是什么机制。 显然，我们的观察与反思会不断更新我们的世界模型（world model） —— 而且这种更新并不依赖于最终结果是成功还是失败。这在人类学习过程中起着非常重要的作用。

也许我们不该只是想着“如何把 model-free RL 的通过率调到 50% 左右，因为这样做仅仅是试图从一个单一的“成功/失败”结果中，挤出那么一点点微薄的信息。也许我们应该转换思路，去研究人类是如何从环境中获取海量信息的。人类并不像现在的机器那样，只盯着最终的结果（成功或失败），而是能从过程、观察和反思中吸收大量的经验和教训。

1 这个公式的意思是：从一个二元结果中学到的信息量 ＝p(样本正确) × (样本正确时获得的信息量) ＋p(样本错误) × (样本错误时获得的信息量)。

2 感谢 Lukas Berglund 指出我此前在这一点上的阐述有误。

END

本期互动内容 🍻

❓人类从失败中能学到远不止“0/1”的反馈——你觉得 AI 系统要如何模拟这种过程性反思能力？

文中链接

[1]https://www.tobyord.com/writing/inefficiency-of-reinforcement...

[2]https://thinkingmachines.ai/blog/lora/#how-much-capacity-is-n...

[3]https://arxiv.org/pdf/2012.03107

[4]https://arxiv.org/pdf/1707.05300

[5]https://arxiv.org/abs/2501.12948

[6]https://arxiv.org/abs/2510.07364v3

[7]https://epoch.ai/data/ai-models

原文链接：

https://www.dwarkesh.com/p/bits-per-sample

原文链接：https://www.nocobase.com/cn/blog/6-best-open-source-ai-ticket...

之前的文章中，我们梳理了一些可以替代 Zendesk 的开源与自托管 AI 工单系统方案。在文章撰写和资料调研的过程中，我们也持续关注了社区里对相关话题的讨论。 从实际使用体验来看，传统工单系统本质上只是一个记录与流转工具，记录问题、改变状态、最后关闭。至于问题是否被快速理解、是否被正确分派、是否能少走弯路，几乎完全依赖人工经验。 在 Reddit 的技术社区中，有两条讨论引起了我们的注意。

!

越来越多的团队开始尝试引入所谓的 “AI Helpdesk”，希望借助 AI 来缓解支持压力。但在 Reddit 的讨论中，我们看到的反馈却相当一致，也非常直接：

• AI 往往只是生成一段看起来很聪明的回复
• 对实际处理效率的提升非常有限
• 整体流程并没有发生变化，只是在原有系统上多了一个 AI 按钮

如果 AI 只是停留在回复层，而没有真正进入工单流程本身，那它对团队的帮助是非常有限的。

💬 嗨！你正在阅读 NocoBase 博客。NocoBase 是一个极易扩展的 AI 无代码/低代码开发平台，用于构建企业应用、内部工具和各类系统。它完全支持自托管，基于插件架构设计，开发者友好。→ 欢迎在 GitHub 上了解我们

也正是在这样的需求和反馈之下，我们认为，“AI 工单系统”已经不再只是一个简单的产品分类，而更像是一个需要被重新定义的解决方案层级。它不应只是一个会生成回复的系统，而应当是一个能够真正介入流程、自动理解与分派工单、基于知识库给出可用建议，并且能够与企业内部业务系统深度结合的 AI 工单系统。

本文将从 AI 工单系统在 2026 年应具备的核心能力出发，系统性梳理这些能力可以如何在不同系统中实现，帮助你和团队在选型时跳出“是否带 AI”的表层判断，回到效率和结构本身。

2026 AI 工单系统的必备能力

1. 自动理解与摘要 AI 工单系统需要准确理解工单内容，从自然语言描述中提取关键信息，减少人工反复阅读和上下文确认的成本。

2. 智能分类与路由 真正有效的 AI 应当能够自动完成初步分类与优先级判断，并将工单分派给合适的团队或角色，而不是把这些决策继续留给人工处理。

3. 基于知识库的回复建议 AI 的价值在于复用已有知识，通过历史工单和文档给出可编辑的处理建议，而不是直接“自动结案”或输出脱离上下文的通用回答。

4. 流程中的 AI 介入点 AI 应当贯穿工单的完整生命周期，在建单前、处理过程中以及关闭与总结阶段持续发挥作用。

5. 可控、可扩展、可自托管 在企业场景下， AI 工单系统必须支持数据主权和模型可替换，避免被单一 SaaS 锁定，才能在长期发展中保持可控性和扩展空间。

开源 AI 工单系统选型清单

1.NocoBase

官网链接：https://www.nocobase.com/

GitHub 链接：https://github.com/nocobase/nocobase

GitHub Star 数：21.4k

核心定位 NocoBase 是一套以数据模型为核心的开源业务系统平台，通过插件化架构扩展业务能力，并将 AI 能力深度融入系统的核心模块之中。工单、知识库、流程、内部服务台都是其可以构建的业务模块。

🎉基于 NocoBase 2.0 构建的智能工单系统

适合场景

• 希望高度自定义工单流程的 IT / 内部支持团队
• 不满足于标准流程，需要结合内部业务系统的组织
• 对数据主权、自托管、AI 模型可控性有明确要求的企业
• 希望将工单系统逐步升级为内部智能服务平台的团队

AI 扩展方式

NocoBase 的 AI 能力不是附加功能，而是通过 AI 员工深度融入业务系统。

1. 自动理解与摘要

• AI 员工可以理解工单的自然语言描述
• 结合数据模型与字段结构，自动提取关键信息
• 支持生成摘要并写回工单字段，减少人工阅读和上下文确认成本

2. 智能分类与路由

• AI 可作为工作流中的决策节点
• 根据工单内容、字段信息和历史数据进行自动分类
• 计算优先级并分派给对应团队、角色或 SLA 流程

3. 基于知识库的回复建议（RAG）

• 工单解决过程可以自动转为知识条目
• 新工单创建时可基于已有知识推荐相似解决方案
• AI 员工可以辅助查找已有知识，并生成建议回复

4. 流程中的 AI 介入点

• AI 可介入建单前（表单填写辅助）
• 处理过程中（分析、建议、补充信息）
• 关闭阶段（总结工单、沉淀知识）

5. 可控、可扩展、可自托管

• 100% 开源、完全自托管
• 支持多种 AI 模型（OpenAI、Claude、本地模型）
• 插件化架构，可基于企业业务灵活调整系统

2. Frappe Helpdesk

官网链接：https://frappe.io/helpdesk

GitHub 链接：https://github.com/frappe/helpdesk

GitHub Star 数：2.9k

核心定位 Frappe Helpdesk 并不是一个孤立的工单系统，而是 Frappe 业务平台中的一部分，天然与 ERP、CRM、项目管理等模块共享数据模型，更偏向业务系统一体化的服务支持方案。

适合场景

• 已经在使用 ERPNext / Frappe 平台的组织
• 希望将工单与业务数据、客户、订单、资产等信息打通的团队
• 对“系统一致性”和内部数据联动要求高，而非只关注客服功能的企业
• 内部 IT 支持、业务支持型 Helpdesk 场景

AI 扩展方式

Frappe Helpdesk 的可以作为业务平台的一部分，能够让工单自然融入企业已有的数据与流程体系。对于已经使用 ERPNext 的团队来说，它更像是一个业务支持入口，而不是独立的 AI 工单系统产品。

1. 自动理解与基础分类（可扩展）

• 可结合 Frappe 平台已有的数据结构
• 通过外部 LLM 或自建 AI 服务，对工单描述进行基础理解

2. 基于业务数据的辅助建议

• 工单可直接关联 ERP / CRM 数据
• AI 可基于已有业务记录，给出处理参考或背景说明
• 更适合“业务支持型”场景，而非高并发客服场景

3. Chatwoot

官网链接：https://www.chatwoot.com/

GitHub 链接：https://github.com/chatwoot/chatwoot

GitHub Star 数： 27.1k

核心定位 Chatwoot 可以统一承载来自不同渠道的对话，并将这些对话转化为可处理的支持请求或工单。

适合场景

• 需要统一管理 Web Chat、Email、社交媒体、IM 等多渠道支持入口的团队
• 将“对话”作为服务起点，而不是先生成工单的组织
• 希望在支持流程前端引入 AI，减轻人工接待和初步沟通压力的团队

AI 扩展方式

Chatwoot 并不以复杂的工单生命周期管理见长，其 AI 能力更多集中在沟通与入口层。

1. 自动理解与摘要

• Chatwoot 天然以“对话”为核心对象

• 通过接入外部 LLM，可实现：

  • 对话摘要
  • 回复草稿生成
  • 常见问题自动应答

2. 工单触发与前置分流

• 对话可根据规则或 AI 判断转化为工单
• 在建单前完成初步筛选和分流
• 减少无效或重复工单进入后端系统

4. Zammad

官网链接：https://zammad.com/

GitHub 链接：https://github.com/zammad/zammad

GitHub Star 数： 5.4k

核心定位 Zammad 以完整的工单生命周期管理为核心，强调多渠道接入、状态流转、权限与 SLA 管理，是一款流程导向非常明确的 Helpdesk 工具。

适合场景

• 需要一套成熟、结构清晰的 Helpdesk 系统的 IT 支持团队
• 对工单生命周期、权限和 SLA 管理有明确要求的组织
• 希望在稳定工单流程之上，引入 AI 做辅助判断与建议的团队
• 以 Helpdesk 为核心，而非平台化重构的场景

AI 扩展方式

Zammad 本身并不内置 AI 功能，但其规则引擎与 API 设计，使其非常适合在既有流程上叠加 AI 能力。

1. 自动理解与摘要（可扩展）

• 可通过 API / Webhook 接入外部 LLM
• 帮助支持人员快速把握问题核心，减少人工阅读成本

2. 规则驱动的分类与分派

• Zammad 拥有成熟的规则系统
• AI 可辅助完成主题识别、优先级判断
• 结合现有规则，实现更智能的分派与升级逻辑

3. 基于知识库的回复建议

• Zammad 支持知识库模块
• 可通过外部 AI 服务，基于已有知识内容生成回复建议

5. FreeScout

官网链接：https://freescout.net/

GitHub 链接：https://github.com/freescout-help-desk/freescout

GitHub Star 数：4k

核心定位 FreeScout 可以提供一个简单、可控的共享收件箱与工单管理工具，功能聚焦、学习成本低，更接近“开源版 Help Scout”。

适合场景

• 中小团队或初期阶段的支持团队
• 以邮件工单为主要支持渠道的组织
• 预算敏感、希望避免复杂系统引入成本的团队
• 对流程复杂度要求不高，但希望逐步引入 AI 辅助的场景

AI 扩展方式

FreeScout 本身并不内置 AI 能力，但其插件机制和简单的数据结构，使其可以在有限范围内叠加 AI 辅助功能。

1. 基于知识库的回复建议（可扩展）

• 结合已配置的知识库内容、历史工单或预设回复模板
• 利用 LLM 生成可编辑的回复草稿，供支持人员参考和调整
• 更适合处理常见问题或重复性场景，而非复杂、多轮上下文的推理

2. 基于规则的初步分类

• 可结合规则与 AI 辅助判断结果
• 对邮件工单进行初步分类或标签标记

6. Faveo Helpdesk

官网链接：https://www.faveohelpdesk.com/

GitHub 链接：https://github.com/faveosuite/faveo-helpdesk

GitHub Star 数：1.2k

核心定位

Faveo Helpdesk 是基于 Laravel 生态的开源 Helpdesk 系统。内置工单、知识库与基础流程管理能力，强调可读性与可扩展性，适合进行二次开发和功能增强。

适合场景

• 使用 Laravel / PHP 技术栈的团队
• 希望在 Helpdesk 基础之上，逐步引入定制功能或 AI 能力的组织
• 对知识库建设与内容复用有明确需求的支持团队
• 不追求平台级重构，但需要一定扩展空间的场景

AI 扩展方式

Faveo Helpdesk 的 AI 扩展主要依托其知识库结构清晰、代码可扩展的特点，更适合从“内容与建议层”引入 AI。

1. 基于知识库的回复建议

• 内置知识库模块，结构清晰
• 可结合外部 LLM，对知识库内容进行检索与生成
• 为支持人员提供可编辑的回复建议

2. 自动理解与摘要（可扩展）

• 可通过 Laravel 生态中的 AI 服务
• 对工单描述进行基础语义理解与摘要
• 帮助支持人员更快把握问题背景。

结语

在选型过程中，比起功能数量，更应该关注 AI 能够在多深的程度上参与到你的工单流程中，系统是否具备持续扩展这些能力的空间。

随着使用场景的变化，工单系统的边界也在不断延展，从最初的问题记录工具，到内部服务台，再到如今的 AI 驱动的业务支持平台，新一代的工单系统正在逐步成为企业内部协作与服务交付的重要基础设施。

💕如果你在工单系统选型或 AI 工单系统实践中有类似困惑，希望这篇文章能带来一些参考，欢迎分享给更多感兴趣的朋友。

相关阅读：

• 4 个值得关注的开源业务数据管理工具
• 4个适合企业业务流程的轻量化软件（附真实案例）
• 6 个替代 Excel 的企业内部管理软件
• 开发者收藏！10 个减少重复 CRUD 的开源工具
• GitHub Star 数量前 12 的 AI 工作流项目
• 最适合外包交付的 6 个开源无代码与低代码
• GitHub 上星星数量前 10 的 AI CRM 开源项目
• 如何快速搭建一个替换 Excel 的系统？（完整指南）

视频会议技术如何重塑智能硬件生态？深度解析适配难点与落地实践
在智能硬件生态中，视频会议技术已不再是边缘附加功能，而是打通人机交互、设备互联与远程协作的核心纽带。从家用智能摄像头到工业巡检机器人，从车载系统到AR眼镜，视频会议依赖的低延时、高稳定音视频传输能力，正推动各类硬件突破物理限制，为用户带来更具沉浸感的远程交互体验。
智能硬件适配视频会议的核心技术挑战
与手机、电脑等通用设备不同，智能硬件因自身特性，在集成视频会议功能时面临三大关键挑战：
算力资源受限：多数智能硬件采用轻量化芯片（如ARM Cortex-M系列），难以支撑视频会议所需的复杂编码和解码运算。因此需定制低复杂度算法，如裁剪非必要画质增强模块，采用H.264 Baseline Profile等轻量级编码标准，在保证视频会议基础画质的同时降低CPU占用。
网络环境不稳定：智能硬件常处于弱网或特殊频段环境（如家用设备依赖易干扰的Wi-Fi 2.4G频段、工业设备位于偏远无公网区域），视频会议需集成抗丢包技术（如FEC前向纠错、ARQ自动重传），即使在30%-50%丢包率下，也能通过冗余数据补全视频帧，避免画面卡顿或声音断续。
功耗控制严苛：智能硬件多依赖电池供电，视频会议的持续音视频传输易快速消耗电量。需通过动态码率调节技术，在网络良好时提升码率保证视频质量，电量不足时切换低码率模式，延长设备续航时间。
视频会议技术在智能硬件场景的落地实践

1. 家用智能硬件：家庭视频会议的便捷入口
   家用智能摄像头已成为家庭视频会议的重要载体，核心需求包括低延时视频通话、双向语音交互等。实时视频预览方面，摄像头采用“极速首帧”技术，优先传输关键帧（I帧）并简化编码复杂度，让用户打开App即可快速接入视频会议，端到端延时控制在500ms以内。双向语音对讲功能则集成AI降噪算法，精准区分人声与环境噪音（如风声、家电声），同时通过回声消除技术避免啸叫，确保家庭视频会议清晰流畅。
2. 智能车载系统：移动场景下的视频会议解决方案
   智能车载系统中的视频会议应用聚焦于移动办公、远程监控等场景，对稳定性和抗干扰性要求极高。车载视频会议优化方面，系统采用自适应抖动缓冲技术，根据车速和网络波动动态调整缓冲时长，将通话延时控制在300ms以内；同时针对车载环境优化语音增强算法，抑制发动机噪音、胎噪等低频干扰，提升视频会议清晰度。远程控车场景中，车主可通过视频会议功能实时查看车辆周边画面，异常移动时快速推送告警视频，响应时间不超过1秒。
3. 工业级智能硬件：远程协作的视频会议支撑
   工业领域中，视频会议技术赋能巡检机器人、AR智能眼镜等硬件，实现高效远程协作与故障诊断。工业巡检机器人通过视频会议技术将现场画面实时回传至中控室，采用边缘节点部署搭建本地化网络，避免公网延迟；同时利用硬件编码加速降低算力消耗，确保视频流稳定不中断。AR智能眼镜则支持工程师与远端专家进行视频会议，专家通过AR标注功能在画面上标记故障点，标注内容与视频流同步叠加，实现“远程手把手指导”，端到端延时低于200ms以保证同步性。
   智能硬件领域视频会议技术的未来趋势
   随着技术发展，视频会议在智能硬件领域的应用将呈现三大趋势：
   多模态交互融合：视频会议将与语音识别、手势控制等技术结合，如智能音箱通过视频会议捕捉用户表情与语音，实现更精准的意图判断。
   端云协同优化：云端分担智能硬件的编码压力，硬件负责采集预处理，云端完成高清编码与AI增强，平衡视频质量与设备功耗。
   标准化协议普及：统一的视频会议协议将打破品牌壁垒，实现不同智能硬件间的无缝互联，如智能手表可直接调取家中摄像头进行视频会议。
   视频会议技术正深度融入智能硬件生态，通过解决适配难点与场景化落地，不断拓展远程交互的边界。未来，随着技术的持续优化，智能硬件与视频会议的结合将为用户带来更高效、更沉浸的使用体验。

大家好，我是良许。

在嵌入式开发中，IIC（I2C）总线可以说是最常用的通信协议之一了。

无论是读取传感器数据、控制EEPROM存储器，还是与各种外设进行通信，IIC总线都扮演着重要角色。

但很多初学者在使用IIC时，往往只关注软件层面的时序和协议，却忽略了硬件层面的关键设计。

今天我就来聊聊IIC总线硬件部分的两个核心要点：开漏输出和上拉电阻。

理解了这两点，你才能真正掌握IIC总线的精髓。

1. IIC总线的基本结构

在深入讲解之前，我们先简单回顾一下IIC总线的基本构成。

IIC总线只需要两根信号线就能实现多主机、多从机之间的通信，这两根线分别是：

• SCL（Serial Clock）：时钟线，由主机产生时钟信号
• SDA（Serial Data）：数据线，用于主从设备之间的数据传输

一条IIC总线上可以挂载多个设备，每个设备都有唯一的地址。

这种简洁的设计让IIC总线在嵌入式系统中广受欢迎，特别是在PCB布线空间有限的场景下。

但问题来了：多个设备共用同一根数据线和时钟线，它们是如何避免冲突的呢？这就要说到IIC总线硬件设计的核心机制了。

2. 开漏输出：IIC总线的灵魂

2.1 什么是开漏输出

开漏输出（Open-Drain）是IIC总线最核心的硬件特性。

要理解开漏输出，我们先来看看常见的GPIO输出模式。

在普通的推挽输出（Push-Pull）模式下，GPIO引脚可以主动输出高电平（通过上管导通）或低电平（通过下管导通）。

这种模式下，引脚能够提供较强的驱动能力，但有个致命问题：如果两个推挽输出的引脚连接在一起，一个输出高电平，另一个输出低电平，就会造成短路，可能烧毁芯片。

而开漏输出则不同，它的内部结构只有一个下拉的NMOS管，没有上拉的PMOS管。这意味着：

• 当GPIO输出低电平时，NMOS管导通，引脚被拉到地（GND），呈现低电平
• 当GPIO输出高电平时，NMOS管截止，引脚呈现高阻态（既不输出高也不输出低）

这种"只能拉低，不能拉高"的特性，正是开漏输出的精髓所在。

2.2 开漏输出的优势

你可能会问：只能拉低不能拉高，这不是很鸡肋吗？恰恰相反，这正是IIC总线能够实现多设备共享总线的关键。

第一个优势：线与逻辑

多个开漏输出连接在同一根线上时，会形成"线与"（Wired-AND）逻辑。

只要有任何一个设备输出低电平，整条总线就是低电平；只有当所有设备都输出高阻态时，总线才能被上拉电阻拉到高电平。

这种特性在IIC总线中至关重要。

比如在多主机系统中，如果两个主机同时发送数据产生冲突，通过检测总线电平，主机可以发现冲突并进行仲裁。

发送"1"的主机如果检测到总线为"0"，就知道有其他主机在发送数据，会主动放弃总线控制权。

第二个优势：电平转换

开漏输出配合上拉电阻，可以轻松实现不同电压域之间的电平转换。

比如一个3.3V的MCU和一个5V的传感器通信，只需要将上拉电阻接到5V电源，就能实现电平匹配。

3.3V的MCU输出低电平时可以将总线拉低，输出高阻态时总线被上拉到5V，这个5V电平不会损坏MCU（因为MCU引脚是高阻态，没有电流流入）。

第三个优势：避免总线冲突

在推挽输出模式下，如果两个设备同时驱动总线，一个输出高一个输出低，就会造成短路。

而开漏输出永远不会主动输出高电平，最多只是高阻态，因此不会产生短路风险。

2.3 STM32中的开漏配置

在STM32中配置IIC引脚为开漏输出非常简单。

使用HAL库的话，代码如下：

void MX_I2C1_Init(void)
{
    GPIO_InitTypeDef GPIO_InitStruct = {0};
    
    /* 使能GPIOB时钟 */
    __HAL_RCC_GPIOB_CLK_ENABLE();
    
    /* 配置IIC引脚：PB6(SCL), PB7(SDA) */
    GPIO_InitStruct.Pin = GPIO_PIN_6 | GPIO_PIN_7;
    GPIO_InitStruct.Mode = GPIO_MODE_AF_OD;  // 复用开漏输出
    GPIO_InitStruct.Pull = GPIO_NOPULL;      // 不使用内部上下拉
    GPIO_InitStruct.Speed = GPIO_SPEED_FREQ_HIGH;
    GPIO_InitStruct.Alternate = GPIO_AF4_I2C1;
    HAL_GPIO_Init(GPIOB, &GPIO_InitStruct);
    
    /* 配置IIC外设 */
    hi2c1.Instance = I2C1;
    hi2c1.Init.ClockSpeed = 100000;  // 100kHz标准速率
    hi2c1.Init.DutyCycle = I2C_DUTYCYCLE_2;
    hi2c1.Init.OwnAddress1 = 0;
    hi2c1.Init.AddressingMode = I2C_ADDRESSINGMODE_7BIT;
    hi2c1.Init.DualAddressMode = I2C_DUALADDRESS_DISABLE;
    HAL_I2C_Init(&hi2c1);
}

注意代码中的 GPIO_MODE_AF_OD，这就是配置为复用功能的开漏输出模式。

同时 GPIO_NOPULL 表示不使用芯片内部的上下拉电阻，因为我们需要外部上拉电阻。

3. 上拉电阻：开漏输出的最佳拍档

3.1 为什么需要上拉电阻

前面提到，开漏输出只能拉低电平，不能主动输出高电平。

那么高电平从哪里来呢？答案就是上拉电阻。

上拉电阻一端连接到电源（通常是VCC），另一端连接到IIC总线。

当所有设备的开漏输出都处于高阻态时，上拉电阻会将总线"拉"到高电平。

当任何一个设备输出低电平时，由于低电平的驱动能力远强于上拉电阻，总线会被拉到低电平。

可以把上拉电阻想象成一根弹簧，总是试图把总线拉到高电平。

而开漏输出就像一只手，需要的时候可以把总线按下去（拉低），松开手（高阻态）时弹簧就会把总线弹回高电平。

3.2 上拉电阻的阻值选择

上拉电阻的阻值选择是个技术活，选大了选小了都不行。

阻值太小的问题：

如果上拉电阻太小（比如1kΩ），虽然可以提供很强的上拉能力，但会带来两个问题：

1. 功耗增加。当总线被拉低时，会有较大的电流从VCC经过上拉电阻流向GND，计算公式为I=VCC/Rpullup。以3.3V系统为例，1kΩ电阻会产生3.3mA的电流，在低功耗应用中这是不可接受的。
2. 增加驱动负担。开漏输出需要吸收更大的电流才能将总线拉低，可能超出芯片的驱动能力。

阻值太大的问题：

如果上拉电阻太大（比如100kΩ），上拉能力会变弱，带来的问题是：

1. 上升沿变慢。总线电容（包括走线电容、引脚电容等）需要通过上拉电阻充电才能从低电平变为高电平。阻值越大，充电时间越长，上升沿越慢。时间常数可以用 τ=R×C 计算。
2. 抗干扰能力下降。较弱的上拉能力使得总线更容易受到外部干扰的影响。

合适的阻值范围：

一般来说，IIC总线的上拉电阻推荐范围是：

• 标准速率（100kHz）：4.7kΩ ~ 10kΩ
• 快速模式（400kHz）：2.2kΩ ~ 4.7kΩ
• 高速模式（3.4MHz）：需要更精确的计算，通常在1kΩ左右

最常用的值是4.7kΩ，这是一个经过实践检验的经验值，在大多数应用场景下都能良好工作。

3.3 上拉电阻的计算方法

如果你想精确计算上拉电阻的阻值，可以使用以下公式。首先需要确定总线电容 Cbus，它包括：

• 走线电容（约10pF/cm）
• 每个设备的引脚电容（数据手册会标明，通常5~10pF）
• 其他寄生电容

假设IIC总线时钟频率为 fSCL，上升时间要求为tr

（标准模式下最大1000ns，快速模式下最大300ns），则上拉电阻的最大值为：

同时，为了保证足够的驱动能力，上拉电阻的最小值需要满足：

其中 VOL(max) 是输出低电平的最大值（通常0.4V），IOL是开漏输出的最大吸收电流（查阅芯片手册）。

举个实际例子，假设：

• 总线电容 Cbus=100pF
• 上升时间要求 tr=1000ns（标准模式）
• 电源电压 VCC=3.3V
• 最大吸收电流 IOL=3mA

则：

因此上拉电阻应该选择在1kΩ到11.8kΩ之间，选择4.7kΩ是非常合适的。

3.4 多个上拉电阻并联的情况

在实际应用中，有时候会遇到多个模块都带有上拉电阻的情况。

比如你的主板上有上拉电阻，外接的传感器模块上也有上拉电阻。

这时候多个电阻会并联，等效电阻会变小。

两个电阻并联的等效电阻计算公式为：

比如两个4.7kΩ的电阻并联，等效电阻为：

这个值仍然在合理范围内，但如果并联的电阻太多，等效电阻可能会过小，导致功耗增加。

因此在设计时，建议只在主板上放置上拉电阻，外接模块上不要再加上拉电阻。

如果模块已经有上拉电阻，可以考虑用0欧电阻或跳线帽来选择性地启用。

4. 实际应用中的注意事项

4.1 上拉电阻的位置

上拉电阻应该尽量靠近主控芯片放置，而不是分散在各个从设备附近。

这样可以减少总线的寄生电容，提高信号质量。

在多层PCB中，建议将IIC走线放在内层，并在下方铺设完整的地平面，以减少干扰。

4.2 长距离传输的考虑

IIC总线本来是为板级通信设计的，传输距离通常在几厘米到几十厘米之间。

如果需要长距离传输（超过1米），需要特别注意：

1. 降低通信速率，比如从400kHz降到100kHz甚至更低
2. 使用更小的上拉电阻（但不要小于最小值）
3. 考虑使用IIC总线扩展芯片或差分信号方案
4. 增加滤波电容，提高抗干扰能力

4.3 调试技巧

在调试IIC通信问题时，可以用示波器观察SCL和SDA信号。正常情况下应该看到：

1. 高电平接近VCC，低电平接近0V
2. 上升沿呈指数曲线（RC充电曲线），下降沿陡峭
3. 没有明显的振铃或过冲

如果上升沿太慢，说明上拉电阻太大或总线电容太大；如果有振铃，可能需要增加串联电阻或并联电容进行阻尼。

4.4 软件模拟IIC的配置

有时候我们需要用GPIO模拟IIC（比如硬件IIC引脚被占用了），这时候也要配置为开漏输出。

示例代码如下：

/* 初始化模拟IIC的GPIO */
void Soft_I2C_Init(void)
{
    GPIO_InitTypeDef GPIO_InitStruct = {0};
    
    __HAL_RCC_GPIOB_CLK_ENABLE();
    
    /* 配置SCL和SDA为开漏输出 */
    GPIO_InitStruct.Pin = I2C_SCL_PIN | I2C_SDA_PIN;
    GPIO_InitStruct.Mode = GPIO_MODE_OUTPUT_OD;  // 开漏输出
    GPIO_InitStruct.Pull = GPIO_NOPULL;
    GPIO_InitStruct.Speed = GPIO_SPEED_FREQ_HIGH;
    HAL_GPIO_Init(I2C_GPIO_PORT, &GPIO_InitStruct);
    
    /* 初始状态设为高电平（实际是高阻态） */
    HAL_GPIO_WritePin(I2C_GPIO_PORT, I2C_SCL_PIN, GPIO_PIN_SET);
    HAL_GPIO_WritePin(I2C_GPIO_PORT, I2C_SDA_PIN, GPIO_PIN_SET);
}

/* 读取SDA电平 */
uint8_t I2C_SDA_Read(void)
{
    return HAL_GPIO_ReadPin(I2C_GPIO_PORT, I2C_SDA_PIN);
}

/* 设置SDA为低电平 */
void I2C_SDA_Low(void)
{
    HAL_GPIO_WritePin(I2C_GPIO_PORT, I2C_SDA_PIN, GPIO_PIN_RESET);
}

/* 设置SDA为高电平（高阻态） */
void I2C_SDA_High(void)
{
    HAL_GPIO_WritePin(I2C_GPIO_PORT, I2C_SDA_PIN, GPIO_PIN_SET);
}

注意在读取SDA电平时，要先将SDA设为高阻态（输出高电平），然后再读取引脚状态。

这样才能正确读取从设备发送的应答信号。

5. 总结

IIC总线的硬件设计看似简单，实则蕴含着精妙的设计思想。

开漏输出和上拉电阻这两个关键点，共同构成了IIC总线多设备共享、双向通信的基础。

开漏输出提供了"线与"逻辑，使得多个设备可以安全地共享同一根总线，避免了总线冲突的风险。

而上拉电阻则为开漏输出提供了高电平，同时还能实现电平转换、限制电流等功能。

两者配合，才能让IIC总线稳定可靠地工作。

在实际应用中，正确选择上拉电阻的阻值、合理布局PCB、注意信号完整性，都是保证IIC通信质量的关键。

希望通过今天的讲解，能让大家对IIC总线有更深入的理解，在以后的项目中少走弯路。

如果你在使用IIC总线时遇到通信不稳定、速率上不去等问题，不妨从硬件层面入手，检查一下是不是开漏输出配置不对，或者上拉电阻选择不合适。

很多时候，硬件问题比软件问题更隐蔽，但一旦找到根源，解决起来反而更简单。

更多编程学习资源

• C语言零基础入门电子书-2026最新版
• STM32零基础入门电子书-2026最新版
• FreeRTOS零基础入门电子书-2026最新版
• C++ 零基础入门电子书-2026最新版
• 51单片机零基础入门学习路线
• AD画板零基础入门学习路线
• C语言零基础入门学习路线
• C++语言零基础入门学习路线
• ESP32零基础入门学习路线
• FreeRTOS零基础入门学习路线
• Linux应用开发零基础入门学习路线
• Linux底层开发零基础入门学习路线
• LVGL零基础入门学习路线
• QT零基础入门学习路线
• STM32零基础入门学习路线

Clawdbot 对接飞书详细教程 手把手搭建你的专属 AI 助手

注意本教程在 Linux 系统下进行

Clawdbot 由于 Claude 的版权问题，已更名为 Moltbot，因此本教程基于最新版本编写。下面进入安装流程

首先准备一台闲置的云服务器或 VPS（推荐使用香港或海外节点）。由于 Clawdbot 运行时权限较大，出于安全考虑，不建议在本地或工作机上安装，推荐在一台独立的空服务器上部署。准备完成后，登录到服务器。

安装

如果你不想安装，可以直接使用阿里云的Clawdbot 一键部署，部署之后可以直接跳到对接飞书。

第一步安装 Git

# 安装 Git
sudo apt update
sudo apt install git -y

第二步安装 Node.js

# 安装 NVM
# 国内使用 gitee 的镜像源
curl -o- https://gitee.com/RubyMetric/nvm-cn/raw/main/install.sh | bash

# 国外使用
curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.1/install.sh | bash

# 重新加载环境变量
source ~/.bashrc

# 安装 Node.js 22
nvm install 22

# 查看 nodejs 版本
node -v # 输出 v22 即可，版本只要 22 就行

安装 Moltbot (原 Clawdbot)

# 使用官方脚本安装
curl -fsSL https://molt.bot/install.sh | bash

服务器在国内，如果安装失败的话，可能需要解决网络问题

其他平台安装方式请参考Moltbot (原Clawdbot) 安装文档

你会看到如下图输出

如果首次安装，时间会很长，需要耐心等待。
如果最后输出如下内容：

→ npm install failed; cleaning up and retrying...

新的脚本服务器内存要求变高了，据我使用下来 2G 内存，肯定会 OOM，如果出错的话，建议使用 swap 把硬盘空间当作交互内存使用。

成功之后会输出如下图片

第一个选项选择 yes, 就是询问你是否知道风险的。
第二步选择 QuickStart

第三步选择模型服务商，这里选择 Qwen，免费额度充足，适合入门使用

选择千问模型后，会提供一个链接，复制并在浏览器中打开，如下图

打开浏览器后，会看到如下界面。由于我已登录过，所以显示账户信息；如果尚未登录，按照提示完成登录即可。

登录完成后，会出现以下选项，提示选择对应的千问模型，如下图

选择默认模型即可。接下来会提示选择 channel，这里先跳过，后续再添加

继续下面选择 skills，也是选择 No，如下图

继续下面选择 hooks，也是使用空格选择 No，如下图

然后等待安装完成，最后会出现以下选项，这里选择 TUI

如果看到 TUI 聊天界面，说明安装成功，可以尝试输入 Hello 进行测试。

然后直接使用 ctrl+c 先关闭，后面我们再来设置

查看服务

可以使用下面的命令来查看

clawdbot status

会看到如下图的结果就说明服务启动了

访问 Web UI 面板

如何访问面板？服务监听在 http://127.0.0.1:18789/ 端口上，我们现在通过 ssh 隧道来访问，输入下面的命令

ssh -N -L 18789:127.0.0.1:18789 用户名@服务器IP
# 回车之后
用户名@服务器IP's password: # 输入密码

然后在浏览器打开 http://127.0.0.1:18789/, 你会看到 Dashboard 了，如下图

图中显示的是未授权状态，回到服务器，输入以下命令

clawdbot dashboard

会看到下面的面板数据

复制对应的 Dashboard URL 到浏览器打开，即可正常查看聊天记录。

至此 Clawdbot 已安装完成，可以正常访问了。然后聊天框里面首次输入 Hello, Clawdbot 会询问你他应该叫什么，应该叫你什么。就是你需要给它设置个名字，还有 bot 改叫你什么。你可以在聊天框这么输入

Name: Clawdbot

My Name: Boss

对接飞书

首先安装飞书插件，输入以下命令

clawdbot plugins install @m1heng-clawd/feishu

登录飞书开放平台 https://open.feishu.cn，点击「开发者后台 -> 创建企业自建应用」，如下图

然后点击创建应用，如下

创建完成后，首先到凭据管理中获取 App ID 和 App Secret，注意保存，后续配置需要使用。

然后添加机器人，如下操作

首先配置个名字

飞书的其他配置先暂停，回到服务器配置 Clawdbot 的飞书参数

添加飞书配置

clawdbot config set channels.feishu.appId "飞书 app id"

clawdbot config set channels.feishu.appSecret "飞书 app secret"

clawdbot config set channels.feishu.enabled true

# 推荐使用 websocket
clawdbot config set channels.feishu.connectionMode websocket

clawdbot config set channels.feishu.dmPolicy pairing

clawdbot config set channels.feishu.groupPolicy allowlist

clawdbot config set channels.feishu.requireMention true

配置完成之后，重启

clawdbot gateway restart

重启完成后回到飞书，找到「事件和回调」，选择长连接模式，如下图

如果配置成功，说明连接已建立。继续下面的配置，添加事件，选择「接收消息」事件

事件添加完成之后，还需要开通权限，有以下权限全部勾选

如下图

以上步骤全部完成后，即可与机器人对话。但在此之前需要先创建一个版本

注意：每次修改配置后都需要重新发布版本，建议全部配置完成后再统一发布。

发布完成后，回到飞书客户端，可以看到应用已上线，点击打开应用

向机器人发送 Hello，即可收到 Moltbot 的回复

如有勘误 还请指正

Clawdbot (moltbot) 对接飞书详细教程 手把手搭建你的专属 AI 助手

大家好，我是凌览。

• 个人网站：blog.code24.top
• 去水印下载鸭：nologo.code24.top

如果本文能给你提供启发或帮助，欢迎动动小手指，一键三连（点赞、评论、转发），给我一些支持和鼓励谢谢。

刷到一个挺扎心的话题：程序员为什么不自己做产品赚钱。

身边还真有不少人问过类似的话："你天天写代码这么厉害，怎么不自己搞个App、做个小程序？随便弄弄不就发财了？"

每次听到这种问题，我都不知道该从哪儿开始解释。

最近在 X 乎上看到同行的回答，看完只能说：太真实了。

理想很丰满、现实很骨感

首先，假装我们是程序员，某天深夜加班回家，瘫在沙发上刷手机，突然一个念头炸开——"我去，这个功能市面上根本没有！我要是做一个，肯定爆火！”。

脑子里的画面瞬间清晰：产品上线、用户疯涨、投资人排队、财务自由...，满脑子都是"老子不干了，要创业"。

说干就干，流程走起来：

第一步：注册账号结果发现邮箱早就被自己多年前注册过，还冻结了。解冻、换邮箱，折腾一圈。

第二步：想名字绞尽脑汁想了个好名字，一搜，已被占用。再想想想，终于通过。

第三步：开发前端后端一把抓，不会前端？没事，Ai结伴编程一把梭。uniapp启动，一套代码多端运行，微信、QQ、抖音、快手平台全都要上。

第四步：买服务器，阿里云一核两G，一年600块，付款的时候手还没抖。

第五步：搞域名，随便挑一个，一年30块，便宜。

第六步：备案到这里，噩梦开始了。拍照、填表、等审核，来来回回折腾。好不容易过了，提交小程序审核——"该项目类型个人不支持，需要企业认证。"

卒。亏损-630元。

但程序员嘛，头铁。不信邪，继续：

第七步：注册公司个体户要经营场所，干脆直接注册公司。准备材料、开对公账户、刻公章，又是一顿操作。

第八步：重新认证企业认证要的材料堆成山，干脆重新注册个小程序。又是想名字（原来的还要等两天才能释放）、填资料、承诺书、盖章...

终于，小程序上线了。

上线只是开始，赚钱才是难题。

每天努力宣传、引流，结果广告收益长这样：昨日收入0.65元。

对，你没看错，六毛五。折线图上的曲线在0.3元到1.8元之间反复横跳，月收入6.72元。服务器钱还没赚回来，先赔进去几百块。

什么会这样？

• 个人开发者不能收费，只能通过挂广告，而广告收入低到离谱。激励广告单价居然只有4.29元/千次展示，Banner广告更惨，几块钱千次展示。算笔账：日访问量要达到2万，才能日入500。2万UV什么概念？很多小公司的官网一天都没这么多人。
• 推广难，小程序是个封闭生态，你不能诱导分享，否则直接封号。只能从其他平台往微信导流，但用户路径一长，流失率奇高。要开通流量主还得先引流500人，这第一道门槛就卡死不少人。
• 审核机制让人头大，页面上文字一多，就说你涉及"内容资讯"，不给过。个人开发者经营类目受限，动不动就踩红线。

不是技术问题，是商业问题

程序员不做小程序赚钱，不是因为不会写代码，而是因为写代码只是万里长征第一步。

做一个能赚钱的小程序，需要：

• 产品能力：做什么？解决谁的什么问题？凭什么用你的？
• 运营能力：流量从哪来？怎么留存？怎么变现？
• 商业资质：公司、对公账户、各种许可证，合规成本不低；
• 时间和精力：白天上班，晚上搞副业，服务器半夜挂了还得爬起来修。

而大多数程序员，只是喜欢写代码而已。让他们去搞流量、谈商务、处理工商税务，比写一万行代码还痛苦。

更扎心的是，就算你愿意干这些，小程序的红利期也早过了。2017年刚出来那会儿，确实有人靠简单工具类小程序赚到第一桶金。现在？各大平台库存量几百万个，用户注意力被某音、被红书切得稀碎，新入局者基本就是炮灰。

成功案例

网上经常能看到"做小程序月入过万"的帖子，但仔细看会发现，要么是卖课的，要么是有特殊资源的（比如手里有公众号矩阵导流），要么是早期入局者吃到了红利。
对于普通程序员来说，接个外包项目，按时薪算可能比折腾三个月小程序赚得还多，还省心。

技术只是工具，商业才是战场。会拿锤子的不一定会盖房子，会写代码的不一定能做出赚钱的产品。这不是技术问题，这是两个完全不同的赛道。

最后

所以，开发一个小程序到底能不能赚钱？

能，但跟你关系不大。

要么你有现成的流量池，比如几十万粉丝的公众号、抖音号，小程序只是变现工具；要么你有特殊资源，比如独家数据、行业资质；再要么你踩中了某个极小概率的风口，比如当年疫情期间的健康码周边工具。否则，个人开发者大概率是炮灰。

写代码是确定性的事，输入逻辑输出结果；做生意是概率性的事，投入不一定有回报。 大多数人适合前者，却误以为自己能驾驭后者。

你呢？有没有过"做个产品改变世界"的冲动？最后成了吗？