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

上周 Cursor 正式宣布成为 SpaceX 子公司，同时发布 Grok 4.6——这是两家合并后推出的首个模型。比起"又一个大公司收购创业公司"的常规叙事，这件事对 AI 编程工具行业的影响要深刻得多。 不是收购，是算力整合 官方说法是"四月开始的 SpaceXAI 合作"终于落定。但措辞值得细读："Access to the largest fleet of GPUs in the world"——这不是财务投资，是算力供给的垄断性整合。 Grok 4.6 的发布节奏印证了这一点。八月十二日发布，五天后收购敲定，中间没有时间差。这意味着 Grok 4.6 的训练已经在 SpaceX 的 GPU 集群上完成了。换句话说，Cursor 早就用上了 SpaceX 的算力，收购只是把"合作关系"变成"所有权关系"。 这对竞争对手是结构性的压制。训练大模型的成本有三分之一在 GPU 租赁或采购上。如果 SpaceX 愿意把全球最大 GPU 集群的空闲算力输送给 Cursor，Cursor 的模型训练成本会显著低于需要从 AWS、 GCP 采购算力的竞品。这个优势会随时间积累，越来越难追赶。 Grok 4.6：长程 Agent 的工程答案 Grok 4.6 的定位很清晰——面向长时运行 Agent 和高复杂度交互任务。Cursor 官方说法是：它能在多个步骤间保持任务连贯性，从研究、代码库分析到"把产品想法变成可运行的第一版"。 有几个技术细节值得关注： 自我验证开始出现。 Cursor 团队提到，在长轨迹任务中，Grok 4.6 展现出"在继续下一步之前检查自己工作"的倾向。这是 Agent 从"执行指令"到"自主质量控制"的关键一步，也是 Code Review Agent 真正可用的基础。 视觉和交互项目的一次成功率提升。 给一个具体产品想法，模型能在一轮内建立结构和视觉语言。这对 prototyping 阶段的效率影响很大——意味着 Agent 能直接产出"可展示"而非"可参考"的中间产物。 ...

过去两周 Cursor 动作密集，三条主线值得关注：云端 Agent 启动速度 3x 提升的安全感工程、AIUC-1 认证背后的企业级 Agent 安全标准确立，以及 Firetiger 团队收购所揭示的「Coding → Production」闭环战略。三条线各有侧重，合在一起是 Cursor 在 Agent 基础设施和商业信任上的双重押注。 Builds：不是缓存，是快照 云端 Agent 的启动延迟是一个被低估的问题。传统模式是"用时再配"：克隆仓库、安装依赖、跑安装脚本——大型代码库上这可以耗时数分钟，Agent 在这期间完全空转。业界常见解法是"预热实例"或"保持常驻"，但资源成本高、状态管理复杂。 Cursor 的 Builds 方案本质上是一个文件系统快照 + 进程状态预热的组合：后台持续 fork warm copy（而非每次从磁盘恢复），克隆和依赖安装全部在构建阶段完成。这让 Agent 启动变成"直接进入已就绪状态"，Cursor 内部环境实测 10x 启动加速、3x 首 token 时间。 真正有价值的工程细节在于失败隔离：一旦某次构建失败（比如依赖更新破坏了安装脚本），该构建永远不会被激活，已有的 Agent 继续正常运行。Fail-fast + 持续可用的设计哲学比单纯的缓存要优雅得多——它解决的不只是"快不快"，更是"能不能持续稳定地快"。 AIUC-1：Agent 安全终于有标准了 AIUC-1 是一个有意思的认证体系——它不只审计"数据怎么存"，更测试"Agent 本身在压力下怎么行为"。对于编程 Agent，这包括：被要求生成不安全代码时的拒绝能力、MCP 调用安全边界、敏感信息泄露风险，以及破坏性操作（删除数据、运行危险命令）时的行为。 Cursor 通过了 Schellman 的独立审计，横跨数千个对抗性场景，两轮测试全部通过。这不是一张买来的证书，而是把安全设计暴露给专业红队做实弹射击的结果。 更有意思的是季度复审机制：认证不是一次性的，AIUC-1 每季度重新测试，标准本身也随 Agent 能力进化而更新。这意味着 Cursor 的安全基线会随时间被迫提升——当 Agent 能做的事更多，评判标准也水涨船高。对企业安全负责人来说，这是一个可量化的信任锚点。 Firetiger：代码写完，运维谁来接管？ Firetiger 是收购的核心主角，团队背景是 Cloudflare、Twitch、Segment、Twilio 的生产系统运维老兵。他们做的是：代码部署后的监控、回归检测、故障调查——并把结果反馈给 Coding Agent。 ...

