很多人只是把 AI 当代码助手,但它其实已经能主导架构设计了

你好，我是曹犟，欢迎关注我的公众号。

最近在和一些同行交流的时候，我有一个这样的感受：有些同学对 AI Coding 的理解，还停留在 “AI 是一个高效的代码助手” 这一层。但如果只把 AI 用在编码环节，可能会低估它真正能做的事情。

在我们自己的实践里，AI 远不只是能写代码，它其实已经能参与、甚至主导架构设计了。当然，这里说的 “主导”，并不是替代人最终拍板，而是主导方案探索、信息收集、备选方案比较和初稿设计。最后的决策和取舍，依然是人的工作。

今天这篇文章，就想针对这个问题，把我的一些思考和经验分享给大家。一家之言，仅供参考。

引子：为什么我越来越有这个感受

这个感受的起点，是最近几个月在一些交流场合频繁被问到的问题。

不少同学会问我比较具体的技术架构选型问题，比如，“在我们这种场景下，Agent 框架应该怎么选？”；再比如，“我们公司的数据量大概是这样，内部知识库的架构应该怎么设计？”。

说实话，这些问题回答起来非常困难。一方面，我的确没有完全吻合他们场景的经验。每家公司的业务复杂度、数据规模、合规要求、已有系统都不一样，我很难凭已有经验给一个靠谱的答案。另一方面，AI 这个领域本身技术迭代太快，一方唱罢一方又登场，去年看起来合适的方案，今年可能就不再是最优解。

但有意思的是，当我回过头来看这些问题时，我发现：虽然我没法直接给出答案，但这类问题恰恰非常适合交给 AI 来解决。

这也是这篇文章想讲的核心判断。

PART01 很多人低估了 AI 真正的价值

把 AI 用在代码补全、生成函数、实现具体功能上，当然有价值。但这些都属于软件研发流程最后的“编码”环节。

可是，如果你真正带过研发团队，就会意识到一个事实：软件研发里真正更难、更影响结果的，很多时候不是 “怎么把代码写出来”，而是 “方案到底应该怎么设计”。

很多团队遇到的瓶颈，并不是代码写不出来，而是需求没有想清楚、边界没有划清楚、技术方案没有比较清楚。真正消耗时间的，是前期的方案探索、技术选型和约束澄清。

所以，如果只把 AI 放在编码这个最末端的环节，本质上就是让它做研发价值链里相对靠后的工作。真正能拉开差距的，不是谁让 AI 多写了几千行代码，而是谁更早也更好地让 AI 进入需求澄清和方案设计这些更靠前的环节。

毕竟，AI 时代，最不值钱的就是代码本身。

PART02 为什么说 AI 已经能进入架构设计阶段

最直接的原因，是我自己用下来的真实体感。特别是 Opus4.6 以上级别的模型，在我并不精通的领域，它们的架构设计能力已经远远超过我。

这背后其实有一个可以讲清楚的道理。架构设计的前期工作，本质上不是拍脑袋，而是信息收集、模式归纳、方案比较、约束澄清。这些事情，恰恰是大语言模型擅长的。

在一些个人并不熟悉、但开源世界已经有大量沉淀的问题上，AI 往往能比人更快看到更完整的方案空间。它接触过的论文、开源项目、技术博客、架构案例，数量上远远超过一个程序员在有限职业生涯里能接触到的。当你把自己的具体约束告诉它，它可以迅速把这些沉淀映射到你的场景上。

当然，这并不意味着 AI 可以替代人做最终决策，最终的判断还是要结合业务理解、团队能力、预算约束、历史包袱来综合取舍。但 AI 完全可以主导前期大量的探索性工作，并显著提升方案讨论的起点。

换句话说，过去你要和几个有经验的同事先做几周调研，再开一下午会也未必能收敛出来几个靠谱的候选方案，现在可能在一两个小时里就能和 AI 一起梳理清楚。

PART03 AI 是怎么 “主导” 架构设计的

具体到使用方法，我通常不会一上来就说“给我一个 xxx 架构方案”。更有效的做法，是把 AI 当成一个方案探索的架构师，让它先帮我澄清约束、展开候选方案，再围绕取舍逐轮收敛。

在这个过程中，我自己会有下面一些体会：

第一，先把场景讲清楚。 把业务场景、数据规模、约束条件、已有系统这些信息交给 AI。很多人对 AI 的输出不满意，其实根源是自己没把输入讲清楚。AI 不是算命，它没办法在信息缺失的情况下给出合理的架构建议。当然，顶级的模型会在需求不清楚的情况下进行反问。

第二，不要一开始就让 AI 给唯一答案。 如果你直接问 “我这种场景应该用什么架构？”，AI 往往会给你一个看起来挺合理、但也没什么特别的答案。更好的做法，是让它先发散出 2 到 3 套候选方案，把方案空间铺开。

