项目介绍： 项目地址： 上一期：v0.2.0 基于 Chrome 内置 AI 的职位分析助手 一句话： Chrome 扩展，用 AI 分析 LinkedIn 职位 —— 五个维度评估，支持 API 与 Gemini Nano 本地双后端。v0.3.0 引入 AI Agent 架构，评估器可联网搜索公司信息，结果实时流式返回，支持断点续跑。 🚀 v0.3.0 新特性 1. AI Agent：评估器可调用搜索和网页工具 问题：之前的评估器完全依赖 LLM 的预训练知识来评估公司风险、薪资水平等，对于新创公司、未公开信息只能猜测。 解决：为风险、薪资、成长、偏好四个评估器配备 websearch（DuckDuckGo）和 readpage 工具。评估过程中，AI 会主动搜索公司裁员新闻、行业趋势、薪资数据等，并阅读实际网页获取真实信息。 salary 评估器 → 搜索 "senior frontend engineer salary Austin 2026" risk 评估器 → 搜索 "company X layoffs 2026" → 阅读相关文章 去重机制：同一个 run 内对同一 URL 只取一次结果，多个评估器共享缓存。 2. 分阶段流水线 + 断点续跑 旧的并行执行（Promise.all）改为 4 阶段流水线： | 阶段 | 评估器 | 依赖 | |||| | Stage 1 | 偏好评估 | 无 | | Stage 2 | 技能匹配 + 薪资评估 | 无 | | Stage 3 | 风险评估 + 成长评估 | 依赖 Stage 2 结果 | | Stage 4 | 总结评估 | 依赖全部完成 | 下游评估器可直接复用上游的研究成果。若中途失败（如网络超时），可点击「继续」从失败阶段重试，无需从头开始。 3. 实时流式结果 以前需要等全部 6 个评估器跑完才能看到报告。现在每个评估器做完立即显示结果，还能实时看到 AI 正在「搜索中...」「阅读中...」的进度状态。 4. Offscreen Document + 结构化输出 将 HTML 转 Markdown 的 DOM 解析移到 offscreen document，解决 MV3 Service Worker 无 DOM 访问的问题 云端模型启用严格 JSON Schema 约束，输出更稳定 推理模型（如 MiniMax）的 think 标签自动裁剪，jsonrepair 兜底解析 HTTP 504 自动重试 📦 历史功能回顾 五种 AI 评估 | 维度 | 说明 | ||| | 薪资评估 | 基于职位、地点、经验估算薪资范围，与期望对比 | | 技能匹配 | 对比职位要求与你的技能栈，标注匹配/缺失/额外技能 | | 偏好评估 | 远程/混合、行业、公司规模等偏好匹配度 | | 风险评估 | 裁员历史、招聘活跃度、职位稳定性 | | 成长评估 | 技能提升空间、职业路径、学习资源 | 双后端：Cloud + Chrome AI | 方案 | API Key | 网络依赖 | Token 费用 | 数据隐私 | |||||| | Cloud (OpenAI) | 需要 | 需要 | 按量付费 | 数据上云 | | Chrome AI | 不需要 | 不需要 | 免费 | 数据不出设备 | Chrome AI 基于 Gemini Nano，开启后无需 API Key、零网络请求、数据完全本地处理，适合隐私敏感场景。 智能对话追问 对报告内容不满意？可直接追问，AI 会结合报告上下文进一步分析。Chrome AI 后端利用有状态 API 实现持久化会话，大幅减少延迟。 🧗 使用方式 1. 从 Chrome Web Store 安装（或 git clone + bun install && bun dev） 2. 打开任意 LinkedIn 职位页面 3. 点击侧边栏 Job Bro 图标 4. 点击「分析」，等待评估完成 5. 查看报告，或进一步追问 Chrome AI 前提：Chrome 127+，启用 chrome://flags/promptapiforgemininano，下载模型（约 4GB，浏览器自动管理） 源码： 🙏 致谢 感谢社区反馈和贡献 欢迎 Star、提 Issue、贡献新功能。让求职分析像打开一个网页一样简单。 🔗 [GitHub](https://github.com/aeroxy/job-bro) · [投稿页](https://github.com/ruanyf/weekly/issues/10236) ### 【工具自荐】Pavemath - 关于道路数字计算的工具 👤 rn-consider > 网址 介绍 提供点开即用无需登录的各类道路数字计算相关的计算器,比如沥青计算器一类。 🔗 [官网](https://pavemath.com/) · [投稿页](https://github.com/ruanyf/weekly/issues/10237) ### 【好文推荐】我刚经历了3小时内增加500+用户的恐怖增长 👤 yanghan-pp > 【我刚经历了3小时内增加500+用户的恐怖增长】 过去3小时之内，我的产品新增了500+的注册用户 考虑到之前我们的产品目前一个多月也才实现了2000+的注册用户，新增的500+的注册用户对我们而言是一次不小的爆发，相当于之前大半个月的工作量 我们的产品为什么突然实现了用户数量上的爆发？很多人以为这会是一个励志的故事：长期坚持不断打磨产品、跟进用户需求改善体验、所做的一切在市场上有了反馈、从此产品步入正轨。 但遗憾的是，都不是。 真实的情况是：我们买量了。但在三个小时后，我们决定结束这场闹剧。 1.预料之外的爆发 我们在做的是一款叫“连连AI”的小程序，产品核心的功能在于让AI根据你的需求帮你找到合适的人并自动进行沟通。这样的话，当你有找人的需求时，无论是找程序员、设计师接单，还是找律师等，你都可以节省繁重的寻找和沟通过程。 用户的爆发，始于一次偶然的提议。 一个团队成员说，我们是不是可以在网上找一些人帮我们拉拉用户，我们按照注册用户数来付费。 于是，我们在一个微信群里发了一条广告。一个小时内，新增的注册用户数就突破了100+，并在随后的一个小时内又突破了300+ 直接给钱的激励效果远超我们的想象，我们仅为一个注册用户支付2块钱左右，但大家仍然有充足的热情帮我们去做这些东西。 即使我们完全有能力支付相应的费用，我们还是仅在三个小时内就决定停止这一切，停止所有“虚假的繁荣”。 2.激烈的心理斗争 关于是否停止这一切，我们经历了激烈的心理斗争。 用户增长的太快了，几个小时内就超过了我们几周所做的工作，而付出的东西又都在我们的预算范围内，这一切都很难让人拒绝。这会不会是一次产品火起来的契机？放任大家增长下去，会不会有意外的收获？ 所有的东西在我脑海中萦绕。 但我们还是决定停止这一切，是因为两个数据： 1.绝大多数的注册用户并没有完成一次有效的行为。一个AI产品，用户只有完成对功能的体验和使用之后，用户才会有留存的可能。对“连连AI”这个产品而言，如果用户有需求并进行了发布，这时候能够体验到用AI帮你找人并自动沟通的过程，这个人才会具有后续留存的可能。 但我们看到，绝大多数的用户只是注册了，并没有完成对功能的体验和使用，甚至连和Ai对话都没有，这意味着这部分用户以后是不可能再继续使用我们的产品的。 当时我们为了修正这种情况，更改了规则，需要用户也完成一次找人功能的使用才算作有效用户，但很快我们又失望了。 2.绝大多数用户只是发了一些无意义的内容。这是一个极为典型的有政策，也有对策的场景，在我们要求用户需要与AI对话，向AI下达任务让AI去帮你找人才算作是有效用户后，我们看到的结果是大部分用户只是发布了一些无意义的内容。这显然不是我们希望的结果，我们很快意识到引来的这部分用户的人群画像是过于宽泛的，他们不知道能用产品来做什么。我们并非挑选用户，但可能过于宽泛的用户群体对我们也并非什么好的事情。 于是，我们做出了停止的决定。 3.对初期产品最重要的是什么 我们之前做的错误的一点，就是花了太多的时间和精力在用户增长上。 因为“连连AI”的核心功能是根据你的需求帮你由AI自动进行匹配并沟通，我们需要不断扩大我们的用户池，否则便可能找不到相应的人。 做用户增长没有错，但不应该将用户的增长情况作为初期最核心的指标。用户的增长情况这种规模性数据更多是金钱等资源投放之后的结果，但你还需要更多的其他数据来验证产品的PMF，例如留存、成功率和用户满意度等等。 如果你初期花费了过多的精力在一个个地拉用户，而不是注重于收集用户的使用情况与反馈，那你可能将精力放错了地方。 你只要能够在一个地方完成闭环即可，在一个场景中满足用户的需求。比如，我们能够专注把创业者找人、或程序员找外包这类场景做好的话，那会比漫无目的地拉用户来的快得多。程序员找外包这类场景中，最麻烦的就是去找订单和沟通需求的过程，如果能够有一个Agent 24小时帮助你在平台上搜集信息并自动沟通的话，会是一件很有价值的事情。 但我们目前这个最基础的场景都没有做好，而是花费了过多的精力在用户增长上。完成一次功能的闭环，比用钱烧出来的用户增长数据的“虚假繁荣”重要的多。 但用户的爆发也是有价值的。它让团队清醒过来，既然用户增长可以用钱解决，那自然应该花更多时间在其他方面，争取在其他方面构建起一定的壁垒。但我们之前不懂，对一个饥渴于流量的创业者而言，只有体会过一定的富足之后才会静下心来思考。就如同一个快要饿死的人，他只会一味地进食、进食、再进食。 这便是我在本次用户增长后的思考，感谢你的阅读。 🔗 [GitHub](https://github.com/ruanyf/weekly/issues/10238) ### 【开源自荐】MuJoCo Skills：面向 Robotics 环境搭建和操控技能库 👤 coolbeevip > 我是这个仓库的作者： 做这个项目的原因很简单：我自己还是机器人仿真的初学者，经常会用 AI 帮我创建 MuJoCo 仿真环境。 这个过程一开始很有帮助。比如我可以让 AI 创建一个 Franka 机械臂抓取场景、UR5e 分拣场景、Go1 越障场景，或者 H1 人形机器人的行走布局。AI 很快能给出 MJCF 文件，也能帮我打开 viewer 检查。 但问题也很明显：生成出来的场景经常“看起来像那么回事”，实际却不一定符合物理常识。 我遇到过的问题包括： 物体悬空 机器人初始姿态不合理 机械臂没有夹爪，却被要求做抓取 末端执行器穿过桌面或传送带 人形机器人一开始就倒下 场景能加载，但不是一个可用的仿真环境 所以我开始把这些经验沉淀成一个 MuJoCo Skill，让 AI Agent 在创建场景时不只是“写 XML”，而是按一个更可靠的流程工作。 这个 Skill 目前主要帮助 AI 做这些事： 构建 MJCF 场景 做基础物理合理性检查 启动 MuJoCo viewer 检查 actuator 做最小控制实验 在不确定时询问用户，而不是猜测需求 对常见场景进行更严格的验证 README 中的示例和场景检查是在 Codex GPT5.5 下验证的。 我并不想把它包装成一个“自动生成完美仿真环境”的工具。它更像是一个给初学者和 AI Agent 使用的工作流约束：让 AI 在创建 MuJoCo 场景时少犯明显错误，也让使用者能更快得到一个可以继续学习和修改的起点。 如果你也在用 AI 辅助机器人仿真，或者你对 MuJoCo、MJCF、机器人控制有经验，欢迎帮我看看这个仓库，也欢迎提建议： 🔗 [GitHub](https://github.com/coolbeevip/mujoco-skills) · [投稿页](https://github.com/ruanyf/weekly/issues/10239) ### 【开源自荐】PaperQuay：给桌面端文献阅读补上 AI 翻译、论文概览、内联笔记和 Agent 工作流 👤 WangQrkkk > PaperQuay是面向桌面端的覆盖 PDF 阅读、全文翻译、论文概览、富文本笔记和 Agent 工作流 AI 辅助文献管理阅读工具。 解决的问题： 常规文献管理工具如 Zotero 等，主要提供基础的文献管理和 PDF 阅读能力；许多 AI 插件与 Zotero 的集成度不够，阅读、翻译、总结、笔记和文献整理往往分散在多个工具里，集成度不够，同时相互之间无法联动。 PaperQuay 希望把这些操作放回同一个桌面工作区：导入 PDF 后，可以管理元数据、分类、标签和附件；阅读时支持 PDF 批注、MinerU 结构块视图、全文翻译、块级译文缓存和划词翻译；速读时可以生成论文概览，包含背景、研究问题、方法、实验设置、主要发现、结论和局限等字段。 笔记方面，PaperQuay 内置富文本 Notes 工作区，支持 [[笔记]] 双向链接、标签、@paper 文献引用、反向链接、本地自动保存和全文搜索，让论文笔记不再脱离文献上下文。 AI 工作流方面，PaperQuay 提供面向文献管理的 Agent 工作区，不只是普通聊天框。Agent 可以辅助批量重命名、元数据补全、智能标签、标签清洗、自动分类和论文总结，并展示工具调用过程和执行结果，方便用户确认后再执行。 数据与隐私方面，PaperQuay 采用本地优先设计，文献库、笔记、批注、导入记录和 RAG 索引保存在本地 SQLite 数据库中，PDF 保存到用户配置的文献存储文件夹。Zotero 兼容是可选能力，可以从 zotero.sqlite 导入分类、标签和可用 PDF 附件，但不强依赖 Zotero。