Sự "Emacs hóa" của Phần mềm: Khi AI biến mọi người thành nhà phát triển công cụ riêng

Công nghệ13 tháng 5, 2026·12 phút đọc

Bài viết khám phá xu hướng "Emacs hóa" phần mềm, nơi các tác nhân AI cho phép người dùng nhanh chóng tạo ra các công cụ giao diện người dùng gốc (native UI) tùy chỉnh để giải quyết các vấn đề cá nhân. Thay vì phụ thuộc vào các ứng dụng có sẵn hay mã nguồn phức tạp, tương lai của phát triển phần mềm đang chuyển dịch sang việc sử dụng prompt để cấu hình và xây dựng giải pháp riêng biệt.

Sự "Emacs hóa" của Phần mềm: Khi AI biến mọi người thành nhà phát triển công cụ riêng

Bạn thực sự cần một trình xem Markdown tốt hơn bạn nghĩ.

Chúng ta đều đọc một lượng lớn Markdown mỗi ngày. Nó đã trở thành ngôn ngữ chung của phát triển phần mềm từ lâu trước khi các mô hình ngôn ngữ lớn (LLM) ra đời. Tuy nhiên, sự trỗi dậy của các tác nhân AI đã đẩy chúng ta vào một giai đoạn tái sinh đầy rắc rối của các công cụ giao diện dòng lệnh (TUI), khiến trải nghiệm đọc trở nên khó chịu. Tôi chắc chắn rằng khoảng 14% sự bực bội đối với mã AI xuất phát từ sự kiệt sức khi phải liên tục cuộn qua các file Markdown trong terminal.

Các công cụ TUI hiện cóCác công cụ TUI hiện có

Có những trình xem Markdown TUI tốt. Các bạn từ Charm đã xây dựng glow, một công cụ tôi đã dùng và thích. Bạn tôi Josh đã xây dựng Markless, một công cụ đẹp mắt với đầy đủ tính năng, nổi bật nhất là điều hướng mục lục. Những công cụ này rất tuyệt. Nhưng chúng bị hạn chế bởi chính terminal, vốn hầu như luôn sử dụng font đơn cách (monospaced) và gây mỏi mắt khi đọc lâu.

Ở phía bên kia, có những trình soạn thảo Markdown với giao diện đồ họa (GUI). Trên macOS, nơi tôi sống, có Obsidian, Typora và Bear — công cụ hàng ngày của tôi. Các trình soạn thảo Markdown với giao diện gốc này hấp dẫn và dễ đọc. Trải nghiệm đọc tốt. Nhưng chúng là các trình soạn thảo. Các trình soạn thảo của tôi nằm ở các màn hình ảo cụ thể, với các cửa sổ được sắp xếp rất kỹ, và việc nhấp ngẫu nhiên vào một file .md làm xáo trộn môi trường soạn thảo của tôi thực sự khiến tôi phát điên.

Vì vậy, tôi đã vào App Store, nơi thực sự có các trình xem Markdown. Chúng cũng ổn thôi. Không cái nào thực sự tốt. Tôi chỉ muốn một hành động hợp lý xảy ra khi tôi nhấp đúp vào một file .md, và các trình xem bạn có thể lấy từ App Store thoạt đầu có vẻ hợp lý. Chỉ sau khi sử dụng một lúc, các vấn đề mới trở nên rõ ràng. Một số thiếu tính năng tìm kiếm văn bản. Một số khác có mua hàng trong ứng dụng (?!). Tôi đã chọn một cái, chỉ để phát hiện vài ngày sau rằng nó không hỗ trợ sao chép văn bản vào bộ nhớ tạm. Lúc đó, tôi chán nản rồi.

Đột nhiên, tôi nhận ra: việc lãng phí thời gian tìm kiếm một trình xem Markdown tốt là một điều ngớ ngẩn. Đây là năm 2026. Tôi có thể để AI tạo ra một cái cho mình.

MDV.app - Trình xem Markdown tùy chỉnhMDV.app - Trình xem Markdown tùy chỉnh

