Anthropic

本文翻译自 Thariq 在 X 上发布的文章：Using Claude Code: The Unreasonable Effectiveness of HTML。本文完全由有道龙虾翻译和发布。 Markdown 已经成为智能体与我们沟通时最主流的文件格式。它简单、可移植，有一定的富文本能力，也很容易让你编辑。Claude 甚至已经非常擅长在 Markdown 文件里用 ASCII 画图。 但随着智能体变得越来越强，我开始觉得 Markdown 变成了一种限制性格式。超过一百行的 Markdown 文件对我来说就很难读。我想要更丰富的可视化、颜色和图表，而且希望它们能轻松分享。 我也越来越少亲自编辑这些文件，而是把它们当作规格说明、参考文件、头脑风暴结果等来使用。即便我确实要修改，通常也是让 Claude 去改，这就削弱了 Markdown 最大的优势之一。 我已经开始更偏好用 HTML 作为输出格式，而不是 Markdown。我也越来越常看到 Claude Code 团队的其他人这么做。下面是原因。 如果你想先看一些例子，可以看这里：html-effectiveness，但记得回来继续读为什么。 为什么是 HTML？ 信息密度 相比 Markdown，HTML 能传达丰富得多的信息。它当然可以表达简单的文档结构，比如标题和格式，但它还可以表示各种其它信息，例如： 用表格表示表格数据 用 CSS 表示设计数据 用 SVG 表示插图 用 script 标签表示代码片段 用 HTML 元素、JavaScript 和 CSS 表示交互 用 SVG 和 HTML 表示工作流 用绝对定位和 canvas 表示空间数据 用 image 标签表示图片 我甚至会说，几乎没有 Claude 能读懂、但你无法用 HTML 相对高效表达的信息集合。这让 HTML 成为模型向你传达深度信息、并让你审阅这些信息的一种非常高效的方式。...

以下内容完全由 有道龙虾 整理，排版和发布。原视频：Head of Claude Code: What happens after coding is solved | Boris Cherny。 Claude Code 一开始并不是爆款 Claude Code 今天看起来像是突然冒出来的未来工具，但 Boris Cherny 讲得很坦白：它最早几乎是“意外”做出来的。 2024 年底，他加入 Anthropic 内部一个叫 Anthropic Labs 的小团队。这个团队像一个孵化器，人数不多，却做出了几件后来影响很大的东西：Claude Code、MCP，还有 Claude 桌面应用。 Claude Code 的起点，是团队看到了一种“产品悬空”状态。模型已经有能力做很多事，但还没有一个产品把这些能力接住。 当时写代码的主流 AI 体验还是自动补全：打开 IDE，按 Tab，一行一行补。Sonnet 3.5 已经让这种体验变得好用，但 Boris 和团队觉得，这不是终点。 他们想做的不是“帮你补下一行”，而是让 agent 直接写完整代码。 问题是，最开始真的不好用。 Boris 说，前 6 个月 Claude Code 基本没跑起来。他自己大概只有 10% 的代码会用它写。早期发布后也没有立刻爆发，虽然有人用，但远远不是今天这种增长曲线。 真正的转折点出现在 Opus 4 发布之后。Claude Code 的增长从那时开始明显加速，之后每一次模型升级，增长都会再拐一次弯。从 Opus 4，到 4.5、4.6，再到 4.7，产品能力几乎是跟着模型能力一起往前跳。 这也是 Claude Code 很特别的一点：它不是为当时的模型做的产品，而是提前半年为下一代模型做的产品。...

