让 AI agent 变成一个广告调研工具：写给零基础的人

如果你一行代码都没写过，这篇文章就是写给你的。我会掰开揉碎地讲清楚：一个 AI agent 是怎么从「我想研究护肤广告」这一句话，一路做出一个能用的调研看板的。然后再讲，你要怎么把这个用完就扔的脚本，变成一个每天早上自己更新的真正应用。

每一个技术词我都会给出一个人话解释，配一个生活里的画面。如果哪一步你觉得像变魔术，那是我没讲明白，不是你脑子跟不上。

先把最后做出来的东西摆出来，你就知道我们要去哪：

• 一次抓取，从广告库里拉了 100 条正在投放的护肤广告。
• 每条广告都被打上标签：它主打什么卖点，势头是往上走还是快凉了，投在哪些地方，品牌大概烧了多少钱。
• 每个品牌的店铺都被扒了个底朝天：真实售价、漏斗类型、用的评价插件、加购套路。
• 全部塞进一个能点、能筛、能排序的看板里。

第一层：完整的工作流，一点不藏

先看文章顶上那张图。整个工具就是六件小活，一件接一件串成一条链。单看每一件都不聪明。神奇的地方只在「串」这个动作上。我们一件一件走一遍，把「它到底怎么做到的？」这个疑问彻底消灭掉。

环节 1：像人一样登录进去

目标： 越过广告库的登录页（这是个付费工具，用户本来就有账号）。

它到底是怎么做的。 agent 用了一个叫 Playwright 的东西。你可以想象一个特技车手，钻进的是你自己那辆真车来开，不是玩具车，也不是画上去的车，是你那辆能上路的真车。Playwright 就是一个机器人，它开的是一个真正的 Chrome 浏览器：能移动鼠标、往输入框里打字、点按钮，跟真人操作一模一样。于是它打开登录页，输入邮箱，输入密码，点「继续」。

这个登录口由 Clerk 把守。你可以把 Clerk 想成门口那个看证件的保安，他分两步查你：先查邮箱，再查密码。头几次都失败了，因为 agent 点得太快，保安第一步还没查完它就往下走了。解决办法特别符合常识：两步之间稍微等一下。 一等，门就开了。

关键词框， Playwright：一个能操控真实浏览器的机器人。Clerk：一个很常见的登录守门系统。

环节 2：找到数据真正住在哪里

这一步很多人觉得玄乎，所以我把发生的事一五一十讲清楚，绝不含糊。

当一个网站给你显示一整墙广告的时候，你的浏览器其实在偷偷给公司的服务器打电话：「把广告给我」，服务器就回你一份整整齐齐的清单。这些电话你看不见，但它们就在页面底下悄悄进行着。每个浏览器都有一个 Network tab（网络面板，也就是一份通话记录），你可以在那里盯着这些电话看。

agent 就盯着那份通话记录，逮到了一个叫 getAds 的电话。它回话的时候，回的不是一个花花绿绿的网页，而是一份 JSON，也就是装在一个个贴了标签的盒子里的数据，像一张已经填好的表格：

{ "brand": "Soluna SKIN", "reach": 11308008, "price": 39, "runningDays": 886 }

诀窍全在这儿。我们没有去截页面的图、再费劲从像素里认字，而是找到了 API，也就是网站自己用来向后厨点数据的那个小窗口，然后用同样的方式去点。跟网站自己拿到的是同一份数据，而且早就是干净的。

生活里的画面： 对着黑板一个字一个字抄餐厅菜单，又慢又容易抄错。我们直接找到了后厨的点菜小票。信息一样，人家早给你打好字了。

关键词框， Network tab：浏览器里记录幕后通话的那份日志。API：程序用来点数据的「点菜窗口」。JSON：装在贴了标签的盒子里的数据（不是网页）。

环节 3：把一页变成一百条广告

getAds 每叫一次，回来 20 条广告，外加一个 cursor（游标）。cursor 就是一个书签。服务器给你那 20 条的同时，基本上是在说：「你看到这儿了，下次拿着这个书签再来问我，我给你接下来的 20 条。」

