前端初见
type: channel
link: https://blog.fishliu.com/
description: AI 工具、自动化工作流与个人知识库实践笔记，兼记录前端开发与生活观察。
items: AI 每天复盘，人该守哪一关：我用三天匿名数据拆了一道 Agent 审批门
items: MCP 服务器变更信任门禁：从配置指纹到人工复核
items: 2026 AI 编程工具横评：Cursor / Trae / Windsurf 实测方法与选型参考
items: 本地 AI 自动化助手实战：n8n + Ollama + Qdrant 架构、配置与踩坑全记录
items: MCP协议技术解读与个人自动化实践：如何让AI工具真正协同工作
items: AI原生浏览器2026实测：Dia/Atlas/Comet谁在替你上网？
items: AI代码审查工具2026实测：CodeRabbit、PR-Agent、Copilot 价格/误报率/审查深度全对比
items: 小红书算法2026底层转向：为什么收藏率比点赞更值钱
items: Karpathy LLM Wiki：用 AI 建一个会自动生长的第二大脑
items: Readwise → Obsidian → 本地 AI 问答：完整配置指南与可复制模板

AI 每天复盘，人该守哪一关：我用三天匿名数据拆了一道 Agent 审批门
type: item
date: 2026-07-16T14:16:34+08:00
description: 状态：独立博客归档稿。SEO 摘要：基于 Claude for Teachers 的定时复盘示例，用三天自造匿名数据回放“输入、校验、诊断、建议、差异、人工审批”链路，说明定时 Agent 如何处理私有文件、证据、回滚、隐私与失败恢复。如果每天收工前，把当天的文件丢进一个文件夹，AI 就能在固定时间读完、找出问题，再把明天该做什么列好，你会不会直接照着执行？这件事听起来很省力。周报不用从头翻记录，内容复盘不用再对着后台发呆，知识库里积压的材料也有人每天整理。可一旦 AI 的建议会改变第二天的工作，麻烦就来了。它读错了怎么办？它把同时发生的变化当成因果怎么办？它发现某个人连续出错，顺手给对方贴了一个长期标签，又怎么办？我最近看到一个很适合拆解这类问题的官方示例。Anthropic 在 2026 年 7 月 14 日发布 Claude for Teachers，提到可以安排重复任务，例如每个上课日 16:00 复核当天的 exit tickets，判断学生掌握情况，再调整次日计划。[1]我没有把这句话直接当成“AI 可以自动改教案”。官方页面展示的是产品用例，不是我已经跑过的结果；“生成调整建议”和“让调整直接生效”，中间也差着一道很重要的门。所以这次我没有上传真实学生资料，也没有假装自己拥有符合条件的账户。我做了一个更克制的三天离线实验：全部使用自造、匿名的模拟数据，只研究一件事。文件输入、诊断、次日建议、人工确认，这四步到底该怎么分工？先把官方说了什么讲清楚Claude for Teachers 当前不是面向所有人的通用免费功能。官方限定的是经验证、在美国 K–12 学校工作的个人教育者。帮助中心还写明，申请者需要使用学校邮箱完成验证，并将 Claude 用于教育目的；它不是学生方案。符合条件者在 2027 年 6 月 30 日前注册，可获得完整一年的免费访问，但仍有额外使用量限制，价格和方案也可能变化。[1][2][3]官方确认该方案包含 Learning Commons connector、教学 skills、Claude Code 和 Cowork。产品页把 scheduled tasks 明确写成 Cowork 的能力；但公告没有把每一个课堂数据分析示例分别归给 Claude Code 或 Cowork，我也没有替官方做这种拆分。[1][2][3]还有一条更容易被说过头。官方称教师方案中的输入和输出不用于模型训练，并为 K–12 场景提供专门条款和数据处理附录。它对 FERPA 的原话是 DPA “written to comply with FERPA”，帮助中心使用的是 “FERPA-aligned protections”。这不能改写成“通过 FERPA 认证”，也不代表学校和教育者从此不用管授权、数据最小化、连接器权限和保存期限。[1][3][4][5]这几条限制看起来有点扫兴，却决定了实验该怎么做。既然我没有登录符合资格的真实账户，就不测试真实调度、私有文件连接和外部写回。既然涉及未成年人数据，就不用“脱敏一下应该没事”的真实材料，而是从零造一份无法映射到真人的数据。我怎么搭这次三天模拟我虚构了一个 12 人的八年级数学小班，用 S-01 到 S-12 作为随机代号。文件里只保留三类低维信息：一道出口题是独立正确、提示后正确还是未掌握；作业是完成、部分完成还是未提交；以及经过压缩的课堂现象。姓名、邮箱、学号、学校、地区、家庭情况、健康和特殊教育信息，全部没有进入数据。就连“为什么没交作业”也不采集，因为这类空白最容易诱使模型编一个听起来合理的原因。每天运行前，我先写好一份“原次日计划”，然后锁住它。AI 不能看完建议后再替我美化原计划。整个链路是这样的：匿名文件 → 隐私、字段和算术校验 → 只依据文件做诊断 → 生成最多 3 条次日建议 → 与原计划逐项比较 → 交给模拟教师批准、修改或拒绝每条建议都必须回答四个问题：证据来自哪里，要占用多少时间，第二天观察什么，什么情况下撤回。我还加了一个很笨、但很有用的默认值：没有完整审批 = DO_NOT_APPLY也就是说，AI 写完不算完成。人没确认，就继续用原计划。第一天，AI 的建议没错，但对象需要改第一天的模拟主题是一次函数的斜率和变化率。12 个代号中，8 个独立答对出口题；11 份作业有提交，其中 6 份达到当天核心目标。文件里还明确记录了两类重复错误：3 份把比值方向写反，2 份算对了却解释错了负斜率的含义。原计划很常见：第二天继续讲图像与截距，先用 5 分钟口头复习公式，再布置 6 道图像题。AI 给出的草案，是把 5 分钟口头复习改成 12 分钟的短流程：先独立做两题，再看匿名错例，最后让同伴解释。它还建议给两个出现坐标顺序错误的代号一张“标 x/…

