Các nhà máy phần mềm (software factories) đang rất thịnh hành trong vài tuần gần đây. Và tôi đã xây dựng một cái.
Đây là những gì tôi đã học được, cách nó hoạt động và cách bạn có thể xây dựng một cái chỉ trong một buổi chiều.
Mục tiêu của tôi
Nó cần phải thực sự đơn giản, một thứ gì đó hoạt động tốt mà không cần phải trông nom quá nhiều. Lý tưởng nhất là nó sẽ chạy hoàn toàn trên gói Claude hiện tại của tôi.
Nghe có vẻ ngây thơ, nhưng về cơ bản, trừ khi nó tích hợp dễ dàng vào quy trình làm việc hiện tại của tôi, thì nó sẽ không phải là thứ tồn tại lâu dài. Tôi không muốn xây dựng thứ này và phải thay đổi tất cả thói quen hiện tại chỉ để sử dụng hệ thống mới này. Tôi biết từ kinh nghiệm rằng nếu điều đó xảy ra, nó sẽ không hiệu quả với tôi về lâu dài và sẽ dần trở nên lỗi thời.
Vì vậy, thay vì tiếp cận điều này như một nỗ lực lớn duy nhất, tôi đã chia nó thành hai giai đoạn riêng biệt:
- Tiền phân loại (Pre-triage) - xác định những việc "cần làm"
- Triển khai (Implementation) - thực sự "làm" những việc đó
Trung tâm là Linear, nguồn dữ liệu chính xác cho biết công việc cần được thực hiện.
Mọi nhà máy phần mềm đều cần có kho lưu trữ tập trung các công việc cần làm, cho dù đó là GitHub issues, Linear hay thứ gì khác. Nó phải là thứ bạn đã sử dụng để có thể dễ dàng mở rộng cho bất kỳ hệ thống nào thêm công việc để các agent hoặc con người nhận và hoàn thành sau đó.
Linear với một issue được tự động tạo ra qua vòng lặp System Health Check
Đường ống (pipeline) có các điểm kết nối (seams) được xác định rõ ràng nhằm giúp quá trình xây dựng một nhà máy phần mềm trở nên khả thi:
- Tạo công việc (các vòng lặp với MCPs)
- Lưu trữ công việc (Linear)
- Hoàn thành công việc (SDLC agent)
Bằng cách chia nhỏ ra, bạn không phải xây dựng cả phần tiền phân loại và phần triển khai cùng một lúc (và tôi thực sự khuyên bạn không nên làm vậy để tránh thiết kế quá mức cần thiết). Linear tạo ra một giao diện rõ ràng giữa việc "cần làm" và việc chúng ta đang "làm", đồng thời dễ dàng mở rộng.
Bước Tiền Phân Loại
Trong sơ đồ trên, công việc tiến triển từ trái sang phải. Phía bên trái là nơi công việc được tạo ra và chứa bất kỳ số lượng hệ thống nào (con người, agent hoặc API) thêm vào những việc cần làm. Tất cả đầu ra được tạo ra trong bước tiền phân loại này đều được đưa vào Linear của chúng tôi.
Một vài vòng lặp chạy trong môi trường đám mây của Claude
Trong bước này, chúng ta có ba vòng lặp chính:
- Vòng lặp Kiểm tra Sức khỏe Hệ thống (System Health Check Loop - tức công cụ tìm lỗi) - vòng lặp này chạy hàng ngày lúc 5 giờ sáng và được kết nối với một vài máy chủ MCP: Posthog để theo dõi lỗi; Vercel để chẩn đoán hệ thống; và Linear để tạo issue.
- Vòng lặp Cải tiến UX và Phản hồi Khách hàng (UX Improvements and Customer Feedback Loop) - vòng lặp này chạy hàng tuần vào Thứ Hai lúc 9 giờ sáng, và quét mọi phản hồi mới, mọi cuộc trò chuyện hỗ trợ khách hàng từ Intercom/Fin, và tất cả các bản ghi lại phiên (session replays) của Posthog. Các bản ghi lại phiên là một mỏ vàng. Bạn có thể thấy nơi xảy ra các cú nhấp chuột vì tức giận (rage clicks) hoặc nơi người dùng đang gặp khó khăn và bối rối.
- Vòng lặp Phân tích Khách hàng Rời bỏ (Churn Analysis Loop) - vòng lặp này chạy hàng ngày lúc 6 giờ sáng và điều tra mọi khách hàng đã nhấp vào hủy trong 24 giờ qua. Nó lấy dữ liệu thanh toán và người dùng từ Stripe (bao gồm email/vị trí của họ), sau đó xem bản ghi lại phiên của khách hàng này trong Posthog để xem họ đã làm gì trước khi hủy. Chúng tôi lấy dữ liệu sử dụng của họ từ Supabase để xem liệu đó có phải là ICP sai (wrong ICP), họ chưa bao giờ trải nghiệm khoảnh khắc "wow" đó, hay gặp phải lỗi. Báo cáo được gửi đến Slack và agent sẽ tạo (hoặc bình luận về) các issue nếu chúng liên quan đến việc khách hàng rời bỏ để tăng mức độ ưu tiên.
Để thực sự chạy các agent này một cách nhất quán, tôi đã giữ mọi thứ đơn giản và sử dụng Claude Code Cloud Routines.
Không thiết kế quá mức với một VPS Hetzner, một chiếc Mac mini caffein hóa, v.v... Đây là cách dễ dàng nhất mà tôi tìm thấy để tận dụng gói đăng ký Claude Code hiện có của bạn và tạo ra các agent luôn hoạt động, có thể được kích hoạt theo lịch trình hoặc qua một sự kiện webhook. Và cho tất cả những người nói "nhưng mà phụ thuộc vào nhà cung cấp (vendor lock in) thì sao!!" - nó chỉ là một vài dòng chữ thôi. Hãy thoải mái sao chép prompt đến bất cứ đâu bạn muốn, tôi chỉ muốn thứ dễ dàng và rẻ nhất để thiết lập mà hoạt động đáng tin cậy.
Và một lý do khác để sử dụng Claude Code Cloud Routines là môi trường đám mây của Anthropic có sự tương đồng gần với Claude chạy cục bộ.
Cloud Claude Routines
Rõ ràng là chúng không có các biến môi trường của bạn (có thể được thêm vào thiết lập môi trường đám mây, nếu cần) nhưng nếu bạn thiết lập kết nối MCP qua các bộ kết nối (connectors) của Ứng dụng Máy tính để bàn, cả CLI Claude cục bộ và Claude từ xa đều có thể sử dụng chúng, không giống như Codex. Đây là tính năng quan trọng đối với tôi và là thứ làm cho các vòng lặp agent tiền phân loại này hoạt động hiệu quả. Nó cũng giúp dễ dàng chạy nhiều phiên song song mà không phải lo lắng về bộ nhớ máy tính xách tay của bạn.
Nếu bạn chỉ triển khai bước tiền phân loại này, bạn vẫn sẽ nhận được rất nhiều lợi thế ngay cả khi bạn không xây dựng bước tiếp theo nơi công việc được hoàn thành.
Hãy bắt đầu nhỏ với một vòng lặp duy nhất, thử nghiệm nó, tinh chỉnh nó, sau đó thêm nhiều hơn. Xác định những quy trình (routines) bạn có thể tạo ra ngay hôm nay để đưa công việc mới, chất lượng cao vào hệ thống theo dõi issue hiện tại của bạn và sau đó làm bất cứ điều gì bạn hiện đang làm để triển khai.
Bước Triển Khai
Phiên bản cơ bản nhất của bước hai là cung cấp cho agent của bạn một ID issue và nói nó hãy hoàn thành nó. Đây là những gì hầu hết mọi người đã làm khi làm việc với các agent, tuy nhiên, nó có thể không phải là thứ bạn muốn nếu bạn đang đọc bài này, bởi vì bây giờ bạn là nút thắt cổ chai (bottleneck) trong vòng lặp, trực tiếp khởi chạy một agent trong một phiên.
Thay vào đó, những gì tôi đã làm là xây dựng một cách để kích hoạt các phiên Claude Code từ xa trực tiếp từ Linear.
Đi từ issue Linear đến Claude
Nó hoạt động như sau:
- Đầu tiên, xác định cách bạn muốn kích hoạt một phiên Claude mới. Đối với chúng tôi, chúng tôi thêm nhãn 'auto' vào một issue Linear để bắt đầu công việc mới này.
- Sau đó, Linear gửi một sự kiện webhook đến dịch vụ API webhook nội bộ của chúng tôi (một ứng dụng Hono nội bộ mới được tạo) để phân tích cú pháp sự kiện và sau đó chuyển tiếp thông tin chính xác đến Claude Routine.
- Cuối cùng, dịch vụ API nhẹ này thực hiện một yêu cầu POST đến Anthropic để kích hoạt Claude routine với một prompt ban đầu.
Sử dụng nhãn 'auto' làm trình kích hoạt cho phép chúng tôi kiểm soát việc thực thi tự động các phiên Claude mới.
Theo mặc định, chúng tôi không để các bước tiền phân loại bao gồm các nhãn 'auto' này và yêu cầu một con người thêm nhãn để kích hoạt agent bắt đầu công việc (giữ con người trong vòng lặp). Đó là lý do tại sao chúng tôi gọi bước 1 là bước tiền phân loại, bởi vì một thứ gì đó vẫn đang xác định xem thực sự nên làm việc gì, thông qua sự tham gia của con người hoặc một số vòng lặp agent theo dõi các issue mới được thêm vào và khởi chạy các phiên triển khai mới.
Tuy nhiên, vì việc thêm nhãn cũng dễ dàng được thực hiện bởi một agent, chúng tôi có thể để các vòng lặp tiền phân loại tạo các issue mới với nhãn 'auto' theo mặc định, từ đó khởi chạy một phiên Claude mới. Sử dụng nhãn trở thành một cách rất linh hoạt để bắt đầu công việc triển khai mới, hoặc tự động bởi một agent hoặc bởi con người chúng ta.
Một dịch vụ định tuyến nhẹ để khởi chạy các phiên Claude
Bởi vì Linear hỗ trợ webhooks, toàn bộ cơ chế "đẩy khi một nhãn được thêm vào" hoạt động được. Hạn chế duy nhất là chúng ta cần có một API công khai để định tuyến chấp nhận các webhook này và định dạng các sự kiện và dữ liệu tải trọng để kích hoạt Claude Code. Dịch vụ mới này cũng thêm các header xác thực chính xác, đó là lý do tại sao bạn không thể để Linear kích hoạt routine trực tiếp.
Ngoài ra, bạn có thể có một routine theo lịch trình bắt đầu sau mỗi khoảng thời gian nhất định và cố gắng triển khai bất kỳ issue mới nào chưa được xử lý có nhãn auto.
Đối với prompt routine thực tế, tôi khuyên bạn nên xây dựng một kỹ năng có thể tái sử dụng (reusable skill) hướng dẫn toàn bộ SDLC, đặt tên giống như /implement hoặc /do, giúp bạn dễ dàng chỉ cần nói "/do ISSUE-NNN", điều này ghi lại cách thực hiện chính xác các bước lấy ngữ cảnh issue, triển khai công việc, xác minh trong trình duyệt, tạo PR và theo dõi các bình luận.
Sau đó, prompt Claude routine, được kích hoạt bởi sự kiện Linear, chỉ có thể có một prompt rất đơn giản. Đây là prompt của tôi:
Hãy lấy issue được cung cấp và sử dụng kỹ năng /do để triển khai thay đổi được yêu cầu và tạo một pull request. Chỉ tìm nạp chính xác issue đã được cung cấp. Nếu issue đó đã hoàn thành hoặc đang trong quá trình xử lý, hãy dừng lại.
Tham chiếu issue không xuất hiện trong tin nhắn này — nó đến dưới dạng một tin nhắn theo dõi riêng biệt được bọc trong thẻ \
<routine-fire-payload>\, được gửi ngay sau tin nhắn này, trong cùng một phiên làm việc. Hãy đợi tin nhắn đó trước khi quyết định xem một issue có được cung cấp hay không. Chỉ kết luận rằng issue không tồn tại, hoặc không có issue nào được đưa ra, sau khi kiểm tra nó trong tin nhắn \<routine-fire-payload>\và xác nhận rằng issue được tham chiếu thực sự không tồn tại.Khi bạn bắt đầu công việc, hãy bình luận về issue, đặt trạng thái của nó thành "Đang xử lý" và cập nhật issue với bất kỳ thông tin có ý nghĩa nào khi bạn tiến triển. Luôn tiền tố các bình luận issue Linear bằng [Claude].
Vậy là lúc này bạn đã có các phiên Claude Remotion song song được kích hoạt qua API, triển khai các issue, mở PR (và hy vọng là xác minh công việc của họ qua Playwright hoặc Agent Browser).
Về cơ bản, đó là một nhà máy phần mềm hoàn chỉnh, có thể quan sát đầy đủ, chạy trong khi bạn ngủ và hoạt động hoàn toàn trên gói đăng ký Claude Code của bạn.
