Bảng phản hồi cho tác nhân AI: Để người dùng tự viết prompt

Một người dùng nhắn cho bạn lúc 11 giờ đêm. "Nút xuất dữ liệu bấm không ăn gì trên Safari."

Bạn biết chuyện gì tới tiếp theo, vì nó đã xảy ra cả trăm lần. Bạn đọc. Bạn hiểu. Rồi bạn mở một hệ quản lý issue và gõ lại lần nữa, bằng lời của mình, kèm đường dẫn tệp, các bước tái hiện và phần ngữ cảnh mà người dùng không có. Rồi lát sau, bạn mở terminal và gõ nó lần thứ ba, dưới dạng một prompt.

Ba lần viết cho cùng một yêu cầu. Lần đầu miễn phí và đến từ chính người đã dính con lỗi đó. Hai lần còn lại là của bạn.

Chính lần viết thứ hai và thứ ba mới là phần công việc mà các tác nhân đã khiến trở nên vô lý.

Thứ cuối cùng bạn vẫn còn gõ tay

Tác nhân lập trình đã bỏ đi rất nhiều thao tác gõ. Chúng không bỏ đi cái đề bài. Vẫn phải có thứ gì đó nói cho tác nhân biết cần xây cái gì, đủ chi tiết để nó khỏi phải đoán, và thứ đó vẫn là một con người ngồi trước bàn phím chuyển lời của người khác thành mệnh lệnh.

Có điều phép chuyển đổi ấy thường vô nghĩa. Một báo lỗi tử tế đã chứa sẵn thứ tác nhân cần: đáng lẽ phải ra gì, thực tế ra gì, ở trang nào, trên trình duyệt nào. Một đề xuất tính năng tử tế đã chứa sẵn ý định và lý do. Người viết ra nó còn ở gần vấn đề hơn bạn.

Vậy mà ta lại coi đoạn văn bản đó như nguyên liệu thô cần chế biến lại, chỉ vì công cụ thu thập nó và công cụ thực thi công việc chưa bao giờ là một. Phản hồi nằm trong một sản phẩm, ticket nằm trong sản phẩm thứ hai, còn tác nhân chạy trong một terminal chẳng biết gì về cả hai.

Xóa khoảng cách đó đi thì bước viết lại không còn chỗ nào để xảy ra.

Bảng phản hồi trở thành gì khi chính nó thực thi được

Backlog công khai là một trang mà người dùng của bạn vào được. Họ báo lỗi, đề xuất tính năng, bình chọn cho thứ người khác đã xin, theo dõi một luồng trao đổi và nhìn trạng thái thay đổi. Đến đây thì nó vẫn chỉ là một bảng phản hồi, và loại đó vốn đã có những sản phẩm tốt.

Khác biệt nằm ở chỗ cái ticket rơi xuống đâu. Nó không rơi vào một sản phẩm phản hồi rồi nằm chờ được xuất đi. Nó rơi thẳng vào bảng công việc mà các tác nhân của bạn vốn đã chạy từ đó, như một ticket ngang hàng, nằm cạnh những cái bạn tự viết.

Từ đó, kéo nó sang In Progress sẽ khởi chạy một tác nhân với đề bài chính là cái ticket: tiêu đề, phần mô tả bằng đúng lời người báo, trang họ đang mở, trình duyệt họ dùng, và cả cuộc trao đổi giữa bạn với họ từ lúc đó tới giờ. Không ai viết lại gì cả. Cái prompt chính là bản báo lỗi.

Hệ quả thú vị không phải là tốc độ. Nó nằm ở chỗ người mô tả vấn đề giờ cũng là người đặc tả công việc, tức đúng thứ ai cũng bảo mình muốn có từ phản hồi người dùng mà gần như không ai dựng cấu trúc để đạt được. Phép đảo chiều đó có tên riêng: backlog do khách hàng dẫn dắt. Hàng đợi thôi làm phỏng đoán của bạn về cái gì quan trọng, và trở thành bản ghi những gì thực sự được yêu cầu.

Ba cánh cửa, vì người ta báo lỗi ngay tại chỗ mình đang đứng

Một bảng phản hồi chỉ chạy được nếu việc báo lỗi rẻ hơn việc đi phàn nàn ở chỗ khác. Nghĩa là phải đón người dùng ngay tại nơi vấn đề xảy ra.

Trang công khai là cánh cửa hiển nhiên: một URL bạn chia sẻ, với chế độ danh sách hoặc lộ trình, lượt bình chọn và một biểu mẫu. Nó hợp với sản phẩm có người dùng chịu đánh dấu trang, và đồng thời là bằng chứng nhìn thấy được rằng công việc đang chạy, thứ có giá hơn hẳn một email cập nhật tình hình không ai đọc.

Widget nhúng là cánh cửa thứ hai: một đoạn script nhỏ đặt trên chính trang của bạn, mở biểu mẫu ngay tại chỗ. Người dùng không phải rời khỏi trang đang có lỗi, và đó đúng là lúc họ sẵn lòng mô tả nó nhất.

