code-review

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Reviewing Local Changes

审查本地代码变更

This skill reviews code changes in the local working tree — before they become a PR. It uses the merge-base diff to isolate "your work" from upstream, regardless of branching strategy.

Review philosophy: Find issues that matter. No nitpicking. Focus on: data loss, security breaches, performance degradation, and production incidents. Explain risk in business terms — "attacker can X" not just "this is insecure."

本Skill用于审查本地工作区中的代码变更——在这些变更成为PR之前。它使用merge-base diff来将“你的工作内容”与上游代码隔离开来，无论采用何种分支策略。

审查理念： 聚焦关键问题，不吹毛求疵。重点关注：数据丢失、安全漏洞、性能下降和生产事故。用业务术语解释风险——比如“攻击者可以执行X操作”，而非仅仅“此处存在安全问题”。

Core Command Pattern

核心命令模式

All reviews start by identifying what changed. The universal approach is a merge-base diff: everything you changed relative to the integration target.

bash

undefined

所有审查都从识别变更内容开始。通用方法是使用merge-base diff：对比你相对于集成目标的所有变更内容。

bash

undefined

1. Update remote refs (required — otherwise you diff against stale refs)

1. 更新远程引用（必须操作——否则会基于过时的引用进行对比）

git fetch origin

2. Get the merge-base (where your work diverged from the target)

2. 获取merge-base（你的工作与目标分支的分叉点）

MERGE_BASE=$(git merge-base HEAD origin/main)

3. Diff: merge-base → working tree (committed + uncommitted + staged)

3. 对比差异：merge-base → 工作区（已提交+未提交+暂存的内容）

git diff $MERGE_BASE

4. Changed file list

4. 变更文件列表

git diff $MERGE_BASE --name-only

5. Diff stats (quick size check before deep review)

5. 差异统计（深度审查前快速查看变更规模）

git diff $MERGE_BASE --stat


**Why merge-base, not `origin/main` directly?**
`git diff origin/main` includes upstream changes that aren't yours. `git merge-base` finds the fork point — so the diff shows only your work, even if main moved ahead. No rebase required.

**Detecting the integration target:**

```bash

git diff $MERGE_BASE --stat


**为什么使用merge-base而非直接对比`origin/main`？**
`git diff origin/main`会包含不属于你的上游变更内容。`git merge-base`能找到分叉点——因此diff只会展示你的工作内容，即使main分支已经更新。无需执行rebase操作。

**自动检测集成目标：**

```bash

Auto-detect: use the upstream tracking branch, fall back to origin/main or origin/master

自动检测：使用上游跟踪分支，若不存在则回退到origin/main或origin/master

TARGET=$(git rev-parse --abbrev-ref @{upstream} 2>/dev/null | sed 's|/.*|/main|')
|| TARGET=$(git rev-parse --verify origin/main 2>/dev/null && echo origin/main)
|| TARGET=origin/master


If the repo uses a non-standard default branch, the user should specify it. Ask rather than guess.

TARGET=$(git rev-parse --abbrev-ref @{upstream} 2>/dev/null | sed 's|/.*|/main|')
|| TARGET=$(git rev-parse --verify origin/main 2>/dev/null && echo origin/main)
|| TARGET=origin/master


如果仓库使用非标准默认分支，用户应指定该分支。请询问用户而非自行猜测。

How this works across branching strategies

不同分支策略下的适配

Strategy	Integration target	What the diff shows
Feature branch	`origin/main`	All commits on your branch + uncommitted work
Trunk-based (TBD)	`origin/main`	Local commits not yet pushed + uncommitted work
Stacked branches	Parent branch ( `origin/feat-base` )	Just this layer's changes
Long-lived branch, main moved ahead	`origin/main`	Still only your changes — merge-base handles it
Just rebased	`origin/main`	Same — merge-base updates to new fork point

分支策略	集成目标	Diff展示内容
特性分支	`origin/main`	你分支上的所有提交 + 未提交的工作内容
主干开发（TBD）	`origin/main`	本地已提交但未推送的内容 + 未提交的工作内容
堆叠分支	父分支（ `origin/feat-base` ）	仅当前层级的变更内容
长期分支，main分支已更新	`origin/main`	仍仅展示你的变更内容——merge-base会自动处理
刚执行过rebase	`origin/main`	效果相同——merge-base会更新到新的分叉点

