七个核心概念：决定/证据/边界/负责人/写回/回滚/未知项

💡 为什么需要这七个概念

AI项目最大的挑战不是技术，而是"不确定性"。需求不确定、模型能力不确定、效果不确定、用户接受度不确定。传统项目管理的工具（甘特图、WBS、里程碑）在AI项目里不好用，因为你一开始根本不知道要做什么、怎么做、做出来效果怎么样。

七个核心概念是FDE在大量AI项目实践中总结出来的"不确定性管理工具"。每个概念对应一种不确定性的管理方法：

决定——管理"做什么"的不确定性；证据——管理"效果怎么样"的不确定性；边界——管理"能做到什么程度"的不确定性；负责人——管理"谁来做"的不确定性；写回——管理"知识沉淀"的不确定性；回滚——管理"出问题怎么办"的不确定性；未知项——管理"还有什么不知道"的不确定性。

这七个概念不是理论，而是实战工具。在项目的每个阶段，你都可以用这七个概念来检查：这个事情决定了吗？有证据吗？边界清楚吗？负责人是谁？写回了吗？能回滚吗？还有哪些未知项？

✅ 概念一：决定（Decision）

"决定"是指：项目中的每个关键选择，都要有明确的决策记录——谁决定的、什么时候决定的、基于什么信息决定的、决定了什么。

为什么"决定"很重要？因为AI项目变化快，今天决定的方案，明天可能因为模型效果不好就推翻了。如果没有决策记录，过两周大家就会忘了"当时为什么这么决定"，然后开始扯皮："我当时就说不行""你没说过啊""那时候信息不一样"。

怎么记录决定？不需要复杂的工具，一个简单的决策日志就行：日期、决策内容、决策人、决策依据、待验证假设。比如："2024-03-15，决定先用GPT-4做POC，因为客户场景复杂，开源模型效果可能不够；待验证：GPT-4在客户场景的准确率是否达到85%。"

记住：决定不是"拍板就完了"，而是"拍板+记录+待验证"。每个决定都有假设，假设需要验证，验证结果可能推翻决定。决定是动态的，不是静态的。

• 核心：每个关键选择都要有明确的决策记录
• 记录要素：日期、内容、决策人、依据、待验证假设
• 目的：避免扯皮、追溯决策逻辑、支持后续调整
• 误区：决定不是拍板就完了，每个决定都有假设需要验证

📊 概念二：证据（Evidence）

"证据"是指：项目中的每个结论，都要有数据或事实支撑，不能凭感觉、凭经验、凭"我觉得"。

AI项目最容易犯的错误就是"凭感觉做决策"。"我觉得这个模型效果不错""我觉得客户会喜欢""我觉得这个功能有用"——这些都是没有证据的判断。没有证据的判断，在AI项目里就是定时炸弹，迟早会炸。

怎么收集证据？三个层次：第一层是"数据证据"——用数据说话。比如模型准确率，跑100条测试数据，准确率85%，这就是证据。第二层是"用户证据"——让真实用户试用，收集反馈。比如客户客服团队试用一周，满意度4.2/5，这就是证据。第三层是"业务证据"——看业务指标有没有变化。比如上线后客服响应时间从32小时降到5分钟，这就是证据。

证据的核心原则：可量化、可复现、可对比。可量化——用数字说话，不用"不错""挺好"；可复现——别人用同样的方法能得到同样的结果；可对比——有基线（before）和结果（after）的对比。

在项目中，你要养成一个习惯：每次做结论前，先问自己"证据是什么？"如果没有证据，就先去收集证据，不要急着下结论。

🚧 概念三：边界（Boundary）

"边界"是指：AI系统能做什么、不能做什么、做到什么程度，要有明确的界定，并且让所有干系人都清楚。

AI项目最大的风险之一就是"期望失控"——客户以为AI什么都能做，结果上线后发现AI只能做一部分，客户就觉得"你骗了我"。边界管理，就是在项目一开始就把"AI能做什么、不能做什么"说清楚，管理客户的期望。

怎么定义边界？三个维度：能力边界——AI在什么场景下效果好，什么场景下效果差；责任边界——AI做的决定出了问题，谁负责；流程边界——AI在整个工作流程中扮演什么角色，哪些步骤AI做，哪些步骤人做。

举个例子：AI客服项目的边界。能力边界——AI能处理70%的常见问题（查物流、问营业时间、退换货政策），不能处理30%的复杂问题（定制化需求、投诉、退款）；责任边界——AI给出的回答，人工需要复核，出了问题由人工负责；流程边界——AI先接，回答不了的转人工，人工处理完把答案写回知识库。

边界不是"限制AI的能力"，而是"保护项目不翻车"。边界清楚了，客户的期望就管理住了，项目的风险就可控了。边界要在项目一开始就说清楚，写进SOW，并且在项目过程中反复确认。

👤 概念四：负责人（Owner）

"负责人"是指：项目中的每个任务、每个模块、每个风险，都要有明确的负责人——谁对这个事情的结果负责。

AI项目常见的问题是"人人都管，人人都不管"。比如数据质量问题，客户说"你们技术团队负责"，技术说"数据是客户提供的，客户负责"，最后数据质量没人管，模型效果差，项目翻车。

负责人的核心原则：每个事情有且只有一个负责人。可以有多个参与人，但只能有一个负责人。负责人对结果负责，参与人提供支持。

