你可能已经跑通过一个 demo，但一接真实业务就发现：输出不稳定、成本算不清、换个模型效果全变、出问题没法复现。这篇不聊概念，按 AI 工程的做事顺序给一套流程——怎么把需求拆成可测的任务、接口层怎么封装、上线前后怎么盯质量，每一步都给出可执行动作和不适用的情况。
你已经跑通过一个 demo 了，接真实业务才发现问题一堆：同一个 prompt 今天好用明天抽风，成本月底一看吓一跳，想换个模型发现业务代码里到处是某家 SDK 的参数，线上出了错连复现都做不到。这些不是模型的问题，是工程没搭起来。
这篇按 AI 工程的做事顺序给你一套开工流程，从需求怎么拆、接口层怎么封、成本怎么算，到上线后怎么盯质量，每一步都给出可执行动作，也说清什么情况下这套流程不适用、别硬套。
先把需求拆成可测的任务，再谈模型
把业务诉求拆成三件事：输入是什么、输出格式是什么、错了怎么发现。这三件拆不清楚，说明这个需求还不适合上大模型，先别急着写代码。拆的时候可以到 /ai-dict/category/application 对照行业场景词，确认自己到底属于哪一类任务，别把检索问答和内容生成混成一个需求。
| 容错等级 | 典型任务 | 技术路线倾向 |
|---|---|---|
| 格式错一点能接受 | 摘要、改写、分类打标 | 可以放宽校验，重点看批量稳定性 |
| 事实错一点不能接受 | 问答、数据查询、合规回复 | 必须接检索或工具，输出要能溯源 |
| 格式和事实都不能错 | 结构化抽取、对接下游系统 | 强校验加兜底，模型只做候选生成 |
- 不要用「效果好」当验收标准，改用一组固定样例，含正常、边界、刁难三类，作为回归集；
- 题型怎么组织可以参考 /benchmarks 里现有榜单的题目设计思路，但别照抄题目内容；
- 每类任务单独记一份「错了长什么样」，这是后面排查和回归的原始素材；
- 如果任务本身没有稳定输入输出，比如开放式头脑风暴，就别硬套这套流程，换个验收方式。
接口层怎么封，决定了后期换模型疼不疼
核心就一句话：业务代码不认某家厂商的 SDK 参数，只认你自己定义的内部方法名。所有模型调用统一走一层适配层，换模型时只改这一处，别去业务文件里全局搜索替换。这一步前期多花半天，后期能省掉无数次返工。
- 定义内部调用契约方法名、入参、返回结构自己定，和任何厂商的参数名解耦；验证方式是搜一遍业务代码，看还有没有厂商专有字段。
- 固定三样东西超时与重试策略、输出结构校验、失败时的兜底返回。缺任何一个，上线后都会以你意想不到的方式出事；验证方式是手动断开网络或塞一个畸形返回，看链路怎么反应。
- prompt 当代码管版本化存放，记录每次改动对应哪批样例；验证方式是随便挑一次线上问题，看能不能定位到当时用的是哪版 prompt。
- 多通路入口先摸底到 /ai-nav/category/ai-api 看有哪些口径可比的入口，比价和额度核对去 /official-api 与 /inference 看当时的数字，别在群里问别人多少钱。
不适用的场景也得说清：一次性的内部小工具、只给自己用的脚本，接一层适配层就是过度设计，直接调厂商 SDK 反而更快，别为了「规范」给自己加活。
成本与吞吐：先算清账再调参
成本别凭感觉判断贵不贵。按「单次请求的输入长度乘调用量」估出月度用量，再拿当时的单价去 /tools/model-cost-calculator 和 /tools/token-price-calculator 换算。单价会变，所以只看工具里当时显示的数字，别记在脑子里。
最容易把 token 吃光的是三个地方：长上下文、多轮对话、检索拼接。分别量出各自占比，再决定优化哪块。三项都高就先砍检索拼接的冗余，多轮对话考虑做历史摘要，长上下文看看能不能只传相关片段。
| 现象 | 先量什么 | 再决定什么 |
|---|---|---|
| 账单比预期高 | 输入长度与调用量的实际分布 | 砍检索冗余还是缩短上下文 |
| 响应慢 | 到 /tools/speed-test 量真实链路延迟 | 瓶颈在网络、模型还是自家检索 |
| 并发一上来就超时 | 适配层的超时与重试是否白等 | 调超时阈值还是加队列 |
用量极小、还在验证阶段的产品，这个阶段该关注的不是省不省钱，而是能不能跑通；过早优化单位成本，容易把产品方向也一起优化没了。
上线不是终点，评测和回归才是日常
固定一套回归样例，每次改 prompt、换模型、调参数都跑一遍，比对通过率，而不是凭印象说「好像变好了」。最有价值的数据来源是线上失败样例，回收进回归集，比任何公开榜单都贴近你的真实场景。
- 改一次 prompt 就跑一次回归，通过率掉了就先回滚再分析；
- 线上失败样例当天记录，按失败类型打标签，别只存原文；
- 判断模型够不够用时，先看 /rankings 的可信度排行和 /benchmarks/registry 的榜单库，再看 /crowd-radar 这类多人交叉验证的口径；
- 公开分数只能当参考，和你的任务不一定对得上，别拿榜单名次直接当选型结论。
换模型前留好回退开关，先小流量对比再全量切换，迁移的检查项可以参考 /models/deploy 的部署测算口径。原型期一天改八版的时候，强行维护完整回归会拖死进度，这时候保证样例集覆盖主路径就行，别追求全。
能被复现的问题才叫问题，复现不了的只能算事故。下一步把你的任务容错等级、适配层契约、回归样例三样先落下来，再打开对比页面看当时的数字。→
常见问题
没有算法背景，能做大模型应用开发吗？
能，但边界要清楚。大部分应用开发工作是把模型当接口用：拆任务、定格式、做校验、盯回归，这些是工程活不是算法活。真正需要算法背景的是微调、推理优化、量化调参这类事情，那部分要么找专业的人，要么先用现成方案顶上，别自己硬啃。
怎么判断一个问题该用大模型还是传统代码？
看规则能不能写全。规则清晰、边界固定的（比如字段格式转换、固定字段抽取）用传统代码更稳更便宜；规则说不清、输入千变万化、需要理解语义的，才交给大模型。混合方案通常最实用：模型负责理解和生成，代码负责校验和兜底。
模型换代了我该跟着换吗？
先问三个问题：现有模型有没有卡住你的业务、新模型在你的回归集上是不是真的更好、换过去的迁移成本有多大。三个都有答案再动。没有回归集就别换，因为换完你根本不知道是变好还是变坏。想跟进度可以看 /news/daily，但别被版本号牵着走。
