WorkBuddy 打工人自救指南 · 第 10 篇

回想今年 2 月，我第一次 Vibe Coding 一个小型签证管理系统，从需求到上线花了四五天。

那时候，我这个一直没怎么碰过代码的人，已经兴奋得不行。现在再回头看，当时还在不停和 AI 对话，解决各种代码、环境、部署和系统对接问题。

才过去几个月，感觉像过了好几年。

话不多说，直接进入正题。

这篇主要讲两件事：

1. 围观一下 Codex 指挥 WorkBuddy 写系统的全过程
2. 聊聊这次 Vibe Coding 踩到的坑，以及下次我会提前想清楚什么

01

先把需求告诉 Codex

我这次还是按SCQA来拆解需求：

S｜背景

团队里的专家会同时支持不同项目，需要算清楚每个项目实际投入了多少人力，以及对应的差旅成本。

C｜冲突

老板一问：

这个项目到底投入了多少人？
有多少成本应该结算给业务部门？

答不上来。

Q｜问题

怎么把团队在不同项目上的投入真正看清楚？

A｜解法

那就 Vibe Coding 一个系统。

支持：

• 工时填写
• 差旅记录
• 项目管理
• 按人 / 项目 / 时间维度汇总
• 团队投入分析

于是我把需求告诉 Codex。

流程变成：

我提需求 → Codex 拆解 → 我确认 → Codex 调起 WorkBuddy Agent 应用模式开始开发。

02

Codex 去指挥 WorkBuddy

我当时给 Codex 的完整需求大概是这样：

 直接操作用户当前已打开的 WorkBuddy，创建一个“项目资源投入管理系统”。 需求： 1）项目管理：管理员可新增/编辑项目，含项目名称、编号、负责人、状态、开始/结束时间、备注；普通成员只能选择已有项目填报。 2）每日工时：一个人可支持多个项目；每条记录关联人员、日期、项目、工时占比；同一人同一天所有项目工时占比合计不得超过1；支持小数；已结束项目不能新增工时；禁止未来日期；支持补录过去日期；最好支持复制昨日；保留修改历史。 3）差旅：录入出差人员、关联项目、开始/结束日期、出发地、目的地、事由、交通方式、住宿天数、差旅总金额、备注、状态；差旅与工时分开记录，出差不自动等于1个工时。 4）个人视图：查看今日/本周/本月工时、未填日期、按项目投入、出差记录；当天不足1时提示剩余可分配工时。 5）汇总看板：支持按人、按项目、按日/周/月/自定义时间范围分析；统计总人天、项目投入、人员负载、项目参与人数、TOP投入人员、出差人天、差旅金额、城市分布；筛选条件联动。 6）权限：管理员看全局并维护项目；普通员工只能维护自己的工时和差旅。7）实现重点：业务规则必须真正生效，不只是前端提示，尤其是“同一人同一天工时总和<=1”；人员与项目是多对多；项目结束保留历史但不能继续录新工时；关键修改要有审计记录。先让 WorkBuddy 生成第一版应用，然后实际检查页面、流程和关键规则；发现问题就继续在 WorkBuddy 里迭代修正。不要只停留在需求描述。

这里之所以用 Codex 去操作 WorkBuddy，主要就是想验证一下 Codex 对电脑应用的感知和操控能力。

直接在 WorkBuddy 里做，当然也可以。

实际跑下来，Codex 能看到 WorkBuddy 当前的开发进展，继续操作，后面还会拉起浏览器做测试和验收。

这个能力确实在线。

比较遗憾的是，第一个版本刚出来没多久，Codex 就因为额度不足，被迫下线了。

不过第一版已经比我预期完整很多。

而且下面展示的，就是当时录屏里的原始版本，没有后期美化。

03

做着做着，我发现前期规划不足，做了几个关键变更

第一版完成后，我自己开始测试。

先发现了一些体验问题。

比如：

• 提示信息位置不够显眼
• 报表 KPI 卡片大小不一致

这些都属于小改。

很快真正影响系统结构的问题出来了。

1. 差旅单少了一个关键字段：出差单号

这个看起来只是加一个字段。

实际改起来，涉及：

• 数据库
• 后端接口
• 前端页面
• 关联逻辑
• README

这次大概 17 分钟修完。

这里得夸一下 Hy4 Preview。

夜间免费，而且这种跨前后端的修改做得还挺稳。

2. 没有角色、权限和数据隔离

这个就不是小问题了，对于正式系统是重大遗漏。

如果只是 Demo，可以先不管。

但如果真要内部使用：

谁能看谁的数据？
谁能维护项目？
谁能看全局看板？
谁能管理用户？

