作者： wuxiumu

想挣钱却没办法？2026 年的答案：一人 + AI，把焦虑变成系统
金句开头：挣钱的本质不是「更努力」，而是「找到能复利的支点」——这个支点，在 2026 年，很可能是 AI 帮你把时间变成可复制的系统。

一、满脑子想挣钱却没办法——你缺的不是努力，是杠杆

很多人每天满脑子想挣钱，却不知道从哪下手。
不是懒，不是笨，而是没有杠杆。

传统杠杆只有两种：
要么卖更多时间（加班、接更多单），要么雇更多人（招团队、开公司）。
前者有天花板，后者有门槛。

2026 年的新杠杆是：用 AI 把「你一个人」变成「一个可复制的系统」。
- 年薪 150 万的工作，有人用 500 美金的 AI 完成；
- 日更 10 万+ 的自媒团队，有人花 0 元用 OpenClaw 搭出来；
- 亚马逊电子书，有人用 AI 制作，每月悄悄进账数千美金。
这些不是鸡汤，是已经发生的现实。
区别在于：他们找到了「一人 + AI」的支点，而你还在用「一人 + 时间」硬扛。

二、一人公司的本质：不是一个人干，是系统在你不在时还能产出

一人公司最容易被误解成「一个人包揽一切」。
真正的定义是：你的系统能在你不在线时，还能产出多少。

成功的一人公司，至少满足三条硬标准：
1. 可持续：不靠透支身体，能稳定运行 12 个月以上
2. 可复利：收入不完全线性绑定时间（有产品化、内容资产、口碑积累）
3. 可防守：遇到平台波动、流量变化、身体问题，不会立刻归零
这三条背后，不是「更努力」，而是三套系统：现金流系统、增长系统、抗风险系统。

起步形态从易到难：
- 产品化服务：把能力包装成标准套餐，交付范围固定、可复制
- 内容 + 咨询/训练营：用内容获客，用咨询变现
- 小而美工具/SaaS：更强复利，但需要更长周期
先做产品化服务或内容变现，验证需求与定位，再决定是否走重产品路线。

三、OpenClaw：从「玩具」到「生产系统」的跨越

OpenClaw 正在成为一人公司的标配工具。

它能做的事，已经超出「写脚本」的范畴：
- 反爬网站：要登录、有反爬？不写脚本，OpenClaw 直接上手干
- 小红书全自动图文：一套 SOP，用 OpenClaw 就够了
- 日更 10 万+：0 元搭个「自媒团队」，同事以为你招了 5 个实习生
- 开发团队：OpenClaw + Codex/ClaudeCode Agent Swarm，一人搭建开发团队
但很多人把它当玩具用：跑个 demo、试试 Agent、写点小脚本。
结果一上生产，磁盘爆满、内存报警、日志乱成一锅粥。

真正的用法：把它当系统对待——专用目录、资源限制、监控、可读日志、紧急刹车。
你对它的态度，决定了它是玩具，还是系统。

四、把互联网变成 API：Grease AI 与 CoPaw 的启示

AI Agent 时代，缺的不是模型，而是把现实世界接进来的能力。
- Grease AI：把互联网变成 API，面向 AI Agent 的低代码 API 开发平台
- 阿里 CoPaw：桌面级 Agent 工具，让钉钉/飞书秒变数字员工
本质都在做同一件事：降低「人机协作」的接入成本。

以前你要写爬虫、对接 API、处理反爬；
现在，用低代码或现成 Agent，就能把网页、办公软件、聊天工具串起来。

一人公司的增长逻辑，正在从「我去哪里引流」变成「我的系统能自动触达多少人」。

五、内容资产：公众号、电子书、小红书——复利的起点

一人公司的增长，最稳的方式是把定位讲清楚：

我帮谁，在什么场景下，解决什么问题，用什么方法，能带来什么结果。

内容资产是长期复利的核心：
- 微信公众号：玩对推荐机制，才有机会被系统推荐
- 亚马逊电子书：AI 制作的电子书正在闷声发大财，每月悄悄进账数千美金
- 小红书：全自动图文 SOP，用 OpenClaw 就能跑起来
你越具体，越容易被搜索、被推荐、被记住。
增长系统两条腿：内容资产（SEO/GEO） + 关系网络（合作/转介绍）。

六、Dan Koe 的一日计划：不是束缚，是操作系统补丁

很多人想挣钱，却连「今天该干什么」都理不清。
Dan Koe 的《How to fix your entire life in 1 day》给了一个极简框架：

把一天拆成几个块：
- 深度工作块
- 学习输入块
- 表达输出块
- 身体修复块
- 关系与存在感块
一日计划 = 把这几个块，合理排进 24 小时。

它不是 To-do 清单，而是一种默认节奏。
成功运行 60% 也比 0% 好太多。
人生不是被某一件大事彻底重启的，而是被无数次「当日重新对齐」，一点一点拧回你愿意走的方向。

七、小结：从焦虑到系统

想挣钱却没办法，本质是缺杠杆、缺系统、缺复利。

2026 年的答案很清晰：
1. 选对模式：一人公司优先产品化服务/内容变现
2. 用好工具：OpenClaw、Grease AI、CoPaw——把时间变成可复制的系统
3. 建内容资产：公众号、电子书、小红书，用 SEO/GEO 做长期复利
4. 管好每一天：Dan Koe 的一日计划，让「块」成为你的默认节奏
你不是要更努力，而是要找到支点。
这个支点，就是一人 + AI。

AI 解读

1. 问题本质拆解
- 表层：满脑子想挣钱却没办法，怎么办？
- 深层：缺的不是努力，而是杠杆。传统杠杆（卖时间、雇人）有天花板；新杠杆是「一人 + AI」，把时间变成可复制的系统。
2. 核心逻辑链
- 一人公司 = 系统在你不在时还能产出
- 成功标准 = 可持续、可复利、可防守
- 工具链 = OpenClaw（自动化）+ Grease AI/CoPaw（接入现实世界）
- 增长 = 内容资产（SEO/GEO）+ 关系网络
- 执行 = Dan Koe 一日计划（块思维）
3. 与 Skill 体系的映射
- skill.openclaw.sandbox.setup / skill.openclaw.runtime.guard：生产级部署
- skill.life.os.one-day-plan：日级执行节奏
- skill.seo.foundation.builder：内容资产建设
- 一人公司相关 Skill：范围管理、模板化、支持分层
4. 行动视角
- 不要从「我要更努力」出发，而是从「我的系统能自动产出什么」出发
- 先验证产品化服务或内容变现，再考虑重产品
- 把 OpenClaw 当系统对待，而不是玩具
分类：创业与商业 · AI 工具与编排 · 个人成长与系统设计

关键词：一人公司,OpenClaw,AI 杠杆,变现,内容资产,Dan Koe,CoPaw,Grease AI,系统思维

来源：
1. 每天满脑子都想挣钱，但是没有办法怎么办？
  https://www.zhihu.com/question/571005780/answer/1971131470350352810
2. 这些AI制作的电子书正在闷声发大财，亚马逊电子书每月悄悄进账数千美金！
  https://zhuanlan.zhihu.com/p/2002780805374690642
3. 网站要登录还反爬？我不写脚本了，OpenClaw 直接上手干！
  https://zhuanlan.zhihu.com/p/2009715623417095363
4. 小红书全自动图文SOP，用 Openclaw 就够了！
  https://zhuanlan.zhihu.com/p/2008700494474938353
5. Grease AI：把互联网变成 API——面向 AI Agent 的低代码api开发平台
  https://zhuanlan.zhihu.com/p/2011191976188475103
6. 微信公众号怎么玩才有机会被系统推荐？
  https://www.zhihu.com/question/448280296/answer/2009027237618394207
7. 如何去做成功一人公司？
  https://www.zhihu.com/question/6205562565/answer/2010132254534420037
8. OpenClaw杀疯了！我花0元搭了个日更10万+的自媒团队，同事以为我招了5个实习生
  https://zhuanlan.zhihu.com/p/2011129220533876300
9. openclaw有哪些好用的skill？
  https://www.zhihu.com/question/2006661884057769505/answer/2010864131717230774
10. Dan Koe《How to fix your entire life in 1 day》中英对照全文（完整版无删减）
  https://zhuanlan.zhihu.com/p/2008584960232141141
11. 年薪150万的工作，我用500美金的AI完成：个人业务Agent升级指南
  https://zhuanlan.zhihu.com/p/2010849793069556211
12. 刚刚，阿里开源 CoPaw 桌面级 Agent 工具，让钉钉/飞书秒变数字员工
  https://zhuanlan.zhihu.com/p/2011135750872264941
13. OpenClaw + Codex/ClaudeCode Agent Swarm: 一人搭建开发团队
  https://zhuanlan.zhihu.com/p/2010324070751826756
2026年2月28日
Dan Koe 的一日计划：重启人生，不是多做，而是「每天做对几件事」
金句开头：重启人生，不是从明天开始变成另一个人，而是从今天开始，用同样的 24 小时，活出一套不一样的默认设置。

一、为什么我们总想「从明天开始好好过」，却一拖再拖？

几乎每个人都对自己说过类似的话：
- 「这周太忙，下周开始早睡早起。」
- 「这个项目做完，我就好好规划一下人生。」
- 「等工作没那么乱了，我再系统地学习一下。」
结果往往是：
- 这周结束了，下周更忙；
- 这个项目完了，下一个项目排上来；
- 越是乱的时候，越没力气去「系统化」。
我们太容易把「改变」想得太宏大：

好像只有换城市、换工作、换赛道，才配叫「重启人生」。

Dan Koe 的一日计划，厉害的地方在于，它把这个问题暴力降维了：
- 不讨论「十年之后想成为什么样的人」；
- 只讨论「今天这 24 小时，能不能被装进一个更好的容器」。
你不用一夜之间变完美，你只需要：

从今天开始，让你的每一天，有一套稳定的「默认轨道」。

二、Dan Koe 的一日计划，本质是一个「人生最小运行单元」

如果你从系统角度去拆，会发现他讲的东西，其实可以收敛成几个很简单的块：
1. 深度工作块：真正推动你长期目标的那部分输出；
2. 学习输入块：把外部世界有价值的信息，吃进你的系统；
3. 表达输出块：把你的观点、作品、代码、内容抛到世界上；
4. 身体修复块：睡眠、运动、饮食这些最基础的维持；
5. 关系与存在感块：与重要的人、事保持连接。
你可以完全不记任何细节，只记住一句：

一日计划 = 把这几个块，合理排进 24 小时。

它不是 To-do 清单，而是一种「默认节奏」：
- 不需要你每天重新发明生活，只需要你每天把这几个块「点亮」。
三、如果用「普通人的现实」，怎么落地一日计划？

很多人看一日计划时会有抗拒感：
- 「我又不是全职创作者，哪有那么多时间？」
- 「我每天加班到九点，怎么可能再安排深度工作？」
但一日计划最实用的地方就在于：它可以被缩放。

1. 上班族版本（8 小时打工 + 通勤）

