• Jxin
    2026-05-13 来自美国
    有 all api list 和 all er 图。生成基本也凉了。上下文直接爆炸。 要反复偿还上下文膨胀导致指令偏移,带来验证的压力。 所以后来。我把 all api list 和 all er 图 直接拿掉,每个需求就去扫需求相关的 api 和 模型就好。这样切分只要需求小,加载的内容就小。上下文就小,生成质量就高。 感觉到现在,生成的东西,其实都不是企业级老项目喂给 AI 的上下文。而是喂给人的。。。确实方便人理解了。但并不适合 ai 每次生成代码时的上下文。。。 但如果还是要喂给人,其实提效就很有限。。。ai 生成是快,人理解可跟不上。人的理解能力就是整个迭代的瓶颈了。提效的只是获取知识的速度。约等于有个差不多 80% 了解项目的专家给你嚼碎了讲。 感官上,这个例子其实算不上企业级的老项目哦。 就这个例子,其实纯 vb 效果也会很好,因为现在的 ai 很聪明,啥 sdd 都不加,啥上下文都不加的话(知道就给,不知道出问题再说,系统复杂到一定程度,本来就穷举不全,通常也就把和资金相关,2c 黄金链路这一类比较敏感的盘明白就好)。

    作者回复: 确实是喂给人的。人看不懂,怎么兜底,人如果看不懂,怎么知道AI理解对。对存量项目,大家的问题是: 怕改出问题。 老项目改造的核心诉求一定是:改对,然后才是改快。 提效是核心诉求,但是永远不是第一诉求。第一诉求是改对。 不是这个例子的问题,课是想通过这例子,建立一套标准的对老项目的认知的流程,从而快速系统的建立初步认知。 “因为现在的 ai 很聪明,啥 sdd 都不加,啥上下文都不加的话(知道就给,不知道出问题再说” 这句话没问题,但是“出问题再说” 本来就是我们要解决的问题。现在大家都是出问题再说,所以每个人的改动效果都不一样,依靠的是个人能力,不是流程。 “提效的只是获取知识的速度。约等于有个差不多 80% 了解项目的专家给你嚼碎了讲。”我认可这句话,也是我认为AI 在老项目中最好的一个功能。 老项目开发兜底的永远是人。改出错了,AI没啥事,人可能要丢工作。所以最开始一定要建立的是人对老项目的认知,然后喂给AI,让AI尽量改对。然后自己能够check。而不是追求,AI 一把改了,提效几倍。而是改对的前提,尽量提效。另外,我认为这个流程后,在后续改起来会越来越快。

    
    
  • Geek_zclap3
    2026-05-14 来自广东
    如果项目太大,跑到一半上下文爆了,怎么处理?重跑一遍吗 【Autocompact is thrashing: the context refilled to the limit within 3 turns of the previous compact, 3 times in a row. A file being read or a tool output is likely too large for the context window. Try reading in smaller chunks, or use /clear to start fresh.】
    
    
  • 五毛仔
    2026-05-13 来自江苏
    大佬快更新,看完了
    
    