---
title: "程序员转型 FDE：别再只顾着写代码，先把话讲清楚"
author: Miles Ma
date: 2026-08-13
section: FDE 实战
url: https://immilesma.com/blog/developer-to-fde-communication/
x: https://x.com/miles_mazy/status/2087861557611110733
description: "程序员转向 FDE，技术能力还要接上客户沟通、表达与商务协作。用具体场景练习把技术讲成对方能判断的方案，问清条件、推进共同投入的下一步，再把承诺落实为可交付的结果。"
---

# 程序员转型 FDE：别再只顾着写代码，先把话讲清楚

> 程序员转向 FDE，技术能力还要接上客户沟通、表达与商务协作。用具体场景练习把技术讲成对方能判断的方案，问清条件、推进共同投入的下一步，再把承诺落实为可交付的结果。

**程序员转 FDE，真的有机会，而且窗口已经打开了**。

AI 正在压缩纯执行型编码，也让企业比过去更需要一批懂技术、能进现场、能把模型真正接进业务的人。程序员手里的工程基础、系统思维和踩坑经验，正是转型时最硬的一张牌。

我身边已经有不少同事在这一轮调整里离开了。每个人离开的原因不同，不能全算在 AI 头上，但继续守着编码、测试和文档这些执行工作，能守住的空间只会越来越小。往客户、判断和交付再走一步，程序员反而可能找到新的位置。

技术底子给了程序员一张很好的入场券，后面的路还得自己走。FDE 要进客户现场，听懂不同角色的话，判断什么值得做，控制好承诺，再把系统做进生产。很多程序员转型时还在继续学框架、堆项目，却没有练过怎么让客户听懂自己的判断，这张入场券也就一直没有用出去。

所以，**程序员转 FDE，第一项要补的能力是表达**。你不需要把自己练成销售冠军，先做到把技术讲清楚，把问题问出来，把一次沟通推到明确的下一步。

