Claude 中文知识站

说实话，去年这个时候我对 Claude 其实挺无感。那时候大家都在 ChatGPT 和 Gemini 里左右横跳，偶尔听到有人吹 Claude 的长上下文，我点进去试两下，觉得也就那样，就又退回 GPT-4 了。 真正让我切过来的契机挺偶然——春节前那阵我在做一个合同解析的私活，原始 PDF 塞进 GPT 之后它经常胡说八道，把”甲方”和”乙方”认反，把日期从 2024 改成 2023。我当时快崩溃了，抱着死马当活马医的态度把同样的东西丢给 Sonnet 4.6，结果它不仅读对了，还主动指出了合同第 14 条的一个歧义条款。 从那天开始，我把 API Key 环境变量换了过来，到现在三个月整。这篇文章不想讲模型参数、跑分榜单——那些东西知乎和 X 上已经写烂了。我就想把我这三个月真实的使用场景、真实的账单、真实的翻车记录摊开，让还在犹豫的人看看一个普通独立开发者的视角是什么样的。 一、先把账单摊开：三个月花了多少钱很多文章讲”性价比”讲得天花乱坠，但从来不给具体数字。我给你看我的： 1 月：$43.20，主要是合同解析那个项目收尾 2 月：$78.50，开始做一个小型的内容生成...

Q2 这三个月我机器上同时挂着三家 API——Anthropic、OpenAI、Google。每次有新项目启动，我都会用这三家分别跑一轮同样的任务，看哪家合适就用哪家做主力，其余两家备着。 这篇文章不是那种”看完就能做决策”的权威指南——我也做不到，任何说自己能做到的人都是在忽悠你。不同场景、不同预算、不同风险偏好，最优解完全不一样。这里只讲我自己在 Q2 的真实使用感受，分六个场景讲，每个场景给一个倾向性选择，最后给一套混搭方案。 先把三家这季度的旗舰摆出来： Claude Opus 4.7：Anthropic 最新，强在 Agent 和代码 GPT-5.4：OpenAI 在多模态和生态上追回来了 Gemini 3.1 Pro：Google 的长上下文 + 原生多模态还是最强 下面按场景拆。 场景一：写代码这个我打得最多——过去三个月三家都让我写过中等复杂度的 Python/TypeScript 项目。 我的倾向：Claude Opus 4.7（但 Sonnet 4.6 性价比更高） 理由很简单：Claude 在”理解现有代码、做克制修改”这件事上依然领先。GPT...

第一次用 Claude Code 的时候，我根本不知道 CLAUDE.md 是干啥的。项目根目录莫名其妙多了个文件，我以为是 Claude Code 的缓存，还一度想把它丢进 .gitignore。 后来在一次协作翻车之后我才意识到这东西有多重要。那次的情况是：我和同事在同一个 repo 里协作，我本地跑 Claude Code 改一个接口改得风生水起，他拉下来跑的时候却发现 Claude Code 一直把代码往完全错误的方向推。排查了俩小时才搞明白——我本地有一份 CLAUDE.md，里面写了一堆项目约定；他没有这份文件（我没 commit），所以他的 Claude 完全不知道这个项目的规矩，只能按通用最佳实践瞎写。 从那天起我开始认真研究 CLAUDE.md。这东西本质上是给 Claude Code 的项目说明书，写得好能让 AI 协作翻倍提效，写得不好能把 AI 带到沟里。这篇把我这半年的经验总结一下。 一、CLAUDE.md 是什么，为什么重要简单说，CLAUDE.md 是 Claude Code 在启动时会自动读入、作为 system context 的一部分注入到模型...

三月底的时候 Anthropic 悄悄发了一版 Agent SDK 1.4，配套文档里第一次把”四层架构”写进去了。之前大家做 Agent 基本都是野路子——谁有经验谁按自己理解搞，抽象到底该切几刀、每刀切在哪儿，全凭个人品味。 我过去一年接过三四个 Agent 项目，踩过的架构坑可太多了。有个项目一开始把工具调用、Prompt 组装、状态管理全塞在一个类里，改到第三个功能的时候那个类已经 2000 多行，谁都不敢动。后来我照着 Agent SDK 的思路重构，砍到四个模块，才算活过来。 这篇文章把 Agent SDK 官方的四层架构拆开讲，每一层我尽量给出接口是什么样、扩展点在哪里、生产上怎么用。如果你正在从零搭一个 Agent，这套骨架可以直接抄。 架构总览：四层是哪四层简单说就是： 应用层（Application）：用户意图、任务定义、UI 对接 Agent 层（Agent）：规划、工具选择、对话管理 运行时（Runtime）：执行循环、重试、超时、熔断 服务层（Service）：模型 API、工具实现、持久化 每一层对下层依赖、对上层提供接口，之间用清晰的数据结构交互...

