OpenAI 近期为 Codex 带来了一个重要更新——现在可以直接调用 Chrome 浏览器了。

看到这个消息后，我立刻把“必装 Chrome”提上了日程。不过，这和我接下来要强调的内容并不冲突——打开浏览器本就是 AI 工具的必备能力，也是日常工作中绕不开的刚需场景。

然而当我第一时间上手尝试时，发现浏览器插件暂时无法安装，只好暂时搁置。

具体的使用方式目前还不明朗。看起来 Codex 是把原先 Browser Use 这类插件的能力直接集成到自身中，以后可能就不再依赖第三方插件了。

但需要留意一点：Browser Use 有一个非常明显的优势——它可以操控几乎所有浏览器，而 Codex 原生集成的能力目前只能打开 Chrome。从灵活性的角度看，估计还是独立的 Browser Use 更好用。

因此，我的推荐不变：Codex 务必安装 Browser Use，Claude Code 务必安装 Playwright。

装上这两个插件，就相当于给你的 Codex 和 Claude Code 装上了“眼睛”和“手”——它们终于可以自己去看网页，然后亲自操作页面了。

浏览器能力为何成了 AI 工具的刚需

浏览器是我们日常工作中使用频率最高的工具，绝大多数信息输入都来自浏览器。

以前，AI 工具想要收集信息，靠的是编写 Python 脚本去网站抓取数据。所以当我们甩给大模型一个链接让它阅读时，它必须先写代码，然后再读取内容。

这种方式既绕了远路，又不太符合人类的使用习惯，速度慢，效果也常常不尽如人意。

现在你给它装上 Browser Use，它就可以自己打开网页去看，效果提升非常明显。

Playwright 与 Browser Use：为 AI 补齐浏览器能力

Playwright 和 Browser Use 的作用本质上是一样的——都是在给 AI 补上浏览器操作这块短板。

它们让 AI 不再只是在对话框里聊天，而是可以真正打开网页、阅读内容、点击按钮、填写表单，甚至截图验证。

因此，它们最合适的场景也高度重叠：

周末在家浏览开源项目时，一个极富创新的东西牢牢抓住了我的眼球。

来自 Y Combinator（全球顶尖创业孵化器）现任总裁 Garry Tan 刚刚开源的一个神级 Skill。

说实话，我最初只当它是个普通的 AI 代码助手。

但看完他贴出的真实数据后，我觉得其中大有门道，必须好好拆解。

这位日程爆满的顶级孵化器 CEO，在过去 60 天内，硬是一个人敲出了 60 多万行生产级代码。

平均每天，即使在兼职状态下，也能稳定产出 1 到 2 万行可实际使用的代码。

这简直不可思议。

难怪 Skill 要用得对才行——连 OpenClaw 这样厉害的龙虾，也是 AI 自己造出来的。

我顺着线索，仔细研究了他开源的该项目 Gstack。

其核心 Skill 由 621 行指令构成。

但它所做的事，极其硬核。

它直接让你原地成为 CEO，并且在系统中内置了整整 15 个极其专业的 AI 角色。

创始人、高级设计师、工程经理、代码审查员、QA 测试工程师……一个建制极其完整的虚拟工程团队，全部为你配备齐全。

光看不练肯定不行。

尽管它原生是为 Claude Code 准备的，但 CC 能用，龙虾也能用，我直接给我的 OpenClaw 装上了这个 Skill。

我从过往项目中挑了一个半成品，交给龙虾使用此 Skill 继续开发；设好明确的验收标准后，我就喝咖啡去了。

结果，它自己闷头跑了整整两个小时，居然真的做到了全自动闭环。

没有卡顿，没有凭空捏造的幻觉，它极其严谨地交付了一整套完整的代码。

我之前只造了个 Demo，缺少鉴权、没有权限分配，它一声不吭全帮我搞出来了。

我花了时间，好好扒开它的底层逻辑。

很多用户在使用AI对话工具时，习惯在一个窗口里持续交流，不愿意重新开启新的对话。从早期的豆包、元宝，到如今的Claude Code、Cursor等开发辅助工具，这种“舍不得重开”的现象十分普遍。

对于“上下文”（Context）这个概念，不少人最初并不清楚它的含义，也未曾在意过。

