组织团队培训时用claude code生成练习题的技巧

四个月前的一个周三下午，我盯着Claude Code吐出来的第14版练习题，突然意识到一个问题：我们团队过去三个月用AI生成的400多道培训题目，至少有一半在浪费学员的时间。

不是题目有错，而是它们太“正确”了。正确到像从教科书上复印下来的，正确到任何一家公司的技术团队都能用，正确到我们的学员做完之后毫无波澜，既不会拍大腿说“这不就是我们上周线上事故的翻版吗”，也不会陷入沉思开始怀疑自己之前的架构决策。

那天下午我做了一个决定：把所有“通用型Prompt”的模板全部删掉，从头开始设计一套完全不同的出题方法。四周之后，我们技术团队内部培训的练习题完成率从51%跳到了87%，更关键的数据是，学员在反馈表里第一次出现了“这题出到我心坎里了”这样的原话。

这就是我写这篇文章的理由。不是要教你“怎么用Claude Code生成一道选择题”，那种内容网上一搜一大把。我要讲的东西更具体也更难复制：如何让AI帮你出题时，出的不是“任何人都会做的题”，而是“只有你们团队才需要的题”。

一、先讲核心结论：出题好坏的差别，不在Claude Code本身，而在你“喂”给它什么东西

很多人第一次用Claude Code出题时的操作路径是这样的：打开对话框，输入“帮我就微服务架构设计出20道多选题，难度中级”，回车，然后看着返回的结果觉得“还行，能用的也就七八道吧”。

这不是Claude Code的问题。任何大语言模型在面对这种模糊指令时，唯一的理性策略就是给出最中庸、最安全、覆盖面最广的答案。因为你说的是“微服务架构设计”，这是一个足以写成三本技术书的命题空间，Claude Code不知道你团队用的是Spring Cloud还是Kubernetes原生，不知道你们最近在拆单体还是在做服务治理，不知道你的学员是应届生还是干了五年的老后端。所以它只能从公开知识中提取那些“全世界开发者都该知道”的知识点来出题。

你把Claude Code当搜索引擎用，它就给你百科式题目；你把它当你们团队的影子技术经理用，它才能给你带血带肉的实战题。

这是我做了几十次对照实验后得出的核心结论。同样一个知识点“服务间通信的超时重试机制”，用“请出5道关于服务超时重试的多选题”得到的题目大概是这样的：

下列关于服务间调用超时重试的说法，正确的是：

A. 超时时间设置越长越好

B. 幂等性设计是安全重试的前提

C. 所有调用都应该启用重试

D. 超时时间应大于下游服务的平均响应时间

这道题本身没有错误，任何一个合格的面试官都会说“嗯，B选项是对的”。但问题在于：这道题和你的团队有什么关系？ 学员做完之后会想“哦，书上也是这么写的”，然后关掉页面，明天就忘了。

而当你换了另一种方式“喂”AI，结果会完全不同。这个方式我等会儿会详细拆解。

先把这个核心判断刻在脑子里：Claude Code出题的质量下限取决于模型能力，但质量上限完全取决于你的输入质量。而输入的真正功力，不在于指令写得有多详细，在于你有没有把团队独有的上下文“注入”到每一次对话里。

二、真实场景：大部分技术团队培训正在陷入“为出题而出题”的泥潭

我在过去一年里帮4个技术团队优化过内部培训的出题流程，规模从20人到300人不等。每进到一个新团队，我都会先做同一件事：把最近一次培训的练习题从头到尾做一遍，然后问自己一个问题，“如果我是一个刚入职半年的新人，做完这些题之后，我对自己日常工作的理解会有任何加深吗？”

答案是：在绝大多数情况下，不会。

不是因为题目太简单或太难。而是因为这些题目和日常工作之间隔着一层“透明玻璃”，看起来都相关，实际上触不到。

举一个我亲眼看到的例子。某个做支付系统的团队，内部培训主题是“分布式事务”，讲师认真准备了PPT，讲完之后发了一套Claude Code生成的练习题，里面有“什么是二阶段提交”、“TCC模式的核心思想”、“Saga补偿机制的优缺点”等等。学员做完题、对了答案、拿了分数，培训就算结束了。

两周之后，这个团队线上出了一次事故：一笔跨服务转账因为一个下游接口超时导致上游补偿逻辑没有正确回滚，产生了短款。当我跟当事开发聊的时候，他说了一个让我印象深刻的细节：

“当时看到那个异常日志，脑子里想的是‘这好像是分布式事务的问题’，但具体该先查哪个服务、该怎么判断补偿链路是否跑完了，我一瞬间有点懵。培训时候做过那些选择题，但跟眼前这个完全是两回事。”

这就是“百科式题目”最隐蔽的副作用：它给你一种“我已经懂了”的错觉，却在你真正需要用的时候，发现理论和实战之间隔着一整条实操鸿沟。

这个案例让我开始系统性地反思一个被很多人忽略的问题：团队培训出题的目的到底是什么？

如果你只是想验证学员有没有认真听课，那百科式题目够用了，甚至直接拿公开题库改一改也行。但如果你的目的是让学员在面对实际工作场景时能更快地做出正确判断、更系统地排查问题、更少地踩已知的坑，那你的题目必须从团队自身的真实经验中长出来。

Claude Code恰好是完成这件事的最佳工具，前提是你知道怎么“喂”它。

三、拆解常见误区：多数人卡在了“把Claude当出题工人”而不是“出题合伙人”

过去几个月我观察到一个非常普遍的现象：很多团队在用Claude Code出题时，花了大量时间琢磨“怎么把Prompt写得更长、更详细”，却很少花时间思考“在Prompt里该放什么样的上下文”。