于是 agent 就开始循环：拿 20 条，收好书签，再问一次，再拿 20 条。循环 5 遍，凑够 100 条。这个动作叫 pagination（分页），字面意思就是「一页一页翻」。cursor 就是你按在书页上的那根手指，让你不会把同一页读两遍，也不会弄丢读到哪了。

关键词框， Pagination（分页）：一页一页地取数据。Cursor（游标）：一个书签，告诉服务器「从这儿接着来」。Rate limit（限流）：服务器允许你问多快，超过它就喊你「慢点」（所以我们在两次调用之间加一个小停顿，这份礼貌能让你不被封）。

环节 4：洗干净、压小、贴标签

原始数据是一团乱麻。这一步就是没人看得见的后厨备菜。

• 只留有用的字段。 每条广告带着几十个字段，我们只留卖家在乎的那些（品牌、花费估算、触达、投放天数、国家、售价），其余噪音全扔。
• 把图片压小。 每条广告的缩略图都被下载下来、再压得更小（用一个叫 sharp 的工具改尺寸），这样最后的看板加载起来飞快，而不是一个 5 兆的大胖子。
• 给卖点打标签。 AI 在这一步才真正显本事。有一半广告带着真实的广告文案（比如「让你终于拥有一直想要的下颌线」）。AI 逐条去读，给它的卖点角度打标：这是前后对比？是问题→解决方案？是讲原理的？还是打「已售罄」这种社会认同的？用死板的关键词过滤器一定会标错，而一个真正读懂句子的读者不会。

有件老实话，后来自己变成了一条洞察：另一半广告根本没有一个字的文案，它们是「目录型」广告（平台从产品清单里自动拼出来的）。没有文字，你就没法从文字里读出卖点。所以它们被标成了「Catalog / DPA」，而这个空白本身就是个发现：热门护肤广告里有一半根本不是人手写出来的创意，而是自动生成的目录广告。

关键词框， AI 打标：让模型去读、去归类，而不是用脆弱的关键词规则。

环节 5：走进每一家竞品的店里

广告库能告诉你很多，但它很少露出真实售价或者漏斗结构。所以机器人（还是 Playwright）挨个打开每个品牌的落地页，一页一页读。

它从一个大多数店铺都会公开、藏起来的标准化数据块里把价格抠出来，这个块叫 JSON-LD（店铺埋在页面里的结构化数据，本来是给 Google 用来展示富媒体结果的，我们顺手借来用）。它还顺便记下：这是一个普通的产品页，还是一篇长长的、故事口吻的软文页（advertorial，先把你说动了再往外跳链接）？装的是哪个评价插件（Loox、Yotpo、Judge.me）？有没有 upsell（加购）套餐、urgency（催单）小贴纸（「只剩 3 件」）、有没有「订阅省钱」的选项？

这些竞品情报，平时你得一家一家店手动去扒。机器人把所有店一次全扒了。

关键词框， Teardown（拆解）：把竞品的页面拆开，看它是怎么搭的。JSON-LD：页面里标准化的隐藏数据。Scraping（抓取）：用程序去读一个网页。

环节 6：变成一个人真正会用的东西

数据再多，如果只是一张没人打开的表格，那就是废的。最后一步把它变成一个 frontend（前端），也就是你看得见、点得动的那部分。

只做一次性的调研，我们没搭服务器，也没建数据库。脚本直接写出一个自带全部内容的 HTML 文件：数据烤进去了，缩略图嵌进去了，筛选和排序用一点 JavaScript 写好。用任何浏览器打开它，你就有了一个真正的工具，按卖点角度筛、按广告花费排、点一张卡片看完整拆解、把赢家导出成表格。

把整套流程画成一张图

同样这六个环节，画成一张真正的流程图，连「真实数据很乱」时那些是/否的岔路口也一起画进去了。从上往下读就行。

真正要紧的那部分：问对问题

