Learn

Mình là PM trong một công ty startup nhỏ. Đội dev thì luôn kín lịch với sản phẩm chính, mà mình thì có cả đống ý tưởng muốn thử - từ chuyển đổi blog công ty sang kiến trúc mới, đến tạo hệ thống để đồng nghiệp tự viết bài mà không cần biết kỹ thuật.

Nên mình tự build bằng vibe coding.

Nói đơn giản, vibe coding là mình mô tả thứ mình muốn bằng ngôn ngữ tự nhiên > AI viết code > mình xem kết quả rồi điều chỉnh. Công cụ mình dùng là Claude Code - một AI chạy ngay trong terminal, có thể đọc code của dự án, viết file mới, chạy lệnh, và deploy. Mình chỉ cần nói "chuyển blog từ lưu trữ file sang database" và nó tự lên kế hoạch > viết code > chạy thử.

Tuần trước, blog công ty mình đã tích lũy được 118 bài viết thuộc 13 danh mục sau hơn nhiều năm hoạt động. Mình cần chuyển toàn bộ từ cách lưu trữ cũ sang database mới - tương đương việc dọn 118 cuốn sách từ kệ cũ sang tủ mới có đánh index, phân loại, tìm kiếm được. Với Claude Code, mình làm xong trong 4 giờ. Thuê người làm thì ít nhất cả tuần.

Rồi mình setup thêm một headless CMS (Keystatic) để đồng nghiệp không biết kỹ thuật có thể tự viết blog - thay vì bắt họ commit file markdown trực tiếp. Sau vài lượt prompt với AI, mọi thứ có vẻ rất hợp lý..nhưng nó không hoạt động. Cùng một lỗi mà lặp đi lặp lại cả chục lần. Mình sửa theo gợi ý của AI - đổi URL > tạo lại secret > kiểm tra biến môi trường - nhưng vẫn gặp lỗi tương tự.

Mất gần cả nửa ngày sau thì mình mới phát hiện ra: AI đã hướng dẫn mình tạo sai loại ứng dụng ngay từ bước đầu tiên.

Chuyện gì đã xảy ra

Keystatic cần kết nối với GitHub qua OAuth để đồng nghiệp có thể đăng nhập và chỉnh sửa nội dung. Để làm được, mình cần tạo một "ứng dụng" trên GitHub cấp quyền truy cập cho Keystatic.

Nghe có vẻ đơn giản, nhưng vấn đề ở đây là GitHub có hai loại ứng dụng, tên gần giống nhau, nằm cạnh nhau trong cùng trang Developer settings:

• OAuth Apps - chỉ cấp access token (chìa khóa tạm), hết hạn là phải đăng nhập lại
• GitHub Apps - cấp cả access token lẫn refresh token (chìa khóa gia hạn), tự động gia hạn phiên làm việc

Keystatic bắt buộc cần refresh token. AI hướng dẫn mình tạo OAuth Apps - loại không có refresh token.

Mọi cấu hình trông có vẻ đúng - có Client ID, có Client Secret, callback URL chính xác. Nhưng Keystatic luôn báo lỗi xác thực vì không nhận được refresh token.

Mình mất nửa ngày xoay quanh các chi tiết - đổi callback URL > tạo lại Client Secret > kiểm tra biến môi trường trên server - trong khi vấn đề nằm ở bước đầu tiên: sai loại ứng dụng.

Cuối cùng, mình yêu cầu AI hướng dẫn lại từ đầu, kiểm tra từng bước một. Lúc đó nó mới nhận ra - và mình mới biết - rằng mình đang dùng OAuth Apps thay vì GitHub Apps.

Đây không phải lỗi duy nhất

Nhìn lại cả tuần build, mình thấy ít nhất 3 lần AI đưa ra gợi ý sai hoặc thiếu sót:

Lần 1: Mình cần đồng nghiệp không biết kỹ thuật có thể tự viết blog. AI đề xuất dựng thêm Payload CMS - một ứng dụng web riêng biệt chỉ để...

Ở các bài trước, mình đã chia sẻ cách mình setup môi trường viết bài:

1. Quản lý bài viết như một CMS
2. Template tự động điền thông tin
3. Sync qua iCloud để viết trên điện thoại

