99% 的开发者都在错误使用 Claude（如何成为那 1%）
8 个月来，我一直把 Claude 当作搜索引擎来使用。提出基础问题，得到基础回答，总感觉没有发挥出它的全部潜力。
我发现了一种使用 Claude 的方法，现在感觉就像随时可以联系到谷歌工程团队一样。
不是 Medium 会员？点击这里免费继续阅读。
为什么大多数人错误使用 Claude
大多数人把 Claude 当作 Google 搜索或 Reddit 问答来对待。他们打开新对话，得到答案后就离开了。
这就像雇佣某人帮你 Google 问题，然后对结果什么都不做。
一些例子：
- "如何让 div 居中？"
- "最好的 React 状态管理库是什么？"
- "修复这个错误：..."
这些例子把 Claude 当作没有上下文的搜索引擎，只是随机提问，期待神奇的答案。
缺失上下文的问题：你不会在不解释你在做什么、尝试过什么或需求是什么的情况下，要求同事调试代码。然而...
95% 的用户从未点击过设置菜单。他们不知道网络搜索、Gmail 集成、文件上传或不同的对话风格。他们用战斗机在公路上行驶。
我以前做错了什么（为什么这很重要）
8 个月来，我一直有这个问题。
我会问 Claude："我应该如何实现 AWS 认证？"然后得到不适合我用例的通用 JWT 教程。
我会粘贴浏览器控制台的错误消息，但不解释任何上下文。
我会创建对话然后离开，不把这些输出作为其他问题的良好上下文重复使用。
我的结果：很多时候感觉不比 Stack Overflow 好。
为什么这很重要：糟糕的输入产生糟糕的输出，当你向 Claude 提供糟糕的简介时，你就会得到糟糕的答案。
让我效率提升 10 倍的发现
我正在调试一个 React 问题，截止日期临近。
我厌倦了问"修复这个错误"，然后它假设我在使用 NextJS。
我上传了整个组件、错误日志、package.json 和项目需求。然后我写道：
"你现在是我的高级 React 伙伴，我上传了一些关于我为什么卡住的问题。仔细思考这个问题，在回复修复方案之前，问我一些问题来更好地理解如何解决这个问题"。
发生了什么：Claude 在 2 分钟内修复了 bug，发现了架构改进，并交付了第一次尝试就完美工作的代码。以前需要我 1 小时的来回对话才能完成。
顿悟时刻：这让我意识到 Claude 不是搜索引擎，它需要适当的简介。
重复使用过去的对话：如果你喜欢结果，那就说"我喜欢这些结果，你能制作一个提示来帮助我将来实现这个吗"。
上下文革命：如何像高级开发者一样简介
级别 1 — 使用模板：
项目背景：
- 我正在构建的内容：[具体描述]
- 技术栈：[确切版本]
- 用户群体：[谁使用这个]
- 时间线：[截止日期和约束]
当前情况：
- 我试图实现的目标：[具体目标]
- 我已经尝试的方法：[之前的尝试]
- 阻碍我的因素：[具体问题]
- 成功标准：[好的结果是什么样的]
现在帮助我[具体请求]。级别 2 — 使用之前对话的提示：
"我喜欢这些结果，你能制作一个提示来帮助我将来实现这个吗"
级别 3 — 更新你的配置文件
Claude 配置文件设置
级别 4 — 使用项目
项目对于分割上下文窗口并将对话保持在一个区域非常有用。然后你可以保留项目知识以帮助所有进一步的聊天。
我喜欢的高级集成设置
Gmail 集成
示例提示：
分析我过去 30 天的邮件：
- 哪些客户最满意/最不满意（语调分析）
- 多个客户面临什么问题？
- 预算信号和扩展机会
- 更频繁请求的技术
格式化为可操作的商业智能。上个月这个分析发现了关键信息，3 个不同的通讯提到了一个新的 Python 库。我能够发现这个新兴趋势，与团队分享，现在我们在使用它。
集成帮助我意识到我忘记确认西西里岛之行的预订。
日历集成
开发者专用分析：
分析我的编码时间表模式：
- 我什么时候写出最好的代码 vs 只是维护现有代码？
- 哪些会议类型破坏了我的编程流程？
- 多少上下文切换在破坏我的生产力？
- 我什么时候应该批量处理管理任务 vs 深度工作？**发现：**我在早上编码效率高 3 倍，但在晚上进行最佳架构思考。现在我在下午安排代码审查和管理工作，保护早上的心流状态，晚饭后进行系统设计。
**结果：**从上下文切换的混乱变为优化的深度工作块。
我的企业级结果提示框架
SCALE 框架
- S — 情况：当前项目上下文和约束
- C — 上下文：技术栈、业务需求、团队结构
- A — 受众：谁使用这个，谁维护这个
- L — 限制：我们不能做什么，预算或时间约束
- E — 预期结果：成功是什么样的
示例提示：
通用开发者提示： "帮我在 GraphQL 和 REST 之间为我的 API 选择"
应用 SCALE 框架：
情况：为我的 SaaS 副项目构建 API，需要在 3 周内交付 MVP
上下文：React 前端，Node.js 后端，PostgreSQL，稍后会有移动应用
受众：1 人前端团队（我），6 个月后会雇佣初级开发者
限制：不能花几周学习 GraphQL，需要初级开发者可维护的东西
预期结果：现在快速开发，稍后容易扩展团队，移动端友好Claude 的回应质量：
- 通用："这是每个的优缺点..."
- SCALE："对于你的情况，使用带 OpenAPI 规范的 REST。原因如下：更快的 MVP 交付，初级开发者友好，这是确切的文件夹结构和使用模式..."
**节省的时间：**2 天研究 → 20 分钟针对性建议
模型选择（Opus vs Sonnet）
我使用 Sonnet 4 的时候（80% 的所有工作）：
- 代码实现和调试
- 邮件草拟
- 文档编写
- 快速问题
我使用 Opus 4 的时候（20% 的工作）：
- 系统架构决策
- 复杂业务逻辑设计
- 多步骤问题解决
- 创造性解决方案
真实例子：
**真实场景：**为我的副项目构建实时聊天功能。
**Sonnet 的方法：**基本的 WebSocket 实现，简单消息广播 **时间：**2 分钟得到工作代码 **结果：**适用于 5 个用户，20 个并发连接时崩溃
**Opus 的方法：**带 Redis pub/sub 的 WebSocket 集群、连接池和优雅回退 **时间：**5 分钟架构 + 实现 **结果：**扩展到 1000+ 用户，优雅处理服务器重启
**区别：**Sonnet 让我达到 MVP。Opus 让我达到生产就绪。那额外的 3 分钟在用户真正出现时为我节省了一次完整重写。
总结
我停止像使用 Google 一样使用 Claude，开始把它当作我最有经验的同事和新的个人助理。
你现在可以做什么
不要让这成为另一篇你忘记的文章，从系统中选择一件事并实施它。
- 如果你有 5 分钟：设置上下文模板
- 如果你有 10 分钟：设置 Gmail 集成并运行你的第一份报告
- 如果你有 15 分钟：设置 Google 日历集成并询问即将到来的会议
- 如果你有 20 分钟：学习这些十亿美元初创公司的提示
大多数开发者读了这些，想"很酷"，但继续向 Claude 提出简单问题，没有得到丰富的结果。
你不同，如果你读到了这里，那就说明你属于那类寻求成为生产力前 10% 的人。
这不仅仅是关于生产力，它正在改变你与工作、压力以及副项目可能性的关系。
Claude 是帮助我处理副项目和爱好的最重要工具。
问题不是你是否应该使用这些技术，而是你能否承受不使用它们的后果？
你有任何我遗漏的技巧吗？在下面评论。
如果你读了这篇文章并且喜欢，请留下掌声，这对我意义重大。关注我获取更多这样的文章！
我与 Claude 或其他提到的工具没有关联。所有分享的观点和经验都是我自己的。
