Tài liệu miễn phí cho người Việt muốn dùng Claude như một hệ điều hành công việc

Tài liệu này được biên soạn dựa trên bài viết gốc về cách biến Claude Fable thành một "second brain" và AI operating system cho đời sống, công việc và doanh nghiệp. Phần dịch cố gắng giữ sát ý bài gốc, nhưng được viết lại bằng tiếng Việt tự nhiên hơn để người Việt dễ đọc, dễ hiểu và dễ áp dụng.

Ở cuối tài liệu, GiangXAI bổ sung thêm phần phân tích riêng:

• Claude Fable có ý nghĩa gì so với các bản Claude trước đây
• Người đang dùng Claude nên thay đổi cách dùng như thế nào
• Người Việt có thể bắt đầu xây AI OS cá nhân từ đâu

---

Tóm Tắt Nhanh

Claude Fable không chỉ là một model mới để hỏi đáp thông minh hơn. Theo cách tác giả đang sử dụng, nó là phần lõi của một hệ thống làm việc lớn hơn: một nơi tập trung toàn bộ bối cảnh cá nhân, doanh nghiệp, khách hàng, nội dung, quy trình và dữ liệu sống.

Điểm quan trọng không nằm ở việc "Claude Fable trả lời hay hơn Claude cũ bao nhiêu". Điểm quan trọng là khi model đủ mạnh, bạn có thể bắt đầu dùng nó như một cộng sự vận hành:

• Nó hiểu bạn là ai
• Nó biết doanh nghiệp của bạn đang làm gì
• Nó biết tài liệu nằm ở đâu
• Nó có thể kết nối dữ liệu sống
• Nó có thể xây workflow, skill, agent và automation
• Nó có thể kiểm tra lại chính kết quả của mình

Khung tư duy chính trong bài là Four Cs:

1. Context: bối cảnh, danh tính, kiến thức, tài liệu, hệ thống thư mục
2. Connections: kết nối tới dữ liệu sống như email, lịch, Slack, ClickUp, Stripe, YouTube, QuickBooks
3. Capabilities: kỹ năng, agent, automation, pipeline, quy trình làm việc
4. Cadence: nhịp vận hành tự động theo lịch, sự kiện hoặc trigger

Hai chữ C đầu tiên tạo nên second brain. Hai chữ C sau biến second brain đó thành AI OS.

Thông điệp an toàn quan trọng nhất trong bài:

Prompt không phải lớp phân quyền. Muốn an toàn thì dùng key, quyền truy cập và giới hạn thật.

Nói ngắn gọn: đừng chỉ bảo AI "đừng gửi email". Nếu không muốn nó gửi email, đừng cấp cho nó key có quyền gửi email.

---

1. Claude Fable Là Gì?

Theo bài viết gốc, Claude Fable là phiên bản công khai của dòng model Mythos-class. Có thể hiểu đơn giản: đây là một lớp model mạnh hơn nhóm Opus trước đó, đặc biệt ở các tác vụ dài, phức tạp, cần hiểu nhiều bối cảnh và tự làm qua nhiều bước.

Nate mô tả Fable như một phiên bản rất mạnh của Claude Mythos, nhưng có thêm nhiều hàng rào an toàn về an ninh mạng và các lĩnh vực nhạy cảm.

Hai điểm cần chú ý trước khi dùng:

Thứ nhất, Fable không phải model rẻ. Trong bài gốc, Nate nhắc rằng nó đắt hơn Opus đáng kể, với mức giá tính theo token cao hơn. Vì vậy nếu dùng không kiểm soát, bạn có thể tiêu tốn hạn mức rất nhanh.

Thứ hai, nó có thể bị các cơ chế an toàn chặn nhầm trong một số trường hợp. Với model mạnh hơn, nhà cung cấp phải cẩn thận hơn về rủi ro lạm dụng. Điều này có nghĩa là đôi khi bạn sẽ thấy model từ chối hoặc chuyển hướng ở những yêu cầu mà bạn nghĩ là bình thường.

Nhưng điểm đáng chú ý nhất không phải chỉ là giá hay guardrails. Điểm đáng chú ý là Fable có vẻ phù hợp hơn cho những công việc dài hơi:

• Đọc nhiều file
• Hiểu cấu trúc dự án
• Lập kế hoạch
• Tự thực hiện nhiều bước
• Xây giao diện
• Kết nối dữ liệu
• Kiểm tra lại kết quả
• Làm việc như một agent thay vì chỉ là chatbot

Đó là lý do bài viết không nói nhiều về benchmark. Nate nhấn mạnh rằng cảm giác dùng, harness và cách bạn thiết kế hệ thống xung quanh model quan trọng hơn nhiều.

---

2. Đừng Bắt Đầu Bằng Kiến Trúc. Hãy Bắt Đầu Bằng Một Mặc Định

Một ý rất hay trong bài gốc là: hệ điều hành AI không bắt đầu từ kiến trúc phức tạp. Nó bắt đầu từ một thói quen mặc định.

Trước đây, Nate cũng giống nhiều người dùng AI khác:

• Mở nhiều công cụ AI khác nhau
• Dùng nhiều subscription
• Tạo nhiều custom GPT
• Tạo nhiều project riêng
• Copy-paste qua lại giữa các tab

Cách đó vẫn có ích. Nhưng vấn đề là bạn phải lặp lại rất nhiều. Mỗi công cụ chỉ biết một phần bối cảnh. Mỗi cuộc trò chuyện lại phải giải thích lại. Nó không giống một cộng sự thật sự hiểu chuyện gì đang xảy ra trong đời sống và doanh nghiệp của bạn.

