Từ bản phác trên giấy ăn đến ứng dụng hoạt động: Cách xây phần mềm từ một ý tưởng với AI
Ai cũng có ý tưởng về ứng dụng. Hầu hết chúng chết ở giai đoạn “cái đó hay đấy” — không phải vì ý tưởng tệ, mà vì khoảng cách giữa “tôi muốn cái này tồn tại” và “cái này tồn tại” trước đây đòi hỏi phải thuê lập trình viên hoặc học code. Cả hai đều không xảy ra vào một buổi chiều thứ Ba.
Khoảng cách đó nhỏ hơn bao giờ hết. Các công cụ tạo ứng dụng AI cho phép bạn mô tả điều mình muốn bằng ngôn ngữ đời thường và nhận lại một ứng dụng hoạt động được — cơ sở dữ liệu, giao diện, logic, tất cả. Bạn có thể xây một ứng dụng từ một ý tưởng trong vài giờ, không phải vài tháng.
Nhưng “mô tả điều bạn muốn” đang gánh rất nhiều ý nghĩa trong câu đó. Phần khó chưa bao giờ là viết code. Mà là tìm ra rốt cuộc bạn thực sự cần gì.
Bắt đầu với động từ, không phải danh từ
Hầu hết mọi người mô tả ý tưởng ứng dụng của mình như một danh từ: “Nó giống Uber cho người dắt chó đi dạo” hoặc “Nó là công cụ quản lý dự án cho freelancer.” Đó là một lời chào hàng, không phải một bản đặc tả. Một công cụ AI chẳng làm được gì nhiều với nó vì nó mô tả một danh mục, không phải một hành vi.
Hãy bắt đầu với những gì người ta sẽ làm với ứng dụng của bạn. Viết ra ba đến năm hành động:
- “Người dắt chó mở ứng dụng và thấy các lượt đặt lịch hôm nay của họ”
- “Chủ chó chọn một khung giờ và đặt một buổi dắt chó đi dạo”
- “Người dắt chó đánh dấu buổi dắt chó đã hoàn thành và chủ chó nhận được một tấm ảnh”
Những thứ đó là xây được. Mỗi cái ánh xạ tới một màn hình, một bảng cơ sở dữ liệu, và một mẩu logic. Công cụ AI không cần lời chào hàng của bạn — nó cần danh sách việc cần làm của bạn.
Carlos, một huấn luyện viên cá nhân ở Mexico City, muốn một ứng dụng để khách hàng đặt buổi tập và theo dõi bài tập của họ. Lần thử đầu tiên của anh là: “Xây cho tôi một ứng dụng thể hình.” Kết quả là một thư viện bài tập chung chung với các giáo án có sẵn — chẳng giống chút nào với thứ anh cần.
Lần thử thứ hai của anh liệt kê những gì anh thực sự làm mỗi ngày:
- Khách hàng xem các khung giờ trống trong tuần
- Họ đặt một khung giờ và nhận xác nhận qua WhatsApp
- Sau mỗi buổi tập, Carlos ghi lại những gì họ đã làm (bài tập, số set, mức tạ)
- Khách hàng mở lịch sử của họ và xem tiến trình theo thời gian
Mô tả thứ hai đó tạo ra một thứ anh có thể dùng được chỉ trong vài giờ.
Xây một màn hình trước
Bạn có thể có mười tính năng trong đầu. Hãy xây một cái.
Hãy chọn màn hình gần nhất với vấn đề cốt lõi — thứ mà ứng dụng của bạn làm được mà không gì khác làm được, hoặc thứ mọi người sẽ dùng thường xuyên nhất. Với Carlos, đó là màn hình đặt lịch. Mọi thứ còn lại (ghi nhật ký tập luyện, biểu đồ tiến trình, thông báo) có thể tính sau.
Khi bạn bắt đầu với một màn hình, ba điều tốt xảy ra.
Bạn học được cách công cụ tư duy. Mỗi công cụ AI đều có quan điểm riêng về bố cục, cấu trúc dữ liệu, và các mẫu tương tác. Xây một màn hình dạy bạn cách giao tiếp với nó — mô tả nào tạo ra kết quả tốt và mô tả nào cần chi tiết hơn.
Bạn có ngay một thứ dùng được. Một màn hình hoạt động hữu ích hơn nhiều so với mười màn hình làm dở dang. Carlos đã có khách hàng đặt buổi tập chỉ trong vòng hai giờ. Phần ghi nhật ký tập luyện đến ba ngày sau. Nếu anh cố xây mọi thứ cùng lúc, có lẽ anh vẫn còn đang chỉnh sửa.
Bạn khám phá ra mình thực sự cần gì. Những tính năng bạn nghĩ là quan trọng trước khi xây hiếm khi trùng với những tính năng thực sự quan trọng sau khi bạn bắt đầu dùng. Carlos cho rằng biểu đồ tiến trình sẽ là tính năng đỉnh nhất. Khách hàng của anh lại quan tâm hơn đến việc đổi lịch một buổi tập chỉ trong hai cú chạm.
Hãy mô tả như thể bạn đang giải thích cho một người bạn
Khi trò chuyện với một công cụ AI, hãy giả vờ bạn đang giải thích ứng dụng cho một người bạn sắp xây nó giúp bạn. Bạn sẽ không nói “triển khai một API đặt lịch theo chuẩn RESTful có phát hiện xung đột.” Bạn sẽ nói “khi ai đó chọn một khung giờ đã có người đặt, hãy hiển thị cho họ khung giờ trống gần nhất tiếp theo.”
Ngôn ngữ đời thường hiệu quả hơn ngôn ngữ kỹ thuật vì nó mô tả kết quả, không phải cách triển khai. AI tự tìm ra cách triển khai. Việc của bạn là cụ thể về những gì người dùng nhìn thấy và làm.
Một số mô tả hoạt động tốt:
- “Khi họ bấm ‘Đặt lịch’, hãy kiểm tra xem khung giờ còn trống không. Nếu còn, xác nhận nó. Nếu người khác đã giành mất, hiển thị một thông báo và đề xuất khung giờ trống gần nhất.”
- “Bảng điều khiển nên hiển thị ba con số ở trên cùng: tổng số khách hàng, số buổi tập tuần này, và doanh thu tháng này. Bên dưới đó, một danh sách các buổi tập hôm nay kèm tên khách hàng và giờ.”
- “Sau một buổi tập, tôi muốn gõ những gì chúng tôi đã làm — kiểu ‘squat 3x10 80kg, đẩy ngực 3x8 60kg’ — và lưu nó vào lịch sử của khách hàng đó.”
Khuôn mẫu trong từng cái: ai làm gì, khi nào, và chuyện gì xảy ra tiếp theo.
Dùng nó, rồi sửa nó
Phiên bản đầu tiên của bất cứ thứ gì cũng sẽ sai theo những cách bạn không thể đoán trước. Đó không phải thất bại — đó là quy trình. Lợi thế của việc xây bằng AI không phải là bạn làm đúng ngay lần đầu. Mà là việc sửa mọi thứ chỉ mất vài phút thay vì vài tuần.
Khi Carlos nhìn phiên bản đầu của màn hình đặt lịch, ba điều khiến anh khó chịu:
- Các khung giờ hiển thị theo khối 30 phút, nhưng buổi tập của anh dài 50 phút
- Không có cách nào để khách hàng hủy mà không phải nhắn trực tiếp cho anh
- Thông báo xác nhận bằng tiếng Anh, nhưng khách hàng của anh nói tiếng Tây Ban Nha
Mỗi lần sửa mất chưa đến mười phút. Anh mô tả vấn đề, công cụ điều chỉnh, và anh đi tiếp. Với một công ty phát triển truyền thống, bất kỳ một trong số này cũng sẽ là một phiếu hỗ trợ và một khoảng chờ.
Thói quen mấu chốt: hãy dùng chính ứng dụng của bạn trước khi cho ai đó xem. Bấm mọi nút. Điền mọi biểu mẫu. Thử làm cho nó hỏng. Những lỗi bạn tự tìm ra rẻ hơn nhiều so với những lỗi do người dùng tìm ra giúp bạn.
Cho một người không phải bạn xem nó
Một khi bạn đã dùng nó đủ để tin tưởng, hãy đưa nó cho một người dùng thật. Không phải năm. Không phải mười. Một người.
Carlos đưa đường link đặt lịch cho người khách hàng rành công nghệ nhất của mình trước. Cô ấy đặt một buổi tập, đổi lịch nó, rồi nhắn cho anh: “Em xem những gì mình đã tập tuần trước ở đâu?” Anh chưa xây phần xem lịch sử tập luyện. Nhưng giờ anh biết chính xác cần xây tính năng nào tiếp theo — không phải bằng cách đoán, mà bằng cách quan sát một người thật cố làm một việc thật và đụng phải bức tường.
Một người dùng cho bạn biết điều gì gây khó hiểu. Năm người dùng cho bạn biết điều gì được ưa thích. Bạn cần kiểu phản hồi thứ nhất trước khi kiểu thứ hai trở nên hữu ích.
Ra mắt trước khi bạn sẵn sàng
Ứng dụng của bạn không cần hoàn chỉnh mới trở nên hữu ích. Nó chỉ cần giải quyết một vấn đề đủ tốt để ai đó dùng nó thay cho thứ họ đang dùng hiện tại — mà thứ đó nhiều khả năng là một bảng tính, một nhóm WhatsApp, hoặc chẳng có gì cả.
Carlos ra mắt hệ thống đặt lịch của mình cho cả 15 khách hàng chỉ với ba tính năng: đặt một khung giờ, hủy một khung giờ, và xem các buổi tập sắp tới. Không ghi nhật ký tập luyện. Không biểu đồ tiến trình. Không tích hợp thanh toán.
Anh thêm những thứ đó trong những tuần tiếp theo, từng tính năng một, dựa trên điều khách hàng thực sự yêu cầu. Phần ghi nhật ký tập luyện được xây sau khi ba khách hàng cùng yêu cầu trong một tuần. Tích hợp thanh toán đến một tháng sau, khi Carlos nhận ra anh vẫn đang thu phí bằng tiền mặt và Venmo.
Sáu tuần sau buổi chiều thứ Bảy đầu tiên ngồi xây, anh đã có một ứng dụng mà 15 khách hàng trả tiền dùng hằng ngày. Nó xử lý đặt lịch, theo dõi bài tập, hiển thị tiến trình, và gửi nhắc lịch hẹn. Anh đã bỏ ra tổng cộng khoảng 20 giờ — rải rác qua các buổi tối và cuối tuần — và 0 đô cho việc phát triển.
Hệ thống trước đây của anh là một Google Calendar, một Google Sheet, và một danh sách phát quảng bá WhatsApp. Nó hoạt động được, nhưng lỗi đặt lịch xảy ra hằng tuần vì khách hàng hay quên kiểm tra lịch trước khi yêu cầu một khung giờ.
Ba sai lầm làm mọi người chậm lại
Cố xây nguyên cả thứ cùng một lúc. Bắt đầu với một màn hình. Làm cho nó hoạt động. Rồi thêm thứ tiếp theo. Việc phình to phạm vi giết chết nhiều ý tưởng ứng dụng hơn là code dở từng làm được.
Sao chép đối thủ thay vì mô tả quy trình làm việc của bạn. Nếu bạn mô tả ứng dụng của mình là “giống Calendly nhưng cho huấn luyện viên cá nhân”, bạn sẽ nhận được một bản sao Calendly với màu khác. Hãy mô tả chính quy trình làm việc của bạn và bạn sẽ nhận được một thứ phù hợp với cách bạn làm việc, chứ không phải cách Calendly quyết định rằng bạn nên làm.
Chờ đợi sự hoàn hảo. Phiên bản đầu tiên của bạn sẽ có những chỗ thô ráp. Cứ ra mắt nó. Bạn sẽ học được nhiều hơn từ vẻ mặt bối rối của một người dùng thật so với cả một tuần đánh bóng những màn hình chưa ai thử.
Rào cản thực sự chưa bao giờ nằm ở kỹ thuật
Trước khi các công cụ tạo ứng dụng AI tồn tại, bạn có ba lựa chọn nếu có một ý tưởng mà không biết lập trình: học code (vài tháng), thuê lập trình viên (hàng nghìn đô), hoặc buông bỏ ý tưởng (miễn phí). Hầu hết mọi người chọn cái thứ ba — không phải vì ý tưởng của họ tệ, mà vì hai cái còn lại đắt đỏ về thời gian hoặc tiền bạc.
Giờ đây bạn có thể xây một ứng dụng từ một ý tưởng trong một ngày. Không phải bản mẫu. Không phải mockup. Một ứng dụng hoạt động được với cơ sở dữ liệu, tài khoản người dùng, và logic thật. Rào cản không còn ở kỹ thuật nữa. Mà ở sự rõ ràng — bạn có mô tả được điều mình cần đủ cụ thể để một AI có thể xây nó không?
Nếu bạn giải thích được nó cho một người bạn, bạn xây được nó.
Nếu bạn đã ấp ủ một ý tưởng, hãy thử xây nó với Proyecta. Bắt đầu với một màn hình — màn hình quan trọng nhất — và xem điều gì xảy ra.