设计和工程是同一种技能,只是材料不同——Maggie Appleton(GitHub Next)

• 人类学研究什么：研究人类，招牌方法叫「参与式观察」——去跟研究对象一起生活、深度浸入。早年西方人类学家去巴布亚新几内亚、澳大利亚的传统民族中生活，发现差异不只在吃什么、住什么，连「颜色是什么」「时间是什么」的理解都完全不同。她爱这门学科，是因为自己是跟着外派家庭在海外长大的孩子（「家」算伦敦，但六岁就离开了），很早就体会到人类过日子没有固定方式。→ 详细
• 大四找工作，教授摆出的出路只有两条：读博当教授，或者进军队——军方会雇人类学家琢磨针对不同国家的人的酷刑手段。同学们的反应是「好吧，我们回去想想」。→ 详细
• 退路是从小就会的网页：90 年代长大，玩 Neopets、MySpace（她的主页「挺哥特风」），十二三岁（约 1999 年）就会写 HTML/CSS；毕业后接自由职业网页设计活、给学校做 IT 技术工作，头几年主要当插画师。→ 详细
• 第一次接触产品设计，是在布拉格一家设计+开发工作室给旧金山创业公司（早期的 Tinder、Uber）做 UI/UX 应用，她负责插画、logo 和品牌——「原来有人专门设计按钮和侧边栏」。→ 详细
• 之后在开发者教育公司 Egghead（教 JavaScript）当了四年插画师、升为艺术总监。为了画教程插画，她必须搞懂自己画的是什么——React 组件、useEffect、JavaScript 函数——「我真正的前端工程教育，就是给他们画插画」，就这样水到渠成转向了前端工程和视觉设计。→ 详细

• Elicit 的一位创始人研究语言模型已 10 年（MIT 出身、读博做机器学习），比任何人都早认定「语言模型会给科学带来革命」。产品核心是用语言模型加速科学文献综述——学者要读成千上万篇论文、把数据抄进电子表格，这对模型是「完美的用例」。她 2021 年底 / 2022 年初加入（在 Egghead 之后）。→ 详细
• 加入时团队六七个人（她可能是第七个），她从头到尾是唯一的设计师；中间有过一个 PM，走后没再招，很长一段时间没有 PM。创始人信念坚定，团建（retreat）时全员一起待好几周，「像一家人」。→ 详细
• 一个免费原型非常受欢迎，攒下大量「大家在搜什么、点什么」的数据和 A/B 测试；整整一年每周上线一个功能，「设计、开发、上线、度量」循环了两年多，让她端到端学会了产品设计——从用户需求、所处领域一路做到前端工程。强度很大，最后她想「先从创业公司退出来歇一阵」。→ 详细

• 她对「设计师做什么」的回答：流程和工程一样——定义问题（确定是对的问题吗？范围划好了吗？）、调研可能的解法并做大范围探索、比较各自取舍、做原型、验证对用户是否管用。区别只在材料。→ 详细
• 设计的材料是空间、尺寸、粗细、颜色、动效、醒目程度，还有文案——「这些措辞能不能让用户明白这个按钮会干什么」；工程的材料过去是语法，如今开发者也更多在更高一层处理架构和数据流。→ 详细
• 产品设计还要定义产品的「名词」和「动词」：球鞋商店很简单，名词就是球鞋、购物车、钱。→ 详细

• 设计 AWS 这类产品，名词就「极其难定」。她主要做科学家、开发者用的 power user（重度用户）工具，名词非常抽象：一组数据该用什么「容器」来装？怎么表达「这组数据连着那组数据」「这个函数把这份数据变成另一份」？开发者工具难，是因为它的可塑性（malleability，能变成很多种形态）太强；政府表单也难，但有约束，难的不是同一种复杂。→ 详细
• 她眼下设计的 agent 工具正卡在这里：「agent 的名词是什么？我们也不知道」——有聊天会话、有 plan、有 MCP、有 skill；能不能造一个新原语，把一串会话一路串到一个 PR，变成装下它们的新名词？每一种边界划法，都会让用户换个方式理解你的产品。→ 详细
• 名词定完还要定动词：哪些动作能作用在哪些名词上。编辑、重命名、删除是经典 CRUD（增删改查），这好办；可「能 fork（分叉复制）一个 agent 会话吗？那意味着什么？」就没人答得上来。→ 详细
• 她心中产品设计最难的部分：设计一个连贯的系统，把可能存在的全部复杂性化简成最简形态、一套真正规范的名词——让用户能「指着那个东西说，我明白它会干什么；点一个按钮，结果不会让我意外」。这话说起来容易、每次做都极难，要花时间把它硬压成最优雅的形态。→ 详细
• Gergely 的类比：这跟工程师搭新系统时在脑子里画地图没两样；他记得 Kent Beck 讲过，自己和 Ward Cunningham 面前摆着一本同义词词典，到处找合适的词给那些构造命名——后来从中诞生了「设计模式」。→ 详细

• 她的立场很硬：科技行业里的产品设计「其实就是软件设计，而软件设计就是工程，是同一种技能」。在意颜色、尺寸、阴影、形状、动效的那个人，同样得懂数据库长什么样、API 是什么样、数据有没有放在对的地方、有没有以正确方式穿过组件。→ 详细
• Gergely 在 Uber、Skype 合作过的设计师是另一种：先用 Sketch 后用 Figma，跟产品一起做探索和 UX 原型、旁听用户测试，最后交出视觉稿和动画让工程师实现，验收时说一句「这个动效感觉不对」；用户旅程门儿清，但用不着管数据库。→ 详细
• Maggie 的回应：「设计工程师」如今是个流行说法，在她看来就是真正投入工程、懂产品怎么运作的设计师。在开发者工具、AI 这种全新领域里这是必需的——「产品怎么运作，很大程度取决于后端能做到什么、数据长什么样」；做政府表单就不必懂数据库，设计师更该当「替用户说话的人」：做访谈、盯流程、看按钮够不够大、措辞对不对。→ 详细
• 她把设计看成一条往外扩的「技术栈」：后端、前端、界面、用户，再到商业语境里的产品、经济语境里的产品；每个位置都有称职的设计师（也有人只做视觉或动画），她自己偏爱「一半工程、一半设计」那一段。→ 详细