![文章配图](https://immilesma.com/blog/developer-to-fde-communication/media/01-image-03.jpg)

我自己就是程序员，做过算法、模型优化和部署，也做过企业内部沟通和培训。这篇文章不继续罗列程序员的毛病，也不把沟通讲成玄学。我只说三个真正卡住转型的问题，以及我认为最有效的练法。

## AI 压缩了执行，程序员不能再只靠执行证明自己

AI 对编码的影响已经不只是补全几行代码。Anthropic 在 2025 年分析了 50 万次编码交互，其中 Claude Code 里 79% 被归为自动化。斯坦福在 2026 年更新的一项劳动力研究也发现，美国 22 至 25 岁、AI 暴露较高职业的就业相对差距仍在扩大，年轻人更难被招进去。

这些数据不能直接推出“所有程序员都会失业”。斯坦福的研究也明确说，这是早期描述，不是简单的因果结论。但程序员也没必要再拿这句话安慰自己：**只负责接需求、写代码、改 Bug 的执行价值，正在被 AI 压价**。

FDE 的价值，恰好比执行多走了几步。他要参与客户发现，判断技术范围，设计和构建系统，推动生产上线，还要把现场反复出现的问题带回研发后台，做成下一次项目可以复用的工具、模块和方法。

这条责任链里当然有代码，但代码只占一段。程序员真正要完成的转变，是从“别人告诉我做什么”，走到“我和客户一起判断什么值得做”。

![文章配图](https://immilesma.com/blog/developer-to-fde-communication/media/02-image-09.jpg)

而这件事的起点，在于你能不能把自己的判断说清楚。

## 你讲了很多技术，别人还是不知道该不该做

程序员表达时最常见的误区，是把“信息完整”当成“已经说清”。

客户问知识库能不能做，程序员从 Embedding、切分、召回、重排一路讲到模型评测。每句话可能都对，客户听完仍然不知道三件事：这个东西能解决我哪一步工作，需要我提供什么，下一步该不该继续。

做账号也是一样。文章越写越厚，视频恨不得把背景、原理、架构和异常处理全部塞进去。同行也许挑不出技术错误，真正可能成为客户的人早就划走了。那件“干货必须足够厚”的长衫，很多时候保护的是程序员的自尊：我讲少了，别人会不会觉得我不专业？

要改这件事，不用先学一套复杂的话术。每次开口前，先问自己一句：**我希望对方听完以后，知道什么、决定什么，或者去做什么**？

比如，不要用“今天介绍一下企业 RAG 的整体架构”开场。你可以直接说：

>

今天先不讨论全公司的知识平台。我想确认客服查制度这一个场景，是否值得用两周做一次真实样本验证。

范围、目的和下一步都在里面。后面的技术细节，才有了该放的位置。

如果临场容易乱，我会先把一段话压成三句。第一句说事实，第二句给判断，第三句落到下一步。

>

客服目前要在十几份制度里找答案，同一问题经常出现不同版本。我的判断是，现在先治理版本和权限，比急着换大模型更重要。下一步希望拿 30 个真实问题，看看错误主要来自资料还是检索。

程序员容易把第一句扩成十分钟背景，把真正的判断藏在最后，至于下一步，常常说着说着就没了。其实改法很朴素：**结论往前放，背景只留能支撑结论的部分，最后一定落到动作**。

![文章配图](https://immilesma.com/blog/developer-to-fde-communication/media/03-image-01.jpg)

同一个判断，还要能根据场合改变长度。电梯里遇到老板，只够说一句结论；第一次沟通，要把事实和下一步交代清楚；到了技术评审，才展开证据、限制和风险。

三个版本共用一个核心判断，你只是根据场合，决定对方需要知道多少。**一句话说不清，通常说明你自己还没想清什么最重要**。讲了半天全是名词，也只能证明你在展示知识，没有帮助对方做判断。

## 把话讲清楚，只完成了一半

表达是把自己的判断送出去，沟通还要把对方没说清的东西拿回来。

程序员喜欢和 AI 聊，因为 AI 会耐心回答，也不会因为一句话没说好就改变合作态度。客户是活人。他说出来的是信息，没说出来的还有目标、风险、权力和情绪。

老板说“尽快上线”，可能在追一个经营目标；业务负责人说“流程不能变”，可能担心项目失败由他负责；一线人员说“都可以”，回去以后却继续用 Excel；IT 强调安全，背后可能是系统出了问题，最后都要落到他的团队头上。

程序员习惯对着一句话的字面给答案。FDE 得再往下多看一层：**他想得到什么，他最怕失去什么，他实际上能决定什么**？

所以我去见客户前，不会先做一份几十页的人物画像。我只给关键角色记三件事：目标、风险、权限。
- 老板要看到什么结果，最怕什么投入失控，他能决定预算，还是只能表达态度？
- 业务负责人背着什么指标，流程变化以后谁会增加工作，他能不能提供真实样本？
- IT 担心哪些安全和维护问题，他能批准接口，还是只能提意见？
- 一线使用者到底卡在哪一步，他是决策者，还是只能提供事实？

这些一开始都只是猜测。沟通的任务，就是拿真实信息把猜测改掉。AI 可以帮你提前演练，但不能把它生成的人物画像直接套到客户头上，更不能因为模型说“此人倾向求稳”，你就真把人家当成项目阻力。

![文章配图](https://immilesma.com/blog/developer-to-fde-communication/media/04-image-08.jpg)

真正有用的问题，往往也不复杂。少问“你觉得这个功能怎么样”，多问“最近一次是怎么做的”。

“最近一次查错制度是什么时候？”

“当时是谁发现的？”

“发现以后怎么处理，耽误了谁？”

意见很容易礼貌，经历更接近事实。顺着一项刚刚发生过的任务往下走，你才能摸到真正的流程、成本和责任。

![文章配图](https://immilesma.com/blog/developer-to-fde-communication/media/05-image-06.jpg)

一场客户沟通，我通常会盯住五件事：最近一次真实任务怎么发生，哪一步最慢或最容易错，不解决会造成什么影响，谁能提供样本、谁承担改变后的风险，以及谁能决定先拿一个小场景继续验证。

听完不要急着上方案，先复述你听到的内容。

>

我确认一下。目前资料能够搜到，真正卡住的是不同版本没人敢确认。第一阶段需要业务 Owner 先给出有效版本，对吗？

客户纠正你的过程，本身就在降低项目风险。沟通结束时，双方至少要对事实、分歧和下一步留下同一个版本。否则会议里气氛再好，回去以后也可能各自理解、各自开工，最后一起返工。

## 谈判的本质，是把条件讲出来

客户说“两周必须上线”，程序员容易走两个极端：要么为了拿项目先答应，要么列出十个技术风险，把客户怼回去。

这两种反应都省事。一个把风险推给未来的自己，一个把推进项目的责任推给客户。

更稳妥的说法是：

>

两周可以完成一个场景的离线验证，条件是本周三前拿到脱敏样本和答案依据。进入生产还需要身份权限、安全评审和回滚方案，这部分现在不能一起承诺。

这不是话术。你只是把范围、周期、依赖和风险摆到了同一张桌子上。**不要只回答“能不能”，要把“什么条件下能、做到哪一步、谁要投入什么”讲完整**。

![文章配图](https://immilesma.com/blog/developer-to-fde-communication/media/06-image-05.jpg)

价格和合同主要由商务团队负责。技术 FDE 要讲清交付范围、成本、依赖、风险和验收边界，商务再结合客户关系、竞争和合同条件谈价格。FDE 不需要一个人包办全部商务，但也不能躲在“我只负责技术”后面乱给承诺。

这也是为什么，表达能力不是让你变成一个能说会道的人。它最终是在保护项目：该答应的答应，该加条件的加条件，该拒绝的拒绝，还要让对方知道你为什么这么判断。

## 每天拿出 20 分钟，把嘴练起来

很多人问我，表达应该看什么书。我的建议是，书可以看，但别再把“学习表达”变成下一项只输入、不输出的任务。

口才、表达和沟通其实是三件事。口才解决能不能顺畅说出来，表达解决能不能组织清楚，沟通负责拿到新信息并推动行动。看《金字塔原理》可以学结构，看《SPIN 销售》可以学追问，看《The Mom Test》可以提醒自己少问观点、多问过去发生的事。可书看完了，嘴不会自动跟着长出来。

每天的练习不用切成一堆精确到分钟的动作。拿出一段完整的 20 分钟，挑当天真正遇到的一个问题，围绕它反复讲就够了。

先对着手机讲一次。不要写逐字稿，纸上只留“事实、判断、下一步”三个词。讲完以后，试着把同一个内容缩成一句话，再换成一段能在会议里讲清的版本。核心判断不要变，只调整信息量。

接着换一个听众。假设坐在对面的是老板、业务负责人、一线使用者或者 IT，再讲一遍。老板关心结果、投入和风险；业务关心流程和验收；一线关心会不会增加操作、出错怎么办；IT 关心数据、权限、稳定和维护。换了四种角色，说法却几乎没有变化，说明你还没有站到对方的责任里。

![文章配图](https://immilesma.com/blog/developer-to-fde-communication/media/07-image-02.jpg)

剩下的时间可以让 AI 扮演一个难搞的客户。你可以直接用这段提示词：

```
你是我的 FDE 表达与客户沟通教练。

请从老板、业务负责人、一线使用者、IT 安全、采购中随机选择一个角色，
不要提前告诉我你的隐藏目标、担忧和决策权限。

项目背景：[填写脱敏后的行业、场景和当前问题]
本次目标：[我希望确认的信息或下一步]

请按以下规则和我对话：
1. 一次只说一句话或问一个问题，不要主动配合我；
2. 可以含糊、质疑、打断、压周期，或者用“回去研究”回避；
3. 我堆技术名词时，追问它对业务结果有什么影响；
4. 我替客户作判断、过度承诺或没有追问证据时，当场指出；
5. 对话结束后，从结论、清晰度、倾听、追问、角色理解、边界和下一步七项评分；
6. 只指出最需要改的两个问题，并让我立刻重说一遍。

不要编造真实客户数据，也不要因为我是练习者就降低难度。

```

练完以后回看录音，只抓当天最明显的一个毛病。可能是语速太快，句子太长，“然后”“就是说”太多，结论放得太晚，或者讲完没有下一步。把最差的那一段重新说一遍，这 20 分钟才算完成。

别一次给自己改十个问题。改得太多，通常只会给明天放弃训练准备理由。**一天只纠正一个毛病，但一定要开口，一定要重说**。

## 不用等练好了，有机会就上去讲

我不建议先关在房间里练一个月，再去找真人。真实表达不是考试，没有“准备完毕”这一刻。

公司里有分享就报名，开会时有一段你能讲清的内容就主动讲，线下活动可以提问就站起来，朋友愿意让你过一遍业务流程就去聊。也可以直接拍视频、做直播、参加一次小型闭门会。**先把这一次讲完，回来再看哪里没讲清**。

![文章配图](https://immilesma.com/blog/developer-to-fde-communication/media/08-image-04.jpg)

现场和练习最大的区别，是别人不会照着你的脚本反应。他可能突然打断，可能追问一个你没准备的问题，也可能礼貌地点头，实际根本没听懂。这些不舒服的瞬间，才是表达真正开始变好的地方。

做自媒体同样是一种上场。每次只讲一个具体问题，用“发生了什么、我是怎么判断的、下一步怎么做”把内容说完。不要每次都写百科全书。播放量未必立刻变好，但评论和私信会告诉你，外面的人究竟听懂了什么。

有机会就讲，也要看场合。FDE 没必要在每场会议里抢话、靠输出刷存在感。项目需要判断、澄清和推进时，你能站出来把关键话说清楚就够了。说完了，再听别人怎么反应。

## 练表达，最后还是为了把生意和交付接起来

销售和客户获取确实是 FDE 的生命线。没有客户，所有模型选型都是纸上谈兵。但这不代表程序员转型以后，必须一个人兼任销售、商务、产品、研发和交付。

更现实的团队里，商务负责关系、价格、合同、采购和回款；FDE 负责客户发现中的技术判断、方案范围、交付成本、风险和验收；工程团队和 AI 承接大量实现、测试与文档工作。关键方案和对外承诺，由双方一起确认。

单子多起来以后，编码可以交给 AI、同事或外包。**客户上下文、关键判断、生产责任和最终验收不能一起外包掉**。项目结束后，FDE 还要把现场验证过的方法带回研发后台，变成下一次项目能更快修改、更快交付的资产。

知识越来越便宜，程序员也确实习惯白嫖文档、开源项目和 AI。以后真正能收费的，很难再是一套名词解释。方案审查、客户模拟、项目纠错、第一单陪跑、企业培训和联合交付，卖的是判断与结果。

程序员的技术底子没有作废。只是代码能力必须往外再长一层：能把问题问出来，把技术讲清楚，把不同角色拉到同一个下一步，再把承诺做成生产结果。

**别再用学习下一门技术，逃避走到人面前**。

我是 Miles，一名从大厂转型 FDE 的 AI 算法专家，做过模型优化部署，也做过企业内部沟通与培训。我也在练习把技术能力变成客户听得懂、愿意采用并能够持续使用的结果。

![文章配图](https://immilesma.com/blog/developer-to-fde-communication/media/09-image-07.jpg)

关注我 @miles_mazy ，后面我会继续把 FDE 的沟通、表达、商务协作、技术交付和 AI 实操一项项拆开。**一起成长，一起赚钱。**

---

[在 X 查看原文](https://x.com/miles_mazy/status/2087861557611110733)