编程 on To the Moon

嵌入式C语言会不会像当年的汇编一样被边缘化？

Mon, 01 Jun 2026 21:37:00 +0800

本文由 AI 自动摘录整理，原始链接：嵌入式C语言会不会像当年的汇编语言一样，慢慢被边缘化？

推荐指数：6/10（读重点章节）

背景

微信公众号「最后一个bug」的文章，探讨在 AI 写代码能力越来越强的背景下，嵌入式 C 语言是否会像当年的汇编语言一样被边缘化，以及嵌入式 C 程序员如何应对。

核心观点

汇编的致命伤是架构绑定：汇编完全绑定特定 CPU 架构，换芯片就得重写；C 语言通过编译器抽象实现了跨平台可移植性，这是汇编永远无法跨越的鸿沟
C 语言是软件世界的地基：CPython 解释器、Java 的 HotSpot 虚拟机、V8 引擎、Linux 内核、FreeRTOS、TCP/IP 协议栈全是 C/C++ 写的——“塔尖可以换，但塔底一动整个塔就塌了”
AI 能生成代码，但解决不了硬件问题：AI 可以写出一份八九不离十的 SPI 初始化代码，但高温下时钟毛刺导致的 SPI 丢数据，AI 看不到示波器波形也闻不到板子烧焦的味道
破局三方向：往"硬"了走（硬件调试）、往"深"了走（系统级设计决策）、往"广"了走（技能栈拓宽，如 Rust/Python/Go）

补充要点

MCU 的物理限制是 C 语言最坚固的护城河——一颗只有 64KB RAM 的 STM32F103 跑不了 AI 模型
AI 辅助生成的外设驱动代码已经可用，但嵌入式工程师的不可替代性从"写代码"转移到了"解决系统问题"
汇编没落不是因为汇编程序员技术不好，而是需求收缩了——纯粹汇编的用武之地仅剩启动代码、RTOS 上下文切换、逆向工程等狭窄场景
系统级决策（裸机 vs RTOS、任务栈大小、优先级排布、磨损均衡策略）是 AI 目前最薄弱的环节
建议用 Rust 的内存安全理念反向改进 C 语言编程习惯——“最好的护城河不是你会什么语言，而是你能解决什么问题”
文章以 SPI 通信高温丢数据的真实案例说明硬件调试的不可替代性：用逻辑分析仪抓了一下午才定位到时钟毛刺

世界级编程大师：AI写的代码，我一行都不看

Mon, 27 Jul 2026 11:32:00 +0800

本文由 AI 自动摘录整理，原始链接：世界级编程大师：AI写的代码，我一行都不看

推荐指数：7/10（推荐阅读原文，观点鲜明且深度够）

背景

机器之心报道了 X 平台上的一场争论：AI Agent 写代码越来越快，开发者到底还要不要逐行审查？《代码整洁之道》作者 Robert C. Martin（Uncle Bob）给出了最激进的答案——完全不看。

核心观点

Uncle Bob 的激进策略：完全不阅读 Agent 写出的任何一行代码。与之对应的是极严格的自动化约束——单元测试、Gherkin 测试、QA 流程、变异测试、覆盖率指标等多重关卡。
信任模式的转变：从依赖人工阅读代码找漏洞，转向工业式的质量管理——先定义规格和验收条件，再用自动化持续验证。两种信任方式本质不同。
审查并未消失，只是上移了：Uncle Bob 仍然亲自审查 Gherkin 验收测试、QA 流程，并进行最终的人工测试验收。关键功能全面审查，普通功能抽查。只是不再逐行读实现代码。

补充要点

反对者的核心焦虑：如果我要对这段代码负责，我必须理解它——这是心理上绕不过去的坎。
更大的风险在于：Agent 可能擅自修改测试让结果适配实现，或者测试全绿但需求理解本身就错了。AI 不会让这些问题消失，反而因为代码生成更快而更难发现。
有开发者提出中间路线：逐行读所有依赖成本太高，完全放弃审查又太激进。重点应是哪些代码必须审、审到什么程度、哪些环节可以自动化。
一个更超前的追问：当 AI 让代码的生成和修改成本大幅下降，代码本身的质量还像过去一样重要吗？如果 Agent 可以随时重写模块，代码是否优雅似乎没那么关键了。
Uncle Bob 的实际做法：Agent 写的单元测试不审，但 Gherkin 测试和 QA 流程仍由他亲自检查，强度取决于项目风险。

一个人+Claude，11天生成超100万行Rust代码！Bun创始人复盘从Zig到Rust重写全过程

Sun, 12 Jul 2026 17:05:00 +0800

本文由 AI 自动摘录整理，原始链接：一个人+Claude，11天生成超100万行Rust代码！Bun创始人复盘从Zig到Rust重写全过程

推荐指数：8/10（推荐读原文）

背景

Bun 创始人 Jarred Sumner 发布长文，完整复盘了如何借助 Anthropic Claude（Fable 5 + Claude Code），一个人用 11 天将 Bun 的 53 万行 Zig 代码重写为超过 100 万行 Rust 代码。这是目前公开已知最大规模的 AI 辅助代码重构项目。

核心观点

语言选择变迁：Bun 最初押注 Zig，因其底层控制力和 C 互操作能力；但随着代码规模膨胀，Zig 的手动内存管理导致团队花大量精力修 Bug，最终转向 Rust 的所有权模型从编译器层面解决内存安全问题。
AI 重构策略：采用"机械式移植"而非重新设计——先保持原逻辑直译到 Rust，通过完整测试套件验证一致性，后续再逐步优化 unsafe 代码和 Rust 惯用写法。核心策略是"先跑起来，再变优雅"。
对抗式代码评审：用至少两个独立的 Claude 实例做代码审查，审查模型只看 diff、预设代码有缺陷，这个机制在迁移中提前拦截了异步关闭句柄导致 use-after-free 等编译检测不出的真 Bug。

