Controlled Agent UI

In a conversation-first AI product, the visual block is only the last mile. The harder problem is deciding whether a business question should land as text, one block, or a workspace, and making that decision stay stable under messy real-world input.

在一个以对话为主的 AI 产品里，视觉 block 只是最后一公里。更难的问题是：真实业务问题到底该落成一句文字、一个 block，还是一个 workspace，以及这个判断如何在复杂输入下依然稳定可信。

Before 过去 The core output was screens, flows, and components. 核心产出主要是 screen、flow 和 component。

What does the page look like?
页面长什么样？
What information should appear above the fold?
首屏应该放什么信息？
How should states, actions, and hierarchy be arranged?
状态、操作和层级怎么安排？

Now 现在 The work expands into system judgement and response control. 工作内容扩展到了系统判断与回应控制。

Should this question be text, a block, or a workspace?
这句话该回文字、block，还是 workspace？
What is the trust boundary between model output and UI?
模型输出和 UI 之间的信任边界在哪里？
Which rules belong in planner, recipe, skill, and eval?
哪些规则应该沉淀到 planner、recipe、skill 和 eval 里？

The core shift

最核心的转变

The goal was not to let AI generate interfaces freely. The goal was to make AI choose the right interface in a controlled, domain-aware way. That is where UX starts becoming system design.

目标不是让 AI 自由生成界面，而是让 AI 在业务场景里做受控的界面选择。也正是在这里，UX 设计开始转化为系统设计。

It shows how I translate UX judgement into system rules. 它体现了我如何把 UX 判断翻译成系统规则。

I would include this project not because it shipped a famous screen, but because it shows my understanding of how the designer's role changes in AI products: beyond visual output, into system behaviour, reasoning boundaries, rendering control, skill structure, and reusable rules.

我会把这个项目放进作品集，不是因为它落地了一个“有名页面”，而是因为它体现了我对 AI 产品里设计师角色变化的理解：设计师不只产出视觉结果，也开始设计系统行为、推理边界、渲染控制、skill 结构和可复用规则。

System chain 整体链路

One business question becomes one controlled UI response.

一句业务问题，最后变成一个受控的 UI 回复。

What made this project interesting was that every step carried a different design responsibility: intent parsing, response-form selection, protocol constraint, and final rendering. The core judgement is encoded upstream: planner routes the turn, the model outputs protocol instead of UI, and renderer plus density keep the final surface controlled.

这条链路有意思的地方在于，每一步都承载着不同的设计责任：意图解析、回应形态选择、协议约束，以及最终渲染。真正关键的判断被前移到了上游：planner 负责路由，模型输出协议而不是界面，renderer 和 density 共同保证最终结果可控。

User asks a business question

用户提出业务问题

For example: “Walk me through this week's operation first, then check East-China cost and Nova's budget tolerance.”

例如：“先过一遍这周整体经营，再看看华东成本和诺瓦预算容忍度。”

Planner classifies the turn

Planner 判断这一轮的类型

It decides whether this turn deserves plain text, a single block, or a larger workspace.

它先判断这一轮该回纯文字、单个 block，还是更大的 workspace。

ResponsePlan is produced

输出 ResponsePlan

The system chooses mode, tool, workspace update pattern, presentation recipe, and density.

系统会确定 mode、tool、workspace 更新方式、展示 recipe 与信息密度。

Tool returns structured protocol data

Tool 返回结构化协议数据

Tool schema constrains the model so it returns allowed UI data instead of arbitrary visual markup.

Tool schema 约束模型只能返回允许的 UI 数据，而不是任意控制视觉层。

Renderer maps protocol to fixed blocks

Renderer 把协议翻译成固定 block

The presentation layer applies recipe and density, but the visual surface remains under product control.

表现层会根据 recipe 和 density 调整气质，但视觉表面仍然在产品控制之内。

ResponsePlan fields ResponsePlan 的关键字段 The planner turns product judgement into structured parameters. Planner 把产品判断翻译成结构化参数。

This is also where the main design rules live: response form is chosen before rendering, the trust boundary stays in protocol, and presentation depth is controlled through explicit fields rather than ad-hoc prompting.

这也是核心设计规则真正落下来的地方：回应形态在渲染前就被选定，信任边界被锁在协议层，展示深度则通过明确字段控制，而不是靠临时提示词。

mode text / single-block / workspace 文字 / 单 block / workspace

Decides the response form.

决定最终的回应形态。

tool Choose the business view 选择业务视图

Such as audit, trend, risk sandbox, vendor snapshot.

如审核、趋势、风险沙盘、供应商快照等。

workspaceMode replace / merge replace / merge

Controls whether this is a fresh workbench or a follow-up update.

决定是新建工作台，还是追问时局部更新。

recipeId Presentation tone 展示气质

Like boss brief, audit form, trend monitor, sandbox.

例如老板简报、审核单、趋势监控、沙盘实验。

