引言
这是《AI实用主义探索》系列推文的第一篇。
本文源自笔者在工作中遇到的大模型选择痛点,当技术更新速度超越人类认知效率时,如何用工具对抗工具。
实现部分主要使用Cursor来完成,顺便分享一下过程中遇到的一些坑。
预计阅读时长: 10-15分钟。
一个“后进生”的痛
年后各个企业受到Deepseek的刺激,纷纷开始“全面拥抱AI”,而我自己的工作也难以免俗。这几个月手头上最重要的事之一,就是帮公司的业务接入各种AI模型。
在这个过程中,经常业务追问n连击“我该用什么模型”、“模型是开源的吗”、“哪个成本更低”、……不胜其烦。
究其根本,是这两个因素在作祟:
1. "追新"的压力
从Open AI横空出世开始,最FOMO的领域非AI莫属。每天打开社交媒体,就会遭受一轮各种"震撼"的AI模型新闻轰炸。
前几天是GPT 4o模型“难以置信”的生图能力,过几天又是GPT o3的推理能力“遥遥领先”,远的不说,阿里赶在五一假期前最后一天“重磅开源”Qwen3,又成了“最强开源模型”。

错失恐惧症(英语:Fear of missing out,简称:FOMO),也称社群恐慌症。是指由自己的不在场所产生的不安与持续性焦虑。患者总感到自己不在时可能发生非常有意义的事。
作为年后才追这波风潮的“后进生”,一边“补课”,一边还要追新,认知成本非常之高。
2. "王婆卖瓜"的厂商们
最近也频频接触了多个厂商的售前,看到了一些啼笑皆非的事,比如:
- 某大厂的技术人员信誓旦旦说自己的IDE是“行业领先”,殊不知他们的feature在Cursor上已经被用烂了
- 某国际供应商说自己的价格比友商“略贵”,算下来发现是另一国际大厂的2倍,是小平台的4倍之多
在众说纷纭的环境下,想要尽可能“科学决策”,降低决策成本是重中之重。

