即刻App年轻人的同好社区
下载
今天补充一些避坑指南和下一步进阶方向
💡 首先是，搭配食用的7 条避坑指南，可以直接扔给 AI 形成记忆：
1. 拒绝“假通”测试：严禁仅用 curl 测试 API。必须通过 MCP 或 browser-use 调用真实浏览器进行端到端点击测试，防止后端数据通了但前端样式丢失或交互失效。
2. 原生视觉走查：截图后禁止让 AI 写 Python 脚本读图。直接调用AI的原生视觉能力“看”截图，让它像真实用户一样判断 UI 布局错位或渲染失败。
3. 带状态调试：放弃 Playwright 默认的无痕沙盒模式。使用 browser-use --browser real --profile "Default" 挂载本地真实 Chrome 配置（含 Cookie/Session），解决因验证码或登录态丢失导致 AI 无法进入业务页面的死结。
4. Git 存档回滚：将 Git Commit 设为“游戏存档点”。在自动化脚本中集成错误检测，一旦 AI 陷入死循环或测试连续失败，自动执行 git reset --hard 回滚至上一个稳定版本，切断错误累积。
5. 原子化任务粒度：task.json 的拆解必须极细。拒绝“完成支付功能”这种模糊指令，必须拆解为“定义数据库表”、“写后端接口”、“写前端组件”、“联调”四个独立任务。
6. 上下文“无状态”化：不要依赖长对话记忆。每次循环强制重置 Context，迫使 AI 必须通过读取 progress.txt 和文件系统来获取状态，这是保持模型长时间运行不“降智”的关键。
7. 文件权限隔离：在 Agent Team 中实施严格的目录级权限控制。Backend Agent 只能写 /api，Frontend Agent 只能写 /src，防止 AI 幻觉导致跨层级乱改代码引发灾难。
🚀 接下来的3 个升级方向，让Agent越来越好用：
1. RAG 动态知识库：为 Agent 挂载向量数据库，索引 Next.js 15、Supabase 等最新官方文档。防止模型因训练数据滞后而写出过时语法（幻觉），实现“边查文档边写代码”。
2. 成本熔断机制：在循环脚本中集成 Token 计费监控。设定阈值（如单任务耗资 >$2 或重试 >5 次），触发时自动 Kill 进程并推送到手机，防止逻辑死循环导致 API 账单爆炸。
3. Human-in-the-Loop 网关：在 task.json 引入 requires_approval 字段。对于数据库 Schema 变更、生产环境部署等高危操作，Agent 必须挂起并发送通知，等待人类回复“Approve”后方可执行。
怎么才能让AI持续工作？这块还有什么经验，欢迎评论交流。
💡 首先是，搭配食用的7 条避坑指南，可以直接扔给 AI 形成记忆：
1. 拒绝“假通”测试：严禁仅用 curl 测试 API。必须通过 MCP 或 browser-use 调用真实浏览器进行端到端点击测试，防止后端数据通了但前端样式丢失或交互失效。
2. 原生视觉走查：截图后禁止让 AI 写 Python 脚本读图。直接调用AI的原生视觉能力“看”截图，让它像真实用户一样判断 UI 布局错位或渲染失败。
3. 带状态调试：放弃 Playwright 默认的无痕沙盒模式。使用 browser-use --browser real --profile "Default" 挂载本地真实 Chrome 配置（含 Cookie/Session），解决因验证码或登录态丢失导致 AI 无法进入业务页面的死结。
4. Git 存档回滚：将 Git Commit 设为“游戏存档点”。在自动化脚本中集成错误检测，一旦 AI 陷入死循环或测试连续失败，自动执行 git reset --hard 回滚至上一个稳定版本，切断错误累积。
5. 原子化任务粒度：task.json 的拆解必须极细。拒绝“完成支付功能”这种模糊指令，必须拆解为“定义数据库表”、“写后端接口”、“写前端组件”、“联调”四个独立任务。
6. 上下文“无状态”化：不要依赖长对话记忆。每次循环强制重置 Context，迫使 AI 必须通过读取 progress.txt 和文件系统来获取状态，这是保持模型长时间运行不“降智”的关键。
7. 文件权限隔离：在 Agent Team 中实施严格的目录级权限控制。Backend Agent 只能写 /api，Frontend Agent 只能写 /src，防止 AI 幻觉导致跨层级乱改代码引发灾难。
🚀 接下来的3 个升级方向，让Agent越来越好用：
1. RAG 动态知识库：为 Agent 挂载向量数据库，索引 Next.js 15、Supabase 等最新官方文档。防止模型因训练数据滞后而写出过时语法（幻觉），实现“边查文档边写代码”。
2. 成本熔断机制：在循环脚本中集成 Token 计费监控。设定阈值（如单任务耗资 >$2 或重试 >5 次），触发时自动 Kill 进程并推送到手机，防止逻辑死循环导致 API 账单爆炸。
3. Human-in-the-Loop 网关：在 task.json 引入 requires_approval 字段。对于数据库 Schema 变更、生产环境部署等高危操作，Agent 必须挂起并发送通知，等待人类回复“Approve”后方可执行。
怎么才能让AI持续工作？这块还有什么经验，欢迎评论交流。
2 00
今天Kimi发布了一系列的新功能，包括新的模型、更强的代码、以及Agent集群能力，号称跑到了gemini-3-pro级别去了，尤其是Agent Swarm集群功能，可以并发操作多个Agent实现复杂任务。
一时间，脑子里很多想跑的。
但好巧不巧，就在刚刚，Deepseek也发布了最新的模型，让外界对v4有了更清晰的预期。
以往解读一个新模型或者论文，需要起码半天，然后再写文章、整理图片，写到公众号里发布，至少一天是没有了。
欸，我灵机一动，是不是可以直接用Kimi Agent Swarm帮我完成以上所有流程呢？正好也能测一下它的效果。
说干就干。
进到Kimi，右下角就能看到K2.5了，选择Agent 集群。
输入任务，让Kimi先找到DeepSeek这个新模型&论文的出处，然后到海外论坛找大v的解读、评价，最后写一篇内容，关键是一定要带上「图片」确保最终是一个图文并茂的「word文档」这样我就可以直接导入公众号后台了。
接着，就能看到Agent Swarm的一顿操作。
首先就是常规的规划任务，基本上按我说的去做。
有趣的来了，Kimi会去自动新建多个subagent「专家」去解决不同的问题，例如这里是word文档生成专家。
还有调研专家、论文解读专家等等。。
点开每个专家，是能看到一个独立的Agent Window，里面是每个subagent的独立操作窗口，这也就是我开头说的 并发操作多个Agent实现复杂任务
这个很强啊，预期后面会接入更多的应用，直接用国产模型就能干到Manus、Flowith用海外顶级模型的效果哈哈哈。
OK，接着来看下Agent Swarm出来的文章效果，我直接导入了。
DeepSeek-OCR2发布：AI学会用眼睛思考了
过去的AI看图，根本就是在瞎扫描
传统大模型看图的方式极度僵硬——从左到右，从上到下，逐行扫描像素。一篇学术论文和一张购物小票，执行完全相同的路径。
这种固定路径的恶果是：AI明明能看到图，却总要先把图转成文字再推理。绕一大圈，效率低且经常出错。
OCR2干的不是优化，是直接换了底层逻辑
1月27日，DeepSeek-OCR2发布，论文名《DeepSeek-OCR 2: Visual Causal Flow》。
OCR1主攻视觉压缩——文字转像素图再压缩成token。效果还行，但本质仍是像素层面处理。
OCR2彻底换了思路：让AI基于图片的内容逻辑去理解，而非执行机械扫描。看复杂报表时，你不会逐字阅读，而是先扫整体结构，再定位关键数字。大脑瞬间在构建逻辑链条。DeepSeek-OCR2做的就是这个，官方称之为视觉因果流。
CLIP被扔了，这才是真正的破局点
传统视觉语言模型用CLIP把图像转token序列，按固定光栅顺序喂给大模型，直接无视图像语义。分栏报纸左右两栏文字，按扫描顺序读上下文全乱。
OCR2把CLIP彻底扔掉，改用LLM架构——基于Qwen2-0.5B——作为视觉编码器。编码器不再简单转token序列，而是根据语义内容动态重排token顺序。同样视觉信息，不同内容结构，输出完全不同。
论文称之为两级级联结构：第一级编码器语义重排序；第二级LLM解码器基于有序序列推理。图片里的因果关系被编码进token顺序本身。
Karpathy点破了一个更深的问题
OmniDocBench基准测试，OCR2得分91.09%，比OCR1提升3.73%。阅读顺序准确度编辑距离从0.085降到0.057。这领域基准已很成熟，几个百分点提升都是重大突破。
Andrej Karpathy——前OpenAI研究员——评论指出：最有趣的问题是，像素是否比文本token更适合作为LLM输入。把图片先转文字再喂模型，是必要的吗？还是可以直接让模型从像素开始理解世界？DeepSeek-OCR2的回答很明确：可以直接从像素开始。Tokenization这个被无数人吐槽的环节，可能真的该退休了。
V4传闻：春节前后会憋出更大的招？
开发者社区关于DeepSeek V4的传闻已扩散。据说发布时间可能在2月春节前后，核心方向是AI编程和长上下文代码理解。
更有意思的传闻：V4可能不再区分通用模型和推理模型，直接把R系列推理能力整合进去。若真如此，配置AI应用的复杂度将大幅下降——这意味着全能模型时代或许真的要来了。
——— END ———
怎么样？其实我之前这篇文章其实也是这样用Kimi Office的能力跑的：一文看懂GEO｜普林斯顿大学最新论文解析
图文排版都不用做了，超级省事。
而且加上，Kimi的多模态能力，听说是可以看2个小时的视频？
那是不是可以开发一个产品，直接从youtube、b站等平台视频转成图文章，对标notebookLM，替代youmind等产品，成本下降一半
有没有搞头？？急！！
Kimi Agent Swarm还有什么有趣玩法吗，球球🥺
一时间，脑子里很多想跑的。
但好巧不巧，就在刚刚，Deepseek也发布了最新的模型，让外界对v4有了更清晰的预期。
以往解读一个新模型或者论文，需要起码半天，然后再写文章、整理图片，写到公众号里发布，至少一天是没有了。
欸，我灵机一动，是不是可以直接用Kimi Agent Swarm帮我完成以上所有流程呢？正好也能测一下它的效果。
说干就干。
进到Kimi，右下角就能看到K2.5了，选择Agent 集群。
输入任务，让Kimi先找到DeepSeek这个新模型&论文的出处，然后到海外论坛找大v的解读、评价，最后写一篇内容，关键是一定要带上「图片」确保最终是一个图文并茂的「word文档」这样我就可以直接导入公众号后台了。
接着，就能看到Agent Swarm的一顿操作。
首先就是常规的规划任务，基本上按我说的去做。
有趣的来了，Kimi会去自动新建多个subagent「专家」去解决不同的问题，例如这里是word文档生成专家。
还有调研专家、论文解读专家等等。。
点开每个专家，是能看到一个独立的Agent Window，里面是每个subagent的独立操作窗口，这也就是我开头说的 并发操作多个Agent实现复杂任务
这个很强啊，预期后面会接入更多的应用，直接用国产模型就能干到Manus、Flowith用海外顶级模型的效果哈哈哈。
OK，接着来看下Agent Swarm出来的文章效果，我直接导入了。
DeepSeek-OCR2发布：AI学会用眼睛思考了
过去的AI看图，根本就是在瞎扫描
传统大模型看图的方式极度僵硬——从左到右，从上到下，逐行扫描像素。一篇学术论文和一张购物小票，执行完全相同的路径。
这种固定路径的恶果是：AI明明能看到图，却总要先把图转成文字再推理。绕一大圈，效率低且经常出错。
OCR2干的不是优化，是直接换了底层逻辑
1月27日，DeepSeek-OCR2发布，论文名《DeepSeek-OCR 2: Visual Causal Flow》。
OCR1主攻视觉压缩——文字转像素图再压缩成token。效果还行，但本质仍是像素层面处理。
OCR2彻底换了思路：让AI基于图片的内容逻辑去理解，而非执行机械扫描。看复杂报表时，你不会逐字阅读，而是先扫整体结构，再定位关键数字。大脑瞬间在构建逻辑链条。DeepSeek-OCR2做的就是这个，官方称之为视觉因果流。
CLIP被扔了，这才是真正的破局点
传统视觉语言模型用CLIP把图像转token序列，按固定光栅顺序喂给大模型，直接无视图像语义。分栏报纸左右两栏文字，按扫描顺序读上下文全乱。
OCR2把CLIP彻底扔掉，改用LLM架构——基于Qwen2-0.5B——作为视觉编码器。编码器不再简单转token序列，而是根据语义内容动态重排token顺序。同样视觉信息，不同内容结构，输出完全不同。
论文称之为两级级联结构：第一级编码器语义重排序；第二级LLM解码器基于有序序列推理。图片里的因果关系被编码进token顺序本身。
Karpathy点破了一个更深的问题
OmniDocBench基准测试，OCR2得分91.09%，比OCR1提升3.73%。阅读顺序准确度编辑距离从0.085降到0.057。这领域基准已很成熟，几个百分点提升都是重大突破。
Andrej Karpathy——前OpenAI研究员——评论指出：最有趣的问题是，像素是否比文本token更适合作为LLM输入。把图片先转文字再喂模型，是必要的吗？还是可以直接让模型从像素开始理解世界？DeepSeek-OCR2的回答很明确：可以直接从像素开始。Tokenization这个被无数人吐槽的环节，可能真的该退休了。
V4传闻：春节前后会憋出更大的招？
开发者社区关于DeepSeek V4的传闻已扩散。据说发布时间可能在2月春节前后，核心方向是AI编程和长上下文代码理解。
更有意思的传闻：V4可能不再区分通用模型和推理模型，直接把R系列推理能力整合进去。若真如此，配置AI应用的复杂度将大幅下降——这意味着全能模型时代或许真的要来了。
——— END ———
怎么样？其实我之前这篇文章其实也是这样用Kimi Office的能力跑的：一文看懂GEO｜普林斯顿大学最新论文解析
图文排版都不用做了，超级省事。
而且加上，Kimi的多模态能力，听说是可以看2个小时的视频？
那是不是可以开发一个产品，直接从youtube、b站等平台视频转成图文章，对标notebookLM，替代youmind等产品，成本下降一半
有没有搞头？？急！！
Kimi Agent Swarm还有什么有趣玩法吗，球球🥺
2 00
最近 Claude Skills 很火。
但我观察了一圈，发现大家都在陷入一种“开发者的自嗨”。
绝大多数 Skills 的应用场景都被死死锁在 IDE 里，锁在开发者的电脑前。
这叫开发提效，不叫业务提效。
真正的业务发生在移动端，发生在你通勤、吃饭、甚至躺在床上刷 TikTok 的时候。
如果你的 AI 能力必须打开电脑、输入命令行才能调用，那它的时空效率就是零。
于是我抛弃本地的 Claude Code，基于 OpenHands 做了一套云端 Skills 系统。
效果极其简单粗暴：
我在刷 TikTok，看到一个爆款视频，点击复制链接，敲击 iPhone 背面三下。
wxv_4355007050494509070
20 秒后，我的飞书多维表格里自动新增了一行数据。
Image
这行数据包含了：这个视频的无水印文件、Gemini 拆解的镜头语言分析、爆款原因推导，以及一套可直接复用的 AI 视频生成提示词。
全过程我不需要打开电脑，不需要切换 APP，不需要等待。
这就是我今天要聊的：如何用 OpenHands + Skills + iOS 快捷指令，构建一套真正落地的业务自动化系统。
01 为什么 Claude Code 在业务侧是伪需求
先厘清两个概念：OpenHands 和 Claude Code。
Claude Code 是 Anthropic 官方推出的命令行工具，它是一个嵌入在你本地终端里的结对程序员。它的 Skills 本质是上下文记忆和本地工具接口。
它的优势是懂你的代码规范，能直接改你电脑里的文件。
但它有一个对于业务场景的致命弱点：它必须依附于你的会话，你不在，它就不动。
它是一个副驾驶（Copilot）。
而 OpenHands（前身 OpenDevin）是一个开源的、自主的 AI 软件工程师。它运行在 Docker 容器里，是一个独立的服务端 Agent。
Image
openhands.dev
它是一个可以被封装成 API 服务的数字员工。
我看重 OpenHands 的核心理由只有一个：它可以 24 小时在线，并且可以通过 API 远程唤醒。
我做的这个 TikTok 分析系统，本质就是把 OpenHands 部署在服务器上，通过 FastAPI 暴露接口。
Claude Code 是给你用的工具；OpenHands 是你雇佣的、随时待命的员工。
🐵
小提示：FastAPI 的服务地址后加/docs就是文档了
02 业务视角：从 刷视频 到「数据入库」的闭环
对于做出海营销和短视频矩阵的朋友，拆解爆款是每天的必修课。
传统的流程极其反人类：
1. 手机刷到视频，点收藏。
2. 晚上回家打开电脑，把链接导出来。
3. 找第三方工具去水印下载。
4. 把视频传给 Gemini 分析。
5. 人工把分析结果复制粘贴到 Excel 或飞书。
这个链路太长，断点太多。任何需要延迟满足的流程，最终都会变成不了了之。
我的远程 Skills 方案，把这个流程压缩到了极致。
整个逻辑是这样的：
Image
用户端（前端）
利用 iOS 自带的快捷指令 + 背部轻点功能。
动作：获取剪贴板内容（TikTok 链接）。
触发：发送 HTTP POST 请求给我的服务器。
反馈：手机震动一下，表示任务已接收。
Image
Image
服务端（后端）
OpenHands 接收到请求后，自主执行以下 Skills：
1. Playwright Skill：
启动无头浏览器。这里有一个技术难点，TikTok 的反爬虫机制非常严格。如果用普通的 request 请求，成功率几乎为零。OpenHands 调用 Playwright 模拟真实浏览器行为，绕过 blob 协议，抓取真实的 MP4 视频流。这种方式的下载成功率稳定在 70%-80%
2. Gemini Skill：
视频下载后，调用Gemini 2.5 Flash，快且便宜。它不只是看，它是理解。它可以识别拍摄角度（俯拍/特写）、运镜方式（推拉摇移）、BGM 节奏点、色彩心理学。
3. Feishu Skill：
将清洗好的结构化数据（JSON），通过 API 写入飞书多维表格。
结果：
当你刷完半小时视频，打开飞书，几十个爆款视频的深度分析报告已经整整齐齐躺在那里了。
这才是 AI 赋能业务的本质：隐形化。
Image
Openhands 的 Skills 文档：
docs.openhands.dev
03 举一反三：跨境电商的远程 Skills 玩法
这套架构的核心逻辑是：移动端触发 -> 服务端 API -> OpenHands 执行复杂 Skills -> 结果回传。
这个逻辑在出海业务里有无限的延展性。
我给几个具体的场景，你们可以拿去直接落地。
场景一：竞品独立站监控
动作：在手机浏览器看到竞品的 Shopify 店铺，复制链接，触发 Shortcut。
Skills：OpenHands 调起爬虫 Skill 扫描该站点的新品上架情况、价格策略，并调用 SEO Skill 分析其关键词布局。
产出：一份竞品分析简报直接推送到你的 Slack 或 钉钉。
场景二：亚马逊差评自动预警与回复草稿
动作：系统监控到差评（自动触发，无需人工）。
Skills：OpenHands 读取差评内容，结合历史客服知识库 Skill，分析用户情绪，并模仿金牌客服的语气撰写 3 个版本的回复邮件。
产出：草稿进入审核流，你只需要在手机上点批准。
场景三：广告素材批量生产
动作：上传一张产品图到指定文件夹。
Skills：OpenHands 识别产品特征，调用 Midjourney 或 Runway 的 API，结合当下的流行趋势 Skill，自动生成 10 种不同风格的广告背景图。
产出：素材自动同步到 Google Drive 供投放团队筛选。
04 为什么非要用 Agent Skills？写个 Python 脚本不行吗？
这是很多技术出身的朋友最容易陷入的误区。
你这个功能，我写个 Python 脚本 + 定时任务也能跑，为什么要搞这么复杂的 OpenHands Skills？
因为业务逻辑是流动的，而脚本是僵死的。
如果你写死了一个 Python 脚本：
当 TikTok 的前端代码更新了 class 名，脚本报错，你得去修。
当飞书的 API 接口变动，脚本报错，你得去修。
当 Gemini 的模型参数调整，脚本报错，你得去修。
但在 OpenHands Skills 的架构下，我们定义的不是步骤，而是目标。
在我的 Skill 定义里，我告诉 OpenHands：你的任务是下载这个页面上的视频，如果常规方法失败，尝试模拟用户滚动；如果还失败，检查是否有验证码并尝试通过。
OpenHands 作为一个 Agent，它具备自主决策和自我修复的能力。
它发现 TikTok 改了页面结构？它会尝试用视觉识别去定位播放按钮。
它发现 API 报错？它会自主查阅文档或尝试备用节点。
在跨境出海这种平台规则朝令夕改的环境下，维护脚本的成本极高。
我们需要的是一个能够理解意图并自主寻找路径的智能体。
05 思路打开，Agentic Skills 的高级玩法
文章到这里，这套远程 Skills 系统的雏形已经搭建完毕。
但如果你觉得这就结束了，那你就小看了 Agentic Skills 的天花板。
我们现在的架构是“一个请求触发一个 Skill”，但这只是冰山一角。真正的威力在于 Multi-Skill Orchestration（多技能编排）。
1. Skill Chain（技能链）与递归调用
OpenHands 的 Skill 本质是可执行的逻辑单元。我们可以像写代码一样，让 Skill A 去调用 Skill B。
比如定义一个 Base-Skill：只负责做基础的数据清洗。
再定义一个 Pro-Skill：先调用 Base-Skill 处理数据，再把结果传给 Analysis-Skill，最后调用 Report-Skill 生成报告。
你可以构建一个自我迭代的 Agent。让它先写一段代码（Coding Skill），然后自己运行测试（Testing Skill），如果报错，递归调用 Coding Skill 进行修复，直到测试通过。
2. 混合云架构（Hybrid Agent Architecture）
OpenHands 运行在 Docker 里，这意味着它可以部署在任何地方。
私有化部署：对于涉及公司财务、用户隐私的数据，你可以把 OpenHands 部署在公司内网服务器上。
公有云调用：对于需要访问外网（如 TikTok 下载、竞品分析）的任务，部署在 AWS 或 Vercel 上。
这样，通过 API 网关，你可以指挥内网的 Agent 去调用外网的 Agent，实现数据在安全域和互联网域之间的智能流转。
3. “人机回环”的异步交互
谁说 API 只有“请求-响应”这一种模式？ 在我的系统中，有些复杂任务（如竞品深度调研）可能需要运行 30 分钟。
流程设计：OpenHands 接收任务 -> 立即返回 TaskID -> 后台异步执行。
关键点：当 Agent 遇到无法决策的卡点（例如：这个验证码我解不开，或者这个竞品网站有两套价格体系，取哪套？），它可以主动通过飞书/Slack 给你发消息请求确认。
你点击确认后，Agent 继续执行。这才是真正的人机协作：AI 处理海量冗余信息，人类只在关键节点做决策。
在这个体系下，Skills 不再是静态的脚本，而是可生长、可组合的原子能力。
未来，你的个人服务器里可能运行着上百个这样的 Skills。它们是一群田螺姑娘，在你睡觉的时候，帮你监控市场、回复邮件、整理知识、优化代码。
而你，只需要握着手机，轻轻敲两下背部，就像魔法师挥动了魔杖。
这，才是 Agent 时代的真正玩法。
但我观察了一圈，发现大家都在陷入一种“开发者的自嗨”。
绝大多数 Skills 的应用场景都被死死锁在 IDE 里，锁在开发者的电脑前。
这叫开发提效，不叫业务提效。
真正的业务发生在移动端，发生在你通勤、吃饭、甚至躺在床上刷 TikTok 的时候。
如果你的 AI 能力必须打开电脑、输入命令行才能调用，那它的时空效率就是零。
于是我抛弃本地的 Claude Code，基于 OpenHands 做了一套云端 Skills 系统。
效果极其简单粗暴：
我在刷 TikTok，看到一个爆款视频，点击复制链接，敲击 iPhone 背面三下。
wxv_4355007050494509070
20 秒后，我的飞书多维表格里自动新增了一行数据。
Image
这行数据包含了：这个视频的无水印文件、Gemini 拆解的镜头语言分析、爆款原因推导，以及一套可直接复用的 AI 视频生成提示词。
全过程我不需要打开电脑，不需要切换 APP，不需要等待。
这就是我今天要聊的：如何用 OpenHands + Skills + iOS 快捷指令，构建一套真正落地的业务自动化系统。
01 为什么 Claude Code 在业务侧是伪需求
先厘清两个概念：OpenHands 和 Claude Code。
Claude Code 是 Anthropic 官方推出的命令行工具，它是一个嵌入在你本地终端里的结对程序员。它的 Skills 本质是上下文记忆和本地工具接口。
它的优势是懂你的代码规范，能直接改你电脑里的文件。
但它有一个对于业务场景的致命弱点：它必须依附于你的会话，你不在，它就不动。
它是一个副驾驶（Copilot）。
而 OpenHands（前身 OpenDevin）是一个开源的、自主的 AI 软件工程师。它运行在 Docker 容器里，是一个独立的服务端 Agent。
Image
openhands.dev
它是一个可以被封装成 API 服务的数字员工。
我看重 OpenHands 的核心理由只有一个：它可以 24 小时在线，并且可以通过 API 远程唤醒。
我做的这个 TikTok 分析系统，本质就是把 OpenHands 部署在服务器上，通过 FastAPI 暴露接口。
Claude Code 是给你用的工具；OpenHands 是你雇佣的、随时待命的员工。
🐵
小提示：FastAPI 的服务地址后加/docs就是文档了
02 业务视角：从 刷视频 到「数据入库」的闭环
对于做出海营销和短视频矩阵的朋友，拆解爆款是每天的必修课。
传统的流程极其反人类：
1. 手机刷到视频，点收藏。
2. 晚上回家打开电脑，把链接导出来。
3. 找第三方工具去水印下载。
4. 把视频传给 Gemini 分析。
5. 人工把分析结果复制粘贴到 Excel 或飞书。
这个链路太长，断点太多。任何需要延迟满足的流程，最终都会变成不了了之。
我的远程 Skills 方案，把这个流程压缩到了极致。
整个逻辑是这样的：
Image
用户端（前端）
利用 iOS 自带的快捷指令 + 背部轻点功能。
动作：获取剪贴板内容（TikTok 链接）。
触发：发送 HTTP POST 请求给我的服务器。
反馈：手机震动一下，表示任务已接收。
Image
Image
服务端（后端）
OpenHands 接收到请求后，自主执行以下 Skills：
1. Playwright Skill：
启动无头浏览器。这里有一个技术难点，TikTok 的反爬虫机制非常严格。如果用普通的 request 请求，成功率几乎为零。OpenHands 调用 Playwright 模拟真实浏览器行为，绕过 blob 协议，抓取真实的 MP4 视频流。这种方式的下载成功率稳定在 70%-80%
2. Gemini Skill：
视频下载后，调用Gemini 2.5 Flash，快且便宜。它不只是看，它是理解。它可以识别拍摄角度（俯拍/特写）、运镜方式（推拉摇移）、BGM 节奏点、色彩心理学。
3. Feishu Skill：
将清洗好的结构化数据（JSON），通过 API 写入飞书多维表格。
结果：
当你刷完半小时视频，打开飞书，几十个爆款视频的深度分析报告已经整整齐齐躺在那里了。
这才是 AI 赋能业务的本质：隐形化。
Image
Openhands 的 Skills 文档：
docs.openhands.dev
03 举一反三：跨境电商的远程 Skills 玩法
这套架构的核心逻辑是：移动端触发 -> 服务端 API -> OpenHands 执行复杂 Skills -> 结果回传。
这个逻辑在出海业务里有无限的延展性。
我给几个具体的场景，你们可以拿去直接落地。
场景一：竞品独立站监控
动作：在手机浏览器看到竞品的 Shopify 店铺，复制链接，触发 Shortcut。
Skills：OpenHands 调起爬虫 Skill 扫描该站点的新品上架情况、价格策略，并调用 SEO Skill 分析其关键词布局。
产出：一份竞品分析简报直接推送到你的 Slack 或 钉钉。
场景二：亚马逊差评自动预警与回复草稿
动作：系统监控到差评（自动触发，无需人工）。
Skills：OpenHands 读取差评内容，结合历史客服知识库 Skill，分析用户情绪，并模仿金牌客服的语气撰写 3 个版本的回复邮件。
产出：草稿进入审核流，你只需要在手机上点批准。
场景三：广告素材批量生产
动作：上传一张产品图到指定文件夹。
Skills：OpenHands 识别产品特征，调用 Midjourney 或 Runway 的 API，结合当下的流行趋势 Skill，自动生成 10 种不同风格的广告背景图。
产出：素材自动同步到 Google Drive 供投放团队筛选。
04 为什么非要用 Agent Skills？写个 Python 脚本不行吗？
这是很多技术出身的朋友最容易陷入的误区。
你这个功能，我写个 Python 脚本 + 定时任务也能跑，为什么要搞这么复杂的 OpenHands Skills？
因为业务逻辑是流动的，而脚本是僵死的。
如果你写死了一个 Python 脚本：
当 TikTok 的前端代码更新了 class 名，脚本报错，你得去修。
当飞书的 API 接口变动，脚本报错，你得去修。
当 Gemini 的模型参数调整，脚本报错，你得去修。
但在 OpenHands Skills 的架构下，我们定义的不是步骤，而是目标。
在我的 Skill 定义里，我告诉 OpenHands：你的任务是下载这个页面上的视频，如果常规方法失败，尝试模拟用户滚动；如果还失败，检查是否有验证码并尝试通过。
OpenHands 作为一个 Agent，它具备自主决策和自我修复的能力。
它发现 TikTok 改了页面结构？它会尝试用视觉识别去定位播放按钮。
它发现 API 报错？它会自主查阅文档或尝试备用节点。
在跨境出海这种平台规则朝令夕改的环境下，维护脚本的成本极高。
我们需要的是一个能够理解意图并自主寻找路径的智能体。
05 思路打开，Agentic Skills 的高级玩法
文章到这里，这套远程 Skills 系统的雏形已经搭建完毕。
但如果你觉得这就结束了，那你就小看了 Agentic Skills 的天花板。
我们现在的架构是“一个请求触发一个 Skill”，但这只是冰山一角。真正的威力在于 Multi-Skill Orchestration（多技能编排）。
1. Skill Chain（技能链）与递归调用
OpenHands 的 Skill 本质是可执行的逻辑单元。我们可以像写代码一样，让 Skill A 去调用 Skill B。
比如定义一个 Base-Skill：只负责做基础的数据清洗。
再定义一个 Pro-Skill：先调用 Base-Skill 处理数据，再把结果传给 Analysis-Skill，最后调用 Report-Skill 生成报告。
你可以构建一个自我迭代的 Agent。让它先写一段代码（Coding Skill），然后自己运行测试（Testing Skill），如果报错，递归调用 Coding Skill 进行修复，直到测试通过。
2. 混合云架构（Hybrid Agent Architecture）
OpenHands 运行在 Docker 里，这意味着它可以部署在任何地方。
私有化部署：对于涉及公司财务、用户隐私的数据，你可以把 OpenHands 部署在公司内网服务器上。
公有云调用：对于需要访问外网（如 TikTok 下载、竞品分析）的任务，部署在 AWS 或 Vercel 上。
这样，通过 API 网关，你可以指挥内网的 Agent 去调用外网的 Agent，实现数据在安全域和互联网域之间的智能流转。
3. “人机回环”的异步交互
谁说 API 只有“请求-响应”这一种模式？ 在我的系统中，有些复杂任务（如竞品深度调研）可能需要运行 30 分钟。
流程设计：OpenHands 接收任务 -> 立即返回 TaskID -> 后台异步执行。
关键点：当 Agent 遇到无法决策的卡点（例如：这个验证码我解不开，或者这个竞品网站有两套价格体系，取哪套？），它可以主动通过飞书/Slack 给你发消息请求确认。
你点击确认后，Agent 继续执行。这才是真正的人机协作：AI 处理海量冗余信息，人类只在关键节点做决策。
在这个体系下，Skills 不再是静态的脚本，而是可生长、可组合的原子能力。
未来，你的个人服务器里可能运行着上百个这样的 Skills。它们是一群田螺姑娘，在你睡觉的时候，帮你监控市场、回复邮件、整理知识、优化代码。
而你，只需要握着手机，轻轻敲两下背部，就像魔法师挥动了魔杖。
这，才是 Agent 时代的真正玩法。
5 02
我是AI卷王饼干哥哥。
最近我在社群里发现一个极度割裂的现象：
一边是看着Sora 2生成的电影级视频、Claude写出的复杂系统惊叹不已，焦虑得睡不着觉；
另一边是想学AI却不知道从哪下手的迷茫。
图片
当我建议从提示词开始入手时，很多新朋友却告诉我：一些博主说提示词工程已死，现在AI理解力这么强，像人一样随便聊聊不就行了吗？
听到这里，我整个人是懵的。
确实，现在的模型能听懂人话，但听懂和能干活完全是两个维度的概念。
你随便聊聊，它就给你随便回回。
想让Cursor写出的代码没有逻辑死循环、让Veo生成的视频镜头不乱晃、让数据分析出的结论不是一本正经的胡说八道，靠随便聊聊绝无可能。
甚至可以说，模型越强大，对提示词精度的要求反而越高。因为强模型的发散性更强，如果你不懂得用结构化的指令去约束它的边界、定义它的路径，它的聪明只会变成不可控的幻觉。
无论技术怎么迭代，AI的底层逻辑依然是提示词驱动。
所以在2026年，想真正掌控AI而不是被AI糊弄，第一件事依然是死磕提示词。
这最有价值，也最见功力。
之前我写过一些不同场景下的提示词方案。
有通用做HTML、SVG的：
AI做SVG的终极方案，一套提示词模板无痛搞定：小红书知识卡片、数据可视化图表、原型图、动态图……
AI做HTML的终极方案，一套提示词模板搞定所有应用：PPT、简历、高保真原型图、知识卡片、动态交互组件等
有专门用于生图、生视频的：
Awesome Nano Banana！迄今最强生图模型的28个玩法合集 | 附提示词
最强视频模型S2上线Lovart，总结了9大实战技巧
VEO 3.1 正面硬刚Sora 2！我扒了 5 个极限场景，Sora竟然输麻了？
有专门用于做数据分析、用户洞察、财报的：
7000字深度对比Claude4、Kimi k2和云听AI，谁才能真正在商业洞察落地？
9000字落地实操：AI做用户购后评论洞察分析
AI做财报分析、行业分析的5大步骤与11个提示词
但老实说，作为日常左右开弓卷自己的AI博主，我觉得这些提示词还有很大的提升空间
所以我重新整理了一个更全、更专业的提示词技巧。
划分成了10个场景，每个场景都有最佳实践的5个技巧，加起来就是50个。
并且整理了官方出版的各种提示词教程合集，加起来上百个。
按饼干哥哥量大管饱惯例，这些完全免费获取。
接下来说下节选一些场景，讲一下痛点和常见问题在哪。
场景一：AI生视频 (Video Generation)
为什么视频生成这么难？
视频生成模型本质上不是在生成图像，而是在模拟物理世界的时间切片。
大多数人在视频生成上受挫，核心原因是用 静态思维 去驱动 动态模型。在文生图 MJ/SD 时代，你只需要描述画面里有什么；但在视频生成时代，如果你只描述画面，模型就必须对 时间维度 和 物理规律 进行全量幻觉补全。
这会导致三个最常见的痛点：
1. 动态坍塌：画面是动的，但主体像幻灯片平移，或者背景不动只有嘴动，缺乏物理惯性。
2. 语义漂移：视频前 2 秒是男人，后 2 秒变成了女人，或者衣服颜色随光影变化而改变。
3. 镜头失控：想要推镜头（Dolly In），模型却生成了主体变大（Scale Up），导致空间透视关系崩塌。
因此，视频提示词的核心逻辑必须从 画面描述 升级为 状态控制指令。你必须显式定义 主体、动作、运镜、光影、物理属性 这五个维度的参数。
最佳实践与技巧
在 Veo 3.1 和 Sora 2 的高频讨论中，被验证最有效的提示词结构并非自然语言长句，而是 分层结构化指令。
1. 通用七层结构框架 (The 7-Layer Structure)
2. 运镜控制的标准化术语
3. 物理与动态的描述技巧
4. 结构化 JSON Prompting (进阶)
5. 负向提示词 (Negative Prompts)
场景二：AI 生图 (Image Generation)
为什么生图总是要抽卡？
现在的生图模型（如 Flux, Midjourney V6, Nano Banana）虽然画质极高，但在精准控制上依然存在巨大痛点。
核心问题在于模型对 自然语言的非结构化理解 与 像素生成的空间逻辑 之间存在断层。大多数用户习惯堆砌形容词（High quality, 8k, beautiful），导致三个典型问题：
1. 语义溢出 (Semantic Bleeding)：你写“蓝色的帽子和红色的鞋”，结果生成了红色的帽子。模型无法将颜色属性精准绑定到特定物体上。
2. 一致性丢失 (Identity Loss)：生成了一张完美的人像，微调提示词想换个背景，结果脸变了。
3. 指令混淆 (Instruction Confusion)：尤其在 Nano Banana 这类支持图像编辑的模型中，用户分不清是在“描述新画面”还是在“下达修改指令”，导致模型只生成了新图而忽略了原图约束。
因此，最佳实践的核心是从 标签堆砌 转向 分层构建 与 工单式指令。
最佳实践与框架
基于 Nano Banana 和 Flux 的最新讨论，以下四种提示词策略被验证为最高效的工业级写法。
1. 编辑模型的“工单式”提示词 (The Work-Order Protocol)
2. 摄影分层结构 (The S-E-L-C Framework)
3. 结构化反向工程 (The Reverse-Engineering JSON)
4. 证件照/规范图的“约束前置” (Constraint-First Prompting)
场景三：AI 编程 (AI Coding / Engineering)
场景四：结构化提示词 (Structured JSON Prompting)
什么是 JSON？它和自然语言写提示词有何本质区别？
JSON (JavaScript Object Notation) 本质上是一种数据交换格式，但在 AI 提示词工程中，它是一种 强制性的思维导图。
自然语言 (Natural Language) 的提示词是线性的流式信息。当你写一段长文时，模型需要自己去拆解哪句话是指令、哪句话是背景、哪句话是约束。这容易导致 注意力分散 或 指令遗忘。
JSON 提示词 则是结构化的键值对信息。它通过 { Key: Value } 的形式，强行将指令拆解为独立的模块。
核心区别对比：
自然语言 (NL)：
请帮我生成一段视频，画面是一个赛博朋克的武士在下雨的东京街头拔刀，镜头要慢动作推近，光线要霓虹感，不要有任何模糊。
缺陷：修饰词容易混淆（霓虹感是修饰街头还是修饰刀？），长难句容易导致模型漏掉“慢动作”这个指令。
结构化提示词 (JSON)：
{
"Subject": "Cyberpunk Samurai",
"Action": "Unsheathing katana",
"Environment": {
"Location": "Tokyo Street",
"Weather": "Heavy Rain"
},
"Camera": "Slow motion, Dolly In",
"Lighting": "Neon ambiance",
"Negative_Prompt": "Blurry, Low resolution"
}
什么场景下最适合用 JSON 写提示词？
并非所有对话都适合用 JSON。在简单的问答中，JSON 会增加 Token 消耗且显得繁琐。但在以下场景中，JSON 是绝对的统治者：
1. 高精度视频生成 (Sora 2 / Veo 3.1)：
如前文所述，视频包含主体、环境、运镜、物理规律等多个维度。用 JSON 可以确保模型不会把“镜头向左移”理解成“主角向左走”。
2. 批量化内容生产 (Programmatic SEO / Ads)：
当你需要生成 1000 条格式统一、但内容不同的广告文案时。你只需要固定 JSON 的结构（Schema），然后用脚本动态替换其中的变量（如产品名），即可保证输出质量的高度一致性。
3. 复杂角色扮演 (Complex Roleplay)：
需要维护复杂的角色状态时。例如：{"Current_Mood": "Angry", "Memory": ["Insulted by user"], "Goal": "Seek revenge"}。用 JSON 显式定义状态，比用自然语言描述“你现在很生气”更稳定。
4. API 对接与工作流自动化 (Agents)：
当提示词是自动化程序的一部分，需要被代码解析时。
最佳实践与注意事项
1. 键名即指令 (Semantic Keys)
2. 伪代码与注释 (Pseudo-code & Comments)
3. 模块化复用 (Modularity)
4. 避免过度嵌套 (Avoid Deep Nesting)
5. 显式定义负向约束 (Negative Constraints within JSON)
场景五：数据分析 (Data Analysis)
场景六：去AI味 (De-AIing / Humanizing)
补充阅读：怎么一眼识别中文、英文内容是AI写的？
场景七：创意写作与角色扮演 (Roleplay & Writing)
场景八：深度调研与搜索 (Deep Research & Search)
场景九：实时语音/对话 (Real-time Voice)
场景十：长期运行与自主智能体 (Long-Running & Autonomous Agents)
本文完整版，关注公众号「饼干哥哥AGI」后台回复「提示词」获取即可。
限制AI上限的，从来不是算力，而是你的逻辑
刷完前面的内容，大家会发现一个残酷事实：
提示词工程，本质上是思维工程。
很多人用不好AI，不是因为不懂技术，而是因为无法清晰地定义问题。
当你脑子里的需求是模糊的一团浆糊时，再强的模型也只能吐给你一堆正确的废话。
我们反复强调结构化、分层、约束、元数据，其实是在逼迫自己把感性的直觉，翻译成理性的工程语言。
未来的分工会非常残酷且清晰：
AI负责极速的执行、穷举和推理，而人类只负责一件事——定义标准。
谁能把模糊的需求定义得越精准，谁就能调用越庞大的算力。
所以，不要去背诵那些所谓的魔法咒语，也不要迷信某种固定的模版。
真正的高手，修练的是把复杂现实问题拆解为机器可执行指令的能力。
当你不再把AI当成一个可以闲聊的网友，而是当成一个需要你用逻辑去编排、去约束、去调试的超级计算集群时，你才算真正跨过了那道门槛。
别让你的思想，成了AI发挥的瓶颈。
最近我在社群里发现一个极度割裂的现象：
一边是看着Sora 2生成的电影级视频、Claude写出的复杂系统惊叹不已，焦虑得睡不着觉；
另一边是想学AI却不知道从哪下手的迷茫。
图片
当我建议从提示词开始入手时，很多新朋友却告诉我：一些博主说提示词工程已死，现在AI理解力这么强，像人一样随便聊聊不就行了吗？
听到这里，我整个人是懵的。
确实，现在的模型能听懂人话，但听懂和能干活完全是两个维度的概念。
你随便聊聊，它就给你随便回回。
想让Cursor写出的代码没有逻辑死循环、让Veo生成的视频镜头不乱晃、让数据分析出的结论不是一本正经的胡说八道，靠随便聊聊绝无可能。
甚至可以说，模型越强大，对提示词精度的要求反而越高。因为强模型的发散性更强，如果你不懂得用结构化的指令去约束它的边界、定义它的路径，它的聪明只会变成不可控的幻觉。
无论技术怎么迭代，AI的底层逻辑依然是提示词驱动。
所以在2026年，想真正掌控AI而不是被AI糊弄，第一件事依然是死磕提示词。
这最有价值，也最见功力。
之前我写过一些不同场景下的提示词方案。
有通用做HTML、SVG的：
AI做SVG的终极方案，一套提示词模板无痛搞定：小红书知识卡片、数据可视化图表、原型图、动态图……
AI做HTML的终极方案，一套提示词模板搞定所有应用：PPT、简历、高保真原型图、知识卡片、动态交互组件等
有专门用于生图、生视频的：
Awesome Nano Banana！迄今最强生图模型的28个玩法合集 | 附提示词
最强视频模型S2上线Lovart，总结了9大实战技巧
VEO 3.1 正面硬刚Sora 2！我扒了 5 个极限场景，Sora竟然输麻了？
有专门用于做数据分析、用户洞察、财报的：
7000字深度对比Claude4、Kimi k2和云听AI，谁才能真正在商业洞察落地？
9000字落地实操：AI做用户购后评论洞察分析
AI做财报分析、行业分析的5大步骤与11个提示词
但老实说，作为日常左右开弓卷自己的AI博主，我觉得这些提示词还有很大的提升空间
所以我重新整理了一个更全、更专业的提示词技巧。
划分成了10个场景，每个场景都有最佳实践的5个技巧，加起来就是50个。
并且整理了官方出版的各种提示词教程合集，加起来上百个。
按饼干哥哥量大管饱惯例，这些完全免费获取。
接下来说下节选一些场景，讲一下痛点和常见问题在哪。
场景一：AI生视频 (Video Generation)
为什么视频生成这么难？
视频生成模型本质上不是在生成图像，而是在模拟物理世界的时间切片。
大多数人在视频生成上受挫，核心原因是用 静态思维 去驱动 动态模型。在文生图 MJ/SD 时代，你只需要描述画面里有什么；但在视频生成时代，如果你只描述画面，模型就必须对 时间维度 和 物理规律 进行全量幻觉补全。
这会导致三个最常见的痛点：
1. 动态坍塌：画面是动的，但主体像幻灯片平移，或者背景不动只有嘴动，缺乏物理惯性。
2. 语义漂移：视频前 2 秒是男人，后 2 秒变成了女人，或者衣服颜色随光影变化而改变。
3. 镜头失控：想要推镜头（Dolly In），模型却生成了主体变大（Scale Up），导致空间透视关系崩塌。
因此，视频提示词的核心逻辑必须从 画面描述 升级为 状态控制指令。你必须显式定义 主体、动作、运镜、光影、物理属性 这五个维度的参数。
最佳实践与技巧
在 Veo 3.1 和 Sora 2 的高频讨论中，被验证最有效的提示词结构并非自然语言长句，而是 分层结构化指令。
1. 通用七层结构框架 (The 7-Layer Structure)
2. 运镜控制的标准化术语
3. 物理与动态的描述技巧
4. 结构化 JSON Prompting (进阶)
5. 负向提示词 (Negative Prompts)
场景二：AI 生图 (Image Generation)
为什么生图总是要抽卡？
现在的生图模型（如 Flux, Midjourney V6, Nano Banana）虽然画质极高，但在精准控制上依然存在巨大痛点。
核心问题在于模型对 自然语言的非结构化理解 与 像素生成的空间逻辑 之间存在断层。大多数用户习惯堆砌形容词（High quality, 8k, beautiful），导致三个典型问题：
1. 语义溢出 (Semantic Bleeding)：你写“蓝色的帽子和红色的鞋”，结果生成了红色的帽子。模型无法将颜色属性精准绑定到特定物体上。
2. 一致性丢失 (Identity Loss)：生成了一张完美的人像，微调提示词想换个背景，结果脸变了。
3. 指令混淆 (Instruction Confusion)：尤其在 Nano Banana 这类支持图像编辑的模型中，用户分不清是在“描述新画面”还是在“下达修改指令”，导致模型只生成了新图而忽略了原图约束。
因此，最佳实践的核心是从 标签堆砌 转向 分层构建 与 工单式指令。
最佳实践与框架
基于 Nano Banana 和 Flux 的最新讨论，以下四种提示词策略被验证为最高效的工业级写法。
1. 编辑模型的“工单式”提示词 (The Work-Order Protocol)
2. 摄影分层结构 (The S-E-L-C Framework)
3. 结构化反向工程 (The Reverse-Engineering JSON)
4. 证件照/规范图的“约束前置” (Constraint-First Prompting)
场景三：AI 编程 (AI Coding / Engineering)
场景四：结构化提示词 (Structured JSON Prompting)
什么是 JSON？它和自然语言写提示词有何本质区别？
JSON (JavaScript Object Notation) 本质上是一种数据交换格式，但在 AI 提示词工程中，它是一种 强制性的思维导图。
自然语言 (Natural Language) 的提示词是线性的流式信息。当你写一段长文时，模型需要自己去拆解哪句话是指令、哪句话是背景、哪句话是约束。这容易导致 注意力分散 或 指令遗忘。
JSON 提示词 则是结构化的键值对信息。它通过 { Key: Value } 的形式，强行将指令拆解为独立的模块。
核心区别对比：
自然语言 (NL)：
请帮我生成一段视频，画面是一个赛博朋克的武士在下雨的东京街头拔刀，镜头要慢动作推近，光线要霓虹感，不要有任何模糊。
缺陷：修饰词容易混淆（霓虹感是修饰街头还是修饰刀？），长难句容易导致模型漏掉“慢动作”这个指令。
结构化提示词 (JSON)：
{
"Subject": "Cyberpunk Samurai",
"Action": "Unsheathing katana",
"Environment": {
"Location": "Tokyo Street",
"Weather": "Heavy Rain"
},
"Camera": "Slow motion, Dolly In",
"Lighting": "Neon ambiance",
"Negative_Prompt": "Blurry, Low resolution"
}
什么场景下最适合用 JSON 写提示词？
并非所有对话都适合用 JSON。在简单的问答中，JSON 会增加 Token 消耗且显得繁琐。但在以下场景中，JSON 是绝对的统治者：
1. 高精度视频生成 (Sora 2 / Veo 3.1)：
如前文所述，视频包含主体、环境、运镜、物理规律等多个维度。用 JSON 可以确保模型不会把“镜头向左移”理解成“主角向左走”。
2. 批量化内容生产 (Programmatic SEO / Ads)：
当你需要生成 1000 条格式统一、但内容不同的广告文案时。你只需要固定 JSON 的结构（Schema），然后用脚本动态替换其中的变量（如产品名），即可保证输出质量的高度一致性。
3. 复杂角色扮演 (Complex Roleplay)：
需要维护复杂的角色状态时。例如：{"Current_Mood": "Angry", "Memory": ["Insulted by user"], "Goal": "Seek revenge"}。用 JSON 显式定义状态，比用自然语言描述“你现在很生气”更稳定。
4. API 对接与工作流自动化 (Agents)：
当提示词是自动化程序的一部分，需要被代码解析时。
最佳实践与注意事项
1. 键名即指令 (Semantic Keys)
2. 伪代码与注释 (Pseudo-code & Comments)
3. 模块化复用 (Modularity)
4. 避免过度嵌套 (Avoid Deep Nesting)
5. 显式定义负向约束 (Negative Constraints within JSON)
场景五：数据分析 (Data Analysis)
场景六：去AI味 (De-AIing / Humanizing)
补充阅读：怎么一眼识别中文、英文内容是AI写的？
场景七：创意写作与角色扮演 (Roleplay & Writing)
场景八：深度调研与搜索 (Deep Research & Search)
场景九：实时语音/对话 (Real-time Voice)
场景十：长期运行与自主智能体 (Long-Running & Autonomous Agents)
本文完整版，关注公众号「饼干哥哥AGI」后台回复「提示词」获取即可。
限制AI上限的，从来不是算力，而是你的逻辑
刷完前面的内容，大家会发现一个残酷事实：
提示词工程，本质上是思维工程。
很多人用不好AI，不是因为不懂技术，而是因为无法清晰地定义问题。
当你脑子里的需求是模糊的一团浆糊时，再强的模型也只能吐给你一堆正确的废话。
我们反复强调结构化、分层、约束、元数据，其实是在逼迫自己把感性的直觉，翻译成理性的工程语言。
未来的分工会非常残酷且清晰：
AI负责极速的执行、穷举和推理，而人类只负责一件事——定义标准。
谁能把模糊的需求定义得越精准，谁就能调用越庞大的算力。
所以，不要去背诵那些所谓的魔法咒语，也不要迷信某种固定的模版。
真正的高手，修练的是把复杂现实问题拆解为机器可执行指令的能力。
当你不再把AI当成一个可以闲聊的网友，而是当成一个需要你用逻辑去编排、去约束、去调试的超级计算集群时，你才算真正跨过了那道门槛。
别让你的思想，成了AI发挥的瓶颈。
2 02
生成引擎正在杀死你的海外流量
一篇论文让我重新思考了品牌出海的底层逻辑
基于《GEO: Generative Engine Optimization》论文
ACM KDD 2024 | 普林斯顿大学 & 印度理工学院
我的困惑
上个月，我遇到了一件特别挫败的事。
我们团队服务的一个跨境电商客户，做了三年的SEO，网站权重稳定，关键词排名也一直在首页。但最近三个月，他们的网站流量开始莫名其妙地下跌，不是断崖式的那种，而是缓慢、持续、让人心慌的下降。
更诡异的是，他们的Google排名几乎没有变化。我检查了所有常规的SEO指标：收录正常，外链稳定，页面速度没问题，内容也在持续更新。一切看起来都很健康，但流量就是不见了。
我开始怀疑是不是竞品加大了投放，或者是市场饱和了。直到有天我用Perplexity.ai搜索他们的核心产品词，看到AI生成的答案时，我才突然意识到：问题不在传统搜索引擎，而在生成引擎。
GEO比SEO更重要
最近读到一篇来自普林斯顿大学和印度理工学院的论文，专门研究生成引擎优化（Generative Engine Optimization）。读完我最大的感受是：我们过去熟悉的流量获取逻辑，正在从根本上被颠覆。
GEO的核心结论很简单：在生成引擎时代，传统的SEO优化正在失效，内容创作者需要全新的优化策略。
论文通过实验证明，使用GEO方法可以将内容在生成引擎响应中的可见性提升最高40%。而这40%的可见性，很可能就是未来品牌出海的生死线。
GEO到底是什么
GEO（Generative Engine Optimization，生成引擎优化）是一套帮助内容创作者优化其内容在生成引擎（如Perplexity.ai、ChatGPT Search、Google SGE等）中可见性的方法论。
与传统SEO不同，GEO面对的是黑盒的、基于大型语言模型的生成引擎。这些引擎不再只是返回链接列表，而是直接生成综合答案，将多个来源的信息融合成一段完整的响应。
GEO的可见性指标
传统SEO用排名衡量可见性，但生成引擎的可见性更复杂。论文提出了几个新的指标：
•词数指标：衡量引用内容在响应中的占比。引用内容越多，可见性越高。
•位置调整词数：考虑引用出现的位置，越靠前的引用权重越高（基于用户注意力衰减规律）。
•主观展示指标：从相关性、影响力、独特性等七个维度评估引用的主观可见性。
这些指标共同构成了GEO的评估体系，也解释了为什么传统SEO在生成引擎时代失效了——因为游戏规则完全不同。
GEO的实战方法
论文测试了九种GEO方法，我挑出了最有实际价值的六种。这些方法通过大型语言模型应用于网站内容，进行特定的风格和内容调整。
表现优异的三种方法
1. 统计数据添加：在内容中加入具体的定量数据而非定性描述。实测效果：位置调整词数指标提升41%。
2. 引文添加：添加来自可信来源的直接引文。实测效果：主观展示指标提升28%。
3. 引用来源：在内容中明确引用可靠来源。实测效果：两种指标均有30%以上提升。
无效的方法
关键词填充：传统SEO的核心手段，在GEO中几乎没有效果，甚至会降低可见性。这个结果让我震惊：我们一直依赖的优化手段，在新范式下不仅无效，还可能有害。
领域特异性：GEO策略要因地制宜
更细的研究发现，不同的GEO方法在不同领域效果差异很大。这意味着，品牌在做海外内容营销时，需要根据目标市场的查询类型，选择不同的GEO策略。
图片
图3：不同领域推荐使用的GEO策略
一个意外的发现：GEO正在 democratize 数字营销
论文有一个发现特别值得所有中小品牌关注：GEO对搜索引擎排名较低的网站帮助更大。
数据显示，排名第五的网站使用GEO方法后，可见性提升了115%；而排名第一的网站，反而可能下降30%。
为什么会这样？传统SEO依赖外链数量、域名权重等因素，这些正是小型创作者难以企及的。但生成引擎主要基于内容本身的质量和相关性，这给了优质内容一个公平竞争的机会。
换句话说，GEO可能是数字营销民主化的一个转折点。小品牌可以通过优质内容在生成引擎中获得与大品牌相近的曝光机会。
SEO vs GEO：可见性逻辑的根本差异
这张图清晰地展示了两者的根本差异：传统SEO连接的是用户与网站，GEO连接的是用户与信息。在生成引擎成为主流信息获取方式的今天，后者显然更符合用户的行为逻辑。
组合策略的威力
单独使用GEO方法已经有不错的效果，但论文发现，组合使用效果更佳。流畅性优化 + 统计数据添加的相对改进达到35.8%，比任何单一策略都要高出5%以上。这意味着，品牌在做内容优化时，应该同时优化多个维度，而不是只关注单一技巧。
真实世界的验证
论文不仅在实验环境中测试，还在Perplexity.ai这个拥有大量真实用户的生成引擎上进行了验证。结果一致：引文添加位置调整词数提升22%，统计数据添加主观展示提升37%，关键词填充比基线差10%。这证明了GEO方法的实际有效性，不是纸上谈兵。
我的反思：品牌出海策略需要重构
读完这篇论文，我回头重新审视了那个流量下滑的客户案例。他们的内容确实在持续更新，但内容策略还是传统的SEO思维：围绕关键词生产内容，注重密度和排名。但在生成引擎看来，这些内容缺乏数据支撑，没有引用来源，也没有权威性引文。
当用户用Perplexity.ai搜索他们的产品词时，AI生成的答案引用了竞品的网站——因为竞品的内容更符合GEO的标准。
问题的根源找到了：我们不是在跟竞品竞争，而是在跟生成引擎的算法逻辑竞争。
未来方向：GEO战略化
这篇论文给我的最大启示是：GEO不是SEO的替代品，而是比SEO更底层、更根本的存在。在品牌出海的过程中，我们需要把GEO战略化。
1. 内容生产流程重构：所有面向海外的内容，都应该经过GEO优化：检查是否有数据支撑、是否有权威引用、是否流畅易读。
2. 多语言GEO策略：论文虽然用英文测试，但GEO的逻辑适用于所有语言。中国品牌做多语言市场时，每个语种都应该有对应的GEO策略。
3. 实时监测生成引擎表现：需要建立新的监测体系，不只是监测关键词排名，还要监测在生成引擎中的引用率和可见性。
4. GEO与产品策略结合：GEO不是营销部门的独立工作，而应该和产品策略结合。产品的数据、特性、用户案例，都应该按照GEO的逻辑来组织和呈现。
生成引擎时代的品牌生存法则
回到开头的那个问题：为什么网站流量在下跌？答案是：用户获取信息的方式变了。他们不再只点击搜索结果，而是越来越多地直接阅读AI生成的答案。如果你的内容没有被AI引用，你就失去了这部分曝光机会。
GEO的本质，是在生成引擎时代重新建立品牌与用户之间的连接。传统SEO连接的是用户与网站，GEO连接的是用户与信息。在生成引擎成为主流信息获取方式的今天，后者显然更符合用户的行为逻辑。
对于做海外市场的中国品牌来说，GEO提供了一个弯道超车的机会。当大家都还在用传统SEO思维做内容时，率先采用GEO策略的品牌，就能在生成引擎中获得先发优势。
这不仅是技术的迭代，更是认知的升级。未来已经来了，只是分布不均。GEO就是未来的一部分。
参考资料
本文提到的论文是《GEO: Generative Engine Optimization》，发表于ACM KDD 2024，由普林斯顿大学、印度理工学院等机构的研究者共同完成。
论文下载：arxiv.org
论文代码和数据已开源，可在 generative-engines.com 查看。
Aggarwal, P., Murahari, V., Rajpurohit, T., et al. (2024). GEO: Generative Engine Optimization. Proceedings of the 30th ACM SIGKDD Conference on Knowledge Discovery and Data Mining (KDD '24), Barcelona, Spain.
一篇论文让我重新思考了品牌出海的底层逻辑
基于《GEO: Generative Engine Optimization》论文
ACM KDD 2024 | 普林斯顿大学 & 印度理工学院
我的困惑
上个月，我遇到了一件特别挫败的事。
我们团队服务的一个跨境电商客户，做了三年的SEO，网站权重稳定，关键词排名也一直在首页。但最近三个月，他们的网站流量开始莫名其妙地下跌，不是断崖式的那种，而是缓慢、持续、让人心慌的下降。
更诡异的是，他们的Google排名几乎没有变化。我检查了所有常规的SEO指标：收录正常，外链稳定，页面速度没问题，内容也在持续更新。一切看起来都很健康，但流量就是不见了。
我开始怀疑是不是竞品加大了投放，或者是市场饱和了。直到有天我用Perplexity.ai搜索他们的核心产品词，看到AI生成的答案时，我才突然意识到：问题不在传统搜索引擎，而在生成引擎。
GEO比SEO更重要
最近读到一篇来自普林斯顿大学和印度理工学院的论文，专门研究生成引擎优化（Generative Engine Optimization）。读完我最大的感受是：我们过去熟悉的流量获取逻辑，正在从根本上被颠覆。
GEO的核心结论很简单：在生成引擎时代，传统的SEO优化正在失效，内容创作者需要全新的优化策略。
论文通过实验证明，使用GEO方法可以将内容在生成引擎响应中的可见性提升最高40%。而这40%的可见性，很可能就是未来品牌出海的生死线。
GEO到底是什么
GEO（Generative Engine Optimization，生成引擎优化）是一套帮助内容创作者优化其内容在生成引擎（如Perplexity.ai、ChatGPT Search、Google SGE等）中可见性的方法论。
与传统SEO不同，GEO面对的是黑盒的、基于大型语言模型的生成引擎。这些引擎不再只是返回链接列表，而是直接生成综合答案，将多个来源的信息融合成一段完整的响应。
GEO的可见性指标
传统SEO用排名衡量可见性，但生成引擎的可见性更复杂。论文提出了几个新的指标：
•词数指标：衡量引用内容在响应中的占比。引用内容越多，可见性越高。
•位置调整词数：考虑引用出现的位置，越靠前的引用权重越高（基于用户注意力衰减规律）。
•主观展示指标：从相关性、影响力、独特性等七个维度评估引用的主观可见性。
这些指标共同构成了GEO的评估体系，也解释了为什么传统SEO在生成引擎时代失效了——因为游戏规则完全不同。
GEO的实战方法
论文测试了九种GEO方法，我挑出了最有实际价值的六种。这些方法通过大型语言模型应用于网站内容，进行特定的风格和内容调整。
表现优异的三种方法
1. 统计数据添加：在内容中加入具体的定量数据而非定性描述。实测效果：位置调整词数指标提升41%。
2. 引文添加：添加来自可信来源的直接引文。实测效果：主观展示指标提升28%。
3. 引用来源：在内容中明确引用可靠来源。实测效果：两种指标均有30%以上提升。
无效的方法
关键词填充：传统SEO的核心手段，在GEO中几乎没有效果，甚至会降低可见性。这个结果让我震惊：我们一直依赖的优化手段，在新范式下不仅无效，还可能有害。
领域特异性：GEO策略要因地制宜
更细的研究发现，不同的GEO方法在不同领域效果差异很大。这意味着，品牌在做海外内容营销时，需要根据目标市场的查询类型，选择不同的GEO策略。
图片
图3：不同领域推荐使用的GEO策略
一个意外的发现：GEO正在 democratize 数字营销
论文有一个发现特别值得所有中小品牌关注：GEO对搜索引擎排名较低的网站帮助更大。
数据显示，排名第五的网站使用GEO方法后，可见性提升了115%；而排名第一的网站，反而可能下降30%。
为什么会这样？传统SEO依赖外链数量、域名权重等因素，这些正是小型创作者难以企及的。但生成引擎主要基于内容本身的质量和相关性，这给了优质内容一个公平竞争的机会。
换句话说，GEO可能是数字营销民主化的一个转折点。小品牌可以通过优质内容在生成引擎中获得与大品牌相近的曝光机会。
SEO vs GEO：可见性逻辑的根本差异
这张图清晰地展示了两者的根本差异：传统SEO连接的是用户与网站，GEO连接的是用户与信息。在生成引擎成为主流信息获取方式的今天，后者显然更符合用户的行为逻辑。
组合策略的威力
单独使用GEO方法已经有不错的效果，但论文发现，组合使用效果更佳。流畅性优化 + 统计数据添加的相对改进达到35.8%，比任何单一策略都要高出5%以上。这意味着，品牌在做内容优化时，应该同时优化多个维度，而不是只关注单一技巧。
真实世界的验证
论文不仅在实验环境中测试，还在Perplexity.ai这个拥有大量真实用户的生成引擎上进行了验证。结果一致：引文添加位置调整词数提升22%，统计数据添加主观展示提升37%，关键词填充比基线差10%。这证明了GEO方法的实际有效性，不是纸上谈兵。
我的反思：品牌出海策略需要重构
读完这篇论文，我回头重新审视了那个流量下滑的客户案例。他们的内容确实在持续更新，但内容策略还是传统的SEO思维：围绕关键词生产内容，注重密度和排名。但在生成引擎看来，这些内容缺乏数据支撑，没有引用来源，也没有权威性引文。
当用户用Perplexity.ai搜索他们的产品词时，AI生成的答案引用了竞品的网站——因为竞品的内容更符合GEO的标准。
问题的根源找到了：我们不是在跟竞品竞争，而是在跟生成引擎的算法逻辑竞争。
未来方向：GEO战略化
这篇论文给我的最大启示是：GEO不是SEO的替代品，而是比SEO更底层、更根本的存在。在品牌出海的过程中，我们需要把GEO战略化。
1. 内容生产流程重构：所有面向海外的内容，都应该经过GEO优化：检查是否有数据支撑、是否有权威引用、是否流畅易读。
2. 多语言GEO策略：论文虽然用英文测试，但GEO的逻辑适用于所有语言。中国品牌做多语言市场时，每个语种都应该有对应的GEO策略。
3. 实时监测生成引擎表现：需要建立新的监测体系，不只是监测关键词排名，还要监测在生成引擎中的引用率和可见性。
4. GEO与产品策略结合：GEO不是营销部门的独立工作，而应该和产品策略结合。产品的数据、特性、用户案例，都应该按照GEO的逻辑来组织和呈现。
生成引擎时代的品牌生存法则
回到开头的那个问题：为什么网站流量在下跌？答案是：用户获取信息的方式变了。他们不再只点击搜索结果，而是越来越多地直接阅读AI生成的答案。如果你的内容没有被AI引用，你就失去了这部分曝光机会。
GEO的本质，是在生成引擎时代重新建立品牌与用户之间的连接。传统SEO连接的是用户与网站，GEO连接的是用户与信息。在生成引擎成为主流信息获取方式的今天，后者显然更符合用户的行为逻辑。
对于做海外市场的中国品牌来说，GEO提供了一个弯道超车的机会。当大家都还在用传统SEO思维做内容时，率先采用GEO策略的品牌，就能在生成引擎中获得先发优势。
这不仅是技术的迭代，更是认知的升级。未来已经来了，只是分布不均。GEO就是未来的一部分。
参考资料
本文提到的论文是《GEO: Generative Engine Optimization》，发表于ACM KDD 2024，由普林斯顿大学、印度理工学院等机构的研究者共同完成。
论文下载：arxiv.org
论文代码和数据已开源，可在 generative-engines.com 查看。
Aggarwal, P., Murahari, V., Rajpurohit, T., et al. (2024). GEO: Generative Engine Optimization. Proceedings of the 30th ACM SIGKDD Conference on Knowledge Discovery and Data Mining (KDD '24), Barcelona, Spain.
1 02
如果我们把这两个月国内部分自媒体和社群里的碎片信息拼凑起来，Manus 这家公司大概长这样：产品垃圾、服务不稳定、拿了融资就跑路、创始人背叛、在新加坡裁员快倒闭了。
但就在昨天，Meta（Facebook）正式宣布收购 Manus。据华尔街日报报道，价格超过 20 亿美元（约 145 亿人民币）。
一家在舆论口中“快不行了”的公司，真的能骗过 Meta 的尽调团队，让他们掏出 100 多亿真金白银吗？
显然，这里面有巨大的信息差。
今天这事被刷屏，让我想起不久前写过的Base44。当时那个独立开发者项目，一个人干了 6 个月做到 8000 万被 Wix 收购。我当时觉得那已经是 2025 年 AI 创业者的天花板了。
没想到Manus更狠。直接把天花板顶到了百亿级别。
为了搞清楚发生了什么，我带着大家先看一遍 Manus 今年到底经历了什么？
3月，Manus 在 X 和 YouTube 上爆火，主打通用 Agent，排队名单一度到了 200 万。
但到了 7月，风评急转直下。因为合规和融资受阻，Manus 决定把总部和核心技术团队搬去新加坡，同时裁撤国内非核心业务。那时候，“跑路”、“药丸”的声音在国内此起彼伏。
接下来的几个月，国内几乎没人再提它。
直到 10月，Manus 发布 1.5 版本，产品口碑在海外开始逆转；12月，官方披露 ARR（年度经常性收入）突破 1 亿美元。
紧接着，就是今天的百亿收购。
骂归骂，钱是真收到了，事是真做成了。
发现没有，Manus 在国内和海外完全是两种评价体系。
很多人分析 Manus 赢在技术、赢在 Benchmark 的融资背书。但我复盘了它大半年的数据，发现 Reddit 社区是它翻盘的关键战场。
前天在国内 5 万人的头部 AI 社群线下行动家大会上，我正好分享了 Reddit 在 AI 出海营销中的玩法。
我不说Manus是靠 Reddit 起死回生的，但在它从“被骂”到“百亿收购”的过程中，Reddit 绝对是它做增长、洗口碑、拿数据的核心阵地。
我花时间扒了 Manus 在 Reddit 上这一年的所有关键操作，总结出了一套很清晰的打法。
下面拆开给你们看。
第一阶段：用“稀缺”换“声量”（3月-4月）
Manus 刚开始做的时候，搞了非常严格的邀请码机制。
这招在国内很容易被骂“饥饿营销”、“耍猴”。但在 Reddit 上，稀缺就是社交货币。
当时 Reddit 上出现了大量“求邀请码”、“谁有码”的帖子。这种 FOMO（错失恐惧）情绪，让产品在早期不稳定的情况下，依然维持了极高的讨论热度。大家关注的焦点是“我也要进去看看”，而不是盯着早期的 Bug 喷。
这为他们争取了宝贵的迭代时间。
早期用户问大家想拿来干嘛
第二阶段：直面争议，把客服做成营销（5月-7月）
到了中期，问题来了。用户开始抱怨 Credits（积分）烧得太快、价格太贵、退款慢。
这时候 Manus 做对了一件事：不装死。
他们在 Reddit 上建立了统一的 Support 渠道，官方人员直接在帖子里回复，甚至公开承认“现阶段确实耗积分，我们在改”。
海外用户不怕产品有缺陷，怕官方消失。Manus 通过在 Reddit 上高频互动，把“诈骗疑云”慢慢转化成了“早期产品的阵痛”。
用户客诉
第三阶段：把积分当钱用，购买用户内容（8月-12月）
这是他们整个营销里最关键的一步，也是直接拉升 ARR 的核心手段。
从 8 月开始，Manus 在 Reddit 上搞了多轮“发 Case 赢积分”的活动。
逻辑很简单：你发一个用 Manus 完成任务的帖子，我给你 1000 Credits；如果你是 Top 5，我给你 3 万 Credits。
最新一轮活动
这根本不是简单的征文比赛。
对于 AI Agent 类产品，算力成本很高。用户如果不付费，很难持续用下去。Manus 很聪明，它不需要花真金白银去 Facebook 投广告，而是用自家产品的“虚拟货币（积分）”，雇佣了成千上万的用户在 Reddit 上帮它写软文、做演示。
到了 12 月，也就是收购前夕，Reddit 上已经铺天盖地全是用户夸它的长文案例。
这些内容，带来了两个结果：
1. 极大地降低了获客成本（CAC）。
2. 给 Meta 的尽调团队展示了最真实的“民意”和活跃度。
这才是 1 亿美元 ARR 背后真正的推手。
最后，说点商业层面的思考。
今天，Manus 被收购，刚好智谱 AI 也在香港成功上市。
这标志着 2026 年将是 AI 产品的“大航海时代”。
同时，不管你是做大模型还是做应用，出海不再是备选项，是必选项。
回到开头。如果 Manus 当时选择留在国内，还在应对无休止的合规审查和舆论口水战，可能早就凉了。他们选择了断臂求生，搬去新加坡，死磕海外社区。
有时候，选择比努力重要。在一个不承认你价值的地方死磕，不如换一片承认你价值的海域。
Manus 在 Reddit 上的这套打法——从冷启动制造稀缺，到建立信任，再到用积分激励构建内容飞轮，其实有一套完整的 SOP。
如果你也想在 2026 年把产品卖给外国人，不管是做 Reddit 运营还是整体出海营销，可以来找我聊聊。
但就在昨天，Meta（Facebook）正式宣布收购 Manus。据华尔街日报报道，价格超过 20 亿美元（约 145 亿人民币）。
一家在舆论口中“快不行了”的公司，真的能骗过 Meta 的尽调团队，让他们掏出 100 多亿真金白银吗？
显然，这里面有巨大的信息差。
今天这事被刷屏，让我想起不久前写过的Base44。当时那个独立开发者项目，一个人干了 6 个月做到 8000 万被 Wix 收购。我当时觉得那已经是 2025 年 AI 创业者的天花板了。
没想到Manus更狠。直接把天花板顶到了百亿级别。
为了搞清楚发生了什么，我带着大家先看一遍 Manus 今年到底经历了什么？
3月，Manus 在 X 和 YouTube 上爆火，主打通用 Agent，排队名单一度到了 200 万。
但到了 7月，风评急转直下。因为合规和融资受阻，Manus 决定把总部和核心技术团队搬去新加坡，同时裁撤国内非核心业务。那时候，“跑路”、“药丸”的声音在国内此起彼伏。
接下来的几个月，国内几乎没人再提它。
直到 10月，Manus 发布 1.5 版本，产品口碑在海外开始逆转；12月，官方披露 ARR（年度经常性收入）突破 1 亿美元。
紧接着，就是今天的百亿收购。
骂归骂，钱是真收到了，事是真做成了。
发现没有，Manus 在国内和海外完全是两种评价体系。
很多人分析 Manus 赢在技术、赢在 Benchmark 的融资背书。但我复盘了它大半年的数据，发现 Reddit 社区是它翻盘的关键战场。
前天在国内 5 万人的头部 AI 社群线下行动家大会上，我正好分享了 Reddit 在 AI 出海营销中的玩法。
我不说Manus是靠 Reddit 起死回生的，但在它从“被骂”到“百亿收购”的过程中，Reddit 绝对是它做增长、洗口碑、拿数据的核心阵地。
我花时间扒了 Manus 在 Reddit 上这一年的所有关键操作，总结出了一套很清晰的打法。
下面拆开给你们看。
第一阶段：用“稀缺”换“声量”（3月-4月）
Manus 刚开始做的时候，搞了非常严格的邀请码机制。
这招在国内很容易被骂“饥饿营销”、“耍猴”。但在 Reddit 上，稀缺就是社交货币。
当时 Reddit 上出现了大量“求邀请码”、“谁有码”的帖子。这种 FOMO（错失恐惧）情绪，让产品在早期不稳定的情况下，依然维持了极高的讨论热度。大家关注的焦点是“我也要进去看看”，而不是盯着早期的 Bug 喷。
这为他们争取了宝贵的迭代时间。
早期用户问大家想拿来干嘛
第二阶段：直面争议，把客服做成营销（5月-7月）
到了中期，问题来了。用户开始抱怨 Credits（积分）烧得太快、价格太贵、退款慢。
这时候 Manus 做对了一件事：不装死。
他们在 Reddit 上建立了统一的 Support 渠道，官方人员直接在帖子里回复，甚至公开承认“现阶段确实耗积分，我们在改”。
海外用户不怕产品有缺陷，怕官方消失。Manus 通过在 Reddit 上高频互动，把“诈骗疑云”慢慢转化成了“早期产品的阵痛”。
用户客诉
第三阶段：把积分当钱用，购买用户内容（8月-12月）
这是他们整个营销里最关键的一步，也是直接拉升 ARR 的核心手段。
从 8 月开始，Manus 在 Reddit 上搞了多轮“发 Case 赢积分”的活动。
逻辑很简单：你发一个用 Manus 完成任务的帖子，我给你 1000 Credits；如果你是 Top 5，我给你 3 万 Credits。
最新一轮活动
这根本不是简单的征文比赛。
对于 AI Agent 类产品，算力成本很高。用户如果不付费，很难持续用下去。Manus 很聪明，它不需要花真金白银去 Facebook 投广告，而是用自家产品的“虚拟货币（积分）”，雇佣了成千上万的用户在 Reddit 上帮它写软文、做演示。
到了 12 月，也就是收购前夕，Reddit 上已经铺天盖地全是用户夸它的长文案例。
这些内容，带来了两个结果：
1. 极大地降低了获客成本（CAC）。
2. 给 Meta 的尽调团队展示了最真实的“民意”和活跃度。
这才是 1 亿美元 ARR 背后真正的推手。
最后，说点商业层面的思考。
今天，Manus 被收购，刚好智谱 AI 也在香港成功上市。
这标志着 2026 年将是 AI 产品的“大航海时代”。
同时，不管你是做大模型还是做应用，出海不再是备选项，是必选项。
回到开头。如果 Manus 当时选择留在国内，还在应对无休止的合规审查和舆论口水战，可能早就凉了。他们选择了断臂求生，搬去新加坡，死磕海外社区。
有时候，选择比努力重要。在一个不承认你价值的地方死磕，不如换一片承认你价值的海域。
Manus 在 Reddit 上的这套打法——从冷启动制造稀缺，到建立信任，再到用积分激励构建内容飞轮，其实有一套完整的 SOP。
如果你也想在 2026 年把产品卖给外国人，不管是做 Reddit 运营还是整体出海营销，可以来找我聊聊。
1 00
周末，我在@超哥 深圳的酒馆Token Lab，搞了一场OpenClaw黑客松闭门会。
130多人报名，真正既懂出海又深度用过OpenClaw的，筛完就剩20来个。做亚马逊VC的、做独立站品牌的、做TikTok起量的、做建材五金出海的、从阿里出来做营销服务的，全坐在一起。
没有人问怎么安装，没有人问md文件怎么配。
聊的全是：业务怎么拆、Skill怎么写得稳、RPA怎么接、VOC看板怎么跑。
这场闭门会结束后，大家达成了一个共识：龙虾想要真正跑起来，需要顶级LLM做大脑，自动化RPA做手脚，高质量Skills做说明书，而落地最重要的一点——你的业务得先SOP化。
我花了一晚上整理了现场的录音，只挑出4个最硬核的落地真相。
看完你会明白，为什么你养的龙虾只会陪你聊天，而别人的龙虾已经在全自动跑业务了。
01 你的龙虾不是缺教程，缺的是业务SOP
AI只是一百或者1000后面的那个0，而自己的业务是1，没有1，后面加多少个0都没有意义。
很多人拿到OpenClaw，第一反应是"这玩意能帮我干啥？"
反了。
正确的逻辑是：我现在的业务卡点在哪，怎么把它拆成SOP让AI去干。
现场有小组分享做亚马逊选品，他们不是让AI漫无目的地搜，而是把选品拆成了12个极度具体的维度——从广告情况、利润测算，到专利壁垒、用户痛点验证。
甚至限定了AI的数据来源，让AI评估证据等级，最后生成一个四象限的机会矩阵。
有个做了8年亚马逊VC的卖家说得更直白：很多选品软件给你看维度，但你自己公司是什么模式、精品还是铺货、运营能力到什么段位、有没有本地化资源——这些前置条件不先定死，AI跑出来的东西没法用。
这叫业务SOP化。
SOP到底要拆多细？这是我听完闭门会回去后，自己实操落地的"监控竞品自动调价"的SOP指令：
Step 1（拉取数据）：用API拉取飞书待处理的数据。
Step 2（网页抓取）：触发爬虫，获取竞品最新售价。
Step 3（算法决策）：规则卡死——定价永远比竞品低0.5刀，但死守10%利润底线。
Step 4（人类确认）：强制暂停，把方案推给人类，拿到确认指令才放行。
Step 5（回写数据）：价格写回飞书，自动更新状态。
你只有把颗粒度拆得这么细，OpenClaw才能给你精准的报告，而不是一堆废话幻觉。
当然这还不够，因为在龙虾执行时，Step2数据爬取一直被网页拦截，十分不稳定。
这也是下面要说的第二个点：怎么结合RPA。
02 机械的活甩给RPA，让龙虾只做逻辑判断
现在最大的误区：把OpenClaw当神，觉得它能接管一切网页操作。
但实际上，让龙虾跑一整套电商工作流，风险极高。
有个养了十几台龙虾的大卖说：他在年前给每个业务线都配了一台，跑了一个星期大家全不用了。记忆错乱、不知道在聊什么、开始骗人。网页环境太复杂，今天能打开明天可能就卡住了，让大模型去执行点击、滑动这种机械动作，不仅容易卡死报错，Token消耗还极其恐怖。
懂行的人怎么做？
用RPA等工作流去跑确定性的流程。
还是拿竞品调价监控这个高频业务场景来拆解：
如果你让OpenClaw去干：它需要打开50个竞品的亚马逊页面，挨个读取最新价格。过程中不仅会触发反爬机制卡死，而且光是读取前端乱七八糟的HTML代码，每天就要消耗恐怖的Token费用。
如果你用RPA + OpenClaw的工业级跑法：
第一步，用RPA写一个固定流程，每天早上8点打开这50个链接，抓取竞品最新价格，整理成表格。精准、快速，不耗Token。
第二步，RPA抓完数据后，通过Webhook把数据直接推给OpenClaw。
第三步，OpenClaw接收数据，分析出竞品A突然降价了15%，然后生成一份报告，自动推送到你的飞书。
在这个链路里：RPA是执行端，解决稳定性的问题；OpenClaw是调度端，解决分析和决策的问题。
现场做AI自动化的@明鉴 老师说了一个很关键的判断：
Coze和n8n根本代替不了RPA，因为有些需要自动化的动作你需要去控制本地客户端、控制本地文件，浏览器环境里做不了。
但OpenClaw也代替不了RPA，因为它不稳定。未来一定是把RPA、Coze、n8n这些和OpenClaw整合在一起——n8n、Coze和RPA作为Skill，给OpenClaw去调度。
我在线下大会的观点
现场他还演示了一个案例：在OpenClaw里输入一条指令"抓取小红书"，龙虾自动调用八爪鱼的RPA流程去执行抓取，数据直接回流到多维表格。整个过程龙虾没有去碰任何网页，只是下了一道命令。
把机械操作还给机器，把逻辑判断交给大模型。
工业级玩法不是让龙虾去点网页，而是让龙虾决定什么时候该点、点完怎么用结果。
03 除了用上顶配模型，用五步法写出高质量Skill
OpenClaw到底好不好用，全看你喂给它什么Skill。
Skill就是AI时代的SOP载体。
但现场的共识是：让龙虾自己手搓的Skill，质量往往很差。
有个做了7年亚马逊、计算机出身的卖家分享了他写Skill的方法论，我觉得是全场最实用的：
第一，写Skill一定用最好的模型写。他所有的Skill都是用Claude Code加Opus 4.6来写，不用龙虾自己写。理由很直接：好的广告投手是用钱烧出来的，好的Skill一定是用Token喂出来的。
第二，先用Plan模式跟大模型过业务需求，Plan过完了再让它动手写代码。这样反而省Token。
第三，写完之后放到Cursor或Cline里执行测试，能监控到整个执行过程——它在哪一步卡住了、调用了什么数据、抓了多少条，全看得到。你用龙虾跑，执行过程是黑盒，根本没法调优。
第四，Skill输出必须强制带数据源。不只要报告，还要原始数据表格。你得能校验它到底是真跑了还是瞎编的。
那具体一个Skill的结构长什么样？
现场展示了一张图，把写Skill的底层逻辑讲得很透。一个能直接落地的Skill，必须包含五个维度：
定场景 + 立目标 + 理规则 + 给示例 + 划边界。
拿亚马逊竞品调价监控来打个样：
WHEN（触发条件）：什么时候用？——收到RPA抓取50个竞品最新价格表格时触发。
WHAT（具体成果）：解决什么问题？——输出带利润核算的《竞品调价执行方案》。
HOW（步骤逻辑）：具体怎么执行？——1.对比找出降价竞品；2.按"比竞品低0.5刀"算出建议价；3.严格校验底线成本。
REFERENCE（正反样例）：执行标准是什么？——【正例】竞品降至19.9，建议调至19.4，保底毛利12%→通过。【反例】建议调价跌破10%利润红线→直接驳回，维持原价。
LIMITS（明确限制）：绝对不能碰的红线是什么？——严禁系统擅自改价，需要人类确认才能执行。
这里面最容易被忽略的是最后一步——划边界。现场有人分享过用龙虾自动发邮件，结果龙虾乱发的惨案。你不把红线写死在Skill里，它真的会自己做主。
逻辑拆得越碎、边界卡得越死，跑出来的东西就越稳。
这块的落地我还单独写了一篇文章：用龙虾模型把跨境电商的业务SOP转成OpenClaw的Skill
04 用OpenClaw跑海外VOC舆情监控
闭门会上第四组做的项目是VOC舆情看板。
先说他们要解决的业务痛点：做品牌出海的公司，通常要配专人盯亚马逊、Reddit、TikTok、Instagram这几个平台，监控自己品牌和竞品的舆情。人工去开一堆网页、手动下载数据、自己提炼关键信息——这活又苦又慢，而且很难做到实时。
他们的目标是把这整个环节自动化掉。
最终呈现的效果是一个完整的舆情看板，拿安克（Anker）做的案例——最上面是今日舆情洞察总结，哪些需要紧急关注、哪些是中等优先级、哪些是正面舆情。下面是品牌被提及的次数和趋势变化，正面、消极、中立的占比，各平台的分布情况，用户高频关键词的词云，以及各平台最新帖子的滚动展示。
运营同事不用再开一堆网页来回切了，盯这一个看板就够了。
现场问了一句"如果真有这样的看板，愿意付费的举手"，一片手举起来。
但最有价值的不是这个前端页面——前端用Web Coding随便搭——而是后端数据怎么抓。这才是真正的坑。
他们在不同平台踩了完全不同的坑，最后跑通的方案是这样的：
亚马逊：用OpenClaw原生的浏览器功能直接打开页面爬取，这个相对简单，数据能抓下来。
X（Twitter）：用了一个叫Agent Reach的Skill，需要先登录拿到Cookies里的关键数据，然后Agent Reach就能自动去获取帖子内容。
Reddit：这是最难的。试了好几个方案都失败了，最后跑通的是用一个叫Browser Win的插件——它在本地建一个MCP，AI通过MCP来操作你本地电脑上的浏览器窗口。好处是只需要登录一次，后续就能持续访问。
TikTok：用原生浏览器功能和Browser Win都能获取到文字内容的帖子数据。
每个平台跑通之后，把每个平台的爬取逻辑各写成一个独立的Skill。比如X平台爬取就封装成一个专用Skill，自动调用Agent Reach；Reddit就自动调用Browser Win。后续执行的时候，龙虾只需要判断该调哪个Skill就行了。
然后利用OpenClaw的心跳机制，设定固定的时间间隔（比如每5分钟），自动去各平台抓一次最新的帖子数据，回来做情感分析和关键词提取，更新到看板上。
关于跨境电商抓数据的Skill可以看这篇文章：给OpenClaw开天眼！解决了10个跨境电商网站爬虫难题
这里有个很重要的细节：分享的人很诚实地说，如果真要把这套VOC看板做到生产级别，他可能会用Web Coding自己写爬虫，因为用Skill去爬的时候第二次就可能出问题，稳定性还不够。
但OpenClaw的价值在于：它提供了一套把所有平台生态连接起来的思路和调度能力——在它之前，没有人想过有这么一个东西，可以把电脑的操作权限完全交出去，让一个AI来统一调度亚马逊、Reddit、TikTok、Instagram的数据采集和分析。
先用龙虾把链路跑通，验证业务逻辑没问题，再把不稳定的环节逐步替换成更可靠的方案。
这才是正确的落地节奏。
05 宁愿养一个虾，也不愿带一个实习生
这句话是现场一个做了7年亚马逊的卖家说的，说完全场都笑了，但没人反驳。
带过团队的人都懂这个痛——你花三个月教一个实习生怎么选品、怎么看广告数据、怎么写Listing，刚能上手干活了，人走了。
但你花三个月打磨一个Skill呢？
这个Skill不会离职。你迭代过的每一版SOP、踩过的每一个坑、优化过的每一条规则，全写在里面。换一台龙虾，装上就能跑。换一个新人来，让他学着用这个Skill，上手速度比从零教快十倍。
更关键的是，Skill是可以复用和组合的。
你写了一个选品分析的Skill，加上一个竞品广告监控的Skill，再加一个VOC情感分析的Skill——三个Skill串起来，就是一个完整的产品决策链条。
你带出来的不是一个人，是一套可以反复运行的业务系统。
现场有人说他现在已经有20多个Skill了，覆盖广告、选品、竞品分析、内容生成各个环节。每个Skill都是从实际业务里一轮一轮磨出来的，就跟带实习生一样——第一版跑出来一定有问题，你看看哪里不对，告诉它改，再跑，再改。区别是实习生改了可能还会犯，Skill改了就是改了。
130多人报名，真正既懂出海又深度用过OpenClaw的，筛完就剩20来个。做亚马逊VC的、做独立站品牌的、做TikTok起量的、做建材五金出海的、从阿里出来做营销服务的，全坐在一起。
没有人问怎么安装，没有人问md文件怎么配。
聊的全是：业务怎么拆、Skill怎么写得稳、RPA怎么接、VOC看板怎么跑。
这场闭门会结束后，大家达成了一个共识：龙虾想要真正跑起来，需要顶级LLM做大脑，自动化RPA做手脚，高质量Skills做说明书，而落地最重要的一点——你的业务得先SOP化。
我花了一晚上整理了现场的录音，只挑出4个最硬核的落地真相。
看完你会明白，为什么你养的龙虾只会陪你聊天，而别人的龙虾已经在全自动跑业务了。
01 你的龙虾不是缺教程，缺的是业务SOP
AI只是一百或者1000后面的那个0，而自己的业务是1，没有1，后面加多少个0都没有意义。
很多人拿到OpenClaw，第一反应是"这玩意能帮我干啥？"
反了。
正确的逻辑是：我现在的业务卡点在哪，怎么把它拆成SOP让AI去干。
现场有小组分享做亚马逊选品，他们不是让AI漫无目的地搜，而是把选品拆成了12个极度具体的维度——从广告情况、利润测算，到专利壁垒、用户痛点验证。
甚至限定了AI的数据来源，让AI评估证据等级，最后生成一个四象限的机会矩阵。
有个做了8年亚马逊VC的卖家说得更直白：很多选品软件给你看维度，但你自己公司是什么模式、精品还是铺货、运营能力到什么段位、有没有本地化资源——这些前置条件不先定死，AI跑出来的东西没法用。
这叫业务SOP化。
SOP到底要拆多细？这是我听完闭门会回去后，自己实操落地的"监控竞品自动调价"的SOP指令：
Step 1（拉取数据）：用API拉取飞书待处理的数据。
Step 2（网页抓取）：触发爬虫，获取竞品最新售价。
Step 3（算法决策）：规则卡死——定价永远比竞品低0.5刀，但死守10%利润底线。
Step 4（人类确认）：强制暂停，把方案推给人类，拿到确认指令才放行。
Step 5（回写数据）：价格写回飞书，自动更新状态。
你只有把颗粒度拆得这么细，OpenClaw才能给你精准的报告，而不是一堆废话幻觉。
当然这还不够，因为在龙虾执行时，Step2数据爬取一直被网页拦截，十分不稳定。
这也是下面要说的第二个点：怎么结合RPA。
02 机械的活甩给RPA，让龙虾只做逻辑判断
现在最大的误区：把OpenClaw当神，觉得它能接管一切网页操作。
但实际上，让龙虾跑一整套电商工作流，风险极高。
有个养了十几台龙虾的大卖说：他在年前给每个业务线都配了一台，跑了一个星期大家全不用了。记忆错乱、不知道在聊什么、开始骗人。网页环境太复杂，今天能打开明天可能就卡住了，让大模型去执行点击、滑动这种机械动作，不仅容易卡死报错，Token消耗还极其恐怖。
懂行的人怎么做？
用RPA等工作流去跑确定性的流程。
还是拿竞品调价监控这个高频业务场景来拆解：
如果你让OpenClaw去干：它需要打开50个竞品的亚马逊页面，挨个读取最新价格。过程中不仅会触发反爬机制卡死，而且光是读取前端乱七八糟的HTML代码，每天就要消耗恐怖的Token费用。
如果你用RPA + OpenClaw的工业级跑法：
第一步，用RPA写一个固定流程，每天早上8点打开这50个链接，抓取竞品最新价格，整理成表格。精准、快速，不耗Token。
第二步，RPA抓完数据后，通过Webhook把数据直接推给OpenClaw。
第三步，OpenClaw接收数据，分析出竞品A突然降价了15%，然后生成一份报告，自动推送到你的飞书。
在这个链路里：RPA是执行端，解决稳定性的问题；OpenClaw是调度端，解决分析和决策的问题。
现场做AI自动化的@明鉴 老师说了一个很关键的判断：
Coze和n8n根本代替不了RPA，因为有些需要自动化的动作你需要去控制本地客户端、控制本地文件，浏览器环境里做不了。
但OpenClaw也代替不了RPA，因为它不稳定。未来一定是把RPA、Coze、n8n这些和OpenClaw整合在一起——n8n、Coze和RPA作为Skill，给OpenClaw去调度。
我在线下大会的观点
现场他还演示了一个案例：在OpenClaw里输入一条指令"抓取小红书"，龙虾自动调用八爪鱼的RPA流程去执行抓取，数据直接回流到多维表格。整个过程龙虾没有去碰任何网页，只是下了一道命令。
把机械操作还给机器，把逻辑判断交给大模型。
工业级玩法不是让龙虾去点网页，而是让龙虾决定什么时候该点、点完怎么用结果。
03 除了用上顶配模型，用五步法写出高质量Skill
OpenClaw到底好不好用，全看你喂给它什么Skill。
Skill就是AI时代的SOP载体。
但现场的共识是：让龙虾自己手搓的Skill，质量往往很差。
有个做了7年亚马逊、计算机出身的卖家分享了他写Skill的方法论，我觉得是全场最实用的：
第一，写Skill一定用最好的模型写。他所有的Skill都是用Claude Code加Opus 4.6来写，不用龙虾自己写。理由很直接：好的广告投手是用钱烧出来的，好的Skill一定是用Token喂出来的。
第二，先用Plan模式跟大模型过业务需求，Plan过完了再让它动手写代码。这样反而省Token。
第三，写完之后放到Cursor或Cline里执行测试，能监控到整个执行过程——它在哪一步卡住了、调用了什么数据、抓了多少条，全看得到。你用龙虾跑，执行过程是黑盒，根本没法调优。
第四，Skill输出必须强制带数据源。不只要报告，还要原始数据表格。你得能校验它到底是真跑了还是瞎编的。
那具体一个Skill的结构长什么样？
现场展示了一张图，把写Skill的底层逻辑讲得很透。一个能直接落地的Skill，必须包含五个维度：
定场景 + 立目标 + 理规则 + 给示例 + 划边界。
拿亚马逊竞品调价监控来打个样：
WHEN（触发条件）：什么时候用？——收到RPA抓取50个竞品最新价格表格时触发。
WHAT（具体成果）：解决什么问题？——输出带利润核算的《竞品调价执行方案》。
HOW（步骤逻辑）：具体怎么执行？——1.对比找出降价竞品；2.按"比竞品低0.5刀"算出建议价；3.严格校验底线成本。
REFERENCE（正反样例）：执行标准是什么？——【正例】竞品降至19.9，建议调至19.4，保底毛利12%→通过。【反例】建议调价跌破10%利润红线→直接驳回，维持原价。
LIMITS（明确限制）：绝对不能碰的红线是什么？——严禁系统擅自改价，需要人类确认才能执行。
这里面最容易被忽略的是最后一步——划边界。现场有人分享过用龙虾自动发邮件，结果龙虾乱发的惨案。你不把红线写死在Skill里，它真的会自己做主。
逻辑拆得越碎、边界卡得越死，跑出来的东西就越稳。
这块的落地我还单独写了一篇文章：用龙虾模型把跨境电商的业务SOP转成OpenClaw的Skill
04 用OpenClaw跑海外VOC舆情监控
闭门会上第四组做的项目是VOC舆情看板。
先说他们要解决的业务痛点：做品牌出海的公司，通常要配专人盯亚马逊、Reddit、TikTok、Instagram这几个平台，监控自己品牌和竞品的舆情。人工去开一堆网页、手动下载数据、自己提炼关键信息——这活又苦又慢，而且很难做到实时。
他们的目标是把这整个环节自动化掉。
最终呈现的效果是一个完整的舆情看板，拿安克（Anker）做的案例——最上面是今日舆情洞察总结，哪些需要紧急关注、哪些是中等优先级、哪些是正面舆情。下面是品牌被提及的次数和趋势变化，正面、消极、中立的占比，各平台的分布情况，用户高频关键词的词云，以及各平台最新帖子的滚动展示。
运营同事不用再开一堆网页来回切了，盯这一个看板就够了。
现场问了一句"如果真有这样的看板，愿意付费的举手"，一片手举起来。
但最有价值的不是这个前端页面——前端用Web Coding随便搭——而是后端数据怎么抓。这才是真正的坑。
他们在不同平台踩了完全不同的坑，最后跑通的方案是这样的：
亚马逊：用OpenClaw原生的浏览器功能直接打开页面爬取，这个相对简单，数据能抓下来。
X（Twitter）：用了一个叫Agent Reach的Skill，需要先登录拿到Cookies里的关键数据，然后Agent Reach就能自动去获取帖子内容。
Reddit：这是最难的。试了好几个方案都失败了，最后跑通的是用一个叫Browser Win的插件——它在本地建一个MCP，AI通过MCP来操作你本地电脑上的浏览器窗口。好处是只需要登录一次，后续就能持续访问。
TikTok：用原生浏览器功能和Browser Win都能获取到文字内容的帖子数据。
每个平台跑通之后，把每个平台的爬取逻辑各写成一个独立的Skill。比如X平台爬取就封装成一个专用Skill，自动调用Agent Reach；Reddit就自动调用Browser Win。后续执行的时候，龙虾只需要判断该调哪个Skill就行了。
然后利用OpenClaw的心跳机制，设定固定的时间间隔（比如每5分钟），自动去各平台抓一次最新的帖子数据，回来做情感分析和关键词提取，更新到看板上。
关于跨境电商抓数据的Skill可以看这篇文章：给OpenClaw开天眼！解决了10个跨境电商网站爬虫难题
这里有个很重要的细节：分享的人很诚实地说，如果真要把这套VOC看板做到生产级别，他可能会用Web Coding自己写爬虫，因为用Skill去爬的时候第二次就可能出问题，稳定性还不够。
但OpenClaw的价值在于：它提供了一套把所有平台生态连接起来的思路和调度能力——在它之前，没有人想过有这么一个东西，可以把电脑的操作权限完全交出去，让一个AI来统一调度亚马逊、Reddit、TikTok、Instagram的数据采集和分析。
先用龙虾把链路跑通，验证业务逻辑没问题，再把不稳定的环节逐步替换成更可靠的方案。
这才是正确的落地节奏。
05 宁愿养一个虾，也不愿带一个实习生
这句话是现场一个做了7年亚马逊的卖家说的，说完全场都笑了，但没人反驳。
带过团队的人都懂这个痛——你花三个月教一个实习生怎么选品、怎么看广告数据、怎么写Listing，刚能上手干活了，人走了。
但你花三个月打磨一个Skill呢？
这个Skill不会离职。你迭代过的每一版SOP、踩过的每一个坑、优化过的每一条规则，全写在里面。换一台龙虾，装上就能跑。换一个新人来，让他学着用这个Skill，上手速度比从零教快十倍。
更关键的是，Skill是可以复用和组合的。
你写了一个选品分析的Skill，加上一个竞品广告监控的Skill，再加一个VOC情感分析的Skill——三个Skill串起来，就是一个完整的产品决策链条。
你带出来的不是一个人，是一套可以反复运行的业务系统。
现场有人说他现在已经有20多个Skill了，覆盖广告、选品、竞品分析、内容生成各个环节。每个Skill都是从实际业务里一轮一轮磨出来的，就跟带实习生一样——第一版跑出来一定有问题，你看看哪里不对，告诉它改，再跑，再改。区别是实习生改了可能还会犯，Skill改了就是改了。
17 09
周末我在深圳办了两场AI跨境电商活动，加起来600人。
聊到OpenClaw 怎么落地的时候，问我最多的问题是：饼干哥哥，你用的是哪些 Skill，能不能分享一些好用的？
我说，没有。
那些公开的 Skill 都不好用。不是因为写得差，是因为它们根本就不是为你的业务写的。
先看我的龙虾在干什么
昨晚，我把一张公司内部的 pSEO 业务流程图发给了我的一只龙虾。
5分钟后，它交付了这些东西：
完整梳理了业务 SOP，拆成了三个 Skill，写完了 9 个文件，自测了 3 个评测用例全部通过，安全审计清单 5 项全绿，安装到了正式目录，可以直接运行。
我全程说了不到 10 句话。
这不是演示，这是在飞书里真实发生的。步骤截图在后面。
但如果1个月前你问我，OpenClaw 好不好用——我的答案和大多数人一样。装了几十个 Skill，跑起来的没几个，更别说真正干活。
这中间发生了什么？
装了 300 个 Skill，但龙虾还是干不了活
ClawHub 上现在有超过 2800 个 Skill。
很多人第一件事就是批量装，装完发现龙虾还是在那里发呆，或者干活干到一半就出错了。
问题出在哪？
通用 Skill 解决的是通用问题。但跨境电商的业务流程，每家公司都不一样。你用飞书多维表格管 SKU，他用 Shopify 后台；你的竞品监控跑 Amazon，他的跑速卖通；你的 KOL 开发发的是 Gmail，他的走 WhatsApp Business。
把别人的 Skill 装进来，充其量是个参考，不是解决方案。
真正能跑起来的 Skill，一定是深度绑定你自己业务流程的。
好，问题来了：怎么把自己的业务，变成龙虾能干的 Skill？
前天我在深圳办了一场 OpenClaw + 跨境电商的黑客松闭门会。有一组同学专门讨论这个问题。他们现场给出了一个公式：
好的 Skill = 定场景 + 立目标 + 理规则 + 给示例 + 划边界
翻译成人话：什么时候用、用完手里有什么、每步怎么做、好案例和坑在哪、边界在哪。
图自@Ena
思路是对的，但嘉宾说了一句让我有点意外的话：开发 Skill 一定要用最顶的海外模型，Claude Opus、GPT-5，不然质量出不来。
我当时没有当场反驳。
专门为龙虾训练的模型，才是正确答案
昨天陆续刷到智谱发布了新模型 GLM-5-Turbo。
定位只有六个字：全球首个龙虾模型。
不是通用模型加了个龙虾适配，而是从训练阶段就针对龙虾工作流专项优化。它重点增强了四个方向：工具调用稳定性、复杂指令拆解、长任务持续执行不中断、高吞吐长链路。
你可能会问，开发 Skill 需要这些能力吗？
需要，而且非常需要。
开发一个完整的 Skill，模型要在一次会话里做这些事：理解业务意图、追问业务细节、梳理 SOP 逻辑、规划 Skill 架构、生成多个文件、自测评测用例、跑安全审计、执行安装命令。
这个过程跨越十几轮对话，涉及大量工具调用，中途不能失忆，不能崩。
这正好是 GLM-5-Turbo 专门练过的场景。
而且它有 200K 的上下文窗口，开发过程中所有的业务背景、SOP 细节、文件内容都在视野里，不会到后面把前面的需求忘掉。
在 ZClawBench（智谱自研的真实龙虾任务评测基准）上，GLM-5-Turbo 在 OpenClaw 场景里整体领先多家主流模型。内测阶段以匿名身份接入 AutoClaw 澳龙，90% 的用户盲测认为它优于其他国产模型。
扣子 Coze、美团、字节 TRAE 的测评团队用的词是：指令遵循力压群雄、长任务稳健不掉链子、高吞吐执行极快不失速。
这些评价，翻译成 Skill 开发场景的意思是：它能跟着你把一个 Skill 从头跑到尾，不会中途跑飞。
我现在OpenClaw就是用的它。
好，回到正题。
图片
Skill 开发这件事，分三个层次。
青铜：一个好提示词，让龙虾帮你写 Skill
最快的路径：把业务 SOP 整理清楚，给 GLM-5-Turbo 一套精心设计的提示词，让它直接帮你生成 Skill 文件。
这套提示词要做四件事：
第一，给模型设定角色和开发规范。告诉它 SKILL.md 的结构要求、文件组织方式、执行者分配逻辑（哪些操作用脚本、哪些用 SubAgent、哪些用主 Agent）。
第二，强制先做边界审查再动手。加一条指令：在你开始生成任何文件之前，先检查 SOP 是否有逻辑漏洞，有任何不清楚的地方立刻停下来反问我。
第三，要求先输出架构蓝图等确认后再写文件。先告诉我目录结构是什么、每一步分配给谁执行、为什么这么分，等我回复「架构确认」再动手。
第四，所有高风险操作加 BLOCKING 标签。写入数据库、发送消息、修改状态，必须强制人工确认才能继续。
我们团队的小伙伴在黑客松期间就用这套方式开发了飞书竞价监控 Skill。
模型收到提示词后，没有直接动手，而是先审查 SOP，发现了三个问题：字段类型与实际表格不一致、有个未提及的字段 Current_Price 用途不明、命名空间前缀写错了。
全部反问确认之后，才输出架构蓝图，等「架构确认」指令，再逐个生成文件。
整个过程 10 分钟，就交付了完整的 Skill。
GLM-5-Turbo 在这个环节的价值是稳。复杂的业务逻辑拆解它不会漏步骤，工具调用链条长它不会中途报错，多轮确认之后它还记得最开始的需求边界。
用的过程你就会发现，它说的东西真的好长好多。。啥都考虑进去了。。
OK，青铜层次能用，但有个隐藏问题：每次开发新 Skill，都要重新整理 SOP、重新写提示词。整理质量不稳定，提示词写得不一样，最后 Skill 质量也不稳定。
接下来升级到「白银」玩法
白银：开发一个专门用来开发 Skill 的 Skill
把开发 Skill 这件事本身，封装成一个可复用的 Skill。
这个 Skill 的核心是五维提问框架。它不会直接帮你写 Skill，而是先系统地问你五个维度的问题，直到业务逻辑完全清晰，再进入开发阶段。
五个维度对应上面的公式：
WHEN 定场景：这个 Skill 什么时候用，用户会说什么话触发它，什么情况下明确不用
WHAT 立目标：跑完这个 Skill 手里有什么，合格的输出是什么样，什么叫失败
HOW 理规则：人工完成这件事的完整步骤，每步的判断逻辑，哪步最容易出错
REFERENCE 给示例：有没有好案例参考，踩过哪些坑，有没有现成模板
LIMITS 划边界：哪些操作必须人工确认，异常情况怎么处理，什么绝对不能做
五个维度问完，Skill 会整理出 SOP 确认稿让你确认，梳理得非常细：
再输出 Skill 规划方案——这个场景要拆几个 Skill、每个 Skill 职责是什么、建议开发顺序。复杂任务就是需要这样多skills协作。
SOP 梳理的质量被标准化了。不管是你自己来，还是团队里其他人来，走完这个流程，输出的 Skill 质量会稳定在一个水准之上。
GLM-5-Turbo 的长任务持续执行能力在这个层次体现得最明显。五维问答通常需要 3-4 轮对话，中间还要跑搜索、整理 SOP、规划架构，整个链条很长。它能从头到尾保持状态，不会到第三轮的时候把第一轮确认好的边界忘掉。
但白银层次还没解决一个问题：Skill 用了一段时间之后需要迭代，怎么管？
随着 Skill 越来越多，哪些在用、哪些出了问题、哪些需要迭代，这些信息如果没人管，Skill 库会越来越乱。
黄金：一个 Agent，管理 Skill 的完整生命周期
这才是昨晚，也就是文章开头故事的底层逻辑。
不是开发一个 Skill，而是建一个专门负责 Skill 生命周期的 Agent。
这个 Agent 的工作流完整跑下来是这样的：
你发一张业务流程图，说「我想把这个场景做成 Skill」。Agent 先去搜索行业最佳实践，然后用五维提问框架问你业务细节，整理出 SOP 确认稿让你确认，规划 Skill 方案，你决定先开发哪个，它进入开发模式，生成完整的 Skill 文件结构，自测，安全审计，安装到正式目录，记入长期记忆。
每天早上自动跑 Skill 健康巡检，每周一分析哪些 Skill 使用频率高、哪些出过错误，每周五跑安全复查。
安全这块有硬规定：capabilities 字段只申请实际用到的权限、没有硬编码密钥、所有写操作前有人工确认节点、异常情况有明确的处理逻辑。审计没过不安装，哪怕你催。
核心配置四个文件：
SOUL.md 刻入 Agent 的身份和底线——使命是业务翻译官，五维问答没跑完不规划 Skill，SOP 确认稿没得到用户确认不开始写文件，安全审计没过不安装。
AGENTS.md 定义七个开发阶段的操作规范，从需求接收、五维提问、SOP 确认、Skill 规划、文件开发、自测，到安全审计和安装，每个阶段的触发条件和交付标准都写死。
TOOLS.md 定义可用工具和每个工具的使用边界，包括搜索调研、文件操作、代码执行、记忆系统、Agent 间通信。
HEARTBEAT.md 定义三个定时任务——每日巡检、每周使用分析、每周安全复查。
我把 NGS 的 pSEO 内容引擎架构图发给了这个 Agent。
它跑了九个问题的五维问答，整理出 SOP 确认稿，我确认之后它规划出「1 主 + 2 子」的三个 Skill 方案，然后顺序开发，9 个文件全部生成，自测三个评测用例全通过，安全审计五项全绿，安装完成，更新 MEMORY.md 归档。
这就是开头那一幕的完整版本。
直接让它跑一个关键词的写文章测试：
也是能走完完整流程，并且给我写好的文章结果。
GLM-5-Turbo 在黄金层次的价值最难被替代：从你说第一句话到三个 Skill 全部安装，中间跨越几十轮工具调用和多次 SubAgent 并行，整个链条一个小时，它没有中途失忆，没有跑飞，每个关键节点该停下来确认的都停了，该自己跑的都跑完了。
这正是它被定位为龙虾模型的原因——不是最聪明，是最能跑完一个完整任务。
🌅
福利！黄金层次的Agent 完整配置文件（SOUL.md / AGENTS.md / TOOLS.md / HEARTBEAT.md）&提示词
关注公众号「饼干哥哥 AGI」
回复关键词「龙虾skill」获取。
这三个层次，不是选一个，是逐步升级
青铜的提示词是白银 Skill 的前身，白银的 Skill 被包含在黄金 Agent 里。
没有 SOP 梳理能力，Agent 再强也问不出有价值的问题。
你今天从青铜开始也完全可以。整理一个业务 SOP，用提示词让 GLM-5-Turbo 帮你开发一个 Skill，跑通一遍。然后再想要不要升级到白银和黄金。
最后
OpenClaw 好不好用，跟你装了多少 Skill 没关系，跟用什么模型也没有直接关系。
它取决于你有没有把业务 SOP 梳理清楚，然后把这个 SOP 变成 Skill。
我开头说，没有什么现成的 Skill 可以推荐。
这不是谦虚，是真相。
好用的 Skill 都是自己调教出来的。但「调教」这件事本身也可以被 SOP 化，可以被工程化，可以变成一条可以复制的流水线。
这才是 OpenClaw 在跨境电商真正落地的方式。
聊到OpenClaw 怎么落地的时候，问我最多的问题是：饼干哥哥，你用的是哪些 Skill，能不能分享一些好用的？
我说，没有。
那些公开的 Skill 都不好用。不是因为写得差，是因为它们根本就不是为你的业务写的。
先看我的龙虾在干什么
昨晚，我把一张公司内部的 pSEO 业务流程图发给了我的一只龙虾。
5分钟后，它交付了这些东西：
完整梳理了业务 SOP，拆成了三个 Skill，写完了 9 个文件，自测了 3 个评测用例全部通过，安全审计清单 5 项全绿，安装到了正式目录，可以直接运行。
我全程说了不到 10 句话。
这不是演示，这是在飞书里真实发生的。步骤截图在后面。
但如果1个月前你问我，OpenClaw 好不好用——我的答案和大多数人一样。装了几十个 Skill，跑起来的没几个，更别说真正干活。
这中间发生了什么？
装了 300 个 Skill，但龙虾还是干不了活
ClawHub 上现在有超过 2800 个 Skill。
很多人第一件事就是批量装，装完发现龙虾还是在那里发呆，或者干活干到一半就出错了。
问题出在哪？
通用 Skill 解决的是通用问题。但跨境电商的业务流程，每家公司都不一样。你用飞书多维表格管 SKU，他用 Shopify 后台；你的竞品监控跑 Amazon，他的跑速卖通；你的 KOL 开发发的是 Gmail，他的走 WhatsApp Business。
把别人的 Skill 装进来，充其量是个参考，不是解决方案。
真正能跑起来的 Skill，一定是深度绑定你自己业务流程的。
好，问题来了：怎么把自己的业务，变成龙虾能干的 Skill？
前天我在深圳办了一场 OpenClaw + 跨境电商的黑客松闭门会。有一组同学专门讨论这个问题。他们现场给出了一个公式：
好的 Skill = 定场景 + 立目标 + 理规则 + 给示例 + 划边界
翻译成人话：什么时候用、用完手里有什么、每步怎么做、好案例和坑在哪、边界在哪。
图自@Ena
思路是对的，但嘉宾说了一句让我有点意外的话：开发 Skill 一定要用最顶的海外模型，Claude Opus、GPT-5，不然质量出不来。
我当时没有当场反驳。
专门为龙虾训练的模型，才是正确答案
昨天陆续刷到智谱发布了新模型 GLM-5-Turbo。
定位只有六个字：全球首个龙虾模型。
不是通用模型加了个龙虾适配，而是从训练阶段就针对龙虾工作流专项优化。它重点增强了四个方向：工具调用稳定性、复杂指令拆解、长任务持续执行不中断、高吞吐长链路。
你可能会问，开发 Skill 需要这些能力吗？
需要，而且非常需要。
开发一个完整的 Skill，模型要在一次会话里做这些事：理解业务意图、追问业务细节、梳理 SOP 逻辑、规划 Skill 架构、生成多个文件、自测评测用例、跑安全审计、执行安装命令。
这个过程跨越十几轮对话，涉及大量工具调用，中途不能失忆，不能崩。
这正好是 GLM-5-Turbo 专门练过的场景。
而且它有 200K 的上下文窗口，开发过程中所有的业务背景、SOP 细节、文件内容都在视野里，不会到后面把前面的需求忘掉。
在 ZClawBench（智谱自研的真实龙虾任务评测基准）上，GLM-5-Turbo 在 OpenClaw 场景里整体领先多家主流模型。内测阶段以匿名身份接入 AutoClaw 澳龙，90% 的用户盲测认为它优于其他国产模型。
扣子 Coze、美团、字节 TRAE 的测评团队用的词是：指令遵循力压群雄、长任务稳健不掉链子、高吞吐执行极快不失速。
这些评价，翻译成 Skill 开发场景的意思是：它能跟着你把一个 Skill 从头跑到尾，不会中途跑飞。
我现在OpenClaw就是用的它。
好，回到正题。
图片
Skill 开发这件事，分三个层次。
青铜：一个好提示词，让龙虾帮你写 Skill
最快的路径：把业务 SOP 整理清楚，给 GLM-5-Turbo 一套精心设计的提示词，让它直接帮你生成 Skill 文件。
这套提示词要做四件事：
第一，给模型设定角色和开发规范。告诉它 SKILL.md 的结构要求、文件组织方式、执行者分配逻辑（哪些操作用脚本、哪些用 SubAgent、哪些用主 Agent）。
第二，强制先做边界审查再动手。加一条指令：在你开始生成任何文件之前，先检查 SOP 是否有逻辑漏洞，有任何不清楚的地方立刻停下来反问我。
第三，要求先输出架构蓝图等确认后再写文件。先告诉我目录结构是什么、每一步分配给谁执行、为什么这么分，等我回复「架构确认」再动手。
第四，所有高风险操作加 BLOCKING 标签。写入数据库、发送消息、修改状态，必须强制人工确认才能继续。
我们团队的小伙伴在黑客松期间就用这套方式开发了飞书竞价监控 Skill。
模型收到提示词后，没有直接动手，而是先审查 SOP，发现了三个问题：字段类型与实际表格不一致、有个未提及的字段 Current_Price 用途不明、命名空间前缀写错了。
全部反问确认之后，才输出架构蓝图，等「架构确认」指令，再逐个生成文件。
整个过程 10 分钟，就交付了完整的 Skill。
GLM-5-Turbo 在这个环节的价值是稳。复杂的业务逻辑拆解它不会漏步骤，工具调用链条长它不会中途报错，多轮确认之后它还记得最开始的需求边界。
用的过程你就会发现，它说的东西真的好长好多。。啥都考虑进去了。。
OK，青铜层次能用，但有个隐藏问题：每次开发新 Skill，都要重新整理 SOP、重新写提示词。整理质量不稳定，提示词写得不一样，最后 Skill 质量也不稳定。
接下来升级到「白银」玩法
白银：开发一个专门用来开发 Skill 的 Skill
把开发 Skill 这件事本身，封装成一个可复用的 Skill。
这个 Skill 的核心是五维提问框架。它不会直接帮你写 Skill，而是先系统地问你五个维度的问题，直到业务逻辑完全清晰，再进入开发阶段。
五个维度对应上面的公式：
WHEN 定场景：这个 Skill 什么时候用，用户会说什么话触发它，什么情况下明确不用
WHAT 立目标：跑完这个 Skill 手里有什么，合格的输出是什么样，什么叫失败
HOW 理规则：人工完成这件事的完整步骤，每步的判断逻辑，哪步最容易出错
REFERENCE 给示例：有没有好案例参考，踩过哪些坑，有没有现成模板
LIMITS 划边界：哪些操作必须人工确认，异常情况怎么处理，什么绝对不能做
五个维度问完，Skill 会整理出 SOP 确认稿让你确认，梳理得非常细：
再输出 Skill 规划方案——这个场景要拆几个 Skill、每个 Skill 职责是什么、建议开发顺序。复杂任务就是需要这样多skills协作。
SOP 梳理的质量被标准化了。不管是你自己来，还是团队里其他人来，走完这个流程，输出的 Skill 质量会稳定在一个水准之上。
GLM-5-Turbo 的长任务持续执行能力在这个层次体现得最明显。五维问答通常需要 3-4 轮对话，中间还要跑搜索、整理 SOP、规划架构，整个链条很长。它能从头到尾保持状态，不会到第三轮的时候把第一轮确认好的边界忘掉。
但白银层次还没解决一个问题：Skill 用了一段时间之后需要迭代，怎么管？
随着 Skill 越来越多，哪些在用、哪些出了问题、哪些需要迭代，这些信息如果没人管，Skill 库会越来越乱。
黄金：一个 Agent，管理 Skill 的完整生命周期
这才是昨晚，也就是文章开头故事的底层逻辑。
不是开发一个 Skill，而是建一个专门负责 Skill 生命周期的 Agent。
这个 Agent 的工作流完整跑下来是这样的：
你发一张业务流程图，说「我想把这个场景做成 Skill」。Agent 先去搜索行业最佳实践，然后用五维提问框架问你业务细节，整理出 SOP 确认稿让你确认，规划 Skill 方案，你决定先开发哪个，它进入开发模式，生成完整的 Skill 文件结构，自测，安全审计，安装到正式目录，记入长期记忆。
每天早上自动跑 Skill 健康巡检，每周一分析哪些 Skill 使用频率高、哪些出过错误，每周五跑安全复查。
安全这块有硬规定：capabilities 字段只申请实际用到的权限、没有硬编码密钥、所有写操作前有人工确认节点、异常情况有明确的处理逻辑。审计没过不安装，哪怕你催。
核心配置四个文件：
SOUL.md 刻入 Agent 的身份和底线——使命是业务翻译官，五维问答没跑完不规划 Skill，SOP 确认稿没得到用户确认不开始写文件，安全审计没过不安装。
AGENTS.md 定义七个开发阶段的操作规范，从需求接收、五维提问、SOP 确认、Skill 规划、文件开发、自测，到安全审计和安装，每个阶段的触发条件和交付标准都写死。
TOOLS.md 定义可用工具和每个工具的使用边界，包括搜索调研、文件操作、代码执行、记忆系统、Agent 间通信。
HEARTBEAT.md 定义三个定时任务——每日巡检、每周使用分析、每周安全复查。
我把 NGS 的 pSEO 内容引擎架构图发给了这个 Agent。
它跑了九个问题的五维问答，整理出 SOP 确认稿，我确认之后它规划出「1 主 + 2 子」的三个 Skill 方案，然后顺序开发，9 个文件全部生成，自测三个评测用例全通过，安全审计五项全绿，安装完成，更新 MEMORY.md 归档。
这就是开头那一幕的完整版本。
直接让它跑一个关键词的写文章测试：
也是能走完完整流程，并且给我写好的文章结果。
GLM-5-Turbo 在黄金层次的价值最难被替代：从你说第一句话到三个 Skill 全部安装，中间跨越几十轮工具调用和多次 SubAgent 并行，整个链条一个小时，它没有中途失忆，没有跑飞，每个关键节点该停下来确认的都停了，该自己跑的都跑完了。
这正是它被定位为龙虾模型的原因——不是最聪明，是最能跑完一个完整任务。
🌅
福利！黄金层次的Agent 完整配置文件（SOUL.md / AGENTS.md / TOOLS.md / HEARTBEAT.md）&提示词
关注公众号「饼干哥哥 AGI」
回复关键词「龙虾skill」获取。
这三个层次，不是选一个，是逐步升级
青铜的提示词是白银 Skill 的前身，白银的 Skill 被包含在黄金 Agent 里。
没有 SOP 梳理能力，Agent 再强也问不出有价值的问题。
你今天从青铜开始也完全可以。整理一个业务 SOP，用提示词让 GLM-5-Turbo 帮你开发一个 Skill，跑通一遍。然后再想要不要升级到白银和黄金。
最后
OpenClaw 好不好用，跟你装了多少 Skill 没关系，跟用什么模型也没有直接关系。
它取决于你有没有把业务 SOP 梳理清楚，然后把这个 SOP 变成 Skill。
我开头说，没有什么现成的 Skill 可以推荐。
这不是谦虚，是真相。
好用的 Skill 都是自己调教出来的。但「调教」这件事本身也可以被 SOP 化，可以被工程化，可以变成一条可以复制的流水线。
这才是 OpenClaw 在跨境电商真正落地的方式。
7 12
有个美国人把 OpenClaw 装进 MacBook，配上一套专门为屋顶承包商定制的 Skills，接好 HubSpot CRM，加上行业专属的 SOUL.md，然后直接寄给客户。
插电，AI 员工上班。
收费 5000 美元一台，后续 weekly 支持。
虽然Macbook对企业落地明显是不行的（后面我会介绍更专业的设备）
但这个项目——叫 RoofClaw——总收入已经超过 180 万美元，服务了 360 多家屋顶承包商。
算一笔账：全球 AI Agent 市场 2025 年 76 亿美元，年复合增长率 49.6%，2033 年预计到 1830 亿美元。全球跨境电商市场今年突破 4 万亿美元，中国出口电商逼近 3 万亿人民币。
这两个万亿级市场的交叉地带——用 AI Agent 帮跨境电商公司干活这件事，保守估计是一个千亿级的服务市场。
而现在，这个市场几乎没人系统在做。
人最终会变成 AI 的燃料
我在上周的 NGS AI跨境电商大会上说过这句话。
听着刺耳，但这就是我们团队现在的真实状态：
👀
全员从微信迁移到飞书，飞书里接入 OpenClaw。所有工作对话，AI 在旁边同步，沉淀成知识，转成 Skills，下次直接调用。这个循环跑起来之后，组织里每一次对话都在给 AI 喂燃料，让它越来越懂这个行业、懂这家公司、懂每一个具体的业务场景。
周日我还办了一场 OpenClaw 跨境电商闭门会，来的都是真在跑业务的人。
但我发现一件事——大家对 OpenClaw 在企业管理端的想象力，明显比业务端弱。
其实跨境公司的管理问题一点不比业务小：员工流失、知识断层、数据滞后、达人管理混乱，每一件都能搞垮一个正在增长的公司。
下面就把我们团队真实在跑的几个场景拆开讲，看看这千亿市场到底要怎么做？
图片
01 沉淀群聊内容为知识库，再转成Skills
公司最贵的隐性成本不是广告费，是人员流动造成的知识损耗。
一个做了两年的运营离职，他知道的平台规则、踩过的坑、和供应商的默契，全带走了。
下一个人从零开始，再踩一遍。这个循环每年都在重复。
我们现在的做法就是前面说那样，如果你也想配置的话，老实说，一点门槛没有。
我都是直接跟Claude沟通的
图片
提示词：
我想用 OpenClaw 搭建一套团队知识自动沉淀系统。
当前状况：
- 团队在飞书群里沟通日常业务
- 核心知识散落在聊天记录里，没有系统整理
- 员工离职后知识断层严重
我的诉求：
1. OpenClaw 接入飞书群，实时监听业务讨论
2. 自动识别有价值的业务经验、踩坑记录、操作规范
3. 整理后写入 AGENTS.md 对应章节（按业务模块分类）
4. 每周五自动输出一份「本周知识沉淀周报」到飞书群
请帮我设计：
1. SOUL.md 中关于知识沉淀的角色定义
2. AGENTS.md 的知识分类结构（覆盖我以下业务模块：[选品/运营/广告/供应链/达人管理]）
3. HEARTBEAT.md 的知识巡检逻辑（每小时检查一次新消息，有价值内容才处理，没有则 HEARTBEAT_OK）
4. 每周五知识周报的 Cron 配置（isolated session + announce 到飞书群）
02 让 AI 来调度企业现有的自动化工具
很多跨境公司已经有一套在跑的自动化流程：n8n 工作流、各种 RPA、定制脚本。
这些东西干活很稳，但彼此之间是孤岛。A 跑完了要不要触发 B，全靠人来盯。
OpenClaw 最适合做的就是这层调度大脑。
我在线下大会的观点
原理是这样的：
👀
OpenClaw Gateway 原生支持 Webhook 接收。在 openclaw.json 的 hooks 里开启 webhook，设好 token，n8n 工作流跑完一个任务，结果通过 HTTP POST 推到 OpenClaw 的 /hooks/agent 端点。OpenClaw 收到后启动一个 isolated session 的 agent turn，判断下一步是继续推进还是需要人工介入，异常的时候生成处理建议并推送到飞书群。
不是替换现有工具，是在上面加了一层会思考的调度层。
参考配置方案：
第一步，在 openclaw.json 里开启 Webhook：
{
"hooks":{
"enabled":true,
"token":"你的安全密钥",
"path":"/hooks",
"defaultSessionKey":"hook:n8n-dispatch",
"allowRequestSessionKey":true,
"allowedSessionKeyPrefixes":["hook:"]
}
}
第二步，n8n 工作流末尾加一个 HTTP Request 节点，POST 到 OpenClaw：
POST http://你的服务器IP:18789/hooks/agent
Header: x-openclaw-token: 你的安全密钥
Body:
{
"message": "n8n 工作流 [广告数据拉取] 执行完毕。结果：ROAS 1.8，花费 ¥3200。请判断是否异常并决定下一步。",
"name": "n8n-广告监控",
"sessionKey": "hook:n8n-ads",
"deliver": true,
"channel": "feishu",
"to": "飞书群ID"
}
第三步，在 AGENTS.md 里写入调度判断逻辑：
## n8n 工作流调度规则
当你收到 n8n webhook 回调时：
1. 解析工作流名称和执行结果
2. 对照以下阈值判断是否异常：
- 广告 ROAS 低于 [你的阈值]：异常，立刻通知
- 库存低于 [X] 天销量：异常，立刻通知
- 工作流执行失败：异常，立刻通知并附失败原因
3. 正常情况：不输出任何内容，静默处理
4. 异常情况：推送到飞书群，格式为「⚠️ [工作流名称] 异常：[具体问题] → 建议：[处理方案]」
5. 工作流依赖关系：[工作流B] 正常完成后，自动触发 [工作流C]（通过 curl 调用 n8n 的 webhook URL）
03 业务 SOP 沉淀成 Skills，才是真正的护城河
这件事我前天发过文章 教怎么把跨境电商的业务SOP转成OpenClaw的Skill
这里就不赘述，核心在于让Openclaw来反问，把业务SOP梳理清楚。
04 让老板回归「做重要决策」这件事
这是我见过最多跨境老板踩的坑：每天花一个小时看各种后台数据，看完也没做什么决策。
数据本身没有价值，数据驱动的决策才有价值。
我们团队跑了一个永不下班的决策助理。
设计逻辑：
👀
连接亚马逊广告 API、独立站 GA4、飞书多维表，每小时拉数据判断异常。ROAS 低于阈值、退款率超标、库存不足 7 天销量——才推送。其他时候沉默。每天早 9 点一份当日简报，已经带结论和建议动作，不需要老板自己算。
除了业务数据，这个 Agent 还能接收团队成员的日报周报，自动提炼关键进展和卡点，老板打开飞书看到的不是一堆文字，而是一份结构化的「需要你关注的事」清单。
老板真正需要的只有一个信息：现在哪件事需要我做决定。
配置方案：
第一步，配置数据巡检的 Cron 任务。用 isolated session，正常时不产生输出：
openclaw cron add \
--name "data-patrol" \
--cron "0 * * * *" \
--session isolated \
--message "执行数据巡检。读取 AGENTS.md 中的异常阈值规则，调用对应 API 拉取最新数据，逐项判断。如果全部正常，只回复 HEARTBEAT_OK，不要输出其他任何内容。如果有异常，输出格式：⚠️ [指标名] 异常：当前值 [X]，阈值 [Y] → 建议：[处理方案]。" \
--announce
第二步，在 AGENTS.md 里定义异常阈值：
## 数据异常阈值（根据自身业务填写）
- 广告 ROAS 低于 [X]
- 单日广告花费超过 [X] 元且 ROAS 未达标
- 退款率超过 [X%]
- 某 SKU 库存低于 [X] 天销量
- 独立站跳出率突增 [X%] 以上
- 新品上线 [X] 天内零转化
## 数据源配置
- 亚马逊广告 API：通过 Skill [amazon-ads] 调用
- GA4：通过 Skill [ga4-report] 调用
- 飞书多维表（库存/销售数据）：表格 URL [填入]
## 推送规则
- 正常不通知，异常立刻推送到飞书群 [群名]
- 紧急事项同时私信老板飞书
05 多 Agent 协作：不要一上来就搞五个 Agent
这是我最想纠正的一个误区。
我之前写过一篇文章：用OpenClaw搭跨境电商团队：5个AI员工，跑通全平台矩阵！
但很多人看了多 Agent 的教程，第一反应就是搞五六个 Agent，一个管选品、一个管广告、一个管内容、一个管达人……然后发现整个系统根本跑不起来。
问题出在哪？
第一，没有队形。五个 Agent 各干各的，谁也不知道队友在做什么，该交接的不交接，该汇报的不汇报。
第二，活派出去收不回来。OpenClaw 的 sessions_send 有个隐藏限制：等下游回复的超时只有 30 秒，超了就丢了，上游 Agent 以为对方没干活。
第三，配置项太多容易漏。每个 Agent 要单独建 workspace、绑 IM 账号、开 A2A 权限、设 Session 可见性，少一项整条链路就是废的。
正确的做法是分阶段来。
阶段一：一个主 Agent + SubAgent 模式
不需要多个独立 Agent。用一个主 Agent，复杂任务通过 sessions_spawn 派给 SubAgent 在后台跑，跑完结果自动回传。这个模式配置最简单，90% 的场景够用。
阶段二：需要多人同时对话时，上多 Agent
当你的团队里多个人需要同时跟不同的 Agent 对话（比如运营找运营助手、老板找决策助手），这时候才需要真正的多 Agent 路由。
关键配置三件事：
1. 工作区物理隔离：每个 Agent 必须有独立的 workspace，用 openclaw agents add 命令创建，不要手动建目录。
2. A2A 通信白名单：在 openclaw.json 里显式开启 agentToAgent，
{
"tools": {
"agentToAgent": {
"enabled": true,
"allow": ["lead", "ops-assistant", "ads-assistant"]
}
}
}
## 协作准则
### 委派任务后
- 收到 sessions_send 返回 { status: "accepted" } 后，如果不依赖结果，继续做下一件事
- 如果必须等结果，告知用户「已委派给 @[队友ID]，等待结果」，然后结束当前轮次
- 队友完成后会通过 sessions_send 回传唤醒你
### 接到任务后
1. 立刻在群里用 message 工具通知用户已接手（消息开头 @上游AgentID）
2. 执行任务
3. 完成后先在群里汇报结果（同样 @上游AgentID）
4. 同时必须调用 sessions_send 将结果发回给委派者，唤醒对方继续工作
3. 双重汇报协议：在每个 Agent 的 SOUL.md 里写入协作准则，解决超时问题：
并设置允许通信的 Agent 列表：
企业落地的最后一公里是设备
很多人找我问设备，这件事不能随便答
个人用户随便玩，Mac Mini 或者一台性能稍好的 PC，跑云端模型 API，完全够了。
但企业就不一样了。最近找我推荐设备的主要是两类场景，我说清楚逻辑，自己对号入座。
第一类：数据不能出门的企业。
很多跨境公司处理的内容包含客服对话、员工沟通、供应商报价、广告数据。这些东西如果全走云端 API，数据就在别人的服务器上跑了。一旦涉及竞争情报、价格策略、KOL 资源这类核心资产，云端方案会让老板很不安。
新闻已经在警告不要在工作设备上安装 OpenClaw，理由是安全风险。私人企业虽然没有这个强制要求，但数据主权的问题真实存在。
这类场景，本地部署模型是唯一干净的解法。
可以看下 行云褐蚁 的 HY50 ，是这个需求里性价比最高的入门方案。500GB 大容量内存，跑 Qwen3 235B Q4 这类 MoE 大模型没有问题，30 路并发足够覆盖一个中小团队的日常 AI 调用，HEYI 自研推理引擎把 CPU 内存带宽发挥到极致，整体预算在十万元级别。
适合：20 人以下的跨境团队，核心诉求是数据不出门、本地跑通 OpenClaw 的完整工作流。
第二类：团队并发量大，多人同时在用 Agent 的企业。
一台机器同时跑 20 个员工的 OpenClaw 请求，每个 Agent 会话又在调用子 Agent，上下文动辄几万 token，对内存带宽和并发能力的要求完全不是普通设备能撑的。
可以看下 HY NV4-6000 ，四块 NVIDIA RTX 6000 Pro，384GB 四路显存，128 路并发实测，32 路日常办公人均上下文 192K。这个配置的核心价值是：公司所有 Agent 工作流共享一套私有算力，数据主权完全自控，金融、法务、合规等对数据安全有强要求的环节可以直接跑。
适合：50 人以上的跨境企业，多个部门同时使用 OpenClaw，需要统一的私有 AI 基础设施。
如果是公司级 AI 中台，要撑全域 Agent 高频并发、大规模自动化业务流，就要上 HY NV8-6000 了：768GB 满血显存，支持 Qwen3.5、GLM 4.7等旗舰模型的原生推理，零量化损耗，总吞吐 2000+ tokens/s。这个配置就不是一个部门的需求了，是整家公司的 AI 算力底座。
给企业定制OpenClaw，这件事有没有搞头？
上面几个场景，有一个共同的前提：需要有人把它们配好。
目前在这件事上最赚钱的模式，不是自己用 OpenClaw 去做事，而是帮别人配好 OpenClaw 然后交付，国内已经有服务商单次服务费已经到数万元人民币。
这个模式的逻辑其实很简单。跨境公司老板知道自己需要 AI，但不知道具体要配什么、怎么配、配好之后维护谁来负责。这个信息不对称，就是服务价值所在。
👀
交付物是一套可以开箱即用的 OpenClaw 配置：SOUL.md 写成符合这家公司文化的人设，核心业务 SOP 转成 Skills 集合，飞书和 n8n 的接口接好，Cron 任务配置完毕，直接部署在 HEYI 硬件上寄给客户，或者上门部署。
插电，AI 员工上班。
海外跨境电商定制服务的市场价格在 500-2000 美元每个项目，企业级定制正在成为 OpenClaw 生态里增长最快的收入来源。而国内市场在这个垂直方向上几乎还是空白。
跨境电商这个圈子，懂业务逻辑的人很多，懂 OpenClaw 配置的人还很少，两者都懂的人几乎没有。
这是一个真实的时间窗口。
插电，AI 员工上班。
收费 5000 美元一台，后续 weekly 支持。
虽然Macbook对企业落地明显是不行的（后面我会介绍更专业的设备）
但这个项目——叫 RoofClaw——总收入已经超过 180 万美元，服务了 360 多家屋顶承包商。
算一笔账：全球 AI Agent 市场 2025 年 76 亿美元，年复合增长率 49.6%，2033 年预计到 1830 亿美元。全球跨境电商市场今年突破 4 万亿美元，中国出口电商逼近 3 万亿人民币。
这两个万亿级市场的交叉地带——用 AI Agent 帮跨境电商公司干活这件事，保守估计是一个千亿级的服务市场。
而现在，这个市场几乎没人系统在做。
人最终会变成 AI 的燃料
我在上周的 NGS AI跨境电商大会上说过这句话。
听着刺耳，但这就是我们团队现在的真实状态：
👀
全员从微信迁移到飞书，飞书里接入 OpenClaw。所有工作对话，AI 在旁边同步，沉淀成知识，转成 Skills，下次直接调用。这个循环跑起来之后，组织里每一次对话都在给 AI 喂燃料，让它越来越懂这个行业、懂这家公司、懂每一个具体的业务场景。
周日我还办了一场 OpenClaw 跨境电商闭门会，来的都是真在跑业务的人。
但我发现一件事——大家对 OpenClaw 在企业管理端的想象力，明显比业务端弱。
其实跨境公司的管理问题一点不比业务小：员工流失、知识断层、数据滞后、达人管理混乱，每一件都能搞垮一个正在增长的公司。
下面就把我们团队真实在跑的几个场景拆开讲，看看这千亿市场到底要怎么做？
图片
01 沉淀群聊内容为知识库，再转成Skills
公司最贵的隐性成本不是广告费，是人员流动造成的知识损耗。
一个做了两年的运营离职，他知道的平台规则、踩过的坑、和供应商的默契，全带走了。
下一个人从零开始，再踩一遍。这个循环每年都在重复。
我们现在的做法就是前面说那样，如果你也想配置的话，老实说，一点门槛没有。
我都是直接跟Claude沟通的
图片
提示词：
我想用 OpenClaw 搭建一套团队知识自动沉淀系统。
当前状况：
- 团队在飞书群里沟通日常业务
- 核心知识散落在聊天记录里，没有系统整理
- 员工离职后知识断层严重
我的诉求：
1. OpenClaw 接入飞书群，实时监听业务讨论
2. 自动识别有价值的业务经验、踩坑记录、操作规范
3. 整理后写入 AGENTS.md 对应章节（按业务模块分类）
4. 每周五自动输出一份「本周知识沉淀周报」到飞书群
请帮我设计：
1. SOUL.md 中关于知识沉淀的角色定义
2. AGENTS.md 的知识分类结构（覆盖我以下业务模块：[选品/运营/广告/供应链/达人管理]）
3. HEARTBEAT.md 的知识巡检逻辑（每小时检查一次新消息，有价值内容才处理，没有则 HEARTBEAT_OK）
4. 每周五知识周报的 Cron 配置（isolated session + announce 到飞书群）
02 让 AI 来调度企业现有的自动化工具
很多跨境公司已经有一套在跑的自动化流程：n8n 工作流、各种 RPA、定制脚本。
这些东西干活很稳，但彼此之间是孤岛。A 跑完了要不要触发 B，全靠人来盯。
OpenClaw 最适合做的就是这层调度大脑。
我在线下大会的观点
原理是这样的：
👀
OpenClaw Gateway 原生支持 Webhook 接收。在 openclaw.json 的 hooks 里开启 webhook，设好 token，n8n 工作流跑完一个任务，结果通过 HTTP POST 推到 OpenClaw 的 /hooks/agent 端点。OpenClaw 收到后启动一个 isolated session 的 agent turn，判断下一步是继续推进还是需要人工介入，异常的时候生成处理建议并推送到飞书群。
不是替换现有工具，是在上面加了一层会思考的调度层。
参考配置方案：
第一步，在 openclaw.json 里开启 Webhook：
{
"hooks":{
"enabled":true,
"token":"你的安全密钥",
"path":"/hooks",
"defaultSessionKey":"hook:n8n-dispatch",
"allowRequestSessionKey":true,
"allowedSessionKeyPrefixes":["hook:"]
}
}
第二步，n8n 工作流末尾加一个 HTTP Request 节点，POST 到 OpenClaw：
POST http://你的服务器IP:18789/hooks/agent
Header: x-openclaw-token: 你的安全密钥
Body:
{
"message": "n8n 工作流 [广告数据拉取] 执行完毕。结果：ROAS 1.8，花费 ¥3200。请判断是否异常并决定下一步。",
"name": "n8n-广告监控",
"sessionKey": "hook:n8n-ads",
"deliver": true,
"channel": "feishu",
"to": "飞书群ID"
}
第三步，在 AGENTS.md 里写入调度判断逻辑：
## n8n 工作流调度规则
当你收到 n8n webhook 回调时：
1. 解析工作流名称和执行结果
2. 对照以下阈值判断是否异常：
- 广告 ROAS 低于 [你的阈值]：异常，立刻通知
- 库存低于 [X] 天销量：异常，立刻通知
- 工作流执行失败：异常，立刻通知并附失败原因
3. 正常情况：不输出任何内容，静默处理
4. 异常情况：推送到飞书群，格式为「⚠️ [工作流名称] 异常：[具体问题] → 建议：[处理方案]」
5. 工作流依赖关系：[工作流B] 正常完成后，自动触发 [工作流C]（通过 curl 调用 n8n 的 webhook URL）
03 业务 SOP 沉淀成 Skills，才是真正的护城河
这件事我前天发过文章 教怎么把跨境电商的业务SOP转成OpenClaw的Skill
这里就不赘述，核心在于让Openclaw来反问，把业务SOP梳理清楚。
04 让老板回归「做重要决策」这件事
这是我见过最多跨境老板踩的坑：每天花一个小时看各种后台数据，看完也没做什么决策。
数据本身没有价值，数据驱动的决策才有价值。
我们团队跑了一个永不下班的决策助理。
设计逻辑：
👀
连接亚马逊广告 API、独立站 GA4、飞书多维表，每小时拉数据判断异常。ROAS 低于阈值、退款率超标、库存不足 7 天销量——才推送。其他时候沉默。每天早 9 点一份当日简报，已经带结论和建议动作，不需要老板自己算。
除了业务数据，这个 Agent 还能接收团队成员的日报周报，自动提炼关键进展和卡点，老板打开飞书看到的不是一堆文字，而是一份结构化的「需要你关注的事」清单。
老板真正需要的只有一个信息：现在哪件事需要我做决定。
配置方案：
第一步，配置数据巡检的 Cron 任务。用 isolated session，正常时不产生输出：
openclaw cron add \
--name "data-patrol" \
--cron "0 * * * *" \
--session isolated \
--message "执行数据巡检。读取 AGENTS.md 中的异常阈值规则，调用对应 API 拉取最新数据，逐项判断。如果全部正常，只回复 HEARTBEAT_OK，不要输出其他任何内容。如果有异常，输出格式：⚠️ [指标名] 异常：当前值 [X]，阈值 [Y] → 建议：[处理方案]。" \
--announce
第二步，在 AGENTS.md 里定义异常阈值：
## 数据异常阈值（根据自身业务填写）
- 广告 ROAS 低于 [X]
- 单日广告花费超过 [X] 元且 ROAS 未达标
- 退款率超过 [X%]
- 某 SKU 库存低于 [X] 天销量
- 独立站跳出率突增 [X%] 以上
- 新品上线 [X] 天内零转化
## 数据源配置
- 亚马逊广告 API：通过 Skill [amazon-ads] 调用
- GA4：通过 Skill [ga4-report] 调用
- 飞书多维表（库存/销售数据）：表格 URL [填入]
## 推送规则
- 正常不通知，异常立刻推送到飞书群 [群名]
- 紧急事项同时私信老板飞书
05 多 Agent 协作：不要一上来就搞五个 Agent
这是我最想纠正的一个误区。
我之前写过一篇文章：用OpenClaw搭跨境电商团队：5个AI员工，跑通全平台矩阵！
但很多人看了多 Agent 的教程，第一反应就是搞五六个 Agent，一个管选品、一个管广告、一个管内容、一个管达人……然后发现整个系统根本跑不起来。
问题出在哪？
第一，没有队形。五个 Agent 各干各的，谁也不知道队友在做什么，该交接的不交接，该汇报的不汇报。
第二，活派出去收不回来。OpenClaw 的 sessions_send 有个隐藏限制：等下游回复的超时只有 30 秒，超了就丢了，上游 Agent 以为对方没干活。
第三，配置项太多容易漏。每个 Agent 要单独建 workspace、绑 IM 账号、开 A2A 权限、设 Session 可见性，少一项整条链路就是废的。
正确的做法是分阶段来。
阶段一：一个主 Agent + SubAgent 模式
不需要多个独立 Agent。用一个主 Agent，复杂任务通过 sessions_spawn 派给 SubAgent 在后台跑，跑完结果自动回传。这个模式配置最简单，90% 的场景够用。
阶段二：需要多人同时对话时，上多 Agent
当你的团队里多个人需要同时跟不同的 Agent 对话（比如运营找运营助手、老板找决策助手），这时候才需要真正的多 Agent 路由。
关键配置三件事：
1. 工作区物理隔离：每个 Agent 必须有独立的 workspace，用 openclaw agents add 命令创建，不要手动建目录。
2. A2A 通信白名单：在 openclaw.json 里显式开启 agentToAgent，
{
"tools": {
"agentToAgent": {
"enabled": true,
"allow": ["lead", "ops-assistant", "ads-assistant"]
}
}
}
## 协作准则
### 委派任务后
- 收到 sessions_send 返回 { status: "accepted" } 后，如果不依赖结果，继续做下一件事
- 如果必须等结果，告知用户「已委派给 @[队友ID]，等待结果」，然后结束当前轮次
- 队友完成后会通过 sessions_send 回传唤醒你
### 接到任务后
1. 立刻在群里用 message 工具通知用户已接手（消息开头 @上游AgentID）
2. 执行任务
3. 完成后先在群里汇报结果（同样 @上游AgentID）
4. 同时必须调用 sessions_send 将结果发回给委派者，唤醒对方继续工作
3. 双重汇报协议：在每个 Agent 的 SOUL.md 里写入协作准则，解决超时问题：
并设置允许通信的 Agent 列表：
企业落地的最后一公里是设备
很多人找我问设备，这件事不能随便答
个人用户随便玩，Mac Mini 或者一台性能稍好的 PC，跑云端模型 API，完全够了。
但企业就不一样了。最近找我推荐设备的主要是两类场景，我说清楚逻辑，自己对号入座。
第一类：数据不能出门的企业。
很多跨境公司处理的内容包含客服对话、员工沟通、供应商报价、广告数据。这些东西如果全走云端 API，数据就在别人的服务器上跑了。一旦涉及竞争情报、价格策略、KOL 资源这类核心资产，云端方案会让老板很不安。
新闻已经在警告不要在工作设备上安装 OpenClaw，理由是安全风险。私人企业虽然没有这个强制要求，但数据主权的问题真实存在。
这类场景，本地部署模型是唯一干净的解法。
可以看下 行云褐蚁 的 HY50 ，是这个需求里性价比最高的入门方案。500GB 大容量内存，跑 Qwen3 235B Q4 这类 MoE 大模型没有问题，30 路并发足够覆盖一个中小团队的日常 AI 调用，HEYI 自研推理引擎把 CPU 内存带宽发挥到极致，整体预算在十万元级别。
适合：20 人以下的跨境团队，核心诉求是数据不出门、本地跑通 OpenClaw 的完整工作流。
第二类：团队并发量大，多人同时在用 Agent 的企业。
一台机器同时跑 20 个员工的 OpenClaw 请求，每个 Agent 会话又在调用子 Agent，上下文动辄几万 token，对内存带宽和并发能力的要求完全不是普通设备能撑的。
可以看下 HY NV4-6000 ，四块 NVIDIA RTX 6000 Pro，384GB 四路显存，128 路并发实测，32 路日常办公人均上下文 192K。这个配置的核心价值是：公司所有 Agent 工作流共享一套私有算力，数据主权完全自控，金融、法务、合规等对数据安全有强要求的环节可以直接跑。
适合：50 人以上的跨境企业，多个部门同时使用 OpenClaw，需要统一的私有 AI 基础设施。
如果是公司级 AI 中台，要撑全域 Agent 高频并发、大规模自动化业务流，就要上 HY NV8-6000 了：768GB 满血显存，支持 Qwen3.5、GLM 4.7等旗舰模型的原生推理，零量化损耗，总吞吐 2000+ tokens/s。这个配置就不是一个部门的需求了，是整家公司的 AI 算力底座。
给企业定制OpenClaw，这件事有没有搞头？
上面几个场景，有一个共同的前提：需要有人把它们配好。
目前在这件事上最赚钱的模式，不是自己用 OpenClaw 去做事，而是帮别人配好 OpenClaw 然后交付，国内已经有服务商单次服务费已经到数万元人民币。
这个模式的逻辑其实很简单。跨境公司老板知道自己需要 AI，但不知道具体要配什么、怎么配、配好之后维护谁来负责。这个信息不对称，就是服务价值所在。
👀
交付物是一套可以开箱即用的 OpenClaw 配置：SOUL.md 写成符合这家公司文化的人设，核心业务 SOP 转成 Skills 集合，飞书和 n8n 的接口接好，Cron 任务配置完毕，直接部署在 HEYI 硬件上寄给客户，或者上门部署。
插电，AI 员工上班。
海外跨境电商定制服务的市场价格在 500-2000 美元每个项目，企业级定制正在成为 OpenClaw 生态里增长最快的收入来源。而国内市场在这个垂直方向上几乎还是空白。
跨境电商这个圈子，懂业务逻辑的人很多，懂 OpenClaw 配置的人还很少，两者都懂的人几乎没有。
这是一个真实的时间窗口。
186 2099
