AI 工程的技术债——现在欠的以后怎么还

老张2026/4/30大约 9 分钟

AI 工程的技术债——现在欠的以后怎么还

适读人群：AI工程师、技术负责人 | 阅读时长：约13分钟 | 核心价值：识别AI应用特有的技术债类型，建立偿还优先级策略

我去年接手过一个维护了快两年的 RAG 项目，代码写得不算差，但打开之后我呆了差不多三分钟。

Prompt 字符串直接硬编码在业务逻辑里，散落在十几个文件中，没有版本，没有注释，不知道哪个是当前生效的。知识库的向量索引三个月没更新，但谁也不知道——没有任何监控告诉你索引是否新鲜。模型版本锁定在 gpt-3.5-turbo（没有日期后缀），调用的时候 OpenAI 已经默默切换了两次底层模型，但他们毫不知情。

评估呢？没有。你问他这个系统回答准不准，他说「我们测试过，感觉还行」。测试用例？没留下来。

这不是这个团队的问题，这是 AI 工程这个阶段普遍存在的现象。大家都在快速迭代，先把功能跑起来，技术债欠了一堆，然后某一天系统崩了或者效果突然变差，你不知道从哪里下手。

今天把 AI 应用里特有的技术债类型整理一下，以及怎么有优先级地还清这些债。

AI 技术债和普通技术债的区别

普通软件的技术债你大概都知道：耦合太紧、缺少测试、命名混乱、重复代码……这些问题修起来难受，但至少是确定性的——你知道坏在哪里，改了就好了。

AI 应用的技术债有一个普通软件没有的特性：不确定性会随着时间累积。

模型在悄悄变，Prompt 对新版本模型可能就不好使了。外部知识库在变，但你的索引可能没跟上。业务场景在扩展，但你的评估集还是六个月前那批样本，它给你一个「准确率 90%」的好看数字，但实际上你的系统在新场景下已经在乱答了。

这种累积的不确定性，才是 AI 技术债最危险的地方。

四种主要的 AI 技术债类型

类型一：Prompt 硬编码

这是最常见的。Prompt 写在代码里，版本控制靠注释（或者连注释都没有），改 Prompt 等于改代码。

为什么这是债？

因为 Prompt 其实是你系统行为的核心配置，它需要迭代、需要测试、需要回滚能力。如果 Prompt 和代码混在一起，任何 Prompt 调整都要走代码发布流程，改个措辞要 PR、Code Review、CI/CD，严重拖慢迭代速度。

更糟的是，当 Prompt 散落在代码各处，你很难对整体 Prompt 策略有全局视图，容易出现多个地方用了互相矛盾的指令，或者某个字段在不同地方的要求不一致。

类型二：模型版本锁定（或者反过来，没有锁定）

两种情况我都见过：

情况A：锁定了一个非常老的模型版本，不敢升级，因为没有评估体系，不知道升级了会不会变差。这类系统慢慢就变成了「技术遗留系统」，维护成本越来越高。

情况B：用了没有日期后缀的模型别名（比如 gpt-4o 而不是 gpt-4o-2024-11-20），以为这样可以自动享受模型升级，结果某次 OpenAI 推了一个新版本，行为有变化，Prompt 效果突然下降，排查了好几天才定位到原因。

正确的做法是：生产环境锁定具体版本，升级时走有评估数据支撑的迁移流程。

类型三：评估测试集不更新

这个是最隐性的技术债，危害最大。

你有一套评估集，跑下来准确率 88%，看着不错，心里踏实。但这套评估集是六个月前做的，你的业务场景已经扩展了很多，新的用户 Query 类型在评估集里没有覆盖。你的系统在新场景下答得一塌糊涂，但你的评估指标看不出来。

这就像你用上个月的财务报表判断这个月的公司经营状况——可能差了十万八千里你还以为一切正常。

类型四：可观测性缺失

AI 应用如果出了问题，你能多快定位到原因？

如果你的系统没有记录完整的输入输出、没有 Token 用量监控、没有延迟分布统计、没有用户反馈数据，那你的排查过程就是纯靠猜——效果变差了，是 Prompt 问题？模型问题？知识库问题？用户输入变了？你根本不知道从哪里下手。

可观测性缺失不是功能问题，但它让所有其他问题的排查难度翻倍。这是长期拖着不修最贵的一种债。

识别和量化技术债的方法

在还债之前，先要搞清楚自己欠了多少。

我会用一个简单的健康度检查清单来评估一个 AI 项目的技术债情况：

Prompt 管理健康度
  □ Prompt 是否有版本管理？
  □ Prompt 是否与业务逻辑代码分离？
  □ 能否在不改代码的情况下回滚 Prompt？
  □ 生产环境有多少个 Prompt？能否列出完整清单？

模型版本管理健康度
  □ 生产环境的模型是否锁定了具体版本号？
  □ 是否有记录每个版本的变更时间和原因？
  □ 模型升级是否有对应的评估报告？

