【FDE知识库专栏】：
https://blog.csdn.net/freewebsys/category_13221845.html
AI 这么强，软件工程师的出路在哪
一句话结论：代码正在变成廉价品，稀缺的是"定义问题"、“算清成本"和"敢背责任”。
出路不是"跟 AI 比写代码"，而是把 AI 变成自己的产能，站到它够不着的地方——存量系统、真实场景、验收标准、最后一公里。
一、先把认知摆正
- AI 让"写代码"的边际成本趋近于零，但软件的边际成本没有趋近于零：需求澄清、数据治理、上线、运维、背锅，一样都没变便宜。
- 历史上编译器、框架、云服务每一次"降门槛"，结果都是软件变多而不是工程师变少。这次大概率也一样，但分层会重新洗牌。
- 被压缩的是"照着文档实现"这一层；被抬高的是：
- 知道该做什么（需求）
- 知道做成什么样算对（验收）
- 知道用多少钱做出来（成本）
- 出了问题谁负责（责任）
- 所以别问"我会不会被替代"，问"我手上有没有 AI 拿不走的东西"。我的答案：老系统的业务细节 + 客户现场 + 数据 + 交付信誉。
二、五条能走的路（按我自己能落地的顺序）
- 存量系统 AI 化——把已有的系统当成资产去改造，而不是重新造。
- 低成本 AI 部署——会算成本、能把成本压下来的人，在这个阶段非常值钱。
- 提供需求——从"接需求"变成"出需求"，这是最难也最抗替代的一层。
- 端到端交付——AI 能力 + 现有系统 + 客户场景，打包成可验收的解决方案（外包/集成）。
- 内容与影响力——公众号/视频/教学，本质是低成本获客渠道，不是主业但要养着。
注意：这五条不是并列选项，是一条链：懂场景 → 能出需求 → 能做 AI 化 → 能低成本部署 → 能端到端交付 → 有内容带客。
三、现有系统怎么"AI 化"
3.1 先分类，不是什么都要 AI 化
| 类型 | 特征 | 处理方式 |
|---|---|---|
| 信息搬运 + 判断 | 看文档、写摘要、分类、抽取、解释、生成 | 优先 AI 化 |
| 强一致 / 强事务 | 记账、对账、撮合、权限、计费 | 不要 AI 化，最多让 AI 做"建议" |
| 硬规则 | 风控阈值、合规校验 | 规则引擎为主，AI 只做异常解释 |
| 手工重复劳动 | 报表、导出、整理、巡检 | 先脚本化，再 AI 化 |
判断标准就一句：出错代价低 + 频率高 + 有标准答案 → 上 AI；反之先别碰。
3.2 三层落地路径（从轻到重）
- 读（Read）：检索增强。把系统里的文档、工单、历史记录接进模型，先只做"问答/摘要/解释"，不改任何数据。
- 写（Write）：工具调用。让 AI 通过受控接口执行动作（查库、生成报表、建单），所有写操作必须走白名单接口 + 可回滚。
- 闭环（Loop）：Agent + 评测。多步任务自动跑，但要有人工抽检、失败兜底、成本上限。
3.3 上线必须带的三件套
- 可观测：每次调用记录 输入/输出/模型/耗时/成本/是否被采纳。
- 可回滚：AI 的结果要能一键关掉，退回人工流程（feature flag）。
- 评测集：自己业务场景的 20~50 条"标准题"，改 prompt/换模型前后都跑一遍，看掉点。
3.4 先跑"影子模式"
AI 在后台跑，结果只记录不生效，和人工结果对比一两周。
数据攒够了、准确率可接受了，再逐步放权（先只建议 → 再一键采纳 → 最后自动）。
没有影子期的 AI 化，基本都会被业务方一句话打死。
3.5 落到我自己的项目上（举例）
- 股票系统适合 AI 化的点：财报/研报/公告摘要、指标含义解释、自然语言选股（NL → 查询条件）、异动原因解释、每日复盘日报生成、数据异常排查助手。
- 不适合 AI 化的点：下单、资金账目、回测撮合、风控硬阈值——这些只能做规则 + 人工复核。
- 先做的第一个：每日复盘日报生成（输入结构化指标 → 输出人话总结），好验收、出错代价低、每天都用。
四、"软件越来越便宜"到底意味着什么
- 便宜的是生成代码，不便宜的是保证它对。所以价值从"实现"移到"验证"。
- 单价会被 AI 拉低，这是事实。利润只能来自 AI 拉不低的部分：
- 数据（别人没有的历史数据、清洗过的脏数据）
- 渠道（客户信你，不信任一个陌生人 + AI）
- 责任（出事有人接电话）
- 最后一公里（部署、联调、权限、合规、培训）
- 竞争逻辑变了：从"能不能做"变成"边际成本谁更低、交付周期谁更短"。
- 反常识一点：token 单价在降，但账单不一定降。上下文变长、Agent 多轮、重试、评测、日志，都会把成本吃回去。所以必须自己算账。
五、低成本 AI 部署：要研究的东西
5.1 成本梯度（从便宜到贵，按需选择）
- 本地小模型：7B~14B 量化（Q4/AWQ/GPTQ），单卡甚至 CPU 可跑，适合分类/抽取/摘要/格式化。
- 本地推理框架：vLLM / SGLang（吞吐、并发、前缀缓存好），llama.cpp / Ollama（轻量、易部署、CPU/Mac 友好）。
- 云 GPU 按需 / 竞价实例：波峰用，波谷关，别常驻。
- API 大模型：只留给真正难的请求（复杂推理、长文档、代码）。
5.2 降本的六个动作（都很实在）
- 混合路由：小模型先答，置信度低/格式不合格再升级到大模型。省钱的大头在这。
- 缓存：精确缓存 + 语义缓存 + prompt 前缀缓存，重复问题不重复花钱。
- 蒸馏/微调替代长 prompt：固定任务用 LoRA 微调小模型，把"提示词里的知识"搬到权重里，长期更便宜也更稳。
- 量化 + 并发调优：KV cache 管理、批大小、上下文裁剪、结构化输出约束（少让模型自由发挥）。
- 评测驱动的降级：每次降级（换小模型/降精度/砍上下文）都必须跑评测集，掉点超过阈值就不降。
- 成本归因：每请求成本、每功能成本、每租户成本，做成一张表天天看。看不见的成本一定失控。
5.3 一个必须做的实验
拿同一批任务（20~50 条真实业务请求），分别在本机小模型和API 大模型上跑，
记录：准确率 / 平均耗时 / 单次成本 / 部署维护成本，出一张对比表。
这张表是我以后报价、选型、说服客户的底气。
六、怎么"提供需求"——这是 AI 时代最贵的能力
需求不是等来的，是在现场捡来的。来源通常是：
- 同事/客户反复抱怨的那句话（“这个报表我每周手动做两小时”）
- 手工重复劳动（复制粘贴、格式转换、跨系统搬运）
- 审批流里的判断（“这个单子该不该批”）
- 看不懂的数据（“这个指标为什么涨”）
把模糊诉求转成四段式需求卡（这是核心方法）：
1. 输入：给什么（数据来源、格式、触发时机） 2. 输出：要什么（格式、示例、可接受的范围） 3. 验收：怎么算对（准确率下限、必须包含的字段、人工抽检规则） 4. 失败：错了怎么办（兜底方案、回滚方式、谁来决定）价值判断四个维度：频率 × 痛度 × 可验证性 × 出错代价。四项都过得去的，才值得做。
一句话：会写"什么样的输出算对"，就是 AI 时代最贵的一句话。
练习方式：每周至少产出一张这样的需求卡，哪怕是自己系统里的一个小功能。
七、我自己的 TODO
- 盘一遍存量系统，列 3 个 AI 化候选点，每个写一张四段式需求卡
- 本机跑通 vLLM / Ollama + 一个小模型，完成"本机 vs API"成本对比表
- 给股票系统建 20 条评测集（日报生成、指标解释、NL 选股各几条）
- 先做"每日复盘日报生成"，用影子模式跑两周，记录采纳率
- 加成本监控：每请求成本、每功能成本，写进日志表
- 写一篇公众号：《把一个老系统 AI 化的 5 个坑》，当获客素材
- 主动找 1 个真实需求（内部或外包），完整走一遍"需求卡 → 交付 → 验收"
- 整理一份"低成本部署选型清单"，能直接给客户看
八、底线和风险
- 钱、账、合规、权限：AI 只做建议，不做决定，且必须可回滚。
- 数据边界要提前讲清楚：哪些能出内网、哪些必须本地模型。
- 别把"会调 API"当核心竞争力——那层很快会被工具吃掉；护城河是场景 + 数据 + 交付 + 信誉。
- 警惕"为了 AI 而 AI"：如果一个脚本能解决，就别上模型。
九、补充：架构师 + AI 是不是就等于 FDE？
先明确 FDE 是什么：Forward Deployed Engineer（前沿部署工程师 / 驻场工程师）。
典型来源是 Palantir 那套模式，现在 Anthropic / OpenAI 等也在大量招。
一句话定义：带着平台能力扎进客户现场，把客户的模糊问题变成可验收、能跑起来的东西，并对结果负责的人。
特征是：离客户近、离钱近、范围模糊、交付压力大、要一个人顶一个小组（AI 正好补这块）。
它不是"售前"，也不是"架构师"，更不是"调包工程师"，它是工程师 + 产品 + 项目经理的混合体。
9.1 结论：架构师 + AI ≈ FDE 的技术底座，但不是 FDE
| 维度 | 架构师 | FDE |
|---|---|---|
| 面对的对象 | 系统和代码 | 客户、人、脏数据、组织政治 |
| 时间尺度 | 半年到三年，长期演进 | 两到八周，必须出结果 |
| 成功标准 | 结构合理、可演进 | 客户签收、业务指标动了 |
| 主要动作 | 设计、取舍、评审 | 访谈、原型、联调、演示、催决策 |
| 输出去哪 | 文档、架构图、代码规范 | 能演示的 demo、上线的东西、验收单 |
| AI 的作用 | 提效（写代码、查资料） | 放大产能（一个人做一个小团队的量） |
所以：架构师的能力回答"这东西怎么搭得对"，FDE 还要回答"这东西该不该做、做了谁付钱、出问题谁兜"。
中间差的不是技术，是商业、沟通、交付节奏三块。
9.2 还需要补的技能（按缺口从大到小）
① 需求与业务侧（最大缺口）
- 行业 know-how：至少能听懂客户在说什么，知道他们的 KPI 是什么
- 访谈与提问：从"我想要个 AI"问到"你每天哪一步最烦、错了会怎样"
- 需求卡能力（前面第六节那个四段式：输入 / 输出 / 验收 / 失败）
- 范围控制：把"能不能再加个…“变成"这属于二期”
- ROI 测算：这个项目省了几个人工小时、值多少钱、多久回本
② 交付与工程侧（架构师底子在，但要提速）
- 极速原型：一天出能演示的 demo（AI 生成 + 现成框架，别从零搭）
- 脏活能力：脏数据清洗、schema 对齐、历史数据迁移——FDE 80% 的时间在这
- 集成：API、OAuth/SSO、网关、内网代理、私有化部署、离线环境
- 可观测与可回滚：影子模式、灰度、一键关掉 AI 的开关
- 问题定位：客户环境里没有日志权限也要能查出来
③ AI 侧（要能算账，不只是能调）
- RAG / 工具调用 / Agent 编排，且知道什么时候不该用 Agent
- 评测集 + 验收指标：把"感觉还行"变成"准确率 92%，抽检 50 条"
- 模型选型与成本：本地小模型 vs API vs 混合路由，每请求成本能报出数
- 幻觉兜底：不知道就说不知道、必须给引用、必须有人复核
- 合规：数据脱敏、能不能出内网、日志留存
④ 人与沟通侧（最容易被工程师忽略）
- 期望管理：敢说"这个做不到"“这要加钱加时间”——FDE 最容易死在过度承诺
- 跨部门推动：IT、安全、法务、业务方，四方都要过
- 演示与讲故事：demo 要打在客户的痛点上，不是打在技术上
- 文档与培训：交付即交接，客户能自己用才算完
- 写作：方案书、周报、复盘——AI 时代这项能力的杠杆反而更大
⑤ 商业侧（架构师完全没有的部分）
- 报价与工作量估算（AI 提效后怎么报才不亏）
- 合同边界：数据责任、模型效果不达标的处理方式
- 验收与回款节奏：验收标准写进合同，别靠口头
- 续约与二期：一次交付 = 一次获客机会
⑥ 个人特质（软但决定性）
- 在信息不全的情况下自己定义任务，不等人给需求
- 抗压 + 快速学陌生行业（两周能跟客户聊得上话）
- 不吹牛：AI 的能力边界敢讲清楚，长期才有人找你
9.3 自检表（架构师 → FDE 的缺口）
- 能独立完成一次客户访谈并产出需求卡
- 一天内能出可演示的 demo（不是 PPT）
- 能对同一个任务给出"本机小模型 / API / 混合"的成本与准确率对比
- 能在客户内网（无外网、有代理、有权限管控）把服务跑起来
- 能写出一份带验收标准的方案书
- 能对客户说"不"，并把"不"变成二期报价
- 交付过至少一个端到端项目，拿到过签收
打勾 5 个以上，基本可以自称 FDE；只勾 1、3 的，是"很强的架构师"。
9.4 路径（给自己排一下）
- 0–1 个月：把手上的存量系统 AI 化跑通一个（日报生成），练"需求卡 + 评测 + 成本表"三件套。
- 1–3 个月：接一个真实小项目（内部或外包都行），强制自己走完"访谈 → demo → 上线 → 验收"。
- 3–6 个月：把这个项目写成案例（公众号/方案书），用它去谈第二个客户。
- 并行：补齐商业侧——报价、范围、验收条款，这三样决定你是"帮忙的"还是"能挣钱的"。
一句话：架构师 + AI 让你有资格做 FDE，能不能做成 FDE，取决于你敢不敢站到客户面前对结果负责。
留一句给自己的话：
不怕 AI 会写代码，就怕自己只会写代码。
