现在看来和项目开始时间有关，在选项中设日期格式为yyyymmdd hh:mm，可发现项目开始时间为16:30，因此填入该工作日的1人日实际工时被挤压到16:30～17:00时间段中，造成了异常。

LZ看一下为什么项目开始时间不是日历所设置的8:30吧

但对于多个任务的情况就有可能了，比如任务1需要7h，接着任务2开始执行，那么任务在8：30开，任务2自然就会在16：30开始了
我们的任务工时不可能正好就是等于一天的，任务分得细了难免会出现不是在8：30开始的情况

而且后来我试验的结果还显示，对于上述任务1进行更新跟踪后，他的开始时间、完成时间就分别变成了8：30和17：00，资源使用率也就变成7/7.5了

初始条件：
无论是前置关系、项目开始日还是其他原因造成Task的开始时间在16:30，那么计划中该Task在这天内0.5h工期中分布了0.5h工时（即资源单位100%）

操作：
如果资源实际在这天花了比计划多的工时，比如8h，填进实际工时以后，MSP把实际开始时间自动设为和开始时间相同（16:30），但这天的实际工时仍然只分布到日历规定的工作结束时间为止(17:00）。

结果：
在0.5h工期内分布了8h实际工时，资源单位就异常了。

可见，实际开始时间的自动设置是导致该问题的原因，不过目前没有发现任何选项可以进一步控制实际开始时间的自动设置。

个人觉得万一有必要，可以用宏来处理：自动查看在当天是否有实际开始时间（资源域）≠工作分配可用开始时间（综合各类日历）的，有的话就改实际开始时间，不过仔细想想其实这里还牵涉到最早开始时间的问题，因此非常复杂，未免有点兴师动众的感觉。

虽然不算严重缺陷，但仍然感兴趣P3之类工具是如何处理类似问题的。