คู่มือพรอมต์
วิธีเขียนข้อเสนอโครงการด้วย Claude
ข้อเสนอที่ได้รับอนุมัตินั้นเจาะจง ข้อเสนอที่ถูกเมินนั้นคลุมเครือ
Claude จาก Anthropic เก่งในการเปลี่ยนไอเดียโครงการหยาบ ๆ ให้เป็นข้อเสนอที่มีโครงสร้าง มีการระบุปัญหา ขอบเขต กำหนดเวลา และรายละเอียดเจาะจงประเภทที่ทำให้ผู้มีส่วนได้ส่วนเสียพูด "ตกลง" จริง ๆ สิ่งที่ Claude ไม่รู้คือ งบประมาณของคุณ ขีดความสามารถจริงของทีมคุณ หรือการเมืองภายในองค์กรของคุณ นอกจากคุณจะบอกมัน นี่คือเหตุผลที่ "เขียนข้อเสนอโครงการให้ฉันสำหรับ X" มักได้คำตอบที่ทั่วไปพอจะเข้ากับบริษัทไหนก็ได้ ทางออกคือให้ข้อจำกัดที่แท้จริงแก่ Claude: ข้อเสนอนี้เพื่อใคร คุณมีอะไรให้ทำงานจริง ๆ และคุณต้องการให้คนนั้นตัดสินใจอะไร
การขอให้ Claude เขียนข้อเสนอโครงการ ให้ระบุปัญหาที่คุณกำลังแก้ไข ข้อเสนอนี้เพื่อใครและคุณต้องการการตัดสินใจอะไรจากพวกเขา ข้อจำกัดจริงของคุณ (ขนาดทีม กำหนดเวลาโดยประมาณ ช่วงงบประมาณ) และคำสั่งให้จัดโครงสร้างร่างเป็นการระบุปัญหา วิธีการที่เสนอ ขอบเขต กำหนดเวลา และตัวชี้วัดความสำเร็จ วางเอกสารพื้นฐาน ข้อเสนอก่อนหน้า หรือบันทึกที่คุณมีอยู่แล้ว และให้ Claude ทำเครื่องหมายสิ่งที่คลุมเครือเกินกว่าจะกลายเป็นแผนที่เป็นรูปธรรม
เผยแพร่เมื่อ
บทเรียนฟรี · ไม่ต้องมีบัญชีรู้จักกับ Claudeทำไมต้อง Claude?6 นาทีเริ่มบทเรียนฟรีสรุปประเด็นสำคัญ
- บอกว่าข้อเสนอนี้เพื่อใครและคุณต้องการให้พวกเขาตัดสินใจอะไร ข้อเสนอให้ทีมของคุณวางแผนอ่านต่างจากข้อเสนอที่ขอให้ผู้บริหารอนุมัติงบประมาณ
- ให้ข้อจำกัดจริงของคุณแก่ Claude: ขนาดทีม กำหนดเวลาโดยประมาณ ช่วงงบประมาณ แผนที่สร้างจากข้อจำกัดที่แต่งขึ้นต้องเขียนใหม่ทันทีที่มีคนรู้ตัวเลขจริงมาอ่าน
- ขอตัวชี้วัดความสำเร็จอย่างเจาะจง ไม่ใช่แค่คำอธิบายงาน ข้อเสนอที่ไม่บอกว่าจะรู้ได้อย่างไรว่าสำเร็จนั้นยากที่จะอนุมัติและยากที่จะตรวจสอบในอนาคต
- วางเอกสารพื้นฐานที่คุณมีอยู่แล้ว: ข้อเสนอก่อนหน้า บันทึกการประชุม โครงร่างหยาบ ๆ Claude จัดระเบียบและขัดเกลาสิ่งที่คุณให้ มันแต่งบริบทเบื้องหลังโครงการเฉพาะของคุณไม่ได้
- อ่านส่วนขอบเขตอย่างระมัดระวังเป็นพิเศษก่อนส่ง ขอบเขตที่คลุมเครือหรือกว้างกว่าที่คุณตั้งใจจริงเป็นเหตุผลที่พบบ่อยที่สุดที่ข้อเสนอก่อปัญหาในภายหลัง
คัดลอกไปใช้ได้เลย
พรอมต์ที่ใช้ได้ทันทีวันนี้
ร่างแรกที่สมบูรณ์จากไอเดียหยาบ ๆ
ฉันต้องการเสนอ [อธิบายไอเดียโครงการของคุณในหนึ่งหรือสองประโยค] นี่คือสำหรับ [ข้อเสนอนี้เพื่อใครและคุณต้องการการตัดสินใจอะไรจากพวกเขา] นี่คือสิ่งที่ฉันมีจริง ๆ ให้ทำงาน: ทีม [ขนาด] กำหนดเวลาประมาณ [ช่วงเวลา] งบประมาณประมาณ [ช่วง หรือ 'ยังไม่กำหนด'] เขียนร่างข้อเสนอพร้อมการระบุปัญหา วิธีการที่เสนอ ขอบเขต (รวมถึงสิ่งที่อยู่นอกขอบเขตอย่างชัดเจน) กำหนดเวลาโดยประมาณ และตัวชี้วัดความสำเร็จ ทำเครื่องหมายสิ่งที่คุณต้องเดาเพราะฉันไม่ได้ให้รายละเอียดเพียงพอ
ความซื่อตรงเกี่ยวกับสิ่งที่คุณยังไม่รู้ เช่นงบประมาณ ให้ร่างที่มีประโยชน์มากกว่าการแต่งตัวเลขขึ้นมาเพื่อเติมช่องว่าง
เปลี่ยนความคิดที่ยังไม่เป็นระบบให้เป็นการระบุปัญหา
นี่คือบันทึกหยาบ ๆ ที่ยังไม่เป็นระบบของฉันเกี่ยวกับปัญหาที่ฉันต้องการแก้ไข: [วางบันทึกของคุณ] เปลี่ยนสิ่งนี้เป็นการระบุปัญหาที่กระชับ สองถึงสามประโยค ที่อธิบายว่าทำไมมันสำคัญและใครได้รับผลกระทบ โดยยังไม่อธิบายวิธีแก้ปัญหา ฉันต้องการให้ปัญหาถูกกำหนดขอบเขตชัดเจนก่อนที่จะเสนอวิธีแก้
แยกการระบุปัญหาออกจากวิธีแก้ปัญหา ข้อเสนอที่กระโดดตรงไปที่วิธีแก้มักทำให้เสียผู้อ่านที่ยังไม่เชื่อว่ามีปัญหาที่ควรแก้
กำหนดขอบเขต รวมถึงสิ่งที่อยู่นอกขอบเขต
นี่คือโครงการที่ฉันเสนอ: [อธิบาย] เขียนส่วนขอบเขตที่ระบุชัดเจนว่าโครงการนี้จะรวมและไม่รวมอะไร โดยมีสิ่งเฉพาะที่ระบุชัดเจนว่าอยู่นอกขอบเขตอย่างน้อยสามข้อ ฉันต้องการหลีกเลี่ยงไม่ให้ข้อเสนอถูกตีความกว้างกว่าที่ฉันตั้งใจ
รายการที่ชัดเจนว่าอะไรอยู่นอกขอบเขตมักเป็นส่วนของข้อเสนอที่ป้องกันความสับสนในอนาคตได้มากที่สุด
ทดสอบความทนทานของข้อเสนอก่อนส่ง
อ่านร่างข้อเสนอนี้เสมือนคุณเป็นผู้มีส่วนได้ส่วนเสียที่ตัดสินใจว่าจะอนุมัติหรือไม่: [วางร่างของคุณ] คุณจะมีคำถามอะไรก่อนอนุมัติสิ่งนี้? กำหนดเวลา ขอบเขต หรือตัวชี้วัดความสำเร็จดูไม่สมจริงหรือไม่ชัดเจนที่ไหน จงเจาะจงว่าอะไรขาดไป ไม่ใช่แค่อะไรผิด
วิธีนี้ได้ผลดีที่สุดก่อนส่งข้อเสนอ ในฐานะการตรวจสอบครั้งสุดท้ายมากกว่าขั้นตอนร่างแรก
ปรับน้ำเสียงของข้อเสนอสำหรับผู้ฟังอื่น
นี่คือข้อเสนอโครงการที่ฉันเขียนให้ทีมของตัวเอง: [วางร่างของคุณ] เขียนใหม่สำหรับผู้ฟังระดับผู้บริหารที่ต้องอนุมัติงบประมาณ: เริ่มด้วยเหตุผลทางธุรกิจและค่าใช้จ่าย ทำให้รายละเอียดทางเทคนิคกระชับ และย้ายรายละเอียดการดำเนินการไปยังส่วนเอกสารแนบท้าย
โครงการเดียวกันมักต้องมีสองเวอร์ชันที่แตกต่างกัน ขึ้นอยู่กับว่าใครอ่านและคนนั้นต้องตัดสินใจอะไร
โครงสร้าง
ห้าส่วนที่พรอมต์ข้อเสนอต้องการ
ห้าส่วนนี้เปลี่ยนไอเดียคลุมเครือให้เป็นสิ่งที่ผู้มีส่วนได้ส่วนเสียสามารถลงมือทำได้จริง
การระบุปัญหา ก่อนวิธีแก้
ระบุปัญหาและเหตุผลที่มันสำคัญก่อนอธิบายวิธีแก้ ผู้อ่านที่ยังไม่เชื่อว่ามีปัญหาจะไม่จริงจังกับวิธีแก้ที่เสนอสำหรับมัน
ขอบเขต รวมถึงสิ่งที่อยู่นอกขอบเขตอย่างชัดเจน
บอกว่าโครงการจะทำอะไร และสำคัญไม่น้อยกว่ากัน จะไม่ทำอะไร ข้อเสนอที่ไม่มีขอบเขตชัดเจนมักขยายตัวในหัวของแต่ละคนจนเป็นสิ่งที่พวกเขาคิดว่ามันหมายถึง
ข้อจำกัดจริง ไม่ใช่ที่แต่งขึ้น
ให้ Claude รู้ขนาดทีมจริง กำหนดเวลาโดยประมาณ และช่วงงบประมาณ แม้บางส่วนยังไม่แน่นอน แผนที่สร้างจากตัวเลขที่แต่งขึ้นต้องทำใหม่ทันทีที่ตัวเลขจริงปรากฏ
ตัวชี้วัดความสำเร็จ ระบุอย่างชัดเจน
บอกว่าคุณจะรู้ได้อย่างไรว่าโครงการประสบความสำเร็จ ข้อเสนอที่ไม่มีตัวชี้วัดความสำเร็จยากที่จะอนุมัติอย่างมั่นใจ และถ้าได้รับอนุมัติก็ยากที่จะตรวจสอบในหกเดือนต่อมา
เข้าใจผู้อ่านของคุณ
โครงการเดียวกันต้องการข้อเสนอต่างกันสำหรับผู้ฟังต่างกัน
ข้อเสนอที่เขียนให้ทีมของคุณวางแผนและข้อเสนอที่เขียนเพื่อขออนุมัติงบประมาณจากผู้บริหารทำหน้าที่ต่างกัน แม้จะอธิบายโครงการเดียวกัน เวอร์ชันสำหรับทีมสามารถลงลึกในรายละเอียดการดำเนินการเพราะผู้อ่านสนใจอยู่แล้ว เวอร์ชันผู้บริหารต้องเริ่มด้วยเหตุผลทางธุรกิจและค่าใช้จ่าย เพราะนั่นคือการตัดสินใจจริงที่ผู้อ่านคนนั้นต้องทำ และรายละเอียดที่ไม่จำเป็นแค่ทำให้การตัดสินใจที่คุณขอล่าช้าออกไป
บอก Claude อย่างชัดเจนว่าใครอ่านและคุณต้องการการตัดสินใจอะไรจากคนนั้น "นี่สำหรับทีมของฉันวางแผนไตรมาสหน้า" และ "สิ่งนี้ต้องได้รับการอนุมัติงบประมาณจากรองประธานที่ไม่รู้รายละเอียดทางเทคนิค" นำ Claude ไปสู่ร่างที่แตกต่างกันสองแบบ แม้สำหรับโครงการเดียวกัน และการระบุผู้ฟังล่วงหน้าช่วยให้คุณไม่ต้องเขียนเวอร์ชันหนึ่งแล้วพบในภายหลังว่ามันผิดสำหรับผู้อ่านจริง
ถ้าคุณต้องการทั้งสองเวอร์ชันจริง ๆ มักเร็วกว่าที่จะเขียนเวอร์ชันละเอียดสำหรับทีมก่อน แล้วขอให้ Claude ปรับให้เหมาะกับผู้ฟังระดับผู้บริหาร แทนที่จะเขียนทั้งสองจากศูนย์ ข้อเท็จจริงพื้นฐานไม่เปลี่ยน เปลี่ยนแค่สิ่งที่ถูกเน้นและสิ่งที่ย้ายไปอยู่ในเอกสารแนบ
ข้อผิดพลาดที่พบบ่อย
อะไรที่ทำให้ข้อเสนอติดขัดแทนที่จะได้รับอนุมัติ
นี่คือช่องว่างที่เปลี่ยนไอเดียที่สมเหตุสมผลให้เป็นข้อเสนอที่ไม่มีใครตอบกลับ
ขอบเขตที่กว้างกว่าที่คุณตั้งใจจริง
ถ้าคุณไม่ระบุว่าอะไรอยู่นอกขอบเขต ผู้อ่านจะเติมช่องว่างด้วยสมมติฐานของพวกเขาเอง ซึ่งมักกว้างกว่าที่คุณตั้งใจเสนอ บอกอย่างชัดเจนว่าโครงการนี้จะไม่รวมอะไร
ไม่มีการตัดสินใจที่ระบุไว้สำหรับผู้อ่าน
ข้อเสนอที่ไม่บอกว่าคุณกำลังขออะไรจริง ๆ การอนุมัติ งบประมาณ บุคลากร ไฟเขียวให้เริ่ม ทำให้ผู้อ่านไม่แน่ใจว่าต้องตอบสนองอย่างไร
ตัวเลขที่แต่งขึ้นแทนข้อจำกัดจริง
กำหนดเวลาหรืองบประมาณที่ Claude เดาเพราะคุณไม่ได้ให้มา จะฟังดูมั่นใจแม้จะเป็นเรื่องแต่ง และคนที่รู้ตัวเลขจริงจะสังเกตว่าข้อเสนอไม่ตรงกับความเป็นจริง
ไม่มีวิธีรู้ในอนาคตว่ามันสำเร็จหรือไม่
ข้อเสนอที่ไม่มีตัวชี้วัดความสำเร็จยากที่จะอนุมัติอย่างมั่นใจ และถ้าได้รับอนุมัติก็ไม่มีวิธีที่ตกลงกันไว้เพื่อตรวจสอบในหกเดือนต่อมาว่าโครงการส่งมอบผลลัพธ์ได้หรือไม่
ใช้สิ่งที่คุณมีอยู่แล้ว
วางเอกสารพื้นฐานของคุณแทนที่จะเริ่มจากศูนย์
ถ้าคุณมีข้อเสนอก่อนหน้าสำหรับสิ่งที่คล้ายกัน บันทึกการประชุมหยาบ ๆ เกี่ยวกับปัญหา หรือแม้แต่โครงร่างที่ทำไว้ครึ่งทาง ให้วางมันลงไปแทนที่จะอธิบายโครงการใหม่จากความทรงจำ Claude จัดระเบียบและขัดเกลาเอกสารที่คุณมีอยู่แล้วได้น่าเชื่อถือกว่าการแต่งบริบท ประวัติ และข้อจำกัดเฉพาะของโครงการจริงของคุณจากคำอธิบายเพียงประโยคเดียวมาก
เรื่องนี้สำคัญเป็นพิเศษสำหรับการระบุปัญหา ถ้าปัญหาเกิดขึ้นในการประชุม ในคำร้องเรียนของลูกค้า หรือในความพยายามที่ล้มเหลวก่อนหน้าเกี่ยวกับสิ่งที่คล้ายกัน บริบทนั้นควรอยู่ในพรอมต์ การระบุปัญหาที่สร้างจากแค่บทสรุปปัจจุบันของคุณเกี่ยวกับประเด็นนี้มักสูญเสียรายละเอียดเฉพาะที่ทำให้ปัญหาเป็นจริงและคุ้มค่าที่จะแก้ไข
สิ่งเดียวกันนี้ใช้ได้กับข้อจำกัด ถ้าองค์กรของคุณมีเทมเพลตข้อเสนอมาตรฐานอยู่แล้ว ช่วงงบประมาณทั่วไปสำหรับโครงการประเภทนี้ หรือข้อตกลงเรื่องกำหนดเวลาตามปกติ ให้สิ่งนั้นแก่ Claude โดยตรงแทนที่จะปล่อยให้มันใช้โครงสร้างทั่วไป ข้อเสนอที่ตรงกับรูปแบบที่องค์กรของคุณคาดหวังสำหรับเอกสารประเภทนี้อยู่แล้วจะถูกอ่านอย่างจริงจังมากกว่าข้อเสนอที่อ่านเหมือนเทมเพลตจากที่อื่น
ควรเก็บโฟลเดอร์ที่อัปเดตอยู่เสมอของข้อเสนอที่ได้รับการอนุมัติในองค์กรของคุณไว้ แม้จะเป็นแบบไม่เป็นทางการ และวางข้อเสนอที่สำเร็จไว้ข้างๆ ร่างของคุณเองเมื่อทำได้ Claude สามารถจับรูปแบบของสิ่งที่มักจะผ่านได้ ไม่ว่าจะเป็นระดับความเป็นทางการที่เฉพาะเจาะจง การเลือกใช้พารากราฟสั้นมากกว่ายาว หรือความเคยชินที่จะเริ่มด้วยการลดความเสี่ยง แล้วนำรูปแบบเดียวกันนั้นมาใช้กับร่างปัจจุบันของคุณ แทนที่จะใช้โครงสร้างทั่วไปที่ไม่ตรงกับสิ่งที่ได้ผลจริงในที่ทำงานของคุณ
ก่อนส่งไป
สิ่งที่ควรตรวจสอบก่อนข้อเสนอไปถึงผู้อ่าน
อ่านส่วนขอบเขตก่อนและถามตัวเองว่ามันอธิบายสิ่งที่คุณตั้งใจจะทำอย่างแม่นยำหรือไม่ ไม่มากไม่น้อย นี่คือส่วนที่มีโอกาสก่อปัญหาในอนาคตมากที่สุดถ้ามันคลุมเครือหรือกว้างกว่าที่คุณตั้งใจจริง เพราะมันจะกลายเป็นจุดที่ทุกคนย้อนกลับมาชี้เมื่อโครงการดำเนินไปแล้ว
ตรวจสอบตัวเลขทุกตัวเทียบกับความเป็นจริง: กำหนดเวลา ขนาดทีม งบประมาณ แผนที่ฟังดูมั่นใจแต่สร้างจากตัวเลขที่เดาไว้แย่กว่าคำพูดตรงไปตรงมาว่า "กำหนดเวลายังไม่สรุปแน่ชัด" เพราะอันแรกจะถูกมองเป็นคำมั่นสัญญาทันทีที่มีคนอ่าน
โครงสร้างในที่นี้ช่วยให้คุณได้ร่างที่แข็งแรงอย่างรวดเร็ว การตัดสินว่าองค์กรและผู้อ่านของคุณต้องการอะไรจริง ๆ สำหรับข้อเสนอเฉพาะนี้ยังคงเป็นของคุณก่อนที่มันจะถูกส่งออกไป
ข้อเสนอที่ชัดเจนถูกอ่าน ข้อเสนอที่คลุมเครือถูกเมิน
โครงสร้างนี้ใช้ซ้ำได้กับทุกข้อเสนอหลังจากนี้ บทเรียนฟรีของ Nightschool AI พาคุณผ่านงานเขียนจริงในที่ทำงานกับ Claude รวมถึงการตัดสินใจเกี่ยวกับขอบเขตและผู้ฟัง
คำถามที่พบบ่อย
สิ่งที่สำคัญที่สุดที่ต้องบอก Claude ก่อนให้มันร่างข้อเสนอคืออะไร?
ข้อเสนอนี้เพื่อใครและคุณต้องการให้พวกเขาตัดสินใจอะไร ข้อเสนอให้ทีมของคุณวางแผนและข้อเสนอที่ขอให้ผู้บริหารอนุมัติงบประมาณต้องการการกำหนดกรอบที่แตกต่างกัน แม้สำหรับโครงการเดียวกัน
ฉันควรให้ตัวเลขงบประมาณแก่ Claude หรือไม่ถ้าฉันยังไม่มี?
ไม่ บอกว่างบประมาณยังไม่สรุปแทนที่จะให้ Claude เดาตัวเลข ตัวเลขที่แต่งขึ้นซึ่งฟังดูมั่นใจจะถูกมองเป็นคำมั่นสัญญาทันทีที่คนที่รู้ตัวเลขจริงเห็นมัน
ทำไมข้อเสนอต้องมีส่วนที่ระบุอย่างชัดเจนว่าอะไรอยู่นอกขอบเขต?
ถ้าไม่มี ผู้อ่านจะเติมช่องว่างด้วยสมมติฐานของพวกเขาเองเกี่ยวกับสิ่งที่โครงการรวมอยู่ ซึ่งมักกว้างกว่าที่คุณตั้งใจจริง การระบุอย่างชัดเจนว่าอะไรถูกยกเว้นช่วยป้องกันความเบี่ยงเบนนั้น
ฉันจะเขียนข้อเสนอที่ใช้ได้ทั้งกับทีมและผู้บริหารได้อย่างไร?
เขียนเวอร์ชันละเอียดสำหรับทีมของคุณก่อน จากนั้นขอให้ Claude ปรับให้เหมาะกับผู้อ่านระดับผู้บริหาร: เริ่มด้วยเหตุผลทางธุรกิจและค่าใช้จ่าย ลดรายละเอียดทางเทคนิค และย้ายรายละเอียดการดำเนินการไปยังเอกสารแนบ
ฉันสามารถใช้บันทึกจากข้อเสนอก่อนหน้าหรือการประชุมแทนการเริ่มจากศูนย์ได้หรือไม่?
ได้ และคุณควรทำ วางเอกสารพื้นฐานที่คุณมีอยู่แล้ว Claude จัดระเบียบและขัดเกลาเอกสารจริงได้ดีกว่าการแต่งบริบทเฉพาะของโครงการคุณจากศูนย์มาก
ทำไมข้อเสนอต้องมีตัวชี้วัดความสำเร็จ?
ถ้าไม่มีวิธีที่ระบุไว้ในการวัดความสำเร็จ ข้อเสนอจะยากที่จะอนุมัติอย่างมั่นใจ และไม่มีวิธีที่ตกลงกันไว้เพื่อตรวจสอบในภายหลังว่าโครงการส่งมอบตามที่สัญญาไว้จริงหรือไม่
ฉันควรตรวจสอบร่างอย่างไรก่อนส่งให้ผู้มีส่วนได้ส่วนเสีย?
ขอให้ Claude อ่านมันในมุมของผู้มีส่วนได้ส่วนเสียและระบุคำถามที่พวกเขาจะมีก่อนอนุมัติ จากนั้นตรวจสอบแต่ละตัวเลขในร่างแยกกันเทียบกับข้อจำกัดจริงของคุณก่อนส่ง
ถ้าองค์กรของฉันมีเทมเพลตข้อเสนอมาตรฐานอยู่แล้วล่ะ?
ให้สิ่งนั้นแก่ Claude โดยตรงแทนที่จะปล่อยให้ร่างใช้โครงสร้างทั่วไป ข้อเสนอที่ตรงกับรูปแบบที่องค์กรของคุณคาดหวังอยู่แล้วจะถูกอ่านอย่างจริงจังมากกว่าข้อเสนอที่ไม่ตรง
ข้อเสนอที่ได้รับอนุมัติเริ่มจากข้อจำกัดจริง
โครงสร้างนี้ใช้ซ้ำได้ทุกครั้ง การให้ตัวเลขที่ซื่อตรงแทนการเดาเป็นส่วนที่คุ้มค่าที่จะทำให้ถูกต้อง