Các hướng dẫn viết chính thức của Microsoft và Google rất mạnh. Chúng dạy ta viết câu ngắn, nói ý chính trước, thống nhất thuật ngữ, viết sao cho dễ dịch, và làm cho văn bản ai đọc cũng thấy dễ chịu.
Nhưng thuốc mạnh không khiến ta khỏe lên chỉ vì uống hết cả chai. Nếu áp dụng hướng dẫn chính thức một cách máy móc, như thể đó là điều luật phải làm theo từng chữ, bài viết sẽ bỗng nhiên xin chuyển sang làm ở trung tâm hỗ trợ của một công ty. Văn bản hôm qua còn càu nhàu "sao lại ra nông nỗi này chứ?" thì sáng hôm sau chỉ còn biết nói "Vui lòng thực hiện các bước sau." Tính cách đã bị đem ra qua hội đồng phê duyệt.
Kết luận rất đơn giản.
Thứ nên mượn từ hướng dẫn chính thức là sự khôn ngoan về cấu trúc, độ rõ ràng, khả năng tiếp cận và viết đa ngôn ngữ, để người đọc không bị lạc. Thứ không mượn là việc đồng phục hóa văn phong khi nó không hợp với mục đích của trang mình.
Và đây không phải tuổi dậy thì nổi loạn chống lại hướng dẫn. Chính hướng dẫn phong cách dành cho lập trình viên của Google cũng nói hãy dùng quy tắc riêng của dự án trước, và có thể lệch khỏi hướng dẫn nếu điều đó có lợi cho người đọc.[4] Rốt cuộc, cả Microsoft lẫn Google đều đặt "người đọc dễ hiểu" ở trung tâm.[1][2][5]
Kết luận trong 5 giây: hướng dẫn là lan can, không phải hiến pháp
Dùng hướng dẫn chính thức sẽ ít gặp tai nạn hơn nếu chia làm ba tầng.
| Tầng | Vai trò | Ví dụ |
|---|---|---|
| Điều kiện bắt buộc | Thứ phải tuân thủ: luật, tiêu chuẩn, đặc tả chính thức | Yêu cầu chính thức về khả năng tiếp cận, tên sản phẩm chính xác, trích dẫn và nguồn |
| Khuyến nghị mạnh | Nguyên tắc giúp dễ đọc lên rất nhiều | Kết luận trước, tiêu đề tạo mạch bài, đoạn ngắn, thống nhất thuật ngữ |
| Hương vị của trang | Thứ được thiết kế theo trang, tác giả và độc giả | Hài hước, ẩn dụ, những câu châm chọc, nhịp điệu, giọng cuối câu, trò đùa quen thuộc |
Rắc rối bắt đầu ngay khi biến cả ba tầng thành "quy tắc tuyệt đối".
Ví dụ, hướng dẫn của Google cho lập trình viên khuyên tránh thành ngữ và sự hài hước phụ thuộc vào văn hóa trong tài liệu kỹ thuật dành cho độc giả toàn cầu.[5] Với tài liệu hướng dẫn cấu hình API được dịch ra 12 thứ tiếng, điều đó rất hợp lý.
Nhưng đó không phải lý do để biến bài review món ăn, nhật ký du lịch, trải nghiệm chơi game, tản văn hay bài quan sát thành "Cấm cười: tài liệu kỹ thuật 24 giờ".
Nhập quy tắc về mà không xem phạm vi áp dụng, ta có thể lắp ra cỗ máy sai từ những linh kiện đúng.
Vì sao dùng nguyên xi hướng dẫn chính thức dễ khiến bài nhạt
Chỉ dẫn của Microsoft về cách viết dễ lướt đọc khuyên đặt thông tin quan trọng lên trước, dùng tiêu đề, câu và đoạn ngắn, và có cách điều hướng cho văn bản dài.[1] Chỉ dẫn về khả năng tiếp cận cũng coi trọng văn bản ngắn, có nghĩa và tập trung.[2]
Đến đây vẫn rất vững.
Nhưng khi tự động hóa và bắt đầu chấm điểm kiểu "càng ngắn càng cao điểm", "xóa ẩn dụ", "xóa từ cảm xúc", "xóa khẩu ngữ" thì mọi thứ hỏng.
Câu ngắn nhiều quá.
Và thế là.
Bài viết.
Thành ra thế này.
Định cho dễ đọc, vậy mà lại nhận về một con robot đánh điện tín.
Ngược lại, nếu thống nhất triệt để mọi đoạn theo "kết luận, lý do, ví dụ", vài bài đầu thì thấy đã, nhưng đến bài thứ 1000 thì người đọc đã đoán trước được tương lai. Thiết kế thông tin cần nhất quán, nhưng không cần cả cách trình diễn cũng giống hệt nhau.
Làm cho dễ đọc không phải là việc rút cá tính ra khỏi văn bản.
Mà là việc giảm công sức vô ích người đọc phải bỏ ra để nắm được ý.
Microsoft và Google thực sự nói gì
Tóm tắt các hướng dẫn chính thức lại, điểm chung hóa ra khá mộc mạc.
Microsoft thúc đẩy mạnh việc "chống lạc đường": đặt cái quan trọng lên trước, viết ngắn và rõ, văn bản dài thì thêm điều hướng, giữ cấu trúc nhất quán.[1] Về khả năng tiếp cận, cũng coi trọng câu ngắn có nghĩa và cấu trúc.[2] Với tài liệu toàn cầu, hãng nói câu ngắn gọn đơn giản và thuật ngữ nhất quán giúp dễ dịch hơn.[3]
Hướng dẫn của Google cho lập trình viên cũng khuyên viết rõ ràng, súc tích, không mơ hồ, giải thích trực tiếp và dùng thuật ngữ nhất quán.[5] Nhưng ở trên cùng của chính hướng dẫn ấy có ghi: hãy dùng phong cách riêng của dự án trước, và có thể lệch khỏi hướng dẫn nếu nội dung tốt hơn.[4]
Về phía tìm kiếm, Google quan tâm không phải việc văn bản trông có giống phong cách Google hay không, mà là thông tin gốc, phân tích gốc, giải thích đầy đủ, trải nghiệm trực tiếp, và nội dung giúp người đọc đạt được mục đích.[6] Chỉ dẫn năm 2026 cho tìm kiếm bằng AI tạo sinh cũng coi trọng góc nhìn riêng và "nội dung không phải những điều chung chung ai cũng làm được", chứ không phải việc hâm nóng lại thông tin sẵn có.[7]
Nghĩa là nếu nối tất cả tài liệu chính thức lại, ta được thế này:
Hãy viết dễ đọc. Hãy chính xác. Hãy giúp người đọc. Và đừng biến thành máy photocopy.
Một yêu cầu khá giống con người.
Đừng tự ý gọi những con số là "tiêu chuẩn của Google"
Điều đặc biệt nguy hiểm trong tự động hóa viết lách là nâng những con số mà hướng dẫn chính thức không hề nhắc tới lên thành thánh chỉ.
"Mỗi câu phải dưới 20 ký tự, đó là tiêu chuẩn Google." "Bài trên 2000 ký tự có lợi cho SEO." "Số tiêu đề phải đúng bằng bao nhiêu." "Tỷ lệ thuật ngữ chuyên môn phải dưới bao nhiêu phần trăm."
Những con số như vậy có thể dùng làm ngưỡng cảnh báo nội bộ. Nhưng nếu phía chính thức không nói, thì không được gọi là "Google bắt buộc" hay "Microsoft bắt buộc".
Thực tế, chỉ dẫn của Google Search về nội dung viết cho con người lại khuyên ta tự hỏi: mình có đang chỉnh bài cho khớp một số từ nào đó vì tưởng Google thích không? Chỉ dẫn này khẳng định rõ Google không có số từ cố định nào được ưa chuộng.[6]
Vì vậy, trong kiểm tra tự động, hãy chia phán định thành ba loại:
- Điều kiện bắt buộc chính thức: đặt thành bắt buộc, kèm căn cứ.
- Khuyến nghị chính thức: biến thành cảnh báo hoặc gợi ý cải thiện.
- Kinh nghiệm riêng của chúng ta: ghi rõ là quy tắc nội bộ, không mượn bảng hiệu chính thức.
Đừng mặc đồng phục Google cho "luật tự đặt của mình". Chỉ cần vậy thôi là lành mạnh hơn nhiều.
Thiết kế ba tầng để vừa dễ đọc vừa vui
Văn bản của bài viết sẽ dễ xử lý hơn khi chia thành ba tầng.
1. Bộ khung của ý nghĩa
Sự thật, kết luận, con số, ngày tháng, điều kiện, trích dẫn, nguồn, sự không chắc chắn.
Ở đây không được đùa. Trong bài hướng dẫn chơi game, sát thương là 3 thì không được viết thành 30 cho vui. Thế giới sụp đổ trước khi tiếng cười kịp đến.
2. Con đường dẫn đến sự hiểu
Tiêu đề, tóm tắt, thứ tự, đoạn văn, bảng, ví dụ cụ thể, giải thích thuật ngữ, liên kết nội bộ.
Ở đây ta đổ thật nhiều sự khôn ngoan của Microsoft và Google vào. Để người đọc không rơi vào cảnh "giờ mình đang ở đâu?" hay "tóm lại là gì?".
3. Giọng của bài viết
Ẩn dụ, trò đùa, những câu châm chọc, quan sát, nhịp điệu, cách nói, ví dụ ngộ nghĩnh.
Nếu cắt hết phần này, thông tin có thể đúng, nhưng không còn lý do gì phải đọc ở chính trang này.
Điều quan trọng là tầng 3 không được phá tầng 1.
Trò đùa dở thì che mất ý nghĩa. Trò đùa hay thì giúp nhớ ý nghĩa dễ hơn.
Ví dụ, chỉ nói "Quản lý ba mảnh là quan trọng" thì yếu.
Nhưng nếu nói "Chỉ có bộ nhớ thì là triết lý, chỉ có GitHub thì là hiến pháp, chỉ có lịch trình thì là người làm công. Ba thứ nối với nhau mới thành nhà máy", người ta nhớ luôn cả sự khác nhau về vai trò.
Trò đùa đang khuân hành lý hộ lời giải thích. Như vậy mới gọi là làm việc.
Với 12 ngôn ngữ, đừng dịch trò đùa, hãy dịch công việc của trò đùa
Thứ dễ hỏng nhất khi làm đa ngôn ngữ là tiếng cười, chứ không phải sự thật.
Câu tiếng Nhật "bài viết chuyển sang làm ở trung tâm hỗ trợ" có thể vẫn hiểu được khi dịch máy sang tiếng Anh. Nhưng chơi chữ, meme mạng, trò đùa theo đuôi câu và các tích văn hóa thì tỷ lệ tai nạn rất cao.
Hướng dẫn của Google về tài liệu kỹ thuật toàn cầu tránh các cách nói và sự hài hước phụ thuộc văn hóa chính là để giảm những tai nạn dịch thuật như vậy.[5]
Tuy nhiên, với bài viết thông thường, cách giải quyết không chỉ là "xóa tiếng cười khỏi mọi ngôn ngữ".
Hãy tách ý nghĩa ra khỏi vai trò của tiếng cười.
Nếu trò đùa trong bản tiếng Nhật có vai trò xả bớt căng thẳng của lời giải thích cứng nhắc, thì tiếng Anh dùng một câu bông đùa nhẹ tự nhiên trong tiếng Anh. Tiếng Hàn tạo nhịp ngắt tự nhiên kiểu tiếng Hàn. Tiếng Trung, Tây Ban Nha, Bồ Đào Nha, Indonesia, Thái, Việt, Pháp, Đức cũng vậy.
Thứ cố định: sự thật, con số, logic, nguồn, sự không chắc chắn.
Thứ được phép viết lại: trật tự từ, ẩn dụ, câu mở, ví von, trò đùa, nhịp của lời giải thích.
Mười hai ngôn ngữ không phải là việc "chuyển đổi tiếng Nhật 11 lần", mà gần với việc "viết cùng một bài báo 12 lần cho tử tế".
Không giống nhà máy dịch thuật, mà giống cuộc họp của 12 biên tập viên. Họp mà lại có ích. Hiếm đấy.
Đặt quy tắc ở ba nơi: bộ nhớ, bản gốc chuẩn và chỉ thị thực thi
Trong nhà máy bài viết tự động, đặt một quy tắc hay một lần rồi vẫn không được yên tâm.
Con người nói "cái hôm trước tôi nói đấy" là hiểu nhau. Quy trình tự động thì ở lần chạy sau sẽ thản nhiên làm như quên sạch.
Vì vậy ta chia thành ba nơi.
| Nơi | Vai trò | Nội dung đặt vào |
|---|---|---|
| Bộ nhớ | Ý đồ biên tập dài hạn | Vì sao có chính sách này, và không được phá điều gì |
| Bản gốc chuẩn (GitHub, v.v.) | Quy tắc chính thức chi tiết | Điều kiện phán định, ví dụ, phạm vi áp dụng, lịch sử cập nhật |
| Lịch trình và chỉ thị thực thi | Hành động mỗi lần | Đọc bản gốc chuẩn mới nhất trước khi chạy; không ưu tiên quy tắc cố định cũ |
Điểm quan trọng là không sao chép dán cùng một quy tắc dài vào cả ba nơi để rồi thành "ba bản gốc chuẩn".
Có ba bản gốc chuẩn thì tuần sau cả ba sẽ nói ba điều khác nhau. Đó không phải thuật phân thân, mà là nội chiến.
Bản gốc chuẩn của quy tắc chi tiết gom về một nơi. Bộ nhớ giữ ý đồ, lịch trình là bản cam kết thực thi "hãy đọc bản gốc chuẩn mới nhất".
Như vậy triết lý viết, đặc tả chính thức và mỗi lần thực thi được nối với nhau.
Kiểm tra tự động cũng phải xem "có xóa mất cá tính không"
Kiểm tra văn bản truyền thống xem lỗi chính tả, độ dài câu, tiêu đề, liên kết và nguồn.
Nếu chỉ vậy, sau một trăm vòng cải thiện chất lượng, tất cả bài viết có thể có cùng một khuôn mặt.
Vì thế hãy đưa cả những mục sau vào kiểm tra:
- Có nắm được kết luận ngay không?
- Chỉ nhìn các tiêu đề H2 có hiểu mạch bài không?
- Không biết thuật ngữ chuyên môn có hiểu được nghĩa không?
- Nguồn, con số và sự không chắc chắn có bị phá hỏng không?
- Quan sát, so sánh, phân tích và trải nghiệm gốc còn giữ lại không?
- Có cắt bỏ không cần thiết những trò đùa hiệu quả và sự ấm áp của bản gốc không?
- Bản sau khi sửa có thoái hóa thành "bản tóm tắt AI chỗ nào cũng có" không?
- Có dịch sát từng chữ cùng một trò đùa ở 12 ngôn ngữ rồi gây tai nạn không?
- Có giả mạo ngưỡng không có trong hướng dẫn chính thức thành "bắt buộc chính thức" không?
Chính sách thư rác của Google Search coi là vấn đề khi dùng AI tạo sinh, dịch thuật hay diễn đạt lại để làm hàng loạt trang mà hầu như không thêm giá trị cho người dùng.[8]
Nghĩa là "ngữ pháp đúng" chỉ là mức tối thiểu.
Phải xem sau khi sửa có làm mất luôn lý do để đọc hay không.
Ví dụ thất bại: điều robot cải thiện văn bản hay làm
Thất bại 1: Rút ngắn tất cả
Tách hết mọi câu dài, làm đứt luôn mạch liên kết ý nghĩa. Cách xử lý là không nhìn vào "độ ngắn", mà xem đọc một lần có thấy rõ quan hệ không.
Thất bại 2: Dùng cùng một cấu trúc câu cho tất cả
Cố định mọi đoạn theo cùng một thứ tự và cùng một nhịp. Cách xử lý là sắp xếp thứ tự thông tin cho gọn, nhưng đừng mặc đồng phục cho cả nhịp điệu.
Thất bại 3: Coi hài hước là nhiễu
Xóa hết ẩn dụ và những câu châm chọc. Cách xử lý là giữ những trò đùa giúp hiểu, chỉ cắt những đoạn lạc đề gây vướng.
Thất bại 4: Tưởng viết kiểu Google là SEO
Nhầm lẫn phong cách tài liệu cho lập trình viên với chất lượng tìm kiếm. Cách xử lý là coi hướng dẫn phong cách, chất lượng tìm kiếm, khả năng tiếp cận và bản địa hóa là các tầng riêng biệt.
Thất bại 5: Bịa ra con số
Gọi con số không có trong nguồn là "tiêu chuẩn Google". Cách xử lý là nếu đó là quy tắc kinh nghiệm nội bộ thì nói rõ như vậy.
Danh sách kiểm tra cuối cùng: làm bài dễ đọc hơn, nhưng đừng dừng giao hàng chất người
- Nắm được chủ đề và kết luận trong 5 giây.
- Nắm được bức tranh toàn cảnh trong 30 giây.
- Chỉ nhìn H2 cũng hiểu mạch bài.
- Hiểu được bằng lời lẽ bình thường.
- Tên chính thức, con số và nguồn chính xác.
- Văn bản dài cũng không bị lạc.
- Có giá trị riêng.
- Trò đùa giúp lời giải thích.
- Trò đùa không phá hỏng sự thật.
- Đã bản địa hóa "chức năng" của trò đùa trong 12 ngôn ngữ.
- Không trộn lẫn điều bắt buộc chính thức, khuyến nghị chính thức và quy tắc nội bộ.
- Dù đã sửa tự động, vẫn còn lý do để đọc ở trang này.
Hướng dẫn chính thức rất mạnh. Chính vì thế, đừng nuốt trọn.
Từ Microsoft, hãy mượn "thiết kế không làm người ta lạc đường". Từ hướng dẫn tài liệu của Google, hãy mượn "sự rõ ràng và thiết kế cho toàn cầu". Từ Google Search, hãy mượn "nội dung cho con người, giá trị gốc và sự tin cậy".
Còn giọng của trang thì hãy tự giữ lấy.
Nâng chất lượng bài viết không phải là mặc đồng phục cho nó. Mà là chỉ sửa sang những chỗ người đọc dễ lạc, và để yên những chỗ sự thú vị đang làm việc.
Lan can thì cần. Nhưng nếu biến cả con đường thành lan can thì không đi được nữa.