我需要一个什么样的工具?
在模型更新换代如此迅速的情况下,认知和结论也需要实时更新。作为开发者出身,“不要浪费时间在可重复的事务上”已经是本能。而AI模型选型过程中的信息收集和对比分析,完美命中自动化的两大评估标准:重复度高、耗费大量时间。
因此,我们需要一个简单易用的模型选择器,降低认知成本,解决自己工作中的痛点。
核心的功能清单:
- 定时更新数据。最核心的基础能力,解决人肉追新的痛苦。
- 价格对比。厂商都说自己比友商便宜,那就拉表看看到底谁更便宜。
- API Feature List。来自一个险些被坑的故事。在gpt 4o的图片生成大火的时候,我们原定接入能力,其实API并不可用,如果选型图片生成模型,得接其他的例如Image 1。
- 导出报表。汇报是工作中不可或缺的一环,既然构建工具是为了解决工作的痛点,那当然需要从工作的全流程来看。
设计与实现
从毕业到现在,自己的技术栈一直是围绕后端打转,对于前端可以说是基本一窍不通。而在走上管理岗位后,写代码的机会也少了很多。好在如今有很多AI编程工具,可以降低编写实现的难度。
鉴于“选择合适的工具”也需要研究成本,从实际出发,有什么用什么。
公司买了Cursor Business,刚好可以薅羊毛,深度试用一下用Cursor搭建从0到1的项目。
Cursor的王牌提示词
之前零零散散用cursor写过一些代码,总觉得有些不及预期。
Claude 3.7发布后,我在Cursor的论坛上看到一个高赞的Claude 3.7思维链提示词,非常实用,体感用了这个提示词后,Accept率至少提高了50%。
出处:https://forum.cursor.com/t/i-created-an-amazing-mode-called-riper-5-mode-fixes-claude-3-7-drastically/65516/6
您是 Claude 3.7,您已集成到 Cursor IDE(VS Code 的一个基于 AI 的分支)中。由于您的高级能力,您往往过于急切,经常在没有明确要求的情况下实施更改,以为自己比我更了解,从而破坏了现有逻辑。这会导致代码出现无法接受的灾难。在处理我的代码库时(无论是 Web 应用程序、数据管道、嵌入式系统还是任何其他软件项目),您的未经授权的修改可能会引入细微的错误并破坏关键功能。为防止这种情况,您必须遵循以下严格协议:
元指令:模式声明要求
您必须在每一个响应的开头用括号标出您当前的模式。没有例外。 格式:[模式: 模式名称]
RIPER-5模式
模式1:研究
标签:[模式:研究]
目的 :仅收集信息
允许 :阅读文件、提出澄清问题、理解代码结构
禁止 :建议、实施、计划或任何行动暗示
要求 :你只能试图了解存在什么,而不是可能是什么
持续时间 :直到我明确发出信号进入下一个模式
输出格式 :以 [模式:研究] 开始,然后仅观察和提问
模式2:创新
标签:[模式:创新]
目的 :集思广益,寻找潜在方法
允许 :讨论想法、优点/缺点、寻求反馈
禁止 :具体规划、实施细节或任何代码编写
要求 :所有想法都必须以可能性而非决策的形式呈现
持续时间 :直到我明确发出信号进入下一个模式
输出格式 :以 [模式:创新] 开头,然后仅显示可能性和考虑因素
模式3:计划
标签:[模式:计划]
目的 :创建详尽的技术规范
允许 :包含确切文件路径、功能名称和更改的详细计划
禁止 :任何实现或代码编写,即使是“示例代码”
要求 :计划必须足够全面,以便在实施过程中不需要做出创造性的决定
强制性最后一步 :将整个计划转换为一个按编号顺序排列的清单,每个原子操作作为单独的项目
清单格式 :
实施检查清单:
[特殊动作1]
[特殊动作2]
...
n. [最终动作]
持续时间 :直到我明确批准计划并发出信号进入下一个模式
输出格式 :以 [模式: 计划] 开头,然后仅显示规格和实施细节
模式4:执行
标签:[模式:执行]
目的 :准确执行模式3中的计划
允许 :仅执行批准计划中明确详述的内容
禁止 :任何不在计划内的偏离、改进或创意添加
进入要求 :仅在我明确发出“进入执行模式”命令后才能进入
指令处理:你需要在运行python命令前,使用正确的虚拟环境,例如执行source activate fastvoice
偏差处理 :如果发现任何需要偏差的问题,立即返回计划模式
输出格式 :以 [模式: 执行] 开头,然后仅执行与计划匹配的内容
模式5:审核
标签:[模式:审核]
命令:进入审核模式
目的 :严格验证计划的实施情况
允许 :逐行比较计划和实施
要求 :明确标记任何偏差,无论偏差有多小
偏差格式 :“ :warning: 检测到偏差:[准确偏差描述]”
报告 :必须报告实施情况是否与计划一致
结论格式 :“ :white_check_mark: 实施与计划完全相符”或“ :cross_mark: 实施与计划有偏差”
输出格式 :以[模式: 回顾]开始,然后进行系统比较和明确判决
如果未设置模式,则按[模式:快速]开始
未经我的明确指令请勿在模式之间转换
你必须在每次回复开始时声明你当前的模式
在执行模式下,你必须 100% 忠实地遵循计划
在审核模式下,你必须标记哪怕是最小的偏差
你不可做出独立的决定
模式转换信号
仅当我明确发出信号时才转换模式:
“进入研究模式”“进入创新模式”“进入计划模式”“进入执行模式”“进入审核模式”“进入快速模式”
如果开启了Agent和自动Accept,看起来就颇有“人工智能”的味了,写代码也可以“挂机”。

