设计师负责
把体验意图变成可审查的实现
- 明确需求、交互、视觉目标与不修改的边界
- 管理 AI 的修改范围，持续查看效果并迭代
- 完成视觉、交互、响应式和基础功能自测
- 检查修改范围是否越界，整理清楚的版本记录与审查说明
01 / Roles
第一步，先划清责任边界
设计师对体验质量和提交质量负责，开发对工程正确性与最终合并负责。AI 是执行助手，不是责任主体
开发负责
保证实现能安全进入主线
- 评估代码结构、性能、安全与工程规范
- 指出风险、冲突和需要补充的测试或修改
- 确认修改符合团队架构和长期维护要求
- 完成代码审查后，批准修改进入团队主线
02 / Mental Model
第二步，看懂代码在哪里
先只看中文：代码要么在你的电脑上，要么在团队云端。括号里的英文只是以后会在开发工具里看到的名称，现在不用背
你的电脑 · 本地（Local）
你正在编辑、运行和测试的代码
main电脑上的团队主线副本feature/seat-full当前任务的隔离分支Working Tree正在编辑、尚未存档的修改
上传（Push）
把本地版本传到团队云端
获取更新（Fetch / Pull）
获取团队更新
团队云端 · 远端（Remote）
团队成员共同访问的项目代码
origin/main团队最新的正式代码主线origin/feature/seat-full上传后的任务分支Pull Request请求开发审查并合入一段修改，实际经过了哪些位置
先在电脑上编辑和存档，再上传给团队审查
01 · 编辑正在修改AI 刚改完，还没有形成版本记录
02 · 选择挑出本次改动只选择这次准备提交的相关修改
03 · 存档建立版本记录在电脑上形成一个可回退的存档点
04 · 同步接入最新主线把工作放到团队最新版本之后
05 · 上传传到团队云端让团队可以看到这次修改
06 · 发起审查请开发检查代码开发确认后再进入团队主线
03 / Workflow
第三步，按 12 步走完一次需求
团队规则优先。第一次加入项目只需额外完成：获得项目权限 → 下载代码 → 安装项目所需工具 → 在电脑上成功运行
A · 准备从团队最新代码出发
目标、范围、不涉及和验收标准
确认没有未保存修改，再获取最新代码
一个任务只由一个负责人主写
B · 实现小步修改，小步存档
公共组件、数据接口和项目工具先询问
视觉、交互、状态、响应式和原功能
确认没有越界，再保存成可回退版本
C · 交接同步主线，提交审查
按团队约定接入最新代码
逐个确认冲突，别让 AI 一键处理全部
写清改动、截图、自测和希望重点审查的内容
D · 审查与上线开发把关，双方验收
自动检查通过，开发审查工程质量
原审查页面会自动更新，继续确认
开发负责发布，设计师完成上线前验收
设计师主导
开发主导 / 双方协作
AI 辅助执行，不承担最终责任
04 / Collaboration Guardrails
多人并行时，再加上防乱护栏
核心不是让所有 AI 助手都更聪明，而是让每次修改都有唯一负责人、清楚边界、隔离空间和可回退的交接点
只允许一个人或 AI 助手主写，不与他人共享任务分支
列表、弹窗、状态、响应式分别做到可预览、可验收、可存档
通用按钮、全局样式和数据接口先约定，再让其他任务接入
说清负责人、任务分支、预计文件、依赖顺序和审查人
R什么时候需要重新同步主线（Rebase）？发起审查前同步；存在未存档修改或共享分支时先停下
这是最干净的起点。刚创建的分支通常不需要再次同步
按团队规则同步代码，处理冲突，重新测试后再上传
自动检查要求、开发提醒或目标分支变化时处理；先和审查人对齐
先保存或临时收起修改，并确认负责人。已经上传后若需改写版本历史，先由开发确认方式
AIAI 能不能自己建立版本存档（Commit）？可以，但必须先自测、检查修改范围，并由人确认
可以自主检查 / 建议
- 查看当前分支、未存档修改和修改对比，运行已有测试
- 建议任务拆分、版本说明和审查页面描述
- 在自己的任务分支内实现已确认的小任务
说明影响后，等人确认
- 建立版本存档：先展示修改对比、测试结果和存档范围
- 上传、重新同步主线、处理冲突或删除分支
- 修改共享能力、跨出边界或改他人负责的文件
版本存档闸门：小任务完成 → 页面与功能自测 → 检查修改范围 → 确认只含相关内容 → 人确认 → AI 建立存档
绝对不能自作主张
reset --hard、clean -fd、push --force- 直接修改团队主线、合并代码或处理全部冲突
- 大量删除、修改数据库 / 密钥或直接正式上线
05 / Vocabulary
遇到陌生词，再来这里查
先理解一个词“发生在哪里、改变了什么、风险是什么”，再学习命令。可以搜索中文、英文或常见命令
共 44 个术语
A项目、位置与分支先回答“代码在哪里、我现在在哪”
Repository / Repo
代码仓库一个项目的代码、版本历史和协作配置的集合
像一个完整的 Figma File，不只是某一张页面
Clone
git clone第一次把远端项目完整复制到自己的电脑，通常一个项目只做一次
把团队云端文件复制成可在本地工作的版本
Local
本地你电脑上的代码、分支和 Commit，不会自动被团队看到
只存在你电脑里的工作副本
Remote
远端GitHub / GitLab 上团队共享的代码仓库
团队可访问的云端主文件
Origin
默认远端名Git 通常给克隆来源起的名字，如 origin/main 表示远端主分支
不是新环境，只是远端仓库的常用昵称
Main / Master
主分支团队认可的主线版本，通常受保护，不应直接 Vibe Coding
当前正式主稿，不是个人探索稿
Branch
分支从某个版本分出的独立开发线，修改不会立刻影响 main
为一个需求复制出的隔离实验版本
Checkout / Switch
git switch切换到另一个分支或版本继续工作
先确认当前画板再动手，避免改错版本
Working Tree
工作区当前文件里尚未 Commit 的新增、修改和删除
正在编辑、还没正式保存版本的画布
HEAD
当前位置指针Git 用来表示“你当前正处在哪个分支 / Commit”的指针
像版本历史里当前高亮的那个节点
B修改、存档与同步一段修改如何从 AI 手里进入团队远端
Status
git status查看当前分支、未提交修改和文件状态，是让 AI 开工前的第一项检查
像先确认自己在哪个稿、有哪些未保存变化
Untracked / Modified
未跟踪 / 已修改Untracked 是 Git 还没记录的新文件；Modified 是已记录文件发生变化
新建但未纳入版本，或旧稿已有改动
Staging Area
暂存区Commit 前选择“这次要打包哪些修改”的区域，不是测试环境 Staging
像提交评审前先选中本轮要交付的页面
Add / Stage
git add把指定修改放入 Staging Area，准备进入下一次 Commit
把选中的改动加入本次版本包
Commit
git commit在本地把一组相关修改保存成有说明、可追踪的版本节点
游戏 Boss 前的存档点；小步 Commit 更容易回退
Commit Hash
如 8f31a72每个 Commit 的唯一 ID，Rebase 后 Commit 内容被重放，Hash 也会变化
一个代码版本的唯一身份证
Diff
版本差异展示新增、删除和修改，是检查 AI 是否越界的主要入口
像对比两个设计版本，先看范围再看细节
Push
git push把本地 Commit 上传到远端分支，之后团队才能看到并创建 PR
把本地存档同步到团队云端
Fetch
git fetch获取远端最新分支和 Commit 信息，但暂时不改你的工作分支
先看看团队云端更新了什么
Pull
git pull获取远端更新，并按配置 Merge 或 Rebase 进当前分支
不仅看更新，还把更新拿进当前版本
Stash
git stash把做到一半、暂时不能 Commit 的修改临时收起，之后再恢复
把桌面上的半成品先塞进抽屉
C合并、冲突与 Code Review多人同时改代码最容易出问题的地方
Merge
合并把一个分支的修改合入另一个分支，可能产生一个 Merge Commit
保留两条历史，再把探索稿合入主稿
Rebase
变基把你分支上的 Commit 重新放到最新 main 后面，会生成新的 Commit Hash
把自己的修改重新接到最新主稿之后，历史更直
Conflict
代码冲突两边改到同一位置，Git 无法判断该保留哪一版，需要人工决定
两个人都改了同一个组件，系统请你做最终取舍
PR · Pull Request
拉取请求在 GitHub 请求把你的远端分支审查后合入目标分支
把实现正式发起评审，不等于已经合并
MR · Merge Request
合并请求GitLab 常用叫法，与 PR 在协作流程中的作用基本相同
同一类“请求审查并合入”的入口
CR · Code Review
代码评审开发检查 Bug、架构、性能、安全和影响范围的过程
不是只看视觉；是工程师对实现质量的最终把关
Approve
批准Reviewer 表示当前修改满足合入要求，但仍需通过团队其他规则
评审通过信号，不一定代表已经上线
Reset
git reset移动历史指针或取消暂存；reset --hard 可能直接丢弃未保存修改
像把版本指针倒回去，Hard 模式可能不可恢复
Revert
git revert新建一个 Commit，反向撤销之前某次修改，已 Push 的多人分支通常更安全
不删历史，而是增加一条“撤回这次变化”的记录
Force Push
git push --force用本地历史强制覆盖远端历史，可能覆盖同事工作，应先确认团队规则
相当于用个人版本强行覆盖团队云端，风险很高
D运行、检查与发布环境代码如何从电脑变成用户可访问的产品
Dependency
依赖项目借用的外部代码包，通常记录在 package.json；升级可能影响整个项目
像整个文件共同依赖的组件库版本，不能为一个小改动随便升级
Environment Variable
.env不同环境的地址、开关或密钥配置，敏感内容不应提交到公开仓库
像项目的运行参数和保险箱钥匙，修改前找开发确认
API
应用程序接口前端向后端读取或写入数据的约定，包括地址、参数和返回结构
像界面与数据服务之间约定好的插口
Build
构建把开发代码加工成浏览器或服务器可以部署运行的产物
把源文件导出成真正可交付的发布包
Test / Check
测试与检查可能包括 Unit Test、E2E、Lint、Typecheck；各自检查不同问题
像同时做规范检查、组件检查和完整流程验收
CI
Continuous IntegrationPush / PR 后自动执行格式、测试、类型和 Build 检查
自动判断“这份修改是否具备合入和发布条件”
CD
持续交付 / 部署把通过检查的版本自动或半自动部署到指定环境
把检查通过的版本送到彩排或正式舞台
Pipeline
自动化流水线串联 Check、Test、Build、Deploy 的自动过程；红色通常表示某一步失败
一条发布检查清单被系统自动逐项执行
Deploy
部署把构建产物放到服务器或平台，让指定人群可以访问
把可交付版本真正摆到一个可访问环境
Local / Dev
本地 / 开发环境Local 是你电脑；Dev 通常是开发联调环境，团队定义可能不同
个人工作台或团队内部测试稿
Staging / Preview
预发布环境接近线上但通常不对真实用户开放，用于上线前完整验收
高保真、能走完整流程的彩排现场
Production / Prod
正式环境真实用户正在使用的线上环境，改动会影响真实业务
最终公开发布的产品版本
Log
运行日志记录系统执行过程、错误和关键信息，是 CI 失败或线上问题的排查入口
像产品运行时留下的过程记录和错误线索
没有找到这个术语，试试中文、英文或命令名称
06 / Codex Prompts
最后，把这套规则交给 Codex
把方括号里的内容替换成你的实际任务。每个提示词都要求 Codex 先说明风险，再执行动作
建议先把团队分支命名、提交格式和 PR 模板补进提示词，团队约定始终优先
01 开始任务：检查是否适合开工同步代码、确认分支与工作区状态
我要开始任务：[任务名称] 请先不要修改代码，帮我检查： 1. 当前 Git 状态、所在分支和未提交修改 2. 远端是否有更新，当前代码是否适合开始开发 3. 建议的分支名称（遵循项目现有命名规范） 4. 这个任务预计涉及哪些文件；标出公共组件、全局配置和高风险文件 5. 当前仓库是否存在可能重叠的分支或修改；无法判断团队 Owner 时提醒我人工确认 任务范围： - 要实现：[具体内容] - 不涉及：[API / 数据库 / 权限 / 其他页面等] 如果工作区干净且适合开始，请说明建议的同步和建分支步骤。不要修改代码，不要 Commit、Push、Rebase 或 Merge；遇到冲突、其他 Agent 修改或不确定项时先停下告诉我
02 开发：实现需求但不要越界给 AI 清楚的目标、范围与禁区
实现任务：[任务名称] 设计目标： - [用户看到什么 / 完成什么] - [视觉与交互要求] - [需要覆盖的状态：默认、Hover、Loading、Empty、Error、Disabled、响应式等] 修改边界： - 只修改与本任务直接相关的代码 - 优先复用现有组件和设计变量 - 不修改全局样式、API、数据库和权限逻辑 - 不升级依赖，不重构无关代码，不删除已有功能 - 如果必须修改公共组件或超出范围，先说明原因和影响，等我确认 - 只在当前任务 Branch 内工作；发现其他 Agent 的修改时不要覆盖 - 未经我确认，不执行 Commit、Push、Rebase、Merge 或任何强制 Git 操作 请先简述实现计划，再开始修改。完成后请运行相关检查，并告诉我：修改了哪些文件、每个文件为什么修改、我应该如何自测
03 提交前：检查 Diff 和自测结果确认没有越界，再建立 Commit
任务已经完成，先不要 Commit 或 Push。请做一次提交前检查： 1. 总结当前 Diff：修改文件、增删范围和每项修改的目的 2. 标出任何可能越界、与任务无关或风险较高的修改 3. 确认没有意外修改依赖、全局样式、API、数据库、权限或配置 4. 运行项目现有的相关检查 / 测试，并报告结果 5. 给我一份设计与功能自测清单，包含核心流程、异常状态和响应式 6. 建议一个符合项目规范的 Commit message 任务原始范围：[粘贴任务范围] 如果发现问题，先说明并建议最小修复方案；不要自动删除或覆盖我已有的修改
04 提交 CR：生成开发易审查的说明Commit / Push 后整理 PR 或 CR 内容
请根据当前分支相对主线的实际 Diff，帮我生成一份可以直接提交给开发的 PR / CR 说明 格式包含： 1. 标题：简短说明做了什么 2. 背景 / 目标：为什么要改 3. 修改内容：按功能分点，说明关键文件或组件 4. 不在本次范围：明确没有修改什么 5. 自测结果：已验证的页面、流程、状态和屏幕尺寸 6. Review 重点：希望开发重点检查的工程风险或不确定项 7. 截图位置：用占位符提示我补充 Before / After 8. 关联需求：用占位符提示我补充任务链接 要求：只根据实际 Diff 写，不夸大测试结果；不确定的内容明确标注“待确认”。最后再给我一个提交 CR 前的 5 项检查清单
你的目标不是独立合并代码
而是稳定地产出：范围明确、体验过关、自测完成、Diff 可解释、开发愿意接手 Review 的提交