AI Claude踩坑记录

先复现，再谈优化。

Claude 在小范围内能给出更细致的建议，包括：

• 命名是否清晰
• 异常处理是否完整
• 是否有过度设计
• 是否有潜在的性能问题

起因：为什么要换到 Claude

最开始我主要用 OpenAI 的产品，API 调用顺手、生态成熟、社区资料多。但日常对话和代码辅助场景下，有几个问题越来越明显：

• 长文本记忆不稳定，聊久一点就「忘了」前面的约束
• 偶尔会出现幻觉输出，但看起来又很有说服力
• 对中文语境的理解有时候差一截，需要反复对齐

换到 Claude 后的第一感受是：约束给清楚时，它更愿意照着做，少自作主张。写代码审查清单、固定输出格式这类任务，比自由发挥的对话省心。

另一个现实原因：价格。2025 年末的 API 价格战之后，Claude 的性价比在长上下文场景下有优势。尤其是要处理大段代码、文档、历史记录时，按 token 算账的感受更直观。

使用场景一：代码审查与重构

这是我用得最多的场景。典型流程是：先把代码贴过去，问它「这段有什么问题」，然后根据反馈再问「你建议怎么改」。

具体做法

我习惯按模块拆，不会一次性把整个项目扔进去：

• 先贴核心业务逻辑，问它「这段在做什么、潜在风险是什么」
• 再贴辅助函数和工具类，让它检查重复代码、边界条件
• 最后贴配置文件和环境变量，看有没有硬编码、敏感信息泄露

这个分步过程的效果比一次性扔整个仓库好很多。Claude 在小范围内能给出更细致的建议，包括：

• 命名是否清晰
• 异常处理是否完整
• 是否有过度设计
• 是否有潜在的性能问题

限制与边界

但实际用下来，边界也很明显：

• 它不理解项目整体架构，除非你反复灌输上下文
• 对业务规则的判断很有限，容易给出「看起来合理但不符合业务」的建议
• 重构建议有时会过度抽象，需要手动评估是否值得

所以我现在把它当成「第二双眼睛」——它能帮我注意到自己忽略的细节，但最终决策还在我。这不完全是模型能力的问题，而是上下文限制和领域知识的天然缺口。

这张图想说的是：让模型帮忙审查代码，关键在于分阶段提问。先搞清楚它在做什么，再看有没有风险，最后评估建议是否合理。省略任何一环，都容易得到「看起来专业但不适用」的输出。

使用场景二：技术写作与内容生成

写这篇文章时，我确实用 Claude 辅助了部分段落。主要用它帮我：

• 跳出既定表达，找到新的叙述角度
• 把零散的想法串成结构化的草稿
• 检查技术术语的使用是否一致

写作流程

我的写作流程会先自己动笔，再让 Claude 补位：

1. 自己先写个粗糙大纲
2. 用 Claude 帮我检查逻辑是否有漏洞
3. 逐段写草稿，写完一段就让它看看「这段哪里没说清楚」
4. 最后再让它整体扫描一遍，找用词重复、结构混乱的地方

这个流程里，Claude 更像编辑：它能指出我没意识到的漏洞，但哪些该展开、哪些该收束，还是我自己定。

这张图是典型的人机协作写作流程。关键在于：每一步都自己先做，再用模型补足。反过来做——先让模型生成、自己再改——很容易得到一篇「看起来不错但没有灵魂」的东西。

幻觉风险

写作场景里最大的风险是幻觉。Claude 偶尔会：

• 编造不存在的概念或术语
• 把相近的概念混为一谈
• 在不熟悉的领域给出看似专业但经不起推敲的解释

所以现在我养成了习惯：让它解释观点背后的来源，然后自己去查证。AI 模型当不了可靠的事实检索引擎，这点边界得自己心里有数。

使用场景三：问题排查与调试

排查 bug 时，Claude 能在几个方面帮上忙：

• 解释报错信息的含义
• 提示可能的排查方向
• 帮助理解陌生代码的意图

实际案例

最近在调试一个 Kubernetes 部署问题时，Pod 一直 CrashLoopBackOff，但日志里没有明显错误。我把：

• 部署 yaml
• Pod 状态描述
• 部分日志片段
• 最近的变更记录