本文整理自 YouTube 频道 Lenny’s Podcast 的访谈视频 How Anthropic’s product team moves faster than anyone else | Cat Wu (Head of Product, Claude Code)，由有道龙虾总结和发布。 如果你还在用半年、一年为单位规划 AI 产品，可能已经慢了。 Anthropic 的 Claude Code 和 Co-work 团队，现在很多产品功能的周期已经从过去的 6 个月，压缩到 1 个月、1 周，甚至有时候是 1 天。 这不是因为他们找到了某个神奇流程，也不只是因为他们能用最前沿的模型。更核心的变化是：AI 正在把“写代码”这件事变便宜，把真正贵的东西推到台前。 那就是：判断该写什么，为什么写，写成什么样。 这也是 Cat Woo 在这次访谈里反复强调的主线。她是 Anthropic 负责 Claude Code 和 Co-work 的产品负责人，和 Boris 一起站在 AI 原生产品构建的最前线。她看到的变化很直接：PM 的角色没有消失，但它正在被重新定义。 PM 的工作，不再是守着路线图开会 Cat Woo 对自己和 Boris 的分工有一个很有意思的描述。 Boris 更像技术负责人和产品愿景提出者，能看到 3 个月、6 个月之后产品该长成什么样，甚至是“AGI pilled”版本的产品该是什么样。...

Varick Agents CTO Eyad Khrais 吃到上一篇 Claude Code 入门文章：The complete claude code tutorial 的红利后（在 X 上大受欢迎，总阅读量接近 500 万），又迅速写了第二篇 Claude Code 进阶的文章：The claude code tutorial level 2。这篇文章的核心在于介绍 Skills（技能）、Subagents（子智能体）和 MCP connectors（MCP 连接器）这三大高级功能。 关键细节 Skills（技能）：教导 Claude 特定工作流 定义与结构：Skill 是一个 Markdown 文件，包含 YAML 头信息（名称、描述）和具体的指令正文。 创建方式：在 ~/.claude/skills/ 目录下创建文件夹和 SKILL.md 文件。 工作原理：采用“渐进式披露”原则。Claude 启动时仅加载 Skill 的名称和描述（约 100 tokens），只有在判定相关时才加载完整指令。这允许用户拥有数十个技能而不占用过多上下文。 应用场景：代码审查标准、Git 提交信息规范（如 Conventional Commits）、数据库查询模式、API 文档格式等。 Subagents（子智能体）：隔离上下文与任务分发 核心优势：解决上下文退化问题。主对话将复杂任务委托给子智能体，子智能体在独立的 200K 窗口中运行，仅返回摘要给主对话，从而防止主上下文被污染。 内置类型： Explore：快速、只读的代码库搜索与分析。 Plan：用于规划模式下的研究和架构决策。 General-purpose：处理需要多步操作的复杂任务。 自定义智能体：用户可在 ~/.claude/agents/ 中定义自定义智能体（如安全审查员），设定特定的系统提示词和工具权限（如只读或读写）。 通信模式：主智能体委托任务 -> 子智能体执行 -> 子智能体返回摘要。注意：子智能体不能再生成子智能体。 MCP Connectors（模型上下文协议）：连接外部世界 功能：一种标准化的接口，允许 AI 模型直接调用外部工具和数据源，无需为每个工具单独集成。 操作命令：使用 claude mcp add --transport http <name> <url> 添加连接。 推荐集成： GitHub：管理代码库、PR 和 Issue。 Slack：读取频道历史和摘要。 PostgreSQL：直接查询数据库。 Linear/Jira：集成任务跟踪。 实际效果：将原本需要切换 5 个标签页（查看 Issue、设计图、Slack 讨论、写代码、更新工单）的工作流，整合为一个连续的会话。 原文：The claude code tutorial level 2 这是官方 Claude Code 教程的第二部分，我将涵盖更高级的概念，帮助你更充分地利用 Claude Code。如果你还没读过第一部分，我强烈建议你在读这篇文章之前先读一下。这篇文章直接建立在那些基础之上。...