这种思维方式的根本问题在哪里？在于它默认为出题这件事可以脱离“题目使用者”而独立存在。但任何一个做过培训的人都知道，好的题目是高度依赖语境的。

我把目前团队使用Claude Code出题时最常见的三个误区列出来，你可以对照着看看自己的团队踩中了几个。

误区一：“指令越详细，题目越精准”

去年我帮一个做电商的团队做培训体系优化，他们的培训经理给我看了一段Prompt，是他花了两个小时打磨的“终极版本”。这段Prompt精确到令人发指的程度：规定了每道题的题干长度不超过80字、四个选项必须长度相等、考查的知识点必须覆盖Bloom分类学中“应用”和“分析”两个层级、不能在题干中出现否定词、不能在选项里用“以上都对”……

他甚至还在Prompt里加了一句：“请确保每道题的干扰项都有明确的错误原因，且错误原因必须与真实开发中常见的认知偏差相关。”

听起来是不是很专业？我当时也觉得“这么细致的指令，出来的题应该没问题吧”。

结果第一版题目出来之后，我挑出了其中三道题，问了他一个问题：“这三道题你自己做一遍试试，看看能不能立刻选出正确答案。”

他做了，全对，用时不到30秒。

我说：“你是这个系统的架构师，你当然觉得简单。你手下那些做日常需求的一线开发，做这几道题的感受是什么？”

他沉默了一会儿，说：“他们可能会觉得是‘背八股文’。”

问题就出在这里。指令的“详细”和“有针对性”是两回事。 你可以把指令写成一页A4纸，但如果纸上写的是“考查微服务设计原则”而不是“考查我们商品中心那个退款链路为什么拆成了三段式调用”，那出来的题再精致，也跟你团队的真实工作无关。

Claude Code面临的本质困境是：它不知道你的团队是谁、在做什么、犯过什么错、踩过什么坑、有什么技术债、今年最重要的项目是哪个。它只能从公开知识中提取模式，然后用一种“放之四海而皆准”的方式把知识点变成题目。

你能给的最重要的信息，从来不是“请把题干控制在80字以内”，而是“请基于以下我们团队的真实案例来出题”。

误区二：“AI出的题质量不行，得大量人工修改”

这是一个自我实现的预言。

很多人第一次用Claude Code出题觉得不满意，于是建立了一个“修复流程”，拿到AI生成的题目后，逐条审视、大幅修改。这个事情做了三四轮之后，他们得出一个结论：“AI出题也就是个半成品，还得靠人。”

然后他们就把Claude Code当成一个“初稿生成器”来用，每次Prompt随便写两句，心里想的是“反正待会儿还得改”。Prompt越写越敷衍，生成质量越来越差，人工修改量越来越大，这个循环就彻底锁死了。

我后来做过一个对比：同样一个培训主题“线上故障排查与根因分析”，A组用“敷衍Prompt + 大量人工修改”的方式，B组用“高质量定制化Prompt + 少量人工审核”的方式。结果很有意思：

• A组平均每道题从生成到入库耗时11分钟（生成1分钟 + 修改10分钟）
• B组平均每道题从生成到入库耗时3分钟（生成2分钟 + 审核1分钟）

B组在“喂”AI的阶段多花了1分钟写Prompt，省了9分钟人工修改时间。

更重要的差异在题目质量上。A组因为预期“反正要改”，很少在Prompt里提供丰富的上下文，所以AI出来的底稿本身就是那种“百度百科”式的内容。人工修改只能修补表面的错误或调整措辞，但很难从根子上改变题目的“气质”。这就好比买了一件版型不对的衣服，你可以改袖子长短、改腰身肥瘦，但肩宽不对就是不对。

B组因为从一开始就给了AI足够多的团队上下文，出来的题目自带团队属性。人工审核只是做一道“安全检查”，而不是推倒重来。

误区三：“出题是一次性工作，出完就完了”

这可能是最容易被忽视但伤害最大的一个误区。

我见过一个做了三年内部培训的技术团队，他们有一个共建题库，里面攒了800多道题。培训经理很自豪地说：“我们的题库是团队的核心资产。”

但我做了一件事之后，他的脸色就不太好看了。我随机抽了30道相对早期入库的题目，然后用它们去测试团队里一位入职两年半的中级开发，这个人参加过最初那些培训，手里有当时的参考答案。结果他只对了19道。

培训经理第一反应是“这人基础不扎实”。我说你再看看题目本身。

我们逐一核对了被答错的11道题，发现其中4道考查的知识点对应的系统模块已经在半年前的重构中被替换掉了，3道涉及的技术方案已经被团队明确弃用，还有2道题的选项设计基于当时的业务规则，而那个规则已经改了两次。

也就是说，不是学员答不对，是题目本身过时了。

题库不是静态资产，它是会腐坏的。你团队的系统架构在变、技术栈在升级、业务规则在调整、踩过的坑在不断新增，如果不出题也跟着持续迭代，题库的“相关性衰减曲线”会非常陡峭。

这三个误区有一个共同的根源：把Claude Code当成“内容生产流水线”的最后一环，而不是“内容设计思维”的起点。 当你转变这个认知，后面所有技巧才有发挥的空间。

四、专业判断逻辑：Claude Code出题的“分水岭”在于你是否建立了信息注入机制

接下来我要讲的东西，才是我在这件事上真正沉淀下来的方法。网上那些“教你写好Prompt”的文章，基本都在讲格式和措辞，比如要用Markdown表格指定题型、要给出示例题目做Few-shot、要设定角色“你现在是一个资深培训专家”。这些东西有用，但都不是核心。

