Trang này được dịch từ tiếng Anh.
Công cụ cho nhà phát triển
Xây dựng ứng dụng riêng tích hợp GitHub
Kliv là công cụ xây dựng ứng dụng bằng AI. Hãy mô tả tích hợp GitHub bạn muốn — yêu cầu khách hàng, issue được gắn nhãn, bản nháp changelog, email phát hành, và hóa đơn — Kliv sẽ xây dựng ứng dụng đó.
Chỉ cần nhập ý tưởng của bạn vào ô văn bản và AI sẽ xây nó cho bạn
Kliv là gì?
Kliv không phải một ô tích hợp có sẵn để bạn đăng ký rồi cấu hình — đây là một công cụ xây dựng ứng dụng bằng AI, tạo ra phần mềm cho bạn.
Bạn mô tả nhu cầu bằng lời của chính mình, và Kliv sẽ xây dựng: cơ sở dữ liệu, logic xử lý, giao diện, và các quy tắc vận hành. Kết quả bạn nhận được là một ứng dụng thật, hoạt động thật, và thuộc về bạn. Bạn có thể sử dụng nó, thay đổi sau này chỉ bằng cách yêu cầu chỉnh sửa, và vận hành nó trên tài khoản cùng tên miền riêng của mình. Đây không phải một mẫu có sẵn gắn tên bạn vào.
Trên trang này, ứng dụng đó là một ứng dụng riêng kết nối với GitHub, hiển thị đúng quy trình làm việc cho những người bên ngoài kho mã nguồn. Kliv xây dựng mọi loại ứng dụng web; đây chỉ là một ví dụ, và đó là nội dung của phần còn lại của trang này.
Vì sao kho mã cần một “mặt tiền” riêng
Công việc bàn giao có thể đã nằm sẵn trong GitHub: issue, pull request, cột mốc (milestone), và bản phát hành (release). Nhưng khách hàng thường không cần đọc GitHub để biết chuyện gì đã xảy ra.
Kliv có thể xây dựng trung tâm bàn giao mà bạn mô tả, xoay quanh các kho mã của bạn. Yêu cầu của khách hàng có thể tạo ra issue được gắn nhãn. Trạng thái trên GitHub có thể phản chiếu ngược lại cho khách hàng. Các pull request đã merge có thể tạo bản nháp changelog. Bản phát hành có thể tạo email dễ đọc và hóa đơn theo cột mốc. Đội ngũ vẫn làm việc trong GitHub như thường lệ; khách hàng thấy một trung tâm bàn giao rõ ràng.
Hai đầu của webhook
Năm loại bản ghi mang câu chuyện bàn giao đi lại giữa GitHub và trung tâm dành cho khách hàng.
Dự án
Một dự án ánh xạ một khách hàng tới các kho mã và cột mốc liên quan. Yêu cầu, mục changelog, và hóa đơn đều gắn với dự án đó.
Yêu cầu
Khách hàng gửi yêu cầu bằng ngôn ngữ thông thường. Ứng dụng mở một issue trên GitHub với đúng nhãn và giữ trạng thái đồng bộ.
Mục changelog
Khi một pull request được merge, webhook tạo một bản nháp gồm tiêu đề PR, dự án, và yêu cầu liên quan. Một người sẽ viết lại trước khi khách hàng nhìn thấy.
Hóa đơn theo cột mốc
Khi một bản phát hành đóng một cột mốc, trung tâm có thể tạo bản nháp hóa đơn chi tiết, chẳng hạn một cột mốc cố định 45.000.000 ₫, kèm thanh toán bằng thẻ trên tài khoản Stripe của chính bạn.
Bức tường phân quyền khách hàng
Khi một khách hàng đăng nhập, họ chỉ thấy các dự án của riêng mình. Một kho mã dùng chung (monorepo) vẫn có thể phục vụ nhiều khách hàng vì quyền truy cập đi theo từng dòng dự án.
Một ví dụ: trung tâm bàn giao của studio sản phẩm do Linh điều hành
Đây là cách một studio có thể sử dụng nó. Đây chỉ là một ví dụ — bạn sẽ mô tả kho mã, quyền truy cập của khách hàng, quy trình xử lý issue, bản phát hành, và quy tắc thanh toán của riêng mình.
Yêu cầu của khách hàng mở đúng issue
Khách hàng của Linh viết hai câu bằng ngôn ngữ thông thường trong trung tâm. Ứng dụng mở một issue được gắn nhãn trong đúng kho mã và liên kết ngược lại với yêu cầu của khách hàng.
Việc phân loại vẫn diễn ra trong GitHub
Studio ước lượng, gắn nhãn, và lên lịch công việc trong GitHub như bình thường. Trung tâm phản chiếu trạng thái đó về màn hình của khách hàng.
Một lần merge tạo ra bản nháp changelog
Khi pull request được gộp vào, webhook tạo một mục changelog đang chờ duyệt, gồm tiêu đề PR, dự án, và yêu cầu mà nó giải quyết.
Một người duyệt lại câu chữ dành cho khách hàng
Ai đó viết lại tiêu đề PR mang tính kỹ thuật thành một câu mà khách hàng có thể đọc hiểu, rồi phê duyệt để đưa vào bản phát hành.
Email phát hành được gửi riêng cho từng khách hàng
Khi phát hành được công bố, các bản nháp đã duyệt trở thành một trang changelog và gửi email cho mỗi khách hàng chỉ những mục thuộc dự án của họ.
Hóa đơn biết chính xác những gì đã bàn giao
Cột mốc đã đóng sẽ tạo bản nháp hóa đơn từ các yêu cầu đã hoàn thành, chi tiết từng mục kèm liên kết thanh toán bằng thẻ ngay trên trang mà khách hàng đã theo dõi công việc.
Mô tả tích hợp GitHub bạn muốn xây dựng
Kliv xây dựng dựa trên mô tả của bạn, nên càng chi tiết, phiên bản đầu tiên càng sát với mong muốn. Hãy nêu rõ kho mã, sự kiện, nhãn, quyền truy cập của khách hàng, bước duyệt, thông báo, và thanh toán. Dưới đây là ba ví dụ để bạn tham khảo:
Trung tâm bàn giao cho khách hàng
Yêu cầu đi vào, changelog đi ra, phân quyền theo từng khách hàng.
“Xây dựng một trung tâm bàn giao cho khách hàng, kết nối với tổ chức GitHub của chúng tôi. Khách hàng gửi yêu cầu và chúng trở thành issue được gắn nhãn trong đúng kho mã, trạng thái issue phản chiếu ngược lại cho khách hàng, các pull request đã merge trở thành bản nháp changelog, mỗi khách hàng chỉ thấy dự án của riêng mình, và các cột mốc cố định 45.000.000 ₫ có thể tạo bản nháp hóa đơn sau khi phát hành.”
Trang changelog công khai
Bản phát hành GitHub trở thành bài viết dễ đọc.
“Xây dựng một trang changelog công khai cho sản phẩm của chúng tôi. Biến các bản phát hành GitHub thành bài viết nháp, yêu cầu một người phê duyệt trước khi đăng, cho phép khách truy cập đăng ký nhận email, và gửi thông báo phát hành kèm liên kết tới các mục đã ra mắt.”
Biểu mẫu tiếp nhận issue
Báo cáo lỗi được gửi tới trong tình trạng đã phân loại sẵn.
“Xây dựng một biểu mẫu tiếp nhận báo lỗi cho đội hỗ trợ của chúng tôi. Người báo cáo gửi mức độ nghiêm trọng, trình duyệt, các bước tái hiện lỗi, ảnh chụp màn hình, và mã tài khoản; ứng dụng tạo một issue trên GitHub kèm nhãn mức độ nghiêm trọng và tệp đính kèm; người báo cáo có thể xem trạng thái theo thời gian thực mà không cần tài khoản GitHub.”
Những phần bạn không cần tự tay xây dựng
Kết nối chỉ cần cấp quyền một lần. Bạn kết nối tổ chức GitHub của mình một lần duy nhất. Token được nền tảng lưu giữ, không dán vào mã nguồn ứng dụng. Ứng dụng có thể mở issue, bình luận, đọc bản phát hành, và nhận sự kiện webhook.
Bản nháp luôn chờ một người duyệt. Các mục changelog đến trong hàng chờ duyệt. Không gì đến tay khách hàng cho đến khi ai đó biến tiêu đề PR mang tính kỹ thuật thành ngôn ngữ phát hành rõ ràng và phê duyệt nó.
Bản thân ứng dụng cũng có kho mã riêng. Kliv đồng bộ mã nguồn của ứng dụng với một kho mã do bạn sở hữu, nên công cụ báo cáo về việc bàn giao cũng được quản lý phiên bản.
Slack có thể là một kênh khác. Một bản phát hành có thể đăng bản tóm tắt lên kênh mà bạn chia sẻ với khách hàng.
GitHub chỉ là một trình kết nối. Cùng một mô hình hành động - phản hồi đó cũng áp dụng cho Slack, Notion, Linear, HubSpot, và nhiều hơn nữa. Xây dựng & mở rộng giới thiệu kho trình kết nối rộng hơn.
Các câu hỏi thường gặp
Kliv chính xác là gì?
Kliv là một công cụ xây dựng ứng dụng bằng AI. Bạn mô tả phần mềm mình cần, nó xây dựng ứng dụng hoạt động thật, và bạn sở hữu kết quả đó. Với trang này, đó là một trung tâm bàn giao kết nối với GitHub, gồm yêu cầu của khách hàng, tạo issue, phản chiếu trạng thái, bản nháp changelog, email phát hành, và hóa đơn.
Tôi nhận được một ứng dụng thật hay chỉ là một mẫu có sẵn?
Một ứng dụng thật. Kliv xây dựng dữ liệu, quy tắc, và giao diện cho đúng trường hợp của bạn, không phải một giao diện dựng sẵn để bạn điền vào. Bạn tiếp tục thay đổi nó bằng cách mô tả điều mình muốn khác đi.
Tôi có thể thay đổi nó sau khi đã xây dựng xong không?
Có. Hãy yêu cầu thay đổi bằng lời thông thường và Kliv sẽ cập nhật ứng dụng. Bạn có thể điều chỉnh trường dữ liệu, quy trình, trang, email, quy tắc truy cập, và báo cáo mà không cần làm lại từ đầu.
Khách hàng có cần tài khoản GitHub không?
Không. Khách hàng đăng nhập vào trung tâm bằng email và mật khẩu, Google, hoặc passkey. GitHub vẫn là công cụ riêng của studio, còn khách hàng chỉ thấy các bản ghi phái sinh.
Nếu tiêu đề pull request quá mang tính kỹ thuật để công bố thì sao?
Mọi mục đều có thể vào hàng chờ duyệt dưới dạng bản nháp. Nó ở trạng thái ẩn cho đến khi ai đó viết lại và phê duyệt.
Điều này có hoạt động với kho mã riêng tư không?
Có. Bạn cấp quyền cho tổ chức một lần, và kết nối được lưu giữ phía máy chủ. Không có khóa nào xuất hiện trong mã nguồn ứng dụng.
Hai khách hàng có thể dùng chung một monorepo không?
Có. Yêu cầu và mục changelog đều mang phạm vi dự án, và quyền truy cập của mỗi khách hàng được áp dụng trên chính các dòng đó.
Ứng dụng có thể tạo issue trên GitHub không?
Có. Một yêu cầu của khách hàng có thể mở một issue được gắn nhãn trong đúng kho mã và giữ liên kết ngược về yêu cầu hiển thị cho khách hàng.
Các pull request đã merge có thể trở thành mục changelog không?
Có. Webhook có thể tạo mục nháp khi pull request được merge, sau đó một người phê duyệt câu chữ sẵn sàng cho khách hàng.
Bản phát hành có thể gửi email hoặc đăng lên Slack không?
Có. Một sự kiện phát hành có thể công bố trang changelog, gửi email, và đăng bản tóm tắt lên kênh Slack dùng chung nếu bạn định nghĩa luồng đó.
Hóa đơn theo cột mốc có thể dùng Stripe không?
Có. Nếu quy trình bàn giao của bạn có các cột mốc trả phí, hóa đơn có thể kèm thanh toán bằng thẻ trên tài khoản Stripe của chính bạn.
Tôi có thể dùng tên miền riêng không?
Có. Trung tâm dành cho khách hàng và trang changelog có thể chạy trên tên miền riêng của bạn.
Tôi có thể chuyển đi khỏi Kliv sau này không?
Có. Mã nguồn của ứng dụng được đồng bộ về kho mã Git của riêng bạn.
Thêm trong danh mục này
Được xây dựng bởi nhà sáng tạo
Khám phá điều có thể
Xem các ứng dụng thật được xây dựng với Kliv bởi nhà phát triển và nhà sáng tạo trên toàn thế giới
Memory Café Coordination Tool
A warm platform for dementia-friendly cafés, connecting caregivers, volunteers, and coordinators.
Remit Record
Track remittances and household budgets seamlessly.
Next Page Book Club
Manage your book club easily with proposals, voting, and history tracking.
Northfern Tattoo Studio
Portfolio and booking site for Northfern Tattoo Studio.
Campo Agua Gestión
Sistema de gestión del agua comunitario para aldeas.
つくりて — 伝統工芸職人サイト
職人が作品を展示し、受注管理を行うサイトです。
Tidal Surf Reports
Crowd-sourced surf condition tracking app.
Riverside Commons HOA Management
A portal for HOA management at Riverside Commons.
よやくん — レストラン予約管理
小規模レストラン向けの予約管理サイトです。
Troop 214 Scout Management
A management tool for Scout Troop 214, focused on outings, advancement, and communication.
Te Kura Kaupapa Māori Whānau Board
A whānau coordination tool for Māori-medium schools.
Tsev Nyeem Ntawv Library
Mobile library coordinator for Hmong and Lao communities.
Memory Café Coordination Tool
A warm platform for dementia-friendly cafés, connecting caregivers, volunteers, and coordinators.
Remit Record
Track remittances and household budgets seamlessly.
Next Page Book Club
Manage your book club easily with proposals, voting, and history tracking.
Northfern Tattoo Studio
Portfolio and booking site for Northfern Tattoo Studio.
Campo Agua Gestión
Sistema de gestión del agua comunitario para aldeas.
つくりて — 伝統工芸職人サイト
職人が作品を展示し、受注管理を行うサイトです。
Tidal Surf Reports
Crowd-sourced surf condition tracking app.
Riverside Commons HOA Management
A portal for HOA management at Riverside Commons.
よやくん — レストラン予約管理
小規模レストラン向けの予約管理サイトです。
Troop 214 Scout Management
A management tool for Scout Troop 214, focused on outings, advancement, and communication.
Te Kura Kaupapa Māori Whānau Board
A whānau coordination tool for Māori-medium schools.
Tsev Nyeem Ntawv Library
Mobile library coordinator for Hmong and Lao communities.
Cho khách hàng thấy tiến độ mà không để lộ kho mã
Hãy mô tả các sự kiện GitHub, quy tắc issue, quyền truy cập của khách hàng, bước duyệt changelog, email phát hành, và thanh toán. Kliv sẽ xây dựng trung tâm bàn giao xoay quanh chúng.
