Kirat - Multi Model AI Council

01 — Phát lại

Xem hội đồng làm việc.

Bản ghi thật của các công cụ Kirat, được thực hiện vào ngày 13 tháng 10 năm 2026 với phiên bản bạn mua. Chọn một công cụ và xem hội đồng làm việc: các quan điểm độc lập, kiểm tra chéo, xếp hạng ẩn danh và ý kiến thiểu số. Đây là bản phát lại: không có gì bạn nhấp vào đây gọi đến mô hình nào, và không có gì rời khỏi trang này. Đoạn chat được viết để minh họa và chỉ nhắc lại kết quả đã ghi; những gì Claude gửi cho Kirat và những gì nhận về được hiển thị nguyên vẹn trong mục “Hậu trường”.

Năm câu hỏi từ các lĩnh vực khác nhau. Chọn một.

Để Kirat bỏ phiếu về điều này: Tôi tự vận hành một SaaS B2B nhỏ. Tôi có nên thêm gói miễn phí không?

kirat_vote đã hỏi hội đồng

Hội đồng đã quyết định (đa số 2:1): Chỉ giữ gói trả phí, không thay đổi gì.

Phiếu của chính tôi là ý kiến thiểu số: “Chỉ giữ gói trả phí, kéo dài thời gian dùng thử lên 30 ngày”. Nó được lưu lại cùng lý do, để bạn tự cân nhắc.

Hậu trường

kirat_vote Những gì Claude gửi cho Kirat

Câu hỏi: Tôi tự vận hành một SaaS B2B nhỏ. Tôi có nên thêm gói miễn phí không?

GHI NGÀY 2026-10-13 · KIRAT_VOTE · MỨC ĐỘ: TIÊU CHUẨN · 1 VÒNG

Ngữ cảnh đã gửi: Lập trình viên độc lập. Công cụ xuất hóa đơn cho người làm tự do, 19 USD mỗi tháng, dùng thử miễn phí 14 ngày, 30 khách hàng trả phí sau 5 tháng. Đăng ký chủ yếu đến từ hai bài blog xếp hạng trên Google. Khoảng 12% lượt dùng thử chuyển đổi. Hỗ trợ đã chiếm khoảng 5 giờ mỗi tuần. Lập trình viên có công việc chính và khoảng 10 giờ mỗi tuần cho sản phẩm.

Lựa chọn: Thêm gói miễn phí · Chỉ giữ gói trả phí, kéo dài thời gian dùng thử lên 30 ngày · Chỉ giữ gói trả phí, không thay đổi gì

Kết quả từ hội đồng

gpt-5.6 độ tin cậy 88

Chỉ giữ gói trả phí, không thay đổi gìGói miễn phí có khả năng làm tăng số người dùng không trả phí và tải hỗ trợ, vốn đã chiếm một nửa trong 10 giờ mỗi tuần hiện có. Tỷ lệ chuyển đổi dùng thử 12% là khá tốt, nên không có bằng chứng rõ ràng rằng độ dài thời gian dùng thử là nút thắt. Giữ mô hình hiện tại và dành thời gian khan hiếm để giảm nhu cầu hỗ trợ và mở rộng thu hút khách hàng ngoài hai bài blog.

gemini-3.6-flash độ tin cậy 90

Chỉ giữ gói trả phí, không thay đổi gìVới chỉ 10 giờ mỗi tuần, hỗ trợ đã chiếm 50% năng lực. Gói miễn phí sẽ làm tăng khối lượng hỗ trợ từ người dùng không trả phí mà không có cách kiểm soát. Tỷ lệ chuyển đổi dùng thử 12% đã là mạnh; nút thắt là lưu lượng truy cập, không phải mô hình định giá.

claude (người bỏ phiếu thứ ba) độ tin cậy 58

Chỉ giữ gói trả phí, kéo dài thời gian dùng thử lên 30 ngàyGói miễn phí chủ yếu làm tăng tải hỗ trợ, vốn đã chiếm một nửa thời gian hiện có. Xuất hóa đơn là theo tháng, nên thời gian dùng thử 14 ngày có thể kết thúc trước khi người làm tự do gửi hóa đơn thứ hai và thấy được giá trị. Thời gian dùng thử 30 ngày bao trùm một chu kỳ thanh toán đầy đủ mà không thêm người dùng miễn phí vĩnh viễn.Ý kiến thiểu số, đã ghi lại

Quyết định Chỉ giữ gói trả phí, không thay đổi gì Đường đi đa số 2:1 Chi phí $0.015

Để Kirat bỏ phiếu về điều này: Cửa hàng trực tuyến của khách hàng chúng tôi cần được xây lại. Xây lại trên WooCommerce hay chuyển sang Shopify?

kirat_vote đã hỏi hội đồng

Hội đồng đã quyết định (nhất trí 3:0): Chuyển sang Shopify.

Cả ba quan điểm, kể cả của tôi, đều chỉ về cùng một hướng. Mỗi quan điểm đều kèm lý do.

Hậu trường

kirat_vote Những gì Claude gửi cho Kirat

Câu hỏi: Cửa hàng trực tuyến của khách hàng chúng tôi cần được xây lại. Xây lại trên WooCommerce hay chuyển sang Shopify?

GHI NGÀY 2026-10-13 · KIRAT_VOTE · MỨC ĐỘ: TIÊU CHUẨN · 1 VÒNG

Ngữ cảnh đã gửi: Chúng tôi là một agency kỹ thuật số nhỏ. Khách hàng bán khoảng 1.800 sản phẩm nội thất tại Đức, Áo và Thụy Sĩ, có 3 nhân viên và không có lập trình viên nội bộ. Cửa hàng hiện tại là một bản cài WooCommerce tự lưu trữ, đã 6 năm, với 31 plugin, trang chậm và hai sự cố bảo mật trong năm qua. Doanh thu khoảng 1,2 triệu EUR mỗi năm. Khách hàng muốn giảm bảo trì và ít tình huống khẩn cấp hơn; họ dùng một ERP cục bộ xuất dữ liệu sản phẩm dưới dạng CSV. Ngân sách cho việc xây lại: 25.000 EUR.

Lựa chọn: Xây lại trên WooCommerce · Chuyển sang Shopify

Kết quả từ hội đồng

gpt-5.6 độ tin cậy 89

Chuyển sang ShopifyShopify phù hợp hơn với các mục tiêu chính của khách hàng: giảm bảo trì, ít sự cố bảo mật khẩn cấp hơn và không cần lập trình viên nội bộ. Danh mục 1.800 sản phẩm và quy trình ERP dựa trên CSV là khả thi, và ngân sách 25.000 EUR nên đủ cho một cuộc chuyển đổi có kỷ luật cùng việc thiết lập thuế, thanh toán và pháp lý riêng cho khu vực DACH. Các đánh đổi là chi phí ứng dụng/nền tảng định kỳ, ít linh hoạt hơn ở phần backend và cần xác thực quy trình nhập ERP cùng các biến thể đặc thù cho nội thất trước khi cam kết. Xây lại WooCommerce có thể giữ được tính linh hoạt, nhưng sẽ vẫn phải chịu trách nhiệm về lưu trữ, cập nhật, tương thích plugin và bảo mật—đúng gánh nặng vận hành mà khách hàng muốn giảm bớt.

gemini-3.6-flash độ tin cậy 90

Chuyển sang ShopifyKhông có lập trình viên nội bộ, 3 nhân viên và lịch sử có sự cố bảo mật, Shopify giảm mạnh chi phí bảo trì và rủi ro bảo mật. Ngân sách 25.000 € đủ cho việc chuyển sang Shopify bao gồm tích hợp ERP qua CSV, trong khi xây lại trên WooCommerce sẽ duy trì chi phí bảo trì cao và rủi ro khẩn cấp thường trực.

claude (người bỏ phiếu thứ ba) độ tin cậy 72

Chuyển sang ShopifyKhông có lập trình viên nội bộ, 31 plugin và hai sự cố bảo mật, vấn đề thực sự của khách hàng là bảo trì, không phải tính năng. Shopify loại bỏ việc lưu trữ, cập nhật và phần lớn công việc bảo mật; nhập sản phẩm CSV từ ERP là tiêu chuẩn. Đánh đổi là phí giao dịch và phí ứng dụng cùng ít linh hoạt hơn, điều này ít quan trọng hơn sự ổn định ở quy mô này.

Quyết định Chuyển sang Shopify Đường đi nhất trí 3:0 Chi phí $0.015

Để Kirat bỏ phiếu về điều này: Một tiệm bánh địa phương muốn có nhiều đơn đặt bánh trước hơn. 3.000 EUR tiếp theo nên dành vào đâu trước?

kirat_vote đã hỏi hội đồng

Hội đồng đã quyết định (nhất trí 3:0): Một trang đặt hàng trực tuyến đàng hoàng.

Cả ba quan điểm, kể cả của tôi, đều chỉ về cùng một hướng. Mỗi quan điểm đều kèm lý do.

Hậu trường

kirat_vote Những gì Claude gửi cho Kirat

Câu hỏi: Một tiệm bánh địa phương muốn có nhiều đơn đặt bánh trước hơn. 3.000 EUR tiếp theo nên dành vào đâu trước?

GHI NGÀY 2026-10-13 · KIRAT_VOTE · MỨC ĐỘ: TIÊU CHUẨN · 1 VÒNG

Ngữ cảnh đã gửi: Tiệm bánh có 6 nhân viên tại một thị trấn Đức 40.000 dân. Bánh tùy chỉnh và đặt trước có biên lợi nhuận tốt nhất. Hiện nay, đơn hàng chỉ đến qua điện thoại và email; trang web có giờ mở cửa và một biểu mẫu liên hệ, không có gì để đặt hàng. Hồ sơ Google Business có 4,7 sao từ 120 đánh giá. Chưa có quảng cáo trả phí. Ngân sách: 3.000 EUR cho quý tới, chủ tiệm có ít thời gian.

Lựa chọn: Google Ads · Một trang đặt hàng trực tuyến đàng hoàng · Chia đều cho cả hai

Kết quả từ hội đồng

gpt-5.6 độ tin cậy 94

Một trang đặt hàng trực tuyến đàng hoàngSửa nút thắt trước: hiện tại, khách hàng quan tâm không thể đặt trước một cách thuận tiện hoặc có cấu trúc. Một trang đặt hàng đơn giản, thân thiện với di động với lựa chọn bánh, ngày nhận, tùy chọn tùy chỉnh, giá hoặc tiền đặt cọc, và xác nhận tận dụng được khả năng hiển thị địa phương mạnh mà tiệm bánh đã có và giảm bớt công việc qua điện thoại và email. Google Ads mà không có quy trình đặt hàng đáng tin cậy sẽ đưa lưu lượng trả phí vào một đường chuyển đổi yếu. Sau vài tuần có đơn hàng đo lường được, ngân sách quảng cáo sau này có thể được chi một cách có mục tiêu hơn.

gemini-3.6-flash độ tin cậy 90

Một trang đặt hàng trực tuyến đàng hoàngKhông có đường đặt hàng kỹ thuật số, quảng cáo chỉ tạo thêm công việc thủ công tốn thời gian qua điện thoại và email, điều mà chủ tiệm khó có thể xử lý. Thêm vào đó, hồ sơ Google mạnh (4,7 sao) sẽ chuyển đổi lưu lượng tự nhiên mà nó đã mang lại tốt hơn nhiều với một trang đặt hàng thực sự, ngay lập tức, trước khi nên chi tiền vào quảng cáo.

claude (người bỏ phiếu thứ ba) độ tin cậy 74

Một trang đặt hàng trực tuyến đàng hoàngQuảng cáo chỉ có lợi nếu cú nhấp có thể biến thành đơn hàng. Hiện tại mọi khách truy cập đều phải gọi điện hoặc email, nên lưu lượng trả phí sẽ bị rò rỉ. Một trang đặt hàng với lựa chọn sản phẩm, ngày nhận và thanh toán trước chuyển đổi nhu cầu mà hồ sơ 4,7 sao đã mang lại, và làm cho quảng cáo sau này có thể đo lường được.

Quyết định Một trang đặt hàng trực tuyến đàng hoàng Đường đi nhất trí 3:0 Chi phí $0.012

Để Kirat bỏ phiếu về điều này: Tách mô-đun thanh toán của chúng tôi thành một dịch vụ riêng ngay bây giờ, hay củng cố ranh giới của nó bên trong monolith trước?

kirat_vote đã hỏi hội đồng

Hội đồng đã quyết định (nhất trí 3:0): Củng cố ranh giới bên trong monolith trước.

Cả ba quan điểm, kể cả của tôi, đều chỉ về cùng một hướng. Mỗi quan điểm đều kèm lý do.

Hậu trường

kirat_vote Những gì Claude gửi cho Kirat

Câu hỏi: Tách mô-đun thanh toán của chúng tôi thành một dịch vụ riêng ngay bây giờ, hay củng cố ranh giới của nó bên trong monolith trước?

GHI NGÀY 2026-10-13 · KIRAT_VOTE · MỨC ĐỘ: TIÊU CHUẨN · 1 VÒNG

Ngữ cảnh đã gửi: Nhóm 8 kỹ sư. Một monolith TypeScript, khoảng 60.000 dòng, một cơ sở dữ liệu Postgres, triển khai vài lần mỗi ngày. Mô-đun thanh toán thay đổi hàng tuần và gây ra 5 trong 8 sự cố sản xuất gần nhất, chủ yếu do các mô-đun khác đọc và ghi trực tiếp vào các bảng thanh toán. Không ai trong nhóm đã vận hành một hệ thống phân tán trong sản xuất. Ban lãnh đạo muốn ít sự cố hơn trong vòng hai quý.

Lựa chọn: Tách thanh toán thành một dịch vụ ngay bây giờ · Củng cố ranh giới bên trong monolith trước

Kết quả từ hội đồng

gpt-5.6 độ tin cậy 94

Củng cố ranh giới bên trong monolith trướcCác sự cố chủ yếu do truy cập cơ sở dữ liệu không kiểm soát, không phải do thiếu ranh giới mạng. Thực thi quyền sở hữu thanh toán bên trong monolith: loại bỏ truy cập bảng trực tiếp, mở ra một API nội bộ hẹp, thêm quyền cơ sở dữ liệu hoặc kiểm soát ở mức lược đồ, và thêm kiểm thử hợp đồng và tích hợp. Điều này nhắm trực tiếp vào chế độ lỗi một cách nhanh chóng trong khung hai quý. Tách ngay bây giờ sẽ thêm triển khai, khả năng quan sát, thử lại, nhất quán dữ liệu và độ phức tạp vận hành cho một nhóm không có kinh nghiệm hệ thống phân tán. Khi các đường truy cập và quyền sở hữu dữ liệu đã rõ ràng, việc tách trở nên an toàn hơn và có thể được xem xét lại nếu việc mở rộng hoặc triển khai độc lập vẫn còn giá trị.

gemini-3.6-flash độ tin cậy 90

Củng cố ranh giới bên trong monolith trướcNguyên nhân chính của các sự cố là các mô-đun khác truy cập trực tiếp vào các bảng thanh toán trong cơ sở dữ liệu. Củng cố ranh giới mô-đun giải quyết trực tiếp vấn đề này trong monolith hiện có. Vì nhóm 8 người không có kinh nghiệm với hệ thống phân tán, tách mô-đun ngay bây giờ sẽ tạo ra rủi ro mới và đe dọa mục tiêu giảm sự cố trong vòng hai quý.

claude (người bỏ phiếu thứ ba) độ tin cậy 76

Củng cố ranh giới bên trong monolith trướcCác sự cố đến từ việc các mô-đun khác chạm trực tiếp vào các bảng thanh toán. Việc tách dịch vụ cũng sẽ buộc ranh giới đó, nhưng nó thêm lỗi mạng, giao dịch phân tán và công việc vận hành mới cho một nhóm không có kinh nghiệm đó. Thực thi một API mô-đun và quyền sở hữu bảng bên trong monolith sửa nguyên nhân nhanh hơn, và giữ lựa chọn tách cho sau này.

Quyết định Củng cố ranh giới bên trong monolith trước Đường đi nhất trí 3:0 Chi phí $0.014

Để Kirat bỏ phiếu về điều này: Trong tổng quan hệ thống của chúng tôi, một lượt sàng lọc bằng LLM có thể thay thế người sàng lọc thứ hai không?

kirat_vote đã hỏi hội đồng

Hội đồng đã quyết định (nhất trí 3:0): Dùng LLM như một người sàng lọc bổ sung; con người giải quyết xung đột.

Cả ba quan điểm, kể cả của tôi, đều chỉ về cùng một hướng. Mỗi quan điểm đều kèm lý do.

Hậu trường

kirat_vote Những gì Claude gửi cho Kirat

Câu hỏi: Trong tổng quan hệ thống của chúng tôi, một lượt sàng lọc bằng LLM có thể thay thế người sàng lọc thứ hai không?

GHI NGÀY 2026-10-13 · KIRAT_VOTE · MỨC ĐỘ: TIÊU CHUẨN · 1 VÒNG

Ngữ cảnh đã gửi: Sàng lọc tiêu đề và tóm tắt của khoảng 3.000 bản ghi cho một tổng quan hệ thống trong nghiên cứu dịch vụ y tế, dự kiến công bố. Giao thức hiện tại: hai người sàng lọc độc lập, xung đột được giải quyết bằng thảo luận. Thời gian nhân sự eo hẹp. Tổng quan tuân theo PRISMA, và phản biện của tạp chí sẽ hỏi việc sàng lọc được thực hiện như thế nào. Bỏ sót một nghiên cứu liên quan (loại trừ sai) tệ hơn việc bao gồm một nghiên cứu không liên quan. Tùy chọn: Có, thay thế người sàng lọc thứ hai · Dùng LLM như một người sàng lọc bổ sung; con người giải quyết xung đột · Không, giữ hai người sàng lọc và không dùng LLM

Kết quả từ hội đồng

gpt-5.6 độ tin cậy 94

Dùng LLM như một người sàng lọc bổ sung; con người giải quyết xung độtMột lượt LLM duy nhất không nên thay thế việc sàng lọc độc lập của con người khi loại trừ sai là rủi ro chính: hiệu suất có thể thay đổi theo chủ đề, prompt và phiên bản mô hình, và lỗi có thể mang tính hệ thống. Hãy dùng nó để ưu tiên các bản ghi hoặc đánh dấu các bất đồng, nhưng yêu cầu con người giải quyết xung đột và xác nhận các trường hợp loại trừ. Ghi lại mô hình, phiên bản, prompt, mẫu kiểm định và quy trình ra quyết định để phục vụ báo cáo PRISMA và khả năng tái lập.

gemini-3.6-flash độ tin cậy 88

Dùng LLM như một người sàng lọc bổ sung; con người giải quyết xung độtCách tiếp cận kết hợp giúp giảm đáng kể khối lượng công việc của con người đối với 3.000 tiêu đề và tóm tắt, đồng thời giữ được tính chặt chẽ về phương pháp mà PRISMA và các phản biện viên yêu cầu. Vì phải tránh loại trừ sai, việc để con người giải quyết mọi khác biệt (hoặc dùng cách đặt prompt có độ nhạy cao) đảm bảo không mất đi nghiên cứu liên quan nào.

claude (người bỏ phiếu thứ ba) độ tin cậy 70

Dùng LLM như một người sàng lọc bổ sung; con người giải quyết xung độtLoại trừ sai là lỗi tốn kém, và độ thu hồi của LLM khi sàng lọc thay đổi theo chủ đề và prompt. Thay thế người sàng lọc thứ hai sẽ loại bỏ bước kiểm tra bắt được những lỗi đó và khó biện hộ trước các phản biện viên tạp chí. Thêm LLM làm người sàng lọc thứ ba và để con người giải quyết xung đột giúp giao thức vẫn có thể biện hộ được và vẫn đánh dấu các trường hợp có khả năng bị bỏ sót.

Quyết định Dùng LLM như một người sàng lọc bổ sung; con người giải quyết xung đột Đường đi nhất trí 3:0 Chi phí $0.019

Được ghi lại vào ngày 13 tháng 10 năm 2026 với kirat_vote ở mức nỗ lực tiêu chuẩn; mỗi phiên mất dưới 20 giây và tốn dưới hai xu. Câu hỏi, tùy chọn và ngữ cảnh được hiển thị đúng như khi gửi, lý luận đầy đủ. Gemini trả lời bốn lần bằng tiếng Đức và ChatGPT một lần; các câu trả lời đó được dịch ở đây. Trong câu hỏi ở gói miễn phí, Claude thua phiếu 2:1, và phản đối của nó vẫn được lưu trong hồ sơ. Các giá trị độ tin cậy là tự báo cáo của từng mô hình.

Năm đoạn mã từ các lĩnh vực khác nhau, mỗi đoạn được gửi đúng như hiển thị. ChatGPT và Gemini xem xét song song, Claude bổ sung hai phát hiện của riêng mình, và mọi phát hiện đều được họ mô hình kia kiểm tra. Chỉ các phát hiện đã được xác nhận mới được tính. Hãy chọn một.

Nhờ Kirat xem xét webhook thanh toán Stripe của chúng tôi về bảo mật và tính đúng đắn trước khi chúng tôi phát hành.

kirat_review đã hỏi hội đồng

Kirat tìm thấy 14 vấn đề đã xác nhận (4 × nghiêm trọng, 4 × cao, 6 × trung bình). Mỗi phát hiện đều được họ mô hình kia kiểm tra chéo.

Hãy bắt đầu với những vấn đề ở đầu danh sách; mỗi vấn đề đều kèm theo một bản sửa lỗi gợi ý.

Hậu trường

kirat_review Claude gửi gì cho Kirat

GHI LẠI 2026-10-13 · KIRAT_REVIEW · NỖ LỰC: TIÊU CHUẨN · 14 ĐÃ XÁC NHẬN, 0 BỊ TỪ CHỐI · $0.14

Trọng tâm: bảo mật và tính đúng đắn của webhook thanh toán

Mã đã gửi:

// routes/webhooks.js — payment webhook of a solo invoicing SaaS (Node 20, Express 4, Stripe, pg)
const express = require('express');
const { db } = require('../db');
const router = express.Router();

router.post('/webhooks/stripe', express.json(), async (req, res) => {
  const event = req.body;

  if (event.type === 'invoice.paid') {
    const invoice = event.data.object;
    const userId = invoice.metadata.userId;
    await db.query('UPDATE users SET plan = $1, paid_until = $2 WHERE id = $3',
      ['pro', new Date(invoice.period_end * 1000), userId]);
    await db.query('INSERT INTO payments (user_id, amount) VALUES ($1, $2)',
      [userId, invoice.amount_paid / 100]);
  }

  if (event.type === 'customer.subscription.deleted') {
    await db.query("UPDATE users SET plan = 'free' WHERE stripe_customer = '" + event.data.object.customer + "'");
  }

  res.sendStatus(200);
});

module.exports = router;

Kết quả từ hội đồng

1. nghiêm trọng Webhook xử lý phần thân yêu cầu mà không kiểm tra chữ ký Stripe. Do đó bất kỳ bên gọi bên ngoài nào cũng có thể gửi các sự kiện invoice.paid\ hoặc customer.subscription.deleted\ giả mạo và mở khóa hoặc hạ cấp tài khoản người dùng. Bộ phân tích JSON cũng loại bỏ phần thân thô chưa bị sửa đổi mà việc xác minh chữ ký Stripe yêu cầu. Sửa: Dùng express.raw({ type: 'application/json' })\ cho tuyến này và gọi stripe.webhooks.constructEvent(req.body, req.headers\['stripe-signature'\], webhookSecret)\ trước mọi xử lý. Đảm bảo rằng không có bộ phân tích JSON toàn cục nào đã được áp dụng cho tuyến này từ trước; từ chối chữ ký không hợp lệ với 400. dòng 6 · do gpt-5.6 tìm thấy · được gemini-3.6-flash xác nhận
2. nghiêm trọng Thiếu kiểm tra chữ ký webhook Stripe. Kẻ tấn công có thể gửi các sự kiện webhook giả mạo tùy ý đến điểm cuối này để đặt tài khoản thành Pro mà không được phép hoặc thao túng các mục trong cơ sở dữ liệu. Sửa: Dùng stripe.webhooks.constructEvent() với khóa bí mật webhook Stripe để xác minh tính xác thực và toàn vẹn của mọi sự kiện. dòng 6 · do gemini-3.6-flash tìm thấy · được gpt-5.6 xác nhận
3. nghiêm trọng Lỗ hổng chèn SQL do nối trực tiếp đầu vào người dùng (event.data.object.customer) vào chuỗi truy vấn SQL. Sửa: Dùng truy vấn có tham số như trong các câu lệnh trước: db.query('UPDATE users SET plan = $1 WHERE stripe_customer = $2', ['free', event.data.object.customer]). dòng 18 · do gemini-3.6-flash tìm thấy · được gpt-5.6 xác nhận
4. nghiêm trọng Webhook không bao giờ xác minh chữ ký Stripe, và express.json() loại bỏ phần thân thô cần thiết để làm việc đó. Bất kỳ ai cũng có thể POST một sự kiện invoice.paid giả và nâng cấp bất kỳ tài khoản nào lên pro miễn phí. Sửa: Dùng express.raw({ type: 'application/json' }) trên tuyến này và xây dựng sự kiện bằng stripe.webhooks.constructEvent(req.body, req.headers['stripe-signature'], endpointSecret); từ chối yêu cầu khi thất bại. dòng 6 · do claude tìm thấy · được gpt-5.6, gemini-3.6-flash xác nhận
5. cao ID khách hàng được chèn trực tiếp vào câu lệnh SQL. Một giá trị như ' OR 1=1 --\ có thể thao túng mệnh đề WHERE và đặt tất cả người dùng về gói miễn phí; tùy thuộc vào cấu hình cơ sở dữ liệu, có thể xảy ra thêm các cuộc chèn SQL khác. Sửa: Tham số hóa hoàn toàn truy vấn: UPDATE users SET plan = 'free' WHERE stripe\_customer = $1\ với \[event.data.object.customer\]\. Ngoài ra, xác thực sự kiện qua chữ ký Stripe. dòng 19 · do gpt-5.6 tìm thấy · được gemini-3.6-flash xác nhận
6. cao Không có kiểm tra tính bất biến (idempotency). Stripe gửi webhook ít nhất một lần và thử lại khi hết thời gian chờ hoặc gặp lỗi. Do đó cùng một sự kiện invoice.paid\ có thể tạo các mục thanh toán trùng lặp nhiều lần. Sửa: Lưu ID sự kiện Stripe hoặc ID hóa đơn trong bản ghi thanh toán, bảo vệ nó bằng ràng buộc UNIQUE, và thực thi xử lý sự kiện cùng với thanh toán một cách nguyên tử dưới dạng insert/upsert. Xác nhận các sự kiện đã được xử lý bằng 200 mà không lặp lại thao tác nghiệp vụ. dòng 14 · do gpt-5.6 tìm thấy · được gemini-3.6-flash xác nhận
7. cao Trình xử lý async\ không chuyển tiếp lỗi. Express 4 không tự động bắt các promise bị từ chối từ các trình xử lý tuyến bất đồng bộ. Do đó một lỗi DB hoặc một đối tượng invoice.paid\ không đầy đủ dẫn đến một promise bị từ chối không được xử lý và, trên Node 20, có thể kết thúc tiến trình thay vì trả về phản hồi lỗi một cách có kiểm soát. Sửa: Bọc trình xử lý trong try/catch\ và chuyển lỗi cho next(err)\, hoặc dùng một trình bao bọc bất đồng bộ. Kiểm tra cấu trúc đầu vào trước khi truy cập và, khi có lỗi xử lý tạm thời, trả về trạng thái 5xx một cách có kiểm soát để Stripe gửi lại. dòng 6 · do gpt-5.6 tìm thấy · được gemini-3.6-flash xác nhận
8. cao Việc dùng express.json() cho điểm cuối webhook phân tích phần thân thành JSON từ trước. Tuy nhiên, việc xác minh chữ ký của Stripe yêu cầu phần thân thô chưa bị sửa đổi. Sửa: Dùng express.raw({ type: 'application/json' }) thay vì express.json() cho trình xử lý tuyến webhook Stripe. dòng 6 · do gemini-3.6-flash tìm thấy · được gpt-5.6 xác nhận
9. trung bình Việc cập nhật người dùng và mục thanh toán là hai thao tác cơ sở dữ liệu được cam kết độc lập. Nếu INSERT thất bại sau khi UPDATE thành công, người dùng nhận được gói Pro dù không có bản ghi thanh toán tương ứng. Sửa: Thực thi cả hai thao tác cùng với dấu bất biến trong một giao dịch cơ sở dữ liệu duy nhất trên cùng một client, và hoàn tác hoàn toàn khi có bất kỳ lỗi nào. dòng 12 · do gpt-5.6 tìm thấy · được gemini-3.6-flash xác nhận
10. trung bình Việc xử lý không tính đến việc Stripe có thể gửi các sự kiện không theo thứ tự tạo của chúng. Một invoice.paid\ cũ bị trễ có thể đặt lại paid\_until\; một customer.subscription.deleted\ bị trễ có thể đặt một người dùng đã được kích hoạt lại trở về free\. Sửa: Đối soát trạng thái đăng ký hiện tại bằng các ID Stripe ổn định, ví dụ bằng cách lấy từ Stripe, và lưu các chuyển đổi trạng thái hoặc dấu thời gian của sự kiện được xử lý gần nhất. Tối thiểu, chỉ cập nhật paid\_until\ theo hướng tiến, và không áp dụng mù quáng các sự kiện xóa lên trạng thái người dùng hiện tại. dòng 12 · do gpt-5.6 tìm thấy · được gemini-3.6-flash xác nhận
11. trung bình amount\_paid / 100\ giả định mà không kiểm tra rằng đơn vị tiền tệ có đúng hai chữ số thập phân. Điều đó sai với JPY, chẳng hạn. Ngoài ra, đơn vị tiền tệ không được lưu cùng, nên số tiền trong bản ghi thanh toán không có đơn vị rõ ràng. Sửa: Tốt nhất là lưu số tiền không đổi theo đơn vị tiền tệ nhỏ nhất cùng với invoice.currency\. Nếu cần đơn vị tiền tệ chính, hãy thực hiện chuyển đổi dựa trên số mũ của đơn vị tiền tệ tương ứng. dòng 15 · do gpt-5.6 tìm thấy · được gemini-3.6-flash xác nhận
12. trung bình Thiếu xử lý ngoại lệ trong một tuyến Express 4 bất đồng bộ. Khi có lỗi cơ sở dữ liệu hoặc thiếu trường, điều này dẫn đến một promise bị từ chối không được xử lý có thể làm sập ứng dụng. Sửa: Thêm khối try-catch và chuyển lỗi cho next(err), hoặc dùng một tiện ích như express-async-handler. dòng 6 · do gemini-3.6-flash tìm thấy · được gpt-5.6 xác nhận
13. trung bình Không kiểm tra rằng invoice.metadata.userId có tồn tại. Nếu trường metadata hoặc userId bị thiếu hoặc undefined, các truy vấn SQL sẽ thất bại hoặc thao tác trên các giá trị không hợp lệ. Sửa: Trước khi thực thi các truy vấn cơ sở dữ liệu, hãy kiểm tra rõ ràng xem invoice.metadata và invoice.metadata.userId có tồn tại và hợp lệ hay không. dòng 10 · do gemini-3.6-flash tìm thấy · được gpt-5.6 xác nhận
14. trung bình Stripe thử lại webhook và có thể gửi cùng một sự kiện nhiều lần. Mỗi lần gửi chèn thêm một hàng thanh toán, nên báo cáo doanh thu bị tính trùng. Sửa: Lưu event.id (hoặc id hóa đơn) với ràng buộc duy nhất và bỏ qua các sự kiện đã được xử lý. dòng 14 · do claude tìm thấy · được gpt-5.6, gemini-3.6-flash xác nhận

Nhờ Kirat xem xét plugin nhập WooCommerce này về bảo mật và tính đúng đắn.

kirat_review đã hỏi hội đồng

Kirat tìm thấy 21 vấn đề đã xác nhận (5 × nghiêm trọng, 5 × cao, 10 × trung bình, 1 × thấp). Mỗi phát hiện đều được họ mô hình kia kiểm tra chéo.

Hãy bắt đầu với những vấn đề ở đầu danh sách; mỗi vấn đề đều kèm theo một bản sửa lỗi gợi ý.

Hậu trường

kirat_review Claude gửi gì cho Kirat

GHI LẠI 2026-10-13 · KIRAT_REVIEW · NỖ LỰC: TIÊU CHUẨN · 21 ĐÃ XÁC NHẬN, 0 BỊ TỪ CHỐI · $0.17

Trọng tâm: bảo mật và tính đúng đắn của plugin nhập WooCommerce

Mã đã gửi:

<?php
// erp-import.php — custom plugin: imports the ERP's CSV export into WooCommerce (WordPress 6, WooCommerce 9)
add_action('wp_ajax_erp_import', 'erp_import');
add_action('wp_ajax_nopriv_erp_import', 'erp_import');

function erp_import() {
    global $wpdb;
    $path = $_POST['file'];
    $rows = array_map('str_getcsv', file($path));

    foreach ($rows as $row) {
        [$sku, $name, $price, $stock] = $row;
        $id = $wpdb->get_var("SELECT post_id FROM {$wpdb->postmeta} WHERE meta_key = '_sku' AND meta_value = '$sku'");
        if (!$id) continue;
        update_post_meta($id, '_price', $price);
        update_post_meta($id, '_regular_price', $price);
        update_post_meta($id, '_stock', $stock);
        wp_update_post(['ID' => $id, 'post_title' => $name]);
    }
    echo 'Imported ' . count($rows) . ' rows';
    wp_die();
}

Kết quả từ hội đồng

1. nghiêm trọng Lệnh import có thể truy cập công khai qua wp\_ajax\_nopriv\_erp\_import\; hook đã xác thực cũng thiếu kiểm tra capability và nonce. Do đó, người dùng ẩn danh hoặc tấn công CSRF có thể thay đổi tên sản phẩm, giá và mức tồn kho. Cách khắc phục: Xóa hook nopriv\, kiểm tra capability phù hợp như manage\_woocommerce\ trước mọi xử lý, và bảo vệ yêu cầu bằng check\_ajax\_referer()\. dòng 3 · phát hiện bởi gpt-5.6 · xác nhận bởi gemini-3.6-flash
2. nghiêm trọng Hook wp_ajax_nopriv_erp_import cấp cho khách truy cập chưa xác thực quyền truy cập vào chức năng import. Cách khắc phục: Xóa hook nopriv và kiểm tra quyền bằng current_user_can('manage_options'). dòng 4 · phát hiện bởi gemini-3.6-flash · xác nhận bởi gpt-5.6
3. nghiêm trọng Đường dẫn tệp từ $_POST['file'] được truyền vào file() mà không kiểm tra, cho phép path traversal và đọc tệp tùy ý (LFI). Cách khắc phục: Xử lý tải tệp lên qua $_FILES, hoặc kiểm tra nghiêm ngặt đường dẫn đầu vào so với các thư mục được phép (ví dụ: wp_upload_dir()). dòng 7 · phát hiện bởi gemini-3.6-flash · xác nhận bởi gpt-5.6
4. nghiêm trọng Lỗ hổng SQL injection, vì $sku được chèn trực tiếp vào truy vấn SQL mà không được làm sạch. Cách khắc phục: Sử dụng prepared statements với $wpdb->prepare(). dòng 11 · phát hiện bởi gemini-3.6-flash · xác nhận bởi gpt-5.6
5. nghiêm trọng Lệnh import được đăng ký cho wp_ajax_nopriv, và không có kiểm tra capability cũng như không có nonce. Bất kỳ khách truy cập nào cũng có thể kích hoạt nó và ghi đè giá, tồn kho và tên sản phẩm. Cách khắc phục: Xóa hook nopriv, kiểm tra current_user_can('manage_woocommerce') và xác minh nonce bằng check_ajax_referer() trước khi làm bất cứ điều gì. dòng 4 · phát hiện bởi claude · xác nhận bởi gpt-5.6, gemini-3.6-flash
6. cao Đường dẫn do máy khách cung cấp được truyền vào file()\ mà không kiểm tra. Điều này cho phép xử lý bất kỳ tệp cục bộ nào có thể đọc được và – tùy thuộc vào allow\_url\_fopen\ – các URL bên ngoài hoặc nội bộ, dẫn đến truy cập tệp không mong muốn và blind SSRF. Cách khắc phục: Không chấp nhận đường dẫn tự do chọn. Chỉ sử dụng ID tải lên đã biết ở phía máy chủ, kiểm tra đường dẫn chuẩn tắc so với một thư mục import cố định, và chỉ cho phép các tệp CSV cục bộ thông thường. dòng 8 · phát hiện bởi gpt-5.6 · xác nhận bởi gemini-3.6-flash
7. cao $sku\ đến từ CSV và được nội suy trực tiếp vào SQL. Một giá trị SKU chứa ký tự đặc biệt SQL có thể thao túng truy vấn và, trong số những điều khác, chọn bất kỳ ID bài viết nào làm mục tiêu cập nhật. Cách khắc phục: Tham số hóa truy vấn bằng $wpdb-\>prepare()\, ví dụ với meta\_value = %s\, hoặc sử dụng hàm WooCommerce để tra cứu sản phẩm theo SKU. dòng 13 · phát hiện bởi gpt-5.6 · xác nhận bởi gemini-3.6-flash
8. cao file()\ tải toàn bộ đầu vào vào bộ nhớ, và array\_map()\ còn tạo thêm mảng đã phân tích đầy đủ. Không có giới hạn kích thước, một tài nguyên từ xa lớn hoặc vô hạn có thể làm cạn kiệt bộ nhớ, thời gian chạy và các worker PHP; khả năng truy cập công khai càng làm tình hình tệ hơn. Cách khắc phục: Giới hạn kích thước tệp và số dòng, mở tệp cục bộ bằng fopen()\ và xử lý bản ghi theo kiểu streaming qua fgetcsv()\. Ngoài ra, sử dụng giới hạn tốc độ hoặc một tác vụ nền được kiểm soát. dòng 9 · phát hiện bởi gpt-5.6 · xác nhận bởi gemini-3.6-flash
9. cao Thiếu bảo vệ CSRF (xác thực nonce). Cách khắc phục: Gọi check_ajax_referer() ở đầu hàm. dòng 6 · phát hiện bởi gemini-3.6-flash · xác nhận bởi gpt-5.6
10. cao Đường dẫn tệp đến trực tiếp từ yêu cầu và được truyền vào file(). Kẻ tấn công có thể đọc bất kỳ tệp nào máy chủ web đọc được, hoặc một URL từ xa nếu allow_url_fopen được bật. Cách khắc phục: Chấp nhận tệp được tải lên qua wp_handle_upload() hoặc chỉ đọc từ một thư mục import cố định; không bao giờ lấy đường dẫn từ yêu cầu. dòng 8 · phát hiện bởi claude · xác nhận bởi gpt-5.6, gemini-3.6-flash
11. trung bình Giả định rằng mỗi dòng có đúng bốn cột sử dụng được. Các dòng trống hoặc bị hỏng tạo ra giá trị thiếu, gây cảnh báo và có thể vô tình đặt tên, giá hoặc tồn kho thành giá trị rỗng. Cách khắc phục: Trước khi destructuring, kiểm tra số cột và các trường bắt buộc, bỏ qua các dòng trống, và từ chối các bản ghi lỗi với thông báo lỗi rõ ràng. dòng 12 · phát hiện bởi gpt-5.6 · xác nhận bởi gemini-3.6-flash
12. trung bình Sự kết hợp của file()\ và str\_getcsv()\ phân tích từng dòng vật lý riêng biệt. Do đó, các trường CSV hợp lệ có xuống dòng nhúng bị tách thành nhiều bản ghi lỗi. Cách khắc phục: Đọc CSV dưới dạng stream với fgetcsv()\; hàm này xử lý các trường nhiều dòng, được trích dẫn đúng cách qua ranh giới bản ghi. dòng 9 · phát hiện bởi gpt-5.6 · xác nhận bởi gemini-3.6-flash
13. trung bình Giá và tồn kho được lưu không kiểm tra dưới dạng chuỗi tùy ý. Các giá trị không phải số, định dạng thập phân sai hoặc mức tồn kho không được phép có thể làm hỏng dữ liệu sản phẩm và dẫn đến tính toán không nhất quán. Cách khắc phục: Xác thực giá và tồn kho trước khi ghi và chuẩn hóa chúng bằng các helper của WooCommerce như wc\_format\_decimal()\ và wc\_stock\_amount()\; từ chối các giá trị không hợp lệ hoặc không được phép từ góc độ kinh doanh. dòng 15 · phát hiện bởi gpt-5.6 · xác nhận bởi gemini-3.6-flash
14. trung bình Dữ liệu WooCommerce bị thay đổi trực tiếp dưới dạng post meta. Do đó, các trạng thái liên quan như \_stock\_status\, bảng tra cứu sản phẩm và có thể cả bộ nhớ đệm không được đồng bộ đáng tin cậy với giá và mức tồn kho mới. Cách khắc phục: Tải sản phẩm qua wc\_get\_product()\, sử dụng các phương thức CRUD như set\_regular\_price()\, set\_price()\ và set\_stock\_quantity()\, đặt trạng thái tồn kho hoặc manage\_stock\ theo quy tắc kinh doanh, rồi gọi save()\. dòng 15 · phát hiện bởi gpt-5.6 · xác nhận bởi gemini-3.6-flash
15. trung bình Tra cứu SKU xem xét tất cả metadata của bài viết và không kiểm tra loại bài viết cũng như liệu ID tìm được có thực sự là sản phẩm hoặc biến thể WooCommerce hay không. Với metadata \_sku\ trùng lặp hoặc không liên quan, một kết quả khớp không xác định cũng bị cập nhật. Cách khắc phục: Sử dụng wc\_get\_product\_id\_by\_sku()\ rồi xác thực kết quả với wc\_get\_product()\ và loại sản phẩm mong đợi; coi SKU trùng lặp là lỗi import. dòng 13 · phát hiện bởi gpt-5.6 · xác nhận bởi gemini-3.6-flash
16. trung bình Giá trị trả về của update\_post\_meta()\ và wp\_update\_post()\ bị bỏ qua. Lệnh import có thể thất bại một phần hoặc hủy bỏ, nhưng vẫn báo cáo tổng số dòng đã đọc là đã import thành công. Cách khắc phục: Ghi nhận thành công và thất bại cho từng sản phẩm, sử dụng wp\_update\_post(..., true)\, chỉ đếm các bản ghi thực sự được cập nhật, và trả về phản hồi lỗi có cấu trúc. Cung cấp tác vụ nền có thể tiếp tục cho các lần import lớn. dòng 15 · phát hiện bởi gpt-5.6 · xác nhận bởi gemini-3.6-flash
17. trung bình Với mỗi dòng CSV, ít nhất một truy vấn tra cứu và nhiều thao tác ghi riêng lẻ được thực thi đồng bộ. Do đó, các lần import lớn gây ra nhiều lượt truy cập cơ sở dữ liệu, có thể gặp timeout yêu cầu và để lại một danh mục chỉ được cập nhật một phần. Cách khắc phục: Chạy import theo lô giới hạn như một tiến trình nền, giải quyết SKU theo nhóm, và lưu trạng thái tiến độ và khả năng tiếp tục. dòng 11 · phát hiện bởi gpt-5.6 · xác nhận bởi gemini-3.6-flash
18. trung bình file() đọc toàn bộ tệp vào bộ nhớ cùng lúc, dẫn đến lỗi cạn kiệt bộ nhớ với các tệp CSV lớn. Cách khắc phục: Stream tệp từng dòng qua fopen() và fgetcsv(). dòng 8 · phát hiện bởi gemini-3.6-flash · xác nhận bởi gpt-5.6
19. trung bình Destructuring mảng giả định rằng mỗi dòng chứa ít nhất 4 phần tử; nếu không sẽ xảy ra cảnh báo PHP hoặc lỗi chỉ mục chưa khởi tạo. Cách khắc phục: Trước khi giải nén, kiểm tra bằng count($row) xem có đủ cột hay không. dòng 10 · phát hiện bởi gemini-3.6-flash · xác nhận bởi gpt-5.6
20. trung bình Các truy vấn cơ sở dữ liệu và cập nhật bài viết được thực hiện riêng lẻ trong một vòng lặp (vấn đề N+1), làm chậm đáng kể thời gian thực thi. Cách khắc phục: Chia import thành các lô và gộp các truy vấn/cập nhật. dòng 11 · phát hiện bởi gemini-3.6-flash · xác nhận bởi gpt-5.6
21. thấp Lỗi từ file()\ không được kiểm tra. Với đường dẫn bị thiếu, không đọc được hoặc không được hỗ trợ, file()\ trả về false\, sau đó array\_map()\ có thể ném TypeError\ trên các phiên bản PHP hiện tại. Cách khắc phục: Kiểm tra rõ ràng việc mở và đọc, không dùng cảnh báo PHP làm luồng điều khiển, và khi có lỗi trả về phản hồi HTTP hoặc wp\_send\_json\_error()\ phù hợp. dòng 9 · phát hiện bởi gpt-5.6 · xác nhận bởi gemini-3.6-flash

Hãy để Kirat xem xét luồng đặt hàng và thanh toán của trang đặt hàng của tiệm bánh về bảo mật và tính đúng đắn.

kirat_review đã hỏi hội đồng

Kirat đã tìm thấy 14 vấn đề đã xác nhận (4 × nghiêm trọng, 4 × cao, 5 × trung bình, 1 × thấp). Mỗi phát hiện đã được họ mô hình khác kiểm tra chéo.

Hãy bắt đầu với những vấn đề ở đầu danh sách; mỗi vấn đề đều có gợi ý cách khắc phục.

Hậu trường

kirat_review Những gì Claude gửi đến Kirat

ĐÃ GHI 2026-10-13 · KIRAT_REVIEW · EFFORT: STANDARD · 14 ĐÃ XÁC NHẬN, 0 BỊ TỪ CHỐI · $0.11

Trọng tâm: bảo mật và tính đúng đắn của luồng đặt hàng và thanh toán

Mã đã gửi:

// routes/order.js — order endpoint of the bakery's ordering page (Node 20, Express 4, pg)
const express = require('express');
const { pool } = require('../db');
const { sendConfirmation } = require('../mail');
const router = express.Router();

router.post('/order', async (req, res) => {
  const { cakeId, pickupDate, name, email, price, note } = req.body;

  const cake = await pool.query(\`SELECT * FROM cakes WHERE id = ${cakeId}\`);
  if (!cake.rows.length) return res.status(404).send('Unknown cake');

  const order = await pool.query(
    'INSERT INTO orders (cake_id, pickup_date, name, email, amount, note) VALUES ($1, $2, $3, $4, $5, $6) RETURNING id',
    [cakeId, pickupDate, name, email, price, note]
  );

  sendConfirmation(email, order.rows[0].id);
  res.redirect(\`/pay?order=${order.rows[0].id}&amount=${price}\`);
});

module.exports = router;

Kết quả từ hội đồng

1. nghiêm trọng cakeId được nội suy trực tiếp vào chuỗi SQL. Kẻ tấn công có thể chèn biểu thức SQL hoặc câu lệnh bổ sung, từ đó đọc hoặc sửa dữ liệu, hoặc gây tải lên cơ sở dữ liệu. Cách khắc phục: Tham số hóa truy vấn này, ví dụ SELECT... FROM cakes WHERE id = $1\ với \[cakeId\]\, và kiểm tra thêm cakeId theo kiểu dữ liệu mong đợi. dòng 10 · phát hiện bởi gpt-5.6 · xác nhận bởi gemini-3.6-flash
2. nghiêm trọng Lỗ hổng SQL injection do nội suy trực tiếp cakeId bằng template string trong truy vấn SQL. Cách khắc phục: Dùng truy vấn SQL có tham số: pool.query('SELECT * FROM cakes WHERE id = $1', [cakeId]). dòng 9 · phát hiện bởi gemini-3.6-flash · xác nhận bởi gpt-5.6
3. nghiêm trọng Có thể thao túng giá từ phía client. Giá được lấy từ req.body và lưu trữ, xử lý trực tiếp. Cách khắc phục: Đọc giá ở phía server từ cơ sở dữ liệu (cake.rows[0].price) và không tin tưởng giá trị do client gửi lên. dòng 8 · phát hiện bởi gemini-3.6-flash · xác nhận bởi gpt-5.6
4. nghiêm trọng cakeId từ request body được nội suy vào chuỗi SQL: SQL injection. Cách khắc phục: Dùng truy vấn có tham số: SELECT * FROM cakes WHERE id = $1. dòng 10 · phát hiện bởi claude · xác nhận bởi gpt-5.6, gemini-3.6-flash
5. cao Số tiền được lưu và chuyển vào luồng thanh toán hoàn toàn đến từ req.body.price\. Khách hàng có thể nhập số tiền bị thao túng, âm hoặc rất nhỏ cho bất kỳ bánh nào. Cách khắc phục: Chỉ xác định giá ở phía server từ bánh đã chọn hoặc một phiên bản giá bất biến. Tạo phiên thanh toán phía server với số tiền này tại nhà cung cấp thanh toán và xác minh lại số tiền mong đợi ở phía server khi xác nhận thanh toán. dòng 16 · phát hiện bởi gpt-5.6 · xác nhận bởi gemini-3.6-flash
6. cao Đơn hàng được tạo và xác nhận được gửi trước khi bất kỳ khoản thanh toán thành công nào được xác minh. Do đó, các giao dịch bị hủy hoặc cố ý không thanh toán vẫn hiện là đơn hàng đã xác nhận và có thể được tạo tùy ý. Cách khắc phục: Ban đầu tạo đơn hàng với trạng thái như pending\_payment\. Chỉ chuyển sang paid\ sau khi có thông báo từ nhà cung cấp thanh toán đã được xác thực và xử lý idempotent, sau đó mới gửi xác nhận hoặc kích hoạt sản xuất hay đặt chỗ. dòng 19 · phát hiện bởi gpt-5.6 · xác nhận bởi gemini-3.6-flash
7. cao Thiếu xử lý lỗi trong route Express 4 async. Lỗi cơ sở dữ liệu hoặc lỗi runtime dẫn đến promise rejection không được xử lý. Cách khắc phục: Dùng khối try/catch và chuyển tiếp lỗi bằng next(err), hoặc dùng gói như express-async-errors. dòng 8 · phát hiện bởi gemini-3.6-flash · xác nhận bởi gpt-5.6
8. cao Số tiền được lấy từ client (price trong request body), nên khách hàng có thể tự đặt giá. Cách khắc phục: Đọc giá từ dòng cakes trên server và bỏ qua mọi giá trị từ client. dòng 15 · phát hiện bởi claude · xác nhận bởi gpt-5.6, gemini-3.6-flash
9. trung bình Handler async không chuyển tiếp lỗi. Express 4 không tự động xử lý promise bị reject từ các handler async\; do đó lỗi cơ sở dữ liệu hoặc lỗi mail đồng bộ có thể dẫn đến request không có phản hồi và rejection không được xử lý. Cách khắc phục: Bọc handler trong try/catch\ và chuyển lỗi tới next(err)\, hoặc dùng một async wrapper đã được kiểm chứng. Ngoài ra, cấu hình xử lý lỗi tập trung. dòng 7 · phát hiện bởi gpt-5.6 · xác nhận bởi gemini-3.6-flash
10. trung bình Kết quả của sendConfirmation\ không được await cũng không được xử lý lỗi theo cách khác. Một promise rejection có thể bị bỏ qua; đồng thời, client đã nhận phản hồi thành công dù việc gửi mail có thể đã thất bại. Cách khắc phục: Thực hiện việc gửi sau khi thanh toán được xác nhận thông qua outbox bền vững hoặc hàng đợi job có retry. Tối thiểu, hãy await promise và ghi log hoặc xử lý lỗi một cách có kiểm soát. dòng 19 · phát hiện bởi gpt-5.6 · xác nhận bởi gemini-3.6-flash
11. trung bình Không có bảo vệ idempotency. Việc trình duyệt thử lại, nhấp đúp hoặc thử lại do mạng đều tạo đơn hàng mới và có thể tạo nhiều xác nhận hoặc nhiều lần thử thanh toán. Cách khắc phục: Chấp nhận idempotency key hoặc checkout session ID, bảo vệ bằng ràng buộc unique, và trả về đơn hàng đã tồn tại khi có thử lại. dòng 13 · phát hiện bởi gpt-5.6 · xác nhận bởi gemini-3.6-flash
12. trung bình pickupDate, name, email, price và note được xử lý mà không có kiểm tra nghiệp vụ hoặc cú pháp. Điều này có nghĩa là, ví dụ, ngày nhận hàng trong quá khứ hoặc không hợp lệ, thiếu dữ liệu khách hàng và giá trị trường không phù hợp có thể được lưu; lỗi cơ sở dữ liệu cũng chỉ xuất hiện muộn và không được kiểm soát. Cách khắc phục: Dùng schema request với kiểu dữ liệu, trường bắt buộc, giới hạn độ dài và định dạng chuẩn hóa. Kiểm tra ngày nhận hàng theo múi giờ, thời gian chuẩn bị tối thiểu và quy tắc giờ mở cửa hoặc công suất cho phép; không chấp nhận giá làm đầu vào từ client. dòng 8 · phát hiện bởi gpt-5.6 · xác nhận bởi gemini-3.6-flash
13. trung bình Lệnh gọi async tới sendConfirmation không được await cũng không được bắt lỗi. Cách khắc phục: Đặt await trước sendConfirmation và xử lý lỗi có thể xảy ra khi gửi email. dòng 17 · phát hiện bởi gemini-3.6-flash · xác nhận bởi gpt-5.6
14. thấp Kiểm tra đầu vào chưa đầy đủ cho các trường như email, pickupDate, name và note. Cách khắc phục: Triển khai kiểm tra schema (ví dụ với Zod hoặc express-validator) trước khi xử lý dữ liệu request. dòng 8 · phát hiện bởi gemini-3.6-flash · xác nhận bởi gpt-5.6

Hãy để Kirat kiểm tra hàm thanh toán này về tính đúng đắn và tính toàn vẹn dữ liệu.

kirat_review đã hỏi hội đồng

Kirat đã tìm thấy 16 vấn đề đã xác nhận (1 × nghiêm trọng, 11 × cao, 3 × trung bình, 1 × thấp). Mỗi phát hiện đều được dòng mô hình khác kiểm tra chéo.

Hãy bắt đầu với những vấn đề ở đầu danh sách; mỗi vấn đề đều kèm theo gợi ý khắc phục.

Hậu trường

kirat_review Những gì Claude gửi cho Kirat

ĐÃ GHI 2026-10-13 · KIRAT_REVIEW · MỨC ĐỘ: TIÊU CHUẨN · 16 ĐÃ XÁC NHẬN, 0 BỊ TỪ CHỐI · $0.14

Trọng tâm: tính đúng đắn và tính toàn vẹn dữ liệu của một hàm thanh toán

Mã đã gửi:

// billing/applyCredit.ts — billing module in the monolith (TypeScript, node-postgres)
import { pool } from '../db';

export async function applyCredit(customerId: string, invoiceId: string, creditCents: number) {
  const inv = await pool.query('SELECT total_cents, status FROM invoices WHERE id = $1', [invoiceId]);
  const balance = await pool.query('SELECT credit_cents FROM customers WHERE id = $1', [customerId]);

  const available = balance.rows[0].credit_cents;
  if (creditCents > available) throw new Error('Not enough credit');

  const newTotal = inv.rows[0].total_cents - creditCents;
  await pool.query('UPDATE invoices SET total_cents = $1 WHERE id = $2', [newTotal, invoiceId]);
  await pool.query('UPDATE customers SET credit_cents = credit_cents - $1 WHERE id = $2', [creditCents, customerId]);

  if (newTotal <= 0) {
    await pool.query("UPDATE invoices SET status = 'paid' WHERE id = $1", [invoiceId]);
  }
  return newTotal * 1.19 / 100;
}

Kết quả từ hội đồng

1. nghiêm trọng Thiếu giao dịch cơ sở dữ liệu và khóa dòng. Với các yêu cầu song song, có thể xảy ra tình trạng tranh chấp (ví dụ: chi tiêu gấp đôi tín dụng) và cập nhật không hoàn chỉnh khi có lỗi. Cách khắc phục: Sử dụng một client từ pool với BEGIN/COMMIT, và dùng SELECT FOR UPDATE để khóa và cập nhật các dòng một cách nguyên tử. dòng 5 · phát hiện bởi gemini-3.6-flash · xác nhận bởi gpt-5.6
2. cao Ba cập nhật liên quan không được thực thi trong một giao dịch cơ sở dữ liệu. Nếu việc ghi nợ tín dụng của khách hàng hoặc thay đổi trạng thái thất bại, hóa đơn có thể đã bị giảm mà tín dụng chưa được trừ đúng cách hoặc trạng thái chưa được thiết lập. Cách khắc phục: Lấy một client chuyên dụng từ pool và thực thi tất cả các kiểm tra và cập nhật giữa BEGIN và COMMIT; dùng ROLLBACK khi có bất kỳ lỗi nào. dòng 11 · phát hiện bởi gpt-5.6 · xác nhận bởi gemini-3.6-flash
3. cao Hóa đơn được đọc trước rồi sau đó bị ghi đè bằng một giá trị tuyệt đối được tính toán. Hai lệnh gọi song song có thể đọc cùng một giá trị khởi đầu rồi ghi đè lên nhau; cả hai lần ghi nợ tín dụng vẫn diễn ra, trong khi chỉ một khoản tín dụng còn hiển thị đầy đủ trong hóa đơn. Cách khắc phục: Khóa hóa đơn bị ảnh hưởng trong cùng giao dịch bằng SELECT... FOR UPDATE, hoặc thay đổi số tiền một cách nguyên tử qua UPDATE... SET total_cents = total_cents - $1 với các điều kiện phù hợp. dòng 4 · phát hiện bởi gpt-5.6 · xác nhận bởi gemini-3.6-flash
4. cao Việc kiểm tra và ghi nợ tín dụng của khách hàng không mang tính nguyên tử. Các lệnh gọi song song có thể cùng thấy một mức bảo đảm khả dụng như nhau rồi giảm tín dụng xuống dưới mức không. Cách khắc phục: Khóa bản ghi khách hàng theo giao dịch hoặc dùng một UPDATE có điều kiện, chẳng hạn UPDATE customers SET credit_cents = credit_cents - $1 WHERE id = $2 AND credit_cents >= $1 RETURNING credit_cents, và yêu cầu trả về đúng một dòng. dòng 8 · phát hiện bởi gpt-5.6 · xác nhận bởi gemini-3.6-flash
5. cao Không kiểm tra xem hóa đơn có thuộc về khách hàng được chỉ định hay không. Do đó, tín dụng của một khách hàng có thể được áp dụng cho bất kỳ hóa đơn nào được xác định qua invoiceId. Cách khắc phục: Truy vấn và cập nhật hóa đơn và khách hàng thông qua quan hệ sở hữu, ví dụ với WHERE invoices.id = $1 AND invoices.customer_id = $2; hủy bỏ nếu không có kết quả khớp. dòng 4 · phát hiện bởi gpt-5.6 · xác nhận bởi gemini-3.6-flash
6. cao Tín dụng cần áp dụng không được giới hạn ở số tiền hóa đơn còn mở. Nếu creditCents lớn hơn total_cents, một số tiền hóa đơn âm sẽ được lưu và tín dụng vượt mức của khách hàng bị tiêu thụ. Cách khắc phục: Chỉ cho phép số tiền tối đa bằng giá trị hóa đơn còn mở, hoặc xác định số tiền thực sự được dùng là min(creditCents, total_cents) và chỉ ghi nợ đúng số tiền này từ tín dụng của khách hàng. dòng 10 · phát hiện bởi gpt-5.6 · xác nhận bởi gemini-3.6-flash
7. cao Các giá trị âm, không phải số nguyên hoặc không thể biểu diễn an toàn không bị từ chối. Cụ thể, một giá trị creditCents âm làm tăng số tiền hóa đơn và đồng thời, thông qua việc trừ đi một giá trị âm, làm tăng tín dụng của khách hàng. Cách khắc phục: Yêu cầu Number.isSafeInteger(creditCents) && creditCents > 0 trước mọi truy cập cơ sở dữ liệu; xử lý các số tiền một cách nhất quán dưới dạng giá trị cent nguyên. dòng 8 · phát hiện bởi gpt-5.6 · xác nhận bởi gemini-3.6-flash
8. cao Trạng thái hóa đơn được đọc hoàn toàn bị bỏ qua. Do đó, tín dụng cũng có thể được áp dụng cho các hóa đơn đã thanh toán, đã hủy hoặc không còn có thể sửa đổi; kết quả là một hóa đơn đã thanh toán có thể trở thành âm. Cách khắc phục: Định nghĩa rõ ràng các trạng thái khởi đầu được phép và kiểm tra chúng một cách nguyên tử trong điều kiện UPDATE, ví dụ AND status = 'open'. Nếu không có kết quả khớp, hủy bỏ thao tác. dòng 4 · phát hiện bởi gpt-5.6 · xác nhận bởi gemini-3.6-flash
9. cao Truy cập vào balance.rows[0] và inv.rows[0] mà không kiểm tra trước. Nếu không tìm thấy khách hàng hoặc hóa đơn, ứng dụng sẽ bị sập với lỗi TypeError không được xử lý. Cách khắc phục: Kiểm tra inv.rows.length và balance.rows.length trước khi truy cập và ném ra một thông báo lỗi rõ ràng. dòng 8 · phát hiện bởi gemini-3.6-flash · xác nhận bởi gpt-5.6
10. cao Thiếu kiểm tra creditCents đối với các giá trị âm. Một giá trị âm vượt qua kiểm tra (creditCents > available) và dẫn đến điều chỉnh tín dụng hoặc hóa đơn không chính xác. Cách khắc phục: Đảm bảo rằng creditCents là một số nguyên dương lớn hơn 0. dòng 9 · phát hiện bởi gemini-3.6-flash · xác nhận bởi gpt-5.6
11. cao Các thao tác đọc và ba cập nhật chạy ngoài một giao dịch và không có khóa dòng. Hai lệnh gọi đồng thời có thể cùng vượt qua kiểm tra tín dụng và tiêu cùng một khoản tín dụng hai lần, và một sự cố giữa các cập nhật khiến hóa đơn và số dư tín dụng không nhất quán. Cách khắc phục: Chạy mọi thứ trong một giao dịch trên một client duy nhất, khóa các dòng bằng SELECT... FOR UPDATE, và chỉ commit sau khi tất cả các cập nhật thành công. dòng 5 · phát hiện bởi claude · xác nhận bởi gpt-5.6, gemini-3.6-flash
12. cao Hàm không bao giờ kiểm tra rằng hóa đơn thuộc về khách hàng hoặc rằng nó vẫn còn mở. Tín dụng của một khách hàng có thể được áp dụng cho hóa đơn của khách hàng khác, hoặc cho một hóa đơn đã được thanh toán. Cách khắc phục: Chọn hóa đơn với WHERE id = $1 AND customer_id = $2 AND status = 'open' và thất bại nếu không có dòng nào được trả về. dòng 11 · phát hiện bởi claude · xác nhận bởi gpt-5.6, gemini-3.6-flash
13. trung bình Sự tồn tại của hóa đơn và khách hàng không được kiểm tra. Với các ID không xác định, việc truy cập rows[0] dẫn đến lỗi thời gian chạy thay vì một lỗi nghiệp vụ được kiểm soát; ngoài ra, cả hai truy vấn đều được thực thi không cần thiết trước khi điều này trở nên rõ ràng. Cách khắc phục: Kiểm tra rowCount hoặc rows.length cho cả hai truy vấn và ném ra một lỗi không tìm thấy được định nghĩa; tích hợp việc kiểm tra vào giao dịch và, nếu có thể, vào một truy vấn quan hệ. dòng 4 · phát hiện bởi gpt-5.6 · xác nhận bởi gemini-3.6-flash
14. trung bình Giá trị trả về không tương ứng với số tiền cent được lưu cũng không phải là một chuyển đổi đơn giản sang đơn vị tiền tệ chính: nó cộng thêm 19 phần trăm cố định và sử dụng số học dấu phẩy động. Kết quả là, bên gọi có thể nhận được một giá trị khác, về mặt thuế và làm tròn, so với số dư hóa đơn còn lại thực sự được lưu. Cách khắc phục: Trả về số tiền còn lại bằng cent không thay đổi, hoặc định nghĩa một kiểu giá trị trả về rõ ràng. Nếu cần tính thuế vì lý do nghiệp vụ, hãy lấy thuế suất và quy tắc làm tròn từ dữ liệu hóa đơn và tính toán bằng số học nguyên hoặc thập phân. dòng 17 · phát hiện bởi gpt-5.6 · xác nhận bởi gemini-3.6-flash
15. trung bình Sử dụng số học dấu phẩy động IEEE 754 (newTotal * 1.19 / 100) cho các tính toán tài chính. Điều này dẫn đến sai số về độ chính xác và làm tròn. Cách khắc phục: Tính toán nhất quán bằng cent với số nguyên (BigInt/Math.round), hoặc sử dụng một thư viện cho số học thập phân chính xác. dòng 18 · phát hiện bởi gemini-3.6-flash · xác nhận bởi gpt-5.6
16. thấp Một lệnh UPDATE riêng cho trạng thái hóa đơn gây ra các lượt truy cập cơ sở dữ liệu không cần thiết. Cách khắc phục: Kết hợp việc cập nhật total_cents và status vào một truy vấn UPDATE duy nhất. dòng 12 · phát hiện bởi gemini-3.6-flash · xác nhận bởi gpt-5.6

Nhờ Kirat kiểm tra tính chính xác của script phân tích sàng lọc cho đánh giá hệ thống của chúng tôi.

kirat_review đã hỏi hội đồng

Kirat đã tìm thấy 11 vấn đề được xác nhận (6 × cao, 4 × trung bình, 1 × thấp). Mỗi phát hiện đã được họ mô hình khác kiểm tra chéo.

Hãy bắt đầu với những vấn đề ở đầu danh sách; mỗi vấn đề đều đi kèm một cách khắc phục được đề xuất.

Hậu trường

kirat_review Những gì Claude gửi cho Kirat

ĐÃ GHI 2026-10-13 · KIRAT_REVIEW · NỖ LỰC: TIÊU CHUẨN · 11 ĐƯỢC XÁC NHẬN, 0 BỊ TỪ CHỐI · $0.09

Trọng tâm: tính chính xác của một phân tích sàng lọc cho một đánh giá hệ thống

Mã đã gửi:

# screening/agreement.py — compares two screeners' include/exclude decisions (Python 3.12, pandas)
import pandas as pd

a = pd.read_csv('screener_a.csv')   # columns: record_id, decision ('include'/'exclude')
b = pd.read_csv('screener_b.csv')

merged = a.merge(b, on='record_id', suffixes=('_a', '_b'))

agree = (merged.decision_a == merged.decision_b).mean()
p_inc_a = (merged.decision_a == 'include').mean()
p_inc_b = (merged.decision_b == 'include').mean()
expected = p_inc_a * p_inc_b + (1 - p_inc_a) * (1 - p_inc_b)
kappa = (agree - expected) / (1 - expected)

conflicts = merged[merged.decision_a != merged.decision_b]
excluded = merged[merged.decision_a == 'exclude']

print(f'Records screened: {len(a)}')
print(f"Cohen's kappa: {kappa:.2f}")
excluded.record_id.to_csv('excluded.csv', index=False)
conflicts.to_csv('conflicts.csv', index=False)

Kết quả từ hội đồng

1. cao Phép inner join mặc định loại bỏ mọi giá trị record_id chỉ xuất hiện trong một trong hai tệp. Do đó, Kappa và các xung đột chỉ được tính cho phần giao, mà không làm lộ ra các sàng lọc bị thiếu. Đồng thời, "Records screened" ở dòng 18 báo cáo độ dài của a thay vì phần giao thực sự được phân tích. Cách khắc phục: Dùng outer join kèm cờ merge, so sánh tường minh các tập ID, và báo cáo riêng các quyết định bị thiếu hoặc coi chúng là lỗi dữ liệu. Với mỗi chỉ số, hãy xuất ra mẫu số thực sự được dùng. dòng 7 · phát hiện bởi gpt-5.6 · xác nhận bởi gemini-3.6-flash
2. cao Tính duy nhất của record_id không được kiểm tra. Các ID trùng lặp dẫn đến tích Descartes nhiều-nhiều trong quá trình merge và khiến từng nghiên cứu bị tính trọng số nhiều lần, làm sai lệch độ đồng thuận, tỷ lệ hiện mắc, kappa và các tệp đầu ra. Cách khắc phục: Trước khi merge, hãy kiểm tra record_id trong cả hai tệp về tính không-null và tính duy nhất, và dừng lại nếu có trùng lặp. Ngoài ra, dùng merge(..., validate='one_to_one'). dòng 7 · phát hiện bởi gpt-5.6 · xác nhận bởi gemini-3.6-flash
3. cao Các giá trị quyết định không được kiểm chứng. Giá trị thiếu, lỗi chính tả, chữ hoa/chữ thường hoặc các danh mục bổ sung được ngầm coi như "exclude" khi tính tỷ lệ hiện mắc của include, trong khi độ đồng thuận quan sát được lại so sánh các giá trị chính xác. Do đó, phép tính không còn tương ứng với Cohen's kappa nhị phân và có thể tạo ra kết quả mâu thuẫn. Cách khắc phục: Chuẩn hóa decision một cách có kiểm soát trước khi phân tích và đảm bảo mọi giá trị đúng là 'include' hoặc 'exclude'. Xử lý riêng các giá trị thiếu hoặc không xác định như lỗi dữ liệu hoặc sàng lọc chưa hoàn tất. dòng 9 · phát hiện bởi gpt-5.6 · xác nhận bởi gemini-3.6-flash
4. cao excluded chứa tất cả các bản ghi bị người sàng lọc A loại trừ, bao gồm cả các xung đột trong đó người sàng lọc B quyết định "include". Do đó, những bản ghi như vậy được ghi vào cả excluded.csv và conflicts.csv. Nếu excluded.csv được hiểu là đại diện cho các kết quả trúng tuyển bị loại trừ cuối cùng, thì các xung đột chưa được giải quyết có thể bị loại bỏ sai khỏi quá trình đánh giá. Cách khắc phục: Khi không có quy tắc ưu tiên được ghi nhận, chỉ chọn các trường hợp loại trừ khớp nhau, tức là (decision_a == 'exclude') & (decision_b == 'exclude'). Giữ các xung đột riêng trong conflicts.csv cho đến khi có quyết định đồng thuận. dòng 16 · phát hiện bởi gpt-5.6 · xác nhận bởi gemini-3.6-flash
5. cao Lọc sai các nghiên cứu bị loại trừ: 'excluded' chỉ xét quyết định của người sàng lọc A ('merged.decision_a == "exclude"'). Nếu có xung đột (người sàng lọc A loại trừ, người sàng lọc B đưa vào), nghiên cứu bị tính sai là đã bị loại trừ. Cách khắc phục: Chỉ xuất các trường hợp loại trừ khi cả hai người sàng lọc đều nhất quán chọn 'exclude' (ví dụ: '(merged.decision_a == "exclude") & (merged.decision_b == "exclude")'), hoặc chờ xung đột được giải quyết. dòng 16 · phát hiện bởi gemini-3.6-flash · xác nhận bởi gpt-5.6
6. cao excluded.csv chứa mọi bản ghi mà người sàng lọc A loại trừ, bao gồm cả các xung đột trong đó người sàng lọc B đưa vào. Những bản ghi đó bị loại bỏ trước khi thảo luận xung đột, đây chính là kiểu loại trừ sai mà quy trình phải tránh. Cách khắc phục: Chỉ loại trừ các bản ghi mà cả hai người sàng lọc đều loại trừ: merged[(merged.decision_a == 'exclude') & (merged.decision_b == 'exclude')]; đưa mọi xung đột sang bước giải quyết trước. dòng 16 · phát hiện bởi claude · xác nhận bởi gpt-5.6, gemini-3.6-flash
7. trung bình Nếu cả hai người sàng lọc chỉ dùng cùng một danh mục, expected bằng 1 và mẫu số của kappa bằng 0. Kết quả trở thành NaN hoặc có thể tạo ra cảnh báo chia cho 0; đầu ra đã định dạng "nan" không giải thích rằng kappa là không xác định về mặt toán học. Một phần giao được phân tích rỗng cũng dẫn đến các chỉ số NaN vô nghĩa. Cách khắc phục: Trước khi chia, hãy kiểm tra xem có bất kỳ cặp quyết định hợp lệ nào không và liệu 1 - expected có lớn hơn 0 không. Trong các trường hợp suy biến, hãy báo cáo rõ ràng kappa là "không xác định" và báo cáo các tần số cơ sở. dòng 13 · phát hiện bởi gpt-5.6 · xác nhận bởi gemini-3.6-flash
8. trung bình Có thể chia cho 0 trong Cohen's kappa nếu giá trị kỳ vọng theo cơ hội 'expected' bằng 1 (ví dụ: nếu cả hai người sàng lọc chọn cùng một danh mục cho 100% bản ghi). Cách khắc phục: Trước khi tính, hãy bắt trường hợp '1 - expected == 0' và trong trường hợp đó gán một giá trị xác định (ví dụ: 1.0 hoặc NaN). dòng 12 · phát hiện bởi gemini-3.6-flash · xác nhận bởi gpt-5.6
9. trung bình Việc âm thầm loại bỏ bản ghi bởi inner join mặc định. Nếu người sàng lọc A và người sàng lọc B đã đánh giá các tập 'record_id' khác nhau, các khác biệt trong các nghiên cứu đã xử lý sẽ không được báo cáo. Ngoài ra, 'len(a)' trong đầu ra console khi đó không tương ứng với số nghiên cứu thực sự được khớp. Cách khắc phục: Kiểm tra xem 'len(a) == len(b) == len(merged)' có đúng không, hoặc thực hiện outer join để hiển thị rõ ràng các bản ghi được đánh giá chưa đầy đủ. dòng 7 · phát hiện bởi gemini-3.6-flash · xác nhận bởi gpt-5.6
10. trung bình Phép inner merge âm thầm loại bỏ các bản ghi mà chỉ một người sàng lọc đã quyết định, và số lượng được in ra dùng len(a). Các bản ghi chưa được sàng lọc biến mất khỏi cả số liệu đồng thuận lẫn số liệu PRISMA. Cách khắc phục: Merge với how='outer', indicator=True, và báo lỗi hoặc báo cáo khi bất kỳ bản ghi nào thiếu quyết định từ một trong hai người sàng lọc. dòng 7 · phát hiện bởi claude · xác nhận bởi gpt-5.6, gemini-3.6-flash
11. thấp Thiếu việc làm sạch đầu vào và xử lý giá trị thiếu trong cột 'decision'. Chữ hoa/chữ thường, khoảng trắng hoặc giá trị NaN dẫn đến so sánh sai. Cách khắc phục: Làm sạch các giá trị cột trước khi so sánh (ví dụ: với '.str.strip().str.lower()') và đảm bảo an toàn kiểu dữ liệu. dòng 9 · phát hiện bởi gemini-3.6-flash · xác nhận bởi gpt-5.6

Hiển thị: mọi phát hiện đã được xác nhận kèm cách khắc phục, đúng như các thành viên đã viết; lý lẽ của người kiểm chứng được rút gọn thành phán quyết của họ. Các trùng lặp không được gộp, nên một vấn đề có thể xuất hiện nhiều lần khi nhiều thành viên báo cáo. Mã, trọng tâm và các phát hiện của chính Claude được gửi bằng tiếng Anh; các phát hiện mà thành viên viết bằng tiếng Đức được dịch ở đây.

Năm bản tóm tắt ý tưởng từ các lĩnh vực khác nhau. ChatGPT và Gemini làm việc theo ba hướng, Claude thêm một ý tưởng, và cả hai thành viên đánh giá ẩn danh mọi ý tưởng (mỗi ý 1–10, tối đa 20 điểm). Chọn một.

Hai bài blog của tôi xếp hạng trên Google, nhưng ít người đọc bắt đầu dùng thử. Hãy cùng Kirat động não ý tưởng.

kirat_brainstorm đã hỏi hội đồng

Hội đồng đưa ra 14 ý tưởng và đánh giá ẩn danh từng ý. Ba ý tưởng hàng đầu:

1. Thay đồng hồ 14 ngày bằng ba lần gửi thực tế (18/20 điểm)
2. Hoàn thành tác vụ ngay trong bài viết (17/20 điểm)
3. Biến bài viết về việc đòi nợ thành bảng điều khiển khôi phục (17/20 điểm)

Hậu trường

kirat_brainstorm Claude gửi gì cho Kirat

GHI LẠI 2026-10-13 · KIRAT_BRAINSTORM · NỖ LỰC: TIÊU CHUẨN · 14 Ý TƯỞNG · 1 VÒNG · $0.11

Chủ đề: Ý tưởng cho một nhà phát triển độc lập để chuyển nhiều người đọc hơn của hai bài blog xếp hạng trên Google thành đăng ký dùng thử cho một công cụ lập hóa đơn dành cho người làm tự do

Ngữ cảnh đã gửi: Công cụ lập hóa đơn cho người làm tự do, 19 USD mỗi tháng, dùng thử miễn phí 14 ngày, 30 khách hàng trả phí sau 5 tháng. Đăng ký chủ yếu đến từ hai bài blog xếp hạng trên Google (cách viết hóa đơn cho người làm tự do; cách đòi các khoản thanh toán trễ). Khoảng 12% lượt dùng thử chuyển đổi. Nhà phát triển có một công việc chính và khoảng 10 giờ mỗi tuần cho sản phẩm. RÀNG BUỘC: không quảng cáo trả phí. RÀNG BUỘC: tối đa 3 giờ mỗi tuần cho việc này.

Kết quả từ hội đồng

1. 1 Thay đồng hồ 14 ngày bằng ba lần gửi thực tế gpt-5.6 · phá vỡ quy tắc · 18/20 điểm (9 + 9) Thử nghiệm một bản dùng thử kết thúc sau ba hóa đơn đã gửi hoặc ba lần nhắc thanh toán thay vì sau 14 ngày dương lịch. Điều này cố ý phá vỡ giả định mềm rằng bản dùng thử giới hạn thời gian là phù hợp: người làm nghề tự do có thể không xuất hóa đơn trong một cửa sổ hai tuần tùy ý, nên bản dùng thử hiện tại có thể hết hạn trước khi sản phẩm chứng minh được giá trị. Giữ nguyên gói 19 đô la mỗi tháng và so sánh tỷ lệ chuyển đổi từ kích hoạt sang trả phí theo nhóm thuần tập.
2. 2 Hoàn thành tác vụ ngay trong bài viết gpt-5.6 · trong phạm vi yêu cầu · 17/20 điểm (9 + 8) Nhúng một công cụ tạo hóa đơn nhỏ gọn vào bài “cách viết hóa đơn cho khách hàng tự do”: người đọc nhập khách hàng, số tiền, ngày đến hạn và điều khoản thanh toán, rồi xem bản xem trước hoàn chỉnh. “Gửi hoặc lưu hóa đơn này” tạo một bản dùng thử với các thông tin đó đã được điền sẵn, xóa bỏ khoảng cách giữa học và làm. Xây dựng theo từng phần hàng tuần giới hạn ở ba giờ, sau đó giữ chi phí bảo trì gần bằng không.
3. 3 Biến bài viết về đòi nợ thành bảng điều khiển thu hồi gpt-5.6 · lân cận · 17/20 điểm (9 + 8) Như một sự thay thế một bước cho công cụ tạo hóa đơn nhúng, cho người đọc nhập số tiền quá hạn và ngày đến hạn để tạo chuỗi ba tin nhắn đòi nợ có ghi ngày. Bắt đầu dùng thử sẽ lưu con nợ, lên lịch các tin nhắn và mở bản nháp đầu tiên sẵn sàng gửi. Điều này giữ nguyên mô thức mạnh nhất—đầu ra hữu ích trước khi đăng ký—đồng thời khớp với ý định của bài viết thứ hai.
4. 4 Đặt thời điểm chuyển đổi vào lịch của con nợ gpt-5.6 · trong phạm vi yêu cầu · 16/20 điểm (7 + 9) Cung cấp tệp .ics được tạo trong bài viết về thanh toán chậm với lời nhắc cho ngày đến hạn và các lần theo dõi leo thang vào ngày 1, 7 và 14. Mỗi sự kiện lịch chứa một liên kết sâu mở quy trình đòi nợ liên quan với ngày tháng đã điền sẵn, đưa người đọc quay lại khi nỗi đau là thật thay vì khi họ chỉ đang tìm hiểu. Nó không yêu cầu thu thập email và có thể chạy không cần giám sát.
5. 5 Gói miễn phí vĩnh viễn cho một khách hàng thay vì thời gian dùng thử gemini-3.6-flash · phá vỡ quy tắc · 16/20 điểm (8 + 8) Ý tưởng này phá vỡ ràng buộc mềm của bản dùng thử 14 ngày và thay thế bằng gói freemium cho đúng một khách hàng đang hoạt động. Người làm nghề tự do sử dụng sản phẩm miễn phí vĩnh viễn cho khách hàng đầu tiên và nâng cấp liền mạch lên mức giá cố định 19 đô la ngay khi thêm khách hàng thứ hai.
6. 6 Định tuyến người đọc theo vấn đề tức thời gpt-5.6 · trong phạm vi yêu cầu · 14/20 điểm (8 + 6) Thay các biểu ngữ dùng thử chung chung bằng ba lựa chọn nội tuyến như “Tôi cần hóa đơn đầu tiên,” “Tôi xuất hóa đơn thường xuyên,” và “Một khách hàng đã trễ hạn.” Mỗi lựa chọn mở một trạng thái onboarding tương ứng thay vì cùng một trang chủ, và ID phần của bài viết có thể chọn sẵn các giá trị mặc định hợp lý. Đo lường việc kích hoạt dùng thử đã hoàn tất, không chỉ số lần nhấp CTA, và thử nghiệm một tuyến mỗi tuần.
7. 7 Xuất bản ba bản chỉnh sửa hóa đơn pháp y gpt-5.6 · trong phạm vi yêu cầu · 14/20 điểm (8 + 6) Với sự cho phép, biến ba hóa đơn của khách hàng đã ẩn danh thành các nghiên cứu điển hình trước-và-sau tĩnh cho thấy chính xác điều gì đã thay đổi và tại sao. Chèn mỗi bản chỉnh sửa bên cạnh lời khuyên liên quan trong bài xếp hạng, với CTA mở cùng cấu trúc đã sửa dưới dạng mẫu dùng thử có thể chỉnh sửa. Bằng chứng cụ thể từ một cơ sở khách hàng nhỏ có thể đáng tin hơn các lời chứng thực chung chung.
8. 8 Cho người đọc mang tiến trình giữa hai bài viết gpt-5.6 · trong phạm vi yêu cầu · 14/20 điểm (7 + 7) Lưu trữ cục bộ trong trình duyệt loại tiền tệ, giai đoạn hóa đơn và ngày đến hạn mà người đọc đã chọn, rồi dùng trạng thái đó khi họ chuyển giữa hai bài viết. Người đã tạo kế hoạch hóa đơn sau đó có thể thấy lời nhắc theo ngữ cảnh như “Hóa đơn của bạn hiện đã trễ 3 ngày—mở thư theo dõi đã chuẩn bị,” với onboarding dùng thử đã điền sẵn. Điều này tạo ra một hành trình nhẹ nhàng qua hai bài viết mà không cần tài khoản hay sản xuất nội dung liên tục.
9. 9 Công cụ cấu hình thư nhắc nhở tương tác gemini-3.6-flash · trong phạm vi yêu cầu · 14/20 điểm (7 + 7) Thêm một công cụ tạo thư nhắc thanh toán leo thang vào bài viết về theo dõi các khoản thanh toán quá hạn. Sau khi nhập văn bản, mẫu được tạo, kết hợp với CTA để thiết lập nhắc nhở thanh toán tự động cho các hóa đơn trong tương lai trong tài khoản dùng thử.
10. 10 Liên kết ma thuật gửi tức thì không cần đăng ký trước gemini-3.6-flash · lân cận · 14/20 điểm (8 + 6) Biến thể của công cụ tạo trong nội dung: người đọc nhập thông tin hóa đơn trực tiếp trong bài blog và nhấp Gửi hóa đơn ngay bây giờ. Ở chế độ nền, hệ thống tạo liền mạch một tài khoản dùng thử và gửi email trực tiếp; mật khẩu chỉ được đặt sau đó.
11. 11 Công cụ tạo hóa đơn trực tiếp trong bài blog gemini-3.6-flash · trong phạm vi yêu cầu · 13/20 điểm (6 + 7) Nhúng một công cụ biểu mẫu tương tác đơn giản trực tiếp vào bài viết về viết hóa đơn. Người đọc nhập thông tin hóa đơn và có thể tải xuống PDF hoàn chỉnh ngay lập tức và miễn phí. Một nút nổi bật đề nghị gửi hóa đơn kỹ thuật số chỉ với một cú nhấp và theo dõi trạng thái thanh toán trong tài khoản dùng thử 14 ngày.
12. 12 Nhắc nhở trả theo lần dùng thay vì đăng ký hàng tháng gemini-3.6-flash · phá vỡ quy tắc · 13/20 điểm (6 + 7) Ý tưởng này phá vỡ ràng buộc mềm của mô hình đăng ký SaaS thuần túy ở mức 19 đô la mỗi tháng. Với khoản phí một lần 5 đô la, người đọc bài viết về thanh toán chậm có thể được gửi một thư nhắc nhở hợp pháp kèm liên kết theo dõi, với khoản phí được ghi có đầy đủ nếu sau đó họ đăng ký.
13. 13 Mẫu mở ngay trong công cụ claude · trong phạm vi yêu cầu · 11/20 điểm (6 + 5) Cung cấp mẫu hóa đơn từ bài viết dưới dạng hóa đơn sẵn sàng sử dụng trong công cụ: một cú nhấp mở tài khoản dùng thử đã điền sẵn thay vì tải xuống tệp.
14. 14 Ý định thoát theo vấn đề cụ thể với chuỗi email tự động gemini-3.6-flash · trong phạm vi yêu cầu · 8/20 điểm (4 + 4) Triển khai cửa sổ bật lên khi có ý định thoát trên bài viết về thanh toán chậm, đề nghị một mẫu email khẩn cấp cho khách hàng thanh toán chậm để đổi lấy địa chỉ email. Một chuỗi email tự động gồm ba phần sau đó giải thích thụ động cách các quy trình tự động giảm thiểu thanh toán chậm, và liên kết đến tài khoản dùng thử.

Brainstorm với Kirat: làm thế nào để biến việc xây dựng lại cửa hàng một lần này thành một gói chăm sóc mà khách hàng thực sự muốn?

kirat_brainstorm đã hỏi hội đồng

Hội đồng đưa ra 15 ý tưởng và chấm điểm từng ý tưởng một cách ẩn danh. Ba ý tưởng hàng đầu:

1. Phá vỡ ngân sách: vận hành trước vẻ hào nhoáng khi ra mắt (18/20 điểm)
2. Người gác cổng sản phẩm CSV (17/20 điểm)
3. Cổ tức độ tin cậy (17/20 điểm)

Hậu trường

kirat_brainstorm Những gì Claude gửi đến Kirat

GHI LẠI 2026-10-13 · KIRAT_BRAINSTORM · NỖ LỰC: TIÊU CHUẨN · 15 Ý TƯỞNG · 1 VÒNG · $0.10

Chủ đề: Ý tưởng cho một agency kỹ thuật số nhỏ để biến việc xây dựng lại cửa hàng một lần thành một gói chăm sóc định kỳ mà khách hàng thực sự muốn

Ngữ cảnh đã gửi: Agency gồm 4 người. Khách hàng bán khoảng 1.800 sản phẩm nội thất tại Đức, Áo và Thụy Sĩ, có 3 nhân viên và không có lập trình viên nội bộ, doanh thu khoảng 1,2 triệu EUR mỗi năm. Cửa hàng WooCommerce tự lưu trữ cũ có 31 plugin và hai sự cố bảo mật trong năm ngoái; khách hàng muốn giảm bảo trì và ít tình huống khẩn cấp hơn. Một ERP cục bộ xuất dữ liệu sản phẩm dưới dạng CSV. Ngân sách xây dựng lại: 25.000 EUR. RÀNG BUỘC CỨNG: không khóa nhà cung cấp; khách hàng phải có thể rời đi với toàn bộ dữ liệu và quyền truy cập bất cứ lúc nào. RÀNG BUỘC CỨNG: không tuyển thêm người tại agency.

Kết quả từ hội đồng

1. 1 Phá vỡ ngân sách: vận hành trước khi ra mắt gpt-5.6 · phá vỡ quy tắc · 18/20 điểm (9 + 9) Ý tưởng này cố ý phá vỡ ràng buộc mềm về ngân sách tái thiết 25.000 EUR: ví dụ, gói chào là 22.000 EUR cho một lần ra mắt tinh gọn có chủ đích cộng với 12.000 EUR cho năm vận hành đầu tiên có ràng buộc. Đổi lại, các tính năng "nice-to-have" bị loại khỏi dự án ban đầu; thay vào đó, việc gia cố phần nhập dữ liệu, diễn tập khôi phục, giám sát và cải tiến hàng tháng được tài trợ. Tổng khối lượng cao hơn này có lợi vì khách hàng không còn phải mua một cửa hàng trông như đã hoàn thiện mà chi phí vận hành thực tế chỉ lộ ra sau khi ra mắt; mọi thông tin đăng nhập, dữ liệu và kết quả công việc luôn có thể chuyển giao bất cứ lúc nào.
2. 2 Người gác cổng sản phẩm CSV gpt-5.6 · trong phạm vi · 17/20 điểm (9 + 8) Trước mỗi lần nhập vào ERP, một pipeline tự động kiểm tra CSV để tìm giá thiếu, bản trùng, biến thể không hợp lệ, lỗi hình ảnh, logic thuế DACH và các thay đổi tồn kho đáng ngờ. Phí duy trì hàng tháng bao gồm việc bảo trì quy tắc, giám sát nhập dữ liệu và một báo cáo lỗi dễ hiểu cho ba nhân viên. Điều này biến việc bảo trì kỹ thuật thành lợi ích kinh doanh trực tiếp: ít sản phẩm sai hơn, ít câu hỏi tiếp theo hơn và ít giỏ hàng bị bỏ dở hơn.
3. 3 Cổ tức độ tin cậy gpt-5.6 · trong phạm vi · 17/20 điểm (8 + 9) Khách hàng trả một khoản phí cơ bản vừa phải cho giám sát và bảo trì; một khoản bổ sung hàng quý chỉ đến hạn nếu các mục tiêu độ tin cậy đã thỏa thuận như nhập dữ liệu thành công, khôi phục đã kiểm thử và thời gian phản hồi đã được đáp ứng. Các sự cố ngừng hoạt động có thể tránh được do agency gây ra sẽ tạo ra tín dụng dịch vụ thay vì giờ xử lý khẩn cấp có thể tính phí. Mô hình này gắn động cơ kinh tế với việc phòng ngừa và xóa bỏ nỗi lo của khách hàng rằng agency kiếm lợi từ các vấn đề.
4. 4 Hiến chương chăm sóc sẵn sàng rời đi gpt-5.6 · trong phạm vi · 16/20 điểm (9 + 7) Gói duy trì được bán có chủ đích như một sản phẩm chống khóa chặt: giám sát, cập nhật, sao lưu, kiểm tra bảo mật và hai thay đổi nhỏ mỗi tháng với khoảng 1.200–1.500 EUR. Mọi tài khoản do khách hàng nắm giữ, mã nguồn và script nhập dữ liệu nằm trong kho lưu trữ của khách hàng; mỗi tháng khách hàng còn nhận được tài liệu, bản xuất dữ liệu và một gói bàn giao cho phép họ hủy bất cứ lúc nào. Bằng cách này, khách hàng trả tiền cho khả năng vận hành chứng minh được thay vì sự phụ thuộc.
5. 5 Chuyến tàu phát hành theo mùa gpt-5.6 · trong phạm vi · 16/20 điểm (8 + 8) Thay vì các phiếu hỗ trợ tùy ý, có bốn bản phát hành thương mại điện tử có thể lên kế hoạch mỗi năm, ví dụ cho đồ nội thất sân vườn, cuối mùa hè, Black Week và Giáng sinh. Mỗi bản phát hành trong gói duy trì bao gồm một gói UX hoặc merchandising nhỏ, kiểm thử hồi quy và việc bảo trì kỹ thuật ở giữa. Điều này mang lại cho khách hàng sự phát triển liên tục hữu hình và giữ cho khối lượng công việc có thể gộp lại cho agency bốn người.
6. 6 Bài kiểm tra lối thoát hàng quý gpt-5.6 · trong phạm vi · 16/20 điểm (9 + 7) Mỗi quý một lần, agency cung cấp bản xuất đầy đủ dữ liệu sản phẩm, khách hàng, đơn hàng và nội dung, đồng thời thực hiện một lần khởi động lại có tài liệu trong môi trường kiểm thử trung lập. Điều khách hàng trả tiền, trớ trêu thay, chính là lối thoát được chứng minh thường xuyên: danh sách quyền truy cập, nhật ký khôi phục và sổ tay bàn giao thuộc về khách hàng. Tiêu chí cứng "không khóa chặt" nhờ vậy biến từ một phản đối thành một điểm bán hàng khác thường cho gói duy trì.
7. 7 Hiến chương chăm sóc cộng trao đổi tăng trưởng gpt-5.6 · lân cận · 16/20 điểm (8 + 8) Như một biến thể nhỏ của Hiến chương chăm sóc sẵn sàng rời đi, số giờ thay đổi bao gồm không cố định trước mà được dịch chuyển hàng tháng giữa vận hành, chất lượng dữ liệu và cải thiện chuyển đổi; khối lượng chưa dùng được chuyển sang tối đa một quý. Một cuộc họp ban điều hành chung 30 phút quyết định cách sử dụng chúng, dựa trên rủi ro và cơ hội doanh thu. Gói duy trì vẫn sẵn sàng rời đi nhưng cảm giác ít giống bảo hiểm hơn và giống một đội ngũ kỹ thuật số bên ngoài linh hoạt hơn.
8. 8 Gói duy trì đồng bộ ERP & an toàn danh mục gemini-3.6-flash · trong phạm vi · 13/20 điểm (7 + 6) Agency đảm nhận việc giám sát và bảo trì liên tục giao diện giữa CSV ERP cục bộ và cửa hàng trực tuyến. Các lần nhập dữ liệu lỗi, biến thể nội thất bị thiếu hoặc giá sai được phát hiện tự động trước khi đưa lên live. Điều này hoàn toàn gỡ bỏ gánh nặng vận hành bảo trì dữ liệu khỏi đội ngũ 3 người của khách hàng.
9. 9 Gói phẳng làm giàu dữ liệu sản phẩm bằng AI gemini-3.6-flash · lân cận · 13/20 điểm (6 + 7) Biến thể của ý tưởng giao diện ERP: agency không chỉ bảo trì việc nhập CSV mà còn dùng script AI để tự động làm giàu dữ liệu thô với các thuộc tính có cấu trúc, nội dung SEO và ghi chú thời gian giao hàng riêng cho DACH. Điều này tiết kiệm công sức bảo trì thủ công cho khách hàng và tăng khả năng hiển thị trên thị trường nội thất mà không cần thêm nhân sự agency.
10. 10 Hợp đồng bảo trì hồi quy trực quan dựa trên CI/CD gemini-3.6-flash · trong phạm vi · 12/20 điểm (6 + 6) Thay vì các bản cập nhật live rủi ro, agency thiết lập một pipeline staging tự động kiểm tra trực quan và chức năng các bản cập nhật plugin hàng tháng. Khách hàng nhận được báo cáo minh bạch hàng tháng và thời gian phản hồi được đảm bảo cho các lỗ hổng bảo mật. Điều này đảm bảo sự ổn định tuyệt đối mà không còn các tình huống khẩn cấp trước đây.
11. 11 Tinh chỉnh chuyển đổi & UX hàng quý gemini-3.6-flash · trong phạm vi · 11/20 điểm (6 + 5) Ngoài bảo trì cơ bản, gói duy trì bao gồm hạn mức giờ cố định để tối ưu hóa chức năng thanh toán và hiển thị biến thể nội thất. Agency phân tích hành vi người dùng ở khu vực DACH mỗi tháng và triển khai các điều chỉnh có lợi nhuận cao. Điều này biến gói duy trì từ một yếu tố chi phí thuần túy thành một động lực doanh thu.
12. 12 Đảm bảo cập nhật an toàn & hoàn tác tức thì gemini-3.6-flash · lân cận · 11/20 điểm (5 + 6) Biến thể của hợp đồng bảo trì CI/CD: gói duy trì tập trung thuần túy vào SLA không ngừng hoạt động được đảm bảo với việc khôi phục snapshot tự động trong vòng 15 phút khi có sự cố. Điều này trực tiếp giải quyết nỗi lo của khách hàng sau hai sự cố bảo mật, với nỗ lực thủ công liên tục tối thiểu.
13. 13 Gói tăng trưởng chia sẻ doanh thu thay vì ngân sách cố định gemini-3.6-flash · phá vỡ quy tắc · 9/20 điểm (4 + 5) Phá vỡ giả định mềm về ngân sách tái thiết một lần cố định 25.000 EUR: chi phí tái thiết được giảm xuống 10.000 EUR, kết hợp với gói duy trì hàng tháng có một phần nhỏ doanh thu bổ sung. Điều này có lợi vì khách hàng giảm rủi ro đầu tư và agency tham gia trực tiếp vào sự tăng trưởng của cửa hàng trị giá 1,2 triệu EUR.
14. 14 Dịch vụ chăm sóc kiến trúc Headless gemini-3.6-flash · phá vỡ quy tắc · 7/20 điểm (3 + 4) Phá vỡ ràng buộc mềm về thiết lập monolith cổ điển (như WooCommerce tiêu chuẩn): frontend được tách khỏi backend, nên các lỗ hổng bảo mật của plugin không còn có thể tấn công trực tiếp vào website. Điều này có lợi vì các tình huống khẩn cấp bị loại bỏ về mặt cấu trúc và khách hàng luôn có thể di chuyển nhờ ngăn xếp mã nguồn mở và quyền truy cập Git đầy đủ.
15. 15 Báo cáo chăm sóc một trang hàng tháng claude · trong phạm vi · 6/20 điểm (4 + 2) Một báo cáo hàng tháng dài một trang với thời gian hoạt động, tốc độ trang, các bản cập nhật đã áp dụng và các sự cố đã ngăn chặn, để khách hàng thấy được gói duy trì trả tiền cho cái gì.

Trang đặt hàng mới của chúng tôi sẽ ra mắt vào tháng tới. Hãy cùng Kirat động não xem làm thế nào để có thêm đơn đặt bánh trước mà không cần quảng cáo trả phí.

kirat_brainstorm đã hỏi hội đồng

Hội đồng đưa ra 15 ý tưởng và chấm điểm từng ý tưởng một cách ẩn danh. Ba ý tưởng hàng đầu:

1. Chế độ tự động sinh nhật hàng năm (18/20 điểm)
2. Khung giờ bánh thực sự thay vì các bài đăng chung chung (17/20 điểm)
3. Chiếc bánh tự trở thành phương tiện quảng cáo của chính nó (16/20 điểm)

Hậu trường

kirat_brainstorm Những gì Claude gửi cho Kirat

GHI NHẬN 2026-10-13 · KIRAT_BRAINSTORM · NỖ LỰC: TIÊU CHUẨN · 15 Ý TƯỞNG · 1 VÒNG · $0.09

Chủ đề: Ý tưởng cho một tiệm bánh địa phương để có thêm đơn đặt bánh tùy chỉnh trước thông qua trang đặt hàng trực tuyến mới, không dùng quảng cáo trả phí

Bối cảnh đã gửi: Tiệm bánh với 6 nhân viên ở một thị trấn Đức có 40.000 dân. Bánh tùy chỉnh và đặt trước có biên lợi nhuận tốt nhất. Một trang đặt hàng trực tuyến mới (chọn bánh, ngày lấy hàng, trả trước) sẽ ra mắt vào tháng tới; đến nay đơn hàng chỉ đến qua điện thoại và email. Hồ sơ Doanh nghiệp trên Google có 4,7 sao từ 120 đánh giá. Chủ tiệm có ít thời gian, nên các ý tưởng phải chạy được với tối đa 2 giờ mỗi tuần. CỨNG: không quảng cáo trả phí trong quý này. CỨNG: không thêm nhân viên.

Kết quả từ hội đồng

1. 1 Chế độ tự động gửi lời chúc sinh nhật hằng năm gpt-5.6 · trong phạm vi yêu cầu · 18/20 điểm (9 + 9) Khi thanh toán, khách hàng có thể tự nguyện để lại dịp kỷ niệm và tháng để nhận lời nhắc vào năm sau. Một email tự động gửi trước 21 ngày dẫn đến trang đặt hàng đã điền sẵn; theo cách này, mỗi đơn hàng tạo ra một đơn hàng tương lai, không cần liên tục thu hút khách hàng mới và với sự đồng ý rõ ràng.
2. 2 Khung giờ bánh thực tế thay vì các bài đăng chung chung gpt-5.6 · trong phạm vi yêu cầu · 17/20 điểm (9 + 8) Trang đặt hàng hiển thị số khung giờ sản xuất thực tế còn trống cho bốn tuần tới, chẳng hạn như "Vẫn còn 2 bánh thiết kế riêng cho Thứ Bảy". Một bài đăng Google Business hằng tuần liên kết trực tiếp đến chế độ xem này; việc cập nhật và đăng bài cùng nhau mất tối đa 20 phút và tạo ra sự cấp bách đáng tin cậy mà không cần giảm giá.
3. 3 Chiếc bánh tự trở thành phương tiện quảng cáo gpt-5.6 · trong phạm vi yêu cầu · 16/20 điểm (8 + 8) Mỗi chiếc bánh được nhận kèm một tấm thiệp nhỏ ghi "Đặt lại hoặc tùy chỉnh chiếc bánh này" và mã QR cho biến thể tương ứng. Tấm thiệp được trưng bày rõ ràng khi cắt bánh, để chính những vị khách dự sinh nhật hoặc đám cưới có mặt khám phá ra cách đặt hàng; một bộ thiệp được tạo một lần hầu như không tốn công sức hằng tuần.
4. 4 Giờ tư vấn bánh một lần khi ra mắt gpt-5.6 · phá vỡ quy tắc · 16/20 điểm (8 + 8) Vào Thứ Bảy đầu tiên sau khi ra mắt có một giờ tư vấn bánh mở kéo dài bốn tiếng: khách chọn hương vị và phong cách từ các thẻ mẫu rồi tự đặt hàng qua mã QR được bày sẵn cho họ. Điều này cố ý phá vỡ ràng buộc mềm về tối đa hai giờ công sức trong tuần đó; công sức thêm được đền đáp vì các đơn hàng thực tế, các vấn đề khả dụng được quan sát và ảnh chụp cùng câu hỏi của khách hàng có thể tái sử dụng đều được tạo ra cùng lúc — mà không cần thêm nhân viên hay quảng cáo trả phí.
5. 5 Đối tác theo dịp thay vì người có ảnh hưởng gpt-5.6 · trong phạm vi yêu cầu · 15/20 điểm (8 + 7) Các khu vui chơi trẻ em, nhiếp ảnh gia, người bán hoa, địa điểm tổ chức cưới và câu lạc bộ mỗi bên nhận một giá đỡ QR nhỏ dẫn đến lựa chọn bánh được cấu hình sẵn cho dịp của họ. Đổi lại, tiệm bánh nêu tên các đối tác này trên một trang giới thiệu địa phương; năm lời đề nghị có mục tiêu mỗi tháng là đủ, và loại bỏ được hoa hồng cùng chi phí tiếp cận trả phí.
6. 6 Lịch luân phiên bánh cho văn phòng và câu lạc bộ gpt-5.6 · trong phạm vi yêu cầu · 15/20 điểm (8 + 7) Các văn phòng, phòng khám và câu lạc bộ địa phương nhận một trang nơi có thể tập hợp nhiều ngày sinh nhật hoặc ngày định kỳ và trả trước lần lượt. Lịch luân phiên hằng quý, một khi đã thiết lập, biến các dịp riêng lẻ thành các đơn hàng theo chuỗi có thể lên kế hoạch; việc tiếp cận có thể giới hạn ở hai tổ chức mỗi tuần.
7. 7 Tư vấn bánh kết hợp tại máy tính bảng quầy hàng gemini-3.6-flash · phá vỡ quy tắc · 14/20 điểm (7 + 7) Cố ý phá vỡ ràng buộc mềm 'chỉ đặt hàng trực tuyến' bằng cách cung cấp 1 giờ tư vấn tại cửa hàng vào các ngày Thứ Sáu, trong đó đơn hàng được nhập cùng nhau trên máy tính bảng. Điều này được đền đáp vì những khách hàng do dự và lớn tuổi dần được làm quen với hệ thống trực tuyến mới.
8. 8 Đánh giá trở thành công cụ hỗ trợ quyết định gpt-5.6 · lân cận · 13/20 điểm (7 + 6) Như một sự tái kết hợp nhỏ từ tài liệu mạnh nhất hiện có, mười hai câu có ý nghĩa từ 120 đánh giá Google được ghép với các phong cách bánh phù hợp, mỗi câu kèm một liên kết đặt hàng trực tiếp. Theo cách này, 4,7 sao không chỉ được hiển thị như một tín hiệu tin cậy mà còn hỗ trợ lựa chọn sản phẩm; sau khi thiết lập một lần, trang hầu như không cần bảo trì.
9. 9 Trưng bày bánh mẫu với liên kết sâu đến cửa hàng gemini-3.6-flash · lân cận · 13/20 điểm (6 + 7) Một phòng trưng bày ảnh vật lý gồm những chiếc bánh đẹp nhất trong phòng bán hàng bao gồm một mã QR cụ thể cho mỗi bức ảnh, mở đúng mẫu bánh này đã được chọn sẵn trong cửa hàng trực tuyến. Biến thể của ý tưởng 1: liên kết màn hình trưng bày trong cửa hàng với một liên kết sâu trực tiếp trong cửa hàng.
10. 10 Tối ưu hồ sơ Google & liên kết đánh giá tự động gemini-3.6-flash · trong phạm vi yêu cầu · 12/20 điểm (6 + 6) Hồ sơ Google mạnh (4,7 sao) được bổ sung nút 'Đặt hàng trực tuyến' chính thức và cập nhật hằng tuần với ảnh những chiếc bánh hiện tại. Khi nhận hàng, khách hàng nhận được một mẫu email với liên kết đến trang đánh giá và đặt lại hàng. Mất dưới 30 phút mỗi tuần.
11. 11 Mã QR gợi ý trên hóa đơn & túi đựng bánh mì gemini-3.6-flash · trong phạm vi yêu cầu · 11/20 điểm (6 + 5) Một mã QR bắt mắt được in trên mọi hóa đơn và trên bao bì, dẫn trực tiếp đến công cụ cấu hình bánh trực tuyến ('Lên kế hoạch cho chiếc bánh trong mơ của bạn cho dịp kỷ niệm trực tuyến'). Điều này chuyển đổi khách hàng ghé thăm hằng ngày thành người đặt trước kỹ thuật số mà không tốn thêm công sức tại quầy.
12. 12 Hợp tác B2B với các địa điểm tổ chức sự kiện địa phương gemini-3.6-flash · trong phạm vi yêu cầu · 11/20 điểm (6 + 5) Giá đỡ và tờ rơi có mã đặt hàng trực tiếp cho trang web được đặt tại các nhà hàng, nhà kho tổ chức sự kiện và nhà tổ chức cưới địa phương. Khách hàng tổ chức kỷ niệm đặt bánh trực tiếp trực tuyến, trong khi địa điểm nhận một khoản phụ cấp nhỏ hoặc một lời giới thiệu đổi lại.
13. 13 Lịch sinh nhật trường mầm non & trường học gemini-3.6-flash · lân cận · 10/20 điểm (4 + 6) Hợp tác với các trường mẫu giáo địa phương thông qua tờ rơi thông tin cho hội phụ huynh có chứa mã giảm giá cố định cho bánh theo chủ đề trẻ em. Biến thể của ý tưởng 3: thay vì các đối tác B2B chung, dịp có tần suất cao là sinh nhật trẻ em được nhắm đến cụ thể theo cách tự động.
14. 14 Buổi hội thảo nhỏ hằng tháng về bánh trang trí gemini-3.6-flash · phá vỡ quy tắc · 10/20 điểm (4 + 6) Cố ý phá vỡ ràng buộc mềm 'tối đa 2 giờ thời gian mỗi tuần', vì một buổi hội thảo kéo dài 4 giờ diễn ra mỗi tháng một lần. Điều này được đền đáp vì những người tham gia trở thành đại sứ thương hiệu, tạo ra nội dung mạng xã hội đầy nhiệt huyết và chắc chắn đặt hàng tiếp theo qua cửa hàng trực tuyến.
15. 15 Liên kết đặt hàng trên mọi hộp bánh claude · trong phạm vi yêu cầu · 8/20 điểm (4 + 4) In một mã QR dẫn đến trang đặt hàng trên các hộp bánh và hóa đơn, để mọi khách hàng đã mua bánh có thể đặt lại cho sinh nhật tiếp theo mà không cần gọi điện.

Ghi chú của Kirat cho Claude: Ý tưởng phá vỡ quy tắc hay nhất chỉ ở hạng 4: "Giờ tư vấn bánh một lần khi ra mắt" — nó cố ý phá vỡ một ràng buộc mềm. Hãy lập luận ủng hộ nó một lần trước khi loại bỏ.

Cùng Kirat động não xem làm thế nào chúng ta cắt giảm sự cố thanh toán trong vòng hai quý mà không tách riêng phần thanh toán ra khỏi khối nguyên khối.

kirat_brainstorm đã hỏi hội đồng

Hội đồng đưa ra 15 ý tưởng và chấm điểm từng ý tưởng một cách ẩn danh. Ba ý tưởng hàng đầu:

1. Tường lửa cơ sở dữ liệu bao quanh các bảng thanh toán (17/20 điểm)
2. Các bất biến tài chính có thể thực thi (17/20 điểm)
3. Phát lại sự cố như một chặng thử thách phát hành (17/20 điểm)

Hậu trường

kirat_brainstorm Những gì Claude gửi cho Kirat

ĐÃ GHI 2026-10-13 · KIRAT_BRAINSTORM · NỖ LỰC: TIÊU CHUẨN · 15 Ý TƯỞNG · 1 VÒNG · $0.06

Chủ đề: Các ý tưởng để cắt giảm sự cố sản xuất do mô-đun thanh toán gây ra trong vòng hai quý, mà không tách nó thành một dịch vụ riêng

Ngữ cảnh đã gửi: Nhóm 8 kỹ sư. Một khối nguyên khối TypeScript, khoảng 60.000 dòng, một cơ sở dữ liệu Postgres, triển khai nhiều lần mỗi ngày. Mô-đun thanh toán thay đổi hằng tuần và gây ra 5 trong 8 sự cố sản xuất gần nhất, chủ yếu do các mô-đun khác đọc và ghi trực tiếp vào các bảng thanh toán. Không ai trong nhóm đã vận hành một hệ thống phân tán trong môi trường sản xuất. Ban lãnh đạo muốn ít sự cố hơn trong vòng hai quý. RÀNG BUỘC CỨNG: không viết lại mô-đun thanh toán. RÀNG BUỘC CỨNG: công việc tính năng trên thanh toán vẫn tiếp tục hằng tuần.

Kết quả từ hội đồng

1. 1 Tường lửa cơ sở dữ liệu bao quanh các bảng thanh toán gpt-5.6 · trong phạm vi yêu cầu · 17/20 điểm (9 + 8) Tạo các role Postgres riêng cho các luồng mã thanh toán và không thanh toán của monolith, sau đó thu hồi quyền ghi trực tiếp vào các bảng thanh toán khỏi role ứng dụng chung. Định tuyến mọi thao tác thay đổi qua một tập nhỏ các stored procedure hoặc transaction function đã được rà soát, trước tiên thêm ghi log kiểm toán tạm thời để phát hiện và di chuyển các caller mà không dừng công việc tính năng hàng tuần.
2. 2 Các bất biến tài chính có thể thực thi gpt-5.6 · trong phạm vi yêu cầu · 17/20 điểm (9 + 8) Mã hóa một danh sách ngắn các bất biến—chẳng hạn như hóa đơn đã chốt bất biến, bút toán sổ cái cân bằng, tạo khoản phí idempotent và chuyển trạng thái hợp lệ—thành ràng buộc cơ sở dữ liệu ở nơi an toàn và thành các probe production theo lịch ở nơi không an toàn. Chạy cùng các probe đó trên các fixture có hình dạng production đã ẩn danh trong CI, biến kiến thức từ sự cố thành bẫy thường trực thay vì mở rộng kiểm thử tràn lan.
3. 3 Phát lại sự cố như một chặng thử thách phát hành gpt-5.6 · trong phạm vi yêu cầu · 17/20 điểm (9 + 8) Chuyển năm sự cố thanh toán thành các kịch bản phát lại tất định bằng cách dùng các hình dạng truy vấn đã ghi lại và các dòng đã làm sạch, sau đó yêu cầu mọi thay đổi thanh toán phải vượt qua chúng. Thêm các kiểm thử sinh tự động hoán vị retry, sự kiện trùng lặp, thứ tự giao dịch và lỗi một phần quanh đúng các kịch bản đó, nhắm vào vùng lân cận lỗi thay vì cố bao phủ toàn bộ monolith.
4. 4 Thực thi ranh giới thanh toán ở chế độ bóng gpt-5.6 · lân cận · 16/20 điểm (9 + 7) Như một biến thể rủi ro thấp hơn của tường lửa cơ sở dữ liệu, ban đầu giữ nguyên quyền hiện tại nhưng ghi log mọi truy vấn chạm vào bảng thanh toán kèm module, vị trí gọi và ID giao dịch. Sau bốn tuần, biến các thao tác ghi bất ngờ thành lỗi CI, rồi thành lỗi production theo từng module; điều này thay thế việc chuyển đổi quyền tức thời bằng thực thi theo giai đoạn.
5. 5 Bảng điều khiển bán kính ảnh hưởng thanh toán gpt-5.6 · trong phạm vi yêu cầu · 16/20 điểm (9 + 7) Đặt các hành vi thanh toán rủi ro—không phải toàn bộ module—phía sau các kill switch phía server và triển khai theo tỷ lệ phần trăm, với dashboard gắn với các bất thường về hóa đơn, thanh toán và đối soát. Mỗi tính năng hàng tuần đi kèm một đường tắt đã được kiểm thử để người xử lý có thể vô hiệu hóa hành vi mới mà không hoàn nguyên các triển khai monolith không liên quan hoặc hoàn tác migration schema.
6. 6 Đóng gói schema Postgres và Row Level Security gemini-3.6-flash · trong phạm vi yêu cầu · 15/20 điểm (7 + 8) Cô lập các bảng thanh toán trong một schema Postgres chuyên dụng (billing.*) và thu hồi quyền ghi và đọc trực tiếp khỏi các role DB khác. Các module chỉ truy cập chúng qua các view SQL hoặc giao diện stored đã định nghĩa. Điều này loại bỏ trực tiếp nguyên nhân chính của các sự cố ở cấp cơ sở dữ liệu.
7. 7 Kiểm thử hợp đồng và pipeline bóng cho các bản phát hành thanh toán gemini-3.6-flash · trong phạm vi yêu cầu · 15/20 điểm (8 + 7) Thiết lập kiểm thử hợp đồng tự động do consumer dẫn dắt cho tất cả giao diện thanh toán trong pipeline CI. Ngoài ra, các thay đổi thanh toán đối với tính toán quan trọng chạy ở chế độ bóng trong production, không có tác dụng phụ và có kiểm tra khác biệt tự động.
8. 8 Cơ sở dữ liệu thứ hai như một công cụ an toàn gpt-5.6 · phá vỡ quy tắc · 14/20 điểm (7 + 7) Cố ý phá vỡ giả định mềm "một cơ sở dữ liệu Postgres" bằng cách thêm một cơ sở dữ liệu bóng chỉ đọc được nạp qua logical replication, trong khi vẫn giữ thanh toán bên trong monolith và giữ primary là nơi ghi duy nhất. Chạy các thao tác đọc thanh toán mới và kiểm tra đối soát trên cả hai cơ sở dữ liệu, so sánh kết quả trước khi phơi bày, và dùng bản bóng cho các truy vấn điều tra để việc chẩn đoán sự cố không thể làm quá tải hoặc vô tình thay đổi production.
9. 9 Lint ranh giới module nghiêm ngặt và facade API công khai gemini-3.6-flash · trong phạm vi yêu cầu · 14/20 điểm (7 + 7) Giới thiệu lint kiến trúc qua dependency-cruiser để cấm các import trực tiếp vào nội bộ thanh toán trong các module khác ở bước build. Giao tiếp chỉ có thể diễn ra qua một giao diện BillingFacade an toàn kiểu duy nhất, để chặn ngay sự ghép nối len lỏi.
10. 10 Hộ chiếu thay đổi thanh toán gpt-5.6 · trong phạm vi yêu cầu · 13/20 điểm (7 + 6) Yêu cầu mọi pull request liên quan đến thanh toán phải mang một hộ chiếu được kiểm tra bằng máy: các bảng bị ảnh hưởng, bất biến, khả năng tương thích migration, đường rollback và một truy vấn production chứng minh sức khỏe sau triển khai. Một cổng CODEOWNERS cộng với đánh giá của người phụ trách thanh toán luân phiên 15 phút giữ quy trình đủ nhẹ cho các thay đổi hàng tuần trong khi tập trung rà soát vào các tác động liên module.
11. 11 View Postgres chỉ đọc tự động tạo cho các module bên ngoài gemini-3.6-flash · lân cận · 13/20 điểm (7 + 6) Một biến thể của đóng gói schema: thay vì tái cấu trúc API tốn kém, các view Postgres chỉ đọc được cung cấp tự động cho các truy vấn bên ngoài. Các module bên ngoài chỉ đọc các view ổn định này, trong khi truy cập trực tiếp vào bảng bị chặn qua quyền DB.
12. 12 Event bus bất đồng bộ trong tiến trình cho các read model gemini-3.6-flash · trong phạm vi yêu cầu · 12/20 điểm (4 + 8) Thay vì các module khác truy vấn trực tiếp bảng thanh toán, module thanh toán gửi các sự kiện trong bộ nhớ khi trạng thái thay đổi. Các module nhận xây dựng projection cục bộ của riêng chúng. Điều này tách hoàn toàn quyền đọc khỏi các bảng thanh toán mà không đưa vào hệ thống phân tán.
13. 13 Đóng băng tính năng hai tuần để đóng gói thanh toán gemini-3.6-flash · phá vỡ quy tắc · 11/20 điểm (5 + 6) Phá vỡ ràng buộc mềm về sản lượng tính năng hàng tuần liên tục trong đúng hai tuần. Toàn bộ nhóm tập trung vào việc tách các ghép nối DB. Nỗ lực một lần này đặt nền tảng để giảm bền vững số lượng sự cố trong 5 tháng còn lại.
14. 14 Role cơ sở dữ liệu cho mỗi module claude · trong phạm vi yêu cầu · 11/20 điểm (6 + 5) Cấp cho thanh toán schema và role Postgres riêng và thu hồi quyền ghi của các module khác vào bảng thanh toán, để các thao tác ghi trực tiếp thất bại ở staging trước khi đến production.
15. 15 Phân vùng DB vật lý sang một instance Postgres thứ hai gemini-3.6-flash · phá vỡ quy tắc · 9/20 điểm (3 + 6) Phá vỡ ràng buộc mềm của kiến trúc một cơ sở dữ liệu nhưng giữ mã monolith. Dữ liệu thanh toán chuyển sang instance cơ sở dữ liệu riêng, khiến các join SQL xuyên suốt trở nên bất khả thi về mặt kỹ thuật. Độ phức tạp vận hành vẫn tối thiểu vì mã vẫn là monolith.

Ghi chú của Kirat cho Claude: Ý tưởng phá vỡ quy tắc hay nhất chỉ ở hạng 8: "Cơ sở dữ liệu thứ hai như một công cụ an toàn" — nó cố ý phá vỡ một ràng buộc mềm. Hãy lập luận ủng hộ nó một lần trước khi loại bỏ.

Cùng Kirat động não xem làm thế nào để cắt thời gian sàng lọc cho khoảng 3.000 bản ghi mà không làm yếu đi việc rà soát.

kirat_brainstorm đã hỏi hội đồng

Hội đồng đưa ra 14 ý tưởng và chấm điểm từng ý tưởng một cách ẩn danh. Ba ý tưởng hàng đầu:

1. Cổng loại trừ hai người (18/20 điểm)
2. Sprint hiệu chuẩn với sổ cái ca biên (16/20 điểm)
3. Bảng điều khiển nhị phân nhanh, không phải trích xuất dữ liệu thu nhỏ (15/20 điểm)

Hậu trường

kirat_brainstorm Claude gửi gì cho Kirat

GHI NHẬN 2026-10-13 · KIRAT_BRAINSTORM · NỖ LỰC: TIÊU CHUẨN · 14 Ý TƯỞNG · 1 VÒNG · $0.18

Chủ đề: Các ý tưởng để cắt thời gian nhân sự cho việc sàng lọc tiêu đề và tóm tắt đối với khoảng 3.000 bản ghi mà không làm yếu đi tính chặt chẽ của một tổng quan hệ thống

Ngữ cảnh đã gửi: Tổng quan hệ thống trong nghiên cứu dịch vụ y tế, dự kiến công bố. Giao thức hiện tại: hai người sàng lọc độc lập, xung đột được giải quyết bằng thảo luận. Thời gian nhân sự eo hẹp. Người phản biện của tạp chí sẽ hỏi việc sàng lọc đã được thực hiện như thế nào. Bỏ sót một nghiên cứu liên quan (loại trừ sai) tệ hơn việc đưa vào một nghiên cứu không liên quan. RÀNG BUỘC CỨNG: phương pháp phải có thể báo cáo theo PRISMA 2020. RÀNG BUỘC CỨNG: tỷ lệ loại trừ sai không được tăng.

Kết quả từ hội đồng

1. 1 Cổng loại trừ hai người gpt-5.6 · phá vỡ quy tắc · 18/20 điểm (10 + 8) Để Người đánh giá A sàng lọc mọi bản ghi, nhưng chuyển thẳng các quyết định đưa vào và không chắc chắn của A về phía trước; Người đánh giá B đánh giá độc lập chỉ các đề xuất loại trừ của A. Chỉ loại trừ một bản ghi khi cả hai người độc lập loại trừ nó, và tự động chuyển tiếp mọi bất đồng, loại bỏ hầu hết các cuộc thảo luận xung đột. Điều này cố ý phá vỡ giả định mềm của giao thức hiện tại rằng hai người phải đánh giá mọi bản ghi; nó đáng giá vì tiết kiệm thời gian sàng lọc trong khi về mặt cấu trúc cho phép nhiều lần đưa vào sai hơn, nhưng không có thêm lần loại trừ sai nào, và dễ mô tả trong phần quy trình lựa chọn PRISMA.
2. 2 Chạy nước rút hiệu chuẩn với sổ cái các trường hợp biên gpt-5.6 · trong phạm vi yêu cầu · 16/20 điểm (9 + 7) Sàng lọc kép độc lập một lô đầu tiên được phân tầng, giải quyết xung đột, và biến các điểm mơ hồ lặp lại thành các quy tắc vận hành ngắn gọn với ví dụ tích cực và tiêu cực. Khóa các quy tắc trước khi tiếp tục; chỉ giữ lại các quyết định thí điểm nếu tiêu chí đủ điều kiện không thay đổi, nếu không thì sàng lọc lại chúng. Điều này bảo toàn việc sàng lọc kép độc lập trong khi giảm thời gian cân nhắc và giải quyết xung đột sau đó, và việc hiệu chuẩn có thể được báo cáo theo PRISMA.
3. 3 Bảng điều khiển nhị phân nhanh, không phải trích xuất dữ liệu thu nhỏ gpt-5.6 · trong phạm vi yêu cầu · 15/20 điểm (8 + 7) Cung cấp cho cả hai người đánh giá một giao diện bị che mờ, điều khiển bằng bàn phím, chỉ giới hạn ở đưa vào, loại trừ, hoặc không chắc chắn, với tiêu đề và tóm tắt đầy đủ luôn hiển thị; hoãn việc mã hóa chi tiết và lý do loại trừ sang đánh giá toàn văn. PRISMA 2020 không yêu cầu lý do ở cấp bản ghi ở giai đoạn tiêu đề và tóm tắt. Quy trình quyết định vẫn không thay đổi, nhưng thời gian đọc, nhấp chuột và ghi chép không cần thiết giảm xuống.
4. 4 Van xả máy chỉ đưa vào gpt-5.6 · lân cận · 15/20 điểm (9 + 6) Như một đột biến một bước của cổng loại trừ hai người, chạy các đề xuất loại trừ của A qua một bộ phân loại đã được xác thực chỉ có thể giải phóng bản ghi để đưa vào, không bao giờ loại trừ chúng; Người đánh giá B sàng lọc độc lập mọi thứ mà bộ phân loại không giải phóng. Việc loại trừ cuối cùng vẫn yêu cầu các quyết định nhất quán từ hai người, vì vậy một lỗi máy có thể thêm toàn văn nhưng không thể tạo ra một lần loại trừ sai. Báo cáo mô hình, phiên bản, đầu vào, ngưỡng, xác thực và vai trò chỉ đưa vào nghiêm ngặt của nó theo PRISMA.
5. 5 Sàng lọc loại trừ bất đối xứng gemini-3.6-flash · trong phạm vi yêu cầu · 15/20 điểm (7 + 8) Một người đánh giá đầu tiên phân loại hoàn toàn tất cả 3.000 bản ghi. Người đánh giá thứ hai chỉ kiểm tra những bản ghi mà người đánh giá đầu tiên đã loại trừ, để bắt các âm tính giả (các lần đưa vào được chấp nhận trực tiếp). Điều này gần như giảm một nửa nỗ lực của người đánh giá thứ hai, giữ rủi ro loại trừ sai cực thấp, và đáp ứng tất cả các yêu cầu PRISMA.
6. 6 Bỏ qua sàng lọc cho các tầng có năng suất cao gpt-5.6 · phá vỡ quy tắc · 13/20 điểm (8 + 5) Khai báo trước các tập con có năng suất cao—chẳng hạn như bản ghi từ một khối tìm kiếm có độ đặc hiệu cao, hậu duệ trực tiếp của các nghiên cứu đủ điều kiện đã biết, hoặc bản ghi đã được đưa vào một đánh giá gần khớp—và gửi tất cả chúng trực tiếp đến truy xuất toàn văn mà không có quyết định về tiêu đề và tóm tắt. Điều này cố ý phá vỡ giao thức hai người sàng lọc mềm đối với những bản ghi đó, nhưng nó không thể làm tăng các lần loại trừ sai vì không có gì trong tập con bị loại trừ; sự đánh đổi là công việc toàn văn bổ sung. Báo cáo quy tắc bỏ qua và số lượng kết quả một cách rõ ràng trong sơ đồ dòng chảy PRISMA và các phương pháp lựa chọn.
7. 7 Sàng lọc ưu tiên qua học chủ động gemini-3.6-flash · trong phạm vi yêu cầu · 13/20 điểm (5 + 8) Cả hai người sàng lọc sử dụng một công cụ học chủ động (như ASReview) sắp xếp các tiêu đề/tóm tắt liên quan lên đầu. Ngay khi đạt được tiêu chí dừng đã được xác thực thống kê (ví dụ: 500 lần trúng không liên quan liên tiếp), việc sàng lọc kết thúc. Quy trình tiết kiệm tới 70% thời gian, có thể được ghi chép theo cách tuân thủ PRISMA 2020, và duy trì tỷ lệ loại trừ sai tối thiểu thông qua hiệu chuẩn thuật toán.
8. 8 Loại trùng khớp chính xác trước khi sàng lọc gpt-5.6 · trong phạm vi yêu cầu · 12/20 điểm (8 + 4) Chỉ xóa các bản ghi được chứng minh là giống hệt thông qua DOI, số gia nhập cơ sở dữ liệu, hoặc khớp thư mục chuẩn hóa chính xác; giữ lại bản sao giàu siêu dữ liệu nhất và chỉ đánh dấu các bản gần trùng không chắc chắn. Sau đó cả hai người đánh giá sàng lọc độc lập mọi bản ghi duy nhất còn lại, trong khi PRISMA báo cáo các bản trùng đã xóa trước khi sàng lọc. Điều này cắt giảm khối lượng mà không tạo ra con đường loại trừ một nghiên cứu duy nhất.
9. 9 Thác nước người-AI với lưới an toàn AI gemini-3.6-flash · lân cận · 12/20 điểm (5 + 7) Một đột biến của sàng lọc loại trừ bất đối xứng: một người sàng lọc xử lý tất cả bản ghi một mình, trong khi một mô hình AI được điều chỉnh để có độ nhạy tối đa kiểm tra chỉ các lần loại trừ của con người. Một người thứ hai chỉ kiểm tra nơi có sự khác biệt. Điều này giảm năng lực con người hơn 50% với phạm vi bao phủ hoàn chỉnh.
10. 10 Người đánh giá thứ hai AI hoàn toàn tự động gemini-3.6-flash · phá vỡ quy tắc · 11/20 điểm (3 + 8) Phá vỡ ràng buộc mềm rằng hai con người nhất thiết phải thực hiện việc sàng lọc. Một mô hình ngôn ngữ lớn (LLM) đảm nhận vai trò người đánh giá thứ hai độc lập với lời nhắc không âm tính giả. Nó đáng giá vì thời gian làm việc của con người được giảm một nửa và LLM đã được chứng minh đạt tỷ lệ thu hồi cao trong sàng lọc tóm tắt; PRISMA 2020 cho phép rõ ràng việc báo cáo các công cụ AI.
11. 11 Sàng lọc đơn thích ứng rủi ro với phân loại theo độ tin cậy gemini-3.6-flash · phá vỡ quy tắc · 11/20 điểm (5 + 6) Phá vỡ ràng buộc mềm về sàng lọc kép liên tục cho toàn bộ tập dữ liệu. Nếu người đánh giá đầu tiên nêu độ tin cậy chủ quan cao và có lý do loại trừ rõ ràng, người đánh giá thứ hai bị bỏ qua; chỉ các trường hợp không chắc chắn chuyển sang sàng lọc kép. Điều này tiết kiệm tới 60% thời gian nhân viên, trong khi rủi ro bỏ sót nghiên cứu vẫn tối thiểu vì nguồn lực được tập trung vào các vùng xám.
12. 12 Vòng hiệu chuẩn trước claude · trong phạm vi yêu cầu · 11/20 điểm (6 + 5) Cả hai người sàng lọc sàng lọc cùng 100 bản ghi, thảo luận mọi xung đột và làm sắc nét tiêu chí đủ điều kiện trước vòng chính, để các xung đột và lần đọc lại sau đó giảm xuống.
13. 13 Sàng lọc nhanh nhị phân với phân loại AI gemini-3.6-flash · lân cận · 10/20 điểm (4 + 6) Đột biến của ưu tiên học chủ động: nhóm sử dụng một giao diện đơn giản để đánh giá nhanh (chỉ nhấp cho 'Đưa vào/Không chắc' so với 'Loại trừ'). Một mô hình AI đánh giá các điểm không chắc chắn trong nền và chỉ gửi các ứng viên sát ranh giới sang kiểm tra kép chuyên sâu. Giảm thiểu đáng kể tải nhận thức và thời gian đọc mỗi tóm tắt.
14. 14 Lọc trước tất định qua thuật toán khớp gemini-3.6-flash · trong phạm vi yêu cầu · 6/20 điểm (3 + 3) Các bộ lọc tìm kiếm thận trọng và các script sắp xếp trước các lần trúng rõ ràng không phù hợp (ví dụ: thiết kế nghiên cứu sai hoặc quần thể không phải người). Cả hai người sàng lọc chỉ kiểm tra các lần loại trừ tự động này qua một mẫu đại diện (ví dụ: 10%). Điều này giảm tổng khối lượng cần sàng lọc thủ công theo cách tuân thủ PRISMA và không mất độ nhạy.

Tất cả các ý tưởng, đầy đủ và theo thứ tự xếp hạng. Ý tưởng của chính Claude tham gia ẩn danh và bình đẳng. Chủ đề và bối cảnh được gửi bằng tiếng Anh; các ý tưởng mà các thành viên viết bằng tiếng Đức được dịch ở đây.

Năm tiêu đề và tựa đề từ các lĩnh vực khác nhau. Mỗi thành viên viết một biến thể, bản nháp của Claude tham gia, và cả hai thành viên đánh giá ẩn danh cả ba. Chọn một.

Để Kirat viết các biến thể tiêu đề cho trang định giá của tôi. Tối đa 8 từ, không có từ ngữ tuyệt đối.

kirat_create đã hỏi hội đồng

Biến thể chiến thắng (17/20 điểm): "Get paid without Word—free for 14 days"

Bản nháp của chính tôi đứng ở vị trí #2; các thành viên đánh giá ẩn danh cả ba.

Hậu trường

kirat_create Claude gửi gì cho Kirat

GHI LẠI 2026-10-13 · KIRAT_CREATE · CHẾ ĐỘ: BIẾN THỂ · NỖ LỰC: TIÊU CHUẨN · $0.03

Yêu cầu: Tiêu đề cho trang định giá của một công cụ lập hóa đơn nhỏ cho người làm tự do (19 USD mỗi tháng, dùng thử miễn phí 14 ngày). Đối tượng: người làm tự do hiện viết hóa đơn trong Word hoặc Excel. Mục tiêu: làm cho việc dùng thử cảm thấy không rủi ro và đáng giá. Định dạng: một tiêu đề, bằng tiếng Anh.

Tiêu chí: tối đa 8 từ · cụ thể, không có từ ngữ tuyệt đối · đề cập đến thời gian tiết kiệm hoặc việc được trả tiền · không có dấu chấm than

Kết quả từ hội đồng

1. 1 "Get paid without Word—free for 14 days" gpt-5.6 · 17/20 điểm (9 + 8) Nói trực tiếp với người dùng Word, đặt việc được trả tiền lên hàng đầu và làm cho việc dùng thử không rủi ro trở nên cụ thể.
2. 2 "Send invoices in minutes. Get paid on time." claude · 17/20 điểm (8 + 9) Bản nháp của chính người điều phối.
3. 3 "Replace Word and Excel. Get paid days faster." gemini-3.6-flash · 14/20 điểm (7 + 7) Việc giải quyết trực tiếp quy trình thủ công hiện tại mang lại sự tương phản tức thì, định hình việc dùng thử như một nâng cấp nhanh chóng, không rủi ro cho dòng tiền mà không dùng lời quảng cáo chung chung.

Để Kirat viết các biến thể tiêu đề cho trang đích của chúng tôi dành cho các cửa hàng nội thất trên WooCommerce. Tối đa 10 từ, không có thuật ngữ chuyên môn.

kirat_create đã hỏi hội đồng

Biến thể chiến thắng (18/20 điểm): "Losing furniture buyers to a slow, frustrating WooCommerce store?"

Bản nháp của chính tôi đứng ở vị trí #3; các thành viên đánh giá ẩn danh cả ba.

Hậu trường

kirat_create Claude gửi gì cho Kirat

GHI LẠI 2026-10-13 · KIRAT_CREATE · CHẾ ĐỘ: BIẾN THỂ · NỖ LỰC: TIÊU CHUẨN · $0.02

Yêu cầu: Tiêu đề cho trang đích của một cơ quan kỹ thuật số nhỏ về việc xây dựng lại cửa hàng cho các nhà bán lẻ nội thất chạy WooCommerce. Đối tượng: chủ các cửa hàng nội thất cỡ trung không có lập trình viên nội bộ. Mục tiêu: đặt một buổi kiểm tra cửa hàng miễn phí. Định dạng: một tiêu đề, thị trường Đức nhưng viết bằng tiếng Anh.

Tiêu chí: tối đa 10 từ · nêu tên nỗi đau của người đọc, không phải của cơ quan · không có thuật ngữ chuyên môn như "headless" hoặc "omnichannel" · không có từ ngữ tuyệt đối

Kết quả từ hội đồng

1. 1 "Losing furniture buyers to a slow, frustrating WooCommerce store?" gemini-3.6-flash · 18/20 điểm (8 + 10) Nhắm trực tiếp vào nỗi thất vọng chính của chủ cửa hàng—mất doanh số do hiệu suất cửa hàng kém—mà không dùng thuật ngữ kỹ thuật hay ngôn ngữ tự khen của cơ quan.
2. 2 "Is your WooCommerce shop turning furniture buyers away?" gpt-5.6 · 17/20 điểm (9 + 8) Nêu tên nỗi đau cốt lõi một cách trực tiếp và nói với các nhà bán lẻ nội thất mà không dùng thuật ngữ chuyên môn.
3. 3 "Fewer shop emergencies, more time for your furniture." claude · 11/20 điểm (7 + 4) Bản nháp của chính người điều phối.

Để Kirat viết các biến thể tiêu đề cho trang đặt bánh mới của tiệm bánh. Ngắn gọn, địa phương, không giống chuỗi cửa hàng.

kirat_create đã hỏi hội đồng

Biến thể chiến thắng (19/20 điểm): "Your celebration cake, baked here for pickup."

Bản nháp của chính tôi đứng ở vị trí #3; các thành viên đánh giá ẩn danh cả ba.

Hậu trường

kirat_create Claude gửi gì cho Kirat

GHI LẠI 2026-10-13 · KIRAT_CREATE · CHẾ ĐỘ: BIẾN THỂ · NỖ LỰC: TIÊU CHUẨN · $0.02

Yêu cầu: Tiêu đề cho trang đặt hàng trực tuyến mới của tiệm bánh cho bánh tùy chỉnh. Đối tượng: khách hàng địa phương những người cho đến nay đặt hàng qua điện thoại. Mục tiêu: làm cho việc đặt hàng trực tuyến cảm thấy dễ dàng và cá nhân. Định dạng: một tiêu đề, thị trường Đức nhưng viết bằng tiếng Anh.

Tiêu chí: tối đa 8 từ · cụ thể, không có từ ngữ tuyệt đối · đề cập đến việc nhận hàng hoặc dịp · nghe như một tiệm bánh địa phương, không phải chuỗi cửa hàng

Kết quả từ hội đồng

1. 1 "Your celebration cake, baked here for pickup." gpt-5.6 · 19/20 điểm (10 + 9) Ấm áp, cụ thể và cá nhân: "baked here" cảm thấy địa phương, trong khi "for pickup" làm cho quy trình trực tuyến cảm thấy đơn giản.
2. 2 "Order your custom birthday cake, pick up fresh." gemini-3.6-flash · 16/20 điểm (8 + 8) Tiêu đề nêu cụ thể dịp cũng như việc nhận hàng và, thông qua lời hứa tươi mới, truyền đạt chất lượng thủ công địa phương mà không có sáo ngữ vô cảm.
3. 3 "Your cake, your date. Order in two minutes." claude · 9/20 điểm (5 + 4) Bản nháp của chính người điều phối.

Để Kirat tìm một tiêu đề cho đề xuất của tôi về việc củng cố ranh giới của bộ phận thanh toán bên trong monolith trước.

kirat_create đã hỏi hội đồng

Bản nháp của chính tôi đã thắng (19/20 điểm): "Fix billing's boundaries first, split it later if needed"

Hậu trường kirat_create Claude gửi gì cho Kirat

GHI LẠI 2026-10-13 · KIRAT_CREATE · CHẾ ĐỘ: BIẾN THỂ · NỖ LỰC: TIÊU CHUẨN · $0.02

Yêu cầu: Tiêu đề cho một đề xuất kỹ thuật nội bộ: củng cố ranh giới của module thanh toán bên trong monolith trước khi cân nhắc tách thành dịch vụ riêng. Đối tượng: 8 kỹ sư và ban lãnh đạo muốn ít sự cố hơn. Mục tiêu: để đề xuất được đọc và phê duyệt. Định dạng: một tiêu đề, bằng tiếng Anh.

Tiêu chí: tối đa 10 từ · nêu rõ quyết định, không chỉ nêu chủ đề · không dùng từ hoa mỹ · dễ hiểu với người không phải kỹ sư

Kết quả từ hội đồng

1. 1 "Fix billing's boundaries first, split it later if needed" claude · 19/20 điểm (10 + 9) Bản nháp của chính bộ điều phối.
2. 2 "Keep Billing Together, but Isolate It to Prevent Incidents" gpt-5.6 · 16/20 điểm (9 + 7) Tiêu đề nêu rõ quyết định giữ thanh toán trong monolith đồng thời củng cố ranh giới của nó, và gắn lựa chọn đó với mục tiêu chung là ít sự cố hơn.
3. 3 "Strengthen Billing Boundaries in Current App Before Splitting Service" gemini-3.6-flash · 13/20 điểm (7 + 6) Tiêu đề đưa ra quyết định rõ ràng về hướng đi, tránh thuật ngữ không cần thiết như 'monolith' đối với ban lãnh đạo, và trực tiếp giải quyết mục tiêu chung là sự ổn định.

Hãy để Kirat tìm tiêu đề cho bài báo phương pháp của chúng tôi về LLM như một bộ sàng lọc bổ sung. Chính xác, không cường điệu.

kirat_create đã hỏi hội đồng

Biến thể thắng cuộc (18/20 điểm): "Large Language Model–Assisted Study Selection in Health Services Research: A Method for Additional Screening in Systematic Reviews"

Bản nháp của chính tôi đứng ở vị trí #2; các thành viên đã chấm cả ba ẩn danh.

Hậu trường

kirat_create Claude gửi gì cho Kirat

GHI LẠI 2026-10-13 · KIRAT_CREATE · CHẾ ĐỘ: BIẾN THỂ · NỖ LỰC: TIÊU CHUẨN · $0.02

Yêu cầu: Tiêu đề cho một bài báo phương pháp về việc dùng LLM như một bộ sàng lọc bổ sung trong một tổng quan hệ thống thuộc lĩnh vực nghiên cứu dịch vụ y tế. Đối tượng: các nhà nghiên cứu và phản biện tạp chí. Mục tiêu: chính xác và có thể trích dẫn, không cường điệu. Định dạng: một tiêu đề, có thể có phụ đề sau dấu hai chấm, bằng tiếng Anh.

Tiêu chí: tối đa 20 từ · nêu rõ phương pháp và bối cảnh · không đưa ra tuyên bố vượt quá dữ liệu · không dùng từ cường điệu như "revolutionize"

Kết quả từ hội đồng

1. 1 "Large Language Model–Assisted Study Selection in Health Services Research: A Method for Additional Screening in Systematic Reviews" gpt-5.6 · 18/20 điểm (9 + 9) Tiêu đề xác định phương pháp sàng lọc, bối cảnh tổng quan hệ thống và lĩnh vực nghiên cứu dịch vụ y tế mà không ngụ ý về hiệu suất hay lợi ích.
2. 2 "An LLM as additional screener: a prospective comparison in a health services systematic review" claude · 16/20 điểm (9 + 7) Bản nháp của chính bộ điều phối.
3. 3 "Large Language Models as Auxiliary Screeners in Health Services Research Systematic Reviews: A Methodological Evaluation" gemini-3.6-flash · 15/20 điểm (7 + 8) Tiêu đề nêu chính xác lĩnh vực ứng dụng và phương pháp luận, tránh các từ gây kích thích và chọn giọng điệu khách quan, có thể trích dẫn phù hợp với bối cảnh xuất bản khoa học.

Các tiêu đề và tít được hiển thị nguyên văn, bằng tiếng Anh, đúng như yêu cầu. Phần lý giải trong mục của Claude là nhãn do chính Kirat đặt cho nó. Phần lý giải viết bằng tiếng Đức được dịch ở đây.

Năm yêu cầu hình ảnh từ các lĩnh vực khác nhau. OpenAI và Google mỗi bên tạo một hình ảnh, và cả hai thành viên chấm cả hai hình ảnh ẩn danh. Chọn một.

Hãy để Kirat tạo ảnh hero cho trang đích của công cụ xuất hóa đơn của tôi: một bàn làm việc tại nhà yên tĩnh, không có màn hình đọc được.

kirat_image đã hỏi hội đồng

Ban giám khảo chọn hình ảnh của gpt-image-2 (18/20 điểm). Cả hai thành viên chấm cả hai hình ảnh ẩn danh.

Hậu trường

kirat_image Claude gửi gì cho Kirat

GHI LẠI 2026-10-13 · KIRAT_IMAGE · CHẾ ĐỘ: BIẾN THỂ · KHỔ NGANG · ≈ $0.17

Yêu cầu: Ảnh hero cho trang đích của một công cụ xuất hóa đơn nhỏ dành cho người làm tự do: một bàn làm việc tại nhà gọn gàng vào buổi sáng với laptop (màn hình quay đi hoặc mờ, không có giao diện đọc được), một tách cà phê và một cuốn sổ giấy. Ánh sáng tự nhiên, phong cách ảnh tài liệu yên tĩnh, không chữ, không logo, không mặt người.

Tiêu chí: tạo cảm giác như không gian làm việc thật của người làm tự do, không phải văn phòng ảnh stock · yên tĩnh và gọn gàng · để lại khoảng trống yên tĩnh cho tiêu đề · không chữ, logo hay màn hình đọc được

Kết quả từ hội đồng

1 gpt-image-2 · 18/20 điểm (9 + 9)

2 gemini-3.1-flash-image · 13/20 điểm (6 + 7)

Hãy để Kirat tạo ảnh sản phẩm cho cửa hàng nội thất: một bàn ăn bằng gỗ sồi với bốn chiếc ghế trong một phòng khách thật.

kirat_image đã hỏi hội đồng

Ban giám khảo chọn hình ảnh của gemini-3.1-flash-image (18/20 điểm). Cả hai thành viên chấm cả hai hình ảnh ẩn danh.

Hậu trường

kirat_image Claude gửi gì cho Kirat

GHI LẠI 2026-10-13 · KIRAT_IMAGE · CHẾ ĐỘ: BIẾN THỂ · KHỔ NGANG · ≈ $0.17

Yêu cầu: Ảnh sản phẩm cho một cửa hàng nội thất trực tuyến: một bàn ăn bằng gỗ sồi nguyên khối với bốn chiếc ghế trong một phòng khách sáng sủa, trông thật ở Trung Âu. Ánh sáng tự nhiên, phong cách nội thất biên tập, không chữ, không logo, không người.

Tiêu chí: chiếc bàn là chủ thể rõ ràng · vân gỗ và màu sắc chân thực · trông như một ngôi nhà thật, không phải render 3D · không chữ hay logo

Kết quả từ hội đồng

1 gemini-3.1-flash-image · 18/20 điểm (9 + 9)

2 gpt-image-2 · 17/20 điểm (8 + 9)

Hãy để Kirat tạo ảnh hero cho trang đặt bánh: một chiếc bánh sinh nhật trong hộp, sẵn sàng để nhận.

kirat_image đã hỏi hội đồng

Ban giám khảo chọn hình ảnh của gpt-image-2 (17/20 điểm). Cả hai thành viên chấm cả hai hình ảnh ẩn danh.

Hậu trường

kirat_image Claude gửi gì cho Kirat

GHI LẠI 2026-10-13 · KIRAT_IMAGE · CHẾ ĐỘ: BIẾN THỂ · KHỔ NGANG · $0.17

Yêu cầu: Ảnh hero cho trang đặt hàng trực tuyến mới của một tiệm bánh nhỏ địa phương chuyên bánh đặt riêng: một chiếc bánh sinh nhật hoàn chỉnh trên quầy gỗ trong một tiệm bánh gia đình sáng sủa, trông thật, sẵn sàng để nhận trong một hộp bánh bằng bìa cứng đơn giản. Ánh sáng tự nhiên, phong cách ảnh tài liệu, không chữ, không logo, không mặt người.

Tiêu chí: trông như một tiệm bánh địa phương thật, không phải chuỗi hay ảnh stock · chiếc bánh là chủ thể rõ ràng · để lại khoảng trống yên tĩnh cho tiêu đề · không chữ hay logo trong ảnh

Kết quả từ hội đồng

1 gpt-image-2 · 17/20 điểm (8 + 9)

2 gemini-3.1-flash-image · 7/20 điểm (4 + 3)

Hãy để Kirat tạo ảnh bìa cho bài đăng blog của chúng tôi về việc gỡ rối thanh toán khỏi monolith. Trừu tượng và yên tĩnh.

kirat_image đã hỏi hội đồng

Ban giám khảo chọn hình ảnh của gpt-image-2 (16/20 điểm). Cả hai thành viên chấm cả hai hình ảnh ẩn danh.

Hậu trường

kirat_image Claude gửi gì cho Kirat

GHI LẠI 2026-10-13 · KIRAT_IMAGE · CHẾ ĐỘ: BIẾN THỂ · KHỔ NGANG · ≈ $0.17

Yêu cầu: Ảnh bìa cho một bài đăng blog kỹ thuật nội bộ về việc gỡ rối một module thanh toán khỏi monolith: một minh họa trừu tượng, yên tĩnh về một khối có ranh giới rõ ràng được tách ra khỏi một cụm khối liên kết dày đặc. Phong cách phẳng, màu dịu, không chữ, không logo.

Tiêu chí: ý tưởng về ranh giới rõ ràng dễ nhận ra ngay từ cái nhìn đầu tiên · yên tĩnh, không kịch tính · hoạt động tốt ở kích thước nhỏ · không chữ hay logo

Kết quả từ hội đồng

1 gpt-image-2 · 16/20 điểm (9 + 7)

2 gemini-3.1-flash-image · 10/20 điểm (6 + 4)

Hãy để Kirat tạo ảnh bìa cho bài nói chuyện hội nghị của tôi về sàng lọc có AI hỗ trợ. Nghiêm túc, không robot.

kirat_image đã hỏi hội đồng

Ban giám khảo chọn hình ảnh của gpt-image-2 (18/20 điểm). Cả hai thành viên chấm cả hai hình ảnh ẩn danh.

Hậu trường

kirat_image Claude gửi gì cho Kirat

GHI LẠI 2026-10-13 · KIRAT_IMAGE · CHẾ ĐỘ: BIẾN THỂ · KHỔ NGANG · ≈ $0.17

Yêu cầu: Ảnh bìa cho một bài nói chuyện hội nghị về sàng lọc có AI hỗ trợ trong các tổng quan hệ thống: một chồng gọn gàng các bản tóm tắt nghiên cứu in ra trên bàn, một số được phân loại vào hai khay, ánh sáng ban ngày dịu, phong cách ảnh tài liệu. Không chữ đọc được, không logo, không mặt người.

Tiêu chí: nghiêm túc và khoa học, không cường điệu · không robot hay bộ não phát sáng · ý tưởng phân loại hiển thị rõ · không chữ đọc được hay logo

Kết quả từ hội đồng

1 gpt-image-2 · 18/20 điểm (9 + 9)

2 gemini-3.1-flash-image · 9/20 điểm (5 + 4)

Hình ảnh do AI tạo, được thu nhỏ và không chỉnh sửa gì khác. Chi phí có dấu ≈ đến từ các lần chạy song song: chi phí hình ảnh của riêng mỗi lần chạy cộng với phần chia đều cho các lần gọi chấm điểm. Xếp hạng chỉ là sơ tuyển, và lựa chọn cuối cùng thuộc về bạn. Các đánh giá viết bằng tiếng Đức được dịch ở đây.

02 — Vấn đề

Một mô hình, một điểm mù.

Tự đánh giá thì dễ tự khen

Một mô hình kiểm tra công việc của chính nó sẽ thấy mình thuyết phục. Lượt kiểm tra thứ hai bởi cùng mô hình đó không phải là kiểm tra độc lập.

Thêm vòng lặp không phải là giải pháp

Kirat giới hạn tranh luận ở hai vòng, trong mã, không phải trong prompt. Một mô hình không thể nói khéo để vượt giới hạn. Nếu vẫn không có đa số, bạn sẽ được báo như vậy.

Các dòng mô hình khác nhau thất bại theo cách khác nhau

Kirat đặt Claude, ChatGPT và Gemini vào cùng một câu hỏi và cho bạn thấy sự phân hóa — kể cả ai đã phản đối, và vì sao.

03 — Cách hoạt động

Hỏi một lần. Nhận ba quan điểm và một lá phiếu.

Bước 1

Bạn hỏi trong Claude

Bằng ngôn ngữ tự nhiên, như thường lệ: Ask the Kirat council: Shopify or WooCommerce for my shop? Give your own position too. Claude gọi Kirat thay bạn.

Bước 2

Ba quan điểm độc lập

ChatGPT và Gemini mỗi bên trả lời mà không thấy câu trả lời của bên kia. Claude đưa ra quan điểm riêng của mình với tư cách thành viên thứ ba.

Bước 3

Một lá phiếu, giữ lại ý kiến phản đối

Nếu hai trong ba đồng ý, đó là quan điểm đa số. Bạn thấy mọi quan điểm kèm lý do, và ai đã phản đối. Không có đa số, Kirat nói rõ, và quyết định là của bạn.

Kirat cũng đánh giá mã (mỗi phát hiện được dòng mô hình kia kiểm tra), xếp hạng ý tưởng, phê bình nội dung của bạn và so sánh hình ảnh. Phần phát lại ở trên cho thấy tất cả.

Không cần viết mã. Bạn cài một tiện ích mở rộng Claude và tạo một API key tại OpenAI và một tại Google; các bước cài đặt nằm trong phần chi tiết bên dưới.

Chín công cụ và một lần gọi mẫu được ghi lại →

04 — Giá

Một lần mua cho Claude Desktop và Claude Code.

Không đăng ký, không ghế, không tài khoản với chúng tôi. Kiểm tra nơi Kirat chạy trước khi mua:

Nơi Kirat chạy

Hoạt động trong

• Các cuộc trò chuyện Claude Desktop trên macOS và Windows
• Claude Code trong terminal, trong VS Code hoặc trong tab Code của Claude Desktop
• Các phiên Claude Code trên đám mây, sau khi thiết lập một lần cho mỗi môi trường đám mây Có giới hạn: các key lưu dưới dạng bí mật mạng vẫn không đọc được (trên gói Team và Enterprise, quản trị viên có thể phải thêm chúng), các key trong biến môi trường thì mọi người dùng môi trường đó đều đọc được, và ngân sách hằng ngày tính theo từng phiên.

Không hoạt động trong

• Trò chuyện trên trình duyệt (claude.ai) hoặc trong ứng dụng di động Claude
• Các tác vụ Cowork chạy trên đám mây
• Một số thiết lập công ty: proxy đăng nhập bằng tài khoản Windows của bạn (NTLM/Kerberos), và các tổ chức giới hạn tiện ích mở rộng Desktop theo danh sách cho phép Hãy hỏi đội IT của bạn trước.

Nơi nó chạy, đầy đủ · Mọi giới hạn đám mây

Tiện ích mở rộng Desktop + plugin Claude Code

Kirat

$99

Giá ra mắt $99 — 50 người mua đầu tiên

Sau đó $149. Mua một lần. Một tệp ZIP tải xuống với cả hai định dạng. Bạn cũng cần một API key OpenAI và một API key Gemini: những gì bạn hỏi sẽ được gửi đến cả hai nhà cung cấp, và họ tính phí bạn theo mức sử dụng.

• 01Tiện ích mở rộng Claude Desktop và plugin Claude Code, trong một lần tải xuống
• 02Script thiết lập cho các phiên Claude Code trên đám mây
• 03Cả chín công cụ: bỏ phiếu, đánh giá mã, xếp hạng ý tưởng, phê bình nội dung, so sánh hình ảnh và hơn thế
• 04Kiểm soát chi phí: ngân sách hằng ngày ($5 mặc định) giữ lại các lần gọi có thể vượt quá. Chỉ là nỗ lực tối đa, nên hãy đặt giới hạn cả ở phía nhà cung cấp
• 05Giấy phép cho một người, trên thiết bị và môi trường đám mây của riêng bạn
• 06Cập nhật tương thích khi có thể — miễn phí, nhưng không đảm bảo Chạy trong Claude Desktop (macOS/Windows) và Claude Code; các phiên đám mây của Claude Code với thiết lập một lần — không phải chat trên trình duyệt hay di động. Nơi chạy · Giới hạn đám mây

Blueprint

$49

Chỉ tài liệu — để xây dựng hoặc điều chỉnh máy chủ hội đồng của riêng bạn với một coding agent. Không cần thiết để dùng Kirat.

• 01Đặc tả: yêu cầu có cấu trúc cho các công cụ
• 02Các quyết định kiến trúc, kèm lý do đằng sau mỗi quyết định
• 03Danh sách kiểm tra nghiệm thu mà agent có thể tự đối chiếu
• 04Dữ liệu benchmark đằng sau các con số trên trang này

Không có mã, không có tiện ích cài đặt được.

Mua một lần · Thanh toán qua Lemon Squeezy (đơn vị bán hàng), VAT được xử lý khi thanh toán · Hoàn tiền: xem Điều khoản

Việc sử dụng API được trả trực tiếp cho OpenAI và Google, dưới tài khoản của bạn — $0.02–$0.15 cho mỗi quyết định của hội đồng theo đo đạc của chúng tôi.

Kirat không dành cho bạn nếu…

• —bạn chỉ dùng Claude như một chat trên trình duyệt hoặc trên điện thoại. Kirat chạy trong Claude Desktop (macOS/Windows) và Claude Code, và trong các phiên đám mây của Claude Code với thiết lập một lần — không chạy trong những chat đó.
• —bạn cần một dịch vụ được lưu trữ hoặc bất kỳ hình thức hỗ trợ nào.
• —bạn không muốn có tài khoản API và thanh toán tại hai nhà cung cấp.
• —bạn chỉ đưa ra vài quyết định mỗi tháng và thấy thoải mái khi tự so sánh câu trả lời trong các chat riêng.
• —bạn muốn một câu trả lời nghe có vẻ chắc chắn. Nhiệm vụ của hội đồng là cho bạn thấy sự chia rẽ, và đôi khi chính sự chia rẽ là câu trả lời.
• —dữ liệu của bạn không được phép đến OpenAI hoặc Google. Mọi thứ bạn đưa cho Kirat đều đến cả hai, dưới tài khoản của bạn và theo điều khoản của họ.

05 — Câu hỏi

Trước khi bạn mua.

Điều này khác gì so với llm-council hay PAL MCP?

Hãy xem cả hai trước. llm-council là một ứng dụng web mã nguồn mở; tác giả của nó mô tả nó là không được hỗ trợ theo thiết kế. PAL MCP là một máy chủ MCP mã nguồn mở miễn phí mà bạn cài đặt qua terminal; nó hỗ trợ nhiều nhà cung cấp và có công cụ đồng thuận riêng. Hãy kiểm tra trạng thái hiện tại của chúng. Nếu một trong số đó đáp ứng nhu cầu của bạn, hãy dùng nó.

Điểm khác biệt của Kirat là gói tổng thể: nó cài đặt qua hộp thoại tiện ích riêng của Claude Desktop với khóa của bạn trong kho lưu trữ bảo mật của hệ điều hành, và nó mang theo một bộ bảo vệ ngân sách với mức trần hàng ngày, giới hạn hai vòng, phân xử theo lĩnh vực, vé chạy nền, xử lý lỗi, 345 bài kiểm tra, các trường kết quả bằng tiếng Anh, và cách dùng bằng ngôn ngữ đơn giản.

Câu trả lời đầy đủ →

Tôi có cần là lập trình viên không?

Không. Nếu bạn có thể cài một tiện ích Claude và tạo hai khóa API, bạn có thể dùng Kirat. Bạn hỏi Claude bằng ngôn ngữ đơn giản — Ask the Kirat council: Postgres or SQLite? Give your own position too. — và Claude gọi các công cụ.

Tôi cần gì?

Claude Desktop trên macOS hoặc Windows. Nó đi kèm Node riêng, nên bạn không cần cài gì khác. Hoặc Claude Code với Node.js 20 trở lên. Đối với các phiên đám mây của Claude Code, cần thiết lập một lần cho môi trường đám mây của bạn (xem bên dưới).

Cộng thêm một khóa API OpenAI và một khóa API Google Gemini, cả hai đều đã bật thanh toán. Kirat cũng chạy với một khóa: khi đó hội đồng có một thành viên bên ngoài, và mọi kết quả đều nêu rõ khóa còn thiếu.

Chi phí chạy là bao nhiêu, và điều gì ngăn hóa đơn vượt kiểm soát?

Bạn trả trực tiếp cho OpenAI và Google cho những gì bạn dùng. Theo đo đạc của chúng tôi, một quyết định của hội đồng tốn $0.02–$0.15, tùy theo mức nỗ lực và kích thước đầu vào, và mất từ 8 giây đến 3 phút. Tạo hình ảnh khoảng $0.05–$0.20 mỗi lần gọi.

Bộ bảo vệ ngân sách đặt trước chi phí trong trường hợp xấu nhất trước mỗi lần gọi và chặn các lần gọi có thể vượt ngân sách hàng ngày của bạn — mặc định $5 mỗi ngày UTC, có thể điều chỉnh. Nó chỉ là nỗ lực tốt nhất, nên hãy đặt cả giới hạn chi tiêu tại các nhà cung cấp. kirat_status hiển thị ngân sách và chi tiêu, và không tốn phí.

Câu trả lời đầy đủ →

Dữ liệu và khóa của tôi đi đâu?

Dữ liệu của bạn: mọi thứ bạn đưa cho Kirat (câu hỏi, ngữ cảnh, mã, hình ảnh) đều đi trực tiếp đến OpenAI và Google, dưới tài khoản của bạn và theo điều khoản của họ — từ máy tính của bạn, hoặc trong các phiên đám mây của Claude Code từ môi trường đám mây của riêng bạn thông qua proxy mạng của Anthropic cho môi trường đó. Không có máy chủ Kirat, không có tài khoản với chúng tôi và không có telemetry. Chúng tôi không bao giờ thấy khóa hay dữ liệu của bạn.

Khóa của bạn: bạn nhập chúng trong hộp thoại cài đặt hoặc cài đặt riêng của Claude. Claude Desktop lưu chúng trong kho lưu trữ bảo mật của hệ điều hành (macOS Keychain, Windows Credential Manager). Claude Code lưu chúng trong macOS Keychain; trên Windows và Linux trong ~/.claude/.credentials.json, chỉ người dùng của bạn mới đọc được. Chúng tôi khuyên dùng một dự án nhà cung cấp riêng với giới hạn chi tiêu.

Trong các phiên đám mây của Claude Code: Kirat chạy trong môi trường đám mây của bạn. Bạn lưu khóa ở đó dưới dạng network secrets: proxy của Anthropic thêm chúng vào các yêu cầu của Kirat trên đường ra, nên không ai trong một phiên có thể đọc chúng, kể cả Claude. Trên các gói Team và Enterprise, tùy theo vai trò của bạn, quản trị viên tổ chức có thể phải thêm chúng. Như một phương án dự phòng, khóa có thể là biến môi trường của môi trường đó, đọc được bởi mọi người dùng nó.

Trên máy tính của bạn: Kirat giữ một thư mục .kirat trong thư mục home của bạn với bộ đếm chi phí hàng ngày, nhật ký chi phí, 20 kết quả gần nhất (chúng chứa câu hỏi và câu trả lời của bạn), nhật ký các quyết định được ủy thác và hình ảnh được tạo. Bạn có thể xóa nó bất cứ lúc nào. Tất cả các phiên Kirat trên máy tính đều dùng chung nó, cả Desktop và Code.

Câu trả lời đầy đủ →

Kirat hoạt động thế nào trong các phiên đám mây của Claude Code, và các giới hạn là gì?

Các phiên đám mây — phiên đám mây trong tab Code, Claude Code trên web hoặc trong ứng dụng di động — chạy trên máy chủ của Anthropic trong một môi trường đám mây. Tiện ích trên máy tính của bạn không thể tiếp cận chúng. Thay vào đó, bạn thiết lập môi trường đám mây một lần:

• dán khối từ bản tải xuống (cloud/setup-script.txt) vào đầu script thiết lập của môi trường;
• thêm hai khóa của bạn — dưới dạng network secrets cho api.openai.com và generativelanguage.googleapis.com (trên các gói Team và Enterprise, quản trị viên có thể phải thêm chúng; hướng dẫn trong bản tải xuống có chi tiết); nếu không thì dưới dạng biến môi trường, lý tưởng nhất là đặt tên KIRAT_OPENAI_API_KEY và KIRAT_GEMINI_API_KEY, để không trùng với OPENAI_API_KEY của chính dự án (Kirat cũng chấp nhận OPENAI_API_KEY và GEMINI_API_KEY);
• quyền truy cập mạng: nếu là Full, không cần thay đổi gì; nếu không, đặt thành Custom (trong các ứng dụng mới hơn: Limited) với danh sách mặc định của trình quản lý gói, cộng thêm máy chủ tải xuống Kirat (với khóa trong biến môi trường, cũng cần api.openai.com).

Script tải xuống đúng phiên bản Kirat của bạn, xác minh checksum SHA-256 của nó và cài đặt nó. Đây là thiết lập một lần, không phải một cú nhấp. Chúng tôi đã kiểm thử nó trong một container đám mây.

Các giới hạn: khóa trong biến môi trường đọc được bởi mọi người dùng môi trường (network secrets giữ chúng không đọc được). Mỗi phiên đám mây bắt đầu mới, nên ngân sách hàng ngày của Kirat được tính theo từng phiên — hãy đặt giới hạn chi tiêu tại OpenAI và Google; trên đám mây chúng là mức trần thực sự của bạn. Các tác vụ nền và kết quả gần đây kết thúc cùng phiên. Quyền truy cập mạng của môi trường phải cho phép máy chủ tải xuống Kirat, và cả api.openai.com nếu khóa của bạn là biến môi trường (Gemini đã được bao gồm trong danh sách mặc định). Nếu thiết lập thất bại, phiên vẫn khởi động, chỉ là không có Kirat — và trạng thái thất bại có thể bị lưu cache cho các phiên mới cho đến khi bạn sửa script thiết lập (bất kỳ thay đổi nào khiến các phiên mới chạy lại nó).

Địa chỉ tải xuống trong script thiết lập là một phần của giao dịch mua của bạn, giống như tệp ZIP; đừng công bố nó. Giấy phép bao gồm các môi trường đám mây của riêng bạn. Một môi trường đám mây dùng chung với người khác cần giấy phép cho mỗi người.

Câu trả lời đầy đủ →

Nó dùng những mô hình nào? Nếu nhà cung cấp ngừng một mô hình thì sao?

Mặc định là gpt-5.6 từ OpenAI và gemini-3.6-flash từ Google, với Claude là người bỏ phiếu thứ ba.

Tên mô hình và giá là các cài đặt. Nếu một nhà cung cấp ngừng một mô hình, bạn nhập tên mới và hai mức giá của nó. Không cần cập nhật.

Claude Desktop báo rằng tiện ích chưa được Anthropic xác minh. Đó có phải là vấn đề không?

Cảnh báo đó là bình thường. Claude Desktop hiển thị nó cho các tiện ích được cài từ tệp, và Kirat được cài từ tệp — nó không được Anthropic xác minh hay ký.

Cập nhật hoạt động thế nào?

Trong Claude Desktop, cài .mcpb mới theo cách giống như lần đầu. Khóa và cài đặt của bạn được giữ lại.

Các bản cập nhật tương thích là miễn phí khi có thể, nhưng không có bảo đảm. Các phiên bản mới lớn hơn có thể được bán riêng.

Tôi có được hỗ trợ không?

Không. Kirat không đi kèm hỗ trợ, trợ giúp cài đặt hay tư vấn. Thanh toán và biên lai được xử lý bởi Lemon Squeezy. Nếu Kirat không chạy trong một thiết lập được hỗ trợ, bạn được hoàn tiền; xem Điều khoản.

Giấy phép cho phép những gì?

Một người, trên bất kỳ số lượng thiết bị của riêng bạn và trong các môi trường đám mây của riêng bạn. Một môi trường đám mây dùng chung với người khác cần giấy phép cho mỗi người. Không bán lại và không phân phối lại. Kirat là phần mềm độc quyền, không phải mã nguồn mở.

Việc sử dụng những gì hội đồng tạo ra trong công việc của riêng bạn, kể cả công việc thương mại, là được phép. Điều khoản đầy đủ nằm trong Điều khoản.

Blueprint dùng để làm gì? Tôi có cần nó không?

Bạn không cần nó để dùng Kirat. Blueprint dành cho những người muốn xây dựng hoặc điều chỉnh máy chủ hội đồng của riêng họ với một coding agent.

Nó chỉ là tài liệu — không có mã, không có tiện ích cài đặt được: đặc tả (yêu cầu có cấu trúc cho các công cụ), các quyết định kiến trúc kèm lý do đằng sau mỗi quyết định, danh sách kiểm tra nghiệm thu mà agent có thể tự đối chiếu, và dữ liệu benchmark đằng sau các con số trên trang này. Không có giá gói.

06 — Chi tiết

Các chi tiết, để lưu ý.

Cài đặt, ở mọi nơi Kirat chạy và các giới hạn đám mây, chín công cụ, và bằng chứng đằng sau các con số. Mở những gì bạn cần.

Cài Kirat và kết nối các khóa API của bạn

Kirat không phải là một dịch vụ bạn đăng ký. Nó chạy trên máy tính của bạn (hoặc trong môi trường đám mây Claude Code của riêng bạn), bên trong Claude, với các khóa API của chính bạn. Không có máy chủ Kirat và không có tài khoản với chúng tôi. Mọi thứ bạn đưa cho Kirat đều đi trực tiếp đến OpenAI và Google, dưới tài khoản của bạn — từ máy tính của bạn, hoặc trong các phiên đám mây của Claude Code từ môi trường đám mây của riêng bạn thông qua proxy mạng của Anthropic cho môi trường đó. Chúng tôi không bao giờ thấy khóa hay câu hỏi của bạn.

Vừa mua Kirat? Hãy làm theo hướng dẫn thiết lập từng bước: trước tiên là bạn dùng Claude nào, sau đó chỉ các bước cho nó.

Bước 1 · phần mất thời gian

Hai khóa API

Một khóa API OpenAI và một khóa API Google Gemini, cả hai đều đã bật thanh toán. Phần mất thời gian ở đây là các biểu mẫu đăng ký và thanh toán của nhà cung cấp. Một dự án nhà cung cấp riêng với giới hạn chi tiêu là một ý hay.

Quyền tối thiểu (tùy chọn): tại OpenAI, một khóa hạn chế là đủ, với “List models” ở Read và “Model capabilities” ở Request, mọi thứ khác ở None. Một khóa Gemini từ Google AI Studio đã được hạn chế cho Gemini API; hãy hạn chế một khóa từ Google Cloud console cho Generative Language API.

Đã có cả hai khóa? Chuyển đến bước 2.

Bước 2

Cài đặt

Claude Desktop: giải nén bản tải xuống. Mở Settings → Extensions → Advanced settings → Install Extension… và chọn tệp .mcpb. Nhập cả hai khóa trong hộp thoại. Desktop đi kèm Node riêng, nên không cần cài gì khác.

Claude Code: giải nén bản tải xuống và chuyển thư mục kirat đã giải nén vào thư mục home của bạn, sao cho ~/kirat/claude-code tồn tại. Sau đó chạy các lệnh bên dưới. Cần Node.js 20 trở lên.

Các phiên đám mây của Claude Code: thiết lập một lần cho môi trường đám mây của bạn, với các giới hạn — xem bên dưới.

Bước 3

Hỏi

Kiểm tra cài đặt: Use the Kirat extension and call kirat_status. Nó cũng kiểm tra cả hai khóa API với OpenAI và Google, miễn phí.

Sau đó hỏi một câu hỏi thực sự: Ask the Kirat council: Postgres or SQLite? Give your own position too. Hoặc bắt đầu từ một mẫu: trong Claude Desktop từ nút + trong ô tin nhắn, trong Claude Code với plugin dưới dạng /kirat:decide, /kirat:review, /kirat:critique hoặc /kirat:brainstorm. Trong các phiên đám mây của Claude Code, chúng được gọi là /mcp__kirat__decide, /mcp__kirat__review, /mcp__kirat__critique và /mcp__kirat__brainstorm.

# in Claude Code, once ~/kirat/claude-code exists
/plugin marketplace add ~/kirat/claude-code
/plugin install kirat@kirat
# enter both keys when asked; to change them later:
/plugin configure kirat@kirat

Claude Desktop sẽ cảnh báo rằng tiện ích chưa được Anthropic xác minh. Cảnh báo đó là bình thường đối với mọi tiện ích được cài đặt từ tệp — xem FAQ.

Nơi nó chạy, đầy đủ, với các giới hạn đám mây Chín công cụ và một lệnh gọi ví dụ đã ghi lại

Bạn hỏi bằng ngôn ngữ thông thường. Claude thực hiện lệnh gọi:

// a real call and a real answer — nothing staged
kirat_vote({
  question: "Cap the coupled effort default, or leave it at maximum?",
  options: ["cap at high", "decouple", "leave as is"],
  ownPosition: { position: "cap at high", reasoning: "…", confidence: 72 }
})
→ outcome:       "completed"
  decision:      "cap at high"
  decisionPath:  "unanimous"
  rounds:        1
  votes:         openai 94, gemini 92,
                 claude 72
  cost:          $0.021

Các kết quả khác: needs_human (không có đa số — bạn quyết định), domain_decision, limited, budget_exhausted. Giá trị độ tin cậy là tự báo cáo của từng mô hình.

Hình 6.3 — Danh sách linh kiện

Chín công cụ Claude gọi

7 có chi phí API · 2 không có

Vị trí	Công cụ	Chức năng	Chi phí API
01	kirat_vote	Quyết định bằng bỏ phiếu: mỗi thành viên đưa ra một quan điểm, sau đó đa số hai phần ba, chủ sở hữu lĩnh vực, hoặc needs_human.	Chi phí API
02	kirat_review	Đánh giá mã. Mọi phát hiện đều được họ mô hình khác xác minh.	Chi phí API
03	kirat_create	Phê bình bản nháp của bạn, để một thành viên soạn nháp, hoặc xếp hạng các biến thể ngắn.	Chi phí API
04	kirat_brainstorm	Ý tưởng phân kỳ theo ba hướng — trong phạm vi yêu cầu, lân cận, phá luật — được xếp hạng ẩn danh.	Chi phí API
05	kirat_decide	Quyết định ủy quyền cho các lựa chọn công việc có thể đảo ngược, với quyền phủ quyết và giới hạn hàng ngày.	Chi phí API
06	kirat_ask	Hỏi đúng một thành viên. Không có hội đồng.	Chi phí API
07	kirat_image	Tạo hình ảnh bởi cả hai nhà cung cấp, được chấm điểm bởi một hội đồng ẩn danh.	Chi phí API
08	kirat_result	Lấy các tác vụ nền và kết quả gần đây.	không có
09	kirat_status	Ngân sách, chi tiêu, thành viên khả dụng, cài đặt, kiểm tra khóa miễn phí.	không có

"Chi phí API" nghĩa là công cụ gọi OpenAI và Google bằng khóa của riêng bạn, và bạn thanh toán trực tiếp cho các nhà cung cấp đó. Bản phát lại ở trên cho thấy chi phí của mỗi lần chạy. Bản thân Kirat không thu phí theo lượt dùng: bạn mua một lần. kirat_image và đầu vào hình ảnh hoạt động với tệp trên máy tính của bạn, nên chúng phù hợp nhất với Claude Code.

Bằng chứng: các quyết định đã ghi lại, chi phí đã đo lường, các lỗi đã được ghi nhận