Cách cải tiến ứng dụng do AI xây dựng mà không làm hỏng nó

Để cải tiến một ứng dụng do AI xây dựng mà không làm hỏng nó, hãy thay đổi một thứ cho mỗi prompt, kiểm tra trong bản xem trước, và lưu một checkpoint trước khi chuyển sang việc khác. Hãy mô tả những gì bạn thấy thay vì những gì bạn nghĩ mã làm, lên kế hoạch cho các thay đổi lớn trước khi xây dựng chúng, và khi một thay đổi đi sai, hãy quay lại phiên bản tốt gần nhất thay vì yêu cầu AI sửa chính bản sửa của nó.

Phiên bản đầu tiên của một ứng dụng thường hoàn thành chỉ trong vài phút. Phần khó là thay đổi thứ năm mươi, khi mỗi prompt mới có nguy cơ làm hỏng một thứ đã từng hoạt động. Hướng dẫn này là vòng lặp giúp tránh điều đó.

Vòng lặp cải tiến

1. Chọn một thay đổi. Một tính năng, một lỗi, một trang.
2. Mô tả nó theo những gì người dùng thấy và làm.
3. Với thay đổi lớn, lên kế hoạch trước. Yêu cầu một kế hoạch, đọc nó, rồi mới xây dựng.
4. Kiểm tra kết quả trong bản xem trước — thay đổi và các luồng gần nó.
5. Lưu một checkpoint hoặc commit.
6. Lặp lại.

Mỗi bước đều tồn tại để giữ cho các thay đổi nhỏ và có thể đảo ngược.

Bước 1: Giữ một danh sách ngắn

Trước khi viết prompt, hãy ghi lại những gì bạn muốn thay đổi, theo thứ tự quan trọng. Điều đó giúp bạn không gửi một đoạn văn gồm mười mong muốn trong một tin nhắn, và cho bạn cách nói "chưa phải lúc này" với những ý tưởng nảy ra giữa chừng.

Nếu một thay đổi lớn, hãy chia nhỏ nó. "Thêm tài khoản nhóm" thành: tạo nhóm, mời một thành viên, chuyển đổi giữa các nhóm, giới hạn dữ liệu trong nhóm hiện tại. Mỗi mục là một prompt riêng. Viết câu chuyện người dùng là cách tốt để làm việc này.

Bước 2: Mô tả những gì bạn thấy

AI không thể nhìn thấy màn hình của bạn trừ khi bạn nói cho nó biết. Hãy chỉ ra những thứ cụ thể và nói điều gì nên xảy ra:

Trên trang giá khi dùng điện thoại, nút của thẻ Pro bị cắt ở mép phải. Giữ nguyên bố cục trên máy tính; trên màn hình dưới 640px, xếp các thẻ theo chiều dọc và làm nút rộng toàn bộ.

So sánh điều đó với "trang giá trông tệ trên điện thoại". Yêu cầu đầu tiên có thể được thực hiện và kiểm tra trong một lần; yêu cầu thứ hai mời gọi một thiết kế lại mà bạn không yêu cầu.

Ảnh chụp màn hình rất hữu ích. Nếu trình xây dựng của bạn chấp nhận hình ảnh, hãy đính kèm một ảnh và khoanh vùng vấn đề.

Bước 3: Lên kế hoạch trước với thay đổi lớn

Với bất cứ thứ gì ảnh hưởng đến nhiều phần của ứng dụng — mô hình dữ liệu mới, thanh toán, vai trò người dùng — hãy yêu cầu một kế hoạch trước khi mã thay đổi:

Chưa thay đổi mã. Tôi muốn người dùng thuộc về các nhóm và chỉ xem các dự án của nhóm mình. Hãy lập kế hoạch thay đổi: những bảng, trang và route API nào thay đổi, điều gì xảy ra với dữ liệu của người dùng hiện có, và bạn sẽ xây dựng theo thứ tự nào.

Hãy đọc kế hoạch. Nếu nó sai, sửa một kế hoạch rẻ hơn nhiều so với việc gỡ một bản đã xây dựng.

Bước 4: Nói rõ những gì không được thay đổi

Các công cụ AI đôi khi "dọn dẹp" những thứ bạn không yêu cầu. Hãy bảo vệ những gì đang hoạt động:

Thêm bộ lọc ngày vào bảng đơn hàng. Không thay đổi các cột, kiểu dáng hoặc nút xuất của bảng.

Với các quy tắc áp dụng ở mọi nơi — màu thương hiệu, giọng điệu, "không bao giờ xóa dữ liệu mà không xác nhận" — hãy đặt chúng trong một tệp ghi chú dự án hoặc cài đặt kiến thức mà AI đọc mỗi lần, thay vì lặp lại chúng.

Bước 5: Kiểm tra nhiều hơn chính thay đổi

Sau mỗi prompt, hãy kiểm tra:

• Chính thay đổi. Nó có làm đúng những gì bạn yêu cầu, trên máy tính và điện thoại không?
• Những thứ lân cận. Các phần khác trên cùng trang, và các luồng dùng cùng dữ liệu.
• Đường đi quan trọng. Đăng ký, đăng nhập, hành động chính, thanh toán. Một lượt kiểm tra ba mươi giây sau mỗi thay đổi lớn sẽ phát hiện phần lớn lỗi sớm.