Vì vậy bước đầu tiên là chọn một "harness" mặc định.

Harness có thể là Claude Code, Codex, Cursor, hoặc một môi trường agent khác. Với Nate, nhiều người trong cộng đồng của anh sẽ chọn Claude Code. Nhưng điểm chính không phải là công cụ nào. Điểm chính là: hãy có một nơi mặc định để bắt đầu mọi việc.

Khi bạn làm mọi thứ qua một môi trường chính, nó bắt đầu tích lũy:

• Context
• Memory
• Quy tắc làm việc
• Thói quen của bạn
• Cách bạn đặt tên file
• Cách bạn ra quyết định
• Cách bạn muốn output được trình bày

Đây là nền tảng của second brain.

Từ đó, Nate chia hệ thống thành hai lớp:

Lớp đầu tiên là second brain. Đây là phần tri thức. Nó trả lời câu hỏi: AI có biết chuyện gì đang xảy ra trong doanh nghiệp, đời sống, khách hàng, kênh YouTube, sản phẩm và dự án của bạn không?

Lớp thứ hai là AI OS. Đây là phần vận hành. Sau khi AI đã hiểu dữ liệu và bối cảnh, bạn bắt đầu xây skill, automation, agent và quy trình để thật sự làm việc từ trong hệ thống đó.

Nói cách khác:

• Second brain giúp AI biết
• AI OS giúp AI làm

---

3. Four Cs: Khung Xây AI OS

Khung Nate dùng để xây và duy trì AI OS là Four Cs:

1. Context
2. Connections
3. Capabilities
4. Cadence

Thứ tự này rất quan trọng.

Context: AI Phải Hiểu Bạn Trước

Context là bối cảnh. Đây là lớp đầu tiên.

AI cần biết:

• Bạn là ai
• Bạn làm gì
• Doanh nghiệp của bạn là gì
• Bạn phục vụ ai
• Sản phẩm của bạn là gì
• Team của bạn gồm những ai
• Tài liệu nằm ở đâu
• Quy trình làm việc ra sao
• Dự án nào đang ưu tiên
• Các quyết định cũ được ghi lại ở đâu

Nate gọi Claude.md của mình là "router". Nó không chứa mọi thứ, mà chỉ đường cho agent biết phải đi đâu.

Ví dụ, file router có thể nói:

• Rule nằm ở thư mục nào
• Reference nằm ở đâu
• Skill nào dùng cho việc nào
• Wiki chính nằm ở đâu
• Master index là file nào
• Hot cache nằm ở đâu
• Các dự án phụ nằm ở đâu

Đây là một tư duy rất quan trọng. Bạn không cần nhồi toàn bộ kiến thức vào một prompt khổng lồ. Bạn cần tạo một hệ thống đường dẫn rõ ràng để AI có thể tự tìm.

Nate nói anh luôn quan sát AI tìm file như thế nào. Nếu anh biết file nằm ở đâu mà AI mất năm phút vẫn không tìm ra, đó là tín hiệu kiến trúc cần được sửa.

Đây là thứ anh gọi là architecture engineering: thiết kế kiến trúc thư mục, file, chỉ mục, quy tắc và đường dẫn sao cho cả người và agent đều tìm được thứ cần tìm.

Một bài kiểm tra rất thực tế:

• Với bạn, cấu trúc thư mục này có trực quan không?
• Nếu không có AI, bạn có tự tìm được tài liệu bằng tay không?
• Agent có thể đi theo cùng logic đó không?
• Nó có phải tìm kiếm quá lâu không?
• Nó có đốt token vì kiến trúc rối không?

Nếu câu trả lời ổn, thì hệ thống của bạn đang đi đúng hướng.

Other Worlds: Gom Các Dự Án Phụ Vào Một Hệ Chính

Một điểm Nate mới thay đổi gần đây là tạo một thư mục gọi là Other Worlds.

Thư mục này chứa các dự án Claude Code khác mà trước đây anh thường mở ở repo riêng.

Anh gom những thứ dùng thường xuyên vào project chính của mình vì hai lý do:

Một là đồng bộ. Khi anh push project chính lên GitHub rồi pull về laptop, mọi thứ đi cùng nhau. Anh không cần nhớ push sáu repo khác nhau trước khi đổi máy.

Hai là khả năng tiếp cận. AI OS chính bây giờ có thể nhìn sang book project, website, video edit, token dashboard và các hệ thống khác. Agent có thể di chuyển giữa các thư mục để tìm thứ cần tìm.

Điểm này rất gần với cách một người làm nội dung, founder hoặc freelancer ở Việt Nam có thể làm:

• Một thư mục cho khách hàng
• Một thư mục cho nội dung TikTok/YouTube
• Một thư mục cho sản phẩm số
• Một thư mục cho SOP nội bộ
• Một thư mục cho tài chính
• Một thư mục cho nghiên cứu
• Một thư mục cho prompt/skill/agent

Tất cả không nhất thiết phải nằm trong một file. Nhưng cần có một nơi trung tâm để AI biết đường đi.

Connections: Tĩnh Và Sống

Sau context là connections.

Một phần dữ liệu của bạn là dữ liệu tĩnh:

• Tiểu sử
• Ghi chú cũ
• Transcript cuộc họp
• Thành tựu năm trước
• Tài liệu chiến lược
• SOP
• Bản kế hoạch

