AI越会写代码,FDE越要做减法

AI coding最容易让人上瘾的地方，是你的想法很快就能变成一个东西。

以前，脑子里冒出一个功能，你还得掂量一下：要改多少代码，花多少时间，会不会影响已有系统。现在，你把想法说出来，模型就开始实现。页面出来了，按钮能点了，新的能力也接进来了。

这种反馈很容易让人觉得，自己一直在向前走。

但我现在越来越看重一个问题：产品是在接近目标，还是只是在不断变大？

我正在做一个电商工具，当前只做自动上下架。这不是因为电商只有这一件事值得做，而是我得先守住这次开发真正要完成的事。

选品、定价、数据分析、内容生成，当然都有价值。可它们有价值，不等于它们现在都应该出现在这个产品里。

开发能力过剩，最先挤掉的可能是判断

我说的“AI开发能力过剩”，是相对于眼前的需求而言的：我们能够快速做出来的东西，已经超过了当前真正需要的东西。

技术难题仍然存在，模型也会写错代码。变化在于，很多想法已经不需要经过很长的等待，就能获得一个看起来像样的实现。

过去，开发成本会替我们挡掉一部分想法。一个功能要花很多时间，大家自然会讨论它有没有必要。

现在，这道阻力变小了。于是“有必要吗”很容易变成“反正很快，先做出来看看”。

先做出来一次，未必有问题。可每个想法都这么处理，产品就开始累积那些尚未证明必要的东西。

做电商工具尤其容易如此。如果顺着已有能力往外想，上下架之后可以接价格调整，价格之后可以接销量分析，数据有了，又可以做一个运营看板。

每一步都有理由，每一步似乎也不难。到最后，原本那个明确的任务，被许多“顺便”围住了。

开发速度越快，越不能省掉决定范围的那一步。

否则，我们会把“今天又做了一个功能”当成进展，却很少确认：用户最在意的那件事，有没有因此变得更好？

代码变便宜了，复杂度没有

一个功能的成本，并不在代码生成完的那一刻结束。

加进产品以后，它就会带来新的状态、测试、异常和维护。功能之间还会相互影响：修改这里，可能牵动那里。

用户也要付出成本。他得理解这个功能做什么、什么时候用，以及它和其他功能有什么关系。

比如，一个人打开上下架工具，想确认这次操作是否完成。如果页面上同时摆着趋势图、评分、推荐和十几个指标，他还得先从这些信息里找到结果。

那些信息可能都有价值，但在这个时刻，它们也可能挡住最重要的事情。

功能要证明自己的价值，也要承担自己带来的干扰。

所以，我不能只看AI写这个功能花了多少时间，还要看它进入产品之后，会占用多少注意力，增加多少维护，会不会让核心任务更难完成。

创造的快感，很容易冒充产品的价值

创造是有反馈的。

你想到一个东西，它出现了；你觉得这里可以更丰富，它就多了一块；你再改一下，画面又更完整了。对开发者来说，这个过程确实很有吸引力。

它比去问清楚一个业务问题，更容易得到即时满足。

问需求，可能发现别人根本不需要这个功能。做验证，可能发现一个漂亮的方案解决不了实际问题。真正跑业务，还可能碰到很多无法靠加一个按钮解决的限制。

相比之下，继续创造顺畅得多。

但开发者的满足感和用户的需要，不能放在同一个位置上。

用户来到一个上下架工具里，不会先关心我用了多少模型、写了多少模块。他首先要完成商品操作，知道结果是否正确，出问题时能不能处理。

如果核心操作还不可靠，我却在不断丰富周边页面，那我享受的是创造过程，产品目标反而被推后了。

一个新功能值得留下，应该因为它帮助用户完成目标，而不是因为我很喜欢把它做出来。

这是我现在要反复提醒自己的地方。AI把创造的门槛降下来了，决定什么值得创造，却仍然是我的责任。

先定目标，再决定哪些功能进入产品

所以，这个电商项目当前只做自动上下架。

这句话看起来很普通，但它能帮我挡住很多诱惑。一个新想法出现时，我先把它放回这个目标里，看看它究竟改善了什么。

它能让上下架结果更准确吗？能减少实际操作中的麻烦吗？还是只是让系统看起来更像一个完整的平台？

前两类值得继续研究，后一类可以先记下来。

