Chia sẻ đam mê công nghệ
Thiết lập

Dùng Claude Code viết script thiết lập Windows: nên bắt đầu từ WinGet

Claude Code có thể giúp gom ứng dụng và tùy chỉnh Windows vào script PowerShell, nhưng nên tách phần cài app khỏi sửa Registry để dễ kiểm tra trước khi chạy.

Màn hình hiển thị biểu trưng Claude bên cạnh máy tính để bàn
Claude Code phù hợp để hỗ trợ tra cứu và soạn script, còn danh sách thay đổi cần do người dùng quyết định. Ảnh: XDA Developers.

Tóm tắt nhanh

  • Claude Code có thể hỗ trợ viết script PowerShell để cài ứng dụng và thiết lập lại Windows theo danh sách yêu cầu.
  • Nên bắt đầu bằng phần cài ứng dụng qua WinGet, kiểm tra đúng mã gói rồi mới thêm các thay đổi hệ thống.
  • Không chạy hàng loạt lệnh sửa Registry chỉ vì AI đã giải thích chúng; cần đối chiếu tài liệu và thử trong môi trường tách biệt.
  • Mốc 20 phút được XDA nêu là kết quả cá nhân, không phải cam kết cho mọi cấu hình hay đường truyền.

Cài lại Windows thường kéo theo một lượt tải ứng dụng, chỉnh File Explorer và tìm lại những thiết lập đã quen dùng. Một script PowerShell có thể gom các thao tác lặp lại ấy vào một nơi, còn Claude Code giúp giảm công tra mã gói và tìm lệnh. Phần cần giữ trong tay người dùng là quyết định thay đổi nào được phép chạy trên máy.

Với máy dùng để học tập hoặc làm việc hằng ngày, cách hợp lý hơn là làm một script cài ứng dụng trước, để các tùy chỉnh Registry và gỡ tính năng sang phần riêng. Khi gặp lỗi, người dùng sẽ dễ biết nguyên nhân nằm ở bộ cài phần mềm hay ở thay đổi của Windows, thay vì phải gỡ rối một script làm quá nhiều việc cùng lúc.

Bắt đầu bằng danh sách ứng dụng, đừng giao AI toàn quyền dọn Windows

Một yêu cầu cụ thể sẽ dễ kiểm tra hơn câu lệnh chung chung như tối ưu Windows. Hãy liệt kê những ứng dụng thật sự cần, yêu cầu Claude Code tìm đúng mã WinGet, nêu nguồn cho từng lựa chọn và chỉ tạo tệp script để đọc lại. Không cần cho công cụ chạy lệnh cài đặt ngay trong lượt soạn mã.

Chẳng hạn, có thể giao việc theo nội dung: “Viết script PowerShell cài Notepad++, 7-Zip, VLC và Brave qua WinGet. Chia riêng từng ứng dụng, giải thích các tham số, ghi lại kết quả cài đặt và không sửa Registry hay gỡ tính năng Windows. Chỉ tạo tệp để tôi kiểm tra, không thực thi.” Đây là cách giới hạn phạm vi công việc, không phải bảo đảm rằng mã AI tạo ra đã an toàn.

Giá trị đáng dùng ở AI nằm ở khâu gom những việc tra cứu vụn vặt. Viết một vòng lặp không khó, nhưng kiểm tra tên gói, chọn tham số và giữ danh sách ứng dụng có thể dùng lại mới là phần dễ bị trì hoãn. Dù vậy, mã gói đúng không đồng nghĩa mọi quyết định cài đặt đều phù hợp với máy của bạn.

Kiểm tra gói trước khi cho chạy hàng loạt

Tài liệu Microsoft Learn hướng dẫn dùng winget search để tìm ứng dụng và winget show để xem thông tin ứng dụng cùng bộ cài được chọn cho hệ thống. Trước khi chạy script, hãy đối chiếu mã gói và thông tin bộ cài của từng ứng dụng, thay vì chỉ đọc tên thân thiện mà AI ghi trong phần chú thích.

Trong ví dụ được XDA công bố, lệnh cài ứng dụng có cấu trúc sau:

winget install -e --id Notepad++.Notepad++ --silent --accept-package-agreements --accept-source-agreements

Theo Microsoft Learn, --id giới hạn tìm kiếm theo mã ứng dụng, còn -e yêu cầu khớp chính xác, có phân biệt chữ hoa và chữ thường. Cách ghép này tránh việc chọn theo một phần tên, nhưng không thay thế bước kiểm tra nguồn gói. Nếu nhiều nguồn có mục trùng nhau, Microsoft hướng dẫn chỉ rõ nguồn bằng tham số --source để phân biệt.

Cần hiểu cả những gì lệnh đang đồng ý thay mình. --silent chạy bộ cài ở chế độ không hiện giao diện; --accept-package-agreements chấp nhận thỏa thuận của gói ứng dụng, còn --accept-source-agreements chấp nhận thỏa thuận của kho phần mềm. Microsoft lưu ý việc chấp nhận thỏa thuận gói không điều khiển các thành phần tùy chọn hoặc phần mềm đi kèm do bộ cài đề nghị. Vì vậy, bớt hộp thoại không có nghĩa là đã kiểm soát toàn bộ hành vi của bộ cài.

Yêu cầu script báo rõ phần đã làm và phần bị lỗi