• 工具一直在变——她的工作本身就包括「搞清楚 GitHub 下一步该做什么」，团队名 GitHub Next 就是这个意思（「这名字确实起得好」）。→ 详细
• 她在用 Codex、Claude，也在 GitHub 内部 dogfooding（拿自家产品先自己用），试过 Conductor、Amp、OpenCode、pi 等各种 agentic harness（套在模型外面、让它能自主干活的执行框架）；眼下很喜欢 Codex，觉得 OpenAI 的桌面 app 设计很漂亮、「是真的想透了」。→ 详细
• 最初的头脑风暴仍用纸和笔（她带了几本笔记本来：「笔记本还没死，永远不会死」）；Figma 也还在用，因为会用，交给 agent 之前可以先在里面做点头脑风暴。→ 详细

• 原话的分量在括号里：一旦你想清楚要做什么——「这其实才是全部的工作」——就交给 agent。她强调不是说实现已被解决，而是实现已经「足够好」：「如果我把 spec（规格说明）写得足够扎实，再列清楚 agent 该怎么替我验证它真的把活干完了」，就可以交出去，只说一句："Right, let me know when you've got a PR up."（好，PR 提上来了告诉我。）→ 详细
• 「我现在基本不怎么看代码了」：评审 PR 时也只是扫一眼、扫一眼、再扫一眼——「嗯，看着挺合理。合并。」（笑）VS Code 偶尔打开，「但其实不怎么用」。→ 详细
• 工作重心因此整体前移：大部分工作都在「告诉 agent 去实现」之前，PR 评审是另一块独立的活；她的工具大多用在前面这一段。以前是先定好要做什么、再打开 IDE 真正开始实现，现在实现不再占那么大比重，「这其实挺美妙的」。→ 详细
• 读这段要带上她的语境：她在前期会做大量原型，而 GitHub Next 主要做原型、验证想法，不需要生产级质量——她自己说这是「特权」，质量门槛比往正式 github.com 发布东西的团队低得多，「那边的门槛非常高」。先摸对方向，确认好了再决定要不要做。→ 详细

• 她正在用原型验证的理论：agent 的瓶颈之一是规划，而眼下规划的体验很糟。你跟 agent 进行一场很长的对话，有时还是在 CLI（命令行界面）这种「相当原始的界面」里；agent 用一连串 A/B/C 选择题拷问你——要是用的是 Matt Pocock 的「Grill Me」skill（专门让 agent 反复追问你、把需求问透的技能），能问上一百遍。→ 详细
• 「到第 20 个问题，你已经挺累了，脑子开始宕机」。Gergely 当场认领：他自己走过一遍，被问了 36 题，问题都问得不错，但到二十几题就开始烦，「而且我完全不知道它什么时候才会停」。→ 详细
• 她把毛病拆成两层：一是人脑会累，没法在这么短时间里做这么多决定；二是大多数决定你根本没有足够信息——它只给一个问题、三个选项，还告诉你推荐 A，于是你就「行，A，A，回车，A，我同意你」。→ 详细
• 更深一层的错配：「agent 特别爱输出一大段又一大段的文字——这对 agent 是理想的输出，但对人不是理想的输入」。人要消化大量信息、真正理解、做出有依据的决策，需要的根本不是这种界面。所以她在探索一种让人更好规划、更好决策、同时更容易理解的界面，而且它得是多人协作的——「所有规划都应该是跟团队一起做的」。→ 详细

▲ 图注：她笔记本里的铅笔线框跨页，构想「和 agent 一起做规划」的界面——堆叠的卡片、可展开的面板、一列分段长条（旁注可辨 full plan、sections），右页是几种屏幕布局草图和手写备注。

• 第一条原则：这件事肯定得在 GUI（图形界面）里做，而不是 CLI；目标是给每个决策更多空间。→ 详细
• 每个决策有自己的迷你文档或卡片。简单的决策给 A/B/C 三选一就行；但当 agent 问「边框用 10%、12% 还是 15% 的灰」，她的反应是「你倒是给我看看啊，这是个视觉问题」；问架构怎么组织，就该给她看架构图、数据流图、状态机。所以她的原型让决策自带嵌入的图表、原型和 HTML——问的是什么问题，就展示做这个决策该用的那种界面。→ 详细
• 结构上：整份计划是一份大文档，里面嵌着可以展开看细节的小决策文档；而且每个决策都挂上做出决定的那个人，日后有审计记录可查。→ 详细
• 挂人的用意不是追责，而是能回溯：「我们当初为什么在后端做了这个决定？」——哦，是 Luke 大概 6 个月前定的，那就打开他的决策卡看看，「他当时手上有哪些信息」。纸上的草图就是在摸索形态：是一叠在屏幕上展开的卡片？一整条线性的东西？还是像刷 Tinder 那样滑来滑去？→ 详细

▲ 图注：她跟电影概念美术师学画时的笔记跨页——左页是蓝铅笔画的立体房屋，右页标题 ROBOTICS、Classifications & definitions，列着 Cartesian、Cylindrical、Spherical、Articulated 几种机器人构型和关节小图，正是「先懂关节，才画得出可信的机器人」。

• 插画师的世界里，你得把所有东西都画出来才知道自己要做什么——构图怎么排、东西的实体形状、一片草地的形状怎么处理；所以她很早就习惯在纸上解决问题（那批本子画于 Egghead 时期）。→ 详细
• 她在洛杉矶（「住着真是糟透了」）跟电影概念美术师学过：用 3D 形体搭建、在空间里作画，技术性强得像工程——画机器人得先懂各种关节怎么拼装，才画得让人信服；「先理解现实，才能把现实画得可信」。这套底子后来直接迁移到 UI 草图上。→ 详细
• 本子里正经和好玩的东西混在一起：有她家孩子的涂鸦，也有给 ESP32（一种带小屏幕、Wi-Fi 和蓝牙的微型芯片设备，她说 Steve Ruiz 已经把所有人都安利去买了）设计的小角色——报天气，还想接上她的 agent，提醒「额度重置前你还剩多少用量」。→ 详细

