开发者效率 | 面条的草稿箱

omp：直接集成 IDE 能力的终端 AI 编码助手oh my pi (omp) 是一个专为终端设计的开源 AI 编码智能体

Mon, 15 Jun 2026 15:52:13 GMT

omp：直接集成 IDE 能力的终端 AI 编码助手

oh my pi (omp) 是一个专为终端设计的开源 AI 编码智能体。它不仅是一个代码生成器，更是一个深度集成 IDE 工具的“全能型选手”，旨在为开发者提供开箱即用、无缝连接的终端开发体验。

核心亮点：

• 深度集成 IDE 工具链：内置 LSP（Language Server Protocol），AI 能够像在 IDE 中一样精准进行跨文件重命名与格式化；同时支持 DAP（Debug Adapter Protocol），可以直接启动调试器（如 lldb, dlv, debugpy）进行单步调试和堆栈排查。
• 创新的 Snapcompact 图像压缩：当对话历史过长时，omp 不使用 LLM 进行文本总结，而是将历史记录渲染成极其微小的像素字体 PNG 图像，并发送给多模态模型读取。这一技术能够确保上下文细节不丢失，且仅消耗约 1/3 的 Token 成本。
• 强悍的 Rust 原生引擎：核心由约 5.5 万行 Rust 代码构建，搜索、shell、AST 分析等高频操作均在进程内完成，避免频繁 fork 子进程，效率极高。
• 本地化记忆与离线整理：使用本地 SQLite 矢量记忆库，并使用本地的小模型（如 Qwen-1.7B / Gemma-1B）在本地整理记忆与会话标题，数据不离设备。
• 强大的协作与扩展性：支持通过 /collab 实现端到端加密的实时会话共享；兼容多种主流编辑器规则（如 Cursor, Cline, Copilot），甚至可以通过 ACP 协议直接在 Zed 编辑器中驱动终端中的同一个 omp 实例。

原链接：https://omp.sh/

#AI编码助手 #编程工具 #Rust #开源项目 #智能开发

omp

omp — a coding agent with the IDE wired in

Subagents, plan mode, LSP, DAP, hindsight memory, hashline edits, time-traveling rules — with a native Rust engine doing the heavy lifting.

Slim Tools：为 AI 智能体减负的统一 MCP 工具网关在使用 AI Agent（如 Claude、Cursor 等）时，你是否遇到过因为加载了太多 MCP 或 OpenAPI 工具，导致上下文窗口（Context Window）被严重占用、Token 消耗飞涨的情况？Slim Tools 提供了一个巧妙的解决方案：它将所有上游工具统一封装进一个极简的 MCP 接口中

Sat, 23 May 2026 12:18:47 GMT

Slim Tools：为 AI 智能体减负的统一 MCP 工具网关

在使用 AI Agent（如 Claude、Cursor 等）时，你是否遇到过因为加载了太多 MCP 或 OpenAPI 工具，导致上下文窗口（Context Window）被严重占用、Token 消耗飞涨的情况？

Slim Tools 提供了一个巧妙的解决方案：它将所有上游工具统一封装进一个极简的 MCP 接口中。

核心特性：

• 统一入口：无需向 AI 暴露所有工具，只需提供一个 Slim Tools 的 MCP URL（https://slim.tools/mcp）。
• 按需探索：AI 代理在运行阶段仅能看到 discover_tools（工具搜索）和 execute_code（沙盒代码执行）两个核心能力。
• 高效联动：AI 通过搜索找到匹配的工具，然后在沙盒中运行代码来组合并调用这些上游 API（如 GitHub、Notion、Slack、Figma 等）。
• 简化授权：统一管理所有上游服务的 OAuth 授权，无需重复配置。

通过这种“运行时发现”的设计，AI 代理无需在上下文里“背负”沉重的工具集，不仅让 Prompt 更加清爽，也让 Agent 的响应速度大幅提升。

原文链接：http://slim.tools

#AIAgents #MCP #开发者工具 #效率工具

Slim Tools

Slim Tools | Tool Orchestration Runtime for AI Agents

Move MCP and OpenAPI tool orchestration out of model context and into one sandboxed runtime.

Gemma 4 图解指南：Google DeepMind 开源模型家族全面解析Google DeepMind 发布了 Gemma 4 系列模型，作者 Maarten Grootendorst（刚入职 Google DeepMind）以丰富的可视化方式详细拆解了这一系列模型的架构设计

