Artifact Optimizer（产物优化分析）

概述

目的：对整个研发过程中产生的各类产物（代码、设计文档、Skill 文件）进行系统化优化审计，不只回答"有没有问题"，更回答"能不能更好、怎么更好"

功能：根据产物类型（代码/设计文档/Skill）自动切换分析维度，进行多维质量评估，按"收益×难度"矩阵输出优先级排序的优化建议报告，并在执行优化前引入 request-guard 刹车检查防止不合理改造

定位：本 Skill 定位为"快速优化扫描"，不做深度专项审计（如安全审计、性能压测等属于专项工具范畴）。分析维度覆盖常见优化面，但不替代特定领域的专家审查

使用场景：

开发者写完一段代码后，想检查是否有性能、可读性、可维护性方面的优化空间
设计文档产出后，想评估架构是否过度设计、设计是否完整、有无优化余地
Skill 创作者写完 Skill 后，想检查触发条件是否精准、流程是否清晰、内容是否冗余
用户直接说"优化一下这段代码"、"这个设计有什么优化空间"、"帮我优化这个 skill" 时

借鉴 bug-impact-analysis 的结构化分析流程与 code-review 的多维度审查方法论，结合 content-simplifier 的精简策略，输出可执行的优化建议报告。

核心原则

"更好"优先于"正确"：默认输入产物功能正确，聚焦于可优化空间
按类型自适应：根据产物类型（代码/设计文档/Skill）自动切换分析维度和策略
分级可执行：每条建议给出优先级、当前状态、优化目标、改进方式、预期收益
不改原文件：只输出分析报告和建议，不直接修改输入产物
推理可追溯：每条优化建议必须关联到具体的分析维度（如可读性、性能、完整性等）
根因驱动：🔴 级优化点必须归因到根因（为什么会出现，而非仅描述症状），同一根因导致的多个症状合并为一条建议
专家资产复用：分析前调用 use_skill("expert-solution-workflow") 查询相关经验、解决方案或记忆，复用已知坑和最佳实践
最小化交互：自主推理优化面，仅在关键信息缺失时提问
不重复造轮子：当条产物类型已有专门的审查 skill 时（如 code-review），本 skill 聚焦于该 skill 未覆盖的"优化"维度

执行流程

Step 0：上下文收集与类型识别

在分析之前，收集必要信息并识别产物类型：

0.1 收集输入

产物内容：用户提供的代码 / 设计文档 / Skill 文件内容或路径
产物上下文：如果是代码，读取关联文件理解完整职责；如果是设计文档，读取关联的设计和需求文档；如果是 Skill，了解其在技能体系中的定位
专家团查询：调用 use_skill("expert-solution-workflow") 查询相关模块的经验、解决方案或记忆（如业务专家资产包；查询失败或不可用则忽略此步骤继续正常流程）。如有相关资产，加载已知坑和最佳实践作为分析参考

0.2 类型识别

产物类型	判断依据	对应分析维度集
代码	文件扩展名为 `.py` `.js` `.ts` `.go` `.java` `.rs` 等，或用户明确说"代码"	[性能、可读性、可维护性、健壮性、简洁性]
设计文档	文件名为 `DESIGN.md`、`design-*.md` 等，或用户明确说"设计文档"	[架构合理性、完整性、清晰度、可行性、前瞻性]
Skill	位于 `skills/` 目录下或名为 `SKILL.md`，或用户明确说"skill"	[触发准确性、流程清晰度、内容冗余度、边界完整性、指令有效性]

如果类型不明确，根据产物内容特征推断并向用户确认。

0.3 异常场景预处理

在进入正式分析前，处理以下边界情况：

