1. 快速原型：从零到可运行看板只花了一个午休
做开发这几年，我见过太多好想法死在“写代码太慢”这一步。需求评审时说得头头是道，一落到代码上，光搭项目骨架、配路由、连数据库就能磨掉一整天。直到我把 Claude Code 正式用在日常开发流里，才意识到 AI 编程助手真正值钱的地方不是帮你糊一屏“能跑的代码”，而是它能把“想清楚”和“写出来”之间的链路压缩到极短。
先交代一下背景。我平时主要用 VS Code 写业务代码，偶尔也会跑一些内部工具、数据分析脚本。Claude Code 是 Anthropic 出的命令行编程助手，可以直接在终端里跑，也能作为 VS Code 插件使用。它最大的特点不是“聊天写代码”，而是能直接读写你项目里的文件、执行命令、跑测试，像一个坐在你旁边的结对程序员，而不是一个只会输出代码片的聊天机器人。
我第一次用它做原型，是给运营部门搭一个内部投放数据看板。需求本身不复杂：每天从数据库里拉一次投放数据，算出点击率、转化率、成本，然后展示成一个简单的网页表格加图表。但问题在于，公司的数据存在一个老旧的 MySQL 库里，表结构混乱，字段命名极不友好，运营那边又催得急，说下周就要看效果。
换作以前，我的流程是先花半天搭个 FastAPI 后端，再花半天写个前端页面，最后还要处理跨域、数据库连接池这些问题。但那天我正好在午休，想着试一下用 Claude Code 直接把这个东西“说”出来。
我打开终端，进入一个空的临时目录，执行了claude启动交互，然后输入了这样一段话：
帮我搭一个投放数据看板： 1. 后端用 Python FastAPI，提供 /api/summary 接口，从 MySQL 的 ad_daily_stats 表读取数据，按日期聚合返回点击率、转化率、花费和 ROI 2. 前端就一个静态 HTML 页面，用 ECharts 画近 7 天的趋势图，页面要简洁，直接可用 3. 数据库连接信息放到 config 文件里，不要硬编码大概过了十几秒，Claude Code 开始在目录里自动创建文件。我能看到它逐个写入main.py、config.py、index.html、requirements.txt，中间还自己问了我一句：“数据库表里的 date 字段是 DATE 类型还是 DATETIME？我需要确认一下查询时是否要加 DATE() 函数。”这个细节让我挺意外，说明它不是拿模板硬套，而是真的在读我的需求之后做了判断。
等它写完，我在终端里执行了pip install -r requirements.txt和uvicorn main:app --reload，打开浏览器，页面直接出来了。整个流程从我开始输入提示词到看到页面，大约 15 分钟。数据库连接那块我配置好 MySQL 账号密码后，数据也正常拉出来了。那一刻我最大的感受是：原型阶段最大的成本已经从“写代码”变成了“把需求描述准”。
不过这里要提醒一句，快速原型看着爽，但并不是没有坑。AI 生成的代码风格和你自己的习惯多半不一样，特别是项目结构上，它倾向于把所有东西放在少数几个文件里。如果你是在一个长期维护的工程里做原型，最好先在提示词里就限定目录结构，否则后面整理代码会多花时间。我的做法是，在 prompt 里加一句“后端拆成 main.py 和 db.py，前端文件放 frontend 目录”，这样生成出来的东西就算不完美，至少骨架是清晰的。
还有一个容易忽略的点：权限范围。Claude Code 默认只在你启动它的那个目录里干活，不会乱动别的项目。但如果你用了--dangerously-skip-permissions之类的参数，它的操作范围就会扩大，这在临时目录里还好，在自己的正式项目里千万不要这样搞，风险太大了。后面我会专门再说权限这个话题。
2. 代码审查：让我不再害怕打开同事的 Pull Request
代码审查这件事，做久了你就知道，真正让人头疼的不是“看代码”，而是“看代码之前先要理解上下文”。尤其是接手别人写了一半的业务模块，光搞清楚数据流是怎么走的就够你看半天，更别提还要从里面找出潜在问题。
我现在收到一个 Pull Request，会先让 Claude Code 帮我做第一轮初筛。做法很简单：把 PR 的分支切到本地，进入项目目录，启动 Claude Code，然后给一个类似下面这样的指令：
请帮我审查当前分支的代码改动，重点关注： 1. 有没有空指针、数组越界这类明显的运行时风险 2. 数据库查询有没有 N+1 问题或者缺少索引的情况 3. 新增的接口有没有鉴权逻辑，参数校验是否完整 4. 有没有明显的重复代码，是否可以抽取公共方法 只列高风险问题，不要逐行点评代码风格为什么只列高风险问题？因为 AI 审查如果放得太宽，你会收到一份几十条的清单——变量命名不规范、函数太长、注释不够——这些大多数是“噪音”，淹没了真正值得关注的问题。把审查范围收窄到运行时错误、性能隐患、安全漏洞这三类，它的准确率会明显提高，也更有助于你快速决定要不要深度介入这个 PR。
实际用下来，Claude Code 在代码审查上最擅长的其实是“读代码路径”。比如有次同事改了一个订单详情接口，改动本身只有七八行，但 Claude Code 顺着调用链往下看，发现这个接口被一个定时任务调用，而定时任务里对返回结果做了非空判断，如果接口改了返回结构，定时任务那边就会悄悄出问题。这个点如果只盯 diff 看，很容易漏掉，因为问题根本不在改动的地方，而在改动“影响”的地方。人类审查员通常需要花时间在代码库里跳转才能发现的跨文件影响，Claude Code 可以在几秒内完成。
当然，它也不是没有缺点。我遇到过几次 Claude Code 为了“安全”而给出过度保守的建议。最典型的一次，它建议在某个接口里把日志级别改成 ERROR，理由是“避免在生产环境打印过多 INFO 日志”。这个建议本身没错，但它没考虑到这个日志是给数据分析那边捞数据用的，改了会直接影响别人的统计任务。这就是 AI 审查和人工审查的本质区别：AI 看到的是代码，但看不到业务约定。
所以我的经验是，让 Claude Code 做代码审查时，一定要把“背景信息”喂给它。你可以在 prompt 里补充一句“这个接口的调用方包括移动端和定时任务，返回结构变更需要同步修改调用方”，它就能更好地判断哪些改动是真正有风险的。审查结果最终还是要你人肉确认，但工作量已经少了一大半。
还有一个小技巧：分阶段审查。第一次让 Claude Code 只做“问题发现”，输出一个风险列表。然后你挑出其中你认为值得深究的几条，再让它针对这几条做“深度分析”，比如给出触发条件、影响范围、修复建议。这样比一开始就让它输出一个“完美方案”更高效，因为后者生成的内容往往过于泛化，反而没有参考价值。
3. Bug 调试实录：一次接口超时问题的完整排查过程
如果说原型和审查让 Claude Code 像一个“高效的工具人”，那 Bug 调试这个场景，才让我真正觉得它是一个会思考的助手。
先说这个 bug 的现场情况。我们有个内部系统，每天凌晨会跑一批批量任务，往一个第三方平台同步数据。这个流程跑了半年都很稳，但有一阵子开始随机报超时错误，平均每天三四次，而且不是固定在某条数据上。这种“偶现 bug”是最烦的，因为它很难稳定复现，你没法在测试环境里等它出错。
以前排查这种问题，我的流程是：先看日志，找到超时的具体接口；然后去代码里找这个接口的逻辑，看有没有明显的阻塞点；如果看不出来，就加日志、重新部署、等它再出错，很多时候一等就是一天。
这次我换了个方式。我让 Claude Code 先读一遍同步模块的代码，然后把它拉到“排查模式”：
我有一个定时同步任务，日志里看到偶发的 requests.exceptions.ReadTimeout，错误发生在调用第三方接口时。请分析整个同步模块的代码，找出所有可能导致超时或者重试后仍然失败的地方，并按可能性从高到低排序。注意看一下连接池配置和重试逻辑。Claude Code 花了一会儿翻代码，给出的分析结果里有一条让我一下子警觉起来。它提到：代码里用的requests.Session()是在一个循环里反复创建的，而且没有显式关闭连接。它判断这可能导致“连接没有复用 + 文件描述符泄漏”，在高并发或长时间运行后出现连接耗尽。说实话，这个问题我看了很多遍代码都没注意到，因为平时大家更关注的是网络波动和第三方接口本身的稳定性，很少有人会去数“每次请求是不是都新建了 Session”。
顺着这个方向，我查了服务器上的连接状态，用ss -s看了 TCP 连接数，发现确实存在大量TIME_WAIT状态的连接。这几乎坐实了 Claude Code 的判断。改法也简单，把 Session 提到函数外面复用，或者用with语法保证用完即关。改完之后部署上去观察了三天，超时错误再没出现过。
这次经历让我总结出一个规律：让 Claude Code 做 bug 定位，最好给它“现场证据”，而不是只给它看代码。比如你贴一段报错日志，告诉它“错误发生前最后一次成功请求是什么时候”，它的分析起点就会从一堆代码里收敛到具体路径上。我现在的做法是，遇到疑难 bug，先跑一个数据收集命令，把相关日志抽出来，连同代码路径一起给 Claude Code，而不是直接打开对话就让它“帮我查 bug”。这个输入方式上的差异，对排查效率的影响非常大。
还有一点值得说：它的“假设-验证”循环对调试很有帮助。你可以在对话里直接问它“是不是 xxx 导致的？”，它会给出“是”、“否”或者“不完全对”的判断，然后基于代码证据解释理由。这种交互比一次性让它给结论更靠谱，因为你的项目上下文是你最清楚，AI 负责补全你没有注意到的盲区。
4. 日常使用中的常见问题与避坑经验
光说不练假把式，用 Claude Code 跑了快两个月，我踩过不少坑，也攒了一些心得。这里挑几个最常见的问题集中说一下，给准备入坑的朋友省点时间。
第一个坑：让 Claude Code 在一棵巨大的代码树里“自由探索”。
如果你的项目有几万个文件，直接让它“看看这个项目结构”，它会被淹没在无关文件里，响应速度变慢，分析也会跑偏。我的做法是在启动时先把工作目录限定到相关子模块，比如claude src/services/order，这样它能聚焦在真正相关的代码上。我试过让它全仓扫描，最后它给的结论基本都在猜，还不如直接给它指个方向。
第二个坑：关于模型选择的一些补充说明。
Claude Code 默认使用 Anthropic 自家的模型，但随着生态发展，它也支持接入第三方模型，比如通过兼容接口接 DeepSeek、Ollama 这样的本地模型。我自己试过接本地模型跑一些小项目的代码补全，好处是数据不出本机、不消耗云端 token，但说实话，在复杂代码理解和多文件跳转上，本地开源模型和云端模型还是有差距。所以我的用法是：日常写业务代码、改简单 bug 用本地模型省钱省心，处理跨模块重构、复杂调试这类“硬仗”切回云端模型。这个搭配方案我后来发现网上也有人推荐，算是比较主流的分工思路。
第三个坑：token 消耗比想象中快，尤其是大文件场景。
Claude Code 处理大文件或者多文件修改时，token 消耗是肉眼可见的。我有一次让它帮我统一给项目内的所有接口加上异常处理，它很勤快，但那次对话把当天的配额用掉了一大半。后来我学乖了，凡是大范围改动，先拆成小任务，一次只改一个模块。另外，可以在对话里明确说“只读取，不要修改”，让它先给方案，你确认后再让它动手，这样可以避免生成大量无效代码、白白烧 token。
第四个坑：权限问题。
Claude Code 执行 shell 命令的能力很强，这也是它比纯聊天工具更好用的原因。但能力越强越要小心。第一次使用它的时候，系统会提示你选择权限模式，我一开始图省事，想放开限制让它“放开跑”，仔细想了想还是收敛了。日常使用，我建议只在信任的项目目录里放行它的命令执行权限，并且定期看下它都执行了哪些命令。它有日志和审计记录，养成习惯，每次跑完扫一眼，能避免很多意外。
第五个坑：它的建议不一定适合你的技术栈。
Claude Code 的知识库覆盖很广，但每个团队的技术选型和内部约定它是不清楚的。比如它可能建议你引入一个你没用过的新框架，或者建议用某种设计模式重构一段已经很稳定的老代码。这种时候不要盲目执行。我的原则是：新项目、非核心模块、一次性脚本，胆子可以大一点，让它放开折腾；老系统、核心链路、高并发模块，它的意见只作为灵感，最终决定权还是在自己手里。
再补充一个实用的对比维度。网上经常有人问“选 Codex 还是 Claude Code”，我两个都用过，简单说下感受：Codex 在纯代码生成上的表现很惊艳，适合“我给你一个问题，你给我一段能跑的代码”这种场景；Claude Code 则更像是“和我协作干活”模式，它在理解既有代码、跨文件改代码、执行操作链路上更强。简单说，你要的是“一个能写的代笔”，选 Codex；你要的是“一个能一起干活既要写还要查还要跑的搭档”，选 Claude Code。当然现在两个产品都在快速迭代，功能边界也在收窄，但就我个人的工作流来说，Claude Code 在代码审查和 bug 排查上带来的效率提升是 Codex 没法比的。
5. 关于工作流的一些后续扩展想法
Claude Code 不是只能做我上面提到的那三件事，把这套交互方式沉淀成自己的工作流之后，它的玩法还能再往外延伸。
我现在最常用的是“分诊台”模式。每天早晨到公司的第一件事，就是把头天夜里用户反馈的错误日志汇总一下，丢给 Claude Code，让它先做一轮归类——哪些是偶发超时，哪些是数据问题，哪些可能是代码 bug。它处理完之后，我再按优先级决定哪些需要立刻跟进，哪些可以先攒着。这一步帮我省掉了大量“打开项目、搜索代码、确认功能逻辑”的时间，等于每天早上都有人先帮你把积压的弹药分好类。
另一个我觉得潜力很大的方向，是让它帮忙写测试数据。以前写单元测试最痛苦的部分就是构造 fixture，尤其是关联了多张表、多个状态的对象。Claude Code 可以读实体类定义，然后直接生成对应的测试数据构造代码，而且它生成的字段名会老老实实按照数据库里的真实字段来，不会自作主张改命名。这个看着不起眼，但对我这种懒得写测试的人帮助特别大，因为最大的心理门槛被抹平了。
最后说一点个人体会。很多人担心 AI 编程助手会让程序员丧失基本功，我的感受恰恰相反。用 Claude Code 越久，我对“什么代码是好的代码”反而越敏感。因为你会频繁看到它生成的代码，有时比你自己写的更合理，有时则隐隐不对味——这时候你就得调动自己的经验去判断。这种“随时有人给你交方案，你来把关”的状态，其实很锻炼代码品味。
当然它也会出错，也会看不懂业务背景，也会一本正经地给出不合适的建议。但把它当作一个反应迅速、涉猎极广的结对伙伴，而不是一个无所不能的自动写码机器，你会发现自己能从中榨出的价值远超预期。至少在快速原型、代码审查、bug 定位这三个场景里，它已经是我每天离不开的工作搭档了。