本文整理自 Varick Agents CTO Eyad Khrais 发布的文章：The complete claude code tutorial 作者 Eyad 结合其 7 年的软件工程经验指出，使用 Claude Code 等 AI 工具时，最大的错误是直接开始输入或生成代码。成功的关键在于先进行架构规划和系统设计，通过与 AI 的深度对话确定方案，而非单向指令。 AI 模型是无状态的，输出质量完全取决于输入的质量。如果 Claude 的表现不佳，通常是因为用户的提示词（Prompt）模糊、缺乏上下文或架构指令不明确。掌握清晰的沟通技巧和约束条件是提升效率的核心。 高效使用 Claude Code 需要精细化管理上下文窗口，利用 .clauderc 文件进行项目级配置，并灵活运用 MCP 和 Hooks 等高级功能来实现自动化和系统化集成，而非仅仅将其作为一次性问答工具。 关键细节 规划模式（Plan Mode）的重要性 先思考再输入：直接生成代码往往效果不佳。建议先进入“计划模式”（按两次 Shift+Tab），花时间与 AI 讨论架构、端到端状态和调试思路。 双向对话：不应只是单向下达指令，而应与 ChatGPT 、 Gemini 或 Claude 进行深入的来回对话，共同确定系统设计方案。 核心配置文件 .clauderc 的使用技巧 作为入职文档： .clauderc 是一个 Markdown 文件， Claude 在每次会话前都会读取。它应像给“失忆后的自己”写的笔记，而非给新员工的文档。 保持精简： Claude 只能可靠地遵循约 150 到 200 条指令。文件内容应简短且与项目高度相关，避免无关信息。 解释“为什么”：告诉 Claude 指令背后的原因（例如：“使用 TypeScript 严格模式是因为我们曾遇到隐式类型导致的生产错误”），这能帮助模型做出更好的判断。 持续更新：将其视为活文档，一旦发现需要重复纠正 AI 某件事，就应立即将其加入配置文件。 上下文窗口管理的艺术 性能衰减点：模型性能在上下文使用率达到 20-40% 时就开始下降，而不是 100% 。 会话隔离：每个功能或任务应开启一个新的会话，避免上下文混杂。 外部记忆：对于复杂任务，让 Claude 将计划和进度写入外部文件，以便跨会话读取。 复制粘贴重置法（The copy-paste reset）：当上下文臃肿时，复制关键信息，运行 /compact 或 /clear 清空上下文，然后只粘贴最关键的内容，以恢复模型智商。 提示词与沟通策略 具体明确：避免模糊指令（如“构建一个认证系统”），应提供具体的技术栈、存储方式和中间件要求。 设定负面约束：明确告诉 Claude 不要过度设计或添加不必要的抽象，特别是对于 Claude 4....

本文翻译自 Anthropic 官方技术博客：Demystifying evals for AI agents。 主要观点 有效的评估（Evals）是团队自信地发布 AI Agent 的基础。与单轮对话的 LLM 不同，Agent 涉及多轮交互、工具调用和状态修改，这使得它们更难评估。缺乏评估会导致团队陷入被动的“打地鼠”模式，仅能在生产环境中发现问题。相反，建立评估体系能让问题在早期显现，量化改进效果，并促进产品与研究团队的协作。 一个完整的评估体系包括任务（Task）、评分器（Grader）、评估工具（Harness）和数据集（Suite）。针对不同类型的 Agent（如代码、对话、研究、计算机操作），需要采用不同的评估策略。评分器通常结合了基于代码的确定性检查、基于模型的灵活评分（LLM-as-judge）以及人工审核，以平衡速度、成本和准确性。 构建评估体系不需要一开始就追求完美。文章提出了一个实用的路线图：从少量的现实失败案例开始，逐步建立无歧义的任务集，设计稳健的测试环境和评分逻辑，并长期维护。重要的是要结合自动化评估、生产监控、A/B 测试和人工审查，形成一个多层次的质量保障网络（类似瑞士奶酪模型），以全面理解 Agent 的性能。 关键细节 核心定义与组件 构建 Agent 评估时涉及以下关键概念： Task (任务)：具有定义输入和成功标准的单个测试用例。 Trial (尝试)：对任务的一次执行，通常需要多次运行以应对非确定性。 Grader (评分器)：对 Agent 表现进行打分的逻辑，可包含多个断言。 Transcript (实录)：完整的交互记录，包括输出、工具调用和推理过程。 Outcome (结果)：试验结束时环境的最终状态（例如数据库中是否存在预定记录）。 不同类型 Agent 的评估策略 Coding Agents：通常使用确定性评分器。例如 SWE-bench Verified 通过运行单元测试来验证代码修复是否成功。 Conversational Agents：侧重于交互质量和任务完成度。常使用 LLM 模拟用户进行多轮对话，并结合状态检查（如工单是否解决）和语气评分。 Research Agents：评估较为主观。策略包括检查内容的依据性（Groundedness）、覆盖率（Coverage）和来源质量。 Computer Use Agents：在沙盒环境中运行，通过检查截图或 DOM 状态来验证结果。例如 WebArena 和 OSWorld。 评分器类型 基于代码 (Code-based)：如字符串匹配、静态分析。优点是快速、便宜、客观；缺点是缺乏灵活性。 基于模型 (Model-based)：如 LLM 评分量表。优点是灵活、能捕捉细微差别；缺点是成本较高，需人工校准。 人工评分 (Human)：专家审查。优点是质量金标准；缺点是昂贵且慢，通常用于校准模型评分器。 处理非确定性与指标 由于 Agent 行为在不同运行间存在差异，文章提出了两个关键指标：...

