前几天，Anthropic 团队分享了一篇文章，总结了他们内部使用 Claude Code 的经验，特别是关于 “Skills”（技能）的使用心得。我觉得这篇文章非常有启发性，不仅介绍了 Skills 的各种类型，还给出了很多编写好 Skill 的建议。 下面是这篇文章的中文翻译（略有删改）。 在 Claude Code 中，Skills 已经成为最常用的扩展方式。它们非常灵活、容易制作，分发起来也很简单。 但是，这种灵活性也带来了一个问题：不知道怎么用才是最好的。什么样的 Skill 值得开发？写好一个 Skill 的秘诀是什么？什么时候该把它们分享给其他人？ 在 Anthropic 内部，我们在大规模使用 Claude Code 的 Skills，目前有数百个在活跃使用中。下面就是我们在开发中总结出的一些经验。 什么是 Skills？ 如果你对 Skills 还不熟悉，建议先阅读官方文档，或者观看我们的最新教程。本文假设你已经对它有所了解。 关于 Skills，最常见的一个误解是：它们"只是 Markdown 文件"。但其实最有趣的地方在于，它们不仅是纯文本，还是一个完整的文件夹，可以包含脚本、静态资源、数据等等。AI 代理（agent）可以发现、探索并操作这些内容。 在 Claude Code 中，Skills 还有非常丰富的配置选项，甚至可以注册动态的 hook（钩子）。 我们发现，最有趣的一些 Skills，正是创造性地结合了这些配置选项和文件夹结构。 Skills 的常见类型 我们把内部的所有 Skills 梳理了一遍，发现它们基本上可以归为以下几类。最好的 Skills 通常只专注于其中一类，而那些让人困惑的 Skills 往往跨越了多个类别。 这并不是一个绝对的列表，但如果你想看看团队内部还缺什么工具，它是一个很好的参考。 1. 库与 API 参考指南（Library & API Reference） 这类 Skill 主要向 Claude 解释如何正确使用某个代码库、CLI 或 SDK。它们既可以针对内部私有库，也可以针对 Claude 容易出错的一些公共库。这类 Skill 通常包含一个参考代码片段的文件夹，以及一份列出各种"坑"的清单，让 Claude 在写代码时避开。 ...

名词解释 ADK: Agent Development Kit（Agent 开发工具包） 最近使用 AI 写代码用到了很多 SKILL，但是每个人写的 SKILL 都不同，没有一个公共的标准或者模式，最近看到Google Cloud 技术团队的一篇文章，很有启发，翻译成中文，大家可以参考一下。 说到SKILL.md，开发者往往过于关注格式——怎么写YAML、怎么组织目录、怎么遵循规范。但现在已经有30多个Agent工具（比如Claude Code、Gemini CLI、Cursor）都采用了相同的布局，格式问题基本上已经解决了。 现在的挑战是内容设计。规范解释了怎么打包一个Skill，但对Skill内部的逻辑结构完全没有指导。比如，一个封装FastAPI约定的Skill，和一个四步文档生成流水线，虽然它们的SKILL.md文件看起来一模一样，但运作方式完全不同。 通过研究整个生态系统中Skill的构建方式——从Anthropic的代码库到Vercel和Google的内部规范——我们发现了五种反复出现的设计模式，可以帮助开发者构建更好的Agent。 作者 @Saboo_Shubham_ 和 @lavinigam 本文将介绍每种模式，并附带可用的ADK代码示例： Tool Wrapper：让你的Agent瞬间成为任何库的专家 Generator：从可复用模板生成结构化文档 Reviewer：按严重程度对代码进行清单式评分 Inversion：Agent在行动前先采访你 Pipeline：通过检查点强制执行严格的多步工作流 模式1：Tool Wrapper Tool Wrapper让你的Agent按需获取特定库的上下文。你不是把API约定硬编码到系统提示词里，而是把它们打包成一个Skill。你的Agent只在真正用到该技术时才加载这些上下文。 这是最简单的实现模式。SKILL.md文件监听用户提示词中的特定库关键词，动态加载references/目录下的内部文档，并将这些规则视为绝对真理。这正是你将团队内部编码规范或特定框架最佳实践直接分发到开发者工作流中的机制。 下面是一个Tool Wrapper示例，教Agent如何编写FastAPI代码。注意指令如何明确要求Agent只在开始审查或编写代码时才加载conventions.md文件： # skills/api-expert/SKILL.md --- name: api-expert description: FastAPI开发最佳实践和规范。在构建、审查或调试FastAPI应用、REST API或Pydantic模型时使用。 metadata: pattern: tool-wrapper domain: fastapi --- 你是FastAPI开发专家。将这些约定应用到用户的代码或问题中。 ## 核心约定 加载'references/conventions.md'获取完整的FastAPI最佳实践列表。 ## 审查代码时 1. 加载约定参考文件 2. 将用户代码与每个约定进行比对 3. 对每个违反项，引用具体规则并建议修复方案 ## 编写代码时 1. 加载约定参考文件 2. 严格遵循每个约定 3. 为所有函数签名添加类型注解 4. 对依赖注入使用Annotated风格 模式2：Generator Tool Wrapper是应用知识，而Generator则强制产生一致的输出。如果你苦于Agent每次运行都生成不同的文档结构，Generator通过填空式流程解决了这个问题。 ...