一个工具有多聪明，取决于它背后的问题有多聪明。在写任何代码之前，真正的活是想清楚：一个卖家盯着一整墙竞品广告时，到底需要知道什么。「把广告给我看看」是个很烂的需求。下面这些问题才让数据变得值钱：

1. 哪些产品值得拿来测？ 信号是：投了非常久、而且被反复复制的广告。一条投了 886 天的广告不是运气好，是它赚钱。这就是一个被验证过的产品，抄它风险很低。
2. 是哪个卖点在成交？ 前后对比、问题→解决方案、讲原理、社会认同。这是页面上最值得偷师的东西。
3. 哪种形式赢？ 视频、图片、还是目录型，你的制作预算该往哪儿砸？
4. 卖点和价格是什么？ 又是冲着哪个市场（哪种货币）去的？
5. 卖给谁、在哪儿卖？ 国家、年龄、性别、投放位置，还有那块没人去抢的空白市场。
6. 它在放量还是在凉？ 千万别抄一条正在往下走的广告。看月环比的触达变化，就知道现在哪些创意正在拿到更多预算。
7. 每个品牌测得多快？ 每个品牌每月出多少条广告，也就是它的创意迭代速度。如果一个对手一个月上 20 条新广告，你一个月一条根本没法比。

注意：这里没有一个问题是技术问题。这就是生意人的脑子。机器是 AI 搭的，但把它指向有用方向的，是这些问题。

那些 prompt：以及为什么越松的反而越好使

大家总以为好的 prompt 就是一份精确、发号施令的规格书。这次做的时候正好相反，而且值得研究一下这些请求是怎么措辞的，因为这是一个你能学会照搬的本事。

下面这几条就是真正驱动这次开发的 prompt（从随口说的越南语转成自然的中文，别的没动）。注意它们都不是打磨过的规格书。这恰恰是重点。

开场那句：

「我想抓 10 条护肤的带货广告。用这个邮箱和密码登进这个网站。你可以用 Playwright 去开浏览器、把数据拉出来。要不你先分析一下现在这网站的结构、HTML/DOM，把该要的信息抠出来，或者你觉得哪种方式合理就用哪种。我脑子里想的样子，是一格一格排开的广告框。」

有两点很打眼。它只钉死了一个硬约束（用 Playwright，这是登录信息），又给了一个清清楚楚的「做完是什么样」（一格一格排开的广告框）。中间的部分，也就是怎么去找、去拉数据，被明明白白地留空了：「你觉得哪种方式合理就用哪种」。就是这一句，才让 agent 自己去把那个藏起来的 getAds API 挖出来，而不是笨手笨脚地截页面的图。

换视角那句：

「现在换成卖家的视角。我想把这些广告好好研究一遍，研究到对我自己投广告有用。你分析一下，一个卖家研究这么一批广告，到底真正需要哪些洞察。做一个 artifact，把展示用的 UI/UX 先搭出来，我好在动手做之前先评估一下。」

这句是故意把决定权交出去的：「你分析一下卖家会需要哪些洞察」，而不是「这是我列好的 8 个指标」。正是这份留白，才让 agent 冒出没人点名要的点子，比如广告迭代速度（一个品牌每月上多少条广告），还有那个发现，热门广告里有一半是自动生成的目录广告。一份发号施令的规格书，只会把结果卡死在提问者自己那点知识的上限里。

逼它保持诚实那句：

「这里面有盲区。比如你让 Claude 去广告库里翻数据，但你得把 Claude 到底做了什么讲清楚，让读的人能看懂。这种盲区还有很多，你再往深里找找。」

这句是一个质量杠杆。它不接受一句糊弄的「然后它就把数据拿到了」，而是逼 agent 把自己的窟窿露出来。让一个模型把自己的活儿摊开给你看，正是你逮住它心虚糊弄之处的办法。

所以把这几句放一起，套路是这样的：

