才发现 Chrome 居然长按后退键能列出历史页面记录!
又试了右键也可以,以前都是狂按后退,要么就是打开历史列表。
xiaohack博客专注前沿科技动态与实用技术干货分享,涵盖 AI 代理、大模型应用、编程工具、文档解析、SEO 实战、自动化部署等内容,提供开源项目教程、科技资讯日报、工具使用指南,助力开发者、AI 爱好者获取前沿技术与实战经验。
社区的朋友们大家好!这是我们首次借用 vibe coding 的方式生成一篇完整的活动图文回顾,欢迎评论留言反馈! 有条件的朋友还可以查看网页版: https\://physical-ai-meetup-beijing-0309.vercel.app/ 2026 开年,开源项目 OpenClaw 的热度证明了个人化 AI 的潜力。从纯文本对话演进而来,Voice Agent 正在 Go Visual、Go Physical,并在往横跨桌面端、移动端与智能硬件的 Go Everywhere。跨平台、多模态的落地实战已经展开。 上周六(3 月 7 日),Physical AI Camp 北京站\&RTE Meetup 落地北京望京留创园。我们邀请了来自声网、矽递科技、Intent Company 和盒智科技的技术与产品专家。大家将围绕模型、通讯、硬件解决方案和终端落地场景的跨平台协同,交流真实的经验。 活动现场的精彩,不止于流程的顺利和思维的碰撞,更在于大家的热情参与。无须多言,一组现场图带大家回顾活动当天现场的热烈氛围! 本次 RTE Meetup 也是 RTE 开发者社区即将推出的 「Physical AI Camp·超音速计划 2026」 的预热前哨站。 我们即将开启一个为期 3 个月的创业营,招募正在 Voice Agent、Physical AI 和实时多模态 AI 领域探索的创业团队。营期内,我们将为入营项目提供技术资源支持、投融资对接,以及行业头部展会的展位资源。 如果你正在这个领域创业,欢迎联系我们! 💡 我们也新开了一个「Physical AI+多模态」微信群,欢迎关注 AI 硬件、跨平台开发、语音交互、视觉理解等方向的伙伴申请加入! 加微信 Creators2022,备注身份和来意(公司/项目+职位/技术栈+加 Physical AI 群),备注完整者优先。 阅读更多 Voice Agent 学习笔记:了解最懂 AI 语音的头脑都在思考什么









关于 Physical AI Camp·超音速计划 2026




目录: 在前面的文章中,咱们聊了: 但是!有一个很现实的问题: 答案就在今天要讲的主题——<font style="color:rgb(118, 146, 60);">提示词工程(Prompt Engineering)</font>。 先来看一个真实的对比。 用户 A 的提示词: AI 的回复: (非常笼统,没什么用) 用户 B 的提示词: AI 的回复: 非常专业,直接可用。 这就是<font style="color:rgb(118, 146, 60);">提示词工程</font>的价值。 <font style="color:rgb(118, 146, 60);">提示词就是你发给 AI 的指令、问题或要求</font>。 <font style="color:rgb(118, 146, 60);">提示词工程(Prompt Engineering)</font>就是: <font style="color:rgb(118, 146, 60);">提示词工程 = 和 AI "沟通"的艺术</font>。 就像和人沟通一样: <font style="color:rgb(118, 146, 60);">大模型是很"听话"的,但前提是你得"说清楚"</font>。 <font style="color:rgb(118, 146, 60);">提示词写得不好,AI 就无法理解你的真实意图</font>。 任务:让 AI 解释一个技术概念 提示词 A: 输出 A: (还行,但太笼统) 提示词 B: 输出 B: (非常详细、专业、易懂!) <font style="color:rgb(118, 146, 60);">看到了吗?提示词越好,输出质量越高</font>。 这是本文的核心!记住这六个原则,你的提示词水平会大幅提升。 告诉 AI 它 <font style="color:rgb(118, 146, 60);">扮演什么角色</font>。 <font style="color:rgb(118, 146, 60);">为什么要明确角色?</font> 常见角色示例: 清楚地告诉 AI 你 <font style="color:rgb(118, 146, 60);">要它做什么</font>。 <font style="color:rgb(118, 146, 60);">任务描述要具体:</font> 告诉 AI 你 <font style="color:rgb(118, 146, 60);">有什么具体要求</font>。 <font style="color:rgb(118, 146, 60);">要求越具体,输出越符合预期</font>。 给 AI 提供 <font style="color:rgb(118, 146, 60);">背景信息</font> 。 <font style="color:rgb(118, 146, 60);">上下文包括:</font> 告诉 AI 你 <font style="color:rgb(118, 146, 60);">希望什么格式的输出</font>。 <font style="color:rgb(118, 146, 60);">常用格式:</font> 如果可以,<font style="color:rgb(118, 146, 60);">给 AI 一个参考示例</font>。 <font style="color:rgb(118, 146, 60);">示例的作用:</font> 咱们来学习一些实用的提示词技巧。 让 AI <font style="color:rgb(118, 146, 60);">展示思考过程</font>。 输出效果: <font style="color:rgb(118, 146, 60);">思维链可以显著提高复杂问题的准确率</font>。 给 AI <font style="color:rgb(118, 146, 60);">几个示例</font>,让它照着做。 这是一个<font style="color:rgb(118, 146, 60);">万能模板</font>: 实际应用: 复杂问题<font style="color:rgb(118, 146, 60);">拆成多个小问题</font>。 <font style="color:rgb(118, 146, 60);">分步提问 = 更精准的结果</font>。 明确告诉 AI <font style="color:rgb(118, 146, 60);">不应该做什么</font>。 好提示词是<font style="color:rgb(118, 146, 60);">迭代出来的</font>,不是一次写成的。 任务:让 AI 推荐一本学习 Python 的书 输出: (有点太简单了) 输出: (好多了,但还是有点笼统) 输出: <font style="color:rgb(118, 146, 60);">完美!</font> <font style="color:rgb(118, 146, 60);">迭代优化的关键:</font> 咱们今天主要讲了以下几点: 1. 什么是提示词工程 2. 为什么提示词很重要 3. 好提示词的六个原则 4. 实用技巧 5. 迭代优化 6. 关键公式 今天留一个实践题: 提示:先用目前的水平写一版,然后根据今天学的内容不断优化,看看最后能优化成什么样。 欢迎在评论区分享你的提示词,咱们一起交流进步! <font style="color:rgb(118, 146, 60);">往期推荐:</font> 如果这篇文章对你有帮助,欢迎点赞关注,我会持续用大白话讲解复杂的技术概念! <font style="color:rgb(118, 146, 60);">系列文章进度:</font> <font style="color:rgb(118, 146, 60);">下一期预告:</font> RAG 是什么?如何让大模型联网学习? 本文由mdnice多平台发布一、前文回顾
<font style="color:rgb(118, 146, 60);">同样的 ChatGPT,为什么有的人用得特别溜,有的人却觉得不好用?</font>
二、背景引入:为什么同样的AI,不同人用差距这么大?
场景:让 AI 写周报
"写周报"本周工作总结:
1. 完成了日常任务
2. 参与了团队会议
3. 学习了新知识
下周计划:
1. 继续完成日常工作
2. 提升专业技能"你是一名软件工程师,请帮我写一份本周工作周报。
本周完成了以下工作:
1. 完成了用户登录功能的前端开发
2. 修复了3个线上bug
3. 参与了需求评审会议
请用专业的格式,包含:工作内容、完成情况、遇到的问题、下周计划。
语气要正式,适合发给领导看。"【本周工作周报】
一、工作内容与完成情况
1. 用户登录功能开发(已完成)
- 实现了手机号登录、微信登录两种方式
- 完成了表单验证和错误提示
- 联调通过,准备提测
2. 线上问题修复(3项,均已完成)
- 修复了首页加载慢的问题(优化了接口)
- 修复了订单状态同步异常的问题
- 修复了Android端闪退问题
3. 需求评审(已完成)
- 参与了V2.0版本需求评审
- 提出了3个技术可行性建议
二、遇到的问题与解决方案
- 登录接口响应慢:通过加缓存优化到200ms以内
- 微信SDK兼容问题:查阅文档后找到解决方案
三、下周计划
1. 用户登录功能提测并修复bug
2. 开始V2.0版本开发
3. 继续跟进线上问题
四、风险与建议
- 建议提前安排登录功能的安全测试三、核心概念一:什么是提示词工程
3.1 什么是提示词(Prompt)?
提示词示例:
- "写一首诗"
- "解释什么是量子力学"
- "帮我把这段话翻译成英文"
- "你是专业的Python工程师,请帮我写代码..."3.2 什么是提示词工程?
设计和优化提示词,让 AI 产出更好结果的<font style="color:rgb(118, 146, 60);">技术和艺术</font>。
3.3 提示词工程的本质
四、核心概念二:为什么提示词这么重要
4.1 提示词是连接你和 AI 的桥梁
你的想法 → 提示词 → AI 理解 → AI 输出
↑
关键!4.2 好的提示词能带来什么?
对比项 糟糕的提示词 好的提示词 输出质量 泛泛而谈、不精准 针对性强、高质量 输出格式 随机、不可用 符合要求、可直接用 沟通效率 来回多次纠正 一次到位 用户体验 觉得 AI 不好用 觉得 AI 很强大 4.3 真实案例对比
"解释什么是微服务"微服务是一种软件架构风格,它将应用程序
拆分成多个小的服务,每个服务独立部署..."你是一名资深架构师,请向一个刚入行的程序员
解释什么是微服务架构。
要求:
1. 用通俗易懂的语言,避免太多专业术语
2. 举一个生活中的类比帮助理解
3. 对比单体架构,说明微服务的优缺点
4. 给出微服务适用场景的建议"【微服务架构详解】
一、什么是微服务?
想象一下你开了一家餐厅:
单体架构就像一个"全能厨师":
- 一个人负责切菜、炒菜、煮饭、洗碗
- 如果这个厨师生病了,整个餐厅就停业了
- 想增加人手也很困难,因为一个人掌握所有技能
微服务架构就像"专业团队":
- 有专门的切菜工、炒菜师、煮饭师、洗碗工
- 每个人只负责自己的工作
- 一个人请假,其他人可以继续工作
- 想扩大规模,只需要多招几个对应岗位的人
微服务就是把一个大的应用程序,拆成多个小的、
独立的服务,每个服务专注于一个功能。
二、对比单体架构
单体架构:
✅ 开发简单,部署方便
❌ 一个bug可能导致整个系统崩溃
❌ 难以扩展,升级需要整体部署
❌ 技术栈统一,难以使用新技术
微服务架构:
✅ 服务独立,一个服务出问题不影响其他服务
✅ 可以针对每个服务单独扩展
✅ 可以使用不同技术栈
✅ 团队可以并行开发
❌ 运维复杂,需要管理多个服务
❌ 服务间调用有性能损耗
❌ 分布式事务处理困难
三、适用场景建议
适合用微服务的情况:
- 团队规模大(超过10人)
- 业务复杂度高
- 需要快速迭代和独立部署
- 不同模块有不同性能要求
不适合用微服务的情况:
- 项目刚开始,业务不明确
- 团队规模小(3-5人)
- 业务简单,不需要拆分五、核心概念三:好提示词的六个原则
原则一:明确角色
❌ "帮我写一篇文章"
✅ "你是一名有10年经验的科技记者,请帮我写一篇关于AI的文章"领域 角色设定 编程 资深软件工程师、架构师、代码审查专家 写作 科技记者、小说作家、文案策划 教育 有经验的老师、一对一辅导员 商业 咨询顾问、产品经理、数据分析师 原则二:明确任务
❌ "Python"
✅ "用Python写一个快速排序算法,包含详细注释"原则三:明确要求
❌ "写一篇关于环保的文章"
✅ "写一篇关于环保的文章,要求:
1. 字数800-1000字
2. 适合初中生阅读
3. 包含3个实用的环保建议
4. 语气积极向上
5. 用讲故事的方式开头"原则四:提供上下文
❌ "帮我优化这段代码"
✅ "我是一名Java初学者,这段代码功能是正确的,
但是运行速度很慢,处理100万条数据需要10分钟。
请帮我分析性能瓶颈,并给出优化建议。
如果有多个优化点,请按重要性排序。
"原则五:指定格式
❌ "分析一下这个产品"
✅ "请从以下维度分析这款产品:
1. 产品定位(用一句话概括)
2. 目标用户(年龄段、特征)
3. 核心功能(列出3-5个)
4. 竞争优势(对比竞品)
5. 潜在问题(列举2-3个)
请用表格形式呈现,每个维度不超过50字"格式类型 适用场景 表格 对比分析、特征列举 列表 步骤说明、要点总结 Markdown 技术文档、结构化内容 JSON/代码 程序化处理、API调用 分段 长文写作、报告生成 原则六:给出示例
❌ "帮我写几条产品文案"
✅ "请帮我为一款智能手表写产品文案。
风格要简洁有力,突出卖点。
示例参考:
'24小时健康监测,你的私人医生'
请按照这个风格,写出5条不同侧重点的文案"六、核心概念四:实用技巧和模板
技巧一:思维链(Chain of Thought)
❌ "小明有5个苹果,吃了2个,又买了3个,现在有几个?"
✅ "小明有5个苹果,吃了2个,又买了3个,现在有几个?
请一步步思考:
1. 先计算吃掉后还剩多少
2. 再计算买后又变成多少
3. 给出最终答案"一步步思考:
1. 小明有5个苹果,吃了2个,还剩 5-2=3个
2. 又买了3个,现在有 3+3=6个
3. 最终答案:6个苹果技巧二:少样本学习(Few-Shot)
❌ "把下面的句子改成更正式的表达"
✅ "请把下面的句子改成更正式的表达。
示例1:
原文:这个项目搞砸了
改写:该项目未能达到预期目标
示例2:
原文:咱们明天开个会
改写:建议明日召开会议讨论
现在请改写:
原文:这个东西太好用了
改写:"技巧三:角色+场景+任务+格式
【角色】你是一名...
【场景】我遇到的问题是...,我的背景是...
【任务】请帮我...,具体要求是...
【格式】请以...格式输出【角色】你是一名有5年经验的Python后端工程师
【场景】我在做一个电商项目,需要实现订单状态流转功能
【任务】请帮我设计订单状态机,包括状态定义和流转条件
【格式】请用代码+注释的形式,并给出状态转换图技巧四:分步提问
❌ "帮我设计一个电商网站"
✅:
Step 1: "电商网站有哪些核心功能模块?请列举并说明优先级"
Step 2: "用户模块需要包含哪些功能?请详细列出"
Step 3: "请帮我设计用户注册登录的数据库表结构"
Step 4: "请用Python实现用户注册的API接口"技巧五:约束条件
✅ "请解释量子计算,要求:
- 不要使用太多数学公式
- 不要超过500字
- 不要使用专业术语
- 不要编造事实
- 面向普通读者"七、核心概念五:提示词的迭代优化
7.1 迭代流程

