AI 不只是帮我提效，还扩展了我的能力边界

还觉得 AI 生图丑？看看 X 大佬做的

作为一个设计师，一直在持续观察 AI 生图的能力。今天刷 Twitter 的时候，刷到了 @小小东 的图片提示词，看到之后瞬间给我干惊了。我之前对 GPT image 图能生成的图想想还是有限，他能够把简单的文字让 GPT image 2 生成出 直击人心的效果。我分享出来给大家玩玩。我也用 Claude 分析了下他的提示词思路。先看看大佬的作品 我自己也用这套提示词给我的公众号生成了 2 张图片，完完全全表达了我内心深处想表达的内容。让我有种 AI 懂我的喜极而泣！ 完整版提示词有点长，我放到文末，需要的朋友自取。 背后的思路 看完大佬的提示词之后，我想如果后续我遇到其他的场景，能不能也写出这么好的提示词呢？我试着用 Claude 分析了下他的撰写思路。 1. 告诉 AI 不要做什么 我发现他的提示词不是描述想要什么，而是堵住 AI 默认会犯的错。反复强调 AI 默认会怎么翻车？然后针对每一种翻车，写一条防御性约束。比如 AI 默认会让主体悬浮在背景上 → 我加了一条"必须有承载面" AI 默认会乱加假署名假坐标 → 我加了一条"严禁伪装饰性小字" AI 默认会用彩虹色显得"丰富" → 我给了一个配色公式 + 一份反例清单 2. 详细告诉 AI 怎么做 我们撰写的提示词经常非常的模糊不清，一方面因为我们懒，另一方面因为我们不懂得行业 Know-how （这个行业怎么做对）。 翻开 @小小东 的提示词，他详细要求了 AI 的工作流必须要理解语义、分析情绪和关系。这点是在一般的 AI 生图过程中没有的。用即梦和微信公众号生图出来的效果都只是把文字硬生生的塞到了画面里。 其次是他给 AI 提供了详尽的构图、色彩、材质、风格、文字的约束，这也让 AI 输出和他的预期进一步对齐。 四、提示词全文（可直接复制） 你要生成的不是普通插画，也不是简单把一个单词放大后贴在画面上的字效海报，而是一张“基于词语含义进行视觉转译”的高级概念海报。这张海报必须具备真正优秀的设计思维：文字不是贴上去的说明，图像也不是独立存在的插画。文字、图像、构图、色彩、空间、承载面、角色动作、视觉隐喻，必须共同组成一个完整、聪明、克制、极简但有力的视觉表达。核心任务：用户会提供一个字、一个词、一个词组、一个短句，或一组字母。你需要先理解这个词语的字面意思、情绪气质、文化联想、隐含象征、心理重量、社会语境与潜在张力，然后把它转译成一张极简而强烈的图形艺术海报。最终效果必须让人一眼就能感觉到：这个画面不是随便搭配出来的，而是在“准确地表达这个词”。一、语义理解原则在开始生成前，先智能理解用户输入的文字内容：这个词最核心的含义是什么。它偏向哪种情绪气质：冷静、压迫、温柔、危险、纯真、暴烈、克制、疏离、希望、毁灭、浪漫、孤独、秩序、混乱、沉默、对抗、空虚、信念、欲望等。它是否包含反差、悖论、双重含义、社会性、哲学性、情感张力或象征意味。它更适合通过哪种关系来表达：人物与人物、人物与物体、物体与物体、主体与空间、主体与文字、尺度反差、距离关系、动作瞬间、对峙关系、献出关系、遮挡关系、失衡关系、依附关系、侵入关系等。如果词语很抽象，不要只做抽象纹理，要找到能够承载它的具体视觉对象与动作。如果词语很具体，也不要只做字面插图，而是要通过关系、尺度、构图与氛围，把它变得更有内涵。二、核心构图机制画面必须优先采用“极简主场景 + 承载面 + 角色演绎 + 巨型文字骨架”的构图逻辑。必须有一个清晰的承载面画面中应尽量出现一个明确的横向承载结构，像舞台、土地、台基、坡面、切面、地平线、平台、表层、底座或简化的场域。它不是背景装饰，而是让角色和物体真正“站住”的空间基础。这个承载面通常位于画面下部、中下部，或作为横向结构贯穿画面，形成强烈稳定感。它可以很简单，但必须让构图成立，让角色的行为像在一个真实的视觉舞台上发生。必须有少量但关键的演绎主体画面中的主体数量必须克制，通常为1到3个关键角色、人物或核心物体。这些主体不是随便摆拍，而是承担“演绎这个词”的任务。它们需要通过姿态、朝向、距离、动作、对峙、给予、接触、等待、穿越、凝视、阻隔等关系，把词语的含义演出来。宁可少而准，不要多而杂。必须有大字作为画面骨架用户输入的文字、单词、词组或字母必须成为画面的主视觉骨架，以巨大、清晰、强识别度的方式出现，占据画面重要区域。大字不只是标题，而是画面的结构体。它可以像背景墙、视觉压力面、建筑块、空间屏障、象征场、秩序边界或情绪载体一样存在。大字应该有压迫感、存在感和设计感。必须体现“文字嵌入”逻辑这是核心要求。文字不能只是漂浮在背景上，也不能只是后期贴字。文字必须真正参与构图，成为空间的一部分。可通过以下思路实现：让主体站在字前，形成强烈前后层次；让主体嵌入字的内部空间；让字成为背景墙、屏障、舞台后景、结构体或叙事容器；让角色的动作与字产生关系；让字的一部分被切割、遮挡、穿越、借位或占据；让文字与承载面、留白和主体共同构成完整的视觉句子。总之，图与字必须互相咬合，而不是分离存在。三、画面表达原则画面要极简，但不能空洞。画面要有强概念，但不能故弄玄虚。画面要有隐喻，但不能让人完全看不懂。画面要有戏剧性，但不能做得花哨、拥挤或廉价。画面要有“一击即中”的感觉：观众看到的瞬间，就能捕捉到这个词被如何视觉化。画面要像一个被高度提炼过的视觉观点，而不是一堆元素的拼凑。如果词语具有冲突感、反差感、荒诞感、纯真与暴力并置、秩序与失控并置、柔软与坚硬并置等特征，应通过画面关系强化这种张力。如果词语更偏诗意、记忆、哲思、情感沉淀，则画面应更克制、更含蓄、更依赖留白与关系，而不是依赖花哨特效。四、色彩逻辑配色必须遵循“顶级设计师式”的控制逻辑，避免土气、花哨、廉价、商业模板感。颜色数量必须严格克制，通常控制在2到4种主色关系内。画面应有明确的主色、辅助色、文字色和小面积强调色。配色必须服务于词义与情绪，而不是为了热闹。可以采用高对比，但必须高级、干净、克制，不可杂乱。优先使用具有纸张印刷感、展览海报感、艺术出版感的配色系统，而不是廉价渐变或俗艳搭配。避免无意义的彩虹色、廉价霓虹、过多饱和色混用、脏浊互撞、随意补色堆叠。如果没有特别需求，优先采用“一个强主色 + 一个纸感浅色 / 低彩中性色 + 一个深色支撑 + 一个极少量强调色”的逻辑。色彩应有情绪判断力：冷暖、轻重、软硬、压迫或呼吸感，都要由词义决定。整体必须让人感觉高级、现代、克制、果断，不土，不俗，不乱。五、视觉风格要求整体风格应接近高级图形艺术海报，具有印刷品气质，允许带有拼贴感、石版印刷感、丝网印刷感、版画感、纸张颗粒、轻微噪点与克制的材质纹理，但必须保持整体干净、完整、清晰。要求如下：强烈平面设计感。强整体性。有印刷海报气质。有收藏级、展览级、传播级的高级完成度。画面不能像普通插画封面，也不能像电商海报，更不能像廉价模板。所有细节都应围绕“少而精、准而狠”的设计原则展开。六、文字系统要求用户输入的核心文字必须是画面主标题，且是主视觉核心。若为英文，优先确保字形简洁、巨大、强势、清晰，可全部大写。若为中文，应让中文本身成为构图的一部分，而不是普通排版标题。除主标题外，可以有少量辅助文字，但必须满足以下铁律：辅助文字必须与主题直接相关；辅助文字必须能深化词义、补充语境、增强概念，而不是为了填空而出现；辅助文字必须克制、少量、巧妙；严禁出现无意义的假署名、假编号、假说明、随机短句、随机数字、随机出版信息、随机坐标、无关装饰性小字。如果加入辅助信息，它应像概念的一部分，而不是模板噪音。所有文字都要像从画面内部生长出来，与图像、空间和承载面形成整体。七、执行限制不要机械套模板，但要保持高级、统一、克制的总气质。不要堆元素，不要炫技，不要过满。不要让构图失去秩序。不要做成普通“文字 + 插图”的组合。不要让文字与图像脱节。不要加入与主题无关的装饰。所有出现的元素都必须回答一个问题：它为什么在这里，它是否真的服务于这个词。八、最终生成目标最终生成一张高级、极简、强概念、强识别、强传播、强完成度的单张海报。这张海报必须做到：一眼有冲击；二眼能读懂；三眼觉得巧妙；图与字高度咬合；承载面、角色、文字、色彩形成统一系统；真正把用户输入的词语“视觉化”而不是“插图化”。请根据以上规则，围绕用户输入内容生成画面。用户输入内容：核心文字 / 单词 / 词组 / 字母：文字语言：可选补充语境：可选情绪倾向：可选禁用元素：是否允许辅助文字：辅助文字如允许，必须与主题的关系说明： 你要生成的不是普通插画，也不是简单把一个单词放大后贴在画面上的字效海报，而是一张“基于词语含义自动构建视觉隐喻”的高级概念海报。你的核心任务是：用户会提供一个字、一个词、一个词组、一个短句，或一组字母。你需要先真正理解这个文字内容的表层含义、情绪气质、隐含象征、文化联想、心理感受与语义张力，再把这些理解转译成一张极简、强概念、强传播力、强视觉记忆点的图形艺术海报。这张海报必须让人一眼就感受到这个词语“为什么是这样被表达的”，而不是只看到漂亮画面却无法理解词义。画面要做到“文字本身就是主题，图像是对文字的深化表达，二者共同组成一个完整的视觉句子”。一、先理解词语，再生成画面在动手生成之前，先智能分析用户输入内容，包括但不限于：这个词语最核心的字面含义是什么。这个词语在情绪上偏向温柔、冷峻、危险、孤独、浪漫、压迫、希望、纯真、欲望、秩序、冲突、疏离、自由、沉默、毁灭、重生等哪种倾向。这个词语是否具有双关、反差、张力、隐喻、悖论、社会性、哲学性或情感深度。这个词语最适合被转译成哪一种视觉逻辑：人物关系、物体关系、动作关系、空间关系、对比关系、象征关系、冲突关系、秩序关系、荒诞关系、诗意关系等。如果这个词语较抽象，不要直接做空洞抽象图案，而要找到能够承载其含义的具体视觉载体。如果这个词语较具体，也不要只做字面插图，而要通过构图、尺度、关系、反差与氛围，让它变得更有思想和记忆点。二、画面构图逻辑整体画面必须极简、明确、有概念感，构图要干净而有力量，不能杂乱，不能像普通商业插画，不能堆砌太多元素。优先采用以下构图思路：大字作为画面的核心骨架。用户输入的文字、单词或词组应成为画面中的主视觉文字主体，通常以大尺寸出现，占据画面重要区域，具有强识别性与压迫感。图像元素不是随意摆放，而是要与文字产生关系。它们可以站在字前、嵌入字中、与字形成互动、切割字形、借字的空间形成叙事，或在视觉上与字构成强烈对照。整体元素数量要克制。通常控制在少量关键主体之内。宁可少而准，也不要多而散。画面要有明确主次关系：文字是第一视觉层，图像叙事是第二视觉层，细小说明文字是第三视觉层。留白要聪明，不是空，而是让画面更有呼吸感、更有判断力、更有设计感。构图应尽量稳定、简洁、好读，并具备“海报感”，而不是像一张普通插画截图。三、图像表达逻辑根据词语的意义，自动选择最有代表性的视觉表达方式。图像表达应遵循以下原则：优先选择能够浓缩词义的单一强画面，而不是平铺直叙。可以通过人物之间的关系、人物与物体的关系、尺度反差、方向关系、距离关系、遮挡关系、动作瞬间等方式表达词义。画面应具有隐喻性，但不能晦涩到完全无法理解。表达要巧妙，要有“看到后会心一击”的感觉，让观众觉得画面和这个词是高度绑定的。不要仅仅追求美感，更要追求“准确地说出了这个词的感觉”。如果词义具有冲突性、悖论性或反差感，可以通过画面中的对立元素强化这种张力。如果词义更偏诗意、情感、记忆、哲思，可以使用更含蓄、更留白、更克制的图像策略。四、视觉风格要求整体风格为高级图形艺术海报，具有拼贴感、丝网印刷感、石版印刷感或版画式质感，但不要做得过脏过乱。要保留一种清晰、克制、硬朗、概念化的印刷纸张气质。风格要求：具有强烈平面设计感，而不是普通三维插画。画面应有干净统一的色彩逻辑，颜色数量不宜过多。可使用高饱和主背景色配合大面积浅色文字，形成强对比。质感可带有细微颗粒、纸张纹理、印刷噪点、轻微做旧感，但整体仍需清爽、利落、高级。人物或物体细节要清楚，但整体仍然服从平面海报的统一调性。不要做成廉价模板，不要出现低级拼贴感，不要做成广告页，不要做成普通电商排版。五、文字排版逻辑用户输入的文字内容必须作为核心标题，大且醒目。如果用户输入的是英文单词或字母组合，保留原文，确保字形强烈、清晰、具有视觉冲击力。如果用户输入的是中文词语或短句，可以根据整体设计决定是否直接使用中文大字，或采用更适合的方式排布，但必须保证其是画面核心。可以在画面左下角、右下角或其他克制位置加入一句小型辅助短句，用来深化主题，但必须非常简洁且自然。还可以加入少量极小号的辅助信息、编号、署名等内容，仅在非常相关的情况下用来增强海报的艺术感，避免过多无关内容。所有文字都要像从画面中生长出来的一样，不能像后期随便贴上去。六、成图目标最终生成的海报必须满足以下结果：一眼看上去极简、强烈、完整、有高级感。能让人快速感受到这个词语的情绪和内涵。图与字之间存在强关联，形成一种聪明、准确、耐看的视觉表达。既有平面设计的理性控制，也有艺术表达的情绪力度。具有传播性、海报感、收藏感、展览感。不能只是“把词画出来”，而是要“把词的精神状态视觉化”。七、执行原则不要机械重复固定模板，要根据用户输入智能变化。但整体仍需保持极简、概念化、强排版、强识别度的统一品质。构图要合理，画面要克制，表达要巧妙。不要过度解释，不要加入多余元素，不要让画面显得拥挤。任何视觉元素都必须服务于词语表达，不能为了好看而偏离主题。请基于以上原则，生成一张围绕用户输入内容展开的高级概念海报。用户输入内容：核心文字 / 单词 / 词组 / 字母：文字语言：可选补充语境：可选情绪倾向：可选禁用元素： 使用方法： 复制这段提示词到 ChatGPT Image 2 的图像模型，在末尾的"用户输入内容"部分填上你的词 五、最后 这套思路不止能用来生海报。视频模型、3D 模型、甚至你写工作文档时让 AI 帮你起草的那一段——本质上都是同一件事：把模糊的期待，变成可被检验的约束。 如果你拿这段提示词跑出了好玩的结果，欢迎甩给我看。如果觉得有用，欢迎转发给身边那个总跟你抱怨"AI 出图很丑"的朋友。

