关于 enhance-prompt
enhance-prompt 是用于分析、编写和改进大模型提示词及 Agent 指令的技能。它依据 token 使用、确定性、祈使表达、格式和常见反模式等原则处理内容，并在收到输入时仅返回改进后的提示词。
主要功能
- 01分类提示词相关请求
- 02分析现有提示词并收集需求
- 03应用 token、清晰度和格式原则
- 04仅返回改进后的提示词
适用场景
- 01修改现有系统提示词
- 02起草 Agent 技能指令
- 03参考提示词工程原则
安装
复制下面的命令，在终端中运行。
npx skills add https:/安装后在 Claude Code 中输入/enhance-prompt确认已加载。
详细介绍
提示词增强
分析、编写并改进大模型提示词和 Agent 指令。将这些原则应用于系统提示词、Agent 指令、技能、CLAUDE.md 文件、规则、斜杠命令以及任何大模型提示词。
工作流
收到输入时：
- 分类请求：确定输入是待审查的提示词、提示词编写需求描述，还是一般性的提示词工程问题
- 分析：对于现有提示词，找出违反以下原则之处。对于新提示词，收集需求
- 应用原则：应用 Token 经济性、确定性、祈使语气、格式和反模式检查
- 生成输出：仅返回增强后的提示词
输出格式
仅返回增强后的提示词。不添加前言、违规说明、评论或解释。整个回复应为改进后的提示词，可直接复制粘贴。
未提供输入时，将以下原则作为参考指南。
Token 经济性
上下文窗口是共享资源。审视每条信息：“模型是否已经知道这点？”只补充模型缺少的上下文。假设模型具备较强的基础能力。
删除修饰性语言。不要使用“请”“记住”“务必”“这很重要”。
用示例代替解释。一个具体的前后对照示例胜过三段描述。
结构化数据优先使用表格。将相关信息压缩成便于浏览的格式。
确定性和具体性
自由度
根据任务要求调整具体程度。
高自由度（文本指令）：适用于存在多种有效方法的情况。中自由度（伪代码、参数化脚本）：适用于存在首选模式的情况。低自由度（精确脚本、无参数）：适用于操作脆弱或一致性至关重要的情况。
消除歧义
每条指令都必须只有一种解释。
使用明确的约束，而非建议。“运行 pytest tests/ --strict-markers”，而非“适当时使用严格标记运行测试”。
完整说明条件。“在 API 边界验证输入”，而非“验证输入”。
删除表示不确定性的词语：“考虑”“尝试”“尽可能”“通常”“经常”。
确定性命令
包含所有标志和参数。使用 dotnet test --logger "console;verbosity=detailed"，而非 dotnet test。
使用绝对路径或范围明确的路径。使用 /src/api/、src/**/*.ts，而非“API 代码”。
行为因版本而异时，注明工具版本。“Node.js 20+：使用原生 fetch”，而非“使用 fetch”。
祈使语气模式
仅使用祈使句。“在边界处验证输入”，而非“你应该在边界处验证输入”。
使用祈使语气编写直接指令。
正确：“在 API 边界验证输入” 避免：“你应该考虑在 API 边界验证输入”
优先使用肯定指令，而非否定指令。使用“让异常继续传播”，而非“不必要时不要捕获异常”。
约束的具体性
明确说明禁止事项和要求。
正确：“不要在后台任务中实现重试逻辑” 避免：“避免防御性模式”
面向大模型解析的格式
使用有助于大模型理解的 Markdown 结构。
| 格式 | 用途 |
|---|---|
| 标题 | 确立上下文和范围边界 |
| 列表 | 列出离散、并列且相互独立的条目 |
| 代码块 | 呈现精确值、命令、标识符和模式 |
| 表格 | 展示结构化比较、参考数据和决策矩阵 |
| 粗体 | 标记违反后会导致失败的硬性约束（最多占内容的 10%） |
| 正文 | 说明概念之间的关系、条件逻辑和理由 |
| 空白 | 在段落和章节之间留空行，便于解析 |
强调和术语
强调修饰语
仅对违反后会导致失败的硬性约束使用 MUST、MUST NOT、REQUIRED。
不要用修饰语表达偏好或默认做法。如果每条指令都使用 MUST，就没有重点可言。
术语一致性
每个概念只选用一个术语，并在全文中保持一致。
推荐：始终使用“API endpoint” 避免：交替使用“API endpoint”“URL”“route”“path”
结构优化
优先列出关键约束。最重要的信息放在文件开头。
逐步细化。先列出全局规则，再列出领域专属规则，最后列出文件专属规则。
清晰划分主题。每个主题单独成节。不要将测试规则与部署流程混在一起。
明确结束各节。结尾不要使用“等等”或“以及更多”。
常见反模式
语言反模式
建议式措辞：
- 避免：“考虑使用 async/await”
- 推荐：“对 I/O 操作使用 async/await”
模糊的量词：
- 避免：“通常验证输入”
- 推荐：“在 API 边界验证输入”
含糊的条件句：
- 避免：“适当时添加日志”
- 推荐：“记录错误及其堆栈跟踪。对于预期的控制流，不要记录日志。”
未指定默认项的多个选项：
- 避免：“使用 Jest、Vitest 或 Mocha 进行测试”
- 推荐：“使用 Vitest 进行测试。旧文件可以使用 Jest。”
结构反模式
将关键约束埋在内容中：
- 避免：先写很长的引言，再在中间提及关键要求
- 推荐：先列出关键要求，必要时再补充背景
过度强调：
- 避免：每 个 词 都 加粗
- 推荐：仅对违反后会导致失败的硬性约束加粗
默认使用列表：
- 避免：所有内容都格式化为项目符号列表
- 推荐：离散事项使用列表，关系说明使用段落
内容反模式
重复框架文档：
- 避免：“React hooks 让你可以在函数组件中使用状态和生命周期……”
- 推荐：“将表单状态存储在 URL 参数中，而不是本地状态中”
泛泛的最佳实践：
- 避免：“函数应该简短且专注”
- 推荐：“API 处理程序仅负责路由。将逻辑移至 services/”
时效性信息：
- 避免：“2025 年 8 月之前，使用旧版 API”
- 推荐：“使用 api.example.com/v2/ 上的 v2 API”
装饰性内容：欢迎词、励志陈述、背景历史。
假设性场景：“如果我们将来迁移到 Postgres……”等到实际发生时再处理，不要讨论假设情形。
优化技巧
句子精简
删除填充语：
- 优化前：“提交更改之前，你应该确保始终运行测试套件”
- 优化后：“提交前运行
pytest”
合并相关指令：
- 优化前：“使用 TypeScript。添加类型注解。启用严格模式。”
- 优化后：“使用启用严格模式并添加显式类型注解的 TypeScript”
命令规范
完整规范：
## Commands
- `pytest tests/ --strict-markers --cov=src --cov-report=html`: Run tests with coverage
- `dotnet build --configuration Release --no-restore`: Production build
- `npm run lint -- --fix`: Auto-fix linting issues
不要这样：
## Commands
Run pytest to test. Use dotnet build for building. Lint with npm.