一些弯路
虽然有了Cursor的辅助,但过程中仍避免不了踩坑和做出调整。
但话说回来,我认为,失败或愚蠢的经验也是有其分享价值的,正确的废话毫无意义。
在此也记录一些我遇到的问题,希望能给看到本文的你提供一些信息参考。
项目根目录错乱
第一个坑是本地的目录设置。原本我是有个{Workdir}目录,用于存放所有代码的,在使用Cursor时我也把项目根目录设置在这里:
{Workdir}/{ProjectDir}
但是在Agent模式下,cursor经常直接在当前目录(Workdir)中执行命令,例如npm install
,导致因根目录下找不到packge.json而执行失败,浪费tokens。

解决方案也比较简单,每次新建项目的时候,新建窗口即可。

计划阶段的人工调整
进入创新模式,帮我设计一个展示站点,内容是“AI大模型竞品调研”。核心页面是一个表格形式的对比站,聚合现在各家模型厂商的大模型的对比。
核心功能模块包括:
(1)登录和反爬虫防护,可以使用cloudflare或集成saas能力
(2)模型筛选和价格计算器,包括汇率折算等
(3)报表生成和导出
(4)支付功能,付费用户可以获取更多报表导出次数和自选列。
创新方案需要从用户吸引力、技术架构和模块划分视角来看。

AI给出的答复乍一看很牛,实际还是有很多细节问题。试过几轮,如果直接从AI生成的计划开始执行,项目建起来之后纠偏就比较难。有的时候慢即是快,在计划阶段,先人工整理出一份计划终稿,可以节省后续修复和调整的时间。
我的思路是沿用之前创新模式提供的结构,在涉及到选型的部分提前通过问答的方式选好,给AI一个确定性的答案。
(1)用户吸引力视角:
A. 核心价值主张:为新引入AI的企业、团队或个人,提供简单易用的模型选择器,降低决策成本,和长期使用成本。
30 seconds, save 30% costs when using AI
B. 痛点解决:厂商王婆卖瓜,都说自己比友商便宜,那到底谁便宜,拉表看看
C. 增长飞轮:社交媒体分享图,一键转发
D. 体验设计:简洁页面(核心是动态表格),省略无关信息;使用Ask Sheet能力,全局/范围提问,联动表格row和column;
(2)模块设计:
A. 登录及付费管理系统:基础设施
B. 价格计算模块: 主页面
C. 报表及导出模块: 创收卖点
(3)技术架构:
技术栈:next.js,UI框架使用TailwindCSS,多语言使用next-i18next
部署:Cloudflare Worker
数据库:Supabase Cloud
支付:Stripe
Auth:Supabase Auth
我的最新设计如上,进入计划模式,帮我补全整体计划和里程碑,不要超出上述范畴。设计为敏捷迭代的方式,例如在最基础的Demo完成后,就进行部署发布测试,将上述计划保存为markdown图表,纵轴为模块,横轴为里程碑,单元格为事项列表。
一轮对话的上下文有限,对话次数越多表现越差。
因此,可以在计划生成后保存一份markdown记录,方便后续对话时引用同一个源头文件。

Agent自动执行
Agent自动执行虽然会达到“一键托管战斗”的效果,但也会带来一些问题。例如,有时Agent会执行一些不必要的操作,或者在没有充分理解上下文的情况下做出错误的决策。
特别是在bugfix阶段,可以切回Ask和Manual模式,逐步调试和修复问题。

客观看待AI工具带来的生产力提升,以AI编程工具为例,我认为现阶段还没达到100%的可用率,而即使只有1%的工作量,对于真正0基础的人来说,其认知成本也不容小觑。
前端的i18n方案
前端对我来说就是那1%。
我的站点部分使用了react next方案。原本计划在项目前端中支持多语言,AI提供了i18next、react-i18next、next-i18next、nextintl等等方案,但在实际使用时,不是出现各类编译问题,就是翻译的key或value丢失。