补充要点

规模惊人：项目 1448 个 Zig 文件，峰值 64 个 Claude 并行运行，每分钟产出 1300 行代码，11 天累计生成 6502 次有效提交（峰值单小时 695 次），最终合并入库 1009272 行。
成本可控：API 消耗输入 token 59 亿、输出 token 6.9 亿，缓存读取 720 亿，按官方定价折算约 16.5 万美元——对比一个工程师团队一年的人工成本，性价比极高。
前置准备：Sumner 先花 3 小时与 Claude 对齐 Zig→Rust 映射规则，输出 PORTING.md 和 LIFETIMES.tsv 作为统一移植标准，并在 3 个文件上做试点验证流程。
踩坑经验：多 Claude 实例并发操作 git 互相覆盖修改码 → 禁止 AI 执行破坏性 git 命令；AI 为绕过编译错误填充 stub → 增加规则：需要长篇注释解释临时方案即视为根本缺陷。
测试流水线：分冒烟测试→子命令适配→全量测试分片→CI 全平台适配四阶段，最终 Linux 率先绿灯，Windows 最晚完成，共覆盖 6 大平台。
最终成果：Bun v1.4.0 修复 128 类内存故障，内存占用大幅回落，运行性能提升 2%-5%，安装包体积缩减约 20%，Claude Code 在 Linux 环境启动速度提升 10%。
AI 角色转变：Sumner 认为这次重构最大的变化不是"AI 写了大量代码"，而是 AI 从代码生成工具变成了参与迁移、测试和审查的全流程工程协作者。

Anthropic 长运行应用护栏设计：GAN 启发式多 Agent 架构

Fri, 22 May 2026 11:20:00 +0800

本文由 AI 自动摘录整理，原始链接：Harness design for long-running application development

推荐指数：7/10（推荐读原文）

背景

Anthropic 工程师 Prithvi Rajasekaran 分享了在长运行自主编码 agent 中护栏设计的最新实践。受 GAN（生成对抗网络）启发，他设计了一套多 Agent 架构（生成器 + 评估器），将前端设计和全栈应用开发两大不同领域的能力推向新高度。文章详细阐述了 naive 实现的两大失败模式（上下文焦虑、自我评估偏误），以及如何通过结构化护栏系统性地突破这些瓶颈。

核心观点

GAN 启发式架构：将生成对抗网络思想引入 agent 设计，用独立的生成器和评估器 agent 形成反馈循环，评估器用 Playwright MCP 真实操作应用界面进行打分，驱动生成器持续迭代改进
主观质量的可量化评估：将 “这个设计好看吗” 转化为可评分的具体标准（设计质量、原创性、工艺、功能性），用 few-shot 示例校准评估器，使其具备比生成器自身更严格的审美判断
护栏简化方法论：模型越强，护栏应越精简。从 Opus 4.5 到 4.6，成功移除 sprint 分片结构，因为新模型的原生能力已不需要这种分解；但规划器和评估器依然带来明显增益

补充要点

上下文焦虑：Sonnet 4.5 在长上下文下会过早收尾工作，仅靠 compaction（压缩摘要）不够，需要 context reset（清空上下文 + 结构化交接）才能解决；Opus 4.5 几乎完全消除了这个行为
自我评估偏误：让 agent 评价自己的作品时，它倾向于自信地表扬——即使客观质量明显平庸。分离生成和评估角色后，调优一个独立评估器比让生成器自我批评容易得多
Sprint 契约机制：生成器和评估器在每个 sprint 前协商 “done” 的定义（具体实现细节和可测试的行为），用文件传递沟通，确保构建内容忠实于规格
前端设计四准则：设计质量（整体感）、原创性（非模板/AI 泛式）、工艺（排版层次、间距一致性、颜色和谐）、功能性（用户能否完成任务），权重重设计质量和原创性
成本与质量权衡：完整护栏版本比 solo agent 贵 20x+（6 小时/$200 vs 20 分钟/$9），但输出质量天差地别——solo 模式核心功能直接不工作，护栏版本能生成可用的完整应用
评估器的迭代调优：开箱即用的 Claude 是差劲的 QA agent——会发现问题然后说服自己不算事。调优方法是读日志、找判断差异点、更新 QA prompt，经过多轮迭代才能达到合理水平
DAW 实验：用更新后护栏一次性生成了一个浏览器内数字音频工作站（4 小时/$124），可编排旋律、鼓点、混响，agent 能端到端驱动所有功能
模型越强，空间越大：好模型不是让护栏不再重要，而是让护栏可以把目标提高到新高度——在模型能够独立完成的事情之上，去攻克更复杂的任务

Claude Code 源码背后的五大设计哲学与妥协

Mon, 11 May 2026 18:04:00 +0800

本文由 AI 自动摘录整理，原始链接：为什么完美的AI Agent不存在？Claude Code源码背后的五大设计哲学与妥协

推荐指数：7/10（推荐读原文）

背景

MBZUAI VILA Lab 联合 UCL 发布了一篇学术论文，以 Anthropic Claude Code 的 TypeScript 源码为样本，系统分析了生产级 AI Agent 的设计空间。论文不满足于描述"怎么实现"，而是尝试从源码反推出驱动架构的设计哲学与设计原则，并梳理了哲学之间的矛盾与取舍。值得注意的是，论文还拿 OpenClaw 做了对照分析。

核心观点