• 给目标和「做完是什么样」，别给步骤。「对我自己投广告有用」「一格一格排开的广告框」。为什么这个方向定了，agent 才能自己挑好办法。
• 明明白白地把决定权交出去。「你觉得哪种方式合理就用哪种」「你来纠正我，或者你觉得怎么合理就怎么来」。这不是偷懒，而是给 agent 留出空间，去补上你根本不知道该问的东西。
• 别锚定。 靠着不把话说太死，你就避开了把答案锚定（anchoring）在自己第一个猜测附近。要是写成「就把 10 条广告连图列出来」，那你就只会拿到这个，一分不多。
• 邀请它主动暴露盲区。「把它到底做了什么讲清楚」「再往深里找找盲区」。一个能被推翻的 prompt，比一个只会奉承你的 prompt 强。

对一场 workdathon 来说，教训就是：把终点和限制条件描述清楚，然后让开。 对一个有本事的 agent 管头管脚，恰恰扔掉了你花钱买它的那个东西：它能看见你漏掉了什么。

关键词框， Prompt（提示词）：你给 AI 的指令。Anchoring（锚定）：不小心把答案框死在你的第一个猜测附近。Agency（自主性）：让 agent 真的去做决定，而不是只会听命令。

第二层：从用完就扔的脚本，到一个真正的应用

第一层今天就能给你洞察。但那个 HTML 文件是一张照片，今早是真的，到下周就馊了。要把它变成一个会自己刷新的活工具，你需要餐厅里剩下的部分：一个后厨、一个储藏室，还有一个永远不打烊的家。下面还是用大白话，讲每个部件怎么运作。

先说清楚：frontend、backend、database 到底是什么

回到上面那张餐厅图。

• Frontend（前端） = 餐厅大堂。你看得见、摸得着的东西（按钮、卡片、筛选器）。用 HTML（骨架）、CSS（刷的漆）、JavaScript（行为）搭出来。
• Backend（后端） = 后厨。跑在服务器上、干重活的代码，在我们这里就是抓取和清洗。
• Database（数据库） = 储藏室和冰箱。两顿饭之间，食材（数据）存放的地方，冷藏好、码整齐。
• API = 服务员。把大堂的请求端到后厨，再把菜端回来。

一次性的调研跳过了后厨和储藏室，脚本做一次菜、直接装成一张 HTML 页面端上桌。但一个每天更新的工具，四个部件一个都不能少。

问题 1：数据库怎么保持干净？

这个词叫 normalize（归一化），说白了就一件事：每个事实只存一次。 在我们的原始数据里，品牌的 Instagram 粉丝数被抄到了每一条广告那一行上。如果这个品牌投了 60 条广告，它的粉丝数就被写了 60 遍。改一次，剩下 59 份就全成假的了。

解决办法是拆开：一张 brands（品牌）表，每个品牌只存一次，带一个 id；再一张 ads（广告）表，每条广告只需要指向它品牌的 id。这个指针叫 foreign key（外键），你可以理解成「详情请看品牌 B1」。这样一来，一个品牌的信息就只住在一个地方。它不可能自己跟自己对不上。

卖家为什么要在乎这个：只有一个干净的数据库，才能让明天那次抓取说出「这条广告是新的」或者「这条凉了」，因为它能拿一份已知的、唯一的昨天来对比。乱的数据看不见变化。整齐的数据才能变成趋势。

问题 2：怎么让它稳定、干净、经得起测试？

三个习惯，不讲黑话：

• 小函数，起清楚的名字。 别写一个 500 行的怪物，写一小块一小块、每块只干一件事的东西：login()、getAds()、cleanAd()、saveToDb()。好读，好修。所谓「clean code」（干净的代码）落到每天，就是这个意思。
• 接住那条会出问题的广告。 真实数据是脏的，价格缺了、页面打不开。把有风险的步骤包起来，让一条坏广告不至于把整次抓取都搞崩（我们这次抓取里，一个加载超时的页面被跳过并记了一笔，而不是直接致命）。这叫 error handling（错误处理）。
• 给每一块做测试。 一个 test（测试）就是一个小小的脚本，检查「我喂进去这个，会不会得到那个？」每次改完代码你就跑一遍，哪个变红了，就是你改坏了东西。这就是 QA（质量保证），它让你下个月改代码时可以不心慌。

