部门去年接手的一个零配件供应商门店系统，赶工期上线，大量使用了 AI coding 后交付使用了
上线后直到现在，大大小小的问题从来没有间断过，感觉越来越改不动了
继续改的人力成本非常大（因为早前没有时间仔细 review 代码），用 AI 改烧 tokens 很厉害，而且经常改了这里，牵动别的地方。另外，AI 还有一个坏习惯，喜欢无端增加很多 corner cases 的预防设计，越改越复杂
由于这个系统的实用价值越来越高，接下来要考虑是让 AI 重头重写一次吗（去年用的时候 AI 智能还不能和今天的能力相比，差比较大），还是继续屎山雕花？
上线后直到现在，大大小小的问题从来没有间断过，感觉越来越改不动了
继续改的人力成本非常大（因为早前没有时间仔细 review 代码），用 AI 改烧 tokens 很厉害，而且经常改了这里，牵动别的地方。另外，AI 还有一个坏习惯，喜欢无端增加很多 corner cases 的预防设计，越改越复杂
由于这个系统的实用价值越来越高，接下来要考虑是让 AI 重头重写一次吗（去年用的时候 AI 智能还不能和今天的能力相比，差比较大），还是继续屎山雕花？
67 条回复 • 2026-09-23 13:00:21 +08:00
 |
1
zishang520 5 天前
让 AI 重写啊
|
 |
2
Ryanzlab 5 天前
直接重构
|
 |
3
koloonps 5 天前
为什么不尝试人工写,非要 ai 写.你是确定这个系统不会长时间运行下去吗?to b 系统新增需求的时候实施产品开发不需要三方先商量下需求的吗,纯 ai 写到时候你完全不知道内部是怎么实现的怎么对接需求?
|
 |
4
106npo 5 天前 via Android
抽出 api 定义和测试，直接 clean room 重构
|
 |
5
sn0wdr1am 5 天前  7
这个时候，你就会遇到一个问题：
1. 改好，重构好，是应该的。 2. 改出问题了，还不如原来的，还得背锅。 总结就是：改好了没功劳，没改好完犊子。 |
 |
6
lemonshuo 5 天前
还的都是之前的技术债
还是需要人工介入 review 代码 我现在游戏后端 一些大需求 ai 写完后没有仔细 review 后面 bug 逻辑问题 再让 ai 改 又会影响到其余的功能 之后只能自己再从头到尾 review 现在代码还是黑盒 虽然能力强了不少 但自己不看一遍 还是有一些小问题的 |
 |
7
duanxianze 5 天前
继续 AI 啊，以前的 AI 太蠢了，让现在的 AI 重写
|
 |
8
gitlight 5 天前
openai 的建议是 tick-tock 。4 天推进，1 天重构。保持定时重构的习惯，人为地给系统注入熵减
|
 |
9
evolighting 5 天前
@koloonps 其实，真要说的话，所谓 AI 大模型当然可以对接需求，只是，为了所谓 AI 大模型的实现的 bug 买单的还是你自己。
最后还是要人工介入，无论是人工审核还是手写关键逻辑。 毕竟感觉对于公司来说， 雇佣一个人而不是外包给，无论是外包公司还是所谓的 AI 大模型编码代理，不就是为了让你来承当对应的责任，处理问题，和背锅的吗（ |
 |
10
firefox12 5 天前
我以为只是我用不来， 比如一个功能 完成 90%了 最后那点 怎么改都不对，改了几次 发现过去对的已经被删除了。
|
 |
11
Timzzzzz 5 天前
重写你不还是用 AI 写 lol
|
 |
12
HongJay 5 天前
是的，重写就能修复
|
 |
13
jacketma OP 楼上的兄弟说的没错，重写也会用 AI ，一方面是现在 AI oneshot 的能力比之前弱智时期强很多，让现在的 AI 改之前的弱智时期的 bug ，成本并不低；另一方面是这个项目的实用价值比较大，主管的意思要增加人对系统的掌控度。现在出了问题很大程度上是在猜可能是哪里有问题，猜对了能较快修复，猜错了定位问题都好久，修复时间都估不准，这么累积下去快要失控了
|
 |
14
antipro 5 天前
利用 AI 重新整理项目中的 feature ，然后人工审核，加入相关的规约要求，再重开一个项目新写吧。
|
 |
15
Reficul 5 天前
有了 AI 之后，代码腐败的速度比之前快多了。重构？没有覆盖完整的 E2E 的情况下重构分分钟死给你看。
|
 |
16
WashFreshFresh 5 天前
重构不过是新的屎山，维护一段时间后又失控，到时候模型更厉害，你难不成再重构吗？
|
 |
17
zuokanyunqishi 5 天前
你凭啥觉得,让 AI 重构不会又是一轮屎山堆呢,程序员本身的软件工程能力只会在 AI 放大下加强.不会无中生有....
|
 |
18
NizumaEiji 5 天前
多写单测 大范围重构+替换呗
|
 |