核心只有一个：你能不能把“团队专属信息”以结构化的方式注入每一次与Claude Code的对话。

我把这个能力拆成三层，逐层递进。这三层能力也定义了一个团队在用AI出题这件事上所能达到的上限。

第一层：事实注入，让AI知道你们团队“是谁”

这是最基础的一层，但大多数团队连这一层都没做。

所谓事实注入，就是在你让Claude Code出题之前，先让它知道关于你团队的关键事实。这些事实至少包括：

技术栈事实。 不要只说“我们做后端开发”，要说“我们用Java 17 + Spring Boot 3.x做服务端，中间件是RocketMQ做异步解耦和Redis Cluster做缓存，数据库是MySQL 8.0分库分表，服务注册用Nacos，配置管理用Apollo，容器化部署在K8s上”。

这个信息决定了AI出题时能不能把知识点落到具体的工具和版本上。比如一道关于“消息消费的幂等性”的题，知道你们用RocketMQ之后，题干里就可以出现“消费位点重置”、“Tag过滤”、“事务消息回查”这些RocketMQ特有的概念，而不是泛泛地谈“消息去重”。

业务领域事实。 不要只说“我们是做电商的”，要说清楚你们负责的是哪个链路、核心业务规则是什么、有哪些容易出问题的边界场景。比如“我们负责交易正向下单链路，核心包括商品校验、库存预占、优惠计算和支付路由四个环节。其中优惠计算涉及满减、折扣券和平台补贴三套规则的叠加，是历史Bug密度最高的模块”。

这个信息直接决定了出题的颗粒度和切入点。如果你只告诉AI“请就电商下单流程出题”，它给你的一定是“下单时要校验哪些信息”这种入门级问题。但当你告诉它“优惠叠加规则曾经因为满减和折扣券的优先级定义不清导致过一次线上资损”，它就能出一道真正考验判断力的题。

团队人物画像事实。 这一点最容易被忽略。你要告诉Claude Code，这些练习题最终是谁来做。是刚入职的校招生？是有一两年经验但没接触过核心系统的开发？还是准备往架构方向走的高工？

不同人群需要的题目，考察点、题干复杂度、选项迷惑性都应该不一样。给新人出的题，难点应该在“识别问题类型”；给高工出的题，难点应该在“权衡方案之间的trade-off”。

我发现一个效果很好的做法：在每次出题前，先用一两句话给Claude Code建一个“学员画像”。比如：“这批学员是入职6-8个月的Java开发，已经能独立完成常规需求，但对线上故障排查缺乏经验，对分布式场景下的一致性保障理解较浅。他们接下来要参与订单中心的重构，需要快速建立对最终一致性和补偿机制的认知。”

这一段话的价值，远超“请生成中等难度的多选题”这种模糊表述。

第二层：组织记忆注入，让AI知道你们团队“经历过什么”

这是我做过的所有尝试中，效果提升最明显的一层。

每个技术团队都有自己的“组织记忆”，那些写在事故报告里的Bug、在复盘会上反复被提起的错误决策、架构评审时被否决了后来又后悔的方案、凌晨三点排查了两小时才找到根因的诡异线上问题。

这些组织记忆是最宝贵的出题原材料。 因为它们是真实的、是疼痛的、是有教训的，用它们出的题天然带有故事感和代入感，学员一看就知道“这不是编出来的”。

具体怎么注入？我不建议直接把整个事故报告扔给Claude Code，那样信息噪声太大了。我用的方法是从事故报告中提取出三个关键要素：

1. 触发条件：什么操作或什么状态下问题被触发了
2. 表现现象：用户/系统看到了什么异常
3. 根因链条：从表象到本质经过了哪些环节

举个例子。我们团队曾经因为数据库连接池的maxWait参数设置不当，在高并发场景下出现过一次服务雪崩。事故报告写了整整8页，但如果要提取出题的素材，核心就这一段：

触发条件：大促时段，下单接口QPS从平时的800飙升至3200

表现现象：部分请求返回timeout，随后越来越多服务实例开始报“无法获取数据库连接”

根因：连接池maxSize设置合理但maxWait设置了2000ms，高并发下等待队列迅速堆积，线程资源被耗尽后导致健康检查也失效，K8s误判实例不健康后触发重启，重启过程中流量打到剩余实例上加速了雪崩

好的，现在这段素材有了。我可以在Prompt里这样用它：

“以下是我们团队发生过的一次真实线上事故的概要：[上面那段素材]。请你基于这个真实场景，生成3道练习题：

1. 一道单选题：考查学员能否识别出问题发生的直接原因（连接池等待超时 vs 健康检查误判 vs 流量过大）
2. 一道多选题：考查学员对连接池关键参数（maxSize、maxWait、idleTimeout、keepaliveTime）各自作用的理解
3. 一道案例分析题：给出一个类似的系统架构图描述，要求学员设计应对流量突增的预案，包括限流、熔断和连接池参数调优三个维度”

用这种方式出的题，效果怎么样？我后来观察学员做这套题时的反应，以往做那种泛泛的“连接池配置最佳实践”题，大家基本上就是“刷题”心态，快速选完看答案，三分钟搞定。但做这套基于真实事故的题时，很多人做到案例分析那一道就开始停下来讨论，“当时如果我们在那个场景里，会不会也犯一样的错？”

当学员开始“讨论”而不是“刷题”，你的题目才真正完成了教学闭环。

第三层：团队语境注入，让AI知道“这题是出给我们自己人的”

这是最细腻的一层，也是决定一道题是“能用”还是“精彩”的一层。