Đến đây, việc viết lách cơ bản đã ổn. Nhưng vẫn còn một khâu cuối cùng: Cập nhật bài viết lên web.

Blog mình dùng Astro, nên muốn có bài mới thì phải đẩy code lên GitHub. Cloudflare Pages sẽ tự động nhận trigger từ GitHub và build lại trang web.

Bình thường, để đẩy code lên, mình phải mở Terminal gõ lệnh hoặc dùng GitHub Desktop. Nhưng việc phải chuyển qua lại giữa các ứng dụng cũng hơi bất tiện mỗi khi mình đang tập trung viết trong Obsidian.

🛠️ Giải pháp: Obsidian Git Plugin

Mình dùng plugin Obsidian Git để đơn giản hóa việc này ngay trong giao diện soạn thảo.

Cấu hình đơn giản

Mình không để mặc định mà chỉnh lại một chút trong phần settings cho phù hợp với thói quen cá nhân:

• Backup interval: Mình chỉnh về (tắt tự động backup). Mình muốn tự quyết định khi nào thì push git, tránh việc plugin tự đẩy lên git khi bài viết chưa hoàn thiện.

Cách mình dùng

Khi viết xong bài, mình mở Command Palette (hoặc dùng phím tắt) rồi chọn lệnh Create backup.

Plugin sẽ tự động commit và push toàn bộ thay đổi lên GitHub. Sau đó Cloudflare Pages sẽ tự build và deploy web.

📱 Trên điện thoại thì sao?

Vì mình để toàn bộ dữ liệu trong iCloud (kể cả phần quản lý lịch sử Git), nên trên điện thoại plugin này vẫn hoạt động y hệt trên máy tính.

Workflow của mình khá đơn giản:

1. Viết bài trên điện thoại.
2. Viết xong, mở Command Palette chọn Create backup.
3. Xong.

Nhờ vậy, mình có thể tranh thủ viết và đăng bài thuận tiện hơn.

Lời kết

Hy vọng những chia sẻ này giúp bạn có thêm một vài gợi ý cho chiếc blog của riêng mình. Cảm ơn bạn đã đọc hết series này <3.

Ở bài trước, mình có nói về việc quản lý bài viết trên Obsidian. Một trong những lý do chính mình chọn cách này là để có thể tranh thủ viết bài trên điện thoại khi ra ngoài quán cafe hoặc nằm trên giường.

Để làm được việc đó, mình cần lưu toàn bộ folder dự án blog vào iCloud.

Tuy nhiên, có một vấn đề nhỏ: Dự án code (như Astro) thường chứa folder rất nặng, gồm hàng trăm file nhỏ. Việc sync đống file này qua iCloud vừa lâu, vừa không cần thiết (vì điện thoại không chạy code này).

Mình cần iCloud chỉ sync file bài viết () và bỏ qua các folder kỹ thuật.

⚙️ Cách giải quyết: .nosync và Symlink

Mình tìm hiểu được một cách khá hay trên macOS để xử lý việc này.

Cơ chế đơn giản là:

1. : iCloud sẽ tự động bỏ qua bất kỳ file/folder nào có đuôi này.
2. Symlink (Symbolic Link): Tạo một liên kết tham chiếu tới folder gốc. Nhờ vậy, code editor vẫn truy cập và làm việc với folder này bình thường.

Cụ thể: Mình đổi tên thành (để iCloud bỏ qua không sync). Sau đó tạo một shortcut tên là trỏ về nó (để code editor vẫn chạy bình thường).

🛠️ Cách mình làm

Mình mở Terminal ngay tại folder dự án và chạy 2 dòng lệnh:

Mình làm tương tự cho folder (folder build).

📱 Kết quả

Lúc này, khi mở folder dự án trên iPhone/iPad, thư mục sẽ không còn xuất hiện. Thay vào đó là file shortcut có dung lượng rất nhỏ.

Nhờ vậy, mình có thể mở file Markdown lên viết mà không phải đợi iCloud load những file không liên quan. Trên máy tính thì source code vẫn đầy đủ để chạy và build web.

⚡️ Tips tối ưu

Nếu bạn ngại gõ lệnh mỗi lần thì có thể dùng 2 cách sau:

1. Script tự động (Cho Terminal)

Thay vì phải nhớ và gõ lại hai dòng lệnh trên mỗi khi tạo dự án mới, bạn có thể tạo một hàm tắt (alias) trong Terminal.

