Codex做UI设计：直接修改Pixso设计稿

Codex 可以通过 Pixso MCP 直接修改可编辑设计稿。做法是连接远程服务、提供目标图层链接，让它先读取页面和设计规范，再限定范围调整结构、组件及样式，最后用截图与图层检查确认结果。想改 UI，就明确要求输出 Pixso 画布中的新方案；只说“做个页面”，容易得到一份前端代码。

已有页面常见的问题并不是“不够炫”，而是主次混乱、间距杂乱、按钮职责相撞。下面用一个团队任务概览页，把 Pixso MCP 的设计编辑能力接入 Codex，完成一轮保留业务内容的界面精修。

先选对产物：这次改画布，不生成代码

“AI 做 UI”至少有三种不同结果：一张展示效果的图片、一份能在浏览器运行的页面，以及由文字、容器、组件等图层组成的设计文件。这次要的是第三种。设计师还能调整文字、移动模块、讨论层级；研发需要实现时，再进入设计转代码流程。

Codex 负责理解要求和组织操作，MCP 把这些操作连接到 Pixso 文件。Skill 可以补充任务顺序与设计约束，但不能代替文件连接，也不会自动赋予编辑权限。已有团队规范时，把规范和真实组件一起交给它，比重复强调“专业、简洁、高级”更有效。

练习页包含顶部问候、三个统计数、待处理任务、项目进度和团队动态。页面要回答的是：今天先做什么，哪些事情需要我行动？因此“待我处理”应该更容易被看见；项目进度提供背景；团队动态可放在次要位置。仅给每块内容加渐变卡片，会让所有模块争夺注意力。

这也决定了改动范围：保留任务名称、负责人、日期和状态，调整模块顺序、间距与按钮层级。不要让模型为了凑整齐，把长标题截断到看不懂，或直接删掉内容较多的模块。

连接Codex，读清要修改的对象

添加远程服务并完成授权

在 Codex 的设置中进入 MCP 配置，添加流式 HTTP 服务，地址填写 https://pixso.cn/mcp，随后按提示完成 OAuth 授权。使用 Codex CLI 时，也可以在终端添加服务并登录：

codex mcp add pixso --url https://pixso.cn/mcp
codex mcp login pixso
codex mcp list

服务出现在列表中之后，还要检查授权与工具是否可用。Codex 当前支持 Streamable HTTP 和 OAuth，配置说明见 官方 MCP 文档；Pixso 的图形界面配置步骤见 远程接入指南。远程方式不要求一直开着 Pixso 桌面端。

账号需要全功能席位或研发席位，目标文件必须可查看；写入设计还需要可编辑权限。设计转代码的 D2C+ 另有企业版席位和企业空间要求，不能把连接成功理解为所有能力都已开通。本篇先完成设计编辑，不依赖 D2C+ 生成前端代码。

给完整业务容器的链接，不给整份文件的模糊指令

在 Pixso 中选中“团队任务概览”的容器，右键复制图层链接，检查链接带有 item-id。普通分享链接只能指向文件，页面链接里的 page-id 也不能代替具体图层。

首次对话先要求只读。让 Codex 返回容器名称、子模块、关键组件、样式或变量，以及仍未读取的部分。远程工作流应依赖明确链接和节点 ID，不要把“当前选中”当作跨设备永远可靠的定位方式。

读取下面的 Pixso 图层链接，先不要修改。请列出该页面的一级模块、各模块的主操作、现有组件和颜色/文字规范。关注“待我处理”与“团队动态”的视觉层级。若节点信息不完整，继续读取相关子节点；不要凭截图猜测图层名称。

目标图层：[粘贴带 item-id 的链接]

若它读出的模块与画布不一致，先解决对象定位。常见原因包括复制了某个小按钮的链接、授权账号没有目标文件权限，或只读取了顶层摘要。已有 Codex 读取设计稿排查方法可以帮助区分这些情况。不要在读错对象时继续下达“全部优化”。

第一轮：让任务优先级出现在视觉上

先把设计目标写成可以观察的变化。“更有设计感”无法判断完成；“待处理任务先于团队动态出现，只有一个页面级主按钮”则可以直接检查。对于任务概览页，可以先给出四条要求：

• 首屏能看见待我处理的任务，以及每项任务的下一步操作。
• “新建任务”是页面级主操作；列表里的“查看”保持次级样式。
• 三个统计数用来概览，不与任务列表争抢最大字号和最强颜色。
• 项目进度和团队动态仍保留，减少视觉权重而不删减信息。

让 Codex 先提出调整方案，再在原稿旁建立一个新容器。这样可以并排比较，原稿也保留作为讨论基线。特别是原组件和共享样式，不应因为修改一页就被全局改变。

