让Codex做一个后台页面，最容易得到的是“能跑”的界面：卡片、按钮、表格都有，换一份文案却还是同一套模板。真正难的是第二轮修改，设计师想只调整一个表单状态，AI却把整页重写；开发拿到设计稿后，也不知道哪些组件必须复用，哪些状态需要补齐。
这类问题通常不是模型不会写代码，而是缺少一套能读取、能修改、能检查的设计工作方法。Design Skill的价值，就在于把“看起来舒服”改成具体规则，再让Codex按规则执行。
PixsoMCP负责把真实设计对象交给Codex。
连接后，Codex可以读取Pixso画布中的页面、图层、组件、变量和标注，获得比截图更完整的上下文。它解决的是“AI看到了什么”。
Pixso AI Skill负责在画布里生成和修改。
设计师可以在Codex中调用它，让AI生成一版页面，或针对选中的区域修改布局、组件和文案；确认设计后，再读取设计稿生成React代码。它解决的是“在哪里改、怎么把设计交付出去”。
普通的Design Skill则规定做事顺序：先读哪些规范，组件怎么映射，必须覆盖哪些状态，完成后如何验收。三者不是一个大提示词。MCP提供对象，Pixso AI Skill提供画布操作，团队Skill提供判断标准。
Anthropic开源的frontend-design适合从零生成第一版UI。它要求先做设计计划，再开始写界面：明确4到6个颜色token、字体层级、布局概念和设计原则，并检查方案是不是只换了文案的常见SaaS卡片。
实际调用时，可以让Codex先根据业务任务给出设计计划，再通过PixsoMCP读取团队组件，最后让Pixso AI Skill在画布中落地。这样生成的不只是颜色变化，而是有取舍依据的页面。它的边界也很清楚：这个Skill不了解你的权限流程和内部组件库，业务规则仍要放进项目说明或Design.md。
Vercel的web-design-guidelines更适合第二轮检查，而不是从零画视觉稿。让Codex在页面生成后逐项检查响应式布局、键盘焦点、可访问性、交互反馈、文案清晰度和空状态。
例如一个表格页面，除了正常数据，还应检查加载中、空数据、筛选无结果和请求失败；窄屏下操作按钮是否被挤走；错误提示是否告诉用户下一步怎么做。检查结果最好变成明确的修改清单，再回到画布或代码逐项处理，而不是让AI一句“优化一下”重新生成整页。
Vercel的react-best-practices解决的是工程实现质量，不是视觉风格。设计稿通过PixsoMCP读取并生成React代码后，可以让它检查组件是否重复、状态是否混在页面里、数据请求和展示是否耦合、列表渲染是否存在明显性能问题。
这一步很容易被忽略：设计工具生成的代码可以作为起点，却不一定符合现有项目的组件边界。先让Codex把Pixso里的组件名、变体和代码组件对应起来，再用工程Skill检查，返工会少很多。
“使用PixsoMCP读取当前画布的注册表单和组件变体；调用Pixso AI Skill，在不改变字段的前提下补充提交失败和空状态；遵守团队Design Skill中的间距、颜色和错误提示规则；完成后读取设计稿生成React代码，再用web-design-guidelines检查窄屏和焦点状态，用react-best-practices检查组件复用。”
执行顺序也要固定：先读真实画布对象，再修改局部设计；设计确认后生成代码；代码生成后分别做体验检查和工程检查；最后由设计师确认业务路径。遇到布局问题，优先回到画布修正约束；只是接口字段变化，再在代码里处理。
生成、局部修改、页面审查、代码交付是四种不同任务。先从一个高频页面开始，例如表单、列表或详情页，记录它需要的组件、状态和验收条件，再决定接入哪个Skill。Skill写得越具体，越能减少模板化结果；但几十条禁止项只会让维护变得困难。
Codex可以把等待时间缩短，设计师仍要决定页面任务、组件边界和取舍。把Pixso画布、MCP和Design Skill接成一条可检查的流程，AI才不只是“生成一张图”，而是参与从设计到代码的连续工作。
