面对同一个任务，用户常常先纠结该选哪个模型、开多高强度，再想要不要换一个重试。如果这些选择由工具替你完成，工程问题会不会少很多？
GitHub 本周介绍 Copilot Fusion，称它会在性能与成本之间作路由和编排，使用 Single、Cascade、Critique 三种执行模式，用户选择投入程度即可。
这条更新的职业意义，不是要求学生立刻背下每种产品模式，而是提示：模型选择正在变成工作流内部的一项决策。搭系统的人仍要解释，这项决策何时有效，什么时候会出错。
最贵的模型 不一定最适合所有步骤
一段业务流程可能同时包含格式转换、资料理解和复杂判断。若所有步骤使用相同强度的模型，简单任务也承担了同样的成本；若全部交给最便宜的方案，难题又可能需要反复返工。
因此，路由需要先认识任务差异。哪些输入容易确认结果，哪些问题存在歧义，哪些输出一旦出错会影响后续工作？没有这些分类，系统只能围绕一个模糊的“效果好”反复尝试。
以模拟文档整理为例，提取日期与判断合同含义不应默认使用相同验收办法。前者可以与原文位置核对，后者涉及语境与解释。教学项目可以只处理低风险资料，避免把模型比较包装成专业意见。
这里的重点不是宣称某个模型一定胜出，而是说明你怎样把任务拆到适合比较的程度。模型名称可以更换，问题分类的依据仍应成立。
升级条件要在看结果之前想好
一个常见方案，是先尝试成本较低的路径，遇到困难再升级。但“遇到困难”必须能被识别。模型自己说很有把握，不一定足够；字数长、措辞专业，也不能当成质量保证。
可以根据任务设计可检查的信号：字段缺失，输出格式错误，证据无法对应，或几个关键条件互相冲突。不同信号可能需要不同处理，有些适合换模型，有些应该向用户澄清。
若输入本身缺少信息，升级到更强模型也未必解决问题。一个成熟的方案应该允许系统说“需要补充材料”，而不把每次不确定都转成更多调用。
这些是可供学生设计项目的思路，不是 GitHub 已公开的内部路由规则。讨论产品发布时，应把发布方说明与自己的工程设计分开。
多一个评论者 也要判断评论有没有用
让另一个模型审查输出，听起来比单次生成可靠。但如果两个过程用了同样有缺陷的材料，第二次调用可能只是把同一个错误说得更坚定。
审查者需要知道要检查什么。是核对引用，寻找遗漏条件，还是比较实现与需求？如果指令只有一句“看看对不对”，很难从结果里知道它真正完成了哪种检查。
可以安排一个带有已知问题的教学样本，让审查过程面对它，再观察是否找到问题、理由是否对应。也保留本来正确的样本，防止系统为了表现审查价值而凭空提出修改。
作品集中值得展示的，不是“用了两个模型互相检查”，而是哪些错误因此更容易被发现，以及哪些问题仍然会漏过。若没有足够样本，结论就保持在这次练习范围内。
成本应该按被接受的结果计算
单次调用价格只是一个因素。被拒绝后再生成、审查与修正、人工确认和等待时间，都可能改变实际工作成本。最便宜的第一次尝试，不一定产生最便宜的最终结果。
一个有用的比较表，可以同时记录首次结果、升级次数、最终是否通过同一套要求，以及实际调用费用。若费用来自假设预算，应明确写成假设；若来自账单，就固定时间和计费范围。
还要避免只对某条路径额外照顾。对方案甲反复调整提示，对方案乙只跑一次，得到的差异很可能来自投入方式。比较时尽量保持任务、输入和接受标准一致，再说明没能控制的因素。
延迟也不能只给一个平均数。读者可能更在意难题要等待多久，或最差情况是否可以接受。一个小样本不足以代表生产表现，却可以帮助你发现接下来需要收集什么。
给路由安排一组反例
可以为模拟资料整理准备三类输入：信息完整且简单的材料，存在缺失字段的材料，以及前后条件冲突的材料。它们不需要来自真实客户，但应足以区分正常处理、升级和询问用户。
先写下你希望系统怎样处理，再运行候选方案。否则，看到结果以后才决定哪条路径合理，很容易替自己喜欢的方案解释。对无法明确评分的问题，可以先保留为人工审查项。
如果某条路由总是调用更强模型，检查它是不是真的识别了困难，还是规则把普通输入也挡住了。若复杂输入没有升级，检查系统是否把看起来完整的答案误认为可靠。两种错误都应计入分析。
可以再增加一个相同内容、不同表述的输入，观察决策是否无故变化。一次差异不能直接说明整个系统不稳定，但能帮助你找到需要进一步检查的条件。
最后把一次规则调整写成记录：修改前后分别解决什么，又新增了什么代价。没有实际运行的设计留在计划里，不把纸面推演写成已经测出的性能改善。
一份路由项目 怎样与求职连接
学生可以从三种自建方案开始：固定单一路径、遇到指定错误再升级、生成后加一次针对性检查。它们只是项目里的设计方案，不需要复刻商业产品的全部能力。
选择一个范围清楚的任务集，先写出接受条件，再比较不同路径。把失败也保存下来，尤其记录“本该升级却没升级”和“本来简单却浪费了调用”的情况。
面试时，重点解释一次路由规则的修改。你发现了什么问题，为什么不直接增加调用次数，新规则又带来了什么代价？这样的回答连接了产品目标与系统行为。
也可以讨论何时不该自动路由。若用户需要指定模型来源、费用上限或某项明确限制，系统需要尊重这些要求，而不是悄悄把任务转给另一条路径。
用户少点一个下拉框，背后可能多了一组需要验证的决策。会搭这种系统的人，应当能说明选路的依据、例外与结果，而不是把所有取舍都藏在“自动选择最佳模型”里。
读者常问
应该先接入很多模型吗
不必。先用少量可比较的方案把任务、条件和接受标准说清楚。候选模型太多会增加配置和解释成本，未必让结论更有价值。一个能说明为什么升级或停止的小系统，比无法解释的模型菜单更适合作为起点。
让更强模型审查 是否一定提高正确率
不一定。审查者也可能依赖同样错误的输入，或误解任务。需要给它明确检查对象，并保留本来正确和已知有问题的样本，观察是否真正发现差异。多一次调用只是流程变化，效果仍需实际检查。
怎样写没有明显胜出方案的结果
可以说明不同条件下各有什么代价，并给出适用范围。研究未得到统一赢家，不等于失败。如果比较帮助团队排除某种不合适的路线，或发现需要补充的材料，也已经产生了可以采用的信息。
产品自动路由后 用户还需要了解什么
至少应能理解当前费用与输出状态是否符合自己的要求，以及什么条件需要指定模型或停止。没有必要要求每个用户研究全部实现，但也不能把重要限制藏在自动化后面，让结果难以解释。
- 介绍 Copilot Fusion· X / 原始帖文
- Copilot Fusion 的模式与限制· GitHub Docs
结合目标岗位，梳理已有经历、本人贡献和可核查的项目成果，讨论下一步准备重点。