Từ lập trình cảm tính đến kỹ thuật thực tế

Có một câu chuyện đã trở nên quá quen thuộc trong cộng đồng lập trình viên năm 2026: một lập trình viên bắt đầu sử dụng trợ lý lập trình AI, năng suất tăng gấp 2-3 lần, mọi người đều vui vẻ. Rồi ba tháng sau, nhóm đó thử thêm một tính năng vào mã nguồn “có sự hỗ trợ của AI” và phát hiện ra:

• Lý luận rời rạc, không có cấu trúc rõ ràng.
• Các chức năng giống hệt nhau đến 80% nằm rải rác trong ba tệp khác nhau.
• Không có bài kiểm thử nào được thực hiện, hoặc các bài kiểm thử thực chất không kiểm tra bất cứ điều gì có ý nghĩa.
• Cùng một AI đó, khi được yêu cầu sửa đổi đoạn mã do chính nó viết ra, lại làm hỏng một thứ hoàn toàn khác.

Đây không phải là thất bại của AI. Đây là thất bại của quy trình làm việc . AI tác nhân là một công cụ vô cùng mạnh mẽ — nhưng giống như tất cả các công cụ mạnh mẽ khác, cách bạn sử dụng nó sẽ quyết định kết quả.

Cách diễn đạt đúng đắn đến từ kho lưu trữ shanraisshan/claude-code-best-practiceđã đạt vị trí số 1 trên GitHub Trending vào tháng 3 năm 2026, với phụ đề: “Từ lập trình cảm tính đến kỹ thuật tác nhân”. Sự khác biệt không nằm ở công cụ — mà là ở phương pháp sử dụng công cụ đó.

Trong bài viết này, chúng tôi sẽ đề cập đến những phương pháp thực tiễn tốt nhất mà bạn có thể áp dụng – dành cho cả lập trình viên cá nhân và nhóm – cùng với các kho lưu trữ GitHub đáng để nghiên cứu trực tiếp.

Trước khi đi sâu vào các phương pháp tốt nhất, đây là tổng quan nhanh về các công cụ phổ biến nhất:

CÔNG CỤ | PHÂN LOẠI | TỐT NHẤT CHO

Terminal-first | Claude Code, Codex CLI, OpenCode, Aider, Gemini CLI | Suy luận phức tạp, nhiều tệp tái cấu trúc, mã nguồn không quen thuộc
IDE-native | Cursor, Cline, Copilot, Windsurf, tích hợp RooCode | Công việc tính năng hàng ngày, IDE tích hợp, tự động hoàn thành nội tuyến.

Mã nguồn mở(BYOK/miễn phí) | OpenCode (172K ), Cline (63K), Aider (46K),Goose (48K) | kiểm soát BYOK, tính linh hoạt của mô hình, minh bạch chi phí

Mô hình phổ biến trong các nhóm sản xuất vào năm 2026: Codex hoặc Claude Code cho các tác vụ nặng về agent, Cursor hoặc Copilot cho việc hoàn thành mã trực tiếp, và một agent mã nguồn mở (OpenCode, Cline hoặc Aider) để tăng tính linh hoạt cho mô hình.

Cộng đồng lập trình viên luôn đánh giá Claude Code là công cụ mạnh mẽ nhất để giải quyết các vấn đề khó khăn: các lỗi đa tệp tinh vi, lập luận kiến ​​trúc và các cơ sở mã không quen thuộc. Nhiều nhóm sử dụng Cursor hoặc Copilot cho các công việc phát triển tính năng thường ngày và chuyển sang Claude Code khi gặp phải những vấn đề thực sự phức tạp.

Thực hành tốt nhất #1: Không bao giờ bắt đầu mà không có ngữ cảnh — Tạo một tập tin hướng dẫn

Đây là sự khác biệt cơ bản nhất giữa lập trình cảm xúc và kỹ thuật tác nhân.

Mọi công cụ trí tuệ nhân tạo (AI) chuyên nghiệp đều có cơ chế đọc hướng dẫn dự án từ một tập tin:

CÔNG CỤ | HƯỚNG DẪN | FILE
Claude Code CLAUDE.mdCode CLAUDE .md
CursorCon trỏ .cursorrules
Cline .clinerules
Codex CLI AGENTS.md
Aider .aider.conf.yml + prompt
GitHub Copilot .github /copilot-instructions.md

Quản lý cửa sổ ngữ cảnh là rất quan trọng: ở mức ngữ cảnh 70%, AI bắt đầu mất độ chính xác. Ở mức 85%, hiện tượng ảo giác tăng lên. Ở mức 90% trở lên, phản hồi trở nên không nhất quán. Chiến lược: 0–50% hoạt động tự do, 50–70% bắt đầu chú ý, 70–90% sử dụng chế độ thu gọn, 90% trở lên sử dụng chế độ xóa rõ ràng là bắt buộc.

Nguồn

Một CLAUDE.md mẫu bạn có thể sử dụng ngay bây giờ:

# [Tên Dự án] — Bối cảnh Tác nhân AI

## Ngăn xếp
– Backend: Laravel 13.x + PHP 8.4
– Frontend: React 18 + TypeScript 5, Tailwind CSS 3
– Cơ sở dữ liệu: PostgreSQL 16 + pgvector
– Xác thực: Laravel Sanctum
– Hàng đợi: Laravel Horizon + Redis

## Cấu trúc thư mục
– /app/Http/Controllers → chỉ định tuyến + phản hồi, không có logic nghiệp vụ
– /app/Services → tất cả logic nghiệp vụ nằm ở đây
– /app/Models → các mô hình Eloquent + phạm vi + mối quan hệ
– /app/Jobs → các tác vụ hàng đợi
– /tests/Feature → kiểm thử tính năng (sử dụng Pest)

## Chuẩn mực mã hóa
– Sử dụng kiểu dữ liệu nghiêm ngặt trong tất cả các tệp PHP: `declare(strict_types=1);`
– Yêu cầu kiểu trả về trên tất cả các phương thức
– Sử dụng camelCase cho biến, PascalCase cho lớp
– Tất cả các chuỗi hiển thị cho người dùng phải được xử lý qua __() để i18n
– Không sử dụng SQL thô ngoại trừ các truy vấn quan trọng về hiệu suất

