OpenClaw实战：前端与全栈招聘岗位详细对比分析

AI编程工具日益普及后，“前端转全栈”究竟是不是一个真实的行业趋势？我在网络上浏览过大量观点碰撞的帖子，各方说法不一。与其依赖主观判断，不如直接查证招聘数据来得可靠。最近，我利用OpenClaw进行了一次实打实的验证，搜索并整理了前后端两个方向的招聘岗位信息，详细分析过后，过程颇具启发性，也得出了几个与直觉相悖的结论。

适合 OpenClaw 的应用场景

说到底，OpenClaw最擅长的领域，可以归结为“搜索、整理、分析”这三个核心词。如果用人工来完成这类任务，不仅耗时费力，不同的人执行出来的结果也可能天差地别，数据质量如同开盲盒般难以预期。如果换用其他AI工具，比如豆包、千问等，它们内部调用的搜索API通常是免费的，质量难以把控，且流程和规范无法自由定制，最终产出完全取决于应用自身的理解能力。而OpenClaw的优势在于，它可以利用本地浏览器进行搜索，相当于模拟人工检索，从而保证搜索质量；此外，它还支持自定义Skill，将流程和要求明确写入，让AI的理解有了扎实的依据。

创建 skill

由于任务比较复杂，第一次尝试我没有让它直接执行，而是先要求它设计一个方案。我给出的提示大致如下：

在当前 AI 编程普及的情况下，前端工程师 纷纷转行为 全栈工程师。我想让我帮我搜索并整理：全栈工程师的招聘情况，各个城市的数量、薪资、技能等，以及前端工程师的数量、薪资和技能。然后两者做对比。而且我打算每个月就让你做 1-2 次这个工作，所以最好能整理成一个 Skill ，这样可复用。对于这个 skill ，你有什么想法？从哪些方面考虑？怎样的流程？PS. 先不要去执行搜索、也不要直接写 skill ，先说你的思路

这里有一个小细节需要提醒：末尾那句“PS.”一定要加上，否则AI会非常激进取干活，大概是为了多赚点token。去掉那句，相当于关掉了它的加速键。

AI给出的方案结构让我相当满意——梳理得十分全面，从数据源到输出格式，再到可行性设计和流程规划，基本都考虑周全了。

继续优化

有了初步框架后，我又换了一个角度，让AI站在阅读者的立场上，思考内容还能如何打磨。提示词改成了这样：

你的设计我非常认同。另外，我会把这个报告发布到博客或公众号，请你再站在阅读者的视角，帮我优化一下，看是否哪里还有缺失？

它很配合地补充了一些报告呈现方面的建议，甚至帮忙构思了一些前端转全栈的实操建议，这已经超出了最初的搜索任务范畴。

生成 skill

分析与优化到位后，我让它正式生成Skill。这是OpenClaw最核心的功能之一。生成过程比预想中要慢，中间还卡了几轮，看得出内容量很大。最终成品非常全面——流程、数据源、数据处理方式、最终产出Markdown报告的格式，都写得一清二楚。在配置目录下也确实能查看到这份Skill文件。

测试 skill

Skill写得再完善，不上真实场景测试也是徒劳。我先拿北京的数据试跑了一次，结果……开局就不太顺利。Skill默认推荐的数据源是Boss直聘，但这家的反爬虫机制极为严格，根本拿不到数据。后来让AI重新推荐，改用了拉勾网和猎聘网，数据就顺利拉回来了。Skill能够成功运行，这才是关键所在。

执行搜索和分析

确认Skill无误后，就开始全量执行：对多个城市分别采集前端和全栈岗位的数据，然后进行对比分析。最终输出的Markdown汇总报告，将各个职位的数量、薪资、技能要求都整理得井井有条，一目了然。

从最终数据来看，前端岗位的招聘数量是全栈岗位的4.75倍——这个结果与很多人主观上的猜测完全相反。大家对这个数据怎么看？欢迎在评论区讨论。

最后

从头到尾完成一遍，整个过程大概花了一个多小时，使用的是Kimi 2.7模型，加上首次创建Skill所消耗的Token，总费用大约只有5元。因为第一次使用需要搭建环境、建立流程，Token消耗会相对大一些；如果再跑一次，只需调出Skill直接执行，效率和成本都会进一步降低——对于这种周期性分析任务来说，性价比确实很高。