When we started working on seenzus, one suggestion came up again and again: make the home screen a device overview. Give every device a card, then put its switch, temperature, energy use, and other states on that card. In this article, a “wall of switches” means a home screen made mainly from those device cards and controls.
The idea is easy to understand. Open the product and you can see what is connected and where to operate it. The product does not need to guess what you want. It displays the state and carries out the command. We took the idea seriously.
We decided against it for a more basic reason than visual preference. seenzus is a Smart Space Agent, not a device dashboard. A device dashboard waits for someone to inspect devices and issue commands. seenzus also uses the structure of the space, current device state, operation history, and memory to decide whether anything needs the user’s involvement.
A device overview does not reduce the decisions a user has to make
A device dashboard has a clear job: show device state and accept operations. The user still decides which device to inspect, whether a state is normal, and whether anything should happen next.
This is simple enough with a small number of devices. As the list grows, the interface can group devices by room or type, move common controls to the top, and collapse the rest. That makes devices easier to find. It does not change the process. The user still reads the state first and then decides whether to act.
There is nothing wrong with that. A control panel is supposed to provide complete, predictable control. But if seenzus puts the full device list on its home screen, adding AI features beside it will not change what people do every day. They will still inspect devices one by one.
We do not want that to be the default way to use seenzus.
A Smart Space Agent should decide whether the user needs to be involved
A Smart Space Agent works with more than a natural language command. It needs to know which rooms and devices exist, what those devices are doing now, what happened recently, and which preferences have been confirmed. Without that context, a change in device state says very little about what should happen next.
Even with that context, the Agent should not show every change. It has to decide whether the state is ordinary or worth mentioning. Does anything need to happen now? If an operation is appropriate, does the user need to decide first? When the evidence is weak, seenzus should keep observing or ask about the missing detail.
The seenzus home screen is organized around that judgment, not around the number of connected devices. When nothing needs action, there is no proactive item. When the user needs to take part, seenzus can present a reminder, a suggestion, or one specific action proposal. The home screen shows the Agent’s current conclusion instead of a device list waiting to be checked.
Putting a chat box on a device page only adds another way to issue commands. The product takes on a different job when the Agent starts handling routine inspection and judgment as well.
Direct control remains available. If someone says, “Turn off the living room lights,” the target and action are clear. seenzus should carry it out without asking for the same approval again. It should ask a follow-up question only when the request is ambiguous, rather than selecting a device that happens to look plausible. People can also open the device page and operate something themselves whenever they want.
An Agent’s judgment is not permission to operate a device
Once an Agent starts filtering information, it can surface something unimportant or miss something that mattered. A proposed operation can also be wrong. We have to treat these as normal product risks, not assume that a future model will remove them all.
Memory can inform seenzus about a preference, but memory alone cannot authorize an operation. A clear request from the user can be executed. If seenzus proposes the operation, it must identify the exact action and ask for permission to perform it once. That approval applies only to the current action. It does not become standing permission for later.
Before execution, seenzus checks the device’s current state and available controls again. The operation is complete only after the device confirms success. If it can be safely reversed, the user gets an undo option. Conversations remain private to the person taking part, while operations on shared devices enter the space’s operation history so other authorized members can see what changed.
These limits add implementation work and create more cases for the interface to handle. We accept that cost. As the Agent makes more judgments, its authority over devices needs to become more precise, not less.
Restraint makes the product look less capable at first
A device dashboard can explain itself the first time it opens. More connected devices make the page look fuller. A Smart Space Agent does not have that advantage.
When seenzus first connects to a space, it can read device state and respond to clear instructions. It does not yet know how that space is normally used. Generating many suggestions would make the product easier to demo, but those suggestions would have little support and would soon become annoying.
Our current rule is to avoid prompting when the evidence is weak, ask about uncertain details, and stop showing an item after it is no longer relevant. This can make seenzus feel restrained at first. It may also leave people wondering what the Agent has been doing. We are still working on how to explain learning without turning the home screen into another feed of states and notifications.
We accept a quieter start. Unsupported suggestions would create a misleading impression of capability. The point of seenzus is to reduce routine checks and decisions over continued use, not to fill the first session with as much content as possible.
We still do not know how much judgment people will delegate
Some people prefer to inspect and operate every device themselves. That is normal. seenzus will keep direct device control and will not add another approval step after a user has already given a clear instruction.
Different spaces will also need different arrangements. A home used every day, a cafe open for regular hours, and a meeting room used occasionally will not have the same requirements for prompts, device authority, or learning. We do not have evidence that the Smart Space Agent model should be the default for every person and every space.
Our answer to the title is settled, though. A device dashboard displays devices and waits for the user to operate them. A Smart Space Agent also decides whether the user needs to be involved. seenzus is designed for the second role while keeping direct control available.
When we evaluate the home screen, we will look at one result: after more devices are connected, does the user also have to inspect more cards? If the answer is yes, seenzus is still a device dashboard. That is not the product we intend to build.
我们开始做 seenzus 时，最常听到的建议之一，是把首页做成设备总览：每台设备一张卡片，开关、温度和耗电都放在上面。下文把这种以设备卡片和控制入口为主要内容的首页叫作「开关墙」。
这种首页很好理解。打开产品就能看见接入了哪些设备，也知道去哪里操作。产品不必推测用户想做什么，只要准确显示状态、执行指令。我们当然认真考虑过。
最后没有这么做，不是因为我们不重视直接控制。原因更基本：seenzus 不是设备控制面板，而是 Smart Space Agent。设备控制面板等待用户检查设备、发出指令；seenzus 则会结合空间结构、设备状态、操作历史和记忆，判断当前是否有事情需要用户参与。
设备总览没有减少用户要做的判断
设备控制面板的职责很明确：显示设备状态，接收操作。应该检查哪台设备，一个状态是否正常，现在要不要处理，仍然由用户决定。
设备不多时，这个过程没什么负担。设备增加以后，可以按房间或类型分组，把常用设备放在前面，不常用的折叠起来。这些设计能让设备更好找，但使用流程没有变。用户还是要先查看，再判断是否需要行动。
这不是控制面板的缺点。它原本就负责提供确定、完整的控制。可如果 seenzus 也把完整设备列表放在首页，那么无论旁边再加多少 AI 功能，用户每天做的仍然是逐项检查设备。
我们不想把逐项检查设为使用 seenzus 的默认方式。
Smart Space Agent 要先判断是否需要用户参与
Smart Space Agent 处理的不只是一句自然语言指令。它还要知道一个空间有哪些区域和设备、设备现在是什么状态、最近发生过什么，以及哪些使用偏好已经得到确认。缺少这些信息，Agent 很难判断一项变化对当前空间意味着什么。
有了这些信息，也不该把所有变化都展示出来。Agent 要先判断：这是正常状态，还是用户应该知道的事？现在需要处理吗？如果要操作设备，是否需要用户决定？依据不够时，seenzus 应该继续观察，或者把不确定的地方问清楚。
所以 seenzus 的首页不按设备数量组织。没有事情需要处理，就不显示主动事项；需要用户参与时，再出现相应的提醒、建议或一个具体的操作提议。首页展示的是 Agent 当前的判断，不是等待用户逐项检查的设备清单。
在设备页加一个聊天框，只是多了一种发指令的方式。产品只有开始承担日常检查和判断，职责才不同于设备控制界面。
直接控制仍然保留。用户说「关闭客厅的灯」，目标和动作都很清楚，seenzus 就应该执行，不必再问一次。指令有歧义时才需要追问，不能自行挑一个看起来合理的设备。用户也可以随时进入设备页面亲自操作。
Agent 的判断不能直接变成设备操作权限
Agent 一旦开始筛选信息，就有可能把不重要的事情提出来，也可能漏掉本来应该提醒的事。主动提出设备操作时，它还可能建议一个不合适的动作。产品设计必须把这些错误当作正常风险，而不是假设以后能把它们全部消除。
因此，seenzus 的记忆可以影响判断，却不能单独授权设备操作。用户已经明确要求的动作可以执行；如果操作由 seenzus 主动提出，就要写清具体动作，并取得这一次操作的同意。一次同意只对当前动作有效，不会变成以后持续执行的权限。
执行前，seenzus 还要重新核对设备状态和可用能力。设备确认成功后，操作才算完成；能够安全撤销的动作，应给用户一个撤销入口。对话内容只属于参与对话的用户，但对共享设备产生的操作会进入空间的操作记录，其他有权限的成员可以看到设备发生了什么。
这些限制增加了实现成本，也让交互多了几种情况。我们接受这个成本。Agent 参与的判断越多，设备权限就越不能含糊。
刚接入时保持克制，产品会显得没那么聪明
设备控制面板第一次打开就能展示全部内容，接入的设备越多，页面越充实。Smart Space Agent 没有这个优势。
刚接入一个空间时，seenzus 能读取设备状态，也能响应明确指令，但还不了解这个空间平时怎样使用。此时生成很多建议，画面会更热闹，也更容易演示。问题是这些建议没有多少依据，很快就会变成打扰。
我们现在的规则是：依据不够时不主动提示，不确定的事情先询问，已经过时的事项不再展示。这对产品演示不利，也可能让用户一开始看不出 Agent 做了什么。怎样把学习过程解释清楚，同时不把首页变成状态和通知列表，我们还在继续处理。
我们宁愿接受前期不够显眼，也不希望用大量提示制造能力很强的印象。seenzus 要减少的是长期使用中的检查和决定，不是让第一次打开时出现尽可能多的内容。
我们还不知道多数人愿意让 Agent 判断到什么程度
有人喜欢亲自查看和控制每台设备，也不希望产品替自己判断。这很正常。seenzus 会保留设备控制，也不会让已经明确的指令再经过重复批准。
不同空间的要求也不一样。长期居住的家、每天营业的咖啡馆和偶尔使用的会议室，对提示频率、设备权限和学习方式会有不同要求。我们目前没有依据说 Smart Space Agent 的默认方式适合所有人和所有空间。
但为什么 seenzus 不是又一面智能家居开关墙，我们的答案已经确定：设备控制面板展示设备，等待用户操作；Smart Space Agent 还要判断当前是否需要用户参与。seenzus 选择了后者，同时保留必要的直接控制。
以后评估首页设计时，我们会看一个结果：接入更多设备后，用户是否也必须多检查几张卡片。如果答案是肯定的，seenzus 仍然只是设备控制面板。那不是我们要做的产品。