完整案例 · 复杂系统体验
房产系统从原技术环境迁移到国产环境，找楼、查看房屋、核对测绘变更这三件事没有变。我重排了它们的页面和入口。选幢后把楼栋属性与相关入口收进同一面板，整幢页把主要区域留给户室矩阵，测绘核对把新旧户室与面积差异并列成组。这三套页面是个人回溯重构的成果，都可以直接点开。
00 / 先看结果
在地图选中宇济一号 17 幢，右侧显示这栋楼的属性和可以继续做的事，从这里可以打开整幢房屋，或进入测绘变更核对。下面的原型使用演示数据。“幢”指一栋楼，“户室”指楼内按房号管理的房屋。
这里展示原型截图。完整原型适合在桌面浏览，可通过下方链接在新窗口打开并操作。
三个原型使用同一栋楼和同一间户室，总图按 17 幢进入，整幢页显示的仍是 17 幢，测绘核对里 1501 室也还是同一间房。
01 / 项目源头
这次改造的背景是房产系统迁移到国产技术环境（信创）。迁移会替换底层环境，工作人员的任务还是那三件，在地图上找到一栋楼，查看楼内房屋，必要时核对新旧测绘记录。我的输入是需求规格、业务流程、旧系统截图和一份初版原型，我用它们判断这三件事各自需要什么信息。
这类业务有三层对象，地图上的楼栋、楼内的户室，以及测绘记录和系统记录之间的对应关系。需求梳理阶段，我先把每层对象各自的属性、状态和操作列清楚，再决定每个页面以哪一层为主、其余信息退到次要位置。后面几节的页面结构都来自这次梳理。
02 / 问题重定义
定位时要看清楼栋在哪，查看整幢要按楼层和单元对照户室，核对变更要同时看到新旧两边的户室和面积。我先看旧界面的版面怎么分，再判断每个页面的主要区域应该留给谁。
总图的旧界面把地图工具放在顶部工具栏，选中的楼栋和可用的操作分在两个地方。选中一栋楼之后，工作人员要先确认选的是哪一栋，再决定做什么。这两件事发生在同一步，所以楼栋信息与可用入口应该落在同一块区域，地图只负责定位。
整幢页要按楼层和单元对照户室。旧界面同时保留顶部工具、左侧属性、上方平面区和下方楼盘表，户室集中在其中一块。对照发生在户室矩阵里，主要区域应该留给它，平面图和属性退到次要位置。
核对变更要把新旧测绘记录对上。这一处的旧界面截图保存在需求材料里，两组记录用两张表逐行并排，一组对应关系落在同一行的两个单元格里。判断一组对应是否成立，要同时看到两边的户室和面积差，所以它们应该并列出现。
03 / 核心方案
选幢、查看整幢、核对变更各自对应一个页面，都围绕同一栋楼组织信息。总图确定当前楼栋，整幢页按楼层和单元展开这栋楼的户室，测绘核对比对新旧记录。每页各服务一个任务，不要求按顺序办理。
选中楼栋后，右侧集中显示名称、编号、属性和相关入口。我按一个条件分配这些入口，即这个操作是否必须先有选中的楼栋。查看整幢房屋、核对测绘变更都以当前楼栋为前提，放在面板里；新建楼栋和资料入库不同，待新建的楼栋本身还没有地图图形，这两项留在全局区域。
旧系统里可以先选幢再找功能，也可以先选功能再选楼，本次按前一种组织，入口集中到面板。
面板把属性和入口放在一起，操作前可以核对这是哪一栋。
没有地图图形的楼栋也需要新建，入口不能依赖已有楼栋的选择。
查看楼内房屋与核对测绘记录是两件事，各自打开对应页面。
我把平面参考和属性收进侧栏，让矩阵默认占主要区域。楼层有两套编号，一套是建筑的实际层号，一套是业务使用的名义层号，这个对应关系沿用原有表达；各户室的业务状态色带也保留。选择一间房屋后，侧栏显示它的具体属性。
这里展示原型截图。完整原型适合在桌面浏览，可通过下方链接在新窗口打开并操作。
“实测替换预测”是测绘成果回到系统时的核对环节。测绘记录里的户室要和系统记录里的房屋对上，面积有差异的交给人工判断。我把每组对应做成关系卡，两边是户室，中间是面积差异。以 1 单元 1501 室为例，系统记录 94.20㎡、测绘记录 95.90㎡，卡片显示 +1.70㎡。
普通对应可以逐项确认。拆分、合并这类结构变化单独标出，一次普通确认不会把它们算作已处理，后续处置交回业务。需要看全部字段时切回表格。
这里展示原型截图。完整原型适合在桌面浏览，可通过下方链接在新窗口打开并操作。
04 / 行业判断
我用这三类产品检查三个决定。选中一个对象之后业务入口放在哪，地图在整个页面里承担什么，逐项核对要拆到什么粒度。参照只用来看别的产品怎样组织，具体安排仍由本案的任务和信息决定。
SuperMap 的公开方案覆盖不动产登记等业务，是我能找到的直接行业参照。我用它检查总图的分工，选中一栋楼之后，与这栋楼有关的操作应该出现在当前对象旁边。据此我把楼栋属性和相关入口放进总图右侧面板。
SuperMap 公开资料 ↗DataV Atlas 面向地理空间数据的展示与分析，是空间类产品的参照。我用它检查地图的职责范围，底图只负责找楼和选楼，选中之后的楼栋属性和业务操作交给面板，不在地图上再叠一层信息。
DataV Atlas 公开资料 ↗飞书多维表格是按记录组织状态的工作流产品，作为这类工具的参照。我用它检查核对的粒度，一次判断对应一组户室。据此实测替换用关系卡承载每组对应，确认动作仍由工作人员执行。
飞书多维表格公开资料 ↗05 / 设计取舍
参照检查的是组织方式，业务原有的信息还要在重排时逐项确认。调整展示主次会碰到三处权衡，分别是状态与选中怎样同时表达、平面参考放在哪里、核对时先看关系还是先看字段。三处都关系到信息会不会丢，下面逐条说明保留了什么。
一间房屋可以同时有多个业务状态，性质另外用符号表示。状态的相对颜色和符号含义沿用原图例，20 项状态一起保留。改动的是选中反馈，用独立描边标出当前选中的房屋，不覆盖状态色带，选择和状态可以同时看清。
要按楼层和单元逐户对照，矩阵能同时铺开一层；要确认一间房屋在楼里的位置，平面图更直观。两者都留下，平面参考收进侧栏后仍可随时打开，实际层与名义层继续分开显示。演示中实际第 18 层对应名义 17A 层，两列并排才能同时对照层序与业务名称。
关系卡用于逐组判断对应关系和面积差异，卡片上保留户室编号、两侧面积和差值，其余字段留在表格里查。两种视图对应两种核对深度。
06 / 价值与边界
三个原型把入口分配、整幢布局和关系核对落成可操作的方案。我用同一栋楼和同一间户室检查页面之间是否对应，再加入面积差异和结构变化的样例，看核对反馈说得清不清楚。
在地图选中 17 幢，进入整幢页选择 1501 室，再返回总图，看的是不是同一栋楼。这条路径可以完整走一遍，页面之间的对象对应通过操作就能检查。
旧界面截图和当前页面对应呈现，可以对照平面参考、属性和矩阵各占多少展示面积，再打开原型检查选房、查看属性的顺序。
面积差异、未关联的户室和结构变化分别呈现。结构项在未明确处置前保持待核对，原型里的确认操作也不会把它们直接放行提交。
这套原型是个人回溯重构的产物，用固定的楼栋、户室和差异样例演示，新建与资料入库只保留入口，没有连接业务系统。面积差异的判断尺度和关联建议的规则，是我在演示数据上的推演，业务上还要确认；结构变化之后由哪个环节处置，也还没有定下来。
07 / AI 协作
三个原型都由我确定页面结构、操作规则和状态含义，AI 负责读取需求与截图、生成页面代码并做一致性检查。每轮生成之后，我按原始需求逐条核对操作逻辑、状态含义和字段对应，核对通过的部分才留在原型里。
总图、整幢和测绘核对各自可以独立打开，围绕同一栋楼检查布局、对应关系和操作反馈；发现的问题回到规则或页面修改。
哪些关系在业务上成立、哪些规则仍要确认，由我判断。AI 负责实现，不替我做这些判断，也不把待确认的规则写成已定论。