improve

改进

通过迭代改进任意输出，直到满足所有标准——每一步都进行评分评估，让“更好”不再取决于主观判断。

模式选择

根据任务涉及的独立维度数量选择模式。这一点很重要：对简单请求强行执行完整循环会浪费时间，而复杂任务若缺少结构，则会导致改动漫无目的。

快速模式

当改进由一个明确维度主导时使用，例如“让这个函数更快”“缩短这段文字”“修正格式”。用户的请求本身就意味着只有一个标准。

1. 明确标准 — 明确说出标准，即使它看起来显而易见（例如：“目标：缩短执行时间”）
2. 阅读并理解 — 对于代码，阅读文件；对于文字，阅读文本。不要在未读内容的情况下进行改进。
3. 进行改进 — 只做一项有针对性的改动
4. 展示改动前后 — 对于代码，提供差异或并排对比；对于文字，指出改动内容及原因。
5. 确认效果 — “这样符合预期吗？还是需要我继续改进？”

升级： 如果用户说“继续”或提出第二个关注点，则切换到完整模式。将当前标准作为第 1 项保留，添加新标准，并将当前输出评为第 0 轮迭代。不会丢失任何工作。

完整模式

当任务涉及 2 个或更多独立维度、存在相互冲突的权衡、用户请求含糊不清（“整理一下”“改得更好”），或用户明确要求迭代优化时使用。

1. 接收输入
2. 确立 1–3 项按优先级排序、可衡量的标准
3. 评估基线（第 0 轮迭代），然后迭代改进——每轮只聚焦一个目标
4. 每轮：改进 → 评分 → 与用户确认 → 决定（继续／停止）
5. 提供包含完整迭代历史的最终输出

领域提示

不同类型的输出有不同的改进模式和工作流程。思考在具体情境下“更好”意味着什么以及如何进行改进时，可以将以下内容作为起点，而不是僵化的规则。

代码

维度： 可读性、性能、正确性、测试覆盖率、惯用风格
工作流程： 先阅读代码 → 找出具体问题 → 进行改动 → 展示差异 → 如有测试则运行。对于性能改进，说明复杂度变化（例如：O(n²) → O(n)）。对于可读性，说明新版本为何更清晰。

文本

维度： 清晰度、简洁性、语气、结构、受众适配度
工作流程： 阅读全文 → 找出结构或清晰度方面的问题 → 修改 → 指出改动内容及原因。若目标是精简内容，则展示修改前后的字数。

数据／配置

维度： 正确性、完整性、一致性、符合架构规范
工作流程： 根据架构规范或预期格式进行验证 → 找出缺失项或错误 → 修正 → 展示新增／更改／移除的内容。对于配置，检查安全问题（硬编码密钥、权限设置过宽）。

设计／视觉

维度： 对齐、层级、无障碍性、响应式设计
工作流程： 检查标记／样式 → 找出视觉层级或无障碍方面的问题 → 修正 → 描述视觉效果的变化。

确立标准时，可以建议用户考虑他们可能未曾想到的、与领域相关的维度。

提问

如果可用，请使用 AskUserQuestion（答案空间可预测时，提供 options 数组）。如果不可用，则使用 ask_user（提供 choices）。如果两者都不可用，则直接用普通文本提问——重要的是提出问题，而不是使用哪种方式。

推断标准

在询问用户评估标准之前，先尝试从请求中推断。用户往往会直接说明想要什么，而不一定会使用“标准”一词：

• “让这个更快” → 性能（快速模式）
• “这让人困惑，而且太长了” → 清晰度 + 简洁性（完整模式，已提供 2 项标准）
• “把这个整理一下” → 含义模糊，询问用户所说的“整理”具体指什么
• “改进这份 README — 我们的入门流程耗时太久了” → 真正的标准是入门速度，而不是 README 的美观程度

能够推断标准时，先确认，而不是从头询问：“我会重点关注 [X] 和 [Y] — 这符合你的期望吗？”这样可以省去一轮沟通。

核心规则

1. 至少有一项标准，才能开始改进。 即使在快速模式下，用户的请求也隐含着一项标准 — 明确说出它。
2. 始终先评分，再评分（完整模式）。每次迭代都要有评分卡。
3. 每次迭代只设定一个明确目标。 密切相关的改动可以一起进行，但必须服务于同一个改进目标。多个不相关的改动会让人无法判断哪些改动起了作用。
4. 优先处理最大的差距。 已达标的项目无需润色，而其他项目仍未达标。
5. 发现回归。 如果先前已达标的标准后来未达标，继续之前先撤销或修复。
6. 适时停止。 所有标准均已达标、连续 3 次迭代无进展、总计 10 次迭代（软上限），或用户要求停止时，都应停止。
7. 用户检查点很重要。 每次迭代评分后，简要分享评分卡并询问用户是否认同评估。自我评分存在盲点 — 用户的看法才是最终依据。

