Developer Tools

两天之内 4700+ Star，241 条 HN 评论——小米 MiMo Code 的发布在开发者社区引起了不小的波澜。但让我真正感兴趣的不是这个数字本身，而是它背后的策略：fork 一个已经有 17 万 Star 的开源项目 OpenCode，然后在上面叠加自己的东西。 坦白说，“大厂 fork 开源项目"这件事本身就自带争议。HN 评论区有人直接开喷：“fork 一个已有的开源项目，不给上游贡献代码，附加可能跟 MIT 许可证冲突的使用限制，然后还要 PR。“但也有另一种声音：如果 fork 出来的东西确实有实质性的技术创新，那这件事本身就有讨论的价值。 所以这篇文章想回答的核心问题是：MiMo Code 到底加了什么？这些加的东西值不值得一个独立项目的存在？ 从 OpenCode 到 MiMo Code：不是换层皮那么简单 先说上游项目。OpenCode（现在叫 opencode）是一个终端原生的 AI 编程助手，17 万+ Star，TypeScript 写的，支持多 Provider、TUI 界面、LSP、MCP 协议和插件系统。它在 2025 年 4 月创建，到现在已经迭代了一年多，是终端编程 agent 领域里用户量最大的开源项目之一。 MiMo Code 保留了 OpenCode 的所有核心能力——多 Provider 切换、TUI 交互、LSP 集成、MCP 工具协议和插件系统——在此基础上叠加了五个关键模块。从源码结构看，它在 packages/opencode 目录下保留了 OpenCode 的核心代码，同时新增了 packages/app、packages/desktop、packages/enterprise、packages/sdk 等模块，看起来不只是一个 CLI 工具，而是一个完整的平台化产品。 持久化记忆系统 —— 这可能是最有意思的部分。它用 SQLite FTS5（全文搜索）做底层存储，维护一个 MEMORY.md 文件作为跨会话的项目知识库。每次你开新会话，记忆自动注入上下文，agent 不需要重新理解项目结构。 ...

最近 HN 上有篇帖子引起了我的注意：一个叫 Lathe 的开源项目，247 points，标题是"Use LLMs to learn a new domain, not skip past it"。 说实话，看到这个标题的第一反应是：又一个 LLM 教学工具？市面上这类东西已经太多了——NotebookLM、各种 AI tutor、ChatGPT 自己就能教你任何东西。但仔细看完 README 和 HN 评论区之后，我觉得这个项目抓住了一个很多人没说出口的痛点。 问题出在哪？ 过去一年，“Vibe Coding"这个概念从 Andrej Karpathy 的一条推文变成了整个行业的主流工作方式。打开 Claude Code、Cursor 或者 Copilot，描述你想要什么，AI 帮你生成代码，你负责 Review 和微调。效率确实高，但这里有一个很少被正面讨论的问题：你到底学到了什么？ HN 上另一篇今天 807 points 的帖子——“LLMs are eroding my software engineering career”——把这个焦虑写得很直白。一位资深工程师说，LLM 正在侵蚀他的软件工程职业，他不知道该怎么办。评论区里各种声音都有，但核心矛盾其实就一个：当 AI 代劳了思考过程，工程师的价值在哪里？ 这不是杞人忧天。看看现在的 AI 编程成本追踪工具（比如 Budi）就知道，很多团队每个月在 AI 编程上的开销已经不小了。但如果你问这些开发者"你从 AI 生成的代码里学到了什么”，大部分人会沉默。 Lathe 的反直觉设计 Lathe 的作者 Deven Jarvis 在 README 里写了一段很长的个人经历，我读完觉得挺真诚的。他在 2000 年代通过 PSP 自制游戏社区学会了编程，后来通过各种 hands-on 教程（build-your-own-x、Crafting Interpreters 这类）不断精进。他说这些教程给他的不只是知识，更是"从零到一"的信心和继续深入的底气。 ...

