GoForum › 🌐 V2EX
问个关于 vibe coding 的问题
UnYu ·
2026-06-02 14:53 ·
0 次点赞 · 6 条回复
我目前正在做旧项目按功能维度迁移至 Vibe Coding 项目，已提前约定技术规范、架构约束等要求。 现有翻新执行流程：
- 借助 AI 梳理总结老项目单个核心功能点
- 基于总结结果罗列全部功能点
- 根据功能点制定迁移翻新 TODO LIST
- 依照 TODO LIST 落地迁移改造
目前有两个比较大的问题
- AI 梳理内容存在选择性遗漏
- AI 梳理、改造时容易漏掉配置化代码、第三方接口请求等隐性逻辑。 新架构规范与老旧代码冲突，AI 改造丢失原有功能 既定分层规范：拆分数据层与业务逻辑层，逻辑层禁止直接引入 RPC 、配置组件，仅依赖数据层；配置解析、原始数据处理全部收拢至数据层。 但老项目历史代码不规范，逻辑层直接耦合 Apollo 配置等代码。AI 重构时优先贴合新架构规范，直接删除违规依赖代码，未做逻辑迁移，造成原有业务功能失效。
这两个造成迁移阶段需要大量人工做功能验证、反复代码 Review ，人力成本偏高。 想知道各位大佬有没有做过翻新，有没有好用的技巧或者方式之类的，或者 Skills 之类的可以让这个过程更加精准之类 目前用的模型是 Codex 的 Gpt-5.5 High
6 条回复
@sentinelK 我老的项目是手搓的，目前组里汇总有统一的 aicoding 的标准，基于 superpower ，现在想整体改造成 ai coding ，是按照功能维度进行迁移的，迁移的过程都有使用 aicoding 的 skills ，如果需要我给完整的上下文的话，那么等同于我直接做个新项目那就不需要进行迁移了，现在是想减少整个功能重头开始的成本，改造的整体目的就是为了老项目后面 ai-coding ，就不会手搓了，因为如果直接再老项目上 ai-coding ，整体的效果和维护性，阅读性都很差，还有 ai 对历史功能的理解每次都要阅读全量代码了，本质是为了同一套标准，aicoding ，减少 token 的使用
Alwaysonline · 2026-06-02 15:23
我的操作是： 截老项目的图，直接给 Codex 先写，写完后再补功能。
目前测下来，还原度最高，而且可控。
@Alwaysonline 已经是让直接阅读老代码的整个项目了，前期也不考虑 token ，就是造，但是漏的东西太多了，效果比预期的差太多了，本来以为直接读老代码会好很多
添加回复
你还需要 登录
后发表回复
1 、你是一口气迁移还是分模块/功能迁移？是否提示 AI 进行充分的功能一致性测试？ 2 、无逻辑相关的代码本来就无法被梳理，是否给了充足的上下文能体现其逻辑？ 3 、不太懂楼主的“迁移至 Vibe Coding 项目”的概念，楼主既想 Vibe Coding ，又想不丢失“不规范的既定分层规范”。那这个改造的目的是什么呢？