Search: #开发者效率

面条的草稿箱

1. 20:18 · 2026年5月23日 · 周六

   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.

2. 18:24 · 2026年4月6日 · 周一

   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 ;)

3. 14:03 · 2026年3月13日 · 周五

   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.

4. 22:31 · 2026年2月10日 · 周二

   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.

5. 21:19 · 2025年12月26日 · 周五

   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!

6. 20:27 · 2025年12月14日 · 周日

   如何让 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

7. 23:36 · 2025年12月11日 · 周四

   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 ...

8. 10:29 · 2025年12月3日 · 周三

   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.