第 13 章 · 别一上来就写代码
一个白写了三周的框架
有个刚转 FDE 的后端工程师,接了个「合同条款问答」的 PoC。他手很快,拿到需求第二天就开工了——自己搭向量库、写检索、封装 API、做了个前端页面,一套工程化架构干得漂漂亮亮,写了三周。
演示那天,业务方看了两分钟就说:「这个问答我们其实想要的是能直接圈出合同里有风险的那句话,不是一问一答。」——他理解的场景,和业务方要的,根本是两回事。三周的框架,推倒重来。
问题不在他技术差,恰恰相反,他技术太好,好到一上来就奔着「造一个耐用的系统」去了,却跳过了「先确认这条路对不对」。 在 PoC 阶段,写代码往往不是最快的验证方式,反而是最慢、最贵、最舍不得推翻的那个。
FDE 戴上架构操盘手这顶帽子,第一条纪律是:别一上来就写代码。 先问「有没有不写代码也能验证的办法」,验证通了、方向对了,再决定要不要、以及在哪里投入工程。这一章给你一条三层路径,教你把力气花在刀刃上。
三层路径:快验 → 定制 → 工程化
同一个需求,有三种造法,代价和用途完全不同。关键是按顺序来,能停在前一层就别进下一层。
第一层:开箱工具快验(1–3 天)。 用 Dify、Coze、n8n 这类平台,拖拽就能搭出一个能跑的流程。目标不是好看、不是耐用,是最快验证「这条路走得通、业务方认这个方向」。第 18 章那个案例,第一版就是用开箱工具三天跑通的。这一层做出来的东西丑、糙、扛不住量,没关系——它的使命是拿到「方向对不对」的答案,答案拿到就该功成身退。
第二层:Vibe Coding 定制(几天到一两周)。 开箱工具总有做不了的地方:一个特殊的交互页面、一个平台不支持的小工具、一段定制的处理逻辑。这时候用 Cursor、Codex 这类 AI 编程工具,以自然语言驱动,快速补上这些定制件。它比纯手写快得多,又比开箱工具灵活——是「快验」和「工程化」之间的过渡带。
第三层:工程化(按需,通常在验收后)。 当 PoC 已验证价值、要走向生产——需要可维护、可扩展、能扛真实流量、能长期演进——才动用 LangGraph、LlamaIndex、FastAPI 这类真正的工程栈,把前两层验证过的东西,重写成一个能上生产、能交接的系统。
一句话记住:前两层是为了「验证值不值得」,第三层才是为了「做得住、传得下去」。 那位工程师的错,是直接从第三层起步。
一张工具选型地图
哪层用什么、什么时候升层,做成一张地图,选起来不纠结。
| 层 | 典型工具 | 用来干什么 | 什么时候用 | 升到下一层的信号 |
|---|---|---|---|---|
| 快验 | Dify / Coze / n8n | 拖拽搭流程,跑通核心 Case | 刚拿到方向,要验证假设 | 方向已确认,但开箱工具做不了某些定制 |
| 定制 | Cursor / Codex 等 Vibe Coding | 补开箱工具做不了的页/工具/逻辑 | 需要定制交互或特殊处理 | 已验收,要上生产、要可维护 |
| 工程化 | LangGraph / LlamaIndex / FastAPI | 可维护、可扩展、上生产 | PoC 通过验收,走向 MVP/生产 | —— |
选型不是一次性决策,而是一条随信号升级的路。 大多数 PoC,在快验和定制两层就能完成验收;真正需要爬到工程化的,是那些已经证明了价值、要长期跑下去的项目。
不管在哪一层,都建议同步维护一张技术架构图(接入层/编排层/智能体层/能力层/数据层/横切),它既是当前施工图,也是升层时的路线图。模板见附录 C。
工具名会变，选型问题不会变。更稳妥的问法是：
| 路径 | 不变的问题 | 工具只是例子 |
|---|---|---|
| 快验 | 能不能 1–3 天把核心流程跑通，让业务方看到方向？ | Dify / Coze / n8n / 其他低代码 Agent 平台 |
| 定制 | 开箱工具缺的交互、集成、脚本能不能快速补齐？ | Cursor / Codex / Claude Code / 其他 AI 编程工具 |
| 工程化 | 能不能多人维护、可观测、可回滚、权限隔离、稳定运行？ | LangGraph / LlamaIndex / FastAPI / 企业内部平台 |
什么时候必须进入工程化？看六个信号：
- 已有真实用户连续使用，不再只是演示。
- 接入了生产系统或客户数据。
- 需要权限隔离、审计日志和回滚。
- 每天调用量、成本或延迟开始影响业务。
- 需要多人维护，不能只靠 FDE 的个人电脑和个人账号。
- 业务方要把它纳入正式流程或 SLA。
快验阶段可以欠一些债，比如界面粗糙、脚本临时、监控简陋；但进入 MVP 前，权限、日志、评估、回滚、成本监控这些债必须还。
FDE 选型的三个判断
工具眼花缭乱,但 FDE 选型时其实就盯三件事,别被新框架带跑。
- 够用就好,别为「更强」升层。 开箱工具能验完的事,别为了「显得专业」去写框架。技术栈的高级程度,不是交付水平的证明。
- 看能不能交接,不只看能不能跑。 第三层工程化的一个隐藏目的,是让东西能被别人接手运营(第 21 章)。选型时就要想:这套将来谁来维护、他 hold 得住吗?
- 成本、延迟、合规一起算。 模型和工具的选择,不只看效果,还要看单次成本、响应延迟、数据是否合规出境。这些在快验阶段就该心里有数。
常见坑
- 一上来就工程化。 跳过快验直接写框架,方向一错三周白干。
- 停不下来,层层往上爬。 快验能收工却非要升到工程化,为不需要的耐用性付代价。
- 只顾跑通,不画架构图。 没有架构图,升层和交接时全靠脑子记,越到后面越乱。
- 选型只看技术光鲜。 挑最火的框架而不是最合适的,埋下没人能维护的坑。
本章产出
往交付包里放一张「工具选型地图 + 当前层架构图」:
为你的 PoC 标出现在处在三层路径的哪一层、用了什么工具、什么信号出现才升下一层;再照 附录 C 画出当前这一层的技术架构图。这张地图让你(和小队)始终清楚:力气该花在验证,还是花在工程。
成熟度自检
- [ ] 我能按「快验→定制→工程化」三层路径,为 PoC 选对起点、不过早工程化(→ L3)
- [ ] 我能画出当前层的技术架构图,并说清升到下一层的触发信号(→ 巩固 L3)