Claude Code每天必用的5个技巧：让AI反过来盘问你

用 Claude Code 写代码，很多人的习惯是丢一句模糊需求，然后让 AI 自己猜着写。结果呢？方向跑偏、逻辑做歪、来回返工。其实问题不在 AI 不够聪明，而在于你没把需求喂清楚。

一位 B 站 UP 主分享了他每天必用的 5 个 Claude Code 技巧，核心思路是：别让 AI 瞎写代码，让它反过来盘问你。这五个技巧串成一条完整的工作流，从模糊想法到可运行的应用，每一步都有章法。

Grill Me：让 AI 反过来逼问你

这是整个工作流的起点，也是最反直觉的一步。

大多数人使用 AI 编程的方式是：我说需求，你来实现。但问题在于，你脑子里的需求往往是模糊的、跳跃的、充满隐含假设的。AI 拿到一句话就开始猜，猜错了就做歪。

Grill Me 的做法恰恰相反——你告诉 Claude Code 你的大致想法，然后让它一条条逼问你：用什么算法？答错的卡怎么重排？数据存哪里？新卡每天放几张？

你随口回答，它边问边把每个决定写进文档，而且每答一条就存一次。哪怕聊了一个小时，也不会忘记前面的内容。

Grill Me 本质上是一种「需求引导」（Requirements Elicitation）技术，在传统软件工程中对应的是需求分析师对客户的深度访谈。软件项目失败的首要原因往往不是技术问题，而是需求不清。IBM 的一项经典研究表明，需求阶段引入的缺陷如果到编码阶段才发现，修复成本会放大 6-10 倍。Grill Me 把这个过程从「人问人」变成了「AI 问人」，利用大语言模型的上下文理解能力，系统性地挖掘用户脑中的隐含假设和未表达的约束条件。

清清楚楚的spec

最终，你脑子里那些零散的想法，就被「炸」成了一份清清楚楚的 spec 文档。需求不用猜了，后面的每一步都有据可依。

Brainstorming：动手前把方案炒明白

需求清楚了，先别急着写代码。第二步是让 AI 帮你做方案头脑风暴。

比如一个调度逻辑应该放在哪里？Claude Code 会摆出多种方案：纯函数、有状态的 layer、还是直接塞进界面里。每种方案标注优劣，绿色代表选中，红色代表否决，理由写得很硬。

以 UP 主的实际案例为例，最终选择了纯函数方案，理由是：

输入输出确定，单元测试最容易写
将来想从 SM-2 算法换成更精准的 FSRS，只需要改这一个文件
界面代码一行都不用动

这里提到的 SM-2（SuperMemo 2）是 1987 年由波兰研究者 Piotr Wozniak 提出的间隔重复算法，是几乎所有现代记忆卡片应用（如 Anki）的算法基础。它根据用户对卡片的评分（0-5 分）动态调整复习间隔和「易度因子」（Easiness Factor）。而 FSRS（Free Spaced Repetition Scheduler）则是近年由开源社区提出的下一代算法，基于 DSR（Difficulty-Stability-Retrievability）三参数模型，通过机器学习拟合用户的真实记忆曲线，在预测遗忘概率方面比 SM-2 精准约 30%-40%。文中选择纯函数架构的一个重要考量，正是为了未来从 SM-2 平滑迁移到 FSRS。

纯函数（Pure Function）是函数式编程的核心概念，指的是给定相同输入永远返回相同输出、且不产生副作用的函数。在软件架构中采用纯函数设计有三个显著优势：一是可测试性极强，不需要 mock 数据库或网络请求，直接传入参数就能验证；二是可组合性好，多个纯函数可以像乐高积木一样拼接；三是并发安全，因为没有共享状态，不存在竞态条件。文中将调度逻辑设计为纯函数，正是利用了这些特性——算法核心与 UI 层完全解耦，替换算法时只需改动一个文件，界面代码零改动。

这种架构决策如果不在动手前想清楚，后面改起来代价极高。

Writing Plan：把方案落成带编号的步骤

方案选定后，下一步是让 AI 把它落成一份带编号、标清依赖关系的执行计划。

关键是标清依赖

关键在于「标清依赖」——先写调度逻辑，再写测试，最后才接界面。这个顺序非常重要，因为 AI 很容易把顺序搞反，导致来回返工。

这里强调的「标清依赖」，对应的是软件工程中的任务依赖图（Task Dependency Graph）概念。在项目管理领域，这类似于关键路径法（CPM）——识别出哪些任务必须串行执行、哪些可以并行。对 AI 编程助手而言，这一步尤为关键，因为大语言模型在处理多步骤任务时容易出现「顺序幻觉」——它可能在底层模块尚未实现时就开始编写依赖该模块的上层代码，导致编译错误或接口不匹配。通过显式的编号和依赖标注，相当于给 AI 画了一张施工蓝图，强制它按正确的拓扑排序逐步推进。

