不懂代码，如何做出UI被夸“真好看”的小程序？

不懂代码，花了半个月做出一个小程序，圈友私信我说：

开心之余，纠结要不要将整个过程分享出来，毕竟我还没有通过小程序赚到钱，但转念一想：

在生财让我受益最多的帖子，往往不是“我赚了 100 万”的捷报，而是圈友提供的“我从 0 到 1 是怎么趟过来”的路线图。现在我刚好有这样一张图在手上，分享出去说不定能帮到一些人。

所以，这篇帖子不聊赚钱（因为还没赚到），就聊两件事：一个技术小白，怎么把想法变成好看的产品、以及中间踩了哪些坑。如果你也想过“自己做个东西”，但被技术吓住了，这篇或许能给你破个冰。

这次分享，适合两类人：

1. 1. 脑子里有想法，但总卡在“我不会技术”这一步的圈友。 我会完整展示，一个技术小白如何借助 AI 工具，把点子从脑子搬到手机上的全流程。
2. 2. 做过点东西，但总觉得“丑”、拿不出手的伙伴。 我会重点拆解，怎么靠有限的审美和工具，让 UI 被夸“好看”。这里面的方法，跟写代码关系不大。

至于老手，这篇文章的技术深度肯定不够看。但如果你对“一个小白怎么用AI工具快速搞出像样产品”这个过程感兴趣，或许也能带来一点不一样的视角。

接下来，我会从三个部分展开，这也是我摸索的真实路径：

1. 1. 需求从哪里“冒”出来的？ （不是拍脑袋，是我自己的真实痛点）
2. 2. 从想法到产品，我走了哪几步？ （展示我的开发流水线）
3. 3. 回头再看，哪些坑本可以跳过？ （我的拍大腿时刻，你的避坑指南）

本次分享的小程序名称，叫「运动罐」，一个极简的运动打卡小程序。

建议先用微信扫码（下面的小程序码），或者在微信搜索「运动罐」体验后再阅读，可能更有感觉。

OK，正文开始。

1. 需求从哪里“冒”出来的？

答案是：从自己身上。

起因是2024年我骑摩托不小心扭到腰，问了几个医生都说没事，但腰时不时会酸痛，很折磨人。没办法只能自己研究解决。

我分析是柔韧性问题，把筋拉顺就会好。找了很多拉伸动作尝试，最后选中古法健身操里边的“上下齐发”。每天做一两组，每次几分钟，前面几个月没什么感觉，持续做了三百多天，奇迹发生：腰完全好了！

这个过程我突然明白——运动这件事，跟存钱一样。每天存一点，看着不起眼，但身体账户里的健康在慢慢变多，直到某一天突然发现：自己变富了。

当时运动时我想找个App记录，但找不到。市面上的App都太复杂、太臃肿了，好像它们都不觉得几个拉伸动作、几个俯卧撑、几分钟平板支撑值得被记录，但我觉得值得。

这个就是我做这个小程序的初衷，用简单的方式记录运动，见证自己日积月累的健康财富。那么，问题来了：这是个真需求吗？

按照往常做法，需要去小红书、抖音调研，看看是不是真的有需求，能不能通过满足这个需求赚到钱。

但我没有。因为我问了自己一个问题：如果做出来只给自己用，一年成本300元（微信小程序认证+云服务），我能接受吗？

答案是可以。

因为我确实有做小运动的习惯，做完会在微信群里打卡（见下图），确实想要有个好的工具可以记录，可能这对其他人不算真需求，对我来说是。

除此之外，我想用这个需求练手，学会AI编程。即便做出来没人用，但我因此掌握了AI编程，也是值得的，便开始研究。

2. 从想法到产品，我走了哪几步？

用了想法，开始进入实现阶段。我在生财看到的大多数分享，主要有两种实现方法：一个是跟AI聊透需求，然后让AI直接生成；一个是把竞品的页面截图发给AI，让AI模仿生成。

第一个方法我尝试过，有个问题，AI无法保证页面的整体风格，如果涉及到多页面，想让它统一修改，很难，很容易改得面目全非；第二个方法则是适合纯前端页面的简单功能，也只适合页面数量少的产品。

我想要实现的，是有一整套完整设计风格的。所以我觉得还是按照产品开发的流程乖乖走一遍会比较好，即：

发现需求->分析需求->写需求文档->出设计图->开发。

这样子做有个好处：每个步骤独立可控，不会乱，做不来的东西大概率就是我想要的，就是比较繁琐。

