跳到正文
观猹观猹学社

把“想上 AI”变成一份能交付的 SOW

从项目线索和真实需求出发，建立 SOW、Spec 与 Demo 的证据链，再用 CLI 完成第一个可验证原型。

✦全文约 5500 字 阅读需 18 分钟 韦雷 Lyon 最近更新 2026.08

01课程介绍#

本节课把业务需求收敛成一个边界清晰、能够落地和验收的企业 Agent 项目。你会从项目范围开始，逐步形成 SOW、Spec 与最短 Demo 证据链。

随后使用 CLI 开发工具跑通一条核心业务流程，验证方案是否真正可用，而不是一开始就建设功能完整的大系统。

你将学到什么

  • 判断项目线索是否值得投入，并明确目标、边界与量化指标。
  • 用一页范围说明书把业务需求转化为可确认的任务。
  • 理解 SOW、Spec 与 Demo 在交付证据链中的不同职责。
  • 使用 CLI 开发工具完成一个可运行、可验收的最小原型。

02课程回放#

正在准备课程回放…
本节课的主线 FDE 的工作不是从写代码开始，而是沿着 线索判断 → 需求诊断 → SOW → Spec → Demo → 交付复用 逐步降低不确定性。每一步都要留下可供客户确认的证据。

03课程课件#

完整课件正在载入…

04从传统 ToB 分工到 FDE 铁三角#

传统 ToB 项目通常由品牌市场、SDR、销售、售前解决方案、项目经理、产品研发、客户成功等多个角色接力完成。客户侧同时存在业务、采购、IT、数字化和管理层，多次转交很容易损失上下文。

AI Coding 降低了构建门槛，但企业 Agent 又要求团队更深入地理解现场业务。两种变化叠加后，原本分散的能力开始向 FDE 聚合。课程将 FDE 拆为三个可以协作、也会互相重叠的方向：

角色 主要职责 最重要的能力 常见转型来源
商务型 FDE 获得线索、识别关键人、推动决策、管理客户关系 懂业务、懂组织、能建立信任 销售、售前、客户成功
产品型 FDE 诊断需求、定义范围、设计方案、制作 Demo、推进项目 问题定义、产品判断、项目管理 产品经理、解决方案、项目经理、设计
工程型 FDE 系统集成、模型与数据处理、测试部署、保障生产稳定性 工程底座、快速学习、现场排障 研发、算法、测试、实施
FDE 不是一个人强行承担所有岗位，而是让最小团队拥有从客户问题到生产结果的完整责任。

对于复杂项目，较稳妥的最小组织仍然是商务、产品、工程组成的“铁三角”。一个人可以同时覆盖多个方向，但不能假设只靠生成一段代码就完成企业交付。

05从项目线索到交付复用的完整路径#

客户最先购买的通常不是 Agent，而是“你做得成”的证据。项目推进的每一步，都应换来下一步更深入的授权，而不是一开始就索要完整预算和数据。

  1. 用案例证据换取诊断机会 通过同行案例、可展示结果、行业经验和关键人信任，让客户愿意安排线上诊断或线下 Workshop。
  2. 进入真实流程，挖出真实问题 看一线人员实际如何工作，确认谁在做、为什么这样做、哪些例外无法写进普通 SOP，以及数据和系统在哪里。
  3. 判断这是不是值得做的项目 核对决策人、业务价值、验收指标、数据条件、交付成本和复用空间，避免被“想看看 AI”之类的伪需求牵着走。
  4. 用 SOW 固定商业边界 明确目标、范围、交付物、里程碑、双方责任、评测方式、验收条件、变更机制与付款节点。
  5. 把 SOW 翻译成 Spec 将商业承诺拆为页面、接口、模型、Prompt、数据结构、测试方案和排期，形成研发可以执行的技术说明。
  6. 制作最短 Demo 证据链 围绕一个核心流程和一个关键指标做出原型，用于和客户拉齐需求，而不是堆出完整功能合集。
  7. 交付结果并沉淀产品能力 把现场规则、数据、评测和反馈沉淀为可复用底座，使第二个同行客户不再从零开始。
