同一个需求，我先出技术方案，再让AI出方案——差距让我沉默了
上周，我带着一个新人做需求评审。
需求不复杂：给平台做一个用户行为日志系统，记录用户在App里的操作轨迹，支持后续查询和分析。
评审开始前，我让他先独立想10分钟，把技术方案思路说出来。
他想了一会儿，打开Cursor，把需求文档粘进去。
30秒后，Cursor吐出了一份技术方案，密密麻麻，三页纸。
他把屏幕转向我，说："你看，方案出来了。"
我没说话。
因为我上周刚做了一个实验：同样这个需求，我先花30分钟独立出方案，再让AI出一份，然后对比。
结果让我沉默了。
一、实验背景
我做这个实验，不是为了证明"人比AI强"或者"AI比人强"。
是因为我发现了一个越来越普遍的现象：
身边越来越多的工程师，拿到需求的第一件事，是打开AI工具。
不是坏事，效率确实高了。
但有一天，一个工作了3年的同事问我："我感觉自己越来越不会独立思考了，脑子像生锈了一样。"
这句话让我停下来想了很久。
如果你从来不独立出方案，只靠AI生成，你的方案设计能力还在吗？
所以我做了这个实验。规则很简单：
- 同一个需求
- 我先独立思考，不查资料，不用AI，30分钟内出方案
- 再把同样的需求喂给AI，让它出方案
- 最后做完整的对比
需求是：用户行为日志系统（真实项目，已脱敏）。
二、需求说明
核心功能：
- 记录用户在App内的行为：页面访问、按钮点击、功能使用
- 支持按用户ID查询历史行为轨迹
- 支持按行为类型统计（如：某功能今天被使用了多少次）
- 数据保留180天，过期自动清理
业务背景：
- 日活用户约5万，高峰期并发约2000
- 现有系统：Spring Boot + MySQL + Redis
- 团队规模：5人，没有专职DBA和运维
三、我的方案（30分钟，独立输出）
我把30分钟的思考过程如实记录下来了，包括我考虑过的和没考虑到的。
首先想到的：存哪里？
5万日活，每个用户平均100次行为，一天就是500万条记录。180天就是9亿条。
MySQL肯定撑不住，第一反应是用Elasticsearch。
写入快，查询灵活，支持全文检索，刚好适合日志场景。
接着想：怎么写入？
直接同步写会影响主链路响应速度。用消息队列解耦，异步写入。
已有技术栈里没有消息队列，要引入RabbitMQ或Kafka。
考虑到团队只有5人，运维成本是个问题。
然后想：怎么查询？
按用户ID查轨迹，按行为类型做聚合统计，Elasticsearch都能支持。
索引设计：以user_id和timestamp为主要索引维度。
最后想：数据清理。
180天过期，ES支持ILM（索引生命周期管理），可以自动清理。
30分钟后，我的方案大纲：
技术选型：
- 日志存储：Elasticsearch
- 消息队列：引入RabbitMQ（已有团队有使用经验）
- App端：埋点SDK，批量上报（每30秒或累积50条上报一次）
架构：
App埋点 → HTTP接口接收 → RabbitMQ → Consumer写入ES
接口设计：
- POST /api/log/report（批量上报，App调用）
- GET /api/log/user/{userId}（查询用户轨迹）
- GET /api/log/stats（行为统计，内部使用）
数据清理：
- ES ILM，180天自动滚动删除
我对这个方案还算满意。
然后我把同样的需求喂给了AI。
四、AI的方案（逐条拆解）
我用的Prompt很简单，就是把需求原文粘进去，加了一句：
请给出完整的技术方案，包括技术选型、架构设计、核心接口设计和风险点。
AI的方案出来了。我花了20分钟认真读完，然后开始逐条和自己的方案做对比。
超出我预期的地方
第一，它考虑了"写入失败"的降级策略。
AI的方案里有这么一段：
消息队列消费失败时，建议设计死信队列（DLQ）和人工介入机制。 同时，App端上报失败时，应将日志缓存到本地，下次启动时重试， 避免行为数据丢失。
我的方案完全没想到App端的本地缓存重试。如果上报接口挂了，这批数据就丢了。
这是个真实的数据完整性问题。
第二，它提出了"数据分级存储"。
建议对日志数据做冷热分离：
- 近30天数据（热数据）：ES，快速查询
- 30-180天数据（冷数据）：转储到对象存储（OSS/S3），成本降低80%
ES存储成本较高，全量存180天在5万日活规模下， 存储成本大约在每月XX元，冷热分离可以显著降低。
我的方案是全量放ES，没有想过存储成本问题。
AI还给我算了一笔账，让我意识到这不是可以忽视的小问题。
第三，它指出了我的消息队列选型问题。
RabbitMQ在日志场景下需要注意： 消息堆积时内存压力较大，建议评估是否使用Kafka。 Kafka更适合高吞吐日志场景，且天然支持数据持久化和回放。
但如果团队没有Kafka运维经验，引入成本较高。 折中方案：使用阿里云MNS或腾讯云CMQ等托管消息队列， 减少运维压力。
这个trade-off分析，比我的方案要细致得多。我只考虑了"RabbitMQ团队有经验"，没有评估它在这个场景下的局限性。
AI答非所问的地方
第一，它的方案假设团队有能力运维ES集群。
AI给出了一套完整的ES集群部署方案：3个master节点，N个data节点，详细的JVM参数配置。
但我们团队5个人，没有专职运维，根本hold不住自建ES集群。
我们更可能用的是云托管的ES服务（阿里云/腾讯云），部署和运维完全不同。
AI不知道我们的团队规模和运维能力，所以给了一个"教科书级别正确但实际用不了"的方案。
第二，它没有考虑现有系统的改造成本。
AI的方案是从零开始设计的，接口命名、返回格式、异常处理方式，和我们现有系统完全不同。
如果直接用，需要对现有代码做大量改造。
但AI不知道我们的代码规范是什么样的，也不知道改造成本有多高。
第三，它建议引入Flink做实时计算。
如果后续有实时分析需求，可以考虑引入Flink， 实现用户行为的实时漏斗分析、A/B测试等。
现阶段我们的统计需求很简单，就是按行为类型计数。Flink是大炮打蚊子，引入成本远大于收益。
这是AI"大而全"的惯性：总是提供完备的技术栈，而不是适合当前阶段的最小可行方案。
五、差距让我沉默的原因
做完对比，我在椅子上坐了很久。
我沉默，不是因为AI比我强。
也不是因为我比AI强。
我沉默，是因为我发现了一件更重要的事：
AI的方案在广度上远超我。它覆盖了更多的技术细节，考虑了更多的边界情况，给出了更完整的风险列表。
但我的方案在深度上有AI没有的东西：我知道这5个人的团队能干什么、不能干什么，我知道我们的运维能力上限，我知道"引入Flink"意味着什么代价。
换句话说：
AI给出的是一个"完美世界"里的方案。
我给出的是一个"我们公司"里能落地的方案。
这两者之间的差距，不是技术能力的差距，而是业务判断力的差距。
AI不知道我们团队的运维能力，不知道我们的技术债，不知道我们半年内的业务发展方向，不知道我们上周刚因为引入一个新中间件翻了一次车还心有余悸。
这些上下文，只在我脑子里。
六、但有一件事我不能忽视
对比结束后，我做了一件有点羞耻的事：
把AI方案里那3个我没想到的点，逐条想了一遍，复盘自己为什么会漏掉。
App端本地缓存重试：我只想了服务端，没有站在客户端视角想上报失败的情况。典型的后端工程师思维盲区。
数据冷热分离：我习惯性地把"方案设计"和"成本核算"分开来想，方案设计阶段不考虑钱。但在一个小团队里，成本是技术选型的核心约束之一。
RabbitMQ在日志场景的局限：我对RabbitMQ的了解停留在"通用消息队列"层面，没有深入对比过它和Kafka在大量日志写入场景下的差异。这是知识盲区。
这3个漏洞，AI帮我找出来了。
这才是AI做方案设计真正的价值：不是替你出方案，而是帮你找到你的方案里的盲区。
七、正确的使用姿势
做完这个实验，我形成了一套自己的工作流。
第一步：人先出方案（20-30分钟）
不要一上来就问AI。
先独立思考，逼自己形成一个完整的方案轮廓，哪怕不完善。
这一步的目的不是"想出最好的方案"，而是激活你的判断力。
你在独立思考的过程里，会形成很多隐性的判断：这个技术我们团队能用、那个方案成本太高、这个风险我们可以接受。
这些判断，是你后面评估AI方案的基础。
没有这一步，你拿到AI的方案，只会觉得"好像挺对的"，然后照单全收。
第二步：AI补漏洞（不是出方案）
把你的方案思路告诉AI，让它来找问题：
我要做一个用户行为日志系统，我的初步方案是：
[粘贴你的方案]
背景：
- 日活5万，峰值并发2000
- 团队5人，无专职运维
- 现有技术栈：Spring Boot + MySQL + Redis
请帮我：
1. 找出这个方案可能存在的技术风险和漏洞
2. 指出我可能遗漏的边界情况
3. 针对我们团队规模，给出更适合的技术建议
不要问"给我出个方案"，要问"帮我找我方案的问题"。
这两个问法，AI给出的东西完全不同。
前者给你一个大而全的通用方案，后者给你针对你的具体情况的精准反馈。
第三步：人做决策（这一步不能外包）
AI给出了它的反馈，接下来的决策是你的，不是AI的。
哪些风险要接受，哪些要规避，哪些建议符合你们的实际情况，哪些是理论上正确但实际上做不到——这些判断，只有你能做。
Prompt模板（可直接用）：
我在做[系统名称]的技术方案，背景如下：
- 业务规模：[DAU/并发/数据量]
- 团队规模：[人数/技术栈/运维能力]
- 约束条件：[时间/预算/现有系统]
我的初步方案是：
[你的方案]
请帮我：
1. 找出这个方案的技术风险（按严重程度排序）
2. 指出可能遗漏的边界情况
3. 针对我们的团队规模，哪些建议可以简化或推迟
4. 有哪些我没提到但值得考虑的技术点
八、回到开头那个新人
评审结束后，我把AI生成的方案打印出来，放到他面前。
我问他："这个方案你能看懂吗？"
他说："能看懂，挺全面的。"
我指着"Flink实时计算"那一段，问他："这个你们能落地吗？"
他沉默了。
我又指着"3节点ES集群"的部署方案，问："这个你们能运维吗？"
他还是沉默。
然后我说：
"这个方案说的技术，大部分是对的。但它不知道你们是5个人，不知道你们上周刚因为引入一个新东西翻车了，不知道你们接下来3个月要赶哪些需求，没有时间做这么重的东西。
AI会写代码，但它不了解你们公司。
你的价值，恰恰在这里。"
他点了点头，第一次认真地开始在纸上写他自己的想法。
写在最后
这个实验让我想明白了一件事：
AI的方案没有错，只是它活在一个没有约束的世界里。
你的工作不是复制AI的方案，而是用你对业务的理解、对团队的了解、对现实约束的判断，把一个"理想方案"变成一个"能落地的方案"。
AI给你广度，你给方案深度。
这才是对的分工。
你平时出技术方案，是先自己想还是先问AI？欢迎评论区聊聊。
后端AI实验室 不讲概念，只谈实战 代码开源，每周更新
