Có vẻ như cứ hễ có gì đang thành chủ đề là người này lại lần nào cũng sản xuất hàng loạt theo kiểu đặt tên open*, nên cảm nhận về họ không được tốt lắm..
Đây chỉ là một suy nghĩ ngắn, nhưng dạo này tôi hay nghĩ như thế này. Nghe nói ngày trước các chuyên gia Assembly khi nhìn các lập trình viên C đã từng nói những câu như “không biết quý bộ nhớ”, “không hiểu phần cứng”, v.v., và bây giờ nhìn lại thì tôi thấy chẳng phải cũng là những lời chỉ trích tương tự trong cùng một mạch hay sao. Rốt cuộc, từ góc độ phát triển phần mềm, chẳng phải chúng ta chỉ đang chuyển sang phát triển bằng một ngôn ngữ trừu tượng hơn (AI) so với các ngôn ngữ lập trình trước đây hay sao. Vì vậy, việc mức độ chuyên môn đối với các ngôn ngữ đã dùng trước đó đương nhiên giảm đi cũng là điều tự nhiên. Tuy vậy, giống như cho đến cách đây không lâu, trong số những người làm phát triển, những ai xử lý các ngôn ngữ low-level hơn hiện tại thường được gọi là “quái vật”, thì có lẽ từ nay những người phát triển theo vibe nhưng vẫn hiểu nguyên lý của các ngôn ngữ cũ vẫn có thể được xem là những người khác biệt.
Vì những lý do như ở mục 2, khi sử dụng hầu hết các LLM tôi luôn kèm thêm chỉ thị yêu cầu chúng đóng vai "kẻ phản biện", và thấy điều đó khá hữu ích theo cách riêng của nó.
Về mặt ý tưởng thì khá thú vị, nhưng vẫn có phần nghi ngờ liệu trên thực tế nó có vận hành trơn tru hay không. Như cũng đã được nhắc trong các ý kiến trên HN, thị trường hai phía (two-sided market) là bài toán lớn vì phải thành công trong việc thu hút khách hàng ban đầu ở cả hai phía.
Ở đây cũng thấy xuất hiện ký tự tiếng Hindi. Gần đây, bất kể là OpenAI, Claude hay Google, việc đầu ra tiếng Hàn bị trộn lẫn tiếng Hindi xảy ra khá thường xuyên; liệu có phải bộ dữ liệu tiếng Hàn được người Ấn Độ gán nhãn không?
Tôi vốn không thích các mô hình Trung Quốc vì phản hồi tiếng Hàn hay bị lẫn tiếng Trung, nhưng dạo gần đây các frontier model lại cứ trộn tiếng Hindi vào, thành ra cảm giác bài xích với mô hình Trung Quốc còn giảm đi.
Đây có vẻ sẽ là một bài viết tham khảo rất tốt. Nếu phần chính của bài viết là cách tiếp cận khóa van của “token đầu vào”,
thì tôi lại thường gặp nhiều trường hợp vấn đề nằm ở chỗ “chính những thứ đã được đăng ký” ngày càng nhiều lên, nên đã thử làm một công cụ tên là claude-slim.
Đây là một CLI quét, phân loại và sắp xếp các tình huống như: trong 60 skill thì có đến một nửa chưa từng được dùng lần nào, hoặc CLAUDE.md bị phình to do plugin. Token counting dựa trên js-tiktoken,
không xóa hẳn mà chuyển sang skills.disabled/ nên có thể restore bất cứ lúc nào.
Nhờ lịch trình khớp nối dày đặc nên việc chuyển tuyến rất thoải mái -> phiên bản hy vọng
Không có cửa chắn ke ga nên vào giờ đi làm, đi học thỉnh thoảng có người lao xuống tự tử, và vì các lý do như mất điện, hỏng hóc nên việc chậm tàu xảy ra khá thường xuyên -> phiên bản tuyệt vọng
Tôi đã sống ở Nhật được 1 năm, và những lúc tôi cảm thấy đường sắt Nhật Bản tốt chiếm khoảng 53%, còn khoảng 47% thì chỉ toàn bực bội. Đặc biệt, tuyến Hibiya có mùi nấm mốc từ điều hòa quanh năm, nên nếu đi tàu mà không đeo khẩu trang thì có cảm giác như sẽ bị viêm phổi.
Đồng cảm. Dữ liệu cốt lõi của các miền chuyên sâu như hàng không vũ trụ, y tế, điều khiển chính xác... được đặt trong mạng nội bộ đóng kín nghiêm ngặt; muốn tiếp cận thì либо phải là người nội bộ then chốt, còn nếu là bên ngoài thì cũng chỉ có thể được mở ra sau khi bỏ ra chi phí đáng kể và ký NDA. Phần lớn dữ liệu mà AI học là những thứ được công khai trên Internet, và nếu là dịch vụ web/app dựa trên Python, JavaScript thì Full Automation ở mức độ nào đó là khả thi.
Còn các thuật toán đồ họa 3D, CAD được dùng trong những miền chuyên sâu thì либо chỉ nằm rải rác manh mún trên Internet, либо hoàn toàn không có, nên ngay cả AI cũng chỉ có thể tạo ra kết quả hời hợt nếu dùng vibe coding. Tôi nghĩ cách tiếp cận an toàn và thực tế là đặt một tác tử chính, liên tục bơm ngữ cảnh miền ở mức micro-managing, rồi phát triển theo phương thức khuếch đại liên tục chứ không phải tự động hóa hoàn toàn do AI tự chủ, với chu trình Planning → Redirection → Review do chính lập trình viên trực tiếp dẫn dắt.
Nhìn mấy lập trình viên code kiểu vibe mà không dùng não là thấy bực thật sự. Sản phẩm do chính mình làm ra có chất lượng tệ hại mà thử lấy lý do là AI viết xem. Người phải chịu trách nhiệm vẫn là bản thân mình.
À đúng thật. Nhìn danh sách repo thì thấy còn thêm vài dự án nữa bắt đầu bằng Open..
Thậm chí còn chưa từng được công bố, vậy thì làm sao có thể đảo ngược để phân tích được chứ...??
Có vẻ như cứ hễ có gì đang thành chủ đề là người này lại lần nào cũng sản xuất hàng loạt theo kiểu đặt tên
open*, nên cảm nhận về họ không được tốt lắm..Tôi thấy mỗi khi dùng Claude thì tiếng Nhật hay xuất hiện. Hôm qua cũng vậy.
Cảm giác như đã đến một thế giới phản địa đàng vậy.
Từ sau Notion AI thì đúng là... mình cũng chẳng còn biết nó là ứng dụng gì nữa rồi.
Không ngờ còn có cả chuyện thế này.
Đây chỉ là một suy nghĩ ngắn, nhưng dạo này tôi hay nghĩ như thế này. Nghe nói ngày trước các chuyên gia Assembly khi nhìn các lập trình viên C đã từng nói những câu như “không biết quý bộ nhớ”, “không hiểu phần cứng”, v.v., và bây giờ nhìn lại thì tôi thấy chẳng phải cũng là những lời chỉ trích tương tự trong cùng một mạch hay sao. Rốt cuộc, từ góc độ phát triển phần mềm, chẳng phải chúng ta chỉ đang chuyển sang phát triển bằng một ngôn ngữ trừu tượng hơn (AI) so với các ngôn ngữ lập trình trước đây hay sao. Vì vậy, việc mức độ chuyên môn đối với các ngôn ngữ đã dùng trước đó đương nhiên giảm đi cũng là điều tự nhiên. Tuy vậy, giống như cho đến cách đây không lâu, trong số những người làm phát triển, những ai xử lý các ngôn ngữ low-level hơn hiện tại thường được gọi là “quái vật”, thì có lẽ từ nay những người phát triển theo vibe nhưng vẫn hiểu nguyên lý của các ngôn ngữ cũ vẫn có thể được xem là những người khác biệt.
Không biết có phải chỉ là cảm giác của tôi không, nhưng dường như ở đây cũng có khá nhiều bình luận được AI viết nhỉ
Vì những lý do như ở mục 2, khi sử dụng hầu hết các LLM tôi luôn kèm thêm chỉ thị yêu cầu chúng đóng vai "kẻ phản biện", và thấy điều đó khá hữu ích theo cách riêng của nó.
Về mặt ý tưởng thì khá thú vị, nhưng vẫn có phần nghi ngờ liệu trên thực tế nó có vận hành trơn tru hay không. Như cũng đã được nhắc trong các ý kiến trên HN, thị trường hai phía (two-sided market) là bài toán lớn vì phải thành công trong việc thu hút khách hàng ban đầu ở cả hai phía.
Có vẻ như đây là bài báo của chính bạn phải không?
Ở đây cũng thấy xuất hiện ký tự tiếng Hindi. Gần đây, bất kể là OpenAI, Claude hay Google, việc đầu ra tiếng Hàn bị trộn lẫn tiếng Hindi xảy ra khá thường xuyên; liệu có phải bộ dữ liệu tiếng Hàn được người Ấn Độ gán nhãn không?
Tôi vốn không thích các mô hình Trung Quốc vì phản hồi tiếng Hàn hay bị lẫn tiếng Trung, nhưng dạo gần đây các frontier model lại cứ trộn tiếng Hindi vào, thành ra cảm giác bài xích với mô hình Trung Quốc còn giảm đi.
Ồ, cảm ơn vì đã chia sẻ!
Đây có vẻ sẽ là một bài viết tham khảo rất tốt. Nếu phần chính của bài viết là cách tiếp cận khóa van của “token đầu vào”,
thì tôi lại thường gặp nhiều trường hợp vấn đề nằm ở chỗ “chính những thứ đã được đăng ký” ngày càng nhiều lên, nên đã thử làm một công cụ tên là claude-slim.
Đây là một CLI quét, phân loại và sắp xếp các tình huống như: trong 60 skill thì có đến một nửa chưa từng được dùng lần nào, hoặc CLAUDE.md bị phình to do plugin. Token counting dựa trên js-tiktoken,
không xóa hẳn mà chuyển sang
skills.disabled/nên có thể restore bất cứ lúc nào.https://github.com/iops-leo/claude-slim
Hướng đi này bổ sung chính xác cho các thiết lập trong bài viết, nên có vẻ sẽ rất tốt nếu dùng song song.
Nhờ lịch trình khớp nối dày đặc nên việc chuyển tuyến rất thoải mái -> phiên bản hy vọng
Không có cửa chắn ke ga nên vào giờ đi làm, đi học thỉnh thoảng có người lao xuống tự tử, và vì các lý do như mất điện, hỏng hóc nên việc chậm tàu xảy ra khá thường xuyên -> phiên bản tuyệt vọng
Tôi đã sống ở Nhật được 1 năm, và những lúc tôi cảm thấy đường sắt Nhật Bản tốt chiếm khoảng 53%, còn khoảng 47% thì chỉ toàn bực bội. Đặc biệt, tuyến Hibiya có mùi nấm mốc từ điều hòa quanh năm, nên nếu đi tàu mà không đeo khẩu trang thì có cảm giác như sẽ bị viêm phổi.
Dùng thử rồi thì thấy khả năng nhận diện phác thảo trên khăn giấy thật đáng kinh ngạc. Giờ thì thậm chí cũng không cần chat nữa.
Ngược lại, sau khi dùng AI Agent thì tôi lại chuyển sang
nvim. Xem source bằngnvimthoải mái hơn nhiều...Đồng cảm. Dữ liệu cốt lõi của các miền chuyên sâu như hàng không vũ trụ, y tế, điều khiển chính xác... được đặt trong mạng nội bộ đóng kín nghiêm ngặt; muốn tiếp cận thì либо phải là người nội bộ then chốt, còn nếu là bên ngoài thì cũng chỉ có thể được mở ra sau khi bỏ ra chi phí đáng kể và ký NDA. Phần lớn dữ liệu mà AI học là những thứ được công khai trên Internet, và nếu là dịch vụ web/app dựa trên Python, JavaScript thì Full Automation ở mức độ nào đó là khả thi.
Còn các thuật toán đồ họa 3D, CAD được dùng trong những miền chuyên sâu thì либо chỉ nằm rải rác manh mún trên Internet, либо hoàn toàn không có, nên ngay cả AI cũng chỉ có thể tạo ra kết quả hời hợt nếu dùng vibe coding. Tôi nghĩ cách tiếp cận an toàn và thực tế là đặt một tác tử chính, liên tục bơm ngữ cảnh miền ở mức micro-managing, rồi phát triển theo phương thức khuếch đại liên tục chứ không phải tự động hóa hoàn toàn do AI tự chủ, với chu trình Planning → Redirection → Review do chính lập trình viên trực tiếp dẫn dắt.
Nhìn mấy lập trình viên code kiểu vibe mà không dùng não là thấy bực thật sự. Sản phẩm do chính mình làm ra có chất lượng tệ hại mà thử lấy lý do là AI viết xem. Người phải chịu trách nhiệm vẫn là bản thân mình.
Giữa bò đen và bò vàng, con nào làm việc giỏi hơn?
Con bò hay bị mắng làm việc giỏi hơn.