openClaw这波热度，最近一直压在我前端交流群的置顶位置。群里的讨论从“它到底怎么部署”一路滑到“前端是不是要被AI Agent干掉了”。先说结论：openClaw不是又一个聊天机器人壳子，而是一个能本地一键部署、能接Teams、能拽进Obsidian、能用一堆skills干活的个人AI自动化平台。它真正在改变的不是哪一行代码，而是前端工程师手里的活儿——过去我们写页面给人看，接下来还得写“能力”给AI调用。这篇文章我想用一次真实的落地过程，把它对前端的影响拆开讲清楚，不管你是刚入门不久的新人，还是带团队的技术负责人，看完应该能明白接下来该往哪个方向使劲。

1. 先想清楚一件事：OpenClaw到底动了前端的哪块蛋糕

1.1 它不只是一个聊天机器人，而是把“对话即执行”变成默认能力

很多前端朋友看到openClaw的第一反应是：这不就是套壳对话界面吗？UI比我写的后台还简单，有什么好慌的。这种判断其实忽略了核心。

openClaw的火爆和普通AI聊天应用不一样的地方在于，它的设计重心不是“陪你聊天”，而是“帮你干活”。从部署方式也能看出来，大家搜的都是openclaw ubuntu安装教程、openclaw本地一键部署、openclaw配置阿里云服务器免费试用这类关键词，说明大量用户是把它当成基础设施在用的。它挂在本地、连上自己的数据源和工具，然后通过一个个skills扩展能力。所谓skills，本质就是一段可以被大模型调用的能力插件，你告诉Agent“今天有哪些任务”，它自己拆解、调skill、给结果。

这跟传统前端项目完全是两个物种。传统前端面向的是“人”：人要点击按钮、要看视觉反馈、要等数据渲染。而openClaw这种Agent平台面向的是“意图”：它接收一句话，然后自己决定调什么、执行什么。前端如果只懂页面渲染，在这套体系里自然觉得哪里不对，因为过去我们所有的技术积累都是围绕“人机交互”建立的，现在突然要面向“模型调用”重新设计东西了。

它本身也需要界面来展示对话、展示工具执行状态、展示agent的思考过程，这些界面恰恰是前端工程师最该做的。很多人看到的是威胁，我看到的是一整块还没被占满的“AI可交互界面”市场。

1.2 前端和OpenClaw的三种交集方式

我把目前前端圈子里真正被openClaw影响的路径梳理成三条，分别对应三种不同的工作方式。

第一条是“用”：前端开发者自己把openClaw当成开发助手。写代码时让它帮忙解释一段不熟悉的DOM逻辑，让它生成一个正则，或者让它把一段console日志整理成报告。这种用法影响最小，本质上只是多了个效率工具。

第二条是“封装”：前端把自己业务系统的能力包装成skills，让openClaw能调用。以我接触的团队为例，他们做的是一个内部订单管理后台，过去前端的工作是写订单查询页、状态筛选器、导出按钮。现在换成openClaw的思路后，前端不再把重心放在“做一整套页面”，而是把“查订单”“筛状态”“生成报表”分别写成可独立调用的接口能力，通过skill描述文件告诉Agent：这个能力是干什么的、需要什么参数、返回什么结构。用户直接在IM工具里问一句“帮我查一下昨天华东区的异常订单”，Agent去调接口、把结果吐回来。页面还在，但页面从“唯一入口”降级成了“可视化出口之一”。

第三条是“改造”：把现有前端应用改造成能被Agent引导、被AI驱动、甚至能反向调用AI能力的形态。典型场景就是企业内部知识库助手、运维工单助手、数据问答大屏。前端的活儿变成了设计人机协同的工作台：AI能做的操作自动执行，AI不能做的再转到人工确认，整个前端界面从“数据表格堆叠”变成“对话流+数据卡片+操作指派”。

