几个月前 Pencil 刚出来的时候，我觉得它对 Figma 是一次降维打击。
那时候我的判断很简单：Figma 的优势在设计生产，但 AI 正在把生产这件事从画布里抽走。Pencil 把设计搬进 IDE，让设计文件和代码共享 repo、branch、commit、merge，这看上去像是一个更接近 AI Coding 时代的设计工具。沿着这个逻辑看，Figma 的问题不是没有 AI，而是它还站在画布中心思考 AI。
这个判断没有错，但只说对了一半。
最近用 Claude Design，我的判断又变了一次。Claude Design 当然也能生成设计、原型、slide、one-pager，也能导出 PDF、PPTX、HTML，甚至能把设计 handoff 给 Claude Code。但如果只把它看成一个设计工具，就错过了它真正重要的地方。
Claude Design 不是 Anthropic 跨界做了一个 Figma 竞品。它更像是 Anthropic 把 Claude Code 那套工作架构，换了一个介质，搬到了视觉设计里。
这件事比设计工具竞争本身重要得多。
我看到的不是功能，是架构
Claude Design 最让我停下来的地方，不是它生成出来的页面有多好看，而是它的 onboarding。
它不是先问你喜欢什么颜色、什么字体、什么圆角，也不是让你从一个空白画布开始拖组件。它先问：有没有 codebase 可以读？有没有一份能代表你们品牌的 PPT、PDF 或设计文件？然后它从这些材料里抽取 color palette、typography、components、layout patterns，生成一套团队设计系统。之后每个项目都会默认带着这套系统往前走。
这看起来是在解决品牌一致性，实际上是在解决 agent 的工作条件。
一个人类设计师之所以能持续做出"像这个公司"的东西，不是因为他每次都重新思考品牌色，而是因为他脑子里已经沉淀了一套长期有效的默认判断：这个品牌通常用什么节奏，什么视觉语气，什么组件习惯，什么布局密度，什么东西看起来"不像我们"。
Claude Design 做的第一件事，就是把这些默认判断变成 agent 每次工作时都会带上的持久上下文。
这和 Claude Code 里的 CLAUDE.md 是同一件事。Claude Code 文档里说得很清楚：CLAUDE.md 是放在项目里的 markdown 文件，Claude Code 会在每次 session 开始时读取，用来承载 coding standards、architecture decisions、preferred libraries、review checklists 等长期指令。它不是一个 prompt 小技巧，而是让 agent 不必每次从零理解项目的"项目记忆"。
换到设计领域，这份记忆不再是代码规范，而是品牌资产、组件习惯、版式语言和视觉边界。
所以 Claude Design 的关键不是"能不能画图"，而是它先问了一个更底层的问题：
一个设计 agent 要想稳定工作，它每次启动时必须知道什么？
这是我认为它和 Claude Code 完全同构的地方。
真正的统一架构：不是工具，而是 harness
我现在越来越觉得，未来垂直岗位和 AI 结合的最佳实践，不是"给这个岗位做一个 AI 工具"，而是给这个岗位搭一套 agent harness。
这个 harness 至少有五层。
第一层是持久上下文。它回答的是：这个岗位里有哪些东西不应该每次重新解释？对工程师来说，是代码结构、架构约定、测试命令、review 标准。对设计师来说，是品牌系统、组件库、设计原则。对 PM 来说，是核心用户是谁、我们做什么、不做什么、哪些取舍原则高于短期需求。对法务来说，可能是合同模板、风险偏好、审批红线。对投研来说，可能是投资框架、历史案例、估值口径和禁区。
第二层是任务上下文。它回答的是：这一次具体要做什么？用户是谁，目标是什么，输入材料有哪些，约束是什么，失败模式是什么，参考样例是什么。Claude Design 里的 brief、上传文档、网页抓取、inline comment，都是在补这一层。Claude Code 里让它先读 repo、看 issue、跑测试、理解 error log，也是这一层。
第三层是专业技能。它回答的是：这个岗位有哪些可复用的动作流程？Anthropic 对 Agent Skills 的定义很接近这一点：Skill 是一组 instructions、scripts、resources，Claude 可以在相关任务里动态加载；它的核心原则是 progressive disclosure，先只加载 name 和 description，真正需要时再读取完整 SKILL.md，必要时再读取更多文件或运行脚本。
这句话翻译成岗位语言就是：不要把所有专业知识都塞进一次 prompt，而要把可复用的专业流程做成 agent 能按需调用的工作手册。
第四层是可执行介质。工程师的介质是 repo、terminal、IDE、git。设计师的介质是 canvas、HTML、PPT、Canva、Figma、Claude Code handoff。PM 的介质不是 PRD，而是 metrics、用户反馈、原型、issue、launch room、evals。很多人还在问"AI 能不能替我写产物"，但更重要的问题是：AI 到底能在哪里行动？它能读什么，改什么，运行什么，提交什么，交付到哪里？
第五层是评估闭环。没有 evals 的 agent workflow，本质上还是一次性生成。真正可规模化的 agent workflow，一定要有某种"成功长什么样"的可执行定义。工程里是 test、lint、CI、review。设计里可能是品牌一致性、可用性、状态覆盖、视觉偏差检查。PM 里就是 Cat Wu 说的 evals：不需要几百个，10 个好的 evals 就能让团队量化目标、量化进展、看到缺口。
把这五层合在一起，你会发现 Claude Design 和 Claude Code 不是两个产品，而是同一套东西在两个介质里的实例化。
Claude Code 是代码岗位的 agent harness。
Claude Design 是设计岗位的 agent harness。
未来每个岗位都会长出自己的 harness。
这也是 Cat Wu 那段访谈真正重要的地方
我原来读 Cat Wu 那篇访谈，最容易被那句"真正值钱的是判断该写什么"吸引。它当然很对。当代码越来越便宜，判断做什么会更值钱。
但现在把 Claude Design 放在一起看，我觉得更重要的不是这句话，而是她描述的 Anthropic 内部工作方式。
她说 AI 原生产品里，PM 的重点不应该是维护多季度 roadmap，而是想办法让一个 idea 以最快速度到用户手里。她提到团队会做严格的 weekly metrics readout，让每个人理解业务；会有一份团队原则，写清楚核心用户是谁、为什么是他们、愿意牺牲什么；会用 research preview 降低上线承诺成本；工程、marketing、docs、DevRel 之间有非常紧的 launch room，让一个功能准备好后第二天就能推出去。
这不是普通意义上的"PM 用 AI 提高效率"。
这是把 PM 这条链路本身重新架构了。
过去 PM 的工作经常被理解成写 PRD、拉会、对齐路线图、协调资源、推动上线。AI 时代，如果工程速度被 Claude Code 大幅加速，PM 的瓶颈就不再是"怎么把需求写清楚"，而是"怎么让团队更快地从信号走到判断，从判断走到行动，从行动走到验证"。
这条链路可以写成：
信号 → 判断 → 行动 → 验证。
信号来自 metrics readout、核心用户反馈、dogfooding、模型边界测试。
判断来自团队原则、产品品味、对当下模型能力的理解。
行动由 Claude Code、Cowork、内部工具和轻量 launch process 放大。
验证由 evals、用户反馈、research preview 和下一轮迭代完成。
这和 Claude Design 做的事情完全对应。设计师的链路是：
需求理解 → 方向探索 → 产物生成 → 视觉验证 → 工程 handoff。
Claude Design 加速的不是"画一个页面"这一小段，而是把整条链路变成 agent 可以参与、可以沉淀、可以复用、可以 handoff 的系统。
所以 Cat Wu 的访谈和 Claude Design 其实在讲同一件事：AI 不是把某个岗位里的一个动作变快，而是把整个岗位链路变成一个更短的闭环。
真正被替代的不是岗位，而是没有 harness 的岗位
这也是我觉得这轮变化比"设计师会不会被替代"大得多的原因。
很多关于 AI 的讨论还停留在岗位名上：设计师会不会被替代，PM 会不会被替代，工程师会不会被替代，分析师会不会被替代。
但岗位名其实是一个很粗糙的单位。AI 真正冲击的不是岗位名，而是岗位里那些没有被结构化、没有被验证、没有被自动化、没有被沉淀的工作链条。
一个设计师如果只会把需求翻译成静态稿，那部分工作会迅速被 Claude Design 这样的工具吞掉。但如果他能把品牌判断沉淀成设计系统，把常见视觉问题写成评估规则，把探索路径变成可复用 skill，把 handoff 变成能直接进入工程实现的包，他就不是在和 AI 抢"画图"这件事，而是在设计整个设计 agent 的工作环境。
一个 PM 如果只会写 PRD，再把 PRD 扔给工程师，那部分工作也会越来越薄。但如果他能把用户信号接进来，把团队原则写清楚，把判断标准变成上下文，把模糊问题拆成可测试的 evals，把从 idea 到用户的路径压到最短，他做的就不是传统 PM，而是产品链路的加速器。
一个运营、法务、财务、HR、投研人员也是一样。
未来每个岗位都要回答同一个问题：
你能不能把自己岗位里的隐性经验，改造成 agent 可以读取、调用、执行、验证的系统？
能回答这个问题的人，不会被简单替代。回答不了的人，不一定被 AI 替代，但会被那些已经搭好 harness 的同行替代。
所以，Claude Design 的意义不在设计
我现在回头看 Claude Design，觉得它最重要的地方甚至不在设计。
它演示了一件更通用的事：当模型能力足够强，产品的核心不再是给用户一个更强的编辑器，而是给 agent 一个更好的工作环境。
这个工作环境里，要有长期记忆，要有本次任务的上下文，要有可调用的专业技能，要有能行动的介质，要有评估和 handoff 的闭环。
Anthropic 在 context engineering 那篇文章里讲过一个很关键的观点：agent 的关键不只是写好 prompt，而是持续管理进入模型上下文的所有信息，包括 system instructions、tools、MCP、external data、message history 等。上下文本身是有限资源，应该用最小但高信号的信息集，最大化模型产生目标行为的概率。
这句话放到岗位上看，几乎就是下一代职业方法论。
过去一个职业高手的优势，藏在脑子里、经验里、习惯里、判断里。新人跟着他干几年，才能慢慢学会什么该看、什么不用看、什么是红线、什么是好、什么是差、什么时候该推进、什么时候该停。
现在这些东西第一次可以被写进上下文、skills、tools、evals 和 workflow 里。它们不再只是人的经验，而会逐渐变成组织的可执行资产。
Claude Design 把这件事在设计领域演示了一遍。
Claude Code 已经在工程领域演示了一遍。
Cat Wu 描述的 Anthropic PM 工作方式，又在产品管理领域演示了一遍。
它们共同指向同一个结论：
AI 原生岗位的核心，不是人更会使用 AI，而是岗位本身被重新组织成一套 agent 可运行的架构。
最后
所以这次我改的不是对 Pencil 的判断。
Pencil 也好，Stitch 也好，Figma 也好，它们仍然是重要的设计工具。但 Claude Design 让我看到的不是一个新工具，而是一种更底层的迁移：同一套 Claude Code 架构，正在被套到代码之外的每一种专业介质上。
今天是设计。
明天是 PM、运营、销售、法务、财务、投研、客服、HR。
每个岗位最后都会被问同一个问题：你的 CLAUDE.md 是什么？你的 skills 是什么？你的工具接口在哪里？你的 evals 怎么写？你的 handoff 怎么闭环？你的经验能不能从个人直觉，变成 agent 可以工作的环境？
这才是 Claude Design 真正值得看的地方。
它不是设计工具的一次更新。
它是所有垂直岗位 agent 化的一次公开样板。