Giới thiệu: Mã Lệnh Không Quan Tâm Đến Cảm Xúc Của Bạn
Vấn đề với các mô hình ngôn ngữ lớn và code là: chúng tự tin đến kinh ngạc và hoàn toàn thờ ơ với việc chương trình của bạn có biên dịch được hay không. sẽ sẵn lòng viết cho bạn một script Python để giải quyết vấn đề của bạn, cộng thêm hai vấn đề nó tự nghĩ ra để giải trí. Bí quyết—bí quyết duy nhất quan trọng—là học cách nhắc tạo ra code chính xác theo cách không để lại chỗ cho cảm xúc và tạo ra nhiều chỗ nhất cho sự thật. Bạn không muốn văn xuôi nghe giống như code. Bạn muốn code hoạt động như code. Có sự khác biệt.
Mọi người coi việc nhắc lệnh như một câu thần chú huyền bí—nói đúng từ, có được một ứng dụng hoàn hảo. Đó là tư duy sùng bái hàng hóa. Code là một hợp đồng. Nếu bạn muốn có được sự chính xác từ , bạn phải viết hợp đồng. “Xây dựng một ứng dụng web” không phải là một hợp đồng. “Tạo một điểm cuối trong chấp nhận , xác thực lược đồ bằng và trả về 422 khi có lỗi lược đồ với định dạng payload cụ thể” là một hợp đồng. Đó là cách nhắc tạo ra code chính xác: bạn phải chốt được hợp đồng.
Đây Là Gì (và Không Phải Là Gì)
- Đây là hướng dẫn cách lấy code đáng tin cậy, có thể kiểm tra được từ .
- Đây không phải là một bài giảng về “AI thay thế các nhà phát triển”. Công cụ không thay thế tư duy.
- Nó tập trung vào các lời nhắc thực tế, cấu trúc và lan can bảo vệ: những phần nhàm chán làm cho điều kỳ diệu xảy ra.
Nếu bạn muốn code chạy được, bạn cần cung cấp cho một định nghĩa hoạt động về “chạy được”. Nếu bạn muốn tạo code chính xác, bạn cần định nghĩa sự chính xác bằng các thuật ngữ rõ ràng, có thể kiểm tra được. Đó là toàn bộ trò chơi.
Định Nghĩa Sự Chính Xác Như Một Luật Sư, Không Phải Một Nhà Thơ
Code “chính xác” không phải là code “có vẻ hợp lý”. Sự chính xác là:
- Tính hợp lệ cú pháp: nó biên dịch hoặc chạy được dưới trình thông dịch.
- Tính trung thực ngữ nghĩa: nó làm những gì đặc tả yêu cầu.
- Hành vi tất định: đầu vào giống nhau, đầu ra giống nhau, trong phạm vi sai số đã xác định.
- Tính đúng đắn của phiên bản: nó sử dụng đúng , phiên bản và tính năng ngôn ngữ.
sẽ cung cấp cho bạn những gì bạn yêu cầu. Nếu bạn yêu cầu “một hàm sắp xếp một danh sách”, bạn có thể sẽ nhận được một hàm. Nếu bạn yêu cầu “một cách sắp xếp ổn định, tại chỗ sử dụng ngữ nghĩa với không gian phụ ”, đó là một lời hứa khác. “Cách nhắc tạo ra code chính xác” bắt đầu bằng việc viết những lời hứa đó vào lời nhắc.
Lời Nhắc Khả Thi Tối Thiểu, Được Nâng Cấp
Tệ: “Viết một cho các tác vụ.”
Tốt hơn: “Viết một với một route xác thực các trường {title: string, dueDate: ISO 8601} và trả về 201 với đối tượng đã tạo hoặc 400 với thông tin chi tiết về lỗi.”
Chính xác: “Tạo một máy chủ với một endpoint duy nhất. Yêu cầu: 1) Xác thực body bằng ; 2) Các trường: title (chuỗi không trống, tối đa 140), dueDate (ngày ISO 8601 trong tương lai); 3) Khi thành công: 201 với {id: , title, dueDate}; 4) Khi không hợp lệ: 400 với {error: 'VALIDATION', details: array}; 5) Không có cơ sở dữ liệu; trong bộ nhớ; 6) Bao gồm tệp kiểm tra bao gồm trường hợp hợp lệ, không hợp lệ (tiêu đề trống, ngày trong quá khứ); 7) Cung cấp script cho test và dev; 8) Sử dụng ; 9) Không bao gồm bình luận thừa.”
Lưu ý hình dạng: phiên bản ngôn ngữ, thư viện, ràng buộc, đầu ra, lỗi, kiểm tra và thậm chí cả cấu trúc gói. Bạn đã loại bỏ sự mơ hồ. Công việc của là điền vào code, không phải yêu cầu.
Mô Hình Giàn Giáo: Hệ Thống, Đặc Tả, Kiểm Tra, Sau Đó Là Code
Nếu bạn muốn tạo code chính xác từ , bạn cần cung cấp cho nó một đường băng:
- Đóng khung hệ thống (dây xích ngắn)
- Bạn: “Bạn đang viết chất lượng sản xuất cho . Chỉ xuất các khối code có tên tệp và không có gì khác.”
- Tại sao: Bạn kiểm soát tông giọng và định dạng đầu ra. Đừng để nó cho sự may rủi.
- Bao gồm phiên bản ngôn ngữ, lựa chọn gói, ngữ nghĩa lỗi, định dạng I/O, giới hạn hiệu suất và ràng buộc bảo mật.
- Yêu cầu viết unit test trước. Kiểm tra định nghĩa “chính xác” tốt hơn tính từ. Nếu một dòng code không phục vụ cho một bài kiểm tra, nó chỉ là trang trí.
- Chỉ sau khi kiểm tra. Vâng, về cơ bản đây là , nhưng với một robot không bao giờ chán viết boilerplate.
- Hướng dẫn cho việc chạy lại
- “Nếu kiểm tra không thành công hoặc import không khớp, chỉ cập nhật các phần bị lỗi. Không viết lại toàn bộ dự án.”
làm tốt khi nó có ngữ cảnh và đường ray. Hãy cho nó đường ray.
Ghim Phiên Bản Không Phải Là Tùy Chọn
Dữ liệu huấn luyện của chứa đầy các tài liệu cũ và mới. Đó là một cách lịch sự để nói rằng nó đã thấy rất nhiều lời khuyên mâu thuẫn. “Sử dụng ” là mơ hồ. “Sử dụng với data router” là chỉ dẫn. Đừng tin vào mặc định:
- Ngôn ngữ: ghim vào —bất cứ thứ gì bạn thực sự chạy.
- Framework: chỉ định các phiên bản chính xác và bất kỳ flag thay đổi nào.
- : ghim phiên bản; so với là quan trọng.
- : chỉ định các quy tắc để tránh việc viết lại “style ping-pong”.
Nếu bạn không ghim, bạn sẽ nhận được một bản medley những bản hit hay nhất từ năm năm trước. Việc tạo code chính xác bị dị ứng với sự hoài cổ.
Lược Đồ Đầu Tiên, Luôn Luôn
Đừng yêu cầu cấu trúc “hồ sơ người dùng”. Xác định lược đồ trong lời nhắc và yêu cầu xác thực:
- Lược đồ hoặc các loại trong
Sau đó, yêu cầu thực thi lược đồ tại các ranh giới—đầu vào , ghi cơ sở dữ liệu và hàng đợi tin nhắn. Yêu cầu các payload và code lỗi rõ ràng. Sự chính xác yêu thích lược đồ. Sự mơ hồ thì không.
Làm Cho Nó Có Thể Quan Sát Được, Nếu Không Đừng Giả Vờ Nó Là Thật
Yêu cầu thêm nhật ký, số liệu và dấu vết nơi bạn cần—và giữ chúng yên lặng nơi bạn không cần. Một lời nhắc tốt bao gồm:
- Chính sách ghi nhật ký: cấp độ, chỉnh sửa , cấu trúc (nhật ký , làm ơn)
- Số liệu: thời gian cho mỗi yêu cầu, số lượng lỗi
- Endpoint kiểm tra sức khỏe: chứng minh các phụ thuộc đang hoạt động
sẽ thêm những gì bạn yêu cầu. Nếu bạn không yêu cầu, bạn sẽ nhận được các câu lệnh in—nếu bạn may mắn.
Lời Nhắc Kiểm Tra Trước Đánh Bại “Chỉ Cần Tin Tôi”
Một cách tốt để nhắc tạo ra code chính xác là biến các bài kiểm tra thành nguồn sự thật. Ví dụ:
“Viết các bài kiểm tra cho một hàm mà:
- chuyển đổi phần cục bộ và phần tên miền thành chữ thường;
- loại bỏ dấu chấm ở phần cục bộ chỉ cho ;
- loại bỏ địa chỉ phụ (+tag) chỉ cho ;
- từ chối đầu vào không có một dấu @ duy nhất hoặc có khoảng trắng;
- giữ lại mã của tên miền unicode như cũ.
Bao gồm các trường hợp đặc biệt. Sau khi viết các bài kiểm tra, hãy triển khai hàm để vượt qua chúng.”
thường sẽ viết code tốt hơn khi bị buộc phải đáp ứng các bài kiểm tra bạn đã mô tả. Nếu không, bạn có một thất bại cụ thể, không phải một cuộc tranh luận cảm tính.
Không Ảo Giác Do Cấu Trúc
Bạn không thể loại bỏ ảo giác, nhưng bạn có thể rào chúng lại:
- Chỉ yêu cầu trích dẫn hoặc nguồn khi nguồn tồn tại. Đối với các phương thức , hãy yêu cầu liên kết tài liệu và yêu cầu code phải khớp với các tài liệu đó.
- Đối với riêng tư, hãy dán đặc tả vào lời nhắc. Đừng mong biết các endpoint nội bộ của bạn.
- Đối với các thư viện có khó hiểu, hãy bao gồm một đoạn mã ví dụ từ tài liệu chính thức và yêu cầu tuân thủ nó.
Code chính xác chủ yếu là các tham chiếu chính xác. Cung cấp cho các tham chiếu.
Hướng Dẫn Phong Cách: Điều Ít Gợi Cảm Nhất, Hữu Ích Nhất
viết code theo bất kỳ phong cách nào nó suy ra. Đó là một công thức cho sự thay đổi. Dán hướng dẫn phong cách của bạn. Chỉ định:
Ngoài ra, hãy yêu cầu một nhận xét lý do ngắn gọn cho các lựa chọn không rõ ràng. Bạn trong tương lai sẽ cảm ơn bạn và hiện tại sẽ tạo ra ít “sửa chữa” hơn.
Lời Nhắc Dài, Đầu Ra Ngắn
Một cách khác để suy nghĩ về cách nhắc tạo ra code chính xác: hãy dành lời lẽ của bạn cho lời nhắc, không phải đầu ra. Bạn muốn:
- Các ràng buộc đầy đủ trong lời nhắc
- Tường thuật thừa tối thiểu trong đầu ra
Yêu cầu nó loại bỏ giải thích và chỉ trả về các khối code có tên tệp và một tệp ngắn gọn. Nếu bạn muốn bình luận, hãy yêu cầu nó trong một lần chạy riêng. Xen kẽ văn xuôi và code là cách lỗi lẻn vào bằng cách đeo kính một tròng và đội mũ chóp.
Tinh Chỉnh: Vòng Lặp Chặt Chẽ Thực Sự Hoạt Động
Con đường nhanh nhất để có code đáng tin cậy không phải là “làm đúng ngay lần thử đầu tiên”. Đó là các vòng lặp sửa chữa ngắn gọn:
- Chạy cục bộ. Dán đầu ra kiểm tra không thành công và lỗi trình biên dịch trở lại một cách nguyên văn.
- Hướng dẫn: “Chỉ sửa đổi số dòng tối thiểu cần thiết; không thay đổi chữ ký hàm trừ khi được yêu cầu bởi các bài kiểm tra không thành công.”
- Lặp lại cho đến khi xanh.
rất xuất sắc trong việc áp dụng các khác biệt khi bạn cho nó biết chính xác điều gì đã hỏng. Đừng diễn giải lại nhật ký lỗi. Hãy dán chúng. Nhật ký là sự thật.
Bảo Mật Là Một Tính Năng, Không Phải Là Một Tái Bút
Vì các mô hình được đào tạo trên code công khai (tốt, xấu và bị nguyền rủa), bạn nên biến bảo mật thành một yêu cầu hạng nhất:
- Nghiêm cấm , và có kiểu chuỗi
- Yêu cầu các truy vấn được tham số hóa, bảo vệ và giới hạn tỷ lệ
- Yêu cầu ghim phụ thuộc cộng với một tệp khóa
- Yêu cầu xử lý bí mật thông qua các biến môi trường hoặc trình quản lý bí mật
Một lời nhắc an toàn theo mặc định tạo ra code an toàn hơn. Một lời nhắc “chúng ta sẽ vá nó sau” tạo ra các tiêu đề.
Hiệu Suất: Nói Rõ “Nhanh” Có Nghĩa Là Gì
“Làm cho nó nhanh” dịch thành “làm bất cứ điều gì”. Thay vào đó, hãy chỉ định số liệu:
- Mục tiêu độ trễ ( cho trong bộ nhớ, cho hoạt động )
- Độ phức tạp thời gian (phải là , không phải )
sẽ chọn các thuật toán phù hợp với ngân sách bạn đặt ra. Hãy cho nó một ngân sách.
Tài Liệu: Đủ Để Giúp Người Lạ Làm Quen
Yêu cầu cung cấp một tệp bao gồm:
- Hướng dẫn thiết lập với các phiên bản chính xác
- Các lệnh cho test, lint, typecheck, run
- Ví dụ về yêu cầu/phản hồi
- Các hạn chế và đánh đổi đã biết
“Code chính xác” bao gồm tài liệu chính xác. Chúng là một phần của sản phẩm bàn giao.
Các Mẫu Lời Nhắc Cụ Thể Bạn Có Thể Ăn Cắp
Mẫu: Endpoint Backend
Hệ thống: Bạn là một kỹ sư tỉ mỉ. Chỉ xuất các khối code có tên tệp.
Người dùng:
- Xây dựng một ứng dụng với một endpoint .
- Yêu cầu: {amount: as string, from: 'USD'|'EUR', to: same}.
- Xác thực bằng ; trả về hình dạng 422 khi có lỗi lược đồ.
- Sử dụng một hàm thuần túy với tỷ giá cố định {USD:1, EUR:1.1}.
- Trả về {amount: string, currency: string} với 200.
- Bao gồm các bài kiểm tra bao gồm trường hợp hợp lệ, không hợp lệ (số thập phân xấu, code không xác định) và edge (0).
- Cung cấp với các phụ thuộc được ghim; bao gồm cấu hình và .
- Không có cuộc gọi mạng, không có bình luận.
Mẫu: Tiện Ích CLI
Hệ thống: Bạn đang viết . Chỉ xuất các khối code có tên tệp.
Người dùng:
- Tạo một có tên đọc và in các slug an toàn cho .
- Quy tắc: chữ thường, chỉ , dấu gạch nối phân tách, thu gọn khoảng trắng, loại bỏ dấu chấm câu.
- Cung cấp và với các bài kiểm tra bảng.
- Bao gồm với các mục tiêu test và build.
Mẫu: Thành Phần Frontend
Hệ thống: Bạn là một kỹ sư thực dụng nhắm mục tiêu .
Người dùng:
- Triển khai một thành phần .
- Props: value: string, onChange(value): void, delay=300.
- Sử dụng ; không có hook của bên thứ ba.
- Bao gồm các bài kiểm tra với bộ hẹn giờ giả.
- Cung cấp story tối thiểu.
Các mẫu này minh họa cách nhắc tạo ra code chính xác bằng cách ghim phiên bản, xác định hành vi và yêu cầu kiểm tra.
Từ Chối Thông Minh: Khi Nào Nên Nói “Đừng Tối Ưu Hóa”
Nếu bạn không muốn tối ưu hóa vi mô sớm (và bạn không muốn), hãy nói như vậy:
- “Ưu tiên khả năng đọc hơn sự thông minh; không xoắn bit trừ khi các bài kiểm tra yêu cầu.”
- “Không đệ quy nếu lặp lại rõ ràng hơn.”
- “Không siêu lập trình; rõ ràng > ngầm định.”
thích gây ấn tượng. Đừng để nó làm vậy. Hãy làm cho nó vượt qua các bài kiểm tra và dễ đọc. Điều đó đủ ấn tượng rồi.
Sider.AI Trong Quy Trình Làm Việc, Nơi Nó Thực Sự Giúp Ích Tôi đã thấy mọi người tung hứng các lời nhắc trong các tab trò chuyện ngẫu nhiên như thể đó là một nghi thức năng suất. Sử dụng một không gian làm việc hiểu ngữ cảnh code. Sider.AI, chẳng hạn, được xây dựng xung quanh việc giữ cho đặc tả, code, diff và nhật ký kiểm tra của bạn trong tầm nhìn, vì vậy vòng lặp “dán lỗi, sửa dòng” thực sự chặt chẽ. Nó không phải là phép thuật; nó là giàn giáo nhàm chán giúp bạn không bị lạc đề. Nếu công cụ của bạn giữ hợp đồng, các bài kiểm tra và code trong cùng một cuộc trò chuyện—mà không làm phiền bạn bằng giấyConfetti—hãy sử dụng nó. làm được. Cách Gỡ Lỗi Với Như Một Đồng Đội, Không Phải Một Nhà Tiên Tri
- Dán đầu ra kiểm tra không thành công chính xác như cũ. Đừng tóm tắt.
- Yêu cầu một diff: “Chỉ trả lời với diff thống nhất so với tệp X.”
- Đối với các lỗi thời gian chạy, hãy thêm đoạn mã có thể tái tạo nhỏ nhất và yêu cầu giải thích cộng với một bản vá.
- Đối với các lỗi thư viện, hãy dán đoạn trích tài liệu bạn nghĩ là áp dụng và hỏi: “Đây có phải là chính xác cho phiên bản X không? Nếu không, hãy cập nhật code và trích dẫn đoạn trích chính xác.”
Mục tiêu là làm cho tranh luận bằng chứng. Bạn mang bằng chứng.
Cuộc Diễu Hành Cạm Bẫy (và Cách Né Tránh Nó)
- Cạm bẫy “mới nhất”: Đừng nói “sử dụng mới nhất”. Hãy nói “sử dụng phiên bản X.Y” và gắn bó với nó.
- Tệp kiểm tra trống: Nếu bạn không yêu cầu kiểm tra, bạn sẽ không nhận được chúng.
- Ngụy biện một lần: Lên kế hoạch cho hai hoặc ba lần tinh chỉnh ngắn. Nó nhanh hơn một lời nhắc cồng kềnh.
- Chính sách lỗi mơ hồ: Xác định mã trạng thái và payload. “Trả về một lỗi” không có nghĩa gì.
- Phụ thuộc không sở hữu: Nếu code dựa vào một dịch vụ bạn không thể kiểm soát, hãy stub nó. Yêu cầu fakes.
Danh Sách Kiểm Tra Lời Nhắc Của Bạn (Dán Cái Này Gần Màn Hình Của Bạn)
- Phiên bản ngôn ngữ và thời gian chạy được ghim
- Phiên bản thư viện được ghim
- Lược đồ dữ liệu được xác định
- Ngữ nghĩa lỗi được xác định (code, hình dạng)
- Kiểm tra trước, sau đó là code
- Các ràng buộc bảo mật rõ ràng
- Ngân sách hiệu suất được nêu
- Phong cách và cấu trúc được chỉ định
- Định dạng đầu ra bị ràng buộc (tên tệp, khối code, diff)
- Vòng lặp tinh chỉnh ngắn với nhật ký đã dán
Nếu bạn đạt được cả mười, thường tạo ra code chính xác tồn tại được dưới ánh sáng ban ngày.
Một Ví Dụ Đã Thực Hiện: Từ Mơ Hồ Đến Đã Xác Minh
Lời nhắc mơ hồ: “Viết một hàm để phân tích cú pháp một cách an toàn.”
Kết quả: Có thể ổn, có thể sai, chắc chắn chưa được kiểm tra.
Lời nhắc chính xác:
“Bạn đang viết . Chỉ xuất các khối code có tên tệp.
Tạo và với một hàm . Yêu cầu: sử dụng với và ; không cho phép byte null; từ chối các tệp >10MB; giới hạn số cột là 100; loại bỏ ; coi các ô trống là chuỗi trống; đưa ra với mã tin nhắn {FILE_TOO_LARGE, NULL_BYTE, TOO_MANY_COLUMNS}. Bao gồm các bài kiểm tra trong với bao gồm đường dẫn hạnh phúc, byte null, tệp 11MB, 101 cột và xử lý . Cung cấp với các phụ thuộc được ghim và cấu hình .”
Bạn sẽ nhận được code, kiểm tra và xử lý edge. Sau đó, bạn chạy kiểm tra, dán các lỗi và lặp lại với các diff tối thiểu. Đó là tạo code chính xác trong thực tế.
Về “Sáng Tạo” và Các Từ Tiếp Thị Khác
Tôi không cần code “sáng tạo”. Tôi cần code chính xác. Hãy dành sự sáng tạo để đặt tên cho con mèo của bạn. Khi nhắc , sự sáng tạo là sản phẩm tự nhiên của các ràng buộc vững chắc. Các bài kiểm tra đúng và các đặc tả rõ ràng tạo ra các giải pháp thanh lịch. Lời nhắc sai tạo ra “ được phát minh lại với biểu tượng cảm xúc.” Đừng cám dỗ nó.
Bí Mật Không Phải Là Bí Mật
Cách nhắc tạo ra code chính xác là nhàm chán: viết ra những gì bạn cần, ghim phiên bản, xác định lược đồ, yêu cầu kiểm tra và lặp lại với các lỗi thực tế. Đó là tất cả. Không có gì huyền bí. Chỉ là kỷ luật kỹ thuật, với một mô hình có thể gõ rất nhanh và không ngại viết mười lăm trường hợp kiểm tra gần như giống hệt nhau.
Và đó là sự thay đổi: sự chính xác là không hào nhoáng. Các lời nhắc hoạt động đọc giống như một danh sách kiểm tra . Code được xuất xưởng đọc như thể nó được viết bởi một người quan tâm. Bạn nhận được cả hai bằng cách đối xử với mô hình như một kỹ sư cơ sở phát triển mạnh dưới các yêu cầu rõ ràng và héo hon dưới sự chỉ đạo mơ hồ. Hãy cho nó một hợp đồng. Hãy làm cho nó vượt qua các bài kiểm tra. Sau đó, có lẽ, bạn có thể tin tưởng nó—với loại tin tưởng bạn dành cho một công cụ, không phải một nhà tiên tri.
Kết Luận: Ít Phép Thuật Hơn, Nhiều Bảo Hành Hơn
Nếu bạn muốn phép thuật, hãy đến một buổi biểu diễn ảo thuật. Nếu bạn muốn phần mềm biên dịch và hoạt động, hãy viết các lời nhắc hoạt động như bảo hành. Cách nhắc tạo ra code chính xác không phải là về cách diễn đạt hoa mỹ hay các từ khóa bí mật. Đó là về các ràng buộc, kiểm tra, phiên bản và vòng phản hồi. Thực hiện bốn điều đó, và bạn sẽ nhận được code chạy được. Bỏ qua chúng, và bạn sẽ nhận được tiểu thuyết được định dạng đẹp mắt.
Code không quan tâm đến cảm xúc của bạn. May mắn thay, các bài kiểm tra cũng vậy.
FAQ
Câu hỏi 1: Cách đơn giản nhất để nhắc Claude Haiku 4.5 tạo code chính xác là gì?
Hãy xem nó như một hợp đồng: ghim phiên bản, xác định lược đồ, chỉ định định dạng lỗi và yêu cầu kiểm tra trước. Các ràng buộc càng rõ ràng, code càng chính xác.
Câu hỏi 2: Làm cách nào để giảm thiểu việc tạo thông tin sai lệch khi Claude viết code?
Dán các tài liệu hoặc thông số kỹ thuật chính thức và yêu cầu tuân thủ chính xác các API đó. Đối với các endpoint riêng tư, hãy bao gồm thông số kỹ thuật của riêng bạn—đừng mong đợi nó đoán.
Câu hỏi 3: Tôi nên yêu cầu Claude tạo các bài kiểm tra hay tự viết chúng?
Hãy yêu cầu Claude tạo các bài kiểm tra trước, sau đó triển khai code để đáp ứng chúng. Các bài kiểm tra xác định độ chính xác tốt hơn các tính từ và giữ cho mô hình trung thực.
Câu hỏi 4: Mức độ cụ thể của việc ghim phiên bản trong lời nhắc nên như thế nào?
Rất cụ thể: thời gian chạy ngôn ngữ, phiên bản chính/phụ của framework và phiên bản SDK. "Mới nhất" mời các mẫu xung đột; độ chính xác phụ thuộc vào các mục tiêu ổn định.
Câu hỏi 5: Sider.AI phù hợp với việc nhắc tạo code chính xác ở đâu?
Sử dụng Sider.AI để giữ các thông số kỹ thuật, code, diff và nhật ký kiểm tra trong một vòng lặp. Nó không tạo ra phép màu—nó chỉ giữ lại ngữ cảnh để các bản sửa lỗi của Claude theo dõi các lỗi thực tế của bạn. 
