AI 接单实战：老网站 Bug 修复＋验收录像，如何做成标准化轻量服务

先说结论：卖的是验收证据，不是“我会用 AI”

对个人开发者来说，“帮我把旧网站修好”太宽泛，客户很难判断要付多少钱，你也很容易被无休止的加需求拖住。更小、更容易交付的产品是：一个获授权的问题、一条约定好的验收路径、一份修改说明和一段能复核的验收录像。

AI 在这里是加速器，不是承诺本身。它可以帮你整理报障、解释控制台日志、提出可能的原因、生成测试草稿；但最终是否修好，要由你用原始复现、修复后的同路径操作、自动化结果和人工检查共同证明。客户购买的是一套可复现、可验证、可回退的结果。

可引用摘要： 老网站小 Bug 轻量单的最小可售单元，是“一个问题＋一条验收路径＋一套交付证据”。AI 负责缩短排查时间，人负责授权、改动判断、风险控制和最终验收。

这个轻量单适合谁，不适合谁

你至少要能读懂浏览器控制台、运行基本命令、修改少量 HTML/CSS/JavaScript 或后端模板。你不需要一开始就承诺重构整站，但必须知道什么时候应该停止接单并转给更有权限的团队。

适合纳入轻量单	不应直接接手
表单按钮点击后无提示、前端校验失效	绕过登录、权限或验证码
手机端样式溢出、菜单无法展开	盗号、支付、资金划转
图片路径错误、页面资源 404	生产数据库直接改写
一个明确页面的接口错误提示	未授权的安全测试或渗透
已有测试环境、可回滚的小范围模板修改	医疗、法律、金融结论型业务逻辑

接单前要确认四件事：客户是否拥有系统或得到维护授权；是否有测试环境或可复制的部署方式；是否能拿到脱敏后的复现信息；上线后能否回滚。缺任何一项，都只能做咨询或复现报告，不能擅自修改线上系统。

把服务写成一页范围合同

用一页范围说明代替“先看看再说”。它不是复杂合同，但要让双方对完成条件有同一个理解。

1. 问题：用一句话描述故障，例如“商品页点击提交后，按钮变灰但没有成功提示”。
2. 范围：限定页面、浏览器/设备、测试账号、允许修改的仓库或文件夹。
3. 验收路径：写出从打开页面到看到结果的每一步，成功结果要能截图或录制。
4. 交付物：问题复现说明、修改文件清单、测试结果、验收录像和回滚说明。
5. 不包含项：重构、视觉改版、服务器迁移、未授权数据处理和第二个独立问题。
6. 变更规则：出现新页面、新接口或新的业务规则时，先暂停并重新确认范围。

报价前可以把这张表发给客户填写：

问题	客户需要提供	你要确认	通过标准
表单提交失败	URL、复现步骤、脱敏截图	测试账号与授权	成功提示出现，刷新后状态符合约定
移动端溢出	设备/视口、页面范围	是否有设计稿	指定视口不出现横向滚动
资源 404	出错 URL、部署方式	仓库和回滚点	资源返回预期状态，页面无新增控制台错误

七步 SOP：从报障到录屏交付

1. 接收报障、授权和脱敏

让客户先提供问题描述，而不是直接发一串生产密码。把姓名、手机号、订单号、Cookie、Token 和真实用户内容替换成占位符。需要登录时，让客户创建短期测试账号，并约定失效时间。

把授权写在工单或邮件里：允许你访问哪个环境、哪个页面、哪个时间窗口，允许做哪些操作。没有授权记录，不要为了“验证一下”去试探后台入口。

2. 做最小复现，不急着改代码

先把环境、浏览器、视口、账号角色、操作步骤和实际结果写成复现卡。打开开发者工具同时记录 Console、Network 和页面截图；只保留解释问题所需的最小请求信息，不复制完整请求头。

复现卡至少包含：

环境：staging.example.test（示例域名）
浏览器：Chromium，桌面视口
步骤：打开商品页 → 填写脱敏测试数据 → 点击提交
实际：按钮进入 loading，10 秒后恢复，页面没有成功或失败提示
预期：显示成功提示，并清空表单
证据：时间、截图、脱敏后的控制台错误摘要

这是一个虚构格式示例，不代表真实客户案例。先复现再修复，可以防止把“网络慢”“账号权限不足”误判成代码 Bug。

3. 让 AI 生成假设，不让它替你下结论

给模型的输入应是脱敏后的复现卡、相关代码片段和错误摘要，并明确要求它列出多个假设、验证方法和可能副作用。不要把整个仓库、环境变量或客户数据直接粘贴进去。

一个可复用的提示模板是：

你是协助排查 Web Bug 的代码审查员。
已知现象：<复现步骤与实际结果>
已知错误：<脱敏后的错误摘要>
相关代码：<最小代码片段>
请输出：1) 按可能性排序的假设；2) 每个假设的验证动作；3) 最小修改建议；4) 回归风险。
不要假设未提供的业务规则，不要输出或要求密码、Cookie、Token。

把模型回答放进排查记录，标注为“候选假设”，并逐条用浏览器或测试验证。AI 说“可能是跨域”不是证据，Network 面板中可复核的请求和响应才是。

4. 小范围修补并保留回滚点

先建立分支或补丁，记录修改前的提交号。优先修复触发问题的最小代码路径，避免顺手升级依赖、重排 CSS 或改动无关页面。若必须改配置，先复制旧值并写回滚命令。

提交信息要能让客户理解，例如 fix: show form result after submit。修复说明写三栏：改了什么、为什么改、没有改什么。没有可回滚点，就不要把“已上线”写进验收结论。

5. 用 Playwright 和 Lighthouse 做可重复检查

Playwright 官方文档将其定位为端到端测试框架，支持 Chromium、WebKit 和 Firefox，并提供测试运行器、断言、隔离、并行和 HTML 报告。你可以把客户约定的验收路径写成一个最小测试；不要为了展示工具而搭建一整套测试平台。

下面是无秘密的示例，域名和选择器均为占位符：

import { test, expect } from '@playwright/test';

test('form shows a result after submit', async ({ page }) => {
  await page.goto('https://staging.example.test/contact');
  await page.getByLabel('Name').fill('Test User');
  await page.getByLabel('Email').fill('test@example.test');
  await page.getByRole('button', { name: 'Submit' }).click();
  await expect(page.getByRole('status')).toContainText('Success');
});

运行测试时保存 HTML 报告；必要时只对失败重试保存 trace。Playwright Trace Viewer 官方文档说明 trace 可以在本地或浏览器中打开，浏览器托管版本会在浏览器内加载文件并声明不会向外传输。即便如此，交付前仍要检查 trace 中没有客户数据。

Lighthouse 可以作为页面性能和常见质量问题的补充检查，但不要把某个分数当成“网站已修好”的唯一证明。验收指标必须回到客户约定的路径：按钮是否可用、结果是否出现、刷新后状态是否正确。

6. 录一段能复核的验收视频

录屏不是宣传片，而是证据索引。建议控制在几分钟内（这是交付习惯的估算，不是平台标准），按固定顺序录制：

1. 显示日期、环境和页面 URL，遮住账号和个人信息。
2. 用同一组脱敏数据重现问题，展示修复前状态或复现记录。
3. 切换到修复版本，沿完全相同的路径操作。
4. 展示成功结果、关键断言或测试报告，不展示秘密值。
5. 说明已覆盖项、未覆盖项和回滚方式。

同时交付一页验收清单：

• 授权环境和测试账号已确认，视频中无密码、Cookie、Token。
• 修复前的现象与修复后的结果使用同一条路径。
• 关键断言、控制台或网络证据可被客户复核。
• 已知未覆盖浏览器、设备和边界条件已列出。
• 修改提交号、部署时间和回滚步骤已写明。

7. 交付、上线和回滚

先把报告、补丁或提交号、测试报告、视频和回滚说明发给客户确认，再按约定窗口上线。上线后重新走一遍验收路径；如果结果不一致，优先回滚并记录差异，不要在生产环境连续试错。

交付目录可以这样组织：

bug-acceptance/
├── 01-reproduction.md
├── 02-change-summary.md
├── 03-test-report.html
├── 04-acceptance-video.mp4
└── 05-rollback.md

客户只需要知道问题是否解决、证据在哪里、出现回归如何处理。你也因此拥有一套可以复用到下一单的交付模板。

虚构演示：表单按钮点击后没有成功提示

下面是演示 SOP 的虚构案例，不是客户案例，也不代表任何真实网站。

问题：测试环境的联系表单点击提交后按钮转圈，接口返回 200，但页面没有显示成功状态。范围合同只覆盖联系页、Chromium 桌面视口和成功提示，不包含邮件服务改造。

排查：复现卡确认接口响应中有 ok: true；AI 提示可能是前端只处理错误分支。人工检查后发现，成功回调更新了一个未被模板读取的状态字段。修复只改动状态字段映射，并保留旧提交号作为回滚点。

验收：Playwright 用脱敏数据断言 role=status 出现 Success；人工刷新页面确认表单状态符合合同；录屏展示同一条路径和测试报告。未覆盖 Safari、邮件送达和真实用户数据，因此这些项目写进“未覆盖项”，不能顺手宣称已经验证。

工具、成本、时间与收益模型

工具	用途	成本写法
通用 LLM	整理报障、生成假设和测试草稿	按你实际套餐或 API 账单记录；不要用模型宣传页推算利润
浏览器开发者工具	Console、Network、设备与视口复现	常见浏览器内置；以本机实际可用功能为准
Playwright	关键路径回归、HTML 报告、trace	开源工具本身与浏览器下载成本分开记录
Lighthouse	性能与质量的补充检查	只记录实际运行环境和报告，不承诺分数提升
Git	分支、差异和回滚点	记录已有托管或本地存储成本
屏幕录制工具	交付验收证据	记录实际软件订阅或存储成本

