第 9 章　从第一次会面到可执行方案

9.1 先判断是不是一个项目

不是每条线索都值得进入技术方案。有些客户只有模糊兴趣，没有具体问题；有些问题真实存在，却没有负责人、数据或预算；还有些项目从一开始就要求在不可能的时间内交付。

FDE 在第一次会面前后要完成资格判断：问题是否正在产生代价，客户是否愿意开放真实流程，能否找到使用者和业务负责人，关键数据是否有取得可能，几周内能否验证一项结果。

如果这些条件完全不存在，立即做 POC 往往只是用技术热情替代商业判断。

第一次会议不需要解决全部问题，但要形成一张足以决定下一步的地图。至少应弄清：谁提出需求，为什么是现在；谁每天遇到问题；当前流程如何运行；哪里最慢、最贵或最容易出错；使用哪些系统；已经尝试过什么；需要哪些数据；哪些错误不能接受；谁能提供资源；谁决定预算；谁负责验收；希望何时看到什么变化。

这些问题不必机械询问。好的交流像共同还原现场，而不是审问客户。遇到“效率很低”“数据很多”之类描述，要继续追问数量、样本和最近发生的实例。

客户通常按照组织和感受讲问题，FDE 需要把叙述翻译成相互连接的部分。

流程说明任务怎样流动，等待和返工在哪里。角色说明谁使用、谁负责、谁提供信息以及谁可能阻止项目。数据说明需要读取和产生什么，来源、质量和权限如何。

决策说明哪些判断由规则完成，哪些依赖经验，哪些必须由专业人员确认。结果说明希望改变什么，以及怎样知道变化已经发生。

最后应能用一段话复述项目：为哪类用户，在什么流程节点，使用哪些数据，辅助什么决定，先改变哪项指标，并遵守什么边界。如果仍只能说“建设企业智能体平台”，说明问题还没有收紧。

方案不是技术组件的陈列，而是对项目判断的完整表达。

现状与问题要说明当前流程和可观察代价；目标要描述最小业务结果；范围要明确用户、流程、数据、系统和不做事项。

方案设计说明规则、检索、模型、工作流、工具与人工怎样配合；前提与假设列出项目成立依赖的条件；风险与护栏覆盖数据、权限、错误后果和降级方式。

实施计划说明阶段、负责人和决策节点；评测与验收说明测试数据、指标、通过标准和评价人；运维与交接说明上线后谁负责监控、更新和支持。

越早把不确定性写出来，后续扯皮越少。隐藏风险不会让客户更有信心，只会让问题在成本更高时出现。

POC 用于证明某项关键技术或假设可行，样本和用户可以受限，不代表系统适合生产。Pilot 是在受控范围内让真实用户、真实数据和真实流程参与，验证采用、效果和运维。

生产项目需要面对持续运行、完整权限、监控、故障恢复、服务责任和规模要求。一个 POC 表现很好，仍可能因为无法集成、风险过高或无人维护而不能上线。

项目开始前必须明确当前阶段，以及进入下一阶段需要什么证据。

企业 AI 项目的成本包括业务调研、数据处理、方案设计、开发、系统接入、测试评测、安全审查、部署、培训、沟通和上线支持。

如果报价只计算写代码的时间，团队会被迫用加班承担遗漏工作，或者在关键环节偷工减料。

不确定性高的项目适合分阶段报价。先对发现和验证阶段收费，关键假设成立后，再确认试点与生产范围。还要写清模型调用、云资源、软件许可、差旅和长期运维由谁承担。价格不是一个数字，而是与范围、责任和风险配套的承诺。

交付团队无法单方面创造业务结果。客户需要按时提供数据、接口、账号、测试用户、业务专家和决策反馈。

这些内容应成为正式前置依赖，并写明负责人和时间。如果依赖延迟，计划怎样调整；如果数据质量与预期不同，是否重新定界。

项目中出现新需求很正常，危险的是悄悄把变化塞进原计划。变更应说明价值、工作量、风险和时间影响，再由有权人员决定加入、替换还是延期。

第一次会面的目标不是立即展示模型，而是判断项目是否成立，并把客户叙述翻译成流程、角色、数据、决策和结果。一份可执行方案要同时说明范围、技术、假设、风险、计划、验收和运维。

方案通过后，真正的挑战才开始：怎样在有限时间内取得可验证进展，又不让试点变成无止境开发。