Chủ đề thì không phải nghĩ lâu. Sử Việt có những trận đánh ai cũng thuộc — bãi cọc, con nước, thuyền giặc mắc cạn — nhưng hiếm khi được kể bằng game. Còn hình ảnh thì có sẵn một thứ rất Việt Nam mà người nước ngoài nhìn là nhận ra: múa rối nước.

Game kể chuyện trên sông Bạch Đằng

Bạch Đằng là game kể chuyện có lựa chọn. Mỗi chương là một trận trên sông Bạch Đằng: năm 938 Ngô Quyền, năm 981 Lê Hoàn, năm 1288 Trần Hưng Đạo. Hiện mình mới làm chương 1, tên ngắn gọn: 938.

Các bạn vào vai Dương Lãng, con trai một người chài bị cả làng coi là "kẻ dẫn giặc". Lãng được Dương Đình Nghệ nhận làm con nuôi, rồi phải đọc con nước để giăng bẫy cọc cho Ngô Quyền — trong khi người cha tưởng đã chết lại đang đứng mũi hạm đội Nam Hán. Câu hỏi xuyên suốt chương: "Làm con thì nợ ai?"

Một lần chơi khoảng 35–45 phút, gồm 22 cảnh, 5 quyết định lớn và 7 kết cục.

Rối nước, tranh khắc gỗ và chú Tễu

Phần mình khoái nhất là cách diễn. Nhân vật là con rối có khớp — đầu, thân, tay hai khúc — nhấp nhô như trên mặt nước, diễn trên sân khấu thủy đình. Màu lấy từ tranh khắc gỗ dân gian: giấy điệp, đỏ son, vàng hoè, chàm. Nhạc là đàn bầu, sáo trúc, trống, chiêng, điệu hò kéo lưới.

Như một buổi rối nước thật, chú Tễu ra mở màn và khép màn. Tễu vẽ theo lối tranh Đông Hồ, đứng ngoài truyện. Giữa các hồi, khi rèm đỏ son kéo kín, Tễu ra pha vài câu hóm hỉnh với bà con — nhưng không bao giờ đùa về cái chết hay về sử.

Game cũng theo nguyên tắc "diễn chứ không kể": cảnh tự chạy theo đoạn như xem phim, phụ đề tối đa 2 hàng, người chơi chỉ chạm ở cuối đoạn, lúc chọn và lúc tương tác. Cảnh 1 dài khoảng 3 phút mà chỉ cần 4 lần chạm.

Lịch sử là xương sống

Làm game về sử rất dễ trượt sang một trong hai cực: bóp méo cho kịch tính, hoặc giọng tuyên truyền. Nên trước khi viết cảnh nào, mình chốt mấy luật:

• Chính sử giữ nguyên ở mọi nhánh: người chơi chỉ quyết định trong những khoảng trống mà sử không ghi.
• Hư cấu có nhãn: mỗi chi tiết gắn tầng nguồn — [CS] chính sử, [TT] thần tích, [SL] suy luận hiện đại, [HC] hư cấu.
• Đối thủ là người thật: phía Nam Hán có người khôn kẻ dại, có lời can đúng. Thắng một đối thủ đáng gờm thì chiến thắng mới có sức nặng.
• Thua cũng không đổi sử: kết cục xấu luôn khép bằng câu "Nhưng lịch sử đã không diễn ra như thế."

Cuối chương có màn "Lịch sử thật" tách bạch đâu là sử chép, đâu là game viết thêm. Có một chi tiết khá vui: Hoằng Tháo chết ở Bạch Đằng, nhưng Toàn thư, Cương mục và Tân Ngũ Đại sử mỗi bộ ghi một kiểu. Lựa chọn cuối của người chơi sẽ khớp với một trong ba cách đó.

Canh con nước

Ngoài lựa chọn, cơ chế chính là canh con nước, 3 lượt: kéo vạch trên cây sào để đặt độ cao cọc, xuất thuyền mồi, phất cờ xuất kích. Mực nước chạy theo nhật triều — gần đỉnh thì chậm, rút giữa chừng thì nhanh. Lựa chọn trước đó cũng ăn vào đây: càng hiểu sông, cửa sổ thời gian càng rộng.

Mình thích nhất chỗ lòng tin biến thành cơ chế. Khi Ngô Quyền chưa tin Lãng, người cầm cờ là Tam Kha, và lá cờ phất chậm hơn cú bấm của các bạn một nhịp.

