豆包过年活动,有红包领,羊毛薅起来

薅了几天元宝的,豆包也有羊毛了。
右下角点豆包过年,不想上传图片的话就选《新春关键词》就行。
xiaohack博客专注前沿科技动态与实用技术干货分享,涵盖 AI 代理、大模型应用、编程工具、文档解析、SEO 实战、自动化部署等内容,提供开源项目教程、科技资讯日报、工具使用指南,助力开发者、AI 爱好者获取前沿技术与实战经验。

薅了几天元宝的,豆包也有羊毛了。
右下角点豆包过年,不想上传图片的话就选《新春关键词》就行。
过去,我们使用 AI 写代码的流程是这样的: 但现在,一切变了。 由 Anthropic 推出的 Claude Code,已经进入了一个全新的阶段: 它不是聊天工具,而是真正的: 终端级 AI Agent 开发工具 Claude Code 可以直接: 本质上,它就是: 进入你的项目目录: 启动 Claude Code: 进入界面: 此时 Claude 已经可以: 强制退出: 方法 1: 方法 2: Claude 会恢复之前的上下文。 非常适合长期项目开发。 Claude Code 有三种核心工作模式: 可以通过快捷键: 在三种模式之间循环切换: Default → Auto → Plan → Default → … 特点: 适合: 这是默认模式。 通过: 或使用命令: 切换到: Claude 会自动: 无需人工确认。 适合: 这是效率最高的模式。 通过: 或使用: 切换到: Claude 会: 例如: Claude 会输出: 适合: 强烈推荐开发前使用。 开启: Claude 会自动: 例如: Claude 会自动完成整个开发流程。 (风险是 Claude 会全面接管你的电脑) 查看上下文: 压缩上下文(强烈推荐): 作用: 长期开发必用。 清空上下文: 用于: 查看任务: 显示: 终止任务: 执行: Claude 会生成: 这个文件用于定义: Claude 会严格遵守。 查看 Agent: 查看 Hooks: 查看 MCP: 查看插件: 查看记忆: 标准开发流程: Claude 会自动完成整个项目开发。 推荐组合: 这是 Claude Code 最强组合。 Claude Code 改变了开发方式: 从: 变成: Claude Code 不再只是 AI。 而是: 未来的软件开发,将不再是: 而是: 谁更早掌握 AI Agent,谁就拥有更高的开发效率。 Claude Code,就是这个时代的入口。 本文由mdnice多平台发布Claude Code 从入门到精通:开发者必备终端命令完全指南(附实战)
提问 → 复制代码 → 粘贴 → 运行 → 报错 → 再问 AI
AI 可以直接操作你的电脑,完成完整开发流程。
一个可以直接干活的 AI 程序员
一、Claude Code 启动与恢复会话
启动 Claude Code
cd your-projectclaudeClaude Code >退出 Claude Code
Ctrl + C
Ctrl + C恢复之前的会话
claude -c/resume二、Claude Code 三大核心模式(Shift + Tab 切换)
Shift + TabDefault 模式(默认安全模式)
Auto 模式(自动执行模式)
Shift + Tab/autoMode: AutoPlan 模式(规划模式)
Shift + Tab/planMode: Plan创建一个博客系统Step 1 创建项目结构
Step 2 创建数据库
Step 3 创建API
Step 4 创建前端三、自动开发模式(真正的 AI 编程)
/auto/auto 创建一个Flask项目四、上下文管理(必须掌握)
/context/compact/clear五、后台任务管理
/tasksRunning tasks:
npm install
python app.py K六、初始化项目(强烈推荐)
/initCLAUDE.md七、高级功能命令
/agents/hooks/mcp/plugin/memory八、完整命令速查表(建议收藏)
claude
claude -c
/plan
/auto
/context
/compact
/clear
/tasks
/init
/agents
/hooks
/mcp
/plugin
/resume九、完整开发流程实战(推荐)
cd project
claude
/init
Shift + Tab → 切换到 Plan 模式
设计项目
Shift + Tab → 切换到 Auto 模式
执行开发十、开发效率提升 10 倍的核心技巧
/init
/plan
/auto
/compact十一、本质总结
人写代码
人描述需求,AI 完成开发
真正的 AI 程序员
结尾
写代码的能力竞争
设计系统的能力竞争
我用 codex 5.3 模型让他做个小程序的页面,总是感觉特别的死板,功能是能用,就是很丑,没有设计感。沟通了两个小时,各种截图给他看别的案例,都改变不了它死板的结局,也使用了 ui ux pro max 这个 skill ,还是不行。
然后我切换到 antigravity 使用 gemin3 pro ,只用了一句话,“我觉得现在的小程序页面设计的太丑了,帮我重新设计一下”,出来的结果瞬间提高档次。
之前用 claude code 做前端设计都没有这么费劲过,只是额度用完了,临时用 codex 顶一顶,结果这么不好用。
我感觉 codex 像是无情的写代码机器一样,有很多条条框框限制着它,不会让他有很多开放性的想法,让他对于“设计”这种方向就没啥能力?
今天还要上班,19:00 下班后放假。
惨……
然后很巧的在隔壁 v 站也是 1 铜币。。。

