> 作者：于晓帆 ｜ 2026-09-29

## 一、先说结果

我 53 岁，做了半辈子供应链管理（采购 / PMC / 库存 / 交期），**不会写一行代码**。

2026 年 6 月 26 日动手，三个多月，我用 AI 交付了两个完整系统：

| 项目 | 规模 | 状态 |
|---|---|---|
| **「AI复盘手」**（微信小程序） | 402 个文件 / **11.4 万行代码** / 38 个云函数 / 25 个页面 | ✅ 2026-09-29 已上线运营 |
| **WorkBuddy · SCM 供应链管理**（企业级 H5） | 313 个文件 / **9.9 万行代码** / 24 个业务域 / 376 个 API / 109 张数据表 | 工厂实测调优中 |

**合计 18.6 万行代码。**

下面分两部分：**先讲这两个系统是怎么搭起来的**（技术部分，可复用的经验），**再讲 AI 和人各自站在什么位置**（我认为更重要）。

---

## 二、「AI复盘手」的四个架构决策

帮做股票期货的人看清自己怎么亏钱。技术栈不复杂，但有几个决策我认为值得记录——尤其是**微信云开发在一个真实商业产品里能做到什么程度**。

---

### 2.1 为什么选微信云开发

对一个人做产品来说，最大的约束不是技术，是**没有团队**。云开发直接消掉了三个负担：

| 环节 | 传统做法 | 云开发 |
|---|---|---|
| 服务端 | 买服务器 / 配环境 / 部署运维 | 云函数，写完即用 |
| 数据库 | 建库建表 / 连接池 / 备份 | 云数据库，SDK 直连 |
| 定时任务 | Cron / 调度框架 | 云函数定时触发器 |

**实际用量**：38 个云函数，覆盖 AI 报告生成、定时调度（日/周/月/年报自动生成）、支付回调、跨端数据同步。这在传统架构里，是至少一个后端团队的工作量。

---

### 2.2 四个我认为值得分享的实践

#### 1. 四层数据存储，解决"记录永不丢"

这是我踩了坑之后重建的架构。对一个**以记录为核心**的产品，丢一条数据都是致命的。

```
L1 内存 → L2 本地 Storage → L3 本地文件 → L4 云端密文备份
```

关键设计：

- **写入后验证**：每次写 L3 文件后立即读回解析，失败重试；主路径全失败则写根目录备份
- **历史快照轮转**：写主文件前，把旧文件轮转为历史快照（保留 2 版），主文件损坏时可回滚
- **云端密钥自愈**：密钥由 `openid + 平台盐值` 派生（`derive-key` 云函数），客户端派生失败时清理残留并重新派生
- **跨设备按天合并**：同一月份的数据在云端按月分片存储，下载时按"日期键并集"合并而非整月覆盖——解决多设备互相同步时"乒乓覆盖"

**踩过的坑**：早期客户端"加密模块未就绪时静默跳过上传，且不记日志"，导致数据只存本地不上云，排查时毫无线索。现在的做法是：**未就绪也入上传队列，由重试机制在就绪后补传**，并打印明确警告。

#### 2. 定时任务：并发池 + 时间预算 + 接力补漏

云端定时生成用户报告，是个典型的"数量增长就崩"场景。云函数有执行超时上限，用户多了必然跑不完。

我的方案是三件事组合：

```js
// 伪代码示意
_processWithConcurrency(users, worker, {
  concurrency: 3,          // 并发池
  timeBudget: 240000,      // 240s 时间预算
}) 
// 接近预算就停止拉新用户，优雅返回
// 未处理的用户，由下一个档位的定时器接力
```

配套两点：

- **幂等保护**：每个用户的报告按 `cacheKey` 判断是否已生成（无论来源），避免接力档重复覆盖
- **多档定时**：日报设了 8 个时间档位（按用户各自设定的复盘时间分散命中）+ 1 个补漏档，而不是所有人挤在一个时刻

#### 3. 加密：openid 派生密钥（平台可信加密）

**先说清定位**：这不是端到端加密（E2E），是**平台可信加密**——密文存云端，密钥由 `openid + 平台盐值` 派生，平台依法可解密（用于生成报告、多设备恢复）。

密文格式：

```
base64( IV[16] || AES-256-CTR(plaintext) || HMAC-SHA256[32] )
```

服务端密钥派生集中在 `cloudfunctions/lib/server-crypto.js`，客户端在 `crypto-helper.js`，两端格式对齐。

**一个真实教训**：曾有用户的记录出现"解密失败（密钥不一致）"。根因是历史遗留的坏密文——客户端解密失败后走哨兵值不入结果集，导致"用本地明文重新覆盖云端"的自愈分支**永远不可达**。修复思路是：**让"解密失败"这个信号能传递到上层的自愈逻辑**（0 条有效记录 + 有失败标记 → 触发重传覆盖）。

#### 4. 主包 2MB 上限：死代码审计 + 分包

小程序主包有 2MB 硬上限。功能越加越多，一定会撞线。

我的做法不是"随便删点东西"，而是**用脚本做全项目扫描**：

1. **死样式扫描**：把所有 `.wxss` 的类名提取出来，与全项目语料（wxml / js / wxs / json 的标识符 + 字符串拼接前缀）比对，命中即保留——最后清掉 73KB 确证死样式
2. **分包重构**：把低频组件下沉到子包（如把只被"我的"页用到的浮层组件移入 `pkg-mine`）
3. **组件跨包引用**：用 `componentPlaceholder` 解决跨分包组件的首帧占位

