Từ hỗn loạn bảng tính đến những hiểu biết dựa trên AI: Kiểm tra thực tế mã hóa Vibe trong 30 ngày

Tại sao các nhà sáng lập không thể sống thiếu Excel—và tại sao họ nên

Thời gian đọc: 7 phút
Phù hợp cho: Những người xây dựng thử nghiệm phát triển AI, các nhà sáng lập mệt mỏi với mô hình tài chính thủ công

Vấn đề mà không ai nói về

Bước vào bất kỳ cuộc họp pitching nào, bạn sẽ chứng kiến cùng một cảnh: Một VC hỏi “Chuyện gì xảy ra nếu tỷ lệ churn giảm 2%?” Gương mặt nhà sáng lập trở nên trống rỗng. Câu trả lời nằm đâu đó trong một cơn ác mộng Excel 47 tab. Ba giờ săn lùng qua các công thức. Một lỗi nhập dữ liệu nhỏ. Một tham chiếu vòng tròn khiến mọi thứ sập đổ.

Đây không phải là một điểm kỳ quặc—đó là điều bình thường. Hầu hết các công ty giai đoạn đầu vẫn dựa vào bảng tính để dự báo tài chính, và các nhà sáng lập đều ghét trải nghiệm này. Toán học thì đơn giản nhưng đầy đau đớn: các mô hình phức tạp mất hàng ngày để xây dựng, hàng giờ để cập nhật, và chỉ trong tích tắc là có thể hỏng.

Vấn đề xứng đáng được cải thiện. Chính điều này đã truyền cảm hứng cho một nhà phát triển dành 30 ngày thử xây dựng một công cụ tư vấn tài chính bằng vibe coding và AI, đồng thời ghi lại mọi sai lầm, insight và bài học rút ra.

Thử nghiệm 30 ngày: Theo số liệu

Thiết lập:

• Thời gian: 30 ngày coding vibe liên tục
• Nền tảng: Môi trường phát triển dựa trên đám mây
• Tổng đầu tư: $127 tín dụng nền tảng
• Dòng mã tạo ra: ~3,500 (chủ yếu hỗ trợ AI)
• Các lần lặp lại và rollback: 73 lần

Kết quả:

• Số nhà sáng lập thể hiện quan tâm ban đầu: 23
• Số đăng ký thực tế: 2
• Hoàn tất onboarding: 3
• Sẵn sàng trả tiền: 1
• Doanh thu tạo ra: $0 (xác thực: cam kết $50/tháng)

Phạm vi:

• Người dùng mục tiêu: nhà sáng lập từ giai đoạn pre-seed đến Series A
• Vấn đề chính giải quyết: cập nhật mô hình tài chính mất hàng giờ
• Giải pháp thử nghiệm: tư vấn tài chính dựa trên AI
• Chỉ số chính theo dõi: độ chính xác tính toán

Tuần 1: Tuần trăng mật gặp thực tế

Ý tưởng ban đầu khá tham vọng: dashboard tài chính theo thời gian thực, đồng bộ dữ liệu mượt mà với phần mềm kế toán, lập kế hoạch kịch bản theo yêu cầu, xuất khẩu sẵn sàng cho nhà đầu tư trong vài giây. Thời gian dự kiến: 2-3 tuần để ra mắt.

Nhưng không phải vậy.

Tuần đầu tiên đã phơi bày ba sai sót nghiêm trọng:

Sai sót #1: Xử lý song song không hiệu quả
Gửi nhiều lệnh cùng lúc cho một AI tạo ra sự nhầm lẫn. Yêu cầu chế độ tối, sửa lỗi bug, và cải thiện hiệu suất trong cùng một prompt dẫn đến một sản phẩm Frankenstein không làm tốt bất kỳ điều gì. Cách khắc phục: từng lệnh một, chờ hoàn thành, rồi đánh giá kết quả.

Chi phí: 6 lần rollback, $23 tín dụng, 3 giờ bị mất

Sai sót #2: Độ phức tạp UI không đơn giản
Yêu cầu đơn giản “chế độ ban đêm” kích hoạt 47 thay đổi không mong muốn. Chữ trắng trên nền trắng. Nút không hiển thị. Phù hợp font yêu cầu chỉnh thủ công từng pixel. Việc triển khai UI mất thêm 3 tuần so với dự kiến.

