三问定乾坤：让 Claude Code 写出可直接上线的代码
写代码前，Claude 需要你先回答三个问题
在你发 prompt 之前，Claude 会从你的描述里猜这三件事：
- 要建什么？ “登录系统”可能是简单的密码比对、完整的 OAuth 流程、或基于 JWT 的 API。你没说，Claude 就随便挑一个。
- 行为该怎么约束？ 出错是直接停掉，还是返回结构化错误？要不要记日志？是否校验输入？要不要哈希密码？这些不指定，Claude 会用最简默认值。
- 结果长什么样？ 一个独立函数？一个模块？带文档字符串的类？纯代码还是带解释？你不说，Claude 就自由发挥。
任何一个没回答，Claude 都会用自己的猜测补上。输出不会错，但肯定不是你想要的样子。
发 prompt 前花三秒想清楚：What, How, Format。就这三个词，能稳定提升输出质量。
写有效的 prompt
弱 vs 强
弱 prompt：
“写一个用户认证函数。”
Claude 会给你一个用户名/密码的简单校验，没有错误处理，没有哈希，没有结构。功能上正确，但上不了线。
强 prompt：
“用 Python 和 FastAPI 写一个用户认证函数，使用 JWT 令牌。验证凭据时要查数据库，签发 15 分钟过期的令牌，并返回结构化 JSON 响应。每个步骤加 docstring 和中文注释。”
四个补充：框架（FastAPI）、语言（Python）、预期行为（JWT、过期、JSON）、输出格式（docstring、注释）。Claude 现在知道“完成”是什么样子了。
链式思考（Chain-of-Thought）与 Extended Thinking
让 Claude 先推理再写代码，能显著提高最终质量。
不先推理：
“写一个 FastAPI 端点计算阶乘。”
Claude 经常给一个递归函数，没有输入验证。正整数能跑，负数和超大数直接崩溃。
先推理：
“在写代码之前，请先列出你的设计方案：FastAPI 端点接受一个数字并返回阶乘。然后写出完整实现，包含输入验证、错误处理和注释。”
Claude 先列出计划——输入 schema、递归 vs 迭代、边界情况（负数、零、超大数）、JSON 输出——然后代码完全匹配计划。结果更安全、更容易调试。
有一点需要注意：在 Claude 的 Extended Thinking（扩展思考）功能出现之前，链式思考是标准做法。Extended Thinking（Sonnet 4.6 和 Opus 4.6/4.7 可用）允许 Claude 在生成输出之前有一个独立预算的推理过程——你可以在 API 响应中查看推理轨迹。对于复杂编码任务，Extended Thinking 通常比手动链式思考效果更好。如果你使用的套餐支持它，在架构决策、复杂调试和多步骤重构时开启它。当 Extended Thinking 不可用，或者你需要推理出现在 Claude 响应的行内时，手动链式思考仍然有用。
无论哪种方式，Anthropic 的文档有一个一致发现：一定要让 Claude 输出它的思考过程。如果推理过程没有出现在响应中，说明推理步骤没有运行。
多文件 prompt
真正的项目横跨多个文件。Claude 能处理得很好——只要你的输入结构清晰。
坏的示范： 把五个文件丢进 prompt 里，不贴标签。Claude 搞不清哪个文件是哪个，也不知道它们之间的关系。
好的示范： 每个文件用清晰标题标记，并在开头说明目标。
Claude，我将分享两个 FastAPI 文件。请分析验证逻辑是如何在两个文件中处理的，
并重构它们以消除冗余。
## FILE: validators.py
[代码]
## FILE: main.py
[代码]
请给出两个文件的完整修正代码。
Claude 理解模块关系，一次完成跨文件重构。Sonnet 4.6 和 Opus 4.6/4.7 的 100 万 token 上下文窗口让你可以这样喂入大型代码库——多个文件、完整文档、测试套件都装得下。
CLAUDE.md：项目级规范
在 Claude Code 中，标准机制是 CLAUDE.md——放在项目根目录（或子目录用于本地规则）的一个文件。Claude 在会话开始时自动读取。
一个 CLAUDE.md 可能包含：
# 项目规范
- 语言：Python 3.12, FastAPI 0.115
- 所有公开函数必须包含 docstring
- 使用 Pydantic v2 模型做请求/响应 schema
- 永远不使用 eval() 或 exec()
- 所有数据库查询经过 Repository 层，路由处理器中不得出现裸 SQL
- 密钥只从环境变量获取
Claude 会根据目录结构自动合并多个 CLAUDE.md——根目录放全局规则，子目录放局部覆盖。这跟高级工程师的思维方式一模一样：项目级约定加上文件级特定约束。
对于 API 用法，系统提示词（system prompts）作用相同——设置一次，该会话中的所有请求都继承这些规范。
关于安全护栏的特别提醒： 把 prompt 当成日志来对待。假设它们可能被审查。不要在 prompt 里放密钥或凭证。把工具权限限制到 Claude 完成任务所需的最小范围。任何涉及认证或访问控制的任务，都要有一个人工审核环节。
最佳实践
初学者
- 每次发送 prompt 前，先过一遍 What, How, Format 检查。
- 调试时直接把完整错误信息贴进去。Claude 看到完整堆栈跟踪时诊断效果最好，而不是你转述的版本。
- 让 Claude 解释它的推理：“你为什么选择了迭代而不是递归？”答案会教你它是如何建模问题的。
有经验的开发者
- 在每个项目中提交一个
CLAUDE.md。保持简短和明确——具体的规则胜过冗长的文档。 - 在多文件 prompt 中清晰标记文件。在顶部说明目标，然后粘贴文件。
- 对复杂任务使用 Extended Thinking。将 effort 设为
xhigh——Anthropic 自己的文档推荐将其作为大多数开发场景的默认值。 - 对于非常长的自主运行，使用子代理：“你刚写好了支付处理器。现在用一个子代理对那段代码执行安全审查。”这样主对话保持专注，审查在独立上下文中运行。
常见 prompt 错误 (已转换为列表)
- 输出太泛：prompt 缺少框架、格式或行为约束。→ 补充具体的语言、库和输出要求。
- 输出被截断：超过了最大 token 限制。→ 要求分段输出，或者先总结再展开。
- Claude 忽略部分 prompt：一次性塞了太多指令。→ 拆分成顺序的 prompt。
- 错误的 import 或语法：缺少版本上下文。→ 指定库版本：“FastAPI 0.115, Pydantic v2”。
- Claude 自相矛盾：上下文漂移。→ 重新锚定：“我们仍然使用 FastAPI 0.115 和 PostgreSQL”。
Prompt 是对话，不是单次命令
那些最会使用 Claude 的开发者都把 prompt 当成对话，而不是一次性命令。先从足够宽泛的描述开始，看看 Claude 如何理解问题；根据返回结果细化；让它解释自己的选择。
每一次迭代都在提升输出质量。久而久之，你会培养出一种直觉：什么时候该给出严格约束，什么时候该留给 Claude 解读空间——紧规格能产出更好的代码，但松散的描述有时会浮现出更优的架构。Anthropic 自己的最佳实践指南说得很直白：有时候一个模糊的 prompt 恰恰是对的，因为你想看看 Claude 如何解读问题，然后再去约束它。
总结
Prompt 是一项技能，学习曲线短，但天花板很高。基础就是：
- 发送前先回答 What, How, Format 三个问题。
- 需要推理的任务用链式思考或 Extended Thinking。
- 多文件输入要清晰标记。
- 把项目规范存进
CLAUDE.md，不用每次重复。
试试这个： 拿出你最近写的一段代码。先写一个弱 prompt——就“改进这个函数”。然后用三个问题写一个强 prompt。对比一下 Claude 返回的结果。差别会非常明显，然后你就再也回不去那种模糊的 prompt 了。