前两周我跟一个做 Agent 产品的朋友吃饭，他甩给我一句话：”MCP 不就是 Function Calling 换了个皮吗？我们已经有 tool use 了，整这个 MCP 协议是 Anthropic 在刷存在感吧。” 我当时嘴里正嚼着东西，差点呛住。这误解在开发者圈里太常见了，甚至连一些写过相关代码的人也会这么觉得。但如果你真的在生产环境里把两种方式都用过，就会明白它们差的不是一点半点——维度根本不一样。 Function Calling 是工具；MCP 是给工具定一个标准插口。你可以说螺丝刀和螺丝的规范是一回事吗？当然不是。 这篇我想把五个最本质的差异一条一条拆给你看，最后说说实际项目选型怎么想。 差异一：协议层 vs 应用层这是最根本的一条，想通了这一点其它四条都顺了。 Function Calling 是 OpenAI 2023 年 6 月发的一个 API 特性，它的本质是：模型输出结构化 JSON，你的应用代码去执行。Anthropic、Google、阿里、智谱……现在都有自己的 tool use / function calling API，但注意——这是...

这个项目的起因特别真实——我老婆是她们公司市场部负责人，某天晚上她一边改文案一边叹气：”这个实习生又把 B 端产品的官网 banner 写成了小红书卖货文案的语气，产品经理又发火了。” 我随口问了一句：”你们公司没有品牌 tone & manner 手册吗？” 她一脸苦笑：”有啊，一份 40 页的 PDF。谁会每写一条文案就翻一遍？” 就这一句话点醒我了。这不就是 Claude Skills 完美适配的场景吗？——一套规则、需要严格遵守、人类执行起来很累、但对 AI 来说只是 reading task。那晚我就开始动手，花了大概两周（零碎时间）做了一个「品牌文案专家」Skill。现在她们市场部三个人日常都在用，实习生再也没犯过低级错误。 这篇想完整记录这个事儿——从需求分析到 SKILL.md 落地到上线后的反馈，给正在想给业务团队做 AI 工具的同学一个参考。 一、这个需求到底是个什么问题先说清楚她们公司的情况。公司主营两条产品线： A 产品：给金融机构的合规审计 SaaS，B 端、客单价百万级、买家是银行风控总监。官网、白皮书、案例都要”稳重、专业、权威” B 产品...

这事儿是我去年底帮一个法律科技公司做合同条款抽取时遇到的。他们要从合同里抽出 “甲方名称 / 乙方名称 / 合同金额 / 签订日期 / 违约条款” 这五个字段，然后入库。 我一开始写的 prompt 是很标准的 Markdown 风格： 12345678910111213## 任务从下面的合同文本中抽取指定字段。## 要求- 返回 JSON 格式- 找不到的字段返回 null- 金额统一转成人民币数字## 合同文本（此处插入合同 3000 字）## 输出字段party_a, party_b, amount, date, penalty_clause 跑了 500 个样本，准确率 71%。老板看完脸色不太好。 我折腾了一下午改 prompt，换措辞、加例子、调顺序，最多也就爬到 75%。然后我想起 Anthropic 官方文档里反复强调的一句话：”Claude was fine-tuned with XML tags.”。我就死马当活马医，把整个 prompt 的结构改成 XML： 123456789101112131415<task...

去年八月我有一个客户项目，每天要处理 3000 多份 PDF 文档，做字段抽取。上线第一周账单直接给我整破防——一周烧了 $780。客户给的预算是一个月 $500，我算了下按这速度一个月得 $3300+，项目直接要赔钱。 那时候我正好看到 Anthropic 更新了 Prompt Caching 的文档，抱着试试的心态改了几行代码。改完跑了一天，第二天打开账单那一刻我真的惊了——单日成本从 $110 降到 $18。不是看错，是真的降了 83%。 从那天起我就成了 Prompt Caching 的重度用户，这东西在我这儿已经是”每个项目上线前必做的检查项”。这篇文章想把我这一年踩过的坑、摸出来的最佳实践全部摊开，给还没用过的人一个能直接照抄的参考。 一、先把价格结构讲清楚很多文章讲 Prompt Caching 第一句就是”能省 90%”，但不告诉你是在什么条件下省的。先把价格表拉清楚： 以 Claude Sonnet 4.6 为例（Opus 4.7 按比例推算）： 普通 input：$3.00 / MTok cache write（5 分钟 TTL）：$3.75 &#...