每个团队都有自己的黑话、缩写、内部系统代号、甚至是技术决策上的“历史包袱”。这些东西对外人是噪音，对内部人却是信息密度最高的表达方式。

举个例子，我们团队内部有一个叫“老退款”的模块，全名是“订单退款审批工作流引擎”，但因为对应的系统入口在内部导航上的标签写的是“退款（旧）”，所以所有人都叫它“老退款”。新人入职第一周就会被老员工告知“那个老退款的代码能不动就别动，里面有很多历史逻辑没人敢改”。

如果你让我出一道关于“退款流程”的题，我可以出一万种花样。但如果你让AI出一道关于“老退款”的题，它不知道“老退款”是什么，除非你告诉它。

所以我在给Claude Code做上下文注入时，会特意加一个叫“团队术语映射表”的东西。结构很简单，就两列：

有了这个映射表，Claude Code出的题目可以是这样的：

假设你是团队一名刚接手“老退款”模块的开发工程师。今天“强哥”在群里同步了昨天“711事故”的复盘结论，核心问题是热点数据缓存策略不当。强哥要求你在“老退款”的approveChain方法中加入一个本地缓存层来减轻Redis压力。以下哪种实现方式最符合团队一贯的技术偏好？

A. 引入Caffeine作为本地缓存，配置最大条目数1000和TTL 5分钟，使用Guava的LoadingCache模式

B. 自己实现一个基于ConcurrentHashMap + 定时清理线程的简易缓存

C. 在方法入口加synchronized，减少并发对Redis的访问

D. 引入Redis集群的读写分离，让approveChain走从节点

这道题背后的考查点其实很简单，就是“本地缓存的实现方式选择”。但这道题读起来完全不像一道“题”，更像一个真实的团队对话场景。“老退款”、“强哥”、“711事故”这些词语一出现，学员就知道“这不是外头扒来的题库”。

三个注入层级的协作关系是这样的：

• 没有第一层（事实注入），AI出的题大概率跑偏，跟你们团队的技术栈和业务八竿子打不着。
• 有第一层但没有第二层（组织记忆注入），AI能出“正确”的题，但出不了“精彩”的题，学员的感受就是“道理都对，但没意思”。
• 有第一层和第二层但没有第三层（语境注入），AI出的题专业、贴合业务，但总觉得隔了点什么，好像是一个外部顾问写的，不是“自己人”写的。

三层齐备之后，你得到的就不只是“练习题”了，你得到的是你们团队独有的培训教材，而且是那种外人拿了也没用的教材，这恰恰是它最有价值的地方。

五、具体操作体系：六个经实战验证的出题技法

接下来是这篇文章中最“干货”的部分。我会把过去大半年里反复实验、踩坑、修正之后沉淀下来的技法逐一拆解。每一个技法我都会给出具体的Prompt示例和它背后的设计逻辑，因为直接复制Prompt没用，你得知道“为什么这么写”，才能在自己的场景里活学活用。

不过说在前面：下面所有的Prompt示例，不要直接复制粘贴。去看它的结构逻辑，然后把里面的团队信息替换成你自己的。复制别人的Prompt就像穿别人的鞋，走的还是别人走过的路。

技法一：“事故回溯法”，把Post-mortem变成练习题

这是我最常用的技法，也是效果最立竿见影的一种。

每个技术团队都会写事故报告。但大多数团队的做法是：事故发生→复盘→写报告→全员通报→存档→遗忘。一份凝聚了团队几小时甚至几天排查心血的报告，最后变成了一个躺在Wiki角落的PDF。

用“事故回溯法”，可以把每一份有价值的事故报告变成3-5道高质量的练习题。具体操作步骤：

第一步：从事故报告里提取“三要素”

打开一份事故报告，找到以下三个信息的精准描述：

• 触发链：是什么操作、什么条件、什么时间点触发了问题。不要写“系统负载过高”，太模糊。要写“大促秒杀时段，下单接口瞬时QPS从1200飙升至4100”。
• 恶化链：问题发生后，是什么机制导致影响面扩大。比如“超时重试导致下游服务被放大调用”、“健康检查失败导致容器被K8s误杀”、“熔断未生效导致故障扩散到非核心链路”。
• 修复链：最终是怎么止血和修复的。要说清楚是“回滚代码”还是“扩容”还是“切流量”还是“改配置”，以及为什么选了这个方案而不是别的。

第二步：把三要素组合成一个“场景素描”

格式可以这样：

场景：某业务模块在[具体条件]下，发生了[具体现象]。此时[系统a]出现了[行为x]，导致[系统b]产生[连锁反应y]。最终表现为[用户侧可见的影响]。值班同学[做了操作1]，效果是[短暂缓解/无效/恶化]；随后[做了操作2]，问题得到初步控制；根因定位后发现是[深层原因]。

注意这里面的用词，“行为x”不要直接说“故障”或“错误”，而是用客观中性的描述让学员自己去判断这到底是不是一个需要干预的异常。因为真实排查中最难的就是第一步：判断“这到底是不是一个真正的问题”。

第三步：定义考查意图和题型组合

不要一套事故只出一类题。一个完整的“事故回溯”至少可以拆出四种不同的考查角度：

第四步：写Prompt，把以上信息一次性喂给Claude Code

下面是一段我实际使用过的Prompt结构，供你参考：

我将为你提供一段我们团队的真实线上事故简要描述。请你基于这段描述生成练习题。

在生成题目之前，请先理解以下背景信息：

