# A Guide to Agent-Native Product Design
**作者**: rico
**日期**: 2026-05-05T11:15:24.000Z
**来源**: [https://x.com/_heyrico/status/2051621781363188219](https://x.com/_heyrico/status/2051621781363188219)
---
The job of a product designer in 2026 has split in two.
There is the version that still treats Figma as the primary deliverable, runs design reviews on Tuesdays, hands files to engineers on Fridays, and spends 80 percent of the week pushing pixels.
Then there is the agent-native version. Agents do most of the production. The designer plans the strategy, dispatches the work, reviews the diffs, and ships the live URL. The week looks nothing like the old one.
Both versions still exist. One of them is going to be unrecognizable in twelve months.
Here is what agent-native product design actually looks like in practice, the four artifacts every designer should be building right now, and the one habit that ties the whole thing together.
## The shape of the work has changed
Marcus Moretti at Every wrote the cleanest summary of this shift for product management: software development used to be 20 percent planning and 80 percent execution. Agent-native work is 80 percent planning and 20 percent execution. The same flip is happening in product design, and most designers have not noticed yet.
20%” stack against a heavier “80%
Old design loop: brief, sketch, mockup, refine, hand off, wait, review the build, cycle. Five days minimum.
New design loop: write the strategy, write the design system file, dispatch the screen, review the PR, ship the URL. Five hours, sometimes less.
The reason the new loop is shorter is not the agent. It is the artifacts. Every minute spent writing strategy.md and design.md is a minute that compounds across every screen the agent generates after that.
If you skip the artifacts, you spend the same five days, with worse output, because the agent is guessing what you mean.
## The four artifacts every agent-native designer ships first
Before the first prompt. Before the first Figma file. Four documents at the root of every project. Each one is short. Each one earns back its time within a week.
1. The strategy.md.
One page. Five sections. Target problem, approach, who it is for, key metrics, tracks. The skeleton comes from Richard Rumelt's Good Strategy Bad Strategy by way of Every's compound engineering plugin, but the principle is older than that.
Without strategy.md, the agent has no idea what success looks like for your product. With it, every dispatched task inherits the same purpose. Tracks become real workstreams. Personas become real constraints. The metric becomes a real bar.
A useful test. If you cannot say what the product's target metric is in one sentence, you are not ready to dispatch a screen.
2. The design.md.
The visual brain. Brand voice, color tokens, typography scale, spacing scale, component anatomy, accessibility rules, dark mode. One page. Fifty lines max. Negative constraints carry as much weight as positive ones. "Never use a gradient" is sharper than "use solid colors."
Every agent in your stack reads this file. Cursor, Claude Code, Codex, v0, Lovable, Figma Make. The output of all of them looks like your brand because they all read the same source of truth.
The honest unlock. Writing your design.md forces you to make taste decisions you have been avoiding for two years. The forty minutes it takes to write the file is the most productive forty minutes a designer can spend in 2026.
3. The CLAUDE.md (or AGENTS.md).
The structural brain. What the codebase is, what frameworks it uses, what conventions matter, what the agent should refuse to do. design.md owns visual rules. CLAUDE.md owns everything else.
Some teams collapse them into one. Bigger teams keep them split. Either is fine. The point is that both files exist, both are committed to git, and both are read on every agent run.
4. The product-pulse routine.
The feedback loop. A scheduled task that pulls metrics from your analytics tool, errors from your tracing tool, conversions from your billing system, and writes a one-page report to a markdown file every morning.
Without a pulse, you ship blind. With one, every design decision lands in a memory the agent can read on the next run. Last week's drop in onboarding completion shows up in tomorrow's planning. The system gets sharper every cycle.
You do not need fancy dashboards. A folder of dated markdown files beats every BI tool a designer has ever ignored.
## The new design loop, step by step
Five steps. Each one ships a real screen. Total time, an afternoon.
Step 1, plan in the strategy file, not in your head.
Open strategy.md. Confirm the track this screen belongs to. Confirm the metric it is meant to move. If the strategy file does not mention this work, something is off. Either update strategy.md or drop the task.
The discipline of running every screen through the strategy file kills more bad work than any design review meeting ever did.
Step 2, write the brief like a product spec.
Three sentences. Who the screen is for. What outcome it produces. What the visual style is. Five minutes. Same brief format every time.
Beginners skip this. Senior designers never do. The brief is the work.
Step 3, dispatch one well-scoped task.
Open Cursor, Claude Code, Codex, or whatever your agent of choice is. Paste the brief. Reference design.md and strategy.md explicitly in the prompt. Ask for a plan first. Read the plan. Approve it.
Then walk away.
The agent reads the strategy, reads the design system, reads the existing components, scaffolds the screen, runs the tests, opens a pull request. The whole thing takes ten to thirty minutes depending on scope.
Step 4, review the PR like a senior reviews a junior.
Open the diff. Look at the screenshots. Click through the preview deploy. Comment on what is off. The agent picks up the comments and revises. Two or three rounds and the screen is ready.
Approvals stop being events. They become a continuous review surface. The Tuesday design review meeting evaporates because the review is happening in the PR all week.
Step 5, ship the URL and log it in the pulse.
Merge. Deploy. The screen goes live. Tomorrow morning's pulse will tell you whether the metric moved. The next planning cycle starts with that data, not with a fresh whiteboard.
## What this looks like at the team level
Three changes worth pushing through this quarter, even if you only ship them on a side project first.
1. Run the strategy interview every quarter.
Not the all-day offsite version. The forty-minute version where you sit with an agent, get interviewed through the five sections, and update strategy.md. The compound engineering plugin's /ce:strategy is one way to run it. A custom prompt in any chat tool is another.
The point is not the format. The point is that the strategy is current, written down, and read by every agent your team uses.
2. Make the PR the design review surface.
Every dispatched screen opens as a draft pull request with screenshots at three breakpoints. Every designer on the team gets tagged automatically. Comments are timestamped, threaded, and addressable. The diff is the artifact.
This is the single biggest change to design ops nobody has fully shipped yet. The teams that get there first run their design org at twice the speed of everyone else.
3. Add an agent persona to your design system.
Treat the agent as a user with its own needs. Document what it reads, what it can call, what it tends to get wrong. The agent persona sits next to the human personas in your design system documentation. The components it consumes are documented in machine-legible form.
This is the work that gets missed in every "AI-augmented designer" pitch. The augmented designer treats the agent as a tool. The agent-native designer treats it as a user, a collaborator, and a junior team member, all at once.
## The pitfalls that look like progress
A clean numbered list of the traps designers fall into in the first month.
1. Generating fifty options and picking one. That is curation, not design. The agent did the work and you signed your name on it. Always run a critique pass on the agent's output. Ask it to argue against itself.
2. Skipping the artifacts because they feel like overhead. They are not overhead. They are the leverage. Every minute on strategy.md and design.md compounds across every screen the agent ships.
3. Letting the agent invent components. If you do not point at existing primitives, the agent will scaffold a new Button every time. Always seed the prompt with: "Use existing components from /components. Do not invent new primitives."
4. Treating the strategy file as a one-time exercise. The strategy is alive. It updates as the product learns. A strategy.md that has not been touched in three months is probably wrong.
5. Running one agent. Run several. Cursor for the screen you are designing live. Codex for the maintenance task you dispatched yesterday. Claude Code for the audit you are walking away from now. The native designer runs the team. The augmented designer picks one tool and forces every problem through it.
## The bigger frame
Agent-native product design is not a new tool. It is a new operating model. The artifacts are the system. The agents are the workforce. The designer is the strategist who sets direction, defines the bar, and ships the URL.
Every week you wait to start is a week your competition is compounding. The strategy file you write today gets sharper next month. The design.md gets richer every project. The pulse gets denser every morning. The work makes itself easier.
That is the whole pitch. The discipline of writing things down compounds. The discipline of dispatching well-scoped tasks compounds. The discipline of reviewing PRs compounds.
The designers who get good at this in 2026 are going to look like they have a small team behind them. The honest answer is they do. The team is a fleet of agents reading the same set of artifacts.
Open a new folder tonight. Write strategy.md. Write design.md. Dispatch one screen. Review the PR. Merge. Ship the URL.
That is day one of agent-native product design. There is no certification. There is no badge. There are only the things you have shipped, and the speed at which you ship the next one.
Get to it.
## 相关链接
- [rico](https://x.com/_heyrico)
- [@_heyrico](https://x.com/_heyrico)
- [8.4K](https://x.com/_heyrico/status/2051621781363188219/analytics)
- [Marcus Moretti](https://every.to/@marcus_fd8302_1)
- [strategy.md](http://strategy.md/)
- [strategy.md](http://strategy.md/)
- [design.md](http://design.md/)
- [strategy.md](http://strategy.md/)
- [strategy.md](http://strategy.md/)
- [strategy.md](http://strategy.md/)
- [design.md](http://design.md/)
- [strategy.md](http://strategy.md/)
- [design.md](http://design.md/)
- [Upgrade to Premium](https://x.com/i/premium_sign_up)
- [7:15 PM · May 5, 2026](https://x.com/_heyrico/status/2051621781363188219)
- [8,468 Views](https://x.com/_heyrico/status/2051621781363188219/analytics)
---
*导出时间: 2026/5/6 00:18:21*
---
## 中文翻译
# 原生代理产品设计指南
**作者**: rico
**日期**: 2026-05-05T11:15:24.000Z
**来源**: [https://x.com/_heyrico/status/2051621781363188219](https://x.com/_heyrico/status/2051621781363188219)
---
到 2026 年，产品设计师的工作已经一分为二。
一种是依然将 Figma 视为主要交付物的版本：周二进行设计评审，周五将文件移交给工程师，一周中 80% 的时间都在推像素。
然后是原生代理（Agent-native）版本。代理完成了大部分生产工作。设计师负责规划策略、分发任务、审查差异代码，并发布上线的 URL。这一周的工作面貌与过去截然不同。
这两种版本目前依然共存。但其中一种在十二个月后将会变得面目全非。
以下是原生代理产品设计在实践中的真实面貌，每一位设计师现在都应该构建的四种产物，以及将这一切串联起来的一个习惯。
## 工作的形态已发生改变
Every 公司的 Marcus Moretti 就产品管理领域的这一转变写出了最清晰的总结：软件开发过去是 20% 的规划和 80% 的执行。原生代理工作则是 80% 的规划和 20% 的执行。产品设计领域正在发生同样的翻转，而大多数设计师尚未察觉。
旧的设计循环：简报、草图、模型、细化、移交、等待、审查构建、循环。最少五天。
新的设计循环：编写策略、编写设计系统文件、分发屏幕、审查 PR（Pull Request）、发布 URL。五小时，有时更少。
新循环之所以更短，原因不在于代理，而在于产物。在编写 `strategy.md` 和 `design.md` 上花费的每一分钟，都会在代理随后生成的每一个屏幕上产生复利效应。
如果你跳过这些产物，你将花费同样的五天时间，且产出更糟，因为代理只能靠猜测来理解你的意图。
## 每个原生代理设计师首先应交付的四种产物
在第一个提示词之前。在第一个 Figma 文件之前。每个项目根目录下的四个文档。每一个都很简短。每一个都能在一周内收回其时间成本。
1. **The strategy.md（策略文档）**
一页纸。五个部分。目标问题、方法、适用对象、关键指标、轨道。骨架源自 Richard Rumelt 的《好战略，坏战略》，经由 Every 的 compound engineering 插件演绎，但其原理比这更古老。
没有 `strategy.md`，代理根本不知道你的产品成功是什么样子的。有了它，每一个分发的任务都继承着相同的目标。轨道变成了真正的工作流。用户画像变成了真正的约束。指标变成了真正的门槛。
一个有用的测试：如果你无法用一句话说出产品的目标指标，你就还没准备好分发一个屏幕任务。
2. **The design.md（设计文档）**
视觉大脑。品牌语调、颜色标记、排版比例、间距比例、组件解剖、无障碍规则、深色模式。一页纸。最多 50 行。负面约束与正面约束同等重要。“永远不要使用渐变”比“使用纯色”更明确。
你栈中的每个代理都会读取这个文件。Cursor、Claude Code、Codex、v0、Lovable、Figma Make。它们所有的输出看起来都像你的品牌，因为它们读取的都是同一个真理之源。
诚实的解锁时刻：编写你的 `design.md` 会迫使你做出那些逃避了两年的审美决策。编写这文件所需的四十分钟是 2026 年设计师能度过的最高效的四十分钟。
3. **The CLAUDE.md (or AGENTS.md)**
结构大脑。代码库是什么、使用什么框架、哪些约定重要、代理应该拒绝做什么。`design.md` 拥有视觉规则。`CLAUDE.md` 拥有其他一切。
有些团队将它们合并为一个。大型团队则保持分开。两者皆可。重点是两个文件都存在，都提交到 git，并且在每次代理运行时都被读取。
4. **The product-pulse routine（产品脉搏例行程序）**
反馈循环。一个定时任务，每天早上从你的分析工具中提取指标，从追踪工具中提取错误，从计费系统中提取转化率，并将一份一页的报告写入 markdown 文件。
没有脉搏，你就是盲目发布。有了它，每一个设计决策都会记录在记忆中，代理可以在下一次运行时读取。上周引导完成率的下降会出现在明天的规划中。系统在每个周期都会变得更敏锐。
你不需要花哨的仪表盘。一个装有日期标记的 markdown 文件的文件夹，胜过设计师曾经忽略过的每一个 BI 工具。
## 新的设计循环，一步步来
五个步骤。每一步都产出一个真实的屏幕。总耗时：一个下午。
**第一步，在策略文件中规划，而不是在你的脑子里。**
打开 `strategy.md`。确认该屏幕所属的轨道。确认它旨在提升的指标。如果策略文件中没有提到这项工作，那就有些不对劲了。要么更新 `strategy.md`，要么放弃这项任务。
让每个屏幕都经过策略文件筛选的这种纪律，比任何设计评审会议都能扼杀更多的劣质工作。
**第二步，像写产品规格说明书一样写简报。**
三句话。屏幕是为谁服务的。它产生什么结果。视觉风格是什么。五分钟。每次都使用相同的简报格式。
初学者会跳过这一步。资深设计师从不这样做。简报就是工作本身。
**第三步，分发一个范围明确的任务。**
打开 Cursor、Claude Code、Codex 或你选择的任何代理。粘贴简报。在提示词中明确引用 `design.md` 和 `strategy.md`。先索要一个计划。阅读计划。批准它。
然后走开。
代理读取策略、读取设计系统、读取现有组件、搭建屏幕、运行测试、打开拉取请求。整个过程根据范围需要十到三十分钟。
**第四步，像资深人员审查初级人员一样审查 PR。**
打开差异代码。查看截图。点击预览部署。评论哪里不对。代理接收评论并修改。两到三轮后，屏幕就准备好了。
批准不再是一个个孤立的事件。它们变成了一个连续的审查界面。周二的设计评审会议消失了，因为审查整周都在 PR 中进行。
**第五步，发布 URL 并将其记录在脉搏中。**
合并。部署。屏幕上线。第二天早上的脉搏会告诉你指标是否移动了。下一个规划周期始于这些数据，而不是一块崭新的白板。
## 这在团队层面是什么样子的
三个值得在本季度推动的改变，即使你首先只在副业项目上发布它们。
1. **每季度进行一次策略访谈。**
不是那种全天外出闭关的版本。而是 40 分钟的版本，你与一个代理坐在一起，通过五个部分接受访谈，并更新 `strategy.md`。Compound engineering 插件的 `/ce:strategy` 是运行它的一种方式。任何聊天工具中的自定义提示词是另一种。
重点不在于格式。重点在于策略是最新的、写下来的，并被你团队使用的每个代理读取。
2. **将 PR 作为设计评审界面。**
每个分发的屏幕都以带有三个断点截图的草稿拉取请求形式打开。团队中的每个设计师都会自动被标记。评论带有时间戳、线程化且可定位。差异代码就是产物。
这是设计运营中最大的单一变化，尚未有人完全实现。率先做到这一点的团队，其设计组织的运行速度是其他人的两倍。
3. **向你的设计系统添加一个代理人设。**
将代理视为一个有其自身需求的用户。记录它读取什么、它可以调用什么、它容易在哪里出错。代理人设位于设计系统文档中的人类人设旁边。它消费的组件以机器可读的形式被记录。
这是每个“AI 增强设计师”宣传中被忽略的工作。增强型设计师将代理视为工具。原生代理设计师则同时将其视为用户、协作者和初级团队成员。
## 那些看似进步的陷阱
设计师在第一个月容易陷入的陷阱清单，编号清晰。
1. **生成 50 个选项然后选一个。** 那是策展，不是设计。代理完成了工作，你只是签了名。始终对代理的输出进行批评审查。让它自我反驳。
2. **跳过产物，因为感觉像是额外负担。** 它们不是负担。它们是杠杆。在 `strategy.md` 和 `design.md` 上的每一分钟都会在代理发布的每个屏幕上产生复利。
3. **让代理发明组件。** 如果你不指向现有的基元，代理每次都会搭建一个新的 Button。始终用以下内容为提示词做铺垫：“使用 `/components` 中的现有组件。不要发明新的基元。”
4. **将策略文件视为一次性练习。** 策略是活的。它随着产品的学习而更新。一份三个月没动过的 `strategy.md` 可能是错的。
5. **只运行一个代理。** 运行几个。Cursor 用于你正在实时设计的屏幕。Codex 用于你昨天分发的维护任务。Claude Code 用于你现在要离开去做的审计。原生设计师管理的是团队。增强型设计师挑选一个工具并强制每个问题都通过它来解决。
## 更大的框架
原生代理产品设计不是一种新工具。它是一种新的运营模型。产物是系统。代理是劳动力。设计师是设定方向、定义标准并发布 URL 的战略家。
你每等待一周开始，你的竞争对手就多一周的复利增长。你今天写的策略文件下个月会更敏锐。`design.md` 会随着每个项目变得更丰富。脉搏每天早上都会变得更密集。工作会让它自己变得更容易。
这就是全部要点。把事情写下来的纪律会产生复利。分发范围明确任务的纪律会产生复利。审查 PR 的纪律会产生复利。
在 2026 年擅长此道的设计师看起来就像背后有一个小团队。诚实的回答是他们确实有。这个团队是一群读取同一套产物的代理机群。
今晚新建一个文件夹。编写 `strategy.md`。编写 `design.md`。分发一个屏幕。审查 PR。合并。发布 URL。
这就是原生代理产品设计的第一天。没有认证。没有徽章。只有你发布的东西，以及你发布下一个东西的速度。
开始吧。
## 相关链接
- [rico](https://x.com/_heyrico)
- [@_heyrico](https://x.com/_heyrico)
- [8.4K](https://x.com/_heyrico/status/2051621781363188219/analytics)
- [Marcus Moretti](https://every.to/@marcus_fd8302_1)
- [strategy.md](http://strategy.md/)
- [strategy.md](http://strategy.md/)
- [design.md](http://design.md/)
- [strategy.md](http://strategy.md/)
- [strategy.md](http://strategy.md/)
- [strategy.md](http://strategy.md/)
- [design.md](http://design.md/)
- [strategy.md](http://strategy.md/)
- [design.md](http://design.md/)
- [Upgrade to Premium](https://x.com/i/premium_sign_up)
- [7:15 PM · May 5, 2026](https://x.com/_heyrico/status/2051621781363188219)
- [8,468 Views](https://x.com/_heyrico/status/2051621781363188219/analytics)
---
*导出时间: 2026/5/6 00:18:21*