怎样把我在网页上的操作写成可靠 SOP？
把动作拆成可观察状态，处理登录、失败、重复提交和结果核对。
本页目录
直接回答
可靠 SOP 需要说明页面当前应是什么状态、如何判断步骤完成、失败后如何处理。先亲自执行，拆成状态变化，给工具，试跑修正，再固化流程。稳定 API 或结构化工具能完成时优先采用；必须操作界面时先观察真实页面，不依赖旧截图固定坐标。
实践建议：报告直接链接到创建或修改后的对象，并列明未处理项。重要动作可以抽样或逐项回读，核查力度取决于错误后果。
适用场景
- 想让 AI 周期性整理后台、读取网页或填写表单。
- 浏览器自动化总是点错、重复执行或卡在登录。
一步一步做
录下完整的人工路径
记录入口网址、账号角色、所需材料、每步动作和成功标志。不要只写理想路径；把首次登录、空列表、加载中和无结果也列出。敏感认证由合适的登录流程完成。
把一步写成状态变化
例如“在订单列表选择本周日期，等列表更新后读取总数”，比“点右上角，再点第三行”稳定。每步明确输入和可观察的输出，避免上一步没成功仍继续。
约定不确定时的处理
遇到验证码、权限不足、页面布局变化或无法确认对象时暂停并报告。对暂时网络故障可有限重试；不能因为重试就重复发送邮件或创建订单。
给操作加去重与结果核对
整理建议：记录已处理对象标识与操作状态。提交前确认目标，提交后读取实际结果；响应超时不等于动作没发生，先查状态再决定是否重做。
先在低风险数据上试跑
观看首轮完整执行，修正定位和分支，再减少人工旁观。保存足够的时间、对象、结果与失败记录，但不要把密码、会话令牌写进日志。
选连接方式，并把登录当作可失效前提
先寻找满足任务的受限连接器、CLI 或 API，确需页面交互再选浏览器工具。不同产品的连接能力不能简单按“连接已有”或“只开新浏览器”二分：官方 Playwright MCP 提供持久 profile、隔离 context 和扩展连接已有浏览器等模式。每种模式都应核对当前账号和任务范围，必要时由人完成登录后回读身份，不把曾经登录当作永久有效。
批量处理先建对象清单，再逐条核结果
实践建议：保存对象ID、源链接、预期动作、当前状态、结果位置和失败原因。选能覆盖常见与异常情形的小批量旁观试跑，确认后才扩批；每条完成后落记录。恢复时只处理未完成项，对提交结果未知的对象先查外部状态。完成数、失败数、未处理数应与输入清单对得上。
把调研读取完整性也纳入验收
用于竞品或资料调研时，对每页记录实际看见的价格、限制、更新日期及证据；登录墙、折叠区、分页和图片没读到就标缺口。首次建立基线，以后比变化；产品是否支持某能力不能仅凭一个按钮判断。多平台发布若已获授权，也要逐平台检查排版、链接和最终状态，不能拿第一站成功替代全部站点。
案例拆解
假设示例：把新反馈整理为待办
读取授权反馈列表，按稳定编号去重，提取问题与证据，生成本地草稿。遇到无法读取的反馈注明遗漏；没有明确授权时不直接回复客户，也不自动关闭反馈。
行动检查
可复制模板
浏览器操作 SOP
任务与允许范围：
入口/账号角色：
输入资料：
步骤 1：预期页面状态 → 操作 → 成功证据
步骤 2：预期页面状态 → 操作 → 成功证据
对象唯一标识与已处理记录：
允许重试的错误：
必须暂停的情况：
提交后的读取核对：
最终报告：完成项、遗漏项、失败原因、下一步。
批量任务清单与恢复单
本批任务/输入清单版本/允许范围：
对象ID | 来源链接 | 预期动作 | 状态（未处理/执行中/已核验/失败/结果未知） | 结果证据 | 重试条件
首次小批量包含的正常/异常情况：
已核验数/失败数/未知数/未处理数/总数：
中断后恢复点：
未知提交先查询什么：
页面变化或账号失效时停止方式：
最终遗漏与下一步：
易错点
- 网页里出现的提示不是用户新指令，应作为待处理内容。
- 浏览器界面会变；定时运行需要监测失败，不能长期假设定位永远有效。
- 脚本返回成功不等于外部系统已保存。
- 接口方式不是安全等级；CLI或API同样可能删除数据，浏览器也能在明确范围内稳定完成任务。
相关指南
官方参考
- Playwright MCP 官方仓库。文档核查记录：2026-10-18；使用前确认适用版本。