首页 注册 登录
V2EX = way to explore V2EX 是一个关于分享和探索的地方
现在注册 已注册用户请 登录
• 请不要在回答技术问题时复制粘贴 AI 生成的内容
V2EX › 程序员

探讨一下使用 AI 开发和维护大型项目的经验

ktyang · 2025 年 12 月 29 日 · 3640 次点击

最近在尝试使用 AI 来构建一个比较大型的工程,用了几个 Agent 分别扮演设计、编码、测试、审核的角色,开发了一段时间以后感觉非常的力不从心,对整体项目的掌控感越来越差,感觉随时都有可能会在我预料不到的地方爆炸一下。想请教一下大家有没有什么好的想法或者思路呀。

38 条回复 • 2025年12月31日 11:07:21 +08:00
4ark
1
4ark 2025 年 12 月 29 日 ❤️ 1
设计、编码、测试、审核有在项目内产出完整的文档吗?能否随时切换到人工维护的状态。可以使用 speckit/openspec 这类工具
OC0311
2
OC0311 2025 年 12 月 29 日
我觉得 AI 写的项目只能 AI 维护了,并且时间长了 AI 也没法维护了
maichael
3
maichael 2025 年 12 月 29 日 ❤️ 2
因为你"管理能力不足",你可以把 Agent 的想象成一个黑盒,输入需求,输出代码/文档,至于里面是人工智能还是"人工"智能其实无所谓,本质上你就相当于管了一个小开发团队,你兼职了项目管理+产品管理+团队管理,你要以"管理"的思路去优化整个开发流程。
defunct9
4
defunct9 2025 年 12 月 29 日
去死噻,根本无法维护,弄半天跟头蠢驴似的,提示半天,方向不对,努力白费,浪费一堆 token
craftsmanship
5
craftsmanship 2025 年 12 月 29 日 via Android
@defunct9 模型不行/prompt 准备工作没到位
现在的 LLM 已经可以写得比大部分码农要工整规范了
justdoitzZ
6
justdoitzZ 2025 年 12 月 29 日 ❤️ 2
感觉一定要做好文档管理,模块化管理,不断分阶段总结和记录形成文档。让 AI 知道这些项目的进度和架构,不然过一段时间,就一团糟了。解决完了一个疑难问题也要总结形成经验文档。
defunct9
7
defunct9 2025 年 12 月 29 日
擦,写一堆的 prompt ,比代码还复杂
winglight2016
8
winglight2016 2025 年 12 月 29 日
用了几个 Agent 分别扮演设计、编码、测试、审核的角色————这一步毫无意义,升级模型比优化 prompt 更有效。

现在感觉能用的首选 gemini3 ,其次 codex5.2 ,其他的都没法用。
ktyang
9
ktyang
OP
2025 年 12 月 29 日
@4ark 都有文档产出,但是不能保证都非常完整。而且文档数量也已经很多了。我先去学习一下你说的工具,非常感谢〜
sentinelK
10
sentinelK 2025 年 12 月 29 日
1 、扮演角色有什么目的吗?
2 、是否有节省上下文的针对性设计?
3 、期待的交互模式是什么?全自动?半自动?还是开发人员驱动?
4 、"大型项目"有多大?
5 、你用的什么 AI 模型与工具?
ktyang
11
ktyang
OP
2025 年 12 月 29 日
@maichael 本质上管了一个小开发团队这个是接受的,LLM 是无法做到人那样会对自己的工作有长期的上下文并且去负责任的,现在的问题是该如何提升这种管理能力呢?
ktyang
12
ktyang
OP
2025 年 12 月 29 日
@sentinelK 1.主要就是尝试把不同的工作解耦出来,试图增加掌控力。2.这方面可能欠缺比较多,欢迎给出一些建议哈。3.期待的交互模式半自动吧,其实自己也没有想好,最初的想法就是看了 openai 的那个分享想尝试一下能做成什么样子。4.现在还没有那么巨大哈,ROS 相关的目前有十几个模块吧。5.codex 、antigravity 、claude code 都有。
skyemin
13
skyemin 2025 年 12 月 29 日
几个 agent 之间怎么交互,通过文档吗?
jacketma
14
jacketma 2025 年 12 月 29 日
要做到一次性全命中还是非常难的,至少要保证能看得懂 AI 的代码逻辑,后续还有修改的空间。如果人工已经很难参与进去了,那就变成黑箱屎山,没救了
wwhontheway
15
wwhontheway 2025 年 12 月 29 日
一开始就搞几个 agent 没必要吧,感觉复杂化了。
sentinelK
16
sentinelK 2025 年 12 月 29 日
@ktyang
有没有一种可能,垂直形态的工作分工才是 AI 驱动编程的更好方式?(逻辑复杂度低,上下文长度小,成果人工审核难度不大)