▲ 图注：笔记本里的一页，页首写着 CHARACTER——一个方盒子、屏幕当脸的小角色，画了好几种姿态，其中一个打着伞；这是她给 ESP32 小屏设备设计的角色，形状先在纸上摸出来。

• 她的对比很具体：当然可以打开 Claude Code 说「嘿 Claude，我有个想法，是一叠卡片，做成手风琴式折叠」，但拿起桌边的笔画出来「快得多、省力太多」。网上总有人说以后做什么都只要写 prompt，她不同意：「在早期阶段，你需要一种反馈很快、非常松散的东西，先摸清一个东西的形状，然后才能用语言讲清楚你想让 agent 做什么。」→ 详细
• 纸的第二个好处是「不会说没就没」：它摆在桌上，第二天一看就想起「我当时在琢磨这个功能该是什么形状」。画的也不必是视觉稿，数据图也行——它是「在想法还没变成语言之前，先把它外化出来的方式」。→ 详细
• 关键的限制在 agent 那边：它们「还是只接受文字输入」。能读图（她也会拍照传进去），但不在行，空间推理和视觉设计都「非常差」——元素周围不留间距、尺寸不对、文字叠在一起，「它们看不见」；用文字向 agent 解释一个视觉想法很难、效果也不好。→ 详细
• 所以她前期的大量设计根本不用 agent，全是在把视觉部分想清楚；等心里有数「我要的就是这个形状」，才交给 agent。Twitter 上有人声称在更早阶段就让 agent 参与了，「我持怀疑态度」。→ 详细
• Gergely 补了工程侧的对照：他见过最高效的架构讨论，都是大家面对面围着白板——组件、数据库、网络连接、重试逻辑，画成二维的方框加箭头，一个人画、另一个人接过笔加组件、画圈；在线协作白板工具火起来也是这个道理。落到实体媒介上，有一种「倒逼你想清楚动词和形状」的作用。→ 详细

• 她认为我们和 agent 打交道的界面「实在太原始了」：这件事才搞了几年（Gergely 算了下，ChatGPT 3.5 是 2022 年 11 月出的，四年）。当年她在 Elicit，团队还在讨论要不要做聊天界面，结果 OpenAI 先做了出来——「他们偷了我们的点子」（玩笑）。→ 详细
• 「软件设计是个极其年轻的领域，满打满算也就 60 年」：连人和机器之间最好的界面都没搞明白，人和 agent 之间「更是几乎还没开始摸索」。→ 详细
• 她的核心比喻：agent 活在「权重、模型、skill、MCP」的世界里，人活在「实体感、质感、光线、材料」的世界里——「要找到某种载体（artifact），让我们能在中间会合、一起创造东西，这才是真正的难题」。她不认为 agent 有意识，但它们是一种倾向于用另一套方式思考和行动的智能，两边很难互相翻译。→ 详细
• 最让她沮丧的是：agent 没法从她肩膀后面看过来、看着笔记本理解她在画什么、帮她把想法往前推。最终的梦想是它们能理解空间、光、形状和线条，「但我觉得我们离那一步还挺远」。→ 详细

• 她自嘲：每个工程师到某个阶段都会觉得自己跟实体世界脱节了，于是挑一样来投入——陶艺、烤面包、修摩托；木工最热门，因为它像工程，要大量测量、要精确。→ 详细
• 现实原因是她在伦敦买了房，老房子总要大修：要做架子、修楼梯扶手。Claude、ChatGPT 连同 YouTube、Instagram 都是不错的 DIY 教练；她零基础报了木工课，相信「还没老到学不动」，也肯定能找到很多和软件相通的地方——只是更让人满足，「你真的能摸到自己做出来的东西」。→ 详细

• Gergely 翻出她几年前的帖子：「今天特别想干脆去当个彻头彻尾的设计工程师……我就是想多碰代码，去解决屏幕上实实在在的问题，做些漂亮的动效。」之后她还专门收集过一批在做设计工程的人名。→ 详细
• 她的划界：X 上很多自称或被称为设计工程师的人，其实是非常出色的微交互设计师——按钮上很酷的悬停效果、很酷的加载过渡。这些很酷，但她不算作设计工程：大多数「直接吩咐 agent 就能做，一行代码都不用看」，本质是高阶的动效和视觉设计，「撑不起一份完整的职业」。→ 详细
• 她心中的好设计工程师：仍然是设计师，仍在意产品的名词、动词和视觉；但和工程师紧密合作、或直接参与实现和写代码，对产品的技术架构有很深的理解（不必是十足的全栈）。他们会问「既然后端数据长这个样子，界面上能做到什么」，以及「考虑到模型能做什么、产品里内置了哪些自定义 skill，我该怎么向用户解释这个产品的能力」——而不是只活在用户访谈、市场和「侧边栏用什么颜色」的世界里。→ 详细
• 她一直自己做前端，「因为这样更省事」；合作的工程师通常乐坏了——「他们讨厌写 CSS」——于是能去做更有意思、更难的活：数据同步、前端里偏后面那一层的逻辑。他们很少在乎圆角对不对，而她在乎，这种分工一直很顺。→ 详细

• 经典矛盾：设计师做了一份完美的 Figma 文件，工程师没有严格按 spec 实现。她作为一直做前端的人从没经历过——「你做的正是他们从来都不想做的那部分」；Gergely 则是过来人：好几年前，一个漂亮的渐变放在移动端「绝对会把滚动性能搞崩」，工程师只能回头问「能不能就用纯色」，还得解释性能限制、Android 低端机，以及设计师常常只沉浸在 iOS 的世界里。→ 详细
• 她不怪设计师：「我觉得这是工具的失败」——大家用的 Sketch、Figma 做出来的像素级效果图，「跟媒介本身的约束毫无关系」（媒介就是 iOS、桌面端或 Web）。做任何设计工作，都得懂你造东西用的材料。→ 详细
• 她的类比：设计桌子的人不会不知道橡木在什么环境下表现如何、松木会怎样被压出凹痕；为 Web 做设计却不懂性能、不懂应用怎么取数据、加载要多久、出现竞态条件（几个操作抢先后导致结果错乱）怎么办——结果就是「糟糕的设计方案，外加很僵的合作关系」。→ 详细
• 她寄望 agent 来弥合：设计师借 agent 跨进工程一侧，还能把它当教练和学习工具——「工程师告诉我有个我这辈子没听说过的错误状态，给我讲讲它为什么会出现，再帮我搭一个状态机」。以前的摩擦在她看来都是工具造成的；那些还放不下「我是做像素级效果图的」的设计师，「我很难想象这种合作关系将来还能顺利」。→ 详细