五大设计哲学之间存在矛盾：人类决策权威 vs 安全（用户 93% 的审批弹窗都点了同意）、安全 vs 能力（严格安全检查会冻结界面）、可扩展性 vs 安全（扩展加载窗口可被攻击利用）。追求多条哲学必然带来取舍，不是设计缺陷
98.4% 的代码是确定性基础设施：Claude Code 的核心设计是"最小脚手架、最大操作 Harness"——不给模型绑太多规划框架，而是用确定性代码（权限检查、工具路由、错误恢复）保障安全执行。AI 决策逻辑仅占约 1.6%
权限系统七层独立防御：工具预过滤、拒绝优先规则、权限模式、ML 分类器、沙箱隔离、会话隔离、Hooks 拦截。任一层都能独立否决操作，但在性能压力下可能共享失败模式
上下文压缩五层递进：预算裁剪 → 历史修剪 → 微压缩 → 上下文折叠 → 自动摘要，每轮模型调用前顺序评估，压缩力度逐层递增
子 Agent 默认独立上下文：通过 Agent 工具派出子 Agent，默认进程内隔离（共享文件系统），也支持 git worktree 隔离。Agent Teams 场景通过文件锁协调多 Agent

补充要点

论文与 OpenClaw 做了六维度对比：Claude Code 逐次安全评估 vs OpenClaw 边界级访问控制；Claude Code 的 Agent 循环是中心 vs OpenClaw 只是网关一个组件
两个系统可以组合使用：OpenClaw 通过 ACP 协议把 Claude Code 作为外部编程 Harness 接入
论文引用了多项研究质疑 AI 代码工具的长期生产力：有研究发现使用 AI 后速度反而慢了 19%（但自我感知快了 20%）；使用 Cursor 后代码复杂度上升 40.7%
论文梳理了六个未来方向：静默失败、记忆持久化、Harness 边界演化、时间跨度扩展、治理合规、对人类长期能力的影响

Claude Code 工程师自曝：Prompt Caching 即一切

Mon, 11 May 2026 18:02:00 +0800

本文由 AI 自动摘录整理，原始链接：深度丨Claude Code工程师自曝：Prompt Caching即一切

推荐指数：8/10（推荐读原文）

背景

Anthropic Claude Code 团队发表技术博客，公开了 prompt caching（提示词缓存）在 Claude Code 中的核心地位。文章坦承 Claude Code 能支撑数百万开发者的长会话编程体验，秘诀不是模型能力，而是围绕缓存命中率做的极致设计。这不是一篇产品宣传，而是工程团队分享的实战经验，包含大量具体的架构决策和踩坑教训。

核心观点

提示词顺序即成本顺序：Prompt caching 基于纯前缀匹配，越稳定的内容越靠前、越动态的越靠后。静态系统指令 + 工具定义在最前，CLAUDE.md 其次，会话上下文次之，对话消息放末尾
永远不要改系统提示词：更新系统提示词会在第一个字节就分裂缓存前缀，前面积累的缓存红利全部归零。正确做法是把变更信息塞进消息流（通过 <system-reminder> 标签），前缀毫发无损
换小模型反而更贵：缓存跟着模型走，切换模型等于全价重喂整个对话历史。正确做法是用主模型整理交接摘要（hand-off message），然后派子 Agent 去执行
不要中途增减工具：工具定义属于系统前缀，增减工具会让缓存全部报废。Plan Mode 的实现是不增删工具、而是用工具状态切换
工具太多用延迟加载：不是删工具而是用 defer_loading 占位符，工具名和数量固定在前缀里，完整 schema 只在调用时才加载

补充要点

缓存命中率被当作服务器 uptime 级别的基础设施指标，掉几个百分点就会触发 SEV 级别告警
对话太长需要压缩总结时，不要新开请求，要用"cache-safe forking"——保留完全相同的前缀，追加一条总结指令
Anthropic 已把 cache-safe compaction 逻辑直接封装进 API，后人不必再踩坑
defer_loading 的设计哲学：用户看到精简工具集，但底层前缀完全静态、永远命中
整个产品的设计路径是反常规的：先确保缓存能命中，再围绕这个硬约束设计功能和交互
核心教训：大多数团队先选模型再堆功能最后才优化缓存，Claude Code 从第一天起就反着来

OpenAI 开源 Symphony：让每个任务自动跑一个 AI Agent

Mon, 11 May 2026 09:10:00 +0800

本文由 AI 自动摘录整理，原始链接：OpenAI 开源 Symphony：让每个任务自动跑一个 AI Agent

推荐指数：6/10（读重点章节即可）

背景

OpenAI 开源了 Symphony——一个把任务看板（Linear）变成 AI Agent 自动编排系统的工具。每个待办任务自动分配 Codex Agent，7×24 小时运行，工程师只需要审核结果。内部数据显示部分团队 PR 数量增长 500%，代表了 AI 编码从「人跟模型对话」走向「人给系统派活」的趋势。

核心观点

人的注意力是新瓶颈：Codex 很强，但工程师同时只能管 3-5 个 Agent 会话，超过这个数效率直线下降。瓶颈不在 Agent，在人。
从管理会话到管理任务：团队意识到围绕"编码会话"设计流程是错的。真正的组织单元是任务/需求/里程碑——让 Agent 从看板自己拉活。
给 Agent 目标而非步骤：OpenAI 的关键教训是把 Agent 当状态机里的刚性节点行不通。给 Agent 目标、工具和上下文，让它自己推理怎么走。
Symphony 核心架构：轮询 Linear 看板 → 每个任务分配独立工作区 → 自动重启 → 状态机驱动（5 个状态：Unclaimed→Claimed→Running→RetryQueued→Released）。
实际效果与代价：PR 翻 5 倍，工作心理门槛大幅降低。但 Token 消耗巨大（14h/3.88亿 Token/~$1000），不适合模糊问题，需要完善的前置条件。