线索阶段证明你理解过类似问题，而不是急着展示所有技术。
诊断阶段获得真实业务、数据和组织上下文。
SOW 阶段把“怎样算赢”写成双方都能执行的约定。
Demo 阶段用可运行结果验证理解，而不是提前承诺生产能力。
交付阶段对稳定性、规模、权限、审计和业务指标负责。

06先判断这是不是一场值得打的仗#

线索需要证据，不只需要介绍

不同客户相信的证据不同：大型民营企业可能看重已服务客户与复杂项目经验；中小企业更关心同行是否已经跑通；有明确痛点的客户则更容易被针对性的解决方案和 Demo 打动。

案例包的任务不是现场签约，而是换来一次更深入的诊断。一个有效案例至少应说明：

  • 客户原来的业务流程和主要问题是什么。
  • 你改变了哪一个关键步骤，而不是笼统地“接入 AI”。
  • 结果如何衡量，产生了多少效率、质量、收入或风险改善。
  • 哪些能力可以迁移到当前客户，哪些仍需重新验证。

诊断需求时，同时看人和事

企业客户说出的需求，往往混合了业务目标、组织立场和个人动机。FDE 既要理解流程，也要识别决策链。

  1. 谁能拍板 谁发起项目、谁掌握预算、谁参与验收，谁只是提供信息。
  2. 流程如何真实发生 一线员工如何获取信息、操作系统、协作、返工和处理例外。
  3. 现在如何被考核 客户每周关注什么 KPI，错误、超时或损失如何计算。
  4. 数据与系统在哪里 输入来自数据库、业务系统、表格、文档还是聊天记录，质量和权限如何。
  5. 为什么以前没有解决 是技术不可行、成本过高、组织不配合，还是目标本身没有价值。
  6. 什么结果可以验收 明确样本、指标、容错、时间和最终签字人。
伪需求的明显信号 如果客户始终不允许接触真实流程、业务人员、数据样本或验收负责人，这次沟通很可能只是市场调研、供应商试稿或内部汇报素材，并不等于一个已经成立的项目。

项目筛选还要考虑复用和经济性

FDE 与按人天出售的外包，关键区别之一是持续沉淀。一个项目即使有收入，如果完全偏离团队的行业和产品方向、无法形成复用能力，也可能消耗掉最稀缺的注意力。

判断维度 继续推进的信号 需要谨慎的信号
决策 关键人明确，预算和验收路径可确认 只有使用者感兴趣，没人能作决定
价值 当前损失可计算，结果可被业务指标表达 只说“体验更好”“显得更智能”
条件 能获得样本、系统接口和业务人员配合 核心数据长期不可得，责任却全部给供应方
成本 报价覆盖铁三角投入、模型费用、风险和利润 项目金额只能覆盖人力，范围还持续蔓延
复用 规则、评测、连接器或工作流可服务同类客户 一次性特殊需求，无法进入团队能力底座

07SOW：先把“怎样算赢”写在纸上#

SOW 是 Statement of Work，即项目工作说明书。它通常作为合同附件，用来确定商业承诺和验收边界；它不是完整的产品需求文档，也不负责描述每一个实现细节。

好 SOW 的判断标准 客户愿意签字，同时团队对其中每一项承诺都有把握做到。SOW 写得“更宏大”并不代表方案更专业，无法验证的承诺只会推迟验收和回款。

一份可执行的 SOW 至少应覆盖以下内容：

业务目标解决哪一个问题，为什么现在要解决。
范围基线包含和不包含什么，P0、P1、P2 分别是什么。
关键人与责任双方负责人、业务配合人、数据提供方和验收人。
交付物系统、接口、模型、文档、培训及其数量与格式。
里程碑每个阶段的时间、输入条件、输出和确认动作。
数据依赖样本规模、质量、权限、脱敏和延迟要求。
评测与验收测试集、指标口径、容错范围、试运行周期和签字机制。
变更与付款变更如何评估、报价、排期，以及首款、阶段款和尾款节点。

