问个关于 vibe coding 的问题

1 、你是一口气迁移还是分模块/功能迁移？是否提示 AI 进行充分的功能一致性测试？
2 、无逻辑相关的代码本来就无法被梳理，是否给了充足的上下文能体现其逻辑？
3 、不太懂楼主的“迁移至 Vibe Coding 项目”的概念，楼主既想 Vibe Coding ，又想不丢失“不规范的既定分层规范”。那这个改造的目的是什么呢？

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

参考旧代码,重新设计,重新 ai coding.然后每一步都留下文档,便于后续 ai coding 拓展,修改.不要想着旧代码改造了,旧的代码视野限制了 ai,不如让 ai 新写 完全参考旧代码的功能逻辑新写一份

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

我的操作是： 截老项目的图，直接给 Codex 先写，写完后再补功能。

目前测下来，还原度最高，而且可控。

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

@UnYu #6 我也试过阅读老代码，Codex 会很保守，效率特别低。

@UnYu 天王来了都无解，太细的和强耦合的就是会漏，并且一次迁移很多 人为也会漏。。。 项目不是很复杂 并且源 prd ue 都在的话再参考老代码逻辑 完全 ai 重构重写 也比这样迁移快一些，有的细节漏就漏了，后续补充描述再补充

我一直在尝试将老项目迁移到新框架，在对业务比较熟悉的情况下，使用 codex 迁移还真的没手动迁移快，我正准备使用最近挺火的一个 skills 仓库重试一次。https://github.com/mattpocock/skills
不过没有抱很大期望，尝试使用了几天发现它很喜欢照抄老代码。

无解～能提升开发速度，但是测试速度降不下来。反而还需要更多的测试。

对于老代码的迁移和改动感觉目前的 ai 还不是特别好

如果是老项目，可以让 ai 先帮忙写测试，后续基于这个测试来验证

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

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

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

最近干了一件类似的事，从一个开源项目中，提取部分前端代码，相关功能的后端代码，从 java 改成 c++，包括适配新的数据库，弄了 2~3 周的时间，边弄边在思考，AI 工具到底能不能提效。

先基于老项目产生 Unit test ，Integration test ，E2E test ，都先跑通，迁移后 AI 需要对照 Unit test ，跑通 Integration test 和 E2E test 。

不要让 AI 直接一口进行非常多的代码生成，这种方式基本都会出问题。除非是前期对需求、功能点、数据库等都确认好，才考虑让 AI 执行。 但是光这样 AI 还是很有可能遗漏，最好的方式是有配套的 SKILL 来进行结果的校验，包括 code review,功能点的测试等。

无解。

针对老项目写的细节性东西，想要完全做到新旧项目完全对齐，截至现在来看不可能

基于 GPT-5.3-Codex 来说的，5.5 没实验过，但是我感觉大同小异。

而且还有个问题，你这个其实不算 vibe coding 了。

我给你个建议，也是我曾经翻新项目的经验。（不能说完全对齐，毕竟新系统比老系统功能丰富些，不太合理 UI/UX 都改了）

步骤：
1.梳理所有模块，比如让 AI 梳理生成 20 多个模块的 FDD 或者 PRD 文件夹，每个文件夹下有具体 feature 。（如必须 100%对齐，那就请仔细修改 FDD ，并强烈建议写详细设计文档，细节性东西必须写清楚）
2.建立树立开发规约和技术架构等等，也就是 AGENT.md
3.开始时，先让 GPT 实现一套简单业务流模块。然后人工 Review 并加以测试。包括 review 配置文件，第三方接口请求等等，第一个模块最费时间，最废 token ，然后补充 AGENT.md 内容。
4.根据已有的代码，再按照模块依次实现，依次 review(有详细设计文档的话，Token 消耗会大幅下降，可能也是命中缓存的缘故)
5.测试，完善 AGENT.md ；修改细节性东西。

其实最终发现，AI 节省的时间在实现，至于是否 100%对齐，那需要大量时间打磨。

@youthdou 给我的感觉就是，无论会不会，都会提效，但是细节性的东西，会消耗不少时间，尤其在你没有明确写好详细设计文档的情况下；

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

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

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

@UnYu ai 不会帮你想出所有场景，除非你在设计文档里明确写出，除非老代码 coding 时，同时期维护详细设计文档，才能提效，否则不能，ai 辅助编程给我最大的感受是，针对不懂得模块和业务，他写的蛮好，但是一旦你有明确业务和设计，他没人那么细，最终时间来看，可能省点编码的体力劳动。