AI 模型的选择与应用：谁干杂活，谁啃硬骨头

「你们现在用哪个模型？」这个问题我不太敢直接回答了。

因为答案听起来像在敷衍：有的活给便宜模型，有的活给推理能力更强的模型，代码审查还要按风险升级，需求文档也有自己的分工。听的人多半觉得这是折腾，但真正跑过一段时间的人知道，这不是收藏模型，而是在控制账单和返工。

团队刚把 AI 引入研发流程时，最容易走向两个极端：「哪个最强用哪个」，或者「哪个便宜用哪个」。前者会撞上账单，后者会撞上返工。更麻烦的是，模型价格不能只看输入单价：输出 token、上下文重复发送、缓存命中、工具调用、重试次数和服务渠道都会改写总成本。订阅套餐的月费，也不能直接拿来和 API 的按量价格比较。

反过来也不行。让旗舰模型去写日志解析脚本、改配置文件、润色周报，就像打车去买楼下便利店的一瓶水，不是不行，是贵。

所以这篇文章想聊清楚一件事：模型选择不是选一个「最好的」，而是把活分层，给每一层配一个「刚好够用又划算」的模型。 先给结论：

• 低风险、高频任务给便宜模型：脚本、格式转换、文档整理和样板代码，结果容易验证，失败也容易重来；
• 高风险、长链路任务给强模型：并发问题、跨模块重构、技术方案和安全相关变更，错误代价远高于模型差价；
• 审查按风险级联：确定性问题先交给 linter、静态分析和依赖扫描，LLM 负责语义检查；命中高风险路径或证据不足时，再升级模型和人工复核；
• 需求是上游：AI 可以整理和质疑需求，但业务目标、约束与验收标准仍由人确认；
• 瓶颈在流程：要把这些环节稳定串起来，就需要工作流集成；对没有专人维护研发基础设施的中小团队来说，工程化成本可能高于模型费。

下面按编码、审查、需求、测试的顺序展开，最后聊为什么这套东西在很多团队里落不了地。

一、先把任务分层，再谈选模型

1.1 价格容易比较，能力不能看一个总分

先看一个常见误区：拿某个编码基准的总分除以 API 单价，试图算出一个「性价比冠军」。这个数看着科学，实际混合了不同模型版本、推理预算、工具配置和题目污染风险，未必能预测你的仓库里会发生什么。

价格差距倒是真实存在。按 2026 年 8 月 20 日各家官方 API 定价，低价档与高端档的标准输入、输出单价常见相差约 5～20 倍；算上缓存、批处理、长上下文、地域路由与低峰价格后，比例还会变化。具体数字应以 OpenAI API 定价、Claude API 定价 和 DeepSeek API 定价 为准，而不是依赖更新不及时的聚合榜单。

这不是说贵的一定值，也不是说便宜的一定划算。真正要比较的是：在相同上下文、工具和验收标准下，完成一次任务的总成本是多少。 单次调用便宜但要重试五次，可能更贵；旗舰模型一次做对，但把整个仓库反复塞进上下文，也未必省钱。

因此，公开基准只适合筛候选，最终选型要回到团队自己的小型评估集：选 20～50 个真实、已脱敏、覆盖不同难度的任务，固定提示、上下文和工具，记录一次通过率、人工修订时间、端到端延迟与 token 成本。排行榜回答「模型大概会什么」，这组数据才回答「它在我这里是否划算」。

1.2 先看自己的工作分布

再看研发工作的分布。把一周的活摊开数一数，你会发现它长得很像长尾：

• 高频低难度：写一次性脚本、改 YAML 配置、拼 SQL、写单元测试、给函数补注释、生成样板代码、整理日志、写周报。量大、重复、结构清晰，做错了编译器或测试会兜底。
• 中频中难度：普通业务功能开发、小范围重构、排查常规 bug。需要一些上下文理解，但有代码库和测试约束，方向不容易跑偏。
• 低频高难度：并发和竞态问题、跨模块架构调整、疑难 bug 的根因分析、性能优化、安全审计。单次耗时极长，试错成本极高，错了不是改一行，是带偏一整个方向。

