UnYu

@remarrexxar 感觉也悬 测试反向的感觉 ai 该漏的还是会漏，很多用例也只是 ai 理解上的 test 感觉覆盖也很难，除非你列出所有场景

@rokcy 前期没有了迁移分了特别多的步骤和 TODO ，前期感觉效果还好，测试起来就发现太多问题了

@yjxjn #19 这样子的成本就太高了，那样子不如重新梳理流程然后当做新需求来做，成本更小而且更快

@duuu 确实，现在都是基本在测试验证，然后修修补补

@miniliuke 是的，目前迁移翻新的感受还是很直观的

@liuliuliuliu 测试部分我有过大量的验证，不少的问题都是通过 ai 测试还有自己提供测试场景发现的，测试是没毛病的，主要是翻新，通过测试让他反改还是差不多的

@Alwaysonline 已经是让直接阅读老代码的整个项目了，前期也不考虑 token ，就是造，但是漏的东西太多了，效果比预期的差太多了，本来以为直接读老代码会好很多

@tengxun 已经搞了一周了，漏的东西太多了，现在本身有 aicoding skills 改动就会留痕，但是因为迁移一直会漏洞漏西，导致现在反而一直在查缺补漏，review 和 test ，其实我现在是有这个想法的，不如重新梳理流程，当新项目做估计要好很多😮‍💨

@sentinelK 我老的项目是手搓的，目前组里汇总有统一的 aicoding 的标准，基于 superpower ，现在想整体改造成 ai coding ，是按照功能维度进行迁移的，迁移的过程都有使用 aicoding 的 skills ，如果需要我给完整的上下文的话，那么等同于我直接做个新项目那就不需要进行迁移了，现在是想减少整个功能重头开始的成本，改造的整体目的就是为了老项目后面 ai-coding ，就不会手搓了，因为如果直接再老项目上 ai-coding ，整体的效果和维护性，阅读性都很差，还有 ai 对历史功能的理解每次都要阅读全量代码了，本质是为了同一套标准，aicoding ，减少 token 的使用