MCP 服务器变更信任门禁：从配置指纹到人工复核
type: item
date: 2026-07-15T14:04:20+08:00
description: 我第一次意识到 MCP 授权有问题，不是因为某个工具突然报错，而是因为它什么都没报。服务器名字没变，界面还在原来的位置，调用也能继续。可一旦去看配置，command、参数和工具说明已经不是上次同意的内容。这类变化不一定恶意，却会让旧授权失去上下文。你当时同意的是一个只读搜索工具，后来它可能多出写文件、发网络请求或执行命令的能力。如果客户端只记住服务器名，用户很容易把“认识它”误当成“仍然信任现在的它”。这篇文章不做 MCP 入门，也不复述安全攻击清单。只解决一个问题：服务器的配置和能力变了，怎样让自动化先停一下，再由人决定是否继续。1. 官方机制到底检查什么GitHub 在 2026 年 7 月 14 日发布的 Visual Studio June Update 中提到，Visual Studio 会在启动时把 MCP 服务器的 configuration fingerprint 和 asset fingerprint 与可信基线比较。Microsoft Learn 对流程给出了更细的两阶段说明。在 Visual Studio 2026 18.7 及以上版本中，这项功能默认开启。服务器进程启动前，客户端先比较当前配置和上一次可信配置。公开文档列出的配置示例包括 transport type、URL、command 和 arguments。发现差异时，信任对话框会出现在进程启动之前。服务器启动并加载资产后，客户端再比较 tools、prompts、resources、resource templates、instructions 等能力与资产的指纹。发现变化后，界面要求用户重新选择 Trust 或 Do not trust。Trust 会接受本次变化，并更新后续比较使用的可信基线。Do not trust 会停止本次启动，下一次激活还会再次验证。这个机制有几个容易被标题省略的边界。首次激活不会先弹一次，而是隐式建立配置和资产基线。内置服务器、组织策略为 RegistryOnly、用户选择 Always Trust，或者主动关闭设置时，也会跳过提示。官方没有公开具体指纹算法、基线保存位置、跨机器同步方式或防篡改机制。它也不是代码签名、发布者认证、恶意软件扫描或提示词注入检测。变化只说明“和上次不同”，不能替你判断这次更新是否值得信任。公开资料能确认的是启动和重新激活阶段的比较。Visual Studio 另会处理运行时 notifications/tools/list_changed，重置工具权限并重新拉取工具列表，但文档没有说这个事件一定触发同一套可信基线弹窗。2. 为什么我要先做一个本地假服务当前执行环境是 Linux，没有 Visual Studio、Windows、devenv 或 PowerShell。因此我没有制造一段看似完整的“弹窗亲测”。我先做了一个不会碰生产数据的 MCP fixture，为后续目标机实验准备稳定对照。它只走 stdio，不监听端口，不发网络请求，不读取 .env。唯一工具 echo_local 只回显输入，不读写用户文件，也不执行 shell。除此之外，它只暴露一条 prompt、一条静态 resource、一条 resource template 和 instructions。实验设计包含 6 个场景： baseline：初始配置与资产 control-no-change：原样重新运行 command-change：把启动命令换成指向同一 Node 二进制的别名 arguments-change：只修改一个实验标签参数 tool-description-change：只修改工具描述 resource-change：只修改 resource 描述 工具和 resource 变体都用机器 diff 确认，只改目标字段。这样到了 Windows + Visual Studio 目标机，一旦出现不同结果，才有可能判断差异来自哪一层。本地协议冒烟 6/6 通过。标准 MCP TypeScript SDK 可以初始化 fixture，并列出 1 个 tool、1 个 prompt、1 个 resource 和 1 个 resource template；工具调用与资源读取均成功。这只能证明夹具能正常跑，不能证明 Visual Studio 对每个字段都会弹出信任对话框。3. 单变量实验该怎么跑在 Windows + Visual Studio 2026 18.7+ 目标机上，我会把每个场景拆成独立 server name 和独立 solution。Trust 与 Do not trust 分支也分开，防止某一次接受更新了基线，污染后面的试次。第一步先激活 baseline。根据官方文档，首次激活应当不弹信…

