【AI原生研发转型·第3篇】需求与设计合体：一次会话出spec.md

系列导语本系列基于 Anthropic《The AI-Native SDLC Playbook》改写保留 Claude Code / Claude Tag / MCP 等原品牌名。第 2 篇讲了用intent.md钉死意图这篇看第二阶段Design为什么要把需求和设计压缩成一次会话。《The AI-Native SDLC Playbook》相关文章链接https://blog.csdn.net/justlookxia/article/details/164093318你有没有过这种经历分析师花两周写了份 spec评审时才发现和安全策略冲突又得推倒重来传统把需求和设计分开是为了问责——谁写的、谁负责。但代价是慢而且信息在转手时损耗。AI-native 的解法很直接让需求和设计在同一次会话里一起长出来。传统痛点分离 慢 损耗需求归产品、设计归架构/分析师中间靠文档接力。等设计评审往往已经几周之后冲突、遗漏全在后期才暴露返工成本最高。AI-native 做法单会话压缩skills 当约束在 AI-native 流程里产品负责人审 spec 而不写 spec。他带着intent.md开一次会话让 Claude 直接产出需求 设计规格同时用机构的skills品牌规范、安全策略、合规、UX 标准当约束让方案一出生就长在标准里。前端场景有个现成例子Claude Design (beta)能从intent.md直接生成 UI mock再导出给 Claude Code 去构建。需求、设计、实现一条线打通。关键点策略不是在几周后的评审里被发现冲突而是在写的时候就被skills 应用并校验。凡是满足不了的矛盾策略Claude 会显式标成关切点areas of concern交给人拍板。先决条件已提交的intent.md品牌 / 安全 / 合规 / UX 类skills封装成SKILL.md一份能直接抄的提示词Read the attached intent.md and produce a requirements and design spec for integrating it into our existing codebase. Apply the skills available to you so the plan conforms to our brand guidelines, security policies and UX standards. Document the spec fully as spec.md, ready to hand to the engineering team. Describe clearly any areas of concern, especially where you cannot satisfy contradicting policies.流程附上intent.md开会话 → 提示产出 spec 并标关切 → 产品负责人审 → 解决关切 → 提交spec.md→ 由人决定是否进 Build。怎么知道转成功了领先指标intent.md到spec.md的提交时差越短越好。滞后指标构建之后的需求返工量——也就是spec.md晚于首个plan.md提交了多少次。返工越少说明这次合体越干净。下篇预告第 4 篇Build没有被接受的计划就不写码。看plan.md、机构知识怎么存进CLAUDE.md和 skills、以及构建期的 hooks 护栏。系列文快链【AI原生研发转型·第1篇】为什么你的AI写码很快团队却还是慢【AI原生研发转型·第2篇】想法不该等人写文档用intent.md把意图一次性钉死【AI原生研发转型·第3篇】需求与设计合体一次会话出spec.md【AI原生研发转型·第4篇】没有计划不写码机构知识变成文件【AI原生研发转型·第5篇】让agent自己先验收反馈回路持续evals【AI原生研发转型·第6篇】人审不过来让agent先审分层评审hooks批准门07-08待发布原文出处https://claude.com/blog/the-ai-native-sdlc-playbook Louis Claxton, 2026-08-21, Anthropic系列索引① 总论 · ② Plan · ③ Design本篇· ④ Build · ⑤ Test · ⑥ Deploy · ⑦ Maintain · ⑧ 番外本系列为外部技术博客的改写保留原品牌名仅供团队学习交流。