optflow

Optflow

概述

使用此技能来发现代码仓库中的优化机会，并端到端地执行选定的优化：

• 先发现优化点（性能、可靠性、可维护性、安全性、成本、开发体验）。
• 按影响、工作量和风险确定优先级。
• 严格按顺序执行，并进行验证、明确提交策略。
• 在用户要求时，或需求不明确时，添加 BDD 行为规范。

触发条件

当用户提出以下一项或多项要求时，触发此技能：

• 要求在代码仓库或库中寻找优化机会。
• 要求制定优化路线图并实施。
• 要求以测试先行的方式交付优化并提交（最终统一提交或分步提交）。
• 要求行为驱动交付（BDD）或验收场景。

工作流

0. 发现待办优化项

• 在规划更改之前扫描代码仓库。
• 将发现的问题分类为：性能、可靠性、可维护性、安全性、开发者体验和成本。
• 对每项发现，记录：
  • 症状和证据（文件／路径／指标）
  • 预期影响
  • 工作量估算
  • 风险级别
• 根据影响、工作量和风险，建立优先级待办列表。
• 明确将低置信度的发现标记为假设。

1. 定义就绪标准（DoR）

参见共享交付基准：references/delivery-base.md

Optflow 的附加要求：

• 如果用户要求实施，且未明确指定提交方式，则使用 per_step（默认值）。
• 如果用户说“每步优化并测试，然后提交”，则使用 per_step。

2. 编辑前制定完整计划

参见共享交付基准：references/delivery-base.md

3. 按需添加 BDD 层

如果用户提出要求，或需求不明确，则使用 BDD。

有关 BDD Lite、场景质量检查清单、场景大纲和测试层映射，请参见共享参考文档：

references/bdd-guide.md

4. 逐步执行

参见共享交付基准：references/delivery-base.md

• 尽可能将每个计划步骤视为一个功能边界。
• 如果 commit_policy = per_step（实施时的默认值）：
  • 仅暂存当前步骤／功能对应的文件。
  • 先运行步骤级检查。
  • 步骤检查通过后立即提交。
  • 记录步骤与提交哈希的对应关系。

5. 按要求应用不向后兼容模式

参见共享交付基准：references/delivery-base.md

6. 使用测试矩阵进行验证

参见共享交付基准：references/delivery-base.md

分步模式下的强制循环（当 commit_policy = per_step 时）：

1. 实施当前功能步骤。
2. 运行对应的步骤检查（至少运行一条自动化命令）。
3. 如果检查通过，立即提交此步骤。
4. 进入下一功能步骤。

7. 提交并交接

参见共享交付基准：references/delivery-base.md

• per_step：每个步骤都必须在开始下一步骤前提交。

输出模板

优化待办列表模板

Finding:
Category: <performance|reliability|maintainability|security|dx|cost>
Evidence: <file/metric/log>
Impact: <high|medium|low>
Effort: <high|medium|low>
Risk: <high|medium|low>
Priority score: <...>
Decision: <implement now|defer>

优化计划模板

Selected Findings:
1. <finding>
2. <finding>

Execution Steps:
1. <step> (done condition: <...>)
2. <step> (done condition: <...>)

Expected Gains:
- <metric or qualitative gain>

防护措施

• 预期需要实施时，不要止步于规划。
• 不要留下未完成的计划步骤。
• 可以立即运行所需测试时，不要推迟。
• 当 commit_policy = per_step 时，提交当前步骤之前不得进入下一计划步骤。
• 当 commit_policy = per_step 时，不要将多个已完成的功能步骤合并为一次提交。
• 如果用户明确要求不处理兼容性问题，不要声称具备兼容性。
• 不要在提交中包含无关的预先存在的脏文件。
• 没有具体的验证证据时，不要进行交接。