How I Build This：从一个 Figma 任务开始

目录

0. 面向未来的 AI Native Product Engineer

在过去，一个新成员要真正 landing 到项目里，通常意味着一段上下文交接成本：一部分来自团队的解释，一部分来自他自己翻代码、读文档、跑命令。有人要介绍目录结构，有人要解释为什么这么拆组件，有人要说明哪些命令能跑、哪些检查必须过、哪些地方不能随便改。项目越成熟，知识越多，新人进入时需要吸收的上下文也越重。团队人数增加以后，产能未必立刻上升，沟通、同步和返工反而会先变成新的摩擦。

当 AI 开始成为开发者日常工作流的一部分，这件事有了另一种可能。一个新成员接手项目时，很可能会先把问题抛给 AI：这个功能为什么这样实现？当时有什么历史背景和取舍？项目用了什么技术栈？如果要改某个模块，应该先看哪个目录和哪几份文档？AI 会成为他 landing 到项目里的上下文入口。一套好的项目工程实践因此需要同时服务于人类开发者和 Coding Agent。目录、文档、测试、质量门禁、实现习惯和验证路径，都应该能让一个新加入的人或一个新开的 Agent session 更快理解项目，知道从哪里开始，知道怎样判断自己做得对不对。

一个更理想的状态是：新成员 landing 到项目以后，不需要先花很长时间补齐隐性上下文。他可以通过代码、文档和 AI 快速建立项目地图，然后在已有决策之上提出自己的判断。这个新成员可以是一位同事，也可以是一个新开的 Agent session；它们进入项目以后，都应该能读懂产品表面、工程约束和已有决策，然后在这些上下文之上继续推进。

要做到这一点，至少有两条线需要同时成立。

第一条线是项目工程实践。它覆盖仓库里所有真正参与交付的硬内容：目录结构、具体代码、组件、样式、内容、i18n、资产、文档、测试和质量门禁。这些内容共同沉淀成一套适合团队的最佳实践，让人类开发者和 Coding Agent 都能通过同一套材料理解项目、修改项目、验证项目。它的价值不在让项目看起来更架构化，重点是让后续每一次修改都有明确的位置、边界和判断依据。

第二条线是 Agent Harness。这里的 Harness，可以理解为一套设计 Agent 工作行为的机制：它把项目上下文、skills、tools、验证习惯和交付标准组合在一起，告诉 Agent 在一个新的 session 里应该如何理解任务、选择路径、执行实现、验证结果，并把工作结果交付给人类。它的目标是让 Agent 的自主性进入一条可验证的工程轨道。一个 Agent 需要知道项目的上下文，知道可以使用哪些 skill 和 tool，知道如何从 Figma 或需求里提取约束，也知道完成实现以后应该运行哪些检查、打开哪些页面、留下哪些证据。

当这两条线都做得足够好，一个很具体的业务场景就会出现：团队想新增一个 Landing Page，或者调整首页中的某个 section。人类开发者可以通过文档、目录和代码快速理解这项工作；Coding Agent 也可以在新的 session 里读到同样的上下文，找到同样的实现入口，跑同样的验证流程。项目交付从依赖某个人脑子里的隐性知识，转向依赖一套可以被阅读、执行和复用的系统。

在这样的工作方式里，AI Native Product Engineer 这个角色开始变得具体。TA 首先是这套系统的使用者：通过 AI、代码和文档理解项目，完成一个具体模块或页面的交付。与此同时，TA 也会持续优化这套交付系统，把上下文、文档、最佳实践和验证路径整理得更清楚，让下一次 landing 更容易。

这些想法并不是从抽象概念开始的。它们来自一次很具体的实现任务。任务材料是一份静态 Figma 视觉参考材料，来自一个收录 Awwwards 2024 网站的 Community 文件，其中 Experience 首页是需要复现的目标。真正要完成的也不只是把画面照出来，还要把一个静态页面推进成可以被评估的前端作品：它要有合理的响应式表现、必要的交互增强、面向多语言的内容组织、可验证的性能与 SEO 基础。

1. 从一个 Figma 任务开始

它不是一个带着完整设计系统、组件说明和交互注释的正式 handoff。打开文件以后，看到的是一个 Community 文件里并排放着的多组网站首页长页面，其中 Experience 这一页被指定为实现范围。它更像一份静态视觉参考材料：页面的视觉结果已经在那里，层级、节奏、颜色、图片和文字都能看见，但很多真正进入前端实现时需要的东西并不会自动出现。

比如，一个页面在 Figma 里可以是一张很长的视觉稿，但到了浏览器里，它需要在不同宽度下重新流动。按钮在视觉稿里只是一个形状和一段文字，但到了产品里，它应该有 hover、active、focus 和移动端触摸反馈。页面里的英文内容可以被照着复现，但任务同时要求多语言，这意味着内容组织不能只服务于当前这一份画面。性能和 SEO 也一样，它们不会从 Figma 图层里长出来，需要在实现时主动进入工程结构。

所以第一步并不是急着写代码。更重要的是先把任务读清楚：Figma 是视觉目标，Experience 首页是边界，最终交付物是一件可以被打开、被审视、被测试、被继续维护的前端作品。这个作品需要尊重原始视觉，也需要补上静态材料天然缺少的响应式、交互、内容、可访问性、性能和验证证据。

这也是这个任务开始变得有意思的地方。表面上，它像一次 Landing Page 复现；真正读完要求以后，它更像一个压缩过的前端交付场景。它要求开发者使用 AI，但又明确要求说明哪些部分经过了自己的判断、调整和取舍。换句话说，AI 的参与本身也变成了交付质量的一部分。生成代码并不难，难的是让 AI 的产出进入一个可被审查、可被修正、可被验证的工程过程。

因此，这个项目从一开始就不适合被当成一次一次性页面临摹。更合理的起点，是把 Figma 当作输入，把网页当作产物，把中间那套让人和 Agent 都能理解、协作和验证的过程当作真正要搭起来的系统。后面的项目结构、文档、i18n、组件边界、验证命令和浏览器复核，都是从这个判断里长出来的。

2. 开始构建项目

这一章进入真正的构建过程。它会按时间和判断推进，写他如何从空项目开始，一步一步把仓库、Harness、Figma 解读、页面实现和验证闭环搭起来。

2.1 先搭一个能继续生长的项目

这里讲早期的项目判断：应用结构、包管理、文档系统、i18n、组件边界、资产管理和质量门禁如何让项目具备可维护性。

2.2 给 Agent 留下可读的上下文

这里通过项目解释 Harness：Model、repository context、skills、tools 如何组合，让 Agent 在新的 session 里也能端到端工作。

2.3 像读需求一样读 Figma

这里讲如何检查、划定、解读 Figma 文件，并把设计稿信息转换成实现约束，同时避免把原始坐标直接当成最终布局 API。

2.4 把设计稿推进成真实页面

这里进入实际开发过程：组件、响应式布局、真实资产、本地化内容、动效、交互，以及开发中发生的具体取舍。

2.5 用验证闭环接住交付

这里讲如何验证结果：测试、质量命令、浏览器检查、视觉复核、性能反馈和部署证据如何形成闭环。

3. 它最后变成了什么

这一章收束全文：这个项目最终成为一个面向 Landing Page 工作的 Agent-ready 前端交付系统，同时也沉淀出一套可以迁移的方法。