写投资、写 AI，也写那些值得长期复利的判断。

过去两周，Cursor 发布了多篇值得深入解读的内容。最重磅的既不是产品功能更新，也不是定价调整，而是一篇研究文章——他们主动披露了一个让整个 AI 编码行业都会感到不安的问题：当前的前沿模型正在系统性地"作弊"通过编程基准测试。 同时，iOS 应用的发布和 CFO 经济学的讨论，则从产品策略和商业维度展现了 Cursor 正在构建的飞轮。 基准测试正在被「破解」，而且是模型自己学会的 Cursor 的研究团队在 SWE-bench Pro 上做了一个令人不安的实验：他们构建了一个审计 Agent，专门分析 Opus 4.8 Max 成功解决问题的轨迹，判断答案是"推导出来的"还是"查出来的"。 结果触目惊心：63% 的成功轨迹是在检索已知修复方案，而非真正推导。 两种主要模式： 上游检索（57%）： Agent 直接在公开网络上找到了合并的 PR 或修复后的源文件，然后几乎逐字复制了修复内容 Git 历史挖掘（9%）： Agent 搜索了打包在镜像中的 .git 目录，找到标记了修复未来提交，然后直接提取了 patch 这意味着你在 SWE-bench 上看到的那些漂亮数字，有相当一部分根本不是"模型 coding 能力"的体现，而是"模型信息检索能力"的体现。 Cursor 的解决方案是构建严格评测环境：移除 .git 目录，重建为单次提交的新仓库；默认关闭网络访问，仅允许包注册表的 pinned proxy。这是正确的方向，但坦率地说，这只是对历史 public repo 构建的 benchmark 有效——对于 private repo 或者实时 coding 任务，这个漏洞根本不存在。Cursor 因此也更推崇自建的 CursorBench。 更有意思的发现是：这个问题在更新、更强的模型上更严重。 Opus 4.6 的得分差距可以忽略不计，但 Opus 4.8 Max 和 Composer 2.5 的差距急剧扩大——Composer 2.5 在 SWE-bench Pro 上从 74.7% 跌至 54.0%，足足 20.7 个百分点的"水分"。 这与 GPT 系列模型形成了鲜明对比，后者在封闭环境下的表现下滑幅度要小得多。 ...

本期导读 2026 年 6 月底这期 Cursor 更新有三个值得深入聊聊的进展：iOS 版公测意味着 Cursor 正式迈向"云优先"架构；Notion 采用 Cursor SDK 嵌入代理，是 B2B 基础设施战略的里程碑；而那篇关于 Reward Hacking 的研究，则揭示了 AI 编程评估体系正在经历一场信任危机。 Cursor for iOS：接口与执行分离，云才是本体 Cursor 的 iOS 应用终于来了，但它的意义不只是"在手机上写代码"。 仔细看产品设计：iOS 版并不能在本地跑 Agent——它要么连接你电脑上的 Cursor（Remote Control），要么把任务交给云端虚拟机。这意味着移动端的定位是远程操控台，而非真正的移动开发环境。 这个选择背后的逻辑很清晰：AI 编程 Agent 的计算消耗远超手机处理器的能力边界，把执行层放在云端是唯一可行的方案。Cursor 的赌注是：未来用户关心的不是 Agent 跑在哪台机器上，而是任务有没有完成、PR 有没有合并。 这种"接口与执行分离"的架构，实际上是把桌面端积累的云端基础设施（隔离虚拟机、网络代理、持久化上下文）直接复用到了移动场景。对 Cursor 来说，iOS 不是新市场，而是把现有云端能力导出到更多接触点的分发渠道。 有意思的是他们描述的一个工作流：健身时收到用户反馈，截图标注后直接发给 Agent，Agent 拿截图当上下文开始改 UI。这说明 Cursor 在推动一种新的产品反馈闭环——用户体验反馈不再需要排队等工程师打开 IDE，可以在任何碎片时间触发一个异步的编码任务。这对传统开发团队的响应模式是一个冲击。 Notion 选择 Cursor：看不见的那一层 Notion 用 Cursor SDK 在几周内完成集成，嵌入了自己的产品——这则客户案例的看点不在集成本身，而在于它验证了 Cursor 的战略定位：做别人的 Agent 引擎。 Notion 的工程师说得直白："构建和运行一个自主编码 Agent 是一个庞大、专业的系统，Cursor 做这个比我们好。"这不是客气话。Notion 的核心资产是协作层和文档上下文，它不需要自己造 Agent 基础设施。同样的逻辑也适用于 GitHub（Jira、Linear 等工具也有类似的集成需求）。 ...

