工时记录示例的价值在于让填报人知道每一格该写什么、审核人知道该看什么。下面给出一份按周填写的完整样例，覆盖开发、评审、会议和支持等常见工作类型，并逐项解释字段取值、颗粒度选择和常见错误。这份示例记录的是投入情况，不涉及工时成本核算与考勤工资计算。
要点总览（TL;DR）
- 工时记录示例的核心是五项信息齐全：谁、哪天、为哪个工作项、投入多少小时、产出什么，示例按天填报、按周提交。
- 工作项要挂到具体任务而非只写项目名，工作内容写动作与产出，时长单位与最小粒度需团队事先统一约定。
- 跨项目或跨工作项的投入按行拆分，一行一个工作项；审核意见区分通过、退回补填、调整时长三种处理并留痕。
- 换团队时可调整字段、填报周期与审批层级，工作项关联、投入与产出对应、审核留痕三项应保持。
- 示例只记录投入，不用于工时成本计量、人力成本核算、考勤加班与工资计算，文中数据为演示用途。
示例要解决什么问题：工时记录该记到什么程度
这份示例面向两个读者：填报人照着填，审核人照着看。它要回答的核心问题是——一条工时记录写到什么程度算合格。合格的标准可以概括为一句话：谁、在哪天、为哪个任务、投入多少小时、产出了什么，五项信息齐全且能相互对应。
记录对象包括五个要素。人，指实际投入劳动的填报人；日期，指工作发生的自然日；任务或工作项，指具体承接的工作单元；投入时长，指在该工作项上花费的小时数；产出说明，指这段时间结束时留下的可观察结果，例如提交的代码、完成的用例、输出的文档或会议结论。
口径边界需要先说清楚。本文示例只记录投入，即“时间花在哪里”。工时成本计量、人力成本分摊、考勤统计、加班认定与工资计算属于另外的管理口径，需要不同的数据来源和规则，本文不展开。
颗粒度上，按天记录与按周汇总各有取舍。按天记录适合工作内容切换频繁、需要按项目分摊、或需要逐日核对进度的团队，信息完整但填报负担较重；按周汇总适合工作内容相对稳定、以周为管理周期的团队，填报轻便但对当天细节的还原度下降。折中做法是按天记录、按周提交，示例采用这一方式。
完整示例：某研发小组一周的工时记录表
以下为演示情景，用于说明填写方式，不代表任何真实团队或客户数据。情景设定：某研发小组的一名后端开发人员，在某一周内参与订单模块迭代、参加评审与例会、并处理一次线上问题支持，按天填报、周五提交、由组长审核。
| 填报人 | 日期 | 项目/工作项 | 工作内容 | 投入小时 | 状态 | 审核人 |
|---|---|---|---|---|---|---|
| 张明 | 周一 | 订单模块迭代 / 订单查询接口开发 | 完成查询接口的入参校验与分页逻辑，提交代码并通过本地自测 | 6 | 已提交 | 李强 |
| 张明 | 周一 | 订单模块迭代 / 迭代启动会 | 参加迭代启动会，确认本周任务拆分与接口联调时间点 | 1.5 | 已提交 | 李强 |
| 张明 | 周二 | 订单模块迭代 / 订单查询接口开发 | 补充异常分支处理，修复联调中发现的空值报错 | 7 | 已提交 | 李强 |
| 张明 | 周三 | 订单模块迭代 / 接口设计评审 | 参加查询接口设计评审，记录三条修改意见并更新设计文档 | 2 | 已提交 | 李强 |
| 张明 | 周三 | 订单模块迭代 / 订单查询接口开发 | 按评审意见调整返回结构，补充单元测试用例 | 5 | 已提交 | 李强 |
| 张明 | 周四 | 订单模块迭代 / 联调支持 | 配合前端完成联调，输出接口字段说明并回复两处字段含义疑问 | 4 | 已提交 | 李强 |
| 张明 | 周四 | 线上问题支持 / 订单列表加载缓慢排查 | 排查慢查询原因，定位缺失索引并提交修复脚本 | 3 | 已提交 | 李强 |
| 张明 | 周五 | 订单模块迭代 / 测试用例评审 | 参加测试用例评审，补充边界场景两条 | 1.5 | 已提交 | 李强 |
| 张明 | 周五 | 订单模块迭代 / 迭代周会 | 汇报本周进度与遗留问题，确认下周联调计划 | 1 | 已提交 | 李强 |
| 本周合计 | 31 | — | — | |||
审核意见栏的填写样子如下：
- 审核结论：通过。
- 审核意见：周四线上问题支持已单独挂到对应工作项，记录清晰；周三评审与开发分两行填写，便于区分投入类型。本周合计31小时，与排班一致。
- 审核人签字与日期：李强，周五。
如果出现需要退回的情况，审核意见可以写成：“周二记录中‘开发’描述过于笼统，请补充具体完成内容与产出；周四联调支持请注明对接人。”这样填报人知道改哪里，审核记录也留下了处理痕迹。
逐项解释：每个字段为什么这样填
工作项关联是整张表的主干。只写项目名，审核人无法判断这段时间具体推进了哪件事，后续按任务统计投入时也无法归集。示例中每一行都挂到“订单模块迭代 / 订单查询接口开发”这样的具体工作项，同一工作项在不同日期出现多次，正是为了体现投入的连续性。
工作内容描述要写动作与产出。示例中“完成查询接口的入参校验与分页逻辑，提交代码并通过本地自测”包含动作（完成校验与分页逻辑）和产出（提交代码、通过自测）。常见错误是只写“开发”“沟通”“开会”这类空词，读者无法从中判断工作是否推进。会议类记录也应写出结论或产出，例如“确认本周任务拆分与接口联调时间点”，而不是只写“参加启动会”。
时长单位与最小粒度需要团队事先约定。示例采用0.5小时为最小单位、以小时为记录单位，原因是半天以内的碎片工作较多，0.5小时粒度足以区分，又不至于让填报人陷入分钟级记录。若团队工作切换较少，也可以约定1小时为最小单位。关键是约定统一并写入填报说明，避免同一团队内有人按0.5小时、有人按整天记录。
跨项目分摊通过分行解决。示例中周四同时出现迭代工作和线上问题支持，分两行记录，各自挂到对应工作项。同一天涉及多个项目时同样处理，一行一个工作项，不把不同工作项合并成一行再在描述里说明比例，否则后续统计无法拆分。
审核意见有三种典型处理。通过，表示记录完整、工作项关联正确、时长与排班无明显冲突；退回补填，用于描述笼统或缺少产出的情况，需指出具体行和补充要求；调整时长，用于填报时长与实际情况存在明显偏差的情况，调整时应说明依据，保留原始填报与调整后的记录，形成可追溯的痕迹。
可迁移规律：换团队、换项目怎么改这份示例
可调整的部分包括字段增减、填报周期和审批层级。字段上，需要区分客户或合同归属的团队可以增加“客户”字段，需要区分工作类型的团队可以增加“工作类型”字段（开发、测试、设计、支持）。填报周期上，工作内容稳定的团队可改为按周汇总提交，切换频繁的团队保持按天填报。审批层级上，小组规模较小时由组长一级审核即可，跨部门协作较多时可增加项目负责人复核。
应保持的部分有三项。工作项关联不能省，它是投入数据可归集的前提；投入与产出的对应不能省，每一行时长都应对应一个可描述的结果；审核留痕不能省，通过、退回、调整都应留下结论和意见，否则记录无法复核。
不同角色的填写差异体现在工作内容描述上。开发人员写清完成的模块、修复的问题和提交的产出；测试人员写清执行的用例范围、发现的缺陷数量和验证结论；设计人员写清交付的设计稿范围、评审轮次和修改要点；支持类角色写清处理的请求数量、解决的问题和对接对象。字段结构可以一致，描述侧重点按角色调整。
从表格迁移到系统填报时，字段映射的思路是：表格中的“填报人”对应系统中的填报人字段，“日期”对应工作日期，“项目/工作项”对应系统中的项目与工作项关联，“工作内容”对应工时说明，“投入小时”对应工时数，“状态”与“审核人”对应提交与审批流程。ONES 支持在工作项上登记工时，填报记录与工作项关联，审批与状态变更在同一流程中留痕，适合把上述表格结构直接落到系统中使用。迁移时先确认工作项层级是否与表格中的“项目/工作项”两级对应，再决定是否需要增加自定义字段承载“工作类型”等信息。
适用边界：这份示例不覆盖哪些情况
这份示例用于记录投入，不能直接作为工时成本计量与人力成本核算的依据。成本核算通常需要结合人员费率、项目归属规则和结算周期，这些信息不在工时记录表内，需要另行建立口径。
示例也不用于考勤、加班与工资计算。工时记录反映的是工作投入的分配，考勤关注出勤事实，加班认定涉及制度与审批，工资计算依据薪酬规则，三者数据来源和管理目的不同，混用容易产生争议。
外包协作、跨组织合作等场景需要另行约定。这类场景往往涉及多方确认、结算口径和保密要求，字段设置与审核流程应在合作开始前明确，不能直接套用内部团队的填报方式。
最后，文中所有人员、日期、任务和数据均为演示用途，用于说明填写方式，不代表任何真实团队的工作记录或绩效表现。套用到自己团队时，请按实际工作项和约定口径替换示例内容。
常见问题
工时记录按天填还是按周汇总更好？
取决于工作切换频率和管理周期。工作内容切换频繁、需要按项目分摊或逐日核对进度的团队，按天记录信息更完整；工作内容相对稳定、以周为管理周期的团队，按周汇总填报负担更轻，但对当天细节的还原度会下降。折中做法是按天记录、按周提交，示例采用这一方式。无论选哪种，都应在填报说明中写清楚，避免同一团队内口径不一致。
同一天参与了多个项目，工时记录怎么填？
按工作项分行填写，一行对应一个工作项，各自记录投入小时。不要把不同工作项合并成一行再在描述里说明比例，否则后续按任务或项目统计投入时无法拆分。示例中周四同时有迭代工作和线上问题支持，就是分两行记录、分别挂到对应工作项的。
审核时发现工时记录描述笼统，应该退回还是直接改？
描述笼统、缺少产出的情况适合退回补填，并在审核意见中指出具体行和补充要求，例如说明哪一天的描述需要补充完成内容与产出。填报时长与实际情况存在明显偏差时，可以调整时长，但要说明调整依据，并保留原始填报与调整后的记录，形成可追溯的痕迹。两种处理都应在审核意见中留下结论。
把表格形式的工时记录搬到系统里，字段怎么对应？
基本映射是：填报人对应系统填报人，日期对应工作日期，项目/工作项对应项目与工作项关联，工作内容对应工时说明，投入小时对应工时数，状态与审核人对应提交与审批流程。迁移前先确认系统的工作项层级是否与表格中的两级结构对应，再决定是否需要增加自定义字段承载工作类型等信息。ONES 支持在工作项上登记工时，填报记录与工作项关联，审批与状态变更在同一流程中留痕，可作为迁移时的参照。
这份工时记录示例能直接用于成本核算或工资计算吗？
不能。示例记录的是投入分配，成本核算还需要人员费率、项目归属规则和结算周期等信息；考勤关注出勤事实，加班认定涉及制度与审批，工资计算依据薪酬规则，数据来源和管理目的都不同。需要这些口径时，应另行建立规则和数据来源，不能直接套用本示例。
