Until We Reach a Shared Understanding — The Foundational AI Skill

Interview me relentlessly about every aspect of this plan until we reach a shared understanding. Walk down each branch of the design tree, resolving dependencies between decisions one by one.

นี่คือ skill ทั้งหมด สามประโยค ผมอ่านจบแล้วรู้สึกเหมือนอะไรบางอย่างในอกเงียบลง

“Until we reach a shared understanding.” “จนกว่าเราจะเข้าใจตรงกัน” — เรียบง่าย โรแมนติก สะกิดใจ ของพังๆ ที่ผมเคย ship ส่วนใหญ่ไม่ใช่ bug มันคือความไม่ตรงกัน — ระหว่างสิ่งที่ผมคิดว่าสั่งไป กับสิ่งที่ถูกสร้างขึ้นจริง แล้วประโยคนี้ก็มาตั้งชื่อให้สิ่งนั้น ไม่ใช่ “เขียน spec ให้ดีขึ้น” ไม่ใช่ “clarify requirements” แต่เป็น เข้าใจตรงกัน ระหว่างสองจิตใจ ของผมกับโมเดล

ผมขโมยมาใช้ทันที

ประโยคนี้มาจากไหน

มาจากวิดีโอของ Matt Pocock ที่พูดถึง 5 Claude Code skills ที่เขาใช้ทุกวัน ตัวแรกที่เขาเปิดคือ grill-me สามประโยค ไม่มี template ไม่มี scaffolding แค่คำสั่งให้สัมภาษณ์เขาจนกว่า design tree — ไอเดียที่เขาให้เครดิต Frederick P. Brooks จากหนังสือ The Design of Design — จะถูกเดินครบทุกกิ่ง

สิ่งที่สะกิดผมคือ ประโยคนี้ไม่ได้พูดถึงการที่ AI ผลิตอะไรออกมา แต่พูดถึง สถานะที่สองฝ่ายไปถึงด้วยกัน AI ยังไม่เสร็จงานเมื่อ plan ถูกเขียน AI เสร็จงานเมื่อเราทั้งคู่เห็นภาพเดียวกัน

การ reframe แบบนี้แหละ คือทั้งหมดของบทความ

Plan mode อย่างเดียวไม่พอ

ก่อนที่ผมจะเจอ grill-me ผมอยู่ใน plan mode ของ Claude Code ตลอด prompt ของผมหน้าตาแบบนี้:

implement landing page using this design.md — start with hero, then…

Plan mode ทำสิ่งที่มันบอก — มันวางแผน มันกระโดดไป how ทันที สิ่งที่มันไม่ทำ และเป็นสิ่งที่ผมขาด คือ ย้อนถามถึง premise มันวางแผนสร้าง feature ที่ผิดได้อย่างมีความสุข นั่นคือรูปแบบของความล้มเหลว มันดูเหมือน progress

grill-me บังคับให้มี phase อื่นก่อน plan จะเริ่ม คุณไม่ได้วางแผนจนกว่าทั้งสองฝ่ายจะเห็นตรงกันว่ากำลังสร้างอะไร

loop ที่ผมใช้จริง

ผมใช้วิธีนี้มาเป็นสัปดาห์แล้ว ไม่ใช่แค่กับ PRD — ใช้กับทุกอย่างที่ cost ของการสร้างผิดสูงกว่า cost ของการคุยเพิ่มอีก 20 นาที ซึ่งปรากฏว่า เกือบทุกอย่าง

1. ผมเสนอ — เป้าหมาย feature refactor ทิศทาง แบบหยาบๆ
2. AI ซักผม — ปกติ 10–16 คำถาม บางครั้งเป็นสองรอบ มันจะตอบสิ่งที่ตอบได้จาก codebase ก่อน แล้วถามชุดหนึ่ง ย่อยคำตอบของผม แล้วกลับมาถามต่อ
3. ผมสะท้อน — ประมาณหนึ่งในสามของคำถามชนมุมที่ผมไม่ได้คิดถึง
4. ผมเสนอใหม่ — คมขึ้น พร้อมมุมใหม่ที่พับเข้ามา

ไปกลับ ดึงดัน จนกว่า design tree จะเดินครบ

session จริง (แบบย่อ)

นี่คือหน้าตา จาก session ล่าสุดในโปรเจกต์ลูกค้าส่วนตัว — เป็น chat platform ที่มีข้อความหลักแสน ผมอยากเพิ่ม message content search เพื่อให้ทีมงาน type msg:พาร์ทไทม์ แล้วหาห้องที่คุยเรื่องงาน part-time ได้จริงๆ ไม่ใช่แค่ห้องที่ผูกกับคนชื่อ “พาร์ทไทม์”