Mất vài giờ để tạo ra một trình xem Markdown tốt hơn những gì tôi tìm thấy trên App Store, nhưng chỉ khoảng 30 phút trong số đó là thời gian tương tác. Phần còn lại là dành để than thở về cải cách quy hoạch trên Facebook trong khi Claude chạy ngầm. Kết quả là MDV.app:

Tôi đang gian lận một chút về mốc thời gian này, vì tôi đã chuẩn bị vài tuần trước đó. Tôi huy động một chiếc Macbook cũ để chạy Claude. Cài đặt Xcode và git. Cấu hình Claude và tìm hiểu một số kỹ năng về Swift và thiết kế macOS. Nhưng chính trình xem đó, ở trạng thái khả dụng, tốt hơn bất kỳ thứ gì trên App Store: khoảng 30 phút.

MDV không phải là ứng dụng macOS tốt nhất từng được xây dựng. Hay thậm chí là một phần mềm đặc biệt xuất sắc (dù nó có thể là trình xem Markdown macOS chuyên dụng tốt nhất). Nhưng nó đã cải thiện chất lượng cuộc sống của tôi một cách đáng kể.

Nó làm được tất cả những thứ ngầu nghẻ. Claude và tôi đã giải quyết được vấn đề chọn và sao chép văn bản từ tài liệu, cũng như tìm kiếm các chuỗi cố định bên trong chúng. Ngoài ra: MDV giữ chỉ mục tìm kiếm toàn văn (SQLite FTS) của tất cả các file Markdown trong lịch sử (có thể chỉnh sửa) của nó, cùng với các dấu trang tắt phím và điều hướng mục lục. Nó nhớ vị trí của tôi, qua các lần khởi động lại, trong tài liệu khi tôi chuyển đổi giữa chúng. Và nó có các chủ đề màu sắc kỹ tính và typography ổn, đây là tính năng quan trọng nhất mà một trình xem Markdown chuyên dụng có thể có. Tất cả những thứ này giờ đây hoạt động trơn tru, bất cứ khi nào tôi nhấp vào một file .md. Tuyệt vời.

Đây là cách tôi biết đây là một vấn đề lớn: vì mỗi khi ai đó gửi cho tôi tin nhắn Signal, màn hình của tôi nhấp nháy. Nó không dừng lại cho đến khi tôi ẩn ứng dụng Signal một cách rõ ràng, điều mà tôi luôn quên làm cho đến khi bị nhức đầu nhẹ vì sự nhấp nháy tinh tế đó.

Điều này xảy ra vì Signal là một ứng dụng Electron, nghĩa là mặc dù nó trông giống như một ứng dụng macOS gốc, nhưng thực tế không phải. Nó là một bản sao hoàn chỉnh của Chromium đang hiển thị một trang web bí mật. Hầu hết mọi ứng dụng UI được phát hành trong 10 năm qua đều chia sẻ thuộc tính này, mỗi cái mang theo một bản sao Chromium nhấp nháy riêng.

Electron không tốt. Nhưng nó luôn "đủ tốt". Xây dựng giao diện người dùng gốc thực sự về mặt lịch sử là một vấn đề khó, bắt đầu từ việc tìm kiếm nhân tài thay thế được để làm công việc này. Các nhà phát triển UI macOS gốc có năng lực là những loài chim hiếm.

Nhưng Claude không chỉ là một nhà phát triển SwiftUI ở mức thay thế được. Claude thực sự giỏi.

Đây không phải là một bài viết về cái chết sắp tới của Electron (nếu được thì tốt). Nó cũng không nhằm khiến bạn dùng trình xem Markdown tuyệt vời của tôi, vốn cực dễ cài đặt và tốt hơn bất kỳ trình xem nào trên App Store và bạn chắc chắn nên dùng nó.

Thực ra, không! Dừng lại. Đừng cài đặt nó. Hãy đối xử với trình xem Markdown tuyệt vời của tôi — vốn rất tuyệt — theo cách mà người dùng Emacs đối xử với một file .emacs đặc biệt bóng bẩy. Hãy lấy ý tưởng và làm một cái tốt hơn.

