Các kỹ thuật xây dựng Obsidian chỉ dành cho thiên tài và những người có thu nhập cao

Kiếm tiền với AI không phải là về "Số lượng Ghi chú"

Trước hết, hãy cùng thảo luận một cách bình tĩnh.

Không có nghiên cứu nào chỉ ra mối quan hệ nhân quả giữa thu nhập 100 triệu yên hàng năm và cấu hình Obsidian. Không có "plugin bí mật chỉ dành cho người giàu."

Ý tôi khi nói "người chơi 100 triệu yên" không phải là người lưu trữ một lượng kiến thức khổng lồ.

Đó là những người có thể chuyển đổi thông tin họ thu được thành:

• Ra quyết định
• Đàm phán
• Tuyển dụng
• Phán đoán đầu tư
• Thiết kế sản phẩm
• Nội dung
• Tài liệu bán hàng
• Hệ thống tổ chức
• Tài sản trí tuệ tái sử dụng

...với tốc độ cực cao.

Người dùng Obsidian thông thường nghĩ về "lưu cái gì."

Người dùng giỏi nghĩ trước tiên về "trong tình huống nào, sử dụng câu hỏi nào, tôi sẽ truy xuất thông tin này trong tương lai?"

Người dùng giỏi hơn nữa theo dõi xem kiến thức được truy xuất đó cuối cùng đã được chuyển đổi thành quyết định hay đầu ra nào.

Nói cách khác, điều bạn thực sự nên thiết kế không phải là "Bộ não thứ hai."

Đó là một Hệ điều hành Trí tuệ Cá nhân giúp tổng hợp việc ra quyết định và sản xuất trí tuệ.

Obsidian lưu ghi chú dưới dạng tệp Markdown cục bộ. Vault chỉ là một thư mục và các thay đổi từ trình chỉnh sửa bên ngoài hoặc script được phản ánh trong Obsidian. Cài đặt và thông tin plugin được tách riêng vào thư mục .obsidian. Điều này có nghĩa là Obsidian không chỉ là một ứng dụng, mà là một "kho lưu trữ kiến thức" có thể được xử lý bởi Git, CLI, Claude và Codex.

Trong bài viết này, chúng tôi coi các yếu tố trên Obsidian như sau:

Khi bạn đạt đến góc nhìn này, cách sử dụng Obsidian của bạn thay đổi hoàn toàn.

Chương 1: Nghiên cứu Các Trường hợp Nước ngoài—Chiến lược Chiến thắng là "Tìm kiếm," Không phải "Tổ chức"

1. Đã học được gì từ Vault của 7 Nhà nghiên cứu

Có một nghiên cứu điển hình được công bố vào năm 2025 điều tra việc sử dụng Obsidian của bảy nhà nghiên cứu khoa học máy tính tại một viện nghiên cứu ở Brazil.

Điều rút ra quan trọng nhất từ nghiên cứu này không phải là cách những người tham gia tạo ghi chú.

Đó là khám phá rằng cách họ dự định truy xuất chúng trong tương lai ảnh hưởng mạnh mẽ đến cách họ tạo và tổ chức ghi chú. Những người tham gia sử dụng thanh tìm kiếm, danh sách thẻ, thẻ trong văn bản và liên kết nội bộ cho các mục đích khác nhau. Một số người dùng cũng đặt các ghi chú đã tạo vào Inbox và xử lý chúng mỗi tuần một lần.

Các đề xuất thiết kế do các nhà nghiên cứu đưa ra có thể tóm tắt thành ba điểm sau:

1. Không yêu cầu phân loại hoàn hảo ngay từ đầu; chuẩn bị một cấu trúc ban đầu tối thiểu.
2. Cho phép thay đổi cấu trúc trong quá trình sử dụng.
3. Kết nối phương pháp tạo/tổ chức với phương pháp tìm kiếm trong tương lai ngay từ đầu.

Nói cách khác, không phải là "tạo các thư mục chính xác."

Mà là quyết định cách bản thân tương lai của bạn sẽ tìm kiếm và ghi chép phù hợp với đường dẫn tìm kiếm đó.

Chỉ riêng điểm này đã cho thấy hầu hết các khóa học Obsidian thông thường đều đi sai hướng.

