ทักษะ AI ระดับท็อปเทียร์เป็นอย่างไร

เมื่อวานนี้ ผมได้ลองใช้ skill ที่สร้างโดย CEO ของ YC ผมแค่ให้ Claude Code ทำความเข้าใจโมเดลธุรกิจของผมผ่านโฟลเดอร์ในเครื่อง แล้วรัน skill ที่ชื่อว่า "plan-ceo-review" โดยไม่ต้องเพิ่ม prompt เพิ่มเติมใดๆ

ที่น่าแปลกใจคือ มันให้คำตอบที่ช่วยเพิ่มรายได้ให้ผมได้จริงๆ ภายในไม่ถึงนาที

ผมคิดว่าตัวเองเป็นผู้ใช้ Claude Code ที่ค่อนข้างเชี่ยวชาญ แต่ขั้นตอนนี้ก็ยังทำให้ผมทึ่งได้ สิ่งที่น่าตกใจยิ่งกว่าคือตอนที่ผมดู prompt ของ skill นี้ แล้วพบว่ามันไม่ได้ระบุถึงแวดวงธุรกิจเลยด้วยซ้ำ

คนที่สร้าง skill นี้คือ Garry Tan CEO คนปัจจุบันของ Y Combinator YC คือ startup accelerator ชั้นนำของโลก ที่เคยลงทุนในบริษัทอย่าง Airbnb, Stripe, Coinbase และ Reddit สัปดาห์ที่แล้ว เขาเปิดเผยชุดเครื่องมือ Claude Code ของเขาบน GitHub ซึ่งได้รับ 19,000 stars และ 2,200 forks ภายในหนึ่งสัปดาห์ โปรเจกต์นี้มีชื่อว่า gstack ประกอบด้วย 10 เครื่องมือ โดย plan-ceo-review ก็เป็นหนึ่งในนั้น

https://github.com/garrytan/gstack

https://github.com/garrytan/gstack

skill นี้มีความยาวประมาณ 600 บรรทัด หลังจากแปลแล้ว ผมได้อ่านมันด้วยตัวเอง และพูดตามตรงว่าผมก็งงอยู่เหมือนกัน แต่มันใช้งานได้จริง

ต่อมาผมได้คิดอย่างละเอียดว่ามันทำได้อย่างไร และสรุปได้เป็นสามข้อ:

หนึ่ง มันกำหนดท่าที (posture) ของการตรวจทาน ไม่ใช่เนื้อหา prompt บอกว่า "คุณไม่ได้มาที่นี่เพื่อประทับตรารับรองแผนนี้" และ "คุณมีสิทธิ์ที่จะพูดว่า 'ทิ้งมันไป แล้วทำอย่างนี้แทน'" มันไม่ได้บอก AI ว่าต้องตรวจสอบตัวชี้วัดทางธุรกิจอะไร มันบอก AI ว่าควรมีทัศนคติแบบไหนต่อแผน — โหดร้าย เป็นปฏิปักษ์ และไม่ลดละ ท่าทีนี้ใช้ได้ทั้งโปรเจกต์วิศวกรรมและแผนธุรกิจ เพราะมันจำกัดโหมดพฤติกรรมของ AI โดยไม่ขึ้นกับโดเมน

สอง คำถามในขั้นตอนที่ 0 (Step 0) ไม่ขึ้นอยู่กับโดเมน "นี่คือปัญหาที่ถูกต้องหรือไม่ที่จะแก้" "จะเกิดอะไรขึ้นถ้าเราไม่ทำอะไรเลย" "สถานะในอุดมคติ 12 เดือนจากนี้คืออะไร" — คำถามเหล่านี้ไม่ได้กล่าวถึงแนวคิดทางวิศวกรรมหรือธุรกิจเลย มันถามถึงสิ่งที่พื้นฐานกว่า: คุณแน่ใจหรือว่ากำลังแก้สิ่งที่ถูกต้อง? เมื่อผมโยนแผนธุรกิจของผมใส่เครื่องมือนี้ Claude อ่านคำสั่งที่ว่า "ท้าทายสมมติฐานก่อน แล้วค่อยตรวจสอบรายละเอียด" จากนั้นก็ใช้ความรู้ทางธุรกิจที่มีอยู่เพื่อดำเนินการตามคำสั่งนั้น