▲ 图注：Figma 文件「GitHub Next 2.0」的画布上，同一星座主视觉摆了好几版静态稿——楔形光束、半屏米色文字区等不同构图；这类会动的视觉在 Figma 里只能一张张画静态版，真实观感要进浏览器才知道。

• 她从不拿 Figma 做高保真效果图：本子上只能定个粗糙的形状，Figma 的用处是把细节定准——「到底什么颜色，对比度才刚好把注意力引到这个元素上？这段文字多大字号读起来才顺？」→ 详细
• 为什么不往高保真走：她主要为 Web 做设计，「在浏览器里一切看起来都不一样」——字体渲染、响应式、断点设在哪儿都会改变观感。所以她总是很早就搬进浏览器：Figma 做到中等保真、把形态定下来，然后进原型里真正微调、打磨。→ 详细
• 有了 agent 之后的流程：让 agent 对着 Figma 稿「把这些全给我弄进去」，然后再让它做一个 jig。jig 是木工词，指你专门做的一个小装置（夹具），帮你把某一道特定工序做准。→ 详细
• 放到设计上就是：在实时运行的原型上，告诉 agent「这些是我拿不准的变量」——标题字号、这几个颜色、动画曲线——「给我滑块、取色器」；然后她实时去调，等数值在活的版本里调到刚刚好，再把它们定为正式的值，「这样快得多」。她的总结：「这就像是按需给自己造一个 Figma。」→ 详细

• GitHub Next 有意和大组织保持一点距离：「我们本来就该是待在一边、做些奇奇怪怪东西的 R&D 团队」，然后努力说服组织里的其他人「我们是对的、该照我们的思路去做」——那是另一套政治问题。她和 GitHub 正式的设计团队接触不多。→ 详细
• 主站设计师的约束完全不同：要守住质量标准、维护一个庞大的设计系统和一个老旧的 Ruby on Rails 应用；面对几百万甚至几千万习惯了固定模式的客户，他们有关键工作流要跑，「你不能挪动他们的按钮」，在 .com 上改任何东西都牵扯一堆政治。→ 详细
• 她所在的小组：她和另一位设计工程师偏设计，其余全是非常资深、「什么都见过」的工程师。工作方式和工程师没多大区别——一样提 PR、用同样的工具和材料，区别只在各自关心应用的哪部分：她关心界面，工程师搭档关心后端和数据流。→ 详细

• 以前的罪：在 Figma 里吭哧吭哧做精细的可点击原型（因为比真在网页上搭复杂东西快），拿去做用户访谈，里面「一切都是假的」——用户想点一个你压根没连到假页面的东西，「整件事显得有点不真诚」。→ 详细
• 就算真做了原型，也没时间做好看，用户常被丑陋的界面分心、困惑，而你心里想的是「我们只有几天，做完就得接着做下一个」。现在完全没这个问题了：她能做出看起来相当精致的东西——但不是 agent 自己做的，「要做出一个我认为过得去的界面，它们需要大量的指引」。→ 详细
• 她的「过夜还原」做法：先在 Figma 里做好相当高保真的稿，然后对 agent 说——「这是 Figma 文件。goal mode（目标模式：给定终点让它自己循环干到达成）。用 Playwright（浏览器自动化工具）截图，要是跟 Figma 不一样就接着改，一直循环到一模一样为止」。它最后真能做到；跑一整晚，第二天早上界面基本就是按她定的规格做出来的。→ 详细
• 这类活在她眼里完全是体力活——「又要做一个侧边栏了，把 React 组件拿过来」。Gergely 补一句：原型反正要扔，不必在乎代码质量和技术债，验证成功了再正经做。→ 详细

▲ 图注：现场录屏——她在 Codex 桌面应用里输入「make me a slider for controlling the animation variations on the constellation experiment」，右侧预览是 GitHub Next 新官网的星座图实验页，节点标着 GitHub Copilot、GitHub Spark、Agentic Workflows、Ace 等团队项目。

• 她说现在「做原型完全是另一种玩法」，可以做野心大得多的东西；jig 让她体会到 malleable software（可塑软件：软件你想让它变成什么样就变成什么样）的味道——「我不再受限于 Figma 现有的那些工具」。→ 详细
• 例子是给新版 GitHub Next 网站做的首页（团队想更方便、更频繁地发布研究）：一个会旋转的动态星座，每颗星是团队这些年做过的项目。流程是先在本子上画草图，再做一堆 jig 去调——背景什么颜色、星图转多快、星星身上的物理效果（「物理部分我一点都不用懂」）、悬停时放大多少、往下滚进入正式页面的滚动效果——「所有这些，我一行代码都没写」。→ 详细
• 怎么让 agent 造 jig：就一句「给我做个滑块，用来控制星座实验里的动画变量」。你只需想清楚「我需要从哪些方面去调，才能把它调对」；她还有一个自己的 skill，让 agent 按她摸索出来、确认管用的偏好把这些控件做得像样。调着调着想到「上面加一层淡淡的颗粒感」，跟 agent 说一声就行，「很多时候感觉就像魔法」。→ 详细
• 现场演示（这个 jig 是用 Dialkit 搭的）：动画速度、强度（给星星施加多大的引力）、星星之间差异多大、往下滚时停住的高度和 logo 尺寸、表面玻璃效果——太亮了底下的字看不清，太弱又几乎看不出是玻璃，得找一个「恰到好处的中间点」。Gergely 的评价：「你还真没开玩笑，这简直就是你的私人 Figma。」→ 详细
• 为什么非得这样：这种东西在 Figma 里做静态稿「真的很难，我做过」——灰背景、多少颗粒、要不要波浪、是不是一半露出屏幕外，这些都能在稿子上摆弄，但「不在浏览器里真正跑起来，你是找不到感觉的」——用起来什么感觉、要滚动多少。她现在只要设计视觉上的东西就这么干：「有实时可调的变量就容易太多了——这是以前做不到的」；过去理论上也能手写，但「光是把东西本身写出来就已经够慢了」。→ 详细

