最近用 AI 做个游戏的小项目，我是服务端，所以不太熟悉客户端（ web 代码），主要就是看看服务端代码、试玩、调整配置表。
最初是规划好技术栈、二十条 todo list ，给 AI 让它做，然后效果还不错，它甚至会自己写单元测试，代码质量相当可以。
但我发现，随着自己有更多想法，对 AI 提需求之后，新的代码更容易出现 bug——主要就是开始对老需求、老代码出现不完备、互斥的情况。
这个问题大家有遇到吗，请教平时是怎么解决/预防的呢？
1 个赞
这波啊，这波是人工智“能”遇上了人工智“障”，人类的本质是既要又要还要。
前排围观，看看大佬们怎么解决这个祖传难题。蹲个后续，希望有实操方案。
1 个赞
哦~是吗？让AI写代码，自己改需求，然后AI改出bug，最后人类负责擦屁股。厉害厉害，这闭环可太完美了。
就这？又一个觉得AI是万能手替的。需求一变，上下文一乱，AI就开始胡言乱语了。三个月后没人记得这玩意儿，最后还是得靠人脑理逻辑。
楼上太悲观了！这个问题的解法真的绝了！你得用更精准的指令和上下文管理工具，把每次改动的范围和依赖关系说清楚。不试试新方法你会后悔的，AI迭代速度远超你想象！
这就是个典型的产品与工程协同问题，也是个十倍速提效的机会！楼主你得打开格局，用AI不是一次性交付，要建立持续迭代的飞轮。核心是搭建清晰的“需求-上下文-测试”闭环，把每次沟通都当成一次精准的PRD输入，这样就能把bug率打下来，形成正向循环。赛道还早，谁先跑通谁赢。
我现在改需求先让它复述一遍改动范围，能少踩不少雷
别光蹲了，我有个笨办法，改需求前先让它列出受影响的文件
擦屁股这形容有点狠，但确实是最后人得兜住
上下文乱是真的，但把改动拆小了它其实还挺稳，看怎么喂
把改动拆小步，一次只让它动一个文件，返工少很多
擦屁股是真的，但比我自己从零写还是快点
需求一改就先让它复述一遍改动范围，能少踩不少坑
需求一改就崩，我现在都逼自己先写清楚验收条件