Nhưng một phần khác là dữ liệu sống, thay đổi liên tục:

• Email mới
• Lịch họp
• Tin nhắn Slack
• Task trong ClickUp
• Doanh thu Stripe
• P&L trong QuickBooks
• Bình luận YouTube
• Khách hàng mới
• Booking mới

Connections là lớp giúp second brain của bạn không bị lỗi thời.

Nate gợi ý một cách đơn giản để tìm các kết nối quan trọng: hãy nhìn vào các app bạn mở hàng tuần.

Bạn thường mở app nào?

• Gmail?
• Google Calendar?
• Google Drive?
• Notion?
• Slack?
• Zalo?
• ClickUp?
• Trello?
• Stripe?
• Shopify?
• YouTube Studio?
• Facebook Business Suite?
• Google Sheets?

Những app này chính là nơi dữ liệu sống của bạn đang nằm.

Nếu chưa biết bắt đầu từ đâu, hãy chia theo nhóm:

• Doanh thu nằm ở đâu?
• Khách hàng nằm ở đâu?
• Lịch nằm ở đâu?
• Giao tiếp nằm ở đâu?
• Công việc nằm ở đâu?
• Cuộc họp nằm ở đâu?
• Kiến thức nằm ở đâu?

Với Nate:

• Skool là revenue và customers
• YouTube cũng là customers
• Stripe và QuickBooks là revenue
• Google Workspace là calendar
• Google Workspace, ClickUp và Slack là communications

Phần lớn các kết nối này đi qua API key, endpoint hoặc CLI.

Bài kiểm tra của lớp connections rất rõ:

Nếu bạn mở Claude Code ngay bây giờ và hỏi nó về bạn hoặc doanh nghiệp của bạn, câu trả lời nghe giống một người lạ hay giống một đồng đội?

Nếu nó nghe như người lạ, bạn thiếu context hoặc connections.

---

4. Fable Đã Biết Gì Về Nate?

Nate đưa ra hai ví dụ để cho thấy hệ thống của anh hoạt động sâu đến mức nào.

Ví Dụ 1: Tự Xây Video Về Hành Trình Của Nate

Anh chạy một lệnh /goal và yêu cầu AI xem toàn bộ project, hiểu nó biết gì về anh, kênh của anh và doanh nghiệp của anh, rồi xây một video giải thích hành trình đó bằng hyperframes.

AI kéo ra được bức tranh khá thật:

• Nate Herk
• Founder ở Chicago
• Creator trong lĩnh vực AI automation
• Người dạy người bình thường xây hệ thống bằng AI
• Làm nội dung YouTube
• Có khóa học miễn phí dài 8 giờ với hơn 1,5 triệu lượt xem
• Có flywheel từ YouTube sang cộng đồng miễn phí, sản phẩm trả phí và high-ticket coaching
• Có team 13 người tại Uppit AI
• Công ty lõi sở hữu nhiều venture khác nhau
• Đã chuyển trọng tâm từ n8n sang Claude Code trong năm nay, nhưng vẫn giữ cùng sứ mệnh

Một chi tiết AI nói sai: nó nói Nate có khoảng 620.000 subscribers, trong khi thực tế gần hơn 800.000. Đây là ví dụ của vấn đề dữ liệu tĩnh. AI dùng lần refresh gần nhất. Nếu được yêu cầu kéo số liệu live từ YouTube, nó có thể cập nhật ngay.

Bài học: second brain mạnh đến đâu cũng vẫn cần phân biệt dữ liệu tĩnh và dữ liệu sống.

Ví Dụ 2: Tự Xây Giao Diện Map Quan Hệ Giữa Transcript

Ví dụ thứ hai cũng là một lệnh /goal chạy một lần, hoàn thành trong khoảng 21 phút.

Nate yêu cầu AI lấy toàn bộ transcript và các mối quan hệ giữa chúng, rồi đưa vào một giao diện sạch để người khác có thể click xem.

AI đã xây một front end với:

• Ideas
• Tools and harnesses
• Techniques
• Các mối liên hệ giữa từng concept
• Video nào nhắc tới concept nào
• Các entry point như "Tôi mới bắt đầu", "Tôi xây sản phẩm", "Tôi vận hành doanh nghiệp"

Để làm được việc đó, AI phải:

• Xây UI
• Đọc transcript YouTube thật
• Tìm quan hệ giữa các ý tưởng
• Map các concept với video
• Nghĩ về user journey
• Làm giao diện đủ dễ hiểu

Điều đáng chú ý là Nate không dùng database phức tạp cho phần lớn việc này. Anh dùng markdown file và cách tiếp cận LLM wiki kiểu Karpathy với Obsidian.

Đây là điểm rất quan trọng với người Việt: bạn không cần bắt đầu bằng database, backend, vector DB hay hệ thống quá phức tạp. Có thể bắt đầu bằng folder và file markdown sạch.

---

5. Model Không Phải Tất Cả. Harness Và Cách Dùng Quan Trọng Hơn

Nate nhấn mạnh rằng benchmark không phải cách tốt nhất để đánh giá model.

Lý do là vì trong thực tế, năng lực của AI phụ thuộc rất nhiều vào:

• Harness bạn dùng
• Công cụ bạn cấp cho nó
• Cách bạn tổ chức file
• Context có rõ không
• Skill có tốt không
• Dữ liệu có cập nhật không
• Có quy trình kiểm tra không
• Có chia nhỏ công việc không

Một model rất mạnh nhưng đặt trong một folder lộn xộn, không có tài liệu, không có rule, không có quyền đọc dữ liệu, thì vẫn chỉ là một chatbot thông minh.

Ngược lại, một model chưa phải mạnh nhất nhưng được đặt trong một hệ thống tốt có thể làm được rất nhiều việc hữu ích.

Với Fable, Nate cảm nhận rằng nó hiểu ý đồ tốt hơn. Anh có thể giao những nhiệm vụ tham vọng hơn, dài hơn, ít cần cầm tay hơn.

Nhưng nó vẫn có nhược điểm:

• Đôi khi chậm
• Đôi khi safeguard nhạy quá mức
• Đôi khi từ chối việc lẽ ra có thể làm
• Chi phí cao
• Dễ đốt limit nếu giao việc không kiểm soát

Vì vậy cách dùng đúng không phải là dùng Fable cho mọi việc. Cách dùng đúng là dùng nó cho các việc xứng đáng với năng lực đó.

---

6. Capabilities: Skill, Agent Và Dây Chuyền Công Việc

Sau khi có context và connections, bạn mới đến capabilities.

Capabilities là những gì AI OS của bạn thật sự có thể làm.

Đây là một bài kiểm tra về thói quen. Trước khi mở Chrome để gửi email, kéo báo cáo, tìm dữ liệu hay viết nội dung, bạn thử mở môi trường AI OS trước.

Khi đưa một công cụ vào hệ thống, Nate thường kiểm tra:

• Công cụ đó có API không?
• Có endpoint không?
• Có CLI không?
• Có thể dùng key scoped không?
• Có thể đọc dữ liệu mà không cần quyền ghi không?

Anh thích CLI và API hơn MCP server trong nhiều trường hợp vì có nhiều quyền kiểm soát hơn và thường rẻ hơn. Nhưng MCP vẫn có thể hữu ích.

Skill Không Cần Phức Tạp

Một skill không nhất thiết phải là quy trình 10 bước.

Skill có thể chỉ là một prompt tốt.

Nếu thứ Hai nào bạn cũng viết cùng một loại báo cáo, hãy biến nó thành skill.

Nếu thứ Sáu nào bạn cũng tổng kết tuần, hãy biến nó thành skill.

Nếu bạn brainstorm với Claude Code và thích kết quả, hãy bảo nó biến quy trình đó thành skill để lần sau dùng nhanh hơn.

Skill sẽ không hoàn hảo ngay lần đầu. Điều đó bình thường.

Mỗi lần dùng skill là một lần thu thập dữ liệu:

• Phần nào tốt?
• Phần nào dài quá?
• Phần nào thiếu?
• Output có đúng format không?
• Có cần thêm ví dụ không?
• Có cần giới hạn quyền không?

Sau đó bạn cập nhật skill.

Nate có hơn 20 skill cùng nhiều global skill, và mỗi lần dùng anh đều feedback để cập nhật. Một skill tạo ảnh anh xây từ bốn tháng trước vẫn còn thay đổi vì sở thích cá nhân, model và endpoint đều thay đổi.

Thông điệp: skill không phải sản phẩm hoàn thiện. Skill là tài sản sống.

Tư Duy Dây Chuyền

Nate nghĩ theo kiểu dây chuyền sản xuất, giống kinh nghiệm từ thời dùng n8n.

Một AI làm một việc thật tốt.

Ví dụ:

• Một agent nghiên cứu
• Một agent lập dàn ý
• Một agent viết bản nháp
• Một agent kiểm tra tính chính xác
• Một agent chỉnh giọng văn
• Một agent chuẩn bị publish

Nếu bạn nhồi tất cả vào một session, context dễ bị loãng. AI dễ mất tập trung. Cuộc trò chuyện dài ra và chất lượng giảm dần.

Cách tốt hơn là làm theo pha:

1. Spin up agent để research
2. Lấy output
3. Clear context
4. Đưa output sang pha draft
5. Đưa draft sang pha polishing
6. Đưa bản cuối sang pha verification

Đây là tư duy rất thực tế cho người làm nội dung, automation, lập trình, marketing hoặc vận hành doanh nghiệp.

Dùng Model Rẻ Hơn Cho Việc Song Song

Vì Fable đắt, Nate khuyên nên đẩy các tác vụ song song cho model rẻ hơn như Sonnet hoặc Haiku, sau đó gom kết quả sạch về.

Ví dụ:

• Fable làm chiến lược chính
• Sonnet đọc tài liệu phụ
• Haiku phân loại nhanh
• Một agent khác tóm tắt
• Fable chỉ xử lý kết luận cuối cùng

Đây là cách tiết kiệm chi phí mà vẫn dùng được sức mạnh của model cao cấp.

---

7. Cadence: Chỉ Tự Động Hóa Sau Khi Đã Chứng Minh Được Quy Trình

Cadence là lớp cuối cùng: những thứ chạy khi bạn đang ngủ.

Nhưng Nate nói rõ: bạn phải kiếm được quyền tự động hóa.

Tự động hóa không phải cứ làm được là nên bật.

Bạn cần chứng minh:

• Skill đã được test đủ nhiều
• Output ổn định
• Rủi ro đã được hiểu
• Có người chịu trách nhiệm
• Có log
• Có visibility
• Có điểm dừng
• Có quyền truy cập được giới hạn

Càng thêm AI vào automation:

• Chi phí tăng
• Rủi ro tăng
• Công bảo trì tăng
• Khả năng lỗi khó đoán tăng

Automation không có nghĩa là quên nó đi. Bạn vẫn cần kiểm tra, giám sát và có người sở hữu.

