来源：https://academy.claude.com/courses/ai-native-sdlc-playbook/requirements-and-design 读这篇之前：02 写成 intent.md 不确定：ZH 是 Clint 译官方英文课体，不是 Anthropic 中文。
本课词汇
| English | 中文 | 怎么记 |
|---|---|---|
| spec.md | 需求和设计说明 | 工程拿它做计划；人审，不人手写 |
| skills | 技能包 | 品牌、安全、合规、UX 写成 agent 会用的约束 |
| Claude Design | Claude 的设计面 | 课里标 beta，从前端 mock 再导出到 Claude Code |
| flagged concerns | 标出的顾虑 | 政策打架、做不到的地方，先给政策主人看 |
| slash command | 斜杠命令 | 把这条 prompt 固化成组织级命令 |
对照正文
产品负责人审，不写 / The product owner reviews, not writes
EN Once the product owner approves the intent.md, Claude takes it and produces a requirements and design spec. This is guided by the organization’s skills for brand, security, compliance, and UX.
ZH 产品负责人批准 intent.md 之后，Claude 拿它产出一份需求和设计 spec。由组织里品牌、安全、合规、UX 的 skills 来引导。
EN The product owner reviews that spec, but doesn’t write it. The goal of this process is to create a spec the engineering team can plan against, with flagged areas of concern.
ZH 产品负责人审这份 spec，但不写。目标是做出工程能拿来做计划的 spec，并把顾虑标出来。
EN Front-end work is the clearest example. Once the intent.md is accepted, the product owner mocks the design up in Claude Design (beta) from the intent.md, iterates on the mock, and then exports it to Claude Code to build.
ZH 前端最清楚。intent.md 被接受后，产品负责人用 Claude Design（beta）从 intent.md mock 设计，迭代 mock，再导出到 Claude Code 去建。
什么变了 / What changes
EN
| Traditional | AI-native |
|---|---|
| Requirements and design are separate phases run by separate teams. Analysts formalize the idea into requirements, and designers then parse those back into a design. The separation exists for accountability, but it is slow and lossy. | Both phases happen in a single prompted session. Claude takes intent.md and produces a requirements and design spec, constrained by the organization’s skills, with areas of concern flagged. |
ZH
| 传统 | AI-native |
|---|---|
| 需求和设计是两队跑的两段。分析师把想法写成正式需求，设计师再解析回设计。分开是为了问责，但慢，而且会丢信息。 | 两段发生在一次 prompt 会话里。Claude 拿 intent.md 产出需求和设计 spec，受组织 skills 约束，顾虑标出来。 |
怎么起步 / Getting started
EN Prerequisites: Write an intent.md file, with brand, security, compliance, and UX policies written as skills.
Infrastructure: A product owner with Claude access. No engineering skill is required.
ZH 先决条件：先有一份 intent.md，品牌、安全、合规、UX 政策写成 skills。
基础设施：产品负责人能用 Claude。不要求工程技能。
怎么做 / How to execute it
EN 1. The product owner opens a session with the organization’s skills available and attaches the intent.md.
2. The product owner’s prompt points at the intent, names the constraints, and demands flagged concerns. Run it by hand at first, then codify it as an organization-level slash command. From there make the acceptance of intent.md in the intent home the trigger, with a non-interactive job that fires on the merge, runs the pass with the organization’s skills loaded, and commits spec.md as a pull request (the CI/CD play in Stage 5: Deploy covers the plumbing). From that point the product owner’s first involvement is the review.
3. The same product owner reviews the spec against the idea. Does the spec solve the stated problem, and are the open questions from intent.md answered or carried forward?
4. Work through the flagged concerns first as they are the points an analyst would have escalated. The product owner resolves each one with its policy owner before engineering sees the spec.
5. Commit spec.md alongside intent.md. The file pair records what was asked for and what was decided.
6. The product owner decides whether the spec and intent progress to build, consulting a technical lead for anything the organization classes as higher risk. A human teammate always makes this call, and accepting the spec is what starts the plan mode play in Stage 3: Build.
ZH 1. 产品负责人开会话，组织 skills 可用，附上 intent.md。
2. prompt 指向意图、点名约束、要求标出顾虑。先手跑，再固化成组织级 slash command。再往下：意图存放处接受 intent.md 当触发，合并时跑一个非交互任务，加载组织 skills，把 spec.md 当成 PR 提交（管道见 Stage 5: Deploy 的 CI/CD 打法）。从那时起，产品负责人第一次出手就是审查。
3. 同一位产品负责人对照想法审 spec。有没有解决说出来的问题？intent.md 里的未决问题答了还是带着走？
4. 先处理标出的顾虑，那是分析师会升级的点。产品负责人和对应政策主人逐条解决，再让工程看到 spec。
5. spec.md 和 intent.md 一起提交。这对文件记录要了什么、决定了什么。
6. 产品负责人决定 spec 和 intent 是否进入构建；组织定为更高风险的，咨询技术负责人。这个电话永远是人同事打的。接受 spec，就是启动 Stage 3: Build 的 plan mode 打法。
长什么样 / What it looks like
EN The prompt:
ZH 那条 prompt：
EN
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.
ZH 读附上的 intent.md，产出一份能接到现有代码库的需求和设计 spec。用你手头的 skills，让方案符合品牌、安全和 UX。完整写成 spec.md，交给工程。凡是顾虑、尤其是互相打架的政策满足不了的，写清楚。
治理 / Governance considerations
EN Instead of policy conflicts being discovered in a review weeks later, the live policy is read and applied while the spec is written. The organization’s skills are applied as constraints on the spec. The spec, the prompt that produced it, and the skill versions in force are all logged in version control. The product owner signs off on the spec, and routes flagged concerns to the named policy owners.
ZH 政策冲突不再等几周后审查才发现，写 spec 时就读、就套正在生效的政策。组织 skills 当作 spec 的约束。spec、产出它的 prompt、当时生效的 skill 版本，都记进版本库。产品负责人在 spec 上签字，把标出的顾虑转给点名的政策主人。
怎么衡量 / How to measure it
EN Leading indicator: Elapsed time between the intent.md commit and the spec.md commit for the same change (two Git timestamps), compared with the old requirements-plus-design cycle.
Lagging indicator: Requirements rework after build starts. Count spec.md commits dated after the first plan.md commit for the same change. Git log will give this directly.
ZH 领先指标：同一改动从 intent.md 提交到 spec.md 提交的间隔（两个 Git 时间戳），跟旧的需求+设计周期比。
滞后指标：构建开始后的需求返工。数同一改动在第一份 plan.md 提交之后的 spec.md 提交。Git log 直接能给。
读完能记住的三句话
EN The product owner reviews spec.md but does not write it. Claude does, constrained by skills.
ZH 产品负责人审 spec.md，不写。Claude 写，受 skills 约束。
EN Flagged concerns go to policy owners before engineering sees the spec. ZH 标出的顾虑先给政策主人，工程再看到 spec。
EN A human always decides whether spec and intent proceed to build. ZH 进不进构建，永远是人拍板。