Claude Code + 自定义模型体验

背景

AI 编程工具的发展突飞猛进：Cursor 横空出世，推出了“Agent 模式”；新竞争者如 Windsurf 也纷纷加入战局。几乎所有产品都开始转向“代理式（agentic）”开发模式——不再依赖单次 LLM 响应进行补全，而是让大模型在一个循环中调用各种工具，来完成更复杂的任务：分析代码库上下文、读取网页与文档、编译程序、运行测试、修复失败构建或测试、不断迭代等。

即使我很喜欢 Claude Code，我也不认为“命令行终端”会是未来开发体验的最佳形式。
可以看看windsurf的这篇文章 https://windsurf.com/blog/what-is-an-agent

虽然世界显然正朝着自主代理的方向发展，但就目前而言，大型语言模型可能还不够完善，无法在没有任何人为干预或纠正的情况下，端到端地完成这些复杂任务。

这种现实带来了一种新的智能体方法，这种方法基于一种认知，即人类应该做什么和智能体应该做什么之间需要保持某种平衡。为了区别于智能体的自主方法，我们将这些智能体称为协作智能体，或简称为 AI flows

这些流程必须在人类进行工作的相同环境中运行。大多数自主代理的尝试，因为它们独立于用户工作，所以是从一个与用户手动完成工作时所处的界面不同的界面调用的。例如，Devin 是从一个网页调用的，但实际上开发人员会在 IDE 中编写代码。虽然这在代理可以真正做任何事情的世界中可能没有问题，但由于这些自主代理系统没有存在于人类进行工作的界面中，因此它们不会意识到人类手动所做的事情。因此，它们会错过很多可以从这些操作中获得的隐含上下文。例如，如果代理存在于 IDE 中，那么它就会意识到最近的手动编辑，这将隐式地告知代理接下来应该做什么。

换句话说，在这个现实中，人类观察智能体的行为很重要，智能体观察人类的行为也很重要。

《Claude Code：面向代理式编程的最佳实践》

Anthropic nthropic 官方的文章：《Claude Code：面向代理式编程的最佳实践》（https://www.anthropic.com/engineering/claude-code-best-practices）

“上下文工程”才是关键

随着主流 AI 的兴起，业界很快提出了一个新概念：提示词工程（prompt engineering）。它的核心理念是：你需要精心设计提示词，才能从模型中获取最优结果。这个观点在早期可能确实有道理，但根据我的实际经验，对于现在的新一代模型来说，提示词工程已经不是重点。

当下的模型在理解不完美输入方面已经有了显著提升——一方面因为模型本身更强大，另一方面也因为它们采用了“思维链（Chain of Thought, CoT）”提示策略。现在你就算给模型模糊的描述、不完整的句子、甚至拼写语法错误，它依然能大致理解你的意图，并将问题拆解为合理的解决步骤。

你在使用 Claude Code 或类似工具时，真正需要反复应对的限制，其实是“上下文窗口”（context window）。

Anthropic 最新的两个模型——Sonnet 4 和 Opus 4——都拥有 200k tokens 的上下文长度，意味着它们一次最多能处理大约 200k token 的文本。但你每输入一个 prompt、模型每回应一句，都在消耗这个上下文容量；而一旦临近尾部，模型的表现往往会变差。

为了解决这个问题，Claude Code 还贴心地显示了一个“上下文剩余容量指示器”——一旦快要用完，它就会自动进入“压缩（compaction）”流程。这一步的意思是：模型会对当前对话内容进行总结，再用这个总结信息来初始化一个新的上下文窗口，以便你继续使用。

但压缩并不完美：它可能遗漏之前对话中的关键细节，或者因为压缩逻辑本身不够精细，将一些错误信息“继承”到新的上下文中。

所以，总结来说——如何在有限的上下文 token 数量内产出最高质量的结果，也就是所谓的上下文工程（context engineering），才是你真正要在编程代理工具中专注优化的核心能力。

全局的CLAUDE.md文件

默认情况下，Claude 会自动读取 CLAUDE.md 文件中的内容——包括用户级别和项目级别的两个版本。但你也可以通过提示词，主动引导它去读取某些文档或源码文件，以补充任务相关的上下文。

Claude 会调用 Search 和 Read 工具查找并读取这些源码文件，再用 Fetch 工具下载 GitHub 上的 Markdown 文档。让它生成总结的这个步骤非常关键，因为总结能迫使模型真正“思考”它理解了什么，而这个总结会被保留在上下文中，进而提升它接下来处理任务的表现。

当你的代码依赖第三方库，或者使用了模型知识截止时间之后发布的新 API 时，预热尤其重要。这类信息模型本身可能并不了解，所以你得手动补充。

现在也有一些专门工具，比如 Context7 和 llm.codes，它们的作用就是将文档格式化成适合语言模型读取的纯文本内容，从而方便“喂”给 Claude 使用。

统一指令：一个全局的CLAUDE.md文件则扮演着“项目经理”的角色，为所有AI智能体设定了共同的行为准则和目标。

代理不会读心，它们需要「规范说明（Spec）」

代理不会读心，它们需要「规范说明（Spec）」

当你让 Claude 构建某个功能时，一份详细的功能说明文档（spec）是引导模型的关键。如果你不愿投入精力编写清晰的需求说明，Claude 就无法帮你完成任何稍微复杂一点的功能。

我们经常能在 AI 产品演示中看到一句话就生成“完整应用”的场景，但那通常只能做出个原型而已。如果你希望产出真正可用的功能，就必须提供一份明确、具体的说明文档。

这个文档并不需要措辞优雅、结构工整

先计划再动手

Claude 有个常见的问题：它常常会在没有足够背景信息的情况下就直接动手实现功能，结果就是生成的代码质量很差。

为了解决这个问题，另一种有效的“预热”策略是：明确让 Claude 启用“深度思考”模式，并先制定一份计划。你可以通过一组“魔法关键词”来激活这个模式：

"think" < "think hard" < "think harder" < "ultrathink"
这些词不是普通的建议，它们是明确的触发信号，会让模型进入不同程度的深度推理状态。其中 “ultrathink” 会消耗最多的 token，但也是效果最好的。

如果你希望 Claude 在动手写代码前先跟你确认方案，可以在 prompt 中明确指出：

“请先制定计划并等待用户确认后再开始实现。”

Cl