原始标题: Claude Code Clearly Explained (and how to use it)

发布日期: 2026-01-19 | 来源频道: @GregIsenberg

📝 深度摘要

1. 对话背景与核心主题

本指南探讨2026年如何用Claude Code构建真正可用的软件。核心观点：AI模型已足够好，但多数人产出的代码仍是"垃圾"，根因在输入需求太模糊。解决方案是工程化流程——先用PRD.md结构化需求，再通过Ask User Question工具深度挖掘细节。开发时采用测试驱动，每特性完成后写测试，通过才进入下一特性。建议新手别用R循环自动化，先手动跑通流程。关键指标是上下文控制在10万tokens以内。

2. 核心干货概览

维度 核心内容 / 动态 价值意义 / 影响程度
技术/工具 Claude Code + Ask User Question 工具 + PRD.md 规划流程 将 AI 代码生成从"随机产出"升级为"精准可控"的工程化流程
战略/逻辑 输入质量决定输出质量（Garbage In, Garbage Out） 彻底改变人与 AI 协作的底层心智模型，从"提需求"转向"做设计"
量化指标 200,000 token 上下文上限；建议控制在 50% 以下（即 100,000 tokens） 防止模型性能下降的核心量化红线
核心方法论 测试驱动开发 + 特性逐一验证 + R 循环自动化 让 AI 生成的代码真正可部署、可维护

2. 深度逻辑与实操拆解

底层矛盾与背景

2026 年的 AI 代码模型已经强大到"惊人"的程度——模型生成的代码质量在很多场景下已经超过人类工程师自己写的代码。然而现实是：大多数人用 AI 生成的代码依然是"slop"（垃圾）。为什么会这样？

核心矛盾：用户给出的输入太模糊、太粗糙。模型无法"肚子里的蛔虫"，它不知道你真正想要什么产品、你需要什么功能、你期望什么样的交互方式。如果你给的是一个模糊的"帮我做个 TikTok UGC 生成工具"，模型只能给你一个模糊的回应。

解决的根本问题：如何让人类向 AI 传达需求的方式，从"凭感觉描述"升级为"结构化工程化表达"。

核心策略推导

Ross Mike 提出了一套完整的"AI 软件工程方法论"，核心逻辑链如下：

  1. 第一层认知升级：理解"输入质量 = 输出质量"。把 AI 想象成一个人类工程师——如果你对人类工程师说"帮我做个东西"，他能做出什么？同样，AI 也需要清晰、具体、可执行的需求描述。

  2. 第二层工程化：用 PRD（产品需求文档）来结构化你的想法。不是简单地说"我要做个电商 app"，而是拆解成具体的特性（Feature）列表。PRD.md 就是你和 AI 之间的"合同"。

  3. 第三层深度挖掘：使用"Ask User Question"工具。这个工具会"采访"你——它会根据你的 PRD 不断追问细节：UI 风格选哪个？AI 脚本生成用什么模型？视频存储用本地还是云端？预算多少？这些细节是普通人根本不会在第一轮就想到的。

  4. 第四层验证驱动：每个特性开发完成后，立即写测试。测试通过才进入下一个特性。这就是为什么 R 循环现在真正可行了——因为模型足够好，你可以在每个环节做质量把控。

  5. 第五层自动化：当你熟练掌握以上所有流程后，再引入 R 循环来自动化执行。

执行 SOP / 操作步骤

步骤一：创建 PRD.md 规划文件

打开 Claude Code，使用 Shift + Tab 激活 Plan Mode，输入你的产品想法，例如：“帮我创建一个 TikTok UGC 生成工具，面向营销agency。请创建一个计划，写入 PRD.md 文件。”

步骤二：使用 Ask User Question 工具进行深度挖掘

不要用默认的 Plan Mode，而是显式调用 Ask User Question 工具。Prompt 示例：

"Read this plan file. Interview me in detail using the Ask User Question Tool about literally anything: technical implementation, UI/UX concerns, and trade-offs. Do not judge me."

这个工具会分多轮"采访"你：

  • 第一轮：核心工作流和技术基础（“你期望的 UGC 视频生成流程是什么？线性步骤？模板化？批量处理？迭代式？”)
  • 第二轮：API 成本管理（“你打算如何处理 API 费用？预算上限是多少？”)
  • 第三轮：UI/UX 和脚本生成（“你希望用什么 AI 模型做脚本生成？UI 风格选极简干净还是 dashboard 重度？”)

步骤三：手动逐个开发特性（不使用 R 循环）

假设你的 PRD 包含 4 个核心功能特性的开发：

  1. 告诉 Claude Code：“请开发第一个特性”
  2. 开发完成后，问：“我如何测试这个功能？”
  3. 让 AI 为该特性写测试用例
  4. 运行测试，测试通过后再进入下一个特性

步骤四：建立 progress.txt 进度文档

每完成一个特性，在 progress.txt 中记录进度。这样 AI 知道自己在哪个位置，不会重复劳动。

步骤五：引入 R 循环（可选，高级阶段）

当你已经熟练掌握以上流程，并且有一个"完美"的 PRD 时，可以使用 R 循环来自动化。配置你的 R 循环时，确保它：

  • 检查是否存在 PRD.md
  • 检查是否存在 progress.txt
  • 每开发完一个特性 → 写测试 → 运行测试 → 测试通过才进入下一个
  • 如果测试失败，自动回到上一个特性修复

步骤六：上下文管理

  • 监控上下文使用量（Claude Code 和 Cursor 都会显示百分比）
  • 超过 50%（约 100,000 tokens）时，务必开启新会话
  • 旧会话中的历史记录可以归档到独立文件，供后续参考

细节支撑