Including uncommitted work

包含未提交的工作内容

The default

git diff $MERGE_BASE

compares merge-base to the working tree — this includes staged, unstaged, and committed changes all at once. That's what you want for a pre-push review: the full picture of what will land.

To review only committed changes (exclude uncommitted work):

bash

git diff $MERGE_BASE...HEAD

默认的

git diff $MERGE_BASE

会对比merge-base与工作区内容——这同时包含暂存、未暂存和已提交的变更。这正是推送前审查需要的：展示所有即将合并的内容全貌。

若仅需审查已提交的变更（排除未提交内容）：

bash

git diff $MERGE_BASE...HEAD

Review Workflow

审查工作流

Execute ALL phases in order. Never skip phases. In quick mode, skip phases marked (full mode only).

请按顺序执行所有阶段，切勿跳过。在快速模式下，可跳过标记为_(仅完整模式)_的阶段。

Phase 1: Gather context

阶段1：收集上下文

Fetch origin and compute the merge-base.
Run
```
git diff $MERGE_BASE --stat
```
to understand the scope (file count, line count).
Get the changed file list with
```
git diff $MERGE_BASE --name-only
```
.
Read the full content of every changed file (not just the diff hunks) — you need surrounding context to judge correctness.
Read the diff itself for line-level analysis.
Check commit messages with
```
git log $MERGE_BASE..HEAD --oneline
```
for intent context.
Identify the change category: new feature, bug fix, refactor, security fix, performance optimization, dependency update.
Identify critical paths: auth, payments, data writes, external APIs, file system operations.

Output: 2-3 sentence summary of what changed and why.

拉取远程代码并计算merge-base。
执行
```
git diff $MERGE_BASE --stat
```
了解变更范围（文件数量、代码行数）。
使用
```
git diff $MERGE_BASE --name-only
```
获取变更文件列表。
阅读所有变更文件的完整内容（而非仅diff片段）——你需要上下文来判断代码正确性。
逐行分析diff内容。
使用
```
git log $MERGE_BASE..HEAD --oneline
```
查看提交信息，了解变更意图。
识别变更类型：新功能、Bug修复、代码重构、安全修复、性能优化、依赖更新。
识别关键路径：认证、支付、数据写入、外部API、文件系统操作。

输出： 2-3句话总结变更内容及变更原因。

Phase 2: Classify risk

阶段2：风险分级

Rank changed files by risk before reviewing:

Critical: auth, payments, crypto, infra/deploy configs, database migrations, secrets management
High: API routes, middleware, data models, shared libraries
Medium: business logic, UI components with state
Low: docs, tests (unless deleting them), static assets, config formatting

Review critical and high files first. If time-constrained, give low-risk files a summary-only pass.

在审查前按风险等级对变更文件排序：

极高风险：认证、支付、加密、基础设施/部署配置、数据库迁移、密钥管理
高风险：API路由、中间件、数据模型、共享库
中风险：业务逻辑、带状态的UI组件
低风险：文档、测试（除非是删除测试）、静态资源、配置格式调整

优先审查极高和高风险文件。若时间有限，低风险文件仅做概要审查。

Phase 3: Security scan

阶段3：安全扫描

Check every changed line against these categories. Flag critical issues immediately.

Broken access control:

Authentication required on protected endpoints?
Authorization checks present (role/permission validation)?
User can only access their own resources (no IDOR)?

Cryptographic failures:

Passwords hashed with bcrypt/argon2 (not MD5/SHA1)?
No hardcoded secrets (API keys, tokens, passwords)?
Secrets come from environment variables?

Injection:

SQL queries use parameterized statements (no string concatenation)?
User inputs sanitized before database queries?
No
```
eval()
```
,
```
exec()
```
, or
```
Function()
```
with user input?
Command injection prevented (no
```
shell=True
```
/ unsanitized args to spawn)?
HTML output escaped to prevent XSS?

Insecure design:

Rate limiting on auth endpoints?
Input validation with schema/type checking?
Proper error handling (no stack traces to users)?

Vulnerable components:

Dependencies up to date (no known CVEs)?
Lockfile committed?

SSRF:

User-provided URLs validated against allowlist?
Internal IPs/localhost blocked?

逐行检查所有变更内容是否符合以下类别，立即标记关键问题。

