Khi nhờ AI sửa một đoạn mã đang chạy, rủi ro lớn nhất không phải là sửa sai chỗ được giao mà là sửa thêm những chỗ không ai giao: đổi tên biến, định dạng lại cả tệp, "tiện tay" tối ưu một hàm bên cạnh. Cách chặn là nói rõ vùng được sửa, liệt kê thứ cấm đụng, đòi thay đổi nhỏ nhất có thể, và nhận kết quả dưới dạng phần khác biệt để rà từng dòng.
Bài này đưa mẫu câu lệnh cho việc sửa mã có sẵn, cách đọc kết quả bằng git, bộ câu lệnh ngắn cho các thao tác thường gặp như đổi tên hay tách hàm, và cách phản hồi khi trợ lý đã lỡ sửa lan. Việc cải tạo cả một khối mã cũ không tài liệu là chủ đề khác, có ở danh mục đọc hiểu và cải tạo mã cũ của trang.
Vì sao trợ lý hay sửa lan ra ngoài
Trợ lý AI được huấn luyện để đưa ra câu trả lời "tốt" theo nghĩa chung: mã gọn, đặt tên rõ, theo phong cách phổ biến. Khi đọc đoạn mã bạn đưa, nó thấy những chỗ có thể "tốt hơn" theo tiêu chuẩn đó và thường sửa luôn, kể cả khi bạn chỉ nhờ thêm một điều kiện kiểm tra. Từ góc nhìn của nó, đó là làm thêm việc tốt; từ góc nhìn của người rà mã, đó là một khối thay đổi lớn mà chỉ một dòng là thứ được yêu cầu.
Thay đổi lan rộng gây ba vấn đề. Người rà khó thấy thay đổi chính giữa hàng chục dòng đổi định dạng. Những thay đổi "vô hại" như đổi tên biến cục bộ đôi khi không vô hại — biến đó được dùng trong một chuỗi mẫu, hoặc tên hàm được gọi bằng chuỗi ở nơi khác. Và lịch sử git trở nên khó đọc: ai đó tra lại lý do một dòng thay đổi sẽ thấy nó nằm trong lần sửa có tiêu đề không liên quan.
Trợ lý trong trình soạn thảo và tác tử có thêm một nguy cơ: chúng sửa trực tiếp trên tệp. Nếu không rà phần khác biệt trước khi lưu thay đổi, những sửa lan đó đi thẳng vào kho mã.
Mẫu câu lệnh sửa mã có sẵn
Bài toán giả định: thêm kiểm tra số lượng tồn kho trước khi cho thêm sản phẩm vào giỏ hàng.
- "Đoạn mã dưới đang chạy đúng. Cần thêm DUY NHẤT một hành vi: khi số lượng yêu cầu lớn hơn tồn kho thì không thêm vào giỏ và trả thông báo Không đủ hàng."
- "Chỉ được sửa trong hàm them_vao_gio. Không đổi tên hàm, tên biến, thứ tự tham số. Không định dạng lại, không đổi kiểu dấu nháy, không sắp xếp lại lệnh nạp thư viện."
- "Nếu thấy chỗ khác có vấn đề, ghi ra một danh sách riêng ở cuối câu trả lời, KHÔNG sửa."
- "Trả lời dưới dạng phần khác biệt (dòng thêm, dòng bỏ) chỉ cho đúng chỗ thay đổi, kèm một câu giải thích."
Dòng "ghi ra danh sách riêng, không sửa" là van an toàn. Trợ lý vẫn được nói điều nó thấy — và điều nó thấy đôi khi đáng giá — nhưng bạn quyết định có xử lý hay không, trong một lần thay đổi riêng. Nhiều người thấy chính danh sách này là phần có ích nhất của câu trả lời.
Khoanh vùng khi dùng trợ lý ngay trong trình soạn thảo
Trợ lý tích hợp trong trình soạn thảo thường có hai cách nhận việc: chat bên cạnh, nhìn được cả tệp hoặc nhiều tệp; và sửa tại chỗ trên đoạn mã bạn bôi chọn. Với việc sửa nhỏ, cách thứ hai là cách khoanh vùng tự nhiên nhất. Bôi chọn đúng hàm hoặc khối cần sửa, gõ yêu cầu, và trợ lý chỉ đề xuất thay đổi trong vùng đó. Bạn thấy ngay phần thêm và phần bỏ ngay trên tệp, chấp nhận hoặc từ chối từng khối.
Bôi chọn không phải là bảo đảm tuyệt đối. Tuỳ công cụ, trợ lý vẫn có thể đề xuất thêm dòng nạp thư viện ở đầu tệp, hoặc ở chế độ tác tử thì tự mở rộng sang tệp khác. Đọc lại phần đề xuất trước khi chấp nhận, đặc biệt những khối nằm ngoài vùng bạn đã chọn.
Một thói quen nhỏ giúp ích nhiều: lưu thay đổi bằng git ngay trước khi nhờ trợ lý sửa. Khi đó thao tác hoàn tác luôn có điểm quay về rõ ràng, và lệnh git diff chỉ hiện đúng những gì trợ lý vừa làm, không lẫn với thay đổi dở dang của chính bạn.
Đọc kết quả bằng git: nhìn vào đâu
Dù trợ lý trả mã đầy đủ hay phần khác biệt, cách kiểm chắc nhất là áp vào tệp rồi xem lệnh git diff. Bảng dưới là những dấu hiệu cần dừng lại hỏi.
| Dấu hiệu trong phần khác biệt | Có thể là gì | Phản hồi |
|---|---|---|
| Hàng loạt dòng chỉ đổi khoảng trắng hoặc dấu nháy | Định dạng lại cả tệp | Bỏ thay đổi, yêu cầu làm lại không định dạng; nếu cần định dạng, làm riêng một lần bằng công cụ định dạng của dự án |
| Tên biến hoặc hàm đổi ở nhiều chỗ | Đổi tên tiện tay | Hỏi lý do; thường yêu cầu giữ tên cũ |
| Dòng nạp thư viện mới | Thêm phụ thuộc | Kiểm thư viện có trong dự án chưa; nếu chưa, hỏi có làm được bằng thứ có sẵn không |
| Tệp ngoài phạm vi bị chạm | Sửa lan | Hoàn tác tệp đó bằng git, nhắc lại phạm vi |
| Chú thích cũ bị xoá | Trợ lý cho là thừa | Khôi phục; chú thích có thể chứa lý do quan trọng |
Lệnh git diff kèm tuỳ chọn bỏ qua khác biệt khoảng trắng giúp nhìn thấy thay đổi thật khi tệp lỡ bị định dạng lại, nhưng đó là cách đọc tạm. Thay đổi đưa lên kho mã vẫn nên sạch, không trộn định dạng với logic.
Câu lệnh ngắn cho các thao tác sửa thường gặp
Đổi tên. "Đổi tên hàm tinh_tien thành tinh_tong_tien ở mọi nơi trong các tệp đã đưa. Liệt kê mọi chỗ đã đổi. Kiểm cả chỗ tên hàm xuất hiện trong chuỗi." Với đổi tên trên cả dự án, tính năng đổi tên của trình soạn thảo dựa trên phân tích mã thường đáng tin hơn để AI tìm thay chữ.
Tách hàm. "Tách đoạn tính phí giao hàng trong hàm xu_ly_don thành một hàm riêng tinh_phi_giao, nhận đúng những biến nó cần qua tham số. Hành vi của xu_ly_don phải giữ nguyên. Không sửa gì khác."
Bỏ lặp. "Ba hàm sau có đoạn kiểm tra quyền giống nhau. Đề xuất cách gom thành một hàm dùng chung, nhưng chưa sửa; trình bày trước ba hàm sẽ thay đổi thế nào." Gom mã lặp chạm nhiều nơi nên đáng có bước kế hoạch.
Thêm xử lý lỗi. "Bọc lời gọi API trong hàm lay_ty_gia bằng xử lý lỗi: hết thời gian chờ thì thử lại một lần, vẫn lỗi thì ghi log và trả None. Không đổi chữ ký hàm."
Nâng cú pháp cũ. "Đổi các vòng lặp kiểu cũ trong tệp này sang cú pháp hiện đại tương đương, giữ nguyên hành vi, mỗi chỗ đổi một dòng giải thích." Chỉ làm khi đã có kiểm thử chạy được.
Giữ hành vi bằng kiểm thử trước khi sửa
Câu "giữ nguyên hành vi" trong câu lệnh chỉ có nghĩa khi bạn có cách kiểm. Nếu đoạn mã đã có kiểm thử, chạy chúng trước khi sửa để chắc tất cả đang qua, rồi chạy lại sau khi áp thay đổi của trợ lý. Nếu chưa có, ít nhất ghi lại vài cặp đầu vào và kết quả hiện tại của hàm sắp sửa, như một bộ kiểm thử tối thiểu.
Một mẹo đáng dùng: trước khi giao việc sửa, nhờ trợ lý viết kiểm thử cho hành vi hiện tại của hàm. Bạn đọc, chạy, xác nhận các kiểm thử đó qua trên mã cũ. Sau đó mới giao việc sửa, và yêu cầu mã mới phải qua cùng bộ kiểm thử, cộng thêm kiểm thử cho hành vi mới. Cách viết kiểm thử tốt có ở danh mục kiểm thử và rà soát của trang; ở đây chỉ cần nhớ thứ tự: chốt hành vi cũ trước, sửa sau.
Khi trợ lý báo cần sửa kiểm thử cũ để mã mới qua được, dừng lại. Hoặc hành vi cũ thật sự phải đổi — một quyết định cần bạn xác nhận — hoặc mã mới đã phá hành vi mà lẽ ra phải giữ.
Một việc sửa lớn: nhiều lần lưu thay đổi nhỏ
Có những việc sửa vốn đã lớn: đổi cách lưu trạng thái đăng nhập, thay thư viện gửi thư, đổi định dạng ngày trên toàn bộ trang quản trị. Với những việc này, "thay đổi tối thiểu" không có nghĩa là ít dòng, mà là mỗi lần lưu thay đổi chỉ chứa một bước có thể kiểm và hoàn tác riêng.
Ví dụ giả định với việc thay thư viện gửi thư: bước một, thêm một hàm bọc gui_thu dùng thư viện cũ, đổi mọi nơi gọi trực tiếp sang gọi hàm bọc — hành vi không đổi. Bước hai, đổi ruột hàm bọc sang thư viện mới. Bước ba, gỡ thư viện cũ. Mỗi bước giao cho trợ lý bằng một câu lệnh riêng, mỗi bước chạy kiểm thử và lưu thay đổi riêng.
Cách chia này khiến người rà mã đọc được từng bước, và nếu bước hai gây lỗi trên máy chủ thật, bạn chỉ hoàn tác bước hai mà vẫn giữ được phần dọn dẹp ở bước một. Giao nguyên việc trong một câu lệnh thì mất cả hai lợi ích đó.
Khi trợ lý đã lỡ sửa lan
Đừng cố gỡ từng dòng sửa lan bằng tay rồi giữ phần đúng. Cách nhanh và sạch hơn là hoàn tác toàn bộ thay đổi bằng git, rồi giao lại việc với câu lệnh chặt hơn. Nếu thay đổi chính đã đúng, bạn có thể dán riêng phần đó vào câu lệnh mới: "Chỉ áp đúng thay đổi này, không gì khác."
Với tác tử, sửa lan thường là dấu hiệu việc giao quá rộng hoặc thiếu tệp hướng dẫn dự án ghi rõ quy ước. Nếu cùng một kiểu sửa lan lặp lại — luôn định dạng lại tệp, luôn đổi dấu nháy — thêm một dòng vào tệp hướng dẫn dự án, để lần sau không phải nhắc trong từng câu lệnh.
Cũng đáng tự hỏi: có phải công cụ định dạng của dự án chưa được cấu hình, nên trợ lý không biết phong cách nào là chuẩn? Một tệp cấu hình định dạng rõ ràng, chạy tự động khi lưu, giải quyết tận gốc tranh cãi về khoảng trắng giữa người và AI.
Câu hỏi thường gặp
Nên nhận toàn bộ tệp hay chỉ phần khác biệt từ chatbot?
Với tệp ngắn, nhận toàn bộ rồi dùng git để so là tiện. Với tệp dài, yêu cầu phần khác biệt hoặc chỉ hàm thay đổi, vì trợ lý chép lại tệp dài dễ làm rơi hoặc đổi những đoạn không liên quan. Dù cách nào, xem git diff trước khi lưu thay đổi.
Trợ lý đề xuất sửa thêm một lỗi nó phát hiện, có nên đồng ý ngay không?
Ghi nhận rồi xử lý thành một việc riêng. Kiểm xem đó có thật là lỗi không bằng cách tái hiện, viết kiểm thử chứng minh lỗi, rồi mới sửa. Gộp vào thay đổi đang làm khiến người rà khó tách hai việc và khó hoàn tác nếu một trong hai sai.
Đổi tên hàng loạt bằng AI có an toàn bằng tính năng của trình soạn thảo không?
Thường không bằng. Tính năng đổi tên dựa trên phân tích mã của trình soạn thảo hiểu phạm vi biến và tham chiếu thật, còn AI làm theo cách đọc văn bản. AI hữu ích để gợi ý tên mới và tìm chỗ tên xuất hiện trong chuỗi hay tài liệu, phần đổi thật nên để công cụ chuyên dụng.
Có cách nào buộc tác tử chỉ được sửa một số tệp không?
Một số công cụ cho phép giới hạn thư mục hoặc tệp tác tử được ghi, hoặc yêu cầu xác nhận trước mỗi lần sửa; tên và cách bật tuỳ công cụ và phiên bản. Khi không có cơ chế đó, câu lệnh giới hạn phạm vi cộng với việc rà git diff là lớp bảo vệ còn lại.
Sửa mã của đồng nghiệp bằng AI có cần báo không?
Nên ghi rõ trong mô tả thay đổi rằng có dùng trợ lý AI, nếu quy ước nhóm yêu cầu. Quan trọng hơn là người sửa phải hiểu và chịu trách nhiệm về mọi dòng thay đổi như khi tự viết; người rà vẫn rà theo tiêu chuẩn bình thường.