一个困扰软件开发很长时间的问题似乎可以被 AI 解决了!

2026-04-11 13:161阅读0评论SEO资源
  • 内容介绍
  • 文章标签
  • 相关推荐
问题描述:

我现在激动得睡不着觉,虽然我刚刚搞完了毕业论文,因为我突然发现一件事情,那就是困扰了软件工程很长时间的软件回归问题似乎可以得到解决了。
​所谓软件回归(Software regression, wiki: Software regression - Wikipedia ),指的就是软件的一个功能在以前是好的,然后你和你的团队修改了其他的一些地方之后,这个功能就爆炸了。在现在的 AI Coding 时代,这个现象出现得非常频繁。每当你和 AI 说出一个新的需求,并且他将这个需求通过代码实现的时候,有的时候,其他的一些看似无关紧要的功能就突然莫名其妙地爆出 bug 了。出现这个问题的原因是很简单的,因为当软件工程复杂的时候,任何一个新的需求,它大概率都会和一些已有的原子功能存在上下游的依赖关系,而实现这个新的需求,就意味着可能需要修改这些。上游的原子功能,而这原子功能本身也有其他的下游依赖的,这些下游依赖的最末端就是那一个个你看似核心需求无关的功能点,那么当你实现这个新的需求,而需要修改这些叶子功能所有的公共原子功能祖先的时候,自然而然地就会发生崩坏的现象。
​通过我最新开发的锡兰这个需求管理平台,以及软件工程所积累的丰富的形式化方法论,再结合 AI 完成自然语言的语言对齐,我认为可以尝试去解决这个过去的难题了。因为这也是很多使用 vibe coding 来快速迭代软件的团队,在软件后期一定会遇到的问题,如果能把这个问题解决,这可太 sexual 了。

image1280×773 460 KB

网友解答:
--【壹】--:

醒了,看看情况先


--【贰】--:

所以你用这些架构在真实 vibe coding 生产中就完全避免这个问题了吗?(不是你来用,是团队里任意一个人随意开发)


--【叁】--:

呆呆,所以原理,步骤,方法,具体实现呢)

重点东西好像没提啊)


--【肆】--:

可以看一下claude code 源码,在快速迭代的情况下即使世界顶尖团队也很难不写出屎山,加一个小功能影响到上游的一大堆潜在问题。在巨大的商业利益下,所有的软件工程方法论都只能妥协。所以现在业界的方向也在不断投入全拟真的测试环境,用巨量的测试用例去做集测,类似汽车的路测,工业现在研究的世界模型这类。


--【伍】--:

可以公开使用了?


--【陆】--:

插个眼~


--【柒】--:

方法论呢


--【捌】--:

我也无法说明,等我的实践结果吧,而且我也没说我的方法会比这些方法好。欢迎理性讨论问题,一切以降本增效为主。


--【玖】--:

期待佬的后续进展


--【拾】--:

社畜苦于论文无从下手


--【拾壹】--:

改一点就改一片属于开发的不规范吧。MVC、DDD、TDD、BDD都是在尽可能避免这些问题,我不太理解你的方法论相比于他们的更优点在哪里,烦请解答一下


--【拾贰】--:

梦回大学软件工程课了


--【拾叁】--:

我从来没说 MVC/DDD/TDD 能完全避免回归问题,我的问题是你还没有解释你的方法论具体比它们好在哪。

“现有方法不完美”≠“你的方法更好”,这两个之间没有因果关系。你需要论证是:

  1. 现有方法具体在哪个环节失效了(是根本防不住,还是执行不到位?)
  2. 你的方法用什么机制解决了这个失效点
  3. 这个机制为什么是现有方法论无法覆盖的

你描述的场景——改公共原子功能导致下游崩坏——本质上是变更影响范围不可控。TDD 给你的是安全网(改完跑测试就知道了),DDD 给你的是限界上下文(跨域改动的概率降低了),它们都没说能"根治"回归,但都是在降低概率和加速发现。

如果你能说清楚"锡兰 + 形式化方法 + AI 对齐"具体在这个链条的哪个环节、用什么机制、做到了什么现有方法做不到的事,那我非常愿意认真听。但目前你跳过了"为什么更好",直接到了"能解决",这个中间缺少了太多东西了。


--【拾肆】--:

软工专业的我看着津津有味,期待佬友的更新


--【拾伍】--:

插眼插眼

问题描述:

我现在激动得睡不着觉,虽然我刚刚搞完了毕业论文,因为我突然发现一件事情,那就是困扰了软件工程很长时间的软件回归问题似乎可以得到解决了。
​所谓软件回归(Software regression, wiki: Software regression - Wikipedia ),指的就是软件的一个功能在以前是好的,然后你和你的团队修改了其他的一些地方之后,这个功能就爆炸了。在现在的 AI Coding 时代,这个现象出现得非常频繁。每当你和 AI 说出一个新的需求,并且他将这个需求通过代码实现的时候,有的时候,其他的一些看似无关紧要的功能就突然莫名其妙地爆出 bug 了。出现这个问题的原因是很简单的,因为当软件工程复杂的时候,任何一个新的需求,它大概率都会和一些已有的原子功能存在上下游的依赖关系,而实现这个新的需求,就意味着可能需要修改这些。上游的原子功能,而这原子功能本身也有其他的下游依赖的,这些下游依赖的最末端就是那一个个你看似核心需求无关的功能点,那么当你实现这个新的需求,而需要修改这些叶子功能所有的公共原子功能祖先的时候,自然而然地就会发生崩坏的现象。
​通过我最新开发的锡兰这个需求管理平台,以及软件工程所积累的丰富的形式化方法论,再结合 AI 完成自然语言的语言对齐,我认为可以尝试去解决这个过去的难题了。因为这也是很多使用 vibe coding 来快速迭代软件的团队,在软件后期一定会遇到的问题,如果能把这个问题解决,这可太 sexual 了。

image1280×773 460 KB

网友解答:
--【壹】--:

醒了,看看情况先


--【贰】--:

所以你用这些架构在真实 vibe coding 生产中就完全避免这个问题了吗?(不是你来用,是团队里任意一个人随意开发)


--【叁】--:

呆呆,所以原理,步骤,方法,具体实现呢)

重点东西好像没提啊)


--【肆】--:

可以看一下claude code 源码,在快速迭代的情况下即使世界顶尖团队也很难不写出屎山,加一个小功能影响到上游的一大堆潜在问题。在巨大的商业利益下,所有的软件工程方法论都只能妥协。所以现在业界的方向也在不断投入全拟真的测试环境,用巨量的测试用例去做集测,类似汽车的路测,工业现在研究的世界模型这类。


--【伍】--:

可以公开使用了?


--【陆】--:

插个眼~


--【柒】--:

方法论呢


--【捌】--:

我也无法说明,等我的实践结果吧,而且我也没说我的方法会比这些方法好。欢迎理性讨论问题,一切以降本增效为主。


--【玖】--:

期待佬的后续进展


--【拾】--:

社畜苦于论文无从下手


--【拾壹】--:

改一点就改一片属于开发的不规范吧。MVC、DDD、TDD、BDD都是在尽可能避免这些问题,我不太理解你的方法论相比于他们的更优点在哪里,烦请解答一下


--【拾贰】--:

梦回大学软件工程课了


--【拾叁】--:

我从来没说 MVC/DDD/TDD 能完全避免回归问题,我的问题是你还没有解释你的方法论具体比它们好在哪。

“现有方法不完美”≠“你的方法更好”,这两个之间没有因果关系。你需要论证是:

  1. 现有方法具体在哪个环节失效了(是根本防不住,还是执行不到位?)
  2. 你的方法用什么机制解决了这个失效点
  3. 这个机制为什么是现有方法论无法覆盖的

你描述的场景——改公共原子功能导致下游崩坏——本质上是变更影响范围不可控。TDD 给你的是安全网(改完跑测试就知道了),DDD 给你的是限界上下文(跨域改动的概率降低了),它们都没说能"根治"回归,但都是在降低概率和加速发现。

如果你能说清楚"锡兰 + 形式化方法 + AI 对齐"具体在这个链条的哪个环节、用什么机制、做到了什么现有方法做不到的事,那我非常愿意认真听。但目前你跳过了"为什么更好",直接到了"能解决",这个中间缺少了太多东西了。


--【拾肆】--:

软工专业的我看着津津有味,期待佬友的更新


--【拾伍】--:

插眼插眼