心法是：假设每一个输入迟早都会变得奇形怪状，然后让程序温柔地、大声地出错，跳过那条坏数据、记一笔、继续往下跑。

问题 3：你需要准备什么，以及部署到底是怎么发生的

这一段是大多数新手觉得最模糊的地方，所以我们放慢来讲。先讲账号和工具。再讲 Railway 到底是个什么东西。然后一步一步讲部署怎么发生。最后讲几个容易把人卡住的地方。

从零开始：账号和工具

要看懂这个工具，你什么都不用准备。但要自己动手做、并且跑起来，就得备齐下面这些。这是一份完整的购物清单，每样东西是什么、去哪弄，都写在里面了。第一层（在自己电脑上跑一次性的调研）只需要前三样。剩下的都是为那个每天自动跑的应用准备的。

别被这张清单吓到。每一个的注册都是你干过一百遍的那套「填邮箱、点确认」。唯一要养成的新习惯，是把这些密码和 key 放在一个安全的地方，永远不要写进你的代码里。

Railway 到底是什么

Railway 是一家公司，它租给你一台云端的电脑，一台永远不关机的电脑，外加一个数据库、一个定时调度器，全都已经接好线了。你完全不用碰实体服务器，也不用装操作系统。你把自己的 GitHub 仓库接上去，Railway 就替你在那台常开的电脑上跑你的代码。

整个思路就这一句：你的笔记本会睡，Railway 那台电脑不睡。所以凡是你不在时也必须一直工作的东西，也就是每天跑的爬虫和那个数据库，就住在这里。（前面提过的 Vercel 是同一个概念，只是为网站调过校；Railway 是为后端、数据库和定时任务调过校的。一句口诀：大堂放 Vercel，后厨和冰箱放 Railway。）

部署怎么一步步发生

Deploy（部署）说白了，就是把你的代码从你的笔记本挪到那台常开的电脑上，再给它一个网址。下面是真实的路径，一步不省。

1. 把代码放到 GitHub 上。 在你的项目里打开终端，敲 git init、git add .、git commit -m "first"，然后去 github.com 建一个仓库，git push。一个 repository（仓库，简称「repo」）就是你的项目文件夹复制到了云上，而且带着一份记住每次改动的记忆。（这几条命令都可以让你的 AI agent 替你跑。）
2. 用 GitHub 登录 Railway。 打开 railway.app，点「Login with GitHub」。这样 Railway 就能看到你的仓库了。用 GitHub 登录还有个好处：你不用再另起一个密码。
3. New Project → Deploy from GitHub repo。 选你的仓库。Railway 会读它，认出这是个 Node.js 项目，装好需要的东西，把它跑起来。这个「装好并启动」就是一次 build（构建），紧接着是一次 deploy（部署）。你没配任何服务器，就已经跑起了一个服务器。
4. 加数据库。 在项目里点 New → Database → PostgreSQL。Railway 会给你起一个真正的数据库（那个冰箱），再悄悄把它的地址当成一个 DATABASE_URL 变量塞给你的代码，这样你的代码不用你复制任何东西就能找到它。
5. 把你的机密都加成 Variables。 打开你的服务 → Variables 标签页 → 加 ADLIB_EMAIL、ADLIB_PASSWORD 和 ANTHROPIC_API_KEY。这些东西住在这里，永远不进代码。跟你不会把银行卡密码写在卡上是一个道理。
6. 拿一个公开网址（这一步就是「上线」）。 服务 → Settings → Networking → Generate Domain。Railway 会给你一个像 your-app.up.railway.app 这样的地址。用任何设备的任何浏览器打开它，你的看板就在那儿了。这个网址就是「它现在在线了」。
7. 把每天跑的爬虫加成第二个服务。 点 New → GitHub repo，选同一个仓库再来一遍。这第二个服务不负责端网站；把它的 start command 设成 node src/pipeline.js，再到 Settings → Cron Schedule 给它一个时间。就这样：两个服务，一个仓库，一个共用的数据库。