Cân bằng thì cho chạy hết 81 tổ hợp quyết định: canh nước giỏi thì phần lớn đường đi tới kết cục tốt nhất, canh trung bình thì không, và không có tổ hợp nào luôn đúng.

Web trước, Godot sau

Bản đầu mình làm trên web — JavaScript, SVG, nhạc tổng hợp bằng Web Audio. Từ kịch bản tới đủ 22 cảnh có hoạt hình mất khoảng hai ngày, rồi mời người chơi thử ba lượt và sửa theo feedback.

Câu chuyện đứng được, nhưng điện thoại thì không: bố cục vỡ, nên bản web phải tạm chặn điện thoại. Thay vì đắp tiếp, mình coi bản web là một bản đặc tả chạy được và làm lại từ đầu cho iOS, Android trên Godot 4.7.

Lý do chọn Godot khá thực dụng. Hình trong game vẽ bằng code, nên engine nào cho làm mọi thứ bằng file chữ — cảnh, hoạt cảnh, dữ liệu — sẽ nhanh hơn hẳn engine nặng thao tác kéo thả trong editor.

Port 22 cảnh sang Godot chia 5 đợt, xong trong một ngày. Phần tốn công là chạy trên máy thật: con Pixel 3 cũ bị văng game ngang cảnh 9 vì rò bộ nhớ ảnh. Phải sửa rò, ẩn phần cảnh nằm dưới màn canh nước, làm shader khắc gỗ rẻ hơn và tự hạ độ nét khi tụt khung hình thì mới giữ được 60 fps.

Claude làm, mình chốt

Code, hình vector, nhạc tổng hợp, tài liệu — gần như toàn bộ là Claude làm. Vai của mình là định hướng và chốt: tinh thần dự án, luật với lịch sử, giọng kể, chuyện gì giữ chuyện gì cắt.

Mọi thứ đi qua vòng phân tích → sửa → chốt, và bản chốt mới nhất là chuẩn. Kịch bản viết lại ba lần trong một ngày, phân cảnh review từng cảnh một, lời 22 cảnh viết lại theo giọng người phường rối kể tích. Chú Tễu ra giữa hồi ba lần cũng là một quyết định mình chốt sau khi cân nhắc.

Claude không thay được chuyên gia sử và hải văn. Bản thử thì đủ, nhưng trước khi phát hành công khai, game cần người có chuyên môn duyệt lại sử và con nước.

Gần đây mình cài thêm Claude Code Game Studios — bộ agent, skill, hook dựng sẵn quy trình của một studio game — để làm một vòng chơi mới: hỏi người. Ở cảnh truy kẻ nội ứng, Lãng phải hỏi từng người, nối các thẻ lời khai trong Sổ tay và bác từng lời tố bằng chứng cứ, chỉ trong 6 lượt hỏi.

Sắp lên sân khấu

Bước tiếp theo là mời chơi thử chương 1 trên điện thoại. Bạn nào muốn xem buổi diễn sớm thì đăng ký ở bachdang.taiphanvan.dev =)).

Rèm đỏ son sắp mở. Hẹn các bạn ở bài sau, khi có feedback đợt chơi thử đầu tiên.

Mỗi lần quay lại là một lần khảo cổ: git log, mở App Store Connect, lục note cũ. Vài lần như vậy thì mình thấy không ổn, phải đổi workflow hoặc dùng tool, automation gì đó thôi. Vừa hay dạo này đang có trend build lại app từ đầu — ArtCraft build lại cả bộ app của Adobe — nên mình cũng tự build một app mới cho nhu cầu của chính mình: Shipdeck.

Shipdeck là gì

Shipdeck là một app macOS native (SwiftUI) gom mọi product của mình vào một cửa sổ. Mỗi product gồm một hoặc nhiều component — iOS app, backend, landing page — nằm rải rác ở một hay nhiều repo.

Mở app lên, màn Overview xếp product vào 4 nhóm, kèm lý do viết rõ ràng:

• Needs a release: kiểu "5 commits since 2.3.0 went live".
• In progress: còn file chưa commit hoặc chưa push.
• Quiet for a while: lâu rồi không có commit nào.
• All good: đã ship, không còn gì treo.

Phần này chạy hoàn toàn không dùng AI. Shipdeck tự đọc git, version trong manifest, appcast của Sparkle và iTunes Lookup. Boring tech — nhanh, chắc, không tốn token.

Claude đọc repo, mình quyết

