prompt-improver

提示词优化器

优化与代码相关的提示词，使其更清晰、优先调查并包含验证步骤。

输入

$ARGUMENTS

---

步骤 1：分析提示词

从以下维度评估输入提示词：

维度	检查内容
任务清晰度	任务类型是否清楚？（实现、修复、重构、审查、测试）是否界定了范围？
调查	是否说明应先阅读并理解，再采取行动？
验证	是否包含适当的检查？（运行测试、构建、lint）
上下文锚定	是否引用了特定文件、函数或模式？
行动具体性	是否明确说明了预期结果？是否陈述了质量要求？
范围控制	范围是否恰当？是否有明确的停止点？

指出输入提示词中薄弱或缺失的维度。

关卡（按顺序执行）

按顺序完成；不得跳过步骤。

1. 审计关卡（步骤 1 结束时）： 通过条件： 后续的“分析”中点明任务类型，并列出表格中每个薄弱或缺失的维度，或明确说明所有维度都已足够，并简要说明你认为已足够的维度。
2. 转换关卡（步骤 2）： 通过条件： “已应用的改进”中列出的每项改进，都对应审计发现的一个缺口（或者在提示词已足够完善时，属于有意强化）。
3. 输出关卡（步骤 3）： 通过条件： 只有在关卡 1–2 通过后，才出现“优化后的提示词”代码块。

步骤 2：应用转换规则

任务清晰度

• 将模糊请求转化为具体的任务类型和范围
• 如果任务类型不明确，添加“实现”“修复”“重构”“审查”或“测试”
• 在可以推断时，指定受影响的文件或组件

调查优先

• 添加“在进行更改之前，阅读并理解[相关文件]”
• 对于 Bug：“先复现并了解根本原因”
• 对于功能：“检查代码库中现有的模式”

防止臆测

• “不要假设尚未阅读的代码结构”
• “使用导入或依赖项之前，先确认它们存在”
• “创建新工具之前，先检查是否已有可用工具”

验证步骤

• 对于实现：“更改后运行测试”
• 对于重构：“确保行为保持不变”
• 对于修复：“验证修复效果并检查是否引入回归”

积极表述

• 将“不要弄坏测试”改为“确保更改后测试通过”
• 将“不要过度设计”改为“实现最简方案”

范围控制

• 缺少明确边界时，补充边界
• 必要时将多部分请求拆分为多个阶段

示例

Bug 修复

Original: "fix the login bug"

Optimized:
Fix the login bug. First, read the authentication-related files to understand
the current implementation. Reproduce the bug to confirm the issue. Identify
the root cause before making changes. Implement the fix and run existing tests
to verify no regressions.

功能实现

Original: "add dark mode"

Optimized:
Implement dark mode for the application. First, check how theming/styling is
currently handled in the codebase. Look for existing color variables or theme
patterns. Implement the toggle and theme switching with minimal changes to
existing components. Run tests and verify the UI renders correctly in both modes.

重构

Original: "clean up the user service"

Optimized:
Refactor the user service for improved maintainability. Read the current
implementation and understand its responsibilities. Identify specific issues
(duplication, unclear naming, tight coupling). Make incremental changes,
running tests after each step to ensure behavior is unchanged.

按任务类型提供的提示

任务类型	提示
Bug 修复	如果已知，请提供复现步骤。说明这是快速修复，还是需要进行根因分析。
功能实现	引用代码库中类似的功能。说明是否需要编写测试。
重构	说明目标（可读性、性能、可测试性）。强调渐进式更改。
代码审查	指明关注领域（安全性、性能、风格）。说明哪些内容无需检查。
测试	指定测试类型（单元、集成、端到端）。引用现有的测试模式。

步骤 3：生成输出

遵循步骤 1 中的关卡顺序（审计 → 转换 → 输出）。按以下确切格式生成输出：

分析

[用 2–3 句话说明提示词类型、薄弱或缺失的维度，或者说明所有维度为何已足够]

已应用的改进

• [列出具体应用的转换]

优化后的提示词

[The improved prompt, ready to copy and use]

针对此提示词类型的提示

[根据“按任务类型提供的提示”表格，给出 1–2 句相关提示]