企业官网建设流程全解析

工时和差旅管理这件事，放在任何一家有规模的公司里都是个"谁提谁头疼"的活儿。业务部门嫌流程繁琐，财务部门嫌票据混乱，管理层想看个实时数据得等月底报表。市面上成熟的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 在这里的核心价值就是编排任务顺序和依赖关系。

我的实际执行顺序是这样的：

1. Codex 先出数据模型。因为工时和差旅的所有功能都建立在数据模型之上，模型不定，后面全是空中楼阁。
2. WorkBuddy 基于数据模型做后端接口。接口是前后端的契约，先定接口，前端才好动手。
3. WorkBuddy 再做前端页面。页面调用已经定好的接口，联调成本最低。
4. 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 生成代码的通用套路：

1. 先看数据流，再看控制流。Agent 生成的代码，数据流出问题的概率远高于控制流。字段类型、空值处理、编码格式，这三样是重灾区。
2. 边界值优先测。空值、零值、超大值、特殊字符，这些边界情况 Agent 经常考虑不全。
3. 权限和状态相关的逻辑重点查。这两块逻辑分支多，Agent 容易漏掉某些组合。
4. 统计类功能必须对账。任何涉及聚合、汇总的功能，都要拿真实数据验证一遍。

这套套路用下来，排查效率比盲目看代码高得多。

5. 从需求到上线的完整时间线复盘

5.1 两小时是怎么分配的

很多人好奇"2 小时"这个数字是怎么来的，我把实际时间分配列出来：

加起来正好两小时出头。但要说清楚，这两小时是"高度专注、需求明确、工具熟练"的前提下。如果需求本身模糊，光是跟业务方对齐就要花掉大半天。所以"2 小时"不是普遍规律，而是一个理想状态下的参考值。

5.2 哪些环节绝对不能省

复盘下来，有几个环节看起来可以省，实际上绝对不能省：

需求拆解不能省。这是整个项目的地基，地基歪了后面全歪。我见过太多人直接甩一句话给 AI，然后抱怨生成的东西不能用。问题不在 AI，在于需求本身就没想清楚。

数据模型检查不能省。Agent 生成的模型通常能跑，但细节经不起推敲。索引、类型、约束这些，必须人工过一遍。

权限和统计的验证不能省。这两块是业务系统的命门，出错代价最大。宁可多花 10 分钟验证，也不要上线后出问题。

5.3 哪些环节可以大胆交给 Agent

反过来，有些环节可以放心交给 Agent：

CRUD 接口的生成。增删改查这种模式化的代码，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 驱动，能快速见效。等这套流程跑熟了，再往更复杂的场景延伸，是比较稳妥的路径。