面条的草稿箱

无原创，纯转发

Search: #AI工具链

  1. 面条的草稿箱

    Earendil 的 Pi 终于拥抱了 MCP：一次"真香"背后的思考Earendil 团队曾在官网和播客中多次公开表态"不支持 MCP"，但最新版本的 Pi 却将 MCP 纳入了核心功能

    Earendil 的 Pi 终于拥抱了 MCP：一次"真香"背后的思考

    Earendil 团队曾在官网和播客中多次公开表态"不支持 MCP"，但最新版本的 Pi 却将 MCP 纳入了核心功能。这不是打脸，而是一次深思熟虑的转变。

    为什么改变了？

    团队给出了三个理由：

    1. MCP 本身在进化。 过去一年，MCP 协议有了显著改进，今天的 MCP 已非昔日可比。
    2. 技术上的协同效应。 将 MCP 引入核心所需的架构改造（如沙箱解释器），同样让 Jev 等其他功能在 Pi 中运行得更顺畅——一举多得。
    3. 主动参与比旁观更好。 与其站在场外批评 MCP 生态中的问题，不如亲自下场，推动它在小型 harness 中更好地工作。

    仍然存在的问题

    MCP 最大的痛点依然是可组合性差——许多 MCP 服务端仍为"把工具一股脑塞进上下文"的模式而设计，返回纯文本而非结构化数据。Earendil 认为 MCP 应该更接近 OpenAPI 的思路：工具返回结构化数据，并通过文档和描述实现智能发现。

    Codemode：关键拼图

    Pi 引入了一个名为 Codemode 的机制——一个运行在 harness 侧的 JavaScript 沙箱，让 AI 能够用代码灵活编排和组合工具调用。配置 MCP 后 Codemode 会自动加载。文章展示了一个令人印象深刻的示例：通过 Codemode 同时调用 Linear MCP 和 Jev 模型，自动分析 issue tracker 中 167 个问题的情绪倾向，整个过程不浪费任何上下文窗口。

    这篇文章传递的核心信息是：技术判断应随环境演变而更新，曾经说"不"并不意味着永远说"不"。

    🔗 https://earendil.com/posts/you-said-no-mcp/

    #MCP #Codemode #Pi #Earendil #AI工具链
    Earendil
    “You Said No MCP!” | Earendil
    “You Said No MCP!” | Earendil
    Pi now supports MCP. Why we changed our minds, what changed in MCP and in Pi, and what Codemode is.

    MCPCodemodePiEarendilAI工具链

  2. 面条的草稿箱

    代码不再是瓶颈：Anthropic 发布的「AI 原生软件工程（SDLC）实战手册」随着 Claude Code 等 Agent 编码工具的普及，编写代码的时间被大幅压缩至数小时

    代码不再是瓶颈：Anthropic 发布的「AI 原生软件工程（SDLC）实战手册」

    随着 Claude Code 等 Agent 编码工具的普及，编写代码的时间被大幅压缩至数小时。然而，传统的软件开发生命周期（SDLC）仍按“人类速度”运行——繁复的需求对齐、人工逐行 Code Review 和层层审批，反而成为了团队新的生产力瓶颈。

    Anthropic 官方近期梳理了一套完整的 AI-Native SDLC 转型框架，将传统的线性研发流程重构为以 Markdown 产物驱动的自治闭环：

    ---

    🔄 六大阶段的关键演进

    1. 规划（Plan）｜意图即代码
    • 告别漫长繁琐的 PRD 编写，业务人员通过与 Claude 头脑风暴直接生成 intent.md（意图文件）。
    • 机器可读、人类可审，提交至 Git 即可直接驱动下一阶段。

    2. 设计（Design）｜需求与设计合二为一
    • 结合团队沉淀的规范库（Skills），Claude 基于 intent.md 快速产出 spec.md。
    • 安全、合规与 UX 约束在生成设计时即刻生效，而非等到几周后的评审会议才被发现。

    3. 构建（Build）｜计划驱动与组织记忆
    • Plan Mode：必须先生成并确认 plan.md 才能落代码，杜绝 Agent 盲目编码。
    • 团队记忆库：通过 CLAUDE.md 和 Skills 固化团队规约；借助 Hooks 建立不可逾越的确定性防线。
    • 并行作战：配合 Git Worktree 和专有子 Agent（Subagents），单名工程师可同时调度多个任务。

    4. 测试（Test）｜让 AI 自查自纠
    • 反馈闭环：为 Agent 配备自动化测试与 UI 视觉对比工具，要求“跑通测试才算 Done”，并禁止 AI 擅自修改测试用例以掩盖 Bug。
    • Continuous Evals：在 CI 中引入 Agent 评估套件，像测代码一样回归测试提示词与配置。

    5. 部署（Deploy）｜双向审查与严格卡点
    • AI 参与 PR 自动化多维度评审，并支持直接根据 @claude 评论修复代码；人类工程师重点聚焦于“业务意图”与“系统风险”。
    • 生产门禁：AI 的自主权终止于生产部署关卡，核心发布动作仍由 Hooks 拦截并等待人工最终授权。

    6. 运维（Maintain）｜自主闭环的起点
    • 当监控指标（如 CI 失败率、5xx 错误）出现统计学异常时，自动化脚本唤醒 Claude 进行故障诊断并生成修复 PR 或新的 intent.md。
    • 结合即时通讯工具（Claude Tag），实现告警自动排查、知识沉淀与自主闭环。

    ---

    核心总结：AI 原生 SDLC 的本质，是把研发流程从“人写代码、人走流程”，升级为“AI 负责闭环执行、人类把控关键治理与评判”的全新协作范式。

    🔗 原文链接：https://claude.com/blog/the-ai-native-sdlc-playbook

    #AI开发 #SDLC #ClaudeCode #软件工程 #人工智能
    Claude
    The AI-native SDLC playbook
    The AI-native SDLC playbook
    Anthropic's stage-by-stage playbook for the AI-native SDLC: how teams plan, design, build, test, deploy, and maintain software with Claude.

    AI开发SDLCClaudeCode软件工程人工智能

  3. 面条的草稿箱

    从“生成报告”到“解决复杂任务”：Apodex 1.1 正式发布传统的 AI 深度搜索往往以生成一份结构化报告为终点，但科研、金融和法律等领域的真实工作，通常在写完报告后才刚开始——清洗脏数据、选择方法、编写运行代码、根据中间结果调整方案，并保证每项结论都能经得起溯源检验

    从“生成报告”到“解决复杂任务”：Apodex 1.1 正式发布

    传统的 AI 深度搜索往往以生成一份结构化报告为终点，但科研、金融和法律等领域的真实工作，通常在写完报告后才刚开始——清洗脏数据、选择方法、编写运行代码、根据中间结果调整方案，并保证每项结论都能经得起溯源检验。

    针对这一痛点，Apodex 正式推出了 Apodex 1.1，旨在将 AI 从单纯的“问答工具”升级为能够处理长周期、多阶段复杂任务的在线工作台。

    ---

    核心亮点一览

    1. 真实环境下的长链路执行

    不再回避复杂的专业格式（CSV、PDF、分子结构等）。模型在真实的文件与代码环境中运行，自主处理异常并完成端到端的数据分析与交付。

    2. 支持运行中随时介入（Human-in-the-loop）

    复杂任务难免需要中途调整。Apodex 1.1 允许用户在任务执行的任意阶段添加新需求或新数据，系统会自动保留有效的中间产物并重新规划后续路径，无需从头再来。

    3. 任务分解与执行状态全透明

    拒绝黑盒等待。基于底层 AgentOS，系统会实时展示当前的执行计划、完成步骤、生成的产物与异常重试情况，让长耗时任务清晰可控。

    4. 自主异步多智能体团队（Agent Team）

    在 Deep Discover 模式下，模型会自主将复杂任务拆解并分发给多个子智能体并行探索。中间结果实时回流至主任务，大幅缩短复杂探索的等待耗时。

    5. 关键结论独立审查（Statement Review）

    将“内容生成”与“结论审核”解耦。针对数据推论、文献引用和计算结果进行独立的交叉校验与证据链追溯，显著降低幻觉风险。

    6. 开源支持与端侧部署

    除了网页端完整版，团队还推出了可本地部署的 35B Apodex 1.1 Mini，并开源了开箱即用的终端智能体框架 FrontierAgent（支持 macOS / Linux 单命令运行）。

    ---

    🔗 原文链接：https://www.apodex.com/blog/apodex-1.1-scaling-agentic-intelligence-for-complex-work

    #人工智能 #AI智能体 #Apodex #大语言模型 #深度研究
    Apodex
    Apodex 1.1: Scaling Agentic Intelligence for Complex Work - Apodex | AI for Discovery
    Apodex 1.1: Scaling Agentic Intelligence for Complex Work - Apodex | AI for Discovery
    The hardest problems have no existing answer. Apodex does the deep research to find one, and checks every step so you can trust the result.

    人工智能AI智能体Apodex大语言模型深度研究

  4. 面条的草稿箱

    开源模型实现端到端自我提升：Ornith-1.5 正式发布Ornith 正式推出了 Ornith-1.5 模型家族，将此前的“自我脚手架（Self-Scaffolding）”机制拓展为完整的端到端自我进化闭环

    开源模型实现端到端自我提升：Ornith-1.5 正式发布

    Ornith 正式推出了 Ornith-1.5 模型家族，将此前的“自我脚手架（Self-Scaffolding）”机制拓展为完整的端到端自我进化闭环。模型不再单纯依赖人工标注数据，而是能够自主生成新任务、构建评估脚手架，并通过强化学习（GRPO）持续进行自我迭代与能力突破。

    ---

    核心技术亮点：自我驱动的学习闭环

    在每个训练周期中，Ornith-1.5 协同优化三个关键环节：

    1. 自主出题（Task Generation）：根据历史解决记录，生成处于能力边界前沿、有效且具有多样性的新挑战。
    2. 构建脚手架（Scaffold Construction）：自主设计解题策略、工具链和评估环境，并加入防作弊与对齐奖励机制。
    3. 策略优化（GRPO RL）：通过解答方案的反馈，联合优化出题质量、脚手架有效性与模型解题策略，实现能力螺旋上升。

    ---

    三种规格模型与性能表现

    Ornith-1.5 覆盖了大中小三种参数规格，在代码生成、复杂推理与 Agent 任务上均有亮眼表现：

    • Ornith-1.5-397B（旗舰 MoE）：
    在 Terminal-Bench 2.1 取得 86.1 分，DeepSWE 取得 56.0 分，整体性能比肩 Claude Opus 4.8，并全面超越同体量的开源模型（如 DeepSeek-V4-Flash 与 GLM-5.2）。

    • Ornith-1.5-35B（轻量 MoE，单 Token 仅激活 3B）：
    在 Agent 编程和代码基准（如 SWE-Bench Verified）上大幅领先同量级对手，甚至显著超越了多款 30B 级别的稠密模型。

    • Ornith-1.5-9B（端侧 Dense）：
    专为边缘设备优化，提供手机端量化版本（支持 iPhone 与 Android），在紧凑体积下展现出越级打怪的推理与代码能力。

    ---

    🔗 阅读原文：https://ornith.ai/ornith_1_5.html

    #人工智能 #开源大模型 #强化学习 #AI编程
    Ornith
    Ornith-1.5: From Self-Scaffolding to Self-Improvement
    Ornith-1.5: From Self-Scaffolding to Self-Improvement
    Introducing Ornith-1.5, an open-source model family that extends self-scaffolding into an end-to-end self-improvement loop.

    人工智能开源大模型强化学习AI编程

  5. 面条的草稿箱

    告别合盖中断：为 AI 编程智能体打造的专属后台运行环境 Herdr在使用 Claude Code、Codex 等 AI 编程助手时，许多人经常遇到两个痛点：一旦合上笔记本电脑或断开连接任务就会中断；同时跑多个 Agent 时，很难及时发现哪一个正在等待输入确认

    告别合盖中断：为 AI 编程智能体打造的专属后台运行环境 Herdr

    在使用 Claude Code、Codex 等 AI 编程助手时，许多人经常遇到两个痛点：一旦合上笔记本电脑或断开连接任务就会中断；同时跑多个 Agent 时，很难及时发现哪一个正在等待输入确认。

    Herdr 正是为解决这些问题而生的智能体运行时（Runtime）。它作为一个后台服务运行，接管终端会话，让你的 AI 智能体可以全天候自主工作。

    核心特性

    • 后台常驻，合盖不掉线：终端直接运行在 Herdr 后台服务中，即使关闭电脑屏幕、网络断开甚至系统重启，会话与分屏布局都能完整保留并继续执行。
    • 状态感知，告别逐屏排查：自动识别每个窗格中 Agent 的实时状态（工作中 / 等待输入 / 空闲），当某个 Agent 需要人工确认时一目了然，无需在多个终端间来回切换。
    • Agent 原生协作：提供统一的 CLI 与 Socket API，不同的 Agent 可以自主分屏、相互唤起并协同处理复杂任务。
    • 开箱即用，无缝兼容：无需改变原有的使用习惯，开箱支持 Claude Code、Cursor、Codex、Copilot 等 20 多种主流 Agent CLI，单二进制文件支持 macOS、Linux 和 Windows。

    安装只需一行命令即可接入现有的开发流，让 AI 智能体真正具备独立持续干活的能力。

    原链接：https://herdr.dev/

    #AI编程 #Agent运行时 #开发者工具 #ClaudeCode #终端工具
    Herdr
    Herdr: made for your agents, remade by them
    Herdr: made for your agents, remade by them
    Herdr is a native app for running coding agents. Your agent can change any part of it, from the sidebar to whole new panels. Close it and your agents keep working.

    AI编程Agent运行时开发者工具ClaudeCode终端工具

  6. 面条的草稿箱

    超越 Git：Zed 推出专为 AI 协作打造的版本控制系统 DeltaDB代码的诞生正逐渐从“提交（Commit）”转向“对话（Conversation）”

    超越 Git：Zed 推出专为 AI 协作打造的版本控制系统 DeltaDB

    代码的诞生正逐渐从“提交（Commit）”转向“对话（Conversation）”。传统的 Git 机制已无法满足人与人、人与 AI 代理（Agent）之间的高频实时协作。为此，现代编辑器 Zed 宣布推出全新的版本控制系统——DeltaDB。

    与通过 Commit 捕获代码快照的 Git 不同，DeltaDB 的核心理念是将开发过程中的每一次微小操作（Delta）都记录下来。它的主要特性包括：

    • 记录每一次操作：不仅是 Commit，DeltaDB 会捕获每一次编辑并赋予其唯一身份，支持随时回溯任意时刻的代码状态，并允许多人与 AI 共同实时修改同一文件。
    • 代码与对话无缝绑定：版本控制不再只针对代码，还包括促成这些代码的对话。你可以从任意一行代码追溯到生成它的讨论上下文，AI 也可以借此理解代码的设计初衷。
    • 消除繁琐的协作仪式：无需等待 Commit、Push 和 Pull Request。团队成员可以随时加入正在进行的工作区，直接与 AI 或同事交流，让沟通在编写代码的瞬间发生。

    DeltaDB 旨在让 Git 和 CI 回归它们最擅长的安全检查与发布功能，而把日常协作留给更实时的工具。该系统预计在几周内开启 Beta 测试。

    原链接：https://zed.dev/blog/introducing-deltadb

    #DeltaDB #Zed #版本控制 #协同开发 #AI时代
    zed.dev
    Software Is Made Between Commits
    Software Is Made Between Commits
    From the Zed Blog: Agents turned the conversation into the real source of our software. DeltaDB is the version control built for it.

    DeltaDBZed版本控制协同开发AI时代

  7. 面条的草稿箱

    为什么 MCP 服务器难以部署在 Serverless 架构上？随着大模型生态的发展，MCP（Model Context Protocol，模型上下文协议）成为了连接 AI 助手与外部工具的热门选择

    为什么 MCP 服务器难以部署在 Serverless 架构上？

    随着大模型生态的发展，MCP（Model Context Protocol，模型上下文协议）成为了连接 AI 助手与外部工具的热门选择。然而，在实际部署中，开发者很快就会遇到一个棘手的架构问题：MCP 服务器默认是有状态的（Stateful）。

    1. 单客户端的尴尬限制

    在最基础的 HTTP/SSE（Server-Sent Events）实现中，服务器通常会将连接通道（Transport）保存在内存变量中。这意味着，一旦有第二个客户端尝试连接，前一个客户端的连接就会被迫中断。

    2. 内存常驻与 Serverless 的冲突

    即便我们通过引入 ID 标识来管理多个连接，依然无法解决核心问题——连接状态依然保存在服务器的内存中。

    这种“有状态”的特性，直接把 Serverless 部署方案（如 Vercel、AWS Lambda）排除在外。因为 Serverless 函数在请求结束后会随时销毁实例，导致内存中的连接状态丢失。要维持连接，你只能选择 VPS 等需要持续运行的服务器，这增加了运维成本。

    3. 如何实现无状态化？

    目前最可行的解决方案是将状态外置。我们可以将 Transport 信息存储到像 Redis 这样的键值数据库中。

    通过将状态抽离到 Redis，MCP 服务器成功实现了无状态化（Stateless），从而能够自由地部署到 Vercel 等 Serverless 平台上。Vercel 官方开源的 mcp-on-vercel 项目正是采用了这种架构设计。

    思考

    虽然通过 Redis 解决了部署问题，但这无疑增加了系统的复杂度。我们不禁会想：在协议设计之初，是否应该让客户端去承担更多的状态维护，从而避免让服务端背上数据库的包袱？

    ---

    原文链接：https://www.aihero.dev/the-problem-with-mcp-stateful-server

    #MCP #Serverless #系统架构 #Redis #AI开发
    www.aihero.dev
    The Problem With MCP: Stateful Servers
    The Problem With MCP: Stateful Servers
    Discover how to deploy MCP servers statelessly using Redis, enabling compatibility with serverless platforms like Vercel and AWS Lambda.

    MCPServerless系统架构RedisAI开发

  8. 面条的草稿箱

    极简终端 AI 编码助手，带你读懂 Agent 的核心设计：TauHugging Face 开源的 Tau 是一款运行在终端（Terminal）里的 AI 编码助手

    极简终端 AI 编码助手，带你读懂 Agent 的核心设计：Tau

    Hugging Face 开源的 Tau 是一款运行在终端（Terminal）里的 AI 编码助手。只需输入简单的需求，它就能帮你读取文件、修改代码、执行 Bash 命令并记录会话历史。

    不同于庞大复杂的商业项目，Tau 的核心定位是一个教学型项目。它的代码极其精简、层级分明，非常适合开发者用来理解“AI 编码 Agent 是如何从零构建的”。

    核心特性：

    • 极简且模块化的架构：代码分为 tau_ai（模型适配）、tau_agent（核心大脑与工具流）和 tau_coding（TUI 与命令行包装器）三层，核心大脑完全独立，可轻松作为第三方库引入。
    • 终端交互式操作：内置基于 Textual 的命令行 TUI 界面，支持 /login 登录、模型切换以及流式输出。
    • 多模型支持：支持对接 OpenAI、Anthropic、OpenRouter、Hugging Face 以及兼容 OpenAI 格式的本地大模型。
    • 持久化会话管理：通过 JSONL 格式安全存储每一次会话，支持中断恢复与分支操作。

    如果你想拥有一个轻量级的命令行开发助手，或是想动手写一个自己的 AI Agent，Tau 是一个绝佳的起点。

    项目链接：https://github.com/huggingface/tau

    #AI #Agent #Python #开源项目 #编程助手
    GitHub
    GitHub - huggingface/tau: A Python port of Pi’s minimalist coding agent.
    GitHub - huggingface/tau: A Python port of Pi’s minimalist coding agent.
    A Python port of Pi’s minimalist coding agent. Contribute to huggingface/tau development by creating an account on GitHub.

    AIAgentPython开源项目编程助手

  9. 面条的草稿箱

    用 Cloudflare Workers 打造专属 AI 邮件与日历中心：开源项目 agentic-cal如果你正在寻找一种不依赖复杂 API 就能聚合多平台日程、并用 AI 辅助处理邮件的方案，这个开源项目非常值得关注

    用 Cloudflare Workers 打造专属 AI 邮件与日历中心：开源项目 agentic-cal

    如果你正在寻找一种不依赖复杂 API 就能聚合多平台日程、并用 AI 辅助处理邮件的方案，这个开源项目非常值得关注。

    agentic-cal 是一个部署在 Cloudflare Workers 上的自托管邮件与日历中心（基于 cloudflare/agentic-inbox 分支开发）。它拥有以下核心功能：

    • 多平台日历聚合（只读）： 无需 OAuth 或第三方 API，直接通过 Proton、Outlook 和 iCloud 的公开 ICS 链接，自动将多平台日程融合成一个统一的“忙/闲”模型。
    • 基于邮件的日程预定（写入）： 采用标准的邮件邀请机制（iMIP 协议）。当需要锁定时间时，系统会向你的账号发送一封标准的会议邀请邮件，你只需在常用客户端点击“接受”，即可完成日程写入。
    • 内置 AI 助手与 MCP 服务： 集成了 Workers AI，不仅能智能起草邮件回复，还会在预约日程前自动检查你的空闲时间。项目还向外暴露了 20 个 MCP（Model Context Protocol）工具，方便你将日程和邮件功能接入 Claude Code 等外部 AI 智能体。
    • 独立的自托管邮箱： 配合 Cloudflare Email Routing 和 Durable Objects (SQLite)，提供完整的邮件收发、富文本编辑、搜索及附件管理功能。

    无论是想要一个无广告、完全掌控的个人邮箱，还是希望用 AI 自动化打理自己的日常排期，agentic-cal 都提供了一个极其优雅的轻量化解决方案。

    https://github.com/talalakkari/agentic-cal

    #Cloudflare #AI助手 #开源项目 #日程管理 #MCP
    GitHub
    GitHub - talalakkari/agentic-cal: Agentic email + calendar hub on Cloudflare Workers. One Worker owns your domain's email surface:…
    GitHub - talalakkari/agentic-cal: Agentic email + calendar hub on Cloudflare Workers. One Worker owns your domain's email surface:…
    Agentic email + calendar hub on Cloudflare Workers. One Worker owns your domain's email surface: a full self-hosted email client with an AI agent, plus a unified calendar that aggregates Pr...

    CloudflareAI助手开源项目日程管理MCP

  10. 面条的草稿箱

    BRAIN.md：为项目构建 AI 友好的决策记忆库在日常开发中，我们常用 README.md 告诉人类如何上手，用 AGENTS.md 指导 AI 怎么在项目中编写代码

    BRAIN.md：为项目构建 AI 友好的决策记忆库

    在日常开发中，我们常用 README.md 告诉人类如何上手，用 AGENTS.md 指导 AI 怎么在项目中编写代码。但项目的核心决策——比如“为什么选择 Postgres 而不是 MongoDB”、“架构设计的底层逻辑是什么”——应该记在哪里？

    BRAIN.md 提出了一个全新的开源标准，旨在项目中建立一个专为 AI 和人类准备的决策记忆库。它不是零散的笔记，而是经过整理、权威的“决策级知识”。

    核心特性

    • 无外部依赖：无需运行任何后台服务或 MCP 服务器，仅基于纯 Markdown 文件约定和一个零依赖的本地 CLI 工具。
    • Git 原生支持：所有知识和决策记录在项目根目录下的 brain/ 文件夹中，随代码一起进行版本控制。
    • 结构化页面设计：核心页面包含 compiled_truth（当前权威结论）和 timeline（追加式的历史证据链）。AI 在读取时能瞬间掌握当前现状，并在需要时追溯历史决策过程。
    • 智能体通用：目前已原生支持 Claude Code 和 Codex，通过简单的全局安装，即可让你的 AI 助手在开发时直接读取项目的“大脑”。

    通过 BRAIN.md，AI 编程助手不仅是在盲目地写代码，而是能够真正理解项目背后的架构决策与技术取舍，从而产出更具上下文合理性的代码。

    原链接：https://projectbrain.md/

    #软件工程 #AI工具 #开发规范 #知识库 #项目管理
    BRAIN.md
    BRAIN.md — A persistent memory layer for your projects
    BRAIN.md — A persistent memory layer for your projects
    An open, agent-agnostic standard for capturing a project's durable knowledge as plain Markdown — read and written through one small CLI. It lives in your repo and travels across agents, machines, and models.

    软件工程AI工具开发规范知识库项目管理

  11. 面条的草稿箱

    AI 编程防翻车：MDN 正式推出 MCP 服务，让 AI 获取最新 Web 规范在大模型辅助编程的时代，你是否也遇到过 AI 给出过时 Web API，或错误浏览器兼容性数据的情况？为了解决这一痛点，MDN 官方宣布推出了 MDN MCP（Model Context Protocol）服务

    AI 编程防翻车：MDN 正式推出 MCP 服务，让 AI 获取最新 Web 规范

    在大模型辅助编程的时代，你是否也遇到过 AI 给出过时 Web API，或错误浏览器兼容性数据的情况？

    为了解决这一痛点，MDN 官方宣布推出了 MDN MCP（Model Context Protocol）服务。

    什么是 MDN MCP？

    MCP 是一种开放标准，允许 AI 工具安全地连接到外部数据源。通过 MDN MCP，你可以将最新的 MDN 官方文档和浏览器兼容性数据（BCD）直接接入到你常用的 AI 编辑器（如 Cursor、VS Code、Zed）或命令行工具（如 Claude Code）中。

    它能带来什么改变？

    • 消除 AI 幻觉与信息滞后：避免 AI 因“知识库截止时间”而给出过时信息。例如，它能准确告知你 Firefox 151 已支持 Web Serial API，而未启用 MCP 的 AI 则会根据旧数据坚称“Firefox 不支持”。
    • 响应速度翻倍：测试表明，启用 MCP 后，AI 响应速度提升了约一倍。AI 无需再耗时爬取和解析网页，而是直接通过协议获取结构化数据。
    • 快速配置：以 Claude Code 为例，只需运行一行命令即可快速集成：
    claude mcp add --transport http mdn https://mcp.mdn.mozilla.net/

    目前该服务已处于实验阶段，感兴趣的开发者不妨立即配置，让你的 AI 助手掌握最权威的 Web 开发知识库。

    原链接：https://developer.mozilla.org/en-US/blog/introducing-mdn-mcp-server/

    #AI编程 #MDN #MCP #前端开发 #大语言模型
    MDN Web Docs
    Introducing the MDN MCP server | MDN Blog
    MDN's MCP server brings MDN's documentation and browser compatibility data directly into your editor or IDE, giving your LLM or coding agent access to accurate, up-to-date web platform information.

    AI编程MDNMCP前端开发大语言模型

  12. 面条的草稿箱

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

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

  13. 面条的草稿箱

    让 AI 掌握顶级设计：TypeUI 风格库还在烦恼 AI 生成的网页风格太普通？TypeUI 为 Claude、Cursor、Gemini 等 AI 工具提供了一套精选的“设计技能（Design Skills）”库，让你的 AI 助手瞬间化身顶级设计师

    让 AI 掌握顶级设计：TypeUI 风格库

    还在烦恼 AI 生成的网页风格太普通？TypeUI 为 Claude、Cursor、Gemini 等 AI 工具提供了一套精选的“设计技能（Design Skills）”库，让你的 AI 助手瞬间化身顶级设计师。

    核心功能：

    • 多样化风格： 涵盖 Bento（盒式）、Neumorphism（新态设计）、Glassmorphism（毛玻璃）、Neobrutalism（新野兽派）等多种流行审美。
    • 即插即用： 提供优化的 skill.md 文件，你可以通过 CLI 命令（如 npx typeui.sh pull bento）直接引入项目，或手动复制到提示词中。
    • 完美适配： 专门针对 Agentic AI 工具进行了优化，确保 AI 生成的代码能精准还原特定的视觉风格。

    使用场景：
    当你使用 AI 开发网页或应用时，只需喂入这些预设的“技能文件”，AI 就能跳出默认的 Bootstrap 或 Tailwind 风格，构建出极具辨识度的视觉界面。

    原文链接：https://www.typeui.sh/design-skills

    #AI设计 #前端开发 #TypeUI #UI设计 #AI工具

    AI设计前端开发TypeUIUI设计AI工具

  14. 面条的草稿箱

    AI 时代怎么招工程师：Augment 的「AI-native」人才标准当 AI agent 能写出大部分代码后，工程师的价值开始上移：不再以“写得快、写得多”为核心，而是以判断力、系统设计与协同能力决定产出质量

    AI 时代怎么招工程师：Augment 的「AI-native」人才标准

    当 AI agent 能写出大部分代码后，工程师的价值开始上移：不再以“写得快、写得多”为核心，而是以判断力、系统设计与协同能力决定产出质量。

    Augment 重新梳理了面向 AI-native（与 AI 共同工作）团队的招聘标准，核心变化可以概括为一句话：人从“作者”变成“架构师与编辑”——定义意图、做取舍、设护栏、把好质量关。

    工程师工作重心的迁移

    • 传统工程：写代码、实现方案、解决问题、看个人产出
    • AI-native 工程：明确意图与权衡、编排 agent、选择正确问题、看系统级结果

    他们认为最重要的 6 个能力维度

    1. 产品与结果品味（Product & Outcome Taste）：能否在代码变“更便宜”时，避免做出“最贵的错误”——把方向做错。
    2. 系统与架构判断（System & Architectural Judgment）：代码能跑不难，难的是“能在生产环境长期稳定地跑”。
    3. Agent 杠杆（Agent Leverage）：能否把 AI 变成真实吞吐量：拆解任务、引导偏航、验证结果（agent 很快，但也可能自信地出错）。
    4. 沟通与协作（Communication & Collaboration）：实现更快后，“达成清晰”更关键；要能把意图讲清楚、促成共识。
    5. 主人翁意识与领导力（Ownership & Leadership）：对结果负责而非只做任务；主动清除阻碍交付的障碍。
    6. 学习速度与实验心态（Learning Velocity & Experimental Mindset）：工具三个月就变一轮，持续实验与快速迭代成为工作常态。

    一个显著的信号是：“纯粹的编码能力”不再是最主要的区分项——依然重要，但不再决定上限。

    从理念到招聘：看“可观察信号”

    他们强调，框架必须能落到面试里，转成可评估的行为证据，例如：

    • 能否快速澄清模糊问题、定义清晰目标？
    • 能否提前识别架构风险，而不是上线后救火？
    • 能否有效指挥并验证 AI 生成的工作？

    未来重点招的 4 类画像

    • AI-native 系统工程师：基础设施与架构判断强，保证“地基”稳。
    • AI-native 产品工程师：产品品味与用户理解强，确保“做对事”。
    • AI-native 应用 AI 工程师：懂模型与应用构建，提升 agent 能力与工作流。
    • AI-native 早期工程师（Early Professional）：学习速度优先，快速适应工具与流程变化。

    这套标准也不只用于招聘，还会反向影响绩效、成长与职业发展：如果真正重视判断力、杠杆与学习速度，就应该在各个环节都体现出来。

    原文链接：https://www.augmentcode.com/blog/how-we-hire-ai-native-engineers-now

    #AI招聘 #工程师能力 #AI代理 #架构设计 #学习型组织
    Augmentcode
    How we hire AI-native engineers now: our criteria
    How we hire AI-native engineers now: our criteria
    How do you hire engineers when agents write 99% of the code? We found ourselves asking that question after realizing our hiring process was built for a…

    AI招聘工程师能力AI代理架构设计学习型组织

  15. 面条的草稿箱

    GitHub Agentic Workflows：用自然语言写 GitHub Actions 的“智能工作流”GitHub 开源项目 gh-aw（GitHub Agentic Workflows），主打一个思路：用自然语言 Markdown 编写“代理式（agentic）工作流”，然后直接在 GitHub Actions 里运行，让 AI 代你完成仓库中的重复性任务

    GitHub Agentic Workflows：用自然语言写 GitHub Actions 的“智能工作流”

    GitHub 开源项目 gh-aw（GitHub Agentic Workflows），主打一个思路：用自然语言 Markdown 编写“代理式（agentic）工作流”，然后直接在 GitHub Actions 里运行，让 AI 代你完成仓库中的重复性任务。

    它提供的核心价值包括：

    • 更低门槛的工作流编写方式：用 Markdown 描述要做什么，而不是从零写复杂的 YAML/脚本
    • 更强调安全的执行模型（Guardrails）：默认只读权限；写入操作需要通过经过清洗的 safe-outputs；并配套多层防护（输入净化、工具白名单、编译期校验、网络隔离、供应链安全等）
    • 完善的文档与上手路径：官方提供 Quick Start 与完整文档，方便快速跑通示例并理解整体机制
    • 生态配套：
    • AWF（Agent Workflow Firewall）：限制与记录代理的网络访问（出站控制）
    • MCP Gateway：统一转发 MCP（Model Context Protocol）服务调用，便于集中管理访问

    适合关注 AI + DevOps、希望把“AI 介入仓库日常操作”做得更可控、更工程化的团队参考与尝试（同时也要保持必要的人类监督）。

    原链接：https://github.com/github/gh-aw

    #GitHubActions #AI自动化 #工作流 #安全工程 #开源项目
    GitHub
    GitHub - github/gh-aw: GitHub Agentic Workflows
    GitHub - github/gh-aw: GitHub Agentic Workflows
    GitHub Agentic Workflows. Contribute to github/gh-aw development by creating an account on GitHub.

    GitHubActionsAI自动化工作流安全工程开源项目

  16. 面条的草稿箱

    Entire：把 AI 编程对话“写进”每一次 Git 提交用 AI 写代码时，最容易丢的不是代码，而是“为什么这么写”的上下文

    Entire：把 AI 编程对话“写进”每一次 Git 提交

    用 AI 写代码时，最容易丢的不是代码，而是“为什么这么写”的上下文。Entire 提供一个思路：在你正常的 git 工作流里，把每次 AI agent 会话自动记录下来，并与对应的 commit 绑定，形成可搜索的历史记录。

    它能做什么？

    • 自动捕获会话：在每次 push 时记录 AI agent 的会话内容，并和提交一起关联。
    • 不改变你的工作方式：通过 CLI 接入现有工具链，尽量减少上下文切换。
    • 支持多种 agent：目前支持 Claude Code、Google Gemini；OpenAI Codex 等集成在路上。
    • 把“意图”留在仓库里：官方强调记录会直接存进 git 历史，不依赖额外托管服务或外部数据库。

    安装方式（官网给出的命令）

    • curl -fsSL https://entire.io/install.sh | bash

    适合希望团队更容易复盘决策、追踪 AI 产出过程、减少重复踩坑的工程项目。

    原链接：http://entire.io/

    #Git #AI编程 #开发工具 #工程效率 #CLI
    Entire
    Entire · The Git forge for agents
    Entire · The Git forge for agents
    Host code and agent sessions together on a fast, distributed Git network. Give your agents the context to understand, collaborate, and ship.

    GitAI编程开发工具工程效率CLI

  17. 面条的草稿箱

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

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

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

  18. 面条的草稿箱

    keep.md：把收藏夹变成「可被 AI 直接读取」的 Markdown APIkeep.md 主打一个简单但实用的思路：把你在各处保存的链接，统一存成 Markdown，并提供 API + Agent 技能，让它们能随时被你的工作流或智能体当作上下文调用

    keep.md：把收藏夹变成「可被 AI 直接读取」的 Markdown API

    keep.md 主打一个简单但实用的思路：把你在各处保存的链接，统一存成 Markdown，并提供 API + Agent 技能，让它们能随时被你的工作流或智能体当作上下文调用。

    它适合这些场景：

    • 你保存了一堆资料链接，希望 AI/Agent 能直接读懂内容并引用
    • 你收藏了文档，想让 Agent 辅助写代码、查用法
    • 你保留了长线程/讨论，希望 Agent 自动整理成摘要或草稿

    工作方式也很直观：你保存链接 → 系统生成 Markdown → 你的 Agent 读取并使用。
    目前提供 Chrome 扩展（页面显示仍在等待 Chrome 商店审核），并支持接入多种工具/平台（如 n8n、Claude SDK、各类 Agent 等）。

    费用信息：免费档包含 50 条链接，付费计划 $10/月起。

    原链接：https://keep.md/

    #书签管理 #Markdown #API #AI工具 #Agent工作流
    Keep
    Keep anything as Markdown for your AI agents
    Keep anything as Markdown for your AI agents
    Save notes, links, images, videos, PDFs, audio, and other useful material as clean Markdown your AI agents can search, read, and update.

    书签管理MarkdownAPIAI工具Agent工作流

  19. 面条的草稿箱

    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代理 #自动化工作流 #云端沙盒 #可观测性 #开发者工具
    www.vm0.ai
    VM0 - Your Trustworthy AI Teammate
    VM0 - Your Trustworthy AI Teammate
    VM0 is an AI agent that connects to 1,400+ tools and does the work. Reports, triage, outreach, research. In Slack or on the web.

    AI代理自动化工作流云端沙盒可观测性开发者工具

  20. 面条的草稿箱

    Agent Trace：为 AI 写的代码建立“可追溯”标准Agent Trace 是一个开放规范，用来记录代码中哪些部分来自 AI、哪些来自人类，并把相关的模型信息、对话链接等“出处”一并纳入版本控制工作流中

    Agent Trace：为 AI 写的代码建立“可追溯”标准

    Agent Trace 是一个开放规范，用来记录代码中哪些部分来自 AI、哪些来自人类，并把相关的模型信息、对话链接等“出处”一并纳入版本控制工作流中。它强调厂商中立，让不同工具都能读写同一套归因数据。

    核心想解决什么

    • 随着 Agent/代码助手产出越来越多代码，团队需要更清楚地知道：哪些改动是 AI 生成、用的是什么模型、对应哪次对话/会话。
    • 这不是法律意义的“所有权”或“版权”判定，而是工程层面的来源记录与可审计性。

    主要目标

    • 互操作性：任何兼容工具都能写入/读取归因记录
    • 细粒度：支持到**文件级、行号范围（line range）**的归因
    • 可扩展：允许各家在不破坏兼容的情况下增加自定义元数据
    • 人和 Agent 都能读懂：尽量不依赖特定 UI 才能理解

    不做什么（边界很明确）

    • 不处理代码法律归属、版权问题
    • 不追踪训练数据来源
    • 不做质量评估（不判断 AI 代码“好或坏”）
    • 不绑定任何界面或产品形态

    规范长什么样（概念速览）

    Agent Trace 的基本单位是 Trace Record（JSON 记录），典型字段包括：

    • version / id / timestamp：规范版本、记录 ID、时间戳
    • vcs：版本控制信息（如 git commit SHA；也支持 jj/hg/svn）
    • tool：生成该记录的工具及版本
    • files：文件列表；每个文件下按 conversation 分组
    • conversations.url：指向产生这段代码的对话链接
    • ranges：该对话贡献的行号范围（可选 content_hash 用于跨移动追踪）
    • metadata：自定义扩展字段（建议用反向域名避免冲突，如 dev.cursor）

    实现与落地

    • 规范本身不规定 traces 存哪：可以是本地文件、git notes、数据库等。
    • 提供了一个参考实现（含存储层、hook 集成），示范如何在文件变更时自动捕获归因信息。

    链接：https://agent-trace.dev/
    #AI编程 #代码归因 #工程规范 #可追溯性 #开发工具
    agent-trace.dev
    Agent Trace
    Agent Trace
    A standard format for tracking AI-generated code.

    AI编程代码归因工程规范可追溯性开发工具

1px