结论先说：WordPress.com 在 2026 年 10 月 9 日发的这个案例，价值不在于「学生做得很漂亮」，而在于它把一条低预算团队也能照抄的交付流水线摆了出来——两个 UX 设计硕士生，125 小时，从用户调研、内容架构、 Figma 线框一路做到 WordPress.com 上线，中间把设计稿直接喂给 WordPress Studio 里的 AI 智能体（Studio Code）生成站点。真正值得学的不是他们用了什么工具，而是那 125 小时里只有不到一半花在「做网站」上。
一、先把事实摆清楚
这件事的参与方比标题看起来复杂，摊开看才知道它为什么能成：
| 参与方 | 角色 |
|---|---|
| Odón Solar（西班牙公益组织） | 客户。做清洁能源推广，长期缺一个像样的官网，也没预算外包 |
| Constanza Diaz 、 Axcel Paucar Garcia | 执行者。 UX 设计硕士在读，需要一段「有成品」的实习才能毕业 |
| UDIT 的 UX 硕士项目 | 学分与实习制度的来源 |
| Economistas sin Fronteras | 中间撮合方，把公益组织和学生对接起来 |
| Mariano Sarmiento | 导师，负责把关过程而不是替学生做 |
| WordPress.com + WordPress Credits | 平台与额度支持 |
注意这个结构：需求方、执行方、撮合方、平台方、把关方，五个角色齐了。缺任何一环，这类项目都会退化成「学生免费做个站练手」——而免费练手的结局通常是做完就没人维护。
二、 125 小时里，做网站只占了小半
官方给出的时间口径是 125 小时，涵盖调研、内容架构、 UX 设计、与 Odón Solar 的干系人沟通，以及在 WordPress.com 上的搭建。把这五项按常规项目经验拆一下，比例大致是这样的：
| 环节 | 大致占比 | 产出物 |
|---|---|---|
| 用户与干系人调研 | 约 25% | 访谈记录、需求清单、优先级 |
| 内容架构 | 约 20% | 站点地图、每页的信息层级 |
| UX 设计与线框 | 约 30% | Figma 文件、可点击原型 |
| 搭建与迭代 | 约 20% | 上线站点 |
| 过程文档（服务蓝图） | 约 5% | 角色、职责、交付物、决策记录 |
这个比例值得单独说一句：真正「搭站」的时间只有五分之一左右。剩下的四分之三都在搞清楚「要放什么、给谁看、按什么顺序讲」。这也解释了为什么很多用 AI 建站的人做出来的页面总觉得空——不是工具不行，是前 75% 的活没干，直接跳到了最后 20%。
三、 Figma → Studio Code：AI 智能体在这条链路里到底干什么
流程本身很朴素：学生在 Figma 里做完设计，把文件交给 Studio Code——WordPress Studio 里面向 WordPress 的 AI 智能体——再用提示词让它按设计稿迭代细节，全程不需要写代码。
这里要说清楚三件事，否则很容易误读成「 AI 一键建站」：
- 输入是设计稿，不是一句话需求。智能体拿到的是已经定好层级、间距、配色的 Figma 文件。它做的是「把已知结构翻译成区块」，而不是「替你想结构」。
- 它是迭代式的，不是一次生成。文中用的是「 prompt it to iterate on the details 」，说明是多轮微调。这更接近和设计师一起改稿，而不是按按钮出成品。
- 它输出的是 WordPress 站点，不是静态页面。这一点决定了后续可维护性——客户拿到的是一套在 WordPress 后台能自己改标题、换图、加页的站点，而不是一堆需要人来改的 HTML 。
这套「设计稿驱动」的路子，和纯代码生成的路子差别很大。前者要求设计稿本身规范（图层命名、组件复用、栅格一致），后者对输入宽容但对结果不可控。关于这两条路线的取舍，之前那篇从设计稿到代码的 AI 工作流拆得更细，这里不重复。
四、可以照着走的一套流程
- 先锁干系人，再谈设计。找客户方唯一能拍板的人，问清三件事：这个站给谁看、看完要做什么、三个月后谁维护。答不上来就先别开工。
- 把内容当结构做，不要当文案做。先定站点地图和每页的信息层级，再填字。顺序反了，后面所有排版都要重来。
- 在 Figma 里做到「规范到可以被机器读」：图层命名统一、组件复用、栅格与间距成体系。这一步决定了后面 AI 能帮上多少忙。
- 拿设计稿喂给智能体做第一版，然后只改细节、不改结构。结构问题回 Figma 改，别在生成结果上打补丁。
- 交付时附一份服务蓝图：谁负责什么、什么时候交什么、关键决策为什么这么定。这份文档的价值往往高于站点本身。
第五步最容易被跳过，也最该保留。这次项目里学生专门写了服务蓝图，记录角色、职责、交付物与决策。对新团队来说这是「下次不用从零开始」；对客户来说这是「换人也不至于推倒重来」的保险。
五、给公益组织和小团队的三条现实建议
1. 先解决「谁维护」，再解决「好不好看」
公益组织的官网最常见的死法不是做得丑，是上线半年后没人敢动。选型时把「非技术人员能不能自己改」放在第一位：能不能在后台改首页文案、换活动图、加一个新页面。这三件事做不到，再漂亮也是负债。
2. 把预算花在内容和结构上，不要花在特效上
这个案例里 125 小时有 45% 花在调研和内容架构。换算成外包报价，这部分通常最不受重视，也最影响结果。一个能让人三秒看懂「你们做什么、我能怎么参与」的朴素页面，胜过十个滚动视差效果。
3. 数据要能带走
托管平台省事，但内容和订阅列表的所有权要提前确认。6,500 篇访谈从关停平台搬回 WordPress 的那篇就是反面教材的正面解法——平台会关，导出能力才是保险。上线时就问一句：文章能不能导出成标准格式？订阅名单能不能导成 CSV？
六、 WordPress.com Education 是什么，国内读者怎么用
案例背后有个容易被忽略的计划：WordPress.com Education。符合条件的学生可以免费用 Student Plan 一年，教育者可以代全班申请，批准后每个学生激活自己的套餐、建自己的站。这次项目还叠加了 WordPress Credits 的额度支持。
对国内读者的实际意义要打个折：这个计划面向学校与在读学生，申请主体是教育机构，个人自建站基本用不上。但它的方法论是通用的——学校或培训机构完全可以照这个结构搭自己的实践项目：找一家真实的公益组织或小微企业做客户，让学生走完整流程，导师只把关不代劳，最后交付上线站点加一份服务蓝图。比起在课堂上做假命题作业，这条路对学生的作品集价值高得多。
如果你是想自己动手的小团队，把重点放在工具链上就够了：Figma 做设计、 WordPress 做承载、 AI 智能体做「设计稿到区块」的翻译。三者串起来，一个人也能跑完这条流水线。平台侧的 AI 能力这两年推进很快，WordPress Agent 把建站压到 4 分钟内那次更新就是个信号——但要注意，压掉的是执行时间，不是判断时间。
没有 Figma 基础，能直接跳到用 AI 建站吗？
能，但结果会明显打折。智能体的输出质量高度依赖输入的结构化程度——设计稿越规范，它翻译得越准；你只给一句「做个公益组织官网」，它只能给你一个通用模板，剩下的调整量可能比从头搭还大。至少要学会把页面拆成「区块 + 层级」再交给它。
公益组织该选托管平台还是自建 WordPress？
看有没有人维护。完全没人懂技术，托管平台更稳；有志愿者能碰后台，自建 WordPress 在数据所有权和长期成本上更划算。判断标准不是价格，是「半年后谁能在两小时内改好首页」。
Studio Code 是什么？和 WordPress Agent 是一回事吗？
不是。 Studio Code 是 WordPress Studio（本地开发环境）里面向 WordPress 的 AI 智能体，主打「给设计稿、生成站点」，偏开发场景；WordPress Agent 是 WordPress.com 平台侧的建站助手。两者都做建站，但一个在本地开发工具里，一个在托管平台里。
125 小时做一个官网，算快还是慢？
对一个包含调研、内容架构、 UX 设计和上线的完整项目来说，属于偏紧但合理。关键不在总时长，而在分配——如果 100 小时都在调样式、 25 小时做内容，那才叫慢。
服务蓝图（service blueprint）到底是什么，非要写吗？
一份把「谁在什么时候交付什么、为什么这么决策」写下来的文档。它不是给客户看的装饰，是给下一个接手的人看的说明书。项目越便宜、团队越流动，这份文档越值钱。
国内学生能申请 WordPress.com 的 Student Plan 吗？
这个计划面向学校与在读学生，由教育者代全班申请，主体是教育机构，个人自建站通常用不上。国内更现实的做法是用自建 WordPress 加本地开发环境练完整流程。
把 Figma 文件直接交给 AI，会不会生成一堆没法维护的代码？
取决于输出目标。如果生成的是静态 HTML，后续维护确实麻烦；如果生成的是 WordPress 区块结构，客户还能在后台自己改。选工具时先问清楚它输出什么，比问它有多快重要。
评论 (0)