提供全面的AI开发指导：
深入探索 Claude Code 的高级功能：MCP 协议扩展外部工具、Hooks 自动化工作流、SubAgent 多智能体并发、CLAUDE.md 项目规范配置。从原理到实战，让你真正掌握这个强大的 AI 编程工具。
Andrej Karpathy提出的Vibe Coding正在成为现实：你不再写代码，而是用自然语言描述需求，AI来实现。这不是未来，这是现在。问题是：你准备好了吗？
上周三下午,我同时开着四个东西:Cursor 里一个 agent 在改重构,终端里 Claude Code 在跑测试,GitHub 上一个 Copilot 后台 agent 在处理我早上随手丢过去的 issue,还有一个 Cursor 云端 automation 在等 CI 结果。我本人那段时间在干嘛?在看 Linear 上的工单,决定下一个派给谁。 我没写一行代码。但那个下午合并了五个 PR。 这不是什么"未来已来"的感慨。这是 2026 年 5 月一个普通工程师的普通下午。半年前——也就是 2025 年底——我的工作方式还不是这样。那时候 AI 编程工具的主流形态是"一个很聪明的补全",你在编辑器里写代码,它帮你接下一段。现在,补全这件事我几乎已经感觉不到它的存在了,因为我的注意力整个挪到了别处。 这半年到底发生了什么,值得拆开看看。 三级跳:补全 → 终端 agent → 后台 agent 如果要给 AI 编程工具这半年画一条线,它是这样三级跳的: flowchart LR A[代码补全2023-2024] --> B[IDE 内 agent2025] --> C[终端 agent2025 下半年] --> D[后台/云端 agent2026] style A fill:#e8e8e8,stroke:#999 style B fill:#fde7c2,stroke:#e8b23c style C fill:#fde7c2,stroke:#e8b23c style D fill:#c2e0fd,stroke:#3c8ce8 第一级是补全:Copilot 那套,光标后面灰字提示,你按 Tab 接受。这个形态决定了一件事——AI 是你的副驾驶,方向盘还在你手里,你得一直盯着路。 ...
一个用 AI 写代码的开发者,现在一天能开五六个 PR。 而审你 PR 的那个人,一天还是只能审五六个。 这两个数字凑在一起,就是 2026 年大多数工程团队真正的麻烦。Faros AI 的数据里,高 AI 使用率的团队完成的任务多了 21%、合并的 PR 多了将近一倍,但 PR 的 review 时长涨了 91%——而且那些 PR 还更大。Opsera 一份覆盖 25 万开发者的报告说得更直白:在没有治理的情况下,AI 生成的 PR 在 review 队列里等的时间是普通 PR 的 4.6 倍,哪怕从写完到提 PR 的时间砍掉了一半多。 写代码这件事,被 AI 解决了一大半。审代码这件事,一点没变。瓶颈就这么从「写」挪到了「审」,而且大多数团队还没意识到。 为什么 AI 写的代码,审起来反而更难 直觉上,AI 代码该更好审才对——它风格统一、不会忘加分号、命名规规矩矩。但真审过 AI 大批量产出的代码的人都知道,事情反过来了。AI 代码难审,难在三个地方。 第一,它看着太合理了。 人写错代码,常常会留下「破绽」——变量名词不达意、缩进乱、注释和代码对不上,这些视觉信号会让 reviewer 警觉。AI 不会。AI 写的错误代码,长得和正确代码一模一样:命名得体、结构清晰、注释贴心。CodeRabbit 的研究说 AI 写的代码暴露的问题比人写的多 1.7 倍,而这些问题里相当一部分是逻辑错误——业界一个被反复引用的说法是,AI 代码的纯逻辑错误率比人高约 75%。一个长得人模人样的函数,你的大脑会默认它没问题,于是真正的 bug 藏在「看着合理」的外壳里溜过去了。 第二,量。 一个 reviewer 以前一天面对的是三五个 PR、每个两三百行。现在是十几个 PR,而且单个更大。注意力是有总量的——审第一个 PR 时你逐行读,审到第八个时你已经在「扫」。Review 质量不是匀速下降的,是过了某个阈值之后断崖式塌掉的。量本身就是一种攻击。 ...
先说一个反常识的事:大多数团队的"第一个 LLM 网关"不是装出来的,是不知不觉写出来的。 最初你的代码里只有一句 openai.chat.completions.create()。后来 OpenAI 半夜抽风,你在外面包了个 try/except,失败就调 Anthropic。再后来财务问"这个月十几万的 token 花在哪了",你又加了一段记账逻辑。再后来某个客户的流量把你的限额打爆,你又写了个令牌桶。 这些 if/else 散在三个仓库、五个文件里,没人敢动。这就是网关——一个没有名字、没有人维护、谁碰谁倒霉的网关。 所以问题从来不是"要不要 LLM 网关",而是"这层东西,是攒成一坨烂代码,还是收拢成一个能被维护的组件"。这篇就讲清楚:它到底该管什么、自建还是用现成、路由策略怎么定,以及它本身会带来什么麻烦。 网关到底替你扛了什么 把它想成 LLM 调用的反向代理:你的应用只跟网关说话,网关再去跟一堆模型供应商打交道。它该扛七件事,但这七件事的优先级差得很远。 能力 解决什么 优先级 统一 API 一套 OpenAI 格式的接口调所有模型,换模型不改业务代码 必须 故障转移 某家供应商挂了 / 限流了,自动切到备用 必须 密钥管理 上游真 key 收在网关,业务侧只发"虚拟 key" 必须 限流配额 按 key、按团队、按租户限 QPS 和预算 高 成本核算 每次调用算钱,按业务线 / 用户出账单 高 可观测 全量请求日志、延迟分位、错误率、token 用量 高 缓存 命中过的请求直接返回,省钱省延迟 看场景 前三个是"接了第二个模型就立刻需要"的。中间三个是"上了生产、有了多个调用方"之后绕不开的。最后一个——缓存——别一上来就上,后面单独说。 统一 API 是地基。2026 年的事实标准是 OpenAI 的 /v1/chat/completions 格式:几乎所有网关都对外讲这套协议,对内再翻译成 Anthropic、Gemini、Bedrock、火山引擎、通义各自的方言。好处很直接——你的业务代码里不该出现任何一家供应商的 SDK,只有一个 base_url 指向网关。换模型这件事,从"改代码、过测试、发版"变成"网关上改一行配置"。 ...
先说一个数字:同样问"帮我查一下这个 bug",发给聊天机器人和发给 Agent,token 消耗能差 50 倍。 聊天机器人就一来一回:你发一段、它回一段,结束。Agent 不一样——它跑的是一个循环:看任务、调工具、读文件、改代码、再检查。循环里的每一步,都要把到目前为止积累的全部上下文,重新发给模型一次。 这就是 Agent 账单的根源。2026 年有人审计了 30 个在生产环境跑 Agent 的工程团队,一个 20 人的团队,单月 API 账单能冲到 11 万美元;用 Claude Code 或 Cursor 这类编码 Agent 的开发者,人均每月 400 到 1500 美元,失控的案例几天就烧掉 4000 美元以上。 更要命的是,这笔钱不是匀速烧的。Demo 跑得好好的,一上量就爆——大部分企业的 Agent 项目,在大规模铺开后的头 90 天里,实际花销会超出试点预算 4 到 11 倍。所以做 Agent,成本不是上线之后再优化的事,是设计时就得算进去的一笔账。 这篇把这笔账拆开:钱花在哪、怎么找到大头、有哪些真能省的手段、怎么设预算和熔断、怎么监控。 钱到底花在哪 先建立一个最反直觉的认知:Agent 跑一个任务的成本,主要不是输出,是输入。 模型 API 按 token 收费,输入和输出分开计价。聊天场景里,大家盯着输出看。但 Agent 不一样,它的成本大头在输入侧的重复计费。 为什么?因为对话历史会"滚雪球"。Agent 每调一次工具,就要把整段对话历史连同工具返回的结果,一起再发一次。一段已经积累到 10 万 token 的上下文,在后续每一次调用里,都按 10 万输入 token 收费——不是只收新增的那部分。一个跑到第 20 步的编码 Agent,光是文件读取塞进来的内容,单步输入就能超过 5 万 token,按 Sonnet 4.6 的价(每百万输入 token 3 美元)算,每一步 0.15 美元,二十步就是 3 美元,而这还只是一个任务。 ...
2025 年 7 月,METR 做了一个实验。16 个资深开源开发者,每人在自己熟得不能再熟的项目里干活,平均经验 5 年。246 个真实任务,随机分两组:一组允许用 AI(主要是 Cursor Pro 配 Claude 3.5/3.7),一组不许用。 实验前,这些人预测 AI 能让自己快 24%。干完之后,他们体感觉得 AI 让自己快了 20%。 实测结果:用 AI 的那组,慢了 19%。 这不是一个标题党段子。它是目前为止设计最干净的一个随机对照实验,而它的结论,跟你每天在朋友圈、在发布会、在融资 PPT 上看到的"10x 工程师"“生产力革命”,是相反的。 所以这篇文章想认真聊一件事:AI 编程到底是不是泡沫。我的答案会比较啰嗦——它在某些环节是真东西,在另一些环节是被吹大的气球,而把这两件事混在一起卖,才是真正的泡沫所在。 营销数字和实测数字,差在哪 先把两组数字摆出来。 营销侧的数字很漂亮:2026 年 84% 的开发者在用 AI 工具,AI 写了 41% 的新增商业代码,人均每周省下 3.6 小时。受控实验里,对那种"写一个函数"“生成一批单测"“铺一段样板代码"的细碎任务,提速 30%–55% 是常见的。 这些数字没造假。问题在于它们都是任务级的数字——把镜头怼到"写代码"这一个动作上,AI 确实快。 但你把镜头拉远到组织级,画面就变了。2025 年的 DORA 报告(Google 做的那份,样本是几千个真实团队)给出的结论很扎心:AI 让个人产出明显上涨——任务完成数 +21%,合并的 PR 数 +98%——但团队的交付速度,基本是平的。同一份报告里,AI 采用度和软件交付稳定性是负相关的。 更具体的两个数字:每个开发者引入的 bug 数,涨了 54%(过去的数据集里这个数字只涨 9%);每个 PR 引发生产事故的概率,涨了 242.7%——也就是说,每合一次代码,捅出线上事故的概率翻了三倍多。 看哪个层面 数字 谁在引用 任务级:写一个函数 提速 30%–55% 厂商、发布会 个人级:周产出 PR +98%,任务 +21% 厂商、个人体感 组织级:交付速度 基本持平 DORA 2025 组织级:稳定性 bug +54%,事故/PR +242% DORA 2025 资深 + 成熟项目 慢 19% METR RCT 同一件事,你站在不同的距离看,能得出完全相反的结论。营销永远站在最近的那个位置拍照。 ...
先说一个数字:Guardrails AI 在 2025 年初做过一次基准测试,结论里有句话很刺眼——单个护栏哪怕准确率有 90%,串五个,误杀率就到 40%。 这句话基本能概括做护栏的全部难处。你不是在"加保护",你是在一条已经够慢、够贵、够不确定的链路上,再叠一层会拖慢、会误判、还得自己维护的东西。问题不是"要不要护栏"——上线的 LLM 应用一定要有——问题是护栏管什么、做多厚、放哪一层。这三件事做错,护栏要么形同虚设,要么把好用户也一起赶跑了。 这篇不讲注入攻击的具体手法(那是另一篇的事),讲更宽的一件事:把用户的输入、模型的输出当成两道关口,这两道关口该怎么修。 护栏到底在拦什么 很多团队上来就装个 moderation API,以为护栏就是"过滤脏话"。不是。护栏分两侧,两侧拦的东西完全不一样。 输入侧,拦的是用户递进来的东西: 敏感信息。用户在对话里贴了身份证号、银行卡、内部工号、客户手机号。你不想把这些原样喂给第三方模型 API,更不想它们出现在日志里。 越界请求。一个做企业财报问答的 Bot,用户问"帮我写一首失恋的诗"。这不危险,但它不是这个产品该干的事——回答了,就是在替竞品做免费体验。 明显的恶意输入。攻击意图、自动化刷量、超长 prompt 灌爆上下文。 输出侧,拦的是模型吐出来的东西,这一侧更难,因为输出是模型生成的、不可预测的: 有害内容。暴力、仇恨、自残、违法信息。这是最经典的一类,也是 moderation API 唯一管得好的一类。 幻觉。模型一本正经地编了一个不存在的退款政策、一个错误的药品剂量。在 RAG 场景里,这意味着输出和检索到的资料对不上。 格式错误。你要的是一段能直接 JSON.parse 的结构化数据,模型给你前面加了句"好的,这是您要的结果:"。下游程序当场崩。 品牌口径。模型说了"我们的竞品确实更便宜",或者用了一个法务明令禁止的承诺词(“保证收益"“绝对安全”)。没毒,但能上财经新闻。 注意最后两类——格式和品牌口径——很多人根本不把它当护栏。但它们恰恰是上线后最高频出事的地方。有害内容一年可能出一次,格式错误一天能出一百次。 四种做法,从便宜到贵 护栏不是一种技术,是一个工具箱。按"成本/能力"从低到高,有四档。 第一档:规则与正则。 关键词黑名单、正则匹配身份证/手机号、长度限制、JSON schema 校验。便宜到几乎不要钱,延迟个位数毫秒,而且结果可解释——你能准确说出"它是因为命中了第几条规则被拦的”。缺点也明显:绕得过,且管不了语义。规则适合拦"形状固定"的东西:PII、超长输入、明确的禁用词。 第二档:专门的分类模型。 这是 2026 年的主力。Meta 的 Llama Guard 是一个专门微调出来的输入输出安全模型,自带六大类不安全分类,还能自定义类目;OpenAI 的 omni-moderation-latest 免费、能同时分类文本和图像。它们的关键优势是快——一个专用 guard 模型跑一次大约 29 毫秒,而拿一个大模型当审查员要 5 到 11 秒。但要清楚它们的边界:OpenAI moderation 只做内容分类,不查注入、不查幻觉、不做 PII 脱敏。它是基线,不是全部。 第三档:用 LLM 审查 LLM。 让另一个模型(或同一个模型换个 prompt)去判断"这条输出有没有问题"。最灵活,能处理"品牌口径"“答非所问"这种规则和分类器都搞不定的模糊判断。代价是它慢且贵——等于每个请求多一次完整的 LLM 调用,延迟翻倍,成本也翻倍。LLM 审查适合留给"少量、高风险、规则写不出来"的判断。 ...
先说结论 场景 推荐 公司统一采购 GitHub Copilot 个人开发追求效率 Cursor 复杂项目重构 Claude Code 学生党/尝鲜 都试试，反正有免费版 下面说说为什么。 GitHub Copilot：稳 优点： 和VS Code集成最好，不卡 企业合规，公司一般都愿意买单 代码补全中规中矩，不会出太离谱的东西 缺点： 对整个项目的理解不如Cursor 有时候补全太保守，不敢写多 适合谁： 大厂员工、需要合规的团队 Cursor：快 我现在主力用Cursor。 为什么？ Tab补全太爽了。它能预测你下一步要改哪个文件、哪一行，按Tab就跳过去了。用久了回不去普通IDE。 对代码库理解深。问它"这个项目怎么加个新API"，它真的会去翻代码，不是瞎编。 Composer模式。告诉它"帮我重构这个模块"，它能同时改好几个文件。 缺点： 有时候太激进，改得多你得仔细review 月费$20，不便宜 适合谁： 追求效率的老手、个人开发者 Claude Code：聪明 Claude Code是后来者，但确实有点东西。 亮点： 理解能力最强，复杂逻辑描述清楚它就能写对 解释代码特别清楚 处理大项目上下文比较好 缺点： 速度比Cursor慢一点 还在迭代，功能没那么完善 适合谁： 需要处理复杂项目、喜欢AI帮忙想方案的人 我的使用习惯 日常写代码：Cursor 遇到复杂问题：切到 Claude Code 聊两句 公司项目：用公司配的 Copilot 不冲突，看场景切换就行。 一点建议 别把AI编程工具当"代码生成器"，把它当"结对编程的同事"。 它写的代码你得review 它不懂的地方你得教它（给上下文） 它写错了跟它说，它会改 用好了效率能提升2-3倍，用不好反而添乱。 有问题留言，我看到会回。
开场：不是Copilot，是Coder 2025年，AI编程工具已经卷到飞起。Cursor、Windsurf、GitHub Copilot……每个都说自己是"最强AI编程助手"。 但当我第一次用上 Claude Code 时，我意识到： 这玩意儿不是来"辅助"我写代码的，它是来替我干活的。 Claude Code 是 Anthropic 推出的命令行AI编程工具。它不是IDE插件，而是一个独立运行在终端里的Agent。你给它一个任务，它会： 自己读代码 自己写代码 自己跑命令 自己修Bug 自己提交PR 这才是2025年该有的AI编程体验。 1. 安装：30秒上手 1 2 3 4 5 6 7 8 # 全局安装 npm install -g @anthropic-ai/claude-code # 进入项目目录 cd your-project # 启动 claude 首次启动会要求登录 Anthropic 账号，授权后就能用了。 费用：使用 Claude API 计费，Claude Sonnet 大约 $3/百万token，正常使用一天几毛钱。 2. 核心能力：不只是聊天 2.1 自主文件操作 Claude Code 可以直接读写你的项目文件： 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 You: 帮我看看 src/api/user.ts 里有什么问题 Claude: 我来读取这个文件... [读取 src/api/user.ts] 发现了几个问题： 1. 第23行：缺少错误处理 2. 第45行：类型定义不完整 3. 第67行：存在潜在的内存泄漏 要我修复吗？ You: 修 Claude: [编辑 src/api/user.ts] 已完成修复，主要改动： - 添加了 try-catch 包装 - 补充了 UserResponse 类型定义 - 在 useEffect 中添加了 cleanup 函数 2.2 执行Shell命令 它能直接在你的终端跑命令： ...
开场：同样的问题，天差地别的回答 先看一个真实场景： ❌ 普通人的提问： “帮我写一篇文章” AI回答：好的，请问您想写什么主题的文章？（然后开始无尽的追问…） ✅ 高手的提问： “你是一位资深科技博主。请用轻松幽默的语气，写一篇800字左右的文章，介绍AI编程助手（如Cursor、Copilot）如何改变程序员的工作方式。文章需要包含：1个生动的开场故事、3个具体的使用场景、1个数据对比、结尾的行动号召。” AI回答：直接输出一篇结构完整、语气生动、可直接发布的高质量文章。 这就是提示词工程的魔力。 第一章：CRISP框架 —— 黄金提示词公式 我总结了一个简单易记的框架：CRISP 字母 含义 说明 C Context（背景） 告诉AI"你是谁"和"场景是什么" R Role（角色） 让AI扮演专家身份 I Instructions（指令） 清晰的任务描述 S Specification（规格） 输出的格式、长度、风格 P Proof（示例） 给出1-2个例子（Few-Shot） 实战模板 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 # 背景 (Context) 我正在为技术博客写一篇关于[主题]的文章，读者是有一定编程基础的开发者。 # 角色 (Role) 你是一位拥有10年经验的资深技术作家，擅长用通俗易懂的语言解释复杂概念。 # 指令 (Instructions) 请帮我撰写这篇文章，要求： 1. 开头用一个真实案例或故事引入 2. 核心内容分为3-4个要点 3. 每个要点配有代码示例 4. 结尾总结并给出行动建议 # 规格 (Specification) - 字数：1500-2000字 - 语气：专业但不枯燥，适当加入幽默 - 格式：Markdown，使用代码块、列表、表格 # 示例 (Proof) 类似风格的文章参考：[给出一段示例文字] 第二章：Chain of Thought —— 让AI学会思考 核心原理：不要让AI直接给答案，让它先"想一想"。 ...
为什么要本地部署？ 在云端API满天飞的2025年，为什么还要本地部署大模型？ 理由1：隐私安全 你的代码、文档、聊天记录……全都发给了云端。 1 2 3 4 敏感场景： - 公司内部代码 → 发给OpenAI？ - 医疗病历数据 → 发给云端？ - 法律合同文本 → 谁来保证不泄露？ 本地部署 = 数据永远不出你的电脑。 理由2：成本控制 使用场景 云端API成本 本地部署成本 每天1万次调用 ~$300/月 电费 ~$30/月 7B模型长期使用 持续付费 一次性硬件投入 团队10人使用 $200+/人/月 共享一台服务器 理由3：低延迟 云端API：网络往返 100-500ms 本地部署：几乎零延迟 理由4：自由定制 想微调？随便调 想改提示词模板？自己改 想限制输出长度？随心所欲 硬件要求 最低配置（跑7B模型） 1 2 3 4 5 CPU：8核以上 内存：16GB 显卡：8GB显存（如RTX 3070） 或 Apple M1/M2/M3（统一内存） 存储：50GB SSD可用空间 推荐配置（跑13B-70B模型） 1 2 3 4 5 CPU：12核以上 内存：32GB+ 显卡：24GB显存（如RTX 4090） 或 Apple M2 Pro/Max/Ultra 存储：200GB SSD可用空间 显存 vs 模型大小速查表 模型大小 最低显存 推荐显存 代表模型 3B 4GB 6GB Phi-3 Mini 7B 6GB 8GB Llama 3.1 7B, Qwen2.5 7B 13B 10GB 16GB Llama 3.1 13B 34B 20GB 24GB CodeLlama 34B 70B 40GB 48GB Llama 3.1 70B 注：使用量化（Q4/Q5）可降低约50%显存需求。 ...