Tôi không dùng nhiều vì đã thay Cmd+K của vscode bằng Cmd+R, nhưng thấy mọi người liên tục chia sẻ trải nghiệm năng suất tăng vọt nên giờ cũng đang phân vân có nên chuyển sang không.
Trong cuốn The Phoenix Project, từng được nhắc đến nhiều lần trên GeekNews, cũng có câu chuyện tương tự. Rằng khi tiến gần tới mức 100% công suất, thời gian phản hồi sẽ tăng theo cấp số nhân.
Tôi hoàn toàn đồng ý với những gì bài viết này nêu ra, đồng thời cũng đồng ý với vấn đề mà bạn đã nói đến.
Thực tế đây cũng là điểm mà tôi đang suy nghĩ.
Tuy có khác nhau ở từng squad, nhưng nếu tích cực để các thành viên trong nhóm tham gia vào sprint planning thì vấn đề bạn nói đến đã không xảy ra. Trong khi chia sẻ bối cảnh của dự án và tình hình thay đổi qua từng sprint để mọi người có thể nhận thức đầy đủ về những công việc thay đổi, tôi cũng yêu cầu thử chia nhỏ công việc một cách rất chi tiết.
Đúng như bạn nói, xét ở góc độ quản lý như theo dõi tiến độ, đo tốc độ làm việc, ứng phó với tình huống ngoài dự kiến, và chi phí cơ hội khi nội dung công việc không diễn ra như mong muốn, thì cuối cùng vẫn thấy rằng phải chia nhỏ ra thì công việc mới tiến triển tốt.
Là người làm trong lĩnh vực sinh học, tôi muốn chia sẻ ngắn gọn kết quả sau khi sử dụng.
Chế độ Research được cung cấp với 2 loại.
Quick summary
Thời gian xử lý khoảng 5~6 phút (theo chuẩn 4070 ti super, 16GB, Mistral và Gemma 3:12b)
Có hiện tượng ảo giác nên tự tạo Reference, nhưng các Ref có gắn link trong tài liệu có vẻ có nguồn gốc rõ ràng.
Có xu hướng trả lời câu hỏi với trọng tâm là công nghệ mới. Đặc biệt hay cố liên hệ với AI.
Detailed Report
Thời gian xử lý khoảng 1 giờ (4070 ti super 16GB, Gemma 3:12b)
Gần như tạo ra một bài review paper hoàn chỉnh. Tuy nhiên có vấn đề là số lượng Reference giảm mạnh. Dù nội dung có thể đúng thì vẫn khó đưa ra căn cứ, nên cần cải thiện thêm một chút. (Có vẻ như nó thực hiện quá trình lặp lại để nâng chất lượng bài viết, nhưng trong quá trình đó các Ref link bị mất đi.)
Tuy vậy, rõ ràng là nội dung được cung cấp có chất lượng cao hơn Quick summary.
Có thể thiết lập nhiều tùy chọn khác nhau trong file Config. Có thể giới hạn cơ sở dữ liệu tìm kiếm chỉ còn PubMed để nâng chất lượng tài liệu lên thêm một mức. Cũng có thể cấu hình số lượng văn bản tìm kiếm mỗi lần hoặc sẽ tạo bao nhiêu chunk khi dùng RAG.
Xét đến việc hiện tại mới là 0.01V, thật đáng kinh ngạc khi một máy Local có thể tạo ra báo cáo đến mức này. Đặc biệt trong lĩnh vực khoa học sự sống, các chatbot thường dùng cách diễn đạt mang tính khái quát, nhưng báo cáo được tạo bởi chương trình này lại dùng lối diễn đạt rất khoa học.
Chương trình này hiện chưa hỗ trợ tiếng Hàn. Dù đặt câu hỏi bằng tiếng Hàn thì báo cáo vẫn được xuất ra bằng tiếng Anh.
Ngoài ra, khi nhận câu trả lời dưới dạng file PDF thông qua tính năng xuất PDF, có vấn đề là tiếng Hàn không hiển thị.
Nếu giải quyết được vấn đề Ref biến mất trong lúc tạo báo cáo và vấn đề gây ra ảo giác, thì tôi nghĩ đây sẽ là một công cụ thực sự mạnh mẽ.
Nếu bỏ hỗ trợ biểu thức chính quy mà cũng chỉ nhanh hơn ripgrep khoảng 2 lần thì độ hữu dụng đúng là hơi thấp.
Có lẽ tôi sẽ cứ tiếp tục dùng ripgrep vì nó hỗ trợ biểu thức chính quy.
Cá nhân tôi thấy có những trường hợp ts có kiểu dữ liệu trở nên cực kỳ phức tạp... đến mức gần như bỏ cuộc (cứ dùng luôn any), chắc là vì tôi chưa hiểu đủ về ngôn ngữ này nhỉ? Tùy tình huống mà tôi thật sự tốn khá nhiều thời gian chỉ để xóa mấy gạch đỏ.
Mình cũng cố gắng giữ 80% khối lượng công việc và chừa 20% khoảng trống, nhưng lúc nào cũng băn khoăn không biết nên lấy tiêu chí nào.. Có khi lại nghĩ hay là tính đơn giản theo thời gian nhỉ.
Khi từng sống tạm ở Thượng Hải khoảng một năm, tôi đã có dịp sang Hàng Châu chơi (lúc đó là để xem kiểu một buổi biểu diễn ấn tượng nào đó), và tôi đã nghĩ đây thật sự là một nơi rất đáng sống vì thành phố sạch sẽ, phong cảnh Tây Hồ cũng rất đẹp. Giờ xem ra nơi này còn trở thành một chỗ tốt để làm doanh nghiệp nữa.
Tôi không dùng nhiều vì đã thay
Cmd+Kcủa vscode bằngCmd+R, nhưng thấy mọi người liên tục chia sẻ trải nghiệm năng suất tăng vọt nên giờ cũng đang phân vân có nên chuyển sang không.Trong cuốn The Phoenix Project, từng được nhắc đến nhiều lần trên GeekNews, cũng có câu chuyện tương tự. Rằng khi tiến gần tới mức 100% công suất, thời gian phản hồi sẽ tăng theo cấp số nhân.
Tôi hoàn toàn đồng ý với những gì bài viết này nêu ra, đồng thời cũng đồng ý với vấn đề mà bạn đã nói đến.
Thực tế đây cũng là điểm mà tôi đang suy nghĩ.
Tuy có khác nhau ở từng squad, nhưng nếu tích cực để các thành viên trong nhóm tham gia vào sprint planning thì vấn đề bạn nói đến đã không xảy ra. Trong khi chia sẻ bối cảnh của dự án và tình hình thay đổi qua từng sprint để mọi người có thể nhận thức đầy đủ về những công việc thay đổi, tôi cũng yêu cầu thử chia nhỏ công việc một cách rất chi tiết.
Đúng như bạn nói, xét ở góc độ quản lý như theo dõi tiến độ, đo tốc độ làm việc, ứng phó với tình huống ngoài dự kiến, và chi phí cơ hội khi nội dung công việc không diễn ra như mong muốn, thì cuối cùng vẫn thấy rằng phải chia nhỏ ra thì công việc mới tiến triển tốt.
Không hiểu nổi. Ngay cả trình độ coding của học sinh tiểu học còn chưa tới chứ đừng nói đến mức học thuật, vậy mà sao lại đem ra chia sẻ...
công nghệ mới. Đặc biệt hay cố liên hệ với AI.Có thể thiết lập nhiều tùy chọn khác nhau trong file Config. Có thể giới hạn cơ sở dữ liệu tìm kiếm chỉ còn PubMed để nâng chất lượng tài liệu lên thêm một mức. Cũng có thể cấu hình số lượng văn bản tìm kiếm mỗi lần hoặc sẽ tạo bao nhiêu chunk khi dùng RAG.
Xét đến việc hiện tại mới là 0.01V, thật đáng kinh ngạc khi một máy Local có thể tạo ra báo cáo đến mức này. Đặc biệt trong lĩnh vực khoa học sự sống, các chatbot thường dùng
cách diễn đạt mang tính khái quát, nhưng báo cáo được tạo bởi chương trình này lại dùng lối diễn đạt rất khoa học.Chương trình này hiện chưa hỗ trợ tiếng Hàn. Dù đặt câu hỏi bằng tiếng Hàn thì báo cáo vẫn được xuất ra bằng tiếng Anh.
Ngoài ra, khi nhận câu trả lời dưới dạng file PDF thông qua tính năng xuất PDF, có vấn đề là tiếng Hàn không hiển thị.
Nếu giải quyết được vấn đề Ref biến mất trong lúc tạo báo cáo và vấn đề gây ra ảo giác, thì tôi nghĩ đây sẽ là một công cụ thực sự mạnh mẽ.
kkkkkk
Tôi thấy mệt mỏi vì quá nhiều plugin của Obsidian
nên đã chuyển sang Reflect, và cực kỳ hài lòng.
Từ lúc nào đó tôi đã bắt đầu ít đụng đến TS hơn, nhưng thấy tin như thế này lại thấy khá hứng thú nhỉ?
Vì thế nên tôi hẳn luôn dành riêng chiều thứ Sáu làm thời gian phát triển cá nhân!
Tôi thực sự rất đồng cảm với bình luận này. Đã có nguy cơ xảy ra việc micromanage đối với các khía cạnh kỹ thuật. Thật sự không hề dễ dàng.
Nếu bỏ hỗ trợ biểu thức chính quy mà cũng chỉ nhanh hơn ripgrep khoảng 2 lần thì độ hữu dụng đúng là hơi thấp.
Có lẽ tôi sẽ cứ tiếp tục dùng ripgrep vì nó hỗ trợ biểu thức chính quy.
GOAT.. ghê thật
Trung Quốc đang bứt phá ghê thật.
Cá nhân tôi thấy có những trường hợp
tscó kiểu dữ liệu trở nên cực kỳ phức tạp... đến mức gần như bỏ cuộc (cứ dùng luônany), chắc là vì tôi chưa hiểu đủ về ngôn ngữ này nhỉ? Tùy tình huống mà tôi thật sự tốn khá nhiều thời gian chỉ để xóa mấy gạch đỏ.Mình cũng cố gắng giữ 80% khối lượng công việc và chừa 20% khoảng trống, nhưng lúc nào cũng băn khoăn không biết nên lấy tiêu chí nào.. Có khi lại nghĩ hay là tính đơn giản theo thời gian nhỉ.
Khi từng sống tạm ở Thượng Hải khoảng một năm, tôi đã có dịp sang Hàng Châu chơi (lúc đó là để xem kiểu một buổi biểu diễn ấn tượng nào đó), và tôi đã nghĩ đây thật sự là một nơi rất đáng sống vì thành phố sạch sẽ, phong cảnh Tây Hồ cũng rất đẹp. Giờ xem ra nơi này còn trở thành một chỗ tốt để làm doanh nghiệp nữa.
Không có nội dung nào về hiệu năng tiếng Hàn, nhưng khi thử trích xuất thì có vẻ cũng không tệ.
Nếu có tính năng né tránh chống macro thì có vẻ sẽ trở thành người chiến thắng của thị trường.
Có vẻ tranh luận đang khá nóng nên chính Anders Hejlsberg đã để lại bình luận trực tiếp.
https://github.com/microsoft/typescript-go/…
Vâng, đúng là cái đó!