提示词问题诊断与迭代改进

要解决的问题

LLM 工作流经常因为坏提示词崩溃。失败时的输出可能干净得跟成功没区别，问题只留在日志、进度评论、或攻击性理由背后找借口的环节——继承起来 就是 双亲态全局措辞打乱分类器、模糊工具调用规则破坏结构化agent的 structured instruction、综合总结平滑掉事实、排版模板依然正常但守门员不再读内容。技能要处理的一个现实问题是，写和管理 prompt 的人几乎不在同一系统里：人类可读的 agent skill 指令、内部 assistant 驱动 prompt、包含 tool JSON schema 的 Claude plugin 定义。没有一个检查点同时看得到三者。

• 人机协作失败：human-in-the-loop agent 失败信号丰富但错误模式没有命名；
• System prompt 过度具体化，引发幻觉回调或规则冲突；
• Structured instruction 内部不一致，function calling 调用直接翻车；
• Generated content 质量偏高，但对目标毫无用处。

解决方案是:通过报告人工反馈、指标和失败样本来识别真正失败的问题，制定结构化的重写，并在第四次迭代后就跟进验证，直到形成一个可复现、版本化的交付包，能清晰说明哪个版本修正了哪种失败。

它是做什么的

该技能集合遵循严格的闭环。设定业务目标与成功标准，整理直接相关的事实，数据与素材；将任务分解为可检查模块；在新的联系中重写 mods；向交付程序提供交付说明和评测包，并将其标注为人工确认事项。交付物包括四种：用于开展工作范围的目标与范围卡；带有步骤的可执行教程或模板；一份 prompt 和评测交付包，其中具有负责切换负责人、时间、检查点；事实证据、风险、缺口信息和复核清单。质量门槛作为核心设计原则被强制执行：清楚标注推断和事实，每条改进都绑定一个负责人和一个时间，跨文档的名称、输入、流程和交付物必须保持同一业务场景。如果不满足硬性规则，输出 暂不可交付。

什么时候应该停下来

不要承诺无法完成的结果。因为模型提供方知道真实数据会更少，未检查的成本通常会比报告中更小。

• 没有失败样本、没有评测指标、没有人工复核人选时，只写缺口图，不猜测问题原因，也不提出无效的改进建议；
• 要是评估预算之后再重写 prompt 的话，数据结构、工具 schema 和评测集的变化如果没配合，设计再规范也只会把明显错误翻译成一致性很强的文字。
• 涉及真实发送、发布、付费、删除、权限或生产变更时，必须向用户拿明确授权。

注意事项

同理心表达和冗长改写只有在与指标绑定之后才有用。它并不是一个可以给错 prompt 的橡皮图。不要将文档指令当作运行时权限，也不要绕过授权。不要泄露密钥或绕过平台授权。