一位干了19年的首席工程师，用生成式AI（GenAI，自动生成内容的AI技术）画了3个月架构图，最后发现团队连系统边界都搞混了。这不是段子，是Verizon工程师Rohit Goyal在2024年踩的真坑——他把自己从"AI尝鲜者"到"回归手工"的完整经历写成了复盘，阅读量在LinkedIn直接破圈。
数据很扎眼：Gartner预测到2025年，30%的企业会因AI生成的错误架构决策导致系统故障。但另一边，麦肯锡的数据显示会用AI的解决方案架构师（Solution Architect，负责设计系统整体方案的技术负责人）效率提升40%。同一把刀，有人切菜有人切手。
第一阶段：AI代笔的蜜月期
Goyal的实验从2024年初开始。他把需求文档丢给Claude和GPT-4，让它们直接输出架构图、API设计和风险评估。前两周效果惊人——过去需要两天的初步方案，现在两小时出图。
他给团队定了个规矩：AI生成内容必须标注"草稿待审"。但问题来得比预期快。第三次评审会上，一位资深开发指着某张图问："这个微服务（Microservice，独立部署的小型服务模块）为什么要调用那个数据库？"Goyal愣住——那是AI画的，他自己也没细想。
追查后发现，AI把两个本不该直连的模块连在了一起，理由是"减少网络跳转"。听起来合理，但违背了Verizon的安全隔离政策。更麻烦的是，这个错误藏在第三层子图里，人工审核时完全漏过。
Goyal在复盘里写：「AI擅长把60分的东西包装成90分的样子。」
第二阶段：发现AI的"幻觉舒适区"
他做了个分类测试。把架构设计拆成五类任务：模式匹配（选技术栈）、约束满足（符合安全合规）、创造性综合（跨系统整合）、风险评估、文档生成。结果出人意料。
AI在文档生成上得分最高，风险评估勉强及格，创造性综合直接翻车。最危险的是模式匹配——AI推荐的方案看起来专业，但底层依赖的是2022年前的训练数据，对Verizon正在迁移的新技术栈一无所知。
有个具体案例。团队要设计一个支持千万级并发的计费系统，AI建议用Redis Cluster做缓存层。方案文档写得滴水不漏，甚至附上了故障转移流程图。Goyal差点签字，最后一刻发现：AI没考虑Verizon内部对Redis的许可证限制，这个方案上线就是合规事故。
他后来总结：「AI的自信程度和正确程度完全不成正比。它不会说'这部分我不确定'，它只会给你编一个最像答案的答案。」
第三阶段：重建人机协作的边界
Goyal没有弃用AI，而是重新设计了使用流程。核心原则只有一条：AI只能处理"有明确对错"的任务，任何需要权衡利弊的决策必须人工介入。
具体操作上，他把架构设计拆成三层。底层是事实层——技术参数、合规条款、历史事故记录，这部分让AI整理和核对，效率提升明显。中间是方案层——多个可行路径的对比，AI可以生成草稿，但必须附带"置信度标签"和"已知盲区说明"。顶层是决策层——选哪条路、承担什么风险，完全禁止AI参与。
他还加了个反向验证机制：让AI扮演"质疑者"角色，对人工方案挑刺。这个用法意外好用——AI能发现人类因思维惯性忽略的边缘情况，比如"如果主数据中心和灾备中心同时断网，这个降级策略是否生效"。
三个月后，团队效率数据出来了：方案产出时间从平均5.2天降到3.1天，但评审返工率从12%升到了19%，后来又回落到8%。那个峰值19%，正是团队还在摸索边界时的代价。
行业镜像：不是工具问题，是分工问题
Goyal的实验在架构师圈子引发了不少讨论。AWS的Principal Engineer Mark Schwartz跟了一篇长文，观点更直接：「很多架构师把AI当成实习生用，却期待它输出专家级判断。这本身就是认知错位。」
Schwartz打了个比方：AI是望远镜，不是导航仪。它能让你看得更远，但不能替你决定往哪走。问题在于，很多组织正在把望远镜架在驾驶座上。
数据侧面印证了这个判断。InfoQ 2024年架构师调查显示，67%的受访者每周使用AI辅助设计，但其中41%承认"曾直接采用AI建议而未充分验证"。更细的分层数据是：工作5年以下的架构师，这个比例是58%；15年以上的，降到23%。
Goyal在文章最后放了一张图——他手画的原始架构草图，旁边是AI生成的精美版本。配文：「左边这张丑图，救了右边这个漂亮方案。」
所以问题变成：当你的AI能在一分钟内生成一份看起来无懈可击的架构设计，你准备花多少时间去证明它是错的？
热门跟贴