title: "AI-Native Workflow: Cấu hình môi trường dev (Cursor/Zed, Copilot, Cline, Windsurf)"
series: "AI-Native Solutions Architect: Từ Coder đến Kiến trúc sư AI"
season: "Season 1 — AI-Native Coding & Tooling"
order: 1
audience: "Software Engineer hướng tới Solutions Architect"
reading_time: "12 phút"
tags:

• ai-native-workflow
• cursor
• zed
• github-copilot
• cline
• windsurf
• dev-environment
• agent-mode

AI-Native Workflow: Cấu hình môi trường dev (Cursor/Zed, Copilot, Cline, Windsurf)

Bạn đã dùng AI code assistant được vài tháng, thậm chí cả năm. Autocomplete gợi ý đúng tên biến, tự hoàn thành vòng lặp for, viết hộ một hàm helper khi bạn gõ comment mô tả. Năng suất có tăng — nhưng nếu thành thật, nó vẫn là một chiếc bàn phím gõ nhanh hơn, không phải một đồng nghiệp làm việc cùng bạn.

Vấn đề không nằm ở model. GPT-4-class hay Claude-class hiện tại thừa sức đọc một ticket Jira, tự vạch kế hoạch sửa 5 file, chạy test, và tự sửa lỗi nếu test fail. Vấn đề nằm ở chỗ: phần lớn kỹ sư vẫn dùng công cụ AI ở cấu hình mặc định, ở chế độ inline-suggestion, và chưa từng bật lên chế độ agent — nơi AI thực sự lập kế hoạch, thực thi nhiều bước, và tự kiểm tra kết quả. Cấu hình môi trường dev sai cách là lý do lớn nhất khiến AI dừng lại ở mức "autocomplete nâng cao".

Bài này không nói AI sẽ thay đổi mọi thứ. Bài này nói cụ thể: môi trường dev của bạn cần được cấu hình như thế nào để một agent AI thực sự hữu ích, khi nào một công cụ phù hợp hơn công cụ khác, và checklist 5 phút để bắt đầu đúng ngay từ dự án tiếp theo.

Vấn đề

Ba năm trước, "dùng AI để code" đồng nghĩa với Copilot gợi ý dòng tiếp theo trong lúc gõ. Đó là mô hình "reactive suggestion" — AI phản ứng với con trỏ chuột, không có khái niệm về mục tiêu tổng thể của task. Nó không biết bạn đang sửa bug, refactor, hay viết feature mới; nó chỉ đoán token tiếp theo hợp lý nhất dựa trên vài trăm dòng context xung quanh.

Thế hệ công cụ hiện tại (2024-2026) chuyển sang mô hình khác hẳn: "agentic execution". Bạn mô tả mục tiêu bằng ngôn ngữ tự nhiên — "thêm rate limiting cho endpoint /api/orders, dùng Redis, giới hạn 100 req/phút/user" — và agent tự:

1. Đọc codebase để tìm các file liên quan (middleware, config Redis hiện có, route định nghĩa endpoint).
2. Lập kế hoạch thay đổi (tạo guard mới, đăng ký ở module nào, cần migration hay không).
3. Viết code, chạy lint/test, đọc log lỗi và tự sửa nếu fail.
4. Trình bày diff để bạn review, không tự ý commit.

Sự khác biệt về chất lượng giữa hai mô hình này không nằm ở model — cùng một model, chạy ở chế độ "chat trả lời một câu hỏi" và chế độ "agent với quyền đọc/ghi file, chạy lệnh terminal" cho kết quả khác nhau hoàn toàn về mức độ hữu ích. Rất nhiều kỹ sư cài Cursor hoặc Copilot, dùng nó y hệt cách dùng IntelliSense 10 năm trước, rồi kết luận "AI chỉ hữu ích cho code boilerplate". Đó là kết luận đúng — với cách cấu hình sai.

Cạm bẫy thứ hai: mỗi công cụ có một triết lý thiết kế khác nhau, và không có công cụ nào "tốt nhất" một cách tuyệt đối. Một kỹ sư solo làm side project khác hoàn toàn nhu cầu với một senior engineer trong team 40 người trên một monorepo 500k dòng code. Việc chọn công cụ theo trend Twitter/X mà không đối chiếu với đặc thù team là một sai lầm cấu hình ở tầm cao hơn: sai lầm về mặt tổ chức, không chỉ về mặt kỹ thuật.

