要不要退掉 Anthropic 订阅？别急，用这套对照测试跑一遍

你刷到那种对比帖子：

• “同一个提示词，让模型写个宝可梦对战小游戏”
• “A 做出来老崩溃，UI 也难看”
• “B 一次就交付精品级作品”

看完很容易上头：那我是不是该把某家的订阅退了？

我建议你先别急。社媒的演示很刺激，但退订这事，最好用你自己的需求跑一遍对照测试。跑完你会很踏实：该留谁、该双持、还是该退，都有依据。

下面这套流程，照做就行。🧪

你真正要比的不是“谁更强”，而是“谁更适合你”

做应用时，模型差距往往不体现在“能不能写代码”，而体现在这些细节：

• 稳定性：能不能一次跑起来？还是动不动白屏/报错/依赖缺失
• 交付完整度：有没有把安装、启动、构建、数据结构都讲清楚
• UI 观感：排版、交互、动效、状态提示，像不像个产品
• 可维护性：目录结构清不清晰，有没有类型、注释、可扩展点
• 修复效率：你甩一个报错，它是“对症下药”还是“继续胡写”

你付费买的，其实是这些。

对照测试目标：同一条提示词，生成“回合制对战 Web 小游戏”

为啥选这个？

因为它刚好卡在“有点复杂但不离谱”的区间：

• 有 UI（信息密度高，容易翻车）
• 有状态机（回合、技能、血量、异常）
• 有随机与平衡（伤害、命中、暴击）
• 有工程化（依赖、构建、组件拆分）

如果一个模型能把这个交付得很稳，你日常的后台管理页、落地页、工具站基本都能省不少事。

一条拿来就能用的提示词（直接复制）

建议你在不同模型里完全原样粘贴，不要手欠微调。微调会把对比搞脏。

你是资深前端工程师 + 轻度游戏策划。
请用 React + TypeScript + Vite 生成一个“回合制对战”Web小游戏（灵感类似宝可梦，但不要使用任何宝可梦名称、素材、招式名）。

硬性要求：
- 必须一次就能跑起来：给出完整项目结构、关键文件完整代码、安装与启动命令。
- UI要像产品：左右对战面板、血条、状态图标、技能按钮区、战斗日志区；移动端也能用。
- 玩法：双方各3只生物（自定义名字），每只生物4个技能（伤害/增益/减益/防御至少各1个）；回合制，速度决定先手；支持异常状态（中毒/灼烧/眩晕任选2个）；胜负条件明确。
- 数值：给出合理的基础数值与技能倍率，避免一回合秒杀；加入命中率与暴击。
- 工程：用清晰的状态管理（可用 useReducer），写出类型定义；组件拆分；不要引入大型状态库。
- 可扩展：技能与生物数据用 JSON/TS 常量表驱动，方便我后面加内容。

交付格式：
1) 项目目录树
2) 逐个文件给出完整代码（不要省略）
3) 运行步骤
4) 你做的关键设计说明（短一点，讲清楚规则和数据结构）

注意：不要引用外部图片或在线资源；所有内容必须本地可运行。

跑分标准：用这张表打分，别凭感觉

建一个表格（Notion/Excel 都行），每个模型跑一次就填一次：

• 可运行（0/1）：pnpm i && pnpm dev 能不能直接出页面
• 报错数量（0~5）：依赖缺失、类型错误、运行时报错
• UI 完整度（0~5）：布局是否齐全、信息是否清晰、移动端是否能看
• 玩法完整度（0~5）：回合、技能、异常、日志、胜负是否闭环
• 数据驱动（0~5）：生物/技能是不是表驱动，扩展是否顺手
• 可读性（0~5）：类型、命名、拆分、注释
• 二次修改成功率（0~5）：你改一个需求，它能不能稳稳改对

建议你加一条最关键的：

• “我今晚能不能早点下班”指数（0~5）：你自己最真实的体感 😄

测试流程：照着做，10 分钟见分晓

1）固定环境，避免“你机器不一样”

• Node 版本固定：例如 node 20.x
• 包管理器固定：pnpm 或 npm 选一个
• 新建空目录，各模型输出都放不同文件夹：

mkdir llm-battle-benchmark
cd llm-battle-benchmark
mkdir model-a model-b

把每个模型的输出分别落地到对应目录。

2）只做一件事：按它给的步骤跑

你要做的不是“帮它擦屁股”，而是看它交付的成品能不能跑。

• 能跑：记 1 分
• 不能跑：把报错完整复制回模型，让它修

3）用同一条“修复提示”回灌

不要自己分析半天再改。你要测的是模型的工程自救能力。

修复提示模板：

我按你的步骤运行后报错如下：
（粘贴完整报错堆栈）

请你：
- 解释根因（1-2句）
- 给出需要修改的文件与完整替换代码
- 给出我需要执行的命令（如需）

修两轮还起不来，稳定性这项基本就见分晓了。

常见翻车点清单（你用来“卡模型脖子”）

很多“看着很强”的演示，死在这些小地方：

• 缺文件：目录树写了，关键文件没给全
• 省略代码：出现“其余类似”“略”这种字样，直接判不合格
• 依赖不一致：写了 Tailwind，却没配 PostCSS；写了图标库，却没装
• 类型地狱：TS 类型不全，运行一堆红线
• 状态混乱：回合推进逻辑散落在多个组件里，修一次崩一次
• 随机失控：伤害公式太离谱，一回合秒杀，谈不上“游戏”
• UI 不可用：技能按钮点了没反馈、日志不滚动、移动端挤爆

你别客气，这些都算“交付质量”。

退订决策：用三句话就够了

跑完对照测试，把结果摊开看，通常会落到这三种结论：

结论 A：留着 Anthropic（或你正在用的那家）

适合你这种情况：

• 你更看重长文本推理、写作稳定、复杂需求拆解
• 你工作流已经绑定（项目、提示、团队习惯都在那边）
• 你跑分里“二次修改成功率”很高

这时退订反而亏，因为你换平台会重新磨合。

结论 B：换到另一家做主力

适合你这种情况：

• 你最常做的是“从 0 到 1 生成小应用/页面”，交付完整度是王
• 你跑分里“可运行”与“UI 完整度”差距很大
• 你不想天天当 QA

一句话：你买的是稳定省心。

结论 C：双持，一个写、一个修

这很常见，也很现实。

• A 更会搭架构、写规则
• B 更会补 UI、修报错、补工程细节

如果你每天都要产出，双持往往比“押宝单一平台”更少折腾。

进阶：把“社媒对比”变成你自己的长期基准

你可以把这套小游戏当成固定 benchmark。

每次模型更新、价格变化、上下文策略调整，你就跑一遍。

建议再加两个小任务：

• 重构任务：让它把 useState 乱写的地方改成 useReducer
• 新增需求：加一个“护盾”机制或“技能冷却”机制

模型强不强，新增需求最能照妖镜。

你可以直接抄走的结论

“别人说某模型碾压”这种信息，只适合当风向参考。

真要决定退订，别靠情绪。

拿同一条提示词，让它们在你电脑上跑起来。谁让你少加班，谁就值。✅