“传统设计流程已死”！IDE成Claude设计负责人新宠：Anthropic人人写代码，最不怕Bug

作者 ｜ 木子

AI 冲击下，“传统设计流程已经死了”，但在Claude 的设计负责人看来，真正被淘汰的不是设计，而是设计师过去那套被奉为“教条”的流程：

“设计师一直被教的那套设计流程，我们几乎把它当成“教条”在信。现在它基本已经死了。今天做设计，你根本没有时间再去做那些精美、打磨到极致的高保真稿了。”

设计没有被 AI 取代，但设计师的工作重心，正在被彻底改写。

过去那些被反复强调的步骤，比如调研、mock、高保真稿打磨，正在快速缩水。可事实上，Claude 的设计师并没有因此清闲下来，反而更忙了：

“我看到两类设计工作正在成形

而且，焦虑也不只发生在设计师身上：

“不仅是设计师觉得要跟上工程师的节奏。我觉得工程师自己也在问：‘我们到底怎么才能跟上我们自己？’”

这位 Claude 设计负责人名叫 Jenny Wen，她在一个访谈节目中表示：

“几年前，这份工作里有 60% 到 70% 都是在做 mock（设计稿 / 界面示意图） 和原型。但现在我觉得，做 mock 的部分大概只剩 30% 到 40% 了。”

不是设计师变懒了，而是产品的节奏变了。功能在滚动上线，代码部分由模型生成，版本像是“长”出来的。当你还在精雕细琢，产品已经更新了。

在 Anthropic，会写代码已经成为设计师的“基操”。被工程师逐渐抛弃的 IDE，反而成了设计师的新工具。

Jenny Wen 还分享了自己的AI 工具栈：

日常几乎是“全套 Claude 组合拳”：用 Claude Chat 处理日常对话，用 Cowork 承担长任务和复杂流程，用 Claude Code 在 VS Code 里改代码细节，甚至在手机和 Slack 里远程 @Claude 直接改前端、提 PR，把设计和工程无缝连在一起。

她指出，在像 Anthropic 这样的 AI 公司里，产品发布时有缺点不可怕，迭代太慢才可怕：

“AI 的用例，很多时候不是你事先“设计出来”的，是你看着用户怎么用、边看边发现的。所以执行与迭代非常关键。”

那么，在这样的变化下，什么样的设计师最有竞争力？

她点出了三类人：

第一类是很强的“通才”（generalists）。不是那种“很多都懂一点”的通才，而是要在几个核心技能上都能做到接近行业 80 分位的水平，很扎实、很能打。

第二类是“深度专家”（deep specialist）。可以是非常技术向的，甚至能做到 50% 像软件工程师。也可以是视觉设计特别强的人。在一个“人人都能做出东西”的世界里，这种很深的、强工艺的能力，反而能让你做出来的东西真正有辨识度。

第三类，她称之为“craft new grad”（“工艺感型应届生 / 新人”）。这是那种职业早期的人，但给人的感觉“聪明得超出年龄”，学得快、愿意学新打法、不带太多固定仪式感和流程包袱。

对此，有网友评价道，别怕 AI 抢走工具，真正属于设计师的是判断力和想法——与其拼命守住过去的工作方式，不如相信自己的直觉，走进变化里。

还有人说得更干脆：“AI 只是让创意脱离表达壁垒，回归单纯的精神创作罢了。”

下面是这期访谈的全部重点内容，AI 前线在不改变原意的前提下进行了编辑。

设计工作的变化

主持人：我们先从一个大问题开始：AI 崛起之后，设计流程到底怎么变了？

Jenny Wen：变化非常大。而且我觉得它还会继续变很久。

过去这一年，我们看到工程的变化比设计剧烈得多。但工程一变，设计也会被迫跟着变。

几个月前，我在柏林做过一个演讲，题目叫《别再迷信设计流程》（Don’t Trust the Design Process）。我在里面讲的是：传统那套设计流程，你做研究与探索（research & discovery），然后发散与收敛（diverge / converge），大家不停地说“相信流程、相信流程”，那套东西基本已经死了。

其实在 AI 之前，它就已经在走下坡路了，但现在工程师可以同时“拉起七个 Claude”快速做功能，作为设计师，你必须放下那套流程。

甚至在我做完那个演讲后的三四个月里，我都觉得它已经有点过时了（说出来还挺尴尬）。尤其是 Opus 4.6 出来、以及很多人假期里开始重度使用 Claude Code 之后，这种被迫改变的压力只会更强、更快。

Jenny Wen：我现在看到两类设计工作正在成形。

第一类，是支持实现与落地执行（implementation & execution）。工程师用多个 Claude agent 飞快地产出功能。任何人都可以提出一个想法，往往工程师会立刻做出一个“能跑起来的粗糙版本”让你试。作为设计师，你已经没有时间再按传统方式做那些精致的高保真稿、或者用那种方式来“主导”了。

第二类，是做愿景与方向（vision & direction）。这依然非常重要，但形态已经变了。

以前我们会做两年、五年、甚至十年的设计愿景。现在更像是三到六个月。与其产出一份“讲得非常漂亮、做得非常精致的 deck”，有时候可能只是做一个原型，给大家指明方向。

在一个人人都能拉起多个 agent、随便朝任何方向做东西的世界里，你需要有东西把大家的工作拉向一致性与效率，让整体能“合到一起”，而不是各做各的。

主持人：所以，不是设计师突然想转型，而是工程迭代快到飞起；与其挡在前面审批，不如先放手让它跑，再在后面把方向、逻辑和体验一块块拼回正轨。

Jenny Wen：对，差不多就是这样。

并没有一个统一的声音在喊“设计师必须立刻改变”，更多是工程工具链变化带来的下游影响。

我也觉得接下来一年左右，设计工具也会发生很大的变化。但目前整体还是在追工程。

同时这也挺“解放”的：设计师也能用各种编码工具参与到实现里。

我现在做了很多“最后一公里”的实现工作，打磨细节、在代码里跟工程师紧密协作，把功能真正推过终点线；也会直接用代码做原型，而不是再依赖工程师来做这些。

主持人：这种变化在所有公司都会发生吗？还是主要在像 Anthropic 这种 AI 原生公司？可能有人听完会想：好吧，Anthropic、Claude 肯定在最前沿，团队也很偏开发者。但他会觉得：这不一定会发生在 Salesforce、ServiceNow 这种公司吧。

