perf-optimize-workflow

性能优化工作流

强依赖项（frontmatter）：clarifying-question-discipline（每轮只问一个问题）、known-issue-research（在定位阶段快速搜索已知性能模式）。如果缺少其中任何一项，请中止并打印：npx skills add FuDesign2008/open-skills -g --skill '*' --yes。

运行时强依赖项（环境提供，非 frontmatter）：用于第 5–6 阶段迭代循环的循环运行器能力——在进入第 5 阶段时探测；如果缺失，则停止优化执行（参见“迭代循环”）。

范围

本工作流负责完整的性能优化范式：构建可复现的基准测试，通过证据有效性检查来把关每个结论，沿完整链路归因瓶颈，每轮只优化一个目标，通过跨运行 A/B 统计验证，并将结果沉淀到基准测试日志中——优化↔验证循环由环境提供的迭代循环驱动（若缺失则如实停止）。每个项目的交付物包括：基准测试日志和测试框架，以及两个不断演进的项目级技能（用于归因的 code-insight 和用于优化的 code-optimizer），它们承载技术栈和项目知识，并在每次优化活动中持续改进。

它要回答：谁在什么条件下、在哪些设备上触发了什么昂贵操作——然后以可衡量的方式消除它。发布/部署决策由项目负责，不属于本工作流。

范式来源：提炼自两个不同技术栈上的完整优化活动（原生 C++ 工具链：工作负载从 29.4s 降至 6.7s，降低 77%，输出逐字节一致；大型 Web 富文本编辑器：提交耗时降低 27%／渲染量减少 31%／内存减少 34%，此外还通过四条路径厘清了一项持续数年的用户卡顿归因）。以下阶段是这两个优化活动共同遵循的、与技术栈无关的骨架。

分层架构

层	所在位置	变更时机
范式与证据规范（本文件）	SKILL.md	很少变更——行为约定，审慎地进行版本管理
项目归因/优化技能	项目的 Agent 技能目录（code-insight、code-optimizer）	每次优化活动——从语料库初始化，并根据活动经验不断演进
技术栈语料库（种子模板 + 证据案例档案）	reference.md	偶尔变更——更新技术栈章节和案例

范式是持久的；项目技能会在每次优化活动中不断积累（技术栈和项目知识都存在这里）；语料库仅用于初始化，需要偶尔更新。不要将易过时的内容放进本文件。

触发识别

触发词（每个触发词都会进入工作流；采用「触发词 + 冒号 + 空格 + 描述」形式时，会直接进入指定阶段——冒号和空格标点不受语言影响）：

• **「性能分析」／「性能问题」／「卡顿」／「很慢」**或英文对应说法（"performance issue", "it's slow", "jank"）→ 从第 1 阶段进入
• 「性能证据」 → 第 1 阶段：基准测试与证据
• 「性能定位」／「性能深入」 → 第 2 阶段：定位瓶颈（「性能深入」表示继续／深入第 2 阶段）
• 「性能假设」 → 第 3 阶段：提出根因假设
• 「性能监控」 → 第 4 阶段：构建可切换的监控
• 「性能优化」 → 第 5 阶段：优化
• 「性能验证」 → 第 6 阶段：A/B 验证
• 「前端性能」／「前端性能优化」／「Electron 性能」 → 从第 1 阶段进入；在项目的 code-insight／code-optimizer 技能完成初始化并成熟之前，将 reference.md 中的前端语料库作为工作知识
• 「伪影排查」／「口径校准」／「设备画像」 → 进入证据把关模式：在任何决策依据该指标之前，根据下文规范审查可疑指标

收到用于分析的性能相关日志或性能分析档案时，也从第 1 或第 2 阶段进入。

通用原则

先建立基准再动刀，证据过关才定罪，沿完整链路归因才能一锤定音，每轮只设一个目标，A/B 交叉验证说了算，负面结果也要留痕。（先建立基准再动刀；只有通过证据关卡才能定罪；沿完整链路归因；每轮只设一个目标；以 A/B 交叉验证结果为准；负面结果也要留痕。）