Claude Code 开发者的一些使用建议 作者：Boris（Claude Code 的创造者） 译者：Claude 日期：2026年3月17日 我是 Boris，Claude Code 的创造者。我想快速分享一些来自 Claude Code 团队的使用建议。团队使用 Claude 的方式和我个人使用的方式不太一样。记住：使用 Claude Code 没有唯一正确的方式——每个人的配置都不同。你应该多尝试，找到适合自己的方法！ 1. 多任务并行处理 同时启动 3-5 个 git worktree，每个运行独立的 Claude 会话。这是最大的生产力提升点，也是团队的首要建议。就我个人而言，我使用多个 git checkout，但大多数 Claude Code 团队更喜欢 worktree——这正是 @amorriscode 在 Claude Desktop 应用中内置支持 worktree 的原因！ 有些人还会给 worktree 命名，并设置 shell 别名（za, zb, zc），这样一键就能在它们之间切换。还有人专门设置一个"分析" worktree，只用于读取日志和运行 BigQuery。 参考：https://code.claude.com/docs/en/common-workflows#run-parallel-claude-code-sessions-with-git-worktrees 2. 复杂任务先从 plan 模式开始 把精力投入到计划中，让 Claude 一次性完成实现。 有人会让一个 Claude 写计划，然后启动第二个 Claude 以高级工程师的身份审查它。 另一个人说，一旦事情开始偏离轨道，就切换回 plan 模式重新规划。不要硬撑下去。他们还明确告诉 Claude 在验证步骤时进入 plan 模式，而不仅仅是在构建时。 ...

一、引言 最近在用 OpenAI 的 Codex APP，官方发布了一份最佳实践指南。我仔细读了一遍，发现里面有很多实用的建议，特别是对于那些刚开始用 AI 编程工具的人。 总结整理了一下这些经验，分享给大家。如果你也在用 Codex（对于其它AI 编程工具也适用），或者对 AI 编程感兴趣，这篇文章应该能帮到你。 二、核心四要素 .webp) 想让 Codex 准确完成任务，每次提问最好包含这四个部分： 目标：你要改什么或建什么 上下文：相关文件、文档、错误信息（用 @ 提及） 约束：代码规范、安全要求、团队约定 完成标准：测试通过、行为改变、bug 复现消失 任务越复杂，越要提供详细信息。一次说清楚，可以减少很多返工。 三、七个实用技巧  1. 复杂任务先规划 遇到复杂或模糊的任务，先让 Codex 做规划再动手。 可以用 /plan 模式，让它先问清问题再执行。如果你只有个大致想法，可以让它先采访你，把模糊的想法变得具体。 对于大型项目，可以用 PLANS.md 模板来管理（建议使用 planning-with-files skill） 。 2. 创建 AI 使用说明书 可以使用 /init 命令初始化 AGENTS.md 文件，然后再根据自己的需要更新。 在项目中创建 AGENTS.md 文件，写上： 项目结构和重要目录 运行、构建、测试命令 代码规范和审查标准 “完成"的定义 这样 Codex 会自动读取，不用重复说明。 3. 配置个人设置 在 ~/.codex/config.toml 中设置： ...

