1. 为什么突然想写投研 Skill最近一个月我几乎把所有业余时间都耗在折腾 AI Agent 的 Skill 机制上起因特别简单我在用 Claude Code 和 Codex 做一些量化数据的抓取和分析发现每次都要重复粘贴一大段提示词把“帮我拉取某只股票最近五年的财务数据、计算年化波动率、再对照行业均值给个结论”这种话术来回打磨。时间一长我实在受不了了索性把整套流程固化成一个可复用的 Skill 包之后不管是分析 A 股个股、港股还是美股 ETF只需要一句话触发Agent 就能自动走完数据获取、指标计算、报告生成的全流程。这篇文章写的不是某个具体股票的投资建议而是把我做这套“AI 投研 Skill”的完整思路、实现过程、踩坑记录一次讲透。如果你本身在用 AI 辅助做投资研究、量化分析或者正在学习 Claude Code Skill、OpenAI Codex Skill、DeepSeek Harness 这类 Agent 扩展机制那么这篇内容应该能直接帮你省掉至少两周的摸索时间。我会从 Skill 的本质讲起给出一个可以直接抄作业的投研 Skill 项目结构再把我实测过的不同模型支持情况列成表格最后是高频问题排查和几条只有真跑过才会懂的避坑经验。2. 先把概念理清楚Skill 到底是什么和 Agent、插件有什么区别2.1 Skill 不是插件是提示词工程的最优封装我用一个最直白的方式来解释传统插件是给程序加功能而 Skill 是给 AI 加“做事的方式”。拿投研来说插件可能会帮你拉取实时行情、调用某个数据库的 API但 Skill 做的是另一件事——当 AI 拿到行情数据之后它应该按照什么维度去分析ROE 和毛利率的权重怎么分配结论该怎么写才不误导人这些“分析方法论”本身就是 Skill 的核心。可以这样理解你给实习生一份《研究报告写作手册》里面规定了数据来源、计算口径、分析框架、输出模板那这份手册就是 Skill。AI Agent 是那个实习生插件是实习生手里的计算器和数据库账号而 Skill 是实习生脑子里的工作流程。没有 SkillAI 每次都在自由发挥这次用市盈率下次用市净率报告格式也千奇百怪有了 SkillAgent 的行为就是可预期、可复现的。2.2 Skill 与 Agent 的分工逻辑现在网上关于“Skill 和 Agent 的区别”讨论很多我自己实测下来最准确的表述是Agent 是调度者Skill 是执行者的能力包。Agent 决定“接下来做什么”Skill 决定“这件事具体怎么做”。比如我让 Agent 去“分析一下新能源板块”Agent 会先拆解任务拉数据、算指标、看新闻、写报告。然后它去调用对应的 Skill——数据拉取 Skill 负责下载数据估值分析 Skill 负责算 PE/PB 分位数新闻情绪 Skill 负责抓舆情最后报告生成 Skill 把前面所有结果组装成一篇完整的投研纪要。这里有一个关键点Skill 之间是可以串联的。我在实际项目里把投研拆成了 4 个独立 Skill而不是一个大而全的 Skill。好处是单个 Skill 的提示词更短、更聚焦Agent 在需要的时候才加载对应 Skill不会把一堆无关指令塞进上下文浪费宝贵的上下文窗口。这一点在 Claude Code 和 Codex 上体现得特别明显Skill 越聚焦模型的理解和执行准确率越高。我在项目里把投研拆成了 4 个独立 Skill而不是一个大而全的 Skill。好处是单个 Skill 的提示词更短、更聚焦Agent 在需要的时候才加载对应 Skill不会把一堆无关指令塞进上下文浪费宝贵的上下文窗口。这一点在 Claude Code 和 Codex 上体现得特别明显Skill 越聚焦模型的理解和执行准确率越高。2.3 为什么投研特别适合用 Skill 来固化投研这件事天然适合 Skill 化因为它有几个明显特征流程固定数据→指标→结论、口径敏感同一个指标不同算法差很远、输出要求高结论必须可追溯、可解释。这些特征正是 Skill 最擅长解决的。我最早手动让 AI 分析股票时经常遇到一个尴尬情况我让它算“年化收益”它给我按算术平均算但实际上应该用几何平均我说“看看估值贵不贵”它直接拿当前 PE 和历史均值比完全忽略行业属性差异。这些口径问题全部可以写进 Skill 的定义里从机制上避免 AI 自由发挥。另外投研还有一个痛点涉及的数据维度非常多。基本面、技术面、资金面、情绪面每个维度都有不同的数据源和计算方式。如果全靠对话式提示词AI 很容易做着做着就忘了前面要求输出前后矛盾。Skill 把每个维度的分析要求、数据来源、计算步骤都写死之后Agent 的执行稳定性能提高一个量级。我实测下来在固定 Skill 加持下连续分析 20 只股票的输出格式一致性比纯提示词至少高出 80%。3. 一个投研 Skill 的完整解剖目录结构、配置文件和执行流程3.1 先看整体目录长什么样我做的这套投研 Skill 包放在一个独立目录里结构如下ai-investing-skill/ ├── SKILL.md ├── scripts/ │ ├── fetch_quotes.py │ ├── fetch_financials.py │ ├── calculate_metrics.py │ └── export_report.py ├── templates/ │ ├── report_template.md │ └── analysis_prompt.md ├── data/ │ └── sector_benchmark.json └── config.yaml这不是我拍脑袋设计的结构而是我在跑了几个不同平台的 Skill 之后总结出来的最通用形态。SKILL.md 是入口文件相当于“这份 Skill 的使用说明书”scripts 目录存放实际执行数据抓取和计算的脚本templates 目录存放生成报告用的模板data 目录放行业基准数据等静态参考config.yaml 存一些可调参数。不同平台对这个结构的识别方式略有差异比如 Claude Code 更看重 SKILL.md 的描述信息Codex 则偏向直接执行 scripts 里的代码但整体框架可以共用。3.2 SKILL.md 的写法与设计要点这是整个 Skill 的灵魂文件我花的时间最多。先看一个简化版的内容--- name: ai-investing-analysis description: 基于多维度数据的个股投研分析。当用户提到分析某只股票、写一份投研报告、评估某公司投资价值时自动触发。适用于A股、港股、美股个股基本面与技术面分析。 version: 1.0.0 author: your-name tags: [investment, stock-analysis, research, fundamental-analysis] --- # AI 投研分析 Skill ## Goals - 对目标公司进行基本面、技术面、资金面三维度分析 - 输出结构化投研报告包含数据来源、计算口径、风险提示 ## Steps 1. 确认目标股票代码和市场A股/港股/美股 2. 调用 scripts/fetch_quotes.py 获取行情数据 3. 调用 scripts/fetch_financials.py 获取财务数据 4. 调用 scripts/calculate_metrics.py 计算核心指标 5. 对照 data/sector_benchmark.json 做行业对比 6. 使用 templates/report_template.md 生成最终报告 ## Constraints - 所有财务指标必须注明计算口径 - 不得给出直接的买卖建议只做客观分析 - 若数据获取失败明确输出失败原因不编造数据 - 估值判断必须对比行业基准禁止孤立看绝对数值 ## Output Format - 使用 Markdown 表格展示核心指标 - 报告必须包含公司概况、财务分析、技术分析、风险评估、结论五个章节设计要点我总结成三条。第一description 字段要写得尽量详细因为它决定了 Skill 在什么条件下被触发写得太宽泛会导致 AI 在不该用的时候乱用第二Constraints 必须放在显眼位置这是控制 AI 输出质量的“法律条文”特别是“不编造数据”和“注明计算口径”这两条几乎解决了我之前一半的问题第三Steps 要写清楚调用顺序和依赖关系避免 AI 跳过数据获取直接开始分析那样结果全是幻觉。3.3 投研 Skill 的几个关键脚本设计SKILL.md 只是告诉了 AI “该做什么”真正干活的还有脚本。我这里挑选三个最核心的脚本讲讲设计思路。数据获取脚本 fetch_quotes.py 的主要职责是拉行情数据我目前兼容了 A 股和港股用 akshare 作为数据源备选方案是 tushare。这里有个非常关键的工程细节aakshare 的接口经常变动所以我在脚本里加了异常捕获和重试机制并且把数据缓存在本地 data 目录避免每次分析都要重复请求。缓存文件按{symbol}_{date}.json命名当天重复分析同一只股票时直接读缓存速度能快十倍以上。指标计算脚本 calculate_metrics.py 负责把原始财务数据加工成分析指标。我在这里踩过最深的坑是财务数据的单位问题A股财报里有些字段单位是元有些是万元如果不做统一处理算出来的指标可能差一万倍。所以我专门加了一层单位自动识别和归一化逻辑比如识别到“营业收入”数值在十亿级别就自动认为单位是元在十万级别就认为是万元然后统一转成元存储。这个细节如果不处理AI 生成的报告就会犯低级错误。报告生成脚本 export_report.py 做的事情没那么复杂就是把计算好的指标填进模板生成最终的 Markdown 报告。不过这里也有一个设计取舍我让脚本做基础组装但真正的分析解读交给大模型来做。也就是说脚本负责把数据表格整理好AI 负责基于这些数据写结论。这样分工的好处是AI 的输出有真实数据打底不会凭空编造数字。3.4 配置文件里该放什么config.yaml 看似不起眼实际是调参的乐趣所在。我举几个我实际放进去的参数data_source: a_share: akshare hk: akshare us: yfinance cache: enabled: true expire_hours: 24 metrics: valuation: [pe, pb, ps] growth: [revenue_yoy, profit_yoy] profitability: [roe, gross_margin, net_margin] solvency: [debt_ratio, current_ratio] risk: max_volatility_warning: 0.4 max_concentration_warning: 0.3 report: language: zhs include_benchmark: true把指标列表和阈值放进配置的好处是你不需要改 Skill 的提示词就能调整分析维度。比如我想多分析一个现金流指标只需在 config.yaml 的 metrics 里加上 cashflow 相关项然后同步更新一下报告模板Agent 就会按照新配置执行。这种“配置驱动”的设计思路让我在调优时不用反复改提示词大大降低了试错成本。4. 实战搭建一套股票分析 Skill从触发到完整报告4.1 触发词的设置与 Agent 选择这一步很多人会忽略但直接决定了你的 Skill 好不好用。我在 description 字段里写的是“当用户提到‘分析某只股票’、‘写一份投研报告’、‘评估某公司投资价值’时自动触发”。实际测试下来我自己项目里的 Claude Code 和 Codex 都能正确识别这些触发条件但响应方式有所不同Claude Code 会先展示它解析出的意图然后询问我确认再执行Codex 更直接识别到触发词后就自动开始跑流程中间基本不打断我。如果你用的是 Cursor 这类编辑器触发机制又不太一样它更依赖文件上下文和规则配置Skill 文件的识别更多通过AGENTS.md里声明。这里有个很重要的实测结论不同 Agent 对 Skill 的加载策略不同。Claude Code 官方主打的是 Claude Skills 的概念对 SKILL.md 的描述信息解析得非常细会通过语义匹配来决定是否加载Codex 的 skill 则更接近一种工作流定义它偏向把 Skill 文件中的步骤转成可执行的 TODO 列表DeepSeek Harness 这类开源工具也支持类似 skill 的机制但它的加载逻辑更轻量基本是靠关键词匹配。我在开发时始终遵循一个原则SKILL.md 写清楚“什么时候用、怎么用、有什么限制”这是所有平台都能识别的最大公约数。4.2 数据获取的实操细节与常见口径问题数据获取是整个流程最容易翻车的环节。我用一个具体案例来说明上个月我让它分析某只A股消费股提示词写的是“分析一下贵州茅台”结果 Agent 直接把“贵州茅台”当成关键词去 akshare 拉数据拉回来的是一堆无关的新闻和相关股票列表而不是 600519 的行情。后面我在 SKILL.md 里加了一条明确约束第一步必须先做股票代码映射A股统一使用 6 位代码港股使用 5 位代码美股使用 ticker 符号用户只提供中文名时必须通过搜索接口转换为标准代码再继续。财务数据的拉取还有个更隐蔽的问题不同数据商对同一指标的算法可能不一致。比如 ROE 就有加权 ROE 和摊薄 ROE 两种口径毛利率有无“剔除营业税金及附加”的差别。我现在的做法是在 SKILL.md 的 Constraints 里写死口径“本 Skill 统一使用加权 ROE毛利率 (营业收入 - 营业成本) / 营业收入若数据源仅提供摊薄 ROE须在报告中显式标注”。这样虽然牺牲了一定的灵活性但换来了结果的一致性和可对比性。分析同一行业的十家公司时如果每家的 ROE 口径都不一样那份报告基本就废了。4.3 指标计算的完整链路从原始数据到分析结论下面是我实际的指标计算链路每一步解决一个问题第一步原始数据清洗。把获取到的 DataFrame 做空值处理、去重、单位归一化。这一阶段的目标是让数据“能用”不代表“能用好”。比如财务数据里有少数年份缺失我会先做向前填充同时把缺失年份登记在报告备注里提醒查看报告的人注意。第二步计算核心财务指标。从 config.yaml 中读取指标列表逐项计算。偿债能力指标要注意流动比率和速动比率要分行业看比如房地产行业普遍偏低不能用制造业的基准去套。所以我引入了 sector_benchmark.json把行业分位数作为一个重要参照避免孤立看绝对数字得出荒谬结论。第三步估值指标的计算有一个必须处理的脏数据问题净资产为负的公司算出来的 PB 会变成负数但在金融终端里这类公司通常显示为“N/A”或者“亏损”。同样PE 在亏损年份会失真。我的脚本里专门处理了这类边界情况当净利润或净资产为负时把对应指标置为 null而不是给一个负数。理由很简单分析师写报告时不会说“这家公司的 PE 是 -5 倍”这样说没有任何意义只会误导读者。第四步技术指标计算。这里我用的是最基础但也最稳定的几个指标20 日和 60 日均线、MACD、RSI(14)。没用太复杂的机器学习模型去预测涨跌原因不是我保守而是实测下来在投研报告里技术指标的作用是描述当前市场状态而不是预测未来。写清楚“股价位于 60 日均线下方短期趋势偏弱”比一句“AI 预测未来一周上涨概率 75%”负责任得多。第五步汇总生成报告。脚本把所有计算结果输出成一个 JSON 中间文件然后用模板拼装。拼装完成后大模型会根据这个结构化数据做最终的“人话化”解读。4.4 完整实战分析一只股票的 Skill 执行记录我完整跑一遍当时分析某新能源龙头用“宁德时代”作为案例但不构成投资建议的记录。第一步我在 Claude Code 里输入“用投研 Skill 分析一下宁德时代。”Agent 收到后先加载 SKILL.md然后回复说“识别到投研分析需求目标股票宁德时代300750开始执行分析流程。”第二步Agent 调用脚本转换股票代码。这里触发了我的股票代码映射逻辑确认 300750 属于创业板市场类型判断为深市 A 股数据源切换到 akshare 的相应接口。第三步拉取行情数据。脚本先检查缓存发现当日没有缓存文件于是发起网络请求。A 股日线行情数据拉取还算顺利返回了近三年约 700 个交易日的开盘、收盘、最高、最低、成交量数据。这里我特意要求保留成交量数据因为后面计算资金面指标时要用。第四步拉取财务数据。这一步遇到了一点问题akshare 返回的某一条财务数据里有一年是缺失的脚本自动做了向前填充并在备注里标注“该公司2021年部分财务数据缺失已用2020年数据填充”。我对这个行为是接受的因为投资分析本身就需要处理不完整信息关键是要让它显式地告诉你而不是默默填上一个数。第五步指标计算。脚本输出了一组关键数据当前 PE 44 倍PB 6.8 倍ROE 约 19.5%毛利率约 25.4%资产负债率约 69%营收同比增长约 22%净利润同比增长约 30%。同时计算了 20 日涨跌幅、60 日涨跌幅、RSI 等技术指标。第六步行业对比。通俗一点说就是把这个公司的估值和利润水平放进新能源电池行业里做横向比较。结果显示行业平均 PE 是 28 倍宁德时代 44 倍明显偏高但它的 ROE 也显著高于行业平均的 12%属于典型的“高估值、高盈利”组合。第七步报告生成。Agent 把这些数据按模板填充再结合之前设定的 Constraints 输出了一份完整报告。报告开头有一段概述“宁德时代当前估值处于行业高位但盈利能力显著优于同行。技术上短期处于回调状态中长期均线仍然呈现多头排列。风险点在于行业竞争加剧导致的毛利率下行压力。本报告仅为客观数据分析不构成买卖建议。”从输入指令到拿到完整报告整个过程大约 4 分钟其中大部分时间花在数据抓取和指标计算上大模型的分析解读只占最后几十秒。这个速度相比我最早手动搜集数据、手动计算、再让 AI 写分析效率提升是数量级的。5. 不同模型对投研 Skill 的支持情况实测5.1 主流 Agent 的 Skill 支持对比我自己实际测了 Claude Code、OpenAI Codex、DeepSeek Harness 和 Cursor 这几个主流环境把它们的 Skill 支持情况整理成了一个表方便大家选型。这个表完全基于我的实测不同版本可能略有差异。AgentSkill 文件格式触发机制脚本执行上下文效率实测体验Claude CodeSKILL.md 目录语义匹配自动加载支持 bash/python较高加载而非全量注入最接近“规范”的体验对 developer 友好OpenAI Codex.md 描述 可执行步骤关键词识别 工作流解析支持 bash/python中等偏向工作流执行执行效率高但复杂任务偶尔会跳过约束DeepSeek Harness轻量 markdown 描述关键词匹配支持一般适合快速原型不太适合复杂生产流程CursorAGENTS.md 规则文件文件上下文感知支持视项目大小而定更适合写代码投研全套流程执行不如上面两个顺畅这里我特别想强调一个观点选什么 Agent 不取决于谁更“强”而取决于你的使用场景。如果主要是在命令行里快速做分析、跑脚本Claude Code 的体验最好它的 Skill 机制最规范对 SKILL.md 的解析也最到位。如果更偏重批量自动化、把分析流程做成定时任务Codex 的流程执行能力更合适。DeepSeek Harness 适合先在本地快速验证思路等确认效果再迁移到正式环境。5.2 模型差异对分析质量的影响除了 Agent 外壳底层模型对投研分析质量的影响其实更大。我用同一个 Skill 包分别让 Claude 和 GPT 模型跑了几轮发现一个有意思的差异Claude 更擅长在遵守约束的前提下输出结构化报告它的文字更克制不会为了显得专业而编造数据GPT 系列在理解复杂指令上更强但偶尔会在报告里稍微放飞一点加入一些原数据里没有的“合理化猜测”。我的解决方案是在 Constraints 里把“必须基于脚本输出的 JSON 数据进行描述禁止新增数据点”这一条写得极其严格并且要求 Agent 在最终报告里附上“数据来源与口径说明”章节这样即使模型想自由发挥也会被拉回来。还有一个让我很惊讶的发现纯文本模型和带工具的模型在这个场景下差距远超预期。带工具调用的模型能真正去执行脚本、读取结果、基于真实数据写报告纯文本模型即使你把数据包在提示词里给它它在分析时也经常忽略数据细节倾向于泛泛而谈。所以如果要用 AI 做辅助投研强烈建议选择支持函数调用或工具使用的 API 版本不要用对话版模型硬撑。5.3 模型上下文大小对 Skill 设计的影响上下文窗口大小直接影响 Skill 的设计策略。我的 SKILL.md 大概 2000 字左右几个脚本加起来几百行如果全部塞进上下文会白白占用几千 token。所以我做了一个“壳 核”的设计SKILL.md 只是壳它只描述流程框架和约束真正的超长内容是脚本代码和模板那些通过 scripts 目录加载不占用提示词空间。这样设计后一次分析任务的完整上下文占用大概在 8000 到 12000 token 之间远低于模型上限给后面的数据表格留足了空间。6. Skill 设计中的绕坑经验与边界问题6.1 上下文污染最容易被忽视的问题我最早使用 Skill 时犯过一个低级错误让多个 Skill 共用同一个全局提示词前缀。结果每次执行时AI 都会把其他 Skill 的约束也加载进来导致互相干扰。比如我的另一个“代码审查 Skill”里有一条约束“涉及生产环境配置变更时必须打回”结果在执行投研分析时AI 居然对报告里的“公司产能扩张计划”给出了“生产环境变更风险过高建议打回”的荒谬结论。这种上下文污染问题在 Skill 多起来之后会越来越严重。解决方法是每个 SKILL.md 只描述自己领域内的规则领域外的内容一律不写并且明确写上“本 Skill 不分析其他领域问题”这种隔离性约束。6.2 踩过坑的高频依赖安装问题Skill 里的脚本会依赖很多 Python 包最常见的是 akshare、pandas、yfinance。这里最大的坑是版本兼容。akshare 更新非常频繁偶尔改一个函数名整个脚本直接跑挂。我在环境准备上做了两件事一是用 requirements.txt 锁死版本号而不是用pip install akshare这种自取最新的方式二是写了一个 dependency_check.py 放在 scripts 里每次执行前快速 import 检查关键依赖如果版本不对就给出提示。这个脚本虽然简单但真的帮我省了很多在分析到一半时才发现缺包的时间。6.3 Skill 设计的边界什么时候该用什么时候该放弃不是所有投研任务都适合用 Skill。我自己总结了一条非常朴素的经验如果某个任务的输入输出结构固定、执行步骤清晰、结果可以被模板化表达那它适合写成 Skill如果任务高度依赖主观判断、每次切入角度都不同、结果没有统一格式那强行做成 Skill 只会让 AI 的输出变僵化。举个例子像“分析某公司年报中的竞争优势”这种开放性问题我就不放进 Skill因为它需要根据年报具体内容灵活调整分析框架。反而“拉取财务数据→计算指标→对比行业→输出表格”这种流水线任务是 Skill 的最佳适用场景。一次把边界理清能让你的 Skill 库保持精简也避免 Agent 在不合适的场景下强行动用 Skill 导致效果更差。7. 高频问题排查与优化技巧实录7.1 数据源失效问题akshare 的接口经常变遇到“数据拉取失败”是最常见的问题。我的排查顺序是先看错误信息是网络超时还是接口报错如果是网络问题等 30 秒重试通常能好如果是接口报错就去 akshare 的更新日志里查有没有接口名变更。实在不行就启动备选方案——切到 tushare 或者直接读本地缓存的旧数据并在报告里注明“数据截止日期为 X 月 X 日”。这些步骤我全写进了 SKILL.mdAgent 遇到问题时不用问人自己就能按流程处理。7.2 报告内容跑偏问题还有一个高频问题报告生成阶段 AI 擅自加入了一些数据里不存在的“分析结论”。比如有一份报告里AI 写了一句“该公司管理层近期有减持计划”但我拉取的数据里根本没有这条信息。后来把 Constraints 里明确加上“报告中的所有事实性信息必须来自脚本输出的结构化数据任何额外信息必须标注为 ‘额外补充’ 并说明信息来源”。加了这条之后这类幻觉问题几乎降为了零。这里我的建议是不要指望模型“自觉”要把不合理的输出路径直接用规则切断。7.3 大型报告生成时的 token 控制生成一份比较详尽的投研报告文本量可能在 3000 字以上加上中间的数据处理结果和工具调用过程token 消耗不小。我测试下来一份报告全流程大概会消耗 2 到 4 万 token取决于数据量和报告详尽程度。如果一天分析十几只股票成本是肉眼可见的。我的优化方案是让脚本先把所有数据和中间结果压缩成一个精炼的 JSON 摘要AI 只基于这个摘要写报告而不是把原始数据全量丢给它。这样既减少了 token 开销也变相降低了模型被无关数据干扰的概率。7.4 多语言报告模板的切换我做的模板默认生成中文报告但偶尔也有英文需求。这个不难我直接在模板目录里放了report_template_en.md并在 SKILL.md 的 config 里加了一个report.language参数。用户在触发时补一句“用英文输出”就会被识别为切换到英文模板。这个功能虽然简单但对我这种经常需要把分析结果转发给海外同事的场景来说算刚需。最后补一句个人体会折腾这套投研 Skill 的过程中我最深的感受是AI Agent 的能力上限并不完全取决于模型本身而取决于你给它设计的“工作手册”质量。同样一个 Claude 模型没有 Skill 时像是刚入职的实习生什么都要问、经常自由发挥配上写得很完整的 SKILL.md 之后就像一个有三年经验的分析师知道自己该看哪些数据、按什么口径计算、报告该怎么组织。如果你正准备给自己的 AI 工作流加上投研能力我的建议是从最小闭环开始先做一个只覆盖行情拉取和估值计算的精简版 Skill跑通后再逐步加财务分析、行业对比、风险提示模块。千万不要一上来就憋大招做全功能版本因为你会在调试过程中发现每一个模块都有大量需要打磨的边界细节迭代式开发才是这套体系最务实的落地方式。