如果你也跟我一样一开始用 WorkBuddy 做图做到怀疑人生——明明提示词写了一大堆模型也够聪明产出的图总有种说不出的“塑料味”排版像 PPT 模板、配色刺眼、构图永远往正中间怼发给同事直接来一句“这是 AI 跑的吧”。说实话WorkBuddy 本身的能力没问题问题在于它没有一个“审美兜底层”。后来我把“审美”这件事拆成 4 个 Skill 装进去做图终于不是碰运气了。这篇文章就把这套方法完整拆开每个 Skill 解决什么、怎么安装、怎么在真实工作流里串起来以及我踩过的坑。适合正在用 WorkBuddy、CodeBuddy 这类 Agent 工具的朋友尤其是需要频繁出图、做架构图、写视觉方案但本身又不是设计师的开发者。1. 先说我为什么开始折腾 WorkBuddy 的 Skill1.1 WorkBuddy 到底是什么和普通工具差在哪WorkBuddy 是一个本地化部署的 Agent 型工作台你可以把它理解成“能自己拆任务、调工具、按步骤执行”的 AI 副驾驶。它跟 CodeBuddy 属于同一套生态很多人从 CodeBuddy 切过来就是看中 WorkBuddy 对自定义指令和 Skill 机制的友好度。Skill 这个概念最早在 Claude Code 那套工作流里火起来后来 Codex Skill、OpenClaw Skill 陆续跟进。WorkBuddy 的 Skill 机制跟它们思路一致把一套完整的“行为准则 操作规范 示例”打包成一个文件夹Agent 在干活时按需加载而不是靠每次对话里临场写一大段提示词。用一句话概括提示词是告诉 AI“这次怎么做”Skill 是告诉 AI“以后遇到这类事都按这套来”。做图这种事恰好是最需要“以后都按这套来”的——因为没有审美规范每次生成都是在盲盒里抽奖。1.2 用 WorkBuddy 做图丑的根因不是模型不行我一开始也以为是底层模型画图能力弱后来发现根本不是。WorkBuddy 出图丑根因有三个第一默认指令太“通用”。AI 并不知道你的场景是公众号封面、产品架构图还是技术方案配图于是它会选择最稳妥的排版——居中、大标题、纯色背景结果就是千篇一律的“AI 模板脸”。第二缺少前置审美判断。真正的好图不是一次生成出来的而是先有“什么算好看”的标准再按标准去执行。WorkBuddy 默认没有这个“判断层”它只负责“生成”不负责“鉴别”。第三反馈回路太慢。你被丑图气到才开始想怎么改提示词改完再跑一次效率极低。如果能让它在动手之前就先过一遍审美规则、动手之后自己检查一遍整个出图质量就上来了。所以问题的本质不是工具不够强而是缺少一套可复用的“审美操作系统”。把这套系统做成 Skill就是最合理的解法。2. 4 个 Skill 的选择逻辑与各自分工2.1 为什么是 4 个而不是 1 个“万能审美包”说实话我也想一个 Skill 搞定所有事。但试过之后发现审美这件事最少包含三个层次第一层是“知不知道什么是好看的”判断力第二层是“能不能把好看做出来”执行力第三层是“能不能避免 AI 味太重”人性化。再加上我日常工作里大量涉及架构图、流程图这类可视化内容于是又加了一个专门管图纸的 Skill。一个万能包的问题在于它所有规则混在一起Agent 加载时不知道该优先执行哪条最后往往是每条都浅尝辄止。拆成 4 个独立 Skill 之后每个都职责单一WorkBuddy 可以按任务类型精准加载。这个设计思路跟你写代码时拆分模块是一个道理。这 4 个 Skill 分别是Taste Skill审美鉴别的“美术总监”负责判断美丑、给修改意见。Impeccable Skill视觉规范落地的“执行标准”负责把美学原则变成可执行的参数。Humanizer Skill去 AI 味的“人味修复器”负责让图看起来像人做的。Archify Skill图纸可视化的“架构美化器”负责让架构图、流程图告别黑框白字。2.2 Taste Skill先解决“不知道丑在哪”Taste Skill 的作用是给 WorkBuddy 装上一个“审美判断前置层”。每次生成图片、网页截图、海报草稿之前它会先对输入的需求做一轮风格判断这个场景适合什么构图、什么调性、什么配色逻辑输出一份简短的“审美简报”。我实际使用时会让它输出三个东西风格定位比如“冷静专业向”还是“活泼社媒向”、视觉禁忌比如“避免大面积高饱和撞色”、参考方向比如“参考杂志封面式留白而不是 PPT 模板式排版”。这个 Skill 的核心价值在于“把隐性审美显性化”。很多非设计背景的人不是没有审美而是说不清“哪里不对”。Taste Skill 相当于帮你把那种模糊的感觉翻译成 AI 能听懂的语言。2.3 Impeccable Skill让“好看”变成可执行的参数光有判断还不够还得让 AI 知道“具体怎么做才叫好看”。Impeccable Skill 就是干这个的它把设计规范拆成了可量化的参数。举个最直接的例子它内置了一套基础排版规范标题字重必须高于正文一个梯度、段间距统一用 1.5 倍行高、页边距不得小于内容区的 8%、同一画面里最多使用 3 种字体。配色上它会按 60-30-10 法则控制主色、辅助色、强调色的比例而不是让 AI 随手抓几个颜色就往上怼。这套规范听起来有点死板但正是这种“死板”让 AI 的输出稳定下来。设计的基础从来不是纯自由发挥而是先有秩序、再谈突破。Impeccable Skill 做的事就是先把秩序建立起来。2.4 Humanizer Skill去掉一眼假的“AI 味”跑过几次图你就会发现AI 做得再“规范”也还是容易有一种难以言说的生硬感。典型症状包括标题永远居中、图片永远对称、注解文字永远工工整整排在下方。Humanizer Skill 专门解决这个问题。它的思路是注入“人类设计师的真实操作习惯”比如标题可以左对齐、刻意制造不对称构图、用色块代替细线做分割、在角落加一个小的装饰性文字。这些都是人类设计师下意识会做的事AI 默认不会。我自己的体会是加了这个 Skill 之后出图从“企业 VI 手册风格”变成了“一个有点审美的同事随手排的版”这个转变对日常沟通非常重要——因为前者一看就是 AI 跑的后者至少愿意多看你一眼。2.5 Archify Skill处理技术人最常画的丑图第四个 Skill 是我单独为架构图、流程图、拓扑图加的。技术场景里最尴尬的事就是业务方案讲得清清楚楚一画架构图就露怯。黑框白字、箭头交叉、该对齐的没对齐整个图的信息传达效率还不如直接说话。Archify Skill 的核心规则包括同一层级组件必须对齐同一边缘、所有节点统一使用 2px 边框、箭头弯曲弧度和方向必须一致、标签文字统一用等宽字体、按区域用浅色背景做分区而不是靠方块拼贴。它做得最好的一点是不只是生成漂亮的图而是把“这个图应该怎么分组、怎么表达层级关系”也一并处理了。所以最后出来的图不光是好看是真的能看懂。Skill 名称核心职责解决的问题典型应用场景Taste审美判断不知道丑在哪生成前出审美简报Impeccable规范落地知道好看但做不出来排版、配色、字体执行Humanizer去 AI 味图太生硬、模板感强社媒图、海报、封面Archify图纸美化架构图、流程图丑技术方案、汇报材料3. 安装与本地部署实操把 Skill 装进 WorkBuddy3.1 Skill 放哪里、目录怎么组织WorkBuddy 的 Skill 本质就是一个本地文件夹里面放着描述文件、规则文件和示例文件。以我目前用的版本为例个人级 Skill 放在~/.workbuddy/skills/下项目级的可以放到当前项目根目录的.workbuddy/skills/下。优先加载项目级找不到再回退到全局。每个 Skill 一个独立文件夹命名要一眼能看出用途比如taste-skill、impeccable-skill。文件夹内部结构我强烈建议保持统一这样后面维护和排查都方便~/.workbuddy/skills/ ├── taste-skill/ │ ├── SKILL.md │ └── rules/ ├── impeccable-skill/ │ ├── SKILL.md │ └── rules/ ├── humanizer-skill/ │ └── SKILL.md └── archify-skill/ └── SKILL.md这套结构不是 WorkBuddy 强制要求的是我自己实践下来比较好用的一种组织方式。目录清晰的好处是哪个 Skill 没生效打开文件夹一看就知道是描述文件写错了还是规则文件没放进对应目录。3.2 SKILL.md 文件到底怎么写SKILL.md 是每个 Skill 的核心入口文件WorkBuddy 通过这个文件来理解“这个 Skill 是干嘛的、什么时候该用”。它的格式其实不复杂最前面是一段 YAML frontmatter用---包起来里面定义元信息后面才是真正的指令正文。我以一个简化版的 Taste Skill 为例完整结构大概长这样--- name: taste-skill description: 在生成任何图片、海报或可视化内容前先输出审美判断和风格建议。 when_to_use: 处理图片生成、封面设计、海报排版、视觉方案评审等任务时必须优先加载。 --- # Taste Skill审美鉴别前置 ## 你的角色 你是一名拥有十年经验的美术总监善于用最简短的话指出设计方案的审美问题。 ## 执行步骤 1. 收到设计任务后先输出审美简报风格定位、视觉禁忌、参考方向。 2. 在 AI 动手生成之前将审美简报作为前置指令注入任务上下文。 3. 生成完成后对结果按 构图、配色、字体、层级 四个维度打分并给出改进建议。 ## 评分标准 - 构图主体位置是否合理留白是否得当。 - 配色色相是否统一对比度是否合适。 - 字体层级是否分明数量是否克制。 - 层级信息主次是否清晰视线引导是否自然。 ## 示例输出 ### 审美简报 - 风格定位冷静专业向适合技术博客封面 - 视觉禁忌避免大面积高饱和撞色避免阴影过重 - 参考方向大留白 细线分割 单强调色写完 SKILL.md 之后把它保存到对应 Skill 文件夹里然后在 WorkBuddy 里重新加载一下 Skill 列表正常就能识别到了。如果没生效先检查 YAML frontmatter 的格式——冒号后面必须有空格缩进必须一致这两个问题占了八成失败原因。3.3 规则文件和组织 Skill 的小技巧除了 SKILL.md我把一些更细的、适合机器读的规则拆到独立文件里。这样做的好处是SKILL.md 保持精简Agent 可以快速理解而真正的硬性规范放在 rules 目录下按需加载。拿 Impeccable Skill 举例它的 rules 目录下会有rules/ ├── typography.md # 字体与排版规则 ├── color.md # 配色规则 └── layout.md # 构图与栅格规则每个规则文件不用长重点是要“机器可执行”。什么叫机器可执行就是每一条规则都是明确的判断标准而不是抽象形容词。比如“颜色要高级”这种话 AI 是没法执行的但“主色不超过 2 个、辅助色不超过 2 个、对比度不低于 4.5:1”这种就是可执行的。还有一个小技巧在 SKILL.md 里加一个when_not_to_use字段明确告诉 Agent“哪些情况不要加载这个 Skill”。这一步很多人会忽略但它对减少上下文混乱非常有用。比如 Taste Skill 不需要在代码编写任务里生效提前写清楚能避免它总出来抢戏。4. 四个 Skill 在真实做图流程里怎么串起来4.1 一条完整流程从想法到成品单独装好了 Skill 只算第一步真正让效果发生质变的是把它们串进同一条工作流。我现在处理任何一张图基本都走四步先让 Taste 做审美判断再让 Impeccable 定执行规范接着用 Humanizer 做人性化调整最后如果是图表类内容再交给 Archify 收尾。以我最近做的一张“AI Agent 架构方案配图”为例。需求很简单给一篇技术博客配一张架构图加一张封面图风格要“简洁高级感”。第一步加载 Taste Skill它会先输出审美简报“该场景适合浅色背景、单强调色、大留白架构图部分建议分层清晰封面图部分建议标题左对齐。”这个简报不一定惊艳但至少方向是对的AI 不会再瞎跑。第二步加载 Impeccable Skill把审美简报转成具体参数背景色用 #F7F7F5 这样的暖灰而不是纯白强调色用低饱和度的蓝绿色标题字号 28px、正文 14px、注释 12px。到这个阶段出图已经不会难看到哪去了。第三步加载 Humanizer Skill做最后的“人味”处理。比如封面标题从居中改成左对齐在右下角加一行小字注释架构图的分组背景从纯色改成轻微圆角的浅色块。这些都是小改动但整体观感立刻不一样了。第四步如果图里带架构内容Archify Skill 会复查一遍节点是否对齐、箭头走向是否一致、标签字体是否统一然后输出一张可以直接贴进博客的图。4.2 每一步的实际指令长什么样在 WorkBuddy 里我不需要手动一个个切换 Skill只需要在任务描述里带上标记。比如任务给技术博客《AI Agent 架构实践》配一张封面图和一张架构图。 风格简洁、专业、有审美感。 请使用 [taste-skill] [impeccable-skill] [humanizer-skill] [archify-skill] 协同完成。WorkBuddy 会自动把这 4 个 Skill 按序加载。每一步的输出是下一步的输入整个流程像一条流水线。我实际跑下来的体感是以前做一张能看的图要来回改三四轮现在基本一次成型偶尔微调也是在审美简报范围内的局部优化。4.3 效果对比装上前后差多少装 Skill 之前WorkBuddy 默认生成的图最典型的问题是“什么都对但就是不好看”。字体字号规范、颜色也算协调但就是有一种“网页模板”的味道像是在告诉你“这是一张 AI 做的图”。装上 4 个 Skill 之后最明显的变化是画面有了“呼吸感”。所谓呼吸感说白了就是留白变多了、层次变清了、元素之间有了主次关系。封面图从最开始的“大标题圆形装饰底纹”变成了“左对齐标题大面积留白一个局部强调色块”虽然内容信息没变但气质完全不同。团队同事后来看到图的第一反应是“这图是你自己排的吧”而不是“这又是 AI 跑的吧”。对我来说这个区别就是全部意义。5. 常见问题与排查技巧实录5.1 Skill 不生效怎么办遇到过的最典型问题就是 Skill 明明放进目录了WorkBuddy 就是不加载。排查思路按顺序走先看文件名是不是叫SKILL.md注意大小写不能错再看他到底放在哪个目录了个人级和项目级的优先级不一样项目里已经有一个同名 Skill 的话全局的那个会被忽略。还有一个隐蔽问题YAML frontmatter 里如果有中文引号或者全角符号解析器可能直接报错但报错信息又不明显表现就是 Skill 没被识别。所以写完 SKILL.md 之后我习惯先用文本编辑器检查一遍引号和冒号是不是半角。5.2 多个 Skill 互相抢戏、上下文爆炸同时挂载 4 个 Skill最直接的副作用是上下文长度会涨。我之前试过把每个 Skill 的 SKILL.md 都写得特别长结果执行任务时 WorkBuddy 光读 Skill 描述就占了大半上下文真正干活的容量反而少了。解决办法有两个。一是严格控制每个 SKILL.md 的长度我自己的标准是控制在 200 行以内只保留核心指令。二是充分利用when_to_use和when_not_to_use让 Agent 只加载当前任务需要的 Skill而不是全部塞进去。5.3 和其他工具生态的兼容问题WorkBuddy 的 Skill 机制和 Claude Code、Codex 的 Skill 在思路上类似但格式并不完全互通。我试过直接把 Claude Code 的 Skill 文件夹拷到 WorkBuddy 里结果有的能识别、有的不行主要原因是 frontmatter 里的字段 WorkBuddy 不识别。如果你从网上下载了别人的 Skill 包先打开 SKILL.md 看看 frontmatter 里有哪些自定义字段。如果看到不认识的字段保留name和description其他字段可以先去掉再一步步加回来测试。下面这张表是我踩坑后整理的最常见的 6 个问题和对应解法基本覆盖了九成的情况。故障现象可能原因快速解决Skill 完全不出现文件名不是 SKILL.md 或目录层级不对改成 SKILL.md放在 skills 根目录下一级出现但从不加载when_to_use 描述太模糊写清楚具体触发场景避免“需要时”这种空话加载但行为错误frontmatter 有未知字段只保留 name/description/when_to_use 再测试上下文不够用Skill 内容过长精简到 200 行以内细节移到 rules/ 目录多个 Skill 冲突规则出现矛盾检查 when_not_to_use明确边界中文内容乱码文件编码不是 UTF-8另存为 UTF-8 without BOM5.4 排查 Skill 问题的通用套路最后分享一个排查 Skill 问题的通用套路二分法禁用。当多个 Skill 同时加载但行为不符合预期时不要排列组合地试直接从“只保留第一个 Skill”开始跑一次任务看结果对不对然后依次追加第二个、第三个。这样很快就能定位到是哪个 Skill 引入的问题。还有就是建议在初期给每个 Skill 单独建档做测试题一套固定的测试任务每次改完 Skill 配置后跑一遍。这其实就相当于自动化测试里的回归测试看起来单调但能避免很多“我明明改了怎么没变化”的问题。6. 我在实际折腾中积累的经验和后续玩法6.1 审美 Skill 不是越多越好先跑通再堆量最开始我收藏了网上能找到的各种 Skill什么科研排版、数学建模可视化、甚至还有一些用途不明的包一股脑全塞进 WorkBuddy。结果就是目录一堆文件夹真正干活时反而不知道该用哪个。后来我学乖了先只保留这 4 个和做图强相关的 Skill把一条完整流程跑顺再根据实际需求慢慢加。加的时候也坚持一个原则新 Skill 要么能独立解决问题要么能明显增强现有流程否则不装。很多人误以为 Skill 是多多益善实际上每次任务加载什么 Skill 是要花上下文和决策成本的装多了只会拖慢 Agent 的响应速度。6.2 把 Skill 当作品类来打磨而不是一次性脚本我最早写 Taste Skill 的时候只写了大概二十行描述效果勉强能用。后来每跑一次图遇到它判断不准确的地方我就顺手在规则文件里补一条。两个月下来这个 Skill 已经比我最初写的那版厚了三倍判断准确率也高了很多。这个迭代思路很重要Skill 不是一次性写完就不管的东西它应该像你的知识库一样持续生长。WorkBuddy 本身的优势就在本地部署所有配置文件都是可读可改的这给了你充足的打磨空间。6.3 从做图延伸到更多内容生产场景这套思路其实不止能做图。我已经把 Taste Skill 的判断框架用到了博客封面选择上把 Archify Skill 的规则用到了方案汇报的排版里Impeccable Skill 里的配色规范也被我抄到了日常 PPT 里。本质上你是在把“审美”拆成一系列可复用的规则而规则一旦沉淀下来放在任何内容生产场景里都成立。我个人的体会是工具层面的差异最终会被抹平真正拉开差距的是你愿不愿意花时间去建立自己的“审美操作系统”。这 4 个 Skill 只是开头后面的扩展空间完全取决于你在实际使用中愿意投入多少心思。 WorkBuddy 做图总翻车？用 4 个 Skill 搭一套审美操作系统
如果你也跟我一样一开始用 WorkBuddy 做图做到怀疑人生——明明提示词写了一大堆模型也够聪明产出的图总有种说不出的“塑料味”排版像 PPT 模板、配色刺眼、构图永远往正中间怼发给同事直接来一句“这是 AI 跑的吧”。说实话WorkBuddy 本身的能力没问题问题在于它没有一个“审美兜底层”。后来我把“审美”这件事拆成 4 个 Skill 装进去做图终于不是碰运气了。这篇文章就把这套方法完整拆开每个 Skill 解决什么、怎么安装、怎么在真实工作流里串起来以及我踩过的坑。适合正在用 WorkBuddy、CodeBuddy 这类 Agent 工具的朋友尤其是需要频繁出图、做架构图、写视觉方案但本身又不是设计师的开发者。1. 先说我为什么开始折腾 WorkBuddy 的 Skill1.1 WorkBuddy 到底是什么和普通工具差在哪WorkBuddy 是一个本地化部署的 Agent 型工作台你可以把它理解成“能自己拆任务、调工具、按步骤执行”的 AI 副驾驶。它跟 CodeBuddy 属于同一套生态很多人从 CodeBuddy 切过来就是看中 WorkBuddy 对自定义指令和 Skill 机制的友好度。Skill 这个概念最早在 Claude Code 那套工作流里火起来后来 Codex Skill、OpenClaw Skill 陆续跟进。WorkBuddy 的 Skill 机制跟它们思路一致把一套完整的“行为准则 操作规范 示例”打包成一个文件夹Agent 在干活时按需加载而不是靠每次对话里临场写一大段提示词。用一句话概括提示词是告诉 AI“这次怎么做”Skill 是告诉 AI“以后遇到这类事都按这套来”。做图这种事恰好是最需要“以后都按这套来”的——因为没有审美规范每次生成都是在盲盒里抽奖。1.2 用 WorkBuddy 做图丑的根因不是模型不行我一开始也以为是底层模型画图能力弱后来发现根本不是。WorkBuddy 出图丑根因有三个第一默认指令太“通用”。AI 并不知道你的场景是公众号封面、产品架构图还是技术方案配图于是它会选择最稳妥的排版——居中、大标题、纯色背景结果就是千篇一律的“AI 模板脸”。第二缺少前置审美判断。真正的好图不是一次生成出来的而是先有“什么算好看”的标准再按标准去执行。WorkBuddy 默认没有这个“判断层”它只负责“生成”不负责“鉴别”。第三反馈回路太慢。你被丑图气到才开始想怎么改提示词改完再跑一次效率极低。如果能让它在动手之前就先过一遍审美规则、动手之后自己检查一遍整个出图质量就上来了。所以问题的本质不是工具不够强而是缺少一套可复用的“审美操作系统”。把这套系统做成 Skill就是最合理的解法。2. 4 个 Skill 的选择逻辑与各自分工2.1 为什么是 4 个而不是 1 个“万能审美包”说实话我也想一个 Skill 搞定所有事。但试过之后发现审美这件事最少包含三个层次第一层是“知不知道什么是好看的”判断力第二层是“能不能把好看做出来”执行力第三层是“能不能避免 AI 味太重”人性化。再加上我日常工作里大量涉及架构图、流程图这类可视化内容于是又加了一个专门管图纸的 Skill。一个万能包的问题在于它所有规则混在一起Agent 加载时不知道该优先执行哪条最后往往是每条都浅尝辄止。拆成 4 个独立 Skill 之后每个都职责单一WorkBuddy 可以按任务类型精准加载。这个设计思路跟你写代码时拆分模块是一个道理。这 4 个 Skill 分别是Taste Skill审美鉴别的“美术总监”负责判断美丑、给修改意见。Impeccable Skill视觉规范落地的“执行标准”负责把美学原则变成可执行的参数。Humanizer Skill去 AI 味的“人味修复器”负责让图看起来像人做的。Archify Skill图纸可视化的“架构美化器”负责让架构图、流程图告别黑框白字。2.2 Taste Skill先解决“不知道丑在哪”Taste Skill 的作用是给 WorkBuddy 装上一个“审美判断前置层”。每次生成图片、网页截图、海报草稿之前它会先对输入的需求做一轮风格判断这个场景适合什么构图、什么调性、什么配色逻辑输出一份简短的“审美简报”。我实际使用时会让它输出三个东西风格定位比如“冷静专业向”还是“活泼社媒向”、视觉禁忌比如“避免大面积高饱和撞色”、参考方向比如“参考杂志封面式留白而不是 PPT 模板式排版”。这个 Skill 的核心价值在于“把隐性审美显性化”。很多非设计背景的人不是没有审美而是说不清“哪里不对”。Taste Skill 相当于帮你把那种模糊的感觉翻译成 AI 能听懂的语言。2.3 Impeccable Skill让“好看”变成可执行的参数光有判断还不够还得让 AI 知道“具体怎么做才叫好看”。Impeccable Skill 就是干这个的它把设计规范拆成了可量化的参数。举个最直接的例子它内置了一套基础排版规范标题字重必须高于正文一个梯度、段间距统一用 1.5 倍行高、页边距不得小于内容区的 8%、同一画面里最多使用 3 种字体。配色上它会按 60-30-10 法则控制主色、辅助色、强调色的比例而不是让 AI 随手抓几个颜色就往上怼。这套规范听起来有点死板但正是这种“死板”让 AI 的输出稳定下来。设计的基础从来不是纯自由发挥而是先有秩序、再谈突破。Impeccable Skill 做的事就是先把秩序建立起来。2.4 Humanizer Skill去掉一眼假的“AI 味”跑过几次图你就会发现AI 做得再“规范”也还是容易有一种难以言说的生硬感。典型症状包括标题永远居中、图片永远对称、注解文字永远工工整整排在下方。Humanizer Skill 专门解决这个问题。它的思路是注入“人类设计师的真实操作习惯”比如标题可以左对齐、刻意制造不对称构图、用色块代替细线做分割、在角落加一个小的装饰性文字。这些都是人类设计师下意识会做的事AI 默认不会。我自己的体会是加了这个 Skill 之后出图从“企业 VI 手册风格”变成了“一个有点审美的同事随手排的版”这个转变对日常沟通非常重要——因为前者一看就是 AI 跑的后者至少愿意多看你一眼。2.5 Archify Skill处理技术人最常画的丑图第四个 Skill 是我单独为架构图、流程图、拓扑图加的。技术场景里最尴尬的事就是业务方案讲得清清楚楚一画架构图就露怯。黑框白字、箭头交叉、该对齐的没对齐整个图的信息传达效率还不如直接说话。Archify Skill 的核心规则包括同一层级组件必须对齐同一边缘、所有节点统一使用 2px 边框、箭头弯曲弧度和方向必须一致、标签文字统一用等宽字体、按区域用浅色背景做分区而不是靠方块拼贴。它做得最好的一点是不只是生成漂亮的图而是把“这个图应该怎么分组、怎么表达层级关系”也一并处理了。所以最后出来的图不光是好看是真的能看懂。Skill 名称核心职责解决的问题典型应用场景Taste审美判断不知道丑在哪生成前出审美简报Impeccable规范落地知道好看但做不出来排版、配色、字体执行Humanizer去 AI 味图太生硬、模板感强社媒图、海报、封面Archify图纸美化架构图、流程图丑技术方案、汇报材料3. 安装与本地部署实操把 Skill 装进 WorkBuddy3.1 Skill 放哪里、目录怎么组织WorkBuddy 的 Skill 本质就是一个本地文件夹里面放着描述文件、规则文件和示例文件。以我目前用的版本为例个人级 Skill 放在~/.workbuddy/skills/下项目级的可以放到当前项目根目录的.workbuddy/skills/下。优先加载项目级找不到再回退到全局。每个 Skill 一个独立文件夹命名要一眼能看出用途比如taste-skill、impeccable-skill。文件夹内部结构我强烈建议保持统一这样后面维护和排查都方便~/.workbuddy/skills/ ├── taste-skill/ │ ├── SKILL.md │ └── rules/ ├── impeccable-skill/ │ ├── SKILL.md │ └── rules/ ├── humanizer-skill/ │ └── SKILL.md └── archify-skill/ └── SKILL.md这套结构不是 WorkBuddy 强制要求的是我自己实践下来比较好用的一种组织方式。目录清晰的好处是哪个 Skill 没生效打开文件夹一看就知道是描述文件写错了还是规则文件没放进对应目录。3.2 SKILL.md 文件到底怎么写SKILL.md 是每个 Skill 的核心入口文件WorkBuddy 通过这个文件来理解“这个 Skill 是干嘛的、什么时候该用”。它的格式其实不复杂最前面是一段 YAML frontmatter用---包起来里面定义元信息后面才是真正的指令正文。我以一个简化版的 Taste Skill 为例完整结构大概长这样--- name: taste-skill description: 在生成任何图片、海报或可视化内容前先输出审美判断和风格建议。 when_to_use: 处理图片生成、封面设计、海报排版、视觉方案评审等任务时必须优先加载。 --- # Taste Skill审美鉴别前置 ## 你的角色 你是一名拥有十年经验的美术总监善于用最简短的话指出设计方案的审美问题。 ## 执行步骤 1. 收到设计任务后先输出审美简报风格定位、视觉禁忌、参考方向。 2. 在 AI 动手生成之前将审美简报作为前置指令注入任务上下文。 3. 生成完成后对结果按 构图、配色、字体、层级 四个维度打分并给出改进建议。 ## 评分标准 - 构图主体位置是否合理留白是否得当。 - 配色色相是否统一对比度是否合适。 - 字体层级是否分明数量是否克制。 - 层级信息主次是否清晰视线引导是否自然。 ## 示例输出 ### 审美简报 - 风格定位冷静专业向适合技术博客封面 - 视觉禁忌避免大面积高饱和撞色避免阴影过重 - 参考方向大留白 细线分割 单强调色写完 SKILL.md 之后把它保存到对应 Skill 文件夹里然后在 WorkBuddy 里重新加载一下 Skill 列表正常就能识别到了。如果没生效先检查 YAML frontmatter 的格式——冒号后面必须有空格缩进必须一致这两个问题占了八成失败原因。3.3 规则文件和组织 Skill 的小技巧除了 SKILL.md我把一些更细的、适合机器读的规则拆到独立文件里。这样做的好处是SKILL.md 保持精简Agent 可以快速理解而真正的硬性规范放在 rules 目录下按需加载。拿 Impeccable Skill 举例它的 rules 目录下会有rules/ ├── typography.md # 字体与排版规则 ├── color.md # 配色规则 └── layout.md # 构图与栅格规则每个规则文件不用长重点是要“机器可执行”。什么叫机器可执行就是每一条规则都是明确的判断标准而不是抽象形容词。比如“颜色要高级”这种话 AI 是没法执行的但“主色不超过 2 个、辅助色不超过 2 个、对比度不低于 4.5:1”这种就是可执行的。还有一个小技巧在 SKILL.md 里加一个when_not_to_use字段明确告诉 Agent“哪些情况不要加载这个 Skill”。这一步很多人会忽略但它对减少上下文混乱非常有用。比如 Taste Skill 不需要在代码编写任务里生效提前写清楚能避免它总出来抢戏。4. 四个 Skill 在真实做图流程里怎么串起来4.1 一条完整流程从想法到成品单独装好了 Skill 只算第一步真正让效果发生质变的是把它们串进同一条工作流。我现在处理任何一张图基本都走四步先让 Taste 做审美判断再让 Impeccable 定执行规范接着用 Humanizer 做人性化调整最后如果是图表类内容再交给 Archify 收尾。以我最近做的一张“AI Agent 架构方案配图”为例。需求很简单给一篇技术博客配一张架构图加一张封面图风格要“简洁高级感”。第一步加载 Taste Skill它会先输出审美简报“该场景适合浅色背景、单强调色、大留白架构图部分建议分层清晰封面图部分建议标题左对齐。”这个简报不一定惊艳但至少方向是对的AI 不会再瞎跑。第二步加载 Impeccable Skill把审美简报转成具体参数背景色用 #F7F7F5 这样的暖灰而不是纯白强调色用低饱和度的蓝绿色标题字号 28px、正文 14px、注释 12px。到这个阶段出图已经不会难看到哪去了。第三步加载 Humanizer Skill做最后的“人味”处理。比如封面标题从居中改成左对齐在右下角加一行小字注释架构图的分组背景从纯色改成轻微圆角的浅色块。这些都是小改动但整体观感立刻不一样了。第四步如果图里带架构内容Archify Skill 会复查一遍节点是否对齐、箭头走向是否一致、标签字体是否统一然后输出一张可以直接贴进博客的图。4.2 每一步的实际指令长什么样在 WorkBuddy 里我不需要手动一个个切换 Skill只需要在任务描述里带上标记。比如任务给技术博客《AI Agent 架构实践》配一张封面图和一张架构图。 风格简洁、专业、有审美感。 请使用 [taste-skill] [impeccable-skill] [humanizer-skill] [archify-skill] 协同完成。WorkBuddy 会自动把这 4 个 Skill 按序加载。每一步的输出是下一步的输入整个流程像一条流水线。我实际跑下来的体感是以前做一张能看的图要来回改三四轮现在基本一次成型偶尔微调也是在审美简报范围内的局部优化。4.3 效果对比装上前后差多少装 Skill 之前WorkBuddy 默认生成的图最典型的问题是“什么都对但就是不好看”。字体字号规范、颜色也算协调但就是有一种“网页模板”的味道像是在告诉你“这是一张 AI 做的图”。装上 4 个 Skill 之后最明显的变化是画面有了“呼吸感”。所谓呼吸感说白了就是留白变多了、层次变清了、元素之间有了主次关系。封面图从最开始的“大标题圆形装饰底纹”变成了“左对齐标题大面积留白一个局部强调色块”虽然内容信息没变但气质完全不同。团队同事后来看到图的第一反应是“这图是你自己排的吧”而不是“这又是 AI 跑的吧”。对我来说这个区别就是全部意义。5. 常见问题与排查技巧实录5.1 Skill 不生效怎么办遇到过的最典型问题就是 Skill 明明放进目录了WorkBuddy 就是不加载。排查思路按顺序走先看文件名是不是叫SKILL.md注意大小写不能错再看他到底放在哪个目录了个人级和项目级的优先级不一样项目里已经有一个同名 Skill 的话全局的那个会被忽略。还有一个隐蔽问题YAML frontmatter 里如果有中文引号或者全角符号解析器可能直接报错但报错信息又不明显表现就是 Skill 没被识别。所以写完 SKILL.md 之后我习惯先用文本编辑器检查一遍引号和冒号是不是半角。5.2 多个 Skill 互相抢戏、上下文爆炸同时挂载 4 个 Skill最直接的副作用是上下文长度会涨。我之前试过把每个 Skill 的 SKILL.md 都写得特别长结果执行任务时 WorkBuddy 光读 Skill 描述就占了大半上下文真正干活的容量反而少了。解决办法有两个。一是严格控制每个 SKILL.md 的长度我自己的标准是控制在 200 行以内只保留核心指令。二是充分利用when_to_use和when_not_to_use让 Agent 只加载当前任务需要的 Skill而不是全部塞进去。5.3 和其他工具生态的兼容问题WorkBuddy 的 Skill 机制和 Claude Code、Codex 的 Skill 在思路上类似但格式并不完全互通。我试过直接把 Claude Code 的 Skill 文件夹拷到 WorkBuddy 里结果有的能识别、有的不行主要原因是 frontmatter 里的字段 WorkBuddy 不识别。如果你从网上下载了别人的 Skill 包先打开 SKILL.md 看看 frontmatter 里有哪些自定义字段。如果看到不认识的字段保留name和description其他字段可以先去掉再一步步加回来测试。下面这张表是我踩坑后整理的最常见的 6 个问题和对应解法基本覆盖了九成的情况。故障现象可能原因快速解决Skill 完全不出现文件名不是 SKILL.md 或目录层级不对改成 SKILL.md放在 skills 根目录下一级出现但从不加载when_to_use 描述太模糊写清楚具体触发场景避免“需要时”这种空话加载但行为错误frontmatter 有未知字段只保留 name/description/when_to_use 再测试上下文不够用Skill 内容过长精简到 200 行以内细节移到 rules/ 目录多个 Skill 冲突规则出现矛盾检查 when_not_to_use明确边界中文内容乱码文件编码不是 UTF-8另存为 UTF-8 without BOM5.4 排查 Skill 问题的通用套路最后分享一个排查 Skill 问题的通用套路二分法禁用。当多个 Skill 同时加载但行为不符合预期时不要排列组合地试直接从“只保留第一个 Skill”开始跑一次任务看结果对不对然后依次追加第二个、第三个。这样很快就能定位到是哪个 Skill 引入的问题。还有就是建议在初期给每个 Skill 单独建档做测试题一套固定的测试任务每次改完 Skill 配置后跑一遍。这其实就相当于自动化测试里的回归测试看起来单调但能避免很多“我明明改了怎么没变化”的问题。6. 我在实际折腾中积累的经验和后续玩法6.1 审美 Skill 不是越多越好先跑通再堆量最开始我收藏了网上能找到的各种 Skill什么科研排版、数学建模可视化、甚至还有一些用途不明的包一股脑全塞进 WorkBuddy。结果就是目录一堆文件夹真正干活时反而不知道该用哪个。后来我学乖了先只保留这 4 个和做图强相关的 Skill把一条完整流程跑顺再根据实际需求慢慢加。加的时候也坚持一个原则新 Skill 要么能独立解决问题要么能明显增强现有流程否则不装。很多人误以为 Skill 是多多益善实际上每次任务加载什么 Skill 是要花上下文和决策成本的装多了只会拖慢 Agent 的响应速度。6.2 把 Skill 当作品类来打磨而不是一次性脚本我最早写 Taste Skill 的时候只写了大概二十行描述效果勉强能用。后来每跑一次图遇到它判断不准确的地方我就顺手在规则文件里补一条。两个月下来这个 Skill 已经比我最初写的那版厚了三倍判断准确率也高了很多。这个迭代思路很重要Skill 不是一次性写完就不管的东西它应该像你的知识库一样持续生长。WorkBuddy 本身的优势就在本地部署所有配置文件都是可读可改的这给了你充足的打磨空间。6.3 从做图延伸到更多内容生产场景这套思路其实不止能做图。我已经把 Taste Skill 的判断框架用到了博客封面选择上把 Archify Skill 的规则用到了方案汇报的排版里Impeccable Skill 里的配色规范也被我抄到了日常 PPT 里。本质上你是在把“审美”拆成一系列可复用的规则而规则一旦沉淀下来放在任何内容生产场景里都成立。我个人的体会是工具层面的差异最终会被抹平真正拉开差距的是你愿不愿意花时间去建立自己的“审美操作系统”。这 4 个 Skill 只是开头后面的扩展空间完全取决于你在实际使用中愿意投入多少心思。