工作流（完整模式）

详细评分标准、评分卡格式、优先级规则和完成条件，请参阅 references/EVALUATION-GUIDE.md

1. 接收 — 接收输入（现有成果或原始请求）
2. 确立标准 — 提取或询问可衡量的评估标准（1–3 项，按优先级排序）
3. 记录基线 — 生成首个输出并评分（第 0 次迭代）
4. 改进 — 进行一项明确的改动，针对最大的差距
5. 评估并检查 — 为新输出评分，向用户分享评分卡，并确认是否符合预期
6. 决定 — 继续、停止或调整标准
7. 交付 — 提供最终输出和完整的迭代历史

第 1 步 — 接收

接收输入并了解你将处理的内容：

• 现有成果 — 用户提供代码、文本或文件路径。继续之前，先通读内容。
• 原始请求 — 用户描述想要的结果。先生成第一个版本，再进入标准设定阶段。

确认已收到内容，并简要概述其当前状态（例如：“这是一个 120 行的 Go 处理程序，用于处理 webhook 事件。我注意到它包含嵌套的错误处理和一些重复模式。”）。此时不要开始改进。

第 2 步 — 确立标准

先尝试从用户的请求中推断标准（见上文“推断标准”），然后进行确认或询问：

• 如果上下文中的标准很明确 — 确认：“我会重点关注 [X] 和 [Y] — 对吗？”
• 如果标准含糊不清 — 询问：“最重要的是把什么做好？”以及“出现什么情况时你会拒绝这个结果？”
• 如果标准超过 3 项 — 按优先级排序并选出最重要的 3 项

对于目标明确的任务，一项标准就足够了 — 不要为了凑数而强迫用户另想标准。可以建议用户未提及但与领域相关的标准（见“领域提示”），但由用户决定。

第 3 步 — 记录基线

生成第一个输出（或原样使用现有成果），依据所有标准评分，并将结果呈现给用户，同时指出主要差距。

第 4 步 — 改进

进行一项明确的改动，针对最大的差距。开始改动前，先说明要改什么以及原因。

第 5 步 — 评估与检查点

根据所有标准为新输出评分，与上一轮结果比较，并检查是否出现退步。然后向用户分享评分表——他们可能会发现你遗漏的内容，或对评分有不同看法。必要时先调整，再继续。

第 6 步 — 决定

如果仍有差距，则继续；如果所有标准均已满足、连续 3 轮没有进展、总计达到 10 轮，或用户要求停止，则停止。

第 7 步 — 交付

提供最终输出并附上摘要。根据项目惯例，表格使用英文：

## Final Output

[The improved result]

---

### Iteration History

| Iteration | Change | Total Score | Delta |
|---|---|---|---|
| 0 (Baseline) | — | X / Y | — |
| 1 | [Change description] | X / Y | +W |
| 2 | [Change description] | X / Y | +W |

**Final Score: X / Y**
**Criteria met:** [List]
**Criteria not met (if any):** [List with reason]

对于较长的改进会话（3 轮及以上），将迭代历史写入文件（例如工作目录中的 improve-history.md），以便在上下文重置时保留进度。告知用户文件路径。

示例

快速模式示例

用户：“让这个函数运行得更快”

1. Goal: improve execution speed
2. Read the function, identify bottleneck
3. Apply optimization
4. Show before/after with explanation
5. "Does this hit the mark, or should I keep going?"

完整模式示例

用户：“改进这个 README——它让人困惑，而且太长了”

1. Receive: README.md contents
2. Criteria (confirmed with user):
   - #1 Clarity: a new team member understands the project in under 2 minutes
   - #2 Conciseness: under 200 lines, no redundant sections
3. Baseline: score both criteria, identify key gaps
4. Iteration 1: restructure for clarity (target biggest gap)
5. Checkpoint: share scorecard, ask user if they agree
6. Iteration 2: trim redundant content (next gap)
7. Deliver: final README + iteration history

边界情况处理

**用户在循环过程中更改标准：**接受更改。根据新标准重新评估当前输出，并从第 4 步继续。

**用户提供反馈，而不是让循环继续运行：**将反馈视为新标准或重新确定优先级的信号。进行调整并继续。

**输出一开始就已完美（基准评估时满足所有标准）：**立即宣布成功。如果用户希望进一步改进，建议他们提高标准。

**标准之间存在冲突：**指出冲突：“标准 A 和标准 B 似乎相互牵制。发生冲突时应优先满足哪一项？”

**用户只想快速修复一处问题：**使用快速模式——不要强行执行完整流程。

此技能不负责的事项

• 不会发掘目标或探索意图——需要用户提供明确的输入和标准（可使用 /brainstorm 来探索）
• 不会猜测“更好”意味着什么——需要明确的标准
• 不会无限迭代——设有明确的停止条件
• 未经用户批准，不会牺牲已满足的标准来满足尚未满足的标准