Search: #AI设计

面条的草稿箱

1. 17:04 · 2026年5月29日 · 周五

   慢即是快：如何利用 AI 写出更高质量的代码
   
   很多人认为，AI 编程的意义在于“快”——以最快的速度堆砌出勉强能运行的代码，然后匆忙合并发布。但这种“快”往往伴随着低质量和技术债。
   
   实际上，大语言模型（LLM）非常灵活，我们完全可以反其道而行之：利用 AI，用更慢的速度写出质量更高的代码。
   
   以下是这种“慢速 AI 编程”的核心思路：
   
   • 让 AI 成为挑剔的 Review 助手：LLM 极其擅长寻找 Bug。你可以通过设置特定的“技能（Skills）”，让多个不同的模型（如 Claude 和 GPT）同时对你的 PR 进行审查并给 Bug 分级，通过交叉验证有效降低误报率。
   • 主导修复与取舍：根据 AI 反馈的 Bug 列表，优先引导 AI 修复高危和中度漏洞。如果发现架构设计有根本性问题，甚至可以果断放弃现有的 PR 重新构思。
   • 把“修 Bug”当成探索之旅：这种工作流虽然不会提升你的“开发速度”，但常常会帮你揪出代码库中早已存在的历史遗留 Bug。在解决这些问题的过程中，你会编写更多单测，深入理解系统的边缘情况。
   
   这并不是那种吹嘘“10倍效率”的浮躁开发方式，而是一种更健康的编程状态：借力 AI，更严谨、更方法论地对待每一行代码，让代码库保持健康。
   
   下次使用 AI 时，不妨慢下来，试着问问它：“我的这段代码可能会在哪里崩溃？”
   
   https://nolanlawson.com/2026/05/25/using-ai-to-write-better-code-more-slowly/
   
   #AI编程 #代码质量 #软件工程 #程序员

   Read the Tea Leaves

   Using AI to write better code more slowly

   A lot of people seem convinced that the point of AI coding is to write low-quality code as fast as possible. Spew out barely-passable slop, open massive PRs, and merge them unvetted. Ship it! But t…

2. 18:03 · 2026年5月11日 · 周一

   Flue：构建下一代 AI Agent 的 TypeScript 架构框架
   
   Flue 提出了一个核心公式：Agent = Model + Harness。它不仅仅是一个简单的 SDK，而是一个专为构建自主 Agent 设计的“可编程治理框架”（Harness），旨在让开发者能够轻松打造像 Claude Code 或 Codex 这样具备规划、环境感知和执行能力的强力工具。
   
   核心特性：
   
   • 高度可编程： 使用 TypeScript 编写 Agent 逻辑，支持定义复杂的技能（Skills）、工作流和多 Session 管理。
   • 自带沙箱环境： 提供内置的虚拟沙箱或连接远程沙箱（如 Daytona），让 Agent 安全地执行 Bash 命令、读写文件或运行代码。
   • 安全与隐私： 采用精细的权限控制，确保敏感的 API Token 不会被模型或沙箱环境直接接触。
   • 跨平台部署： 编写一次逻辑，即可部署为 HTTP 服务，或在 CLI、GitHub Actions、Cloudflare Workers 等多种环境运行。
   
   与其使用通用的成品 AI 工具，Flue 鼓励开发者根据特定的产品需求、数据和工作流，构建完全属于自己的定制化 Agent。
   
   https://flueframework.com/
   
   #AI #Agent #TypeScript #开发工具 #开源项目

   Flue

   

   Flue — The Agent Harness Framework

   Agent = Model + Harness. Build autonomous agents and powerful AI workflows with Flue's programmable TypeScript harness. Write once, deploy anywhere.

3. 11:22 · 2026年4月13日 · 周一

   让 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工具

   www.typeui.sh

   

   Design Skills for AI | TypeUI

   Browse 67 design skills and use them to give Claude, Codex, Cursor, and other AI coding tools a consistent visual direction for generated UI.

