技术周报写得好，不是为了显得忙，而是让团队知道系统正在变得更稳定、更快、更可维护。
很多程序员周报只写：修复 XX bug、完成 XX 接口、参与 XX 评审。问题是这些描述只说明「做了事」，没有说明「产生了什么技术价值」。
技术周报最好围绕四类价值写：交付、质量、性能、风险。
一、技术周报结构
| 模块 | 示例 |
| 本周交付 | 完成接口、页面、任务、联调 |
| 稳定性提升 | 修复线上问题、补监控、减少告警 |
| 性能 / 效率 | 接口耗时、构建速度、自动化效率 |
| 风险与依赖 | 排期风险、技术债、跨团队依赖 |
| 下周计划 | 明确可验收产出 |
二、模板
本周完成
- 完成【模块/需求】开发，包含【核心功能 1/2/3】，当前状态为【已提测/联调中/待上线】。
- 修复【问题类型】共【数量】个，其中【关键问题】已通过【方式】验证。
- 补充【测试/监控/文档】，降低后续维护成本。
技术价值
本周重点提升了【稳定性/性能/可维护性】。例如：【接口/任务】耗时从【旧值】降低到【新值】；【告警/错误】从【旧值】下降到【新值】。
风险与下周计划
当前风险是【依赖/排期/技术方案】。下周计划完成【可验收产出】，并在【时间】前同步给【团队/负责人】。
三、把普通描述改成高分描述
普通写法：
修复订单接口 bug，开发优惠券功能。
高分写法：
修复订单接口在高并发下重复提交问题，补充幂等校验和 3 条单测；完成优惠券核销接口开发，目前已进入联调，预计下周二提测。
差别在于：第二种写法有问题背景、解决方式、质量保障、当前状态和下一步。
四、程序员周报常见误区
- 只写代码任务，不写系统影响。
- 只写「修复 bug」，不写复现原因和验证方式。
- 下周计划太虚，比如「继续开发」。
- 不写风险，导致延期时没人提前知道。
五、推荐工具
- 用 技术文档 Prompt 整理 README。
- 用 代码 Review Prompt 检查 PR。
- 用 职场写作资料包 拿技术周报、述职和晋升答辩模板。