Thêm product thì chỉ cần chọn folder. Một session Claude Code headless, read-only sẽ survey repo: tách component, tìm command build/test, service, docs, tra app trên store. Sau đó mình review từng bước, field nào AI điền thì nguồn của nó nằm ngay cạnh, một click là thấy.

Survey chạy ở chế độ --restricted, không có shell, file bị git-ignore và file secret như .env đều bị chặn — kể cả tên file non-ASCII hay nằm trong submodule.

Code đổi thì có Sync with Code: survey lại dựa trên các commit kể từ lần trước, list từng field thay đổi (cũ → mới), mình tick cái nào thì lưu cái đó. Toàn bộ data product nằm trong một file products.json trên máy, không ghi gì vào repo.

App Store Connect ngay cạnh code

Thêm App Store Connect key (lưu trong keychain) là mỗi iOS app có tab App Store: version, review state, phased release, TestFlight build, feedback của tester, review của user. Release một version hay reply review đều làm ngay trong app, có bước confirm.

Không còn cảnh mở cả chục tab browser để biết app nào đang "Waiting for Review".

Agent phải hỏi trước khi chạm vào Apple

Đây là phần mình khoái nhất. Mỗi product mở được session Claude Code ngay trong Shipdeck (terminal embedded bằng SwiftTerm), và session vẫn chạy khi mình chuyển sang product khác.

Mình muốn agent dùng được Shipdeck — đọc trạng thái product, xem App Store, trả lời review — nhưng không muốn nó tự ý đụng vào Apple. Nên mọi thay đổi, dù của mình hay của agent, đều đi qua một action layer. Ý tưởng này mình mượn từ ArtCraft: mọi action là một command có id cố định, nên GUI, CLI hay MCP đều gọi chung một đường. Mỗi action có một tier:

• read: đọc thông tin, chạy thoải mái.
• local: sửa data trên máy.
• remote: gọi ra ngoài, ví dụ reply review.
• publish: thứ user thấy được, ví dụ release version.
• owner: chỉ mình làm được.

Agent gọi Shipdeck qua Unix socket, command shipdeck hoặc MCP server, và bị nhốt trong đúng product của session đó. Action remote hay publish sẽ nằm chờ trong approval inbox: Allow Once, Deny kèm lý do (agent đọc được lý do), hoặc Always Allow cho riêng product đó — riêng publish thì lần nào cũng hỏi. Mọi lần chạy đều được ghi vào journal.jsonl để trace lại.

Bài này đang được viết trong một session Claude Code chạy bên trong Shipdeck =)).

3 ngày, từ 0.1.0 lên 0.6.3

Code do Claude Code viết — chuyện đó giờ chẳng còn gì lạ nữa. Việc của mình là product owner: nói rõ muốn gì, dùng thật hằng ngày, thấy chỗ nào lạc quẻ thì bắt sửa. Vài chỗ mình trực tiếp yêu cầu hoặc bắt lỗi:

• Agent không được tự ý đụng Apple → approval inbox và permission rules (0.6.0).
• AI không được tự ghi đè data → Sync with Code chỉ lưu field mình tick (0.6.1).
• Người lạ cài vào phải chạy được → kiểm tra máy chưa có Claude Code hay Command Line Tools, survey fail thì hiện rõ Claude Code in ra gì, thêm nút Send Feedback (0.6.2).
• Ô input của Claude bị trôi khi scroll → bật full-screen renderer của Claude Code để input luôn nằm dưới đáy (0.6.3).
• UI lỗi vặt: sheet Add Key bị collapse mất field, tab trên toolbar bị cắt khi chuyển product (0.4.4–0.4.5).
• Auto-update không lên bản 0.4.0 → root cause là zsh không tách ${sha:+-f sha=$sha} thành hai argument, GitHub từ chối update appcast. Một bug nhỏ xíu mà mất cả buổi.

Ba ngày, 21 commit, 14 bản release có auto-update qua Sparkle, signed và notarized đàng hoàng. Tốc độ này mấy năm trước mình không dám nghĩ tới.

Tiếp theo

Shipdeck chưa mở public, mình vẫn đang làm tiếp vài tính năng:

• Google Play trong Overview — đa số indie mobile dev ship cả Android, thiếu cái này thì chưa gọi là "mọi product trong một chỗ".
• Marketing: draft post từ data thật của product (version, commit từ bản trước, release notes), mình sửa rồi tự đăng.