本文整理自 Anthropic 的工程师 Barry 和 Mahesh 在 AI Engineer 做的关于 Skills 的分享：Don’t Build Agents, Build Skills Instead。 Anthropic 这帮工程师真的非常高产，继创造了 MCP 协议、Claude Code 编码 Agent 后，又创造了 Skills。他们的每一次创新都是源于实际工程开发中的真实需求，比如： MCP 协议的提出是因为解决模型与异构数据源（如本地文件、SaaS工具）连接的碎片化与标准化难题； Claude Code 创造是因为突破对话框的限制，让 AI 直接深入本地开发环境，实现从“阅读代码”到“执行构建”的自主闭环。 而 Skills 的创造是因为 将高频、复杂的任务逻辑封装为可复用的标准化模块，让 Agent 拥有长期的“肌肉记忆”，避免在重复任务中反复进行低效的 Prompt 引导。 以下是本次分享的核心内容，由我和 Gemini 3 Pro 共同整理而成。 代码就是这一层通用的接口 以前我们有个误区，觉得不同领域的 Agent 应该长得完全不一样。做金融的 Agent 和写代码的 Agent，肯定需要完全不同的工具和脚手架，甚至得为每个用例单独造一个 Agent。 但后来我们发布了 Claude Code（我们的第一个编程 Agent），搞着搞着发现：原来底下那个通用的 Agent 其实比我们想象的要强大得多。 代码不仅仅是一个使用场景，它其实是连接数字世界的通用接口。 想象一下生成一份财务报告：模型调用 API 拉数据、在文件系统里整理、用 Python 分析、最后输出格式化文件。这一整套流程，其实只需要极薄的一层脚手架（Bash 和文件系统）就能搞定。 智商 300 的天才 vs....

本文整理自前 Meta 首席工程师、Claude Code 创造者 Boris Cherny 深度访谈。 你可能还没听过 Boris Cherny 这个名字，但如果你关注 AI 编程，你一定听说过 Claude Code。 Boris 是 Claude Code 的创造者，现在在 Anthropic 工作。在此之前，他在 Meta（Facebook）和 Instagram 摸爬滚打了多年，一路干到了 Principal Engineer（首席工程师/IC8 级别）。 从早期的 Facebook Groups 到 Instagram 的日本团队，再到如今在 Anthropic 重新定义编程方式，Boris 的职业生涯简直就是一本“工程师打怪升级指南”。 这不仅仅是关于写代码，更是关于如何在大厂里找到“潜需求”、如何用“旁门左道”的项目获得晋升，以及——在 AI 满天飞的今天，我们到底该怎么写代码？ 一、 产品哲学的核心：寻找“潜需求” (Latent Demand) 如果问 Boris 做产品最重要的原则是什么，他会毫不犹豫地告诉你：潜需求。 什么意思？简单说就是：你永远没法让用户去做他们根本不想做的事。你只能发现他们已经在笨拙地尝试做的事，然后帮他们做得更顺滑。 他在 Facebook 时的几个成功项目都验证了这一点： Marketplace（二手交易市场）： 他们发现 Facebook Groups 里居然有 40% 的帖子都是在买卖东西，尽管那个功能根本不是为此设计的。用户在“滥用”产品，这恰恰就是机会。 Facebook Dating： 数据显示，大量用户在查看非好友的異性主页。也是一种本来就存在的“潜需求”。 正如 Boris 所说：“找到用户的意图，然后给他们铺好路，别试图强行改变他们的行为。” 二、 大厂生存：跨部门协作与“Side Quests” 在大厂工作，常常像是在泥潭里跳舞。Boris 讲了一个他在 Facebook 做“Chats in Groups”项目时的噩梦。...