Mon, 06 Apr 2026 10:24:46 GMT

Gemma 4 图解指南：Google DeepMind 开源模型家族全面解析

Google DeepMind 发布了 Gemma 4 系列模型，作者 Maarten Grootendorst（刚入职 Google DeepMind）以丰富的可视化方式详细拆解了这一系列模型的架构设计。

四款模型，覆盖多种场景

• Gemma 4 E2B — 密集模型，等效 20 亿参数，适合端侧部署
• Gemma 4 E4B — 密集模型，等效 40 亿参数，适合端侧部署
• Gemma 4 31B — 310 亿参数的密集模型
• Gemma 4 26B A4B — MoE 架构，总参数 260 亿，推理时仅激活 40 亿参数，兼顾性能与效率

所有模型均为多模态，支持图像输入；小模型（E2B/E4B）还额外支持音频输入。

核心架构亮点

注意力机制优化：

• 局部注意力（滑动窗口）与全局注意力交替堆叠（5:1 或 4:1），最后一层始终为全局注意力
• 全局注意力层采用 8 个 Query 共享 1 个 KV 头的分组查询注意力（GQA）
• K=V 技巧：全局注意力层中 Key 等于 Value，进一步压缩 KV 缓存
• p-RoPE：仅对前 25% 维度施加旋转位置编码，避免低频维度引入噪声，提升长上下文处理能力

视觉编码器：

• 基于 Vision Transformer（ViT），支持可变宽高比和可变分辨率
• 通过 2D RoPE 编码 patch 的二维位置信息
• 引入 soft token budget（70/140/280/560/1120），用户可按任务需求灵活选择分辨率

MoE 架构（26B A4B）：

• 128 个专家中每次激活 8 个 + 1 个始终激活的共享专家（3 倍大小）
• 虽然总参数 260 亿，推理速度接近 40 亿参数模型

Per-Layer Embeddings（E2B/E4B）：

• 每一层都有独立的 token embedding 查找表，存储在闪存而非显存中
• 让小模型在有限 RAM 下也能获得更强的表达能力，非常适合手机等端侧设备

音频编码器（E2B/E4B）：

• 基于 Conformer 架构，通过梅尔频谱图提取特征并下采样为 soft token
• 支持语音识别和翻译等任务

🔗 https://newsletter.maartengrootendorst.com/p/a-visual-guide-to-gemma-4

#Gemma4 #GoogleDeepMind #多模态 #MoE #开源模型

Maartengrootendorst

A Visual Guide to Gemma 4

A great start to a new job ;)

CursorBench：Cursor 如何更贴近真实开发来评估模型质量开发者正在把更长、更复杂的编程任务交给智能体：跨多个文件、工具和步骤

Fri, 13 Mar 2026 06:03:11 GMT

CursorBench：Cursor 如何更贴近真实开发来评估模型质量

开发者正在把更长、更复杂的编程任务交给智能体：跨多个文件、工具和步骤。Cursor 认为，评测方式也必须随之升级，才能真实反映“好用与否”。

Cursor 的做法是 线上 + 线下 的混合评测闭环：

• 线下：CursorBench（内部基准）
基于工程团队的真实 Cursor 会话构建，而不是从公开代码库抽题。因为更贴近实际工作流、信息更不充分且常带歧义，CursorBench 往往能更好地区分前沿模型，并衡量多维能力（正确性、代码质量、效率、交互行为等）。

• 线上：真实流量的受控实验
用于捕捉线下评测遗漏的退化：例如线下评分器判“正确”，但开发者实际体验变差。Cursor 会用多类代理指标（交互信号 + 输出质量信号）综合观察，并通过消融实验归因（如移除语义搜索工具来定位其关键场景）。

为什么不太依赖公开基准？Cursor 指出三类常见问题：

1. 任务不匹配：许多基准仍偏向“修 bug”或“解谜题”，与真实开发请求脱节。
2. 评分困难：真实请求常有多种正确解，固定答案容易误伤合理方案。
3. 数据污染：公开仓库题目容易进入训练数据，分数被抬高；甚至出现“记忆补丁”与测试缺陷等问题。

下一步，Cursor 预计开发会更多转向“长时运行智能体”。他们也计划让 CursorBench 适配更长任务，并解决成本、可复现性、以及离线结果与真实体验之间的差距。

原文链接：https://cursor.com/cn/blog/cursorbench

#模型评测 #编程智能体 #基准测试 #Cursor #开发者体验

Cursor

