我目前正在做旧项目按功能维度迁移至 Vibe Coding 项目，已提前约定技术规范、架构约束等要求。 现有翻新执行流程：
目前有两个比较大的问题
这两个造成迁移阶段需要大量人工做功能验证、反复代码 Review ，人力成本偏高。 想知道各位大佬有没有做过翻新，有没有好用的技巧或者方式之类的，或者 Skills 之类的可以让这个过程更加精准之类 目前用的模型是 Codex 的 Gpt-5.5 High
 |
1
sentinelK 6h 55m ago
1 、你是一口气迁移还是分模块/功能迁移？是否提示 AI 进行充分的功能一致性测试？
2 、无逻辑相关的代码本来就无法被梳理，是否给了充足的上下文能体现其逻辑？ 3 、不太懂楼主的“迁移至 Vibe Coding 项目”的概念，楼主既想 Vibe Coding ，又想不丢失“不规范的既定分层规范”。那这个改造的目的是什么呢？ |
 |
2
UnYu OP @sentinelK 我老的项目是手搓的，目前组里汇总有统一的 aicoding 的标准，基于 superpower ，现在想整体改造成 ai coding ，是按照功能维度进行迁移的，迁移的过程都有使用 aicoding 的 skills ，如果需要我给完整的上下文的话，那么等同于我直接做个新项目那就不需要进行迁移了，现在是想减少整个功能重头开始的成本，改造的整体目的就是为了老项目后面 ai-coding ，就不会手搓了，因为如果直接再老项目上 ai-coding ，整体的效果和维护性，阅读性都很差，还有 ai 对历史功能的理解每次都要阅读全量代码了，本质是为了同一套标准，aicoding ，减少 token 的使用
|
 |
3
tengxun 6h 40m ago
参考旧代码,重新设计,重新 ai coding.然后每一步都留下文档,便于后续 ai coding 拓展,修改.不要想着旧代码改造了,旧的代码视野限制了 ai,不如让 ai 新写 完全参考旧代码的功能逻辑新写一份
|
|
4
UnYu OP @tengxun 已经搞了一周了，漏的东西太多了，现在本身有 aicoding skills 改动就会留痕，但是因为迁移一直会漏洞漏西，导致现在反而一直在查缺补漏，review 和 test ，其实我现在是有这个想法的，不如重新梳理流程，当新项目做估计要好很多😮💨
|
 |
5
Alwaysonline 6h 36m ago
我的操作是： 截老项目的图，直接给 Codex 先写，写完后再补功能。
目前测下来，还原度最高，而且可控。 |
|
6
UnYu OP @Alwaysonline 已经是让直接阅读老代码的整个项目了，前期也不考虑 token ，就是造，但是漏的东西太多了，效果比预期的差太多了，本来以为直接读老代码会好很多
|
|
7
Alwaysonline 6h 27m ago
@UnYu #6 我也试过阅读老代码，Codex 会很保守，效率特别低。
|
 |
8
1Tiger 5h 38m ago
@UnYu 天王来了都无解，太细的和强耦合的就是会漏，并且一次迁移很多 人为也会漏。。。 项目不是很复杂 并且源 prd ue 都在的话再参考老代码逻辑 完全 ai 重构重写 也比这样迁移快一些，有的细节漏就漏了，后续补充描述再补充
|
 |
9
AItsuki 5h 35m ago
我一直在尝试将老项目迁移到新框架，在对业务比较熟悉的情况下，使用 codex 迁移还真的没手动迁移快，我正准备使用最近挺火的一个 skills 仓库重试一次。https://github.com/mattpocock/skills
不过没有抱很大期望，尝试使用了几天发现它很喜欢照抄老代码。 |
 |
10
duuu 5h 31m ago
无解～能提升开发速度，但是测试速度降不下来。反而还需要更多的测试。
|
 |
11
miniliuke 5h 30m ago
对于老代码的迁移和改动感觉目前的 ai 还不是特别好
|
 |
12
liuliuliuliu PRO 如果是老项目，可以让 ai 先帮忙写测试，后续基于这个测试来验证
|
|
13
UnYu OP @liuliuliuliu 测试部分我有过大量的验证，不少的问题都是通过 ai 测试还有自己提供测试场景发现的，测试是没毛病的，主要是翻新，通过测试让他反改还是差不多的
|
 |
16
youthdou 5h 16m ago
最近干了一件类似的事，从一个开源项目中，提取部分前端代码，相关功能的后端代码，从 java 改成 c++，包括适配新的数据库，弄了 2~3 周的时间，边弄边在思考，AI 工具到底能不能提效。
|
 |
17
remarrexxar 5h 13m ago
先基于老项目产生 Unit test ，Integration test ，E2E test ，都先跑通，迁移后 AI 需要对照 Unit test ，跑通 Integration test 和 E2E test 。
|
 |
18
rokcy 5h 8m ago
不要让 AI 直接一口进行非常多的代码生成，这种方式基本都会出问题。除非是前期对需求、功能点、数据库等都确认好，才考虑让 AI 执行。 但是光这样 AI 还是很有可能遗漏，最好的方式是有配套的 SKILL 来进行结果的校验，包括 code review,功能点的测试等。
|
 |
19
yjxjn 4h 27m ago  1
无解。
针对老项目写的细节性东西，想要完全做到新旧项目完全对齐，截至现在来看不可能 基于 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%对齐，那需要大量时间打磨。 |
|
23
UnYu OP @remarrexxar 感觉也悬 测试反向的感觉 ai 该漏的还是会漏，很多用例也只是 ai 理解上的 test 感觉覆盖也很难，除非你列出所有场景
|
Select Language