Waku,一个最小的 React 框架,已经发布了 1.0 alpha 版本,这标志着它的公共 API 领域已经非常稳定,项目将重点转移到缺陷修复和兼容性改进上。 Waku 1.0 alpha 对于这个轻量级框架来说是一个重要的里程碑,它已经开发了将近三年。这个版本的发布稳定了框架的公共 API,并标志着从功能开发转向完善和稳定性。团队承诺在每个版本中提供发布说明,并在需要时提供迁移指南,因为他们朝着 1.0 beta 和发布候选阶段努力。 这个版本强调的一个关键优势是 Waku 在大多数具有动态路由的静态站点中找到了自己的最佳点,包括营销站点、博客、文档站点和轻量级电子商务应用。该框架简单的每个路由配置使得它可以直接在完全静态或完全动态渲染之间进行选择,甚至可以将这两种方法混合在一起,布局、切片和页面都有自己的渲染配置。 与早期版本相比,1.0 alpha 版本的发布引入了一个破坏性变更,这影响了实现基于配置的路由或部署适配器的用户。入口文件已经从 Waku 将自己定位为像Next.js这样的更重框架的替代品,特别是对于那些想要直接使用React Server Components而不需要企业级特性复杂性的小型项目开发者。该框架建立在Vite和Hono之上,优先考虑了开发者体验,同时支持所有最新的 React 19 特性,包括服务器组件和服务器操作。LogRocket上的一篇比较文章指出,虽然 Next.js 为复杂应用提供了广泛的功能,但 Waku 的极简主义方法使其成为不需要全面框架化重量级项目的理想选择。 这个发布在 React 社区引起了兴趣。在Reddit上,一些用户注意到了公告的简洁性,Waku 的创造者Daishi Kato在一位用户询问框架的目的是什么后,反馈到: 没有解释它是什么,或者为什么我们应该好奇? Waku 创造者回应: 好主意。它甚至没有提到它是一个 React 框架... 希望https://waku.gg/#introduction有所帮助,但我不确定是否足以让人们好奇。如果我要加一些话让它变得有趣,那就是: * 它是一个从一开始就为 React Server Components 开发的 React 框架。 * 它是基于 Vite 和 Hono 的。 * 它的 API 很小,易于学习。 * 开发服务器和构建过程非常快,这主要归功于 Vite。 这个公告也被Bytes newsletter和Netlify 2025网络框架回顾所报道,后者指出 Waku 向 alpha 的转变是 React Server Components 在整个生态系统中成熟的一部分。 开发者应该注意到一些架构考虑。Waku 在这个阶段明确设计为非生产项目,团队通过他们的GitHub讨论积极寻求反馈。框架目前缺乏一些开发者可能期望从成熟框架中获得的功能,例如内置缓存层,尽管它支持部署到多个平台,包括 Cloudflare 和 AWS Lambda。 Waku 是一个主要由 Daishi Kato 开发的开源项目,他以创建流行的 React 状态管理库Zustand、Jotai和Valtio而闻名。框架的名字,在日语中意味着“激发”,反映了它的目标是在保持轻量级和专注于 React Server Components 基础的同时,提供一种令人兴奋和愉快的开发者体验。 原文链接:server-entry.ts和client-entry.ts重命名为waku.server.ts和waku.client.ts。从早期版本升级的开发者需要相应地重命名这些文件。这个版本没有迁移指南,但是有一个早期社区创建的迁移指南提供了从版本 0.25 升级到 0.27 的详细升级说明。
现在 AI 都这样了,那接下来一两年,什么东西会是一个爆点呢。当然现实世界中肯定就是物理 AI 的天下。但是互联网我在想哪个点会爆?我在想是不是 AI 小说和短视频这块,朋友们觉得呢
我发现现在出了什么 skill agent ,但是我去做游戏套壳站,还是老办法,感觉自己要打磨一下流程了,复用的工具确实要多花点时间打磨好
快过年了,祝大家都快乐开心,下面这个游戏就是打打广告了
碰到一个西语的《 Looking For You 》,氛围还挺有意思的。顺手做成了网页版,想试试的话不用下载,直接打开能玩:
https://lookingforyougame.com
西语看不懂也没那么难受,网页版配合截图翻译/浏览器翻译会轻松很多。这次 vibecoding 是用的上次老哥推荐的 CarryCode ,还可以,也可能是这次这个游戏编译比较简单
很多同事休假了,没什么需要推进的事情。
公司系统也封禁期了,不需要上线迭代。
只要不出线上问题,能一连摸鱼好几天。
希望成本低、预期可以较长时间存活的,谢谢。
大家好,我是良许。 在嵌入式开发中,我们经常需要让主控芯片与各种外设进行通信,比如读取温湿度传感器的数据、控制 OLED 显示屏显示内容、读写 EEPROM 存储器等等。 这时候就需要用到各种通信协议,而 I2C 总线就是其中最常用的一种。 我刚入行做单片机开发的时候,第一个接触的通信协议就是 I2C,当时用 STM32 读取一个温度传感器,虽然代码不多,但理解其工作原理还是花了不少时间。 今天就和大家详细聊聊 I2C 总线的方方面面。 I2C 总线是由飞利浦公司(现在的 NXP)在 1980 年代开发的一种串行通信总线。 它最大的特点就是只需要两根信号线就能实现多个设备之间的通信,这两根线分别是 SDA(Serial Data Line,串行数据线)和 SCL(Serial Clock Line,串行时钟线)。 相比于并行总线需要 8 根、16 根甚至更多的数据线,I2C 总线大大节省了芯片的引脚资源和 PCB 板的布线空间。 I2C 总线采用主从模式(Master-Slave),通信过程中必须有一个主设备来控制总线,从设备只能被动响应。 主设备负责产生时钟信号和发起通信,从设备则根据自己的地址来判断是否需要响应。 一条 I2C 总线上可以挂载多个主设备和多个从设备,理论上最多可以连接 128 个设备(7 位地址模式)或 1024 个设备(10 位地址模式)。 I2C 总线的硬件连接非常简单。 SDA 和 SCL 都是开漏输出(Open-Drain)或开集输出(Open-Collector),需要外接上拉电阻到电源。 典型的上拉电阻阻值在 1kΩ 到 10kΩ 之间,具体取值要根据总线电容负载和通信速率来确定。 总线电容越大、速率越高,上拉电阻就要选得越小。 开漏输出的特点是只能主动拉低电平,不能主动拉高电平,释放总线后依靠上拉电阻将电平拉高。 这种设计有两个好处:一是允许多个设备连接到同一条总线上而不会发生电气冲突,二是可以实现不同电压等级设备之间的通信(通过选择合适的上拉电压)。 在实际项目中,我曾经遇到过一个问题:I2C 通信时好时坏,波形也不太正常。 后来发现是上拉电阻选得太大了(用的是 10kΩ),总线电容负载比较大,导致信号上升沿太慢。 换成 2.2kΩ 的电阻后问题就解决了。 所以硬件设计时一定要注意这个细节。 I2C 总线定义了几种不同的速率模式: 标准模式(Standard Mode):时钟频率最高 100kHz,这是最早的 I2C 标准,现在很多低速外设仍然使用这个速率。 快速模式(Fast Mode):时钟频率最高 400kHz,是目前最常用的速率模式,能够满足大部分应用场景的需求。 快速模式增强版(Fast Mode Plus):时钟频率最高 1MHz,用于对速度要求较高的场合。 高速模式(High Speed Mode):时钟频率最高 3.4MHz,需要特殊的硬件支持,实际应用中比较少见。 超快速模式(Ultra Fast Mode):时钟频率最高 5MHz,这是最新的标准,目前支持的设备还不多。 在实际开发中,我们最常用的是标准模式和快速模式。 选择哪种速率主要看外设芯片的支持情况和实际需求。 如果只是读取一个温度传感器,标准模式完全够用;如果要驱动一个 OLED 显示屏,可能就需要用到快速模式来提高刷新速度。 I2C 通信的开始和结束都有特定的信号标志。 起始条件(Start Condition)是指在 SCL 为高电平期间,SDA 由高电平变为低电平。 停止条件(Stop Condition)是指在 SCL 为高电平期间,SDA 由低电平变为高电平。 这两个条件非常重要,它们定义了一次完整通信的边界。 主设备在发起通信前必须先发送起始条件,通信结束后必须发送停止条件。 从设备通过检测起始条件来知道通信开始了,通过检测停止条件来知道通信结束了。 还有一种特殊情况叫做重复起始条件(Repeated Start),就是在一次通信过程中,不发送停止条件,直接再发送一个起始条件。 这样可以在不释放总线的情况下改变通信方向或切换从设备,常用于连续读写操作。 I2C 总线上的数据传输以字节为单位,每个字节都是 8 位。 数据在 SCL 为低电平期间准备好,在 SCL 为高电平期间被采样。 数据传输遵循高位在前(MSB First)的原则,也就是先传输最高位。 每传输完一个字节,接收方都要发送一个应答位(ACK)或非应答位(NACK)。 应答位是在第 9 个时钟周期内,接收方将 SDA 拉低表示应答,如果 SDA 保持高电平则表示非应答。 主设备作为接收方时,通常在接收到最后一个字节后发送非应答位,告诉从设备数据传输结束了。 I2C 总线上的每个从设备都有一个唯一的地址,主设备通过这个地址来选择要通信的从设备。 标准的 I2C 地址是 7 位,加上 1 位读写位,总共占用一个字节。 读写位为 0 表示写操作,为 1 表示读操作。 比如一个 EEPROM 芯片的地址是 0x50(二进制 1010000),当主设备要写数据时,发送的地址字节就是 0xA0(1010000 + 0);当主设备要读数据时,发送的地址字节就是 0xA1(1010000 + 1)。 有些 I2C 设备支持 10 位地址模式,这样可以在同一条总线上连接更多设备。 10 位地址的传输需要两个字节,第一个字节的高 5 位是 11110,后面跟着 10 位地址的最高 2 位和读写位;第二个字节是 10 位地址的低 8 位。 不过实际项目中,10 位地址模式用得比较少。 在设计系统时,必须确保总线上的每个从设备地址都不相同。 但有时候会遇到地址冲突的情况,比如需要在同一条总线上连接两个相同型号的传感器,而这两个传感器的地址是固定的。 解决办法有几种:一是选择支持地址配置的芯片,很多 I2C 设备都有几个地址选择引脚,通过接高电平或低电平可以改变设备地址。 二是使用 I2C 总线扩展器或多路复用器,将一条总线扩展成多条独立的总线。 三是如果可能的话,使用软件模拟 I2C,用不同的 GPIO 引脚来连接不同的设备。 一次完整的 I2C 写操作时序如下: 一次完整的 I2C 读操作时序如下: 这个时序看起来比较复杂,但实际使用时,STM32 的 HAL 库已经把这些细节都封装好了,我们只需要调用几个简单的函数就可以完成通信。 STM32 芯片内部集成了硬件 I2C 控制器,可以自动处理时序、应答等细节,大大简化了编程工作。 使用 STM32CubeMX 配置 I2C 非常方便,只需要几个步骤: 生成的代码中会有一个初始化函数,类似这样: HAL 库提供了多个 I2C 通信函数,最常用的有以下几个: MPU6050 是一个常用的六轴姿态传感器,内部集成了三轴陀螺仪和三轴加速度计,通过 I2C 接口与主控芯片通信。 它的 I2C 地址是 0x68 或 0x69(取决于 AD0 引脚的电平)。 下面是一个读取 MPU6050 数据的完整例程: 这个例程展示了 I2C 通信的典型流程:先初始化设备,然后循环读取数据。 需要注意的是,HAL 库的 I2C 地址参数需要左移 1 位,因为库函数会自动添加读写位。 有时候硬件 I2C 引脚被占用了,或者需要在任意 GPIO 上实现 I2C 通信,这时候可以用软件模拟 I2C。 虽然软件模拟的效率不如硬件 I2C,但胜在灵活性高,而且对于低速设备来说完全够用。 软件模拟 I2C 的核心是用 GPIO 来产生 I2C 时序。下面是一个简单的实现: 软件模拟 I2C 的代码比较长,这里只列出了部分关键函数。 完整的实现还需要接收字节、发送应答等函数。 虽然代码量比较大,但原理很清晰,就是严格按照 I2C 时序来操作 GPIO 引脚。 在实际项目中,I2C 通信失败是很常见的问题。 遇到这种情况,可以按照以下步骤排查: 第一步,检查硬件连接。 用万用表测量 SDA 和 SCL 是否正常,静态时应该是高电平(上拉电阻的作用)。 如果是低电平,可能是某个设备把总线拉低了,或者上拉电阻没接好。 第二步,检查设备地址。 很多初学者会忘记地址要左移 1 位,或者把读写位搞混了。 可以用逻辑分析仪抓取波形,看看实际发送的地址是否正确。 第三步,检查时序。 有些 I2C 设备对时序要求比较严格,如果时钟速率太高或者延时不够,可能导致通信失败。 可以尝试降低时钟速率,或者在关键位置增加延时。 第四步,检查设备状态。 有些设备需要先初始化才能正常工作,比如 MPU6050 默认是睡眠模式,必须先写电源管理寄存器唤醒它。 仔细阅读设备的数据手册,按照要求进行初始化。 当多个主设备同时发起通信时,可能会发生总线冲突。 I2C 协议定义了仲裁机制来解决这个问题:每个主设备在发送数据的同时监测总线状态,如果发现总线电平与自己发送的不一致,就说明有其他设备也在发送数据,这时候要立即停止发送,让出总线。 仲裁过程是按位进行的。 由于 I2C 是开漏输出,低电平会覆盖高电平,所以发送低电平的设备会赢得仲裁。 比如设备 A 发送地址 0x50(01010000),设备 B 发送地址 0x48(01001000),在第 5 位时,A 发送 1 但检测到 0,就知道自己输掉了仲裁,会停止发送。 不过在实际应用中,多主设备的情况比较少见。 如果确实需要多个主设备,要做好软件设计,避免同时发起通信,或者使用仲裁机制来处理冲突。 I2C 协议允许从设备在需要更多时间处理数据时,通过拉低 SCL 来延长时钟周期,这叫做时钟延展(Clock Stretching)。 主设备在拉高 SCL 后,必须检测 SCL 是否真的变成高电平,如果 SCL 被从设备拉低了,就要等待从设备释放 SCL。 有些 STM32 的硬件 I2C 控制器支持时钟延展,有些不支持。 如果不支持,遇到需要时钟延展的从设备就可能出现问题。 这时候可以尝试用软件模拟 I2C,或者在软件中实现时钟延展检测。 I2C 总线的信号频率不高,但在强电磁干扰环境下仍然可能出现通信错误。 我之前做过一个项目,设备在实验室测试时一切正常,但到了工业现场就频繁出现通信失败。 后来发现是附近有大功率电机,产生了很强的电磁干扰。 解决电磁干扰问题的方法有:缩短 I2C 总线长度,理想情况下不要超过 1 米。 在 SDA 和 SCL 上串联小电阻(比如 100Ω),可以抑制高频干扰。 使用屏蔽线或双绞线。 在软件中增加重试机制,检测到通信错误时自动重试。 I2C 总线是嵌入式系统中最常用的通信协议之一,它结构简单、使用方便、节省引脚,非常适合连接各种低速外设。 掌握 I2C 的工作原理和编程方法,是每个嵌入式工程师的必备技能。 在实际开发中,我们既要理解 I2C 的底层时序,也要会使用 HAL 库等高层接口。 遇到问题时,要善于用逻辑分析仪等工具来分析波形,结合数据手册来排查原因。 只要多实践、多总结,很快就能熟练掌握 I2C 通信。 希望这篇文章能帮助大家更好地理解和使用 I2C 总线。 如果你在项目中遇到了 I2C 相关的问题,欢迎留言交流讨论。 更多编程学习资源1. I2C 总线基础知识
1.1 什么是 I2C 总线
1.2 I2C 总线的硬件连接
1.3 I2C 总线的速率模式
2. I2C 通信协议详解
2.1 起始和停止条件
2.1.1 数据传输格式
2.2 设备地址
2.2.1 地址冲突问题
2.3 完整的通信时序
3. STM32 的 I2C 编程实战
3.1 硬件 I2C 的配置
void MX_I2C1_Init(void)
{
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;
hi2c1.Init.OwnAddress2 = 0;
hi2c1.Init.GeneralCallMode = I2C_GENERALCALL_DISABLE;
hi2c1.Init.NoStretchMode = I2C_NOSTRETCH_DISABLE;
if (HAL_I2C_Init(&hi2c1) != HAL_OK)
{
Error_Handler();
}
}3.2 I2C 读写函数
// 主设备发送数据
HAL_StatusTypeDef HAL_I2C_Master_Transmit(I2C_HandleTypeDef *hi2c,
uint16_t DevAddress,
uint8_t *pData,
uint16_t Size,
uint32_t Timeout);
// 主设备接收数据
HAL_StatusTypeDef HAL_I2C_Master_Receive(I2C_HandleTypeDef *hi2c,
uint16_t DevAddress,
uint8_t *pData,
uint16_t Size,
uint32_t Timeout);
// 向指定寄存器写数据
HAL_StatusTypeDef HAL_I2C_Mem_Write(I2C_HandleTypeDef *hi2c,
uint16_t DevAddress,
uint16_t MemAddress,
uint16_t MemAddSize,
uint8_t *pData,
uint16_t Size,
uint32_t Timeout);
// 从指定寄存器读数据
HAL_StatusTypeDef HAL_I2C_Mem_Read(I2C_HandleTypeDef *hi2c,
uint16_t DevAddress,
uint16_t MemAddress,
uint16_t MemAddSize,
uint8_t *pData,
uint16_t Size,
uint32_t Timeout);3.2.1 实战案例:读取 MPU6050 传感器
#define MPU6050_ADDR 0xD0 // MPU6050地址左移1位(0x68 << 1)
#define WHO_AM_I_REG 0x75 // WHO_AM_I寄存器地址
#define PWR_MGMT_1_REG 0x6B // 电源管理寄存器
#define ACCEL_XOUT_H 0x3B // 加速度X轴高字节寄存器
// 初始化MPU6050
uint8_t MPU6050_Init(void)
{
uint8_t check;
uint8_t data;
// 读取WHO_AM_I寄存器,检查设备是否存在
HAL_I2C_Mem_Read(&hi2c1, MPU6050_ADDR, WHO_AM_I_REG, 1, &check, 1, 1000);
if(check == 0x68) // MPU6050的WHO_AM_I值是0x68
{
// 唤醒MPU6050(默认是睡眠模式)
data = 0;
HAL_I2C_Mem_Write(&hi2c1, MPU6050_ADDR, PWR_MGMT_1_REG, 1, &data, 1, 1000);
// 设置加速度计量程为±2g
data = 0x00;
HAL_I2C_Mem_Write(&hi2c1, MPU6050_ADDR, 0x1C, 1, &data, 1, 1000);
// 设置陀螺仪量程为±250°/s
data = 0x00;
HAL_I2C_Mem_Write(&hi2c1, MPU6050_ADDR, 0x1B, 1, &data, 1, 1000);
return 0;
}
return 1;
}
// 读取加速度数据
void MPU6050_Read_Accel(int16_t *AccelX, int16_t *AccelY, int16_t *AccelZ)
{
uint8_t data[6];
// 从ACCEL_XOUT_H开始连续读取6个字节
HAL_I2C_Mem_Read(&hi2c1, MPU6050_ADDR, ACCEL_XOUT_H, 1, data, 6, 1000);
// 组合高低字节
*AccelX = (int16_t)(data[0] << 8 | data[1]);
*AccelY = (int16_t)(data[2] << 8 | data[3]);
*AccelZ = (int16_t)(data[4] << 8 | data[5]);
}
// 主函数中的使用示例
int main(void)
{
HAL_Init();
SystemClock_Config();
MX_GPIO_Init();
MX_I2C1_Init();
int16_t accel_x, accel_y, accel_z;
if(MPU6050_Init() == 0)
{
while(1)
{
MPU6050_Read_Accel(&accel_x, &accel_y, &accel_z);
// 这里可以对数据进行处理或显示
// printf("X: %d, Y: %d, Z: %d\r\n", accel_x, accel_y, accel_z);
HAL_Delay(100); // 延时100ms
}
}
else
{
// MPU6050初始化失败
while(1)
{
// 错误处理
}
}
}3.3 软件模拟 I2C
// 定义SDA和SCL引脚
#define I2C_SCL_PIN GPIO_PIN_6
#define I2C_SCL_PORT GPIOB
#define I2C_SDA_PIN GPIO_PIN_7
#define I2C_SDA_PORT GPIOB
// 延时函数(用于控制时钟速率)
void I2C_Delay(void)
{
uint8_t i = 10; // 调整这个值可以改变速率
while(i--);
}
// 设置SDA为输出模式
void SDA_OUT(void)
{
GPIO_InitTypeDef GPIO_InitStruct = {0};
GPIO_InitStruct.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_SDA_PORT, &GPIO_InitStruct);
}
// 设置SDA为输入模式
void SDA_IN(void)
{
GPIO_InitTypeDef GPIO_InitStruct = {0};
GPIO_InitStruct.Pin = I2C_SDA_PIN;
GPIO_InitStruct.Mode = GPIO_MODE_INPUT;
GPIO_InitStruct.Pull = GPIO_PULLUP;
HAL_GPIO_Init(I2C_SDA_PORT, &GPIO_InitStruct);
}
// 产生起始条件
void I2C_Start(void)
{
SDA_OUT();
HAL_GPIO_WritePin(I2C_SDA_PORT, I2C_SDA_PIN, GPIO_PIN_SET);
HAL_GPIO_WritePin(I2C_SCL_PORT, I2C_SCL_PIN, GPIO_PIN_SET);
I2C_Delay();
HAL_GPIO_WritePin(I2C_SDA_PORT, I2C_SDA_PIN, GPIO_PIN_RESET);
I2C_Delay();
HAL_GPIO_WritePin(I2C_SCL_PORT, I2C_SCL_PIN, GPIO_PIN_RESET);
}
// 产生停止条件
void I2C_Stop(void)
{
SDA_OUT();
HAL_GPIO_WritePin(I2C_SCL_PORT, I2C_SCL_PIN, GPIO_PIN_RESET);
HAL_GPIO_WritePin(I2C_SDA_PORT, I2C_SDA_PIN, GPIO_PIN_RESET);
I2C_Delay();
HAL_GPIO_WritePin(I2C_SCL_PORT, I2C_SCL_PIN, GPIO_PIN_SET);
I2C_Delay();
HAL_GPIO_WritePin(I2C_SDA_PORT, I2C_SDA_PIN, GPIO_PIN_SET);
I2C_Delay();
}
// 发送一个字节
void I2C_Send_Byte(uint8_t byte)
{
uint8_t i;
SDA_OUT();
HAL_GPIO_WritePin(I2C_SCL_PORT, I2C_SCL_PIN, GPIO_PIN_RESET);
for(i = 0; i < 8; i++)
{
if(byte & 0x80)
HAL_GPIO_WritePin(I2C_SDA_PORT, I2C_SDA_PIN, GPIO_PIN_SET);
else
HAL_GPIO_WritePin(I2C_SDA_PORT, I2C_SDA_PIN, GPIO_PIN_RESET);
byte <<= 1;
I2C_Delay();
HAL_GPIO_WritePin(I2C_SCL_PORT, I2C_SCL_PIN, GPIO_PIN_SET);
I2C_Delay();
HAL_GPIO_WritePin(I2C_SCL_PORT, I2C_SCL_PIN, GPIO_PIN_RESET);
}
}
// 等待应答
uint8_t I2C_Wait_Ack(void)
{
uint8_t ack;
SDA_IN();
HAL_GPIO_WritePin(I2C_SCL_PORT, I2C_SCL_PIN, GPIO_PIN_SET);
I2C_Delay();
if(HAL_GPIO_ReadPin(I2C_SDA_PORT, I2C_SDA_PIN))
ack = 1; // 无应答
else
ack = 0; // 有应答
HAL_GPIO_WritePin(I2C_SCL_PORT, I2C_SCL_PIN, GPIO_PIN_RESET);
return ack;
}4. I2C 使用中的常见问题
4.1 通信失败的排查
4.2 总线冲突和仲裁
4.3 时钟延展
4.4 电磁干扰
5. 总结
点赞 + 关注 + 收藏 = 学会了 有没有发现 n8n 的聊天窗只有一个输入框,好像没有上传文件的功能。 那是因为没开启“Allow File Uploads”。双击「When chat message received」节点,在“Parameters”里找到“Options”,点击“Add Field”开启“Allow File Uploads”。 回到工作流面板,打开聊天窗口就能看到这里有一个上传文件的按钮。 但需要你用多模态大模型,才能识别图片内容。我用 Kimi-k2.5 演示一下。 上传一张小恐龙图片。 问它“这张图里的动物是什么?”。 Kimi-k2.5 很快就识别出来了。 以上就是本文的全部内容啦,想了解更多n8n玩法欢迎关注《n8n修炼手册》👏 如果你有 NAS,我非常建议你在 NAS 上部署一套 n8n,搞搞副业也好,帮你完成工作任务也好 《『NAS』不止娱乐,NAS也是生产力,在绿联部署AI工作流工具-n8n》 点赞 + 关注 + 收藏 = 学会了整理了一个n8n小专栏,有兴趣的工友可以关注一下 👉 《n8n修炼手册》