要抓住的核心是：你租了一台永不打烊的电脑，把 GitHub 上的代码交给它，把密码单独锁进另一个抽屉，再给它定一个时间表，让它在你不管的时候替你干活。

关键词框， Deploy（部署）：把代码挪到一台常开的电脑上，配一个公开网址。Repo（仓库）：你的项目文件夹，放到云上，带版本记录。Build（构建）：把代码装好、备好，让它能跑起来。Domain（域名）：别人打开的那个网址。Variable（变量）：代码在运行时才去读的一个机密。

问题 4：打开每天自动跑（cron）

一个 cron job 就是给代码用的闹钟：「每天到这个点，跑这件事」。在 Railway 上，你把它设成第二个服务的 Cron Schedule，用五个数字：分、时、日、月、周。0 1 * * * 的意思是「每天，1 点的第 0 分」。有一个坑值得先说清楚：Railway 的钟走的是 UTC，不是你的本地时间。越南是 UTC+7，所以越南时间 08:00 对应的是 0 1 * * *（也就是 UTC 的 01:00）。这个写错了，你的抓取就会在错的钟点跑，而这正是「怎么什么都没发生」最常见的那个意外。

每天早上闹钟一响，爬虫就登录、拉一批新广告、跟昨天对比（新的标出来，消失的标成已死），再写进那个共用的数据库。web 服务本来就一直在读这个数据库，所以你的看板不用任何人动它就是新的。这个循环，闹钟 → 抓取 → 对比 → 存储 → 展示，明天再来一遍，就是把一份一次性报告变成一个活工具的分水岭。那张照片，变成了一台监控摄像头。

可能会卡住你的地方

老实列一下路上的坎，免得它们把你拦住：

• 登录被挡住。 广告库会防机器人。只登录你真有账号的工具，加上小小的等待和重试（我们就是这么做的），别使劲猛敲。要是它硬性封了自动化，那就认了，这是人家的权利。
• 图片过一天就白了。 缩略图的链接是临时的（签名过的 URL，会过期）。解决办法：在跑的过程中就把图片下载存下来，别指望那个链接以后还管用。我们的应用把它们存进了数据库。
• 「在我笔记本上好好的，一到 Railway 就不行。」 几乎总是浏览器的问题：爬虫需要服务器上装着 Chrome。解决办法：用官方的 Playwright Docker 镜像，它里面已经带了 Chrome（我们的 Dockerfile 就是这么干的）。
• 数据库连接报错。 Railway 的内部数据库 URL 不需要 SSL，外部的那个需要。我们的代码会根据 URL 自动切换，但如果你手动配置，八成就卡在这儿。
• cron 在错的钟点跑了。 又是 UTC。先把你的本地时间换算过去。
• 突然来一张账单。 打标的分类器会调用 Claude，每次跑花一点点；一个数据库加一个常开的服务，每月也花一点点。先用免费额度起步，盯着用量，另外记住：如果你不填那把 API key，分类器有一个免费的关键词兜底方案。
• 机密泄露了。 千万别把你的 .env 文件提交上去，也别把密码粘进代码。所有敏感的东西都放进 Railway Variables。第一天就把 .env 加进 .gitignore。
• 服务条款。 只研究你有资格用的工具，把数据留着自己分析，而不是拿去二次分发。有用不等于可以乱来。

关键词词汇表：留着这个

只带走一句话的话，带这句

你并不需要会写代码，才能拿到真正的广告调研，你需要的是问出一个够犀利的问题，然后让一个有本事的 agent 把背后那条又枯燥又六环节的链子搭起来。第一层，任何人今天下午就够得着。第二层，无非是加一个后厨、一个储藏室、一个闹钟，让这个工具在你睡觉的时候继续替你干活。

把它指向你自己的市场。想清楚一个好答案该长什么样。然后，让开。