1. 从一次差点翻车的接口设计说起去年秋天我接手了一个订单履约系统的重构项目。需求本身不算复杂把原来单体应用里的下单、库存扣减、履约单生成三段逻辑拆成独立服务通过消息队列解耦。我花了大概两个小时把领域模型和时序图画完正准备动手写详细设计文档同事丢给我一个AI编程助手说“你试试让它帮你出个初稿能省不少时间”。我确实试了。把需求描述和几张草图丢进去不到三十秒它吐出来一份看起来相当完整的设计方案服务拆分、接口定义、消息格式、异常处理、甚至还有一段伪代码。第一眼的感觉是“这东西真能处”。但当我逐行读下去冷汗就下来了——它在库存扣减和履约单生成之间设计了一个同步RPC调用而这两个服务恰恰是我要解耦的核心。如果按它的方案落地消息队列就白引入了高峰期依然会级联阻塞。这件事让我重新思考了一个问题AI在技术设计里到底该扮演什么角色它不是不能信而是你得知道什么时候该信、什么时候必须自己拍板。这篇内容就是把我这大半年和AI结对做设计的经验拆开讲包括哪些环节它确实能提效、哪些环节它给的答案必须打问号、以及我是怎么建立一套“信任分级”机制的。如果你也在用AI辅助架构设计或技术方案评审这些踩过的坑应该能帮你少走点弯路。2. AI在技术设计里真正擅长的三件事2.1 把零散需求整理成结构化文档技术设计最耗时的部分往往不是“想”而是“写”。你脑子里已经有方案了但要把背景、目标、非目标、约束条件、接口定义、数据模型、异常分支一条条写清楚这个过程非常磨人。AI在这件事上表现相当好——你把需求要点用大白话列出来它能帮你扩写成一份格式规整的设计文档初稿。我现在的习惯是先用自由文本把需求背景、核心流程、关键约束写下来不需要讲究结构想到哪写到哪。然后让AI基于这段文字生成一份带章节的设计文档骨架。它会把“非功能需求”单独拎出来会把“边界条件”列成表格这些确实比我自己从零搭要快。但注意它整理的是你给它的信息不会帮你发现你没说出来的隐含需求。比如你忘了提“库存扣减必须幂等”它大概率也不会主动补上除非你在提示词里明确要求它检查幂等性。2.2 快速生成多种方案供你对比技术设计里经常遇到“条条大路通罗马”的情况缓存用本地还是分布式、消息用Kafka还是RocketMQ、服务间调用用同步还是异步。AI的优势在于它能快速把几种常见方案的优缺点列出来形成一个对比矩阵。虽然这些对比未必完全准确但至少能帮你快速建立一个决策框架。我一般会这样问它“针对XX场景列出三种可能的实现方案分别从一致性、可用性、运维复杂度、团队熟悉度四个维度做对比。”它给出的表格通常能覆盖七八成需要考虑的因素剩下的两成——比如你们团队对某个中间件的实际运维经验、公司基础设施的现状——只有你自己知道。AI给的是通用视角的对比你要做的是把通用视角和你的具体上下文做减法。2.3 对已有设计做“盲审”式挑刺这是我觉得AI最有价值的一个用法。当你已经写完一份设计文档自己反复看容易陷入思维定势这时候让AI扮演一个“挑刺的评审者”角色往往能发现一些你忽略的点。我会在提示词里明确要求它“假设你是一个严格的架构评审者找出这份设计中可能导致线上故障的三个隐患并说明触发条件。”实测下来它确实能指出一些我没想到的边界情况比如“如果消息消费失败后重试三次仍然失败死信队列的告警阈值设了吗”“库存扣减和订单状态更新不在同一个事务里中间宕机怎么恢复”。这些问题不一定都是真问题但它提供了一个外部视角的检查清单比我自己对着文档干想要高效得多。3. 那些AI一本正经胡说八道的时刻3.1 它会把“常见做法”当成“最佳做法”塞给你AI的训练语料里包含了大量技术博客、开源文档和问答社区的内容这导致它有一个明显的倾向把出现频率最高的方案当成推荐方案。比如你问它“服务间通信怎么做”它大概率会推荐RESTful API或者gRPC因为这两种在公开资料里出现得最多。但你的场景可能恰恰需要基于消息的异步通信或者基于共享存储的批处理模式。我踩过的一个坑是在设计一个对账系统时AI建议用定时任务轮询数据库来比对两边数据。这个方案本身没错但它没有考虑数据量——我们的对账表每天新增千万级记录轮询全表扫描根本不现实。AI不知道你的数据规模、QPS、延迟要求它只能给“平均情况”下的答案。所以每次它给出方案建议我都会追问一句“这个方案在数据量达到XX、并发达到XX的情况下还成立吗”这一问往往能逼出它方案里的隐含假设。3.2 它会在你不熟悉的领域编造看似合理的细节这是最危险的情况。当你对某个技术领域不够熟悉时AI生成的错误内容你根本识别不出来。我在设计一个基于事件溯源的审计模块时AI建议了一种“快照事件回放”的混合存储方案听起来很专业术语也用得对。但我后来查了资料才发现它把快照的生成时机和事件版本号的对应关系搞错了——按照它的方案回放时会出现状态不一致。判断AI是否在编造的一个实用技巧是让它给出具体的数字或公式。比如它说“这个方案能支撑高并发”你就问“具体支撑多少QPS怎么算出来的”。如果它给不出合理的计算过程只是重复“高并发场景下表现良好”这类空话那大概率是在糊弄。真正靠谱的方案一定能落到具体的参数和计算上。3.3 它倾向于过度设计把简单问题复杂化AI似乎有一种“炫技”倾向。你让它设计一个内部管理后台的权限模块它可能会给你搬出RBAC、ABAC、策略引擎、属性加密一整套。但你的实际需求可能只是“管理员能看所有数据普通用户只能看自己的”。这种过度设计如果落地会带来巨大的维护成本。我的应对方式是在提示词里加一个约束——“用最少的组件和最简单的方案实现优先考虑团队现有技术栈”。这句话能显著降低它“堆砌技术名词”的概率。另外每次它给出一个复杂方案我都会问自己这个复杂度是需求本身带来的还是AI为了显得专业而加上去的4. 我总结的“信任分级”实操框架4.1 把设计任务按风险等级分类经过大半年的磨合我现在会把技术设计任务分成三类对应不同的AI参与程度任务类型典型场景AI参与度我的角色低风险整理类文档格式化、术语统一、方案罗列高度信任直接采用初稿审核事实准确性中风险分析类方案对比、边界条件检查、风险识别参考其输出逐条验证结合上下文筛选高风险决策类核心链路设计、数据一致性方案、容量规划仅用作“反面教材”完全自主决策这个分类的关键在于风险等级不是由技术难度决定的而是由“出错后的修复成本”决定的。文档格式错了改一下就行但核心链路设计错了可能导致线上故障修复成本天差地别。4.2 用“三问法”快速判断AI输出的可信度每次AI给出一个设计建议我会快速问自己三个问题这个方案依赖哪些我没告诉它的假设比如它假设网络可靠、假设消息不丢、假设数据量不大。把这些假设列出来逐个核对是否成立。如果这个方案错了最坏的结果是什么如果最坏结果是“文档需要重写”那可以放心用如果是“线上数据不一致”那就必须自己重新设计。我能不能用一句话向团队解释清楚这个方案为什么是对的如果解释不了说明我还没真正理解它这时候采用就是盲目信任。这三个问题花不了两分钟但能过滤掉大部分“看起来对但实际有问题”的AI输出。4.3 建立自己的“AI输出检查清单”针对技术设计这个场景我整理了一份检查清单每次AI给出方案后逐项过一遍一致性方案里提到的所有组件它们之间的数据流是否闭环有没有“只写不读”或“只读不写”的环节边界空值、零值、超大值、并发冲突这些边界情况方案里有没有覆盖失败路径每个网络调用、每次磁盘写入、每条消息消费失败后怎么处理重试策略是什么可观测性方案上线后怎么知道它运行正常关键指标有哪些告警阈值怎么定回滚如果上线后发现有问题怎么快速回退有没有数据迁移的逆向操作这份清单里的问题AI有时候能答上来有时候答不上来。答不上来的部分就是我必须自己补上的部分。5. 一次完整的“人机结对”设计过程还原5.1 需求拆解阶段我主导AI辅助回到开头那个订单履约系统的例子。这次我没有直接让AI出方案而是先自己把需求拆成几个核心问题下单和库存扣减之间一致性要求是什么允许短暂不一致吗履约单生成的触发条件是什么是支付成功还是库存扣减成功如果库存扣减成功但履约单生成失败怎么补偿我把这三个问题写清楚然后让AI针对每个问题列出可能的答案和对应的技术方案。它给出的选项确实拓宽了我的思路比如它提到“可以用本地消息表实现最终一致性”这个方案我之前没考虑过。但最终选哪个是我根据团队对消息中间件的熟悉程度和运维成本决定的。5.2 方案设计阶段AI出草稿我逐行审方案设计阶段我让AI基于我确定的核心决策生成一份详细设计文档。它写得很快接口定义、消息格式、状态机都列出来了。但我逐行审的时候发现了几个问题它把库存扣减的响应设计成了同步返回扣减结果但我们的场景是异步消息这里它“习惯性”地用了同步模式。它定义的消息格式里缺少一个关键字段——业务流水号没有这个字段就无法做幂等。它的状态机里少了一个“已取消”状态而我们的业务里用户是可以取消订单的。这三个问题都不是“AI能力不足”而是它不知道我的具体约束。同步还是异步、需不需要幂等、有没有取消操作这些信息只有我有。所以方案设计的正确姿势是AI负责把框架搭出来我负责往里填业务约束。5.3 评审阶段让AI扮演“魔鬼代言人”设计文档写完后我让AI扮演一个“专门挑刺的评审者”提示词是这样的“你是一个严格的架构评审者你的任务是找出这份设计中可能导致线上故障的隐患。重点关注数据一致性、失败恢复、并发冲突、容量瓶颈。每个隐患要说明触发条件和影响范围。”它给出了五条意见其中三条是真问题两条是过度担心。真问题里有一条特别有价值它指出“库存扣减和履约单生成之间的消息如果重复消费会导致重复履约”。这个问题我确实没考虑到后来在消息消费端加了幂等校验。AI在“找问题”这件事上比“给方案”靠谱得多因为找问题不需要了解你的全部上下文只需要基于通用经验做逻辑推演。6. 比工具选型更重要的事建立自己的判断锚点6.1 为什么同一个AI在不同人手里效果差很多我观察到一个现象同一个AI工具在不同工程师手里产出的设计质量差异巨大。有人用AI写出高质量的设计文档有人用AI写出一堆看似专业但无法落地的废话。差异不在于提示词写得好不好而在于使用者自己有没有判断锚点。判断锚点就是你脑子里的一套标准什么样的设计是好设计、什么样的方案在你的场景下可行、什么样的复杂度是可以接受的。有了这套锚点AI的输出就是“素材”你可以快速筛选、组合、修正。没有这套锚点AI的输出就是“答案”你只能全盘接受或全盘否定。6.2 我的判断锚点是怎么建立起来的说实话这个锚点不是看几篇文章就能建立的它来自实际踩坑。我经历过消息重复消费导致数据错乱、经历过缓存和数据库不一致导致用户看到脏数据、经历过同步调用链过长导致雪崩。这些经历在我脑子里形成了条件反射看到同步调用就想到超时和重试、看到消息就想到幂等和顺序、看到缓存就想到失效和穿透。AI可以帮你加速设计过程但它不能替你积累这些条件反射。所以我的建议是不要因为有了AI就跳过“自己动手设计”的阶段。你可以让AI出初稿但一定要自己逐行审、自己推演失败路径、自己算容量。这个过程本身就是建立判断锚点的过程。6.3 把AI当成“陪练”而不是“代练”我现在对AI的定位很明确它是一个不知疲倦的陪练。它可以随时陪我推演方案、帮我查漏补缺、给我提供不同视角。但它不能替我上场打比赛。技术设计的最终责任人是我线上出了故障背锅的也是我。这个责任边界想清楚了使用AI的心态就稳了——用它提效但不对它产生依赖参考它的输出但保留自己的判断。7. 几个让我印象深刻的“AI翻车”案例7.1 它把“最终一致性”理解成了“最终会一致”在设计一个跨服务的余额扣减方案时AI建议用“异步对账补偿”来实现最终一致性。听起来没问题但它的补偿逻辑是“定时扫描差异记录发现不一致就重新执行扣减”。这里有个致命问题重新执行扣减可能导致重复扣款。它把“最终一致性”简单理解成了“最终会一致”但忽略了达成一致的过程中可能引入新的不一致。正确的做法应该是补偿操作必须是幂等的或者补偿的是“修正”而不是“重放”。比如发现A服务扣了款但B服务没记账应该补记账而不是重新扣款。这个区别AI没有区分因为它对“一致性”的理解停留在概念层面没有落到操作层面。7.2 它给出的容量估算缺少关键变量有一次我让AI估算一个消息队列的容量需求它给了一个公式日均消息量 × 峰值系数 ÷ 单机吞吐。公式本身没错但它没有考虑消息大小、副本数、磁盘IO这些因素。按照它的估算三台机器就够了但实际上因为消息体较大加上三副本至少需要六台。AI做容量估算时倾向于用“教科书公式”而忽略工程实践中的放大因子。我的经验是AI给的估算值至少乘以1.5到2的安全系数然后再根据自己的经验做调整。更好的做法是让它列出估算所依赖的所有假设你逐个核对哪些假设在你的场景下不成立。7.3 它在“非功能需求”上几乎从不主动展开技术设计里有一类需求叫“非功能需求”性能、可用性、安全性、可维护性、可观测性。AI在功能设计上表现不错但在非功能需求上几乎从不主动展开除非你明确要求。比如它设计了一个API但不会主动说这个API的QPS上限是多少、超时时间设多少、限流策略是什么。我的做法是在提示词里强制要求它输出“非功能需求”章节并且给出具体的数值而不是定性描述。比如不要写“高性能”要写“P99延迟小于200ms支撑5000 QPS”。如果它给不出具体数值说明它没有认真考虑这个维度这时候就需要我自己补上。8. 写给正在用AI做技术设计的你如果你刚开始用AI辅助技术设计我的建议是先从低风险任务开始逐步建立信任边界。不要一上来就让AI设计核心链路先让它帮你整理文档、列方案对比、做检查清单。在这些低风险场景里你会慢慢摸清它的能力边界和犯错模式。然后养成“追问假设”的习惯。每次AI给出一个方案不要只看结论要看它依赖了哪些假设。这些假设往往藏在字里行间需要你主动追问才能暴露出来。比如它说“用缓存提升性能”你就问“缓存失效时怎么办”它说“异步解耦”你就问“消息丢了怎么补偿”。最后保留自己动手设计的习惯。AI可以帮你写初稿、做检查、提供参考但核心决策必须自己拍板。这不是因为AI不可靠而是因为只有你自己对业务上下文负责。AI不知道你的团队能力、不知道你的运维现状、不知道你的用户特征这些只有你知道。把AI的输出和你的上下文结合才是技术设计的正确打开方式。我在实际使用中最大的体会是AI让“写设计文档”这件事变快了但让“想清楚设计”这件事变得更重要了。因为当生成变得廉价判断就变成了稀缺能力。你得知道什么是对的、什么是错的、什么是在你的场景下可行的。这个判断力AI给不了你只能自己练。