1. 以数据为依据：没有测量结果，就不下结论。还没有复现路径或可分析的数据 → 首要任务是建立它们（阶段 1），而不是提出假设。
2. 证据过关：每项用于决策的指标都必须先通过证据有效性规范（见本文中的章节）。非决策级数据可以提供参考，但不能作为定罪依据。
3. 单变量、可复现：每个假设都应能通过现有数据或少量针对性埋点判定是非；每次优化只触及一个根因点，以便归因其收益；结果必须可复现、可证伪——相关性不等于因果关系。
4. 自上而下覆盖完整链路：从用户感知的链路（宏观）深入到热点（微观）；先找出 哪里 慢（耗时／资源占比），再弄清 谁 触发了它，以及 在什么条件下 触发。避免盲人摸象式的局部分析。
5. 生产级构建与设备配置：验收数据应来自生产级构建；定罪级结论应来自按设备配置校准的运行结果（CPU 限频矩阵），不能只依赖高端开发机。
6. 不做过早优化：只优化经过测量、影响用户且超过阈值的问题。没有数据支撑的预防性优化只会徒增复杂度。

• ⚠️ 主动询问：遵循 clarifying-question-discipline ——每轮只问一个问题，通过多轮提问直至问题明确，并在回答前先澄清。

阶段流程

正向流程：取证 → 定位 → 提出假设 →（监控）→ 优化 → 验证，在“优化 ↔ 验证”之间迭代，直至达到目标或不再具备成本效益。

常见跳转：

• 阶段 1 缺少数据，必须先建立监控 → 转到阶段 4，再返回阶段 1。
• 阶段 2 的数据已经确定瓶颈 → 跳过阶段 3，进入阶段 4/5。
• 阶段 6 推翻假设 → 返回阶段 2/3；优化效果不足 → 返回阶段 5。
• 间歇性问题难以捕获 → 优先进行阶段 4 的长期监控，待问题复现后再继续。

---

证据有效性规范

硬性关卡：性能结论只有通过以下检查后，才能用于制定优化决策。这些陷阱分为四类——测量伪影（环境或工具扭曲了数据）、构建级别污染（数据真实，但测量的并非目标内容）、设备配置不匹配（数据真实，但问题只出现在没人抱怨的机器上），以及对比环境状态无效（A/B 判定本身是在受污染的环境中得出的）。包含真实数字的匿名案例完整档案：reference.md 第 4 部分。 | # | 学科 | 单行规则 | |---|-----------|---------------| | 1 | 环境限流伪影 | 来自受控运行时（无头／被遮挡／处于后台）的帧／调度类别指标，在证明有效之前一律无效——后台限流可能会将帧回调频率压低几个数量级，模拟焦点也无法解除限流；应在可疑时间段采样执行器进行检测（以空闲为主 ⇒ 伪影）；改为测量同一任务（刺激和测量处于同一调度单元中，因此运行时无法在两者之间延后工作） | | 2 | 监控器自身污染 | 插桩构建版本与生产版本可能相差数倍（监控开销 + 未优化代码）；开发版本指标只用于比较 A/B 趋势——优化决策应使用生产版本指标；若与运行时原生指标冲突，以运行时指标为准 | | 3 | 框架计数器歧义 | 信任任何框架内部统计数据之前，都应先小规模审计（将独立计数与原生指标交叉核对）；数量级相矛盾意味着计数器才是伪影——计数器只能用于判断趋势，不能作为定论证据 | | 4 | 设备配置校准 | 要得出足以定论的结论，需要采用 CPU 限速矩阵（例如 1x/8x/20x）× 路径 × 缩放比例；对低端用户而言，未限速时得出的「无问题」结论无效——同一工作负载在不同单元中可能得出三种结论 | | 5 | 输入事件真实性 | 每次合成输入负载都必须验证可观测的状态变化（实际变化 == 预期变化）；绕过产品真实输入管线的合成按键／滚动事件，无论驱动报告成功与否，均属无效 | | 6 | 插桩开关生命周期 | 在加载时读取的开关，必须在产品脚本加载前注入（通过调试协议的预加载注入功能）；由延迟回调结束的测量区间会受到环境限流影响（规则 1）——阶段性结论应使用同步区间和原生长时间工作计数器 | | 7 | 禁止外推单个样本 | 开发者机器上的数据不代表用户配置；关于负投资回报率的结论需要用户配置证据（汇总遥测／支持反馈／实地数据）——不得从单个账户进行外推 | | 8 | 终极对照实验 | 当分析器未显示代码热点（运行时内部占主导）时，将实时场景克隆为纯静态副本（环境相同，不含任何产品逻辑），并在相同条件下运行相同负载：副本 ≈ 原场景 ⇒ 大部分开销来自内容规模 × 环境的物理成本，优化方向应转向削减这部分基础成本；两者之差即为产品代码的边际开销——也是代码级优化的上限；消融实验注意事项：「机制存在 ≠ 机制有效」 | | 9 | 负面结果须留痕 | 在基准测试日志中为受污染的行标记失效警告（内容／原因／正确的指标口径）；保留排除记录，避免后续读者重走弯路或引用错误数据 | | 10 | 对比环境状态有效性 | 交错进行的 A/B 测试假设两组处于相同环境中——切换代码后，热重载状态（新旧模块混杂、单例重复、注册项过期）会系统性污染其中一组；涉及结构单元（模块／单例拓扑）的更改，必须在两组测试之间重置环境（重启／硬刷新），否则评审者的结论无效 |

