"Văn của AI dài quá, tôi thực sự không đọc hết nổi 😅"
"Tôi đang trả hơn 15.000 yên mỗi tháng cho Claude Code, nhưng không cảm thấy xứng đáng với số tiền đó."
Nhiều người chỉ hài lòng vì bản thân đang sử dụng AI, nhưng chỉ một số ít thực sự biến nó thành kết quả. Đó là trạng thái "cảm giác như đã dùng rồi."
Bạn đã từng gặp những tình huống này với Claude Code chưa?
- Bạn yêu cầu nó "tóm tắt xu hướng đối thủ tuần trước" vào sáng thứ Hai, và nó trả về một báo cáo dài. Bạn liếc qua rồi bỏ qua không đọc.
- Bạn nghi ngờ rằng nếu bạn không đọc kỹ các tài liệu do AI tạo ra, thì chắc chắn các thành viên trong nhóm cũng không đọc.
- Bạn trả hơn 3.000 yên mỗi tháng cho Claude Code, nhưng đầu ra chưa bao giờ được sử dụng trong một cuộc họp hay đề xuất nào.
- ChatGPT và Claude.ai cho ra kết quả đẹp mắt, nhưng tại sao Claude Code chỉ xuất ra Markdown, khiến việc đọc trở nên mệt mỏi đến vậy?
Bài viết này dành cho những người đó.
Khi bạn đọc xong, bạn sẽ có thể tự nhiên tạo ra các tài liệu từ Claude Code mà cả bạn và người khác thực sự sẽ đọc.
Bạn cũng sẽ có được góc nhìn rằng "định dạng đầu ra là gì" là yếu tố quan trọng hơn nhiều trong đánh giá của người dùng so với "bạn yêu cầu Claude Code làm gì."
Thariq Shihipar (@trq212), một nhà phát triển tại Anthropic, người thực sự xây dựng Claude Code, đã viết về một tư duy đang lan rộng trong công ty trên X, và nó đã trở thành một trong những bài đăng được lưu và chia sẻ nhiều nhất trong cộng đồng Claude Code.
Nó đã nhận được phản hồi rất lớn ngay sau khi phát hành.
Đây không chỉ là một mẹo nhỏ dành cho những người đam mê AI; đó là câu chuyện về người xây dựng công cụ thách thức Markdown, vốn đã là tiêu chuẩn ngầm của ngành AI, nói rằng "nó không còn là cách làm nữa."
Tôi nghĩ điều này quan trọng, vì vậy tôi quyết định giải thích nó bằng tiếng Nhật ngay lập tức.
Hai điều trước khi bạn bắt đầu đọc:
- Đánh dấu trang này. Chỉ trong tuần này, hãy dành thời gian để thử xuất ra HTML.
- Nếu bạn có thành viên trong nhóm sử dụng Claude Code, hãy chia sẻ điều này với họ. Cách các báo cáo hàng tuần và đánh giá PR của bạn được "đọc" sẽ thay đổi rõ rệt từ tuần sau.
Tôi sẽ phân tích và giải thích nội dung, đồng thời chuyển thể nó sang cách hoạt động trong bối cảnh kinh doanh Nhật Bản 👇
Bài đăng gốc tại đây:
https://x.com/trq212/status/2052809885763747935
Bản thân nhà phát triển Anthropic không còn sử dụng Markdown nữa
Đây là điểm khởi đầu. Thariq Shihipar (@trq212), người viết bài đăng gốc, là nhà phát triển đang xây dựng Claude Code tại Anthropic. Hành vi Claude hỏi lại người dùng ở "chế độ lập kế hoạch" để tinh chỉnh yêu cầu là một tính năng do chính anh ấy triển khai.
Anh ấy nói rằng mình không còn chấp nhận Markdown từ công cụ mà mình đang xây dựng. Theo cách nói của anh ấy, Markdown đã trở thành một định dạng hạn chế đối với anh ấy.
Đây không chỉ là sở thích cá nhân. Thariq đề cập rằng việc áp dụng HTML đang lan rộng trong chính nhóm Claude Code. Những người tạo ra công cụ này đang từ bỏ Markdown mà nó tạo ra và chuyển sang HTML.
Và bằng chứng có thể sờ thấy được. Trên trang demo https://thariqs.github.io/html-effectiveness/https://thariqs.github.io/html-effectiveness/), có 20 ví dụ HTML độc lập. So sánh ba cách tiếp cận đối với tìm kiếm debounced, các tương tác vi mô tạo cảm giác hoàn thành nhiệm vụ, danh sách token của hệ thống thiết kế, giải thích theo tab cho các ví dụ mã và tài liệu đọc có chú giải ở lề. Tất cả đều là những ví dụ thực tế về việc thay thế "tài liệu bạn chỉ liếc qua" bằng "tài liệu được đọc đến cuối." Bạn có thể mở chúng trong trình duyệt ngay bây giờ.
Đọc điều này, bạn sẽ nhận ra một điều. Các Artifacts bạn thường nhận được trong ChatGPT hoặc Claude.ai — những "giao diện có tab," "sơ đồ màu sắc," và "nút tương tác" — thực ra được xuất ra dưới dạng HTML. Nhận thức ở đây là: "Lý do chúng trông đẹp như vậy là do sự khác biệt trong chính định dạng." Giờ đây, thế giới đó có thể được mang đến tầm tay bạn với Claude Code.
Cho đến nay, văn bản do AI tạo ra hầu như chỉ là Markdown. Người xây dựng nó đang lặng lẽ bắt đầu phản đối, nói rằng "không còn nữa." Đó là cốt lõi của tin tức. Nhưng đối với bạn, người làm việc với AI hàng ngày, đây là một câu chuyện sẽ có hiệu quả từ sáng thứ Hai.
Markdown từng là tiêu chuẩn ngầm của ngành AI
Hãy xác nhận những giả định mà chúng ta coi là hiển nhiên. Nếu không có điều này, việc chuyển sang HTML có thể chỉ giống như một vấn đề về sở thích.
Cho đến nay, Markdown là tiêu chuẩn thực tế cho đầu ra của AI. Hãy nghĩ lại về văn bản bạn thấy hàng ngày:
- CLAUDE.md trong thư mục gốc của dự án, *.md cho định nghĩa agent, SKILL.md cho Skills.
- Tài liệu chính thức của Anthropic, Claude.ai Help và nhiều hướng dẫn Claude Code khác nhau.
- Các công cụ phát triển AI cạnh tranh, quy tắc Cursor, hướng dẫn GitHub Copilot và hướng dẫn Cline đều dựa trên .md.
- Wiki nội bộ, GitHub README, văn bản xuất từ Notion và biên bản cuộc họp dán vào Slack.
- Văn bản tóm tắt sao chép từ các cuộc trò chuyện ChatGPT.
Mọi thứ đều được xây dựng trên giả định về Markdown. Thật khó để tìm thấy một định dạng khác ngoài Markdown trong thông tin văn bản bạn gặp khi xử lý AI.
Hiện tượng mẫu CLAUDE.md của Karpathy thu về hơn 80.000 sao trên GitHub xảy ra chính xác bởi vì Markdown là ngôn ngữ chung của ngành.
Theo cách nói của Thariq, Markdown đã trở thành định dạng chính thống cho các agent. Anh ấy là người đã xây dựng các công cụ trên nền tảng Markdown trong một thời gian dài.
Giờ đây, người đó đã nói rõ: Markdown đã trở thành một định dạng hạn chế đối với tôi. Đây là khoảnh khắc một người trong nội bộ Anthropic ném đá vào tiền đề mà toàn bộ ngành công nghiệp đang dựa vào.
Nói một cách đơn giản: Markdown bạn nhận được từ Claude Code, các quy tắc Cursor đọc và đầu ra AI trên Wiki nội bộ của bạn đều là một phần của cùng một luồng "Markdown là ổn." Người tạo ra nó đã bắt đầu vẽ một kênh khác.
Từ đây, chúng ta sẽ đi vào chi tiết tại sao Markdown không đến được với mọi người và thay thế nó bằng gì.
5 lý do tại sao Markdown không được đọc
Hãy sắp xếp các hạn chế của Markdown. Đây không phải về thông số kỹ thuật; đó là về trải nghiệm hàng ngày của bạn từ thứ Hai đến thứ Sáu. Tôi đã liệt kê các lợi ích của HTML từ bài viết gốc bằng cách lật ngược chúng để chỉ ra điểm yếu của Markdown.
① Nếu vượt quá 100 dòng, ngay cả bạn cũng sẽ không đọc
Bản thân Thariq viết rằng khi một tệp Markdown vượt quá 100 dòng, anh ấy ngừng đọc nó.
Khi bạn yêu cầu Claude Code "tóm tắt xu hướng đối thủ tuần trước," có lẽ bạn đã từng trải nghiệm việc đóng phản hồi dài 120 dòng mà không cuộn. Nếu người tạo ra nó không đọc, thì không ai trong nhóm đọc. Thực tế là không chỉ tác giả, mà các thành viên khác trong tổ chức cũng chỉ đọc lướt qua.
② Ngay cả khi được chia sẻ, nó không mở đẹp trong trình duyệt, vì vậy không ai động vào
Markdown không được hiển thị đẹp một cách tự nhiên trong trình duyệt. Ngắt dòng bị hỏng trong Slack, định dạng bị hỏng trong email và mất công để chuyển đổi sang PDF hoặc chụp ảnh màn hình cho các đề xuất.
Mỗi lần chia sẻ, ai đó phải làm công việc chuyển đổi nó thành "dạng có thể đọc được." Markdown là một định dạng tạo ra ma sát mỗi khi được chia sẻ, đến mức các liên kết thường không được nhấp vào.
③ Không có màu sắc hoặc sơ đồ, vì vậy chỉ truyền tải được dàn ý
Bạn muốn nhấn mạnh sự khác biệt về số liệu, hiển thị cảnh báo bằng màu đỏ hoặc hiển thị luồng bằng mũi tên. Để làm điều này trong Markdown, bạn phải vẽ sơ đồ bằng ký tự ASCII hoặc thể hiện màu sắc bằng ký tự Unicode.
Không ai muốn giải mã điều đó, và người viết thì mệt mỏi. Ngay cả khi Claude cố gắng vẽ một sơ đồ, nó vẫn bị lướt qua.
④ Bạn không thể chạm hoặc di chuyển nó, vì vậy kết thúc chỉ bằng việc đọc
Bạn muốn thử một màu nhẹ nhàng hơn một chút, kiểm tra tốc độ của hoạt ảnh hoặc xem nó trông thế nào nếu bạn tăng giá trị lên 1,5 lần.
Trong kinh doanh, thường xuyên có những tình huống bạn cần "thử nó" để đưa ra phán quyết. Bạn không thể làm điều đó với Markdown. Bạn đọc nó, mô phỏng trong đầu, sau đó gửi lại hướng dẫn bằng văn bản — một vòng lặp kém hiệu quả.
⑤ Nó bị hỏng khi mở trên thiết bị di động
Slack, email hoặc Notion khi đang di chuyển. Trong bối cảnh kinh doanh Nhật Bản, một nửa số tài liệu được chia sẻ lần đầu tiên được mở trên thiết bị di động.
Bố cục Markdown không theo chiều rộng màn hình. Bảng tràn ngang, các khối mã bị ngắt dòng một cách khó coi và hệ thống phân cấp tiêu đề trở nên vô hình. Mong muốn đọc biến mất ngay lúc đó.
Hãy đặt tên cho điều này. Mỗi lần bạn tạo ra Markdown không thể đọc, sự mệt mỏi tích tụ cho cả người gửi và người nhận ngay cả trước khi mở nó. Chi phí cuộn 100 dòng, sửa ngắt dòng trong Slack, thất bại trong giao tiếp do thiếu sơ đồ và màu sắc, sự chậm trễ trong phán quyết vì không thể tương tác và sự hỏng hóc trên thiết bị di động.
Tất cả đều là những khoản phí ẩn phải trả hàng ngày. Trong bài viết này, chúng tôi gọi đó là "Format Tax."
Đây không phải là một khoản thuế nhỏ. Hơn một nửa giá trị của Claude Code được quyết định không phải bởi nội dung đầu ra, mà bởi "nó đến được với ai và đi được bao xa." Bằng cách xuất ra ở định dạng không đến được với mọi người, về cơ bản bạn đang vứt bỏ một nửa số tiền đăng ký của mình.
Cách chuyển đổi: Chỉ cần thêm "Xuất ra dưới dạng tệp HTML"
Bạn không cần phải suy nghĩ quá nhiều về điều này. Có ít việc phải làm hơn bạn nghĩ.
Chỉ cần thêm một dòng vào cuối yêu cầu Claude Code thông thường của bạn. Ba điều sau đây có nghĩa giống nhau:
- "Xuất ra dưới dạng tệp HTML"
- "Xuất ra dưới dạng HTML một trang"
- "Làm thành HTML để người đọc có thể mở trực tiếp"
Nếu bạn cảm thấy thoải mái hơn khi viết bằng tiếng Anh, "make a HTML file" hoặc "make a HTML artifact" cũng được. Kết quả là như nhau.
Claude Code có thể kéo ngữ cảnh từ MCP, trình duyệt, git và hệ thống tệp. Sức mạnh của Claude Code là nó có thể gói gọn các nguồn thông tin rộng hơn nhiều vào một HTML duy nhất so với các phiên bản trò chuyện web của ChatGPT hoặc Claude.ai.
Điều này kết nối lại với những gì chúng ta đã thảo luận trước đó. Các Artifacts bạn nhận được trong ChatGPT hoặc Claude.ai và nghĩ là "đẹp" đã được xuất ra dưới dạng HTML.
Giờ đây, bạn có thể nhận được cùng một thế giới đó ở phía Claude Code. Đó không phải là một câu chuyện kỹ thuật khó khăn; bằng cách thay đổi một dòng trong cách bạn yêu cầu, các tài liệu thực sự đến được với mọi người sẽ xuất hiện.
Thariq nhấn mạnh một điểm trong bài viết của mình: "Tôi không muốn điều này được đóng gói thành một Skill /html ngay bây giờ; tôi muốn mọi người làm quen với nó thông qua các prompt trước." Điều này mặc dù anh ấy là nhà phát triển trong nhóm Claude Code, người tạo ra Skills.
Anh ấy không bác bỏ việc biến nó thành một Skill. Anh ấy nói: "Nếu bạn đóng gói nó trước khi cách sử dụng được định hình, bạn sẽ bỏ lỡ những phần thực sự hiệu quả."
Trong nội bộ Anthropic, các đầu ra HTML đã trở nên phổ biến đang bắt đầu được thành phần hóa thành các plugin Playground. Thay vì chờ đợi một sản phẩm hoàn chỉnh ngay từ đầu, hãy thử nó với một prompt một dòng trước để tìm ra mẫu phù hợp với công việc của bạn. Chỉ sau khi đạt đến điểm đó, bạn mới nên chuyển sang biến nó thành một Skill.
Việc viết "xuất ra HTML" trong mỗi prompt có vẻ như là một nhiệm vụ, nhưng việc chọn định dạng không phải là một nhiệm vụ. Khoảnh khắc bạn chuyển từ Claude xuất Markdown sang Claude xuất HTML, bạn đã tiến được nửa bước để trở thành người "thiết kế đầu ra trước khi chờ đợi một Skill được thiết kế sẵn."
5 tình huống kinh doanh thay đổi chỉ bằng cách chuyển sang HTML
Chương này có hiệu quả cho công việc thực tế từ thứ Hai đến thứ Sáu. Tôi đã sắp xếp lại năm trường hợp sử dụng từ bài viết gốc theo thứ tự tần suất trong bối cảnh kinh doanh Nhật Bản: Báo cáo hàng tuần/Tóm tắt nghiên cứu, So sánh song song các đề xuất, Tinh chỉnh thiết kế, Màn hình chỉnh sửa ra quyết định và Đánh giá PR/Thông số kỹ thuật.
Mỗi tình huống được tóm tắt với vấn đề hiện tại, Trước/Sau và cuối cùng là một hướng dẫn mẫu để đưa cho Claude Code.
[Tình huống 1] Gửi báo cáo hàng tuần và tóm tắt nghiên cứu kèm sơ đồ
Một điều phổ biến trong kinh doanh Nhật Bản. Sáng thứ Hai, sếp của bạn yêu cầu: "Tóm tắt xu hướng tuần trước."
Trước đây: Bạn dán 120 dòng Markdown vào Slack. Ngắt dòng bị hỏng. Sếp không mở nó. Nó không được đưa vào tài liệu cuộc họp quản lý. Bạn kết thúc bằng cách giải thích bằng lời nói: "Tôi đã bảo Claude làm."
Sau này: Bạn tóm tắt nó thành một trang HTML duy nhất kết hợp nhật ký Slack, lịch sử ticket Linear hoặc Notion, nhật ký git và tài liệu nội bộ. Bạn bao gồm một sơ đồ luồng kinh doanh đơn giản bằng SVG và đặt ba điểm chính trong các khối màu ở cuối.
Nếu bạn đặt cái này vào bộ nhớ nội bộ và chia sẻ URL, sếp của bạn có thể mở nó trên điện thoại khi đi làm, ban quản lý có thể trích dẫn nó và nó có thể được dán vào biên bản cuộc họp.
Điểm mấu chốt ở đây là Claude Code có thể kéo ngữ cảnh từ MCP, trình duyệt, git và hệ thống tệp. Ngay cả khi bạn yêu cầu một trò chuyện web "tạo HTML," thật khó để gói gọn nhiều nguồn thông tin như vậy vào một. Đây là một báo cáo hàng tuần mà chỉ Claude Code mới có thể tạo ra.
Bản thân Thariq đã viết rằng anh ấy đã tạo các sơ đồ cho bài viết của mình bằng cách yêu cầu Claude Code đọc tất cả HTML trong thư mục mã của anh ấy và tóm tắt chúng thành một trang. Một "báo cáo hàng tuần được đọc" và một "sơ đồ cho bài viết giải thích được đọc" về mặt cấu trúc là giống nhau.
▼ Hướng dẫn mẫu:
"Đọc tất cả tương tác Slack tuần trước, ticket Linear đã hoàn thành và nhật ký git, sau đó xuất báo cáo hàng tuần dưới dạng một trang HTML duy nhất mà sếp của tôi có thể nắm bắt trong 1 phút. Bao gồm một sơ đồ luồng kinh doanh đơn giản bằng SVG và ba điểm chính trong các khối màu ở cuối. Đảm bảo nó không bị hỏng khi mở trên điện thoại thông minh."
[Tình huống 2] Hiển thị 6 phương án đề xuất/nghiên cứu cạnh nhau
Nên đi theo hướng nào cho đề xuất tuần tới? Một tình huống phổ biến trong lập kế hoạch, bán hàng và hoạch định doanh nghiệp, nơi nhiều phương án được tạo ra và thống nhất với những người ra quyết định.
Trước đây: Bạn gửi sáu phương án trong sáu tệp Markdown riêng biệt. Khách hàng không thể mở và so sánh từng cái một. Họ hỏi: "Cái nào là đề xuất hàng đầu của bạn?" và bạn nhận ra mình chưa so sánh đầy đủ chúng.
Sau này: Bạn sắp xếp sáu phương án với các tông màu, mật độ và đối tượng mục tiêu khác nhau trong một lưới trên một trang HTML duy nhất. Bạn thêm một dòng đánh đổi dưới mỗi phương án. Người ra quyết định so sánh tất cả trên một màn hình và ngay lập tức phản hồi: "Tôi muốn kết hợp cái này và cái này" hoặc "Sử dụng mục tiêu từ #3 với mật độ của #1." Việc giải quyết cuộc thảo luận thay đổi ngay khi bạn hiển thị chúng song song.
Đối với người ra quyết định, thời gian để phán xét khác xa giữa việc nhận sáu tệp và có sáu phương án xếp hàng trên một màn hình. Nó không chỉ là "khiến họ đọc nó" mà còn là "cho phép họ đưa ra quyết định."
▼ Hướng dẫn mẫu:
"Tạo 6 phương án đề xuất cho bài thuyết trình tuần tới với các tông màu, mật độ và đối tượng mục tiêu khác nhau, và sắp xếp chúng trong một lưới trên một trang HTML duy nhất. Viết một dòng đánh đổi dưới mỗi phương án. Ngoài ra, thêm một nút ở cuối để sao chép kết quả dưới dạng Markdown sau khi quyết định được đưa ra."
[Tình huống 3] Quyết định thiết kế và nguyên mẫu bằng cách chạm vào chúng
Khi quyết định màu sắc, kích thước hoặc chuyển động, bạn nên từ bỏ việc thống nhất thông qua văn bản. Đây là tình huống mà marketing, PR và lập kế hoạch qua lại nhiều lần về email cảm ơn hoặc nút trên trang đích.
Trước đây: Bạn giao tiếp bằng những từ như "màu xanh nhẹ nhàng hơn một chút" hoặc "làm cho chuyển động mềm mại hơn." Hình ảnh của người nhận lệch đi mỗi lần. Nhìn vào phiên bản quay lại sau một vòng, bạn thêm nhiều từ hơn: "Không, không phải loại nhẹ nhàng đó."
Sau này: Bạn yêu cầu Claude Code tạo một HTML nơi bạn có thể di chuyển thanh trượt cho màu sắc và tốc độ hoạt ảnh. Bạn tạo nguyên mẫu cho các nút email cảm ơn hoặc nút CTA trên LP dưới dạng các trang HTML duy nhất và gửi URL cho các bên liên quan. Mọi người chạm vào nó, quyết định các giá trị tốt nhất và chỉ sao chép các giá trị đó trở lại Claude. Sự qua lại bằng văn bản giảm đi và thời gian đạt được thỏa thuận rút ngắn.
Liên quan đến điều này, Anthropic Labs đang bắt đầu chính thức hóa khái niệm "chạm để quyết định và sao chép thao tác trở lại Claude" này như một plugin Playground. Đầu ra HTML không chỉ là một mẹo nhỏ; đó là một hướng đi mà chính Anthropic đang nuôi dưỡng như một mẫu hình.
▼ Hướng dẫn mẫu:
"Tạo một HTML nơi tôi có thể quyết định màu sắc và tốc độ hoạt ảnh của nút trong email cảm ơn bằng ba loại thanh trượt. Thêm một nút ở cuối để sao chép các giá trị đã quyết định."
[Tình huống 4] Tạo màn hình phán quyết trong 3 phút
Những biện pháp nào nên được gán cho Bây giờ, Tiếp theo, Sau này hoặc Cắt bỏ cho kỳ tiếp theo? Sắp xếp 30 ticket để quyết định ưu tiên là một "nhiệm vụ phán quyết" điển hình cho PdM, người lập kế hoạch và hoạch định doanh nghiệp.
Trước đây: Bạn xếp 30 mục trong một bảng tính và điền thủ công vào cột ưu tiên từng cái một. Bạn sắp xếp, suy nghĩ lại, chuyển sang trang tính khác và chuyển lại. Có ngày bạn dành 30 phút và vẫn không có kết luận.
Sau này: Bạn yêu cầu Claude Code "tạo một HTML nơi tôi có thể kéo và thả các mục vào bốn cột: Bây giờ, Tiếp theo, Sau này và Cắt bỏ." Một màn hình chỉnh sửa chuyên dụng đã sẵn sàng trong 3 phút. Bạn kéo 30 thẻ và khi hoàn thành, sao chép kết quả. Thời gian cho các nhiệm vụ phán quyết giảm đi một bậc độ lớn.
Có một nguyên tắc thiết kế ở đây dễ bị bỏ qua nhưng rất hiệu quả. Đó là câu mà Thariq viết: "Luôn kết thúc bằng một lần xuất." Khi tạo màn hình chỉnh sửa, luôn bao gồm các nút "Sao chép dưới dạng JSON," "Sao chép dưới dạng Prompt" hoặc "Sao chép dưới dạng Markdown."
Nếu không có điều này, bạn không thể trả lại kết quả sắp xếp của mình cho Claude và nó kết thúc chỉ như một công cụ nhiệm vụ. Một màn hình chỉnh sửa trở thành một thiết bị phán quyết chỉ khi bạn tạo một vòng lặp: phán quyết trong HTML, sau đó trả lại kết quả văn bản có cấu trúc cho Claude.
Ý tưởng tương tự này có thể được sử dụng để chỉnh sửa cờ tính năng, trình soạn thảo prompt hệ thống song song hoặc gắn nhãn phê duyệt/từ chối cho tập dữ liệu. "Tạo một giao diện dùng một lần, chuyên dụng trong 3 phút" là nơi giá trị thực sự của Claude Code được thể hiện rõ ràng nhất.
▼ Hướng dẫn mẫu:
"Tạo một HTML nơi tôi có thể kéo và thả 30 biện pháp cho kỳ tiếp theo vào bốn cột: Bây giờ, Tiếp theo, Sau này và Cắt bỏ. Cuối cùng, đặt một nút 'Sao chép dưới dạng Markdown' để tôi có thể xuất kết quả sắp xếp kèm lý do cho mỗi dòng."
[Tình huống 5] Bàn giao đánh giá PR và chia sẻ thông số kỹ thuật với diff được mã hóa màu
Cuối cùng, một tình huống cho việc cộng tác với các kỹ sư. Ngay cả khi bạn không đọc mã, với tư cách là PdM, giám đốc hoặc biên tập viên, bạn có thể được mời tham gia đánh giá PR hoặc xác nhận thông số kỹ thuật.
Trước đây: Bạn được yêu cầu mở màn hình diff GitHub. Bạn không thể biết phần nào của diff là quan trọng và phần nào có thể bỏ qua chỉ bằng cách nhìn. Bạn phải đọc các bình luận để theo dõi câu chuyện. Những người không đọc mã thường chỉ nói "cho tôi biết nếu có gì" và đóng nó lại.
Sau này: Bạn yêu cầu Claude Code "biến PR này thành một tài liệu đánh giá HTML mà người không đọc mã có thể nắm bắt trong 30 giây." Các bình luận được đính kèm bên cạnh các diff, phạm vi ảnh hưởng được mã hóa màu và một bản tóm tắt ba mối quan tâm được cung cấp ở cuối. Nếu bạn tải cái này lên bộ nhớ nội bộ và chia sẻ URL, các PdM và giám đốc có thể cung cấp phản hồi bằng một nút. Những người cộng tác với các kỹ sư cuối cùng có thể tham gia vào các đánh giá.
HTML không phải là ngôn ngữ dành cho kỹ sư; đó là một công cụ để truyền tải một câu chuyện. Ý nghĩa của diff, rủi ro và phạm vi ảnh hưởng — "thông tin yêu cầu giải mã" này được truyền tải với chú thích, màu sắc và bố cục. Đó là ý nghĩa của việc chuyển đổi HTML.
▼ Hướng dẫn mẫu:
"Biến PR này thành một tài liệu đánh giá HTML mà người không đọc mã có thể nắm bắt trong 30 giây. Đính kèm bình luận bên cạnh các diff, hiển thị phạm vi ảnh hưởng bằng mã hóa màu và tóm tắt ba mối quan tâm ở cuối."
Trong khi bạn tiếp tục xuất ra Markdown cho năm tình huống này, format tax đang lặng lẽ nhưng tích lũy hàng ngày. Việc bạn dừng nó ngay khi nhận ra sẽ là sự khác biệt bắt đầu từ tuần sau.
6 câu hỏi nảy sinh khi chuyển đổi
Đọc điều này, có lẽ một số câu hỏi sẽ xuất hiện trong đầu bạn. Tôi đã sắp xếp lại phần FAQ từ bài viết gốc theo thứ tự mà độc giả kinh doanh Nhật Bản có khả năng gặp phải.
■ Nó có sử dụng nhiều token hơn không?
Có, nó có. Bài viết gốc nói rằng mất thời gian gấp 2-4 lần để tạo so với Markdown. Tuy nhiên, Opus 4.7 có ngữ cảnh 1M token, vì vậy rủi ro các cuộc trò chuyện bị gián đoạn do giới hạn ngữ cảnh từ việc trả về HTML hầu như không còn.
Kết luận của Thariq là: "Các con số tăng lên, nhưng nếu bạn chọn kết quả được đọc, nó sẽ được đền đáp cho tổng thể công việc." Đó là sự lựa chọn giữa việc sử dụng hợp đồng hàng tháng hơn 3.000 yên của bạn cho 1.000 dòng Markdown không được đọc hoặc một trang HTML được mở.
■ Thiết kế có bị xấu không?
Đây là một mối quan tâm chính đáng, nhưng có các biện pháp đối phó.
Một là sử dụng các plugin thiết kế giao diện người dùng của Claude Code. Một cách khác là cung cấp cho Claude một mẫu HTML từ trang web của công ty bạn hoặc các tài liệu hiện có. Nếu bạn cung cấp một tệp tham khảo và nói "theo tông màu này" hoặc "với phông chữ và bảng màu này," Claude sẽ xuất ra HTML phù hợp với diện mạo công ty bạn. Giữ một tệp như design-system.html trong cơ sở mã của bạn cho phép bạn tham khảo nó mỗi lần.
■ Chỉnh sửa HTML có phiền phức không?
Bạn không cần phải tự chỉnh sửa nó.
Bản thân Thariq viết rằng anh ấy không trực tiếp chạm vào HTML. Nếu bạn nói với Claude, "Làm dịu màu này một chút" hoặc "Làm phần thứ ba nhỏ hơn một chút," nó sẽ sửa cho bạn. Miễn là bạn sử dụng nó cho thông số kỹ thuật, động não hoặc tài liệu tham khảo, bạn có thể để lại tất cả việc chỉnh sửa cho Claude.
■ Làm thế nào để mở nó? Làm thế nào để chia sẻ nó?
Mở nó rất dễ dàng. Chỉ cần mở tệp HTML mà Claude Code tạo ra cục bộ trong trình duyệt của bạn.
Bạn thậm chí có thể yêu cầu Claude "mở tệp này" và nó có thể mở nó trong trình duyệt cho bạn. Khi chia sẻ, cách dễ nhất là tải nó lên bộ nhớ nội bộ hoặc S3 và cung cấp URL. Nếu bạn dán liên kết trong Slack hoặc email, người nhận có thể mở nó trong trình duyệt của họ. Bước bổ sung đó là chuyển đổi Markdown sang PDF hoàn toàn biến mất.
■ Kiểm soát phiên bản thì sao?
Thành thật mà nói, HTML không phù hợp lắm cho việc quản lý diff Git. Sửa một dòng có thể di chuyển diff sang nơi khác do cài đặt formatter. Bản thân Thariq viết rằng HTML là điểm yếu lớn nhất của kiểm soát phiên bản.
Đó là lý do tại sao giải pháp thực tế là: "Sản phẩm bàn giao cho con người" là HTML và "thông số kỹ thuật hoặc hồ sơ bạn muốn giữ lịch sử" là Markdown. Không phải là xóa bỏ Markdown, mà là chuyển sang tư duy chọn định dạng dựa trên mục đích của đầu ra.
■ Tôi có thể ngừng sử dụng Markdown hoàn toàn không?
Không. Hồ sơ, lịch sử thay đổi và văn bản có cấu trúc bạn muốn giữ trong kho lưu trữ nên vẫn là Markdown.
CLAUDE.md và SKILL.md dễ quản lý và theo dõi diff hơn nếu chúng vẫn là Markdown. HTML phù hợp cho việc "gửi đến mọi người," "cho mọi người chạm vào," "xếp nhiều phương án" và "cho mọi người phán quyết bằng màu sắc." Nếu bạn hiểu nó một cách rộng rãi là "Markdown để tương tác với AI, HTML để phân phối cho mọi người," bạn sẽ không bị lạc.
Đến bây giờ, những nghi ngờ ban đầu của bạn sẽ được giải tỏa. Một bài viết bao gồm cả nhược điểm đáng tin cậy hơn — đó là niềm tin của tôi với tư cách là một người viết.
Bạn sẽ tiếp tục trả Format Tax hay chuyển sang phía thiết kế?
Cuối cùng, hãy nâng tầm nhìn của chúng ta lên để kết thúc.
Chúng tôi đã thảo luận trước đây về "Thuế Prompt"—chi phí phải gõ lại cùng một tiền đề cho Claude. Sau đó, là câu chuyện chuyển sang lớp thiết kế với thư mục .claude. "Thuế Định dạng" này là chủ đề thứ ba trong loạt bài đó. Sau lớp hội thoại và lớp thiết kế, giờ chúng ta đã đề cập đến lớp đầu ra.
Hãy định nghĩa "Format Tax" như một điều chúng ta có thể chia sẻ với độc giả:
Nếu bạn cứ chọn những định dạng đầu ra không được đọc, sự mệt mỏi sẽ tích tụ cho cả bạn và người khác ngay cả trước khi mở ra. Bạn trả hơn 3.000 yên mỗi tháng cho Claude Code, nhưng các sản phẩm lại không bao giờ được dùng trong các cuộc họp. Cảm giác đó đến từ việc không đưa ra phán quyết về lựa chọn định dạng. Đây chính là Format Tax.
Xuất ra Markdown là một công việc. Chọn HTML là một quyết định. Dù sử dụng cùng Claude Code, một quyết định duy nhất trong việc chọn định dạng sẽ thay đổi đáng kể khoảng cách mà sản phẩm của bạn có thể tiếp cận.
Và HTML không phải là ngôn ngữ dành cho kỹ sư. Nó là công cụ để tạo ra những tài liệu được đọc. Hãy tạm gác ý tưởng xây dựng một trang web sang một bên. Chỉ cần thử xuất báo cáo tuần, đề xuất hoặc tài liệu đánh giá mà bạn đang viết trong tuần này dưới dạng HTML. Thế là đủ.
Hãy nói về bức tranh lớn hơn.
Kỷ nguyên mà Markdown là tiêu chuẩn ngầm của ngành AI đang lặng lẽ kết thúc bên trong Anthropic. Trong khi CLAUDE.md, SKILL.md và các quy tắc Cursor đều được xây dựng trên nền tảng Markdown, thì định dạng đầu ra đang bắt đầu chuyển đổi trước tiên. Những độc giả nào chứng kiến khoảnh khắc tiêu chuẩn thay đổi có thể tiến lên nửa bước.
Tất nhiên, một khi bạn nhận ra "Tôi làm việc này mỗi tuần," bạn có thể chọn phát triển nó thành một Skill.
Bên trong Anthropic, các mẫu có tần suất cao cho đầu ra HTML, như Playgrounds liên quan đến thiết kế, đang dần được nuôi dưỡng như các thành phần. Tuy nhiên, trong tuần đầu tiên, một dòng lệnh là đủ. Tối nay, hãy thử xuất chỉ một báo cáo tuần dưới dạng HTML. Tuần sau, hãy thử sắp xếp sáu tùy chọn đề xuất trong một lưới duy nhất. Bắt đầu từ đó, và thuế định dạng sẽ lặng lẽ giảm dần.
Chính Thariq đã viết ở cuối bài viết của mình: "Tôi từng sợ phải ngừng đọc sâu Markdown và giao phó mọi phán quyết cho Claude. Kể từ khi chuyển sang HTML, tôi cảm thấy mình quay lại vòng lặp với Claude hơn, và trên hết, việc tạo ra nó thật sự rất vui."
Chọn một định dạng là một công tắc để giành lại quyền chủ động khi làm việc với AI, đồng thời cũng là một công tắc để mang lại một chút nhiệt huyết cho công việc hàng ngày của bạn.
Bạn sẽ tiếp tục sản xuất Markdown không được đọc, hay sẽ chuyển sang phe chọn định dạng? Tuần tới sẽ là ranh giới.
Tóm tắt
- Nhà phát triển xây dựng Claude Code tại Anthropic tuyên bố không còn sử dụng Markdown nữa. Việc áp dụng HTML đang lan rộng trong nội bộ nhóm.
- Cho đến nay, Markdown là tiêu chuẩn ngầm cho AI—từ Claude Code, Cursor đến GitHub Copilot, Cline, Wiki nội bộ và đầu ra ChatGPT. Người sáng tạo đã thách thức tiêu chuẩn ngành đó.
- Có 5 lý do Markdown không được đọc: không thể đọc lại ở 100 dòng / bị hỏng khi chia sẻ / không có màu sắc hay biểu đồ / không thể chạm để đánh giá / bị hỏng trên di động. Những chi phí ẩn này là "Format Tax."
- Để chuyển đổi, chỉ cần thêm một dòng: "Xuất ra dưới dạng tệp HTML." Việc biến nó thành Skill có thể chờ cho đến khi việc sử dụng đã ổn định.
- 5 tình huống kinh doanh—báo cáo tuần, đề xuất song song, tinh chỉnh thiết kế, màn hình đánh giá và đánh giá PR—biến thành tài liệu được mở, đánh giá và phản hồi chỉ bằng cách chuyển sang HTML.
- Chọn định dạng là một phán quyết, không phải một công việc. Xuất ra Markdown là một công việc; chọn HTML là một phán quyết. Sự khác biệt giữa người dùng Claude Code mở ra ở đây.
Dành cho những ai thấy bài viết này hữu ích:
Phòng thí nghiệm Claude Code của Đại học Tokyo (@ClaudeCode_UT) là một tài khoản được vận hành nghiêm túc bởi một nhóm sinh viên Đại học Tokyo. Chúng tôi cũng đang hợp tác phát triển kinh doanh Claude Code với các công ty lớn, và chúng tôi chỉ chia sẻ những thiết kế và bí quyết thực sự hiệu quả trên thực tế.
Chúng tôi cung cấp thông tin và bí quyết "thực sự hữu ích" chuyên biệt cho công việc thực tế mỗi ngày 👇
■ Phát hành miễn phí các kỹ năng Claude Code có thể sử dụng trong thực tế
■ Dịch thuật và tái cấu trúc thông tin AI chính thống từ nước ngoài vào bối cảnh kinh doanh Nhật Bản
■ Đây là nơi duy nhất để nhận miễn phí các kỹ năng và công cụ được phát triển nghiêm túc bởi nhóm Đại học Tokyo mà "thực sự hữu ích" ❗️
Nếu bạn quan tâm, hãy theo dõi và xem thử.
LINE ở đây ⇩