Script nên ghi kết quả theo từng ứng dụng và cho biết bước nào chưa hoàn tất. Một cửa sổ PowerShell đã chạy tới dòng cuối chưa đủ để kết luận toàn bộ ứng dụng đều được cài thành công, nhất là khi danh sách dài hoặc có bộ cài cần xử lý riêng.

Cũng nên yêu cầu AI giải thích hành vi khi chạy lại: ứng dụng đã có sẽ được bỏ qua, nâng cấp hay gọi bộ cài thêm lần nữa? Microsoft có tham số --no-upgrade để bỏ qua nâng cấp nếu đã tồn tại phiên bản cài đặt. Đừng mặc định một vòng lặp WinGet bất kỳ đều có tính chất chạy lại an toàn chỉ vì phần mô tả của AI nói vậy.

Tách sửa Registry và WSL thành phần tùy chọn, thử trước trên môi trường riêng

Máy tính với cửa sổ PowerShell đang hiển thị công cụ DietPi
Môi trường PowerShell cho phép chạy script, nhưng cần đọc hiểu các lệnh trước khi cho phép thay đổi hệ thống. Ảnh: XDA Developers.

Thay đổi giao diện và gỡ tính năng nên được xét riêng, bởi chúng tác động tới cách Windows hoạt động sau khi script kết thúc. Hiện phần mở rộng tệp phục vụ một nhu cầu khác hẳn việc vô hiệu hóa một tính năng hệ thống; gom cả hai dưới nhãn dọn máy khiến người dùng khó nhận ra mình đang chấp thuận điều gì.

Ví dụ của XDA dùng Registry để bật giao diện tối, hiện tệp ẩn và phần mở rộng tệp, đồng thời cho File Explorer mở vào This PC. Phần khác xử lý Copilot, Recall, kết quả Bing trong Start và widgets. Đây là danh sách tùy chỉnh của một người dùng, không phải danh sách bắt buộc cho mọi bản Windows hay mọi máy tính.

Mỗi thay đổi cần có lý do và cách hoàn tác

Với từng mục muốn thêm vào script, hãy yêu cầu Claude Code nêu khóa hoặc lệnh được dùng, phạm vi tác động và tài liệu làm căn cứ. Đọc cả giá trị sẽ ghi, thay vì chỉ xem lời giải thích bên cạnh. Nếu chưa hiểu một thay đổi sẽ làm gì, bỏ mục đó khỏi lần chạy đầu là lựa chọn tốt hơn để AI quyết định thay.

Nên lưu trạng thái cũ trước khi sửa và yêu cầu hướng dẫn hoàn tác tương ứng. Một lệnh đặt lại giá trị mặc định chưa chắc khôi phục đúng thiết lập mà máy đã có trước đó. Với máy công ty, các tùy chỉnh còn cần tuân theo chính sách quản trị; không nên dùng script cá nhân để tự thay các thiết lập do bộ phận IT quản lý.

Windows cũng thay đổi sau các bản cập nhật, nên một khóa Registry từng có tác dụng không phải lời hứa rằng nó sẽ luôn hoạt động. Nếu AI không chỉ ra được căn cứ phù hợp với phiên bản Windows đang dùng, giữ nguyên thiết lập đó sẽ ít rủi ro hơn việc thêm một dòng lệnh không rõ hiệu quả.

Thử riêng phần có khởi động lại

Cài WSL cần được kiểm tra như một chuỗi thao tác có điểm dừng. Trong trường hợp XDA mô tả, script dùng mục RunOnce để tiếp tục sau khi khởi động lại, rồi Ubuntu vẫn cần người dùng hoàn thành thiết lập. Vì vậy, tự động hóa không đồng nghĩa có thể bỏ mặc toàn bộ quá trình từ đầu tới cuối.

Nếu không cần môi trường Linux, hãy để WSL ngoài script ban đầu. Nếu cần, yêu cầu AI trình bày rõ lệnh nào chạy trước khi khởi động lại, mục nào được đăng ký để chạy tiếp và người dùng phải làm gì sau khi đăng nhập. Không nên ghép một cơ chế tự chạy trở lại vào script chỉ để tiết kiệm vài thao tác mà chưa đọc hiểu nó.

Có thể dùng Windows Sandbox, nếu máy hỗ trợ và đã bật tính năng này, để kiểm tra các lệnh phù hợp trong môi trường tách biệt trước khi đụng tới hệ thống chính. Với chuỗi cần khởi động lại như WSL, nên thử trên máy ảo hoặc máy phụ phù hợp; một lượt chạy trong môi trường thử nghiệm không chứng minh mọi thiết lập sẽ áp dụng giống hệt trên máy thật.

Sau khi chạy, cần xem nhật ký và kiểm tra kết quả thay vì dựa vào thông báo hoàn tất. Bắt đầu từ danh sách ứng dụng giúp phần việc lặp lại trở nên gọn hơn mà chưa phải đánh đổi cấu hình hệ thống. Chỉ bổ sung các tùy chỉnh sâu khi từng mục đã có lý do rõ ràng, biết cách kiểm tra và có đường quay lại nếu kết quả không như mong muốn.

Nguồn tham khảo: XDA Developers; Microsoft Learn: lệnh WinGet install; Tài liệu Claude Code.

Bài này thế nào?

Hoá đơn của bài này

Tek viết bài này bằng cà phê. Mời Tek một ly nha?

Theo dõi TekCafe: Facebook · YouTube

Bài viết mới nhất