我对“给 Agent 做代码搜索”这类工具一直有点警惕。 原因很简单：很多产品把问题讲成“grep 太笨，向量检索更聪明”，最后落地却变成另一个黑盒。Agent 找不到符号定义时，开发者至少还能看见它 grep 了什么；如果换成一个语义搜索服务，结果看起来更像魔法，但错的时候也更难排查。 所以看到 HN 上的 Semble 时，我第一反应不是“又一个代码 RAG”，而是问一个更工程化的问题：编程 Agent 到底需要什么样的代码搜索？ Semble 的答案挺明确：它不是给人做 IDE 搜索，也不是给企业做大规模代码知识库，而是给 Claude Code、Codex、Cursor、OpenCode 这类编程 Agent 提供一个本地、低延迟、少 token 的代码检索层。HN 原帖标题也很直接：Show HN: Semble – Code search for agents that uses 98% fewer tokens than grep。截至我写这篇时，项目在 GitHub 上已经超过 1000 stars，最近提交也在 2026 年 5 月，至少不是一个空 README 项目。 为什么 grep 对 Agent 不够友好 人用 grep，其实会做很多隐性判断。 你搜 auth，看到 30 个文件，会快速扫目录名、测试文件、legacy 文件，再决定先打开哪个。你会知道 auth_test.py 不是主实现，compat/ 里可能只是兼容层，AuthProvider 的定义比调用点更重要。 Agent 就没这么省。 它通常会先 grep，一个关键词命中几十个文件，然后 read 一堆文件。每多读一个文件，就多消耗上下文窗口、多花钱、多增加模型注意力噪声。更麻烦的是，Agent 经常会被“看起来相关”的调用代码带偏，最后改了外围逻辑，真正的核心函数反而没碰。 ...

如果你用过 Claude Code、Codex CLI 或 Cursor 这类编程 Agent，大概率见过一种很烦人的失败模式：它明明已经读完文件，却又回头读一遍；明明应该先写测试，却开始大面积重构；明明只是修一个 20 行 bug，却顺手动了 6 个模块。最后 token 花了，diff 也出来了，但你不敢合并。 我越来越觉得，这不是“模型不够聪明”一个问题。 更准确地说，是我们把 Agent 放进了一个没有交通规则的城市：Read、Grep、Edit、Bash、Web、MCP 工具全都摊在它面前，然后指望一段系统提示词告诉它“请谨慎驾驶”。提示词当然有用，但它不是刹车，也不是红绿灯。 这也是 Statewright 最近在 HN 上引起我注意的原因。它的口号很硬：Agents are suggestions, states are laws. 用人话翻译：不要只靠模型“自觉”，把工作流拆成确定状态，在每个状态里只开放它该用的工具。 状态机不是新概念，但放在 Agent 上刚好戳中痛点 Statewright 做的事情并不神秘。它让你定义一个工作流，例如 planning → implementing → testing → completed。在 planning 状态里，Agent 只能读文件、搜索代码；进入 implementing 以后才允许 Edit/Write；到 testing 状态，Bash 可以用，但只能跑 pytest、cargo test、npm test 这类白名单命令。 项目 README 里的示例很直观：planning 只给 Read/Grep/Glob，implementing 允许 Read/Edit/Write 且限制 max_edit_lines、max_files_per_state，testing 才给 Bash，并且通过 guard 判断测试是否通过。官方的 workflow schema 也把这些字段明确写成结构化配置，而不是自然语言建议。 ...

你有没有发现一个很尴尬的现象：团队开始认真用 AI 写代码以后，最先失控的往往不是代码质量，而是账单。Claude Code、Cursor、Codex CLI、Copilot Chat 各跑各的，每个人都觉得自己只是“顺手问了一下”，月底看费用才发现它已经变成了一项真实的研发成本。更麻烦的是，你很难回答几个最朴素的问题：钱花在哪个 repo？哪个分支？哪个 ticket？哪类任务最烧 token？一次看起来普通的重构，为什么会突然吃掉几十美元？ HN 上这两天出现了一个小项目 Budi，标题很直白：local-first AI coding cost tracker。它的 GitHub README 说得更具体：Budi 用来追踪 Claude Code、Cursor、Codex CLI、Copilot CLI 和 Copilot Chat 的 token 与成本，并按 repo、branch、ticket、file 做归因，默认数据都留在本机；可选的云同步只上传聚合后的日报指标，不上传 prompt、代码和回复。项目还很年轻，GitHub stars 只有十几个，但最近提交就在 2026 年 5 月，README、Homebrew tap、Cursor/VS Code 扩展和文档都已经成体系。所以我不会把它包装成“成熟企业级平台”，但它抓住了一个真实问题：AI 编程正在从个人效率工具，变成需要治理的工程基础设施。 这件事比“又一个成本看板”重要。 过去我们管云成本，有 FinOps；管服务质量，有 APM；管模型调用，有 LLM gateway 和 tracing。可 AI coding agent 的调用链很奇怪：它发生在开发者本地，混在编辑器、CLI、终端和 IDE 插件里，很多时候并不经过公司统一网关。你当然可以强推所有请求走代理，但这会碰到权限、延迟、离线开发、个人账号和隐私边界等一堆问题。Budi 的路线反过来：不拦在网络路径上，而是读本地已经存在的 transcript / JSONL / SQLite / session-state，再从这些记录里还原 token、模型、时间、项目上下文和成本。 用人话说，它不是收费站，更像电表。 Budi 官网把这个卖点写得很清楚：安装后本机跑一个小 daemon，tail AI 工具已经写到磁盘的 transcript；编辑器里显示状态栏；CLI 用来做 repo、branch、ticket 级别的归因；“Nothing in your network path”。这句话其实是架构取舍的核心。走网络代理的好处是数据完整、控制力强，可以做限流、审计、脱敏和统一 key 管理；坏处是部署重、侵入强，还可能成为单点故障。走本地日志解析的好处是轻、隐私边界清晰、不中断开发者原有工作流；坏处也明显：不同工具日志格式会变，成本估算依赖 pricing manifest，某些 provider 的真实账单可能需要后续 API reconciliation。 ...

