CtrlK
BlogDocsLog inGet started
Tessl Logo

systematic-optimization

系统化问题解决与优化流程(领域无关):量化基线→全量列问题→根因分类→结构性方案(拒绝临时补丁)→借鉴同类方案→归纳取舍→展示计划确认实施→实施→验证生效→度量闭环。核心原则:规则/流程存在≠被执行,能落到"无法绕过的机制"就不写建议;优化必须可度量。 用于用户要求"优化""改进""复盘""为什么反复出问题""效率低/成本高/质量差/总是复发"等任何领域的系统性改进,或接手反复失败的任务时。 不用于单点小修复(用 minimal-implementation);不用于只读审查不出方案的场景。

72

Quality

88%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide

SecuritybySnyk

Low

Low-risk findings worth noting

SKILL.md
Quality
Evals
Security

系统化问题解决与优化流程(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 运维领域实例,方法适用于任何领域)。

Repository
ooooooooooooooooooop/agent-tools
Last updated
First committed

Is this your skill?

If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.