Jenny Wen：我去年在柏林的那场演讲，意外成了我做过“共鸣最大”的一场演讲，这说明整个行业里很多人都开始感受到这一点：老的设计流程用不下去了。

设计师、PM 都在用 Claude Code、还有 v0 之类的工具做原型，PM 也开始自己“拉起来”原型了，所以确实有一股趋势正在出现。

但那次演讲也有不少反弹。很多人把整个职业生涯都建立在这套稳定的设计流程上，学习它、教它、用它，他们会强烈地维护它，比如说：“没有 discovery 不行”“这些流程环节不能丢”。

所以确实也有一部分行业还没走到这个工作方式上。

快速发布 vs 深度调研

主持人：到底什么路径会带来更成功的产品和公司？一种是花时间做 discovery、用户研究、mock、迭代、beta 测试；另一种是工程师快速发布一些“还行但不完美”的东西，然后快速学习、快速迭代。你的感觉是：第二条路现在反而可能更快逼近真正好的产品吗？

Jenny Wen：我觉得你必须用判断力去决定什么时候该发。但总体来说：能快速执行、把东西做出来、用真实数据去试、以真实用户为中心去验证，这确实会带来更好的产品。

特别是我们现在做的很多东西，是基于非确定性的 AI 模型。你没法把所有状态都 mock 出来，也没法光靠理论推演。甚至你都很难做一个“可点击”的原型把所有情况覆盖掉。你必须接上真实模型，用真实用户的用法去跑，才能知道会发生什么。

而且 AI 的用例，很多时候不是你事先“设计出来”的，是你看着用户怎么用、边看边发现的。所以执行与迭代非常关键。

在 Anthropic 当设计师的一天

主持人：那在 Anthropic 做设计师到底是什么体验？能不能讲讲一天的工作是什么样？

Jenny Wen：在 Anthropic，有相当多的时间其实都花在“跟上公司里正在发生什么”上。

我也在一些规模差不多的公司工作过，当然也会信息很多、事情很多。但在这里我会更强烈地觉得：我必须跟上。

一方面是研究侧的模型进展；另一方面任何时候都有很多团队在做原型、试不同想法，各种项目代号满天飞。我经常在做的事就是：搞清楚这些项目到底是什么、各自走到哪一步，因为我想提前看到“接下来会有什么东西要找上我”。

同时公司内部也有很多原型和产品，我自己也想去试。我很好奇，想把这些东西摸一遍。

另外还有很多内部的人会写一些对行业走向的洞见与观点，有些是偏哲学层面的争论，有些是公司方向的讨论，读起来特别有意思。

在别的公司，我可能会觉得：这都不是我能影响的，离我很远，不太在意。但在这里，因为信息量和事件类型都不一样，我会特别想跟上。

Jenny Wen：除了“跟上信息流”之外，我还是会留出一些时间去想未来。

比如这周我就给自己划了一段时间：我们之前在 Co-work 上一直处于强执行模式，现在我想停下来想想：接下来三个月会怎样？在市场、模型进展的背景下，它可能会往哪里走？

把方向可视化出来，对团队对齐很有帮助，能把大家往同一个方向拉。

然后我也会花很多时间跟工程师一起“jam”，大量是对话、白板推演、看他们做出来的东西，然后给反馈，像一种“设计咨询”式的参与。

我一天里也会有一部分时间在写代码：做打磨、做实现。经常是我和工程师一起把一个东西讨论清楚，他先做出第一版，然后我进去一起把它抛光。

这个部分真的很有趣，而且说实话几个月前这还不是我工作里这么重要的一块。

传统设计还在，只是比例减少了

主持人：你还会做传统设计流程里的那些事吗？比如原型、用户研究、panel（访谈 / 小组）、你刚才描述的整套流程。

Jenny Wen：会的，我们还是在某种程度上做这些。团队里有用户研究员，会做传统研究，也会做问卷；全团队都会读那些研究和反馈。我们也还在做原型、我也还在做 mock。

只是我现在工具更多了，而且每块事情花的时间比例变了。

主持人：也就是说，以前你生活的“饼图”大概是：传统思考、规划、原型、mock、研究，再加上一些反馈与执行；现在这个饼图变了。

Jenny Wen：对。几年前我可能会说：60% 到 70% 的时间是做 mock 和原型；剩下的 20% 左右是在跟工程师一起 jam、一起咨询式配合；最后 10% 可能是协调类会议。

但现在我觉得：做 mock 的部分大概 30% 到 40%；另外 30% 到 40% 是直接跟工程师配对一起做；然后还有一块（具体占比我也说不准了）是实现，真的去做、去交付、去发布。

Jenny 的 AI 工具栈

主持人：你的 AI 工具栈是什么？

Jenny Wen：我们基本就是在 Claude 全家桶里深挖。

我当然用Claude Chat，但越来越多地用Claude Cowork。

我几乎把所有“聊天类需求”都迁到 Cowork 了，因为它更适合长任务、长流程的事情，而我以前问 Claude 的大多就是这种长任务。

然后还有Claude Code。我主要是在 VS Code 里用，因为我经常要改前端细节，能看着代码再跟 Claude 对话会很方便。

我也在尝试更多“远程使用 Claude Code”的方式，比如手机、比如 Slack。特别好玩：有人说“这个 icon 偏了”，你直接 @mention Claude，Claude 就给你改了，然后你把 PR 捡起来一看：搞定。这个体验真的很爽。

总之，我们这里基本是“全屋 Claude”。

主持人：你还在用 Figma 吗？

Jenny Wen：在用。

主持人：现在 Twitter 上有个很大的争论：设计的未来是不是 code？我们还需要 Figma 吗？还需要“设计工具”吗？你的看法是什么？

Jenny Wen：Figma 仍然重要。可能我作为前 Figmate 有点偏爱，但每次我用 Figma 都会觉得：对，我就该用这个。它依然在很关键的地方补上了缺口。

很大一部分是“探索多方案”的能力，你能快速想到八到十种不同做法。很多最好的设计，就是在你能把一堆想法扔到墙上，然后再筛选、再整理、逼着自己想更多方向的时候诞生的。

而现在这些编码类工具并不太适合做这种探索，因为它非常线性：你会在一个方向上投入很深，然后跟 Claude 反复迭代这个方向。

Figma 让你能发散去探索很多不同的选择，我觉得它还会以这种方式继续存在。

另外还有一些非常细的视觉与交互细节，也特别适合在 Figma 里试，比如字体、微交互、风格探索。把这些放在一个画布上专门对比、推敲，非常有价值。很多时候我并不想直接跳进代码来做这些。

