先安装并连接，
再进入业务流程。
Web 使用手机号与密码；浏览器插件和 Codex Skill 使用 V2 设备会话。平台 Cookie、Provider Key 和管理员密码不在工具之间传递。设备授权先建立身份；浏览器插件随后自动领取自己的目标配置。SellerPilot 只有在内置 image_gen 不可用且明确选择第三方代理时才领取 sellerpilot-image。
只走“Codex 发起 → Web 批准 → Codex 验证”的最短成功路径。
提供可复制指令、版本入口、设备授权、配置同步、撤销与排障。
说明每个业务节点先做什么、怎样使用工具、需要什么输入输出以及何时放行。
- 1开通 Marqel 账户。
- 2按本页安装需要的 Skill 或浏览器插件。
- 3完成对应设备授权和配置同步。
- 4确认版本、设备和配置状态均正确，再进入业务指南。
ChatGPT 桌面应用（Codex / Work）
这是运行 Marqel Skills 和使用 Codex Switch 前必须先安装的本地环境。Codex 已整合在 ChatGPT 桌面应用中：从产品选择器进入 Codex；选择 ChatGPT 后，还可在 Chat 与 Work 间切换。
理解代码库、编辑文件、运行命令并调用使用 $ 的 Codex Skills。
用于研究、分析以及文档、表格、演示文稿等交付物；Skill 通过 @ 选择。
安装步骤
- 先安装 ChatGPT 桌面应用，并使用自己的 ChatGPT 账户登录；需要终端或编辑器工作流时，也可另装 Codex CLI / IDE 扩展。
- 在 ChatGPT 桌面应用的产品选择器中进入 Codex；处理研究或交付物时，选择 ChatGPT 后切换到 Work。
- 首次启动时选择实际项目工作区，不要把业务仓库复制进 Control Center。
- 确认当前模式能读取所需独立 Skill，但不要把 Etsy、1688 或 AdsPower Cookie 写入环境变量。
- 需要第一次连接 Marqel 时，从 Tutor 的“Skill 设备授权”步骤开始；授权完成后在同一模式验证当前用户。
完成标准
- ChatGPT 桌面应用可启动，产品选择器可进入 Codex；
- Codex 可打开实际项目工作区并启动目标 Skill，或 ChatGPT Work 可选择对应 Skill；
- Marqel 授权结果为
authorized，验证结果为verified； - 未通过聊天、剪贴板或截图传递 Token。
Codex Switch
为本机 Codex 管理第三方 Provider、模型与连接；它不是 Codex 运行环境，也不会代替你安装 ChatGPT、Codex CLI 或 IDE 扩展。
安装步骤
- 先关闭旧的 Codex / ChatGPT 进程，再从 Release 页面下载当前系统安装包并完成安装。
- 打开 Codex Switch，确认它识别到已经安装的 Codex 本地环境；识别不到时先返回上一节修复环境，不要把 Switch 当作 Codex 安装器。
- 按团队本地配置规范添加获授权连接，Provider Key 不进入截图、对话或共享文档。
- 应用连接后从 Codex Switch 打开新的 Codex 任务，核对实际使用的 Provider 与模型；不要把界面的“已选择”当成真实请求已经验证。
- Codex Switch 只负责本地模型连接；Marqel V2 设备授权仍在对应 Skill 中完成。
Skill 一键安装、更新与版本管理
在登录后的工具中心先选择 ChatGPT 桌面应用中的 Codex 或 Work，也可以选择 Codex CLI / IDE，再复制一键安装 / 更新指令。纯浏览器或云端环境不能写入你的电脑，因此不支持本机 Skill 安装。
tar、可申请访问 www.marqel.shop 的命令网络权限，以及用户级 Skill 与共享会话目录写权限。Windows 安装 staging 位于目标 Skill 根目录内，即使系统临时目录与 CODEX_HOME 分属 C:/D: 也不会执行跨卷重命名。浏览器能打开网站不代表 Node 命令已经联网。job_id。不要改成浏览器手动下载：Bootstrap 后续仍需受保护 GET、状态 POST、摘要校验和原子安装。若管理员策略禁止批准请求，请切换到允许请求批准的本地模式或联系管理员，不要循环重试。${CODEX_HOME:-$HOME/.codex}/skills、在 Windows 使用 %CODEX_HOME%\skills（未设置时为 %USERPROFILE%\.codex\skills）；ChatGPT Work 分别使用 $HOME/.agents/skills 与 %USERPROFILE%\.agents\skills。一次作业只写当前选择的客户端目录。@marqel-business-skill-manager；ChatGPT 桌面应用中的 Codex，或 Codex CLI / IDE，使用 $marqel-business-skill-manager 或 /skills。工具中心会按所选模式转换全部可复制指令。$marqel-business-skill-manager update-all；用户调用本身批准备份并修复同版本本机内容漂移，无需再创建 Web 作业。本地较新版本和 Catalog 摘要冲突仍失败关闭。intelligent-outreach）全部从 https://www.marqel.shop 的登录后受保护地址安装。只有目录明确登记了真实可访问的公开 GitHub 仓库时才使用 GitHub；没有对应 GitHub 仓库的 Skill 默认使用 Marqel 安装源，不生成不存在或无权限的仓库地址。团队 Skills：一键安装或更新
- 登录工具中心，选择真实本地执行环境，点击“复制一键安装 / 更新指令”；受保护包 URL 不进入提示词。
- Bootstrap 先检查 Node、tar、命令网络、共享会话目录和对应客户端 Skill 根目录，再安装或更新
marqel-control-center-auth与marqel-business-skill-manager。 - Bootstrap 自动验证现有 V2 会话；缺少授权时自动运行设备授权并把 Web 作业置为“等待设备批准”，批准期间不预签发其余包 URL。
- 授权成功后，管理器读取同一
job_id的install-or-update模式，先扫描完整目录并提交服务端复核的差量计划；当前项直接跳过，只有缺失、落后、可修复或获批迁移项才即时申请链接。任何阻断都在业务包写入前停止；Web 只有在全部 checkpoint 与同一设备报告一致后才显示“安装完成”。
日常版本管理
每个 Marqel 受管 Skill 在每段新对话的首次主要业务操作前，都会通过同根目录的 Manager 做一次共享检查；结果缓存 24 小时，因此不会为每个 Skill 重复联网。检查不修改文件，只有用户明确执行统一更新后才进入设备授权、备份与替换。
check-updates统一只读检查$marqel-business-skill-manager check-updates 使用 24 小时非敏感缓存比较全部受管 Skill；网络不可用时报告 freshness_unknown，不把未知说成最新。
update-all直接统一更新$marqel-business-skill-manager update-all 先全量预检，再只为必要差量申请链接；有效设备会话直接复用，同版本本机内容漂移先备份再修复，不要求另建 Web 作业。需要时先更新 Auth 与 Manager，再由新 Manager 接手续跑；本地较新版本和 Catalog 摘要冲突继续阻断。全程单锁、摘要验证并在完成时提示重启 Codex。
status完整性与配置诊断比较本机版本、包摘要和安装内容摘要，并显示两个生图消费者的脱敏配置状态，不修改文件。
report状态上报把 Skill ID、版本、包摘要和内容摘要写入当前设备记录，Web 据此显示是否过旧或完整性异常。
install-missing仅补缺失兼容命令，只安装不存在的 Skill，不更新已有目录。
update --approve-updates旧版兼容入口旧 Manager 尚不识别 update-all 时，使用一次该命令升级；升级到新 Manager 后，日常只需使用 update-all。
$marqel-business-skill-manager resume --job-id <installation_job_id>设备授权与会话维护
这一节保存第一次授权、有效期、自动续期与模型配置领取的准确规则。设备码短，不代表实际授权只有几分钟。
$marqel-control-center-auth 开头的指令都发送到 Codex 对话，不是 macOS / Windows 终端命令。第一次授权的真实流程
- 在 Codex 对话发送
$marqel-control-center-auth device-start；若由工具中心安装，Bootstrap 会在缺少会话时自动发起同一授权流程。 - 授权 Skill 创建或读取本机 Ed25519 安装身份，向 Marqel 申请设备码，并自动打开
device-approval.html。8 位代码只在 10 分钟内有效。 - 使用自己的 Marqel Web 账户登录，核对名称
Codex Orchestrator Skill、类型codex_skill、IDcodex-orchestrator；任一不符都不要批准。 - 批准后回到 Codex。普通流程显示
authorized；安装或更新image-proxy后，Skill Manager 会自动同步当前用户的sellerpilot-image配置，同步失败不会泄露凭据，并会提示在 Codex 使用$marqel-business-skill-manager sync-image-config统一重试。 - 发送
$marqel-control-center-auth verify。看到verified、当前用户、accessExpiresAt与refreshExpiresAt后，首次授权完成。
日常维护指令
status只看本地状态$marqel-control-center-auth status 分别显示 Access 与 Refresh 到期时间、滚动策略和是否可刷新，不打印 Token。
verify联机核验$marqel-control-center-auth verify 请求 /api/auth/me，只返回用户与不含凭据的服务器会话摘要。
refresh主动续期$marqel-control-center-auth refresh 轮换 access / refresh 凭据；日常访问在接近到期时会自动刷新。
sync-image-config统一补同步生图配置一级用户完成 Web 配置后，普通用户在 Codex 发送 $marqel-business-skill-manager sync-image-config，由 Manager 同时更新 SellerPilot 与 image-proxy 并核对同一摘要；不要求运行脚本或接触 API Key。
open打开管理页$marqel-control-center-auth open 打开当前 Control Center 的设备与授权页。
revoke断开本机连接$marqel-control-center-auth revoke 只删除本地共享会话并保留安装密钥；服务器撤销在 Web“设备与授权”中执行。
有效期、范围与本地文件
- 设备码默认 10 分钟，只影响这一次人工批准；过期就重新发起，不影响已经批准的设备。
- Access Token 默认 30 分钟；有效 Refresh Session 会在需要时自动换取新 Access，所以页面不应把 Access 到期显示成“账号即将掉线”。
- Refresh Session 默认采用滚动 90 天，以
status返回的实际时间为准；服务器撤销、用户停用或 Refresh 到期后才需要重新授权。 - 平台管理员查看全平台设备；一级用户查看当前组织设备；普通用户只查看自己的设备。
- macOS / Linux：会话
~/.etsy-ops/codex-skill-session.json，安装密钥~/.etsy-ops/codex-installation-key.json，通用目标回执写入~/.etsy-ops/codex-client-config.json；image-proxy的专用配置写入~/.codex/image-proxy/image-provider.json，目录与文件仅当前系统用户可读写。 - Windows：对应文件保存在
%LOCALAPPDATA%\Marqel；文件使用当前用户专属权限。
配置到底如何下发
继续使用 Codex 自身模型，不接收 Web Base URL 或 API Key。
一级用户在 Web 配置 image_generation 并分配成员后，普通用户安装受保护的 image-proxy；Skill Manager 在安装或更新完成后自动同步，真实生图前会按版本检查并领取轮换后的配置。
扩展以自己的设备目标领取 Provider、Base URL、主/视觉/备用模型、交互策略和 API Key；不会收到生图密钥。
AdsPower 扩展以自己的设备目标领取相同类型的多模态配置；不会收到 SellerPilot 生图密钥。
SKILL.md、不共享浏览器 Cookie，也不批准供应商、图片、Listing、广告预算、Etsy 写入或公开发布。Store Assortment Architect
用于创建、更新或审计版本化店铺规划。工具会先纠正模糊或不准确的市场表述，再把证据、假设和缺口分开；冷启动不要求先登录 Etsy。
安装与状态
$marqel-business-skill-manager update-all登录后的工具中心也可复制一键安装 / 更新指令；完成后重启 Codex。$marqel-business-skill-manager status基础调用
$cross-border-store-assortment-architect 基于品类、目标客户和市场种子建立首版店铺计划；先校正模糊成功口径，缺失证据保持为假设，不派发寻源。$cross-border-store-assortment-architect 以 supplier_capability_seed 模式评估【现有产品能力】；缺失市场、客户或预算时只作可逆假设，不提升业务就绪状态。$cross-border-store-assortment-architect 将已验证的店铺计划同步到 Marqel Web，并回读相同 store_plan_id、版本与组织；不要自动派发寻源。dispatchAllowed=false 固定不变。只有 existing_store 的卖家私域诊断需要对应 Etsy 会话，Marqel 设备授权不等于 Etsy 登录。首次验证
- 用 Manager 状态确认该 Skill 是工具中心当前受管版本。
- 发送冷启动指令，确认返回输入纠偏、
store_plan_id、正整数版本、结构/业务就绪两类验证结果和证据缺口。 - 确认结果不会为了满足样本数量而补入弱竞品，也不会把搜索卡片评论数写成单品评论。
- 只有执行同步指令后，才在 Web“店铺规划”页核对同一 ID、版本和组织的 readback。
商品验证与编排 Skills
商品验证和供应商执行是店铺计划下游的独立能力，通过版本化契约与 operation_id 协作；每条指令都可单独复制到 Codex。
验证市场、人群、区域、关键词、价格、利润与风险；也支持现有 Listing 审计和显式 Web 同步。
只为已批准的独立 operation_id 编排 1688 / 淘宝任务、证据评估与双平台对账。
Positioning Analyst
$cross-border-positioning-analyst 验证 store_plan_id=<store_plan_id> 下 assortment_slot_id=<assortment_slot_id> 的市场、人群、区域、关键词、价格、利润与风险；只输出证据、假设和缺口，不自动寻源。$cross-border-positioning-analyst 审计这个现有 Listing：<listing_url>；区分页面事实、市场证据、假设和缺失证据，并给出可验证的改版方向。$cross-border-positioning-analyst connect$cross-border-positioning-analyst status$cross-border-positioning-analyst sync --input /absolute/path/to/result.jsonSourcing Orchestrator
$cross-border-sourcing-orchestrator 为已批准的 assortment_slot_id=<assortment_slot_id> 创建独立 operation_id，并按 1688 后淘宝顺序创建证据任务；遇到登录墙或验证码暂停。$cross-border-sourcing-orchestrator 为 operation_id=<operation_id> 按 target-profile.json 向 1688、淘宝派发只读取证任务；遇到登录墙、验证码或安全校验立即暂停。$cross-border-sourcing-orchestrator 为 task_id=<task_id> 提交供应商证据评估；经济门开启时使用 source-backed-economics.json，并保留来源与时间戳。$cross-border-sourcing-orchestrator 对 operation_id=<operation_id> 执行 1688 与淘宝双平台只读对账；不领取新任务、不重试平台、不修改人工审核状态。配置边界
- 普通 Codex Skills 不配置 Web Base URL 或 API Key，直接使用 Codex 自身模型。
- 只有
image-proxy第三方代理生图需要在模型配置建立image_generation能力、分配组织成员并绑定 SellerPilot 制图场景。 - 共享 V2 设备会话不共享业务审批；每个店铺计划版本、商品 operation 和外部动作保留独立记录。
1688 / 淘宝供应商执行器
从公开 GitHub Release 下载，安装在普通 Chrome 中，仅用于 1688 / 淘宝；不要在 AdsPower Etsy Profile 中加载。
新手最短路径 · 5 步
- 从上方 GitHub 最新发布下载 ZIP 和
release-manifest.json。 - 确认 ZIP 的 SHA-256 等于清单中的
artifact_sha256；当前值为a495b19671a47cb63b5227624587d0fd1ca1bc2aff32cf8305e287fa7aa4650b，然后解压到固定目录。 - 普通 Chrome 打开
chrome://extensions，启用开发者模式并加载解压目录。支持 Chrome 114 及以上。 - 在插件发起设备授权，Web 核对
supplier-sourcing-chrome-runner后批准；回到插件确认 v0.1.8 和“配置已应用”。 - 在普通 Chrome 登录 1688 / 淘宝并领取一个只读测试任务；遇到登录墙或验证码立即暂停。
领取 operation_id 对应的 1688 与淘宝任务；核验要求数量的真实详情页，验证码出现时暂停。Etsy 浏览器工具
同一 GitHub 仓库保留两条互不覆盖的产品线。先按是否使用 Codex 与 Marqel Web 工作流选版本；不要把 2.0 当作独立版的原地升级。
main保留浏览器内 AI 侧边栏、竞品与趋势研究、报告和本地工作流，适合没有 Codex 的用户。
源码与安装说明 ↗下载独立版源码快照 ZIP ↓核对独立版 Release 证据 ↗edge2.0只执行 Web 已审批任务：页面预检、确定性草稿填充、隐私安全证据和终态对账；不在插件内做竞品分析。
源码与安装说明 ↗下载 Edge 2.0 源码快照 ZIP ↓怎样选择
- 没有 Codex、希望在浏览器中完成研究与运营辅助：选择
main的独立版。 - 已经使用 Codex 生成方案，并通过 Marqel Web 审批、派发和复盘：选择
edge2.0分支。 - 两个版本使用同一稳定扩展 ID，不能在同一个 Profile 中同时加载；切换前先停用或卸载当前目录。
- 从独立版切换到 2.0 会清理旧模型凭证、报告、监控任务、工作流断点和本地经营参数；没有兼容迁移。
- 扩展重载后刷新所有已经打开的 Etsy 标签页，再执行只读预检和受控验收。
Edge 2.0 新手安装与配置 · 6 步
点击“下载 Edge 2.0 源码快照 ZIP”。文件名应包含 etsy-growth-agent-edge2.0，不要下载 main。
完整解压 ZIP，打开内层同名文件夹，确认这一层直接包含 manifest.json。以后不要移动或删除该目录。
从 AdsPower 的 Profiles 页打开经营该 Etsy 店铺的 Profile；在该浏览器进入 chrome://extensions，开启开发者模式并选择“加载已解压的扩展程序”。最低 Chrome 116。
打开 Edge 侧栏 → 设置 →“连接设备”。浏览器会打开 Marqel 批准页；使用自己的 Web 账号核对 etsy-growth-agent 后批准。
AdsPower 一项填写 Profiles 列表最右侧的字母数字 ID，不是“序号”或“编号”；店铺一项填写 Etsy Shop Name。
点击“保存并报告到 Web”，刷新已经打开的 Etsy 标签页；回到 Web 工具中心确认 Edge 版本、运行时 ID、Profile 和店铺均已上报。
两个绑定项从哪里获得
- 回到 AdsPower 客户端的 Profiles 列表，找到当前正在经营该 Etsy 店铺的那一行。
- 复制最右侧 ID，例如
k1eulg7o。不要填写左侧“序号”或中间“编号”，也不需要进入 General 寻找 Profile 名称。 - 把该 ID 原样填入 Edge。它对应 AdsPower Local API 的 Profile ID（
user_id）；不要填 AdsPower 登录账号、代理 IP、Chrome 扩展 ID 或临时窗口编号。
- 打开自己的店铺主页，地址通常是
https://www.etsy.com/shop/ExactShopName或ExactShopName.etsy.com。 - 复制 URL 中
/shop/后面的部分，例如地址是etsy.com/shop/MyStudioCo，就填写MyStudioCo。 - 不要填登录邮箱、Etsy 用户名、商品 URL、店铺显示标题或
me。Edge 保存时会统一成小写用于匹配；店铺改名后必须在没有活动任务时重新绑定。
browserProfileRef 字段名，但用户填写值固定为 AdsPower 的 Profile ID。“RB-01～RB-07”到底是什么？查看七项发布验收
结论：核心功能已经写入源码并通过本地测试；尚缺的是在指定真实环境中的逐项验收证据，所以当前是“源码候选 / 受控试用”，不是“功能完全没有开发”。
- 构建与权限：核对 Git、版本、扩展 ID、Chrome 版本和最小权限。
- 单一界面：确认 Dock、侧栏、设置和节点后台没有重复或越权入口。
- 页面与隐私：确认公开页、编辑页和敏感账号／订单／付款页面被正确分类和遮罩。
- 任务与租约：确认只有 Web 精确批准且绑定一致的任务可以领取、续租和恢复。
- 字段填充：在当前 Etsy 编辑器变体中验证允许字段、失败回滚，并确认绝不点击 Save 或 Publish。
- 安全证据：确认截图先脱敏、只绑定当前任务，并且不会发送到模型或第三方分析端点。
- 人工保存与终态回读：确认人工保存草稿后，ID、URL、失败状态和不重复执行规则能在 Web 对账。
安装完成标准
- 扩展管理页显示
Marqel Etsy Edge版本2.0.0，没有加载错误。 - Edge 设置显示设备“已连接”，两个绑定项显示“已绑定”。
- Web 浏览器扩展卡片能看到同一运行时 ID、AdsPower Profile ID 和 Shop Ref。
- 刷新 Etsy 页面后，Dock 只有任务、Web、设置；竞品分析应从 Codex 的 Etsy Growth Strategist 发起。
- 第一次只执行页面预检；没有 Web 已批准任务时，Edge 不应填充字段或保存证据。
Etsy Open API 申请与配置
只有计划通过 Etsy 官方接口读取店铺私有数据时才需要。Growth Agent 的 AdsPower 登录、Marqel 设备授权和模型配置仍不要求 Etsy API Key；这三套能力彼此独立。
适合卖家为自己的店铺制作报表、自动化或内部工具；只能授权注册时对应的店铺。
先申请 Personal App 并接受更深入审核；需要规模化服务其他卖家时，再申请 Commercial Access。本期 Web 连接页暂不支持此模式。
新手最短路径 · 5 步
- 先确认 Etsy 店铺已激活、状态正常，并且账号下没有其他活跃 App；只有新注册账号、尚未完成开店时先不要申请。
- 登录 Etsy Developer Portal ↗。只服务自己的店铺选择 Create a seller app ↗；计划服务其他卖家时选择 Personal App，不要误用 Seller App。
- 准确填写应用用途并同意 Etsy API 条款，随后在 Your Apps 查看状态；只有显示 Approved 后，API keystring 和 shared secret 才能使用。
- 登录 Marqel 后打开 Etsy API 连接 →，复制页面给出的精确回调地址到 Etsy App 设置；回到页面加密保存凭据并验证 API Key。
- 点击“前往 Etsy 完成店主授权”，在 Etsy 官方页核对自己的店铺及
shops_r、listings_r与transactions_r三项只读权限；回到页面确认店铺与 Token 有效期。不要在截图或对话中粘贴 Key、Secret 或 Token。
凭据和有效期边界
- API keystring 与 shared secret 用于应用身份；访问私有店铺数据还必须取得店主授权的 OAuth Token。
- OAuth Access Token 当前有效期为 1 小时；Refresh Token 当前有效期为 90 天，可按官方刷新流程换取新 Token。它们与 Marqel 的 30 分钟 Access／滚动 90 天设备会话不是同一套凭据。
- 回调地址必须与 Etsy 登记值逐字匹配，包括协议、大小写、子域名、路径和结尾斜杠。
- 本期固定只读
shops_r、listings_r与transactions_r；没有 Listing、订单或广告写入权限。已有旧连接需要重新完成一次店主授权才能取得新增的交易只读权限。
商品、成本与周度经营
这是 Control Center 内置能力，不需要安装 Skill 或浏览器插件。内部 SKU 与渠道解耦，可先服务 Etsy，也能在未来复用于其他销售渠道。
支持 Etsy-first 自动同步，也支持 Web-first 先建 SKU；上架状态保存在独立渠道关联中。
按批次追加供应商价格，为订单行分配实际批次，并维护每笔订单的实际物流费用。
有官方连接时自动读取订单和商品；成本完整后再输出贡献利润，缺失数据不补零。
有 Key 与无 Key 的使用边界
- 已获批准的官方连接：服务端按固定周频自动读取商品、变体、库存、订单、交易、支付、退款、账本、评价数量和履约事实，并同步到通用 SKU 与订单账本。
- 暂时没有 API Key：仍可在 Web 建 SKU、维护供应批次、准备渠道关联和 Listing 草稿；但 Etsy 订单和商品事实不会被标记为“已自动同步”，周报也不会伪造 Etsy 指标。
- 店主授权不等于免除平台规则：面向其他卖家提供工具，应使用 Etsy 批准的 Personal App／Commercial Access；Seller App 只适用于卖家自己的单店自用集成。
- 插件边界：插件可执行用户明确批准的页面任务和终态回读；除非 Etsy 明确书面授权，不把浏览器扩展作为批量读取、分析或绕过官方 API 的通道。
SellerPilot Product Image Industrial
把已确认的产品事实、定位和 Listing Brief 变成可审核 Etsy 图片组。主制图 Skill 与第三方生图代理均由工具中心的一键安装 / 更新作业交付。
统一安装：使用工具中心一键作业
不要再单独复制 GitHub 安装提示。工具中心的“一键安装 / 更新”会把 sellerpilot-product-image-industrial 与 image-proxy 一起安装到所选 Codex 或 ChatGPT Work 环境，并在更新已有受管版本前自动备份。
image_gen 是 Codex 系统能力，不需要由本作业重复安装。先选择正确的工作模式
提供已批准事实、源产品图、平台、语言与图片角色；先做身份锁和 1–3 张锚点图，通过后再并行完成其余图片。
明确只要一张、禁止文字和无依据配件；仍执行身份、事实、平台构图与最终交付检查。
用于探索 2–3 个方向时要明确写“快速草图，不作为最终交付”，避免误走完整生产流程。
输入现有图片或 tldraw 标注，只修复失败角色或标注区域，不重生成已经批准的资产。
高质量请求应包含什么
- 身份来源：标明哪些是自有产品图、哪些只是竞品参考；竞品只用于分析，不作为产品身份。
- 平台与受众：写明 Etsy、目标国家或语言、买家场景、图片数量和需要的主图／场景／细节／信息图角色。
- 事实与禁区：列出已经确认的材质、尺寸、结构、配件和允许出现的文案，同时写清未知项和不得出现的声明。
- 输出模式：说明是正式套组、单张正式图、快速草图、审计还是局部返工；未说明时，多图正式需求按质量生产处理。
- Provider 偏好：通常让 Skill 先检查 Codex 原生
image_gen；只有明确要求第三方代理时才指定third_party_proxy。
不要把所有图片一次性塞给 Provider；保留原图作为分析证据，按角色准备必要的上传副本。
锚点图先通过产品身份、物理真实性或表面图案检查，再扩展整组，返工成本明显更低。
使用上一轮 QA 或 tldraw 标注，比“整组重做”更稳定，也避免重复调用 Provider。
非中英文尤其要先审语言、脚本方向与断行；最终还要检查成图里实际可见文字，而不是只看提示词。
Web 配置，已安装工具自动领取并生图
- 一级用户在 Web“模型配置”创建
image_generation能力，填写 HTTPS Base URL、主模型和 API Key；选择“全员共享”或为下属普通用户添加成员专属 Key。 - 一级用户在 Web“工具能力”把该能力绑定到
SellerPilot 制图场景；保存后不需要向普通用户发送配置值。 - 已经安装受管
image-proxy的普通用户直接在 Codex 发送$image-proxy generate 根据已批准需求生成一张 Etsy 主图或edit；工具会在第三方请求前自动从 Web 拉取并安全应用当前用户的 Base URL、模型和 Key。 - 缺少设备会话时，工具自动打开 Web 批准页并等待；普通用户只需用自己的 Web 账户核对、批准，原调用随后自动继续，无需复制设备码或再发同步指令。
$image-proxy dry-run …是零网络、零费用的请求预检；$image-proxy status是非敏感状态查看。两者都不是首次配置步骤。- 一级用户和普通用户可在 Web“设备与授权”查看配置是否
applied、stale或sync_failed；一级用户轮换 Key 后，下一次真实调用自动取得新版本。
$marqel-business-skill-manager sync-image-config，一次修复 SellerPilot 与 image-proxy 并核对摘要。正常安装、更新、生成和编辑不要求用户手工同步，更不要求复制粘贴任何 Provider 凭据。完成标准
sellerpilot-product-image-industrial与image-proxy均作为受管 Skill 安装，并与marqel-control-center-auth位于同一个用户级 Skill 根目录；- 真实
generate/edit会先自动拉取sellerpilot-image配置，失败时在 Provider 请求前停止； - Web 可回读
applied状态；所有网页、Codex 输出、安装日志和报告都不显示 Base URL、API Key、Token 或本机凭据内容。
$sellerpilot-product-image-industrial 根据已批准的 Image Production Request 生成 Etsy 主图与信息图；先检查内置 image_gen，原生可用则使用 native_codex；明确使用第三方代理时调用 image-proxy，它会自动领取 Web 配置，再做身份一致性 QA。Etsy Listing Ops
根据已批准商品事实、图片和供应商证据形成可审阅 Listing 草稿。
常用指令
$etsy-listing-ops 为已批准 operation_id=<operation_id> 生成英文 Listing 草稿；绑定图片 manifest 与证据来源，不创建 Etsy 写入任务。$etsy-listing-ops --operation-id <operation_id> --title "<title>" --description "<description>" --tags "tag one,tag two" --price "24.00" --currency USD$etsy-listing-ops --operation-id <operation_id> --input /absolute/path/to/listing-draft.json --dry-run首次验证
- 确认 Skill 已安装，并通过 V2 设备授权读取一个已批准的
operation_id。 - 先使用
--dry-run，确认 Product Review、图片 QA、manifest 和证据门全部通过。 - 创建后确认返回的是 Control Center 草稿，并且
publishAllowed=false、writeStatus=not_started；不得自动创建 Etsy 写入或公开发布任务。
Etsy Campaign Operator
根据已批准 Listing、图片和可审计指标建立广告计划、预算护栏、审批包与复盘建议；不会自动产生花费。
常用指令
$etsy-campaign-operator 为已批准 Listing 和图片 manifest 建立 Etsy Ads 首发测试建议、预算护栏与审批包；不启用广告、不修改预算。$etsy-campaign-operator 根据 campaign-brief.json 创建日预算 10、上限 30、目标 ROAS 2.5、最大 CPA 8 的首发计划；只生成计划和审批包，不启用广告。$etsy-campaign-operator 提交 campaign-plan.json 进入广告花费审批；成功后必须显示 AWAITING_SPEND_APPROVAL，不得执行 Etsy Ads 写入。$etsy-campaign-operator 使用 etsy-ads-evidence-bundle.json 评估 campaign-plan.json；证据缺失、过期或口径不一致时返回 INSUFFICIENT_EVIDENCE。$etsy-campaign-operator 为 campaign_id=<campaign_id> 提交 recommendation.json 和同一 Evidence Bundle；暂停或扩量仍需人工审批与 Etsy 平台回读。首次验证
- 确认 Listing Readiness、SellerPilot 图片 QA、预算上限和证据来源都已存在。
- 先生成计划并提交审批，确认状态为
AWAITING_SPEND_APPROVAL，而不是“广告已启用”。 - 使用 Growth Agent 下载的同一个 Evidence Bundle 同时执行 evaluate 和 recommend；缺失或口径错误时应返回
INSUFFICIENT_EVIDENCE。 - 确认建议仍要求人工审批，且没有自动执行 Etsy Ads 外部动作。
Intelligent Outreach
通用站外社媒推广 Skill；不读取 Etsy 会话，也不取得 AdsPower 控制权。
promotion-object-handoff.v1 作为输入；不要提供 Etsy Cookie。首次验证
- 确认 Skill 已安装并能读取交接单中的商品、渠道目标、素材和声明边界。
- 发送下方基础调用，确认只生成渠道策略与内容草稿。
- 确认没有登录账号、自动发布或产生预算。
$intelligent-outreach 根据已批准的 promotion-object-handoff.v1 生成站外渠道策略和内容草稿；遵守目标社区规则，不登录 Etsy，不自动发布。常见问题
设备码无法批准
确认 Web 用户仍启用且未到期，设备码在十分钟内，并逐字核对 clientType、clientId 与设备名称。过期后从客户端重新发起。
页面显示的几十分钟是不是设备授权有效期
不是。那是短期 Access 凭据，默认 30 分钟并自动刷新。真正维持设备授权的是滚动 90 天 Refresh Session；只有被撤销、用户停用或 Refresh 到期后才需要重新授权。
设备授权后 Base URL / API Key 会不会自动配置
会，按目标自动处理。1688 / 淘宝执行器和 Etsy Growth Agent 在批准后领取各自的多模态配置；受管 image-proxy 与 sellerpilot-product-image-industrial 在安装/更新完成后分别自动领取当前用户获授权的 Base URL、模型和 API Key，image-proxy 每次真实生成或编辑前还会刷新。缺少会话时工具自动打开 Web 批准页，普通用户批准后原调用继续。需要手动刷新受管生图配置时，只使用 $marqel-business-skill-manager sync-image-config，它会同时核对两个消费者；普通用户不复制配置，也不直接运行 Auth 或单个消费者脚本。除这两个受管生图消费者外，其他 Codex Skills 不领取 Web Provider 配置。
为什么供应商插件没有拿到生图 API Key
这是正确的最小权限结果。供应商与 Etsy 插件只需要多模态 LLM；SellerPilot 仅在第三方代理路径需要生图模型。场景中即使残留其他模型引用，服务端也不会把不属于目标能力的配置下发。
1688 任务为什么暂停
登录墙、验证码、安全校验或页面结构无法可靠读取时必须暂停。这不是失败；由用户完成验证后从相同任务恢复。
为什么模型能力页只有三个工具
页面只显示可能需要 Web 下发模型配置的目标：Etsy Growth Agent、供应商浏览器执行器与 SellerPilot 第三方生图代理。SellerPilot 原生 image_gen 路径以及店铺规划、商品分析、编排和 Listing 等 Codex Skills 不需要重复配置。
不同管理层能看到哪些用户状态
平台管理员可在“账户与权限”查看全部用户、修改普通/一级用户等级并维护组织归属；一级用户只在“组织管理”查看本组织注册用户、组织名称和自动邀请码。普通用户不显示组织管理。任何页面都不会显示密码、Token、Cookie 或 Provider Key 明文。
团队成员可以共用模型 API Key 吗
可以。一级用户在模型集群的第一行勾选“全员共享”后，旗下普通用户默认继承同一 Key；取消勾选后，该 Key 只供当前一级用户使用。需要不同 Key 时点击“添加用户 API Key”，每行选择一位旗下用户。成员专属行优先于共享行。
Image Proxy 与 SellerPilot 主 Skill 分别验收
一键安装 / 更新会把同一份 sellerpilot-image 配置分别应用到 image-proxy 和 sellerpilot-product-image-industrial，不再用前者的成功状态代替后者。
- 已有且属于同一 Web 账号的有效设备会话会直接复用；只有缺少或失效时才打开设备批准页。
- Web 已配置第三方生图时，两个消费者都必须显示
applied、Key 可用且delivery digest一致，安装作业才显示完成。 - Web 未配置时，两边都会清除旧的受管配置并一致显示未配置，避免继续使用过期 Key。
- 工具中心“生图 Provider 配置状态”分别回读两项结果；
$marqel-business-skill-manager status可做本机只读复查。
$marqel-business-skill-manager sync-image-config先校验 Auth、Manager、image-proxy 与 SellerPilot 都是工具中心当前受管版本；随后复用会话或自动打开 Web 设备批准，同时导入两个消费者并核对相同 delivery digest。它不升级 Skill、不迁移独立安装、不生成图片，也不强制切换用户明确选择的外部 Provider。$sellerpilot-product-image-industrial provider-statusstatus 是同义命令。两者只显示应用状态、可用性、delivery revision/digest 与当前 profile，不显示 Base URL 或 API Key。主 Skill 显示“已下发可用，但当前仍优先原生 image_gen”是允许的：配置已备好，但自动路由仍尊重原生能力优先。update-all 备份修复。下载失败会换新短时链接重试，失败后只恢复同一 job_id。Etsy Growth Strategist
承接独立版浏览器中的竞品分析、店铺优化、Listing 诊断、评论洞察与趋势观察。Codex 形成证据化增长实验，Web 保存版本与审批；Edge 2.0 不运行这些分析。
限定对象、市场、关键词、时间与证据来源，区分公开事实、私域回读、假设和缺口。
保存 etsy-growth-cycle.v1、基线、主 KPI、目标、观察窗口、护栏、版本和批准状态。
批准后由 Listing Ops、Campaign Operator、Store Architect 或人工执行；Edge 只处理获批 Etsy 页面任务并回读。
<listing_url_1>、<国家或地区>、<关键词> 等内容都需要换成你的真实输入；不要连同尖括号原样发送。竞品基准和公开店铺诊断必须给出 URL。若分析本店转化、订单或广告等私域指标，仅有 URL 不够，还需要获授权 Etsy API 回读或用户导出。$etsy-growth-strategist 以 competitor_benchmark 模式分析以下 Etsy 竞品 Listing：<listing_url_1>、<listing_url_2>、<listing_url_3>；目标市场=<国家或地区>；核心关键词=<关键词>；观察日期=<YYYY-MM-DD>；只使用公开可见证据，形成一个主假设与主 KPI，不让 Edge 打开竞品页。$etsy-growth-strategist 以 shop_audit 模式诊断 Etsy 店铺：<https://www.etsy.com/shop/ExactShopName>；目标市场=<国家或地区>；分析区间=<YYYY-MM-DD 至 YYYY-MM-DD>；合并公开页面、获授权 Etsy API 回读和用户导出，缺失转化或订单证据时保持 insufficient_evidence。$etsy-growth-strategist 以 listing_optimization 模式为 operation_id=<operation_id> 设计一个单变量实验；实验对象=<标题、主图、价格、描述或标签中的一项>；写明基线、目标、观察窗口、护栏与停止条件，批准后交给 etsy-listing-ops。$etsy-growth-strategist 以 review_voice 模式分析评论证据：<Etsy Listing URL、评论导出文件绝对路径或已绑定证据>；目标市场=<国家或地区>；提取购买动机、异议、质量与交付问题，提出一个可验证的图片或文案实验。$etsy-growth-strategist 以 trend_watch 模式验证趋势假设：<要验证的趋势或季节性判断>；目标市场=<国家或地区>；核心关键词=<关键词>；观察日期=<YYYY-MM-DD>；记录来源与淘汰条件，不把趋势信号写成销量保证。$etsy-growth-strategist 将 </absolute/path/to/growth-cycle.json> 同步到 Marqel Web；回读相同 operationId、cycleId、version 与 externalActionPerformed=false。