7.2 实战案例:迭代优化提示词
第一版提示词:
"推荐一本Python书"我推荐《Python编程:从入门到实践》,
这本书适合初学者...第二版提示词:
"我是编程零基础,想学Python做数据分析。
请推荐一本适合我的书,并说明推荐理由。"针对你的情况,我推荐《利用Python进行数据分析》。
推荐理由:
1. 专注于数据分析方向
2. 有丰富的实例
3. 涵盖pandas、numpy等核心库
...第三版提示词:
"我是编程零基础,想学Python做数据分析。
请按以下格式推荐书籍:
【推荐书籍】书名+作者
【适合人群】什么样的读者适合这本书
【核心内容】这本书主要讲什么(3-5点)
【推荐理由】为什么推荐(结合我的情况)
【学习建议】如何使用这本书学习
【备选方案】如果这本书不适合,还有什么替代选择"【推荐书籍】
《Python编程:从入门到实践》
作者:Eric Matthes
【适合人群】
- 编程零基础的小白
- 想快速上手实践的读者
- 希望循序渐进学习的初学者
【核心内容】
1. Python基础语法和数据类型
2. if语句、列表、字典等基础概念
3. 类和面向对象编程入门
4. 实战项目:外星人入侵游戏、数据可视化、Web应用
【推荐理由】
针对你零基础想学数据分析的情况:
1. 前半部分打好Python基础,后半章节包含数据可视化,
正好衔接你的目标
2. 强调实践,每个知识点都有代码示例
3. 项目驱动,学完能做出实际东西
【学习建议】
1. 前10章打基础,每天1-2章
2. 重点练习第6-9章(列表、字典、类)
3. 学完后继续学习《利用Python进行数据分析》
4. 边学边敲代码,不要只看不练
【备选方案】
如果你想直接学数据分析:
- 《利用Python进行数据分析》- Wes McKinney
(适合有一定编程基础的读者)
如果更喜欢视频学习:
- B站上的"Python零基础教程"系列八、常见场景的提示词示例
场景一:写代码
你是一名资深[语言]工程师,请帮我[具体任务]。
背景:
- 我要实现的功能是:[描述]
- 当前遇到的问题是:[描述]
- 我的经验水平:[初学者/中级/高级]
要求:
1. 代码要有详细注释
2. 遵循最佳实践
3. 包含错误处理
4. 给出使用示例场景二:写文章
你是一名资深的[领域]撰稿人,请帮我写一篇关于[主题]的文章。
文章要求:
1. 目标读者:[描述读者群体]
2. 文章风格:[专业/通俗/幽默/正式]
3. 字数要求:[具体字数]
4. 核心观点:[要传达的主要观点]
5. 文章结构:[大纲或要求]
请用:
- 吸引人的标题
- 开头要有吸引力
- 中间内容要有干货
- 结尾要有总结或号召场景三:分析问题
我遇到了一个[领域]的问题,请帮我分析。
问题描述:
[详细描述问题]
背景信息:
- 我的目标是:[描述]
- 当前情况是:[描述]
- 我已经尝试过:[描述]
- 限制条件是:[描述]
请从以下角度分析:
1. 问题根源是什么
2. 有哪些可能的解决方案
3. 每个方案的优缺点
4. 你推荐哪个方案,为什么
请用表格形式呈现方案对比。场景四:学习辅导
你是一名有经验的[学科]老师,请帮我学习[主题]。
我的情况:
- 当前水平:[零基础/初学/有基础]
- 学习目标:[具体目标]
- 学习时间:[每天/每周多少时间]
- 遇到的困难:[描述]
请提供:
1. 学习路线图(分阶段)
2. 每个阶段的学习内容和时间安排
3. 推荐的学习资源(书/视频/网站)
4. 学习方法和注意事项
5. 如何检验学习效果
请用循序渐进的方式,适合我当前水平。场景五:邮件/消息
请帮我写一封[类型]的邮件/消息。
场景:
- 收件人是:[职位/关系]
- 发送目的:[具体目的]
- 核心内容:[要传达的信息]
- 期望结果:[希望对方做什么]
邮件要求:
1. 语气:[正式/友好/紧急/委婉]
2. 长度:[简洁/详细]
3. 重点:[需要突出的内容]
请包含:
- 合适的标题
- 清晰的开场
- 结构化的正文
- 明确的结尾/行动号召九、本文小结
原则 要点 明确角色 告诉 AI 扮演什么角色 明确任务 清楚说明要做什么 明确要求 具体的要求清单 提供上下文 给出背景信息 指定格式 规定输出格式 给出示例 提供参考样例 好的提示词 = 明确角色 + 清晰任务 + 具体要求 + 足够上下文 + 合适格式十、今日思考题
选择一个你经常使用的场景(比如写代码、写文章、学知识),按照今天讲的原则和技巧,写一个"终极版"提示词。
3 月 9 日,Anthropic 正式推出了一款名为 Code Review 的代码审查产品。与传统运行在开发者本地 IDE 中的辅助插件不同,该服务直接卡位 GitHub 和 CI/CD 流程,在代码提交后、人工审查前进行自动拦截与检查。 然而,真正引发开发者圈子震动的是其高昂的定价。Claude Code 创始人 Boris 证实,该服务按 token 消耗量计费,平均每次 Pull Request(PR)的审查费用在 15 到 25 美元之间。 开发者 Sinai Gross 实测了 3 个 PR(两个约 750 行,一个约 100 行),平均单次花费达 18.39 美元。 如果将这个成本放入中大型工程团队中,数字将变得极为夸张。以一个 50 人的开发团队为例,假设每人每天提交 1-2 个 PR,按单次 20 美元计算,每天的审查费用高达 2000 美元,全年成本轻松突破 70 万美元。随着企业规模扩大,这笔费用极易飙升至数百万美元。 作为对比,市面上同样主打 AI 代码审查的 CodeRabbit,其包月费用仅为 24 美元(且对开源项目免费)。这意味着 Claude 多跑两三次 PR,花费就已经超过了竞品一个月的价格。 在追求极致效率的 AI 工具赛道里,Claude 的 Code Review 显得异常“慢”。Anthropic 官方表示,平均一次审查需要耗时约 20 分钟。 这种延迟来源于其底层设计的刻意选择:并行 Agent 机制与全代码库扫描。系统并非只盯着 PR 改动的寥寥几行代码,而是将整个代码库作为上下文进行遍历,以排查不同模块间可能引发的连锁 Bug。 此外,Anthropic 产品负责人 Cat Wu 明确表示,这组并行的 AI Agent 仅专注于“逻辑错误(logic errors)”,而完全忽略代码风格问题。数据显示,在超过 1000 行变更的大型 PR 中,84% 的自动审查能发现平均 7.5 个有效问题;而在人类工程师的反馈中,被 AI 标记的问题否决率不到 1%。 Anthropic 在发布时透露了一个略显讽刺的行业现状:过去一年,自家工程师的代码产量暴增了 200%,导致“代码审查”成了开发流程中最大的瓶颈。写代码的速度远超审代码的速度,PR 堆积如山,人类工程师根本看不完。 于是,Anthropic 给出的解决方案是:用 AI 来审 AI 写的代码。 这一逻辑迅速引发了社区的强烈质疑。有开发者尖锐地指出,这违背了“裁判不能同时当运动员”的基本原则。既然 Claude 具备查出 Bug 的能力,为什么不能在生成代码的阶段就直接写对?甚至有阴谋论吐槽:这会不会演变成 Claude 先故意(或受限于能力)写出一堆包含隐患的代码,然后再通过“修复自己制造的 Bug”来持续按量收费? 👇 欢迎关注我的公众号 在 AI 爆发的深水区,我们一起探索真正能穿越周期的技术价值。 欢迎关注【睿见新世界】
一、 一次 PR 审查 25 美元,“按量计费”的屠刀挥向工程团队




【笔者观点】 软件行业的计费逻辑正在发生极其残忍的重构。过去,SaaS 模式的本质是“一次买断时间,无限次使用”;而 Claude 的定价策略,正在将代码审查变成一种类似水电煤的“基础设施税”。这背后折射出一个反常识的现实:在 AI 时代,代码生成的边际成本趋近于零,但“验证正确性”的成本却在呈指数级上升。大厂们可能刚刚因为 AI 裁掉了一批程序员省下薪水,转头就得把这笔钱以“API 调用费”的形式如数奉还给大模型公司。
二、 放弃“秒回”,用 20 分钟换取“逻辑级”的排雷
【笔者观点】 毫无波澜的“秒级代码规范检查(Lint)”已经毫无商业价值。Claude 敢于让开发者等 20 分钟,本质上是在用“高昂的算力+时间”去兑换“极低的误报率”。在复杂的工业级项目中,宁可花 20 刀和 20 分钟去排雷,也不愿让一个隐蔽的逻辑 Bug 炸毁生产环境。这也给所有做 AI 研发效能的团队敲响了警钟:开发者对“正确的废话(比如挑剔缩进和命名)”极其厌恶,谁能精准刺穿逻辑层的错误,谁才具备收过路费的资格。
三、 既当裁判又当运动员:AI 闭环下的终极阳谋

【笔者观点】 这才是整盘棋中最令人脊背发凉的商业阳谋。AI 巨头们先是用极高的代码生成产能,撑爆了人类工程团队的审查极限,人为制造出巨大的“技术债务焦虑”和“系统失控恐慌”。当所有人都发现代码合并不进去时,巨头再反手卖给你一个天价的“解药”。看似是给模型的不稳定打补丁,实则是完成了商业变现的完美闭环。未来,不交这笔“代码审查税”的企业,可能连自己系统的底层逻辑是如何崩塌的都无从知晓。
微信搜索 【睿见新世界】 或扫描下方二维码,获取每周硬核技术推文:
我问减肥这种简单的,生成一会就给我重置,都说这个问题不合适。
我无语了,感觉有什么似乎控制着。
好像大家用 imgurl 比较多, imgbox 也挺好用的啊
没有被墙,在微信中打开也不会拦截,速度也还行吧