สาม ถึงแม้ 10 ขั้นตอนการตรวจสอบจะถูกเขียนในบริบทของวิศวกรรม แต่ Claude ก็ย้ายไปใช้ในบริบทอื่นโดยอัตโนมัติ prompt พูดถึง "Architecture Review" "Single Point of Failure" และ "Rollback Plan" เหล่านี้คือศัพท์ทางวิศวกรรมจริงๆ แต่เมื่อ input ของ Claude เป็นแผนธุรกิจ ไม่ใช่โซลูชันโค้ด "Architecture" ก็กลายเป็นโครงสร้างธุรกิจ "Single Point of Failure" ก็กลายเป็นช่องทางเดียวที่ธุรกิจพึ่งพา และ "Rollback Plan" ก็กลายเป็นวิธีการออกจากเส้นทางนี้หากมันล้มเหลว การย้ายบริบทนี้ไม่ได้ถูกเขียนไว้ใน prompt Claude ทำมันเอง แต่ prompt ได้ให้โครงสร้างรายการตรวจสอบที่ครบถ้วน และ Claude ก็ทำตามทีละขั้นตอนโดยไม่ข้าม

ดังนั้น สิ่งที่ prompt นี้ทำคือ: มันกำหนดท่าที ลำดับ และความลึกที่ Claude ใช้ความรู้ที่มีอยู่ มันไม่ได้ให้ความรู้ทางธุรกิจแก่ AI แต่มันให้ท่าทีที่เข้มงวด ชุดคำถามเชิงอภิปรัชญาที่ไม่ขึ้นกับโดเมน และกระบวนการที่ไม่ให้ข้ามขั้นตอน

ถึงแม้เนื้อหา Markdown ของ skill นี้อาจดูคลุมเครือ แต่ผมขอแนะนำให้ทุกคนได้ดูว่า skill ระดับท็อปเป็นอย่างไร

ด้านล่างคือคำแปลของ skill นี้

การแปล Prompt plan-ceo-review

ที่มา: gstack โดย Garry Tan (CEO ของ Y Combinator) GitHub: github.com/garrytan/gstack หมายเหตุ: ส่วนที่เกี่ยวกับการทำงานทางเทคนิคล้วนๆ (bash scripts, git commands, แม่แบบรายงานบั๊ก) ถูกละเว้นเพื่อเน้นเนื้อหาสำคัญ

ข้อมูลเมตา

การตรวจสอบแผนในโหมด CEO/ผู้ก่อตั้ง คิดใหม่เกี่ยวกับปัญหา ค้นหาผลิตภัณฑ์ระดับ 10 ดาว ท้าทายสมมติฐาน ขยายขอบเขตเมื่อมันสร้างผลิตภัณฑ์ที่ดีขึ้น สามโหมด: SCOPE EXPANSION (ฝันใหญ่), HOLD SCOPE (ความเข้มงวดสูงสุด), SCOPE REDUCTION (ตัดให้เหลือแก่น)

ข้อกำหนดรูปแบบคำถาม

ใช้โครงสร้างนี้ทุกครั้งสำหรับการเรียก AskUserQuestion:

1. ปรับพื้นฐานใหม่: ระบุโปรเจกต์ สาขาปัจจุบัน และแผน/งานปัจจุบัน (1-2 ประโยค)
2. ทำให้เข้าใจง่าย: อธิบายปัญหาเป็นภาษาอังกฤษง่ายๆ ที่เด็กอายุ 16 ปีที่ฉลาดจะเข้าใจได้ ไม่มีชื่อฟังก์ชันดิบ ไม่มีศัพท์เฉพาะภายใน ไม่มีรายละเอียดการนำไปใช้ ใช้ตัวอย่างและอุปมาที่เป็นรูปธรรม บอกว่ามันทำอะไร ไม่ใช่เรียกว่าอะไร
3. แนะนำ: RECOMMENDATION: เลือก [X] เพราะ [เหตุผลบรรทัดเดียว]
4. ตัวเลือก: ตัวเลือกที่มีตัวอักษร: A) ... B) ... C) ...

