FDE要不要自己写代码？动手边界在哪

这个问题背后其实藏着两种焦虑：技术出身的人担心自己变成只会开会的人，业务出身的人担心自己因为不会写代码进不了这个门。两种焦虑都有道理，答案在中间：FDE 必须能动手，但动手不等于全部自己写。

一、为什么必须能动手

现场的判断需要快速验证。客户说「我们的物料编码有规律」，你如果只能记下来带回公司排期，两周后才知道这个规律有二十个例外，那这两周就白等了。能动手的人当场跑一段脚本，半小时就知道真相。

更重要的是话语权。在客户的技术人员面前，能打开终端跑出结果的人，说话分量和只会画流程图的人完全不同。这种信任无法靠头衔换取。

所以门槛是明确的：会读数据、会写脚本、会调接口、会搭一个能点的界面。不需要是架构大师，但必须能独立走完从想法到演示的闭环。

二、什么时候该停手

现场写出来的东西，本质是验证品而不是交付品。它证明了路走得通，但没有考虑并发、权限、异常处理、长期维护。这时候就该停手，把需求整理清楚交回产品团队做正式版本。

很多 FDE 在这一步栽跟头——原型跑通后客户说「这个就挺好用，直接上吧」，然后一个临时脚本变成了生产系统，三个月后没人敢碰。

判断标准很简单：这段代码要不要有人在半年后维护。要，就必须走正式流程；不要，临时方案完全可以。

现场代码的使命是回答「行不行」，不是回答「稳不稳」。混淆这两件事，代价往往在半年后才付。

三、AI 工具改变了这条线

过去要写脚本得会一门语言，现在借助编程助手，业务出身的人也能在半小时内跑出一段数据分析。这条门槛实实在在被拉低了。

但降低的是动手门槛，不是判断门槛。工具能替你写代码，替不了你判断这段数据能不能信、这个字段业务上到底代表什么、这个结果是不是幸存者偏差。

所以未来 FDE 的能力结构会更偏向：业务理解占四成，判断与设计占四成，纯编码只占两成。这对业务出身的人其实是好消息。

四、阿优至简的视角

我们做中小企业项目，动手能力的要求反而更高——因为客户那边通常没有技术团队接得住。你不能说「把这个字段导出来给我」，得自己去数据库里捞。

但我们同样坚持一条：凡是要长期跑的东西，都不用现场临时方案。现场跑通的逻辑会重新用规范方式实现，并且交给客户一份能看懂的说明。这一步多花两三天，能省掉后面无数次半夜的电话。

落地前的三条至简建议

1. 先练闭环：确保自己能在半天内独立完成一次「取数—分析—演示」，这是入场券。
2. 先划红线：明确哪些代码是验证用、哪些必须走正式流程，写进项目规范里。
3. 先补业务：技术出身的人，把补业务知识的优先级排在补新框架之前。

会写代码不是 FDE 的充分条件，但不会动手一定当不了 FDE。真正稀缺的，是知道什么时候该动手、什么时候该收手。