Search: #开发者成长

  1. AI 时代给年轻开发者的六条建议:写代码已经不够了有人问资深工程师 Matthias Endler,今天会给年轻开发者什么建议

    AI 时代给年轻开发者的六条建议:写代码已经不够了

    有人问资深工程师 Matthias Endler,今天会给年轻开发者什么建议。他的回答出人意料——几乎与代码无关。

    学会做产品。 即使 LLM 能写大部分代码,市场仍然需要能理解用户需求、设计方案、根据反馈迭代的人。这项能力不随技术更替而贬值。

    学会学习。 当信息唾手可得,真正稀缺的是批判性思维和基于数据做决策的能力。理解底层原理,远胜于死记硬背和简单的模式匹配。

    学会沟通。 能把想法讲清楚、能激发他人协作的人,影响力是成倍放大的。别做独狼。

    成为问题解决者。 当所有人都用同样的工具时,拉开差距的是你解决问题的速度和质量。选一个问题,深入领域,建立快速反馈循环,不断迭代。

    拥有不止一项技能。 只会写代码的人很容易被替代。把编程能力和你真正感兴趣的领域结合起来——比如健身、金融、教育——这会大幅缩小你的竞争圈。好奇心驱动的探索比纯靠意志力更持久。

    本质上什么都没变。 上一代人或许仅凭编码能力就能找到工作,但最优秀的开发者从来都不只是写代码。工具变强了,意味着"写代码"本身不再是护城河,你必须锻炼其他肌肉。

    🔗 https://endler.dev/2026/advice-to-young-developers/

    #开发者成长 #AI时代 #职业建议 #软技能 #产品思维 Advice to Young Developers

  2. AI Agent 框架如何实现崩溃自愈?深入 Pi 的 Durable Harness v2 架构设计在构建复杂且长周期的 AI Agent 系统时,进程崩溃、外部 API 超时以及并发冲突是不可避免的挑战

    AI Agent 框架如何实现崩溃自愈?深入 Pi 的 Durable Harness v2 架构设计

    在构建复杂且长周期的 AI Agent 系统时,进程崩溃、外部 API 超时以及并发冲突是不可避免的挑战。开源 AI Agent 工具库 Pi(earendil-works/pi)发布了其核心执行引擎 AgentHarness v2 的设计规范,全面重构了 Agent 的持久化、并发与容错模型。

    ---

    核心设计亮点

    1. 确定性持久化与崩溃恢复(Durable Runs)
    预写意图(Intent-first):在执行任何副作用(LLM 请求、工具调用)之前,必须先持久化一条意图记录;执行完成后再将结果作为节点提交。
    零中间态:无论是调用中断、系统崩溃还是上下文超限,重启后都能根据日志精确定位到最近的安全边界进行恢复或重试,绝不产生不一致的脏状态。

    2. Lanes(多泳道并行架构)
    • 引入类似 Git 分支的 Lane 概念。一个会话(Session)拥有唯一的共享对话树,但可以在上面并发运行多个独立的 Lane(如 Slack 频道下的不同 Thread)。
    • 每个 Lane 拥有独立的 Leaf 指针与操作日志,保证多任务互不干扰且免受竞态冲突影响。

    3. 对 KV Cache 极度友好的追加模式(Append-Only Context)
    • 运行中所有交互和配置修改均以追加(Append)形式进入上下文,避免因中间插入导致模型端 KV Cache 失效,显著降低 Token 消耗与延迟。
    • 只有在显式触发压缩(Compaction)时才做重整。

    4. 单步驱动与确定性测试(Deterministic Stepping)
    • 支持 manual 驱动模式:Agent 的每一个网络请求、工具执行、Hook 回调和存储写入都会在虚拟门控前暂停。
    • 开发者和测试套件可以一步步单步调试,任意注入输入或模拟崩溃,彻底消除异步 Agent 系统的难以复现的隐蔽 Bug。

    5. 清晰的职责分离
    Session Tree:只负责只增的对话与事实树,不掺杂编排逻辑。
    Operation Logs:记录状态机流水,专为崩溃恢复服务。
    Hooks 与 Events 分立:Hooks 负责拦截与修改执行流,Events 负责单向、实时的 UI 状态订阅。
    多存储后端:原生适配内存、JSONL 与 SQLite,并向下兼容 v3 格式。

    ---

    对于正在探索长时间运行 Agent、多分支 Agent 或企业级容错工作流的开发者来说,Pi 的 Harness v2 提供了一套非常严谨、工业级的状态机与架构参考范式。

    完整设计文档:https://github.com/earendil-works/pi/blob/harness-v2/j4/packages/agent/docs/harness-v2.md

    #AIAgent #系统架构 #开源项目 #LLM #状态机 pi/packages/agent/docs/harness-v2.md at harness-v2/j4 · earendil-works/pi

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

    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 — a coding agent with the IDE wired in

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

    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

  5. VM0:用自然语言搭建 AI Agent,并在云端 24/7 运行VM0 主打的是「面向 AI Agent 的基础设施」,让你用自然语言定义工作流、在云端沙盒环境里持续运行,并且能完整观测每次执行过程

    VM0:用自然语言搭建 AI Agent,并在云端 24/7 运行

    VM0 主打的是「面向 AI Agent 的基础设施」,让你用自然语言定义工作流、在云端沙盒环境里持续运行,并且能完整观测每次执行过程。

    它能做什么

    一键运行 Agent:支持按需执行或定时调度,适合做日报、监控、内容汇总等自动化任务。
    自然语言构建工作流:在 Claude Code 里描述目标,协作编辑 AGENTS.md,快速拼出可执行的 Agent 指令与流程。
    云端隔离沙盒:本地开发、云端运行,环境隔离,适合让 Agent 长时间稳定跑任务。
    全链路可观测:实时日志、产物输出、执行回放(checkpoint),便于排查与迭代。

    示例场景(官网展示)

    HackerNews 摘要 Agent:自动读 Top 文章,筛选 AI 相关内容并生成可发布的总结。
    TikTok 达人筛选 Agent:搜索与筛选创作者,输出分析报告。
    日报 Agent:聚合多源数据与 API,总结后写入 Notion。
    博客生成 Agent:结合多个 API 自动产出内容。

    快速开始(官网命令)

    npm install -g @vm0/cli && vm0 onboard

    原链接:https://www.vm0.ai/

    #AI代理 #自动化工作流 #云端沙盒 #可观测性 #开发者工具 VM0 - Your Trustworthy AI Teammate

  6. OpenClaw 正式亮相:把 AI 助手带到你常用的聊天软件里OpenClaw 宣布品牌更名,并明确了项目定位:一个运行在你自己的机器上的开源 Agent 平台,可从你日常使用的聊天应用直接调用(WhatsApp、Telegram、Discord、Slack、Teams 等),让 AI 助手“跟着你走”

    OpenClaw 正式亮相:把 AI 助手带到你常用的聊天软件里

    OpenClaw 宣布品牌更名,并明确了项目定位:一个运行在你自己的机器上的开源 Agent 平台,可从你日常使用的聊天应用直接调用(WhatsApp、Telegram、Discord、Slack、Teams 等),让 AI 助手“跟着你走”。

    为什么改名:从 Clawd / Moltbot 到 OpenClaw

    团队经历了多次命名迭代:

    Clawd:好记但涉及商标/法务问题,被建议更换
    Moltbot:寓意“蜕壳成长”,但不够顺口
    OpenClaw:已完成商标检索、域名与迁移准备,强调两点:
    Open:开源、开放、社区驱动
    Claw:延续“龙虾”项目起源与文化

    OpenClaw 是什么:你的助手,你的规则

    核心主张很直接:Your assistant. Your machine. Your rules.
    不同于把数据放在第三方服务器上的 SaaS 助手,OpenClaw 允许你把系统跑在本地电脑、家用服务器或 VPS 上:基础设施你掌控、密钥你掌控、数据也由你掌控

    本次发布更新亮点

    随更名一起上线的更新包括:

    新渠道:新增 Twitch、Google Chat 插件
    模型支持:新增 KIMI K2.5、Xiaomi MiMo-V2-Flash
    Web Chat:支持像聊天软件一样发送图片
    安全加固:累计 34 个与安全相关的提交,并发布可机器验证的安全模型;同时提醒 prompt injection 仍是行业难题,建议参考安全最佳实践

    接下来:安全优先 + 维护体系建设

    团队表示下一阶段会继续把安全作为最高优先级,同时提升网关稳定性、体验打磨,并扩展更多模型与提供商支持。由于项目增长迅猛,也在引入更多维护者并建立流程,鼓励社区参与贡献或赞助维护工作。

    原链接:https://openclaw.ai/blog/introducing-openclaw

    #开源 #AI代理 #隐私安全 #自托管 #聊天机器人 Introducing OpenClaw - OpenClaw Blog

  7. 以“推理速度”交付:AI 编程把瓶颈从写代码变成了等模型这篇文章的核心观点很直接:AI 编程代理的能力跃迁后,作者交付软件的速度越来越不取决于“敲代码”,而更受限于两件事——模型推理时间(inference time)和少数真正需要深度思考的设计决策

    以“推理速度”交付:AI 编程把瓶颈从写代码变成了等模型

    这篇文章的核心观点很直接:AI 编程代理的能力跃迁后,作者交付软件的速度越来越不取决于“敲代码”,而更受限于两件事——模型推理时间(inference time)和少数真正需要深度思考的设计决策。

    作者回顾了今年的变化:从最初“有些提示能一次跑通就很惊喜”,到现在“默认就该一次跑通”。在这种前提下,他甚至不再逐行读代码,而是看执行/修改流,关注系统结构是否合理、关键组件在哪里、整体是否按预期运转。

    文章也给了不少可复用的工作方法:

    先从 CLI 做起:任何产品先做命令行版本,方便代理直接运行验证,形成闭环;核心逻辑稳了再上 UI(比如扩展、App)。
    关键决策是生态与依赖:语言/框架/依赖选对了,代理更容易一次完成;作者常用 TypeScript(Web)、Go(CLI)、Swift(macOS/iOS)。
    更偏向“对话式协作”,而不是复杂流程:先和模型聊清楚、让它探索代码、共创方案,满意后再让它开干;他认为“Plan mode”更像旧时代不得已的手段。
    对比 codex 与 Opus:codex 常会先长时间读代码再动手,虽然更慢但更稳,尤其适合大型功能和重构;Opus 更“急”,适合小改动但更容易漏上下文。
    迭代式构建,不依赖回滚:不喜欢 checkpoint/频繁 revert,更多是让模型继续改、继续朝更好的方向“绕山而上”。
    自动化与多项目并行:同时推进多个项目,用队列把想法排进去;瓶颈往往是人而不是编排系统。
    配置思路:提高工具输出 token 上限、合理设置自动压缩阈值,让模型能一次读更多文件;作者强调新压缩机制更可靠,甚至像一次“复查”。

    如果用一句话总结:当“写代码”越来越像可并行外包给代理的体力活,工程师的价值更集中在选型、架构、数据流、约束定义与验收标准上;而真正影响交付速度的,往往是推理等待时间和你是否想清楚要做什么。

    原链接:https://steipete.me/posts/2025/shipping-at-inference-speed
    #AI编程 #Codex #开发工作流 #效率工具 #软件工程 Shipping at Inference-Speed | Peter Steinberger

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

    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 基建mem059% 份额领跑(按 PyPI + npm 月下载量口径)。
    向量数据库:没有绝对赢家;Weaviate 约 25%,其余多家在 10–25% 之间拉锯。
    AI 规则文件CLAUDE.md 使用率 67%;不少团队多格式并存,且 17% 的仓库三种格式都用
    AI SDK 增长:Anthropic SDK 以 43M 下载领先(约 8 倍增长);Pydantic AI 增长 3.7×6M
    LLMOps:LiteLLM 月下载量增长 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工具链 #模型评测 #软件工程趋势 Get the State of AI Coding Report | Greptile

  9. Bloom:自动化生成“行为评估”的开源框架前沿模型的对齐研究离不开高质量的行为评估,但传统评估往往开发周期长、容易“过时”(被训练数据污染或被能力提升绕过)

    Bloom:自动化生成“行为评估”的开源框架

    前沿模型的对齐研究离不开高质量的行为评估,但传统评估往往开发周期长、容易“过时”(被训练数据污染或被能力提升绕过)。Anthropic 发布了 Bloom:一个开源的“代理式”评估生成框架,用更快、更可扩展的方式衡量模型是否出现特定不对齐行为。

    Bloom 的核心思路是:研究者只需定义要测的行为(并可提供少量示例与配置),Bloom 就能自动生成大量情境并运行对话,最后给出该行为在不同模型上的出现频率与严重程度。官方结果显示,Bloom 的评分与人工标注有较强一致性,也能把“正常模型”和被刻意设计成异常行为的“模型个体”区分开。

    Bloom 怎么做评估(四阶段流水线)

    理解(Understanding):分析研究者的行为描述与示例,明确“要测什么、为什么测”。
    构思(Ideation):自动生成一批用于诱发目标行为的评估场景(含系统提示、用户设定、环境等)。
    执行(Rollout):并行跑场景,对话中还会模拟用户与工具响应,以更真实地触发目标行为。
    判定(Judgment):评审模型为每段对话打分,并输出套件级总结指标(如诱发率、平均行为强度)。

    与固定题库不同,Bloom 每次运行可生成不同场景,但通过“seed 配置”保持可复现;研究者还能调节模型选择、对话长度、是否使用工具、场景多样性,以及增加如“真实感”“诱发难度”等副指标。

    已发布的基准与一个案例

    Anthropic 同时发布了对 16 个模型的基准结果,覆盖四类对齐相关行为:

    • 迎合性妄想(delusional sycophancy)
    • 受指令驱动的长程破坏(instructed long-horizon sabotage)
    • 自我保存(self-preservation)
    • 自我偏好偏差(self-preferential bias)

    在“自我偏好偏差”案例中,Bloom 复现了系统卡里的模型排序,并进一步发现:在某些模型上,提高推理强度会降低偏差(更多体现为识别利益冲突后拒绝自评)。

    开源地址与技术细节见原文与报告:
    https://www.anthropic.com/research/bloom

    #AI安全 #对齐研究 #模型评估 #开源工具 #大模型 Introducing Bloom: an open source tool for automated behavioral evaluations

  10. Agent Skills:给 AI Agent “装上技能包”Agent Skills 是一种开放格式:把一套可复用的指令、脚本与资源打包成「技能」,让智能体在需要时按需加载,从而更准确、更高效地完成真实工作

    Agent Skills:给 AI Agent “装上技能包”

    Agent Skills 是一种开放格式:把一套可复用的指令、脚本与资源打包成「技能」,让智能体在需要时按需加载,从而更准确、更高效地完成真实工作。

    为什么需要它?

    • 智能体能力越来越强,但常缺少上下文与流程知识;技能把这些程序化经验与团队/组织知识变成可携带、可版本管理的包
    • 对作者:一次构建,多处部署,跨多种智能体产品复用
    • 对企业与团队:把组织最佳实践沉淀为可审计、可迭代的工作流

    它能带来什么?

    领域专长:把法律审阅、数据分析等专业流程封装成可复用指南
    新能力扩展:例如自动做演示文稿、搭建 MCP Server、分析数据集等
    可重复的工作流:多步骤任务标准化,稳定且可追踪
    互操作性:同一技能可在不同“支持技能”的工具/产品间通用

    生态与开放性
    该格式最初由 Anthropic 提出并以开放标准发布,已被多种 AI 开发工具与产品支持,并在 GitHub 上开放协作。

    上手入口

    • 了解技能是什么、格式规范、如何集成、示例技能与参考库(校验与生成 prompt XML)

    原链接:https://agentskills.io/home
    #AI代理 #开放标准 #工作流 #知识沉淀 #开发者工具 Agent Skills Overview - Agent Skills

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

    如何让 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 - spences10/claude-skills-cli: 🤖 CLI for creating Claude Agent Skills with progressive disclosure validation. Built for…

1px