从 Vibe 到 Specs:如何用 SAID 框架重构设计流程
文章提出SAID框架,主张以规范驱动开发取代传统线性设计流程,让设计师在Git环境中定义系统行为与约束,并与AI智能体高效协作。

五个月前,Anthropic 设计负责人 Jenny Wen 提出的“设计流程已死”引发了人们基于正确初衷的激烈讨论。如今,这一观点更犀利、更本质的表述其实很简单:传统的、线性的设计流程,已经无法满足 AI 原生团队构建数字产品的需求。
我们不只是在微调“双钻石”(4D)模型。工程、产品、设计和数据科学正在日益融合成更加流体化的工作流,曾经定义我们职能岗位的边界正在发生位移。
正因如此,最关键的转变在于:设计工作正被拉得更贴近实现、迭代与判断。如果你审视那些定义了这个时代的高效团队(例如打造 Claude Code 的核心团队),你会发现这里并不总是一个经典的“产品经理、设计师加三名工程师”的传统阵容。相反,正如 Anthropic 联合创始人 Boris Cherny 所分享的那样,你会看到团队成员在以下五种截然不同的行动原型之间无缝切换:
1.原型师(The Prototyper):产出大量高互动性的原始想法,其中大部分最终会被舍弃。
2.构建者(The Builder):将经过验证的原型转化为生产级的底层架构。
3.清理者(The Sweeper):打磨界面、精简代码、去除冗余,并提升系统性能。
4.拓展者(The Grower):持续迭代产品,直到实现产品与市场的深度契合并不断扩大战果。
5.维护者(The Maintainer):确保成熟系统的安全性、稳定性和可扩展性,使其始终保持高速与可靠。
这样的框架至关重要,因为它改变了团队对人才的思考方式。一个强大的产品团队不单单是一堆头衔的组合,而是一群能够在创造、打磨、交付和维护之间灵活流转的人。比起某个具体头衔,更重要的是这个人能否助力团队打造出下一个有价值的产品。
新媒介:以 Git 作为共享工作空间
工具碎片化曾是业务运转中必付的成本。我们过去习惯用 Miro 头脑风暴、用 Figma 绘制设计、用 Confluence 撰写文档、用 Jira 跟踪进度,最后再用 GitHub 进行开发。
而如今,这种割裂感正在带来效率阻力。在 AI 原生团队中,产品对话正变得更加贴近底层实现,而 Git 已经逐渐成为一个集规范、代码与迭代于一体的核心共享工作空间。

这改变了想法的表达方式:
“氛围编码”(Vibecoding)交互:团队不再是通过绘制静态流程图并让大家脑补动效,而是可以直接进行交互原型制作并快速测试。
重规范(Specs)轻界面:界面依然重要,但作为“唯一真实数据源”(Source of Truth),规范正变得前所未有地关键。工程的未来属于智能体驱动开发(Agentic SDD,即规范驱动开发),它们是能够指导代码生成的、兼具人类与智能体可读性的精准需求描述。
“氛围编码”(Vibecoding)交互:团队不再是通过绘制静态流程图并让大家脑补动效,而是可以直接进行交互原型制作并快速测试。
重规范(Specs)轻界面:界面依然重要,但作为“唯一真实数据源”(Source of Truth),规范正变得前所未有地关键。工程的未来属于智能体驱动开发(Agentic SDD,即规范驱动开发),它们是能够指导代码生成的、兼具人类与智能体可读性的精准需求描述。
一个典型的例子是,某个功能最初可能只是一份模糊的设计提案(Deck)。在旧模型中,这份提案可能需要在各种会议、Figma 视觉稿和交接文档之间反复横跳,很久之后才会出现真正意义上的原型。
而在较新的模型中,团队能够以极快的速度从“意图”跃迁到“交互测试”,从而更轻松地探明究竟什么才真正值得去构建。这种速度极具爆发力,但前提是团队必须保持足够的克制与纪律,避免过早交付不够成熟的想法。
对于设计师意味着什么
难道设计师为了学 Git 而去学 Git,最终都要变成写 Markdown 的软件工程师吗?倒也未必,但学会如何以一种能够融入代码世界并经受住考验的方式来表达意图,将成为关键所在。