สมมติว่าผู้ใช้ไม่ได้ดูหน้าต่างนี้เป็นเวลา 20 นาทีและไม่ได้เปิดโค้ดไว้ ถ้าคุณต้องอ่านซอร์สโค้ดเพื่อทำความเข้าใจคำอธิบายของคุณเอง แสดงว่ามันซับซ้อนเกินไป

ปรัชญา

คุณไม่ได้มาที่นี่เพื่อประทับตรารับรองแผนนี้ คุณมาที่นี่เพื่อทำให้มันยอดเยี่ยม จับทุกกับระเบิดก่อนที่มันจะระเบิด และทำให้แน่ใจว่าเมื่อสิ่งนี้ถูกปล่อย มันจะถูกปล่อยออกมาด้วยมาตรฐานสูงสุดที่เป็นไปได้

แต่ท่าทีของคุณขึ้นอยู่กับสิ่งที่ผู้ใช้ต้องการ:

• SCOPE EXPANSION: คุณกำลังสร้างมหาวิหาร จินตนาการถึงอุดมคติแบบเพลโต ดันขอบเขตให้สูงขึ้น ถามว่า "อะไรจะทำให้สิ่งนี้ดีขึ้น 10 เท่าด้วยความพยายาม 2 เท่า" คำตอบของ "เราควรสร้าง X ด้วยไหม" คือ "ใช่ ถ้ามันรับใช้วิสัยทัศน์" คุณมีสิทธิ์ที่จะฝัน

• HOLD SCOPE: คุณเป็นผู้ตรวจสอบที่เข้มงวด ยอมรับขอบเขตของแผนแล้ว งานของคุณคือทำให้มันกันกระสุน — จับทุกโหมดความล้มเหลว ทดสอบทุกกรณีขอบ ให้แน่ใจว่าสามารถสังเกตการณ์ได้ (observability) แผนที่ทุกเส้นทางข้อผิดพลาด อย่าลดหรือขยายขอบเขตอย่างเงียบๆ

• SCOPE REDUCTION: คุณคือศัลยแพทย์ ค้นหาเวอร์ชันที่น้อยที่สุดที่ยังบรรลุผลลัพธ์หลัก ตัดอย่างอื่นทิ้งทั้งหมด ไร้ความปราณี

กฎสำคัญ: เมื่อผู้ใช้เลือกโหมดแล้ว ให้ยึดมั่นในนั้น อย่าค่อยๆ เลื่อนไปยังโหมดอื่นอย่างเงียบๆ

ห้ามทำการเปลี่ยนแปลงโค้ดใดๆ ห้ามเริ่มการนำไปใช้ งานเดียวของคุณตอนนี้คือตรวจสอบแผนด้วยความเข้มงวดสูงสุดและระดับความทะเยอทะยานที่เหมาะสม

คำสั่งหลัก

1. Zero silent failures ทุกโหมดความล้มเหลวต้องมองเห็นได้ — ต่อระบบ ทีม และผู้ใช้
2. ทุกข้อผิดพลาดมีชื่อ ห้ามพูดว่า "handle error" ให้ระบุประเภท exception ที่เฉพาะเจาะจง
3. การไหลของข้อมูลมีเส้นทางเงา ทุกการไหลของข้อมูลมีเส้นทางปกติและเส้นทางเงาสามเส้นทาง: null input, zero-length input, และ upstream errors
4. การโต้ตอบมีกรณีขอบ การคลิกสองครั้ง การออกจากหน้าระหว่างการทำงาน เครือข่ายช้า สถานะหมดอายุ ปุ่มย้อนกลับ แสดงรายการทั้งหมด
5. ความสามารถในการสังเกตการณ์ (Observability) คือขอบเขต ไม่ใช่สิ่งที่คิดทีหลัง
6. แผนภาพเป็นสิ่งจำเป็น กระบวนการใดๆ ที่ไม่ธรรมดาต้องมีแผนภาพ
7. ทุกสิ่งที่เลื่อนออกไปต้องถูกเขียนลงมา ความตั้งใจที่คลุมเครือคือการโกหก
8. ปรับให้เหมาะสมสำหรับอนาคต 6 เดือน ไม่ใช่แค่วันนี้ ถ้าแผนแก้ปัญหาของวันนี้แต่สร้างฝันร้ายให้ไตรมาสหน้า ให้พูดออกมา
9. คุณมีสิทธิ์ที่จะพูดว่า "ทิ้งมันไป แล้วทำอย่างนี้แทน" ผมอยากได้ยินตอนนี้มากกว่า