量化指标从客户考核中来

“提高效率”“优化体验”无法直接验收。指标应从客户已有的业务考核中提取，例如：

  • 质量：准确率、召回率、合规率、一次通过率、错误率。
  • 效率：单任务耗时、单位时间产能、人工复核时长、流程周转时间。
  • 规模：并发量、日处理量、覆盖账号数、稳定运行时长。
  • 业务：转化率、收入、成本和风险损失，但要确认哪些因素确实由本项目控制。

对于未经真实数据验证的 AI 指标，不要在合同阶段盲目写高。业务结果通常由产品、组织、运营和市场共同决定，不应把供应方无法控制的全部结果直接变成单方验收责任。

SOW 管理变化，而不是假装需求不会变

  1. 先记录范围基线冻结双方已经确认的目标、功能和交付条件。
  2. 提出变更申请写清新需求的原因、价值、优先级和预期结果。
  3. 评估影响说明它对人员、模型成本、排期、既有指标和风险的影响。
  4. 重新确认承诺由双方确认是否替换原范围、追加预算，或进入后续阶段。

付款常见做法是按签约、上线或阶段验收、最终验收分三期；复杂项目也可能拆为五期，并保留一部分维保或质保金。具体比例没有统一答案，关键是让付款节点与可确认的交付物对应，并在涉及 SLA 时明确故障等级和扣款条件。

08从 SOW 到 Spec，再到最短 Demo 证据链#

SOW 决定商业边界，Spec 决定技术实现。进入开发前，要把页面、接口、模型、Prompt、数据结构、测试和部署要求写成可以被工程团队与 Coding Agent 共同执行的说明。

Demo 的目标不是功能越多越好，而是用最短路径证明核心价值。开始制作前先回答三个问题：

  1. 给谁演示 老板关心价值和结果，业务负责人关心流程，IT 关心集成、安全与运维。
  2. 只跑哪条核心路径 选择最能代表业务价值的输入、关键处理和输出，不先做所有边缘功能。
  3. 要证明哪个数字 用真实样本演示效率、准确率、产能或风险改善，并保留可复查依据。
阶段 主要用户 目标 不能混淆的边界
Demo 制作人与决策相关方 具象化需求，确认理解和核心价值 能演示不等于可由真实用户长期使用
MVP 一小批真实用户 跑通账号、权限、数据和完整任务闭环 可试用不等于达到生产规模和稳定性
生产交付 正式业务团队 满足稳定性、性能、安全、审计和运维要求 需要工程化重构，不能默认沿用 Demo 代码

CLI 开发工作流

Claude Code、Codex、Cursor 等工具可以显著缩短从材料到 Demo 的时间。课程建议在本地项目中保持完整上下文，用项目规则文件和结构化文档约束 Agent，而不是只发一条模糊指令。

  1. 建立项目规则在 AGENTS.md 或对应项目说明中记录架构、运行方式、数据边界和质量要求。
  2. 输入可信上下文提供已确认的 SOW、会议纪要、旧系统截图、样本数据和现有代码，而不是让模型猜业务。
  3. 先生成 Spec让 Agent 复述目标、拆解数据流与页面流程，并暴露还未确认的问题。
  4. 按小步任务实现一次完成一个可验证的功能，持续运行测试、截图和记录变更。
  5. 用真实样本验收围绕业务测试集比较输入、输出、错误类型和指标，不以“页面能打开”作为完成标准。
  6. 沉淀可复用资产将连接器、评测脚本、Prompt、Skill 和流程模板返回产品底座。

课程演示的 ChatDemo 思路，是在客户交流时同步收集录音、文字和材料，再快速生成可展示原型，让需求确认发生在客户仍有完整上下文的时候。它适合缩短反馈回路，但仍不能代替正式的 Spec、测试和生产工程。

