Atomeocean仪式性贡献流程指南
本文档指导Atomeocean轻量工作成员以规范、可追溯、可审核的方式，向 Job Compass 开源项目提交一次完整的“仪式性贡献”（Ceremonial Contribution）。
全程在浏览器里就能走完，不需要在电脑上安装任何软件，也不需要任何编程基础。
本页只讲“怎么做”
本页覆盖从新建文件到 PR 合并的完整操作流程，以及一次贡献是否被计为有效的验收与判定规则。
- 面经文章里具体写什么（JSON 字段规范、Markdown 模板、引用来源）——见面经内容规范
- 为什么要做仪式性贡献——见轻量工作指南
- 每月要做几次、不做的后果——见轻量员工工作量管理规定
这项任务到底在做什么
一句话：写一篇真实的美国面试经验，提交到 Job Compass，审核通过并合并进主线后，这次合并记录就计入你选择的有效在职月。
| 问题 | 答案 |
|---|---|
| 要交什么 | 一篇真实的美国面试经验，以你自己面过的经历为主。参考公开信息整理时需要标注来源，并加入自己的理解，不能整篇照抄 |
| 需要写代码吗 | 不需要。不要求与你的专业相关，也不需要任何编程基础 |
| 交到哪里 | Atomeocean 的开源项目 Job Compass |
| 怎么交 | 在 GitHub 网页上新建两个文件，然后发起一个 Pull Request（简称 PR，在 GitHub 上提交内容的方式） |
| 最终成品 | 一次合并进 Job Compass 主线的贡献记录，外加一份书面审核报告 |
| 做不下去怎么办 | 任何一步卡住都可以交给公司，见我做不到时公司怎么接手 |
两种完成方式
先判断自己属于哪一种，两种方式的最终成品完全一样。
| 路径 A：你自己提交 | 路径 B：公司代做 | |
|---|---|---|
| 适合谁 | 愿意跟着本页图文在网页上操作 | 完全不会，或中途做不下去 |
| 你要做什么 | 按下面的步骤新建两个文件、发起 PR | 下单时在「PR链接或代做说明」里写明请公司代做，并填写员工姓名或已有 GitHub 账号 |
| 公司做什么 | 3 个工作日内完成审核、批准并合并，另出一份书面审核报告 | 下单后 2 个工作日内主动联系你，约一次约 15 分钟的实时沟通，之后代注册账号 / 代提交 / 代合并，同样出一份书面审核报告 |
| 最终成品 | 一次合并进 Job Compass 主线的贡献记录 | 同左 |
开始之前（仪式性贡献前须知）
贡献目的
轻量工作员工在 Atomeocean进行仪式性贡献，是为了保障员工自身在美国的签证与身份合规，以便向移民局证明在Atomeocean有真实可查的工作记录。
此类贡献内容对公司本身 不产生任何实际价值。
基本要求
- 仪式性贡献旨在为你自己建立在美国的合规工作记录，主要时间花在准备面经内容上，网页端的提交操作本身通常十几分钟即可完成。
- Atomeocean设有Discord社区和Office Hour机制，如遇困难请及时沟通寻求帮助。
- 提交后请按照下方验收与判定核对，若流程卡顿，可参考第2条联系协助，也可以直接交给公司代做。
- 基于第1点，Atomeocean 不强求必须完成此项工作。如无美国工作记录需求，可选择放弃。
- 请勿使用任何LLM模型生成灌水内容，尊重审核人员的人工劳动。
获得提交权限
- 已加入 Atomeocean GitHub Organization
- 已获得 Job Compass 仓库的访问权限
- 了解本次贡献的目标内容是美国面试的真实经验
我这里不会了
连 GitHub 账号都还没有、或者不知道怎么申请权限，都不影响你完成本月贡献 —— 公司可以从这里接手。
需要协助时
如果遇到以下情况
- 不确定内容是否合适
- 不清楚放在哪个目录
- 不熟悉 GitHub 的网页操作
可在 Discord 社区中咨询，特别是mentor，Atomeocean提供每周数次的 轻量工作Office Hour可以语音求助。
如果不想再研究操作，直接走公司代做也不会影响本月贡献的有效性。
编辑内容
一次仪式性贡献需要在 Job Compass 仓库中新增两个文件：一个存放面试基本信息的 JSON，一个存放面试过程的 Markdown。
1. 生成六位随机ID
先生成一个六位随机ID（如 869pu4），由数字和小写字母组成，两个文件共用同一个ID。目前atomeocean还没有提供生成工具，可以随便想一个。
2. 确定两个文件的路径
按下面的路径格式创建，需要替换 {company} 和 {六位随机ID} 两个值：
docs/assets/json/interview-experience/{company}/{六位随机ID}.json
docs/zhHans/interview-experience/{company}/{六位随机ID}.md{company} 用公司英文小写，多个单词之间用短横线连接（如 apple、bytedance）。例如添加一个 Apple 公司的面试经验，company 取 apple，六位随机ID 取 869pu4，则创建
docs/assets/json/interview-experience/apple/869pu4.json
docs/zhHans/interview-experience/apple/869pu4.md建议先把两个文件的内容在本地的记事本或编辑器里写好，再照着下面的步骤粘贴到网页上。
我这里不会了
内容写不出来、或者不确定格式对不对，都可以交给公司接手。
第一步：新建第一个文件并提交到新分支
打开 job-compass 仓库，进入 docs/assets/json/interview-experience/ 目录。
点击右上方的 Add file 按钮，选择 Create new file 选项。
页面跳转到文件编辑器。上方输入框的左侧已经带着你当前所在的目录，只需要在框里填 {company}/{六位随机ID}.json（例如 apple/869pu4.json）—— 输入 / 时 GitHub 会自动建出还不存在的公司文件夹。在下方编辑器里粘贴文件内容。
编辑过程中可以随时点 Preview 预览效果。这一步就代替了本地检查文件内容。
内容写好后，点右上方的 Commit changes... 按钮。
弹出的对话框里填写提交信息：第一个输入框写一句简短说明（例如 docs: add interview experience (ceremonial)），第二个输入框是选填的详细描述。
对话框下方选择提交到哪个分支。🚫 不要直接提交到 main 分支，请选择新建分支，并按下面的规则填写分支名：
yourname/ceremonial-yyyymmdd例如 alice/ceremonial-20260106。该命名方式用于
- 明确贡献人
- 标识为仪式性贡献
- 便于后续审计与统计
填好后点 Propose changes。
先别急着创建 PR
点完 Propose changes 后页面会跳到 Pull Request 发布页，但你还有第二个文件没提交。 先按下一节把第二个文件也提交到同一个分支，再回来创建 PR。
我这里不会了
这一步做不下去不影响你完成本月贡献 —— 公司可以从这里接手。
第二步：在同一分支上新建第二个文件
两个文件必须在同一个分支上，才能包含在同一个 PR 里。而 GitHub 网页编辑器在第一次提交后会回到默认分支，所以第二个文件不能直接接着建，要先切分支。
- 回到 job-compass 仓库首页。
- 点左上方的分支选择器（默认显示
main），在列表里选中你刚创建的分支（如alice/ceremonial-20260106）。确认分支名已经变成你的分支，再继续。 - 确认分支已经切过来后，进入
docs/zhHans/interview-experience/目录，重复第一步的操作：Add file→Create new file→ 在输入框里填{company}/{六位随机ID}.md（例如apple/869pu4.md）→ 粘贴内容 →Commit changes...。 - 这一次的提交对话框里，分支选项要选「提交到当前分支」，不要再新建分支。
如果需要修改已经提交过的文件，进入该文件后点右上方的铅笔图标 Edit this file 即可。
分支选错了怎么办
如果第二个文件不小心又新建了一个分支，两个文件就会分在两个 PR 里，会被要求重新整理。 发现选错时，最省事的做法是把这个文件在正确的分支上重新提交一次。
我这里不会了
切分支这一步最容易卡住。做不下去时，公司可以从这里接手。
第三步：创建 Pull Request
两个文件都提交到同一分支后，打开仓库上方的 Pull requests 选项卡，点 New pull request，把你的分支与 main 对比后进入 PR 发布页（刚提交完时页面顶部通常也会直接出现 Compare & pull request 提示按钮）。
在 PR 发布页填写标题与描述。
请确保
- PR 标题 简要描述本次贡献内容
- PR 描述 包含：
- 本次贡献的内容说明
- 是否为首次贡献
- 如有对应 Issue，请在描述中关联（如 Fixes #123）
- 重要: PR Assignees 已指派给自己 —— 在右侧栏
Assignees中点assign yourself
请确认PR Assignee是你自己的GitHub账号，否则无法关联到个人工作记录中
确认无误后点 Create pull request，PR 创建完成，并显示在仓库上方的 Pull requests 选项卡中。
创建前请再核对一次：这个 PR 里应该恰好包含两个文件（一个 JSON、一个 Markdown），且只有一篇面试经验。
如需更完整的网页端图文与视频演示，可参考发布 Pull Request (PR) 教学，操作流程完全一致。
我这里不会了
这一步做不下去不影响你完成本月贡献 —— 公司可以从这里接手。
根据Review意见修改并通过 CI
- Mentors 或 Maintainers 会对 PR 进行 Review
- 请根据 Review 意见继续修改，修改方式同样在网页上完成：进入 PR 的
Files changed标签，在要改的文件右上角点铅笔图标编辑；或回到仓库、用分支选择器切到你的分支后再编辑该文件。提交时选择「提交到当前分支」，改动会自动出现在这个 PR 里。 - CI 检查通过是合并前的必要条件；三项都满足后由技术团队完成合并，你不需要自己动手
如对 Review 意见不理解，可在PR评论区或 Discord 中进行沟通。
别让 PR 静默
维护者提出修改意见后，连续 7 天无任何更新或回复的 PR 会被关闭，见 PR 自动关闭政策。
我这里不会了
已经提交但改不下去、或者 PR 停在半路，公司可以在你这个 PR 的分支上直接接手。
合并 Pull Request
当满足以下条件后：
- Review已通过
- CI状态为 ✅
- 内容符合项目规范
由 Atomeocean 技术团队将 PR 合并至 main 分支 —— 这一步不需要你自己点合并。合并完成后，按下方验收与判定核对即可。
我这里不会了
如果 PR 停在半路（review 意见迟迟没跟上、CI 一直不过），公司可以从这里接手。只提交不合并是不计入贡献的，所以不要把 PR 放着不管。
验证发布成功
PR合并后，请确认
- Job Compass 仓库中已包含你的内容
- Job Compass 网站或文档页面已成功更新（可能存在缓存或延迟）
如长时间未生效，可在 Discord 中反馈。
我做不到时公司怎么接手
上面任何一步做不下去，都不需要放弃本月贡献。在延长在职有效月份下单时，在「PR链接或代做说明」字段里写明请公司代做，并填写你的员工姓名或已有的 GitHub 账号即可。
会怎么安排
- 下单后 2 个工作日内，公司会主动联系你，约一次约 15 分钟的实时沟通。你不需要自己找渠道预约。
- 为什么必须实时：GitHub 账号的注册与登录需要当场的邮箱验证码或 2FA 验证码，只能同步完成，没法用邮件来回。
- 会上你需要配合的只有两种情形之一：
- 提供邮箱收到的验证码 —— 默认做法，公司用你的姓名代注册一个新的 GitHub 账号；
- 提供用于登录的已有 GitHub 账号信息 —— 次选。
- 沟通结束后你无需再跟进。公司完成提交与合并，并把书面审核报告发送到你下单时预留的邮箱。
- 如果是新注册的账号，公司会把这个账号登记到你的员工页面 —— 贡献记录是按 GitHub 账号归属到员工的，没登记就不会计入。合并完成后，你可以在员工页面的我的合规档案标签页自行核对本次记录是否已入账。
四个环节分别怎么接手
| 卡在哪一步 | 公司怎么接手 | 你在下单时提供 |
|---|---|---|
| 注册 GitHub 账号 | 公司用你的姓名代注册 | 员工姓名；注册过程需要你在 15 分钟沟通中实时提供邮箱验证码 |
| 本地配置 Git 与项目 | 主路径已经取消这一步；仍需要时由公司代做 | GitHub 账号 |
| 提交 PR | 公司代提交并代合并 | GitHub 账号 |
| 已提交 PR 但停滞 | 公司在该 PR 的分支上直接重写 | 该 PR 链接 |
代做的终点就是合并
不计入贡献的情形里写着「PR 仅提交但未合并不计入」——代做路径不存在这个风险， 因为公司代做的终点就是把内容合并进 Job Compass 主线。
代做的 PR 计入对应 GitHub 账号所对应的员工名下，与你自己提交的记录性质一致。
无法配合验证码就无法代做
如果你在沟通中无法提供邮箱验证码，也不愿提供已有账号信息，公司无法代注册或代登录，代做就无法进行。
已经装好 Git 的人可以走命令行
以下内容不是必经步骤。上面的网页端流程已经覆盖全部操作；如果你本来就有 Git 环境、更习惯命令行，可以按这里操作。
展开命令行操作步骤
1. 配置 Git 环境
确保本地已正确安装并配置 Git
git --version
git config --global user.name "Your Name"
git config --global user.email "your@email.com"2. Clone Job Compass 仓库
git clone https://github.com/atomeocean/job-compass.git
cd job-compass3. 确认仓库状态
确保当前分支为 main，且本地代码是最新的
git checkout main
git pull4. 创建分支
🚫 禁止直接在 main 分支上开发。分支命名规则与网页端一致：
git checkout -b alice/ceremonial-202601065. 提交代码
按编辑内容创建两个文件后，将变更加入暂存区并提交
git add .
git commit -m "docs: add interview experience (ceremonial)"Commit Message 建议规范
- 信息简洁明确
- 一个PR可以包含1个或多个commit
6. 推送并创建 PR
git push origin yourname/ceremonial-yyyymmdd随后在 GitHub 上创建 Pull Request，标题、描述与 Assignees 的要求与上文「第三步：创建 Pull Request」完全一致。
Review 阶段的修改在同一分支上继续 commit 并 push 即可。
验收与判定
完成以上流程，即视为一次完整且合规的仪式性贡献。 贡献记录包含Job Compass网站页面更新和GitHub PR记录，完全满足美国工作身份合规要求。
验收清单
请逐项确认以下条件均已满足：
- Pull Request 已合并 —— 确认 PR 已被合并至代码库的主分支。
- 合规工作记录已登记 —— 确认在 Atomeocean 员工页面的“合规工作记录”中，已添加对应的仪式性贡献记录。
- GitHub 活动网格已更新 —— 确认 GitHub Profile 的活动网格图已显示本次贡献记录。
- Job Compass 部署完成 —— 确认 Job Compass 网站已成功部署，并可访问对应 URL。
不计入贡献的情形
以下情况不计入仪式性贡献：
- PR 仅提交但未合并 —— 若 Pull Request 因内容不达标、长期无响应等原因始终没能合并至主分支，不计入贡献。这是最常见的误区：合并本身由技术团队完成，但你需要把 review 意见跟完，否则 PR 会停在半路甚至被关闭。
- 一个 PR 中包含多篇面试经验 —— 我们会在沟通后关闭该 PR，请拆分为每篇一个 PR。
- 内容为 AI 直接生成 —— 检测到 PR 内容由 AI 直接生成的，我们将在留言说明后关闭该 PR。
- PR 因长期无响应被关闭 —— 见下方政策。
内容层面的具体要求见面经内容规范。
PR 自动关闭政策
为什么我的PR会被关闭
A：当PR在连续无活动时： 等待修改阶段：维护者提出修改意见后，7天内无任何更新或回复
如果我有事无法及时响应怎么办
A：我们完全理解！请选择以下任一方式
- 在 PR 中留言说明预计可响应的时间
- 为 PR 添加
work in progress标签 - 简单回复“收到，将在[日期]前处理”即可重置计时器
自动关闭会影响我的贡献记录吗
A：关闭的PR会保留在项目历史中，展示您的贡献努力。为鼓励活跃协作，仅成功合并的PR会计入月度贡献统计。
如何避免PR被误关闭
A：保持定期沟通是关键
- 即使只是“正在处理中”的简短回复
- 分批提交修改，每次提交都会重置计时
- 遇到困难时主动求助，维护者很乐意提供指导
节假日或周末会计时吗
不会