1. Codex 网页设计交付流程里Skill 到底解决什么问题Codex 现在默认的前端能力已经不算弱。我拿同一份个人资料做过对照不给任何第三方 Skill直接让 Codex CLI 读input/vic-source.md它自己就能跑完信息整理、页面结构、视觉设计、响应式适配甚至调用浏览器检查桌面端和移动端发现标题拥挤后回头改 CSS 再验证。黑底加荧光黄绿的方案把$42K ARR、2,800 用户、3.2M 摄影浏览提成独立指标这些都不是我教的。所以问题就变成了Agent 已经会做页面再叠 Skill 还能提升什么我的实测结论是Skill 提升的不是会不会做而是按什么标准做、做到什么程度、最后怎么检查。这三个 Skill 分别卡在交付流程的三个节点上design-taste-frontend给页面加设计约束把画一张海报变成搭一套可维护的组件系统humanizer只动文案不动页面去掉 AI 写作痕迹和空洞升华better-interface交付前做界面 Review抓出肉眼容易漏掉的可访问性和交互状态问题适合谁看这篇已经在用 Codex CLI 做前端、想让输出更稳定的人被 AI 文案的在城市之间做产品也做记录这类句子尬到过的人以及每次交付前都要手动检查对比度、焦点环、aria 状态的强迫症选手。不适合谁只想让 AI 随便生成一个静态页、不打算复用工作流的人。这种情况下 Codex 默认能力就够了装 Skill 反而增加变量。整条链路我用 TaoToken 统一 Key 接入一个 API Key 跑通模型调用省得在多个平台之间切来切去。下面按前置准备 → 配置 → 验证 → 排障的顺序拆开讲每一步都能直接复制。2. TaoToken 统一 Key 前置准备与 Codex 环境接入先说清楚为什么要用统一 Key。Codex CLI 这类工具在跑 Skill 的时候一次任务里可能触发多轮模型调用读资料、生成页面、调浏览器检查、根据 Review 结果修复。如果每换一个模型或工具就换一套鉴权配置会散得到处都是。TaoToken 的做法是给你一个 Base URL 加一个 Key模型 ID 按需切换Codex 侧只认这一套。官网入口在 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content API 地址是 https://taotoken.net/api 注意 API 地址不带 UTM 参数配置的时候别把查询串带进去。前置准备分三步。第一步拿 Key。进控制台创建 API Key路径是 https://taotoken.net/console?utm_sourcetaotoken_aicg_blog_endutm_contentconsoleutm_campaignrewrite 创建完复制出来只显示一次。如果你还没想好模型可以先去模型对话页 https://taotoken.net/chat?utm_sourcetaotoken_aicg_blog_endutm_contentmodel-chatutm_campaignrewrite 试一下同一个 Key 能不能正常出结果确认通道没问题再往 Codex 里配。第二步确认 Codex CLI 版本。我这次用的是 Codex 0.149.1模型走 GPT-5.6 Sol High。版本差异会影响配置文件位置先codex --version看一眼。低于 0.140 的建议先升级老版本的 auth 处理和新版不一致容易在排障时误判。第三步决定 Skill 的安装范围。所有第三方 Skill 我都装在当前项目的.agents/skills/下不写全局。原因很实际每轮只增加一个变量避免测试 Skill 污染其他 Codex 项目。Project 级安装还有个好处删项目目录就等于清理干净不留残留。环境变量这块Codex 支持从 shell 读也支持写进配置文件。我倾向写配置文件因为 Skill 执行时可能起子进程环境变量不一定继承得到。下面第三节给完整片段。有一点要提醒TaoToken 在这里的角色是统一的模型调用通道不是替代 Codex 或编辑器。Codex 还是那个 CodexSkill 还是那些 SkillTaoToken 只是让鉴权和模型切换这件事收敛到一个 Key 上。3. 可复制的 Skill 配置片段与 Codex 调用示例这一节是全文最该抄的部分。配置分两块Codex 侧的模型接入和 Skill 侧的安装与调用。先看 Codex 的模型接入配置。Codex CLI 的配置目录在用户主目录下的.codex/里面有个config.toml。把下面这段按你的实际路径填进去# ~/.codex/config.toml model gpt-5.6-sol model_provider taotoken [model_providers.taotoken] name TaoToken base_url https://taotoken.net/api env_key TAOTOKEN_API_KEY wire_api chatbase_url一定写https://taotoken.net/api不要带任何查询参数。env_key指向环境变量名Key 本身不写进配置文件避免误提交。然后设置环境变量。Windows PowerShell 用$env:TAOTOKEN_API_KEY sk-你的KeymacOS 或 Linux 用export TAOTOKEN_API_KEYsk-你的Key想持久化就写进 shell 的 profile 文件或者 Windows 的系统环境变量面板。如果你用的是 Codex 的auth.json方式部分版本走这个结构是这样{ OPENAI_API_KEY: sk-你的Key, OPENAI_BASE_URL: https://taotoken.net/api }三件套对齐检查Base URL 是https://taotoken.net/apiKey 是控制台创建的那串Model ID 是gpt-5.6-sol。这三个任何一个错位都会在下一节验证时报错。Skill 安装。三个 Skill 都走npx skills addProject 级# 设计约束 npx skills add https://github.com/Leonxlnx/taste-skill \ --skill design-taste-frontend # 文案优化 npx skills add https://github.com/blader/humanizer # 交付 Review只装本次需要的 7 个 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装完检查.agents/skills/目录确认每个 Skill 下有SKILL.md。调用示例。Codex CLI 里用$前缀触发 Skill。设计阶段$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。文案阶段关键是只改文字不动结构$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. 页面整体表达保持自然、简洁符合个人主页而不是企业宣传稿的语气。 完成后请另外告诉我哪些文案被修改、原文是什么、 修改后是什么、为什么修改。Review 阶段第一次只审不改$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 5. 所有问题必须基于当前实际页面不要为了凑数量而提出修改 6. 不要重新设计页面也不要把纯审美偏好当成错误。 请把发现的问题分成三类 A. 明确需要修复的问题 B. 建议优化但不影响正常使用的问题 C. 纯审美偏好或可选建议 本轮完成 Review 后停止不要自动修复。这三段提示词的核心思路是控制变量每轮只加一个 Skill每轮只改一个维度输出目录分开。这样出问题时能快速定位是哪一步引入的。4. 验证请求与端到端成功结果配置完别急着跑完整任务先做一次最小验证确认 TaoToken 通道通了。最直接的方式是 curl 打一次 chat 接口curl https://taotoken.net/api/v1/chat/completions \ -H Authorization: Bearer $TAOTOKEN_API_KEY \ -H Content-Type: application/json \ -d { model: gpt-5.6-sol, messages: [{role: user, content: 回复 OK 两个字母}] }返回里能看到choices[0].message.content是OK说明 Key、Base URL、Model ID 三件套对齐了。这一步过了再进 Codex。Codex 侧验证直接跑一个轻量任务codex exec 读取 input/vic-source.md只输出文件里出现过的数字不要做别的如果模型正常返回那些数字说明 Codex 已经通过 TaoToken 拿到模型响应。然后是端到端。我按00-baseline → 01-taste → 02-humanizer → 03-final四个目录跑完整流程每轮结果如下。Baseline 轮Codex 默认能力输出黑底荧光黄绿方案主动提取$42K ARR、2,800 用户、3.2M 摄影浏览、4 年旅居成独立指标调浏览器检查后发现标题拥挤改 CSS 重新验证。这一轮证明默认能力已经能跑完信息整理到自我修复的闭环。Taste 轮挂design-taste-frontend后页面方向明显变了。Baseline 像一张有视觉张力的海报Taste 版更像懂工程规范的前端工程师做的文字、按钮、交互图片解耦做成可维护的双主题组件系统支持明暗主题。QA 覆盖也更全检查了图片与文字关系、Hero 标题换行、390px 和 500px 移动端横向溢出、深色主题、完整长页面、prefers-reduced-motion、文字对比度。有个细节一张生成图片把说明文字烘焙进了图里Codex 读 Skill 规则后主动改成图片 独立 HTML 文本。这里要划清归因边界。Taste 版同时用了 Codex 自带的图像生成能力生成 3 张场景配图最终页面是 GPT-5.6 Sol 本身的前端能力、Skill 规则、图像生成能力、本轮 QA 共同作用的结果不能把所有视觉变化都算到design-taste-frontend头上。Humanizer 轮文案变化比删几个 AI 高频词有意思。比如Before在城市之间做产品也做记录。 After在不同城市生活做产品也拍照。Before过去几年Vic 在不同城市生活独立完成产品、代码、摄影和播客。 After过去几年Vic 一边在不同城市生活一边做产品、写代码、拍照和录播客。变化集中在三处抽象名词变具体动作泛化总结变具体事实介绍稿语气变自然个人表达。数字、年份、项目名、技术栈这些明确信息基本保持原样。Better-interface 轮第一次只 Review 不改结果A 明确需要修复 4 B 建议优化 4 C 纯审美偏好 0 Layout Clear Writing Clear Typography Clear Verdict Block页面肉眼看已经没明显问题它没纠结圆角留白而是抓出颜色、可访问性、交互状态上的 4 个交付问题小字号强调色文字对比度不足、焦点环对比度不足、可见标签与 accessible name 不一致、系统主题变化后aria-pressed状态不同步。修复轮只修 A1 到 A4B 类建议全部保留不动。修完重新验证4 个问题均解决Verdict 从Block变成PASS。这里的 PASS 只代表本轮 Review 没有 A 类阻断问题不等于完成生产级可访问性认证也没做真实屏幕阅读器或 Axe、Lighthouse 独立审计。5. 本篇常见报错排查401、local proxy failed、reading choices、OAuth跑这套流程报错基本集中在接入层。下面按我实际遇到和常见反馈整理。401 Unauthorized。最常见的原因是 Key 没生效或写错位置。检查顺序echo $TAOTOKEN_API_KEY看环境变量有没有值config.toml里env_key拼写是否和实际变量名一致Key 有没有多余空格或换行。还有一种情况是 Key 创建后没复制全控制台只显示一次漏了就重新建一个。如果 curl 能通但 Codex 报 401多半是 Codex 进程没继承到环境变量改成写进auth.json或重启终端。local proxy failed。这个报错通常出现在 Codex 尝试走本地代理但代理没起来或者base_url被错误地指向了本地地址。检查config.toml里base_url是不是https://taotoken.net/api别写成http://localhost或带端口。另外确认没有残留的代理环境变量HTTP_PROXY、HTTPS_PROXY这类如果指向一个不存在的本地端口也会触发这个错。清掉再试。reading choices 相关报错。典型表现是解析响应时读不到choices字段报cannot read property choices of undefined或类似。原因一般是返回体不是标准 chat 格式可能是wire_api配错了。config.toml里wire_api chat要和实际接口对齐。如果返回的是错误 JSON比如 401 的 body解析自然失败所以先确认鉴权没问题再看这个错。OAuth 相关报错。Codex 某些版本默认走 OAuth 登录流程如果你用 API Key 接入可能会看到 OAuth token 刷新失败或登录态冲突。处理方式是明确走 API Key 模式别混用登录态。检查auth.json里是不是同时存在 OAuth 字段和 API Key 字段冲突时清掉 OAuth 部分只留OPENAI_API_KEY和OPENAI_BASE_URL。如果之前登录过官方账号先登出再配 Key。Skill 安装安全提示。装humanizer时我碰到过安装器给的安全扫描结果Gen Safe、Socket 0 alerts、Snyk High Risk。第一次看到没继续装先取消人工检查仓库里的SKILL.md重点看是否要求执行外部脚本、是否下载未知文件、是否上传本地数据、是否读取无关目录、是否调用额外网络服务。当前SKILL.md主要是文本处理规则没看到明显高风险指令才在隔离的 Project 里继续测。这里没法简单判断 Snyk 的 High Risk 就是误报人工检查SKILL.md也不等于完整安全审计。更实用的做法是扫描结果冲突时先确认 Skill 来源和实际指令再决定是否安装、权限限制在什么范围。所有 Skill 走 Project 级安装也是出于这个考虑。Skill 不生效。$skill-name敲了没反应先确认.agents/skills/下有对应目录和SKILL.md再确认当前工作目录是项目根目录Codex 从当前目录往上找.agents最后看 Skill 名拼写design-taste-frontend和better-interface这类带连字符的容易打错。排障时如果拿不准是通道问题还是 Skill 问题先用模型对话页 https://taotoken.net/chat?utm_sourcetaotoken_aicg_blog_endutm_contentmodel-chatutm_campaignrewrite 单独发一条消息通道通了再回 Codex 查 Skill。接入文档在 https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_contentdocutm_campaignrewrite 参数细节以文档为准。6. 三个 Skill 怎么选以及长期编码场景的接入方式跑完整个流程三个 Skill 的定位比较清楚了。design-taste-frontend适合你已经有明确设计规范、想让 Agent 稳定执行的时候。它把设计原则固化成规则Codex 会按规则做组件解耦、双主题、QA 检查。代价是执行链变长一轮任务里模型调用次数明显增加。如果你只是临时做个简单页面Codex 默认能力就够不必上这个。humanizer适合文案是交付物一部分的场景。它只动文字不动结构这个边界很重要意味着你可以放心在已经定稿的页面上跑它。但它给的是 Review 建议具体改不改还得人工判断别全盘接受。better-interface适合交付前的最后一道检查。它不纠结审美专抓对比度、焦点环、aria 状态这类肉眼容易漏的问题。第一次跑建议只 Review 不改看清楚它报什么再决定修哪些。A 类必修B 类看情况C 类忽略。组合方式上我的建议是串行设计 → 文案 → Review → 修复每步输出到独立目录。这样任何一步出问题都能回退也方便对比每轮变化。别三个 Skill 一起上变量太多出了问题定位不到。长期做编码和 Agent 任务的话单次调用按量走不如用 Coding Plan 划算入口在 https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentcoding-planutm_campaignrewrite 。它适合那种每天都要跑 Codex、频繁触发多轮模型调用的场景。API Key 管理在 https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentapi-keysutm_campaignrewrite 需要多把 Key 分项目隔离的时候用得上。最后说个实测感受模型能力越强Skill 的价值越往把专业工作方法、约束和检查流程固化给 Agent这个方向走。会不会做已经不是唯一问题按什么标准做、做到什么程度、最后怎么检查才是 Skill 真正值得看的部分。这次三个 Skill 跑下来最大的收获不是页面变好看了而是整条交付流程变得可复现、可回退、可检查。