系统性思维：盯住依赖、连接点和会失效的环节

从"这个按钮能用"到"整个系统能扛住"

在与 AI 协作的过程中，一个很容易养成的习惯是：每次只关注眼前正在做的那个功能。按钮能点了？好。表单能提交了？好。页面能显示了？好。然后继续做下一个功能。

这种逐个击破的方式在开发初期完全没问题。但随着项目的功能越来越多，一个微妙的变化正在发生：这些功能不再是孤立存在的，它们之间开始产生依赖。

用户点击"提交订单"这个按钮，背后可能牵动了前端表单验证、后端的业务逻辑、数据库的写入操作、支付接口的调用、邮件服务的通知……这些环节像齿轮一样咬合在一起。任何一个齿轮卡住，整个链条都会停摆。

系统性思维，就是学会看见这些齿轮之间的连接，而不只是盯着单个齿轮转不转。

什么是依赖

"依赖"这个概念在前面讲包管理器时出现过——你的项目依赖某个库才能运行。但在系统层面，依赖的含义更广。

你的前端页面依赖后端接口返回数据，才能显示内容。 你的后端接口依赖数据库正常运行，才能读写数据。 你的登录功能依赖第三方认证服务，才能验证用户身份。 你的部署流程依赖 GitHub 仓库能正常访问，才能拉取最新代码。

每一条依赖关系都是一条链——链条越长，中间任何一环断裂的可能性就越大。

连接点：最容易出问题的地方

在一个系统中，不同部分之间交接的那个地方——前端和后端之间、你的代码和第三方服务之间、本地环境和服务器环境之间——这些"连接点"往往是最容易出问题的位置。

原因很简单：在每个部分的内部，逻辑通常是自洽的。但在两个部分交接的边界，各自的假设可能并不一致。比如前端期望后端返回一个列表，但后端在数据为空时返回了 null 而不是空列表——功能在有数据时完美运行，在没有数据时就崩了。

好的架构师不需要精通每个部分的内部实现，但一定会特别关注这些连接点——数据在交接时的格式对不对？错误发生时有没有合理的处理？某个外部服务不可用时，系统会优雅地降级还是直接崩溃？

"如果……会怎样？"

培养系统性思维最简单的方法，就是经常问自己这个问题：

"如果 _____ 出了问题，会发生什么？"

• 如果用户在支付过程中网络断了，钱扣了但订单没生成怎么办？
• 如果 AI 接口突然返回错误，页面会显示空白还是会有提示？
• 如果某一天你用的第三方服务涨价了或者停止运营了，你的项目有替代方案吗？

你不需要为每一个假设都提前实现解决方案——很多情况在个人项目中发生的概率很低。但意识到这些风险的存在本身就是有价值的。它让你在设计方案时自然地留出余地，而不是把系统做得像一栋没有预留任何冗余的建筑。

让 AI 帮你看见全貌

系统性思维听起来需要丰富的工程经验，但实际上 AI 可以帮你快速建立这种视角。

你可以请 AI 帮你列出当前项目中所有的依赖关系——它依赖哪些外部服务？数据从哪里来、到哪里去？各个模块之间是怎么调用的？

你也可以拿着这张依赖关系图，逐条追问 AI："如果这个环节挂了，系统会怎样？我需要做什么来应对？"

你不需要一次性把所有问题都想清楚。但每次你问出一个"如果……会怎样"的问题，你对这个系统的理解就深了一层，你作为架构师的判断力也就强了一分。