说实话这事儿是被运营部门逼出来的。 我们公司有个内部订单系统，MySQL 库里挂着几千万行数据。运营组的小姑娘几乎每天都要问技术：”帮我查一下昨天 XX 渠道的退款单数””帮我拉一下 3 月 GMV 按城市分组”。一开始还好，后来一天能来十几次，我们这边排期排不过来，她那边也急，经常下班前还在等一张报表。 上个月我心一横，花了一个下午给她搭了个 MCP Server，直接让 Claude Desktop 接到内网 MySQL 上。现在她自己用自然语言问，Claude 帮她写 SQL、跑 SQL、甚至画个简单的 Markdown 表格出来。这篇想把整个过程完整写一遍——不是教科书式的”hello world”，是真真正正上了生产、正在跑的那版。 一、为什么选 MCP，不选 Function Calling先澄清一个事儿。这个需求技术上确实可以用 Function Calling 直接做——写个 Python 脚本，调 Claude API，把 execute_sql 定义成一个 tool，让模型生成 SQL 然后你本地执行。我一开始也是这么想的。 但有几个问题绕不开： 运营小姑娘...

说一个让我自己有点尴尬的事。2023 年那会儿，我在公司内部做过一场分享，题目叫《Prompt Engineering 十二招》，里面讲的全是些”你是一个资深 XX””请一步一步思考””输出格式如下”这种现在看起来挺初级的东西。当时还挺受欢迎，后来这套 slides 还被隔壁部门借去讲过两次。 到了 2025 年下半年做 Agent 项目的时候，我突然发现那套思路彻底不够用了——我可以把单次请求的 prompt 调到完美，但 Agent 跑几十轮之后照样翻车；我可以给模型写一个漂亮的 system prompt，但真正决定它表现的是每一步我塞给它的上下文。 这时候我才反应过来：过去两年大家琢磨的 “Prompt Engineering”，其实只是 “Context Engineering” 的一个子集，而且是最小的那一块。 这篇我把自己这一年半从 Prompt 调教转向 Context 工程的思路转变讲清楚，以及我现在实际在用的四个支柱：Writing、Selection、Compression、Isolation。 一、Prompt Engineering 的天花板在哪先回到起...

去年十二月我换了新电脑，重装环境的时候顺手把 Cursor、Cline（当时还叫 Claude Dev）、Claude Code CLI 三个都装上了。当时想的是挨个试一圈看哪个最顺手，没想到一试就是四个月，到今天为止三个都还在我机器里跑着，各自占据了不同的位置。 这四个月我大概写了三万行代码——两个接私活的项目、一个自己的开源玩具、公司一个中型重构。三种工具都被我当主力用过至少三周，翻车记录和真香时刻都不少。这篇文章不想搞那种”跑分表格三选一”的套路文，就聊聊我自己的切换逻辑。 先说结论：我现在怎么用它们的直接把结论放前面，免得有人看不下去。我现在的分工大概是这样： Claude Code CLI：日常 70% 的活，尤其是需要”跨文件理解 + 改动可控”的任务 Cursor：快速写新功能、起新项目、那种”白纸画图”的场景 Cline：偶尔启动，专门对付那些需要”多轮自主执行”的任务，比如跑迁移脚本、批量改配置 下面展开讲每个的优点、缺点、和我踩过的具体坑。 一、Cursor：上手最快，但越用越有保留Cursor 是我最早买年费的。说实话它的新手友好度是三个里最高的——装上...

上个月我给一个做跨境电商的朋友做了个客服 bot，接 WhatsApp 和独立站两个入口，每天大概 3000-4000 轮对话。刚上线的时候我图省事，全部走 Sonnet 4.6——毕竟他们家客户问的问题挺杂，有退换货有物流追踪有产品咨询，我怕 Haiku 扛不住。 结果第一个月账单出来，$430。朋友当时没说什么，但我自己看着这个数字挺刷新的——一个小电商客服，一个月光 AI 费用就快赶上一个兼职客服工资了。这东西如果要商用化，成本必须砍下来。 我花了差不多一周时间重构，最后的方案就是标题这个：前面塞一个 Haiku 4.5 当 Router，先判断问题类型，简单的直接 Haiku 回，复杂的才转给 Sonnet。上线跑了一个月，账单掉到 $128，砍了大概 70%。这篇把整个思路和踩过的坑都讲清楚。 一、为什么是路由，不是降级很多人第一反应是”那我直接全部换成 Haiku 不就行了”。我试过，不行。 Haiku 4.5 处理简单问题确实够用，但它有几个明显的短板： 多轮对话容易丢线索。用户上一轮说了订单号，下一轮问”那个能退吗”，Haiku 有概率接不住 复杂意图识别差。用...