门槛规则：对于任何指标，如果负责其陷阱类别的规范尚未解决，该指标就不足以用于决策——可以仅作为趋势参考，但不得用于驱动优化选择、优先级安排或通过／失败判定。

---

阶段 1：基准测试与证据（性能证据）

目标

将模糊的「有点卡」转化为可复现、标准化且有日志记录的工作负载，并量化基线与目标／红线——而不是一次性的手动复现。如果已有基准测试工具，就运行它；如果没有，构建一个最小版本也是本阶段的一部分，因为之后的每个阶段都依赖可重复的数值。

需要澄清的信息

• 症状：具体是哪种操作（点击/滚动/输入/打开/输入法……），「缓慢」表现为何（卡顿/空白/加载指示器/无响应），尽可能量化；明确分析边界（问题的起点和终点）。
• 可用数据：是否已有日志/性能分析记录/检测数据？如果没有，确定可在什么环境中、通过什么方法采集数据。
• 复现情况：总是出现还是间歇出现；对数据量/设备类别/持续时间有什么要求。

基准测试框架约定（构建时）

• 基于场景清单规划标准化工作负载：先创建或查阅项目的用户场景清单（真实使用场景的完整集合及其覆盖状态——将其存放在框架旁边，例如 SCENARIOS.md），再规划脚本化负载以弥补其中的空白（打开 × 规模、输入 × 字符数、滚动 × 轮数、切换、长时间编辑会话、输入法、粘贴……）。每个负载都通过真实输入路径（规范 5）驱动，并通过内容变化验证。
• 长会话退化属于独立的问题类别：短会话揭示单次操作的开销；持续编辑/笔记切换/历史记录增长则揭示累积退化（内存持续增长、延迟趋势上升、撤销历史膨胀）。应通过专门的负载（会话/切换/历史记录类别）覆盖，并依据趋势斜率和拐点进行分析，而非单次运行的数值。
• 探针脚本模式：每个反复出现的归因问题都应沉淀为框架下可复用的探针脚本（命名约定为 probe-*——性能分析器采样、分阶段计时、计数器审计、节流矩阵驱动器……）。项目 code-insight 中的流水线步骤应调用探针，而非临时编写脚本；首轮测试活动建立初始探针集，后续活动再扩充。
• 自动采集：指标收集只需接入一次，之后每次运行都复用——不要手动复制粘贴。优先采用控制台/日志解析和结构化 JSON 存档。
• 先建立基线：任何改动之前，先记录优化前的基线；之后的每项结论都要与之比较。
• 基准测试日志：在仓库根目录维护一个只追加的文件（例如 BENCHMARK.md），记录每次运行：日期、提交、工作负载、规模、关键指标、备注。此日志是测试活动的记忆——结论、撤回和失效记录都应写入其中（阶段 6）。
• A/B 判定器：构建或复用跨运行的统计判定器（见阶段 6），避免仅凭观察两个数字来回答「是否有所改善」。