Sau đó mới mời 10–20 người dùng thật, sửa những gì họ vấp phải, rồi mới tính chuyện launch. Thước đo mình đặt ra không phải lượt tải, mà là một tuần sau họ còn mở app không.

Bao giờ có bản cho các bạn thử, mình sẽ viết tiếp. Còn giờ thì quay lại ship đã.

"It's done. It's over." — Frodo, The Lord of the Rings.

Vấn đề: app "quick" nhưng vẫn chưa đủ quick

QuickSpend ban đầu mình build cho chính mình dùng — eat own dogfood, ít nhất để sản phẩm mọi người dùng được thì mình phải dùng được và thấy ổn trước đã. Dùng vài tháng thì lộ ra một điều khá đau lòng: chính mình vẫn quên ghi chi tiêu đều đặn =)).

Lý do thì quá đơn giản — vấn đề chắc chắn ai cũng gặp: quá lười, quá vội để note lại chi tiêu.

Cuối tháng nhìn lại chart, data thưa như tóc mình sau 30 tuổi. Vậy là vấn đề không nằm ở app, nó nằm ở bước phải mở app. Cái cần loại bỏ chính là cái đó. Mình muốn một flow mà user chỉ cần nói "chi tiêu nhanh 50k trà sữa" là xong, không cần tap gì hết, không cần nhìn màn hình, đẹp như mơ.

Hướng xử lý: đẩy entry point ra khỏi app

Trên iOS có hai con đường rõ ràng:

• Nói thẳng với Siri — kịch bản đẹp nhất, không tap gì hết, sang chảnh như quảng cáo Apple.
• Shortcuts — backup thực dụng cho khi Siri trở chứng. Trigger được bằng tap, widget, hoặc gọi qua Siri đều ngon.

Siri thì... vẫn ngu ngu, đôi khi mình hỏi giờ Hà Nội còn trả lời sai múi giờ =)). Nhưng Shortcuts là vũ khí mạnh thật trong hệ sinh thái Apple — một khi setup xong nó chỉ là một nút bấm. Nên mình build cả hai, dùng Shortcuts làm safety net để khi Siri drop ball thì user vẫn không bị chặn.

Luồng mới: hai kịch bản

Kịch bản 1 — qua Shortcut (path luôn work)

"Hey Siri, chi tiêu nhanh."

Siri trigger shortcut → shortcut hỏi lại "nội dung gì?" → user nói câu tự nhiên (ví dụ "50k trà sữa") → loading → AI parser xử lý.

Hai nhánh tuỳ confidence của parser:

• Confidence cao: app lưu luôn, Siri thông báo "đã ghi", end flow. Không cần mở app, không cần nhìn màn hình, đẹp như mơ.
• Confidence thấp: app mở ra với UI listing transaction được parse, user confirm lưu hoặc cancel. App không tự tin thì cứ hỏi, hơn là lưu bừa rồi user phải vào sửa.

Kịch bản 2 — gọi thẳng app qua Siri (path đôi khi work)

"Hey Siri, dùng Chi tiêu nhanh để thêm chi tiêu 50k uống trà sữa."

Kịch bản đẹp: Siri hiểu intent, gọi thẳng app, app nhận text Siri đã transcribe sẵn → AI parser xử lý y hệt luồng trên. Đỡ hẳn một bước — user không phải đợi Siri hỏi lại "nội dung gì". Sướng phải không nào?

Đời không như là mơ. Mình test khá nhiều lần, kết quả không hề ổn định =)). Mà oan cho Siri một phần — đào sâu vào API mới phát hiện đây không hoàn toàn lỗi của em ấy: AppShortcutsProvider của Apple chỉ cho phép phrase có parameter khi parameter là AppEntity hoặc AppEnum. Với free-form String (như nội dung chi tiêu), phrase bắt buộc phải open-ended — Siri trigger intent rồi mới hỏi lại "What expense should I add?". Mình sẽ nói thêm ở phần kỹ thuật bên dưới.

Hệ quả: câu kiểu "Hey Siri, dùng Chi tiêu nhanh thêm 50k trà sữa" về mặt API là không declarable được, Siri đoán mò. Đó là lý do Shortcut variant tồn tại — nó là path mình tin được, khi Siri đang có hứng làm việc thì kịch bản 2 mới đẹp.

Nghe đồn với Apple Intelligence thì Siri sẽ thông minh hơn, hy vọng là vậy để kịch bản 2 ổn định hơn trong tương lai. Hiện tại thì mình chưa test được vì đang chỉ có iPhone 15, bạn nào có iPhone 16 Pro hoặc 17 thử giúp mình xem Apple Intelligence có cứu được kịch bản 2 không nhé =)).