补充要点

依赖管理：任务之间可设依赖关系，Agent 自动判断可并行和阻塞的任务。比如先迁移 Vite→再升级 React→再更新组件库。
Agent 能力进化路径：最初只提交一个 PR → 处理 Code Review 反馈 → 关闭过期 PR → 分析代码库和文档做计划。
大仓库优势：自动 rebase、解冲突、重试 CI 失败项，monorepo 特别受益。
“Symphony 构建 Symphony”：开发团队把 Symphony 本身的任务拆成 Issue，让 Symphony 自己编排 Agent 完成，meta 度拉满。
技术本质是 Spec：核心是一个 SPEC.md 文件，定义了 6 个组件 + 5 状态状态机，社区已基于 spec 做多种实现。
探索行为大幅增加：当发起代码变更的代价趋近于零，人们开始更频繁做实验性尝试，只有 Google 级别内部工具链才能做到的事。
谁可以发起工作的边界变了：产品经理和设计师直接往看板提需求就行，不用 checkout 代码库，描述完需求就能收到审核包。
失败即信号：Agent 产出跑偏时不手动修补，而是加护栏、加技能、完善文档，让系统持续改进。

Agent 框架中的记忆管理

Sat, 09 May 2026 17:22:00 +0800

本文由 AI 自动摘录整理，原始链接：Agent 框架中的记忆管理

推荐指数：7/10（推荐读原文）

背景

来自公众号 CppMore，系统梳理了 Agent 框架中记忆管理的完整架构：从短期记忆、长期记忆到治理策略，结合 Wuwe Agent Framework 的 C++ 实现给出具体代码示例。是中文社区少见的 Agent 记忆管理深度文章。

核心观点

记忆管理决定 Agent 智能化程度：记什么、怎么记、何时记、如何取，是四个关键问题。成功的经验积累越多，Agent 越智能
短期记忆维持上下文连续性：LLM 每次 API 调用都是独立的，必须手动保存上下文（对话消息、任务状态、历史摘要）。同时需要预算控制——上下文有限、成本递增、无关信息干扰
长期记忆需显式写入，默认不自动记录：只保存稳定可复用的信息（用户偏好、项目事实、决策约束等），自动写入可能污染后续会话、泄露敏感信息
治理策略是产品化前提：信息隔离（跨用户不串）、敏感过滤（API key 不入库）、TTL 过期清理、操作审计追踪，缺一不可

补充要点

短期记忆三类：对话消息、任务状态、历史摘要——历史摘要是保留有效复杂性、消除噪声的关键手段
长期记忆存储双引擎：SQLite 存完整内容 + 向量数据库（如 Qdrant）建语义索引，语义索引是派生数据，丢失可从 SQLite 重建
语义搜索解决的核心痛点：表达方式不同但意思相同的查询，常规数据库无法匹配
召回流程：Qdrant 语义搜索 → SQLite 取完整记录 → 过滤/排序 → 注入 Prompt
Wuwe C++ 框架中 memory_policy 控制各类记忆窗口大小，memory_context 管理作用域
长期记忆需分组（user/application/conversation/agent），否则不同场景记忆混串

Anthropic研究员Erik Schluntz的Vibe Coding大师课

Sat, 25 Apr 2026 13:29:00 +0800

本文由 AI 自动摘录整理，原始链接：如何正确Vibe Coding？这是来自Anthropic编程智能体负责人的大师课

推荐指数：9/10（必读原文）

背景

Anthropic 研究员、《构建高效智能体》合著者 Erik Schluntz 分享了他在生产环境中实践 Vibe Coding 的完整方法论。他曾因手伤被迫将工作全权交给 Claude，在此过程中总结出一套可复制的工程化实践。网友 Movez 盛赞此演讲"胜过 100 门付费课程"。

核心观点

找到可验证的抽象层，而非逐行审查代码：就像 CTO 靠验收测试管理工程师、PM 靠体验产品验证功能，开发者需要建立不读底层代码就能验证的检查点。Vibe Coding 的核心是"忘记代码，但始终关注产品"。
聚焦"叶子节点"策略：将代码变更限制在不被其他模块依赖的末端功能上，允许在这些区域产生技术债。系统主干和底层架构仍需人工严密保护。随着模型能力提升，可信任 AI 接管的层级正在向下延伸。
把自己当 Claude 的产品经理：不要问 Claude 能为你做什么，要问你能为 Claude 做什么。Erik 的标准流程是花 15-20 分钟让 AI 先探索代码库、查找相关文件、制定计划，再汇总成清晰的提示词执行。
22000 行代码的生产级合并：Anthropic 内部在 RL 代码库中成功合并了 22000 行 AI 生成代码，核心策略：数天前期规划 + 叶子节点限定修改范围 + 核心逻辑人工审查 + 长时间压力测试。两周工作量压缩到 1 天。

补充要点

TDD 是 Vibe Coding 的安全网：强制只写极简的端到端测试（快乐路径 + 2 个错误场景），确保人类能看懂。测试是 Vibe Coding 中唯一需要亲自审查的代码。
上下文压缩时机：在"人类程序员会停下来吃午饭"的自然断点处进行 Compact。先让 Claude 把计划写入文档，再压缩，将 10 万 Token 压到几千。
工具链协同：Claude Code 负责主要修改和框架搭建，Cursor 用于精确行级修改和收尾修复。面对陌生代码库，先用 Claude Code 探索建立全局视图。
关于安全：做好 PM 是根本——需要懂行，知道什么是危险的。对生产系统必须问出正确的问题引导 AI。期待涌现"数学证明级别正确"的产品和沙盒化前端开发环境。
指数级增长的含义：不是"好两倍"，而是"好一百万倍"。从 KB 到 TB 的存储跃迁就是先例。模型能力提升的速度远超想象。

