Link bài viết gốc： https://mp.weixin.qq.com/s/FmDtiR0Lnhk54...
Kim Tiên Sinh là người Triều Tiên à · Tài khoản WeChat · Lão Kim cùng bạn vọc AI · 2026-10-16 20:22
Bài viết này được chia sẻ lại, bản quyền thuộc về tác giả gốc, toàn văn căn cứ theo link bài gốc
Đây là một bài hướng dẫn kỹ thuật nhập môn. Trong bài sẽ xuất hiện một số thuật ngữ kỹ thuật; bản thân Lão Kim cũng không phải dân kỹ thuật chuyên nghiệp, nên tôi hiểu rằng khi mới bắt đầu đọc những nội dung này, bạn khó tránh khỏi cảm giác hơi xa lạ.
Nhưng tiếp xúc nhiều rồi, dần dần hiểu rõ một thuật ngữ có nghĩa là gì, giải quyết được vấn đề nào, thì khi sử dụng AI, bạn sẽ dễ dàng mô tả yêu cầu một cách cụ thể hơn. Đôi khi, biết thêm một phương pháp, bạn sẽ nhận ra hóa ra việc này cũng có thể nhờ AI hỗ trợ, và dùng AI cũng sẽ thuận tay hơn.
Vì vậy, hy vọng bạn có thể kiên nhẫn đọc hết, không cần phải nhớ mọi thứ ngay trong một lần đọc. Hôm nay chúng ta hãy bắt đầu từ thuật ngữ Git, để xem khi chúng ta để AI liên tục sửa code, Git có thể giúp ích được gì.
Git dùng để làm gì, tại sao viết code lại cần dùng đến nó?
Giả sử bạn và đồng nghiệp cùng chỉnh sửa một trang web. Trong cùng một tệp, bạn sửa tiêu đề trang, còn đồng nghiệp sửa nút đăng nhập. Cả hai người đều lưu lại một bản, vậy cuối cùng nên dùng bản của ai? Nếu trực tiếp lấy bản này ghi đè lên bản kia, những chỉnh sửa của người còn lại có thể sẽ bị mất.
Git chính là công cụ dùng để quản lý những thay đổi kiểu này. Bạn có thể giao một loạt thay đổi cho Git lưu lại thành một phiên bản có thể tra cứu về sau, thao tác này gọi là commit. Git sẽ ghi lại lần commit này đã sửa những đâu, so sánh sự khác biệt giữa hai phiên bản, đồng thời giúp bạn gộp các thay đổi của hai người lại với nhau. Nếu cả hai cùng sửa vào một vị trí và không thể tự động merge, Git sẽ đánh dấu xung đột (conflict) để con người tự xử lý. Nếu phát hiện lần sửa đổi này bị lỗi, bạn cũng có thể xem lại các phiên bản trước đó để hoàn tác thay đổi tương ứng.
Tất cả những công việc này được gọi chung là Kiểm soát phiên bản , còn nơi chứa các tệp dự án và lịch sử sửa đổi được gọi là Kho lưu trữ mã nguồn . Nó không chịu trách nhiệm đánh giá xem nút đăng nhập dùng có tốt hay không, việc đó phải dựa vào các bước kiểm tra và test riêng biệt.
Git và GitHub cũng không phải là cùng một thứ. Git là công cụ version control, còn GitHub là trang web lưu trữ các Git repository và hỗ trợ làm việc nhóm. Không cần dùng GitHub, bạn vẫn có thể sử dụng Git.
Đối với một dự án, sau khi mỗi người và mỗi AI viết xong phần code của mình, vẫn cần phải tổng hợp các thay đổi phù hợp vào phiên bản chung của toàn đội ngũ, bước này gọi là merge.
AI viết code nhanh hơn, nhưng khâu phía sau lại ngày càng quá tải
Anthropic, công ty đứng sau Claude, mỗi ngày đều phải xử lý khối lượng lớn các lượt merge như vậy. Chỉ có điều, AI viết code ngày càng nhanh, khiến các khâu lưu trữ, phân phối và kiểm tra code bắt đầu không theo kịp.
Code được viết ra mới chỉ là bước khởi đầu để tạo nên một phần mềm. Gần đây, họ đã dành 5 tháng cùng 7 người để xây dựng lại một bộ công cụ nội bộ, thay thế hệ thống Git quản lý code nội bộ, nhằm giải quyết vấn đề: sau khi viết code xong, mọi người còn đang phải chờ đợi điều gì.
Tháng 5 năm nay, mỗi ngày Anthropic phải merge khoảng 2.500 lượt thay đổi code vào repository, đến tháng 9, con số này đã vượt quá 30.000. Ở đây chúng ta đang nói về số lượt thay đổi code, chứ không phải số dòng code , và một lần thay đổi có thể tác động đến nhiều tệp.
Trong biểu đồ thống kê chính thức, hai màu sắc đại diện cho hai quy trình review thay đổi mà họ lần lượt sử dụng, đường màu đen là trung bình 7 ngày. Tính đến ngày 9 tháng 9, số lượt merge trong một ngày đã đạt 30.401 lần.
Nhưng viết xong code không có nghĩa là trang web hay phần mềm có thể sử dụng được ngay. Các tác vụ tự động hóa trước tiên phải lấy được bản code cần kiểm tra, sau đó build thành chương trình có thể chạy được, rồi chạy test để xem có làm hỏng các tính năng cũ hay không. Toàn bộ quy trình tự động build và test này thường được gọi là CI.
Claude viết code ngày càng 'khủng', nhưng thời gian chờ tải code, chờ build, chờ test lại không hề biến mất. Khâu testing cũng bắt đầu không theo kịp: một lượt test còn chưa chạy xong thì hàng trăm, thậm chí hàng nghìn thay đổi mới có thể đã được merge vào repository. Ngay cả khi bài test vượt qua, điều đó cũng chỉ chứng minh phiên bản được đem đi test đó đạt chuẩn, chứ không thể đảm bảo cho những dòng code được bổ sung vào sau.
Khi tốc độ viết nhanh hơn, sự chờ đợi vốn không mấy ai để ý trước đây nay bắt đầu trở nên đắt đỏ.
Anthropic gom nhiều dự án vào một repository lớn duy nhất để quản lý tập trung, cách làm này gọi là monorepo. Nhánh chính (main branch) của repo này — tức nhánh chủ đạo để cả đội ngũ tổng hợp các thay đổi — có lịch sử dung lượng gần 100 GB, và một bản copy code phục vụ cho tác vụ sau khi nén lại vẫn vượt quá 25 GB.
Repository quá lớn khiến mỗi lần kéo code về đều rất tốn công sức, nhưng phiền toái hơn cả là việc phải kéo đi kéo lại nhiều lần. Quy trình build và test tự động của họ mỗi ngày phải chuẩn bị mã nguồn khoảng 25 triệu lần, đó là còn chưa tính đến các bản sao do lập trình viên, tác vụ AI và tác vụ nghiên cứu sử dụng.
Một tác vụ phải chờ thêm vài phút tưởng chừng không có gì to tát, nhưng khi một thao tác tương tự lặp lại hàng chục triệu lần mỗi ngày, nó sẽ ngốn một lượng tài nguyên máy móc khổng lồ — mà lượng tài nguyên này thậm chí còn chưa hề được dùng để test code hay làm nghiên cứu, mà chỉ mới tiêu tốn cho việc chuẩn bị bắt đầu làm việc.
Họ không vội xóa bỏ Git ngay từ đầu, mà tìm cách tải về ít hơn trước: ví dụ như chỉ lấy lịch sử gần nhất, chỉ tải các thư mục cần thiết, đồng thời triển khai thêm nhiều bản sao repo để mọi tác vụ truy cập, các bản sao này gọi là mirror. Họ cũng lưu trước trạng thái của repo tại một thời điểm nhất định, tức là snapshot, để các tác vụ mới không phải chuẩn bị lại từ đầu mỗi lần chạy.
Trong sơ đồ kiến trúc cũ bên dưới, một nhánh xử lý việc đồng bộ mirror theo các thay đổi mới nhất, nhánh còn lại chịu trách nhiệm tạo snapshot để cung cấp cho các tác vụ tiếp theo sử dụng. Vào giờ cao điểm, Anthropic từng vận hành tới hàng trăm Git mirror.
Những giải pháp này quả thực đã giúp kéo dài thời gian, nhưng các thay đổi được merge ngày càng dồn dập khiến snapshot vừa tạo xong đã lập tức bị lỗi thời, các mirror cũng phải liên tục đồng bộ. Việc tải ít dữ liệu đi lại khiến các thao tác như tra cứu lịch sử hay kiểm tra xem ai đã sửa dòng nào trở nên khó duy trì hơn.
Vì thế, họ bắt đầu cân nhắc: liệu có thể thay đổi cách phân công công việc để mỗi tác vụ bớt phải làm những bước chuẩn bị lặp đi lặp lại hay không?
Chuyển sang Scion: Cụ thể đã cắt giảm được những gì?
Anthropic đã phát triển nên Scion, một hệ thống version control chuyên biệt phục vụ codebase nội bộ quy mô lớn . Hệ thống này thay thế Git để quản lý ai đã sửa những gì, các thay đổi được merge ra sao và cách tra cứu lại những bản ghi này trong tương lai. Họ cũng xây dựng công cụ Antique đi kèm để các kỹ sư xem và review thay đổi, kết hợp cùng các hệ thống tìm kiếm code, quản lý phân quyền... 7 kỹ sư đã hoàn thành toàn bộ quá trình phát triển và di chuyển hệ thống chỉ trong vòng 5 tháng.
Git có một ưu điểm rất lớn: sau khi lấy đủ dữ liệu tương ứng, lập trình viên dù mất mạng vẫn có thể tra cứu lịch sử, so sánh phiên bản và lưu các thay đổi ngay trên máy tính của mình. Tuy nhiên, phần lớn đối tượng sử dụng tại Anthropic lại là AI và các tác vụ tự động hóa luôn online; khi làm việc chúng vốn dĩ không thể rời xa server, và sau khi sửa xong cũng phải tổng hợp lại vào phiên bản dùng chung của cả đội ngũ.
Vì vậy, Scion chuyển nhiều phần việc hơn lên server, chẳng hạn như tra cứu lịch sử, lưu phiên bản mới và merge code; máy chạy tác vụ chỉ giữ lại những dữ liệu cần dùng, cần thư mục nào mới lấy thư mục đó, cần tệp nào mới lấy tệp đó .
Một số tác vụ thậm chí không cần tải tệp về. Chẳng hạn, một tác vụ kiểm tra tự động chỉ muốn biết hai phiên bản khác nhau ở điểm nào thì chỉ cần trực tiếp truy vấn server là đủ, không cần phải chuẩn bị sẵn một repo ở local chỉ để trả lời câu hỏi đó.
Khi lưu lại một lượt thay đổi, Scion cũng quản lý tách biệt giữa danh sách các tệp bị sửa đổi và nội dung chi tiết của tệp. Nhờ đó, chi phí tài nguyên để tạo bản ghi thay đổi này chủ yếu phụ thuộc vào việc lần này đã sửa bao nhiêu, chứ không phụ thuộc vào độ lớn của toàn bộ repository.
Bản ghi này gọi là changeset, bên trong ghi nhận ai đã sửa gì và trỏ tới nội dung tệp được lưu trữ riêng biệt. Cấu trúc thư mục sẽ do server suy luận độc lập, không cần phải nhồi nhét mọi chi tiết vào cùng một bản ghi.
Những tác vụ thực sự cần đến tệp sẽ ưu tiên lấy từ nguồn gần nhất. Tệp đã dùng có thể được lưu tạm để lần sau tái sử dụng trực tiếp, điều này gọi là cache. Scion sẽ tìm trong cache trên cùng một máy trước, nếu không có mới tìm đến cache cùng khu vực, nếu vẫn không có thì mới gửi yêu cầu tới server lưu trữ dữ liệu gốc.
Trong sơ đồ kiến trúc chính thức bên dưới, scion-daemon và scion-cache chính là hai tầng cache này, các mũi tên màu cam thể hiện yêu cầu được gửi tới tầng nào. Khi nhiều tác vụ cần dùng chung một tệp, hệ thống sẽ không phải yêu cầu server thượng nguồn (upstream) cung cấp lại từ đầu mỗi lần.
Họ cũng giới hạn phương thức truy cập giữa các tầng để tránh trường hợp khi một khu vực gặp sự cố, tất cả các request sẽ ồ ạt đổ dồn về upstream làm tê liệt cả các khu vực khác.
Theo dữ liệu nội bộ được Anthropic công bố, tài nguyên CPU và bộ nhớ mà hạ tầng Scion yêu cầu đã giảm xuống chỉ còn khoảng 1/200 so với hạ tầng Git mirror trước đây, và hệ thống tự động build & test cũng nhờ đó mà giải phóng được 25% công suất CPU.
Điều này không có nghĩa là cứ đổi công cụ thì máy tính sẽ chạy nhanh hơn 200 lần. Thứ họ tiết kiệm được chính là chi phí hạ tầng trong các repository khổng lồ với vô số tác vụ lặp đi lặp lại. Đối với các tác vụ AI, một thay đổi trực quan rõ rệt là thời gian trung vị để chuẩn bị thư mục làm việc mã nguồn độc lập cho một tác vụ mới đã giảm từ 7,1 phút xuống còn 5,1 giây.
Claude không hề thông minh hơn nhờ việc đổi hệ thống version control, mà đơn giản là cuối cùng nó cũng không còn phải chờ đợi lâu đến thế nữa.
Claude phụ trách viết code, vậy các kỹ sư cần làm gì?
Bản thân Scion cũng được xây dựng bằng chính Claude; model vừa tạo ra áp lực mới, nhưng đồng thời cũng giúp đội ngũ giải quyết được bài toán hóc búa.
Thống kê dưới đây là về quá trình phát triển của chính hai hệ thống Scion và Antique, từ tháng 1 đến tháng 9 đã merge lũy kế 12.257 lượt thay đổi. Phạm vi thống kê này khác với con số hơn 30.000 lượt mỗi ngày của toàn bộ repository ở phần đầu, nó phản ánh khối lượng thay đổi trong quá trình phát triển hai bộ công cụ này.
Đầu năm, đội ngũ từng tự tay viết một phiên bản chương trình để import dữ liệu từ Git sang Scion. Sau đó, khi có được phiên bản nội bộ sớm Claude Mythos Preview, họ đã để model viết lại toàn bộ. Kết quả chính thức được công bố là mức tiêu thụ bộ nhớ giảm xuống còn 1/20, tốc độ nhanh gấp 4 lần, đồng thời vẫn bảo đảm chuẩn xác các yêu cầu về thứ tự import cũng như cấu trúc dữ liệu.
Nhưng model viết code tốt không đồng nghĩa với việc lúc nào nó cũng chọn đúng giải pháp. Trong quá trình migration, có một tác vụ cần tra cứu xem một lượt thay đổi nhất định được merge vào main branch vào thời điểm nào, và agent đã chọn cách tra từng dòng một từ commit log.
Viết theo cách này chưa chắc đã không ra kết quả, nhưng bản ghi càng nhiều thì tra cứu càng chậm. Đội ngũ vốn đã có sẵn công cụ code review, chỉ cần truy vấn trực tiếp công cụ đó là xong, không việc gì phải lật lại toàn bộ lịch sử. Các kỹ sư phải ngăn chặn cách làm này, không thể chỉ vì code chạy được mà chấp nhận một hướng đi không phù hợp.
Một lần khác, agent chịu trách nhiệm bắt lỗi lại nghi ngờ quá mức về độ tin cậy của một service nội bộ khác, khiến Claude thêm vào hàng loạt bước xác thực dư thừa. Nhìn riêng từng vị trí thì có vẻ như đang bổ sung lớp bảo vệ, nhưng đặt trong tổng thể cả hệ thống thì lại gia tăng độ phức tạp không cần thiết, khiến người bảo trì sau này phải tốn thêm nhiều thời gian.
Vì vậy, 7 kỹ sư này vẫn review từng yêu cầu thay đổi của hệ thống, nhưng họ tập trung nhiều hơn vào ý đồ thay đổi thay vì đọc từng dòng code: tại sao vấn đề này lại giải quyết theo cách đó, có giải pháp nào sẵn có không, và liệu nó có phá vỡ các điều kiện tiên quyết mà những tính năng khác đang phụ thuộc hay không.
AI có thể triển khai một cách làm rất hoàn chỉnh, nhưng bản thân nó chưa chắc đã biết rằng cách làm đó ngay từ đầu vốn không nên được chọn.
Trong bảng so sánh thời gian mà phía chính thức công bố, tổng thời gian trung vị cho mỗi yêu cầu thay đổi tiêu tốn vào việc version control đã giảm từ 34 phút xuống còn 3,7 phút. Tuy nhiên mức độ thay đổi ở từng thao tác là không giống nhau: có thao tác chỉ nhanh hơn một chút, có thao tác lại tiết kiệm được vài phút; việc tối ưu cái gì cần phải dựa vào việc tác vụ thực tế đang ngốn thời gian ở đâu.
Repository xử lý nhanh hơn rồi, nhưng bài toán testing vẫn còn đó. Nếu vì chờ một vòng kiểm tra hoàn tất mà khóa toàn bộ repo lại, không cho các thay đổi mới merge vào, thì với số lượng lớn như vậy sẽ rất khó duy trì. Anthropic không thể tiếp tục áp dụng hiệu quả cơ chế khóa toàn cục này, do đó họ đã tăng cường đầu tư vào testing tự động sau khi merge và trước khi đưa lên production.
Code được merge vào vẫn có thể xung đột lẫn nhau; họ tin rằng Claude có thể xử lý các xung đột này rất nhanh, nhưng điều đó không đồng nghĩa với việc có thể cắt bớt khâu test. Khi nào kiểm tra, phát hiện lỗi thì ngăn chặn triển khai lên production như thế nào, làm sao để rollback về phiên bản trước... tất cả vẫn cần phải được sắp xếp chặt chẽ.
Người bình thường dùng AI làm dự án: Đâu là phần cần học hỏi?
Bản thân Anthropic cũng nói rất rõ ràng: Scion không phù hợp để làm phương án thay thế Git phổ thông . Đối với đại đa số repository, thiết kế của Git vẫn hoàn toàn phù hợp. Trường hợp họ gặp phải là tình huống đặc thù: một monorepo siêu lớn kết hợp với lượng lớn AI liên tục viết code không ngừng nghỉ.
Đây cũng không phải việc chỉ cần tải một công cụ về hay gõ một câu lệnh khác là xong; quy trình code review, tìm kiếm, test tự động đều phải thay đổi theo. Anthropic chia sẻ kinh nghiệm kỹ thuật thực tế của chính họ, chứ không phải mang đến một sản phẩm đại trà để các đội ngũ thông thường có thể áp dụng thay thế Git ngay lập tức.
Khi sử dụng Claude trong nội bộ, mức sử dụng model mà họ sẵn sàng chi trả cũng vượt xa hầu hết các công ty khác, bởi vì họ còn đồng thời kiểm thử năng lực của model. Do đó, con số 7 người và 5 tháng không thể dùng để ước tính chi phí nếu chúng ta muốn làm điều tương tự.
Đối với những người dùng AI để xây dựng website hay công cụ nhỏ, điều hữu ích hơn cả là phân biệt rõ hai việc: Khoảng cách giữa việc 'AI đã viết xong code' và 'tính năng này đã có thể yên tâm đưa vào sử dụng' vẫn còn cả một chặng đường công việc ở giữa.
Chẳng hạn khi nhờ AI thêm tính năng đăng nhập vào trang web, không thể chỉ nhìn thấy trên giao diện xuất hiện thêm một cái nút là xong, mà còn phải kiểm tra các trường hợp đăng nhập bình thường, nhập sai mật khẩu, đăng xuất rồi mở lại... Ví dụ này không đòi hỏi một hệ thống đồ sộ như Scion, nhưng bạn vẫn cần lưu lại lịch sử thay đổi để biết lần này đã sửa những gì, và nếu xảy ra sự cố thì có thể rollback quay trở lại.
Nếu thời gian chủ yếu bị tiêu tốn vào việc giải thích đi giải thích lại yêu cầu hay sửa các lỗi phát hiện qua kiểm thử, hãy ưu tiên giải quyết những vấn đề đó trước. Nếu bạn luôn gặp tình trạng nhiều bản code sửa qua sửa lại mà không phân biệt nổi bản nào mới chuẩn, hãy bắt đầu áp dụng version control. Chừng nào repository chưa khiến bạn phải chờ đợi quá lâu, thì không việc gì phải đập đi xây lại toàn bộ quy trình chỉ để chạy theo kiến trúc của người khác.
Điều cần thay đổi là mắt xích đang làm chậm công việc của chính bạn, chứ không phải công cụ mà người khác vừa mới đổi.
Lời kết
Lần này Anthropic đã làm nên Scion, nhưng những phương án bị các kỹ sư chặn lại trong bài viết gốc cũng rất đáng để ghi nhớ.
Dù là tra cứu từng mục trong commit log hay thêm từng lớp kiểm tra xác thực, Claude đều có thể viết ra rất nhanh, rồi bổ sung test, khiến ngay cả những phương án không phù hợp cũng mang dáng dấp của một sản phẩm hoàn thiện.
Khi một hướng đi đòi hỏi nhiều nhân lực, đội ngũ thường phải thảo luận trước xem có đáng làm hay không. Giờ đây việc triển khai đã rẻ hơn rất nhiều, bước thảo luận này lại dễ bị bỏ qua; nhưng đợi đến khi code đã viết xong xuôi, người ta lại dễ cảm thấy đã làm nhiều đến thế rồi, xóa bỏ toàn bộ thì quá tiếc.
Vì vậy, kỹ sư vẫn cần phải biết nói "không" với một phần code đã được viết xong, ngay cả khi nó trông có vẻ hoàn chỉnh, thậm chí đã chạy thông suốt.
Khi việc viết code ngày càng trở nên dễ dàng, việc xóa bỏ một đoạn code vốn dĩ không nên tồn tại có lẽ sẽ trở thành một quyết định khó khăn hơn.
Học tương tác với AI (NotebookLM)
Ngoài đọc , bạn có thể nghe , xem và xem hoạ thông tin ở đầu bài. Bài này còn có bộ công cụ tương tác do AI tạo: Bài kiểm tra trắc nghiệm, Thẻ ghi nhớ, Sơ đồ tư duy, Bản trình bày và Báo cáo chuyên sâu.
Mở không gian học tương tác