Ask User Question 工具会追问的具体问题示例：

  • “你理想的 UGC 视频生成工作流是什么？线性步骤式？模板式？批量处理？迭代式？对话式？”
  • “你希望如何处理 API 成本？有预算上限吗？”
  • “你希望用什么数据库和托管方案？”
  • “你希望用什么 AI 模型做脚本生成？”
  • “你希望什么 UI 风格？极简干净？Dashboard 重度？创意工具感？Chat 优先？”
  • “你有基础头像还是需要自定义头像？需要多场景视频吗？”
  • “视频存储你想怎么做？即时下载？云存储？外部存储？”

Ross Mike 的 R 循环配置要求：

  • 必须有 PRD.md
  • 必须有 progress.txt
  • 每个特性必须写测试
  • 测试通过才能进入下一个特性

推荐的上下文红线：

  • 模型：Claude Opus 4.5
  • 上下文上限：200,000 tokens
  • 建议安全线：50,000-100,000 tokens（25%-50%）
  • 超过 100,000 tokens 后模型表现会"劣化"，出现"开头很好，后面越来越差"的现象

3. 核心执行资产

Prompt / 指令集还原

Ask User Question 工具调用 Prompt：

Read this plan file. Interview me in detail using the Ask User Question Tool about literally anything: technical implementation, UI/UX concerns, and trade-offs. Do not judge me.

Plan Mode 基础 Prompt：

Please help me create a plan. Write this in the PRD.md file.

手动开发单个特性 Prompt：

Let's build the first feature. Please implement it. Once done, tell me how I can test this. How can I run this app?

测试驱动开发 Prompt：

Please write a test for this feature. After writing the test, run it to verify it passes.

工具链配置

  • 主工具：Claude Code
  • 替代工具：Cursor, OpenCode, Codex
  • 规划文件：PRD.md（产品需求文档）
  • 进度追踪：progress.txt
  • R 循环工具：Ralph Wiggum（作者建议先不用，等熟练后再用）
  • 终端工具：Ghosty（作者推荐使用的终端，而非 Mac 原生终端）
  • 代码托管：GitHub

4. 专家洞察与风险边界

反直觉/非共识结论

1. R 循环是"毒品"，新手不应该碰

这可能是最反直觉的观点——大家都在说 R 循环多厉害，但 Ross Mike 建议新手完全不要用。原因是：如果你不会手动开车，你买特斯拉的自动驾驶就等于浪费钱。你需要先学会"驾驶"——也就是手动逐个开发特性、测试、验证——才能理解自动化的价值和边界在哪里。

2. MCP、Skills、Prompt.md、Agent.md 都不重要

这也是一个反共识观点。Ross Mike 认为这些"高级功能"并不是你做不出好产品的根本原因。如果你做不出好产品，99% 的情况是因为你的 PRD 写得烂，不是因为你缺少某个 MCP 插件。

3. 计划阶段应该"无聊到让人想死"

当你使用 Ask User Question 工具时，它会没完没了地问问题，很多用户会觉得"烦死了"。但 Ross Mike 说：这就对了。真正值钱的计划就是要把所有细节都问出来，这个过程本身就是痛苦的，但它能帮你节省后面几十倍的返工时间。

4. “AI slop"的根本原因是人类自己的输入是 slop

模型已经足够好了。如果你还在生成"垃圾代码”，那不是因为模型不行，是因为你给的需求太模糊。2026 年的模型已经比大多数人类工程师写的代码质量高了。

局限性与避坑指南

1. 不要在 PRD 写得很烂的时候使用 R 循环

R 循环只会忠实地执行你的烂计划。如果你用一个粗糙的 PRD 启动 R 循环，你就是在"给 Anthropic 捐钱"（原话）。R 循环不会帮你发现计划的问题，它只会高效地执行一个坏计划。

2. 不要在没有任何实际部署经验时使用 R 循环

如果你还没有成功部署过一个完整的应用到 Vercel 或其他平台，你就没有"资格"使用 R 循环。先用手动方式跑通整个流程：规划 → 开发 → 测试 → 部署。你需要知道一个完整的 app 长什么样。

3. 上下文超过 50% 必须开新会话

这是技术红线。当上下文超过 100,000 tokens（约 50%），模型的表现会明显下降。你会感觉"模型开始犯蠢"——其实不是模型变笨了，是你给它喂的信息太多了，它开始"遗忘"早期的重要上下文。

4. 不要沉迷工具链配置

不要花太多时间研究 MCP、研究 prompt.md、研究各种"神级 prompt"。这些都不是决定你产品成败的关键。决定成败的是：你是否想清楚了你到底要做什么。

5. 软件开发正在变得"easy"，但软件工程依然是"hard"

任何人都可以用 AI “克隆"一个价值数十亿美元的软件。但让一个软件真正有人用、体验好、界面美、交互流畅——这依然需要人类的"胆识”（Audacity）、品味和思考。AI 可以帮你写代码，但它无法帮你做产品决策。

5. 金句

“模型已经足够好了，如果你还在输出垃圾，那是因为你输入的就是垃圾。”

“不要把 R 循环当作起点。它应该是你熟练掌握手动开发之后的加速器，而不是代替你学习的拐杖。”

“PRD 就是你和 AI 之间的合同。合同越模糊，交付物就越垃圾。”

“Ask User Question 工具会问到让你烦死了的程度——但正是这种烦人才是价值的体现。”

“软件构建变得简单了，但软件工程依然很难。做一个有人用的、体验好的产品，需要的是胆识、品味和思考，这些是 AI 给不了你的。”

“如果你还没有成功部署过一个完整的 app，你就没有任何资格使用 R 循环。”

“上下文超过 50% 就开新会话。不要让你的 AI 同事因为信息过载而变笨。”

📺 视频原片

视频ID: zxMjOqM7DFs