但繁琐归繁琐，能够实现才是最重要的，开始尝试。

2.1 跟Claude把需求聊透

一开始是跟Gemini聊，但感觉质量不高，看到别人分享，都说用Claude聊需求最好，试试。

在Claude网页上可以免费使用Sonnet 4.5模型，足够用，把我一开始的想法发给它：

提示词
Plain Text
我想要做一款微信小程序，用来记录我每天的运动情况，想法是类似于像存钱罐一样，每天运动一点点，然后就记录下来，日积月累。

目前想到的产品名称是“身财”，传达存运动量罐让身体变富的概念。

目前我的需求是下面4点，你帮我看看具体该怎么设计产品（记住是微信小程序）

1、每天运动了，就打开记录一下，记录的操作可能是：
「2026年2月1日23:29 记录 上下齐发：60下 马步摇：60下 俯卧撑：20个」
「2026年2月3日23:29 记录 上下齐发：60下 马步摇：60下 羽毛球：34分钟」
「2026年2月4日23:29 记录 上下齐发：60下 跑步：34分钟5公里」
一天可能有多次记录，比如“2026年2月5日18:00 记录 跑步：34分钟5公里” “2026年2月5日23:29 记录 上下齐发：60下 马步摇：60下 俯卧撑：20个”

2、可以看到今天的运动情况

3、可以看往年今日的运动情况

4、要有汇总，比如一周/一个月/一年运动了多少天，做了哪些运动，比如上下启发1200下、马步摇1200、俯卧撑3000个、羽毛球180分钟、跑步120分钟15公里

我一开始想的小程序名字是“身财”，想要强调身体就是最大的财富，但在做的过程觉得不好，容易跟“身材”“生财”混淆，解释成本太高，后面跟Claude聊，才改成“运动罐”。

所以说，产品开发的过程，很多细节都是边做边调整的，不用太在意，重点是逻辑、架构不要出错。

Claude理解后给出一份详细文档，包括产品架构设计、详细的功能设计、核心技术方案等等，部分内容见下图。

这些截图内容只是为了还原我的开发过程，可以不用细看，重点看思路和流程。

乍看之下很全面，但里边有很多逻辑没有细化，不能大意被骗了。

每个产品都有自己的核心逻辑，一定要聊细，越细、越清楚越好。因为我们的思考能力有限，一开始没办法想得太全面，所以可以在描述完需求之后加上一句：“可能还会有我没考虑到的情况，你仔细分析后帮我给了一个可行的详细方案”，AI就会帮我们考虑得很全面。

然后我们根据AI的回答，在里边做选择题和判断题就会轻松很多。

比如基于它的回答，我提出问题：

提示词
Plain Text

没想到Claude一顿输出，甩了一大堆代码给我，看不懂。

所以必须要求它：

提示词
Plain Text
你先不要写代码，先跟我聊需求，聊产品设计方案，等我们确定了再写方案也不迟

这一句话很重要，很多时候AI编程会出错，问题就在于需求聊不清楚就让AI开发，写出来的代码就很容易有问题。

用这个话要求Claude之后，它会认真思考方案，同时还会跟你确认功能，比如：

根据Claude的方案和提问，写出自己的思考、判断。

如果自己拿不准哪种方案更好，就问它：“从用户角度分析，你觉得哪一种更好，为什么？或者说有没有更好的方案。”

我经常跟Claude写小作文，比如：

这样子跟Claude详细讨论完，感觉很完善了，就让它输出一份完整详细的产品需求文档，看看哪里还需要调整。

我们在跟AI讨论的过程中，有时候看起来它理解我们的意思了，但实际上并没有，让它总结出文档，一切以“白纸黑字”为据最好。

提示词
Plain Text
你先输出一份完整详细的产品需求文档给我，我再看看哪里还需要调整

果然，Claude给出的需求文档有很多逻辑需要优化，我把里边不合理的地方一一指出来，又写了一篇小作文。

下面截图是我根据需求文档给的修改意见。

这样子跟它聊下来，我们就得到一份完整、详细的需求文档。但对于技术小白来说，还有一个问题：文档里边给出的数据结构设计是代码，我看不懂，该怎么判断是不是合理的？

也就是说，这里的逻辑是AI觉得完整、详细了，但里边可能藏着我不知道的坑，所以我让Claude把代码变成文字，这样才能理解逻辑有没有问题。

提示词
Plain Text
你帮我重新生成一份完整的需求文档，从数据结构设计开始，里边的代码部分全部替换成文字逻辑表述，不然我看不懂