Bước 1: Mở file cấu hình của Terminal (trên Mac thường là ) bằng lệnh:

Bước 2: Kéo xuống cuối file và dán đoạn code này vào:

(Xong thì bấm rồi để lưu, để thoát)

Bước 3: Cập nhật thay đổi:

Từ giờ, khi làm dự án mới, bạn chỉ cần mở Terminal ngay tại folder đó và gõ lệnh (ví dụ: ).

2. Dùng AI

Nếu bạn dùng Antigravity hay các AI Assistant có quyền chạy terminal, cứ copy prompt này cho nó làm giúp:

---

Bài tiếp theo: Sau khi viết xong trên điện thoại, làm sao để đẩy bài lên web?
→ Git Workflow trong Obsidian

Ở bài trước Setup Obsidian Template, mình đã giải quyết xong khâu tạo bài viết.

Hiện tại blog mình mới chỉ có khoảng hơn chục bài thôi. Tuy nhiên, bắt đầu có những lúc mình muốn tìm lại một bài cũ để sửa, hoặc check xem bài nào đang viết dở, thì việc phải lướt trong danh sách file rồi mở từng cái cũng hơi thủ công.

🤔 Vấn đề: Muốn nhìn tổng quan hơn

Bình thường code editor chỉ hiện danh sách tên file. Muốn biết bài nào (nháp) hay (đã đăng), hay bài nào chưa có ảnh cover, mình phải mở file đó ra mới thấy.

Với số lượng bài ít thì không sao, nhưng mình muốn có một cái nhìn tổng quát hơn.

🛠️ Giải pháp: Properties View

Obsidian có sẵn tính năng Properties View. Hiểu đơn giản là nó gom thông tin Frontmatter của các bài viết lại và hiển thị dưới dạng bảng.

Cách bật

Trước tiên, bạn cần bật plugin Properties View trong phần Core Plugin của Obsidian.

Sau đó, bạn cần chọn folder chứa các bài viết của mình (ở đây là ), và chọn "New Base".

Sử dụng thực tế

Mình chủ yếu dùng view này để:

1. Check bài nháp: Nhìn cột , thấy cái nào đang checked thì biết là chưa đăng.
2. Check ảnh bìa: Lướt cột , thấy ô nào trống thì bổ sung.
3. Xem ngày đăng: Sort cột để xem thứ tự bài viết.

Đơn giản vậy thôi. Nó giúp mình quản lý danh sách bài viết trực quan hơn chút so với việc chỉ nhìn list file.

Một cái tiện nữa là mình có thể sửa thông tin ngay trên bảng. Ví dụ muốn publish bài nào thì bỏ tick ngay tại bảng, đỡ phải mở file.

---

Kết luận

Với nhu cầu blog cá nhân đơn giản, plugin Properties View có sẵn của Obsidian là đủ để mình quản lý bài viết. Không cần cài thêm plugin, không cần setup phức tạp.

Bài tiếp theo: Làm sao để viết được trên cả điện thoại lúc ra ngoài?

→ Mời bạn xem tiếp: .nosync và Symlinks tối ưu iCloud

Ở bài trước Tận dụng Obsidian làm editor chính, mình có nhắc đến "nỗi đau" khi phải gõ tay từng dòng Frontmatter cho mỗi bài viết mới.

Hôm nay mình sẽ chia sẻ chi tiết cách mình xử lý vấn đề này bằng plugin Templater.

🤔 Tại sao cần Templater?

Ban đầu mình nghĩ dùng tính năng Templates có sẵn (Core Plugin) của Obsidian là đủ. Nhưng nó quá đơn giản, chỉ chèn được ngày giờ và một vài thông tin cơ bản.

Nhu cầu của mình thì phức tạp hơn:

1. Hỏi tiêu đề ngay khi tạo: Không muốn phải click vào title để sửa.
2. Slug tự động: Mình muốn nhập tiêu đề "Cách nấu phở" thì nó phải tự sinh ra slug (bỏ dấu tiếng Việt, thay khoảng trắng...).
3. Tên file chuẩn: Tự động đổi tên file thành .

Nên mình lựa chọn cài thêm plugin Templater (với khả năng chạy JavaScript) để có thể tự động hóa quy trình này.