这三天条路径没有哪一条是把前端消灭掉的，它们共同的特点是：前端的核心产出从“页面”变成了“能力入口”，从“一次性开发”变成了“持续可被调用的服务”。这一点想不明白，后面做所有技术方案都会走弯路。

1.3 前端工程师正在从“画手”变成“能力封装者”

我甚至觉得，openClaw流行之后，前端岗位描述里“熟练使用Vue/React”的重要性会逐年下降，而“能把业务逻辑抽象成结构化接口并配置给AI调用”会成为更有区分度的能力。

原因不复杂。在openClaw这类平台里，前端面对的“用户”有两个：一个是最终的人类用户，另一个是大模型。大模型不是看页面漂不漂亮来评分，它只看你的skill描述规不规范、参数schema定义清不清晰、返回数据是不是稳定可解析。换句话说，前端在Agent体系里的工作，很大一部分是“接口设计”。

这恰好是前端一直不太重视、但其实具备优势的地方。做B端系统的前端，天天跟接口联调、跟后端扯字段、处理各种状态分支，对接口语义、数据结构、异常情况已经很敏感了。把这些经验迁移到“设计一个AI可调用的能力包”上，比让后端来做人机界面的成本低得多。所以我的判断是：openClaw不会让前端失业，而是会把“会写页面但不懂能力抽象”的那批人淘汰掉。

2. 开发模型的变化：从写页面到写能力

2.1 Skills就是“能被AI调用的函数”，前端本来就擅长这件事

先把skills这个概念说透。我的理解是，它类似浏览器插件的机制，也像一个npm包，但它被调用的方式不是“用户点击”，而是“大模型根据意图选择并触发”。至少我目前接触到的skill定义方式，大致包含三块：描述文件（说明这个skill是干嘛的、入参是什么、出参是什么）、执行脚本（实际干活的逻辑）、返回结果（多数情况是结构化JSON）。

如果你写过Vue组件，其实不难映射：组件props就是skill的入参，组件emit出去的事件就是skill的返回值，组件本身干的事就是执行逻辑。只不过以前调用者是人和父组件，现在调用者是大模型而已。

这也是为什么openClaw相关的热词里会出现“前端开发skills”“前端传参”“前端组件库”这一类搜索。大家发现，把一个能力做成可配置参数、可复用、可组合的形态，这件事前端从做组件第一天起就在练了。你写过table组件，知道要把列配置、数据源、分页行为抽象成props；你写过上传组件，知道要处理回调、进度、异常分支。这些经验放到skill设计上，底层逻辑几乎是一模一样的。

2.2 实操示例：一个网页截图检查Skill，前端可以怎么设计

光说概念不够，我拿一个实际场景走一遍：假设企业内部想通过openClaw做页面巡检，每天检查几个核心页面的布局是不是正常、有没有控制台报错、首屏加载是不是超时。这个能力如果做成前端页面，你需要写脚本、写任务列表、写定时触发、写结果通知。但在openClaw体系里，你只需要写一个“页面截图检查”skill，让Agent在对话里就能驱动它。

先定义入参，这块我习惯用类似JSON Schema的方式：

name: web_page_inspect description: 检查指定页面的渲染状态、截图并返回关键指标，用于页面巡检和视觉回归。 parameters: type: object properties: url: type: string description: 待检查页面的完整URL viewport_width: type: integer default: 1280 description: 模拟浏览器窗口宽度 check_selector: type: string description: "需要确认存在的核心元素选择器，如 #root" required: - url

注意description不是写给用户看的，是写给大模型看的，所以要把触发条件、边界情况说清楚。比如如果URL不可达，脚本应该返回什么错误码，而不是让模型瞎猜。

执行逻辑我用Node写一个最小示例，熟悉Puppeteer的都是这个套路：

