Phần lớn bài viết về AI trong công việc nói về chuyện gõ nhanh hơn. Đó chưa bao giờ là vấn đề của mình.
Vấn đề của mình là khoảng bảy mươi quy trình lặt vặt chỉ nằm trong đầu đúng một
người, và người đó là mình. Dựng lại một booking hỏng từ bốn nguồn log khác
nhau. Chạy SQL vào một database production mà client mysql tiêu chuẩn còn
không kết nối tới được. Dựng lại đúng cái request đã gửi lên nhà cung cấp khi
trong tay chỉ có mỗi cái trace-id. Kiểm tra xem một tính năng đã thật sự vào đủ
mười một repo mà nó động tới chưa.
Hỏi mình thì có câu trả lời. Rút mình ra khỏi team thì việc đứng.
Nên thứ mình tự động hoá không phải code. Là những quy trình vây quanh code.
Nguyên tắc 1 — làm tới lần thứ hai thì biến nó thành lệnh
Một slash command trong Claude Code là một file markdown mà phần nội dung chính là cái prompt. Đúng một điều đó là toàn bộ mẹo: runbook và tool thôi không còn là hai thứ rời nhau rồi lệch dần. Viết quy trình ra chính là ship cái tự động hoá.
Hai bộ cho hai team, cộng lại 42 lệnh, tính cả repo thứ ba thì khoảng 70 runbook:
Số dòng quan trọng hơn số lệnh. Bốn nghìn dòng prompt là bốn nghìn dòng cạm bẫy đã có người trả giá — đúng loại thứ không bao giờ lên tới wiki, vì ngồi viết nó ra giống như thừa nhận mình vừa mất toi một buổi chiều.
Nguyên tắc 2 — thứ mình cắt được là số bước, không phải số phím gõ
Đây là cái mà mấy lệnh đó thật sự gộp lại. Mỗi con số là số thứ khác nhau mà một người phải chọn giữa, phải mở, hoặc phải chạy — đọc thẳng từ thân runbook, không phải bấm đồng hồ đo:
Cái go-live là rõ nhất. Một tính năng đụng tới tiền có thể nằm rải trên mười một
repo; sót một cái là hệ thống thu thiếu của khách mà không văng lỗi ở đâu cả.
Kiểm bằng tay là mười một lần git log cộng với sự tập trung tuyệt đối. Kiểm
bằng lệnh là một dòng, và cái lệnh thì không chán ở repo thứ mười một.
Nguyên tắc 3 — nhãn nguy hiểm dán ở mục lục, không chôn trong thân bài
Rủi ro khi đưa cho một agent quyền chạy lệnh không phải là nó làm sai. Rủi ro là nhìn lướt bốn mươi lệnh, bạn không phân biệt được cái nào nguy hiểm. Nên mọi lệnh đều mang mức sát thương của nó ngay trên mục lục:
Với mọi thứ nằm ở dải giữa, quy trình là cố định và nó nằm trong tool, không nằm trong đầu người: dry run → in kế hoạch → xin xác nhận → thực thi → đọc lại để verify. Trong phần quy ước có một câu mình tâm đắc nhất:
Lệnh nào bỏ qua một bước là bug của lệnh đó — đi sửa lệnh, đừng lách bằng cách làm tay.
Khi "thôi lần này thôi" bị coi là một bug report chứ không phải một lối tắt, cái rào chắn mới sống sót qua được một ngày xấu trời.
Hai chi tiết đã được cơ khí hoá, quan trọng hơn vẻ ngoài của chúng. Trước mọi
thao tác ghi, lệnh chạy SELECT @@hostname, @@read_only và in kết quả ra cho
người xem — vì config local mỗi máy một khác, và có vài service commit sẵn
file config trỏ thẳng vào production. Và sự đồng ý hết hạn ngay trong lượt:
"lần trước họ đồng ý rồi" không tính.
Nguyên tắc 4 — một cổng tất định chạy trước khi bất kỳ model nào được review
Thứ nặng nhất mình đang chạy là một pipeline nhiều agent để sinh tài liệu mapping API của nhà cung cấp. Hình dạng của nó mới là phần đáng lấy:
Ba quyết định trong đó đáng đồng tiền:
Phiên orchestrator không làm nội dung. Nó cầm một whitelist chỉ-đọc rất chặt và đi giao việc. Một phiên vừa viết tài liệu vừa chấm tài liệu thì lần nào cũng sẽ duyệt chính nó.
Một script tất định chạy trước mọi reviewer là LLM. Cái gì script kiểm được — schema, trường bắt buộc, tham chiếu gãy — thì script kiểm, và kiểm trước. Bạn không thuyết phục được một cái script. Chỉ thứ sống sót qua script mới đáng để một model bỏ công đọc.
Fixer là một agent riêng chỉ cầm Edit. Cái tìm ra vấn đề không phải cái
được phép sửa file.
Nguyên tắc 5 — agent để phản bác, không phải agent để gật
Kiểu hỏng mặc định khi nhờ một model review là nó thấy bạn nghe cũng có lý. Nên bước review bị lật ngược: mỗi phát hiện được giao cho một agent có nhiệm vụ ghi rõ là phản bác nó, và mặc định kết luận "không có thật" khi chưa chắc. Chỉ cái nào sống sót mới được báo lên.
Tỉ lệ khá phũ, và đó chính là điểm cần: phần lớn thứ ra từ lượt đầu đều nghe hợp lý và sai. Chạy một cuộc điều tra theo kiểu này, khoảng bốn trên năm phát hiện chết trước khi có người đọc tới. Số còn lại thì đáng để họp.
Cùng cái phản xạ đó xuất hiện trong hai bộ lệnh dưới dạng một mục bắt buộc: mọi kết quả audit đều phải kết thúc bằng "chỗ mình không chắc". Nó tốn đúng một đoạn văn, và nó là khác biệt giữa một tài liệu đồng nghiệp xây tiếp lên được với một tài liệu họ phải đi verify lại từ đầu.
Nguyên tắc 6 — năm việc giờ chạy không cần mình
Năm job headless chạy theo lịch, tự viết worklog và báo cáo tuần từ git, ticket và chat. Mỗi job tự verify đầu ra của chính nó trước khi động vào một file được track — một job chạy tự động mà ghi ra file hỏng lúc 7 giờ sáng thì còn tệ hơn là không có job nào.
Con số mình không có
Bạn sẽ thấy ở đây không có câu "tiết kiệm 40% thời gian".
Mình chưa bao giờ đo nó, nên mình sẽ không đăng nó. Toàn bộ ở trên đều là số đếm: file, dòng, repo, bước, agent, job. Mấy cái đó mình dựng lại được ngay trước mặt bạn.
Mình có giữ một file chi phí, mỗi con số trong đó đều mang nhãn đo được hay ước tính, kèm ngày và nguồn — trong đó có một lần tối ưu được ghi lại như một thất bại, kèm phép tính hoàn vốn viết ra đàng hoàng. Một con số ước tính bị người đọc sau hiểu thành số đo là cách nhanh nhất để mất niềm tin vào cả tài liệu, và cái cám dỗ đăng một con số đẹp mà chưa đo chính là thứ mà toàn bộ cái bộ khung này sinh ra để chặn.
Nếu phải gọi tên cái lợi thật sự, nó không phải số giờ. Nó là mấy cái quy trình thôi không còn nằm trong một cái đầu nữa — kể cả những ngày cái đầu đó đi nghỉ.
Những gì mình không giao
- Kết luận nguyên nhân gốc khi một phần mắt xích nằm ngoài phạm vi. Nếu hai mắt xích nằm ở repo mình không đọc được, đầu ra trung thực là hai giả thuyết còn lại và câu query phân biệt chúng — không phải một câu trả lời chắc nịch.
- Bấm gửi. Mail ra ngoài thì soạn nháp, không gửi.
sudo. Lệnh được đưa lại cho mình; mình chạy.- Bất cứ thứ gì mà bằng chứng duy nhất là "nhìn có vẻ đúng". Không đọc lại sau khi ghi thì coi như chưa làm.
Không có cái nào ở trên là cẩn thận cho vui. Chúng cùng một luật nằm dưới cả sáu nguyên tắc: một model rất giỏi tạo ra thứ trông giống câu trả lời, và toàn bộ việc của cái bộ khung này là làm cho khác biệt đó lộ ra trước khi nó lên tới production.