得到：

这时候就好理解多了，但里边有很多术语看不懂，怎么办？

继续求助AI，新开一个对话，把这个数据结构设计发给它，让它教我：

提示词
Plain Text
将下面的数据结构设计内容详细拆解，教我理解，要专业，也要容易理解：
【数据结构设计内容】

基于AI给出的解释，提出自己的需求，问它怎么改？提示词格式是“在…里边，我想要…，我该怎么改？”

比如：

提示词
Plain Text
在记录类型定义里边，我想要的是用户在创建运动项目时就已经确定好「可选单位」，比如俯卧撑属于“类型1：按次数”，在创建时设置单位为“个”，在创建时就默认“个”；在“类型2：按时长”里边单位只有一个“分钟”；在“类型3：按时长 + 距离”里边，单位只有“分钟+公里”，我该怎么改？

根据它的建议改完之后如果自己还不确定，继续问它：

提示词
Plain Text
我改成下面这个样子可以吗？有没有其他没考虑到的？
【数据结构设计内容】

这样子跟它持续讨论，最后就能得到一份自己能够理解的完整、详细的数据结构设计，也就可以进入设计、开发了。

接下来我们进入第二步：做出一整套好看、统一风格的UI设计图。

2.2 用Stitch出设计图

用Claude聊需求有个好处，它默认会用ASCII画出页面布局。这样子我们能直观看到页面内容是不是我们想要的，确定之后给Stitch参考，画出来的图不会跑偏。

这里的 ASCII 是指：用普通键盘上的字符（横线、竖线、加号、字母、数字）拼出来的纯文本框线图。

即：不用图片、不用画图软件，只用文字和符号画界面。

除此之外，需求文档里边还有一张图很重要：产品结构图。

它能够确定每个页面有什么内容，结合ASCII图发给Stitch，就能得到好看、有用的UI图。

一开始我把需求发给Stitch，没有给产品结构图和ASCII图，让它自由发挥，出来的几个版本一般，页面功能都不是自己想要的。

给它圈定好产品结构图和首页的ASCII线框图后，告诉它要做什么产品，想要什么风格，就能够得到想要的效果：

提示词
Plain Text
我想要设计一个运动打卡的小程序，核心哲学是不追求痛苦的爆发，只追求持续的累积。像存钱一样记录运动，让健康成为看得见的资产。下面是我的产品结构图，你能不能基于这个结构图帮我设计页面，要符合我的定位，最好是简约、干净且具有极佳排版美学的风格
【首页的ASCII线框图】
【产品结构图】

当它输出这三个页面时，我被惊艳到了，虽然配色不统一，但里边的元素和功能都对上了，风格也是我想要的。

如果你刚才有体验一下「运动罐」的话，会发现这个设计跟实际上有不少区别。

很正常，因为现在你看到的页面是我在这些页面的基础上一点点迭代出来的。

比如我觉得现在首页的颜色不符合产品定位，就跟Stitch提要求：

提示词
Plain Text
页面的品牌色需要跟【身财统计】【项目管理】的统一，你评估一下，【身财统计】【项目管理】的绿色会不会更好，更有活力一些？

比如我想要一个首页内容为空的页面，继续提要求：

提示词
Plain Text
生成一个今日运动内容为空，往年今日内容为空的页面给我看看长什么样

比如我想要一个记录运动的页面，继续提需求：

提示词
Plain Text
基于这个配色（即首页的配色），我想要一张【记录运动】的操作页面看看

想要什么页面，想要页面怎么布局，跟Stitch聊，它是免费使用的，不用怕限额。

一开始使用Stitch，我还担心需要用很专业的术语才能让它做出好看的设计图，发现根本不用，用日常的对话就好，像我上面这几个对话一样。

这个过程最重要的就是耐心，因为每张页面都需要自己评估、调整、确定，「运动罐」这个小程序只有15个页面，但我一共做了下面这么多图，可以看看。

总之，这个过程就是慢慢做，慢慢调整，做出满意的作品。

步骤讲完了，是不是很简单？这个方法也是我尝试把需求发给它，不断调整提示词，摸索了两天后得出来的。

在做的过程中，我感觉就是回归一个核心的原则：你给AI越多参考、越多条件，得到的东西越接近你想要的。

如果你用AI觉得不得劲，可以基于这个原则思考一下，会有惊喜。

现在需求文档有了，设计图也有了，那么该怎么让AI把两者结合起来，一比一还原实现呢？这是真正难的地方，半个月时间，我至少有一半时间在研究这个，最后误打误撞捣弄出来了。