export async function run(params) { const { url, viewportWidth = 1280, checkSelector } = params; const browser = await chromium.launch({ headless: true }); const page = await browser.newPage(); await page.setViewport({ width: viewportWidth, height: 800 }); const errors = []; page.on('console', (msg) => { if (msg.type() === 'error') errors.push(msg.text()); }); const start = Date.now(); await page.goto(url, { waitUntil: 'networkidle2', timeout: 20000 }); const loadTime = Date.now() - start; const shot = await page.screenshot({ fullPage: true }); const visible = checkSelector ? await page.$(checkSelector) !== null : true; await browser.close(); return { loadTime, visible, hasConsoleErrors: errors.length > 0, consoleErrors: errors.slice(0, 5), screenshot: shot.toString('base64') }; }

这段代码里最关键的两个设计：第一，截图用base64返回而不是存到某个固定路径，原因是Agent拿到结果后可能要继续传给其他工具或模型分析，自包含的返回省掉一堆路径依赖问题；第二，显式返回console错误信息，这样大模型能进一步判断“页面有没有问题、问题方向是脚本报错还是资源加载失败”。

写完skill之后，你会发现自己的角色已经变了。以前你把同样逻辑写在一个页面里，用户自己打开、自己点、自己看，现在你把它变成了一个“可供任何对话调用”的能力单元。这就是“从写页面到写能力”最直观的差别。

2.3 业务页面要开始适应“AI会来调用”这件事

openClaw接入Obsidian、Teams这类用法越来越常见之后，前端工程师还要面对一个比较隐蔽的问题：现有页面本身也在被AI“看”。

什么意思？比如openClaw要通过skill去读取你后台某个列表页的数据，它不会像人一样去看可视化表格，它可能直接请求你页面背后的数据接口。如果接口返回字段混乱、错误码含义模糊、分页参数难以理解，Agent的skill写得再漂亮也白搭。

所以前端在做新功能时，不能再只考虑“人打开浏览器能不能看懂”，还要考虑“一个自动化脚本能不能稳定地调用”。我给自己团队定的几个改造原则很简单但很管用：

• 接口返回宁可字段多一点，也不要让同一个字段在不同接口里叫不同名字；
• 错误信息必须机器可读，统一用结构化code，而不是把“服务器开小差”直接塞给调用方；
• 给内部工具类页面增加一个只读数据出口，绕过DOM，让Agent直接拿JSON数据，不要让它去解析表格。

一开始团队觉得这是在给别人做嫁衣，后来发现收益很快显现出来。openClaw在回答用户问题时，表达能力不再受制于人机界面的“可读性”，知识库问答准确率明显提升，因为数据链路干净了。前端页面反而更敢做视觉优化，反正AI拿到的是结构化数据，页面只管把结果渲染好，两边互不拖后腿。

这个过程也会改变前端的“UE”思维。以前讲前端UE，说的是用户体感、交互动线、视觉层级；现在还要多一条“AI UE”，也就是大模型作为用户时的体验：描述够不够清晰、参数合理不合理、返回稳不稳定。前端ue是什么这个热搜词，未来可能真的会长出这样一个分支。

2.4 动态配置免打包不是玄学，是元数据驱动

热门搜索里有一组词很能说明问题：“前端动态配置不用重新打包编译”。传统思路下，前端改一个页面字段、加一个按钮、换一套筛选条件，都要走开发、发版、上线。如果业务方隔三差五提小需求，前端团队就会被版本发布拖死。

openClaw这类Agent平台催生了一种新的可能：能力的增删改走配置，界面渲染交给通用组件。我做过一个实验，把一张卡片组件做成“配置驱动”：

• 前端只维护一个通用的EntityCard组件，它不关心业务字段是什么，而是接收一段配置，按配置渲染标题、字段、动作按钮；
• 业务配置存放在后端或本地JSON里，前端启动时拉取；
• openClaw需要新增一个数据卡片时，不写任何前端代码，直接在skill返回结果里附带一段“渲染指令”，前端解析后动态生成卡片。

配置结构大概是：