证据门槛（本阶段的任何数值对外使用前）

对计划沿用的每项指标，确保其符合文件内规范 1（节流伪影）、2（监视器自污染）、5（输入真实性）、6（开关生命周期）。未通过门槛的数值应标记为仅供趋势参考。

输出

• 有哪些数据可用/缺失；如果缺失，明确具体的采集操作（由谁运行什么、采集什么）。
• 建议的输出：结构化的问题定义——症状（量化）、复现条件、分析边界、基线、目标阈值/红线。
• 基准测试框架状态：已有/本阶段构建/推迟并说明原因。

---

阶段 2：定位瓶颈（性能定位）

目标

找出数据中的异常（哪些环节耗费了多少时间/资源、何时发生），追踪完整的触发链，并将范围缩小到 1～2 个核心环节——所有关键数字都必须已通过证据门槛。

项目归因技能（code-insight）

栈／项目专属的归因流水线作为项目级技能，由此工作流创建并持续改进——范式文件保持通用。

• 阶段开始时探查：查找项目的 code-insight 技能（位于项目惯用的 Agent 技能目录中）。找到 → 在本阶段的本地化工作中运行其流水线，并记录其未覆盖的任何缺口（该缺口就是本轮改进的候选项）。未找到（首次开展） → 将其作为分步流水线创建：采用 reference.md 第 5 部分中的归因流水线模板（当前为 JS 技术栈），结合本次运行发现的项目信息（工具路径、工作负载细节、已知陷阱、在测试框架下的初始 probe-* 脚本）进行调整；第 1-2 部分作为各流水线步骤的知识附件；正式提交前，对创建的内容进行专家视角审查。手动模式下确认创建位置；自动模式下采用项目惯例。
• 创建的技能是长期保留的项目资产：后续会话和项目中的其他 Agent 均可直接调用，不依赖此工作流。

分析方法

1. 全链路拓扑：将从用户操作到问题终点（代码执行、系统调用、网络／存储）的路径分段，不留空档、不重叠；每段都可单独计时。
2. 双维度采集：时间（每段耗时／占比）+ 资源（CPU／内存／IO／网络），两者都不可遗漏。资源利用率超过 70% 是常见的警戒线——超过后，响应时间会非线性上升。
3. 初步筛查：按耗时占比对各段排序（例如 >20% = 高成本）；标记资源异常（饱和、持续增长、错误率）；排除低成本且资源正常的部分。

归因技术（根据数据表现选择）

• 文本日志：按关键词／耗时／错误代码筛选，查看片段和调用栈。
• 性能分析：优先查看宽条／高占比区域，再深入到函数／组件。如果渲染占主导，则对编辑器／Web 应用采用四类拆分：框架提交／样式插入／布局／绘制——它们的修复方式完全不同；不要把“渲染”当作一个整体来分析。
• 强制重排分析（写入→读取模式；富文本编辑器中，DOM 变更后立即读取选区边界，是典型的头号原因）。
• 没有 JS 热点（(program)／(idle) 占主导）？→ 由规范 8 的静态副本对照实验判定：成本来自产品代码，还是来自 DOM 规模的物理成本。这个实验本身就能终结一场持续多年的争论。
• 已知模式快速搜索：当 known-issue-research 的触发条件满足时，加载它，并在进行更深入的定制分析前运行其性能模式变体。