Nhiều khóa học yêu cầu bạn quyết định thư mục, thẻ, plugin và giao diện trước.

Tuy nhiên, trên thực tế, câu hỏi bạn nên quyết định trước tiên là:

Ba tháng nữa, tôi sẽ lo lắng về điều gì khi cần thông tin này?

2. Nicole van der Hoeven—Biến Ghi chú thành Công cụ Học tập Nghề nghiệp

Nicole van der Hoeven, người làm việc với tư cách là Developer Advocate và Performance Engineer, cho biết việc ghi chú liên tục về công việc đã có tác động tích cực không chỉ đến tốc độ học tập mà còn đến sự nghiệp của cô trong ngành công nghệ.

Điểm mấu chốt không phải là cô ấy "đã tạo ra một cơ sở dữ liệu kiến thức đẹp."

Mà là cô ấy ghi lại quá trình học trong công việc và tái sử dụng nó để chia sẻ công khai, giải thích và thuyết trình.

Cô ấy đưa các ghi chú học tập vượt ra ngoài hồ sơ cá nhân vào:

• Thuyết trình
• Bài viết
• Video
• Tài liệu
• Tài liệu giáo dục
• Công việc tiếp theo

Sự "chuyển đổi từ đầu vào sang đầu ra" này tạo ra giá trị kinh tế của kiến thức.

3. Bruno Paz—Local, Markdown, Plugin Tối thiểu

Kỹ sư phần mềm Bruno Paz tổng hợp mọi thứ từ đoạn mã, cuộc họp, thông số kỹ thuật dự án đến nghiên cứu và kiến thức cuộc sống vào Obsidian.

Tuy nhiên, quan trọng hơn việc đưa mọi thứ vào Obsidian là triết lý thiết kế của anh ấy.

Anh ấy nhấn mạnh tính khả chuyển của Markdown và quản lý lịch sử qua Git, áp dụng chính sách giữ số lượng plugin ở mức tối thiểu. Plugin giúp Obsidian tiện lợi, nhưng bản thân nội dung không nên phụ thuộc quá nhiều vào các plugin cụ thể.

Anh ấy cũng chuẩn hóa Frontmatter như type với các template, đặt Wikilinks đến các ghi chú liên quan trong topics, và liệt kê chúng bằng Bases hoặc Dataview.

Kết luận ở đây rất rõ ràng:

Có thể khôi phục chỉ bằng Markdown khi mọi thứ hỏng hóc quan trọng hơn là có nhiều chức năng cao.

4. Ian O'Byrne—Luồng Thông tin từ "Tiêu thụ → Tuyển chọn → Sáng tạo"

Ian O'Byrne, người sử dụng Obsidian trong giáo dục và nghiên cứu, cấu trúc Vault của mình theo luồng này:

• Tiêu thụ: Đầu vào như bài báo, sách, bài nghiên cứu, podcast
• Tuyển chọn: Chắt lọc điểm chính, liên hệ chúng, tạo MOC
• Sáng tạo: Đầu ra như blog, bản tin, tài liệu giảng dạy
• Meta: Thông tin vận hành cho chính Vault

Điều quan trọng không phải là tên thư mục.

Đó là cấu trúc nơi thông tin di chuyển từ đầu vào qua quá trình tạo ý nghĩa đến đầu ra. Anh ấy giải thích rằng quy trình quan trọng hơn nền tảng và Vault sẽ phát triển khi cần.

Tổng kết các trường hợp nước ngoài này, các Vault xuất sắc có năm điểm chung:

1. Truy xuất trước—Làm việc ngược từ các tìm kiếm trong tương lai
2. Lấy đầu ra làm trung tâm—Hướng đến các sản phẩm bàn giao, không chỉ lưu trữ
3. Local trước—Sử dụng Markdown làm nguồn sự thật
4. Lược đồ tối thiểu—Đừng làm phức tạp các trường đầu vào
5. Tiến hóa—Thay đổi cấu trúc trong khi sử dụng

Chương 2: Sáu Chỉ số Xác định "Vault 100 Triệu Yên"

Số lượng ghi chú, số lượng liên kết và vẻ đẹp của Đồ thị không phải là các chỉ số hiệu suất thiết yếu.

Tôi sẽ đo lường hiệu suất Vault bằng sáu chỉ số này:

1. Độ trễ Ghi lại

Thời gian từ khi có ý tưởng đến khi lưu nó.

Mục tiêu là trong vòng 30 giây. Một cấu trúc buộc bạn phải suy nghĩ về thẻ, ghi chú liên quan và vị trí lưu tại thời điểm nhập là yếu.

2. Thời gian Truy xuất

Thời gian để đến được thông tin cần thiết.

Nhắm đến trong vòng 30 giây cho thông tin chung và trong vòng 60 giây cho các bản ghi quyết định quan trọng.

3. Chi phí Tái tạo Ngữ cảnh

Thời gian để khôi phục một câu chuyện là về cái gì khi xem các ghi chú cũ.

Một ghi chú chỉ có tiêu đề cuộc họp là yếu. Một ghi chú lưu giữ "Bối cảnh," "Quyết định," "Lý do," "Tiền đề," và "Hành động tiếp theo" là mạnh.

4. Khả năng Truy xuất Nguồn gốc Quyết định

Tỷ lệ phần trăm các phán đoán quan trọng mà sau đó bạn có thể theo dõi:

• Tại sao nó được quyết định
• Điều gì đã bị từ chối
• Những tiền đề nào tồn tại
• Những điều kiện nào sẽ kích hoạt sự đảo ngược

5. Tỷ lệ Chuyển đổi Đầu ra

Tỷ lệ phần trăm các Ghi chú Nguồn hoặc Ghi chú Thường xanh đã lưu được tái sử dụng cho các bài viết, đề xuất, sản phẩm, quyết định, cuộc họp hoặc hoạt động bán hàng.

6. Khả năng Thực thi của Tác nhân

Tỷ lệ phần trăm thời gian Claude hoặc Codex có thể tìm kiếm, đề xuất và xác minh mà không hiểu sai các quy tắc của Vault.

Tổng kết lại, ROI của một hệ thống kiến thức có thể được nghĩ như sau:

ROI Kiến thức = (Kiến thức Được tái sử dụng + Quyết định Được cải thiện + Sai lầm Được tránh) / Thời gian dành cho việc ghi chép, tổ chức và bảo trì

Ngay cả khi số lượng ghi chú tăng lên, nếu chúng không được tái sử dụng, thì chỉ có mẫu số đang tăng lên.

Chương 3: Cấu trúc Vault Dễ dàng cho Người dùng Việt Nam

Nếu tôi xây dựng từ đầu, tôi sẽ sử dụng cấu trúc cấp cao nhất này:

MyVault/

├── 00_Inbox/

│ ├── AI/

│ └── Clippings/

├── 10_Daily/

│ └── 2026/

├── 20_Projects/

├── 30_Areas/

├── 40_Notes/

│ └── MOCs/

├── 50_Sources/

├── 60_Entities/

│ ├── People/

│ ├── Companies/

│ └── Products/

├── 70_Outputs/

│ ├── Drafts/

│ └── Published/

├── 80_Assets/

├── 90_System/

│ ├── Templates/

│ ├── Bases/

│ ├── Schemas/

│ ├── AgentSkills/

│ └── AI/

├── 99_Archive/

├── scripts/

├── .claude/

├── .agents/

├── .codex/

├── CLAUDE.md

└── AGENTS.md

00_Inbox

Đầu vào chưa được phân loại. Đừng tổ chức ở đây. Thẻ thường không cần thiết. Đây là nơi "chỉ để lưu."

10_Daily

Nhật ký công việc theo thời gian. Để lại các ghi chú, cuộc trò chuyện, nhận thức và tiến độ không đáng để tạo ghi chú độc lập.

20_Projects

Các hoạt động có điều kiện hoàn thành. "Tăng doanh số" là một Lĩnh vực hoặc Mục tiêu, nhưng "Sửa đổi giá gói doanh nghiệp vào tháng 9 năm 2026" là một Dự án. Dự án phải luôn có next_action.

30_Areas

Các lĩnh vực trách nhiệm đang diễn ra. Quản lý, bán hàng, tuyển dụng, tài chính, sức khỏe, gia đình, học tập, v.v. Các Lĩnh vực vẫn còn ngay cả khi Dự án đã hoàn thành.

40_Notes

