★ FEATURED ARTICLE 1. 一次翻车让我重新理解AI辅助编程前几天帮一个学弟看他的量化作业差点看吐了。代码能跑结果却不对回测净值曲线画出来像心电图指标算得有模有样但一问细节就露馅——这不是学弟一个人的问题这是他让AI全流程代写的结果。我自己也干过同样的事后来翻了几次车才慢慢摸出一套靠谱的用法先让A模型把任务打磨成清晰的任务书再让B模型照着任务书去执行。这套组合我实测了大半个学期作业返工率明显下降更重要的是交完作业之后你能把每个细节都讲明白答辩环节基本不会翻车。先说清楚我为什么用A模型和B模型指代。最近AI工具迭代太快直接报名字容易被误会成打广告而且我聊的是方法论不绑定具体产品。A模型指的是那种擅长多模态理解、推理能力强、擅长把含糊需求整理成结构化方案的大模型尤其适合做“思考”和“打磨”B模型指的是那种擅长改代码、能读仓库文件、可以执行终端命令的编程智能体它强在“动手”而不是“空想”。这套组合不是灵机一动而是我拿真实作业反复试错试出来的后面会把整个流程、提示词模板、踩坑记录都摊开讲。这些年AI写代码的门槛越来越低但翻车率一点没低。原因很简单大部分人的用法是打开一个对话框把作业题目原封不动粘进去然后期待AI交出一份完美答案。第一次跑出来看着挺像样改两个参数再跑就崩崩完把报错贴回去它修好一处又弄坏另一处来回几轮之后代码已经没法看了。这篇博文就是写给正在被这个循环折磨的人量化作业也好其他编程作业也罢真正的问题不在AI能力不够而是你让一个模型同时干了“设计”和“施工”两份活儿它顾不过来。1.1 直接让AI一把梭我交上去的是什么我先还原一下最典型的翻车现场。把作业题粘进对话框AI很快吐出一份完整的Python文件里面有数据下载、因子计算、回测引擎、画图脚本看着应有尽有。我连看都没细看直接跑了一遍居然没报错当时心里还挺美。结果仔细一检查就发现问题了它把某个指标的计算口径理解错了用的是一套网上流传的简化公式和课程讲义里的定义完全不是一回事回测里还偷偷用了未来数据前视偏差在前几行就埋下了整个策略的胜率曲线是假的。这种错不是运行时报错是逻辑层面的错靠眼睛看很难发现只有拿数据一笔一笔对才知道哪里不对。另一个高频问题是上下文失控。作业通常包含题目描述、数据说明、公式定义、参考文献好几块内容加起来小一万字。一次性塞进对话框之后刚开始几轮对话还正常改到第五轮、第六轮模型开始“失忆”前面说好的变量命名它忘了某个模块的接口改了三遍最后版本里同时存在两套写法。最离谱的一次它把两个函数的参数顺序换了还嘴硬说是为了“统一风格”结果我的整个回测框架全部崩掉。更隐蔽的问题是内容幻觉这是最容易让人栽跟头的。AI会一本正经地编造一个不存在的函数库或者把某个API的用法写错因为训练语料里混入了大量过时内容。量化领域变化很快库的接口经常升级AI给出的调用方式可能是两年前的版本你照抄下去轻则版本冲突重则计算结果根本不对。直接让AI一把梭本质上是在赌赌它理解题目到位、赌它代码没有逻辑错误、赌它用的库版本恰好合适。这三件事同时成立的几率比你想象的低得多。1.2 复盘后发现的三类典型问题第一类问题是需求模糊。作业题目里经常有大量隐含条件比如“请实现一个均值回归策略”这句话不同人理解完全不一样回归窗口参数是多少交易成本怎么设标的范围是什么持仓周期多久这些题目没说、AI也不会主动问于是它按照大数据训练出来的“平均理解”自行发挥结果自然偏离课程要求。说白了AI不是不聪明是你根本没跟它对齐目标。第二类问题是抽象设计与具体实现打架。一个模型同时负责做架构设计和写代码时它会倾向于“省事”为了减少代码量把模块边界模糊掉或者跳过异常处理。等你想扩展某个功能时才发现当初的设计根本没有留接口只能推倒重来。这就像一个施工队既当设计师又当包工头必然倾向于选最省料的做法而不是最合理的做法。第三类问题是验证缺失。直接生成的代码AI通常不会主动做边界测试。你输入正常数据它能跑输入极端值、空值、异常值就原形毕露。量化作业尤其怕这个因为金融数据经常有停牌、缺失、复权调整这些坑处理不好整个回测都是错的。复盘下来我发现这些问题几乎都能追溯到同一个根源缺少一道独立的“需求整理”环节。如果能在让AI动手写代码之前先把目标、约束、验收标准一条条列清楚后面翻车的概率会小很多。2. 双模型分工为什么必须“先打磨、再执行”想通上面那层之后我开始尝试把“设计”和“施工”拆开。最初的想法很朴素既然一个模型又当架构师又当码农容易翻车那就找两个模型各干各的一个专职把需求理清楚、把方案定明白另一个专职把方案变成代码、把代码跑通。这个思路听起来简单实际跑下来效果出乎意料地好而且背后的逻辑非常硬核不同模型在预训练目标、数据侧重、接口形态上有天然差异用对地方比什么都强。2.1 A模型的强项是“把混乱变清晰”A模型最擅长的是处理非结构化输入。原始作业题往往是一段话夹杂着公式截图、数据表、老师随口提的注意事项信息密度很高但组织混乱。A模型的多模态理解能力可以把这些碎片统一整理成结构化的任务书里面包含背景说明、实现目标、数据字段、算法步骤、验收标准。它还有一个难能可贵的习惯会主动追问。你给它一段含糊的需求它会列出三到五个问题让你确认而不是闷头就开写。我实际用下来的感受是A模型非常适合做“需求澄清”和“方案设计”这两个环节。它能读图课程讲义里的公式截图可以直接丢给它它能读PDF论文附录里的因子定义也能准确提取它能做长文本推理把前后几段需求矛盾的地方揪出来。这些都是写代码之前必须做好的准备工作。量化作业尤其受益于这一步因为量化策略的细节太多了时间戳要不要对齐、涨跌停怎么处理、手续费是按比例还是按固定金额——每一条都需要白纸黑字写清楚。A模型的局限也很明显它的强项是语言和逻辑不是精确工程。让它在长代码仓库里定位一个bug或者连续修改十几个文件它表现得很一般。有些A产品本身不具备直接执行代码、读取本地文件夹的能力它的“代码”输出更多是示意性质的离能跑的完整工程还有距离。所以它适合做前半段不适合做后半段。2.2 B模型的强项是“把方案变成代码”B模型正好补上A模型的短板。这类编程智能体是为“操作”而生的它能读取整个项目目录、能打开具体文件、能搜索代码里的函数定义、能执行终端命令甚至能自己跑测试然后根据结果修改代码。它天然适应“你给它明确任务它逐个文件修改每步反馈进度”这种工作方式。我后来才发现B模型最舒服的用法不是让它自由发挥而是给它一份足够具体的任务书让它当一个严格的执行者。这里有一个关键差异A模型写代码是“生成”B模型写代码是“工程”。A模型倾向于一次性吐出一大段完整代码B模型则习惯分步骤操作——先看现有代码结构再定位需要改的位置然后小步修改、小步验证。这种差异决定了它们适合不同的环节。你要做的是把一个复杂的作业任务拆成一系列明确的子任务然后让B模型像流水线工人一样逐项完成。B模型同样有它的局限它不擅长处理模糊指令。你让它“写一个更好的策略”它会无从下手你让它“把signal函数改为基于5日动量信号输出0到1之间的连续值并同步修改回测脚本中的参数传递逻辑”它就能干得很漂亮。所以B模型的发挥水平高度依赖你交给它的任务书质量。这正好说明为什么需要先用A模型打磨A模型的任务书越清晰B模型的执行力就越强返工越少。2.3 一张表格看懂分工边界很多人纠结“到底哪个模型更强”我觉得这个问题问错了。应该问的是“哪个模型适合做眼前这个环节”。把两个模型放在各自擅长的位置上效果远好过让任何一个单打独斗。下面这张表我整理了很久基本能说明日常写作业时的分工边界工作内容适合的模型原因作业题目理解与需求拆分A模型多模态理解强能从零散材料中提炼结构公式与算法口径确认A模型推理能力强能发现题目中的隐含条件输出详细任务书与验收标准A模型结构化文本生成能力优秀逐文件实现代码与接口B模型能操作真实文件适合工程化实现运行调试与报错定位B模型能直接执行命令快速迭代代码逻辑审查与结果复核A模型能站在全局角度发现逻辑漏洞最终代码整理与注释补充B模型重复性工作适合自动化执行这个分工思路类比到现实里就是产品经理加高级工程师的组合A模型负责把用户一句话变成需求文档B模型负责把需求文档变成可交付的代码。中间不重叠也不留空白。最关键的是任务书这个东西本身就形成了“接口”A模型的输出就是B模型的输入两边不用直接对话一份清晰文档就完成了交接。这也是为什么我后来管它叫“任务书驱动开发”而不是简单的“两个AI聊天”。3. 完整实操工作流从原始需求到可交付作业方法论说完了接下来是最重要的部分具体怎么操作。我用的这套流程一共三个阶段每个阶段都需要跟AI打交道但方式和目标完全不同。下面我把每个阶段的提示词模板也放出来方便你直接抄作业。3.1 阶段一让A模型产出任务书拿到作业题之后先别急着让任何模型写代码。第一步是把所有材料收集齐包括题目原文、课件的相关章节、公式截图、数据字典然后统一丢给A模型让它产出任务书。这部分是我踩过最多坑的地方一开始我给的提示词太笼统只写“帮我整理一下这个作业”结果A模型只吐出来一段摘要完全不够用。后来我总结出一个固定的提示词框架我现在有一个量化相关的编程作业需要你帮我把它拆解成一份可执行的任务书。 请严格按照以下结构输出 1. 项目背景用一段话描述这个作业要解决什么问题。 2. 输入数据说明列出所有数据字段、类型、时间粒度、缺失值处理方式。 3. 实现目标用编号列出全部功能需求每条必须能被验证。 4. 算法细节写明每个指标的计算公式、参数含义、边界条件。 5. 接口设计定义主要函数名、输入参数、返回值。 6. 验收标准列出至少5条可测试的完成标准例如“回测净值曲线能正常生成且无前视偏差”。 7. 注意事项写出你从题目中识别出的所有隐含条件以及你可能不确定、需要我确认的地方。这里有个细节第七点特别重要。A模型会主动列出它拿不准的点你只需要针对这些点补充确认所有模糊地带就被提前封死了。我印象最深的一次它追问“交易成本是按双边还是单边计算滑点是否需要单独建模”这几个问题我之前根本没想过作业题里也确实没说。我去翻课件才发现老师默认用的是单边千分之一如果按AI一开始猜的双边算整个策略的收益特征会完全不同。这就是任务书的价值——把猜变成确认。任务书产出之后你还要自己读一遍因为最终对作业负责的是你不是AI。读的时候重点看“算法细节”和“注意事项”部分凡是你看不懂的、不符合课程要求的当场让A模型修改。这个阶段修改成本最低等B模型把几万行代码写完了再改口径心态会直接崩掉。3.2 阶段二让B模型严格按任务书执行拿到A模型产出的任务书之后进入第二阶段让B模型动手写代码。这个阶段的核心原则是“拆小步、勤反馈”不要让B模型一次性做完整件事而是把任务书拆成多个逻辑单元一个一个交付。你看B模型能做的事很多但每次给它安排的工作范围应该尽量小。我推荐这样拆分先让B模型搭好项目框架包括目录结构、基础工具函数、数据加载模块然后单独实现指标计算模块再单独实现回测引擎最后做可视化与汇总报告。每完成一个单元就让B模型运行测试或示例数据验证确认通过后再进入下一个单元。这样做的好处是一旦某个环节出问题定位范围非常小不会牵扯到全部代码。给B模型的指令同样有套路。它跟普通对话框不同你最好明确告诉它操作边界。我的固定写法是请阅读项目目录下的 task.md任务书按照其中第X节到第Y节的要求完成以下工作 1. 创建文件 src/indicators.py实现 param、window 两个参数。 2. 实现函数 calculate_momentum输入为价格序列输出为动量向量公式请严格按照任务书中的定义。 3. 运行 python -m pytest tests/test_indicators.py确保测试通过。 4. 如果测试不通过先查看报错日志修改相关代码后重新运行直到通过为止。 每完成一个步骤请用简短文字汇报当前状态不要一次性做完所有事情。注意第三点和第四点这就是在用B模型的自主测试能力。很多人在这一步偷懒让B模型写完代码就完事了只依赖后面的人工测试结果发现问题时已经堆积了一大堆代码。让B模型周期性地运行测试命令等于让每一项修改都经过验证之后再往下走整体返工量会大幅减少。阶段二最容易忽略的是“版本备份”。B模型每完成一个单元我就建议你手动复制一份项目快照。这样即使后面的修改出了问题也能随时回到之前的可用状态。别依赖B模型去记历史它没有这个能力也别指望 IDE 的回退功能能解决所有问题有些改动跨了十几个文件回退也会乱套。手动备份虽然土但最可靠。3.3 阶段三把结果回灌给A模型审查和修复B模型完成了第一版代码之后不要急着交作业。整个流程里最容易被跳过的就是这个审查阶段而它恰恰是质量提升最大的一环。审查分两层第一层是代码运行层确保所有测试通过、结果能正常输出第二层是逻辑层确保实现真的符合作业要求。第二层是B模型的盲区因为代码跑通了不代表逻辑对它没有课程背景不知道老师想考核什么这时候需要A模型出场。我通常的做法是把B模型生成的代码文件、任务书、输出结果汇总成一个压缩包或者一段完整文本丢给A模型做审查。A模型的任务有两块一是通读代码对照任务书逐条核对实现完整性二是检查逻辑正确性包括是否存在前视偏差、是否使用了未来数据、指标计算公式是否符合任务书定义。审查提示词可以这样写这是一份量化作业的代码实现请扮演一个严格的代码审查员。 任务书内容如下... 代码文件内容如下... 请逐条对照任务书中的实现目标检查 1. 每个功能是否完整实现。 2. 指标计算公式是否与任务书完全一致特别注意边界条件和单位。 3. 是否存在前视偏差或未来数据被意外使用的情况。 4. 程序对缺失值、极端值的处理是否安全。 5. 输出结果是否合理例如收益率是否在一个合理范围。 对于发现的问题请按严重程度排序标明具体代码行号和修改建议。这一步产出的审查报告就是第三阶段的“补丁任务书”。你需要把报告再交给B模型去执行修改。于是整个流程形成了一个循环A模型定方案、B模型写代码、A模型查问题、B模型打补丁。一般走两到三轮之后代码质量会有质的飞跃。我第一次完整跑完这套流程时审查报告只列出了三个小问题修改完后一次通过验收那种顺畅感是之前“一把梭”完全没体会过的。4. 实测效果翻车率与返工次数对比光说不练假把式。我把这套“先打磨、再执行”的组合跟老办法“单模型一把梭”放在同一类作业上做了对比前后各测了六次记录下完成时间、返工次数、代码行数、验收结果这些维度。因为样本量不大我拿到的数据只能算个参考但趋势已经非常明显。4.1 评测方法与打分维度我选用的评测对象是六份不同类型的量化编程作业包括动量因子回测、波动率计算、均线交叉策略实现、组合优化Demo、数据处理清洗脚本、风险评估报告。每一份作业我都用两种方式各做一遍一种是直接把题目丢给B模型让它全流程处理另一种是用上面说的A模型先出任务书、再让B模型执行、最后A模型审查的三阶段流程。每份作业记录四个维度总耗时从开始梳理需求到验收通过、返工次数需要推倒重来的次数、代码可读性假定一个刚接手的人能否快速看懂、提问后能否解释实现细节。为了防止评分太主观我让室友他本身也在学量化编程当第二评审他的评分权重占一半。整个测试周期拉了三周中间统一用同一套数据源避免数据差异影响判断。最终结果挺有意思直接放表作业类型单模型总耗时双模型总耗时单模型返工次数双模型返工次数单模型可读性双模型可读性动量因子回测5.5小时4.2小时41一般较好波动率计算2.1小时1.8小时20较差一般均线交叉策略3.3小时2.9小时31一般较好组合优化Demo7.8小时6.1小时62较差一般数据清洗脚本1.6小时1.3小时10较好较好风险评估报告4.5小时3.7小时31一般较好4.2 对比结果告诉我们什么总耗时这块初看好像双模型并没有快太多甚至也就省了百分之二十到三十的时间但实际上这是“假象”。单模型的总耗时里藏着大量无效的来回拉扯而且那些时间看起来是在工作实际上是在无限循环地修bug。双模型的耗时更多花在前期梳理上中后期执行和修复环节流畅很多整个过程中我的参与感更强知道自己每一步在做什么。最让我意外的是返工次数断崖式下降。单模型几份作业里最少也要返工一次大的组合优化甚至返工六次每次都是推倒重来那七点八小时的耗时就是这么耗出来的。双模型这边有四份作业都是零返工或者一次返工而且返工内容也变了——不再是“全部重写”而是局部修复。这个差异直接决定了最后交付时的心态手里拿着一个自己清楚来龙去脉的代码跟拿着一团AI吐出来的黑盒完全是两种体验。可读性方面A模型在任务书阶段就给每个函数定义了明确的职责B模型照着任务书实现时也会保留注释和类型标注最后生成的代码结构天然比较规整。单模型一把梭出来的代码则经常出现“一个函数八百行、中间全是魔法数字”的写法跑起来没毛病但换个人根本读不懂过两周你自己也忘了当初的逻辑。作业验收时老师往往会抽查代码或者让你解释思路可读性差简直是要命的。4.3 一次完整的三轮往返记录举个具体例子。某次作业是动量因子回测原始题目只有一段话“请设计一个动量策略完成回测并输出绩效指标。”如果直接让B模型写它大概率会按自己理解的默认配置来做比如默认二十日动量、默认每期调仓。写出来的代码看着完整但没法解释为什么选这些参数。换成双模型流程之后A模型先追问了几个问题动量信号窗口取多少调仓频率是日频还是周频交易成本要不要扣标的池的筛选规则是什么这几个问题直接把作业的隐含条件全部暴露出来。确认完这些之后A模型输出了一份包含六个模块的任务书从数据加载到绩效计算全部定义了接口。B模型分四步完成了实现搭建框架、实现信号计算、实现回测引擎、生成报告。第一版跑通后A模型审查时发现了一个潜在问题就是信号计算里没有处理停牌日的空值可能导致复权数据错位。我把审查意见返回给B模型它修改了一个函数补上了空值填充逻辑第二轮就通过了全部验收。整个过程用时四小时出头返工一次输出结果有完整文档支撑拿去答辩完全不虚。5. 常见问题与排查技巧实录这套流程整体可靠但也不是没毛病。跑了十几份作业之后我把踩过的坑和排查心得整理成了几个典型问题你现在遇到的大概率是这几种。5.1 A模型把任务书写成了论文B模型直接摆烂怎么办任务书不是越详细越好。有一段时间我为了追求“严谨”让A模型把每一个函数的边界情况都写出来结果产出了一份将近一万字、跟学术论文一样厚的任务书。B模型拿到之后反而不会干活了它面对超长文本和大量微妙约束要么试图在一个文件里塞下全部逻辑要么干脆输出一个“我建议先简化需求”的摆烂式回答。后来我学到的处理办法是把任务书按执行批次拆成多份短文档。一份任务书控制在两千字以内覆盖三到五个行为目标。比如第一批只做数据加载和清洗第二批做信号计算第三批做回测引擎。B模型每次只读它当前要完成的那一小块效率和准确率都高很多。如果你发现A模型写的任务书太长直接在提示词里加一句“请将任务书按模块拆分每个模块单独成节每节不超过500字”效果立竿见影。5.2 B模型执行时擅自改接口导致后面全崩了这是我在阶段二遇到最多的问题。任务书里明明约定某个函数叫generate_signal输入是 DataFrame输出是 Series。B模型执行到一半可能觉得参数结构不合理直接改成compute_signal或者改变了返回的数据结构而且不主动告诉你。等下一个模块引用这个函数时找不到函数名整个回测脚本直接崩。应对办法有两个。第一在给B模型的指令里反复强调“修改任何任务书约定的函数签名之前必须先输出修订说明征得同意后再动手不得静默修改接口。”第二阶段二每完成一个模块立刻让B模型运行一遍可以验证这个模块的测试命令确保接口没有意外变化。如果你的测试覆盖得当接口变动会在第一时间爆出来而不是攒到最后一起炸。5.3 上下文越拉越长模型开始胡言乱语不管是A模型还是B模型对话超过一定轮数之后都会出现“上下文疲劳”。表现就是前面约定好的东西突然忘记、对简单问题给出互相矛盾的回答、甚至开始重复输出。这个问题在B模型身上尤其明显因为它要处理文件内容、报错日志、运行结果上下文消耗比纯对话快得多。我的应对策略是“对话重置法”。一旦发现B模型的回答质量明显下降马上新建一个对话窗口把当前项目状态写成一个简短说明粘进去让它基于这个说明继续干活。相当于给AI一个“重新开场”的机会摆脱前面对话累积的噪音。这不是偷懒而是控制上下文的主动策略实测下来能让后期错误率明显下降。新建对话时我会把项目目录结构、最近完成的改动、下一步任务三项列清楚信息量不大但足够让B模型恢复状态。5.4 常见问题速查表现象可能原因排查与解决B模型不按要求写输出泛泛而谈任务书太模糊或太长重写任务书明确函数名、参数、验收测试命令B模型在同一个错误上反复循环上下文疲劳它已经丢失了关键状态新建对话窗口把当前状态压缩后重新接入A模型审查时没发现问题代码量太大审查不彻底拆成小文件逐一审查并在提示词中要求按严重程度排序输出生成的代码总是报Unicode错误数据文件编码不一致在阶段一任务书中写明数据统一用UTF-8编码并在B模型指令中强调回测结果数字离谱大概率是前视偏差或未来数据泄漏拿最小数据集人工推演一遍再让A模型专门检查时序逻辑B模型无视指令使用虚拟示例数据它找不到真实数据路径在指令中给出数据的绝对路径并要求先运行数据预览命令确认加载成功修改需求后代码大量返工当初任务书没有预留扩展点回阶段一重新出设计着重定义好接口封装避免牵一发动全身代码能跑但答辩答不上来跳过审查阶段只求跑通把任务书A模型复盘提问答一遍再拿去答辩排查的逻辑其实就一条是谁引入的错误就回到谁那里修正。A模型引入的口径问题回A模型补任务书B模型引入的实现问题回B模型打补丁。别图省事让一个模型去修另一个模型的烂摊子那样只会越修越乱。6. 最后再说几句真心话写完这些我突然想起最早那次翻车的场景——凌晨两点对着满屏报错毫无头绪脑子里只有一个念头AI到底行不行。事后回想AI没有不行是我用错了方法。把它从“代写工具”的位置挪到“结对程序员”的位置一切就顺畅了。任务书驱动这套方法不只是为了防止翻车更重要的是让你始终掌握作业的主导权。每一份任务书、每一轮审查报告都是你自己参与产出的到最后你自然能讲清楚代码里每一行是干什么的。我个人现在的习惯是即便是十分钟就能写完的小脚本也会花两分钟让A模型列一个执行清单再让B模型照着写。磨刀不误砍柴工这个习惯帮我省掉了很多“小改引起大崩”的麻烦。工具还在快速迭代但“先想清楚、再动手做”这个原则不会过时两个模型怎么搭配、任务书怎么写详细你完全可以根据自己的习惯调整核心逻辑不变把思考交给擅长思考的把执行交给擅长执行的中间用一份看得懂的任务书连接。希望这套方法也能让你的作业顺利过关。
阅读完成 · 觉得有帮助？