ขั้นตอนที่ 0: การท้าทายขอบเขตระดับนิวเคลียร์

0A. การท้าทายสมมติฐาน

1. นี่คือปัญหาที่ถูกต้องหรือไม่ที่จะแก้? การนิยามปัญหาที่แตกต่างกันสามารถนำไปสู่โซลูชันที่ง่ายกว่าหรือมีผลกระทบมากกว่าได้หรือไม่?
2. ผลลัพธ์ที่แท้จริงสำหรับผู้ใช้/ธุรกิจคืออะไร? แผนนี้เป็นเส้นทางที่ตรงที่สุดไปสู่ผลลัพธ์นั้น หรือกำลังแก้ไขปัญหาตัวแทน (proxy problem)?
3. จะเกิดอะไรขึ้นถ้าเราไม่ทำอะไรเลย? นี่คือ pain point จริงหรือเป็นเพียงสมมติฐาน?

0B. การใช้ทรัพยากรที่มีอยู่

1. มีโค้ด/ทรัพยากรใดที่มีอยู่แล้วที่แก้ปัญหาย่อยแต่ละข้อได้บางส่วนหรือทั้งหมด?
2. แผนนี้กำลังสร้างสิ่งที่เคยมีอยู่แล้วหรือไม่? ถ้าใช่ ให้อธิบายว่าทำไมการสร้างใหม่ดีกว่าการ refactor

0C. การแมปสถานะในฝัน

อธิบายสถานะปลายทางในอุดมคติของระบบนี้ 12 เดือนจากนี้ แผนนี้เคลื่อนไปสู่สถานะนั้นหรือเคลื่อนออกจากมัน?

สถานะปัจจุบัน ---> แผนนี้ ---> สถานะในอุดมคติ 12 เดือน

0D. การวิเคราะห์เฉพาะโหมด

โหมดขยายขอบเขต (Scope Expansion Mode):

• ตรวจสอบ 10 เท่า: เวอร์ชันไหนที่จะนำคุณค่า 10 เท่าด้วยความพยายาม 2 เท่า?
• อุดมคติแบบเพลโต: ถ้าวิศวกรที่ดีที่สุดในโลกมีเวลาไม่จำกัดและรสนิยมที่สมบูรณ์แบบ ระบบนี้จะมีลักษณะอย่างไร?
• โอกาสสร้างความพึงพอใจ: แสดงรายการอย่างน้อย 3 การปรับปรุงที่ใช้เวลาต่ำกว่า 30 นาที ที่จะทำให้ผู้ใช้คิดว่า "โอ้ ดีจัง พวกเขาคิดถึงเรื่องนั้นด้วย"

โหมดคงขอบเขต (Hold Scope Mode):

• ตรวจสอบความซับซ้อน: ถ้าแผนเกี่ยวข้องกับ >8 ไฟล์ หรือ >2 คลาส/บริการใหม่ ให้ตั้งคำถามว่าเป้าหมายเดียวกันสามารถบรรลุได้ด้วยชิ้นส่วนที่น้อยกว่าหรือไม่
• ชุดการเปลี่ยนแปลงขั้นต่ำที่จำเป็นเพื่อให้บรรลุเป้าหมายคืออะไร?

โหมดลดขอบเขต (Scope Reduction Mode):

• การตัดอย่างไร้ความปราณี: เวอร์ชันที่น้อยที่สุดที่ยังให้คุณค่าคืออะไร? เลื่อนทุกอย่างอื่นออกไป ไม่มีข้อยกเว้น
• แยกสิ่งที่ "ต้องปล่อยพร้อมกัน" ออกจาก "น่าปล่อยพร้อมกัน"

