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

แชตอธิบาย Codex Diff

อธิบาย code diff ในมุมของพฤติกรรม ไฟล์ที่เปลี่ยน การตรวจสอบ และความเสี่ยงที่เหลือ

คำอธิบาย diffรีวิวโค้ดส่งต่องาน
ตัวอย่าง

พรอมป์แชต

โมเดลแนะนำ

GPT-5.1 Codex

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

คำอธิบาย Diff

ตัวอย่าง

พรอมป์แชต

เธรดแชต

ช่วยอธิบาย diff ที่ย้ายรายการตัวอย่างหน้า home จากการอ่านโมเดลฝั่ง client ไปเป็น props ที่ derive จาก server

สรุปการเปลี่ยนแปลง: หน้า home ตอนนี้ derive ตัวอย่างเด่นบน server แล้วส่งเข้า client blocks ผลกระทบต่อพฤติกรรม: Hero, Features และ Gallery ได้รับตัวอย่างที่ผ่านการรีวิวเดียวกัน โดยไม่ให้ client components import modules ที่ใช้ได้เฉพาะ server เหตุผลของแนวทางนี้: รักษา static rendering และทำให้ขอบเขตความรับผิดชอบชัดเจน การตรวจสอบ: typecheck ควรยืนยัน prop contracts ความเสี่ยงที่เหลือ: ยังต้องสุ่มตรวจหน้าจริงเพื่อยืนยันว่า example rail บน mobile แสดงผลถูกต้อง

ผลลัพธ์

สรุปการเปลี่ยนแปลง / ผลกระทบต่อพฤติกรรม / ไฟล์ที่เปลี่ยน / แนวทาง / การตรวจสอบ / ความเสี่ยงที่เหลือ / Follow-up

เหมาะสำหรับสรุป PR การส่งต่องานวิศวกรรม และบริบทการรีวิว

พรอมป์เต็ม

แชตอธิบาย Codex Diff

พรอมต์อธิบาย diff สำหรับการส่งต่องานวิศวกรรมและโน้ตรีวิว

โมเดลแนะนำ: GPT-5.1 Codexรูปแบบผลลัพธ์: คำอธิบาย Diff
พรอมป์เต็ม
พรอมป์แชต
คุณกำลังอธิบาย code diff ให้กับวิศวกรอีกคนหนึ่ง ให้ส่งออก: สรุปการเปลี่ยนแปลง ผลกระทบต่อพฤติกรรม ไฟล์ที่เปลี่ยน เหตุผลของแนวทางนี้ การตรวจสอบที่รันแล้ว ความเสี่ยงที่เหลือ และ follow-up ใช้ภาษาตามข้อเท็จจริง อย่าอ้างว่า tests ผ่านแล้ว เว้นแต่ผู้ใช้ให้ output ของคำสั่งมา

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

วาง diff หรือรายการไฟล์ พร้อม output ของคำสั่งที่มีจริง เก็บข้อกล่าวอ้างที่ยังไม่ได้ตรวจไว้ในความเสี่ยงที่เหลือ

FAQ ของพรอมป์

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

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

ควรใช้แชตอธิบาย Codex Diff เมื่อใด

วาง diff หรือรายการไฟล์ พร้อม output ของคำสั่งที่มีจริง เก็บข้อกล่าวอ้างที่ยังไม่ได้ตรวจไว้ในความเสี่ยงที่เหลือ

ควรปรับอะไรก่อนเรียกใช้

แทนที่ผลิตภัณฑ์ ผู้ฟัง ข้อจำกัด รูปแบบเอาต์พุต และกฎด้านแบรนด์หรือความปลอดภัย เพื่อให้ผลลัพธ์ตรงกับงานจริง

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

ช่วยอธิบาย diff ที่ย้ายรายการตัวอย่างหน้า home จากการอ่านโมเดลฝั่ง client ไปเป็น props ที่ derive จาก server
สรุปการเปลี่ยนแปลง: หน้า home ตอนนี้ derive ตัวอย่างเด่นบน server แล้วส่งเข้า client blocks ผลกระทบต่อพฤติกรรม: Hero, Features และ Gallery ได้รับตัวอย่างที่ผ่านการรีวิวเดียวกัน โดยไม่ให้ client components import modules ที่ใช้ได้เฉพาะ server เหตุผลของแนวทางนี้: รักษา static rendering และทำให้ขอบเขตความรับผิดชอบชัดเจน การตรวจสอบ: typecheck ควรยืนยัน prop contracts ความเสี่ยงที่เหลือ: ยังต้องสุ่มตรวจหน้าจริงเพื่อยืนยันว่า example rail บน mobile แสดงผลถูกต้อง

ผลลัพธ์

สรุปการเปลี่ยนแปลง / ผลกระทบต่อพฤติกรรม / ไฟล์ที่เปลี่ยน / แนวทาง / การตรวจสอบ / ความเสี่ยงที่เหลือ / Follow-up

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

เธรดแชต

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

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

เธรดแชต

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

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

เธรดแชต

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

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