工时和差旅管理这件事放在任何一家有规模的公司里都是个谁提谁头疼的活儿。业务部门嫌流程繁琐财务部门嫌票据混乱管理层想看个实时数据得等月底报表。市面上成熟的SaaS产品不少但要么按人头收费贵得离谱要么字段和审批流跟自家制度对不上改起来还得求着厂商排期。我这次干脆换了个思路不写代码或者说几乎不手写代码让 Codex 当技术总监指挥 WorkBuddy 和 HY4 两个 AI Agent 分工干活从一句需求描述到系统上线前后不到两小时。这篇文章就把整个过程拆开讲清楚——不是炫技而是把Vibe Coding 到底怎么落地到一个真实业务系统这件事说明白包括我踩过的坑、Agent 之间怎么分工、哪些环节必须人工兜底。1. 为什么工时差旅系统值得用 AI Agent 重做一遍1.1 传统做法的三个死结先说清楚痛点不然容易变成为了用 AI 而用 AI。工时和差旅管理系统的本质是表单 审批流 统计报表三件套听起来简单但真正落地时会撞上三堵墙。第一堵墙是字段和规则的强定制性。每家公司对工时的定义都不一样有的按项目维度拆分有的按任务维度有的还要求区分可计费工时和内部工时差旅更是五花八门差旅标准按职级、城市、出差天数浮动补贴算法能写满一页纸。通用 SaaS 产品为了兼容所有客户字段设计得极其臃肿实际用起来 80% 的字段是废的。第二堵墙是审批流的动态性。今天老板说超过 3 天的出差要总监审批明天又改成跨部门项目要项目经理会签。这种规则变更在传统开发里意味着改代码、测试、发版周期以周计。而业务方的耐心是以天计的。第三堵墙是数据孤岛。工时数据在 A 系统差旅报销在 B 系统项目成本核算在 Excel 里三者对不上账是常态。财务月底对账时那种数据打架的场面做过的人都懂。1.2 AI Agent 切入的合理性在哪我判断一个场景适不适合用 AI Agent 来做看三个指标规则是否可描述、结构是否相对固定、变更是否频繁。工时差旅系统恰好三条全中。规则可描述意味着我可以用自然语言把业务逻辑讲清楚Agent 能理解结构相对固定意味着数据模型不会天天推倒重来CRUD 加审批流的骨架是稳定的变更频繁意味着传统开发的改一次发一次版成本太高而 Agent 驱动的系统可以做到改需求即改系统。这里要区分一个概念Vibe Coding 不是随便说说 AI 就帮你写完。它的真实含义是你用接近自然语言的方式表达意图AI 负责把意图翻译成可运行的代码和配置你负责把关方向、验证结果、处理边界。人的角色从写代码的人变成定义问题的人 验收的人。这个转变听起来轻松实际上对需求描述的清晰度要求更高了——你描述得含糊Agent 就给你造一堆看起来能用、实际全是坑的东西。1.3 三个角色的分工逻辑这次我用到的三个工具角色定位完全不同这也是整个方案能跑通的关键。Codex 是技术总监。它不直接干最脏最累的活而是负责理解整体需求、拆解任务、决定技术选型、协调另外两个 Agent 的工作顺序。你可以把它理解成一个经验丰富但没时间亲自写代码的架构师它的价值在于决策和调度。WorkBuddy 是全栈执行者。它擅长把具体的功能模块落地成可运行的东西包括前端页面、后端接口、数据存储。我让它负责工时填报、差旅申请、审批流这些核心业务模块。HY4 是数据与集成专员。它更偏向数据处理、报表生成、外部系统对接这类活儿。统计看板、数据导出、跟现有系统的数据同步交给它。提示这三个角色的划分不是固定的你可以根据手头工具的能力特点重新分配。核心原则是让每个 Agent 干它最擅长的那类活而不是让一个 Agent 从头包到尾。2. 开工前的环境准备与需求拆解2.1 把一句话需求拆成可执行的任务清单我最初给 Codex 的输入只有一句话做一个工时和差旅管理系统支持员工填报、主管审批、财务统计。这句话对人来说信息量太少对 Agent 来说更是没法直接执行。所以第一步是需求拆解这一步必须由人来主导不能全甩给 AI。我按角色 - 动作 - 数据三个维度把需求展开角色核心动作涉及数据员工填报工时、提交差旅申请、上传票据项目、任务、工时数、出差地点、日期、金额主管审批工时、审批差旅、退回修改审批状态、审批意见、审批时间财务查看统计、导出报表、核对补贴汇总工时、差旅费用、补贴金额管理员配置项目、配置差旅标准、管理用户项目字典、职级标准、城市系数这张表看起来平平无奇但它是整个项目的宪法。后面所有 Agent 生成的内容都要能对应回这张表里的某一行。如果某个功能点在这张表里找不到归属要么是需求漏了要么是多余功能两种情况都要处理。2.2 技术选型的取舍为什么不用重型框架Codex 在拆解完需求后给出的第一个建议是技术选型。这里有个反直觉的点AI Agent 驱动的项目反而应该选轻量、约定优于配置的技术栈。原因很简单。Agent 生成代码时依赖越少、约定越明确出错的概率越低。如果你选一个需要大量手写配置、各种注解满天飞的框架Agent 很容易在配置细节上翻车而且排查起来极其痛苦。我最终定的方案是前端单页应用组件化状态管理用最朴素的方案不引入复杂的状态库后端轻量 Web 框架路由和业务逻辑分离清晰数据存储关系型数据库表结构显式定义不用 ORM 的自动迁移部署单机可跑容器化打包不搞复杂的编排这套选型的核心逻辑是可预测性优先。Agent 生成的每一部分我都能快速看懂、快速验证。如果用了重型框架光是理解 Agent 生成的配置就要花掉大量时间得不偿失。2.3 给 Agent 定规则这一步决定了后续效率热词里有一条给 workbuddy 定几条规则后续对所有任务都生效这条我深有体会。在正式开工前一定要给每个 Agent 设定全局规则否则它会按自己的默认习惯来生成的东西风格不统一后期整合时你会想砸键盘。我给 WorkBuddy 定的规则大致是这几条所有接口统一返回结构包含状态码、消息、数据三个字段所有时间字段统一用 ISO 格式时区固定所有金额字段用整数存储以分为单位避免浮点误差所有列表接口必须支持分页默认每页 20 条所有写操作必须记录操作人和操作时间给 HY4 定的规则偏向数据侧统计口径必须显式声明不允许出现默认口径导出文件统一用 CSV编码固定所有聚合查询必须能追溯到明细数据这些规则看起来琐碎但它们的作用是把隐性约定变成显性约束。Agent 不需要猜我也不需要事后返工。实测下来定规则这一步花 15 分钟能省下后面至少一小时的扯皮时间。3. Codex 如何指挥两个 Agent 协同干活3.1 任务编排谁先谁后谁依赖谁三个 Agent 协同最怕的是互相等或者互相踩。Codex 在这里的核心价值就是编排任务顺序和依赖关系。我的实际执行顺序是这样的Codex 先出数据模型。因为工时和差旅的所有功能都建立在数据模型之上模型不定后面全是空中楼阁。WorkBuddy 基于数据模型做后端接口。接口是前后端的契约先定接口前端才好动手。WorkBuddy 再做前端页面。页面调用已经定好的接口联调成本最低。HY4 最后做统计和导出。因为统计依赖前面产生的真实数据放最后最合理。这个顺序不是拍脑袋定的而是遵循依赖倒置原则被依赖的东西先做依赖别人的东西后做。如果顺序反了比如先做前端页面那页面里的字段名、接口地址全是猜的等后端出来必然大改。3.2 数据模型整个系统的地基Codex 给出的数据模型我做了少量调整后定稿。核心表有这么几张用户表存基本信息、角色、职级、所属部门项目表存项目编号、名称、负责人、状态工时表存用户、项目、任务描述、工时数、日期、审批状态差旅申请表存用户、出差地点、起止日期、事由、预估费用、审批状态差旅明细表存关联的申请、费用类型、金额、票据信息审批记录表存关联单据、审批人、审批动作、意见、时间这里有个关键设计决策审批记录单独成表而不是在业务表里加几个状态字段。原因是审批可能有多级、可能被退回重提、可能中途加签用状态字段根本表达不了这种复杂度。单独成表后任何单据的完整审批链路都能查出来这对财务审计极其重要。注意数据模型阶段一定要人工仔细过一遍。Agent 生成的模型通常能用但不一定好用。比如它可能忘了加索引可能字段类型选得不合适可能漏了软删除标记。这些细节后期改起来成本很高前期花 20 分钟检查非常值。3.3 接口契约前后端不打架的关键WorkBuddy 生成后端接口时我要求它先输出接口文档再写实现。接口文档包含路径、方法、请求参数、响应结构、错误码。这份文档就是前后端的合同。举个工时填报接口的例子{ path: /api/timesheet, method: POST, request: { projectId: string, taskDesc: string, hours: number, workDate: string (ISO date) }, response: { code: 0, message: success, data: { id: string } } }有了这份契约前端页面生成时就不会瞎猜字段名联调时也不会出现前端传 a、后端收 b的低级错误。实测下来先定契约再写代码联调时间能压缩一半以上。3.4 审批流的实现状态机是绕不开的审批流是整个系统里逻辑最绕的部分。我一开始想让 Agent 自由发挥结果它生成了一堆 if-else 嵌套看得我头皮发麻。后来我明确要求用状态机的方式实现审批流。状态机的核心是把状态和转移条件分离当前状态触发动作目标状态条件待提交提交待审批必填项完整待审批通过已通过审批人有权限待审批退回已退回填写退回意见已退回重新提交待审批修改后重提已通过撤销已撤销未进入结算这样设计的好处是新增审批规则时只需要加一行配置不用改代码逻辑。比如老板突然说超过 3 天的差旅要总监审批我只需要在状态机里加一条转移规则几分钟搞定。这就是前面说的改需求即改系统的具体体现。4. 实测中踩到的坑与排查过程4.1 字段类型不一致导致的静默失败第一个坑出现在工时填报功能上线测试时。员工填了 8 小时工时提交后数据库里存的是 8但统计页面显示的是 0。排查了半天发现是前端传的是字符串 8后端按数字处理时没做转换直接存进去变成了字符串聚合查询时被当成 0 处理。这个问题最坑的地方在于它不报错。接口返回成功数据库也写进去了就是统计不对。我后来在 WorkBuddy 的规则里补了一条所有数值型字段在入库前必须显式转换类型转换失败要报错。这条规则加上后类似的静默失败再没出现过。排查这类问题的思路是从最终结果倒推数据流。统计显示 0先看聚合查询的 SQL再看数据库里的实际值再看接口收到的原始值一层层往回找很快就能定位。4.2 审批权限判断的边界情况第二个坑是权限。测试时发现一个普通员工居然能审批自己的工时。原因是权限判断只检查了是否有审批权限没检查是否是自己提交的单据。这类问题的本质是权限判断的维度不全。完整的权限判断至少要考虑三个维度谁在操作、操作什么、操作的对象属于谁。我后来把权限逻辑统一抽成一个函数所有审批入口都调用它避免每个接口各写一套。提示权限相关的逻辑千万不要让 Agent 分散在各个接口里实现。一定要抽成统一的中间件或函数否则迟早会出现某个接口漏判的情况。4.3 统计口径的歧义第三个坑最隐蔽。HY4 生成的工时统计报表我核对时发现跟手工算的对不上。查了半天发现是**工时的口径不一致**报表里统计的是所有状态的工时包括被退回和撤销的而业务上只应该统计已通过的工时。这个问题暴露了前面定规则时的一个疏漏——我要求了统计口径必须显式声明但没要求口径必须跟业务确认。后来我补了一条流程任何统计功能上线前必须拿真实数据跟业务方核对一遍。数字对不上功能就不算完成。4.4 Agent 生成代码的通用排查套路踩了这几个坑之后我总结出一套排查 Agent 生成代码的通用套路先看数据流再看控制流。Agent 生成的代码数据流出问题的概率远高于控制流。字段类型、空值处理、编码格式这三样是重灾区。边界值优先测。空值、零值、超大值、特殊字符这些边界情况 Agent 经常考虑不全。权限和状态相关的逻辑重点查。这两块逻辑分支多Agent 容易漏掉某些组合。统计类功能必须对账。任何涉及聚合、汇总的功能都要拿真实数据验证一遍。这套套路用下来排查效率比盲目看代码高得多。5. 从需求到上线的完整时间线复盘5.1 两小时是怎么分配的很多人好奇2 小时这个数字是怎么来的我把实际时间分配列出来阶段耗时主要工作需求拆解20 分钟人工梳理角色、动作、数据数据模型15 分钟Codex 生成 人工调整后端接口30 分钟WorkBuddy 生成 契约确认前端页面25 分钟WorkBuddy 生成 联调统计导出15 分钟HY4 生成 对账测试修复15 分钟边界测试 权限验证加起来正好两小时出头。但要说清楚这两小时是高度专注、需求明确、工具熟练的前提下。如果需求本身模糊光是跟业务方对齐就要花掉大半天。所以2 小时不是普遍规律而是一个理想状态下的参考值。5.2 哪些环节绝对不能省复盘下来有几个环节看起来可以省实际上绝对不能省需求拆解不能省。这是整个项目的地基地基歪了后面全歪。我见过太多人直接甩一句话给 AI然后抱怨生成的东西不能用。问题不在 AI在于需求本身就没想清楚。数据模型检查不能省。Agent 生成的模型通常能跑但细节经不起推敲。索引、类型、约束这些必须人工过一遍。权限和统计的验证不能省。这两块是业务系统的命门出错代价最大。宁可多花 10 分钟验证也不要上线后出问题。5.3 哪些环节可以大胆交给 Agent反过来有些环节可以放心交给 AgentCRUD 接口的生成。增删改查这种模式化的代码Agent 生成得又快又好人工写反而容易出错。前端页面的布局。表单、列表、详情页这些标准页面Agent 生成的完成度很高微调即可。数据导出的实现。CSV 导出、字段映射这类逻辑Agent 处理得很稳。基础校验逻辑。必填校验、格式校验、长度校验这些规则明确的东西交给 Agent 没问题。核心判断标准是规则明确、模式固定、出错代价低的活儿交给 Agent规则模糊、需要权衡、出错代价高的活儿人来把关。6. 这套打法能复用到哪些场景6.1 判断一个需求适不适合 Agent 驱动不是所有系统都适合用这套打法。我总结了一个简单的判断框架看四个维度业务规则能否用自然语言描述清楚能就适合不能先想清楚再说。数据模型是否相对稳定稳定就适合天天变先别急。是否有大量模式化的 CRUD有就适合全是复杂算法另说。变更是否频繁频繁Agent 驱动的优势越明显。工时差旅系统四条全中所以效果很好。反过来如果是那种核心逻辑是复杂数学计算、或者对性能有极致要求的系统Agent 驱动的收益就没那么大。6.2 类似的管理系统可以照搬按这个思路以下这些系统基本可以照搬这套打法请假管理系统跟工时差旅高度相似表单 审批 统计采购申请系统多了供应商和比价但骨架一样资产管理系统多了资产状态流转逻辑类似客户跟进系统表单 权限 报表套路一致内部工单系统分派 处理 统计结构相同这些系统的共同点是流程驱动 数据记录 统计呈现正好是 Agent 最擅长的领域。6.3 什么情况下要谨慎有两种情况我会特别谨慎。一种是涉及资金流转的系统比如支付、结算这类系统对准确性和安全性的要求极高Agent 生成的代码必须经过严格审计不能直接上线。另一种是涉及大量外部系统对接的系统因为外部系统的接口往往文档不全、行为诡异Agent 很难处理这种脏环境。这两种情况的共同点是容错空间小。Agent 生成的东西本质上是大概率正确但业务系统有时候要求必须正确。这种时候人的把关就不能省。7. 关于 Vibe Coding 的一点个人体会用这套打法做完工时差旅系统之后我最大的感受是Vibe Coding 的门槛不在工具而在把问题说清楚的能力。工具本身已经足够强了Codex 能理解复杂需求WorkBuddy 能生成可运行的代码HY4 能处理数据逻辑。但如果你自己都没想清楚要做什么工具再强也白搭。我见过太多人把 AI 当许愿池扔一句话进去就等着收成品结果当然是失望。真正有效的用法是你先想清楚 80%让 AI 补剩下的 20%然后你验收。想清楚的部分包括业务规则、数据模型、权限逻辑、验收标准让 AI 补的部分包括代码实现、页面布局、接口细节验收的部分包括边界测试、权限验证、数据对账。还有一个体会是规则要前置。前面花 15 分钟给 Agent 定规则后面能省下大量返工时间。规则定得越细Agent 的自由发挥空间越小但生成结果的稳定性越高。这个 trade-off 在业务系统开发里稳定性永远优先。最后说个实际的这套打法目前最适合的是内部工具类系统也就是给自己人用、不对外、容错空间相对大的系统。这类系统用传统方式做投入产出比很低用 Agent 驱动能快速见效。等这套流程跑熟了再往更复杂的场景延伸是比较稳妥的路径。
不写代码，2小时用AI Agent搭建工时差旅管理系统实战
工时和差旅管理这件事放在任何一家有规模的公司里都是个谁提谁头疼的活儿。业务部门嫌流程繁琐财务部门嫌票据混乱管理层想看个实时数据得等月底报表。市面上成熟的SaaS产品不少但要么按人头收费贵得离谱要么字段和审批流跟自家制度对不上改起来还得求着厂商排期。我这次干脆换了个思路不写代码或者说几乎不手写代码让 Codex 当技术总监指挥 WorkBuddy 和 HY4 两个 AI Agent 分工干活从一句需求描述到系统上线前后不到两小时。这篇文章就把整个过程拆开讲清楚——不是炫技而是把Vibe Coding 到底怎么落地到一个真实业务系统这件事说明白包括我踩过的坑、Agent 之间怎么分工、哪些环节必须人工兜底。1. 为什么工时差旅系统值得用 AI Agent 重做一遍1.1 传统做法的三个死结先说清楚痛点不然容易变成为了用 AI 而用 AI。工时和差旅管理系统的本质是表单 审批流 统计报表三件套听起来简单但真正落地时会撞上三堵墙。第一堵墙是字段和规则的强定制性。每家公司对工时的定义都不一样有的按项目维度拆分有的按任务维度有的还要求区分可计费工时和内部工时差旅更是五花八门差旅标准按职级、城市、出差天数浮动补贴算法能写满一页纸。通用 SaaS 产品为了兼容所有客户字段设计得极其臃肿实际用起来 80% 的字段是废的。第二堵墙是审批流的动态性。今天老板说超过 3 天的出差要总监审批明天又改成跨部门项目要项目经理会签。这种规则变更在传统开发里意味着改代码、测试、发版周期以周计。而业务方的耐心是以天计的。第三堵墙是数据孤岛。工时数据在 A 系统差旅报销在 B 系统项目成本核算在 Excel 里三者对不上账是常态。财务月底对账时那种数据打架的场面做过的人都懂。1.2 AI Agent 切入的合理性在哪我判断一个场景适不适合用 AI Agent 来做看三个指标规则是否可描述、结构是否相对固定、变更是否频繁。工时差旅系统恰好三条全中。规则可描述意味着我可以用自然语言把业务逻辑讲清楚Agent 能理解结构相对固定意味着数据模型不会天天推倒重来CRUD 加审批流的骨架是稳定的变更频繁意味着传统开发的改一次发一次版成本太高而 Agent 驱动的系统可以做到改需求即改系统。这里要区分一个概念Vibe Coding 不是随便说说 AI 就帮你写完。它的真实含义是你用接近自然语言的方式表达意图AI 负责把意图翻译成可运行的代码和配置你负责把关方向、验证结果、处理边界。人的角色从写代码的人变成定义问题的人 验收的人。这个转变听起来轻松实际上对需求描述的清晰度要求更高了——你描述得含糊Agent 就给你造一堆看起来能用、实际全是坑的东西。1.3 三个角色的分工逻辑这次我用到的三个工具角色定位完全不同这也是整个方案能跑通的关键。Codex 是技术总监。它不直接干最脏最累的活而是负责理解整体需求、拆解任务、决定技术选型、协调另外两个 Agent 的工作顺序。你可以把它理解成一个经验丰富但没时间亲自写代码的架构师它的价值在于决策和调度。WorkBuddy 是全栈执行者。它擅长把具体的功能模块落地成可运行的东西包括前端页面、后端接口、数据存储。我让它负责工时填报、差旅申请、审批流这些核心业务模块。HY4 是数据与集成专员。它更偏向数据处理、报表生成、外部系统对接这类活儿。统计看板、数据导出、跟现有系统的数据同步交给它。提示这三个角色的划分不是固定的你可以根据手头工具的能力特点重新分配。核心原则是让每个 Agent 干它最擅长的那类活而不是让一个 Agent 从头包到尾。2. 开工前的环境准备与需求拆解2.1 把一句话需求拆成可执行的任务清单我最初给 Codex 的输入只有一句话做一个工时和差旅管理系统支持员工填报、主管审批、财务统计。这句话对人来说信息量太少对 Agent 来说更是没法直接执行。所以第一步是需求拆解这一步必须由人来主导不能全甩给 AI。我按角色 - 动作 - 数据三个维度把需求展开角色核心动作涉及数据员工填报工时、提交差旅申请、上传票据项目、任务、工时数、出差地点、日期、金额主管审批工时、审批差旅、退回修改审批状态、审批意见、审批时间财务查看统计、导出报表、核对补贴汇总工时、差旅费用、补贴金额管理员配置项目、配置差旅标准、管理用户项目字典、职级标准、城市系数这张表看起来平平无奇但它是整个项目的宪法。后面所有 Agent 生成的内容都要能对应回这张表里的某一行。如果某个功能点在这张表里找不到归属要么是需求漏了要么是多余功能两种情况都要处理。2.2 技术选型的取舍为什么不用重型框架Codex 在拆解完需求后给出的第一个建议是技术选型。这里有个反直觉的点AI Agent 驱动的项目反而应该选轻量、约定优于配置的技术栈。原因很简单。Agent 生成代码时依赖越少、约定越明确出错的概率越低。如果你选一个需要大量手写配置、各种注解满天飞的框架Agent 很容易在配置细节上翻车而且排查起来极其痛苦。我最终定的方案是前端单页应用组件化状态管理用最朴素的方案不引入复杂的状态库后端轻量 Web 框架路由和业务逻辑分离清晰数据存储关系型数据库表结构显式定义不用 ORM 的自动迁移部署单机可跑容器化打包不搞复杂的编排这套选型的核心逻辑是可预测性优先。Agent 生成的每一部分我都能快速看懂、快速验证。如果用了重型框架光是理解 Agent 生成的配置就要花掉大量时间得不偿失。2.3 给 Agent 定规则这一步决定了后续效率热词里有一条给 workbuddy 定几条规则后续对所有任务都生效这条我深有体会。在正式开工前一定要给每个 Agent 设定全局规则否则它会按自己的默认习惯来生成的东西风格不统一后期整合时你会想砸键盘。我给 WorkBuddy 定的规则大致是这几条所有接口统一返回结构包含状态码、消息、数据三个字段所有时间字段统一用 ISO 格式时区固定所有金额字段用整数存储以分为单位避免浮点误差所有列表接口必须支持分页默认每页 20 条所有写操作必须记录操作人和操作时间给 HY4 定的规则偏向数据侧统计口径必须显式声明不允许出现默认口径导出文件统一用 CSV编码固定所有聚合查询必须能追溯到明细数据这些规则看起来琐碎但它们的作用是把隐性约定变成显性约束。Agent 不需要猜我也不需要事后返工。实测下来定规则这一步花 15 分钟能省下后面至少一小时的扯皮时间。3. Codex 如何指挥两个 Agent 协同干活3.1 任务编排谁先谁后谁依赖谁三个 Agent 协同最怕的是互相等或者互相踩。Codex 在这里的核心价值就是编排任务顺序和依赖关系。我的实际执行顺序是这样的Codex 先出数据模型。因为工时和差旅的所有功能都建立在数据模型之上模型不定后面全是空中楼阁。WorkBuddy 基于数据模型做后端接口。接口是前后端的契约先定接口前端才好动手。WorkBuddy 再做前端页面。页面调用已经定好的接口联调成本最低。HY4 最后做统计和导出。因为统计依赖前面产生的真实数据放最后最合理。这个顺序不是拍脑袋定的而是遵循依赖倒置原则被依赖的东西先做依赖别人的东西后做。如果顺序反了比如先做前端页面那页面里的字段名、接口地址全是猜的等后端出来必然大改。3.2 数据模型整个系统的地基Codex 给出的数据模型我做了少量调整后定稿。核心表有这么几张用户表存基本信息、角色、职级、所属部门项目表存项目编号、名称、负责人、状态工时表存用户、项目、任务描述、工时数、日期、审批状态差旅申请表存用户、出差地点、起止日期、事由、预估费用、审批状态差旅明细表存关联的申请、费用类型、金额、票据信息审批记录表存关联单据、审批人、审批动作、意见、时间这里有个关键设计决策审批记录单独成表而不是在业务表里加几个状态字段。原因是审批可能有多级、可能被退回重提、可能中途加签用状态字段根本表达不了这种复杂度。单独成表后任何单据的完整审批链路都能查出来这对财务审计极其重要。注意数据模型阶段一定要人工仔细过一遍。Agent 生成的模型通常能用但不一定好用。比如它可能忘了加索引可能字段类型选得不合适可能漏了软删除标记。这些细节后期改起来成本很高前期花 20 分钟检查非常值。3.3 接口契约前后端不打架的关键WorkBuddy 生成后端接口时我要求它先输出接口文档再写实现。接口文档包含路径、方法、请求参数、响应结构、错误码。这份文档就是前后端的合同。举个工时填报接口的例子{ path: /api/timesheet, method: POST, request: { projectId: string, taskDesc: string, hours: number, workDate: string (ISO date) }, response: { code: 0, message: success, data: { id: string } } }有了这份契约前端页面生成时就不会瞎猜字段名联调时也不会出现前端传 a、后端收 b的低级错误。实测下来先定契约再写代码联调时间能压缩一半以上。3.4 审批流的实现状态机是绕不开的审批流是整个系统里逻辑最绕的部分。我一开始想让 Agent 自由发挥结果它生成了一堆 if-else 嵌套看得我头皮发麻。后来我明确要求用状态机的方式实现审批流。状态机的核心是把状态和转移条件分离当前状态触发动作目标状态条件待提交提交待审批必填项完整待审批通过已通过审批人有权限待审批退回已退回填写退回意见已退回重新提交待审批修改后重提已通过撤销已撤销未进入结算这样设计的好处是新增审批规则时只需要加一行配置不用改代码逻辑。比如老板突然说超过 3 天的差旅要总监审批我只需要在状态机里加一条转移规则几分钟搞定。这就是前面说的改需求即改系统的具体体现。4. 实测中踩到的坑与排查过程4.1 字段类型不一致导致的静默失败第一个坑出现在工时填报功能上线测试时。员工填了 8 小时工时提交后数据库里存的是 8但统计页面显示的是 0。排查了半天发现是前端传的是字符串 8后端按数字处理时没做转换直接存进去变成了字符串聚合查询时被当成 0 处理。这个问题最坑的地方在于它不报错。接口返回成功数据库也写进去了就是统计不对。我后来在 WorkBuddy 的规则里补了一条所有数值型字段在入库前必须显式转换类型转换失败要报错。这条规则加上后类似的静默失败再没出现过。排查这类问题的思路是从最终结果倒推数据流。统计显示 0先看聚合查询的 SQL再看数据库里的实际值再看接口收到的原始值一层层往回找很快就能定位。4.2 审批权限判断的边界情况第二个坑是权限。测试时发现一个普通员工居然能审批自己的工时。原因是权限判断只检查了是否有审批权限没检查是否是自己提交的单据。这类问题的本质是权限判断的维度不全。完整的权限判断至少要考虑三个维度谁在操作、操作什么、操作的对象属于谁。我后来把权限逻辑统一抽成一个函数所有审批入口都调用它避免每个接口各写一套。提示权限相关的逻辑千万不要让 Agent 分散在各个接口里实现。一定要抽成统一的中间件或函数否则迟早会出现某个接口漏判的情况。4.3 统计口径的歧义第三个坑最隐蔽。HY4 生成的工时统计报表我核对时发现跟手工算的对不上。查了半天发现是**工时的口径不一致**报表里统计的是所有状态的工时包括被退回和撤销的而业务上只应该统计已通过的工时。这个问题暴露了前面定规则时的一个疏漏——我要求了统计口径必须显式声明但没要求口径必须跟业务确认。后来我补了一条流程任何统计功能上线前必须拿真实数据跟业务方核对一遍。数字对不上功能就不算完成。4.4 Agent 生成代码的通用排查套路踩了这几个坑之后我总结出一套排查 Agent 生成代码的通用套路先看数据流再看控制流。Agent 生成的代码数据流出问题的概率远高于控制流。字段类型、空值处理、编码格式这三样是重灾区。边界值优先测。空值、零值、超大值、特殊字符这些边界情况 Agent 经常考虑不全。权限和状态相关的逻辑重点查。这两块逻辑分支多Agent 容易漏掉某些组合。统计类功能必须对账。任何涉及聚合、汇总的功能都要拿真实数据验证一遍。这套套路用下来排查效率比盲目看代码高得多。5. 从需求到上线的完整时间线复盘5.1 两小时是怎么分配的很多人好奇2 小时这个数字是怎么来的我把实际时间分配列出来阶段耗时主要工作需求拆解20 分钟人工梳理角色、动作、数据数据模型15 分钟Codex 生成 人工调整后端接口30 分钟WorkBuddy 生成 契约确认前端页面25 分钟WorkBuddy 生成 联调统计导出15 分钟HY4 生成 对账测试修复15 分钟边界测试 权限验证加起来正好两小时出头。但要说清楚这两小时是高度专注、需求明确、工具熟练的前提下。如果需求本身模糊光是跟业务方对齐就要花掉大半天。所以2 小时不是普遍规律而是一个理想状态下的参考值。5.2 哪些环节绝对不能省复盘下来有几个环节看起来可以省实际上绝对不能省需求拆解不能省。这是整个项目的地基地基歪了后面全歪。我见过太多人直接甩一句话给 AI然后抱怨生成的东西不能用。问题不在 AI在于需求本身就没想清楚。数据模型检查不能省。Agent 生成的模型通常能跑但细节经不起推敲。索引、类型、约束这些必须人工过一遍。权限和统计的验证不能省。这两块是业务系统的命门出错代价最大。宁可多花 10 分钟验证也不要上线后出问题。5.3 哪些环节可以大胆交给 Agent反过来有些环节可以放心交给 AgentCRUD 接口的生成。增删改查这种模式化的代码Agent 生成得又快又好人工写反而容易出错。前端页面的布局。表单、列表、详情页这些标准页面Agent 生成的完成度很高微调即可。数据导出的实现。CSV 导出、字段映射这类逻辑Agent 处理得很稳。基础校验逻辑。必填校验、格式校验、长度校验这些规则明确的东西交给 Agent 没问题。核心判断标准是规则明确、模式固定、出错代价低的活儿交给 Agent规则模糊、需要权衡、出错代价高的活儿人来把关。6. 这套打法能复用到哪些场景6.1 判断一个需求适不适合 Agent 驱动不是所有系统都适合用这套打法。我总结了一个简单的判断框架看四个维度业务规则能否用自然语言描述清楚能就适合不能先想清楚再说。数据模型是否相对稳定稳定就适合天天变先别急。是否有大量模式化的 CRUD有就适合全是复杂算法另说。变更是否频繁频繁Agent 驱动的优势越明显。工时差旅系统四条全中所以效果很好。反过来如果是那种核心逻辑是复杂数学计算、或者对性能有极致要求的系统Agent 驱动的收益就没那么大。6.2 类似的管理系统可以照搬按这个思路以下这些系统基本可以照搬这套打法请假管理系统跟工时差旅高度相似表单 审批 统计采购申请系统多了供应商和比价但骨架一样资产管理系统多了资产状态流转逻辑类似客户跟进系统表单 权限 报表套路一致内部工单系统分派 处理 统计结构相同这些系统的共同点是流程驱动 数据记录 统计呈现正好是 Agent 最擅长的领域。6.3 什么情况下要谨慎有两种情况我会特别谨慎。一种是涉及资金流转的系统比如支付、结算这类系统对准确性和安全性的要求极高Agent 生成的代码必须经过严格审计不能直接上线。另一种是涉及大量外部系统对接的系统因为外部系统的接口往往文档不全、行为诡异Agent 很难处理这种脏环境。这两种情况的共同点是容错空间小。Agent 生成的东西本质上是大概率正确但业务系统有时候要求必须正确。这种时候人的把关就不能省。7. 关于 Vibe Coding 的一点个人体会用这套打法做完工时差旅系统之后我最大的感受是Vibe Coding 的门槛不在工具而在把问题说清楚的能力。工具本身已经足够强了Codex 能理解复杂需求WorkBuddy 能生成可运行的代码HY4 能处理数据逻辑。但如果你自己都没想清楚要做什么工具再强也白搭。我见过太多人把 AI 当许愿池扔一句话进去就等着收成品结果当然是失望。真正有效的用法是你先想清楚 80%让 AI 补剩下的 20%然后你验收。想清楚的部分包括业务规则、数据模型、权限逻辑、验收标准让 AI 补的部分包括代码实现、页面布局、接口细节验收的部分包括边界测试、权限验证、数据对账。还有一个体会是规则要前置。前面花 15 分钟给 Agent 定规则后面能省下大量返工时间。规则定得越细Agent 的自由发挥空间越小但生成结果的稳定性越高。这个 trade-off 在业务系统开发里稳定性永远优先。最后说个实际的这套打法目前最适合的是内部工具类系统也就是给自己人用、不对外、容错空间相对大的系统。这类系统用传统方式做投入产出比很低用 Agent 驱动能快速见效。等这套流程跑熟了再往更复杂的场景延伸是比较稳妥的路径。
