当前持续投入的八类问题

这份排序回答了什么

它回答“哪些类别持续留下了最多处理记录”。它尚不能准确回答“全体成员在哪类问题上花了最多小时”。记录日既可能反映持续工作，也可能反映补录和归档习惯。

若按去重主题数排序，营养功能从第 2 位变为第 8 位，现场稳定性从第 8 位变为第 5 位。前八类保持一致，但名次对口径敏感。

哈尔滨项目复盘记录了 38.48 小时 Codex 活跃投入，其中天厨接入为 16.77 小时。这只说明少数集成主题可能很重，不能外推全团队人工工时。

统计方法与覆盖边界

1. 范围：当前 zhctprompt 团队共享仓库。时间窗：2026-08-20 至 2026-09-18，共30个自然日。用户未指定时间窗，本报告取最近30天作为“当前”快照，不是全历史排名。
2. 基线：67c33a686c364735c9c3f555f70e650752b72c85；全库718条唯一任务索引，按 updated_at 日期筛出200条。最新更新不在窗口内的任务及未登记任务不计入；因此不代表团队全部工作。
3. 归并：逐条核对200个任务标题与证据入口，合并为125个问题/工作主题，归入12类；重点主题抽读原始说明。分类与合并属于分析判断，可在明细中逐项调整。
4. 去重：同一业务目标的方案、父任务、开发子任务、诊断与复测合为一组。主题以独立业务结果为单位，不以文件数计数；一个主题只计入一个主类，跨类内容不重复计数。
5. 主指标“问题记录日”：取该主题关联任务索引文件在窗口内的 Git 提交日期并集；同一主题同一天多次提交或多个子任务只计1日，再按类求和。使用作者日期，不统计文件行数、关键词次数或提交次数。
6. 排序：问题记录日降序；同值按问题组数降序，仅用于展示。第4/5名同为20日、第6/7名同为17日，真实投入不分高低。
7. 总计185个问题记录日。这是多个问题跨日期的记录量，可以超过30；绝不是185个人天。补录、集中归档和文档维护会影响该指标，不能把记录日期当作实际连续工作日期。
8. 124/125主题有可匹配Git记录；“本地模型运行能力”缺匹配记录，主指标计0但保留在主题数和任务数中，不补造时间。
9. 对话采集登记仅能证明姜阳本机覆盖；没有全员统一人工工时。少量Ruflo任务周期或Codex回合耗时，不能直接和人工工时相加，也不能由单项目外推全团队。
10. 类别是工作问题的聚合，不表示所有投入都是返工或浪费；AI方法建设、营养产品研发可能形成长期资产。安全类留痕少也不代表风险低或不重要。
11. 证据等级：任务索引与Git存在性为A；说明与复盘为B；问题合并、成因与管理建议为D。未做个人绩效排名。

展开查看全部 12 类与主题