Ba Loại Trigger

Nate chia trigger thành ba nhóm:

Manual: bạn gọi nó khi cần. Ví dụ: "tạo báo cáo tuần này".

Event: có sự kiện xảy ra thì quy trình chạy. Ví dụ: email mới, khách hàng đặt lịch, payment thành công.

Schedule: chạy theo lịch. Ví dụ: mỗi thứ Hai, mỗi tối Chủ nhật, mỗi cuối tháng.

Cách triển khai có thể rất đa dạng:

• Claude Code routines
• Loops
• Script deterministic chạy trên Modal
• n8n automation
• Workflow do Claude OS tạo rồi đẩy sang n8n
• Cron job
• CLI automation

Chọn cách nào phụ thuộc use case.

---

8. Prompt Không Phải Lớp Phân Quyền

Đây là phần quan trọng nhất về an toàn.

Nate nói rất thẳng: prompt không bao giờ là permission layer.

Nếu AI có thể làm gì đó, hãy giả định rằng một lúc nào đó nó có thể làm.

Nếu nó có quyền gửi email, nó có thể gửi email.

Nếu nó có quyền đọc database, nó có thể đọc database.

Nếu nó có quyền ghi discount code, nó có thể ghi discount code.

Nate kể một sự cố thật: một agent chủ động lấy task từ danh sách, hiểu sai nhiệm vụ, tự quyết định cần tạo mã giảm giá và gửi nó tới khoảng 150.000 đến 200.000 người trong danh sách email. Mã đó không bao giờ được phép gửi ra. Team phải gửi lời xin lỗi.

Anh không đổ lỗi cho người xây. Team biến sự cố thành case study để mọi người hiểu rủi ro và học cách làm an toàn hơn.

Bài học là:

Keys, not prompts.

Tức là dùng key, quyền và giới hạn thật.

Nếu agent không có key để vào "phòng gửi email", nó không thể gửi email.

Đó mới là lớp phân quyền đáng tin.

Sau đó bạn vẫn phải sửa instruction để nó không hiểu sai nữa. Nhưng instruction chỉ là lớp hướng dẫn. Permission thật phải nằm ở key, role, scope và hạ tầng.

Với người Việt đang xây automation, đây là nguyên tắc sống còn:

• Dùng read-only key khi chỉ cần đọc
• Không dùng admin key cho agent thử nghiệm
• Tách key theo từng chức năng
• Không để một agent có quyền quá rộng
• Việc gửi email, chuyển tiền, xóa dữ liệu, cập nhật database nên có bước duyệt
• Ghi log mọi hành động quan trọng
• Test bằng môi trường sandbox trước

---

9. Ba Mẹo Sử Dụng Của Nate

Mẹo 1: Dùng AI Như Thought Partner, Nhưng Luôn Giữ Hoài Nghi

Đừng hỏi "làm thế nào", nhận câu trả lời rồi bảo AI làm ngay.

Hãy brainstorm với nó.

Hãy bắt nó phản biện.

Hãy dùng nhiều sub-agent để nhìn từ các góc khác nhau.

Ví dụ:

• Một agent đóng vai CFO
• Một agent đóng vai khách hàng khó tính
• Một agent đóng vai kỹ sư bảo mật
• Một agent đóng vai marketer
• Một agent đóng vai người mới hoàn toàn

Sau đó bạn dùng trực giác và kinh nghiệm của mình để quyết định.

Nate nhắc rằng model vẫn có xu hướng chiều lòng người dùng. Nó có thể đồng ý quá nhanh. Vì vậy bạn cần yêu cầu nó phản biện thật sự.

Mẹo 2: Để AI Phỏng Vấn Bạn

Nate dùng một skill gọi là "Grill Me", ban đầu lấy cảm hứng từ Matt Pocock, rồi chỉnh lại để viết brainstorm docs.

Skill này sẽ hỏi anh 15, 25 hoặc 30 câu để kéo kiến thức ra khỏi đầu anh và đưa vào AI OS.

Đây là cách rất mạnh cho người mới bắt đầu.

Bạn có thể mở một setup mới và nói:

Hãy phỏng vấn tôi để hiểu toàn bộ doanh nghiệp của tôi. Hỏi từng câu một. Sau đó tổng hợp thành tài liệu context cho AI OS.

AI sẽ hỏi:

• Bạn bán gì?
• Khách hàng là ai?
• Vấn đề chính của khách hàng là gì?
• Bạn kiếm tiền như thế nào?
• Quy trình bán hàng hiện tại ra sao?
• Team gồm những ai?
• Công cụ đang dùng là gì?
• Dữ liệu nằm ở đâu?
• Việc lặp lại nhiều nhất là gì?
• Điều gì không được phép tự động hóa?

Đây là cách biến kiến thức trong đầu founder, creator, freelancer hoặc nhân sự vận hành thành tài sản có cấu trúc.

Mẹo 3: Bắt AI Tự Kiểm Tra Công Việc Của Nó

Đây là mẹo quan trọng nhất.

Trong ví dụ xây relationship map, Nate nói rõ đây là demo cho YouTube, không cần production-ready, nhưng phải dễ hiểu. Sau đó anh yêu cầu dùng dynamic workflow để xác minh mọi thứ chính xác và hoạt động.

AI không chỉ build. Nó phải kiểm tra.

Ví dụ:

• Mở giao diện bằng Playwright
• Click qua các trang
• Kiểm tra beginner có hiểu không
• Kiểm tra software engineer có thấy hữu ích không
• Kiểm tra business owner có tìm được thứ họ cần không
• Kiểm tra link có hỏng không
• Kiểm tra dữ liệu có khớp transcript không

Nate nói hãy cho Claude Code khả năng kiểm tra giống như bạn kiểm tra việc của một intern.

Đây là khác biệt giữa bản đầu 70% và bản tốt hơn nhiều.

---

10. Cuối Cùng, Tất Cả Chỉ Là Folder Và File

Model và harness chỉ là động cơ. Hệ thống mới là thứ bạn đang xây.

Nate nhấn mạnh rằng cuối cùng tất cả chỉ là folders và files.

Nếu ngày mai bạn chuyển từ Claude sang Codex thì sao?

Nếu bạn quay lại Sonnet thì sao?

Nếu bạn dùng một coding agent khác thì sao?

Nếu hệ thống của bạn là folder, markdown, skill, routing logic, logs và wiki, thì model nào cũng có thể đọc được.

Đó là lý do Nate giữ nhiều cấu trúc:

• .claude
• .codex
• .agents
• claude.md
• agents.md

Mục tiêu là càng tool-agnostic càng tốt.

Bạn không thật sự đang học Claude Code hay Codex. Bạn đang học cách xây tài sản vận hành lặp lại được cho chính mình.

Đó là IP cá nhân của bạn:

• Folder
• Markdown
• Skill
• Routing logic
• Logs
• Wiki
• Workflow
• SOP
• Automation

Thông điệp này giúp giảm áp lực chạy theo mọi model mới. Model sẽ thay đổi. Harness sẽ thay đổi. Nhưng hệ thống của bạn vẫn ở đó.

Một ngày nào đó bạn có thể chạy chính hệ thống này trên một model open source hoặc một harness riêng mà không cần quá kỹ thuật.

---

11. Lightning Round: Những Câu Hỏi Thường Gặp

Chạy cả ngày tốn bao nhiêu?

Còn tùy. Với Nate, anh làm nhiều knowledge work chứ không phải heavy coding liên tục, dùng gói cao cấp và hiếm khi chạm giới hạn năm giờ, chỉ đôi khi chạm giới hạn tuần.

Nhưng Fable đắt hơn, nên nếu dùng cho các task lớn liên tục, chi phí và limit sẽ bị đốt nhanh.

Dữ liệu của tôi đi đâu?

Với Claude, dữ liệu đi tới Anthropic theo chính sách của nền tảng bạn dùng. Nếu bạn xử lý dữ liệu cực kỳ nhạy cảm, bạn cần cân nhắc kỹ việc dùng model closed-source và cấu hình bảo mật của tài khoản.

Tôi có cần biết code không?

Không nhất thiết.

Nhưng nếu biết cách tổ chức folder, viết markdown, đặt tên file, tạo quy trình và mô tả yêu cầu rõ ràng, bạn sẽ đi nhanh hơn rất nhiều.

Ngày đầu tiên với một folder trống thì làm gì?

Bắt đầu bằng việc để AI phỏng vấn bạn.

Sau đó tạo:

• profile.md: bạn là ai
• business.md: doanh nghiệp làm gì
• offers.md: sản phẩm/dịch vụ
• customers.md: khách hàng
• tools.md: công cụ đang dùng
• processes.md: quy trình lặp lại
• rules.md: điều AI được và không được làm
• index.md: chỉ mục dẫn đường

Khi AI tự tin nhưng sai thì sao?

Kiểm tra nguồn.

Yêu cầu nó chỉ ra file, dòng, dữ liệu hoặc link gốc.

Sau đó cập nhật Claude.md, skill hoặc tài liệu context để lỗi đó ít lặp lại hơn.

Live connections hoạt động thế nào?

Thông qua API, CLI hoặc connector.

Tìm API docs của công cụ, đưa cho Claude Code hoặc để nó tự nghiên cứu, rồi yêu cầu nó dùng endpoint cụ thể.

Luôn dùng scoped API key. Nếu chỉ cần đọc transcript cuộc họp, key không nên có quyền sửa hoặc xóa.

Nếu bỏ bê hệ thống vài tuần thì sao?

Không quá nghiêm trọng. Bạn chỉ cần sync dữ liệu lại, cập nhật context và tiếp tục.

Team có nên mỗi người tự xây AI OS không?

Có, nhưng cần một phần kiến thức chung.

Hãy quyết định shared knowledge nằm ở đâu:

• ClickUp
• Slack
• Notion
• Google Drive
• GitHub
• Obsidian vault

Mọi người nên có quyền đọc vào nguồn chung, tránh mỗi người copy một bản riêng rồi kiến thức phân mảnh.

Rào cản lớn nhất không phải kỹ thuật. Rào cản lớn nhất là adoption: mọi người có thật sự dùng nó mỗi ngày không?

---

Phần Phát Triển Bởi GiangXAI

12. Claude Fable Có Ý Nghĩa Gì So Với Các Bản Claude Trước?

Với các bản Claude trước như Sonnet, Haiku hoặc Opus, phần lớn người dùng vẫn dùng Claude như một chatbot mạnh:

• Hỏi đáp
• Viết nội dung
• Tóm tắt
• Dịch
• Viết code từng đoạn
• Phân tích tài liệu
• Brainstorm

Các tác vụ đó vẫn rất hữu ích. Nhưng chúng thường diễn ra trong một cuộc trò chuyện riêng lẻ.