2026 AI 编程工具横评：Cursor / Trae / Windsurf 实测方法与选型参考
type: item
date: 2026-07-08T17:33:02+08:00
description: AI 编程工具选择不是排行榜，而是场景匹配技术归档 · 可复现测试方案 · 2026-07-06本文是「财AI智研所」AI 编程工具系列的技術归档版。提供完整的测试方法、评分维度、复现步骤和数据模板，供读者自行验证。 〇、声明与局限性 重要：本文不包含最终排名。 原因如下： 1. Cursor / Trae / Windsurf 均为桌面 GUI 应用，当前 headless Linux 服务器环境无法进行真实交互测试。所有功能描述基于官方文档和公开资料，非实测数据。 2. Claude Code 不纳入本轮。作者未订阅 Claude Pro/Max 套餐，不编造未体验的内容。 3. 价格数据来自各工具官网（采集日期 2026-07-06），可能随时调整。 4. 本文提供的是可复现的测试框架，读者可在自己的 Mac/Windows 环境上执行相同测试并填写评分。 如果你看到网上有文章直接给出"Cursor 9.2 分 > Windsurf 8.7 分 > Trae 7.5 分"之类的精确排名，但没说测试环境、测试项目、测试 prompt，那大概率是编的。 一、测试项目：Hermes Studio 1.1 项目概况 属性说明 名称Hermes Studio（hermes-web-ui） 仓库github.com/EKKOLearnAI/hermes-studio 技术栈前端 Vue 3 + TypeScript + Vite；后端 Koa + TypeScript + Socket.IO 结构monorepo：packages/client、packages/server、packages/desktop 复杂度中等——前后端联调、WebSocket 实时通信、多模型 API 代理、i18n、Docker 部署 1.2 为什么选这个项目 全栈覆盖：前端组件、状态管理、路由、后端 API、数据库、WebSocket，能考察 AI 工具的跨层理解能力 真实复杂度：不是 todoMVC，单个任务 10-30 分钟可完成 可复现：开源仓库，任何人可 git clone 后从同一 commit 开始测试 贴近实际：AI 编程工具的目标用户正是做这类全栈项目的开发者 1.3 环境搭建 # 1. 克隆仓库 git clone https://github.com/EKKOLearnAI/hermes-studio.git cd hermes-studio # 2. 切到约定的测试 commit（待实测时确定具体 hash） git checkout <test-commit-hash> # 3. 安装依赖 npm ci --ignore-scripts # 4. 配置环境变量 cp .env.example .env # 编辑 .env，填入测试用 API Key（建议使用低成本模型） # 5. 启动开发服务器 npm run dev 确认 http://localhost:5173 可访问且后端 API 正常响应后，开始测试。 二、测试任务清单（5 个任务） 同一项目、同一 Prompt、同一证据链，才能做可复现实测 所有任务在每款工具上使用完全相同的 prompt 执行。 T1：前端 UI 功能开发 目标：为聊天界面添加消息搜索功能。 Prompt： 在 packages/client 中实现一个消息搜索功能： 1. 在聊天页面顶部添加一个搜索框，支持按关键词搜索历史消息 2. 搜索结果高亮显示匹配文本 3. 点击搜索结果跳转到对应消息位置 4. 支持按消息角色（user/assistant/system）筛选 5. 搜索结果超过 50 条时分页显示 考察维度：组件设计、状态管理、DOM 操作、搜索算法选择、UI/UX 细节。 预计耗时：15-25 分钟。 T2：后端 API 开发 目标：实现 Token 用量统计 API。 Prompt： 在 packages/server 中新增 Token 用量统计模块： 1. 新增 /api/usage/tokens 接口，返回当前用户各模型的 token 消耗统计 2. 支持按时间范围查询（today/week/month/custom） 3. 支持按模型分组统计 4. 数据从现有的消息记录中聚合，不新建表 5. 添加请求频率限制：每分钟最多 30 次 考察维度：SQL 聚合能力、路由设计、中间件使用、错误处理。 预计耗时：20-30 分钟。 T3：跨层 Bug 修复 目标：修复一个预设的 WebSocket 断连 Bug。 预设方式：在 packages/server/src/ws/handler.ts 中修改心跳逻辑，使服务端在客户端发送 ping 后不回复 pong，导致客户端超时断连。 …

本地 AI 自动化助手实战：n8n + Ollama + Qdrant 架构、配置与踩坑全记录
type: item
date: 2026-07-06T23:27:20+08:00
description: 本地 AI 自动化助手：n8n 编排、Ollama 推理、Qdrant 检索的离线架构。 本文是《我在家里的 NAS 上，搭了一个不联网的 AI 助手》的技术扩展版。包含完整的 Docker Compose 配置、n8n 工作流 JSON 解读、API 调用示例、初始化脚本，以及所有踩坑点的详细解决方案。适合想完整复刻或深入理解每个组件的读者。 系统架构 ┌─────────────────────────────────────────────────────┐ │ 你的电脑 / NAS │ │ │ │ ┌──────────┐ ┌──────────────┐ ┌────────────┐ │ │ │ n8n │───▶│ Ollama │ │ Qdrant │ │ │ │ :5678 │ │ :11434 │ │ :6333 │ │ │ │ │ │ │ │ │ │ │ │ 工作流 │ │ qwen2.5:7b │ │ 向量数据库 │ │ │ │ 编排 │ │ (LLM推理) │ │ (语义检索) │ │ │ │ │ │ │ │ │ │ │ │ │───▶│nomic-embed │───▶│ documents │ │ │ │ │ │ (文本向量化) │ │ collection │ │ │ └──────────┘ └──────────────┘ └────────────┘ │ │ │ ▲ │ │ └────────────────────────────────────┘ │ │ 检索 + 生成 │ └─────────────────────────────────────────────────────┘ 组件 角色 端口 资源需求 n8n 工作流引擎，Webhook 入口，编排所有调用 5678 CPU 1-2核，RAM 512MB-1GB Ollama 本地 LLM 推理 + Embedding 11434 RAM 8GB+（7B模型），CPU推理或GPU加速 Qdrant 向量数据库，语义检索 6333 (HTTP) / 6334 (gRPC) RAM 512MB-2GB，磁盘按数据量 Docker Compose 完整配置 version: "3.8" services: ollama: image: ollama/ollama:latest container_name: ollama ports: - "11434:11434" volumes: - ollama_data:/root/.ollama networks: - ai-local restart: unless-stopped # CPU-only 模式，无需 GPU 配置 # 如果有 NVIDIA GPU，取消下方注释： # deploy: # resources: # reservations: # devices: # - driver: nvidia # count: all # capabilities: [gpu] qdrant: image: qdrant/qdrant:latest container_name: qdrant ports: - "6333:6333" # HTTP API - "6334:6334" # gRPC volumes: - qdrant_data:/qdrant/storage networks: - ai-local restart: unless-stopped n8n: image: n8nio/n8n:latest container_name: n8n ports: - "5678:5678" volumes: - n8n_data:/home/node/.n8n networks: - ai-local restart: unless-stopped environment: - N8N_HOST=localhost - N8N_PORT=5678 - N8N_PROTOCOL=http - WEBHOOK_URL=http://localhost:5678/ - GENERIC_TIMEZONE=Asia/Shanghai # 容器内通过服务名访问 Ollama 和 Qdrant - OLLAMA_BASE_URL=http://ollama:11434 - QDRANT_BASE_URL=http://qdrant:6333 volumes: ollama_data: qdrant_data: n8n_data: networks: ai-local: driver: bridge 关键配置说明： 网络：三个服务都在 ai-local bridge 网络中，容器间可以通过服…

