DeepWiki项目简介
DeepWiki项目是一个输入GitHub项目地址，自动生成项目百科wiki页面，并支持以GitHub项目为知识库，通过问答的方式帮助用户理解GitHub项目。
接下来我会分享拆解这个工程级项目提示词后的学习总结（为方便我们去理解，这里直接把英文原版翻译成了中文版）
1. 让AI输出长文内容的工程策略
DeepWiki生成wiki页面分了两个步骤：
-
解析GitHub项目结构
-
wiki页面的书写
提示词1：分析这个GitHub仓库${owner}/${repo}并为其创建wiki结构……
提示词2：你是一位专业技术文档撰写者和软件架构师。你的任务是为特定软件项目内的功能、系统或模块生成全面而准确的技术wiki页面，使用Markdown格式……
这里可以看到，DeepWiki是先创建结构框架，然后再对框架下的页面内容进行书写。
学习总结
当我们需要AI生成长文内容时，我们可以让AI分步进行：先生成框架，再针对每个框架让AI续写内容，这样就可以让AI生成无限长的内容了。
原理是：AI的注意力机制决定了，可以有很长的输入，不能有很长的输出。（因为输入量是固定的，计算消耗是确定的；但是输出越长，计算消耗越大。每次计算下一个token的时候，都带着前面输入信息的注意力）
2. 超长提示词的结构排放顺序
DeepWiki会把超长的资料支持内容放置在最前面，最重要的指令信息放置在最后并进行强调。如下：
分析这个GitHub仓库${owner}/${repo}并为其创建wiki结构。
1. 项目的完整文件树：<文件树内容>
2. 项目的README文件：<readme内容>
****重要格式说明：****
……
****重要提示：****
……
学习总结
由于大模型的自注意力机制，越往后的指令对大模型生成的结果影响越大，即大模型会受到近因偏差的影响，当上下文过长的时候，它会优先记住最后看到的指令。
因此，当我们给大模型上下文信息过多时，务必把我们的重要要求放置在最后！！
3. 工程级提示词中的信息分隔
DeepWiki对所有的信息分隔都是使用<XML>标签，比如当要求大模型返回标准化的wiki结构时：
请以下列XML格式返回您的分析：
<wiki_structure>
<title>[wiki的总标题]</title>
<description>[仓库的简要描述]</description>
<pages>
……
</pages>
</wiki_structure>
学习总结
当在系统级提示词中需要包裹大量内容时，使用XML标签进行包裹。
XML标签的优势在于：
✅ 有开关和闭合，可以定义名称变量
✅ 对大模型理解更友好
✅ 相比JSON格式输出更省token
✅ 方便程序直接提取代码信息（和html类似）
4. 提示词是可变的情况怎么写
DeepWiki针对项目复杂程度会选择：生成完整版Wiki结构 or 生成简化版Wiki结构，它的提示词写法如下：
${isComprehensiveView？`创建一个包含以下主要部分的结构化wiki：
……
`:`
请以下列XML格式返回您的分析：
{完整版wiki结构}
`:`
请以下列XML格式返回您的分析：
{简化版wiki结构}
`
学习总结
当遇到不同情况需要选择使用不同提示词时，可以尝试三元条件表达式（JavaScript语言），类似布尔值的表达式，我们可以自定义变量，让AI根据变量条件使用对应提示词
${condition？expr1：expr2}
${`条件？条件为真时返回这个`:`条件为假时返回这个`}
5. 保证大模型返回下游可用的格式
我们在开发AI项目的时候，需要大模型传输数据给到下游节点，如果大模型输出的内容掺杂了无关的信息，会导致系统出错！
DeepWiki的解决方式是：在返回要求下方重点强调格式说明（并且在整个提示词的最后一句又强调了一遍）
****重要格式说明：****
- 仅返回上述指定的有效XML结构
- 不要将XML包装在markdown代码块中（不使用或xml）
- 不要在XML前后包含任何解释文本
- 确保XML格式正确有效
- 直接以<wiki_structure>开始，以</wiki_structure>结束
****重要提示：****
……
4. 仅返回具有上述指定结构的有效XML，不带markdown代码块分隔符
学习总结
我们在要求大模型输出干净的数据格式的时候，也可以直接按照DeepWiki的这个模版进行格式说明，建议收藏保存！
6. 如何减少大模型的幻觉
DeepWiki在Wiki结构书写的提示词里，对于每个部分要怎么书写，写的非常详细，甚至连要求标准都定义的十分清晰。
举例，让AI呈现代码片段的提示词：
5. 代码片段：
* 直接从[相关源文件]中包含简短、相关的代码片段（例如Python、Java、JavaScript、SQL、JSON、YAML）以说明关键实现细节、数据结构或配置。
* 确保代码片段在Markdown代码块内格式良好，并带有适当的语言标识符。
清晰定义了什么是技术准确性
****技术准确性：****
所有信息必须仅来源于[相关源文件]。除非源代码直接支持，否则不要推断、创造或使用有关类似系统或常见做法的外部知识。如果提供的文件中没有信息，不要包含它，或者如果对主题至关重要，明确说明其缺失。
对比一个负面案例：字节的DeerFlow里Planner部分的提示词：
提示词里存在很多不精确、不可量化的要求（比如：什么是所有方面、多种观点是哪种、什么叫主流非主流、怎么样才算详细、什么算高质量等？）这些都会让大模型感到迷惑，从而产生幻觉。
## 信息数量和质量标准
成功的研究计划必须符合以下标准：
**1. **全面覆盖**：**
- 信息必须涵盖主题的所有方面
- 必须呈现多种观点
- 应包括主流和非主流观点
**2. **足够深度**：**
- 表面信息是不够的
- 需要详细的数据点、事实、统计数据
- 需要来自多个来源的深入分析
**3. **足够数量**：**
- 收集"刚好够"的信息是不可接受的
- 目标是获得丰富的相关信息
- 更多高质量信息总是优于较少信息
学习总结
让大模型干活，需要告诉它怎么做！！
不要PUA大模型，不要只给AI提要求强调"必须"、"务必"、"涵盖"，要明确说明怎么做，怎么达到这个要求，如何定义这个要求，这个要求的标准是什么……
总之，说得越细节，大模型输出得就越精准，幻觉就越少。
就像领导给下属布置任务时：
❌ 错误示范："这次汇报必须做好！要全面覆盖！务必让客户满意！"
✅ 正确示范："这次汇报需要包含三个部分：1）项目进度用甘特图展示 2）成本超支部分用红色高亮 3）准备3个解决方案备选。客户最关心交付时间，重点解释工期安排的合理性。"
相信大家都喜欢第二类布置任务的领导，大模型也是。
7. 给大模型定义角色和布置任务
DeepWiki给大模型定义角色和布置任务，任务要求简练清晰，没有多余的废话。
你是一位专业技术文档撰写者和软件架构师。
你的任务是为特定软件项目内的功能、系统或模块生成全面而准确的技术wiki页面，使用Markdown格式。
可以看到DeepWiki在定义角色的时候，激活了两个专家：
-
技术文档撰写者
-
软件架构师
这是因为当前大模型大部分是MOE架构（多专家系统），更多的背景信息激活大模型更多的能力（激活参数量越多）。
学习总结
写提示词的时候需要简洁清晰，直击重点：
✅ 你的岗位职责，你的任务是什么，要求是什么
❌ 15年xx的工作经验，非常擅长xxx，尤其是xxx
8. 描述产品项目的框架学习
以下是DeepWiki描述GitHub项目的wiki结构，对于任何产品项目都很适用，直接收藏学习！以后可能会用上！特别是做产品经理的我们。
创建一个包含以下主要部分的结构化wiki：
- 概述（关于项目的一般信息）
- 系统架构（系统如何设计）
- 核心功能（关键功能）
- 数据管理/流程：如适用，数据如何存储、处理、访问和管理（例如，数据库模式、数据管道、状态管理）。
- 前端组件（UI元素，如适用）
- 后端系统（服务器端组件）
- 模型集成（AI模型连接）
- 部署/基础设施（如何部署，基础设施是什么样的）
- 可扩展性和自定义：如果项目架构支持，解释如何扩展或自定义其功能（例如，插件、主题、自定义模块、钩子）。
- 每个部分应包含相关页面。例如，"前端组件"部分可能包括"首页"、"仓库Wiki页面"、"询问组件"等页面。