Steve Klabnik 写给软件开发者的 Claude 入门指南：先理解工具、从只读对话开始，再逐步过渡到更复杂的问题。

作者：Steve Klabnik
发布于：2026-01-07
原文：https://steveklabnik.com/writing/getting-started-with-claude-for-software-development/

从很多方面看，2025 年都是很有意思的一年。对我而言，其中一个变化是：我从一个讨厌 AI 的人，变成了相当重度的用户。陆续有人请我写一份“Claude 使用指南”，于是我想，新年到了，何不试试看？刚开始接触这些工具时，找不到这类内容曾让我非常沮丧，所以写出来也算为大家做点贡献。

这篇文章面向希望在 2026 年初了解这类工具的软件开发者。我会先介绍一些背景，再带你迈出试水的第一步。如果大家喜欢，我会继续写下去——这个主题可以谈的内容实在太多。由于 Claude 是我最常用的工具，本文会直接围绕它展开，不过其中不少方法也适用于其他平台。

要学的东西很多

首先要说明，这篇文章之所以可能只是系列的第一篇，是因为正如刚才所说，这里面可以讲的东西实在太多。这一点比你最初想象的更重要。无论别人怎么说，真正熟练地使用大语言模型并不容易。这个领域的很多建议来自没有教学背景的人，他们已经忘了自己为了走到今天投入了多少时间。

我喜欢把它类比成 Vim：所有人都承认，模态编辑是一种完全不同的工作方式。我们会拿“不小心打开 Vim 后连怎么退出都不知道”开玩笑，但也有很多人承认，它强大的能力值得你跨过学习曲线。我对大语言模型的看法也是如此：想真正做出成果并不轻松，但投入学习的时间可能很值得。

还有一件事必须提前说：对你而言，这份投入也可能并不值得。我不会责怪任何不想花时间学习新工具的人，尤其是在一个变化如此迅速的领域。本文要讲的几乎所有内容，都是最近 12 到 14 个月才真正成熟起来的。再过 12 个月，这篇文章也许就毫无用处了，我不知道。就像有人觉得学习 Vim 不如继续使用普通编辑器一样，认为这些东西不值得投入时间，也是完全理性、合理的决定。你不会像某些鼓吹者说的那样“被时代抛下”；软件开发者不学 Vim 也照样可以工作。这里不是要打响 Vim 与 Emacs 的战争，而是想说：“如果你想学 Vim，我认为可以这样入门；如果不想，也完全没问题。”

此外，因为需要介绍的内容太多，本文只会讲背景和第一步，否则篇幅会长得离谱。你不可能读完一万字就突然成为专家，还是得亲手使用这些工具。所以，你应该在每篇文章之间留出时间实践。把内容拆开，恰好能提供一些自然的停顿点，让你真正去试一试。

有意识地使用

谈论这个主题时，我最先想说的是一件自己经常思考的事：与身边很多人相比，我使用大语言模型的效果通常更好。这件事一直困扰着我，因为我也不完全确定原因。不过，我确实有一个猜想。

我会以一种……或许称不上“科学”，但至少算理性的方式对待这个领域。我不断尝试，丢掉看起来无效的方法，保留看起来有效的方法，并尽量保持批判性思考。

不过——

虽然这个领域里“凭感觉”（vibe）一词背后的问题很复杂，但我认为它也确实重要。感觉和氛围真的会影响结果。我有一些更偏科学的理由，也有一些更来自日常经验的理由。总体而言，我认为你以什么态度参与这个过程，会在一定程度上决定最终效果；开始这段学习旅程时，应该有意识地留意自己的态度。

觉得这听起来太玄学？那我说得具体一点：我真心相信，对 Claude 破口大骂会让它表现得更差。如果你像对待一位值得尊重的同事那样与大语言模型合作，结果会更好；如果斥责、侮辱或以其他方式恶劣对待它，结果就会更差。

这很重要，因为很多对大语言模型持怀疑态度的人在尝试时，也许不会真的说“Claude，你他妈到底有什么毛病”（尽管我确实亲眼见过），但事情不顺利时，他们往往更容易流露出挫败感。请用上自己的情绪调节能力。批评 Claude 的做法完全没问题，但表达方式应该确保在一家健康的公司里不会让你被人举报到 HR。应该这样说：

你为什么选择这种做法？我更希望我们采用 <这种方案>，可以解释一下吗？

不要这样说：

别再犯这种低级错误了。你明明知道我们应该用 <这个>，而不是 <那个>，蠢货。

我认为善待他人对你自己也有好处。不过，即使你厌恶人类，也可以把这种态度当作一项提高工具产出的技能。我认为在这里适当地拟人化，反而是一件好事。后面进入实践步骤时，我们还会回到这一点。更高层的原则是：大语言模型不是人，但它基于人类使用的语言工作，语言就是它的 API。因此在我看来，像与同事交流一样和它互动，才是正确方式。