访问控制失效：

受保护的端点是否要求身份验证？
是否存在授权检查（角色/权限验证）？
用户是否只能访问自身资源（无IDOR问题）？

加密机制缺陷：

密码是否使用bcrypt/argon2哈希（而非MD5/SHA1）？
是否存在硬编码密钥（API密钥、令牌、密码）？
密钥是否来自环境变量？

注入攻击：

SQL查询是否使用参数化语句（而非字符串拼接）？
用户输入在进入数据库查询前是否经过 sanitize 处理？
是否存在使用用户输入的
```
eval()
```
、
```
exec()
```
或
```
Function()
```
？
是否防止了命令注入（无
```
shell=True
```
/ 未 sanitize 的参数传入spawn）？
HTML输出是否经过转义以防止XSS？

不安全设计：

认证端点是否有速率限制？
是否使用 schema/类型检查进行输入验证？
是否有完善的错误处理（不向用户暴露堆栈跟踪）？

易受攻击的组件：

依赖是否为最新版本（无已知CVE漏洞）？
是否提交了锁定文件？

服务端请求伪造（SSRF）：

用户提供的URL是否经过白名单验证？
是否阻止了内部IP/本地主机访问？

Phase 4: Logic & performance

阶段4：逻辑与性能检查

Bugs:

Null/undefined access, off-by-one, race conditions, resource leaks
Wrong operator, inverted condition, missing edge case, unreachable code
Error swallowing (empty catch blocks), resources not closed in finally/defer
Incorrect state transitions

Performance — database & external calls:

N+1 query problem (loop with queries/API calls inside)?
Missing indexes on foreign keys or WHERE clauses?
Large result sets without pagination?
Transactions held too long?

Performance — algorithms:

O(n^2) or worse in hot path?
Unnecessary array copies or object clones?
Nested loops that can be flattened?
Unnecessary
```
await
```
in loops — use
```
Promise.all()
```
when independent?

Performance — caching:

Repeated expensive operations without caching?

API contract:

Breaking changes to public interfaces without migration/versioning?

Bug检查：

空值/未定义访问、边界值错误、竞态条件、资源泄漏
错误的运算符、条件反转、缺失的边缘情况、不可达代码
错误吞噬（空catch块）、未在finally/defer中关闭资源
不正确的状态转换

性能——数据库与外部调用：

是否存在N+1查询问题（循环内部包含查询/API调用）？
外键或WHERE子句是否缺少索引？
大型结果集是否未做分页处理？
事务是否持有时间过长？

性能——算法：

热点路径是否存在O(n^2)或更差的复杂度？
是否存在不必要的数组复制或对象克隆？
嵌套循环是否可以扁平化？
循环中是否存在不必要的
```
await
```
——独立操作应使用
```
Promise.all()
```
？

性能——缓存：

重复的昂贵操作是否未做缓存？

API契约：

公共接口的破坏性变更是否未提供迁移方案/版本控制？

Phase 5: Architecture & testing

阶段5：架构与测试检查

Architecture (flag only significant issues):

Business logic mixed with I/O or presentation?
God file (>500 lines or >20 exports)?
Circular dependencies?
Same logic duplicated in 3+ places?
Magic numbers without named constants?

Testing:

New features have tests?
Bug fixes have regression tests?
Security-critical paths tested?
Edge cases covered (empty input, max values, errors)?

If tests are missing for critical paths, list what should be tested.

架构（仅标记重大问题）：

业务逻辑是否与I/O或展示层代码混合？
是否存在“上帝文件”（超过500行或20个导出）？
是否存在循环依赖？
相同逻辑是否在3个以上地方重复？
是否存在未定义命名常量的魔法数字？

测试：

新功能是否有对应的测试？
Bug修复是否添加了回归测试？
安全关键路径是否有测试覆盖？
是否覆盖了边缘情况（空输入、最大值、错误场景）？

若关键路径缺少测试，请列出应测试的内容。

Phase 6: Run checks (full mode only)

阶段6：执行检查（仅完整模式）

bash

undefined

bash

undefined

Lint changed files (adapt to project)

检查变更文件的代码规范（适配项目实际情况）

npm run lint # or: ruff check, cargo clippy, golangci-lint run, etc.