Sai sót #3: Hướng dẫn mơ hồ tạo ra sai lầm đắt đỏ
Nói “làm cho nó trực quan hơn” mà không rõ ràng dẫn đến việc phải cấu trúc lại toàn bộ bố cục. Độ chính xác trở thành yếu tố quyết định giữa $2 các vòng lặp và $50 các vòng lặp. Một prompt chi tiết mô tả chính xác màu sắc, kích thước, vị trí đã loại bỏ sự mơ hồ.

Khoảnh khắc đột phá đến khi phát hiện ra một lệnh duy nhất biến đổi toàn bộ quy trình làm việc: “Đừng thay đổi gì mà không xác nhận hiểu biết của bạn với tôi trước.”

Cụm từ này đủ để tránh mất hơn $50 trong tín dụng lãng phí qua các vòng lặp không cần thiết.

Giai đoạn giữa: Khi mọi thứ bắt đầu hỏng

Các vấn đề phát sinh trong tuần thứ hai. Di chuyển với WiFi không ổn định khiến việc debug lỗi TypeScript gần như không thể trên thiết bị di động. Tính năng rollback trở nên vô cùng cần thiết—đôi khi phải revert tới 12 lần trong một ngày khi các tính năng thử nghiệm gây ra nhiều lỗi hệ thống.

Đến ngày 15, việc tiêu hao tín dụng đã tăng vọt. Tuần 1 tiêu tốn $34; Tuần 2 lên tới $93. Mỗi lần lặp lại tiêu tốn từ $2-5 tùy độ phức tạp. Điều này dẫn đến việc thiết lập giới hạn ngân sách hàng tuần: vượt quá sẽ tạm dừng để suy nghĩ chiến lược.

Khủng hoảng tính toán

Điểm ngoặt đến khi các tester phát hiện ra một lỗi nghiêm trọng: các phép tính tài chính sai khoảng 20%. Chi phí thu hút khách hàng hiển thị $47 khi câu trả lời đúng là $58.75—một chênh lệch có thể làm hỏng các vòng gọi vốn.

Nguyên nhân: AI đưa ra giả định không rõ ràng về thuật ngữ. “Churn hàng tháng” đôi khi mang ý nghĩa tỷ lệ hàng năm. Các phép tính giá trị khách hàng trọn đời dùng công thức tự chế thay vì phương pháp tiêu chuẩn.

Điều này dẫn đến một nguyên tắc quan trọng: Luôn xác nhận thủ công kết quả AI. Một bảng tính song song để kiểm tra trở thành tiêu chuẩn. Các prompt mơ hồ như “tính LTV” được thay thế bằng hướng dẫn chính xác từng bước:

Tính LTV như: (Doanh thu trung bình trên mỗi người dùng × Biên lợi nhuận gộp) / Tỷ lệ churn hàng tháng

Trong đó:

• Doanh thu trung bình trên mỗi người dùng = Tổng MRR / Khách hàng hoạt động
• Biên lợi nhuận gộp = (Doanh thu - COGS) / Doanh thu
• Tỷ lệ churn hàng tháng = Khách hàng churn trong tháng này / Khách hàng bắt đầu tháng

Hiển thị các bước tính từng bước.

Với độ chính xác cao, độ chính xác đã được cải thiện rõ rệt.

Phản hồi của người dùng thay đổi mọi thứ

Sau hai tuần xây dựng, nhóm thử nghiệm beta đầu tiên đưa ra phản hồi thẳng thắn nhưng sáng suốt:

• Các phép tính sai lệch đáng kể
• Tính năng xuất khẩu gặp lỗi với dataset trên 50 dòng
• Các tính năng cốt lõi bị chôn vùi dưới các lớp điều hướng
• Tỷ lệ onboarding chỉ đạt 0% dù có quan tâm ban đầu

Một bình luận phản hồi đã trở thành bước ngoặt: “Tôi không muốn một công cụ mô hình tài chính nữa. Tôi muốn ai đó nói cho tôi biết số của tôi có hợp lý không.”