MCP协议技术解读与个人自动化实践：如何让AI工具真正协同工作
type: item
date: 2026-07-02T10:33:30+08:00
description: MCP协议技术解读与个人自动化实践2024年底，Anthropic发布了一个开源协议。一年后，它被捐赠给Linux Foundation，获得了所有主流AI平台的支持，生态规模突破一万个公开服务器。这个协议叫 MCP（Model Context Protocol，模型上下文协议）。本文将从技术角度解读MCP是什么、为什么它能成为AI工具互联的事实标准，并分享我如何用5个支持MCP的工具搭建个人自动化工作流。 一、MCP解决了什么问题？ 在MCP出现之前，每个AI工具想连接外部服务（比如读Notion、查日历），都需要单独写一套接口。这不仅重复劳动，还造成了一个个"AI孤岛"——每个工具只能在自己的世界里工作。 MCP的解决方案很直接：定义一种通用的协议，让所有AI工具和服务都用同一种方式通信。 Anthropic官方文档用了一个精准的类比：MCP就像AI工具世界的USB-C接口。 就像USB-C让你不用为每个设备带不同的数据线，MCP让AI工具不用为每个服务写不同的接口。 技术架构 MCP基于 JSON-RPC 协议，采用 Client-Server 架构： MCP Client（客户端）：AI应用，如Claude Desktop、Cursor、ChatGPT、VS Code等 MCP Server（服务端）：连接具体服务的适配器，如Notion MCP Server、Google Calendar MCP Server等 MCP Server提供三种核心能力： Resources（资源）：让AI读取外部数据（如Notion页面、日历事件） Tools（工具）：让AI执行操作（如创建文档、发送邀请） Prompts（提示模板）：预定义的交互模板 传输方式支持两种：stdio（本地进程通信）和 Streamable HTTP（远程通信，SSE方式已于2025年11月弃用）。 来源：MCP官方规范、MCP介绍页 二、为什么MCP在2026年成为事实标准？ 三个关键节点决定了MCP的地位： 1. 时间线：从开源到行业共治 时间 事件 2024年11月 Anthropic发布MCP开源项目 2025年全年 主要AI平台陆续采用 2025年12月 Anthropic将MCP捐赠给Linux Foundation旗下的AAIF（Agentic AI Foundation） 捐赠不是Anthropic一家的事——AAIF由Anthropic、Block、OpenAI共同创立，支持者包括Google、Microsoft、AWS、Cloudflare、Bloomberg。 这意味着MCP已经不是任何一家公司的私有项目，而是行业共治的开放标准。 来源：Anthropic捐赠公告、Linux Foundation新闻稿 2. 平台覆盖：所有主流AI工具都已支持 截至2026年中，以下平台均已支持MCP： 平台 支持方式 备注 Claude Desktop 原生支持 最早支持MCP的客户端之一 Claude Code 原生支持 通过claude mcp add命令配置 Cursor 原生支持 AI原生IDE，MCP配置内置 VS Code (Copilot) 2025年7月GA 正式可用，不再需要preview ChatGPT Desktop 2025年3月采用 OpenAI官方支持 Gemini 已支持 Google官方采用 Microsoft Copilot 已支持 微软官方采用 Windsurf 已支持 AI编码工具 Zapier MCP Server + Chrome扩展 zapier.com/mcp n8n v1.88+ MCP Client/Server节点 开源自动化平台 Chrome 第三方扩展 浏览器自动化 Make.com MCP Server功能 自动化平台 Perplexity AI 已支持 Asana MCP客户端列表确认 来源：VS Code MCP GA公告、Zapier MCP 3. 生态规模 公开MCP Server数量：10,000+（Anthropic 2025年12月公告） SDK月下载量：97M+（Python + TypeScript） Claude Connectors（基于MCP）：75+ 企业级部署支持：AWS、Google Cloud、Azure、Cloudflare 三、MCP生态概览：去哪里找MCP Server？ 渠道 类型 地址 官方Registry 官方社区驱动 https://github.com/modelcontextprotocol/registry mcp.so 第三方目录 https://mcp.so mcpservers.org 第三方目录（Awesome MCP Serve…

