在 VS Code 中用 GitHub Copilot 还原 Pixso 设计稿，可以先把 https://pixso.cn/mcp 配进工作区的 .vscode/mcp.json，完成授权，再让 Agent 读取带 item-id 的目标图层。确认读到正确页面后，先匹配项目已有组件，再分区域实现和验证。不要一上来就要求“生成整个系统”，也不要把连接成功当成交付完成。
下面以已有 Vue 3 + TypeScript 项目中的费用报销审批页为例，串联费用明细、凭证附件和通过／驳回状态。Pixso MCP负责向 Agent 提供设计上下文；Copilot 则结合当前仓库进行实现。审批规则、接口和权限仍由项目本身决定。
先确定要还原的审批页，而不是整个设计文件
这次任务的输入应是一个清楚的审批页容器，而不是几十张画板的文件首页。把申请人、报销单号、费用明细、凭证附件、审批记录和操作区放在同一页面范围内，再为“填写驳回理由”补上对应状态。页面中的姓名、单号和金额使用非敏感数据。
生成代码前，先确认三项条件：
- 设计范围明确。在 Pixso 中选中审批页的容器，右键复制图层链接，确认链接带有
item-id。普通文件分享链接不能准确指定本次要读取的对象。 - 项目已经能运行。在 VS Code 中打开现有仓库，先按项目说明启动，记录已有的类型检查、Lint 和测试命令。不要把旧项目本身的构建错误误判为 MCP 接入问题。
- 账号具备所需能力。调用 Pixso MCP 需要全功能席位或研发席位。读取设计还需要文件可查看权限，修改设计需要可编辑权限；设计转代码另涉及企业版对应席位及企业空间文件条件，详见工具与权限说明。
只想从设计稿实现前端页面，不必顺带授权修改原始设计。把“读取 Pixso、修改本地代码”和“写回 Pixso 画布”分开，任务边界更清楚。
用 servers 配置 VS Code 原生 MCP
在工作区创建或打开 .vscode/mcp.json，将 Pixso 远程服务加入现有 servers 对象。已有其他服务器时保留原配置，不覆盖整个文件：
{
"servers": {
"pixsoRemote": {
"type": "http",
"url": "https://pixso.cn/mcp"
}
}
}保存后，通过命令面板中的 MCP: List Servers 找到 pixsoRemote，启动服务，并按提示完成 Pixso OAuth 授权。确认登录的是有权查看该审批文件的账号，而不是浏览器里另一个个人账号。远程接入不需要一直打开 Pixso 网页；具体端点和授权方式可参阅Pixso 远程 MCP 文档。
文件名和顶层字段必须对应。本节使用的是 VS Code 原生 .vscode/mcp.json，顶层为 servers。新版 Copilot 还支持仓库根目录 .mcp.json 等便携配置，其顶层是 mcpServers。不要只改文件名、不改格式，也不要把 Cursor 的配置整段原样粘进这里。两种格式的字段和交互输入支持并不完全相同，可查看VS Code 配置参考。
如果界面中没有出现刚添加的服务，先确认正在使用的 Agent 会话、工作区和配置来源。不要在多个位置反复添加同名条目，否则后续很难判断实际连接的是哪一个。
需要本地连接时，先弄清 127.0.0.1 指向哪里
若要边查看桌面画布边操作，可把服务地址换成 Pixso 客户端当前展示的本地地址。默认是 http://127.0.0.1:3667/mcp，但端口可能因占用发生变化；连接类型仍为 http，不是 sse。使用期间需要保持客户端登录、MCP 服务开启、目标文件打开且页签激活。相关前提见Pixso 本地 MCP 文档。
尤其要留意 Remote SSH、WSL 和开发容器：127.0.0.1 是发起连接的运行环境自己的回环地址，不一定是你正在看的那台电脑。把配置文件放到远程工作区，并不会把桌面上的 Pixso 服务一起搬过去。遇到本地地址无法访问，先确认请求实际从哪里发出，再决定使用云端 OAuth 路线，还是按团队网络方案连接本地服务；不要为排错直接把本地端口暴露到公网。
第一次只读：让工具返回审批页，而不是让模型猜页面
在聊天输入处选择 Agent，将审批容器的完整图层链接交给 Copilot。第一轮只验证读取，不改设计，也不改代码：
使用 Pixso MCP 读取这个费用报销审批容器链接：[粘贴图层链接]。
先不要修改设计和代码。
返回容器名称、尺寸，以及申请信息、费用明细、凭证附件、审批操作区的主要节点。
指出当前设计中有没有驳回理由状态。
如果链接无效、权限不足或找不到节点，请停止，不要猜测设计内容。展开会话中的工具调用，确认返回来自 Pixso MCP，而不只是 Agent 给出一段合理的文字描述。可以先使用 get_node_dsl 理解层级，再针对有疑问的局部读取更细数据；需要对照画面时，查看实际可用的截图工具和返回结果。
核对三个具体对象：审批页的名称是否正确，费用明细是否属于这一张单据，底部操作是否包含预期的通过与驳回入口。任何一项不对，都应重新定位节点，而不是继续让 Agent 生成代码后再补救。
允许 MCP 服务器启动、完成 Pixso 登录、启用某个工具、批准这次工具操作，是不同的控制点。工作区 MCP 配置受 Workspace Trust 约束；不要为了消除报错而信任未经检查的仓库。对于写入、执行脚本或更大范围的动作，应先阅读调用参数，确认它与本次任务一致。
让 Copilot 先找现有组件，再决定新增什么
已有后台项目通常已经具备表单、表格、上传、弹窗、按钮和消息提示。把设计稿直接转换成另一套独立 HTML，可能看起来接近，却绕开了项目的校验、权限和样式规范。接入团队仓库时，先要求 Copilot 检查实际组件和类型，再给出映射。
先只读当前 Vue 3 + TypeScript 项目。
查找现有的表单、费用明细表格、附件展示或上传、弹窗、按钮、消息提示与设计 Token。
同时检查审批页相邻路由、API 类型和错误处理方式。
按“Pixso 区域 → 已有组件 → 缺少的状态 → 拟修改文件”列出映射。
引用你实际找到的文件路径；没有找到的能力单独列出。
暂时不新增依赖，不创建第二套基础组件，不修改接口和路由。针对本页，映射至少要回答以下问题：
- 申请信息如何呈现？复用详情布局和日期、金额格式化方式，避免把同一项目的金额显示成另一种精度。
- 费用明细如何承载？先使用现有表格与单元格插槽，核对类别、发生日期、金额、备注等实际字段，不凭视觉顺序猜 API 字段名。
- 凭证是查看还是上传？审批人只查看时应复用附件展示能力；只有业务明确允许补充凭证，才接入已有上传流程，不能给审批人凭空增加编辑权限。
- 驳回理由放在哪里？沿用项目既有弹窗或表单容器，复用校验、按钮禁用与关闭行为，而不是另写一套看起来相似的组件。
- 颜色和间距怎么复用？设计属性先映射到项目现有 Token；找不到对应值时说明差异，再决定局部补充，不直接在各处散落新的数值。
审完映射再批准修改范围。例如只新增审批页展示组件并接入既有路由，不更换 UI 库、不改登录机制、不重写全局样式。MCP 的价值是提供准确设计信息，不是替团队决定仓库架构。
把通过、驳回与凭证状态补成可实现的规则
静态画板能说明入口和布局，但不能自动告诉 Agent“谁有权审批”“理由是否必填”“请求失败后是否保留内容”。先把本页规则写清，再让 Copilot 绑定状态。下面采用一个具体约定：审批人可查看凭证、通过或驳回；驳回理由必填；提交失败时保留已填理由。若项目规则不同，应以真实接口契约替换这三条。
凭证：区分没有附件、正在读取和读取失败
“暂无凭证”只适用于接口已成功返回且列表为空。加载中的空数组不能立即显示这个结论；读取失败也不能伪装成没有附件。附件名可能很长，既要避免挤坏布局，也要让用户获得完整名称。点击查看的目标应来自项目已有的授权访问逻辑，不把私有文件地址硬编码进页面。
如果业务允许补充凭证，再补上传中、成功、失败与取消状态，并复用已有文件大小、类型和重试规则。界面显示了文件名，不代表服务端已经收到了文件；在上传确认之前，不应把它当作可提交的有效凭证。
驳回：关闭表单不等于提交成功
点击驳回后进入理由表单，焦点落到合适的输入位置。未填写理由时，错误提示关联到该字段；提交中阻止重复点击，失败时保留理由并允许重试。成功后再关闭表单、更新审批状态和列表数据。用户主动取消时，按项目既有规则处理未提交内容，并将焦点返回驳回入口。
通过操作也要区分“请求已发出”和“服务端确认成功”。是否需要二次确认、能否撤销、成功后留在详情还是返回列表，都应来自业务约定，不能由 Agent 根据按钮颜色自行决定。
先做可读页面，再接审批行为
批准实施后，把工作拆成三步：先完成申请信息、费用表格和附件展示；再接入驳回理由表单；最后连接审批请求和成功后的数据刷新。每一步都查看 diff，避免为了完成一张页面改动无关模块。
按已确认的组件映射实现这张审批页。
使用项目现有 Vue 3 + TypeScript 写法，保留既有 API 类型、路由和权限逻辑。
先实现只读区域，完成检查后再处理驳回表单与审批提交。
驳回理由按已给业务规则校验；提交失败保留输入；成功后再更新状态。
不要新增 UI 库、重复基础组件或生产接口调用。
每一步说明修改文件，并运行项目已有的相关检查。
不要自动提交、推送或部署。服务能启动却无法工作，用 Show Output 缩小问题
遇到异常，先运行 MCP: List Servers，选择 Pixso 服务，再选择 Show Output。若当前版本提供 Agent Customizations 预览界面，也可从其中的 MCP Servers 菜单打开输出；没有该面板时使用命令面板即可。查看错误时记下配置来源、运行环境和失败步骤，分享日志前移除令牌、授权头和私有链接。入口及信任规则可查VS Code 官方排障说明。
- 服务没有出现：先查当前会话读取哪份配置，再检查文件位置和顶层字段。不要把
mcpServers填入原生.vscode/mcp.json。 - 连接或登录失败：远程路线核对端点与 OAuth 账号；本地路线核对服务是否开启、端口是否变化以及网络请求从哪里发出。
- 工具可见却读不到审批页：检查带
item-id的链接与文件可查看权限。本地选区路线还要确认当前激活文件和容器。 - 读取正常但设计转代码被拒绝：按工具返回信息检查席位和文件所属空间。重新安装扩展不能修复账号权限。
- 服务运行但工具没被调用：检查当前会话是否启用该工具，再明确要求执行一次只读动作，并展开输出验证。不能因为回答“像读过设计稿”就认为调用成功。
修正原因后重新启动对应服务器，再重复那条小范围只读任务。不要直接重跑整页生成，否则会把接入故障与代码改动混在一起。首次调用应验证实际工具和输出，相关操作见VS Code 工具使用说明。
从能显示到能交接，还要过这几项检查
费用报销审批页的验收不能只有一张桌面截图。先运行项目已有的类型检查、Lint、相关测试和构建；命令应从仓库配置确认，不假定每个项目都有相同的脚本名。随后在本地或测试环境检查以下场景：
- 长内容：多条费用项、长备注、长附件名不会覆盖金额、操作入口和关键状态。窄屏下明确表格的滚动或分组策略，不让整页横向溢出。
- 异步状态：加载、空数据、附件读取失败和审批提交失败都有不同反馈，不出现“请求失败却显示操作成功”。
- 表单与键盘：驳回理由可通过键盘填写与提交；校验错误可定位；取消后焦点有明确去处；提交中不会发出重复请求。
- 组件复用：检查 import、props 与设计 Token，确认没有新造第二套按钮、弹窗或错误提示，也没有把示例姓名和金额写死在组件内部。
- 接口与权限：前端按钮显隐不能替代服务端鉴权。审批是否成功以真实接口结果为准；不在生产单据上验证测试场景。
把视觉差异限定到具体区域再让 Copilot 修复，例如“只调整费用表格的单元格间距和金额对齐，不改接口与校验”。每次回到同一 Pixso 图层对照，既能保持任务范围，也能避免局部修样式变成重写整页。
最终交接应包括修改文件、复用组件、执行过的检查和仍需确认的业务规则。需要回看不同 IDE 的基础接入方式时，可参考Pixso MCP 连接指南；落实到这张审批页时，始终沿着“读对设计对象、接入已有工程、验证真实状态”的顺序推进。
