shakespeares 2025-10-19 | bình luận cha | trong: Phát hành Bun 1.3 (bun.sh)

Chắc hẳn phải có lý do Vite không gộp vào, nên mình cũng tò mò không biết trải nghiệm sử dụng Bun trong thực tế thế nào.

 

Có lẽ đây cũng là phần có thể được áp dụng khi dùng Claude Code cho việc lập trình. Hiện tại tôi cũng đang đưa hướng dẫn vào Claude.md và tách riêng các hướng dẫn chi tiết để triển khai.

 

Ồ, cảm ơn vì phần giải thích cốt lõi.

 

Thực tế là... dù có biết điều đó thì vẫn còn rất nhiều thứ vượt xa hơn thế..

 

Có vẻ như để thực hiện nhiều tác vụ với ít token, thay vì tối ưu hóa prompt thì có thể giải quyết khá đơn giản bằng cách tận dụng multi-agent và tóm tắt. Tôi đồng ý với vấn đề được nêu ra, nhưng cảm thấy cách giải quyết này cũng có những giới hạn nhất định.

 

Việc xử lý ngữ cảnh và Claude Skills có liên quan gì với nhau nhỉ? Ban đầu tôi đã nghĩ rằng: nó khác gì so với các custom command của Claude Code trước đây? Nhưng khi đọc tài liệu thì tôi cảm thấy điểm khác biệt lớn nhất có lẽ là việc có thể đưa cả mã script như Python hay JavaScript vào trong một skill và thực thi nó.

 

Có vẻ là không phải toàn bộ SKILLS.md đều được đưa vào context, mà lúc đầu luôn chỉ có phần tên và mô tả như bên dưới được đưa vào trước.


name: skill-creator
description: Hướng dẫn để tạo các skill hiệu quả. Skill này nên được dùng khi người dùng muốn tạo một skill mới (hoặc cập nhật skill hiện có) nhằm mở rộng khả năng của Claude bằng kiến thức chuyên biệt, quy trình làm việc hoặc tích hợp công cụ.
license: Complete terms in LICENSE.txt

 

Dù sao thì cuối cùng có vẻ họ cũng đã làm được một việc tốt.

 

Có vẻ như họ đang chủ trương triết lý phần mềm tự do ở mức quá cực đoan, trong khi vẫn dùng Internet qua dây đồng do các nhà cung cấp kéo sẵn, hoặc lấy đĩa vệ tinh làm cái gọi là giải pháp thay thế.
Có lẽ dù tất cả những điều viết ở đây đều thành hiện thực, họ vẫn sẽ kết luận rằng mã nguồn mở chưa giành chiến thắng.

 

Đúng là Livewire khá thú vị, nhưng chỉ cần UI hơi phức tạp một chút là nó sẽ thành địa ngục. Từ thời điểm đó, Phoenix cũng mất hẳn lợi thế của mình. Chu kỳ càng kéo dài thì càng vất vả, nên cá nhân tôi không mấy khuyến nghị nó.

 

Skills cũng dùng token phải không? Nếu vậy thì có vẻ vấn đề về mức sử dụng token sẽ lại phát sinh, nhưng đến lúc đó thì tôi không rõ sẽ ứng phó thế nào.

 

Trước đây tôi cũng gần như là một tín đồ serverless và áp dụng kiến trúc serverless khắp nơi, nhưng dạo này tôi lại thích cấu trúc gồm một ec2 và một rds hơn. Rồi sau đó dần dần tách từng thứ cần thiết ra. Việc đưa serverless vào giờ khiến tôi phải cân nhắc rất nhiều.
Có nhiều lý do, nhưng chỉ cần trong team có một người không có kiến thức về serverless thôi là chi phí giao tiếp/bảo trì đã tăng lên đáng kể. Và khi quay lại vận hành server, tôi lại một lần nữa cảm nhận rằng serverless không hề rẻ như mình nghĩ, cũng không tiện như mình tưởng.

 

Khi làm việc với Claude Code, tôi cứ phải liên tục nhét các chỉ dẫn hay quy định vào context, rồi cuối cùng lại phải cân nhắc giữa lượng token sử dụng và context. Sau đó tôi nghĩ ra cách tạo thư mục, viết chi tiết vào đó bằng các file md theo từng chức năng, còn trong claude.md thì chỉ nhét thật nhiều pointer kiểu muốn làm gì thì xem cái nào; cách này hoạt động khá tốt mà chi phí cũng rẻ. Skills về bản chất chắc là tập hợp những thứ như vậy, nên có vẻ sẽ khá hữu ích.

 

MSA, OneDrive, Copilot vân vân... Mong họ ngừng việc ép buộc nhét những thứ đó vào miệng người dùng.

 

Mong là đừng hiểu lầm, tôi không nói Hacker News là vớ vẩn đâu.

 

Không cần dài dòng tào lao, cốt lõi có vẻ rốt cuộc vẫn chỉ là bài toán làm sao xử lý context cho hiệu quả.

 

Kỹ thuật xét cho cùng luôn là cuộc chiến về chi phí
Ban đầu thì dùng để rút ngắn thời gian tạo prototype hoặc xây dựng business
Về sau phải tối ưu hóa để giảm chi phí
Bản thân kiểu bài viết này đã chứng minh người viết không hiểu gì về kỹ thuật
Kiểu như vậy vậy