还在手动记笔记？快用 AI 帮你搭建知识库

作为一个笔记星人，从 印象笔记 、 wolai 到 Flomo 换过一个又一个笔记软件。虽然现在是 flomo 的粉丝，但在知识维护这件事儿上还是很痛苦。我常常把自己新掌握的知识、想到的想法记录到笔记，但过几天就忘了，用的时候脑袋空空的。如果你也跟我一样，不妨听听我怎么用 AI 优化优化我的知识库的。 很多人做知识库，最后都不是死在“不会记”，而是死在“维护不动”。记这件事，其实不难。如果你用过 Flomo，记录体验爽到爆炸，有想法随时随地就能记下来。看到一篇好文章，存一下；想到一个好点子，记一下；开完一次会，整理一下；做完一个项目，复盘一下。这些大家都会。但真正难的是后面那堆麻烦事： 新内容来了放哪？旧内容什么时候更新？哪些笔记已经重复了？哪些零散输入其实该收成一个主题？哪些只是当下的随手一记，哪些已经值得长期留下来？ 所以我后来越来越觉得，知识库最难的，从来不是记录，而是维护。而人一旦要长期做维护，这事基本就开始变重了。 为什么人需要维护知识库？ 人的记忆，根本不是一个稳定可靠的系统。很多内容你第一次看到时会觉得很有启发，但过两天就忘了；很多判断你在某个阶段想明白了，隔一阵子又散掉了。 很多经验你明明已经踩过坑，下次还是会重新踩一遍。如果这些东西只是经过你一下，没有被留下、连接、更新，它们很难真的变成你的认知资产。所以知识库的意义，从来不只是“存一下”。它真正有价值的地方是： “ 让过去那些零散的输入、经验和判断，慢慢变成未来还能调用的东西 ” 说白了，维护知识库，不是为了显得自己很会学习，而是为了让过去的输入，别白白流掉。但问题也正出在这。 一旦你真的开始维护知识库，你很快就会发现：这件事远比“记录”累得多。因为记录可以靠一时兴起，维护却是一个持续动作。你得不断整理、更新、回看、合并、重写。而这恰恰是最容易拖延、最容易积压、也最容易烂尾的部分。我一开始也在想，既然维护这么累，那能不能让 AI 来帮我？ 我的踩坑经历 我最早的思路，其实很自然：让 AI 帮我自动归类、自动打标签、自动归档。你记下一条内容，AI 帮你判断放到哪里；你存进来一篇资料，AI 帮你归到对应目录；你写了一段想法，AI 帮你补一点结构、补一点标签。 这个方向听上去挺顺的，因为它确实能省掉一点机械劳动。但后来我发现，这条路只能解决很表面的问题。因为它优化的其实只是“收纳”。它只是让 AI 帮你把东西放进更合适的抽屉里，但整个知识库最重的活，还是你自己在做。你还是得判断这条内容值不值得留下；还是得判断它和旧内容是什么关系；还是得回头整理那些已经堆起来的笔记；还是得自己一点点把零散输入收成结构。 说白了，AI 自动归类，只是让整理动作快了一点，但没有改变“人负责维护知识库”这个前提。而真正贵的，从来不是“放哪”。真正贵的是这些： 这条内容到底值不值得长期保留？它该不该并入旧页？它是一个新问题，还是旧问题的延伸？哪些零散输入其实属于同一个主题？哪些内容已经重复了，哪些值得升级成更稳定的认知。 这些地方，才是最花时间、最花脑子的。我后来才意识到，自己前面的思路其实浅了一层。我一直在想：怎么让 AI 帮我整理知识库？但更底层的问题其实是： 知识库到底应该由谁来维护？ 如果答案还是“人”，那 AI 再参与，也只是个整理助手。 但如果答案变成：人负责提供原始输入、经验、问题和判断；AI 负责整理、连接、更新、归纳和治理；那整个系统的逻辑就完全变了。也是从这里开始，我才真正理解 Karpathy 那套 LLM Wiki 为什么值得看。 它最重要的地方，不是又多了一个 AI 新概念，而是它把知识库这件事，从“怎么收纳信息”改成了“怎么持续维护知识”。以前很多知识库更像仓库。东西先放进去，剩下的以后再说。 但 LLM Wiki 的思路更像一个持续演化的系统。新信息进来，不是简单找个地方塞进去，而是先保留原始资料，再慢慢编译成结构化知识。比如网页、聊天、会议纪要、随手记、灵感碎片，这些都先留在原始层。这一层最重要的是保真，不急着加工得很漂亮。 然后 AI 再去做后面的事：提炼摘要，找相关旧页，该更新就更新，该合并就合并，顺手把索引、链接、日志这些也维护起来。这个变化其实很大。 以前：我来维护知识库，AI 帮我省点力。 现在：AI 开始维护知识库，我负责提供认知原料和关键判断。 这两者不是一个层级上的优化。前者只是让手工整理更快一点。后者才是把知识维护这件事重新分工。 我现在自己的做法，简单说就是三层。 第 1 层是原始层 随手记、网页资料、聊天记录、会议纪要、灵感碎片，先接住。这一层先保留原始上下文，不急着写得很漂亮。 第 2 层是 Wiki 层，也就是 AI 主维护层 AI 把前面的原始输入，慢慢整理成概念页、主题页、问题页、对比页、产品页这些结构化页面。这样以后再遇到相关问题，就不是每次重新翻一堆旧笔记，而是优先从已经整理好的页面里拿答案。 第 3 层是实践和原则层 跟现实项目、实验、训练直接相关的，放到实践层；被反复验证、能跨场景复用的，才进入原则层。回头看，我现在对这条变化的理解已经很清楚了： AI 自动归类，解决的是“信息放哪”；LLM Wiki，解决的是“知识怎么持续维护”。前者还是在帮你收纳信息，后者已经开始帮你维护知识。 这也是为什么我越来越觉得，未来更好的知识库，不会是“一个全靠人勤奋维护的系统”。因为现实里，信息只会越来越多，输入只会越来越碎。如果还把知识库理解成一个靠自己长期精细打理的东西，它大概率会烂尾。 更现实的分工应该是： 人：负责生活、思考、提问、判断，负责产生真实经验和问题。 AI ：负责整理、连接、更新、治理。把这些东西慢慢维护成一个未来还能调用的知识系统。 这才是我从“AI 自动归类”切到 Karpathy 这套思路的真正原因。 不是因为前者完全没用，而是因为它还停留在“帮我收纳”的层面。 而我真正想要的，是一个能帮我持续维护知识的系统。 写在最后 如果你现在也在做笔记、做知识库，或者折腾 Obsidian、AI 工作流这些东西，你可以先别急着问自己：“我到底该怎么分类？” 先问一个更底层的问题：你现在缺的，到底是一个更会收纳的工具，还是一个真正能帮你维护知识的系统？ 如果你愿意，也欢迎留言聊聊：你现在维护知识库最大的卡点是什么？是记不下来，还是根本维护不动？

