Image by SORA
“我该用哪一个模型？”——初级工程师会这样问。
“哪里会先坏？”——资深工程师会这样问。
大多数 AI 程序在演示中光鲜亮丽，在生产中却悄无声息地失效，原因就在这里。
AI 并没有让软件工程变简单。它只是揭示了谁本来就做得好。
模型是最容易的部分——如果你见过一个 AI 功能在预发布环境里一切顺利，却在真实流量、脏数据和不可预测的用户面前土崩瓦解，你就懂了。系统才是难点。
这篇文章不讲提示词、框架，也不追最新的模型发布。它讲的是资深工程师如何真正打造能经受真实世界交互的 AI 系统。
AI 系统的失败并不发生在你以为的地方
多数 AI 失败不是模型失败。
它们是：
- 数据失败
- 假设失败
- 集成失败
- 监控失败
简单说，模型只是症状显现的地方。资深工程师很早就内化了这一点。他们不是从“让我们加个 AI 吧”开始，而是从一个极其无聊的问题开始：
即便模型完美，问题还剩下什么？
因为在生产中，模型从不完美。
第一步：资深工程师从约束开始，而不是从能力开始
初级心态：
“这个模型能做什么？”
资深心态：
“这个系统被允许在哪里失败？”
在写下第一行代码之前，资深工程师会定义约束：
- 延迟预算
- 成本上限
- 准确率阈值
- 故障容忍度
- 合规或隐私边界
这会塑造后续的一切。
例如：
- 如果延迟必须小于 300 毫秒，一半流行的模型立刻出局。
- 如果不能容忍幻觉，生成式输出必须被门控、验证或约束。
- 如果数据每天变化，静态微调就是陷阱。
约束即架构。
第二步：把数据当产品，而不是输入
资深工程师常常是用很痛的方式发现这个安静的事实：
你的数据管道决定了 AI 系统的稳定性。
资深工程师不“拉数据”。他们“拥有”数据契约。
他们会明确：
- 数据来自哪里
- 多久变化一次
- 出问题谁负责
- 什么叫做“坏数据”
并把这些变成可自动化的约束执行。
示例：把数据验证当一等公民
“`python
from pydantic import BaseModel, ValidationError
class UserEvent(BaseModel):
user_id: str
action: str
timestamp: int
def validate_event(event_dict):
try:
return UserEvent(**event_dict)
except ValidationError as e:
log_error(e)
raise
“`
这不是“额外工作”。这是防御性系统设计。
资深工程师默认上游数据终有一天会“说谎”。
第三步：模型是可替换组件，而不是神圣遗物
模型会吸引年轻工程师的目光。资深工程师会把它们替换掉。
在真实系统里你需要能：
- 切换模型
- 比较输出
- 即时回滚
这需要抽象。
资深模式：模型适配器
“`python
class LLMClient:
def generate(self, prompt: str) -> str:
raise NotImplementedError
class OpenAIClient(LLMClient):
def generate(self, prompt):
return openai_response(prompt)
class LocalModelClient(LLMClient):
def generate(self, prompt):
return local_model(prompt)
“`
为什么这很重要：
- 供应商宕机时可切换提供商
- 可进行 A/B 测试
- 可优雅地降级
模型不是系统。它是一个依赖项。
第四步：为部分失败而设计
AI 系统不会“干净”地失败，它们会“退化”。
资深工程师假定：
- API 会超时
- 模型会产生幻觉
- 嵌入向量会漂移
- 外部服务会限流
所以他们会构建后备路径。
示例：分层的 AI 响应
python
def get_answer(query):
try:
return high_quality_model(query)
except TimeoutError:
return fast_model(query)
except Exception:
return cached_answer(query)
这不是悲观。这是现实主义。
专业提示：如果你的 AI 系统没有后备方案，你就没有系统——你只是在赌。
第五步：可观测性胜过智能
多数 AI 团队监控的是准确率。资深工程师监控的是行为。
他们会跟踪：
- 提示词变更
- 输入数据分布
- 输出熵
- 延迟百分位数
- 单次请求成本
因为生产问题很少自报家门。
Observability 示例
“`python
def monitored_generate(prompt):
start = time.time()
response = model.generate(prompt)
duration = time.time() – start
log_metrics({
"latency": duration,
"prompt_length": len(prompt),
"response_length": len(response)
})
return response
“`
然而，仅有日志和仪表盘是远远不够的。与事后复盘相比，资深工程师更注重建立早期预警信号，以便在问题影响用户之前主动介入。
第六步：Automation 是唯一可扩展的方式
依赖手工操作的 AI 系统难以长久。资深工程师会将以下关键环节自动化：
* 评估
* 回归测试
* 提示变更
* 数据漂移检测
* 发布与回滚
自动化评估示例
python
def evaluate_model(model, test_cases):
scores = []
for case in test_cases:
output = model.generate(case["input"])
scores.append(compare(output, case["expected"]))
return sum(scores) / len(scores)
自动化评估应在以下场景自动触发：
* 部署前
* 数据变更后
* 模型更新后
如果一个 AI 系统需要依赖人工“抽检”来保证质量，那么它本质上已经存在问题。
第七步：默认将人作为系统的一部分
AI 系统不会取代人，而是会改变工作流。资深工程师在设计时会主动纳入：
* 人工审核闭环
* 人工覆写机制
* 审计追踪
这一点在高风险应用领域尤为重要。
人在回路模式示例
python
if confidence < THRESHOLD:
route_to_human_review(result)
else:
auto_approve(result)
这并非妥协，而是构建经得起审查的生产级系统的必要设计。
第八步：Prompt Engineering 只是最后 10%
Prompt Engineering 并非资深工程师的主要工作。他们将更多精力投入在：
* 输入标准化
* 输出验证
* 状态管理
* 缓存策略
* 成本控制
一个绝佳的提示词若置于糟糕的系统架构之上，依然会失败。正如一句经验之谈：“如果提示词承担了过多工作，那说明你的系统架构做得太少。”
第九步：为变化而设计，而非为完美而设计
初级工程师的目标是构建“最佳”的 AI 系统，而资深工程师的目标是构建“最能适应变化”的系统。因为：
* 模型会迭代进步
* 成本会动态变化
* 法规会持续调整
* 用例会不断演化
最终胜出的系统往往是那些看似“无聊”的：模块化、可观测、可替换——这与其他优秀软件系统的特质并无二致。
现实世界中的样貌
一个由资深工程师构建的 AI 系统通常遵循以下路径：
* 从简单方案开始
* 尽早投入运行
* 建立强力度量体系
* 进行渐进式改进
它不追逐热点，在故障时无需慌乱，不依赖个人英雄主义，其状态通过数据清晰呈现。
最后的思考
AI 并未创造出一类全新的工程问题，而是放大了我们本就存在的问题。资深工程师在 AI 项目上成功的原因，与其在其他领域成功的原因相同：他们深刻理解的是系统，而不仅仅是工具。
如果你的 AI 项目脆弱、不可解释、难以运维，那么更换一个更好的模型并非解决之道。此时，你更需要的是扎实的工程实践。
关注“鲸栖”小程序，掌握最新AI资讯
本文来自网络搜集，不代表鲸林向海立场，如有侵权，联系删除。转载请注明出处：http://www.itsolotime.com/archives/18784