也许将来有一天，我会进一步阐述这种看法，也可能不会。这样做主要出于我的个人信念，但我仍然希望把它分享出来。

Claude 网页版与 Claude Code

好了，前面的话讲完了，现在来看看使用 Claude 的不同方式。实际上选择不少，但我只关注两种：通过 https://claude.ai 使用网页版，以及使用 Claude Code。

这两种使用方式有本质区别，也各有优缺点。真正进行软件开发时，应该使用 Claude Code，原因在于稍后会接触到的“智能体循环”。不过，刚开始试水时使用网页版也没问题。最重要的是明白：网页界面的体验与 Claude Code 并不相同。如果我只能使用网页界面，我不会像现在这样看好这些工具。但它仍然可以发挥作用，尤其适合刚入门的时候——只要你清楚两者差异很大。

套餐与 API 计费

接下来是另一个重要话题：钱。我不责怪任何人不愿花时间学习这类工具，还有一个原因——Vim 免费，Claude 却绝对不免费。不过，我们需要具体分析。

费用问题主要取决于三个因素：使用 Claude 网页版还是 Claude Code、能够访问哪些模型，以及实际花费。下面逐一说明。

你现在就可以打开 https://claude.ai，免费与 Claude 对话，但不付费就无法使用 Claude Code。因此，如果你希望从最小的投入开始，可以先用网站体验，再决定是否花钱。这完全没问题，只要记住两种体验不同。作为起点，它也许很合适。

在 2024 和 2025 年，有充分理由认为必须订阅付费套餐，因为只有这样才能使用最新模型。现在某种程度上仍是如此，不过模型已经进步到一个阶段，新旧版本之间的差距正在变得没那么重要。我认为在 2026 年上半年，模型版本仍然有一定影响。简单来说，Claude 3、4 和 4.5 之间的差异很明显；但对我而言，一年前的 Claude 4 就已经足以完成真正的工作。我不完全确定现在免费用户拿到的是哪个版本，不过至少够用。等下一轮模型发布时，免费可用的版本大概就已经足够好，这个问题也会失去意义。但要知道，一分钱一分货，付费确实能换来更好的表现。

（说到模型，你会听到 Claude 的三个名称：Haiku、Sonnet 和 Opus。顾名思义，能力从弱到强依次排列，速度则从快到慢。Sonnet，尤其是 4.5 版本，几乎做什么都很不错；Opus 4.5 非常出色；Haiku 则很适合某些特定任务。）

至于实际费用，套餐有每月 20 美元、100 美元和 200 美元几档，也可以选择“按 API 调用付费”。你也许会想：“我只按调用付费，控制一下用量就好。”这是一个很合理的想法，也是一个非常糟糕的选择。订阅套餐能换来的用量远超它的价格。举个例子：我最近在一个晚上用完了每周额度。我的套餐是每月 200 美元，折算下来这一周支付约 50 美元；但系统估算，如果按 API 调用计费，同一周的用量会花掉 1,440.73 美元。当然，我是非常重度的用户，但道理不变：一个刚开始尝试这些工具的人，也很容易用掉超过 20 美元的 API Token。

如果你想认真体验这些工具，就挤出 20 美元，订阅最便宜的套餐，实验结束后再取消。这样既能使用 Claude Code，又给支出设定了上限，两全其美。节制使用也会带来一些不错的附带效果，但坦率地说，那更像是中级甚至高级话题。建立这些技能时一直担心费用，只会分散注意力。通过套餐封顶支出，就不必担心一不小心花到破产。

背景终于交代完了。下面开始迈出第一步。

第一步：进行一场对话

所有人都对大语言模型生成代码的能力感兴趣，但我认为那其实是第二步，而不是第一步。最初使用这些工具时，我希望你保持完全只读。这也是为什么网页版适合入门：Claude Code 生成代码的能力远胜网页版，但我们一开始根本不准备写代码。

找一段自己最近写过的代码，什么都可以。打开 https://claude.ai，输入：

嗨，Claude！我们可以聊聊这段代码吗？

然后粘贴代码。不需要任何花哨的提示词技巧，甚至不必说明它是什么编程语言，只需给它一段代码。十行可以，一百行也可以，但刚开始不建议直接贴一千行。

Claude 大概会先对你的代码做一番基础分析，然后提出一个问题。我把自己和朋友最近讨论的大约 50 行代码交给它，得到的回答大致是：

当然可以！这段代码看起来是在 <描述它的作用>，其中包含 <代码完成的三件事>。

