研发日志
软著项目研发日志怎么写？字段、模板与记录整理方法
CCopyright 编辑团队内容核对：非官方指南
研发日志的价值来自可核对的工作事实。写清做了什么、依据在哪里、产生了什么结果，比把日期排满或补写大段通用技术描述更有用。
下载模板或整理已有记录原始记录、周报与回溯整理稿分别怎样使用
开发时形成的日志、Issue 讨论、评审记录可以保留原件或原始链接。周期性周报通常概括一段时间的工作，应能追溯到对应事项。
如果现在根据旧提交整理开发过程，应写明“整理日期”和引用来源，保留原始日期字段，不能把今天编排的文档描述为当时逐日记录。
推荐字段：让每条记录都有来源
这些字段用于整理，不代表每个项目都有固定的阶段或每天必须记录一次。空白模板不预填作者、日期、审核人或测试结论。
| 字段 | 建议内容 |
|---|---|
| 事项日期 | 实际事件日期；不确定时说明依据和精度 |
| 阶段或模块 | 填写真实工作范围，不强行凑齐全生命周期 |
| 工作内容 | 具体功能、问题或修改，不只写“完成开发” |
| 结果与状态 | 实际完成、待解决、测试失败等状态 |
| 依据 | 提交号、Issue、文档版本或测试记录链接 |
| 整理人及整理日期 | 如为回溯整理，单独记录，不替代事项日期 |
如何把描述写得可核对
教学示例：“处理库存导入时空行导致的解析错误，修改导入校验逻辑，依据为对应提交与测试输出。”实际使用时应填入真实提交号和结果。
避免把未执行的测试写成通过，也不要仅凭提交标题推断评审、上线或验收。缺少结果资料时，可以明确写“仅有代码提交记录，测试资料待核对”。
从版本记录整理草稿的边界
资料工具保留作者时间、提交者时间、作者和提交说明，并将它们整理成可读记录。它不会自动补出立项会议、需求调研、测试或第三方结论。
导出后结合真实需求和测试资料人工补充。保留输入的历史记录文件，确保整理稿中的每条摘要都能回到来源。
过去没有研发日志怎么处理
先查找已有的需求文档、任务记录、邮件交付、测试输出与版本备份。将能够核实的事项汇总，并说明哪些记录缺失。
如补正明确指定了日志，而你无法提供原始日志，应向办理机构确认如何解释或补充其他资料，不通过批量生成日期和人员来掩盖缺失。
常见问题
软著研发日志必须每天一条吗？
本轮核对未发现统一的“每天一条”要求。应按真实项目记录和具体通知处理，不能为了数量补造事项。
可以直接把 Git 提交说明当作研发日志吗？
Git 记录可以作为来源，但通常不覆盖完整研发过程。工具导出的是有来源的整理稿，仍需人工核对并补充确有依据的信息。
下载的日志模板可以直接提交吗？
模板仅提供字段，没有实际项目内容。需要填写、核对，并按通知要求确认是否适合作为附件。
依据与资料来源
- 国家版权局：《计算机软件著作权登记办法》
第 9—11 条说明申请材料；第 22 条说明补正期限。
- Git 官方：git log
提交历史、作者时间与提交者时间的导出说明。