Đối với những người chưa biết, đây là cách văn hóa Emacs hoạt động: những người gắn bó trọn đời với nó xây dựng các ứng dụng hoàn chỉnh trong elisp (một trong những ngôn ngữ khủng khiếp nhất thế giới). Những "ứng dụng" này luôn bắt đầu để giải quyết một nhu cầu cá nhân liên quan đến soạn thảo văn bản, và không thể tránh khỏi việc mở rộng tham vọng và phạm vi vượt xa mọi giới hạn hợp lý của những gì trình soạn thảo văn bản nên làm. Nếu bạn nhìn vào /r/emacs, đó là 0% Product Hunt, 100% show-and-tell.

Có các gói elisp phổ biến mà nhiều người dùng. Nhưng ngoại trừ Magit, các mọt sách có khả năng đáng báo động là thay thế chúng bằng các phiên bản bóng bẩy hơn của riêng họ (và sau đó khoe chúng, chuyển sang giai đoạn hình thành bào tử của vòng đời elisp). Mọi thứ trong Emacs đều có thể uốn nắn.

Cho đến nay, gót chân Achilles của văn hóa Emacs là rằng, ngoại trừ Magit, các gói của nó có xu hướng mang lại trải nghiệm người dùng thảm hại. Xấu xí, chậm chạp, và chỉ có thể khám phá sau khi tự gây ra những tổn thương vỏ não elisp trong nhiều năm.

Nhưng các tác nhân AI đã khoan thăm dò văn hóa Emacs, và nó đang rò rỉ ra thế giới rộng lớn hơn. Được cung cấp quyền truy cập vào màn hình và đầu vào, các tác nhân xây dựng đáng tin cậy các giao diện người dùng gốc. UI gốc là lãnh thổ của các chương trình được đóng gói chuyên nghiệp. Giờ đây, tất cả đều tùy biến như cấu hình trình soạn thảo của bạn. Và, trong khi tôi chắc chắn có giới hạn trên về mức độ tốt của những giao diện đó (với các mô hình tiên phong hiện tại), trần đó cao hơn bất cứ thứ gì bạn có thể làm trong TUI.

Vậy điều gì có nghĩa là phần mềm được "Emacs hóa"? Hãy cùng đi sâu vào nó.

Đầu tiên, đó là phần mềm cá nhân. Hầu hết trong số nó sẽ chỉ hữu ích cho người tạo ra nó, và sau đó bị lãng quên, giống như hàng chục chương trình elisp nhỏ lỗi thời nằm rải rác trong .emacs của tôi. Phần mềm cá nhân định hình tinh thần của Emacs, vốn được thiết kế cẩn thận trong nhiều thập kỷ để nuôi dưỡng các loại công cụ này. "Emacs hóa" đồng hồ hóa rằng mọi thứ giờ đây hoạt động theo cách này, không chỉ là các trình soạn thảo văn bản cầu kỳ.

Tuy nhiên, thỉnh thoảng, một trong những chương trình này sẽ thoát ra khỏi giới hạn. Nó sẽ đủ hữu ích để nhiều hơn một người cài đặt. Nhưng ngay cả khi đó, sản phẩm được phát hành cũng không phải là điều quan trọng nhất về nó. Mã nguồn cũng không phải. Nếu một tác nhân đã viết tất cả mã SwiftUI trong dự án của tôi, bạn có được gì từ việc đọc kỹ nó?

Tôi có lẽ chỉ đúng một chút về điều này, nhưng tôi nghĩ một động lực đáng kể của các gói Emacs mới là phản ứng xúc tác giữa cấu hình cục bộ lộn xộn của bạn và mã elisp của mọi người khác. Một khi bạn biết cách hoàn thành công việc trong elisp, việc xây dựng giải pháp của riêng bạn có thể dễ dàng hơn là cài đặt gói một cái có sẵn. Trong môi trường đó, mã chỉ là sự quan tâm nhất thời. Điều quan trọng là các ý tưởng, sự quan sát rằng "ừ, bạn có thể làm điều đó, và nó sẽ hoạt động tốt".