## Cái gì Những điều KHÔNG NÊN làm
– Không bao giờ mã hóa cứng các thông tin bí mật – luôn sử dụng `env()`
– Không bao giờ sử dụng `dd()` hoặc `var_dump ()` trong mã sản xuất
– Không bao giờ tạo các tệp dài hơn 300 dòng – chia thành các module
– Không bao giờ cài đặt các phụ thuộc mới mà không có xác nhận
– Không bao giờ thay đổi lược đồ cơ sở dữ liệu mà không tạo migration

## Yêu cầu kiểm thử
– Mỗi tính năng mới phải có bài kiểm thử tính năng PEST
– Độ phủ tối thiểu 60% cho các lớp dịch vụ mới
– Chạy `php artisan test` trước khi hoàn thành

Cách làm việc
– Lập kế hoạch trước khi viết mã: giải thích cách tiếp cận của bạn, chờ phê duyệt
– Cam kết theo từng mốc nhỏ với các thông báo mô tả
– Nếu không chắc chắn, hãy hỏi – đừng giả định

Nguyên tắc thực hành tốt nhất #2: Lập kế hoạch trước, lập trình sau — Điều không thể thiếu đối với các nhiệm vụ phức tạp.

Đây là thực tiễn tốt nhất nhưng lại thường bị bỏ qua nhất và có tác động lớn nhất.

❌ QUY TRÌNH LẬP TRÌNH VIBE:
Yêu cầu → AI lập trình ngay lập tức →
bạn xem xét một loạt thay đổi →
có lỗi →
AI sửa lỗi, lại làm hỏng việc khác →
bạn lại sửa → vòng lặp vô tận…

✅ QUY TRÌNH KỸ THUẬT AGENTIC:
Yêu cầu → AI tạo kế hoạch →
bạn xem xét kế hoạch (nhanh chóng) →
phê duyệt → AI thực hiện từng bước →
xem xét từng bước → cam kết
Cách kích hoạt Chế độ lập kế hoạch
# Claude Code — kích hoạt chế độ lập kế hoạch
# Shift+Tab → chọn chế độ “Lập kế hoạch”

# Hoặc sử dụng lời nhắc rõ ràng:
“Trước khi viết bất kỳ dòng mã nào, hãy tạo một kế hoạch rõ ràng:
1. Những tệp nào sẽ được thay đổi và tại sao
2. Phương pháp triển khai từng bước
3. Các trường hợp ngoại lệ cần xử lý
4. Các bài kiểm thử cần viết

Không viết bất kỳ mã nào cho đến khi tôi chấp thuận kế hoạch.”
Mẫu nhắc nhở cho các nhiệm vụ phức tạp
Tôi muốn thêm [mô tả tính năng].

Trước khi lập trình:
1. Phỏng vấn tôi để làm rõ bất kỳ yêu cầu nào chưa rõ ràng

. 2. Tạo bản đặc tả bao gồm:
– Phương pháp kỹ thuật đề xuất
– Các tập tin sẽ được tạo/sửa đổi
– Thay đổi lược đồ cơ sở dữ liệu (nếu có)
– Các điểm cuối API mới (nếu có)
– Các bài kiểm thử cần viết

3. Chờ phê duyệt trước khi bắt đầu.
Công nghệ sử dụng: [công nghệ của bạn] Ràng buộc: [các ràng buộc của bạn] Cách tiếp cận được khuyến nghị: bắt đầu với một bản mô tả hoặc câu hỏi tối thiểu và yêu cầu AI phỏng vấn bạn, sau đó mở một phiên mới để thực hiện bản mô tả đó. Luôn luôn tạo một kế hoạch được phân chia theo từng giai đoạn, với mỗi giai đoạn có nhiều bài kiểm tra (kiểm tra đơn vị, tự động hóa, tích hợp). Chia nhỏ các tài liệu yêu cầu sản phẩm (PRD) thành các lát cắt dọc xuyên suốt tất cả các lớp.

Thực hành tốt nhất #3: Cam kết nhỏ và thường xuyên — Mạng lưới an toàn của bạn

Đây là biện pháp bảo vệ quan trọng nhất khi làm việc với các tác nhân AI. Như nhiều nhóm đã trải nghiệm một cách khó khăn — AI có thể tạo ra những thay đổi sâu rộng cùng một lúc mà bạn không hề nhận ra.

# ❌ KHÔNG NÊN: để AI làm việc trong thời gian dài mà không commit
# Sau 2 giờ → git add . → git commit -m “AI stuff”

# ✅ NÊN: commit theo từng mốc nhỏ
git add src/auth.js
git commit -m “feat(auth): add JWT token refresh [ai-assisted]”

# ✅ Gắn thẻ các commit liên quan đến AI để theo dõi kiểm toán
git commit -m “refactor(db): optimize user query [ai-assisted] – Changed N+1 query to eager loading
– Added database index on email column
– Reviewed and tested manually”

# ✅ Trước khi giao một nhiệm vụ lớn cho AI – hãy tạo một checkpoint
git stash # hoặc commit trạng thái hiện tại
# Giao nhiệm vụ cho AI
# Xem lại kết quả
# Nếu tốt: commit
# Nếu xấu: git checkout . (rollback)
Thiết lập một Hook tiền cam kết cho Cổng kiểm soát chất lượng
# .git/hooks/pre-commit — chạy tự động trước mỗi lần commit
#!/bin/sh

echo “Đang chạy kiểm tra trước khi commit…”

# PHP: chạy kiểm thử
php artisan test –stop-on-failure
if [ $? -ne 0 ]; then
echo “Kiểm thử thất bại. Commit bị hủy bỏ.”
exit 1
fi

# PHP: chạy phân tích tĩnh
./vendor/bin/phpstan analyse –level=6
if [ $? -ne 0 ]; then
echo “PHPStan thất bại. Sửa lỗi trước khi commit.”
exit 1
fi

# JavaScript: ESLint
npx eslint src/ –ext .ts,.tsx
if [ $? -ne 0 ]; then
echo “ESLint thất bại. Sửa lỗi trước khi commit.”
exit 1
fi

echo “Tất cả các kiểm tra đều đạt!”
exit 0

Thực hành tốt nhất #4: Xem xét mã AI như một lập trình viên cấp dưới viết yêu cầu kéo (PR)

Đây là sự thay đổi tư duy quan trọng nhất. AI không phải là một lập trình viên cấp cao mà bạn có thể hợp nhất sản phẩm đầu ra của anh ta mà không cần đọc. Hãy coi sản phẩm đầu ra của AI như một yêu cầu kéo (PR) từ một lập trình viên trẻ thông minh nhưng không hiểu bối cảnh kinh doanh của bạn.