随着对AI工具的深入使用，大家才逐渐理解Context的意义，以及上下文工程（Context Engineering）的重要性。回顾过去，因为长期在一个窗口堆积大量信息而浪费的Token，难免让人惋惜。

可能很多你身边的朋友也和你一样，虽然用了很久AI，但对上下文的理解仍停留在模糊阶段。本文就将帮助你彻底搞懂上下文——从基础概念到高阶技巧，一网打尽。

说明：本文中的命令示例基于Claude Code和Cursor，使用方法在各主流工具中均可通用。

上下文到底是什么？

一句话概括：上下文指的是AI对话窗口中，你与AI的所有交流内容、你让AI读取的文件信息，以及AI如何理解并处理这些信息的一整套过程。

基础使用方法

使用过AI聊天工具的人，基本都懂得一些“喂上下文”的基础操作——提供背景信息、粘贴文本、@引用某个文档等。这些常规操作这里不再赘述。

然而，仅仅知道“怎么用”还远远不够。只有避开常见的坑、掌握高阶技巧，才能真正拉开差距。

你可能不知道的：上下文的坑和技巧

技巧1：喂材料要精准，别“All-in”

很多人以为给AI的材料越多越好，恨不得把整个项目文件夹全部丢进去，期待它能“全面了解”。

但结果往往事与愿违：重点被海量信息淹没，AI在庞杂的材料中难以抓住关键，反而给出平淡无奇的回答。

正确的做法是：能引用单个文件就不要引用整个目录，能提取相关段落就提前手动缩小范围。先提供摘要，再补充长内容，切忌一股脑地甩出大段文本。

在Cursor中使用时，尽量@单个文件而非整个文件夹；在Claude Code中，可以指定路径让AI自己搜索，而不是将大段代码直接粘贴到对话中。

技巧2：不相关的任务一定要分开聊

不同性质的任务不放在同一个窗口里讨论，这一点比较好理解。混在一起有两大坏处：一是无关内容白白占用上下文空间，二是AI容易被之前的话题干扰，给出牛头不对马嘴的答复。

需要特别强调的是：即便是同一个项目，如果是完全不同的工作任务，也建议开设不同的窗口。

举个例子，你刚用AI完成了一份PPT，效果不错，下一个PPT还想在同一窗口里做。这种做法不太合理。首先，窗口可能已打开很久，缓存早已失效，继续使用意义不大。其次，即便时间不长，前后两个PPT的主题差异过大，原来积累的上下文对新的工作毫无帮助，只会占用宝贵空间。

Claude Code中有一个很好用的命令/btw（by the way），意为“顺便问一下”。询问完毕即删除，不会占用上下文。这个命令充分体现了程序员的巧思，值得善用。

技巧3：上下文超过50%就该另开窗口——但别开得太频繁

这是广为认可的经验，Claude的开发人员也给出过类似建议。

上下文的空间并非无限。每个模型都有上下文窗口的上限，通常用百分比来衡量。当占用达到50%左右时，AI就会开始“挤占”——前面的内容被压缩，重要细节可能丢失，回答质量显著下滑。

因此，养成这样的习惯很有必要：上下文占用到50%时，该清理就清理，该另开窗口就果断重开。不要不舍得那个对话，继续堆积只会让效果越来越差。

在Claude Code里，输入/context可以查看当前上下文占用情况。Token即将超出时，不妨及时查看，做到心中有数。

Cursor中没有直接查看占用的命令，但在聊天界面有一个上下文栏，能够显示当前引用了哪些文件、上下文大致填满了多少。一个用命令，一个用界面，直观程度差不多。

不过，这里有一个反直觉的要点：频繁开新窗口不一定省钱。

背后的玄机在于缓存机制。AI每次收到你的消息，都需要从头“阅读”整个上下文——系统指令、工具定义、CLAUDE.md中的规则、此前所有的对话记录。在同一个窗口中，前面那些不变的内容会被缓存起来，下次读取缓存的成本只有重新计算的十分之一。

而一旦你新建了一个窗口，之前积累的缓存全部作废，数万Token的“基础设施”又需要重新全价加载。频繁使用/clear或每做一步就开新会话，等同于反复为这些不变的内容支付全价。