评估体系健康度
  □ 是否有评估集？
  □ 评估集最近一次更新是什么时候？
  □ 评估集覆盖了业务的主要场景吗（近三个月有没有新场景没覆盖）？
  □ 是否有回归测试流程（改了 Prompt 之后会跑评估吗）？

可观测性健康度
  □ 是否记录了完整的输入（Prompt + 用户输入）？
  □ 是否记录了 Token 用量？
  □ 是否记录了延迟（E2E 和模型调用分开）？
  □ 是否有用户反馈收集机制？
  □ 是否有告警（比如延迟突然升高、错误率上升）？

这个清单不是用来打分的，是用来找盲区的。每个 □ 的「否」就是一笔技术债。

偿还优先级：怎么判断先还哪个

技术债不可能一次性全还清，需要排优先级。我用两个维度来判断：风险程度（不还会有多痛）和偿还成本（还这笔债需要多少时间）。

风险 / 成本矩阵

               成本低          成本高
风险高    [立即处理]        [分期处理]
风险低    [有空就做]        [暂时搁置]

可观测性缺失 → 优先级最高

这个通常成本不算太高（搭日志系统、加监控），但不做的风险极高——出了问题你什么都查不了。而且可观测性是其他所有改进的基础，你先把日志打好，才能有数据来判断其他问题有多严重。

搭一个基本的 AI 日志系统，两个工程师专注一周可以做到初步版本。

评估集过时 → 优先级第二

这个的风险是隐性的，但是严重的——你的「准确率指标」可能是个假象。定期更新评估集，把近三个月的真实用户 Query 抽样加进来，这个工作持续做，每次花不了太多时间，但不做累积下来的风险很大。

Prompt 硬编码 → 优先级第三

重要，但可以分步走。不需要一下子把所有 Prompt 全部抽离，可以先在新功能上用正确的方式管理 Prompt，旧的逐渐重构。关键是建立规范，后面的人不要再欠这个债。

模型版本锁定 → 根据情况

如果你用的是有日期后缀的版本，这个债暂时不急。如果你在用没有日期的别名，建议尽快锁定——代价很低，风险能规避。

实操：怎么还 Prompt 硬编码这笔债

说具体一点，Prompt 硬编码怎么重构。

第一步：把所有 Prompt 找出来，集中在一个地方。

# 不好的：Prompt 散落在各处
def analyze_sentiment(text):
    prompt = f"分析以下文本的情感倾向，返回 JSON...\n{text}"
    return call_llm(prompt)

def extract_keywords(text):
    prompt = f"从以下文本中提取关键词...\n{text}"
    return call_llm(prompt)

第二步：建一个 Prompt 配置层，和业务逻辑分开。

# prompts/sentiment.py
SENTIMENT_ANALYSIS_V2 = """
你是一个文本分析助手。分析以下文本的情感倾向。

输出要求：
- 返回严格的 JSON 格式
- 字段：sentiment (positive/negative/neutral), confidence (0-1), reason (一句话解释)

文本：{text}
"""

# prompts/__init__.py
from .sentiment import SENTIMENT_ANALYSIS_V2
from .extraction import KEYWORD_EXTRACTION_V1
# ... 集中管理所有 Prompt

第三步：加版本号，用明确的命名。

# 版本命名规则：功能名_V版本号
# 升级时创建新版本，旧版本保留（方便回滚）
SENTIMENT_ANALYSIS_V1 = "..."  # 2024-09 版本，已废弃
SENTIMENT_ANALYSIS_V2 = "..."  # 2025-01 版本，当前使用

第四步：把 Prompt 版本记录到日志里。

def analyze_sentiment(text, prompt_version="SENTIMENT_ANALYSIS_V2"):
    prompt_template = getattr(prompts, prompt_version)
    prompt = prompt_template.format(text=text)
    result = call_llm(prompt)
    
    # 日志里记录用了哪个 Prompt 版本
    log_ai_call(
        prompt_version=prompt_version,
        input=text,
        output=result
    )
    return result

这四步不需要一次性完成，可以在正常迭代里慢慢做，每改一个功能就顺手把对应的 Prompt 重构掉。

偿还技术债的节奏

还技术债最忌讳的是「专门立一个项目来还债」。这种项目大概率会因为优先级被业务功能挤掉，然后烂尾。

我自己的做法是把技术债偿还融入日常迭代：

每个 Sprint 预留 15%-20% 的时间专门做技术债
改任何一个模块之前，顺手把这个模块里已知的技术债还掉
做 Code Review 时，把发现的新技术债记录到 Backlog，不要放过

技术债不会自己消失，但也不需要一次性还清。重要的是不要让它以比你还的速度更快的速度增长。

AI 工程还是个相对新的领域，很多最佳实践还没形成。你现在看到的那些「潦草实现」，两年后回头看，就是当年欠下的债。早点有这个意识，早点建立正确的工程规范，比等到债台高筑了再还要容易很多。