企业官网建设流程全解析

先说一个判断：在 AI Agent 工具井喷的当下，决定工具上限的不是模型本身，而是你到底给了它多少“可复用的能力包”。这个能力包，在不同的产品里有不同的叫法，在 WorkBuddy 里叫做 Skill。过去我们总觉得，AI 工具强不强取决于模型参数够不够大；实际用下来你会发现，同一个模型，有人能把它调教成项目助理、文档分析师、备课助手，有人只能拿到一堆“正确的废话”，差别就在于有没有把任务固化成 Skill。

很多同学把聊天型 AI 当“搜索引擎高级版”用，输出好坏全看当时的提示词和运气。但真正的效率玩家，早已把高频任务沉淀成 Skill：一份周报、一次 PDF 信息抽取、一套备课流程、一段打斗动作分镜的提示词，都能变成几十秒内可复用的能力。同样是 WorkBuddy，有人用它搭起了完整的工作台，有人还停留在“输入问题、等待输出”的原始阶段，这种差距不是工具造成的，是使用方式造成的。

这篇文章按真实使用顺序，把 Skill 的查找、安装、创建、使用、优化五个环节完整过一遍。文中示例代码和配置可以直接复制使用，配合你自己的业务场景稍作修改，10 分钟内跑通第一个 Skill 并不夸张。如果你之前尝试过 Skill 却没有成功，多半是卡在目录结构、description 匹配或权限这三件事上，这篇文章也会逐一展开。

1. 为什么需要 Skill：从“通用助手”到“任务专家”

1.1 只靠提示词，为什么不够用

提示词不是不能解决问题，而是解决问题的成本太高。一段好的提示词依赖个人表达能力，同一个团队里，A 写的周报提示词和 B 写的完全不一样，换个人就不可复制。更重要的是，提示词只能约束模型“怎么说”，很难约束模型去执行真实的工具操作，比如读取 git 提交记录、扫描某个目录、调用外部脚本、批量处理 PDF 文件。

从结果上看，提示词是一次性的“灵感”，换一个项目、换一个同事、换一台电脑，这段经验就断了。团队里经常出现这种情况：某个人特别会写提示词，每个任务都能调出很好的结果，但这个人一休假，整个团队的 AI 使用水平立刻退回到新手状态。问题不在于人，而在于经验没有被结构化、没有沉淀成可以被反复加载的资产。

这时候 Skill 的价值就很明显了。它不是把提示词再抄一遍，而是把“指令 + 示例 + 脚本 + 素材”打包成一个独立软件包。模型加载一个 Skill，就像给一个通用员工发了一本针对某个岗位的操作手册：输入什么、按什么顺序处理、输出成什么格式、碰到边界情况怎么办，手册里都写清楚了。

1.2 Skill 是什么：一包可以复用的“工作能力”

从社区共识和各家 Agent 工具的实现来看，Skill 的标准形态是：一个以 SKILL.md 为核心的目录。SKILL.md 的头部是 YAML 格式的元信息，包括名称、描述、版本、触发词；正文则是 Markdown 格式的完整操作指令。目录里还可以附带脚本、模板、参考资料，做真正复杂的任务也没问题。

可以这样理解 Skill 的定位差异：

提示词是一次性的灵感，Skill 是长期沉淀的资产。如果你在 WorkBuddy 里看到“skill 编码”之类的编号，通常是指 Skill 在社区或管理后台中的登记编号，方便检索和定位问题。实际使用时，你不需要记住这些编码，只要按任务关键词搜索即可。

1.3 WorkBuddy、CodeBuddy 与 Skill 的关系

WorkBuddy 和 CodeBuddy 从命名就能看出同属一个产品家族。从社区使用习惯看，CodeBuddy 更偏编程场景，WorkBuddy 更偏“工作台”场景：把文档处理、信息抽取、报告生成、备课、科研整理、资料归纳等日常任务编排成自动化流程。两者都支持 Skill，这也是同一套 Skill 包可以在多种 Agent 工具之间迁移复用的原因。

