# 后端开发反思报告 写作指南

> **字数**：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 层，不仅代码更清晰，还能单独写单元测试了。这让我真正理解了为什么要分层..."