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

แชตกำหนดขอบเขต Refactor ด้วย Codex

กำหนดขอบเขต refactor โดยแยกการเปลี่ยนแปลงที่จำเป็น การ cleanup ที่เป็นทางเลือก ขอบเขตความรับผิดชอบ และ non-goals

ขอบเขต refactorสถาปัตยกรรมขอบเขต
ตัวอย่าง

พรอมป์แชต

โมเดลแนะนำ

GPT-5.3 Codex

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

ขอบเขต refactor

ตัวอย่าง

พรอมป์แชต

เธรดแชต

ช่วยกำหนดขอบเขต refactor เพื่อให้ model example derive จาก Prompt templates โดยยังคง model config ไว้

เป้าหมาย: ให้ launch examples วิ่งผ่าน prompt templates ที่ผ่านการรีวิวแล้ว การเปลี่ยนแปลงที่จำเป็น: เพิ่ม example aggregation, อัปเดต pages, อัปเดต audits และ docs นอก scope: การเปลี่ยน provider config, billing params, runtime forms หรือ prompt database storage Compatibility: เก็บ path เดิมไว้เฉพาะจนกว่า reviewed coverage จะครบ Acceptance: พื้นผิว launch example ทั้งหมด prefer reviewed prompt examples และ typecheck ผ่าน

ผลลัพธ์

เป้าหมาย / การเปลี่ยนแปลงที่จำเป็น / Optional cleanup / In scope / Out of scope / Boundaries / Acceptance

เหมาะสำหรับการ cleanup สถาปัตยกรรม การกำหนด boundary และการหลีกเลี่ยง churn ที่ไม่เกี่ยวข้อง

พรอมป์เต็ม

แชตกำหนดขอบเขต Refactor ด้วย Codex

พรอมต์กำหนดขอบเขต refactor สำหรับขอบเขตสถาปัตยกรรมและ non-goals

โมเดลแนะนำ: GPT-5.3 Codexรูปแบบผลลัพธ์: ขอบเขต refactor
พรอมป์เต็ม
พรอมป์แชต
คุณกำลังกำหนดขอบเขต refactor ให้ส่งออก: เป้าหมาย การเปลี่ยนแปลงที่จำเป็น การ cleanup ที่เป็นทางเลือก ไฟล์ที่อยู่ใน scope ไฟล์ที่อยู่นอก scope ขอบเขตความรับผิดชอบ compatibility notes และ acceptance checks เลือกการเปลี่ยนแปลงที่เล็กที่สุดซึ่งแก้ปัญหาจริงได้ก่อน ระบุอย่างชัดเจนว่าอะไรไม่ควรถูกแตะ

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

วางปัญหา ข้อจำกัด และไฟล์ที่แตะไปแล้ว ขอให้โมเดลปกป้องงานที่ไม่เกี่ยวข้องอย่างชัดเจน

FAQ ของพรอมป์

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

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

ควรใช้แชตกำหนดขอบเขต Refactor ด้วย Codex เมื่อใด

วางปัญหา ข้อจำกัด และไฟล์ที่แตะไปแล้ว ขอให้โมเดลปกป้องงานที่ไม่เกี่ยวข้องอย่างชัดเจน

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

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

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

ช่วยกำหนดขอบเขต refactor เพื่อให้ model example derive จาก Prompt templates โดยยังคง model config ไว้
เป้าหมาย: ให้ launch examples วิ่งผ่าน prompt templates ที่ผ่านการรีวิวแล้ว การเปลี่ยนแปลงที่จำเป็น: เพิ่ม example aggregation, อัปเดต pages, อัปเดต audits และ docs นอก scope: การเปลี่ยน provider config, billing params, runtime forms หรือ prompt database storage Compatibility: เก็บ path เดิมไว้เฉพาะจนกว่า reviewed coverage จะครบ Acceptance: พื้นผิว launch example ทั้งหมด prefer reviewed prompt examples และ typecheck ผ่าน

ผลลัพธ์

เป้าหมาย / การเปลี่ยนแปลงที่จำเป็น / Optional cleanup / In scope / Out of scope / Boundaries / Acceptance

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

เธรดแชต

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

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

เธรดแชต

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

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

เธรดแชต

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

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