01 / 从名词到蓝图
先把体系装进脑子
2020 年我成为 Infra 首位设计师，没有任何技术背景。日志、服务、容器、存储、中间件等等——这些技术人员习以为常的词，对我全是陌生概念，每个词都要单独想办法理解。
我的学习渠道不止一条，每条都要自己校准：上网查资料，零散、不系统；向技术同事提问，要判断信息的准确度——每个人都带着自己的理解，未必客观；纯技术的表达又听不懂，只能靠类比，再反复确认、验证。理解是搭起来的，从微观到宏观，一层都不能少：名词是原子，产品是分子，产品之间的关系是它们的连接，整个平台蓝图是拼出来的整体——而每一层都要回答同一件事：谁在用、要完成什么。
成员设计师其实不需要像我这样把整个系统装进脑子。我必须要懂，是因为我要负责团队：对内管理、培养和质量把控，对外和各技术负责人沟通，自己还要哪里缺人补哪里——这个位置要求我同时具备广度和深度。而这些理解，最终都落在具体的页面上。
02 / 页面是体系的投影
体系复杂，页面就复杂
SpaceShopee Engineering Infrastructure 建设的平台：日志、监控、Service CMDB、Server CMDB 等子产品都内置于其中，按产品线组织。 是超大规模的平台：服务交付、计算、网络、存储、观测与治理连在一起，业务研发、SRESite Reliability Engineer，站点可靠性工程师：负责服务的稳定运行、资源管理与故障处理，权限上通常覆盖业务研发的全部能力。、DBA数据库管理员：负责数据库的部署、运维与优化。、网络与服务器运维都在上面工作，权限范围各不相同——SRE 的权限理论上已包含业务研发的所有权限，业务研发也会跨多个产品工作，SRE 管的也不只是服务器。一次服务变更，可能同时涉及服务归属、部署、资源、流量、权限、工单和观测。
Space 的上百个子产品里，两个 CMDB 让「体系的投影」看得最具体：Service CMDBSpace 平台内「服务身份和交付」产品线的子产品：管理服务与资源绑定。一个开发可能负责多个子团队的 N 个服务，权限越大服务树越复杂。 的复杂在页面结构，Server CMDBTechnical Operation Centre（TOC）下管理服务器的子产品：SRE 管理海量服务器，每个筛选条件由「字段＋运算关系＋取值」三字段组合。 的复杂在查询——两个子产品，两种复杂，长在同一套体系上。具体的设计过程，写在 《从具体产品深入全局，建立工程平台的设计基础。》 里。
这套理解不便宜。最初绝大部分产品都没有专属的 TPMTechnical Product Manager，技术产品经理：负责技术类产品的需求、推进与跨团队协调，与业务产品的产品经理不同。，技术负责人就是需求方，需求常常要自己补全。先弄懂体系，意味着动手画页面前要花掉大量时间；但跳过它，后面每一次修改都在为没弄懂的部分还债。后来在 Ask，三天里把分散的需求快速拼成可运行的全貌，走的是同一条路——只是把「慢慢学」压缩成了「边碰边画」。
03 / 组织复杂度，而不是消灭它
把体系翻译成秩序
想清楚之后，设计的工作是组织复杂度，而不是消灭它：筛选要持续说明操作范围，关联信息要放在一起读，PageHeader 在滚动时收缩、把空间还给内容——每一个决定都在帮用户在复杂的体系里保持方向。
理解还要能交接。我在产品还没成型时就动手梳理全貌，把产品、用户和关系整理成一张可共享的大纲；后来三次季度汇报、两百多页材料，记录的正是这个过程——从 2020 年的产品地图，到 2021 年十三条产品线的版图。这套东西让团队共享同一张地图，而不是各自带着各自的想象工作。（原始汇报材料可在当面交流时脱敏展示）
做设计系统时，我发现这是同一件事：v4→v5 升级整理的材料，本质上也是在教相关者理解设计系统的整体机制。复杂业务系统与设计系统，是不同领域的同一个问题：先把体系装进自己的脑子，再把体系装进更多人的脑子。（这份升级材料同样可在当面交流时脱敏展示）
这些理解最后要传给下一位协作者：哪些信息要一起看，为什么拆开配置与结果。先把系统弄懂，页面才知道该怎么画；把理解写下来，接手的人才不用从头再弄懂一遍。我也试过把这些判断直接交给 AI——能写进规范的部分，装得进去；写不进去的部分，在 《我试着把自己蒸馏给 AI，只成功了一部分。》 里讲过。
相关文件涉及企业内部信息，可在面试交流中结合脱敏处理后的材料展开介绍。