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?
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.
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.
Vibe coding không hoàn thiện đầu ra chỉ với 1 prompt.
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.
Để giúp mọi người dễ hiểu nhất có thể, tôi đã lấy ví dụ về việc cải thiện mã từ đoạn code do AI viết mà có vấn đề về cấu trúc, trong trường hợp không có chỉ thị riêng.
Đ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,
Khi có quy tắc chỉ thị định hướng cấu trúc như một base context, tổng mức sử dụng token cũng có khả năng giảm, và
vì tồn tại biến số là việc thu được đầu ra cuối cùng thông qua n lần lệnh prompt,
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 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:
Chuẩn bị 2 phiên bản: mã nguồn để truy vấn cho AI, và mã nguồn đã được tiền xử lý bằng prompt (?) từ chính mã nguồn đó
Chạy lần lượt hai mã nguồn này trên GPT5 và Sonnet, mỗi bên 5 lần, rồi so sánh lượng token tiêu thụ
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.
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.
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.
Đ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.
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?
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ản thân Web Codecs API đã có hiệu năng rất tốt, nên hầu hết các thư viện media trên web đều cho hiệu suất vượt trội. Vì vậy nếu gọi đây là TypeScript thuần thì cũng hơi khó nói.
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?
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 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 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.
Quà tặng vô dụng đang khá được ưa chuộng... có vẻ sẽ hay để khám phá thêm những món quà vô dụng mới.
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.
Nếu bạn cần tận dụng thông tin không gian, thì đây là một lựa chọn tốt.
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…
Đ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.
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?
Chồng chéo không cần thiế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.
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.
Đột nhiên tất cả dấu chấm đều biến mất.
Kết luận
Dùng AI có thể giúp cắt giảm chi phí nhờ nâng cao năng suất,
nhưng bản thân nó không tự tạo ra tiền.
Mấy thứ như nodejs khi muốn bind vào ứng dụng khác thì khá là phiền phức, giá mà làm được dễ hơn một chút thì tốt.
Bản thân Web Codecs API đã có hiệu năng rất tốt, nên hầu hết các thư viện media trên web đều cho hiệu suất vượt trội. Vì vậy nếu gọi đây là TypeScript thuần thì cũng hơi khó nói.
Nhìn benchmark thì khá thú vị là hiệu năng không tệ.