▲ 图注：agent 造好的 jig——星座图页面右侧多出「Constellation surface」调参面板，分 Animation（Speed、Intensity、Variation）、Sizing And Scroll（Resting Height、Resting Logo Size 等）、Glass（Surface Opacity、Blur）三组滑块，左栏是 agent 的工作日志；这就是本节说的看着作品、直接上手调。

• 她把 jig 归到 Bret Victor（既是工程师也是设计师）那一脉：他在 2010–2013 年前后的一系列演讲里，有一场叫《Stop Drawing Dead Fish》（别再画死鱼），批评编程不是「实时」的媒介——在编辑器里改变量、跑完构建、再去浏览器看效果，两者之间没有直接连接。→ 详细
• 他的核心主张是：你要时时刻刻有即时、直接的反馈，能看着正在做的东西直接上手调。以前没有任何编程系统能对每个变量实时预览，最接近的只有浏览器里的 DevTools；「现在我们终于做得到了」。→ 详细

• Gergely 引用一位叫 Amir 的工程师：「作为工程师，我会让 Claude Design 生成 20 个高保真备选，不断迭代到得出一个完美的设计，很享受，而且比跟设计团队打交道快多了。」他说这类「还需要设计师吗」的论调一直都有——工程师也问还要不要 PM，PM 也问还要不要工程师。→ 详细
• Maggie 的回答分场景：手边没有设计师、只想验证一个产品或证明一个假设、又需要个界面时，让模型出 20 个高保真设计「挺好的」；简单的东西（一个按钮加一个侧边栏）也没问题。但这终究取决于品味——她一眼就会看出「这些明显是 AI 生成的」，也不确定它们能不能完成该完成的任务。→ 详细
• 真正需要设计师的时刻：你在做某种新的原语、要摸清它该长成什么样。那时需要「有一个人专门负责把问题好好想透，把脑力活干了：做实验，拿给用户看，弄清楚大家到底哪些能看懂、哪些看不懂」——这才是设计师该进来干的活。她也坦白：模型给她做的设计，「我一看就觉得质量太差了，太糟糕了」。→ 详细

• 她的判断：模型像是被灌输过一些「通用设计原则」，却不懂细微差别和上下文，执行起来又太死板——最典型的是 agent 总想给界面上每样东西都加一个文字标签。→ 详细
• 例子：关闭侧边栏通常用一个图标按钮，因为大多数人早被训练出来了，试着点一下就知道它是干嘛的；agent 却会在右上角写上「关闭侧边栏」「关闭弹窗」，甚至在一个按钮上面放四行说明文字。「我明白，在模型的脑子里，它想的是这样能让界面对人类更好理解，但实际上这是非常糟糕的设计。」→ 详细

• 「AI 的理想 UI 长什么样」这个大问题她认为短期内找不到答案，但很多好界面的原则没变：展示数据的形式还是仪表盘、侧边栏、文档这些。→ 详细
• Elicit 的故事：科学家从论文里提取数据，原本就在 Excel 里干——一张大表，每行一篇论文，每项数据填进单元格。团队刚起步时觉得「这也太老派了」，于是试遍各种疯狂方案：卡片铺满的无限画布、线性堆叠的卡片、像 Notion 那样界面丰富的可组合文档。结果每一场用户访谈里用户都说「这太让人困惑了，我能不能就要一张表格？」——每次都是。→ 详细
• 折腾几个月后的结论：「AI 的新 UI 是……一张表格」（笑）。至少在他们的用例里，用户原本在用的界面就是最好的，因为最熟悉、认知负荷最小。她不后悔「走这一趟」，但提醒大家别以为 AI 的 UI 会和现在的想象截然不同——能做更强大的事、有很大杠杆，但她预计最终还是用文档、侧边栏、卡片、表格这些「早已摸索出来、确实管用、大家也都会用」的经典形式搭起来。→ 详细
• Gergely 补充：学任何新 UI 范式都有认知负担，大家还在用操作系统、Google Sheets、Excel；就像教爸妈、爷爷奶奶用手机，学会就好了——「可你真的还想再来一遍吗？」她答：「不想。」→ 详细
• 正确的做法是「从熟悉的原语出发，再往外扩」：聊天机器人不是最终形态，看 Codex——有聊天窗口，但旁边还有 git worktree（同一仓库同时开多个工作副本）、批注、调试等一整套界面；Elicit 也一样，表格还是那个表格，只是往表格里面和周围塞进了很多东西。→ 详细

• 这是她自创的说法（capability gaslighting，煤气灯效应原指让人怀疑自己判断的心理操纵），和 Ethan Mollick 的「锯齿状前沿」（jagged frontier）基本是一回事，只是她想出来时还没读过他的东西。底层事实是：模型在某些事上好得不得了，在另一些事上差得不行，而你很难预测一个具体任务会落在哪一边。→ 详细
• 「煤气灯」的感受来自她早期使用：模型先在某个任务上让你惊艳，让你相信它能力超强；换件事一试就失败——「我感觉你在对我搞煤气灯操纵，让我以为你是个超级聪明的 agent，结果你摔了个大跟头」。更隐蔽的是，有时它已经失败了，她却没完全意识到错得多离谱，因为心里还揣着「可你是前沿模型啊，Opus 绝不可能真的在这上面出错——可它明明一天到晚都在出错」。→ 详细
• 和跟人合作完全不同：一个真正的专家表现忽高忽低非常少见，要是他突然把专业知识全忘光，你会问「你是不是精神崩溃了」；可模型每天都这样——今天做得很好的任务，明天可能就搞砸，原因可能是 prompt 换了写法、手头上下文不一样，或者输出本身就是随机的。所以跟它们合作很难，「你永远说不准会得到什么」。→ 详细
• Gergely：模型确实在进步，但你还是得保持怀疑。Maggie 补充：前沿模型有个基本盘，不会低于某个水平；但模型一直在变，大家常抱怨升级到新模型后「它擅长的东西就变了」，或在某些事上达不到预期——还是很难预测。→ 详细