不少团队的 AI 调用会呈现这种长尾，但比例不能替别人拍脑袋。先从网关或助手导出一个月的匿名统计，再按任务类型、风险和 token 量分类。对评估集上通过率接近的简单任务，价格、延迟、稳定性和数据边界才是主要变量。

1.3 分层的原则

把「任务风险」和「模型档位」对齐，我用的判断标准是四个问题：

1. 做错了代价多大？ 错了会被编译器发现、测试拦截、随时重写，还是错了会埋进生产、误导设计、带偏团队？
2. 需要多深的上下文和推理？ 一个函数内的逻辑，还是跨模块、跨服务、跨需求文档的因果链？
3. 量大不大？ 每天跑几次，还是每天跑几百次？
4. 数据能不能发出去？ 是否包含源代码、密钥、个人信息、客户数据或受地域限制的数据？模型够不够强，不能越过合规边界。

前 3 个问题的答案越「重」，越值得提高模型档位；第 4 个问题则是硬边界，不满足就不能发送。这张表是一个起始映射，后面每一节都会解释它为什么这么分：

这张表不是静态的。模型在迭代，价格在降，去年「不够用」的今年可能「刚好够用」。分层策略的意义恰恰在于：它给了你一个稳定框架，模型变了，改的是映射关系，不是整个流程。

二、编码侧：低风险走快车，高风险留预算

2.1 什么是「杂活」

编码侧最容易出问题的地方，是很多人对「编码」一视同仁。写一个解析 Nginx 日志的脚本和排查一个偶发的并发 bug，都被归为「写代码」，于是都交给同一个模型。

我把杂活定义得宽一些：所有量大、重复、结果可验证、做错了代价低的工作。

• 非编码但技术相关的：翻译技术文档、整理会议纪要、把 JSON 日志转成表格、写正则、拼复杂的 find 或 awk 命令、解释报错信息；
• 低难度编码：一次性脚本、简单 CRUD、改配置文件、补单元测试、格式化、生成样板代码、把一种数据格式转成另一种。

这类活的共同点是上下文相对短、答案有明确约束，错了有编译器、测试或下一次运行兜底。在它们确实占团队调用大头时，也最值得优化单价和延迟。

2.2 为什么低价档通常够用

三个理由，按重要性排：

第一，便宜。 高频任务每次只省几分钱，一个月跑上千次就会形成稳定差额。省下来的预算，恰好留给高风险任务、工具调用和人工复核。

第二，通常更快，但要实测。 小模型往往首 token 更快、吞吐更高，不过供应商排队、地域网络和推理模式都可能反转结果。杂活追求的是「要什么马上给什么」，所以延迟应进入评估表，而不是从模型大小直接推断。

第三，结果容易验证。 低价档并不天然可靠，只是这类任务有便宜的反馈：编译器、测试、schema、格式化器或人工抽查能很快暴露错误。真正给人底气的不是模型名，而是验证闭环。

DeepSeek 的低价型号、OpenAI 与 Anthropic 的小型号，以及其他满足数据边界的模型，都可以进入这一层。它的定位是吞吐层，不是「永远正确层」。谁在你的评估集上便宜、快、通过率够用，就用谁，没必要把供应商名字焊死在流程里。

2.3 什么是「硬骨头」，为什么值得用贵的

硬骨头的特征是：上下文长、因果链深、做错了代价高、且没有便宜的验证手段。

• 排查偶发的并发问题：需要把 goroutine 调度、锁、channel、内存屏障串成一条因果链，错一步方向就偏；
• 跨模块重构：要同时理解十几个文件的耦合关系，改了一个调用点，连锁反应要在脑子里过一遍；
• 疑难 bug 的根因分析：现象和根因之间隔了三四层抽象，每一层都可能是陷阱；
• 架构设计和技术方案评审：方案一旦拍板，后续几个月的开发都建立在这个决策上。

这类任务的共同点是试错本身很贵。强模型更可能减少无效尝试，但这仍需用团队任务验证。若模型缺少关键运行时信息、生产指标或业务约束，再贵也只能给出更流畅的猜测。

还有一个容易被忽略的点：硬骨头通常量小，但单次上下文很大。 把省下的日常预算挪到这里通常划算，不过不能因此把成本写成「微不足道」：长上下文、工具结果、反复执行测试和多轮修复都会吃 token。