在使用大模型的过程中，你肯定发现目前的大语言模型（LLM）在逻辑推理、代码编写和文本生成方面表现优异。但是，它们都有一个共同的局限：无法直接干预外部世界。 如果你要求模型“查询订单状态”或“发送一封邮件”，它通常会回复：“对不起，我无法访问您的数据库。”这是因为模型本质上只是一个预测下一个 Token 的概率模型，并没有直接访问系统资源的权限。 Tool Call（工具调用，也称 Function Calling）的出现，正是为了给模型安装上“手脚”，让它能够通过结构化的方式与外部系统交互。 ## 一、 核心概念：决策与执行分离  理解 Tool Call 的关键在于：模型本身并不执行代码，它只负责决策。 我们可以将其理解为“指挥官”与“执行官”的关系： 模型（决策者）：负责判断“当前需要调用哪个工具”、“需要传入什么参数”。 程序（执行者）：负责运行真实的后端逻辑，如数据库查询、发送邮件、鉴权、限流等。 这种“决策与执行分离”的架构，确保了系统的安全性。模型产生的只是一个 JSON 格式的调用指令，真正的执行权限始终掌握在开发者手中，而不是交给模型。 二、 通用工作流 无论是查询数据（读操作）还是执行动作（写操作），在工程上通常遵循以下五个步骤： 定义工具：开发者向模型描述可选工具的功能（建议使用动词命名，如 get_order_status）及其参数规格（使用 JSON Schema）。 发送上下文：将用户问题与工具清单一并发送给模型。 模型决策：模型判断当前问题是否需要工具。如果需要，它会返回一个结构化的响应，包含工具名、参数及唯一标识符 call_id。 本地执行：程序解析参数，调用真实的 API 或数据库，并获取结果。 生成回答：程序将执行结果回传给模型，模型结合结果生成最终的自然语言回复。 三、 Tool Call Schema 详解 Schema 是模型与程序之间的“契约”。定义得越严谨，模型调用的准确率就越高。 1. 结构示例 { "type": "function", "function": { "name": "get_order_status", "description": "根据订单号查询订单状态与物流信息", "parameters": { "type": "object", "properties": { "order_id": { "type": "string", "description": "订单号，例如 1001" } }, "required": ["order_id"], "additionalProperties": false }, "strict": true } } 2. 字段含义与最佳实践 字段 说明 最佳实践 name 工具的唯一标识符 使用动词式命名，如 get_order_status description 工具的用途说明 越详细越好：说明适用场景、限制条件及返回格式 parameters 参数定义 每个参数都应包含 type 和 description required 必填参数名数组 明确模型必须提供的字段 additionalProperties 额外参数 设为 false，防止模型生成多余参数 strict 严格模式 设为 true，强制模型输出符合 Schema 的 JSON 3. 一个“好”的描述长什么样 差的描述： ...

