提示词技能何时有效：小样本对照实测

请求只有一句话，AI 写出的提示词往往能读，却未必能用：客户身份怎么核验，例外由谁批准，外部文本里的指令该不该执行，这些规则可能根本没写进去。作者做的 prompt-engineer，就是先追问这些缺口，再起草、自查和修补提示词。

作者拿它与未加载技能的 Claude（Opus 5.5）对比，得到的结论很克制：需求简短、输入不可信时更有帮助；需求已经完整时，收益很小。更有意思的是，他们最后把五个 agent 的流程砍成了一个技能文件。

为什么五个 agent 最后只剩一个技能文件

作者先测试了五个 agent 合写提示词。每份耗时 15–23 分钟，花费 3.81–5.52 USD。两个请求各跑一次后，模型盲评给出的分数是：五 agent 为 7.75/10，单 agent 为 7.83，写作者搭配独立红队为 8.12。

红队负责找漏洞，但分数更高还不足以证明值得保留。

后续测试覆盖 18 次运行、108 个预埋缺陷，共 30 种。没有独立红队的早期开发版也找全了缺陷，与红队相同；发布版则找到 107/108。去掉红队后，每份成本从 0.73–0.78 USD 降到 0.42–0.50 USD，耗时从 165–170 秒降到 92–96 秒。

负责联网查最新指导的研究 agent 也被删除：不带它，35/51 个会话通过，约 69%；带上它，65/101 通过，约 64%。差异不显著，省掉它却能把成本降到一半或更低，并缩短时间。

增加角色不等于增加效果，每一步都得证明自己值得花钱。

最终留下的流程很短：提出几个附带默认值的问题，写简短规格和草稿，再分别模拟目标模型、粗心用户和恶意用户来检查，修复发现的问题。平均每份成本为 0.39–0.45 USD，耗时 71–104 秒，包含提问环节；真人作答所花的时间仍需另算。

收益来自补齐规则，还是更会写提示词

最能说明问题的是需求完整度对比。

作者让没见过该技能的 agent 编写十二类请求，用 83 个输入，在每个写作者的两份提示词上测试。面对只有一到三句话的请求，技能组的 166 次运行通过率为 92%，未被要求先提问的 Claude 为 49%；十二类中，技能在八类更好，其余没有更差。

请求完整后，结果变成 96% 对 97%。

这支持一个更具体的解释：技能的重要价值在于把缺失的业务约束问出来，而不是把已经清楚的需求重新包装。

另外两组测试是带订单工具的客服机器人和意大利语编辑助手，共 17 个任务场景，每种写作者、每个案例各生成六份提示词。只给技能一句话请求时，它比拿到完整笔记的 Claude 高 18.6 个百分点，主要差距来自 Claude 在三个场景里要求客户额外提供一次不必要的身份证明。但逐场景比较是八胜、四负、五平，差异不显著。

当 Claude 也被要求先提问，技能的优势缩到 6.3 个百分点，同样不显著，成本几乎相同；技能生成的提示词则少了 29%–38% 的词数。

对日常使用者，这个对照很实用：先试着要求模型澄清缺失规则，可能已经接近专门技能的收益。

外部文本里的指令，为什么值得单独测

提示词注入（prompt injection）指的是：本来应该作为处理材料的文本，夹带了要求模型改变行为的指令。编辑助手尤其容易遇到这种边界问题，因为它必须阅读用户提交的原文。

在意大利语编辑助手的测试中，预埋指令被服从的次数分别是：

• 技能生成的提示词：0/41。
• 拿到完整笔记的 Claude：9/42。
• 被要求先提问的 Claude：5/40。

这个结果比「文字写得更专业」更有意义。它检查的是提示词能否守住任务与输入材料之间的界限。不过，0/41 只能说明这批会话没有失守，不能保证其他攻击也无效。

原文提供了 Claude Code 的安装命令，用于添加 marketplace 并安装技能：

/plugin marketplace add HighMarck17/prompt-engineer
/plugin install prompt-engineer@prompt-engineer

注意第二行的 prompt-engineer@prompt-engineer 是完整安装标识。claude.ai 用户则使用最新 release 中的 zip，项目采用 MIT 许可。

我的判断

我认可作者先做减法的思路，也认可把业务规则和输入边界放在文案润色之前。对客服这类任务，多问一次身份凭证不只是措辞问题，它会直接改变流程。

但这些数据还不足以证明该技能普遍优于 Claude。五 agent 对比只有两个请求、各跑一次；评分者是模型；两个 agent 案例还参与过技能开发；回答澄清问题的负责人也是模拟的，真人未必答得那么充分。

因此，92% 对 49% 更适合解读为「这套流程在简短需求测试中有效」，不能直接外推到任意团队。对于完整需求，96% 对 97% 已经提示了收益边界；对于先要求 Claude 提问的替代做法，作者也没有得到显著优势。至于长期维护成本、真人配合程度，原文没说清。

能拿来做什么

• 给客服、编辑类助手写提示词时，先列出必须确认的规则，并为澄清问题提供默认选项，让负责人能逐项纠正。
• 在日常 AI 编程中遇到需求过短，可以先要求模型指出缺失约束并提问，再观察是否还有必要引入专门技能；原文没有验证代码生成收益。
• 对需要读取外部文本的助手，加入夹带指令的测试材料，检查模型是否会把待处理内容当成命令执行。
• 优化自己的 agent 流程时，固定任务逐步删除研究、审查等角色，同时比较通过率、成本和耗时，别只凭流程看起来更完整来判断。