编程 | 面条的草稿箱

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.

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.

用好编码代理：Claude Code 2.0 的关键功能与“上下文工程”心法这篇长文把 Claude Code 2.0 当成一个“能动手的工作台”来拆解：不仅讲新功能，更强调如何用更好的流程与上下文管理，让代理稳定产出

Mon, 29 Dec 2025 00:50:48 GMT

用好编码代理：Claude Code 2.0 的关键功能与“上下文工程”心法

这篇长文把 Claude Code 2.0 当成一个“能动手的工作台”来拆解：不仅讲新功能，更强调如何用更好的流程与上下文管理，让代理稳定产出。

1) 先换个视角：你不是“追上更新”，而是“借力变强”

作者给了一个更实用的框架：

• 跟进工具：定期用、定期看更新（不必天天追）。
• 深耕领域：懂业务/系统设计/工程习惯，才能把“未知”变成“可提问、可验证”。
• 多玩多试：用不同模型做同一件事，快速建立直觉与边界。

2) Claude Code 2.0 值得关注的体验升级

一些偏“日常效率”的改动，叠加起来很实用：

• 语法高亮 + 更舒服的评审体验（作者因此更愿意在 CLI 里完成 review）
• /context 看上下文占用（建议复杂任务到 60% 左右就交接或压缩）
• Checkpointing（Esc+Esc / /rewind）：能回到某个检查点，回滚代码与对话
• Prompt suggestions / 历史搜索（Ctrl + R）：减少重复输入
• 更快的模糊文件搜索、队列导航、LSP 插件 等

3) Sub-agents（子代理）怎么用才不浪费

作者重点讲了“子代理不是魔法，是上下文与工具调用策略”：

• Explore：偏“只读搜索专家”，适合快速扫代码库、定位文件与线索。
• general-purpose / plan：更像“全能协作者”，通常会继承更多上下文。
• 关键提醒：不要只依赖 Explore 的摘要。摘要是“有损压缩”，重要文件最好让主代理再读一遍，让信息彼此“交叉注意力”，推理更稳。

4) 核心概念：Context Engineering（上下文工程）

代理之所以“烧 tokens”，不是它话多，而是：

• 工具调用本身 + 工具返回结果都会进入上下文；
• 上下文越长，检索与注意力越容易退化（作者称为 context rot / degradation）。

因此，上下文工程的目标是：

• 把最相关的信息放进来
• 控制“噪音”和重复指令
• 用清晰结构（计划、scratchpad、handoff）对抗跑偏

5) Hooks / Skills / MCP：把“提示词”产品化

作者把这三者放在一起看：

• Hooks：在对话生命周期某个节点自动触发脚本（比如 Stop 后自动提醒/继续下一步）。
• Skills：把领域指令与脚本做成“按需加载”的技能包，避免常驻系统提示导致上下文膨胀。
• MCP：连接外部工具/服务，但要注意“工具定义与中间结果”同样会吃上下文与成本；文中也提到用代码执行环境来降低这种膨胀的思路。

6) 一个很实战的工作流建议

作者的默认搭配大意是：

• Claude（Opus 4.5）偏执行与沟通：更像结对编程伙伴、反馈快。
• Codex 偏 review/找 bug：更克制、误报少，适合做“第二视角审查”。
• 面对难功能：先跑一个“可丢弃的草稿版本”，用它暴露模型的偏差，再用更精准的提示第二轮迭代。

原文链接：https://sankalp.bearblog.dev/my-experience-with-claude-code-20-and-how-to-get-better-at-using-coding-agents/

#ClaudeCode #编码代理 #上下文工程 #AI工具 #软件工程

sankalp's blog

A Guide to Claude Code 2.0 and getting better at using coding agents

A deep dive into Claude Code 2.0 features, Opus 4.5 workflows, and context engineering. Learn sub-agents, MCP servers, hooks, skills, and practical tips to boost your AI-assisted coding productivity.

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

