这是《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. "王婆卖瓜"的厂商们
最近也频频接触了多个厂商的售前，看到了一些啼笑皆非的事，比如：
在众说纷纭的环境下，想要尽可能“科学决策”，降低决策成本是重中之重。
在模型更新换代如此迅速的情况下，认知和结论也需要实时更新。作为开发者出身，“不要浪费时间在可重复的事务上”已经是本能。而AI模型选型过程中的信息收集和对比分析，完美命中自动化的两大评估标准：重复度高、耗费大量时间。
因此，我们需要一个简单易用的模型选择器，降低认知成本，解决自己工作中的痛点。
核心的功能清单：
从毕业到现在，自己的技术栈一直是围绕后端打转，对于前端可以说是基本一窍不通。而在走上管理岗位后，写代码的机会也少了很多。好在如今有很多AI编程工具，可以降低编写实现的难度。
鉴于“选择合适的工具”也需要研究成本，从实际出发，有什么用什么。
公司买了Cursor Business，刚好可以薅羊毛，深度试用一下用Cursor搭建从0到1的项目。
之前零零散散用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会执行一些不必要的操作，或者在没有充分理解上下文的情况下做出错误的决策。
特别是在bugfix阶段，可以切回Ask和Manual模式，逐步调试和修复问题。
客观看待AI工具带来的生产力提升，以AI编程工具为例，我认为现阶段还没达到100%的可用率，而即使只有1%的工作量，对于真正0基础的人来说，其认知成本也不容小觑。
前端对我来说就是那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的优势在于辅助，例如不同技术栈之间切换，例如让写后端的人可以写出前端页面；大部分代码可以自动生成，可以让人专注于设计和指令，而不是被技术细节所困扰。但是，它仍存在一些无法解决的问题，例如对话轮数过多后，表现直线下降；对于真正0基础的人来说，并不像其宣称的那么好用。
AI工具带来的生产力提升效果还需要客观看待，但对于科技的发展我一向持积极态度。拥抱变化是主旋律，个人的认知势必要随之更新迭代。假设人的一生中需要工作40年，按照4年换一份工作计算，也需要换10次。4年前做的事情跟现在截然不同，也是情理之中。
在一个动态的系统中，没有一劳永逸的解决方案。
——《纳瓦尔宝典》
分享一篇对我很有帮助的文章：https://guangzhengli.com/blog/zh/indie-hacker-tech-stack-2024
虽然迫于生活压力，没有办法完全彻底转型踏入独立开发者的道路，但我认为这里提到的观念和工具都是很有价值的。
以当前这个项目为例，目前使用的技术栈有：
目前基本都是穷鬼套餐，预计用量增长后，这里也会产生相应的费用，希望这个项目能撑到这个时候：）
其实这不是我第一个启动的项目，我从去年开始陆陆续续做一些小项目，但基本都有头无尾。我很认可Build in public的思想，但因为种种原因，始终没有把自己做的东西发布出来。
失败的原因无非是：
最近两年一直在关注AI领域的创业机会，也陆续看了很多别人的成功或失败经验，从“GPT套壳”到“万物皆可Deepseek”。虽然觉得自己懂一万种道理，真正做的时候还是会因为这些“已知的原因”而踩坑，知行合一是一件很难的事。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。