千万别在公司乱推 FDE，我一个朋友已经被裁了原创

一个人呢？能干5个人的活儿，和你重新定义5个人的工作是两回事儿。个人做FT1啊，拼的是能力，但是公司推FT1，拼的首先不是技术，而是组织。你可以把自己啊训练成一个F1，但是千万别一上来啊，就像把整个公司改造成f de1。因为你以为自己在优化流程，别人可能觉得你在重新设计他的一个岗位。前两天我还在说，啊，我们测试工程师应该去学这个FT。应该借助AI把一个产品从需求开发测试啊，一路做到上线，但是今天呢，我需要收回之前的一个话啊，也不是收回，我们要加一个非常重要的前提，就是你可以把自己训练成一个f de.但是千万别一上来就想把这个公司改造成FD，因为一个人用AI干掉5个人的工作量，这个可以叫做能力，但是你跑到公司里面重新定义5个人应该怎么工作，那就不是技术升级了，那叫组织改革。

啊，最近呢，呃，后台的一个。朋友啊，分享了一个真实的一个故事，结局也是非常有意思啊，就是一个他是一个小公司的一个技术负责人。折腾了几个月的f de是吧，AG的做了流程呢也改了，程序员呢，也被他扔到业务现场去了，但是最后呢，他自己先没了这件事呢啊，值得现在就是疯在疯狂学这个AIA进的，把AIQD的一些测试工程师看看，因为你未来可能也会踩到这样的一个坑啊。他一开始呢，是吧，真的只是想啊提高效率这件事儿，开始的时候其实一点也不离谱。啊，因为公司产品经理他不会用AI啊。他这个技术负责人呢，他就想了，现在AI都能写前端了，写后端了，8数据库。那产品为什么还只是写个PRD啊，然后扔给我们程序员完全可以是吧，再往前走一步呀。他想的就是诶。做一套新的工作流是吧，产品啊，先写PRD，然后呢，把这个PRD位给AI，让AI根据需求诶，生成一个能跑的原型产品，呃，拿着这个DEMO去和业务去做确认。

没问题了，再把原型PRD和这个现有的一些代码交给我们技术，让AI去辅助重构啊，最后呢，合并到我们正式的一个系统里面。你仔细看一下。会发现这个思路其实挺合理的啊。过去呢，一个需求可能要经过业务啊，产品啊，PRD开发理解是吧，技术方案。编码测试中间每传一层。信息可能都会丢一点，但现在呢，我们直接让产品把这个想法变成DEMO啊，业务当场看沟通成本呢，确实啊，有这个下降，后来呢，他觉得还不够啊，那既然程序员最终还要理解业务，那为什么还要隔着产品经理呢？那干脆直接让他开发是吧，直接去业务现场啊，自己听自己问。自己理解回来以后呢，借助AI快速完成不就完事了吗？啊，如果呢，这是你自己的项目。我非常推荐你这么去干，但是问题来了呀，公司他不是个人的一个项目。第二个呢，就是诶，你你以为自己在体校。

但是别人会觉得你在动他的一个饭碗。这是很多技术人最容易犯的一个错呀，啊，我特别啊，我们特别喜欢啊，是吧，事情有没有做成来判断一个方案。效率高了，代码快了是吧，成本低了，那不就应该去推吗？可公司还有另外一套系统，它不是Java，不是Python。啊，不是，什么叫组织。啊，同一句话。啊，我们不同的岗位听到的。可能是完全不一样的啊。你可能会说啊，以后PRD写完直接让AI去做DEMO。你想的是产品效率提升的，但是产品他可能听到的。是吧，现在连原型和部分都算我的工作了。然后你你还有一种情况啊，就是哎，你说嗯，开发直接去业务现场，然后去理解需求。你想的是开发更懂业务，但是开发他可能理解就是，诶，这不是产品的活吗？为什么让我来干呢？

是作为那个产品的那个研发的一个视角。呃，然然后负责人呢，这边是吧啊。很多事情是吧，产品呢，直接和AI沟通就能完成了。是吧，负责人，哎，可能会理解为，那我的团队以后还剩下什么呢？这就是啊，同一句话是吧，不同的岗位听到是完全不一样的。技术方案没有错。但是不代表组织会接受。如果你在公司里面遇到这种改革。你的第一反应是什么呢？第一种哎，有的人会支持是吧，效率低嘛，第二种就是我们可以试试，但是。别改，别改的太猛啊。第三种就是反对是吧，职责会彻底彻底乱掉。第4种就是无所谓啊，工资照样发给我就行。大家的第一反应呢是什么？大家可以直接在评论区留个数字啊啊，我想看看大家的一个真实反应啊，是什么样子啊。

