# 一个人 3 天写小程序，LLM 我是怎么选的

> 开发微信小程序"心算小目标"过程中的 LLM 选型笔记  
> 适用读者：独立开发者、技术 Lead、想落地 AI 提效的小团队

上周，我一个人用了 3 天时间，把一个微信小程序从一行代码写到了上线可运行。

不是工作项目，纯粹是兴趣使然。我想做一个让孩子愿意做口算题、长辈愿意一起动动脑的小工具。3 天后，"心算小目标"上线了。

这篇文章想跟分享的是：在 3 天的开发过程中，我是怎么用 LLM 的——哪个模型做哪件事，为什么这么选，以及我踩过的坑。

## 一、先说结论

**没有"最好的模型"，只有"最匹配场景的模型"。**

我这 3 天的实际工作流：

| 任务 | 首选模型 |
|---|---|
| 写代码、写组件、写工具函数 | Claude Sonnet 4.5 |
| 查 API、读文档、解释错误信息 | GPT-5 |
| 中文文案、营销话术、品牌调性 | GPT-5 |
| 复杂算法推导、数学证明、公式调优 | Claude Sonnet 4.5 |
| 多语言翻译、跨语言改写 | GPT-5 |
| 长上下文（读整个项目再重构） | Claude Sonnet 4.5 |

这不是"哪个模型最强"的排名，是我**在真实工作流里**用出来的偏好。每个人、每个项目、不同任务、不同上下文，结论都不一样。

下面说讲讲我的选型逻辑。

## 二、三个评估维度

我选模型主要看三个维度，按重要度排序：

### 1. 任务匹配度

不同模型的训练目标和微调重点不一样。比如 Claude 在代码和长文本上有明显优势，GPT 在通用理解和多语言上有优势。

实际工作中，我会问自己：

- 这是一个**生成**任务（写代码、写文案）还是**理解**任务（总结、改写、提取）？
- 输入是**结构化**的（代码、数据）还是**非结构化**的（自然语言、对话）？
- 我需要模型**严格遵循**我给的约束，还是希望它**自由发挥**？

这三个问题答出来，模型选择范围就缩窄了一半。

### 2. 上下文窗口

我经常让模型一次性读完一个项目的整个文件夹再给出建议。这种场景下，上下文窗口不够大就完蛋。

目前主流模型的上下文窗口：

| 模型 | 上下文 |
|---|---|
| Claude Sonnet 4.5 | 200K tokens（实测可处理整个中型项目） |
| GPT-5 | 200K tokens（同样可处理整个中型项目） |
| DeepSeek V3 | 64K tokens（够用但吃力） |
| Qwen 2.5 | 32K-128K tokens（（视版本） |
| Kimi K2 | 128K tokens |
| GLM-4.6 | 128K tokens |

我平时用的 IDE 集成（Cursor、Trae）会根据模型自动处理上下文截断，所以"理论窗口"和"实际可用"不一样。**真正决定能不能用的，是模型在长上下文下的注意力稳定性**。

这上面，Claude 和 GPT 是双优——我喂给它们整个小程序的项目源码（约 80 个文件，2 万行代码），让它们做重构建议，两个都没"丢失上下文"。

### 3. 速度与成本

最后一个维度很现实：API 调用贵不贵、响应快不快。

这是目前我心里的性价比排名（个人体感，会变）：

- **极致便宜**：DeepSeek V3、Qwen 2.5、GLM-4.6（中文场景极强，token 单价最低）
- **中等**：Kimi K2、GPT-5 mini
- **最贵**：Claude Sonnet 4.5、GPT-5 full

我的策略是：**贵模型用在"必须"的场景，便宜模型覆盖"量大"的场景**。

举个真实例子：我开发小程序的时候，**写代码**这种"少而精"的场景用 Claude Sonnet 4.5（贵但准），**写测试用例、批量改文案**这种"多而重复"的场景用 GLM-4.6（便宜量大）。两个配合的用法成本比单一模型便宜 40%。