IDE 成了设计师的新宠

主持人：有意思的是你还在用 IDE，因为在工程那边，明显正在往命令行、agent 流程迁移，IDE 好像都不“酷”了。但你这里很好理解：你只是想改点 CSS、颜色之类的，跟 agent 说“把这个 hex 改一下”反而更麻烦。

Jenny Wen：对，真的很烦。有时候你说“把这个换成那个 class”，还不如自己进去把 class 改掉。

主持人：会不会未来 IDE 反而更像是设计师和 PM 的工具，而工程师已经走到别处去了？

Jenny Wen：也许吧。

主持人：所以你大量时间是在跟工程师一起工作。 我从你的建议里总结出的一个重点是：放手。核心不是死守设计当“最后审批人”，而是让工程先跑起来。可问题是，当工程每天都在发版、迭代飞快，设计师怎么既不被甩在后面，又不把自己逼疯，还能让产品最终看起来像一个整体？

Jenny Wen：每次我和工程师一起工作，尤其是在更偏“顾问式”协作的情况下，我都会尽量解释清楚：我为什么会这样想。

目标是帮助他们提炼出背后的原则，而不是我只丢一句：“不，我觉得这里不应该放这个。”

我会换成这样表达：“我觉得这里应该有一个按钮，因为不是所有人都意识到你可以通过 prompt（提示词）触发这个功能。”然后我会给一个例子，可能来自用户研究，或者其他证据。

我会刻意把工程师带回设计系统和对应的代码规范上。因为现在很多代码是 Claude 写的，而它并不会天然遵循既有的设计模式，如果没人盯着，很容易越写越跑偏。

所以，对我来说，最重要的不是每次都亲自盯着，而是让工程师理解原则和设计系统，未来能自己判断、自己做对，而不是事事都来找我。

至于你说的“别把自己逼疯”：很难，现在真的很难。

我从工程师和设计师两边都听到同样的感受。因为我们现在能做到的事情太多了，于是就会想做更多。

所以不只是设计师在想：“我们得跟上工程师。”工程师自己也在想：“我们到底怎么才能跟上我们自己？”

在 AI 时代如何
维持工艺感、质量与信任

主持人：对设计师来说，工艺感（craft）、优秀体验、质量和信任，是这份工作的核心。理论上也会带来更成功的产品和公司。当产品一天能发布上千次、你根本跟不过来，而且似乎也没有设计师参与时，你怎么思考如何维持工艺感、质量和信任？

Jenny Wen：倒也不是完全没有设计师参与。更准确地说，是一个设计师要兜住的东西几乎太多了，多到一个人根本顾不过来。

我会重点关注的是：一个功能或产品在用户“采用周期”（adoption cycle）里处于什么阶段，相比之下，它到底还是一个很早期的预览，还是已经进入更广泛的使用。

比如，我们有时会发布一些东西，并且明确告诉大家：“这是一个 research preview（研究预览）。”它还很早期，会有缺陷，我们会把这个前提讲清楚、把预期管理好。

Claude Cowork就是个典型例子。我们把它当作“研究预览”发布，很清楚它还不完美，甚至可以说这是它目前“最差的版本”，之后只会更好。但我们还是选择上线，因为内部反复验证过它的价值，相信它已经能让一部分用户真正受益。

它可能还不是最容易上手的；可能还不是最高质量的；可能还有问题。但我们仍然放出来，是因为我们认为收益大于代价。

我觉得这样是可以的，尤其当它已经有明确价值，而且值得尽快让用户先用起来。

但你必须对用户做出的承诺是：“我们先把它放出来，但我们会持续迭代。我们会听取你的反馈，把它做得更好。”

你要对这件事做出承诺，并且要让用户看见。你必须回应反馈、展示持续改进。

因为“提前发布”最容易丢掉质量信任的一种方式就是：你先发了，然后就没下文了，这才最伤品牌。

但如果你提前发布，同时持续迭代，其实是可能在不伤害公司品牌的前提下做到的。

我觉得我们做得还不错。如果要给听众一个 takeaway（关键结论），那就是：我们会继续这么做。

而且说实话，这对我作为设计师来说也很有趣，因为你把东西放出去，立刻就能学到东西，立刻就能收到反馈，也立刻就知道下一步该做什么。

主持人：我听你描述这件事的方式是：用速度来建立信任。

Jenny Wen：对，完全是，用速度建立信任。但同时也要让用户觉得“被听见了”。要让大家清楚：我们是在根据他们想完成的事情来修、来改；他们的反馈被重视、被使用了。

主持人：这点在 Labs 团队发布东西时特别明显。你们都很擅长：大家在推特上发，团队立刻回复推文和评论，然后继续发版，“我们昨天就修了”，“这个正在推进 / 已经发生了”。给人的感觉很明确：这是今天的真实状态。我们知道它哪里坏了，我们会修。而且因为 Claude Code 写代码很快，所以修复也来得非常快。

AI 会不会拥有“品味”？

主持人：现在很多人都在问：当 AI 从补全代码进化到几乎写完整个产品、甚至能帮你想点子，人类到底还剩下什么价值？在真正的“超级智能”到来之前，我们还能在哪些地方不可替代？

Jenny Wen：我认为它（AI）会在品味、判断力和设计方面变得更强。

我也觉得，我们可能把这些东西抓得有点太紧，会说：“设计师永远知道什么才是最该发的，或者什么才是这个东西最好的版本。”

我确实认为 AI 的品味会提升。

但归根结底，总得有人来决定：到底什么会被做出来？什么才真正重要？

当人们说“AI 会替我们把软件都做了”的时候，做软件最难的部分，很多时候并不是“把它做出来”。你回想自己工作中最艰难的时刻，往往是因为你和别人对“一个功能该不该进、该怎么进”产生分歧。AI 可以参与讨论、提供建议，但它未必能替你解决你和另一个人之间的争执。

所以，“决定最终到底把什么放进我们构建的产品里”这件事，本身就是一种品味。但可能不是审美意义上的“taste”，更像是对下一步该做什么的判断。

主持人：看到 AI 这么快接管 coding，一年前，甚至两年前，大多数人都会说“不可能”，而现在最优秀的工程师已经信任它到甚至不看代码了……

这让我重新审视了很多假设，比如：“AI 永远不会像顶尖 PM 或设计师那样，判断什么是好、决定做什么。”

