AI辅助编程翻车自救指南：双模型分工与任务书驱动实战

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模型负责把用户一句话变成需求文档，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模型审查的三阶段流程。每份作业记录四个维度：总耗时（从开始梳理需求到验收通过）、返工次数（需要推倒重来的次数）、代码可读性（假定一个刚接手的人能否快速看懂）、提问后能否解释实现细节。

为了防止评分太主观，我让室友（他本身也在学量化编程）当第二评审，他的评分权重占一半。整个测试周期拉了三周，中间统一用同一套数据源，避免数据差异影响判断。最终结果挺有意思，直接放表：

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 常见问题速查表

排查的逻辑其实就一条：是谁引入的错误，就回到谁那里修正。A模型引入的口径问题，回A模型补任务书；B模型引入的实现问题，回B模型打补丁。别图省事让一个模型去修另一个模型的烂摊子，那样只会越修越乱。

6. 最后再说几句真心话

写完这些，我突然想起最早那次翻车的场景——凌晨两点，对着满屏报错毫无头绪，脑子里只有一个念头：AI到底行不行。事后回想，AI没有不行，是我用错了方法。把它从“代写工具”的位置挪到“结对程序员”的位置，一切就顺畅了。任务书驱动这套方法，不只是为了防止翻车，更重要的是让你始终掌握作业的主导权。每一份任务书、每一轮审查报告都是你自己参与产出的，到最后你自然能讲清楚代码里每一行是干什么的。

我个人现在的习惯是，即便是十分钟就能写完的小脚本，也会花两分钟让A模型列一个执行清单，再让B模型照着写。磨刀不误砍柴工，这个习惯帮我省掉了很多“小改引起大崩”的麻烦。工具还在快速迭代，但“先想清楚、再动手做”这个原则不会过时，两个模型怎么搭配、任务书怎么写详细，你完全可以根据自己的习惯调整，核心逻辑不变：把思考交给擅长思考的，把执行交给擅长执行的，中间用一份看得懂的任务书连接。希望这套方法也能让你的作业顺利过关。