Đối với các loại phần mềm tôi đang nói về, bạn muốn các câu lệnh (prompt) hơn là mã nguồn.

Nếu bạn là một mọt sách thoải mái với ý tưởng tự làm phần mềm của riêng mình, mọi thứ giờ đây đều có thể lập trình, không chỉ ở nghĩa kỹ thuật mà còn ở nghĩa thực tế. Và điều đó dẫn đến một cảm giác mà tôi nghĩ nhiều người có khi tạo phần mềm với các tác nhân: điều gì có nghĩa là nói bạn đang "xây dựng" nó? "Xây dựng" ngụ ý nhiều nỗ lực hơn những gì bạn bỏ ra. Những gì bạn đang làm cảm giác giống như cấu hình hơn, trên một nền tảng đột nhiên trở nên có thể cấu hình nhiều hơn rất nhiều. Một nền tảng cảm giác rất giống Emacs.

Điều đầu tiên mà một nhà phát triển "bị nhiễm" AI nói với bạn sau khi lao xuống là cách họ cuối cùng đã hoàn thành tất cả các dự án phụ ngẫu nhiên mà họ đã tích lũy trong nhiều năm.

Đó là một triển vọng thú vị trên chính nó. Nhưng hiện tại cũng là trường hợp rằng những thứ đó, dù cụ thể đến mức nào, cũng có thể dễ chịu khi sử dụng. Tôi không bỏ qua sự mỉa mai khi sự Emacs hóa làm suy yếu nhiều lập luận để chịu đựng chính Emacs, và các giao diện người dùng xập xệ của nó. Magit vẫn là thứ tốt nhất hiện nay. Hiện tại.

Tôi không có một tuyên bố hùng hồn nào để đưa ra về Tương lai của Phần mềm. Nhưng tôi khá chắc chắn phần mềm dành cho mọt sách sẽ trở nên thú vị hơn nhiều. Chúng ta có thể cải thiện mạnh mẽ (và dễ dàng) bao nhiêu ứng dụng terminal kêu kẽt? Tôi cuối cùng sẽ có thể hiểu iostat! Trên cả một đội máy chủ, thậm chí. Và bpftrace! Bạn đã thấy những rắc rối mà Brendan Gregg phải chịu đựng để thực hiện trực quan hóa terminal từ bpftrace chưa? Bạn không phải chịu đựng bất kỳ điều nào trong số đó nữa. Thực tế, tôi cũng không.

Tôi là một nhà nghiên cứu lỗ hổng, và tôi đã như một đứa trẻ trong cửa hàng kẹo trong nửa đầu năm 2026 với tất cả các đột phá trong phát triển khai thác bằng mã hóa tác nhân. Nhưng tôi hiểu điều đó khiến tôi trở nên kỳ quặc, và rằng đối với hầu hết các bạn, tất cả những gì đi kèm với những tiến bộ đó là nỗi sợ hãi.

Vì vậy, tôi rất vui mừng khi có một cái gì đó mới để nói về thực sự cảm thấy như một điều tốt tuyệt đối. Xây dựng UI gốc giờ đây vui vẻ; vui hơn nhiều so với việc xây dựng giao diện web từng là. Hãy thử nó; làm một cái gì đó ngớ ngẩn cụ thể cho vấn đề của riêng bạn, tận hưởng nó một chút, và sau đó chia sẻ nó ở đâu đó — hoặc tốt hơn, chỉ là một ảnh chụp màn hình và các câu lệnh bạn dùng để tạo ra nó.

Cải thiện giao diện cho các công cụ dòng lệnhCải thiện giao diện cho các công cụ dòng lệnh

Chia sẻ:FacebookX
Nội dung tổng hợp bằng AI, mang tính tham khảo. Xem bài gốc ↗