Danh sách kiểm tra đánh giá mã AI
TRƯỚC KHI HỢP NHẤT/CHẤP NHẬN mã AI, hãy kiểm tra:

BẢO MẬT:
□ Có thông tin đăng nhập hoặc bí mật nào được mã hóa cứng không
? □ Dữ liệu đầu vào của người dùng đã được xác thực và làm sạch chưa
? □ Các truy vấn cơ sở dữ liệu có an toàn khỏi tấn công injection không ? □
Có kiểm tra ủy quyền trên tất cả các điểm cuối không? TÍNH

CHÍNH XÁC : □
Logic có chính xác cho tất cả các trường hợp ngoại lệ
không? □ Xử lý lỗi có toàn diện
không? □ Kiểu trả về có khớp với mong đợi không?

CHẤT LƯỢNG:
□ Có sự trùng lặp với mã hiện
có không? □ Mã này có thể kiểm thử được không?
□ Tên mã có rõ ràng và mô tả không?
□ Mã này có dễ hiểu sau 6 tháng nữa không?

HIỆU SUẤT:
□ Có truy vấn N+1 ẩn nào không?
□ Có vòng lặp nào có thể được tối ưu hóa không?
□ Các tài nguyên (kết nối, tệp, bộ nhớ) đã được đóng đúng cách chưa?

KIỂM THỬ:
□ Các bài kiểm thử có bao gồm trường hợp hoạt động bình thường không?
□ Các bài kiểm thử có bao gồm các trường hợp ngoại lệ và kịch bản lỗi không?
□ Các bài kiểm tra có thực sự kiểm tra logic, chứ không chỉ đơn thuần là “không mong đợi lỗi”?
Các gợi ý để thách thức trí tuệ nhân tạo
# Sau khi AI hoàn thành việc lập trình, hãy sử dụng lời nhắc này để đánh giá:
“Hãy xem lại đoạn mã bạn vừa viết với những câu hỏi sau:
1. Các lỗ hổng bảo mật tiềm ẩn nằm ở đâu?
2. Những trường hợp ngoại lệ nào chưa được xử lý?
3. Điều này có thể gây lỗi ở đâu trong môi trường sản xuất?
4. Điều gì có thể được đơn giản hóa?

Hãy thành thật – đừng chỉ nói rằng mã trông ổn.”

# Hoặc hãy mạnh tay hơn:
“Hãy chứng minh cho tôi thấy điều này hoạt động. Tạo một bản so sánh (diff) về những thay đổi và cho tôi xem
các bài kiểm thử chứng minh mỗi thay đổi hoạt động chính xác.”

Thực hành tốt nhất số 5: Kiểm tra là một bước sàng lọc — chứ không phải là một yếu tố thêm vào sau.

Độ phủ kiểm thử trung bình trong các dự án được viết bằng Vibe-coded chỉ khoảng 12%, so với 68% trong các codebase được viết theo phương pháp truyền thống. Và chi phí bảo trì mã AI có thể tăng 300% trong 18 tháng đầu tiên nếu không có độ phủ kiểm thử đầy đủ.

Cách tiếp cận hiệu quả nhất: yêu cầu AI viết các bài kiểm thử song song với quá trình triển khai .

# Gợi ý hiệu quả cho phát triển hướng kiểm thử với AI
“Triển khai [tính năng] với phương pháp kiểm thử trước:
1. Viết các bài kiểm thử lỗi trước (mô tả hành vi mong muốn)
2. Viết phần triển khai tối thiểu để các bài kiểm thử vượt qua
3. Tái cấu trúc nếu cần thiết

Đối với mỗi bài kiểm thử, hãy đảm bảo nó bao gồm:
– Trường hợp thành công
– Các trường hợp lỗi (đầu vào không hợp lệ, không tìm thấy dữ liệu, v.v.)
– Các trường hợp ngoại lệ có thể xảy ra trong thực tế”
// Các bài kiểm tra ví dụ được yêu cầu cùng với phần triển khai
// Tính năng: API Tạo bài đăng

it ( ‘tạo bài đăng thành công’ , function() {
$user = User :: factory ()-> create ();
$response = $this- > actingAs ( $user )
-> postJson ( ‘/api/posts’ , [
‘title’ => ‘Bài đăng thử nghiệm’ ,
‘content’ => ‘Kiểm tra nội dung đủ dài’ ,
]);
$response- > assertCreated ()
-> assertJsonPath ( ‘data.title’ , ‘Bài đăng thử nghiệm’ );
$this- > assertDatabaseHas ( ‘posts’ , [
‘title’ => ‘Bài đăng thử nghiệm’ ,
‘user_id’ => $user- >id,
]);
});

it ( ‘kiểm tra các trường bắt buộc’ , function () {
$user = User :: factory ()-> create ();
$response = $this -> actingAs ( $user )
-> postJson ( ‘/api/posts’ , []);
$response -> assertUnprocessable ()
-> assertJsonValidationErrors ([ ‘title’ , ‘content’ ]);
});

it ( ‘ngăn chặn việc tạo bài đăng chưa được xác thực’ , function () {
$this -> postJson ( ‘/api/posts’ , [ ‘title’ => ‘Test’ ])
-> assertUnauthorized ();
});
Thiết lập CI để đảm bảo chất lượng
# .github/workflows/quality.yml
name: Code Quality Gate

on: [ push , pull_request ] jobs:
quality:
runs-on: ubuntu-latest
steps:
– uses: actions/checkout@v4
– name: Setup PHP
uses: shivammathur/setup-php@v2
with:
php-version: ‘8.4’
– name: Install dependencies
run: composer install –no-dev
– name: Run tests with coverage
run: |
php artisan test –coverage –min=60
# Build fails if coverage < 60%
– name: Static analysis
run: ./vendor/bin/phpstan analyse –level=6
– name: Security audit
run: composer audit
– name: Detect code duplication
run: |
npx jscpd src/ –threshold 5
# Fails if duplication > 5%

Thực hành tốt nhất số 6: Quản lý bối cảnh — Duy trì chất lượng xuyên suốt buổi học

Đây là kỹ thuật ít được thảo luận nhất nhưng lại có tác động lớn nhất đến tính nhất quán của kết quả đầu ra của AI.