所以这一层应从各家的强推理或编码型号里选。具体选谁，取决于仓库评估结果、上下文与工具能力、数据处理条款、可用地域、速率限制和故障切换方案。高风险任务还要保留人工判断，不能把「用了旗舰」当成质量证明。

2.4 编码之外：需求补充、设计与任务拆分

「编码」这个词之外，还有三类工作经常被漏掉，但它们同样需要 AI 参与，而且难度都不低：

• 需求补充：拿到需求文档后，把含糊的部分列成问题清单反哺产品。这是典型的「读得懂还要问得出」，对上下文理解有要求。
• 设计：技术方案的第一稿。架构选型、模块划分、接口定义、数据流。错了会影响后面所有代码。
• 任务拆分：把需求拆成可独立交付、可独立验收的子任务，排依赖、估规模。拆分质量会显著影响后续编码和测试的效率。

这三类工作的产出接近「决策」而不是「代码」，错了不会马上报错，而是像慢性病一样在项目后期发作。所以它们应该归入中高风险档：强模型可以帮忙列备选、找矛盾和整理证据，最终取舍由能承担结果的人确认；低价模型则适合把评审纪要转成 checklist 之类的机械工作。

这里藏着一个伏笔：任务拆分能不能省力，很大程度取决于上游的需求文档质量。 需求文档结构清晰，拆分就更接近机械劳动；需求文档含糊，拆分就成了猜谜，AI 容易把含糊继续传下去。这条链的起点，在第四部分。

2.5 编码侧的成本账

把上面的策略落成一组可复算的示例。假设团队一个月处理 800 次 AI 任务；为了避免把某天的厂商价格伪装成长期规律，统一使用两档四舍五入后的代表单价：低价档输入/输出为 0.5/1.5 美元 / 100 万 token，强模型档为 5/25 美元 / 100 万 token。这不是报价，只是预算模型。

计算公式只有一条：成本 = 输入 token × 输入单价 + 输出 token × 输出单价。按相同 token 量，全用低价档约 8 美元，全用强模型约 98 美元，分层约 29 美元。实际账单还要加缓存写入、搜索等工具调用、失败重试、代理平台加价和税费；反过来，缓存命中或批处理也可能把成本压低。更重要的是，三种方案的质量不能靠价格推断，必须把人工修订时间和失败率一起记账。

编码侧的分层，本质是把「贵」用在错误代价最高的地方。 到这里，编码侧的账算清楚了。但编码只是研发流程的一环，更大的省法和更大的坑，在审查侧。

三、审查侧：工具打底，模型按风险级联

3.1 为什么从审查开始自动化

代码审查天然处在 MR 流程里，确实适合自动化，但顺序不能搞反：先用确定性工具处理确定性问题，再让模型处理语义问题。

把一次人工代码审查拆开，你会得到两类工作：

• 机械部分：格式、命名、已知危险函数、依赖漏洞、部分空指针和资源泄漏模式。规则明确，适合 formatter、linter、SAST（静态应用安全测试）与 SCA（软件成分分析）。
• 判断部分：设计是否合理、抽象是否过度、这个取舍是否符合业务方向、测试有没有覆盖真正的风险。需要上下文、经验和立场。

机械问题到底占多少时间，各团队差异很大，不能凭感觉写成一个普遍比例。能确定的是：这部分可重复、可验证，而且不需要为每一行支付 token。先把它们挡在模型之前，通常比教 LLM 模仿 linter 更便宜、更稳定。

LLM 更适合补工具的盲区：跨文件的行为变化、错误处理是否符合业务语义、测试是否覆盖了真正的风险。它会漏报也会误报，长 diff 还可能被截断，所以正确分工是：工具查规则，模型找线索，人作判断。

3.2 接入方式：GitLab 里的审查机器人

代码托管在 GitLab，审查机器人就以 GitLab 为中心搭。实现不复杂，核心是一条线：

MR 创建/更新 → 触发 → 拉取变更 → 拼 prompt → 调模型 → 把评论写回 MR

触发方式有两种，各有利弊：

