![](https://developer.qcloudimg.com/http-save/yehe-12464096/bd4006f03198ccc54f45ab920f03f29c.png)

小七准备开个新坑，找些好用的 Skill，实测跑一跑，看看它们到底是真提效，还是 README 看起来很美。第 1 期本来想走一个经典的剧本：先让 AI 裸跑出一版“土味网页”，再挂几个 Skill 来一场改头换面。结果第一步就被 Codex 把剧本撕了——至少在这次个人主页任务里，Codex 默认做出来的页面已经挺能打。

不过准备工作都做一半了，那就换个思路（其实是偷懒🐶）：**当 Agent 本身已经具备不错的任务能力，再给它叠 Skill，还能提升什么？**

## 懒人版：这 3 个 Skill 分别管什么？

这次我们用同一个个人主页任务，连续测了 3 个 Skill。简单说就是：`设计 → 文案 → 交付检查`

![](https://developer.qcloudimg.com/http-save/yehe-12464096/e098cf38fcb394524f1189729b4c00cc.png)

下面是实测过程：

## Baseline 先验证 Codex 的默认能力

为了方便做前后对照，这次统一使用 **Codex** **CLI** 完成整个实验。Baseline 和后续 Skill 都保持同一套环境：

```Plain
OS           Windows
Codex        0.149.1
Model        GPT-5.6 Sol High
Frontend     HTML + CSS + JavaScript
Input        同一份 vic-source.md
Skill scope  Project
```

所有第三方 Skill 都只安装在当前项目的 `.agents/skills/` 下，不写入全局环境。这样每一轮尽量只增加一个变量，也避免测试 Skill 影响其他 Codex 项目。

![](https://developer.qcloudimg.com/http-save/yehe-12464096/7d15b232558be28d2a8b3730a264ec0e.png)

图 1：Codex CLI 实验环境

我们准备了一份虚构的个人资料 `vic-source.md`，里面有独立产品、摄影、播客、旅居经历，以及 ARR、用户数、播放量等数据。第一轮不给任何第三方 Skill，直接让 Codex 自己做：

```Plain
读取当前工作目录中的 input/vic-source.md。

请根据其中提供的资料，为 Vic 制作一个完整的单页个人主页，并将全部文件保存到：

outputs/00-baseline/

要求：

1. 页面使用 HTML、CSS、JavaScript 实现，可以直接在本地浏览器打开；
2. 根据你自己的默认设计判断完成页面设计；
3. 页面需要清晰呈现人物介绍、重要经历、产品/作品、关键数据、内容创作、工具/设备和社交链接；
4. 同时兼顾桌面端和移动端浏览；
5. 不得添加 vic-source.md 中不存在的人物经历、数字、产品信息或其他事实；
6. 本轮不要调用任何额外的第三方自定义 Skill；
7. 不参考其他版本，从原始资料独立完成这一版。

完成后请自行检查页面是否能够正常打开，以及是否存在明显的排版和内容错误。
```

结果比我们预期要好，Codex 选择了黑底 + 荧光黄绿色的视觉方案，还主动把：

```Plain
$42K ARR
2,800+ 用户
3.2M 摄影浏览
4 年+旅居
```

提取成独立指标。页面生成后，它继续调用浏览器检查桌面端和移动端，发现标题拥挤等问题后又修改 CSS 并重新验证。

![](https://developer.qcloudimg.com/http-save/yehe-12464096/cedae4bd600d29744a334b68fe89f03d.png)

图 2：Codex 未使用第三方 Skill 生成的 Baseline 个人主页首屏

在这次任务里，不加第三方 Skill，Codex 已经自行跑完：

```Plain
信息整理
→ 页面结构
→ 视觉设计
→ 前端实现
→ 响应式
→ 浏览器检查
→ 自我修复
```

到这里，就出现了开头提到的本期内容的思路转变：**已经会做页面的 Codex，加上专业 Skill 之后，会发生什么变化？**

## `design-taste-frontend` 给页面增加设计约束

还是在 `Project` 中，我们安装第一个 Skill `Leonxlnx/taste-skill`：

```PowerShell
npx skills add https://github.com/Leonxlnx/taste-skill `
  --skill "design-taste-frontend"
```

接着让 Codex 调用 `design-taste-frontend` 并读取同一份 `vic-source.md`，明确不参考 Baseline：

```Plain
$design-taste-frontend

读取当前工作目录中的 input/vic-source.md。

请根据其中提供的资料，为 Vic 制作一个完整的单页个人主页，并将全部文件保存到：

outputs/01-taste/

要求：

1. 页面使用 HTML、CSS、JavaScript 实现，可以直接在本地浏览器打开；
2. 请严格按照 design-taste-frontend Skill 的设计原则完成页面设计；
3. 页面需要清晰呈现人物介绍、重要经历、产品/作品、关键数据、内容创作、工具/设备和社交链接；
4. 同时兼顾桌面端和移动端浏览；
5. 不得添加 vic-source.md 中不存在的人物经历、数字、产品信息或其他事实；
6. 不参考 outputs/00-baseline，从原始资料独立完成这一版；
7. 不要主动调用其他第三方自定义 Skill。
```

两版最终走出了明显不同的设计方向。

![](https://developer.qcloudimg.com/http-save/yehe-12464096/bb467604bfac2ad68f158d61dca6a9d9.png)

![](https://developer.qcloudimg.com/http-save/yehe-12464096/939ac82daa193768a10830f25d9cc1f2.png)

图 3：Baseline 与 `design-taste-frontend` 版本首屏对比，左侧为 Codex 默认版本，右侧为 Taste 页面（支持明 / 暗主题）

Baseline 倾向于一次性‘画’一张具有视觉张力的海报，而挂载 `taste-skill` 后，Codex 更像一个懂工程规范的前端工程师——把文字、按钮、交互图片解耦，做成了可维护的双主题组件系统。

这一轮实际覆盖了更多设计与 QA 检查：

```Plain
图片与文字关系
Hero 标题换行
390px / 500px 移动端
横向溢出
深色主题
完整长页面
prefers-reduced-motion
文字对比度
```

例如，有一张生成图片直接把说明文字烘焙进了图片里，Codex 在读取 Skill 规则后主动调整成：

```Plain
图片
+
独立 HTML 文本
```

移动端标题、导航和不同视口也经过了多轮重新渲染。这一轮的变化是 **Codex 开始按照更明确的设计规则和更完整的** **QA** **流程执行任务**。

### Baseline vs `design-taste-frontend` 第一轮实验对比

![](https://developer.qcloudimg.com/http-save/yehe-12464096/87f82e3ec5b4eeb3a95c32a89c18fc75.png)

不过，也需要划清归因边界：Taste 版本同时调用了 Codex 自带的图像生成能力生成 3 张场景配图，最终页面来自 **GPT-5.6 Sol 本身的前端能力、Skill 规则、图像生成能力以及本轮** **QA** 的共同作用，不能把所有视觉变化都归因于 `design-taste-frontend`。另外，Taste 这一轮实际覆盖了更多设计与 QA 检查，执行链也明显更长。

页面基本定了，下一步只动文字。

## `humanizer` 不动页面只改文字

先尝试安装 `humanizer`：

```PowerShell
npx skills add https://github.com/blader/humanizer
```

不过安装到这里先碰到了一个安全提示，我们暂停检查了一轮，确认后才继续在 Project 中安装并测试。

### 安装 Skill 前先检查安全提示

humanizer 安装小插曲，安装器给出的安全扫描结果是：

```Plain
Gen      Safe
Socket   0 alerts
Snyk     High Risk
```

![](https://developer.qcloudimg.com/http-save/yehe-12464096/70b20ba8addea76b778108a5a2f0dfc8.png)

图 4：安装 `humanizer` 时的安全扫描截图——Gen Safe、Socket 0 alerts、Snyk High Risk

第一次看到这个结果时，我们没有继续安装，而是先取消操作，人工检查当前仓库里的 `SKILL.md`，重点确认：

```Plain
是否要求执行外部脚本
是否下载未知文件
是否上传本地数据
是否读取无关目录
是否调用额外网络服务
```

当前 `SKILL.md` 主要是文本处理规则，没有看到上述明显高风险指令，因此才决定在这个隔离的 Project 中继续测试。这里没法简单判断 Snyk 的 `High Risk` 就是误报；同时，**人工检查** **`SKILL.md`** **也不等于完成了一次完整安全审计**。

更实用的处理方式是：安全扫描出现冲突时，先确认 Skill 来源和实际指令，再根据当前任务决定是否继续安装，以及把权限限制在什么范围。测试中所有 Skill 都采用 Project 级安装，也是出于这个考虑。

搞定 `humanizer` 安装后，让 Codex 调用 Skill 执行以下指令：

```Plain
$humanizer

请基于 outputs/01-taste/ 中已经完成的个人主页，使用 humanizer Skill 优化页面中的用户可见文案。

请先将 outputs/01-taste/ 的最终交付文件完整复制到：

outputs/02-humanizer/

之后只修改 outputs/02-humanizer/。

本轮要求：

1. 只优化页面文案，不改变页面整体布局、CSS 视觉系统、组件结构和交互逻辑；
2. 使用 humanizer Skill 去除明显的 AI 写作痕迹、空洞升华、营销式表达和不自然的措辞；
3. 尽量使用具体动作、真实事实和已有数字表达人物经历；
4. 不得添加 input/vic-source.md 中不存在的事实；
5. 不要为了“更像人”而改变原始信息含义；
6. 页面整体表达保持自然、简洁，符合个人主页而不是企业宣传稿的语气。

完成后，请另外告诉我：
- 哪些文案被修改；
- 原文是什么；
- 修改后是什么；
- 为什么修改。
```

实际修改比“删掉几个 AI 高频词”更有意思：

```Plain
Before
在城市之间，做产品，也做记录。

After
在不同城市生活，做产品，也拍照。
```

```Plain
Before
过去几年，Vic 在不同城市生活，
独立完成产品、代码、摄影和播客。

After
过去几年，Vic 一边在不同城市生活，
一边做产品、写代码、拍照和录播客。
```

更多详细内容可以看下面这张图：

![](https://developer.qcloudimg.com/http-save/yehe-12464096/2639289a126a543f1a8866fb901dd86c.png)

图 5：`humanizer` 实测文案 Before / After 修改展示

这轮变化主要集中在：

```Plain
抽象名词 → 具体动作
泛化总结 → 具体事实
介绍稿语气 → 更自然的个人表达
```

数字、年份、项目名称、技术栈等已经明确的信息则基本保持原样。

在这次个人主页制作中，`humanizer` 进行了一轮**系统的文案 Review**：它会提醒 Agent 哪些地方太抽象、太模板化，但具体修改是否采用，仍然需要人工判断。

设计和文案都有了，最后看看这版页面在交付检查里会发生什么。

## `better-interface` 做交付前界面 Review

`better-interface` 会协调多个专项 Skill。我们没有把整个仓库全部安装，只选择本次 Review 需要的 7 个：

```PowerShell
npx skills add jakubkrehel/skills `
  --skill better-interface `
  --skill better-accessibility `
  --skill better-layout `
  --skill better-writing `
  --skill better-typography `
  --skill better-colors `
  --skill better-ui
```

全部采用 Project 级安装。第一次运行只 Review，不允许它自动修改：

```Plain
$better-interface

请对 outputs/02-humanizer/ 中已经完成的个人主页做一次 full interface review。

这一轮只审查，不修改任何文件。

要求：

1. 不修改 outputs/02-humanizer/ 中的 HTML、CSS、JavaScript、图片或其他文件；
2. 不复制文件到 outputs/03-final/，03-final 暂时保持为空；
3. 可以读取页面代码、原始资料和必要的 Skill，也可以使用本地浏览器做桌面端、移动端或主题检查；
4. 请按照 better-interface 的完整审查流程，重点检查：
   - Accessibility
   - Layout
   - Writing
   - Typography
   - Colors
   - UI / interaction
5. 所有问题必须基于当前实际页面，不要为了凑数量而提出修改；
6. 不要重新设计页面，也不要把纯审美偏好当成错误。

请把发现的问题分成三类：

A. 明确需要修复的问题
B. 建议优化但不影响正常使用的问题
C. 纯审美偏好或可选建议

本轮完成 Review 后停止，不要自动修复。
```

执行完成后，`better-interface` 给出了这次 Full Interface Review 的结果：

```Plain
A 明确需要修复    4
B 建议优化        4
C 纯审美偏好      0

Layout            Clear
Writing           Clear
Typography        Clear

Verdict            Block
```

这个结果还挺有意思。页面肉眼看已经没有明显问题，`better-interface` 也没有继续纠结圆角、留白这类设计选择，而是抓出了**颜色、可访问性和交互状态**上的 4 个交付问题：

![](https://developer.qcloudimg.com/http-save/yehe-12464096/9a5ac80c4aa82b767f5278f9de499cf5.png)

这些都不属于“页面好不好看”的问题，却是**肉眼浏览时很容易漏掉的交付细节**。

## 只修明确问题让 Review 从 Block 变成 PASS

到这里，4 个需要修复的问题已经明确。Review 另外还给了 4 个 B 类建议，包括 Escape 关闭移动菜单、新标签页提示、主题切换过渡和 Hover 处理。

为了继续控制变量，这一轮**只修 A1～A4，B 类建议全部保留不动**：

```Plain
基于刚才完成的 Full Interface Review，请进入修复阶段。

请先将 outputs/02-humanizer/ 的最终交付文件完整复制到：

outputs/03-final/

之后只修改 outputs/03-final/，不得修改 outputs/02-humanizer/、outputs/01-taste/ 或 outputs/00-baseline/。

本轮只修复 Review 中被归为 A 类“明确需要修复”的 4 个问题：

A1. 小字号强调色文字对比度不足
A2. 焦点环对比度不足
A3. 可见标签与 accessible name 不一致
A4. 系统主题变化后 aria-pressed 状态不同步

要求：

1. 按刚才 Review 给出的建议修复；
2. B1-B4 建议优化项本轮全部不修改；
3. 不重新设计页面；
4. 不修改已经确认正常的布局、排版、文案、图片和视觉结构；
5. 修改后重新验证 A1-A4 是否解决；
6. 最后明确列出每个问题的具体修改方式和验证结果；
7. 如果 A1-A4 全部通过，请给出新的 Review verdict。

完成后停止，不继续做额外优化。
```

修复完成后，我们重新验证了 A1～A4，4 个问题均已解决：

![](https://developer.qcloudimg.com/http-save/yehe-12464096/061d8299407538c34f23310408c27dfd.png)

按照 `better-interface` **本轮 Review 的检查口径**，最终结果变成：

```Plain
A 类问题    4 → 0

Verdict
Block → PASS
```

这里的 `PASS` 仅代表本轮 Review 已不存在 A 类阻断问题，并不等同于完成了完整的生产级可访问性认证；本次也没有额外进行真实屏幕阅读器或 Axe / Lighthouse 独立审计。

到这里，这次 Skill 实践就算正式收口了。

## 这 3 个 Skill 怎么选？

跑完整个流程后，3 个 Skill 的定位已经比较清楚：

![](https://developer.qcloudimg.com/http-save/yehe-12464096/97494b7c35719aa78a8b64cd85641366.png)

如果只是临时做一个简单个人页，现在的 Codex 默认能力已经能完成大部分工作。如果经常让 Agent 重复完成同类任务，Skill 的价值会更加明显：它可以把设计规范、写作习惯或者 Review 标准固定到 Agent 的工作流里，减少每次重新解释规则的成本。

这次实践给我们的一个明显感受是：随着模型本身能力增强，Skill 的价值开始更多体现在把专业工作方法、约束和检查流程固化给 Agent。“会不会做”已经不是唯一的问题。按什么标准做、做到什么程度、最后怎么检查，正在成为 Skill 更值得看的部分。

小七准备开个新坑，找些好用的 Skill，实测跑一跑，看看它们到底是真提效，还是 README 看起来很美。第 1 期本来想走一个经典的剧本：先让 AI 裸跑出一版“土味网页”，再挂几个 Skill 来一场改头换面。结果第一步就被 Codex 把剧本撕了——至少在这次个人主页任务里，Codex 默认做出来的页面已经挺能打。

实测推荐 3 个 Skill，轻松上手 Codex 网页设计与交付流程

小七实测3个前端Skill：`design-taste-frontend`强化设计规范与双主题支持，`humanizer`去除AI腔、优化文案自然度，`better-interface`完成可访问性等交付级审查。结果表明——当Agent基础能力已强，Skill核心价值转向固化专业标准、流程与质量门禁。

编程语言

开发工具

前端

实测3个Codex Skill：design-taste-frontend让页面从海报风变成可维护双主题组件系统；humanizer把抽象文案改成具体动作表达；better-interface抓出4个肉眼难察的对比度与交互问题，修复后Review从Block转PASS。Skill价值在于固化设计规范、写作标准与QA流程。

安全审计

代码解释

Agent

4核4G3M云服务器 新用户低至38元/年！

lighthouse

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

实测3个Codex Skill：design-taste-frontend让页面从海报风变成可维护双主题组件系统；humanizer把抽象文案改成具体动作表达；better-interface抓出4个肉眼难察的对比度与交互问题，修复后Review从Block转PASS。Skill价值在于固化设计规范、写作标准与QA流程...

实测推荐 3 个 Skill，轻松上手 Codex 网页设计与交付流程-腾讯云开发者社区-腾讯云

实测推荐 3 个 Skill，轻松上手 Codex 网页设计与交付流程

实测推荐 3 个 Skill，轻松上手 Codex 网页设计与交付流程

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