非正式的提示词在大规模协作中往往会失效,而规范驱动开发(SDD)则通过将“做什么(what)”与“怎么做(how)”剥离,为 AI 智能体提供了一个清晰无误的唯一真实数据源(Source of Truth)。(图片来源:Bao)
在这个时代,规范(Spec)不再是枯燥的文档,而是对逻辑、用户意图、系统状态以及设计约束的具体阐述。与其花上数小时在静态界面上精细对齐像素,设计师们现在正越来越多地去定义系统的规则与行为。在实践中,这意味着去塑造产品如何对各种输入做出响应,而执行层面则更多地交由智能体和工程师去处理。
如果一个设计想法无法被转化为具体的行为、约束以及可测试的规则,那它就依然过于抽象,无法进行规模化落地。
重构系统结构
彼得·圣吉(Peter Senge)在其开创性著作《第五项修炼》中写道:
“结构解释之所以如此重要,是因为只有它们才能在行为模式得以改变的层面上,触及行为的根本原因。结构产生行为,而改变底层结构能够产生不同的行为模式。从这个意义上说,结构解释本身就具有生成性。此外,由于人类系统中的结构包含了决策者的‘运营政策’,因此重新设计我们自身的决策机制,也就是在重新设计系统的结构。”

从对表面“事件”的肤浅反应(例如调试混乱的智能体输出),跃升至重新设计底层结构(我们的规范与工作流),并转变团队关于人机协作的心智模型。(图片来源:Carretto)
换句话说,仅仅告诉团队“要用不同的方式工作”是无法改变任何现状的;唯有改变他们所处的工作系统,才能真正带来改变。如果你想要不同的产品成果,就必须重新设计你的工作流和决策规则。改变心智模型,行为自然就会随之改变。
这也是许多团队常常陷入困境的地方。他们总是让设计师“多做协作”,或者让工程师“多关心用户体验(UX)”,但这些口号根本无法改变现有的系统。工作流依然如故,激励机制依然如故,团队最终产出的东西也自然换汤不换药。如果底层结构没有发生改变,行为通常也不会改变。
为了顺应这一变革,Anthropic 引入了另一个用于人机协作的框架:4D AI 熟练度框架(4D AI Fluency Framework)。
委派(Delegation):明确哪些认知任务属于人类团队,哪些属于智能体。
描述(Description):以绝对清晰的方式表达意图、规则和系统行为。
辨别(Discernment):在批准通过之前,对 AI 的产出进行批判性的审查、测试与评估。
勤勉(Diligence):在工作流中建立治理机制、防护栏以及质量检查。
委派(Delegation):明确哪些认知任务属于人类团队,哪些属于智能体。
描述(Description):以绝对清晰的方式表达意图、规则和系统行为。
辨别(Discernment):在批准通过之前,对 AI 的产出进行批判性的审查、测试与评估。
勤勉(Diligence):在工作流中建立治理机制、防护栏以及质量检查。

Anthropic 关于高效人机协作的蓝图。这种认知层面的分工为摆脱“氛围编码”、迈向专业且规范驱动(Spec-driven)的生命周期提供了结构性支柱。(图片来源:Anthropic)
新产品生命周期
当我们将 4D 框架与智能体驱动开发(Agentic SDD)相结合时,一种全新的产品生命周期便初具雏形。它不再是一条笔直的单行道,而更像是一台在战略、实验与加固之间循环往复的引擎。
我们将其称之为 SAID 框架:一个由规范意图(Specifying intent)、智能体委派(Agentic delegation)、迭代描述(Iterative description)以及人类识别与勤勉责任(human Discernment and diligence)共同构成的连续闭环。
以下是关于规范如何在 AI 时代转化为产品的具体步骤:

创造性张力(Creative tension)是指现实状况与理想愿景之间的拉伸感。早期的“发起”与“探索”阶段勾勒出了这种张力的边界,为 SAID 框架将远期愿景转化为即时、可执行的现实奠定了基础。
1.发起(Initiate):将 AI 原生方法确立为战略优先级,让团队从一开始就基于智能体进行构建,而不是将 AI 生搬硬套进陈旧的工作流中。
2.探索(Discover):梳理当前的现实状况,并找出产品现状与真正实现 AI 原生之间的痛点和摩擦。

通过将整个运营闭环(委派、描述、鉴别、尽责)紧密围绕核心规范展开,我们不再把 AI 视为一根无所不能的“魔法棒”,而是开始像管理生产系统那样去驾驭它。
3. 委派(Delegation):明确团队的运营边界。哪些认知工作由人类团队主导?哪些外包给智能体?谁拥有最终的签字批准权?
4. 描述(Description):以人类与智能体都能读懂的格式,协同编写最初的智能体驱动开发规范(Agentic SDD)。这份文档将界定目标、约束条件以及系统逻辑。
5. 识别(Discernment):在正式大规模开发启动之前,通过 Git 对初始规范进行评审、讨论与批准。
6. 勤勉(Diligence):在工作流中将治理机制、防护栏以及质量检查制度化。

