สำรวจก่อน

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

หากคุณจำคำแนะนำจากเอกสารนี้เพียงข้อเดียว ให้จำไว้ว่า เมื่อไม่แน่ใจ ให้สำรวจก่อนเสนอแผน

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

เมื่อใดควรสำรวจ

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

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

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

สิ่งที่มันทำ (และไม่ทำ)

การสำรวจคือ บทสนทนา ไม่ใช่ตัวสร้างเนื้อหา

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

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

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

• สร้างโฟลเดอร์สำหรับการเปลี่ยนแปลง (change folder)
• เขียนอาร์ติแฟกต์ใดๆ (ไม่มีการเสนอแผน, สเปค, การออกแบบ หรืองานย่อย)
• เขียนหรือแก้ไขโค้ด

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

ติดตั้งเรียบร้อยแล้ว

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

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

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

คุณ: /opsx:explore

AI:  คุณต้องการสำรวจเรื่องอะไร?

คุณ: ระบบเช็คเอาท์ของเราบางครั้งสร้างคำสั่งซื้อซ้ำ ฉันไม่รู้ว่าทำไม
     และไม่รู้ว่าต้องแก้ไขอย่างไรอย่างปลอดภัย

AI:  ให้ฉันขุดลึกลงไปในกระบวนการเช็คเอาท์...
     [อ่านบริการจัดการคำสั่งซื้อ ตัวจัดการ webhook การชำระเงิน และ
      ตรรกะการส่งข้อมูลจากไคลเอนต์]

     นี่คือสิ่งที่ฉันพบ มีสองสาเหตุที่ทำให้เกิดคำสั่งซื้อซ้ำ:

     1. ไคลเอนต์สามารถส่งข้อมูลซ้ำได้ (คลิกสองครั้ง, ลองใหม่เมื่อเครือข่ายช้า)
        ไม่มีกลไกป้องกัน (debounce)
     2. webhook การชำระเงินสามารถถูกเรียกมากกว่าหนึ่งครั้ง และตัวจัดการ
        จะสร้างคำสั่งซื้อทุกครั้ง ไม่มี key สำหรับ idempotency

     สาเหตุข้อ #2 เป็นอันตรายกว่า: อาจมีการหักเงินและดำเนินการจัดส่งซ้ำได้

     มีสามวิธีในการแก้ไข เรียงตามความแข็งแกร่งโดยประมาณ:
     - ใช้ idempotency key บน endpoint การสร้างคำสั่งซื้อ (จัดการได้ทั้งสองสาเหตุ)
     - ลบรายการซ้ำบน webhook โดยใช้ payment-intent id (จัดการได้เฉพาะข้อ #2)
     - ป้องกันการส่งซ้ำด้านไคลเอนต์ (จัดการได้เฉพาะข้อ #1 ซึ่งเป็นแค่การปิดบังบั๊กจริง)

     จากโค้ดปัจจุบันของคุณที่เก็บ payment-intent id ไว้แล้ว
     แนวทาง idempotency-key เป็นการเปลี่ยนแปลงเล็กน้อยแต่ได้ผลลัพธ์สูงสุด
     ต้องการให้ฉันกำหนดขอบเขตเรื่องนี้ไหม?

คุณ: ใช่ ให้ใช้ idempotency key

คุณ: /opsx:propose add-order-idempotency-key

AI:  สร้าง openspec/changes/add-order-idempotency-key/, พร้อมข้อเสนอแนะ
     และ delta spec ที่อิงจากสิ่งที่เราพบ刚刚 Ready for implementation.

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

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

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

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

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

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

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

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

ข้อดีข้อเสียอย่างตรงไปตรงมา

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

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

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

ไปต่อที่ไหน

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