没事,后面让 AI 重构——这到底是敏捷开发,还是偷懒?
以前做复杂业务系统,需求阶段通常会反复调研,把业务流程、状态、权限、异常场景等尽可能确定下来,甚至建好表再进入开发。
现在有了 AI,有些复杂模糊的概念和流程,以前会反复拉会,必须拿到结果才能继续往下推,现在 AI 的速度那么快,有时候变成了:
需求没完全想清楚没关系,先让 AI 做一版,模糊的概念让 AI 偷偷敲定了,后面需求明确了或者明显有人提出了不对,再去改。
简单项目、MVP 我觉得没什么问题,快速试错本来就是优势。但复杂的业务系统这么干,会不会把“需求没想清楚”变成了“先做出来再说”?
尤其是 ERP、CRM、审批、财务这类系统,一旦数据库结构、接口、权限和业务流程确定下来,后面的重构成本可能远高于前期调研。
我目前公司里的项目中,已经遇到了流程的某个业务节点,反复修改到业务代码很难去手动维护的地步。
所以想讨论一个问题:
AI 降低了开发和试错成本之后,复杂业务是不是也应该从“先把需求想清楚再开发”,变成“先做一版再迭代”?
还是说:“后面让 AI 重构”本质上只是项目经理把原本应该自己解决的需求分析问题,偷懒转嫁给了开发?
大家实际项目里现在存在这个情况吗?
---
本文经过 AI 润色优化
---
原文链接:[点击查看](https://www.v2ex.com/t/1233424)
现在有了 AI,有些复杂模糊的概念和流程,以前会反复拉会,必须拿到结果才能继续往下推,现在 AI 的速度那么快,有时候变成了:
需求没完全想清楚没关系,先让 AI 做一版,模糊的概念让 AI 偷偷敲定了,后面需求明确了或者明显有人提出了不对,再去改。
简单项目、MVP 我觉得没什么问题,快速试错本来就是优势。但复杂的业务系统这么干,会不会把“需求没想清楚”变成了“先做出来再说”?
尤其是 ERP、CRM、审批、财务这类系统,一旦数据库结构、接口、权限和业务流程确定下来,后面的重构成本可能远高于前期调研。
我目前公司里的项目中,已经遇到了流程的某个业务节点,反复修改到业务代码很难去手动维护的地步。
所以想讨论一个问题:
AI 降低了开发和试错成本之后,复杂业务是不是也应该从“先把需求想清楚再开发”,变成“先做一版再迭代”?
还是说:“后面让 AI 重构”本质上只是项目经理把原本应该自己解决的需求分析问题,偷懒转嫁给了开发?
大家实际项目里现在存在这个情况吗?
---
本文经过 AI 润色优化
---
原文链接:[点击查看](https://www.v2ex.com/t/1233424)
· 0 个赞
· 0 个赞
· 0 个赞
· 0 个赞
· 0 个赞
· 0 个赞
· 0 个赞