HTML hay Markdown: AI nên nói chuyện với bạn bằng cách nào?
Một kỹ sư Anthropic gần như bỏ Markdown. Phân tích cả hai phía của cuộc tranh luận đang viral.
Tuần trước tôi đọc một bài viết khiến tôi phải dừng lại và xem xét lại cách mình làm việc với AI.
Câu mở đầu của bài: “Thú thật là tôi đã ngừng dùng Markdown gần như hoàn toàn - dù phải nói trước, tôi có lẽ thuộc phe HTML maximalist khá cực đoan.”
Người viết câu đó không phải một blogger ngẫu nhiên - ông là Thariq Shihipar, kỹ sư trong team Claude Code tại Anthropic, công ty đứng sau Claude.
Bài viết của ông - “Using Claude Code: The Unreasonable Effectiveness of HTML” - viral trong vòng vài ngày. Simon Willison (một trong những tiếng nói uy tín nhất về công cụ AI) viết phản hồi. Hacker News có thread tranh luận sôi nổi. UX Hack Substack phân tích lại với tiêu đề khiêu khích: “Markdown is Dead?” (Markdown đã chết?).
Tại sao một bài viết về định dạng file lại gây ra phản ứng như vậy?
Vì đây không thực sự là bài về HTML. Nó là bài về cách con người và AI nên giao tiếp với nhau trong thời đại mà AI làm ngày càng nhiều việc thay chúng ta. Và câu trả lời của Thariq thách thức một quy ước đã tồn tại nhiều năm trong cộng đồng dev.
Trong bài viết này, tôi sẽ làm ba việc:
Tóm tắt chính xác lập luận của Thariq
Trình bày phía phản đối - những điều tác giả không nói tới
Đưa ra đánh giá cá nhân của tôi sau khi đọc cả hai phía
Mục tiêu không phải chọn phe, mà là giúp bạn tự quyết định cho cách làm việc của mình.
Bài gốc: “Using Claude Code: The Unreasonable Effectiveness of HTML” - Thariq Shihipar (@trq212), Engineer, Claude Code · Anthropic. Trang đi kèm với 20 ví dụ HTML thực tế: thariqs.github.io/html-effectiveness
⚠ Lưu ý trước khi đọc: Bài viết này phân tích quan sát thực tiễn của Thariq Shihipar - kỹ sư đang làm việc trực tiếp với AI hàng ngày tại team Claude Code (Anthropic) - chứ không phải kết luận từ nghiên cứu định lượng có đối chứng. Lập luận của ông dựa trên kinh nghiệm cá nhân và quan sát trong team; hiện chưa có dữ liệu so sánh chính thức giữa HTML và Markdown trong tương tác với AI. Phần phân tích, đánh giá sao ★, và khuyến nghị 4 con đường ở cuối bài là góc nhìn cá nhân sau khi đọc cả hai phía của cuộc tranh luận - không phải sự thật khách quan. Mời bạn đọc với tư duy phản biện. Mục đích bài viết không phải thuyết phục bạn chọn phe, mà cung cấp đủ thông tin để bạn tự quyết định cho cách làm việc của mình.
Phần 1 - Tại sao bài viết này gây bão?
Để hiểu được tại sao một bài viết về HTML lại làm cộng đồng dev tranh luận quyết liệt, bạn cần biết Markdown đã giữ vị trí thống trị như thế nào trong nhiều năm qua.
Markdown - định dạng văn bản nhẹ do John Gruber tạo ra năm 2004, với sự hỗ trợ quan trọng từ Aaron Swartz - đã trở thành một trong những ngôn ngữ định dạng phổ biến nhất trong cộng đồng dev và trong nhiều cách làm việc với AI. Trên GitHub, rất nhiều README, tài liệu kỹ thuật, issue, pull request và tài liệu được viết bằng Markdown hoặc GitHub Flavored Markdown - biến thể Markdown được GitHub mở rộng để phục vụ lập trình và cộng tác tốt hơn. Nhiều trợ lý AI hiện nay cũng thường hiển thị câu trả lời bằng Markdown hoặc các biến thể dựa trên Markdown. Markdown gần như đã trở thành một ngôn ngữ chung của tài liệu kỹ thuật hiện đại - quen thuộc đến mức nhiều người dùng nó mỗi ngày mà không còn đặt câu hỏi vì sao.
Thariq đặt câu hỏi đó. Và câu trả lời của ông có sức nặng vì nó đến từ chính người đang xây dựng Claude Code tại Anthropic. Trong bài, ông viết rõ rằng ngày càng nhiều người khác trong team Claude Code cũng đang chuyển sang HTML. Đây chỉ là quan sát của một người về một team - chưa đủ để gọi là “xu hướng ngành” - nhưng nó là tín hiệu đáng chú ý từ nội bộ một công ty đang xây dựng các sản phẩm AI hàng đầu.
Theo tôi quan sát, bài viết này viral không phải vì nội dung mới mẻ - mà vì nó đặt tên cho một cảm giác chung mà nhiều người đã âm thầm có nhưng chưa nói ra. Bất kỳ ai từng phải đọc một file Markdown 300 dòng do AI tạo ra đều biết cảm giác mệt mỏi đó. Chúng ta đã chấp nhận nó như một sự thật không thay đổi được.
Khi một người có tiếng nói “không, chúng ta không cần chấp nhận điều này” - đó là khoảnh khắc làm bùng phát thảo luận. Điều thú vị về trường hợp của Thariq: ông không phát minh ra HTML, không nghĩ ra khái niệm tương tác mới. Ông chỉ áp dụng một công cụ đã tồn tại 30 năm vào một ngữ cảnh mới - AI tạo nội dung cho người đọc. Đó là một dạng đột phá thầm lặng, vì nó không phải phát minh, mà là cách nhìn mới về cái cũ.
Phần 2 - Thariq Shihipar là ai, và tại sao điều ông nói có sức nặng?
Thariq Shihipar không phải một developer ngẫu nhiên trên Twitter. Ông là kỹ sư đang xây dựng Claude Code tại Anthropic - sản phẩm nổi tiếng nơi developers tương tác với AI để code, lên kế hoạch và làm việc kỹ thuật phức tạp. Trên website cá nhân, ông tự giới thiệu là “Engineer & serial entrepreneur” (kỹ sư và doanh nhân nhiều lần khởi nghiệp). Có nghĩa: ông ở vị trí trực tiếp xây dựng và quan sát cách AI tương tác với người dùng dev - một góc nhìn ít người ngoài Anthropic có được.
Bài viết của ông không phải lý thuyết. Nó kèm theo thariqs.github.io/html-effectiveness - một trang web với 20 file HTML cụ thể mà Claude Code đã tạo ra, được nhóm thành 9 nhóm công việc. Đó là bằng chứng có thể click vào xem, không phải lời nói suông.
Đây là điểm khiến bài viết khác biệt với những bài “X vs Y” thông thường: nó tự chứng minh luận điểm của mình. Bạn đọc bài viết về sức mạnh của HTML - và bằng chứng cho lập luận đó cũng là một trang HTML mà bạn đang tương tác.
Tôi đặc biệt ấn tượng với cách Thariq trình bày bằng chứng. Đây là một bài học về thuyết phục - bạn không chỉ nên nói ý tưởng của mình, mà nên thiết kế cách trình bày sao cho chính cách trình bày đó là bằng chứng cho ý tưởng.
Bài học rút ra cho người làm nội dung: nếu bạn nói về sức mạnh của một thứ, hãy dùng chính thứ đó để truyền tải thông điệp. Nếu bạn viết về tầm quan trọng của hình ảnh hoá thông tin, đừng dùng chữ - hãy dùng hình ảnh.
Phần 3 - Vấn đề gốc rễ: 3 thay đổi khiến Markdown trở nên lỗi thời
Lập luận của Thariq dựa trên ba quan sát kết hợp lại.
① AI ngày càng làm được nhiều hơn - nhưng Markdown không theo kịp
Khi AI chỉ trả lời câu hỏi đơn giản, một đoạn văn bản là đủ. Nhưng ngày nay, các tác nhân AI có thể đọc cả mã nguồn, phân tích lịch sử Git, tổng hợp dữ liệu từ nhiều nguồn (Slack, Linear, web) trong cùng một quy trình. Đầu ra giờ đây có chiều sâu thông tin mà chỉ riêng văn bản khó chứa được mà không trở thành một tường chữ.
Ví dụ Thariq đưa ra trong bài: Claude Code đã từng cố hiển thị màu sắc trong Markdown bằng cách dùng các ký tự unicode để “ước tính màu” - kèm ảnh chụp màn hình minh hoạ. Đó là dấu hiệu một công cụ thông minh đang bị buộc dùng định dạng quá hẹp.
② Bạn không còn tự chỉnh sửa nữa - nên lợi thế “dễ chỉnh sửa” mất ý nghĩa
Một trong những lý do Markdown thắng thế là “con người dễ chỉnh sửa được”. Nhưng theo Thariq: nếu cách làm việc của bạn là AI tạo file → bạn yêu cầu AI chỉnh sửa file → AI cập nhật - thì bạn chẳng bao giờ trực tiếp gõ vào file đó. Lợi thế “dễ chỉnh sửa cho người” trở nên ít quan trọng.
Lưu ý: Không phải ai cũng có cách làm này. Nhiều người vẫn trực tiếp chỉnh sửa đầu ra của AI - và đây là một trong những phản biện chính từ cộng đồng mà tôi sẽ trình bày ở Phần 6.
③ Bạn không đọc - và không thể bắt người khác đọc
Đây là điểm thực dụng và Thariq nói thẳng đến mức gần như là thú nhận: ông không thường đọc file Markdown dài hơn 100 dòng. Và ông không thể bắt đồng nghiệp đọc các tài liệu dài như vậy trong tổ chức.
“Thực tế là tôi thường không đọc một file Markdown dài hơn 100 dòng, và càng không thể bắt người khác trong tổ chức đọc nó.”
Thariq Shihipar (dịch từ bài gốc)
Trong ba điểm trên, điểm số 3 là điểm tôi thấy chính xác và đáng suy ngẫm nhất. Chúng ta sống trong ảo tưởng rằng việc tạo ra tài liệu = giao tiếp. Không phải. Giao tiếp chỉ xảy ra khi người nhận thực sự đọc và hiểu. Một tài liệu 500 dòng Markdown nằm trong thư mục của bạn không phải giao tiếp - đó là bụi tài liệu, viết ra rồi để đó.
Tôi nghĩ điểm này áp dụng rộng hơn nhiều so với công cụ AI. Trong nhiều tổ chức tôi quan sát, có rất nhiều “diễn tài liệu” - viết nhiều tài liệu để cảm thấy mình đã làm việc, nhưng không ai đọc. Câu hỏi đúng không phải “tôi có viết tài liệu không?” mà là “tài liệu của tôi có được đọc và hiểu không?”
Phần 4 - 6 lý do HTML thắng
Thariq đưa ra sáu lợi ích cụ thể. Tôi sẽ trình bày từng cái - kèm đánh giá xem điểm nào thuyết phục mạnh, điểm nào yếu hơn.
Các đánh giá ★ dưới đây là chủ quan - phản ánh cách tôi cân nhắc lập luận sau khi đọc cả phía Thariq lẫn phía phản biện, không phải đo lường khách quan có dữ liệu. Bạn có thể không đồng ý với cách chấm của tôi.
01 · Mật độ thông tin cao hơn hẳn
HTML biểu diễn được mọi loại dữ liệu: bảng có định dạng đẹp, màu sắc CSS chính xác, biểu đồ SVG, đoạn code có tô màu cú pháp, bố cục không gian phức tạp, ảnh, hoạt ảnh. Thariq viết: “Tôi dám nói rằng gần như không có loại thông tin nào Claude có thể đọc được mà bạn không thể biểu diễn khá tốt bằng HTML.”
Đánh giá: Thuyết phục mạnh ★★★★★. Đáng chú ý là chính Thariq giữ chữ “gần như” - HTML không phải giải pháp tốt nhất cho mọi định dạng (PDF mạnh hơn cho in ấn, LaTeX mạnh hơn cho công thức toán, ứng dụng gốc mạnh hơn cho giao diện phức tạp). Nhưng trong bối cảnh AI tạo nội dung cho con người đọc trên web, phạm vi biểu đạt của HTML rộng nhất - và đó là bối cảnh đang được bàn.
02 · Người ta thực sự đọc nó
Theo Thariq: Markdown dài thì khó tiêu hoá. HTML với các tab điều hướng, hình minh hoạ, liên kết, hiển thị tốt trên điện thoại thì dễ đọc hơn nhiều. Đây là điểm ông nói thẳng và không nương: tài liệu không được đọc thì vô nghĩa.
Đánh giá: Thuyết phục mạnh ★★★★☆. Đúng với tài liệu dài cần chia sẻ với nhiều người. Với ghi chú ngắn 50 dòng hay tài liệu kỹ thuật đọc qua công cụ hiển thị Markdown tốt (Notion, Obsidian), Markdown vẫn nhanh và đủ - lập luận này không phải lúc nào cũng đúng.
03 · Chia sẻ dễ dàng hơn
Markdown khó chia sẻ vì trình duyệt không hiển thị trực tiếp. Tải file HTML lên S3 → có ngay đường link để chia sẻ. Đồng nghiệp mở trên điện thoại cũng được.
Đánh giá: Thuyết phục vừa ★★★☆☆. Hợp lý, nhưng GitHub và Notion hiển thị Markdown khá tốt rồi. Lợi thế này nhỏ hơn Thariq nói trong nhiều trường hợp thực tế.
04 · Tương tác hai chiều
HTML cho phép thanh trượt, nút điều chỉnh, nút bấm để tinh chỉnh thiết kế hoặc thử các lựa chọn. Mẹo quan trọng: thêm nút “Copy as Prompt” (sao chép thành câu lệnh) để đưa thiết lập trở lại thành đoạn văn bản dán vào Claude. Đây là vòng phản hồi mà Markdown không thể có.
Đánh giá: Thuyết phục mạnh ★★★★★. Đây là điểm tôi thấy ít người để ý nhưng có thể thay đổi cách làm việc đáng kể - đặc biệt khi bạn đang khám phá thiết kế hoặc thử nghiệm các tham số.
05 · Tận dụng toàn bộ sức mạnh của Claude Code
Claude Code có thể đọc hệ thống file, gọi các MCP (Slack, Linear), xem lịch sử Git, duyệt web qua Claude in Chrome - rồi tổng hợp tất cả vào một file HTML có biểu đồ và bối cảnh đầy đủ.
Đánh giá: Thuyết phục trong điều kiện cụ thể ★★★★☆. Chỉ đúng nếu bạn dùng Claude Code. Với Claude.ai web hay ChatGPT, lý do này yếu hơn.
06 · Đơn giản là vui hơn
Thariq nói thẳng: “Making HTML documents with Claude is just more fun” (làm việc với HTML cùng Claude đơn giản là vui hơn). Ông cảm thấy gắn bó và đầu tư hơn vào sản phẩm khi nhìn đầu ra đẹp.
Đánh giá: Thuyết phục nhẹ ★★★☆☆. Niềm vui quan trọng nhưng không đủ để thuyết phục người ra quyết định trong môi trường công việc. Tôi đồng ý về mặt cảm xúc - nhưng nó không nên là lý do duy nhất.
Phần 5 - 5 trường hợp dùng thực tế (với câu lệnh được dịch chú thích)
Phần này có giá trị thực hành rất rõ. Thariq chia sẻ câu lệnh thực tế ông dùng. Tôi giữ nguyên câu lệnh tiếng Anh và dịch chú thích chi tiết bên dưới.
Trường hợp 1 · Lập kế hoạch và khám phá ý tưởng
Thay vì tạo một file Markdown đơn lẻ, Thariq tạo cả một mạng lưới các file HTML liên kết với nhau. Quy trình: tạo 6 hướng → mở rộng một hướng với bản phác thảo và đoạn code mẫu → viết kế hoạch triển khai → tạo phiên Claude mới và đưa tất cả file vào làm bối cảnh.
Câu lệnh gốc: “I’m not sure what direction to take the onboarding screen. Generate 6 distinctly different approaches — vary layout, tone, and density — and lay them out as a single HTML file in a grid so I can compare them side by side. Label each with the tradeoff it’s making.”
Dịch: “Tôi chưa rõ hướng nào cho màn hình hướng dẫn người dùng mới. Hãy tạo 6 cách tiếp cận khác biệt rõ rệt - khác nhau về bố cục, giọng văn và mật độ thông tin. Bố trí tất cả trong một file HTML duy nhất theo dạng lưới để tôi so sánh cạnh nhau. Ghi chú rõ mỗi cái đang đánh đổi điều gì.”
Chú thích: Cấu trúc câu lệnh này quan trọng - cụm “khác biệt rõ rệt” ngăn AI tạo ra 6 phiên bản na ná nhau. Yêu cầu “ghi chú đánh đổi” buộc AI phải suy nghĩ về cái giá phải trả của mỗi lựa chọn.
Trường hợp 2 · Review code và hiểu code
Code rất khó đọc trong Markdown. HTML cho phép hiển thị phần khác biệt với chú thích bên lề, tô màu các phát hiện theo mức độ nghiêm trọng. Thariq cho biết hiện nay ông đính kèm trang HTML giải thích cho mỗi pull request ông tạo - một thay đổi cách làm việc ông áp dụng từ khi viết bài này.
Câu lệnh gốc: “Help me review this PR by creating an HTML artifact that describes it. I’m not very familiar with the streaming/backpressure logic so focus on that. Render the actual diff with inline margin annotations, color-code findings by severity and whatever else might be needed to convey the concept well.”
Dịch: “Giúp tôi review pull request này bằng cách tạo một file HTML mô tả nó. Tôi không quen với phần logic streaming/backpressure nên hãy tập trung vào đó. Hiển thị phần khác biệt thực tế với chú thích bên lề, tô màu các vấn đề theo mức độ nghiêm trọng.”
Chú thích: Mấu chốt là câu “tôi không quen với phần X” - chỉ rõ điểm yếu của bạn để AI tập trung giải thích. Đây là mẫu câu lệnh quan trọng: khai báo thẳng điểm yếu kiến thức của mình.
Trường hợp 3 · Thiết kế và bản dùng thử
Claude Design được xây dựng trên HTML vì HTML cực kỳ linh hoạt trong biểu đạt thiết kế. Claude có thể phác thảo thiết kế bằng HTML trước, rồi chuyển sang React, Swift.
Câu lệnh gốc: “I want to prototype a new checkout button, when clicked it does a play animation and then turns purple quickly. Create a HTML file with several sliders and options for me to try different options on this animation, give me a copy button to copy the parameters that worked well.”
Dịch: “Tôi muốn làm bản dùng thử một nút thanh toán mới, khi bấm vào nó có hoạt ảnh ‘play’ rồi chuyển sang màu tím nhanh chóng. Tạo file HTML với nhiều thanh trượt và lựa chọn để tôi thử các biến thể khác nhau, kèm nút sao chép để lấy lại các tham số nào hoạt động tốt.”
Chú thích: Đây là mẫu “sân chơi thử nghiệm” - AI không tạo cho bạn câu trả lời cuối, mà tạo công cụ để bạn tự khám phá. Nút sao chép tham số là cầu nối đưa kết quả khám phá quay lại vòng làm việc với AI.
Trường hợp 4 · Báo cáo, nghiên cứu và học hỏi
Claude Code giỏi tổng hợp thông tin từ Slack, mã nguồn, lịch sử Git, internet → chuyển thành báo cáo HTML đẹp.
Câu lệnh gốc: “I don’t understand how our rate limiter actually works. Read the relevant code and produce a single HTML explainer page: a diagram of the token-bucket flow, the 3–4 key code snippets annotated, and a ‘gotchas’ section at the bottom. Optimize it for someone reading it once.”
Dịch: “Tôi không hiểu bộ giới hạn tốc độ của chúng ta thực sự hoạt động thế nào. Hãy đọc code liên quan và tạo một trang HTML giải thích: biểu đồ luồng token-bucket, 3-4 đoạn code chính có chú thích, và phần ‘các điểm dễ vấp’ ở cuối. Tối ưu cho người đọc một lần duy nhất.”
Chú thích: Câu cuối đáng học - yêu cầu “tối ưu cho người đọc một lần duy nhất” buộc AI tổ chức thông tin theo độ ưu tiên, không dài dòng. Đây là cách dùng ràng buộc để định hướng đầu ra thay vì để mặc định.
Trường hợp 5 · Giao diện chỉnh sửa tuỳ biến
Đôi khi khó mô tả thứ bạn muốn chỉ bằng chữ. Thariq nhờ Claude tạo một giao diện dùng một lần - không phải sản phẩm, không tái sử dụng, chỉ là một file HTML làm đúng cho việc đang xử lý. Quan trọng: luôn kết thúc bằng nút sao chép sang JSON hoặc sao chép thành câu lệnh.
Câu lệnh gốc: “I need to reprioritize these 30 Linear tickets. Make me an HTML file with each ticket as a draggable card across Now / Next / Later / Cut columns. Pre-sort them by your best guess. Add a ‘copy as markdown’ button that exports the final ordering with a one-line rationale per bucket.”
Dịch: “Tôi cần sắp xếp lại 30 ticket Linear này theo độ ưu tiên. Tạo file HTML với mỗi ticket là một thẻ kéo thả được, giữa 4 cột: Now / Next / Later / Cut (Bây giờ / Tiếp theo / Sau / Bỏ). Sắp xếp sẵn theo dự đoán tốt nhất của bạn. Thêm nút sao chép thành Markdown để xuất thứ tự cuối kèm câu lý giải cho mỗi nhóm.”
Chú thích: Yêu cầu “sắp xếp sẵn theo dự đoán tốt nhất” là mẫu đáng để ý: cho AI làm bản nháp thay vì bắt đầu từ con số 0. Bạn chỉnh sửa từ điểm xuất phát hợp lý, tiết kiệm công sức so với cách làm thủ công.
Điểm chung mà tôi thấy ở cả 5 câu lệnh là gì? Thariq luôn nghĩ về vòng lặp phản hồi. Không bao giờ chỉ “tạo cho tôi X.” Luôn kèm theo: “có nút để tôi đưa kết quả quay lại quy trình.” Đây là mẫu thiết kế đáng học hỏi.
Bài học cho bạn khi viết câu lệnh cho AI: đừng nghĩ về đầu ra, hãy nghĩ về quy trình làm việc. Đầu ra của lần này phải là đầu vào dễ dàng cho lần sau. Đó là khác biệt giữa “dùng AI” và “thực sự cộng tác với AI.”
Phần 6 - Phía phản đối: những điều Thariq không nói tới
Đây là phần tôi nghĩ quan trọng để bạn quyết định. Bài viết của Thariq là quan điểm của một người tự nhận là HTML maximalist (cực đoan hoá HTML). Trong thảo luận trên Hacker News, cộng đồng dev đã đưa ra nhiều phản biện đáng cân nhắc mà bản thân Thariq cũng thừa nhận một phần.
Phản biện ① · Chi phí token thực sự là vấn đề
Thariq xua nhẹ tay khi nói “với cửa sổ ngữ cảnh 1M thì không đáng kể.” Nhưng một bình luận trên Hacker News chỉ ra thẳng: “An html table takes up way more tokens than a markdown table” (một bảng HTML tốn nhiều token hơn nhiều so với bảng Markdown). Với người dùng API trả tiền theo token, đây là chi phí thật. Với những ai chạy AI trên thiết bị di động hoặc không có mạng, cửa sổ ngữ cảnh vẫn nhỏ hơn nhiều.
Phản biện ② · Đầu ra đẹp dễ tạo ảo giác chất lượng
Đây là điểm tinh tế nhưng quan trọng mà cộng đồng dev đã nêu: HTML hiển thị đẹp có thể che giấu lỗ hổng logic trong nội dung. Một file Markdown dở thì dễ nhận ra dở; một file HTML đẹp dễ làm người đọc tin tưởng vào nội dung mà không kiểm tra kỹ. Khi AI tạo nội dung ngày càng nhiều và nhanh, đây là rủi ro thật: bạn có thể nhận đầu ra đẹp mắt và bỏ qua việc kiểm tra xem nó có chính xác không. Đẹp ≠ đúng.
Phản biện ③ · Markdown vẫn ưu thế rõ rệt ở quản lý phiên bản
Thariq tự thừa nhận đây là nhược điểm lớn nhất. Khi review thay đổi trong tài liệu qua thời gian, phần khác biệt của Markdown dễ đọc; phần khác biệt của HTML là một mớ thẻ rối rắm. Với những team làm việc nghiêm túc với “tài liệu như mã nguồn”, đây không phải lựa chọn dễ bỏ.
Phản biện ④ · Cùng chỉnh sửa với AI khó hơn nhiều
Bình luận được bầu chọn cao trên Hacker News nói thẳng: “with a HTML doc it is much harder to do that than with MD” (với tài liệu HTML, việc đó khó hơn nhiều so với MD) - “việc đó” là khi bạn có ý rõ ràng và muốn nhanh chóng tự gõ chỉnh sửa. Markdown vẫn có ưu thế lớn khi bạn cần chỉnh sửa nhanh cùng AI - và đây là cách làm việc phổ biến với nhiều người.
Góc nhìn cá nhân về cuộc tranh luận:
Đọc cả hai phía, tôi nghĩ cả Thariq và phe phản đối đều đúng - nhưng với những bối cảnh khác nhau. Đây không phải vấn đề đúng-sai, mà là vấn đề từng trường hợp dùng.
Thariq đúng khi: đầu ra là sản phẩm cuối, cần chia sẻ với nhiều người, có dữ liệu phức tạp cần hình ảnh hoá, và bạn dùng Claude Code (có khả năng đọc bối cảnh từ nhiều nguồn).
Phe phản đối đúng khi: bạn cần chỉnh sửa nhanh cùng AI, làm việc trên môi trường lập trình, quan tâm quản lý phiên bản, hoặc đang viết tài liệu kỹ thuật dạng tra cứu lâu dài.
Câu trả lời cho câu hỏi tiêu đề bài này thực ra ít kịch tính hơn nhiều người tưởng: AI nên nói chuyện với bạn bằng cả HTML và Markdown - tùy việc, tùy bối cảnh, tùy người đọc. Markdown chưa chết và sẽ không chết, nhưng vai trò của nó đang được định nghĩa lại trong bối cảnh AI tạo nội dung. Việc biết khi nào dùng cái nào là một kỹ năng mới tôi gọi tạm là “đọc hiểu định dạng”.
Phần 7 - Bạn có 4 con đường, không phải 2
Cuộc tranh luận này không bắt bạn chọn 1 trong 2. Trong thực tế, bạn có ít nhất bốn con đường khả thi - mỗi cái phù hợp với một kiểu cách làm việc khác nhau. Đây là phân loại của tôi để giúp bạn tự xác định mình thuộc nhóm nào:
🔴 Con đường 1 · Theo HTML toàn diện (như Thariq)
Gần như bỏ Markdown hoàn toàn. Đây là phe cực đoan mà chính Thariq tự nhận.
Phù hợp nếu: Bạn dùng Claude Code chuyên nghiệp hàng ngày, đầu ra chủ yếu để chia sẻ hoặc hình ảnh hoá, không quan tâm việc phần khác biệt trong Git bị rối, sẵn sàng trả thêm chi phí token cho đầu ra đẹp, và bạn làm việc một mình không cần đồng nghiệp cùng chỉnh sửa nhiều.
Cẩn trọng nếu: Bạn làm việc nhiều với review code qua Git, người đọc chính là dev xem qua môi trường lập trình, hoặc bạn cùng chỉnh sửa tốc độ cao với AI.
⚫ Con đường 2 · Theo Markdown toàn diện (giữ nguyên hiện tại)
Không đổi gì cả. Markdown cho mọi thứ.
Phù hợp nếu: Cách làm việc của bạn chủ yếu là ghi chú nhanh, README, tài liệu kỹ thuật sống trong Git. Bạn cùng chỉnh sửa rất nhiều với AI và cần tốc độ cao. Bạn quan tâm chi phí API.
Cẩn trọng nếu: Bạn đang tạo nhiều báo cáo dài để chia sẻ với người không phải dev nhưng họ không đọc. Đó là dấu hiệu định dạng đang là rào cản, không phải nội dung.
🟧 Con đường 3 · Chuyển đổi theo từng việc (đa số sẽ phù hợp)
Cùng một người, dùng cả hai định dạng tùy việc. Đây là cách thực dụng nhất cho người mới làm quen với đầu ra HTML từ AI.
Cách phân loại việc của tôi:
Dùng HTML cho: báo cáo, tài liệu thiết kế, giải thích pull request, làm bản dùng thử, khám phá nhiều phương án, tài liệu cho người không phải dev
Dùng Markdown cho: ghi chú cá nhân, README, comment trong code, bản nháp email, tài liệu đang làm trong Git, tài liệu cần chỉnh sửa cùng AI
Phù hợp nếu: Bạn vừa code vừa làm sản phẩm, có nhiều kiểu người đọc khác nhau, đang xây dựng trực giác về việc định dạng nào dùng khi nào.
🟦 Con đường 4 · Kết hợp cả hai (cho người dùng chuyên sâu)
Dùng cả hai trong cùng MỘT quy trình - tận dụng điểm mạnh của cả hai định dạng.
Ví dụ các mẫu hiệu quả:
Bản nháp → Bản cuối: Làm bản nháp bằng Markdown (nhanh, dễ chỉnh sửa cùng AI) → chuyển sang HTML khi cần chia sẻ công khai
Tài liệu làm việc → Tài liệu công bố: Tài liệu đang làm bằng Markdown lưu trong Git → tạo tài liệu HTML đi kèm riêng cho người không phải dev
Code → Bài giải thích: Code và README giữ Markdown → tạo trang HTML giải thích cho người ngoài team khi cần
Phù hợp nếu: Bạn đã có quy trình làm việc với AI ổn định, muốn tối ưu sâu, không ngại tốn công thiết lập mẫu sẵn.
Khuyến nghị thực tế của tôi: Đừng cố chọn con đường ngay khi đọc xong bài này. Bắt đầu với Con đường 3 (chuyển đổi theo từng việc) - thử HTML cho 1-2 việc cụ thể trong tuần tới (báo cáo tuần, khám phá thiết kế, hay giải thích pull request). Sau 2-4 tuần, bạn sẽ tự nhận ra mình nghiêng về phía nào: cực đoan như Thariq, giữ Markdown vì chi phí và Git, hay vẫn dùng cả hai theo từng việc. Đừng để bài viết của Thariq hay của tôi quyết định thay bạn - dữ liệu từ cách làm việc của chính bạn mới là câu trả lời cuối cùng.
Phần 8 - Bài học lớn: AI và “tư duy định dạng”
Sau tất cả phân tích, tôi muốn rút ra một bài học rộng hơn - một bài học không chỉ về HTML hay Markdown, mà về cách chúng ta làm việc với AI trong những năm tới.
Trong nhiều năm, chúng ta nghĩ về việc dùng AI như sau: “AI là công cụ. Tôi ra lệnh cho nó. Nó trả lời. Xong.” Đây là mô hình đầu vào - đầu ra đơn giản.
Nhưng Thariq đang chỉ ra một cách nghĩ khác: AI là cộng sự trong một vòng lặp tư duy. Và trong vòng lặp đó, định dạng của đầu ra không phải vấn đề trang trí - nó là chất xúc tác hoặc rào cản cho lần tương tác tiếp theo.
Khi AI tạo ra một file Markdown 300 dòng, nhiều người (trong đó có Thariq) lướt qua, không thực sự đọc, và chấp nhận. Khi AI tạo ra một file HTML có tương tác kèm thanh trượt, bạn dễ tương tác, điều chỉnh, phản hồi hơn. Định dạng ảnh hưởng đến mức độ tương tác của bạn với đầu ra - và mức tương tác đó là một trong những yếu tố ảnh hưởng đến chất lượng kết quả cuối cùng. Đây không phải định luật, chỉ là quan sát thực tiễn, nhưng đủ quan trọng để đáng cân nhắc.
Đây là một góc nhìn có thể áp dụng cho mọi tương tác với AI, không chỉ HTML và Markdown:
Nếu bạn muốn tương tác sâu với đầu ra của AI - hãy yêu cầu định dạng giúp bạn tương tác.
Nếu bạn cần chia sẻ với người khác - hãy yêu cầu định dạng giúp họ thực sự đọc.
Nếu bạn đang khám phá - hãy yêu cầu định dạng có vòng phản hồi (thanh trượt, nút bấm, sao chép quay lại).
Nếu bạn đang quyết định - hãy yêu cầu định dạng hiển thị các đánh đổi đặt cạnh nhau.
Tôi gọi tạm điều này là “đọc hiểu định dạng” - hiểu rằng loại định dạng nào kích hoạt loại tư duy nào khi tương tác với AI. Đây không phải kỹ năng duy nhất cần để làm việc tốt với AI - cách viết câu lệnh, chọn mô hình, dùng công cụ, đánh giá đầu ra đều có vai trò không kém. Nhưng đây là kỹ năng nhiều người chưa để ý tới, và có lẽ đáng để bắt đầu chú ý.
Ý đồ thực sự của Thariq và bài học
Thariq kết bài gốc của ông bằng một thú nhận đáng suy ngẫm: ông bắt đầu chuyển sang HTML không phải vì nó đẹp hơn, mà vì ông sợ rằng vì đã ngừng đọc kỹ các kế hoạch, ông sẽ phải để Claude tự quyết định mọi thứ - một sự từ bỏ kiểm soát không có ý thức.
HTML thay đổi điều đó. Khi đầu ra đẹp và có tương tác, bạn muốn đọc. Bạn tương tác với nó. Bạn không trở thành một người chỉ ngồi chờ AI làm xong.
Đây là điểm tôi nghĩ đáng chú ý - đặc biệt với những ai đang bắt đầu nghiêm túc làm việc với AI. AI sẽ ngày càng tự động làm nhiều hơn. Câu hỏi không phải “AI có thay tôi không” - mà là “khi AI làm thay tôi, tôi có còn hiểu và quyết định được không?” Việc bạn vẫn còn “trong vòng lặp” tư duy với AI là một trong những giá trị quan trọng nhất bạn cần giữ trong giai đoạn này.
Định dạng không phải vấn đề trang trí. Nó định hình cách bạn tương tác với đầu ra của AI - và do đó, định hình cả chất lượng kết quả bạn nhận được. Đáng để bạn suy nghĩ kỹ về nó, dù bạn kết luận đi theo Thariq, đi ngược lại ông, hay chọn một con đường ở giữa.
Nếu bạn thấy bài này có giá trị, hãy đăng ký để nhận các phân tích khác về AI và tương lai công nghệ trong tương lai. Phản hồi và tranh luận luôn được hoan nghênh.
Nguồn tham khảo: