Công cụ "Đọc Markdown / HTML trên di động" mà tôi đã hé lộ trước đây đã hoàn thành, và nó có tên là Jilan.
Nó giải quyết một vấn đề nhỏ nhưng ngày càng gây khó chịu:
Khi ai đó gửi cho bạn một báo cáo AI, một bản PPT dạng web, hoặc một tài liệu Markdown qua WeChat, ứng dụng Tệp, hoặc một nhóm chat, việc mở nó trên điện thoại thường dẫn đến màn hình trắng, mã nguồn thô, lỗi hiển thị, hoặc hoàn toàn hoang mang không biết dùng ứng dụng nào.
Các tệp như .md, .markdown, .html, .htm, .txt, và thậm chí cả các tệp ZIP web đã được đóng gói giờ đây có thể được mở trực tiếp trên iPhone và iPad bằng Jilan.
Xử lý cục bộ, lưu trữ cục bộ — không cần tải lên và không cần đăng ký tài khoản.
Có một đường dẫn TestFlight ở cuối bài; bạn có thể đăng ký trực tiếp nếu muốn dùng thử. Tôi đã mở 8.000 suất.
Nhưng tôi không làm Jilan chỉ vì thiếu một trình đọc.
Lý do trực tiếp hơn là gần đây tôi ngày càng cảm thấy rõ ràng rằng khi AI tham gia vào sản xuất nội dung, các định dạng chúng ta dùng để trao đổi nội dung đang thay đổi.
Rất nhiều nội dung văn bản bắt đầu được tạo ở định dạng Markdown, và rất nhiều nội dung trình chiếu được tạo ở định dạng HTML.
Jilan chỉ là một công cụ nhỏ rơi ra khi sự thay đổi này chạm đến phía di động.
Markdown không chỉ là một định dạng văn bản; nó đang trở thành lớp dữ liệu cho AI
Cách đây vài ngày, tôi thấy một câu trích dẫn từ tác giả của Obsidian mà tôi nghĩ rất chính xác: .md đang trở thành một điểm Schelling trong tương tác tệp của AI.
Điểm Schelling là một lựa chọn mà mọi người tự nhiên hướng tới mà không cần bất kỳ quy định bắt buộc nào.
Markdown bây giờ cũng hơi giống vậy.
Không ai bắt buộc AI phải sử dụng Markdown, và không có ủy ban tiêu chuẩn nào lên tiếng công bố điều gì.
Nhưng trong sử dụng thực tế, dù là con người viết cho AI hay AI viết cho con người, kết quả thường là một tệp .md.
Lý do rất đơn giản.
Nó là văn bản thuần túy, nên nhẹ nhàng cho mô hình đọc và viết.
Nó có đủ cấu trúc để thể hiện tiêu đề, danh sách, bảng biểu, khối mã và liên kết.
Và nó không bị bọc trong một định dạng phức tạp như .docx.
Con người có thể mở trực tiếp, AI có thể xử lý trực tiếp, và việc quản lý phiên bản cũng như so sánh khác biệt rất sạch sẽ.
Nhưng tôi nghĩ quan trọng hơn, Markdown không còn có thể chỉ được hiểu là "văn bản trong trình soạn thảo."
Nó giống như dữ liệu nền tảng trong một quy trình làm việc của AI hơn.
Đó là cách tôi sử dụng nó trong CodePilot.
Nó không có cơ chế ghi nhớ đặc biệt phức tạp; nhiều bộ nhớ thực ra chỉ là một tập hợp các tệp Markdown.
AI ghi vào chúng, AI đọc từ chúng, và tôi có thể tự mở và chỉnh sửa chúng.
Hơn nữa, các widget trong CodePilot có thể sử dụng các tệp Markdown và bộ nhớ cục bộ này làm nguồn dữ liệu.
Khi tệp thay đổi, hiển thị của thành phần cũng thay đổi theo.
Lúc này, Markdown không chỉ là "một bài viết để đọc."
Nó trở thành một lớp dữ liệu cục bộ rất nhẹ: con người có thể thấy, AI có thể đọc, và các công cụ có thể tạo ra giao diện và tương tác mới dựa trên nó.
Đây cũng là lý do tại sao tôi cảm thấy hướng đi mà nhiều người đang theo đuổi bằng cách tiếp tục mài giũa các trình soạn thảo Markdown có thể hơi hạn hẹp.
Điều thực sự thú vị không phải là tạo ra một hộp chỉnh sửa đẹp hơn, mà là coi Markdown như dữ liệu để xây dựng những cách đọc, quản lý và tương tác giữa người và máy tính mới.
HTML đang trở thành lớp hiển thị cho nội dung AI
Ở đầu kia là HTML. Xu hướng này cũng ngày càng rõ rệt trong thời gian gần đây.
Tháng trước, tôi đã mã nguồn mở một Kỹ năng PPT (PPT Skill) tạo bài thuyết trình ở định dạng web.
Nó đã đạt 10.000 sao trong 25 ngày, và sau đó, trong các buổi bảo vệ offline, triển lãm và chia sẻ, tôi liên tục thấy mọi người sử dụng PPT được tạo bằng nó.
Điều này đã xác nhận một điều với tôi:
Trong nhiều tình huống, thứ mọi người muốn không phải là một tệp .pptx tiêu chuẩn, mà là một bài thuyết trình có thể trình bày, hiểu và chia sẻ nhanh chóng.
Thật trùng hợp, nhóm Claude Code gần đây cũng đang nói về điều tương tự.
Họ có một bài viết cụ thể về lý do tại sao ngày càng nhiều đầu ra bắt đầu sử dụng HTML thay vì Markdown.
Lý do trực tiếp: HTML có mật độ thông tin cao hơn, dễ dàng hơn cho phân cấp trực quan, tốt hơn cho việc hiển thị biểu đồ, bố cục và tương tác, và người khác dễ dàng mở và đọc hơn.
Điều này rất gần với trải nghiệm của riêng tôi.
Markdown tốt cho việc củng cố nội dung, nhưng khi dài, nó trở nên khó đọc. Một báo cáo hàng nghìn hoặc hàng chục nghìn từ nhồi nhét vào một tệp .md thực sự khó để một người có thể tiếp thu, ngay cả khi cấu trúc đúng.
HTML thì ngược lại. Nó có thể sử dụng bố cục, khoảng trắng, màu sắc, biểu đồ và tương tác để tổ chức thông tin thành thứ gì đó giống như "thứ để được tiêu thụ" hơn. Nó không tốt hơn cho việc lưu trữ sự kiện, nhưng tốt hơn cho việc giúp mọi người hiểu các sự kiện.
Vì vậy, tôi ngày càng có xu hướng xem hai thứ này một cách riêng biệt:
Markdown là lớp dữ liệu, HTML là lớp hiển thị.
Giữ nội dung nền tảng ở Markdown — sạch sẽ, dễ đọc và kiểm soát phiên bản.
Khi cần hiển thị cho mọi người, trình bày hoặc chia sẻ bên ngoài, hãy kết xuất nó thành HTML.
Đây không phải là một tiêu chuẩn lớn mới nào đó; nó giống như một sự phân công lao động đã tự nhiên phát triển từ các quy trình làm việc của AI hơn.
Nhưng chuỗi này bị phá vỡ trên di động
Nội dung thì có, tệp đã được gửi, nhưng vấn đề xảy ra ở bước cuối cùng: mọi người thường mở chúng trên điện thoại.
Máy tính để bàn thì ổn. Bạn có trình duyệt, trình soạn thảo, và nếu mọi cách khác đều thất bại, thì có VS Code.
Nhưng di động thì khác.
Đặc biệt là khi bạn nhận được một báo cáo do AI tạo ra, một PPT web hoặc một tài liệu Markdown trong WeChat, trải nghiệm phổ biến là không mở được, hiển thị mã nguồn, lỗi hiển thị hoặc phải nhảy qua lại giữa vài ứng dụng. Đó là một việc nhỏ, nhưng rất khó chịu.
Một ứng dụng nhắn tin tức thời như WeChat về cơ bản không phải là một trình đọc tệp.
Ưu tiên của nó là trò chuyện, xem trước và chuyển tiếp, chứ không phải mở một cách nghiêm túc một tệp Markdown hay HTML.
Trình duyệt cũng không được thiết kế cho tình huống này.
Theo mặc định, trình duyệt xử lý "bạn đưa cho tôi một liên kết, tôi sẽ mở trang web cho bạn."
Nhưng những gì người khác gửi cho bạn thường là một tệp cục bộ, không phải một liên kết. Bạn chắc chắn có thể nhảy qua nhiều vòng để ném HTML vào trình duyệt, nhưng toàn bộ chuỗi dài và lộn xộn.
Nhiều công cụ Markdown cũng hướng đến việc chỉnh sửa và ghi chú, và không nhất thiết phù hợp để tạm thời mở một tệp do người khác gửi.
Chưa kể một số công cụ yêu cầu bạn nhập, đồng bộ hóa, xây dựng thư viện hoặc đăng ký tài khoản.
HTML có thêm một lớp vấn đề bảo mật: một tệp lạ có thể chứa tập lệnh và bạn không nhất thiết muốn chúng thực thi theo mặc định.
Vì vậy, tôi luôn cảm thấy rằng một thứ rất đơn giản đang bị thiếu:
Một cách để mở các tệp quy trình làm việc AI phổ biến này trên điện thoại một cách an toàn và thuận tiện.
Đó chính là Jilan.
Jilan rất tập trung: Mở, Đọc, Giữ lại
Jilan không được tạo thành một trình soạn thảo, cũng không được kết nối với AI. Nhân tiện, tôi phải khen ngợi biểu tượng ứng dụng do CodeX vẽ; nó thực sự rất dễ thương.
Ngay từ đầu tôi đã rất rõ ràng rằng nó chỉ làm ba việc: Mở, Đọc, Giữ lại.
Khi bạn nhận được một tệp, hãy chọn Jilan từ WeChat, ứng dụng Tệp hoặc bảng chia sẻ hệ thống để mở nó. Nó hỗ trợ các tệp .md, .markdown, .html, .htm, .txt và .zip được đóng gói từ các nguồn web.
Tất cả các tệp đều được xử lý cục bộ — không tải lên, không đăng ký tài khoản.
Khi đọc Markdown, tôi chủ yếu điều chỉnh nó cho việc đọc văn bản dài.
Cỡ chữ, khoảng cách dòng và nền có thể thay đổi; bảng dài có thể cuộn ngang; tài liệu có cấu trúc tiêu đề có thể sử dụng mục lục để nhảy.
Cú pháp Obsidian phổ biến, chẳng hạn như danh sách tác vụ, Callouts, chú thích cuối, Frontmatter và thẻ, cũng được tương thích hết mức có thể.
Nó cũng hỗ trợ chuyển đổi giữa chế độ tối và các chủ đề màu sắc.
Khi đọc HTML, tôi quan tâm nhiều hơn đến "sự kiểm soát."
Nó sử dụng WebView hệ thống để hiển thị cục bộ, hỗ trợ phóng to, chuyển đổi giữa chế độ dọc và ngang, và chuyển đổi giữa chế độ di động và máy tính để bàn.
Các tập lệnh động bị tắt theo mặc định. Bạn thường không biết liệu có tập lệnh trong một tệp HTML lạ hay không.
Vì vậy, Jilan không giả định việc thực thi tập lệnh theo mặc định; nếu bạn gặp một trang thực sự cần JS để xem, bạn có thể bật nó theo cách thủ công.
Hỗ trợ ZIP cũng được tạo ra cho các tình huống thực tế.
Nhiều trang web do AI xuất ra không phải là một tệp HTML duy nhất, mà là một index.html cùng với một thư mục assets.
Jilan sẽ tự động tìm điểm truy cập sau khi giải nén, và các hình ảnh cũng như CSS cục bộ có thể tải bình thường, vì vậy kiểu dáng không bị mất và hình ảnh không bị lỗi.
Các tệp bạn đã mở sẽ tự động ở lại trong lịch sử cục bộ của bạn. Nếu lần sau muốn xem lại, bạn có thể tìm thấy chúng trong ứng dụng.
Việc nhập cùng một tệp nhiều lần sẽ không tạo ra các bản sao trùng lặp và các tệp quan trọng có thể được đánh dấu yêu thích.
Đây là ranh giới hiện tại của nó.
Nó không làm đồng bộ hóa đám mây, tài khoản, chỉnh sửa hoặc tích hợp AI.
Không phải vì những tính năng này không quan trọng, mà bởi vì một trình xem trước tiên phải thực hiện tốt công việc "mở và đọc xong" một cách sạch sẽ.
Jilan đi theo hai điều đầu tiên
Nhìn lại, Jilan không phải là một công cụ nhỏ biệt lập.
Tháng trước tôi đã tạo Kỹ năng PPT (PPT Skill) vì tôi tin rằng HTML sẽ trở thành một hình thức rất tự nhiên để AI tạo nội dung trình chiếu.
Nó không nhất thiết sẽ thay thế PowerPoint, nhưng để "nhanh chóng tạo ra thứ có thể trình bày," HTML đủ nhẹ, đủ mở và đủ phù hợp để các mô hình tạo ra trực tiếp.
Tôi tạo CodePilot vì tôi tin rằng Markdown sẽ trở thành một vật mang dữ liệu và bộ nhớ rất tự nhiên trong cộng tác AI.
Nó không phải là định dạng đẹp nhất, nhưng nó dễ nhất để con người, mô hình và công cụ sử dụng đồng thời.
Jilan xử lý bước thứ ba:
Các định dạng này không thể chỉ dừng lại ở việc "được tạo ra"; mọi người phải có thể thực sự mở, đọc và giữ chúng lại.
Hai điều đầu tiên là về sản xuất; Jilan là về tiêu thụ.
AI đã có thể tạo ra Markdown và HTML.
Nhưng nếu các tệp này bị hỏng ngay khi đến tay điện thoại, thì dù trải nghiệm tạo ra có suôn sẻ đến đâu, nó cũng chưa thực sự đến tay người dùng.
Jilan lấp đầy một dặm cuối cùng đó.
Nhưng điều này còn lâu mới kết thúc
Jilan hiện tại chỉ lấp đầy lớp nông nhất: nhận một tệp và mở nó.
Trong tương lai, vẫn còn một số vấn đề cần giải quyết.
Ví dụ, quản lý.
Rất nhiều người đã có một số lượng lớn các tệp Markdown và HTML rải rác trên điện thoại, ổ đám mây, lịch sử trò chuyện và các bộ nhớ đệm ứng dụng khác nhau.
Chúng không phải là không có giá trị; chúng chỉ quá phân tán để tìm kiếm hoặc quản lý.
Ví dụ, chia sẻ.
Jilan giải quyết "làm thế nào tôi xem những gì người khác gửi cho tôi."
Nhưng ngược lại, "tôi đã tạo một tệp HTML, làm thế nào để người khác mở nó một cách thuận tiện" vẫn còn là một vấn đề rắc rối.
Nếu bạn gửi tệp, người kia có thể không mở được; nếu bạn gửi một liên kết, bạn phải tự tìm một nơi để triển khai nó.
Ví dụ, đa thiết bị.
Đọc dở trên điện thoại và tiếp tục trên máy tính, hoặc tạo một báo cáo trên máy tính và đẩy nó sang điện thoại để đọc, đều rất tự nhiên.
Nhưng ngay khi bạn làm đồng bộ hóa, bạn gặp phải tài khoản, đám mây, quyền riêng tư và sự phức tạp.
Jilan vẫn còn rất nhỏ — nhỏ đến nỗi tôi không thực sự muốn đóng gói nó thành một sản phẩm lớn.
Nhưng nó hoàn toàn phù hợp với khoảng trống mà tôi gặp hàng ngày:
AI đã tạo ra nội dung, nhưng tôi chỉ muốn xem nó một cách tử tế trên điện thoại của mình.
Nếu bạn cũng thường xuyên bị làm phiền bởi các tệp Markdown, HTML và PPT web, hãy dùng thử.
TestFlight:
Tôi cũng rất muốn nghe suy nghĩ của bạn về điều này: sau sự tham gia của AI, các tài liệu, bài thuyết trình và việc đọc sẽ thực sự trở thành như thế nào?