• Webhook 触发：GitLab 的 Merge Request 事件推送到自建服务，服务调 GitLab API 拉 diff，审查完成后把结果作为 MR 评论发回去。灵活，能做复杂的后处理，但需要维护一个常驻服务。
• CI 触发：在 .gitlab-ci.yml 里加一个 job，在 MR pipeline 中运行。job 可以读取源码和 MR 相关环境变量，再通过 GitLab API 写回评论。它不需要单独的常驻服务，但仍要维护 Runner、凭证、重试与去重；是否每次 push 都跑可以用 rules 控制。

两条路各有利弊，我更倾向 CI 触发：少一个常驻服务，少一类故障。机器人拉取变更后，把 diff、变更文件列表和仓库规范拼成 prompt，交给模型，再把结果解析成带行号定位的评论。

实现上值得注意的几点：

• 评论要分级。把 AI 输出分成 blocker（必须改）和 suggestion（建议）两档，写回 MR 时用不同前缀区分。全是一个级别，人会直接无视。
• 行级定位。评论必须钉在具体行上，能 diff 定位就定位，定位不了的放总评。飘在空中的评论没有行动力。
• 控制噪音。同一类问题每个 MR 刷几十条，前三次还有人看，第四次开始全团队选择性失明。机器人的系统提示里要明确「只报有实际影响的，风格类问题留给 linter」。

3.3 两级级联：风险路由，不是便宜模型放行

机器人的第一步是接入流程，第二步才是算账：哪些 MR 可以只做轻量检查，哪些必须升级？

不能只让低价模型说「通过」就结束，因为最难发现的问题恰恰可能被第一级漏掉。级联要加入与模型结论无关的风险信号：认证、权限、支付、加密、数据迁移、公共 API、并发原语、大范围删除，以及异常大的 diff，都应直接升级。

于是有了级联设计：

MR 到来 → linter / 测试 / SAST / SCA
                ↓
       低价模型做语义初审
        ↓             ↓
低风险且证据充分   高风险 / 存疑 / 工具告警
        ↓             ↓
     人工审查 ← 强模型复核

第一级用低价模型做语义初审。 它输出的不是笼统的「通过/不通过」，而是带文件、行号、证据和置信度的候选问题。格式与已知规则不让它重复检查，避免评论刷屏。

第二级用强模型复核。 触发条件既包括初审存疑，也包括上面的高风险路径和确定性工具告警。复核要读取必要的调用链、测试和仓库规范，而不是只看孤零零的 diff；输出仍然只是供人判断的证据。

这个设计能不能省钱，取决于升级率。若每个 MR 都升级，级联只会增加一次低价调用；若初审漏报严重，省下的调用费会变成事故成本。上线前应在历史 MR 上回放，至少记录准确率、召回率、每千行评论数、升级率、人工采纳率和平均审查时长。

在没有这些数据之前，不能宣称成本只有几分之一、拦截率几乎不变。可以先以影子模式运行：机器人评论但不设门禁，与人工结论对照几周，再决定阈值。AI 审查从头到尾都不是终审。

3.4 多角色：不同方向，不同模型

通用审查解决「这代码写得对不对」，但专业风险有专业的门道。一个通用 prompt 让模型同时审安全、性能和依赖，结果是什么都提一嘴，什么都审不深。

更有效的做法是按审查方向拆角色，每个角色有独立的系统提示、独立的触发条件，甚至独立的模型：

• 安全审查：注入、越权、敏感信息泄漏、危险函数、加密误用。先跑 SAST 和密钥扫描，再让强模型结合业务授权模型找语义漏洞；模型不能替代安全负责人。
• SQL 审查：SELECT *、隐式类型转换等规则交给静态检查；索引是否缺失、查询是否慢，要结合 schema、执行计划和真实数据分布，不能只看 SQL 文本。
• 依赖审查：许可证和已知漏洞优先读取 lockfile、SBOM、漏洞数据库与项目官方信息。模型适合汇总证据，不应凭记忆判断版本是否安全。

角色之间可以并行：同一个 MR，安全角色和 SQL 角色同时开跑，评论用不同前缀写回，比如 AI/SECURITY 和 AI/SQL。开发者一眼能看出是哪类问题，处理优先级也清楚。