AI สำรวจ codebase ก่อน แล้วถาม 14 คำถามในชั่วโมงถัดมา ตัวอย่างที่ทำให้ผมหยุดพิมพ์:

Q1: Should message search be part of free text, or a separate qualifier? If we fold it in, every name search scans 165K search_text rows. Or we introduce msg: as an explicit qualifier.

โอเค อันนี้ผมคิดไว้แล้ว (โซน 8/12)

Q2: The matching message won’t be the latest message shown in the card. The user sees a room but has no idea which message matched or where it is in the conversation. Three options: (A) return the room, user scrolls; (B) return the room + matched message snippet; (C) A now, B later.

อันนี้ผมไม่ได้คิดถึง เลย Card UI แสดงข้อความล่าสุด ดังนั้น msg: จะโยนห้องที่มีพันข้อความให้ user โดยไม่มี cursor กิ่งของ design tree ที่ผมพลาด (โซน 4/12)

Q12: Snippet length. The matched message could be very long. Should the RPC return the full search_text and let the frontend CSS-truncate, or return a 100-char window from the DB centered on the match?

คำถาม database performance ที่ผมคงไม่ถามตัวเองจนกว่าจะขึ้น prod (โซน 4/12 เช่นกัน)

พอคำถามที่ 14 AI สรุป plan ทั้งหมดกลับมา ทุกกิ่งถูกคลี่ ทุกการตัดสินใจถูกบันทึก ตอนมันถามว่า “Anything you want to change, or should I start implementing?” ผมรู้สึกสงบจริงๆ ความรู้สึกนั้นแหละ คือ stopping criterion ที่ผมจะย้อนกลับมาพูดถึง

ความแปรปรวน

ตัวเลข 4/12 เป็นค่าเฉลี่ยคร่าวๆ มันไม่นิ่ง

• Domain ที่ผมรู้ขึ้นใจ — บางครั้งออกมาจาก session แบบ 0/12 ทุกคำถามที่ AI ถาม ผมแก้ไว้หมดแล้ว ก็ยังมีประโยชน์ เป็นการ confirm ผมลงมือได้โดยไม่ต้องลังเล
• ดินแดนที่ไม่คุ้น — บางครั้ง 8/12 ผมตอบคำถามไปครึ่งหนึ่งแล้วถึงรู้ว่าผมไม่เข้าใจสิ่งที่กำลังสร้างจริงๆ นั่นไม่ใช่ความล้มเหลวของ skill — นั่น คือ skill มันทำงานอย่างที่มันควรทำ

4/12 ไม่ใช่เป้า มันคือข้อสังเกตว่าเกือบทุกครั้ง มีอะไรบางอย่าง

มันทำงานสองทิศ

grill-me ดูผิวเผินเหมือน AI ดึง requirements ออกมาจากคุณ แต่สิ่งที่เกิดขึ้นจริงต่างออกไป คำถามมันย้อนกลับมาดันคุณ ให้คุณทบทวนจุดยืนของตัวเอง

อันนี้เห็นชัดที่สุดในงานที่ไม่ใช่ engineering ผมเพิ่งถาม AI ว่าจะเข้าตลาดอสังหาริมทรัพย์ที่สนใจยังไง ผมคาดว่าจะได้ playbook แบบร่าเริง แต่ที่ได้คือการซัก — คำถามเรื่องกรอบเวลาของ capital ความสบายใจต่อ risk ต้องการ yield หรือ appreciation จะบริหารเองหรือ delegate พอถึงคำถามที่หก ผมเปลี่ยนใจเรื่องสิ่งที่ถามไปตั้งแต่แรก

มันไม่ใช่ “AI สัมภาษณ์ผม” แต่เป็น “สองจิตใจที่หน้าไวท์บอร์ด หนึ่งในนั้นจำทุกอย่างจากอินเทอร์เน็ตได้” ไม่มีใครเป็นคนคุม เราทั้งคู่รับผิดชอบต่อความเข้าใจตรงกัน

เมื่อไม่ควรใช้

section ซื่อตรง grill-me ไม่ฟรี

• การเปลี่ยนแปลงเล็กๆ ที่ชัดเจน — แก้ typo bump dependency เพิ่ม log สักบรรทัด prompt ปกติไปเลย
• พื้นที่ที่ผมมั่นใจว่าต้องทำแบบนี้แน่นอน — ผมกระโดดเข้า plan mode ตรงๆ แล้วไปทุ่มเวลากับ implementation detail แทน
• เมื่อมันถามมากเกินไป — บางครั้ง AI เจาะลงไปใน detail เล็กๆ ที่ผมปัดทิ้งไปแล้ว 20 27 คำถาม รอบละ 12 พอถึงจุดนั้นผมตัดจบแล้วบอก “พอแล้ว เขียน plan เลย” มันฟัง