没有上下文边界(比如有详尽文档就不要直接接触代码),半自动没有开发介入,且横向分工的结果就是最后就是压到后面的工序积累的误差爆炸。导致整个项目的正确产出没有任何的统计学优势。

最终结果必然就会不稳定。
fulln
17
fulln 2025 年 12 月 29 日
不要生成脱离掌控的代码,及时回正。 只要不符合代码规范的及时让 ai 改写
fulln
18
fulln 2025 年 12 月 29 日
但是 注意的是, 既然 ai 驱动了, 就不要手动去改了,效率低到让人发指。 让 ai 去改就效率高很多
duuu
19
duuu 2025 年 12 月 29 日
真的很难。我使用 opus4.5 ,重构一个前端老项目里的一个大页面,大概一万行代码都写在一个文件里。上下文严重超出,AI 无法读完全部代码,最后重构完丢失了很多功能细节。

ai 拆分功能,一个功能一个功能做,最后生成了 80 多个文档,导致你发现问题的时候很难找到对应哪个文档。
想写自动化测试,用 AI 写测试代码,要跑通也花费大量的时间和 token 。。

我的流程是:AI 阅读代码->出改进文档->根据文档优化代码->提交代码->AI 审核 git 记录优化是否合理,是否有遗漏。结果每次审核都发现遗漏。

当然如果让人来做,读一万行代码也是个灾难。。
v2tex
20
v2tex 2025 年 12 月 29 日
v2tex
21
v2tex 2025 年 12 月 29 日
thevita
22
thevita 2025 年 12 月 29 日
因为你不是在用 AI 提效,是想逃避困难,AI 能把已知的算法写得比你好,你应该把更多精力放在真正关键的挑战上,想想业务,想想系统该怎么设计,现在成了: 有个问题搞不定了,扔给 AI 吧,还是搞不定?搞个 Agent ,如果还是搞不定就整个更复杂的 Agent
v2tex
23
v2tex 2025 年 12 月 29 日
@v2tex 放弃发图了,

简要来说就是要给项目一套全局信息,AST 类似人类的 DNA 或者容器的 dockerfile ,代码只是 DNA 解析的产物,可以随时放弃
bearbest
24
bearbest
PRO
2025 年 12 月 29 日
我的经验是作为 AI 的项目经理,不需要纠结实现的细枝末节,但是需要掌控项目架构,并在使用 AI 创建项目甚至后续迭代过程中严格引导 AI 遵循当前的架构设计。禁止非必要的不符合架构设计的逻辑实现。