▲ 图注：本节题目出自她这场演讲的标题页——One Developer, Two Dozen Agents, Zero Alignment / Why we Need Collaborative AI Engineering，页脚写着 Maggie Appleton、AI Engineer Conference, London、April 2026；右侧一个人形图标，四周散落着一圈应用图标。

• 这是 GitHub Next 已经集中攻了一年多的问题，也是她那场演讲《One Developer, Two Dozen Agents, Zero Alignment》（一个开发者、二十几个 agent、零对齐）的主题。出发点是一个现实：大家都在自己机器上、在本地跟 agent 干活，每个人单独跟 agent 待在一起可以跑得飞快，可软件从来都是团队造的——你总得跟产品经理、设计师、其他工程师对齐「大家各自在做什么决定」，而我们没有趁手的工具。→ 详细
• 现有工具管不到最要紧的那一段：有 Slack，有 Linear、GitHub Issues 管 issue，但「在你写下一个 issue 之前，还有大量前期规划」——因为写 issue 时你已经准备交给 agent 了，在那之前得先就做法达成一致：该不该做这个功能？形态对不对？接口对不对？要不要做数据库迁移？这段前期工作几乎没有好工具，有 agent 参与的就更少。→ 详细
• 最大的空白：「我们有了 agentic coding 工具，但没有一个是实时多人协作的」——所有会话都是私有的，往往在你本机上，根本没法分享给别人。现在开始有变化：Jack Dorsey 的 Buzz，以及 GitHub Next 自己做的原型 ACE，都在往「类似 Slack 的界面里共享算力、共享沙箱，一边写代码一边聊天」的方向走。→ 详细
• 但她认为就算有了带 agent 的 Slack 式界面，问题仍「完全没有解决」——你还需要让大家达成一致的工具。她在推的主张是：「决策」需要变成一等原语（first-class primitive，产品里被正式建模、可以被指着操作的基本对象）。agent 把一个决策摆到人面前时：它在屏幕上得足够显眼、带足信息；可能需要团队里另一个人来帮忙定或至少给意见；得有人为这个决策负责；要留下记录——「这些是我们定下来的事，这些是要喂给 agent 的上下文」；然后写出一组清晰的 issue 或 spec 交出去实现，另一头再做验证检查。→ 详细
• 为什么现在对齐变得这么要命：「在过去的世界里，实现要花很长时间，你可以边做边调整；可现在有了一个交给 agent 的硬交接点，你们就必须在前期全部对齐」——而眼下谁都做不到。她说连自己团队也一直有这种感觉：大家各自在自己机器上跑，很难在「我们在做什么」这件事上保持一致。→ 详细

• ACE 是她加入 GitHub Next（不到一年）以来的主项目：基本就是「Slack 加上云端算力」，沙箱用 microVM（轻量虚拟机），还能开 PR、审代码，是一个一体化的多人协作工作空间。原型很有用，但对同一时间只有三四个人的小团队来说「野心太大」，做成真正的产品不可行。→ 详细
• 退而求其次，把其中的部分拆出来交付给 GitHub 其他地方：沙箱已经成了 GitHub 桌面应用的一部分；这个原型也让领导层更认真对待「多人协作」，在找别的途径把它做进产品。→ 详细
• Gergely 拿 Ramp 做对照（同批 238 就是 Ramp CPO 的演讲）：Ramp 自建的 coding agent 叫 Inspect，跑在 Slack 里，也有 Chrome 插件和网页界面，而且是强制协作——没法把任何东西设成私有。产品经理、设计师都能在 Slack 频道里跟它对话，任何人都能加入任何会话、输入 prompt、改变方向。起初他们担心隐私，后来发现「大家都挺文明的」，根本不成问题，反而因此传播得更好、形成了反馈回路。→ 详细
• 它在 Ramp 好用，是因为 agent 接进了他们所有内部系统，云端机器是一台功能完备的开发机（类似云端开发环境），工作量很大。Gergely 的判断：给一家公司量身定做可行，做成通用方案难得多——这就是「只挠自己的痒」和「做出对那么多人都管用的东西」的区别。Maggie 补充：Slack 推出了面向开发者体验的一整套东西，Buzz 也在往这个方向走，「显然很多人都意识到这是个问题了」。→ 详细

• 团队的职能是「跑到产品前面去」：产品团队清楚接下来半年到一年该做什么，Next 想的是 GitHub 能来一次什么样的大胆豪赌、什么更冒险、遥远的未来长什么样。ACE 全套做下来太重，现在他们收缩范围，挑能给领导层指方向的部分做原型。→ 详细
• 当下的开放研究问题是怎么做出不招人烦的主动型 agent（proactive agent，不等你开口、自己在后台干活的 agent）：假设智能免费或便宜到无所谓，你能同时跑 100 个后台 agent——用什么方式消化它们的产出，才最不让人应接不暇、最不烦人？agent 和人一起在一份文档里工作、在后台做修改时，怎样才不让人觉得被侵扰、被打断？→ 详细
• 做法是把这类设计问题做成原型，攒成研究——等哪天 GitHub 想往这个方向做，就能拿出来说「这是我们做过的全部研究」。→ 详细

• Gergely 引用开发者 Jorge Manrubia 的文章《Oh my craft》：「随着模型进步，在小事上亲自介入的必要性正在迅速衰减；当模型有能力自己处理细节时，在细节上花太多时间就开始显得是在浪费人的注意力。」作者已经好几个月没亲手写过一行代码——可他以前是泡在代码里、每个细节都看在眼里的，而「手艺」恰恰意味着守在细节里。→ 详细
• 他追问：总有「好好好，这个你来定吧」的诱惑——刚才做滑块时就是这样，那个无关紧要，「但它也可能是要紧的」。→ 详细
• Maggie 先撇清：她不算真正意义上的工程师，「并不怎么在乎代码整不整洁」；但她在乎设计，而 agent「绝对还做不到我要求的设计水准」——她得深度参与，才能让观感和手感达到自己做的样子，所以常常有点恼火地亲自下场：「不行，这个过渡动画太糟糕了，应该这么做。」→ 详细