Kỹ thuật cốt lõi

Ba trục thiết kế phân biệt các công cụ AI-native

Trước khi so sánh từng công cụ, cần một khung để đánh giá khách quan. Ba trục quan trọng nhất:

flowchart LR
    A[Mức độ tích hợp vào editor] --> A1["Fork toàn bộ IDE<br/>(Cursor, Windsurf)"]
    A --> A2["Extension trên VS Code<br/>(Copilot, Cline)"]
    A --> A3["Editor riêng từ đầu<br/>(Zed)"]

    B[Mức độ tự trị] --> B1["Suggestion-only<br/>(autocomplete)"]
    B --> B2["Chat có context<br/>(hỏi-đáp)"]
    B --> B3["Agent tự thực thi<br/>(đa bước, đa file, chạy lệnh)"]

    C[Mô hình quan hệ con người-AI] --> C1["AI là công cụ gợi ý"]
    C --> C2["AI là cộng tác viên đồng bộ thời gian thực"]
    C --> C3["AI là agent nhận task, làm việc độc lập"]

• Trục 1 — Tích hợp: fork toàn bộ IDE (Cursor, Windsurf) cho phép AI can thiệp sâu vào mọi lớp — file tree, terminal, git, debugger — nhưng đánh đổi bằng việc bạn phụ thuộc vào roadmap của một sản phẩm đóng thay vì hệ sinh thái mở của VS Code. Extension trên nền VS Code (Copilot, Cline) giữ nguyên toàn bộ hệ sinh thái extension bạn đã quen, nhưng bị giới hạn bởi API extension mà VS Code cho phép. Zed đi hướng khác: viết lại editor từ đầu bằng Rust để tối ưu hiệu năng và tích hợp AI/collaborative editing như tính năng gốc, không phải lớp vá thêm.

• Trục 2 — Mức độ tự trị: đây là trục quan trọng nhất và cũng là trục bị bỏ qua nhiều nhất. Một công cụ có thể hỗ trợ cả ba mức nhưng người dùng chỉ khai thác mức 1. Chế độ agent (mức 3) là nơi giá trị thực sự nằm — nhưng cũng là nơi rủi ro cao nhất (agent có thể sửa sai file, chạy lệnh không mong muốn) nên đòi hỏi cấu hình quyền hạn (permission) cẩn thận.

• Trục 3 — Mô hình quan hệ: Cline và các agent tự trị coi AI như một "junior engineer" nhận task rồi tự làm, báo cáo lại. Cursor Composer/Agent mode và Windsurf Cascade nằm giữa — bạn giám sát theo từng bước hoặc từng nhóm bước. Zed's collaborative AI nghiêng về mô hình "pair programming" đồng bộ, AI và người cùng nhìn một buffer.

So sánh 5 công cụ theo triết lý thiết kế

Lưu ý quan trọng: bảng trên mô tả triết lý thiết kế, không phải bảng tính năng cố định — các công cụ này cập nhật liên tục, tính năng của công cụ A hôm nay có thể xuất hiện ở công cụ B tháng sau. Điều ổn định hơn nhiều là triết lý nền tảng: Cursor/Windsurf đặt cược vào việc sở hữu toàn bộ editor để tối ưu trải nghiệm AI; Copilot đặt cược vào việc phổ cập không ma sát; Cline đặt cược vào minh bạch và kiểm soát; Zed đặt cược vào hiệu năng thuần và collaborative editing.

Thực hành

Phần này hướng dẫn setup cụ thể với Cursor làm ví dụ đại diện (phổ biến nhất, đại diện tốt cho mô hình "fork IDE + agent mode tích hợp sâu"). Nguyên lý tương tự áp dụng được sang Windsurf hoặc Cline với thay đổi nhỏ về vị trí menu.

Bước 1 — Bật Agent mode (Composer) đúng cách

Mặc định, Cursor mở ra ở chế độ Chat (hỏi-đáp, không tự sửa file). Để agent thực sự tự trị:

