AI AI Tools Guidebook
AI Tool Tutorials

Cursor for Beginners: 30 Minutes to a Working Loop (2026)

From install to your first useful edit in 30 minutes: Inline vs Composer vs Chat, codebase indexing, @Files context injection, Apply, and rollback.

Published: Author: AI Productivity Guide Team 🌐 查看中文版本

Cursor isn’t “VS Code + ChatGPT” — it wires AI directly into file operations. Here’s the minimum viable workflow.

Install and first open

  1. Download from the official site (VS Code fork, extensions still work)
  2. Sign in, pick a model — Claude Sonnet is the best price/performance default
  3. Open an existing project directory

The three core actions

Inline edit (Cmd + K)

Cursor sits on a code block, press Cmd + K (Mac) / Ctrl + K (Win), type “add comments”, “convert to TypeScript”, etc. Only that block changes.

Composer (Cmd + I)

Opens a panel. Use it for cross-file work: “create routes/user.ts mirroring routes/auth.ts.” Composer reads multiple files and proposes multi-file edits.

Chat (Cmd + L)

Read-only conversation — understand code, debate approaches.

Make the AI actually see your project

Indexing takes time, but finishing the index ≠ it’ll use that context. Two explicit injection paths:

  • In Composer, type @ and pick specific files
  • Type @Codebase to search the whole repo

If the indexer sits at “Indexing…” for hours, that is its own failure mode — see why Cursor indexing never completes before retrying.

Apply and rollback

AI proposes edits → click Apply All or apply per file → don’t like it? Cmd + Z, or git restore.

Never Apply All 30 files in an unfamiliar project without reading the diff. If Cursor’s view of the file no longer matches what is on disk (Apply seems to ignore your recent edits), restart with a fresh window — see IDE state out of sync.

Good for

  • Refactoring a function / renaming
  • Creating analogous files
  • Writing tests
  • Explaining unfamiliar code

Not good for

  • Large architecture work
  • Long-chain debugging (Claude Code fits better)
  • Reversible multi-step ops (git gets messy)

Real-world example

Use this workflow on one concrete task first. For example: summarize one PDF, rewrite one landing-page section, audit one pull request, generate one image direction, or debug one prompt. Keep the input small enough that you can manually judge whether the AI helped. Once the result is reliable, repeat the same pattern on the full document, full codebase, or full creative batch.

When to ask for human review

  • The output will be published publicly, sent to a customer, used in code, or used for money decisions.
  • The answer contains factual claims, legal / medical / financial implications, private data, or brand-sensitive language.
  • The tool changed files, settings, permissions, billing, deployment, or anything that is hard to undo.
  • You cannot explain why the final output is correct without trusting the model blindly.

Copy-ready prompt

I want to use this workflow for a real task.

Goal:
- [describe the specific outcome]

Context:
- Tool I am using: [ChatGPT / Claude / Gemini / Cursor / Codex / other]
- Source material: [paste or attach files, notes, links, screenshots]
- Constraints: [tone, length, format, deadline, audience, privacy limits]

Please do three things:
1. Restate the task in your own words and list any missing information.
2. Produce the first version using only the context I provided.
3. Add a short review checklist so I can verify the result before using it.

Detailed walkthrough

  1. Start with the smallest real input. Do not test the workflow on fake filler text; use one real file, one real page, one real bug, or one real creative brief.
  2. Give the tool the goal, the source material, and the definition of a good answer in the same message. This prevents the model from optimizing for the wrong thing.
  3. Ask for a plan before the final output when the task affects code, public content, money, accounts, or brand voice.
  4. Run one iteration and inspect the result manually. Mark missing context, factual uncertainty, formatting drift, and places where the model overreached.
  5. Ask for a revision using concrete feedback, not “make it better”. Say what to keep, what to remove, and what standard the next version must meet.
  6. Save the final prompt, inputs, and review checklist as a reusable template for the next similar task.

Failure modes

  • The output is generic: add real source material and a stricter output format.
  • The tool invents facts: ask it to separate “confirmed from source” from “inference” and remove anything unsupported.
  • The answer is too long: set a target length and ask for a concise version after the first draft.
  • The result looks polished but wrong: verify against the source, not against how confident the writing sounds.
  • The workflow stops helping after one round: reset with a clean prompt that includes the corrected context and the best previous output.

FAQ

Q: When should I use Cmd+K vs Composer vs Chat? A: Cmd+K (Inline) for a single block — comments, a refactor, a type conversion. Composer for multi-file changes you want to review in one diff. Chat for questions and exploration that won’t change code yet. Picking wrong wastes tokens and time.

Q: Why doesn’t Cursor seem to know about other files in my project? A: The codebase index hasn’t finished, or you didn’t inject context. Use @Files or @Code to explicitly bring in other files. Don’t assume Cursor reads the whole repo by default — it doesn’t.

Q: How do I roll back an AI edit I don’t like? A: Reject the diff before pressing Apply. If you already applied, use git — git restore <file> or your editor’s undo stack. Always work on a feature branch so a bad Apply is one command away from a clean state.

Q: Which model should I pick as the default? A: Claude Sonnet is the best price/performance default for daily edits. Switch to a stronger model (Opus or GPT-5) for hard refactors. Switch to a cheaper one for boilerplate.

Tags: #Cursor #AI coding

Related Articles