Phần lớn công việc code vẫn bắt đầu bằng một câu trong group chat. "File export CSV bị mất dòng cuối." "Thêm SSO trước buổi demo được không?" "Prod lại đang trả 500 ở bước checkout nữa rồi." Ai đó thả một cái thumbs-up, có thể một coding agent được trỏ tới nó, và ba ngày sau không ai nói được nó đã ship chưa, ai đã review, hay commit nào đã fix nó. Tin nhắn trôi đi. Công việc trở thành giai thoại.
Khoảng trống đó là vấn đề cấu trúc, không phải vấn đề kỷ luật. Một tin nhắn chat không có người phụ trách, không có trạng thái, không có acceptance test, và không có liên kết tới diff giải quyết nó. Trỏ một coding agent vào tin nhắn đó là bạn đã tạo ra công việc không thể truy vết. Mọi thứ còn tệ hơn khi bạn chạy nhiều hơn một agent, vì lúc đó bạn cũng không nói được agent nào đã động vào nó.
Bài viết này sẽ đi qua cách biến một tin nhắn chat thành một code task có thể truy vết: một thiết lập tự làm (DIY) tối giản cho bạn được gì, nó dừng mở rộng ở đâu, và một lớp task dùng chung thêm vào điều gì. Sharkly là workspace dành cho phiên bản truy vết được, vì nó nằm phía trên các coding agent của bạn và giữ mục tiêu, lượt chạy, các blocker, diff, và review của con người trong cùng một bản ghi. Bạn đã có coding agent rồi. Việc cần làm là biến công việc của chúng thành thứ cả team có thể theo dõi.
Vì sao chat là nơi code task chết dần
Một group chat tối ưu cho tốc độ trò chuyện, tức là ngược lại với thứ mà một code task cần. Một task thực thụ mang theo mục tiêu được nêu rõ, người phụ trách, tiêu chí nghiệm thu, một trạng thái bạn có thể truy vấn, và một liên kết ngược về thay đổi đã đóng nó. Một tin nhắn chat không mang gì trong số đó. Nó chỉ mang một timestamp và một reaction.
Chế độ thất bại rất cụ thể. Một yêu cầu đến, được đồng ý một cách không chính thức ngay trong thread, rồi thread tiếp tục trôi. Hai ngày sau ai đó hỏi "mình đã fix cái bug export đó chưa nhỉ?" và câu trả lời đòi hỏi phải tìm kiếm trên Slack, phỏng đoán, và cuộn qua một channel nơi cụm từ y hệt xuất hiện tới chín lần. Kể cả khi tìm thấy tin nhắn, nó cũng không cho bạn biết bản fix đã merge chưa. Cuộc trò chuyện và code nằm ở hai hệ thống riêng biệt chưa từng biết tên nhau.
Trỏ một coding agent tự hành vào tin nhắn đó và vết truy vết còn ngắn hơn nữa. Agent đọc một dòng Slack, chạy trong terminal trên laptop của ai đó, sửa file, rồi báo lại vào chính cái thread trôi nhanh đã nuốt mất yêu cầu kia. Giờ bạn có một execution log không ai lưu, một thay đổi không ai liên kết, và một quyết định không ai ghi lại.
Pipeline DIY, và điểm nó ngừng mở rộng
Bạn không cần một sản phẩm để bắt đầu. Một pipeline tự làm khả thi sẽ như thế này: copy tin nhắn chat, paste vào coding agent như một prompt, để nó làm việc trong một Git worktree tách biệt để không đụng vào checkout chính, và mở một pull request liên kết ngược về một tracking issue với dòng Closes #123. Đó là truy vết thật, và với một developer solo xử lý từng yêu cầu một, nó thường là đủ.
Đây là cặp quyết định trung thực. Nếu bạn chỉ có một người, chạy một agent, đóng xong một task trước khi sang task kế tiếp, thì vòng lặp copy-paste-rồi-sang-worktree là hiệu quả và bạn không nên thêm tooling vào đó. Chi phí của một hệ thống dùng chung sẽ tốn hơn giá trị mà nó mang lại.
Thiết lập này ngừng mở rộng ngay khi hai điều cùng đúng một lúc: hai agent đang chạy, hoặc hai người đang điều phối công việc, hoặc hai repository cùng tham gia. Lúc đó pipeline thủ công bắt đầu xuất hiện lỗ hổng:
| Điều gì vỡ | Vì sao vòng lặp DIY không che được |
|---|---|
| "Agent nào đang giữ bug export?" | Việc phân công sống trong đầu bạn, không nằm trong một bản ghi |
| "Cái này xong rồi hay vẫn đang chạy?" | Trạng thái là cái terminal bạn đã đóng, không phải một trường có thể truy vấn |
| "Ai đã approve thay đổi auth?" | Việc phê duyệt là một cái thumbs-up, giờ đã trôi đi |
| "Diff cho yêu cầu Slack đó đâu?" | PR liên kết tới một issue, nhưng issue chẳng bao giờ liên kết tới yêu cầu |
| "Agent thực sự đã thay đổi gì?" | Run log sống trong một session đã kết thúc |
Mỗi lỗ hổng là một chỗ mà task lại trở nên không thể truy vết. Bạn có thể vá chúng bằng tay với nhiều issue hơn, quy ước đặt tên, và kỷ luật. Cách đó hiệu quả cho tới khi nó không còn hiệu quả, và nó thất bại âm thầm — cách thất bại tệ nhất của một quy trình.
"Có thể truy vết" nghĩa là gì khi task được chia sẻ
Truy vết được không phải là một cảm giác. Mọi câu hỏi về một mẩu công việc đều có câu trả lời nằm ở một chỗ và tồn tại lâu hơn những người đã online khi nó bắt đầu. Một task truy vết được sẽ giữ ngữ cảnh, phân công, tiến độ, blocker, kết quả, và review của con người luôn hiển thị từ lúc yêu cầu đến lúc release.
Sharkly mô hình hóa điều này thành một Task, đơn vị công việc chính trong hệ thống. Một Task không phải là tin nhắn chat và cũng không phải một terminal session. Nó là bản ghi dùng chung mà một tin nhắn chat trở thành khi bạn quyết định hành động dựa trên nó. Mục tiêu nằm trong phần mô tả. Một Agent hoặc một người trở thành Assignee. Quá trình thực thi của Agent, các blocker, kết quả, và phần thảo luận tiếp theo đều quay về timeline của Task thay vì biến mất vào một terminal riêng tư. Khi thay đổi được land, pull request được liên kết bằng ID, để yêu cầu và diff cuối cùng cũng biết tên nhau.
Có một ranh giới cần lưu ý, vì người đọc có thể hiểu sai. Sharkly không thay thế Claude Code, Codex, hay các coding agent khác của bạn. Những công cụ đó thực hiện việc thực thi. Sharkly bổ sung lớp task dùng chung, ngữ cảnh, và review bao quanh chúng. Agent vẫn viết code. Sharkly khiến công việc có thể giao được và truy vết được.
Biến một tin nhắn chat thành task truy vết được với Sharkly
Workflow đủ ngắn để bạn nhớ trong đầu. Bắt đầu với một tin nhắn thật, ví dụ bug export CSV, và đưa nó ra khỏi channel:
- Ghi lại tin nhắn thành một Task. Tạo một Task với yêu cầu làm mục tiêu. Nếu chat của bạn nằm trên Slack, một Slack bot cho coding agent sẽ biến mention thành một Task mà không cần rời khỏi thread.
- Định hình nó để một Agent có thể thực thi. Một báo cáo bug dài một dòng không phải là một spec có thể thực thi. Thêm bước tái hiện, hành vi mong đợi, và một acceptance test. Cùng kỷ luật như quản lý task cho AI agent: một Task mà Agent có thể đóng cần một mô tả mà Agent có thể hành động dựa trên đó.
- Giao nó và để Agent chạy. Agent nhận Task, làm việc trong một worktree tách biệt để công việc song song không đụng nhau, và stream tiến độ về cho Task. Bạn đang xem một bản ghi, không phải một terminal.
- Review và chấp nhận. Agent đính kèm tóm tắt thay đổi, kết quả test, và các giới hạn đã biết. Một người chấp nhận, yêu cầu thay đổi, hoặc đưa ra quyết định merge.
Bước cuối cùng là phần đáng được nói rõ: Agent nghiên cứu, thực thi, test, và báo cáo. Con người định hướng, trao quyền, và chấp nhận kết quả. Tự động hóa dừng lại ở đúng nơi cần đến phán đoán của team. Một task truy vết được khiến việc bàn giao đó trở nên khả thi, vì người review thay đổi nhìn thấy toàn bộ đường đi từ yêu cầu đến diff. Khi công việc xong, bạn có thể theo dõi những gì agent đã hoàn thành mà không cần dựng lại từ ký ức. Đó chính là cùng một xương sống như một workflow từ yêu cầu đến code hoàn chỉnh, chỉ khác là bắt đầu từ một mẩu chat thay vì một ticket chính thức.
Bạn có thể tự xây một phiên bản của quy trình này bằng tay với issue và worktree, hoặc dùng Sharkly để quản lý workflow sao cho vết truy vết vẫn giữ được khi khối lượng công việc tăng lên.
Checklist bạn có thể chạy ngay hôm nay
Hãy chạy checklist này với thiết lập hiện tại của bạn. Mỗi ô chưa tick là một chỗ mà một task sinh ra từ chat có thể mất dấu:
- [ ] Mọi yêu cầu chat được xử lý đều trở thành một Task có người phụ trách, không phải một emoji reaction.
- [ ] Mỗi Task có một mô tả mà Agent có thể thực thi: repro, hành vi mong đợi, acceptance test.
- [ ] Mỗi Agent đang chạy làm việc trong một worktree tách biệt, để hai task không bao giờ đụng vào cùng file.
- [ ] Run log, blocker, và kết quả của Agent quay về Task, không phải vào một terminal rồi đóng lại.
- [ ] Pull request được liên kết với Task bằng ID, để yêu cầu và diff chỉ cách nhau một cú click.
- [ ] Một người chấp nhận hoặc từ chối kết quả, và quyết định đó được ghi lại trên Task.
- [ ] Bạn có thể trả lời "cái này xong chưa, ai làm, và diff ở đâu?" mà không cần tìm kiếm trong chat.
Khi xử lý từng yêu cầu một, vòng lặp thủ công tự nó đã đạt được phần lớn các mục này. Khi chạy nhiều agent trong một team, Sharkly cho bạn một chỗ để quản lý task và kết quả của chúng. Tải Sharkly và chuyển một yêu cầu chat thật thành một Task trước khi bạn giao cả channel cho nó.
FAQ
Tôi có cần Sharkly để làm cho các task sinh ra từ chat trở nên truy vết được không? Không. Một developer đơn lẻ chạy một agent đã có được truy vết thật từ một worktree cộng với một pull request liên kết tới một issue. Mô hình AI agent inbox bắt đầu đáng giá khi bạn có nhiều agent hoặc nhiều người và các liên kết thủ công bắt đầu trượt.
Điều gì khiến một tin nhắn chat khó được coding agent thực thi? Nó thường thiếu bước tái hiện, một kết quả mong đợi, và một acceptance test. Biến "export bị lỗi" thành "export CSV làm mất dòng cuối; mong đợi N dòng, nhận được N-1; xong khi số dòng khớp." Giờ Agent đã có thứ để đóng lại.
Cái này khác gì một hệ thống ticketing thông thường? Một ticket theo dõi công việc mà con người sẽ làm. Một code task truy vết được còn mang theo execution log của Agent, lượt chạy tách biệt của nó, và diff được liên kết, nên bản ghi bao trùm cả quyết định lẫn thay đổi. Xem coding agent có con người trong vòng lặp để biết con người giữ vai trò ở đâu trong vòng lặp.
Sharkly có đọc trực tiếp channel Slack của tôi không? Bạn kết nối một Sharkly Agent vào Slack để một mention trở thành một Task. Cuộc trò chuyện vẫn ở lại Slack; bản ghi công việc truy vết được nằm trong Sharkly.