# Mã Claude — các lệnh quản lý ngữ cảnh
/clear # Đặt lại hoàn toàn ngữ cảnh — sử dụng khi chuyển đổi giữa các tác vụ chính
/compact # Nén ngữ cảnh trong khi vẫn giữ lại thông tin quan trọng
/compact tập trung vào việc triển khai xác thực, bỏ qua việc gỡ lỗi kiểm thử
/rewind # Quay lại trạng thái trước khi thực hiện thất bại (nhấn đúp Esc) #

Mẫu phiên được đề xuất:
# Phiên 1: Lập kế hoạch + đặc tả
# ↓ /clear
# Phiên 2: Triển khai tính năng A → cam kết
# ↓ /clear
# Phiên 3: Triển khai tính năng B → cam kết
# ↓ /clear
# (không phải một phiên dài rối rắm cho mọi thứ)
Dành cho con trỏ và dòng
# Cursor — mẹo ngữ cảnh:
– Sử dụng @file để tham chiếu các tệp cụ thể, đừng mở tất cả mọi thứ
– Chỉ sử dụng @codebase cho các truy vấn cấp cao, không phải mọi lời nhắc
– Bắt đầu một phiên mới cho các tác vụ thực sự khác nhau

# Cline – mẹo ngữ cảnh:
– Cline tích cực hơn trong việc đọc tệp – theo dõi việc sử dụng token
– Sử dụng .clinerules để giới hạn các tệp được phép đọc
– Đặt max_tokens cho mỗi tác vụ để kiểm soát chi phí

Thực hành tốt nhất #7: Đánh giá bằng AI kép — Tách biệt người viết và người đánh giá

Một mô hình cực kỳ hiệu quả: sử dụng một phiên bản AI để viết mã và một phiên bản hoàn toàn riêng biệt để xem xét mã đó. Một AI mới – không có bối cảnh từ quá trình viết mã – sẽ khách quan và phê bình hơn nhiều.

# Thiết bị đầu cuối 1 — AI với vai trò “nhà phát triển”
claude
> Triển khai quy trình thanh toán cho ứng dụng thương mại điện tử này.
[đã hoàn thành mã]

# Thiết bị đầu cuối 2 – AI mới với vai trò “người đánh giá cấp cao”
claude
> Bạn là một kỹ sư phần mềm cấp cao có khả năng phân tích.
Hãy xem xét việc triển khai quy trình thanh toán này, tập trung vào:
1. Các lỗ hổng bảo mật (đặc biệt là xử lý thanh toán)
2. Các điều kiện tranh chấp tiềm ẩn
3. Các trường hợp lỗi chưa được xử lý
4. Các vấn đề về hiệu suất
[dán mã từ Thiết bị đầu cuối 1]

# Hoặc trong một phiên duy nhất sau khi hoàn thành:
“Hãy xem lại mã bạn vừa viết như thể bạn là một
người đánh giá hoài nghi lần đầu tiên nhìn thấy nó. Xác định ít nhất 3 vấn đề tiềm ẩn, sau đó khắc phục chúng.”
Thực tiễn tốt nhất số 8: Chuẩn hóa trên toàn nhóm — CONVENTIONS.md
Đối với các nhóm sử dụng tác nhân AI cùng nhau, bạn cần một tập tin nằm trên cùng của tệp tin sau CLAUDE.md:

# QUY ƯỚC LẬP TRÌNH AI — Nhóm Kỹ thuật

## Các Quy tắc BẮT BUỘC cho Tất cả Đầu ra AI
### Trước khi AI Bắt đầu Một Tác vụ
– [ ] Đảm bảo CLAUDE.md / .cursorrules được cập nhật
– [ ] Tác vụ có vé/vấn đề với tiêu chí chấp nhận rõ ràng
– [ ] Nhánh đã được tạo: `feature/ticket-123-short-description`

### Trong Khi AI Đang Làm Việc
– [ ] Cam kết mọi mốc nhỏ – không để AI làm việc mà không có cam kết trong hơn 30 phút
– [ ] Xem lại mọi tệp AI thay đổi trước khi chuyển sang bước tiếp theo
– [ ] Nếu AI yêu cầu cài đặt một phụ thuộc mới – DỪNG lại và thảo luận với nhóm trước

### Trước Khi Đẩy / Yêu cầu Kéo
– [ ] php artisan test (tất cả đều xanh)
– [ ] php artisan test –coverage (tối thiểu 60%)
– [ ] ./vendor/bin/phpstan analyse (không có lỗi)
– [ ] composer audit (không có lỗ hổng nghiêm trọng)
– [ ] Xem xét thủ công từng tệp AI đã thay đổi – từng tệp một

### Trong Mô tả Yêu cầu Kéo – Bắt buộc
– Nêu rõ sự tham gia của AI: “Được triển khai với sự hỗ trợ của AI (Claude Code)”
– Phần nào do AI tạo ra so với phần nào được viết thủ công
– Các bài kiểm tra đã chạy và kết quả của chúng

## Những gì cần xem xét thủ công trước khi hợp nhất
– AI không thể đẩy trực tiếp vào nhánh main hoặc develop
– AI không thể sửa đổi các biến môi trường hoặc bí mật
– AI không thể tạo các migration mà không có đánh giá lược đồ
– AI không thể sửa đổi mã xác thực/bảo mật mà không có đánh giá bảo mật
Các kho lưu trữ GitHub đáng để nghiên cứu
Dựa trên dữ liệu mới nhất từ ​​GitHub và cộng đồng nhà phát triển:

1. shanraisshan/claude-code-best-practice— Xu hướng nổi bật số 1 trên GitHub, tháng 3 năm 2026
Liên kết: //github.com/shanraisshan/claude-code-best-practice

69 mẹo hữu ích thuộc 11 danh mục: Gợi ý, Lập kế hoạch, Ngữ cảnh, Phiên, CLAUDE.md + .claude/rules, Tác nhân, Lệnh, Kỹ năng, Hook, Quy trình làm việc, Git/PR, Gỡ lỗi. Được xây dựng với sự đóng góp từ Boris Cherny, kỹ sư đã xây dựng Claude Code tại Anthropic.

Những gì bạn sẽ học:
– Các mẫu CLAUDE.md đã được kiểm thử trong môi trường sản xuất
– Các kiểu nhắc nhở cho các tình huống khác nhau
– Cách thiết lập các lệnh slash tùy chỉnh (/plan, /review, /ship)
– Quy trình làm việc Git được thiết kế đặc biệt cho phát triển tác nhân
2.FlorianBruniaux/claude-code-ultimate-guide
Liên kết: //github.com/FlorianBruniaux/claude-code-ultimate-guide