density Scan or deep dive 扫一眼还是详细展开

Controls information depth without changing the protocol contract.

在不改变协议的前提下控制信息展开程度。

Technical evidence 技术证据

The work was also encoded as reusable skills, prompts, and evaluation logic.

这份设计工作，也被沉淀成了可复用的 skill、prompt 和评估逻辑。

To me, this is what makes the project feel technical: the design rules did not stay in slides. They were translated into reusable skill structure, preflight checks, variant grammars, and eval habits.

我觉得这里最有“技术感”的地方，是这些设计规则没有停留在文档里，而是进一步被翻译成可复用的 skill 结构、前置检查、变体语法和 eval 习惯。

Planner document Planner 文档 The routing rules were written down as an actual playbook. 路由规则被写成了一份真正的 playbook。

It records how one business question should be classified into text, single block, or workspace, and which structured fields must be decided before rendering.

它把一条业务问题该如何被判断为 text、single block 或 workspace，以及渲染前必须先定下哪些结构化字段，真正写进了文档。

Recipe document Recipe 文档 Visual tone was controlled through recipes, not ad-hoc styling. 视觉气质通过 recipe 控制，而不是临时拼样式。

Instead of asking the model to improvise UI, the document defines what each response tone should feel like, such as executive brief, audit sheet, trend monitor, or scenario lab.

不是让模型临场决定 UI 长什么样，而是先定义不同回应气质该长成什么样，比如 executive brief、audit sheet、trend monitor、scenario lab。

Example sets Example 集合 Positive and negative examples were collected for evaluation. 为了评估，也整理了正反例话术。

The point was not only to polish UI, but to verify whether the planner could route real business phrasing into the right form, tool, and level of detail.

重点不只是把 UI 做漂亮，而是验证 planner 能不能把真实业务话术分到正确的形式、工具和信息密度上。

planner-playbook.mdplanner-playbook.md presentation-recipes.mdpresentation-recipes.md examples-positive.mdexamples-positive.md examples-negative.mdexamples-negative.md

planner-playbook.md planner-playbook.md This document defines the planner's decision fields. 这份文档定义了 planner 要判断的字段。

It is closer to a routing guide than a visual spec.

它更像一份路由规则文档，而不是传统视觉规范。

mode: text / single-block / workspace
tool: choose the business view
workspaceMode: replace or merge
recipeId: response tone
density: scan or deep dive

presentation-recipes.md presentation-recipes.md Recipes control presentation mood without exposing raw style knobs. recipe 用来控制呈现气质，而不是直接暴露样式旋钮。

The same protocol can be rendered with different tones depending on task intent.

同一套协议，在不同任务意图下可以呈现成不同气质。

- executive-brief
- audit-sheet
- trend-monitor
- scenario-lab

examples-positive.md examples-positive.md Positive examples anchor the kinds of requests the planner should handle well. 正例用来锚定 planner 应该处理好的请求类型。

They are written in natural business phrasing, not in system language.

它们用的是真实业务话术，而不是系统术语。

- "这周整体经营先过一遍，再看看华东成本和诺瓦预算容忍度"
- "先给我老板摘要，再展开华东成本"
- "把 4 月预算偏差最大的供应商拉出来，给我一张审核卡"

examples-negative.md examples-negative.md Negative examples define what should stay as text or be rejected. 反例用来定义哪些请求应该保持文字回应，或直接被拦下。

This is where trust boundary and response discipline become explicit.

这也是信任边界和回应纪律被写清楚的地方。

- "直接按你的理解做个 dashboard"
- "把所有数据都塞进一张卡里"
- "随便给我一个好看的总览卡片"

Design workflow 推荐工作流

My workflow starts with task patterns, not with components.

我的工作流会从任务模式开始，而不是先画组件。

Once the design object shifts upstream, the sequence also changes: list tasks first, then define response form, then test planner and only afterward inspect the UI.

当设计对象前移之后，工作顺序也会跟着变：先列任务，再定义回应形态，再测试 planner，最后才是看 UI。

Step 01 步骤 01 List real business tasks first 先列真实业务任务

Audit
审核
Trend monitoring
趋势监控
Risk simulation
风险推演
Record verification / boss summary
档案核对 / 老板摘要

Step 02 步骤 02 Define the ideal block for each task 为每类任务定义理想 block

What must be visible above the fold
首屏重点是什么
What fields are required
哪些字段必须出现
What should never be added for fake completeness
哪些内容不该为了“完整”而硬补

Step 03 步骤 03 Collect real user phrasing and test planner 收集真实话术并测试 planner

Feed positive / negative examples
补充正反例
Run planner evaluation before visual review
在看 UI 前先跑 planner eval
Only then verify recipe differences in the actual UI
再去确认 recipe 在视觉上是否真的有差异

What designers design changes in the AI era.

AI 时代，设计师设计的对象变了。