同一个需求，我先出技术方案，再让AI出方案——差距让我沉默了

上周我带着一个新人做需求评审。需求不复杂给平台做一个用户行为日志系统记录用户在App里的操作轨迹支持后续查询和分析。评审开始前我让他先独立想10分钟把技术方案思路说出来。他想了一会儿打开Cursor把需求文档粘进去。30秒后Cursor吐出了一份技术方案密密麻麻三页纸。他把屏幕转向我说你看方案出来了。我没说话。因为我上周刚做了一个实验同样这个需求我先花30分钟独立出方案再让AI出一份然后对比。结果让我沉默了。一、实验背景我做这个实验不是为了证明人比AI强或者AI比人强。是因为我发现了一个越来越普遍的现象身边越来越多的工程师拿到需求的第一件事是打开AI工具。不是坏事效率确实高了。但有一天一个工作了3年的同事问我我感觉自己越来越不会独立思考了脑子像生锈了一样。这句话让我停下来想了很久。如果你从来不独立出方案只靠AI生成你的方案设计能力还在吗所以我做了这个实验。规则很简单同一个需求我先独立思考不查资料不用AI30分钟内出方案再把同样的需求喂给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 ILM180天自动滚动删除我对这个方案还算满意。然后我把同样的需求喂给了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实验室不讲概念只谈实战 代码开源每周更新