Kiến thức để tái sử dụng lâu dài. Đặt nội dung ở đây mà bạn có thể giải thích bằng lời của mình, không chỉ là trích đoạn. Không cần phải tuân thủ nghiêm ngặt "một ghi chú, một khái niệm." Trong tiếng Việt, chủ ngữ và tiền đề dễ bị lược bỏ, vì vậy phân mảnh quá mức sẽ phá vỡ ngữ cảnh. Tiêu chuẩn là:

1 Ghi chú = Nội dung bạn muốn tái sử dụng như một đơn vị duy nhất trong tương lai

50_Sources

Bản ghi thông tin bên ngoài. Sách, bài báo, bài viết, video, tài liệu cuộc họp, dữ liệu nghiên cứu, v.v. Tách biệt "những gì bên kia nói" khỏi "cách tôi diễn giải nó."

60_Entities

Các thực thể như người, công ty, sản phẩm, khách hàng, đối thủ cạnh tranh và công nghệ. Ngay cả khi cùng một người hoặc công ty xuất hiện trong nhiều dự án, chỉ giữ một Ghi chú Thực thể.

70_Outputs

Bài viết, tài liệu lập kế hoạch, đề xuất, kịch bản video, thuyết trình, tài liệu bán hàng, thông số kỹ thuật sản phẩm, v.v. Điều quan trọng là đặt Đầu ra trong một thư mục cấp cao nhất độc lập. Một Vault chỉ nhằm mục đích lưu trữ sẽ trở thành nghĩa địa của kiến thức.

90_System

Các cơ chế vận hành chính Vault, chẳng hạn như template, Schemas, Bases, quy tắc AI và Skills. Bằng cách xây dựng điều này, bạn có thể giải thích các hoạt động của chính mình.

Có nên là một Vault duy nhất?

Về nguyên tắc, có. Các liên kết nội bộ trong Obsidian được giải quyết trong một Vault; việc chia tách Vault sẽ làm đứt gãy mối quan hệ giữa các kiến thức. Trong nghiên cứu đã đề cập, những người tham gia chia Vault của họ thành ba phần đã báo cáo sự nhầm lẫn trong tìm kiếm.

Tuy nhiên, hãy tách biệt về mặt vật lý những thứ sau:

• Thông tin mà đầu vào AI bên ngoài bị cấm theo hợp đồng.
• Thông tin y tế, số ID cá nhân, thông tin xác thực.
• Thông tin nhân sự có độ nhạy cảm cao.
• Dữ liệu được quản lý.
• Thông tin không thể chuyển cho các mô hình bên ngoài theo chính sách tổ chức.

Hãy nghĩ về nó như việc tách một "Vault Cá nhân" và một "Vault Được quản lý."

Chương 4: Đừng Trộn lẫn Vai trò của Thư mục, Properties, Links và Tags

Lý do lớn nhất khiến các hệ thống Obsidian sụp đổ là thể hiện cùng một phân loại bằng cách sử dụng đồng thời thư mục, tag, property và link. Hãy cố định vai trò của chúng như sau:

Thư mục dành cho "Vòng đời"

Inbox, Project, Source, Output, Archive, v.v. Chúng đại diện cho giai đoạn hiện tại của một ghi chú trong quy trình.

Properties dành cho "Kiểu và Trạng thái Xử lý Máy"

type, status, created, project, revisit, v.v. Obsidian Properties được lưu dưới dạng YAML và có thể có các kiểu như text, list, number, checkbox, date, datetime và tags.

Links dành cho "Mối quan hệ Ngữ nghĩa"

[[Chiến lược Định giá]], [[Công ty ABC]], [[Khả năng Đảo ngược của Quyết định]], v.v. Việc biến một chủ đề thành ghi chú thay vì thẻ cho phép bản thân chủ đề đó giữ các giải thích, phản chứng, tài liệu tham khảo và MOC.

Tags dành cho "Trạng thái Xuyên suốt Tạm thời"

Giới hạn thẻ ở những thứ như #review, #waiting, #question, #contradiction, #publish.