但我现在开始觉得它可能会做到。甚至在你描述的场景里，它可以对两个正在争论的人说：“这是你需要的全部数据。为什么这个才是正确答案。按 1，我就把它做出来。”

主持人：那你的意思是：AI 会变得更强，但我们仍然需要很厉害的设计师、很厉害的 PM、以及工程师？

Jenny Wen：对。

总得有人决定：“我们要做这种产品。”或者当 AI 提供了一堆可能性时，也需要有人对最终决策负责。

即便 Claude 能写代码，工程师仍然要对“代码是否能工作、是否符合产品逻辑”负责。

所以仍然存在这样一层决策或判断的责任。也许有一天我们不需要承担这层，但至少现在还得由我们来承担。

聊天机器人界面的未来

主持人：AI 界面设计里还有一个持续的问题：聊天机器人和终端。我觉得没人一开始会认为聊天机器人会成为 AI 的长期 UI。大家以为它只是过渡。结果现在更进一步，终端也变得重要了。你觉得我们和 AI 的交互方式会不会还有下一步？还是 chatbots 和 terminals 最终会成为主流？

Jenny Wen：我觉得很可能会是“组合形态”。

会有一些你可以点、可以交互的 UI 和界面，更具触感的体验。我们在 Claude 内部，甚至在 chatbot 里，已经看到并在尝试这种方向。

我们最近发布了一些 widgets（小组件），让 Claude 可以用交互式方式问你问题，并展示天气、股票等信息。这些反响不错，因为人们仍然喜欢看到 UI、喜欢点它、摸它、操作它，而且很多时候这比把所有东西都打字输入 Claude 更高效。

与此同时，当我们更深入地拥抱 chatbot 这种范式，它带来了一个“固定、预先写死的 UI”做不到的灵活世界。

所以我的判断是：我不觉得 chat 会消失。它打开了一种全新的方式，几乎无限多种方式，让我们与模型协作、让我们和电脑对话，这是以前没有的。

但在一些具体事情上，直接的 UI 仍然是最好的选择。而且我认为，未来会有更多 UI 是由模型生成的，而不是每次都靠人手写出来。

所以我们现在处在一个阶段：我不认为 chat，甚至可能包括“对着终端说话”会消失。

挺有意思的是：像 OpenClaw、Clawdbot、Moltbot 这些名字，它们其中一个很大的创新，其实就是提供了另一种聊天入口：WhatsApp、Telegram、短信 SMS。那是一个很大的“解锁点”：“哦，我可以直接在 WhatsApp 里跟它聊。”

而且你想，我们人类本来就一直在聊天、一直在说话。这是一种很丰富的交互方式。现在只是多了一个媒介，让我们能用它和电脑互动。

主持人：对，Kevin Weil（他在另一家 AI 实验室工作）提过一个很好的观点：对话是一种非常强的界面，几乎适用于所有层级的智能。

我们可以跟很聪明的人说话，也可以跟没那么聪明的人说话，都能沟通；它能覆盖整个智能谱系。我们甚至可以和 200 IQ 或 300 IQ 的人交流，对话依然有效。

这也是为什么它成为了一种很美的方式，能够和不断增长的模型智能一起“扩展”，而且会持续有效。

Jenny Wen：嗯，我完全理解，这很有道理。

从 Director 回到 IC

主持人：好，我想回到“管理 vs IC（个人贡献者）”这个话题。你最近又重新回到一线做 IC 了，能聊聊为什么这么选择吗？以及在你看来，设计管理者是不是也有必要下场，重新做一段时间具体工作？

Jenny Wen：对，我确实有一些看法。

过去这一年在 Anthropic，我一开始是以 IC 身份加入的。之后带团队做了几个月管理，因为组织结构需要。现在我又回到全职 IC 了。

我之所以以 IC 身份加入，是因为我对需要被完成的工作很兴奋，而且我想贴近工作本身。

同时我也觉得，在我“继续往企业阶梯往上爬”之前，这可能是个重要时机。我当时脑子里也在想：未来中层管理还安全吗？这个岗位会不会持续存在？还是我应该先下场，把手弄脏？

公平地说，我两边都喜欢：我喜欢管理人、搭建团队；我也喜欢做 IC 工作。我当时其实有点像“勉为其难的管理”：“行吧，需要我我就做。”

但今年做 IC 让我学到了很多，如果我一直做管理就学不到的技能。

今年设计流程变化太大了，我也因此补了很多硬技能，如果我只做管理，我根本没时间去发展这些能力。

如果以后我再回去做管理，我会对流程变化有更强的同理心和理解。这很重要，因为团队现在的工作方式确实变了。如果你自己不在这种方式里工作：去测试工具、尝试新方法，就很难真正共情。

如果我没在这个环境里亲身经历，我不确定我是否能完全理解它，或者是否知道该怎么带团队。这就是今年给我的收获。

从 Director 回到 IC

主持人：好，我想回到“管理 vs IC（个人贡献者）”这个话题。你最近又重新回到一线做 IC 了，能聊聊为什么这么选择吗？以及在你看来，设计管理者是不是也有必要下场，重新做一段时间具体工作？

Jenny Wen：最大的时候，大概 12 到 15 个设计师，我下面还有几位 manager。

主持人：你提到过一种感觉：中层管理可能不会长久。你现在怎么看？设计管理会长期存在吗，还是大家都会变成 IC？

Jenny Wen：只要有团队存在，有一个人来管理通常就会有帮助。

管理者确实有价值，关键在于这个角色的形状、以及他们实际在做什么。

现在一个真正有用的管理者，不再只是纯粹的人事管理：“帮你做职业发展”“做一对一”“确保你在工作中感觉良好”。这类东西相比以前，感觉没那么“成立”了。

我觉得未来的管理者，是既能为团队指明方向、也能带好人的人：既深度参与具体工作、提供清晰判断，又能营造一个让团队发挥出最佳水平的环境。

主持人：你觉得自己长期会回去做管理吗？

Jenny Wen：我大概率会。我很喜欢帮助团队把产品做到最好。我的座右铭是 “whatever it takes（不惜一切代价）”。

如果团队需要有人定方向、搭团队，那可以是我；如果需要有人下场执行，那也可以是我。

主持人：所以你的意思是，设计管理者最好也重新回到一线做一段时间具体工作。只有亲身经历这些变化，才能真正理解当下的环境，也才能把团队带好。

Jenny Wen：我觉得是的。

传统上在工程领域，他们招一个 EM（工程经理），甚至有时候是 director，会让 EM 先轮转几个月，接一些任务，理解技术之后，再成为全职 manager。