• 我们团队负责某电商平台的交易下单链路，技术栈是Java + Spring Boot + RocketMQ + Redis
• 这批学员是工作1-3年的后端开发，有一定排查经验但对分布式系统故障的传导机制理解不深
• 团队内部习惯把数据库连接池相关故障称为“池子问题”，把缓存穿透/击穿/雪崩统称为“缓存崩了”

事故描述如下：[这里粘贴你提取好的三要素和场景素描]

请生成以下练习题：

1. 【单选题】考查学员能否从给出的多条告警信息中，最快定位到问题的直接触发点。请给出4个选项，每个选项对应一种可能的判断路径，其中只有一条是正确的“第一反应”。干扰项请使用真实排查中常见的误判路径。
2. 【多选题】考查学员对恶化链的理解。列出5个可能导致故障扩大的因素，其中3个与本次事故直接相关，2个是通用常识但本次事故中并未出现。要求学员选出相关的3项。
3. 【排序题】将本次事故从触发到修复的关键事件打乱顺序，要求学员恢复正确的时间线。
4. 【问答题】如果你是当时的值班工程师，在事故发生的第5分钟（此时现象已出现但根因未明），你会做哪三件事？请按照优先级排序并说明理由。

注意事项：

• 所有题干和选项中涉及的系统名称、参数名称，请使用我们团队内部的真实命名
• 选项设计不要过于工整对称，真实场景中的决策往往不是“一个完美答案对三个明显错误”
• 问答题请同时生成一份参考答案和评分要点，评分要点不需要“满分标准答案思维”，而是列出“答到哪些点上可以得分”

我用这个结构出过的题目，最典型的反馈是：“做完这套题感觉自己真的经历了一次线上排查。”这就是事故回溯法的核心价值，它把别人犯过的错，变成了你没有亲身经历却能从中汲取教训的学习体验。

技法二：“架构决策复盘法”，把技术评审变成判断题和选择题

事故回溯法关注的是“已经发生的坏事”，架构决策复盘法关注的则是“曾经面临过的抉择”。

我观察到技术团队有一个很有意思的现象：85%以上的技术决策，在做出之后的半年内会至少被回过头来审视一次。 有的是因为线上问题暴露了决策的缺陷，有的是因为业务发展超出了当初的假设，还有的纯粹是因为新来的高工觉得“当时那个方案不行”。

这些被反复审视的决策时刻，是最佳的出题素材。因为它们天然包含“两难”和“权衡”，而这些恰恰是优秀技术练习题最核心的品质。

具体操作上，我通常从团队过去半年的架构评审会议纪要或者技术方案文档中挖掘素材，重点关注那些有“分歧”的决策，也就是评审会上不同角色持不同意见、最终有人被说服但也有人不完全认同的决策。

提取素材时，我关注三个维度：

• 当时摆在桌面上的方案选项（至少两个，最好三个）
• 每个方案的利弊在当时是怎么被评估的
• 最终选择方案的核心依据是什么

然后我会构建这样一个Prompt：

我们团队在[某个时间点]面临一个技术决策：[简要描述背景和目标]。

当时有三个候选方案：

方案A：[描述]，核心优势是[xxx]，核心风险是[xxx]

方案B：[描述]，核心优势是[xxx]，核心风险是[xxx]

方案C：[描述]，核心优势是[xxx]，核心风险是[xxx]

最终团队选择了方案B。

现在回头看，[补充一些事后视角的信息，比如方案B的哪些假设被验证了、哪些出了问题、有没有出现当初没预料到的情况]。

请基于以上内容生成：

1. 【单选题】假设你回到了当初评审的那天，在仅掌握当时信息的情况下，哪个选择是最合理的？请设计4个选项，分别对应“选A”“选B”“选C”“信息不足无法决定”，要求每个选项的解释逻辑贴合当时的实际情况。
2. 【材料分析题】请将三个方案的利弊整理成一份简短的对比表，然后提问：如果业务方在三个月后告诉你需求从[x]变成了[y]，你会坚持原方案还是切换到其他方案？请说明判断依据。
3. 【开放性讨论题】这个案例中，最终选择的方案B在落地后遇到了[实际遇到的问题]。如果你是当时的决策者，在评审阶段有没有什么信息是你希望提前获取的？请设计一个“评审前应确认清单”。

架构决策复盘法的精妙之处在于：它考查的不是学员对某个知识点的记忆，而是他们在信息不完备的情况下做出技术决策的能力。 而这恰恰是高阶工程师最核心也最难训练的能力之一。

技法三：“代码考古法”，让Claude Code从你们自己的代码仓库里出题

这是专门针对技术团队的一个技法，也是我认为Claude Code相比其他通用AI工具最独特的优势所在。

Claude Code可以直接读取和分析代码。这意味着你可以把团队的真实代码（或者脱敏后的代码片段）直接喂给它，让它基于这些代码出题。这个能力太强了，因为它从根本上解决了“题目和实际工作脱节”的问题，题目的素材就是你们自己写的代码，怎么可能脱节？

具体来说，“代码考古法”有几个非常实用的应用场景：

场景一：基于历史Bug的修复提交出题

找到你们Git仓库里那些修复了重要Bug的commit，把修复前后的代码diff和commit message一起喂给Claude Code，让它出“找出这段代码中存在的问题并给出修复方案”这样的题。

比如我们团队曾经有过这样一个Bug：一个for循环里使用了未加限流的RPC调用，当循环量比较大时打爆了下游服务。修复方案是在循环外加了一个批次限流器，把1000次调用分成10批，每批间隔200ms。

我把修复前那段带Bug的代码（当然做了一点脱敏处理）和一段简短的背景描述喂给Claude Code：