这个缓存机制在Claude Code和Cursor中同样适用。Cursor虽然没有/clear命令，但新建Chat的效果是一样的——之前的缓存白存了。

因此，正确的心态是：能继续就继续，开新窗口是有条件触发的操作。

什么条件该继续？

任务没换、距离上一条消息不超过1小时、之前的上下文对当前工作仍有帮助——那就继续聊，缓存还是热的，几乎不花钱。如果暂时没有新想法但不想让缓存过期，可以发一条简短消息来保持活跃。

什么条件该重开？

任务已更换、闲置超过1小时（缓存大概率已过期）、上下文塞满了不相关的“噪音”——那就果断重开。

个人的实践心得是：一个会话只专注完成一件事，这样一来几乎不会触发配额问题。

技巧4：超出上下文限制怎么办？用命令“续命”

有时一个窗口聊了很久，内容确实很重要，不想就此放弃，但上下文眼看就要塞满了。这时有两个“续命”方法：

/compact：压缩对话历史，对之前的内容进行总结，腾出更多上下文空间。交流多轮之后，用它能有效延续会话寿命。这是Claude Code的命令，Cursor目前没有对应的手动命令，但它会在上下文接近满载时自动压缩（侧边会提示“Summarizing chat context”），效果相同，只是不能主动触发。

/summarize：如果不想丢失历史信息但对话已经过长，可以用这个命令让AI提取核心信息（关键背景、已做决策、待解决问题），上下文能被压缩到原本的15%以内。Claude Code和Cursor都支持此命令。

两者的思路一致：上下文快满时，要么压缩，要么另起炉灶。

技巧5：长内容给路径，别往对话里贴

面对报错日志、大段代码、长文档时，很多人的第一反应是复制粘贴到对话中让AI自己去查找。

请不要这么做。

将10000行日志直接复制粘贴到对话里，这些内容会永久占据你的上下文空间，每一轮新的对话都要重新“阅读”一遍。更聪明的做法是把文件路径发送给AI，让AI自行检索需要的信息，只把真正相关的内容拉入上下文。

在Claude Code中，直接把路径写在对话中即可，AI会使用grep等工具去搜索。在Cursor里，用@引用文件——注意，能@单个文件就别@整个文件夹，引用粒度越细，上下文越干净。

请牢记一句话：最便宜的Token，是根本没进入上下文的Token。

上下文管理并非玄学，而是一种可以培养的良好习惯。给AI喂对材料、控制好用量、将不相关的任务分开讨论、长内容传递路径而非直接粘贴——做到这几点，你已经领先了大多数用户。

善用上下文，另一个直接的好处就是节省大量Token。当下算力竞争日趋激烈，AI不断进化，各大模型的Token单价持续走高。未来谁能用最少的Token完成工作，谁就更有可能获得效率优势。学会管理上下文，其实就是掌握了节约Token的关键能力。

想必大家按我的方式用完智谱的免费额度后，正在寻找新的替代方案。这次为大家推荐腾讯最新发布的Hy3大模型，目前同样可免费使用。

下面就来详细介绍如何免费接入Hy3。

整个过程仅需两步：首先登录OpenRouter平台，接着找到Hy3模型并完成接入。

请跟随我的步骤逐一操作。

一、认识OpenRouter并获取密钥

OpenRouter是全球知名的AI大模型聚合服务平台，安全可靠，无需担心风险。

访问官网：https://openrouter.ai

进入后需要注册账号，这样才能拿到API密钥以便在cc-switch中进行配置。（注册流程十分简单，相信大家都能顺利搞定。）

注册完毕，获取密钥。打开cc-switch，找到图中红框标示的OpenRouter专属入口，将密钥直接粘贴进去即可。

二、搜索并接入腾讯Hy3模型

接入密钥后，点击“Models”，在搜索框中输入“hy3”，即可找到该模型。注意括号内的“free”字样，代表当前完全免费。作为国内大厂出品的模型，Hy3相比那些不知名的免费模型要可靠得多。

免费政策随时可能调整，建议尽快接入使用。

要接入Hy3，首先进入其详情页，然后点击“API”标签，复制红框标注的内容。（注意，只复制引号内的文本，双引号本身不要复制。）

