copy → เติมข้อมูลจริงใน [...] → ส่งให้ AI
คุณเป็น technical writer เขียนคู่มือการใช้งาน [ชื่อระบบ] บริบท: - ระบบ: [อธิบายสั้นๆ ว่าทำอะไร] - ผู้ใช้เป้าหมาย: [เช่น เจ้าหน้าที่ฝ่ายขาย / ลูกค้าทั่วไป] - ฟีเจอร์ที่จะเขียน: [ชื่อฟีเจอร์] ข้อมูลอ้างอิง (ใช้เฉพาะข้อมูลนี้ ห้ามเดา): - Screenshot: [แนบ] - ชื่อปุ่ม/เมนู/field ที่ถูกต้อง: [ลิสต์] - Status/flow: [อธิบาย] เขียนคู่มือแบบ Markdown ประกอบด้วย: 1. ภาพรวมสั้นๆ ว่าฟีเจอร์นี้ทำอะไร 2. ขั้นตอนการใช้งาน (numbered steps, อ้างปุ่ม/เมนูจริง) 3. กรณี error ที่อาจเจอ + วิธีแก้ 4. หมายเหตุ/ข้อควรระวัง โทน: [กระชับเป็นทางการ / เป็นกันเอง] ถ้าข้อมูลไม่พอจุดไหน ให้ทำ [TODO: ...] แทน อย่าแต่งขึ้นมา
จาก OpenAPI spec ด้านล่าง เขียนเอกสารอธิบาย endpoint นี้สำหรับนักพัฒนา [วาง spec / yaml] รวม: - คำอธิบายว่า endpoint ทำอะไร - request: method, path, params, body (ตัวอย่างจริงจาก spec) - response: แต่ละ status code + ตัวอย่าง - error case รูปแบบ Markdown ใช้ field name จาก spec เท่านั้น ห้ามเพิ่ม field ที่ไม่มี
นี่คือตัวอย่างสไตล์คู่มือที่เราใช้: [วางเนื้อหาเล่มเดิม 1-2 หน้า] ช่วยเขียนหน้าใหม่เรื่อง [หัวข้อ] ให้โทน โครงสร้าง และวิธีใช้คำ เหมือนตัวอย่างข้างบน เนื้อหาที่จะเขียน: [ข้อมูล/screenshot]
ช่วยรีวิวคู่มือด้านล่างในฐานะ technical writer: [วาง draft] เช็ก: - ขั้นตอนชัด ทำตามได้จริงไหม - มีจุดไหนคลุมเครือ / ข้ามสเต็ป - edge case / error ที่ยังขาด - โทนสม่ำเสมอไหม บอกจุดที่ต้องแก้เป็นลิสต์ + เขียนเวอร์ชันปรับปรุงให้
แปลงเนื้อหานี้เป็นไฟล์ Docusaurus .mdx:
[วางเนื้อหา]
- ใส่ frontmatter: title, sidebar_position: [เลข]
- ใช้ admonition (:::tip, :::warning) ตรงหมายเหตุ/คำเตือน
- escape อักขระ MDX ที่จะทำ build พัง (<, {, })
- ถ้ามี flow ซับซ้อน เสนอ card layout แบบ Infima (class="row"/"col")[วาง prompt ตัวจริงที่เราใช้แล้วได้ผลดี]