触发条件也可以按内容优化：改动涉及 SQL 文件、查询构造代码或 schema 时跑 SQL 审查；依赖清单或 lockfile 变化时跑依赖审查；鉴权、加密相关路径无条件跑安全审查。触发器也会漏判，因此高风险角色还应允许人工手动启动。

角色的边界也是扩展点。团队如果开始重视数据合规，就加一个「个人信息处理审查」的角色；重视可观测性，就加一个「日志与指标审查」。角色的本质是把「团队关心的方向」翻译成「独立的 prompt 和触发规则」，加一个方向不扰动其他角色。

3.5 AI 通过之后，人才介入

流水线的最后一步很关键：AI 审查通过 ≠ 审查通过。

AI 审查的价值是把人从机械劳动里解放出来，让人去做 AI 做不了的事：这个设计在业务上对不对、这个取舍值不值、这个抽象会不会害了下一个接手的人。 人工审查的重点从「挑错」转移到「判断」，从逐行挑刺变成对设计、对业务、对方向的确认。

实操上可以让自动检查先跑完，但不必让人等所有模型串行结束。低风险检查可以并行；涉及权限、资金、隐私和数据破坏的变更，则必须等强模型与责任人完成复核。人工看的重点是模型给出的证据、模型没覆盖到的业务语义，以及这次变更是否值得承担风险。

误报是绕不开的话题。AI 评论应是「提示」而不是「判决」，但开发者核实并关闭一条错误评论并非零成本。如果机器人十有八九在胡说，团队很快就会选择性失明。所以要限制评论预算、合并重复问题、要求引用证据，并持续统计采纳率。宁可少说，不可刷屏。

到这里，审查侧的边界也清楚了：确定性工具打底，低价模型提供候选线索，强模型处理高风险与疑难项，人承担最后的判断。成本通常逐层增加，处理量则应逐层减少。

但审查机器人再聪明，也审不出「这个需求本身就不对」。要解决这个问题，得上游走。

四、需求侧：AI 写代码，倒逼需求质量

4.1 需求质量是 AI 产出的天花板

生成式模型很容易补齐缺失信息：如果流程没有明确要求它停下来提问，它往往会替含糊需求编一个合理解释，然后一路做下去。 有些代理会主动澄清，但这取决于提示、工具和执行策略，不能把它当成默认保障。

有经验的人拿到含糊需求，通常会问：「这个字段为空时怎么处理？」「两条规则冲突时以哪个为准？」代理也应该被要求先列假设和阻塞问题，未获确认不得实现。否则它会用最符合统计直觉的内容把洞填上，而且填得很流畅，直到边角场景炸掉才暴露。

三种最典型的问题需求，对 AI 都是灾难：

• 含糊：「列表页要快」。快是多快？数据量多大？瓶颈在查询还是渲染？AI 会把「快」翻译成「加个索引」，然后心安理得地交差。
• 自相矛盾：「同时支持导出全部数据和限制导出数据量」。两个规则互斥，AI 会两个都实现一半，或者默默选一个而你不知道它选了哪个。
• 上下文缺失：「复用现有的登录模块」。哪个模块？什么接口？什么版本？如果拿不到仓库信息，AI 很可能假设一个看似合理的模块，而且不会自动标出这个假设。

人的含糊有机会被沟通拦截，AI 的含糊则可能被「合理猜测」悄悄消化。所以用 AI 写代码，把需求质量变成了全流程的硬约束：需求写得烂，代理只会更快地产生需要返工的代码。

4.2 需求也要 AI 写、AI 审

既然 AI 写代码对需求质量这么敏感，就让 AI 更早介入需求，但不是把需求的所有权交给 AI。产品侧可以让模型整理初稿、做对抗审查，再进入人工评审。

AI 整理需求，不是让它从零编业务，而是给它经过授权的业务背景、用户反馈和约束，让它产出结构化草稿：背景与目标、非目标、功能描述、边界条件、异常流程、验收标准、影响范围。产品经理仍要确认业务判断并补充模型不知道的约束。能省多少时间因团队而异，在没有实测前，不该写成「两小时压到半小时」。

AI 审需求，则是按固定的检查清单过一遍：