模型标识符为：tencent/hy3-preview:free（直接复制这个也行）

返回cc-switch，在先前选择OpenRouter供应商的那个界面中，将复制的模型标识符粘贴进去。为确保无误，建议每个与模型标识相关的输入框都粘贴一遍，如图所示。

点击保存，配置完成。

此时打开你的Claude Code，就能看到Hy3模型已经成功接入了！

三、更多免费模型接入技巧与注意事项

在OpenRouter上，你还可以探索并接入其他免费模型。在搜索框输入“free”，便会列出一系列当前免费的模型。

参照上面的方法，只需将类似tencent/hy3-preview:free的标识符粘贴进去，就能替换成任意你想调用的大模型。

你也可以尝试粘贴通用的openrouter/free，它会自动调度当前空闲的免费模型。但经我实测，效果很不理想，容易调用到能力很差的模型，基本无法解决实际问题，因此不建议使用。

以上步骤顺利完成后，恭喜你，Claude Code又多了一份免费的调用额度。

当然，免费服务也有局限：每天调用次数限制为50次，超出后会返回429错误。

若觉得50次不够用，可以考虑充值10美元，这样每日免费模型的调用次数将提升至600次，且不会消耗那10美元的余额。

目前还不清楚腾讯Hy3是否设有每日免费上限，但从我开始撰写本文至今已过去两小时，它仍在稳定执行我交给的任务，还未中断。

现在就按照本教程为你的CC接入Hy3，然后构思一个想要实现的项目，这个假期便可以安心在家享受“vibe coding”的乐趣了。

腾讯云 · Hy Token Plan

腾讯云全新推出 Hy Token Plan，
一款专注 Agent 工作负载的高性价比套餐

腾讯云基于自研混元 Hy3 Preview 模型推出 Hy Token Plan，个人版最低 28 元/月，为 Agent 工作负载量身定制的专属订阅方案。

从 Coding Plan 再到 Agent Plan，各大云厂商的价格与技术博弈日趋激烈。继火山方舟的 Agent Plan 深度解析之后，腾讯云携 Hy Token Plan 强势入局。如果说火山方舟的优势在于“模型生态丰富”，那么腾讯云这次打出的牌则是“精准”与“省钱”。

Hy Token Plan 是一款专门面向 Agent 工作负载的专属订阅计划，直接针对当前 Coding Plan 实用性不足的痛点。个人版最低仅需 28 元/月，对于频繁调用 API 的 Agent 工具（如 OpenClaw、Hermes）而言，无疑是一个极具吸引力的新选择。

01

🚀 产品核心优势

与市场上通用化的 Token 订阅不同，Hy Token Plan 有着极其垂直的产品定位：专为 Agent 工作负载打造。

它基于腾讯 2026 年 4 月全新发布的自研混元Hy3 Preview模型构建。

越是深入探索AI工具，越能体会到：真正起决定性作用的，其实是最原始的那一点——你是否会写提示词（prompt）。

知名技术大V卡帕西一直把一句话挂在置顶位置：

含义很简单：只要你会说话，能把问题描述给AI，它就能帮你实现。这句话从根子上点明了提示词的基础价值和不可替代性。

然而，“会说话”和“会表达”之间隔着巨大的鸿沟。我用一段亲身经历来说明这点。

用Word编辑任务的实战教训

有一次，我想让AI帮忙优化一个方案文档，其中某个章节不符合要求，需要修改。我把整个方案丢给AI，并指出这个章节不行，得优化。我当时写的提示词如下：

帮我优化一下这个方案，要求：

1. 按照“数据采集—数据治理—数据分析—数据展示”的结构，重新组织下一级内容。
2. 当前文档中的文字内容不动，只是把它们归到对应的板块下面。
3. 标题、字体都要和原文档保持完全一致。

接着我把那份文档也附了上去。

我自认为描述已经足够清晰，结果AI交付的成果却一塌糊涂。我分别在Claude Code、Workbuddy、Codex里用这段提示词跑了一遍，甚至切换了不同模型，硬是折腾了五个小时，也没得到满意的结果。

我复盘下来，情况是：