Tiện ích Chrome là cánh cửa thứ ba, và cũng là cái làm thay đổi hành vi nhiều nhất. Người dùng bôi đen đoạn bị lỗi trên bất kỳ trang nào, bấm vào tiện ích, thế là ticket được gửi đi với URL và phần đã chọn đính kèm sẵn. Thứ bạn nhận về không phải là "nó không chạy", mà là một bản báo lỗi có tọa độ.

Với một agency, cánh cửa thứ ba thường chính là khách hàng, và chế độ cổng khách hàng chỉ mở theo lời mời: mỗi khách hàng một bảng, không ai khác nhìn thấy, không phải thêm một thuê bao SaaS nào vào hệ thống.

Định tuyến, vì "đúng tác nhân" không phải chỉ một tác nhân

Một ticket vừa đến thì chưa gửi cho ai cả. Đó là vấn đề thực tế của mọi hộp thư đến: phải có ai đó quyết định người nhận việc.

Ticket đến từ bên ngoài được định tuyến tới tác nhân có chuyên môn khớp với nó, nên một bố cục vỡ đi tới chuyên gia frontend còn một truy vấn rò rỉ đi tới chuyên gia backend, mà bạn không phải phân loại hàng đợi bằng tay mỗi sáng. Khi chưa cấu hình gì, phương án dự phòng được làm cho ngờ nghệch và dễ đoán một cách có chủ đích: tác nhân phát triển đầu tiên trong dự án, không bao giờ là một vai trò marketing hay PM tình cờ nằm trên đầu danh sách.

Bạn cũng có thể trỏ một ticket vào cả một đội tác nhân thay vì một cá thể, để yêu cầu của khách hàng đi qua bước phát triển rồi bước QA trước khi tới tay bạn.

Phần ai cũng quên: người báo lỗi nhận lại được gì

Thu thập phản hồi thì dễ. Khép lại vòng lặp mới là chỗ các sản phẩm đánh mất người dùng.

Khi một ticket chuyển sang giai đoạn phát triển, tác giả của nó được báo. Khi nó được ưu tiên, họ được báo. Khi bạn quyết định sẽ không làm, họ cũng được báo, kèm lý do bạn viết ra, và như vậy vẫn tốt hơn nhiều so với im lặng. Còn khi bản sửa thực sự lên sản phẩm, họ nhận một tin nhắn nói đúng như vậy, gom thành một thông báo cho mỗi lần phát hành thay vì năm email rời rạc cho năm ticket.

Có một chi tiết nhỏ hơn nhưng quan trọng hơn vẻ ngoài của nó: commit khép lại một ticket người dùng sẽ ghi công người báo bằng tên riêng, và dòng ghi công đó theo ra tới tận changelog công khai. Ai từng thấy tên mình gắn với một thay đổi đã phát hành thì sẽ báo tiếp con lỗi sau. Toàn bộ cơ chế giữ chân người dùng chỉ có vậy, và nó không tốn gì. Chạy vòng lặp đó vài tháng, bạn có phát triển dẫn dắt bởi phản hồi như một thực tế quan sát được chứ không phải một khẩu hiệu: lượt bình chọn quyết định thứ tự, và thứ tự quyết định các bản phát hành.

Nếu một yêu cầu đến trong tình trạng mơ hồ, khoanh phạm vi ticket chen vào giữa bản báo cáo và công việc: một tác nhân Product Manager biến yêu cầu lờ mờ đó thành bản mockup của chính sản phẩm bạn đang có, với thay đổi đã được áp vào, để bạn duyệt ý tưởng ngay trên cái ticket đó trước khi ai kịp viết một dòng mã.

Chỗ mà các công cụ cổ điển dừng lại

Đây không phải một đòn đánh vào những tên tuổi sẵn có. Canny, Featurebase, Fider và UserVoice làm tốt phần thu thập, gộp trùng và xếp hạng, và họ có nhiều năm mài giũa đúng những chỗ quan trọng với các nhóm sản phẩm. Cả bốn dừng ở cùng một điểm vì cùng một lý do cấu trúc: chúng được xây cho những tổ chức mà bộ phận kỹ thuật nằm ở phòng ban khác, chỉ với tới được qua một lần xuất dữ liệu.

Dòng cuối mới là dòng quyết định. Trong một đội lớn, viết lại một yêu cầu thành đặc tả là công việc thật với giá trị thật, và khâu xuất dữ liệu không phải nút thắt. Trong một đội một tới năm người ra sản phẩm bằng tác nhân lập trình, chính việc viết lại đó là nút thắt, và nó lỗ trắng.

Những gì cách này không giải quyết

Một bảng phản hồi nối thẳng vào tác nhân không phải chế độ lái tự động, và coi nó như vậy thì bạn nhận đúng cái kết ai cũng đoán ra.

Ticket tệ vẫn cho ra công việc tệ. Một báo lỗi một dòng không kèm đường tái hiện thì chẳng cho tác nhân thứ gì để bấu víu, và nó sẽ tự tin làm sai. Cái bảng chỉ chuyển tiếp được đúng những gì đã viết ra.

