Artifact Optimizer

---
name: artifact-optimizer
description: 对代码、设计文档、Skill 做系统化优化分析，按优先级给出"还能更好"的改进建议（不查 bug）。触发："优化这段代码/设计/skill"、"有什么优化空间"、"怎么改进"、"artifact optimizer"；纯 review 走 code-review，修改请求走 request-guard。
---

# Artifact Optimizer（产物优化分析）

## 概述

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

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

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

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

---

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

## 核心原则

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

## 执行流程

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

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

#### 0.1 收集输入

1. **产物内容**：用户提供的代码 / 设计文档 / Skill 文件内容或路径
2. **产物上下文**：如果是代码，读取关联文件理解完整职责；如果是设计文档，读取关联的设计和需求文档；如果是 Skill，了解其在技能体系中的定位
3. **专家团查询**：调用 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>| 模块/函数名 | 行号范围 | 一句话概述 |<br>|-------------|----------|------------|<br>| ClassName | 10-50 | 处理用户认证的核心类 |<br>| main() | 100-200 | 程序入口，协调各模块 |<br>```<br>**步骤2：范围选择** - 让用户从表格中选择重点分析范围（默认选择：核心逻辑、主要函数、关键模块）<br>**步骤3：聚焦分析** - 如用户未指定，自动聚焦：代码取 main/入口函数 + 核心业务逻辑；文档取核心设计章节 |
| **产物类型混合**（如代码含大量结构化注释，或设计文档内嵌代码块） | 以主体内容为准，辅以"该文件包含 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：优化机会识别

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

```markdown
## 🔍 优化机会识别

### 各维度评估

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

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

### 优化机会清单

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

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

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

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

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

**触发条件（同时满足以下两点）**：
1. 总分 ≥ 18/25（平均 ≥ 3.6）
2. 无 🔴 级优化点

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

```markdown
## ✅ 优化扫描结论

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

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

### 各维度评分

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

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

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

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

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

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

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

**O-XX：[优化点名称]**
- **维度**：[所属维度]
- **根因**：[为什么会出现这个问题，与 Step 2 清单的根因列对应；🟡/🟢 级可省略]
- **当前状态**：[具体描述问题所在]
- **优化目标**：[期望达到的状态]
- **改进方式**：
  ```
  [具体的优化方案，如为代码则给出优化前后的对比]
  ```
- **预期收益**：[量化或定性描述优化后的效果]
- **风险评估**：[优化是否可能引入副作用]

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

[同上格式]

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

[同上格式]
```

**优先级判定规则**：
| 收益 \ 难度 | 低难度 | 高难度 |
|-------------|--------|--------|
| **高收益** | P0 立即优化 | P1 择机优化 |
| **低收益** | P1 择机优化 | P2 可选优化 |

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

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

### Step 4：优化影响分析

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

```markdown
## 📊 优化影响分析

### 直接影响

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

### 潜在风险

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

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

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

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

### Step 5：执行建议

```markdown
## 🛠 执行建议

### 建议执行顺序

| 阶段 | 优化点 | 预计工作量 | 说明 |
|------|--------|------------|------|
| 第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：后续步骤

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

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

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 爆炸
- **零优化不做假**：如果产物质量确实很高无需优化，直接输出简洁结论即可，不强行"找点问题"
- **维度筛选优先**：用户有权指定只分析特定维度，此时仅分析指定维度，报告中需标注分析范围
- **重复分析去重**：对已分析过的产物做二次分析时，标注"二次分析"，优先检查上次建议的落地情况，避免重复输出相同建议