• Claude Code + MiMo：内容改得可以，但格式完全对不上。
• Workbuddy + hy3：格式还能用，可内容质量不行。
• Codex + ChatGPT：内容和格式都还过得去，但耗时极长，整个过程将近拖了一小时。

我深入观察了每个工具和大模型处理这项任务的方式，发现它们背后的处理流程大相径庭。在梳理了各自的优劣势之后，我总结出一条最佳处理路径，然后把提示词改写成这样：

给我优化一下这个方案，优化方法是：

1. 先把这份Word文档转成Markdown格式，然后再去读取里面的内容。
2. 找到XX章节，将该章节的内容按照“数据采集—数据治理—数据分析—数据展示”的结构编写。编写完成后，生成一份新的Markdown文档。
3. 把生成的Markdown文档转换回Word格式，具体做法是：

1）将原Word文档中“数据设计”这一部分整体复制到新Word文档中。  
2）将Markdown里的内容按同样格式转换进去，同时保留原文档的标题格式、字体和编号样式。

4. 把生成的新Word文件复制回原文档中（这一步你也可以手动复制，自行选择）。

神奇的事情发生了。原本每个AI工具都会花大量时间、效果还不理想的同一个任务，随着这条提示词的改写，全部给出了符合我预期的成果，而且整体工作时间也明显缩短。我不由得发自内心地感叹：提示词这件事，真的太重要了。

写提示词，真的是一门手艺活儿

现在很多面试中都会出现一个高频问题：“你写提示词的原则是什么？”网上能找到一套标准答案，大家可以自行搜索。

但我想说的不是那个标准答案，而是我本人对提示词的理解。

首先，提示词的复杂度取决于你要完成的工作的复杂程度。简单的事情，随便问就行，没什么可说的，正如大神卡帕西所言，会说人话就好。

而面对复杂任务时，第一要务是你自己必须先把“到底要什么”想清楚，然后再组织成提示词，交给AI。如果自己都表达得含含糊糊，反而不要描述太多——半明不白的提示词更容易把AI带偏，还不如用一句话直接交代。这就好像一位不懂装懂的领导胡乱指挥，结果同样糟糕。

当你用一句话把意图说清楚时，AI至少会基于自己的推断形成思考闭环，做出来的东西有基本的逻辑。随后你再进行微调，甚至推倒重来，就都随你掌控了。

复杂工作的另一种处理方法就是拆分，也就是项目管理中的WBS（工作分解结构）。把大任务拆成一个个小包，为每个小包装写好提示词，再按照先后顺序依次喂给AI。这也是非常原始但有效的办法。想起来去年我用豆包写方案时，就是自己先把章节结构搭好，把每个小节要写什么明确告诉豆包，然后由它一段一段地输出。现在大模型越来越聪明了，生成一个完整方案的便捷性已经大大提高，不再需要逐段复制粘贴。

但即使如此，用AI工具写方案时，“读取资料—撰写方案—转为Word”这些环节，仍然需要拆分开来。

这样做的好处，首先是让你作为“项目经理”拥有了里程碑和检查点。哪个环节出问题，就可以直接在这个环节调整，充其量这叫“变更”；要是等整个完整交付以后再改，就成了“返工”。返工的成本远比变更高得多。把这个逻辑照搬到AI工作流程里也是一样：过程中发现错误，及时修正，不会对后续产生连锁影响。这正是项目拆分思想的精妙之处。

结语

AI不是万能的，并非所有事情都可以一股脑儿丢给它完成。说到底，AI是基于预训练数据集运转的，它的能力存在明确的边界，一旦任务超出了它的数据覆盖范围，它也会“宕机”。

而你的工作有着极强的特殊性，背后许多坑、许多经验，只有你自己清楚。大模型一开始做这件事时并没有现成的参考，必须由你来讲清楚，它才能规避那看不见的陷阱。

而你究竟能否讲清楚，能否将提示词写成结构化、流程化、清晰化的表达，直接决定了AI能否真正帮你把这份工作漂亮地完成。

根据 Statista 统据，2023 年谷歌搜索引擎的全球市占率高达 93.12%，对于中国出口电商与跨境贸易企业而言，Google 广告几乎是触达海外用户、驱动询盘与成交的必经之路。正因如此，熟悉并善用谷歌搜索引擎，成为每一位外贸独立站运营者无法回避的课题。