overhead ราว 15–30 นาทีต่อ feature ที่มีความหมาย เยอะอยู่ แต่ก็ยังน้อยกว่าการสร้างของผิดเป็นสัปดาห์

stopping criterion

รู้ได้ยังไงว่าเข้าใจตรงกันแล้ว

ตอบตรงๆ AI มี sense ของมัน มันหยุดตอนที่ควรหยุด เมื่อ tree ถูกเดินครบ คำถามหยุดไหล แล้วมันเสนอสรุป plan กลับมา สรุปนั้นแหละคือสัญญาณ ถ้าผมอ่านแล้วรู้สึกสงบ เราเสร็จแล้ว

ถ้าอ่านแล้วรู้สึกกังวล — เดี๋ยว แล้วเรื่อง… — นั่นคือรอบต่อไป

ทำไม AI ถึงเก่งเรื่องนี้เป็นพิเศษ

Pair programming และ rubber duck มีอยู่ ผมใช้ทั้งสองอย่างแล้ว Pair programming มันจริง แต่สำหรับผมมันเป็นทิศทางเดียว — ในฐานะ engineer ที่ senior กว่า ผมไม่ค่อยได้ push back เป็ดก็ไม่ถามอะไรเลย

AI มีสิ่งที่ทั้งสองอย่างไม่มี — มันจะถาม ครบทั้ง 12 คำถาม ไม่ใช่แค่สามอันดับแรกที่มนุษย์เหนื่อยๆ จะจัดว่าสำคัญที่สุด ไม่มี social cost ในการถามสิ่งที่ฟังดูเชย มันไม่ตัดสินผมที่ไม่ได้คิดถึงเรื่องนั้น มันอดทนไม่มีที่สิ้นสุด ความครอบคลุมนั้น — commitment ที่จะเดิน tree ให้ครบจริงๆ — คือเหตุผลที่อัตรา blind spot 4/12 คงที่ คู่หูที่เป็นมนุษย์คงหยุดที่ข้อ 3

chain ที่ตามมา

หลัง grill-me workflow ที่เหลือของ Matt ก็ทำงานต่อ — write-a-prd, prd-to-issues, tdd ผมรัน chain ครบจากต้นจนจบแล้ว สิ่งที่ผมไม่ได้คาดคือ เมื่อความเข้าใจตรงกันถูก lock ต้นน้ำ ผมปล่อย agent รัน ข้ามคืนโดยไม่ต้องเฝ้า ได้ ตื่นมาเจอ issue ที่เสร็จ

ความกล้าแบบนั้น — เดินออกจากคีย์บอร์ดขณะที่ของกำลังถูกสร้าง — ไม่ใช่เรื่อง technical มันเป็นเรื่องต้นน้ำ เป็นเรื่องความเข้าใจตรงกัน

สั้น เรียบ ไม่ผูกกับ framework

อีกเรื่องหนึ่ง ถ้าเปิด repo skill สาธารณะของ Matt ดู จะสังเกตอะไรบางอย่าง — มัน เล็กมาก grill-me สามประโยค ตัวอื่นก็ไม่ได้ยาวไปกว่านั้น ไม่ผูกกับ framework ไหน ไม่มี pattern เฉพาะภาษา

นั่นคือ virtue ของมัน skill พวกนี้เข้ารหัส process ไม่ใช่ tech ใช้ได้ใน SvelteKit repo Go service Rails app notebook เอกสาร PRD หรือการตัดสินใจซื้ออสังหา process คือสิ่งที่ AI agent พลาดเสมอ — ไม่มี memory ไม่มีรสนิยม ไม่มี intuition ว่าเมื่อไหร่ควรหยุด การเข้ารหัสมันชัดๆ คือสิ่งที่ทำให้มันใช้ได้

Skill ไม่ต้องยาวถึงจะทรงพลัง อย่างที่ Matt พูดในวิดีโอ — เลือกคำที่ถูกต้องสำหรับ LLM ในเวลาที่ถูกต้อง ความสั้น คือ feature

และมัน portable ข้าม tool Vercel’s skills CLI ใช้ได้กับทุกอย่าง:

npx skills@latest add mattpocock/skills/grill-me

เท่านี้ หนึ่งบรรทัด คุณมี skill พื้นฐานใน setup ที่ใช้ agent อะไรก็ได้

ประโยคนั้น อีกครั้งหนึ่ง

until we reach a shared understanding

จนกว่าเราจะเข้าใจตรงกัน

ใส่ไว้ใน skill ใส่ไว้ใน system prompt ใส่ไว้หัว template PRD ใส่ไว้บน sticky note

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

ขอบคุณครับ Matt ผมจะใช้ประโยคนี้ไปอีกนาน