{ "cardTitle": "异常订单", "fields": [ { "label": "订单号", "key": "orderId", "type": "text" }, { "label": "金额", "key": "amount", "type": "currency" }, { "label": "状态", "key": "status", "type": "tag", "colorMap": { "pending": "orange", "done": "green" } } ], "actions": [ { "label": "查看详情", "type": "link", "url": "/order/${orderId}" } ] }

前端代码一行没改，卡片就从“只有订单号”变成“订单号+金额+状态标签+详情按钮”。这套机制的价值在于，AI理解业务需求后，自己就能产出一份新配置，前端重新拉取配置即完成“发布”。

当然，完全免打包是不现实的，但把所有硬编码业务字段抽成“元数据+渲染器”的模式，在Agent时代一定是个大方向。因为Agent的输出天然是结构化的，如果能和前端渲染层约定好一套schema，就等于给AI装了一只“可绘制的手”，它生成的东西不需要再走一遍传统开发排期。前端工程师在这个环节的战略价值，就是把这套schema定得足够好用、足够有扩展性。

3. 企业落地拆解：本地Agent + 前端的最短实现路径

3.1 需求与整体架构：员工问知识库，Agent去干活

理论说多了容易飘，还是回到一个可以直接复现的企业场景。假设你要给团队做一个知识库问答助手，希望员工打开内部网页就能问“报销流程是什么”“新员工怎么配电脑”“合同审批找谁盖章”，同时还要让这些问答能追溯到具体文档，不能像通用大模型那样瞎编。

方案里引入openClaw的出发点很明确：它本地部署、数据可控、能通过skills统一对接内部知识库和工单系统。架构上我是这么拆的：

前端工作台（Vue/React 对话界面） ↓ 用户提问,发起流式请求 OpenClaw Agent 服务 ↓ 根据问题选择并调用skill 知识库检索Skill（读取内部文档/向量库） 内部接口Skill（查询工单/人员/流程） ↓ 返回结构化结果并附带来源 前端渲染对话流 + 数据卡片

这个链路里，前端不是简单做一个聊天框，而是做一个“Agent工作台”。用户看到的页面，左侧是对话历史，中间是流式输出，右侧是Agent每一步的执行状态和来源文档。这种感觉就像把一辆车的仪表盘、方向盘和发动机拆开重新排布，页面负责把Agent的“思考”透明化，用户不再对着黑盒提问。

3.2 前端要做的三件事：对话UI、流式对接、卡片渲染

第一件是对话UI。不推荐直接套一个现成聊天组件，因为Agent场景下的消息类型比普通聊天复杂：要有文本、工具调用状态、错误提示、数据卡片、来源引用。消息模型建议统一成类似这样的结构：

{ role: 'assistant', type: 'text' | 'tool_call' | 'tool_result' | 'data_card' | 'error', content: '...', meta: { toolName: 'knowledge_search', duration: 230, status: 'success' } }

前端根据type渲染不同组件，消息历史里才能既有文字又有操作痕迹，而不是一锅粥。

第二件是流式对接。openClaw服务端开一个对话接口，前端用fetch加ReadableStream逐段解析，避免用户等待模型完整输出后才看到结果。最小实现我推荐直接处理SSE协议：

