easy-wins

轻松取胜

找到一项范围明确的改动，让整个系统更简单、更安全、更快，或更不容易回归。优先完成工作，而不是开启另一条清理线。

操作规则

只有满足以下所有条件，提案才算轻松取胜：

• 范围具体：明确指出文件、符号、依赖项、资源、测试或迁移步骤；
• 收益惠及用户或许多维护者，而不只是作者；
• 有证据支持所发现的问题和拟议的修复方案；
• 改动可以在一个小型 PR 中完成审查和测试；
• 已了解风险，并制定了验证计划；
• 结果能够减少熵：减少概念、依赖项、路径、例外、过时信息，或让旧状态重新出现的方式。

不要把这变成泛泛的架构评审。提出可修复的候选项，而不是“改进模块化”或“增加更多测试”这类主题。

执行

1. 确定搜索范围

提出建议前先检查：

1. 工作区、当前分支、项目说明、包清单、构建/测试/代码检查命令，以及现有贡献规则。
2. 近期历史（git log，大致查看最近 30–90 天）。重点关注近期或反复修改过的文件和子系统。
3. 如果使用仓库工具检查起来很方便，就查看未关闭的 PR/问题以及近期关闭的项目；避免提出已在进行或刚刚完成的工作。
4. 热点区域附近的代码和配置。使用仓库原生的搜索和分析工具；不要只根据文件名猜测。

从最小的有效扫描开始。只有第一轮没有找到有证据支持的候选项时，才扩大范围。

2. 寻找高杠杆的收尾点

按大致以下顺序查找这些信号。为每个候选项指定一个主要类别；将实现手段作为标签，而不是额外类别：

• 移除与整合：无用的依赖项、脚本、配置、代码、导出项、功能标志、资源、生成产物、重复行为、不可达路径或多余的回退方案；
• 完成迁移：仍有明显后续步骤、兼容性垫片、双路径或回退方案的旧迁移；
• 依赖维护：明显落后，或带来安全、维护成本的依赖项；提出升级前，先检查变更日志/发行说明和兼容性；
• 回归与边界覆盖：高价值边界缺少测试，尤其是真实缺陷的回归测试，或经常修改路径的测试；
• 可测试性与边界简化：存在不纯的接缝，而小规模提取纯函数或明确边界就能让行为更易验证，且不引入抽象；
• 开发者与 CI 反馈循环：工具运行缓慢、不稳定、噪声大或结果不确定，且存在局部、可衡量的修复方案；
• 可靠性与故障路径修复：错误被吞掉、不安全的回退、缺少超时或恢复处理、非确定性，或对部分损坏或无效输入处理不佳；
• 安全与隐私强化：不安全的日志记录、权限范围过宽、不安全的默认设置、缺少边界验证，或过时的凭据/配置路径；
• 契约与文档漂移：过时的注释、文档、示例、测试或生成输出，其中记录了实现细节，或描述了错误的项目行为。

不要提出面向用户的行为、UX、无障碍或产品改动。这些需要与利益相关方讨论。只有在存在可衡量的局部实现修复，且不改变产品行为或需要产品决策时，运行时性能工作才属于范围。

对于移除相关的主张，需通过导入/引用、脚本、配置、动态加载、生成文件和已记录的命令，证明其确实已无用。对于迁移相关的主张，需指出旧路径和新路径，以及要删除的最后一部分或要执行的切换。对于依赖升级，应检查变更日志/发行说明和兼容性，而不是把版本较旧当作有价值的依据。

3. 为候选项评分

恰好创建 5 个候选项，然后对它们排序。每个候选项都必须达到证据门槛，并且确实是容易实现的收益；必要时继续搜索或扩大扫描范围，而不是用较弱的候选项凑数。若每个候选项都符合条件，优先选择主要类别多样的组合。每个候选项只能有一个主要类别；将实现手段单独记录为标签。每个维度按 1–5 分评分：

• 影响：对用户、可靠性、安全性、性能或维护者覆盖面的益处。
• 覆盖面：受益的用户、运行、软件包或贡献者数量。
• 置信度：问题和修复确实存在的直接证据强度。
• 近期性：与近期更改的代码或活跃工作流的相关性。
• 可完成性：范围是否明确，以及一个小型 PR 完成该工作的可能性。
• 熵减：移除的概念、依赖、路径、例外或过时事实；旧状态无法再度出现时可额外加分。
• 成本：预期的实现和审查工作量；分数越高越差。
• 风险：回归、兼容性、迁移或推出风险；分数越高越差。

