游牧周记第50期
· 5 min read
标签 Tags
claude skills
开发
现在的微信小程序开发是怎样的?
我上次写小程序大约是4年以前。 这次接到一个想法,所以又拿起来试试。 体验是:
- 还是得用微信的工具
- 默认还是js而不是ts
- gitHub似乎不好接入,自带的git没搞明白
- 文档还是很不好查
- 语法等方面似乎多年没变化 不过幸好有terminal,我试了一下claude cli居然能用。 快速写了个云函数实现的AI Chat。
小程序开发的坑
- 不支持导入json文件,不管是require还是import都不行,只有改成js文件export了。
- 页面间传参数,中文会乱码,必须先编码,接收端再解码,但我遇到的情况更奇葩,要双重解码才能用,明明就是一个字符串而已。
- 调用云函数失败: Error: cloud.callFunction:fail Error: errCode: -504003 | errMsg: Invoking task timed out after 3 seconds ,云函数的默认超时时间3秒,如果连接第三方服务如ai等,就要设置长一点,免得随时报错。这个在云函数面板很深处设置,和env一样。
小程序还不能实现的
- AI Chat的流时输出,靠云函数还不行,除非自建服务器。
react的context和zustand用哪个?
发现前几天AI帮我写的一个复杂组件,用了context做状态共享管理,又是provider又是reducer的挺复杂,它可能不知道我装了zustand。 以前我用zustand主要是全局管理,当时一个组件(由一些分组件构成的逻辑链)就没想到用。 这两种到底谁好呢? AI总结:
如果你已经装了 Zustand,就不要再为了局部状态引入 Context。
直接创建一个独立的小 store,既高效又简洁。
| 项目类型 | 状态作用范围 | 推荐方式 |
|---|---|---|
| Expo / Next.js | 局部 UI 状态(颜色、开关) | Context |
| Expo / Next.js | 多组件间共享业务数据(购物车、表单、播放控制) | Zustand 局部 store |
| SSR 项目(Next.js) | 跨请求安全的全局状态 | Zustand + 自定义初始化逻辑 |
但是性能和使用复杂度的双重优势,让人必须选zustand啊。
| 特点 | React Context | Zustand |
|---|---|---|
| 设计定位 | 提供全局数据传递的通道 | 状态管理库(比 Redux 轻量) |
| 状态存放 | Context Provider 内部 | 独立的 store(React 之外) |
| 状态更新触发 | 依赖 React 渲染机制(Provider 的 value 变化会导致消费组件重渲染) | 基于订阅机制(只更新订阅的组件) |
| 使用复杂度 | 简单(但易导致重渲染) | 简单且性能更好 |
| TypeScript 支持 | 需要手动声明 | 内置优秀的类型推导 |
| SSR 支持 | 原生(React 内置) | 需要一点配置(Next.js SSR 支持良好) |
个人结论,以后没事就别折腾什么context了,直接zustand搞定一切。 当然据说react 18+对性能有所改善,待观察。
我目前的AI辅助开发模式
显然每个人的工作流程和习惯都是适应出来的,类似生物进化。 这个时代,每天都有人在推荐更好的方式、更好的工具、更好的模型。 我建议你们看一眼就好,没有颠覆性的东西出现前,还是要自己用着趁手才是最好的。 如何找到最适合自己的路线,不在工具层面浪费太多时间和成本呢?
- 先按以下思路理清楚几个问题并诚实回答:
- 不考虑条件限制的话,我想要的最好方式是什么?
答:和OpenAI沟通,整理自己的思路;具体开发过程在Claude code + Claude最好模型辅助下进行;无限制tokens;再加上好用的代码补全。