2.3 让Codex写代码实现

这次我选择让Codex帮我写代码，原因很简单，它当时送了我一个月的试用期。

而且大家都说它的架构能力最强，写代码强，就是速度慢。使用下来，这也是我的真实体感。

具体该怎么让Codex实现呢？我第一次用也不清楚，所以从最笨的提问开始：

提示词
Plain Text
我想要开发一个运动打卡记录的微信小程序，我该怎么让你帮我快速、完整的实现？

基于Codex给的回答，继续聊：

提示词
Plain Text
在我们没聊清楚需求之前，切记一定不要写代码。
1、技术方案：我不懂，是微信小程序，你建议用什么？我的目的是要性能最好、维护最方便的
2、关于产品功能的，我需要写一份详细的产品需求文档以及设计好UI页面给你吗？

这时候就可以把产品概述、产品结构图、数据结构设计发给它，让它了解需求：

提示词
Plain Text
我初步想好了产品概述、功能架构和数据结构设计，见下面，不知道有没有遗漏差的地方。其实也用Stitch把页面基本都设计好了，不过每个页面的逻辑还没有写
【一、产品概述 二、产品结构图 三、数据结构设计】

没想到基于产品结构图和数据结构设计，Codex给我指出了10个问题，而且说能够将这10个问题变成“可确认选项”给我做选择题。不得不说，Codex的代码能力是真的强：

让它把这10个问题变成“可确认选项”的同时，我问它怎么将Stitch的设计图发给它，让它实现：

提示词
Plain Text
可以啊，你先把以上 10 条变成“可确认选项”给我逐条拍板。

对了，是不是拍板好了我们继续做文档定稿，定稿了之后我再把Stitch设计的UI页面截图发给你，或者是把每个页面的代码发给你？如果是发代码，这些页面的代码估计跟微信小程序的不一样，估计需要你识别出里边的样式帮我转换成适配微信小程序的代码了

根据它提出的这两点，把所有页面“截图+页面说明+页面代码”发给它。

• • 页面说明：即每一页有什么内容，展示逻辑、交互方式是什么，这部分在Claude写的需求文档就有。Claude输出的需求文档，每个页面都会用ASCII展现，同时详细说明页面的每个部分，很详细。
• • 页面代码：Stitch设计出来的页面，自带代码，可以查看、复制，这个打开Stitch用一下就知道了。

全部发好后，跟Codex讨论定稿，输出开发清单，这样子AI有了约束，才不会天马行空。

同时为了不让“讨论需求”和“开发实现”的窗口混在一起，导致内容庞杂，容易出错，可以在Codex新开一个对话，让它用来写代码。

具体对话流程是：

1、最终PRD（需求文档）定稿

提示词
Plain Text
你仔细确定好还有没有问题需要我确认，没有的话整合成一版“最终PRD定稿清单”给我

2、Codex整合好之后，告诉我可以进入下一步，整理成“可执行开发清单（页面任务+数据层+接口层+验收用例）”，但我发现一个问题，它给的这份需求文档没有涉及到UI说明，所以继续追问：

提示词
Plain Text
这份PRD定稿清单没有体现出我的UI页面，是不是可执行开发清单（页面任务+数据层+接口层+验收用例）就有体现？如果我想要让公司里的工程师开发，实现我的需求逻辑和UI界面以及交互，我该怎么做？

这里说的“让公司里的工程师开发”，其实就是新开对话让Codex开发。

3、Codex说它整合的需求文档只涉及到业务，没有UI，还让我冻结一版UI，我不懂，继续问，问它能不能基于我前面发的所有页面“截图+页面说明+页面代码”生成：

提示词
Plain Text
冻结一版UI，这个该怎么做，我不懂。就我分享给你的逻辑以及页面代码，你能不能帮我生成的？还是说我需要提供什么东西

4、感觉它说的没毛病，同意它的方案：

提示词
Plain Text
全部按推荐。

如果我要让工程师开发，是不是把所有文件发给他就好。从专业的角度看，你觉得合并成一个文件，还是分开多个文件？基于你的建议能不能在文件夹帮我创建对应的文件，我倒是让工程师直接读取文件里边的内容开发，你看这样子可以吗

5、到这里很完整了，可以新开对话让Codex开发，但怎么要求呢？我不懂，继续问它：

提示词
Plain Text
我现在要让工程师读取docs文件夹开发，我该怎么跟他说？是需要让他先分析再执行吗

