你在 Prompt 和 Skills 设计上有哪些实践经验？

核心回答

下面以代码审查 Prompt 与 Skill 的迭代给出一份实践答法示例。

我会先把任务、必要上下文、边界和输出写进 Prompt，反复使用的检查顺序、严重程度与报告模板再沉淀成 Skill。我的重点是让每条规则能对应一种具体失败，而不是让提示词看起来更长、更专业。

例如初版只有“全面审查并给出建议”，容易把风格偏好当成缺陷，也容易看到检查命令失败就断定代码有错。我会把问题标准改为“说明触发条件、行为影响和代码依据”，补一组真实缺陷与纯风格意见的对照例子，并增加“先区分断言失败与环境失败”的判断。

实现分工上，我整理技能触发描述和正文，把严重程度长说明放入参考文件，把字段与格式等确定性检查交给脚本。随后固定模型、输入和工具条件，对照漏报、误报、格式错误与工具成本，检查新规则有没有解决原问题并导致其他退化。没有对照数据时，不给出提升比例。

Prompt 与 Skill 怎样分工

一次性需求写在当前提示词，例如只审查指定提交、重点看空输入。长期都适用的项目约定放在宿主支持的项目规则中。只在审查任务中需要的严重程度标准、检查顺序和报告模板放进 Skill。

这样主提示词不会携带所有专业细节，命中任务后再加载正文和必要资源。AgentScope 的技能注册和 Deep Agents 的技能中间件都体现这一思路；具体目录扫描、显式调用和权限字段依实现而异。

把一次失败改成具体规则

假设审查结果出现两类问题：把命名偏好写成高危缺陷；看到测试命令失败，就断定业务代码有错。相应调整可以是：

1. 收窄问题定义。 输出项需要包含发生条件、受影响行为和代码依据；纯风格意见不进入缺陷列表。
2. 分开观察与结论。 命令失败先判断是测试断言失败，还是依赖、环境或命令入口问题，再决定能否归因于本次改动。
3. 加入一对对照例子。 给一个确实越界的循环及问题说明，再给一个只是不合个人风格的实现，展示为什么后者不报告为缺陷。
4. 确定性校验交给程序。 必填字段、文件位置格式等由脚本或结构校验处理；语义正确性仍需结合代码审查，格式通过不能证明结论正确。

这些变化分别解决判断范围、错误归因、输出粒度和格式稳定性。它们不要求把所有场景都写成禁止清单；规则过多或冲突时，反而应删除无效内容。

怎样组织回归

保留正常、边界、已知失败与不应触发的输入，分别保存期望判断。对比改动前后同一批任务，并在模型或工具定义变化后再检查。触发准确但报告失真，优先调整正文、工具反馈或上下文；触发就错了，先改技能描述或发现配置。

可记录问题误报与漏报、人工修改量、结构错误、总耗时及工具调用次数。没有对照数据时，描述规则与验证方法即可，不预先承诺提升比例。

追问

Prompt 越详细越好吗？

要看新增信息能否减少当前失败。清楚的默认路径和必要反例有价值，重复常识、互相矛盾的要求和不相关背景会增加成本。

为什么不让模型自行评判所有结果？

模型评判可以辅助语义检查，但与生成模型可能共享盲点。结构校验、真实命令结果和业务对照数据应独立保留，关键结论再结合人工判断。

对应教程

参考资料