Bạn có biết điều mà người tạo ra Claude Code cho là quan trọng nhất không?
Đó không phải là cách viết prompt. Cũng không phải là lựa chọn mô hình.
"Hãy cho Claude phương tiện để tự kiểm tra đầu ra của nó."
Đây là điều duy nhất. Anh ấy khẳng định đây là mẹo quan trọng nhất để sử dụng Claude Code.
Bài viết này là sự tiếp nối của cuộc thảo luận đó. Chúng ta hiểu nguyên tắc này. Vậy, làm thế nào để cụ thể cung cấp những phương tiện đó? Câu trả lời là các máy chủ MCP.
Thành thật mà nói, biết hay không biết điều này thực sự thay đổi trải nghiệm sử dụng Claude Code. Thời gian dành cho việc dán tài liệu, sao chép issue, và tự mở màn hình để kiểm tra—tất cả đều trở nên không cần thiết.
Bạn có đang gặp những điều này với Claude Code không?
- Mã được tạo ra sử dụng cú pháp cũ, và bạn tự sửa nó mỗi lần.
- Bạn lại phải tự mở trình duyệt để xem màn hình vừa tạo có hoạt động không.
- Bạn sao chép nội dung issue, dán vào Claude, yêu cầu nó triển khai, sau đó lại quay lại viết tiến độ.
- Mỗi khi có lỗi production, bạn lại sao chép stack trace từ Sentry.
- Bạn biết từ MCP nhưng chưa thiết lập gì vì không biết nên thêm cái gì.
Đúng vậy. Tôi cũng đã làm tất cả những điều đó.
Tôi sẽ nói trước: ngay cả những người không thể code cũng có thể đọc bài viết này. Tôi sẽ giải thích các thuật ngữ kỹ thuật khi chúng xuất hiện. Thực tế, MCP là một hệ thống mà những người không phải kỹ sư có thể thấy lợi ích lớn hơn.
Khi bạn đọc xong, có khả năng bạn sẽ muốn tìm một nơi trong công việc của mình mà bạn đang "sao chép và dán mỗi lần."
Hãy lưu lại bài viết này.
"Boris" thực sự là ai?
Boris Cherny. Anh ấy là người đã tạo ra Claude Code.
Anh ấy nói rõ ràng "Tôi đã tạo ra Claude Code", vì vậy không có gì phải nghi ngờ. Anh ấy là người hiểu triết lý thiết kế của Claude Code ở mức sâu nhất.
Cách sử dụng của anh ấy thật phi thường.
Đầu tiên, anh ấy đã không viết code bằng tay trong một thời gian dài. Thay vào đó, anh ấy chạy khoảng năm phiên Claude trong terminal và thêm năm đến mười phiên trên web cùng lúc, đánh số các tab và quản lý Claude nào đang chờ phản hồi của con người thông qua thông báo.
(Hãy tưởng tượng bạn có 15 cấp dưới, tất cả đang làm các nhiệm vụ khác nhau, và chỉ những người gặp khó khăn mới đến gọi bạn.)
Hơn nữa, CLAUDE.md của anh ấy—cuốn sổ tay quy tắc dự án—chỉ dài khoảng 100 dòng. Anh ấy không phải kiểu người viết một lượng lớn các quy tắc.
Câu nói được trích dẫn thường xuyên nhất của anh ấy là:
"Đừng viết prompt. Hãy viết vòng lặp."
Thay vì tìm cách hỏi một cách tử tế, hãy tạo một môi trường nơi Claude có thể tự động luân chuyển qua các nhiệm vụ. Đây là cốt lõi trong triết lý của anh ấy.
3 Nguyên Tắc Mà Boris Nhắc Đi Nhắc Lại
Nhìn vào các bài đăng của anh ấy, anh ấy nói những điều tương tự một cách nhất quán.
Nguyên tắc 1: Hãy cho Claude phương tiện để tự kiểm tra đầu ra của nó.
Anh ấy gọi đây là "mẹo quan trọng nhất." Lời giải thích của anh ấy rất dễ hiểu:
Nếu bạn yêu cầu ai đó xây dựng một trang web nhưng cấm họ sử dụng trình duyệt, điều gì sẽ xảy ra? Sẽ không có gì tốt đẹp cả.
Nhưng nếu bạn đưa cho họ một trình duyệt, họ sẽ xây dựng, xem xét, sửa lỗi, xem lại, và lặp lại cho đến khi nó tốt.
Claude cũng vậy. Nếu bạn cung cấp cho nó phương tiện để kiểm tra, nó sẽ tự lặp lại cho đến khi hài lòng.
Nguyên tắc 2: Biến các tác vụ được thực hiện hơn một lần mỗi ngày thành hệ thống.
Giải thích cùng một quy trình trong chat mỗi lần là lãng phí thời gian, vì vậy hãy biến nó thành một Skill hoặc một lệnh. Vì chi phí để giữ nó sẵn sàng cho đến khi được gọi gần như bằng không, nên không có hại gì khi tạo ra nó.
Nguyên tắc 3: Đưa các công cụ bên ngoài vào không gian làm việc của Claude Code.
Slack, trình theo dõi issue, cơ sở dữ liệu, API nội bộ. Bằng cách làm cho những thứ này có thể truy cập trực tiếp từ Claude Code, sự di chuyển giữa các công cụ biến mất.
Đây là lúc MCP xuất hiện.
Cuối cùng
Khi nói về MCP, bạn luôn gặp phải rào cản này.
Khoảnh khắc bạn kết nối MCP, bàn tay của Claude Code sẽ chạm tới môi trường production. Triển khai, DNS, thanh toán, dữ liệu khách hàng. Đọc thì được, nhưng nếu bạn đột nhiên cho phép ghi hoặc xóa, tai nạn sẽ xảy ra.
Vậy, bạn ủy thác ở đâu, và con người xác minh ở đâu?
Tôi đang tặng miễn phí một biểu đồ ranh giới. Tôi muốn bạn xem nó một lần trước khi cài đặt MCP.
👇
MCP là gì trong một câu?
Hãy làm rõ điều này trước.
MCP là một "giao diện chung để kết nối các công cụ AI và dịch vụ bên ngoài." Hãy nghĩ về nó như một chuẩn USB.
Trong một thế giới không có điều này, bạn sẽ cần phải xây dựng các tích hợp riêng biệt cho Claude, ChatGPT và các AI khác. Với chuẩn MCP, một nhà cung cấp dịch vụ xây dựng nó một lần và nó có thể được sử dụng bởi tất cả các công cụ AI tương thích.
Và để nói rõ, MCP không chỉ thêm các tính năng cho Claude Code.
Nó mang chính mục tiêu công việc vào bên trong Claude Code.
Bản thiết kế Figma, lỗi Sentry, ticket Linear, log production Cloudflare—Claude nhìn thấy chúng trực tiếp và chạm vào chúng trực tiếp. Đó là lý do tại sao việc sao chép-dán biến mất.
Và bây giờ, chuẩn này đã thay đổi đáng kể.
Sự Thay Đổi Trong Các Điều Kiện Tiên Quyết Của MCP
Điều này vẫn chưa được tổ chức tốt trong cộng đồng Nhật Bản, vì vậy hãy lưu ý.
Trong bản cập nhật thông số kỹ thuật mới nhất, MCP đã trải qua cuộc đại tu lớn nhất kể từ khi phát hành. Dưới đây là bốn thay đổi chính:
Không trạng thái (Statelessness). Các MCP từ xa trước đây được thiết kế để máy chủ duy trì trạng thái kết nối. Điều đó đã biến mất; bây giờ nó là kiểu yêu cầu-phản hồi như HTTP tiêu chuẩn. Lợi ích là nó chạy trực tiếp trên các môi trường serverless hoặc edge. MCP giờ đây có thể được xây dựng như một hệ thống mở rộng quy mô theo truy cập thay vì một máy chủ thường trực duy nhất.
Hỗ trợ các tiến trình chạy dài (Long-running processes). Giả định rằng một công cụ trả về kết quả ngay lập tức đã bị loại bỏ. Nó có thể trả về một mã theo dõi trước, cho phép kiểm tra tiến trình, cập nhật và hủy bỏ sau đó. Di chuyển mã quy mô lớn, tạo video, phân tích dữ liệu dài và triển khai toàn bộ môi trường—những "tác vụ mất hàng giờ" này giờ đây được hỗ trợ chính thức thông qua MCP.
Khả năng trả về UI trong cuộc hội thoại. Trước đây, MCP tập trung vào văn bản và JSON, nhưng bây giờ máy chủ có thể trả về màn hình hoạt động. Màn hình chọn mục tiêu triển khai, biểu đồ, nút phê duyệt/từ chối, biểu mẫu. Nói tóm lại, MCP đang chuyển từ một hệ thống nơi AI gọi API ở chế độ nền sang một chuẩn cho các ứng dụng nhỏ chạy trên nền tảng AI.
Xác thực cấp tổ chức. Được liên kết với các nhà cung cấp danh tính doanh nghiệp, một khi quản trị viên phê duyệt, nhân viên sẽ tự động kết nối khi đăng nhập lần đầu. Việc phân phối khóa API cho từng cá nhân biến mất.
Lưu ý rằng phía Anthropic đang triển khai điều này theo trình tự. Việc thông số kỹ thuật được hoàn thiện là khác với việc Claude Code cục bộ của bạn có thể sử dụng mọi thứ ngay lập tức.
(Thỉnh thoảng tôi thấy các bài báo phóng đại điều này, nhưng cách diễn đạt chính thức là "đang triển khai theo trình tự.")
Có hơn 950 máy chủ MCP được liệt kê trong danh sách kết nối của Claude. Con số này thật choáng ngợp, nhưng thực sự không có nhiều đến vậy mà bạn thực sự cần cài đặt.
8 Máy Chủ MCP Chính Thức Biến Đổi Claude Code
Đây là phần chính.
Tiêu chí lựa chọn gồm ba điều: chúng phải là máy chủ chính thức do nhà cung cấp quản lý, dễ dàng cho người mới bắt đầu cảm nhận được hiệu quả, và triển khai trực tiếp một trong ba nguyên tắc của Boris.
- Context7 MCP: Loại bỏ nguyên nhân gây ra mã lỗi thời
Khi Claude Code xuất ra mã không chính xác, nguyên nhân thường không phải do mô hình thiếu thông minh.
Đó chỉ là do thông tin mà nó tham chiếu đã cũ.
Sử dụng các API đã ngừng hoạt động. Xuất ra cú pháp Next.js cũ. Trộn lẫn các cài đặt từ các phiên bản khác nhau. Tạo ra các tùy chọn không tồn tại. Điền vào các triển khai không có trong tài liệu bằng cách phỏng đoán. Tất cả đều là vậy.
Context7 là một MCP cung cấp tài liệu mới nhất cho các thư viện và framework cho Claude Code theo phiên bản. Thay vì trả lời từ bộ nhớ, bạn tạo ra trạng thái nơi nó triển khai sau khi tra cứu tài liệu của phiên bản cụ thể.
Prompt thực tế:
Sử dụng Context7, kiểm tra tài liệu chính thức cho phiên bản hiện tại của Next.js được sử dụng trong dự án này.
Sau khi kiểm tra, hãy sắp xếp những điều sau trước khi bắt đầu triển khai:
- Triển khai được khuyến nghị cho phiên bản hiện tại
- Các triển khai đã ngừng hoạt động
- Sự khác biệt so với mã dự án hiện tại
- Các tệp yêu cầu sửa đổi
Không triển khai dựa trên phỏng đoán; chỉ sử dụng các phương pháp được mô tả trong tài liệu.
Lưu ý: Không trộn lẫn nhiều khái niệm trong một truy vấn. Hỏi về "auth, routing và caching" sẽ trả về kết quả rộng và nông. Độ chính xác sẽ tốt hơn khi bạn kéo từng khái niệm riêng biệt.
Kho lưu trữ chính thức: https://github.com/upstash/context7
- Playwright MCP: Cho Claude chạm vào chính trình duyệt
Điều này triển khai trực tiếp Nguyên tắc 1 của Boris.
Claude Code có thể viết mã, nhưng nó không biết liệu màn hình nó viết ra có thực sự hoạt động hay không. Kết nối Playwright MCP cho phép Claude mở một trình duyệt thực, nhấp vào nút, điền biểu mẫu, theo dõi chuyển hướng, bắt lỗi, sửa lỗi và kiểm tra lại.
Điều thú vị về hệ thống này là nó không chỉ xem ảnh chụp màn hình dưới dạng hình ảnh. Nó đọc Cây Trợ năng (Accessibility Tree)—thông tin có cấu trúc của màn hình. Nó hiểu cái gì là nút, trường nhập liệu hay tiêu đề. Bởi vì nó đọc ý nghĩa, nên ít có khả năng nhầm lẫn các yếu tố trực quan giống nhau.
Prompt thực tế:
Khi triển khai hoàn tất, hãy mở môi trường cục bộ với Playwright MCP.
Thực sự vận hành và xác minh những điều sau:
- Đăng ký mới
- Đăng nhập
- Hiển thị trong quá trình nhập lỗi
- Vỡ bố cục ở chiều rộng điện thoại thông minh
- Đăng xuất
Nếu thất bại, đừng đoán nguyên nhân chỉ bằng cách đọc mã; hãy tái tạo nó trong trình duyệt trước khi sửa.
Sau khi sửa, hãy chạy lại các thao tác tương tự và chỉ báo cáo hoàn thành sau khi xác nhận thành công.
Tôi sẽ thành thật ở đây.
Điều mà chính Boris nói rằng anh ấy sử dụng mọi lúc cho công việc web thực ra là tiện ích mở rộng trình duyệt Claude Code, chứ không phải Playwright MCP. Anh ấy nói rằng nó ổn định hơn các MCP tương tự vì nó có thể chia sẻ trạng thái đăng nhập như hiện tại.
Vì vậy, trường hợp sử dụng là: nếu bạn muốn kiểm tra màn hình thực tế bằng trình duyệt đã đăng nhập của mình, hãy sử dụng tiện ích mở rộng. Nếu bạn muốn tự động hóa nó như một bài kiểm tra và chạy cùng một quy trình nhiều lần, hãy sử dụng Playwright MCP.
Cả hai đều chia sẻ cùng một triết lý: "Hãy cho Claude một trình duyệt."
Kho lưu trữ chính thức: https://github.com/microsoft/playwright-mcp
- Figma MCP: Đọc dữ liệu thiết kế, không chỉ hình ảnh
Khi bạn truyền thiết kế dưới dạng ảnh chụp màn hình, Claude luôn phải phỏng đoán.
Lề là bao nhiêu pixel? Cỡ chữ là bao nhiêu? Màu này là màu thương hiệu hay màu tạm thời? Phần này có phải là một component có thể tái sử dụng không? Tất cả đều được phỏng đoán bằng mắt thường từ một hình ảnh.
Kết nối Figma developer MCP cho phép truy cập trực tiếp vào thông tin thiết kế có cấu trúc. Giá trị, màu sắc, cấu trúc component, design token. Sự phỏng đoán biến mất.
Prompt thực tế:
Truy xuất frame hiện đang được chọn từ Figma MCP.
Đầu tiên, chỉ trích xuất những điều sau và không bắt đầu triển khai:
- Cấu trúc trang
- Các component cần được tái sử dụng
- Định nghĩa màu sắc và kiểu chữ
- Quy tắc về lề
- Những thay đổi dự kiến trong quá trình co giãn đáp ứng
Sau khi xác nhận nội dung đã trích xuất, hãy ưu tiên sử dụng các component dự án hiện có để triển khai.
Nếu tạo một component mới, hãy giải thích trước tại sao các component hiện có không đủ.
Và đây là phần thực sự quan trọng.
Kéo thiết kế từ Figma, triển khai trong Claude Code, kiểm tra trong Playwright, sửa nếu hỏng. Kết nối ba điều này biến thiết kế thành xác minh thành một dòng duy nhất.
Giá trị của MCP được hiểu rõ hơn trong sự kết nối này hơn là riêng lẻ.
Tài liệu chính thức: https://developers.figma.com/docs/figma-mcp-server/
- Linear MCP: Đọc ticket và viết tiến độ
Boris nhắc đến đồng nghiệp của mình trong các PR với @claude và yêu cầu nó thêm bài học vào sổ tay quy tắc. Nói tóm lại, anh ấy không tách biệt không gian quản lý issue khỏi không gian làm việc của AI.
Kết nối Linear MCP chính thức cho phép tìm kiếm, tạo, cập nhật và bình luận về các issue hoàn toàn trong Claude Code. Vì nó là một kết nối từ xa do Linear lưu trữ với xác thực, bạn không cần phải giữ một máy chủ chạy trên PC của mình.
Điều này làm cho quy trình sau trở nên liền mạch:
Đọc Issue → Điều tra mã liên quan → Tạo kế hoạch triển khai → Triển khai → Kiểm tra → Bình luận tiến độ trên Issue → Cập nhật trạng thái
Prompt thực tế:
Kiểm tra các issue được gán cho tôi đang trong quá trình thực hiện trong Linear.
Sau khi sắp xếp thứ tự ưu tiên và sự phụ thuộc, hãy thực hiện những điều sau cho issue có mức ưu tiên cao nhất:
- Xác định thông tin còn thiếu trong yêu cầu
- Điều tra mã liên quan
- Tạo một kế hoạch triển khai và trình bày nó trước khi triển khai
- Triển khai và kiểm tra sau khi được phê duyệt
- Bình luận các hành động đã thực hiện trên Issue
Vui lòng chờ xác nhận của tôi trước khi thay đổi trạng thái.
Luôn bao gồm dòng cuối cùng đó. Nếu bạn để nó tự động hóa các thay đổi trạng thái, bạn sẽ kết thúc với "công việc chưa hoàn thành được đánh dấu là đã hoàn thành" từ quan điểm của các thành viên khác trong nhóm.
Tài liệu chính thức: https://linear.app/docs/mcp
- Sentry MCP: Theo dõi nguyên nhân mà không cần dán lỗi
Bạn làm gì khi xảy ra lỗi production?
Mở Sentry, sao chép stack trace, dán nó vào Claude, tìm tệp bạn nghi ngờ, dán nó luôn. Không có điều nào trong số đó là cần thiết.
Giá trị của Sentry MCP không chỉ là hiển thị danh sách lỗi. Nó đặt nội dung lỗi, stack trace, tần suất, người dùng bị ảnh hưởng, nó đến từ bản phát hành nào, mã liên quan và các lỗi tương tự trong quá khứ vào một vòng lặp điều tra duy nhất.
Prompt thực tế:
Truy xuất lỗi chưa được giải quyết có nhiều người dùng bị ảnh hưởng nhất trong 24 giờ qua từ Sentry.
Điều tra theo thứ tự sau:
- Phân tích các điều kiện xảy ra
- Xác định mã liên quan
- Tạo một bài kiểm tra tái tạo
- Nếu có thể tái tạo, hãy triển khai một bản sửa lỗi tối thiểu
- Chạy tất cả các bài kiểm tra
- Tóm tắt nguyên nhân gốc rễ và cách sửa lỗi
Nếu không thể tái tạo, đừng sửa dựa trên phỏng đoán. Hãy liệt kê thông tin bổ sung cần thiết để thu hẹp nguyên nhân và dừng lại ở đó.
Câu "Nếu không thể tái tạo, đừng sửa dựa trên phỏng đoán" rất hiệu quả. Nếu không có nó, một bản sửa lỗi có vẻ hợp lý có thể được áp dụng trong khi nguyên nhân gốc rễ vẫn còn và nó sẽ báo cáo là "đã sửa."
Tài liệu chính thức: https://docs.sentry.io/product/sentry-mcp/
- Cloudflare MCP: Hiển thị trạng thái của môi trường triển khai
Cho đến nay chúng ta đã nói về phát triển, nhưng cái này là về vận hành.
Cloudflare đã phát hành nhiều máy chủ MCP chính thức để vận hành các dịch vụ của mình. Kiểm tra cài đặt, quản lý Worker, phân tích log, cài đặt DNS, cài đặt bảo mật, kiểm tra hiệu suất. Nó được thiết kế không chỉ để đọc, mà còn để đề xuất và thực sự thực hiện các thay đổi.
Điều này có nghĩa là Claude Code có thể cải thiện mã sau khi thấy nó hoạt động như thế nào tại điểm đến triển khai.
Prompt thực tế:
Kiểm tra trạng thái môi trường production hiện tại với Cloudflare MCP.
Điều tra:
- Lỗi trong 24 giờ qua
- Thời gian phản hồi
- Tỷ lệ cache hit
- Sự kiện bảo mật
- Các ngoại lệ xảy ra trong Worker
Sau đó, phân loại các vấn đề thành hai loại sau:
A. Những vấn đề yêu cầu thay đổi mã
B. Những vấn đề có thể cải thiện chỉ bằng cài đặt Cloudflare
Trong cả hai trường hợp, luôn trình bày một kế hoạch trước khi thực hiện thay đổi. Không thay đổi cài đặt cho đến khi tôi phê duyệt.
Vì điều này chạm đến cơ sở hạ tầng, hãy giới hạn ở chế độ chỉ đọc trong quá trình giới thiệu ban đầu. Không cần phải cho phép thay đổi cài đặt ngay từ đầu.
Tài liệu chính thức: https://developers.cloudflare.com/agents/model-context-protocol/cloudflare/servers-for-cloudflare/
- Stripe MCP: Kết hợp mã thanh toán với cài đặt Stripe
Lý do việc triển khai thanh toán khó khăn là vì bạn không thể biết câu trả lời đúng chỉ bằng cách nhìn vào mã. Bạn phải kiểm tra những sản phẩm và giá nào được đăng ký ở phía Stripe và cách webhook được thiết lập trong một tab khác trong khi viết.
Stripe MCP chính thức bao gồm tìm kiếm tài liệu chính thức và thông tin hỗ trợ ngoài các thao tác API Stripe. Triển khai, xác minh cài đặt và tham khảo tài liệu đều diễn ra ở cùng một nơi.
Hơn nữa, Stripe cung cấp Skills cho các agent ngoài MCP. Vận hành với MCP và thực thi các phương pháp hay nhất với Skills. Sự kết hợp này rất mạnh mẽ.
Prompt thực tế:
Sử dụng Stripe MCP và tài liệu Stripe chính thức, tạo một kế hoạch triển khai cho tính năng đăng ký hàng tháng.
Đảm bảo bạn kiểm tra những điều sau:
- Cấu hình Sản phẩm và Giá
- Cách tạo Checkout Session
- Các sự kiện sẽ được nhận qua Webhook
- Quy trình hủy
- Hành vi trong quá trình thanh toán thất bại
- Các phương pháp ngăn chặn đăng ký trùng lặp
- Phương pháp kiểm thử
Chỉ sử dụng chế độ test của Stripe trong quá trình làm việc. Không thực hiện bất kỳ thay đổi nào đối với dữ liệu production.
Không bao giờ xóa hai dòng cuối cùng đó. Đây không phải là một MCP để chạy với những cánh cổng đó mở.
Tài liệu chính thức: https://docs.stripe.com/mcp
- GitHub MCP: Đóng vòng lặp phản hồi review
Cuối cùng là cái này.
Nhưng xin đừng hiểu lầm; giá trị của GitHub MCP không phải là "có thể chạy các lệnh git." Claude Code đã có thể chạm vào git cục bộ và GitHub CLI.
Giá trị đến khi duyệt qua thông tin chỉ tồn tại ở phía từ xa: chi tiết issue, nhận xét review PR, kết quả CI, trạng thái của các kho lưu trữ khác, tìm kiếm mã nội bộ và các cuộc thảo luận trong quá khứ.
Prompt thực tế:
Kiểm tra PR tương ứng với nhánh hiện tại bằng GitHub MCP.
Lấy tất cả các nhận xét review chưa được giải quyết và phân loại chúng thành ba loại sau:
- Những thứ phải sửa
- Những thứ yêu cầu quyết định thiết kế mà tôi nên quyết định
- Những thứ được đánh giá là không cần sửa (bao gồm lý do)
Chỉ triển khai "những thứ phải sửa" và vượt qua các bài kiểm tra.
Không chạm vào những thứ yêu cầu quyết định thiết kế; thay vào đó, hãy sắp xếp các điểm tranh luận và các tùy chọn và trình bày chúng.
Đọc nhận xét review, sửa lỗi, kiểm tra và báo cáo—tất cả đều được đóng trong Claude Code.
Kho lưu trữ chính thức: https://github.com/github/github-mcp-server
Xây Dựng Một "Stack", Không Chỉ Là Các Công Cụ Đơn Lẻ
MCP kém hiệu quả hơn khi được thêm vào từng cái một. Nó biến đổi khi được sắp xếp theo quy trình làm việc.
Stack Sản Xuất Web:
Kéo thiết kế từ Figma → Kiểm tra cú pháp chính xác hiện tại với Context7 → Triển khai trong Claude Code → Xác minh trình duyệt với Playwright → PR và phản hồi review trên GitHub → Triển khai và kiểm tra log trên Cloudflare
Stack Phát Triển SaaS:
Kéo yêu cầu từ Linear → Kiểm tra thông số kỹ thuật với Context7 → Triển khai trong Claude Code → Thiết lập và xác minh thanh toán với Stripe → Kiểm tra thao tác người dùng với Playwright → Giám sát lỗi production với Sentry
Điều đang xảy ra:
Trong cả hai stack, quy trình đều giống nhau.
Lấy thông tin, lập kế hoạch, xây dựng, tự kiểm tra, phản ánh ra bên ngoài, xem kết quả.
Vòng lặp này được đóng lại mà không cần rời khỏi Claude Code.
Nguyên tắc "Hãy cho nó phương tiện để kiểm tra" của Boris không chỉ là về một trình duyệt. Nó có nghĩa là cung cấp cho nó phương tiện để xác nhận tính đúng đắn của từng bước trong quy trình.
Người Mới Chỉ Cần Ba Điều Này
Tôi không nói là cài đặt tất cả tám cái. Làm điều đó sẽ dẫn bạn đến những cạm bẫy trong chương tiếp theo.
Giai đoạn 1: Context7
Mục tiêu là giảm mã không chính xác.
Vì nó tập trung vào đọc, nên rủi ro thấp. Bắt đầu ở đây là an toàn nhất và cho phép bạn cảm nhận được hiệu quả nhanh nhất.
Giai đoạn 2: Playwright hoặc Tiện ích mở rộng Trình duyệt
Mục tiêu là để Claude tự xác minh kết quả đầu ra.
Nếu bạn đang làm công việc web, điều này thay đổi mọi thứ đáng kể. Xây dựng, mở, tìm lỗi, sửa, mở lại. Con người không còn cần phải ở giữa.
Giai đoạn 3: Linear hoặc GitHub
Mục tiêu là kết nối đầu vào và đầu ra của công việc.
Từ ticket đến triển khai, PR và cập nhật tiến độ. Tại thời điểm này, Claude Code thay đổi từ một "người viết mã chờ hướng dẫn" thành một "thành viên tự mình thúc đẩy công việc tiến lên."
Ba điều này là đủ. Nghiêm túc đấy.
Cạm Bẫy Bạn Phải Đọc
Cạm bẫy 1: Nhiều MCP hơn không làm cho nó thông minh hơn
Đây là quan niệm sai lầm lớn nhất.
Nếu bạn kết nối một số lượng lớn MCP, số lượng công cụ ứng viên mà Claude có thể chọn sẽ tăng lên. Điều gì xảy ra sau đó?
Nó bị nhầm lẫn về việc nên sử dụng cái nào. Nó tiêu tốn context. Nó nhầm lẫn các công cụ tương tự. Nó thực hiện các thao tác bạn không yêu cầu. Quản lý quyền trở nên phức tạp và bạn mất dấu những gì được phép.
Thay vì kết nối 100, bạn sẽ nhận được kết quả tốt hơn bằng cách chỉ kích hoạt 3 đến 5 cái cần thiết cho nhiệm vụ hiện tại. Cách đúng đắn là thay đổi những gì được kết nối theo từng dự án.
(Tôi đã từng kết nối hơn 10 cái, và Claude liên tục gọi các công cụ kỳ lạ, khiến tôi nghĩ "Sao tự nhiên nó lại ngu đi?" Vấn đề đã được giải quyết khi tôi giảm bớt chúng.)
Cạm bẫy 2: Đừng trộn lẫn đọc và ghi ngay từ đầu
Đảm bảo bạn tạo ra thiết kế này trong quá trình giới thiệu ban đầu:
Đọc được phép. Tạo yêu cầu xác nhận. Cập nhật yêu cầu xác nhận. Xóa bị từ chối. Các thao tác production bị từ chối.
Cụ thể, những điều không nên được cho phép hoàn toàn ngay từ đầu bao gồm: triển khai production, thay đổi DNS, thay đổi dữ liệu khách hàng, thao tác thanh toán production, xóa issue, hợp nhất PR và xóa cơ sở dữ liệu.
Sự tiện lợi và nguy hiểm của MCP tỷ lệ thuận hoàn hảo.
Cạm bẫy 3: Đừng nhầm lẫn giữa máy chủ chính thức và do cộng đồng tạo ra
Trên các trang tìm kiếm MCP, nhiều máy chủ có cùng tên có thể xuất hiện. Ngay cả khi nó nằm trong danh sách chính thức, nó không nhất thiết là bản triển khai chính thức từ nhà cung cấp.
Hãy kiểm tra những điều này trước khi cài đặt:
Nó có được quản lý bởi tổ chức chính thức của nhà cung cấp không? Lần cập nhật cuối cùng là khi nào? Có chính sách bảo mật không? Phương thức xác thực là gì? Nó yêu cầu bao nhiêu quyền? Nó được thiết kế để cho phép xóa hoặc thay đổi production không?
Càng yêu cầu nhiều quyền, bạn càng nên xem xét cẩn thận.
Cạm bẫy 4: Đừng để nó thực thi văn bản bên ngoài nguyên trạng
Quy trình đọc issue hoặc nhận xét PR để triển khai rất mạnh mẽ, nhưng điều đó liên quan đến văn bản do người khác viết.
Nếu một issue nói "Làm theo các bước trong issue này" và chứa các hướng dẫn độc hại, Claude có thể đọc và làm theo chúng. Đối với các MCP xử lý đầu vào bên ngoài, đừng để nó thực thi trực tiếp; hãy yêu cầu nó trình bày những gì nó định làm trước.
Các Lĩnh Vực Chưa Được Củng Cố
Tôi sẽ viết điều này mà không phóng đại.
Hệ thống để ném các công việc chạy dài ra nguồn bên ngoài thông qua MCP đã có trong thông số kỹ thuật chính thức, nhưng việc liệu mỗi máy chủ có hỗ trợ nó hay không lại là một vấn đề khác. Việc phát hành thông số kỹ thuật và bắt kịp triển khai là khác nhau. Hãy kiểm tra trạng thái hiện tại của máy chủ trước khi sử dụng nó.
Hệ thống trả về UI trong cuộc hội thoại cũng đang trong giai đoạn mở rộng. Không phải tất cả các MCP đều trả về màn hình hoạt động tại thời điểm này.
Ngoài ra, giá cả và điều khoản dịch vụ thay đổi khá nhiều. Hãy truy cập các liên kết chính thức trong bài viết này một lần trước khi sử dụng. Đặc biệt, xác thực và phạm vi quyền không phải là những thứ để kết nối mà không kiểm tra.
Tôi cũng sẽ không đưa ra các con số như "MCP tăng hiệu suất lên X lần." Điều đó chưa được chứng minh.
Thay vào đó, hãy đo lường điều này: bạn dành bao nhiêu phút mỗi ngày cho việc sao chép-dán, chuyển đổi màn hình và xác minh trực quan? Đó là những gì biến mất với MCP.
Những Gì Cần Làm Hôm Nay
Đừng cố gắng làm mọi thứ. Chỉ một điều.
Hãy nhìn lại công việc của bạn và tìm một nơi mà bạn đang "qua lại giữa Claude Code và một màn hình khác."
Nó có thể là tài liệu. Nó có thể là một issue. Nó có thể là một màn hình lỗi. Nó có thể là một thiết kế.
Chỉ cài đặt MCP loại bỏ một điều đó. Hãy cảm nhận hiệu quả, sau đó thêm cái tiếp theo.
Nguyên tắc của Boris cuối cùng cũng quy về điều này: Hãy cho Claude phương tiện để kiểm tra công việc của chính nó. Khoảnh khắc bạn đưa ra, Claude bắt đầu tự chạy cho đến khi nó hài lòng.
Trong khi bạn dừng lại, bạn sẽ sao chép cùng một thứ hôm nay và dán nó vào cùng một màn hình. Khoảnh khắc nó di chuyển, chuyến đi khứ hồi đó sẽ không bao giờ quay trở lại.
Tối nay, hãy mở Claude Code và nghĩ về chỉ một màn hình bạn thường xuyên di chuyển đến nhất.
Mọi thứ đều bắt đầu từ đó.