6、根据Codex的建议，开始新开对话开始写代码，写了二十多分钟，兴奋得直搓手，没想到一打开，被泼了一盆冷水，做出来的UI惨不忍睹。

左边是设计图，右边是实现出来的效果图。

首页设计图

存入运动页实现效果图

完整体验下来，整个小程序的功能都实现了（侧面说明前期需求文档准备得越充分，实现的功能效果越好），但UI除了颜色对了，其他没有一丁点跟设计图一样，很绝望，该怎么办？

我深呼吸，心平气和问Codex：

提示词
Plain Text
我在微信开发者工具编辑了小程序，发现实现的UI界面跟我发给你的基本不一样，为什么会这样？

Codex给出的答案看起来挺有道理，继续追问：

代码块
Plain Text
你给我一份“逐页UI差异清单（按优先级）”，让工程师照单改

提示词
Plain Text
你能不能在文件里更新这些修改点，对应将我截图的页面更新，让工程师直接根据这份清单和截图页面实现测试？

提示词
Plain Text
你给我一个清晰命令，我直接告诉工程师

好了，看它输出得这么专业，估计这次可以了。结果一出来，想打人的心有了。

这次我语气有些冲，直接问：

提示词
Plain Text
现在小程序实现的UI跟我想要的差太远了，你还记得我之前发给你的页面UI设计吗？如实回答我。我如果想要像素级还原每个页面，该怎么做？

Codex给了回答，说要Stitch/Figma源文件，要每个页面元素的详细设计说明，这些我不懂，但我隐约觉得不对：Stitch设计的页面自带代码，代码已经把效果做出来了，是最好的设计说明。只要把这些代码转换成小程序语言就可以，为什么还要多此一举？

所以我没有管它，我觉得问题可能出在我的指挥上。可能是前面一次性将所有页面截图+代码发给它，内容太多，Codex混乱了？

我开始尝试：

1. 1. 单个页面截图，让Codex像素级还原，有偏差。
2. 2. 发单个页面的代码，让Codex像素级还原，有偏差。
3. 3. 发单个页面的截图+页面代码，让Codex像素级还原，有偏差。

有些没辙了。

都说Gemini的设计在线，我把Stitch的代码发给它，尝试跟它学习专业的UI描述，让Codex改：

提示词
Plain Text
我如果想将下面这份代码发给微信小程序工程师，让他用微信小程序的语言将页面实现我这份代码的UI效果，我该怎么跟他说？
【页面代码】

有点效果，但不多。

我指挥Codex根据设计图调整页面的每个元素，仅仅一个“存入运动页”就弄了我两三天时间（具体见下图），最后还是有不尽人意的地方，崩溃。问题到底出在哪？

我跟Codex聊、跟Claude聊、跟Gemini聊、跟ChatGPT聊，各种尝试，最后误打误撞了解到：

• • 一开始Codex输出的开发清单里边，默认写了优先级：视觉与交互以《02_UI冻结清单_V1.md》为准。
• • 所以我每次截图+复制页面代码让Codex优化UI，都会受到它的影响，没办法像素级还原。

功夫不负有心人，终于破案了！

我调整了一下提示词发给Codex：

提示词
Plain Text
我现在需要优化「**页面」的UI，图片是设计图，下面是HTML的参考代码，你帮我像素级实现成设计图的样子，可以做到吗？有*点需要注意：
1、只实现浅色模式（因为Stitch给的代码默认有暗黑模式，需要明确）
2、HTML的参考代码中的字体大小需换算成微信小程序的尺寸（HTML的字体大小单位跟小程序不一样，需要明确）
3、本轮页面UI优化以我最新截图+该页HTML参考代码为第一优先级；02_UI冻结清单_V1.md 仅作历史参考，不作为本轮阻断标准。
【HTML参考代码】
【截图】

这样子基本每次都能一次性像素级还原设计图，有时候只需要做一点点小调整。

至此，一个好看、好用的小程序就做出来了！

最后一步上架小程序，让Antigravity帮忙填写资料，不仅快，还很有效。

2.4 让Antigravity填写资料

第一次上架小程序，提交代码审核需要填写很多资料，我不懂，秉承着万事用AI的原则，我选择用Antigravity。

Antigravity里边的Gemini模型虽然写代码不怎么样，但它能够读取整个代码库的逻辑，知道怎么准确填写内容，更容易通过审核，所以把需要填的内容通通截图问它就好。

通过这样的方法，我今天提交审核，明天就过审可以发布了，很快。