Mấy vấn đề khi build feature này

Đồng bộ ngôn ngữ giữa Siri và app. Trước đó QuickSpend tách ngôn ngữ hiển thị và ngôn ngữ transcribe — user có thể chạy UI tiếng Anh nhưng voice input tiếng Việt, kiểu menu Tây mà order Việt. Khi thêm Siri vào, separation đó vỡ — Siri chỉ nói một ngôn ngữ tại một thời điểm theo system. Mình phải bỏ tách biệt đó, gộp về một locale duy nhất. Trade-off đáng vì consistency quan trọng hơn flexibility mà chắc chỉ có mỗi mình dùng.

Tên app khi Siri gọi. Như đã thấy ở kịch bản 2 — Siri nhận diện app name không ổn định, đặc biệt khi user trộn Anh–Việt trong câu lệnh. Mình thử nhiều phrasing khác, kết quả tốt nhất hiện tại vẫn là: đừng tin Siri, dùng Shortcut.

Liên quan đến tên app nữa, mình đã thêm tên app theo locale: tiếng Việt là Chi tiêu nhanh, tiếng Anh vẫn là QuickSpend, còn tiếng Nhật, tiếng Tây Ban Nha nữa — không nhớ là gì, dùng translator dịch =)).

Với tên app như vậy, khi trigger bằng Siri sẽ có câu kiểu:

"Hey Siri, thêm chi tiêu vào Chi tiêu nhanh."

Nghe nó lủng củng sao sao ấy, nhưng chưa biết làm sao vì để Siri nhận diện thì vẫn phải kèm tên app.

Phần kỹ thuật (skip OK nếu không quan tâm)

Section này dành cho ai tò mò Apple stack. Không quan trọng để dùng feature — nhảy thẳng xuống phần tổng kết cũng được.

Bốn thành phần chính:

• App Intent (AddExpenseIntent) — define action với @Parameter text + requestValueDialog ("What expense should I add?"). Return type IntentResult & ShowsSnippetView & ProvidesDialog để Siri vừa đọc dialog vừa show snippet card. Đặt openAppWhenRun = false để happy path chạy hoàn toàn ngoài app — không launch UI, Siri đọc kết quả là xong.
• AppShortcutsProvider + localized phrases — declare phrases EN với \(.applicationName) interpolation, các locale vi/ja/es seed vào AppShortcuts.xcstrings. Limitation đã nhắc ở trên: phrase chỉ accept parameter là AppEntity/AppEnum. Với free-form String thì phrase bắt buộc open-ended, Siri phải hỏi value qua dialog — đây là root cause của kịch bản 2 flaky.
• Snippet view + confirm flow — ParsedExpenseSnippetView là SwiftUI view render inline trong Siri card. Confidence ≥ 0.9 → .result(dialog:) auto-save, Siri đọc xác nhận, end flow. Confidence thấp → requestConfirmation(actionName: .log, dialog:, snippet:) ra card có nút Cancel / Log. Edge case khó chịu: label nút lấy từ system enum ConfirmationActionName, localize theo system locale chứ không theo app language — chưa fix được.
• Bundled Shortcut "Quick Expense" — chain Dictate Text → AddExpenseIntent, giúp user nói liền một mạch thay vì đợi Siri hỏi lại "nội dung gì". Đây là Shortcut cài qua link "Add to Shortcuts" ngay trong app.

Code chi tiết hơn để dành bài khác — bài này dài quá thì các bạn lại skip mất.

Tổng kết

Sau patch 3.0, QuickSpend cuối cùng cũng đúng cái tên Quick:

• ✅ Voice-first flow: log chi tiêu không cần mở app trong happy path.
• ✅ Shortcut safety net: luôn có path ổn định khi Siri trở chứng.
• ✅ AI parser auto-save khi confidence cao — Siri thông báo, không gián đoạn flow của user.

Điểm chưa ổn:

• ❌ Kịch bản "gọi thẳng app qua Siri" còn flaky. Mình đổ lỗi cho Siri, không nhận =)).
• ❌ Chưa test được với Siri có Apple Intelligence vì chưa lên đời máy xịn hơn iPhone 15. Bạn nào có iPhone 16 Pro hoặc 17 thử giúp mình, nếu Apple Intelligence cứu được kịch bản 2 thì mình sẽ rất biết ơn.