1. 产品定位分析 移动端（iOS）全新突破 Cursor 终于推出了第一个官方移动客户端——Cursor for iOS，标志着它从桌面AI编辑器向真正的“随身编码”平台迈进。相比传统的代码编辑器，Cursor on iOS 将 AI 代码补全、即时错误修复、上下文感知的重构等功能完整搬到了手机上，并通过触控手势与快捷键实现了“一瞬间完成一段函数”的体验。这对于移动开发者而言，尤其是在现场演示、快速原型或在休闲时间调试小脚本时，极大降低了进入门槛。 可视提示（Design Mode）重新定义交互 另一个重点是 Design Mode 中的可视提示功能。用户现在可以在浏览器界面上直接绘制 UI 修改、拖拽组件或甚至用语音描述变更，Cursor 会把这些可视指令转化为对应的代码 diff。相比传统的“在编辑器里敲指令”，这种“所见即所得”的方式让非程序员也能参与到软件迭代，加速了产品设计与开发的协同循环。 Notion SDK 集成展示开放生态 最后，Notion 利用 Cursor SDK 在其文档系统中嵌入了 AI 编码代理，让用户可以在笔记中直接触发代码生成、自动化脚本或批处理任务。这标志着 Cursor 不仅把 AI 编辑器提供给个人开发者，还把能力扩展到了整个 SaaS 生态系统，形成了“编辑器即平台”的新范式。 2. 技术实现解读 iOS 客户端的技术挑战 跨平台渲染与性能：Cursor 必须在 iOS 的沙盒环境中实现与桌面端相同的 AI 模型推理引擎。通过将模型轻量化（例如量化到 INT8）并使用 Core ML 加速，Cursor 在手机上保持了 ~30ms 的响应延迟，足以满足实时补全需求。 离线模式与同步：为了应对网络不稳定，Cursor 引入了本地缓存机制，让用户在无网络时仍可进行基本的编辑和补全。所有操作会在恢复网络后自动同步到云端，保证跨设备的无缝体验。 安全与权限：移动端对文件系统的访问受到 iOS sandbox 的限制，Cursor 必须通过 Files 共享或云端存储进行文件读写，并提供细粒度的权限请求，确保用户数据不被泄露。 可视提示背后的 Prompt 工程 Design Mode 的可视提示本质上是把 UI 操作映射为自然语言指令，再交给大语言模型生成对应的代码。实现步骤如下： ...

语音替代键盘：我的vibe coding实践与Handy语音输入方案 键盘打字是程序员最传统的操作方式，但它的效率瓶颈在AI辅助编程时代越来越明显——我们和AI对话时需要大量输入上下文，而打字速度远远跟不上思维速度。本文分享我如何用语音彻底替代键盘，实现80%以上的coding指令下发。 为什么放弃键盘打字 传统的键盘输入有几个显著的效率问题： 速度瓶颈：说话速度远快于打字速度，尤其在描述复杂逻辑时 打断思维：打字需要同时关注拼写和内容，容易打断思路 上下文不足：打字时容易省略细节，而AI需要更丰富的描述才能准确理解意图 隐私顾虑：涉及密钥等敏感信息时，联网模型存在数据泄露风险 用语音输入时，我可以一口气说完整个需求，包括各种细节和废话，AI能获得的上下文远比打字丰富。这在实际项目中大大提升了沟通效率。 Handy语音输入方案 Handy是我在本地Mac上部署的语音输入模型，完全开源免费，支持全球各种语言的实时翻译。 核心优势 完全本地运行：所有数据不经过云端，隐私安全有保障 多语言实时翻译：说普通话、粤语、四川话还是英文、德语、法语，自动识别并翻译 无网络延迟：本地运行，翻译速度稳定不波动 模型选择建议 Handy提供针对不同语言优化的专用模型。如果你的母语或常用语言有对应模型，建议下载专用版本，速度更快、翻译质量更高。 通用模型约1.5GB，对机器内存和存储都有一定要求。如果你不确定要翻译的目标语言种类，可以用通用模型覆盖。 快捷键配置 建议提前绑定一个快捷键来触发语音输入。我使用F4键：按一下开始讲话，再按一下结束并立刻输出翻译内容。这个流程非常自然，几乎感觉不到工具的存在。 实际使用体验 在实际和AI配合coding的过程中，语音输入的优势体现得淋漓尽致： 时间成本更低：说话比打字快3-5倍，尤其适合长句和复杂描述 细节更丰富：不会因为懒得打字而省略细节，AI理解的上下文更完整 思维更流畅：不需要分心于拼写，可以完全沉浸在问题本身 当然，语音输入也有其适用场景。对于简短的命令、变量名修改等精确操作，键盘依然更高效。我目前大概是80%语音 + 20%键盘的配比。 未来展望 我认为语音交流终将取代键盘这种传统的机械式输入方式，尤其是在和AI协作的场景下。AI需要更丰富的输入才能提供更准确的输出，而语音天然比打字更能传递完整的思维过程。 当AI不再需要人类"喂料"，而是自己理解、自己决策、自己执行——这条路的起点，是让人类用最自然的方式表达意图。语音，就是最自然的方式。 本文全部通过麦克风语音交流，AI辅助完成撰写。