贴给 Claude，它给出的排查路径是：

1. 先检查 liveness probe 和 readiness probe 的配置是否合理
2. 看看是不是启动时依赖的资源还没就绪
3. 检查资源限制是否过低导致 OOM
4. 查看容器镜像是否与当前环境兼容

这个顺序很合理，不是瞎猜。按这个路径排查，最后发现是 readiness probe 的超时时间设置过短，导致服务启动就被判定为不健康。

这张图想说明的是：模型在排查问题时，能给出一个相对系统的排查路径。它不会直接告诉你答案，但能帮你避免在错误的方向上浪费太多时间。

限制条件

但这个场景的限制同样明显：

• 它不了解你的基础设施细节，除非你详细说明
• 对分布式系统的复杂问题，它给出的建议可能过于简化
• 无法直接执行操作，需要你手动执行命令并反馈结果

所以现在我把 Claude 当成「远程同事」——我可以把问题描述给它，听听它的看法，但具体执行和判断还是靠自己。

踩坑记录

用到现在，踩过的坑不少。挑几个典型的说。

坑一：上下文膨胀

早期习惯是每次对话都从零开始，把历史记录不断往上堆。结果发现：

• 响应速度越来越慢
• 模型开始「忘」前面的约束
• API 费用蹭蹭往上涨

现在的做法是：

• 每个任务开一个新的对话会话
• 在会话内保持上下文，但避免跨会话引用
• 需要跨会话的信息，自己维护文档或笔记，再按需喂给模型

这张图对比了两种使用方式。早期那种「把所有历史都保留」的做法，看起来省事，响应却越来越慢，模型还更容易偏离原始意图。

坑二：过度依赖

有一段时间，遇到问题第一反应是「问 Claude」，而不是自己先查文档、看源码。结果是：

• 理解深度不够，只能停留在表面
• 没形成自己的知识体系，下次类似问题还得问
• 对模型输出失去判断力，容易被带着跑

现在给自己定了规矩：

• 先自己找答案，最多花 30 分钟
• 没思路再问模型，但要说明自己已经做了哪些尝试
• 模型给出的建议，要去验证而不是直接照搬

坑三：信任边界

有时候模型给出的答案看起来很合理，但实际一跑就错。原因可能是：

• 它不了解你的环境约束（版本、配置、依赖）
• 它把不同场景的经验混在一起了
• 它在你不熟悉的领域里幻觉

现在养成习惯：对模型给出的任何技术建议，尤其是涉及配置、命令、版本号的部分，都要：

• 自己查官方文档验证
• 在测试环境先跑一遍
• 找到可信的来源交叉确认

结果：现在怎么用 Claude

经过这段时间的磨合，我对 Claude 的定位基本清楚了。

它适合什么

• 作为「第二双眼睛」，帮我检查自己忽略的细节
• 作为「头脑风暴伙伴」，帮我跳出既定思路
• 作为「实时解释器」，帮我理解陌生代码或文档
• 作为「草稿编辑」，帮我整理和润色文字

它不适合什么

• 作为「最终决策者」，它的建议需要我来评估
• 作为「事实检索」，它给出的信息要去验证
• 作为「领域专家」，在专业领域还是靠自己积累

使用原则

现在我的使用原则就几条：

• 先明确问题，再问模型，避免把思考外包
• 把它的输出当成建议，而不是答案
• 保持对输出的判断力，不盲目信任
• 在自己熟悉的领域，用它的视角补足盲点
• 在自己不熟悉的领域，用它做快速入门，但最后还是要深挖

结语

Claude 是个好工具，但它就是个工具。它能放大我的能力，但代替不了我的判断。

现在我对它的期望已经从「它什么都能解决」收敛到「它在某些地方能帮上忙」。知道它擅长什么、不擅长什么，该问就问，该自己查就自己查，反而用得顺。

Claude 就是个工具。好工具能放大能力，但代替不了判断——这点用久了自然会接受。

版权声明: 本文首发于 指尖魔法屋-AI Claude踩坑记录（https://blog.thinkmoon.cn/post/399-ai-anthropic-claude-claude-actual-practice/） 转载或引用必须申明原指尖魔法屋来源及源地址！