设计可能也需要类似机制。历史上，设计更偏人事管理导向。

主持人：那你回到 IC 之后，觉得自己最生疏的是什么？

Jenny Wen：其实是做 crit（设计评审），以及被批评。 真的很难。经常性地接受批评性反馈很难。

作为设计师，把作品拿出来、讲出来，然后持续接受大量 critique（评审意见），本身就是一个很脆弱、很需要心理准备的过程。

Claude Cowork 的“10 天构建”

主持人：所以你现在是在负责 Cowork 的设计，对吗？

Jenny Wen：对。

主持人：Boris 之前说过，大家一开始对 Cowork 有很多宏大设想，争论不断，最后反而收敛成一个更务实的决定：先把它做成产品里的一个“高级终端”。那它为什么最终长成现在这个样子？这个形态是怎么一步步定下来的？

Jenny Wen：Cowork 这块，我们内部其实做过一堆不同形态的原型（prototype）。我们尝试了很多东西，也一直不太确定到底什么时候才算“准备好可以发”。

后来事情就像是突然同时发生了一样，“好，我们很快就要发了。”

然后就是 10 天，10 天的构建。

当然，整体肯定不止 10 天。更准确地说：从我们内部已有的东西，到我们觉得可以对外发布的版本，大概用了 10 天。我们其实已经做了一阵子，只是一直没确定最终该以什么“形态”（form factor）呈现。

之所以能走到这一步，是因为我们之前有很多内部探索，比如各种 agent harness（智能体驱动的框架 / 底座）之类。我们把一些交互的小模块先单独做原型，后来这些模块才逐渐演变成 Co-work 里最终呈现的样子。

举个例子：当 Claude 给你一个待办清单（to-do list）时，我们试过很多不同的展示形态；它给出多选题（multiple-choice questions）时，我们也试过很多不同形式；还有怎么教用户理解“这东西能干什么”（use cases），我们也探索了不同方式。

我也不敢说我们最终选的是“史上最好的形态”，但基本上，我们把内部已经跑通、大家确实喜欢的东西拿出来，然后觉得：与其继续闭门打磨，不如先发出去，获得更多真实信号。

所以，我们逼着自己在那 10 天内发布，本质上就是：“不管现在手里有什么，就先放出去，然后再在真实反馈里迭代。”我们现在也确实在这么做。

主持人：而且你们一发布就“炸翻互联网”，所以看起来这招挺成功的。

主持人：在 Cowork 目前的功能里，有没有哪一个是你最自豪的？或者有什么你特别迫不及待想修、想改的？

Jenny Wen：说实话，我最自豪的是：我们把它发出来了。真的，就是发出来了。

具体某一个功能我还说不上来，因为一个东西做久了，尤其对设计师来说，你眼里大部分时间看到的都是它的缺陷。

但我有很多事情很兴奋。比如我们一直在迭代首页，希望它更像这样：“这些是你可以交给 Claude 的任务”，以及“这些是 Claude 正在做的任务”。

这应该正在逐步上线，也许等这期播客播出的时候，已经上线了也说不定。

主持人：对，我看到了这个小小的随机推荐按钮，你点一下它就会给你不同的想法。

Jenny Wen：对。

然后当你真正开始和 Claude 一起工作时，我们也希望它更像一个待办清单：“这些是 Claude 正在处理的事情”，“这些是 Claude 需要你关注 / 介入的事情”。

我们有机会把它做得更像一个“你和 Claude 共用的任务清单”。我很期待继续往这个方向迭代。

我也很期待去思考更本质的“形态”问题：它会不会永远在你屏幕上常驻？还是它会跨越不同的工作界面 / 不同终端，在它正在做事的那些“表面”（surfaces）上主动触达你？

主持人：我很喜欢你刚才澄清“并不只是 10 天”。很多人爱说“我们 10 天做出来的”，但你强调的是：前面其实有大量时间花在方向判断、原型、mock、各种尝试上，然后才是“好，我们知道它大概该是什么了，开干，发布”。

Jenny Wen：对。不知道为什么，Cowork 发布后在网上最病毒式传播的点变成了“只用了 10 天”。

但事实上，我们做过很多探索，有很多人在不同模块上同时推进。真的不只是 10 天，而且参与的人也很多。

它属于那种“这个点子反复出现，但总不是最合适的时机”的项目；或者它会以不同变体出现。然后突然某一刻时机到了，就会觉得好像一切都理所当然、好像“早就该这样”，但其实背后是一条很长的路。

主持人：如果有人对 Cowork 还不太了解，我会这样描述它：像是“长了手的 Claude”，它可以在你的电脑上真的动手做事。你觉得用一两句话这么说合适吗？

Jenny Wen：这个说法很好。我之前没听过，但我很喜欢。我可能以后会更常用，“长了手的 Claude”。

我也会这样想它：Claude 特别擅长把你的一堆“垃圾”整理成好看的东西。

我最喜欢的一个 Cowork 用法是：我给它一个文件夹，里面是什么其实不太重要，但它能从里面提炼出有价值的东西。我已经这么做过很多次了。

AI 时代，哪三类
设计师人才最抢手？

主持人：在设计师岗位变化这么大的情况下，你现在在招人时，会特别看重什么新的特质？你觉得在这个新世界里成功所需要的关键是什么？

Jenny Wen：我觉得在这种环境里，一个很重要的东西是“韧性”，一种“顺势而为 / 能滚动适应”（roll with it）的心态。

身边变化太快了，你得愿意调整、愿意试新方法、试新工具、不断学习，而不是被旧流程卡住。

然后我觉得现在有三类人特别有意思。其实以前也重要，但在这个时代它们显得更关键。

第一类是很强的“通才”（generalists）。不是那种“很多都懂一点”的通才，而是更像“块状能力”（block-shaped）：如果按 T 型人才来讲，他们在几个核心技能上都能做到接近行业 80 分位的水平，很扎实、很能打。

这非常罕见，也很难招。因为设计角色正在被拉伸，越来越像 PM，也越来越像工程。你如果在几个能力桶里都很强，就更容易扩展、灵活变形自己的角色。

所以这种人很让人兴奋，当然，这要求也很高。

第二类是“深度专家”（deep specialist）。在 T 型人才里，“T 的那一竖”比多数人更深，可能是行业前 10% 的水平。同样也很难找到。

我觉得某些公司能招到这样的人，会非常幸运。