这些必须有明确的规则。

3. 鉴权也没接

后面又对接了企业内部统一身份。

对于内部系统，切记：

不要自己再造一套身份系统。

内部系统如果不接统一身份，后面用户、权限、组织信息都会越来越麻烦。

4. 还得考虑长期维护

做到这里，我已经不想把它当成一次性 Demo 了。

所以继续补：

代码管理 → 流水线 → 环境 → 部署

这套链路。

到这里，它才开始算是一个真正能继续维护的内部系统。

以上这部分又花了我周六早上大概两个小时。

04

这个系统后续怎么优化？

截至现在，系统基本已经可用。

后面的体验问题，就等真实用户反馈再继续改。

比较重要的是：

代码管理 → 流水线 → 环境 → 部署

已经跑通。

所以之后用户提需求，我只需要继续和 WorkBuddy 交互就能快速响应。

比如很快就有人反馈：

“这个工时只能一天一天加吗？”

那就继续发给 WorkBuddy 和 Hy4。

改。

测。

推上线。

初步看来，一天迭代几个小版本，应该也没什么压力。

这里说的“上线”，指的是部署到内网环境，不是只在本地跑。

这点差别很大。

05

Vibe Coding 下次要注意的坑

系统最后跑起来了。

整体过程其实还算顺，但还是有几个坑值得记下来。

1. 需求没想清楚，后面的改动会越来越贵

最典型的两个例子：

• 差旅表单漏了“出差单号”
• 人员、角色、权限一开始没有想完整

前面几个页面都做完了，才发现没有完整的用户和角色管理。

这时候再补，数据库、接口、登录态、数据权限都要一起改。

小功能可以。但下面这些最好早点想：

• 身份
• 权限
• 数据结构
• 关键业务规则

2. Demo能跑，不代表能顺利上线

系统从本地走到正式环境时，基建不好的公司，开发人员可能遇到很多问题。

环境：应该部署在哪里？内网还是外网？机器需要多少，怎么申请？

域名：怎么申请？如何路由到服务器IP？

数据：数据存储在哪里，SQLite表格够不够用？要不要单独数据库实例。

鉴权：和公司员工账号系统怎么互通，如何获取身份信息？切记重复造轮子，尤其是内部使用的系统，不和统一登陆打通等于自废一臂。

3. 要尽早搭起一个能持续迭代的pipeline

一个系统上线，不是结束。后面一定会不断循环：

使用 → 发现问题 → 出方案 → 开发 → 发布 → 验证 → 再使用

如果这条链路没搭好，前面开发得再快，也很难长期稳定迭代。

当然，这次系统做得很快，所以还有很多工程化工作没补全。

比如：

• 没有完整区分测试、灰度、正式环境
• 运维可观测还不够
• 指标体系还没设计
• 数据备份和恢复也可以继续加强

这些都是后面要补的。

写在最后

这次完整过程大概是：

我基本没碰代码。

最后真的跑起来了一个：

的小系统。

但这次最大的感受：

需求从提出到上线的循环，真的被AI加速了。

以前软件开发离很多产品经理还挺远。现在你已经可以直接下场。

需求有没有想清楚，反而开始变得更重要。

如果你们团队的软件开发流程，到现在还完全没有因为 AI 做任何变化，我觉得确实可以停下来重新想一下了。

都看到这里了，如果这篇内容对你有一点启发，欢迎顺手点个赞、在看，或者分享给身边可能需要的人。
也可以给我点个星标⭐，这样下次更新就更容易第一时间找到我。
感谢阅读，我们下篇见～

《别再陪 AI 聊天了：WorkBuddy 打工人自救指南》

 【09】WorkBuddy 、豆包工作、千问办公 上演“三国杀”，我让 WorkBuddy 自动盯住这场智能体办公大战

【08】每天上班先翻邮件、看日历、查项目？这活我让 WorkBuddy 先干了

【07】人都出门了，老板突然让我改 PPT，我怎么让 WorkBuddy 把活接了？

【06】这套活我都教 AI 三遍了，为什么第四遍还要重新说？我开始用 WorkBuddy Skill

【05】会开完了，谁答应干什么来着？我让 WorkBuddy 从会议纪要一路跟到任务执行！

【04】WorkBuddy Excel 数据分析实战：老板问“销售额为什么掉了”，我差点让 AI 分析错了

【03】老板下午要 PPT？ 这次我没让 WorkBuddy 先做 PPT

【02】周五又要憋周报？我让 WorkBuddy 去腾讯会议、TAPD 和腾讯文档里自己找

关键词