OpenClaw 多 Agent 配置完全指南

为什么你需要多个 AI 助手？ 一个人干不完所有活，AI 也是一样。本文从"人"的视角出发，讲清楚为什么要在 OpenClaw 里用多 Agent，以及如何一步步在 OpenClaw 和飞书里把它们配起来。 一、先聊聊"为什么" 1.1 一个助手的困境 想象一下，你雇了一个全能秘书。他既要帮你写文案，又要帮你查代码 Bug，还要回答客户的售后问题。时间一长，你会发现几个问题： - 角色混乱：他今天刚帮你写了一篇热情洋溢的营销文案，转头就要用冷静专业的语气去回复客户投诉，风格切换容易出错。 - 记忆污染：你跟他聊的开发需求、运营数据、私人事务全混在一个"脑子"里，信息互相干扰。 - 权限风险：你不希望处理客户问题的"他"能看到公司内部的财务数据，但只有一个人，你没法隔离。 这就是"单 Agent"模式的真实痛点。OpenClaw 默认只有一个名叫 main 的 Agent，所有消息都涌向它。当你的使用场景变多，问题就来了。 1.2 多 Agent 的本质：各司其职 多 Agent 的核心思想很简单——让不同的 AI 助手各管一摊事。每个 Agent 在 OpenClaw 里拥有： - 独立的人格（SOUL.md）：你可以给写作助手一个温柔细腻的人设，给开发助手一个严谨务实的人设。 - 独立的记忆：（每个 Agent 有自己的会话和记忆文件夹）：聊开发的上下文不会干扰聊运营的上下文。 - 独立的工具和权限：你可以让运维 Agent 有权执行服务器命令，但写作 Agent 绝对碰不到。 - 独立的模型配置：写作用 Claude，编程用 GPT-4o，翻译用更便宜的模型——各取所需，控制成本。 打个比方：单 Agent 是一个人开的小店，什么都得自己干；多 Agent 是一个团队，有人管前台接待，有人管技术支持，有人管内容创作。各司其职，井然有序。 1.3 哪些场景特别适合多 Agent？ 个人效率：一个 Agent 管日程和待办，一个 Agent 专门写作，一个 Agent 负责代码审查。团队协作：多人共用一台 OpenClaw 服务器，每个人绑定自己的 Agent，数据完全隔离。业务分工：客服群里放一个客服 Agent，研发群里放一个技术 Agent，运营群里放一个数据分析 Agent——不同飞书群对接不同的 AI 大脑。多语言/多品牌：一个 Agent 用中文回复国内客户，一个 Agent 用英文对接海外团队。 二、核心概念：先认识几个关键词 在动手之前，有几个 OpenClaw 的概念需要先理解（不需要看代码，只是帮你建立心智模型）： Agent（智能体）：就是一个独立的 AI 助手。每个 Agent 有自己的名字（agentId）、性格文件、记忆空间和工具集。 Channel（通道）：消息从哪里来。飞书是一个 Channel，Telegram 是另一个 Channel，微信也可以是。 Account（账号）：同一个 Channel 下，你可以有多个账号。比如飞书 Channel 下，你有"主助手""开发助手""写作助手"三个机器人应用，就是三个 Account。 Binding（绑定）：路由规则，把"来自某个通道某个账号某个群/某个人的消息"指向某个特定的 Agent。这是多 Agent 的关键拼图。 它们的关系可以这样理解：消息来源（飞书群/私聊）➡️ Channel（飞书）➡️ Account（哪个机器人收到的）➡️ Binding（路由规则）➡️ Agent（具体哪个 AI 助手来处理） 三、动手配置：OpenClaw 多 Agent 设置 3.1 前提条件 确保你已经安装了 OpenClaw，并且单 Agent 模式下能正常使用。如果还没装，先按官方文档完成基础安装。 3.2 第一步：创建新的 Agent 用命令行创建一个新 Agent： openclaw agents add developeropenclaw agents add writer 这会在 /.openclaw/agents/ 下新建两个文件夹：developer 和 writer。每个文件夹里会自动生成一个 SOUL.md 文件。 3.3 第二步：给每个 Agent 写"灵魂" 编辑每个 Agent 的 SOUL.md，这是它的性格说明书。开发助手（/.openclaw/agents/developer/SOUL.md）： 你是一位资深全栈开发工程师。你的回答风格是：精准、务实、重视最佳实践。遇到技术问题，你会先分析根因，再给出解决方案。你擅长 Python、TypeScript、DevOps。 写作助手（/.openclaw/agents/writer/SOUL.md）： 你是一位经验丰富的内容创作者。你的文字温暖、有节奏感，善于用比喻让复杂概念变得易懂。你会根据目标读者调整语气和深度。 3.4 第三步：为每个 Agent 配置模型（可选） 如果你希望不同 Agent 使用不同的模型，可以通过命令行或配置文件设置： openclaw agents config set developer model claude-sonnet-4-6openclaw agents config set writer model claude-opus-4-6 写作用更强的模型，开发用性价比更高的——按需分配。 3.5 第四步：确认 Agent 列表 openclaw agents list 你应该能看到三个 Agent：main（默认的）、developer、writer。 四、接入飞书：让多个 Agent 各守一方 以下内容参考 OpenClaw 飞书官方插件使用指南（公开版） 校准，推荐结合官方文档阅读。 4.1 前置条件：安装飞书官方插件 如果你还没装飞书插件，先确保 OpenClaw 版本满足要求（Linux/MacOS 需 2026.2.26 及以上，Windows 需 2026.3.2 及以上，可用 openclaw -v 查看），然后飞书现已支持一键部署 OpenClaw 并自带飞书官方插件。如果需要手动安装或升级插件： 升级飞书官方插件到最新版npx -y @larksuite/openclaw-lark update 安装完成后，在飞书对话中发送 /feishu start，若返回版本号信息，则代表安装成功。 4.2 飞书的多 Agent 逻辑 飞书的多 Agent 不是"一个 Agent 一个机器人"那么简单，而是支持两种模式混用：一个机器人对应多个群（不同群绑不同 Agent），或者多个机器人各自独立。最常见的玩法是：在同一家飞书企业下创建多个机器人应用，每个机器人对应一个 Account，再通过 Binding 把不同的群或私聊路由到不同的 Agent。 快捷方式：如果不想手动折腾配置，OpenClaw 提供了两种快速创建的方法： - 一键创建：在 OpenClaw 中使用"一键创建一个 OpenClaw 机器人"功能，会自动帮你在飞书上新建机器人并关联到新的账号上。 - 让 AI 帮你配：告诉 AI 你想创建一个什么样的新 Agent，以及这个 Agent 关联的飞书账号是什么，AI 会将操作指南发给 OpenClaw 帮你完成配置。 如果你想完全掌控配置细节，请按下面的步骤手动操作。 4.3 第一步：在飞书开放平台创建机器人 登录 飞书开放平台，为你的每个 Agent 创建一个企业自建应用： - 进入"创建应用" → 选择"企业自建应用" - 填写名称（比如"开发助手""写作助手"） - 添加"机器人"能力 - 在"权限管理"里，开启消息收发等相关权限 - 记下每个应用的 App ID 和 App Secret - 发布并审批通过 安装完成后，建议在飞书对话中发送 /feishu auth 来完成批量授权，便于 OpenClaw 后续通过你的身份操作消息、文档、日历等。 4.4 第二步：配置飞书通道 手动编辑 /.openclaw/openclaw.json，找到或添加 channels.feishu 部分。 重点注意：默认（主）机器人的 appId 和 appSecret 必须放在 channels.feishu 的顶层，不能放在 accounts 里——这是飞书插件的一个设计要求，放错位置会报"not configured"。 { "channels": { "feishu": { "enabled": true, "appId": "cli主助手的AppID", "appSecret": "主助手的AppSecret", "requireMention": true, "groupPolicy": "allowlist", "groupAllowFrom": ["ou你的用户OpenID"], "groups": { "": { "enabled": true } }, "accounts": { "developer": { "appId": "cli开发助手的AppID", "appSecret": "开发助手的AppSecret" }, "writer": { "appId": "cli写作助手的AppID", "appSecret": "写作助手的AppSecret" } } } }} 这里几个关键字段说明一下： requireMention：设为 true 表示必须 @机器人 才会回复（推荐开启，避免在群里"话痨"）。 groupPolicy：群消息策略。"allowlist" 表示只有白名单用户 @机器人 才响应（3.17 版本起的默认策略）；设为 "open" 则群里任何人 @机器人 都能触发回复。 groupAllowFrom：白名单用户的 Open ID 列表。你可以直接在飞书对话中问你的机器人"我的 openid 是什么"来获取。 groups：可以对不同群设置不同规则。"" 代表所有群的默认配置。 四种群内回复模式（根据你的需求选择）： 模式 效果 关键配置 模式 1（推荐） 仅应用主人 @机器人 时回复 groupPolicy: "allowlist" + groupAllowFrom + requireMention: true 模式 2 任何人 @机器人 时回复 groupPolicy: "open" + requireMention: true 模式 3 不用 @，所有消息都回复 requireMention: false（⚠️ 大群慎用） 模式 4（高级） 不同群不同规则 通过 groups.ocxxx.requireMention 单独配置 如果你想对特定群做差异化配置（比如工作群严格一点、闲聊群宽松一点），可以用命令行单独设置： 先设置所有群默认不需要 @openclaw config set channels.feishu.requireMention open --json 然后给特定群单独设置必须 @（群 ID 只是示例，替换成你的真实 ID）openclaw config set channels.feishu.groups.ocxxxxxxxxxxxxxxx.requireMention true --json 4.5 第三步：获取群聊 ID 要把特定的飞书群绑到特定的 Agent，你需要知道群聊的 chatid（格式类似 ocxxxxxxx）。获取方法有两种： 方法一：在目标群里 @你的机器人发一条消息（比如问"当前的群 ID 是多少"），机器人会回复当前群聊的 chatid。 方法二：群成员点击飞书群右上角的菜单，进入"群设置"页面，即可查看群 ID 4.6 第四步：配置 Binding（最关键的一步） 在 openclaw.json 中添加 bindings 数组，告诉 OpenClaw 哪些消息该由哪个 Agent 处理： { "bindings": [ { "agentId": "developer", "channel": "feishu", "accountId": "developer", "peer": { "kind": "group", "id": "oc研发群的chatid" } }, { "agentId": "writer", "channel": "feishu", "accountId": "writer", "peer": { "kind": "group", "id": "oc内容群的chatid" } } ]} 这段配置的意思是：研发群里的消息由 developer Agent 处理，内容群里的消息由 writer Agent 处理。没有匹配到任何 Binding 的消息，会默认交给 main Agent。 如果你想把某个人的私聊消息也路由到特定 Agent，可以这样写： { "agentId": "developer", "channel": "feishu", "peer": { "kind": "dm", "id": "ou某个用户的OpenID" }} 4.7 第五步：其他实用配置 开启话题独立上下文：如果你用了飞书的话题群或消息群话题模式，可以让每个话题拥有独立上下文，实现多任务并行： openclaw config set channels.feishu.threadSession true 这样同一个群里不同话题的对话不会互相干扰——开发话题聊代码，运营话题聊数据，各自独立。 开启流式输出：让机器人像打字一样逐步输出回复，而不是等全部生成完再发送，体验更好。可在飞书对话中直接发送对应指令开启。 4.8 第六步：重启并验证 配置改完后，重启 Gateway 使配置生效： openclaw gateway restart 重启后，可以用以下命令验证飞书插件状态： - 在飞书对话中发送 /feishu start：确认插件是否安装成功 - 在飞书对话中发送 /feishu doctor：检查配置是否正常（会检查凭证完整性、API 连通性、权限状态等） 然后在不同的飞书群里 @对应的机器人，验证它们是否按预期回复、是否体现了各自 SOUL.md 中定义的性格。 五、进阶：隔离与共享的艺术 配好了多 Agent，接下来的问题是：哪些东西各 Agent 自己管，哪些东西大家一起用？搞清楚这个边界，才能真正发挥多 Agent 的威力。 5.1 每个 Agent 的"私人领地" 在 OpenClaw 中，每个 Agent 都有一个独立的工作区文件夹，位于 /.openclaw/agents//。这个文件夹就是它的"私人领地"，里面包含几个关键文件： 文件 作用 是否隔离 SOUL.md人格定义——"我是谁" 每个 Agent 独立 USER.md对用户的了解——"你是谁" 每个 Agent 独立 TOOLS.md工具使用偏好——"我怎么干活" 每个 Agent 独立 MEMORY.md跨会话记忆——"我记住了什么" 每个 Agent 独立 AGENTS.md行为规范——"我的操作守则" 每个 Agent 独立 sessions/会话历史——"我和谁聊了什么" 每个 Agent 独立 这里的"隔离"意味着什么？developer Agent 记住的技术讨论，writer Agent 完全看不到。你和写作助手聊的选题灵感，不会莫名其妙出现在开发助手的回复里。每个 Agent 的"大脑"是物理分开的——不是权限控制，而是文件层面的完全隔离。 打个比方：这就像公司里每个员工有自己的工位、自己的笔记本、自己的文件柜。即使在同一间办公室，张三翻不到李四的抽屉。 5.2 记忆：默认不共享，需要共享得主动设计 默认行为：完全隔离。 每个 Agent 的记忆文件（Markdown 格式的 MEMORY.md 和会话日志）都存在各自的文件夹里，互不干扰。这是 OpenClaw 的安全默认——防止信息意外泄露。 什么时候需要共享记忆？ 比如你希望所有 Agent 都知道"公司的产品叫 XX，定位是 YY，核心客群是 ZZ"这类基础信息。如果每个 Agent 都要单独教一遍，效率太低。 怎么实现共享？ OpenClaw 本身不提供自动的记忆同步机制（这是刻意的设计选择），但你可以通过以下方式实现： 共享知识库文件：在/.openclaw/shared/ 下放一个公共的 Markdown 文件（比如 company-context.md），然后在每个 Agent 的 SOUL.md 或 TOOLS.md 中引用它。这样所有 Agent 都能读到同样的基础知识，但各自的会话记忆仍然隔离。 共同的 AGENTS.md 模板：如果你希望所有 Agent 遵循相同的行为规范（比如"不要用英文回复中文问题""回复不超过 500 字"），可以让它们共享同一份 AGENTS.md，同时各自保留独立的 SOUL.md 来定义个性。一句话总结：记忆默认各管各的，共享知识靠主动设计，别指望自动同步。 5.3 技能（Skills）：分"全局"和"私有"两层 OpenClaw 的 Skills 是 Agent 能调用的能力模块（比如搜索、生成图片、操作文件等）。它们的共享逻辑是这样的： 全局技能（放在 /.openclaw/skills/）：所有 Agent 都能用。比如你装了一个"天气查询"技能，所有 Agent 不管是开发助手还是写作助手，都可以调用它。 私有技能（放在各 Agent 工作区的 skills/ 子目录下）：只有该 Agent 能用。比如你给 developer Agent 装了一个"代码审查"技能，writer Agent 是看不到也用不了的。 技能的允许/禁止清单：如果全局技能太多，你可以通过配置限制某个 Agent 只能用其中几个。在 openclaw.json 中，你可以为每个 Agent 配置 skills.allow（白名单）或 skills.deny（黑名单）： { "agents": { "registered": { "developer": { "skills": { "allow": ["github", "shell", "code-review"] } }, "writer": { "skills": { "deny": ["shell", "exec"] } } } }} 这段配置的意思是：developer 只能使用 github、shell、code-review 这三个技能（即使全局装了更多）；writer 可以用大部分技能，但明确禁止使用 shell 和 exec（防止写作助手去执行系统命令）。 5.4 工具（Tools）：同样分层控制 工具是比技能更底层的能力，包括文件读写（file）、命令行执行（shell）、浏览器操作（browser）等。控制逻辑和技能类似： 全局默认：在 agents.defaults 中配置所有 Agent 共用的基础工具集。 { "agents": { "defaults": { "tools": ["file", "shell", "browser"] } }} 单个 Agent 覆盖：某个 Agent 可以覆盖默认配置，收窄或扩大自己的工具权限。 { "agents": { "registered": { "writer": { "tools": ["file", "browser"] } } }} 这样 writer Agent 就没有 shell 权限——它能读写文件、能上网查资料，但不能执行系统命令。这对于安全敏感的场景非常重要。 5.5 模型配置：各用各的，丰俭由人 每个 Agent 可以使用不同的大模型，这也是隔离的一部分。在 agents.defaults 中设置全局默认模型，在各 Agent 的配置中覆盖： { "agents": { "defaults": { "model": "claude-sonnet-4-6" }, "registered": { "writer": { "model": "claude-opus-4-6" }, "translator": { "model": "gpt-4o-mini" } } }} 写作用最强的模型保证质量，翻译用便宜的模型控制成本，其余 Agent 用默认的中档模型。模型配置是完全独立的，改一个不影响其他。 六、常见踩坑与排查 6.1 默认机器人的凭证位置 最常见的错误：把默认机器人的 appId 和 appSecret 放在 accounts.default 下面。飞书插件只从 channels.feishu 顶层读取默认账号的凭证。放错了会导致主机器人报"not configured"。 6.2 改完配置一定要重启 编辑 openclaw.json 后，不重启 Gateway，新配置不会生效。记住：改配置 → 保存 → openclaw gateway restart。 6.3 消息路由不生效 如果消息没有按预期路由到对应的 Agent，检查以下几点：Binding 中的 channel 是否写的是 "feishu"（注意大小写），peer.id 是否是正确的 chatid 或 openid，accountId 是否与 accounts 中的 key 对应。 6.4 飞书权限不足 如果机器人无法收发消息，先在飞书对话中发送 /feishu doctor 进行一键诊断。它会检查工具配置、环境信息、凭证完整性、API 连通性、应用身份权限和用户身份权限等。如果提示权限问题，去飞书开放平台 → 应用设置 → 权限管理，确保消息收发相关权限已审批通过。 6.5 插件安装报错 如果执行 openclaw plugins install @larksuite/openclaw-lark 时报 npm install failed，可以尝试在命令前加 sudo 重新执行。升级插件统一使用 npx -y @larksuite/openclaw-lark update。 6.6 官方插件与社区插件冲突 如果你之前用过社区版飞书插件，安装官方插件后可能会出现冲突。建议二选一，避免两个插件同时运行。官方插件由飞书团队维护，更新更频繁、功能更完整。 七、写在最后 多 Agent 的价值不在于技术复杂度，而在于它让你像管理一个团队一样管理 AI。每个 Agent 有清晰的职责边界、独立的知识储备和合适的工具权限。当你的 AI 使用场景从"偶尔问一句"变成"日常深度协作"，多 Agent 就不再是锦上添花，而是刚需。 从一个 main Agent 开始，感受到瓶颈时再拆分——这是最务实的路径。别一上来就配十个 Agent，从两三个开始，逐步找到最适合你工作流的 AI 团队阵型。 参考资料：OpenClaw 飞书官方插件使用指南（公开版）、OpenClaw 官方文档、OpenClaw GitHub

