| 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 的具体不足，下游也没法复现。所以你要做两件事：
-
萃取缺陷内核：从这次真实问题里剥出那个让 AI（或人）翻车的最小
技术内核——去掉所有跟它无关的项目背景、业务逻辑、庞大依赖，只留下
触发这个错误所必需的最小要素。
-
用简单场景重新包装：把这个内核装进一个表面简单、普通、常见的
场景里。场景越平平无奇越好——一个日志分析、一个配置解析、一个服务
启动、一个小脚本。关键是：错误要隐蔽地藏在这个简单场景里。
为什么要隐蔽
难度的真正来源不是"场景复杂"，而是"缺陷隐蔽"。一个看起来人畜无害的简单
任务，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]
talent list [--status pending]
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
[ ] 已脱敏，且脱敏不影响缺陷技术内核
