akakidz

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

  •  
  •   akakidz · 13 days ago · 3024 views

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

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

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

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

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

    所以想讨论一个问题:

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

    还是说:

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

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


    本文经过 AI 润色优化

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

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

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

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

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

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

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