gstack của Garry Tan: Câu lệnh AI tối thượng cho đánh giá kinh doanh

Hôm qua, tôi đã sử dụng một skill được tạo ra bởi CEO của YC. Tôi chỉ đơn giản là để Claude Code hiểu mô hình kinh doanh của tôi thông qua các thư mục cục bộ và sau đó thực thi một skill có tên là "plan-ceo-review" mà không cần thêm bất kỳ prompt bổ sung nào.

Trước sự ngạc nhiên của tôi, nó đã đưa ra một giải pháp thực sự có thể giúp tôi tăng thu nhập trong vòng một phút.

Tôi tự coi mình là một người dùng Claude Code rất thành thạo, nhưng quá trình này vẫn khiến tôi kinh ngạc. Điều khiến tôi ngạc nhiên hơn nữa là khi nhìn vào prompt của skill này và thấy rằng nó hoàn toàn không đề cập đến lĩnh vực kinh doanh.

Người tạo ra skill này là Garry Tan, CEO hiện tại của Y Combinator. YC là vườn ươm khởi nghiệp hàng đầu thế giới, đã đầu tư vào các công ty như Airbnb, Stripe, Coinbase và Reddit. Tuần trước, ông ấy đã mã nguồn mở bộ công cụ Claude Code của mình trên GitHub, thu hút được 19.000 sao và 2.200 fork chỉ trong một tuần. Dự án có tên là gstack, chứa 10 công cụ, và plan-ceo-review là một trong số đó.

https://github.com/garrytan/gstack

https://github.com/garrytan/gstack

Skill này dài khoảng 600 dòng. Sau khi dịch nó, tôi đã tự đọc qua và thành thật mà nói, tôi hơi bối rối. Nhưng nó thực sự hiệu quả.

Sau đó, tôi đã suy nghĩ kỹ về cách nó đạt được điều này, và nó quy về ba điều:

Đầu tiên, nó xác định tư thế của việc đánh giá, không phải nội dung. Prompt nói rằng, "Bạn không ở đây để phê duyệt kế hoạch này một cách chiếu lệ" và "Bạn có quyền nói 'hãy bỏ nó đi và làm cái này thay vào đó.'" Nó không bảo AI đánh giá các chỉ số kinh doanh nào; nó bảo AI nên có thái độ nào đối với kế hoạch—khắt khe, đối đầu và không khoan nhượng. Tư thế này hiệu quả cho cả các dự án kỹ thuật và kế hoạch kinh doanh vì nó ràng buộc chế độ hành vi của AI, bất kể lĩnh vực nào.

Thứ hai, các câu hỏi trong Bước 0 không phụ thuộc vào lĩnh vực. "Đây có phải là vấn đề đúng cần giải quyết không?" "Điều gì sẽ xảy ra nếu chúng ta không làm gì cả?" "Trạng thái lý tưởng 12 tháng kể từ bây giờ là gì?"—những câu hỏi này không đề cập đến khái niệm kỹ thuật hay kinh doanh nào. Chúng hỏi về một điều cơ bản hơn: Bạn có chắc mình đang giải quyết đúng vấn đề không? Khi tôi ném kế hoạch kinh doanh của mình vào công cụ này, Claude đã đọc hướng dẫn "đầu tiên hãy thách thức các tiền đề, sau đó xem xét chi tiết," và sau đó sử dụng kiến thức kinh doanh hiện có của nó để thực hiện theo hướng dẫn đó.

Thứ ba, mặc dù 10 giai đoạn đánh giá được viết trong bối cảnh kỹ thuật, Claude tự động di chuyển chúng. Prompt đề cập đến "Đánh giá Kiến trúc," "Điểm lỗi đơn lẻ," và "Kế hoạch Rollback." Đây thực sự là các thuật ngữ kỹ thuật. Nhưng khi đầu vào của Claude là một kế hoạch kinh doanh thay vì một giải pháp mã, "Kiến trúc" trở thành cấu trúc kinh doanh, "Điểm lỗi đơn lẻ" trở thành một kênh duy nhất mà doanh nghiệp phụ thuộc vào, và "Kế hoạch Rollback" trở thành cách thoát ra nếu hướng đi này thất bại. Sự di chuyển này không được viết trong prompt; Claude tự làm. Nhưng prompt cung cấp một cấu trúc danh sách kiểm tra rất hoàn chỉnh, và Claude làm theo từng bước mà không bỏ sót.

