akakidz

“没事,后面让 AI 重构”——这到底是敏捷开发,还是偷懒?

  •  
  •   akakidz · 1 day ago · 2411 views

    以前做复杂业务系统,需求阶段通常会反复调研,把业务流程、状态、权限、异常场景等尽可能确定下来,甚至建好表再进入开发。

    现在有了 AI ,有些复杂模糊的概念和流程,以前会反复拉会,必须拿到结果才能继续往下推,现在 AI 的速度那么快,有时候变成了: 需求没完全想清楚没关系,先让 AI 做一版,模糊的概念让 AI 偷偷敲定了,后面需求明确了或者明显有人提出了不对,再去改。

    简单项目、MVP 我觉得没什么问题,快速试错本来就是优势。 但复杂的业务系统这么干,会不会把“需求没想清楚”变成了“先做出来再说”?

    尤其是 ERP 、CRM 、审批、财务这类系统,一旦数据库结构、接口、权限和业务流程确定下来,后面的重构成本可能远高于前期调研。

    我目前公司里的项目中,已经遇到了流程的某个业务节点,反复修改到业务代码很难去手动维护的地步。

    所以想讨论一个问题:

    AI 降低了开发和试错成本之后,复杂业务是不是也应该从“先把需求想清楚再开发”,变成“先做一版再迭代”?

    还是说:

    “后面让 AI 重构”本质上只是项目经理把原本应该自己解决的需求分析问题,偷懒转嫁给了开发?

    大家实际项目里现在存在这个情况吗?


    本文经过 AI 润色优化

    20 replies    2026-08-12 23:28:57 +08:00
    Eba
        1
    Eba  
       1 day ago
    哪哪都是一个巨大的草台班子,人和项目有一个能跑就行。
    就算拿 AI 开发,10 个人也有 10 个想法。
    现在我公司还有人把代码片段复制给网页豆包改代码,甚至有些功能还不会做。。。
    muooOOO
        2
    muooOOO  
       1 day ago
    把 “不清晰的需求,先让 AI 做一版” 变成 “不清晰的需求,先让产品用 AI 敲定”。
    calmbinweijin
        3
    calmbinweijin  
       1 day ago
    公司越大,最下方个人的能力也就要求越低
    spike0100
        4
    spike0100  
       1 day ago via iPhone
    是现状。
    akakidz
        5
    akakidz  
    OP
       1 day ago
    @muooOOO 只能甩锅用,我觉得重构成本变得越来越小,需求侧普遍变懒了。
    mgcnrx11
        6
    mgcnrx11  
       1 day ago
    后面让 AI 重构”本质上只是项目经理把原本应该自己解决的需求分析问题,偷懒转嫁给了“未来”
    Sundayz
        7
    Sundayz  
       1 day ago
    是的,但是研发不要焦虑,留存好证据以后甩锅就好了。
    bgm004
        8
    bgm004  
       1 day ago
    “没事,后面让 AI 重构”(但是别让我干)
    huigeer
        9
    huigeer  
       1 day ago via Android   ❤️ 1
    放下个人情怀,享受缺德人生
    nice2cu
        10
    nice2cu  
       1 day ago
    需求不清晰 写出的代码后面肯定不可控了
    kooze
        11
    kooze  
       1 day ago
    是敏捷偷懒
    winnerczwx
        12
    winnerczwx  
       1 day ago   ❤️ 2
    这就是两种不同立场人的思维模式在打架

    开发觉得我要一步一个脚印 把每个系统 每个模块都做到尽善尽美, 因为后面出了问题还得我来擦屁股

    产品 营运觉得我要尽快把功能上线, 我要给用户给领导一个交代, 所以功能只要满足当下需求就行 后面的事后面再说

    不过有一说一 现在用 ai 来重构的成本确实比以前小了很多
    darksword21
        13
    darksword21  
    PRO
       1 day ago
    后面让 AI 重构?那请现在把所有功能的自动化测试做全,不然后面肯定没法重构
    fe619742721
        14
    fe619742721  
       1 day ago
    AI 时代软件形态可能又要变化了,主贴里的先实现再重构可能是一个前奏,以后可能重构都不需要了,有需求了再开发新的就是了

    以后可能不会有规模化的设计好的软件产品了,每个人都可以直接让 AI 输出当前需要的功能,用完就扔,下次遇到新需求再生成新的
    whileFalse
        15
    whileFalse  
       1 day ago
    这跟 AI 有啥关系,不用 AI 的时候也是先做出来再优化啊。
    Beliver
        16
    Beliver  
       1 day ago
    换个角度思考这个问题:每个人都想给自己争取利益,产品的最大利益是什么? 是能够向上对老板交差就行,代码写的怎么样,人家压根就不关注;程序员的最大利益是什么,代码好不好维护,质量怎么样,后续别坑我.....;
    所以你提的这个问题跟 AI 不 AI 没啥关系,成年人的世界,看的都是利益,大家关注的重点压根不一样,自然就没有人会去考虑你的立场。
    uxstone
        17
    uxstone  
       1 day ago
    敏捷开发本身也是一种偷懒
    evilHa
        18
    evilHa  
       1 day ago
    开发角度肯定是要先确定再搞,bug 少。

    产品角度就不是了,先产品上线,试错,积累用户。不成就撤了,成了就哪块功能最吸引用户就多搞哪块。
    akakidz
        19
    akakidz  
    OP
       1 day ago
    @whileFalse 不用 AI 的时候,牵扯多部门、多角色的复杂业务,一般会尽可能把场景调研清楚。部门之间存在差异的地方,也会尽量先拉齐再开发。
    现在 AI 把开发和修改的成本降低了,变成了:先分别满足各部门的需求,大家都用起来,等数据入库了,再回头翻库表、查代码,慢慢把各部门的业务逻辑拉齐。
    甚至先拉齐两个部门,跑几个月,再把另外几个部门的业务接进来,等业务满足不了了,再继续推翻重构。

    问题是,这时候系统已经有真实业务数据了,以前开发的时候 在第一版就该解决掉的问题,现在硬拖到问题暴露了再解决,以前只听说大厂因为迭代快会这样,现在我们这小公司的业务也频繁有这种情况了
    irvinghua
        20
    irvinghua  
       1h 21m ago
    楼主可以翻一翻《软件工程》教科书
    你说的是软件工程里面的瀑布模式和快速原型模式优劣之争,不是啥新鲜事
    About   ·   Help   ·   Advertise   ·   Blog   ·   API   ·   FAQ   ·   Solana   ·   1560 Online   Highest 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 47ms · UTC 16:50 · PVG 00:50 · LAX 09:50 · JFK 12:50
    ♥ Do have faith in what you're doing.