在深入探讨实时数仓的技术实现后,我们触及了一个更根本的问题:如何构建能随业务弹性伸缩的技术架构?电商系统作为数字商业的基础设施,其架构演进轨迹完美诠释了技术选型与业务增长的共生关系。本文将以业务增长阶段为主线,深入剖析电商系统从单体到微服务的完整演进路径,揭示每个关键决策背后的技术账本与商业逻辑。 电商业务呈现出明显的阶段性增长特征,每个阶段对技术架构的需求有本质差异。据行业数据分析,成功电商企业通常经历三个关键增长阶段: 初创验证期(0-1阶段):核心目标是验证商业模式,需要快速迭代产品功能。此阶段技术投入占营收比可达10%-15%,但绝对金额有限。 规模扩张期(1-10阶段):业务量呈指数级增长,系统压力从功能实现转向性能与稳定性保障。技术投入重点从功能开发转向系统优化。 生态构建期(10-100阶段):业务多元化发展,技术架构需要支持多业务线协同与生态开放。技术投入更加注重长期效益与平台化能力。 每个阶段的架构决策错误都会产生倍数级的修正成本。数据显示,在规模扩张期才进行架构改造的成本,比在早期进行适度超前设计的成本高出3-5倍。 架构演进的根本动力是不断变化的业务需求与现有技术能力之间的差距。当这种差距影响到业务发展时,架构变革就成为必然选择。 架构决策的三维评估模型: 成功的架构演进不是单纯追求技术先进性,而是在适当的时机为适当的业务选择适当的技术。 在业务从0到1的验证阶段,单体架构具有不可替代的成本优势。业界数据表明,超过80% 的成功电商平台初始版本采用单体架构。 初创期单体架构的典型特征: 初创期典型的单体应用结构 技术选型策略: 某新兴电商平台采用Spring Boot单体架构,3人团队在2个月内实现了包含商品展示、下单、支付的核心流程,快速验证了市场可行性。 即使在这一阶段,也需建立架构债务预警机制,避免系统过早腐化。 债务积累的预警信号: 债务控制策略: 某时尚电商在初创期通过严格的模块边界划分,即使代码量增长到10万行,仍能保持较高的开发效率,为后续架构演进奠定了良好基础。 当业务达到一定规模后,单体架构的架构瓶颈开始显现。根据行业经验,当日订单量超过1万单,或开发团队超过15人时,架构升级的需求变得迫切。 规模扩张期的典型挑战: 某中型电商平台在日订单量达到2万单时,单体应用的问题集中爆发:每次大促前需要4小时停机发布,系统平均响应时间从200ms劣化到2000ms,严重影响了业务发展。 微服务转型最危险的误区是一步到位的重写策略。成功的架构演进应采用渐进式拆分,平衡风险与收益。 五阶段拆分路线图: 第一阶段:模块化重构(1-3个月) 通过模块化改造为后续拆分做准备 第二阶段:数据访问层抽象(2-4个月) 第三阶段:核心服务拆分(3-6个月) 拆分出的独立服务配置 第四阶段:服务治理完善(持续进行) 第五阶段:数据彻底分离(6-12个月) 某跨境电商平台采用这一渐进策略,用18个月时间完成了从单体到50+微服务的平稳过渡,期间业务持续增长,未发生因架构转型导致的重大故障。 不是所有模块都适合拆分为微服务。科学的拆分决策需要基于多维度评估: 服务拆分评估矩阵: 得分高于7分的模块优先考虑拆分 某电商平台基于这一框架,优先拆分了用户、商品、搜索等高内聚、高性能要求的服务,而将配置管理、数据字典等低变更功能保留在单体中,实现了拆分效益最大化。 当电商业务进入生态构建期,技术架构的核心目标从支撑内部业务转向赋能生态伙伴。这一转变要求架构具备高度的可扩展性与开放性。 平台化架构的典型特征: 某大型电商平台通过平台化改造,将交易、物流、支付等核心能力开放给10万+ 生态伙伴,年GMV增长300%,其中40% 来自生态伙伴贡献。 中台架构是平台化战略的具体实现,旨在解决重复建设和数据孤岛问题。 电商中台典型结构: 中台化实施路径: 某零售集团通过中台建设,将新业务上线时间从平均3个月缩短到2周,研发效率提升40%,同时保证了各业务线体验的一致性。 在服务规模达到一定数量后,治理复杂度成为新的挑战。需要引入更先进的治理模式。 服务网格架构: 基于服务网格的精细流量管理 治理策略升级: 某电商平台通过引入服务网格,将跨服务调用的故障定位时间从小时级缩短到分钟级,系统可用性从99.9% 提升到99.99%。 架构决策本质上是投资决策,需要全面评估各项成本。 微服务架构的显性成本: 微服务架构的隐性成本: 实证研究表明,微服务架构的初始投入通常比单体架构高50%-100%,但随业务规模增长,边际成本显著降低。 架构投资的价值主要体现在业务赋能和成本节约两个维度。 业务赋能价值: 成本节约价值: 某电商平台在微服务改造后,虽然初期投入增加80%,但第二年即开始显现收益:新功能上线时间缩短60%,资源利用率提升40%,故障处理时间减少70%,第三年即实现投资回报。 科学的架构决策需要建立量化评估框架,避免主观臆断。 架构决策评分卡: 某电商平台在业务早期阶段的架构决策评估 这一框架帮助团队在特定业务背景下,做出数据驱动的架构决策。 常见陷阱:盲目追求技术先进性,过早引入复杂架构。 典型案例:某初创电商在业务初期即采用全微服务架构,8人团队维护20+ 服务,运维复杂度远超团队能力,导致产品迭代缓慢,错过市场窗口。 应对策略: 常见陷阱:忽视康威定律,架构与组织能力不匹配。 典型案例:某电商企业将系统拆分为15个微服务,但团队结构仍为功能型组织,导致跨团队协作成本高昂,交付效率反而下降。 应对策略: 常见陷阱:低估分布式环境下数据一致性的复杂度。 典型案例:某电商平台在微服务拆分后,因分布式事务处理不当,导致超卖和资金不一致问题,造成重大经济损失。 应对策略: 业务背景:从区域性电商向全球跨境电商转型,业务覆盖从3个国家扩展到30+ 国家。 架构挑战:需要支持多货币、多语言、多时区,同时保证系统性能和稳定性。 演进策略: 成果:系统支持日均1000万订单,平均响应时间<200ms,实现了99.99% 的可用性。 业务背景:从传统电商向社交电商转型,业务模式从搜索式购物转向内容驱动购物。 架构挑战:需要支持高并发实时互动,处理海量用户生成内容。 演进策略: 成果:系统支持百万级同时在线,内容发布到可见延迟<1秒,用户互动率提升3倍。 电商架构演进是一场持续的平衡艺术,需要在业务需求、技术能力与团队结构之间找到最佳平衡点。 核心演进原则: 架构决策的心智模型: 未来趋势:随着云原生、Serverless等技术的发展,电商架构正向着更弹性、更智能的方向演进。但无论技术如何变化,架构服务于业务这一基本原则不会改变。 成功的电商架构师既是技术专家,也是商业分析师,能够准确判断每个业务阶段的技术需求,做出最具成本效益的架构决策。这正是电商架构演进的艺术所在。 📚 下篇预告 点击关注,掌握实时数据平台构建的价值评估与方法论! 今日行动建议:技术架构的本质是业务增长的函数,每一个成功的架构演进都是对成本、效率与风险的精妙平衡
1 架构演进的本质:业务增长与技术成本的动态平衡
1.1 电商业务增长的阶段性特征
1.2 架构演进的底层逻辑
2 初创验证期:单体架构的成本优势与陷阱规避
2.1 单体架构的合理性与实施策略
// 典型的电商单体应用结构
ecommerce-monolith/
├── src/
│ ├── main/
│ │ ├── java/
│ │ │ └── com/
│ │ │ └── ecommerce/
│ │ │ ├── user/ # 用户模块
│ │ │ ├── product/ # 商品模块
│ │ │ ├── order/ # 订单模块
│ │ │ ├── payment/ # 支付模块
│ │ │ └── Application.java # 应用入口
│ │ └── resources/
│ │ ├── application.properties
│ │ └── static/
│ └── test/
├── pom.xml
└── Dockerfile2.2 单体架构的债务积累与预警机制
3 规模扩张期:分布式架构的必然选择与实施路径
3.1 规模扩张期的架构挑战
3.2 渐进式拆分策略与实践
// 单体内部的模块化改造
// 在pom.xml中明确模块依赖
<modules>
<module>user-service</module>
<module>product-service</module>
<module>order-service</module>
<module>common-utils</module>
</modules>
// 定义清晰的模块接口
public interface UserService {
UserDTO getUserById(Long userId);
// 其他接口方法
}
优先拆分变更频繁、性能敏感的核心服务,如用户服务、商品服务:# 用户服务独立部署配置
spring:
application:
name: user-service
datasource:
url: jdbc:mysql://localhost:3306/user_db
username: user_svc
password: ${DB_PASSWORD}
# 服务注册与发现配置
eureka:
client:
service-url:
defaultZone: http://eureka-server:8761/eureka/3.3 微服务拆分的决策框架
评估维度 权重 评估标准 得分 业务边界 30% 领域驱动设计中的限界上下文 0-10 变更频率 25% 模块独立变更的需求强度 0-10 性能需求 20% 特殊性能要求(如高并发、低延迟) 0-10 团队结构 15% 与康威定律的匹配度 0-10 技术异构 10% 需要不同技术栈的支持程度 0-10 4 生态构建期:平台化架构的协同效应
4.1 平台化架构的业务价值
4.2 中台战略的落地实践
业务中台:用户中心、商品中心、交易中心、支付中心
数据中台:用户数据平台、商品知识图谱、实时数仓
技术中台:微服务框架、 DevOps平台、容器平台4.3 微服务治理的深度优化
# Istio VirtualService配置示例
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: product-service
spec:
hosts:
- product-service
http:
- match:
- headers:
user-type:
exact: premium
route:
- destination:
host: product-service
subset: v2
- route:
- destination:
host: product-service
subset: v15 技术账本:架构演进的投资回报分析
5.1 架构演进的成本模型
5.2 架构演进的价值评估
5.3 架构决策的量化框架
| 评估维度 | 权重 | 单体架构 | 微服务架构 | 得分 |
|---------|------|---------|-----------|------|
| 开发效率 | 20% | 8/10 | 6/10 | 单体+0.4 |
| 系统性能 | 15% | 5/10 | 9/10 | 微服务+0.6 |
| 运维复杂度 | 15% | 9/10 | 5/10 | 单体+0.6 |
| 可扩展性 | 20% | 4/10 | 9/10 | 微服务+1.0 |
| 技术风险 | 10% | 8/10 | 6/10 | 单体+0.2 |
| 团队适配 | 10% | 9/10 | 5/10 | 单体+0.4 |
| 成本效益 | 10% | 8/10 | 6/10 | 单体+0.2 |
| **总分** | **100%** | **7.0/10** | **6.8/10** | **单体胜出** |6 电商架构演进的常见陷阱与应对策略
6.1 技术导向的过度设计
6.2 团队结构与架构不匹配
6.3 数据一致性的低估
7 成功案例复盘:电商架构演进的最佳实践
7.1 案例一:全球跨境电商的平滑演进
7.2 案例二:社交电商的快速转型
总结
《实时数据平台的价值链——数据采集、加工、存储、查询与消费的协同效应与ROI评估》—— 我们将深入探讨:
开发者朋友们大家好: 这里是 「RTE 开发者日报」 ,每天和大家一起看新闻、聊八卦。我们的社区编辑团队会整理分享 RTE(Real-Time Engagement) 领域内「有话题的技术 」、「有亮点的产品 」、「有思考的文章 」、「有态度的观点 」、「有看点的活动」,但内容仅代表编辑的个人观点,欢迎大家留言、跟帖、讨论。 本期编辑:@koki、@鲍勃 它具备一个现在所有 OpenClaw 产品都没有的「杀手级」功能------直接在微信和龙虾对话,让它帮你干活。但比较遗憾的是,目前 QClaw 还没正式上线。 根据官网信息,它支持 Mac 和 Windows 双端,内置了 Kimi-2.5 模型,内测用户展示的界面显示可默认关联到 Kimi、Minimax、GLM、DeepSeek 等内置模型,还可让用户自定义大模型。 值得关注的是,QClaw 背靠着一个庞大的 Skills 生态,链接了 ClawHub 和 GitHub,拥有超过 5000 种 Skills 储备。另外 QClaw 还拥有「持续记忆」的能力和本地数据保存。 也是同一时间,企业微信官方宣布支持通过 OpenClaw 快速接入并写入数据至智能表格,让 AI 真正成为办公利器。同时,「长连接方式」 不仅支持被动回复,还支持 AI 主动向用户发送消息。 腾讯版龙虾 WorkBuddy 也在昨日正式上线,完全兼容 OpenClaw 的技能,它能接入 QQ、飞书、钉钉等工具。还支持多窗口多 Agent 智能体并行工作、与 CodeBuddy 统一管理后台、账号与计费体系等亮点。 (@APPSO) * SpacetimeDB 2.0 核心逻辑非常暴力:它直接砍掉了传统的 API 中间层,让客户端直连数据库。这款基于 Rust 编写的引擎试图打破「数据库+后端服务器」的传统架构,将两者融合为一个统一体。 这种架构最直观的改变是,所有的逻辑处理和状态变更都会由数据库实时推送到所有关联客户端。开发者在演示中甚至直接用它跑通了视频通话,证明了其在极低延迟下的同步能力。 尽管社区对其「1000 倍加速」的跑分公平性(尤其是协议对比方面)仍有争论,但其在工程上的尝试非常明确:针对多人竞技游戏、协作办公工具以及 AI Agent 之间的高频对话,提供一种无需反复构建后端 CRUD 接口的开发新范式。 GitHub 链接: https://github.com/clockworklabs/SpacetimeDB ( @sitinme@X) * ElevenLabs在 2026 年 SXSW 期间发布了纪录片集《11 Voices》,这是首部由失语症患者利用 AI 重建原声进行旁白叙述的系列短片。 该项目展示了 11 位因渐冻症(ALS)、事故或其他疾病导致永久丧失说话能力的人士,如何通过 ElevenLabs AI 语音克隆技术重新获得属于自己的沟通声音,并应用于教学、表演及家庭生活等真实场景。 该项目技术侧重点在于对语调细节、呼吸感及情感共鸣的参数化模拟,使失语者能够通过文本输入实时驱动 AI 生成具备其原始音色的语音流。 作为 ElevenLabs Impact Program 的核心部分,该计划旨在通过向医疗、教育及文化领域的非营利机构以及有视力或言语障碍的个人免费开放 AI 工具,帮助全球 100 万人重拾声音。 目前,由影星迈克尔·凯恩爵士配音的项目预告片已上线,展示了 AI 技术在身份认同与情感连接中的实际应用案例。 (@elevenlabsio@X) Runway 正式推出 Runway Characters ,这是一套基于其 GWM-1(General World Model)底座的实时视频智能体 API。该工具允许开发者通过单一参考图像,零微调(Zero Fine-tuning)生成具备完整对话表现力的数字分身,旨在将传统的文本交互升级为高保真、低延迟的实时视频流交互。 核心技术规格与集成能力 * API 控制参数: 开发者可利用该 API 将视频智能体无缝集成至产品、网页或 App 中。除了视觉输出,系统支持触发特定的业务逻辑。例如,智能体可根据实时库存引导用户下单、自动创建客户支持工单,或调用企业私有数据回答专业咨询。目前,BBC 及 Silverside 已接入该套件用于内容制作与交互开发。 ( @runwayml@X) 昨日,钉钉发布旗下 AI 硬件 DingTalk A1 在医疗行业的垂直化版本。 官方表示,DingTalk A1 医生版也是 AI 硬件在医疗临床问诊及决策领域的重要落地。 据悉,DingTalk A1 医生版与壹生检康豆蔻妇科大模型深度融合,能够为医生提供从语音记录、信息整理到医学知识检索与临床决策支持的全流程 AI 辅助,助力医生群体进入 AI 时代的工作方式。 DingTalk A1 是钉钉在 2025 年推出的首款 AI 硬件。这款仅 3.8mm 厚度的「AI 录音卡片」,搭载 6 麦克风阵列,具备远场拾音能力,支持最长 45 小时连续录音,可以实现 AI 语音转写、会议纪要生成,同声传译及 AI 助理等功能。 另外,豆蔻医疗大模型目前已经在全国近千家医疗机构中落地应用,为众多妇产科医生提供 AI 文献分析报告并提示鉴别诊断方向。 ( @APPSO) * 全国人大代表、格力电器董事长董明珠在接受采访时,回答了自己对于年轻一代的看法。 董明珠说,「不同的时代都有不同时代的年轻,有不同的快乐和烦恼。我觉得我们年轻人要有一种更好的心态去面对自己的现状,积极向上的心态去解决问题。现在的年轻人都很努力,根本不需要我们讲,他们自己就会知道自己应该做什么。」 对于「有年轻人担心被 AI 替代」这一话题,董明珠则表示,「我那么大年纪都不怕被 AI 替代,你们年轻人怕什么?只能通过学习,做到比 AI 聪明!」 * 据她透露,自己已熟练使用 AI 正常处理工作。在 2025 年中国品牌节上,董明珠还曾提及传统产业与 AI 技术的共生关系。其认为,数字化时代的 AI 技术需要嫁接在传统产业中,两者需要完美结合;而对于传统制造业来说,更要不断地创新和提高自身的水平。 (@APPSO) * 招聘、项目分享、求助......任何你想和社区分享的信息,请联系我们投稿。(加微信 creators2022,备注「社区黑板报」) 湾区硅谷的开发者和创业者们,3 月 19 日见! GTC 期间,来一场动脑又动手的 Physical AI 全天候嘉年华!同一场地,两场硬核活动无缝衔接: 🌅 上午 09:30|Meetup:对话真实世界 Agora | RiseLink | MiniMax | HumanTouch | EverMind | Resonance Ventures 等大咖齐聚,拆解全模态与端侧智能的机会与未来。 🛠 下午 13:30|Workshop:手搓语音 AI 硬件 基于 TEN 框架,实操接通语音 AI Agent。重点来了👉现场备有 40 套 Agora R1 开发板,代码跑通直接把硬件带回家! 上下午活动需分开独立报名,名额有限,拼手速: 上午 Meetup 报名: 下午 Workshop 报名: 地点:Sunnyvale (审核后发具体定位) * 阅读更多 Voice Agent 学习笔记:了解最懂 AI 语音的头脑都在思考什么 写在最后: 我们欢迎更多的小伙伴参与**「RTE 开发者日报」**内容的共创,感兴趣的朋友请通过开发者社区或公众号留言联系,记得报暗号「共创」。 对于任何反馈(包括但不限于内容上、形式上)我们不胜感激、并有小惊喜回馈,例如你希望从日报中看到哪些内容;自己推荐的信源、项目、话题、活动等;或者列举几个你喜欢看、平时常看的内容渠道;内容排版或呈现形式上有哪些可以改进的地方等。 作者提示:个人观点,仅供参考
01 有话题的技术
1、腾讯上线旗下三款龙虾 AI