19
Gu0Qiang 5 天前
定期让能力更强的新模型重扫上下文、推翻重写，本质上就是把重构成本打下来了。哪家科技公司不重构？过去不重构往往不是不想，而是技术债堆到改不动、没人愿意接盘。AI 如果能把推倒重来的边际成本降到足够低，重构就会变成常态。
|
 |
20
op351 5 天前 2
项目中有维护对应的业务，架构，功能演进，开发坑的文档吗，类似 code wiki 的那种？
实测中大型项目有 code wiki 的话，ai 改起来会顺很多，token 消耗也会减少 |
|
21
koloonps 5 天前
@evolighting 人工写的目的不是为了背锅,是为了有人能够知道这个系统到底有多少功能.不然到时候你还要搞个知识库来查询.
|
 |
22
icebay 5 天前
先整理出问题，想好方案再让 AI 改，该合并的合并，该重新实现的重新实现，按模块一个个来。
当 AI 反复做不好某个点的时候，就表示你需要重新整理了。 |
 |
23
qiaobeier 5 天前
不知道重构一个成熟的中小型项目要烧多少钱的 token ，1000 美元打得住吗？
|
 |
24
sumu 5 天前 1
这个太简单了
把《重构》这本书看一遍，用书中的技巧即可。 至于重写，呵呵，这么说吧，如果你没能力用重构把一个屎山清理干净，你重写，也不会有不同的结局，屎山也是一步步有序的堆起来的。 |
 |
25
waterfish88 5 天前
两条线同时进行吧，一组改 BUG 一组进行重构
|
 |
26
Bootis 5 天前 2
只要不是超大体量的 repo,按照这个方法论进行 ai coding 基本都是可控的： https://openai.com/index/harness-engineering/?utm_source=chatgpt.com
https://developers.openai.com/cookbook/articles/codex_exec_plans |
|
27
jacketma OP @op351 只有最早期的需求文档，还是比粗颗粒的那种，code widi 想都别想了，主要是开始觉得这个项目是个辅助系统，零配件供应商可能不一定会大力使用，最后凉了就算了。开发也是交差的心态，结果领导觉得也能用，现在反而成了主力系统，体质不好跳重担就不行啊
|
 |
28
Felldeadbird 5 天前
数据库结构你已经定了，接下来 API 化，让 ai 写文档，构建规范。提升复用方法。
|
|
30
jacketma OP @Felldeadbird 这也是目前少有的不变量，开始建表的时候研讨了很久，数据库结构一直没怎么大改，才有改代码的想法
|
 |
31
ajaxfunction 5 天前
不可能了，ai 和手机一样，你没用过的时候也不觉得有什么。
一但你用过了，就再也离不开了，手写几行代码就会觉得浑身痛苦 |
 |
32
molvqingtai 5 天前
需要有 spec
|
 |
33
roundgis 5 天前 via Android
说白了 AI 的使用成本开始超过人工了
|
 |
34
Bunnyranch 5 天前
AI 重构完事了。
>AI 还有一个坏习惯，喜欢无端增加很多 corner cases 的预防设计，越改越复杂” 这个可以用指令预防呀 |
|
35
op351 5 天前 1
@jacketma 可以让 ai 先写 code wiki ，初期 token 消耗会比较大，因为所有的文件都要读一遍，但会有利于后面的开发
code wiki 让 AI 写也很简单的，类似于一个结构化的树形 readme 可以先有一个父入口的 readme ，然后按功能或者页面切分多个文件夹，文件夹内再写 md 格式的说明文件,文件之间通过相对路径做引用 |
 |
37
clemente 5 天前
搞好 用户层面的 ci/cd 全场景覆盖 再重构
|
|
39
evolighting 5 天前
@koloonps 背锅其实就是负责这个意思的调侃了。就算完全丢给所谓 AI 大模型来做所有工作，我甚至觉得某种意义上其实和全都丢给外包一样，不过是可以实时沟通，实时调整需求，而且绝对不会拒绝（只需要加钱烧 token ）的外包。
最后，当然可以说， 项目设计，项目管理也交给所谓 AI 大模型，那就会回到最终的那几个问题上了，既然都可以视作外包，那经营模式其实就是另一套东西了。 |
 |
40
xubeiyou 5 天前
用 ai 重构就行 其实也得看你们怎么用 ai
|
 |
41
THESDZ 5 天前 1
先按照穿透开发，给它建立好 约束，自动化测试，用例等。然后再考虑重构的问题。
|
 |
43
freemoon 5 天前
AI 是辅助编程，设计这方面还得你主导，你只给需求其他都不管，那肯定就变石山了。
|
 |
44
nicegoing 5 天前
数据结构还是得你来设计。我发现 ai 很喜欢加状态变量，提一句需求，就加一个变量。但是很多状态是互斥的，有些状态是可以由已经存在的状态组合的。ai 一直向上堆屎山，大力出奇迹，刚开始没事，堆多了最后 ai 自己都丢三落四了。人可以根据状态之间的联系，用枚举，排列组合做减法，直接就减少了一堆无用的兜底代码。
|
 |
