Tôi đã xây dựng sản phẩm bằng AI—cách cải tiến mà không làm hỏng những gì đang hoạt động

Tìm hiểu thêm về cách làm việc với các mô hình trong tài liệu Ailoot.

Vì sao công việc tốn kém nhất lại bắt đầu sau khi ra mắt?#

Bạn xây một ứng dụng trong một buổi tối, đăng liên kết và gửi cho bạn bè. Nó hoạt động. Rồi một tuần sau, người dùng thật đầu tiên xuất hiện, nhấp sai một thứ gì đó và một nửa tính năng ngừng hoạt động. Bạn nhờ Claude sửa—nó sửa được một thứ nhưng lại làm hỏng thứ khác. Nghe quen không?

Và đây là lúc câu hỏi chính xuất hiện: sau khi ra mắt sản phẩm, bạn phải làm gì khi sự phấn khích trước nguyên mẫu đầu tiên chạy được đã qua và bạn vẫn phải tìm cách duy trì nó? Có thể gọi đây là vibe coding dành cho người trưởng thành. Xây dựng là niềm hứng khởi và tốc độ. Bảo trì đòi hỏi sự bình tĩnh: bạn hiểu mình đang thay đổi gì và kiểm soát được thay đổi đó. Hầu hết mọi người thất bại ở phần thứ hai vì chẳng ai chuẩn bị cho họ.

Một nghiên cứu trong ngành đã phân tích hơn một triệu thay đổi mã từ 2,444 nhóm và tính xem tiền chi cho phát triển AI thực sự đi đâu. Bức tranh như sau:

Hướng dẫn “Chi phí ẩn của vibe coding” giải thích các con số này chi tiết hơn. Ở đó, câu hỏi là bạn đang trả tiền cho những gì. Còn ở đây, câu hỏi khác: 44 xu trong mỗi đô la được dùng để sửa lỗi—và toàn bộ bài viết này nói về cách ngăn tỷ lệ đó tăng lên. Công việc giữ nó trong tầm kiểm soát được gọi là bảo trì.

Sự khác biệt giữa người làm vibe coding theo cách của người trưởng thành và người chỉ trông chừng mạng nơ-ron thể hiện sau khi ra mắt. Codebase của người thứ nhất phát triển, họ cải tiến sản phẩm mà không làm hỏng gì. Một tháng sau, sản phẩm của người thứ hai đã trở thành một mớ lộn xộn rò rỉ khắp nơi mà họ sợ đụng vào. Tiếp theo, tôi sẽ giải thích cách để thuộc nhóm đầu tiên.

Những gì thực sự hỏng: 5 thảm họa sau khi ra mắt#

Đây là các báo cáo hậu sự cố công khai về những sản phẩm thực tế được xây bằng AI, có số liệu và ngày tháng. Hãy xem chúng như bản đồ bãi mìn—mỗi quả mìn đã phát nổ với ai đó, và cách tránh nó đã rõ.

Cả năm trường hợp đều có cùng nguyên nhân gốc rễ. Theo mặc định, AI làm cho mọi thứ hoạt động ngay lúc này chứ không an toàn một tháng sau dưới tải cao. Bạn không thể thấy sự khác biệt khi phát triển trên máy tính của mình. Nó trở nên rõ ràng khi người lạ đầu tiên có ý đồ xấu xuất hiện.

Vấn đề không nằm ở việc không tự viết mã—nhiều người làm việc theo cách này. Vấn đề là không hỏi: “Cơ sở dữ liệu đã được bảo mật chưa?” Tiếp theo, tôi sẽ cho bạn xem một prompt có thể đặt câu hỏi này thay bạn.

Lưới an toàn đầu tiên là git và khả năng quay lại “như hôm qua”#

Khi Claude làm hỏng thứ gì đó, bạn cần một nút “đưa nó trở lại như hôm qua”. Về mặt kỹ thuật, nút đó gọi là git và nó đơn giản hơn bạn nghĩ.

Ba thuật ngữ người không phải lập trình viên cần hiểu:

1. Repository — thư mục dự án của bạn được lưu trên đám mây (thường là GitHub). Đây là bản sao của toàn bộ mã, không chỉ nằm trên máy tính của bạn.
2. Commit — một điểm để quay lại. Về cơ bản, bạn đang nói với mã rằng “lưu ở trạng thái này”. Mỗi commit là một dấu mốc để bạn có thể quay về.
3. Deploy — triển khai. Mã được lưu cục bộ trên máy tính và chỉ hoạt động với bạn. Deploy gửi mã đến máy chủ bên ngoài để mọi người đều có thể sử dụng.

Chỉ cần có các điểm commit gần đây, bạn có thể hoàn tác mọi thứ bị hỏng chỉ bằng một câu. Đúng nghĩa đen.

Tôi đã làm hỏng thứ gì đó—hôm qua mọi thứ còn hoạt động, nhưng hôm nay thì không. Hãy tìm commit gần nhất khi mọi thứ vẫn ổn, cho tôi xem những gì đã thay đổi kể từ đó và khôi phục dự án về trạng thái đó.

Hãy áp dụng ngay hai quy tắc sau, trước khi người khác nhìn thấy sản phẩm:

• Repository phải ở chế độ riêng tư. Không công khai. Nếu không, bất kỳ ai cũng có thể đọc mã của bạn và mọi thứ bên trong.
• Đưa tệp chứa thông tin bí mật vào danh sách bỏ qua. Key, mật khẩu và thông tin đăng nhập cơ sở dữ liệu được lưu trong một tệp riêng (thường là .env), và tệp đó không bao giờ được đưa vào repository. Thêm một dòng cho .env trong .gitignore, như vậy thông tin bí mật vẫn ở chỗ bạn.

Có hướng dẫn riêng về cách khôi phục thay đổi an toàn trong Claude Code: Cách khôi phục thay đổi trong Claude Code. Không có điểm để quay lại thì bạn đang đi trên dây mà không có lưới an toàn, và sớm muộn gì cũng ngã.

/rewind khôi phục những gì, và không khôi phục những gì?#

Claude Code chụp snapshot trạng thái trước mỗi thay đổi nó thực hiện. Lệnh /rewind (hoặc nhấn Esc hai lần) khôi phục cả tệp lẫn cuộc trò chuyện về một điểm đã chọn. Rất tiện: nếu bạn làm hỏng một tính năng năm phút trước, bạn có thể quay lại thời điểm cách đây năm phút.

Nhưng có một cái bẫy khiến người mới mất dữ liệu. /rewind không khôi phục mọi thứ:

Chính Anthropic nói rõ: snapshot là nút “undo” cục bộ, còn git là lịch sử lâu dài. Snapshot bổ trợ cho việc kiểm soát phiên bản nhưng không thay thế nó.

Điều cần nhớ trong thực tế đối với người không phải lập trình viên: /rewind sẽ cứu bạn khi “Claude vừa làm hỏng một tính năng”. Nhưng nếu nó đã xóa một hàng trong cơ sở dữ liệu hoặc tải mã lên đám mây, chỉ git và bản sao lưu cơ sở dữ liệu mới khôi phục được. Vì vậy hãy giữ cả hai lớp: snapshot để hoàn tác nhanh, commit để lưu lịch sử lâu dài của dự án.

Làm thế nào để cải tiến mà không làm hỏng những gì đang hoạt động?#

Cứ hai người thì có một người mắc vào vòng lặp này. Bạn yêu cầu AI sửa một lỗi nhỏ. Nó đề xuất một thay đổi hợp lý. Thay đổi đó làm hỏng thứ khác. Bạn yêu cầu nó sửa vấn đề mới, rồi lại phát sinh thêm hai vấn đề. Cứ thế tiếp diễn.

Vòng lặp này xảy ra vì vibe coding không mang tính xác định. Cùng một prompt có thể tạo ra hai đoạn mã khác nhau ở hai lần chạy. Vì vậy, mỗi lần chỉnh sửa đều có thể âm thầm làm lệch logic xung quanh: ngưỡng chiết khấu chuyển từ 10 lên 12 phần trăm, hoặc quy tắc xác thực đổi cách hoạt động—mà bạn không kiểm tra và cũng chẳng có một cảnh báo nào. Hiện tượng này gọi là trôi dạt logic, và nó âm thầm phá hỏng đúng những thứ mang lại doanh thu: giá cả, quyền truy cập và thanh toán.

