把立项换到交付时踩过的坑

“做AI项目最大的幻觉，是以为数据充足、模型足够大、算力足够多，问题就自动解决了。

"

过去两年带过几个AI项目，有的跑到了生产环境，有的在demo阶段就胎死腹中。

项目不是从需求分析开始的，是从数据评估开始的

第一个坑就在立项阶段。传统项目可以先把需求想清楚再考虑实现，但AI项目的可行性直接挂载在数据上。

去年接过一个客服问答项目，业务方给的原始需求是"让机器人能回答90%的用户问题”。表面上看需求很清楚，但真正能评估可行性的东西没出现：历史对话数据有多少、数据质量如何、覆盖哪些业务场景、怎么标注。

跑到数据仓库一看：最近一年的完整对话记录只有3万条，其中超过60%是简单的"查询订单状态"和"退换货流程"，剩下的40%分散在100多个不同的场景里，每个场景只有几十条数据。模型能学会什么？学会说"好的"、“稍等”、“已经处理了”。

这就是AI项目立项时的第一个现实检查：数据规模 × 数据质量 × 场景覆盖度 = 可实现的复杂度上限。这三者任何一项不合格，要么降低项目目标，要么先做数据治理。

那次项目的调整策略是：缩小到三个核心场景（查单、退货、物流），人工整理了5000条高质量对话，在这个范围内目标才变得合理。如果立项时就顺着90%的需求往下走，后面三个月基本上就是在给一个不可能的目标加班。

技术规划不是选最先进的，是选最能落地的

第二个坑出现在技术选型。团队里有人提议上最新的LLM模型、做prompt工程、整一套完整的RAG流水线，看起来很先进，但实际落地时发现几个问题：模型推理延迟太高、RAG检索不准确、prompt效果波动大、维护成本远超预期。

后来退回更简单的方案：用中小型模型、少样本学习、针对每个场景单独做微调。效果更稳定、推理成本更低、出现问题也更容易定位。

# 实际使用的配置（简化版）
MODEL_CONFIG = {
    "base_model": "llama-3.2-8b-instruct",  # 不用最大的，够用就行
    "temperature": 0.3,  # 控制输出的稳定性
    "max_tokens": 512,   # 限制回答长度，避免瞎编
    "top_p": 0.9,
}

技术选型时实际要权衡的是：

• 模型效果 vs 推理成本
• 方案先进性 vs 维护复杂度
• 实验环境效果 vs 生产环境表现
• 单次性能峰值 vs 长期稳定性

去年另一个项目因为在选型时过于激进，用了当时还很不稳定的某个框架，生产部署后三天两头遇到版本兼容问题，最后不得不花两周时间重构到更稳定的方案上。现在回想，那个框架的README都没写清楚生产部署的注意事项，就敢直接用，完全是自找麻烦。

数据准备不是一次性的，是持续对抗的过程

第三个坑在数据环节。很多人以为AI项目做数据就是"收集、清洗、标注"三步走，但实际操作中更像是一个持续对抗的过程。

去年做电商评论情感分析时，遇到的第一个问题是标注一致性。不同标注员对同一条评论的情感判断经常不一样，“服务态度还行，但物流慢"到底算正面还是负面？这种模糊边界在真实数据里占了30%以上。

解决方案不是找更多标注员，而是明确标注规则并持续对齐：

# 标注规则示例（实际项目中的片段）
ANNOTATION_RULES = {
    "positive": "用户明确表达了满意、推荐、认可的意图",
    "negative": "用户明确表达了不满、失望、投诉的意图",
    "neutral": "纯事实描述或情感倾向不明确",
    "mixed": "同时包含正面和负面情感，且难以判断主次"
}

数据清洗环节也有坑。有些评论里包含大量emoji、特殊符号、错别字，还有一些明显是机器生成的重复内容。如果不动脑子直接全删，会损失很多有价值的信息；如果不处理，又会影响模型效果。

最后采取的做法是：

• emoji转为文字表达
• 错别字在不影响理解的情况下保留
• 机器生成内容通过重复度和语言特征识别并过滤
• 特殊符号视情况保留或替换

这个环节投入的时间比预期多了一倍，但效果直接体现在模型准确率上：从73%提升到81%。

风险控制不是写在文档里的，是部署前反复验证的

第四个坑在风险控制。项目文档里写了一堆风险应对措施，但真正出问题时才发现很多东西根本没验证过。

去年部署到生产环境后遇到的第一个问题是数据漂移。模型在训练集上表现很好，但面对新的用户评论时准确率突然下降。原因是业务调整后评论的语言风格变了，出现了很多训练集中没有的词汇和表达方式。

后来加了数据漂移监控：

# 简化的监控逻辑
def monitor_drift(new_data, reference_data, threshold=0.1):
    """监控数据漂移，超过阈值触发警报"""
    feature_drift = calculate_feature_drift(new_data, reference_data)
    label_drift = calculate_label_drift(new_data, reference_data)

    if feature_drift > threshold or label_drift > threshold:
        trigger_alert("Data drift detected, consider retraining")

    return feature_drift, label_drift

第二个风险点是模型幻觉。在开放问答场景中，模型会一本正经地回答错误信息。这个问题在测试环境里没完全暴露，因为测试数据大多是已知问题，生产环境中用户的真实问题各种奇怪都有。

最后的应对方案包括：

• 限制模型只回答训练覆盖范围内的问题
• 对不明确的问题返回"无法确定，建议人工处理”
• 关键环节保留人工审核
• 记录所有模型输出用于后续分析

这些措施部署后，幻觉导致的错误回答下降了90%以上。

交付不是模型上线了就完了，是建立可维护的闭环

最后一个大坑在交付环节。很多人觉得模型部署上线就算交付完成了，但实际生产环境中的AI项目需要持续的监控和调优。

上个月接手一个老项目，模型是两年前部署的，上线后基本没维护过。现在看数据发现：准确率从当初的85%降到了68%，原因包括业务规则变化、数据分布漂移、模型本身在处理新的边界情况时表现不佳。

交付时应该建立的闭环包括：

实际操作中，交付后还需要：

• 持续监控模型效果和成本
• 定期收集业务反馈
• 分析失败案例
• 计划性模型重训
• 文档化决策过程和维护经验

如果项目刚交付就没人管了，几个月后多半会出问题。AI项目不是一次性交付的产品，是需要持续维护的系统。

不是总结的总结

做AI项目几年下来，最大的感受是：它不是魔法，是工程。需要把看起来很玄的问题拆解成可操作的步骤，把不确定的事情用实验来验证，把理想化的期望调整到现实的边界上。

立项时看数据、选型时重落地、数据准备要持续、风险控制要验证、交付要建立闭环——这些听起来都不怎么"AI"，但正是这些很"工程"的东西，决定了AI项目最后是成功还是失败。

经验可以参考，但每个项目都有它自己的坑。这篇文章里的做法，到你自己的项目里可能还需要再调整。实际做的时候，多听一线的声音，多看真实的数据，少相信那些听起来很完美的方案。

AI项目的坑很多，但每个坑爬过去，都会学到一些东西。这些积累下来的经验，才是项目管理里最宝贵的资产。

版权声明: 本文首发于 指尖魔法屋-把立项换到交付时踩过的坑（https://blog.thinkmoon.cn/post/193-ai-project-management-from-start-to-delivery/） 转载或引用必须申明原指尖魔法屋来源及源地址！