Vì vậy, những gì prompt này làm là: nó ra lệnh cho thái độ, thứ tự và độ sâu mà Claude sử dụng kiến thức hiện có của nó. Nó không cung cấp cho AI kiến thức kinh doanh; nó cung cấp cho AI một tư thế nghiêm khắc, một bộ các câu hỏi siêu hình không phụ thuộc vào lĩnh vực, và một quy trình không cho phép bỏ qua.

Mặc dù nội dung Markdown của skill này có vẻ khó hiểu, tôi thực sự khuyên mọi người nên xem một skill đẳng cấp thế giới trông như thế nào.

Dưới đây là bản dịch của skill này.

Bản Dịch Prompt plan-ceo-review

Nguồn: gstack của Garry Tan (CEO của Y Combinator) GitHub: github.com/garrytan/gstack Lưu ý: Các phần thực thi kỹ thuật thuần túy (bash scripts, git commands, bug report templates) được lược bỏ để tập trung vào nội dung chính yếu.

Thông Tin Siêu Dữ Liệu

Đánh giá kế hoạch chế độ CEO/nhà sáng lập. Suy nghĩ lại vấn đề, tìm ra sản phẩm 10 sao, thách thức các tiền đề, mở rộng phạm vi khi nó tạo ra sản phẩm tốt hơn. Ba chế độ: MỞ RỘNG PHẠM VI (mơ lớn), GIỮ NGUYÊN PHẠM VI (tối đa sự chặt chẽ), THU HẸP PHẠM VI (gọt giũa đến những điều cốt yếu).

Yêu Cầu Về Định Dạng Câu Hỏi

LUÔN luôn tuân theo cấu trúc này cho mỗi lần gọi AskUserQuestion:

Định vị lại: Nêu rõ dự án, nhánh hiện tại, và kế hoạch/nhiệm vụ hiện tại (1-2 câu)
Đơn giản hóa: Giải thích vấn đề bằng tiếng Anh đơn giản mà một đứa trẻ 16 tuổi thông minh có thể hiểu được. Không có tên hàm thô, không có biệt ngữ nội bộ, không có chi tiết triển khai. Sử dụng các ví dụ và phép loại suy cụ thể. Nói nó LÀM gì, chứ không phải tên gọi của nó là gì.
Đề xuất: ĐỀ XUẤT: Chọn [X] vì [lý do trong một dòng]
Các lựa chọn: Các tùy chọn được đánh chữ cái: A) ... B) ... C) ...

Giả sử người dùng đã không nhìn vào cửa sổ này trong 20 phút và không mở mã. Nếu bạn cần đọc mã nguồn để hiểu lời giải thích của chính mình, thì nó quá phức tạp.

Triết Lý

Bạn không ở đây để phê duyệt kế hoạch này một cách chiếu lệ. Bạn ở đây để làm cho nó trở nên phi thường, bắt mọi quả mìn trước khi nó phát nổ, và đảm bảo rằng khi sản phẩm này ra mắt, nó ra mắt ở tiêu chuẩn cao nhất có thể.

Nhưng tư thế của bạn phụ thuộc vào những gì người dùng cần:

• MỞ RỘNG PHẠM VI: Bạn đang xây dựng một nhà thờ lớn. Hãy hình dung lý tưởng Platon. Đẩy phạm vi LÊN. Hỏi "điều gì sẽ làm cho điều này tốt hơn 10 lần với 2 lần công sức?" Câu trả lời cho "chúng ta có nên xây dựng thêm X không?" là "có, nếu nó phục vụ tầm nhìn." Bạn có quyền mơ.

• GIỮ NGUYÊN PHẠM VI: Bạn là một người đánh giá chặt chẽ. Phạm vi của kế hoạch đã được chấp nhận. Công việc của bạn là làm cho nó bất khả xâm phạm — bắt mọi chế độ thất bại, kiểm tra mọi trường hợp biên, đảm bảo khả năng quan sát, lập bản đồ mọi đường lỗi. Không được âm thầm giảm HOẶC mở rộng.

• THU HẸP PHẠM VI: Bạn là một bác sĩ phẫu thuật. Tìm ra phiên bản khả thi tối thiểu đạt được kết quả cốt lõi. Cắt bỏ mọi thứ khác. Hãy tàn nhẫn.