证据门槛

规范 3（计数器审计——使用任何框架内部统计数据前都要审计） 和 8（对照实验） 在此适用。

输出

• 异常摘要（缓慢／高流量／高频 + 位置）；用一句话或一张图说明因果链“操作 → … → 瓶颈”。
• 1-3 个初步假设，并说明支持／反驳证据；列出核心瓶颈段（1-2 个）及其占比。

---

第 3 阶段：假设根本原因（性能假设）

目标

将异常提炼为可验证、可证伪的根因假设，按常见模式分类；按用户影响 × 验证成本排序。

推理参考

• USE 方法（资源瓶颈）：利用率／饱和度／错误。
• RED 方法（执行／请求瓶颈）：速率／错误／耗时。
• 常见模式表（响应范围过宽、更新未批处理、高频触发、积压任务同时触发、资源泄漏、同步阻塞、重复计算）：本范式文件中介绍通用形式；具体前端表现见 reference.md。

证据门槛

纪律 7（禁止基于单个样本进行外推——“用户不会遇到这个问题”需要用户画像证据） 和纪律 4（节流矩阵——针对用户感知卡顿的假设，必须在经过校准的单元格上验证） 适用于此处。

输出

• 最可能的 1–2 个假设，每个都能判定为是或否（“是不是完整重新渲染？”可以回答；“代码写得很差”则不行）；按可能性排序；并注明验证方法（使用现有数据，或使用 Stage 4 中的哪些监控点）。

---

Stage 4：构建可切换的监控（性能监控）

目标

当现有数据无法验证假设时，在关键路径上添加可切换、适用于生产环境的可观测性——代码永久保留，运行时控制是否启用。

设计原则

1. 由开关控制（环境变量／配置／功能标志／调试开关）：在生产环境中关闭时 = 零输出、零采样、开销可忽略；开启时 = 输出结构化数据，并与现有日志保持一致。
2. 永久保留，而非临时使用：提供常驻能力，而非之后需要移除的埋点。
3. 可对齐：时间戳和位置标识符保持稳定，可与现有日志／性能分析数据合并到同一时间线上。
4. 恰到好处：记录位置、时间戳以及用于确认／排除假设的少数关键变量；复用项目的日志格式。
5. 开关生命周期：在模块加载时读取的开关，必须在页面脚本之前注入（纪律 6）。

监控点选择

先选直接触发点（状态更新／请求发起／重新计算入口），然后是中间链路节点（调用顺序／频率），最后是耗时计算的入口／出口（每次调用的耗时／次数）。

输出

监控点列表（文件:行号或函数、用途、开关名称），以及用于启用／复现／捕获的用户操作。若根本原因已可确认 → 跳至 Stage 5。

---

Stage 5：优化（性能优化）

此阶段与 Stage 6 作为迭代循环执行（见“迭代循环”）；在此阶段开始时探测环境门槛。

目标

实施能够消除／缓解已确认瓶颈的更改——每次迭代只针对一个根因，并根据影响确定规模。

项目优化技能（code-optimizer）

生命周期与 code-insight 相同：在阶段开始时探测项目的 code-optimizer 技能；若找到 → 按照其优化流程处理此目标并记录差距；若未找到 → 根据 Part 5 模板（JS 技术栈）和本次运行的发现，将其整理为分步骤流程。该流程种子 MUST 包含一个深度归因步骤，并委托项目的 code-insight 执行（两者是协作流程，而非彼此孤立的工具）。它会积累项目中经验证的优化模式和被否决的尝试，使每次优化行动都能从更好的起点开始。

原则