好在谷歌围绕网站运营生态，打造了一系列强大且完全免费的工具，能帮助站长快速诊断问题、洞察趋势、优化表现。下面我们将逐一解读这些值得每一位外贸人选掌握的谷歌利器。

Google Search Console（谷歌站长工具）

Google Search Console（谷歌站长工具）是网站管理者不可或缺的中央控制台，其核心价值在于全方位监控指向网站的外部链接。透过这个平台，你可以准确掌握哪些网站引用了你的内容，从而精准把握外链全貌。一旦发现来源可疑或对排名有害的垃圾外链，站长工具便允许你主动“拒绝”这些链接，清除其对网站的负面影响。这种主动防御能力，是维护网站健康、确保搜索引擎表现持续向上的关键护盾。定期使用谷歌站长工具，可以让你在问题萌芽阶段就及时拦截，为网站赢得更稳健的搜索排名。
入口：https://search.google.com/search-console

PageSpeed Insights

PageSpeed Insights 是 Google 推出的免费网页性能测评工具，它的任务就是对加载速度进行全方位体检。该工具会深度扫描你的页面，基于多项关键指标给出综合评分，并附上一份针对性极强的优化清单。通过这些建议，你能精准定位拖慢网站速度的瓶颈——比如未压缩的图片、阻塞渲染的资源等，从而有针对性地提速，显著改善用户浏览体验。
入口：https://pagespeed.web.dev/

Google Analytics（谷歌分析）

Google Analytics（谷歌分析）是谷歌官方的数据分析利器，帮助卖家实时追踪网站流量、用户来源、转化事件等核心数据。值得新手特别留意的是，GA 系统需要一到两周的数据积累周期才能呈现有效分析，因此强烈建议在启动任何广告投放之前就完成安装，这样一上线即可捕捉到高质量的数据信号，为后续优化提供可靠依据。
入口：https://analytics.google.com/analytics/web/provision/#/provision

Google Trends（谷歌趋势）

Google Trends（谷歌趋势）是一款与百度指数功能类似的免费趋势探针。基于谷歌庞大的搜索数据，它能够展现任何话题或关键词在不同时间段、不同地区的搜索热度变化以及相关查询的分布情况。无论你是要验证产品季节性，还是挖掘新兴市场兴趣点，谷歌趋势都能为你提供直观的数据参考。
入口：https://trends.google.com/trends/?geo=US

Google 全球商机洞察

谷歌全球商机洞察（Market Finder）是一个专为出口企业设计的情报工具。它能够结合你的网站产品，智能分析潜在的海外高价值市场，呈现竞争对手格局以及各渠道广告投放的成本与收益数据。当你准备将产品推向全球，却不知何处切入时，只需借助该工具即可快速获取市场排名、获客成本、行业概况等关键情报，从而准确锁定最适合产品出海的目标市场。
入口：https://marketfinder.thinkwithgoogle.com/intl/en_us

谷歌广告联盟（Google AdSense）

谷歌广告联盟（Google AdSense）是谷歌旗下久经考验的广告变现平台。它允许网站主在自己的页面上展示与内容高度相关的广告，并从中获取收益。网站主只需简单管理广告位，谷歌的智能算法便会自动匹配最合适的目标广告，实现流量价值的最大化。对经营者来说，AdSense 不仅是变现渠道，更是一个免费观察竞争对手素材创意的绝佳窗口。
入口：https://adsense.google.com/start/

谷歌广告资料库

2023年7月起，谷歌推出一项新的广告透明度政策，正式上线广告资料库（Ads Transparency Center）。这一工具类似 Meta 的广告图书馆，用户可以通过品牌名称搜索其正在投放的广告，还能按地区、格式进行过滤，并查看广告的最后投放日期。对于外贸运营者而言，这意味着可以更轻松地研究竞品的广告素材、创意策略与投放节奏，为自身的广告优化提供一手参考。
入口：https://adstransparency.google.com

Chrome 应用商店扩展程序