Claude Fable đại diện cho một bước chuyển khác: từ AI assistant sang AI operator.

Assistant trả lời bạn.

Operator có thể đi vào hệ thống, đọc tài liệu, hiểu mục tiêu, lập kế hoạch, thao tác công cụ, kiểm tra kết quả và báo cáo lại.

Điểm khác biệt không chỉ là "thông minh hơn". Điểm khác biệt là khả năng xử lý những việc dài hơi hơn:

• Hiểu một repo lớn
• Làm migration qua nhiều file
• Đọc hàng loạt transcript
• Xây bản đồ tri thức
• Thiết kế workflow nhiều bước
• Giữ mục tiêu qua thời gian dài
• Tự ghi chú để cải thiện kết quả
• Tự kiểm tra sản phẩm cuối

Điều này khiến cách dùng Claude phải thay đổi.

Với Claude cũ, bạn có thể nghĩ:

Tôi cần prompt tốt hơn.

Với Fable và các model agentic mạnh hơn, bạn nên nghĩ:

Tôi cần môi trường làm việc tốt hơn cho AI.

Prompt vẫn quan trọng, nhưng không còn là lợi thế chính. Lợi thế chính là:

• Context sạch
• File rõ ràng
• Quy trình tốt
• Quyền truy cập đúng
• Skill được cập nhật
• Automation có kiểm soát
• Dữ liệu sống được kết nối
• Cơ chế verify kết quả

Nói cách khác, Claude Fable không chỉ nâng cấp model. Nó làm lộ ra một năng lực mới: người biết xây hệ thống quanh AI sẽ có lợi thế lớn hơn người chỉ biết hỏi prompt.

---

13. Người Đang Dùng Claude Nên Hiểu Điều Này Như Thế Nào?

Nếu bạn đang dùng Claude, thông điệp thực tế là:

Đừng chỉ đổi model. Hãy đổi cách dùng.

Nếu bạn chỉ mở Claude lên và hỏi từng câu rời rạc, bạn sẽ thấy Fable hoặc các model mới thông minh hơn, nhưng chưa thấy hết sức mạnh.

Muốn thấy sức mạnh thật, hãy cho Claude một môi trường làm việc:

• Một folder dự án rõ ràng
• Một file chỉ đường
• Một bộ tài liệu context
• Một nơi chứa ghi chú
• Một bộ skill lặp lại
• Một số kết nối dữ liệu sống
• Một quy trình kiểm tra output

Thay Đổi 1: Từ Chat Sang Workspace

Đừng coi Claude chỉ là cửa sổ chat.

Hãy coi Claude là người làm việc trong workspace của bạn.

Workspace đó nên có:

• Tài liệu cá nhân
• Tài liệu doanh nghiệp
• Mục tiêu quý/tháng/tuần
• Danh sách dự án
• Ghi chú cuộc họp
• Transcript
• SOP
• Quy tắc ra quyết định
• Brand voice
• Tài liệu khách hàng
• Lịch sử chiến dịch

Khi Claude có workspace, nó không cần bạn giải thích lại từ đầu mỗi lần.

Thay Đổi 2: Từ Prompt Sang Process

Prompt là câu lệnh.

Process là quy trình.

Người mới thường hỏi:

Prompt nào để viết content tốt?

Người dùng nâng cao sẽ hỏi:

Quy trình nào để từ research, insight, angle, draft, edit, fact-check đến publish?

Claude mạnh nhất khi được đặt trong process.

Ví dụ một process viết bài:

1. Agent nghiên cứu audience
2. Agent tổng hợp insight
3. Agent tạo 10 angle
4. Agent chọn angle phù hợp brand
5. Agent viết draft
6. Agent edit giọng văn
7. Agent kiểm tra claim
8. Agent tạo caption và CTA

Đây là khác biệt giữa "AI viết giúp tôi một bài" và "AI tham gia vào dây chuyền sản xuất nội dung".

Thay Đổi 3: Từ Một AI Làm Tất Cả Sang Nhiều Vai Trò Nhỏ

Một cuộc trò chuyện dài dễ bị loãng.

Thay vào đó, hãy chia vai trò:

• Researcher
• Strategist
• Writer
• Editor
• Fact-checker
• Reviewer
• Automation builder
• QA tester

Mỗi vai trò có hướng dẫn riêng và output riêng.

Kết quả cuối cùng tốt hơn vì mỗi agent không phải ôm quá nhiều việc.

Thay Đổi 4: Từ Tin Tưởng Sang Verify

Claude giỏi hơn không có nghĩa là bạn được bỏ kiểm tra.

Ngược lại, vì Claude có thể làm nhiều hơn, bạn càng cần verify tốt hơn.

Hãy yêu cầu:

• Nêu nguồn
• Trích file gốc
• Liệt kê giả định
• Tự kiểm tra lỗi
• Chạy test
• Mở browser kiểm tra UI
• So sánh với yêu cầu ban đầu
• Tạo checklist trước khi hoàn thành

Model càng mạnh, hệ thống kiểm tra càng quan trọng.

Thay Đổi 5: Từ "Cấp Quyền Rộng" Sang "Cấp Quyền Tối Thiểu"

Nếu bạn kết nối Claude với công cụ thật, hãy dùng nguyên tắc least privilege:

• Chỉ cấp quyền cần thiết
• Chỉ cấp trong phạm vi cần thiết
• Chỉ cấp trong thời gian cần thiết
• Tách quyền đọc và quyền ghi
• Tách môi trường test và production
• Với hành động rủi ro, bắt buộc có bước duyệt của người

