同一个界面，相隔六天
PillDoc 药局选址把首尔的诊所开业候选地和药局开设候选地按百分制评分标在地图上，无需登录即可打开。到七月底，功能其实已经全部跑通了。
下面两张是同一个标签页（药局开设候选）。前一张是 7 月 31 日，后一张是刚才重新打开的同一个界面。这期间没有新增任何功能，连列表里的候选和名次都一样。变的是界面要求使用者做多少事。
| 7 月 31 日 | 现在 | |
|---|---|---|
| 工具栏控件 | 两个下拉框、两个勾选框、一个按钮、一个下拉框，共六个平铺一行 | 三个菜单按钮，关着也在按钮里写着当前值 |
| 选择底图 | 写着「基本地图」的下拉框 | 从四张预览图中选一张 |
| 计算时刻与数据量 | 标签旁常驻「计算 07-30 16:12 · 医院 19,911 · 药局 5,903」 | 列表底部两个信息图标 |
| 标记怎么读 | 地图下方常驻两行 | 图例一行加一个信息图标 |
| 既有设施开关 | 工具栏里两个开关，图例里另外单列各类别件数 | 没有开关。合并成图例内八个类别勾选框 |
| 候选详情 | 右栏一次摊开六块收益估算和处方来源表 | 地图上的弹窗，分三个标签页 |
原则一 —— 使用者不熟悉 IT 时，熟悉比好看更对
用这个界面的是药师。他们每天用地图应用，却从没想过地图控件该长什么样。对这样的人来说，一个精心重新设计的控件，恰恰因为它是新设计的而显得陌生。
所以参照对象定为韩国人用得最多的地图——네이버 지도（Naver 地图）。它选底图时不用文字问你，而是在同一个位置放上地图的小图片让你挑。读文字、再在脑中想象那张地图长什么样，这一步被整个省掉了。
药局选址也改成了这种方式。基本地图、详细地图、Kakao、卫星四种各配一张小图。这些图不是裁下来的真实地图瓦片，而是手绘的矢量图：保存并再分发地图服务的瓦片是服务条款禁止的，而多开四个预览地图实例会让加载变慢，而这个界面本来就是为配置不高的电脑调过的。所以画的不是「那张地图的真实样子」，而是「能区分性格的图」——选择需要的只有这个。
从熟悉中照搬的是位置和方式，不是图片
照搬的不是 Naver 的图本身，而是两件事：控件放在界面的哪里，以及用什么来做选择。
这两点使用者已经在别的服务里学完了，照搬过来学习成本就是零。反过来，在这里发挥独创性，使用者就得为你的界面再学一次。先问清楚这些人愿不愿意付这个成本。药师不愿意。
原则二 —— 不要罗列要归组，归了组也得在关着时说出当前值
7 月 31 日的工具栏上平铺着六个控件：自治区下拉、行政洞下拉、既有医院勾选、既有药局勾选、地点分析按钮、底图下拉。
问题不在数量。问题在于，想知道「现在看的是什么」得把六个全扫一遍。把下拉框排开，界面的当前状态就散落在这些控件之间。
归组后剩三个：地区、地点分析、底图。关键不是数量少了，而是关着的按钮写着自己的当前值。地区按钮上写着「首尔全域」或者「江南区驿三洞」，不打开就能读到。没有这个条件，归组就只是把信息藏起来。
决定哪些不归组同样重要。医院选址／药局选址的标签页原样留在外面——这个界面有两种模式这件事本身就是第一信息，收起来就会有使用者始终不知道有药局选址。相反，两个既有设施勾选框干脆移出工具栏，放进地图上的图例里：颜色的含义和开关这个颜色的开关应该在同一处，而这个位置图例本来就占着。
所以归组有三条规则。相关的放进同一个按钮后面；这个按钮关着也要显示当前值；告诉使用者这个界面有什么的控件，不要归组。
原则三 —— 不要全部摊开，按需再取出
7 月 31 日的界面把知道的全写在了屏幕上。计算时刻和载入条数常驻标签旁；地图下方两行常驻着「变淡＝另一个标签页的候选」「标记大小＝候选看分数，既有医院看类别」「地图右键＝该点即时分析」。右侧详情栏里，预计处方流入、月调剂营收、月 OTC 净利、转让费参考、合理月租、来源集中度、实际来源处方一次全摊开。
这些信息都没错。问题是它们不会同时被需要。第一次进来的人想知道标记是什么意思；用熟了的人则觉得这段说明每次都在啃食地图高度。一个界面要同时面对这两种人。
于是常驻文字被挪到了信息图标后面。是挪走，不是删掉，这个区别很重要——把依据抹掉，使用者就失去了验证估算值的手段。现在按图例旁的图标会出现标记读法，列表底部两个图标回答计算时刻和用了哪些数据。界面安静了，依据还在。
同样的原则也用在术语上。7 月 31 日的界面上有一行「来源集中度 HHI 0.847」。HHI 是衡量市场集中度的统计指标，而这个界面的读者是药师。读一遍理解不了的词，就不放在界面正文里。现在这类术语进了说明内部，并用禁用词清单做成测试，防止它们再漏回正文——这不是人每次靠眼睛都能抓住的错误。
原则四 —— 全部条目共有的事实归标题，不归条目
列表里装着四十个候选，有三件事对四十个全都成立：这是什么的候选、从哪个范围里选出来的、最多显示多少个。把这三件事写在每一项上，同一句话就重复四十次。重复的话不再是信息而变成背景——但它仍然占着位置和视线。读不到，成本却还在。
所以这三件事由标题一行承担：「医院开业候选 · 首尔全域 · Top 40」。每一项只写彼此不同的部分——名次、洞名、地址、分数、推荐科目。
计算时刻也因为同样的理由换了位置。7 月 31 日「计算 07-30 16:12 · 医院 19,911 · 药局 5,903」贴在界面最上方标签旁边。可这个新鲜度描述的不是整个界面，而是正下方列表里的分数。现在它降到那个列表的底部，变成一句话加一个图标。把事实放在它所描述的东西旁边，就不必另外说明它指的是什么。不需要做新组件，也不需要重排版面——这是降低认知负荷最便宜的办法。
还有附带收获。标题一旦负责说明范围，地区按钮就会共用生成那句话的同一个函数，于是「标题和按钮说着不同范围」这种事故在结构上被堵死了。整理显示，顺带把状态管理也整理了。
这为什么是氛围编程的问题
这个界面的代码不是人一行行敲出来的。相当一部分由 AI 写成，所以功能上得很快。按需求衡量，7 月 31 日的界面已经算完成：候选按分数排序、可以缩小地区范围、可以打开详情、可以分析任意地点。规格书上写的，全都有。
规格书上没有的，是 UI/UX 判断。六个要不要并成三个，底图用文字选还是用图选，标记说明常驻还是收进图标，全部条目共有的事实是每项都重复一遍还是在标题里说一次。这些不会从「帮我实现」里长出来。
需求没写的时候，AI 会给出最常见的形态：控件按顺序排开，手上有的数据全印到界面上。不是因为这样错，而是因为这是最安全的默认值——永远不会因为遗漏而被扣分的那一个。
所以氛围编程越快，越需要 UI/UX 概念。当「写不出代码」不再是瓶颈，剩下的瓶颈就是决定什么该收起、什么该留下的那个人。这个界面也是别的开发者做的，最后单独辅导的只有上面四点。这四点花了六天。
拿去对照你正在做的界面的四行
一、做同样事情的控件，在你的使用者每天打开的应用里已经有了吗？有就先照搬它的位置和方式。独创性是下一个问题。
二、一行里的控件超过四个了吗？超过就归组。但归组后的按钮必须在关着时显示当前值。做不到就别归，原样留着更好。
三、界面上有常驻的说明文字吗？问问使用者过了最初三十秒还会不会读它。不会，就挪到信息图标后面。不要删掉。
四、列表每一项都重复着同一个词吗？有就从项目里拿掉，提到列表标题上。
四条都不是新功能，而是摆放问题。所以这些可以交给 AI 做——但要交出去，人得先知道这四条。氛围编程里人必须亲手抓住的，恰恰就是这个位置。
自己去看看
这个界面无需登录即可打开。在 https://www.pilldoc.co.kr/PharmSite 按一下右上角的「基本地图」按钮，原则一和原则二会同时出现。列表底部的两个图标和图例旁的那个图标是原则三，列表标题是原则四。
界面上所有金额和件数都是模型估算值。真要用于开业决策，需要另行到现场核实。