第三类，也是我觉得现在被低估的一类，我称之为“craft new grad”（“工艺感型应届生 / 新人”）。

这是那种职业早期的人，但给人的感觉“聪明得超出年龄”，同时又谦虚、渴望学习。

很多公司现在都在招资深人才，做过类似事情的人。但由于岗位职责在变、期待在变，反而需要一些“白纸”型的人：学得快、愿意学新打法、不带太多固定仪式感和流程包袱，这在今天非常有价值。

所以这三类人，是我现在最兴奋的三种原型。

主持人：关于你说的“深 T”：比如一个人在哪种技能上特别强，可能是什么样？

Jenny Wen：有些设计师非常技术向，甚至能做到 50% 像软件工程师。这很有意思，因为对我们来说，你现在很多时候是直接在和模型打交道，深一点的工程经验会非常有帮助。

另一种深度专家是视觉设计特别强的人，比如图标（icons）。在一个“人人都能做出东西”的世界里，这种很深的、强工艺的能力，反而能让你做出来的东西真正有辨识度。

给新人和资深设计师的建议

主持人：如果一个年轻设计师想入行并且做得好，甚至想加入 Anthropic，你会给什么建议？

Jenny Wen：做很多东西。多试、多做，做出真正的东西。

我不知道现在的设计教育是什么状态，但我读书那会儿，很多东西偏理论，各种方法论、框架。

而我认识的最厉害的“craft new grad”，其实就是直接用技术把东西做出来。他们不会因为自己经验不足就觉得受限。有时候，他们反而因为“没有那些包袱”，更自由。因为我们这些在行业里待久的人，身上会背着很多预设和期待，而他们没有。他们会觉得“一切皆有可能”。

所以：多做、多分享，并且找到一个也在做东西的社群。

我母校后来搞了一个叫 Socratica 的东西，他们的核心就是做项目、展示项目，像科学展览那样。有一波人就是“做东西的人”：有人做了“Claude 机器人”项目，组装机器人让它跑在 Claude 上；还有人在波士顿一辆公交车上贴了那种会动的玩具眼睛（googly eyes）。

它传递的就是一种行动力：“我们就是可以动手做事。”同时也有社群感：大家都在尝试、在构建、在分享。

不管在什么学校或背景下，只要你能找到类似方式，这种“做出来”的作品，会让人非常突出。

主持人：那对资深设计师来说：你是不是必须变得更技术化、必须学会写代码？还是说不往这边靠也能成功？

Jenny Wen：我觉得懂一点会有帮助，不一定要学到能从零搭建所有东西，但现在设计语言里越来越多地包含“实现”（implementing）这件事。

我也在想：随着模型和产品继续变好，我们会不断往更高的抽象层移动。你可能不需要理解每一行代码到底怎么跑。

但我会建议：把 coding 工具纳入你的工具箱。

不管你最后是不是“技术型设计师”，设计师都应该知道这些工具、会用这些工具，而不是按传统方式去学 React 那一套。

主持人：如果把 Claude 或 Claude Code 当成一个“设计师”来看，它现在到底有多强？你会愿意把它当成团队里的设计师来用吗？

Jenny Wen：还不会。我觉得Claude 现在还达不到“可雇佣设计师”的程度——它还不是强通才，也不是深度专家，也不是“craft new grad”。

它很擅长做第一轮草案、给出很多不同想法，但还没有哪种东西让我觉得“特别、值得雇进来”。

不过从另一个角度说，这对设计师来说暂时是好消息。

当然也很有意思去看它会变到多强。最大的开放问题是：它能不能做出真正惊艳的、全新的、独特的创意体验？还是永远不可能像人类设计师一样？

但它在过去一年里确实进步很大。

“低杠杆任务”的价值

（The Value of “Low-Leverage”

Tasks for Managers）

主持人：你之前提到过一些关于管理的看法，比如你有个挺颠覆的观点：管理者并不存在所谓“低杠杆时间”，那些看起来不重要的小事，其实往往很有价值。能具体说说你的理解吗？

Jenny Wen：对。我记得我刚做管理者时，曾听过一些建议，可能来自课程或书，强调要优先级管理，把工作分类。

比如一个 2x2 框架，大概是：“只有我能做的事”“别人也能做的事”，以及剩下的都算低杠杆，你就不该再做了。

而很多所谓“低杠杆任务”，往往是很琐碎、很钻细节的事情，理论上别人也能做。

但我回想我最尊敬的那些领导者，他们身上一个很强的特质是：他们会挑一些“看起来低杠杆”的事，自己亲自去做，结果这些事反而变得高杠杆，恰恰因为是他们在做。

比如一个例子：很资深的领导会深度 dogfood（亲自长期使用自家产品）。他们不停测试、复现 bug、把日志发给工程师、挑细节。很粗粝、很耗时间，但它能让你对产品建立极深的熟悉感。

而且它也会营造一种氛围：“这个领导真的在乎，真的懂产品，愿意卷起袖子和团队一起干。”

同样地，一个资深领导亲自修一个 bug 也很有力量。我见过 Mike Krieger 自己提 PR。那很棒，因为它传达的信号是：“我们都在同一条船上。没有什么工作是这个人不屑做的。”

再比如一个文化层面的例子：有人会特意花心思做一张很用心的周年纪念卡片。按理说助理也能做，但当一个领导亲自做时，它表达的是：他 / 她愿意为“在乎”付出时间和努力。

这就是我想践行的：主动选择一些看似低杠杆、但其实值得我亲自投入的事。

主持人：太有意思了。从某种意义上，低杠杆会因为“你亲自做”而变成高杠杆，因为你的下属并不期待你会把时间花在这上面，所以它反而很突出。

Jenny Wen：对。而且它也会成为一种“你的领导风格之所以特别”的组成部分。

主持人：我还听说你会鼓励团队成员互相 roast（吐槽 / 调侃），表面听起来不是个很美好的工作环境。但我也听说你带出来的团队，往往是最快乐、绩效也最高的。聊聊 roast 这件事，以及你对打造高质量团队有什么体会？

Jenny Wen：我不是那种会说：“哟，你们得互相 roast！”的人。我不会强迫。

但我想心理安全感（psychological safety）以及团队成员真的相处融洽时，你想想你的朋友：你们会互相开玩笑、互相调侃、试探边界。你不太会一开始就这么对同事，因为你们还在建立舒适感和安全感。

所以我并不是希望团队一定要 roast，但当大家舒服到能开一点玩笑时，往往是个好信号。