Claude Code 源码泄露了，有人用 Python 复刻了一个极简版

Wed, 01 Apr 2026 22:35:00 +0800

本文由 AI 自动摘录整理，原始链接：Claude Code 源码泄露了，有人用Python复刻了一个极简版

推荐指数：9/10（必读原文）

背景

2026 年 3 月，Anthropic 在 npm 发布时不小心把 source map 一起打包进了生产版本，导致 57MB 的 cli.js.map 文件公开暴露——里面包含了 1906 个 TypeScript 源文件的完整内容。cc-mini 是社区基于这批泄露源码，用 Python 还原的极简复刻版本。

核心观点

源码泄露是低级失误：cli.js.map 本质上是 JSON 文件，包含文件路径列表和完整源码，写个脚本就能批量还原全部 4756 个文件
泄露源码揭示了 Anthropic 未发布功能：卧底模式（隐藏 AI 生成痕迹）、情绪监控（追踪用户爆粗口）、神秘模型 Capybara、KAIROS 永远在线 Agent 模块
cc-mini 是开源极简复刻版：用 Python 重写核心逻辑，目标是让任何人都能读懂、改动、二次开发

补充要点

6 个内置工具：Read、Write、Edit、Glob、Grep、Bash，权限分级（读操作自动放行，写操作需确认）
Skill 系统：把高频操作固化成一行命令，支持项目专属 SKILL.md
KAIROS 自动记忆系统：用 /remember 记录，/dream 整理成按话题分类的长期记忆文件
Sandbox 安全执行：用 Linux 原生 bubblewrap 沙盒，文件系统只读，网络默认隔离
Coordinator 主从架构：主线程负责软调度，Worker 线程负责具体执行，权限硬隔离
工程实践参考价值：上下文压缩、Agent 长期记忆、MCP 工具调度、永远在线的 Agent 设计

Claude Code 的 Prompt Caching 设计哲学

Tue, 24 Mar 2026 21:47:00 +0800

本文由 AI 自动摘录整理，原始链接：Claude Code 的 Prompt Caching 设计哲学

推荐指数：9/10（必读原文）

背景

这是一篇来自 Claude Code 团队的工程总结，解释为什么 Prompt Caching 不只是某个 API 的性能优化技巧，而是 Agent 产品的系统设计约束。一旦接受这个前提，很多"为什么 Claude Code 要这样实现"的细节都会突然变得合理。

核心观点

Prompt Caching 是前缀匹配：前缀里任何改动都会让后面的缓存一起失效。这意味着 system prompt、工具定义、上下文结构必须尽量保持稳定
用消息承载变化，不要频繁修改 system prompt：状态切换应该通过消息或专用工具表达，而不是改 prompt
Plan Mode 的正确实现：不是切换工具集，而是通过 EnterPlanMode/ExitPlanMode 工具本身表示状态切换。工具定义始终不变，缓存前缀不被破坏
延迟展开工具：请求里保留轻量级工具 stub，需要时通过 ToolSearch 加载完整 schema。缓存前缀保持稳定，昂贵定义按需注入

补充要点

Compaction 必须共享父会话前缀：使用相同的 system prompt、工具定义、上下文结构，只在最后追加 compact 指令
保存 compaction buffer：提前预留足够的上下文空间，确保 compact 请求和摘要都能放得下
不要在会话中途切模型：模型切换会破坏缓存
监控缓存命中率：像监控可用性和延迟一样认真对待

设计哲学

如果把这篇文章压缩成一句话，那就是：Prompt caching 不是某个 API 的性能优化技巧，而是 Agent 产品的系统设计约束。

对做 Agent 产品的人来说，最值得抄的不是某个孤立技巧，而是背后的工程态度：先承认缓存约束是真实存在的，再围绕约束设计状态机、工具系统和上下文流转方式。只有这样，长程、多轮、低延迟、可负担的 Agent 体验才有机会成立。

Claude Code 架构学习资源：12 课掌握 AI Agent 核心设计

Tue, 24 Mar 2026 21:45:00 +0800

本文由 AI 自动摘录整理，原始链接：Claude Code 架构学习资源

推荐指数：8/10（推荐读原文）

背景

这是一个渐进式学习网站，通过 12 节课带你理解 Claude Code（Anthropic 的 AI 编程 Agent）的设计思路。每节课都从一个核心问题出发，展示如何用代码解决问题，代码量从 84 行逐步增长到 694 行。

核心观点

渐进式学习路径：从 L1 到 L5 逐层递进，每一步都清晰可见，代码改动列得明明白白
问题驱动设计：先戳痛点再给解药，让你明白为什么需要这个机制，不是堆砌概念
工具注册机制：通过规范的注册机制像搭积木一样给 Agent 塞入各种工具函数（s02 Tools）
多层规划能力：从简单的 TodoWrite（s03）到跨 Agent 共享的依赖感知任务板（s07 Tasks）

补充要点

s04 Subagents：子 Agent 用独立的 messages[]，保持主对话干净
s05 Skills：按需加载知识，不把所有规则塞进 System Prompt
s06 Compact：三层压缩策略（滑动窗口、摘要压缩、选择性保留）实现无限会话
s08 Background Tasks：后台线程 + 通知总线，非阻塞执行慢操作
s09-s12 协作层：持久队友 + 异步邮箱、共享通信规则、自主认领任务、按目录隔离
Worktree + Task Isolation：每个 Agent 在自己的目录工作，避免冲突

学习价值

学完这 12 课，你能理解 Claude Code 的设计思路，用任何语言（Python/Go/JS/TS/C++/Java）自己动手写一个 AI 编程 Agent。核心模式是语言无关的。

