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

Claude Opus 4.7 บันทึกรีวิวเหตุการณ์

ใช้ Claude Opus 4.7 เปลี่ยนโน้ตเหตุการณ์ให้เป็นบันทึกรีวิวที่สงบและชัดเจน พร้อมไทม์ไลน์ สาเหตุราก และเจ้าของงานติดตามผล

รีวิวเหตุการณ์บันทึกปฏิบัติการ
ตัวอย่าง

พรอมป์แชต

โมเดลแนะนำ

Claude Opus 4.7

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

บันทึกรีวิวเหตุการณ์

ตัวอย่าง

พรอมป์แชต

เธรดแชต

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

สรุป: outage ส่งผลต่อการสร้างโปรเจกต์ใหม่ในช่วงเวลาจำกัด ขณะที่เซสชันเดิมยังใช้งานได้ ผลกระทบต่อลูกค้า: ผู้ใช้ดูงานที่บันทึกไว้ได้ แต่บางส่วนเริ่มงาน generation ใหม่ไม่ได้ ปัจจัยสนับสนุน: โน้ตชี้ไปที่การไม่มีขีดจำกัด retry ที่ชัดเจน เจ้าของ alert ไม่ชัด และการตรวจ deploy ที่ไม่ครอบคลุม path ที่ได้รับผลกระทบ สิ่งที่ได้ผล: rollback ทำได้เร็วเมื่อระบุเจ้าของงานได้แล้ว รายการดำเนินการ: เพิ่ม check ที่ขาดไป กำหนดเจ้าของ alert ให้ชัด ทดสอบขีดจำกัด retry และนัดรีวิวติดตามผลพร้อมวันครบกำหนด

ผลลัพธ์

สรุป / ผลกระทบ / ไทม์ไลน์ / สิ่งที่เกิดขึ้น / ปัจจัยสนับสนุน / สิ่งที่ได้ผล / รายการดำเนินการ / เจ้าของงาน / คำถามเปิด

ตัวอย่างบทสนทนาแบบมีโครงสร้างสำหรับบันทึกรีวิวเหตุการณ์

พรอมป์เต็ม

Claude Opus 4.7 บันทึกรีวิวเหตุการณ์

Claude Opus 4.7 บันทึกรีวิวเหตุการณ์: เปลี่ยนโน้ตเหตุการณ์ให้เป็นรีวิวหลังเหตุการณ์

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

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

วางโน้ตพร้อมเวลา log ผลกระทบต่อลูกค้า และเจ้าของงานที่ทราบ แยกข้อสันนิษฐานออกจากหลักฐานที่ยืนยันแล้ว

FAQ ของพรอมป์

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

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

ควรใช้ Claude Opus 4.7 บันทึกรีวิวเหตุการณ์เมื่อใด

ใช้หลังเกิด outage การปล่อยเวอร์ชันที่ล้มเหลว หรือปัญหาด้านปฏิบัติการ เมื่อโน้ตต้องถูกเปลี่ยนให้เป็นบันทึกรีวิวที่อ่านง่าย

จะหลีกเลี่ยงการกล่าวโทษในเอาต์พุตได้อย่างไร

ให้ข้อเท็จจริง ไทม์ไลน์ และบริบทของระบบ แล้วขอให้สรุปปัจจัยสนับสนุนและการดำเนินการของเจ้าของงาน แทนการระบุความผิดของบุคคล

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

ช่วยเปลี่ยนโน้ต outage เหล่านี้ให้เป็นบันทึกรีวิวหลังเหตุการณ์ รวมผลกระทบต่อลูกค้า ไทม์ไลน์ ปัจจัยสนับสนุน และรายการดำเนินการพร้อมเจ้าของงาน
สรุป: outage ส่งผลต่อการสร้างโปรเจกต์ใหม่ในช่วงเวลาจำกัด ขณะที่เซสชันเดิมยังใช้งานได้ ผลกระทบต่อลูกค้า: ผู้ใช้ดูงานที่บันทึกไว้ได้ แต่บางส่วนเริ่มงาน generation ใหม่ไม่ได้ ปัจจัยสนับสนุน: โน้ตชี้ไปที่การไม่มีขีดจำกัด retry ที่ชัดเจน เจ้าของ alert ไม่ชัด และการตรวจ deploy ที่ไม่ครอบคลุม path ที่ได้รับผลกระทบ สิ่งที่ได้ผล: rollback ทำได้เร็วเมื่อระบุเจ้าของงานได้แล้ว รายการดำเนินการ: เพิ่ม check ที่ขาดไป กำหนดเจ้าของ alert ให้ชัด ทดสอบขีดจำกัด retry และนัดรีวิวติดตามผลพร้อมวันครบกำหนด

ผลลัพธ์

สรุป / ผลกระทบ / ไทม์ไลน์ / สิ่งที่เกิดขึ้น / ปัจจัยสนับสนุน / สิ่งที่ได้ผล / รายการดำเนินการ / เจ้าของงาน / คำถามเปิด

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

เธรดแชต

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

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

เธรดแชต

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

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

เธรดแชต

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

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