前期大量 AI coding 上线的项目，越来越改不动了，该重写吗？

让 AI 重写啊

为什么不尝试人工写,非要 ai 写.你是确定这个系统不会长时间运行下去吗?to b 系统新增需求的时候实施产品开发不需要三方先商量下需求的吗,纯 ai 写到时候你完全不知道内部是怎么实现的怎么对接需求?

抽出 api 定义和测试，直接 clean room 重构

这个时候，你就会遇到一个问题：

1. 改好，重构好，是应该的。
2. 改出问题了，还不如原来的，还得背锅。

总结就是：改好了没功劳，没改好完犊子。

还的都是之前的技术债
还是需要人工介入 review 代码 我现在游戏后端 一些大需求 ai 写完后没有仔细 review 后面 bug 逻辑问题 再让 ai 改 又会影响到其余的功能 之后只能自己再从头到尾 review
现在代码还是黑盒 虽然能力强了不少 但自己不看一遍 还是有一些小问题的

继续 AI 啊，以前的 AI 太蠢了，让现在的 AI 重写

openai 的建议是 tick-tock 。4 天推进，1 天重构。保持定时重构的习惯，人为地给系统注入熵减

@koloonps 其实，真要说的话，所谓 AI 大模型当然可以对接需求，只是，为了所谓 AI 大模型的实现的 bug 买单的还是你自己。
最后还是要人工介入，无论是人工审核还是手写关键逻辑。

毕竟感觉对于公司来说， 雇佣一个人而不是外包给，无论是外包公司还是所谓的 AI 大模型编码代理，不就是为了让你来承当对应的责任，处理问题，和背锅的吗（

我以为只是我用不来， 比如一个功能 完成 90%了 最后那点 怎么改都不对，改了几次 发现过去对的已经被删除了。

重写你不还是用 AI 写 lol

是的，重写就能修复

楼上的兄弟说的没错，重写也会用 AI ，一方面是现在 AI oneshot 的能力比之前弱智时期强很多，让现在的 AI 改之前的弱智时期的 bug ，成本并不低；另一方面是这个项目的实用价值比较大，主管的意思要增加人对系统的掌控度。现在出了问题很大程度上是在猜可能是哪里有问题，猜对了能较快修复，猜错了定位问题都好久，修复时间都估不准，这么累积下去快要失控了

利用 AI 重新整理项目中的 feature ，然后人工审核，加入相关的规约要求，再重开一个项目新写吧。

有了 AI 之后，代码腐败的速度比之前快多了。重构？没有覆盖完整的 E2E 的情况下重构分分钟死给你看。

重构不过是新的屎山，维护一段时间后又失控，到时候模型更厉害，你难不成再重构吗？

你凭啥觉得,让 AI 重构不会又是一轮屎山堆呢,程序员本身的软件工程能力只会在 AI 放大下加强.不会无中生有....

多写单测 大范围重构+替换呗

定期让能力更强的新模型重扫上下文、推翻重写，本质上就是把重构成本打下来了。哪家科技公司不重构？过去不重构往往不是不想，而是技术债堆到改不动、没人愿意接盘。AI 如果能把推倒重来的边际成本降到足够低，重构就会变成常态。

项目中有维护对应的业务，架构，功能演进，开发坑的文档吗，类似 code wiki 的那种？
实测中大型项目有 code wiki 的话，ai 改起来会顺很多，token 消耗也会减少

@evolighting 人工写的目的不是为了背锅,是为了有人能够知道这个系统到底有多少功能.不然到时候你还要搞个知识库来查询.

先整理出问题，想好方案再让 AI 改，该合并的合并，该重新实现的重新实现，按模块一个个来。

当 AI 反复做不好某个点的时候，就表示你需要重新整理了。

不知道重构一个成熟的中小型项目要烧多少钱的 token ，1000 美元打得住吗？

这个太简单了
把《重构》这本书看一遍，用书中的技巧即可。

至于重写，呵呵，这么说吧，如果你没能力用重构把一个屎山清理干净，你重写，也不会有不同的结局，屎山也是一步步有序的堆起来的。

两条线同时进行吧，一组改 BUG 一组进行重构