核心用法
Error Message Improver 是一个面向应用开发者、SaaS 运营团队和技术支持人员的诊断增强技能。其核心工作流包含六个步骤：首先重述用户的目标、约束和成功标准；其次创建简洁的工作计划或模板；仅在关键信息缺失时询问补充，其余情况合理假设并继续；优先采用本地硬件友好的方案（脚本、模板、清单、CPU 安全的小模型）；交付定制化的制品或分析；最后验证输出并标注风险。
该技能接收模糊或技术性过强的原始错误信息，输出包含「什么失败」「为何失败」「下一步行动」三要素的结构化改进方案，可直接嵌入产品界面或支持文档。
显著优点
需求验证充分：基于12项跨3个来源族的在线信号，非孤立需求，需求评分100/100，本地可行性评分30/30，具有明确的市场验证基础。
输出即行动：不同于泛泛的建议，该技能强制要求产出可立即执行的制品——代码片段、检查清单、决策流程图或自动化脚本，用户无需二次加工。
硬件亲和：明确偏好本地脚本和小型模型方案，降低对云服务依赖，适合安全敏感或网络受限环境。
触发词覆盖全面：涵盖 productivity、debugging、user feedback、support 等高频场景，便于在对话中自然调用。
潜在缺点与局限
依赖用户输入质量：若原始错误信息极度匮乏，技能需大量假设，可能产生偏离实际的改进建议。
领域特异性不足：作为通用框架，对特定技术栈（如某云厂商专有错误码）的深度优化需人工补充。
验证机制待明确：简介中「验证输出」步骤缺少具体量化标准（如可读性评分、行动完成率），实际效果依赖执行者经验。
适合的目标群体
- SaaS 产品经理：需统一产品错误体验，降低客服工单量
- 开发者体验工程师：优化 SDK/CLI 的错误反馈设计
- 技术支持团队：快速生成标准化故障排查话术
- 开源维护者：改善社区 issue 响应效率
使用风险
- 假设累积风险：连续默认假设可能导致方案偏离用户真实环境，建议关键假设显式列出并要求确认
- 本地化限制：当前框架未明确多语言错误信息的优化能力，国际化产品需谨慎评估
- 维护负担：生成的检查清单和模板需随产品迭代同步更新，否则成为过时文档
- 性能边界：虽声明 CPU 友好，但复杂日志分析场景若未做分块处理，仍可能触发长时运行