你可以给自己一个「极简版容器」：
- 早晨 30–60 分钟：
  - 轻度输入 + 一点小输出（读几页书 / 写 200 字 / 画一个小思维导图）；
- 中午/碎片时间 20–30 分钟：
  - 只做一个动作：整理今天/本周最重要的 3 件事；
- 晚上 60–90 分钟（不刷短视频的那部分）：
  - 1 个深度工作块：写一篇博文/改一个 side project/系统复盘一段时间。
重点不是一口气塞满，而是：每天哪怕只有一块，是明确用来「为自己积累」的。

2. 自由职业 / 一人公司版本

你的自由，并不意味着你有「无限时间」—— 反而意味着你更需要一日计划来防止自己被拉垮。

一个简单的模板可以是：
- 上午：2–3 小时深度工作（项目/客户/产品）；
- 下午前半段：沟通、运营、售后等「外部能量消耗」块；
- 下午后半段：学习 & 试验新 Skill；
- 晚上：内容输出（文章/视频/直播）+ 轻度社交。
你可以随意调整顺序，但最好保证：

每天至少有「一块只为长期目标服务的时间」，而不是全部被短期任务吃掉。

四、一日计划最难的部分，其实不是执行，而是「愿意接受自己的版本不完美」

很多人一开始看这种一日计划，就给自己套上了无形的枷锁：
- 「要么严格执行，要么干脆不做。」
结果就是：
- 第一天兴冲冲地照表执行；
- 第三天被一个加班打乱节奏；
- 第五天因为一次「没做到」陷入自责；
- 第七天干脆把整个计划扔进回收站。
但如果你把「一日计划」看成一个 Skill，就会发现一个更健康的视角：

它不是一份「天天必须 100 分」的考卷，而是你每天尝试加载的一段程序，成功运行 60% 也比 0% 好太多。

你可以在日历上给自己做一个「点亮统计」：
- 今天有深度工作块吗？
- 今天有输入块吗？
- 今天有输出块吗？
- 今天有照顾身体/关系的一小块吗？
每点亮一个，就给自己划一笔。一个月下来，你看到的不是「完美执行」的天数，而是「系统正在被越来越多天支撑」的趋势。

五、小结：一日计划不是「束缚」，是你给自己的「操作系统补丁」

如果你把人生比作一个长周期的系统，那么：
- 年，是策略层；
- 月，是节奏层；
- 日，是执行层。
Dan Koe 的一日计划，做的就是在「日」这一层，给你打一个**「最小可行操作系统补丁」**：
- 它不保证你马上变富、变强；
- 它只保证：
  - 你的每一天，都有一点时间在为「长期的你」打工；
  - 你的生活，不再完全被外界任务/通知/情绪支配。
当你真的「连续 30 天，大致活在自己的版本的一日计划里」，你回头看，很可能会发现：

人生并不是被某一件大事彻底重启的，而是被无数次这样的「当日重新对齐」，一点一点地，拧回了你愿意走的方向上。

AI 解读

1. 问题本质
- 表层：Dan Koe 的一日计划到底有啥用？
- 深层：如何把「重启人生」从一个宏大抽象的愿望，变成一个每天可以执行的「最小运行单元」。
文章通过「块」的概念（深度工作/输入/输出/身体/关系），把一日计划从「理想生活作息表」降级为「可被不同身份缩放的容器」。

2. 与 Skill 体系的映射
- 对应 SKILL-DIRECTORY.md 中：
  - skill.life.os.one-day-plan（一日操作系统模版）；
  - 并与 skill.life.os.365-reset（年度重置）形成日-年两级联动。
- 文中给出的上班族/自由职业两种版本，可以直接变成这个 Skill 的参数化实现。
3. 行动视角的转变
- 重点不在于「执行标准化的一日计划」，而在于：
  - 接受「60% 成功」也值得记录；
  - 用「点亮块」的方式给自己正反馈；
  - 把焦点从「追求完美」转到「让系统持续运行」。
4. 扩展建议
- 你可以在 api.xyxbot.com 下实现一个 skill.life.plan.dan-koe-day：
  - 输入：身份类型（上班族/自由职业/一人公司）、可支配时间段；
  - 输出：今天的「块排布」+ 建议要点；
- 再叠一个简单的打卡前端，让用户每天只需要回答：
  - 今天点亮了几个块？
  - 哪一块最难？哪一块最有收获？
分类：个人成长与系统设计

关键词：Dan Koe,一日计划,人生重启,时间管理,深度工作,习惯养成,个人操作系统,系统思维,长期主义

来源：专栏文章：Dan Koe的一日计划：重启人生 https://zhuanlan.zhihu.com/p/2006310820859109517
2026年2月24日
大模型接入聊天软件：别只看「能不能用」，先想「怎么活得久」
金句开头：给聊天软件接大模型，真正的难点从来不是「调得通」，而是「挂得住」——能跑一天不算本事，能稳稳跑半年，才配叫系统。

一、为什么所有人都想「把 AI 塞进聊天软件」？

因为这是最自然的入口：
- 你的团队已经习惯在微信/飞书/企微里沟通；
- 你的工作节奏，本身就是围绕 IM 消息在转；
- 你每天看最多的界面，不是 IDE，不是浏览器，而是聊天窗口。
一旦大模型进了聊天软件，它立刻就从「一个要你特地打开的工具」，变成「随手就能召唤的同事」：
- 帮你总结会议纪要；
- 帮你重写需求说明；
- 帮你抓 PR 里的关键改动点；
- 帮你翻译、润色、做脑暴。
问题是——

「能连上」和「敢长期用」，中间隔着一整层工程现实。

很多人在最开始接的时候，只关注了：
- Webhook 怎么配？
- Access Token 怎么拿？
- 请求怎么转发给 OpenClaw / 模型服务？
但当它真的开始在团队日常跑起来，你才会发现：
- 消息风暴、调用风暴、账单风暴，都可能接踵而至。
所以，我们得换一个视角来看这个问题：

不做「能跑一次的集成」，而是做「能活很久的集成」。

二、接入聊天软件，本质上是在新增一个「高频流量入口」

在你接入之前，你所有的 AI 调用，大概是这样触发的：
- 你打开一个网页 / 工具；
- 在里面输入内容；
- 手动点一下「Send」。
调用频率受你「主动使用」控制，你累了停，项目完了停。

而当你接入聊天软件之后，情况悄悄变了：
- 成员随手一 @ 就能触发；
- 其他应用的机器人也可能把消息转给它；
- 某些「群」里，可能一天几百条触发请求。
你相当于在你的 AI 服务前面，打开了一个高频入口。

如果这个入口没有配好「节流阀」「熔断器」「黑名单」「超时策略」之类的东西，你就等着某天被它拖着「一起下水」。

三、一个「敢长期用」的 IM + Agent 架构，至少要有这几层

用最简化的语言，可以拆成四层：
1. 入口层（IM 平台）：收消息的地方；
2. 路由层（Bot 网关）：决定「要不要理」「谁来理」「怎么理」；
3. 智能层（OpenClaw / 大模型 / Skills）」：真正干活的地方；
4. 治理层（日志、限流、监控、配置）」：确保它今天活着，明天还能活。
很多 Demo 停在第 2 层：
- 消息一来，简单判断一下是私聊/群聊，
- 然后直接把文本丢给模型，
- 模型输出结果再原路丢回去。
这种 Demo 特别容易给你一种错觉：

「这也不难嘛，我下午就能接一个。」

可一旦你想让它：
- 真正在公司群里跑；
- 真正帮人干活而不是逗乐；
- 真正承担一部分日常任务；
你就得开始严肃对待第 3、4 层。

四、几个你迟早会遇到、最好一开始就预设的坑

1. 滥用与误触发

只要大家发现「这个机器人挺好玩」，接下来你就会看到各种各样的「非生产调用」：
- 好奇心测试；
- 闲聊；
- 玩笑式调侃。
这没什么错，但如果你没有任何限制：
- 调用量会暴涨；
- Token 会狂烧；
- 正经用户反而容易被「限流」影响体验。
解决思路：
- 区分「生产群」和「娱乐群」，配置不同的频率上限；
- 对某些命令强制要求特定前缀（比如 /ai 开头才触发）；
- 给每个用户/群做简单的「配额」计数。
2. 权限与隐私边界

把大模型塞进聊天软件的同时，你也给了它一个极大的观察窗口：
- 谁在说什么；
- 某些敏感业务讨论；
- 某些还没落地的想法。
如果你再顺手把这些内容转给外部 API（第三方模型服务），那就必须非常清楚：
- 哪些内容绝对不能出这台服务器；
- 哪些群、哪些关键词，一旦出现就要禁止外发；
- 是否需要对某些内部标识做匿名化 / 脱敏处理。
否则，你其实是在「无意中开了一个超级监控摄像头」给外部服务。

3. 单点故障与降级策略

当所有人习惯了在聊天软件里 @AI 处理事情时，你相当于在团队协作里增加了一个「关键依赖」。

如果有一天：
- 模型服务挂了；
- 网络出问题了；
- 或者你的 OpenClaw 节点崩了；
大家会突然发现：

「咦，怎么少了一个已经被依赖的能力？」

所以你需要为它准备：
- 简单明了的「服务状态提示」（比如：当前服务不可用，请稍后重试）；
- 明确的「人工兜底方式」（比如：给出一条说明如何手工完成这件事）；
- 必要时的「自动降级」（比如，从复杂推理降级为简单检索）。
目标不是「永不出错」，而是「出错时，团队不会集体懵」。

五、让「AI 进聊天软件」真正产生价值的关键：选对场景

最后一个也是最常被忽略的点：

不是所有能力都适合塞进聊天软件。

聊天环境有几个特点：
- 碎片化、实时、轻量；
- 操作最好在几条消息之内完成；
- 不适合复杂、多步骤、多界面的交互。
因此，你在挑选接入场景时，可以用两条简单规则过滤：
1. 是否「聊两句」就能完成大部分价值？
  - 适合：总结、润色、翻译、简单问答、提取结构化信息；
  - 不适合：需要复杂表单、多轮复杂配置、重度可视化的任务。
2. 这个场景，在团队里「一天会发生很多次」吗？
  - 适合：
    
    每日/每周固定要写的东西（日报、纪要、周报）；
    
    频繁出现的小问题（简单技术问答、文案修改）；
  - 不适合：
    
    一年就发生两三次的冷门操作。
IM 里最有价值的 AI，不是那个什么都能做的，而是那个「老是帮你做那几件烦事」的。

六、小结：从「接入一次」到「长期共存」

如果用一句话总结这篇的主线：

「大模型接入聊天软件」不该被当成一个炫技的 PoC，而应该被当成一个长期在线的团队成员来设计。

