本地与云端 AI 的工程上下文：人物角色、内容智能与 Zero-Prompt UX
Source: Dev.to
请提供您希望翻译的完整文本内容，我将为您翻译成简体中文并保持原有的格式、Markdown 语法以及技术术语不变。谢谢！
Source: https://blog.agentailor.com/blog/chrome-builtin-ai-cloud-hybrid-system
介绍
在上一篇文章中，我们介绍了 DocuMentor AI 的混合架构如何在 Chrome 本地 Gemini Nano 与云端 AI 之间无缝切换。我们构建了一个系统，能够根据能力和性能约束自动路由任务。
然而，仅有强大的执行层只是成功的一半。另一半呢？为这些模型提供上下文的工程化。
大多数 AI 工具只给你一个强大的模型和一个空白的文本框，然后让你自己想办法该问什么。这就像把专业相机交给某人并说“拍一张好照片”——技术上可以实现，但全部负担都落在用户身上。
DocuMentor 采用了不同的方式：通过智能上下文工程实现零提示 UX。用户从不需要编写提示词。他们只需点击一个功能（快速扫描、深度分析、速查表），扩展程序就会处理其余工作——组装正确的角色元素、提取合适的页面片段，并将所有内容塑造成 AI 不会误解的请求。
本文将拆解其工作原理：零提示设计背后的理念、为每个响应提供个性化的角色系统，以及能够精准决定向 AI 发送何种内容的内容智能层。
零‑提示哲学
大多数技术文档工具和 AI 驱动的浏览器都采用相同的用户体验模式：一个空白的聊天输入框，提示文字类似 “Ask me anything about this page”。
表面上看这很友好，但如果你不知道该问什么，就会产生三个问题：
- 认知负荷 – 用户必须思考如何表述问题。
- 意图模糊 – 细微的措辞变化会导致答案天差地别。
- 通用回复 – 没有用户上下文，AI 只能给出千篇一律的答案。
我创建 DocuMentor 正是为了解决我自己的痛点：我每周花数小时浏览文档、博客和 API 参考，想要快速提取所需信息。有时我只想要一个 TL;DR 来判断是否值得继续阅读；有时我需要一份速查表以备后用；还有时候，我只想知道 “我需要在意这个吗？”
这些都是 具体且重复出现的需求。为什么每次都要从头阐述它们？
以功能为先的设计
与其提供空白聊天框，DocuMentor 直接提供四个专门的功能：
| 功能 | 功能说明 |
|---|---|
| 快速扫描 | 即时洞察：TL;DR、“是否值得阅读？”、相关资源、页面结构 |
| 深度分析 | 全面概览、代码模式、视频推荐、带有推理的学习资源 |
| 速查表 | 精简、可操作的摘要，便于快速查找 |
| AskMe | 定向聊天：选中文本或图片并提出具体问题 |
每个功能都对应一个预设的意图。用户不必思考提问方式，只需选择想要的结果。扩展程序随后会生成提示词，挑选合适的页面片段，并应用用户的角色设定。
这不仅是便利，更是 消除歧义。当用户点击 快速扫描 时，根本不存在误解的空间。AI 知道要返回何种格式、提供何种细节以及用户关心的重点。
Persona‑Driven Personalization
在构建初始功能集后，我意识到一个关键问题：这些功能不应该返回通用答案。
“我应该阅读这个吗？”的推荐在不知道提问者是谁的情况下毫无意义。资深 AI 工程师不需要神经网络的入门介绍，而初级前端开发者则需要。相同的功能、相同的页面，却需要完全不同的答案。
于是我引入了 persona 系统——一个根据用户资料来塑造每一次 AI 响应的机制。
Persona 包含哪些内容
| Component | Description |
|---|---|
| Role | AI/ML Engineer、Frontend Developer、Backend Engineer 等 |
| Seniority | 初级、Intermediate、Senior |
| Skills | 编程语言、框架、概念——每项都有熟练度（Beginner、Intermediate、Advanced） |
| Learning Goals | 用户当前想要掌握的内容（例如 “Master LangGraph for production AI agents”） |
| Learning Preferences | 文本、视频或混合形式 |
Figure: The five components of a DocuMentor persona.
挑战不仅在于收集这些信息——更在于哪些元素对哪些功能重要。
将 Persona 元素映射到功能
| Feature | Relevant Persona Elements |
|---|---|
| Quick Scan | Role、Seniority、Skills、Learning Goals |
| Deep Analysis | Role、Seniority、Skills、Learning Goals、Learning Preferences |
| Cheat Sheet | Role、Seniority、Skills |
| AskMe | 所有元素（取决于具体查询） |
例如，学习偏好对 cheat sheet 并不相关（用户已经决定要文本），而 技能和目标 对 “我应该阅读这个吗？” 的推荐至关重要。向模型发送无关的 persona 数据会产生噪音并浪费 token——在本地 AI 上尤其要注意上下文限制。
结论
Zero‑prompt UX，结合精细调校的人格系统，使 DocuMentor 能在不强迫用户编写提示的情况下提供精准、上下文感知的答案。通过仅将必要的人格属性映射到每个功能，我们保持令牌使用的高效，同时仍能提供高度个性化的输出。
接下来的章节（此处未展示）将深入探讨 content‑intelligence layer、prompt‑generation pipeline，以及混合本地/云执行的 performance considerations。敬请期待！
Persona‑Driven Recommendations
场景： 你是一名 初级前端开发者，正在学习 React，恰好看到一篇关于高级状态管理模式的文章。
DocuMentor 的 “我该读吗？” 功能可能会说：
是的，阅读它。
这篇文章涵盖了useReducer和 Context API 模式，能够提升你的 React 技能。它假设你已经熟悉useState，而这正是你的情况。示例实用且符合你的学习目标：掌握用于生产环境的 React。
场景： 你是一名 资深后端工程师，虽然了解 React，但并不专注前端工作。
DocuMentor 的推荐：
跳过此文。
你已经从 React 经验中掌握了这些模式。阅读它不会推进你当前的目标（精通分布式系统）。如果以后需要复习，速查表功能已经为你准备好。
同一页面，同一功能，但因为人物设定告诉 AI 谁在提问 以及 他们为何在意，所以得到完全不同的推荐。
这并不是为了个性化而个性化。它在于 尊重用户的时间。通用的 AI 工具会让你阅读无关内容或隐藏重要洞见，从而浪费时间。基于人物的 AI 像一位了解你背景和优先级的知识同事。
内容智能：战略页面拆分
早期我犯了大多数 AI 开发者都会犯的天真错误：我把整个页面的 HTML喂给模型，认为它能“自行弄清”。
结果惨败：
| 问题 | 为什么会受影响 |
|---|---|
| 上下文溢出 | 原始 HTML 很容易超过 Chrome AI 大约 4 K token 的限制 |
| 噪声淹没信号 | 广告、导航、页脚和 JavaScript 与实际内容竞争 |
| 幻觉 | 像 Gemini Nano 这样的小模型会被无关信息弄糊涂 |
第一步修复 → 内容提取
我使用 Mozilla 的 Readability 库（对 Readability 失效的页面提供自定义回退）来提取干净、可读的文本。
即使清理后，又出现了新问题：并非每个功能都需要相同的信息。
| 功能 | 所需信息 |
|---|---|
| 摘要与速查表 | 完整文章内容 |
| 视频推荐 | 仅页面摘要 |
| “学习资源”建议 | 页面链接和导航上下文（不包括文章正文） |
把所有内容发送给每个功能会浪费 token、增加延迟，并降低相关性。
解决方案： 战略页面拆分。
DocuMentor 的面向目的的章节
- 主要内容 – 核心文章文本（通过 Readability 提取）
- 目录 – 页面结构与层级
- 页面链接 – 内容中嵌入的 URL
- 代码块 – 为模式分析单独提取
- 面包屑和导航 – 关于页面在文档中位置的元数据
图示：页面章节根据实际相关信息被策略性地路由到不同功能。
功能‑章节映射
| 功能 | 使用的内容章节 |
|---|---|
| 摘要 | 主要内容 |
| 速查表 | 主要内容 + 代码块 + 页面链接 |
| 视频推荐 | 仅摘要 |
| 学习资源 | 摘要 + 页面链接 + 面包屑 + 导航 |
| 代码模式（深度分析） | 代码块 + 上下文 |
具体示例：视频推荐
一种天真的做法是把完整的 10 K 字文章发送给模型，然后让它寻找相关的 YouTube 视频。这会：
- 在单个功能上消耗大部分 Chrome AI 的 token 配额
- 减慢响应速度（模型在调用 YouTube API 前要处理 10 K 字）
- 在低显存设备上面临配额错误的风险
DocuMentor 的优化流程
- 生成页面的摘要（≈200‑300 词）。
- 将摘要以及用户画像一起发送给 AI。
- AI 根据主题和用户的学习目标生成最佳的 YouTube 搜索查询。
- 扩展程序调用 YouTube Data API（在 AI 之外）。
- AI 对前 10 条结果进行排名，以匹配用户目标和页面摘要的相关性。
- 返回前 3 条视频并附上个性化描述。
结果：相较于发送完整内容，速度提升约 10 倍，token 使用仅为原来的约 1/10。因为 AI 只看到相关信息（摘要 + 画像），推荐更精准。
这种模式在每个功能中都会重复：内容智能并不是给 AI 更多信息，而是给它正确的信息。
跨供应商的自适应提示
最后一层上下文工程：你如何构造请求与发送的内容同样重要。
DocuMentor 在两个 AI 供应商上运行：
| Provider | Characteristics |
|---|---|
| Gemini Nano (local) | • 简单、指令式的说明 • 每个提示只处理一个推理任务 • 防御性输出解析（常返回格式错误的 JSON） |
| Gemini 2.0 Flash (cloud) | • 丰富的多步骤说明 • 支持工具调用 • 可靠的结构化输出 |
persona 和 content sections 保持不变，但 prompt framing 会根据模型的推理能力进行调整。
示例：视频推荐
| Provider | Prompt strategy |
|---|---|
| Gemini Nano (local) | 顺序分解 – 将每一步拆分为单独的 AI 调用： 1️⃣ 生成搜索查询 → 2️⃣ 调用 API → 3️⃣ 排序结果 → 4️⃣ 格式化输出 |
| Gemini Flash (cloud) | 单次工具增强调用 – 模型一次性接收摘要、persona 和生成查询、通过 YouTube 工具获取结果、排序并格式化的指令 |
通过根据每个供应商的优势调整提示，DocuMentor 能在本地和云端环境中实现最高的准确性、速度和 token 效率。
工作原理
LL：模型生成查询，调用 YouTube 工具，对结果进行排序，并格式化输出——全部在一次请求中完成。
用户从未看到这些复杂性。他们点击 “视频推荐”，系统会自动路由到相应的提供商和提示策略。
接下来
这只是 DocuMentor 上下文工程系统的第一个版本。未来迭代我正在探索的两个方向：
1. 用户可自定义的功能提示
让用户能够为各个功能添加个性化指令。例如：
- “在摘要中，始终包含核心概念的简要定义。”
- “在视频推荐时，优先选择时长不超过 15 分钟的短教程。”
- “在建议资源时，侧重官方文档而非博客文章。”
这可以让用户在不必对每个请求细致思考的情况下微调体验。
2. 动态角色
目前，角色是静态的。但全栈开发者可能希望有时以 前端工程师 的视角查看页面，下一次则以 后端工程师 的视角，取决于具体情境。
未来版本可以让用户在每个页面切换角色，甚至根据内容类型自动推断角色调整（例如，在阅读认证相关内容时自动采用 安全聚焦 的视角）。
目标保持不变：个性化而无需过度思考。AI 应该适应你，而不是让你去适应它。
最后思考
构建有效的 AI 功能不仅仅是挑选合适的模型或编写巧妙的提示词。更关键的是为这些提示词提供上下文：
- 零提示 UX – 功能取代聊天框，消除用户的猜测。
- 基于角色的个性化 – 每个响应都会根据角色、技能、目标和偏好进行调整。
- 内容智能 – 通过战略性拆解，确保功能获得恰当的所需信息。
结果是：一个 AI 工具，它的感觉不像聊天机器人，而更像一位了解你目标的知识渊博的同事。
如果你想看到实际效果，请在技术文章或文档页面上尝试 DocuMentor AI。如果你觉得它有用，支持此工作的最佳方式是留下评论并分享给可能受益的人。
我也很想听听你的想法：**你还想了解 DocuMentor 构建的哪些方面？**请留言或联系我——你的反馈将决定我下一篇写作的方向。