对开发者来说，学 Skill 的成本是单向的：你学会了这套格式，换工具时迁移成本很低，因为核心是标准化的 SKILL.md 约定，界面只是外壳。真正值得投入精力的，是理解“如何把一个模糊任务拆解成模型能稳定执行的指令”，这个能力在任何工具上都通用。

2. Skill 核心概念与目录格式

2.1 SKILL.md：Skill 的“门面”

SKILL.md 是 Skill 的入口，Agent 工具读取 Skill 时，第一眼看到的就是它的元信息。一个实用的 SKILL.md 至少包含四个部分：

1. 元信息（frontmatter）：name、description、version、trigger、author、tags。其中 description 最重要，因为它决定了 Skill 能不能在对话中被自动匹配到。
2. 任务定义：说明这个 Skill 解决哪类问题、边界在哪里、不处理什么。
3. 执行步骤：模型必须遵守的流程，最好用带序号的列表明确写出先后顺序。
4. 输出规范：包括结构、格式、语气、禁忌事项，让每次输出尽量稳定。

这里有一个新手常见的误解：以为 SKILL.md 越长越专业。实际上，描述写得太长、太宽泛，反而容易让模型匹配错误任务；正文写得太长，模型可能抓不住重点。好的 SKILL.md 应该像一份精确的作业指导书，规定做什么、怎么做、输出什么，而不是一篇自由发挥的论文。

2.2 标准目录结构

以最常见的约定为例，一个完整的 Skill 目录大概长这样：

weekly-report/ ├── SKILL.md # 入口文件，必须有 ├── scripts/ # 辅助脚本目录（可选） │ └── build_report.py ├── templates/ # 模板目录（可选） │ └── weekly_report_template.md ├── assets/ # 参考素材目录（可选） │ └── example_reports.md └── README.md # 说明文档，便于团队阅读（推荐）

目录名通常与 name 保持一致，使用小写字母和连字符。scripts、templates、assets 这类组织方式是社区中的通用惯例，WorkBuddy 等工具在导入 Skill 时会按目录扫描；具体字段以工具文档为准，但“一个 Skill = 一个目录 + SKILL.md”这个核心模型，在主流实现里是一致的。如果你下载的 Skill 包解压后不见 SKILL.md，而是套了一层同名目录，第一步应先修正目录层级，再放入正式目录。

2.3 触发与匹配逻辑

Skill 的触发主要靠 description。当用户输入自然语言时，WorkBuddy 会把候选 SKILL.md 的 description 与用户意图做相似度匹配，如果相似度高，就自动加载该 Skill。换句话说，description 不是给人看的简介，而是给模型看的检索索引。

明白这一点，很多使用问题就能解释通了：你说“帮我写周报”，但 Skill 的 description 写的是“生成项目管理摘要”，模型很可能匹配不上；你说“把这段文字去一下 AI 味”，如果 Skill 的 description 里没有“去AI味”“自然语言改写”等词，它也不会被加载。第 7 章我会专门讲怎么优化 description，这里先记住一个结论：Skill 能不能被自动调用，取决于 description 和你真实说法的匹配程度，而不是 Skill 内部写得好不好。

3. 环境准备：安装 WorkBuddy 并确认 Skill 目录

3.1 安装与版本说明

WorkBuddy 的安装本身不复杂，从官网下载对应操作系统的客户端即可。官方版本通常会提供 Windows、macOS、Linux 的安装包，下载时注意区分 64 位和 32 位。热搜里出现过 workbuddy win7 这样的关键词，说明确实有老系统用户在做尝试，这类环境在安装前需要额外确认系统版本兼容性，最好先看一眼官方文档的系统要求。

