大家好，我是 Qoder 大使刘汪洋。给大家分享的主题是：Qoder 仓库 Wiki 实践案例和最佳实践探索。

当前，很多团队在积极推进 AI Coding，但当真正面对企业级的特别复杂的项目时，发现 AI 的增益不明显。今天，我将结合我维护的一个企业级复杂项目，分享一个最佳实践。通过提示词自动优化、仓库 Wiki、用户手册、项目 Rule、MCP 等一套组合拳，让 AI 在企业级项目中发挥出更大价值。

项目介绍

这是一个比较复杂的企业级项目，相比于传统业务项目，它更偏框架和中间件层，更加复杂。

• 代码抽象层次特别多，维护框架的新人很难看懂。

• 和很多企业级项目一样，也存在文档缺失，文档和代码不完全对应的情况。

• 它自己定义了语法糖，用户需要熟悉特定语法，上手成本非常高。

理想是很丰满的，用户读一次我们的手册，就过目不忘，可以根据要求很好地写出对应的脚本。

但理想很丰满，现实很骨感。 用户看文档的时候觉得很枯燥，而且非常低效，看完可能还记不住，很容易忘。

他们在写脚本时就会寻求技术支持的帮助，但技术支持可能正忙于工作，不确定什么时候能回复。而且就算把报错原因告诉他，他也得回到 IDE 里再改。一来一回，一个小问题可能卡十几分钟、半小时甚至更久。

实践经验

那我们是怎么做的？

我们作为平台的开发者，需要沉淀出一些语法文档和最佳实践。技术客服的同学在日常答疑过程中，也要把常见问题进行沉淀。这样我们就有了一个比较详细、准确、完整的用户手册。

这还不够，我们用 Qoder 去生成仓库 Wiki。因为基于代码生成出来的 Wiki 是非常全面、专业和完整的，而且非常准确。我们把沉淀的知识和 Qoder 生成的仓库 Wiki 一起作为一个知识库，包装成 MCP，就可以在 Qoder 中给用户使用了。

很多人都知道现在的知识库提取不可能那么完美，可能提取错误、遗漏等。于是我们就把关键的一些语法通过 Qoder 压缩成用户规则，这样最关键和精华的内容就可以始终放在上下文里。

那么有了关键的用户规则，又可以通过 MCP 可以获得知识库中的信息。

那么对于平台用户来说，它就可以非常好地生成代码，让 AI 让 Qoder 进行代码审查遇到报错，就可以轻松地进行 bug 修复。任何相关的绝大多数疑问就可以在 Qoder 中自助提问解决。毫不夸张地说，大多数问题用户都可以在 IDE 中一站式解决，效率提升 200% 以上。

比如说我们有一个脚本编写的需求，如果我们自己写，可能会存在语法记不住的情况，需要来回复制一些模板代码，可能得花上一两个小时，而且还会有各种语法问题。

我们需要特别注意，我们现在是让 AI 帮我们写代码，就尽量把技术方案写得结构化、更清晰、准确、完整。这一点非常重要。

关键的语法规则已经在项目规则中，我们描述需求，让 Qoder 自动优化一下提示词，并发送。短短一两分钟的时间，Qoder 就可以一次性生成三四百行代码，而且质量非常高。

我们在编写脚本的过程中，难免会写出一些 BUG。那么有了这些信息之后，我们只需要把错误信息发送给它，它有我们的源码、有我们的语法规则，就可以快速分析问题，给出原因和修复方案，并自动修复。

我们以前可能需要看文档或者找技术支持。

现在我们按照前面所说，将用户手册和仓库 Wiki 一起导入到知识库平台。你可以使用阿里云百炼知识库 也可以使用其他平台。有些平台提供官方 MCP，如果没有提供你也可以让 Qoder 基于 NodeJS 根据知识库平台的 API 封装一个 MCP 服务。

我们在项目规则中，告诉 Qoder 在什么时候使用这个 MCP 以及如何使用这个 MCP。

现在，如果有任何疑问，直接在 Qoder 里提问，它会自动通过 MCP 调用我们的知识库，获取想要的信息。

那么我们有了源码、用户手册、仓库 Wiki、用户规则、提示词、MCP 、记忆，这些非常丰富的上下文。我们就可以把 Qode 打造成一个 AI 超级伙伴。

有了这些信息，对平台的开发者有什么好处？

那比如说我们去做一些升级的时候，就可以让他给我们做出风险评估。我们要做一个方案的话，也可以让他帮我们出方案。有了方案之后，我们也可以让他根据我们的方案进行功能的迭代。如果遇到一些疑难杂症，只需要把额外的一些信息再给到他，他就可以获得最完整的上下文，快速定位疑难杂症。

