# Seed Harvester

> 在真实项目中把一个刚解决（或难以解决）的工程问题，萃取并包装成一个 最小复现包的"难题种子卡"。这个 skill 是给**真实项目里遇到问题的 AI agent**用的。当你刚啃完一个棘手 bug、部署故障、依赖冲突、配置错误、 AI review 指出的难题，或用户说"把这个坑沉淀成题"、"汇总这个错误"、 "提炼一下这个问题"、"把刚才那个问题整理出来给出题用"、"记录前因后果" 时，立即使用本 skill。产出 problem_seed.md 或 problem_seed.json （难题种子卡），作为出题流水线的交接物。

- Skill: `haaaiawd/seed-harvester` (Agent Skill)
- Install (CLI): `npx skillmds@latest add haaaiawd/seed-harvester`
- Raw SKILL.md: https://api.skillmd.com/api/skills/haaaiawd/seed-harvester/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: AI & ML
- Author: haaaiawd (https://skillmd.com/u/haaaiawd)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/haaaiawd/seed-harvester

---


# 难题种子卡采集

你现在的角色：**真实项目里的工程 agent**。你刚经历了一个真实问题——
你自己解决的、和用户一起踩坑的、或 AI review 指出而难以处理的。本 skill
的任务是把这段真实经历**萃取成一个最小复现包**，沉淀为难题种子卡，交给
下游出题流水线（`exam-author`）构造成正式评测题。

## 核心思路：萃取 + 包装

这是本 skill 最重要的一点，先想清楚再动手。

**不能拿整个大项目当题。** 真实项目体量太大、上下文太多，没法在上面测出
AI 的具体不足，下游也没法复现。所以你要做两件事：

1. **萃取缺陷内核**：从这次真实问题里剥出那个让 AI（或人）翻车的**最小
   技术内核**——去掉所有跟它无关的项目背景、业务逻辑、庞大依赖，只留下
   触发这个错误所必需的最小要素。

2. **用简单场景重新包装**：把这个内核装进一个**表面简单、普通、常见**的
   场景里。场景越平平无奇越好——一个日志分析、一个配置解析、一个服务
   启动、一个小脚本。关键是：**错误要隐蔽地藏在这个简单场景里**。

### 为什么要隐蔽

难度的真正来源不是"场景复杂"，而是"缺陷隐蔽"。一个看起来人畜无害的简单
任务，AI 会本能地用最直接的 naive 解法去做——而那条路恰好踩中你埋的隐蔽
缺陷。表面简单让 AI 放松警惕，隐蔽缺陷让它翻车。这就是能打败顶尖模型的
题该有的样子。

举例：让 AI 统计日志里的状态码——简单。但日志里混了格式略有差异的行、
或有跨行的畸形记录、或编码不一致——naive 的 `awk` 一把梭就会漏算或算错，
而 test 恰好检查这些边界。场景简单，缺陷隐蔽。

### 萃取时要保真

萃取是"提纯"，不是"编造"。这个缺陷必须是真实发生过的——它的触发机制、
失败方式、根因都来自真实经历。你只是把它从庞大上下文里抽出来、换个简单
外壳，**技术内核必须原样保留**。凭空捏造的缺陷会被平台风控识别为合成数据。

## 采集流程

### 第一步：还原真实问题

把这次问题的完整脉络过一遍，确认你能回答：

- **现象**：最初的错误表现、报错信息、失败的命令是什么？
- **触发条件**：什么操作、什么输入、什么前置状态下触发的？
- **根因链**：表层现象 → 中层原因 → 根本原因，怎么传导的？
- **解法**：最终怎么修的？关键命令/改动是什么？
- **弯路**：试错了哪些方向？哪些 naive 尝试失败了？——这部分极其宝贵，
  直接揭示 AI 易错点。

不确定的环节去核实：错误日志、git history、配置文件、依赖清单、CI 输出。
不要凭印象。

### 第二步：萃取缺陷内核

从真实问题里剥出最小技术内核：

- 触发这个错误**必需**的要素有哪些？（某个边界数据、某个配置项、某个
  执行顺序、某个环境缺失）
- 哪些是**无关**的项目背景，可以全部丢掉？
- 缺陷的本质机制是什么？（一句话说清：什么情况下、因为什么、导致什么）

### 第三步：设计简单包装场景

为这个内核找一个简单普通的外壳：

- 场景要常见、好理解，AI 一看就觉得"这不简单嘛"
- 缺陷隐蔽地嵌进去——不在任务描述里明说，藏在数据/配置/环境状态里
- 想清楚 naive AI 会怎么做这个简单任务，确保它的直接解法会踩中缺陷

### 第四步：分析 AI 卡点（难度依据）

问自己：**一个没有现场上下文的 AI agent，拿到这个简单包装会怎么翻车？**

常见卡点类型，对号入座：

- **隐蔽边界**：简单任务里藏着边界数据，naive 解法漏处理
- **幻觉参数**：会用不存在的命令行参数 / 配置项 / API
- **症状治标**：只处理表层报错，没触达根因
- **环境盲区**：默认依赖已装 / 端口可用 / 配置正确，实际不成立
- **顺序陷阱**：步骤有强依赖顺序，做错就失败
- **隐藏耦合**：改 A 会破坏看似无关的 B
- **危险操作诱导**：naive 解法会触发不可逆操作（rm/数据丢失）

写清楚：**naive AI 最可能选的错误路径是什么，正确路径需要什么洞察**。
下游据此设计 test，专门卡住 naive 解法。

### 第五步：脱敏

真实但脱敏，是合规底线：

- 公司名、内部项目名、人名 → 通用占位（`acme-service`、`internal-api`）
- 密钥、token、密码、内网 IP、域名 → 脱敏或替换为示例值
- 真实业务数据 → 结构相同的合成示例（仅数据脱敏，缺陷内核仍真实）

脱敏后确认：去掉这些信息不影响缺陷的技术内核。

### 第六步：填写种子卡

按下方模板填写，保存为 `problem_seed.md`（或等价的 `problem_seed.json`，
下游 agent 解析更方便，二选一即可）。

### 第七步：录入索引

种子卡写完后，用 `talent` CLI 录入全局索引，让下游出题 skill 能抓到：

```bash
talent add <种子卡路径> <种子卡名称> <一句话概要> --status pending
```

示例：
```bash
talent add ".devin/problem-seeds/dedup-schema-trap/problem_seed.md" \
  "dedup-schema-trap" \
  "MySQL TEXT 列建唯一索引报 1170 + 软删除标记列进唯一索引导致归档循环撞 1062" \
  --status pending
```

录入后确认：
```bash
talent list --status pending   # 应该能看到刚录入的卡
```

## 难题种子卡模板（problem_seed.md）

```markdown
# 难题种子卡：<简单包装场景的一句话标题>

## 摘要
<2-3 句话说清：这是个什么简单任务，里面藏着什么隐蔽缺陷>

## 缺陷内核（真实来源）
<从真实问题萃取出的最小技术内核：什么情况下、因为什么、导致什么。
 一句话说清缺陷的本质机制>

## 真实来源说明
<这个缺陷真实发生在什么场景里（已脱敏）。证明它来自真实经历而非编造>

## 包装场景设计
<选了什么简单普通的外壳来装这个缺陷。任务表面看起来是做什么的。
 → 下游用作 instruction.md 的任务描述>

## 缺陷如何隐蔽嵌入
<缺陷藏在哪：数据里？配置里？环境状态里？为什么 AI 不容易一眼看出。
 → 下游用来设计 environment / 输入数据 / 初始故障状态>

## 复现环境要素
<复现这个缺陷需要的环境条件：
 - 基础镜像 / 操作系统
 - 必需依赖及版本（哪些装、哪些故意不装）
 - 关键配置 / 输入数据（含隐蔽缺陷的部分）
 - 预置故障状态（残留进程、占用端口、畸形数据等）
 → 下游直接据此写 Dockerfile + 初始化脚本>

## AI 卡点分析（难度依据）
<没有现场上下文的 AI 拿到这个简单任务会怎么翻车：
 - naive AI 最可能选的直接解法：...
 - 为什么这条路会踩中隐蔽缺陷：...
 - 正确解法需要的关键洞察：...
 - 卡点类型：[隐蔽边界/幻觉参数/症状治标/环境盲区/顺序陷阱/隐藏耦合/危险操作]
 → 下游据此设计 test，专门卡住 naive 解法>

## 期望最终状态（解决判定）
<问题被真正解决后，系统应处于什么可验证的状态：
 - 哪个文件应存在 / 内容应是什么
 - 哪个进程应运行 / 哪个端口应可访问
 - 哪个命令应返回什么 / 哪个 HTTP 响应应是什么
 必须是封闭式、可自动判定的（解决 or 未解决，二元）。
 → 下游据此写 tests，决定 reward=1 的条件>

## 参考解法
<正确解出来的关键命令序列 / 改动。
 → 下游用作 solution/solve.sh 的参考>

## 试错记录（可选但宝贵）
<解决过程中走过的弯路、失败的尝试，直接反映 AI 易错点>

## 脱敏说明
<列出做了哪些脱敏处理，确认缺陷技术内核未受影响>
```

## 交接

种子卡填好后，交给下游 `exam-author` skill。它会按字段映射构造
instruction / environment / solution / tests 四件套，在虚拟环境验证 reward=1，
并用 naive 解法自测难度。

### 种子卡索引（CLI）

种子卡写完后，用 CLI 录入全局索引。下游出题 skill 通过索引抓取待处理的种子卡。

**安装**（只需一次）：
```bash
cd ~/.config/devin/skills/seed-harvester/scripts && npm install -g .
```

安装后直接用 `talent` 命令，无需 node 前缀。

**索引数据**：`~/.config/devin/seed-index.json`

```bash
# 写入记录（写完种子卡后执行）
talent add <path> <name> <summary> [--status pending]

# 抓取记录（出题 skill 用这个找待处理的种子卡）
talent list [--status pending]

# 更新状态（开始做题时改 ready，提交平台后改 submitted）
talent update <name> --status ready

# 标记种子卡已被用于某题（支持多种子卡融合成一道题）
talent link <name> <examDir>

# 查看统计
talent stats
```

**状态流转**：`pending`（刚采集）→ `ready`（开始做题）→ `submitted`（题目已提交平台）

### 种子卡与题目的映射关系

种子卡和最终题目**不是 1:1**。多张种子卡可以融合成一道题：

- **1:1**：一张种子卡单独成题（如 `ssrf-webhook` → `ssrf-webhook` 题）
- **N:1**：多张种子卡融合成一道题（如 `stuck-pending-throw` + `dead-retry-guard` → `exam_003`）

融合策略见 `exam-author` skill 的"多 bug 合并"章节：bug 1 当幌子，
bug 2 是真 bug，两个都必须修才能过 test。

用 `link` 命令记录映射关系后，`stats` 会显示题目→种子卡的完整映射：

```
题目 → 种子卡映射:
  exam_003 ← stuck-pending-throw + dead-retry-guard
  ssrf-webhook ← ssrf-webhook
```

## 质量自检

交付前确认：

```
[ ] 缺陷真实发生过，不是编造（反合成数据）
[ ] 已萃取成最小复现包，剥掉了无关的大项目上下文
[ ] 包装场景简单普通，缺陷隐蔽嵌入而非明说
[ ] 想清楚了 naive AI 的直接解法会踩中缺陷
[ ] 根因链完整，从现象追到了根本原因
[ ] 期望最终状态是封闭式、可自动判定的（二元结果）
[ ] 复现环境要素足够下游搭出 Dockerfile
[ ] 已脱敏，且脱敏不影响缺陷技术内核
```