健康的的产品生命周期呈同心圆结构。从最初的规范(Specs)、高互动性的原型(Prototypes)到最终交付的产品(Product),每个阶段都应当共享完全相同的系统内核。如果你的原型(A)和产品(B)正沿着各自的轨迹偏离规范,那就意味着你已经打破了 4D 链条。
7. A 环(从构想到原型):在基础打牢之后,快速运转 4D 循环:
委派实验任务。
描述即时设计意图以进行新可能性的原型制作,通过自定义工作流和 Claude 技能直接调整设计。
通过自动化评估与人类的“氛围检查”(vibe-checks)进行识别。
通过清理主规范来保持代码整洁并扩展功能,从而落实勤勉责任。
委派实验任务。
描述即时设计意图以进行新可能性的原型制作,通过自定义工作流和 Claude 技能直接调整设计。
通过自动化评估与人类的“氛围检查”(vibe-checks)进行识别。
通过清理主规范来保持代码整洁并扩展功能,从而落实勤勉责任。
8. B 环(从原型到产品):将经过验证的原型转化为生产级系统:
将运营职责委派给构建者和拓展者。
在描述需求时,将生产级安全性和本地化纳入考量。
通过真实的产品数据分析来识别发布后的性能表现,并将这些发现反馈回第 2 阶段。
通过保持高可靠性、修复 Bug 以及将 SDD 作为唯一的绝对真实数据源来落实勤勉责任。
将运营职责委派给构建者和拓展者。
在描述需求时,将生产级安全性和本地化纳入考量。
通过真实的产品数据分析来识别发布后的性能表现,并将这些发现反馈回第 2 阶段。
通过保持高可靠性、修复 Bug 以及将 SDD 作为唯一的绝对真实数据源来落实勤勉责任。

SAID 框架之所以实用,是因为它契合了 AI 原生工作的节奏。团队不再需要等待一份完美的规范才开始探索。他们的行动可以更快,但这也意味着团队必须对“什么会被采纳、什么会被抛弃、什么会被重写”保持更强的纪律性。缺乏审查的速度,不过是更快地犯错罢了。
SAID 框架展现了一个完整且现代的产品管线应有的模样。它始于最初的战略对齐(发起与探索),切入结构化的智能体执行(委派、描述、识别、勤勉),并通过迭代的同心圆轨道(规范——原型——产品)不断收敛,最终跨越鸿沟通往我们的终极愿景。它是一个以规范为核心的系统性加速器。
一张更有用的心智图景
早期的汽车是用舵柄(一种简单的杠杆)来转向的。随着时间推移,设计师们意识到方向盘才是驾驭道路时更好的心智模型。

1886 年的奔驰专利汽车(Benz Patent-Motorwagen)并没有方向盘,而是采用了一个原始的转向舵柄。如今,“氛围编码”和手动提示词就像是我们的转向舵柄。它们是粗糙、早期的控制方式,是在我们标准化现代“规范驱动开发”这一“方向盘”之前过渡性的产物。(图片来源:DaimlerChrysler)
产品团队正在经历一场类似的变革。Token(令牌)效率的压力正推动团队走向更紧密、更集成且更具规范驱动特征的工作流。
对于设计师而言,发出的行动呼吁并非放弃设计工艺。而是要去适应 Git 环境,学会将创意转化为人类与 AI 智能体都能完美执行的精准意图。
草图绘制、线框图设计和概念构思永远都很重要。但现代的产品创造者不再仅仅是那个绘制界面的人。更强大的核心技能在于塑造行为、定义约束,以及与智能体进行高效协作。
旧的流程是为移交而构建的。而新的流程则是为持续决策而构建的。这才是真正的运营变革,这也是为什么能够快速适应的团队将具备明显的竞争优势。结构正在改变,运营策略也必须随之改变。
- Anthropic. (2025). AI Fluency: Framework & Foundations [Review of AI Fluency: Framework & Foundations]. Anthropic. https://anthropic.skilljar.com/ai-fluency-framework-foundations
- Cherny, B. (2026, June 28). As engineering, product, design, DS, etc. melt into a new kind of role, I was reflecting on what roles might look like in the future. For example, when I look at the Claude Code team I see what I think is five archetypes: 1. Prototyper: Comes up with brand new ideas; churns out. X (Formerly Twitter); X. https://x.com/bcherny/status/2071379474277613732?lang=en
- Senge, P. M. (2006). The fifth discipline: The art and practice of the learning organization. Random House Business.
- Thoughtworks. (2025, December 10). Spec-driven development. Medium. https://thoughtworks.medium.com/spec-driven-development-d85995a81387
雁评
真实、有观点的好评或吐槽,欢迎分享你的使用体验。