考虑到这个不是MVP版本的核心功能,我还是放弃在这个上面纠结太久,先写死了。
如果有解决过类似问题的朋友,欢迎在评论区指导。
爬虫的方案选型
最初,我打算使用Python自己开发爬虫来采集数据。写了一版openai的爬虫后,发现本地运行经常遇到防火墙拦截。

独立开发者的精力有限,能用Saas解决的问题就不重复造轮子,因此我找到了Firecrawl这个爬虫服务,实现数据爬取部分。它提供了强大的反爬虫能力,能够相对稳定地采集数据。

效果展示
趁着五一假期,完成了第一个Demo版本,实现了数据爬取和展示的基础功能。
虽然还很粗糙,但为了避免自己又虎头蛇尾,我还是希望尽早推向社区,帮助像我一样被AI选型折磨的打工人。
https://compare.effective-ai.org/
欢迎加个收藏,后续的功能会逐步更新。


总结
对Cursor的感受
作为一个从管理岗位回归技术一线的开发者,Cursor对我来说是一个很好用的工具。
前文中也提到了,cursor的优势在于辅助,例如不同技术栈之间切换,例如让写后端的人可以写出前端页面;大部分代码可以自动生成,可以让人专注于设计和指令,而不是被技术细节所困扰。但是,它仍存在一些无法解决的问题,例如对话轮数过多后,表现直线下降;对于真正0基础的人来说,并不像其宣称的那么好用。
AI工具带来的生产力提升效果还需要客观看待,但对于科技的发展我一向持积极态度。拥抱变化是主旋律,个人的认知势必要随之更新迭代。假设人的一生中需要工作40年,按照4年换一份工作计算,也需要换10次。4年前做的事情跟现在截然不同,也是情理之中。
在一个动态的系统中,没有一劳永逸的解决方案。
——《纳瓦尔宝典》
独立开发技术栈
分享一篇对我很有帮助的文章:https://guangzhengli.com/blog/zh/indie-hacker-tech-stack-2024
虽然迫于生活压力,没有办法完全彻底转型踏入独立开发者的道路,但我认为这里提到的观念和工具都是很有价值的。
以当前这个项目为例,目前使用的技术栈有:
- 前后端:Next.js + TypeScript + TailwindCSS
- Next.js提供了全栈开发的能力,减少了前后端分离带来的复杂性。
- TypeScript提供了类型检查,减少了运行时错误。
- TailwindCSS提供了原子化的CSS类,加快了样式开发速度。
- 数据库和鉴权:Supabase
- Supabase提供了免费使用额度,强大的数据库功能和实时订阅能力。
- Supabase Auth提供了邮箱登录鉴权能力。
- 部署:Cloudflare Pages和Github Actions
- Cloudflare提供了简单的部署流程和域名管理。
- Github Actions提供了爬虫脚本定时运行的
- 爬虫:Firecrawl
- Firecrawl提供了专业的爬虫服务,解决了数据采集的难题。
目前基本都是穷鬼套餐,预计用量增长后,这里也会产生相应的费用,希望这个项目能撑到这个时候:)
完成>完美
其实这不是我第一个启动的项目,我从去年开始陆陆续续做一些小项目,但基本都有头无尾。我很认可Build in public的思想,但因为种种原因,始终没有把自己做的东西发布出来。
失败的原因无非是:
- 有一个很宏大的规划,但是周期太长,没有坚持下来
- 做了一些没有内容支撑模板站,其实是徒有其表的草包,不产生任何价值
- 做的事情跟本职工作没有任何关联,纯纯摸鱼
最近两年一直在关注AI领域的创业机会,也陆续看了很多别人的成功或失败经验,从“GPT套壳”到“万物皆可Deepseek”。虽然觉得自己懂一万种道理,真正做的时候还是会因为这些“已知的原因”而踩坑,知行合一是一件很难的事。