量化这行有个挺尴尬的现实：一个策略的idea可能只有三行字，但把它变成能跑通回测、能接数据、能上实盘的工程代码，往往要写五百行。所以这两年我做策略开发和团队协作时，大模型已经从"新鲜玩意"变成了日常工具箱里的标配。可问题随之而来——当工具箱里并排摆着 ChatGPT、Claude、DeepSeek、Grok、Gemini、GLM、Qwen、Kimi 这八把螺丝刀时，到底哪把拧哪种螺丝最省力？
这篇就是我过去几个月拿真实量化任务做的一次横向对比。不是跑分榜复读，也不是看谁写诗写得好，而是把量化交易从数据获取、因子研究、策略编码、回测调试到文档阅读的整条链路拆开，逐段丢给这八家模型,记录它们的表现、翻车点和意外惊喜。做量化交易的朋友、自己写策略的独立开发者、以及带团队做研究工程化的同学，都能从里面找到可以直接抄的分工方案。
1. 量化场景里的大模型到底在干什么活
1.1 五类高频任务，权重完全不同
很多人第一次拿大模型做量化，上来就让它"写一个赚钱的策略"，然后失望而归。这个用法本身就错了。量化开发的工作量大头根本不在"发明策略"，而在于把策略工程化。我给团队统计过时间分布，大致是这样：
| 任务类型 | 时间占比 | 对大模型的核心要求 |
|---|---|---|
| 数据获取与清洗 | 约30% | 熟悉数据源SDK、字段语义准确、不编造字段 |
| 策略代码编写与重构 | 约25% | 代码能一次跑通、懂回测框架的坑 |
| 报错排查与调试 | 约20% | 会读堆栈、能定位到具体行、不乱改 |
| 因子研究与数学推导 | 约15% | 统计/数学功底扎实、推导不吃字 |
| 文档与研报阅读 | 约10% | 长文本抽取准确、能提炼可执行结论 |
这张表很关键，因为它直接决定了评价标准。如果你的实际场景是"数据清洗占三成"，那一个数学推理满分但天天编造tushare字段名的模型，对你来说就是负资产。反过来，如果你的工作是做因子挖掘和风险建模，那代码写得再漂亮但统计推导含糊的模型，也帮不上忙。
所以我在横测里没有给八家模型排一个总榜，而是按上面五类任务分别打分。总榜这种东西对量化来说意义不大，因为每个人的任务配比不一样，甲之蜜糖乙之砒霜。
1.2 一个常见误区：拿刷题榜当招聘标准
第二个误区是看公开榜单。数学竞赛、代码竞赛的分数当然有参考价值，但和量化实操之间隔着好几层。原因有三个：
第一，量化代码是"脏"的。竞赛题给的输入是干净的、边界明确的，而真实行情数据里有停牌、有涨跌停、有除权除息、有缺失值、有重复行、有单位不一致。模型能不能在这些脏数据面前保持稳健，和它在干净题目上的表现几乎不相关。
第二，量化代码是"长"的。一个完整的回测脚本通常几百行，涉及数据层、信号层、组合层、执行层。模型的上下文一致性能不能撑住这么长的代码，是另一个维度的能力。
第三，量化领域知识是"偏门"的。什么是前复权、什么是幸存者偏差、为什么T+1会导致成交假设出问题，这些属于行业常识，但不在通用语料的高频区。有些模型会用非常自信的语气告诉你一个错误的复权处理方式，这比直接说"我不知道"危险得多。
我这次的八个测试对象，用的都是各自当时可获得的版本，通过官方API或官方客户端调用。要提醒一句：模型迭代很快，我这边的结论只代表我测试时的状态，你自己上手前最好用同一套任务集重新验一遍，成本也就半天时间。
2. 我的横测口径：任务集、评分表和控制变量
2.1 任务集怎么设计才有区分度
我总共设计了六组任务，加起来两百多个用例，每组都有明确的"标准答案"或"可验证结果"。设计原则是：任务必须可判定，不能靠感觉打分。
- 任务组A：策略代码生成。给出明确的需求描述，要求输出可直接运行的回测脚本，跑一次看是否报错、逻辑是否符合描述。
- 任务组B：代码重构与bug定位。我给一段我自己故意埋了bug的策略代码，看模型能否指出问题行和原因。
- 任务组C：数据接口编码。要求用指定数据源写取数+清洗代码，重点看是否编造字段、是否处理复权和停牌。
- 任务组D：因子与统计推导。涉及相关性、协整、回归、组合优化，看推导过程是否严谨。
- 任务组E：长文档抽取。丢一份几十页的API文档或研究报告，要求抽取结构化信息。
- 任务组F：中文金融语义理解。包括研报摘要、公告解读、财务指标口径辨析。
这六组覆盖了前面说的五类高频任务，而且每一组都能用客观标准判定对错，避免了我主观偏好带来的偏差。
2.2 评分维度和权重分配
每个任务我按四个维度打分，采用五分制：
| 维度 | 说明 | 权重 |
|---|---|---|
| 正确性 | 结果是否事实正确、代码是否跑通 | 40% |
| 完整性 | 是否遗漏关键边界处理（复权、停牌、手续费） | 25% |
| 稳定性 | 同一任务多次提问结果是否一致 | 20% |
| 可读性 | 代码结构和解释是否方便人接手 | 15% |
正确性权重最高是毫无疑问的。我把稳定性单独拎出来，是因为量化开发对可复现性要求极高。一个模型今天给你写df['close']，明天写成df['closing_price']，即使两个都"对"，也会让协作成本飙升。稳定性差的模型，在团队场景里几乎是不可用的。
2.3 提示词统一模板
控制变量的关键在提示词。我对八家模型用的是同一套模板，结构如下：
【角色】你是一名量化策略工程师，熟悉 pandas / numpy / backtrader。 【任务】实现一个基于双均线的日频择时策略回测。 【约束】 1. 数据字段：date, open, high, low, close, volume, amount 2. 必须处理停牌（volume == 0 视为停牌） 3. 交易成本：双边万分之三，含印花税 4. 输出完整可运行代码，不要省略任何函数 5. 说明每段代码的作用 【输出格式】先给代码块，再给不超过200字的说明。模板里有几个细节是刻意设计的。要求"字段清单"是为了看模型会不会自己发明字段；要求"必须处理停牌"是压力测试，看它是否真的理解A股的交易机制；要求"不要省略"是为了防止模型用# 此处省略若干行偷懒。实测下来，这个模板本身就筛掉了一批模型——有好几家会无视"不要省略"的指令，直接给半截代码。
3. 策略代码生成实测：谁写出来的东西能直接跑
3.1 双均线策略：八家模型的第一次交卷
任务组A的第一个用例就是上面那个双均线策略。八家模型里，代码能不改一个字直接跑通的是少数。我把典型问题归类了一下：
- 字段编造类。有模型用了
df['adj_close']，但我给的字段清单里根本没有这个字段。还有模型用了df['turnover_rate']。这类问题的根源是模型见过太多包含这些字段的代码，形成了"肌肉记忆"，忽略了当前上下文。 - 指令忽略类。明确说"不要省略"，依然输出
# ... 后续逻辑类似。这种在八家里出现了两三次。 - API幻觉类。backtrader 的
Cerebro参数、Strategy的方法名写错，或者把 backtrader 的写法和 vectorbt 的写法混在一起。 - 边界缺失类。停牌处理直接漏掉，或者在停牌日依然用前一日收盘价成交，导致回测结果虚高。
这里我要说一个反直觉的结论：代码跑通不等于策略正确。有个模型写出的脚本能顺利跑完并输出漂亮的收益曲线，但那曲线是假的——因为它在这一天用收盘价生成信号，又在同一天用收盘价成交，构成了典型的未来函数。这种错误不会报错，只会让你的回测结果好得不像话。所以我的评分里，"逻辑正确"比"能跑通"更重要，这也是我为什么坚持人工核对每一段信号逻辑。
实测下来，在"代码一次跑通率"这个指标上，Claude 和 DeepSeek 表现最稳，GPT 系列紧随其后，Qwen 和 GLM 在中文注释和国内框架适配上更顺，Gemini 在长代码块的结构一致性上不错，Kimi 的长上下文让它能hold住大段代码，Grok 在需要结合实时市场语境的任务里比较有特点。
3.2 未来函数与复权处理：模型最容易翻车的地方
如果你只想从这篇里记住一件事，那就是这一节。我在两百多个用例里统计过错误类型分布，未来函数和复权处理这两类错误占了所有严重错误的将近一半，而且这两类错误都不报错。
先说未来函数。常见形式有三种：一是用当日收盘价计算信号并用当日收盘价成交；二是用了财务数据但没有做"公告日对齐"，直接按报告期对齐；三是做标准化或排名时用了全样本数据（比如df['zscore'] = (df - df.mean()) / df.std()这种写法，df.mean()包含了未来数据）。
我专门设计了一个"埋雷"用例：给出一个看起来正常的动量策略，但里面混入了全样本标准化。八家模型里，主动指出这个问题的只有少数几家，大部分会把它当成正常代码继续优化。能指出的模型有一个共同特征：它们会先通读整段代码再动手，而不是看到问题就直接改。
再说复权。A股的除权除息处理是个经典坑。原始价格序列在除权日会出现跳空，如果直接算收益率，会得到一个虚假的大幅波动。正确做法是用复权价格或者用复权因子还原。实测中，只有部分模型会在没有提示的情况下主动处理这一点；如果你明确要求"处理除权除息"，大多数模型能给出正确方案，但方案之间质量差距很大。有的给出的是"用后复权"，有的是"用前复权"，而这两者在回测中的适用场景是不同的——前复权适合看历史收益率，后复权适合看长期累积，混用会导致信号错位。
提示：凡是模型生成的回测代码，一定要人工检查三处——信号计算用了哪根K线、成交价用了哪根K线、标准化和排名用了什么窗口。这三处是未来函数的高发区。
3.3 框架适配能力：backtrader、vnpy、rqalpha 的差异
框架适配是区分度很高的一个维度。我用同一个策略需求，分别要求输出 backtrader、vnpy、rqalpha 三个框架的版本。
backtrader 因为语料多，绝大多数模型都能写出像模像样的代码，但细节准确率参差。典型错误是把next()和prenext()的调用时机搞混，或者notify_order的状态机处理不完整。
vnpy 的适配就明显吃力了。vnpy 版本迭代快，API 在不同版本间变化大，模型很容易混用不同版本的接口。我测试时，能一次写对 vnpy 事件驱动结构的模型不多，大部分需要我提供具体的类名和方法签名才写得对。这也是我后来总结出的一个通用技巧：涉及国内框架，一定要把关键接口签名贴进提示词，别指望模型凭记忆写对。
rqalpha 介于两者之间。它的API相对稳定，模型表现尚可，但在涉及context对象和order_target_percent这类组合层操作时，容易漏掉保证金和可用资金的约束。
这一节的实际结论是：框架越主流、版本越稳定，模型表现越好；框架越冷门或版本动荡，越需要你把接口文档喂进去。这个规律在所有八家模型上都成立，差别只在于有些模型"扛造"一些，给的上下文少也能猜个八九不离十。
3.4 报错排查：把堆栈丢进去谁最管用
任务组B是我个人觉得最实用的场景。量化开发中，报错排查占的时间太多了。我的做法是把完整堆栈加上相关代码段一起丢给模型，看它能否定位到具体行并给出正确的修改方向。
实测中，报错排查的表现差异比代码生成更大。有些模型会犯一个很烦人的毛病：不去读堆栈，直接开始重写整段代码。这看起来像是解决了问题，实际是把你的代码改得面目全非，还引入了新的不确定性。
比较靠谱的表现是这样：先指出报错来自哪一层（数据层还是信号层），再指出具体是哪一行的什么参数不匹配，最后给出最小改动方案。我特别喜欢那种会说"如果你这里的数据源返回的是datetime64而框架要的是float时间戳，可以在这一行加一个转换"的模型——它把根因和修法都讲清楚了。
还有一个技巧分享给你：排查复杂bug时，把"最近一次能跑的版本"和"现在报错的版本"一起丢进去做diff，效果比只丢报错版本好得多。八家模型在有对照版本时的定位准确率都会明显提升，其中长上下文能力强的模型提升幅度最大，因为它们能真正读完两份代码再做对比。
4. 数据接口与清洗环节：字段幻觉比语法错误更致命
4.1 数据源选型的现实约束
聊数据之前先明确一点：模型不能替你做数据源选型，这个决定取决于你的品种、频率、预算和合规要求。模型能做的是帮你把选定数据源的取数代码写对。
常见的选择路径大致是：本地开源库适合个人研究和小规模回测；专业数据服务商适合需要稳定性和历史深度的场景；券商或交易通道自带的行情接口适合实盘对接。这三类各有取舍，模型在这三类上的表现也不一样。
开源库的字段名相对固定，模型记忆比较牢，但容易出现"记混版本"的问题——比如某个库早期版本用ts_code，后期改用别的字段名，模型可能给你一个已经废弃的写法。专业数据服务商的SDK，模型记忆最薄弱，因为语料少，这类接口基本必须靠你把文档贴进提示词。通道类接口的坑在于认证和连接管理，模型写业务逻辑没问题，但涉及会话保持、断线重连这些工程细节，往往需要人来把逻辑补全。
4.2 让模型写取数代码的正确姿势
经过大量试错，我固化了一套流程，能显著降低字段幻觉率：
- 先贴schema。在提示词里明确给出字段名、类型和含义，越详细越好。这一条能把字段编造率降低一大截。
- 要求模型先复述。让它先用一句话确认"我要用的字段是这些"，再写代码。这样可以提前发现它理解偏差。
- 要求做防御性处理。明确要求：字段不存在时抛出明确异常，而不是静默跳过。量化里最怕的就是静默失败。
- 要求输出数据校验段。让模型在代码里加一段检查：行数、时间范围、缺失值比例、重复行数。这段代码非常便宜，但能救很多次。
我实测过一个对比：不加schema直接问，字段编造率相当高；加上schema并要求复述后，编造率下降非常多。这个差别比模型之间的差别还大。换句话说，提示词的规范程度对结果的影响，超过你选哪家模型。
4.3 脏数据处理的实战案例
举个我真实遇到过的场景。某次我从一个数据源取到的日线数据，回测结果异常好，年化收益高得离谱。排查半天，发现是数据里存在重复行——同一天有两行记录，导致那天的成交量被重复计算，触发了信号。
我把这坨数据丢给八家模型，要求做清洗。能主动发现"重复行"这个问题的模型不多，大部分只做了缺失值处理。后来我在提示词里明确加了"检查并处理重复行"，所有模型都能写出正确的去重逻辑。这个案例的教训是：模型不会主动怀疑数据，你要带着怀疑去提问。
再举一个更隐蔽的例子：单位不一致。有的数据源成交量单位是股，有的是手；有的成交额单位是元，有的是千元。这种问题不会报错，只会让你的因子悄悄失真。我的应对方式是在提示词里明确写"volume单位为手，amount单位为元，请勿做单位换算"，因为如果不说，有些模型会自作主张帮你乘100。
5. 因子研究和数学推导：谁的脑子真的清楚
5.1 统计检验和协整
因子研究里最常见的数学需求是平稳性检验、协整关系判定和回归分析。我设计了一个用例：给两组时间序列，要求做协整检验并给出交易信号构造思路。
正确做法是先做单位根检验判断单整阶数，同阶单整才能做协整检验，然后对残差做平稳性检验。八家模型里，能把这个流程完整走下来的占多数，但细节上有几个常见偏差：
- 有的模型跳过单位根检验，直接做协整，这在统计上是不严谨的。
- 有的模型把检验统计量的临界值和p值的判断逻辑搞混。
- 有的模型在构造交易信号时，用了未来数据来做标准化，又踩了前面说的坑。
让我比较意外的是，有些平时代码写得一般的模型，在数学推导上反而更清楚，会主动写出假设检验的原假设和备择假设，并解释为什么需要同阶单整这个前提。所以我的结论是：代码能力和数学能力不是一回事，选模型时要按你的任务配比来。
5.2 组合优化与风险模型
组合优化是我测试里区分度最大的数学任务。我要求实现一个带权重约束和换手率惩罚的均值方差优化。这个任务有几个难点：约束条件的正确表达、数值稳定性的处理、以及当优化不可行时的降级方案。
实测中，几乎所有模型都能写出基于二次规划的骨架，但在约束表达上差异明显。有的模型把权重和为一的约束用等式约束表达，这在可行域是凸集时没问题；有的用惩罚项近似，虽然更灵活但需要调参。这两种方案都对，但适用场景不同，能不能说清楚为什么选这个方案，是区分"背模板"和"真理解"的分水岭。
最容易被忽略的是不可行情况。真实场景里，约束之间可能互相冲突，导致无解。有没有模型主动加上"求解失败时的降级逻辑"，我在测试时专门留意了这一点。加上的人不多，但加上的人代码质量明显高一个层次。
5.3 数学推导的常见幻觉
数学推导的幻觉比代码幻觉更危险，因为它看起来更有理有据。我遇到过的典型情况包括：
- 把某个统计量的自由度记错，推导过程每一步看起来都对，结论是错的。
- 引用一个不存在的定理名称，煞有介事地"根据某某定理可得"。
- 在推导中悄悄改变假设，比如一开始假设独立同分布，中间某一歩又用了序列相关的性质。
应对方法很简单也很有效：让模型把每一步的假设列出来。我在提示词里加了一句"每一步推导请注明用到的假设"，结果模型自己就暴露了一些前后不一致的地方。这一招对付数学幻觉特别好用，建议你试试。
6. 长文档阅读：研报、API文档、合约规则
6.1 上下文窗口不是越大越好用
现在各家都在卷上下文长度，动不动就上百万token。但我在实际使用中的体会是：上下文长和高准确率是两件事。
我做过一个测试，把一份几十页的API文档丢进去，问其中某个接口的参数含义。长上下文模型确实能"看到"这个信息，但定位准确率参差。有的模型会在长文档里迷失，把不同章节的信息混在一起；有的模型即使找到了位置，也会在复述时加入不存在的内容。
比较稳的做法是分两步：先让模型做目录级的检索，确认目标信息在哪一节，再单独把那一节的内容喂进去提问。这两步法看起来多了一步，实际准确率提升明显，尤其是需要精确引用参数默认值的场景。
6.2 结构化抽取的准确率对比
任务组E里，我要求从一批研究报告里抽取结构化信息：标的、评级、目标价、核心逻辑、风险提示。抽取结果我做了人工核对。
表格类信息的抽取准确率整体不错，但有几个坑值得说。第一个是"单位陷阱"，报告里写"目标价35元"，模型抽成"目标价35"丢掉单位，后续程序处理时会出错。第二个是"否定句陷阱"，报告里写"公司不存在商誉减值风险"，有的模型抽成了"商誉减值风险"，把否定句变成了肯定。第三个是"多值场景"，报告里给了悲观、中性、乐观三种情形的目标价，模型只抽了一个，而且没说明是哪一个。
应对方式还是那句老话：在提示词里把输出schema定义死，明确要求"如果某项不存在填null，如果有多值请全部列出并注明情形"。加上这句之后，抽取准确率提升非常可观。
7. 私有化部署与成本账：本地跑模型在量化场景值不值
7.1 什么情况下必须本地部署
这一节是我后来补上的，因为很多做量化的朋友有实实在在的顾虑：策略代码和数据是不能随便往外发的。这里不讲任何网络访问相关的话题，只说部署形态的选择逻辑。
需要考虑本地部署的场景大致有三类：一是代码和数据有严格的保密要求，不能出内网；二是需要极低的调用延迟，比如盘中实时生成信号；三是调用量极大，长期看自建比按量付费更划算。
反过来，如果你的需求是偶发的策略研究、文档阅读、报错排查，那用云端服务更省心，因为省去了硬件采购、模型版本维护、推理服务运维这一大堆事。
7.2 显存和吞吐的粗算
真要本地部署，绕不开显存估算。一个粗略的经验公式是：推理所需显存大致等于参数量乘以每参数字节数，再加上KV缓存。常见量化格式下，参数量B级模型在特定精度下的显存占用如下表所示（这是粗略估算，实际会因实现和批大小浮动）：
| 参数量 | 精度 | 权重显存（约） | 备注 |
|---|---|---|---|
| 7B | FP16 | 14GB | 单卡较高显存可跑 |
| 7B | INT8 | 7GB | 消费级高端卡可跑 |
| 7B | INT4 | 4GB | 门槛最低 |
| 32B | INT8 | 32GB | 需要专业卡 |
| 72B | INT4 | 40GB左右 | 需要多卡或大显存卡 |
KV缓存这部分容易被忽略。上下文越长、并发越高，KV缓存占用越大，有时候会超过权重本身的占用。如果你的场景是长文档处理，务必把KV缓存算进去，否则会碰到显存不足的报错。
吞吐方面，可以用 vLLM 这类推理框架来提升并发能力，它通过分页注意力等机制提高显存利用率和吞吐量。部署时建议先跑一个压力测试，测出你的硬件在目标上下文长度下的实际并发上限，再决定服务配置。
7.3 混合架构：本地模型加云端模型
我自己最终的方案是混合的：高敏感度任务走本地模型，通用型任务走云端模型。
具体分工是：涉及真实持仓、账户信息、私有因子的处理，全部在本地模型完成；而像读公开文档、解释报错、写通用的代码骨架这类任务，交给云端模型，因为它们在长上下文和综合能力上更强。
这个架构的好处是成本可控且风险可控。本地模型不需要最强，够用就行——它主要承担"数据不出内网"的职责。云端模型承担"需要最强脑力"的职责。
8. 我最终的工作流分工：多模型流水线
8.1 各环节的主力与替补
测完两百多个用例之后，我固化了一套分工，分享给团队后大家都觉得好用。这不是排名，而是按任务类型匹配：
| 任务环节 | 主力选择倾向 | 理由 |
|---|---|---|
| 策略代码骨架 | Claude、DeepSeek | 代码一次跑通率高，少编造字段 |
| 国内框架适配 | Qwen、GLM | 中文语境和国内生态熟悉 |
| 长文档抽取 | Kimi、Gemini | 长上下文定位稳定 |
| 报错排查 | Claude、GPT系列 | 会读堆栈，给最小改动方案 |
| 数学推导 | 按用例实测挑选 | 数学能力和代码能力不对应 |
| 实时语境结合 | Grok | 需要结合当下市场语境时有特点 |
| 本地私有化 | Qwen、GLM | 开源权重可得，部署生态成熟 |
我要强调，这张表是我个人的经验值，你的任务配比不同，结论可能不同。而且模型迭代很快，这张表每隔几个月就应该重测一次。
8.2 一个完整的策略开发流水线示例
说个具体流程，你可以直接照着搭。假设我要开发一个新的动量策略：
第一步，用长上下文能力强的模型读三到五份相关研报，抽取可执行的因子逻辑，输出结构化的假设列表。第二步，把这些假设翻译成数学表达式，用数学能力强的模型做推导和边界检查，重点看有没有隐含的未来信息。第三步，把表达式交给代码能力强的模型写成回测脚本，提示词里带上完整字段schema和框架接口签名。第四步，跑回测，把报错堆栈和"最近可运行版本"一起丢给排查能力强的模型定位。第五步，回测结果出来之后，用另一个模型做"红队审查"——专门找未来函数、幸存者偏差、过拟合迹象。第六步，如果涉及敏感数据，把相关处理挪到本地模型执行。
这个流水线的核心思想是用不同模型互相制衡。同一个模型既写代码又审查代码，往往会漏掉自己的盲区。换个模型来挑刺，命中率明显提高。这是我实测下来最有价值的一条经验。
9. 踩坑清单：这些坑我替你踩过了
9.1 关于提问方式的坑
最大的坑是提问太笼统。"帮我写个量化策略"这种问题，得到的答案一定是模板化的废话。反过来，把字段清单、约束条件、输出格式、边界要求都写清楚，同一个模型给你的东西质量天差地别。
第二个坑是不给上下文。很多人排查bug时只贴报错信息，不贴代码。模型只能猜。把相关代码段一起贴上去，定位准确率立刻上升。
第三个坑是让它一次做太多事。"帮我写策略、回测、优化参数、生成报告"，这种大而全的请求，结果往往是每一块都做得半吊子。拆成多个小任务，逐个攻破，效率反而更高。
9.2 关于结果验证的坑
第一个必须养成的习惯是：回测曲线太漂亮时，第一反应是怀疑，不是高兴。我在测试中见过太多"跑得通但逻辑错"的代码，尤其是未来函数问题，它不会报错，只会让你的收益虚高。
第二个习惯是对关键参数做敏感性检查。模型帮你选的参数（比如均线周期）往往是它从语料里带出来的常见值，不一定适合你的品种。参数敏感性检查能帮你判断策略是稳健还是过拟合。
第三个习惯是保留人工复核环节。我个人的红线是：任何要上实盘的代码，无论模型写得多漂亮，必须人工逐行审一遍信号逻辑和成交假设。这个环节的时间成本，远比一次真实的策略事故便宜。
最后分享一个小技巧。我给团队建了一个"提示词库"，把每次效果好的提示词存下来，按任务类型归类。几个月下来，这个库成了团队最值钱的资产之一，因为好的提示词比换模型带来的提升更稳定、更可复现。如果你也长期做量化开发，强烈建议从今天就开始攒这个库。