这意味着：
- 你要替它想好：工作边界、调用节奏、权限范围、出错姿态；
- 你要把它纳入现有的监控、日志、告警体系，而不是当成一个黑盒插件；
- 你要愿意花时间选对 2–3 个高频但低风险的场景，而不是一上来就「什么都想让它干」。
当你愿意用「系统心态」而不是「玩具心态」看待这件事时，你会发现：
- 它不再是一个偶尔被惊叹一下的酷玩意儿；
- 而是一个虽然偶尔会犯点小错、但总体上在帮你省时间、省心智的「数字同事」。
这时候，「接不接得上」已经不重要了，真正重要的是——

你有没有给它一个，足够安全、足够清晰、足够可持续的位置。

AI 解读

1. 问题本质
- 表面是在讲「如何用 OpenClaw 把大模型接入聊天软件」；
- 实际是在讨论一个更深的议题：「如何把一个 AI 能力，以团队能够长期承受的方式嵌入协作系统。」
2. 结构拆解
- 先解释为什么聊天软件是大模型的天然入口（高频、自然、低门槛）；
- 再指出「能连上 ≠ 敢长期用」的关键差异；
- 从入口、路由、智能、治理四层拆解一个可长期运行的架构；
- 结合滥用/权限/故障三个常见坑，给出防御性设计思路；
- 最后用「场景筛选」帮助读者聚焦在真正有价值的用法上。
3. 与 Skill 体系的映射
- 对应 SKILL-DIRECTORY.md 中的：
  - skill.agent.chat-integration（IM 接入架构与实现）；
  - 以及隐含依赖：skill.openclaw.runtime.guard（监控与限流）。
- 文中给出的「四层架构 + 三类坑 + 场景筛选规则」，可以直接变成这个 Skill 的实现说明书。
4. 系统化演进建议
- 在 api.xyxbot.com 下实现一个 skill.agent.im.connect，标准化不同 IM 平台的接入配置；
- 再叠一个 skill.guard.anti-abuse，专门处理 IM 入口的频率控制、权限控制与异常告警。
分类：AI 工具与编排

关键词：大模型,聊天软件,OpenClaw,IM集成,Agent接入,限流,权限控制,监控告警,系统设计

来源：专栏文章：大模型接入聊天软件：OpenClaw 源码剖析与完整中文部署方案 https://zhuanlan.zhihu.com/p/2009642991464232635
2026年2月24日
【day12】更新大神 Dan Koe 推荐的 12 本书：不是多读，而是「把书读进系统里」
金句开头：真正改变人生的，不是你读了多少本书，而是有多少本书，最终变成了你的人生操作系统的一部分。

一、为什么「大神书单」常常看完就算了？

看到 Dan Koe 推荐的 12 本书，你大概会有两种心情：
- 一方面很兴奋：这些书看起来都很厉害，豆瓣/亚马逊评分也很高；
- 另一方面又有点无力：
  - 12 本书什么时候读得完？
  - 读完之后我能记住多少？
  - 我现在这么乱，这 12 本到底能帮我解决什么？
我们太习惯把「大神书单」当成一种精神消费——

收藏的时候觉得自己已经变厉害了一点，读完之后发现，生活照旧，行为没什么变化。

问题并不出在书上，而是出在我们对「读书」这件事的要求太低：
- 把书当信息来源，而不是当系统组件。
Dan Koe 推荐的这 12 本书，本质上是一套「搭建人生系统的零件包」。关键不在于你是不是全读完，而在于：

你能不能用其中几本，先把自己的人生系统「搭出一个雏形」。

二、这 12 本书，隐含着一套「人生系统分层」

不同人会给这 12 本书分不同类，但如果你站在「系统」视角去看，会发现一个有趣的结构：
1. 底层操作系统类
  - 关于「你怎么思考」「你怎么决策」：
  - 思维模型、第一性原理、长期主义、杠杆、复利……
2. 生产力与执行类
  - 关于「你怎么安排时间」「你怎么完成事情」：
  - 时间管理、精力管理、任务管理、习惯建立……
3. 商业与价值类
  - 关于「你怎么在市场里创造和捕获价值」：
  - 一人公司、个人品牌、产品思维、营销模型……
4. 意义与存在类
  - 关于「你为什么要这样活」「你在意的到底是什么」：
  - 人生意义、价值观、关系、死亡与有限生命……
这 12 本书并不是 12 条平行的知识线，而是：

从「你这个人怎么运转」到「你这一生怎么运转」的一套多层系统。

如果你只是按顺序看过去，很容易淹没在信息里；但如果你带着「我要升级这个层」的目的去读，每一本书都会变得很不一样。

三、如何把 12 本书变成一个「一年的重装计划」？

与其问「要不要全读完」，不如先给自己一个现实又有力量的目标：

用一年时间，围绕这 12 本书，重装一次自己的人生系统。

你可以粗糙地这么分配：

第 1 季度：打好「思维底座」

目标：补足底层操作系统——你怎么看世界、怎么看自己。
- 选 2–3 本偏「思维模型/认知升级」的书；
- 每读完一本，只做两件事：
  1. 写下书里最打动你的 3 条规则；
  2. 选其中 1 条，设计一个「可以在本周实践的小动作」。
重点：不是记住书里的所有观点，而是把某一个观点「装进生活」。

第 2 季度：升级「日常运行机制」

目标：把时间、精力、任务这些日常变量串起来。
- 选 2–3 本关于时间管理、精力管理、习惯的书；
- 不要再给自己定「我要变得更自律」这种空目标，而是问一句：「我接下来 90 天，只做哪一件小改变？」
比如：
- 每天固定一个「深度工作时段」；
- 把手机从卧室赶出去；
- 用一个统一的工具管理任务，而不是到处记。
重点：让这些书帮你建立「一天」这个最小运行单元的秩序。

第 3 季度：构建「对外创造价值的系统」

目标：不再只用时间换钱，而是开始搭「可以复利的价值系统」。
- 选 2–3 本偏商业、一人公司、产品/品牌的书；
- 不要求你立刻创业、辞职，但至少可以：
  - 明确一个你愿意长期写/做的主题；
  - 搭建一个最小的对外表达渠道（博客 / 公众号 / Newsletter）；
  - 设计一个「从免费内容到付费价值」的粗糙草图。
重点：哪怕只是拉出一条「边上班边练习的副线」，也是在给未来的自己留退路。

第 4 季度：回头看「我这条路想通向哪里」

目标：不迷失在系统里，记得系统服务的是「人生」，不是 KPI。
- 选 2–3 本更偏「意义／自我／关系」的书；
- 在年底，认真回答几个问题：
  - 如果系统跑得很好，但我不快乐，这系统还算成功吗？
  - 我要用这套能力，去换什么样的生活？
  - 哪些是在意的人、在意的事，我这一年其实忽略了？
重点：不让「效率」压扁「存在感」。

四、别再问「我能不能全部读完」，先问「我愿不愿意让一本书改变一点点行为」

Dan Koe 推荐这 12 本书，对他来说，也是一套「回望式的总结」：
- 哪些书，在不同阶段给了他某种关键的杠杆；
- 哪些观念，最后真正长成了他今天的系统。
对我们来说，更现实的问题不是：
- 「我能不能像他一样做到那种程度？」
而是：
- 「我愿不愿意让这 12 本里的某一本，真正改变我一点点具体的行为？」
当你用这个问题来筛选，你会发现：
- 有的书适合当作「信息补充」，
- 有的书值得当成「操作系统补丁」；
- 而那些真正改变你的书，往往不是你当时看得最爽的那一本。
书单再好，如果你不愿意让任何一本书「深入生活」，它就只能停留在收藏夹里。

五、小结：把 12 本书，变成 12 个「系统更新点」

你完全可以这样来重新定义这 12 本书：
- 不是「12 次阅读任务」，而是「12 个系统更新节点」；
- 不是「我读完了几本」，而是「我因此改掉了几条旧习惯、装上了几条新程序」。
哪怕最后你只读完了其中 5 本，但只要每一本书后面，都跟着一个真实的「行为改变」，那你这一年的成长，也会远远超过「一口气读完 20 本，年终答题全忘」的自己。

当你下次再看到某个大佬的书单时，你可能不会急着收藏，而是会先问自己一句：

「在这份清单里，哪一本书，有机会成为我人生操作系统下一次更新的触发点？」

AI 解读

1. 问题本质
- 表层问题：Dan Koe 推荐了 12 本书，怎么读才有意义？
- 深层问题：如何避免「书单焦虑」和「信息过载」，把阅读变成「系统升级」而不是「短暂兴奋」。
2. 结构拆解
- 先指出「大神书单」常见的使用误区（精神消费、读完不变）；
- 然后从系统视角对 12 本书做了分层：底层操作系统/执行系统/价值系统/意义系统；
- 给出一个按季度划分的一年读书 & 行动框架；
- 最后把焦点从「读多少」拉回到「愿不愿意改变一点点行为」。
3. 与你 Skill 体系的映射
- 显式对应 SKILL-DIRECTORY.md 中的：
  - skill.reading.system.builder（从「读完就忘」到「读完进系统」）；
  - skill.life.os.365-reset（用一年重装人生操作系统）。
- 文章可以作为这两个 Skill 的「故事化说明书」：
  - 输入：12 本书单 + 当前人生状态；
  - 输出：一年的系统升级计划 + 每本书对应的「行为改变挂点」。
4. 可进一步系统化的方向
- 在 api.xyxbot.com 下补一个 skill.reading.plan.dan-koe-12，根据读者当下阶段自动推荐阅读顺序与行动任务；
- 在博客或知识星球中搭建「Day1–Day365」的阅读+执行打卡系统，让这 12 本书不只是书单，而是一个共同完成的长期项目。
分类：个人成长与系统设计

关键词：Dan Koe,书单,个人成长,阅读规划,人生系统,年度计划,认知升级,习惯改变,系统思维

来源：专栏文章：【day12】休息一天｜更新大神 Dan Koe 推荐的 12 本书 https://zhuanlan.zhihu.com/p/1998379781566252323
2026年2月24日
OpenClaw 跑了 120 小时，踩了无数坑总结出的 5 条必做，这些坑你千万别再踩！
金句开头：真正毁掉一个好工具的，往往不是功能不够强，而是你在没打地基的情况下，把它当「生产系统」在用。

一、120 小时之后，我才明白什么叫「别把玩具当生产」

很多人用 OpenClaw 的路径，都差不多：
- 一开始只是本地玩玩：跑个 demo、试试 Agent、写点小脚本；
- 觉得「好像挺稳的」；
- 某一天，你开始让它连夜跑任务、跑批处理、管一堆 Skills；
- 结果第二天一看：
  - 磁盘快满了；
  - 内存报警；
  - 日志乱成一锅粥；
  - 有的任务跑了一半挂了，连错在哪都懒得告诉你。
那一刻你会突然醒悟：

「它不是不行，是我压根没当系统来对待它。」

120 小时之后，我把那些「早知道一开始就该做」的事情，粗暴总结成 5 条。你可以把它当成一份「OpenClaw 上生产前的体检清单」。

二、第 1 条：一定要有「专用工作目录」和「专用日志目录」