AI原生浏览器2026实测：Dia/Atlas/Comet谁在替你上网？
type: item
date: 2026-07-02T06:20:35+08:00
description: 从左到右：Dia Browser、ChatGPT Atlas、Perplexity Comet —— 三种不一样的「替你上网」我花了两个礼拜，把三款AI原生浏览器装进Mac，每天切着用。起因很简单：我日常70%的时间泡在浏览器里——看文档、查API、刷GitHub Issues、写公众号稿子。Arc用了一年半，肌肉记忆早焊死在快捷键上。但2026年的浏览器战场，已经是Dia、Atlas、Comet三款从不同方向杀出来，都在说同一句话：「别自己找了，我替你上网。」Dia Browser：最像浏览器的AI浏览器打开Dia第一感觉——还是Arc那套味道。左侧边栏、Space分组、垂直标签页。但Dia真正动手脚的地方在地址栏：按Cmd+K出来的是一个AI聊天面板。我试了个真实场景：周会上需要快速了解Svelte 5最新RFC的争议点。按Cmd+K，输入问题。Dia先读取我正开着的RFC页面，横向拉了三个相关链接，合并成一段带引用的摘要推给我。不到十五秒，我没碰鼠标。它还有个叫 Skills 的功能——预构建的AI提示模板，一键完成"比价"、"翻译"、"摘要"。Memory功能让浏览器记住你的工作习惯，比如你的常用搜索术语、打开频率高的文档类型。下次再搜类似内容时，结果是排序过的。但Dia的问题也很明显：平台锁死——目前只支持macOS Apple Silicon，Windows用户还在waitlist上。而且它还处于邀请制beta阶段。评分：7.8/10ChatGPT Atlas：OpenAI亲自下场做浏览器Atlas是OpenAI在2025年10月发布的首款独立浏览器。它的核心思路和Dia不一样——它不是给浏览器加AI功能，而是把ChatGPT做成浏览器。最大杀器是 Agent Mode。有了用户许可后，AI可以替你点链接、填表单、跨标签页比较信息、甚至写邮件。我让它帮我比较三家云服务商的GPU定价——它真的开了五个标签页，逐一抓取价格数据，最后在侧边栏整理成了一张对比表。Atlas还有一个可选的 Memory 层，让浏览器记住你的浏览历史。你可以随时查看、修改、删除这些记忆。OpenAI明确表示默认不使用你的浏览数据训练模型。限制也不少：目前也是macOS only（Apple Silicon），Agent Mode需要Plus/Pro订阅。复杂多步骤任务偶尔会卡在reCAPTCHA上——AI暂时还不会认红绿灯。评分：7.5/10Perplexity Comet：搜索之王的浏览器化Perplexity把自家的AI搜索引擎直接做成了浏览器。Comet是Chromium内核，这意味着Chrome Web Store的全部扩展都可以直接用。它的杀手锏是模型切换：在侧边栏输入 /gpt 用GPT-4o、/claude 用Claude 4 Sonnet、/gemini 用Gemini 2.5 Pro。我平时做调研时，经常用同一个问题三个模型各跑一遍，看谁的回答质量更高。还有连接器（Connectors）功能——可以绑定Gmail、Google Calendar、Notion、Slack、GitHub。比如GitHub Notification太多，直接在Comet里让它总结今日未读Issues的分类和优先级。但Comet的代理浏览成功率我实测下来只有65%左右。简单任务（页面摘要、比价）很靠谱，复杂多步骤（注册流程、多步表单）经常卡住或跑偏。另外，AI功能会通过Perplexity服务器路由页面内容——隐私敏感场景要慎重。价格：Perplexity Pro $20/月包含Comet使用权。评分：7.0/10横向对比与选型建议三款产品的定位其实很清晰： Dia — 渐进增强派：保留浏览器本来面目，用AI强化每一个操作环节。适合"我想保留浏览习惯但希望AI辅助"的用户。 Atlas — 彻底重构派：用ChatGPT的交互模式重塑浏览器。适合ChatGPT重度用户，尤其是Plus/Pro订阅者。 Comet — 窄化极致派：把AI搜索引擎和代理浏览推向极致。适合需要深度调研、多模型对比的进阶用户。 选型建议： 内容创作者/研究者 → Dia（对话体验最好） ChatGPT日常用户 → Atlas（生态捆绑最紧） 深度调研需求 → Comet（多模型+连接器） 隐私敏感用户 → 这些都还不适合，回Chrome+本地AI方案 写在最后两个礼拜用下来，我最大的感受不是「AI浏览器有多强」，而是浏览器这个十年没变过的东西，终于开始变了。三款产品都还在早期，都不完美。但这恰恰是最好的体验时机——在它们还没被巨头垄断、还没有固化搜索习惯之前，自己上手试一圈，形成你的判断。你试过哪款AI浏览器？评论区聊聊你的体验～免责声明：本文为个人主观体验，版本截至2026…

