是否设计开发过 Skill，功能边界与实现方式是什么？

核心回答

下面以代码审查 Skill给出一份项目答法示例。

我设计的是一个审查指定代码改动的 Skill，输入是一份 diff 和相关文件，输出是包含文件位置、触发条件和影响的问题清单。我负责把审查顺序、问题严重程度和输出规则整理成 SKILL.md，把长说明放进 references/，把可重复的格式与静态检查放进脚本。

执行时，宿主先根据技能名称与描述判断是否命中，加载正文后，Agent 再读代码、追调用链、运行必要检查并整理结论。我划定的边界是“找有依据的缺陷”，普通代码解释不触发这套审查，也不自动修改代码或提交。

一个需要处理的失败是：只有“全面审查”这类要求时，输出容易把命名偏好也当成缺陷。我将规则改成“每个问题说明发生条件、影响及代码依据”，加入真正缺陷与纯风格意见的对照例子，再用正向、隐含触发和不应触发的任务检查。评估同时看漏报、误报和工具成本，不以输出更多问题作为效果更好的依据。

从任务边界落到实现

先把输入限定为一个改动范围，例如一次提交的 diff 和相关文件；输出限定为“位置、问题、触发条件、影响”。只解释代码含义、仅格式化文档等请求不应自动进入全面审查。

可以采用这样的目录：

code-review/
├── SKILL.md
├── references/severity-guide.md
└── scripts/run_checks.py

SKILL.md 的 description 说明任务动作与输入；正文说明先理解改动目标，再追受影响的调用链，必要时运行已有检查，最后给出问题依据。严重程度的长说明放在 references/，只有判断需要时才读。脚本负责可重复检查，返回退出状态和结构化结果；模型负责判断结果是否与本次改动有关，不能把每条扫描提示都写成确定缺陷。

集成时还要让宿主扫描技能目录，并给 Agent 提供读取说明文件的工具。例如 AgentScope 的技能注册会把技能描述接入提示词，但正文文件仍需要可用的读文件或命令工具访问。目录里有文件，不等于运行时已发现它。

怎样判断设计有效

触发与任务质量分开评估：

• 明确触发：“用代码审查技能检查这次改动。”检查技能是否真正加载。
• 隐含触发：“这个改动会不会在空列表时出错？”检查是否根据任务语义命中。
• 负例：“解释这个函数的作用。”检查是否误跑整套审查。
• 产物检查：准备确有边界缺陷、没有缺陷和检查命令失败的样例，对照问题定位与依据，并记录漏报、误报、额外工具调用和耗时。

如果误触发，先收窄描述；如果已经加载却漏掉问题，检查正文决策规则、上下文和测试入口。升级模型或修改技能后，用同一组样例对照，才能判断变化来自哪里。正式团队复用时再维护版本、依赖与回滚入口，避免用户得到不同版本的隐含规则。

追问

所有内容都能写进一个大 Prompt 吗？

可以，但不同任务每次都携带全部说明，会增加上下文成本和维护冲突。Skill 的价值是独立组织、按需加载与复用；一次性要求通常留在当前提示词即可。

技能里写了“只读”是否足以限制修改？

不足以。说明约束模型行为，实际写权限仍应由工具、沙箱和宿主策略控制。审查型技能通常只需要读权限，是否允许运行脚本也应由执行环境限定。

对应教程

参考资料