在AI项目中，客户与利益相关者最不希望看到的就是意外。
他们真正期待的是清晰透明、持续一致的沟通。他们渴望成果，但也希望开发人员或产品经理能够保持务实，并与项目目标始终保持一致。同样重要的是，他们希望对整个项目流程拥有充分的可见性。
本文将分享一系列实用原则和技巧，旨在帮助AI项目顺利推进。这些洞察来源于超过15年的AI项目管理和部署经验，并作为此前博文《AI项目期望管理技巧》的后续补充。
在处理AI项目时，不确定性并非仅仅是附带影响，它可能决定整个项目的成败。
在博客的各个章节中，将提供读者可以立即付诸实践的建议。
现在，深入探讨！
ABU (持续更新，保持透明)
在销售领域，有一条著名的黄金法则：ABC——“Always Be Closing”（永远促成交易）。其核心思想是，每一次互动都应推动客户更接近成交。在AI项目管理中，同样有一条至关重要的准则：ABU (Always Be Updating)——持续更新。
这条规则的含义一目了然：绝不能让利益相关者置身于信息黑洞。即便项目进展甚微或停滞不前，也必须迅速沟通。沉默只会滋生不确定性，而不确定性则是信任的致命杀手。
实施ABU的一个直接有效的方法是每周向所有利益相关者发送一份简短的邮件。邮件内容应保持一致性、简洁性，并聚焦于以下四个关键点：
- 本周在性能方面取得的突破或达成的关键里程碑；
- 交付物面临的问题或上周计划中影响利益相关者预期的变更；
- 团队或资源调配的最新情况；
- 商定成功指标的当前进展；
这种定期的沟通节奏能够确保所有人保持步调一致，同时又不会被过多的信息所淹没。核心洞察在于，人们并非真的厌恶坏消息，他们只是讨厌突如其来的“坏惊喜”。如果项目团队能够坚持ABU原则，并每周管理期望，便能建立起信誉，并在不可避免的挑战出现时，为项目提供有效的保护。
让产品尽早面向用户
在AI项目中，项目团队很容易陷入一个误区：为自己构建产品，而非为实际使用该产品或解决方案的最终用户服务。
经常出现的情况是，团队对自身关注的功能充满热情，但这些功能对终端用户而言却意义不大。
因此，不要做任何假设。务必尽早且频繁地将产品呈现给用户。真实的反馈是任何其他信息都无法替代的。
实现这一目标的一个实用方法是通过轻量级原型或小范围试点。即使产品远未完成，将其展示给用户也有助于验证假设并确定功能优先级。在项目启动之初，就应尽快确定一个原型展示日期。
避免陷入技术陷阱
工程师们热爱技术——这是他们职业热情的重要组成部分。然而，在AI项目中，技术仅仅是实现目标的赋能工具，而非最终目的。仅仅因为某项技术在理论上可行（或者在演示中看起来令人印象深刻），并不意味着它能够解决客户或利益相关者的实际问题。
因此，指导原则非常简单，但执行起来却颇具挑战性：不要以技术为起点，而要以需求为导向。每一个功能或每一行代码都应能追溯到一个清晰的用户痛点。
应用此原则的一个实用方法是在提出解决方案之前，先验证问题的真实性。花时间与客户交流，梳理他们的痛点，并自问：“即使这项技术完美运行，它对他们来说真的重要吗？”
炫酷的功能并不能拯救一个无法解决实际问题的产品。但当技术扎根于真实需求时，用户采纳便会水到渠成。
工程师们常常专注于优化技术或开发引人注目的功能。然而，最优秀的工程师（即“10倍工程师”）能够将技术实力与理解利益相关者需求的罕见同理心相结合。
业务指标优先于技术指标
项目团队很容易沉溺于技术指标之中——例如准确率、F1分数、ROC-AUC、精确率、召回率等。然而，客户和利益相关者通常并不关心模型是否提高了0.5%的准确率；他们更关心的是模型能否有效降低客户流失、增加收入，或节省时间和成本。更糟糕的是，客户和利益相关者往往误以为技术指标才是最重要的，而从商业角度来看，情况却并非如此。项目团队有责任引导他们转变观念。
如果客户流失预测模型的准确率达到92%，但营销团队无法根据其输出设计出有效的营销活动，那么这个指标便毫无意义。相反，如果一个“准确率较低”的模型，因为其可解释性而帮助客户流失率降低了10%，那便是一个实实在在的成功。
应用此原则的一个实用方法是在项目启动时就明确定义业务指标——可以提出以下问题：
- 项目的财务或运营目标是什么？（例如：将呼叫中心的平均处理时间缩短20%）
- 哪些技术指标与这一业务成果相关性最强？
- 如何向非技术背景的利益相关者有效传达结果？
有时，正确的衡量指标根本不是准确率。例如，在欺诈检测中，一个能够捕获70%欺诈案例且误报率极低的模型，可能比一个准确率高达90%但却拦截了数千笔合法交易的模型更有价值。
所有权与交接
一旦解决方案上线，谁将拥有它的所有权？如果项目成功，客户能否始终可靠地访问它？当项目团队不再参与项目时，后续如何处理？
这些问题经常被忽视或推迟，但它们却决定着项目成果的长期影响力。因此，项目团队需要从第一天起就规划好交接工作。这意味着要系统地记录流程、进行知识转移，并确保客户团队能够在没有持续参与的情况下，自行维护和运营模型。
交付一个机器学习模型仅仅是完成了工作的一半——部署后的阶段往往至关重要，却经常在业务与技术团队的沟通中被忽视。
成本与预算透明度
解决方案的运行成本将是多少？是否采用了云计算基础设施、大型语言模型（LLMs）或其他可能带来可变开销的技术，而这些开销是客户必须了解的？
从项目伊始，就需要向利益相关者全面展示成本驱动因素。这意味着要细致地列出基础设施成本、许可费用，尤其是对于生成式AI（GenAI）项目，还需要明确令牌消耗等使用费用。
管理这一方面的一个实用方法是设置清晰的成本跟踪仪表板或警报系统，并定期与客户进行审查。对于大型语言模型，应在不同场景下（例如平均查询量与高负荷使用）估算预期的令牌使用量，以避免日后出现意外。
客户可以接受成本，但绝不能接受隐藏或具有多重扩展性的成本。预算的透明化使得客户能够对解决方案的扩展做出更切合实际的规划。
规模化
谈及规模化……
规模化完全是另一回事。这是AI解决方案能够实现最大业务价值的阶段，但也是大多数项目失败的症结所在。在笔记本中构建模型是一回事，而将其部署以处理真实世界的流量、数据和用户需求则是另一项巨大挑战。
因此，务必清晰阐明将如何实现解决方案的规模化。这正是数据工程和MLOps发挥作用的领域。需要探讨如何确保整个管道（数据摄取、模型训练、部署、监控）能够随着需求增长而扩展，同时保持可靠性和成本效益。
在沟通规模化时，需要考虑的关键领域包括：
- 软件工程实践：版本控制、CI/CD管道、容器化和自动化测试，以确保解决方案在演进过程中不会崩溃。
- MLOps能力：自动化再训练、数据漂移和概念漂移的监控，以及警报系统，以确保模型随着时间推移保持准确性。
- 基础设施选择：云端与本地部署、水平扩展、成本控制，以及是否需要专用硬件。
一个在隔离环境中表现良好的AI解决方案或项目是远远不够的。真正的价值体现在当解决方案能够扩展服务数千用户、适应新数据，并在初始部署后长期持续产生业务影响。
本文总结的实用建议包括：
- 每周向所有利益相关者发送一份简短的邮件更新，内容涵盖项目突破、存在问题、团队动态以及指标进展。
- 承诺尽早推出原型或试点，以便与终端用户共同验证假设。
- 优先验证问题——不要从技术入手，而应从用户需求出发。用户访谈是实现这一目标的绝佳方式（如果可能，离开办公桌，花一天时间与用户一同体验他们的工作流程）。
- 预先定义业务指标，并将技术进展与这些指标紧密关联。
- 从项目伊始就规划好交接：做好文档记录、培训客户团队，并确保所有权清晰明确。
- 建立仪表板或警报系统以跟踪成本（特别是针对云计算和基于令牌的生成式AI解决方案）。
- 在构建时充分考虑可扩展性：包括CI/CD、漂移监控、模块化管道以及可随需求增长的基础设施。