这给我们平台开发者提前规避了很多潜在风险，也带来了巨大的效率提升。

比如说我们想 Groovy 升级到 5.0.2，会有哪些风险。

比如说我们直接在网页上问 Gemini 或 ChatGPT，他们给出的回答可能会有帮助，但不可能那么具体，因为他们没有你的源码，也没有你的仓库 Wiki，也不知道你的核心语法和用户手册等等。

那么有了这些上下文之后，Qoder 就可以给出更全面的评估。我们看到它在这个过程中读取了很多关键源码，也会用到我们的仓库 Wiki 和其他相关信息。最后给出的风险评估非常完整，而且非常具体，这样帮助就更大。

经验分享

我们需要转变认知。

以前是人类写代码，流程成熟，系分文档写得随意，也不用写什么提示词。

现在想让 AI 写代码，大模型快速迭代，AI 工具也在探索，就必须把任务拆解到模型能力范围之内：模型越弱，拆得越细；要把任务交代清楚，把 AI 写代码所需的信息给充足和准确。

可以把自己经常需要重复的一些提示词放到项目规则中，比如“生成实体使用 Lombok 注解”、“单元测试使用 JUnit4、“JSON 使用 Fastjson ”、“完成任何功能都不要写 ReadMe 文档”等。

还有一些关键的信息，比如说一些关键语法规则等等，需要让他始终关注的信息就可以放到项目规则中。

我们还可以把工具和行为约束，放到项目规则里。比如“如果缺少信息，可以调用 xx MCP，使用 yy工具，参数传 mm”、“任何改动请先出方案，我确认后你再执行”。

我们可以通过 MCP 拓展大模型的边界。我们既是 MCP 的消费者，可以在 Cursor 中选择一些好用的 MCP 来使用；也是 MCP 的生产者，可以封装一些 MCP 工具，让大模型完成更个性化和复杂的任务。

很多人哪怕是封装 MCP 服务，他们也只是把简单的 API 接口封装出来。然而 MCP 背后可以是一个知识库，也可以是一个工作流，甚至可以是一个智能体。

那么我们提到了仓库 Wiki，也提到了项目规则，也提到了 MCP，这里简单讲讲它们的区别。

仓库 Wiki 主要是帮助我们快速熟悉代码，以及把最新的代码文档化，然后可以更高效地作为编码的其中一个参考。然后我们把它封装成知识库，通过 MCP 挂到 Qoder 里，然后也可以作为用户答疑的材料。

规则的话就通常是团队的一些规范、一些关键的语法规则、AI 使用工具的一些说明，还有一些人机交互的一些约定。

MCP 的话主要还是拓展大模型的边界，它既可以让我们通过 MCP 去获取一些信息，也可以让它通过 MCP 去执行一些操作。

最后给出复杂项目的上下文的解法：

首先我们尽量把复杂的任务优先选择更强大的模型。我们需要重视源码、仓库 Wiki、项目规则，这些都是上下文重要构成部分。我们需要通过提示词表达清楚需求，也可以通过 Qoder 对提示词进行优化。如果优化的提示词和我们想要表达的不一致，就说明之前的表达要么不准确，要么有缺失。我们要把系分文档（技术方案）写得比以前更加结构化、清晰、准确、完整。可能包括项目的背景、项目的价值、项目的研发周期、项目的主要负责人、整体的架构、每个功能点接口的定义和时序图，以及数据库、定时任务、消息队列设计等等。

然后我们需要沉淀一些知识库，比如说我们可以沉淀一些用户最佳实践、常见问题等知识库，它也是上下文的重要组成部分，而且这些东西都无法直接在仓库中获取到的。

我们需要使用或者封装 MCP 给 Qoder 来用。然后我们也可以通过开启记忆让 Qoder 去记住我们的一些偏好，更好地为我们服务。

如果这些都还不行的话，项目仓库实在是太庞大，最后一个杀手锏就是我们需要考虑对项目进行拆分了。

写在最后

现在很多团队的 AI Coding 走到深水区，AI 增益不明显。

随着 AI Coding 走到深水区，上下文工程的价值也会越来越大。上下文工程不仅是提示词，还包括系分文档、用户手册、源码、仓库 Wiki、项目规则、MCP、记忆等。

我们只有把上下文工程搞好，才能够让 AI 在复杂的企业级项目中发挥出更大的价值。

今天的分享就到这里，我们下次再见！