• 她一直在尝试写设计类 skill，把自己的偏好原原本本告诉 agent。这些偏好并不普适——比如边框和元素之间留多少 padding（内边距），不是人人认同、也不适合每个产品——但对她来说是有固定规则的：「就是这么多 padding、这种边框、这种边框阴影，挺标准的」。→ 详细
• 问题是规则写下来了，agent 却不能在所有地方正确应用，结果不管用。她最后总得亲自去改一些具体数值——比如边框上某个透明度——「你会觉得到了今天，这些早该被自动化掉了」，毕竟大家都在说 agent 正在接管一切，这对它们本该是小菜一碟。→ 详细
• 但她又反问自己：要是明天一觉醒来那个 skill 突然好使了、agent 完全照她的规格做设计，「我会不会觉得，最好玩的那部分没了？一个精美的界面出现在我面前，可我什么都没为它做，这会让人满足吗？我不确定。」→ 详细
• 她拿室内设计类比：Gergely 夫妇装修新家时在 Pinterest 上收集图给室内设计师看，那时除了截图没别的工具；而现在 Pinterest 上很多是 AI 生成的——房间美得不得了，但一看「这个肯定是 AI」。对实体空间这是个大问题：光线可能不真实，现实中根本不存在这个房间，「所以它对我的室内设计几乎毫无意义」。→ 详细

• AI 做出的界面客观上都挺漂亮——训练数据就是网上所有我们点过赞的东西。但假如所有 agent 都能分毫不差地做出当下流行的 Linear、Vercel 美学（极简、干净、大片白、一点圆角），这种风格就会变成「你只是用 agent 做的设计」的露馅信号，人们会转向别的做法；想显得与众不同，就得有真人去做点新的东西。→ 详细
• 她的设计观：设计有普适的基本功（字够不够大、元素周围空间够不够），但「很大一部分是时尚」——现在流行像 Linear，像 MySpace 就不流行了（前些年也流行过）；10 年后还像 Linear 就会显得非常过时。模型未必理解设计处在一个一直在变的文化语境里，同一种风格会向人传递不同的信号。→ 详细
• 例子：Claude 有一套很好认的设计语言——奶油色背景、略微偏红的文字、到处是眉题小字（标题上方那行小标签）。人一看就知道「嗯，这是 Claude 生成的，没有任何人参与过」，「那我都不知道自己还要不要费劲去看它」。你选的美学会向看的人传达信息，一看就是 agent 做的东西，大家可能会「想都不想就拒之门外」。→ 详细
• 文字同理。Gergely 说自己读写都多（读大量小说），AI 写的东西一读就不对劲——那种重复感、那堆形容词；但他也怀疑只有专家看得出，而专家永远是少数。→ 详细
• Maggie 也是写作者：读到一丁点那种味道的句子，就「直接关掉标签页」。回头读一本 50 年前写的非虚构书，光开头就让人耳目一新——完全没有「如果这样，那么那样」「不是 X，而是 Y」的句式，「就像呼吸到了原汁原味的人类文字」，以至于「任何 agent 硬凑出来的东西我都读不下去了」。→ 详细

• 她的定义：「它就是博客，只不过附带了一些额外的规则」——每一篇都不必是完成品，只要向读者清楚标明它还没写完；文章随时间慢慢生长，带一个「更新于」日期。她用园艺比喻给文章分三个成熟阶段：幼苗（seedling）、抽芽（budding）、常青（evergreen）——想了一半的东西先标成幼苗发出来，之后再回来写完或改好。→ 详细
• 这套规则是她对抗完美主义的解药：当然希望有些东西是最好、最精致的作品，但篇篇如此「完全不现实，真那样的话我什么都发不出来」。花园大约 2020 年开始，她写的比大多数人网站上的博客都多——「说实话，有些篇只有三段那么长」。→ 详细
• 长文也能这么写：读到一半会碰到「草稿进行中」的标记，往下都是要点列表或「这里应该讲讲 X」之类的粗糙笔记。有一篇她三年前开始写，每有空闲就回去再写完一段、把草稿标记往下挪一挪——相当于公开地工作，让读者看到一点「车库门后面」的样子。→ 详细
• 她认为这件事成立的关键是你和读者之间的约定：只要说清楚「这些是我还没写完的粗糙笔记」，而不是宣称「这是我最好的完成之作」，读者就会以正确的心态去读。→ 详细

• 出处：2024 年柏林 Local-First（本地优先）大会上她的演讲《家常软件与赤脚开发者》。「家常软件」一词来自 Robin Sloan，指你为自己和家人做的软件，就像给家里人做一顿家常饭——他给家人做了个互发小视频留言的 app，不放在别人的服务器上、不用付钱、不归哪家大公司管。「更多的软件本就应该是这样」：不必是 App Store 上 2.99 美元的东西，也不必拿数据去换。→ 详细
• 她当年预测语言模型会让这类软件爆发（那时还没有 agent），「现在当然已经完全成真了」：人人都在做自己的菜谱管理、家务 app、健身 app，把软件做成自己想要的样子，而不用下载千篇一律的标准版。→ 详细
• 她往外延伸出「赤脚开发者」：概念源自毛泽东时代中国的「赤脚医生」——从农村挑选农民做基础医疗培训（打疫苗、打抗生素），再派回村里，项目极其成功。开发者这个职业昂贵、门槛高，可很多人只需要一点小软件：给社区菜园、给自己住的那条街管日程、管库存，Google Sheets 又不够用；过去只能凑钱买个凑合的软件、或拿数据去换。现在社区里那个 power user（过去会用 Notion、Airtable 的那种人）用 agent 就能做出来，花不了多少 token；「他们不用读代码。只要东西能用——只要他们验证过——就没问题」。→ 详细
• Gergely 想起 90 年代中后期的网管（webmaster）：power user 型的管理员，管学校的 Windows 系统、运营公司网页、打补丁，收入不高，有志愿的也有拿工资的，在网管论坛上互相帮忙——那是一场草根运动，不像赤脚医生是政府项目。→ 详细
• Maggie 说这件事需要再来一遍，但这些人需要更多支持和工具。现在一大批 vibe coder（不看代码、只凭跟 AI 对话做应用的人）只会跟 agent 说「给我做个能干 X 的 iOS app」，却不懂工程——安全地基问题一大堆、数据处理不对，「迟早有一天会把数据库弄丢」。→ 详细
• 她的药方是本地优先（local-first）框架：数据放在本地、在几台设备之间同步，根本不需要云端数据库；数据归自己所有，别人买不走、交易不了、也访问不到（一点「数据主权」）。框架要把好的安全性、好的数据持久化这些扎实原则预先落实，上层再配好用的界面原语，让赤脚开发者轻松构建——「下一代 Airtable 也许就会是这个样子，这是我所希望的」。→ 详细