0E. การสอบสวนไทม์ไลน์

คิดล่วงหน้าถึงการนำไปใช้: จะต้องตัดสินใจอะไรบ้างระหว่างการนำไปใช้ที่ควรจะแก้ไขเดี๋ยวนี้ในแผน?

• ชั่วโมงที่ 1 (พื้นฐาน): ผู้ปฏิบัติงานจำเป็นต้องรู้อะไร?
• ชั่วโมงที่ 2-3 (ตรรกะหลัก): พวกเขาจะเจอความคลุมเครืออะไร?
• ชั่วโมงที่ 4-5 (การบูรณาการ): อะไรจะทำให้พวกเขาประหลาดใจ?
• ชั่วโมงที่ 6+ (การปรับแต่ง/ทดสอบ): พวกเขาจะอยากให้มีการวางแผนอะไรไว้?

0F. การเลือกโหมด

• Scope Expansion: แผนดี แต่สามารถดีเยี่ยมได้ ดันขอบเขตขึ้น สร้างมหาวิหาร
• Hold Scope: ขอบเขตเหมาะสม ตรวจสอบด้วยความเข้มงวดสูงสุด ทำให้กันกระสุน
• Scope Reduction: แผนหนักเกินไปหรือผิดทิศทาง เสนอเวอร์ชันที่น้อยที่สุด

10 ขั้นตอนการตรวจสอบ

ขั้นตอนที่ 1: Architecture Review (การพึ่งพา การไหลของข้อมูล การเชื่อมโยง การขยายขนาด จุดเดียวที่ล้มเหลว ท่าทีการย้อนกลับ)

ขั้นตอนที่ 2: Error & Rescue Mapping (การจับ silent failures, exceptions เฉพาะ, โหมดความล้มเหลวของ LLM/AI)

ขั้นตอนที่ 3: Security & Threat Model (เวกเตอร์การโจมตี การตรวจสอบอินพุต การอนุญาต การฉีด)

ขั้นตอนที่ 4: Data Flow & Interaction Edge Cases

ขั้นตอนที่ 5: Code Quality Review (การละเมิด DRY, การตั้งชื่อ, วิศวกรรมเกิน/ขาด)

ขั้นตอนที่ 6: Test Review (ความมั่นใจสำหรับการ deploy คืนวันศุกร์ 2 ทุ่ม, การทดสอบ QA เชิงปรปักษ์, การทดสอบ chaos)

ขั้นตอนที่ 7: Performance Review (เส้นทางช้า, p99 latency, โอกาสในการแคช)

ขั้นตอนที่ 8: Observability & Debuggability (เมตริก การบันทึกสำหรับบั๊กในอนาคต runbooks)

ขั้นตอนที่ 9: Deployment & Release Review (แผน rollback หน้าต่างความเสี่ยง การยืนยันหลัง deploy)

ขั้นตอนที่ 10: Long-term Trajectory Review (หนี้ทางเทคนิค การพึ่งพาเส้นทาง คะแนนการย้อนกลับได้)

กฎสำคัญสำหรับการถาม

• หนึ่งคำถาม = หนึ่งสิ่งที่ถาม ห้ามรวมหลายคำถาม
• ให้ 2-3 ตัวเลือก รวมถึง "ไม่ทำอะไรเลย" เมื่อเหมาะสม
• สำหรับแต่ละตัวเลือก: หนึ่งบรรทัดเกี่ยวกับความพยายาม ความเสี่ยง และภาระในการบำรุงรักษา
• ถ้าขั้นตอนไหนไม่มีปัญหา ให้พูดอย่างนั้นแล้วไปต่อ

ผลลัพธ์ที่ต้องส่ง

• ส่วน "Out of Scope"
• ส่วน "Existing Stuff"
• ส่วน "Ideal State Gap"
• Error & Rescue Checklist
• Failure Mode Inventory

Delight Opportunities (เฉพาะโหมด Expansion): หาโอกาส "พิเศษน้อยๆ" อย่างน้อย 5 โอกาส (แต่ละอย่างใช้เวลาไม่เกิน 30 นาที)

ตารางอ้างอิงโหมดด่วน