FDE Training · Module 09

09

方案架构与产品化

模块 09 · 方案架构与产品化

本章目标：掌握 FDE 区别于普通后端的核心能力——把客户的业务需求变成可落地的技术方案，在客户现有 IT 约束下做架构选型，快速验证，再把结果沉淀成可复用资产。模块 12 会给配套的完整实战案例。

9.1 需求翻译：从业务语言到技术需求

9.1.1 核心动作

客户讲业务语言，你要做"翻译机"： 客户一句话 → 真实诉求 + 隐性约束 + 伪需求 → 可落地的技术需求

真实诉求：客户嘴上说的背后，真正想解决的业务问题。
隐性约束：客户没明说但存在的限制（数据不能出内网、必须兼容老系统、预算有限、准确率底线）。
伪需求：听起来合理但实则不是真需求的（比如"要全自动"但出了事没人负责）。

9.1.2 需求翻译清单（背下来，比写代码先问）

问题	为什么问
你 w 理想结果 / 业务指标是什么？	没有目标没法验收
数据从哪来、什么格式、在不在内网？	决定可行性 & RAG/权限方案
准确率要达到多少？错了谁兜底？	决定是自动还是人工复核
谁能有权限看哪些数据？	决定 RBAC + 权限过滤
多久要上线？预算多少？	决定范围 & POC 边界
现有的 IT 系统、账号体系是怎样的？	决定对接成本

9.1.3 一个对比（人话示范）

客户说："我要 AI 帮我把所有合同自动审了，别再人工了。"
FDE 心里翻译出的技术需求：
- 文档格式（PDF 多是一图一页？扫描版要 OCR）？
- 审单规则从哪来（有没有标准文件）？
- 准确率要求 vs "自动"的矛盾：哪些场景必须人工兜底？
- 数据权限：审单人只能看自己经办的合同。
- 成本：全自动审海量合同，token 和准确率要权衡。

9.2 Must / Should / Could 范围管理

9.2.1 把所有需求分成三堆

Must：不做会出事 / 不满足就验收不过。
Should：重要但可后置。
Could：锦上添花，可砍。

9.2.2 为什么要管范围

客户中途不停加需求，是 FDE 最大的延期和成本杀手。管范围不是拒绝客户，而是有理有据地评估代价、排期、取舍。

操作要点：

每加一条需求，先问"是不是『现在非做不可』？加了对业务指标有多大帮助？成本多少？"
超出 MVP 的一律进"下一期"清单，写清楚理由。
用"三堆"表拉着客户一起对过，双方签名（留痕也满足审计，模块 07）。

9.3 方案设计：在客户约束下选型

9.3.1 先列约束，再选型

约束决定架构，别一上来就选"最潮的技术"：

数据能不能出内网？（决定私有化 or 用 API）
有没有 GPU？几卡？算力多少？（决定模型大小/量化）
客户现有系统／账号体系？（决定对接方式）
预算和上线时间窗？（决定 MVP 范围）

9.3.2 选型要权衡的三角：效果 / 成本 / 上线速度

效果好 ⇄ 成本高 ⇄ 上线慢
三者只能优先两个, 要跟客户讲清楚取舍

例：要效果好 + 上线快 → 用大厂 API（但数据出内网账要算清）；要数据安全 + 效果好 → 私有化大模型（但成本高、周期长）。

9.3.3 输出一张"方案画布"（交付常用）

维度	内容
业务目标	用一句话说清解决什么
数据	从哪来、格式、内网吗、谁有权限
技术选型	模型/框架/架构、为什么这么选
集成点	接客户哪些系统、账号、流程
范围	Must/Should/Could
风险	数据安全、效果不达标、工期
验收标准	业务指标 + 技术指标，双方认可
里程碑	阶段、产出、负责人

这份画布就是和客户对齐的"合同"，也是后面验收和复盘的依据。

补充：单体 vs 微服务怎么选（决策清单）——别一上来就上微服务，先照五条打勾：① 单一产品、小团队、抢时间上线 → 选单体，简单好维护；② 明确多团队并行、要独立部署/独立扩容 → 才考虑微服务；③ 对高可用和故障隔离有硬要求（一个模块挂不能拖垮全站）→ 微服务更占优；④ 能接受服务发现、熔断、配置中心等治理成本 → 微服务值；⑤ 边界说不清就先单体起步，等真正“痛”了再拆。无论哪种，都要有清晰的架构分层（接入层/业务层/数据层各司其职），别把逻辑揉成一团。完整选型思路去 Spring Cloud 页补齐。