如果他们也能对你这个 leader 有这种感觉，也可能是好信号，因为说明他们不怕你，有安全感：他们可以说点什么，而不用担心“说错了就被炒”。

比如我上一个团队，他们会拿我在 crit（评审）里常说的一些话来开玩笑，某些口头禅。

主持人：比如呢？

Jenny Wen：我总会说：“好，下一步是什么？”“我们怎么跟进？” 然后他们就会学我：“好，下一步是什么？”，有点模仿我那种语气。

我觉得这说明他们不怕我。他们信任我。也说明他们对彼此、对我这个人已经足够了解，知道边界在哪。

同时也总有人会问：你和你的下属是朋友吗？很多人会说不应该是朋友。

我对这个平衡的理解是：你需要一个心理安全的底座，大家对彼此、对你都很放松，但同时他们也要知道你标准很高。

这两者看似有张力，但其实可以很好地共存：当心理安全建立起来后，大家彼此信任了，你再去坚持高标准反而更容易，因为你可以在没有恐惧的情况下这么做。

我会把它类比成一种“严格的父母”。我的团队知道：我会一直在，不会动不动就把他们开掉；但他们也知道我希望他们变得更好，我标准很高，我会和他们一起把作品做到最好。

所以这个平衡点就是：你能不能创造一个环境，让团队敢于 roast 你，同时也清楚他们必须做出很棒的工作，而且在你的带领下，他们也确实会做出很棒的工作？

主持人：这建议太棒了，让我想到《Radical Candor》（彻底坦诚）：既真诚关心，又直接挑战。我听到的就是：让大家知道你很在乎他们，同时也要直说、要坚持高标准。

“可读性（Legibility）框架”

主持人：我听说你特别喜欢一个叫 “legibility framework（可读性 / 可理解性框架）” 的东西。讲讲它吧：你怎么用？为什么你觉得它很有价值？

Jenny Wen：我好像是去年在 Twitter 上看到这个框架的。作者是 Evan Tana，他是 SPC 的合伙人，也就是一个 VC。

它本质是一个 2x2。可能当时没引起太多关注，但我一旦开始用它去看问题，就停不下来了。

在这个 2x2 里：创始人（founders）可以是“不可读 / 难懂”（illegible）或“可读 / 好懂”（legible）；想法（ideas）也可以是“不可读 / 难懂”或“可读 / 好懂”。

他的意思大概是：如果创始人和想法都非常“可读”，那这个想法往往就不够新颖，因为别人也能马上理解、马上去做，你就很难真的找到新的东西。

真正有意思的区域，是“想法本身不可读”的情况。这里的“不可读”是指：它站在前沿，人们还没理解；或者它的描述方式还没被表达成一种对大众最合理、最容易懂的形式。

这显然是 VC 很适合使用的一种视角：你要找别人看不到的机会，然后把它带到世界上。

但我也觉得，设计师的角色，至少在像 Anthropic 这种前沿实验室里，很大一部分就是：发现那些“不可读”的想法，努力看懂它到底是什么，然后把它变成“可读”的东西，不管是通过叙事表达，还是通过真正的 UX、形态（form factor），最后把它做出来并发布。

我刚才提到我会去翻 Slack、看大家在做什么，我其实就是在做这件事：看看有哪些想法“有能量”，但还不太说得清楚，这些想法值得我在工作里更深入去想。

有个和 Cowork 很相关的例子：去年中途，有人做过一个内部原型，我们叫它 “Claude Studio”。

它是一个非常密集、非常强力的界面，构建在某种 agentic harness（智能体框架）之上，我记得当时可能是 Claude Code。它有各种面板：展示 Claude 知道什么、会什么技能、正在做什么、输出预览等等。

我作为设计师看到它时的反应是：我不知道这里发生了什么。我真的看不懂。但我看到研究人员、做这个的人，以及很多内部同事，他们对它有很强的兴奋感和能量。我就觉得：好，这里面肯定有东西，只是我还没看明白。

这就是一个“不可读想法”的例子。

最终从那个原型里沉淀出来的是 skills framework（技能框架），也就是那些用来指示 Claude 如何做某事的 markdown 文件。我没有直接参与那部分；是做原型的人从中提炼出来的。

但后来当我开始做 Claude Cowork、思考这些东西应该以什么形态呈现时，那个原型对我影响很大：比如看到 Claude 的计划和待办、看到 Claude 的上下文、看到它在浏览哪些文件，这些信息形式，都启发我把它们从原型里“抽出来”，带进 Cowork。

所以，我会觉得设计师在看内部原型时，某种程度上也要像 VC 一样去思考。

主持人：我最近和一位 VC 做了个研究，回头看那些后来成为巨头公司的团队成员——比如 Palantir、Stripe、Linear、Notion，他们在公司还很早期时，到底看中了什么信号？

我们发现，一个重要因素是：那些想法往往疯狂到让大多数人觉得“不可能”，甚至被嘲笑，比如当年的 Palantir、OpenAI。

当然，听起来疯狂的不一定都会成功，看不懂的也不一定就是好机会。但你的意思是，真正值得关注的，往往是那些让人觉得有点陌生、还没被讲清楚，却又隐隐让你觉得有意思的东西——也许你能成为那个把它真正梳理清楚的人。

Jenny Wen：对，还有一点是：如果某个东西周围有能量，但我又不太明白这种能量到底来自哪里，那反而是一个信号，我应该深入下去，搞清楚它到底是什么。

主持人：对。因为很多被早期想法吸引的人，往往也说不清楚原因。你得自己去挖、去理解。

关于 Anthropic 的设计团队

主持人：除了我们聊到的，你还有没有什么想留给听众的话、想强调的点？

Jenny Wen：我想特别点名一下 Anthropic 的设计团队，夸夸他们。

他们是一群非常谦逊的人。他们不一定在社交媒体上特别高调，但他们做了很多很棒的工作，尤其是在工作内容变化这么剧烈的时期。

这个团队很有韧性，而且能力跨度很大：从非常技术、偏原型和实现的人，到非常讲究工艺、能把交付做得特别漂亮、直接上线并且很惊艳的人，都有。

而且我们全年都在招聘。所以我想说一句，如果我没把你们吓到：如果你觉得我们内部的工作方式“更刺激而不是更可怕”，我很愿意和你聊聊、建立联系。

主持人：最让人觉得刺激的是能拿到那些 Slack 的访问权限，或者看到所有正在被做出来的功能。

Jenny Wen：对，这才是核心好处。我们现在就跟超级智能聊聊，让它告诉我该投什么，开玩笑的。

