Tóm tắt
- Báo cáo thí nghiệm cho thấy sau khi refactor cấu trúc mã (mẫu chiến lược·factory pattern, tách file, sắp xếp lại
.cursorrules) bằng một dòng prompt, rồi chạy cùng một prompt bổ sung tính năng, lượng token AI sử dụng đã giảm mạnh (Zero-context, N=5). Prompt và mã nguồn dùng trong thí nghiệm đều đã được công khai nên có thể tái hiện.
Dữ liệu cốt lõi
-
Claude-4 Sonnet: trung bình 390,159 → 242,265 tokens (−37.91%)
-
GPT-5: trung bình 315,839 → 233,634 tokens (−26.03%)
-
Tiêu chuẩn: Total Tokens do Cursor hiển thị. Việc so sánh giá trị tuyệt đối giữa các mô hình là không có ý nghĩa (khác biệt trong cách thống kê theo từng mô hình).
Thiết lập (tóm tắt)
-
IDE Cursor 1.6.6, mô hình GPT-5 / Claude-4 Sonnet
-
Tất cả prompt đều ở Zero-context, khởi động lại hoàn toàn trình soạn thảo sau mỗi vòng
-
Tiêu chí thành công: nếu triển khai được yêu cầu chỉ với một prompt duy nhất thì được tính là thành công
Vì sao điều này quan trọng
-
“Cấu trúc mã tốt” không chỉ giúp con người dễ đọc hơn mà còn có ảnh hưởng đến token, chi phí và thời gian của AI theo bằng chứng định lượng
-
Việc công khai prompt và repository giúp đảm bảo khả năng tái lập (có thể áp dụng ngay trong thực tế và cho các thí nghiệm tiếp theo)
Đánh giá cá nhân
- Với tư cách là người dùng Cursor, tôi cho rằng đây là một phương pháp rất tốt, cung cấp một cách tiếp cận cốt lõi để tiết kiệm chi phí.
- Bài viết cũng có đề cập, nhưng việc lấy mẫu chưa đủ nhiều vẫn là một điểm khá đáng tiếc.
34 bình luận
Chắc học ở lò luyện đặt tiêu đề rồi nhỉ..
Tôi đã xem thí nghiệm này rất thú vị.
Cảm ơn bạn.
Có lẽ cũng vì tiêu đề nói là một dòng prompt duy nhất nên điều người ta muốn xem và nội dung bài viết lại khác nhau, nên cảm giác đó càng rõ hơn.
Vâng, tôi cũng nghĩ vậy. T_T
Xin lỗi;;
Cảm ơn mọi người đã dành nhiều sự quan tâm cho bài viết này. Có lẽ vì mục đích phát hành ra nước ngoài khá lớn nên bài được viết bằng tiếng Anh, và do đó dường như đã phát sinh nhiều vấn đề khác nhau.
Vì vậy, tôi xin chia sẻ bài viết đã được sắp xếp lại bằng tiếng Hàn.
https://modgo.org/tokeun-sayongryang-37-91-reul-gamsosikin-dan-hanjuly…
Xin gửi phần tổng hợp bổ sung liên quan đến prompt đã được sử dụng.
Dù sao thì cách này cũng đặc biệt có lợi cho các lập trình viên khi viết prompt để cải thiện cấu trúc. Vì mỗi chương trình có đặc tính khác nhau, nên để tối ưu hiệu quả cải tiến ở mức cao sẽ cần một mức độ kiến thức phát triển phần mềm nhất định.
Tuy vậy, điều đó không có nghĩa là các vibe coder không phải lập trình viên không thể sử dụng phương pháp này. Dù hiệu quả có thể khác nhau, chỉ với những lệnh đơn giản như "Hãy dọn dẹp mã nguồn của dự án. Hãy xóa những đoạn mã không được sử dụng." thì AI cũng sẽ thực hiện việc phân tách và sắp xếp tệp cũng như class.
Tuy nhiên, vì sự khác biệt về mức độ chi tiết trong cải thiện cấu trúc có thể tạo ra chênh lệch về hiệu quả, nên cần cẩn trọng khi tham khảo tài liệu.
Vậy là trong prompt chỉ nên gắn những ý cốt lõi một cách logic. Tức là càng thêm đủ thứ vào prompt thì càng nhiều nhiễu, nên đoạn mã tạo ra cũng sẽ phức tạp hơn và có nhiều nhiễu hơn, có phải là vậy không?
Điểm cốt lõi là sau khi yêu cầu AI tái cấu trúc kiến trúc mã, lượng token tiêu thụ đã giảm xuống.
Ngược lại, cũng có thể giải thích rằng nếu tiếp tục đưa ra lệnh khi mã đang ở trạng thái có lỗi cấu trúc, mức sử dụng token sẽ tăng lên.
Tóm lại, nội dung muốn nói là cần có sự cải thiện về cấu trúc của mã nguồn, chứ không có nghĩa là prompt phải được viết ngắn gọn và logic chỉ với những ý cốt lõi.
Tôi cũng thấy phần giới thiệu này và bài gốc quá dài dòng, cảm giác như do một người viết không giỏi chắp bút nên khá khó đọc trong quá trình theo dõi.
Tóm lại, ý chính có thể gói gọn là
"hãy thêm một dòng chỉ thị chứa ràng buộc có cấu trúc để giảm số token"
ở mức như vậy.
Bài viết này mang tính chất gần với một nghiên cứu "thực nghiệm",
nên mọi số liệu có trong bài đều tập trung vào việc giúp tất cả những ai đọc bài này có thể "tái hiện" lại.
Vì vậy, tôi đã ghi lại toàn bộ mã nguồn gốc được sử dụng và mọi quy trình dùng trong thử nghiệm,
để cung cấp thông tin sao cho mọi người làm thí nghiệm đều có thể thu được cùng một kết quả.
Nhìn vào không khí trong phần bình luận thì tôi cảm nhận rằng,
về sau có lẽ tôi nên tách thành hai bài: một bài theo kiểu tóm tắt 3 dòng,
và một bài dành cho những người muốn biết chi tiết.
Nếu bạn cho tôi biết phần nào của bài viết này khiến bạn cảm thấy quá phức tạp hoặc quá dài dòng,
thì điều đó sẽ là sự giúp đỡ rất lớn cho việc viết các bài sau này của tôi.
Tôi cũng có cảm giác tương tự.
Tôi hiểu ý định của tác giả, nhưng so với những gì đã làm thì bài viết có vẻ phức tạp quá mức.
Có lẽ anh/chị muốn đưa tối đa các chi tiết dùng trong thí nghiệm vào bài nên mới viết như vậy,
nhưng nếu chỉ chắt lọc ngắn gọn phần cốt lõi thì những người quan tâm đến chủ đề này chắc cũng sẽ hiểu được.
Nếu mạnh dạn lược bớt chi tiết và chỉ tóm gọn ý chính thì có lẽ sẽ tốt hơn.
Cá nhân tôi thấy ý đồ và kết quả của tác giả khá thú vị.
Luận điểm chính dường như là mã nguồn tốt hơn sẽ dẫn đến mức tiêu thụ token ít hơn,
và có vẻ anh/chị đã thiết kế rồi thực hiện một thí nghiệm liên quan đến điều đó.
Nếu liệt kê theo phần tôi hiểu về thí nghiệm thì có vẻ là như sau:
Có lẽ là như vậy.
Và nếu cách hiểu của tôi là đúng, thì kết luận dường như là mã nguồn đã được tiền xử lý bằng prompt nhìn chung tiêu thụ ít token hơn.
Đây là một kết luận thú vị, nhưng ý kiến của tôi về thí nghiệm như sau.
Đây không phải là một phép so sánh công bằng
Nhìn về mặt số liệu thì có vẻ đã giảm, nhưng có lẽ nên so sánh bằng tổng số token dùng để xử lý mã nguồn mới đúng.
Nói cách khác, số token đã dùng cho bước tiền xử lý cũng nên được tính đến.
Nếu số token dùng để tiền xử lý quá lớn thì thực chất lại tiêu tốn nhiều token hơn và trở nên vô nghĩa; còn kể cả khi ít đi nữa thì chênh lệch mức tiêu thụ token thực tế có lẽ cũng sẽ nhỏ hơn đáng kể so với những gì bài viết thể hiện.
Cần so sánh mã nguồn trước và sau tiền xử lý
Nếu loại trừ token đã dùng cho tiền xử lý, thì lượng token tiêu thụ khi truy vấn có vẻ đã giảm một cách đáng kể.
Tuy nhiên, nếu phân tích được chính xác sự khác biệt nào trong mã nguồn đã tạo ra mức chênh lệch này, thì ý nghĩa của bài viết sẽ lớn hơn nhiều.
Vì điều đó cũng có nghĩa là có thể tối ưu prompt tiền xử lý để khuếch đại tối đa sự khác biệt đó.
Tác giả nói rằng việc refactor cấu trúc mã đã dẫn đến kết quả này, nhưng tôi không đồng ý và cho rằng hiện vẫn chưa thể biết chắc.
Bởi nếu yêu cầu AI cải thiện những phần khác ngoài refactor, thì cũng có thể vẫn làm giảm lượng token tiêu thụ.
Cần thêm các thí nghiệm đa dạng hơn
Tôi nghĩ nên chạy cùng một thí nghiệm này trên các codebase khác chứ không chỉ với đoạn mã hiện tại.
Vì cần phải đánh giá xem kết quả này có tốt một cách nhất quán hay không.
Tuy nhiên, tôi hiểu rằng trên thực tế việc kiểm thử như vậy có thể khó, nên có lẽ chỉ cần xem đây như một ý tham khảo là được.
Tôi hoàn toàn đồng ý. Tôi rất hoan nghênh những lời phê bình theo kiểu này.
Con người không sống một mình, và năng lực hay hoàn cảnh của mỗi cá nhân đều khác nhau.
Bản thân tôi cũng chỉ là một lập trình viên bình thường, và không thể tự bỏ chi phí cá nhân để thực hiện mọi bài kiểm thử.
Tôi hy vọng bài viết này sẽ trở thành hạt giống, tạo ảnh hưởng tích cực đến nhiều người và là điểm khởi đầu cho nhiều nghiên cứu tiếp theo.
Phụ đề có vẻ không thật sự khớp với nội dung. Nếu sắp xếp lại, thì phụ đề như “cần phân tích rõ hơn các yếu tố cụ thể gây ra việc giảm token” có vẻ phù hợp hơn.
Tôi đồng ý với khá nhiều điểm trong nội dung này. Tuy nhiên, tính chất của bài viết này cũng bao hàm yếu tố “đề xuất cách áp dụng thực tế cho những người đang đọc bài này”.
Chỉ cần nhìn vào các bình luận đã có dưới bài này cũng có thể cảm nhận được bầu không khí chung; và đây cũng là điều tôi mới biết gần đây, có vẻ trong số những người dùng AI có khá nhiều người không phải lập trình viên nhưng vẫn làm vibe coding.
Nếu tạo ra kết quả ấn tượng từ đoạn mã do chính tác giả trực tiếp tinh chỉnh mà không thông qua AI,
thì rất dễ bị nhìn nhận là tác giả đang khoe kỹ năng lập trình của mình và hạ thấp năng lực của AI.
Vì vậy, tôi đã chọn đề cập đến ví dụ mà bất kỳ ai cũng có thể tự cảm nhận kết quả thông qua yếu tố “prompt”, thứ mà các vibe coder nói chung đều có thể tận dụng.
Tiếp nối nghiên cứu này, tôi hy vọng sẽ có thêm những nghiên cứu phân tách chi tiết hơn các yếu tố ảnh hưởng đến mức sử dụng token của AI.
Nếu thông qua 1 lần chỉnh sửa cấu trúc mà mang lại hiệu quả giảm mức tiêu hao token của n lần prompt, thì lượng token giảm được sẽ được phản ánh xuyên suốt n lần thực hiện giống nhau đó.
n là chỉ số được quyết định bởi mục tiêu của dự án, số lượng chức năng, cũng như lượng và độ phức tạp của mã nguồn cần cho chúng,
và gần đây do các code agent của Cursor / Claude đang có các bản cập nhật theo hướng chia nhỏ đơn vị thực thi để giải quyết vấn đề lặp vô hạn hoặc việc AI sử dụng token bừa bãi,
Tôi cho rằng việc nghiên cứu riêng về chỉ số n liên quan đến độ phức tạp của dự án là đúng đắn.
Điểm không nên bỏ qua ở đây là việc cải thiện cấu trúc tuyệt đối không phải là hành vi diễn ra độc lập với quá trình phát triển mã.
Đó có thể là phần chịu ảnh hưởng như một base context thông qua prompt ban đầu, hoặc qua các ràng buộc như ruleset của AI (.cursorrules),
và trong suốt chu kỳ phát triển dự án, 1 lần cải thiện cấu trúc không thể giải quyết mọi thứ.
Nói cách khác, thay vì lên kế hoạch cải thiện mã theo chu kỳ cố định, việc định hướng cấu trúc đúng ngay từ base context là hướng tốt hơn.
Ngoài ra, tôi cho rằng việc nghiên cứu riêng trường hợp có và không có quy tắc chỉ thị định hướng cấu trúc như một base context là phù hợp hơn.
Tóm lại đối với mục 1,
cho nên lập luận rằng phải cộng thêm mức sử dụng token của 1 lệnh prompt cải thiện cấu trúc vào để tính toán là không thật sự chuẩn xác.
Tôi không hiểu rõ lắm ý anh/chị đang nói trong phần bình luận. Ý của tôi là nếu muốn so sánh công bằng hai phương pháp thì chẳng phải nên so sánh tổng số token tiêu thụ hay sao? Việc refactoring chẳng phải cũng tiêu tốn token sao?
Ngoài ra, những gì anh/chị trả lời dường như cũng không được viết trong bài, và có vẻ cũng là nội dung chưa được thực nghiệm. Có vẻ ý anh/chị là không nên so sánh token cho mỗi lần truy vấn, mà khi truy vấn nhiều lần thì overhead của refactoring sẽ giảm xuống, đồng thời số token kỳ vọng cho mỗi truy vấn cũng giảm nên tổng số token sẽ có lợi hơn. Nhưng điều đó có lẽ chỉ đúng khi chi phí giảm vẫn được duy trì qua nhiều lần truy vấn như anh/chị nghĩ, tức là đang giả định một tình huống rất lý tưởng. Không thể đảm bảo rằng mức giảm chi phí do refactoring sẽ được giữ nguyên bất kể số lượng truy vấn tiếp theo là bao nhiêu, và cũng không thể giả định như vậy nếu không có thực nghiệm. Nếu muốn bảo vệ ý định đó, có lẽ anh/chị nên cho thấy bằng thực nghiệm mức giảm chi phí với nhiều hơn 1 lần truy vấn. Nhưng chẳng phải thí nghiệm chỉ được thực hiện 1 lần rồi đem ra so sánh thôi sao?
Nói thêm, đây chỉ là giả định của riêng tôi, nhưng nếu cứ lặp lại truy vấn vô hạn lần để đạt cùng một mục tiêu (đầu ra cuối cùng lý tưởng), thì trong điều kiện lý tưởng, dù có refactoring hay không, mã nguồn cuối cùng có lẽ cũng phải hội tụ về cùng một dạng. (đầu ra cuối cùng lý tưởng là duy nhất)
Nếu giả định này là hợp lý, thì khi số lần truy vấn tăng lên, khác biệt giữa việc có và không có refactoring sẽ giảm đi, nên lợi ích cost down về token có vẻ cũng sẽ dần giảm theo. Vì vậy, xét ở góc độ vĩ mô, nếu lợi ích từ việc giảm chi phí này không duy trì đủ lâu, thì chênh lệch về tổng số token dùng cho các truy vấn có thể cũng không có ý nghĩa thống kê đáng kể, đúng không?
Và bạn cũng đã hỏi về nội dung liên quan đến thí nghiệm về số lần liên kết prompt.
Thực ra, theo chiều ngược lại thì đây là một yếu tố rất dễ để tác giả, nói nôm na, "làm trò".
Bản thân việc phát triển đã có rất nhiều lựa chọn về hướng triển khai, và nếu cứ tích lũy prompt theo hướng khiến mức sử dụng token tăng mạnh hơn, thì con số đó sẽ phình to ra như quả cầu tuyết.
Trong nghiên cứu có một triết lý gọi là 'Cumulative Science'.
Ít nhất theo tiêu chuẩn của tôi, tôi vẫn chưa từng tìm thấy một nghiên cứu nào về mức sử dụng token cho một lệnh đơn lẻ,
nên thay vì lập tức nghiên cứu N lần, tôi tập trung vào việc xử lý bài kiểm thử và kết luận thật chắc chắn cho 1 lần,
còn nghiên cứu N lần thì có thể được tiếp nối sau thí nghiệm này.
Ngoài ra, trong một bài viết khác, tôi cũng từng đề cập đến sự khác biệt trong cách AI hoạt động tùy theo sự khác nhau của codebase.
(Chủ đề này cũng từng được giới thiệu trên GeekNews: https://modgo.org/aineun-hyeonjae-kodeu-gujoyi-byeoge-maghyeoissda/)
Nói ngắn gọn, bài viết đó bàn về các bài kiểm thử và kết quả cho thấy chất lượng đầu ra thay đổi tùy theo codebase được đưa vào cho AI.
Điều này có nghĩa là, tùy vào chất lượng và định hướng của codebase ban đầu, chất lượng mã được viết tiếp theo có thể được duy trì, hoặc cũng có thể tiếp tục xấu đi.
Tức là chi phí refactoring ở giai đoạn đầu của dự án và chi phí refactoring của một dự án đã tiến triển rất xa có thể khác nhau rất lớn.
Nếu người đặt câu hỏi là một lập trình viên, có lẽ bạn đã từng nghe câu "tàu sân bay trên thuyền buồm" ít nhất một lần.
Refactoring là một chủ đề sâu sắc mà chi phí có thể thay đổi khổng lồ tùy vào việc nên thực hiện ở thời điểm nào, hoặc tùy theo tư tưởng và thiết kế được áp vào ngay từ giai đoạn đầu của dự án.
Thay vì đưa biến số đó vào để khiến kết luận trở nên thiếu ổn định,
thì ở đây người ta đã tiến hành một bài kiểm thử có thể giải thích chắc chắn ít nhất ở mức: "À, nếu chất lượng codebase tốt thì lượng token sử dụng sẽ giảm."
Xin phép giải thích lại.
Người thực hiện vibe coding có phổ rất rộng, từ người không phải lập trình viên đến lập trình viên giàu kinh nghiệm. Tùy theo mức độ kiến thức họ đang có, chất lượng đầu ra có thể khác biệt một trời một vực, hoàn toàn không liên quan đến nội dung bài viết này.
Ai đó có thể tự nhiên vận hành theo tiền đề dùng Cursor, đưa các quy ước OOP cơ bản và quy tắc tách class/method vào
.cursorrules, từ đó làm việc theo cách gần như không cần refactor thêm; nhưngtừ một ai khác, có thể đang xảy ra tình trạng sản sinh hàng loạt mã cấp thấp do thiếu khả năng nắm bắt những nội dung cốt lõi vốn quá cơ bản.
Thậm chí, trước đó đã có rất nhiều bài viết và trải nghiệm nhấn mạnh rằng về cơ bản cần duy trì chất lượng code tốt thông qua thiết lập rule cho project.
Điều này gợi ý khả năng rằng có những người đang hưởng lợi về mặt mức sử dụng token ngay cả khi không refactor một cách tường minh.
Tuy nhiên, các trường hợp trên không tổng hợp rõ ràng mức giảm sử dụng token theo từng đơn vị thực thi thông qua việc định nghĩa các rule đó. Vì vậy, bài viết này kiểm thử sự khác biệt về mức sử dụng token tùy theo chất lượng codebase và tổng hợp lại kết quả.
Nói cách khác, tùy theo người dùng, số lần refactor tường minh bản thân nó lại trở thành một biến số từ 0 đến n lần,
và có lẽ nên hiểu rằng ý định cốt lõi của bài viết này là giải thích cho câu hỏi: “Vì sao nên quan tâm đến một codebase có chất lượng tốt?”
Tôi là tác giả. Cảm ơn bạn đã phản hồi. Tôi sẽ tham khảo điều đó khi viết bài tiếp theo.
Có phải ý là khi thêm prompt này vào cùng thì chi phí đã giảm xuống đúng không? Tôi không chắc mình đã hiểu đúng ý chính hay chưa.
Nói thêm thì cấu trúc mã cần được cải tổ theo một mô hình phù hợp với chính dự án đó. Như nội dung trong câu trả lời bên dưới, nếu hỏi AI về việc cải tổ cấu trúc, nó sẽ chỉ ra cách cải tổ phù hợp với dự án tương ứng.
Cách tôi khuyến nghị là không đưa lệnh cải tổ cấu trúc cho AI ngay lập tức, mà hãy bảo nó thử đề xuất trước. Nó sẽ đưa ra phản hồi, và nếu bạn tiếp tục trao đổi cho đến khi đạt được một đề xuất đủ hiệu quả rồi mới yêu cầu áp dụng, thì luồng làm việc sẽ tốt hơn.
Một mẹo bổ sung là nên hoàn thành công việc trước khi xảy ra việc tóm tắt ngữ cảnh (khởi tạo lại bộ đệm ngữ cảnh) nếu có thể; còn nếu việc khởi tạo lại bộ đệm ngữ cảnh là không thể tránh khỏi, thì nên yêu cầu thêm trước các quy tắc cải thiện vào
.cursorrules. Nếu ngữ cảnh bị khởi tạo lại trong lúc đang làm việc, khả năng AI mắc lỗi sẽ cao hơn.Tham khảo thêm, việc kích thước mã nguồn đầu vào càng nhỏ thì lượng token tiêu thụ càng giảm là một sự thật hiển nhiên đã được biết đến rộng rãi. Đó cũng là lý do file
.cursorignoređược tạo ra.Nhìn chung, khi để AI cải thiện cấu trúc, trong hầu hết trường hợp lượng mã nguồn có xu hướng giảm xuống, nên nhận định rằng cứ cho nó dọn dẹp vì bất kỳ lý do gì thì chi phí cũng sẽ giảm có vẻ là một lập luận đáng tin.
Bài viết này bổ sung thêm luận điểm rằng có thể đạt được mức giảm token sử dụng thêm nữa thông qua việc dẫn dắt tới một cấu trúc tốt hơn.
Đúng vậy. Như cũng đã nêu trong bài viết, việc kích thước mã của dự án giảm sau khi cải thiện mã là sự thật.
Tuy nhiên, trong ví dụ này, mức giảm theo số lượng ký tự chỉ vào khoảng 10%, và chỉ riêng điều đó thì không thể giải thích được mức giảm 37,91% về lượng token sử dụng.
Trong bài viết có liên kết đến kho lưu trữ mã nguồn, và bất kỳ ai cũng có thể tái hiện để kiểm thử.
Tôi chưa trực tiếp thử nghiệm theo cách này,
nhưng tôi nghĩ prompt như sau cũng có thể hoạt động:
'Phân tích đoạn mã hiện tại và cải thiện cấu trúc theo hướng mà bạn dễ quản lý hơn.'
Ý chính chính xác là, tôi nghĩ điều này có nghĩa rằng khi làm việc với AI, không chỉ truyền đạt các yêu cầu về chức năng mà việc định hướng tốt một cấu trúc phù hợp và đúng đắn cũng có thể giúp giảm chi phí.
https://modgo.org/dib-rag-gaelreogtig-modeu-seuteurimeoreul-wihan-ciji…
Chế độ DeepRAGGalactic này là do bạn tự làm trực tiếp à?
Cái này cũng làm bằng vibe coding luôn sao?
Xin chào. Tôi là chủ blog.
Đúng là tôi đã tự làm chế độ Deep Rock Gal này, và hiện đang cung cấp dịch vụ thông qua máy chủ cá nhân. (Điều này cần thiết vì xác thực OAuth của Chzzk)
Việc phát triển chế độ này có bao gồm cả phát triển bằng Unreal Engine, nhưng đáng tiếc là phía Unreal Engine khá khó để làm vibe coding.
Thay vào đó, bản thân cách phát triển mod không quá khó, nên nếu bạn quan tâm thì có thể dễ dàng học qua hướng dẫn phát triển mod (https://modgo.org/dib-rag-gaelreogtig-modeu-gaebal-part-1/).
Tôi đã thấy bài viết anh đăng về chế độ đó ở cộng đồng khác, hóa ra đúng là bài do chính người tạo ra chế độ đó viết.
Tôi không ngờ anh còn viết cả bài hướng dẫn về chế độ Blueprint, cảm ơn anh.
Quả nhiên từ đầu anh đã là một người rất giỏi phát triển rồi!
À, thì ra bạn đã từng thấy chế độ của tôi ở cộng đồng khác rồi.
Những bài tôi đã viết còn nhiều chỗ thiếu sót, nhưng nếu có thể giúp ích thì tôi rất vui.
Thật bực mình
Nếu bạn cho tôi biết phần nào đã khiến bạn khó chịu, tôi sẽ trả lời một cách thân thiện.
Vui lòng xem mục bình luận trong Hướng dẫn sử dụng trang web.
Xin hãy trao đổi một cách thân thiện và nhã nhặn.
Nếu có ý kiến phản biện, vui lòng chỉ viết nội dung đó