How we compare model quality in Cursor · Cursor

We use a hybrid online-offline eval process to keep our understanding of model quality aligned with what developers actually do.

Stripe「Minions」：一键生成、端到端交付的无人值守编码代理Stripe 在内部打造了一套名为 Minions 的编码代理：从接到任务到产出可评审的 PR，全程几乎无需人类介入

Tue, 10 Feb 2026 14:31:52 GMT

Stripe「Minions」：一键生成、端到端交付的无人值守编码代理

Stripe 在内部打造了一套名为 Minions 的编码代理：从接到任务到产出可评审的 PR，全程几乎无需人类介入。现在，Stripe 每周有超过 1000 个合并的 PR 是由 Minions 从头到尾生成的（人类负责 Review，但不写代码）。

为什么要自研？

在 Stripe 这种超大规模、强约束的工程环境里，“从零写个原型”和“在成熟巨型代码库里安全改动”完全不是一回事：

• 代码库规模巨大（数亿行），栈也相对小众：大量后端是 Ruby + Sorbet，还有大量 Stripe 自研库，LLM 天然不熟
• 业务风险极高：Stripe 的代码承载着 每年超过 1 万亿美元 的支付规模，并受金融合规与监管约束
• 既要让代理“会写”，也要让它“按规矩写、能跑通、能过 CI”，并与既有研发流程深度结合

工程师怎么用？

最常见的入口是 Slack：

• 在讨论线程里 @Slack App 就能发起 Minion，它会读取整个线程与相关链接作为上下文
• 也集成到内部系统里：文档平台、Feature Flag、工单系统等
例如 CI 发现 flaky tests，会生成工单，直接提供按钮让 Minion 去修

完成后，Minion 会：

• 创建分支 → 推送 → 跑 CI → 按模板生成 PR

如果效果不理想，人类可以补充指令让它再改；即使不完美，也常常是很好的“可用起点”。

Minions 背后怎么运作（要点版）

Stripe 的思路是：把“创意生成”交给 LLM，把“必须可靠执行的步骤”交给确定性工具链。

• 运行环境：在隔离的 devbox 中执行（10 秒内可启动，预热并预载代码与服务），与生产与公网隔离，便于并行
• Agent 框架：基于 Block 的开源编码代理 goose 的 fork，并做了强定制
• 规则与上下文：读取各类 agent rule 文件，但多为“按目录条件生效”，避免全局死规则拖累
• 工具调用：接入 MCP（函数调用通用协议），并建设内部 MCP 服务 Toolshed，提供 400+ 工具（文档、工单、构建状态、Sourcegraph 搜索等）
• 反馈与质量闸门：
• 首先跑本地启发式 lint/检查（通常 <5 秒）
• 再跑选择性的 CI（Stripe 有 300 万+ 测试），部分失败可自动修复
• 为控制成本与等待时间：最多两轮 CI，强调“能本地提前发现就不要拖到 CI”

接下来

这篇是系列 Part 1，主要讲“怎么用、能做什么”；Part 2 会深入实现细节。整体信号很明确：当“开发者注意力”成为稀缺资源时，无人值守、可并行的编码代理正在改变工程协作方式。

原文链接：https://stripe.dev/blog/minions-stripes-one-shot-end-to-end-coding-agents

#AI工程化 #编码代理 #开发者效率 #CI实践 #Stripe

stripe.dev

Minions: Stripe’s one-shot, end-to-end coding agents

Minions are Stripe’s homegrown coding agents, responsible for more than a thousand pull requests merged each week. Though humans review the code, minions write it from start to finish. Learn how they work, and how we built them.

2025 年 AI 编程现状：效率在涨，工具与模型在分化Greptile 发布的《The State of AI Coding 2025》梳理了 AI 编程在 2025 年的关键趋势：工程产出显著提升，开发工具生态快速扩张，而不同大模型在“响应速度、吞吐、成本”上的取舍越来越清晰

Fri, 26 Dec 2025 13:19:39 GMT

2025 年 AI 编程现状：效率在涨，工具与模型在分化

Greptile 发布的《The State of AI Coding 2025》梳理了 AI 编程在 2025 年的关键趋势：工程产出显著提升，开发工具生态快速扩张，而不同大模型在“响应速度、吞吐、成本”上的取舍越来越清晰。

1) 工程效率：PR 更大，个人产出更高