45
layxy 5 天前
说白了现在的 AI 开发堆逻辑只能到一定阶段让他重构下，否则越堆越多，人是没办法维护的
|
 |
46
pony2335 5 天前
@Bunnyranch 有这样的规则？
|
 |
47
LittleOrangeCat 5 天前
这不是 ai 问题，只是 ai 加速了这个进程。我之前那公司五年的 rn 代码，改一处测多处，你以为人写的就好了？
|
 |
48
dirstart 5 天前
搞一个 skill ，然后基于这个 skill 重构
|
 |
49
egan0606 5 天前 2
向上反馈，AI 时代，这是要付出的成本以及代价； 上头认可， 就重构，不认可，就继续堆； 遇到有问题就解决问题， 不好解决， 就一直解决； 年轻人， 不要既要又要， 也不要让自己去承担无谓成本 ；
|
 |
50
V2Try 5 天前 via iPhone
重构，一方面是 AI 更强了，另一方面是你对项目的理解也更深了，知道哪些痛点和教训。
|
 |
51
zlo309618100727 5 天前
反正业务需求确定，就重新用 AI 写，进度还快些。
|
 |
52
guguphoenix707 5 天前
重写吧。保留测试用例，AI 看 AB 版本差异
|
 |
53
aleimu 5 天前
opencode2 重构时都说了,一件事要干三遍才算真的干明白了
|
 |
54
mengdodo 5 天前
自食苦果
|
 |
55
FishLotte 5 天前 via Android
继续用 Ai 写吧，毕竟去年的 Ai 跟今年的 Ai 相比差的太远了。
|
 |
56
kinghly 5 天前 via iPhone
能力问题而已。水平低的用 AI 做的项目基本属于能用级别。
|
 |
57
zsyevan 5 天前
1. 如果有 PRD ， 将 PRD 纳入 git 管理，没有就先重新梳理 PRD
2. 集成测试按照 PRD 来一套 3. claude code 的 simplify , review 按照模块挨个来 5 遍。 4. 再基于 PRD 复核 代码实现是否一致， 来个几遍。 5. 没事在用 astra ，fable review 下代码 6. 阿里 出了 open code review ， 也来个几遍。 差不多可以了。 |
 |
58
ddhYr 5 天前
业务梳理清了吗，测试用例有了吗，你重构有人和你一块吗
|
 |
59
chitanda 5 天前
你应该把用的哪个 ai ，什么时期去写的发出来。现在 AI 之间的差距比人还大，而且随着时间迭代更是夸张
|
 |
60
lozzow 5 天前
5.2 的代码让 5.5 重构,5.5 的代码让 6 来重构,至于 6 的代码,你就等 7 来重构
|
 |
61
yidinghe PRO 想要赚钱就得继续投入，这个道理都不懂吗。先让 AI 分析问题，如果能不动数据库设计，就重构，否则考虑重写。
|
 |
62
akira 5 天前
先让 AI 梳理现在 系统的现状， 形成 相关 技术架构文档，技术详细设计文档， 数据库设计文档，需求文档 等等。 当然了，AI 时代了， 这些文档一定是 md 格式的， 并且最好用 llm wiki 之类的结构来存。
然后就可以安排 AI 开始进行重构了， 先分析问题，形成重构需求， 再安排 AI 逐个进行重构 验证。 其实就是把重构需求 视为 一个普通的开发任务，让他自己去折腾就是了 |
 |
63
nuo7mi7 5 天前 via Android
上线后直到现在，大大小小的问题从来没有间断过
这个没有对应 qa 人员测试吗，虽说有 ai 但是该有的质量流程还是得有啊，既然没有那就不能要求没问题，所以公司省钱那都是有代价的 |
 |
64
chemzqm 4 天前
该扔就扔，该重做就重做
|
 |
65
iorilu 4 天前
对 ai 来说永远是从头做最简单
|
 |
66
ykb8121 4 天前 1
和我们类似，内部赛马，疯狂先用 AI 搭 MVP ，一旦客户认可，立马开始重构。基本上就是先污染，后治理的逻辑。用最低人力成本商业化试错（压榨），所以现在这个阶段是时候重构/重写了。
新建工程可以把老项目也放进来，作为业务参考依据，然后先定新项目的工程约束、目录结构，内部规范、依赖等等。 推荐下 https://github.com/walkinglabs/learn-harness-engineering/tree/main 资料。 初始化好 harness 环境，定好 AGENTS.md 、feature_list 、program.md..../docs/design-docs/ 下补好各种设计文档，甚至外部源码的库。 再加上一些评估标准之类的，形成个闭环，剩下的功能一项项补吧，祝好运。 |
 |
67
qfdk PRO 我也有这个 问题 但是 opus 5.5 睡觉的时候已经重构了 还测试了 删掉了 里面屎山一样的注释. 。做了拆分..... 值得尝试
|
• 请不要在回答技术问题时复制粘贴 AI 生成的内容