我用 SKILL.md 做了一个简历生成器¶

Ch07.047 我用 SKILL.md 做了一个简历生成器¶

📊 Level ⭐⭐ | 7.1KB | entities/我用-skillmd-做了一个简历生成器.md

我用 SKILL.md 做了一个简历生成器¶

“你养龙虾了吗？”——这是2026年春天最流行的社交寒暄。一个月前，我也跟风在阿里云上花68块买了台轻量服务器，一键部署了OpenClaw。那只可爱的小龙虾在我的服务器里安了家，24小时在线，能操控电脑、执行命令、发消息。然后呢？然后我发现，我根本不知道怎么“教”它干活。 这大概是所有“养虾人”的共同困惑：OpenClaw给你的是一个空转的引擎，它有能力做任何事，但它不知道你要它做什么。有人用它自动抓取公告、盯盘选股，有人用它一键发文到微信公众号，有人用它处理政务民生服务。区别在哪？区别在于，那些真正用起来的人，都学会了一件事：给AI写“说明书”。 今天就带你亲手写一份“说明书”。我们要做一个Resume Forge Skill——把你的Markdown简历一键转成PDF。全程不用写复杂的Agent代码，只用SKILL.md，搭配OpenClaw的Skills机制。

• ** 零外部依赖 ** ：不需要API Key、数据库、网络。任何人克隆下来就能跑。

相关实体¶

• Skill Engineering Ai As Algorithm
• Hermes Agent Getting Started Guide 2026
• Llm Raiders Private Ai Server
• Pi Mono Github
• 我用 Skillmd 做了一个简历生成器

→ 原文存档

• MOC

深度分析¶

SKILL.md 规范的核心理念是"渐进式披露"（Progressive Disclosure）——这是一个在 UI 设计领域早已成熟的模式，核心思想是只展示当前步骤需要的信息，不提前加载无关内容。在 AI Skill 场景下，这个模式的价值被进一步放大：LLM 的上下文窗口是稀缺资源，Skill 的设计者需要决定什么信息在什么时候进入上下文。文章演示的三层架构（前置元数据 ~100 token → 正文 ~1350 token → 按需加载的外部文件）本质上是一套严格的资源分配协议，确保每个 token 都花在刀刃上^。

description 字段的设计是整个 Skill 的灵魂。与其说它是描述，不如说它是一个"触发条件清单"。文章强调要同时包含正向触发词（resume、CV、ATS-friendly）和负向边界（Do NOT use for: cover letters、job searching），这种正负清单的设计让 LLM 可以在不做算法判断的情况下完成路由决策。这是一种把复杂推理转化为查表的策略——查表的速度远快于推理，且可预测性更高。对于企业级 Skill 场景，这种确定性比"聪明的推理"更重要，因为一次误触发可能导致生产环境的错误行为^。

验证循环（Validate Loop）是 Skill 可靠性的核心保障。文章中的 Step 4 要求 Agent 在验证零错误之前不得进入下一步，这个简单的约束实际上把"自我纠正"能力嵌入到了工作流里。传统的单轮 LLM 调用没有这个机制——模型输出什么就是什么，错了只能靠人工发现。验证循环把"检验"这个动作显式化了。更值得注意的是验证器的错误消息设计：每条错误不仅说明"缺少什么"，还直接给出"怎么补"（添加 H1 标题 # 你的姓名），让 Agent 可以不经过人类确认直接执行修复。这种"自解释的错误消息"是 Skill 设计中极易被忽视但极其重要的细节^。

Gotchas 陷阱清单是整篇文章中最有价值的设计模式之一。它的本质是把人类专家才知道的"隐式知识"（tacit knowledge）显式化。Agent 不会自己发现 WeasyPrint 会静默回退到系统默认 serif 字体，也不会天然知道 accented 字符可能破坏 ATS 解析——这些是只有踩过坑的人才能写出来的内容。如果没有 Gotchas，Agent 只能通过试错学习，浪费大量 token 且可能产生不合规输出。专家知识显式化、一次编写到处运行——这才是 Skill 作为知识封装单元的真正价值所在^。

脚本通过 bash 运行、只返回结构化 JSON 这一设计选择，隐藏着一个深刻的工程哲学：把"不确定性"留给 LLM，把"确定性"留给脚本。解析简历、生成 PDF 都是确定性任务，应该用确定性代码执行；只有"判断 Skill 是否相关"、"决定下一步做什么"这类需要泛化能力的任务才交给 LLM。这种分工让 Skill 的 token 消耗变得可预测、可控制——LLM 的非确定性能力和确定性脚本的可靠性各自在擅长的层面发挥作用，形成了一个高效的混合执行架构^。

实践启示¶

1. description 是 Skill 的第一产品力：在动手写正文之前，先花时间打磨 description。加入所有可能的触发词，明确负向边界（Do NOT use for），让 LLM 能精准判断何时激活这个 Skill。description 的质量直接决定了 Skill 的触发准确率^。

2. 用清单式工作流组织正文：将 Skill 的执行步骤写成 - [ ] Step N: 描述 的清单格式，给 Agent 提供清晰的进度感和每步的具体脚本路径。避免让 Agent 自己决定"下一步做什么"——确定性来自显式的步骤声明^。

3. 每个验证错误消息必须包含修复操作：不要只写"缺少字段"，要写"缺少字段：添加 H1 标题 # 你的姓名 到 Markdown 顶部"。验证器的价值不仅在于发现问题，更在于让 Agent 能在不询问人类的情况下直接执行修复^。

4. 尽早沉淀 Gotchas，别让 Agent 试错学习：当你发现一个 Skill 会踩的坑，立刻写成 Gotchas 条目。Gotchas 是专家知识显式化的最佳载体，是 Skill 能在不同团队、不同场景复用的核心资产。格式建议：说明症状 → 原因 → 隐含的解决方法^。

5. Level 3 资源按需加载，不要提前嵌入正文：ATS 优化指南、行业风格参考这类内容只在特定任务需要时才加载。让只想"转 PDF"的用户不付出 ATS 指南的 token 成本，让需要"金融岗位 ATS 友好简历"的用户精准触发相关文件的加载^。