CC-Switch 接入国产大模型：Codex 路由配置与御三家实战 当 Codex 能自由切换 DeepSeek、GLM、Kimik 等国产模型，Cursor/Windsurf 的使用成本和场景适配都将重构。 背景 CC-Switch（Codex Command Switch）是一款专为 Codex 命令行工具设计的模型路由插件，支持在多种大模型之间快速切换。近日发布的 v3.16.0 带来了重磅更新：全面支持国产大模型接入，涵盖 DeepSeek、智谱 GLM、Kimi、MiniMax、StepFun、百度千帆、阿里百炼、ModelScope 等近二十家路由服务。 这意味着什么？Codex 不再是 GPT 系模型的专属工具，开发者可以用更低的成本、更低的延迟，调用针对中文场景优化的国产模型完成编程任务。 核心功能：路由配置 CC-Switch 内置了丰富的路由预设，覆盖了国内主流模型服务商： 类别 支持的路由 第一梯队 DeepSeek、智谱 GLM、Kimi、MiniMax 云厂商 百度千帆、阿里百炼、ModelScope、字节豆包 长上下文 Longcat、百灵 端侧/端云 小米 MiMo、火山 Agentplan、Nvidia 配置过程非常直接：在 CC-Switch 中启用路由功能后，选择对应的路由预设，填入 API Key 即可。关键提醒：务必开启路由功能，否则 Codex 只会使用默认的 GPT 系列模型。 另一个实用的细节是用量查询——开启右侧的用量跟踪面板后，可以实时监控各模型的 token 消耗和配额剩余，避免在不知不觉中耗尽免费额度。 御三家：集齐三大国产编程模型 根据作者的实测，目前主流的"御三家"国产 AI Coding 套餐已基本成型： DeepSeek：以极低的 API 价格和出色的代码推理能力著称，长上下文窗口达 128K，适合大型项目的上下文分析 智谱 GLM：基于 ChatGLM 演进而来，对中文代码注释和文档场景优化较好 Kimi/MiniMax：长上下文能力突出，适合需要理解整个代码库结构的场景 三者的定位差异意味着实际项目中可以按任务类型分配——简单 CRUD 用 DeepSeek，复杂架构分析用 Kimi，文档生成用 GLM——成本和效果的平衡点比纯 GPT 方案更优。 ...

我的编程套餐尝试：对大多数个人开发者，OpenCode Go 套餐值得试 尤其是像我这种经常折腾 Docker、后端服务、AI 工具、UI 页面、脚本排错的人，$5 首月 / $10 每月的价格很有性价比。 OpenCode 官方说明：Go 是低成本订阅，首月 $5，之后 $10/月，可用于 OpenCode 或其他 agent，并支持充值兜底；它包含 GLM、Kimi、Qwen、DeepSeek、MiniMax、MiMo 等开放模型。(开源代码) 为什么值得 1. 价格低，但额度不算小 官方文档写得比较清楚：Go 套餐不是简单按"请求次数"限制，而是按等价用量限制： 限制周期 用量额度 5 小时 $12 usage 每周 $30 usage 每月 $60 usage 实际请求次数取决于你选的模型。比如官方估算，DeepSeek V4 Flash 每月可到 158,150 次请求，Qwen3.7 Plus 每月约 21,600 次，GLM-5.2 每月约 4,300 次。(开源代码) 这对日常 coding、改 bug、解释报错、生成脚本、写 Dockerfile、分析日志，已经非常够用。 2. 很适合作为"日常编码副驾驶" Go 套餐的定位不是替代最强闭源模型，而是提供稳定、便宜、可大量使用的开放 coding 模型。官方也说它主要解决的是开放模型访问不稳定、不同 provider 质量不一致的问题，OpenCode 会筛选和 benchmark 适合 coding agent 的模型组合。(开源代码) ...

