用 Qoder 的 Repo Wiki 与 Skill，把老项目从"不敢改"做到自我迭代的实战指南
大家好！我是岳阳博，一名后端开发工程师。很高兴有机会和大家一起探讨：“在老项目中如何使用 Vibe Coding 进行编程”。
Qoder 的 Repo Wiki 可以帮助我们快速理解项目架构，梳理项目的调用关系，并生成详细的说明文档，同时，它还可以帮助团队培养新同事。
以往新同事入职，其实都有一个比较重的带教过程，而且这个过程是双向消耗时间的。一般是我先带他过一遍项目，做一个整体介绍，先建立基本认知；然后他再自己去看代码、看文档，到这一步还不够，后面还会反复来找我沟通、确认、答疑，经过多轮之后，才能对项目有一个相对深入的理解。
用了 Repo Wiki 之后，这件事情其实发生了一个变化。因为系统已经帮我们把项目梳理成了比较完整的说明文档，新同事一来，不再是先找人，而是先用 Ask 模式去“问项目”。大部分问题，其实在这一阶段就已经解决掉了，大概能覆盖 80% 左右。等他再来找我沟通的时候，带的已经是那 20% 更关键、更有针对性的问题。这样一来，学习路径就从“人带人”，变成了“先自助，再深度交流”。新同事上手更快，我们双方投入的时间也明显下降。
虽然已经对项目有了一定理解，但代码编写的问题并没有因此得到解决。最初，我的做法很直接——让 AI 去完成具体功能的实现。
AI 很快就能输出大量代码片段，但真正运行时，会发现其中存在不少漏洞和偏差。于是，我开始不断补充说明，对问题进行二次、三次，甚至更多轮的描述和修正。
然而结果并没有朝着预期发展，反而逐渐失控：代码在反复修改中变得越来越混乱，逻辑也越来越难以把控。到最后，甚至出现了一种“不敢再改”的状态。
我换了一个角度去思考这个问题：如果把 AI 当作一位同事，在这样的描述下，他真的能把事情做好吗？现在的 AI 能力已经很强，某种程度上，它确实可以被当作一位“刚入职的新同事”。但问题在于——面对这些模糊、零散甚至不断变化的描述，它真的能够准确理解吗？
思考到这里，我逐渐意识到，问题或许并不完全在 AI，而是回到了我们自身：我们给出的信息，是否足够清晰、具体、可执行？基于这样的认知，我开始了新一轮的尝试。
我开始调整自己的表达方式——不再只说“要做什么功能”，而是尽可能把细节讲清楚、讲具体。
如果只是简单抛出一个庞大的功能，AI 对需求的理解往往会和我们产生偏差。于是，我开始补充更多约束条件和背景信息，甚至从一些非常小的任务入手，比如“在 PO 上新增一个字段”，或者“写一个简单的计算工具类”。
我更想强调的是：这不仅仅是在完成任务，而是在建立一种与 AI 的沟通机制。就像新同事入职，你需要逐步了解他的做事方式。通过这些小而具体的功能，我慢慢摸清了它的“习惯”，同时它也在适应我的表达方式。当需求被拆得越小、越细，沟通就越精准，最终的结果也越可控。
有一次在和 AI 交互的过程中，我发现一个细节：当我给出实现方案时，它并不会一味照做，反而会提示“这个方式可能不太合适”，甚至给出更优的建议。
我开始反思，或许问题不在于“让它去做”，而在于“怎么和它对齐”。于是，我逐渐从“命令式使用”，转变为“主动询问”。不再直接让它写代码，而是先描述自己的需求和设计思路，比如：“我现在有这样一个需求，我的设计是这样的，你帮我看看是否合理？”
这样的变化带来了两个明显的好处：一方面，AI 能更好地理解你的思路和上下文；另一方面，它也能补充你未曾考虑到的细节和方案。经此之后，我的使用方式也随之调整为：先通过提问完成对齐，再进入代码编写。
在持续使用过程中，我逐渐发现，如果在同一个对话中不断叠加新需求，而不去控制上下文长度，AI 对问题的理解很容易出现偏差。尤其是当上下文变得非常长（比如接近 200K）时，信息开始变得混杂，重点被稀释，AI 的“判断力”也会明显下降。
从实践来看，我更倾向于将上下文控制在一个相对可控的范围内，大致在 20%～30% 时，整体效果会更稳定。当需求本身比较多、比较杂时，我的做法是主动进行拆解：将一个大需求拆成多个小需求，分多轮对话分别处理。这样不仅能有效控制上下文长度，也能让每一步的结果更加清晰、可控。
这一点其实是踩过坑之后得出的经验。前面几轮代码编写和 Review 都进行得很顺利，但在后续某一次描述不够清晰的情况下，AI 误改了之前已经调整好的代码，前面的成果被覆盖，一天的工作几乎白费。
这让我意识到，当代码已经可用，并且通过 Review 后，就应该立即进行提交。这样一来，即使后续修改出现问题，也可以快速回退到稳定版本，避免重复劳动带来的损耗。
上述这些方法，其实已经可以支撑我们完成大部分基础功能的开发。但随之而来的，还有一个新的问题：AI 生成的代码，往往不完全符合我们的代码风格，或者公司的业务规范。
针对这一点，我尝试通过 Skill 的方式来解决。我把这套体系称为“Skill 宇宙”——在这里，AI 不再只是一个辅助工具，更像是你的一个“分身”。它不仅能理解你的需求，还能逐渐复用你的习惯、约定和规范。
通过构建不同的 Skill，我们可以将代码风格、通用逻辑甚至业务约束进行沉淀，让 AI 在生成代码时，天然贴合我们的使用方式，而不是每次都从零开始对齐。
其实并不复杂。我们可以直接通过 Ask 模式来描述自己的需求，同时把既有的方法设计、代码风格以及约定规则一并告诉 Qoder，让它基于这些信息进行生成。
在实际使用过程中，如果发现生成结果与预期不一致，也不需要反复在对话中纠正，而是回到 Skill 文件本身，对其中的描述和规则进行调整即可。需要强调的是，这并不是一蹴而就的，而是一个持续优化、不断迭代的过程。
举个更贴近实际的例子。在日常业务开发中，我们往往已经沉淀了一些固定的规范，比如：统一的异常处理工具类、特定的查询构建方式等。如果不加以约束，在 Vibe Coding 的过程中，AI 虽然能够生成“看起来正确”的代码，但很可能并不符合我们的业务规范。这个时候，就可以把这些约定进行拆分和分类，沉淀为不同的 Skill，用来约束和引导 AI 的生成行为。
接下来，我们通过一个具体的实战案例，来看看这套方式是如何落地的
在基于 Spring Boot 后端项目的实验中，我重点关注了两个痛点：
在一系列尝试之后，我逐渐沉淀出一套相对稳定的开发工作流：
从需求拆分开始，通过 Ask 模式先对齐需求，再进入 Agent 模式进行代码实现；随后进行代码 Review，确认无误后及时提交。
整体流程可以概括为：需求拆分 → Ask 模式对齐需求 → Agent 模式修改代码 → 代码 Review → 及时提交。
大多数人在最初接触 Vibe Coding 时，都会经历“效果不理想”的阶段。但问题是：我们能不能像大模型一样，持续进行自我迭代？
我总结了一套简单的自我优化机制：
当结果是成功的，就把有效的方法沉淀下来，整理进个人知识库，形成可复用的经验；
当结果不理想时，就进行归因分析，找到问题的根源。进一步来看，问题大致可以分为两类：
我的答案是：不一定。
写代码只是我们工作的一部分，而不是全部。Qoder 的能力，其实远不止于此——它同样可以用于写剧本、打磨爆款文章，甚至构思视频脚本。
当你把使用边界打开，会发现它不只是一个“写代码的工具”，更像是一个可以参与思考、协同创作的伙伴。
基于这样的想法，我做了一次更有意思的尝试——让 Qoder “定义它自己”。
我让它写歌词、起名字、设计赛博朋克风格的角色形象，甚至为 MV 创作分镜提示词。这些内容被逐步串联起来，最终，在 Qoder “大脑”的指引下，我完成了一个完整的 MV——《我是 Qoder》。
最后想对大家说：我们先用起来，再慢慢变得更强。
更多企业解决方案请咨询 ➔
01 老项目问题及突破口
- 代码量非常大： 我们的老项目代码量可能有几万、几十万条，甚至几百万条，规模非常庞大。
- 历史逻辑非常复杂： 因为是老项目，人员迭代或者需求变更非常频繁。
- 理解成本非常高： 针对新人来讲，如果要理解、学习并完善项目，时间成本可能是几天甚至几周。
Repo Wiki：让 AI 成为带教“学长”
Qoder 的 Repo Wiki 可以帮助我们快速理解项目架构，梳理项目的调用关系，并生成详细的说明文档，同时，它还可以帮助团队培养新同事。
02 踩坑与尝试
虽然已经对项目有了一定理解，但代码编写的问题并没有因此得到解决。最初，我的做法很直接——让 AI 去完成具体功能的实现。
AI 很快就能输出大量代码片段，但真正运行时，会发现其中存在不少漏洞和偏差。于是，我开始不断补充说明，对问题进行二次、三次，甚至更多轮的描述和修正。
然而结果并没有朝着预期发展，反而逐渐失控：代码在反复修改中变得越来越混乱，逻辑也越来越难以把控。到最后，甚至出现了一种“不敢再改”的状态。
我换了一个角度去思考这个问题：如果把 AI 当作一位同事，在这样的描述下，他真的能把事情做好吗？现在的 AI 能力已经很强，某种程度上，它确实可以被当作一位“刚入职的新同事”。但问题在于——面对这些模糊、零散甚至不断变化的描述，它真的能够准确理解吗？
思考到这里，我逐渐意识到，问题或许并不完全在 AI，而是回到了我们自身：我们给出的信息，是否足够清晰、具体、可执行？基于这样的认知，我开始了新一轮的尝试。
尝试1：具象化需求
我开始调整自己的表达方式——不再只说“要做什么功能”，而是尽可能把细节讲清楚、讲具体。
如果只是简单抛出一个庞大的功能，AI 对需求的理解往往会和我们产生偏差。于是，我开始补充更多约束条件和背景信息，甚至从一些非常小的任务入手，比如“在 PO 上新增一个字段”，或者“写一个简单的计算工具类”。
我更想强调的是：这不仅仅是在完成任务，而是在建立一种与 AI 的沟通机制。就像新同事入职，你需要逐步了解他的做事方式。通过这些小而具体的功能，我慢慢摸清了它的“习惯”，同时它也在适应我的表达方式。当需求被拆得越小、越细，沟通就越精准，最终的结果也越可控。
尝试2：主动询问，先对齐再编写
有一次在和 AI 交互的过程中，我发现一个细节：当我给出实现方案时，它并不会一味照做，反而会提示“这个方式可能不太合适”，甚至给出更优的建议。
我开始反思，或许问题不在于“让它去做”，而在于“怎么和它对齐”。于是，我逐渐从“命令式使用”，转变为“主动询问”。不再直接让它写代码，而是先描述自己的需求和设计思路，比如：“我现在有这样一个需求，我的设计是这样的，你帮我看看是否合理？”
这样的变化带来了两个明显的好处：一方面，AI 能更好地理解你的思路和上下文；另一方面，它也能补充你未曾考虑到的细节和方案。经此之后，我的使用方式也随之调整为：先通过提问完成对齐，再进入代码编写。
尝试3：控制上下文长度
在持续使用过程中，我逐渐发现，如果在同一个对话中不断叠加新需求，而不去控制上下文长度，AI 对问题的理解很容易出现偏差。尤其是当上下文变得非常长（比如接近 200K）时，信息开始变得混杂，重点被稀释，AI 的“判断力”也会明显下降。
从实践来看，我更倾向于将上下文控制在一个相对可控的范围内，大致在 20%～30% 时，整体效果会更稳定。当需求本身比较多、比较杂时，我的做法是主动进行拆解：将一个大需求拆成多个小需求，分多轮对话分别处理。这样不仅能有效控制上下文长度，也能让每一步的结果更加清晰、可控。
尝试4：最小提交原则
这一点其实是踩过坑之后得出的经验。前面几轮代码编写和 Review 都进行得很顺利，但在后续某一次描述不够清晰的情况下，AI 误改了之前已经调整好的代码，前面的成果被覆盖，一天的工作几乎白费。
这让我意识到，当代码已经可用，并且通过 Review 后，就应该立即进行提交。这样一来，即使后续修改出现问题，也可以快速回退到稳定版本，避免重复劳动带来的损耗。
03 Skill 宇宙：让 AI 复用你的“习惯”
上述这些方法，其实已经可以支撑我们完成大部分基础功能的开发。但随之而来的，还有一个新的问题：AI 生成的代码，往往不完全符合我们的代码风格，或者公司的业务规范。
针对这一点，我尝试通过 Skill 的方式来解决。我把这套体系称为“Skill 宇宙”——在这里，AI 不再只是一个辅助工具，更像是你的一个“分身”。它不仅能理解你的需求，还能逐渐复用你的习惯、约定和规范。
通过构建不同的 Skill，我们可以将代码风格、通用逻辑甚至业务约束进行沉淀，让 AI 在生成代码时，天然贴合我们的使用方式，而不是每次都从零开始对齐。
如何构建 Skill（方法与实践）
其实并不复杂。我们可以直接通过 Ask 模式来描述自己的需求，同时把既有的方法设计、代码风格以及约定规则一并告诉 Qoder，让它基于这些信息进行生成。
在实际使用过程中，如果发现生成结果与预期不一致，也不需要反复在对话中纠正，而是回到 Skill 文件本身，对其中的描述和规则进行调整即可。需要强调的是，这并不是一蹴而就的，而是一个持续优化、不断迭代的过程。
举个更贴近实际的例子。在日常业务开发中，我们往往已经沉淀了一些固定的规范，比如：统一的异常处理工具类、特定的查询构建方式等。如果不加以约束，在 Vibe Coding 的过程中，AI 虽然能够生成“看起来正确”的代码，但很可能并不符合我们的业务规范。这个时候，就可以把这些约定进行拆分和分类，沉淀为不同的 Skill，用来约束和引导 AI 的生成行为。
接下来，我们通过一个具体的实战案例，来看看这套方式是如何落地的
在基于 Spring Boot 后端项目的实验中，我重点关注了两个痛点：
- 异常处理： 我们业务中肯定有自己的异常工具类。
- 查询封装： JPA 有多种查询方式（接口方法、原生 SQL、条件构建等）。如果让 AI 自己写，他会有多种实践方式，不一定符合项目规范。
- 没有 Skill 的情况下： AI 使用了 JPA 定义的方法写了原生 SQL，且没有使用我们自定义的 Error 方法。虽然逻辑没问题，但不符合预期。
- 有了 Skill 之后： 我预先构建了“查询 Skill”和“异常 Skill”。再次生成代码时，构建动态查询和异常抛出都自动使用了我们自己的业务工具类。
04 我的工作流与自我优化机制
在一系列尝试之后，我逐渐沉淀出一套相对稳定的开发工作流：
从需求拆分开始，通过 Ask 模式先对齐需求，再进入 Agent 模式进行代码实现；随后进行代码 Review，确认无误后及时提交。
整体流程可以概括为：需求拆分 → Ask 模式对齐需求 → Agent 模式修改代码 → 代码 Review → 及时提交。
当结果不理想时，就进行归因分析，找到问题的根源。进一步来看，问题大致可以分为两类：
- 不可控因素：比如模型能力的限制。这种情况下，可以考虑及时调整模型或更换工具；
- 可控因素： 比如提示词（Prompt）不够清晰、业务逻辑本身存在漏洞、代码结构需要重构，或者对工具的使用还不够熟练（例如没有区分清楚 Ask 模式和 Agent 模式）。
05 Qoder 只能编写代码吗？
我的答案是：不一定。
写代码只是我们工作的一部分，而不是全部。Qoder 的能力，其实远不止于此——它同样可以用于写剧本、打磨爆款文章，甚至构思视频脚本。
当你把使用边界打开，会发现它不只是一个“写代码的工具”，更像是一个可以参与思考、协同创作的伙伴。