导读： 在传统软件外包和企业 IT 流程里，项目启动的第一步通常是“写需求文档（PRD）”。

双方的产品经理和业务代表关在会议室里，反复撕扯、签字画押，耗时一个月拿出一份厚厚的 PRD。如果程序员在没有 PRD 的情况下动手，会被视为极其不专业的“草台班子”。

然而，FDE（前线部署工程师） 的交付逻辑彻底颠覆了这一常识：零 PRD，无需求文档，却能在一周内上线跑通核心系统。这背后的核心秘诀，恰恰是 FDE 独有的“现场走动 + 极速原型 + 渐进式驯化”交付法。

---

一、 PRD 的神话破灭：为什么完美的文档无法保证成功的交付？

为什么大厂和外包极其依赖 PRD？因为他们需要用文档作为“免责合同”。 一旦项目失败，开发商可以说：“我是完全按照 PRD 开发的，难用是你们产品设计的问题。”

但在实际商业现场，PRD 存在两个致命的 Bug：

1. 用户无法描述“没见过的东西”： 在系统上线前，业务人员脑子里的需求是抽象和分裂的。他们无法凭空想象出 AI Agent 在遇到网络异常时应该如何交互。强迫他们写 PRD，只能逼出大量不切实际的伪需求。
2. 遗漏了“非正式工作流”： 每个办公室都有大量不成文的“潜规则”（例如：“张姐每天下班前要手动把红字单据导出来发给老板，因为老板不看系统”）。这些暗流流程是永远不会被写进 PRD 的，但它们才是系统能否运转的关键。

二、 FDE 的一周极速交付流程（The 7-Day Sprint）

FDE 不写 PRD。他们用“可以跑通的代码/工作流”代替文档。以下是 FDE 经典的一周交付时刻表：

[第1天: 现场观察与影子体验] ➜ [第2-3天: 搭建骨架与垃圾原型] ➜ [第4-5天: 现场试用与在线重构] ➜ [第6-7天: 平滑发版与价值交付]

Day 1：现场观察与“影子体验”（Shadowing）

FDE 不去会议室开会，而是直接提着椅子坐到一线的出纳、客服或销售员旁边，进行半天的“影子观察”。

• 观察他们怎么复制粘贴数据、怎么查收邮件、怎么在不同软件间切换。
• 识别出最消耗时间的瓶颈（例如：手工对账需要对照 3 个不同的表格）。
• 产出：在脑海中勾勒出最简捷的业务闭环（Happy Path），无需任何文档。

Day 2 - Day 3：搭建骨架与“垃圾原型（MVP）”

FDE 回到座位，使用 n8n + Supabase + Dify 极速拼装出系统的核心骨架：

• 不写 登录注册、密码找回、华丽的权限管理、系统设置看板（这些在早期都是浪费时间）。
• 只实现核心通路：数据进入  AI 提取分类  自动写入老系统数据库  飞书通知。
• 这个原型可能没有任何精美的前端界面，但它已经可以在生产数据下运转起来。

Day 4 - Day 5：现场试用与“在线重构（Live Refactoring）”

FDE 把这个垃圾原型直接部署到一线员工的电脑上，让他们开始试用，并在旁边静静观察：

• 员工抱怨：“这个按钮字太小了。”  FDE 当场打开 Cursor，修改 CSS，热重载，2 秒钟更新完毕。
• 员工反馈：“哎呀，遇到外币单据系统报错了。”  FDE 现场捕获报错日志，发现是汇率换算逻辑缺失，当场补写 10 行 Python 代码，重新运行工作流，问题解决。在这个阶段，系统在真实业务场景的撞击下迅速完善。

Day 6 - Day 7：平滑上线与“赋能交接”

经过两天的现场高频迭代，系统已经完美贴合了员工的真实操作习惯。 FDE 在第 6 天将其平滑部署到客户的本地 Docker 容器中。 第 7 天，FDE 对员工进行简单的 10 分钟培训，并在客户老板的电脑上拉出实时提效看板。项目圆满交付。

三、 PRD 传统开发与 FDE 极速交付的本质对比

写在最后

“软件工程最大的浪费，就是去完美地实现那些根本不需要的功能。”

PRD 往往是官僚主义和推卸责任的温床。 AI 时代，工具的极速发展让“开发成本”降到了历史最低。高价值的 FDE 应该甩掉 PRD 的繁文缛节，用最快的速度把一个粗糙但能跑通的核心原型推到用户面前，在真实业务流的碰撞中敏捷雕琢系统。这，才是让软件工程降本增效的终极法则。

本文作者：Mason / 睿亭信息咨询

如果你对 FDE 落地模式感兴趣，或者正在谋求转型，欢迎关注我们，获取最前沿的 AI 工作流与 FDE 实战指南