在企业数字化转型浪潮中,CRM系统已从单一客户管理工具升级为覆盖全业务链路的数字化中枢。本文选取超兔一体云、Creatio、Keap、简道云、销帮帮CRM、快启六款市场主流产品,从客户管理、销售管理、AI智能、自定义能力、 API 对接五大核心维度展开专业横向对比,为不同规模、不同需求的企业提供选型参考。 先通过全局表格快速建立认知: 实现客户数据统一归集、精准画像、生命周期管控与权限安全,最终提升客户留存与复购率。 适配不同业务场景的跟单模型,通过自动化与可视化提升销售转化率与团队管控能力。 将AI能力嵌入业务全流程,降低人工成本、提升决策精准度与流程效率。 根据企业个性化业务需求快速调整系统,适配不同行业与发展阶段的变化。 打通企业现有系统数据孤岛,实现全业务流程协同与数据共享。 企业在选择CRM或数字化平台时,需紧密结合自身规模、业务特性、数字化转型阶段及核心需求优先级决策:中大型企业更需关注全业务协同、复杂流程定制与跨系统集成能力;中小微企业则侧重轻量化部署、低成本获客与快速上手的工具属性。上述六款产品各有核心优势,通过精准匹配自身需求,可有效借助数字化工具提升客户运营效率、销售转化能力与企业整体竞争力。一、核心定位与适配客户总览
品牌 核心定位 适配客户群体 核心优势关键词 超兔一体云 全业务一体化数字化平台 成长型→中大型企业(全业务协同) 多跟单模型、AI工作流、RPA集成 Creatio 无代码定制化CRM平台 中大型企业(复杂流程需求) 全流程无代码定制、多AI模型选择 Keap 轻量化CRM+营销自动化平台 中小微企业(基础获客需求) 低成本、轻量化营销自动化 简道云 零代码低代码应用搭建平台(含CRM) 全规模企业(平台化需求) 拖拽式搭建、跨办公平台集成 销帮帮CRM 垂直行业深耕型CRM 成长型企业(垂直赛道) AI客户评分、云叩低代码支撑 快启 SCRM+AI智能获客平台 中小企业(获客驱动型) 微信生态整合、AI获客机器人 二、客户管理维度:全生命周期价值挖掘能力对比
核心价值
横向对比表格
品牌 多渠道数据整合 客户画像构建 生命周期管理 权限管控 特色功能 超兔一体云 多渠道+自动查重(含企业简称模糊匹配) 工商/天眼查/社交数据自动补全 客池自动分类+工作流驱动 岗位细分权限(财务仅看数据) AI生成跟进工作流、经纬度标记 Creatio 360°视图统一归集 自定义字段+流失客户智能分析 关键节点自动提示 精细化授权访问/修改 AI智能体嵌入Outlook/Teams Keap 获客蓝图+表单采集 行为数据分层精准触达 基础跟进提醒 轻量化角色权限 条件触发式内容推送 简道云 表单+第三方集成 标签化管理+场景化自动化维护 规则触发客户维护 角色数据权限 生日关怀自动化流程 销帮帮CRM 公海池分配+自动归集 AI评分+360°立体画像 阶段化跟进管控 垂直行业数据权限 自定义标签适配赛道需求 快启 微信生态+多方式录入 标签管理+行为轨迹记录 智能公海流转+签约客户分库 异常操作实时提醒 个性化自动丢公海规则 品牌亮点可视化(超兔客户管理核心逻辑)
mindmap
root((超兔客户管理核心逻辑))
多渠道数据整合
广告/官网/微信/工商搜客
自动查重(客户名/手机号/企业简称)
客户画像构建
工商/天眼查数据补全
社交头像/经纬度自动标记
自定义字段与列表布局
生命周期管控
客池自动分类(需求培养/成交等)
AI生成工作流驱动跟进
权限安全
岗位细分权限(财务/销售隔离)三、销售管理维度:跟单效率与流程可控性对比
核心价值
雷达图分值对比(满分10)
横向对比表格
品牌 核心跟单模型 销售自动化能力 数据可视化 特色功能 超兔一体云 三一客小单/商机跟单/多方项目 工作流驱动+待办提醒+自动日报 行动记录分析+业绩拆解 三一客“三定”推进、多方项目收支管控 Creatio 无代码自定义全流程 预定义模板+自定义自动化规则 定制化销售漏斗 全流程节点精准配置 Keap 轻量化跟进模型 跟进提醒+邮件自动化推送 基础漏斗可视化 营销获客流程自动化 简道云 自定义流程搭建 规则触发任务+数据联动 实时业绩仪表盘 多维度销售数据监控 销帮帮CRM 全流程阶段化跟进 拜访记录自动同步+智能提醒 AI辅助业绩报表 高价值客户精准识别 快启 线索→签约→售后全流程 自动跟进任务+外勤签到 多维度工作报表 销售人员外勤行为管理 品牌亮点可视化(超兔“三一客”小单快单流程)
sequenceDiagram
销售->>超兔系统: 录入小单线索
超兔系统->>销售: 生成三定任务(定人=销售A, 定时=24h内, 定动作=首次触达)
销售->>超兔系统: 完成触达并记录客户需求
超兔系统->>销售: 触发下一节点(发送报价, 限时12h)
销售->>超兔系统: 客户确认报价, 生成订单
超兔系统->>销售: 自动标记至“成交”客池, 同步财务数据四、AI智能维度:业务场景的深度赋能对比
核心价值
横向对比表格
品牌 AI核心能力类型 大模型支持情况 核心应用场景 超兔一体云 自然语言生成工作流+多场景AI助手 内置AI+Coze工作流调用 AI待办/AI日报/AI话术/沟通内容意向分析 Creatio 跨流程推理智能体 OpenAI/Anthropic/Gemini自主选择 客户互动辅助/流程自动化推理 Keap 基础营销自动化 无明确大模型支持 条件触发内容推送/跟进提醒 简道云 智能助手+数据预警 内置AI模型 生日关怀触发/数据异常预警 销帮帮CRM AI客户评分+智能工作流 内置AI模型 高价值客户识别/售后报销自动化 快启 AI获客机器人+大数据分析 内置AI+大数据模型 精准线索挖掘/客户意向分析 品牌亮点可视化(超兔AI工作流生成逻辑)
flowchart LR
A[销售输入自然语言需求: 新线索24h内触达, 未完成提醒主管]
B[AI解析生成工作流草稿]
C[用户确认/调整节点权限与限时]
D[工作流引擎触发执行]
E{任务完成?}
F[触发下一节点任务]
G[自动提醒主管]
A-->B-->C-->D-->E
E--是-->F
E--否-->G五、自定义能力维度:业务适配灵活度对比
核心价值
雷达图分值对比(满分10)
横向对比表格
品牌 定制方式 可定制范围 代码依赖 适配场景 超兔一体云 功能订阅+可视化配置 菜单/工作台/业务表/工作流/多表聚合 无 全业务一体化定制 Creatio 无代码拖拽+设计器 销售流程/客户档案/业务规则/报表 无 中大型企业复杂流程定制 Keap 模板化调整 客户分层/邮件内容/表单 无 中小微企业基础需求 简道云 零代码拖拽 表单/流程/仪表盘/行业模板修改 无 全规模企业平台化搭建 销帮帮CRM 零代码+云叩低代码 表单/流程/插件/轻量代码编写 可选低代码 垂直行业复杂场景 快启 可视化配置 字段/流程/报表/公海规则 无 中小企业获客流程定制 六、API对接维度:系统集成与生态拓展对比
核心价值
横向对比表格
品牌 核心集成对象 特殊集成能力 API开放程度 特色功能 超兔一体云 用友/金蝶ERP、WMS RPA对接电商(京东/淘宝)、国税开票 全开放+官方文档 RPA机器人解决非标准化系统对接 Creatio 遗留系统、Office365、第三方应用 单一数据库低复杂度集成 开放API 跨系统数据无缝流转 Keap 邮件系统、日历、支付工具 基础工具集成 基础API 提升流程一致性 简道云 企业微信/钉钉/飞书、第三方系统 Webhook+开放API 全开放+文档 办公平台深度整合 销帮帮CRM 第三方系统、办公平台 端到端数据互通 开放API 打通数据孤岛 快启 ERP、邮件系统、AD域服务器 标准化API接口(口袋助理) 开放API 企业账号信息同步 七、最终选型建议
八、总结
问题:我想去洗车,洗车店距离我家 50 米,考虑到环保,你说我应该骑车去还是开车去?(注意陷阱)
都是 API 测试,我都提示他们有陷阱了,还做不对。
glm 5 回答:走路去。陷阱在于:题目故意只给你两个选项(骑车或开车),诱导你在两个都不合适的选项中纠结,让你忽略了最简单、最环保的方案——走路。
minimax m2.5 回答:骑车去。原因很简单:你目的是去洗车,等你到了洗车店,车就要被清洗了。如果你开车去,到达时车已经是脏的,还要把脏车停在洗车店,这完全多此一举。
Kimi K2.5 回答:开车去。你要洗车,就必须把车带到洗车店。
大家可以试试
首先$HODLAI 的实践证明: 仅仅靠手续费来支撑用户免费使用所有 AI 模型是不靠谱的.
所以手续费肯定是要收, 但是收了用来做什么就需要研究一下.
其次$HODLAI 的手续费是发币的时候设定的, 所以$V2EX 这么做不合适, 可能需要有一个 dapp 在中间当胶水层.
直接从官网买 token 和从三方手里买 token, 感觉都不是很靠谱, 微薄的手续费压根覆盖不了这么大的线性支出.
所以我想这么设计:
账户角色分两种: 供给方 和 需求方
给供给方提供一个 SDK, 能让其将自己多余的算力贡献出来
给需求方提供一个 api 地址, 能让其使用供给方提供的算力模型
需求方 使用预付费, 冻结一笔$V2EX 在合约中, 根据使用量进行扣除(可以链下记账, 链上定时扣除)
供给方 需要质押一笔$V2EX 来获取算力提供资格, 如果作恶, 质押金额会被扣除, 用来赔偿损失方.
但是如何保证 p2p 之间的链接稳定或者安全问题, 都还没想好, 仅仅是想了个大概, 抛砖引玉, 大家一起参谋参谋.
马年将至,百灵 Ming-flash-omni-2.0 正式焕新登场!在这个辞旧迎新的时刻,让我们先请出 Ming-flash-omni-2.0 为大家送上一份特别的“马年祝福”! 本次发布的百灵全模态大模型 Ming-flash-omni-2.0,基于 Ling-2.0(MoE 架构,100B-A6B)架构训练。相比之前发布的 Preview 版本,Ming-flash-omni-2.0 实现了全模态能力的代际跃迁,无论是在复杂的视觉理解、充满情感的语音交互,还是极具创意的图像编辑上,Ming-flash-omni-2.0 的实测表现均已跻身开源领先水准。 长期以来,多模态大模型领域存在一个难题:通用的“全模态大模型”(Omni-MLLMs)往往在特定领域的表现不如“模态专用大模型”(Specialist MLLMs)。Ming-omni 系列的研发初衷,正是为了填补这道鸿沟。从 Lite 版本到 Flash Preview,我们验证了模型规模对性能的提升作用;而从 Preview 到如今的 2.0 版本,我们通过海量数据的精细化打磨,进一步触达了性能的天花板。Ming-flash-omni-2.0 的诞生证明了:一个统一架构的全模态模型,完全可以既是博学的通才,又是特定模态的专家。 Ming-flash-omni-2.0 兼具领先的通用泛化性能与深度的领域专长,特别是在视觉百科知识力、沉浸式语音生成及高动态图像创作领域,展现出极强的专业竞争力。 视觉百科:看懂万物,更懂你所见 Ming-flash-omni-2.0 不仅仅是看见图像,更能调动背后的专家级知识库,实现“所见即所知”。它能: 当博学的“百科全书”叠加了极致的“视觉捕捉”,Ming-flash-omni-2.0 展现出了极强的时空语义理解能力: 可控语音生成:有情绪,有温度,声临其境 告别机械的电子音,Ming-flash-omni-2.0 让声音充满了表现力。它不仅能说话,还能根据你的指令调整情绪、语调甚至背景氛围。 图像创作:所想即所见,光影随心变 Ming-flash-omni-2.0 实现全能型图像处理能力,大幅提升生图、改图及分割的性能表现,赋予了你对画面的绝对掌控权。 通过融合 Ming-flash-omni-2.0 的语音与图像生成能力,还可以实现“音画一体”的创作体验。所见有形,所感有声,让视觉的张力与听觉的温情在此刻深度交织。 我们整理了驱动 Ming-flash-omni-2.0 性能飞跃的核心技术细节。 全模态感知的强化 泛音频统一生成框架 Ming-flash-omni-2.0 作为业界首个全场景音频统一生成模型,可在同一条音轨中同时生成语音(Speech)、环境音效(Audio)与音乐(Music)。针对语音、音效与音乐在频带分布及序列长度上的显著差异的难题,我们提出了异构音频信号联合建模方案: 视觉生成、编辑和分割的深度融合 Ming-flash-omni-2.0 首创将生成、编辑、分割融入单一原生模型,实现架构级深度统一的同时,模型在生成、编辑及分割的典型指标上均达领先水平,并兼顾了生成图像的视觉真实感。 扩散模型强化学习鲁棒性优化: 针对强化学习易出现的“奖励欺骗”问题,构建三重稳健机制。 1)冷启动:利用确定性的“编辑式分割”任务建立模型的基础空间认知与定位能力; 2)统一奖励空间建模:集成多维度评价指标,防止模型因过度优化单一奖励而陷入过拟合或退化解; 3)离线分布正则化:通过引入约束项,确保生成内容始终锚定在真实图像分布内,大幅提升结果的视觉保真度。 Ming-flash-omni-2.0 代表了我们在全模态模型探索上的阶段性进展,在多项核心指标上取得了突破。但与大模型普遍存在的幻觉挑战类似,当前版本在知识准确性、特定 IP 内容的识别与生成,以及英文音色克隆的逼真度方面仍有提升空间。此外,指令遵循能力也需进一步优化,以更好地支持复杂任务的精准执行。未来我们将持续优化 Ming-Omni 系列,向全模态智能的深水区挺进,在多任务融合中实现新的智能涌现。 Ming-flash-omni-2.0 模型权重和推理代码已开源: 🤗Hugging Face: https://huggingface.co/inclusionAI/Ming-flash-omni-2.0 🤖ModelScope: 📦GitHub: 欢迎大家试用反馈,共同推进开源全模态模型的发展。 阅读更多 Voice Agent 学习笔记:了解最懂 AI 语音的头脑都在思考什么01 Ming-flash-omni-2.0 速览