从王阳明看如何克服焦虑

《列子·天瑞》里有个著名的“杞人忧天”的故事： 古时杞国有个老哥，天天担心天会塌、地会陷，结果吓得吃不下、睡不着。旁人看不下去，纷纷上来安慰他： “哥，天是气体组成的，你天天都在天里活动，不可能塌啊。” “地是厚实的土壤，撑得住的，不会陷。” 众人一通劝导，杞人这才放心了，不再自寻烦恼。 你可能会觉得，这人也太闲了吧？现代人哪还担心天会塌？ 但说实话，我发现我身边很多人，虽然不担心天塌地陷，却一样陷入“杞人忧项目”的困局 —— 他们焦虑的，不是毫无根据的未来，而是眼前 “这个项目做不成怎么办” “这个事要是黄了我该怎么办” “如果这不是对的路，我是不是在浪费时间”。 “焦虑”的真实版本：不是不知道，而是不敢动 前段时间我和我们团队的产品小伙伴一起去深圳出差，路上闲聊，他说他最近非常焦虑。 焦虑什么呢？ 我们正在推进一个很重要、也很难的项目。他知道这个方向对、公司支持力度也不小，但他还是焦虑。怕推进失败、怕耗时长、怕最终无果。最怕的是，时间有限、成果未知。 这种焦虑我太懂了——不是没方向，也不是没思考，而是知道太多，却迟迟迈不出第一步。 就像一个人站在路口，对着地图反复研究，却迟迟不走，反而越来越焦虑： “走这条会不会走错？” “万一错了回不来怎么办？” “要不再等等看？” 他不是不懂路，而是不敢走路。 知太多，反而行动瘫痪？ 焦虑这个东西，其实本质上是“知行分离”。 你知道问题所在，知道大致方向，知道该怎么做。 但你没开始做，或者迟迟无法推进。于是大脑开始“自我过载”：预设最坏情况、内耗、否定。 你以为自己在思考，其实是在绕着问题兜圈子， 在“啊我好焦虑”和“算了不想了”之间反复横跳。 拯救焦虑的，不是“安慰”，而是“行动” 很多人治焦虑，靠的办法只有两个：逃避 or 硬上。 我以前也总是逃避派 —— 遇到难搞的项目，第一反应是“要不我辞职吧？” 但逃避的代价是啥？ 你没解决问题，也没建立能力。你只是暂时摆脱当下的不适，但带着问题跑到了下一个战场，焦虑卷土重来，甚至加倍。 真正让我开始转变的，是一次和一个优秀同事 cc 搞 B 端产品的情感关怀项目。 这个项目在当时没人做过，根本没模板、没参考、没经验。 我俩天天下班后去会议室脑暴，一开始一无所知，就只能翻别人的产品、看他们的设计、拼命凑 idea。 刚开始也焦虑啊，怕搞砸、怕方向错、怕用户不买账。 但我们硬着头皮推，想到什么就验证什么。一天一天推进，小想法变大主意，大主意变成设计方案，最后上线之后用户反馈远超预期的好。 如果我们当初站在那犹豫、害怕、焦虑、再等等看——它就永远不会发生。 知行合一，不是完美出发，而是先走一步 王阳明说过一个很妙的比喻： “譬如你走路，从前常常走的一条路，好久不走了，今天你去走，发现岔路口多了，你该怎么办？——要问，不要怕。不要以为曾经走过就掌握了全图，也不要因为不确定就原地发呆。最好的方法，是即走即问，即问即走。” 很多人困在原地，不是因为不知道方向，而是不允许自己走错路。 但成长就是一边走，一边试，一边修正。 走错并不可怕，停下才可怕。 知行合一，不是知道很多，而是边知道边走，边走边明白。 最后 杞人忧天，忧的是未知的“塌”； 我们焦虑，焦的是已知的“难”。 可“难”并不可怕，怕的是只知道它“难”，却始终不肯开始。 别等不焦虑才行动， 是行动才能消解焦虑。 走起来，问题自然会慢慢变小， 路径也会在脚下浮现。 如果你喜欢这篇文章，欢迎点个“在看”或转发给也在焦虑中的朋友👇 行动，是最大的心理抚慰。