AI 配置活动实操流程
第一步：录制操作并生成 Skill
通过屏幕录制插件让 AI 学习操作步骤并生成 Skill。需注意两点：
- 必须使用第一梯队的大模型，确保其理解语义而非单纯模仿像素，避免因屏幕分辨率变化导致执行失败。
- 若 Agent 包含"XX for Chrome"等选项建议关闭，防止其绕过 Skill 直接控制浏览器获取数据。
第二步：确认 Skill 交付物
Agent 将从数百个录制接口中提取核心业务流程，过滤搜索、文档浏览等噪声请求，封装为可参数化的 Skill，并列出每一步调用的 API 及其作用。
第三步：配置测试活动验证
通过自然语言指令让 Agent 使用该 Skill 配置一个测试活动（包含名称、商户号、规则、白名单等）。首次执行可能需手动授权，或在开发者工具 Network 标签页获取 Cookie 提供给 Agent，以通过系统身份验证。若测试结果符合预期，即可准备上线；若不一致，需反馈修正直至达标。
第四步：下达正式批量指令
指令 Agent 配置 100 个活动，明确活动命名规则（支持动态参数）、商户号及 UID 白名单的数据源（如飞书文档特定列）、业务线归属，以及金额、门槛、预算等动态参数。若 Skill 已包含提交审批逻辑，AI 将自动完成全流程。
第五步：人工最终审核
对于涉及资金投入和产品体验的关键活动，仍需人工复核。AI 能大幅提升效率，但无法承担决策责任。至此，整体工时下降超过 99%。相比熟手单个人工配置需 10-20 分钟，AI 实现了百倍效率提升。这将推动团队结构优化：淘汰不愿学习者，保留人员效能倍增，进而获得更高薪酬回报。
Skill 实现原理与思路拆解
总体架构
该 Skill 本质上是一个API 编排器（API Orchestrator）。它不重写业务逻辑，而是将营销平台后端的 8 个 API 接口按固定顺序串联，实现“克隆/创建活动”的完整闭环。
大白话：如同在银行办业务，需依次经过取号、填表、提交、审批等窗口。Skill 的作用就是自动跑完所有窗口，无需人工干预。
第一步：Cookie 管理（身份认证）
专业术语：基于 Cookie 的会话认证。Skill 启动时检查本地 Cookie 文件，若存在则读取为请求头，否则提示用户通过授权链接获取。
大白话：Cookie 如同门禁卡。平台只认卡不认人，保存卡号后即可自动通行。
实现细节与缺陷：Cookie 文件持久化路径为/data/userdata/XX-skill/.cookie。已知缺陷在于ensure_cookie()函数仅检查文件存在性，未将内容加载到环境变量，在严格模式下可能导致后续引用报错，运行前需手动导出。
第二步：构建 HTTP 请求头
专业术语：HTTP 请求头模拟。Skill 为 tiger 和 marketing-draft 两套后端服务分别构建完整请求头，包含 GraphQL 方法标识、服务路由、前端版本号及浏览器指纹等。
大白话：后端服务有许多“暗号”，如页面来源、前端版本、浏览器型号等。若口令不对，请求将被直接拒绝。
核心逻辑是通过tiger_headers()和draft_headers()函数拼接 curl 的-H参数列表。
第三步：查询源计划信息
专业术语：基于 CreateUserId 和 PlanNo 过滤器的计划列表查询。通过 tiger 服务的 QueryPlanInfo 方法，发送 GraphQL 风格 POST 请求。
大白话：克隆计划前需先定位目标。此步骤即“搜索”，列出指定用户创建的计划并筛选出待克隆项。
请求参数示例：
{"PlanStatus": ["INIT"], "CreateUserId": ["xxx@yyy.com"], "PageNo": 1, "PageSize": 200}响应返回包含 PlanNo、PlanName、PlanStatus 等信息的 PlacementPlanInfoList 数组。
第四步：查询投放位信息
专业术语：投放位资源查询。通过 PlaceNo 查询该位置的元数据，包括资源编号、名称及可用计划规则等。
大白话：投放位即“广告位”。此步骤查询位置基本信息，供后续创建计划时调用。
第五步：查询源计划详情
专业术语：通过 PlanNo + PlanModifyNo 双键查询计划完整配置，涵盖通用字段（commonFields）和素材字段（materialFields）。
大白话：前三步是“找到人”，这一步是“看清全貌”。需获取活动名称、权重、时间段、白名单、配置表达式等所有参数，确保克隆无遗漏。
响应结构包含 commonFieldsValues（通用配置）和 materialFieldsValues（素材配置），作为后续修改的基础。
第六步：创建草稿
专业术语：在 marketing-draft 服务中创建克隆类型的草稿记录，关联源计划的 BusinessId。
大白话：克隆第一步是“拍照”复制一份生成草稿，此时尚未提交至平台。
请求参数示例：
{"SopId": "时间戳生成的唯一 ID", "Name": "操作记录", "Scene": "PayResultLotteryFree", "Type": "clone", "BusinessId": "源计划 PlanNo", "OperationSceneType": "auto_save"}响应返回草稿 ID（DR 开头数字），作为后续修改的凭证。已知缺陷：create_draft() 函数中处理 restrict_merchant_ids 时存在语法错误，批量任务中已通过独立 Python 脚本生成 payload 规避。
第七步：修改草稿数据
专业术语：将新参数（活动名称、商户号、UID 白名单、业务线、权重等）覆写入草稿的通用和素材字段并保存。
大白话：草稿建立后，需将名字、商户号、白名单等新内容填入，覆盖原有值。
主要修改字段包括 PlanName、UidWhiteList、RestrictMerchantIdList、BusinessTeam 及 ConfExpressions 等。响应 DR000000 表示成功。
第八步：创建新计划
专业术语：将修改后的草稿数据提交至 tiger 服务，调用 PlanInfoAdd 方法创建新的投放计划记录，这是核心写入操作。
大白话：草稿修改完毕后，需“提交申请”才能在平台真正创建新活动计划。
关键坑点：PlanInfoAdd 响应不返回新计划的 PlanNo 和 PlanModifyNo，仅返回状态码和 RecordNo。若直接解析响应会导致误判失败。正确做法是通过计划名称再次查询获取新编号。
第九步：激活计划
专业术语：调用 UpdatePlanStatus 方法将计划状态从 INIT 变更为 RUNNING，触发审批流程（实际进入 APPROVING 状态）。
大白话：计划创建后处于“待激活”状态，此步骤即“按下启动键”进入审批流。
第十步：验证
专业术语：重新调用 QueryPlanInfo 查询新计划，验证状态和参数是否符合预期。
大白话：完工检查，确认名称、商户号、状态无误后方算完成。
批量处理思路
专业术语：批量创建时，查询类操作（步骤 1-3）仅执行一次获取模板，写入类操作（步骤 6-10）循环执行。采用 Python 脚本实现循环、延时及错误追踪，中间结果持久化至 JSON。
大白话：如同工厂流水线，先确定“模板”，再重复执行“建草稿→改草稿→提交→激活→验证”。每个活动间增加间隔以防压垮平台，出错记录后继续，最后汇总。
批量脚本关键设计：
- 数据来源：指定飞书表格的列和规则。
- 速率控制：活动间隔 1 秒，PlanInfoAdd 后等待 2 秒。
- 容错机制：每步独立 try/catch，失败记录至 results 数组。
- 断点续传：中间结果写入/tmp/batch_create_log.json，防止崩溃丢失进度。
- 分阶段执行：先全部创建（INIT 状态），再统一激活。
Skill 产出机制与限制分析
Skill 是如何产出的？
涉及 Skill-creator 的录制机制，其描述为“从几百个录制接口中提取核心业务流程，自动链式重放”。工作原理如下：
- 流量捕获：通过代理（MITM）捕获浏览器操作营销平台时的每一个 HTTP 请求（URL、Method、Headers、Body、Response）。
- 流程提炼：从原始请求中识别核心业务链路，区分查询、写入及前置依赖。
- 生成脚本：将请求模式固化为带参数化的 curl 调用脚本（SKILL.md + run.sh）。
大白话：如同有人全程录像你的做菜过程并写成菜谱。但录像机只能记录动作（HTTP 请求），无法记录思考（浏览器渲染、JS 执行），因此产物本质是“一堆 curl 命令”而非“浏览器自动化脚本”。
为何需要手动输入 Cookie 且禁止浏览器自动化？
第一，录制方法论的天然结果。Skill-creator 录制的是 HTTP 流量，产出的是 curl 重放脚本。“禁止浏览器自动化”并非主动限制，而是工具能力边界——它从未录制浏览器操作，自然无法重放。
第二，沙箱环境约束。许多公司沙箱策略禁止启动监听端口的进程。Playwright/Puppeteer 等工具需通过 WebSocket 通信（本质是端口监听），因此在沙箱内物理上无法运行本地浏览器。改进方案是采用 agent-remote-browser，将浏览器置于远端服务，但这不在当前 Skill 设计范围内。
第三，SSO 与风控的脆弱性。营销平台涉及复杂的 SSO 登录、重定向及 JS 执行。即使通过浏览器自动化走通，Cookie 过期需重跑登录流程，且易触发风控（验证码、异常检测）。相比之下，"一次手动提供 Cookie + 长期自动调用"运维成本更低。
第四，确定性与可审计性。Curl 调用具有确定性，输入输出一致，易于排查问题。浏览器自动化受 DOM 加载时序、网络延迟等影响，失败模式多且难复现。
未来改进方向：接入 agent-remote-browser 处理 Cookie 获取（只需登录一次并持久化），其余 API 调用仍保持 curl 方式，兼顾便捷性与确定性。