场景	处理方式
超大文件（代码 >2000 行 / 文档 >10000 字）	步骤1：结构扫描 - 使用工具列出文件中的类/函数/模块定义（含行号），以表格输出概览：<br>```markdown<br>
产物类型混合（如代码含大量结构化注释，或设计文档内嵌代码块）	以主体内容为准，辅以"该文件包含 XX 类型的混合内容，分析以主体类型维度为主，混合部分仅做简要标注"
既非代码也非文档也非 Skill	告知用户当前支持三种类型，询问是否按通用文档标准分析
用户指定只关注某几个维度	尊重用户选择，仅分析指定维度，报告中标注"按用户要求仅分析 [维度列表]"
关注点模糊（用户只说"帮我优化一下"，未给出任何关注方向）	先猜后问：基于产物特征推断最可能的 1-2 个关注维度（如脚本代码推断"可读性+健壮性"），输出推断结论让用户确认或纠正；用户无明确倾向时按全维度分析
产物已经过本 Skill 分析并优化过	判定方式：由用户主动标注"这是二次分析"或在分析前询问"该产物是否已经过本 Skill 分析？"<br>处理流程：1) 在报告开头标注"二次分析"；2) 优先检查上次建议的落地情况（如有历史报告）；3) 聚焦新增优化空间，避免重复输出相同建议；4) 如无历史报告，则按首次分析处理

0.4 语言覆盖

本节仅适用于代码类型产物。代码优化支持以下语言的自适应分析，其他语言按通用标准处理：

语言	特有优化关注点
Python	Pythonic 写法、类型注解、标准库利用
JavaScript/TypeScript	异步模型、类型定义、bundle 体积
Go	错误处理模式、goroutine 管理、接口设计
Java	流式 API、异常体系、资源管理
Rust	所有权语义、unsafe 使用、错误传播
C/C++	内存管理、指针安全性、RAII
其他语言	按通用标准（可读性/可维护性/简洁性）分析

Step 1：多维度质量评估

根据产物类型，在各维度上进行打分和评估。只分析"有没有优化空间"，不判断"有没有 bug"。

1.1 代码优化维度

维度	分析内容	打分
性能	是否有不必要的循环、重复计算、低效数据结构、可优化的 I/O 操作？	1-5
可读性	命名是否清晰、逻辑是否直观、注释是否适量且有用？	1-5
可维护性	函数是否过长、职责是否单一、耦合度是否过高、魔法数字是否有解释？	1-5
健壮性	边界条件是否处理、异常路径是否覆盖、是否有合理的降级策略？	1-5
简洁性	是否有冗余代码、可简化的逻辑、过度的抽象层？	1-5

语言自适应：不同语言有不同的优化关注点：

Python：是否有更 Pythonic 的写法、类型注解是否完整、是否利用了标准库
JavaScript/TypeScript：是否有不必要的异步化、类型定义是否合理
Go：错误处理是否冗余、是否有 goroutine 泄漏风险
其他语言同理

1.2 设计文档优化维度

维度	分析内容	打分
架构合理性	架构选型是否匹配问题规模（过度设计/设计不足）？模块划分是否清晰？是否考虑了基本的安全设计（如认证、授权、数据保护）？	1-5
完整性	是否覆盖了所有关键设计点（接口、数据模型、错误处理、非功能需求）？有无遗漏？	1-5
清晰度	描述是否易于理解？关键决策是否有权衡说明？图表是否清晰？	1-5
可行性	方案是否技术上可落地？是否有明显的技术风险未讨论？	1-5
前瞻性	是否考虑了扩展性？是否预见了可能的变更方向？	1-5

1.3 Skill 文件优化维度

维度	分析内容	打分
触发准确性	触发短语是否精准？是否会误触发？是否覆盖了核心使用场景？	1-5
流程清晰度	执行流程是否明确？步骤间关系是否清楚？分支条件是否无歧义？	1-5
内容冗余度	是否有重复描述？示例是否过多？背景介绍是否冗长？	1-5
边界完整性	行为边界是否明确？不该做的事是否清晰标注？适用范围是否说明？	1-5
与已有Skill关系	与其他Skill的职责边界是否清晰？是否有重叠或遗漏？定位是否明确？	1-5
指令有效性	指令是否可执行？输出格式是否明确？AI 能否准确理解并执行？	1-5

1.4 评分校准锚点

各维度 1-5 分统一按以下锚点打分，确保跨分析的一致性：

分值	含义	锚点描述
1	严重不足	该维度存在明显缺陷，严重影响产物质量
2	较弱	有多处可改进，整体偏低
3	一般	基本合格，有零星可优化点
4	良好	整体不错，仅个别细节可微调
5	优秀	该维度几乎无优化空间，可作为范例

打分原则：先判断维度整体水平落在哪个区间（1-2 / 3 / 4-5），再在区间内微调。3 分是"及格线"，4 分是"良好线"。

Step 2：优化机会识别

基于各维度评估结果，识别具体的优化机会点：

## 🔍 优化机会识别

### 各维度评估

| 维度 | 评分 | 评估 |
|------|------|------|
| [维度1] | X/5 | [一句话评估] |
| [维度2] | X/5 | [一句话评估] |
| ... | ... | ... |

**总分**：[X/25]（如有 5 个维度）

### 优化机会清单

| # | 优化点 | 所属维度 | 严重度 | 根因 | 当前状态 | 优化目标 |
|---|--------|----------|--------|------|----------|----------|
| O-01 | [具体可优化的点] | [维度名] | 🔴/🟡/🟢 | [为什么会出现这个问题] | [当前存在的问题] | [期望达到的状态] |
| O-02 | ... | ... | ... | ... | ... | ... |

**严重度说明**：
- 🔴 高：优化后效果显著，收益大
- 🟡 中：值得优化，有一定收益
- 🟢 低：锦上添花，有更好没有也不影响

**根因归因规则**：
- 🔴 级优化点**必须**填写根因（回答"为什么会出现"，而非复述症状）；🟡/🟢 级可简写或填 "-"
- **同根因合并**：同一根因导致的多个症状合并为一条优化点，在"当前状态"中列出各症状表现，避免同一问题被拆成多条建议
- **根因在需求层**：若根因不在产物本身而在上游需求（如设计文档架构混乱源于需求未想清楚），标注 `[根因在需求层]`，并在报告中建议移交 `requirement-mining` 深挖，本 Skill 不展开需求分析

2.1 快速出口：高质量产物提前终止

完成维度评估后，判断是否需要走完整流程：

触发条件（同时满足以下两点）：

总分 ≥ 18/25（平均 ≥ 3.6）
无 🔴 级优化点

满足条件时：直接输出简洁结论并终止，跳过 Step 3~7：

## ✅ 优化扫描结论

**总分**：[X/25]

该产物当前质量较高，无明显优化空间。各维度均在良好线以上。

### 各维度评分

| 维度 | 评分 | 评估 |
|------|------|------|
| [维度1] | X/5 | [一句话评估] |
| [维度2] | X/5 | [一句话评估] |
| ... | ... | ... |

如需针对特定维度做深度分析，请指定关注方向。

不满足条件时：进入 Step 3 继续完整流程。

Step 3：优先级排序与优化建议

对优化机会按"收益 × 实现难度"矩阵排序，给出具体改进建议：

## 🎯 优化建议（按优先级排列）

### P0 — 高收益低难度（立即优化）

**O-XX：[优化点名称]**
- **维度**：[所属维度]
- **根因**：[为什么会出现这个问题，与 Step 2 清单的根因列对应；🟡/🟢 级可省略]
- **当前状态**：[具体描述问题所在]
- **优化目标**：[期望达到的状态]
- **改进方式**：

[具体的优化方案，如为代码则给出优化前后的对比]

- **预期收益**：[量化或定性描述优化后的效果]
- **风险评估**：[优化是否可能引入副作用]

### P1 — 高收益高难度 / 低收益低难度（择机优化）

[同上格式]

### P2 — 低收益高难度（可选优化）

[同上格式]

优先级判定规则：

收益 \ 难度	低难度	高难度
高收益	P0 立即优化	P1 择机优化
低收益	P1 择机优化	P2 可选优化

收益判定标准：

高收益：优化后影响≥3个文件/模块，或显著提升性能/可读性/可维护性，或修复了明显的架构问题
低收益：优化后影响范围小，提升不明显，或仅改善细节

难度判定标准：

低难度：不改变外部接口，不涉及架构调整，不需要大量测试验证，可在1小时内完成
高难度：需要修改接口、调整架构、大规模重构，或需要复杂的测试验证，预计工作量>4小时

Step 4：优化影响分析

评估优化建议执行后的潜在影响：

## 📊 优化影响分析

### 直接影响

| 优化点 | 影响范围 | 影响说明 |
|--------|----------|----------|
| O-01 | [受影响的功能/模块] | [优化后的正面影响] |
| O-02 | [受影响的功能/模块] | [优化后的正面影响] |

### 潜在风险

| 优化点 | 风险类型 | 风险说明 | 缓解措施 |
|--------|----------|----------|----------|
| O-XX | [性能回归/兼容性/...] | [具体风险] | [如何规避] |

### 同类优化机会（横向展开）

如果某个优化点是模式性的（如"多处使用同样低效的写法"），列出同类型的其他优化目标：

- `file_x.py:line_y`：存在相同的可优化模式
- `module_z/xxx.md`：设计文档中存在类似的结构问题

Step 5：执行建议

## 🛠 执行建议

### 建议执行顺序

| 阶段 | 优化点 | 预计工作量 | 说明 |
|------|--------|------------|------|
| 第1批 | O-01, O-03 | 小（<1h） | 低风险高收益，可立即执行 |
| 第2批 | O-02, O-04 | 中（1-4h） | 需配合测试验证 |
| 第3批 | O-05 | 大（>4h） | 涉及架构调整，建议评审后再执行 |

### 验证建议

| 优化点 | 验证方式 | 验证标准 |
|--------|----------|----------|
| O-01 | [如：运行现有测试套件] | [所有测试通过，无性能回归] |
| O-02 | [如：人工检查 + 运行集成测试] | [功能行为不变，结构更清晰] |

Step 6：输出完整优化报告

将以上分析合并为结构化报告：

# 产物优化分析报告

## 📋 基本信息
- **产物类型**：[代码 / 设计文档 / Skill]
- **产物路径**：[文件路径或"用户直接提供"]
- **分析时间**：[时间]
- **分析范围**：[简要描述分析范围]

## 🔍 优化机会识别
[Step 2 输出]

## 🎯 优化建议
[Step 3 输出]

## 📊 优化影响分析
[Step 4 输出]

## 🛠 执行建议
[Step 5 输出]

## 📝 总结

| 优先级 | 优化点数 | 预计总工作量 | 核心收益 |
|--------|----------|--------------|----------|
| P0 | N | ... | ... |
| P1 | N | ... | ... |
| P2 | N | ... | ... |

Step 7：后续步骤

分析报告输出后，询问用户：

分析报告已完成，请选择后续步骤：

1. 🛠 执行优化 — 基于报告中的 P0 建议，对产物进行优化修改
2. 🧪 发起 challenger 质疑 — 对分析报告进行二次审查，检查是否存在遗漏或误判
3. ⏭️ 跳过

请选择 [1 / 2 / 3]：

注意：选项互斥，只能选择一个执行。如需先质疑再优化，请选择 2 完成质疑后，再选择 1 执行优化。

选择 1：执行优化

先调用 request-guard 技能进行刹车检查：对用户提出的具体优化方案进行三维度检查（是否与已有约定冲突、是否有更简单方案、是否会引入副作用），防止优化方案本身不合理或过度设计
request-guard 通过：再根据报告中 P0 优化建议，对产物实施修改
request-guard 存疑：输出疑虑和替代建议，等用户确认：
- 用户确认"继续"：执行原方案
- 用户确认"换方案"：重新走 request-guard 验证新方案
- 用户确认"跳过该优化点"：继续分析下一个 P0 优化点
request-guard 拦截：输出拦截原因，跳过该优化点，继续分析其他 P0 优化点
修改完成后自动进入 auto-review

选择 2：发起 challenger 质疑

调用 challenger skill，对本次分析报告进行二次审查
challenger 质疑策略聚焦于：优化维度是否遗漏、优化建议是否切实可行、优先级判定是否合理

与已有 Skill 的关系

已有 Skill	与本 Skill 的区别
`code-review`	关注"代码是否有 bug"，本 Skill 关注"代码能不能更好"
`design-review`	关注"设计是否有缺陷"，本 Skill 关注"设计能不能更优"
`content-simplifier`	仅处理 Skill/Rules 文件的内容冗余精简，本 Skill 覆盖更广（含代码/设计文档）且维度更多
`request-guard`	在执行优化修改前做刹车检查：用户的优化方案是否与已有约定冲突、是否有更简单的替代、是否会引入副作用。本 Skill 产建议，`request-guard` 验方案
`requirement-mining`	关注"需求本身是否合理、根因是什么"，本 Skill 关注"产物能不能更好"。当优化点的根因在需求层时，本 Skill 只标注 `[根因在需求层]` 并建议移交 `requirement-mining` 深挖，不自行展开需求分析

协同使用建议：先执行 code-review / design-review 排除缺陷，再执行 artifact-optimizer 产出优化建议，执行优化前用 request-guard 验证改造方案的合理性。

行为边界

不做代码修改：只输出优化建议报告，不直接修改输入产物
不替代 review：不判断正确性，只判断优化空间。缺陷检测是 code-review / design-review 的职责
不做价值判断：不评价"这个产物值不值得做"，只评估"这个产物有没有优化空间"
需求层问题移交：发现优化点的根因在需求层时，仅标注并建议移交 requirement-mining，不在本 Skill 内做需求挖掘或方案根本性评估
推理可追溯：每条优化建议必须关联到具体的分析维度和证据（代码行、文档段落、Skill 流程步骤）
不确定性标注：对无法确认的优化建议标注 [需确认]
不编造问题：不能为了"显得有发现"而编造不存在的优化点
最终决定权归用户：优先级和建议仅供参考，用户可选择不执行或调整
专家资产优先：当存在相关模块的专家资产时，优先利用其中的最佳实践和已知坑辅助分析
快速扫描定位：本 Skill 定位为"快速优化扫描"而非"深度专项审计"。安全审查、性能压测、架构评审等深度分析应使用对应的专项工具
超大文件处理：对超过 2000 行代码或 10000 字文档的产物，先输出结构概览，由用户选择分析范围，避免 token 爆炸
零优化不做假：如果产物质量确实很高无需优化，直接输出简洁结论即可，不强行"找点问题"
维度筛选优先：用户有权指定只分析特定维度，此时仅分析指定维度，报告中需标注分析范围
重复分析去重：对已分析过的产物做二次分析时，标注"二次分析"，优先检查上次建议的落地情况，避免重复输出相同建议

artifact-optimizer

SKILL.mdskills/artifact-optimizer/SKILL.md