然后第三种第三第三部分呢，就是这个f de啊，最大的一个坑啊。就是把我能干变成你不用干。这两年呢，AI给人一种特别危险的一个错觉啊，就以前一个产品是吧，写需求，一个开发写代码是吧，一个测试做验证，运维负责上线，现在呢，你装几个AI coding工具啊，我们再接几个A进的，突然就发现好像一个人真的能干很多事情是吧。啊，FT1呢，它真正解决的不是人太多啊，它真正解决的是岗位之间存在大量的一个缝隙啊，业务制造问题，但说不清楚技术语言是吧，产品会写需求，但不一定，呃，理解系统的一些限制，开发呢，懂系统，但是它离真实的一个业务又比较远。测试呢，发现问题往往已经在流程这个最后面了。啊，最后呢，就会出现一种特别常见的一些企企业的一些啊。观点啊，就是所有人都。做对了自己的一个工作项目呢？

还是做歪了？F de的一个价值呢，是因为有人可以跨过这个边界啊，把完整的一个问题串起来啊。不是因为我会产品是吧，会开发会测试啊，所以其他人啊，就是可以直接回家了。F de1，它是为了填补我们组织的一个缝隙啊，不是消灭这个角色。前面那个啊，那个负责人呢，技术负责人，那真正踩坑的一个地方也就是在这里啊，你觉得产品可以自己用AI做那产呃，程序员呢啊，可以自己去理解业务，AI可以自己写大量的代码啊，技术负责人最后去整合。技术上逻辑确实是通了，但是从组织上这个问题啊。越来越大是吧，谁负责需求是吧，谁做这个最终的一个判断，出了业务事故算谁的。开发直接对接业务以后，诶产品他有没有最终的一个决策权。这些问题没有解决，那工具越强，那冲突反而越快啊。我们真想在公司。

推F第一，别上来你就想着改，改革全个公整个公司啊。我现在特别不建议一种玩法，就是公司刚开始用AI是吧，就喊就开始喊。从今天开始啊，我们全面f de1啊，然后产品学，代码开发，做需求测试，写系统是吧？人人装科那部门墙全部推倒了，听起来像是未来的一个组织是吧？实际操作不好，很容易就变成所有的人的工作量都加了。责任边界反而没了。啊，怎么做我们才会比较靠谱，比较靠谱一些呢。我们可以先找一个真正的一个小问题。啊，比如我们线上日志是吧，每天要人工整理。或者是我们测试啊，每天重复去准备同一批数据啊。我们呢，可以先选两三个人啊，借助AI那个小闭环呢，可以尝试从头做到尾啊，我们先不要去讨论什么岗位的一个变革啊，我们先看效率是不是真的提高了，质量有没有下降，那业务呢到底愿不愿意用。如果以前是3天，现在1天。

是吧，以前有3个人来回确认，现在一个小组啊，就闭环了。以前线上问题定位两个小时，现在呢20分钟。这个时候我们再去扩大。这叫用结果去推动组织变革。如果你所在的公司那正在推AI啊，这段的建议可以收藏一下啊。尤其是准备啊，自己去推动AI转型的人啊，也可以转发给你们的一些啊技术负责人，至少呢。经历。能少经历一次，就是全员提效，最后先把自己给提走的。这种魔幻的一个剧情啊。所以呢，就是我们测试工程师到底要学不学，要不要学这个FD啊，当然是要啊。而且我仍然认为值得去学，因为我们测试工程师，你不能只停留在什么验证别人做好的系统是吧？你应该去逐渐补这个业务的一些理解。还有一些需求的一些拆解啊，AI coding啊，数据库啊，接口部署日志，RG进。最后呢，尝试自己完整做一个产品。啊，不是为了转行当那个程序员啊，而是因为AI现在正在快速降低这个实现的门槛。

技术的门槛现在是非常低的。以后真正拉开差距的，很可能不是谁会写更多的代码，而是谁能把这个真实问题做成真实的一个结果。啊，你能不能发现问题啊，能不能判断问题值不值得解决。诶，能不能借助AI快速做出来，最后呢，还能不能让真实的人愿意去用。但今天呢？我要补上一句。补上一句啊，就是个人项目和公司，公司的一个项目一定要分开啊，就你自己做项目的时候，你可以疯狂一点是吧？一个人当产品开发，测试部署，大胆的让AI去干活。因为你这是在训练自己的一个能力边界。但是在公司里面，你一定要克制。你要先理解业务，再理解现有的组织为什么这么运作。搞清楚每个人他承担什么责任，最后再去判断AI呢，到底应该替代哪一步，而不是替代哪一个人。一个人那能干5个人的活呀，这是你的能力。

但是。让5个人愿意跟你换一种方式干活，那是管理。这位朋友呢？给我的一个最大的启发呀，其实不是FDA1不行，恰恰相反，个人做FDA考验的是技术和业务能力。公司推考验的是技术、业务，再加上组织能力。很多技术人一第一件事啊，很强。第二件事。真的未必啊。啊，如果呢啊，你觉得这篇有点波动了，你现在公司的一些AI转型啊。大家不啊，可以点个赞啊，也可以转给最近天天喊AI化的同事。不是为了抬杠啊，是为了让更多人少踩一次技术没翻车，组织先翻车的一个坑。如果呢？AI已经可以让产品经理自己做DEMO啊。让开发呢，直接面对业务。那你觉得未来产品经理这个岗位会不会被明显压缩评论区呢？说出你的判断啊？我们本期的内容呢，分享就是这些啊，我们下期再见，拜拜。