列出每项估算值，并计算透明的排序分数：

leverage = impact × reach × confidence × finishability × entropy reduction

将 leverage 除以 cost × risk。公式中不包含近期性。近期更改可能尚未充分完善；近期性仅作为背景证据，并在置信度、熵减、覆盖面和可完成性都相同时用于打破平局。近期更改是相关性信号，不是进行高风险更改的许可。不要仅因影响大就推荐高风险项目。

候选项必须减少熵、防止回归或产生可衡量的收益。在其他条件相当时，熵减应获得额外权重。

4. 提交提案

恰好列出五项。将首要推荐放在最前面。每项提案都必须包含：

• 类别：搜索分类体系中的一个主要类别。
• 标签：删除、迁移、提取、测试或依赖更改等实现手段。
• 标题：操作 + 具体目标。
• 证据：命令、历史记录、引用或测量结果，以及它们能证明什么。
• 更改：精确到文件、符号或依赖，以及最小可行差异。
• 收益：谁能受益，以及这如何减少熵、防止回归或产生可衡量的收益。
• 评分：影响、覆盖面、置信度、近期性、可完成性、熵减、成本、风险。需报告近期性，但不将其纳入公式。
• 验证：能够发现失败的测试、静态检查、基准测试、构建或运行时检查。
• 剩余风险：仍不确定的事项及其控制方法。
• PR 形式：预期标题、涉及的文件，以及是否需要迁移说明或发行说明。

明确说明证据不完整之处。“可能未使用”只是调查线索，不能作为删除提案。

请用户选择一个候选项。扫描期间不要编辑代码或创建分支。如果工作树不干净，可以扫描并报告候选项，但在基线干净之前必须拒绝实施。

5. 执行选定的候选项

用户作出选择后：

1. 用一个简短计划重述范围、成功检查项和风险。除非所选更改与提案有实质差异，或会对生产环境／数据造成不可逆影响，否则无需再次征求批准，直接继续。
2. 获取最新的默认分支，从该分支创建一个聚焦的分支，并检查确切代码。除非提案明确要求更改，否则保留公开行为。
3. 编写最小改动。在可观察行为的边界添加或调整测试。只有在保留的测试仍能覆盖契约时，才移除实现细节测试。
4. 先运行聚焦检查，再运行仓库要求的 lint、类型、构建和测试命令。将失败如实报告为失败；不得为了通过而降低检查标准。
5. 重新扫描，确认未引入旧导入、兼容路径、引用、文档、锁文件条目、生成的输出和死测试。对于移除操作，确认已移除的内容确实不存在，且构建仍能正常运行。
6. 提交一个连贯的更改，推送分支，并遵循仓库惯例创建 PR。PR 标题和正文必须包含简短的 What 和 Why，以及证据、验证结果、风险和熵的降低。将描述标记为 AI generated。不得在 PR 中夹带第二项清理。如果仓库不使用 PR，或无法访问远程仓库，则保留聚焦的补丁，并准确报告剩余的交接事项。

如果没有候选项达到证据和风险标准，则报告“未发现容易实现的改进”，并列出最有希望但尚未达标的候选项及其缺少的证据。不要为了每天提出方案而强行推荐。

PR 创建后即停止。由人工负责审核和后续跟进。

完成标准：所选范围已实现；有证据支持的检查均已通过；若目标是移除旧路径，则旧路径无法悄然残留或重新出现；并且 PR 已创建，或已准确报告剩余阻碍。

质量标准

优先选择简单的删除、完整的迁移、针对性的回归测试或可衡量的工具改进，而不是大范围重构。只有当原生代码更精简、更清晰、受项目运行时矩阵支持且行为等效时，才优先采用。将注释和文档视为代码：删除过时信息，但保留代码本身无法体现的原由。

未经明确说明风险、兼容性证据以及回滚或推出计划，绝不要将涉及安全、数据破坏、公开 API 或重大依赖变更的方案作为“容易实现的改进”提出。如果没有候选项达到标准，请直言不讳，不要为了营造进展而凭空制造方案。