1. Mở panel AI bằng Cmd/Ctrl + I (Composer/Agent).
2. Chọn chế độ Agent (không phải Ask) — chế độ Agent cho phép AI tự đọc nhiều file, tự chạy terminal command, tự áp diff nhiều file cùng lúc.
3. Kiểm tra phần quyền hạn (thường ở settings Cursor > Features > Agent): bật Auto-run terminal commands chỉ cho các lệnh an toàn (lint, test, build), tắt cho lệnh có tác dụng phụ (git push, rm, deploy script).

Bước 2 — Cấu hình model theo loại task

Đừng dùng một model cho mọi việc. Cấu hình gợi ý (menu chọn model trong Composer):

• Task đơn giản, autocomplete, sửa 1 file nhỏ: model nhanh/rẻ hơn (ví dụ nhóm "mini"/"flash"-class) — độ trễ thấp quan trọng hơn khả năng suy luận sâu.
• Task kiến trúc, refactor nhiều file, debug logic phức tạp: model reasoning mạnh nhất bạn có quyền truy cập — chấp nhận độ trễ cao hơn để đổi lấy chất lượng plan.
• Review diff trước khi merge: dùng một model khác với model đã viết code, để tránh "self-review bias" — model tự review code do chính nó viết thường bỏ sót lỗi nó tự mắc phải.

Bước 3 — Keyboard shortcut cho các thao tác dùng nhiều nhất

Thiết lập trong Cursor Settings > Keyboard Shortcuts, ví dụ một bộ mapping hợp lý:

// keybindings.json — ví dụ mapping thực dụng cho Cursor
[
  {
    "key": "cmd+i",
    "command": "composer.startComposerPrompt",
    "when": "editorTextFocus"
  },
  {
    "key": "cmd+k",
    "command": "editor.action.inlineEdit",
    "when": "editorTextFocus"
  },
  {
    "key": "cmd+shift+l",
    "command": "composer.addSelectionToChat",
    "when": "editorHasSelection"
  },
  {
    "key": "cmd+shift+enter",
    "command": "composer.acceptAllChanges",
    "when": "composerHasDiff"
  },
  {
    "key": "cmd+shift+backspace",
    "command": "composer.rejectAllChanges",
    "when": "composerHasDiff"
  }
]

Nguyên tắc: thao tác nào bạn lặp lại trên 10 lần/ngày (mở agent, chọn selection đưa vào chat, accept/reject diff) phải có shortcut một tay, không qua menu.

Bước 4 — Prompt mẫu để khởi động agent đúng cách (thay vì hỏi mơ hồ)

Prompt yếu, dựa vào suy đoán:

Sửa lỗi validate email trong form đăng ký

Prompt đủ context để agent lập kế hoạch thay vì đoán mò:

Bug: endpoint POST /api/auth/register chấp nhận email không hợp lệ dạng
"user@@domain..com" (nên bị từ chối 400).

Yêu cầu:
1. Tìm DTO validate hiện tại của endpoint này (khả năng ở modules/auth/dto).
2. Thêm rule validate email nghiêm ngặt hơn bằng class-validator
   (@IsEmail với option cho phép domain có nhiều subdomain nhưng chặn
   ký tự lặp bất thường như "..").
3. KHÔNG tự viết regex tay — dùng decorator/thư viện sẵn có của
   class-validator nếu đủ, chỉ viết custom validator nếu class-validator
   không đủ mạnh.
4. Viết lại/thêm unit test cho case email hợp lệ và 3 case email
   không hợp lệ (bao gồm case double-dot ở trên).
5. Chạy `pnpm test` sau khi sửa, dán lại output test.
6. Không tự commit — dừng lại ở diff để tôi review.

Khác biệt cốt lõi: prompt thứ hai cho agent (a) vị trí bắt đầu tìm kiếm, (b) ràng buộc kỹ thuật cụ thể (không tự chế regex), (c) tiêu chí nghiệm thu rõ ràng (test case cụ thể), (d) giới hạn quyền hạn (không tự commit). Đây chính là nơi "prompt engineering" gặp "cấu hình môi trường" — công cụ tốt mà prompt mơ hồ vẫn cho kết quả tệ.

Checklist "5 phút setup" cho dự án mới

Chạy checklist này ngay khi mở một repo mới trong Cursor (hoặc công cụ tương đương):