我还会反过来问：如果拿掉这个功能，用户完成自动上下架会失去什么？是必要的正确性、效率和处理失败的能力，还是只是少了一块看起来丰富的页面？

这里要分清：范围小，不代表事情可以做得粗糙。

操作失败却显示成功，不能因为“第一版简单”就放过；商品匹配错误，不能用“以后优化”搪塞；必要的权限和结果检查，也不能为了少写代码删掉。

这些东西直接决定核心任务能不能完成，属于当前需求的一部分。

而选品分析、复杂看板等能力，需要有自己的真实问题和验证依据。今天没有这个依据，就不必因为模型能写，提前把它们带进来。

目标明确之后，功能才有判断标准。

同样一个功能，在一个项目里可能是关键需求，在另一个项目里可能是干扰。不能只讨论它“有没有用”，还要讨论它对当前目标有没有必要。

YAGNI和奥卡姆剃刀，帮我守住两种边界

这也是我重新看重两条老原则的原因。

第一条是YAGNI，You Aren’t Gonna Need It。它提醒我们，不要为尚未发生的需求提前建设功能。Martin Fowler对YAGNI的解释

它不是说未来的需求不重要，而是说：未来的可能性，还不能直接替代今天的需求证据。

比如，一个上下架工具未来可能服务更多人，也可能扩展到更多业务。这些方向可以想，可以记录，但不必现在就把每个方向对应的系统全部搭好。

等真实需求出现，再用新的目标判断。那时候加功能，依据会比今天的猜测清楚得多。

第二条是奥卡姆剃刀。我把它的简约思路用在实现选择上：满足当前需求的办法有几种，就优先选择更简单、容易理解和维护的那一种。

已经决定要解决一个问题，也不代表必须拿出最丰富的方案。已有能力能解决，就先复用；直接的流程能跑通，就不急着加很多中间层。

YAGNI帮助我决定哪些东西现在不做，奥卡姆剃刀帮助我把需要做的东西做得更简单。

这两条原则，都以理解问题为前提。不了解业务就砍功能，和不了解业务就加功能一样，都是在凭感觉做决定。

做减法的对象，是没有必要的复杂度。用户已经需要、系统正确运行必须依赖的能力，要完整保留。

FDE要管住的，是目标和结果

我理解的FDE，是进入真实业务、对交付结果负责的人。

在这个位置上，不能只追求实现能力。客户提出一个想法，除了知道怎么做，还要判断它解决什么问题，是否值得现在做，会不会把已有任务变得更难完成。

模型可以帮我迅速实现一个方案，也可以帮我分析和找反例。但最后，哪些东西进入产品，仍然需要我结合真实业务作判断。

我的开发流程也要服务这些判断。工具可以帮助实现和审查，但选了什么工具，并不能替我回答产品为什么存在。

工具可以换，这个原则不能丢。

我不会因为多接了几个工具，就自动获得更清楚的产品目标。也不会因为代码通过了审查，就证明每个功能都值得做。

代码正确、功能有用、产品目标明确，是几件需要分别确认的事。

工具越强，越应该把节省下来的时间用来理解真实问题、检查实际结果，而不是全部用来增加功能。

写在最后

我喜欢创造，也认可AI给开发者带来的自由。很多过去做不起、做不动的想法，现在终于可以尝试了。

但一个正在交付的产品，需要明确的目标。探索时可以展开想象，做产品时得知道自己要完成什么。

对我现在这个电商项目来说，目标就是自动上下架。先让这件事可靠地完成，再看真实使用中有没有新的需要。

后面该加的功能，我会加。只是它们得带着真实问题来，而不是仅仅带着一句“我们也能做”。

AI让创造越来越容易。FDE的判断，要让创造始终有方向。

如果你也在用AI做项目，想从“能写出来”走到“真正解决问题”，欢迎关注我的公众号**「维天说」**。我会继续分享自己的开发实践，以及从程序员走向FDE时，怎样判断需求、检查结果、把东西交付给真实用户。

想拿自己的项目练一次，可以在公众号对话框发送【资料】，免费领取《AI-FDE入门实践册》，里面有任务卡、验收记录和交接模板。先把“要解决什么、做到什么才算完成”写清楚，再开始加功能。

如果你正在做AI项目，或考虑转型FDE，也欢迎带着具体问题来交流。发送【微信】获取联系方式，或直接添加：weitian_shuo。添加时备注“公众号＋你的行业或岗位＋最想解决的一个问题”。