从一个按钮开始，建立软件工程的总地图。
项目与协作、文件与 Excel、订单与支付
软件系统是一组共同完成产品目标的程序、数据和运行资源。
先看到全貌，后续遇到 React、API、Redis、Docker 等概念时才能知道它们的位置。
本章位于整门课的入口，负责建立后续所有知识的坐标系。
用户、客户端、前端、网络、后端、数据、基础设施和运维。
任何真实产品都可以沿着“操作—请求—业务—数据—运行环境”向下拆解。
用户看到的是产品表面，系统内部由多层能力共同支撑。
先看用户动作和业务风险，再理解技术为什么出现，以及它会怎样改变页面、状态和流程。
项目经理打开项目列表，筛选负责人并下载某个项目的合同附件。
页面需要拿到项目数据、成员权限和附件地址；其中任何一层缺失，页面都只能展示假数据或静态内容。
浏览器运行前端，后端提供项目 API，数据库保存项目记录，对象存储保存合同，云服务器承载这些程序。
设计项目列表时同步标注数据来源、权限差异、附件状态、加载失败和空状态。
最外层是客户端，包括网页、App、桌面端和小程序。客户端负责接收用户操作、展示信息，并通过网络访问后端。
后端负责业务规则和数据处理，数据库保存长期数据，缓存、文件存储和消息系统承担专门能力。服务器、容器和云平台让这些程序持续运行。
看到一张页面时，继续追问：数据从哪里来？操作会改变什么？失败发生在哪一层？
项目管理工具的项目列表由前端渲染，列表数据来自项目 API，项目记录保存在数据库，附件放在对象存储，系统运行在云服务器上。
一次简单交互会穿过多个技术层，并最终形成可持久保存的数据。
先看用户动作和业务风险，再理解技术为什么出现，以及它会怎样改变页面、状态和流程。
用户填写名称、负责人和日期后点击提交。
重复提交、权限不足、名称冲突、网络超时和数据库失败都可能让结果与页面提示不一致。
前端校验并发送请求，后端检查权限和业务规则，数据库写入成功后返回新项目，前端再更新列表。
需要设计提交中、创建成功、字段错误、名称冲突、无权限和结果未知等状态。
前端先读取表单状态并检查必填项，随后把结构化数据放进 HTTP 请求。后端接收请求，确认身份和权限，再执行创建项目的业务逻辑。
数据库写入成功后，后端返回新项目数据。前端收到响应，关闭弹窗、刷新列表并展示成功提示。任何一步失败，都需要对应的错误状态和恢复方式。
Loading、Success、Error、No Permission 都对应真实系统状态，不只是视觉变体。
创建过程中按钮进入 Loading；接口返回 403 时展示无权限；返回 409 时提示名称冲突；返回 201 时进入新项目详情。
页面能显示、应用能交互、系统能持续处理业务，这三种完成度不同。
先看用户动作和业务风险，再理解技术为什么出现，以及它会怎样改变页面、状态和流程。
团队拿到 AI 生成的项目管理页面，按钮能点、弹窗能开，但刷新后刚创建的数据全部消失。
交互只发生在浏览器内，没有真实 API、数据库、权限和错误恢复，无法持续承载业务。
把静态页面接入动态状态、后端接口和持久化数据，并补齐登录、权限、日志和部署。
验收时分开检查视觉结果、交互结果、真实数据和系统异常，不用“能点”替代“能用”。
静态页面主要展示固定内容；动态前端会根据状态、路由和接口数据改变界面；完整系统还包含后端、数据库、权限、文件、日志和部署。
AI 很容易生成一张可见页面。要让它变成长期运行的业务产品，还需要明确数据模型、接口、业务规则、异常流程和工程环境。
评估 AI 生成结果时，分别检查视觉完成度、交互完成度和系统完成度。
演示页面可以模拟交互；真实产品需要数据持久化、权限、错误处理和部署环境。
角色分工来自系统层级和专业复杂度。
先看用户动作和业务风险，再理解技术为什么出现，以及它会怎样改变页面、状态和流程。
运营上传十万行客户数据，希望看到进度、错误行和最终导入结果。
产品规则、界面状态、接口、异步任务、数据校验、测试和线上监控缺一项，都可能造成数据丢失或用户误判。
产品定义规则，设计整理流程与状态，前后端实现，QA 覆盖边界，DevOps/SRE 保障任务稳定运行。
设计稿中要把排队、处理中、部分成功、失败、错误报告和重新执行完整交付。
产品经理定义目标与业务规则，设计师组织用户体验，前端实现客户端，后端实现业务和数据，测试负责验证，DevOps 与 SRE 负责交付和稳定运行。
同一个功能会经过多个角色。设计师定义上传体验，前端实现文件选择与进度，后端生成上传凭证，对象存储保存文件，测试覆盖失败和重试，运维监控容量与错误。
设计交付越接近真实系统状态，跨角色沟通成本越低。
先看边界，再看箭头，最后看数据存储和外部依赖。
先看用户动作和业务风险，再理解技术为什么出现，以及它会怎样改变页面、状态和流程。
用户从订单页发起支付，支付平台完成扣款后通知商城更新订单。
图中可能同时出现客户端、网关、订单服务、支付服务、数据库和第三方支付，工具名很多，容易失去业务主线。
从用户入口沿箭头追踪：创建支付单、调用第三方、接收回调、更新订单、发送通知，再标记数据落点与系统边界。
先把每条箭头翻译成用户动作和状态变化，再判断页面要展示“待支付、处理中、成功、异常”。
架构图中的方框通常代表客户端、服务、数据库或外部系统；箭头代表调用或数据流；分组边框代表网络、团队或业务边界。
阅读时从用户入口开始，沿箭头找到请求经过的组件，再观察哪些模块保存数据、哪些属于第三方、哪些存在多个实例。不要从工具名称开始背。
先把复杂架构图翻译成用户任务，再逐层补上技术名称。
看到 Client → Gateway → Order Service → PostgreSQL，可以翻译为：客户端通过统一入口调用订单能力，订单数据保存在关系型数据库。
选择一个你熟悉的产品功能，用七个节点画出：用户操作、前端状态、请求、后端业务、数据库、响应、界面更新。