Đây là điều nhiều người bỏ qua khi quá hào hứng với automation.

---

14. Lộ Trình Bắt Đầu Cho Người Việt

Bạn không cần xây toàn bộ AI OS ngay.

Hãy bắt đầu nhỏ, nhưng đúng hướng.

Bước 1: Tạo Folder AI OS Cá Nhân

Tạo một thư mục, ví dụ:

my-ai-os/

Bên trong có:

00-router/
01-profile/
02-business/
03-projects/
04-customers/
05-content/
06-processes/
07-skills/
08-logs/
09-connections/

Không cần hoàn hảo. Quan trọng là có chỗ để bắt đầu.

Bước 2: Tạo File Router

Tạo file:

AI_OS.md

Nội dung ban đầu:

Bạn là AI assistant làm việc trong hệ thống AI OS cá nhân của tôi.

Khi cần hiểu tôi là ai, đọc 01-profile/profile.md.
Khi cần hiểu doanh nghiệp, đọc 02-business/business.md.
Khi cần xem dự án, đọc 03-projects/index.md.
Khi cần hiểu khách hàng, đọc 04-customers/customers.md.
Khi cần viết nội dung, đọc 05-content/brand-voice.md.
Khi cần làm việc lặp lại, xem 06-processes/.
Khi cần dùng skill, xem 07-skills/.

Luôn nêu rõ nguồn dữ liệu đã dùng.
Không tự thực hiện hành động bên ngoài nếu chưa được phép.
Với hành động gửi, xóa, cập nhật hoặc thanh toán, phải hỏi lại trước.

Bước 3: Để Claude Phỏng Vấn Bạn

Dùng prompt:

Hãy phỏng vấn tôi để xây second brain cá nhân.
Hỏi từng câu một.
Mục tiêu là tạo ra các file profile.md, business.md, customers.md, offers.md, processes.md và rules.md.
Sau mỗi nhóm câu hỏi, hãy tổng hợp thành nội dung markdown rõ ràng.

Đừng cố viết mọi thứ một lần. Hãy để AI hỏi và kéo dữ liệu ra khỏi đầu bạn.

Bước 4: Biến Việc Lặp Lại Thành Skill

Liệt kê 5 việc bạn làm lặp lại hàng tuần:

• Viết bài Facebook
• Lên ý tưởng video
• Tóm tắt meeting
• Viết email cho khách
• Chuẩn bị báo cáo
• Review nội dung
• Tạo outline khóa học
• Phân tích feedback khách hàng

Chọn một việc và tạo skill đầu tiên.

Ví dụ:

Skill: weekly-content-ideas
Mục tiêu: tạo 10 ý tưởng nội dung mỗi tuần dựa trên brand voice, khách hàng mục tiêu và sản phẩm hiện tại.
Input: ghi chú tuần, câu hỏi khách hàng, sản phẩm đang bán.
Output: bảng gồm angle, hook, format, CTA, mức độ ưu tiên.

Bước 5: Chỉ Kết Nối Dữ Liệu Sống Khi Đã Có Nhu Cầu Rõ

Đừng vội kết nối mọi thứ.

Bắt đầu với dữ liệu dễ và ít rủi ro:

• Google Drive read-only
• Google Calendar read-only
• YouTube Analytics read-only
• Google Sheets read-only

Sau đó mới tính tới quyền ghi, gửi email hoặc automation có tác động thật.

Bước 6: Ghi Log Mọi Lần AI Làm Việc Quan Trọng

Tạo thư mục:

08-logs/

Mỗi lần AI làm một việc lớn, lưu lại:

• Ngày
• Mục tiêu
• Dữ liệu đã dùng
• Output
• Lỗi phát hiện
• Điều cần cải thiện
• Skill nào cần cập nhật

Đây là cách AI OS của bạn học dần.

---

15. Kết Luận

Bài viết gốc của Nate Herk không chỉ nói về Claude Fable. Nó nói về một cách dùng AI trưởng thành hơn.

Thay vì hỏi:

Model nào mạnh nhất?

Hãy hỏi:

Tôi đã xây môi trường đủ tốt để model mạnh phát huy chưa?

Thay vì hỏi:

Prompt nào hay nhất?

Hãy hỏi:

Quy trình nào đang lặp lại trong công việc của tôi và có thể biến thành skill?

Thay vì hỏi:

Làm sao tự động hóa mọi thứ?

Hãy hỏi:

Việc nào đã đủ ổn định, đủ an toàn và đủ rõ trách nhiệm để tự động hóa?

Claude Fable làm cho tương lai AI OS trở nên rõ hơn. Nhưng nền tảng vẫn rất đơn giản:

• Folder
• File markdown
• Context rõ
• Kết nối đúng
• Skill nhỏ
• Agent chuyên biệt
• Quyền truy cập tối thiểu
• Kiểm tra nghiêm túc

Bạn không cần chờ model tiếp theo để bắt đầu.

Bạn có thể bắt đầu bằng một folder hôm nay.

---

Ghi Chú Nguồn

Tài liệu này dựa trên bài viết gốc của Nate Herk về cách anh biến Claude Fable thành second brain và AI operating system cá nhân. Nate là một creator/founder trẻ, nổi bật trong mảng AI automation, AI agent, Claude Code workflow và xây dựng hệ thống vận hành bằng AI.

Phần dịch và diễn giải đã được biên tập lại cho người Việt, đồng thời bổ sung góc nhìn ứng dụng thực tế bởi GiangXAI.