夜雨聆风10 分钟开发一个工具分析小红书数据！
AI 的个人生产力提升是一个工具组合问题，不是愿不愿意用的问题！
很多人讨论 AI 生产力时，问题常常被简化成一句话：你愿不愿意用 AI？
这其实是一个误导性问题。
真正决定个人生产力能不能被 AI 放大的，通常不是“态度”，而是“工具组合”。一个人当然可以很愿意用 AI，每天打开 ChatGPT 问十几个问题，但如果 AI 始终停留在聊天框里，不能读取当前网页，不能理解本地文件，不能接入浏览器，不能长期运行一个服务，不能嵌入工作流，那么它能带来的提升很快会碰到天花板。
反过来，一个人未必需要把 AI 当成某种宏大信仰。只要他的工具链设计得足够顺手，AI 会像搜索、截图、浏览器插件、快捷键一样自然进入日常任务。生产力提升不是靠“多问 AI”，而是靠把 AI 放到正确的位置上。
这篇文章想从一个具体案例讲起：我们做了一个“小红书网页即时 AI 解析助手”。需求很简单：
支持在各种网页端直接嵌入 AI 对话入口，AI 可自动抓取当前网页内容，可直接提问分析。例如在小红书笔记网页端，可以让 AI 提炼笔记亮点、拆解内容数据表现、提取评论区高频关键词，实现网页内容即时 AI 解析。
看起来这是一个“让 AI 分析网页”的需求，但真正落地时，它暴露的问题非常典型：AI 个人生产力不是单点模型能力问题，而是端到端工具组合问题。
一、问题不在 AI 会不会分析，而在它能不能进入现场
如果把小红书笔记内容复制出来，粘贴给 AI，让它分析标题、正文、评论关键词，模型当然能做。
问题是，这样的流程太慢。
真实场景里，用户不是为了“使用 AI”而使用 AI。用户是在浏览网页、看笔记、刷案例、找灵感、拆竞品、看评论。这个时候如果要复制标题、复制正文、展开评论、整理格式、打开聊天窗口、粘贴、补充说明，整个动作链路就已经把生产力吃掉了。
所以真正的问题不是：
AI 能不能分析小红书笔记？
而是：
AI 能不能在我正在看的网页里，直接拿到我眼前这篇内容，并且马上回答？
这就是“进入现场”的问题。
聊天框里的 AI 是一个外部顾问。嵌入网页里的 AI 才像一个随身副驾驶。
因此第一层工具组合出现了：
浏览器扩展：负责嵌入页面入口 Content Script：负责读取当前 DOM 本地 Bridge：负责承接网页请求 AI CLI / OpenClaw / Codex：负责真实模型分析 小红书页面：负责提供当前登录态下已经渲染出来的内容
这不是单个 AI 模型能解决的，它需要一组工具互相接力。
二、为什么不是直接爬小红书？
很多人的第一反应可能是：那就写个爬虫吧。
但这类网页端即时分析场景，爬虫未必是最优解。尤其是小红书这种页面，内容通常有几个特点：
依赖登录态 动态渲染 评论区滚动加载 页面结构经常变化 某些内容只在用户当前浏览器环境里可见
如果用服务端爬虫，马上会遇到登录、风控、渲染、接口变动等问题。而用户明明已经在浏览器里打开了页面，浏览器已经拿到了渲染结果、登录态和可见评论，我们为什么不直接读取当前页面？
所以第一版架构选择了浏览器扩展，而不是服务端爬虫。
核心逻辑是：
function extractPageContext() {const metaDescription =document.querySelector('meta[name="description"]')?.content || "";const headings = visibleText("h1,h2,h3").slice(0, 40);const text = (document.body?.innerText || "").replace(/\n{3,}/g, "\n\n").replace(/[ \t]{2,}/g, " ").trim().slice(0, 28000);return {url: location.href,host: location.host,pageTitle: document.title,metaDescription,headings,xiaohongshu: isXiaohongshu() ? extractXhsContext() : null,text};}
这里的关键不是代码复杂，而是架构判断：
让 AI 读取“用户已经看到的东西”，比重新构造一个服务端抓取系统更贴近个人生产力场景。
个人生产力工具最重要的是少打断、少搬运、少切换。浏览器当前页面就是最自然的上下文容器。
三、嵌入入口：AI 应该出现在工作流里，而不是工作流之外
第一版实现中，我们在页面右下角注入了一个 AI 按钮。用户打开网页后，可以直接唤起分析面板。
简化后的注入结构大概是这样：
const root = document.createElement("div");root.id = "codex-page-ai-root";root.innerHTML = `<button class="codex-ai-launcher" title="AI 解析当前网页">AI</button><section class="codex-ai-panel" aria-label="AI 解析当前网页"><div class="codex-ai-top"><div><div class="codex-ai-title">网页 AI 解析</div><div class="codex-ai-subtitle">自动读取当前页面已渲染内容</div></div><button class="codex-ai-close" title="关闭">×</button></div><div class="codex-ai-actions"><button data-prompt="提炼这篇小红书笔记的内容亮点、爆点和可复用结构。">提炼亮点</button><button data-prompt="拆解这篇笔记的数据表现线索，包括标题、封面暗示、互动诱因和可能的传播原因。">拆解表现</button><button data-prompt="提取当前评论区高频关键词、用户痛点和可追问选题。">评论关键词</button></div><div class="codex-ai-log"></div><form class="codex-ai-input"><textarea placeholder="直接问：这篇笔记适合怎么仿写？"></textarea><button type="submit">发送</button></form></section>`;
这个小面板看似只是 UI，但它改变了用户与 AI 的关系。
传统方式是：
用户看网页 用户复制内容 用户打开 AI 用户描述任务 用户粘贴内容 AI 分析
嵌入式方式变成：
用户看网页 用户点 AI AI 自动读取当前页面 用户直接提问
这不是少了两步的问题，而是认知负担的下降。工具越贴近现场，使用成本越低，生产力提升越容易发生。
很多 AI 产品失败，并不是因为模型弱，而是因为入口错了。入口不在用户的任务现场，AI 就会变成“另一个要维护的工具”。
四、Bridge：浏览器不能直接做所有事
浏览器扩展可以读取页面内容，但它不适合直接承载复杂 AI 调用。
原因包括：
API Key 不应该暴露在前端 本地 CLI 只能由本地服务调用 后续可能要接 OpenClaw、Codex、OpenAI API、私有模型 需要统一处理超时、错误、fallback 浏览器跨域、安全策略会限制很多能力
所以我们做了一个本地 bridge，监听 127.0.0.1:4319：
const server = createServer(async (request, response) => {if (request.method === "GET" && request.url === "/health") {sendJson(response, 200, {ok: true,port,aiProvider,aiCommand,aiAgent,aiSessionId,aiTo,codexCommand});return;}if (request.method === "POST" && request.url === "/analyze") {const payload = await readBody(request);const answer = await analyze(payload);sendJson(response, 200, { answer });return;}sendJson(response, 404, { error: "not found" });});
浏览器扩展只负责发请求：
const response = await fetch("http://127.0.0.1:4319/analyze", {method: "POST",headers: { "content-type": "application/json" },body: JSON.stringify({ prompt, context })});
这个 bridge 是整个组合里的关键“适配层”。它让上层 UI 不关心底层到底接的是 OpenClaw、Codex CLI、OpenAI API，还是未来某个本地模型。
个人生产力系统里，适配层非常重要。因为单个工具一定会变：
今天用 OpenClaw 明天想走 Codex CLI 后天要接公司内部模型 再后来要做多模型路由
如果没有 bridge，前端扩展会被底层实现绑死。加了 bridge，工具组合就有了可替换性。
五、失败不是异常，而是工具组合的常态
在实际调试中，我们遇到了几个非常典型的问题。
第一个问题：Chrome 扩展图标是灰色的。
原因不是扩展坏了，而是第一版没有配置 action.default_popup，只做了页面内右下角按钮。于是 Chrome 工具栏里的扩展入口看起来不可用。
后来补了 Manifest：
{"manifest_version": 3,"name": "网页即时 AI 解析助手","version": "0.1.0","permissions": ["activeTab"],"host_permissions": ["http://127.0.0.1:4319/*","http://localhost:4319/*"],"action": {"default_title": "打开网页 AI 解析","default_popup": "popup.html"}}
再加一个 popup，向当前页面发送消息：
const [tab] = await chrome.tabs.query({active: true,currentWindow: true});await chrome.tabs.sendMessage(tab.id, {type: "codex-page-ai-toggle"});
页面里的 content script 接收消息：
chrome.runtime?.onMessage?.addListener((message) => {if (message?.type !== "codex-page-ai-toggle") return;const isOpen = panel.classList.toggle("open");launcher.style.display = isOpen ? "none" : "block";});
这说明什么？
说明用户体验问题经常不在 AI，而在工具边缘。图标灰色、页面没刷新、content script 没注入，这些都不是模型问题，却会直接决定用户觉得“能不能用”。
第二个问题：扩展提示 Failed to fetch。
这也不是 AI 模型问题，而是本地 bridge 没启动。
检测方式很简单：
lsof -nP -iTCP:4319 -sTCP:LISTEN或者：
node --input-type=module -e "const r = await fetch('http://127.0.0.1:4319/health');console.log(await r.text());"
如果没有服务，就启动：
cd /Volumes/jeff/codex-project/projects/xhs-page-ai-assistant/bridgenpm run start
第三个问题：页面抓取成功了，但显示“没有成功调用 openclaw”。
这次问题在 AI provider。OpenClaw 的 agent 命令不能裸调，需要指定 --agent、--session-id 或 --to。否则它会报：
Pass --to <E.164>, --session-id, or --agent to choose a session于是我们把 bridge 改成 provider 链：
async function runAi(prompt) {const errors = [];if (aiProvider === "openclaw" || aiProvider === "auto") {try {return await runOpenClaw(prompt);} catch (error) {errors.push(`openclaw: {error.message}`);if (aiProvider === "codex") {throw new Error(errors.join("\n"));}}}throw new Error(errors.join("\n"));}
这个改动非常关键。因为它把“单工具失败”变成了“工具组合继续工作”。
生产力系统不能假设每个环节永远在线。它应该有降级机制：
OpenClaw 有配置就走 OpenClaw 没配置就走 Codex CLI Codex 也失败就返回本地启发式分析 同时把失败原因暴露出来，方便继续修
这才是可用工具链的样子。
六、AI 调用不是一个函数，而是一条链路
很多 demo 会把 AI 调用写成一个简单函数：
const answer = await callAI(prompt);但真实系统里，callAI 背后至少有这些问题：
prompt 怎么构造？ 网页内容太长怎么办？ 当前页面内容不足时怎么提示？ CLI 超时怎么办？ stdout 是文本还是 JSON？ 模型返回结果写在哪里？ 失败后怎么 fallback？ 如何避免前端暴露密钥？ 如何给用户可理解的错误信息？
在我们的 bridge 里，prompt 构造大概是这样：
function buildAgentPrompt(userPrompt, context) {return `你是一个网页内容分析助手。请基于用户当前浏览器页面已经渲染出来的内容回答，不能编造页面里没有的信息。用户问题：{JSON.stringify(compactContext(context), null, 2)}回答要求：1. 用中文。2. 如果是小红书笔记，优先输出：内容亮点、互动/数据表现线索、评论关键词/用户痛点、可复用选题或仿写建议。3. 如果页面内容不足，明确告诉用户需要打开具体笔记、展开评论或滚动加载。4. 输出要短而有洞察，不要复述大段原文。`;}
这里有几个有意设计的约束。
第一，要求“不能编造页面里没有的信息”。因为网页即时分析很容易让用户误以为 AI 看到了全部内容，但扩展实际只能读取当前 DOM。评论没展开、图片没识别、隐藏内容没加载，AI 就不应该假装知道。
第二，要求“如果页面内容不足，明确告诉用户”。这能把失败从“系统坏了”转成“你需要滚动加载评论”。用户知道下一步该怎么做，工具就不会显得神秘。
第三，要求“不要复述大段原文”。网页分析的价值不是搬运，而是压缩、判断、抽象、建议。
生产力工具中的 prompt 不是随便写一段角色设定。它是用户体验、系统边界和错误处理的一部分。
七、从“愿不愿意用”到“能不能无缝用”
回到开头的问题：为什么说 AI 的个人生产力提升是工具组合问题，而不是愿不愿意用的问题？
因为“愿意”只能解决心理门槛，不能解决操作摩擦。
一个愿意用 AI 的人，如果每次都要复制、整理、粘贴、描述背景、等待结果，他很快会减少使用。不是他不认可 AI，而是链路太重。
一个不怎么强调 AI 的人，如果浏览器里有一个按钮，能自动读取当前内容，能直接问“这篇为什么火”“评论区用户痛点是什么”“能不能仿写成我的行业版本”，他反而会自然地高频使用。
真正的生产力提升来自这些问题被解决：
AI 能不能拿到上下文？ AI 能不能出现在任务现场？ AI 能不能调用本地工具？ AI 能不能在失败时降级？ AI 能不能减少用户整理材料的时间？ AI 能不能用快捷入口匹配高频任务？ AI 能不能被替换、扩展、组合？
这就是工具组合问题。
在这个案例里，真正有价值的不是“让 AI 分析小红书”这句话，而是这条链路：
小红书页面↓Chrome Extension 注入入口↓Content Script 抓取 DOM↓Local Bridge 接收上下文↓OpenClaw / Codex CLI / 其他模型↓返回结构化洞察↓页面内继续追问
当这条链路跑通后，AI 就不再是一个额外应用，而是网页能力的一部分。
八、个人 AI 工具栈的几个设计原则
从这个小项目可以抽象出几个更通用的原则。
1. 优先接入现有工作流，而不是发明新工作流
用户已经在浏览器里看网页，就不要要求他去另一个系统上传链接。用户已经在本地写文档，就不要要求他手动复制到 AI 页面。AI 应该嵌进当前工具，而不是把任务迁移到 AI 工具里。
2. 上下文自动化比模型炫技更重要
很多时候，用户问 AI 之前最烦的是整理上下文。标题、正文、评论、URL、当前状态，这些都应该由工具自动收集。上下文自动化做得好，普通模型也能产生很高价值。
3. 本地 bridge 是个人 AI 系统的重要组件
浏览器、桌面应用、CLI、文件系统、模型 API 之间需要一个适配层。本地 bridge 可以承接这些连接，让上层入口保持轻量。
4. 允许多 provider，而不是押注单点
OpenClaw、Codex CLI、OpenAI API、本地模型都可以成为 provider。个人生产力系统应该允许切换，而不是绑死一个命令。
5. 失败信息要可操作
“Failed to fetch”对用户没有帮助。更好的提示是：
本地 bridge 未连接。请启动：cd .../bridgenpm run start
工具组合越复杂，错误提示越要像操作指南。
6. 先做可运行闭环，再做智能增强
第一版不必完美识别所有小红书字段。先把“页面入口 → 抓取内容 → AI 分析 → 页面返回”跑通，后续再优化评论抽取、图片理解、数据结构化、历史记录、批量分析。
九、下一步可以怎么演进
这个原型已经证明了方向，但如果要变成更完整的个人生产力工具，还可以继续做几层增强。
第一，改进小红书 DOM 抽取。当前主要依赖可见文本和 class 模糊匹配，后续可以针对笔记标题、正文、作者、发布时间、点赞收藏评论数、评论列表做更稳定的结构化抽取。
第二，加入截图和视觉理解。很多小红书笔记的关键信息在封面和图片里，只读 DOM 不够。可以让扩展抓取当前视口截图，或者提取图片 URL，交给多模态模型分析封面钩子、版式和视觉卖点。
第三，做历史分析记录。用户分析过的笔记可以保存为本地库，后续做选题池、爆款结构总结、账号对标报告。
第四，做 prompt 模板系统。不同场景需要不同问题模板，比如：
拆标题钩子 提炼封面卖点 评论痛点聚类 仿写成律师行业版本 生成 10 个二创选题 判断是否适合投流 生成账号定位建议
第五，做自动保活。当前 bridge 停了就会 Failed to fetch。后续可以做成 LaunchAgent、菜单栏应用，或者让扩展检测不到服务时给出一键启动指引。
第六，做跨网站通用适配。不只小红书，B 站、抖音网页版、知乎、公众号文章、淘宝商品页、飞书文档、Notion 页面，本质都可以走同一套“当前页面上下文 + AI 分析”的架构。
到这里，AI 才真正开始变成个人操作系统的一部分。
结语：AI 不是一个按钮，而是一组连接
AI 个人生产力的核心，不是“我今天有没有打开 AI”，而是“AI 有没有被放进我正在工作的地方”。
如果 AI 只是一个聊天窗口，它当然有价值，但它仍然需要用户主动搬运上下文。 如果 AI 能进入浏览器、文件、命令行、文档、表格、知识库、自动化脚本，它就开始从“问答工具”变成“生产力层”。
所以，个人生产力提升不是愿不愿意用 AI 的问题。
愿意用，只是开始。 真正的分水岭是：你有没有把 AI 和你的工具组合起来。
浏览器扩展解决入口，本地 bridge 解决连接，CLI/模型解决推理，fallback 解决稳定性，prompt 解决任务边界，页面内交互解决使用摩擦。它们合在一起，才构成一个真正可用的 AI 工作流。
未来的个人效率差距，可能不取决于谁更相信 AI，而取决于谁更会搭工具链。
不是“你愿不愿意用 AI”。 而是“AI 能不能在你需要它的那一秒，已经站在现场”。
