一个产品经理的第一次 Vibe Coding
2024年6月18日，我儿子出生了！综合考虑之后，我们决定请一位育儿嫂协助带娃。随后，一个非常具体的问题出现了：怎样更清楚、更省心地给育儿嫂发工资？
而「薪算」的起源最早也不是一个完整的产品计划，没有什么MRD和BRD，完全就是希望能够处理好这个非常具体的生活问题。育儿嫂这个行业常见的一种工资计算方式是：
育儿嫂一周工作6天，休息1天（或者工作X天休息Y天）
法定节假日工作则N倍工资，休息则N-1倍工资
每工作满26天，结算一次工资
一开始我觉得这件事很简单：阿姨工作满 26 天，我转一次钱就行。无非是确认起止日期，扣除休息日，再处理一下节假日工资。
但真正执行起来并不是这样。前几个月，几乎每次都是阿姨先提醒我：“已经满 26 天了，该发工资了。”然后我再回头打开日历，重新核对日期。
这种感觉让我很不舒服。一方面，我对整个周期没有掌控感；另一方面，阿姨刚到家里的几个月，双方还没有完全建立信任。她提醒之后，我不能马上回复，而是要先核算一遍。换位思考，她可能也会觉得我不够信任她。
除了我自己要算清楚什么时候该发工资，这件事落到家庭生活里，也不只是我一个人算明白就行。很多时候，发薪信息还需要同步给家里人。所以后面干脆就拉了个微信群，正好也偶尔要在群里和阿姨同步一些事项，并且在转账的时候也会把开始工作时间和结束的工作时间放在转账说明中，以便于下次计算日期的时候好确认开始日期。
不过，这些做法都有一个前提：我已经准确确认阿姨工作满了 26 天。偏偏对我来说，最麻烦的就是算清楚这 26 天：
周期从哪天到哪天？
中间休了哪几天？
有没有节假日？
节假日上班了还是休息了？
法定节假日是几天？
所以问题不只是“能不能算出一个数字”，而是能不能把这个数字背后的周期、考勤和调整说明白。
从微信群、Excel 到 AI，再到小程序
在真正做小程序之前，我经历过一轮很自然的工具演进。
最开始的方式就是开头提到的微信群记录加手动数日子。阿姨会在群里说“这个周期到了”，或者我们简单确认一下“从哪天到哪天，一共多少天”。我再打开日历数一遍，中间休息了几天、是不是刚好满 26 天、发薪日有没有提前或延后。
后来我尝试用 Excel 表格，把起止日期、休息日、工资金额这些信息结构化记录下来。表格确实比聊天记录清楚，但它也带来了新的维护成本：每次都要打开表格、更新日期、检查公式，还要确认表格里的规则是不是和这次实际情况一致。
再后来，我开始用豆包来帮我算。我会告诉它开始时间、结束时间、中间哪几天休息，让它帮我判断阿姨提出的发薪时间是否匹配。之后我还专门建了一个固定对话框，把周期工资、默认休息日、节假日规则这些关键信息都告诉它。
除了直接用文字告诉豆包哪天工作、哪天休息，我后来还尝试过另一种方式：在日历上直接标注。我的想法是，既然工资计算的核心是考勤，那把一个月的日历截图出来，在上面标清楚哪几天工作、哪几天休息，再交给豆包识别，理论上会比我用文字逐个描述更直观。
但实际效果并不稳定。
豆包对图片里标注信息的识别并不总是准确。有时会漏掉某一天，有时会把工作日和休息日理解反，有时会因为截图里跨月、周几排列或标注方式不同，导致日期对应关系出错。即使它识别出了大部分日期，后续在套用工资规则时也仍然可能出现偏差。这类错误比纯文字计算更难发现。因为我还要先判断它有没有正确理解图片，再判断它有没有正确计算金额。原本是想减少输入成本，结果反而多了一层校对工作。
固定规则不难，临时调整才麻烦
最开始我以为，只要知道起止日期和周期天数，事情就差不多能算清楚。但实际执行的时候却发现，真正麻烦的不是固定规则，而是现实情况总在变化，如果没有一个好的方式记录下这个变化，后续再追溯就会很痛苦。
比如节假日前后，家里可能会安排外出。原本阿姨应该休息的周末，可能会因为我们还在家、需要照看孩子，就和她商量继续工作；到了真正节假日那几天，因为我们全家外出，她反而可以休息。还有一次，孩子打麻腮风疫苗后发烧。那段时间我们也比较忙，阿姨就连续多工作了几天。等孩子状态稳定、阿姨也方便休息时，再把休息日补回来。原本可能是周六周日只休一天，后来就变成某几天连续工作，再集中休息一两天。
这种情况很常见，几乎每个周期都会有一些非常规的变化，这些变化其实不是规则彻底变了，而是每个周期里都会出现一些小调整：原本该休息的日子变成工作，原本该工作的日子变成休息。
问题也就出在这里！！！
如果只是一个固定排班，不管是用脑子记，还是用计算器、Excel 或 AI，都不算太难。但一旦每个月都有临时调换，真正考验的就不是计算能力，而是记忆力。我要记得哪几天是临时上班，哪几天是补休，哪些调整已经和阿姨沟通过，哪些只是我自己脑子里还没记录下来。
而我的记忆力显然不适合承担这个任务。
后来我意识到，我需要的不是月底再算一次，而是平时就把每一次临时调整记下来。只要每天的工作和休息状态是明确的，结算时就不需要再从微信群、Excel、AI 对话和记忆里拼凑上下文。
比较了一下App、网页和微信小程序等不同形态的开发成本、使用门槛和使用频率，最后决定借助 AI 做一个微信小程序，「薪算」也就这样诞生了。
功能不复杂，问题倒不少
真正开始 Vibe Coding 后，我发现麻烦的不只是功能实现。很多问题来自产品细节，也有一些来自我和 AI 的协作方式。虽然它只是一个看起来并不复杂的薪资计算工具，但作为一个几乎没有技术背景的代码小白，我在和 Codex 协作的过程中还是遇到了不少意料之外的问题。
问题一：改 A 时，B 也被顺手改了
这是我遇到最频繁的问题之一。
我很多时候只是想改一个很小的地方，比如把首页里的“发薪提醒”放到更下方，或者把订阅按钮放到最右侧并调整大小。但实际改动过程中，页面其他区域的布局也可能被一起影响。
还有一次，我只想修改“工作 / 休息”切换状态的样式，其他保持不变。但实际效果仍然需要反复校正，因为这个控件和日历区域、日期说明、底部操作区都有关系，稍微动一下就可能影响整体观感。
这类问题对 AI 来说可能是“顺手优化”，但对我来说就是偏离需求。因为我并不具备阅读代码实现方式的能力，所以在这个过程中我的诉求很明确：只改指定部分，其他保持不变。
解决方式：把边界写进全局规则。
后来我把这条规则写进项目的全局说明里：修改内容时，只修改我指定的部分，其他保持不变。这样每次后续开发时，AI 都会先看到这条约束。
问题二：日历展示反复推翻
决定做小程序后，我最先遇到的问题不是工资公式，而是日历怎么展示。
因为这个工具的核心并不是一个输入框，也不是一个计算按钮，而是“每天到底是工作还是休息”。如果日历不好用，整个产品就不成立。
我尝试过很多版（真的很多很多很多版，而且会很容易陷入到这个好看，那个也很精致的泥沼中出不来）
一开始想把每天做成更明显的状态块，但手机屏幕上一个月有三十天，每个格子都很小，信息稍微多一点就会挤。后来尝试只用颜色区分工作和休息，又担心用户看不出当前选中的是哪一天。再后来加入绿色点和灰色点，分别表示工作和休息，同时用蓝色突出当前选择日期。
工作/休息切换按钮的样式也改过好几轮。它看起来只是一个小开关，但实际上承担了“修改考勤”的核心动作。样式不清楚，用户就不知道自己是在查看日历，还是已经改了某一天的状态。
解决方式：让日历只承担最核心的信息。
最后我选择了相对克制的方案：日历主体保持干净，只用绿点和灰点来区分工作/休息状态；选中日期和今天用更明确的视觉状态；底部放当天的工作/休息切换。它不是最花哨的方案，但更适合反复使用，既能直观看出阿姨在当前周期内的出勤情况，也可以直接调整某一天的工作或休息状态。
问题三：节假日规则很难一次说清
另一个反复最多的问题是节假日。普通工作日和普通休息日其实很好算，真正让事情复杂起来的是法定节假日。
节假日休息，要不要发工资？
节假日上班，是单倍、双倍还是三倍？
节假日刚好落在默认休息日，该按休息处理还是按节假日处理？
双方约定和常规理解不同，产品应该怎么表达？
这些问题不是单纯的技术问题，而是规则表达问题。
解决方式：不替用户判断唯一标准，而是提供可选口径。
我和实际使用场景反复确认了很多轮，最后没有试图把所有细节都塞进产品，而是把它抽象成几个可选择的口径：休息时如何处理，上班时按几倍工资补偿。
这样用户可以按照双方真实约定设置，而不是被产品强行带到某个单一规则里。工具要做的是记录和计算，而不是替用户判断所有关系。严格地说，这并不是 AI 带来的问题，而是产品本身的规则没有被提前想清楚。但在 AI 协作开发中，这类模糊会被进一步放大：只要需求方没有明确口径，AI 就很容易按照自己的理解继续发散。
问题四：AI 完成后的测试不够全面
还有一个逐渐暴露的问题是测试不够全面。
AI 完成一个功能后，通常会做一些基础检查，但它未必会覆盖完整用户路径。比如某个页面单独看没问题，但从首页进入、再跳转到结算、再保存历史、再返回日历，就可能出现状态不一致。
也有些问题只有在真实设备或微信开发者工具里才能明显看出来，比如按钮位置、页面加载速度、返回行为、截图生成效果。
解决方式：每个版本先生成测试用例，再按用例验证。
所以到后面我开始调整开发方式：每开发一个版本，不只是让 AI 写代码，还会先生成一份更详细的测试用例。
测试用例会覆盖关键路径，比如新增档案、修改考勤、切换工作/休息、进入结算、确认发薪、查看历史、生成图片、删除记录、返回首页等。然后再基于这份测试用例让它逐项验证。
问题五：很容易陷入无休止的优化
还有一个问题不完全来自 AI，而是来自我自己。
开发过程中很容易进入一种状态：看到这个地方好像还能再优化一下，那个页面也还能再调整一下。日历样式可以再改，按钮大小可以再调，页面跳转可以再顺一点，发薪记录可以再完整一点，生成图片可以再好看一点。
每一个想法单独看都合理，但加在一起，就会让开发变成一个没有终点的过程。
有几次其实不是我主动判断“这一版已经够了”，而是 Codex 的额度快耗尽了，才被迫停下来。这个结果虽然客观上帮我结束了一轮迭代，但它不是一种理想的项目管理方式。
如果一个产品只能靠额度耗尽来停止优化，说明我对版本边界还不够清楚。
解决方式：回到主线，按版本规划控制范围。
后来我开始更明确地按版本拆分能力。比如这一版只解决发薪前确认、考勤标记、发薪明细图片和快照结构；下一版再考虑历史详情、每日考勤明细、公式展示；再往后才是发薪提醒和订阅消息。这样做的好处是，每次开发都有一个明确的停止点。不是因为“已经没有额度了”，而是因为“这一版该解决的问题已经解决了”。
完成当前版本设定的问题后，我就不再继续发散。除非遇到真正阻断使用的问题，否则不再“顺手优化”。开发过程中发现的其他小问题统一记录下来，积累到一定数量后，再放进一个明确的版本中集中处理。
现在它变成了什么
现在的「薪算」仍然是一个很小的工具，优先满足我自己的使用需求。
它的核心逻辑是：先保存家政服务人员的工资规则，再用日历记录每天工作或休息，根据用户设置提前发送发薪提醒，到发薪时根据周期、考勤、节假日和临时调整计算金额，最后保存完整发薪记录，支持图片分享。
目前它包含的主要能力有：
- 工资规则设置：人员档案、周期工资、周期天数、计薪模式、默认休息日和节假日口径；
- 日常考勤记录：通过首页日历记录每天工作或休息，并查看当前周期统计和累计薪资；
- 发薪结算：支持发薪前明细确认，以及奖励、预支、扣减等手动调整；
- 发薪留痕：保存历史记录和详情，生成发薪明细图片，并支持发薪提醒订阅。
关于后续规划
目前我暂时不打算继续高频迭代「薪算」。
它最初就是为了解决我自己的发薪问题，而现在的功能已经基本满足我的个人使用：记录规则、标记考勤、核对结算、保存历史、生成明细图片，这个闭环已经够用。所以短期内，我不会为了让它看起来更完整而继续堆功能。除非后续真的有较多人使用，或者收到一些我认为有建设性、也符合产品边界的建议，我才会考虑继续迭代。
我的收获
Vibe Coding 首先帮我解决了一个真实存在的问题，简单、直接，也确实已经用到了日常生活中。更重要的是，作为一个除了 SQL 之外几乎没有完整写过代码的人，我第一次完整体验了用 AI 辅助开发产品的全过程。
以前看 AI 编程，更多像是在看一种趋势：大家都在讨论它会不会改变开发方式、会不会提高效率、会不会替代某些工作，但是因为没有设身处地的参与，体感还是不够强烈。但真正自己拿一个生活里的问题去做，感受会完全不同。我开始更清楚它擅长什么、容易在哪些地方出问题，什么时候可以快速推进，什么时候必须由人来补充上下文、明确边界并作出判断。
从这个角度看，「薪算」对我来说不只是一个发薪工具。它更像是一次完整练习：我用一个真实、足够小、又能马上验证的问题，学习怎样向 AI 讲清需求、限制修改边界、验证完整流程，并在适当的时候停止优化。
这个小程序未必会成为一个很大的产品，但它已经让我有信心继续做下一个。
如果你家里也有类似的家政发薪场景，可以在微信里搜索「薪算」试试。
