即刻App年轻人的同好社区
下载
置顶
原来 MacBook 刘海屏还有这个隐藏操作
MacBook 刘海屏最烦的，
就是顶部图标经常被挡住。
软件明明开着，
你却看不见。
想改一下顶部应用设置，
结果连入口都找不到。
真的很抓狂。
今天帮客户排查问题时，
我突然发现一个办法：
按住 Command 键，
把顶部图标往左拖。
被藏起来的图标，
就能一点点被“挤”出来。
说实话，
这一刻我还真有点被苹果这个设计惊到了。
平时骂它，
但这种小细节又确实挺巧妙。
又学到一个实用小技巧。
MacBook 刘海屏最烦的，
就是顶部图标经常被挡住。
软件明明开着，
你却看不见。
想改一下顶部应用设置，
结果连入口都找不到。
真的很抓狂。
今天帮客户排查问题时，
我突然发现一个办法：
按住 Command 键，
把顶部图标往左拖。
被藏起来的图标，
就能一点点被“挤”出来。
说实话，
这一刻我还真有点被苹果这个设计惊到了。
平时骂它，
但这种小细节又确实挺巧妙。
又学到一个实用小技巧。
3 10
龙虾🦞落地，可能比很多人想得更快
今天在上海，
和一位做“龙虾”的朋友聊了2小时
一个很明显的信号是：
很多企业已经开始主动探索 AI 的应用。
比如：
做工厂 SaaS ERP 的
在研究用龙虾做流程自动化。
做外贸的
在探索 AI 做商品上架。
甚至还有电力公司
在讨论 AI 参与电力调度。
这些需求都来自真实企业。
一个趋势很明显：
大家已经开始思考——
哪些岗位，可以交给 AI。
今天在上海，
和一位做“龙虾”的朋友聊了2小时
一个很明显的信号是：
很多企业已经开始主动探索 AI 的应用。
比如：
做工厂 SaaS ERP 的
在研究用龙虾做流程自动化。
做外贸的
在探索 AI 做商品上架。
甚至还有电力公司
在讨论 AI 参与电力调度。
这些需求都来自真实企业。
一个趋势很明显：
大家已经开始思考——
哪些岗位，可以交给 AI。
1 01
很多人问：小龙虾适合卖给谁？
我的判断其实很简单：
更适合 B 端，而不是 C 端。
C 端是消费思维，大家会比价格。
B 端是生意思维，只看值不值。
如果小龙虾能帮企业做内容、做自动化、做获客，
那它其实就是一个 24 小时在线的数字员工。
所以如果想用小龙虾创业，
与其做工具给普通人玩，
不如直接做解决方案给企业用。
我的判断其实很简单：
更适合 B 端，而不是 C 端。
C 端是消费思维，大家会比价格。
B 端是生意思维，只看值不值。
如果小龙虾能帮企业做内容、做自动化、做获客，
那它其实就是一个 24 小时在线的数字员工。
所以如果想用小龙虾创业，
与其做工具给普通人玩，
不如直接做解决方案给企业用。
1 00
和客户在酒店，打磨他的龙虾 🦞AI 获客助手
很多人做内容，最先问的是：
怎么追热点，怎么冲流量，怎么做爆款。
但真正想做生意的人，问的往往不是这个。
客户今天跟我反复确认的一件事是：
不要假热闹，
要真获客。
宁愿内容播放不高，
也要能吸引精准客户；
宁愿粉丝不多，
也不要一堆看起来很漂亮、实际转化为零的数据。
所以今晚我们做的，不只是“聊内容”。
而是把整个流程一环一环打磨清楚，
把 龙虾🦞 工作流真正落到业务上，
把他的小龙虾，养成一个能持续干活的超级助手。
以后比的不是谁更会蹭热点，
而是谁先拥有一套稳定获客的内容系统。
很多人做内容，最先问的是：
怎么追热点，怎么冲流量，怎么做爆款。
但真正想做生意的人，问的往往不是这个。
客户今天跟我反复确认的一件事是：
不要假热闹，
要真获客。
宁愿内容播放不高，
也要能吸引精准客户；
宁愿粉丝不多，
也不要一堆看起来很漂亮、实际转化为零的数据。
所以今晚我们做的，不只是“聊内容”。
而是把整个流程一环一环打磨清楚，
把 龙虾🦞 工作流真正落到业务上，
把他的小龙虾，养成一个能持续干活的超级助手。
以后比的不是谁更会蹭热点，
而是谁先拥有一套稳定获客的内容系统。
0 00
上午去一位朋友公司，聊了聊「小龙虾」在企业里的落地玩法，顺便帮他们把内容生产的工作流拆了一遍，还画了一版 SOP。
很多人一开始都会误会一件事：
觉得只要有了小龙虾，就能自动产出好内容。
但其实不是。
小龙虾只是工具，真正决定结果的，是背后的 SOP 内容生产流程。
只有把选题、素材、生成、二次加工这些步骤流程化，它才有可能稳定产出结果。
但这里面有一个挺大的变化：
以前我们用的是「软件工具」，
现在更像是在 养一个数字员工。
为什么这么说？
因为它有三个很像员工的特征：
1. 有长期记忆，可以被持续训练，越用越懂你的业务
2. 可以部署在服务器上 24 小时运行，一直在线
3. 可以主动给你发消息、推送结果，而不是等你去打开软件
所以交互方式其实已经变了。
以前是：
人 → 打开工具 → 操作软件。
现在更像是：
人 → 给员工下任务 → 等结果。
谁能把这套 SOP 打磨出来，
内容生产就真的可以开始自动化了。
很多人一开始都会误会一件事：
觉得只要有了小龙虾，就能自动产出好内容。
但其实不是。
小龙虾只是工具，真正决定结果的，是背后的 SOP 内容生产流程。
只有把选题、素材、生成、二次加工这些步骤流程化，它才有可能稳定产出结果。
但这里面有一个挺大的变化：
以前我们用的是「软件工具」，
现在更像是在 养一个数字员工。
为什么这么说？
因为它有三个很像员工的特征：
1. 有长期记忆，可以被持续训练，越用越懂你的业务
2. 可以部署在服务器上 24 小时运行，一直在线
3. 可以主动给你发消息、推送结果，而不是等你去打开软件
所以交互方式其实已经变了。
以前是：
人 → 打开工具 → 操作软件。
现在更像是：
人 → 给员工下任务 → 等结果。
谁能把这套 SOP 打磨出来，
内容生产就真的可以开始自动化了。
3 10
Codex 可能是现在最被低估的产品之一。
很多人都在聊 OpenClaw。
但我这几天实际折腾下来，真正适合干重活的，反而是 Codex。
OpenClaw 安装并不简单。
要装 Node.js 相关包，要跑多个命令，中间还会遇到各种环境问题。
所以最简单的办法不是自己硬啃，
而是直接给 Codex 一句提示词：
“请帮我安装 OpenClaw，遇到问题请自己解决。”
它会自己排查依赖、处理报错、查文档，把流程一步步跑通。
后面接飞书也是一样，我只负责去后台找 API ID 和密钥，剩下的交给 Codex。
而真正想把 OpenClaw 用好，核心其实是 Skills。
如果觉得 Skills 很抽象，
你可以把它理解成一个可反复调用的专用能力包。
比如做一个“PPT 生成 Skill”：
以后我只要给它一个大纲，它就按预设好的结构、风格和规则，自动生成一份 PPT。
所以 Skills 不是几句提示词。
它更像是你把一套成熟方法论，沉淀成了一个可复用的工程资产。
既然是资产，就该像工程一样管理。
用 Codex 去写，用 GitHub 去备份。
改坏了还能回滚。
这也刚好说明了两者最合理的分工：
Codex 更适合工程层。
装环境、修问题、写代码、写 Skills、改模板。
而且如果你是 ChatGPT Plus 用户，直接用 Codex 写代码，不用额外走 API，不用额外花钱。
OpenClaw 更适合使用层。
它更像一个可以聊天的 AI 助手，适合你直接发任务，让它调用技能去执行。移动端尤其顺手。
如果只是这一次结果不满意，
比如第一页文字太多了、第二页标题不够好、某一页风格不对，
其实直接在 OpenClaw 里继续对话调整就行。
因为这类都属于一次性的结果微调，
本质上是在改这次的输出，不会影响到底层的 Skills。
只有当某个问题反复出现，
你才值得回到底层，用 Codex 去改 Skill 本身。
所以我现在越来越觉得：
Codex 负责底层工程
OpenClaw 负责上层交互
写代码、搭 Skills、修环境，用 Codex。
调用技能、执行任务、微调结果，用 OpenClaw。
我甚至看到有人直接让 OpenClaw 的自愈器去改 Skills，最后把自己给改崩了。
本质上不是 Skills 不行，而是这类底层工程，本来就更适合交给 Codex。
把 Skills 当成资产，把代码当成工程，把 GitHub 当成备份。
这样整个工作流才更稳。
很多人都在聊 OpenClaw。
但我这几天实际折腾下来，真正适合干重活的，反而是 Codex。
OpenClaw 安装并不简单。
要装 Node.js 相关包，要跑多个命令，中间还会遇到各种环境问题。
所以最简单的办法不是自己硬啃，
而是直接给 Codex 一句提示词：
“请帮我安装 OpenClaw，遇到问题请自己解决。”
它会自己排查依赖、处理报错、查文档，把流程一步步跑通。
后面接飞书也是一样，我只负责去后台找 API ID 和密钥，剩下的交给 Codex。
而真正想把 OpenClaw 用好，核心其实是 Skills。
如果觉得 Skills 很抽象，
你可以把它理解成一个可反复调用的专用能力包。
比如做一个“PPT 生成 Skill”：
以后我只要给它一个大纲，它就按预设好的结构、风格和规则，自动生成一份 PPT。
所以 Skills 不是几句提示词。
它更像是你把一套成熟方法论，沉淀成了一个可复用的工程资产。
既然是资产，就该像工程一样管理。
用 Codex 去写，用 GitHub 去备份。
改坏了还能回滚。
这也刚好说明了两者最合理的分工：
Codex 更适合工程层。
装环境、修问题、写代码、写 Skills、改模板。
而且如果你是 ChatGPT Plus 用户，直接用 Codex 写代码，不用额外走 API，不用额外花钱。
OpenClaw 更适合使用层。
它更像一个可以聊天的 AI 助手，适合你直接发任务，让它调用技能去执行。移动端尤其顺手。
如果只是这一次结果不满意，
比如第一页文字太多了、第二页标题不够好、某一页风格不对，
其实直接在 OpenClaw 里继续对话调整就行。
因为这类都属于一次性的结果微调，
本质上是在改这次的输出，不会影响到底层的 Skills。
只有当某个问题反复出现，
你才值得回到底层，用 Codex 去改 Skill 本身。
所以我现在越来越觉得：
Codex 负责底层工程
OpenClaw 负责上层交互
写代码、搭 Skills、修环境，用 Codex。
调用技能、执行任务、微调结果，用 OpenClaw。
我甚至看到有人直接让 OpenClaw 的自愈器去改 Skills，最后把自己给改崩了。
本质上不是 Skills 不行，而是这类底层工程，本来就更适合交给 Codex。
把 Skills 当成资产，把代码当成工程，把 GitHub 当成备份。
这样整个工作流才更稳。
3 00