如果你已经习惯让 Claude Code 或 Codex 写业务代码，那么下一个很自然的问题是：能不能让同一个 Agent 顺手把产品原型、落地页、PPT、甚至一段演示视频也做出来？ 我以前对这类“AI 做设计”的项目比较警惕。原因很简单：很多工具只是把 prompt 包了一层漂亮 UI，最后产物看起来像模板站，改两轮就塌。但最近 Hacker News 上的 Open Design 让我多看了几眼。它不是另一个单点生成器，而是把 Claude Code、Codex、Cursor Agent、Gemini CLI、Qwen、Copilot CLI 等命令行编码 Agent 当成“设计引擎”，再叠一层本地优先的技能、设计系统、沙盒预览和导出链路。项目 README 直接把自己定位成 Claude Design 的开源替代。 这句话听起来很大，但工程上真正有意思的不是“替代 Claude Design”，而是它暴露了一个更具体的搜索问题：设计工作流到底应该由专门的设计模型驱动，还是由已经会读文件、改代码、跑命令的 Coding Agent 驱动？ 我的判断是：Open Design 不一定会马上成为生产级设计平台，但它代表了一条很值得关注的路线——把设计从“生成一张图”拉回到“生成一个可运行、可审查、可导出的工程项目”。 它不是文生图工具，而是把设计任务工程化 Open Design 的 README 里有几个关键词很关键：local-first、BYOK、agent CLI auto-detect、Skills、Design Systems、sandboxed preview、HTML/PDF/PPTX/MP4 export。翻成人话就是：它不试图自己训练一个万能设计模型，而是把你机器上已有的 Agent CLI 调起来，让 Agent 在一个受控项目里生成和修改设计资产。 这和很多 AI 设计产品的差别很大。后者通常是“输入一句话，得到一个不可解释的视觉结果”；Open Design 更像是“给 Agent 一个设计系统、任务说明和预览环境，让它持续修改文件，直到产物可运行”。 说白了，它把设计任务变成了一种软件工程任务。 这件事的价值在于可迭代性。一个登录页、一份销售 deck、一个移动端交互原型，本质上不只是图片，而是一组结构、样式、文案、资源和导出规则。Coding Agent 已经擅长处理这些东西：读项目、改组件、运行构建、根据错误日志修复。Open Design 做的是把这些能力迁移到设计场景。 这里我会联想到之前写过的 Claude Code Routines：真正稳定的 Agent 工作流，很少靠一次神奇 prompt，而是靠可复用步骤、上下文约束和反馈循环。Open Design 的 Skills 和 Design Systems，本质上也是在给 Agent 建立可复用的“套路”。 ...

真实案例引入：深夜 11 点的 PR 终于有人 review 了 王海（化名）是一家中型 SaaS 公司的后端工程师。团队采用 monorepo 结构，每到周五晚上，积压的 PR 少则七八个，多则十几个。手动 review 耗时耗力，完全丢给 AI review 工具又担心质量。 他尝试的解法：用 Claude Code Routines 配置了一个每周五 20:00 自动运行的代码审查 routine。Claude 会主动拉取本周所有未合并的 PR，按模块分类，生成结构化 review 报告推送到 Slack。第二天早上，他只需要花 20 分钟过一遍 AI 的报告，重点关注高风险变更。 这不是科幻场景——这是 Claude Code Routines 已经支持的真实能力。 背景：Claude Code 不只是交互式工具 Claude Code 最早以"终端里的 AI 搭档"定位——你提需求，它在本地仓库里翻代码、写文件、跑测试。但这套模式的本质还是被动响应：你在，它才动。 2026 年 4 月 14 日，Anthropic 正式发布 Routines 功能（官方文档，HN 热度 700+），将 Claude Code 的能力边界从"交互式"扩展到"自动化"。你可以定义一组任务，让它按时间表、按 GitHub 事件、或按 API 调用触发，在 Anthropic 托管的云端基础设施上自动执行——不需要保持终端打开。 框架核心拆解 触发模型：三种自动化路径 Routines 支持三种触发机制，覆盖了开发者日常中最常见的自动化场景： ...