• 修复根因，而非症状：更改应对应 Stage 3 中的模式（缩小范围、批处理、节流、缓存、移至线程外等），而非笼统地“让它更快”。
• 技术选型决策交由用户决定：引入新依赖、替换数据结构或改变分配／内存策略 → 列出候选方案及其权衡（性能／可移植性／维护成本），由用户选择——Agent 不得擅自决定。
• 每次迭代只针对一个目标：每次提交只优化一项内容，使更改易于审查和回退，并让 Stage 6 的收益归因明确。多个不错的想法应排队，分开迭代。
• 分层优先级（由高到低）：业务逻辑 → 应用代码 → 框架／依赖 → 系统／硬件；优先选择较高层，以及“更改成本低、收益高”的方案。
• 按时间占比排序：优先优化占比最高的部分；占比 <10% 的部分即使提升 100 倍，对总体影响也很小（阿姆达尔定律）。
• 稳定性：不得改变语义、引入功能缺陷或造成新的性能副作用。
• 没有收益 → 回退：Stage 6 否决该更改时 → 回退（基准测试日志保留负向记录），不要在其上叠加第二项推测性更改。

输出

变更清单（文件、位置、摘要）+ 与 Stage 4 监控相匹配的建议验证场景／指标，供 Stage 6 使用。

---

Stage 6：A/B 验证（性能验证）

此阶段通常在迭代循环中运行（见“迭代循环”）；单次运行仅是用户明确要求时的例外。

目标

1. 对假设给出是／否判断。
2. 如果 Stage 5 修改了代码：以生产级标准，通过统计方法证明优化有效且没有副作用，否则回退。

证据门槛

本阶段的每项判断（包括单次运行）都必须遵循规范 2（生产级验收）、4（基于节流矩阵单元格给出用户卡顿判断）、**9（记录驳回与失效情况）**和 10（结构单元发生变化时在两组测试之间重置环境）。

A/B 跨轮次统计判定

• 将上一个提交的构建版本保留为基线（快照以提交哈希为键）。
• 交替运行 B₁ A₁ B₂ A₂ B₃ A₃（基线、新版本，交错执行），让系统负载噪声大致均匀地影响两组。
• 只有当 avg_B − avg_A > max(stdev_B, stdev_A) 时才接受改进（验收规则；其他地方会引用，仅在此处说明）。单次运行和 N 次中的最小值都不能作为判断依据（N 次中的最小值会追逐空闲时刻；单次运行会追逐噪声）。
• 判定前，遵循规范 10：如有结构性变更，须在两组测试之间重置环境。
• 与源范式有意不同之处（已记录）：源范式接受“确定正确”的微优化，即使其效果处于噪声范围内；本工作流对 Agent 执行采用严格的统计门槛，因为 Agent 往往会系统性地高估“确定正确”。若要恢复此例外，必须提供静态等价性证明并获得用户确认。
• 原理：交替运行会经历相同的机器状态，因此差值比绝对数值稳定得多，无需锁定机器、固定核心或终止服务。

验证清单

• 假设判断：已证实／已证伪／不确定（+ 缺少什么、后续监控或重新分析计划）。
• 有效性：使用相同的复现路径，列出前后关键指标，并事先说明通过标准。
• 回归：功能正确性（正常／边界／峰值情况）保持不变——对于转换流水线优化，输出等价性检查（例如逐字节相同）是最有力的形式。
• 副作用：不存在其他性能问题（例如延迟问题解决了，但内存持续增长）。
• 验证标准：验收数据来自生产级构建（规范 2）；用户卡顿判断来自按设备配置校准的单元格（规范 4）。
• 记录：将本次运行追加到基准测试日志中——包括驳回项（规范 9：记录无收益和产物异常条目及其原因，避免他人重走死路或引用错误数据）。

停止条件

所有假设均已验证、目标均已达成，或剩余瓶颈的性价比过低（变更成本 ≫ 收益）。这是整个优化活动的停止条件；循环部分的停止条件用于决定何时结束单轮。之后可选择将关键指标纳入常规监控／CI 门槛。

---

迭代循环（受环境约束，是 Stage 5-6 的强制要求）

