作者：我本人。没错，这篇文章也是 Claude 帮我润色的—— 但前提是，我先花了数小时把所有思考和经验完整写了出来。
使用一个工具却不看使用指南，就等于花时间和金钱一次次撞墙。当然，墙最终总会被撞开，但你为此消耗的精力是原本的 10 倍。先看指南，才是磨利斧头。
我很喜欢一句话：
“如果给我六小时砍倒一棵树，我会先用前四小时磨利斧头。”
黎明薄雾森林里，伐木工正在特写镜头下用磨刀石打磨巨斧，火花轻柔飞溅。氛围专注、从容、沉静。浅景深，暖调黄金时刻光线穿透雾气。照片级写实风格。
我以前用 Claude Code 就是这种状态：打开对话，脑子里只有模糊想法，随便“想”十分钟，然后剩下的时间都在跟 AI 拉扯，让它产出一段像样的内容。 Token 一点点消耗，时间一小时小时过去——不是 Claude 做不到，而是我根本没准备好如何指挥它。
直到我开始在打开终端前真正做规划，一切才彻底改变。这是我学到的东西。
使用 Claude Code 的两种方式（其中一种会把你坑惨）
方式一：随缘乱问，听天由命
打开 Claude Code，输入类似：“把我的 JavaScript 转成 TypeScript。”
Claude 能做到吗？能。 它会顺利做到吗？最终也许会。 但真实过程是这样的：
你会先花掉约 10 万 Token，只为让它明白你**真正想要什么。**再花 10 万做项目规划。 再 10 万改 bug。 再 10 万做迭代。
恭喜你——一个功能都没上线，月度 Token 额度先见底了。 这不是夸张，这是大多数开发者都会踩的坑，只是很多人硬扛过去而已。
方式二：磨利斧头再开工（我踩过无数坑才总结出来）
在打开终端之前，先做这些不起眼但至关重要的事：
1. 把你的想法完整写出来
不是简单的要点列表，而是一段完整的叙述。 比如：“我想做一个应用，让人们可以互相确认状态、报平安。” 把它展开：边界场景、设计动机、解决的问题。 把所有想法倒进一个文档：PROJECT-UNDERSTANDING.md。
2. 认真打磨这份文档
因为它真的很重要。 修正缩进、整理标题、清理列表格式。 这不是无用功——大模型非常依赖**结构。**一份格式清晰的文档，产出效果远好于一堆意识流文字。 自己重读一遍，甚至让朋友读一遍。 如果他们不用提问就能看懂你的项目，你就准备好了。
3. 自己选定技术栈
不要让 AI 替你决定。 不是它不行，它完全能给出合理选择。 但你最终会得到一个自己不完全理解的代码库，所有决策都不是你做的。 这就是巨型技术债的源头，要花好几个月才能清理干净。 熟悉你的技术栈，掌控它。
4. 给功能排优先级
按顺序写下来： MVP 核心功能 → 附加功能 → 未来规划。 当 Claude 开始出现需求蔓延时，这就是你的北极星。
正确搭建项目的方式
当你的理解文档足够清晰后： 创建项目目录，用最精简的基础结构初始化项目， 把 PROJECT-UNDERSTANDING.md 放进去， 再配上一份你自己写的简短 README.md。
现在打开终端，输入那个神奇的命令：
claude
在做任何事之前，**先切换到 Sonnet 4.6，**然后运行：
/init
看看会发生什么： Claude 会分析你的项目结构、读取 Markdown 文件、理解技术栈， 然后自动生成一个 CLAUDE.md 文件—— 一份**活文档，**包含这个项目专属的规则、约定、边界、该做什么、不该做什么、如何在你的代码库中行事。
你刚刚给 Claude 装上了属于你项目的“大脑”。
正式开发阶段
从这里开始，工作流取决于你的项目类型。我主要做两类：纯后端服务和全栈应用。
对于后端项目，我永远先自己思考数据库结构。自己梳理实体、关系、数据流， 然后用“讲故事”的格式写出来，交给 Claude 做校验——不是生成，是校验。
当我对 schema 设计满意后，再下达指令：“用 Prisma 实现已通过的 schema。”（Prisma 仅为示例）
因为 Claude 已经从 /init 阶段和你的理解文档里完全理解了项目， 这一步只需要几分钟，而不是几小时。
紧接着再输入：“根据已创建的 schema，结合 @project-understanding 里定义的业务逻辑，生成一份数据库调用的实现方案。”
注意我做了什么： 我用 @ 直接指向文件。 这是 Claude Code 里引用文件的方式—— 它能避免 Claude 到处搜索、猜测，从而节省大量 Token， 并明确告诉它该看哪里。
TASKS.md 体系
在真正开始编码前，让 Claude 创建一个 TASKS.md 文件。 里面包含实现方案所需的**所有任务，**按阶段整理。
这会成为你项目的共享记忆。 Claude 按任务一步步执行，你永远知道进度在哪里， 会话之间不会丢失任何信息。
写出真正有用的提示词
一次高效会话和一次无效浪费，区别几乎全在提示词怎么写。
不要写：“把登录功能修好。”
要写：“在 Auth 模块中，登录控制器即便凭证正确也会抛出 401。错误信息如下：[粘贴控制台日志]。请查看 @auth.controller.ts，解释问题原因，然后给出修复方案，并推荐最优做法。”
清晰、直接、用 @ 指向文件、粘贴真实错误。 先让它解释问题，再让它修复——理解问题本身就是解决问题的一半。 Claude 经常会挖出你根本没注意到的隐藏问题。
当 Claude 给出修复方案时，通常会标注它推荐哪一种以及原因。 但**最终决定权在你。**去尝试、理解权衡、掌控你的代码库。
真正的核心教训
Claude Code 不是一个代码生成器。 它是一位能力极强的协作伙伴。 和任何伙伴一样，你准备充分，它表现才会最好。
那些疯狂消耗 Token 的开发者，不是因为 Claude 不行， 而是他们递给 Claude 一把钝斧头，却疑惑为什么树砍不倒。
先规划项目，梳理思路，正确初始化， 使用清晰、带文件引用的提示词。 然后让 Claude 做它真正擅长的事： 执行、校验、加速你已经思考清楚的工作。
想看这套完整工作流的实际演示？
我上面讲的一切——/init 流程、规划结构、提示词规范—— 都不是我原创的。 我是从这里学来的：
anthropic.skilljar.com/claude-code…
这就是我烧完第一月 Token 额度后，恨不得早点出现的指南。
去学吧。 在碰树之前，先磨利你的斧头。
-------------------------------------------------------------