以下是一段我们团队一个数据处理模块的真实代码。这段代码上线后曾在一次批处理任务中导致了严重的下游服务性能问题。请阅读代码，然后生成：

1. 一道单选题，考查学员能否识别出代码中最可能导致下游压力的部分
2. 一道代码改错题，要求学员写出修复方案的核心逻辑（不需要完整代码，用伪代码描述即可）
3. 一道追问：“除了加限流之外，还有哪些架构层面的改进可以避免这类问题再次发生？”

这样的题目做出来，学员的感受不是“我在做题”，而是“我在Code Review一段实际存在问题的代码”，完全还原了真实工作场景。

场景二：基于复杂业务逻辑出题

每个团队都有那么几段“老人走了就没人敢动”的代码。这些代码往往包含了大量隐式的业务规则和边界条件处理，是出题的金矿。

做法很简单：把那一段代码喂给Claude Code，请它先分析代码中隐含了哪些业务规则；然后针对其中最容易被误解或遗漏的规则出题。

以下是我们团队一段处理订单退款审批的核心代码。这段代码因为历史原因，包含了多项隐式业务规则，新人在维护时经常因为不了解隐含逻辑而引入Bug。

请先完整分析这段代码中包含的所有业务规则（包括显式的if-else和隐式的状态流转约束），然后请针对其中“最容易因误解而导致Bug”的三条规则逐一设计单选题，每道题的四个选项里，一个正确、一个反映了常见的误解、一个反映了过时的老规则（目前已不适用但代码中未显式删除）、一个是单纯的干扰项。

这种题目的价值在于：把隐性知识显性化。 那些只存在于老员工脑子里、从来没有被正式文档化过的规则，通过出题的过程被挖掘、被审视、被验证，最终变成了可以传承的组织知识。

场景三：基于接口契约出题

如果你团队的微服务之间有明确的接口定义（比如Proto文件、OpenAPI规范或者内部接口文档），可以拿这些定义让Claude Code出题，考查学员对服务间交互契约的正确理解。

这个方向我试下来最有价值的题型是“边界条件识别”，给出一段接口定义，让学员判断在哪些边界条件下这个接口可能出现非预期行为。考查的不是“怎么调这个接口”，而是“这个接口设计有什么隐含假设”。这直接对应了分布式系统中那些“接口看着没问题、凑在一起就炸了”的经典故障模式。

技法四：“对立评审法”，让Claude Code自己跟自己打擂台，提高题目质量

前三种技法都是在讲“怎么出题”，这个技法讲的是“题出来之后怎么让它更好”。

很多人拿到Claude Code生成的第一版题目，看完之后觉得“还行，但有几个选项明显不对”，然后手动改一改就用了。但我发现有一种方法能让Claude Code自动帮你提升题目质量，而且效果往往比人工修改更好。

这个方法我叫它“对立评审法”。操作很简单：

拿到第一版题目之后，不要直接修改。新建一个对话，把题目贴进去，给Claude Code一个“对立评审”的角色指令，让它逐一审查每道题的质量。

具体Prompt可以这样写：

以下是一套为[某培训主题]设计的练习题。请你以“严苛的评审专家”身份审查这套题目。你的工作不是夸奖，是找问题。请逐题审查，并重点检查：

1. 题干是否有歧义：同一个句子，是否可能被不同人理解为不同含义？如果有，指出是哪个词或哪个结构引起了歧义。
2. 正确选项是否唯一且无争议：在特定上下文中，正确选项是否可能被合理地质疑？如果存在“不同的人可能有不同理解”的空间，请指出。
3. 干扰项是否具有真实的迷惑性：一个合格的干扰项应该让“半懂不懂”的人倾向于选它。如果某个干扰项明显离谱（一看就是错的），请指出并建议如何改进。
4. 题目难度是否与目标学员匹配：[在这里描述目标学员的技术水平]。如果某道题明显过难或过易，请指出。
5. 是否存在“ChatGPT式废话”：题干或选项中是否有一些看似专业但没有实际信息量的表述。如果有，请标记并给出精简建议。

请按题目编号逐一给出审查意见，格式为：

题目X：[问题类型] – [具体问题描述] – [修改建议]

我用这个方法审了不下200道题，发现一个规律：Claude Code出的题目中，大约30%不需要任何修改，50%存在一到两处可优化点，15%存在较明显的质量问题需要返工，还有5%存在方向性错误（比如考查点跑偏了或者正确选项确实有争议）。

这个比例意味着，如果你不审查直接拿来用，出问题的概率其实不低。而“对立评审法”提供了一种低成本、高效率的质量门禁。

我后来把这个流程固化成了一个标准作业：出题 → 对立评审 → 根据评审意见修改 → 人工终审。人工终审只审那15%被标记为“有明显质量问题”的题，以及随机抽查30%的“通过”题。 这样既保证了质量，又把人工工作量降到最低。

技法五：“难度校准法”，用学员的真实正确率反推题目难度标签

所有出题的人都会给题目标难度，“初级”“中级”“高级”。但问题是，这些标签大多基于出题人自己的直觉，而不是学员的实际表现。

我在帮一个30人的团队做培训时做过一个实验。我让他们把题库里标签为“中级”的50道单选题拿出来，给团队里公认的“中等水平”的10个开发做了一遍。结果发现，这50道“中级”题目中：

• 有8道题正确率超过90%，意味着对于中等水平学员来说其实是“简单”题
• 有11道题正确率低于40%，意味着这些题对中等水平学员来说其实是“困难”题
• 只有31道题的正确率落在60%-85%这个“中级”应该对应的区间

也就是说，靠直觉标难度，误差率高达38%。