第三，让 AI 主动补充开源实现和行业最佳实践。 在候选方案的基础上，让它去检索相关的开源项目、经典架构模式、行业里的公开案例。这一步非常关键，因为它能让讨论从 “我觉得” 变成 “业界是怎么做的”。

第四，围绕成本、复杂度、可维护性、扩展性等维度继续追问，让方案逐步收敛。 每一轮对话，都围绕具体的 trade-off 展开。这种方式有点像你面对一个经验丰富但并不了解你业务的外部顾问，你在和他一起把问题想清楚。

这四步走下来，你会发现 AI 在架构设计过程中承担的，已经不只是 “代码助手” 的角色，而是一个方案共创者的角色。

PART04 一个具体例子：让 AI 设计企业内部知识库的架构方案

下面用一个具体的例子来具体展示上面这四条体会。前面提到了 “企业内部知识库应该怎么建？”这个 case，我就拿这个问题来模拟示范。

这个例子并不是想证明这个知识库的架构方案有多好，只是想让大家对 Claude Code 配合 opus4.7 在架构设计上有什么能力有一个感性的认识。

这是我在描述原始需求（对应体会一：先把场景讲清楚）：

这里我刻意没有把信息一次讲满，想看 AI 会不会主动追问。它果然没有马上给架构方案，而是先判断“信息不够”，并把问题拆成几类会真正影响架构走向的决策：核心场景是 AI 问答、统一搜索，还是完整 Wiki 平台；原有 Confluence 和企微文档是替代、并存，还是单向同步；权限模型是按部门、密级，还是更细粒度；LLM 是本地部署，还是调用企业级 API。

后续几轮里，它继续用选择题推动问题收敛。比如，先确认核心场景更接近 AI 问答 / RAG，再确认存量文档暂时采用单向同步，然后继续确认 LLM 可以调用企业级 API，审计合规需要完整日志、回答溯源、敏感访问审批和审计报告。这其实已经不是普通的需求补充，而是在帮人识别架构设计的关键分叉点。

几轮反问和需求澄清之后，AI 并不是直接进入“写方案”，而是先整理出一份需求规格，作为后续架构设计的输入。它会把前面的回答归纳成核心形态、数据规模、权限身份、功能模块、风险点和待补充边界，同时把 SLA、可用性、预算、交付时间、移动端、企微集成深度这些还没定清楚的问题标出来。

接下来是关键一步：我没有直接问 “应该用哪个方案”，而是主动要求它给出多个候选，方便做权衡（对应体会二：不要一开始就让 AI 给唯一答案）：

AI 先抛出了几个比较维度，告诉我这些方案应该从哪些角度去权衡（对应体会四：围绕成本、复杂度、可维护性等维度收敛）。这几个维度包括：底座是 Fork 现成平台还是自研库，数据平面是否独立，检索是一线架构还是多线架构，前端到底是沿用平台 UI 还是完全自研门户。

下面是其中一个候选方案的具体设计和优缺点分析。需要说明的是，这里并不是在推荐这个方案，而是想展示 AI 能把一个候选方案拆到什么粒度：架构草图、核心选型、优缺点、团队工作量、典型风险，都会被放到同一个讨论框架里。

在更完整的对话里，AI 在每个候选方案里都主动参考了对应的开源实现和行业案例（也就是体会三），让讨论从 “我觉得” 真正变成 “业界是怎么做的”。这里为了不让例子太冗长，就不再展开了。

最后，它并没有简单说 “选 A” 或者 “选 B”，而是给出了一条条件化的决策路径：如果 PDF、表格、扫描件占比很高，更适合偏向深度 Fork 的方案；如果文档主体是 Confluence 原生富文本或 Markdown，更适合把精力放在数据平面和编排层；如果团队前后端能力成熟、周期也充足，自研方案才更有意义。

到这里，这个虚拟案例就可以结束了。回头看整轮对话，我自己只是做了需求的输入，但 AI 已经把场景澄清、方案空间、关键取舍和风险点基本摊开了。一份完整度不低的架构初稿已经摆在面前，而且里面不少取舍，是我凭自己经验未必能第一时间想到的。

结尾：真正变化的，不只是编码效率

写到这里，其实我想表达的判断已经比较清晰了。

很多人到今天为止，还把 AI 当成一个 “更智能的代码补全工具”。但从我最近一段时间的实践看，AI 真正开始改变的，不只是编码效率，也包括研发流程中更靠前的方案设计环节。

从需求澄清，到技术选型，到架构设计，到方案比较，这些过去非常依赖 “有经验的架构师” 的环节，现在已经可以由人和 AI 一起来完成。而且在很多我自己并不精通的领域，AI 的参与甚至可以让方案质量更高。

某种意义上，未来真正拉开差距的，未必是谁让 AI 多写了几行代码，而是谁更早学会让 AI 进入需求澄清和架构设计。

以上是我最近的一些观察和体会，一家之言，仅供参考。如果你也在尝试让 AI 进入架构设计环节，或者在这个过程中有不一样的体会，欢迎扫码进群和我交流。