2、SpacetimeDB 2.0:融合数据库与服务器架构的 Rust 实时数据同步引擎

02 有亮点的产品
1、ElevenLabs 将在 SXSW 首映 AI 语音纪录片《11 Voices》,聚焦于用科技帮助失声者重获新声
2、Runway 推出 Characters:可定制的实时智能数字人
3、钉钉发布 DingTalk A1 医生版

03 有态度的观点
1、董明珠:我都不怕被 AI 替代,年轻人怕什么?

04 社区黑板报
1、Physical AI 系列活动硅谷站!探讨和上手全模态与硬件智能丨 Meetup+Workshop,3 月 19 日


2、3.14 北京丨养虾社 国内虾人浓度最高的OpenClaw Weekly Meetup预告来了!




哪位大善人分享一个 v2ex 的邀请码,一直没注册看帖,还是不方便,求好心人分享个码MTY4MzUxNDMwQHFxLmNvbQ==
,我 linuxdo 现在 3 级也能邀请你,
不想咸鱼买
假设你有一个电商团队,需求如下: 这 3 个群 @ 同一个飞书 Bot,但各群收到的回复风格和能力完全不同。 OpenClaw 的多 Agent 机制就是为这种场景设计的:不同 Workspace → 不同人格和技能 → 通过 bindings 路由到不同群。下面一步步配。 每个 Agent 有自己的 Workspace,彼此隔离。Workspace 下的 销售助手: 售后客服: 运营助手: Skill 是 Markdown 格式的能力描述,放在 销售助手的数据查询 Skill: curl -s -H "Authorization: Bearer $SHOP_TOKEN" \ }' curl -s -H "Authorization: Bearer $SHOP_TOKEN" \ }' 运营助手的库存预警 Skill: curl -s -H "Authorization: Bearer $SHOP_TOKEN" \ }' 这是路由的关键——定义 Agent 列表、群到 Agent 的映射、飞书渠道: 几个关键设计: 飞书群 ID 在哪找?群设置 → 群信息 → 群 ID( OpenClaw 用出站 WebSocket 连飞书——不需要公网 IP,不需要配 Webhook。 ⚠️ 顺序很重要: 先启动 OpenClaw(WebSocket 连上),再去飞书开放平台配事件订阅。反过来会报连接失败。 飞书开放平台 → 事件与回调 → 添加事件 → 订阅 把 Bot 分别拉进 3 个群,在销售群 @ Bot: 如果配置正确,销售群收到数据分析风格的回复,售后群收到客服风格的回复——底层是同一个进程。 运营助手不能只被动回答,还要主动推消息。在 每天 9 点自动推日报,每 4 小时扫一次库存。 如果你是电商平台方,要给每个卖家提供 AI 助手,可以用 一商户一容器 的方式: 用 Amazon ECS 或 EKS 编排,CloudFormation 模板化部署。所有容器共享 Bedrock 后端(按量计费),数据通过独立 Workspace 天然隔离。 好处是隔离性强——一家出问题不影响其他家。AI Agent 场景主要消耗模型调用而非 CPU/内存,资源利用率的损失可以接受。 没有写后端代码。人格是 Markdown,技能是 Markdown,路由是 JSON。配置驱动,不是开发驱动——这是 OpenClaw 做多 Agent 和传统 Function Calling 方案的根本区别。 本文是「OpenClaw 云端实战」系列第 4 篇。 你的团队有类似的多角色 AI 需求吗?配置过程有什么问题直接评论区问,手把手帮你排查 🔧同一个进程跑 3 个 AI Agent,按飞书群自动路由——OpenClaw 多角色配置实战
电商团队通常不止一个群:销售群聊业绩、售后群处理工单、运营群盯库存。如果每个群想配一个专属 AI 助手,开 3 台服务器太浪费。这篇文章演示怎么在同一个 OpenClaw(🦞)实例里配 3 个不同人格、不同技能的 Agent,按飞书群 ID 自动路由,用户感知是 3 个独立助手,底层是 1 个进程。
场景和目标
群 需要什么样的 AI 核心能力 销售讨论群 热情、数据驱动 查销售额、分析订单趋势、监控退货率 售后工单群 耐心、严谨 处理退款、查工单状态、分类客诉 运营日报群 简洁、效率至上 库存预警、补货建议、自动日报 Step 1:建 Workspace 目录
SOUL.md 定义人格,skills/ 目录定义能力。mkdir -p /data/workspace-sales/skills
mkdir -p /data/workspace-support/skills
mkdir -p /data/workspace-ops/skills写人格文件
cat > /data/workspace-sales/SOUL.md << 'EOF'
# 销售助手
你是电商团队的销售数据分析助手。
## 风格
- 先给数据再给分析,用百分比和趋势说话
- 主动发现异常:"华东区退货率比上周高了 3 个点"
## 不做
- 不处理售后和退款
- 不编造数字,数据来自平台 API
EOFcat > /data/workspace-support/SOUL.md << 'EOF'
# 售后客服
你是电商团队的售后处理助手。
## 风格
- 先确认问题再给方案
- 涉及退款给明确金额和操作步骤
## 不做
- 不回答销售数据
- 超授权金额提醒找主管
EOFcat > /data/workspace-ops/SOUL.md << 'EOF'
# 运营助手
你是电商团队的运营监控助手。
## 风格
- 能用数字就不用文字
- 预警信息标粗
- 主动推送关键信息
## 不做
- 不处理销售分析和售后
EOFStep 2:写 Skill 文件
skills/ 目录下,OpenClaw 自动加载到对应 Agent 的 System Prompt。cat > /data/workspace-sales/skills/sales-query/SKILL.md << 'EOF'
# 销售数据查询
## 什么时候用
用户问销售额、订单量、退货率、GMV、客单价、转化率
## 怎么做
### 查今日概况
"$SHOP_API/v1/orders/stats?date=$(date +%Y-%m-%d)" | jq '{total_orders: .data.order_count,
total_amount: (.data.total_amount / 100 | tostring + " 元"),
avg_price: (.data.avg_amount / 100 | tostring + " 元"),
return_rate: (.data.return_rate | tostring + "%")
### 查日期范围趋势
"$SHOP_API/v1/orders/trend?start=$START&end=$END" | jq '.data[] | {date: .date,
orders: .order_count,
amount: (.total_amount / 100)
## 输出要求
- 先报数字,再给环比
- 退货率 > 5% 主动标出
EOFcat > /data/workspace-ops/skills/inventory-alert/SKILL.md << 'EOF'
# 库存预警
## 什么时候用
用户问库存,或定时任务触发
## 怎么做
"$SHOP_API/v1/inventory/alerts" | jq '.data[] | select(.stock < .safety_stock) | {sku_id: .sku_id,
name: .product_name,
current: .stock,
safety_line: .safety_stock,
gap: (.safety_stock - .stock)
## 输出要求
- 按缺口大小排序
- 缺口超安全库存 50% 标"紧急"
- 补货建议 = 安全库存 × 2 - 当前库存
EOFStep 3:核心配置 openclaw.json
{
"ai": {
"provider": "amazon-bedrock",
"model": "us.anthropic.claude-sonnet-4-6",
"auth": "aws-sdk"
},
"agents": {
"list": [
{
"id": "sales",
"name": "销售助手",
"workspace": "/data/workspace-sales"
},
{
"id": "support",
"name": "售后客服",
"workspace": "/data/workspace-support"
},
{
"id": "ops",
"name": "运营助手",
"workspace": "/data/workspace-ops"
}
]
},
"bindings": [
{
"match": {
"channel": "feishu",
"peer": { "kind": "group", "id": "oc_sales_group_id" }
},
"agentId": "sales"
},
{
"match": {
"channel": "feishu",
"peer": { "kind": "group", "id": "oc_support_group_id" }
},
"agentId": "support"
},
{
"match": {
"channel": "feishu",
"peer": { "kind": "group", "id": "oc_ops_group_id" }
},
"agentId": "ops"
}
],
"channels": {
"feishu": {
"enabled": true,
"accounts": [{
"appId": "cli_your_app_id",
"appSecret": "your_app_secret"
}],
"dmPolicy": "open",
"groupPolicy": "open",
"requireMention": true
}
},
"session": {
"dmScope": "per-peer"
}
}bindings:飞书群 ID → Agent ID 的映射规则,消息进来自动路由requireMention: true:群里必须 @ Bot 才回,避免刷屏dmScope: per-peer:同群不同人的对话自动隔离oc_ 开头)。Step 4:接入飞书
创建飞书应用
im:message、im:message:send_as_bot、im:chat:readonly启动并验证
openclaw gateway start
# 确认飞书连上了
tail -f ~/.openclaw/logs/gateway.log | grep feishu
# 期望看到:[feishu] WebSocket connected to wss://open.feishu.cn/...im.message.receive_v1 → 发布版本。拉 Bot 进群测试
@销售助手 今天卖了多少?Step 5:定时推送
openclaw.json 加 cron:{
"cron": {
"jobs": [
{
"id": "morning-report",
"schedule": "0 9 * * *",
"agentId": "ops",
"task": "生成昨日运营日报:销售额、订单量、退货率、低库存清单,推送运营群",
"channel": "feishu",
"target": "group:oc_ops_group_id"
},
{
"id": "stock-check",
"schedule": "every 4h",
"agentId": "ops",
"task": "检查库存,低于安全线的 SKU 立即推预警",
"channel": "feishu",
"target": "group:oc_ops_group_id"
}
]
}
}进阶思路:SaaS 化多租户
# docker-compose 示例
version: '3'
services:
openclaw:
image: openclaw/openclaw:latest
environment:
- SELLER_ID=${SELLER_ID}
volumes:
- ./workspace-${SELLER_ID}:/data/workspace
restart: always
mem_limit: 512m总结:改了哪些文件
新增:
/data/workspace-sales/SOUL.md
/data/workspace-sales/skills/sales-query/SKILL.md
/data/workspace-support/SOUL.md
/data/workspace-support/skills/ticket-handler/SKILL.md
/data/workspace-ops/SOUL.md
/data/workspace-ops/skills/inventory-alert/SKILL.md
修改:
openclaw.json ← 加了 agents.list + bindings + cron📖 完整架构设计参考:亚马逊云科技官方博客深度解析
参考链接
今天突发奇想在工作的空档拿 cursor 挂在后台 vibe 了一个纯 iOS 手机端的小龙虾,现在已经初步可用了。想知道有没有人感兴趣,要不要继续搞?
目前集成了 简易 memory 、agent/sub-agent 交互、简易 cron 机制 和 MicroPython 运行时,看上去最大众的 openclaw 用法都能玩。
最大摄氧量 VO₂Max 只支持 14–65 ml/kg/min 的范围,一旦超过 65 ,数据就不会变了
其他部署教程都在讲怎么在 Linux 服务器上跑 OpenClaw。但有些能力,只有 macOS 才能给: 这不是"Linux 也能勉强做"的事——这些是 macOS 独占能力。而亚马逊云科技的 EC2 Mac 实例是云上运行真 macOS 的方案:Apple Silicon 硬件 + 完整 macOS 系统 + 云端 24/7 在线。 亚马逊云科技提供了开源的 OpenClaw Mac 部署模板,一个链接搞定所有基础设施。 点击下方链接,直接跳转到 CloudFormation 创建页面: 你只需要填两项: 其余全部由模板自动创建:Dedicated Host、EC2 Mac 实例、IAM 角色(含 Bedrock 权限)、安全组、EBS 存储。 Mac 实例启动比 Linux 慢(要分配 Dedicated Host + 初始化 macOS),耐心等 CloudFormation 状态变成 完成后打开 Outputs 标签页,记下: CloudFormation Outputs 里有 OpenClaw Web UI 的连接方法。通常是通过 SSM 端口转发: 然后浏览器打开 这是 Mac 实例的杀手级功能——不需要任何第三方桥接,直接用 macOS 原生的 Messages.app。 先建立 Screen Sharing 连接,才能操作 GUI: 在本地 Mac 建立端口转发(新开一个终端窗口): 连接 Screen Sharing: 输入用户名和密码,你就能看到远程 Mac 的桌面了。 在远程桌面上: 激活成功后,你会看到对话列表和蓝色发送按钮。 编辑 OpenClaw 需要读取 Messages 数据库,必须授权: 点击 用另一台设备(iPhone、iPad)给这个 Apple ID 发一条 iMessage。OpenClaw 会回复一个配对码: 在 Mac 终端确认配对: 完成!现在 OpenClaw 就是你的 iMessage 助手了。🎉 接入 iMessage 只是起点。在 macOS 云实例上,OpenClaw 还能: OpenClaw 能截屏识别界面元素,像真人一样操作任何 Mac 应用: 构建失败时 OpenClaw 自动通过 iMessage 通知团队,附上错误日志摘要。 macOS Shortcuts 可以串联多个 App 的操作,OpenClaw 可以触发和管理这些工作流: Mac 实例结合了 macOS 原生安全 + 亚马逊云科技企业级防护: 关键点:不需要开放任何公网端口。所有远程访问通过 SSM Session Manager,走亚马逊云科技内网通道,安全且可审计。 Q:Mac 实例可以随时停止吗? Q:支持哪些 macOS 版本? Q:iMessage 登录后需要手机验证吗? Q:可以同时接入 iMessage 和 Slack/飞书吗? Q:Windows 用户怎么连远程桌面? Mac 云实例让 OpenClaw 拥有了苹果生态的全部能力。后续文章会讲: 关注亚马逊云开发者账号获取更新。 本文是「OpenClaw 云上实战指南」系列第 2 篇。OpenClaw 接入 iMessage 教程:Mac 云实例部署 + 苹果生态自动化完整配置
OpenClaw(社区昵称"龙虾"🦞)不只是能聊天——当你把它部署在一台真正的 macOS 云服务器上,它就变成了你的"云端 Mac 秘书":能发 iMessage、操作 Finder、跑 AppleScript、甚至帮你处理邮件。本文是「OpenClaw 云上实战指南」系列第 2 篇,教你用亚马逊云科技 Mac 实例实现这件别的平台做不到的事。
这篇文章讲什么?
你需要什么
⚠️ 重要:Mac 实例基于 Dedicated Host(专用主机),有 24 小时最低租用期。启动后至少运行 24 小时才能释放。适合长期运行的助手场景,不适合"跑 5 分钟试试"。
方案选择
CloudFormation 一键部署 手动部署 适合谁 快速体验、不想折腾 想深入理解每一步 耗时 ~20 分钟(等待自动创建) ~40 分钟 灵活度 固定配置 完全自定义 本文重点 ✅ 简要说明 一键部署:CloudFormation 模板(推荐)
第 1 步:启动 CloudFormation 栈
参数 说明 Key Pair 你的 EC2 密钥对(没有就先在 EC2 控制台创建一个) Availability Zone 可用区( us-west-2a 或 us-west-2b,看哪个有 Mac 主机)📖 模板源码:aws-samples/sample-Moltbot-on-AWS-with-Bedrock
第 2 步:等待 15-20 分钟
CREATE_COMPLETE。i-xxxxxxxxxxxx)第 3 步:连接到 Web UI
# 在本地终端运行(保持窗口不关)
aws ssm start-session \
--target i-xxxxxxxxxxxx \
--region us-west-2 \
--document-name AWS-StartPortForwardingSession \
--parameters '{"portNumber":["18789"],"localPortNumber":["18789"]}'http://localhost:18789 即可进入 OpenClaw 控制台。配置 iMessage:让 OpenClaw 收发蓝泡泡
第 1 步:连接远程桌面
# 通过 SSM 连接到实例
aws ssm start-session --target i-xxxxxxxxxxxx --region us-west-2
# 在远程 Mac 上启用 Screen Sharing
sudo launchctl load -w /System/Library/LaunchDaemons/com.apple.screensharing.plist
# 设置登录密码
sudo dscl . -passwd /Users/$(whoami) "你的密码"aws ssm start-session \
--target i-xxxxxxxxxxxx \
--region us-west-2 \
--document-name AWS-StartPortForwardingSession \
--parameters '{"portNumber":["5900"],"localPortNumber":["15900"]}'open -a "Screen Sharing" vnc://localhost:15900💡 没有 Mac?用任何 VNC 客户端连接
localhost:15900 也行。不过操作 iMessage 需要看到 GUI,所以远程桌面是必须的。第 2 步:登录 Apple ID
第 3 步:安装 imsg CLI
imsg 是一个轻量工具,让 OpenClaw 能通过命令行读写 iMessage:brew install steipete/tap/imsg
which imsg
# 输出: /opt/homebrew/bin/imsg第 4 步:配置 OpenClaw 接入 iMessage
~/.openclaw/openclaw.json,添加 channels 配置(合并,不要覆盖整个文件):{
"channels": {
"imessage": {
"enabled": true,
"cliPath": "/opt/homebrew/bin/imsg",
"dbPath": "/Users/ec2-user/Library/Messages/chat.db",
"dmPolicy": "pairing"
}
}
}字段 说明 cliPathwhich imsg 返回的路径dbPathMessages 数据库路径,用户名通常是 ec2-userdmPolicypairing 表示新用户需要配对码才能和 OpenClaw 对话第 5 步:授权 Full Disk Access
+,用 Cmd+Shift+G 输入路径,分别添加:/System/Applications/Utilities/Terminal.app/opt/homebrew/bin/imsg/Users/ec2-user/.nvm/versions/node/v22.22.0/bin/node(Node 通常已在列表中,确认开关打开)第 6 步:重启 & 测试
openclaw gateway restart从另一台设备发送: "你好"
OpenClaw 回复: "配对码: XXXX,在控制台输入以下命令完成配对"openclaw pairing approve imessage XXXXMac 实例能做什么?(不只是 iMessage)
📧 自动处理邮件
-- OpenClaw 通过 AppleScript 操作 Mail.app
tell application "Mail"
set unreadMessages to every message of inbox whose read status is false
repeat with msg in unreadMessages
-- 检查发件人、标记重要邮件、自动归档
end repeat
end tell📋 GUI 自动化(截屏 + OCR)
🔨 iOS CI/CD
# OpenClaw 执行 Xcode 构建
xcodebuild -workspace MyApp.xcworkspace \
-scheme MyApp \
-destination 'platform=iOS Simulator,name=iPhone 16' \
test🔄 Shortcuts 工作流
安全架构
安全层 macOS 原生 云端增强 系统保护 SIP(系统完整性保护) Nitro System 硬件隔离 应用验证 Gatekeeper + XProtect IAM 角色权限控制 磁盘加密 FileVault EBS 卷加密 密码管理 Keychain Secrets Manager 网络隔离 — VPC 私有网络 远程访问 Screen Sharing SSM(零公网端口) 审计 系统日志 CloudTrail + CloudWatch 常见问题
A:可以停止,但 Dedicated Host 有 24 小时最低租期。实例停止后 Host 仍计费,直到满 24 小时后释放 Host。
A:当前 us-east-1 区域支持 macOS 14 (Sonoma)、macOS 15 (Sequoia) 和 macOS 26 (Tahoe),均为 ARM 架构。最新可用 AMI 为 2026 年 2 月更新。
A:首次登录 Apple ID 时需要双重认证(2FA),用你的 iPhone 或其他已登录设备确认。之后不需要重复验证。
A:可以。OpenClaw 支持多渠道并行,在 openclaw.json 的 channels 里分别配置即可。
A:安装任何 VNC 客户端(如 RealVNC Viewer),连接 localhost:15900(需要先建立 SSM 端口转发)。下一步
参考链接
作者:亚马逊云开发者 | 部署步骤基于官方博客实测验证
我在 Mac 上跑了两周龙虾(OpenClaw 🦞),合盖断了 3 次之后决定搬到云上。 头一次断是周五下班,合上 MacBook 就走了——周末两天 Slack 消息没人回、RSS 抓取全停了、cron 任务挂了一地。第二次是出门开会,4G 热点一断龙虾直接掉线。第三次更离谱:macOS 系统更新自动重启,我回来一看 三次之后我不想再赌了。合盖断线这事在本地部署是个无解的结构性问题——你不可能要求笔记本永远开着不动。 刚好第 1 篇讲过 Lightsail 一键部署、第 3 篇讲过龙虾自动开 EC2——云端实例不存在"合盖"这个概念,启动之后就一直跑着。搬家本身不难,但坑全藏在迁移过程里。 这篇文章记录我从本地 Mac 迁到亚马逊云科技 EC2 实例的完整过程,包括迁移清单、实际命令、4 个踩过的坑和解法,以及搬完之后的真实体感对比。如果你也受够了笔记本合盖断线,这篇能帮你少走弯路。 先搞清楚龙虾的"家当"有哪些。在本地 Mac 上跑一下 一共 5 类东西需要考虑: 其中 云端实例我已经按第 1 篇的方案 B 开好了——一台 看看包有多大: 跑了两周,4MB 多——主要是 session 历史。 输出: 别直接启动——配置文件还是本地版本的,直接跑会炸。改什么见下面的坑 1。 这是我踩的头号坑。本地 Mac 上用的是 Anthropic 官方 API Key,配置长这样: 搬到 EC2 后要换成 Bedrock + IAM,不需要任何密钥(第 1 篇详细讲过原理): 用 三行改动,API Key 直接删掉。EC2 实例通过 IAM 角色自动获取临时凭证,不需要配置文件里写任何密钥。 验证方法: 看到 把 检查 session 文件: 问题在 修复:批量替换路径 验证: 重启 gateway,龙虾恢复记忆——之前的对话上下文全回来了。 踩坑教训:迁移完启动前,养成习惯先 本地 Mac 时区是 搬到 EC2 后没改,结果——凌晨 1 点(UTC 9:00 = 北京时间 17:00?不对,UTC 9:00 = 北京 17:00)。 等等,我之前设的是"本地 9:00",本地是 UTC+8,所以实际是 UTC 1:00。到了 EC2 上系统时区是 UTC,cron 读的是 UTC 时间, 总之时间全乱了。 解法:统一用 UTC 思维 转换速查表(北京时间 → UTC cron 表达式): 或者直接让龙虾帮你算——在 Slack 里跟它说"帮我把所有 cron 任务从北京时间转成 UTC",它会自动改 Slack 和 Telegram 的 bot token 是跟着 bot 走的,不绑定特定 IP 或机器。所以 token 搬过去理论上直接能用——但 webhook URL 是绑 IP 的,换了机器就得更新。 如果你用的是 Socket Mode(推荐),连接方式是 outbound websocket,不需要 webhook URL,token 搬过去就能用: 启动后确认连接: Telegram bot 默认用 webhook,URL 绑定了旧机器的地址。搬到新 IP 后需要更新: 如果嫌每次换 IP 都要改 webhook,可以改用 long polling 模式——在 跑了一周之后回头看,差距一目了然: 体感上变化很大的一点:以前用龙虾像用一个"桌面软件",打开才有,关了就没了。搬到云上之后它变成了一个"一直在线的同事"——你不需要主动想着去用它,它自己会在后台帮你抓新闻、处理消息、跑定时任务。 那三次合盖断线的日子一去不复返了。 如果你现在还在本地跑龙虾,而且只是偶尔用用,本地完全够了——不需要为了"上云"而上云。 但如果你已经开始依赖它(配了 cron 任务、接了 Slack 渠道、让它帮你监控 RSS),那迁移到云上是早晚的事。与其等下次合盖断线的时候着急,不如现在花 40 分钟搬完。 从这个系列五篇文章走下来,一只龙虾从"试试看"变成了"离不开":第 1 篇解决了部署和安全问题,第 2 篇打通了苹果生态,第 3 篇实现了全自动扩展,第 4 篇探索了多模型协作,这第 5 篇解决了"搬家"的临门一脚。 五篇看完,你手上应该已经有一只跑在云端、24/7 在线、零密钥、能自己干活的龙虾了。剩下的事——就交给它吧。 怕你上面看散了,这里把所有命令串一遍: 搬家本身不难——4 条命令传文件,改 3 处配置——难的是那几个不看日志根本发现不了的坑。踩完之后回头看,早搬早省心。 📖 系列回顾: 🔗 延伸阅读:《把 AI Agent 部署到云端,是值得做的事》 — 亚马逊云科技官方博客 OpenClaw 是开源项目,欢迎参与社区贡献。本系列所有代码和配置均在 GitHub 上公开。从本地到云:一个 OpenClaw 玩家的迁移踩坑实录
本文是「OpenClaw 云上实战指南」系列第 5 篇(完结篇)
openclaw gateway 进程没了,session 文件还锁着。搬什么?迁移清单
tree,看看 ~/.openclaw 目录结构:~/.openclaw/
├── openclaw.json # 核心配置(模型、渠道、心跳)
├── workspace/ # 工作区(SOUL.md、skills/、memory/ 等)
│ ├── SOUL.md
│ ├── USER.md
│ ├── MEMORY.md
│ ├── memory/
│ │ ├── 2026-02-25.md
│ │ ├── 2026-02-26.md
│ │ └── ...
│ ├── skills/
│ │ ├── content-watcher/
│ │ └── rss-ai-reader/
│ └── articles/
├── sessions/ # 聊天历史
├── .secrets/ # 本地密钥(迁移后用 IAM 替代)
└── crontab.json # 定时任务文件/目录 重要程度 说明 openclaw.json必须搬 核心配置,但到云上要改(见坑 1) workspace/必须搬 龙虾的"灵魂"——人格、记忆、技能全在这里 sessions/建议搬 聊天历史,丢了不影响功能但龙虾会"失忆" .secrets/不要搬 本地密钥文件,到了云上用 IAM 角色替代,更安全 crontab.json必须搬 定时任务配置,但时区需要调整(见坑 3) workspace/ 是重中之重。里面的 SOUL.md 定义了龙虾的性格,memory/ 存着它的日常记忆,skills/ 是你装的各种能力插件。这些丢了龙虾就不是"你的龙虾"了——它虽然还能跑,但会变成一只陌生的新龙虾。动手搬家:4 条命令
t4g.medium ARM 实例,挂了 IAM 角色,Bedrock 权限就位。1. 打包本地文件
# 本地 Mac 上执行
cd ~/.openclaw
tar czf ~/openclaw-backup.tar.gz \
openclaw.json \
workspace/ \
sessions/ \
crontab.json$ ls -lh ~/openclaw-backup.tar.gz
-rw-r--r-- 1 bill staff 4.2M 3 8 14:32 openclaw-backup.tar.gz2. 传到云端
# rsync 增量传输,比 scp 断点续传更靠谱
rsync -avzP ~/openclaw-backup.tar.gz \
ubuntu@<EC2-IP>:~/sending incremental file list
openclaw-backup.tar.gz
4,398,080 100% 12.35MB/s 0:00:00 (xfr#1, to-chk=0/1)3. 云端解压
# SSH 到 EC2
ssh ubuntu@<EC2-IP>
# 解压到 ~/.openclaw
mkdir -p ~/.openclaw
cd ~/.openclaw
tar xzf ~/openclaw-backup.tar.gz4. 启动前先改配置
坑 1:API Key → IAM 角色——配置文件要改
// 本地版 openclaw.json
{
"llm": {
"provider": "anthropic",
"model": "claude-sonnet-4-20250514",
"apiKey": "sk-ant-api03-xxxxxxxxxxxxx"
}
}// 云端版 openclaw.json
{
"llm": {
"provider": "amazon-bedrock",
"model": "anthropic.claude-sonnet-4-20250514",
"region": "us-east-1"
}
}diff 看一下改了什么: {
"llm": {
- "provider": "anthropic",
- "model": "claude-sonnet-4-20250514",
- "apiKey": "sk-ant-api03-xxxxxxxxxxxxx"
+ "provider": "amazon-bedrock",
+ "model": "anthropic.claude-sonnet-4-20250514",
+ "region": "us-east-1"
}
}# 确认 IAM 角色已绑定
$ curl -s http://169.254.169.254/latest/meta-data/iam/security-credentials/
OpenClawBedrockRole
# 确认 Bedrock 可调用
$ aws bedrock-runtime invoke-model \
--model-id anthropic.claude-sonnet-4-20250514 \
--region us-east-1 \
--body '{"anthropic_version":"bedrock-2023-05-31","max_tokens":10,"messages":[{"role":"user","content":"ping"}]}' \
/dev/stdout 2>/dev/null | jq -r '.content[0].text'
Pong!Pong! 就说明模型调用链路通了。整个过程不需要管密钥轮换、不需要担心 Key 泄露——IAM 角色的临时凭证由亚马逊云科技自动管理,每小时刷新一次。💡 如果之前本地用的是其他模型(比如 OpenAI),Bedrock 上也有 Claude、Nova、DeepSeek 等多种选择,改
model 字段就行。第 4 篇会详细讲 Nova 模型的切换实战。具体支持列表见 Bedrock 模型页面。坑 2:Session 历史路径变了——龙虾"失忆"
sessions/ 目录搬过去之后,启动龙虾,发现它完全不记得之前的对话。$ ls sessions/
main.json slack-C07XXXXXX.json telegram-123456789.json
$ head -5 sessions/main.json
{
"id": "main",
"createdAt": "2026-02-22T06:30:00.000Z",
"homedir": "/Users/bill/.openclaw",
"messages": [homedir 字段——还指向 /Users/bill/.openclaw(macOS 路径),但云端是 /home/ubuntu/.openclaw。OpenClaw 用这个路径解析 workspace 里的相对引用。# 一行搞定
cd ~/.openclaw/sessions
sed -i 's|/Users/bill/.openclaw|/home/ubuntu/.openclaw|g' *.json$ grep homedir main.json
"homedir": "/home/ubuntu/.openclaw",$ openclaw gateway restart
Gateway restarted. Sessions loaded: 3grep 一遍旧路径,确认没有残留:$ grep -r '/Users/' ~/.openclaw/sessions/ | wc -l
0 # 确认没有残留的 macOS 路径⚠️ 如果你的 session 文件特别大(几十 MB),也可以选择不迁移——龙虾会从
MEMORY.md 和 memory/ 目录重建上下文。丢的是逐条对话记录,不是"人格"。人格在 SOUL.md,记忆在 memory/,这些都在 workspace 里。坑 3:定时任务时区差 8 小时——凌晨 3 点推送日报
Asia/Shanghai(UTC+8),我设了一个每天早上 9 点抓 RSS 并推送摘要的 cron:// crontab.json(本地版)
{
"jobs": [
{
"name": "daily-rss-digest",
"schedule": "0 9 * * *",
"task": "抓取 RSS 订阅,生成今日摘要,推送到 Slack"
}
]
}0 9 * * * 就变成了 UTC 9:00 = 北京 17:00。// crontab.json(云端版,UTC 时间)
{
"jobs": [
{
"name": "daily-rss-digest",
"schedule": "0 1 * * *",
"task": "抓取 RSS 订阅,生成今日摘要,推送到 Slack"
}
]
}0 1 * * * = UTC 01:00 = 北京时间 09:00。搬家时脑子里要装一个公式:北京时间减 8 小时 = UTC 时间。你想要的北京时间 cron 里写的 UTC 08:00 0 0 * 09:00 0 1 * 12:00 0 4 * 18:00 0 10 * 22:00 0 14 * crontab.json 里的时间字段。毕竟这种机械换算的活交给 AI 来做正合适。💡 你也可以在 EC2 上改系统时区(
timedatectl set-timezone Asia/Shanghai),但不建议——云上统一用 UTC 是业界惯例,避免和 CloudWatch、CloudTrail 等服务的日志时间对不上。日志排查的时候时区不统一会让人抓狂。坑 4:渠道重连——Token 能用但 Webhook 要换
Slack(Socket Mode)
// openclaw.json — Slack 配置,直接搬
{
"channels": {
"slack": {
"enabled": true,
"appToken": "xapp-1-A07XXXXXX-...",
"botToken": "xoxb-..."
}
}
}$ openclaw gateway start
...
[Slack] Connected via Socket Mode ✓
[Slack] Listening on 2 channelsTelegram(Webhook Mode)
# 更新 webhook 到新 IP
curl -s "https://api.telegram.org/bot<TOKEN>/setWebhook?url=https://<NEW-EC2-IP>:8443/telegram/webhook"
# 验证
curl -s "https://api.telegram.org/bot<TOKEN>/getWebhookInfo" | jq '.result.url'
"https://<NEW-EC2-IP>:8443/telegram/webhook"openclaw.json 里把 webhook 去掉,龙虾会自动降级到 polling:{
"channels": {
"telegram": {
"enabled": true,
"botToken": "7000000000:AAxxxxxx"
// 不配 webhook,自动用 long polling
}
}
}💡 第 2 篇里的 iMessage 渠道比较特殊——它依赖 macOS 系统,如果你从 Mac 迁到 Linux,iMessage 渠道需要单独保留在 Mac 实例上。可以参考第 2 篇的 Mac 云实例方案。
搬家前后对比
维度 本地 Mac EC2 云端 在线时长 取决于开机时间,平均每天不到 12 小时 7×24 不间断运行 断线次数(一周) 3 次(合盖、断网、重启) 0 次 API 密钥管理 明文写在配置文件里 IAM 角色自动管理,零密钥 cron 定时任务 合盖就停,醒来不一定恢复 准时执行,从未漏过 Slack 消息响应 人在电脑前才有反应 凌晨 3 点消息也能秒回 RSS 抓取推送 出差那几天漏了 3 天内容 每天定点推送,一天不落 安全审计 无,全靠自觉 CloudTrail 记录每次 API 调用 迁移耗时 — 约 40 分钟(含踩坑排查时间) 写给还在犹豫的人
完整迁移命令速查
# ===== 本地 Mac =====
# 1. 打包
cd ~/.openclaw
tar czf ~/openclaw-backup.tar.gz \
openclaw.json workspace/ sessions/ crontab.json
# 2. 传到云端
rsync -avzP ~/openclaw-backup.tar.gz ubuntu@<EC2-IP>:~/
# ===== 云端 EC2 =====
# 3. 解压
mkdir -p ~/.openclaw && cd ~/.openclaw
tar xzf ~/openclaw-backup.tar.gz
# 4. 改配置:API Key → Bedrock
# 编辑 openclaw.json,provider 改 amazon-bedrock,删掉 apiKey
# 5. 修 session 路径
cd sessions/
sed -i 's|/Users/<你的用户名>/.openclaw|/home/ubuntu/.openclaw|g' *.json
# 6. 改 cron 时区(UTC+8 → UTC,减 8 小时)
# 编辑 crontab.json
# 7. 更新 Telegram webhook(如果用了的话)
curl -s "https://api.telegram.org/bot<TOKEN>/setWebhook?url=https://<EC2-IP>:8443/telegram/webhook"
# 8. 启动!
openclaw gateway start一句话总结
先看时间线: 人类总操作时间:不超过 5 分钟。 其余全是 AI 自主完成。 要复现这个实验,你需要: 这是整个实验的信任基础——你需要告诉亚马逊云科技:"这台服务器上的程序,有权限操作我的云资源。" 给 OpenClaw 所在 EC2 实例的 IAM 角色添加以下权限: 以下是真实对话记录(简化版)。整个过程在 Telegram 里完成。 龙虾执行的命令: 龙虾执行的命令: 这是最"赛博朋克"的一步——龙虾发现自己 SSH 不过去,于是决定自己解决: 龙虾执行的命令: 龙虾执行的核心命令: 两只龙虾完全独立:各自有自己的 Telegram bot、对话记忆、工作空间。通过内网 SSH 互通。 部署完成后,母体龙虾自动给新生龙虾换了一个权限更小的 IAM 角色: 母体保留完整权限(能管理基础设施),子体只保留 Bedrock 权限(只能调模型)。这是基本的安全实践。 这个实验展示的不只是"AI 能执行命令"——而是 AI 能够理解自己的运行环境、发现问题、自主解决问题、并完成一个完整的端到端部署流程。 核心前提是亚马逊云科技的 IAM + Bedrock + EC2 组合: 当这三者结合,AI 就不只是"能聊天"了——它能自主管理基础设施。 关注亚马逊云开发者账号获取更新。 本文是「OpenClaw 云上实战指南」系列第 3 篇。龙虾 AI 自己开服务器:OpenClaw 全自动部署实战,25 分钟 0 命令(附完整代码)
这不是标题党——我真的在聊天框里跟 OpenClaw(社区昵称"龙虾"🦞)说了一句"帮我再部署一个",然后它自己创建了 EC2 实例、分配了弹性 IP、SSH 过去装好了环境、写好了配置文件、启动了新的 Gateway。全程 25 分钟,我没打开过终端。本文是「OpenClaw 云上实战指南」系列第 3 篇,教你复现这个过程。
它到底干了什么?
时间 操作 谁干的 0:00 部署母体龙虾,给 IAM 权限 人类 0:00 查询网络资源,清理闲置 EIP 龙虾 0:00 创建 x86 EC2,分配绑定 EIP 龙虾 0:06 自己给自己加权限,打通 SSH 龙虾 0:14 远程安装 Node.js + OpenClaw 龙虾 0:19 手写配置,启动 Gateway 龙虾 0:22 提供 bot token 和 pairing code 人类 0:25 新龙虾正常响应 ✅ 龙虾 前提条件
第 1 步:给龙虾 IAM 权限
权限策略 用途 AmazonEC2FullAccess创建/管理 EC2 实例、弹性 IP、安全组 IAMFullAccess管理 IAM 策略(龙虾需要给自己加权限) AmazonBedrockFullAccess调用 AI 模型 ⚠️ 这些权限适合实验和测试。生产环境请遵循权限收敛原则,只授予必要的操作权限。实验结束后记得收紧。
第 2 步:跟龙虾聊天——"帮我再部署一个"
2.1 龙虾自查环境
人类:帮我看看你所在区域的网络资源情况。
龙虾:(自动执行了 aws ec2 describe-addresses 等命令)
你有 3 个弹性 IP:
- 1.1.1.1 → 绑在我身上
- 2.2.2.2 → 闲置
- 3.3.3.3 → 也闲置(在花冤枉钱)
要清理吗?aws ec2 describe-addresses --region ap-southeast-1
aws ec2 describe-instances --region ap-southeast-12.2 龙虾创建新服务器
人类:开一台 x86 的 EC2,配置和你一样,但要 x86 不要 ARM。
龙虾:(创建了 t3.large 实例,分配 EIP,绑定到新实例)
新实例已就绪:
- i-0fa6ff98817xxxxxx (t3.large, Ubuntu 24.04)
- EIP: 2.2.2.2aws ec2 run-instances \
--instance-type t3.large \
--image-id <ubuntu-24.04-x86-ami> \
--key-name xxxxxxx \
--security-group-ids sg-07c7ee9aa12dxxxx \
--subnet-id subnet-02d4f3a65e8xxxxx \
--iam-instance-profile Name=OpenClaw \
--tag-specifications 'ResourceType=instance,Tags=[{Key=Name,Value=OpenClaw-x86}]'
aws ec2 associate-address --allocation-id <id> --instance-id <id>2.3 龙虾自己给自己加权限
龙虾:SSH 不通——Permission denied。我只有自己的密钥,没有新实例的 PEM 文件。
不过我可以用 EC2 Instance Connect 解决。我需要给自己加一个 IAM 权限。
人类:你自己加吧。
龙虾:(给自己的 IAM Role 加了 ec2-instance-connect:SendSSHPublicKey 权限)
✅ 权限加好了。推送公钥中……
(推送临时公钥到新实例,趁 60 秒有效窗口把公钥永久写入 authorized_keys)
✅ SSH 打通了。# 给自己加权限
aws iam put-role-policy \
--role-name OpenClaw \
--policy-name EC2InstanceConnect \
--policy-document '{
"Version": "2012-10-17",
"Statement": [{
"Effect": "Allow",
"Action": "ec2-instance-connect:SendSSHPublicKey",
"Resource": "arn:aws:ec2:ap-southeast-1:*:instance/<new-id>"
}]
}'
# 推送临时公钥(60 秒有效)
aws ec2-instance-connect send-ssh-public-key \
--instance-id <id> --instance-os-user ubuntu \
--ssh-public-key file:///home/ubuntu/.ssh/id_ed25519.pub
# 趁窗口写入永久公钥
ssh ubuntu@<ip> 'echo "<pubkey>" >> ~/.ssh/authorized_keys'💡 踩坑提示:
ec2-instance-connect:SendSSHPublicKey 推送的公钥只有 60 秒有效。龙虾的策略是:推送后立刻 SSH 进去,把公钥写入 authorized_keys,一劳永逸。2.4 龙虾远程部署新龙虾
人类:开始部署吧。
龙虾:
步骤:
1. 装 Node.js 22
2. 安装 OpenClaw
3. 写配置文件(参考我自己的配置)
4. 启动 Gateway
需要一个新的 Telegram Bot Token。
人类:(去 BotFather 创建了新 bot,发来 token)
龙虾:(全部通过 SSH 远程完成)
✅ 新龙虾已上线。去给它发条消息。# 远程安装 Node.js
ssh ubuntu@<ip> 'curl -fsSL https://deb.nodesource.com/setup_22.x | \
sudo -E bash - && sudo apt-get install -y nodejs'
# 远程安装 OpenClaw
ssh ubuntu@<ip> 'npm install -g openclaw'
# 远程写配置(龙虾参考了自己的配置,手写了新实例的版本)
ssh ubuntu@<ip> 'cat > ~/.openclaw/openclaw.json << EOF
{
"models": {
"providers": {
"amazon-bedrock": {
"auth": "aws-sdk",
"models": [
{ "id": "us.anthropic.claude-sonnet-4-6" }
]
}
}
},
"channels": {
"telegram": {
"enabled": true,
"botToken": "<NEW_BOT_TOKEN>"
}
}
}
EOF'
# 启动并设为开机自启
ssh ubuntu@<ip> 'openclaw gateway install && \
loginctl enable-linger ubuntu && \
systemctl --user start openclaw-gateway.service'2.5 新龙虾激活
人类:(给新 bot 发了消息) 它要配对,code 是 XXXXXXXX。
龙虾:(在新实例上执行了 openclaw pairing approve)
✅ 配对完成。新龙虾已经可以正常对话了。最终架构
┌──────────────────────┐ ┌──────────────────────┐
│ ARM EC2 │ SSH │ x86 EC2 │
│ t4g.large │◄───────►│ t3.large │
│ │ │ │
│ OpenClaw Gateway │ │ OpenClaw Gateway │
│ "母体龙虾" │ │ "子体龙虾" │
│ │ │ │
│ Bedrock (零密钥) │ │ Bedrock (零密钥) │
└──────────────────────┘ └──────────────────────┘实验结束:安全收紧
# 创建只有 Bedrock 权限的新角色
aws iam create-role --role-name BabyClaw \
--assume-role-policy-document '{
"Version": "2012-10-17",
"Statement": [{
"Effect": "Allow",
"Principal": {"Service": "ec2.amazonaws.com"},
"Action": "sts:AssumeRole"
}]
}'
aws iam attach-role-policy --role-name BabyClaw \
--policy-arn arn:aws:iam::aws:policy/AmazonBedrockFullAccess
# 替换子体龙虾的角色
aws ec2 replace-iam-instance-profile-association \
--association-id <id> \
--iam-instance-profile Name=BabyClaw踩坑总结
坑 解决方案 EC2 Instance Connect 公钥只有 60 秒有效 推送后立刻 SSH 进去写入 authorized_keysIAM 策略传播有延迟 put-role-policy 后等约 10 秒再操作SSH 断开后 systemd user service 停止 必须执行 loginctl enable-linger ubuntu新实例没有 Python/pip Node.js 方式安装 OpenClaw 不依赖 Python Bedrock 模型 ID 需要用 Inference Profile 用 us. 前缀的 ID 启用跨区域路由这说明了什么?
下一步
参考链接
作者:亚马逊云开发者 | 实验过程基于官方博客真实记录
翻一翻现有的 OpenClaw 部署教程,几乎每篇都让你把第三方大模型的 API Key 明文写进配置文件。这有几个问题: 亚马逊云科技的 Amazon Bedrock 搭配 IAM 角色认证,可以做到: 下面是两种部署方式。 Amazon Lightsail 是亚马逊云科技的轻量级云服务器,固定月费。官方已经上架了 OpenClaw 蓝图(Blueprint ID: 完成!回到 OpenClaw 控制台就能开始聊天了。全程没有输入过任何 API Key。 想深入理解每个组件,或者想用 Graviton ARM 实例省钱?手动部署更灵活。 这一步用 IAM 角色替代 API Key,是整个方案的核心。 进入 EC2 控制台 → Launch instances: 为什么选 同配置 ARM 比 x86 便宜约 20%。OpenClaw 是 Node.js 应用,在 ARM 上运行完全正常(本文就是在 ARM 实例上写的)。 启动后,选中实例 → Actions → Security → Modify IAM role → 选择 安装 Node.js 和 OpenClaw: 关键选项: 编辑 三个关键点: 浏览器打开 部署完想确认 Bedrock 通了?在实例上跑这段 Python(已实测通过): 如果你想验证 IAM 角色是否正确绑定: 部署完了只是起点。后续文章会讲: 关注亚马逊云开发者账号获取更新。 本文是「OpenClaw 云上实战指南」系列第 1 篇。OpenClaw 部署教程:Bedrock + IAM 零密钥方案,告别 API Key(附 Lightsail 一键安装)
OpenClaw(社区昵称"龙虾"🦞)是 2026 年 GitHub 上增长速度极快的开源 AI 助手框架,能 24/7 在线帮你处理消息、执行命令、管理文件。本文教你用亚马逊云科技的两种方式部署它——关键是:不需要任何 API Key。
为什么要告别 API Key?
方案 A:Lightsail 一键部署(5 分钟上手)
openclaw_ls_1_0),开箱即用。第 1 步:创建实例
还没有亚马逊云科技账号?点此免费注册,Lightsail 新用户前 3 个月可免费试用部分套餐。
us-east-1)规格 vCPU 内存 SSD 月费 适合场景 small_3_0 2 2GB 60GB $12 个人体验 medium_3_0 2 4GB 80GB $24 推荐,日常使用 large_3_0 2 8GB 160GB $44 多人/多渠道 💡 个人体验 $12/月够用,多人用建议 $24 起。仅 IPv6 的版本更便宜($10/$20/$40),如果你不需要公网 IPv4。
第 2 步:配对浏览器
y 确认,a 批准配对第 3 步:启用 Bedrock
📖 详细步骤参考官方博客:推出 OpenClaw on Amazon Lightsail
方案 B:EC2 手动部署(完全掌控每一步)
前提
第 1 步:创建 IAM 角色(关键的安全步骤)
AmazonBedrockFullAccess,勾选,NextOpenClaw,Create role⚠️
AmazonBedrockFullAccess 适合快速上手。生产环境建议创建自定义策略,只授予你需要的模型和操作权限。第 2 步:启动 EC2 实例
配置项 值 说明 AMI Ubuntu Server 24.04 LTS (ARM) AMI ID: ami-0f1b9964277dbd54e(us-east-1)实例类型 t4g.medium2 vCPU, 4GB RAM, Graviton ARM Key pair 你的 SSH 密钥 没有就 Create new 存储 20GB gp3 够用 t4g.medium(ARM/Graviton)?类型 架构 配置 小时价 月费(估算) t4g.medium ARM 2C 4GB $0.0336 ~$24 t3.medium x86 2C 4GB $0.0416 ~$30 OpenClaw 角色。第 3 步:SSH 登录 & 安装
ssh -i "your-key.pem" ubuntu@<EC2 公网 IP># 安装 nvm
curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.40.3/install.sh | bash
source ~/.nvm/nvm.sh
# 安装 Node.js
nvm install 24
node -v # v24.x.x
# 安装 OpenClaw
npm install -g openclaw@latest
openclaw --version第 4 步:配置向导
openclaw onboard --install-daemon配置项 选这个 Mode Manual Gateway Local gateway Model provider amazon-bedrock Default model us.amazon.nova-2-lite-v1:0Gateway auth token(设一个密码) Channels / Skills 先 Skip 第 5 步:配置 Bedrock 模型
~/.openclaw/openclaw.json,在 models 部分加入(合并,不要覆盖整个文件):{
"models": {
"providers": {
"amazon-bedrock": {
"baseUrl": "https://bedrock-runtime.us-east-1.amazonaws.com",
"api": "bedrock-converse-stream",
"auth": "aws-sdk",
"models": [
{
"id": "us.amazon.nova-2-lite-v1:0",
"name": "Nova 2 Lite(日常对话,高性价比)",
"reasoning": false,
"input": ["text", "image"],
"cost": { "input": 0.06, "output": 0.24 },
"contextWindow": 300000,
"maxTokens": 8192
},
{
"id": "us.amazon.nova-pro-v1:0",
"name": "Nova Pro(复杂推理)",
"reasoning": false,
"input": ["text", "image"],
"cost": { "input": 0.80, "output": 3.20 },
"contextWindow": 300000,
"maxTokens": 8192
}
]
}
}
}
}"auth": "aws-sdk" —— 使用 IAM 角色认证,不需要写 Keyus. 前缀的模型 ID —— 这是 Inference Profile,启用了跨区域自动路由(CRIS)。某个区域繁忙时请求会自动切到其他区域,避免排队第 6 步:启动
openclaw gateway restart
openclaw statushttp://<EC2 IP>:18789/?token=<你的密码> 即可使用。验证:确认 Bedrock 连通
import boto3, json
# 在 EC2 上不需要传 credentials,IAM Role 自动生效
bedrock = boto3.client('bedrock-runtime', region_name='us-east-1')
response = bedrock.invoke_model(
modelId='us.amazon.nova-2-lite-v1:0',
contentType='application/json',
accept='application/json',
body=json.dumps({
"messages": [{"role": "user", "content": [{"text": "你好,用一句话介绍你自己"}]}],
"inferenceConfig": {"maxTokens": 200}
})
)
result = json.loads(response['body'].read())
print(result['output']['message']['content'][0]['text'])
# 输出: 我是一个人工智能助手,我可以帮助你回答问题、提供信息、生成文本,并支持多轮对话。import boto3
sts = boto3.client('sts', region_name='us-east-1')
print(sts.get_caller_identity())
# 应该看到你的 Account ID 和 Role ARN,而不是 User ARN下一步
参考链接
作者:亚马逊云开发者 | 所有代码均在 us-east-1 区域实测通过
这么多年来,一种感觉就是做订单总是不会一帆风顺, 我们还是贸易中间商,介于老外和工厂之间,
有人问我要不要搞工厂,我都是说不要搞,非常累,工厂赚再多的钱也是他该得的,他付出心血和努力是巨大的,厂房的管理,人员的管理,订单的进程,她不是点对点的结束,它是一个长期的过程。非常考验人的耐心和心性。
所以订单的过程我总是希望各种事情顺一点,少操点心,就谢天谢地了。特别是那种订单利润不多,款式杂 颜色多的订单。
特别是小公司,单子又不多,又需要这些订单来维持生计。如果在大公司是有不同部门分工明确,业务部门 QC 部门等,小公司基本上都是一个人处理。
传统统计方法在时间序列分析中既简洁又有力,但面对大规模时间序列集合时,扩展性往往不尽如人意。现实中的趋势变化往往微弱、带有噪声、数量也不止一个,靠肉眼判断既不可靠也不现实。一旦需要处理数十乃至数百条时间序列,人工识别就更不可行了。 解决思路是用程序来定位变化点。估计趋势变化点的手段有很多,本文聚焦于网格搜索策略与分段回归的结合,自动确定变化点的数量和位置。 完整代码有 R 和 Python 两个版本,Streamlit 应用也可在线体验。 网格搜索是一种系统化的优化技术,原理并不复杂:在预定义的离散候选参数集上逐一评估模型,按照指定准则挑出表现最好的那组配置。 在分段回归中,待搜索的参数就是节点(knot)的数量和位置,每个节点对应一个候选变化点。整体流程如下: 为减少过拟合、增强稳定性,还需要设置节点之间的最小距离约束,避免变化点在时间轴上挤得太近。 比较不同变化点数量的模型之前,需要有一套统一的评价标准。代价函数(也叫损失函数或目标函数)就是干这个的:它接收一组模型参数,输出一个标量,反映模型误差或拟合质量。机器学习和统计建模中的训练与模型选择,本质上都是在寻找令代价函数取极值的参数组合。 回归问题中,代价函数度量的是预测值与观测值之间的偏差。常见选择包括:均方误差(MSE)度量平方残差的均值;平均绝对误差(MAE)度量绝对残差的均值;负对数似然(NLL)度量观测数据在给定模型下出现的概率。 这些指标只关注拟合优度,不考虑模型复杂度。变化点越多的分段回归模型几乎总能把误差压得更低,哪怕它只是在拟合噪声。 应对方法是引入惩罚代价函数,在拟合质量和模型复杂度之间取得平衡。AIC(赤池信息准则)和 BIC(贝叶斯信息准则)是两个典型代表,均以负对数似然为基础,再加上一个与估计参数数量相关的惩罚项。 AIC: AIC=-2log(L) +2k BIC: BIC=-2log(L)+klog(n)* 其中: 惩罚项的存在抑制了不必要的复杂度,有助于在网格搜索中筛选出真正有意义的变化点数目。BIC 的惩罚力度比 AIC 更重,选出的变化点数量往往更少——也就更保守。 基础概念铺设完毕,下面定义网格搜索的具体流程。一个典型的变化点检测网格搜索包含四个环节: 函数输入是时间序列与搜索空间参数,输出是最优节点集合。 Figure 3: A general grid search function workflow 网格搜索胜在直白、易于实现,但计算开销会随候选变化点数量的增长而快速膨胀。引入搜索空间约束可以缓解这个问题:减少待评估的配置数,同时也起到防止过拟合的作用。 具体的约束手段有三条:一是排除序列头尾一定比例的观测值,保证每个分段都有足够数据支撑趋势估计;二是强制每个分段包含不少于某个阈值的观测值,稳定斜率估计,避免模型在短而嘈杂的片段上过拟合;三是限定节点数量的上限,控制搜索范围。 设置这些参数时需要综合考虑观测值数量、序列频率以及业务逻辑。 回到前一篇教程的示例——加利福尼亚州天然气消费者数量,看一下网格搜索函数在 R 中的实现。Python 版本可在对应 notebook 中获取。 加载所需的库: 引入一组辅助函数,其中包括网格搜索函数 piecewise_regression: 加载序列并整理格式: 序列为年度数据,index 列是时间戳,y 列是数值: 绘制序列: 用 piecewise_regression 函数识别最优节点数量及位置: 搜索空间由以下参数定义: 这里把 max_knots 设为 4,搜索空间中节点数量的范围就是 0–4。函数会根据约束条件生成候选配置,并裁剪掉不满足条件的组合。 运行结果如下: 输出按节点数量分组列出了测试过的模型数,最终确定最优节点数为 2。函数还抛出了一条警告:受搜索空间约束限制,观测值不足以容纳 4 个节点,因此跳过了对应的拟合。这一行为符合预期——说明约束条件正在起作用。 下面的动画展示了搜索空间中所有配置的拟合过程: 函数输出中包含搜索过程和最优结果的详细信息。最优节点数: 节点位置: 最后,用 函数加上注释,把最优节点叠加到原始序列上进行可视化: 网格搜索配合分段回归,对于识别趋势变化点的数量和位置是一种切实可行的方案。它最适合的场景是相对"干净"的时间序列,主导信号就是底层趋势——本文的示例正是如此。 现实中的时间序列往往不这么纯粹。季节性、突发水平偏移、异常值都可能干扰甚至扭曲趋势成分。在这些效应存在的情况下,网格搜索可能定位到虚假的变化点,也可能遗漏真正有意义的趋势断裂。 一种可行的预处理策略是先做分解(如 STL),将趋势成分分离出来,再在提取到的趋势上执行网格搜索,而非直接在原始序列上操作。 本文展示了如何将变化点检测转化为一个优化问题:通过网格搜索遍历候选节点配置,用惩罚似然准则(BIC)选出最优模型,配合分段回归完成趋势变化点的自动检测。 分段回归是建模趋势变化的可解释框架;网格搜索虽然朴素,但在估计变化点位置上行之有效;BIC 等惩罚准则在拟合优度与模型复杂度之间做出了取舍,抑制了过拟合倾向;搜索空间约束——边缘缓冲区、最小分段长度、最大节点数——进一步稳定了模型并降低了计算开销。 网格搜索在计算效率上确实算不上最优解,但它的透明度是一大优势,作为基线方法和实际工程中的可用方案都没有问题。面对更复杂的场景,可以在此框架基础上引入高级优化策略或贝叶斯变化点检测方法。下一篇教程将讨论如何把这套方法应用到更复杂的实际场景中。 本文代码: https://avoid.overfit.cn/post/17546aec522448f3a843c394d804fe48 by Rami Krispin
Figure 1: Identify the optimal number of knots and their positions using grid search使用网格搜索寻找变化点
定义代价函数