AI代码审查工具2026实测：CodeRabbit、PR-Agent、Copilot 价格/误报率/审查深度全对比
type: item
date: 2026-07-01T14:12:01+08:00
description: AI代码审查工具2026实测：CodeRabbit、PR-Agent、Copilot 价格/误报率/审查深度全对比摘要：本文实测了三款主流AI代码审查工具（CodeRabbit、PR-Agent、GitHub Copilot Code Review），覆盖价格结构、误报率、审查深度、集成难度四个维度。适合正在评估AI代码审查工具的工程团队参考。为什么需要AI代码审查代码审查是软件工程里最容易被低估的瓶颈。一个10人团队，每天少说十几个PR。人工review占掉了大量本该写代码的时间，而且审查质量参差不齐——资深工程师觉得太简单不想看，初级工程师看不出问题，最后要么合并了带bug的代码，要么审查流程变成了橡皮图章。2026年，AI代码审查工具已经从"尝鲜"变成了"日常"。但"日常"不等于"无脑用"——你需要知道每个工具的边界在哪里，成本结构是什么，调优需要多少时间。这篇文章是我过去两周实测三款工具的结果。价格、误报率、审查深度、集成难度，全都说清楚。三款工具概览CodeRabbitCodeRabbit是一个专业AI代码审查平台，总部在旧金山。核心卖点是40多个linter和SAST扫描器的集成，加上一个能学习你团队编码习惯的配置系统。你用YAML文件定义代码规范，它按你的规范审查，而且会随着反馈越来越准。除了审查，还能生成docstring、单元测试、站会报告。支持VS Code、Cursor、Windsurf和CLI。支持平台：GitHub、GitLab、Azure DevOps、Bitbucket 计费模式：按PR作者计费（审查者不收费） 安全认证：SOC 2 Type IIPR-Agent（Qodo/CodiumAI）PR-Agent的前身是CodiumAI的开源项目。2024年CodiumAI更名为Qodo后，PR-Agent迁移到了The-PR-Agent组织，作为独立开源项目维护。GitHub上有11700多颗星。它的思路很简单：你在PR评论区发slash命令（/describe、/review、/improve、/ask），它就执行对应操作。完全自托管，可以跑在GitHub Action、GitLab CI、Bitbucket Pipeline里。LLM用自己的API Key（BYOK），所以你只付OpenAI或Anthropic的调用费。支持平台：GitHub、GitLab、Bitbucket 计费模式：开源免费（Apache 2.0），用户承担LLM API费用 商业版：Qodo Teams $19-30/user/月GitHub Copilot Code Review2026年6月1日，GitHub把Copilot的计费模式从"premium request units"改成了"AI Credits"——1 credit等于1美分，按token消耗计费。代码补全在所有付费套餐里都是无限的，不消耗credits。但chat、agent模式、代码审查都要消耗credits。Copilot的代码审查功能不是独立产品，而是Copilot平台的一部分。好处是和GitHub工作流集成最深，坏处是只支持GitHub。支持平台：仅GitHub 计费模式：AI Credits（$0.01/credit），按token消耗 代码补全：所有付费套餐无限次，不消耗credits价格对比：10人团队月成本我按10人团队、月均100个PR算了三档场景。轻度使用（每个PR约200行代码）工具月成本（USD）月成本（CNY）备注PR-Agent开源版$50-100¥363-725LLM API费用（GPT-4o-mini）GitHub Copilot Business$190¥1,37810用户×$19CodeRabbit Pro$240¥1,74010作者×$24（年付）中度使用（每个PR约500行，需要测试生成）工具月成本（USD）月成本（CNY）备注Qodo Teams$300¥2,17510用户×$30GitHub Copilot Pro+$390¥2,82810用户×$39CodeRabbit Pro+$480¥3,48010作者×$48（年付）重度使用（每个PR约1000行，高频agent工作流）工具月成本（USD）月成本（CNY）备注CodeRabbit Enterprise定制（预估$800+）¥5,800+需联系销售Qodo Enterprise定制（预估$600+）¥4,350+需联系销售GitHub Copilot Max$1,000¥7,25010用户×$100一个值得注意的细节：CodeRabbit按PR作者计费，审查者不收费。如果你团队10个人但只有5个人开PR，CodeRabbit的实际成本会减半。Copilo…

小红书算法2026底层转向：为什么收藏率比点赞更值钱
type: item
date: 2026-06-30T12:37:37+08:00
description: 说实话，我最近看数据的时候发现一个有意思的现象。有些笔记点赞数一般，但收藏率特别高。另一些笔记点赞不少，收藏却寥寥无几。按过去的经验，点赞多的应该是「爆款」。但现在的算法似乎不这么认为了。我开始认真研究这件事，越看越觉得，2025-2026 年小红书的内容推荐机制，正在经历一次底层转向。这次转向的核心，不是「点赞 vs 收藏」这么简单。而是平台对「内容价值」的判断标准，从浅层互动转向了深度行为。这篇文章，我想把这件事讲清楚。一、点赞正在失去算法权重先说一个可能让你意外的事实。在小红书的内容推荐核心公式 CES 评分里，点赞的权重只有 1 分，和收藏并列最低。CES = 点赞数 × 1 + 收藏数 × 1 + 评论数 × 4 + 转发数 × 4 + 关注数 × 8更关键的是，2025 年平台引入了大量隐性评估维度——截图次数、保存行为、深度阅读率、完播率。这些指标不直接显示在前端，但在算法精排阶段，它们对流量层级的影响远超点赞。本质上，点赞越来越偏向「社交礼仪」。用户随手双击表示「看到了」，但不一定真正需要那条内容。收藏则不同。用户要把笔记收入「待看清单」「旅行攻略」「护肤心得」这些文件夹，等于向算法传递了一个明确信号：「这篇内容值得留存复用」。行为成本完全不同，算法对它们的权重判断自然也不同。二、算法的真实逻辑：从互动量到行为深度2026 年的流量分发路径，比 2023 年复杂得多。一条笔记发布后，先进入种子池（据创作者经验约 200-500 人），测试基础指标（点击率、前 5 秒留存率、前 30 分钟互动率）。通过粗排后，进入精排阶段。精排不再是简单的 CES 分数累加，而是多维度综合评分。据行业观察，各维度大致权重分布如下：原创度（占比较高）互动深度 + 停留时长（关键指标）完播率 / 完读率（重要参考）截图 / 保存 / 分享（深度行为信号）商业价值 / 账号权重（基础门槛）停留时长和深度阅读率成为关键指标。据平台公开说明，用户完整阅读并停留超过 45 秒，内容会被标记为「高质量」。阅读深度低于 80% 的碎片化笔记，可能直接被打入低质内容池。还有一个值得关注的趋势：小红书聚光后台已经把截图次数和保存图片次数纳入数据维度。这两个行为的商业含义非常明确——截图通常是为了「去淘宝以图搜同款」，是购买的前置动作。平台把这类行为归类为「高价值深度互动」，其对内容权重的贡献度可能超过评论和转发。一句话总结这个变化：点赞是情绪，收藏是选择，截图是意图，停留时长度量信任。算法正在从「识别互动」走向「识别真实价值需求」。三、搜索流量成为主战场另一个重大变化是搜索流量的占比。据行业报告，2026 年搜索流量已成为小红书最大流量入口，占比超过 65%。搜索排序公式调整为：搜索流量 = 出价 × 用户需求匹配度 × 内容质量分 × 账号信任分算法已进入意图识别阶段，能区分「信息型搜索」和「交易型搜索」，针对性匹配不同内容类型。关键词堆砌策略失效，乱用关键词甚至触发限流。更值得关注的是「搜后率」这个指标。用户看完笔记后搜索品牌或产品名，系统判定为高度种草转化力，会启动二轮流量助推。长尾词的权重也显著提升。「地域 + 人群 + 场景」的组合词，比大品类词更容易获得精准流量。这意味着，内容的长尾效应变得前所未有的重要。一篇优质笔记的推荐有效期可以延长到 90 天以上，持续从搜索端获取流量。四、什么样的内容更容易被收藏？说了这么多算法逻辑，回到实际问题：什么样的内容更容易被收藏和长时间阅读？我观察了两类内容，它们的共同特征是信息密度高、可操作、有明确的使用场景。案例一：清单型干货有一个做 AI 工具评测的账号，之前发的内容大多是「这个工具好用」「那个工具不行」，点赞不少但收藏率一般。后来他调整了策略，发了一篇《AI 工具挑选的 3 个核心判断标准 + 自检清单》。内容结构是这样的：前 200 字直接抛出核心结论：选 AI 工具不看功能列表，看这三个维度每个维度配一个具体场景和判断标准最后附一个 10 项自检清单，读者可以对照自己的需求逐项打分这篇笔记的点赞数并不是他最高的，但收藏率是平时的 3 倍多。为什么？因为清单型内容有一个天然优势：用户收藏它，是为了以后用。它变成了一个工具，而不只是一条信息。案例二：步骤化教程另一个做自动化工作流的账号，之前发的内容偏理论，讲「为什么要做自动化」「自动化的好处」。后来他改成了步骤化教程：《从手动到自动的 5 个阶段：自动化工作流搭建路线图》。每个阶段都有：这个阶段解决什么问题具体用什么工具输入是什么，输出是什么常见的坑和避坑方法这篇内容的停留时长是他平均值的 2 倍，因为读者真的在一个字一个字地跟着做。步骤化教程的收藏率高，是因为它降低了行动门槛。用户收藏它，是为了回头照着做。这两个案例的共同点是：内容本身变成…