你主要想讨论哪一方面？是在考虑整体设计、遇到了某个具体问题，还是希望我针对某一部分给出反馈？

接下来可以沿很多方向继续，具体取决于你粘贴了什么。下面是一些有意思的提问思路：

你认为这段代码符合这门语言的惯用写法吗？

如果只能改进其中一点，你会选择什么？

如果希望把这段代码改成能够 <完成某件事>，你会怎么做？

这段代码里存在缺陷吗？

它是否存在我没有考虑到的安全风险？

诸如此类。这里的目标只是熟悉整个过程。它确实有些奇怪，和面对编译器完全不同。

如果 Claude 说了你不同意的话，可以像对同事一样提出异议：

我不太同意。原因是系统的另一个部分存在 <某种行为>，这会影响这里的决策。

你为什么提出这个建议？我想进一步理解你的考虑。

Claude 绝不可能永远正确，这完全没问题。目标是共同工作，而不是把它当成一个突然能解决所有问题的魔法工具。

第二步：提出更大的问题

这样练习几次后，就可以过渡到 Claude Code。原因是你能够逐渐扩大问题的范围。安装并登录后，你会进入终端提示符。它也许会提醒你创建 CLAUDE.md，现在不用管，继续围绕代码库与 Claude 对话。

相比前一步，这是一次明显升级：以前必须手工粘贴全部代码，现在 Claude 可以自己寻找相关文件。可以试试下面这些提示词：

请审查我的整个代码库，并提出五项改进建议。

你能在 <某个组件> 中找出缺陷吗？

我想了解 <某个组件> 的性能，我们可以讨论一下吗？

我很喜欢让 Claude 帮忙验证自己的直觉。几个月前，我在开发一个 Rust 应用时考虑进行一次重构。我一直没有动手，因为担心过程繁琐、耗时，而且最后未必能改善代码库。它可能有帮助，也可能没有；为了验证一个可能无效的想法而投入一两天，实在不划算。于是，我问了 Claude。下面是一条相对较长的提示词示例：

嗨，Claude！我正在考虑重构代码。在这样一个函数中：<粘贴代码>，我不喜欢当前的实现，考虑改成：<粘贴代码>。不过，我知道这会改变函数签名，进而影响代码库中的其他代码。我有几个问题：1. 如果进行这项修改，需要更新多少个函数签名？2. 能否选择一个比较简单的端点，展示重构后的代码？3. 能否再选择一个最复杂的端点，展示重构后的代码？

Claude 给出的答案大致是：“需要修改 250 个签名，下面是代码库中这两个示例修改前后的样子。”Claude 当然并不完美，实际数量也许是 260 个。但重点在于，它帮助我验证了直觉：这确实是一项不小的工作。同时，我也看到了重构对自己真实代码的影响，从而判断它能否真正改善代码库中那些最棘手的部分。

注意，这里并没有什么特别的“提示词工程”。不需要写“请作为一名资深软件工程师”之类的话，只要像与人交流一样和它说话就可以。这并不意味着提示词毫无用处，但此类优化属于中高级话题。坦率地说，到了现在，我甚至怀疑“作为某某角色”这种技巧是否还有帮助，也许以后再谈。重点是：对工具越来越熟悉之后，你自然可以开始提出更复杂的问题。

Claude 可以异步工作，所以你可以把这些问题放到后台，等完成后再回来查看。好吧，某种程度上是这样。结束之前，我们还需要谈谈权限。

权限

默认情况下，Claude 会进入“编辑前询问”模式，这是很好的起点。执行某些操作前，它会先征求你的意见，你可以回答同意或拒绝。请认真看看它准备做什么，再给出自己能够接受的答案。

高级用户基本会允许 Claude 随意操作，但你现在还没有到那个阶段。作为新用户，有些风险尚不明显。因此，即使每次都要确认有些烦人，我仍建议最初只授予最低权限。系统允许你选择“本次会话剩余时间内都允许执行同类命令”；当它只是想运行 grep 一类操作时，可以同意。但现阶段，我建议不要让它写代码；如果它询问，就拒绝。后续文章会带你进入那一步。

总结

这就是我的 Claude 入门建议：花 20 美元订阅套餐；像与人交流一样与它对话；先把它当成获取代码反馈的工具，不要急着让它写任何东西。随着你逐渐理解它的能力，再一点点扩大问题的范围。发现它走偏时，可以温和地提出异议。

这里的目标，是对工具能够做什么形成一份基础认识，而不是在一个下午里凭感觉让它写完整个应用。这些练习也许显得过于简单，但相信我，后面会越来越难。正式让 Claude 写代码之前，你最好先打牢使用只读问题与它协作的基础。

希望这篇文章对你有帮助。