从产品经理到 FDE:AI 时代,软件交付的最小单元正在变回「人」

1998 年我入行。一个模块从需求调研、库表设计、编码、测试到客户现场交付，全是一个人。那会儿不觉得有问题——改一个字段当天就能在客户机器上看到结果，谁也不用等谁。

二十多年后，我做过开发、产品经理、技术管理。今天我又在用另一种方式交付：从澄清问题、画原型、定契约，一路做到代码生成和现场验证——团队管这个角色叫 FDE。它看起来像 1998 年，但成本结构完全不同。

1998 年没有统一平台，没有开源生态，没有能读懂代码的 AI——没有降低协作成本的工具。

软件交付最贵的一环是协作——把一个人脑子里的东西搬到另一个人脑子里。需求讲一遍、设计讲一遍、接口讲一遍，每一次都有损耗。

那最理性的选择就是消灭「讲述」：一个人干到底，所有的讲述都变成自己的思考。

三个好处是真实的：协调成本几乎为零，交付极快；有完整的因果感；人被逼着想清楚每一层，因为没人兜底。

代价也真实，而且会在项目变多之后集中爆发：

最致命的不是慢，是不可复用。它的效率是借来的：用「不协作」换速度，代价是每一分经验都留在个人身上，组织一点没攒下。项目少的时候看不出来，项目一多，账就连本带利还回来。

所以那个年代的正确方向，是往分工走。

行业后来的演进很清楚：把一个人的活拆成「项目经理—产品经理与测试—开发团队」的三角。

项目经理管外部（资源、进度、客户关系），产品经理翻译需求对接开发，测试在末端把关。

价值是把能力规模化了：任一环都能换人，有了质量关卡，产品资产可跨项目复用。

它成立的前提，是一个很少被写下来的假设：需求可以被一次性说清楚，并且在一段时间内保持不变。

工业时代这个假设基本成立；软件时代，几乎从来不成立。

开发常说「你把需求定清楚，别改」。在项目管理上正确，在认识论上错误——用户不是不想说清楚，是不知道自己不知道什么。需求不是「收集」来的，是看到东西之后才想清楚的。

所以开发要「明确、正确、不变」，用户给「不完整、有缺口、会变」——不是态度冲突，是结构冲突。需求过三个人才到写代码的人手上，这个冲突就无解。

这就是「长尾项目」的来历。但它的机理，很多人理解反了。

不是需求总量大，而是变更分布在长尾：八成共性的可以复用，两成个性化的要单独设计、单独验证、单独扯皮——成本大头在这两成。

敏捷把「变更」制度化了——拥抱变化，小步快跑，这没错。但它没有把「承接变更的单元」变小。一次变更只能进排期，一个排期就是一个版本，一个版本留一段尾巴。变更越多，尾巴越长，用户越等不起，就越绕过流程直接找开发——项目被拖成长尾。

长尾项目的弊端有七条，根子只有三个——下表前三行。

一句话：三角结构把「能力」规模化了，但没有把「信息」规模化。而软件交付的成本大头，恰恰是信息。

这里说的「信息」不是数据，是决定「做什么、为什么做、做成什么样算对」的判断：客户的真实意图、不能碰的约束、当初否掉另一个方案的原因、验收用什么对数、这次改了什么。

它们大多不在文档里——在某个人的脑子里，或在某次对话里。文档擅长写「是什么」，不擅长写「为什么」和「不能碰什么」。

能力可以靠加人规模化，信息不能。加人只会让信息多过一道手——每过一手都是一次有损压缩，丢的部分还不会报错。

FDE 真正解决的问题：让「信息」有了不依赖某个人的载体。

FDE(Forward Deployed Engineer，前置部署工程师)来自 Palantir，2005 年前后。

当时他们卖数据平台给情报和国防客户，发现软件很强，客户用不起来。于是把人派进去——工程师坐在客户现场，用真实数据和系统把工作流直接建起来。

有两个关键细节。

第一，它是一对搭档。Delta（前线工程师）负责技术最后一公里；Echo（部署策略师）负责组织最后一公里——谁推动、谁拍板、流程怎么配套。

第二，现场发现的模式必须回流平台，让每次部署都比上一次更便宜。这是它和外包的根本区别：外包卖同样的工时两次，FDE 让经验沉淀成资产。

此后 Palantir 的前线工程师一度比产品工程师还多。近两年 OpenAI、Anthropic、微软、AWS 都组建了类似团队做企业级 AI 落地——模型能力不缺，缺的是把它接到真实业务流程上的人。

FDE 的内核不是「什么都会」，是离问题足够近，并对结果负责——不是对「交付了没有」，是对「有没有产生结果」。

它和 1998 年的全包，差在三件事：

差别不在「一个人」，在一个人背后站着什么。

FDE 的「一个人」不是「一人公司」。