Có một quy tắc để ngăn trôi dạt, đủ đơn giản để dán lên tường: đừng commit đoạn mã mà bạn không thể giải thích cho người khác từng chữ một.

Trong thực tế, quy tắc này trở thành một khung lệnh có sẵn để dùng trước mọi thay đổi đối với mã đang hoạt động. Nó khiến AI làm từng bước nhỏ và cho bạn thấy chính xác những gì đã thay đổi.

Trước khi thay đổi mã, hãy làm những việc sau:

Lưu trạng thái hiện tại đang hoạt động thành một điểm khôi phục riêng (commit).

Mô tả bằng lời chính xác những gì bạn định thay đổi và trong những tệp nào.

Thực hiện thay đổi nhỏ nhất có thể—chỉ làm những gì giải quyết yêu cầu của tôi, không thêm gì khác.

Cho tôi xem những gì đã thay đổi và giải thích từng thay đổi để tôi có thể giải thích lại cho người khác.
Đừng đụng đến logic về giá, quyền truy cập hoặc thanh toán trừ khi tôi yêu cầu.

Một nguyên tắc khác giúp tiết kiệm hàng tuần là giữ kỷ luật về phạm vi nhiệm vụ. Một điểm đau, một thay đổi, triển khai nhanh. Đừng yêu cầu AI viết lại một nửa dự án chỉ trong một prompt. Đôi khi các nhà phát triển chuyên nghiệp bắt đầu xây cả một Uber trong khi thứ họ cần chỉ là một nút—rồi kéo dài công việc đó nhiều tháng. Bạn không cần làm vậy.

Mọi điều tôi mô tả đều dựa trên một yếu tố: quản lý ngữ cảnh. Để AI không làm hỏng logic bên cạnh, nó cần ghi nhớ các quy tắc của dự án.

Làm thế nào để kiểm tra thay đổi trước khi phát hành?#

Giữa “chạy được trên máy tính của tôi” và “chạy được với mọi người” có một bước trung gian mà người mới thường bỏ qua: bản sao thử nghiệm. Đây là một snapshot riêng của môi trường production để kiểm tra thay đổi trước khi người thật nhìn thấy nó. Chu trình làm việc như sau:

1. Tự xây dựng và kiểm tra thay đổi (development).
2. Deploy thay đổi lên staging—bản sao của production nhưng không có người dùng thật.
3. Chạy các tình huống chính và đảm bảo không có gì thay đổi.
4. Chỉ lúc này mới deploy lên production.

Vì sao việc này quan trọng sau khi ra mắt: mỗi lần phát hành đều có rủi ro. Một thay đổi mã nhỏ có thể làm hỏng đăng nhập tài khoản. Thiếu một thiết lập cũng có thể khiến toàn bộ sản phẩm ngừng hoạt động. Staging phát hiện các vấn đề này mà không gây hậu quả; còn trên production, bạn sẽ mất khách hàng.

Để không phải tự kiểm tra mọi thứ mỗi lần, hãy dùng prompt để AI so sánh cách hoạt động của phiên bản mới với phiên bản cũ ở những khu vực quan trọng.

Tôi sắp triển khai một thay đổi. Hãy lần lượt kiểm tra các tình huống quan trọng của sản phẩm và xác nhận từng tình huống vẫn hoạt động như trước:

Đăng ký và đăng nhập người dùng mới.

Thanh toán và cấp quyền truy cập sau khi thanh toán.

Quyền truy cập—người dùng thông thường không thể xem dữ liệu của người khác hoặc khu vực quản trị.

Các con số quan trọng trong logic kinh doanh (giá, chiết khấu, giới hạn) không thay đổi.
Nếu có bất kỳ điều gì hoạt động khác với phiên bản trước, hãy dừng lại và cho tôi thấy chính xác những gì đã thay đổi.

Thông tin bí mật của bạn đang ở đâu? Lỗ hổng lớn nhất của người mới#

Tôi sẽ giải thích chi tiết cái bẫy lớn nhất này vì nó khiến nhiều sản phẩm sụp đổ hơn bất cứ thứ gì khác. Khi AI viết mã, cách dễ nhất là đặt key vào nơi nó sẽ hoạt động ngay—trực tiếp trong mã của trang mở trên trình duyệt. Bạn sẽ không nhận ra sự khác biệt trong lúc phát triển. Nhưng bất kỳ ai cũng có thể đọc mọi thứ được gửi đến trình duyệt chỉ bằng cách mở công cụ dành cho nhà phát triển.

Nhà sáng lập có khách hàng bị tính phí $87,500 sau đó nói rằng chỉ một prompt thôi cũng có thể ngăn được việc đó. Các khoản phí cuối cùng đã được hoàn lại, nhưng phí không hoàn lại và sự an tâm đã mất thì vẫn còn. Đây là prompt đó.

Kiểm tra toàn bộ dự án và đảm bảo không có secret key nào lọt vào trình duyệt:

Tìm tất cả key của cơ sở dữ liệu, hệ thống thanh toán và dịch vụ bên ngoài.

Đảm bảo mỗi key chỉ được lưu trên máy chủ, trong các biến môi trường, không nằm trong mã của trang.

Kiểm tra lịch sử dự án—trước đây có key nào vô tình lọt vào đó không?
Cho tôi danh sách tất cả những nơi bạn tìm thấy thông tin bí mật và việc cần làm với từng nơi.

Một cái bẫy khác nằm ngay gần đó là chỉ kiểm tra quyền truy cập ở phía trình duyệt. Nếu sản phẩm quyết định có “hiển thị khu vực quản trị” hay không trong mã trang, bất kỳ ai cũng có thể vượt qua quyết định đó. Quyền truy cập luôn phải được kiểm tra trên máy chủ. Cơ sở dữ liệu chỉ được trả dữ liệu cho người có quyền—đó là mục đích của row-level security (RLS), và cần bật nó trên mọi bảng.

Trước khi bán quyền truy cập hoặc cho người khác vào, hãy thực hiện kiểm tra bảo mật tổng quát cho sản phẩm.

Xem xét dự án như một kẻ tấn công và tìm các lỗ hổng bảo mật:

Có secret key nào được lưu trong mã gửi đến trình duyệt hoặc trong lịch sử dự án không?

Row-level security (RLS) đã được bật trên mọi bảng cơ sở dữ liệu chưa, và quyền truy cập có được kiểm tra trên máy chủ thay vì chỉ trong trình duyệt không?

Đã cấu hình sao lưu cơ sở dữ liệu tự động chưa, và tôi đã từng kiểm tra xem có thể khôi phục từ bản sao lưu đó chưa?

Cơ sở dữ liệu production có được cách ly khỏi môi trường chạy tác tử AI không?
Với từng mục, hãy cho tôi biết mọi thứ đều ổn hay chính xác cần sửa gì.

Có hướng dẫn đầy đủ riêng về bảo mật cho vibe coding: Cách bảo mật ứng dụng được tạo bằng vibe coding. Quy tắc rất đơn giản: mặc định hãy coi mọi thứ AI làm là không an toàn cho đến khi bạn kiểm tra và xác nhận điều ngược lại.

Nên hosting sản phẩm ở đâu: các bậc hosting#

Bạn không cần thuê máy chủ riêng và tự cấu hình ngay lập tức—ban đầu đây là việc phức tạp, sẽ ngốn thời gian của bạn. Có một bậc thang để leo lên khi sản phẩm phát triển:

1. Hosting miễn phí (ví dụ Vercel)—dành cho bản thân, thử nghiệm và các dự án nhỏ. Cách này phù hợp nếu nền tảng có sẵn cho đối tượng người dùng của bạn và bạn không lưu dữ liệu cá nhân của mọi người.
2. Nền tảng deploy bằng một lệnh (Railway)—khi bạn có backend và cơ sở dữ liệu. Bạn deploy bằng một lệnh, không cần cấu hình máy chủ. Rào cản ban đầu rất thấp.
3. Máy chủ chuyên dụng của riêng bạn—khi tải cao và bạn cần toàn quyền kiểm soát. Hãy chuyển sang lựa chọn này sau, khi đã chạm giới hạn của nền tảng.

