我入坑 OpenClaw 的时间不算早但踩的坑绝对不少。这东西的核心价值一句话概括把各种大模型、IM 渠道和 Skills 能力统一到一个 Agent 调度层里让你不用每次都在不同终端之间切来切去。真正用起来之后我最大的感受是难点从来不是安装而是怎么把它配置成能稳定处理你日常工作的形态。尤其是当你同时接了飞书、微信又想让不同模型分别承担不同任务还想着用 Skills 把重复劳动固化下来的时候配置、排错、优化就变成了一场持久战。这篇东西不打算再复述一遍安装向导我默认你已经把 OpenClaw 跑起来了准备进入“用好它”的阶段。我把自己实际用下来的 12 个技巧、踩过的几个典型坑、以及一份按场景整理的必装 Skills 清单全部列出来。不是官方文档式的罗列而是我在真实工作流里验证过、删删改改之后留下的东西。1. 先搞清楚 OpenClaw 的定位它不是模型是 Agent 调度中枢1.1 为什么我最终选了 OpenClaw很多人第一次接触 OpenClaw 时会有个误会以为它跟 ChatGPT、Claude 一样是个聊天窗口。实际上它更像一个“调度中枢”负责接收来自不同渠道的消息把消息交给不同的大模型去处理再调用你准备好的 Skills 来执行具体任务最后把结果通过原渠道返回给你。换句话说模型负责“想”OpenClaw 负责“听、说、动手”。这个定位决定了它真正的优势场景你不是只想在网页里问几个问题而是想让 Agent 出现在飞书群里、微信私聊里甚至定时帮你跑一个报告、拉一次数据、整理一份文档。它把“入口”和“大脑”解耦了。入口可以随时切换大脑也可以随时切换这种灵活性是单一聊天工具给不了的。1.2 OpenClaw 和 WorkBuddy 这类工具怎么选社区里经常有人问 OpenClaw 和 WorkBuddy 哪个好。按我的实际体验这俩不是完全同层的东西。WorkBuddy 更偏向开箱即用的“对话式工作台”界面友好、配置简单适合个人轻度使用而 OpenClaw 更像个可编程的 Agent 骨架配置项多、扩展点也多适合你要把它嵌进自己的 IM、CI、定时任务里长期跑的场景。如果你只是偶尔让 Agent 帮你总结一篇文章WorkBuddy 完全够用。但如果你像我一样需要同时在飞书、微信、终端三个入口操作同一个 Agent还要自己维护一套 SkillsOpenClaw 的灵活度会高很多。我的建议是不要因为“哪个更火”去选要想清楚你是在找聊天工具还是在找 Agent 基础设施。1.3 典型部署架构WSL2 上的本地常驻服务我目前的部署形态是这样的OpenClaw 作为常驻服务跑在 WSL2 环境里系统为 Ubuntu 发行版。它通过 channel 连接飞书和微信模型侧配置了千问和魔塔ModelScope上的开源模型作为备用通道核心开发场景使用兼容 OpenAI 接口的模型。Skills 统一放在专用目录里用 git 做版本管理。这个架构的好处是所有东西都在本地数据不出自己机器调试起来也直观。坏处是 WSL2 环境偶尔会闹脾气比如下面要说的环境校验失败、会话文件锁冲突都是真实高频出现的问题。2. 部署和运行环境里最容易翻车的两个点2.1 WSL2 环境安全校验失败的排查链路报错信息是 “could not safely verify the wsl2 environment”我一开始以为是自己系统缺了什么依赖后来才发现这大概率是 OpenClaw 在启动时对 WSL2 做了环境检测检测不通过就直接拒绝启动。这个问题常见原因有三个按出现频率排序第一WSL 内核版本太旧。Windows 上的 WSL2 内核是独立更新的版本过旧会导致部分系统调用缺失检测脚本跑不完就会报这个错。解决办法是先看wsl --version的输出再执行wsl --update升级内核。我建议把 Windows Update 里“接收其他 Microsoft 产品的更新”这个选项也打开WSL 内核才能跟着系统更新走。第二Systemd 没有启用。OpenClaw 常驻运行依赖 systemd 管理进程如果 WSL 发行版里没开 systemd服务拉起时机不对也会检测失败。检查方式是看/etc/wsl.conf里有没有[boot] systemdtrue这一段。没有的话加上然后在 Windows 侧执行wsl --shutdown重启发行版。很多“装好了但起不来”的问题其实都是这一步没做。第三发行版本身太干净。有些精简 Linux 镜像连curl、ca-certificates都没装完整检测脚本调用系统命令失败后会误判成环境不安全。我的处理经验是先apt update apt upgrade再装build-essential git curl ca-certificates把这几个基础包补齐再重新跑 OpenClaw大概率就过了。2.2 session file locked多进程抢占同一会话“agent failed before reply: session file locked (timeout 60000ms)” 这个报错我前前后后折腾了一整天才找到规律。它本质上就是有另一个进程正在持有同一个 session 文件的操作权而你新发起的请求一直在等锁释放等到 60 秒超时就报错了。触发场景非常典型飞书群里有人发消息Webhook 触发了一个 Agent 任务同时你又在终端里对同一个 session 发起请求又或者定时任务和手动触发撞在了一起。OpenClaw 默认以会话为单位做文件和状态管理一个 session 同一时间只允许一个进程写操作这就是锁冲突的直接来源。我的解决办法分三步。第一步给不同渠道分配不同的 session 前缀比如feishu-work、wechat-daily、terminal-main从源头降低撞车概率。第二步确认没有残留进程用ps aux | grep openclaw查一遍有异常进程就清掉。第三步直接把 session 存储目录下残留的.lock文件删除目录一般在~/.openclaw/sessions或你自己配置的路径下。删锁文件前确认没有正在运行的会话否则会丢上下文。2.3 环境变量与配置文件的加载顺序OpenClaw 的配置文件和环境变量加载顺序是个很容易被忽略的细节。很多人的问题是在终端里export了变量能用但一旦通过 systemd 或开机脚本启动就失效。这是因为 OpenClaw 默认读取.env文件而终端里 export 的变量不会写进.env。我的做法是所有密钥和 endpoint 全部集中到.env配置文件只写路径引用不写明文密钥。然后通过一个启动脚本统一加载先set -a加载.env再启动 OpenClaw确保 systemd、终端、定时任务三处启动方式的行为一致。这个改动看起来不起眼但能省掉后面大量“为什么重启后就不认千问配置”的排查时间。3. Channel 接入实战飞书、微信、千问和魔塔3.1 选 channel 的判断标准官方支持的 channel 越来越多但“支持”和“好用”之间有不小距离。我选 channel 的标准只有三条第一条双向通信是否完整。有些 IM 的机器人只能主动发消息不能接收用户回复有些能收能发但无法识别群里的 消息。这决定了你能不能做真正的对话式交互。第二条消息长度限制是否适合你的输出。飞书、微信对单条消息长度都有硬限制Agent 一次输出 3000 字很容易被截断后面我会单独说。第三条是否支持审批流或回调。如果你想让 Agent 执行高风险操作比如发邮件、改文件、调接口最好选带审批回调机制的 channel或者自己在 Skills 里实现确认环节。3.2 飞书输出截断的根因与缓解“OpenClaw 在飞书输出容易被截断”这个问题不止一个人问过。根因分两层第一层是飞书消息接口本身有长度限制超出部分会被服务端直接切掉第二层是 OpenClaw 把模型输出一次性发给了飞书没有做分片。解决思路不是去调飞书接口的隐藏参数而是改变 Agent 的输出方式。我在 Skills 里给一个“飞书输出格式化”的通用指令如果内容超过 800 字必须先拆成多个小节每个小节单独发送同时把最重要的结论放在第一条消息里。这样做其实是把“输出策略”从模型手里拿到 skill 指令里稳定性和可控性立刻提升。另外还有一种做法是让复杂任务的最终产物写成文件或文档飞书只发送摘要和链接。这样既绕过了长度限制又保留了完整信息。我在周报场景里就是这样配的Agent 生成完整周报到本地文件飞书里只推一个结构化摘要。3.3 微信“能发不能收”的排查清单这个是社区里出现频率极高的问题OpenClaw 能主动往微信发消息但用户用微信回复时 Agent 根本没反应。我整理了自己的排查顺序先看日志里有没有收到微信回调。如果压根没回调问题出在回调地址配置或微信侧的接收消息设置常见于没有在微信公众平台/企业微信后台正确配置接收消息 URL。如果有回调但 OpenClaw 没有触发 agent那就是消息类型过滤的问题。很多 channel 默认只处理文本消息图片、语音、小程序卡片全被丢弃。你还要确认自己的配置是否限制了只响应某些群或某些关键词。再有就是登录态问题我遇到过几次“能发不能收”是因为微信侧的登录 session 过期了。主动发送时 OpenClaw 会重新拉起登录态但被动接收时校验更严格过期就静默丢弃。这个没有任何日志提示非常坑我现在的做法是每天第一次使用前检查一下 channel 状态把登录态检查做成一个小 skill 定时跑。3.4 用千问和魔塔模型时的注意点配置千问时关键是确认好 base_url 和模型名。OpenClaw 通过“OpenAI 兼容接口”的方式去连千问所以你在配置里写的是兼容接口的地址、密钥和模型 ID而不是 SDK 专用参数。我踩过的坑是千问平台上同一个模型有多个版本 ID写错一个字符就报 model not found而且报错信息还很隐蔽。对接魔塔ModelScope的核心也是找兼容接口。魔塔上的很多开源模型不会直接提供 OpenAI 格式接口需要自己起一个推理服务做协议转换。这一步不是 OpenClaw 的职责而是部署在外部。我的建议是先用 curl 单独测试这个兼容接口是否正常再填进 OpenClaw 配置不要把推理服务的启动问题混进 agent 的排错里。模型 fallback 也是个很实用的配置把主模型设为千问备用模型设为魔塔上的开源模型主模型没响应或超时的时候自动切换。这个机制我在长任务场景里救过好几次急。4. 提升日常效率的 12 个 OpenClaw 使用技巧这一节是整篇里最“干”的部分全部来自我自己的实际配置不一定每条都适合你但每一条都值得试试。技巧一用 profile 隔离工作和个人场景。OpenClaw 支持多 profile 配置相当于一个程序多套“人格”。我的做法是建了work和personal两个 profilework 里只接飞书、只允许工作日 9 点到 20 点响应模型用千问personal 里只接微信模型用魔塔上的开源模型响应时间和语气都不太一样。两套配置互不干扰切换时一条命令完成。技巧二高频重复提示词一定要固化成 Skill而不是靠聊天记录。我一开始图省事把常用 prompt 放在系统提示词里结果每改一次都得重启会话还经常和其他指令冲突。后来全部改成 SKILL.md 文件按场景命名用的时候让 Agent 按描述自动加载。效果立竿见影特别是周报、日报这种格式化任务。技巧三给 IM channel 配触发白名单。飞书群里人多口杂如果谁 Agent 都会触发任务很容易被刷屏或误触发。我在配置里限制了只有指定用户 ID 或指定关键词才能激活 Agent。这样既不影响别人看聊天记录又避免 Agent 被无关消息反复唤醒还省了 token 消耗。技巧四用 session 超时配置缓解锁冲突。在第 2.2 节我讲了锁冲突的排查其实还可以在配置里调短会话空闲超时让不活跃的 session 尽快释放锁。默认超时如果太长来一个不完整的对话就会占住会话锁不放后面消息全堵住。我把空闲超时从默认值调到了 15 分钟社区日常使用的体验马上顺了很多。技巧五定时任务不要只用 cron要指定 channel。我一开始写定时任务只写了 cron 表达式和要执行的命令结果任务确实跑了但结果不知道发到哪里。后来统一在定时任务里显式指定输出 channel 和用户 ID每天早上 9 点的任务摘要准时出现在飞书里。这个经验对写自动化流程特别重要Agent 不仅要“会做”还要“知道把结果给谁”。技巧六长文本任务采用“文件 摘要”双输出模式。飞书截断问题除了靠分片更稳妥的方式是让 Agent 把完整内容写到本地文件或对象存储消息里只发摘要。我在所有可能超过 1000 字的任务里都强制了这个规则效果稳定。这条对微信、飞书都适用。技巧七配置模型 fallback 链。把可用模型按优先级排好主模型是千问超时或报错时自动切到魔塔模型再不行走本地小模型兜底。这个机制很适合国内网络环境下的日常使用至少“OpenClaw 没反应”的情况少了七八成。技巧八调试 Agent 行为时先看工具调用日志。很多时候你觉得 Agent 答非所问其实不是模型笨而是它调错了工具或根本没调工具。OpenClaw 的日志会记录每次工具调用参数和结果调错问题时先翻日志再决定是改模型还是改 skill。技巧九用 dry-run 模式验证危险操作。我给高风险类的 skill 单独开了审计模式Agent 执行删除、发送外部消息、调外部接口前先在日志里输出将要执行的命令和参数人工确认后才真正执行。这一步避免了不止一次“Agent 把不该发的消息发出去”的尴尬。技巧十定期清理 session 和日志目录。OpenClaw 跑久了session 和日志膨胀非常快。我写了一个清理类 skill每周自动扫描会话存储和日志目录删除超过 30 天的历史会话和超过 100MB 的日志文件。既防止磁盘写满也让启动和加载变快。技巧十一把输出格式约束做成独立 Skill。不同模型对格式的理解不一样有的爱用表格有的爱用列表。我把“输出格式约定”做成一个公共 skill里面定义了什么场景用表格、什么场景用列表、代码块怎么标注、文件名怎么命名。任何模型加载后都能保持一致的输出风格这个对团队协作尤其重要。技巧十二高危操作前加人工审批钩子。OpenClaw 可以配置审批回调Agent 执行到关键步骤时暂停等待指定用户在 IM 里确认。我把它用在发邮件、改配置、调支付接口这几个场景。过程虽然多一步但换来的安全性是值得的。5. Skills 的核心机制与安装路径5.1 SKILL.md 格式frontmatter 正文指令Skills 是 OpenClaw 生态里最重要的一层抽象。一个 Skill 本质上就是一个文件夹里面有一个SKILL.md文件作为主入口格式上分两部分开头是 YAML frontmatter包含name和description后面是正文用自然语言描述这个 Skill 的执行步骤、约束条件和输出格式。description的写法非常关键。Agent 会通过它来决定何时加载这个 Skill写得越具体越好。比如“用于生成代码 Review 清单输入 git diff输出按严重程度分级的评审意见”就比“用于代码评审”好得多。我在实践中的体会是description 要写清“输入是什么、输出是什么、在什么场景下用”而不是写一堆宣传语。正文部分不需要严格的编程语法但建议用编号步骤写清楚流程。模型看到编号步骤后的执行稳定性明显高于自由文本。如果 Skill 需要调用外部脚本可以在同目录下放scripts/文件夹并在正文里写明调用方式。5.2 Skills 目录位置与搜索顺序OpenClaw 在启动时会按约定顺序扫描多个 Skills 目录。我的配置里主要有两个一个是随仓库维护的团队共享目录一个是用户个人目录。团队目录用 git 管理改东西走提交个人目录放一些临时用的小 skill不轻易同步到团队。如果你发现某个 Skill 总是不生效第一件事就是确认它放在了正确的目录层级下。正确结构是skills/skill-name/SKILL.md如果少了一层目录或把 SKILL.md 直接扔在 skills 根目录下Agent 可能扫描不到。我见过太多人卡在这一步页面写着“已装 Skills”实际 Agent 根本没加载到。5.3 手动安装 GitHub 上的 Skills 的正确姿势手动安装 GitHub 上的 Skills 时不要直接点击下载 SKILL.md 文件后乱放。正确做法是先看仓库的 README确认它的目录结构是否遵循skills/skill-name/SKILL.md的约定然后把整个 skill 文件夹 clone 或复制到本地 Skills 目录。这里有个容易踩的坑很多仓库里的 skill 是为 Claude Code 或 Codex 设计的配置文件里可能带了它们特有的字段。OpenClaw 读取这类 skill 时通常只识别通用字段和正文部分特殊字段会被忽略。所以安装后一定要先用简单任务测一下确认 Skill 真的被加载而不是装了个寂寞。5.4 CodeBuddy 和 Claude Code 公用 Skills 目录的做法有社区用户问 CodeBuddy 和 Claude Code 怎么公用 Skills 目录这也适用于 OpenClaw。思路很简单设置一个共享环境变量让多个工具指向同一个 Skills 根目录然后把 SKILL.md 的格式统一成大家都兼容的版本。实践中有个细节不同工具对 frontmatter 字段的容忍度不同。有些工具遇到未知字段会警告但不影响使用有些工具则会直接忽略整个 skill。所以我维护共享目录时会刻意保持 frontmatter 极简只用name和description复杂配置全部放到正文里。这样三个工具读同一个文件时表现最稳定。5.5 清理类 SkillsTibo 的方法为什么好用Tibo 关于清理 Skills 的方法在社区传得很广核心思想只有一个不要手工一个个判断哪个 skill 没用而是让 Agent 自己做一个“审计清理” skill。这个 skill 会扫描所有已安装 skill统计每个 skill 的加载次数、最近使用时间、描述与功能的匹配度然后生成一个“建议删除/归档”清单。我用过之后才发现自己装了快 30 个 skill真正高频使用的只有 8 个左右。剩下的全是“看着有用实际从没触发”的类型。清理完以后模型做选择时的准确率明显提升因为它不再需要从一堆劣质 skill 里找正确答案。这也说明 Skills 不是装得越多越好而是越精准越好。6. 按场景整理的必装 Skills 清单6.1 通用效率类Superpowers 与上下文管理通用效率类里我最推荐 Superpowers它是一个包含多个子 skill 的合集核心是给 Agent 提供一套结构化的“思考-执行-纠错”工作流。装上它之后Agent 面对复杂任务时不再直接给结论而是先拆解目标、再分步骤执行、最后自查验证输出质量稳定很多。另外建议装一个上下文管理类 skill。OpenClaw 的会话有上下文窗口限制长任务很容易把前面的信息“挤”出去。上下文管理 skill 会在任务开始前检查会话长度主动压缩历史、提炼关键决策保证模型始终握着最重要的信息。这类 skill 在没有很强大模型的情况下尤其救命。6.2 代码开发必备Codex 系、前端系和数学建模代码场景里Codex 用户社区沉淀了不少好用的 Skills。首选是代码库问答类 skill它知道你的项目目录结构、代码风格和常用依赖回答问题时能直接引用具体文件而不是空泛地给思路。其次是 Git 提交信息规范类 skill它能根据 diff 生成符合 Conventional Commits 的提交信息省掉我每次手写的时间。前端开发类我装了一个专门约束组件生成的 skill它会自动注入项目当前使用的技术栈比如 React Tailwind、目录命名规范、样式隔离方式甚至要求“新组件必须带 accessibility 属性”。装完之后生成的代码几乎不用大改返工率低了很多。数学建模类 skill 在竞赛圈非常火核心是把“问题理解-假设定义-模型选择-求解-验证”的流程固化下来。对于华为杯这类建模比赛好的建模 skill 还会附带常用模型的适用条件和代码模板让你不用每次从头推导。我的建议是选 skill 时重点看它有没有内置验证环节而不是只教你怎么列公式。6.3 论文写作与排版LaTeX、图片生成和结构化大纲论文场景里LaTeX 排版 skill 是我用过回报率最高的一个。它内置了公式环境、表格模板、参考文献格式规范还能把一段口语描述转成规范的 LaTeX 源码。用之前我每篇论文都要花半天调格式用之后基本一次成型而且完全符合目标期刊或会议的常用模板。图片生成类 skill 也值得装特别是现在 Agent 可以调用文生图能力。这类 skill 会把“画一只猫”扩展成包含镜头、风格、光线、构图的完整提示词并对输出图片做格式检查。实际效果是生成图可用率从三成提升到七成以上省下的重试时间非常可观。论文大纲类 skill 则负责在动笔前生成结构化 outline先定义研究问题再拆出相关工作、方法、实验、结论各章每章都要有关键论点和预期证据。这样写出来的论文逻辑明显更紧凑不会被模型带上“凑字数”的歪路。6.4 运维与日常清理类、会话管理类和常用源推荐运维侧的必装项就是前面提到的清理类和会话管理类 skill。清理类负责定期清扫日志、session、临时文件会话管理类负责查看当前所有会话状态、锁定异常会话、手动释放锁文件。这两者配合好OpenClaw 的稳定性会上一个台阶。最后是 Skills 源。社区里最值得关注的仓库是 awesome-claude-skills 这类汇总列表它会按场景把主流 skill 分好类标注维护状态和兼容性。还有一些专门提供 skill 下载的源网站上面能找到实验性很强的新 skill。我的挑选标准是看最近更新时间、看 star 数、看 README 里有没有使用示例。满足这三条的安装缺一条的慎重一条都不满足的不要装。7. Skills 的测评、自研与知识库积累7.1 怎么测评一个 Skill 好不好用我测评 skill 的方法很简单准备一组固定的测试用例每个用例包含输入、期望行为和期望输出格式然后分别在“有 skill”和“无 skill”两种状态下运行对比成功率、输出质量和 token 消耗。只测一次不算至少跑三遍因为模型输出有随机性。另外我会重点测 skill 的“触发准确率”。一个 skill 装得再好Agent 在该用的时候不用那就是白装。测试方法是给 Agent 一个任务看它是否能从描述中匹配到正确 skill。如果连续几次都没有自动触发我会修改 description 让它更容易被匹配。描述里关键词越贴近用户的实际说法触发率越高。测评结果我会记成一个简单的表格包含 skill 名称、测试场景、成功率、平均耗时、备注五项。每两周回顾一次清理掉那些连续两周都没被触发或成功率长期低于 80% 的 skill。这个习惯帮我保持了 Skills 目录的“瘦身”也让模型决策负担一直维持在低位。7.2 从零写一个 AI Skill 的样例写 skill 没有想象中难。我以一个“会议纪要格式化” skill 为例它要做的事情是把飞书里的对话记录整理成结构化会议纪要。核心文件长这样--- name: meeting-minutes-formatter description: 用于把聊天记录或会议转录文本整理成结构化会议纪要。输入是一段非结构化的对话或转录文本输出是包含会议主题、参会人、决策项、待办事项和负责人与截止时间的 markdown 文档。适合产品评审、项目同步、复盘会等场景。 --- # 会议纪要格式化 ## 输入 - 会议原始文本聊天记录、语音转写内容 ## 执行步骤 1. 识别会议主题如果输入没有显式主题依据讨论内容推断一个简短的会议标题。 2. 提取参会人和角色人名出现时按原文保留不要猜测或补充职位。 3. 识别决策项出现“我们决定”“结论是”“就按这个来”等表达时标为决策项。 4. 提取待办事项出现“下次”“需要做”“负责人”“截止”等表达时提取为待办事项并给出负责人与截止时间原文未明确时记为“待确认”。 5. 按以下 markdown 结构输出 - 会议主题 - 会议时间 - 参会人 - 决策项列表 - 待办事项表事项、负责人、截止时间、状态 ## 注意事项 - 不添加原文中不存在的信息。 - 如果输入内容过短或信息量不足直接输出空模板并提示“原始记录信息不足”。 - 待办事项状态统一填写“未开始”不要自行推断进度。装进skills/meeting-minutes-formatter/SKILL.md之后我只需要在对话里说“把这段聊天记录整理成会议纪要”Agent 就会自动匹配到这个 skill 并按步骤执行。整个过程不需要写任何代码语法门槛很低你完全可以照这个模板做自己的场景化 skill。7.3 Skills 市场现状与源网站去哪儿找现在的 Skills 生态非常像早期手机应用市场爆发前夜仓库到处都是但质量和维护水平参差不齐。主流渠道有这么几类GitHub 上的 awesome 系列聚合仓库、个人博客里分享的 skill 集合、以及一些社区维护的 skill 索引网站。找好 skill 我有两个习惯一是优先找带“测试用例”或“示例输出”的仓库这类作者通常真的在实际场景里验证过而不是只写了漂亮的 README二是优先下载支持多工具的通用格式比如只依赖name和description字段的避免被某个具体产品绑架。这样以后即使你从 OpenClaw 迁到别的工具手上的 skill 资产也不会作废。7.4 Code AI 知识库怎么积累最后说说知识库积累。我见过太多人把知识库当成文件堆扔一堆 PDF 进去就觉得“AI 知道了”。实际效果是模型检索出一堆不相关片段回答质量反而下降。更好的做法是把团队知识拆成一个个“最小可执行单元”每个 unit 就是一个 skill包含背景、步骤、注意事项和反例。我现在的积累路径是每次解决完一个重复性问题就顺手把它写成 skill 放进共享仓库每周抽半小时做一次 review合并重复项、更新过时描述。这样知识库不是静态文档而是会持续进化的技能集合。配合 git 提交记录你能清晰看到团队能力沉淀的轨迹。我个人在实际操作中的体会是OpenClaw 这种工具的上限不取决于模型多强而取决于你有没有把“做事的方法”沉淀成 skill。装十个大而全的 skill不如把一个核心场景的 skill 打磨到极致。我清理完自己的 skills 目录从三十几个删到十几个之后Agent 才真正从“会聊天”变成“会干活”。这篇内容里提到的技巧和清单也是我现在仍然每天都在用的配置底稿希望能给你一个明确的起点。
