这里从一个人的学习记录开始，现在想慢慢变成大家一起整理的笔记。你可以只改一句话，也可以长期照看一个板块。先把事情讲清楚，比把流程做复杂更重要。
最短的参与路线：找到一页 → 提问或提 PR → 找另一位同伴看一遍 → 检查通过后合并。
从哪里下手
想找一个具体的小任务，先看看路线图：本版主要做面试准备，后续也欢迎 CV、自动驾驶、Jetson、仿真和机器人方向的朋友参与。版本记录会把待发布和已发布分开。
读者自愿分享的实习、全职或转行去向，和贡献者名单一起放在首页。它和贡献记录分开，不按去向决定贡献者身份。
| 想做什么 | 从哪里开始 |
|---|---|
| 改错字、补引用、修翻译 | 直接提小 PR，不必先申请 |
| 内容有疑问，或者想补一个例子 | 在文章底部「这一页哪里可以更好？」选一类反馈，会打开预填好的 issue；不用先想好答案 |
| 新写一篇、做一个交互图 | 先用内容提案说说问题、放在哪、准备怎么讲，再开 draft PR |
| 想一起维护一个板块 | 开提案，写下感兴趣的范围和大致精力；不用承诺每天在线 |
| 想补充署名或自愿填写地图位置 | 用贡献记录，附相关 issue / PR 即可 |
讨论统一留在 GitHub Issues，具体修改在 PR 里审。中英文同一篇共用讨论入口，先搜一下，尽量接着已有话题聊，不再另外维护一套评论区。
反馈表有五类：内容纠错、信息过时、解释不清、想加主题、网站问题。先选最接近的一项即可；板块和来源不知道可以留空，维护者会补。不是每次提问都要附论文，有公开依据时再加上。
板块由谁照看
| 板块 | 审核联系 | 讨论记录 |
|---|---|---|
大模型基础foundations | 已认领 @tianyi-zhang-02 | 讨论 |
强化学习与 Post-trainingposttrain | 已认领 @tianyi-zhang-02 | 讨论 |
评估evaluation | 已认领 @tianyi-zhang-02 | 讨论 |
数据与检索data-retrieval | 已认领 @tianyi-zhang-02 | 讨论 |
系统、多模态与 Agentssystems-agents | 已认领 @tianyi-zhang-02 | 讨论 |
感知、机器人与自动驾驶embodied | 已认领 @tianyi-zhang-02 | 讨论 |
前沿观察frontier | 已认领 @tianyi-zhang-02 | 讨论 |
工程实践与开源practice | 已认领 @tianyi-zhang-02 | 讨论 |
求职经历与心态career | 已认领 @tianyi-zhang-02 | 讨论 |
面试准备exercises | 已认领 @tianyi-zhang-02 | 讨论 |
写作资料与存档papers | 已认领 @tianyi-zhang-02 | 讨论 |
站点与协作site | 已认领 @tianyi-zhang-02 | 讨论 |
待认领不等于没人管：确认新负责人前，由仓库维护者临时接审。表里只放已经同意的人，不先替朋友安排工作，也不按提交数量自动分配权限。
作者负责内容；板块 reviewer 帮忙看事实、讲解和验证；维护者负责跨板块一致性、发布和争议收尾。这是分工，不是头衔。任何人都可以讨论或 review，正式合并仍需要有相应权限的审核者。
一次修改怎么过审
- 范围小一点。 一次 PR 尽量解决一个问题。涉及多个板块时，列清影响范围并请相关 reviewer 看。
- 说清依据。 引用公开来源；实验说明条件和复现方法；把观察、推测和已经验证的结论分开。检查通过不代表结论正确。
- 另一位人类看过。 常规修改需要至少一位非作者的相关 CODEOWNER 批准。审阅意见都处理或明确答复后再合并；新增提交会使旧批准失效。
- 过自动检查。 构建、隐私扫描、协作配置、测试和中英结构检查都需要通过。结构一致不等于翻译质量合格；只写一种语言时先开 draft PR，补齐后再合并。
- 合并后上线。 保留作者与共同作者署名。main 上的内容才会部署，draft PR 不算发布。
现在还只有一位确认的维护者。管理员暂时保留应急绕过权限，用于无其他审核者时的小修或修复发布故障；使用时应在 PR 里写清原因，不能把自查写成独立审核。第二位审核者确认后，再评估收紧这一例外。网站写着什么规则，和 GitHub 实际开启了哪些保护，是两件事；维护者应核对仓库设置。
AI 可以帮忙看哪一部分
维护者可以先选出公开段落，让三个角色分别看技术、讲解，以及引用与公开边界。初审工具默认只生成本地请求；需要明确开启才调用 API，目前没有自动运行的审核 bot。
三份意见放在一起，不投票决定通过。模型没有读过链接里的原文，也没有替我们跑实验；指出的问题仍需人核实。调用失败、意见不一致或依据不足，就把这部分留给人继续看。正式审核和发布决定不交给 AI。
Issue 是即时公开的，不要提交内部资料或私人进度文件，也不要指望初审会替你删掉。内容选择有主观性，不同学习路线可以并存；涉及事实的分歧，要回到来源和可复现的条件。
真有分歧时怎么办
错字不用投票。方法或结论有争议，先比较来源、假设和实验，不按资历拍板；暂时无法判断时，保留两种解释并标出不确定性。
只有目录重组、公共界面、审核规则或权限变化，才需要一次正式决定：
- 用提案写清问题、至少一个替代方案、影响和回退办法；通常留 72 小时收集意见。没人回复不等于同意。
- 有多位维护者时，邀请另一位相关维护者审阅；还只有一位时，明确记录这是单维护者决定，不伪装成共同共识。
- 讨论仍无法收束，由未涉及利益冲突的仓库维护者决定；有个人冲突时请另一位中立参与者协助。决定、理由、保留意见和重新讨论的条件都留在原 issue 中。
- 隐私泄露或站点故障可以先隐藏、回退或止损，再补记录。敏感信息不要贴进公开 issue，也不要为了说明原因再次传播。
不需要另开委员会，也不按周开会。普通内容只走正常 PR。
贡献不只有提交
审阅、提问、翻译和纠错也值得被记住。可以附上相关 issue 或 PR，申请在这里补充署名；不需要为了上榜凑提交。
贡献者名单和提交记录在首页。提交数只说明一部分活动，不是质量排名，更不是表决权。共同写作保留共同作者署名；issue 中的纠错和审核帮助，可以经本人同意后补到上面的感谢记录。位置完全自愿，也可以申请移除。
几条底线
- 对事不对人。欢迎不同意见，不接受人身攻击、骚扰、广告或与学习无关的争吵。
- 只用公开资料或可公开复现的例子。不提交公司内部数据、招聘细节、凭据或他人隐私；拿不准就先别发。自动扫描只是兜底，不能代替人工判断。
- AI 可以辅助写作、翻译和代码，但作者要自己验证。重要使用方式在 PR 里交代，不伪造引用、实验或独立 review。
- 引用注明来源，图和代码确认有权使用；新增外部脚本、依赖或第三方服务先说明用途与风险。
- 原创代码使用 MIT，原创笔记使用 CC BY 4.0；提交前确认你有权按对应许可分享，第三方材料保留原条款。详细范围见许可说明。
- 一般问题先提醒并说明原因，反复或严重违规才限制参与。安全问题可以立即处理；历史上的有效贡献不因意见不同而抹掉，署名移除按隐私请求或明确滥用情况处理。
具体怎么写、怎么本地预览，见贡献指南。