Insight này đã định hình lại toàn bộ hướng phát triển sản phẩm. Công cụ không phải là một bảng tính tốt hơn—nó là một cố vấn. Không phải một ứng dụng mô hình tài chính khác, mà là một AI tư vấn xác nhận giả định, cảnh báo dự báo không thực tế, so sánh chuẩn ngành, và trả lời các câu hỏi “nếu như” về các kịch bản.

Sự chuyển hướng này đã loại bỏ sự phức tạp. Thay vì xây dựng tích hợp doanh nghiệp, kiểm soát phiên bản nâng cao, và cộng tác đa người dùng, sản phẩm tối thiểu khả thi tập trung vào:

• Nhập mô hình tài chính thủ công
• Xác thực và so sánh dựa trên AI
• Lập kế hoạch kịch bản tối đa 3 kịch bản
• Trả lời câu hỏi bằng ngôn ngữ tự nhiên về các chỉ số tài chính
• Xuất khẩu định dạng phổ biến

Các trở ngại kỹ thuật

Ba hạn chế lớn về mặt kỹ thuật đã rõ ràng:

Hối tiếc về lựa chọn ngôn ngữ:
Bắt đầu với TypeScript thay vì Python tạo ra ma sát. Lỗi kiểu tiêu tốn hàng giờ debug. Các dự án sau cần chọn ngôn ngữ dựa trên sự thoải mái của nhà phát triển, chứ không phải theo độ phổ biến.

Hứa hẹn tích hợp vs. thực tế:
Các nhà sáng lập liên tục hỏi về đồng bộ QuickBooks. Thực tế: OAuth 2.0, webhook, ánh xạ dữ liệu, xử lý lỗi, làm mới token, và xác thực quy tắc kế toán. Đây không phải là nhiệm vụ vibe-coding.

Độ chính xác trong tính toán tài chính:
Các công thức tài chính phức tạp—đường cong giữ chân theo nhóm, tính NPV, giá trị khách hàng trọn đời—đẩy khả năng hỗ trợ của AI đến giới hạn. Các prompt “dễ” tạo ra kết quả tự tin nhưng sai lệch. Chỉ các hướng dẫn cực kỳ chính xác với công thức rõ ràng mới cho ra kết quả đáng tin cậy.

Quyết định chuyển hướng

Đến ngày 28, việc thu nhỏ quy mô là cần thiết. Toàn bộ ý tưởng quá phức tạp để làm mẫu nhanh. MVP cốt lõi ra mắt gồm:

✅ Trình tạo mô hình tài chính thủ công
✅ AI cố vấn để xác thực và so sánh
✅ Lập kế hoạch kịch bản cơ bản
✅ Chức năng xuất khẩu
✅ Hỏi đáp bằng ngôn ngữ tự nhiên

❌ Tích hợp thời gian thực (hoãn lại)
❌ Hợp tác nâng cao (hoãn lại)
❌ Bảo mật doanh nghiệp (hoãn lại)

Đôi khi ít hơn lại là nhiều hơn.

Những gì đã thành công, những gì chưa, và phía trước

( Các nguyên tắc chính đã bám sát

1. Độ chính xác phẫu thuật vượt qua hướng dẫn mơ hồ
“Làm tốt hơn” → lãng phí. “Thay đổi nút thành #0066CC, tăng phông chữ lên 16px, thêm padding 8px” → thành công.

2. Cập nhật tuần tự hơn là thay đổi song song
Giao một lệnh. Chờ. Xem xét. Tiếp tục. Không bao giờ đa nhiệm AI.

3. Xác thực thủ công là không thể thương lượng
Không bao giờ tin vào kết quả AI mà không kiểm tra độc lập, đặc biệt trong tài chính.

4. Rollback thoải mái mà không cảm thấy tội lỗi
73 lần rollback trong 30 ngày nghĩa là lặp lại nhanh chóng mà không sợ hãi. Quay lại nhanh hơn sửa lỗi.

5. Người dùng biết họ cần gì
Insight chiến thắng đến từ việc lắng nghe: “Nói tôi xem số của tôi có hợp lý không” trở thành chiến lược sản phẩm.

) Những gì sẽ thay đổi ngày mai