本文由 Anthropic 工程师 Justin Young 撰写：Effective harnesses for long-running agents。本文探讨了随着 AI Agent能力增强，在处理跨越数小时或数天的复杂任务（如软件工程）时面临的核心挑战：如何在多个有限的上下文窗口（context windows）之间保持工作的连贯性。作者指出，仅靠上下文压缩不足以解决问题，Agent 容易出现试图一次性完成任务（one-shotting）或过早宣布任务完成的失败模式。 为了解决上述问题，作者提出了一套基于 Claude Agent SDK 的双重解决方案： 初始化Agent （Initializer agent）：负责在首次运行时设置环境和规划任务。 编码Agent （Coding agent）：负责在后续会话中进行增量开发，并为下一次会话留下清晰的记录。 这一方案通过结构化的环境设置、详细的功能列表和严格的增量工作流，确保Agent 能够像人类工程师轮班一样，在没有先前记忆的情况下高效接手工作。 关键细节 核心挑战与失败模式 上下文限制：Agent 在离散的会话中工作，新会话开始时没有之前的记忆。 常见错误：在使用 Opus 4.5 等前沿模型时，若仅给出高层级提示，Agent 倾向于试图一次性构建整个应用，导致上下文耗尽、功能半途而废且缺乏文档；或者在仅完成部分功能后误判项目已完成。 解决方案的具体实施 环境初始化：Initializer agent 会创建关键的基础设施，包括： init.sh 脚本：用于启动开发环境。 claude-progress.txt 文件：记录Agent 的操作日志。 初始的 git 提交：建立版本控制基础。 功能列表（Feature List）：创建一个包含详细需求的 JSON 文件（例如 claude.ai 克隆项目包含 200 多个功能点）。选择 JSON 而非 Markdown 是为了防止模型意外覆盖文件结构。 增量工作流与状态管理 快速上手（Getting up to speed）：Coding agent 在每个会话开始时执行标准化步骤： 运行 pwd 确认工作目录。 读取 git 日志和进度文件以了解最近的工作。 读取功能列表，选择优先级最高且未完成的功能。 运行 init....

2025 年 11 月 25 日，Anthropic 正式发布了 Claude Opus 4.5 ，这是目前在编程、智能体（Agent）协作以及计算机操作领域最先进的模型。它在处理深度研究、幻灯片制作和电子表格等日常任务上也有显著提升，代表了 AI 系统能力的又一次飞跃。 关键细节 卓越的编程与推理能力 超越人类的测试成绩：在 Anthropic 内部用于招聘的高难度工程测试中，Claude Opus 4.5 在 2 小时的时间限制内，得分超过了以往所有的人类候选人。 基准测试提升：在 Terminal Bench 测试中，该模型比 Sonnet 4.5 提升了 15% ；在 Excel 自动化任务中，准确率提升了 20% ，效率提升了 15% 。 创造性解决问题：在 $\tau$-bench 测试中（模拟航空公司客服），模型展示了极高的灵活性，通过“先升舱再改签”的合规策略解决了看似无法处理的修改航班请求，体现了深度的推理能力。 成本效益与开发工具 定价与获取：开发者现在可以通过 API 使用 claude-opus-4-5-20251101 ，定价为每百万 token $5 / $25 ，这使得 Opus 级别的能力更加普及。 效率提升：在处理长程编程任务时，该模型可节省高达 65% 的 token 用量。工具调用错误和构建错误减少了 50% 到 75% 。 新的控制参数：API 新增了 “effort parameter” （努力程度参数），允许开发者在速度/成本与极致性能之间进行权衡。在最高设定下，其表现超出 Sonnet 4.5 4....