const response = await fetch('/api/agent/run', { method: 'POST', headers: { 'Content-Type': 'application/json' }, body: JSON.stringify({ conversationId: this.conversationId, message: this.input, enabledSkills: ['knowledge_search', 'internal_api'] }) }); const reader = response.body.getReader(); const decoder = new TextDecoder('utf-8'); let buffer = ''; while (true) { const { done, value } = await reader.read(); if (done) break; buffer += decoder.decode(value, { stream: true }); const lines = buffer.split('\n'); buffer = lines.pop() || ''; for (const line of lines) { if (line.startsWith('data:')) { const event = JSON.parse(line.slice(5)); this.pushMessage(event); // 逐条追加到对话流 } } }

这一步最大的作用是把“等待时间”变成“阅读时间”，用户看着模型“边想边说”，体感上比白屏转圈好太多。一定要用流式，不用的话体验完全两个档次。

第三件是卡片渲染。Agent回答如果只是纯文本，信息密度是不够的，比如它告诉你“三条异常订单”，用户还是不知道具体是哪些。我让skill在返回时约定一个card_schema字段，前端拿到后自动匹配渲染组件。前面提到的EntityCard就是一个例子。再复杂一点，可以让卡片里嵌入一个iframe加载大屏局部图表，实现“对话入口+可视化出口”的混合体验。

这三件事做完，前端在项目里的角色就非常清楚了：我们不是给AI做壳，我们是在定义“AI与人协作时信息如何呈现”。

3.3 从Teams到Obsidian：入口渠道本质上是另一种“前端”

热搜词里“openclaw 如何接入microsoft teams”“openclaw obsidian”都在问入口渠道。前端不要觉得这是运维的事，入口渠道其实就是“不同的前端外壳”。

Teams里，Agent会以一个Bot身份出现，用户不用打开你的网页，直接在IM里和AI对话。这时候前端的“页面”就不是网页了，而是Teams卡片。卡片要写清楚意图按钮、显示操作结果、支持用户确认动作，比如“报销流程已生成，点击确认提交”。发送频率、消息截断、权限范围这些限制也和网页完全不同。

Obsidian更像个人知识库场景。用户把openClaw接入Obsidian后，可以直接在笔记里让Agent整理摘要、生成双链、汇总某主题下的所有笔记。前端在这类场景里的发力点是提供一套“笔记卡片”渲染规则，让Agent返回的内容能优雅地嵌入Markdown瀑布流里。

我个人的经验是：不要为每个入口各写一套逻辑，而是把Agent的核心能力做成一个独立服务，Teams、Obsidian、Web工作台都只是入口壳。前端维护一套通用交互组件，再为不同平台写一层轻量适配器，成本是最低的。这样就算明天又多了一个新入口，你也不需要重做一遍业务逻辑。

3.4 部署联调阶段容易踩的坑

这部分都是我在本地折腾时真正遇到的问题，写下来帮后来人省时间。

第一个坑是localhost。前端跑在浏览器里，如果openClaw服务端跑在本地容器里，前端页面访问api地址千万不能用localhost，要用局域网IP，否则容器内外网络不通。特别是如果你用了Docker Compose部署，端口映射虽然做了，但localhost指向的是容器自己，不是宿主浏览器。

第二个坑是CORS。openClaw服务默认不一定会给你开放跨域访问，前端直接fetch会报跨域错误。需要在服务端配置allowedOrigins，把前端应用地址加白名单。开发环境还要留意预检请求，浏览器会先发OPTIONS，接口得能正确响应，不然控制台一直在报错你还会以为是接口挂了。

第三个坑是上下文长度。Agent如果一次检索知识库塞进太多文档，输出很快会“忘记”前面的内容，表现为越到后面回答越偏。解决方案是检索时做chunk切分和摘要，而不是把全文一股脑丢给模型。前端在这件事上能配合的是：在调用接口时显式传conversationId，让服务端做会话管理，并支持用户一键清空上下文。

第四个坑是返回字段不一致。不同skill是我写了不同同事写的，字段命名风格不统一，前端渲染组件经常报undefined。后来我强制要求所有skill返回统一schema：data、meta、error三件套，data再按业务细分。前端做防御性渲染，即使字段缺失也只降级展示，不让整个卡片崩溃。

4. 技能树与面试风向：前端下一步该补什么

4.1 2026年的前端面试题，重心在变

前端面试题2026、前端面试题2026及答案、2026 react 前端面试掘金这些词已经说明大家开始预判趋势了。以前面试前端问的是闭包、原型链、手写防抖节流、浏览器渲染机制，这些基础当然还是重要，但增量部分已经明显偏AI工程化。

我最近帮朋友模拟面试，发现出题人的兴趣点转移到这些方向了：

• 如果要在页面里集成AI助手，消息是流式返回的，你会怎么设计前端状态管理？
• 如何把现有后台系统改造成AI可调用的服务？从接口、权限、数据结构三个角度说。
• 大模型返回的Markdown和JSON混合内容，怎么设计渲染器才不容易XSS又保持扩展性？
• 如果Agent调用一个工具耗时很久，前端怎么反馈、怎么取消、怎么恢复？
• 你怎么设计一个“AI操作可审计”的前端界面？

这些问题没有标准答案，考的是有没有真正在Agent场景里写过代码。以前背八股能混过面试，现在面试官会追问“你的前端组件如何被一个非人类用户调用”，答不上来就很尴尬。

我当时整理这套问题的感受是：前端的基础能力没有作废，但组织和呈现方式在变。闭包、异步、原型链这些东西是地基，地基上方长出来的楼，从“管理页面状态”变成了“管理AI交互流”。

4.2 前端需要补的新技能清单

我给团队列过一个对照表，不是让大家扔掉老本行，而是在老本行上面叠一层Agent时代的技能：

表格里最后一行容易被忽略。AI引入后，代码仓库里不仅要管前端代码，还要管skills描述文件、提示词模板、不同模型的调用参数。这类文件需要版本化、评审、回滚，否则Agent行为失控时根本无从排查。前端工程师如果懂工程化，接管这部分会非常顺手。

我还会推荐有精力的人去了解一点向量检索的基础概念。它不需要你写算法，但你要知道为什么搜“报销流程”和“差旅报销规范”会返回不同文档，以及如何把检索结果截断、加权、排序后塞给模型。懂了这个，你设计的前端展示才有依据。

4.3 大屏、数字孪生、worker：老场景被Agent重新激活

很多人觉得大屏可视化、数字孪生、web worker处理大文件这些方向跟前端AI趋势没关系，其实关系比想象中近得多。

大屏可视化的传统痛点是指标配置复杂，想看一个数据要层层点菜单。有了openClaw这类Agent后，用户可以直接说“给我看一下华北区的销售趋势，按周聚合，顺便标出异常峰值”。Agent负责查数、生成图表配置，前端大屏接收配置、实时渲染。前端要做的不是给每个图表写定制逻辑，而是把常见图表收敛成“配置可控、数据驱动”的组件，Agent只需要输出标准化option，大屏立刻就能画图。

数字孪生网站同理。以前数字孪生场景里设备状态、告警明细靠人自己去翻，现在Agent可以主动查询设备状态，前端孪生场景根据Agent返回结果高亮异常点位。比如车间里某台设备温度过高，Agent给出原因和处置建议，前端在三维场景里把设备标红并弹出处理按钮，整个运维体验上了一个台阶。

web worker处理大文件这个场景更实在。前端要上传超大文件，如果用传统方式，主线程会卡顿，用户根本没法继续操作。用worker做切片、计算hash、断点续传的交互，配合Agent还可以更进一步：让Agent生成上传策略、自动重试失败分片、汇报上传进度。前端只需要把worker事件暴露给Agent，Agent就能接管操作。类似的思路还能延伸到音视频流处理、本地推理等场景。

这些老场景被重提，不是因为它们之前不重要，而是Agent给了它们一个统一的交互入口。前端如果手里还握着这些硬技能，不但不吃亏，反而更容易做出差异化的Agent应用。

5. 入坑阶段常见问题速查与行动路线

5.1 部署和联调问题速查表

很多人卡在第一步不是能力问题，是踩坑太花时间。我把高频问题汇总成一张表，按经验概率排序：

这些坑其实不新鲜，前端在传统联调时代也踩过类似的，只是换了个壳。调试思路不变：先确认网络通不通，再确认数据对不对，最后看渲染层有没有兜底。

从部署方式来看，openClaw在Ubuntu上本地一键部署是最主流的路径，用一个干净的Ubuntu容器或云服务器，跑Docker Compose拉起整套服务。Windows开发机建议用WSL2或Docker Desktop，注意文件挂载路径和端口占用。阿里云这类云服务器免费试用也常见，但买来之后第一件事是改默认密码、只开放必要端口，Agent服务本身不带鉴权的话一定套一层网关，别裸奔到公网。

5.2 把业务接口封装成Skill的注意点

封装是最容易见效的切入点，但很多人写着写着就变味儿了，把skill写成了一个“巨无霸接口”。我自己的几条纪律可以分享：

• 一个skill只做一件原子事。比如“查订单”和“根据订单号生成对账单”要拆开，不要塞进同一个skill。大模型对“职责单一”的函数理解最准，描述也好写。
• 参数宁少勿多。skill入参每多一个字段，大模型选错参数的概率就高一分。能用三个参数解决的，不要用六个。
• 返回一定是结构化JSON。不要返回一段拼接好的文本让AI再解析一遍，那样既多一次出错机会，也浪费token。
• 错误码要具体。不要只返回“failed”，要返回“ORDER_NOT_FOUND”“API_TIMEOUT”“UNAUTHORIZED”这类可行动的错误码，模型才能给出有意义的补救建议。

还有一点容易被忽略：鉴权。skill本质上是把内部接口暴露给了一个能自然语言调用的Agent，权限控制必须做好。不要让一个内部查询skill成为“任何人都能调”的裸奔接口，哪怕Agent部署在本地，也要按最小权限原则配置访问范围。前端做配置面板时，最好把“skill可用范围”“调用白名单”“操作审计日志”这几个字段做成显性选项，而不是逼着运维去改配置文件。

5.3 给前端的新手行动路线

如果你现在想快速切入openClaw这个方向，我给一条“三天路线”，不需要一上来就啃完整个技术栈。

第一天，跑通本地部署。找一台能跑Ubuntu的机器或云服务器，按openclaw的官方文档做本地一键部署，目标只有一个：能在本地打开它的Web界面，和它对话。这一步的重点不是搞懂每个配置项，而是亲手建立“部署、启动、日志、重启”的肌肉记忆。

第二天，写一个最简单的skill。建议不要选太复杂的业务，先做一个“网页标题采集”：给Agent一个URL，它返回这个页面的title、description、重点标签。这个skill逻辑简单，但足够让你理解描述文件、参数校验、执行脚本、返回结构四条链路是怎么回事。写完后试着让Agent换个URL再调一次，观察它是怎么理解参数的。

第三天，把自己最熟的一个业务接口封装成skill。如果你是做电商后台的，就封装“查订单详情”；做内容平台的，就封装“根据关键词搜文章”。让Agent通过对话完成一次真实查询，再尝试让你写的前端工作台调用它。到这里，你已经完整走了一遍“Agent+前端”的闭环，之后再回头看各种架构文章，会顺畅非常多。

我个人强烈建议走一趟这个闭环，因为看十篇分析都不如自己跑通一次。很多恐惧来自未知，亲手做一遍之后就会发现，openClaw带来的不是“前端要不要改行”的问题，而是“前端能力边界可以扩展到多宽”的问题。

我自己在这套东西折腾下来最深的体会是：前端不是被AI取代，而是多了个麻烦但很有潜力的“新用户”。这个用户不看视觉效果，只看接口规不规范、参数符不符合schema、返回数据能不能稳定解析。做openClaw的skills，本质上就是在做一次极端的“用户需求分析”，只不过这个用户是个不带感情的大模型。想验证我说的，别只看文章，按照第三节那套流程，拿家里的旧电脑装个Ubuntu，本地把openClaw跑起来，再把自己最熟的一个业务接口包成skill，感受一次“对话即调用”的完整链路。跑通之后你再回头看现在的项目，很多以前觉得理所当然的前端工作量，其实都可以换个方式重新设计。