research-to-skill

投研分析到 Skill 开发 SOP——把一次性深度分析沉淀为长期可运行 skill 的五阶段标准流程（立项判断→一次性投研→验证门禁→skill化沉淀→双模式运行与迭代）与十条核心规则。当用户说"把这次分析做成skill""总结成SOP""这个研究以后要反复用""开发监控类skill""分析结论怎么固化"时使用。

投研分析到 Skill 开发 SOP

0. 技能定位

把「一次性投研分析 → 长期可运行 skill」的完整过程固化为五阶段标准流程：立项判断、一次性投研、验证门禁、skill化沉淀、双模式运行与迭代。适用于任何"分析结论需要反复使用或持续监控"的场景——金融信号监控、事件跟踪、数据规律沉淀、策略验证皆可，不绑定特定市场或数据类型。

案例引用（SOP 来源项目）：本 SOP 源自两个真实 skill 的完整生命周期——量价类抄底信号监控与政策托底强度监控。前者用十余年日线回测验证信号、按固定周期自动重跑；后者维护历史政策事件库、按事件分类研判托底强度。两个项目分别验证了"数据驱动型"与"事件驱动型"两条 skill 化路径，本 SOP 的每条规则都来自这两个项目的实战教训。

When to Use

• 刚完成一份深度分析（投研/数据/策略），判断它值不值得做成 skill
• 把"手动分析→出结论"的过程固化为可重复执行、可自动运行的规则
• 审阅或重构已有的分析型 skill，判断其结构是否符合双模式标准

Don't use for: 一次性交付的分析报告（做完即止、无复用需求）；纯叙事型复盘文档。

一、五阶段流程

阶段一：立项判断——先决定要不要做

做成 skill 之前，先回答三个问题：

1. 是否反复使用？ 这个分析是"做一次就够"还是"以后还要用、要持续盯"？一次性的 → 报告交付即可，不做 skill。
2. 结论能否编码？ 分析结论能否写成确定的规则（阈值、判断分支、分类表），而不是依赖临场发挥？能编码 → 可沉淀；结论高度依赖人工判断 → 暂缓。
3. 触发场景是否清晰？ 用户以后会用什么话触发它（如"现在能不能买""今天有什么信号"）？没有清晰触发场景的 skill 不会被调用，等于没做。

三问全过 → 进入阶段二。任一不满足 → 不做或缩小范围。

案例引用（立项判断）：某次分析完成后用户追问"能不能把这套逻辑做成 skill"——当时已具备全部条件：结论可编码为信号阈值表、用户有明确的反复触发场景（日常监控）、且分析本身已积累多年数据。三问全过才启动 skill 化。

阶段二：一次性投研——先研究透，再谈沉淀

这一阶段只做一件事：把分析做扎实，产出「结论 + 口径」双份资产。关键动作：

1. 先写口径，再跑数据。 在开始统计之前，把每个指标的定义、窗口、去重规则、基准线写下来。口径不预先定死，后面必然出现"怎么数都对不上"的口径漂移。
2. 数据可复现。 数据源、拉取脚本、截止日期全部记录；数据增量更新而非整表重写；完整性检查是必跑项。
3. 结论分级。 每条结论标注样本量与可信度。小样本结论不得写成确定性结论。
4. 留存底稿。 分析脚本、中间产物、明细表归档到独立目录，只增不改。底稿是后续所有修订的修订基准。

产出物：一份研究底稿（含口径定义、结论清单、样本明细）。

案例引用（口径预定义教训）：量价信号初版统计未识别"同一行情起点"，同一轮行情被多次触发重复计数，胜率双向失真——高估型信号从 86.7% 修正到 75%，低估型信号从 37.8% 修正到 80%（方向反转）。根因是去重口径未预先定义。修复后统一为"窗口不重叠"口径：相邻触发间隔≥持仓窗口则合并、保留首个。

阶段三：验证门禁——结论要过得了审

投研结论从"看起来对"到"可以写进 skill"，必须过以下门禁：

1. 基准对比。 结论优于随机/运气线才算有效。没有对照基准的胜率没有意义。
2. 敏感性检验。 换口径、换窗口、换去重规则，结论是否稳定？大幅波动要查明原因。
3. 独立复核。 关键反转结论至少用另一路证据交叉验证（如事件明细 + 独立统计 + 图形目视）。
4. 用户签收。 与既有结论相反的重大变更，必须向用户展示证据并获得确认后才能落库。未经签收的结论不得进入知识库。

案例引用（人工复核）：某指数回测出现"强烈反向"信号，经三路交叉验证（事件明细、独立谷底统计、K线目视）确认为重复计数假象，方向实为反转有效——但样本量打折后仍需标注小样本。复核结论由用户拍板后才修订知识库。

阶段四：skill化沉淀——把结论变成执行程序

skill 的本质是执行程序，不是交接报告。沉淀阶段遵守以下结构：

