先回答这项工具到底负责什么
WorkBuddy接入 Pixso MCP 后，最有价值的场景是把前端页面和设计稿放在同一套检查流程里。它不等于内置 Pixso 连接器，也不能替代设计师确认业务状态。先通过自定义 MCP 配置连接，再让它读取订单详情页的节点、组件和状态，最后逐项核对实现。
Pixso 远程 MCP 运行在云端，Pixso MCP支持读取节点、样式、变量和截图；WorkBuddy负责组织任务、读取本地项目和呈现检查结果。两边都没有权限时，页面不会因为多写一句提示词就自动可读。
先完成连接，再进入验收
当前 WorkBuddy 文档支持 CLI 参数与 MCP 配置，但默认连接器列表不等于已经内置 Pixso。把远程服务作为用户明确配置的连接器，核对地址、认证方式和工具开关；本地文件读取范围也要限制到当前项目。
codebuddy mcp add pixso --transport http https://pixso.cn/mcp
codebuddy mcp list实际命令以 WorkBuddy 当前版本为准。不要把 token 写进仓库，也不要因为工具列表出现就默认拥有设计文件编辑权限。
把验收范围写成可观察步骤
订单详情页常见差异包括信息卡片边界、金额数字、状态标签、操作按钮、加载态、空态和错误态。把验收范围写成页面、容器和组件列表，再给 WorkBuddy 一个只读任务，要求返回节点名称、尺寸、组件和变量，不立刻修改。
| 检查对象 | 先确认什么 | 通过标准 |
|---|---|---|
| 布局 | 主信息与侧栏宽度 | 内容边界和间距可复核 |
| 数据 | 金额、时间、编号 | 数字和格式不被改写 |
| 操作 | 发货、退款、返回 | 主次按钮与权限对应 |
| 状态 | 加载、空、错误 | 每种状态有下一步 |
截图与结构证据要同时成立
截图适合观察首屏层级、留白和遮挡；节点和属性适合检查尺寸、文字、组件实例和变量。WorkBuddy可以按“截图—节点—规则”顺序输出差异，但不能只凭截图判定组件关系。
订单金额和状态颜色还需要业务确认。一个视觉上相同的标签可能代表不同状态；一个布局差异也可能是响应式规则而不是 bug。把差异分为必须修复、需要业务确认和可接受偏差三类，避免把所有不一样都改成相同。
一次只修一类差异
优先修复边界和阅读顺序，再处理组件和状态文案。修复一组间距后重新截图和读取节点；如果结果显示重复容器或共享组件被改动，立即停止并恢复版本。不要让 WorkBuddy在一次任务里同时改页面骨架、颜色变量和业务文字。
差异清单 → 选择一类改动 → Pixso写入 → 重新读取节点
截图复核 → 记录未处理差异 → 再开始下一轮把可编辑页面交给团队
订单详情页验收至少要包含：主信息可读、金额格式正确、操作按钮与权限匹配、加载/空/错误态可达、移动宽度不遮挡、节点仍可编辑。通过工具返回“完成”不代表这些条件都成立。
明确自动化边界和人工判断
WorkBuddy可以读取项目文件、整理差异、调用已授权的 MCP 工具并生成待办。设计师仍要决定品牌表达、信息优先级和交互取舍；产品和研发要共同确认金额、权限和状态语义。
最终交付保留设计稿、代码版本、差异清单和人工确认记录。这样既能利用 Agent 提高复核效率，也不会把一次自动检查包装成完整的视觉回归测试。