网站地址：https://learn.shareai.run/zh/

Claude Code Skills 完全指南：打造你的 AI 编程助手

Fri, 20 Mar 2026 15:48:00 +0800

本文由 AI 自动摘录整理，原始链接：Claude Code Skills 完全指南

推荐指数：8/10（推荐读原文）

背景

Claude Code 是 Anthropic 推出的 AI 编程助手，其核心能力来自 Skills（技能）系统。Skills 允许开发者定义定制化的行为、规则和工具，让 Claude 更好地理解项目上下文、遵循团队规范、执行复杂任务。本文是 Claude 官方团队的实践经验总结。

核心观点

Skills 是 Claude Code 的灵魂：通过 Skills 可以定义 Claude 的行为边界、工具使用方式、代码风格偏好等，使其成为真正的"团队成员"而非通用工具
三种核心能力：Skills 包含 Rules（规则）、Tools（工具）、Hooks（钩子）三大组件，分别控制 Claude 的思考方式、行动能力、和执行时机
从 Gotcha 开始：最实用的 Skills 往往从简单的"陷阱提醒"开始，比如"不要删除测试数据"、“生产环境禁止 force push"等，逐步积累完善

补充要点

提供代码比让 Claude 自己写更高效：将脚本和库交给 Claude，让它专注于组合和决策，而非重新构建基础代码
按需钩子（On Demand Hooks）：只在需要时激活的钩子，比如 /careful 阻止危险操作、/freeze 限制编辑范围
Skills 分发：小团队可直接检查到代码库（./.claude/skills），大团队可建立内部插件市场
衡量效果：可通过 PreToolUse 钩子记录 Skills 使用情况，了解哪些受欢迎、哪些触发率低
组合 Skills：Skills 之间可以相互依赖和引用，比如"CSV 生成"可以调用"文件上传”

技术细节

Skills 的三种核心组件：

组件	作用	示例
Rules	定义思考规则	“使用 TypeScript 时优先用 interface 而非 type”
Tools	提供 Bash 命令和脚本	数据抓取脚本、部署命令
Hooks	在特定时机触发	提交前检查、危险操作警告

按需钩子示例：

/careful — 阻止 rm -rf、DROP TABLE、force-push 等危险操作
/freeze — 限制只能在特定目录编辑，调试时防止"顺手修复无关内容"

智能体软件工程 - 代码的未来

Fri, 13 Mar 2026 10:43:00 +0800

本文由 AI 自动摘录整理，原始链接：智能体软件工程 - 代码的未来

推荐指数：7/10（推荐读原文）

背景

这是一本由 Ahmed E. Hassan 撰写的在线书籍，探讨 AI 智能体如何改变软件开发。书籍提出"智能体软件工程"（Agentic Software Engineering）这一新学科，关注如何在 AI 与人类协作的环境中确保软件的可靠性和可信度。

核心观点

代码生产不是瓶颈：真正的挑战在于复杂性管理、团队沟通，以及长期维护系统完整性
从编码到架构的转变：AI 智能体时代，开发者的重心从"写代码"转向"设计架构"和"管理复杂性"
智能体软件工程是新学科：专注于在 AI 和人类共同参与的随机性环境中，确保系统的可靠性和可信度

补充要点

成功的关键：明确意图、管理风险边界、要求证据——而非追求打字速度
瓶颈不在代码产量，而在如何让系统长期保持健康
适合对 AI 辅助编程、软件工程未来趋势感兴趣的读者
书籍在线免费阅读，支持中英文切换

彻底理解C++中的适配器模式！

Thu, 12 Mar 2026 09:50:00 +0800

本文由 AI 自动摘录整理，原始链接：彻底理解C++中的适配器模式！

推荐指数：8/10（推荐读原文）

背景

文章通过一个实际场景——将第三方日志库集成到现有系统——深入浅出地讲解了 C++ 中的适配器模式。从最简单的包装函数，到类适配器（继承），再到对象适配器（组合），逐步展示了解决接口不兼容问题的演进过程。

核心观点

适配器的本质：在两个不兼容的接口之间搭建桥梁，让它们能够协同工作，而无需修改任何一方的代码
类适配器 vs 对象适配器：类适配器使用多重继承，一个适配器只能绑定一个具体类；对象适配器使用组合持有基类指针，可以适配整个继承体系
组合优于继承：继承是"我是什么"，编译时决定，绑定到具体类；组合是"我有什么"，运行时可以指向基类的任意子类，灵活性更高

补充要点

问题场景：系统有统一的 ILogger 接口，第三方库 FastLogger 接口完全不同（std::string vs const char*，log()/error() vs writeLog() + level）
包装函数的局限：只能做简单转换，无法参与面向对象体系（比如注册到需要 ILogger* 的容器中）
类适配器示例：class LoggerAdapter : public ILogger, public FastLogger，通过继承同时实现接口和复用实现
对象适配器优势：当第三方库新增 HighPerfLogger、LowPowerLogger 等变种时，同一个适配器类通过持有 FastLogger* 基类指针即可适配所有子类
运行时切换实现：对象适配器可以在运行时更换被适配对象，实现动态切换日志实现

Linux零拷贝技术终极指南：mmap、sendfile、splice、MSG_ZEROCOPY一次讲透

Tue, 10 Mar 2026 20:08:00 +0800

本文由 AI 自动摘录整理，原始链接：Linux零拷贝技术终极指南

推荐指数：8/10（推荐读原文）

背景

这篇文章系统讲解了 Linux 零拷贝技术，从传统 read+write 的 4 次数据拷贝、4 次上下文切换入手，逐一介绍 mmap、sendfile、splice、MSG_ZEROCOPY 四种零拷贝方案的原理、适用场景和限制。适合需要理解高性能 I/O 的后端开发者。