1. 主文档只写可执行结论。 SKILL.md 只保留当前权威的规则、阈值、命令、判定分支；研究过程、口径沿革、修正记录一律不进正文。
2. 双层知识库。 机器可读文件（JSON，供程序读取判断）与人类可读文件（MD，供专家审阅）各一份，二者同步修订，防止漂移。
3. 单一口径源。 统计口径与术语定义放在一个稳定文件（如 references/口径.md），所有脚本与报告不得偏离。
4. 台账只增不改。 更新历史文件只追加、不修改旧条目，顶部放最新。
5. 目录隔离。 代码（scripts）、知识（references）、数据（data）、归档（stats）分目录；归档目录 append-only，每次重跑生成新的时间戳子目录。
6. 数据管理写死。 数据源、更新命令、完整性检查、密钥缺失时的行为（索要而非静默跳过）全部写成明确指令。

案例引用（目录结构）：监控类 skill 的标准骨架为 SKILL.md + references（机器地图 JSON / 人读地图 MD / 单一口径 MD / 台账 MD）+ scripts（公共库、拉数、完整性检查、重跑、监控）+ data + stats（YYYYMMDD/ 归档）。事件驱动类 skill 的差异点在于知识库主体是历史事件库而非信号表。

阶段五：双模式运行与迭代——让它自己活起来

skill 上线后按双模式运转：

• 模式A（日常运行）：用固化后的规则做判断/监控/输出。输入当前状态 → 查知识库 → 输出结论。模式A 不改知识库。
• 模式B（周期自更新）：按固定周期重跑全部统计 → 与上一版归档比对 → 结论变化分级（不变/微调/重大）→ 重大变更先经用户签收 → 修订知识库 → 追加台账 → 新归档。

铁律：未经重跑不得改结论，未经记录不得改知识库。 模式B 的触发周期写进 SKILL.md（如"距上次重跑超过 N 天自动触发"），不依赖人工记忆。

案例引用（双模式）：量价监控 skill 模式A 输出各标的的抄底信号，模式B 每 180 天自动全量重跑统计并修订信号地图。事件驱动 skill 模式A 在信号触发后的交易日运行，模式B 按固定 cron（如每年 5/11 月）重跑事件统计。两类 skill 共享"模式A 消费知识库、模式B 修订知识库"的分工。

二、核心规则表

规则	说明
先定口径，再跑数据	指标定义/窗口/去重/基准在统计前写死；口径漂移是结论失真的首要来源
结论必须过基准	与随机/运气线对比，不显著优于基准的信号无效
小样本必须警示	样本不足的结论附样本量、标注待观察，禁止表述为确定性结论
重大变更先签收	与既有结论相反的变更，向用户展示证据、获确认后才落库
只写结论，不写过程	SKILL.md 正文只留当前权威规则；研究过程进底稿与台账
机器与人读同步	程序读的 JSON 与专家读的 MD 同步修订，防止知识库漂移
单一口径源	口径定义收口在一个稳定文件，脚本与报告不得偏离
台账只增不改	更新历史只追加、不修改旧条目
归档 append-only	每次重跑生成新时间戳目录，旧归档永不覆盖
双模式分工	模式A 消费知识库、模式B 修订知识库；未经重跑不改结论、未经记录不改知识库

三、Common Pitfalls

1. 把研究报告当 skill 写。 正文堆研究过程、口径沿革、修正对照——agent 拿不到确定性指令，专家被迫考古。过程进底稿/台账，正文只留规则。
2. 口径事后补。 先跑数据再定义口径，等于让数据决定结论。任何统计开始前先把口径写死。
3. 重复计数不自知。 同一事件被多次触发却按多次统计，胜率双向失真（高估或低估都可能）。去重规则必须预先定义并写入口径。
4. 把样本内拟合当通用结论。 拟合值被误标为样本外表现，夸大预测力。发布前核对每个数字的口径属性。
5. 小样本不标注。 触发次数个位数的信号写成高胜率结论，误导后续判断。样本量永远跟着结论走。
6. 知识库静默修改。 不重跑就改结论、不改台账就改知识库——破坏可追溯性，后续比对全部失锚。
7. 机器与人读脱节。 JSON 改了 MD 没改（或反之），程序判断与人工审阅看到两套规则。
8. 跨场景套用结论。 场景A 验证的规则直接套到场景B。每条规则必须绑定其验证场景。
9. 签收环节缺失。 重大结论反转不经过用户确认直接落库，事后返工成本远高于事前一次确认。

四、Verification Checklist

• 立项三问已过：反复使用？可编码？触发场景清晰？
• 口径在统计前已定义，写入单一口径源文件
• 每条结论有样本量与基准对比
• 重大变更已经用户签收
• SKILL.md 正文无研究过程/口径沿革/溯源对账句
• 机器知识库与人读知识库内容一致
• 台账只增不改，归档目录 append-only
• 模式A 与模式B 的分工、触发周期写死在 SKILL.md
• 数据管理指令完整：数据源/更新命令/完整性检查/密钥缺失行为