一人公司是商业形态的最小化，算盈亏；FDE 是交付单元的最小化，算杠杆——平台、契约、机器关卡一样不能少，少了就退化成个体户。

区别在资产归属：一人公司的经验归自己；FDE 的经验必须回流成组织资产。同一套 AI 工具，去掉回流是个人外包，加上回流是组织能力。

为什么这次一个人能覆盖一条链路？三件事同时变了。

AI 把「从想法到可运行」的成本压掉一个数量级，一个人就能覆盖需求、设计、编码、验证。可运行的 demo 取代文档成为共识载体——用户看到东西才说得清需求。共性能力沉到平台里（脚手架、组件库、生成规则、测试基线），一个人才扛得住第二个项目。

三条缺一不可：只有 AI 没平台，十人十种实现，技术债更快；只有平台没 AI，交付还是慢；有 AI 有平台没契约和机器关卡，质量无人把关，上线就露馅。

不等于「一人包干」，只需要三道机制。

平台托底：共性能力不下放到项目，否则一个人造的轮子比十个人造的更歪。

契约前置：接口、数据模型、权限、验收标准，四件事先冻结，代码后生成。契约能被机器检查，人盯人不行。

机器关卡：编译、单测、契约一致性审计、安全扫描。把质量从「人的责任心」换成「流水线的硬约束」——责任心会疲劳，流水线不会。

落到组织上，大概是这样一个小结构：

注意这里没有「产品经理」这个格子。产品经理的能力没有消失，它变成了 FDE 的核心能力：定义问题、判断什么值得做、把验收标准说清楚。这些是 FDE 最难的活，写代码只是其中一项，而且是最容易被 AI 接手的那一项。

结论先说：不是组织变革，是交付单元的迁移。不用改架构，不用裁人。三步，顺序不能反。

▍第一步：砍信息损耗（1~2 个月）

不改岗位，只改一件事：需求澄清会、原型、契约，同一天产出。

现在是需求会→写文档→评审→设计→开发，中间隔几周，每段都在丢信息。改成会上当场画原型、当场定死四件事（接口、数据模型、权限、验收标准），冻结后代码才开始写。变更入口收归一人，建台账。

验收标志：变更从提出到上线不超过一周；开发不再问「到底要什么」；需求返工明显下降。

这一步不涉及岗位变动，但决定后两步能否成立——契约不前置，FDE 只是更快的传声筒。

▍第二步：把 FDE 这个人立起来（2~3 个月）

选一个人，对一条链路端到端负责。建议产品经理出身、又能写代码的人——FDE 最难的活是定义问题，不是写代码。

三个动作：他不是「接需求」，是去现场定义问题；他交付的不是文档，是可运行的东西；他必须拿到需求拍板权和上线决定权。没有这两个权力，FDE 会退化成全栈打杂。

同时立起两个复核点：契约评审、上线评审——只有这两处需要第二个人。

验收标志：能独立跑完一个中等模块的端到端交付；第二个同类项目耗时比第一个短。

▍第三步：建复用底座（持续，第一个项目结束就开始）

第一个项目结束时，强制交回一件资产（一个模板、一个组件、一条生成规则、一批用例）。第二个项目开始时，先用资产，再写新代码。

平台团队 2~3 人兼职足够，职责一条：让第十个项目比第一个便宜。

验收标志：新项目共性部分不用重写；FDE 交付周期逐个项目下降。

注意：平台是从项目里抽出来的，不是提前设计的。先建中台再改交付，通常半年出不来东西。

▍为什么顺序不能反

一句话：先砍信息损耗，再立交付单元，再建复用底座，最后才动组织和考核。

第一件：为了省人工，把三个角色并成一个。

项目经理的活拆两层看。事务层（排期、跟踪、周报、纪要、需求转述）AI 能替掉七八成。责任层（合同、回款、验收签字、资源争取、风险担责）替不掉——AI 能写周报，但不能在验收单上签字。

项目经理可以兼 Echo，而且往往更优——政企项目里，项目经理本就是客户关系的持有者，最清楚钱从哪来、谁在推、谁在拖。

但项目经理不能兼 FDE——不是能力问题，是时间位置问题。FDE 和 Echo 都要泡现场，只是泡的地方不同。一个人同时泡两处，必然空一处。空的那处不会表现为交付延期，而是「验收了，没人用」——这种失败最难追责，也最贵。

省成本要省在重复劳动上，不要省在现场。需求转述、文档撰写、样板代码、测试用例、回归验证、进度汇总——这些占传统项目工时大半，且不产生差异化价值。

第二件：把工具当成了模式。

三不要：不要把「人少」当「敏捷」——没平台托底，就是 1998 加更快的技术债。不要用 AI 生成量当交付量——跑通多少条业务、通过多少条契约检查才有意义。不要让 FDE 变成高级外包——没有回流，就是用更快的速度制造十种实现。