作为工程师，我们这两年最常听到的问题是：AI 会不会替代工程师。
真正落到一线你会发现，问题其实换了形态。代码生成当然在加速，但团队最吃力的地方，越来越不是“把代码写出来”，而是“在极快迭代里保持方向一致、质量可控、决策有人负责”。
最近看了一期 Lenny‘s Podcast 对 Anthropic 设计负责人 Jenny Wen 的深度访谈。Jenny 之前是 Figma 的设计总监，主导过 FigJam 和 Slides 从概念到发布的全流程，更早在 Dropbox、Square 和 Shopify 做设计，现在负责 Claude Co-work 的设计。
她在访谈里给出了一个很扎实的判断——
“设计师们被教导的那套设计流程，我们曾经把它当圣经一样遵循，现在基本已经死了。”
（”This design process that designers have been taught—we sort of treat it as gospel—that‘s basically dead.“）
这句话表面在说设计，但背后指向的是整个研发体系的协作重排。这篇文章就从这场访谈出发，聊一个对我们更切身的问题：当 AI 把研发节奏抬到新速度后，架构师和高级工程师到底该怎么重新定位自己。
你最先感到的变化，是决策窗口在变短
过去你可能有几周时间做方案比选、跨组评审、再推进实现。
现在很多团队已经进入另一种节奏：一个想法上午提出，下午就有 Agent 驱动的可运行版本，第二天就有人拿真实数据来讨论去留。
Jenny 提到了一个很直观的场景：Anthropic 内部工程师可以同时并行运行 7 个 AI Agent。她说了一句很有意思的话——
“不仅仅是设计师在感叹要跟上工程师的节奏，连工程师自己都在问：我们该怎么跟上自己的 Agent？”
作为架构师，你应该能感受到这背后的三个变化同时在发生：
- 讨论窗口更短。 过去那种“先花两周写 RFC、再开三轮评审”的节奏，越来越跟不上实现的速度。抽象争论的容忍度在降低。
- 原型数量暴涨。 以前一个迭代周期出一两个方案，现在可能同时冒出五六个可运行版本。筛选成本从前端实现转移到了后端决策。
- 局部最优更容易出现。 每个 Agent 在自己的分支上跑得很快很好，但合到一起时，系统一致性比以前更难守。
所以，这不是“工程师减少了价值”。
工程师的价值正在从“实现单点功能”迁移到“维持系统秩序”。
设计流程为什么会失效：根源在工程侧
Jenny 指的是经典的双钻石模型——先调研发散，再收敛，再发散，再收敛。她 2025 年 9 月在柏林的 Hatch Conference 做了一场叫“Don‘t Trust the Design Process”的演讲，引发了很大反响。但那场演讲才过了三四个月，她自己就觉得内容过时了。尤其是 Opus 4.6 发布、大量人在假期期间发现了 Claude Code 之后，变化比她预期的还要快。
这套流程不是没有方法论价值，而是它依赖的前提已经变了。
过去的前提是 实现慢、改动贵，所以前置设计可以显著减少返工。现在的前提是 实现更快、试错更便宜，先做可运行版本再迭代，很多时候反而更经济。
Jenny 给了一组很清晰的数字来描述这种变化：
- 几年前：60-70% 的时间做设计稿和原型，20% 与工程师配合，10% 开协调会。
- 现在：30-40% 做设计稿，30-40% 与工程师直接结对，剩下的时间——自己写代码实现。
她还提到了协作方式的变化。以前设计师给反馈是“这个按钮不该放这里”，现在更多是解释背后的原则——“我觉得应该有个按钮，因为用户研究显示不是所有人都知道可以用提示词触发这个功能”。她也会引导工程师用设计系统里现成的组件，因为 Claude 写代码时并不总是会自动使用设计系统。
“你最好别挡着他们，让他们放手干。”
（”You‘re better off not blocking that, letting them cook.“）
如果你是架构师，这句话值得反复琢磨。它不是说放弃标准，而是说 管理方式要从“前置门禁”变成“伴随式护栏”。你要管理的，不再只是技术栈复杂度，还包括“高速并发实验”带来的组织复杂度。
双轨并行：速度和方向必须同时存在
Jenny 把变化概括成两条轨道并行。这个框架虽然是从设计视角提出的，但对工程团队同样适用。
第一条轨道：执行推进。 让功能尽快进入真实环境。工程师在高速出活，任何人都可以提一个想法然后让 AI 做一个粗糙版本出来试试。
第二条轨道：短期方向。 确保团队不会各自很快但整体发散。过去可以做 2 年甚至 10 年的愿景，做出精美的故事化演示文稿；现在的愿景通常只能看到 3-6 个月后，形式有时候就是一个能指方向的原型。
如果只保留执行轨道，团队会非常快，但系统会逐渐碎片化。
如果只保留方向轨道，团队会非常统一，但交付速度会显著下滑。
这跟我们做架构的逻辑是一样的：你不能只画蓝图不落地，也不能只埋头写代码不看方向。成熟团队的关键能力，是让这两条轨道同时存在，并且彼此校正。
在这个结构里，不同角色的结合点很清晰：
- 架构师把控边界、协议和一致性约束，用 3-6 个月的短期方向取代僵化的长期蓝图。
- 高级工程师推动关键链路落地，把抽象原则变成可运行实现，亲自介入“最后一英里”的代码细节。
- 设计与产品负责体验取舍和价值判断，减少无效实现。
三方的共同目标是：让每一轮快速迭代都不透支下一轮的系统健康。
非确定性模型，正在改写我们熟悉的评审方式
传统业务系统里，我们可以通过状态图、接口契约、联调清单把大部分路径提前穷举。
AI 产品里，这个假设不再成立。相同输入可能给出不同输出，用户行为路径也更发散。Jenny 说得很直接：你无法在设计稿里模拟所有状态，甚至做不出有意义的可点击原型。你必须用真实模型、看真实用户怎么用，才能发现真正的使用场景。
【注：Non-deterministic（非确定性）指同样的输入可能产生不同的输出。传统的“画好所有界面状态”的方法在 AI 产品中失效了，因为 AI 的回应本身不可预测。】
这对架构评审的冲击是直接的。
以前是“先评审完整方案，再允许进入开发”。现在更现实的做法是“先让关键链路跑起来，再围绕真实行为收敛方案”。架构师的角色从“前置守门人”转变为“实时顾问”——不要求团队在写代码前必须先通过完美的架构评审，而是在工程师构建出初步版本后，立刻介入一起过流程、梳理逻辑、提供实时反馈。
对高级工程师来说，这不是降标准。恰恰相反，这是把质量工作从“文档正确”推进到“行为正确”——你要对着真实运行的系统来判断，而不是对着一份 PPT。
工具栈分层之后，谁负责什么反而更清楚
访谈里一个容易被忽略的话题是：Figma 没消失，IDE 也没有取代一切，Co-work 这类长任务助手也不是万能。
Jenny 认为 Figma 仍然重要，但原因跟以前不一样了。代码工具太线性——你用 Claude Code 做一个方向，就会一直在那个方向上迭代深入。但好的方案探索需要先想 8-10 种不同做法，把想法甩到墙上再筛选。这种发散式探索，画布工具仍然做得最好。
她在 Anthropic 的日常工具栈是这样的：Claude Chat 已经基本被 Claude Co-work 取代了，因为她的使用场景大多是长时间运行的任务。Claude Code 主要在 VS Code 里用，做前端打磨时需要同时看代码和跟 Claude 对话。一个她觉得特别有意思的工作方式是：有人在 Slack 里说“这个图标偏了”，@ 一下 Claude，Claude 自动改好代码并提交 PR，她直接合并就完成了。
对架构师来说，更值得关注的是分层逻辑本身：
- 探索层（Figma / 画布工具）：快速并排多个方向，做发散式对比。对应我们的方案比选阶段。
- 执行层（IDE + Claude Code）：在代码里做最后一公里的实现和打磨。对应我们的落地实现阶段。
- 长任务层（Claude Co-work）：承接跨文档、跨上下文的复杂工作。对应我们的系统梳理、技术文档、架构重构。
【注：Claude Co-work 是 Anthropic 于 2026 年 1 月推出的桌面端 AI 智能体产品，可以操作用户电脑上的文件，完成文档生成、数据整理等非编码类知识工作。】
Lenny 在访谈中还观察到一个有趣的错位：在工程领域，IDE 正在被命令行和 Agent 取代，工程师觉得 IDE“不酷了”。但对设计师和产品经理来说，IDE 反而变成了新工具——有时候直接改一个 CSS 样式比跟 AI 描述快多了。工具的“身份”正在被重新分配。
当团队把这三层关系理顺，谁在探索、谁在落地、谁在维护上下文连续性，不再靠会议里反复解释。
“10 天发布”最容易被误读，真正难的是后面的 30 天
这次访谈里提到 Co-work 的“10 天发布”故事，很多人只记住了速度。
但 Jenny 纠正了这个印象：这 10 天是从内部版本到外部可见版本的最终冲刺，不是从零开始。在此之前，团队在不同的 Agent 框架上做过大量原型和探索——待办列表怎么展示、多选问题用什么形式、怎么教用户理解使用场景，都试过很多种方案。
“这个想法一直在反复出现，然后突然之间，时机到了，感觉就像一直都这么显而易见一样。但走到那一步的旅程很长很长。”
（”The idea kept coming back, and then all of a sudden, it‘s the right moment, and it feels like it was so obvious all along. But there was a long, long journey to get there.“）
真正决定口碑的，也不是“首发有没有瑕疵”，而是发布后的迭代响应有没有兑现。
Jenny 在访谈里说了一句很直接的话：
“真正损害品牌的，不是发布了一个早期版本，而是发布之后什么都不做。”
（”The way that you really lose trust around quality... is if you release it early and then nothing ever happens.“）
这对工程组织的启发很实在。如果发布后没有快速修复、没有清晰反馈通路，再快的首发都会被用户理解为“你只是在抢时间线”。反过来，只要团队持续响应——Anthropic 每次发布新版本后，团队成员在 Twitter 上回复用户反馈，快速修复问题，公开展示进展——用户会把“早期版本的不完美”看作进化过程的一部分。
Lenny 把这种理念概括为“ 通过速度建立信任 ”（Building trust through speed）。Jenny 补充说不只是速度，还有让用户觉得“我的反馈被听到了、被用上了”。
对做架构的人来说，这意味着你的系统设计必须为“快速响应”预留空间——可观测性、灰度发布、快速回滚，这些不是加分项，而是基本盘。
最值得警惕的是“内部高潜原型被流程错杀”
访谈后半段提到了一个来自 SPC（South Park Commons，硅谷创业社区）合伙人 Evan Tana 的“可读性框架”。矩阵的两个轴是：发起人是否“可读”（别人一看就懂他是谁），想法是否“可读”（别人一听就懂要做什么）。
如果两者都高度可读，那这个机会大概率已经有人在做了。 最有价值的往往是“想法不可读”的象限 ——别人看不懂、但有能量在汇聚的方向。
Jenny 分享了一个具体案例。去年 Anthropic 内部有人做了一个叫“Claude Studio”的原型，界面非常密集和复杂，建在某种 Agent 框架上。她第一眼看到时觉得“我不知道这是什么”。但她注意到研究团队和内部用户对它非常兴奋。她没有忽略这个信号，而是选择深入了解。最终，那个原型里的核心概念——比如 Skills 框架（用 Markdown 文件指导 Claude 如何完成特定任务），以及展示 Claude 计划和待办事项的 UI——都被提取出来放进了 Co-work 的正式产品中。
这跟我们日常碰到的情况很像：团队里总有人私下搞了个“不规范”的内部工具，代码写得挺糙，但用的人特别多。你是按标准把它毙掉，还是先搞清楚它解决了什么问题？
架构师并不是要为所有“野路子原型”背书，而是要识别哪一类“暂时不规整”的东西值得给第二次机会，再通过架构约束把它从原型拉成产品。这是“守纪律”与“保创新”之间最难的平衡点。
当 AI 也在进化“品味”，人的价值回到最朴素的两件事
访谈里有一句话让我印象很深：
“构建软件最难的部分，其实不是构建它本身。”
（”A lot of the hard parts of building software are actually, like, not building it.“）
Jenny 认为 AI 在品味和判断上会越来越好，“我们可能在这一点上执念过深了”。Claude Code 的负责人 Boris Cherny 也在最近的播客上表示：Claude Code 已经不只是写代码了，它开始帮他想点子、扫描反馈和缺陷报告来主动提出改进建议。
【注：Boris Cherny 是 Claude Code 的创建者和负责人，在 2026 年 2 月的 Lenny‘s Podcast 中表示“编码这件事基本已经被解决了”。】
模型会越来越会写代码，也会越来越会生成方案。很多实现动作会继续自动化。
但回想你工作中最难的时刻，往往不是技术实现，而是你和另一个人在争论“这个功能到底该不该做”、“该做成什么样”。这种人与人之间的决策分歧，AI 可以提供参考意见，但不能替你解决。
Lenny 在访谈中用了一个放射科的类比：AI 可能比放射科医生更擅长看片子，但你还是需要一个人签字，因为得有人在出错时承担责任。
团队真正高成本的时刻，依然是这些问题：
- 两个都可行的方向，怎么选。
- 短期收益和长期一致性，怎么权衡。
- 线上出问题时，谁来拍板、谁来承担后果。
就像今天即使 Claude 能够编写所有的代码，最终仍然需要人来确保“这些代码是否真正有效”、“在产品逻辑中是否合理并值得信赖”。
所以在 AI 时代，架构师和高级工程师的核心竞争力不会消失，只会变得更明确： 第一是决策质量，第二是问责能力。
团队的“配合面”该怎么建
如果把这轮变化当成一次岗位升级，那么“结合”不是简单分工，而是形成一个稳定的配合面。
Jenny 在谈到招人标准时，提到了三种面向未来的人才原型。虽然她说的是设计岗位，但对工程团队同样有借鉴意义：
- 方块型强通才：不是什么都沾点但都不深，而是多个核心技能都达到 80 分位水平。这种人在角色边界模糊的时代特别有价值——能随时切换成半个产品经理或半个架构师。
- 深 T 型专家：在某个细分领域排到行业前 10%。在“任何人都能用 AI 做出还行的东西”的时代，深度专长才能做出差异化。
- 行动派新锐：职业早期但成熟度超过年龄，没有固化的流程思维，学新工具的速度极快。Jenny 说大多数公司都在抢资深人才，但恰恰因为规则在变，一个白纸状态的快速学习者可能比满脑子旧流程的资深人更有优势。
对我们来说，这意味着架构师自身也需要拓宽技能边界。单纯的理论指导在 AI 工具大幅降低执行门槛的今天，已经不够了。你需要熟悉并使用最新的 AI 工具来辅助编码、验证想法和排查问题，把自身的技术视野扩展到产品体验和业务落地上。
在配合面的建设上，管理者是否回到一线也很关键。Jenny 自己就是从 Figma 设计总监的位置回到了 IC（Individual Contributor，个人贡献者）岗位。她的判断很实在：
如果一直在做纯管理，根本不会有时间去习得这些新的硬技能。
她提到回到 IC 后最不适应的事情是： 接受批评 。作为设计师要在团队面前展示工作、接收批评性反馈，这是一个相当脆弱的过程，而管理岗待久了会对此生疏。
她建议管理者也应该做类似工程管理者的“实操轮岗”——先花几个月做 IC 理解技术变化，再回去管团队。脱离真实交付太久，你对“该快还是该稳”的判断，很容易失真。
这也引出了访谈中另一个有意思的话题： “低杠杆”的事，到底该不该做？
管理培训会教你用矩阵分类工作，把“低杠杆”的事都砍掉。但 Jenny 观察到，她最尊敬的领导者往往反其道而行——深入一线亲自测试产品、重现 Bug、和工程师一起查日志、甚至像 Instagram 联合创始人 Mike Krieger（现 Anthropic 首席产品官）那样亲自提交代码。
正因为是他们在做，这些事反而变成了高杠杆。 它向团队传递的信息是：“没有什么事是掉价的。”
Jenny 还提到了一个衡量团队健康度的信号： 当团队成员敢拿你开玩笑时 。她之前团队的人会模仿她在设计评审会上的口头禅“OK，下一步是什么？”——这说明他们了解你、不怕你。这种心理安全感是推行高标准的基础。就像“严厉的父母”：团队知道你会支持他们，同时也知道你要求最好的工作。
最后一句
“设计流程已死”如果只当成设计圈话题，会看窄。
它其实在提醒整个研发组织：
- 从“交付文档”走向“交付结果”。
- 从“阶段串行”走向“方向与执行并行”。
- 从“首发完美”走向“持续兑现”。
回到开头那个问题。AI 会不会替代工程师？
短期内更现实的答案是：AI 会替代一部分旧工作习惯。谁能更快把“实现能力”升级为“系统判断力”，谁就在下一轮协作结构里占优势。
Jenny 在访谈最后被问到人生座右铭，她说了一句话：
“It is what it is.”
听起来像认命，但她说在一切都在变的世界里，这句话能给你需要的轻松感来继续前行。
对架构师和高级工程师来说，也许可以把这句话换一种理解：
接受变化的事实，然后专注于你真正不可替代的部分——做出好的决策，并为它负责。
来源
这场由 AI 驱动的研发变革仍在进行中，欢迎来云栈社区的开发者广场，和我们一起探讨更多关于未来团队协作与个人发展的可能性。
发表于 3 小时前
|
查看: 7|
回复: 0