**一个反直觉的发现**：体积报告里"插件"那一栏会把同一个插件**重复统计多次**，看起来占用很大，实际只打包一次。别被报告误导——最后还是要看上传时的真实包大小。

---

## 三、SCM 供应链系统：把工业逻辑搬进代码

如果说小程序是"把一个想法做出来"，那 SCM 系统就是"把一个行业的复杂度装进去"。

### 3.1 它长什么样

面向中小制造企业的供应链管理，覆盖从**销售预测 → MPS 主生产计划 → MRP 物料需求 → APS 高级排程**，到轻量 WMS / TMS 的全链条。核心指标：

| 维度 | 数据 |
|---|---|
| 后端（Node + Express） | 191 文件 / 59,923 行 |
| 前端（React + AntD） | 122 文件 / 39,322 行 |
| **业务域** | **24 个模块**（路由层 16,099 行 ｜ 智能体 7,169 ｜ APS 排程 6,627 ｜ 工具 6,288…） |
| API 端点 | **376 个** |
| 数据表 | **109 张**（建表集中在 `schema.js`，2,667 行，全项目最大文件） |
| 前端页面 | 97 个 + 16 个公共组件 |

### 3.2 两个我认为关键的工程决策

**一是"依赖极轻"**。后端运行依赖只有 6 个，前端 9 个——用 `node:sqlite` 免掉了独立数据库服务器。对中小制造企业的私有化部署场景，这意味着**交付成本极低**：不用教客户配数据库、不用运维中间件。

**二是"异常要看得见"**。制造业最怕的不是出错，是**错了没人知道**。所以系统里做了安灯（Andon）机制：工序出现断点，看板显示异常状态，**并自动通过微信通知责任人**。这个设计来自我在工厂的经验——供应链的问题从来不是"发现不了",而是"发现了没人管"。

### 3.3 它和"AI 写代码"的关系

必须说清楚：这套系统能长到 109 张表、376 个接口还不乱，**靠的不是代码写得漂亮，而是业务骨架是我想清楚的**。

从基础数据到智能中心，每个域管什么、谁依赖谁、哪里是断点，我心里有一张图。AI 负责把这张图变成 9.9 万行代码。

**这恰好印证了我的判断：人提供思想，AI 提供实现——而思想来自你真正干过的事。**

---

## 四、AI 在其中的角色

必须承认：**这 18.6 万行代码我一行没写，全部由 AI 编程工具生成。**

但我想说的不是"AI 很强"，而是**AI 和人各自该站在什么位置**：

- **AI 强在"给定方向上的执行力"**——你说清了要什么，它实现得又快又好；
- **AI 弱在"质疑方向本身"**——我曾遇到它在一个错误假设上重试 12 次的情况（一直在查加密算法，而真正的问题是"根本传不上去"）。它的努力放大了错误的方向。

所以我的角色不是"程序员"，是**系统设计者 + 纠偏者**：把系统拆成节点、看清依赖、判断方案会不会堵，在它偏了的时候说一句"不是这里"。

**这套能力恰好来自我的本行**——供应链管理。做产品的这几个月里我发现，"物料"可以变成"用户需求"，"产线"变成"功能模块"，"交期承诺"变成"上线时间"，"异常处理"变成"边界条件与兜底"。**思维模型是可以迁移的，代码不需要。**

---

## 五、给同路人的三句话

1. **门槛不是零，是转移了**——从"会写代码"转移到"想清楚"。想不清楚，AI 只会更快地给你一堆错东西。
2. **守住工程纪律**——不编造数据、失败必须可诊断、体积与可靠性必须人把关。这三件事 AI 替不了。
3. **你的行业经验是壁垒**——技术人人可学（现在 AI 帮你学），但对业务的理解来自你真干过。

---

*关于作者：于晓帆，前供应链管理专家（采购 / PMC / 库存 / 交期），现 AI 时代独立开发者。深圳市载禧科技有限公司创始人。*


我 53 岁，做了半辈子供应链管理（采购  PMC  库存 / 交期），不会写一行代码。

# 53 岁不会写代码，我用 AI 交付了 18.6 万行代码：一个已上线的微信小程序 + 一套企业级 SCM

53岁，不会写代码，用AI三个多月交付了两个系统：一个已上线的微信小程序（11.4万行/38个云函数）+ 一套企业级SCM系统（9.9万行/376个API/109张表），合计18.6万行代码。本文讲架构决策与踩坑，以及一个判断：AI强在执行，弱在质疑方向。

独立开发者

人工智能

编程语言

低代码

53岁供应链专家零代码基础，用AI工具3个月开发2套系统共18.6万行代码：微信小程序"AI复盘手"已上线，企业级SCM供应链系统含109张数据表、376个API。分享四大架构决策、定时任务并发池、加密方案及2MB包限制优化经验，论证行业经验+AI是开发新范式。

代码解释

数据同步

数据存储

云数据库

服务器

云函数

数据库

智能体

中间件

AI编程

路由

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

tencentdb-catalog

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

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

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

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

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

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

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

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

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

社区新版编辑器体验调研

# 53 岁不会写代码，我用 AI 交付了 18.6 万行代码：一个已上线的微信小程序 + 一套企业级 SCM-腾讯云开发者社区-腾讯云

# 53 岁不会写代码，我用 AI 交付了 18.6 万行代码：一个已上线的微信小程序 + 一套企业级 SCM

# 53 岁不会写代码，我用 AI 交付了 18.6 万行代码：一个已上线的微信小程序 + 一套企业级 SCM

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