• 一致性：前后术语是否统一、规则之间是否矛盾、数字是否对得上；
• 完整性：每个功能点有没有验收标准、异常流程有没有覆盖、边界条件是否明确；
• 可测试性：验收标准能不能转成测试用例，还是写成了「体验良好」这种没法验证的句子；
• 可拆分性：功能点之间的依赖是否清楚，能不能拆成独立交付的任务。

这两步可以优先测试强模型，因为需求站在整条链的上游。不过「文档短，所以花不了多少钱」也不总成立：竞品材料、会议记录和历史决策会显著拉长上下文。更稳妥的做法是先用低价模型清洗、去重和索引材料，再让强模型只读取相关证据；关键数字与结论必须能追溯到来源。

4.3 人评审的位置变了，但没有消失

AI 写、AI 审都通过之后，文档进入常规流程：需求评审、技术评审。这一步不能被 AI 替代，但它的内容变了。

需求评审常会花时间处理「这行字什么意思」「这里缺个异常流」「两个地方写得对不上」。AI 预审可以提前暴露一部分问题，但不能保证清零。评审会上仍要回答真正需要人的部分：这个需求该不该做、业务价值够不够、技术方案是否合理、排期和风险怎么定。

理想结果是把产品、研发、测试从文字校对中省出来，转向 AI 替代不了的判断。但会议是否真的变短，应由评审时长、会后补充问题数和需求返工率验证，不能只凭体验宣布胜利。

4.4 任务拆分的水到渠成

需求文档过了评审，到研发侧的任务拆分，通常会顺畅一些，但不等于不用补文档。

原因是拆分的结构已经藏在文档里：功能点清单是任务骨架，验收标准是完成条件，依赖关系是排期依据。AI 能把骨架展开并提出顺序，但工作量估算、隐含的组织依赖与发布风险仍需要团队补齐。

对比一下没有这条链的情况：研发拿到一份口头转述、补充全靠微信群聊记录的需求，任务拆分变成考古——从聊天记录、设计稿截图和「上次开会说过的」里拼出真相。那种状态下让 AI 拆分，它只会把含糊分得更碎。

五、测试侧：需求充分之后的水到渠成

5.1 从验收标准到测试用例

测试是需求链条上最顺滑的一环：验收标准几乎就是测试用例的骨架。 一条「导出数据量超过一万条时需要分批」的验收标准，天然对应正反两组用例：正常分批、边界值、超限场景、失败重试。

AI 在这个环节的产出分两层：

• 用例清单：从需求文档抽取场景，生成带编号的用例列表——前置条件、步骤、预期结果，覆盖正例、边界和异常。低价模型可以先做，人需要检查是否漏掉业务风险。
• 测试代码：把用例清单转成可执行代码。单元测试模板性强，适合低价模型，但「测试通过」只说明实现符合这份测试，不能证明测试本身正确。至少要评审关键断言，并结合覆盖率或变异测试检查测试是否真的能抓住错误。

模型选择上，测试生成和低难度编码可以共用一档：低价模型为主，高风险测试人工复核。 红灯能暴露实现或测试不一致，绿灯却可能来自一个无效断言，别把颜色当结论。

5.2 测试跑完之后，AI 还能接着干活

测试的执行和结果分析也是 AI 的用武之地：

• 失败定位：把已脱敏的失败日志和相关代码交给模型，让它给出带证据的根因假设，不把猜测写成结论。
• 归类 flaky：重复失败的用例、时好时坏的用例，让模型读历史日志做归类，人再决定修还是删。
• 补漏：审完需求文档，让 AI 对照现有用例清单，指出哪些验收标准还没有测试覆盖。

这些活零碎、量大，适合从低价档开始。测试侧的完整闭环是：需求充分 → 用例清单 → 测试代码 → 执行 → 结果分析。 每一环 AI 都能辅助，但都要留下可执行证据。

5.3 但前提始终是需求

测试侧这条链跑得顺，有一个重要前提：需求文档写清验收标准、异常流和边界条件。需求充分不等于测试自动充分，但至少提供了可验证的起点；「体验良好」这种标准连人都难以转换成用例，AI 生成再多也只是虚假的安全感。

