系统化问题解决与优化流程（Systematic Problem-Solving & Optimization）

方法骨架与业界经典问题解决法同构（见文末对照表），本 skill 在经典流程上补充了两次实践沉淀的关键增量：量化先行（第 0 步）与约束分层（第 5 步）——后者回答"为什么改了还会复发"：方案若落在"靠人遵守"的约定层，就必然复发。

触发边界

• 用户说"优化 / 改进 / 复盘 / 为什么反复出问题 / 效率是不是低 / 成本是不是高 / 质量是不是差 / 总在重复犯同一个错"；
• 接手一个反复失败或长期停滞的任务/流程/系统；
• 审查发现同一类问题反复出现（反模式重演）。

流程（九步）

第 0 步：证据先行，量化基线

没有数字的"问题"是感觉。 先量化再下结论：

• 从日志、监控、账单、转录、数据中提取指标：频次、时长、成本、等待时间、失败率、资源消耗、重复次数；
• 用时间线重建事件流，找"长时间无产出/高消耗"的段；
• 建立优化前的基线数字（第 8 步同口径对比用）。
• 反例：不量化就下结论（"好像很慢""感觉浪费"）→ 无法证明改进，也无法定位根因。

第 1 步：发现所有问题（全量列举）

• 不修修补补，先把问题全部列出（悬挂、空转、重复、超支、返工、错误率……）；
• 每个问题标注证据（哪段日志/哪个数字/哪个事件）；
• 区分表象与真问题：表象是症状，真问题是"缺什么机制导致症状反复出现"。

第 2 步：寻找根因（分类定位）

根因分三类，处理方式不同：

根因类型	特征	对策
缺约束	根本没有对应的规则/流程/检查	补约束
有约束不执行	规则/流程存在但当事人没遵守	加执行点检查（checklist、门禁）
无法强制执行	约束靠"记得遵守"，没有系统拦截	改系统/工具/平台层做强制约束（唯一真正根治）

判定方法：对每个问题问"约束存在吗？存在但没执行吗？为什么没执行——是不知道、忘了、还是没法强制？"。第三类是复发问题的常见真根因：规则写在哪不重要，规则拦不拦得住才重要。

第 3 步：寻找解决方案（结构性优先，拒绝临时）

每提出一个方案先问：这是临时方案还是结构性方案？

• 临时方案：手动清理一次、这次注意点、下次记得、特例处理……（会复发）
• 结构性方案：自动回收、预算上限、参数必填、流程节点拦截……（系统无法绕过）

追求大局观：不从单个问题打补丁，而是看"这一类问题"缺什么结构性机制。临时方案只用于止血，必须伴随结构性方案，否则问题必然复发。

第 4 步：借鉴同类问题的已知解法

• 先定义问题域，再检索（关键词来自根因；来源：文献、业界方案、开源项目、其他领域类比、内部历史案例）；
• 只回收结构化结果（机制名 | 出处 | 实现方式 | 链接/引用），不堆砌原文；
• 对照表：机制 | 出处 | 实现 | 来源。

第 5 步：归纳成为最终方案（取舍）

• 借鉴方案对照本系统/本场景约束：哪些能移植、哪些不能、怎么改造；
• 最终方案必须包含：落点（改哪里）、行为变化（什么条件下触发什么）、可验证的验收点（可观测的字段/指标/行为）；
• 按成本/收益取舍，不做过度设计（防御过多本身也是问题）。

约束分层（本步必做，逐方案标注）——回答"这方案会不会复发"：

约束层	含义	可靠性	判定
系统层	平台/代码/工具层强制执行（参数门禁、自动回收、硬校验）	✅ 无法绕过	真方案
流程层	流程节点检查、checklist、审批门	⚠️ 依赖执行者"记得查"	半方案，需观察
约定层	文档、规范、培训里的"应当/禁止"	❌ 经常不执行	弱约束，不算方案

约定层不执行是经验事实，不是假设（实证：禁令写入文档并被当事人看过，下一次照旧违反；"及时处理"规则存在数月，问题照样悬挂）。因此：

• 约定层条目必须显式标注"未强制，待观察"，不得自称"已解决"；
• 若该问题反复出现，就必须升级到系统层，不能停留在约定层；
• 半方案（流程层）要设观察期和升级触发条件：N 次复发即升级。