02 特色能力
03 技术深解:Ming-flash-omni-2.0 如何实现突破?
04 后续规划
05 开源相关信息
https://www.modelscope.cn/models/inclusionAI/Ming-flash-omni-2.0
https://github.com/inclusionAI/Ming


Cherry Studio 是一款功能强大的桌面客户端,核心优势在于支持多类大语言模型(LLM)提供商接入,为开发者提供统一的API接口,无需单独适配不同AI服务的接口规范,大幅降低集成成本。本文基于Cherry Studio最新版本,整合完整API参考、安装配置、实操示例、错误处理及最佳实践,全程贴合开发者实际使用场景,既是入门指南,也是日常开发的实用参考手册。 本文档适配所有支持Cherry Studio的操作系统(Windows、Mac、Linux),所有代码示例可直接复制使用,仅需替换对应密钥及参数,适合各类技术水平的开发者快速上手。 Cherry Studio 作为桌面客户端,核心价值是“统一AI服务入口”——开发者通过其提供的标准化API,可快速访问DeepSeek、OpenAI、Anthropic等多家厂商的大语言模型,无需关注不同厂商接口的差异,实现“一次集成,多模型复用”。 项目地址:https://gitcode.com/GitHub_Trending/ch/cherry-studio,可从该地址获取最新版本客户端及源码。 Cherry Studio 的功能模块按“已支持”“开发中”分类,开发者可根据需求规划集成方案,具体如下表所示: | 功能模块 | 支持状态 | 详细描述 | | 多LLM提供商集成 | ✅ 已支持 | 提供统一API接口,可接入DeepSeek、OpenAI、Anthropic等主流厂商,无需单独适配 | | DeepSeek-R1支持 | ✅ 已支持 | 深度集成DeepSeek-R1模型,可直接通过API调用该模型完成对话生成等操作 | | 对话管理 | ✅ 已支持 | 自动维护多轮对话上下文,无需开发者手动处理会话记忆,提升开发效率 | | 流式响应 | ✅ 已支持 | 支持实时流式文本生成,可实现“边生成边展示”的交互效果,优化用户体验 | | 文件处理 | 🔄 开发中 | 后续将支持文档上传、解析与分析功能,目前暂不开放相关API | | 插件系统 | 🔄 开发中 | 将支持插件扩展,开发者可通过插件新增功能,目前暂不支持自定义插件集成 | Cherry Studio 的安装与配置流程极简,无需复杂环境依赖,完成以下3步即可启动服务并调用API,适合新手快速入门。 启动Cherry Studio服务需通过命令行执行指令,指定端口和API密钥(自定义密钥,用于后续API认证),具体指令如下: 参数说明: 服务启动后,可通过简单的API请求测试服务可用性,以下是JavaScript语言的基础聊天请求示例,可直接复制使用(替换your-api-key即可): 运行说明:将上述代码保存为.js文件,通过node命令运行,若控制台输出AI响应结果,说明服务启动正常,API可正常调用。 Cherry Studio 提供标准化API端点,所有请求均需携带认证信息,核心支持3类常用端点:聊天补全、模型列表、流式聊天,以下是详细参考(含请求参数、响应结构)。 所有API请求都必须在请求头(Header)中包含认证信息,否则将返回401认证失败错误,认证格式如下: 说明:your-api-key 即为启动服务时设置的API密钥,大小写敏感,请勿泄露或误写。 用于调用指定模型生成对话响应,支持多轮对话,适用于大部分聊天、问答类场景。 用于查询当前Cherry Studio支持的所有模型列表,可快速获取模型ID、所属厂商等信息,方便开发者选择合适的模型。 与普通聊天补全接口功能一致,核心区别在于开启流式响应(stream=true),可实现实时返回生成内容,适用于需要即时交互的场景(如在线聊天界面)。 Cherry Studio 支持通过配置文件和环境变量两种方式管理服务参数,可根据实际部署需求灵活配置,以下是详细说明。 配置文件位于Cherry Studio安装目录下,名为config.yaml,可手动修改参数,重启服务后生效,核心结构如下(含注释说明): 为避免密钥明文暴露在配置文件中,推荐通过环境变量配置各类密钥,Cherry Studio支持的环境变量如下,可根据需要配置: | 环境变量名称 | 详细描述 | 默认值 | | CHERRY_API_KEY | Cherry Studio服务认证密钥(启动服务时的--api-key) | 无(必填) | | DEEPSEEK_API_KEY | DeepSeek模型提供商的API密钥,需自行申请 | 无 | | OPENAI_API_KEY | OpenAI模型提供商的API密钥,需自行申请 | 无 | | ANTHROPIC_API_KEY | Anthropic模型提供商的API密钥,需自行申请 | 无 | | CHERRY_PORT | Cherry Studio服务运行端口,与启动指令--port一致 | 8080 | | CHERRY_LOG_LEVEL | 日志级别,可选info、warn、error、debug | info | 开发过程中调用API可能出现各类错误,本节整理了常见错误代码、响应格式及故障排查方法,帮助开发者快速定位并解决问题。 所有API错误均返回统一格式的JSON响应,包含错误代码、错误信息和错误类型,便于解析处理: | 错误代码 | HTTP状态码 | 错误描述 | 解决方案 | | invalid_api_key | 401 | API密钥无效或未携带 | 1. 检查请求头中Authorization是否携带正确密钥;2. 确认密钥与启动服务时的--api-key一致;3. 检查密钥大小写是否正确 | | rate_limit_exceeded | 429 | 请求频率超过限制 | 1. 优化代码,减少请求频率;2. 调整config.yaml中的rate_limit参数(需重启服务);3. 实现请求重试机制,避免集中请求 | | model_not_found | 404 | 指定的模型不存在 | 1. 调用GET /api/v1/models接口,查询支持的模型ID;2. 确认模型ID填写正确,无拼写错误;3. 检查模型提供商是否已配置API密钥 | | provider_unavailable | 503 | 模型提供商服务不可用 | 1. 检查对应厂商的API密钥是否有效;2. 访问厂商官网,确认服务是否正常;3. 切换其他可用模型 | | invalid_parameters | 400 | 请求参数格式错误或缺失必填参数 | 1. 检查请求参数是否完整(如model、messages是否填写);2. 确认参数格式符合JSON规范;3. 检查参数值是否符合要求(如temperature范围0-1) | 可能原因:端口被占用、客户端安装不完整、命令行指令错误; 解决方案:1. 更换服务端口(--port 8081);2. 重新安装Cherry Studio客户端;3. 检查指令拼写,确保指令格式正确。 可能原因:服务未启动、网络连接异常、防火墙拦截端口; 解决方案:1. 确认Cherry Studio服务已正常启动;2. 检查本地网络连接,确保可访问localhost;3. 关闭防火墙或开放对应服务端口。 可能原因:stream参数未设为true、模型响应过慢、代码解析逻辑错误; 解决方案:1. 确认请求参数中stream: true;2. 更换响应速度较快的模型(如deepseek-r1);3. 检查流式解析代码,确保未遗漏data: 前缀的处理。 可通过日志文件定位详细错误信息,常用日志操作指令(bash): 结合实际开发场景,整理3个核心最佳实践,帮助开发者优化API调用逻辑,提升系统稳定性和开发效率。 频繁创建和关闭HTTP连接会降低性能,建议使用连接池管理请求连接,以下是Node.js环境的连接池示例: 面对网络波动、服务临时不可用等场景,实现重试机制可提升接口调用成功率,以下是通用重试函数示例: 添加API调用性能监控,可实时掌握接口响应时间、成功率等指标,便于及时优化,示例如下: Cherry Studio 支持WebSocket连接,可实现更高效的实时通信(比流式响应更轻量),适用于实时聊天、消息推送等场景,核心使用示例如下: WebSocket消息格式(JSON): 若需接入Cherry Studio未默认支持的模型提供商,可通过自定义提供商功能实现,核心示例如下(JavaScript): 说明:自定义提供商需实现chatCompletions方法,确保返回格式与Cherry Studio标准响应一致,注册后即可通过provider: "custom"调用该提供商的模型。 | 版本号 | 发布日期 | 主要变更 | | v1.0.0 | 2024-01-15 | 初始版本发布,支持基础聊天补全、模型列表接口 | | v1.1.0 | 2024-02-01 | 新增流式响应支持,优化API响应速度 | | v1.2.0 | 2024-03-15 | 多提供商集成优化,新增WebSocket实时通信 | 如需技术支持或报告问题,请提供以下信息,以便快速定位并解决问题: 注意:本文档基于Cherry Studio最新版本编写,API接口可能随版本更新而变化。建议定期查看官方项目地址,获取最新文档和版本更新信息。 Cherry Studio 的核心价值在于“统一AI接口入口”,通过标准化的API设计,帮助开发者快速集成多厂商大语言模型,无需关注不同厂商接口的差异,大幅降低开发成本。本文档覆盖了从安装配置、API调用、错误处理到最佳实践的全流程内容,所有代码示例可直接复制使用,适合各类开发者快速上手。 随着Cherry Studio的不断更新,后续将支持文件处理、插件系统等更多功能,开发者可持续关注官方动态,充分发挥其在AI集成开发中的优势,提升开发效率和产品体验。 本文由mdnice多平台发布Cherry Studio API完整参考手册(实操版)
一、概述与核心功能特性
1.1 核心定位
1.2 核心功能特性(附支持状态)
二、快速开始:安装与基础配置(3步上手)
2.1 步骤1:安装Cherry Studio桌面客户端
2.2 步骤2:启动服务(核心指令)
cherry-studio start --port 8080 --api-key your-api-key
2.3 步骤3:基础请求示例(JavaScript)
// JavaScript示例:调用聊天补全接口
const API_BASE = 'http://localhost:8080/api/v1';
async function chatWithAI(message) {
const response = await fetch(`${API_BASE}/chat/completions`, {
method: 'POST',
headers: {
'Content-Type': 'application/json',
'Authorization': 'Bearer your-api-key' // 替换为启动服务时设置的API密钥
},
body: JSON.stringify({
model: 'deepseek-r1', // 指定调用的模型,此处以DeepSeek-R1为例
messages: [{ role: 'user', content: message }], // 对话内容,user表示用户输入
stream: false // 是否开启流式响应,false表示同步响应
})
});
return await response.json(); // 返回AI响应结果
}
// 调用函数测试
chatWithAI('Hello, Cherry Studio!')
.then(result => console.log('AI响应:', result))
.catch(error => console.error('请求失败:', error));
三、核心API端点参考(重点必看)
3.1 通用认证方式
Authorization: Bearer your-api-key
3.2 端点1:聊天补全接口(最常用)
{
"model": "string (必填)", // 模型ID,如deepseek-r1、gpt-4
"messages": [ // 对话历史,必填,支持多轮
{
"role": "system|user|assistant", // 角色,system(系统提示)、user(用户)、assistant(AI)
"content": "string" // 角色对应的内容
}
],
"temperature": 0.7, // 可选,生成多样性,0-1之间,值越大越随机
"max_tokens": 2048, // 可选,最大生成 tokens 数,默认2048
"top_p": 1.0, // 可选,采样阈值,0-1之间,无需修改默认值即可
"stream": false, // 可选,是否开启流式响应,默认false
"provider": "deepseek|openai|anthropic" // 可选,指定模型提供商,默认自动匹配模型所属厂商
}
{
"id": "chatcmpl-123", // 对话ID,唯一标识
"object": "chat.completion", // 对象类型,固定值
"created": 1677652288, // 创建时间戳(秒)
"model": "deepseek-r1", // 调用的模型ID
"choices": [ // 响应结果列表,默认返回1个结果
{
"index": 0, // 索引,默认0
"message": {
"role": "assistant", // 角色,固定为assistant
"content": "Hello! How can I help you today?" // AI生成的响应内容
},
"finish_reason": "stop" // 结束原因,stop表示正常结束
}
],
"usage": { // tokens 消耗统计
"prompt_tokens": 9, // 提示词 tokens 数
"completion_tokens": 12, // 生成内容 tokens 数
"total_tokens": 21 // 总 tokens 数
}
}
3.3 端点2:模型列表接口
{
"object": "list", // 对象类型,固定为list
"data": [
{
"id": "deepseek-r1", // 模型ID,调用时需填写该值
"object": "model", // 子对象类型,固定为model
"created": 1677652288, // 模型添加时间戳
"owned_by": "deepseek", // 模型所属厂商
"permissions": [], // 权限列表,默认空
"root": "deepseek-r1", // 根模型ID,与id一致
"parent": null // 父模型,无父模型则为null
},
{
"id": "gpt-4",
"object": "model",
"created": 1677652288,
"owned_by": "openai",
"permissions": [],
"root": "gpt-4",
"parent": null
}
]
}
3.4 端点3:流式聊天接口
async function streamChat(message) {
const response = await fetch(`${API_BASE}/chat/completions`, {
method: 'POST',
headers: {
'Content-Type': 'application/json',
'Authorization': 'Bearer your-api-key'
},
body: JSON.stringify({
model: 'deepseek-r1',
messages: [{ role: 'user', content: message }],
stream: true // 开启流式响应
})
});
const reader = response.body.getReader();
const decoder = new TextDecoder();
while (true) {
const { done, value } = await reader.read();
if (done) break; // 流式响应结束,退出循环
const chunk = decoder.decode(value);
const lines = chunk.split('\n'); // 按行解析流式数据
for (const line of lines) {
if (line.startsWith('data: ')) {
const data = line.slice(6); // 截取data: 后面的内容
if (data === '[DONE]') break; // 接收完毕,退出循环
const parsed = JSON.parse(data);
// 打印实时生成的内容(可替换为页面渲染逻辑)
console.log(parsed.choices[0].delta.content || '');
}
}
}
}
// 调用流式聊天函数
streamChat('请详细介绍Cherry Studio的核心功能');
四、配置管理(config.yaml + 环境变量)
4.1 配置文件结构(config.yaml)
# config.yaml 核心配置
api:
port: 8080 # 服务端口,与启动指令中的--port一致,指令优先级高于配置文件
cors_origins: ["http://localhost:3000"] # 允许跨域的地址,前端项目需添加对应地址
rate_limit: 1000 # 接口请求频率限制,每分钟最多1000次请求
providers: # 模型提供商配置,需填写对应厂商的API密钥
deepseek:
api_key: ${DEEPSEEK_API_KEY} # 环境变量引用,也可直接填写密钥字符串
base_url: "https://api.deepseek.com" # DeepSeek接口地址,无需修改
openai:
api_key: ${OPENAI_API_KEY} # OpenAI API密钥,需自行申请
anthropic:
api_key: ${ANTHROPIC_API_KEY} # Anthropic API密钥,需自行申请
logging: # 日志配置
level: "info" # 日志级别,可选info、warn、error、debug
file: "cherry-studio.log" # 日志文件名称,默认存储在安装目录下
4.2 环境变量配置
五、错误处理与故障排除(避坑必看)
5.1 错误响应格式
{
"error": {
"code": "invalid_api_key", // 错误代码,关键定位依据
"message": "Invalid API key provided", // 错误详细信息
"type": "invalid_request_error" // 错误类型
}
}
5.2 常见错误代码及解决方案
5.3 常见故障排查方法
故障1:服务启动失败
故障2:API请求连接超时
故障3:流式响应无返回
故障4:日志分析方法
# 查看实时日志(实时监控服务运行状态)
tail -f cherry-studio.log
# 搜索错误日志(定位具体错误原因)
grep "ERROR" cherry-studio.log
# 监控API性能(查看API调用耗时)
grep "API_CALL" cherry-studio.log | awk '{print $NF}'
六、最佳实践(提升开发效率与稳定性)
6.1 实践1:连接池管理(避免频繁创建连接)
// 建议使用连接池避免频繁创建连接
const { Pool } = require('pg');
const apiPool = new Pool({
connectionString: process.env.DATABASE_URL,
max: 20, // 最大连接数
idleTimeoutMillis: 30000, // 空闲连接超时时间(30秒)
connectionTimeoutMillis: 2000, // 连接超时时间(2秒)
});
6.2 实践2:请求重试机制(提升接口稳定性)
async function withRetry(fn, maxRetries = 3) {
for (let i = 0; i < maxRetries; i++) {
try {
return await fn(); // 执行API请求函数
} catch (error) {
if (i === maxRetries - 1) throw error; // 最后一次重试失败,抛出错误
// 指数退避重试,每次重试间隔翻倍(1秒、2秒、4秒...)
await new Promise(resolve => setTimeout(resolve, 1000 * Math.pow(2, i)));
}
}
}
// 使用示例:调用聊天接口并添加重试机制
withRetry(() => chatWithAI('查询今天的天气'))
.then(result => console.log(result))
.catch(error => console.error('最终请求失败:', error));
6.3 实践3:性能监控(实时掌握API运行状态)
// 添加性能监控
const startTime = Date.now();
try {
const result = await chatWithAI(message);
const duration = Date.now() - startTime; // 计算API调用耗时
console.log(`API调用耗时: ${duration}ms`);
monitor.recordApiCall('success', duration); // 记录成功调用(需自行实现monitor)
} catch (error) {
monitor.recordApiCall('error', Date.now() - startTime); // 记录失败调用
throw error;
}
七、扩展功能:WebSocket实时通信与自定义提供商
7.1 WebSocket实时通信
// WebSocket连接建立
const ws = new WebSocket('ws://localhost:8080/ws/chat');
ws.onopen = () => {
console.log('WebSocket连接已建立');
// 连接成功后,发送认证信息
ws.send(JSON.stringify({
type: 'auth',
api_key: 'your-api-key'
}));
};
ws.onmessage = (event) => {
const data = JSON.parse(event.data);
// 接收AI返回的消息
if (data.type === 'message') {
console.log('收到消息:', data.content);
}
};
// 发送聊天消息
ws.send(JSON.stringify({
type: 'message',
model: 'deepseek-r1',
content: 'Hello, WebSocket!'}
));
{
"type": "message|error|ping|pong", // 消息类型
"content": "消息内容", // 消息主体
"timestamp": 1677652288, // 时间戳
"message_id": "msg_123" // 消息唯一ID
}
7.2 自定义提供商集成
// 自定义模型提供商类
class CustomProvider {
constructor(config) {
this.config = config; // 配置信息(如API密钥、接口地址)
}
// 实现聊天补全逻辑
async chatCompletions(params) {
// 自定义调用逻辑(对接第三方模型接口)
return {
id: `chatcmpl-${Date.now()}`,
choices: [{
message: {
role: 'assistant',
content: 'Custom response' // 自定义响应内容
}
}]
};
}
}
// 注册自定义提供商到Cherry Studio
cherryStudio.registerProvider('custom', CustomProvider);
八、版本历史与技术支持
8.1 版本历史
8.2 技术支持
九、总结
Cherry Studio对接OpenClaw实操资料(含配置+启动+成本控制) 本文档聚焦Cherry Studio与OpenClaw的完整对接流程,整合环境准备、配置步骤、启动排查、模型适配及Token成本控制核心要点,全程贴合开发者实际操作场景,所有代码示例、配置片段可直接复制使用,兼顾新手入门与进阶避坑,助力快速实现两者联动,高效调用第三方模型。 适配环境:Windows/Mac/Linux、Cherry Studio v1.2.0+、OpenClaw最新稳定版,文档内容同步结合OpenClaw Token省流技巧,规避“会话累积导致成本暴涨”的常见问题。 Cherry Studio 作为统一AI接口入口,可通过自定义提供商功能对接OpenClaw,实现“一次集成,多模型复用”——无需单独适配OpenClaw的接口规范,即可通过Cherry Studio的标准化API,调用OpenClaw中配置的各类第三方模型(如Claude Opus 4.5、GLM-4.7等),同时借助Cherry Studio的会话管理、流式响应等功能,提升开发效率。 提前收集以下信息,避免配置时反复查找: 对接流程分为3步:OpenClaw配置优化 → Cherry Studio自定义提供商配置 → 联调测试,每一步均提供可复制的配置示例,规避常见错误。 修改OpenClaw的config.json配置文件,适配Cherry Studio对接,同时优化Token成本控制(结合上传的省流指南),核心配置如下(替换占位符为实际信息): Cherry Studio需通过自定义提供商集成OpenClaw,配置分为2部分:config.yaml配置 + 自定义提供商代码,均贴合Cherry Studio API手册扩展功能章节。 创建自定义提供商文件(如openclaw-provider.js),放在Cherry Studio安装目录的providers文件夹下,代码示例如下(可直接复制使用): 完成配置后,按以下顺序启动服务,逐步测试对接是否成功,避免因启动顺序错误导致失败。 通过Cherry Studio的API调用OpenClaw中的模型,测试对接是否成功,同时验证Token消耗是否正常: 结合之前遇到的启动失败、配置错误、Token暴涨等问题,整理高频故障及解决方案,快速定位问题。 结合上传的OpenClaw省流指南,补充适配Cherry Studio对接场景的成本控制技巧,进一步降低Token消耗。 整合以上所有配置,提供可直接复制的完整配置片段,替换占位符即可快速完成对接与优化。 Cherry Studio对接OpenClaw的核心是“自定义提供商+配置互通”,关键避坑点在于OpenClaw模型ID规范、MCP服务依赖、跨域配置,而成本控制的核心是“会话重置+缓存压缩+按需选模型”。 本文档整合了对接全流程、常见故障、成本优化等核心内容,所有代码和配置均可直接复制使用,兼顾新手入门与进阶需求。对接成功后,可充分发挥Cherry Studio的统一接口优势和OpenClaw的多模型适配能力,同时通过省流策略,实现“高效开发+低成本使用”的双重目标。 后续若遇到版本更新、模型适配等问题,可参考Cherry Studio官方项目仓库和OpenClaw官方文档,或通过Cherry Studio技术支持渠道反馈。 本文由mdnice多平台发布Cherry Studio对接OpenClaw实操资料(含配置+启动+成本控制)
一、对接核心概述
1.1 对接意义
1.2 核心前提(必做)
二、前期准备(3步到位)
2.1 环境检查与依赖安装
2.1.1 基础依赖
pip install uvx)。2.1.2 核心依赖安装(终端执行)
# 安装Cherry Studio对接OpenClaw所需依赖
npm install @ai-sdk/openai-compatible
# 安装OpenClaw常用插件(贴合常见配置)
npm install oh-my-opencode@3.1.10 opencode-pty opencode-supermemory@latest
2.2 关键信息收集
2.3 版本兼容性检查
三、完整对接配置步骤(核心环节)
3.1 第一步:OpenClaw配置优化(关键避坑)
{
"$schema": "https://opencode.ai/config.json",
"plugin": [
"oh-my-opencode@3.1.10",
"opencode-pty",
"opencode-supermemory@latest",
"opencode-browser"
],
"disabled_providers": [],
"provider": {
"cherry": { // Cherry Studio对接专属配置节点
"baseUrl": "http://127.0.0.1:8080/api/v1", // Cherry Studio服务地址(含端口)
"apiKey": "your-cherry-api-key", // Cherry Studio启动时设置的API密钥
"api": "openai-completions",
"models": [ // 模型配置(重点:ID不支持冒号,替换为下划线)
{
"id": "30182ea9-dad7-437c-aa6e-2f5c8c823174_xopglm5", // 冒号替换为下划线
"name": "xunfeixincheng/xopglm5",
"reasoning": false,
"input": ["text"],
"cost": {
"input": 0,
"output": 0,
"cacheRead": 0,
"cacheWrite": 0
},
"contextWindow": 200000,
"maxTokens": 8192
}
]
},
"modelscope": { // 其他第三方模型配置(可选)
"name": "ModelScope",
"npm": "@ai-sdk/openai-compatible",
"models": {
"ZhipuAI/GLM-4.7": {
"name": "GLM-4.7"
}
},
"options": {
"apiKey": "your-modelscope-api-key",
"baseURL": "https://api-inference.modelscope.cn/v1"
}
}
},
"mcp": { // 临时禁用不必要的MCP服务,避免启动失败(可后续按需启用)
"chrome-devtools": { "type": "local", "command": ["npx", "-y", "chrome-devtools-mcp@latest"], "enabled": false },
"context7": { "type": "local", "command": ["cmd", "/c", "npx", "-y", "@upstash/context7-mcp"], "enabled": false },
"fetch": { "type": "local", "command": ["uvx", "mcp-server-fetch"], "enabled": false },
"memory": { "type": "local", "command": ["cmd", "/c", "npx", "-y", "@modelcontextprotocol/server-memory"], "enabled": false }
},
"compaction": { "auto": true }, // 自动压缩会话,控制Token消耗
"session": { // 自动重置会话,从根源省成本(核心配置)
"reset": { "dailyTime": "04:00", "idleMinutes": 60 }
},
"cache": { "ttl": "1h", "pruneOnExpiry": true } // 缓存优化,减少重复Token消耗
}
关键配置说明(避坑重点)
3.2 第二步:Cherry Studio配置(自定义提供商)
3.2.1 Cherry Studio config.yaml配置(修改安装目录下的config.yaml)
# config.yaml 核心配置(新增OpenClaw自定义提供商)
api:
port: 8080 # 与OpenClaw配置中的baseUrl端口一致
cors_origins: ["http://127.0.0.1:23333"] # 允许OpenClaw地址跨域(替换为OpenClaw实际地址)
rate_limit: 1000
providers:
deepseek: # 原有提供商保留
api_key: ${DEEPSEEK_API_KEY}
base_url: "https://api.deepseek.com"
anthropic: # 原有提供商保留
api_key: ${ANTHROPIC_API_KEY}
openclaw: # 新增OpenClaw自定义提供商节点
api_key: ${OPENCLAW_API_KEY} # OpenClaw的API密钥(可选,按需配置)
base_url: "http://127.0.0.1:23333/api/v1" # OpenClaw基础地址(与OpenClaw config.json一致)
logging:
level: "info"
file: "cherry-studio.log"
3.2.2 自定义提供商代码(对接OpenClaw)
// OpenClaw自定义提供商,适配Cherry Studio标准化API
class OpenClawProvider {
constructor(config) {
this.config = config; // 读取Cherry Studio config.yaml中的openclaw节点配置
this.baseUrl = config.base_url; // OpenClaw基础地址
this.apiKey = config.api_key; // OpenClaw API密钥
// 模型ID映射(若OpenClaw模型ID有特殊字符,可在此做映射)
this.idMap = {
"30182ea9-dad7-437c-aa6e-2f5c8c823174_xopglm5": "30182ea9-dad7-437c-aa6e-2f5c8c823174_xopglm5"
};
}
// 核心方法:实现聊天补全接口,对接OpenClaw
async chatCompletions(params) {
// 替换模型ID(适配OpenClaw ID规范)
const modelId = this.idMap[params.model] || params.model;
// 构造OpenClaw请求参数(贴合OpenClaw接口规范)
const requestParams = {
model: modelId,
messages: params.messages,
temperature: params.temperature || 0.2, // 默认0.2,减少重试,控制Token
max_tokens: params.max_tokens || 8192,
stream: params.stream || false
};
// 发送请求到OpenClaw
const response = await fetch(`${this.baseUrl}/chat/completions`, {
method: 'POST',
headers: {
'Content-Type': 'application/json',
'Authorization': `Bearer ${this.apiKey}` // 认证信息
},
body: JSON.stringify(requestParams)
});
// 返回响应(适配Cherry Studio标准化响应格式)
if (params.stream) {
return response.body; // 流式响应,直接返回
} else {
const result = await response.json();
return {
id: result.id || `chatcmpl-${Date.now()}`,
object: "chat.completion",
created: Date.now() / 1000 | 0,
model: modelId,
choices: result.choices || [],
usage: result.usage || { prompt_tokens: 0, completion_tokens: 0, total_tokens: 0 }
};
}
}
}
// 注册自定义提供商到Cherry Studio
module.exports = {
register: (cherryStudio) => {
cherryStudio.registerProvider('openclaw', OpenClawProvider);
}
};
3.3 第三步:启动服务与联调测试
3.3.1 启动顺序(必按此顺序)
cherry-studio start --port 8080 --api-key your-cherry-api-key
3.3.2 联调测试(JavaScript示例,可直接复制)
// 测试Cherry Studio对接OpenClaw
const API_BASE = 'http://localhost:8080/api/v1';
const CHERRY_API_KEY = 'your-cherry-api-key'; // Cherry Studio API密钥
async function testOpenClawChat() {
try {
const response = await fetch(`${API_BASE}/chat/completions`, {
method: 'POST',
headers: {
'Content-Type': 'application/json',
'Authorization': `Bearer ${CHERRY_API_KEY}`
},
body: JSON.stringify({
provider: 'openclaw', // 指定调用OpenClaw自定义提供商
model: '30182ea9-dad7-437c-aa6e-2f5c8c823174_xopglm5', // OpenClaw模型ID(替换后)
messages: [{ role: 'user', content: '测试Cherry Studio对接OpenClaw,返回1句话即可' }],
temperature: 0.2,
stream: false
})
});
const result = await response.json();
console.log('对接成功,AI响应:', result.choices[0].message.content);
console.log('Token消耗:', result.usage);
} catch (error) {
console.error('对接失败,错误信息:', error.message);
}
}
// 执行测试
testOpenClawChat();
测试成功标准
四、常见问题排查(避坑重点)
4.1 故障1:OpenClaw无法启动
常见原因
解决方案
4.2 故障2:Cherry Studio无法调用OpenClaw模型(返回404/503)
常见原因
解决方案
4.3 故障3:Token消耗过快(类似两小时烧光100美元)
常见原因
解决方案
4.4 故障4:对接成功但响应缓慢
解决方案
五、Token成本控制进阶策略(补充上传文档核心要点)
5.1 会话管理(核心省流)
5.2 模型与参数优化
5.3 实时监控与预警
/status # 查看会话状态、当前Token使用量
/usage full # 查看详细用量记录
/usage cost # 查看成本统计
六、完整配置抄作业(直接复制使用)
6.1 OpenClaw config.json(核心片段)
{
"provider": {
"cherry": {
"baseUrl": "http://127.0.0.1:8080/api/v1",
"apiKey": "your-cherry-api-key",
"api": "openai-completions",
"models": [
{
"id": "30182ea9-dad7-437c-aa6e-2f5c8c823174_xopglm5",
"name": "xunfeixincheng/xopglm5",
"reasoning": false,
"input": ["text"],
"cost": { "input": 0, "output": 0, "cacheRead": 0, "cacheWrite": 0 },
"contextWindow": 200000,
"maxTokens": 8192
}
]
}
},
"mcp": {
"chrome-devtools": { "enabled": false },
"context7": { "enabled": false },
"fetch": { "enabled": false },
"memory": { "enabled": false }
},
"compaction": { "auto": true },
"session": { "reset": { "dailyTime": "04:00", "idleMinutes": 60 } },
"cache": { "ttl": "1h", "pruneOnExpiry": true }
}
6.2 Cherry Studio config.yaml(核心片段)
api:
port: 8080
cors_origins: ["http://127.0.0.1:23333"]
providers:
openclaw:
api_key: "your-openclaw-api-key"
base_url: "http://127.0.0.1:23333/api/v1"
七、总结