第1875篇：技术评审会的AI准备——用LLM提前挑战你方案的弱点
第1875篇：技术评审会的AI准备——用LLM提前挑战你方案的弱点
技术评审会上最尴尬的事情是什么？
是你花了一周时间写的方案，在会上被一个问题直接击穿，然后当场无法回答。更糟的是，你回去重新想了三天，发现这个问题确实是个根本性问题，方案需要大改。
这种情况我经历过不止一次。后来我慢慢总结出来：大多数在评审会上被问倒的问题，并不是什么刁钻的问题，而是那些我在写方案时"假装它不存在"的问题。
LLM在这件事上能帮到你。它不会碍于面子，也不会因为担心关系而避开敏感问题，它会直接指出你方案里的弱点，让你在会前就面对它们。
评审会上最常见的质疑方向
我整理了一下，技术评审会上的质疑大概集中在这几个方向：
每个方向都有对应的"经典刁钻问题"。好的技术方案，是在写方案时就把这些问题回答掉，而不是等着在评审会上被问到。
核心工具：多角色质疑模拟器
我做了一个工具，叫"多角色评审模拟器"。它用不同的专家视角来挑战你的方案：
@Service
public class TechReviewSimulator {
// 评审官角色定义
private static final List<ReviewerRole> REVIEWER_ROLES = List.of(
ReviewerRole.builder()
.name("资深架构师")
.focus("整体架构合理性、扩展性、技术债务")
.challengeStyle("从宏观视角质疑技术选型和架构决策")
.build(),
ReviewerRole.builder()
.name("性能工程师")
.focus("响应时间、吞吐量、资源利用率、极端场景")
.challengeStyle("用具体数字和压测场景质疑性能假设")
.build(),
ReviewerRole.builder()
.name("安全工程师")
.focus("认证授权、数据安全、注入攻击、敏感数据处理")
.challengeStyle("从攻击者视角挖掘安全漏洞")
.build(),
ReviewerRole.builder()
.name("SRE工程师")
.focus("可观测性、故障恢复、运维复杂度、告警")
.challengeStyle("从运维噩梦的角度质疑方案")
.build(),
ReviewerRole.builder()
.name("业务方代表")
.focus("是否满足业务需求、实现速度、ROI")
.challengeStyle("从业务价值和交付时间的角度质疑")
.build()
);
public TechReviewReport simulate(String techProposal,
String projectContext,
String constraints) {
List<RoleReviewResult> roleResults = REVIEWER_ROLES.parallelStream()
.map(role -> simulateRoleReview(role, techProposal, projectContext))
.collect(Collectors.toList());
// 综合所有角色的质疑，生成优先级排序
String synthesis = synthesizeFindings(roleResults);
return TechReviewReport.builder()
.roleResults(roleResults)
.synthesis(synthesis)
.criticalIssues(extractCriticalIssues(roleResults))
.suggestedAdditions(extractSuggestions(roleResults))
.build();
}
private RoleReviewResult simulateRoleReview(ReviewerRole role,
String proposal,
String context) {
String prompt = """
你现在扮演一位%s，正在评审一个技术方案。
你的关注点：%s
你的质疑风格：%s
项目背景：%s
技术方案：
%s
请从你的专业角度：
1. 提出3-5个最关键的质疑问题（要有具体场景支撑）
2. 指出方案中你认为存在的潜在风险
3. 列出方案中缺失的必要内容
4. 如果你要投反对票，你会基于什么理由
请直接、犀利，不要客气。这是技术评审，不是友情鼓励。
输出格式：
{
"role": "%s",
"critical_questions": [
{
"question": "问题内容",
"severity": "high/medium/low",
"context": "为什么这个问题很重要"
}
],
"risks": ["风险描述列表"],
"missing_content": ["缺失内容列表"],
"veto_reasons": ["如果投反对票的理由，如果有的话"]
}
""".formatted(
role.getName(), role.getFocus(), role.getChallengeStyle(),
context, proposal, role.getName()
);
String response = chatClient.call(prompt);
return parseRoleResult(response, role.getName());
}
}这个模拟器会并行运行5个角色的质疑，通常2-3分钟就能输出一份完整的"预演评审报告"。
实战：一个缓存方案的预演
让我用一个具体例子说明这个工具的价值。假设你设计了这样一个方案：
为了解决首页数据接口慢的问题，我们计划引入Redis缓存。缓存策略是：首次请求时写入缓存，TTL设置为5分钟。后续请求直接从缓存读取，减少数据库压力。
这个方案看起来没什么问题，对吧？我们来看看模拟器会输出什么。
资深架构师视角：
质疑1：缓存穿透没有防护方案
严重性：高
背景：如果有大量请求查询不存在的Key，每次都会穿透到数据库。
比如恶意请求或用户ID枚举攻击，会导致数据库压力骤增。
方案中没有提到Bloom Filter或空值缓存策略。
质疑2：缓存击穿没有处理
严重性：高
背景：某个热点Key在TTL到期瞬间，会有大量并发请求同时穿透到数据库。
5分钟TTL意味着每5分钟可能发生一次击穿风险。方案中没有互斥锁或
逻辑过期策略。
质疑3：缓存雪崩风险
严重性：中
背景：如果大量Key同时过期（比如系统重启后重建缓存），数据库会承受
突发压力。需要TTL随机化或预热机制。SRE工程师视角：
质疑1：Redis故障时的降级策略是什么？
如果Redis宕机，服务是直接报错还是降级到数据库直查？
方案中没有提到fallback机制，生产故障时这是第一个被问到的问题。
质疑2：缓存一致性如何保证？
数据库数据更新后，对应的缓存如何失效？
TTL被动过期意味着5分钟内可能读到脏数据，这个对业务可以接受吗？
没有看到主动更新或删除缓存的机制。
质疑3：Redis容量规划在哪里？
首页数据有多少，每个Key大概多大？
Redis的内存会不会被打满？maxmemory-policy设置的是什么？你看，一个"看起来没问题"的缓存方案，被质疑出了5个严重问题。这些问题在你提交方案之前，你有没有想到？
生成预答案：不只是找问题，也要帮你回答
找到问题还不够，你还需要准备答案。工具的第二步是生成预答案草稿：
@Service
public class ReviewAnswerPreparationService {
/**
* 为每个质疑问题生成建议答案
* 包括：直接回答、补充方案、需要进一步调研的项
*/
public List<PreparedAnswer> prepareAnswers(
String techProposal,
List<CriticalQuestion> questions,
String teamCapabilities,
String existingInfrastructure) {
return questions.parallelStream()
.map(q -> prepareAnswer(q, techProposal, teamCapabilities, existingInfrastructure))
.collect(Collectors.toList());
}
private PreparedAnswer prepareAnswer(CriticalQuestion question,
String proposal,
String teamCap,
String infra) {
String prompt = """
背景信息：
- 技术方案：%s
- 团队能力：%s
- 现有基础设施：%s
需要准备的质疑回答：
问题：%s
问题背景：%s
请帮我准备一个完整的回答，包含：
1. 直接回答（如果方案里已经有考虑到的话）
2. 如果方案确实有缺失，给出补充方案（优先使用现有基础设施）
3. 如果需要数据支撑，指出需要补充哪些测试/调研
4. 回答时需要承认的风险和取舍
5. 如果这个问题确实很难解决，给出诚实的评估
语气要专业、坦诚，不要试图掩盖问题。
评审官看得出来你是在回避问题还是真的有方案。
""".formatted(
proposal, teamCap, infra,
question.getQuestion(), question.getContext()
);
String answer = chatClient.call(prompt);
return PreparedAnswer.builder()
.question(question)
.suggestedAnswer(answer)
.requiresAdditionalWork(detectsGap(answer))
.build();
}
/**
* 检测答案是否揭示了需要补充工作的地方
*/
private boolean detectsGap(String answer) {
return answer.contains("需要进一步") ||
answer.contains("还需要调研") ||
answer.contains("方案中未考虑");
}
}方案补充：把缺失内容加回去
有了质疑列表和预答案，下一步是把缺失内容补进方案里。这一步我让LLM生成补充章节的草稿：
@Service
public class ProposalEnhancementService {
/**
* 根据评审模拟报告，生成方案补充章节
*/
public List<ProposalSection> generateMissingSections(
String originalProposal,
TechReviewReport reviewReport) {
List<String> missingTopics = reviewReport.getAllMissingContent();
return missingTopics.stream()
.map(topic -> generateSection(topic, originalProposal))
.collect(Collectors.toList());
}
private ProposalSection generateSection(String topic, String proposal) {
String prompt = """
这是一份技术方案：
%s
该方案被评审指出缺少以下内容：%s
请为该方案生成这部分内容的草稿，要求：
1. 与现有方案风格一致
2. 内容要具体，有方案细节，不是泛泛而谈
3. 如果有多个选项，要说明选择依据
4. 如果某些数字需要实测确定，明确标注"待压测确认"
5. 控制在300-500字
""".formatted(proposal, topic);
String content = chatClient.call(prompt);
return ProposalSection.builder()
.topic(topic)
.content(content)
.isGenerated(true) // 标注是AI生成，需要人工审核
.build();
}
}一个完整的评审准备工作流
把以上步骤串起来，我的评审准备流程是：
整个流程跑一遍大概30-45分钟，比你自己反复读方案找问题要高效得多，而且更系统。
评审会上的实际效果
用了这个方法之后，我自己的评审会通过率从原来的"经常需要大改"变成了"通常一次通过，偶有小改"。
更重要的是，即便评审时被问到了意料之外的问题，因为做了系统性的事前梳理，心理状态也不一样——你知道你已经思考过了大部分角度，被问到的问题更可能是真正的盲点，而不是你偷懒没想到的。
有几点额外的经验：
经验一：不要试图在方案里掩盖弱点
LLM帮你找到了弱点，但你要做的不是用文字把弱点包装成优点，而是正视它，给出处理策略。评审官见过太多方案，他们能闻到"在回避问题"的气息。
经验二：对不确定的事情，主动说出来
"这个部分我们需要压测数据才能最终确定"比"我们评估能达到XX性能"要可信得多。前者是诚实，后者是拍脑袋，评审官都知道。
经验三：准备对比方案的讨论
LLM的质疑里通常会包含"为什么不用XX方案"，提前准备这个问题的答案，说明你做了方案对比，选择现有方案的原因。这是体现技术深度的地方。
经验四：区分方案里的决策和假设
方案里哪些是确定要做的，哪些是基于假设的（比如"假设并发量不超过1000QPS"）。把假设明确写出来，评审官会更信任你的方案，因为他知道方案的前提条件是什么。
两个不该用LLM做的事
最后说两个常见的误用：
误用一：让LLM直接修改你的方案
LLM不了解你的团队能力、你的基础设施、你的组织约束。它给的修改建议可能在技术上是对的，但在你的实际情况下不可行。方案的修改必须由你做，LLM只是提供思路。
误用二：把LLM的质疑当成"答题"，机械地逐条回应
有些质疑可能是LLM过度谨慎产生的误报，有些问题在你的具体场景下根本不是问题。要判断哪些质疑是真正值得回应的，而不是试图把所有质疑都消灭掉。
技术评审的本质是：你向更有经验的人展示你的思考深度，证明你考虑了足够多的角度。LLM帮你扩展了"你能思考到的角度"，但最终说服评审官的，还是你自己的判断和表达。