Obsidian không phải app ghi chú
Hầu hết người dùng Obsidian vẫn nghĩ về việc sử dụng nó theo một cách rất lỗi thời. Họ nói “mình đang viết ghi chú”, hoặc “mình đang tổ chức thông tin”. Những từ này nghe bình thường, nhưng chúng ẩn chứa một cách suy nghĩ cũ kỹ. Obsidian không phải một cái vở ghi chú, cũng không phải một tủ hồ sơ số hóa.
Obsidian là một IDE.
Nếu bạn từng tiếp xúc với lập trình, IDE là Integrated Development Environment: một công cụ toàn diện để viết mã, thử nghiệm mã, gỡ lỗi mã, tối ưu hóa mã. Không ai viết mã bằng tay vào tờ giấy rồi hy vọng nó chạy được. Lập trình viên viết mã vào IDE, IDE giúp kiểm tra cú pháp, gợi ý hoàn thành, chỉ ra lỗi.
Obsidian cũng vậy. Nó không phải nơi để bạn viết ghi chú rồi để đó. Nó là nơi để bạn xây dựng một hệ thống kiến thức. Và như bất kỳ hệ thống nào, nó cần các bộ phận khác nhau để hoạt động tốt. Khi bạn chuyển sang mindset này, mọi thứ thay đổi: bạn không “viết ghi chú” nữa, bạn “develop” knowledge. Bạn không “sắp xếp thông tin”, bạn “lint code” và “deploy updates”.
Bạn là kiến trúc sư, không phải người viết
Khi bắt đầu sử dụng Obsidian kết hợp AI, bạn cần thay đổi cách nghĩ về vai trò của mình. Bạn không phải người viết ghi chú. Bạn là kiến trúc sư. Bạn đang thiết kế một cơ sở dữ liệu kiến thức.
Trong một dự án phần mềm, có ba loại người. Kiến trúc sư quyết định cấu trúc tổng thể, những khối chính, cách chúng giao tiếp với nhau. Lập trình viên viết mã để thực hiện kế hoạch của kiến trúc sư. Tester kiểm tra xem mã có hoạt động đúng không, tìm lỗi.
Khi bạn sử dụng Obsidian + AI, bạn giữ hai vai trò. Bạn là kiến trúc sư: quyết định vault nên có cấu trúc gì, loại ghi chú nào cần phải có, cách chúng liên kết. Đồng thời bạn cũng là tester: kiểm tra xem nội dung AI tạo ra có tốt không, tìm lỗi, sửa chúng. Còn LLM (AI) là lập trình viên: nó “viết mã” (ở đây, mã chính là nội dung) để thực hiện kế hoạch của bạn.
Đây là sự thay đổi quan trọng trong cách suy nghĩ. Bạn không còn là người viết; bạn là người làm quyết định. AI là người viết. Điều này có nghĩa là bạn cần bỏ bớt thời gian cho việc viết, và dành nhiều thời gian hơn cho việc xem xét, đánh giá, sửa chữa và liên kết.
Bốn vai trò của AI trong vault
Nếu Obsidian là IDE, thì AI không chỉ có một vai trò. AI có tối thiểu bốn vai trò khác nhau, và hiểu rõ từng vai trò giúp bạn sử dụng nó hiệu quả hơn nhiều.
Vai trò đầu tiên là compiler. AI nhận vào thông tin thô, có thể là bài báo, trang web, đoạn video transcript. Nó biến những thứ đó thành ghi chú Obsidian có cấu trúc. Nó trích xuất ý tưởng chính, tạo tiêu đề, thêm context. Công việc này giống compiler trong lập trình: biến mã nguồn (raw data) thành mã máy (ghi chú có cấu trúc).
Vai trò thứ hai là librarian. AI tìm kiếm, tìm nạp, tổng hợp. Khi bạn hỏi “mình có ghi chú nào về chủ đề X?” hoặc “có ghi chú nào liên kết đến Y không?”, AI giúp bạn tìm. Nó cũng có thể gợi ý những mối liên kết mà bạn có thể đã bỏ lỡ.
Vai trò thứ ba là editor. AI đọc lại ghi chú, tìm lỗi, đề xuất cải thiện. Nó có thể nói “ghi chú này thiếu ví dụ cụ thể” hoặc “đoạn này mâu thuẫn với ghi chú kia”. Nó cũng có thể cập nhật ghi chú khi bạn có thông tin mới.
Vai trò cuối cùng là gardener. AI chăm sóc vault như người làm vườn chăm cây. Nó tìm ghi chú cũ và đề xuất xóa hoặc cập nhật. Nó tìm ghi chú rời rạc và đề xuất mối liên kết mới. Nó gợi ý lỗ hổng trong cấu trúc và đề xuất ghi chú mới để lấp đầy. Bài AI agent bảo trì vault đi sâu vào vai trò gardener này, giống như CI/CD pipelines cho vault.
Bốn vai trò này không hoàn toàn tách rời. Một câu hỏi của bạn có thể kích hoạt hai hoặc cả bốn vai trò cùng lúc. Nhưng điều quan trọng là hiểu rằng AI không chỉ viết; nó là một hệ thống đầy đủ để giúp bạn quản lý kiến thức. Claude trợ lý vault là ví dụ cụ thể về cách biến Claude thành “programming partner” cho vault, đảm nhiệm cả bốn vai trò trên.
Workflow IDE thực tế
Hãy tưởng tượng một luồng làm việc cụ thể. Bạn đang đọc một bài báo hay. Bạn không muốn mất thời gian viết ghi chú dài dòng; bạn chỉ muốn ghi lại ý tưởng chính.
Bước đầu tiên, bạn copy bài báo vào tệp trong thư mục raw/ của Obsidian. Chỉ là copy-paste thôi, không xử lý gì cả. Đây là raw data đi vào hệ thống.
Bước hai, bạn mở Claude (hoặc một LLM khác) và bảo nó biên soạn bài báo thành ghi chú Obsidian. Bạn yêu cầu trích xuất ý tưởng chính, tạo tiêu đề, tạo tag phù hợp với hệ thống tag đang dùng. Đây là vai trò compiler của AI.
Bước ba, Claude trả về ghi chú đã biên soạn. Bạn đọc nó. Nếu tốt, bạn chuyển vào wiki folder. Nếu cần sửa, bạn yêu cầu Claude chỉnh lại. Đây là vai trò tester của bạn.
Bước bốn, bạn liên kết ghi chú mới với các ghi chú hiện có trong vault. Đây là lúc kiến trúc sư lên tiếng: ghi chú này thuộc về đâu trong hệ thống? Nó kết nối với concept nào?
Bước năm, một lần mỗi tuần, bạn hỏi Claude phân tích vault. Có ghi chú nào cần cập nhật không? Có mối liên kết nào bị bỏ lỡ không? Có lỗ hổng nào cần lấp không? Đây là vai trò librarian và gardener kết hợp.
Luồng này là workflow IDE thực tế. Mỗi bước là một phần của hệ thống lớn hơn. Bạn không viết ghi chú; bạn là kiến trúc sư. AI viết ghi chú; nó là programmer. Bạn kiểm tra ghi chú; bạn là tester. Và Markdown chính là ngôn ngữ chung giữa bạn và AI trong workflow này, đảm bảo cả hai hiểu nhau.
Một lưu ý quan trọng: khi yêu cầu AI biên soạn ghi chú, hãy rõ ràng về những gì bạn muốn. Nói “hãy trích xuất ý tưởng chính” khác với “hãy tạo tóm tắt”. Nói “hãy tạo tag cho vault của mình” khác với “hãy tạo tag chung chung”. Càng cụ thể bạn là, AI sẽ làm càng tốt.
Viết prompt như một kiến trúc sư
Nếu bạn là kiến trúc sư, bạn cần ba kỹ năng. Thứ nhất, biết bạn muốn xây dựng gì. Kế hoạch có thể đơn giản (chỉ muốn ghi lại mọi thứ mình đọc) hoặc phức tạp (xây dựng hệ thống kiến thức cho công ty). Thứ hai, biết nói chuyện với AI, biết cách hỏi rõ ràng, mô tả chính xác những gì bạn cần. Thứ ba, biết đánh giá công việc của AI, biết khi nào AI làm đúng, khi nào sai, khi nào tốt nhưng có thể tốt hơn.
Karpathy pattern là ví dụ về một kiến trúc sư tốt. Andrej Karpathy có vault rất đơn giản, nhưng nó phục vụ một mục đích rõ ràng. Anh ấy biết mình muốn gì, biết cách tổ chức ghi chú để AI hiểu, biết cách đánh giá công việc của mình.
Một kiến trúc sư xấu sẽ nói “AI, hãy tạo vault hoàn hảo cho mình” rồi copy kết quả mà không suy nghĩ. Một kiến trúc sư tốt sẽ nói “mình muốn vault có cấu trúc thế này vì mình sử dụng nó theo cách này, mình muốn những tag thế này vì mình tìm kiếm theo cách này, bạn có thể giúp mình sửa lỗi không, bạn có thể gợi ý cải thiện không?” Sau đó, kiến trúc sư tốt sẽ đọc kỹ gợi ý, suy nghĩ xem có hợp lý không, chỉ chấp nhận những gợi ý thực sự phù hợp.
Đây là cách viết prompt theo mindset kiến trúc sư. Thay vì “Hãy tạo ghi chú Obsidian từ bài báo này”, hãy nói “Mình đang xây dựng vault về machine learning. Ghi chú này nên chứa ý tưởng chính từ bài báo, ví dụ cụ thể, và tham chiếu đến ghi chú khác trong vault. Đây là danh sách tag mình đang dùng. Mình muốn ghi chú được viết dễ hiểu, không quá kỹ thuật.” Prompt dài hơn, nhưng cung cấp cho AI những thông tin cần thiết để hiểu bạn, hiểu nhu cầu, và đưa ra gợi ý tốt.
Khi AI quá tốt: cảnh báo cần thiết
Có một vấn đề cuối cùng mà ít người nhắc đến: khi AI quá tốt. Nếu AI làm tất cả công việc cho bạn, bạn không còn là kiến trúc sư nữa. Bạn trở thành khách hàng, hoặc tệ hơn, bạn không tham gia gì cả.
Điều này tệ vì hai lý do. Thứ nhất, bạn sẽ không học hỏi. Nếu AI làm tất cả, bạn sẽ không bao giờ hiểu tại sao công việc lại được thực hiện theo cách đó. Thứ hai, bạn sẽ mất quyền kiểm soát. Nếu AI tạo ra vault mà bạn không hiểu, bạn không thể thay đổi nó, không thể cải thiện nó. Vault đó sẽ trở thành hộp đen, giống như một chương trình mà không ai biết nó hoạt động thế nào.
Giữ cân bằng là quan trọng. AI nên làm phần lớn công việc “viết”, nhưng bạn phải hiểu những gì nó làm, và bạn phải sẵn sàng thay đổi nếu cần thiết. Khi bạn nói “AI là programmer”, điều này không có nghĩa bạn không cần xem xét “mã” của nó. Một programmer xấu viết code tồi. Một AI xấu viết ghi chú tồi. Bạn phải review cả hai.
Claude Code và vault là ví dụ về cách dùng công cụ mạnh mà vẫn giữ quyền kiểm soát. Bạn là kiến trúc sư, Claude Code là programmer, nhưng mọi thay đổi đều phải qua review của bạn.
Tại sao mindset này thay đổi tất cả
Cách suy nghĩ IDE quan trọng vì nó thay đổi hoàn toàn cách bạn tiếp cận Obsidian. Thay vì cố gắng viết ghi chú hoàn hảo mỗi lần, bạn có thể viết nhanh rồi để AI giúp cải thiện. Thay vì cố tổ chức mọi thứ hoàn hảo từ đầu, bạn bắt đầu đơn giản rồi để AI giúp phát triển.
Mindset này cũng có nghĩa bạn không cần là nhà viết tốt để có vault tốt. Bạn chỉ cần biết mình muốn gì, và biết cách nói chuyện với AI để đạt được điều đó. Đó chính là kỹ năng kiến trúc sư: không phải viết code (nội dung), mà là thiết kế hệ thống và review kết quả.
Câu hỏi thường gặp
Dùng IDE mental model thì công việc có nhiều hơn không?
Công việc thay đổi chứ không tăng. Bạn sẽ dành ít thời gian “viết ghi chú vô mục đích” và nhiều thời gian hơn cho “tư duy kiến trúc”. Tổng lượng thời gian có thể giảm vì AI xử lý phần viết nặng, còn bạn tập trung vào phần ra quyết định.
Không phải lập trình viên, có áp dụng IDE mental model được không?
Hoàn toàn được. IDE mental model không yêu cầu bạn biết code. Nó chỉ là cách suy nghĩ về cấu trúc, debugging (tìm lỗi trong vault), version control (theo dõi thay đổi), và review (đánh giá chất lượng). Ai cũng có thể áp dụng.
Obsidian không có tính năng debugging hay testing như IDE thực sự?
Đúng. Nhưng bạn có thể tự tạo ra. Đó là phần “extension” của IDE model: bạn tự định nghĩa tools để lint (kiểm tra chất lượng ghi chú), test (xác nhận liên kết hoạt động), validate (đảm bảo metadata đầy đủ). AI chính là công cụ mạnh nhất cho việc này.
Bài liên quan
- Karpathy pattern — pattern cơ bản để xây dựng wiki trên IDE
- Claude trợ lý vault — cách dùng Claude làm programming partner cho vault
- AI agent bảo trì vault — AI agents tự động bảo trì vault như CI/CD pipelines
- Claude Code và vault — dùng Claude Code để quản lý vault với quyền kiểm soát
- Markdown là ngôn ngữ chung với AI — tại sao Markdown là cầu nối giữa bạn và AI
Nguồn tham khảo
[1] Obsidian — ứng dụng ghi chú dựa trên Markdown.
[2] Andrej Karpathy. LLM Wiki Pattern — GitHub Gist.
[3] Visual Studio Code — IDE phổ biến nhất, ví dụ so sánh với Obsidian.
Bửu Trung — Dân Lười, thích Tối ưu.
Bạn đang ở vai trò nào khi dùng Obsidian? Người viết ghi chú hay kiến trúc sư? Kể mình nghe, mình rất tò mò.