客户数据不能直接交给公共开发工具 CLI 工具可以用于制作脱敏 Demo 和理解授权代码，但涉及银行、合同、客户资料等敏感数据时，应使用客户沙箱、私有部署或本地脱敏流程。Demo 阶段的便利不能越过企业的数据与合规边界。

09三个案例：从现场问题到可复用能力#

案例一：鞋服电商素材智能套版

斯凯奇、安踏等鞋服品牌每年有大量 SKU，需要为不同电商平台制作不同尺寸的主图、详情页和视频素材。传统模板可以减少重复操作，但仍依赖设计师逐个替换和检查。

初始状态系统已能完成大部分套版，但准确率约为 85%，无法直接进入规模生产。
现场工作FDE 驻场连接 IT 与业务团队，把客户反馈拆成模块、场景、优先级和验收状态。
技术闭环收集真实图片，制定特征和标注规则，划分训练集与测试集，持续回归错误案例。
交付结果一个月内将关键指标提升到约 95%，并把能力迁移到下一个鞋服客户。
客户面对的从来不只是“能不能生成”，而是能不能持续达到他的交付标准。

案例二：母婴品牌社媒账号矩阵

项目需要把导购人设、选题库、品牌规范与广告法合规结合起来，支撑数千个小红书 KOS 账号持续产出。解决方案采用 AI 初审与人工二审协作，并由 FDE 连接导购、营销、营养专家和 IT 等多个部门。

  • 把账号规模、单日或单周产能、合规通过率写成可追踪指标。
  • 将品牌和广告法规则沉淀为 Skill，而不是每篇内容重新人工解释。
  • 保留人工终审，避免把合规责任交给概率模型。
  • 通过驻场梳理跨部门流程，再决定哪些步骤适合自动化。

案例三：银行信用卡 AI 客服

项目面向社媒、企业微信等渠道，需要准确回答信用卡产品与权益问题，并支持多轮对话。仅依赖传统向量检索时，复杂意图和上下文容易丢失。团队通过意图、槽位、推理和检索组合的 Agentic RAG 逐步改善结果。

  • 从约 70% 到 95% 的提升并非一次 Prompt 调整，而是长期的数据、评测和业务规则建设。
  • 多轮场景要识别用户当前意图、已提供信息和仍缺少的槽位。
  • 上线后出现数据偏移时，要回到错误样本、指标口径和 SOW 责任边界定位问题。

三个案例共同指向同一条规律：现场反馈只有被转化为规则、数据、评测和产品能力，才会形成复利。

10答疑中的关键边界#

FDE 与解决方案架构师是什么关系

两者都承担“翻译”职责。解决方案架构师通常把业务需求翻译成可销售、可配置的标准方案，并沉淀行业共性；FDE 更偏向把需求翻译成可部署、可运行、可被真实用户使用的产品结果。随着 Demo 和现场交付越来越重要，两者能力正在明显重叠。

FDE 是不是外包

驻场本身不能区分 FDE 与外包。外包常按明确需求和人天完成定制任务；FDE 还要参与问题定义、对业务结果负责，并把一次现场交付沉淀回可复用产品。若团队什么项目都接、只按时间收费且没有沉淀，实际工作仍会退化为外包。

企业是否已经会为 FDE 单独付费

目前很多国内项目不会在招标文件中明确要求“配置几名 FDE”，客户的治理、采购和验收流程也不会因为改了岗位名称就变化。FDE 更多是一种降低交付成本、提高成功率的组织与工作方式。能否单独收取驻场和咨询费用，取决于客户类型、供应商资质和项目价值。

每个企业都需要先做本体吗

不需要。完整 Ontology 实施涉及业务流程、数据定义、清洗和组织共识，更适合数据基础成熟的大型企业。许多中小企业先建立清晰知识、语义和工作流层即可，过早建设重型本体只会增加成本。

非技术背景能否转 FDE

可以从商务型或产品型 FDE 切入，但仍要具备基本的技术判断：知道 Demo 与生产的差距，能识别数据、安全、接口和评测风险，并与工程团队共同对交付负责。反过来，工程背景也必须补足业务观察和客户沟通能力。