Có một buổi sáng mình ngồi đếm: trong 5 lần mở Claude gần nhất, cả 5 lần mình đều mở đầu bằng câu "Mình là Steve, làm marketing, viết cho người đi làm Việt Nam, giọng văn xưng mình gọi bạn, đừng sáo rỗng...". Copy đúng một đoạn giới thiệu, dán đi dán lại. Rồi dán thêm bài viết mẫu để nó bắt được văn phong. Rồi nhắc lại đừng dùng emoji vô tội vạ.
Mỗi lần như vậy mất chừng 3-5 phút chỉ để "làm nóng máy". Nhân với chục lần một ngày, nhân với cả tháng — đó là một đống thời gian mình vứt đi chỉ vì AI không nhớ mình là ai.
Project trong Claude sinh ra để dẹp đúng cái nỗi đau đó. Bài này mình chỉ bạn cách setup một lần rồi dùng mãi, kèm 2 ví dụ prompt + output thật mình đang chạy, và quan trọng nhất — những lúc Project làm chậm việc thay vì nhanh hơn, để bạn né.
Bài dành cho: người đã dùng Claude (hoặc ChatGPT) kha khá, thấy mình lặp lại việc "mồi context" mỗi ngày, và muốn hệ thống hóa nó lại.
Phân biệt trước cho khỏi rối: Cowork, Project, Claude Code
Ba từ này hay bị dùng lẫn, mình tách rõ ngay từ đầu để bạn khỏi hiểu nhầm:
- Claude (chat thường): cửa sổ hội thoại đơn lẻ. Đóng lại là quên. Mỗi conversation là một tờ giấy trắng.
- Project: một "phòng làm việc" trong Claude. Bạn set sẵn hướng dẫn (custom instructions) và nạp tài liệu tham khảo vào đó. Mọi conversation tạo bên trong Project đều tự động thừa hưởng cái context này. Đây là thứ bài viết đang nói tới.
- Claude Cowork: chế độ làm việc cộng tác — bạn giao cho Claude một tác vụ nhiều bước, nó tự chạy tools, đọc file, tạo file trong một môi trường có sẵn. Project thường là nơi bạn đặt các phiên Cowork để chúng có chung bộ nhớ.
- Claude Code: công cụ dòng lệnh (terminal) để Claude làm việc trực tiếp trên codebase của bạn. Khác hẳn — cái này cho lập trình.
Nói gọn: Project = bộ nhớ dùng chung. Cowork = cách làm việc nhiều bước. Code = công cụ cho dev. Bài này tập trung vào Project, vì nó là thứ ai cũng dùng được, không cần biết code.
Project thực chất giải quyết cái gì
Bản chất Project không phải phép màu. Nó chỉ làm một việc: giữ lại phần context mà bạn phải gõ lại mỗi lần, và tự động chèn vào đầu mọi cuộc trò chuyện.
Ba thứ bạn nạp vào một Project:
- Custom instructions — "Claude, trong phòng này bạn luôn là X, viết theo giọng Y, tránh Z". Set một lần.
- Knowledge (tài liệu) — brand guideline, bài viết mẫu, bảng giá, tài liệu kỹ thuật... Claude đọc và tra khi cần.
- Các conversation cùng chủ đề — nằm chung một chỗ, dễ tìm lại.
Khác biệt so với chat thường, mình thấy rõ nhất ở 3 điểm này (đây là quan sát từ trải nghiệm của mình, không phải số liệu đo lường):
| Tiêu chí | Chat thường | Project |
|---|---|---|
| Bộ nhớ context | Gõ lại mỗi lần | Set một lần, tự áp dụng |
| Giọng văn / style | Phải dán bài mẫu lại | Đọc từ knowledge có sẵn |
| Tìm lại việc cũ | Lục lịch sử mỏi mắt | Gom trong một Project |
Mình cố tình không đưa con số kiểu "chính xác 60% lên 98%" như bản cũ của bài này từng viết — vì thật ra chẳng ai đo được cái đó một cách nghiêm túc, và mình không muốn bịa cho ra vẻ khoa học. Cái bạn cảm nhận được là: bớt lặp lại, đỡ mệt đầu, và output ra đúng "chất" hơn ngay từ lần đầu. Vậy là đủ đáng làm rồi.
Setup một Project trong khoảng 15 phút
Bước 1 — Tạo Project (1 phút)
Mở Claude, ở thanh bên trái chọn Projects → New Project (hoặc dấu +). Đặt tên rõ ràng theo mục đích, ví dụ "Viết bài blog Steve" chứ đừng đặt "Project 1".
Nếu bạn đang có một conversation đang chạy ngon và muốn Claude nhớ luôn nó, mở menu của conversation đó và chọn thêm vào Project.
Bước 2 — Viết custom instructions (8 phút)
Đây là phần quyết định 80% chất lượng. Đừng viết chung chung kiểu "hãy giúp tôi viết hay". Hãy viết cụ thể như đang onboard một nhân viên mới. Khung mình dùng:
## Vai trò
Bạn viết thay cho Steve — làm marketing 16 năm, dạy AI thực chiến
cho người đi làm Việt Nam.
## Giọng văn
- Xưng "mình", gọi người đọc là "bạn".
- Chân thành, thẳng, cụ thể. Không guru, không sáo rỗng.
- Không nhồi emoji.
## Ràng buộc bắt buộc
1. Không bịa số liệu. Nếu là ước lượng thì ghi rõ "theo trải nghiệm của mình".
2. Mỗi bài phải có ít nhất 1 ví dụ prompt cụ thể + mô tả output mẫu.
3. Định nghĩa thuật ngữ ở lần đầu xuất hiện.
4. Không hứa thu nhập phi thực tế.
## Khi không chắc
Hỏi lại mình trước khi viết, đừng đoán bừa rồi viết cả bài sai hướng.
Mẹo: ràng buộc "khi không chắc thì hỏi lại" cực kỳ đáng giá. Nếu thiếu dòng này, Claude sẽ tự bịa giả định rồi viết một bài dài dựa trên giả định sai — bạn phải đọc hết mới phát hiện.
Bước 3 — Nạp tài liệu vào Knowledge (5 phút)
Upload những file Claude cần để "hiểu bạn": 2-3 bài viết mẫu tốt nhất (để bắt văn phong), brand guideline, bảng thuật ngữ riêng, hoặc file dữ liệu bạn hay tra. Đừng nạp cả kho — nạp thứ tinh túy nhất. Mình sẽ nói kỹ lý do ở mục pitfall bên dưới.
Ví dụ thực chiến 1 — Project viết bài blog
Sau khi setup xong Project "Viết bài blog Steve" như trên, mình chỉ cần gõ một prompt ngắn, không cần dán lại giới thiệu hay bài mẫu:
Viết mở bài (hook) cho bài "Cách dùng Claude Project cho dân văn phòng".
Tình huống đau: mỗi sáng mở chat lại phải giải thích lại từ đầu.
3-4 câu, đúng giọng của mình.
Output mẫu Claude trả về (nhờ đã đọc instructions + bài mẫu trong knowledge):
Có một việc mình làm mỗi sáng mà mãi mới nhận ra là lãng phí: mở Claude lên, gõ lại "mình làm marketing, viết cho dân văn phòng, giọng thế này thế kia...". Ngày nào cũng vậy. Như thể mỗi sáng lại tuyển một nhân viên mới rồi training lại từ số 0. Đến lúc đếm ra tổng thời gian, mình mới giật mình.
So sánh với khi mình hỏi cùng prompt đó trong một chat trắng (không Project):
Trong thời đại số hóa ngày nay, việc tối ưu hóa quy trình làm việc với AI là vô cùng quan trọng. Bài viết này sẽ giúp bạn khám phá những phương pháp hiệu quả để...
Thấy khác biệt chưa? Chat trắng ra giọng "báo cáo tốt nghiệp", sáo rỗng, xưng "chúng ta". Bản trong Project ra đúng giọng "mình/bạn", có tình huống thật, không màu mè — vì nó đã có sẵn ràng buộc và bài mẫu để bắt chước. Mình không phải gõ lại một chữ nào về văn phong.
Ví dụ thực chiến 2 — Project phân tích số liệu marketing
Project thứ hai mình chạy tên "Phân tích quảng cáo". Trong Knowledge mình nạp sẵn một file định nghĩa các chỉ số (CTR, CPC, CPA, ROAS tính thế nào) và ngưỡng tốt/xấu theo ngành của mình. Instructions yêu cầu: luôn nêu con số cụ thể, chỉ ra 1 vấn đề lớn nhất trước, rồi mới đề xuất.
Mình dán bảng số liệu tuần vào và hỏi:
Đây là số liệu 5 nhóm quảng cáo tuần này. Nhóm nào nên tắt,
nhóm nào nên tăng ngân sách? Nói thẳng, đừng liệt kê lại hết.
Nhóm A: chi 2tr, 45 lead, CPA 44k
Nhóm B: chi 3tr, 20 lead, CPA 150k
Nhóm C: chi 1.5tr, 38 lead, CPA 39k
Nhóm D: chi 2.5tr, 8 lead, CPA 312k
Nhóm E: chi 1tr, 22 lead, CPA 45k
Output mẫu:
Tắt ngay nhóm D — CPA 312k, cao gấp 7-8 lần nhóm tốt nhất, đang đốt tiền. Đây là vấn đề lớn nhất tuần này.
Cân nhắc tắt hoặc sửa creative nhóm B — CPA 150k, gấp gần 4 lần nhóm C. Nếu sản phẩm biên lợi nhuận cao thì còn gồng được, nếu không thì cắt.
Tăng ngân sách nhóm C và E — CPA 39-45k, hiệu quả nhất. Dồn phần tiền vừa cắt từ D và B sang đây, tăng từ từ 20-30% mỗi lần để không phá vỡ thuật toán.
Ngân sách giải phóng được từ D + B là khoảng 5.5tr, đủ để scale 3 nhóm còn lại.
Điểm hay: mình không cần giải thích CPA là gì, ngưỡng bao nhiêu là xấu — Project đã có file định nghĩa trong Knowledge. Nếu hỏi câu này trong chat trắng, mình phải kèm cả một đoạn bối cảnh dài, và câu trả lời thường sẽ liệt kê lại đủ 5 nhóm cho "an toàn" thay vì nói thẳng nhóm nào chết.
Lưu ý: các con số trên là ví dụ minh họa để bạn thấy dạng output, không phải số liệu chiến dịch thật.
Sai lầm thường gặp (và lúc Project làm bạn chậm hơn)
Mình từng nghĩ cứ nhồi càng nhiều vào Project càng thông minh. Sai. Đây là 3 lỗi mình đã dính và cách né:
1. Nhồi quá nhiều tài liệu vào Knowledge → Project chậm và lạc. Có giai đoạn mình nạp 20 bài viết cũ vào một Project cho "chắc ăn". Kết quả ngược: Claude bị nhiễu, lôi ý từ bài không liên quan, câu trả lời loãng và chậm hẳn. Cách tránh: chỉ nạp 2-4 file tinh túy nhất. Knowledge là để bắt "chất", không phải kho lưu trữ. Nếu cần nhiều loại tài liệu khác nhau, tách thành nhiều Project.
2. Một Project ôm quá nhiều mục đích → hướng dẫn đá nhau. Mình từng gộp "viết bài + phân tích số liệu + trả lời email khách" vào một Project. Instructions cho việc này lại phá việc kia — bảo "viết dài, có ví dụ" cho blog nhưng lại muốn "ngắn gọn, thẳng" cho email, Claude không biết nghe ai. Cách tránh: một Project một mục đích. Thà có 4 Project gọn còn hơn 1 Project ôm đồm.
3. Instructions viết quá dài, quá nhiều quy tắc → Claude quên bớt. Khi bạn nhét 30 quy tắc, những quy tắc ở giữa hay bị lãng quên. Cách tránh: giữ 5-8 quy tắc quan trọng nhất, viết ngắn gọn, ưu tiên ràng buộc "cứng" (như "không bịa số") lên đầu.
Và một điều thật lòng: không phải việc gì cũng cần Project. Với một câu hỏi dùng một lần rồi bỏ — "dịch giúp câu này", "tóm tắt email này" — mở chat trắng còn nhanh hơn. Project chỉ đáng công khi bạn làm cùng một loại việc lặp lại nhiều lần. Nếu bạn thấy mình bỏ 15 phút setup một Project mà cả tháng dùng đúng 2 lần, thì đó là setup thừa. Chia nhỏ theo việc bạn thật sự lặp lại, không phải theo việc bạn tưởng sẽ lặp lại.
Takeaway
Project không thông minh hơn Claude thường. Nó chỉ giúp bạn thôi phải giải thích lại chính mình mỗi ngày. Cái được lớn nhất không phải tốc độ — mà là output ra đúng "chất" của bạn ngay từ câu đầu, vì AI đã biết bạn là ai.
Bắt đầu đơn giản: chọn một việc bạn làm nhiều nhất, lập một Project cho nó, viết instructions ngắn gọn, nạp 2-3 file mẫu. Chạy thử một tuần. Khi thấy đã ngon, mới nhân bản sang việc khác. Đừng lập 10 Project trong ngày đầu — bạn sẽ bỏ hết.
Một Project. Một mục đích. Vài file tinh túy. Đó là công thức mình quay lại dùng sau khi thử đủ kiểu phức tạp.
Muốn nâng thêm một bậc? Đọc tiếp Claude Skills — Setup Claude đúng cách để hiểu cách "cài kỹ năng" cố định cho Claude, thứ đi xa hơn cả Project.