Chrome 应用商店集结了数不胜数的浏览器扩展，可大幅提升跨境电商的工作效率。标签页管理类插件能帮助你轻松处理多任务切换、标签合并与批量操作；信息提取插件则可以一键抓取网页中的文字、图片等核心内容；广告拦截扩展为你营造无干扰的整洁浏览环境；安全检测类插件还能自动拦截恶意网站，保护账号与数据安全。善用这些轻量级工具，往往能让独立站的日常运营事半功倍。
入口：https://chromewebstore.google.com/

面对复杂的 GitHub 仓库无从下手？只需输入仓库地址，这些工具就能带领你快速拆解核心逻辑，彻底理解项目架构。

深度拆解引擎：DeepWiki

开源仓库：https://github.com/AsyncFuncAI/deepwiki-open

在线访问：https://deepwiki.com/

DeepWiki-Open 是一个开源工具，能够将任何代码仓库（无论是 GitHub、GitLab 还是 BitBucket）瞬间转变为结构精美、交互丰富的 AI 驱动 Wiki 文档站点。你只需粘贴仓库 URL，它便会自动解析代码库，生成包含 Mermaid 可视化图表的详尽文档，并将所有内容整理成易于导航的 Wiki，全程无需人工编写。

DeepWiki 的核心运作机制本质上是执行一个多阶段处理流水线：它克隆目标仓库，将每个源文件读取并分块，然后将这些代码块嵌入向量数据库以实现智能检索，最后通过实时 WebSocket 连接，逐页流式传输 LLM 生成的文档。最终呈现的是一个精致的 Wiki，包含架构图、组件拆解、数据流可视化以及相互交叉引用的页面——所有这些都在一个支持明暗主题切换的 Web 界面中呈现。

该系统还内置了 Ask 功能，允许你借助检索增强生成（RAG）技术直接与仓库进行对话；更有 Deep Research 模式，能够对复杂主题进行多轮迭代式深度调研，在多达 5 轮研究循环中综合各项发现，最终给出全面详尽的解答。

中文开源解读专家：Zread

在线访问：https://zread.ai

Zread 是由智谱 AI 推出的一款 AI 驱动、完全免费的 Github 项目阅读神器。它通过结构化代码分析与深度知识萃取，一键生成清晰易懂的 GitHub 项目中文文档，帮助开发者迅速掌握优秀项目的核心架构、实现逻辑与最佳实践。

• 一键生成项目文档：只需要输入 GitHub 仓库地址，Zread 就能自动梳理项目脉络，输出内容涵盖目录架构、代码流程图、核心功能拆解以及使用指南等，极大降低开源项目的学习门槛。

代码知识图谱交互器：GitNexus

项目地址：https://github.com/abhigyanpatwari/GitNexus

核心理念：将代码视为知识图谱，实现实时交互

你可以将代码库想象成一个活生生的有机体。单个文件是细胞，函数和类是蛋白质，导入语句是突触连接，而调用链则是神经通路。传统的代码搜索工具——比如 grep、IDE 的查找引用，甚至基于 LSP 的跳转到定义——只能让你一次检查一个细胞。GitNexus 则构建了完整的神经系统：它映射每一个细胞，追踪每一条通路，把相关的细胞分组为功能性器官（集群），并记录神经触发的完整序列（执行流）。这张结构图持久化保存在本地图数据库中，并通过 Model Context Protocol (MCP) 提供给 AI Agent，赋予它们任何提示词工程都无法复刻的能力：对代码架构的真正理解。

开源地址：https://github.com/alibaba/page-agent

Page Agent 是一个完全运行在浏览器中的 AI 驱动自动化框架。它彻底摆脱了传统自动化方案对无头浏览器、Python 运行环境或浏览器扩展的依赖，以极其轻量的页内 JavaScript 库形式存在。这意味着任何 Web 应用都能通过自然语言直接控制，完全不需要后端基础设施。

该项目由阿里巴巴开发，基于 MIT 许可证维护，当前版本 1.6.1。整个工程采用 TypeScript monorepo 架构，借助 npm workspaces 统一管理，并使用 Vite 作为构建工具。

Page Agent：连通大语言模型与现实网页的桥梁

Page Agent 的根本价值在于，它在大语言模型与可交互的 Web 页面之间建立了一座通道。你只需用一句自然语言发出指令，例如 “点击登录按钮并填入我的邮箱”，代理就会自主观察页面状态、推理下一步行动，并在循环中反复执行 DOM 操作，直至任务完成。