4. 16:45 · 2026年4月10日 · 周五

   让 AI 像顶级设计师一样编程：GetDesign.md 设计规范库
   
   如果你正在使用 AI 助手（如 Cursor、Claude 或 Bolt）进行前端开发，那么这个网站值得加入收藏夹。GetDesign.md 汇集了包括 Apple、Stripe、Linear、Notion 以及 SpaceX 在内的 60 多种知名品牌的设计系统灵感。
   
   它的核心价值在于“AI 友好”：你可以直接将这些精炼的 DESIGN.md 文件丢给 AI 编程助手，AI 就能迅速理解其设计语言、配色方案和排版逻辑，从而帮你构建出风格统一、质感高级的 UI 界面。
   
   无论你是想要打造极简的工具软件，还是具有视觉冲击力的官网，这里都是一个绝佳的 UI 风格武器库。
   
   https://getdesign.md/
   
   #设计系统 #AI工具 #前端开发 #UI设计 #生产力工具

   getdesign.md

   

   getdesign.md — DESIGN.md collection for AI coding agents

   Browse independent design system analyses from popular websites. Drop one into your project as design reference for your coding agent.

5. 08:53 · 2026年4月6日 · 周一

   Linear 发布 Agent 交互指南（AIG）：定义人机协作的新契约
   
   AI Agent 正在重塑软件的规划、构建、审查和部署方式。当 Agent 大量产出工作成果时，人类的角色也随之转变——价值重心转移到编排输入、构建上下文和审查输出上。
   
   这种转变需要一套全新的人机交互契约。Linear 提出了 Agent Interaction Guidelines（AIG），为设计更自然融入人类工作流的 Agent 交互制定了基础原则。
   
   六大核心原则
   
   1. Agent 必须表明身份
   当人类与 Agent 协同工作时，Agent 必须清晰标识自己的身份，绝不能被误认为是真人。
   
   2. Agent 应原生融入平台
   Agent 应通过平台已有的 UI 模式和标准操作来工作，而非另起炉灶。
   
   3. Agent 应即时反馈
   沉默会带来不确定性。Agent 被调用后应立即提供反馈（如"思考中"指示器），让用户知道请求已被接收。
   
   4. Agent 应透明展示内部状态
   无论是思考、等待输入、执行还是完成，Agent 都应清晰展示当前状态。用户可以随时检视其推理过程、工具调用和决策逻辑。
   
   5. Agent 应尊重退出指令
   当被要求停止时，Agent 必须立即退出，且只有收到明确信号后才能重新介入。
   
   6. Agent 不能承担最终责任
   Agent 可以执行任务，但最终责任始终归属于人类。需要建立清晰的人机委托模型。
   
   ---
   
   AIG 是一份持续演进的开放文档，Linear 邀请社区共同参与完善。
   
   🔗 https://linear.app/developers/aig
   
   #AI_Agent #人机交互 #Linear #设计原则 #AIG

   linear.app

   

   Agent Interaction Guidelines (AIG) – Linear Developers

   Foundational principles and practices for designing agent interactions that integrate more naturally into human workflows.

6. 08:13 · 2026年3月13日 · 周五

   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

   The most powerful AI software development platform with the industry-leading context engine.

7. 11:09 · 2026年1月31日 · 周六

   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代理 #隐私安全 #自托管 #聊天机器人

   openclaw.ai

   

   Introducing OpenClaw - OpenClaw Blog

   The journey from Clawd to Moltbot to OpenClaw—and why this name is here to stay.

8. 14:20 · 2026年1月24日 · 周六

   AgentFS：为 AI Agent 设计的“可审计”文件系统
   
   AgentFS 是 Turso 团队开源的 面向 AI Agent 的文件系统：不仅能像传统文件系统一样读写文件/目录，还把 Agent 的状态与行为记录成可查询、可快照的结构化数据，便于调试与复盘。
   
   它解决什么问题？
   
   • 可审计：每一次文件操作、工具调用、状态变更都会写入同一个 SQLite 数据库，可直接用 SQL 追踪“发生了什么”。
   • 可复现：一个 .db 文件就是完整运行态，支持复制/快照/回滚，用来复现某次执行或做 what-if 实验。
   • 可迁移：所有内容都封装在单个 SQLite 文件里，易于移动、备份，甚至纳入版本管理。
   
   包含哪些组件？
   
   • SDK：TypeScript / Python / Rust（程序化访问文件系统、KV、工具调用记录）。
   • CLI：初始化与管理 AgentFS；在 Linux 用 FUSE、macOS 用 NFS 挂载到本机目录；也可在沙箱里把它挂载到 /agent。
   • 规范：提供基于 SQLite 的 Agent 文件系统规格（SPEC）。
   
   使用提醒
   
   • 官方标注为 ALPHA 阶段：更适合开发、测试与实验环境，关键数据请谨慎上生产。
   
   原链接：https://github.com/tursodatabase/agentfs
   #AI代理 #文件系统 #SQLite #可审计 #开发工具

   GitHub

   GitHub - tursodatabase/agentfs: The filesystem for agents.

   The filesystem for agents. Contribute to tursodatabase/agentfs development by creating an account on GitHub.

9. 08:51 · 2026年1月22日 · 周四

   CoreSpeed：为 AI Agent 打造的容器运行时基础设施
   
   CoreSpeed 主打把「Agent 运行」这件事做成开箱即用的基础设施：你可以像部署普通容器一样部署 AI Agent，并获得更快启动、更强隔离和更易扩展的体验。
   
   它解决的核心问题：把 Agent 从 Demo 变成可上线的系统。
   
   关键能力一览
   
   • 127ms 级别快速启动：通过内置 Warm Pool，让容器接近“秒开/毫秒开”，减少冷启动等待。
   • 按用户隔离的安全沙箱：一人一容器，降低数据串扰与安全风险。
   • 无限水平扩展 + 可缩到 0：按需分配资源，空闲可降到零成本运行。
   • AI & MCP Gateway：统一接入 AI 模型与 MCP Server，提供可观测性与安全防护（例如减少 API Key 泄露风险），并支持按调用计费。
   
   配套：Zypher（TypeScript Agent Runtime）
   
   同时他们提供 Zypher SDK，强调：
   
   • 不是固定工作流，而是「真 Agent」的反应式循环
   • 模型/供应商无关（Claude、GPT 等）
   • 多 Agent 协作架构
   • 丰富工具与 MCP 协议支持
   • 更节省 Token 的上下文加载与执行策略
   
   原文链接：https://www.corespeed.io/
   
   #AI代理 #容器基础设施 #MCP #AgentRuntime #开发者工具

10. 10:00 · 2026年1月18日 · 周日

    以“推理速度”交付：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 #开发工作流 #效率工具 #软件工程

    steipete.me

    

    Shipping at Inference-Speed | Peter Steinberger

    Why I stopped reading code and started watching it stream by.

11. 16:37 · 2026年1月12日 · 周一

    Agent-native 应用：把“功能”变成“结果”
    
    这篇文章提出一种新范式：与其把产品能力写成一堆固定功能，不如构建一个能反复调用工具、直到达成目标的“软件代理（agent）”。核心在于：让代理拥有与用户同等的操作能力（UI 能做的，代理也能通过工具做到），并把工具设计成足够原子化的“积木”。这样，新功能往往不再是写代码，而是写一段描述结果的提示词；同时，用户提出的意外需求会推动系统“涌现”出新用法，并反过来指导你补齐工具与能力缺口。
    
    五个核心原则
    
    • 对等（Parity）：任何 UI 动作，代理都应能通过工具实现同样的结果；否则代理会卡死。
    • 粒度（Granularity）：工具是原子能力；“功能”是代理在循环中用工具达成的结果。改行为优先改提示词，而不是重构代码。
    • 可组合（Composability）：有了原子工具 + 对等能力，就能通过新提示词快速拼出新“功能”（开发者/用户都能做）。
    • 涌现能力（Emergent capability）：用户会提你没设计过的需求；代理若能组合工具完成，就是新机会；若失败，则暴露工具缺口。
    • 持续变好（Improvement over time）：通过沉淀上下文（context 文件）与迭代提示词，应用可在不发版的情况下持续变强。
    
    落地方法（把原则变成工程实践）
    
    • 先做“能力地图”：列出用户能做的事，逐项确认代理具备创建/读取/更新/删除（CRUD）能力，避免“能新建不能修改/删除”的断腿体验。
    • 先原语、后领域工具：先用文件、bash、读写等基础工具跑通；再为高频模式加领域工具，用于效率、校验、术语锚定，但不要把“判断”写进工具里。
    • 文件作为通用接口：文件天然可读、可审计、可迁移，代理也最擅长操作；内容放文件、结构化高频数据放数据库（或混合：文件作可读真相，DB 做索引与性能）。
    • 明确完成信号：不要靠“看起来差不多了”判断结束；让工具/编排层返回明确的 complete 信号，避免无限循环或半成品。
    • 透明的代理行为：工具调用、进度、状态变化要让 UI 可见；“沉默的代理”会让用户觉得坏了。
    • 把“授权”做成产品能力：根据风险与可逆性决定自动执行还是强确认；尤其是发送邮件、发布内容等高风险动作。
    
    对移动端的启示
    
    • 移动应用容易被后台杀死，代理任务却可能很长：需要checkpoint/恢复机制，尽可能在每次工具结果后存档。
    • iCloud 之类的文件同步能让多设备共享“同一工作区”，但要处理冲突与未下载文件等边界。
    
    原链接：https://every.to/guides/agent-native
    
    #AgentNative #软件代理 #AI产品 #工具调用 #产品架构

    every.to

    

    Agent-native Architectures

    A technical guide for building applications where agents are first-class citizens