所以测试侧的选型不能脱离需求质量、代码风险和验证工具单独决定。这也是我把需求侧放在整篇文章中间位置的原因：上游越含糊，下游越难用测试补救。

六、全链路：一条需求的旅程

把前四部分拼起来，一条需求从提出到上线的完整旅程长这样：

每个节点旁边标着的模型档位，是前面几节的结论落点。注意这条链的两个特征：

第一，每个环节的 AI 都在消费上一个环节的产物。 任务拆分消费需求文档，编码消费任务，审查消费代码，测试消费需求与实现。质量沿链条单向传递，上游含糊一点，下游放大一圈。这解释了为什么需求侧的投入性价比最高，也解释了为什么需求侧不值得省钱。

第二，人的位置全部在「决策点」。 需求评审、人工审查、方案确认，AI 负责把物料准备好，人负责拍板。AI 替代的是「生产物料」的体力活，不是「承担责任」的判断活。

整条链不能简单折算成「一条需求几美元」。大型仓库的上下文、工具调用和重试可能让模型费明显增加，接入、监控、评估与人工复核更不是免费的。预算时至少分开记录 API 成本、平台订阅、基础设施、维护工时和返工工时。省下来的若只是模型钱，不算提效；端到端交付时间和缺陷率一起改善，才算。

问题来了：这张图在你的团队里跑得起来吗？

七、现实困境：这套流程为什么经常嵌不进去

7.1 流程高度依赖工作流嵌入

前面所有的设计，都建立在一个隐含前提上：你的研发流程是结构化的。

审查机器人要挂在 MR 事件上，需求文档要进评审流程，测试要接 CI，任务拆分要进看板。AI 不是一个装在 IDE 里的插件，插上就能用；它是嵌在工作流里的一组节点，每个节点都要和现有的托管平台、流水线、评审制度、文档习惯对上接口。

这正是 AI 提效最容易被低估的成本。网上演示的 AI 工作流都在标准化的平台上跑：GitHub 的 Action、GitLab 的 webhook、现成的机器人框架，装上去就能动。但真实企业的流程千差万别：有的用 Gerrit 的 Change 模型，有的用 Gitea 的自托管，有的评审在群里口头过，有的需求文档在飞书上散落着。AI 工作流的落地难度，取决于现有流程离「结构化」有多远，而不是模型本身有多强。

一个典型的例子是审查机器人。GitLab 的 MR pipeline、Webhook 和行级 Discussion API 能把常见拼图直接接起来；Gitea 也已经提供 Pull Request Webhook、REST API 和内置 Actions，并非「没有接口」。真正的差距更多在现成集成数量、权限细粒度、工作流兼容细节、运维责任和团队熟悉度。工程量应通过原型验证，不能武断地写成「半天」对「一周」。

7.2 托管平台会显著影响工程量

这引出一个容易忽略的事实：托管平台会显著影响 AI 工作流的基础设施成本，但不是唯一变量。 这件事我在《源代码托管怎么选：Gerrit、GitLab、GitHub 与 Gitea》里写过选型的四个问题，这里只补 AI 这一个维度：

• GitHub：第三方 Action 和应用生态成熟，找现成集成相对容易；公有云、企业版与数据驻留仍要按组织要求评估。
• GitLab：CI/CD、Webhook 与 MR API 集成度高，自托管和 SaaS 都有完整路径；许可档位、升级和 Runner 运维同样是成本。
• Gitea：轻量、可控、自托管，提供兼容 GitHub Actions 的 Gitea Actions、Pull Request 事件和 API；生态与部分工作流语法不如 GitHub 丰富，Runner、安全隔离和兼容性验证需要自己负责。可参考 Gitea Actions 与 Webhook 事件文档。

注意这里的因果：平台能力、生态与团队现状共同决定自建成本。 选型时应做一个最小原型：触发 PR、读取 diff、提交行级评论、限制机器人权限、重跑与去重。五件事跑通，再谈谁更适合，不要用品牌印象替代验证。

7.3 大不大小不小的团队最痛苦

更大的问题是人。

大厂有平台组、效能组，一群专门的人维护研发基础设施：CI 平台、机器人框架、代码扫描、评审规范。AI 工作流对他们来说是「在现有平台上加一个模型调用」，基础设施是现成的，甚至预算也是现成的。