npm run lint # 或：ruff check, cargo clippy, golangci-lint run等

Run affected tests

运行受影响的测试

npm test # or: pytest, go test, cargo test, etc.

npm test # 或：pytest, go test, cargo test等

Secret scanning (if available)

密钥扫描（若可用）

gitleaks detect --source . --no-git

Dependency audit (if lockfile changed)

依赖审计（若锁定文件有变更）

npm audit # or: pip audit, cargo audit, etc.


Only run tools that exist in the project. Check for the presence of config files (`package.json`, `pyproject.toml`, `Cargo.toml`, `go.mod`) before assuming a tool is available.

npm audit # 或：pip audit, cargo audit等


仅运行项目中已配置的工具。在运行前请检查配置文件（`package.json`、`pyproject.toml`、`Cargo.toml`、`go.mod`）是否存在，不要假设工具可用。

Phase 7: Production readiness (full mode only)

阶段7：生产就绪检查（仅完整模式）

Environment variables documented?
Backward compatible? If not, is there a migration path?
Logging added for new critical operations?
No sensitive data in logs (passwords, tokens, PII)?
Graceful error messages for users (no raw stack traces)?

环境变量是否有文档说明？
是否向后兼容？若不兼容，是否有迁移方案？
新的关键操作是否添加了日志？
日志中是否包含敏感数据（密码、令牌、PII）？
是否为用户提供了友好的错误提示（无原始堆栈跟踪）？

Producing the Review

生成审查报告

Finding format

问题记录格式

For every finding, provide:

File + line: exact path and line number. MUST exist in the diff — verify before reporting.
Severity:
```
CRITICAL
```
/
```
HIGH
```
/
```
MEDIUM
```
/
```
LOW
```

Category:

security

bug

logic

performance

architecture

testing

Title: one-line summary
Risk: what can happen — explain in business terms ("attacker can...", "users will see...", "data will be lost when...")
Current code vs fix: show both. Before/after, not just "consider changing this."
Confidence: if uncertain, say so. Prefix with
```
[Uncertain]
```
and explain what would confirm or refute.

Finding template:

CRITICAL security: [Title]
File: path/to/file.ts:42
Risk: [What can happen in business terms]

Current:
  [problematic code]

Fix:
  [corrected code]

每个问题需包含：

文件+行号：精确的路径和行号。必须存在于diff中——报告前请验证。
严重程度：
```
CRITICAL
```
/
```
HIGH
```
/
```
MEDIUM
```
/
```
LOW
```

类别：

security

bug

logic

performance

architecture

testing

标题：一行摘要
风险：可能产生的后果——用业务术语解释（“攻击者可以...”、“用户会看到...”、“当...时数据会丢失”）
当前代码 vs 修复方案：同时展示两者。提供前后对比，而非仅“建议修改此处”。
可信度：若不确定，请明确说明。前缀添加
```
[Uncertain]
```
并解释需要哪些信息来确认或排除问题。

问题记录模板：

CRITICAL security: [标题]
File: path/to/file.ts:42
Risk: [业务术语描述的风险]

Current:
  [有问题的代码]

Fix:
  [修正后的代码]

Output structure

输出结构

undefined

undefined

Review Summary

审查摘要

Recommendation: BLOCK | APPROVE WITH COMMENTS | APPROVE

[2-3 sentence summary of what changed and overall assessment]

建议： BLOCK | 带评论批准 | 批准

[2-3句话总结变更内容及整体评估]

Blocking Issues ([count])

阻塞性问题（数量：[count]）

[CRITICAL and HIGH findings with file, line, risk, and before/after fix]

[CRITICAL和HIGH级别的问题，包含文件、行号、风险及前后修复方案]

Non-Blocking Suggestions ([count])

非阻塞性建议（数量：[count]）

[MEDIUM and LOW findings — performance, architecture, quality]

[MEDIUM和LOW级别的问题——性能、架构、代码质量]

Test Coverage

测试覆盖

[What's covered, what's missing, suggested test cases]

[已覆盖的内容、缺失的内容、建议的测试用例]

Metrics

指标

Files changed: [count]
Lines added/removed: [+N / -N]
Critical issues: [count]
Non-blocking suggestions: [count]

undefined

变更文件数：[count]
增删代码行数：[+N / -N]
关键问题数：[count]
非阻塞性建议数：[count]

