AI 代码后面怎么维护,心智负担太大了

[cc9910]

ai 生成爽是很爽,但是数量太多了,每次阅读起来真的太累了
今天加了两个函数,回来一看,又多了 300 行,也不能说它错,因为字段检验,格式又是自己写的要求
本来立项的时候,规定一个文件最长就 400 行,现在都多余,无非是拆分一堆小文件,还不如一个文件两千行,省得点了
整个项目搞下来都几万行了
读是肯定要读的,不然后面报错,只能跟 ai 一起赌运气了,好累啊,难道要用 AI 控制 AI?

[yechentide]

降低耦合，限制 AI 的探索/修改范围

[rocmax]

spec driven development ，ai 生成的代码成本已经可以忽略不计，那么人应该从维护代码转为维护 spec 。代码由 ai 根据可验证的 spec 检查。

[midsolo]

公司把某些内部系统外包出去了，项目交付前负责验收的同事开始介入，在对代码进行验收审计时发现，外包人员用 AI 狂拉了 8w 多行源码......

他的心智负担很重，求他的心理阴影面积？

[apkapb]

按照 token 算，我大概有 10%-20%的 token 是用来让 AI 重构代码的

[lujiaosama]

别说代码了，每次看 AI 生成的文档，我都累得不行。GPT 生成的文档一大坨，读得头皮发麻。

[gumayusi]

让真人去查真人，让 AI 去查 AI 。谁污染谁治理，觉得 AI 有智商能编写代码的人，没理由觉得 AI 没智商维护代码。

[lujiaosama]

@rocmax 复杂度不会消失，只会转移。不读代码也得读文档，文档也不轻松。

[sir283]

Ai 写写小软件还可以，写那些成型的，还是算了吧，屎山堆屎山，最后直接爆了。

分享一下我用 Ai 写的软件：

免 ROOT 强力删除安卓系统内置垃圾软件： https://github.com/MrsEWE44/easyManager ，还有其它功能，详细在 GitHub 主页。

宇宙超级无敌音乐下载工具： https://github.com/MrsEWE44/musicDownload ，支持所有主流音乐平台的歌曲文件下载，支持无损下载，详细在 GitHub 主页。

[erwin985211]

如果你是最新的模型的话，我觉得完全不用特别担心，直接让 AI 查 AI ，你自己就化为测试视角，而不是去审查代码的视角，看看 AI 有没有把功能实现，如果你还要坚持现在的完全把所有代码都审查一遍，确实，心智负担会比较大

[CodeGou]

测试覆盖+AI 审查。

如果还有担忧说明测试覆盖的还不全面。还得继续完善测试范围和质量（基本这块也是 AI 来做了）

[mmz0717]

@gumayusi 看来大明王朝 1566 没少看啊

[zzNaLOGIC]

@rocmax 实际在生产项目上跑下来，并没有想象的那么美好。 规则和实际逻辑不匹配是常有的事情，甚至 spec 更难懂，在大型项目上甚至有些绕的匪夷所思，生怕人类看懂。 原先以为是 speckit 流程太复杂了，换成 openspec ，虽然人要干的事变少了，但是规则质量更差了。

[neuthself]

@mmz0717 哈哈哈，看到前两句的排版，也是想到大明王朝

[craftsmanship]

@mmz0717 这下不得不看了

[dandel1on]

@gumayusi 话是这么说，但是 AI 犯错造成损失 AI 可不承当责任

[archxm]

简单啊，多招几个程序员，多人审核，拆解任务

[skuuhui]

公司是你自己的吗？为啥操那么多心

[yifangtongxing28]

公司只给你了指挥 AI 写代码的钱，没给你挑 AI 错的钱


能找出来 AI 错误并修复的人，得精通古法和 vibe coding ，已经被干掉了。

[gkeeno]

只能说以前怎么维护屎山，现在就怎么维护

[gophlet]

因为大多数人用 AI 开发新项目都是井喷式产出代码，我觉得这种模式只适合 MVP 和功能边界清晰的小项目。想要持续迭代的话，还是结合 AI 渐进式开发比较好。