会“听话”的页面听起来像个营销口号但放在 AI 编码这个语境里它是非常实在的工程能力。码道这类以自然语言驱动开发的平台配合 OpenTiny 这套企业级组件体系再注入一层智能化 Skill就能让前端页面从“你手动改一行行代码”变成“你说需求页面自己变”。我最近做了一个后台管理模块的落地实验整个链路就是“码道 OpenTiny 智能化 Skill”效果比我预想的要稳得多。这篇文章把整体思路、Skill 的结构设计、指令到组件的映射规则以及我踩过的坑全部整理出来给正在做 AI 前端落地的朋友一个可参考、可复制的样本。1. 智能化 Skill 是怎么一回事前端为什么也需要它1.1 从 Claude Code、Cursor 到前端工程Skill 的本质是给 Agent 装行业知识最近 Agent Skill 在 AI 编程圈里可以说是最热的词之一不管是 Claude Code 的 skill、Cursor 的 skill、Codex 的 skill还是各种社区里的 skill 推荐、skill 开发指南、skill 编码规范大家都在讨论同一件事怎么让大模型驱动的编码 Agent 在具体项目里“懂行”。Skill 本质上是一套有结构的目录里面包含 SKILL.md 指令文件以及配套的示例代码、API 文档、约束规则。Agent 接到任务时可以按需加载对应 Skill在不做模型微调的前提下临时获得某个领域的高质量上下文。为什么这个机制对前端特别重要因为前端知识太分散了组件库的 API 版本差异、工程目录约定、类型定义、样式规范这些东西在大模型的通用训练数据里是混着来的。你直接让 Agent 写页面它很容易写出一个“看起来差不多但 API 早就弃用”的代码或者把 Vue2 和 Vue3 的写法搅在一起。Skill 干的事情就是把当前项目的“标准答案”事先整理好让 Agent 不猜、不编照着标准来。我一开始用了挺久通用提示词后来才发现把组件知识做成 Skill 才是真正省事的做法因为提示词会越积越乱Skill 是可以分目录、分版本、按需加载的。1.2 码道 OpenTiny为什么这个组合值得认真做码道是一个以自然语言为核心的开发提效平台你可以把它理解为“描述需求 → 生成代码 → 联动调试”这条链路的产品化流水线。它本身的能力在于意图理解和代码生成调度但它并不天然认识某个具体组件库需要被注入上下文才能生成真正贴合项目规范的页面代码。OpenTiny 恰好就是最值得注入的那部分上下文。OpenTiny 是华为云开源的企业级前端组件库体系核心包括跨框架的 TinyVue一套代码支持 Vue2、Vue3、TinyNGAngular 版本、TinyPro 设计规范以及 TinyEngine 低代码引擎。这套组件体系服务的场景基本都是中后台管理系统这类系统有个显著特征页面形态高度标准化表格、表单、弹窗、树、分页是绝对主力业务流程复杂但对交互形式的创新要求不高。这恰恰是智能化 Skill 最能发挥价值的地方。如果能让码道生成的页面默认走 OpenTiny 的组件规范等于把后台开发里最耗时的“组件选型、API 调用、样式统一”一次性消化掉。页面“听话”的关键其实不是 AI 本身多聪明而是它有没有一套稳定的行为准则可以依赖。这套行为准则就是我们要做的 Skill。2. 整体设计一条自然语言口令如何变成会动的页面2.1 为什么选 OpenTiny而不是自己封装一套或直接裸写我在设计阶段不是没想过直接用 Ant Design 或者 Element Plus最后定 OpenTiny 有几个非常现实的理由。第一是跨框架能力。很多公司现在处于 Vue2 向 Vue3 迁移的中间态存量项目和老项目并存。TinyVue 的核心卖点是同一套代码同时支持 Vue2 和 Vue3这意味着码道生成出来的业务组件在新老项目里可以保持一致逻辑Skill 只需要维护一份示例代码不需要为不同框架各写一套。这一点在实操里省下的工作量是很可观的。第二是企业级场景的深度沉淀。OpenTiny 的中后台组件不是简单包装像 Table 里的树形表格、列设置、跨页多选Form 里的动态表单项、联动校验这些后台开发里最磨人的细节它都给到了开箱即用的配置。Skill 在做指令到组件映射时不需要教 Agent 去拼装底层逻辑直接指向现成配置项就行。第三是可组合生态。OpenTiny 不是孤立的组件库TinyEngine 低代码引擎、TinyPro 设计规范可以和码道生成的页面无缝衔接。这意味着将来如果要把这套 Skill 复用到低代码搭建场景路径是通的不会做白工。2.2 四段链路一句话从输入到页面的完整过程码道 OpenTiny Skill 的完整链路我拆成了四个环节每个环节各司其职意图理解码道先把用户的自然语言解析成结构化意图。比如“做一个用户列表左侧按部门过滤支持搜索和分页”会被拆成页面类型列表页、数据字段用户、部门、交互行为搜索、分页、过滤、组件布局左树右表。Skill 匹配码道根据解析结果在已注册的 Skill 列表里选择 OpenTiny 页面生成 Skill把组件规范、API 映射表、示例代码注入到 Agent 的上下文窗口。代码生成Agent 结合 Skill 上下文生成 Vue 单文件组件代码、接口请求模块、以及路由配置。这个阶段 Skill 的主要作用是把“选择哪套组件 API、按什么格式写”锁定住。渲染联调生成的代码通过码道的预览环境直接渲染用户可以基于渲染结果继续下指令比如“表格加一列操作按钮”、“弹窗里的表单加一个上传控件”形成闭环。这四个环节里最容易出问题的不是第一步意图理解而是第二步和第三步的衔接。如果 Skill 里的示例代码和当前组件版本对不上Agent 就会一本正经地生成用不了的代码。所以我在设计 Skill 时把组件版本信息写死在目录说明里防止 Agent 凭记忆调用旧 API。2.3 把“规范”做成 Skill 能读懂的形态这里有个重要的设计思路我想单独说一下。很多人以为 Skill 就是一篇长长的 prompt实际上不是。SKILL.md 是入口但它后面应该挂真正的工程资产OpenTiny 组件 API 摘录、标准页面示例代码、类型定义引用、常见错误写法对照。我把这些内容拆成独立文件放在 Skill 目录里SKILL.md 只负责告诉 Agent“什么时候用这个 Skill、先看哪个文件、遇到什么情况必须遵守什么规则”。举个例子在 SKILL.md 里我会写“生成表格时必须使用 TinyVue 的 t-table 组件数据属性用 data列配置用 columns分页配置用 pagination 参数禁止自定义实现排序和筛选”而在 components 子目录里放一个完整的表格页面示例代码。Agent 读 SKILL.md 知道约束读示例代码知道落地形态两者配合生成质量基本稳定。这比全文塞一段几千字的规范要有效得多因为 Agent 对长上下文的注意力会衰减但你让它先读“约束文件”再读“示例文件”它执行的路径就很清楚。3. Skill 落地实操从目录结构到 SKILL.md 编写3.1 准备工作把 OpenTiny 常用组件的家底先摸清在动手写 Skill 之前我做了一件事把 OpenTiny 文档里中后台高频组件全部过了一遍按“组件名、核心 API、典型用法、版本差异”四个维度整理成表格。这一步没法省因为 Skill 的质量上限取决于你喂给 Agent 的资料质量。我整理的时候发现几个容易踩的细节。第一TinyVue 在老项目和 Vue3 新项目里引入方式不同Skill 里必须同时给出兼容写法。第二OpenTiny 的 Table 组件有很多增强能力比如交互式列设置、树表结构、斑马纹这些能力如果不写进 SkillAgent 大概率会倾向于用基础的 el-table 风格写法白白浪费组件优势。第三表单校验和支持 v-model 的自定义校验规则这种隐藏能力文档里写得散需要你自己在示例里提炼。准备阶段我会额外确认当前项目锁定的 OpenTiny 版本号比如使用 TinyVue ^3.14 还是某个固定版本并把版本号写进 SKILL.md 的 frontmatter 区域。这样后续如果组件 API 更新我可以直接新建 Skill 版本不影响已在使用的旧流程。3.2 标准目录结构与 SKILL.md 核心模板我建议一个 Skill 目录至少包含四个部分SKILL.md入口文件声明 Skill 的用途、适用条件、触发规则。references/放组件 API 精要、最佳实践说明、常见错误对照。examples/放可直接复制的完整示例代码按场景划分。templates/放页面级模板比如标准列表页、标准表单页、标准弹窗确认流程。下面是我在码道里注册的一个 OpenTiny 页面生成 Skill 的 SKILL.md 示例结构可以直接抄--- name: opentiny-page-generator description: 基于 OpenTiny TinyVue 生成企业级中后台页面。适用于列表页、表单页、弹窗、树表联动、数据看板等场景。当用户需求涉及表格分页、搜索筛选、表单校验、树结构展示时优先使用本 Skill。 allowed-tools: read, write, edit, bash version: 1.0.0 opentiny-version: tinyvue ^3.14 --- # OpenTiny 页面生成 Skill ## 触发条件 - 用户描述的页面属于中后台管理类型 - 涉及表格、表单、弹窗、树、分页、筛选等组件 ## 核心约束 1. 所有页面必须使用 OpenTiny TinyVue 组件禁止使用其他组件库混搭。 2. 表格统一使用 t-table列配置使用 columns 数组分页使用 pagination 配置项。 3. 表单统一使用 t-form表单项使用 t-form-item校验规则使用 Form 的 rules 配置。 4. 交互弹窗使用 t-dialog禁止自行封装遮罩层。 5. 组件引入方式优先使用全量引入如项目已配置按需引入则补全对应 import 语句。 6. 样式统一使用组件内置主题禁止在页面内自定义覆盖主色。 ## 使用步骤 1. 先读取 references/component-api.md 确认组件核心 API。 2. 再阅读 examples/tinyvue-list-page.vue 了解标准列表页结构。 3. 根据用户指令优先复用 examples 中的骨架代码。 4. 生成代码后检查是否有遗漏的 import 语句和类型定义。 ## 注意 - 如果用户需求涉及的数据结构不明确先给出字段假设等待用户确认。 - 不要擅自引入额外的第三方依赖比如日期库、请求库。 - 表格操作列统一以“操作”命名宽度建议 160px。3.3 示例代码的质量决定了生成质量的上限SKILL.md 是约束examples 才是真正的生产力。我写示例代码时有几个原则分享出来供你参考。第一个原则是“完整可运行”。“可运行”的意思不是代码能编译而是能把一个真实页面全部跑通。我的列表页示例里包含组件引入、接口请求、表格列配置、分页处理、搜索表单、删除确认弹窗所有逻辑闭环。这样 Agent 在生成新页面时能直接把它当成骨架而不是从零开始拼。第二个原则是“场景优先”。我按后台最常出现的场景做了分类数据列表、数据表单、树表联动、数据看板、结果反馈页。每个场景一个示例文件而不是按组件粒度拆十几个零散片段。因为 Agent 理解“一个页面应该这样搭”比理解“一个按钮应该这样写”要难得多页面级示例正好补上这个认知。第三个原则是“刻意留注释”。我的示例代码里会写关键注释比如“这里的分页参数需要与后端接口保持一致”这能让 Agent 生成新代码时自动带上同样严谨的注释习惯。实测下来留注释的示例比不留注释的示例生成的代码在可维护性上明显高一个档次。3.4 在码道平台注册 Skill 并完成冒烟测试Skill 目录准备好之后接入码道的过程不算复杂但有一个关键动作把所有文件路径在 SKILL.md 里写清楚让码道的 Agent 能正确索引。我的做法是在 references 目录里放一个 index.md汇总所有文件的路径和建议阅读顺序避免了 Agent 自己去翻目录。冒烟测试我建议准备一套固定的测试指令集至少覆盖五类场景“生成一个用户管理列表页支持搜索、分页、批量删除”“在列表页基础上升级左侧加部门树点击树节点过滤表格”“生成一个新增用户表单包含姓名、手机号、部门下拉、头像上传”“把表单里的手机号校验改成自定义规则校验运营商号段”“表格加操作列包含编辑和删除删除前弹窗二次确认”测试时重点盯三类问题组件 API 是否使用正确、import 语句是否完整、布局和交互是否符合中后台习惯。只要这五类场景能稳定通过Skill 就算真正可以交付了。4. 让页面真正“听话”的交互机制与实测记录4.1 指令到组件的映射规则“听话”的本质是把用户零散的语言表达映射到一组稳定的组件组合上。我整理了基础映射表Agent 在执行时按这张表做组件决策用户指令特征映射组件关键配置列表、表格、数据展示t-tablecolumns、pagination、loading搜索、筛选、条件查询t-form t-table表单内联布局表单项与查询参数绑定左侧树 右侧列表t-tree t-table树点击事件驱动列表查询参数新增、编辑、详情弹窗t-dialog t-formdialog 宽度按表单内容自适应批量操作、多选t-table row-selection跨页选中需开启保留选中配置状态展示、标签t-tag t-badge状态色统一使用主题色板反馈、确认、提示t-message / t-modal破坏性操作强制二次确认这张表我直接放进了 references/component-api.mdAgent 在生成代码前会先过一遍映射逻辑而不是凭感觉猜组件。实测下来有了这张表之后组件选错率下降得非常明显。4.2 典型指令实测记录我在真实项目里跑了一批指令这里挑三条有代表性的记录指令一“生成一个商品列表页顶部是搜索区按名称和状态筛选下面是表格展示商品编码、名称、分类、价格、状态分页展示有批量上下架操作。”生成的代码骨架很标准搜索区用的 t-form内联布局两个 t-input 加一个状态选择表格用的 t-table列宽设置合理操作列包含“上架”“下架”两个按钮和二次确认。整个生成加渲染大概四十秒我手动调整的只有价格列的格式化逻辑其余直接可用。指令二“左侧放一个分类树右侧展示分类下的商品表格点击树的子节点表格自动按分类过滤。”这条指令的挑战在于数据联动。Skill 示例里正好有树表联动场景Agent 直接复用了点击事件处理逻辑把 tree 的 node-click 事件与表格查询参数绑定生成结果没有出现逻辑断层。这验证了“页面级示例 映射表”组合策略的价值。指令三“表单里手机号字段做校验要求是 1 开头的 11 位数字提示‘请输入正确的手机号’。”这条指令比较简单但很能说明问题。Agent 没有自己去写正则而是查了 Skill 里的自定义校验示例生成了带 pattern 和 message 的规则配置。虽然它没有用更细的号段校验但基础格式校验已经达标符合中后台常规要求。4.3 复杂场景多组件联动的边界在哪里实测中我发现指令越复杂Skill 的约束价值越大但用户的表达也越容易歧义。比如“表格里加一列进度条”这种表达Agent 可能会用 t-progress 组件独立渲染也可能期望用表格的 customRender 插槽。这种细节歧义光靠 Skill 解决不了我会在映射表里补充一条规则涉及表格自定义单元格渲染时统一使用 columns 中的自定义渲染函数并在 examples 里给出一个带进度条、标签、图片缩略图的定制单元格示例。另外一个比较棘手的是“接口字段未知”的场景。用户说“生成订单列表页”但没人告诉 Agent 订单接口返回了什么字段。我的处理方式是让 Skill 强制要求 Agent 给出字段假设表并在页面顶部标注“接口字段待确认”注释。这样生成的代码不是完美成品但完全可继续迭代而且没有悄悄编造字段避免了后端联调时的大面积返工。这条规则写进 SKILL.md 之后生成质量稳定性提升了很多。5. 常见问题与排查技巧实录5.1 高频问题速查表整个链路跑下来我遇到的最典型问题集中在五类整理成速查表便于你对照排查问题现象可能原因排查方法生成的代码引用了不存在的组件属性Skill 中 API 摘录太粗Agent 靠记忆补全补全 references 中的组件 API 精要锁定版本号import 语句缺失示例代码没有强调引入路径在 SKILL.md 中写入全量引入与按需引入两套规范树表联动失效事件名写错或示例缺失联动场景在 examples 中增加树表联动完整示例写明事件绑定方式接口字段错误用户表达不完整Agent 自行假设强制 Skill 生成“字段假设表”与真实接口核对后再固化样式与设计规范偏离缺少主题和布局约束在约束中加入禁止自定义主色、统一内联表单宽度等硬性规则生成耗时过长或上下文超限Skill 文件过多导致无效加载用 index.md 规划阅读路径减少 Agent 翻找成本5.2 三个避坑心得第一个心得Skill 别贪大按场景拆版本比做一个“全能 Skill”靠谱得多。我一开始试图把 OpenTiny 所有组件全部写进一个 Skill结果 Agent 每次都要读大量无关内容生成速度慢还容易被不相关的示例带偏。后来拆成“页面生成”和“组件定制”两个 Skill核心场景交给页面生成 Skill特殊场景再单独加载效果立刻改善。第二个心得示例代码是长期资产值得花时间精修。SKILL.md 是 Agent 的导航examples 才是它真正抄作业的答案本。我每次修正一个生成错误都会反哺到示例代码里比如发现 Agent 生成的批量删除确认逻辑不够严谨就直接把完整逻辑写进示例下一次它就不会再犯同样的错。这个迭代模式比简单地修改提示词有效得多。第三个心得一定要让 Agent 在生成代码后自检 import 语句和 API 版本。这个问题在刚开始高频出现表面原因是示例代码没有覆盖完整深层原因是 Agent 对“组件全量引入后还需要单独 import 吗”存在认知混淆。我后来在 SKILL.md 里强制要求生成代码后执行一次自检列表包括 import 完整性、组件名与属性名大小写、以及分页参数与接口的对接方式这类低级错误几乎清零了。5.3 想更进一步Skill 与低代码、跨团队复用的扩展思路这次实验跑通之后我还有一个明显感受OpenTiny Skill 的价值不止于码道这个入口。因为 Skill 的形态是标准的目录加文档它可以被其他支持 Skill 机制的 Agent 复用也可以在没有 Agent 的场景下作为团队的前端开发规范文档使用。更进一步如果和 OpenTiny 的 TinyEngine 低代码引擎结合这套 Skill 里沉淀出的组件映射规则还能直接指导低代码搭建平台的组件编排逻辑让“代码生成”和“拖拽搭建”两套体系共享同一套组件语义。我个人在实际操作中的体会是智能化 Skill 的难点从来不在“怎么写提示词”而在于你能不能把领域知识整理成结构化的、Agent 真正容易消费的形态。码道负责的是意图到代码的执行链路OpenTiny 负责的是企业级页面的标准底座Skill 负责的是连接这两者的行业知识。三者配合页面会“听话”就不再是演示时的花活而是一条能真正放进日常工作流的提效路径。最后再分享一个小技巧每个 Skill 目录里放一个 CHANGELOG.md每次改动都记录版本和原因几个月后回看你会清楚地知道哪些策略有效、哪些规则反而限制了生成质量这对 Skill 的持续迭代非常有帮助。