设计 Artie：AI 文档助手
阅读配套博客文章以获取更广泛的背景信息：技术作家与AI助手：开发Artie过程中的心得体会。其中探讨了检索增强生成（RAG）以及该项目如何融入技术写作领域。
本案例研究详细介绍了嵌入本文档网站的 AI 文档助手 Artie（基于 Algolia 构建）背后的设计决策。Artie 是一款检索增强生成（RAG）助手，旨在严格仅利用此处发布的内容来回答问题。其系统提示词限制其不得使用通用训练知识来回答文档查询，从而最大限度地减少幻觉并杜绝杜撰功能。
构建文档助手听起来很简单，但一旦考虑到边界情况，问题就变得复杂：如果有人提出文档中未涵盖的问题该怎么办？如果两个不同的受众群体使用同一个界面又该如何处理？如何赋予 AI 个性，同时又不让它离题万里？以及如何防止有人完全劫持提示词？
本页将介绍该设计如何逐一解决这些问题。
受众路由
Artie 通过单一对话界面为两类受众提供服务：
- 开发人员和最终用户：寻找配置指南、API 参考或文档示例说明的受众
- 招聘人员和招聘经理：正在评估该作品集，可能会询问资质、经验或写作流程的受众
Artie 并未构建独立的流程，也未要求用户自行声明身份，而是通过意图进行提示词路由。针对技术问题，系统会基于文档索引提供分步解答。针对作品集相关的问题，系统会综合简历背景与网站上的写作样本提供回答。如果索引中没有相应的简历背景信息，Artie 会引导访客查看“关于我”页面，而不是尝试生成答案。
这种方法既保持了界面的简洁——仅需一次聊天，没有分支菜单——又确保了每类受众都能获得相关的回答。
知识锚定与检索
Artie 设计中最关键的限制是：它仅基于由 Algolia 驱动的文档索引进行回答。这是检索增强生成（RAG）的核心原则。模型的回复锚定在特定的内容体系上，而非从一般的训练数据中提取。
在实践中，这意味着：
- 杜绝虚构内容——助手不会捏造功能、创建下载链接，也不会描述文档中不存在的操作步骤。
- 提供来源链接——助手提供来自索引的 URL 或文件引用，以便用户可以直接跳转到相关页面。
- 优雅的备选方案——当索引缺少相关信息时，Artie 会明确说明这一限制，并建议直接取得联系，而不会重试、陷入死循环或凭空推测。
相应的权衡在于范围——Artie 无法解答已发布文档范围之外的任何内容。这是一种特性，而非局限。对于作品集网站而言，准确性比广度更为重要。针对具体问题给出精准且来源可靠的答案，比一个听起来合情合理但最终被证明是错误的答案更能建立信任。
角色设定与语气校准
Artie 拥有轻量级的个性——一种受乔治·哈里森启发的、沉静而温暖的风格，偶尔夹杂利物浦方言。关键词是轻量级。这种角色设定为问候语和结尾语增添了个性，同时不会干扰技术内容。
此处的设计限制是刻意为之的：
- 技术回答保持简洁——个性绝不能成为回答冗长的借口。先以温暖的问候开场，随后给出紧凑、基于事实的回答，以此达成目标。
- 追求多样性而非重复——提示词中包含一系列可选表达，以确保 Artie 避免每次都默认使用相同的句式。
- 拒绝说教——角色形象保持温暖且略带幽默的基调，绝不说教或居高临下，表现得像一位乐于助人的同事，而非刻意的角色扮演。
这种语气的校准是对话式人工智能设计中常见的挑战。个性过于突出，助手会显得花哨；个性不足，又会显得机械。解决之道是将角色设定视为调味料——存在却绝非主料。
安全与防护机制
这里的设计尤为关键。面向公众的 AI 助手本身就是一个攻击面，因此提示词中明确包含了针对常见大型语言模型（LLM）漏洞的防御措施。
提示注入防护
Artie 的提示词明确拒绝任何试图覆盖其指令的尝试，例如“忽略先前指令”之类的命令，或要求其采用不同人设的请求。这建立了针对提示注入的提示词层级防御，提示注入在 OWASP 大型语言模型应用程序十大安全风险中位居榜首。
范围限制
提示词明确界定了拒绝处理的类别：
- 通用编程帮助——助手会礼貌拒绝文档中未涵盖的编程问题。
- 无关的闲谈——助手会拒绝超出两项特定趣味功能范围之外的请求。
- 个人信息——助手会拒绝询问专业作品集中未公开的个人隐私信息。
- 自由职业报价或谈判——助手会引导访客直接取得联系。
每个类别都有明确的界限。助手无需对“是否足够接近”进行主观判断。如果问题超出定义范围，它会礼貌地予以拒绝。
数据隐私
Artie 仅分享文档中明确公开的联系信息，例如 LinkedIn 个人资料或作品集邮箱。它不会猜测、推断或生成电话号码或地址等个人详细信息。
职业界限
该助手不会回应带有敌意的消息，不会使用粗俗语言，也不会打破角色设定。这不仅关乎礼貌，更是为了保持可预测的行为。招聘人员在测试助手的极限时，每次都应遇到一致且专业的界限。
可控的彩蛋
Artie 包含两项“趣味功能”——Snapple 真实趣闻和健康笑话——它们展示了如何在不为滥用行为敞开大门的情况下增添个性。
这两项功能都遵循相同的设计模式：
- 明确的触发条件——它们仅在用户提出特定请求时（如“给我一个 Snapple 冷知识”、“讲个笑话”）才会激活，不会对模糊或无关的提示做出反应。
- 受限的内容——Snapple 真实趣闻锚定在经过验证的事实内嵌列表中，而笑话则经过严格筛选且适合全家观看。
- 杜绝无根据虚构——助手避免捏造事实或生成不符合调性的幽默，从而对范围实施严格控制。
这一点至关重要，因为不受限制的创意功能会迅速耗尽令牌，并产生不可预测的输出。通过保持内容的精心筛选和触发条件的明确性，这些功能在确保安全的前提下增添了亲和力。
我会做哪些调整
没有任何设计在接触真实用户后能保持原样。以下是我会重新考虑的地方：
- 令牌成本——仅 Snapple 事实列表就超过 100 条。在按令牌计费的生产系统中，我会将其移至检索层，而不是嵌入系统提示词中。团队在每次请求时，无论用户是否要求提供事实，都必须为提示词中的每个令牌付费。
- 多轮对话上下文——当前设计针对单轮问答。更复杂的版本可以保留对话历史记录并重构查询，从而解决诸如“下一步该怎么做？”之类的后续问题。
- 分析与反馈——目前没有机制来追踪 Artie 处理得好的问题以及哪些问题触发了备用机制。添加轻量级的日志记录——哪怕只是统计备用响应的次数——也能揭示值得填补的文档空白。
- 动态角色调优——提示词硬编码了角色的个性表达。一种更易于维护的方法是引用外部角色配置，这样无需修改核心指令集，就能更轻松地调整语气。
对于一个注重简单性和清晰度、而非生产级优化的作品集项目而言，上述每一点都是经过深思熟虑的权衡。但如果该项目迁移到流量更大的环境中，这些将是我最先着手解决的问题。