Các khái niệm như "Marketing" hoặc "AI" nên được đặt dưới dạng link bất cứ khi nào có thể. Sử dụng thẻ như một từ điển khái niệm dẫn đến sự gia tăng thẻ (ví dụ: #AI, #ArtificialIntelligence, #GenerativeAI). Thay vào đó, hãy sử dụng Bí danh trong các ghi chú khái niệm.

Chương 5: Lược đồ Property Tối thiểu

Đừng cố gắng điền 20 mục ngay từ đầu. Chia Lược đồ thành ba giai đoạn:

Giai đoạn Ghi lại

Chỉ những điều cần thiết:
``yaml
type: inbox
created: 2026-07-24
status: inbox
``

Giai đoạn Nâng cấp

Thêm vào khi nó có giá trị để lưu trữ lâu dài:
``yaml
type: note
created: 2026-07-24
status: active
topics:
- "[[Chiến lược Định giá]]"
- "[[B2B SaaS]]"
source_notes:
- "[[SRC Nghiên cứu Định giá Đối thủ cạnh tranh 2026-07]]"
confidence: medium
sensitivity: internal
``

Giai đoạn Vận hành

Thêm các mục cần thiết cho Dự án hoặc Quyết định:
``yaml
type: project
created: 2026-07-24
status: active
owner: me
area: "[[Quản lý]]"
due: 2026-09-30
next_action: So sánh kế hoạch hàng năm của 5 đối thủ cạnh tranh
``

Chương 6: Quy tắc cho Tên tệp Tiếng Việt

Không cần phải ép buộc nội dung văn bản hoặc tiêu đề tiếng Việt sang tiếng Anh. Tuy nhiên, giữ tên Property và tên thư mục được sử dụng cho xử lý máy ở dạng ASCII. Tôi sử dụng các quy ước đặt tên sau:

• Dự án: PJT Tái thiết kế Định giá Doanh nghiệp
• Quyết định: DEC 2026-07-24 Biến Kế hoạch Hàng năm thành Đề xuất Tiêu chuẩn
• Ghi chú Thường xanh: Giá được xác định bởi Rủi ro Thất bại Triển khai hơn là Số lượng Tính năng

Làm cho tiêu đề Ghi chú Thường xanh là "Khẳng định" thay vì "Tên Danh mục." Tiêu đề khẳng định giúp bạn nhớ lại nội dung chỉ từ kết quả tìm kiếm.

Chương 7: Các Template Thực sự Cần Bao gồm

Ghi chú Hàng ngày

Bao gồm "Nhật ký Khó khăn." Ghi lại "những gì tôi đã tìm kiếm nhưng không tìm thấy" cho phép bạn cải thiện Vault dựa trên các lần tìm kiếm thất bại thực tế. Phát triển cấu trúc từ các tìm kiếm thất bại, không phải từ sở thích thẩm mỹ.

Ghi chú Dự án

Ghi chú Dự án không phải là kho chứa nhiệm vụ. Nó là Trung tâm Chỉ huy Dự án nơi bất kỳ ai cũng có thể hiểu trạng thái hiện tại trong 30 giây.

Ghi chú Quyết định

Trong công việc có lợi nhuận cao, chất lượng quyết định quan trọng hơn thông tin. Do đó, Ghi chú Quyết định là loại ghi chú có giá trị nhất. Trường quan trọng nhất là Trình kích hoạt Đảo ngược. Một người ra quyết định xuất sắc là người có thể viết ra tại thời điểm đưa ra quyết định trong những điều kiện nào họ sẽ thay đổi ý kiến.

Chương 8: MOC là "Mô hình Tư duy Đã được Biên tập," Không phải Danh sách Liên kết

Một MOC (Bản đồ Nội dung) tốt chứa đựng sự phán xét của người biên tập. Nó là một mô hình nhận thức đã được biên tập, nén gọn cách bạn hiểu hiện tại về toàn bộ một lĩnh vực, thay vì chỉ là một danh sách các ghi chú liên quan.

Chương 9: Tạo "Bảng điều khiển Quản lý" với Bases

Obsidian Bases là một tính năng cốt lõi cho phép bạn hiển thị, lọc và sắp xếp các Property của ghi chú như một cơ sở dữ liệu. Sử dụng nó để tạo "Bases Dự án Đang hoạt động" hoặc "Bases Đánh giá Quyết định" để khôi phục các phán đoán đã bị bỏ lửng.

Chương 10: Plugin Phân cấp

• Cấp 0 (Chỉ cốt lõi): Properties, Templates, Daily Notes, Bases, Search, Canvas, v.v.
• Cấp 1 (Khi có ma sát): QuickAdd, Templater, Tasks.
• Cấp 2 (Chỉ khi Bases không đủ): Dataview.

Giữ số lượng Plugin Cộng đồng đang hoạt động ở mức 12 hoặc ít hơn. Ghi lại mục đích, phương án thay thế và điều kiện xóa cho mỗi plugin.

Chương 11: Thay đổi Quyết định trong Năm 2026—Obsidian CLI Chính thức

Kể từ tháng 7 năm 2026, Obsidian có CLI chính thức. Nó cho phép bạn vận hành phiên bản máy tính để bàn từ terminal: tìm kiếm, đọc, tạo, cập nhật property và kiểm tra nhiệm vụ. Điều này cho phép Claude và Codex vận hành bằng cách sử dụng logic giải quyết của riêng Obsidian thay vì chỉ chỉnh sửa Markdown trực tiếp.

Chương 12: Cấu trúc Đúng đắn cho Vault Gốc AI

Để AI tự do chỉnh sửa tất cả các ghi chú không phải là "sử dụng AI." Điều đó giống như giao tất cả tài liệu công ty cho một thực tập sinh chưa được kiểm duyệt. Sự phân công lao động đúng đắn là:

• Con người: Mục tiêu, đánh giá giá trị, phê duyệt cuối cùng, chỉnh sửa MOC.
• Obsidian: Nguồn sự thật, mối quan hệ, lịch sử, chế độ xem.
• Claude: Chắt lọc ý nghĩa, so sánh, phản biện, viết nháp.
• Codex: Thay đổi cấu trúc, script, xác thực, đánh giá khác biệt.
• Git: Khôi phục, kiểm toán, cách ly thử nghiệm.
• Trình xác thực: Phát hiện vi phạm lược đồ và bất thường liên kết.

Chương 13: Đặt CLAUDE.md và AGENTS.md

Claude Code đọc CLAUDE.md như các hướng dẫn liên tục. Codex tìm kiếm AGENTS.md. Đặt một "Hợp đồng Vận hành Vault" trong các tệp này để xác định ngôn ngữ (văn xuôi tiếng Việt, property ASCII), quy tắc an toàn (chạy thử mặc định) và quy tắc lược đồ.

Chương 14: Biến các Nhiệm vụ Obsidian thành Skills thông qua Claude

Xác định "Kỹ năng Tác nhân" cho các nhiệm vụ bạn làm hơn ba lần hoặc cho chất lượng tiêu chuẩn hóa. Ví dụ: kỹ năng obsidian-distill có thể chuyển đổi các ghi chú cuộc họp thô thành Quyết định, Nhiệm vụ và Ghi chú Thường xanh. Một Skill tốt là một tiêu chuẩn công việc có thể thực thi lại với đầu vào, quy trình, điều cấm kỵ và điều kiện hoàn thành rõ ràng.

Chương 17: Mẫu Cộng tác cho Claude, Codex và Obsidian CLI

• Mẫu 1: Chắt lọc Ghi chú Cuộc họp (Claude trích xuất quyết định/nhiệm vụ).
• Mẫu 2: Đánh giá Quản lý Hàng tuần (Claude tổng kết tiến độ trong tuần và các dự án bị đình trệ).
• Mẫu 3: Kiểm tra Độ lệch Lược đồ (Codex phát hiện sự không nhất quán của property).
• Mẫu 4: Kiểm tra Tiền đề Quyết định (Claude kiểm tra xem các giả định đằng sau các quyết định trong quá khứ có còn đúng không).

Đây là cách sử dụng vượt xa việc "tóm tắt ghi chú bằng AI." Bạn sử dụng AI như một bộ điều khiển trí tuệ kiểm toán các phán đoán trong quá khứ của bạn.

Chương 18: Bao gồm Trình xác thực Vault

Nếu AI đang chỉnh sửa Vault của bạn, đừng chỉ bằng lòng với "nó có vẻ ổn." Thực hiện kiểm tra tĩnh tối thiểu thông qua các script (ví dụ: vault_check.py) để xác minh các loại, trạng thái và property bắt buộc được phép.