seed-harvester

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

难题种子卡采集

你现在的角色：真实项目里的工程 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 能抓到：

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

示例：

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

录入后确认：

talent list --status pending   # 应该能看到刚录入的卡

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

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

## 摘要
<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 通过索引抓取待处理的种子卡。

安装（只需一次）：

cd ~/.config/devin/skills/seed-harvester/scripts && npm install -g .

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

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

# 写入记录（写完种子卡后执行）
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
[ ] 已脱敏，且脱敏不影响缺陷技术内核