不会设计也能做 App:我用 Codex + Stitch 做出了「岁时」原型

大家好，我是十月七。

最近我想做一款倒数日 App。

原因很简单：市面上的倒数日工具不少，但有些广告太多，有些功能越做越重，还有些对农历和桌面小组件的支持并不好。

我想要的东西其实很克制：打开就能看到重要日子，支持农历，数据保存在本地，桌面上能放一个安静耐看的小组件。

产品名我也想好了，叫「岁时」。

问题随之而来。我会描述需求，却不擅长设计一整套 App 界面。直接让 Codex 写代码，又很容易得到一个“功能能跑，界面像作业”的版本。

这次我没有急着写代码，而是让 Codex 先陪我把产品想清楚。等 design.md 成形后，我才打开 Google Stitch。现在原型已经有了，接下来轮到 Codex 把这些页面变成真正能运行的 App。

整个流程可以概括成：

这篇先分享前半段：我怎样从一句模糊的想法，得到一套可以继续开发的 App 原型。

现在让 AI 创建一个 App 并不难。

你可以直接对 Codex 说：“帮我做一个倒数日 App。”它很快就能搭项目、写页面、补交互。

但“能生成”与“你想要”之间，往往隔着一大段没有说清楚的东西。

我当时最纠结的是产品气质。它究竟是一款严肃的效率工具，还是更偏情侣纪念？首页应该让日期醒目，还是让剩余天数压住全场？

“新中式”也很容易翻车。月白和留白算新中式，水墨、印章和祥云同样可以被模型理解成新中式，但做出来完全是两款 App。

这些问题没有答案，AI 只能自己猜。

所以，Codex 接到的第一项任务不是建工程，是陪我把产品想清楚。

我先给 Codex 描述了产品方向，并明确告诉它：暂时不要开发，先输出一份供 Stitch 使用的设计文档。

你也可以参考下面这段提示词：

Codex 最终生成了一份三千多字的 design.md。

文档里有一条要求让我印象很深：天数必须是页面的视觉主角。

顺着这条要求，很多细节就有了答案。创建事件不能像填写报表，朱砂红也不能铺满页面。桌面小组件更麻烦，它得像一个可以长期放在手机上的系统组件，而不是一张只适合截图的营销卡片。

设计文档还定义了一组颜色：月白、米白、墨黑、竹青、黛蓝、朱砂和浅金。每个颜色都有用途，Stitch 不需要临场猜测。

我觉得这一步很值。

它像是在正式装修前，先把户型、动线和材料表确定下来。后面即使换设计工具或换模型，这份文档仍然可以继续使用。

接下来进入 Google Stitch。

我把 design.md 最后一部分整理好的英文提示词交给 Stitch，让它一次生成 5 个主要页面：

1. 首页2. 创建事件页3. 事件详情页4. 桌面小组件页5. 设置页

下面是这一轮生成完成后的 Stitch 全局工作台。左侧是 Codex 整理的设计文档，中间是 Stitch 提炼出的颜色、字体和组件规范，右侧依次排列详情、首页、设置、创建事件和小组件页面；下方则是为卡片和小组件生成的背景素材。

从这张全图能更直观地看到，Stitch 生成的并非一张孤立的效果图。文档、设计系统、页面和素材都被放在同一个画布上，后续调整某个页面时，可以随时对照整体风格。

这里有个小经验：不要只告诉 Stitch“做一个新中式倒数日 App”。

“新中式”“高级”“简洁”都很主观。提示词里最好同时写清楚颜色、页面结构、示例数据，以及明确禁止的内容。

例如我在提示词里专门写了：

如果没有这句话，模型很容易把“中国审美”理解成古风海报。

几轮生成之后，首页已经比较接近我想要的气质。

页面上能直接看到公历和农历日期，分类包括学习、纪念、工作和生活。倒数天数是卡片里最醒目的信息，小组件也被放在底部主导航中，没有藏进设置菜单。

这说明前面的设计约束确实起作用了。

第一轮原型出来以后，我改成按页面逐个调整，不再追加一大段综合提示词。

首页重点检查信息层级；详情页检查日期、分类、提醒和操作按钮；小组件页重点看不同尺寸放到真实桌面后是否还能读清楚。

详情页最后形成了下面这种结构：

小组件页则生成了素笺、月相、竹青等不同方向：

设置页也遵守了“本地优先”的定位，没有凭空加入登录、会员或订阅入口。

除了完整页面，Stitch 还生成了一组可以直接用于事件卡片和桌面小组件的背景 Card。