时间可以用自己的历史记录校准。没有历史数据时，下面只是估算：需求确认 15–30 分钟，最小复现 20–60 分钟，修复与回归 30–120 分钟，录屏和交付 15–30 分钟。复杂度一旦超过一个验收路径，就应拆成新单，不要用平均值掩盖不确定性。

收益只用公式核算：收益 = 验收单价 × 完成单数 − 直接成本。例如，假设你自行设定单价 300 元、完成 2 单、直接工具和存储成本合计 40 元，则这是一个“估算净额 560 元”的算术演示，不是市场报价、收入保证或客户案例。真实复盘还应扣除沟通、返工、税费和平台成本。

如何找第一批客户：先卖检查，不先卖大改版

最容易让陌生客户理解的入口，是“付费复现＋验收清单”，而不是“我能用 AI 重构网站”。你可以按下面的顺序获客：

1. 在自己的演示站制造一个可控的小故障，公开复现卡、修复差异和脱敏验收录像。
2. 发布一篇问题导向的文章，解释什么信息能让排查开始，什么请求会被拒绝。
3. 在熟人、小商家或开发者社区中提供一次范围明确的检查，不主动索要生产密码。
4. 客户确认问题后，再报价修补和上线；发现第二个独立问题时重新报价。

本站的 AI 自动化服务文章 适合解释跨系统、需要人工审批的流程项目；Cursor Chrome 扩展文章 可作为 AI 辅助开发环境的背景。它们不是本轻量单的成功案例，也不应被拿来承诺结果。

风险、隐私与合规边界

OWASP 的当前 Top 10 页面列出的版本是 2025；其路径遍历页面解释，攻击者可能利用 ../ 等路径变体访问 Web 根目录之外的文件。你不需要把每个客户网站都做成完整安全审计，但看到疑似路径遍历、权限绕过或敏感数据暴露时，应停止“顺手修一下”，保留最小证据并建议客户找合格的安全人员。

录屏和 AI 输入都可能带出隐私。交付前检查浏览器历史、地址栏参数、Network 请求、截图、trace 和本地录屏目录；只保留必要文件并按客户约定删除临时副本。不要将客户源码、环境变量、真实用户数据或访问凭据上传到未经授权的第三方服务。

同时要区分“修复证明”和“安全保证”：一条通过的 E2E 测试只能证明这条路径在这个环境中通过，不能证明系统没有其他缺陷。合同、广告和公开文章都不要写“绝对安全”“一次修好”或“保证提升转化”。

验证指标：用交付证据复盘，而不是用想象的收入

每单只追踪能被复核的指标：

• 复现步骤是否能被另一名开发者独立重走。
• 修复前后同一路径的结果是否不同且符合合同。
• 自动化测试是否在约定浏览器/视口通过。
• 录屏、报告和提交号能否互相对应。
• 客户是否明确确认已覆盖项和未覆盖项。
• 返工来自原问题、范围变更还是环境差异。

一周后再看这些记录，才知道哪个场景适合继续标准化。不要用没有基线的“节省了多少人力”或“提高了多少转化”替代证据。

常见问题

没有客户源码，能不能接这个服务？

只有公开页面而没有书面授权、测试环境或可回滚方式时，不应修改或探测客户系统；可以先交付复现报告，但要把修复和上线排除在范围外。

AI 能不能直接替我判断 Bug 已经修好？

不能。AI 可以生成排查假设和测试草稿，最终结论必须来自人工复现、自动化结果、关键路径检查和客户确认。

验收录像里应该放什么？

应展示脱敏后的环境、复现前状态、修复后的同一路径、关键断言或报告，以及已知未覆盖项；不要录入密码、Cookie、Token 或客户隐私数据。

来源清单

以下来源均为官方页面。页面未显示明确发布日期的，按要求标注日期状态；访问日期为 2026-08-24。

1. Microsoft Playwright， “Installation / Introduction”：页面未标注发布日期；抓取响应的 HTTP Last-Modified 为 2026-08-21；访问于 2026-08-24。用于核对 Playwright Test 的浏览器支持、测试运行器、断言、隔离、并行和 HTML 报告描述。https://playwright.dev/docs/intro
2. Microsoft Playwright， “Trace viewer”：页面未标注发布日期；抓取响应的 HTTP Last-Modified 为 2026-08-21；访问于 2026-08-24。用于核对 trace 查看方式和浏览器托管版本的本地加载说明。https://playwright.dev/docs/trace-viewer
3. OWASP， “OWASP Top Ten Web Application Security Risks”：页面未标注发布日期；抓取响应的 HTTP Last-Modified 为 2025-12-24；访问于 2026-08-24。页面明示当前发布版本为 OWASP Top 10 2025。https://owasp.org/www-project-top-ten/
4. OWASP， “Path Traversal”：页面未标注发布日期；抓取响应的 HTTP Last-Modified 为 2026-08-21；访问于 2026-08-24。用于核对路径遍历和 ../ 路径变体的风险解释。https://owasp.org/www-community/attacks/Path_Traversal

本文中的时间、价格、成本和收益算式均为个人交付模型或明确标注的估算，不是上述来源发布的市场数据。