安装完成后，进入工作台界面，先熟悉两个地方：Skill 管理入口和设置里的数据目录。绝大多数后续问题，比如 Skill 不显示、缓存占满磁盘、历史记录丢失，都和这两个入口有关。不要急着学复杂编排，先把基础环境看清楚，后面会省很多时间。

3.2 确认 Skill 存放目录

第一次使用前，建议先找到 Skill 目录。一般会有两个层级：

• 用户级目录：全局生效，通常位于用户主目录下的隐藏文件夹中，类似~/.workbuddy/skills。
• 项目级目录：跟随某个工作台项目，放在项目目录内的.workbuddy/skills或skills文件夹中。

怎么确认？在 WorkBuddy 设置里查看“数据目录 / Skill 目录”。如果版本没有直接显示，可以在文件管理器里搜索SKILL.md，定位已有 Skill 的位置。用户级目录适合个人常用技能，项目级目录适合特定项目的专用技能。两者不冲突，但要注意：同一个 Skill 在用户级和项目级都存在时，项目级通常会优先生效，这会直接导致你改了用户级文件却看不到变化。

3.3 修改缓存目录的常见做法

长时间处理 PDF、维护大量 Skill 之后，缓存目录可能膨胀到几个 GB。把系统缓存换到另一个盘，是很多用户的刚需。操作上无非两条路：

1. 在设置的“数据目录 / 缓存目录”里直接切换。
2. 通过环境变量指定，部分版本支持，具体变量名以版本说明为准。

修改后重启 WorkBuddy，确认新目录出现了对应的子目录。不要手动把旧缓存复制到新目录，避免损坏索引。如果修改后没有生效，优先检查两个地方：是否重启、是否设置了只读权限。这类问题通常和 Skill 本身无关，但却会浪费很多排查时间。

4. 查找 Skill：来源、类型与质量判断

4.1 官方与社区来源

Skill 的来源通常有三类：

1. 官方 Skill 商店 / 市场：安装后直接搜索、一键安装，安全性最高。
2. GitHub 与社区仓库：很多开发者把 Skill 包开源，搜索“WorkBuddy Skill”或对应任务关键词就能找到。
3. 网盘 / 群文件分享：中文社区里很常见，尤其是教程合集和离线包。

从热搜词能看出，社区对 Skill 的需求非常细分：备课、科研、PDF 处理、测试、打斗动作分镜、去 AI 味、语言学习、像素动画、代码审查等等。你可以直接按照“任务词 + Skill”的组合去搜索，比如“备课 skill”“测试 skill”“去AI味的 skill”，命中率比单纯搜 Skill 高得多。搜索时如果看到 skill 编码，可以用来定位同一个包的不同版本，避免下载到旧版。

4.2 常见 Skill 类型

从这张表能看出，Skill 并不一定需要脚本。纯指令型 Skill 适用于创意、写作、教学类任务；工具型 Skill 配合脚本，可以完成文档过滤、数据统计、文件批处理等需要真实计算的工作。刚开始接触 Skill 时，建议先选一个纯指令型任务练手，跑通格式后再考虑加脚本，这样可以避免“模型输出问题”和“脚本问题”混在一起，难以排查。

4.3 质量判断标准

下载一个 Skill 之前，花 30 秒看四件事：

1. description 是否具体。只说“生成周报”太宽泛，能写出“为研发团队生成中文周报，包含本周总结、关键进展、风险与阻塞、下周计划”才算合格。
2. 结构是否完整。有 SKILL.md、有明确的步骤和输出规范，比只有一段模糊提示词靠谱得多。
3. 版本与更新。有 version 和变更记录，说明作者在维护；长期不更新的 Skill 遇到新版 Agent 工具时可能失效。
4. 脚本安全性。如果包含脚本，先打开看一眼，确认没有读取敏感路径、没有可疑网络请求、没有把数据发送到未知地址。

这四条是底线。尤其是第四点，Skill 本质上是“会被 AI 执行的一段程序化指令”，安装一个来源不明的 Skill，跟运行一个来源不明的脚本风险类似。社区里质量高的 Skill 包很多，但同样存在粗制滥造的搬运包，下载前多看一眼能省掉后续大量麻烦。

