我不再事事都用 Opus 了。虽然还在用 Claude、Kimi 和 GPT，但 AI 成本一夜之间降低了 43%

1查看你最近的 30 个 Droid 任务，将它们分为两组：
2
3适合前沿模型的任务：涉及系统架构、认证、支付、安全、
4跨服务依赖的任何任务，出错会导致调试或回滚耗时的问题。
5超过 100 行业务逻辑的复杂重构。
6
7常规任务：文档更新、配置变更、为已有函数添加测试、
8有明确规范的小 bug 修复、版权声明、README 编辑、
9样板代码生成、简单迁移。
10
11分别统计每组数量。
12
13基于 Factory 的会话级数据：
14"重置我的密码"类任务：Opus 0.84 美元 vs 路由后 0.09 美元，节省 89%。
15"添加版权声明"类任务：Opus 0.62 美元 vs 路由后 0.12 美元，节省 81%。
16
17将你的常规任务数量乘以这个差值。
18这个差距就是你当前的模型选择税。

1拉取上个月的 Droid 会话日志。
2
3对于每个会话：
4- 任务类型（按规则 1 的分类）
5- 所用模型
6- 成本
7
8计算：
9- 在常规任务上使用前沿模型的总支出
10- 这些任务使用高效模型的成本（按 80-90% 的降幅计算）
11- 通过路由可实现的月度节省
12
13这是你启用 Factory Router 之前的基准。
14大多数团队会发现 30-50% 的会话是常规工作却在用前沿模型运行。

1任务的描述方式会向路由系统传递其复杂度信号。
2
3低复杂度信号（路由到高效模型）：
4- “简单配置更新，无业务逻辑：将 config.yaml 中的 timeout 从 30 改为 60”
5- “为 /helpers 中的工具函数添加缺失的 JSDoc 注释”
6- “更新 README 以反映新的部署步骤”
7
8高复杂度信号（路由到前沿模型）：
9- “重构认证中间件以支持新的 SSO 集成，涉及 3 个服务”
10- “调试支付处理器中的竞态条件（仅在并发负载下出现）”
11- “重新设计限流系统以支持每个租户的阈值”
12
13具体且上下文丰富的任务描述能提高路由准确性。
14模糊的描述会被保守地路由到前沿模型。

1估算 Factory Router 节省的公式：
2
3每月会话数：[N]
4无路由时的平均会话成本：[Opus 基准，以美元计]
5常规任务占比：[来自规则 1 审计的百分比]
6常规任务成本降低：80-90%
7
8月度节省估算：
9N × 基准 × 常规占比 × 0.85 = 每月回收的美元
10
11年度：乘以 12。
12
13对于一个每月运行 5,000 次会话、平均成本 2.87 美元、40% 常规工作的团队：
145,000 × 2.87 美元 × 0.40 × 0.85 = 4,879 美元/月 = 58,548 美元/年
15
16这是最低值。Missions（长时间运行的自主任务）会进一步放大节省。

1在启用路由之前，明确哪些工作必须留在前沿模型上。
2
3编写一次。将其粘贴为路由指导基线：
4
5“以下情况始终需要前沿模型：
6- 任何涉及 [认证/支付/安全层] 的更改
7- 涉及超过 [N] 个文件的跨服务重构
8- CI/CD 管道配置的更改
9- 数据库模式迁移
10- 任何在我们的问题跟踪器中标记为 [P0/关键] 的事务
11
12其他所有内容均可路由到高效模型。”
13
14这将成为你的路由策略文档。
15随着你了解哪些工作需要前沿模型处理，不断更新它。

1在 Factory CLI 或桌面应用中：
2
31. 打开模型选择器
42. 选择 “Factory Router”
53. 完成。
6
7无需任何配置即可开始。Router 会立即使用默认路由逻辑。
8
9验证是否启用：
10运行一个简单任务（"更新此文件中的注释"）。
11检查会话日志中的模型归属。
12你应该看到高效模型在处理它，而不是 Opus。
13
14如果在简单任务上看到 Opus，请确认 Router 已选中，而不是特定的模型覆盖。

1路由指导是建议性的。它帮助 Router 针对你的特定代码库做出更好的决策。
2它不会强制指定模型。
3
4将此作为路由指导起点粘贴，并根据你的技术栈进行编辑：
5
6"认证、支付和安全更改：使用前沿模型。
7数据库迁移和模式更改：使用前沿模型。
8影响外部消费者的 API 合同更改：使用前沿模型。
9
10文档更新：使用高效模型。
11为现有函数添加测试：使用高效模型。
12配置和环境变量更改：使用高效模型。
13样板代码生成和脚手架：使用高效模型。
14代码注释和 JSDoc：使用高效模型。
15README 和变更日志更新：使用高效模型。
16
17其他所有情况：Router 根据任务上下文自行决定。"

1对于大规模运行 Agent 的团队，路由指导成为一份治理文档。
2
3受监管行业（银行、医疗、企业 SaaS）的标准模板：
4
5"高灵敏度路由规则：
6- 任何涉及 [PII / 财务数据 / 认证] 的内容 = 仅限前沿模型
7- 任何外部 API 更改 = 仅限前沿模型
8- 生产部署脚本 = 仅限前沿模型
9- 事件响应任务 = 仅限前沿模型
10
11标准路由：
12- 开发、预发布和测试环境 = Router 自行决定
13- 内部工具和自动化 = 优先使用高效模型
14- 文档、报告和沟通 = 优先使用高效模型
15
16覆盖策略：
17任何开发者都可以针对某个任务请求使用前沿模型。
18Router 将其视为硬性覆盖，而非建议。
19所有前沿模型覆盖请求将被记录，供月度审查。"
20
21将此保存为 ROUTING_POLICY.md 文件，放在项目根目录。
22在 CLAUDE.md 或等效的上下文文件中引用它。