第 6 步：展示计划，确认实施（决策门）

方案在实施前必须过一次决策门。 把第 5 步归纳的最终方案以紧凑、可决策的形式呈现给用户/决策方：

• 要改什么：方案清单（每条含：落点、行为变化、约束层、成本/收益）；
• 不改什么：非目标（明确排除的相邻内容，防止实施时范围蔓延）；
• 风险：主要风险与回滚方式；
• 验收标准：第 7 步生效验证的可观察判据；
• 等待确认：明确请求确认（同意 / 调整 / 驳回）后才进入实施。

规则：

• 决策方在场（交互会话）→ 必须展示并等待确认，不得跳过；
• 决策方不在场（纯自动 goal 轮次）→ 按既定授权执行，但涉及删除、全局配置、外部系统、权限变更的高风险改动仍须停下等待人工确认；执行时在报告中说明"已按既定授权实施，高风险项已留待人工确认"；
• 被驳回/要求调整 → 回到第 3-5 步修订方案后重新展示，不直接实施。

第 7 步：实施

• 最小正确改动（不顺手重构、不扩大范围）；
• 新机制必须配回归保护（测试/复验），防止下次改动破坏；
• 跑完相关检查（构建、测试、校验、lint），全部通过才算实施完成。

第 8 步：验证生效（三件套，缺一不可）

改动落地 ≠ 已生效。 检查生效链路：

1. 物证：改动确实写入目标（文件 hash / 配置生效 / 版本号）；
2. 加载：运行中的系统确实加载了新内容（重启/热加载/部署确认——旧进程不会自动用新代码/新配置）；
3. 行为观察：实际触发一次，确认新行为出现（新字段、新报错、新拦截、指标变化）。

第 9 步：度量闭环（对比基线）

• 用第 0 步的同一指标重新量化，确认改进真实发生（不是自我感觉）；
• 若未改进，回到第 2 步重新找根因——可能根因找错了，或方案落在约定层没生效；
• 记录观察期与复发触发条件（尤其半方案）。

核心原则

1. 约束存在 ≠ 被执行：能落到系统层（硬校验、自动回收、预算上限）就不写建议；
2. 临时方案必须伴随结构性方案：否则问题复发；
3. 量化优先：每个问题带数字，每个优化带前后对比；
4. 验证生效三件套：物证 → 加载 → 行为，缺一不可；
5. 不重复造轮子：先检索同类问题的已知解法再设计；
6. 约定层不执行：约定层条目标注"未强制，待观察"；同一问题反复出现即升级到系统层。

输出契约

问题解决/优化完成报告：

基线（第 0 步数字）
问题清单（全量，带证据）
根因分类（缺约束/不执行/无法强制）
方案（临时 + 结构性；每个方案标注约束层：系统 | 流程 | 约定）
借鉴对照（机制 | 出处 | 来源）
计划确认（要改什么 / 不改什么 / 风险与回滚 / 验收标准 / 决策结果：同意|调整|驳回）
实施（改动/回归保护/检查结果）
生效验证（物证 / 加载 / 行为观察）
度量对比（优化前 vs 优化后）
约定层条目单独列出并标注"未强制，待观察"（不得自称已解决）

与经典方法论的关系

本流程骨架与业界经典方法同构，本 skill 的增量在量化先行与约束分层：

本流程	DMAIC（六西格玛）	丰田八步法	PDCA
第 0-1 步 量化+列问题	Measure / Define	明确问题	Plan（现状把握）
第 2 步 根因	Analyze	根因分析	Plan（原因分析）
第 3-5 步 方案+取舍	Improve	对策	Plan→Do
第 6 步 展示计划确认实施	Improve（决策门/Gate Review）	决策确认	Plan→Do（批准后执行）
第 7-8 步 实施+验证	Improve / Control	实施与效果确认	Do→Check
第 9 步 度量闭环	Control	标准化与横展	Act

与相邻 skill 的分工

• minimal-implementation：单点小改的执行纪律；本 skill 管"系统性解决问题"全流程；
• execution-discipline：执行层不空转；本 skill 管"方法论"；
• decision-gates：决策正确性；本 skill 第 5 步的取舍可叠加使用。

相关示例见 examples/（示例为 agent 运维领域实例，方法适用于任何领域）。