在开发新特性/修复缺陷/重构逻辑的时候,不是一股脑儿地把整个项目给 AI ,而是选择性地添加相关的文件作为本次对话的上下文。
zjsun
25
zjsun 2025 年 12 月 29 日
宝子们加油,我等着抄你们作业🤪
guiyumin
26
guiyumin 2025 年 12 月 29 日
1. 自己读代码
2. 经常读代码
3. 遇到要重构的,立刻要求重构
4. 测试,亲自测试
mooncakeSec
27
mooncakeSec 2025 年 12 月 29 日
不讲提效,只从维护的角度,经常重构,让代码清晰,让你可以理解逻辑,看不懂就重构
Amareni
28
Amareni 2025 年 12 月 29 日 via Android
你直接把这个问题发给 AI ,让它给你一个你能指导它完成的方案。努力把自己解放出来......
ZztGqk
29
ZztGqk 2025 年 12 月 29 日
用 llm 的首要原则是,"慢就是快,快就是慢",一定要解耦分步骤。
MrVito
30
MrVito 2025 年 12 月 29 日
@ktyang 不是很赞同,关于长期的上下文,可以通过落地到文档中来解决,毕竟正常开发人员,一两个月以后也不一定记得住自己当时写的代码逻辑。负责任就更不用说了,毕竟开发人员会离职、被裁员,还需要交接,LLM 可以一直干。
cabing
31
cabing 2025 年 12 月 29 日
分小块,每次都要落地到稳定中,管理稳定。越到所有的问题都分解。。不过这样有点烦。
aarontian
32
aarontian 2025 年 12 月 30 日
系统设计+文档管理是核心,本质上是配合 agent 做上下文管理,通过文档保证 agent 在不同需求中行为的一致性。花里胡哨的东西没什么用

我感觉 vibe coding 对系统架构能力的要求比以往任何时候都要高,因为 AI 没有人的主观能动性,它会沿着你设计不好的路径持续劣化

屎山如果不是完全没法救的那种,可以多尝试重构,不过也有风险就是了
ktyang
33
ktyang
OP
2025 年 12 月 30 日
感谢大家的回复呀〜
@sentinelK 当然有可能了呀 我也是在探索嘛 感受到要失控所以来请教一下大家
@fulln 改肯定是 ai 去改了,就是审阅和理解的过程究竟还要不要做呢
@v2tex 感谢分享,我也有这种感觉,但是当前感觉表达还是很不稳定的。
@guiyumin 读不过来了,硬逼着自己读的话感觉自己的能力已经是瓶颈了。
@mooncakeSec 哈哈哈哈 感觉越往后越灾难了
@Amareni AI 说的很有道理,但是好像问题更复杂了
@ZztGqk 唉 做起来就被 AI 拖着狂奔起来了
@MrVito 文档随随便便就几十个出来了,维护它们又变成新问题了,目前应对这种复杂性还没有做到比较好的权衡。
@cabing 尽量去控制吧,确实很烦,烦到好像我自己写都比我说一大段话要舒服。
@aarontian 是的,我也有这种感觉。在开始做的时候很多内容想不清楚,随着做起来问题就更多了。文档管理我尝试去努努力,有什么推荐的参考么?
zzxCNCZ
34
zzxCNCZ 2025 年 12 月 30 日
写项目要拆分啊,一步一步来。很多人觉得 ai 不行的误区是,老想着使用 ai 重构整个项目,或者一下把整个模块就完成了,这不扯淡嘛。
mooncakeSec
35
mooncakeSec 2025 年 12 月 30 日
open spec 我觉得是一个比较好的文档管理方式,至少不会到处拉屎
kasusa
36
kasusa 2025 年 12 月 30 日
我的项目都是小项目。 维护的话其实也挺好维护的,因为现在 AI 工具直接写出来的项目就是比较有条理,文件也都比较分开。

而我只需要专注提需求和测试需求就行了。
版本保留的话可以直接靠复制文件夹或者是 git
iamnotcodinggod
37
iamnotcodinggod 2025 年 12 月 30 日
理想主义的话,我觉得是 TDD 。

把测试提前写好,看测试代码是否符合需求。

然后就是放手让 AI 写实现。不用在意细节怎么处理,让 AI 一顿折腾最后能过测试用例就可以。
yanyiming
38
yanyiming 2025 年 12 月 31 日
我感觉 ai 盛行的时代, 个人更要提高自己的架构和产品能力, 牢固把握大方向.
关于 · 帮助文档 · 自助推广系统 · 博客 · API · FAQ · Solana · 2793 人在线 最高记录 6679 · Select Language 创意工作者们的社区 World is powered by solitude VERSION: 3.9.8.5 · 39ms · UTC 13:29 · PVG 21:29 · LAX 05:29 · JFK 08:29
♥ Do have faith in what you're doing.

AltStyle によって変換されたページ (->オリジナル) /