语音替代键盘：我的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从'自由发挥的概率模型'，变成一个'有边界、可验证、可审计、可恢复的工程系统'。

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

作为独立开发者，我为什么选择 Eino 来构建 AI 应用（Go语言） 独立开发者做 AI 应用，最怕两件事：一是踩坑，二是被框架绑架。 踩坑意味着你花了两周搭的系统，上线后发现根本撑不住并发，或者调试起来像开盲盒；被框架绑架意味着框架的每一次大版本更新都是你的加班夜。 我花了一段时间评估了几个主流选项，最后在自己的项目里选了 Eino。说说理由。我使用的 Eino 版本如下： github.com/cloudwego/eino v0.8.13 你一个人，精力是最稀缺的资源 独立开发者和公司团队最大的区别，不是技术水平，而是精力分配。你同时要管产品、设计、开发、运营，留给"研究框架"的时间极其有限。 这就是为什么框架的设计哲学对你来说比对大公司更重要。一个设计混乱的框架，会把你困在细节里；一个设计清晰的框架，让你专注在真正重要的事上。 Eino 的核心设计思路很简单：把能力拆成组件，把流程描述为图，框架处理所有脏活。 你需要一个 RAG 系统，就把检索、提示词、模型调用几个节点连起来；你需要一个能用工具的 Agent，就把工具注册进去，Agent 的循环调用逻辑框架全包了。 你不需要理解流式数据如何在节点间传递，不需要手写工具调用的解析循环，不需要自己实现多轮对话的上下文管理。这些都是框架该做的事，Eino 做了。 字节跳动帮你提前踩过坑 独立开发者最大的风险之一，是用了一个没有生产验证的框架。看起来文档漂亮，demo 跑得顺，真到线上就各种奇怪问题——并发时状态串了，流式输出在特定场景下卡住了，Token 超限时框架直接崩了。 Eino 在字节跳动内部跑了超过半年，支撑着豆包、TikTok 这类亿级用户的产品。这不是说拿来炫耀的背书，而是一个工程上的实际意义：那些你独自开发时可能要花几个月才踩到的边界 case，字节内部的工程师已经踩过了，并且修掉了。 你站在他们的肩膀上出发，少走很多弯路。 Go 语言是独立开发者的好朋友 很多 AI 框架是 Python 的，Python 当然没有问题，但如果你的后端是 Go 写的——或者你打算用 Go——那嵌入一套 Python 框架会带来真实的运维成本：两套依赖管理、两个运行时、两种调试工具。作为一个人，你付不起这个代价。 Eino 是原生 Go 框架，跟你现有的 Go 服务深度集成，单二进制部署，没有额外的运行时负担。Go 的强类型也意味着很多错误在写代码时就被发现，而不是到线上才暴露——对于没有 QA 团队的你，这一点格外重要。 你不用从零开始集成所有东西 独立开发者做 AI 应用，通常需要接入：某个大模型 API、某个向量数据库、某个可观测性工具。每接一个，都要读一遍 SDK 文档，写一堆胶水代码。 Eino 的扩展库（EinoExt）已经帮你把这些都做了。OpenAI、Claude、Gemini、豆包 Ark、Ollama，开箱可用；Elasticsearch 等向量存储，直接接；OpenTelemetry 的 Tracing，一行配置。你换模型供应商不需要改业务代码，换向量库也一样——因为 Eino 的组件接口是统一的，实现是可替换的。 ...