🛠️ Các bước Setup

Bước 1: Cài đặt Plugin

Vào Settings → Community Plugins → Tắt "Restricted mode" → Tìm và cài Templater.

Bước 2: Chuẩn bị folder chứa template

Mình tạo một folder riêng để chứa các file mẫu, ví dụ: .

Vào Settings → Templater, ở mục "Template folder location", trỏ đến folder vừa tạo.

Bước 3: Tạo file Script

Tạo một file mới trong folder template đó, đặt tên là . Copy đoạn code này vào:

Cách script này hoạt động:

1. Hỏi tiêu đề: Khi chạy, nó sẽ hiện một popup hỏi bạn "Bài này tên gì?".
2. Xử lý Slug: Nó dùng JavaScript để biến "Tiếng Việt có dấu" thành "tieng-viet-khong-dau".
3. Tự đổi tên file: File sẽ tự biến thành .
4. Đặt trỏ chuột: sẽ đưa con trỏ chuột xuống dưới cùng, sẵn sàng để bạn viết.

🚀 Sử dụng

Quy trình viết bài mới của mình giờ chỉ còn 2 bước:

1. Bấm để tạo file mới từ template (phím tắt mình gán cho Templater).
2. Nhập tiêu đề và Enter.

Bùm! File được đổi tên, frontmatter được điền, và mình có thể bắt đầu viết ngay lập tức. Mọi thứ diễn ra trong chưa đầy 5 giây.

Bạn có thể áp dụng cách này cho Daily Note, Project Note, hay bất cứ loại nội dung nào có cấu trúc lặp đi lặp lại.

---

Bài tiếp theo: Sau khi tạo bài viết dễ dàng rồi, làm sao để mình có thể quản lý danh sách hàng chục bài viết?
→ Mời bạn xem tiếp Quản lý danh sách bài Blog với Obsidian Properties

Blog của mình build bằng Astro. Bản chất các bài viết là file Markdown (, ) nằm trong folder .

Ban đầu mình viết blog bằng code editor. Cũng không có vấn đề gì - đằng nào cũng là edit file Markdown. Nhưng sau khoảng 10 bài, mình bắt đầu thấy một số điểm không ổn.

🤔 Vấn đề khi viết nhiều bài

1. Frontmatter lặp đi lặp lại

Mỗi bài viết Astro bắt buộc phải có YAML frontmatter:

Quy trình tạo bài mới:

1. Mở một bài cũ
2. Copy frontmatter
3. Paste sang file mới
4. Sửa tay từng field: title, slug, date...

Làm vài lần thì ổn, nhưng làm hoài thấy mất công ghê! Đặc biệt là phần slug và rename file - mình thường xuyên gõ sai hoặc quên format ngày tháng. Chưa kể việc phải xóa dấu tiếng Việt thủ công cho slug nữa.

2. Khó quản lý trạng thái bài viết

Khi có nhiều bài, mình không biết:

• Bài nào đang ở trạng thái nháp?
• Bài nào chưa có description?
• Bài nào thiếu cover image?

File explorer của code editor chỉ hiện danh sách các file . Mình phải mở từng file để kiểm tra.

3. Vẽ diagram phải dùng app khác

Khi cần vẽ ảnh minh hoạ:

1. Mình mở Excalidraw.com hoặc Figma
2. Vẽ xong export ảnh
3. Copy vào folder
4. Import ảnh vào bài viết

Mỗi lần muốn sửa lại phải lặp lại từ đầu.

4. Không đồng bộ giữa các thiết bị

Code editor chủ yếu dùng trên laptop. Muốn viết bài trên iPad hay iPhone thì mình phải vào GitHub edit trực tiếp (rất mất công), hoặc dùng app note tạm rồi về máy tính viết lại.

Trước đây mình thậm chí còn nghĩ ra workflow đăng bài qua Telegram Bot để giải quyết vấn đề này.

---

🛠️ Obsidian giải quyết như thế nào?

1. Tự động frontmatter với Templater

Plugin Templater giúp tự động hóa việc tạo frontmatter.

Mình tạo một file template. Khi tạo bài mới, template sẽ:

• Hỏi tiêu đề bài viết
• Tự động tạo slug từ tiêu đề (ví dụ: "Hướng dẫn Obsidian" → )
• Tự động điền ngày tháng hiện tại
• Tự động đổi tên file thành