• PR 规模变大：2025 年 3 月到 11 月，PR 的中位改动行数从 57 增至 76，约 +33%。
• 开发者产出上升：人均代码产出从 4,450 增至 7,839 行，约 +76%，AI 工具被视为“产能放大器”。
• 中型团队提升更明显：6–15 人团队的人均产出从 7,005 增至 13,227 行，约 +89%。
• 单文件改动更密：每个文件的改动行数中位数从 18 增至 22，约 +20%，说明 PR 不只变大，也更“集中”。

2) 工具采用：从“能用”到“形成标准层”

• 记忆/Memory 基建：mem0 以 59% 份额领跑（按 PyPI + npm 月下载量口径）。
• 向量数据库：没有绝对赢家；Weaviate 约 25%，其余多家在 10–25% 之间拉锯。
• AI 规则文件：CLAUDE.md 使用率 67%；不少团队多格式并存，且 17% 的仓库三种格式都用。
• AI SDK 增长：Anthropic SDK 以 43M 下载领先（约 8 倍增长）；Pydantic AI 增长 3.7× 到 6M。
• LLMOps：LiteLLM 月下载量增长 4× 至 41M（LangSmith 与 LangChain 安装存在绑定关系）。

3) 模型格局：生态差距在收敛

• SDK 下载量：OpenAI 约 130M 领先；Anthropic 自 2023 年 4 月起增长 1,547×；Google 约 13.6M。
• 差距缩小：OpenAI 与 Anthropic 的下载量比从 2024 年 1 月的 47:1，降至 2025 年 11 月的 4.2:1。

4) 作为“编程 Agent 后端”，模型各有侧重

报告用统一参数对多模型做了延迟、吞吐、成本等基准：

• 首 token 响应（TTFT）：Claude Sonnet/Opus（p50 < 2.5s）明显更快，更利于交互式编程保持“心流”。
• 生成吞吐：GPT-5 Codex / GPT-5.1 吞吐更高，长输出更快结束，利于并行跑更多 Agent/CI。
• 成本倍率（以 GPT-5 Codex = 1× 归一）：GPT-5 Codex ≈ GPT-5.1（1×）；Gemini 3 Pro（1.4×）；Sonnet 4.5（2×）；Opus 4.5（3.3×）。

结论很直接：选型不再是“谁最强”，而是你更在意 响应速度、吞吐效率，还是预算。

5) 研究方向：规模、上下文与 Agent 的“系统工程”

报告还汇总了 2025 年影响工具与应用的一批研究线索，包括：

• MoE 的效率设计（如 DeepSeek-V3：关注 KV cache、路由与训练信号密度）。
• 长上下文 vs RAG 的边界（不同数据结构下各有优势；以及 KV 级检索等新思路）。
• Agent 训练与检索策略（用 RL 学会“何时搜索”、如何管理长程记忆、如何降低噪声上下文干扰等）。

原文链接：https://www.greptile.com/state-of-ai-coding-2025

#AI编程 #开发效率 #LLM工具链 #模型评测 #软件工程趋势

Greptile

AI Code Review | Greptile | Merge 4X Faster, Catch 3X More Bugs

AI Code Reviews that understand your entire codebase. Automate PR reviews, catch bugs faster, improve code quality with AI-driven analysis. Try Greptile free!

如何让 Claude Code Skills 可靠激活Claude Code 的 Skills 功能理论上会根据描述自动激活，但实际测试发现激活率仅约 20%，跟抛硬币差不多

Sun, 14 Dec 2025 12:27:39 GMT

如何让 Claude Code Skills 可靠激活

Claude Code 的 Skills 功能理论上会根据描述自动激活，但实际测试发现激活率仅约 20%，跟抛硬币差不多。作者通过 200+ 次测试，找到了两种有效方案。

测试结果对比：

• Simple 简单指令：整体成功率仅 20%
• Forced Eval 强制评估：成功率 84%，最稳定
• LLM Eval 预评估：成功率 80%，更快更省钱

核心发现

强制评估之所以有效，在于它创建了「承诺机制」：

1. Claude 必须逐一评估每个 Skill 并给出 YES/NO
2. 明确表态后才能继续实现
3. 使用 "MANDATORY"、"CRITICAL" 等强硬措辞增加执行力

如何选择

Forced Eval：追求稳定性，不介意输出冗长
LLM Eval：追求速度和成本，适合单一技能场景

使用方法：在 .claude/hooks/ 创建对应脚本，并在 settings.json 中配置 hook。如果用 claude-skills-cli，可直接运行：