极小的团队流程更轻，可能只需要 IDE 助手和人工互审，暂时不值得维护一整套审查机器人。

最痛苦的是中间态：「大不大小不小」的团队。 业务复杂到需要流程约束，人却少到没有人专门维护基础设施。CI 是某个后端兼职在管，代码托管当初是「图省事」选的 Gitea，评审规范贴在墙上没人更新。这样的团队看到前面那套全链路，第一反应不是「怎么落地」，而是「谁来维护」。

这个困境没有银弹，只能承认：模型费用只是 AI 工作流成本的一部分，工程化能力往往更稀缺。 调通 API 不难，把它变成每天稳定运行、可观测、可回滚的流程，则需要时间和明确的维护责任。

7.4 务实路径：从最小闭环开始

给同处中间态的团队的建议是：不要一次全上，从最小闭环开始，一步一步加：

• 第一步，IDE 助手。先在非敏感仓库或沙箱试用，杂活档配低价模型。这一步接入成本较低，但仍要处理账号、许可、数据策略和效果评估。
• 第二步，审查机器人。等 MR 量涨到人工审查吃力了，再上审查机器人。先只做「评论，不设门禁」——机器人只提建议，不阻塞合并。团队适应了它的表达方式，再考虑两级级联和门禁。
• 第三步，需求侧。由愿意试点的产品经理先行：AI 整理需求、AI 找矛盾，人确认业务判断。跑通一两个项目并记录返工率，再决定是否推广。
• 第四步，测试侧。需求文档质量稳定之后，再试点生成测试，并用关键断言评审、覆盖率或变异测试验证效果。

每一步都是「上一个环节稳定了，再开下一个」。中间态团队的容错率低，一次铺开五个环节，任何一个环节的机器人挂了、prompt 漂了、评论刷屏了，都会让整个团队对 AI 工作流失去耐心——而耐心是这套东西唯一不能花钱买的资源。

还有一条务实的边界：能买的不自建。 审查机器人、AI 编码助手、需求评审工具，如果市面上有成熟的 SaaS 或开源方案，优先用。自建的意义在于「贴合自己的流程」，但对没有专人的团队来说，自建的维护成本会以「某个周末」的形式持续征收。工具可以慢慢换，流程断了团队就散了。

7.5 数据与权限先于模型能力

模型选得再漂亮，代码和客户数据发错地方，整套方案依然不及格。接入前至少确认：供应商是否保留输入、是否用于训练、数据处理地域、删除与审计能力、企业合同，以及内部哪些仓库允许外发。密钥、访问令牌和生产日志默认应先扫描、脱敏或直接禁止发送。

带工具的代理还多一层风险：仓库文档、Issue、依赖说明甚至代码注释都可能包含提示注入，诱导模型泄露上下文或调用危险工具。应使用最小权限的短期凭证，把读代码、写评论、修改代码和合并发布拆成不同权限；来自仓库的文字一律当作不可信数据，危险操作需要确定性规则与人工批准。

八、结尾：选模型不是收藏模型

回到开头的问题：「你们现在用哪个模型？」

现在可以回答得更准确：低风险任务从低价档开始，高风险任务给强模型并保留人工复核；代码审查让确定性工具打底，再按风险级联；需求由 AI 整理和质疑，人负责决定。 供应商名字只是当前映射，不是方法本身。

这套分层的依据从头到尾只有一条：按任务的错误代价、验证成本、数据边界和调用规模来路由。 便宜模型做杂活的底气来自结果容易验证，强模型啃硬骨头的理由来自一次正确方向的价值，而两者都不能越过人的责任边界。

再往深一层看，token 单价通常不是最难控制的部分。真正稀缺的是把模型嵌进流程并持续校准的工程化能力：那个挂在 MR 事件上的机器人、那份可追溯的需求文档、那组不会随着模型更新一起失效的评估任务，以及那条有人负责、能够降级的流水线。

说到底，模型选型不是一次采购，而是一条反馈回路：先定义风险和验收标准，再用自己的任务测，记录成本与返工，最后调整路由。先跑通一个最小闭环，再让数据决定下一步。这样才不至于模型换了一代，整套方法也跟着报废。