Không có gì tự hợp nhất. Tác nhân tạo ra một nhánh và một cái diff, và mọi quy tắc bạn từng đặt ra về việc duyệt kết quả của tác nhân vẫn còn nguyên giá trị, nhất là với những gì chạm vào xác thực, thanh toán hay dữ liệu. Một ticket đến từ người lạ không phải lý do để hạ chuẩn. Đó là lý do để nâng chuẩn lên.

Và khối lượng là chuyện có thật. Một bảng công khai thành công thì sẽ ồn ào, đó là vấn đề đẹp nhưng có giá thật. Ticket trùng được đánh dấu ngay lúc gửi, lượt bình chọn tách được thứ một người muốn khỏi thứ bốn mươi người muốn, và đóng một ticket kèm lý do viết ra vẫn nhanh hơn để nó mục ruỗng. Nhưng vẫn phải có người đọc hộp thư đến.

Dựng nó lên

Mở backlog của một dự án, bấm Public backlog, chọn một URL và một chế độ hiển thị. Toàn bộ phần thiết lập chỉ có vậy, và trang đã chạy ngay từ lúc đó.

Việc bạn làm sau đó còn quan trọng hơn phần thiết lập. Hãy đặt đường liên kết ở nơi người dùng của bạn vốn đã có mặt: trong ứng dụng, trong các câu trả lời hỗ trợ, ở cuối ghi chú phát hành. Một bảng phản hồi không ai biết tới thì chẳng thu được gì, và kiểu hỏng của tính năng này không nằm ở kỹ thuật, nó nằm ở chỗ cái liên kết chẳng bao giờ được chia sẻ.

AgentsRoom là trung tâm điều khiển mà tất cả những thứ này chạy trên đó: một bảng công việc nơi một cái thẻ trở thành một tác nhân đang chạy, một trang phản hồi công khai hoặc riêng tư nối thẳng vào đó, một widget nhúng, một tiện ích Chrome, và các thông báo cho khách hàng bắn đi đúng lúc công việc thực sự lên sản phẩm. Nó hoạt động với Claude Code, Codex, OpenCode, Antigravity CLI, Aider, Grok Build, Mistral Vibe và Kimi Code.

Tải AgentsRoom và xuất bản cái bảng đầu tiên của bạn.

Các câu hỏi thường gặp

Bảng phản hồi cho tác nhân AI là gì?

Một trang công khai để người dùng báo lỗi và đề xuất tính năng, được nối thẳng vào chính bảng công việc mà các tác nhân lập trình của bạn thực thi. Khác biệt so với một công cụ phản hồi cổ điển nằm ở bước cuối: thay vì xuất yêu cầu sang một hệ quản lý issue rồi viết lại thành prompt, bản thân cái ticket trở thành đề bài của tác nhân, đúng bằng lời của người đã báo.

Một ticket của người dùng có thực sự tự nó khởi chạy được một tác nhân AI không?

Việc khởi chạy vẫn là một hành động có chủ ý: ai đó kéo ticket sang In Progress, và tác nhân được sinh ra với ticket làm prompt. Thứ diễn ra tự động là khâu định tuyến, đưa ticket mới đến đúng tác nhân có chuyên môn khớp với nó. Còn để mọi thứ một người lạ viết ra tự động chạy thẳng thì đó không phải tính năng, đó là một lỗ hổng bảo mật.

Cái này khác gì Canny, Featurebase, Fider hay UserVoice?

Những công cụ đó rất giỏi thu thập, gộp trùng và xếp hạng nhu cầu, và tất cả đều dừng ở cùng một chỗ: chúng trao cho bạn một danh sách đã ưu tiên, rồi vẫn phải có người biến từng dòng thành công việc. Chúng không có lớp thực thi vì được xây cho những nhóm sản phẩm mà kỹ sư ngồi ở nơi khác. Ở đây, canh bạc là điều ngược lại: bề mặt thu thập và bề mặt thực thi là cùng một đối tượng.

Có bắt buộc phải công khai lộ trình sản phẩm mới dùng được không?

Không. Công khai, không lập chỉ mục và chỉ theo lời mời là ba chế độ riêng biệt. Một agency chạy mỗi khách hàng một bảng sẽ dùng chế độ chỉ theo lời mời, và không công cụ tìm kiếm nào nhìn thấy nó. Một lập trình viên đơn lẻ muốn nhận yêu cầu và lượt bình chọn từ người dùng thì chọn công khai. Phần thực thi hoạt động y như nhau trong cả ba.

Điều gì ngăn một bảng công khai ngập trong nhiễu?

Không gì ngăn được nhiễu kéo đến, và nói khác đi thì thiếu thành thật. Thứ mà cái bảng thay đổi là chi phí xử lý đống nhiễu đó: các ticket gần trùng được đánh dấu ngay khi gửi, lượt bình chọn cho bạn biết cái gì thực sự được mong đợi, và một ticket bạn không định làm thì đóng lại kèm lý do gửi tới tận tác giả. Những ticket bạn giữ lại thì đến nơi cùng với ngữ cảnh mà một người lạ đã viết sẵn cho bạn.