在原容器旁创建“任务概览 / 精修方案”，不要覆盖原稿。允许移动和调整新方案内的模块；保留全部任务名称、状态、负责人和日期。把待处理任务放在主要阅读区域，团队动态放到次级区域。“新建任务”保留主按钮，行内“查看”使用次级动作。先沿用文件中的组件和规范，不新增装饰插画，不改共享主组件。

这个阶段主要使用设计读取和写入能力，而不是反复生成整页图片。当前工具中，query_nodes 可定位图层，read_components 可了解可复用组件，apply_design 可组织与修改设计内容。工具实际参数由客户端发现的 schema 决定；向 Codex 描述目标即可，不需要把想象出来的 JSON 参数硬塞给它。

比较时先看阅读顺序：眼睛是否从页标题走向待处理任务，再看到次要动态。若右侧动态仍然因为高饱和底色抢眼，就降低该区域的视觉权重，而不是继续把左侧标题加大。层级是相对关系，不能靠所有东西一起变粗解决。

第二轮：统一布局，不把所有元素改成一样

结构确定后，再处理间距、字号、圆角与状态。若先统一颜色再重排布局，很容易做两遍。这里的“统一”也不是把每一个数值改成 16 或 24，而是让相同职责使用相同规则。

有设计变量时先读变量；只有局部数值时先盘点，再决定是否收敛。query_all_unique_props 可以帮助发现杂散属性，replace_props 可批量修改属性，但直接要求“所有红色改成品牌色”可能连错误提示也一起改掉。

只检查“任务概览 / 精修方案”。列出重复职责却使用不同字号、圆角或间距的对象，并给出目标值。保留成功、警告、错误的语义色。不要改Logo、图片、原稿、共享主组件或文件级变量。经确认后，只调整列明的节点；每轮返回具体修改节点和未处理事项。

假设团队原有的面板内边距为 24、任务行内部间距为 12，可以沿用这些值，但这不是适用于所有产品的固定答案。字体也应考虑中文长标题、数字与英文缩写：先保证可读与不截断，再追求某个视觉节奏。密集后台页和营销落地页的字号策略不必相同。

组件关系要单独看。外观相同的两个按钮，可能一个是实例，一个是散落的矩形与文本。仅凭截图“看起来一致”，无法证明组件复用已经完成。需要 Codex 返回读取到的组件或实例关系；查不到时就作为普通图层处理，不能口头宣称“已全部组件化”。

第三轮：看截图，也看可编辑结构

一轮改动结束后，先让 Codex 对新旧容器截图，再检查布局。远程 MCP 可使用 take_screenshot，check_layout 帮助发现结构问题。但工具返回没有异常，不代表信息层级、文案和业务状态已经合格。

设计师可以按三个层面检查：

1. 视觉：标题是否拥挤，任务名称是否被遮挡，按钮是否跑出容器，主要区域能否一眼辨认。
2. 结构：模块是否仍是独立容器，文字是否可编辑，组件实例和变量引用有没有被破坏。
3. 内容：原有任务、状态与负责人是否完整，日期有没有被模型顺手改写，“待处理”是否错误变成“已完成”。

对原稿和精修方案分别截图，检查相同区域。逐项核对：任务与负责人没有遗漏；待处理列表优先；页面级主按钮唯一；长标题不遮挡状态；原稿和共享组件未修改。把已确认的问题落实到具体节点。如果只能确认视觉，明确哪些结构尚未读取，不把“看起来相同”当作组件关系相同。

再做一次内容压力检查：把任务名临时换成长标题，尝试空列表与较多任务两种情况。文字变长后，行高应该有合理变化；任务变多后，列表扩展不应遮住下一模块。测试结束恢复示例内容，并保留检查结果。

若某轮工具调用报错，先读取新方案当前状态，核对已经生效的部分，再继续剩余改动。不要假设失败会自动回滚，也不要重发一整段“创建所有模块”的指令，否则容易在画布中堆出重复页面。需要撤回时，由设计师在画布或历史版本中选择正确的恢复点。

什么时候继续交给Codex，什么时候亲手调整

重复而边界明确的任务适合继续交给 Codex：统一一组卡片的内边距、让同类标签采用同一规则、根据已有组件补一个状态、读取评论后整理需要修改的对象。它的价值在于把已明确的设计判断落实为一组可检查操作。

“这页到底应该优先服务谁”“主操作是否合理”“品牌应该呈现什么气质”，仍需要设计师判断。若你对方向还没有共识，可以先让 Pixso 智能设计生成候选方向，在画布中选择与完善；已有成熟规范、需要连续编辑时，再让 Codex 带着明确对象推进。

一套实用的协作节奏是：设计师确定任务和边界，Codex 读取并执行，设计师看图与结构反馈，再做小范围下一轮。最后得到的应是一份团队能继续编辑和讨论的设计稿，而不是一张无法维护的漂亮截图。