Vấn Đề: Discord Là Một Hố Đen Thông Tin
Tôi đã cảm thấy thất vọng với Discord trong nhiều năm. Đây là nơi mà các cộng đồng sống, nhưng cũng là nơi thông tin đi vào quên lãng. Bạn có một cuộc trò chuyện sâu sắc, ai đó đặt ra một câu hỏi hay, bạn cung cấp một câu trả lời chi tiết—và chỉ sau vài ngày, nó bị chôn vùi dưới hàng ngàn tin nhắn mới, không còn dấu vết.
Điều này đã khiến tôi đặc biệt khó chịu với CSMM và Takaro, nơi mà cộng đồng của chúng tôi luôn cần câu trả lời cho các câu hỏi giống nhau. Kiến thức không tích lũy được; nó như đã bốc hơi. Vì vậy, tôi muốn xây dựng một thứ gì đó để khắc phục tình trạng này—một hệ thống có thể ghi lại các cuộc trò chuyện trên Discord, làm cho chúng có thể tìm kiếm được và biến kiến thức cộng đồng thành thứ gì đó vĩnh cửu và hữu ích.
Tôi đã cố gắng xây dựng một giải pháp với AI hai lần, mà bọn trẻ gọi là "vibe coding"—chỉ có tôi và một trợ lý AI cố gắng tạo ra một thứ gì đó có chức năng. Cả hai lần thử nghiệm đều thất bại thảm hại (hình 1 và 2), và nhìn lại, rõ ràng tại sao. Đây không phải là một ứng dụng CRUD đơn giản mà bạn có thể hoàn thành trong một buổi chiều. Đây là một hệ thống phức tạp thực sự với một frontend để duyệt qua cơ sở kiến thức, một API backend xử lý các hành động và điều phối Discord, một dịch vụ học máy cho embedding và tìm kiếm, một cơ sở dữ liệu với khả năng tìm kiếm vector, và các worker nền để đồng bộ hàng triệu tin nhắn.
Việc làm cho tất cả các thành phần này hoạt động cùng nhau trong khi vẫn giữ được bức tranh lớn trong tâm trí? Đó là nơi mà mã hóa AI thuần túy gặp khó khăn. Các cửa sổ ngữ cảnh quá nhỏ, AI quên những gì nó đang xây dựng, và bạn kết thúc với một mớ hỗn độn của các tính năng thực hiện dở dang không liên kết với nhau. Sau đó tôi tìm thấy Kiro, và mọi thứ đã thay đổi.
Phát Triển Dựa Trên Đặc Tả: Tại Sao Nó Thực Sự Hoạt Động Lần Này
Tôi đã thấy các phương pháp phát triển dựa trên đặc tả trước đây—có những dự án như Taskmaster AI hoặc ai-dev-tasks hứa hẹn các quy trình làm việc AI có cấu trúc. Nhưng tất cả đều gặp phải điều mà tôi gọi là "vấn đề LLM nôn mửa." Hỏi một LLM lập kế hoạch một tính năng, nó sẽ háo hức nôn ra hàng ngàn ký tự—các giai đoạn lập kế hoạch, chiến lược hoàn tác, chiến lược kiểm tra, mục tiêu hiệu suất, các sơ đồ kiến trúc, tất cả mọi thứ. Nó trông ấn tượng ở cái nhìn đầu tiên, nhưng thực sự là những thứ vô nghĩa lấn át những gì bạn đang cố gắng xây dựng.
Kiro thì khác vì nó giữ cho các đặc tả nhẹ nhàng và tập trung. Đây là sự thay đổi lớn đối với tôi—thay vì bị chìm trong tài liệu, tôi thực sự có thể thấy những gì mình đang xây dựng. Quy trình làm việc buộc tôi phải suy nghĩ khác đi: tôi sẽ viết một đặc tả mô tả những gì tôi muốn, Kiro sẽ tạo ra một đề xuất thiết kế, và sau đó tôi sẽ xem xét và ngay lập tức thấy vấn đề. "Điều này sẽ không hoạt động," tôi nghĩ, hoặc "Tôi đã không cụ thể đủ về yêu cầu đó." Chúng tôi sẽ lặp đi lặp lại cho đến khi đặc tả chắc chắn, và chỉ sau đó mới bắt đầu triển khai.
Quá trình trao đổi trước khi bất kỳ mã nào được viết? Đó là điều đã tạo nên sự khác biệt. Với Kiro, AI luôn có một thứ gì đó cụ thể để tham khảo—đặc tả—vì vậy nó không thể trôi dạt vào việc triển khai các tính năng ngẫu nhiên hoặc quên kiến trúc giữa chừng. Nó giống như có những rào chắn giữ cho AI tập trung vào những gì thực sự quan trọng.
Điểm Nổi Bật Kỹ Thuật: Sự Phát Triển Của Điểm Tìm Kiếm
Hãy để tôi đưa ra một ví dụ cụ thể về cách điều này hoạt động trong thực tế. Điểm tìm kiếm là trái tim của Verta—khi ai đó đặt câu hỏi trong Discord, bot sử dụng tìm kiếm để tìm các cuộc thảo luận trước đó có liên quan. Frontend sử dụng nó để duyệt qua, cụm câu hỏi phụ thuộc vào nó, về cơ bản mọi thứ đều xoay quanh việc tìm kiếm hoạt động tốt.
Thực hiện đầu tiên của tôi là, nói một cách nhẹ nhàng, rác rưởi. Tìm kiếm từ khóa cơ bản đã bỏ lỡ hầu hết các kết quả liên quan và trả về nhiều tiếng ồn. Tôi biết nó cần phải tốt hơn nhưng không chắc cách tiếp cận, vì vậy tôi đã hỏi Kiro: "Tìm kiếm này không hoạt động tốt. Bạn có thể giúp tôi tìm ra cách tiếp cận tốt hơn không?"
Cách mà Kiro gợi ý thực sự rất thực dụng. Đầu tiên, thực hiện một tìm kiếm ban đầu để có kết quả sơ bộ. Sau đó, đưa những kết quả đó cho một LLM và hỏi: "Dựa trên những kết quả này, những tìm kiếm nào khác có thể tìm thấy thông tin liên quan?" Thực hiện các tìm kiếm bổ sung đó, sau đó kết hợp tất cả cho câu trả lời cuối cùng. Nếu bạn là một người làm marketing điên cuồng, bạn có thể gọi điều này là một "đại lý AI thông minh nhiều bước", tôi gọi đó là một hàm nhỏ thực dụng. Đơn giản đủ để triển khai nhanh chóng, tinh vi đủ để cải thiện đáng kể chất lượng kết quả. Đó là loại gợi ý làm cho Kiro trở nên có giá trị: không phải là quá kỹ thuật, chỉ đơn giản là giải quyết vấn đề hiện tại.
Bài Học Rút Ra: Thực Tế Của Phát Triển Hỗ Trợ AI
Quy trình làm việc của tôi đã hoàn toàn thay đổi kể từ khi áp dụng phương pháp này. Trước đây, tôi dành phần lớn thời gian của mình trong trình chỉnh sửa—viết mã, đọc mã, gỡ lỗi mã, công việc lập trình thông thường. Giờ đây, tôi dành phần lớn thời gian của mình trong các tệp markdown, tạo và tinh chỉnh các đặc tả. Đây là một loại công việc khác, nhiều hơn về việc suy nghĩ qua các vấn đề hơn là thực hiện giải pháp.
Các đặc tả Kiro mặc định là nguyên bản, điều này có lý—chúng cần phục vụ một đối tượng chung. Nhưng tôi đã viết phần mềm trong nhiều năm và tôi biết cách tôi muốn mọi thứ được xây dựng, vì vậy tôi tùy chỉnh rất nhiều. Tôi xóa đi những điều không cần thiết, thêm mô tả chính xác về những gì tôi muốn, và lặp lại nhiều lần trước khi triển khai. Đây không phải là một lỗi; đó là thực tế của việc làm việc với các công cụ AI. Không AI nào tạo ra các đặc tả hoàn hảo trong một lần, và điều đó không sao cả. Điều kỳ diệu nằm trong quy trình lặp lại.
Đây là phần quan trọng mà nhiều quảng cáo công cụ AI thường bỏ qua: bạn không thể hoàn toàn tin tưởng bất kỳ đại lý AI nào. Tất cả chúng đều có những thiếu sót theo cách riêng của chúng, và bạn cần phải xem xét kỹ lưỡng từng phần mã được tạo ra, kiểm tra một cách kỹ lưỡng, và sẵn sàng can thiệp khi chúng đi sai hướng. Không phải là thay thế phán đoán con người; mà là tăng cường nó.
Sự hợp tác thực sự là từ đúng ở đây. Tôi sử dụng bộ não con người của mình để hướng dẫn AI qua các đặc tả, và AI xử lý các chi tiết triển khai. Cả hai chúng tôi không thể xây dựng Verta một mình—tôi sẽ bị mắc kẹt trong các chi tiết triển khai, và AI sẽ xây dựng một cái gì đó mà về mặt kỹ thuật hoạt động nhưng không đạt được mục tiêu.
Kết Luận
Verta tồn tại bởi vì Kiro đã làm cho phát triển dựa trên đặc tả trở nên thực tiễn—không phải phiên bản phức tạp, quá kỹ thuật mà tôi đã thấy trước đây, mà là một cách tiếp cận nhẹ nhàng thực sự giúp bạn xây dựng mọi thứ. Sự chuyển biến từ "viết mã cả ngày" sang "suy nghĩ trong các đặc tả" không chỉ là về năng suất; mà còn là về việc xây dựng phần mềm tốt hơn bằng cách suy nghĩ qua các vấn đề trước khi thực hiện giải pháp.
Có phải nó hoàn hảo không? Không. Tôi có cần phải chăm sóc AI và bắt lỗi của nó không? Chắc chắn rồi. Nhưng lần đầu tiên, tôi có một hệ thống quản lý kiến thức Discord hoạt động thực sự, phục vụ cho người dùng thực tế, và giải quyết vấn đề mà tôi đã đặt ra để khắc phục. Sau hai lần thử nghiệm thất bại, điều đó cảm thấy rất tốt.
Đôi khi, điều đó là tất cả những gì quan trọng—không phải có quy trình hoàn hảo hay mã hoàn mỹ, mà là thực sự giao hàng một cái gì đó giải quyết một vấn đề thực tế. Và nếu điều đó cần sự kết hợp giữa sự sáng tạo của con người và triển khai AI để đạt được? Tôi sẽ chấp nhận điều đó.
