在现在想重构一个项目，是重写一份简单呢，还是慢慢重构简单呢

历史项目如果体积过大，用新语言的时候会重新组织结构，按模块迁移。至少我是这样的

用slint的话挺难的

现在还需要在乎架构吗，rust用得少但是我希望低占用，也想试试新鲜感

感觉整理功能重写简单，重构涉及到太多东西，AI又喜欢测试，导致重构用的时间比写还要长，我尝试过重大重构，一个任务都要磨蹭很久

我拿比较便宜的ai试着重构，感觉不理想，很多边界老是漏，不知道贵的会不会好点

看多大多重的项目了，太大太重的话感觉推倒重写会更好，就不会有历史包袱了

AI 迁移会自己脑补、猜测一些不存在业务逻辑，有时候只是一个运算符号的区别。如果你没有精力去测试、review 最好是保持现状。如果一定要迁移不要一次性进行大规模重构。从单页面、功能开始。

大项目建议重写,AI的上下文不够长,读代码也花钱,效率也不高

你可以单开一个对话,让AI先对旧项目进行分析, 功能清单,操作流程,数据结构,外部依赖这些,全部都整理好,然后重写规划好

再让AI重新开发

(重构还有个问题,AI可能会把旧项目的石山代码一起带进来,AI改功能,旧功能改过之后,没清干净,之后AI再读,上下文遗忘,AI:这怎么有个接口,是什么,最开始的项目书上好像有,那重新接起来吧)

已稳定运行的，承载大数据量，大量用户的工程化项目建议不要大刀阔斧的改，要逐步分离功能，慢慢重构上线，甚至推荐能跑就行，能别动就别动，如果是非核心项目就随便了，折腾！！

我用astra来重构，猛吃我额度，进度不见涨。小的重构还好说，大的重构要认真考虑是不是重写比较划算

旧的先留着,备份好,然后慢慢重写,有不对的,就用新开的对话让AI查一下,一定是第三方会话,不要污染上下文

太重就按照功能重写吧，重构成本太大了。上下文估计都吃不住。

我总感觉让他查会把原语言的坏写法带过来，原来那个项目是ts+electron，我试着让他看着改成rust，总感觉他就是把原来的搬过来改成rust的写法，有点头大

所以我说让第三方AI会话去查,然后你来比对验证,接着直接告诉执行重写项目的AI要怎么做,

三方AI会话,一个读原项目,一个重写新项目,一个比对新旧项目,前面两个是完全不接触,不进入对方的工作区,看不到对方的信息的,对比新旧会话的可以看到新旧项目,但严格要求只读,对比功能,审查,梳理要求,对比新旧项目的对话的结果,由你来手动发给重写项目的AI,直接给指令,让他做

就不会被旧项目污染

先解耦，然后派发重写，只给资料，不要给代码。测试不对就找到问题，然后更新提示词，从头再写。当给外包派活就行。

我现在觉得对各种高级语言、性能相关的追求，都是执念，我们或许可以把注意力放到别的更有开创性、新奇性的东西上。

他那个项目太肿了，然后一些技术债比较多，所以我想用比较好的架构和语言来重构，而且我也想试试rust