1. 杂记
近期在 Codex 和 Claude Code 指导和协助下做了一款熟人间的点餐微信小程序。记录一下实践相关经验。
此次前我还没有开发过微信小程序，也没写过 JS 等前端代码，没用过 python 的 fastapi 等服务框架，也没自己完整实践过项目的版本管理（包括dev版本到release版本的build部署，版本升级等等）。
过程中还是学习了不少。但更为重要的是，现在靠 ChatGPT + Codex + Claude Code 让我此次完整实践和学习的效率都高了非常多。
这里记录一些实践经验
2. 小程序申请备案
在微信开放平台新建一个小程序并跟随引导设置小程序名字、图标、邮箱、备案信息等。
如果是个人账户（我这次这种）申请的小程序则不允许涵盖经营相关内容，也不支持支付等接口。
且个人账户的小程序在备案时需要说明清楚用途和经营无关（我为此备案失败了三次）。
3. 微信开发者工具
下载微信开发者工具，用微信号登录，AppID处应该可以直接选择上一步创建的 App 的 ID
前端架构由于是用 AI 开发，建议用尽量基础一点的架构（训练数据更充分），即 JS-基础模板，可以减少一些 bug 的可能性。
创建后目录下会自动创建一版基础的微信小程序工程结构。
4. 工程结构
由于我们希望尽量用 AI 来开发，肯定是希望 AI 能同时负责前端和后端，且能提升开发效率（如遇见 bug 先检查前端代码，没问题就自动继续检查后端），否则我们还要扮演联调过程的通信者。
所以我们可以把客户端工程目录 client, 服务器工程目录 server, 文档目录 doc 放在同一个大工程文件夹下。
这样无论使用 Claude Code、Codex、Gemini Cli、Copilot 都可以直接在大文件夹下操作，更加方便。
4.1 文档
参考 SPEC AI 开发工作流，即先有 Specification Document 再基于此文档开发，个人体验在现阶段 AI 开发效果还是蛮好的。个人体验优势如下：
SPEC 优势1：文档化厘清自己的需求。
表达清楚脑海中的想法，并不是一件自然而然或者轻松的事情，是需要付出一些努力的，文档化就是在帮助自己结构化厘清想法。
不过甚至更多的时候，往往脑海中的想法本身就是模糊的，更需要通过文档（也可以结合其他比如草图之类的方法），让自己的想法清晰完善起来。
对想法有了 好的/结构化/精确的 需求描述，AI 执行的结果才更可预期
SPEC 优势2：高效把控 AI 开发结果
目前 AI 以及 agent 训练，尽量遵循需求本身开发基本上都是最基础的要求。且实践下来 Codex、Claude Code 这方面能力都是不错的（有些复杂的需求有时会只做一半，但偏离一般很少，通常也仅在细节上，后期很好改）
所以很大程度上，把控住 SPEC 文档，就把控住了后面 90% 的 AI开发。
且相比于 AI 开发以后去各个文件里分析函数引用关系，慢慢阅读代码而言，阅读 SPEC 显然就轻松高效了太多
SPEC 优势3：AI 协助高效写 SPEC
在团队开发中，写 SPEC 文档本身确实也是一件不太轻松的事情。
不过现在有了 AI 本身可以帮助我们写 SPEC （进一步让AI扮演产品经理角色），效率则更进一步
具体而言，比如对于一个 feature 可以先写一个简单的需求，表达清楚自己暂时想到的想要的东西:
日历页面的翻页功能
当前问题：日历页面仅能看到12天，如果想提前发出餐次或者提前很多天下单都做不到
考虑修改：
- 添加分页逻辑，默认页是从当下的昨天，到当下之后的第12天，一共14天，即两周
- 日历的顶部可能有一个可点击的按钮，文本为“两周前”点击后相对于当前分页的日期整体往前14天，刷新整页
- 日历底部有一个可点击的按钮，文本为“两周后”，点击后相对当前分页的日期整体往后14天，刷新整页
- 设计一下这两个按钮样式，尽量和页面搭配一点，好看一点
- 可以尝试顶部的“两周前”按钮默认看不到，需要往下拉，滑动后才能看到，即默认进入日历页面时滑动位置在此按钮以后
基于以上需求先写此feature 的 SPEC 文档。先不要改代码并且要求 AI 去基于此写 SPEC（我一般写 SPEC 喜欢用 Codex：感觉Codex 更擅长设计，且可以云端处理需求，手机提需求，就很方便）
AI 写完以后看一看 AI 写的 SPEC 文档（建议如果要对开发有把控力，尽量要有能力搞懂文档提到的所有内容，如果不懂则没办法掌控。AI 时代想搞懂这些也不难，问 AI 就行，慢慢学）
AI 写的 SPEC 经常会有一些细节非我们预期的。比如歪曲、更常见的是添加很多没必要的逻辑、以及 AI 对于有些实现会直接在 SPEC 中写两套方案。对于这些我们需要进一步对 SPEC 进行修改。
- 可以自己手动修改 SPEC，适合改一些小细节，或者删一些没必要的内容
- 也可以把想修改的内容列成 list 丢给 AI 来修改（更像老板和产品经理开会对方案）
- 图库管理面不显示图片有效标记为否的图
- 已失效/已删除的图片 不要有恢复功能
- 图库页面可以选择一张图其作为默认图（可能存在 system settings?存一下默认图的 id），默认图在图库页面有个标记。删除默认图，自动找一个最新的且还生效的图作为默认图。要考虑图库不存在任意有效图片的情况（各个列表选项内容处提示“无”，图片用纯灰之类的占位都行）
- 餐次、订单创建、订单展示页面如果发现当前餐次的图片失效/或没有文件/图片ID不存在，则展示默认图
- 创建餐次时默认选择默认图
- 图片展示时统一剪切到16:9比例（受前端控制）
- 不用统计图片的引用次数对于一些复杂的需求， SPEC 可能需要修改多轮。
SPEC 确定没问题，再让 AI 实际去根据 SPEC 开发和测试（不过由于是微信小程序，目前 AI 仅方便对后端逻辑进行测试，前端需要手动来）。
5. AI 使用
由于 Claude Code 对中国封锁非常严，要在国内使用需要比较强的梯子，但我自己尝试失败了。
目前使用的方式是直接用在美国的云服务器来远程控制开发（vscode ssh 远程开发非常方便）。
且我尝试过阿里云的美国服务器，发现依旧用不了（openai 和 claude 都是），应该是专门针对阿里云服务器做了屏蔽。
Google Cloud , AWS , Azure 这些应该可以用，但价格都不便宜（即使首年有免费额度，但总是时间有限）
个人暂时找了个国内不知名的小云服务器商，非凡云，可能是比较小，没上 Claude 和 Openai 的封锁名单
如果没有合适的方式，也可以尝试我这种方法。
我的非凡云邀请链接：https://sso.ffy.com/sign-up?invite_code=PZkF8tgNkv
5.1 Codex
codex