更重要的是，这份计划让你能在写第一行代码之前就做 review。方向不对，当场拦下来，比写完再推翻省太多时间和精力。

这一步的本质是：用文档约束 AI 的行为边界，让它按照你审核过的路线图执行，而不是自由发挥。

TDD：先写测试再写代码

第四个技巧是 TDD（测试驱动开发），这在 AI 编程时代变得尤为重要。

TDD（Test-Driven Development）由 Kent Beck 在 2003 年正式提出，核心循环是「红-绿-重构」：先写一个会失败的测试（红），再写最少的代码让它通过（绿），最后重构优化。在传统开发中，TDD 的争议在于前期投入大、节奏慢。但在 AI 辅助编程场景下，TDD 的价值被重新放大——因为 AI 生成的代码天然缺乏「意图验证」机制，它可能写出语法正确但逻辑微妙偏差的代码。测试用例充当了一道自动化的「验收关卡」，让 AI 的输出必须通过明确的正确性标准，而不是仅仅「看起来对」。

测试就是可执行的需求，它把「什么算对」用代码钉死。让 Claude Code 先写测试用例，再写实现代码。代码一跑，大半测试都绿了，但总有那么一两条红的——而这些红色用例往往暴露的是你靠肉眼很难发现的边界问题。

是测试自动揪出来的

UP 主举了一个真实例子：有一条测试发现，连续答错八次后记忆参数掉到了 0.9，跌破了下限。再低的话，整个间隔算法就会崩溃。这种边界情况，你肉眼盯代码很难想到，是测试自动揪出来的。

Debugging：顺着测试找根因，不瞎改

最后一个技巧是 debugging，但不是传统意义上的「盯着代码瞎猜」。

因为前面已经有了完善的测试用例，测试已经精确指出了问题所在——答错那条分支忘了给参数加下限。修复方案也很明确：补一行代码，把参数夹在 1.3 以上。

再跑一遍测试，全绿。从报错到修好，测试全程领着你走，而不是你对着几百行代码逐行排查。

这种「测试驱动调试」的方式与传统 debugging 形成了鲜明对比。传统调试往往依赖开发者的经验和直觉，通过打断点、加日志、逐行跟踪来定位问题，效率高度依赖个人能力。而在 AI 编程场景中，AI 生成的代码逻辑对开发者来说是「半黑盒」的——你大致知道它在做什么，但未必清楚每一行的细节。有了测试用例作为「探针」，问题定位从「大海捞针」变成了「精确制导」，大幅降低了调试的认知负担。

五步串成一条完整工作流

一个模糊想法

回顾这五个技巧，它们不是孤立的小窍门，而是一条完整的 Claude Code 工作流：

Grill Me → 问清需求，生成 spec
Brainstorming → 定方案，选架构
Writing Plan → 列步骤，标依赖
TDD → 写测试，钉边界
Debugging → 修干净，全绿通过

一个模糊的想法，就这样一步步跑成了一个真正能用的应用。

这五步工作流的底层逻辑，其实暗合了经典软件工程中的「瀑布模型」精髓——需求分析、系统设计、详细设计、编码实现、测试验证——只不过每个阶段都由 AI 加速完成，而人类的角色从「执行者」转变为「决策者」和「审核者」。这也是当前 AI 辅助开发的最佳实践方向：不是让 AI 端到端地替你完成一切，而是在每个关键节点保留人类的判断和把关。

核心启示：谁该指挥谁？

这套工作流最值得思考的一点是：用 AI 写代码，到底该你指挥它，还是让它反过来盘问你？

答案是两者兼有。在需求阶段，让 AI 盘问你，逼出你脑子里的隐含假设；在执行阶段，用计划和测试约束 AI，让它按照你审核过的路线走。

这种「人机协作」的模式，比单纯地给 AI 下指令要高效得多。AI 不是替代你思考的工具，而是帮你把思考过程结构化、显性化的搭档。掌握这套方法论，才算真正用好了 Claude Code。

从更宏观的视角来看，这套工作流揭示了 AI 编程工具的一个深层趋势：提示词工程正在演变为工作流工程。早期人们关注的是如何写出一条好的 prompt，而现在的最佳实践是设计一整套结构化的人机交互流程。单条 prompt 的优化空间是有限的，但当你把多个精心设计的交互步骤串联起来，形成一条可复用的工作流时，AI 的输出质量会产生质的飞跃。这也是为什么越来越多的团队开始将 AI 编程的最佳实践沉淀为标准化的流程模板，而不仅仅是一组 prompt 技巧。