怎么明确负责人？用RACI矩阵：R（Responsible，执行者）——谁来做；A（Accountable，负责人）——谁对结果负责；C（Consulted，咨询者）——需要听取谁的意见；I（Informed，知情者）——需要通知谁。每个任务都要明确R和A，A只能有一个。

在AI项目中，特别要注意几个容易"没人管"的事情：数据质量（谁负责数据清洗和标注？）、知识库维护（谁负责更新知识库内容？）、模型调优（谁负责监控模型效果并调优？）、用户培训（谁负责培训客户团队使用？）、上线后运营（谁负责上线后的日常运维？）。这些事情如果没有明确负责人，最后一定会出问题。

📝 概念五：写回（Write-back）

"写回"是指：项目过程中产生的知识、经验、数据、规则，要及时写回到知识库、系统、文档中，让后续的人能复用。

AI项目的价值不仅仅是交付一个系统，更是沉淀一套可复用的知识。比如：客户访谈中发现的行业痛点、方案设计中总结的最佳实践、模型调优中积累的参数经验、上线后收集的bad case——这些都是宝贵的知识，如果不写回，项目结束就丢了，下一个项目还要从头再来。

写回的三个层次：第一层是"数据写回"——把新的数据、新的案例写回训练集或知识库。比如AI客服回答不了的问题，人工处理后把答案写回知识库，下次AI就能回答了。第二层是"规则写回"——把新的业务规则、新的判断逻辑写回系统。比如发现某类问题需要特殊处理，就把这个规则写回系统的规则引擎。第三层是"经验写回"——把项目中的经验教训写回文档和案例库。比如这个项目踩了什么坑、怎么解决的，写进案例库，下一个项目就能避免。

写回的核心原则：及时、结构化、可复用。及时——不要等项目结束才写，当天的事情当天写；结构化——按照统一的模板写，不要写成流水账；可复用——写的内容要让别人能看懂、能直接用。

写回是AI项目"越用越好"的关键。没有写回机制的AI系统，上线后效果会越来越差（因为数据过时、规则过时）；有写回机制的AI系统，上线后效果会越来越好（因为知识在持续积累）。

↩️ 概念六：回滚（Rollback）

"回滚"是指：当AI系统出问题时，能够快速、安全地切回到人工或旧系统，保证业务不中断。

AI系统不是100%可靠的，模型会出错、数据会异常、系统会故障。如果没有回滚机制，一旦AI出问题，业务就中断了，客户就炸了。回滚机制是AI项目的"安全网"，平时不用，但必须有。

回滚的三个层次：第一层是"功能级回滚"——某个AI功能出问题，单独关掉这个功能，其他功能正常运行。比如AI客服的自动回复出问题，关掉自动回复，转人工，其他功能（知识库查询、工单创建）正常。第二层是"系统级回滚"——整个AI系统出问题，全部切回人工或旧系统。比如模型服务挂了，所有请求转人工，保证业务不中断。第三层是"数据级回滚"——数据出问题（比如知识库更新错了），能快速恢复到上一个版本。

怎么实现回滚？技术上：配置开关（feature flag）——每个AI功能都有开关，出问题一键关掉；灰度发布——新功能先给10%用户用，没问题再逐步放开；版本管理——知识库、模型、规则都有版本管理，出问题一键回退到上一个版本。流程上：应急预案——出问题了谁来处理、怎么处理、多久处理完，要有明确的预案；演练——定期做回滚演练，确保真出问题时能快速响应。

回滚的核心原则：可快速（出问题5分钟内能切回）、可安全（切回后业务正常运行，不丢数据）、可透明（切回后用户感知不到，或者有明确的提示）。

记住：回滚不是"失败"，而是"负责任"。有回滚机制的项目，客户才敢放心用；没有回滚机制的项目，客户用得提心吊胆，出一次问题就不敢用了。

❓ 概念七：未知项（Unknown）

"未知项"是指：项目中还有哪些事情是我们不知道的、不确定的、需要验证的。把未知项显性化，是管理不确定性的关键。

AI项目最大的风险不是"已知的困难"，而是"未知的未知"——你不知道自己不知道什么。比如：你不知道客户的数据质量这么差，你不知道这个场景模型效果这么差，你不知道客户内部有这么多政治斗争。这些"未知的未知"，才是项目翻车的真正原因。

怎么管理未知项？两个步骤：第一步，把未知项显性化——在项目开始时，列出所有你不确定的事情，做成"未知项清单"。比如：模型在客户场景的准确率未知、客户数据质量未知、客户团队接受度未知、预算是否够未知。第二步，逐个验证未知项——把未知项按优先级排序，高优先级的先验证，用POC、调研、访谈等方式把"未知"变成"已知"。

未知项清单的要素：未知项描述、影响程度（高/中/低）、验证方法、验证时间、负责人、当前状态（未验证/验证中/已验证）。比如："模型准确率未知，影响高，用100条标注数据做POC验证，第2周完成，张三负责，当前未验证。"

未知项管理的核心原则：显性化（把不知道的事情列出来，不要藏在心里）、优先级（先验证影响大的未知项）、动态更新（每周更新未知项清单，验证完的划掉，新发现的加上）。

一个好的FDE，不是"什么都知道"，而是"知道自己不知道什么，并且有计划地去验证"。承认未知，不是无能，而是专业。