到了这里，整个小程序开发就完成了。这一套流程其实无论用在开发小程序，还是App、Web上，都成立，因为开发流程都是通用的。

最后再给大家讲讲几个坑。

因为我第一次开发小程序，还是这种涉及到前后端数据处理的，有几个坑前期没意识到，导致后面代码重构，写下来给大家提个醒。

3. 回头再看，哪些坑本可以跳过？

3.1 数据处理决定系统架构。

一开始讨论需求的时候没有跟AI明确要多端（比如手机、平板、电脑）同步数据，AI默认将数据存储在微信本地里边，导致了一个问题：同一个微信号在不同设备上的数据各自独立，比如一个微信号在手机上、平板上各自存在两份数据，对于一个运动打卡小程序来说，明显不合理。

我一开始没意识到这个问题，等到准备上架发布时才发现，花了两天时间重构了底层的系统架构。

为什么会这么晚发现？

因为我一开始不知道用微信扫码登录微信开发者工具进行开发、测试，再用同一个微信扫码预览体验小程序，其实是同一个微信号，所以在测试的时候觉得两套数据很正常。后面在数据库里看到其中是同一个微信用户，才知道出问题了。

不同的数据处理决定了系统架构不同的设计方式。我跟ChatGPT聊了之后，意识到更成熟的开发顺序，其实是：

• ◦ 数据存在多久？
• ◦ 是否多端？
• ◦ 是否允许覆盖？
• ◦ 是否允许丢失？
• ◦ 强一致
• ◦ 最终一致
• ◦ 本地优先 + 云备份
• ◦ 而不是一开始就纠结技术选型。

前两个步骤明确之后，就能知道架构应该怎么设计了。不懂问AI就好。

3.2 小程序静默登录

微信小程序是支持无感微信身份登录的，即：用户不用先看到“登录页/授权弹窗”，打开就能用；系统在后台用微信账号唯一标识（openid）识别用户并存云端数据。

典型场景是：

1. 1. 首次进入小程序，直接开始使用，不被登录流程打断。
2. 2. 同一微信号下次再来，数据自动还是自己的。
3. 3. 换手机但还是同一微信号，历史记录可恢复。
4. 4. 切换到另一个微信号，会看到另一套独立数据。

这样子有个好处：用户体验门槛很低，同时可以避免游客的数据丢失和后续可能进行数据合并的复杂度。

一开始我不知道，设计了一套登录流程，让用户在某些条件下触发登录弹窗登录。当时做得可开心了，但很明显，这不是一个好方案。据统计，每一个多余的点按都会导致约 20% – 40% 的用户流失。静默登录能够将流失率降到了最低。

我也是上线之后才发现了这一点，只能重构登录逻辑。需要注意的是，静默登录后显示的默认头像和昵称要设计一下，具备专业性，不要让人觉得是冷冰冰的“未登录用户”。

3.3 环境隔离

因为我使用的是微信的云开发，默认只有一个环境，所以测试环境和正式环境是同一个。一开始我不知道，在测试时疯狂造数据，等到上线后打开小程序想正常使用，傻眼了。

所以涉及到后端的，可以另外创建一个测试环境，这样子后续开发迭代更改代码，不会影响到正式环境。不过两个云环境就需要两份钱，如果不需要的话，可以用另一个手机小号测试，确保正式使用的手机数据不会脏乱。

4. 总结

写到这里就结束。整个过程下来，如果你问我，用AI做产品最大的体会是什么？

我觉得就两个字：明确。

你给AI的要求越明确，越容易得到自己想要的效果。特别是在代码里边，一切都是讲究规则的，比如一个小小的排序功能，背后有很多种实现逻辑，不同逻辑对应不同的数据更新规则，有不同的问题。你只有明确了心里才有底，不然的话AI会偷懒、会坑你。

但一开始我们都是新手，做不到明确，怎么办？可以运用小时候学到的一个道理：不懂就问，或者说不耻下问。

跟AI聊天有一个天大的好处，就是不用怕不好意思。很多时候我们不敢问问题是因为怕自己问的问题太小、太傻了，担心别人会怎么看我们。跟AI聊天就完全没有这个顾虑，鸡毛蒜皮的小事都可以问，不用怕丢脸。

之前看过一句话：很多产品都值得用设计重做一遍。

我很认可，也因为圈友夸的那一句，我花了3天时间复盘了这篇内容，算是把自己的那点AI技能掏空了。希望对大家有帮助。

最后祝愿大家都能做出自己满意的产品，我要去研究怎么赚到钱了。