核心观点

传统 read+write 有多贵：一次"读文件发网络"涉及 4 次上下文切换、4 次数据拷贝（2 次 DMA + 2 次 CPU），其中 2 次 CPU 拷贝是纯浪费
sendfile 是零拷贝起点：Linux 2.1 引入，一个系统调用顶替 read+write，上下文切换从 4 次降到 2 次；配合 SG-DMA 网卡可做到 0 次 CPU 拷贝
splice 更灵活：可在任意两个 fd 之间传数据（其中一个必须是 pipe），只传页面引用不传数据；Linux 2.6.23 后 sendfile 内部就是基于 splice 实现的
MSG_ZEROCOPY 让普通 send 也能零拷贝：Linux 4.14 引入，适合需要先处理数据（加密/压缩）再发送的场景，但仅对大数据块（>10KB）有收益

补充要点

mmap + write：减少一次 CPU 拷贝（从 4 次降到 3 次），但上下文切换还是 4 次
sendfile 限制：输入必须是文件，输出必须是 socket
Nginx 静态文件服务用 sendfile，配置 sendfile on;
Kafka 消费者拉取消息用 sendfile，数据不进 JVM 堆，这是超高吞吐的核心原因之一
MSG_ZEROCOPY 需要等内核通知才能安全修改 buf，编程模型更复杂
小数据场景（<10KB）用 MSG_ZEROCOPY 反而更慢，页面 pin/unpin 开销超过拷贝本身

企业级AI Coding的落地方法，都在这本实战手册里了

Tue, 10 Mar 2026 19:30:00 +0800

本文由 AI 自动摘录整理，原始链接：企业级AI Coding的落地方法，都在这本实战手册里了

推荐指数：7/10（推荐读原文）

背景

字节跳动 TRAE 团队发布了《2026 企业级 AI 编程实践手册》，系统性地介绍了企业级 AI Coding 的落地方法论。文章从开发范式变革、SOLO 模式、智能体协作到实践案例，展示了 AI 如何真正成为企业开发的确定性生产力。

核心观点

AI 原生开发范式：开发流程从"需求→设计→编码→测试"压缩为"高效输入→流程设计→代码质量把控"，开发者从"写代码的人"变成"定义问题的人"
SOLO 模式：TRAE 的核心创新，让 AI 自主完成从任务拆解、代码生成到测试部署的全流程，人类只需扮演"决策"和"审核"角色
业务 Context 是关键：Trae Loop 实验数据显示，启用 Skills 时 Bug 修复率达 100%（32/32），不使用时仅 59%（19/32），证明业务上下文是提升 AI 能力的决定性因素
设计稿转代码的突破：通过 Figma MCP Server + Code Connect，将设计组件与代码组件建立映射，采用模块化拆分策略，而非"一键生成整页代码"

补充要点

TRAE 已覆盖前端设计还原、后端逻辑实现、Agent 构建的全流程
Skills 机制让 Loop 具备"业务记忆"，每次成功修复成为下次的 Context
两大核心优化策略：约束 AI 的实现规模 + 提供高质量的上下文
开发者需更深入分析业务流程，思考边界情况和异常场景
企业需调整组织结构、协作方式与治理机制，才能将个体效率转化为组织能力
未来的软件工程不区分"人写的代码"还是"AI 写的代码"，只有"高质量的业务价值"

Linux零拷贝技术终极指南：mmap、sendfile、splice、MSG_ZEROCOPY一次讲透

Mon, 09 Mar 2026 19:45:00 +0800

本文由 AI 自动摘录整理，原始链接：Linux零拷贝技术终极指南

推荐指数：9/10（必读原文）

背景

从 Nginx 静态文件服务到 Kafka 百万级消息吞吐，零拷贝技术是高性能 I/O 的核心秘密。文章系统讲解了 Linux 中的四种零拷贝技术——mmap、sendfile、splice、MSG_ZEROCOPY——的原理、适用场景和选型建议，并配有清晰的数据流图示。

核心观点

传统 read+write 有 4 次拷贝：2 次 DMA + 2 次 CPU 拷贝，其中 CPU 拷贝是纯浪费——数据经过用户空间却啥也没处理
零拷贝 ≠ 完全不拷贝：零拷贝是指零 CPU 拷贝，DMA 拷贝（磁盘→内存、内存→网卡）始终存在，但由硬件完成
sendfile 是最常用的零拷贝：一次系统调用顶 read+write，上下文切换从 4 次降到 2 次，配合 SG-DMA 网卡可实现零 CPU 拷贝
splice 更灵活但需要 pipe：可在任意两个 fd 之间零拷贝传输，但其中一个必须是管道；Linux 2.6.23 后 sendfile 内部就是基于 splice 实现
MSG_ZEROCOPY 让普通 send 也能零拷贝：适合需要先处理数据（加密/压缩）再发送的场景，但只对 >10KB 数据划算

补充要点

mmap 优化有限：减少 1 次 CPU 拷贝，但上下文切换仍是 4 次，适合需要读写文件内容的场景
sendfile 限制：输入必须是文件，输出必须是 socket
Nginx 配置：sendfile on; + tcp_nopush on; 是静态文件服务的标配
Kafka 零拷贝：通过 FileChannel.transferTo() 底层调用 sendfile，数据不进 JVM 堆
MSG_ZEROCOPY 注意：需要通过 error queue 接收完成通知；若网卡不支持 SG-DMA 会静默退化为有拷贝模式
选型建议：文件→网络用 sendfile；fd 间透传用 splice；需处理数据再发送且 >10KB 考虑 MSG_ZEROCOPY；读写文件用 mmap

