@zer0quant 你好,从知乎那篇《我用 Codex,把投资研报到股票因子的流程做成了一个 Skill》一路读到 docs/skills/factor-research/SKILL.md,想聊聊这个 skill 的设计。
最打动我的不是它能生成因子,而是它把「研报 → 候选因子 → 人工审核 → FactorSpec → 质量门 → 代码 → 执行检查 → 归档」整条链路拆成了带 Checkpoint 的文件驱动流程——每一步产物都落盘成 factors.json/approved.json,既能让人中途介入,又能 resume。尤其是 validate_factors_json.py 把契约前置:我照着 SKILL.md 跑了一组对比输入,zer0factor-native 的 FactorSpec 通过,而 Qlib 风格的 $close + CamelCase 命名直接被拦下。这恰好挡住了 AI 写因子时最容易犯的那类错——你是有意识地把「不要生成 Qlib 可执行表达式」这条约束做成了硬校验,而不只是写在 prompt 里。
这套流程越规范,我越好奇真实用户会怎么用它:他们上传的是哪类研报,selection_mode 通常选哪个,在哪一步 Checkpoint 最常改 factors.json,代码验证三次失败后又会怎么决定。这些信号是把 SKILL.md 和 references 继续打磨下去的最好依据。
所以想给你的 SKILL.md 配一个可以直接试跑的入口:
读者点徽章就能上传一份研报 PDF 或描述一个选股因子方向,直接跑这个 skill,不用 clone 仓库、不用配 zer0share 同级目录、也不用自己的 API key——推理成本由平台承担。每一次从 README 进来的运行都会在 Socialistic 留下一条 trace,你能看到用户实际输入什么、在哪一步重试,把这些真实会话回灌进 SKILL.md 和 references/。把这个徽章嵌进 README,读者就能在 clone 之前先看到一次完整产出。
我可以把 trace 入口和几条对改进 SKILL.md 有用的真实样本一起发给你。也欢迎到 socialistic.ai 看看。有问题可以邮件 shesonglin@tinkerland.ai 或微信 crook-1184。如果觉得不相关,直接关掉这个 issue 就好。
@zer0quant 你好,从知乎那篇《我用 Codex,把投资研报到股票因子的流程做成了一个 Skill》一路读到
docs/skills/factor-research/SKILL.md,想聊聊这个 skill 的设计。最打动我的不是它能生成因子,而是它把「研报 → 候选因子 → 人工审核 → FactorSpec → 质量门 → 代码 → 执行检查 → 归档」整条链路拆成了带 Checkpoint 的文件驱动流程——每一步产物都落盘成
factors.json/approved.json,既能让人中途介入,又能 resume。尤其是validate_factors_json.py把契约前置:我照着 SKILL.md 跑了一组对比输入,zer0factor-native 的FactorSpec通过,而 Qlib 风格的$close+ CamelCase 命名直接被拦下。这恰好挡住了 AI 写因子时最容易犯的那类错——你是有意识地把「不要生成 Qlib 可执行表达式」这条约束做成了硬校验,而不只是写在 prompt 里。这套流程越规范,我越好奇真实用户会怎么用它:他们上传的是哪类研报,
selection_mode通常选哪个,在哪一步 Checkpoint 最常改factors.json,代码验证三次失败后又会怎么决定。这些信号是把 SKILL.md 和 references 继续打磨下去的最好依据。所以想给你的 SKILL.md 配一个可以直接试跑的入口:
读者点徽章就能上传一份研报 PDF 或描述一个选股因子方向,直接跑这个 skill,不用 clone 仓库、不用配
zer0share同级目录、也不用自己的 API key——推理成本由平台承担。每一次从 README 进来的运行都会在 Socialistic 留下一条 trace,你能看到用户实际输入什么、在哪一步重试,把这些真实会话回灌进SKILL.md和references/。把这个徽章嵌进 README,读者就能在 clone 之前先看到一次完整产出。我可以把 trace 入口和几条对改进 SKILL.md 有用的真实样本一起发给你。也欢迎到 socialistic.ai 看看。有问题可以邮件 shesonglin@tinkerland.ai 或微信 crook-1184。如果觉得不相关,直接关掉这个 issue 就好。