Git Worktree：多分支并行开发的利器 Git 的分支功能很强大，但实际开发中经常遇到一个问题：需要在同一时间处理多个任务，比如主分支有紧急 Bug 要修，同时又想在一个新分支上做重构。这时传统的 git checkout 会让你陷入 stash、切换、再 pop 的循环，环境重建也很麻烦。 [ Git 2.6 引入了 git worktree 命令，它允许一个 Git 仓库对应多个工作目录，每个目录可以检出不同的分支，实现真正的并行开发。 什么是 Worktree？ 简单说，Worktree 就是一个仓库的多个「分店」。它们共享同一个 .git 目录（包含所有分支历史、提交记录），但拥有独立的文件系统和工作环境。 仓库.git（共享） ├── 主工作树（main 分支） ├── ../feature/（feature 分支） └── ../bugfix/（bugfix 分支） 这样，你可以在不同目录同时编辑不同分支，互不干扰。 核心区别 特性 普通分支 Worktree 工作目录 单一目录，切换分支需 checkout 多个独立目录同时存在 环境隔离 切换分支需重建 node_modules 等 各树独立环境 并行开发 需要 stash 保存变更 无需 stash，直接并行 存储开销 只占指针空间 共享 .git，只复制工作文件 这些差异让 worktree 特别适合一台机器上并行开发多个功能。 基本使用 1. 创建 Worktree 在主仓库执行： # 基于现有分支创建 git worktree add ../feature-branch feature-branch # 创建新分支并检出 git worktree add ../new-feature -b new-feature 创建后，你得到一个新目录 ../feature-branch/，里面是 feature-branch 分支的完整工作树，主目录保持不变。 ...

 如何从 0 实现一个极简 Agent 这两年大家一提 Agent，脑子里很容易浮现出一个“会思考、会规划、会调用工具、还会自我修复”的高级智能体。听起来很玄，但如果把那些花哨概念都剥掉，一个能跑起来的极简 Agent，其实没有那么复杂。 说到底，它就两件事： 一个持续运行的 while 循环。 一套精心设计的上下文工程。 大模型本身既没有状态，也没有手脚。它只负责在当前上下文里做判断：这轮该说话，还是该调用某个工具；如果调用工具，工具名是什么，参数应该怎么填。真正读文件、执行命令、写入内容、保存记忆、控制权限的，都是你写的程序。 所以 Agent 的核心从来不是“让模型像人一样思考”，而是：如何把合适的信息在合适的时机交给模型，再把模型的决策稳稳地落到执行环境里。 这篇文章就结合我手头这套玩具代码，从 0 到 1 拆一下：如何把一个看起来很复杂的 Agent，拆成几个可以逐步实现的小能力。 先讲结论：Agent 的最小闭环是什么？  一个最小 Agent，至少要有下面这条闭环： 用户提出任务 -> 模型判断是否需要工具 -> 程序执行工具 -> 把执行结果回填给模型 -> 模型继续决策 -> 直到模型不再调用工具，输出最终答案 这个流程也可以写成更工程化一点的五步： 定义工具，并用 JSON Schema 描述参数约束。 把用户消息、系统提示词、工具清单一起发给模型。 模型返回普通文本，或者返回 tool_call。 程序解析 tool_call，在本地执行真实工具。 将工具结果作为 tool 消息带回模型，进入下一轮。 只要这条链打通，一个最简 Agent 就已经成立了。 为什么说本质是 while 循环？ 因为 Agent 和普通聊天机器人的根本区别，不在于“更聪明”，而在于“能继续行动”。 普通聊天模型通常是一次请求、一次回复，停在那里。Agent 则是在程序外面再包一层循环，让它可以不断经历： Think -> Act -> Observe -> Think 这在代码里其实非常朴素。simple-agent.py 里就是典型的双层循环： ...

coding planning 价格对比 厂商 计划名称 API类型/功能 定价模式 主要特点 适用场景 链接 阿里云 百炼 Coding Plan qwen3-coder-plus 代码生成模型API Lite：7.9元/首月，40元/月 Pro：39元/首月，200元/月 - 兼容OpenAI/Anthropic API规范 - 支持Qwen Code、Claude Code、Cline - 固定月费，月度请求额度 智能编程辅助、多语言代码迁移、企业级软件开发 https://www.aliyun.com/benefit/scene/codingplan 豆包（字节） 方舟 Coding Plan Doubao-Seed-Code 模型API Lite：8.9元/首月，40元/月 54元/首季，120 元/季 Pro：49.9元/首月，200元/月，600 元/季 - 支持Claude Code、Cursor、Cline等5+工具 - 用量达Claude Pro的3倍（Lite）/3倍（Pro） - 一站式开发 中等强度开发任务、复杂项目开发 https://www.volcengine.com/activity/codingplan 邀请码：RNBDFW69 智谱AI GLM Coding Plan GLM-5/GLM-4.7 代码模型API Lite：411 元/年，132元/季49元/月 Pro：1251 元/年，402元/季，149元/月 Max：3939元/年，1266元/季，469元/月 - 支持GLM-5（对标Claude Opus） - 适配20+编程工具 - 免费MCP（联网搜索、图像理解、开源仓库） 轻量级/复杂/海量工作负载，SWE-bench榜单第一梯队 https://bigmodel.cn/glm-coding MiniMax Coding Plan MiniMax M2.1 模型API Starter：9.9元/首月，29元/月 Plus：49元/月 Max：119元/月 - 支持图像理解、联网搜索MCP - 适配9种编程工具 - 邀请好友返利机制 入门级/专业/高级开发场景 https://platform.minimaxi.com/subscribe/coding-plan Kimi（月之暗面） Kimi Claw Kimi K2.5 模型API（通过会员订阅） Andante：49元/月（Kimi Code可调用） Moderato：99元/月（4倍额度） Allegretto：199 元/月 Allegro: 699元/月 - Agent 4倍速优先用 - 支持Kimi CLI、Kimi Code - 连续包年立省240元 高频Agent调用、快速开发 https://www.kimi.com/membership/pricing 阿里百炼 ...

The 40-Year Evolution of RPC: From Simple Procedure Calls to Modern Microservices The 40-Year Evolution of RPC: From Simple Procedure Calls to Modern Microservices Executive Summary Remote Procedure Call (RPC) has been a fundamental paradigm in distributed computing for over four decades. This article traces its evolution from simple client-server communications to modern microservices architecture, examining key developments, challenges, and the ongoing debate between developer convenience and system correctness. Through this historical lens, we’ll understand why RPC remains relevant in today’s cloud-native world. ...

深入探讨字符串和 JSON 对比技术：多语言实现指南 为什么字符串和 JSON 对比如此重要？ 在讨论具体技术之前，我们先来看看为什么这个话题如此重要。在软件开发中，我们经常需要比较两个版本的文本或数据结构。这可能是为了： 版本控制：跟踪代码或配置文件的变化。 数据同步：确定需要更新的数据部分。 差异化展示：在用户界面上直观地显示变更。 调试和测试：快速识别系统行为的变化。 正确的对比技术可以极大地提高开发效率，减少错误，并为用户提供更好的体验。现在，让我们探讨各种实现方法。 字符串差异比较 Python 实现：使用 difflib Python 的 difflib 模块是一个强大而灵活的工具，适合各种文本比较任务。让我们看一个详细的例子： import difflib def string_diff(string1, string2): """ 比较两个字符串并以类似 git diff 的格式输出差异 """ diff = difflib.unified_diff( string1.splitlines(keepends=True), string2.splitlines(keepends=True), fromfile='原始文本', tofile='新文本', n=0 # 上下文行数，设为0只显示变化的行 ) for line in diff: if line.startswith('+'): print(f"\033[92m{line}\033[0m", end='') # 绿色显示新增行 elif line.startswith('-'): print(f"\033[91m{line}\033[0m", end='') # 红色显示删除行 elif line.startswith('^'): print(f"\033[94m{line}\033[0m", end='') # 蓝色显示变化位置 else: print(line, end='') # 示例使用 str1 = "Hello, World!\nThis is a test string.\nGoodbye!" str2 = "Hello, World!\nThis is a modified test string.\nSee you later!" print("原始文本:") print(str1) print("\n新文本:") print(str2) print("\n差异:") string_diff(str1, str2) 这个实现有几个值得注意的特点： ...