กลับไปที่คลังพรอมป์
คลังพรอมป์พรอมป์แชต

แชตรากสาเหตุของเทสต์ที่ล้มเหลว

เปลี่ยนล็อกเทสต์ที่ล้มเหลวและสรุป diff ล่าสุดให้เป็นสาเหตุที่เป็นไปได้ ขั้นตอนทำซ้ำ และเส้นทางแก้ไขขั้นต่ำ

การทดสอบวิศวกรรมคุณภาพ
ตัวอย่าง

พรอมป์แชต

โมเดลแนะนำ

GPT-5 Codex

รูปแบบผลลัพธ์

โน้ตรากสาเหตุของเทสต์

ตัวอย่าง

พรอมป์แชต

เธรดแชต

typecheck ผ่านในเครื่อง แต่ build ล้มเหลวเมื่อ static prompt params มี slug ใหม่ที่ไม่มีเนื้อหา locale

สาเหตุที่เป็นไปได้: มีแหล่งเทมเพลต แต่ไม่มีไฟล์ locale ที่ตรงกัน การทำซ้ำปัญหา: เพิ่ม slug แล้วรัน build จนชน prompt static params การแก้ไขขั้นต่ำ: เพิ่มไฟล์ locale en และ zh สำหรับ slug นั้น เทสต์ถดถอย: รัน prompts:check ก่อน build โน้ตห้ามแก้: อย่าแก้ route generation เว้นแต่ไฟล์ locale ถูกต้องแล้ว

ผลลัพธ์

สาเหตุที่เป็นไปได้ / การทำซ้ำปัญหา / การแก้ไขขั้นต่ำ / เทสต์ถดถอย / โน้ตห้ามแก้

เปลี่ยนล็อกเทสต์ที่ล้มเหลวและสรุป diff ล่าสุดให้เป็นสาเหตุที่เป็นไปได้ ขั้นตอนทำซ้ำ และเส้นทางแก้ไขขั้นต่ำ

พรอมป์เต็ม

แชตรากสาเหตุของเทสต์ที่ล้มเหลว

เปลี่ยนล็อกเทสต์ที่ล้มเหลวและสรุป diff ล่าสุดให้เป็นสาเหตุที่เป็นไปได้ ขั้นตอนทำซ้ำ และเส้นทางแก้ไขขั้นต่ำ

โมเดลแนะนำ: GPT-5 Codexรูปแบบผลลัพธ์: โน้ตรากสาเหตุของเทสต์
พรอมป์เต็ม
พรอมป์แชต
คุณเป็นวิศวกรที่โฟกัสการทดสอบและกำลังคัดแยกเทสต์ CI ที่ล้มเหลว เปลี่ยนโน้ตที่ให้มาให้เป็นรีวิวเชิงปฏิบัติที่ทีมสามารถนำไปทำต่อได้ ส่งคำตอบโดยมีหัวข้อ: สาเหตุที่เป็นไปได้, การทำซ้ำปัญหา, การแก้ไขขั้นต่ำ, เทสต์ถดถอย, โน้ตห้ามแก้ ยึดทุกข้อสรุปกับโน้ตที่ให้มา ระบุข้อเท็จจริงที่ขาดหายแทนการแต่งเพิ่ม

หมายเหตุการใช้งาน

วางโน้ตจริง ข้อจำกัด และแหล่งข้อมูลจริง หลีกเลี่ยงข้อมูลส่วนตัว เว้นแต่จำเป็นต่อการรีวิว

FAQ ของพรอมป์

ก่อนใช้พรอมป์นี้

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

ควรใช้แชตรากสาเหตุของเทสต์ที่ล้มเหลวเมื่อไร

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

ควรใส่อะไรก่อนรันพรอมต์นี้

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

ตัวอย่างเธรด

typecheck ผ่านในเครื่อง แต่ build ล้มเหลวเมื่อ static prompt params มี slug ใหม่ที่ไม่มีเนื้อหา locale
สาเหตุที่เป็นไปได้: มีแหล่งเทมเพลต แต่ไม่มีไฟล์ locale ที่ตรงกัน การทำซ้ำปัญหา: เพิ่ม slug แล้วรัน build จนชน prompt static params การแก้ไขขั้นต่ำ: เพิ่มไฟล์ locale en และ zh สำหรับ slug นั้น เทสต์ถดถอย: รัน prompts:check ก่อน build โน้ตห้ามแก้: อย่าแก้ route generation เว้นแต่ไฟล์ locale ถูกต้องแล้ว

ผลลัพธ์

สาเหตุที่เป็นไปได้ / การทำซ้ำปัญหา / การแก้ไขขั้นต่ำ / เทสต์ถดถอย / โน้ตห้ามแก้

พรอมป์เพิ่มเติมในโหมดนี้

เธรดแชต

เราต้องการสร้างผู้ช่วย AI สำหรับทีมอีคอมเมิร์ซขนาดเล็กที่เปลี่ยนภาพสินค้าให้เป็นแอสเซ็ตแคมเปญ

สมมติฐานปัญหา: ทีมอีคอมเมิร์ซขนาดเล็กเสียเวลาในการเปลี่ยนภาพสินค้าดิบให้เป็นแอสเซ็ตแคมเปญพร้อมใช้ในแต่ละช่องทาง สมมติฐานที่เสี่ยงที่สุด: คุณภาพภาพสูงพอ ทีมเชื่อถือการสร้างรูปแบบแอสเซ็ตด้วย AI และเวลาตรวจทานคือคอขวดจริง คำถามวิจัย: ใครเป็นเจ้าของการสร้างแอสเซ็ตแคมเปญ การแก้ไขติดขัดตรงไหน และมาตรฐานคุณภาพใดที่ขวางการเผยแพร่ แผนตรวจสอบ: สัมภาษณ์ operator 5 คน ทดสอบ flow สร้างแอสเซ็ตด้วยพรอมป์ต์ 3 แบบ และเปรียบเทียบเวลาจนได้แอสเซ็ตที่อนุมัติครั้งแรก เกตตัดสินใจ: ไปต่อเฉพาะเมื่อทีมสามารถได้ดราฟต์ที่เผยแพร่ได้เร็วกว่ากระบวนการปัจจุบัน

เธรดแชต

เรากำลังสำรวจผลิตภัณฑ์โน้ต AI ใหม่สำหรับที่ปรึกษาเดี่ยว ช่วยเปลี่ยนเรื่องนี้ให้เป็นบรีฟวิจัย

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

เธรดแชต

นี่คือโครงหน้า Landing Page สำหรับผลิตภัณฑ์ AI ของเรา ช่วยบอกหน่อยว่าอะไรยังไม่ชัดเจนก่อนที่เราจะออกแบบ

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