2.4 KiB
2.4 KiB
后端开发反思报告 写作指南
字数：800–1500 字
形式：自由叙述，不必拘泥于固定格式
核心：我们想听到的是你的思考，而非代码的复述
写作要求
请围绕以下 三个问题 展开你的反思：
1. 你遇到的最大挑战是什么？你是如何解决的？（约 4 分）
- 描述一个让你卡住、困惑或反复调试的具体问题
- 说明你的排查过程：尝试了哪些方法？走了哪些弯路？
- 最终是如何解决的？从中学到了什么？
💡 好的回答会展现真实的问题解决过程，而不是"一切顺利"的流水账。
2. 如果重新做一遍，你会有什么不同的设计决策？（约 3 分）
- 回顾你的代码架构、数据模型或实现方式
- 哪些地方你现在觉得可以做得更好？
- 如果时间充裕，你会如何改进？
💡 这个问题考察的是你的反思能力和技术判断力，承认不足比假装完美更有价值。
3. 你如何使用 AI 辅助开发？有什么经验教训？（约 3 分）
- 举 1-2 个具体例子：你问了什么？AI 给了什么回答？
- 哪些 AI 建议是有用的？哪些是错误或需要修改的？
- 你学到了什么关于"如何正确使用 AI"的经验？
💡 诚实地分享 AI 帮助你的地方和误导你的地方，这比"AI 很有用"的泛泛之谈更有价值。
评分说明
| 维度 | 分值 | 评分标准 |
|---|---|---|
| 问题解决 | 4 分 | 问题描述具体、解决过程真实、有明确的学习收获 |
| 反思深度 | 3 分 | 能识别自己代码的不足、提出合理的改进思路 |
| AI 使用 | 3 分 | 有具体案例、能辨别 AI 输出的优劣、有实用的经验总结 |
不需要写的内容
- ❌ 代码结构的详细说明（代码本身会说话）
- ❌ API 端点的罗列（README 已经有了）
- ❌ "我学到了很多"之类的空话
- ❌ 复制粘贴的技术概念解释
示例片段
不好的写法： "我使用了三层架构，Controller 负责接收请求，Service 负责业务逻辑，Repository 负责数据访问..."
好的写法： "在实现歌单复制功能时，我最初把所有逻辑都写在 Controller 里，导致代码又长又难测试。后来我把业务逻辑抽到 Service 层，不仅代码更清晰，还能单独写单元测试了。这让我真正理解了为什么要分层..."