主持人：那关于招聘，你有没有什么更具体的建议，给那些想申请的人？

Jenny Wen：想想我刚才提到的那几个原型，尤其是强通才和深度专家，这是我们最兴奋的两类。整体来说就是：“块状能力”和“深 T”。

最后环节：快问快答

主持人：你最常推荐给别人的书是什么？

Jenny Wen：第一本是Robert Caro 写的《The Power Broker》。我推荐它推荐得非常“强势”，因为它大概有 1100 页。

但在这个时代，我们的注意力跨度那么短，我反而觉得它值得从头到尾完整读完。因为很少有传记或回忆录能横跨一个人的整个人生，展现他在几十年尺度上的变化。

而且这本书写的是一个非常有争议的人，Robert Moses，所以你能看到一个更复杂、更有层次的视角。我觉得我们之所以失去“长周期思维”，是因为太沉迷当下。这本书会提醒你：职业生涯很长；同时它也能帮你理解一个人如何把事情做得极其高效、极其到位。

所以第一本：《The Power Broker》。

第二本我也很常推荐，叫《Insomniac City》，作者是 Bill Hayes。他在科学家 Oliver Sacks 去世前后那段时间，是 Oliver Sacks 的伴侣。

这是一本非常美、很飘渺（ethereal）的回忆录，关于 Oliver Sacks 最后的日子，以及他们的爱情故事。它跟你的播客主题几乎没什么关系，Lenny，但我很爱这本书。它会让你思考死亡，也思考爱与生命。是我最喜欢的书之一。

主持人：你最近有没有特别喜欢的一部电影或电视剧？

Jenny Wen：最近看了《A Sentimental Value》。我是在飞机上看的，你懂的，这肯定不是导演希望你看电影的方式（笑）。

它是一部挪威电影，导演也是《世界上最糟糕的人》（The Worst Person in the World）的那位。节奏、写作、人物关系，都很细腻、很美。

它基本是一个家庭故事，但也围绕他们一生居住的那栋房子展开。很美的一点是：那栋房子本身几乎也成了一个角色。我也不知道还能怎么形容，就是一部非常好的电影。

然后我也会推荐，当然，《The Pit》第二季。我们最近在追。我觉得大家都喜欢看“专业能力很强的人在认真工作”的内容。

主持人：想象一下当那部剧的演员得多辛苦，要学要背那么多术语。

Jenny Wen：对对对。而且看起来节奏也超级快。他们一镜到底要完成那么多动作、那么多走位，演员一定很难。

我也是最近才意识到 Noah Wyle 年轻时演过《急诊室的故事》（ER），现在又在这部剧里当“主心骨”了。

主持人：你最近发现、特别喜欢的一个产品是什么？但不能是 Cowork。

Jenny Wen：不是最近才发现，但我从它刚出来就用了大概两年，最近又发现了新的好处。

它叫Retro。没用过的人可以理解为：一个小型的社区照片分享 App，你只能分享“这一周”的照片，而不是你整个相册里所有年份的照片。

它几乎没有任何传统社交媒体的机制：你看不到那些数字指标（like count 之类的），没有广告等等。

一个很好的点是：现在我已经用了两年，我可以按“周”去回看跨年的生活，比如“哦，原来两年前的这一周我在做这个”。它变成了一种很特别的方式，让我重新体验自己每一周的生活。

主持人：而且如果你想培养自己的设计品味，Retro 本身也是个制作得很精致的 App。

Jenny Wen：对。

主持人：设计师都爱 Retro。我完全能想象。

主持人：最后一个问题。回到 Cowork：有没有一个让你觉得“哇，Cowork 竟然能做到这个”的用例？不管是你自己在用的，还是你听别人说的。

Jenny Wen：我很喜欢的一类用法是“自我洞察”（introspection）。

我有一个本地笔记文件夹，我用 iA Writer，我会随手写各种东西。几年下来我积累了很多笔记：一对一记录、随机想法、小备忘、采访笔记等等，什么都有。

对我来说最酷的一件事是：用 Cowork 分析整个文件夹，从里面提炼洞见，甚至基于这些内容生成一些“成型的东西”。

任何时候只要我能更了解自己一点，我都会很喜欢。

我前两天做过一个很实际的用法，跟招聘有关：我想把我心目中“设计工艺感（craft）到底是什么、我怎么判断”的标准说清楚，因为很多人其实很难把这种东西表达出来。

于是我让 Cowork 读我所有笔记，包括采访笔记、我过去写的备忘录、我在乎的一些点，它最后给我做出了一套“评估设计工艺感的 rubric（评分量表 / 评价标准）”，用来面试时判断候选人。

这种洞察特别酷：它会把你自己都没意识到、但你其实一直在隐含表达的东西“翻出来”。这对我来说非常有意思。

主持人：我换个更直白的说法：你有一个文件夹，里面是这些年写下的所有东西，比如一对一记录、会议笔记，可能还有会议转写，然后你把整包资料交给它去分析。

我原本想问你具体用了什么 prompt，但听起来其实很简单：让它读完你所有写过的内容，帮你总结——你到底是怎么理解设计的。

Jenny Wen：对，我当时大概是这么跟它说的：这个文件夹里有很多面试笔记，还有不少我平时关于设计工艺的思考。你都读一遍，然后帮我整理出一份备忘录或评估标准，总结我在面试中是怎么判断一个人有没有 “craft” 的。

https://www.youtube.com/watch?v=eh8bcBIAAFo

声明：本文为 AI 前线整理，不代表平台观点，未经许可禁止转载。

会议推荐

OpenClaw 出圈，“养虾”潮狂热，开年 Agentic AI 这把火烧得不可谓不旺。在这一热潮下，自托管 Agent 形态迅速普及：多入口对话、持久记忆、Skills 工具链带来强大生产力。但这背后也暴露了工程化落地的真实难题——权限边界与隔离运行、Skills 供应链安全、可观测与可追溯、记忆分层与跨场景污染、以及如何把 Agent 纳入团队研发 / 运维流程并形成稳定收益。

针对这一系列挑战，在 4 月 16-18 日即将举办的 QCon 北京站上，我们特别策划了「OpenClaw 生态实践」专题，将聚焦一线实践与踩坑复盘，分享企业如何构建私有 Skills、制定安全护栏、搭建审计与回放机制、建立质量 / 效率指标体系，最终把自托管 Agent 从可用的 Demo 升级为可靠的生产系统。