5. 安装 Skill：三种常用方式与验证

5.1 方式一：界面一键安装

在 WorkBuddy 的 Skill 商店里搜索关键词，点击安装，然后在 Skill 管理列表里确认状态，这是最快的方式，适合官方市场里的常用技能。界面安装的好处是没有路径问题，工具会自动把 Skill 放到正确的目录并注册到列表里。缺点是如果商店里的版本不全，你可能找不到需要的 Skill，这时候就要用第二种方式。

5.2 方式二：手动导入 Skill 包

手动导入适合从 GitHub、网盘下载的 zip 压缩包。操作不复杂，但有几个容易踩的坑：

1. 解压后确认目录顶层是 SKILL.md，而不是多包了一层的同名文件夹。
2. 建议先解压到临时目录，验证目录结构，再放入正式目录。
3. 用户级目录和项目级目录的选择，按是否希望全局生效来决定。

示例命令如下：

# 进入用户级 Skill 目录（Windows 用户请用对应路径） mkdir -p ~/.workbuddy/skills cd ~/.workbuddy/skills # 解压 Skill 包 unzip weekly-report.zip # 解压后检查目录结构 ls -la weekly-report/ cat weekly-report/SKILL.md | head -20

放到正式位置后，重启 WorkBuddy 或点击“刷新 Skill 列表”。看到新的 Skill 出现在列表里，说明导入成功。如果列表里看不到，第一个要检查的就是目录层级，其次是文件名大小写，SKILL.md 不要写成 skill.md 或 Skill.md。

5.3 方式三：企业内网离线部署

很多团队使用 WorkBuddy 是在内网环境，无法直接访问外部商店。这时 Skill 的传递方式就变成：在可联网的环境下载 Skill 包 → 打包压缩 → 通过内网文件系统或企业网盘传到目标机器 → 放置到目标机器的 Skill 目录 → 重启验证。

这里最常见的坑是权限。放到系统目录后如果提示无权限读取，用普通用户目录代替系统目录；如果服务以特定账号运行，要保证该账号对 Skill 目录有读写权限。把 Skill 和模型一起部署到内网服务器时，还要检查模型配置路径和 Skill 路径是否一致，否则会出现 Skill 加载成功但模型调用失败的怪问题。内网环境排错成本高，建议在部署前用同一个 Skill 包在测试环境完整跑一遍。

5.4 安装后的验证

装完不能只在列表里看到就完事。验证分三步：

1. 查看详情：确认 name、description、version 读取正常。
2. 发起一次测试对话：直接说与 description 相关的一句话，看 Skill 是否被自动加载。
3. 查看日志：如果加载失败，WorkBuddy 日志中通常会有 Skill 解析路径的记录。

如果测试对话没有被匹配，优先考虑不是目录问题，而是 description 与测试语句不匹配。这一点不理解的人，会在目录上反复折腾，白白浪费时间。

6. 创建并使用 Skill：从 0 到 1 的完整示例

6.1 需求分析与目录创建

为了不发散，我们做一个可实际使用的“项目周报”Skill。需求如下：

• 输入：用户用自然语言描述本周工作。
• 输出：结构化周报，包含本周总结、关键进展、风险与阻塞、下周计划。
• 加分项：自动读取当前项目 git 仓库最近 7 天的提交记录，把提交信息整理进周报。

这里故意让 Skill 同时包含指令与脚本，覆盖“纯指令”和“带工具能力”两种形态。先创建目录：

mkdir -p ~/.workbuddy/skills/weekly-report/scripts mkdir -p ~/.workbuddy/skills/weekly-report/templates

6.2 编写 SKILL.md

--- name: weekly-report description: 为项目团队生成中文周报。当用户提到"写周报""项目周报""本周总结""weekly report"时使用。 version: 1.0.0 author: your-name tags: [report, project-management, workflow] --- # 项目周报 Skill 你是一个项目周报撰写助手，目标是产出一份可以直接粘贴到团队的周报。 ## 执行步骤 1. 询问用户汇报周期，默认最近一周。 2. 如果用户没有提供任务明细，运行 scripts/build_report.py 读取 git 日志作为素材来源。 3. 让用户确认或补充：本周完成事项、下周计划、风险阻塞。 4. 按下方模板输出周报。 ## 输出模板 ### 本周总结 （2-4 句话概括整体进展） ### 关键进展 - 完成 XXX，支持 XXX 能力 / 解决 XXX 问题 ### 风险与阻塞 - XXX，计划于 XX 时间解决 ### 下周计划 - XXX ## 写作规则 - 每条进展使用"动词 + 对象 + 结果"句式。 - 删除掉"进行了一些优化"这类含糊表述。 - 使用数据时保持原样，不要编造 commit、PR 链接或数据。

注意 description 里包含了“写周报”“项目周报”“本周总结”“weekly report”等自然语言说法，这能让模型更容易匹配合适的任务。正文里的写作规则不是可有可无的修饰，而是真正决定输出质量的部分：没有这些规则，模型会生成一堆“本周进行了多项工作”的空话；有了“动词 + 对象 + 结果”的约束，输出才会变得可读、可交差。

6.3 加入辅助脚本

# 文件路径：~/.workbuddy/skills/weekly-report/scripts/build_report.py import subprocess import sys from datetime import datetime, timedelta def get_commits(days=7): since = (datetime.now() - timedelta(days=days)).strftime("%Y-%m-%d") cmd = ["git", "log", "--since=%s" % since, "--pretty=format:%h|%an|%s"] try: result = subprocess.run(cmd, capture_output=True, text=True, check=False) if result.returncode != 0: print("提示：当前目录不是 git 仓库或读取失败", file=sys.stderr) return [] lines = result.stdout.strip().splitlines() commits = [] for line in lines: parts = line.split("|", 2) if len(parts) == 3: commits.append({"hash": parts[0], "author": parts[1], "message": parts[2]}) return commits except Exception as exc: print("读取 git 日志异常: %s" % exc, file=sys.stderr) return [] if __name__ == "__main__": commits = get_commits() print("最近 7 天提交数：%d\n" % len(commits)) for c in commits[:20]: print("- %s | %s | %s" % (c["hash"], c["author"], c["message"]))

脚本的逻辑很简单：在 git 仓库里读取最近 7 天提交，输出短哈希、作者、提交信息。脚本本身没有写操作，只读 git 历史，权限风险很低。如果你在 Windows 上运行，建议把 Skill 目录放到项目内部，并确认 git 命令在 PATH 中；否则脚本会报“git 不是内部或外部命令”。

6.4 注册、重启与验证

把weekly-report目录放到 Skill 目录后，重启 WorkBuddy，在 Skill 列表中确认 weekly-report 出现。然后发起一句测试：

“帮我写本周项目周报，这是我这周做的事：完成了登录模块重构，修复了三个线上 bug，下周要开始做权限中心。”

正确结果是：模型自动加载 weekly-report，并输出包含本周总结、关键进展、风险与阻塞、下周计划的完整周报。如果它没有按模板输出，说明 SKILL.md 没有被读取，先检查目录位置和文件名大小写。如果模型回复“我无法运行脚本”，说明当前会话没有脚本执行权限，需要在配置里打开对应的执行开关。

6.5 触发方式与工作台编排

日常对话中最常见的触发是自动匹配：用户在对话框输入自然语言，WorkBuddy 根据各 SKILL.md 的 description 与用户意图的相似度，自动加载最优 Skill。这种体验最自然，但对 description 质量要求最高。

除了自动匹配，很多 Skill 的 frontmatter 里有 trigger 字段，或者约定了一组触发词。用户可以直接在对话中提到触发词，比如“用周报 Skill 生成本周总结”。显式触发适合验证一个 Skill 是否可用，也是自动化流程中更可控的调用方式。

WorkBuddy 名字里的“工作台”不是形容词。从社区的使用方式看，它的核心能力是把多个 Skill 编排成一条自动化链路，比如：SkillA 抓取资料 → SkillB 做信息抽取 → SkillC 生成结构化报告 → 最后人工确认输出。这样“搭工作台”的价值就不是省一次对话，而是省掉一条业务链路的人力。

对初学者，建议先不要急着编排多 Skill。先把单个 Skill 用熟，理解它的输入输出边界，再考虑组合。否则一旦某个环节匹配不上，你会在链路中间反复调试 description，体验非常糟糕。

7. 优化 Skill：让输出从“能用”变成“好用”

7.1 从一次失败输出开始迭代

不少同学创建完 Skill 后就不再修改，这很可惜。Skill 的真正价值在于它可以不断迭代，而且每迭代一次，所有使用它的人都会同步受益。推荐的优化循环是：

一次测试 → 观察输出偏差 → 定位原因 → 修改 SKILL.md 或脚本 → 再次测试。

输出偏差大概率来自三类原因：输入信息不足、步骤顺序不明确、输出规范太弱。三者的修法完全不同，先判断再动手。如果模型总是漏掉某个步骤，问题在正文流程；如果模型结构都对但内容空泛，问题在输出规范和示例；如果模型压根没加载 Skill，问题在 description。

7.2 优化 description 与触发词

description 的改进有三个方向：

1. 增加更多的自然语言等价说法：“写周报”可以扩写成“生成项目周报”“本周工作汇总”“weekly report summary”。
2. 收敛范围：如果 Skill 既写周报又写月报还写日报，description 最好按最典型场景写，其他场景在正文里说明。
3. 加入边界：“仅当用户要求中文周报时使用”，避免其他语言场景误匹配。

判断标准很简单：让一个不了解该 Skill 的人，看到 description 后能立刻说出这个 Skill 适合什么任务。如果他能说出来，说明 description 合格；如果他说“好像是做报告的吧”，说明还不够具体。

7.3 优化指令与示例

正文的优化重点是具体化。“请输出一份周报”和“每条进展用动词 + 对象 + 结果句式”，对模型的影响完全不同。前者全靠模型自由发挥，后者真正约束了输出质量。

还有一招很有效：在 SKILL.md 里放一个完成示例。在 templates/example_reports.md 里放两个不同项目的周报范文，比写十条规则都有用。Few-shot 示例对模型输出的稳定性和风格统一性帮助极大，尤其是写作类、报告类 Skill。示例要放在能被正文引用的位置，而不是放在一个从不被加载的角落。

7.4 版本管理与团队协作

给 SKILL.md 维护 version 和变更记录，不是形式主义。团队里多个 Skill 一起变更时，没有版本号你根本不知道哪个成员改了什么。建议：

• 每个 Skill 独立一个小 git 仓库，或者放进团队公共仓库的子目录。
• 名字格式统一：小写字母、数字、连字符。
• 修改 description 属于“不兼容变更”，必须升版本，因为会影响匹配行为。
• 每次变更在 README 或变更记录里写清楚“为什么改”。

这套习惯一开始可能觉得多余，但 Skill 数量超过 20 个之后，没有版本管理就意味着只能靠记忆维护，基本等于没有维护。

7.5 其他常见优化方向

热搜里有一类很典型的“去 AI 味”Skill。这类 Skill 的优化本质就是约束模型：禁止“首先、其次、综上所述”等词汇，要求用短句、口语化表达、减少排比句。规则不复杂，但效果差异极大，原因就在于约束词写得多具体、有没有给出正反例。

不管你的 Skill 是什么方向，优化原则是一致的：说得越具体、示例越充分、边界越清楚，输出就越稳定。优化的终点不是“写得很多”，而是“每个词都在约束模型行为”。能达到这个状态，说明你真的理解了自己任务的坑在哪里。

8. 常见问题与排查思路

如果遇到表格之外的问题，第一步永远是看日志。WorkBuddy 的日志一般会在数据目录的 logs 文件夹下，按时间查找“Skill 解析”“Skill load”相关记录。在提问之前先贴出日志，能省掉大量来回沟通。日志是一种客观证据，也是排查一切 AI 工具问题的通用入口。

9. 最佳实践与工程建议

9.1 命名与目录规范

稳定的命名约定非常重要。建议：

• 目录名、name 字段保持大小写和连字符一致，例如weekly-report。
• 一个 Skill 只做一件事。如果一个 Skill 的描述里出现“同时也处理”这样的说法，说明它应该被拆分。
• 所有临时文件放在 Skill 自己的 scripts 临时目录或系统临时目录，不要污染项目目录。
• 每个 Skill 至少有一个 README，说明用途、依赖和调用方式，方便团队其他成员使用。

这些规范看起来琐碎，但决定了 Skill 库能不能长期维护。没有规范时，Skill 数量一多，查找和排错的成本会指数级上升。

9.2 安全边界

第三方 Skill 的质量参差不齐，安全上要守住几条底线：

• 不安装来源不明的 Skill，尤其是带可执行脚本的。
• 脚本读取文件时限定在用户显式指定的目录内，不要随意扫描整个磁盘。
• Skill 涉及网络请求时，必须在 README 中声明请求目标和目的。
• 运行环境遵循最小权限原则，不要用管理员账号常驻运行 WorkBuddy。
• 处理敏感文档时，先在测试副本上验证 Skill 行为。

记住：Skill 本质上是一段会被 AI 执行的程序化指令，你给它多少权限，它就有多少能力。安装第三方 Skill 前，把它当作安装一个开源软件包来对待，该审查的审查，该隔离的隔离。

9.3 内网部署与团队分发

企业场景下，Skill 管理建议按下面方式做：

• 维护一个内部 Skill 仓库，使用 git 管理版本变更。
• 提供标准打包流程：目录打包成 zip，校验包内不应包含绝对路径。
• 在目标机器上先解压到临时目录、验证结构，再放入正式目录。
• 如果 Skill 需要模型配合，确认内网模型服务的接口地址、系统提示词和 Skill 的关系，避免出现两层提示词互相冲突。

内网环境调试成本高，尤其要养成“先验证再分发”的习惯。一个 Skill 包在开发机上能跑，不代表在内网服务器上能跑，差异通常出在路径、权限和模型服务地址这三处。

9.4 质量保障与下一步实践

把 Skill 当作产品来对待，而不是一次性脚本。为每个 Skill 写一个冒烟测试提示词：固定输入，检查输出结构中的关键字段是否存在。每周或每次大版本升级后跑一轮回归测试，并记录测试结果。这些方法不需要额外工具，一个共享文档就能做起。

回到开头的判断：模型决定 AI 的下限，Skill 决定 AI 的上限。WorkBuddy 值得花时间研究，不是因为它多了一个花哨的功能，而是因为它让“把能力沉淀下来”这件事变得足够简单。如果你今天只带走一件事，那就是：从自己的高频任务出发，创建一个最小的 SKILL.md，先用纯指令让它给出稳定的输出格式，再逐步加入脚本、示例和版本管理。

下一步建议从三个方向深入：一是把多个 Skill 编排进工作台自动化链路；二是研究复杂 Skill 中脚本与模型的协作边界，什么该让模型判断，什么该让脚本计算；三是建立团队级 Skill 共享仓库，让每个成员都能贡献和消费技能。当 Skill 库积累到一定程度，AI 工具的使用体验会发生质变——到那时候，你会发现自己已经回不到“输入问题、等待输出”的原始阶段了。