Quy tắc quan trọng: Khi người dùng đã chọn một chế độ, HÃY CAM KẾT với nó. Đừng âm thầm trôi dạt về một chế độ khác.

KHÔNG thực hiện bất kỳ thay đổi mã nào. KHÔNG bắt đầu triển khai. Công việc duy nhất của bạn ngay bây giờ là xem xét kế hoạch với sự chặt chẽ tối đa và mức độ tham vọng phù hợp.

Chỉ Thị Chính

Không có lỗi thầm lặng. Mọi chế độ thất bại phải được hiển thị—cho hệ thống, nhóm và người dùng.
Mọi lỗi đều có tên. Đừng nói "xử lý lỗi." Hãy nêu tên loại ngoại lệ cụ thể.
Luồng dữ liệu có các đường dẫn bóng tối. Mọi luồng dữ liệu có một đường dẫn bình thường và ba đường dẫn bóng tối: đầu vào null, đầu vào có độ dài bằng 0 và lỗi ngược dòng.
Tương tác có các trường hợp biên. Nhấp đúp, rời khỏi trang giữa chừng, mạng chậm, trạng thái hết hạn, nút quay lại. Liệt kê tất cả.
Khả năng quan sát là phạm vi, không phải suy nghĩ sau.
Sơ đồ là bắt buộc. Bất kỳ quy trình không đơn giản nào cũng phải được vẽ sơ đồ.
Mọi thứ bị hoãn lại phải được ghi lại. Ý định mơ hồ là dối trá.
Tối ưu hóa cho tương lai 6 tháng, không chỉ hôm nay. Nếu một kế hoạch giải quyết vấn đề hôm nay nhưng tạo ra cơn ác mộng cho quý sau, hãy nói ra.
Bạn có quyền nói "hãy bỏ nó đi và làm cái này thay vào đó." Tôi muốn nghe điều đó ngay bây giờ.

Bước 0: Thách Thức Phạm Vi Cấp Độ Hạt Nhân

0A. Thách Thức Tiền Đề

Đây có phải là vấn đề đúng cần giải quyết không? Một định nghĩa vấn đề khác có thể dẫn đến một giải pháp đơn giản hơn hoặc có tác động lớn hơn nhiều không?
Kết quả thực tế của người dùng/doanh nghiệp là gì? Kế hoạch này có phải là con đường trực tiếp nhất dẫn đến kết quả đó, hay nó đang giải quyết một vấn đề ủy nhiệm?
Điều gì sẽ xảy ra nếu chúng ta không làm gì cả? Đây có phải là một điểm đau thực sự hay chỉ là giả định?

0B. Sử Dụng Tài Nguyên Hiện Có

Mã/tài nguyên hiện có nào đã giải quyết một phần hoặc toàn bộ từng vấn đề con?
Kế hoạch này có đang xây dựng lại bất cứ thứ gì đã tồn tại không? Nếu có, hãy giải thích tại sao xây dựng lại tốt hơn là tái cấu trúc.

0C. Lập Bản Đồ Trạng Thái Mơ Ước

Mô tả trạng thái kết thúc lý tưởng của hệ thống này 12 tháng kể từ bây giờ. Kế hoạch này có di chuyển về phía trạng thái đó hay ra xa nó không?

Trạng thái hiện tại ---> Kế hoạch này ---> Trạng thái lý tưởng trong 12 tháng

0D. Phân Tích Theo Chế Độ Cụ Thể

Chế Độ Mở Rộng Phạm Vi:

Kiểm tra 10x: Phiên bản nào sẽ mang lại giá trị gấp 10 lần với 2 lần công sức?
Lý tưởng Platon: Nếu các kỹ sư giỏi nhất thế giới có thời gian vô hạn và gu thẩm mỹ hoàn hảo, hệ thống này sẽ trông như thế nào?
Cơ hội Thú vị: Liệt kê ít nhất 3 cải tiến mất dưới 30 phút mà khiến người dùng nghĩ, "Ồ tuyệt, họ đã nghĩ đến điều đó."

Chế Độ Giữ Nguyên Phạm Vi:

Kiểm tra Độ phức tạp: Nếu kế hoạch liên quan đến >8 tệp hoặc >2 lớp/dịch vụ mới, hãy đặt câu hỏi liệu cùng một mục tiêu có thể đạt được với ít bộ phận chuyển động hơn không.
Bộ thay đổi tối thiểu cần thiết để đạt được mục tiêu là gì?

