暂无搜索历史
我上一篇关于 FDE 的文章认为,系统思维——而不是原始的编码速度——才是区分"交付持久产品"的 FDE 与"交付慢慢腐烂的 demo"的 FDE 的关键。有人...
更难的问题是:你能不能把一个模糊的业务问题,发现真正重要的东西,设计出技术上可信的系统,并把权衡讲得足够清楚,让工程主管和客户都信任你去构建它。
几年前,当有人说 Forward Deployed Engineer(前向部署工程师,FDE) 时,大多数人会立刻联想到 Palantir 这样的公司。
一个面向生产的系统设计案例,涵盖客户调研、异步推理、Google Cloud 架构、AI 安全、评测、可靠性与成本。
写一段CRUD代码,是确定性工作。写一个SQL查询,是确定性工作。写一个单元测试,是确定性工作。
三问法(System of Record Cost of Inaction Day 2)
AI时代的影响:被AI替代的风险中等。如果你的技术容易被AI替代(比如CRUD开发),那这条路越来越难走。但如果你在"AI替代不了"的领域(比如底层系统、安全、...
下一篇预告: FDE系列18:技术人的四条路——深技术专家/FDE型/管理者/超级个体
如果系统宕机1小时,公司损失100万。你让系统从99.9%可用提升到99.99%可用,每年减少宕机时间8小时。你为公司避免了800万的损失。
传统售前方案:"我们使用最新的计算机视觉技术,结合多光谱遥感数据,通过深度学习模型实时识别病虫害,精准喷洒农药。"
开发工程师最常见的思维模式:"功能交付"——需求来了,我写代码,功能上线,任务完成。
向量数据库选型:Pinecone(云原生)/ Milvus(开源)/ Weaviate(混合)
客户的数据永远是脏的、乱的、不完整的。 用模拟数据验证通过的方案,一上真实数据就崩。
Palantir提出了一个概念叫"Delta"——产品原厂能力与客户需求之间的鸿沟。
客户说出来的需求:客户认为的"解决方案"客户真正的需求:客户想解决的核心问题客户不知道但需要的:客户没想到,但能带来更大价值的方案
如果说FDE的工作方法是一套操作系统,那"技术落地五步法"就是这个操作系统的内核。
专业能力:你懂不懂?可靠性:你能不能说到做到?亲近度:你和我是不是"一路人"?自我导向:你是为了自己,还是为了我?(分母,越小信任越大)
客户的原话:"我们想提升客户体验。"这个词——"客户体验"——可能是技术人最怕听到的词之一。因为它太模糊了。"客户体验"到底是什么?是响应速度更快?是界面更好看...
FDE(我):"好的。我先了解一下你们现在的客服流程。你们现在每天有多少客服工单?"
某门店周末有大型促销活动,销量会暴涨3倍,但系统不知道。某门店门口在修路,客流量下降50%,但系统也不知道。