规范驱动开发（SDD）的局限性随着 AI 编程的兴起，一种旧模式正在回归：编写详细的规范文档（Spec），然后期望 AI 能稳定地生成“正确”的代码

Thu, 04 Dec 2025 01:43:23 GMT

规范驱动开发（SDD）的局限性

随着 AI 编程的兴起，一种旧模式正在回归：编写详细的规范文档（Spec），然后期望 AI 能稳定地生成“正确”的代码。然而，这种规范驱动开发（Spec-Driven Development, SDD）在实践中往往会碰壁，原因与当年瀑布流开发模式失败类似——现实的变化总比规范文档快。

为什么规范驱动开发会失败？

1️⃣ 维护成本高昂

编写详尽的规范耗时巨大，而且在需求变更、约束调整时，保持规范与代码同步会产生巨大的维护成本，有时甚至会加倍工作量。

2️⃣ 规范无法反映所有上下文

规范描述了系统“做什么”，却无法解释“为什么”这么做。而“为什么”恰恰承载了关键背景信息，如技术权衡、团队在迭代中的学习、以及塑造解决方案的现实约束。

3️⃣ 过度规范化造成虚假的安全感

一份详细的规范会给人一种“一切尽在掌握”的错觉，但这往往是虚假的。软件开发是一个探索性过程，最重要的洞见往往在构建开始后才会出现。

4️⃣ 抽象层次错误

多数 SDD 工具关注的是实现的细节（“如何做”），比如字段定义、函数签名等，但更重要的是其背后的意图、约束和上下文（“为什么做”）。

什么才是真正重要的？—— 上下文工程

文章认为，AI 编程缺失的不是更详细的规范，而是更完善的上下文保留。AI 原生的开发流程应该：

• 从意图出发，明确要解决的问题和核心约束。
• 保持上下文的实时更新，让团队与 AI 保持同步。
• 让规范跟随代码库，成为动态演进的文档。
• 保留决策背后的“为什么”，而不仅仅是需求。

总而言之，对于需求稳定、边界清晰的领域，SDD 是有效的。但对于不断演化的探索性开发，上下文驱动的方法能更好地适应变化。

原文链接：https://isoform.ai/blog/the-limits-of-spec-driven-development

#AI #软件开发 #编程 #规范驱动开发

isoform.ai

The Limits of Spec-Driven Development - Isoform

We enable private equity firms and mid-market companies to build bespoke AI products 5x faster. Services include AI feature shipping, AI-led integration, data migration, and legacy system modernization.

这篇文章探讨了“制造软件”的真正含义. 作者认为，这远不止是编写代码，而是一个发现、创造和交付价值的完整过程. 它始于深入理解问题和用户需求，终于创造出能为他人生活带来积极改变的工具.真正的挑战在于处理那些模糊不清、充满人性的部分：理解混乱的需求、平衡不同的观点、并在不断变化的环境中找到前进的道路.软件开发是一门手艺，它结合了解决问题的智慧和创造有用工具的乐趣. 从一个想法到最终产品，这个过程充满了挑战，但也带来了巨大的满足感.原文链接：Making Software#软件开发 #产品思维 #编程 #创造力

Mon, 24 Nov 2025 10:22:42 GMT

这篇文章探讨了“制造软件”的真正含义. 作者认为，这远不止是编写代码，而是一个发现、创造和交付价值的完整过程. 它始于深入理解问题和用户需求，终于创造出能为他人生活带来积极改变的工具.

真正的挑战在于处理那些模糊不清、充满人性的部分：理解混乱的需求、平衡不同的观点、并在不断变化的环境中找到前进的道路.

软件开发是一门手艺，它结合了解决问题的智慧和创造有用工具的乐趣. 从一个想法到最终产品，这个过程充满了挑战，但也带来了巨大的满足感.

原文链接：Making Software

#软件开发 #产品思维 #编程 #创造力