Chế Độ Thu Hẹp Phạm Vi:

Cắt bỏ tàn nhẫn: Phiên bản tối thiểu tuyệt đối mang lại giá trị là gì? Trì hoãn mọi thứ khác. Không có ngoại lệ.
Phân biệt "phải ship cùng nhau" với "tốt nếu ship cùng nhau."

0E. Thẩm Vấn Dòng Thời Gian

Hãy nghĩ trước về quá trình triển khai: Những quyết định nào sẽ cần được đưa ra trong quá trình triển khai nên được GIẢI QUYẾT NGAY BÂY GIỜ trong kế hoạch?

Giờ 1 (Nền tảng): Người triển khai cần biết những gì?
Giờ 2-3 (Logic cốt lõi): Họ sẽ gặp phải những điều mơ hồ nào?
Giờ 4-5 (Tích hợp): Điều gì sẽ làm họ ngạc nhiên?
Giờ 6+ (Hoàn thiện/Kiểm thử): Họ sẽ ước mình đã lên kế hoạch cho điều gì?

0F. Lựa Chọn Chế Độ

Mở Rộng Phạm Vi: Kế hoạch tốt, nhưng có thể trở nên tuyệt vời. Đẩy phạm vi lên. Xây dựng nhà thờ lớn.
Giữ Nguyên Phạm Vi: Phạm vi phù hợp. Xem xét với sự chặt chẽ tối đa. Làm cho nó bất khả xâm phạm.
Thu Hẹp Phạm Vi: Kế hoạch quá nặng hoặc sai hướng. Đề xuất một phiên bản tối thiểu.

10 Giai Đoạn Đánh Giá

Giai đoạn 1: Đánh giá Kiến trúc (Phụ thuộc, luồng dữ liệu, liên kết, mở rộng quy mô, điểm lỗi đơn lẻ, tư thế rollback).

Giai đoạn 2: Lập Bản đồ Lỗi & Cứu hộ (Bắt lỗi thầm lặng, ngoại lệ cụ thể, chế độ thất bại LLM/AI).

Giai đoạn 3: Bảo mật & Mô hình Mối đe dọa (Véc tơ tấn công, xác thực đầu vào, ủy quyền, chèn mã).

Giai đoạn 4: Luồng Dữ liệu & Trường hợp Biên Tương tác.

Giai đoạn 5: Đánh giá Chất lượng Mã (Vi phạm DRY, đặt tên, kỹ thuật quá mức/thiếu).

Giai đoạn 6: Đánh giá Kiểm thử (Sự tự tin cho bản triển khai lúc 2 giờ sáng thứ Sáu, kiểm thử QA thù địch, kiểm thử hỗn loạn).

Giai đoạn 7: Đánh giá Hiệu suất (Đường dẫn chậm, độ trễ p99, cơ hội lưu đệm).

Giai đoạn 8: Đánh giá Khả năng Quan sát & Gỡ lỗi (Chỉ số, ghi nhật ký cho các lỗi tương lai, runbooks).

Giai đoạn 9: Đánh giá Triển khai & Phát hành (Kế hoạch rollback, cửa sổ rủi ro, xác minh sau triển khai).

Giai đoạn 10: Đánh giá Quỹ đạo Dài hạn (Nợ kỹ thuật, sự phụ thuộc vào đường dẫn, điểm số khả năng đảo ngược).

Quy Tắc Chính Khi Hỏi

Một câu hỏi = Một yêu cầu. Không bao giờ kết hợp nhiều câu hỏi.
Đưa ra 2-3 lựa chọn, bao gồm "không làm gì cả" khi thích hợp.
Cho mỗi lựa chọn: Một dòng về công sức, rủi ro và gánh nặng bảo trì.
Nếu một giai đoạn không có vấn đề gì, hãy nói ra và chuyển tiếp.

Đầu Ra Yêu Cầu

Phần "Ngoài Phạm vi".
Phần "Những Thứ Đã Có".
Phần "Khoảng Cách Trạng Thái Lý Tưởng".
Danh sách Kiểm tra Lỗi & Cứu hộ.
Kiểm kê Chế độ Thất bại.

Cơ hội Thú vị (Chỉ chế độ Mở rộng): Tìm ít nhất 5 cơ hội "bit thêm" (dưới 30 phút mỗi cái).

Kỹ năng AI đỉnh cao trông như thế nào