pnpm exec claude-skills-cli add-hook

🔗 原文链接

#ClaudeCode #Skills #开发技巧 #Anthropic #AI工具

GitHub

GitHub - spences10/claude-skills-cli: 🤖 CLI for creating Claude Agent Skills with progressive disclosure validation. Built for…

🤖 CLI for creating Claude Agent Skills with progressive disclosure validation. Built for Claude Code to use when humans ask it to create skills. - spences10/claude-skills-cli

Claude Code Skills 不会自动激活？这有个解决方案Claude Code 的 Skills 功能号称是"自主激活"的——只要你的请求匹配技能描述，Claude 就会自动使用

Thu, 11 Dec 2025 15:36:38 GMT

Claude Code Skills 不会自动激活？这有个解决方案

Claude Code 的 Skills 功能号称是"自主激活"的——只要你的请求匹配技能描述，Claude 就会自动使用。但现实很骨感：它根本不会。

作者创建了一个 research 技能，用于验证信息来源。每当说"research this"，Claude 应该自动调用该技能。结果呢？Claude 每次都无视技能，直接蛮干。

问题根源

Claude 太过专注于完成任务，会直接跳过检查可用工具的步骤。即使 Hook 提醒"检查一下 skills"，Claude 也当成背景噪音忽略。

解决方案：用 Hook 强制激活

核心思路：不要依赖"自主激活"，而是通过 UserPromptSubmit Hook 检测触发词，显式命令 Claude 使用技能。

# 温柔提醒（无效）
echo '💡 Check skills for relevant skills'

# 强制指令（有效）
echo "🔍 INSTRUCTION: Use Skill(research) to handle this"

区别在于：一个是"请考虑一下"，另一个是"闭嘴听令"!

更简洁的通用方案

后来作者发现了更简单的方式——一条通用 Hook 指令适用于所有技能：

"command": "echo 'INSTRUCTION: If prompt matches any skill keywords, use Skill(skill-name) to activate it.'"

无需维护关键词脚本，无需处理冲突。

实测结果

20 次测试，成功率约 50%——基本靠运气。但比维护复杂脚本省心多了。

结论：官方说 Skills 会自动激活，实际不会。用简单 Hook 碰碰运气，重要任务还是显式调用 Skill(skill-name) 最靠谱。

🔗 原文链接

#ClaudeCode #AI工具 #开发技巧 #Hooks #编程

Scott Spence

Claude Code Skills Don't Auto-Activate (a workaround) - Scott Spence

So I got Claude Skills to register with Claude Code (sorted the
YAML formatting issue),
and the skills are now showing up when I ask Claude ...

Mistral AI 发布新一代开源模型 Mistral 3Mistral AI 今日发布了其下一代 AI 模型系列 —— Mistral 3，包含一个前沿的大模型和一系列为边缘计算优化的小模型，全部在 Apache 2.0 许可下开源

Wed, 03 Dec 2025 02:29:55 GMT

Mistral AI 发布新一代开源模型 Mistral 3

Mistral AI 今日发布了其下一代 AI 模型系列 —— Mistral 3，包含一个前沿的大模型和一系列为边缘计算优化的小模型，全部在 Apache 2.0 许可下开源。

Mistral Large 3
一款顶级的稀疏混合专家（MoE）模型，拥有 41B 激活参数和 675B 总参数，性能可与最强的闭源模型相媲美。它在多语言对话和图像理解方面表现出色。

Ministral 3 系列
专为边缘和本地应用设计，提供 3B、8B 和 14B 三种尺寸，实现了卓越的性价比和效率。同样具备多模态和多语言能力。

核心亮点

完全开源：所有模型均采用 Apache 2.0 许可，开发者可自由使用和定制。
多模态与多语言：原生支持文本、图像理解以及超过 40 种语言。
强大生态合作：与 NVIDIA、vLLM 及 Red Hat 紧密合作，提供高效的推理和部署支持。
广泛可用：已登陆 Hugging Face、Amazon Bedrock、Azure 等多个平台。

Mistral 3 的发布进一步推动了开放、透明和可访问的 AI 发展，为开发者和企业提供了更强大的工具。

原文链接：https://mistral.ai/news/mistral-3

#MistralAI #AI #LLM #开源模型 #Mistral3

Mistral AI

Introducing Mistral 3 | Mistral AI

The most powerful AI platform for enterprises. Customize, fine-tune, and deploy AI assistants, autonomous agents, and multimodal AI with open models.