让 AI 做一个网页，已经可以从一句话开始。
描述功能，等待生成，再告诉它哪里需要修改。一些过去需要设计师和工程师来回配合的工作，如今可以在与智能体的对话中快速推进。
但在执行之前，AI 也可能把一连串问题交还给你：布局选哪种？按钮放哪里？这几个技术方案用哪个？当它在选项旁标上“推荐 A”，你是否真的理解了其中的区别？
GitHub Next 资深研究工程师 Maggie Appleton（从事设计与原型开发）就遇到过这种情况。她的工作是制作原型，探索人与 AI 协作开发软件的新方式。一次规划任务中，智能体连续问了她 36 道题。问题并不差，但到第 20 多道时，她已经开始厌烦，而且不知道什么时候才会结束。
相比之下，把明确的设计稿交给智能体，体验就顺畅得多：让它实现、截图、对照、修改，第二天起来，界面已经基本成形。
从明确的设计稿到可用的原型，AI 正在加快这个过程。但在动手之前，想法如何理清、方案如何比较、团队如何达成共识，仍然是设计工作需要解决的问题。
在最新一期 The Pragmatic Engineer Podcast 中，Maggie 与主持人 Gergely Orosz 分享了这两种体验背后的工作方式，以及她正在探索的解决办法。以下是这场访谈的核心内容编译。
设计先要弄清楚产品怎么用
主持人提到，一位工程师分享过自己的做法：让 AI 一次生成 20 个高保真的界面方案，再不断迭代，直到找到满意的设计。他觉得这个过程很愉快，甚至比与设计团队沟通更快。
Maggie 并不否定这种用法。如果手边没有设计师，只想验证一个产品想法，需要一个按钮、一个侧边栏，让模型先做出界面完全可以。
但当产品的基本形态都还没确定时，困难就不只是选出哪张图更好看。
在 Maggie 看来，设计首先是解决问题：确认问题是否找对，范围是否清楚，探索不同方案，再做原型、找用户验证，观察他们是否理解、能否使用。
产品设计还要决定，用户面对的究竟是什么，以及可以对它做什么。
一家卖鞋的网站里，商品、购物车、付款都容易理解。开发工具就复杂得多：一组数据应该放在哪里？不同数据之间有什么关系？怎样让用户理解一次操作会带来什么变化？
到了智能体产品里，这些问题更加明显。会话、计划、技能和工具之间应该怎样组织？它们能否组合成一个更容易理解的整体？用户能不能把一次会话分成不同分支，继续探索不同方案？
这些概念的边界怎样划分，会影响用户如何理解整个产品。Maggie 认为，设计的一项难点，就是把复杂关系整理成连贯、清楚的结构，让用户知道自己面前是什么，也能预期点击之后会发生什么。
因此，当产品需要探索一种新的交互方式时，仍需要有人认真研究问题、做实验，再把方案拿给用户试。
她也发现，模型有时会机械地执行设计原则。例如，为了让界面“容易理解”，它会给每个按钮加文字，甚至在按钮旁放好几行说明。一个通常用图标就能表达的关闭操作，也被写成“关闭侧边栏”或“关闭弹窗”，页面因此堆满文字。
模型似乎知道要解释功能，却未必能判断解释到什么程度才合适。
设计质量也取决于对技术条件的理解。
Maggie 心目中的设计工程师，需要深入了解产品怎样运行：后端的数据结构允许界面做什么，数据什么时候能取回来，加载失败会发生什么，某种视觉效果是否影响性能。
她和主持人谈到过往设计与工程之间的一种摩擦：设计稿里漂亮的渐变，放到实际设备上可能拖慢滚动；静态页面上的理想效果，实现时还要面对屏幕尺寸、网络和设备性能的限制。
Maggie 把这比作家具设计。设计桌子的人需要了解木材的特性；设计软件的人，也需要理解软件运行的条件。
她希望智能体能够帮助设计师跨过这道门槛。例如，工程师指出一种没听说过的错误状态时，设计师可以请 AI 解释它为什么发生，再一起梳理不同状态之间怎样转换。这样，设计与实现之间的讨论才会更具体。
从纸上草图，到浏览器里的原型
虽然大量使用智能体，Maggie 在最早期的设计探索中，依然经常拿出笔记本。
她正在探索一种帮助团队与智能体共同规划的界面。一个决定应该是一张卡片，还是嵌在长文档里？卡片怎样展开？不同方案是上下排列，还是逐张切换？
这些问题，她会先画出来。
脑中出现一个“像一叠卡片，又能折叠展开”的想法时，当然可以试着向 Claude Code 描述。但对她而言，在纸上画几笔往往更快，也更省力。尤其在想法还没清楚到能够用语言表达时，草图可以帮助她继续思考。
画几个方框，加几条箭头，就能尝试一种布局。纸还可以留在桌上，第二天看到时，她会想起自己在探索什么，再接着往下画。
她也会把图片交给智能体。但在她的使用经验里，模型处理空间关系和视觉细节仍有不足，因此，她常常先独立想清楚大致形状，再让智能体参与实现。
随后是 Figma。她用它进一步确定颜色对比、文字尺寸和页面布局，但通常不会在静态设计稿里打磨到最终状态。
因为真正的网页还会受到字体渲染、屏幕宽度和响应式布局等因素影响。交互是否顺畅，需要滚动多少距离，也得实际操作才知道。她会尽早把设计放进浏览器，在可运行的原型上继续调整。
AI 明显加快的，正是把想法变成可操作原型的过程。
过去，用 Figma 做可点击的演示，往往要提前连接好不同页面。测试者点到没有准备的位置，演示就进行不下去。即使团队做了真正运行的网页，也可能因为时间有限，来不及改善外观，用户反而被粗糙的页面分散注意力。
现在，Maggie 能更快做出细节完整的原型。有时，她会把 Figma 文件交给智能体，让它实现页面，通过浏览器自动化工具截图，再与设计稿对照，不像就继续修改。
她说，这样的任务可以放着跑一夜，第二天起来，界面已经基本符合要求。
不过，这依然需要明确指导。她所在团队主要是探索和验证想法，原型的工程质量要求也与正式上线的产品不同。一次探索失败，原型可能直接被丢弃；方向有效，团队才会继续推进。
她尤其喜欢让 AI 为当前原型生成一套临时调节工具。
标题字号拿不准，就加滑块；颜色没定，就加取色器；动画速度不合适，就把速度变成可以实时调整的参数。她一边拖动，一边观察，找到满意的效果后，再把数值固定下来。
Maggie 借用了木工里的“jig（夹具）”来形容这类工具：为完成某项具体工作制作的辅助装置。在她的软件原型里，它就是一个按需生成的控制面板。
GitHub Next 网站的动态星图是一个具体例子。星图展示团队做过的项目，她需要调整背景颜色、旋转速度、悬停时元素放大的程度，以及向下滚动进入正文的效果。
她先画草图，再让智能体生成原型和调节工具，自己反复尝试。她说，在这个例子里，她没有亲手写代码。
这种用法很直观：一些难以用文字精确说明的视觉要求，可以先变成可操作的参数，让人亲眼看到差别，再决定最终效果。
让人做选择，先把选项讲明白
但当交互回到聊天窗口，体验就不一定如此顺畅了。
Maggie 尝试过让智能体连续提问，以便把开发计划想得更周全。它给出问题，列出 A、B、C，再标注推荐项。她一路回答了 36 道题。
这些问题有价值，但连续作答让她越来越不耐烦。更麻烦的是，她并不总有足够的信息来理解选项。
智能体问边框的灰色程度应该是 10%、12% 还是 15%，她想要的是先看到实际效果。如果讨论的是系统怎样组织，她希望看到架构图、数据流图，或者表示不同状态如何变化的图。
只给一个问题、三个选项和一个推荐答案，很难让人理解自己同意的究竟是什么。
她描述，问题不断出现后，自己开始倾向于顺着推荐项回答：“选 A，继续，同意。”
智能体在收集答案，人却未必越来越清楚。
这促使她探索另一种规划界面：给每个决定一张卡片或一份小文档，根据问题的性质，附上图片、图表、网页原型或必要说明。简单决定可以继续用选择题；复杂决定则需要更充分的展示和讨论。
这里可以借用一个相关概念：“选择架构师”。
诺贝尔经济学奖得主 Richard Thaler 与哈佛大学法学教授 Cass Sunstein 在合著的《助推》中介绍了这一概念。负责安排人们如何面对选项、作出决定的人，都在承担这样的角色。选项怎样组织、默认项如何设置、提供什么反馈，都是选择架构的一部分。
放到智能体产品中，界面设计者也在安排这种决策环境。边框颜色的选择，可以展示几个实际效果；架构方案的比较，可以配上结构图和相应的取舍。Maggie 的决策卡片探索，可以从这个角度理解：先让人看懂选择，再让人作答。
这并不意味着提问越少越好。重要问题依然值得讨论，关键是给人的信息是否足以支持判断。
她希望，这样的界面还能让团队共同参与，并记录每项决定由谁作出、当时有哪些依据。这些想法仍处在原型探索阶段，但它们指向一个很具体的产品问题：长段文字和连续选择题，未必是所有决策最合适的呈现方式。
个人做得快，团队也要跟得上
当多人各自使用智能体，这个问题就进一步变成了团队协作问题。
Maggie 曾做过一场题为“一个开发者、二十多个智能体、零共识”的演讲。她观察到，一个人与智能体配合时，可以推进得很快；但软件通常由产品经理、设计师和工程师共同完成。
这个功能要不要做？应该以什么形态出现？是否需要调整数据库？哪些限制必须考虑？团队仍然需要一起讨论。
而且，不少讨论发生在正式任务写出来之前。等一项任务已经清楚到可以交给智能体执行时，前面往往已经有大量探索和协商。
在 Maggie 看来，当时许多智能体编程工具偏重个人使用，会话留在各自的电脑和工作环境里，团队不容易知道彼此讨论过什么、作出了哪些决定。
GitHub Next 曾探索过一个叫 ACE 的原型，把类似 Slack 的交流界面与共享计算环境、共享沙盒结合起来，让团队能够一边讨论、一边开发。她也坦言，这个项目对他们的小团队而言相当有挑战。
而即使有了共同的聊天空间，也不代表大家自然就会达成共识。
她希望每项决定都有足够的信息，相关成员可以参与讨论，最后有人负责确认，并把决定及其依据记录下来。几个月后，团队想知道为什么选了某个后端方案，可以回看当时的材料，而不是重新猜测。
这种记录的目的，是帮助团队理解过去的取舍。
Maggie 认为，以前实现软件需要较长时间，团队可以在过程中不断调整。现在，当任务交给智能体后，执行会迅速推进，团队就更需要在交付任务之前确认彼此的理解。
她也把这视为自己团队正在经历的问题：每个人都在各自的机器上快速工作，保持一致并不容易。
因此，AI 编程工具还有一部分工作需要继续探索：让团队共同规划、讨论选择、确认任务，并在完成后验证结果。
写在最后
这场访谈给我们的一个具体启发，是把 AI 的用途延伸到“帮助自己看清问题”。
Maggie 可以请智能体生成一个网页，也可以请它为网页加上滑块，让自己比较不同效果；可以让它列出方案，也可以要求它先把方案画出来，再与团队讨论。
对于使用者，这是一种可以尝试的工作方法：当一句“帮我改得更好”反复得不到满意结果时，想想能否让 AI 提供一个更容易比较和修改的中间步骤。
视觉效果可以并排展示，流程可以画成图，拿不准的参数可以做成控件。这样，人就有机会在具体反馈中逐步明确要求。
AI 加快制作之后，这些探索和调整也有机会变得更方便。最终值得追求的体验，是让人既能把东西做出来，也能更清楚地知道自己为什么这样做。
文章参考资料：https://www.youtube.com/watch?v=KZSzF0KEFRg
