Claude Artifacts giúp bạn dựng prototype nhanh. Nhưng sau vài ngày, vấn đề mới xuất hiện: mỗi chat nhớ một ít, mỗi lần bạn lại phải giải thích từ đầu, quyết định cũ bị quên, sample data nằm rải rác, và cuối cùng Claude bắt đầu trả lời lệch.
Claude Projects giải quyết phần này ở mức vừa đủ cho non-tech user. Bạn tạo một project riêng cho một ý tưởng app, đặt instructions, upload knowledge cần thiết, và dùng các chat trong cùng project để làm việc tiếp mà không phải copy lại toàn bộ bối cảnh.
Đừng hiểu Projects như database. Nó không thay hệ thống quản lý sản phẩm, không thay repo, không thay source of truth của công ty. Nhưng với vibe coding có kiểm soát, Projects là một cái hộp context rất hữu dụng.
Project nên chứa gì
Một Claude Project tốt cho prototype nên có 4 nhóm:
- Project instructions: cách Claude phải trả lời và giới hạn nào không được vượt.
- Project knowledge: tài liệu mẫu, quy trình, CSV sample, screenshot, brand note.
- Decision log: đã chọn gì, vì sao chọn, chưa làm gì.
- Handoff pack: khi cần chuyển qua dev hoặc coding agent, họ nhận được gì.
Điểm quan trọng: context trong một project không tự động kỳ diệu chảy qua mọi chat nếu bạn chỉ nói trong chat cũ. Theo docs hiện tại, nội dung muốn dùng ổn định giữa các chat nên được đưa vào project knowledge hoặc instructions. Vì vậy, sau mỗi quyết định quan trọng, đừng chỉ để nó trôi trong hội thoại. Ghi lại vào decision log.
Project instructions: luật chơi của prototype
Project instructions nên ngắn và rõ. Ví dụ:
Bạn đang hỗ trợ tôi prototype app bằng Claude Artifacts.
Audience:
- Tôi là non-tech user.
- Giải thích bằng tiếng Việt, practical, không dùng jargon nếu không cần.
Product rules:
- Đây là prototype, không được nói như production-ready app.
- Luôn phân biệt sample data và data thật.
- Không đề xuất upload dữ liệu khách hàng nhạy cảm.
- Không giả định có backend, auth, database nếu tôi chưa nói.
- Khi build artifact, hãy restate behavior trước rồi mới build.
Output style:
- Ưu tiên checklist, flow, prompt template.
- Khi có rủi ro, nói thẳng rủi ro và cách kiểm.Instructions này không thay review của bạn, nhưng giảm khả năng Claude đi sai hướng. Nó cũng giúp các chat mới trong project giữ cùng giọng và cùng guardrail.
Project knowledge: nạp context, không nạp bí mật
Project knowledge là nơi để những file Claude cần tham chiếu lại nhiều lần. Với non-tech vibe coding, các file hợp lý gồm:
- Process doc: quy trình tư vấn khách, xử lý booking, kiểm kho.
- Sample CSV đã ẩn danh.
- Screenshot màn hình app hiện tại.
- Brand note: màu, tone, cách gọi sản phẩm.
- FAQ khách hàng.
- Danh sách field cần có trong form.
- Policy nội bộ đã được phép dùng cho prototype.
Không nên upload:
- Dữ liệu khách hàng thật.
- Số điện thoại, email, địa chỉ, thông tin y tế, tài chính.
- Contract chưa được phép chia sẻ.
- API key, password, token.
- Export database raw.
Nếu cần data giống thật, tạo sample data. Đổi tên, đổi số điện thoại, đổi email, đổi mã đơn. Ghi rõ trong file: “Dữ liệu mẫu, không phải dữ liệu thật”.
Decision log: phần non-tech hay thiếu nhất
Prototype thay đổi nhanh. Hôm nay bạn chọn bỏ login. Ngày mai bạn thêm mobile-first. Tuần sau bạn quyết định không lưu data trong Artifact. Nếu không ghi lại, Claude có thể hỏi lại hoặc tệ hơn, tự đảo quyết định.
Tạo một file decision-log.md trong project knowledge:
# Decision log
## 2026-05-29
- App đầu tiên là booking tracker cho nhân viên tư vấn tour.
- Version prototype không có backend, không có login.
- Sample data phải ghi rõ là sample.
- Mobile-first vì nhân viên dùng điện thoại.
- Không làm payment trong giai đoạn này.
## Open questions
- Booking thật sẽ lấy từ CRM hay nhập tay?
- Ai được quyền xem toàn bộ booking?
- Có cần export CSV không?Khi Claude đề xuất tính năng mới, bạn cập nhật log nếu đồng ý. Nếu không đồng ý, cũng ghi “Rejected: chưa làm dashboard quản lý doanh thu trong prototype đầu”. Điều này giúp scope không phình ra.
RAG mode là gì và cần hiểu tới đâu
Theo docs hiện tại, RAG for Projects có trên các plan Claude và có thể tự bật khi project knowledge tiến gần hoặc vượt giới hạn context. Bạn không cần hiểu thuật toán. Chỉ cần hiểu thực tế:
- Project knowledge lớn không có nghĩa Claude luôn đọc từng dòng y như bạn mong.
- File càng rõ tên, càng ngắn, càng có cấu trúc, càng dễ dùng.
- Đừng upload 50 file lộn xộn rồi mong Claude tự biết file nào quan trọng.
- Khi cần file cụ thể, gọi tên file trong prompt.
Ví dụ:
Dựa trên `decision-log.md` và `booking-sample.csv`, hãy cập nhật app brief cho version 2. Không dùng các file khác nếu không cần.Cách này tốt hơn “dựa trên mọi thứ trong project”.
Khi nào tạo project mới, khi nào tạo chat mới
Tạo chat mới trong cùng project khi:
- Vẫn là cùng một app.
- Bạn muốn thử một hướng UI khác.
- Bạn cần viết tài liệu handoff.
- Bạn muốn audit lại prototype hiện tại.
Tạo project mới khi:
- App khác hẳn.
- Khách hàng hoặc domain khác.
- Context cũ có thể gây nhiễu.
- Bạn cần tách quyền chia sẻ trong Team/Enterprise.
- Prototype cũ đã kết thúc và không nên ảnh hưởng ý tưởng mới.
Đừng nhồi mọi ý tưởng vào một project “My apps”. Vài tuần sau bạn sẽ có một đống context lẫn lộn, Claude trả lời theo quyết định của app A trong khi bạn đang làm app B.
Handoff pack cho dev hoặc coding agent
Mục tiêu cuối của Claude Projects không phải là giữ bạn mãi trong Claude. Mục tiêu tốt hơn là giúp bạn tạo một handoff rõ.
Khi prototype đã đủ tốt, nhờ Claude tạo file handoff:
Tạo handoff pack cho dev từ project này.
Bao gồm:
- Product goal.
- Target users.
- Core flows đã test trong Artifact.
- Screenshots cần đính kèm.
- Field list.
- Validation rules.
- Sample data note.
- Open questions.
- Non-goals.
- Risks before production.
Không viết như app đã production-ready.Một dev nhận handoff như vậy sẽ review nhanh hơn nhiều so với nghe “em có cái prototype trên Claude, anh xem giúp”. Một coding agent cũng ít tự đoán hơn nếu có product goal, flow, non-goals và risk list.
Chốt lại
Claude Projects là lớp context giữa một prompt lẻ và một repo thật. Với non-tech vibe coding, hãy dùng Projects để giữ instructions, file mẫu, quyết định và handoff. Đừng upload dữ liệu nhạy cảm. Đừng xem project knowledge như database. Dùng nó để giảm việc lặp lại và tăng chất lượng bàn giao.