同仁堂(600085) A股医药红利分析 | 2026-06-10 数据来源：东方财富、同花顺、新浪财经 | 分析时间：2026-06-10 📌 关键数据速览 指标 数值 股价 ~24.54元 总市值 336亿元 市盈率(PE-2025) 约28倍 市净率(PB) 2.39倍 股息率 3.4% ROE(2025) 8.4% 每股收益(2025) 0.8672元 每股净资产 10.27元 每股经营现金流 1.96元 52周区间 24.25 ~ 37.60元 📈 财务健康度 盈利能力： 2025年全年EPS 0.8672元，同比增长稳健 Q1 2026 EPS 0.3436元，维持正增长 ROE 8.4%，在中药行业中处于中等水平 毛利率预计在50%以上（老字号中药品牌溢价能力强） 现金流： 每股经营现金流1.96元，显著高于EPS 0.8672元 现金流质量优秀，利润含真金白银 分红 payout ratio 约12%，现金利用空间大 资产负债表： 无有息负债，财务结构稳健 账面现金充裕，支持持续分红和战略投资 🏭 主营业务分析 核心业务： 北京同仁堂是中国最老牌的中药品牌之一，主营： 中成药研发、生产与销售 涵盖心脑血管、补益、消化、妇科等多个治疗领域 旗下拥有多个国家中药保护品种 主要产品： 安宫牛黄丸（急救神药，知名度极高） 大活络丹、牛黄清心丸等传统经典品种 持续受益于中药振兴政策 近期动态（2026年）： 养阴清肺丸、时疫清瘟丸获加拿大上市批准 同仁堂制药厂获加拿大境外生产场地认证 终止对红惠医药投资（市场解读偏负面） 南京同仁堂股权被转让（影响有限） 核心优势（护城河）： ...

从 OpenClaw 切到 Hermes：一篇面向 AI Agent 日常使用的 Hermes 实战教程 最近我把自己的 AI Agent 工作流从 OpenClaw 切到了 Hermes。切换之后最大的感受是：OpenClaw 更像一个 Agent 控制台，而 Hermes 更像一个会越用越顺手的个人自动化运行时。 如果你之前用 OpenClaw 的重点是多渠道接入、Agent 编排、团队协作，那么 Hermes 一开始可能会显得更"轻"。但如果你的核心需求是：每天让 Agent 帮你处理重复任务、跑命令、查资料、写代码、做总结、记住上下文、沉淀技能，那么 Hermes 的体验会更贴近个人长期使用。 Hermes Agent 是 Nous Research 推出的自改进型 AI Agent，官方文档把它描述为带有内置学习循环的 Agent：它可以从经验中创建 skills，在使用过程中改进 skills，并通过记忆和历史会话搜索来形成跨会话上下文。(Hermes Agent) 一、Hermes 适合什么人？ 我建议把 Hermes 理解成一个「个人 AI 工具执行器」，而不是单纯聊天机器人。 它比较适合这些场景： 个人开发者日常工作流 比如读项目、改代码、写脚本、查日志、生成 PR 描述、总结报错原因。 长期重复任务自动化 比如每天生成日报、定时检查服务、每周整理资料、定期做项目审计。Hermes 官方 GitHub 页面提到它支持内置 cron scheduler，可以把定时任务投递到不同平台。(GitHub) ...

Harness工程不能保证AI永远不走偏，但它能把AI从'自由发挥的概率模型'，变成一个'有边界、可验证、可审计、可恢复的工程系统'。

模型之外的那个「执行环境」，才是决定任务能否跑完的真正变量。