其突出优势之一，是基于文本的 DOM 操作策略。Page Agent 不会通过屏幕截图依赖多模态 LLM——那类方案不仅成本高，响应也慢。相反，它会从实时 DOM 树中提取出结构清晰且经过精简的交互元素文本表示。LLM 直接根据这些文本进行推理，判断需要和哪个元素交互、执行何种动作。这样既快速又轻量，并且几乎可以对接所有兼容 OpenAI 接口的模型。

分层架构与自主执行循环

Page Agent 采用分层架构，每一层的职责都被封装在独立的包中。各层之间通过异步、面向接口的方式进行通信，从而保证了高度的解耦和可测试性。

Agent 执行循环是整个系统的核心，它严格遵循 ReAct（推理 + 行动）模式，并融入了独有的“行动前反思”机制。在每一轮循环中，代理都会先观察页面状态，回顾之前的子目标与进度，规划接下来的动作，然后执行。这一循环不断重复，直至任务被标记为完成或者达到预设的最大步数。

Page Agent 是一个纯客户端 ReAct 循环，完全在浏览器内运行——无需 Python、无头浏览器或任何后端改造。它把页面的 DOM 读取为结构化文本，通过 LLM 推理出下一步，并利用浏览器原生的元素 API 去执行操作。

开箱即用的智能工具集

Page Agent 内置了一套供 LLM 在任务执行过程中调用的工具。每一个工具都通过 Zod schema 定义并进行输入校验，实际的 DOM 操作则委托给 PageController 来完成。

Hy3 的试用期结束了，也来晒一下这段时间的消耗成绩。

输入 Token 一共用掉了 6.225 亿，输出 Token 约为 530 万。

这么大的输入量，主要和我大量整理知识库的工作有关。我也用 Hy3 尝试开发了一款软件，运行了大约一小时左右，开发效果还算可以。页面能正常打开，交互也形成了闭环。

不过实际使用中，生成的软件并没有满足客户需求，于是决定重构。但重构的进展非常不顺利，整整折腾了一天，到最后什么也没搭出来，代码还被改崩了。

不得不吐槽的一点是，Hy3 在 OpenRouter 上的速度明显受限，用起来非常慢。但考虑到是免费额度，也只能忍一忍了。它的上下文窗口似乎只有 128K，跑两个任务就会提示空间不足。我是通过 Claude Code 接入的，每次上下文用满以后，压缩过程都极其耗时，甚至好几次直接自动中断。现在也分不清到底是 Claude Code 还是 Hy3 的原因。

所以后来我干脆直接执行 /clear 指令，反正免费资源，大不了再让模型重新读取一遍所有项目文件，放开来用。

再分享一件让我心情舒畅的小事。

根据当前 Hy3 的收费规则，我让豆包帮忙换算了自己消耗的 Token 对应的费用：

• 输入费用：622.5 × 0.066 = $41.085
• 输出费用：5.3 × 0.26 = $1.378
• 总费用：$41.085 + $1.378 = $42.463

换算成人民币大约是 306 元。如果按老一辈“省下的就是挣下的”这种说法，那这个月已经“挣”了 306 元，想起来也挺有意思。当然，跟大神们比起来不过是九牛一毛，还需要继续努力，把需要整理的工作和其他耗 Token 的任务积攒起来，等下一波优质模型免费窗口期再抓住机会。

Hy3 停供之后，后遗症立刻显现出来。好几个依托大模型搭建的网站都面临宕机，尤其是那个用来演示的知识库问答站点，以前别人抱怨响应慢，现在索性完全不可用了。这样看来，Hy3 的免费额度确实为各个项目的推进帮了很大的忙。能用的时候没觉得多珍贵，还总吐槽它，一旦没有了，又开始怀念。

总的来说，Hy3 作为一个下位替代或兜底模型完全没有问题。就像团队里专做脏活累活的成员，让它去承担关键重任可能难以胜任，那种任务需要 Claude 或 ChatGPT 这样的精英级模型，但如果只是整理知识库，调用 Opus 就显得太过奢侈，而这正是 Hy3 这类模型的价值所在。