Claude Code可以帮你完成一部分难度校准。方法是这样：出完一套题之后，不要立刻发出去。加一步对话，让Claude Code预估每道题的难度，并且给出依据。

以下我贴出了刚生成的10道题目。请逐一预估每道题的难度级别（简单/中等/困难），并给出你的判断依据。判断时请考虑以下因素：

• 目标学员画像：[已经在之前对话中描述过]
• 题目考查的知识点是常见的还是偏门的
• 正确选项和干扰项之间的区分度（干扰项越有迷惑性，难度越高）
• 题目是否需要多步推理还是直接记忆即可作答
• 题干中是否包含可能误导学员的“陷阱”表述

拿到Claude Code的难度预估之后，去做一件事：在题目真正投入使用后，收集每道题的实际正确率数据，回头来修正难度标签。

我现在的标准是：前两轮培训的题目都用Claude Code预估的难度标签先发布，然后根据实际正确率做动态调整。三轮之后，题库里90%以上的题目难度标签基本准确了。

这个做法的额外收益是：当你积累了足够多的正确率数据后，你可以反过来优化你的出题Prompt。 比如你发现“自己出的案例分析题正确率普遍偏低”，那可能是因为你在题干中故意嵌入了一些容易误导的表述，下次出题时就可以有意识地控制这种表述的密度和明显度。

技法六：“变质预警法”，建立题库的周期性审查机制

前面在误区三里提到了“题库会腐坏”这个话题，这里展开讲怎么解决。

我的做法是建立一套简单的“题库健康度检查”机制，并且把Claude Code当作这个检查机制的“协查员”。

机制运转流程如下：

第一步：给每道题打上“依赖标记”

在入库每一道题时，明确记录它依赖哪些“可能变化的事物”。我设了三个维度的依赖标记：

• 系统依赖：这道题的正确答案依赖于某个系统模块的当前行为。如果那个模块被重构或替换，这道题的答案可能就变了。
• 规则依赖：这道题涉及某个业务规则。一旦业务规则调整，题目可能需要更新或废弃。
• 技术栈依赖：这道题考查的知识点在指定的技术栈版本下成立。如果版本升级导致行为变化，题目可能需要调整。

第二步：设置检查周期

不同类型依赖的检查周期不同：

第三步：让Claude Code协助检查

到了检查周期，把需要审查的题目连同“变化了什么”的信息一起喂给Claude Code：

以下题目入库时的背景是：[原来的系统/规则/技术栈状态]。

最近发生的变化是：[描述发生了什么变化]。

请判断：这个变化是否导致以下题目中的任何一道存在“答案不再正确”或“题干描述的场景不再成立”的问题？请逐题给出判断。

对于存在问题的题目，请标注：

• “需修改”：题目的考查点仍然有效，但需要调整题干或选项中的某些信息
• “需废弃”：题目的考查点和现有系统/规则/技术栈已经完全不匹配，建议从题库中移除

这个方法让我在最近一次系统重构后，40分钟内就完成了对涉及该系统的27道题目的审查，其中标识了4道需要修改、2道需要废弃。如果全凭人工逐题去判断，这个工作量至少要大三倍而且容易遗漏。

六、不同情况下的行动建议与取舍

上面讲了六个具体的技法，都属于“怎么做好”的范畴。但对很多团队来说，真正的困难往往不在“怎么做好”，而在“怎么开始做”以及“做到什么程度算够了”。

这一部分专门处理“做选择”的问题。

情况一：小团队（10人以下），培训频率低，没有专职培训负责人

你的核心矛盾：出题这件事很重要，但全团队能投入的时间非常有限。

我的建议：优先使用“事故回溯法”，其他技法可以缓一缓。

逻辑是这样的：小团队最大的优势是成员之间信息透明度高，大家都知道自己团队发生过什么事故、踩过什么坑。用“事故回溯法”出题，不需要你再花额外的时间去同步上下文。而且因为团队小，每一道基于真实事故的题都能引发热烈的讨论，一个人做了题，另一个人看到会说“这个事故那天刚好是我值班，我补充一个细节”。

具体执行上的取舍：

• 取“深度”舍“广度”。不要试图为每次培训都生成一套完整的练习题，而是精选团队过去一年最重要的2-3个技术事故，基于它们生成一组深度题。
• 取“讨论”舍“考核”。小团队的练习题目的不是打分排名，而是激发讨论和反思。所以问答题和开放性问题占的比例可以比大团队更高。
• 出题频率：建议每季度集中出一次题，一次产出足够覆盖未来三到四个月内部技术分享的需求量。不要每两周出一次，小团队扛不住这个节奏。

情况二：中型团队（30-100人），有培训体系，有负责培训的人但不是全职

你的核心矛盾：题库的量上来了，但质量和一致性难以保证。多人参与出题，每个人用Claude Code的习惯不同，出来的题目风格差异大。

我的建议：先建一套“出题Prompt模板库”，再谈发散和个性化。

前面我讲了很多定制的技巧，但这里的“定制”指的是题目内容要贴合团队，不是指每个人按自己的偏好随意发挥。团队的Prompt必须有一套公共的“底座”，所有人在底座之上再做个性化。

这个底座至少包含：

• 一段固定的“团队画像描述”（技术栈、业务、学员画像，一次性写好，所有人出题时都贴这一段）
• 一份“团队术语映射表”（统一维护，定期更新，所有人共用）
• 每种题型的标准输出格式规范（比如单选题的选项标识统一用A/B/C/D，问答题的参考答案必须附评分要点，等等）

具体执行上的取舍：