优化（Stage 5）和 A/B 验证（Stage 6）必须在挂载于真实环境循环运行器上的重复循环中执行——绝不能作为一次性运行，也不能自行编造文字版循环。持续多轮才能积累收益；手动单次运行会在第一个明显热点处停止，并悄然丢失该范式的核心价值。

环境门槛（进入阶段 5 时）

探测环境是否具备循环能力——已安装的循环运行器（类似 ralph-loop 的运行器、/loop、目标驱动的长程运行，或任何能在每轮管理上下文并让 Agent 自动跨轮继续运行的机制）：

• 已找到 → 将下方的循环主体挂载到该运行器上并进入循环。运行器负责驱动每轮节奏和继续运行；此工作流规定每轮包含的内容以及何时停止。
• 未找到 → 停止优化执行。报告分析阶段的发现（这些发现仍然有效且可交付），并说明确切的阻碍：安装循环运行器，然后从阶段 5 重新开始。不要退而求其次，只进行一次手动运行——如实中止胜过伪造循环。

此门槛是对环境的运行时强依赖（并非 frontmatter 依赖——循环运行器是环境插件，而非可安装的技能）。

循环主体（每轮按顺序执行）

1. 分析性能 — 在本轮重新采集热点；上一轮的列表已过时。
2. 恰好选择一个目标 — 按用户影响 × 时间占比选出排名最高的热点；其余目标排队等待。
3. 优化该目标 — 按照 Optimize 阶段执行（映射到根因、可回退）。
4. A/B 判定 — 阶段 6 的验收规则决定接受或回退；判定前遵守纪律 10（结构单元发生变化时，在两组测试之间重置环境）；若不接受 → 本轮回退。
5. 正确性门槛 — 提交前运行完整测试套件／验证输出等价；测试未通过时绝不提交。
6. 提交 + 快照 + 日志 — 每轮提交一次；将已接受的构建快照设为下一轮的基线（以提交哈希为键）；无论接受还是拒绝，都将本轮结果及原因追加到基准测试日志。

停止条件（满足任意一项）

• 连续 5 轮无收益 — 优化集已收敛。
• 达到目标 — 已达到并验证阶段 1 的阈值／红线。
• ROI 已耗尽 — 剩余瓶颈带来的收益不再值得付出改动成本。

停止时：总结接受／拒绝的轮数、相对于基线的总测量收益，以及剩余瓶颈及其 ROI 评估。

上下文纪律（长循环会因上下文膨胀而失效）

每轮都将结果写入基准测试日志，并且只传递以下内容：本轮摘要、基线快照指针和停止条件计数器。原始性能分析和中间数据留在归档文件中——按需检索，绝不在轮次间完整传递。

技能演进（每次停止时；长循环中约每 5 轮一次）

技能也是代码——项目的 code-insight／code-optimizer 本身就是该范式的产物，会在使用中不断改进。每次满足停止条件时：

• 将本次优化活动中经过验证的经验融入这两项技能：有效的归因模式、失败的优化（附拒绝数据），以及发现的特定技术栈／项目陷阱。
• 基准测试日志中的失效条目和负面结果是主要输入——它们准确记录了技能出错或遗漏的内容。
• 从该技术栈的专家视角审查更新（例如语言语义／运行时与框架／硬件与平台），然后再合并：活动中途总结的经验可能相互矛盾，也可能与技能现有内容冲突——先修正不一致之处，再写入。
• 就地更新技能；下一次优化活动将从更完善的起点开始。这正是该范式实现跨优化活动累积，而不只是在单次活动内累积的方式。

输出详细程度（自适应）

• 问题简单、数据充足：精简为“异常 + 因果链 + 结论”。
• 涉及复杂问题／多个模块：按阶段简要输出，并附上关键代码片段。
• 特定技术栈知识（框架版本、阈值、模式、工具表）：从 reference.md 中自然引入——切勿将特定技术栈细节硬编码到此范式文件中。