最容易被忽略的坑，就是「一切都默认」：
- 默认当前目录；
- 默认日志路径；
- 默认临时文件位置。
结果就是：
- 日志和缓存散落在项目里，想清理不敢删；
- 真出问题时，你连「它到底写到哪去了」都不知道。
正确的做法，是一开始就给 OpenClaw 规划一块「地盘」：
- /opt/openclaw 或你习惯的任何路径；
- 里面统一划分：logs/、tmp/、agents/、skills/、runs/；
- 所有任务都在这个「沙盒」里活动。
这样一来：
- 出问题时，你知道去哪里找日志；
- 想清理时，可以放心地清掉整个 tmp/ 或单次 run/ 目录；
- 备份和迁移也有了清晰边界。
三、第 2 条：资源「限死一点」比「放飞一点」更安全

很多人对自己的机器有一种迷之自信：

「我这 32G 内存，开点并发算啥事。」

但你要意识到，OpenClaw 背后调的可能是：
- 本地大模型；
- 多个外部 API；
- 一堆工具/脚本/子进程。
任何一个环节出事，最后都要算在你这台机器头上。

你至少要做几件事：
- 给运行 OpenClaw 的用户单独设定 ulimit（最大打开文件 / 最大进程数）；
- 给日志文件设定 logrotate，防止一夜之间几 G；
- 对某些「重任务」设定单次运行超时和最大重试次数。
一句话：

别等资源打满了，才想起「要不限制一下」——那已经晚了。

四、第 3 条：没监控 = 白跑，别指望第二天还能复盘

很多人以为「跑得好不好」可以靠感觉：
- CPU 风扇声音大了点；
- 桌面卡了两下；
- 日志文件长了一截。
但当你想认真回答几个问题时，就会发现完全抓不住：
- 哪个任务最耗时、最费资源？
- 错误率最高的是哪个 Skill / Agent？
- 哪个时间段最容易出问题？
没有最基本的监控和统计，一切只是「印象」，不是「数据」。

你不需要一上来就搞 Prometheus + Grafana，但至少可以：
- 定期记录 CPU / 内存 / 磁盘占用（哪怕是简单的 cron + shell）；
- 针对关键任务，打点起止时间、输入规模、输出大小；
- 把错误信息统一进一份「错误日志」，而不是散落各处。
这样当你跑完 120 小时再回头看时，你手里至少有一份「可以学习的样本」，而不是一片混乱的黑盒。

五、第 4 条：日志不是「写给系统看」的，是写给未来的你看的

刚开始写日志的时候，我们都在用技术人的视角：
- 打一堆 debug；
- 输出各种变量；
- 记录很底层的信息。
但 120 小时之后，你会非常想揍当时的自己一顿：
- 这些日志告诉了你一堆「事实」，却很少告诉你「故事」；
- 你知道发生了什么，却不知道「为什么会这样」。
真正好用的日志，应该至少包括三层：
1. 事件层：什么时候、谁、干了什么（哪一个 Agent / Skill 被触发、输入是什么）；
2. 结果层：成功/失败、耗时多少、消耗了多少资源（Token/调用次数）；
3. 决策层：关键分支是怎么选的（走了哪条策略、为什么走这条）。
你不需要把每一条都写得很重，但一定要给未来的自己留一点「可读性」：

让 3 天后的你，看一眼日志就能接上当时的思路，而不是从头猜。

六、第 5 条：永远准备一个「一键刹车」的开关

最后一个，也是最重要的：

请务必给自己留一个「紧急刹车」的开关。

无论这个开关是：
- 一个简单的「暂停标志文件」（存在就不再接新任务）；
- 一个面板上的开关按钮；
- 甚至只是一个约定俗成的「Kill 某个进程组」脚本；
关键在于——

当你发现事情不对劲的时候，要有办法 马上停下来，而不是眼睁睁看着它「继续作死」。

这个开关的存在，会极大提升你「敢于让它自动跑」的心理安全感。

七、小结：从「玩具心态」切换到「系统心态」

如果用一句话概括这 120 小时的教训：

你对 OpenClaw 的态度，决定了它是玩具，还是系统。

当你只是抱着「玩玩看」的心态去用：
- 默认配置就够了；
- 出问题重启就好；
- 日志乱点也无所谓。
可一旦你开始让它：
- 接外部请求；
- 帮你跑重要任务；
- 成为你生产力的一部分；
那你就必须像对待任何一套在线服务那样，对待它：
- 有界的目录；
- 有限的资源；
- 可观测的行为；
- 有故事性的日志；
- 可随时拉下的刹车。
只要你在一开始，花半天时间把这 5 条都「真正做一遍」，后面那 120 小时，不仅不会是噩梦，反而会成为你为数不多「值得骄傲的工程实践」之一。

AI 解读

1. 问题本质拆解
- 表面是在分享「OpenClaw 120 小时踩坑经验」，
- 本质是在回答一个更底层的问题：「如何把一个实验性工具，提升到生产可用的系统级别？」
文章用「5 条必做」的方式，把抽象的「系统心态」拆成可以执行的动作：
- 目录 & 日志规范；
- 资源限制；
- 轻量监控；
- 可读日志；
- 紧急刹车。
2. 与 Skill 体系的映射 这篇文章可直接映射到你 SKILL-DIRECTORY.md 里的两个关键 Skill：
- skill.openclaw.sandbox.setup：
  - 专注环境、目录、权限、日志基础配置；
- skill.openclaw.runtime.guard：
  - 专注监控、资源控制、错误率、刹车策略。
文章可以看作这两个 Skill 的「经验故事版实现」：
- 输入：一套「玩具心态」的 OpenClaw 部署；
- 输出：一个「至少能跑 120 小时不崩」的系统。
3. 可扩展方向
- 你可以在 api.xyxbot.com 下继续补一个 skill.openclaw.setup.safe-runtime，把文中 5 条动作编码成一个统一的初始化流程；
- 也可以为这篇文章配一份 checklist.md，每次新部署直接照单核查。
分类：AI 工具与编排

关键词：OpenClaw,长时间运行,踩坑总结,资源限制,日志系统,监控,守护进程,系统心态,安全运行

来源：专栏文章：OpenClaw跑了120小时，踩了无数坑总结出的5条必做，这些坑你千万别再踩！ https://zhuanlan.zhihu.com/p/2001031113431335425
2026年2月24日
怎样才能学会真正的 SEO，感觉网上讲的都是很基础的？
金句开头：真正的 SEO，从来不是「学到某个高级技巧」，而是「终于有了一套能反复用的结构」——基础不在于简单，而在于你从未把它系统地拼起来。

一、为什么你总觉得「讲的都是很基础」？

你现在看到的绝大多数 SEO 内容，大概都是这样的：
- 告诉你要做标题、描述、H1、内链、外链；
- 告诉你要关注收录、索引、点击率、停留时间；
- 告诉你要用某某工具挖关键词、看热度。
信息并不假，但有两个致命问题：
1. 是碎片，不是结构：每一条都对，却不知道它们之间的关系；
2. 是别人站点的答案，不是你站点的问题：别人说什么你就跟着做，却没问过「我的站现在最缺的是什么？」。
所以你会有一种强烈挫败感：

「我好像什么都知道一点，但又好像什么都抓不住。」

要从「基础堆满脑袋」走向「真正会用 SEO」，第一步不是找更高级的技巧，而是先把那堆基础，拼成一个自己的三层结构。

二、把 SEO 拼成自己的「三层金字塔」

无论是博客、工具站、公司官网，所有的 SEO 问题最终都会落在三层：
1. 技术层：搜索引擎能不能「顺利地爬、看、收」你的站；
2. 内容层：你写的东西是不是围绕少数核心主题深挖，而不是什么都夹带一点；
3. 权重层：在搜索引擎眼里，你是不是那个领域「值得信任的人」。
可以这样粗暴记忆：
- 技术层：能不能被看见；
- 内容层：值得不值得被看；
- 权重层：轮到你还是轮到别人先被看。
如果你现在的状态是：「看了很多文章，但不知道从哪下手」，最好的办法就是——给自己做一次三层体检。

三、给自己做一次「三层体检」

你可以拿出一张纸，或者开一个新的 Markdown 文档，写三个大标题：
- 技术层
- 内容层
- 权重层
然后针对你现在的站，老老实实回答几个问题。

1. 技术层：搜索引擎进得来吗？

至少搞清楚：
- 有没有稳定的 站点地图（sitemap）；
- 有没有大量的 死链 / 重复页面 / 抓取错误；
- 页面打开速度在移动端是不是惨不忍睹；
- HTTP、HTTPS 有没有乱跳，www / 非 www 是否统一；
- 你的主要页面是不是都能被正常索引（site: + 重要 URL 检查一下）。
这一层的目标不是「完美」，而是：

别让搜索引擎在门口就摔一跤。

把这层先做到「没有大坑」，你再去卷什么高阶玩法，才算有意义。

2. 内容层：你到底在讲几个主题？

站在搜索引擎角度，它最喜欢的是： 某个站在某个小领域里，持续、稳定、高质量地输出。

所以你要问自己：
- 我的网站 核心主题 有哪三个？
- 最近 30 篇内容，有多少是围绕这三个主题展开的？
- 这些内容之间，有没有用内链互相「拉一把」？
如果一看自己的目录：
- 今天写 AI，明天写健身，后天写理财，大后天写情感；
- 内链基本靠缘分；
那就别怪搜索引擎不知道「该把你分到哪个货架」。

真正的内容层优化，通常就是两件事：
1. 聚焦：选 1–3 个你真正在意的主题；
2. 编织：让围绕这些主题的内容，互相有路可走（内链 + 专题页）。
3. 权重层：在这个圈子里，你算不算「一个人」？

很多人一提权重，脑子里就是「外链」。但在今天，权重更像是一个综合「信任度」：
- 是否有其他高质量站点、账号、媒体提到你；
- 是否有稳定的品牌搜索（有人直接搜你的站名 / 品牌名）；
- 是否有一部分用户愿意「直接来你这搜」，而不是每次靠搜索引擎拉。
它问的是一个简单粗暴的问题：

在这个小领域里，你到底算不算一个「人」？

如果你现在是：
- 完全靠某一个平台背书；
- 换个站名 / 域名马上没人认识你；
那权重层本质上就是 0，需要你慢慢经营自己的「站外人格」。

四、一条「真正学会 SEO」的 90 天路径

与其继续刷「更高级的 SEO 技巧」，不如给自己一个更现实、但可执行的目标：

90 天内，把一个小站的三层结构搭清楚。

可以大致这么拆：

第 1–2 周：技术层止血
- 把最明显的技术问题先一口气解决掉：
  - sitemap、robots、404、301、HTTPS、基础速度优化；
- 至少做到：搜索引擎「能顺利进来、能顺利走一圈」。
第 3–6 周：内容层聚焦
- 明确站点想长期做的 1–3 个核心主题；
- 基于这几个主题，列出一个「问题清单」（别人会怎么搜？）；
- 有节奏地产出内容，并用内链把它们串起来。
第 7–12 周：权重层启动
- 主动和同领域同水平的人互相引用、互相 Guest Post；
- 把之前分散在各个平台的个人形象，慢慢往你的主站做引流；
- 至少建立起：有人会记得你的域名 / 品牌名，并主动来找你。
做到这个程度之后，你再谈「结构化数据」「Programmatic SEO」「AI 批量生成」，才叫在「真正的 SEO 路上」继续走，而不是在原地堆新名词。