Karpathy LLM Wiki：用 AI 建一个会自动生长的第二大脑
type: item
date: 2026-06-30T12:22:44+08:00
description: Karpathy LLM Wiki：用 AI 建一个会自动生长的第二大脑你问 AI 一百个问题，知识归零一百次。Karpathy 说：换个玩法——让 AI 替你持续编译一本百科全书，问得越多，它越聪明，知识永远不归零。这不是又一个「Obsidian 搭建教程」先说清楚：这篇文章不是教你怎么用 Obsidian 做笔记、怎么整理 PARA、怎么挑插件。那些话题网上已经写得够多了。我要讲的是一种完全不同的知识生产方式——让 LLM 当「编译器」，把你的原始资料增量编译成一本结构化、互相链接的 Markdown 百科全书。这个想法来自 Andrej Karpathy。2025 年 4 月，他在 GitHub Gist 上发了一篇不到 500 字的短文，标题叫 LLM Wiki。没有代码，没有工具推荐，只是一个思路：与其每次提问都让 AI 从原始文档里重新检索、重新拼答案（RAG 的老路子），不如让 AI 把知识预先编译成一本 wiki。交叉引用已经建好，矛盾已经标注，综合结论已经反映了所有已读过的资料。这条 gist 拿到了 55K 点赞，30 多个开源实现紧随其后。为什么一个「让 AI 写 wiki」的想法能引爆全网？因为它戳中了一个每个人都在忍受的痛点——你剪藏了 500 篇文章，一篇也没看过。你问 AI 同一个问题，它每次给你不同答案。你的知识从来没有在「积累」，只是在「循环」。LLM Wiki 要解决的就是这件事。一、为什么不是 RAG？——「增量编译」vs「每次重做」RAG 的问题大多数人用 AI 处理知识的方式，本质上都是 RAG（Retrieval-Augmented Generation，检索增强生成）：上传文件 / 丢链接AI 把文档切成碎片（chunks）你提问时，AI 从碎片里检索出相关的几段拼成一个答案给你结束。下次再问，从头来。NotebookLM 是这样，ChatGPT 的文件上传是这样，绝大多数「AI 知识库」产品都是这样。问题在哪？没有积累。你问了一个好问题，AI 花了一堆 token 检索、推理、综合，给出了一个精彩的回答——然后这个回答就消失了。下次你或者别人问类似的问题，同样的检索、同样的推理、同样的 token 消耗，一切从零开始。这就像每次做菜都从买菜开始。LLM Wiki 的核心差异Karpathy 的方案完全不同：知识被编译一次，然后持续维护，不是每次查询重新推导。打个比方：你有一个助手，不只是帮你做菜——他会帮你备菜、切好、分装、贴标签。下次做菜的时候，直接打开冰箱拿就行。如果来了新食材，他会更新冰箱里的分类，而不是把所有菜都倒掉重来。这就是「增量编译」：新资料进来 → LLM 读取它LLM 对比已有的 wiki 页面更新已有页面（加入新信息、补充细节）创建新页面（如果有全新概念）建立交叉引用（双向链接）标注矛盾（A 页面说 X，B 页面说 Y，但两者冲突）更新索引和日志知识是编译进去的，不是检索出来的。这两者的区别，用一个表格说清楚：维度RAG（每次重做）LLM Wiki（增量编译）知识处理时机查询时实时检索摄入时预先编译知识形态原始文档碎片结构化 wiki 页面交叉引用每次查询重新发现已预先建立矛盾处理可能返回冲突信息已标注并待审核更新方式追加文档到向量库增量更新已有页面人工介入较少（自动索引）较多（审核编译结果）知识积累无（每次从零开始）有（雪球越滚越大）一句话总结：RAG 是「每次现查现答」，LLM Wiki 是「持续编译、越用越厚」。二、Karpathy 的三层架构Karpathy 在 gist 里描述了一个简洁的三层结构。理解这三层，就理解了 LLM Wiki 的全部骨架：┌─────────────────────────────────┐ │ Schema 层（规则） │ ← CLAUDE.md / SYSTEM.md │ 告诉 LLM 怎么组织 wiki │ ├─────────────────────────────────┤ │ Wiki 层（编译产物） │ ← 你的「第二大脑」 │ 概念文章、实体页面、索引、链接 │ ├─────────────────────────────────┤ │ Raw 层（原始资料） │ ← 等待编译的原料 │ 文章、论文、播客笔记、网页剪藏 │ └─────────────────────────────────┘Schema 层：规则书一个 Markdown 文件（通常叫 CLAUDE.md 或 SCHEMA.md），告诉 LLM：目录结构怎么组织文件怎么命名链接格式是什么什么时候创建新页面、什么时候更新已有页面遇到矛盾信息怎么处理这是整个系统的「宪法」。 LLM 每次操作前都会读它，确保编译出来的一致性。Wiki 层：你的百…

