1. 项目概述工时管理系统PRD到底要解决什么问题1.1 为什么看起来简单PRD反而容易翻车先聊一个现象。很多人一提“工时管理系统”第一反应是“不就是填表、审批、看统计吗”。真开工写PRD时问题一个接一个冒出来工时按天填还是按小时填跨项目任务怎么拆分员工填了工时项目经理不审批怎么办离职员工的历史工时谁来认加班工时和正常工时混在一起财务核算成本怎么区分周报汇总的数字和工时明细对不上以哪个为准这些细节单独拎出来都不难难的是它们互相耦合。前端页面一旦做出来再想改“工时最小粒度”这种底层规则开发返工量非常大。PRD存在的意义就是在动手开发前把这些耦合问题一次性厘清。这里可以参考支付网关设计文档PRD的思路。很多人觉得支付网关和工时管理系统八竿子打不着但底层逻辑其实高度相似都需要把“状态”“流转”“对账”这些东西写死。支付网关PRD最看重的是幂等和状态机工时系统同样如此——一张工时单从草稿到提交再到审批通过任何一步都不能卡死更不能出现数据对不上的情况。1.2 核心角色与典型场景这份PRD写给谁看一份PRD如果只写功能按钮开发大概率会做出一个“能用但不好用”的系统。我习惯先列角色和场景因为角色决定权限场景决定流程。这份系统涉及五类角色普通员工填报本人工时查询个人填报记录。项目经理查看项目组成员工时审批项目下的工时单。部门主管查看部门整体工时投入审批部门成员的工时。财务/HR核算项目人力成本同步薪酬与结算数据。系统管理员配置项目、任务、审批流、催办规则。典型场景也建议写清楚。比如“研发人员同时参与A、B两个项目周一在A项目投入4小时、B项目投入4小时需要按项目分别填报周五被临时拉去C项目救火需要补录C项目工时时当天合计不能超过8小时”。这类场景描述直接指导数据模型设计工时的粒度、项目的多对多关系、每日上限校验全都藏在这些场景里。如果说功能需求是骨架角色和场景就是血肉。PRD里有这两块后续开发、测试、UAT都轻松很多。2. 核心功能拆解填报、审批、状态机与边界规则2.1 工时填报的最小粒度与字段设计先说一个最容易被拍板带偏的设计工时粒度。我见过有团队把粒度做成“按项目填比例”结果月末核算时财务拿着计算器一个一个对也见过把粒度做成“每天只能填一个项目”直接逼员工把非项目工作硬塞到某个项目里。我的建议是最小粒度设0.5小时每日填报上限与考勤规则挂钩。这样既照顾了碎片化工作又不会让数据碎到没法用。字段建议至少包含填报日期精确到自然日所属项目、所属任务/模块工时数精确到0.5小时工作内容说明必填建议限制100字内加班标识与加班审批单关联引用信息如关联的迭代、工单号便于追溯补充一个实操细节在前端页面上日期选择器默认选当天项目下拉框默认选“最近常用项目”工作内容说明做成必填且带字数统计。这些交互细节写进PRD开发照着做就行不用反复确认。“为什么必须限制当天总工时不超过8小时”因为工时是考勤的延伸。虽然有些团队弹性办公但工时记录的基准仍应是标准工时。若当天填报超过8小时应提示走加班审批而不是直接允许填10个小时、15个小时否则成本失真审计也有麻烦。2.2 审批流与状态机参考支付网关PRD的思路工时系统的审批流看起来简单但状态设计一定要严谨。我一般把工时单状态设计为草稿保存但未提交已提交进入审批队列审批中当前审批人处理中已通过已驳回已撤回仅提交后、审批前可撤回这里有几个边界必须写死状态之间不允许跳转比如“已通过”不能直接“驳回”“已撤回”不能直接“删除”。已通过的单据需要修改时不允许直接改原记录只能走“修正单”或“管理员调整”并留审计日志。驳回时必须填写原因且驳回后可重新编辑再提交生成新的版本记录。为什么说这和支付网关PRD的思路很像支付单从“待支付”到“支付成功”再到“退款”每一步都不能凭空出现。工时单也一样状态机必须收敛任何状态都要有出口不能出现“提交了但审批人离职了”导致单据卡死的情况。建议在PRD里附上状态流转表标明每个动作的触发角色和前置条件。催办逻辑也要写清楚已提交超过24小时未审批系统自动提醒审批人超过48小时抄送部门主管。阈值做成可配置项方便不同部门调整节奏。2.3 加班、请假和异常工时怎么处理很多PRD只写“填报-审批”没写“异常工时”上线后被投诉最多就是这里。三个典型场景加班场景先有加班审批单才能填报对应加班工时。填报页面通过接口校验关联加班的日期和时长如果没申请加班直接填加班工时前端给出提示。这样杜绝了事后乱填。请假、出差场景这部分不该计入项目工时但需要和HR系统打通后展示“出勤状态”避免员工请假当天还能填项目工时出现“人在休假、工时满勤”的笑话。公共任务场景开会、培训、技术预研这类不归属具体项目的工时必须设立公共任务池。否则员工只能乱选项目数据全被污染。公共任务也应有负责人比如部门主管负责最终审批。3. 实战技巧让智能体根据前端页面反推PRD3.1 前端页面里藏着哪些需求信息最近团队里开始流行“先有前端页面再让智能体写PRD”的做法。很多同学问前端页面都有了怎么样让智能体根据页面的展示信息和交互来写需求文档我的回答是页面本身就是最好的需求草稿关键是你得教会智能体怎么“读”。前端工程里的信息量其实很大页面字段表单项、列表列、筛选项直接映射数据模型和枚举值。交互事件按钮点击、表单校验、弹窗提示、状态变化对应功能流程和异常分支。路由和权限哪些菜单对哪些角色可见对应权限矩阵。接口定义请求参数、响应结构、错误码对应后端约束和数据流。以工时填报页为例页面上的“项目”“任务”“工时数”“工作内容”四个字段直接告诉智能体系统需要一份工时记录包含日期、项目、任务、时长、说明。页面上的“保存草稿”和“提交审批”两个按钮则对应“草稿态”和“已提交态”两个状态。3.2 给智能体喂什么数据才能写出可用的PRD实测下来单纯贴一张截图让智能体看效果很差。比较靠谱的做法是把信息结构化后喂进去。我建议准备四类材料页面清单每个页面的名称、用途、入口以及页面元素输入框、下拉、按钮的说明。接口数据前后端联调的API文档重点标注必填字段、枚举值和校验规则。交互说明诸如“提交成功跳转列表页”“驳回后弹窗提示原因”这类描述。现状约束比如“同一人同一天总工时不超过8小时”“已审批单据不可删除”等业务规则。然后配合一个明确的提示词。我常用的模板大概是下面这样请根据我提供的前端页面信息和接口信息输出一份完整的PRD。要求包含功能概述、数据字典、用户故事含状态机和异常流程、每个页面的交互规则、验收标准。对于信息不足的地方用[待确认]标注不要自行假设业务口径。实际体验下来智能体能快速产出第一稿尤其是数据字典、用户故事列表和验收标准省掉很多机械劳动。但业务口径、审批层级、统计规则这类“看不见”的约束智能体基本猜不准需要人工补。3.3 智能体版本的PRD需要人工补哪里我用智能体写工时系统PRD时发现它最容易在三个地方出错统计数据口径智能体往往默认“汇总所有填报数据”但实际业务里可能需要“只统计已审批通过的单据”。如果PRD不写明开发做出来的报表会跟绩效对不上。异常流程边界智能体很少主动考虑“员工已离职但工时未审批”“项目已关闭但有历史补录申请”这类边界需要人工在提示词里强制要求或者自己补充。权限矩阵前端页面可能只有登录后的界面智能体没法区分不同角色的可见范围。这一步建议人工列出角色-页面-操作矩阵再让智能体校验逻辑一致性。所以我的习惯是让智能体出初稿我负责补“业务规则”和“权限矩阵”然后把整份PRD丢给开发评审。在AI时代写PRD核心竞争力不是打字速度而是判断口径和补全边界的能力。4. 统计报表与成本核算PRD里的数据口径4.1 从原始工时记录到管理指标工时管理系统最容易被忽视的部分是统计模块。业务方一开始说“有个明细列表就行”但上线三个月后各种统计需求全部来了项目投入人天、人员利用率、部门工时分布、项目成本估算。这里必须给关键指标定义清楚避免开发“自由发挥”填报工时员工原始填报的工时包含草稿和未审批。有效工时审批通过且未删除的工时统计报表默认用这个口径。加班工时带加班标识的工时单独成列不影响正常排班分析。核定工时按劳动合同或考勤规则确定的基准工时用于计算利用率。举例来说一个员工本周填报了40小时其中5小时加班、12小时待审批。如果统计报表直接用填报工时算成本就会把还没审批的数据提前算进项目成本。PRD里明确“有效工时”口径后开发、财务都不会再吵架。报表输出也要考虑实际使用场景。明细报表支持按日期、项目、人员筛选和导出汇总报表按周/月聚合支撑人天投入和成本估算。导出大文件时不要同步阻塞页面异步生成并通知下载这类非功能需求同样写进PRD。4.2 权限模型与数据隔离设计权限模型建议用“角色 数据范围”双维度不然后期一定会出现“项目经理能看到全公司薪酬”这种安全事故。普通员工仅本人填报记录、个人统计。项目负责人该项目内成员的工时记录统计项目总投入。部门负责人本部门成员的工时记录汇总本部门工时。财务/HR全公司工时汇总和明细但不应看到员工备注的个人私密内容如有。管理员配置权限、调整异常数据所有调整记录留存。这里有个容易被忽略的点项目工时汇总与部门工时汇总往往是两个不同口径。项目经理看的是“项目A所有参与成员本周投入”部门主管看的是“本部门成员本周所有项目投入”。如果权限和数据范围不写清楚开发做出来的报表就可能互相矛盾。5. 非功能需求与PRD规范细节5.1 性能、审计与合规约束工时数据直接关系到薪酬和项目成本审计要求比普通业务系统高。我建议在PRD里单独写一节非功能需求否则后期上线前安全评审会拆台。审计日志记录所有关键操作提交、审批、驳回、撤回、管理员调整、导出报表。字段至少包含操作人、操作时间、操作类型、操作前后值。数据保留工时记录和审计日志至少保留3年具体按公司合规要求删除功能只允许对草稿态数据操作。性能目标列表页接口500ms以内月度汇总报表查询3秒以内导出异步生成。数据一致性审批通过后报表立刻可见如果报表有缓存必须写明缓存刷新策略。“为什么工时系统还需要审计日志”因为一旦财务按工时结算人力成本任何无痕修改都可能被质疑。哪怕只是改一个数字也要能查出来是谁、什么时候、为什么改的。5.2 把“对账思维”写进PRD我强烈建议在PRD里加一个“对账”设计。工时系统不是填完就结束它一个月要跟很多系统对账跟考勤系统对出勤工时、跟项目管理系统对任务进度、跟财务系统对项目成本。具体做法是每月1号系统自动生成“上月工时月报”包含员工填报总数、审批通过数、加班数、异常数。财务拿这个月报和薪酬系统核对如果某个员工显示请假2天却有40小时工时立刻就能发现异常。类似支付网关里的“对账文件”一个原则系统内部所有汇总数字都能追溯到明细所有状态转换都有日志。6. 常见问题与实操避坑实录6.1 典型问题速查表整理几个开发实施阶段的典型问题供读者参照问题现象可能原因解决思路员工重复提交工时单前端未做防抖后端未加唯一索引前端按钮提交时置灰后端对“日期人员项目任务”建唯一索引审批流卡住审批人离职PRD未定义转审机制增加“审批人不可用时自动转给上级”逻辑周报汇总和工时明细对不上统计口径不一致统一使用“审批通过”的明细汇总PRD写明口径智能体生成的PRD里状态缺失前端页面没有覆盖全部状态人工补充状态机流转表再让智能体校验一致性加班工时被重复计算成本加班标识缺失或关联错误加班工时必须关联加班审批单消除重复6.2 实操带来的几条PRD写作心得最后分享几条我自己的实操经验。第一工时管理系统的PRD核心不是功能列表而是“口径”。把填报工时、有效工时、加班工时的定义写清楚后面大概率不会出大乱子。第二先画状态机再写功能流程。哪怕只是草稿级别的状态表也能帮你发现很多异常场景。比如“已提交但项目已关闭”这种需求不列出来开发完全不会主动处理。第三AI写PRD时一定要把“业务口径”单独作为一条提示词要求。你可以在提示词里加一句“所有统计指标必须标注统计口径禁止自行假设”。实测这句话能减少一半返工。如果你正在做类似系统我的建议是先让智能体根据前端页面生成第一稿再自己补上审批流、权限矩阵、统计口径和审计字段。PRD改到第三版之后再拿给开发评审这时候评审效率会高很多。毕竟工时这类系统真正的门槛从来不是功能页面而是那些没人提、但上线后一定会踩的边界场景。