• 她主张设计师别怕参与工程，反过来也一样：设计师可以让 Codex、Claude、Copilot「给我讲讲后端——不用讲细节，讲讲它的轮廓」；开发者也可以问 agent「好的侧边栏有哪些原则」「我有个博客，教我点排版」。你等于有了一位非常有耐心的家教，会告诉你什么时候该调行高、一行具体放多少个字符。→ 详细
• 以前学这些很难，得待在设计团队里——尤其是怎么做用户访谈、怎么做可用性测试这类产品设计功夫，除了几本书外面基本找不到。现在可以直接说「这是我手上的数据，给我出几个能呈现它的界面点子」；agent 在这种概念层面「还挺不错」，哪怕界面本身不一定做对。→ 详细

• 人类学对她像一副可以戴上的眼镜：像人类学家那样看，就会去想「这次互动、这个情境、这个问题里，有哪些没说出口的文化规则在起作用」。哪怕你做的是数据库，用户也身处某种文化语境——怎么判断一个东西值得信任、一件事值不值得花时间、一个流程该怎么走，都有被文化框定的预设，也取决于你的受众有多国际化。→ 详细
• 例子：有些文化里时间从右往左、或从上往下流，而西方默认从左往右；有些文化给颜色分类的方式不同，会把蓝和绿看成同一种颜色。不一定能直接用在界面上，但关键是明白人类解读一件事的方式非常多样——甚至可以通过你做的工具，教人换一种方式看世界。→ 详细
• Gergely 顺势提议：AI 让写代码变容易了，工程师越能承担业务的其他部分、越有同理心越有价值——不如像人类学家那样把自己嵌到客户当中，「去当一回客户」，就像 Amazon 讲的「客户至上」。→ 详细
• Maggie 接着说：某种意义上工程师马上要有更多空闲时间，可以往设计拓展，而越过界面再往前就是用户研究——彻底搞懂你在为之构建的领域、人们在什么真实场景里用它（在工厂里？在地铁上？什么时候掏出你的 app？），以及那个关键时刻：一个人伸手去拿你的产品而不是别的产品时，「他们在什么时候认定你就是对的解决方案」。→ 详细

• 《Addiction by Design: Machine Gambling in Las Vegas》（Natasha Dow Schüll 著；中文直译「为成瘾而设计：拉斯维加斯的机器赌博」）：她最喜欢、送给最多人的一本，大学时读的。作者是人类学家，既生活在沉迷赌博机的人中间、写他们的亲身经历，也写设计这些机器的人——怎么设计出一台让人能连坐 12 小时的机器？赌场为什么都没有窗户（让你坐在机器前感觉不到时间）？这本书把文化人类学、参与式观察和机器设计与工程混在一起，读完你会想到手机、想到 Instagram，「稍微反思一下，我们到底在给人们造些什么样的系统」。→ 详细

• 他觉得这期最有意思的一点是：Maggie 每天在为 agentic 工具的未来做原型，设计流程却从纸和笔开始——理由是「agent 看不见，但我们人类看得见」。他追问自己这是否只适用于视觉类的东西：回想他和工程师最高效的头脑风暴，也总是在白板前画系统和组件。→ 详细
• 另一个超酷的技巧是「自己造一个 Figma」：用 AI 生成带滑块的原型，拖动就能调参数、改设计——现场的星座动画演示里，类似 Figma 的工具几分钟就为你现造出来。→ 详细
• 他欣赏 Maggie 对手艺的坦诚：agent 让她更快，但如果 agent 直接吐出完美设计，她未必喜欢。这正是他对代码的感受——把代码写好曾是他喜欢也擅长的事，现在代码不是他写的，「感觉更像一种交易」，跟创造本身少了联结。→ 详细
• 他的收获：设计上 agent 还没到那一步，Maggie 也并不想放下心里的那个设计师；开发者或许也该备一个笔记本，把想法画成草图——不只是 UI，还有架构和系统——至少能少一点「离不开 agent」的感觉，给自己留出一块没有 AI 的空间。→ 详细

片中没有口播联系方式；以下链接来自 The Pragmatic Engineer 节目页的引用清单。

• Maggie Appleton：个人网站（即她的数字花园）https://maggieappleton.com · X https://x.com/Mappletons · LinkedIn https://www.linkedin.com/in/maggieappleton
• 片中提到的她的两场演讲 / 文章：《One Developer, Two Dozen Agents, Zero Alignment》https://maggieappleton.com/zero-alignment ·《Home-Cooked Software and Barefoot Developers》https://maggieappleton.com/home-cooked-software
• 片中提到的其他资源：Matt Pocock 的「Grill Me」skill https://www.aihero.dev/skills-grill-me · 搭 jig 用的 Dialkit https://github.com/joshpuckett/dialkit · Bret Victor 的网站 https://worrydream.com · Robin Sloan 的网站 https://www.robinsloan.com · Jorge Manrubia《Oh my craft》https://www.linkedin.com/pulse/oh-my-craft-jorge-manrubia-etm8e · Ramp 为何自建 coding agent Inspect（Pragmatic Engineer 深度文章）https://newsletter.pragmaticengineer.com/p/why-ramp-built-inspect · Elicit https://elicit.com · GitHub Next https://githubnext.com