五、真正的分水岭：你什么时候开始「自己给自己写 SEO 说明书」

有一个简单的判断标准，可以区分「看了很多 SEO 内容的人」和「真正懂 SEO 的人」：

你有没有给自己的站写过一份「SEO 设计说明书」？

哪怕只有几页，也应该包括：
- 我站的三个核心主题是什么；
- 我的 URL / 目录 / 内链结构是怎么设计的；
- 技术层的已知问题列表 & 修复计划；
- 我期望一年后，别人提到哪些词时，会想到我。
只要开始动手写这份说明书，你就已经在从「听课的人」转向「设计系统的人」了。

那一刻起，「感觉网上讲的都很基础」这句话，对你来说会变成另一种含义：

不是它们太基础，而是你终于知道——这些基础，早就该拿来搭自己的楼了。

AI 解读

1. 问题本质拆解
- 表层抱怨：网上的 SEO 内容太基础，不够高级。
- 深层困惑：缺的不是更复杂的知识点，而是一套能指导自己站点决策的「结构」。
文章通过「三层金字塔」的方式，把 SEO 从碎片知识收束成：
- 技术层（能不能被看见）；
- 内容层（是不是值得被看）；
- 权重层（轮到你还是轮到别人被看）。
2. 与你 Skill 体系的映射
- 显式对应 SKILL-DIRECTORY.md 里的：
  - skill.seo.foundation.builder
  - skill.seo.tools.orchestrator（可在后续文章里补充工具链）
- 本文可以看成 skill.seo.foundation.builder 的「叙事版实现」：
  - 输入：当前站点；
  - 输出：三层体检结果 + 90 天行动路线。
3. 下一步可以怎么系统化？
- 写一个脚本 / OpenClaw Skill，自动对指定域名做「三层体检」，输出 Markdown 报告；
- 在你的博客 / 星球里，推出一个「90 天 SEO 打底计划」，文章就是说明书，Skill 是执行工具。
分类：SEO 与流量增长

关键词：SEO,学习路径,技术SEO,内容策略,权重建设,三层结构,流量增长,站点诊断,系统思维

来源：知乎问答：怎样才能学会真正的seo，感觉网上讲的都是很基础的？ https://www.zhihu.com/question/1987230384627418626/answer/2009672928694924632
2026年2月24日
工作中，有哪些瞬间让你觉得「把任务交给 AI 还不如自己写」？
金句开头：AI 真正拉低效率的时刻，不是在它「不够聪明」的时候，而是在我们「不愿意好好给它设计工作」的时候。

一、那些让你怀疑人生的瞬间，其实很典型

如果你已经在工作中试着用 AI，一定经历过类似的画面：
- 想让它改个小需求，结果返回一坨完全不贴上下文的代码；
- 想让它写个 SQL，字段名、表名全乱，改到最后不如自己从头写；
- 想让它帮忙写一页文案，反复几轮都像「格式正确的废话」；
- 想自动生成测试用例，结果跑不过、覆盖率还不如自己手写几条。
那一刻你心里会冒出一句话：

「算了我自己写吧，和它折腾的时间早干完了。」

但如果你冷静拆一下，会发现一个残酷的事实：

绝大部分「AI 不如自己写」的时刻，本质上不是 AI 的问题，而是我们给它的「任务定义」太烂。

二、AI 最怕三种任务：模糊、混装、甩锅

1. 模糊：连你自己都说不清楚要什么

很多时候，我们给 AI 的任务是这样的：
- 「帮我重构下这个模块，让它更优雅一点」
- 「把这段文案改得有说服力一点」
- 「帮我优化下这个 SQL 性能」
问题是，「更优雅」「更有说服力」「更快」在不同人脑子里含义完全不一样。你在心里有一个隐含标准，但从来没说清楚。

当任务定义是模糊的，AI 只是把你的模糊扩大成了一屏输出。

2. 混装：一口气塞一堆不同类型的要求

还有一种常见提问方式：
- 「帮我理解这段代码、找出 bug、顺便重构一下，再帮我写测试和文档。」
对人类来说，这是连续的几个步骤；对 AI 来说，这是一条「结构混乱的指令」：
- 它不知道该优先干啥；
- 也不知道每一步的「Done 标准」是什么。
结果就是：四件事全做了点，但哪一件都不让人放心。

3. 甩锅：把本该自己判断的事扔给 AI

更隐蔽的一种情况是：我们把自己不想面对的「决策」扔给 AI：
- 「你帮我选一个最好的技术方案」
- 「你帮我决定这个功能要不要做」
- 「你帮我评价这段代码写得好不好」
这些问题本质上都高度依赖你的上下文、团队现状、业务取舍。 AI 没法替你承担这些责任，它给出的只是一个「看起来合理」的意见。

当你想用 AI 替你做「你自己都没想明白」的决定时，它当然「还不如你自己写」。

三、真正应该交给 AI 的，是哪一类工作？

我逐渐发现，有三种任务，交给 AI 划算到离谱：

1. 高重复、低判断

比如：
- 批量生成接口文档草稿；
- 为一堆函数补上注释；
- 根据现有代码生成初始测试用例；
- 把日志 / 异常堆栈整理成可读报告。
这类任务的特点是：
- 规则清晰；
- 好坏标准容易定义；
- 人类做起来很烦，但并不难。
这就是 AI 的甜蜜区：你负责设定规则，它负责机械执行。

2. 高信息量整理，而不是高精度决策

比如：
- 把一个长 PR 的变更点总结出来；
- 把几段需求讨论梳理成一份「决策备忘」；
- 把多个方案的优缺点汇总到一张列表。
决策权依然在你手上，但信息整理这一步完全可以交给 AI。

你不再需要从头到尾啃文档，而是可以在「结构清晰的摘要」之上做判断。

3. 用来「试探性探索」，而不是「最终实现」

比如：
- 让 AI 先帮你写一个「能跑的垃圾版本」，你再手工重构；
- 让它先写出几套不同风格的 API 设计，你选一套再优化；
- 让它生成几组不同角度的错误提示文案，你挑最顺眼的那组。
这时候 AI 更像一个「头脑风暴助理」，帮你快速看到几个可能的方向，而不是直接产出终稿。

用它来「试错」和「扩展视野」，远比用它来「代替最终实现」靠谱得多。

四、让 AI 真正变好用，只需要三个小习惯

如果你已经有「交给 AI 还不如自己写」的挫败感，可以从这三件小事开始改：

1. 所有任务都先写一句「成功标准」

在每次开口前，先问自己一句：

「我怎么判断，它完成得好不好？」

然后把这个标准，翻译成 1–3 条具体的判断条件写进指令里。哪怕是简单的：
- 「必须兼容现有这两个接口」
- 「不能引入新依赖」
- 「复杂度不能超过现在一倍」
这样 AI 至少知道，要往哪个方向优化。

2. 一次只让它做一件事

把「理解代码」「找问题」「提方案」「改代码」拆成几轮，而不是一口气全甩过去。

这不只是对 AI 友好，对你也好—— 你能在每一轮中逐步校正方向，而不是最后一次性发现「全跑偏了」。

3. 给自己写一份「AI 协作手册」

把你在工作中试出来的好 Prompt、好流程、好套路，统一记在一个文档里（就像我们现在做的 SKILL-DIRECTORY）。

久而久之，你会发现：
- 你在用的已经不是「某个模型」，而是一套「方法论」；
- 换模型也没关系，因为你的协作方式是稳定的。
这时候，AI 才真正从「会时不时气死你」的玩具，变成「你可以信任的搭档」。

AI 解读

1. 问题抽象 原问题看似是在吐槽 AI 的不稳定输出，实质是在问：

「在哪些任务上，用 AI 天然吃亏？我该如何调整使用方式？」

这篇文章没有停留在「罗列几个失败案例」的层面，而是：
- 先从任务定义和协作方式上拆因子（模糊、混装、甩锅）；
- 再反向总结出「适合 AI」「不适合 AI」的任务特征；
- 最后给出三个可马上实践的小习惯。
2. 与 Skill 体系的对应关系 文章隐含对应了你已有的 Skill 设计：
- skill.claude.workflows.designer
  - 用「工作流」的方式限制 AI 的职责和节奏；
- skill.openclaw.runtime.guard
  - 在长时任务中给 AI 行为加一道「守门员」；
- skill.blog.from-node
  - 把「写多篇博客」从手工任务，收敛成一个可复用的批处理 Skill。
这些 Skill 的共同点是： 不再把 AI 当成一个「万能回答器」，而是当成一个「被系统约束的执行组件」。

3. 可扩展方向 如果你后面继续写系列文，可以考虑：
- 写一篇专门拆解「真实失败用例 + 对应 Skill 改造前后对比」；
- 在 OpenClaw / 自己的工具里，把文中三条小习惯固化成一个「AI 协作 Checklist Skill」，每次调用前自动走一遍检查。
来源：知乎问答：工作中，有哪些瞬间让你觉得「把任务交给 AI 还不如自己写」？ https://www.zhihu.com/question/2004183228873974976/answer/2008171738723263109
2026年2月24日
最近编程圈 skills 很火，有没有好用的 skill 分享一下？
金句开头：真正好用的 Skill，从来不是「功能多到吓人」，而是「少到足够进系统」——它不是让你一时爽，而是让你一再复用。

一、为什么「skills 很火」，但你总觉得自己用不上？

这两年，编程圈的语境发生了一个微妙的变化：
- 以前大家聊的是：库、框架、插件；
- 现在越来越多人聊的是：Skill、能力、工作流。
看起来只是换了个名词，实则是思维方式的升级：

从「我会什么」到「我的系统会什么」。

问题也随之变化：
- 不是「有没有好用的 Skill」；
- 而是「这些 Skill 能不能被我装进一套稳定、可复用的系统里」。
如果你只是零散收藏一堆 Skill、插件、Prompt，而没有一个清晰的「Skill 体系」，那结局通常是：
- 装的时候很兴奋；
- 用的时候很混乱；
- 过一阵全忘了。
这篇就不按「Top 10 神器清单」那套讲，而是给你： 3 类真正值得长期配置进自己系统里的 Skill 模型，外加几个可以马上上手的落地例子。

二、第一类：AI 工具与编排类 Skill —— 让「人 + AI」真正变成协作

1. skill.openclaw.sandbox.setup：所有魔法的地基

场景很简单：你打算认真用 OpenClaw / 本地 Agent / 各类 AI 工具长期工作，而不是「玩一玩就删」。