## 三、我具体怎么用

### 场景 1：写组件代码

**任务**：实现一个波浪动画的 SVG 组件。

**选择**：Claude Sonnet 4.5

**为什么**：Claude 在代码生成上有个独特优势——它倾向于先理解你的整体意图，再给具体的实现。我让它实现 5 层 SVG 波浪动画，它给我的第一版不是堆砌代码，而是先回答我：

> 这个动画的"紧迫感"主要由两个维度决定：时间紧迫感（视觉速度）和空间紧迫感（视觉密度）。我建议深层慢、表面快、交替翻滚……

然后才是代码实现。这种"先想清楚再动手"的风格，非常匹配我做技术决策时的思维方式。

GPT-5 在代码生成上也很强，但风格更偏"直接给方案"，对"为什么会这么做"的解释相对少一点。

### 场景 2：理解错误信息

**任务**：小程序报了一个我看不懂的渲染错误。

**选择**：GPT-5

**为什么**：错误信息理解是 GPT 系列的传统强项。Claude 在这事上也行，但 GPT 在多语言、技术术语标准化方面更稳定——它见过太多 GitHub Issue、Stack Overflow 的训练数据。

具体来说，我遇到 `TypeError: Cannot read properties of undefined (reading 'apply')` 这种错误，GPT 给的解释通常更接近"真实根因"，而不是套一个通用模板。

### 场景 3：写中文文案

**任务**：给小程序首页写一段"老师介绍"的话。

**选择**：GPT-5

**为什么**：GPT 在中文自然语言上有非常强的语感，调性拿捏更细腻。同样是写"幽默但不失分寸"的文案：

- GPT 写的："欢迎来这里～练习心算，10 组快问快答就能拿到小红花 🌸；也可以选个心愿，用小红花设置一个任务，分享到群聊让群友帮你实现。"
- Claude 写的：相对正式一点点，"幽默感"会少半档

中文文案这事，GPT 略胜一筹。

### 场景 4：算法推导

**任务**：调优时间锦囊的奖励公式 `gift = floor((10 - usedTime)^2)`。

**选择**：Claude Sonnet 4.5

**为什么**：这是数学题，不是代码题。Claude 在数学推理上的稳定性比 GPT 略好一点——它倾向于在给出公式前先验证边界条件（usedTime=10 时 gift=0、usedTime=0 时 gift=100）。

GPT 也能做这事，但偶尔会"想当然"地直接套公式，不验证边界。

### 场景 5：长上下文重构

**任务**：读整个小程序的代码，找出可以抽取公共逻辑的模块。

**选择**：Claude Sonnet 4.5 / GPT-5（两者都行）

**为什么**：这种任务对"长上下文注意力"要求极高。我让两个模型都做了同样的事：

- Claude：倾向于**先概述整体架构**，再指出可抽取的模块，最后给出重构建议。
- GPT：倾向于**直接列出问题点**，再给出重构建议。

风格不同，但结果质量相当。我更偏好 Claude 的"先概述"，因为它帮我重新理了一遍思路。

### 场景 6：批量改文案

**任务**：把小程序里所有"许愿"相关的文案统一改成"心愿"。

**选择**：GLM-4.6（便宜量大）

**为什么**：批量改文案是"量大"的任务，用最贵的模型不划算。

GLM-4.6 在中文场景下的表现超出我预期，2.5 元/百万 token 的价格让我可以放心让它跑几十次。

## 四、我踩过的坑

### 坑 1：用大模型生成"我想写"的东西

最初我尝试让 LLM 直接生成小程序的代码框架，结果生成的代码看起来很完整，但很多地方和我的产品设计不符。

教训：**LLM 是"结对程序员"，不是"接需求的外包"**。我应该给 LLM **清晰的产品意图**（PRD 级别），让它在我框定的范围内写代码，而不是让它帮我"做产品决策"。