第一张是偏素笺风格的米白卡片。浅金刻度、朱砂圆点和极淡的日轮只负责烘托时间感，文字放上去仍然是主角。

第二张使用竹影和一条朱砂竖线，适合生日、节气或生活类事件。

第三张是黛蓝月相。它可以用在深色小组件、纪念日或已经发生的事件上。

还有更轻的远山版本。它保留了东方审美，但没有直接堆水墨笔触，放置大数字时也不会显得拥挤。

檐影版本更有日期与节气的仪式感，适合中秋、春节等特殊事件。

最后一张以竹青渐变和同心刻度表现时间流动，可以用于学习、工作或长期目标。

这些 Card 并不只是文章配图。后续让 Codex 开发 App 时，它们会作为实际视觉资产进入项目，同时帮助 Codex理解不同主题应该怎样搭配文字颜色、留白和信息层级。

这种逐页修改的好处是，每次只解决一个问题。

如果同时要求它调整配色、导航、卡片层级、字体和文案，模型很可能修好一处，又把另一处改乱。

原型确认后，我把 Stitch 的结果下载到了本地。

除了 screen.png，文件夹里还有两类很有价值的内容。

第一类是 DESIGN.md。

它记录了 Stitch 实际采用的颜色 Token、字体、字号、圆角和间距。例如 moon-white 对应 #F7F3EA，页面边距是 20px，卡片间距是 16px。

第二类是 code.html。

部分页面可以导出 Tailwind HTML。它不是 Android 原生代码，却保留了页面结构、颜色配置、图标和排版关系。下一步让 Codex 实现 Jetpack Compose 页面时，这些代码可以作为参考，而不必只靠截图猜尺寸。

这一次，交给 Codex 的是一整套设计上下文：

对 AI 开发来说，上下文越完整，反复解释和返工通常就越少。

高保真原型离可以提交应用商店的 App，还有不少距离。

这次最明显的一次翻车，是创建事件页导出的截图几乎全白，只能回到 Stitch 工作台查看，幸好 HTML 还在。

其他页面也没有整齐到可以直接交付。顶部留白不完全一致，有些字号看起来像来自两套系统。导出的 HTML 依赖 Tailwind 和在线字体，对 Android 开发来说只能当参考。

更大的工作都还在后面：保存按钮现在只是一个按钮，日期不会计算，数据也没有落到本地。农历换算、提醒和桌面小组件，还得老老实实写原生能力。

这些问题反而提醒我：原型的任务是确定产品和视觉方向，工程实现仍然需要验证。

Stitch 负责让想法变得可见，Codex 接下来要负责让它真的工作。

下一步，我会把整个 Stitch 导出目录交给 Codex，并要求它先读取两份设计文档、页面截图和 HTML，再创建 Android 工程。

第一版 MVP 不会贪多。我准备先让首页和创建页跑起来，用 Jetpack Compose 还原视觉，再把事件存进本地数据库。只要新增一条日期后，首页能正确显示“还有多少日”，这个 App 就算第一次有了心跳。

详情页和设置页随后补上，同时处理“已经 X 日”和“就是今日”这两个状态。每完成一个页面，我都会在 Android 模拟器里打开它，和 Stitch 原型放在一起对照。颜色、圆角和字体偏了多少，截图最诚实。

农历、通知提醒和桌面小组件会根据实现复杂度逐步加入。尤其是小组件，我希望它最后真的能长期放在桌面上使用，静态效果图还远远不够。

等 MVP 跑起来后，我会把项目结构、关键提示词、Codex 修改过程、踩过的坑和最终效果整理成下篇。

写在最后

这次我忍住了“一句话生成 App”的冲动。代码晚写了一点，但产品第一次在我眼前有了具体模样：它该安静到什么程度，首页应该先看见什么，哪些装饰多一点就会跑偏。

Codex 和 Stitch 的分工也在这个过程中慢慢清楚了。一个帮我整理想法、接手工程，另一个把那些还说不明白的视觉偏好摊在画布上。它们之间的 design.md、截图和设计 Token，才是这次真正留下来的东西。

目前「岁时」仍然是一套原型。它有好看的页面，也有一些明显没完成的地方。下一篇能不能把这套设计真正装进 Android 手机，我也很期待。

你想一想：如果 Codex 和 Stitch 可以帮你完成产品文档、界面设计和代码实现，你最想做一款什么 App？

欢迎在评论区告诉我。如果你也期待「岁时」的开发实战，记得点个赞、在看，也可以把这篇转发给那个一直说“我有个 App 想法”的朋友。