Nếu bắt đầu lại, ưu tiên sẽ thay đổi:

1. Phỏng vấn 10 người dùng TRƯỚC khi xây dựng bất cứ thứ gì—Phát hiện ra insight “tư vấn chứ không phải tool” vào Ngày 1, chứ không phải Ngày 21
2. Chọn Python thay vì TypeScript—Sự thoải mái về ngôn ngữ quan trọng hơn độ phổ biến của framework
3. Ngân sách tín dụng cứng 200-300 đô—Ép buộc kỹ thuật prompt tốt hơn và tránh vòng xoáy lặp lại vô tận
4. Thủ công trước, tự động sau—Xác nhận nhu cầu trước khi xây dựng tích hợp
5. Hạn chót MVP hai tuần—Ngăn chặn tính năng lan man, ép ưu tiên

Những điều nên bỏ qua hoàn toàn

• Chế độ ban đêm ###không ai yêu cầu; mất 3 ngày###
• Giao diện hoàn hảo (nhà sáng lập ưu tiên chức năng hơn thẩm mỹ)
• Hứa hẹn tích hợp (xác thực quy trình thủ công trước)
• Tính năng nâng cao (đạt 10 người trả phí trước khi mở rộng)

Con đường phía trước

Thành công không có nghĩa là hoàn hảo—nó có nghĩa là một nhà sáng lập sẵn sàng trả $50/tháng cho phiên bản đơn giản hơn. Đó là xác thực.

Lộ trình thực tế:

**Giai đoạn 1 (Tuần 5-8): **Xác thực giá trị cốt lõi bằng vibe coding. Mục tiêu: 10 khách hàng trả phí $50/tháng. Các tiêu chí thành công: <10% churn hàng tháng, NPS >40.

**Giai đoạn 2 (Sau 50-100 khách hàng): **Chuyển sang phát triển truyền thống. Thuê nhà phát triển fintech. Xây dựng tích hợp. Thêm tính năng doanh nghiệp. Ngân sách: $50K-100K.

Khi vibe coding đạt giới hạn

Điểm mạnh:

• Mẫu nhanh (tuần so với tháng)
• Các thao tác CRUD
• Tích hợp API AI
• Chức năng xuất khẩu
• Landing pages
• Chu kỳ lặp nhanh

Điểm hạn chế:

• Công thức tài chính phức tạp (NPV, đường cong giữ chân theo nhóm)
• Tích hợp API doanh nghiệp (OAuth, webhook)
• Các công việc đồng bộ dữ liệu nền
• Kiến trúc bảo mật đa khách hàng
• Tối ưu hiệu suất (<300ms truy vấn)
• Hợp tác theo thời gian thực

Ngưỡng tốt nghiệp: Khi hơn 10 khách hàng trả phí yêu cầu các tính năng mà vibe coding không thể cung cấp về cơ bản.

Bài học cho bất kỳ nhà xây dựng nào thử nghiệm AI

Trước khi bắt đầu:

• Chọn ngôn ngữ bạn thực sự hiểu
• Đặt ngân sách tín dụng hàng tuần và tuân thủ
• Định nghĩa “hoàn thành” bằng văn bản
• Tìm 3 tester thực sự (không quan tâm quan sát viên)
• Phỏng vấn hơn 10 người dùng tiềm năng trước

Trong quá trình xây dựng:

• Một prompt cho mỗi lần lặp; chờ hoàn thành
• Định nghĩa rõ ràng các thuật ngữ mơ hồ (“trực quan,” “sạch,” “đơn giản”) rõ ràng
• Xác thực tất cả các phép tính độc lập
• Theo dõi chi tiêu hàng ngày
• Chụp màn hình các phiên bản hoạt động trước các bước chuyển hướng lớn

Khi nào nên lùi bước:

• Cùng một lỗi vẫn lặp lại sau 5 lần thử
• Bạn đang giải thích nhiều hơn là xây dựng
• Người thử nghiệm không thể hoàn thành các quy trình cốt lõi
• Các yêu cầu tính năng doanh nghiệp liên tục xuất hiện
• Tín dụng tiêu hết mà không có người dùng trả phí