Với người không phải lập trình viên vừa ra mắt sản phẩm, lựa chọn dễ nhất là nền tảng deploy bằng một lệnh mà không phải tự cấu hình máy chủ. Sau này hãy chuyển sang máy chủ riêng. Nếu muốn đi theo lộ trình này với ví dụ cụ thể, hãy xem hướng dẫn deploy dự án vibe coding lên máy chủ riêng bằng Coolify.

Khi nào nên tách ứng dụng, cơ sở dữ liệu và bản sao lưu?#

Có ba thứ không nên để chung một chỗ: ứng dụng, cơ sở dữ liệu và bản sao lưu. Khi số lượng người dùng còn ít, mọi thứ ở cùng nhau cũng ổn. Nhưng có một dấu hiệu rõ ràng cho biết đã đến lúc tách chúng ra.

• Đặt ứng dụng và cơ sở dữ liệu trên các máy khác nhau. Dấu hiệu: khi tải cao điểm, CPU và bộ nhớ duy trì trên 70–80 phần trăm, các yêu cầu chậm lại, ứng dụng và cơ sở dữ liệu tranh giành cùng một tài nguyên. Sau khi tách, bạn có thể tăng cường cơ sở dữ liệu mà không đụng đến ứng dụng, và ngược lại.
• Tuân theo quy tắc sao lưu 3-2-1. Ba bản sao dữ liệu, trên hai loại phương tiện khác nhau, một bản ở ngoài địa điểm chính. Cách này bảo vệ bạn khỏi sự cố phần cứng và ransomware. Điều quan trọng là sao lưu phải tự động.

Tần suất sao lưu phụ thuộc vào mức độ thiệt hại nếu mất dữ liệu trong vài giờ. Với dịch vụ thuê bao mà mất một giờ bản ghi thanh toán là không chấp nhận được, chu kỳ backup phải ngắn hơn một giờ, hoặc cần transaction log và khôi phục theo thời điểm (PITR) đã xác minh. Chọn theo mất dữ liệu tối đa chịu được và thử thời gian khôi phục dịch vụ riêng. Với blog thì sao lưu mỗi ngày một lần là đủ. Cách nghĩ rất đơn giản: hãy quyết định lượng dữ liệu bạn có thể chấp nhận mất rồi cấu hình sao lưu cho phù hợp.

Giúp tôi quyết định đã đến lúc chuyển sản phẩm sang hạ tầng nghiêm túc hơn chưa. Hãy kiểm tra và hỏi tôi về từng điểm:

CPU và bộ nhớ tải ở mức nào vào giờ cao điểm—mức sử dụng có duy trì trên 70–80 phần trăm không?

Cơ sở dữ liệu và ứng dụng nằm trên cùng một máy hay trên các máy khác nhau?

Đã cấu hình sao lưu cơ sở dữ liệu tự động chưa, và tôi đã thử khôi phục từ bản sao lưu chưa?

Có bản sao môi trường riêng (staging) để kiểm tra trước khi triển khai không?
Dựa trên kết quả, hãy đưa ra đề xuất rõ ràng: giữ nguyên điều gì, tách riêng điều gì trước và vì sao.

Còn một câu hỏi riêng: nên dùng cơ sở dữ liệu được quản lý hay tự quản lý. Với một nhóm nhỏ, cơ sở dữ liệu được quản lý gần như luôn là lựa chọn tốt hơn: tự quản lý thì phần cứng rẻ hơn nhưng lại ngốn hàng giờ bảo trì. Nếu bạn làm một mình và sản phẩm của bạn không phải là hạ tầng, số giờ đó đáng giá hơn khoản chênh lệch giá máy chủ.

Làm thế nào để tự động hóa việc bảo trì?#

Bảo trì thủ công rất mệt mỏi. Bạn có thể giảm bớt gánh nặng theo hai cách: giám sát và tác tử tuần tra.

Giám sát dùng hai công cụ khác nhau cho hai công việc khác nhau:

1. “Website có đang hoạt động không?”—công cụ giám sát uptime (ví dụ UptimeRobot). Nó ping sản phẩm sau mỗi vài phút và gửi cảnh báo nếu sản phẩm ngừng hoạt động. Có gói miễn phí.
2. “Cụ thể thì cái gì đã hỏng?”—công cụ theo dõi lỗi (ví dụ Sentry). Nó thu thập lỗi bên trong ứng dụng và cho biết lỗi xảy ra ở đâu, vì sao.

Công cụ đầu tiên phát hiện sản phẩm bị ngừng hoạt động. Công cụ thứ hai cho biết tính năng nào gặp lỗi và vì sao. Kết hợp lại, chúng trả lời câu hỏi: “Tôi có biết sự cố xảy ra trước khi khách hàng viết thư cho bộ phận hỗ trợ không?”

Cấp độ tự động hóa thứ hai là tác tử tuần tra. Hãy hình dung một công ty bất động sản: lúc bảy giờ sáng, tác tử AI đọc yêu cầu trên website, thấy biểu mẫu đặt chỗ bị hỏng, tìm nguyên nhân trong mã và mang đến cho bạn bản sửa sẵn sàng cùng lời giải thích. Bạn xem xét và nói “được”—nó sẽ deploy. Thứ tự rất quan trọng: trước tiên giải quyết vấn đề của người dùng (cấp quyền truy cập, xin lỗi), sau đó điều tra nguyên nhân và vấn đề tiền bạc.

Thêm một quy tắc về quyền truy cập cơ sở dữ liệu production của AI: cấp cho nó tài khoản chỉ đọc và giấu dữ liệu cá nhân sau một lớp trung gian để tác tử nhìn thấy “tên” thay vì tên thật của một người. Như vậy, kể cả khi mắc lỗi, về mặt vật lý nó cũng không thể xóa hoặc làm hỏng dữ liệu production. Sự cố trong bảng ở trên, trong đó một tác tử xóa sạch cơ sở dữ liệu production, chính là ví dụ về việc thiếu hạn chế này. Hướng dẫn Cần làm gì nếu AI xóa cơ sở dữ liệu của bạn giải thích cách xử lý khi thảm họa đã xảy ra.

Khi nào nên đóng một sản phẩm?#

Phần thường bị đánh giá thấp nhất của việc bảo trì là biết khi nào nên ngừng bảo trì. Ai xây dựng nhiều cũng có một nghĩa địa dự án: tạo ra một sản phẩm, mày mò một thời gian rồi bỏ dở. Điều đó bình thường, và không phải thất bại. Thất bại là cố kéo lê nhiều tháng một thứ không ai sử dụng chỉ vì tiếc thời gian đã bỏ ra.

Bạn có thể dùng những mốc sau để ra quyết định:

1. Hai tuần—đủ để biết một ý tưởng có hiệu quả hay không. Nếu những người dùng thật đầu tiên quay lại, hãy tiếp tục. Im lặng cũng là một câu trả lời.
2. Ba tháng—giới hạn cứng. Nếu sản phẩm chưa thành công sau ba tháng, hãy đóng nó lại. Với tốc độ của vibe coding, dành sáu tháng thử nghiệm một ý tưởng là quá lâu.

Đóng một dự án rất khó về mặt tâm lý, vì vậy hãy xem đó là một quyết định chứ không phải cảm xúc. Buông bỏ một dự án mà bạn đã đầu tư cũng giống như sa thải một nhân viên không thể làm được việc: thật khó chịu, nhưng giữ họ lại tốn kém hơn để họ ra đi.

Bảo trì là công việc giúp sản phẩm tiếp tục tồn tại và hữu ích với mọi người. Mọi thứ khác—git, sao lưu, giám sát—chỉ là công cụ giúp bạn đạt đến thời điểm sản phẩm bắt đầu phục vụ bạn mỗi ngày.

Xây dựng một sản phẩm bằng AI trong một buổi tối mới chỉ là một nửa công việc. Giữ cho nó tiếp tục hoạt động và an toàn khi phát triển—đó là ý nghĩa của vibe coding dành cho người trưởng thành.

Bước tiếp theo của bạn—Ailoot.