undefined

Recommendation logic

建议逻辑

BLOCK — must fix before pushing:

Any CRITICAL security issue (data breach, auth bypass, injection)
Data loss risk (missing transaction, no validation before delete)
Breaking change without migration path
Known performance regression

APPROVE WITH COMMENTS — non-blocking, track as follow-up:

Performance improvements (not regressions)
Architectural suggestions
Missing non-critical tests
Code quality improvements

APPROVE — when all of:

Zero critical/high security issues
No data loss risk
Performance acceptable
Critical paths tested

BLOCK — 推送前必须修复：

任何CRITICAL级别的安全问题（数据泄露、认证绕过、注入攻击）
存在数据丢失风险（缺失事务、删除前无验证）
无迁移方案的破坏性变更
已知的性能退化

带评论批准 — 非阻塞性问题，可后续跟踪：

性能优化建议（非退化）
架构改进建议
缺失非关键测试
代码质量改进建议

批准 — 满足以下所有条件：

无CRITICAL/HIGH级别的安全问题
无数据丢失风险
性能符合要求
关键路径有测试覆盖

Review Modes

审查模式

The user may request a specific mode:

"quick review" / "fast review": phases 1-5 only (no tool execution). Focus on bugs and security. Default mode.
"full review": all 7 phases — run lint, tests, secret scan, dependency audit, production readiness.
"security review": phases 1-3 only. Deep security focus — full OWASP check. Skip logic/perf/architecture.

Default to quick review unless the user asks otherwise.

用户可能会请求特定的审查模式：

“快速审查” / “极速审查”：仅执行阶段1-5（不运行工具）。聚焦Bug和安全问题。默认模式。
“完整审查”：执行全部7个阶段——运行代码规范检查、测试、密钥扫描、依赖审计、生产就绪检查。
“安全审查”：仅执行阶段1-3。深度聚焦安全——完整的OWASP检查。跳过逻辑/性能/架构检查。

除非用户特别要求，默认使用快速审查模式。

Handling Large Changesets

处理大型变更集

Changesets over 1000 lines changed require chunking:

Start with the changed file list and the diff stats.
Classify all files by risk (Phase 2).
Review the top 10 highest-risk files in full depth.
For remaining files, provide a one-line summary per file (what changed, any obvious issues).
If a single file diff exceeds 500 lines, review it hunk-by-hunk.
Tell the user you've prioritized — don't silently skip files.

Over 5000 lines: warn that a thorough review at this scale is unreliable. Suggest splitting the work and offer specific split points based on the file groupings.

变更行数超过1000行的变更集需要拆分审查：

先查看变更文件列表和diff统计。
按风险等级对所有文件分类（阶段2）。
深度审查前10个最高风险的文件。
剩余文件每个提供一行摘要（变更内容、是否有明显问题）。
若单个文件的diff超过500行，按片段逐段审查。
告知用户你已优先审查高风险内容——不要默默跳过文件。

变更行数超过5000行：告知用户此规模的变更难以进行彻底审查，建议拆分工作，并根据文件分组提供具体的拆分建议。

Decision Policy

决策规则

ALWAYS run
```
git fetch origin
```
before computing the diff. Stale refs mean wrong diffs.
ALWAYS use the merge-base, not a direct diff against
```
origin/main
```
. Direct diffs include upstream changes that aren't the user's.
ALWAYS read full file content, not just diff hunks. The same function above/below the hunk is critical context.
ALWAYS verify file paths and line numbers exist before citing them. Never hallucinate a reference.
ALWAYS provide concrete code evidence for every finding. No vague "this could be problematic".
ALWAYS explain risk in business terms. "Attacker can read any user's data via IDOR" — not "this is insecure."
ALWAYS show before/after code for fixes. Don't just describe what to change.
Discover before assuming: check what tools/configs exist in the repo before running lint/test commands. Check the default branch name before assuming
```
main
```
.
Limit output: cap at 15 findings per review. If more issues exist, summarize the rest and note the count.
Rank by impact: report critical/high first. If you hit the cap, drop low findings.
One finding per issue: don't repeat the same pattern across 10 files. Flag it once, note "same pattern in N other files".
Verify claims: if you flag an N+1 query, verify it's actually in a loop. If you flag a race condition, verify concurrent access is possible.
When in doubt, flag it: better to surface a concern than miss a critical issue. But label uncertainty honestly.

