Skip to content

สำรวจสอบสวน (Explore First)

/opsx:explore คือคู่คิดของคุณ จงเรียกใช้มันเมื่อคุณมีปัญหาแต่ยังไม่มีแผนงาน มันจะทำการตรวจสอบ codebase ของคุณ ชั่งน้ำหนักตัวเลือกต่างๆ ร่วมกับคุณ และชี้แจงว่าสิ่งที่คุณต้องการจริงๆ คืออะไร ทั้งหมดนี้ก่อนที่จะมีการสร้าง artifact หรือโค้ดบรรทัดใดๆ ขึ้นมา เมื่อภาพชัดเจนแล้ว มันจึงส่งต่อให้ /opsx:propose

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

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

เมื่อไหร่ควรสำรวจสอบสวน

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

  • คุณรู้ ปัญหา แต่ไม่รู้ วิธีแก้ ("หน้าเว็บช้า" "ระบบยืนยันตัวตนวุ่นวาย" "เราได้รับคำสั่งซื้อซ้ำๆ")
  • คุณกำลังเลือกระหว่างแนวทางต่างๆ และต้องการให้มีการวิเคราะห์ข้อแลกเปลี่ยน (tradeoffs) เทียบกับโค้ดปัจจุบันของคุณ
  • คุณเป็นมือใหม่ของ codebase นั้นและจำเป็นต้องทำความเข้าใจว่าสิ่งใดทำงานอย่างไรก่อนที่จะทำการเปลี่ยนแปลงมัน
  • ข้อกำหนดยังคลุมเครือและคุณต้องการทำให้มันชัดเจนขึ้นก่อนที่จะผูกมัด
  • คุณสงสัยว่างานนั้นใหญ่กว่าหรือเล็กกว่าที่เห็น และต้องการประเมินขอบเขตอย่างซื่อสัตย์

ให้ข้ามการสำรวจสอบสวนไปเลยก็ต่อเมื่อคุณรู้แน่ชัดแล้วว่าต้องการอะไรและอย่างไร ในกรณีนั้น ให้ตรงไปยัง /opsx:propose ทันที

มันทำอะไรได้บ้าง (และไม่ได้ทำอะไรบ้าง)

Explore คือ การสนทนา ไม่ใช่เครื่องมือสร้างโค้ด

สิ่งที่มันทำ:

  • อ่านและค้นหา codebase ของคุณเพื่อตอบคำถามที่แท้จริง
  • เปรียบเทียบตัวเลือกและระบุข้อแลกเปลี่ยนของแต่ละทาง
  • วาดแผนภาพ (diagrams) เพื่อให้การออกแบบสามารถอ่านได้ง่าย
  • ช่วยคุณจำกัดแนวคิดที่คลุมเครือให้กลายเป็นขอบเขตที่เป็นรูปธรรมและสร้างได้จริง
  • เปลี่ยนผ่านไปยัง /opsx:propose เมื่อคุณพร้อม

สิ่งที่มันไม่ได้ทำ:

  • สร้างโฟลเดอร์สำหรับเปลี่ยนแปลง (change folder)
  • เขียน artifact ใดๆ (ไม่ว่าจะเป็น proposal, specs, design หรือ tasks)
  • เขียนหรือแก้ไขโค้ด

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

มันถูกติดตั้งไว้แล้ว

ข่าวดีคือ /opsx:explore ถูกรวมอยู่ในโปรไฟล์ core เริ่มต้น เคียงคู่ไปกับ propose, apply, sync และ archive คุณไม่จำเป็นต้องเปิดใช้งานสิ่งใด หาก OpenSpec ถูกตั้งค่าไว้ในโปรเจกต์ของคุณ explore ก็พร้อมใช้งานใน AI chat ของคุณ (เช่นเดียวกับคำสั่ง /opsx:* ทั้งหมด คุณพิมพ์มันลงในแชทของผู้ช่วย ไม่ใช่ในเทอร์มินัล ดู How Commands Work)

ตัวอย่างฉบับเต็ม

ดูว่าความกังวลที่คลุมเครือสามารถกลายเป็นการเปลี่ยนแปลงที่ชัดเจนและสร้างได้จริงได้อย่างไร

text
You: /opsx:explore

AI:  What would you like to explore?

You: Our checkout sometimes creates duplicate orders. I don't know why
     and I don't know how to fix it safely.

