开发规范与 AI 使用
技术部对部员的核心期待不是「立刻独立扛项目」，而是养成可维护的代码习惯，并且真正理解你提交的内容。以后面试被深挖项目时，这些同样用得上。
部内总纲见 规章制度 · 代码规范；各仓库还有各自的 Contributing，以更严格者为准。
基本原则
能看懂、能解释
- PR 里的改动，你要能回答：为什么这样写、还有没有更简单的写法。
- 若别人（或面试官）指着某段代码追问，你应该能 walkthrough，而不是「AI 生成的我不清楚」。
- 学习目的优先：借助工具可以，但不能把不理解的黑盒交差。
小步、可读、可 review
- 命名清楚；避免无意义缩写和巨型函数。
- 不要整段复制粘贴 AI 输出而不整理；删 dead code、统一风格。
- PR 尽量小且聚焦；description 写清「改了什么、为什么」。
- 不懂就问 eboard，比 silent 糊过去好。
先本地，后 PR；默认不碰生产
- 改动先在本地跑通、自测，再提 PR。
- 生产环境、服务器、域名新人默认不操作；需要权限时找部长或 eboard 明确授权后再做。
Cursor / Claude 怎么用
可以
- 在本地用 AI 问概念、查报错、生成脚手架或小片段。
- 用 AI 辅助改部内 repo 的功能（仍须自己 review）。
- 在理解 diff 的前提下 提 PR。
不可以
- 不读 diff 就提交；无法解释的文件或函数。
- 把 AI 输出当黑盒 merge；面试/ review 时讲不清楚实现。
- 用 AI 绕过学习：「能跑就行」但说不清原理 — 长期会吃亏。
自检（提 PR 前）
- 通读 整个 diff，每一文件都能说大意。
- 任选一行，能解释为什么这样写。
- 若被问「不用 AI 你会怎么写」，能答个大概方向。
- 本地已跑过相关功能或构建（视项目而定）。
与各项目规范的关系
认领项目后，请阅读该 repo 的 Contributing / Code Style，例如：
| 项目 | 入口 |
|---|---|
| 少数派抽奖 | Development Setup · Code Style |
| CSSA Docs | Development Setup · Contribution Workflow |
其他项目在侧边栏 项目文档 → 参与贡献 中查找。
违规与部内文化
规章制度 提到：不遵守代码规范导致可读性问题时，部内会有「小节目」🎭 — 轻松提醒，但也说明规范是被认真看待的。