Feature này thực sự hữu ích với chính mình — ba ngày qua data trong app full hơn cả tháng trước cộng lại. Nếu các bạn cũng dùng QuickSpend, update lên 3.0 khi nó ship và quẩy thử. Feedback gì cứ ib mình hoặc gửi qua form feedback trong app — mình đọc hết.

Còn nhiều thứ phải cải thiện trong luồng này:

• Cho user edit trực tiếp transaction trong UI confirm khi parser nhầm — thay vì chỉ save / cancel.
• Polish prompt để parser thông minh hơn, handle được nhiều cách nói tự nhiên hơn của user.
• Tìm thêm hướng tối ưu luồng — bớt step, bớt loading, bớt phụ thuộc Siri nếu có thể.
• Khi có điều kiện nâng máy lên dòng có Apple Silicon hỗ trợ Apple Intelligence (iPhone 15 Pro trở lên), mình sẽ research Foundation Models framework (WWDC 2025) — Swift API gọi thẳng model ~3B on-device của Apple, có guided generation và tool calling. Hứa hẹn parser chạy hoàn toàn offline, không cần gọi cloud.

Hy vọng sẽ có bài kế nữa về QuickSpend — nếu có người dùng thật thì mình mới có động lực update tiếp =)).

Hẹn gặp lại ở bài sau.

Bắt đầu một thứ luôn là rất khó, duy trì nó lại càng khó hơn. Mình thích làm điều khó nên mình làm trang này =)).

Có thể viết bài với nhiều người là điều bình thường nhưng với mình thì đây là một bước nhảy vọt. Mình sẽ cố gắng duy trì đều đặn, không để quá 2 tuần không có bài mới. Sẽ không hoàn hảo, nhưng ai cũng phải bắt đầu từ đâu đó.

Bắt đầu của mình là từ đây, bài viết đầu tiên, sau nhiều năm lặng lẽ quan sát, lắng nghe, giờ đến lúc cất tiếng, chào thế giới.

Site này là gì

taiphanvan.dev không phải blog kỹ thuật thuần, cũng không phải portfolio. Đây là canvas cá nhân — chỗ mình tô vẽ mọi ý tưởng, ghi mọi thứ mình muốn ghi, làm mọi thứ mình muốn làm.

Lưu ý, mọi bài viết đều đậm tính cá nhân, nếu bạn thấy không hợp, có thể trao đổi với mình, mình luôn sẵn sàng mở rộng góc nhìn, tiếp cận vấn đề theo một góc khác — hoặc không, bạn có thể cứ lặng lẽ rời đi.

Mình đang chuyển sang làm sản phẩm

Trước giờ mình quen làm theo spec do người khác viết — thuần engineer. Mobile, web, vài năm chuyển stack, nhưng vai trò không đổi: nhận task, code, ship.

Cái mình đang đổi không phải stack — là vai trò. Mình muốn đứng từ đầu chuỗi: nhận diện vấn đề, design giải pháp, kiến trúc hệ thống, rồi mới đến code.

Gọi là gì cũng được — product owner, solution architect, system engineer — quan trọng là không gò bó vào 1 domain nữa. Mobile, web, backend, AI infra, devtools... ngon ở đâu thì làm ở đó. Stack chỉ là công cụ; vấn đề mới là cái cần giải.

Sẽ viết gì

Đối tượng đọc: bất cứ ai. Có thể là dev đang search debug log, có thể là bạn vô tình search "review phim X" rồi click vào.

Categories dự kiến:

• tech — note từ build production, debug stories, pattern lặp lại
• ai — cách mình dùng LLM trong daily work, thí nghiệm, thất bại
• product — quyết định thiết kế, trade-off giữa "ngon" và "ship được"
• film, books — cái mình vừa xem, vừa đọc, đáng ghi lại
• photography — ảnh chụp + ghi chú thiết bị / setup
• games — game đang cày, vài cảm giác về game design
• thoughts — bất cứ thứ gì còn lại

Không ép format. Một bài có thể 200 chữ, có thể 2000. Có quan điểm, không hedge. Sai thì sửa công khai.

Roadmap

Chưa có roadmap cụ thể về topic — đặt sẵn cứng dễ thành tự gò bản thân. Nhưng có cam kết về tần suất:

• Target: 1 tuần 2 bài.
• Mandatory: 1 tuần ít nhất 1 bài.

Tuần nào không có bài nào, coi như mình đang lười.

Hẹn gặp lại bro ở bài sau.