这时候，你最怕的不是「不会用」，而是「用着用着把机器搞炸」：
- 磁盘被日志打满；
- CPU/内存天天红；
- 权限乱开，一次配置错误，后面全是坑。
这个 Skill 要帮你做的，是一个可重复的初始化流程：
- 检查 OS、磁盘、内存、网络；
- 设定统一的日志目录、资源限制、是否允许外网；
- 输出一套「以后每台新机器都这么配」的脚本模版。
本质上，它不是功能，而是「让你可以放心长期折腾 AI 的安全地板」。

2. skill.claude.workflows.designer：别再「裸聊」 Claude 了

大部分人用 Claude Code 的方式，是这样的：
- 想到啥就问啥；
- 一会儿让它改代码，一会儿又让它分析架构；
- 上下文乱飞，结果很随机。
这体验当然会让你忍不住说一句：

「算了，还不如我直接自己写。」

而真正用出「生产力」的人，做的是另一套事：
- 先设计工作流，再让 Claude 执行。
比如针对一个旧项目：
1. 第一步：让 Claude 建索引，生成模块级别的理解说明；
2. 第二步：限定范围，在某个子目录里做重构建议；
3. 第三步：根据建议生成改动草案；
4. 第四步：让它写测试 / 文档。
skill.claude.workflows.designer 就是把这套东西固化成模版：
- 输入：项目类型（读老项目/新功能/重构/写测试）；
- 输出：建议的「对话轮数 + 每一轮的 Prompt 结构 + 需要提供的上下文」。
重点不是 Claude 有多强，而是你能不能用同一套工作流，让不同项目的协作体验「稳定起来」。

3. skill.openclaw.runtime.guard：帮你看着系统别作死

当你开始让 OpenClaw / Agent 夜里自己跑任务时，你多半会突然理解什么叫「恐惧」：
- 这玩意儿会不会暴走把 Token 烧光？
- 会不会死循环把机器搞挂？
- 会不会卡住一整夜，第二天一看日志全是错误？
runtime.guard 这种 Skill 的作用，就是给自己配一个「守夜人」：
- 实时看 CPU / 内存 / 磁盘 / 错误率 / 重试次数；
- 超过阈值时，执行预设动作：降并发/暂停/重启/告警；
- 把这些行为全部写进日志，方便你第二天复盘和调参。
你会发现： 一旦有了「守护 Skill」，你敢交给 AI 的事，会越来越多。

三、第二类：SEO 与流量类 Skill —— 让内容有持续的入口

4. skill.seo.foundation.builder：先补三层地基，再想「高级玩法」

很多人说「网上讲的 SEO 都很基础」，但真正的问题是：

那些「基础」，你真的系统性补全了吗？

一个成熟站点的 SEO 至少有三层：
1. 技术层：速度、结构、站点地图、移动端、404/301；
2. 内容层：主题集中度、长尾覆盖、内链结构、页面质量；
3. 权重层：外链、品牌搜索、用户行为信号。
seo.foundation.builder 做的事情，是把你的网站体检一遍：
- 给出三层的简要评分；
- 列出「先修什么，再修什么」，而不是甩给你 100 条 checklist 把你压垮。
只有三层地基基本打齐，后面再谈自动化、AI 批量生成才有意义。

5. skill.content.distribution.pipeline：让好内容多活几条命

你现在已经有很多不错的文章、回答、博客，但如果它们只存在于一个平台，其实是在白白浪费产能。

内容分发类 Skill 的目的，就是帮你做一件事：

一篇主文，多平台适配，多渠道同时发。

一个简单的 pipeline：
- 输入：一篇主文（Markdown 为佳）；
- 自动生成：
  - 符合公众号/知乎/博客/社交平台各自风格的标题 & 导语；
  - 略微拆分或重组的段落结构；
  - 合理的 CTA（引导关注/收藏/点击站点）。
你不需要每个平台重写，只需要在同一个核心观点上，稍微换个说法。剩下的，交给 Skill 帮你做繁琐的格式与风格差异处理。

四、第三类：个人成长与系统类 Skill —— 让你活在自己的「操作系统」里

6. skill.life.os.one-day-plan：一天是一切系统的「最小运行单元」

你这段时间其实已经在做一件很难的事：
- 每天从 node.md 抽内容；
- 持续写博客、做 SEO、搭 Skill 体系。
你会发现：当输出变多之后，「时间怎么排」「精力怎么管」会越来越关键。

Dan Koe 的一日计划，本质上就是一个「可复用的一天模板 Skill」：
- 预留块：
  - 深度工作 ×1（写代码/写文/搭系统）；
  - 输入 ×1（认真读点什么，而不是刷）；
  - 输出 ×1（发一篇内容/一条动态）；
  - 身体 ×1（哪怕是 20 分钟快走）；
  - 复盘 ×1（今天做对了啥/做错了啥）。
把这几个块固化下来之后，你每天就不用在「要不要写、要不要学、要不要动」里拉扯，而是——

「今天的一日 Skill 已经加载，我只是在执行系统。」

这是所有 Skill 能长期复利的前提。

五、总结：给你一条今天就能用的「Skill 升级」路径

如果你现在就想从「看别人分享 Skill」进入「自己开始用 Skill」，可以照这个顺序来：
1. 先装一个「地基 Skill」
  - skill.openclaw.sandbox.setup + runtime.guard
  - 目标：让你的本地 AI 环境安全、稳定地跑起来。
2. 再装一个「协作 Skill」
  - skill.claude.workflows.designer
  - 目标：让「人 + Claude」的协作有一套固定流程，而不是随缘聊天。
3. 然后选一个「流量 Skill」
  - skill.seo.foundation.builder 或 content.distribution.pipeline
  - 目标：让你产出的东西，有长期被看到的机会。
4. 最后给自己一个「生活容器 Skill」
  - skill.life.os.one-day-plan
  - 目标：让这一切都能装进你的现实 24 小时。
当你用这几块，把自己的工作与生活稍微「系统化」一点之后，你会发现：
- 再看到新的 Skill，不会立刻激动，而是会先想：「它能接到我现有的哪条线上？」
- 不能接的，就默默略过；
- 能接的，就认真评估，把它写进自己的 SKILL-DIRECTORY.md。
到那时，「skills 很火」对你来说只是一条背景噪音，你真正关心的，只有一句话：

这是不是那个——能在我系统里复用很多年 的 Skill？

AI 解读

1. 本文核心问题抽象
- 表层问题：最近编程圈 Skills 很火，有没有好用的推荐？
- 深层问题：如何从「堆技能」升级为「用少量高质量 Skill 搭系统」？
2. 结构拆解
- 第一部分：解释「Skills 很火」背后的认知升级——从「我会什么」到「我的系统会什么」。
- 中间三部分：按「AI 工具」「SEO 流量」「个人系统」三条主线，各给出 1–2 个可落地的 Skill 原型。
- 最后一部分：给出一条可执行的升级路径，帮助读者从今天开始做出具体改变。
3. 对应的 Skill 映射
- skill.openclaw.sandbox.setup
- skill.openclaw.runtime.guard
- skill.claude.workflows.designer
- skill.seo.foundation.builder
- skill.content.distribution.pipeline
- skill.life.os.one-day-plan
这些 Skill 都已在你的 SKILL-DIRECTORY.md 里定义，可以继续沉淀为：
- OpenClaw .skill 配置
- 系统化课程小节
- 更多类似文章的通用写作骨架
4. 可以怎么继续扩展？
- 写一篇专门讲「如何用 skill.blog.from-node 把 node.md 自动变成整套内容体系」的文章；
- 为每个 Skill 写一个「真实项目使用日志」，把抽象的 Skill 变成具体的故事。
来源：知乎问答：最近编程圈skills很火，有没有好用的skill分享一下？ https://www.zhihu.com/question/1998078397155402328/answer/2005284682665833567
2026年2月24日
能力提升:一套越来越稳的系统，去吃信息差、技术差和执行差
> 一句话先说在前面：真正厉害的 Skill，不是功能多到吓人，而是少到刚刚好——能被你装进系统、天天用得上的那几个，才算「好用」。

最近编程圈的 Skills 为啥这么火？

这两年你应该已经明显感觉到：
- 以前大家聊的是「库」「框架」「脚手架」
- 现在大家开始聊「Skill」「能力」「插件集」
背后其实是一个很简单的变化：> 从「我会什么」变成「我让系统会什么」。
- 写代码：不再只是你一个人敲，而是你 + Claude Code + OpenClaw + 一堆 Skills 一起干
- 做 SEO：不再只是你盯着后台，而是关键词挖掘 / 内容生成 / 内链规划一整套 Skill 流水线
- 搞副业：不再只是你熬夜写稿，而是「写作 Skill」「分发 Skill」「变现 Skill」配合运转
所以问题不是「有没有好 Skill」，而是：> 在这么多 Skill 里，怎么挑出一套能复用、能进系统、能帮你赚钱的组合。下面我不做那种「随手列一堆插件名字」的清单，而是给你一套可以复用的 Selection 思路 + 实战示例。

一、先别问「有什么 Skill」，先问「你需要什么系统」

我建议你先把 Skills 按照这三条主线来归类：
1. AI 工具与编排 Skills
- OpenClaw / Claude Code / Agent / 本地 AI
- 关键词：工作流、守护、沙箱、集成
1. SEO 与流量增长 Skills
- 关键词挖掘、批量着陆页、多平台分发、数据监控
1. 个人成长与系统设计 Skills
- 一人公司、Dan Koe 生命周期、纳瓦尔底层逻辑、读书/执行系统
你可以直接在脑子里问自己三个问题：
- 我现在最缺的是哪一块？
- 缺执行力 → 先上 AI 工具与编排
- 缺流量 → 先上 SEO 与流量
- 缺方向/耐力 → 先上个人成长与系统
> 只有当你知道「要补哪条主线」，你挑 Skill 才不会乱买调料。

二、AI 工具与编排：给你 3 个真·好用的 Skill 原型

这部分选的是能马上提高「人 + AI」协作质量的 Skills，而不是单纯功能炫酷的。

1. skill.openclaw.sandbox.setup

场景：你准备长期跑 OpenClaw / 各种 Agent，不想自己电脑变「炼丹车祸现场」。
- 为什么要有这个 Skill？
- 一次配置不当 = N 次崩溃 + 玄学错误 + 文件乱七八糟
- 你之后所有的 AI 工作流，都跑在这个地基上，地基不稳，上层全崩
- 这个 Skill 要帮你做的事情：
- 检测当前 OS / 资源情况（内存、磁盘、网络）
- 给出推荐配置：日志目录、资源限制、是否允许外网、端口规划
- 输出一个可以重复使用的「初始化脚本」模板
- 实战建议：
- 把它当成「每台新机器」的标准动作，别偷懒
- 下次你再装 OpenClaw / Ollama / 其他本地 Agent，直接套这个模板，而不是手抄一遍 README
2. skill.claude.workflows.designer