Các trường hợp thực tế: Fountain (nhanh hơn 50%), Rakuten (hoạt động tự động 7 giờ), CRED (tốc độ gấp đôi), TELUS (tiết kiệm được 500.000 giờ). Dữ liệu nghiên cứu: 60% sử dụng AI, 0–20% ủy quyền hoàn toàn, số lượng yêu cầu kéo được hợp nhất mỗi ngày tăng 67%.

Những gì bạn sẽ học:
– Chiến lược quản lý cửa sổ ngữ cảnh
– Các mô hình ROI đa phiên bản
– Các mô hình phản tác dụng cần tránh trong doanh nghiệp
– Danh sách an toàn MCP và quy trình kiểm duyệt
3.VILA-Lab/Dive-into-Claude-Code
Liên kết: //github.com/VILA-Lab/Dive-into-Claude-Code

Phân tích có hệ thống mã Claude để thiết kế các hệ thống tác nhân AI hiện nay và trong tương lai. Bao gồm cấu trúc bên trong vòng lặp tác nhân, công cụ, tự động hóa thiết bị đầu cuối, hệ thống phân quyền theo cấp bậc và quy trình làm việc động.

Những điều bạn sẽ học:
– Cách thức hoạt động của vòng lặp tác nhân
– Mô hình phân quyền và các ràng buộc bảo mật
– Các mô hình quy trình làm việc động
– Các vấn đề về tuân thủ và an toàn
4.Piebald-AI/claude-code-system-prompts
Liên kết: //github.com/Piebald-AI/claude-code-system-prompts

Tất cả các lời nhắc hệ thống Claude Code, được cập nhật theo từng phiên bản: 27 mô tả công cụ tích hợp sẵn, lời nhắc tác nhân phụ (Lập kế hoạch/Khám phá/Nhiệm vụ), lời nhắc tiện ích (CLAUDE.md, nén, xem xét bảo mật, tạo tác nhân). Nhật ký thay đổi qua 211 phiên bản kể từ v2.0.14.

Những điều bạn sẽ học:
– Cách các tác nhân AI “suy nghĩ” từ góc nhìn của hệ thống
– Các mô hình tạo tác nhân và tổng hợp bộ nhớ
– Quy trình đánh giá bảo mật mà chính AI sử dụng
5. Aider-AI/aider— 46.000 sao
Liên kết: //github.com/Aider-AI/aider

Công cụ lập trình cặp đôi trên terminal đầu tiên hoạt động theo kiểu Git — mọi chỉnh sửa đều là một commit. Không phụ thuộc vào mô hình, hỗ trợ Claude, GPT-5, Gemini và Grok. 72% mã nguồn của Aider được chính Aider viết.

Những gì bạn sẽ học:
– Quy trình làm việc AI gốc Git được thực hiện đúng cách
– Cách kiểm tra các thay đổi AI thông qua lịch sử Git
– Chuyển đổi mô hình để tối ưu hóa chi phí
– Tài liệu tham khảo mã nguồn mở về lập trình tác nhân
6. opencode-ai/opencode— 172 nghìn sao (được đánh giá cao nhất)
Liên kết: //github.com/opencode-ai/opencode

Công cụ quản lý mã nguồn mở được đánh giá cao nhất năm 2026. Giấy phép MIT, hoạt động trên thiết bị đầu cuối, không phụ thuộc vào mô hình — hỗ trợ tất cả các nhà cung cấp LLM chính thông qua khóa API của riêng bạn.

Những điều bạn sẽ học:
– Cách triển khai một công cụ lập trình dựa trên tác nhân từ đầu
– Các mẫu kiến ​​trúc cho tác nhân AI
– Hệ thống plugin và khả năng mở rộng
– Quy trình làm việc dựa trên tác nhân tiết kiệm chi phí
Dấu hiệu cho thấy quy trình làm việc AI của bạn đang đi đúng hướng
DẤU HIỆU CỦA MỘT QUY TRÌNH LÀM VIỆC LÀNH MẠNH:
✅ Bạn có thể giải thích mọi thay đổi mà AI đã thực hiện — không có gì là “phép thuật”
✅ Độ phủ kiểm thử không giảm sau khi AI hoạt động
✅ Việc xem xét đầu ra của AI không mất nhiều thời gian hơn việc xem xét mã thông thường
✅ Mã do AI tạo ra tuân theo các quy ước đã có trong dự án
✅ Lịch sử commit dễ đọc và có ý nghĩa
✅ Khi AI mắc lỗi, bạn phát hiện ra trong vòng 15 phút

DẤU HIỆU CHO THẤY CÓ GÌ ĐÓ KHÔNG ỔN:
⚠️ Bạn đang hợp nhất mã AI mà không thực sự hiểu nó
⚠️ “Mã này hoạt động, nhưng tôi không biết tại sao”
⚠️ Các bài kiểm thử được viết sau khi tính năng được triển khai – hoặc không được viết
⚠️ Các phụ thuộc mới xuất hiện mà bạn không nhận thấy
⚠️ AI đã commit trực tiếp vào nhánh main
⚠️ Một phiên AI chạy hơn 2 giờ mà không có commit
Kết luận: Trí tuệ nhân tạo là yếu tố nhân rộng, chứ không phải là chế độ tự động.
Ví dụ dễ hiểu nhất để hình dung việc lập trình AI hướng đến tác nhân vào năm 2026 là một phi công với hệ thống lái tự động tiên tiến. Hệ thống lái tự động có thể xử lý hầu hết các thao tác bay — nhưng một phi công giỏi vẫn biết máy bay đang ở đâu, hướng đi của nó và khi nào cần điều khiển bằng tay.

Những nhà phát triển giỏi nhất năm 2026 không phải là những người thúc đẩy AI nhiều nhất. Họ là những nhà phát triển:

Hãy cung cấp ngữ cảnh phù hợp — AI hiểu mã nguồn, các tiêu chuẩn và các ràng buộc.
Lập kế hoạch trước khi lập trình — họ không giao phó các quyết định về kiến ​​trúc cho AI.
Xem xét kỹ lưỡng mọi kết quả đầu ra — họ coi kết quả đầu ra của AI giống như báo cáo PR của một lập trình viên cấp dưới.
Hãy thường xuyên thực hiện commit — luôn có điểm để hoàn tác.
Hãy sử dụng các bài kiểm thử như một cánh cổng — mã nguồn không có bài kiểm thử sẽ không được chấp nhận, bất kể ai là người viết ra nó.
Công cụ — Claude Code, Cursor, Cline, Codex, hay bất cứ công cụ nào khác — chỉ là thứ yếu. Quy trình làm việc và kỷ luật mới quyết định chất lượng sản phẩm đầu ra.

Hãy bắt đầu ngay hôm nay: tạo một CLAUDE.mdhoặc .cursorrulestrong dự án của bạn. Chỉ cần năm phút đầu tư sẽ giúp bạn tiết kiệm hàng giờ gỡ lỗi do đầu ra AI không nhất quán.

13 lệnh mã giúp rút ngắn chu kỳ phát triển của tôi xuống còn một nửa

hầu hết các nhà phát triển, bao gồm cả tôi, trong một thời gian đều sử dụng nó như một công cụ tìm kiếm thông minh hơn. Đặt câu hỏi. Nhận câu trả lời hoặc Viết mã. Chấp nhận/Tiếp tục.

Như vậy là bạn đã bỏ lỡ quá nhiều cơ hội, điều đó gần như là đáng tiếc.

Đây là 13 lệnh của Claude mà tôi sử dụng gần như hàng ngày để:

• đẩy nhanh quá trình lập kế hoạch
• giảm thời gian gỡ lỗi
• cải thiện chất lượng mã
• nén ngữ cảnh
• tránh ảo giác
• lặp lại nhanh hơn
• và suy nghĩ thấu đáo hơn trong quá trình phát triển

Một số là lệnh gạch chéo. Một số là mẫu lệnh. Tất cả đều là những thứ tôi sử dụnghàng ngày. Tôi sẽ chỉ cho bạn chúng là gì, tại sao chúng hoạt động và chính xác khi nào nên sử dụng chúng.

1. Tự động dọn dẹp các chi nhánh địa phương cũ
Lệnh:

Xóa các nhánh cục bộ không có trong kho lưu trữ từ xa — áp dụng cho tất cả các kho lưu trữ trong không gian làm việc, hoặc chỉ kho lưu trữ hiện tại .
Một trong những điều khó chịu nhất trong các dự án kéo dài là gì?

Các nhánh Git chết xuất hiện khắp nơi.

Sau nhiều tháng phát triển tính năng, kho lưu trữ cục bộ của bạn trở thành một nghĩa địa:

các thí nghiệm cũ
các nhánh tính năng được hợp nhất
các bản sửa lỗi bị bỏ rơi
công việc chạy nước rút cũ
Vì sao điều này lại mạnh mẽ
Thay vì thực hiện thủ công:

kiểm tra các chi nhánh
so sánh với điều kiện từ xa
xóa từng cái một
Claude có thể:

phân tích trạng thái kho lưu trữ
phát hiện các nhánh lỗi thời
tạo các lệnh dọn dẹp an toàn
tự động hóa quy trình làm việc
Điều này trở nên vô cùng hữu ích trong:

monorepos
hệ thống microfrontend
kiến trúc phụ trợ đa dịch vụ
cơ sở mã nguồn doanh nghiệp lớn
Lợi ích năng suất thực tế
Nghe có vẻ nhỏ.

Không phải. Đó là các hợp chất ma sát của chất phát triển.

Một không gian làm việc sạch sẽ sẽ cải thiện:

tốc độ điều hướng
sự minh mẫn về tinh thần
Sự tự tin của Git
hội nhập
hiệu suất cuối cùng
Những tự động hóa vận hành nhỏ tạo ra động lực rất lớn theo thời gian.

2. Chạy thử nghiệm + Kiểm tra độ phủ mã + Tự động sửa lỗi mọi thứ
Lệnh:

Chạy lệnh `npm test` với chức năng đo độ phủ mã. Phân tích các lỗi và vi phạm ngưỡng, sau đó tự động sửa các bài kiểm tra bị lỗi và bổ sung độ phủ mã còn thiếu cho đến khi tất cả các ngưỡng đều được đáp ứng .
Tại sao điều đó lại điên rồ?
Thông thường, quy trình kiểm thử sẽ diễn ra như sau:

Chạy thử nghiệm
Lỗi đọc
Sửa chữa thủ công
Chạy lại các bài kiểm tra
Kiểm tra phạm vi bảo hiểm
Bổ sung các bài kiểm tra còn thiếu
Lặp lại mãi mãi
Lệnh này nén toàn bộ vòng lặp.

Claude có thể:

kiểm tra các bài kiểm tra thất bại
hiểu logic sai lệch
khẳng định sửa chữa
tạo ra các trường hợp ngoại lệ bị thiếu
cải thiện phạm vi phủ sóng
tự động đáp ứng các ngưỡng
Điều này làm thay đổi tốc độ phát triển.
Việc kiểm tra không còn là:

một giai đoạn riêng biệt
một nhiệm vụ nhàm chán
hoặc điều gì đó bị hoãn lại đến “sau này”
Nó trở nên gắn liền với chính quá trình phát triển.

Đó là một sự thay đổi lớn về tư duy.

Đặc biệt hữu ích cho
Ứng dụng React
Các dự án Next.js
API Node.js
hệ thống giao diện người dùng doanh nghiệp
các cơ sở mã cũ
tái cấu trúc
Quy trình làm việc đơn giản này có thể tiết kiệm hàng giờ mỗi tuần.

3. Rút ngắn các phiên làm việc dài mà không làm mất mạch nội dung
Lệnh:

Tóm tắt những gì chúng ta đã thảo luận, rồi tiếp tục.
Các phiên làm việc với AI kéo dài cuối cùng sẽ trở nên hỗn loạn.

Bối cảnh ngày càng mở rộng.
Những quyết định quan trọng biến mất.
Các sợi chỉ bị mất dấu.
Vì vậy, lệnh này đã trở thành một trong những lệnh yêu thích của tôi.

Lý do nó hiệu quả
Claude nén lại:

quyết định kiến ​​trúc
tiến độ thực hiện
kết luận trước đó
các bộ chặn dòng điện
ngữ cảnh hoạt động
Sau đó tiếp tục mà không hề giảm tốc độ.

Về cơ bản là:

tối ưu hóa bộ nhớ phiên
ghi chú bàn giao cho nhà phát triển
và bảo tồn ngữ cảnh kết hợp
Đây là vàng trong thời gian này
tái cấu trúc lớn
thảo luận về thiết kế hệ thống
phiên gỡ lỗi
Lập trình cặp AI
quy hoạch kiến ​​trúc
Chỉ riêng lệnh này thôi đã cải thiện đáng kể quy trình làm việc của AI trong ngữ cảnh dài.

4. Loại bỏ câu trả lời dài 800 từ
Lệnh:

Nói ngắn gọn thôi . Nếu cần, tôi sẽ hỏi thêm.
Trí tuệ nhân tạo rất thích đọc luận văn. Còn các lập trình viên thì thường không.

Đôi khi bạn chỉ muốn:

giải pháp
lệnh
câu trả lời
nguyên nhân gốc rễ
Không còn gì khác.

Tại sao điều đó lại quan trọng
Thao tác này sẽ loại bỏ:

bông xốp
giải thích quá mức
những lời từ chối trách nhiệm lặp đi lặp lại
ví dụ không cần thiết
Và điều đó biến Claude thành một trợ lý kỹ thuật sắc bén hơn nhiều.

Cải tiến vượt bậc cho
gỡ lỗi
quy trình làm việc tại nhà ga
Sử dụng CLI
Thao tác Git
nhiệm vụ thực hiện nhanh chóng
Câu trả lời ngắn giúp tăng tốc độ thực thi.

Tốc độ thực thi rất quan trọng.

5. Trước tiên, hãy làm rõ những giả định tiềm ẩn.
Lệnh:

Trước khi trả lời, bạn đang giả định điều gì?
Điều này bị đánh giá thấp một cách oan uổng. Hầu hết các sản phẩm đầu ra tồi tệ của AI đều xuất phát từ những giả định ngầm.

Điều này mở ra điều gì?
Claude bắt đầu vạch trần:

thiếu ngữ cảnh
các phụ thuộc ẩn
những diễn giải không được nêu rõ
giả định về môi trường
các giả định khung
Điều này có nghĩa là:
bạn phát hiện ra lỗi trước khi quá trình thực hiện bắt đầu.

Ví dụ
Có lẽ Claude cho rằng:

bạn sử dụng TypeScript
bạn sử dụng App Router
Bạn đang triển khai lên Vercel
Bạn đang sử dụng PostgreSQL.
Bạn đang sử dụng Tailwind
Nhưng ngăn xếp của bạn thì khác.

Lệnh này sẽ ngay lập tức làm nổi bật những khoảng trống đó.

Đây là tư duy cấp cao.
Những kỹ sư giỏi luôn liên tục đặt câu hỏi về các giả định. Lệnh này dạy trí tuệ nhân tạo (AI) làm điều tương tự.

6. Buộc phải sử dụng lý luận trực quan trong các quyết định quan trọng.
Lệnh:

Hãy suy nghĩ thật kỹ trước khi đưa ra câu trả lời cuối cùng .
Điều này làm thay đổi cách Claude suy luận.

Vì sao nó lại mạnh mẽ
Thay vì chỉ đưa ra kết luận, Claude tiết lộ:

chuỗi lập luận của nó
sự đánh đổi
các con đường quyết định
logic kiến ​​trúc
luồng gỡ lỗi
Điều này trở nên vô cùng hữu ích trong các trường hợp sau:

lỗi khó
thiết kế cơ sở dữ liệu
tối ưu hóa hiệu suất
hệ thống phân tán
quyết định mở rộng quy mô
Lưu ý quan trọng
Bạn không nên sử dụng cái này cho mọi việc.

Nhưng đối với những nhiệm vụ kỹ thuật quan trọng thì sao?

Nó vô cùng quý giá.

Vì việc hiểu được lý do thường quan trọng hơn chính câu trả lời.

7. Thoát khỏi tầm nhìn hạn hẹp chỉ tập trung vào kết quả đầu tiên
Lệnh:

Hãy cho tôi ba phiên bản. Từ các góc độ khác nhau.
Sản phẩm đầu tiên hiếm khi là sản phẩm tốt nhất. Hầu hết các nhà phát triển đều dừng lại quá sớm.

Tại sao điều này lại quan trọng
Điều này phá vỡ thuyết định mệnh của trí tuệ nhân tạo.

Thay vì nhận được:

một kiến ​​trúc
một cách triển khai
một kiểu giải pháp
Bạn sẽ nhận được:

nhiều góc nhìn
các phương pháp cạnh tranh
các sự đánh đổi thay thế
Ví dụ về kết quả
Claude có thể tạo ra:

một giải pháp ưu tiên hiệu năng
một giải pháp ưu tiên khả năng bảo trì
giải pháp MVP nhanh chóng
Giờ đây bạn đang đưa ra các quyết định kỹ thuật thay vì chấp nhận kết quả một cách mù quáng.

Đó là một sự khác biệt rất lớn.

8. Hãy để Claude tự kiểm tra trước khi bạn làm.
Lệnh:

Bây giờ hãy tự phê bình những gì bạn vừa viết.
Lệnh này vô cùng hữu ích.

Chuyện gì xảy ra
Claude bắt đầu:

kiểm tra logic của chính nó
tìm các trường hợp ngoại lệ
phát hiện điểm yếu
xác định rủi ro
đặt câu hỏi về các lựa chọn kiến ​​trúc
Nó trở thành cả hai:

người thực hiện
và người đánh giá
Vì sao phương pháp này lại hiệu quả đến vậy
Hầu hết các lỗi của AI đều tồn tại vì không ai thách thức kết quả đầu ra. Điều này tạo ra một chu kỳ tự đánh giá tức thời.

Điều này cải thiện đáng kể:

độ tin cậy
chất lượng kiến ​​trúc
sẵn sàng sản xuất
mã an toàn
Điều này đặc biệt hữu ích trước:

triển khai
tái cấu trúc lớn
quyết định thiết kế API
thay đổi cơ sở hạ tầng
9. Hãy xây dựng một hình tượng nhất quán một lần và ngừng lặp lại chính mình.
Lệnh:

Trong toàn bộ cuộc trò chuyện này , bạn là [vai trò].
Việc nhắc nhở nhập vai bị đánh giá thấp một cách đáng kể.

Ví dụ
Bạn có thể biến Claude thành:

kỹ sư nhân viên cấp cao
Kiến trúc sư DevOps
chuyên gia hiệu suất
người đánh giá bảo mật
Giám đốc công nghệ (CTO) của công ty khởi nghiệp
nhà thiết kế sản phẩm
chuyên gia thử nghiệm
Tại sao điều này lại quan trọng
Các vai trò khác nhau tối ưu hóa cho các kết quả khác nhau.

MỘT:

Giám đốc công nghệ của công ty khởi nghiệp ưu tiên tốc độ
Kỹ sư an ninh ưu tiên sự an toàn.
Kỹ sư nhân viên ưu tiên khả năng mở rộng
Kỹ sư sản phẩm ưu tiên trải nghiệm người dùng (UX).
Kết quả đầu ra trở nên đồng nhất hơn đáng kể.

Điều này giúp loại bỏ sự lặp lại.
Thay vì lặp lại:
“Hãy hành động như…”

mỗi lời nhắc…

Bạn chỉ cần thiết lập ngữ cảnh cố định một lần. Cải thiện đáng kể quy trình làm việc.

10. Lặp lại mà không cần bắt đầu lại từ đầu
Lệnh:

Viết lại câu trả lời cuối cùng nhưng [ một thay đổi].
Tốc độ lặp lại quan trọng hơn là sự nhắc nhở hoàn hảo.

Vì sao điều này lại mạnh mẽ
Thay vì tạo lại mọi thứ từ đầu, bạn tinh chỉnh từng bước một.

Ví dụ:

“Hãy viết lại đoạn này theo cách đơn giản hơn.”
“Hãy viết lại phần này sao cho người mới bắt đầu dễ hiểu hơn.”
“Hãy viết lại đoạn mã này bằng TypeScript.”
“Hãy viết lại đoạn mã này bằng Prisma.”
“Hãy viết lại sao cho phù hợp hơn với môi trường sản xuất.”
Điều này tạo ra sự hợp tác thực sự.
Bạn hãy ngừng đối xử với AI như:

một máy bán hàng tự động
Và hãy bắt đầu đối xử với nó như thế này:

một đối tác kỹ thuật sáng tạo
Sự thay đổi về tư duy đó sẽ thay đổi mọi thứ.

11. Hãy yêu cầu sự thật khó chịu
Lệnh:

Hãy cho tôi câu trả lời theo cách khó chịu hơn .
Trí tuệ nhân tạo thường ưu tiên ngoại giao. Kỹ thuật thực tế thường đòi hỏi sự thẳng thắn đến tàn nhẫn.

Tại sao các nhà phát triển cần điều này?
Đôi khi bạn cần Claude nói rằng:

Kiến trúc của bạn được thiết kế quá phức tạp.
Ý tưởng khởi nghiệp của bạn thiếu tính khác biệt.
Thiết kế API của bạn rất dễ bị lỗi.
Kế hoạch mở rộng quy mô của bạn sẽ không hiệu quả.
Sự trừu tượng của bạn là không cần thiết
Và thành thật mà nói? Những câu trả lời đó thường là những câu trả lời có giá trị nhất.

Điều này giúp cải thiện chất lượng quyết định.
Vì câu trả lời an toàn nhất không phải lúc nào cũng là câu trả lời hữu ích nhất.

12. Kiểm tra kỹ lưỡng mọi giả định trước khi thực hiện.
Lệnh:

Hãy đánh dấu mọi giả định mà bạn đã đưa ra.
Lệnh này giúp cải thiện tư duy kỹ thuật.

Tại sao điều đó lại quan trọng
Những hệ thống tốt cũng thất bại vì những giả định ngầm.

Lệnh này buộc phải suy nghĩ rõ ràng về:

cơ sở hạ tầng
tỉ lệ
độ trễ
môi trường
xác thực
bộ nhớ đệm
đồng thời
triển khai
Điều này cực kỳ hữu ích cho
đánh giá kiến ​​trúc
hệ thống sản xuất
logic phụ trợ do AI tạo ra
hệ thống phân tán
kế hoạch mở rộng
Nó giúp giảm thiểu đáng kể các điểm mù.

13. Lệnh chỉnh sửa mạnh mẽ nhất mà bạn chưa sử dụng
Lệnh:

Bây giờ hãy thu ngắn nó xuống còn một nửa .
Một trong những lệnh chỉnh sửa tốt nhất từ ​​trước đến nay.

Tại sao phương pháp này lại hiệu quả đến vậy?
Các nhà phát triển thường đánh giá thấp:

sự rõ ràng
ngắn gọn
mật độ tín hiệu
Hầu hết các lời giải thích sẽ dễ hiểu hơn khi được tóm gọn lại.

Lệnh này dùng để làm sắc nét:

tài liệu
ghi chú kiến ​​trúc
Mô tả PR
Kết quả đầu ra của AI
tài liệu hướng dẫn hội nhập
viết blog
Siêu năng lực tiềm ẩn
Nó dạy bạn biết trân trọng:

độ chính xác hơn khối lượng
sự rõ ràng hơn là sự phức tạp
Đó là phẩm chất của một kỹ sư kỳ cựu.

Bài học thực sự ở đây không phải là về Claude.
Vấn đề cốt lõi là giao tiếp.

Những nhà phát triển giỏi nhất trong kỷ nguyên AI đang học hỏi:

cách hướng dẫn AI
cách thức hình thành tư duy
cách rút gọn quy trình làm việc
cách lặp lại nhanh chóng
Cách tư duy phản biện với máy móc
Những mệnh lệnh này không phải là phép thuật. Chúng là đòn bẩy. Và đòn bẩy chính là cách mà các nhóm nhỏ hiện nay xây dựng nên những thứ khổng lồ.

Lời kết
Đa số các nhà phát triển vẫn đang sử dụng AI một cách hời hợt. Trong khi đó, các kỹ sư hàng đầu đang xây dựng:

quy trình làm việc
hệ thống chỉ huy
các mẫu AI có thể tái sử dụng
vòng lặp suy luận tự động
Khoảng cách đó sẽ ngày càng lớn hơn.

Bạn không cần:

gợi ý hoàn hảo
Hướng dẫn kỹ thuật nhanh 400 trang
hoặc các khuôn khổ phức tạp
Bạn chỉ cần một vài mệnh lệnh có sức ảnh hưởng lớn và tích lũy theo thời gian. Hãy bắt đầu với 13 mệnh lệnh này. Bạn sẽ cảm nhận được sự khác biệt gần như ngay lập tức.