• 取“一致性”舍“创意度”。在题库建设的早期阶段，宁可题目风格统一甚至略显单调，也不要出现“张三出的题像八股文、李四出的题像脑筋急转弯”的情况。
• 指定一个人做“题库主理人”，负责审核入库的每一道题，并对Prompt模板库做版本管理。
• 出题频率：建议每月集中出一次，由培训负责人提前规划好每期培训需要的题型和数量，然后分配给相应主题的讲师去执行出题。

情况三：大团队（100人以上），多业务线，跨地域，培训需求复杂

你的核心矛盾：不同业务线的技术栈、业务知识差异很大，一套统一的题库根本不能覆盖所有人的需求。但如果每个业务线各自为政搞题库，又无法做跨线知识共享。

我的建议：建一个“核心题库”和多个“业务线题库”的分层结构。“核心题库”包含跨线通用的技术能力和工程素养类题目（比如代码Review能力、故障排查方法论、系统设计权衡思维），由中央培训团队负责维护。“业务线题库”则由各线技术负责人自行建设，但必须复用中央团队提供的Prompt模板库和出题SOP。

这个架构的好处是：共性部分保证质量下限，个性部分支撑业务适配。

具体执行上的取舍：

• 中央团队不负责各业务线的业务类题目。因为“让不了解你业务的人帮你出业务题”是必败的。
• 但中央团队必须输出“出题能力”，包括出题培训、Prompt模板、审核标准、Claude Code使用指南。让业务线的人具备“自己给自己出好题”的能力，比帮他们出100道题更有价值。
• 跨线流动机制：鼓励各业务线把自己题库中“具有跨线参考价值”的题目（比如优秀的故障排查案例）贡献到核心题库。可以设置一定的激励，比如季度最佳贡献题目的讲师有额外奖励。

出题这件事的“度”：做到什么程度就该停了？

这是我在帮团队做培训优化时最常被问到的一个问题，也是最少被认真思考的问题。

很多团队在尝到了Claude Code出题的甜头之后，容易陷入一种“题库军备竞赛”，拼命出题、堆数量、追求覆盖所有知识点的所有维度。但我必须泼一盆冷水：题库不是越大越好。

我观察到一个明显的边际效益递减曲线。一个小团队，从零开始建设题库，前50道高质量、贴合业务的自有题目带来的培训效果提升是巨大的。从50道到150道，增益依然显著但曲线开始放缓。但当题库超过200道之后，继续增加题目数量的边际收益变得非常低，因为学员根本没有足够的时间做完那么多题，而且新出的题和已有的题之间的差异化也越来越难拉开。

我的判断标准是：当你的团队中每个人在每次培训后平均能认真完成并消化3-5道高质量练习题时，不要再增加题量了，把精力转向提升这3-5道题的质量和时效性。

具体来说，如果你发现以下三个信号中的任何一个，就该停下来审视了：

1. 学员开始跳过题目直接看答案。 说明题目已经多到超出了他们的时间承受力，或者题目的吸引力下降到了他们觉得“不值得认真做”的程度。
2. 讲师的出题热情下降。 一开始用Claude Code出题有新鲜感，但如果不控制节奏，很快会变成一种负担。当出题人都在敷衍的时候，题目质量必然跳水。
3. 题库中超过30%的题目在过去三个月内没有人被分配到、没有人做过。 这说明这些题目要么和当前培训脱节，要么从一开始就没有存在的必要。

七、关键能力总结：从“会用Claude Code出题”到“用Claude Code出团队的题”

回到最开始那个场景。四个月前，我对着Claude Code吐出来的第14版练习题发呆，意识到“通用题在浪费学员时间”。在那之后的四个多月里，我做了几十次实验、审了超过400道AI生成的题目、参与了大大小小十几场培训的题目设计。如果只能留下一条最重要的经验，那就是这一条：

Claude Code是你在这件事上能找到的最聪明的“出题助理”，但你必须承担起“出题主编”的角色。 助理负责执行和产出，主编负责定方向、给素材、做判断。你给助理的素材越丰富、越精准、越“内部”，它产出的东西就越不可能被外部替代。

如果你今天看完这篇文章只能带走一件事，带走这个：下一次打开Claude Code之前，先花10分钟收集三段信息，你团队当前的技术栈细节、最近一次让你印象深刻的技术事故的简要描述、以及三个你团队的内部“黑话”。然后把这三段信息放进你的第一条Prompt里。

你会看到完全不一样的出题结果。

如果你已经在用Claude Code出题了，我建议你做一件事：从你们现有的题库里随便抽10道题，拿给你们团队里公认“技术判断力最强”的那个人，问他一个问题，“这10道题里，有几道让你觉得‘只有我们团队才能出这样的题’？”

如果他的答案是“三四道”或更少，那你可能需要重新审视一下自己的出题方式了。

下一步行动，我不说“赶紧去试试”这种正确的废话。我说三件更具体的事：

第一，打开你团队的事故报告归档，找到过去一年中影响最深刻的两份。用本文“技法一”的结构提取素材，然后打开Claude Code，试一次。

第二，花30分钟和你团队里最资深的那个工程师聊一聊，问他一个问题：“你觉得咱们团队新人最容易在哪些事情上重复犯老错误？”把他提到的场景记下来，这些就是你下一套题的核心素材。

第三，审视一下你现有的题库。把那些“去掉你们的内部术语之后、任何一个同技术栈的团队都能直接用”的题目标记出来。不用删，但要有意识，这类题的比例应该逐步降低，取而代之的是“丢了你们内部上下文就没法做”的题。

Claude Code能帮你加速这个进程，但它不能替你决定方向。方向这件事，永远靠人。