话说回来，

大家好，我是孟健。

Kimi K3 发布了。这个结果，我终于可以公开说了：发布之前，我已经把 ShipSolo 微信小程序这个真实项目整个交给它。从需求梳理到部署验证走完全程，最终完整交付。

交付出来的体感，已经摸到 GPT‑4 和 Claude Opus 那一档。跑完这一趟，我最直接的感受是：国产模型真的到这一档了。

项目比看上去复杂得多

ShipSolo 是我在运营的产品，官网已有大量免费文章、会员手册和一整套站点技能。这次给它配一个微信小程序，听着简单，实际接手的是一整套已经在跑的程序。

现有程序里有基于 D1 的后端数据，有 Google OAuth 账号程序，有一个只写了一半、留着历史遗留问题的小程序 repo。还有 Nginx + SSL 的服务器和 Cloudflare Worker + OpenNext 的部署链路。域名有两个这方面，shipsolo.io 面向海外使用者。shipsolo.cn 已完成备案。微信小程序的 request 合法域名必须走备案域名。.io 这条路走不通，只能靠 .cn。话说回来，

痛点：多套技术栈混合、备案限制、历史遗留代码。这些都容易导致需求误判或实现卡壳。

我给 K3 的首轮需求有五点：

• 小程序尽量复用 shipsolo.io 的现有数据；
• Google 登录的使用者要和微信身份打通；
• 文章要方便在微信群、朋友圈转发阅读；
• 小程序定位偏获客引流；
• 遇到不清楚或信息不足的地方主动来问，不要自己瞎猜。

K3没有急着写代码，先把问题摸清楚

K3拿到需求后没有直接开工，而是先通读了 README、NEXT_STEPS、miniapp 目录、后端代码还有 D1 的 schema。又抓取了 shipsolo.io 的线上页面并用本机 GitHub CLI 把网站源码克隆下来对现有 API 结构、认证方式、内容组织方式做了全景式梳理。

调研产出：

• #1 TabBar 图标缺失导致编译报错；
• #2 复制微信号功能内容为空；
• #3 搜索接口路由存在 bug；
• #4 分享按钮无响应。

痛点：

K3还识别出小程序合法域名必须备案的硬约束，提出用 api.shipsolo.cn 做一层桥接。后端数据方案给出了三种选项，并逐条列出维护成本和数据一致性风险。最终可以使用单库反代方案，以避免双写和数据漂移。