1Missions 是 Factory 的长时间运行自主任务。
2可能需要数小时或数天的工作，无需监督。
3
4启用 Factory Router 后，Missions 将受益于相同的路由逻辑。
5Mission 中的每一步都会被适当路由。
6复杂 Mission 中的简单步骤将在高效模型上运行。
7只有当真正需要前沿推理时，Mission 才会按前沿模型计费。
8
9配置方法：
10在启动任何 Mission 之前启用 Factory Router。
11添加反映 Mission 复杂度轮廓的路由指导：
12
13"此 Mission 涉及 [高复杂度核心工作] 和 [常规支持任务]。
14核心工作（架构决策、安全分析）：前沿模型。
15支持工作（文档、配置、样板代码）：高效模型。
16对于任何不包含上述指定推理的步骤，
17请使用可用的最高效模型。"
18
19长时间的 Missions 会获得比例更大的节省，因为它们累积了更多常规步骤。

1Factory Router 跨提供商进行路由，以提高可靠性。
2如果某个提供商路径出现问题，会话将通过健康的提供商继续执行。
3
4对于有正常运行时间要求的企业团队：
5
6"可靠性路由策略：
7- 每个模型的主要提供商：[列出你偏好的提供商]
8- 故障转移触发：任何请求失败或超过 [N] 秒延迟
9- 故障转移行为：如果可能，使用相同模型、不同提供商。
10  如果相同模型不可用，升级到下一个前沿模型。
11- 专用 TPM：与 Factory 客户团队确认你的层级。
12- 目标：99.9% 以上的请求可靠性。
13
14记录所有故障转移事件。每周审查提供商健康模式。"

1设定每周例行任务来跟踪 Router 性能。
2
3检查 Factory 会话日志：
41. 本周总会话数
52. 模型分布（每类模型占比）
63. 路由后的成本 vs 基准（全部使用 Opus）
74. 任何 Router 升级到前沿模型的会话（质量信号）
8
9报告格式：
10> 会话数：[N]
11> 高效模型使用率：[%]
12> 前沿模型使用率：[%]
13> 实际支出：$[金额]
14> 基准（全部 Opus）本应花费：$[计算值]
15> 每周节省：$[金额]
16> 升级到前沿模型的次数：[N]（审查路由指导改进）
17
18如果升级率超过 10%，请检查你的路由指导。
19升级过多意味着常规任务被描述成了复杂任务。

1在将 Factory Router 部署到整个团队之前，运行 Factory 的 Agent 就绪评估。
2
3它将评估 100+ 个信号，涵盖：
4- 代码库健康状况（测试覆盖率、CI 可靠性、文档）
5- 工作流成熟度（PR 流程、代码审查标准、部署管道）
6- 团队就绪度（对 Agent 工具的熟悉程度、现有自动化水平）
7
8使用输出来优先安排哪些工作流应先路由。
9
10高就绪度工作流：立即部署 Router，完全启用路由。
11中就绪度工作流：部署 Router 并采用保守指导，更多使用前沿任务。
12低就绪度工作流：先建立就绪度再路由。
13Agent 工具在未经准备的代码库上会在前沿模型上花费更多时间来纠正错误。
14
15Router 的节省在高就绪度环境中最高。

1Factory Router 从前沿和高效模型池中选取。
2你配置的池会影响可用的路由选项。
3
4推荐的初始池：
5
6前沿层（复杂工作）：
7- Claude Opus（最新版本）
8- GPT-5.2（如果在你的批准供应商列表中）
9
10高效层（常规工作）：
11- Kimi K2.6（代码任务方面的 F1 分数性价比最高）
12- MiniMax M2.7（简单任务成本最低）
13
14在验证了它们在你代码库上的性能之后，再添加模型。
15先从两层结构开始。
16有了路由数据后，再扩展到三层（前沿/中端/高效）。
17
18记录哪些模型已批准用于哪些合规要求。
19如果你的企业限制某些模型提供商，则相应地配置池。
20Factory 提供美国托管的开源模型，适用于需要数据驻留的环境。

1Factory 可在 CI 管道中工作。路由同样适用。
2
3将 Factory Router 添加到你的 GitHub Actions 工作流中：
4
5对于拉取请求审查：
6"按文件变更范围对 PR 审查任务进行路由。
7- 安全与认证文件更改：前沿模型
8- 测试文件：高效模型
9- 文档更改：高效模型
10- 混合型 PR：如果可能则分节路由，否则整个审查使用前沿模型"
11
12对于自动化 QA：
13"按测试复杂度对 QA 任务进行路由。
14- 关键路径端到端测试：前沿模型
15- 单元测试生成：高效模型
16- 回归测试套件：高效模型"
17
18CI 路由的节省会复合增长，因为它每次提交都会运行。
19在每天 100 次提交的测试生成任务上，Opus 与 Kimi K2.6 之间的成本差异是显著的。

1路由指导应随着代码库和团队的发展而演变。
2
3月度审查议程（30 分钟）：
4
51. 成本报告：实际 vs 基准，节省趋势
62. 升级分析：哪些任务升级了，为什么
73. 路由指导更新：当前指导是否仍反映代码库复杂度？
84. 新模型评估：池中是否有值得添加的新模型？
95. 团队反馈：开发者是否经常覆盖 Router？原因是什么？
10
11提示路由指导需要更新的一些问题：
12- 升级率高于 15%：指导过于偏向高效模型
13- 升级率低于 2%：指导可能过于保守，留下了节省空间
14- 开发者覆盖率高于 20%：Router 未达到开发者的预期
15
16每次审查后更新 ROUTING_POLICY.md。