面试追踪

需求背景

近期在求职，我需要维护一个Excel来记录我投递了哪些岗位，但是这个有的时候很麻烦，所以我想要开发一个记录我自己岗位投递的APP（本质上这个软件仍然是一个“记账”软件）。

UI设计

本次需求最开始使用的是Pi + Deepseek V4 Flash，选择这个组合的原因很简单————穷（因为Deepseek V4 Flash配合Pi的缓存命中率高，而且Deepseek V4 Flash本来就比较便宜）。但是，Deepseek V4 Flash的审美有点一言难尽。

所以后面切到了Kimi K3 + Claude Code进行UI设计，不得不说，Kimi K3的审美比Deepseek V4 Flash要高出一大截。

我只问了下面的一个问题：

...
另外,我希望设计要充满高级感(例如, 苹果味十足)

然后Kimi-K3给出了下面的几种设计风格（配合ui-ux-pro-max来设计的）：

### ① Apple 人文风（Human Interface）
**气质**：克制、友好、润物细无声
- 大量留白、大标题、毛玻璃、弹簧动效
- 颜色只用作"语义"（绿=通过，橙=待办），绝不装饰
- **参考**：Apple 自带 App、Things 3

### ② 暗夜奢华（Dark Luxe）
**气质**：专业、锋利、有"金融终端"的贵气
- 深炭黑底 + 发丝级细分隔线（hairline），信息悬浮在暗色空间里
- 单一点缀色（一抹香槟金或荧光绿）贯穿全局，用得极省
- 衬线/等宽字体混排，数字用表格等宽体，像 Bloomberg 终端
- **参考**：Linear、Revolut、高端仪表盘

### ③ 瑞士编排风（Swiss / Editorial）
**气质**：理性、建筑感、像一本高级杂志
- 黑白为主 + 一个高饱和功能色（国际橙红），强网格、巨大号字体做层级
- 不用卡片和阴影，靠**字重和留白**分区，分割线细如刀锋
- **参考**：Vercel、Kinfolk 杂志、无印良品海报

### ④ 暖白侘寂（Warm Minimal）
**气质**：安静、温润、文具感
- 米白/宣纸色底（不是纯白），墨色文字，陶土色点缀
- 衬线体标题 + 极淡的纸纹理，圆角更小、更"方"，像一本 Moleskine
- **参考**：MUJI、Notion 早期、日式手账

基于此，Kimi K3生成了UI交互原型，我选了一下，最终决定用瑞士编排风然后把背景颜色调成了宣纸的颜色。

Kimi K3 生成的UI设计稿和Deepseek V4 Flash生成的效果对比如下：

从原型到产品

UI 定稿之后，我并没有一步到位想清楚要做什么形态，而是边做边调整，前后换了三次：

最开始想做一个 App。 把投递、笔试、面试、HR 面、OC 这些环节做成一条时间线。做到一半发现，我一个还没上线的东西，让别人装个 App 来试用，门槛实在太高。

于是先做了一个 Web 版。 把 App 里那套逻辑原样搬过来，写成一个零构建、零依赖的纯 HTML/JS 页面，数据存在浏览器本地。这样别人点开链接就能玩，不用装任何东西。现在这个版本还留着，你看到的在线体验就是它。

最后又迁到了微信小程序。 想来想去，国内大家最习惯的还是小程序——不用下载、不用记网址，扫一下或者搜一下就进去了。所以又用原生小程序重写了一遍，目前是主力版本，正在备案中。

三端的逻辑是同一套：投递流程的「领域层」（状态怎么流转、时间怎么算、城市时区怎么对应）写成纯函数，RN、Web、小程序各自移植一遍，UI 各自实现。这样改一处业务规则，三端照着同一份逻辑对齐就行。

这次 Vibe Coding 的几点总结

整个项目我一行代码都没写，全是和 Agent 一遍遍聊出来的。回头看，有三件事我觉得特别重要。

1. 设计先行，别急着实现

我最深的体会是：不要一上来就让它写代码。第一步是先把需求想清楚——这个过程可以慢慢和 Agent 磨，尽可能地把所有需求点都讨论出来，一个角落都别放过。奇妙的是，等这一步做完，整个 App 其实已经在我脑海里成形了，后面做的只是把它「搬」出来而已。需求聊透了，就把每个细节都定下来，形成一份 PRD——也就是把所有功能点都列清楚、定死。

PRD 定下来之后，再去做 UI。这里我强烈建议用 ui-ux-pro-max 这个 skill，让它做一个把所有交互都实现的单个 HTML 原型。为什么强调「交互都实现」？因为 PRD 是文字，很多需求细节你光看文字是想不到的，只有真的落到页面上、能点了，才会发现「原来这里我没想清楚」。它和 PRD 是互补的。

举几个我们这个项目里的真实例子：

• 环节的状态到底谁来定？ 一开始我设想的是手动标记「待面试/待结果」。但做原型时点来点去发现很别扭——时间到了它不就是待结果了吗？最后改成状态完全由时间驱动：没填时间就是「未安排」，时间在未来是「待面试」，时间一过自动变「待结果」。手动能设置的只有最终的「通过/未通过」。这个规则是看文字很难想到的，是拖着一个真原型才试出来的。
• OC 要不要填一堆字段？ 原型里我给 OC（发 offer 了）也配了时间、地点、形式一堆输入框，点的时候才发现根本多余——OC 就是终点啊。最后定成「OC 即终态」，添加 OC 就等于已录用，一个字段都不用填。
• 改判一个已经走过的环节怎么办？ 比如我前面已经「通过」了笔试、进到面试了，结果 HR 告诉我笔试其实挂了。这时候后面那些环节还留着吗？原型里点了才发现必须处理，最后定的是：历史环节改判「未通过」，会弹窗提示并级联删掉它后面的所有环节，而且所有删除都能撤销。

这些规则，如果当时直接让 Agent 写代码，多半就稀里糊涂做进去了，等发现不对再改，成本比在原型阶段想清楚高得多。

2. 一定要有一个 AGENTS.md，并且逼它记变更

开发阶段我给项目根目录放了一个 AGENTS.md，里面写清了各种规矩。这次我觉得最值的一条，是要求它把每一个变更都记进 CHANGELOG.md：

## Changelog

ALWAYS REMEMBER: record every change in the top-level CHANGELOG.md.
Every code, configuration, asset, or documentation change must update
CHANGELOG.md (in this directory, not inside any sub-repo) in the same change set.

- Add the newest entry at the top of CHANGELOG.md.
- Use the actual date of the change.
- Describe concrete user-facing or engineering changes; avoid vague entries
  such as "optimization".
- Deferred cross-end syncs are also recorded there as pending items (with the
  ends still to be synced), so they are not lost.
- Documentation-only and maintenance changes must also be recorded.

为什么这么较真？因为 Vibe Coding 的时候，你自己是不过代码的，Agent 改了你也不知道它到底动了什么。几天下来，没有这份 CHANGELOG，我根本说不清项目现在是什么状态、哪个功能做到哪了。有了它，我每次回来翻一眼就知道昨天干了啥、哪些多端同步还欠着。最后那条「欠着的同步也记成待办」特别管用——三端开发经常是小程序先改了，RN 和 Web 还没跟上，不记下来转头就忘了。

3. 可以不懂技术细节，但一定要懂技术选型

有了 PRD 之后，真正写代码的过程，我的体会是：具体怎么实现可以不用懂，但用什么技术做，一定要自己拍板。

说实话，这一步是我一个程序员朋友帮我把关的。他不会替我抠每一行代码，但每次我要做个技术决定，他会告诉我这么选的后果是什么。比如后端最后没用微信云开发、改成自建服务器，就是他提醒我云开发后期迁移麻烦、而且我想留着以后迁到别的平台的余地。这种判断，光靠 Agent 是拿不准的，因为它不知道你的长期打算。

所以我的结论是：Vibe Coding 不会写代码没关系，但需求要想清楚（PRD）、交互要落实（原型）、变更要留痕（CHANGELOG）、选型要有人懂（技术决策）。这四件事抓住了，剩下交给 Agent 就好。