- Khi dùng Claude Code, nếu sử dụng HTML làm định dạng đầu ra thay vì Markdown thì có thể tạo ra kết quả dễ đọc và dễ rà soát hơn cho con người, nhờ thể hiện phong phú hơn về trực quan, màu sắc, sơ đồ và tính tương tác
- HTML có thể biểu đạt hiệu quả phần lớn thông tin mà Claude có thể đọc được thông qua bảng biểu, CSS, SVG,
script, tương tác JavaScript, hình ảnh, canvas và định vị tuyệt đối
- Claude Code có thể đọc ngữ cảnh như hệ thống tệp, MCP, trình duyệt, lịch sử Git rồi kết hợp chúng thành đầu ra HTML; chỉ cần bắt đầu bằng cách yêu cầu “hãy tạo một tệp HTML”
- Các cách sử dụng chính được chia thành đặc tả·kế hoạch·khám phá, review và hiểu mã nguồn, thiết kế và nguyên mẫu, báo cáo·nghiên cứu·học tập, và giao diện chỉnh sửa tùy biến dùng một lần
- HTML mất thời gian tạo lâu hơn Markdown từ 2 đến 4 lần và gây nhiễu trong diff nên khó quản lý phiên bản, nhưng đổi lại có ưu điểm lớn về khả năng biểu đạt, chia sẻ và xác suất thực sự được đọc cao hơn
Vì sao bắt đầu thích HTML hơn Markdown
- Markdown đã trở thành định dạng tệp thống trị để agent giao tiếp với con người; nó đơn giản, có tính di động tốt, thể hiện được một ít định dạng và con người cũng dễ tự chỉnh sửa
- Claude cũng tạo sơ đồ ASCII rất tốt trong Markdown, nhưng khi agent ngày càng mạnh hơn thì Markdown bắt đầu cho cảm giác là một định dạng bị hạn chế
- Các tệp Markdown dài quá 100 dòng trở nên khó đọc, và nhu cầu chia sẻ dễ dàng hơn các phần trực quan phong phú, màu sắc và sơ đồ cũng tăng lên
- Khi ngày càng thường xuyên yêu cầu Claude chỉnh sửa tệp thay vì tự tay sửa trực tiếp, giá trị của ưu điểm lớn nhất của Markdown là dễ chỉnh sửa thủ công cũng giảm đi
- Ngay trong đội ngũ Claude Code, việc dùng HTML làm định dạng đầu ra cũng đang tăng lên, và có thể xem ví dụ tại html-effectiveness
Khả năng biểu đạt và chia sẻ của HTML
- HTML không chỉ thể hiện cấu trúc tài liệu như tiêu đề và định dạng, mà còn có thể biểu đạt nhiều loại thông tin hơn hẳn Markdown
- Các loại thông tin có thể biểu đạt gồm dữ liệu bảng thông qua table, dữ liệu thiết kế qua CSS, minh họa SVG, các đoạn mã thông qua thẻ
script, và tương tác bằng JavaScript cùng CSS
- Có thể dùng SVG và HTML để thể hiện workflow, dùng định vị tuyệt đối và canvas để biểu đạt dữ liệu không gian, và chèn hình ảnh bằng thẻ
img
- Phần lớn tập hợp thông tin mà Claude có thể đọc được đều có thể được biểu đạt khá hiệu quả bằng HTML, biến nó thành một định dạng hiệu quả cả cho mô hình truyền tải thông tin sâu lẫn cho con người rà soát
- Nếu không dùng HTML, Claude có thể phải dùng những cách biểu đạt kém hiệu quả trong Markdown như sơ đồ ASCII hoặc ước lượng màu bằng ký tự Unicode
- Khi Claude thực hiện các tác vụ phức tạp hơn và phải viết các bản đặc tả, kế hoạch lớn hơn, thực tế là các tệp Markdown dài quá 100 dòng không còn dễ đọc
- Tài liệu HTML có thể tổ chức cấu trúc một cách trực quan bằng tab, minh họa, liên kết, nên dễ điều hướng hơn, và cũng có thể làm responsive để đọc khác nhau tùy kích thước màn hình
- Các tệp Markdown không được trình duyệt render tốt theo mặc định nên thường phải đính kèm qua email hoặc tin nhắn, trong khi HTML chỉ cần đưa lên nơi như S3 là có thể dễ dàng chia sẻ bằng liên kết
- Các bản đặc tả, báo cáo, mô tả PR ở dạng HTML giúp đồng nghiệp dễ mở và tham khảo hơn, nên khả năng thực sự được đọc cao hơn nhiều
- Tài liệu HTML cũng có thể hỗ trợ tương tác hai chiều như thêm slider hoặc knob để điều chỉnh thiết kế hay thay đổi tùy chọn thuật toán và xem kết quả
- Thậm chí còn có thể tạo chức năng sao chép phần đã điều chỉnh thành prompt để dán lại vào Claude Code; ví dụ liên quan được đề cập trong playgrounds post
Vì sao dùng Claude Code cùng với HTML
- Claude Code có thể đọc nhiều loại ngữ cảnh như hệ thống tệp, MCP, trình duyệt, lịch sử Git rồi kết hợp chúng thành kết quả HTML
- Ví dụ, nó có thể tìm toàn bộ các tệp HTML được tạo trong một thư mục mã nguồn, nhóm và phân loại chúng, rồi tạo một tệp HTML chứa các sơ đồ đại diện cho từng loại
- Ngoài hệ thống tệp, còn có thể tìm thêm ngữ cảnh từ MCP như Slack, Linear, từ trình duyệt web qua Claude in Chrome, hoặc từ lịch sử Git
- Quá trình cùng Claude tạo tài liệu HTML cũng thú vị hơn và tạo cảm giác gắn bó, đầu tư hơn vào sản phẩm được tạo ra
- Không cần tạo riêng kỹ năng
/html; chỉ cần bắt đầu bằng cách yêu cầu “hãy tạo một tệp HTML” hoặc “hãy tạo một HTML artifact”
- Mẹo quan trọng là phải biết artifact đó cần làm gì và sẽ được dùng như thế nào; lúc đầu nên viết prompt từ đầu mỗi lần để học được nhiều cách dùng khác nhau
Các cách sử dụng chính
-
Đặc tả, kế hoạch, khám phá
- HTML trở thành một canvas phong phú để Claude đào sâu vấn đề, và có thể bắt đầu công việc bằng một bộ nhiều tệp HTML thay vì một bản kế hoạch Markdown duy nhất
- Có thể đi theo luồng: trước tiên brainstorm nhiều hướng, sau đó mở rộng một hướng để tạo mockup hoặc đoạn mã, cuối cùng viết kế hoạch triển khai
- Khi kế hoạch đã ổn, có thể tạo phiên làm việc mới và chuyển các tệp này sang để triển khai; agent kiểm chứng cũng có thể đọc cùng các tệp đó để nắm được ngữ cảnh rộng hơn
- Có thể yêu cầu tạo 6 cách tiếp cận khác nhau cho màn hình onboarding với bố cục, tông và mật độ khác nhau trong một lưới HTML duy nhất, đồng thời hiển thị trade-off của từng lựa chọn
- Cũng có thể yêu cầu tạo một kế hoạch triển khai HTML dễ đọc gồm mockup, luồng dữ liệu và các đoạn mã cần xem xét
- Phù hợp để khám phá cách triển khai mã và so sánh nhiều thiết kế trực quan khác nhau
-
Review mã và hiểu mã nguồn
- Mã nguồn có thể khó đọc trong tệp Markdown, nhưng trong HTML thì có thể render diff, chú thích, sơ đồ luồng, cấu trúc mô-đun, v.v.
- Có thể dùng để hiểu đoạn mã do agent viết, nhận review mã, hoặc giải thích thay đổi cho người đang xem PR
- Trong một số trường hợp nó còn hiệu quả hơn chế độ xem diff mặc định của GitHub, và cũng có thể hình thành quy trình đính kèm một tệp giải thích mã HTML cho mỗi PR
- Có thể tạo HTML artifact phục vụ review PR, tập trung vào logic streaming/backpressure chưa quen thuộc, thêm chú thích ở lề vào diff thực tế và tô màu theo mức độ nghiêm trọng
- Dùng được cho việc viết PR, review PR và hiểu các chủ đề trong mã nguồn
-
Thiết kế và nguyên mẫu
- Claude Design được xây dựng trên nền HTML, và HTML có sức biểu đạt thiết kế cao ngay cả khi bề mặt cuối cùng không phải HTML
- Claude có thể phác thảo thiết kế bằng HTML rồi sau đó viết bằng ngôn ngữ mong muốn như React, Swift
- Có thể tạo nguyên mẫu cho các tương tác như animation, action, và thêm slider hoặc knob để điều chỉnh các giá trị mong muốn
- Có thể yêu cầu tạo một nút checkout sau khi nhấn sẽ chạy animation rồi nhanh chóng chuyển sang màu tím, đồng thời có nhiều slider, tùy chọn và nút sao chép các tham số phù hợp
- Phù hợp để tạo artifact hệ thống thiết kế, tinh chỉnh component, trực quan hóa thư viện component và tạo nguyên mẫu animation thú vị
-
Báo cáo, nghiên cứu, học tập
- Claude Code rất mạnh trong việc tổng hợp thông tin từ nhiều nguồn dữ liệu rồi chuyển thành báo cáo dễ đọc
- Có thể yêu cầu nó tìm kiếm qua Slack, codebase, lịch sử Git, Internet, rồi tạo các báo cáo dễ đọc cho bản thân, lãnh đạo hoặc cả nhóm
- Kết quả có thể là tài liệu HTML dài, hướng dẫn tương tác, hoặc ở dạng slide hay deck
- Nếu yêu cầu nó tạo sơ đồ bằng SVG thì sẽ rất hữu ích cho trực quan hóa
- Khi chuẩn bị bài viết về prompt caching, đã có cách dùng là cho nó đọc lịch sử Git và tạo một tệp nghiên cứu HTML chuyên sâu bao quát toàn bộ các thay đổi liên quan đến prompt caching
- Cũng có thể yêu cầu nó đọc mã liên quan của rate limiter và tạo một trang giải thích HTML duy nhất gồm sơ đồ luồng token-bucket, 3~4 đoạn mã cốt lõi có chú thích và một phần gotchas ở cuối
- Phù hợp cho tóm tắt cách tính năng hoạt động, giải thích khái niệm, báo cáo trạng thái hằng tuần, báo cáo sự cố, minh họa SVG, lưu đồ và sơ đồ kỹ thuật
-
Giao diện chỉnh sửa tùy biến
- Khi khó mô tả điều mình muốn chỉ bằng hộp văn bản, có thể tạo một trình chỉnh sửa HTML dùng một lần phù hợp với đúng dữ liệu đang làm việc
- Đây không phải sản phẩm hay công cụ tái sử dụng, mà là một tệp HTML đơn lẻ được thiết kế đúng mục đích cho một mẩu dữ liệu cụ thể
- Điểm cốt lõi là ở cuối cần có phần xuất ra như “copy as JSON” hoặc “copy as prompt”, để có thể dán kết quả thao tác trong UI trở lại vào Claude Code
- Có thể biến 30 ticket Linear thành các thẻ kéo-thả trong các cột Now / Next / Later / Cut, rồi sao chép thứ tự cuối cùng sang Markdown kèm một dòng lý do cho từng bucket
- Có thể tạo cấu hình feature flag thành một trình chỉnh sửa theo form, nhóm theo khu vực, hiển thị phụ thuộc, cảnh báo khi bật một flag trong khi flag tiền đề đang tắt, và chỉ sao chép các khóa đã thay đổi dưới dạng diff
- Khi điều chỉnh system prompt, có thể đặt prompt có thể chỉnh sửa cùng các ô biến được làm nổi bật ở bên trái, còn bên phải là ba mẫu đầu vào được render theo thời gian thực, kèm bộ đếm ký tự·token và nút sao chép
- Phù hợp cho việc sắp xếp lại ticket·test case·feedback, chỉnh sửa cấu hình có cấu trúc, điều chỉnh prompt·template·câu chữ, tuyển chọn dataset, chú thích tài liệu·bản chép lời·diff, và chọn các giá trị khó biểu đạt bằng văn bản như màu sắc, easing curve, crop region, cron schedule, regex
Câu hỏi thường gặp và giới hạn
- Markdown thường dùng ít token hơn, nhưng HTML có sức biểu đạt cao hơn và khả năng thực sự được đọc lớn hơn nên chất lượng đầu ra tổng thể tốt hơn
- Với 1MM context window của Opus 4.7, mức tăng lượng token không quá đáng kể trong cửa sổ ngữ cảnh
- Dù gần như đã ngừng dùng Markdown cho hầu hết mọi mục đích, đây vẫn là một phong cách sử dụng nghiêng mạnh về phía ưu tiên HTML tối đa
- Các tệp HTML có thể mở trong trình duyệt cục bộ, cũng có thể yêu cầu Claude mở giúp, và nếu cần liên kết có thể chia sẻ thì có thể tải lên S3
- Việc tạo HTML mất nhiều thời gian hơn Markdown, có thể lâu hơn 2 đến 4 lần, nhưng kết quả được đánh giá là xứng đáng
- Một trong những nhược điểm lớn nhất là quản lý phiên bản, vì diff HTML gây nhiễu hơn Markdown và khó review hơn
- Nếu muốn Claude tạo HTML đúng gu của mình thì frontend design plugin sẽ hữu ích
- Nếu muốn khớp với phong cách của công ty, có thể cho Claude xem codebase để tạo một tệp HTML hệ thống thiết kế duy nhất, rồi dùng nó làm tài liệu tham chiếu cho các tệp HTML khác về sau
- Dùng HTML giúp giảm nỗi lo rằng sẽ không đọc kỹ các kế hoạch do Claude viết rồi buộc phải giao toàn bộ lựa chọn cho nó, từ đó có thể ở trong trạng thái “flow” nhiều hơn khi làm việc cùng Claude
1 bình luận
Ý kiến trên Hacker News
Tôi lo rằng nếu nghiêng sang HTML, chúng ta sẽ mất đi khả năng con người và LLM cùng nhau viết và chỉnh sửa tài liệu một cách dễ dàng
Với văn bản giải thích đơn giản thì không sao, nhưng với các đặc tả phức tạp hơn, khả năng đi thẳng vào kết quả được tạo ra để tự sửa là cực kỳ quan trọng. Tài liệu HTML khiến việc đó khó hơn nhiều so với Markdown, và dĩ nhiên có thể lại yêu cầu LLM chỉnh HTML, nhưng khi trong đầu bạn đã biết rõ mình muốn nói gì thì bản thân việc đó lại trở thành một rào cản nữa. Nếu kiểu mẫu này trở nên phổ biến, có lẽ việc đồng sáng tạo người/LLM sẽ giảm thêm, và chúng ta sẽ tiến tới chỗ giao cả cách diễn đạt, giọng điệu lẫn lựa chọn nội dung cho LLM. Tôi khá bất ngờ vì FAQ trên blog không hề nhắc đến mối lo này
Ví dụ như một lệnh
pandocchỉ một dòngTôi đang làm một game mobile nhỏ có góc nhìn isometric và âm thanh, đã bảo Codex tạo công cụ đặt khối trong tài liệu three.js có sẵn rồi chụp màn hình bằng công cụ nhà phát triển Chromium, thì nó tạo ra một cấu trúc JSON nhỏ định nghĩa khối, màu và hiệu ứng để xuất ra tileset 2.5D. Tôi cũng để nó định nghĩa âm thanh và nhạc bằng script Python
uv, thì nó tự nghĩ ra một định dạng YAML có thể tạo tiếng ồn. Bài test SVG pelican giờ bị vượt xa hoàn toàn, Codex còn tạo ra đủ prototype art cho lính, hiệp sĩ, linh mục và cả prototype soundtrack nữaĐiều mỉa mai là đây không phải một trang HTML tương tác mà là một bài đăng Twitter chứa ảnh render từ HTML
Rốt cuộc cũng khá buồn cười khi cổ vũ HTML trên một nền tảng có cấu trúc ngữ nghĩa còn nghèo nàn hơn Markdown
Có lẽ là cả hai
Đây là prompt tôi hay dùng khi khám phá ý tưởng hay công cụ mới
Ngay cả trước thời AI tôi cũng đã làm các công cụ nhỏ theo cách này, và tôi thích việc có thể gửi công cụ qua email cho bạn bè rồi bảo “nếu muốn sửa thì cứ ném vào LLM”
Phạm vi những gì bạn có thể làm chỉ với một file HTML duy nhất chứa style và JS khi tạo dashboard, app nhỏ, hoặc tiện ích tương tác với API hay lấy dữ liệu từ đâu đó là rộng đến mức đáng ngạc nhiên. Chỉ cần quăng nó vào thư mục cá nhân
~trên máy chủ dùng chung của công ty là ai cũng có thể xem và dùng ngayindex.htmlđơn giản với CSS inline, rồi khi ưng kết quả thì đặt file đó cạnh file template của dự án và bảo LLM hòa thiết kế trongindex.htmlvào templateTừ trước đến giờ khi dùng LLM, trọng tâm của tôi luôn là bản thân “ứng dụng”, chứ không phải các công cụ phụ trợ xung quanh nó. Những công cụ phụ đó không cần hoàn thiện cao hay xử lý mọi trường hợp, chỉ cần chạy đủ hữu ích là được. Dùng xong thì bỏ, ngày mai làm cái mới
Khả năng ráp nhanh các công cụ kiểu này rồi đưa lên một static site thực sự rất tiện
Công nghệ web thực sự đã làm đúng rất nhiều thứ. Nhiều người hay than phiền, nhưng nó đáng nể thật
Ở chỗ làm trước tôi từng phải xử lý một ứng dụng được vibe coding ra và cuối cùng nghỉ việc cũng vì chuyện đó: frontend Next.js một trang đơn và backend API tách riêng khiến URL phía người dùng không khớp với endpoint backend. Vì AI dùng React hooks cho mọi thứ nên trạng thái nằm trong bộ nhớ, còn routing dựa trên URL thì không tồn tại nếu không được chủ động thiết kế. Thành ra liên kết không tự nhiên có sẵn, và người dùng chẳng có cách nào link tới bất cứ đâu ngoài điểm vào cấp cao nhất. Đúng là liên kết đấy. Nhất là với công cụ nội bộ, mọi thứ đều nên có thể liên kết được để dễ cộng tác và xử lý sự cố. Thiết kế cần có tài nguyên định vị thống nhất và các động từ rõ ràng là điều đã được nghĩ ra rất hay từ 30–40 năm trước rồi
Có vài điểm đánh đổi giữa HTML và Markdown bị bỏ sót ở đây. HTML kém hiệu quả token hơn nhiều, và việc đưa phản hồi chính xác cho một bố cục HTML cũng khó hơn Markdown
Hai điểm đánh đổi này lại có lợi cho Anthropic. Dùng HTML làm phương tiện sẽ làm tăng lượng token tiêu thụ, và họ cũng có thể đang đầu tư vào các công cụ chú thích hay đánh dấu trong HTML như một phần của Claude Design, từ đó tăng lock-in. Hoặc là ngẫu nhiên, hoặc là chiến lược rất giỏi
Tôi cũng không rõ vì sao phản hồi chính xác lại khó hơn Markdown. Có thể đặt
id, section v.v. bằng thẻ màDù đã làm việc với HTML hàng chục năm, với tài liệu đơn giản thì Markdown vẫn nhanh hơn. Sẽ rất tốt nếu có một điểm trung gian, và thực tế các thứ giàu tính năng hơn như GitHub Markdown đã tồn tại rồi
Bạn có thể nhúng Mermaid, hoặc dùng thứ như MDX để trộn component khi cần. Theo tôi biết thì readme.com cũng dùng MDX ở bên dưới. Nếu cần card hay layout, bạn còn có thể thêm component dựa trên thứ như Bootstrap. Giờ chỉ còn thiếu hỗ trợ ở mức giao diện thôi. Vì vốn đã render được HTML thuần rồi nên việc thêm Markdown mạnh hơn có lẽ cũng không quá khó
Cả đặc tả Markdown gốc [1] lẫn CommonMark [2] đều quy định rõ hỗ trợ inline HTML. Vì vậy tùy mục đích mà bạn có thể nhận được phần nào lợi ích của cả hai bên
Phần lớn thời gian chỉ cần dùng header và đoạn văn Markdown bình thường, thêm ảnh và bảng là đã dễ đọc ở dạng thô mà không cần thẻ HTML. Nếu muốn chèn những thứ như SVG mà tác giả lấy làm ví dụ, bạn có thể nhúng trực tiếp SVG, còn người xem thì render Markdown bằng trình xem họ thích. Khi đang xem file Markdown thô trong VS Code mà gặp thẻ HTML thì chỉ việc mở preview bằng
Cmd+Shift+Vlà xong. Tất nhiên, nếu là một trang web thực thụ với nút tương tác và tùy biến kiểu dáng hoàn toàn thì khó mà làm được, nhưng nếu chủ yếu là văn bản, ảnh, bảng và chỉ thêm vài thành phần phụ trợ chỗ này chỗ kia thì vẫn đi được khá xa[1] https://daringfireball.net/projects/markdown/syntax#html
[2] https://spec.commonmark.org/0.31.2/#html-blocks
Từ tháng 1 tôi đã thúc đẩy mạnh cách làm này cho các mục đích ngoài lập trình. Thuộc tính quan trọng là nó là một nguồn chân lý duy nhất có thể chỉnh sửa, để cả LLM lẫn con người hiểu được, có thể render và sửa dần từng bước
Tôi khá hay nói chuyện với người bình thường về cách họ làm việc với AI, và hễ bắt gặp một cuộc trò chuyện về AI ngoài đời là tôi lại chen vào kiểu như nhà nhân học. HTML artifact giống như thanh địa chỉ URL mới của trình duyệt. Giống như cách một số người dùng hiểu thanh đó chính là Google vậy. Dạo này nhiều người nói về các đầu ra như “bảng tính”, “bản trình bày”, “tóm tắt marketing 1 trang”, “slideshow”, “phân tích cạnh tranh”, “sơ đồ hệ thống HVAC”, và bảo rằng làm việc trong web ChatGPT hay Claude không hay lắm, còn dùng Claude Code hay OpenClaw để tạo tài liệu mới thì như phép màu.
Khi hỏi tài liệu thực sự là gì và sự khác biệt trong trải nghiệm nằm ở đâu, phải gặng khá nhiều hoặc bảo họ cho xem trực tiếp vì họ chưa có từ vựng điện toán, nhưng cuối cùng lúc nào cũng đi tới kết luận rằng artifact đó là HTML. Trải nghiệm dễ chịu đến từ việc lặp đi lặp lại trên file HTML (+CSS+hình ảnh) nằm trong hệ thống tệp với khả năng render tức thì chất lượng cao, và nếu cần còn có thể rắc thêm chút JavaScript. Nếu có hệ thống git thì họ thậm chí có thể được quản lý phiên bản mà không nhận ra. Nếu không có thì tôi khuyên nên tạo checkpoint. Với người dùng phổ thông, quản lý phiên bản có thể là nấc học tiếp theo
Ngược lại, trải nghiệm bị nhúng trong web là việc chọc đi chọc lại vào DOCX/PPTX/XLSX nằm trong cửa sổ ngữ cảnh, đồng thời phải xử lý một khái niệm mơ hồ về kho lưu trữ cục bộ. Thực ra nó vẫn được render thành HTML ở sidebar mà thôi. Quy trình làm việc với HTML cũng giúp tích hợp các phương tiện khác dễ hơn nhiều. Suy cho cùng, loại công việc trình bày này chính là vibe coding của đại chúng, và không cần phải biết hết mọi lớp rùa bên dưới. Dù vậy, nếu muốn thì vẫn có thể mở ra chỉnh sửa hoặc dễ dàng chuyển cho một agent khác. Một hệ thống được tạo ra cho giao tiếp đa phương tiện cộng tác rốt cuộc lại trở nên hữu ích cho việc trí tuệ máy hỗ trợ giao tiếp của chúng ta
Trước đây, agent của chúng tôi(https://www.definite.app/) từng viết báo cáo và dashboard bằng đặc tả YAML được frontend framework render
Ví dụ, nếu người dùng nói “hãy tạo báo cáo hiển thị doanh thu và số đơn theo tháng, đồng thời hiển thị 100 đơn gần nhất”, agent sẽ viết một đặc tả để frontend render. Cách này nhanh, nhưng rồi chúng tôi bị chôn vùi dưới hàng loạt yêu cầu tính năng mà framework phải render được. Kiểu như “đoạn này tôi muốn bỏ nhãn”, “đoạn kia cần nhãn”, “có thể biến biểu đồ này thành heatmap không”. Từ vài tháng trước, chúng tôi để agent viết thẳng HTML; quá trình tạo lâu hơn nhưng gần như không còn giới hạn tùy biến nữa. Cách mới này cũng còn nhiều vấn đề, như người dùng phi kỹ thuật phải debug những ứng dụng quái vật do chính họ tạo ra, nhưng nhìn chung khách hàng thích hơn rất nhiều
Với các đầu ra agent dài, tôi đọc bằng VIM và Quick Look của macOS (có kèm extension render Markdown), hoặc dán vào MarkEdit có panel preview
Tệ nhất thì cứ bảo agent làm một trang web cục bộ đơn giản để parse và render Markdown là được. Markdown vốn được phát minh như một dạng rút gọn của cú pháp web[0], và đây chính là use case đó. Có lẽ lượng token và thời gian để bảo agent chuyển Markdown cơ bản sang HTML còn lớn hơn so với những cách này
0. https://daringfireball.net/projects/markdown/
Dùng bot đang thực sự trở nên quá hỗn loạn và tự tham chiếu rồi