12. 15:43 · 2026年1月1日 · 周四

    Steel：为 AI Agent 打造的开源云端浏览器基础设施
    
    Steel 是一个开源的浏览器 API，用来在云端按需启动并控制“浏览器集群”，让 AI Agent、自动化脚本把能力真正带到网页上运行。
    
    它适合做什么？
    
    • 大规模网页抓取与数据采集（也支持更稳定的反爬配置）
    • 自主 Web Agent（下单、订票、填写表单等真实操作流程）
    • 模型训练数据采集、AI 购物助手、RPA/销售自动化、QA 测试、客服自动化
    
    核心能力概览
    
    • Sessions API：一行调用启动浏览器会话
    • 自动 CAPTCHA 处理：减少流程中断
    • 代理与指纹控制：降低被识别为机器人的概率
    • 快速启动：平均会话启动时间低于 1 秒（同区域更快）
    • 长会话：单个会话最长可跑 24 小时
    • 上下文复用：保存/注入 Cookies 与本地存储，续跑更顺畅
    • 低改动迁移：Puppeteer/Playwright/Selenium 通过少量改动即可上云
    • 可观测性：提供会话查看器，支持实时/录制回放调试
    • 安全登录：帮助自动化访问需要登录的站点
    
    价格与开源
    
    • 提供免费档起步（按浏览器小时/代理带宽/CAPTCHA 计量），也有从个人到企业的多档套餐
    • 项目开源，可本地运行或用 Docker 自托管（官方 GitHub 仓库提供）
    
    原链接：https://steel.dev/
    #浏览器自动化 #AI代理 #Web抓取 #开源工具 #云基础设施

    steel.dev

    

    Steel | Open-source Headless Browser API

    Steel is an open-source browser API purpose-built for AI agents.

13. 08:50 · 2025年12月29日 · 周一

    用好编码代理：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.

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

15. 21:52 · 2025年12月23日 · 周二

    MiniMax M2.1 发布：面向真实复杂任务的多语言编程升级
    
    MiniMax 发布新一代文本模型 MiniMax M2.1，目标从“可用、低成本”进一步走向“能解决真实世界的复杂任务”，重点补齐多语言工程协作与办公场景执行力。
    
    这次重点提升了什么？
    
    • 多语言编程能力系统增强：覆盖 Rust / Java / Go / C++ / Kotlin / Objective‑C / TypeScript / JavaScript 等，更贴近真实项目的多语言栈协作。
    • Web & App 开发更强、更好看：强化原生 Android / iOS 开发，同时提升设计理解与审美表达，支持复杂交互、3D 场景模拟与高质量可视化。
    • 更适合办公场景的“复合指令”执行：在多约束条件下做端到端任务推进，更强调“按要求完成”而不是只写对代码。
    • 更简洁、更高效的输出：相较 M2，响应更精炼、速度更快、token 消耗更低，适配持续式 AI Coding / Agent 工作流。
    • 更强的 Agent / 工具泛化：官方称在多种编码工具与 Agent 框架中表现稳定，并兼容常见的上下文管理约定。
    • 对话与写作质量同步提升：不仅是“更会写代码”，也更擅长技术文档与日常写作的结构化表达。
    
    基准与展示
    
    • 在多项软件工程评测上相对 M2 有明显提升，并强调多语言场景竞争力；同时引入 VIBE（含 Web/Simulation/Android/iOS/Backend）评测体系，用更接近真实运行环境的方式验证“能跑、能交付”。
    
    如何使用
    
    • API：已上线 MiniMax Open Platform
    • 产品：基于 M2.1 的 MiniMax Agent 已开放
    • 开源：模型权重提供本地部署，推荐 SGLang / vLLM 等推理框架
    
    原文链接：https://www.minimax.io/news/minimax-m21
    
    #MiniMax #开源大模型 #AI编程 #多语言开发 #Agent工作流

    MiniMax

    MiniMax M2.1: Significantly Enhanced Multi-Language Programming, Built for Real-World Complex Tasks

