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

做小程序别急着写代码、画界面。先想清楚要记什么数据、砍掉多余功能、让 AI 搭骨架,界面自然水到渠成。

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

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

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

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


一、先砍功能:MVP 不是偷懒,是清醒

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

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

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

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

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


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

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

落成三张结构(这是 utils/defaultData.js 里真实的定义):

1
2
3
4
// 记录项类型:名称、单位、范围、步长,都在一处统一定义
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 越准。模糊的需求,只会养出模糊的产物。


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

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

还是那几步:

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

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


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

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

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

收尾

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

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

下篇聊:数据想好了,存本地还是存云上?怎么"秒开还不丢"?

希望所有努力的人都能找到并提升自己的核心价值
使用 Hugo 构建
主题 StackJimmy 设计