2026-07-20 起，这套系统改成中央仓库协作开发：谁改代码都从同一个地方拉、往同一个地方推，push 到 main 就自动上线。这份文件记录我们是怎么接起来的、以后怎么一起维护。
两台电脑各自开发，汇到同一个私有仓库；仓库跟正式环境之间由 Railway 自动接管，中间没有人手动上传代码这一步。
敏感文件（.env · staff.json · ai-students.json）只留在各自电脑上，从不经过仓库这一段。
从拉代码到真正上线，固定走这七步——顺序本身就是规则，跳步是踩坑的开始。
git clone 仓库 → npm install → 复制 .env.example 成自己的 .env。本地库跟线上完全隔离，怎么测都不会碰到真实数据。
git checkout -b feat/要做的事，群里说一声在改哪块，避免两人同时动同一个文件。
起服务，把受影响的功能页面至少点一遍。线上是真人在用的系统，裸测等于拿正式环境当测试场。
git push 到自己的分支，开 Pull Request 到 main——不直接推 main。
两人小团队，走个形式过一眼也好过完全不看。这一步是防止互相覆盖对方改动的最后一道关。
merge 进 main 的瞬间，Railway 自动拉代码构建，通常一分钟内上线，不用任何人手动操作。
看 Railway 部署日志或直接开正式环境页面，确认这次改动真的健康上线了。
系统能长期让两人 + AI 一起维护，靠的是这几条边界，不是靠记性。
staff.json / ai-students.json 全部 gitignore。需要真数据本地测试，找永良要，走 AirDrop / 加密盘，别用 IM 或邮件明文发。
main 就是线上push / merge 进 main 会直接部署到真实员工在用的系统。动手前问自己一句：这个改动本地测过了吗。
生产密钥都在 Railway 后台环境变量里，跟本地 .env 无关。本地 .env 自己填自己的测试值，不互传、不进仓库。
第一次拉这个项目，照这张表从上到下走一遍。
| 步骤 | 命令 / 位置 |
|---|---|
| 拉代码 | git clone https://github.com/DCT-TWC/dct-twc-ops.git |
| 装依赖 | npm install |
| 配环境 | cp .env.example .env，本地填 PORT=3200 / DB_PATH=./ops.db |
| 起服务 | npm start → 打开 http://localhost:3200 |
| 开分支 | git checkout -b feat/xxx |
| 推分支 | git push -u origin feat/xxx |
| 详细步骤 | 仓库里的 CONTRIBUTING.md |
| 系统设计 / 踩过的坑 | 仓库里的 HANDOFF-OPS.md |