关键词：微信小程序、独立开发、AI 辅助编程、算法产品化、育儿工具
适用人群：想做一个“工具型”小程序、对“规则数字化”感兴趣、或正在探索 AI 辅助编程（Claude Code/Codex/Qoder/Trae 等）的开发者。
1. 背景：为什么要自己造轮子？
1.1 真实育儿痛点
自从家里有了宝宝，“今天穿多少？”就成了每天早上的灵魂拷问。 尤其是换季或天气多变的时候：
- 天气预报的误导：同样是 15°C，晴天无风 vs 阴雨大风，体感完全是两个季节。
- 个体差异：新生儿、好动的幼儿、怕冷的小孩，对温度的需求截然不同。
- 场景切换：家里有暖气 24°C，出门只有 5°C，怎么穿能方便穿脱且不着凉？
- -能够手动编辑温度：根据用户输入的实际温度进行推荐。
1.2 市面产品的不足
搜了一圈市面上的工具，发现主要分两类：
- 通用天气 App：只给“穿衣指数”（如“建议穿毛衣”），太笼统，无法针对宝宝月龄定制。
- 母婴公众号/文章：只有静态的“穿衣公式”（如“洋葱穿衣法”），需要家长每天自己查天气、做加减法，不仅麻烦还容易算错。
1.3 程序员的解决方案
作为习惯了“万物皆可量化”的程序员，我决定把这些模糊的**“育儿经验”和“体感直觉”**，翻译成一套可运行、可验证的代码规则。
于是就有了这个小程序：基于实时天气 + 个人体质 + 场景（室内/外），自动计算出精确到“件”的穿衣与盖被建议。
2. 核心思路：把“经验”重构为“算法”
这个项目的核心不是 UI，而是背后的决策引擎。我将其拆解为四个步骤：
Step 1: 环境标准化（不再只看气温）
天气预报的温度只是基础。引入了一个 adjustTemperature 函数，综合了以下因子计算“体感温度”：
- 风力修正：大风天体感温度显著下降（风寒效应）。
- 湿度修正：高湿会让冷更冷（湿冷）、热更热（桑拿天）。
- 室内补偿：如果用户选择“室内”，则根据是否有暖气/空调进行温度补偿（通常 +3~5°C）。宝宝天气好随时需要出门。
Step 2: 用户画像参数化
“宝宝怕冷”不能只靠感觉。
- 年龄权重：月龄越小，基础代谢调节能力越弱，需要的保暖权重越高。算法里将 0-3 岁拆分成了 5 个细分阶段。
- 体质偏好：引入
sensitivity参数（怕热/标准/怕冷），对最终推荐结果进行非线性微调。
Step 3: 量化“穿衣法则” (The 26°C Rule)
采用了崔玉涛“26°C 穿衣法则”作为基准公式：
所需保暖度 = 26°C - 当前体感温度 + 年龄补偿
例如：体感 16°C，宝宝 3 个月大（补偿 +1°C），则需要补齐的温差为 26 - 16 + 1 = 11°C。
Step 4: 动态规划与规则约束
有了“所需温差”，剩下的就是从衣柜里凑出这个数吗？ 不全是。单纯的数字相加可能会得出“穿 5 件短袖”这种异常结论。因此引入了分层系统和约束引擎：
- 分层：打底层 (Base) -> 保暖层 (Insulation) -> 外层 (Outer) -> 配饰 (Accessory)。
- 约束：
- 连体衣与裤子互斥。
- 外层厚度必须 >= 内层（避免内厚外薄导致不适）。
- 极寒天气最多 3-4 层，避免臃肿。
- 必须有且只有一件外层（除非极热）。
3. AI 辅助开发实战：效率与质量的平衡
这个项目主要利用 Codex + Qoder 完成的。闲鱼买了Claude Code中转服务最近不太稳定且有点贵，如果从0到1开发一个项目token消耗不起，结合最近AI编码经验：找一个稳定的国产模型（IDE）解决日常问题 + 国外顶级模型解决架构或bug难题。
3.1 那些 AI 帮大忙的时刻
- 规则引擎的快速原型： 我向 AI 描述：“写一个函数，输入温度、风力、湿度，输出体感温度。参考炎热指数和风寒指数公式。” AI 瞬间给出了包含复杂数学公式的实现，我只需要微调参数。
- 繁琐数据的生成：
衣物数据库（
clothingData.js）包含几十种衣物的温度值、图标路径、适用年龄。我给了一个样例，AI 帮我扩充了剩下的 90%，并自动补全了英文 key 和中文描述。 - 正则与校验： 表单验证、时间格式化等“脏活累活”，交给 AI 几乎零失误。
3.2 那些 AI “翻车”的教训（以及如何解决）
- 逻辑漏洞：
初期 AI 写推荐逻辑时，容易出现死循环或推荐为空。
解决：我引入了 Property-based Testing (性质测试)。利用
fast-check库生成数千组随机天气数据，狂测 AI 写的函数，一旦抛出异常或返回空，就抓出来修复。这是保证算法健壮性的关键。 - 上下文丢失：
当文件变大，AI 容易忘记之前的约束（比如“连体衣不能配裤子”）。
解决：模块化。我把核心算法拆分到独立文件，每次只让 AI 关注一个小函数，而不是把整个
app.js扔给它。 - 幻觉： AI 偶尔会编造不存在的小程序 API。 解决：始终以官方文档为准，AI 给的代码必须在真机/模拟器跑通才算数。
3.3 我的“人机协作”最佳实践
- 人：定义接口（Input/Output）、设计数据结构、编写测试用例、制定业务规则（比如“什么是合理的穿衣”）。
- AI：填充函数实现、生成样板代码、编写单元测试、优化变量命名。
- 人：Code Review、真机体验、调整参数手感。
4. 项目结构与预览
4.1 目录结构
保持了原生小程序的简洁：
clothes-weather/
├── pages/ # 视图层
│ ├── index/ # 首页 (核心算法调用 + UI展示)
│ ├── guide/ # 科普页 (静态展示)
│ └── profile/ # 设置页 (宝宝档案管理)
├── utils/ # 逻辑层 (核心)
│ ├── clothing.js # 推荐算法引擎
│ ├── clothingData.js # 衣物数据库
│ └── weather.js # 天气服务适配器
├── images/ # 静态资源 (部分走云存储)
└── ...
4.2 效果预览
4.3 小程序二维码
5. 实现细节
5.1 天气与定位：高德 SDK 的接入与兜底
项目选用了 高德地图微信小程序 SDK 作为核心数据源，它能提供精准的逆地理编码（坐标转城市）和详细的实时/预报天气数据。 但在实际开发中，第三方接口可能会不稳定，或者用户拒绝授权定位。
- 策略：
- 优先高德定位：调用
amap.getWeather获取实时数据。 - 缓存降级：若定位失败，自动读取缓存的“上次定位城市”。
- 默认兜底：若缓存也失效，则降级为默认城市（如“北京”）。
- UI 保护：接口彻底挂了？展示“数据更新失败”，并尝试用历史数据或估算数据填充，坚决避免白屏。
- 优先高德定位：调用
5.2 资源管理：微信云开发 (Cloud Base) 的 CDN 实践
小程序主包大小有着严格的 2MB 限制，而高清的衣物和床品图片是“体积大户”。 我接入了 微信云开发 (Cloud Base) 的存储能力，将所有静态资源上传至云端。
- 接入方式：在小程序后台开通云开发，直接控制台上传图片，获取 CDN 链接。
- 代码实现：本地代码只保存图片的文件名（如
coat_thick.png），运行时动态拼接云存储的前缀域名。 - 效果：主包体积被压缩到了几百 KB，且图片加载享受微信生态内的 CDN 加速，体验极佳。
5.3 “换一套”功能的算法实现
用户常问：“我没这件羽绒服怎么办？” 算法实现：
- 计算当前推荐方案的总保暖值（如 +12°C）。
- 在衣物库中寻找其他组合，只要总值在
[11.5, 12.5]区间内，且不与当前方案重复，即为有效替代。 - 这样给出的不是“标准答案”，而是“参考范围”。
6. 后续规划
- 多宝模式：支持切换不同宝宝的档案（二胎家庭刚需）。
- 库存管理：用户可以勾选“我有哪些衣服”，算法只在拥有的衣服里推荐（避免推荐了买不到的款）。
- 更智能的学习：用户如果手动修改了推荐（比如把薄外套换成了厚外套），算法记录下来，下次微调该用户的体质参数。
7. 写在最后
当发现 AI 可以帮你把脑子里的“模糊经验”快速变成手中的“精准工具”时，编程的乐趣就被放大了。希望这篇文章能给你一些灵感，无论是做个小程序，还是写个脚本，去解决你身边的问题吧！
8. 参考资料
关于作者：LZG，全栈开发者，新手奶爸。喜欢折腾技术，也喜欢探索 AI 开发的边界。