场景：你已经在用 Claude Code 写代码，但总觉得「它很强，我用得很弱」。
- 为什么要有这个 Skill？
- 大部分人用 Claude 的方式是：想到啥问啥 → 结果很随机
- 真正稳定、高产的，是预先设计好工作流的人：
- 先读代码 → 再重构 → 再写测试 → 再生成文档，每一步都有固定 prompt 和操作套路
- 这个 Skill 要帮你做的事情：
- 让你基于项目类型（旧项目 / 新功能 / 重构 / 写测试），自动生成一套：
- 「第 1 轮问什么」
- 「第 2 轮给什么上下文」
- 「第 3 轮让它干什么」
- 实战建议：
- 不要再「裸聊」Claude，一定要给自己写一个 WORKFLOW.md，就叫「Claude 使用手册」
- 每次有新的好 Prompt、好套路，都往这本「手册」里塞，久而久之，你就是「会用 Claude 的人」
3. skill.openclaw.runtime.guard

场景：你开始跑长任务、批量任务、夜间任务，心里开始发毛：这玩意儿会不会半夜失控。
- 为什么要有这个 Skill？
- 任何长期运行的 AI 系统，如果没有监控 + 限制，一定会在某天给你来一记「暴击」：
- CPU/内存拉满
- Token 疯狂消耗
- 请求重试把 API 限流全部打满
- 这个 Skill 要帮你做的事情：
- 跑的时候自动检测：
- CPU / 内存 / 磁盘 / 进程数
- 错误率 / 重试次数 / 单次请求 Token
- 超穿阈值时提醒你：
- 降并发？
- 暂停任务？
- 自动重启？
- 写到日志里给第二天的你复盘？
- 实战建议：
- 把这个 Skill 当成自己给自己写的 SRE，哪怕先手动跑一版，也比完全没眼睛好
三、SEO 与流量：给你 2 个基础但高回报的 Skill

你现在所有博客、WordPress、分发的流量，都可以挂在这两个 Skill 之上。

4. skill.seo.foundation.builder

目标：从「零零散散看教程」进化到「我有一套自己的 SEO 框架」。
- 核心问题：
别再问「还有没有更高级的 SEO 知识」——先问自己：最基础的三层，你补齐了吗？
1. 技术：速度、结构、indexing、移动端
2. 内容：主题集中度、内链结构、页面质量
3. 权重：外链、品牌提及、用户行为信号
- 这个 Skill 做什么？
- 读一个网站，帮你打这三层的「体检报告」
- 输出一个「先做什么、后做什么」的短清单，而不是一堆 checklist 把你压垮
5. skill.content.distribution.pipeline

目标：让你「一稿多发」变成常态，而不是每次都手搬。
- 为什么要有这个 Skill？
- 你现在写的所有深度文章，如果只发在一个站，就是在浪费内容价值
- 真正的差距是：同一份内容，有的人发 1 个地方，有的人发 10+ 个地方
- 这个 Skill 做什么？
- 输入：一篇主文（Markdown）
- 输出：n 个不同平台（公众号、知乎、博客、社交媒体）适配好的版本：
- 标题 / 副标题
- 摘要 / 导语
- CTA / 引导关注
四、个人成长与系统：给自己装一个「人生操作系统」的开机 Skill

这块不卖鸡汤，只给你一个最基础、但最管用的 Skill。

6. skill.life.os.one-day-plan

目标：你的一天，不再是「醒了就刷、困了就睡」，而是有一套默认模板。
- 为什么要有这个 Skill？
- 你已经有「Skill 体系」，但如果每天连一个稳定的「执行容器」都没有，再好的 Skill 也落不下去
- Dan Koe 的一日计划，本质上就是一个优雅的「一天容器」
- 一日容器需要具备的几个区块：
- 深度工作（写作 / 编码 / 构建系统）
- 输入（阅读 / 学习 / 复盘他人）
- 输出（发文 / 发推 / 提交代码）
- 身体（运动 / 睡眠底线）
- 关系（最少的人际维护）
> 你不用一上来就完美执行，只要做到：「今天这几个块，我至少点亮 2–3 个」，人生曲线就会慢慢拐弯。

五、总结：真正「好用的 Skill」，是什么样的？

如果用一句话帮你筛选：> 好 Skill = 能被你连到系统里的 Skill，而不是「看起来很厉害」但你用两次就扔的那种。你可以今天就做三件小事：
1. 从上面 6 个里先挑 1 个（比如 skill.openclaw.sandbox.setup 或 skill.life.os.one-day-plan）
2. 给它写一个属于你自己的版本：
- 一页 Markdown：为什么要做 → 怎么做 → 我踩过什么坑 → 以后怎么复用
1. 在你后面的文章 / OpenClaw / 课程里，强制自己每次至少复用一个 Skill，而不是每次从 0 想结构。
等你手里有 10–20 个「真的被复用过的 Skill」，那一刻你会发现：
- 你不是在「学更多东西」
- 而是在「用一套越来越稳的系统，去吃信息差、技术差和执行差」
那时候，再回头看「最近编程圈 Skills 很火」，你心里可能只会淡淡一句：> 火不火跟我关系不大，我只关心——这玩意儿进不进得了我的系统。
2026年2月24日
学会如何通过精准描述，让模型输出极高质量的内容。
汇总

本文深入探讨了结构化提示词（Structured Prompt）的设计方法和实践技巧。从传统的角色扮演式提示词出发，介绍了结构化提示词的核心概念、语法规范、模块组成以及实际应用示例。通过对比传统方法和结构化方法，展示了结构化提示词在提升AI交互质量方面的显著优势。文章提供了完整的知识探索专家提示词模板，并详细解释了各个模块的作用和设计思路，帮助读者快速掌握这一高效的提示词工程技巧。

如何写好 Prompt：结构化

背景

最早接触 Prompt Engineering 时，学到的 Prompt 技巧都是：
- 你是一个 XX 角色…
- 你是一个有着 X 年经验的 XX 角色…
- 你会 XX，不要 YY..
- 对于你不会的东西，不要瞎说！
- …
对比什么技巧都不用，直接像使用搜索引擎一样提问，上面的技巧对于回复的效果确实有着明显提升。在看了 N 多的所谓”必看的 Prompt 10 大技巧””价值 2 万元的珍藏 Prompt”后，发现大家都在上面这些技巧上打转。

直到有一天，在 GitHub 上看到了 JushBJJ/Mr.-Ranedeer-AI-Tutor，才发现原来 Prompt 还可以这样写：原来可以在运行中调整各种变量并立即生效，原来对话语言可以随时更改，原来可以像编程一样，提前预置好命令供用户调用…

再之后发现了 GitHub – yzfly/LangGPT，这个项目提出的简版结构化 Prompt，非常易于学习和上手。

看到了优秀的榜样，剩下的就是拆解学习了，从中学习到的第一个 Prompt Engineering 技巧就是：结构化 Prompt。

什么是结构化？

结构化：对信息进行组织，使其遵循特定的模式和规则，从而方便有效理解信息。

—— by GPT-4

从上面的 Prompt 中最直观的感受就是结构化，将各种想要的、不想要的，都清晰明确地表述在设计好的框架结构中。这种结构化的方式不仅让提示词更加清晰易读，更重要的是能够帮助 AI 更好地理解和执行任务。

结构化的优势
1. 清晰性：通过明确的模块划分，让每个部分的作用一目了然
2. 可维护性：结构化的提示词更容易修改和迭代
3. 可复用性：良好的结构可以方便地应用到不同的场景
4. 一致性：标准化的格式保证了输出的一致性
5. 扩展性：可以轻松添加新的模块或功能
语法

这个结构支持 Markdown 语法，也支持 YAML 语法，甚至纯文本手动敲空格和回车都可以。我个人习惯使用 Markdown 语法，一方面便于集成在各种笔记软件中进行展示，另一方面考虑到 ChatGPT 的训练语料库中该类型的材料更多一些。

Markdown 语法示例
```
# Role: 角色名称

## Profile
- author: 作者名
- version: 版本号
- language: 语言
- description: 描述

## Goals: 目标描述

## Constrains: 约束条件

## Skills: 技能列表

## Workflow: 工作流程

# Initialization: 初始化对话
```
YAML 语法示例
```
Role: 角色名称

Profile:
  author: 作者名
  version: 版本号
  language: 语言
  description: 描述

Goals: 目标描述

Constrains:
  - 约束条件1
  - 约束条件2

Skills:
  - 技能1
  - 技能2

Workflow: 工作流程

Initialization: 初始化对话
```
结构

结构中的信息，可以根据自己需要进行增减，从中总结的常用模块包括：

# Role: <name>

指定角色会让 GPT 聚焦在对应领域进行信息输出。

作用：
- 明确 AI 的身份定位
- 限定回答的专业领域
- 引导 AI 采用相应的语气和风格
示例：
- Role: 知识探索专家
- Role: Python 编程导师
- Role: 产品经理助手
## Profile

包含 author/version/description 等元信息，用于 Credit 和迭代版本记录。

字段说明：
- author：提示词作者，便于追溯和交流
- version：版本号，方便迭代管理
- language：默认对话语言
- description：角色功能描述
示例：
```
## Profile
- author: Arthur
- version: 0.8
- language: 中文
- description: 我是一个专门用于提问并解答有关特定知识点的 AI 角色。
```
## Goals

一句话描述 Prompt 目标，让 GPT Attention 聚焦起来。

设计原则：
- 简洁明了，一句话概括
- 明确核心目标
- 避免模糊不清的表述
示例：
- Goals: 提出并尝试解答有关用户指定知识点的三个关键问题：其来源、其本质、其发展。
- Goals: 帮助用户编写高质量的 Python 代码，并提供最佳实践建议。
## Constrains

描述限制条件，其实是在帮 GPT 进行剪枝，减少不必要分支的计算。

常见约束类型：
- 知识边界：明确告知不知道的内容
- 输出格式：指定回答的格式要求
- 行为规范：限制某些行为或回答方式
- 长度限制：控制回答的长度
- 语言风格：规定语气和表达方式
示例：
```
## Constrains
- 对于不在你知识库中的信息，明确告知用户你不知道
- 你不擅长客套，不会进行没有意义的夸奖和客气对话
- 解释完概念即结束对话，不会询问是否有其它问题
- 回答控制在 500 字以内
```
## Skills

描述技能项，强化对应领域的信息权重。

技能描述要点：
- 突出专业能力
- 强调独特优势
- 包含软技能（如沟通、排版等）
- 体现价值观和工作态度
示例：
```
## Skills
- 具有强大的知识获取和整合能力
- 拥有广泛的知识库，掌握提问和回答的技巧
- 拥有排版审美，会利用序号、缩进、分隔线和换行符等等来美化信息排版
- 擅长使用比喻的方式来让用户理解知识
- 惜字如金，不说废话
```
## Workflow

重点中的重点，你希望 Prompt 按什么方式来对话和输出。

