1. 从“辅助写代码”到“主力写代码”的认知转变
1.1 为什么这个话题突然火了
最近半年，我身边越来越多的工程师开始把 Claude 放到编码流程的中心位置，而不是像以前那样只把它当成一个“高级自动补全”。这个转变不是小打小闹，它直接改变了我们每天的工作方式：以前是人写代码、工具辅助；现在是人描述意图、Claude 生成主体代码、人做审查和集成。这个模式在海外技术社区已经被反复讨论，国内也有不少团队在悄悄跟进。
我自己是从去年底开始系统性地用 Claude 写代码的，到现在大概有八九个月的高强度使用经验。中间踩过不少坑，也总结出了一些比较稳的套路。这篇文章就把我自己的实践、观察到的同行做法、以及社区里反复验证过的经验，完整地梳理一遍。不管你是刚听说 Claude Code 的新手，还是已经在用但总觉得“差点意思”的老用户，应该都能从里面找到能直接抄作业的东西。
1.2 核心问题到底是什么
标题问的是“你们是怎么做到的”，这个问题背后其实藏着好几层意思。第一层是工具层面：用什么形态的 Claude？是网页版、桌面客户端、还是命令行工具 Claude Code？第二层是流程层面：怎么把 Claude 嵌入到日常开发、代码审查、PR 提交这些环节里？第三层是上下文管理层面：怎么让 Claude 理解你的项目结构、编码规范、业务逻辑，而不是每次都从零开始猜？第四层是质量控制层面：生成的代码怎么保证可靠、怎么防止密钥泄露、怎么处理它偶尔的“幻觉”？
这四个层面缺一不可。很多人只解决了第一层，装了个 Claude Code 就开始用，结果发现生成的代码跟项目风格完全不搭，或者改着改着就把原有逻辑改坏了。问题不在 Claude 本身，而在于没有把后面三层搭起来。
1.3 适合谁来参考
这篇文章主要面向几类人：一是已经有一定编程经验、想大幅提升编码效率的工程师；二是正在评估要不要把 LLM 引入团队工作流的 tech lead；三是对 Claude Code、AGENTS.md 这些概念好奇但还没动手的开发者。如果你完全没写过代码，这篇文章的部分内容可能会有点吃力，但关于工具选型和上下文管理的思路，对任何想用 LLM 做实际工作的人都有参考价值。
2. 工具选型：Claude 的几种形态怎么选
2.1 网页版、桌面版、CLI 的适用场景
Claude 目前主要有几种使用形态，每种适合的场景差别很大。网页版最轻量，打开浏览器就能用，适合快速问问题、写小段代码、解释报错信息。但它的问题也很明显：没法直接访问你本地的代码文件，每次都要手动复制粘贴，上下文一长就容易乱。桌面客户端比网页版好一点，可以拖文件进去，但本质上还是“对话式”的交互，跟真正的工程流程隔了一层。
真正让“用 Claude 写所有代码”变得可行的是 Claude Code 这个命令行工具。它直接跑在你的终端里，能读写本地文件、执行命令、查看 git 状态、创建 PR。这个形态的关键区别在于：Claude 不再是一个你“去访问”的网站，而是一个住在你项目里的协作者。它可以自己去看你的目录结构、读你的配置文件、理解你的依赖关系，然后基于这些真实信息来生成代码。
我自己的组合是这样的：日常快速问答用网页版，需要处理整个项目级别的任务时切到 Claude Code。桌面版我基本不用，因为它的能力介于两者之间，反而不如两端极致。
2.2 Claude Code 的安装与基础配置
Claude Code 的安装本身不复杂，但有几个细节容易卡住人。在 macOS 和 Linux 上，通常是通过 npm 全局安装，命令大概是npm install -g @anthropic-ai/claude-code，然后在你项目的根目录下运行claude就能启动。Windows 用户需要注意，官方对 Windows 的支持是通过 WSL 实现的，如果你直接在 PowerShell 里跑，可能会遇到虚拟化平台相关的报错，提示需要启用虚拟机平台功能。这个问题的根源是 Claude Code 底层依赖的一些沙箱机制在原生 Windows 上跑不起来，走 WSL 是最省事的方案。
安装完之后第一件事是配置 API 密钥。这里有个重要的安全提醒：千万不要把密钥硬编码在项目文件里，也不要在对话中直接把密钥粘贴给 Claude。正确的做法是通过环境变量注入，比如在 shell 的配置文件里设置ANTHROPIC_API_KEY，或者用 Claude Code 提供的配置命令来管理。我见过有人图省事直接把密钥写在.env文件里然后提交到了仓库，这种事情一旦发生，密钥就等于公开了。
2.3 和 VS Code 的配合方式
虽然 Claude Code 是命令行工具，但它和 VS Code 的配合可以很顺。一种方式是在 VS Code 的集成终端里直接跑 Claude Code，这样你一边看代码一边跟 Claude 交互，切换成本很低。另一种方式是用 VS Code 的 task 功能把 Claude Code 的命令绑定成快捷键，需要的时候一键唤起。
我个人的习惯是分屏：左边是 VS Code 的编辑器，右边是终端里的 Claude Code。当 Claude 生成了一段代码，我可以直接在编辑器里看到文件的变化，然后用 VS Code 的 diff 功能快速审查。这个流程比“复制粘贴到网页版再复制回来”要顺畅太多了，尤其是当改动涉及多个文件的时候。
2.4 接入其他模型的考量
社区里也有人讨论把 Claude Code 接到其他模型上，比如通过一些兼容层让 Claude Code 调用别的 LLM。这个做法在技术上是可行的，但我不太推荐在生产项目里这么干。原因是 Claude Code 的很多能力是跟 Claude 模型本身深度绑定的，比如它对工具调用的理解、对长上下文的处理、对代码结构的把握，换一个模型之后这些能力可能会打折扣。如果你只是想省钱或者做实验，可以试试；但如果是正经的项目开发，还是用原生组合比较稳。
3. 上下文管理：让 Claude 真正懂你的项目
3.1 AGENTS.md 是什么、为什么重要
如果说 Claude Code 是发动机，那 AGENTS.md 就是方向盘。这个文件放在项目根目录下，用来告诉 Claude 这个项目是干什么的、代码怎么组织、有哪些约定俗成的规则。没有它，Claude 每次都要靠猜；有了它，Claude 一进来就能进入状态。
AGENTS.md 的内容通常包括几个部分：项目概述（一句话说清楚这个项目解决什么问题）、目录结构说明（哪个目录放什么）、编码规范（命名习惯、缩进风格、注释要求）、常用命令（怎么跑测试、怎么构建、怎么启动开发服务器）、以及一些禁忌（比如不要改某个核心文件、不要引入新的依赖）。这些信息看起来琐碎，但它们直接决定了 Claude 生成的代码能不能直接用。
我自己的 AGENTS.md 大概两百行左右，写的时候参考了社区里几个开源项目的模板。写完之后最直观的感受是：以前 Claude 生成的代码我至少要改三成，现在大部分情况下改一成以内就够了。
3.2 怎么写一份有效的 AGENTS.md
写 AGENTS.md 有几个原则。第一是具体，不要写“代码要清晰”这种废话，要写“函数名用驼峰、变量名用下划线、每个导出函数必须有 JSDoc 注释”。第二是简短，Claude 的上下文窗口虽然大，但也不是无限的，把最重要的规则放在前面，细节可以放在后面。第三是更新，项目变了 AGENTS.md 也要跟着变，不然 Claude 会按照过时的规则来生成代码。
一个常见的误区是把 AGENTS.md 写成给人类看的文档。它其实是给模型看的指令，所以语气要直接，用“必须”“禁止”“优先”这样的词，而不是“建议”“可以考虑”。另外，如果你有多个项目，不要指望一份 AGENTS.md 走天下，每个项目的规则都不一样，该分开写就分开写。
3.3 context.md 和知识库的补充作用
除了 AGENTS.md，还有一个叫 context.md 的文件也很有用。如果说 AGENTS.md 是“规则手册”，那 context.md 就是“背景资料”。它通常用来放一些 Claude 需要知道但又不适合放在 AGENTS.md 里的信息，比如业务领域的术语解释、历史决策的原因、跟外部系统的对接方式。
再往上一个层次是 LLM wiki 知识库。这个概念最近被讨论得很多，核心思路是把项目相关的所有文档、决策记录、常见问题整理成一个结构化的知识库，让 Claude 可以按需检索。这个做法在大型项目里特别有价值，因为大型项目的知识散落在各种地方，新人上手要花几周，Claude 如果没有知识库支撑，也只能看到代码表面。
3.4 上下文窗口的实战管理技巧
Claude 的上下文窗口虽然大，但在实际使用中还是会遇到“聊着聊着它就忘了前面说过什么”的情况。我的应对策略是：把长任务拆成短会话，每个会话聚焦一个明确的目标。比如“重构用户认证模块”是一个会话，“给认证模块写测试”是另一个会话。这样每个会话的上下文都是干净的，Claude 不容易被无关信息干扰。
另一个技巧是主动清理。当对话进行到一定程度，我会让 Claude 总结一下当前的状态和待办事项，然后开一个新会话，把总结贴进去作为起点。这样既保留了关键信息，又释放了上下文空间。实测下来，这个做法能让 Claude 在长任务中的表现稳定很多。
4. 编码流程：从需求到 PR 的完整链路
4.1 需求描述怎么写 Claude 才听得懂
用 Claude 写代码，第一步是把需求说清楚。这里的关键是：不要用人类之间那种“你懂的”式的模糊表达。Claude 不会“懂”，它只会根据你给的信息做推断。所以需求描述要尽量包含：输入是什么、输出是什么、边界条件有哪些、异常情况怎么处理。
举个例子，如果你说“帮我写个函数处理用户上传的图片”，Claude 会生成一个很通用的函数，但大概率不符合你的实际需求。如果你说“写一个函数，接收一个 File 对象，校验它是不是 JPEG 或 PNG，大小不超过 5MB，返回一个 Promise，成功时 resolve 压缩后的 Blob，失败时 reject 一个带错误码的对象”，Claude 生成的代码就能直接用。
我自己的习惯是先让 Claude 复述一遍需求，确认它理解对了再让它动手。这个步骤看起来多此一举，但实际上能省掉很多来回修改的时间。
4.2 让 Claude 先出方案再写代码
直接让 Claude 写代码，有时候它会一头扎进细节里，写出一个能跑但结构很差的实现。更好的做法是分两步：先让 Claude 给出实现方案，包括文件结构、函数划分、关键数据结构，你审查确认之后再让它写具体代码。
这个做法还有一个好处：方案阶段修改的成本很低，改几句话就行；代码阶段修改的成本就高了，可能要重写整个文件。我在做一个比较复杂的模块时，通常会花十分钟跟 Claude 讨论方案，然后再花二十分钟让它写代码，整体效率比直接写要高。
4.3 代码审查环节怎么用 Claude
Claude 不仅能写代码，还能审代码。我现在的习惯是：Claude 生成代码之后，让它自己先审一遍，找出潜在的问题。这个“自审”步骤能 catch 掉不少低级错误，比如变量没定义、边界条件没处理、异常没捕获。
然后我会再让 Claude 从“审查者”的角度看一遍，问它“这段代码如果被一个资深工程师 review，会被指出什么问题”。这个提问方式能激发出 Claude 更批判性的输出，它会更认真地去找逻辑漏洞和设计缺陷。实测下来，这个技巧比直接问“这段代码有什么问题”效果要好。
4.4 PR 的创建与描述生成
Claude Code 可以直接帮你创建 PR，包括生成 PR 描述。这个功能在团队协作里特别省事，因为写 PR 描述是很多人讨厌的环节。Claude 会根据代码改动自动总结改了什么、为什么改、怎么测试，生成的描述质量通常比人手写的还规范。
不过这里有个注意事项：Claude 生成的 PR 描述要人工过一遍，确认它没有夸大或者遗漏。我见过 Claude 把一个小改动描述成“重大重构”的情况，也见过它漏掉一些关键改动的说明。PR 描述是给同事看的，准确性比效率更重要。
4.5 提交信息的规范化
提交信息（commit message）也是 Claude 可以帮忙的地方。如果你在 AGENTS.md 里规定了提交信息的格式，比如“type(scope): description”，Claude 会按照这个格式来生成。我自己的项目里用的是 conventional commits 规范，Claude 生成的提交信息基本都能直接用，偶尔需要微调一下 scope。
这里有个小技巧：让 Claude 在生成提交信息之前先看一下最近的几条提交记录，这样它能更好地匹配项目的习惯。这个做法在接手一个新项目时特别有用，因为不同项目的提交风格差别很大。
5. 质量控制与安全防护
5.1 防止密钥泄露的几条铁律
用 LLM 写代码，密钥安全是绕不过去的问题。我总结了几条铁律：第一，永远不要把密钥粘贴到对话里，哪怕是“临时看一下”也不行；第二，在 AGENTS.md 里明确写出哪些文件包含敏感信息，让 Claude 不要碰；第三，用.gitignore和 pre-commit hook 双重保险，防止敏感文件被提交；第四，定期用工具扫描仓库，检查有没有意外泄露的密钥。
Claude Code 本身有一些安全机制，比如它不会主动去读.env文件，但你不能完全依赖这些机制。最可靠的做法还是从流程上杜绝：密钥只存在于环境变量里，代码里只引用变量名，不出现实际值。
5.2 生成代码的可靠性验证
Claude 生成的代码大部分时候是可靠的，但偶尔也会有“看起来对但实际有问题”的情况。我的验证策略是：单元测试优先。让 Claude 写代码的时候顺便写测试，然后跑一遍测试。如果测试通过，至少说明基本逻辑是对的；如果测试失败，Claude 通常能根据报错信息自己修。
对于没有测试覆盖的部分，我会用“小步验证”的方式：让 Claude 一次只改一个函数或者一个模块，改完立刻手动验证，确认没问题再继续。这个做法比“让 Claude 一口气改十个文件然后一起测”要稳得多。
5.3 处理 Claude 的“幻觉”和错误
Claude 有时候会“编造”一些不存在的东西，比如引用一个不存在的库、调用一个不存在的方法、或者对某个 API 的行为做出错误假设。这种情况在涉及较新或者较小众的技术栈时更容易出现。
应对方法是：对于 Claude 生成的涉及外部依赖的代码，一定要去查官方文档确认。如果 Claude 说“可以用 xxx 库的 yyy 方法”，你就去那个库的文档里搜一下 yyy 方法是不是真的存在。这个步骤花不了多少时间，但能避免很多后续的调试痛苦。
5.4 代码风格的一致性保障
Claude 生成的代码风格如果不加约束，会跟你项目现有的风格有出入。解决办法是在 AGENTS.md 里写清楚风格规则，并且在项目里配置好 linter 和 formatter。Claude Code 可以运行这些工具，如果生成的代码不符合规范，linter 会报错，Claude 看到报错后会自己修正。
我自己的项目里用的是 ESLint + Prettier，在 AGENTS.md 里写明了“生成的代码必须通过 lint 检查”。实测下来，Claude 会主动去跑 lint，然后根据报错调整代码，基本不需要我手动干预。
6. 常见问题与排查技巧实录
6.1 安装和配置阶段的典型问题
| 问题现象 | 可能原因 | 解决方法 |
|---|---|---|
| Windows 上启动报虚拟化平台错误 | 原生 Windows 不支持沙箱机制 | 改用 WSL 环境运行 |
| 提示 API 密钥无效 | 环境变量没设置或设置错误 | 检查 shell 配置文件，确认变量名正确 |
| 安装后命令找不到 | npm 全局路径没加入 PATH | 检查 npm 的 global bin 路径并加入 PATH |
| 连接超时 | 网络环境问题 | 检查网络连接，确认能访问所需服务 |
6.2 使用过程中的高频问题
一个很常见的问题是 Claude 改着改着就把不相关的代码也改了。这个通常是因为它在“理解”代码的时候产生了误判，觉得某些地方也需要调整。解决办法是在指令里明确说“只改 xxx 文件，不要动其他文件”，或者在 AGENTS.md 里写明“修改代码时只改与当前任务直接相关的部分”。
另一个问题是 Claude 生成的代码在本地跑不起来，但错误信息很模糊。这时候可以把完整的错误信息贴给 Claude，让它分析。大部分情况下它能定位到问题，但如果错误涉及环境配置或者依赖版本，可能需要你手动排查。
6.3 上下文丢失的应对
上下文丢失的表现是：Claude 突然开始用错误的假设来生成代码，或者忘记了之前说好的约定。这时候不要试图“纠正”它，直接开一个新会话，把关键信息重新贴进去。在长任务中，我通常会每隔一段时间就保存一下当前的状态总结，这样即使上下文丢了，也能快速恢复。
6.4 性能与成本的平衡
Claude 的使用是有成本的，尤其是当你频繁处理大项目的时候。我的经验是：把贵的模型用在关键环节（比如方案设计、复杂逻辑实现），把便宜的模型用在辅助环节（比如写注释、生成提交信息）。另外，不要让 Claude 去读整个项目，只让它读相关的文件，这样能显著减少 token 消耗。
6.5 团队协作中的注意事项
如果你在团队里推广 Claude Code，有几件事要提前做好：一是统一 AGENTS.md 的模板，让所有人的 Claude 行为一致；二是建立代码审查机制，Claude 生成的代码也要走正常的 review 流程；三是定期分享使用技巧，让团队成员互相学习。我见过一些团队因为缺乏规范，每个人用 Claude 的方式都不一样，结果代码质量参差不齐。
7. 我个人的一些实操心得
用了这么久 Claude 写代码，最大的体会是：它改变的不是“写代码”这个动作本身，而是“思考代码”的方式。以前我花很多时间在敲键盘上，现在花更多时间在描述需求、审查方案、验证结果上。这个转变一开始不太适应，但习惯了之后会发现整体效率提升很明显。
另一个心得是：不要指望 Claude 一次就做对。把它当成一个很快但需要指导的初级工程师，你的任务是给它清晰的方向、及时的反馈、以及必要的约束。当你把这三样给足了，它的产出质量会超出你的预期。
最后分享一个小技巧：在 AGENTS.md 里加一条“每次修改代码后，用一句话总结改了什么”。这个习惯能让 Claude 的输出更聚焦，也方便你快速了解它的改动。我加了这条之后，审查代码的时间大概少了三分之一。