源码剖析：iostream的缓冲区设计

Mon, 09 Mar 2026 19:25:00 +0800

本文由 AI 自动摘录整理，原始链接：源码剖析：iostream的缓冲区设计

推荐指数：8/10（推荐读原文）

背景

文章深入剖析 C++ iostream 的底层缓冲引擎 std::streambuf，讲解其三组指针体系、核心虚函数机制、缓冲策略与性能优化技巧，以及如何通过继承 streambuf 实现高性能日志系统、加密流、内存映射流等高级应用。

核心观点

streambuf 是 iostream 的缓冲引擎：作为所有 I/O 流的底层抽象，streambuf 是连接逻辑流操作与物理设备（文件、网络、内存）的桥梁
双重指针体系设计精妙：输入缓冲区（eback/gptr/egptr）和输出缓冲区（pbase/pptr/epptr）分离，使 streambuf 能高效处理双向流（如 fstream）
三种缓冲策略权衡性能与实时性：无缓冲（实时但慢）、行缓冲（交互友好）、全缓冲（性能最优）
同步与绑定是性能杀手：sync_with_stdio(false) + cin.tie(nullptr) 可提升 2-5 倍 I/O 性能

补充要点

核心虚函数：underflow（缓冲区空时填充）、overflow（缓冲区满时刷新）、sync（同步到设备）
格式化操纵器：无参（dec/hex/fixed）和带参（setw/setprecision），需 <iomanip>
类型安全优势：编译期类型检查、自动类型转换、支持用户自定义类型（重载 << 和 >>）
输出优化：避免频繁 endl（会刷新），用 '\n' 代替；使用 ostringstream 批量输出
输入优化：整行读取 + 手动解析；C++17 的 std::from_chars 提供零分配快速解析
自定义 streambuf 应用：时间戳日志系统、透明加密/解密流、内存映射零拷贝 I/O
缓冲区刷新时机：缓冲区满、endl/flush、程序正常退出、输入操作前（cin 与 cout 绑定）

Claude Code 工程师：我们花了一年，才学会像 Agent 一样思考

Sun, 08 Mar 2026 20:14:00 +0800

本文由 AI 自动摘录整理，原始链接：Claude Code 工程师：我们花了一年，才学会像 Agent 一样思考

推荐指数：8/10（推荐读原文）

背景

Claude Code 核心开发者 Thariq 写了一篇长推「Lessons from Building Claude Code: Seeing like an Agent」，分享了他们一年多来设计 Agent 工具的心得——不是发布新功能，而是讲怎么想明白该给 AI 配什么工具这件事。

核心观点

工具能力上限取决于使用者能力上限：给不会编程的人一台超级电脑，不如给他计算器；同理，给 Claude 配一堆它用不好的工具，不如配几个它真正懂得调用的工具
一个工具一个语义，混合意图会让模型困惑：AskUserQuestion 工具迭代了三次才成功——失败原因分别是语义冲突、自由文本不稳定、模型不知道何时调用
模型能力进化，工具设计需要跟着迭代：TodoWrite 曾经必要，但后来反而束缚了更强的模型；今天正确的约束，明天可能是枷锁
渐进式披露：不加工具也能加能力：通过「Context on Demand」让 Agent 需要时再拉取上下文，而不是把文档全塞进系统提示

补充要点

学会"像 Agent 一样看世界"：读它的输出、做实验、持续观察，而不是假设它能或不能做什么
工具多了有代价：每多一个选项，模型就多一个决策负担，性能和稳定性都会受影响
Claude Code Guide 子 Agent：专门回答关于 Claude Code 自身的问题，有专门优化的搜索指令
Grep 工具替代 RAG：让 Claude 自己搜索代码库，主动构建自己需要的上下文
工具设计是艺术不是科学：高度依赖模型、目标、环境三个变量，唯一可靠的路径是持续实验

读 OpenAI 的 Harness Engineering，我学到的几件事

Sun, 08 Mar 2026 18:48:00 +0800

本文由 AI 自动摘录整理，原始链接：读 OpenAI 的 Harness Engineering，我学到的几件事

推荐指数：8/10（推荐读原文）

背景

OpenAI 官方博客《Harness Engineering》分享了他们内部团队如何用 Codex（基于 GPT-5 的编码 Agent）从零构建真实产品：3 名工程师在 5 个月内，全程不写一行代码，完全通过 prompt 驱动 AI 产出约 100 万行代码。文章总结了在"让 AI 写全部代码"这条路上踩过的坑和积累的经验。

核心观点

给 Agent 一张地图，而不是百科全书：AGENTS.md 精简到约 100 行，只充当目录指向结构化 docs/，避免上下文稀释和模式匹配退化
仓库是唯一的真相来源：Agent 访问不到的东西对它不存在，偏好"无聊"但稳定的技术，有时宁可重写也不用不透明的外部依赖
约束越严格，Agent 越高效：固定依赖方向 + 确定性 linter + LLM 审计，中央强制边界、局部允许自治，约束越清晰解空间越小
模型是马，驾具是缰绳：未来工程师的核心能力是设计"驾具"——定义约束、构建反馈循环、管理文档结构

补充要点

当 Agent 搞不定时，问"缺了什么工具/文档/能力"，让 Agent 自己补，而不是自己上手
大 AGENTS.md 失败的四个原因：上下文稀释、重要性通胀、快速腐烂、难以验证
“纠错成本低，等待成本高”：PR 生命周期要短，让快速检测修复替代一次性做对
技术债像高息贷款：持续小额偿还 > 复利后痛苦解决，把人类品味"固化"进系统持续执行
透明内部代码比不透明外部依赖有更高"杠杆"：Agent 能看到仓库代码，但翻不了文档