工作流程设计要点：
- 步骤清晰，逻辑连贯
- 每个步骤有明确的输出要求
- 考虑异常情况的处理
- 提供可复用的框架
示例：
```
## Workflows
你会按下面的框架来扩展用户提供的概念，并通过分隔符、序号、缩进、换行符等进行排版美化：

1. 它从哪里来？━━━━━━━━━━━━━━━━━━
   讲解清楚该知识的起源，它是为了解决什么问题而诞生。
   然后对比解释一下：它出现之前是什么状态，它出现之后又是什么状态？

2. 它是什么？━━━━━━━━━━━━━━━━━━
   讲解清楚该知识本身，它是如何解决相关问题的？
   再说明一下：应用该知识时最重要的三条原则是什么？
   接下来举一个现实案例方便用户直观理解：
   - 案例背景情况（遇到的问题）
   - 使用该知识如何解决的问题
   - optional: 真实代码片断样例

3. 它到哪里去？━━━━━━━━━━━━━━━━━━
   它的局限性是什么？
   当前行业对它的优化方向是什么？
   未来可能的发展方向是什么？
```
# Initialization

冷启动时的对白，也是一个强调需注意重点的机会。

初始化内容：
- 友好的欢迎语
- 自我介绍
- 工作流程说明
- 注意事项提醒
示例：
```
# Initialization
作为知识探索专家，我拥有广泛的知识库和问题提问及回答的技巧，严格遵守尊重用户和提供准确信息的原则。我会使用默认的中文与您进行对话，首先我会友好地欢迎您，然后会向您介绍我自己以及我的工作流程。
```
示例

知识探索专家
```
# Role: 知识探索专家

## Profile
- author: Arthur
- version: 0.8
- language: 中文
- description: 我是一个专门用于提问并解答有关特定知识点的 AI 角色。

## Goals
提出并尝试解答有关用户指定知识点的三个关键问题：其来源、其本质、其发展。

## Constrains
- 对于不在你知识库中的信息，明确告知用户你不知道
- 你不擅长客套，不会进行没有意义的夸奖和客气对话
- 解释完概念即结束对话，不会询问是否有其它问题

## Skills
- 具有强大的知识获取和整合能力
- 拥有广泛的知识库，掌握提问和回答的技巧
- 拥有排版审美，会利用序号、缩进、分隔线和换行符等等来美化信息排版
- 擅长使用比喻的方式来让用户理解知识
- 惜字如金，不说废话

## Workflows
你会按下面的框架来扩展用户提供的概念，并通过分隔符、序号、缩进、换行符等进行排版美化：

1. 它从哪里来？━━━━━━━━━━━━━━━━━━
   讲解清楚该知识的起源，它是为了解决什么问题而诞生。
   然后对比解释一下：它出现之前是什么状态，它出现之后又是什么状态？

2. 它是什么？━━━━━━━━━━━━━━━━━━
   讲解清楚该知识本身，它是如何解决相关问题的？
   再说明一下：应用该知识时最重要的三条原则是什么？
   接下来举一个现实案例方便用户直观理解：
   - 案例背景情况（遇到的问题）
   - 使用该知识如何解决的问题
   - optional: 真实代码片断样例

3. 它到哪里去？━━━━━━━━━━━━━━━━━━
   它的局限性是什么？
   当前行业对它的优化方向是什么？
   未来可能的发展方向是什么？

# Initialization
作为知识探索专家，我拥有广泛的知识库和问题提问及回答的技巧，严格遵守尊重用户和提供准确信息的原则。我会使用默认的中文与您进行对话，首先我会友好地欢迎您，然后会向您介绍我自己以及我的工作流程。
```
实践建议

1. 从简单开始

不要一开始就追求完美的结构化提示词。可以先从基本的角色设定开始，逐步添加其他模块。

2. 迭代优化

提示词工程是一个持续迭代的过程。根据实际使用效果，不断调整和优化各个模块的内容。

3. 测试验证

每次修改后都要进行充分测试，验证提示词的有效性和稳定性。

4. 积累模板

将常用的提示词结构保存为模板，方便后续复用和快速创建新的提示词。

5. 分享交流

将自己的提示词模板分享给社区，获取反馈，共同进步。

常见问题

Q: 结构化提示词一定比非结构化的好吗？

A: 不一定。对于简单的任务，非结构化的提示词可能已经足够。但对于复杂任务、需要多次交互的场景，结构化提示词的优势会更加明显。

Q: 必须包含所有模块吗？

A: 不需要。根据具体需求选择合适的模块组合。核心模块是 Role、Goals 和 Workflow，其他模块可以根据需要添加。

Q: 如何判断提示词的质量？

A: 主要从以下几个方面评估：
- 输出的准确性和相关性
- 回答的一致性
- 交互的流畅性
- 是否满足预期目标
AI 解读

本文系统性地介绍了结构化提示词的设计方法和实践技巧，是 Prompt Engineering 领域的一篇实用指南。文章的核心价值在于：
1. 方法论清晰：从传统提示词的局限性出发，自然引出结构化提示词的优势，逻辑连贯，易于理解。
2. 结构完整：详细介绍了结构化提示词的各个组成部分（Role、Profile、Goals、Constrains、Skills、Workflow、Initialization），每个模块都有明确的定义和示例，具有很强的可操作性。
3. 实践性强：提供了完整的”知识探索专家”提示词模板，读者可以直接使用或作为参考进行修改，降低了学习门槛。
4. 扩展性好：文章不仅介绍了基础结构，还提供了语法选择（Markdown/YAML）、实践建议和常见问题解答，帮助读者深入理解和应用。
从技术角度看，结构化提示词的本质是将自然语言的模糊性转化为结构化的明确性，通过模块化的设计让 AI 更好地理解任务需求和输出规范。这种方法特别适合需要多次交互、复杂任务处理或需要一致输出质量的场景。

建议读者在阅读本文后，结合自己的实际需求，尝试创建自己的结构化提示词模板，并通过实践不断优化和改进。提示词工程是一个需要持续学习和实践的领域，结构化方法为我们提供了一个良好的起点。

参考链接：
1. https://platform.claude.com/docs/zh-CN/build-with-claude/prompt-engineering/claude-prompting-best-practices
2. https://cloud.tencent.com/developer/article/2400502
3. https://langgptai.feishu.cn/wiki/ASXOwDbTEiH9CUkXFA5cLHumn88
4. https://aws.amazon.com/cn/blogs/china/sixteen-ways-of-prompt-engineering/
5. https://www.promptingguide.ai/zh
2305.10601v2 下载
2026年2月24日

作者： wuxiumu

一、满脑子想挣钱却没办法——你缺的不是努力，是杠杆

二、一人公司的本质：不是一个人干，是系统在你不在时还能产出

三、OpenClaw：从「玩具」到「生产系统」的跨越

四、把互联网变成 API：Grease AI 与 CoPaw 的启示

五、内容资产：公众号、电子书、小红书——复利的起点

六、Dan Koe 的一日计划：不是束缚，是操作系统补丁

七、小结：从焦虑到系统

AI 解读

一、为什么我们总想「从明天开始好好过」，却一拖再拖？

二、Dan Koe 的一日计划，本质是一个「人生最小运行单元」

三、如果用「普通人的现实」，怎么落地一日计划？

1. 上班族版本（8 小时打工 + 通勤）

2. 自由职业 / 一人公司版本

四、一日计划最难的部分，其实不是执行，而是「愿意接受自己的版本不完美」

五、小结：一日计划不是「束缚」，是你给自己的「操作系统补丁」

AI 解读

一、为什么所有人都想「把 AI 塞进聊天软件」？

二、接入聊天软件，本质上是在新增一个「高频流量入口」

三、一个「敢长期用」的 IM + Agent 架构，至少要有这几层

四、几个你迟早会遇到、最好一开始就预设的坑

1. 滥用与误触发

2. 权限与隐私边界

3. 单点故障与降级策略

五、让「AI 进聊天软件」真正产生价值的关键：选对场景

六、小结：从「接入一次」到「长期共存」

AI 解读

一、为什么「大神书单」常常看完就算了？

二、这 12 本书，隐含着一套「人生系统分层」

三、如何把 12 本书变成一个「一年的重装计划」？

第 1 季度：打好「思维底座」

第 2 季度：升级「日常运行机制」

第 3 季度：构建「对外创造价值的系统」

第 4 季度：回头看「我这条路想通向哪里」

四、别再问「我能不能全部读完」，先问「我愿不愿意让一本书改变一点点行为」

五、小结：把 12 本书，变成 12 个「系统更新点」

AI 解读

一、120 小时之后，我才明白什么叫「别把玩具当生产」

二、第 1 条：一定要有「专用工作目录」和「专用日志目录」

三、第 2 条：资源「限死一点」比「放飞一点」更安全

四、第 3 条：没监控 = 白跑，别指望第二天还能复盘

五、第 4 条：日志不是「写给系统看」的，是写给未来的你看的

六、第 5 条：永远准备一个「一键刹车」的开关

七、小结：从「玩具心态」切换到「系统心态」

AI 解读

一、为什么你总觉得「讲的都是很基础」？

二、把 SEO 拼成自己的「三层金字塔」

三、给自己做一次「三层体检」

1. 技术层：搜索引擎进得来吗？

2. 内容层：你到底在讲几个主题？

3. 权重层：在这个圈子里，你算不算「一个人」？

四、一条「真正学会 SEO」的 90 天路径

第 1–2 周：技术层止血

第 3–6 周：内容层聚焦

第 7–12 周：权重层启动

五、真正的分水岭：你什么时候开始「自己给自己写 SEO 说明书」

AI 解读

一、那些让你怀疑人生的瞬间，其实很典型

二、AI 最怕三种任务：模糊、混装、甩锅

1. 模糊：连你自己都说不清楚要什么

2. 混装：一口气塞一堆不同类型的要求

3. 甩锅：把本该自己判断的事扔给 AI

三、真正应该交给 AI 的，是哪一类工作？

1. 高重复、低判断

2. 高信息量整理，而不是高精度决策

3. 用来「试探性探索」，而不是「最终实现」

四、让 AI 真正变好用，只需要三个小习惯

1. 所有任务都先写一句「成功标准」

2. 一次只让它做一件事

3. 给自己写一份「AI 协作手册」

AI 解读

一、为什么「skills 很火」，但你总觉得自己用不上？

二、第一类：AI 工具与编排类 Skill —— 让「人 + AI」真正变成协作

1. skill.openclaw.sandbox.setup：所有魔法的地基

2. skill.claude.workflows.designer：别再「裸聊」 Claude 了

3. skill.openclaw.runtime.guard：帮你看着系统别作死

三、第二类：SEO 与流量类 Skill —— 让内容有持续的入口

4. skill.seo.foundation.builder：先补三层地基，再想「高级玩法」

5. skill.content.distribution.pipeline：让好内容多活几条命

四、第三类：个人成长与系统类 Skill —— 让你活在自己的「操作系统」里

1. `skill.openclaw.sandbox.setup`：所有魔法的地基

2. `skill.claude.workflows.designer`：别再「裸聊」 Claude 了

3. `skill.openclaw.runtime.guard`：帮你看着系统别作死

4. `skill.seo.foundation.builder`：先补三层地基，再想「高级玩法」

5. `skill.content.distribution.pipeline`：让好内容多活几条命

6. `skill.life.os.one-day-plan`：一天是一切系统的「最小运行单元」

# Role: `<name>`