做小程序先别写代码：骨架最关键

Tue, 04 Aug 2026 20:30:00 +0800

很多人做小程序，第一反应是先把界面画漂亮。

我刚开始也一样，兴致勃勃想先把首页搞得赏心悦目。后来被自己按住了：界面是皮，数据是骨。骨头没搭正，皮再好看也立不住。

说个底：这套小程序，是靠 WorkBuddy 加腾讯混元（hy3）一点点磨出来的。我本来不是干这行的，在能源行业待了二十多年，写代码的事儿从没碰过。所以下面这套"动手前的准备"，你照着做，也能折腾出自己的小工具。

动手写代码之前，先把"要记什么数据"想清楚，再让 AI 帮你搭骨架。这道理外行也能懂。

一、先砍功能：MVP 不是偷懒，是清醒

「简单记」上线初期，我故意只做一个核心功能——把日常小事随手记下来。

为什么砍？精力就那么多。先把一个核心闭环做到你每天都想用，比铺一堆用不上的功能强。

可直接复制的提示词： 我要做一个 XX 小工具，脑海里有一堆功能。帮我把它们分成"必须有 / 可以有 / 暂时不要"三档，并说明每一档的理由。别急着写代码。

我把它记成一句话：MVP 是最小可活版本，先验证有人愿意用，再谈功能多不多。

这一节真正的重点：让 AI 帮你做减法，比做加法难，也更值钱。

二、把"我要记的东西"翻译成数据

我盘了一遍自己到底要记什么：一件要记的事，得有名字、单位、范围；一次记录，得有哪天、多少、备注。

落成三张结构（这是 utils/defaultData.js 里真实的定义）：

// 记录项类型：名称、单位、范围、步长，都在一处统一定义
record_types:  [{ id, name, unit, minValue, maxValue, stepValue, emoji }]
record_items:  [{ type, name }]            // 该类型下记什么具体事项
record_entries:[{ id, type, item, value, unit, date, note }]  // 一条条真实记录

可直接复制的提示词： 帮我把"我想做 XX 工具"翻译成一套数据表：需要哪几张表、每张表有哪些字段（名称/类型/说明）。用大白话，别写代码。

说白了就一句：先定义"名词"（也就是数据），再定义"动词"（也就是操作）。名词稳了，动词才好写。

三、先结构后界面：给 AI 的指令都变了

有了数据模型，我再让 AI 搭页面，说的就不是"做个好看的页面"了。

而是：“按 record_entries 渲染列表，按 record_types 出筛选。”

AI 给的东西明显更对路——因为我自己的需求变具体了。

可直接复制的提示词： 基于上面这套数据表，帮我生成页面骨架：需要哪几个页面、每个页面放什么、数据怎么取。先给结构，别一步到位写满功能。

你越具体，AI 越准。模糊的需求，只会养出模糊的产物。

四、不会编程也能用：用这思路理一份"周报台账"

怕你以为这套只服务于写代码，我拿个纯办公、零代码的场景收尾：做一份自己的周报。

还是那几步：

砍功能：“周报先只记’本周做了啥 + 下周计划’，别一上来搞 KPI 看板。”
定数据：“需要两张表：事项（谁/什么/状态）、计划（下周/负责人）。”
先结构后界面：“先用表格把字段定下来，再谈配色和图表。”

你看，连表格公式都不用会，全程就是给 AI 布置任务、再验收结果。

五、收藏这张「动手前自查清单」

截图存下来，动手写任何东西前扫一遍：

✅	动手前自查
1	我先砍掉"可有可无"的功能了吗？（MVP 思维）
2	我把"要记什么"翻译成数据表了吗？（先名词后动词）
3	我先要骨架、再要界面了吗？（结构优先）
4	每一次，我都亲自验收了吗？（最重要的一条）

收尾

一句话：想清楚数据，界面就是水到渠成的事。

这套思路拿到 Excel 台账、拿到自动化流程上，一样好使。说白了就一句话：先想"记什么"（数据，也就是功能的内核），再想"怎么好看"（界面，也就是美化）。

下篇聊：数据想好了，存本地还是存云上？怎么"秒开还不丢"？