16. 08:57 · 2025年12月21日 · 周日

    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安全 #对齐研究 #模型评估 #开源工具 #大模型

    Anthropic

    

    Introducing Bloom: an open source tool for automated behavioral evaluations

    Anthropic is an AI safety and research company that's working to build reliable, interpretable, and steerable AI systems.

17. 00:03 · 2025年12月13日 · 周六

    Android Use：让 AI 代理能控制原生 Android 应用的开源库
    
    📱 这是一款专为移动设备设计的 AI 代理工具，解决了一个核心问题：笔记本电脑无法在卡车驾驶室、送货途中等场景使用。
    
    核心亮点：
    
    • 利用 Android 无障碍 API 获取结构化 UI 数据，无需昂贵的视觉模型
    • 相比 Anthropic Computer Use，成本降低 95%（每次操作 $0.01 vs $0.15）
    • 延迟低于 1 秒，准确率超 99%
    • 核心代码不到 200 行，简洁可扩展
    
    应用场景：
    
    🚛 物流：卡车司机在驾驶室内提交发票
    🚗 零工经济：Uber/DoorDash 司机多应用切换
    📦 快递：自动扫描包裹并标记送达
    🏦 移动银行：自动化对账和交易处理
    
    工作原理：
    
    1. 感知 - 通过 ADB 获取无障碍树（XML）
    2. 推理 - GPT-4 分析屏幕状态并决策
    3. 执行 - 通过 ADB 命令操作设备
    
    项目发布 24 小时内在 X 上获得 70 万+ 浏览，已有多家物流公司启动试点。
    
    🔗 GitHub 项目地址
    
    #Android #AI代理 #自动化 #物流科技 #开源

    GitHub

    

    GitHub - Action-State-Labs/android-action-kernel

    Contribute to Action-State-Labs/android-action-kernel development by creating an account on GitHub.

18. 22:35 · 2025年12月12日 · 周五

    MCPorter 🧳 — TypeScript 调用 MCP 服务器的终极工具
    
    MCPorter 是一个 TypeScript 运行时、CLI 和代码生成工具包，专为 Model Context Protocol (MCP) 设计。它让开发者能够以更优雅的方式调用 MCP 服务器，无需繁琐的配置和模板代码。
    
    核心特性：
    
    • 零配置发现 — 自动合并来自 Cursor、Claude、Codex、Windsurf、VS Code 等编辑器的 MCP 配置
    • 一键生成 CLI — 将任意 MCP 服务器定义转换为可分发的命令行工具
    • 类型安全客户端 — 自动生成 .d.ts 接口和客户端包装器
    • 友好的 API — createServerProxy() 暴露驼峰命名方法，自动处理 JSON Schema 默认值
    • OAuth 支持 — 内置 OAuth 缓存，支持 HTTP、SSE 和 stdio 传输协议
    
    快速开始：
    
    

    # 列出你的 MCP 服务器
    npx mcporter list
    
    # 调用工具
    npx mcporter call context7.resolve-library-id libraryName=react
    
    # 生成独立 CLI
    npx mcporter generate-cli --command https://mcp.context7.com/mcp
    

    
    
    安装方式：
    
    

    # 使用 npx 即时运行
    npx mcporter list
    
    # 添加到项目
    pnpm add mcporter
    
    # Homebrew
    brew install steipete/tap/mcporter
    

    
    
    项目采用 MIT 许可证，当前版本 v0.7.1。
    
    🔗 GitHub 仓库
    
    #MCP #TypeScript #CLI #开发工具 #AI工具

    GitHub

    GitHub - openclaw/mcporter: Call MCPs via TypeScript, masquerading as simple TypeScript API. Or package them as cli.

    Call MCPs via TypeScript, masquerading as simple TypeScript API. Or package them as cli. - openclaw/mcporter

