Skip to main content

Search: #编程

无原创,纯转发
  1. CursorBench:Cursor 如何更贴近真实开发来评估模型质量

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

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

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

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

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

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

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

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

    #模型评测 #编程智能体 #基准测试 #Cursor #开发者体验 How we compare model quality in Cursor · Cursor
  2. 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 Minions: Stripe’s one-shot, end-to-end coding agents
  3. 用好编码代理: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工具 #软件工程
  4. 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 #编程 Claude Code Skills Don't Auto-Activate (a workaround) - Scott Spence
  5. 规范驱动开发(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 #软件开发 #编程 #规范驱动开发 The Limits of Spec-Driven Development - Isoform
  6. 这篇文章探讨了“制造软件”的真正含义. 作者认为,这远不止是编写代码,而是一个发现、创造和交付价值的完整过程. 它始于深入理解问题和用户需求,终于创造出能为他人生活带来积极改变的工具.

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

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

    原文链接:Making Software

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