9.4 原形快速验证（POC）：短平快暴露卡点

目的：别等到上线才发现不行。用最少的投入，快速验证"这个方案到底可不可行、卡点在哪"。
POC 要做的三件事：
1. 只验证风险最高的部分（如"扫描合同能识别到几成""模型能达到准确率吗"）。
2. 用最容易上手的原型（脚本、简单前端、真数据跑一遍）。
3. 提前暴露卡点：把"会不会挂"的环节先替到（网络连通、数据质量、模型效果、成本）。

# 一个 1 天内能跑的 POC 雏形
def poc_review(contract_text):
    from openai import OpenAI
    c = OpenAI()
    r = c.chat.completions.create(
        model="gpt-4o",
        messages=[{"role":"user",
                  "content":f"请判断该合同主要风险点，输出JSON结论:\n{contract_text}"}],
        temperature=0,
    )
    return r.choices[0].message.content

POC 的价值：用极低成本回答"能不能做、要多少代价、卡在哪个点"，这是让客户和老板都放心的最快方式。

9.5 可复用资产沉淀：把现场方案变成公司资产

FDE 干完一个项目，别只留一堆一次性脚本。要点：

组件化：把常用能力（脱敏、限流、RAG 检索、Guardrails）封装成可复用模块。
模板化：把常见交付（客服、审单、报表 Agent）做成"模板 + 配置"，下一个客户快速起。
SDK/文档：沉淀成带说明的内部库，新人能直接用。
反馈回流：把现场真实的客户痛点、产品缺陷反馈内部产品/模型团队，推动产品迭代。

为什么要做：FDE 的价值不只在一个项目，而是"一个项目变成 N 个项目的加速器"。这也常是面试里的加分题。

9.6 模块练习

拿一句客户需求（如"让客服效率翻倍，全部用 AI 处理"），做一遍需求翻译：列出真实诉求、隐性约束、伪需求各 1-2 条。
写一份"方案画布"（9.3.3 的表格），填入你熟悉的任意客户场景。
把一个需求拆成 Must/Should/Could 三堆，各至少 2 条。
设计一个 1 周内的 POC：明确只验证哪几个"高风险点"、用什么原型、怎么判定可行。
把你之前写的组件（脱敏/限流/RAG）整理成一个可复用的内部模块，写一句 README。

9.7 本章面试题

"客户说'我要 AI 全自动处理所有合同'，你会怎么做？" → 答：不直接开工。先需求翻译：问清文档格式、准确率要求、谁有权限、错谁兜底、成本；拆范围（哪些可自动哪些必须人工）；做 POC 验证效果；再定方案、验收。强调"全自动"往往要拆成"自动+人工复核"。
"在客户现有环境约束下你怎么选技术方案？" → 答：先列约束（数据内网、GPU、账号体系、预算工期），再用"效果/成本/上线速度"三角权衡；输出方案画布跟客户对齐，而非先选最潮技术。
"你如何管理客户不断加需求？" → 答：把需求按 Must/Should/Could 分堆，拉客户一起对齐；新增需求先评估代价和影响，能后置的进下一期；用画布和里程碑留痕。管范围不等于拒绝，是让双方对代价有共识。
"POC 的目的和做法？" → 答：用最小投入快速验证高风险点（数据质量、模型效果、网络、成本），提前暴露卡点；只验证"能不能行、要多少代价"，不给客户画大饼。
"你如何在现场沉淀可复用资产？" → 答：把通用能力组件化、常见交付模板化、写文档和 SDK，并把客户痛点反馈内部产品/模型团队驱动迭代。让一个项目变成 N 个项目的加速器。

9.8 小结

需求翻译是 FDE 的核心：客户业务语 → 真实诉求 + 隐性约束 + 伪需求 → 技术需求。
范围管理：Must/Should/Could 三堆 + 画布 + 里程碑，管住延期和成本。
方案设计：先列约束再选型，效果/成本/速度三角权衡，输出方案画布。
POC：短平快验证高风险，提前暴露卡点。
资产沉淀：组件化/模板化/反馈回流，让经验放大到很多项目。
下一章：出了事怎么办——排障实战。模块 12 会给配套完整案例。