Bài speaker & demo
AI giúp tôi xây nhanh, nhưng không được tự quyết định
Thành chia sẻ cách một yêu cầu đi qua Intake, nơi AI có thể đọc và đề xuất nhưng phải dừng trước quyền duyệt, hành động và nghiệm thu của con người.
Vì sao Thành xây Intake
Trong một team nhỏ khoảng 10 người cùng làm nhiều dự án, yêu cầu không đi vào từ một nơi duy nhất. Có việc đến qua tin nhắn, email, ảnh chụp màn hình hoặc một câu nói trong cuộc họp. Trước khi giao cho team, Thành vẫn phải đọc lại, hỏi thêm, xác định dự án, đặt mức ưu tiên và kiểm tra xem yêu cầu đã đủ rõ để làm hay chưa.
Ở vai trò CTO, có lúc Thành trở thành người đứng giữa gần như toàn bộ dòng công việc. Vấn đề không phải team thiếu một công cụ tạo task. Vấn đề là ngữ cảnh bị mất khi thông tin được chuyển từ cuộc trò chuyện thành việc cần làm, còn trách nhiệm thì không phải lúc nào cũng được ghi lại rõ ràng.
Intake được xây từ tình huống đó và đang được ZiniSoft dùng trong một controlled pilot nội bộ từ đầu tháng 10/2026. Thành dùng chính hệ thống này trong bài speaker để trả lời một câu hỏi: AI có thể giúp team đi nhanh hơn mà không tự nắm quyền quyết định hay không?
Điều Thành từng tin chưa đúng
Thành từng nghĩ rằng khi một yêu cầu đã được ghi lại thành task thì phần khó nhất đã xong. Nhưng một task có tiêu đề gọn chưa chắc đã giữ đúng ý của người đưa yêu cầu. Một người nhận việc cũng chưa chắc đã biết dựa vào đâu để xem là hoàn tất.
Có lần báo cáo cuối ngày ghi một việc đã xong, nhưng khi Thành mở lại hệ thống quản lý mã nguồn, Issue vẫn còn mở. Người báo cáo không cố tình làm sai. Hai bên chỉ đang dùng hai định nghĩa khác nhau cho chữ “xong”.
Từ đó, Thành thay đổi cách nhìn: lời báo xong chưa đủ để nghiệm thu. Một việc cần có dấu vết để người chịu trách nhiệm có thể kiểm tra, chẳng hạn Issue đã được cập nhật, bản sửa đã được ghi nhận hoặc lý do ngoại lệ đã được lưu lại.
Năm bước từ yêu cầu đến bằng chứng
- Capture: giữ lại lời yêu cầu và nguồn gốc ban đầu, thay vì chỉ chép phần đã được diễn giải thành task.
- Structure: AI đọc, phân loại và đề xuất cách viết lại. Đây vẫn là một bản nháp.
- Approve: người hiểu công việc sửa nội dung, đặt ưu tiên và chịu trách nhiệm cho bản được duyệt.
- Act: hệ thống chỉ tạo Issue hoặc đưa việc vào kế hoạch từ nội dung đã được duyệt.
- Audit: trạng thái, quyết định và bằng chứng được giữ lại để người khác có thể kiểm tra.
Năm bước này không phụ thuộc vào một mô hình AI hay một công cụ quản lý việc cụ thể. Ranh giới Thành muốn giữ là: AI có thể chuẩn bị một quyết định, nhưng không được tự biến đề xuất của mình thành hành động thật.
Điều Thành đã trình bày trực tiếp
Trong phần demo, một feedback được đưa vào đúng cửa tiếp nhận của Intake. AI đọc và đề xuất nội dung. Thành kiểm tra, sửa mức ưu tiên rồi mới duyệt để hệ thống tạo Issue. Issue sau đó xuất hiện trong kế hoạch làm việc để người phụ trách sắp xếp.
Điểm Thành muốn người nghe nhìn thấy không phải tốc độ tạo task. Một task được tạo nhanh nhưng sai ngữ cảnh chỉ giúp team đi sai nhanh hơn.
Khoảnh khắc quan trọng nhất xuất hiện ở bước nghiệm thu. Thành thử xác nhận một việc chưa có bằng chứng. Hệ thống không cho đi tiếp như một trường hợp bình thường mà yêu cầu Thành cung cấp lý do. Thành chọn dừng lại.
Nó chặn cả CTO. Đó là hành vi có chủ ý, vì chức danh của người bấm nút không nên thay thế bằng chứng mà team đã thống nhất từ trước.
Một phần khác của bài nói cho thấy agent dừng ngay khi hồ sơ dự án chưa đủ. Nó chưa tạo nhánh, chưa đọc Issue và chưa sửa mã. Khi thiếu ngữ cảnh, câu trả lời có trách nhiệm nhất của AI đôi khi là chưa hành động.
Điều Thành rút ra sau khi dùng với team
Sau khi dùng Intake với chính team của mình, Thành không còn xem một task được tạo ra là kết quả. Kết quả chỉ có ý nghĩa khi có thể trả lời được ba câu hỏi:
- Yêu cầu này đến từ đâu và nội dung gốc là gì?
- Ai đã đọc, sửa và cho phép hệ thống hành động?
- Bằng chứng nào cho thấy công việc thực sự hoàn tất?
AI giúp Thành giảm thời gian đọc, chuẩn hóa và đối chiếu thông tin. Nhưng quyền ưu tiên, giao việc, chấp nhận ngoại lệ và nghiệm thu vẫn cần một người có tên và chịu trách nhiệm.
Đây cũng là phần nối giữa hai Operator Notes: yêu cầu được ghi lại chưa có nghĩa đã hiểu giống nhau và làm rõ workflow trước khi thêm nhiều AI agent.
Bạn có thể bắt đầu từ một việc nhỏ
Bạn chưa cần xây một hệ thống giống Intake. Hãy chọn một việc AI đang hỗ trợ trong team và viết rõ ba ranh giới:
- AI được phép đọc, chuẩn hóa hoặc đề xuất điều gì?
- Ai là người duyệt trước khi đề xuất trở thành hành động?
- Người duyệt cần nhìn thấy bằng chứng gì trước khi tin kết quả?
Nếu chưa trả lời được câu thứ hai và câu thứ ba, việc nên làm tiếp theo chưa phải là thêm một agent khác.
Phạm vi của bài demo
Đây là một controlled pilot nội bộ, không phải một case chứng minh ROI hoặc khả năng tự vận hành ở quy mô lớn. Bài demo cho thấy workflow có thể giữ nguồn gốc, buộc đi qua cổng duyệt và yêu cầu bằng chứng trước khi nghiệm thu. Nó chưa chứng minh mô hình này phù hợp với mọi team.
Hình minh họa trên trang đã được dựng lại cho mục đích công khai. Thành không đưa deck nội bộ, video dự phòng, dữ liệu khách hàng hoặc kiến trúc nội bộ vào bài viết này.