AI:  Let me dig into the checkout path...
     [reads the order service, the payment webhook handler, and the
      client submit logic]

     Here's what I found. There are two ways a duplicate can happen:

     1. The client can submit twice (double-click, retry on slow network).
        Nothing debounces it.
     2. The payment webhook can fire more than once, and the handler
        creates an order each time. There's no idempotency key.

     Cause #2 is the dangerous one: it can charge and fulfill twice.

     Three ways to fix it, roughly in order of robustness:
     - Idempotency key on the order-creation endpoint (handles both causes)
     - Dedup on the webhook by payment-intent id (handles #2 only)
     - Client-side debounce (handles #1 only, papers over the real bug)

     Given your code already stores the payment-intent id, the
     idempotency-key approach is a small change with the biggest payoff.
     Want me to scope that?

You: Yes, let's do the idempotency key.

You: /opsx:propose add-order-idempotency-key

AI:  Created openspec/changes/add-order-idempotency-key/, with a proposal
     and delta spec grounded in what we just found. Ready for implementation.

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

การส่งต่อให้ Propose

Explore ไม่ได้เก็บเข้าสู่สิ่งใด เมื่อคุณพร้อม คุณเพียงแค่เริ่มต้นการเปลี่ยนแปลง และ AI จะนำบริบทจากการสนทนาของคุณไปใส่ใน artifact

text
explore  ──►  propose  ──►  apply  ──►  archive
 (think)     (agree)       (build)     (record)

คุณสามารถพูดด้วยภาษาธรรมดา ("มาเปลี่ยนสิ่งนี้ให้เป็นการเปลี่ยนแปลงกันเถอะ") หรือรัน /opsx:propose <name> โดยตรง ไม่ว่าจะด้วยวิธีใด การสำรวจสอบสวนที่คุณเพิ่งทำไปจะกลายเป็นรากฐานของ proposal ไม่ใช่แค่การสนทนาที่ถูกทิ้ง

หากคุณใช้ชุดคำสั่งแบบขยาย (expanded command set) explore สามารถส่งต่อให้ /opsx:new แทนได้ สำหรับการสร้าง artifact ทีละขั้นตอน ดู Workflows

เคล็ดลับสำหรับการสำรวจสอบสวนที่ดี

  • นำปัญหามา ไม่ใช่นำวิธีแก้ "ระบบล็อกอินช้า" เปิดโอกาสให้ AI ได้ทำการตรวจสอบ "เพิ่ม Redis cache" เป็นการผูกมัดคุณกับคำตอบที่คุณยังไม่ได้ทดสอบ
  • ถามถึงข้อแลกเปลี่ยนออกมาดังๆ "ข้อเสียของแต่ละตัวเลือกคืออะไร?" จะทำให้ได้การเปรียบเทียบที่ซื่อสัตย์มากขึ้น
  • ให้มันอ่านก่อน การสำรวจสอบสวนที่ดีที่สุดเริ่มต้นด้วยการที่ AI ดูโค้ดของคุณจริงๆ ไม่ใช่การเดา ชี้ไปยังพื้นที่ที่เกี่ยวข้องหากช่วยได้
  • ไม่เป็นไรที่จะล้มเลิก หากการสำรวจสอบสวนเผยว่าแนวคิดนั้นไม่คุ้มค่า นั่นถือเป็นชัยชนะ คุณเรียนรู้มันในราคาถูก
  • สำรวจซ้ำระหว่างการเปลี่ยนแปลง ติดขัดระหว่าง /opsx:apply? คุณสามารถถอยหลังและสำรวจปัญหาย่อย จากนั้นจึงกลับมา

ข้อแลกเปลี่ยนที่ซื่อสัตย์

สิ่งที่คุณได้รับ: explore จะจับจุดผิดพลาดในราคาที่ถูกที่สุด ก่อนที่จะมี artifact ใดๆ เกิดขึ้น มันทรงพลังเป็นพิเศษในโค้ดที่ไม่คุ้นเคย ซึ่งความสามารถของ AI ในการอ่านและสรุประบบจะช่วยคุณประหยัดเวลาหลายชั่วโมงในการขุดค้นหา สิ่งที่ต้องจ่าย: ความอดทนเล็กน้อย Explore คือการสนทนา ดังนั้นมันจึงช้ากว่าการยิง /opsx:propose และหวัง สิ่งนี้เป็นภาระงานที่มากเกินไปสำหรับงานที่คุณเข้าใจอยู่แล้วและควรข้ามไป

หลักการง่ายๆ คือ: ยิ่งงานคลุมเครือมากเท่าไหร่ explore ก็ยิ่งให้ผลตอบแทนมากขึ้นเท่านั้น งานที่ชัดเจนขึ้นเรื่อยๆ คุณก็สามารถข้ามไปยังการเสนอแผนงานได้เลย

จะไปต่อที่ไหน

  • Commands: /opsx:explore: ข้อมูลอ้างอิงที่แม่นยำ
  • Workflows: explore ในฐานะส่วนหนึ่งของวงจรประจำวัน
  • Examples & Recipes: explore ในการเดินผ่านแบบเต็มรูปแบบ
  • Getting Started: คู่มือสำหรับงานแรก รวมถึงการสำรวจสอบสวน