Readwise → Obsidian → 本地 AI 问答：完整配置指南与可复制模板
type: item
date: 2026-06-29T22:04:14+08:00
description: Readwise → Obsidian → 本地 AI 问答：完整配置指南与可复制模板> 这篇是技术配置文档，不是散文。目标是你照着做，90 分钟内跑通最小闭环。> 所有需要你自己适配的地方用 ⚠️ 标出。 〇、你要搭的是什么 图：Readwise 高亮进入 Obsidian 金库，经过索引后，变成本地 AI 可以带引用回答的知识抽屉。 阅读源（Kindle/网页/PDF/RSS/Twitter） ↓ Readwise Reader（高亮、标注、AI 摘要） ↓ 自动同步 Obsidian Vault（Markdown 笔记库） ↓ 嵌入索引 Ollama + ChromaDB（本地 AI 问答） ↓ 你问："我读过的关于 X 的所有内容，核心观点是什么？" 四个环节，每个环节单独可替换。下面逐个讲配置。 一、Readwise → Obsidian 同步配置 1.1 前置条件 | 项目 | 要求 | |------|------| | Readwise 订阅 | ⚠️ 必须 Full 计划（$9.99/月年付 或 $12.99/月月付）。Lite 计划不支持导出到 Obsidian | | Obsidian | 1.4+ 版本 | | 网络 | Obsidian 同步时需要能访问 Readwise API | ⚠️ 学生/教育者享 50% 折扣，在 Readwise 设置页提交 .edu 邮箱即可。 1.2 安装 Readwise Official 插件 Settings → Community plugins → Browse 搜索: "Readwise Official" （注意：不是 "Readwise"，不是 "Readwise Mirror"，认准官方标识） 当前版本：v3.0.3（2026 年 5 月发布） 下载量：19.4 万+ 协议：GPL-3.0 GitHub：github.com/readwiseio/obsidian-readwise 安装后点击插件设置里的 Connect，浏览器会跳转到 Readwise 授权页，授权完成即连接成功。 1.3 同步频率设置 插件设置里有同步频率选项： | 选项 | 适用场景 | |------|---------| | 打开 Obsidian 时自动同步 | 推荐。最省心，打开 vault 就拉最新 | | 每 1 小时 | 重度阅读者，实时性要求高 | | 每 12 小时 | 日常使用，每天早晚各一次 | | 每 24 小时 | 轻度使用 | | 手动 | 完全自控 | ⚠️ 建议选"打开 Obsidian 时自动同步"。原因：Obsidian 不是 24 小时开着的，选时间间隔的话，间隔内的高亮不会及时进来。 1.4 同步目标文件夹 在插件设置中指定同步目标文件夹： Readwise Articles/ ⚠️ 不要用根目录。单独建一个文件夹放 Readwise 同步内容，方便后续区分"自动同步进来的"和"自己手写的"笔记。 1.5 同步机制的重要限制（必读） | 行为 | 说明 | |------|------| | 同步方向 | 单向：Readwise → Obsidian，不可逆 | | 追加模式 | 新高亮追加到文件底部，不会覆盖已有内容 | | 修改不同步 | 在 Readwise 中修改高亮文本，Obsidian 中不会更新 | | 重命名陷阱 | 在 Obsidian 中重命名 Readwise 生成的文件后，下次同步会创建一个同名新文件，而不是追加到重命名后的文件 | | 来源延迟 | Kindle/Instapaper/Pocket 的高亮不是实时的，一天只同步几次到 Readwise | ⚠️ 重命名陷阱是最常见的坑。 规则：还在活跃高亮的文档（你还会继续读、继续标注的），绝对不要在 Obsidian 里重命名。已经读完不再取新高亮的文档，重命名没问题。 1.6 Kindle 等延迟来源的处理 如果你用 Kindle 阅读，高亮同步到 Readwise 可能有延迟。处理方法： 1. 登录 readwise.io 网页版 2. 进入 Documents 页面 3. 找到对应文档，点击强制同步按钮 4. 等 Readwise 侧同步完成后，再在 Obsidian 中触发同步 二、Obsidian 侧配置 2.1 与阅读流相关的插件清单 ⚠️ 以下只列与"阅读→沉淀→AI 问答"链路直接相关的插件。其他插件（日记、Git 备份、Omnisearch 等）在之前的文章中已讲过，这里不重复。 | 插件 | 作用 | 是否必须 | |------|------|---------| | Readwise Official | 高亮同步 | 必须 | | Tem…