必须在计算diff前执行
```
git fetch origin
```
。过时的引用会导致错误的diff结果。
必须使用merge-base，而非直接对比
```
origin/main
```
。直接对比会包含不属于用户的上游变更。
必须阅读文件完整内容，而非仅diff片段。diff片段上下的代码是判断正确性的关键上下文。
必须在引用文件路径和行号前验证其存在性。不要编造引用。
必须为每个问题提供具体的代码证据。不要使用模糊的“此处可能存在问题”。
必须用业务术语解释风险。比如“攻击者可通过IDOR读取任意用户数据”——而非仅“此处不安全”。
必须提供问题代码与修复代码的前后对比。不要仅描述修改方向。
先确认再假设：在运行代码规范/测试命令前，先检查仓库中是否有对应的工具配置。在假设默认分支前先确认实际分支名称。
限制输出：每次审查最多列出15个问题。若存在更多问题，总结剩余问题并说明总数。
按影响排序：先报告CRITICAL/HIGH级别的问题。若达到数量上限，忽略低级别问题。
一个问题只记录一次：若同一问题模式出现在10个文件中，仅标记一次，并注明“相同问题模式出现在其他N个文件中”。
验证问题：若标记N+1查询问题，请确认它确实存在于循环中。若标记竞态条件，请确认存在并发访问的可能。
存疑时标记问题：宁可提出疑问也不要遗漏关键问题。但需如实标注不确定性。

Safety Rules

安全规则

No secrets in output: never include API keys, tokens, passwords, or connection strings in findings — even if found in the diff. Say "hardcoded secret detected at file:line" without echoing the value.
No code execution beyond standard tooling: only run linters, test suites, and scanners that are already configured in the project. Never run arbitrary code from the changeset.
Read-only: the review does not modify any code. Suggested patches are advisory — presented in the finding body, not applied.
Never approve blindly: if you can't confidently assess the changes (e.g., binary files, minified code, languages you don't know well), say so instead of guessing.

输出中不得包含密钥：即使在diff中发现API密钥、令牌、密码或连接字符串，也不要在问题记录中包含具体值。只需说明“在file:line处检测到硬编码密钥”，不要回显密钥内容。
仅运行标准工具：仅运行项目中已配置的代码规范检查、测试套件和扫描工具。不要运行变更集中的任意代码。
只读操作：审查过程中不得修改任何代码。建议的修复方案仅作为参考——展示在问题记录中，不自动应用。
绝不盲目批准：若无法自信评估变更内容（如二进制文件、压缩代码、不熟悉的编程语言），请如实告知用户，不要猜测。

Error Handling

错误处理

No remote configured: the repo may be local-only. Fall back to diffing against the first commit or ask the user what to diff against.
Detached HEAD: the user may be on a detached HEAD (e.g., during rebase). Use
```
git diff origin/main
```
directly as fallback.

Default branch isn't
main
: check with

git remote show origin | grep 'HEAD branch'

git symbolic-ref refs/remotes/origin/HEAD

. Don't assume

main

Lint/test command fails: report the failure output as a finding (category:
```
info
```
). Don't retry broken tooling — flag it and move on.
Binary files in diff: skip binary files. Note them in the summary ("N binary files changed — not reviewed").
Empty diff: if the merge-base diff is empty, tell the user — there's nothing to review. Check if they have uncommitted changes with
```
git status
```
.

无远程仓库配置：仓库可能仅为本地仓库。回退到与第一个commit对比，或询问用户应对比的基准。
分离HEAD状态：用户可能处于分离HEAD状态（如rebase过程中）。回退到直接使用
```
git diff origin/main
```
对比。

默认分支不是
main
：使用

git remote show origin | grep 'HEAD branch'

或

git symbolic-ref refs/remotes/origin/HEAD

检查。不要假设默认分支是

main

。

代码规范/测试命令执行失败：将失败输出作为问题记录（类别：
```
info
```
）。不要重试失效的工具——标记问题后继续后续审查。
Diff中包含二进制文件：跳过二进制文件。在摘要中注明“N个二进制文件已变更——未审查”。
空Diff：若merge-base diff为空，告知用户——无可审查内容。使用
```
git status
```
检查是否存在未提交的变更。