Nếu có điều gì không ổn, hãy báo cáo thật chính xác — xem cách viết báo cáo lỗi tốt.

Bước 6: Quay lại thay vì chồng thêm

Khi một thay đổi làm hỏng thứ gì đó và bản sửa đầu tiên không hiệu quả, hãy dừng lại. Mỗi "bản sửa" thêm được xây trên một trạng thái hỏng, và các vấn đề cộng dồn lên.

Thay vào đó:

1. Quay lại phiên bản hoạt động gần nhất (một checkpoint hoặc commit Git).
2. Tìm xem prompt đã không rõ ràng ở đâu.
3. Thử lại với một yêu cầu nhỏ hơn hoặc rõ ràng hơn.

Thay đổi đó làm hỏng chức năng lưu bản nháp. Tôi đã quay lại. Lần này: chỉ thêm chỉ báo tự động lưu, dưới dạng chữ trên thanh tiêu đề. Không thay đổi cách lưu bản nháp.

Bước 7: Biết khi nào nên xây lại

Xây lại từ đầu sẽ loại bỏ rất nhiều chi tiết đang hoạt động. Điều đó chỉ đáng làm khi:

• Ý tưởng sản phẩm đã thay đổi hoàn toàn.
• Cấu trúc nền tảng không thể hỗ trợ những gì bạn cần — ví dụ, nó được xây như một trang tĩnh và bây giờ cần tài khoản và cơ sở dữ liệu.
• Dự án vẫn còn gần như trống.

Khi bạn xây lại, hãy liệt kê những thứ cần giữ: tên, màu sắc, nội dung, những phần người dùng thích.

Ví dụ về prompt

Trước khi tiếp tục, hãy tóm tắt cách ứng dụng hiện hoạt động: các trang, dữ liệu nó lưu trữ, và bất cứ điều gì bạn cho là dễ vỡ.

Tôi muốn thêm đặt lịch định kỳ. Phiên bản nhỏ nhất mà vẫn hữu ích là gì? Hãy đề xuất thành ba thay đổi riêng biệt để chúng ta thực hiện từng cái một.

Xem xét ba thay đổi gần nhất xem có cái nào có thể làm hỏng luồng thanh toán không. Chưa chỉnh sửa gì.

Lỗi thường gặp

• Mười yêu cầu trong một prompt. Một số được làm, một số làm dở, và bạn không biết cái nào là cái nào.
• Phản hồi mơ hồ. "Nó bị hỏng" hay "làm cho nó tốt hơn" chỉ tạo ra phỏng đoán.
• Không bao giờ kiểm tra những thứ lân cận. Thay đổi một thành phần dùng chung làm hỏng ba trang khác.
• Sửa cái đã sửa. Khi đã sâu bốn prompt vào một lỗi, hãy quay lại.
• Lặp lại ngữ cảnh mỗi lần thay vì giữ các quy tắc cố định trong ghi chú dự án.
• Xây lại khi bị kẹt. Hầu hết những lúc "bắt đầu lại" thực ra chỉ cần "quay lại hai bước".

Danh sách kiểm tra

• Một mục tiêu cho mỗi prompt.
• Tôi mô tả những gì tôi thấy và điều gì nên xảy ra.
• Thay đổi lớn có kế hoạch trước khi có bất kỳ mã nào.
• Tôi nói rõ những gì không được thay đổi.
• Sau mỗi thay đổi, tôi kiểm tra nó, các phần lân cận và đường đi quan trọng.
• Tôi lưu checkpoint hoặc commit sau mỗi thay đổi đang hoạt động.
• Khi một bản sửa thất bại, tôi quay lại thay vì chồng thêm bản sửa.
• Các quy tắc cố định nằm trong ghi chú dự án mà AI đọc mỗi lần.

Cải tiến trên Mythex

Mythex được xây dựng quanh vòng lặp này:

• Các chế độ Plan, Build và Ask. Plan thảo luận cách tiếp cận trước khi chỉnh sửa; Ask trả lời mà không thay đổi mã; Build thực hiện thay đổi. Xem Chat.
• Checkpoint. Sau mỗi lượt thành công, Mythex lưu một checkpoint git; Revert to this point sẽ quay lại. Bạn cũng có thể sửa một tin nhắn trước đó và Discard & resend để thử một prompt khác từ thời điểm đó. Xem Cải tiến mà không cần xây lại.
• Kiến thức. Project settings → Knowledge chứa các ghi chú cố định mà agent tuân theo trong mỗi tin nhắn.
• /test yêu cầu agent nhấp qua bản xem trước như một người dùng sau một thay đổi lớn.

Các yêu cầu nhỏ hơn cũng tốn ít credit hơn. Về cách viết chính các prompt, xem cách viết prompt cho trình xây dựng ứng dụng AI; khi có lỗi xảy ra, xem cách gỡ lỗi ứng dụng do AI xây dựng.

Câu hỏi thường gặp