Quy trình tạo bài mới:

1. Tạo file mới
2. Apply template
3. Nhập tiêu đề
4. Xong

Không cần copy-paste hay sửa tay nữa.

2. Quản lý với Base View

Obsidian có tính năng Base View - xem tất cả bài viết dưới dạng bảng.

Mình có thể:

• Lọc bài viết theo trạng thái:
• Sắp xếp theo ngày
• Nhóm theo category

Thay vì phải mở từng file để kiểm tra như trước.

(Chi tiết: Quản lý danh sách bài Blog với Obsidian Properties)

3. Vẽ trực tiếp với Excalidraw

Plugin Excalidraw cho Obsidian:

• Vẽ ngay trong Obsidian
• File lưu trong vault
• Khi cần dùng cho blog: Mở file → Copy as PNG → Dán trực tiếp vào bài viết
• Muốn sửa thì chỉ cần mở file sửa rồi copy-paste lại

Không cần phải chuyển qua app khác.

4. Viết trên nhiều thiết bị

Vault Obsidian mình để trong iCloud. Kết hợp với kỹ thuật (để chặn sync các...

Định nghĩa

Dry run là chế độ chạy thử trong đó chương trình thực thi toàn bộ logic, nhưng không tạo ra bất kỳ thay đổi thực tế nào lên dữ liệu hay hệ thống.

Nói cách khác:

• Hệ thống chạy thử toàn bộ logic.
• Báo trước các bước và kết quả dự kiến.
• Nhưng không tạo ra tác động thật (không ghi dữ liệu, không thay đổi trạng thái của bất kỳ dữ liệu nào, không ảnh hưởng hệ thống).

Tại sao cần Dry run?

• ✅ Nhìn thấy chính xác những gì thật sự sẽ diễn ra.
• ✅ Kiểm tra tính chính xác, ngăn chặn sai sót trước khi chạy thực tế.
• ✅ Xem trước kết quả để quyết định có làm thật hay không.

Để dễ hiểu hơn, có một khái niệm khá tương đồng và được sử dụng rộng rãi hơn trong các buổi biểu diễn - "Rehearsal".

• Rehearsal (Dry Run): Diễn thử gần như giống 100% buổi biểu diễn chính thức để xem mọi thứ vận hành ra sao, nhưng chưa có khán giả thật.
• Buổi biểu diễn thật: Làm thật, có khán giả, có kết quả thật.

Áp dụng thực tế

Mình có một script để chuyển đổi link ảnh từ định dạng Obsidian wikilink sang Markdown chuẩn. Script này có quyền đọc, sửa và ghi đè hàng loạt file nội dung.

🤔 Vấn đề:

Chỉ cần có một vài lỗi nhỏ trong logic:

• Link của toàn bộ các file có thể bị sai hàng loạt.
• Để khôi phục về lại trạng thái ban đầu trước khi thay đổi sẽ rất mất thời gian.

💡 Giải pháp:

Trước khi chạy thật, mình bật chế độ dry run:

• Script đọc toàn bộ file như bình thường.
• In ra danh sách file sẽ bị thay đổi.
• Hiển thị nội dung trước / sau của từng chỗ bị convert.
• Nhưng không ghi bất kỳ thay đổi nào vào file.

⚡️ Kết quả:

• Mình nhìn thấy chính xác script sẽ làm gì.
• Dễ dàng phát hiện một vài trường hợp chưa xử lý đúng để sửa lại logic.
• Sau khi output dry run đúng như mong đợi, mình mới cho chạy thật.

---

Góc tò mò

Theo một số nguồn tài liệu mình tìm được, thì thuật ngữ Dry run xuất phát từ huấn luyện chữa cháy vào đầu thế kỷ XIX.

• Dry run (Diễn tập khô): Thực hành với vòi phun nước nhưng không có nước (khô).
• Wet run (Diễn tập ướt): Chữa cháy thực tế với nước thật.

Sau đó được áp dụng bởi:

• Quân đội (diễn tập không dùng đạn thật)
• Hàng không (các chuyến bay mô phỏng)
• Kỹ thuật phần mềm (kiểm thử mà không thay đổi)

Nguồn tham khảo:

• https://dictionary.cambridge.org/dictionary/english/dry-run
• https://www.wordorigins.org/big-list-entries/dry-run
• https://www.worldwidewords.org/qa-dry1.html

Ngữ cảnh:

• Có những suy nghĩ, ý tưởng xuất hiện trong đầu và mình muốn post nhanh những suy nghĩ đó.
• Với workflow hiện tại, buộc mình phải suy nghĩ tiêu đề cho bài post, việc này cũng tạo khá nhiều rào cản khiến dòng suy nghĩ của mình bị ngắt quãng.

Giải pháp:

Để giải quyết vấn đề trên, mình có một vài ý tưởng:

1. Dùng AI tự động đọc nội dung rồi viết lại tiêu đề
   
   --> Cách này về mặt hiệu quả có vẻ ổn, tuy nhiên sẽ hơi mất công setup và tốn tài nguyên nhất định cho AI. Nhưng liệu có cần thiết không hay mình đang lấy dao mổ trâu để mần gà?
2. Quy định một cấu trúc mặc định cho bài post
   
   --> Ví dụ: "Ghi chú - Ngày giờ"
3. Cũng tương tự cách 2, nhưng để có ngữ nghĩa hơn thì dùng câu đầu tiên trong nội dung bài post làm tiêu đề.
   
   --> Mình chọn cách này, vì cảm giác nó vẫn rõ ràng và có ý nghĩa hơn cách 2. Tuy nhiên cũng cần lưu ý câu đầu không nên viết quá dài để đảm bảo bảo thẻ tiêu đề không "lố" SEO.

Xong, giờ thì cứ post vào rơi vào trường hợp trên thì mình ẩn tiêu đề bài post trên giao diện để nhìn nó hợp lý hơn (bằng CSS).

Homepage mobile khi mới vào cảm giác nhìn hơi trống, thiếu sự kết nối giữa header và các bài post. Nên mình nghĩ mình sẽ làm cái gì đó ở đây, để tạo sự liền mạch.

Lượn một vòng tìm ý tưởng, Substack vẫn là trang hợp với gu mình nhất, nên mình sẽ làm cái thanh Categories ở trước danh sách bài post.

User vừa có thể nắm bắt nhanh những danh mục chính mà blog mình có, cũng thấy "dễ thở" hơn khi vào trang đã đập vào mắt toàn chữ là chữ.

Mỗi tội mình lười làm ảnh đại diện cho từng category ghê 🙂‍↕️

Tuần trước, trong quá trình chuẩn bị cho một chiến dịch marketing với mã giảm giá trên landing page, team mình đã tạo một mã test giảm 100% để kiểm thử quy trình thanh toán. Khi chính thức mở landing page để đăng ký, mình đã dựng một Dashboard dạng Leaderboard để theo dõi hiệu quả sử dụng của các mã giảm giá.

Và bất ngờ, một mã giảm 100% nội bộ xuất hiện trên Leaderboard… tá hoả luôn! Cũng may là có dashboard đó, nếu chỉ dựa vào danh sách đơn hàng, khả năng cao là mình đã lướt qua mà không để ý.

Leaderboard mình dựng nhanh để dễ dàng theo dõi số mã được sử dụng.

Điều mình học được từ vụ này

• Khi nhìn vào danh sách đơn hàng, mã test 100% rất dễ bị lẫn giữa hàng trăm đơn hàng khác. Mình đã từng lướt qua mà không nhận ra có đơn dùng mã đó.
• Xem bảng xếp hạng mã ref giúp mình nhận diện dễ hơn, vì khi nhìn vào danh sách trên bảng xếp hạng, tự dưng “mã lạ” lại nhô lên. Trường hợp này, mã test nội bộ rõ ràng trên bảng, nên mình phát hiện nhanh.
• Việc trực quan hóa dữ liệu giúp mình nhanh chóng nhận ra các điểm bất thường hơn. Một bảng xếp hạng đơn giản đã giúp mình nhìn thấy những mã không hợp lệ mà rất khó có thể nhận ra từ dữ liệu thô.

Sau khi phát hiện ra mã bất thường, team mình đã phải xử lý và chuẩn bị một checklist nghiêm ngặt hơn để kiểm soát mã test trước khi chạy thực tế.

Bài học nhớ đời luôn!