• Bật Agent mode, kiểm tra danh sách lệnh terminal được auto-run — loại bỏ mọi lệnh có tác dụng phụ nguy hiểm (push, deploy, migrate trên production).
• Xác nhận index codebase đã chạy xong (Cursor cần index để agent tìm file liên quan chính xác — với repo lớn việc này mất vài phút, đừng bắt đầu prompt agent khi đang index dở).
• Set model mặc định cho Composer là model reasoning mạnh nếu đây là monorepo phức tạp; model nhanh nếu là project nhỏ/prototype.
• Bind 3 shortcut cốt lõi: mở agent, accept diff, reject diff.
• Kiểm tra file .gitignore đã loại trừ thư mục cache của công cụ AI (ví dụ .cursor/, tránh commit nhầm state cục bộ).
• Thử một prompt "khảo sát" trước khi giao task thật: "Tóm tắt kiến trúc thư mục src/, liệt kê 5 module chính và trách nhiệm của mỗi module" — đây là bài kiểm tra nhanh xem agent đã "hiểu" codebase đến đâu (bài 2 của series sẽ đào sâu kỹ thuật để cải thiện bước này).

Checklist này cố tình ngắn — mục tiêu là loại bỏ ma sát ban đầu, không phải xây một quy trình nặng nề. Với team, checklist này nên nằm trong file onboarding, không phải kiến thức truyền miệng.

Cạm bẫy thường gặp

1. Dùng chế độ mặc định rồi kết luận "AI chưa đủ tốt". Đây là cạm bẫy phổ biến nhất. Rất nhiều đánh giá tiêu cực về AI coding tool thực chất là đánh giá về autocomplete — vì người dùng chưa từng bật agent mode, chưa từng viết prompt có ràng buộc kỹ thuật rõ ràng, và chưa từng cấu hình quyền hạn để agent tự chạy test/lint. So sánh công bằng phải là: agent mode, prompt tốt, quyền hạn hợp lý — so với chính bạn tự làm task đó.

2. Chọn công cụ theo trend thay vì theo đặc thù team. Một startup 3 người dùng Cline vì thích sự minh bạch tuyệt đối của từng lệnh terminal là hợp lý — nhưng áp cùng công cụ đó cho một team 50 kỹ sư sẽ tạo ra 50 cấu hình permission khác nhau, không ai kiểm soát được rủi ro tổng thể. Ngược lại, một agency làm nhiều dự án nhỏ, thay đổi codebase liên tục, có thể thấy Windsurf's task-oriented Cascade phù hợp hơn Cursor's codebase-deep-index vì mỗi dự án chỉ dùng một thời gian ngắn, không cần đầu tư index sâu. Câu hỏi đúng không phải "công cụ nào hot nhất" mà là "team tôi cần mức độ tự trị nào, mức độ minh bạch nào, và có sẵn sàng đánh đổi gì để lấy tốc độ".

3. Agent mode không đồng nghĩa "tắt não review". Agent tự chạy test và test pass không có nghĩa là logic đúng — test có thể thiếu case, hoặc agent có thể "sửa" test cho khớp với code sai thay vì sửa code cho đúng với yêu cầu. Luôn đọc diff, không chỉ đọc "test đã pass". Đây là lý do bước 6 trong prompt mẫu ở trên yêu cầu agent dừng lại chờ review, không tự commit — kỷ luật này quan trọng hơn công cụ bạn chọn.

🧭 Góc nhìn Solutions Architect
Khi đánh giá một công cụ AI-native cho team, tôi tự hỏi: (1) Nếu agent này chạy sai trên production codebase, blast radius lớn đến đâu — và cấu hình quyền hạn hiện tại có giới hạn được nó không? (2) Chi phí chuyển đổi editor/workflow của cả team có tương xứng với lợi ích tăng năng suất đo được, hay tôi đang chọn vì FOMO? (3) Công cụ này có tạo ra một "single point of dependency" mới (khoá vào một IDE đóng, một nhà cung cấp) mà tôi cần cân nhắc trong quyết định kiến trúc dài hạn của team?

🔗 Bài viết liên quan

• Context Engineering: .cursorrules & Codebase Map — đào sâu phần "làm sao AI hiểu đúng dự án" mới chỉ nhắc sơ ở bài này.
• Advanced Prompting: Chain-of-Thought tốt hơn ReAct — kỹ thuật viết prompt nâng cao để khai thác tối đa chế độ agent vừa cấu hình xong.

Bài tiếp theo: Context Engineering: .cursorrules & Codebase Map