### 坑 2：信任 LLM 的代码质量

LLM 写的代码第一遍通常都不能直接用。我后来养成了一个习惯：**LLM 给的代码必须 review，必须跑测试，必须考虑边界条件**。

具体来说，我会问 LLM：

> 这段代码在以下边界条件下会怎样：空数组、超大数组、Unicode 特殊字符、网络断开……

如果 LLM 答不上来，或者答错了，那这段代码就不能直接用。

### 坑 3：忽略上下文窗口的"实际可用"

Claude Sonnet 4.5 官方说支持 200K tokens，但实际体验中，喂 200K 的内容时，前 1/3 的注意力就开始下降了。

教训：**不要迷信"理论窗口"**。一个 80K tokens 的请求通常比一个 180K tokens 的请求效果更好。我会主动拆分大任务，避免一次性喂太多。

### 坑 4：工具选择影响工作流

我之前用 Cursor + Claude，写代码效率确实高，但 Cursor 的 IDE 集成有时候会"自作主张"——自动应用 LLM 的修改，结果破坏了我已有的代码。

教训：**让 LLM 给我代码，我自己 review 和应用**。这个流程比"LLM 自动应用"更慢，但更可靠。

## 五、我现在的工具栈

最后分享一下我现在的工具栈，方便你参考：

- **IDE 集成**：Trae（字节跳动的 AI IDE）+ Cursor（偶尔用）
- **主力模型**：Claude Sonnet 4.5（写代码）、GPT-5（理解 + 中文文案）
- **辅助模型**：GLM-4.6、Qwen 2.5、DeepSeek V3（批量任务）
- **不依赖某一个模型**：每个任务都根据"匹配度"选模型，不存在"我只看一家"的情况

## 六、未来我会关注的

- **本地化部署**：随着国产开源模型（Qwen、GLM、DeepSeek）的成熟，本地化部署的成本在下降。我自己的小项目在尝试用 Ollama + Qwen 2.5 做本地辅助。
- **多模型协作**：Workflow 里同时调用多个模型，让它们各自做擅长的部分，最后聚合。这是 AI Agent 的核心思路。
- **评测体系**：我开始建自己的评测集——把日常开发中遇到的真实问题整理出来，定期跑一遍各家模型，看哪个模型在哪个任务上更好。这是数据驱动的选型方式。

## 七、最后

LLM 选型没有标准答案，但我有几个原则：

1. **永远用最匹配场景的模型，不要用"听说最强"的模型。**
2. **让 LLM 做"生成"和"理解"，不要让它做"决策"。**
3. **保持评测习惯，自己跑出来的数据比榜单更可信。**
4. **不要被任何一家绑定，多模型协作是大势所趋。**

如果你也在选 LLM，希望我的经验能给你一些参考。如果你有不同的选型逻辑，欢迎留言交流。

— 写于 LLM 评测 v3 第七轮

---

如果你也在做小程序或 AI Agent，欢迎留言交流。
欢迎体验我的小程序，名字叫做：心算小目标

开发微信小程序"心算小目标"过程中的 LLM 选型笔记   适用读者：独立开发者、技术 Lead、想落地 AI 提效的小团队

一个人 3 天写小程序，LLM 我是怎么选的

产品砖家

人工智能

开发工具

编程语言

一个人3天开发微信小程序"心算小目标"的LLM选型实战经验。按任务匹配度选模型：Claude Sonnet 4.5写代码、GPT-5处理中文文案和错误理解、GLM-4.6覆盖批量任务，多模型协作可降本40%。提供真实案例、踩坑记录和工具栈参考，助你高效落地AI提效。

DeepSeek

2026上云采购 | AI焕新·智启新局

weda

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

一个人 3 天写小程序，LLM 我是怎么选的-腾讯云开发者社区-腾讯云

一个人 3 天写小程序，LLM 我是怎么选的

一个人 3 天写小程序，LLM 我是怎么选的

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