Figure 2: Example for finding the optimal number of knots using the BIC score网格搜索工作流程

注意,这里用不含节点的简单趋势模型作为网格搜索结果的基准。
网格搜索实现
library(dplyr)
library(tsibble)
library(plotly) fun_path <- "https://raw.githubusercontent.com/RamiKrispin/the-forecaster/refs/heads/main/functions.R"
source(fun_path) path <- "https://raw.githubusercontent.com/RamiKrispin/the-forecaster/refs/heads/main/data/ca_natural_gas_consumers.csv"
ts <- read.csv(path) |>
arrange(index) |>
filter(index > 1986) |>
as_tsibble(index = "index")
ts |> head() # A tsibble: 6 x 2 [1Y]
index y
<int> <int>
1 1987 7904858
2 1988 8113034
3 1989 8313776
4 1990 8497848
5 1991 8634774
6 1992 8680613 p <- plot_ly(data = ts) |>
add_lines(x = ~ index,
y = ~ y, name = "Actual") |>
layout(
title = "Number of Natural Gas Consumers in California",
yaxis = list(title = "Number of Consumers"),
xaxis = list(title = "Source: US energy information administration"),
legend = list(x = legend_x, y = legend_y)
)
p
Figure 4: Yearly number of natural gas consumers in California. The series is trending up without seasonality patterns grid <- piecewise_regression(
data = ts,
time_col = "index",
value_col = "y",
max_knots = 4,
min_segment_length = 8,
edge_buffer = 0.05,
grid_resolution = 20
)max_knots - 最大节点数量min_segment_length - 两个节点之间的最小观测值数量edge_buffer - 从序列头尾排除的观测值比例grid_resolution - 每个节点数量对应的最大搜索组合数 Testing 0 knot(s)...
Best BIC: 919.28 | RSS: 1.006639e+12 | Tested 1 configurations
Testing 1 knot(s)...
Best BIC: 858.05 | RSS: 182625404855 | Tested 18 configurations
Testing 2 knot(s)...
Best BIC: 844.26 | RSS: 115452860424 | Tested 25 configurations
Testing 3 knot(s)...
Best BIC: 852.94 | RSS: 131838198802 | Tested 5 configurations
Testing 4 knot(s)...
Optimal model: 2 knot(s) with BIC = 844.26
Warning message:
In generate_candidates(k, min_idx, max_idx, min_segment_length) :
Cannot fit 4 knots with min segment length 8
Figure 5: Animation of the grid search process grid$optimal_knots
[1] 2 grid$knot_dates
[1] 1999 2007plot_knots
Figure 6: The optimal number of knots and their positions based on the grid search results局限性
对于结构复杂或噪声较大的序列,能够联合建模趋势与季节性的变化点检测方法可能更为适用。
总结
| 任务名 | 时间 | 状态 |
|---|---|---|
| health-check | 每 6 小时 | ✅ |
| 早间提醒 | 每天 07:15 | ✅ |
| 阿里云账单提醒-早 | 每天 09:00 | ✅ |
| HotNews 用户统计-早 | 每天 09:00 | ✅ |
| 发票采集提醒 | 每天 09:00 | ✅ |
| 发票自动采集 | 每天 10:00 | ✅ |
| HotNews 用户统计-午 | 每天 12:00 | ✅ |
| 阿里云账单提醒-晚 | 每天 18:00 | ✅ |
| 智能巡检 | 每天 08:00, 20:00 | ✅ |
| HotNews 用户统计-晚 | 每天 20:00 | ✅ |
| 晚间预告 | 每天 22:30 | ✅ |
| 工资生成与邮件发送 | 每月 1 号 09:00 | ✅ |
| hot.uihash.com | 欢迎来看 | ✅ |
还记得刚入行时那个让我通宵加班的Bug吗?那天我自认为完美地完成了功能开发,一个 后来,一位资深开发告诉我:"在成熟的团队里,你那个push方式早就被禁用了。试试这个: 就是这个看起来有些奇怪的命令,彻底改变了我的代码提交方式,也让我真正理解了什么是专业的代码审查流程。 当你执行 这个命令是Gerrit代码审查系统的核心,它为Git仓库装上了一道"安检门"。 在Git的世界里,一切都是引用。分支、标签,本质上都是对提交的引用。 而 简单说:refs/for是"提议",refs/heads是"命令"。 当你执行 这就解释了为什么你的提交没有直接出现在目标分支,而是在Gerrit的Web界面上等待审查。 Change-ID是Gerrit自动添加到提交消息中的唯一标识符,格式如下: 当审查者要求你修改代码时,你需要提交新版本。Change-ID告诉Gerrit:"这不是一个新的审查请求,而是对已有Change #884120的更新"。 要自动生成Change-ID,需要安装commit-msg钩子: 安装后,每次 此时,Gerrit会返回一个URL: 在Gerrit Web界面,审查者可以进行: 评分规则: 收到-1评分后,你需要修改代码: Gerrit会自动将这次推送作为同一个Change的新补丁集(Patch Set)。 当代码获得+2和Verified+1后,有权限的用户点击"Submit",代码才会真正合入目标分支。 每个Change只做一件事,控制在200行以内。大变更难以审查,也容易引入Bug。 原因:没有安装commit-msg钩子,或者提交早于钩子安装。 解决: 可以,但需要特殊权限。在启用了强制审查的仓库中,普通开发者没有 正如一位前辈所说:"Code Review不是门槛,而是阶梯。每一次审查,都是你代码质量的跃迁。" 现在,当你再执行这个"魔法"命令时,希望你看到的不仅是一个Git操作,而是一个专业开发者对代码的敬畏之心。 延伸阅读:一次不规范提交引发的血案,让我发现了Git中的"代码安检门"
引言
git push origin master将代码直接推送到主分支。结果第二天,整个构建系统崩溃了——因为我忽略了代码规范,更没有经过任何审查。项目经理的脸色,至今难忘。git push origin HEAD:refs/for/xxx分支"一、初识"魔法"参数:一个命令的前世今生
1.1 直观理解:这不是普通的 push
git push origin HEAD:refs/for/master时,表面上看起来像是推送到master分支,但实际上,你的代码去了一个完全不同的地方。1.2 基础语法拆解
git push origin HEAD:refs/for/xxx分支origin:远程仓库名称HEAD:指向当前分支的最新提交::本地引用与远程引用的分隔符refs/for/xxx分支:Gerrit的特殊引用,表示"为xxx分支创建审查请求"二、深入剖析:refs/for背后的"魔法"
2.1 引用(Reference)的秘密
# 本地分支:refs/heads/master
# 远程分支:refs/remotes/origin/master
# 标签:refs/tags/v1.0refs/for/,是Gerrit创造的一个虚拟引用。2.2 refs/for vs refs/heads:天壤之别
对比维度 refs/for/xxx refs/heads/xxx 核心用途 创建代码审查请求 直接更新分支 是否审查 ✅ 必须经过审查 ❌ 绕过审查 代码入库 审查通过后入库 立即入库 适用场景 团队协作、质量管控 个人项目、紧急修复 2.3 Gerrit的"善意的谎言"
git push origin HEAD:refs/for/master时,Gerrit并没有真的创建一个叫refs/for/master的分支。它做了什么?refs/for/前缀refs/changes/命名空间下# 存储格式示例
refs/changes/20/884120/1
# [CD]:Change号后两位
# [ABCD]:Change号
# [EF]:补丁集编号三、Change-ID:连接一切的"身份证"
3.1 什么是Change-ID?
Change-Id: I47c6e77e3a9c8b9c8b9c8b9c8b9c8b9c8b9c8b9c3.2 为什么需要它?
3.3 commit-msg钩子:自动化的魔法
# 克隆时安装钩子
git clone ssh://user@gerrit-server:29418/project.git && \
(cd project && \
curl -o .git/hooks/commit-msg \
https://gerrit-server/tools/hooks/commit-msg && \
chmod +x .git/hooks/commit-msg)git commit都会自动添加Change-ID。四、完整工作流程:从提交到合入
4.1 第一步:本地开发与提交
# 创建功能分支
git checkout -b feature/awesome-function
# 开发、提交
git add .
git commit -m "feat: 添加超棒功能"
# Change-ID会自动添加到提交信息末尾4.2 第二步:推送审查请求
git push origin HEAD:refs/for/masterremote: New Changes:
remote: https://gerrit-server/c/my-project/+/884204.3 第三步:审查与评分
4.4 第四步:修改与更新
# 修改代码
git add .
# 关键:使用--amend修改同一提交
git commit --amend
# 注意:Change-ID保持不变
# 再次推送
git push origin HEAD:refs/for/master4.5 第五步:合入代码
五、最佳实践:让refs/for发挥最大价值
5.1 规范化提交信息
# 好的提交信息
feat(用户模块): 增加手机号登录功能
- 支持国际手机号格式验证
- 集成短信验证码服务
- 添加登录频率限制
Change-Id: I47c6e77e3a...5.2 小步快跑,单一职责
5.3 使用Topic管理相关变更
# 为相关变更设置相同Topic
git push origin HEAD:refs/for/master%topic=user-login-refactor5.4 定期Rebase,保持代码最新
git fetch origin master
git rebase origin/master
git push origin HEAD:refs/for/master5.5 及时响应审查意见
六、常见问题解答
Q1:为什么提示"missing Change-Id"?
# 安装钩子后,为最近一次提交添加Change-ID
git commit --amend --no-editQ2:可以直接推送到refs/heads吗?
refs/heads/*的推送权限。Q3:如何下载别人的Change进行本地测试?
# 在Gerrit UI上,点击"Download"按钮,复制fetch命令
git fetch https://gerrit-server/my-project refs/changes/20/884120/2
git checkout FETCH_HEADQ4:如果目标分支不存在怎么办?
refs/for/xxx中的xxx必须是仓库中已存在的分支,否则Gerrit会拒绝推送。七、总结:从"提交代码"到"贡献代码"
git push origin HEAD:refs/for/xxx不仅仅是一个命令,它代表着一种工程文化的转变: