可直接喂给 WorkBuddy 的实战模板 | 零基础构建策划团队 Skill

原创

腾讯程序员
腾讯程序员

腾讯技术工程

2026年11月5日 17:33
广东

去阅读

作者：finnxwang

丨 导语  不会写代码，也能搭出好用的团队共享 Skill 和知识库。笔者整理了搭建、迭代和团队协作的实战经验，包含完整的起步与迭代流程。把本文交给你的 Agent，再补充自己的业务材料、可用工具和权限，就能按文中的方法，从零开始搭建和完善自己的工作 Skill。

一、从口口相传、机械配表，到可以复用的团队经验

最初建这个 Skill，我是想减少重复配表的工作量，也减少遗漏和返工。我所在项目的策划案和配置规则经过多轮迭代，很多判断需要反复确认：先查哪份数据，哪些字段要一起改，遇到什么情况要找人确认，改完又怎样验收。这些经验分散在文档、历史任务和个人记忆里。同事换个问题来问，我要再解释一次；新人接手，又要从头讲一遍。而某个数改对了，并不代表相关配置都改对了，问题往往到后续才暴露。所以我希望做的不只是替我改表的工具，而是把查、改、验组织成一套可复用的流程。我把 Skill 理解为一份组织起来的大 Prompt，再加上工作流程和资料。真正理解和执行任务的仍然是 Agent，Skill 提供方法，工具提供操作能力，权限决定可以做什么。更多基础知识网上已有很多介绍，这里不再赘述。

在搭建和迭代过程中，我把这个 Skill 推广给全组的策划同事使用，现在同组的策划同学已普遍用它指挥 Agent 干活。因此，我也积累了一套零代码基础搭建 Skill 的经验。这里不过多讲解我们数值配置 Skill 的具体内容，而是将思路和方法分享给同样没有代码基础的产品、策划、运营等 P 族同学。

没有代码经验，有时反而是优势——注意力会更多放在实际操作和业务结果上。当然，零代码基础不等于不需要代码：涉及脚本时，可以让 AI 协助实现，但业务规则仍要由人确认，脚本也必须经过测试，确保合理、可用。

这篇文章可以直接复制给你的 Agent 阅读学习。它可以据此梳理必要输入、生成初版、检查已有 Skill 的问题，并组织验证和回传。后文给出了完整示例和测试用例，但自己的业务材料、平台安装方式、工具和权限仍需要你补充。下面以我从设计到配置再到验收的工作为例，说明这套方法如何落地。

二、总体架构：路由、知识、执行、验证四层职责

2.1 四层各自解决什么问题

一次配置任务的主线如下，知识层为执行和验证提供同一份依据：

用户需求 → 路由层：确认任务、对象、范围
                    ↓
           知识层：提供规则与来源
                    ↓
           执行层：按流程查询或修改
                    ↓
           验证层：对照要求检查结果
                    ↓
           交付结果；新发现进入回传流程

这四层是职责划分，不意味着每个任务都要跑一遍完整流程。只问一个规则时，路由到知识层就够了；需要批量改动时，才进入完整的执行和验证链路。

2.2 文件怎样组织

我的配置 Skill 将这些职责分别放在入口、专题、工具和验证资料中。下面是目录示意：

config-skill/
├── SKILL.md          # 入口：任务识别、路由和必要约束
├── README.md         # 使用方法、版本、依赖和能力说明
├── references/       # 专题知识：数据来源、业务规则、操作说明
├── registries/       # 需要机器读取的规则或登记数据
├── scripts/          # 查询、处理、自检和校验工具
├── tests/            # 脚本和规则的回归测试
└── governance/       # 变更记录、候选知识和回传规范

这是逐步完善后的组织方式，不是入门时必须建齐的目录。将内容拆开，是为了让入口保持简洁，同时让规则和工具能够各自维护。例如字段口径变了，优先修改知识层；查询工具换了，主要改执行层。如果工具变化也影响权限或验收方式，相关层仍要一起调整。

三、四层架构设计要点

3.1 路由层：先识别任务，再决定怎么做

“查一下这条配置”和“检查这批配置对不对”都包含“配置”，但前者是查询实际内容，后者是对照期望进行核查。路由层要识别的是意图，而不只是关键词。我们的配置 Skill 会先确认对象、范围、依据和授权，再选择问答、查询、修改或核查流程；已有信息直接复用，缺失信息集中确认，不沿用其他任务的材料。

入口描述写清适用与不适用场景，再按任务指向相关专题；知识未覆盖到的内容明确说明，不宣称已经支持。这个思路同样适用于需求整理、方案核对和运营报表：先明确要完成什么，再决定读取哪些知识、调用哪些工具，以及怎样验证。流程的轻重取决于影响范围和错误成本，不必让每个任务都走完整链路。

3.2 知识层：判断有来源，更新有归属

知识层不仅记录字段含义，还要说明数据来源、应当修改的源头、关联关系和业务口径。我们的做法是按需读取专题知识，并为结论保留证据来源、验证状态、约束性质、适用版本和核实时间。“大家一直这么做”是惯例，不自动成为系统硬约束；某次任务成功，也不代表其中的做法适用于所有场景。

已确认的规则统一维护，执行和检查共用，其他位置通过引用使用。新发现先作为候选，规则冲突交由负责人确认，不静默覆盖正式结论。工具提取的数据和人工审核的解释也要区分，查到一个值不等于理解了它的含义。无论是运营指标口径还是产品审批规则，更新后都要检查相关入口、示例和测试是否仍然一致。

3.3 执行层：把规则变成可重复的工作流

我们的配置 Skill 把理解需求、选择专题交给 Agent，把查询、查重和格式检查等固定操作交给工具。可迁移的分工是：模型处理需要理解和判断的部分，有明确规则的匹配、计算和格式处理尽量交给工具或脚本，同时写清输入、输出和失败时的停止条件。并不是每个 Skill 都需要脚本，关键是不让同一套规则每次都被临场重新解释。查询先限定来源和范围，缓存与摘要只帮助定位，重要结论回到原始依据核对；没查到也要说明已查范围。涉及修改时，先确认授权、保护原内容，再做获准的最小改动并回读结果；保护的不只是文件，也包括已确认的方案和审批状态。实践中发现的错误补成检查点或失败用例，让经验进入下一次流程，而不只留在对话里。

3.4 验证层：独立核查结果

验证层要在执行前定义成功标准，执行后用实际结果对照预期。我们的配置 Skill 区分格式、规则、业务关联和最终使用效果，不把文件能打开当成业务正确；配置 Skill 负责修改和写后自检，检查 Skill 负责对照期望核查结果。

其他业务不一定要拆成两个 Skill，但也应区分生成、修改和核查。独立验证的重点不是换一个模型，而是重新读取原始依据：能计算的重新计算，能查来源的回查来源，需要负责人判断的明确标出。小任务做必要核对，批量或高风险任务按确认范围完整检查。输入是否齐全、输出是否符合目标、结果是否真正落地，都要分别说明；脚本测试、材料推演和业务验收不能互相替代，未检查的部分明确标为“未验证”。

四、从真实任务到第一个 Skill（内含模板）

4.1 先说清任务，再开始搭建

搭建 Skill 前，可以先拿一个真实任务，把需求说清楚。高质量 Prompt 的核心是：目标明确、边界清楚、输入完整、规则可执行、输出要求明确，并有自检闭环。这些信息不仅决定一次任务能否做好，也是后面提取 Skill 规则的基础。

对没有代码基础、也不熟悉提示词写法的同学，我觉得 WorkBuddy 的增强提示词功能是一个好用的起点。它能辅助整理任务描述，让我们不必完全从空白开始组织表达。下面是同一次输入增强前后的示意，大家可以在自己的任务中尝试：

增强前：

增强后：

不过，增强后仍要检查是否保留了原意，有没有加入自己并未提出的要求。我也在 AgentLens 中查看过这项功能的增强指令。

任务说清楚后，再把本文交给 Agent，让它依次完成以下步骤：

1. 确认业务任务。

明确给谁用、做什么、输入在哪里、产出是什么，并让你提供一次人工完成的样例。
2. 提取判断与边界。

从样例中整理步骤、依据、例外和停止条件。缺少的业务口径集中问清，不从示例数字推导通用规则。
3. 组织最小初版。

写清入口、必要资料、执行步骤、输出要求和回传。按实际需要建目录，不要求一次建齐四层的全部文件。
4. 补齐工具前提。

记录可用工具、输入输出、失败处理和验收方法。脚本可以由 AI 生成，但在样本中运行并核对前，只能标为待验证工具，不能挂进正式写入流程。
5. 先试用，再扩大范围。

先在只读材料或副本上验证正常、缺失、冲突等情况。确认后再接入真实写入；记录初版版本、测试结果和已知限制。

安装目录、加载方式以所用平台的说明为准。SKILL.md 的名称与描述帮助 Agent 发现和选择 Skill，但“文件已生成”和“宿主实际加载成功”是两件事。验证时要看可获取的加载记录；看不到记录，就注明触发行为尚无法确认。

4.2 一份可直接改造的 Skill 初版

下面以“活动配置核对”为教学示例：只核查，不修改，没有项目专属数据。假定已经准备好一份正式规则文档和待核对材料。代码块中是完整的 SKILL.md 初版；旁边只需先补一份 references/activity-rules.md，写明来源、字段含义、关联规则及未确认项。

---
name: activity-config-review
description: >
  对照已确认的活动规则，核对用户提供的活动配置，输出差异及待确认项。
  适用于活动配置核查；不用于设计奖励数值、修改源文件或发布活动。
---

# 活动配置核对

## 任务与必要输入
- 必要输入：待核对材料、核查范围、已确认的规则或预期。
- 用户只问规则时，读取专题回答，不要求配置文件。
- 用户要核对配置时，读取实际材料，与期望逐项对照。
- 已提供的信息直接复用；缺少材料或口径时集中提问。

## 知识入口
- 读取 references/activity-rules.md。
- 只将适用版本已确认的规则用于确定性判定。
- 材料缺失时说明缺什么，不自行生成业务规则。

## 执行步骤
1. 确认本次对象和范围，不沿用其他任务的材料。
2. 列出核查项及每项的预期值、来源，歧义先确认。
3. 只读材料，逐项记录实际值与关联关系。
4. 用真实值对照预期；无匹配项时说明已查范围。
5. 汇总明确差异、待确认项及未执行检查。

## 行为边界
- 可以做：读取获准材料、按已确认规则核查、列出差异。
- 需要先问：材料缺失、规则冲突、期望不明确、需扩大范围。
- 不做：猜测空值、修改源文件、自行设计奖励、自动发布。
- 原因：核查是发现差异，不是代替业务负责人作决策。

## 输出与验收
输出：核查项｜依据或预期｜实际值｜判定｜建议。
明确差异必须有实际值与预期；不能判定的单列，不猜结论。
说明哪些检查已执行，哪些未执行；不将静态核查称为活动生效验证。

## 回传
发现新规则或旧说明有误时，按下列字段整理草稿，交用户审核。
- 发现、任务场景、Skill 版本
- 期望与实际、处理建议、证据及验证状态
- 适用范围、共享检查、当前收录状态
只整理，不自动修改共享规则或外发。

这个版本可以先用于材料核对，不依赖额外脚本。业务扩展后，再引入读取和校验工具；如果工具不可用，就说明限制，不能把“计划调用”写成“已经执行”。

4.3 用四类输入检验初版

初版至少准备以下四类测试。它们也是修改后的回归用例，不应每次只挑最顺利的样本测试。

每次保存输入、预期、真实输出和判定依据。仅列出测试方法不算测试完成；没有实际运行的项目标为“未执行”。如果新增脚本，还要在副本上核对读写范围、异常处理和结果，再允许进入正式流程。

换到周报、产品需求检查等场景时，由 Agent 替换业务输入、规则、风险和验收项，不能照搬本示例的“活动”或配表流程。

五、团队一起持续优化：按问题改层，而不是不断打补丁

5.1 找到失效的位置

我们维护配置 Skill 时，逐渐形成的做法是：记录失败样本，先判断问题属于哪一层，再修改相应内容。不要每次出错，都在入口追加一条“必须注意”。

这些是已经采用的改进方向，不意味着表中每项都已有量化收益。脚本能检查的项目，依据真实测试结果说明；模型是否更容易正确选择流程、同事是否更省时，则需要另外评估。我们的模型对照评估已有规格，但尚未执行，不把脚本回归通过当作整体准确率提升。

5.2 优化后怎样判断有效

保留旧版本和失败样本，用相同材料、工具和测试条件比较新旧结果。改描述时看触发，改知识或步骤时看内容，改工具时看工具运行和最终结果。除了复测原问题，还要检查相邻场景，避免修好一个、误伤另一个。效率统计应包含人工补充、等待、复核和返工，不能只算 AI 生成第一版的时间。若只测了入口文件的大小变化，就只报告文件大小变化；没有实际数据，不写提速或准确率百分比。每轮交付记下四件事：改了哪些文件、解决哪类问题、实际验了什么、还剩哪些限制。已经批准的业务规则不因优化而改动；引入新工具、新权限或扩大处理范围时，重新确认。

5.3 利用 skill-creator

下面这段是我维护配置 Skill 时经常使用的审查指令。其中引用的 skill-creator 是 Anthropic 官方提供的 Skill，可以交给你的 Agent 去优化 Skill 结构：

请参考 https://github.com/anthropics/skills/tree/main/skills/skill-creator 中的规范和最佳实践，检查并直接修改当前 Skill，使其更高效、准确、精简，检索更快，并降低新手在自己的 Agent 上使用的门槛。
具体要求：
1. 审查现有技能定义、参考资料和相关文档，识别重复内容、歧义、检索障碍及缺失约束；在保留核心能力和既有业务规则的前提下优化。
2. 明确技能的触发条件、适用场景、必要输入、输出要求和配置校验规则；对于信息不足、配置冲突或超出范围的请求，明确需要补充或确认的内容，避免猜测。
3. 精简无效指令和重复资料，优化信息组织与检索入口，减少无关内容读取，同时保留影响配置正确性的关键规则。
4. 更新 README 及相关说明，明确支持与不支持的能力、使用前提、必要配置、Agent 适配要求和已知限制，区分技能可直接完成的事项与依赖外部工具或人工确认的事项。
5. 用典型配置、边界情况和错误输入验证修改效果；如声称检索提速或准确性提升，应提供实际验证依据，不编造结果。
完成后简要列出修改文件、主要改进、验证结果和剩余限制。若无法访问参考链接或定位现有 Skill，请说明缺失材料并提出必要问题，不凭空假设项目结构。

六、聊聊团队知识库建设难的问题：先让大家用起来，再一起完善

6.1 为什么集中建库很难启动

大家其实都很忙。让每个人先抽出时间，把自己知道的东西整理成完整知识库，很容易变成一个长期没有进展的任务。

也不是所有同事一开始都能看到它的重要性。自己的工作照常能做，整理知识的收益却是以后才出现的；即使整理过一轮，规则变了没人及时更新，文档还是会慢慢失去可信度。

我的做法是先解决一个实际问题，让大家觉得 Skill 好用。先提供能回答常见问题的知识和一个低风险的使用入口，不要求每个人先交一套完整手册。等大家真正用起来，再把使用中的发现带回来。

6.2 人和 AI 一起进化

每个人使用时都会遇到新问题：少了一条说明、某个步骤不适用、现有口径已经变化。过去这些发现常留在聊天里，现在可以让 AI 在任务结束时整理成回传草稿，使用者只需要核对重点，不必从头写文档。

如果你的 Skill 也需要多人使用，最好一开始就写清回传机制：

• 什么时候整理：

发现缺失规则、旧说明有误或可复用的操作经验时，才生成草稿，不是每次都写一份总结。
* 整理什么：

问题、期望与实际、处理方法、原始证据、适用范围和版本。
* 谁能更新：

成员的 Agent 只读整理、脱敏并交用户确认；维护人查重和审核后，再修改共享知识。
* 怎样反馈：

告诉贡献者收录到哪里、哪些仍待确认、共享版本是否已更新。成员本机写过，不等于所有人已经拿到。

一次有效的回传不需要很长，证据不足也不用硬凑。先标为候选，后面补证据；只有个人环境才适用的设置不进入通用规则。涉及未公开内容的证据，仅在项目允许的范围流转，不因为“脱敏过”就可以随意外发。

6.3 组员的回传模板

可以把下面的模板放在 Skill 中，让 Agent 任务收尾时按需填写：

【发现】一句话说明问题或新知识
【类型】新规则 / 旧说明有误 / 踩坑经验 / 能力建议
【场景】任务类型、适用环境、Skill 版本或安装来源
【期望与实际】原本应该怎样，实际发生了什么
【处理】已经怎样解决，或建议修改什么
【证据】原始数据、文档或工具结果；已测试 / 文档来源 / 仅推断
【适用范围】通用 / 特定业务 / 仅个人环境 / 仍待确认
【当前状态】仅在对话中 / 已写入成员本机 / 已合入共享版本
【共享检查】已去除凭据和个人路径；证据流转范围符合项目要求

维护人可以让自己的 Agent 先查重、归类、整理差异，再审核关键规则。这样大家不必先完成一次庞大的建库工程，而是在每次使用里补充一点。对我来说，这也是配表 Skill 最值得留下的价值：具体任务会结束，处理方法可以留下。下一位同事使用时，就能少花一些从头摸索和反复沟通的精力。

最后

笔者也是代码和 AI 小白，文章比较浅显，也有很多不足之处，还请大家多多谅解，也欢迎指正。我之前在 CodeBuddy 搭建，后来因为工程中经常需要用到 TAPD、工蜂、iWiki 等工具，就转移到了 WorkBuddy（现在各类连接器和功能做得确实很好，实名夸一下辛苦迭代的同学们）。

现在，没有代码基础的人也能借助 AI 编写代码、实现工具，这是一件很了不起的事情。AI 能力不断进步，但这不代表我们不需要学习了。

我在优化这套 Skill 的过程中收获了很多，也对项目流程、工作流优化和 AI 工具有了更多思考。我觉得，思考并提出问题，是这个时代最宝贵的能力，出题远比答卷更重要。