19. 23:10 · 2025年12月9日 · 周二

    Beyond Vibe Coding：AI 辅助开发完整指南
    
    Google 工程负责人 Addy Osmani 发布了一份全面的 AI 辅助开发指南，帮助开发者从"氛围编程"迈向生产级工程实践。
    
    核心观点
    
    70% 问题：AI 能快速完成 70% 的功能原型，但剩余 30% 需要深厚的工程知识。修一个 bug 可能引入新问题，安全漏洞风险也不容忽视。
    
    AI 开发光谱
    
    • 自动补全：预测下一行代码
    • 聊天机器人：自然语言问答
    • 智能代理：自主处理多步骤任务
    
    关键最佳实践
    
    1️⃣ 先规划，后编码：让 AI 先提供架构方案，而非直接生成代码
    2️⃣ 上下文为王：提供相关代码、设计文档、错误信息
    3️⃣ 视觉辅助：截图胜过千言万语
    4️⃣ 每次改动后测试：小步快跑，避免调试噩梦
    5️⃣ 清晰描述意图：说明你想实现什么，而非仅描述表面症状
    
    进阶技巧
    
    • 提示工程：分解复杂任务、提供输入输出示例、善用角色扮演
    • 上下文工程：像操作系统管理内存一样动态组装信息
    • CLI 代理：Claude Code、Gemini CLI 等工具让终端成为强大的开发环境
    • 多代理协作：不同专业代理并行处理任务
    
    生产就绪原则
    
    ⚠️ 始终审查 AI 生成的代码——像审查初级开发者的代码一样
    🔒 安全第一：输入验证、凭证管理、SQL 注入防护
    
    

    未来的模型只会越来越强大。今天学会与 AI 协作，就是在为明天的工程实践做准备。
    

    
    🔗 原文链接
    
    #AI辅助开发 #VibeCoding #提示工程 #软件工程 #AddyOsmani

    beyond.addy.ie

    Beyond Vibe Coding - A Guide To AI-Assisted Development

    Transform your development workflow with AI. Learn from Google Chrome's Engineering Leader how to master AI-assisted development and build better software.

20. 22:07 · 2025年12月7日 · 周日

    AI 代理上下文工程实战：Manus 团队的六大核心经验
    
    Manus 团队在构建 AI 代理过程中，经历了四次框架重建，最终总结出六条关键原则：
    
    1. 围绕 KV 缓存设计
    KV 缓存命中率是最关键指标，直接影响延迟和成本(10倍差距). 实践要点：保持提示前缀稳定(避免时间戳)、使用只追加式上下文、确定性序列化 JSON.
    
    2. 遮蔽而非移除工具
    动态增删工具会破坏 KV 缓存并导致模型困惑. 解决方案是使用状态机掩蔽 token logits，通过响应预填充约束动作空间，同时保持工具定义稳定.
    
    3. 文件系统作为上下文
    面对 128K token 限制和长上下文性能下降问题，Manus 将文件系统视为无限外部记忆. 代理学会按需读写文件，压缩策略保持可恢复性(如保留 URL 可重新获取网页).
    
    4. 通过复述操控注意力
    典型任务需约 50 次工具调用，易偏离目标. Manus 通过不断更新 todo.md 文件，将全局计划推入模型近期注意力范围，避免"迷失在中间"问题.
    
    5. 保留错误内容
    将失败尝试保留在上下文中，让模型看到错误和堆栈跟踪，隐式更新内部信念，降低重复错误概率. 错误恢复能力是真正代理行为的核心指标.
    
    6. 避免少样本示例陷阱
    重复的行动-观察对会让模型陷入固定模式. 通过引入结构化变化(不同模板、措辞、格式噪音)增加多样性，打破模式依赖.
    
    核心启示：上下文工程决定代理的速度、恢复能力和扩展范围. 智能代理的未来需要精心设计每一个上下文.
    
    原文链接
    
    #AI代理 #上下文工程 #Manus #LLM优化 #KV缓存

    manus.im

    

    AI代理的上下文工程：构建Manus的经验教训

    这篇文章分享了Manus通过我们自己的"SGD"所达到的局部最优解。如果你正在构建自己的AI代理，我们希望这些原则能帮助你更快地收敛。