2. บอก Claude ให้รู้จักเราก่อน

Claude ช่วยได้ดีขึ้นมากถ้ารู้ว่าเราเป็นใคร ใส่ข้อมูลนี้ไว้ใน Project Instructions ตั้งแต่ต้น:

• ชื่อ + ทำงานอะไร + หน้าที่หลักคืออะไร
• เป้าหมายตอนนี้คืออะไร
• ถนัดเรื่องไหน กำลังเรียนรู้เรื่องไหน
• ชอบคำตอบสั้นหรือยาว ไม่ชอบคำตอบแบบไหน

ยิ่งให้ context ชัด คำตอบยิ่งตรง

3. ตั้ง Custom Instructions ให้ Claude ทำงานในสไตล์เรา

รู้จักเราแล้ว ยังต้องบอกอีกว่าอยากให้มัน “ทำงานกับเราแบบไหน” ตัวอย่าง Instructions ที่ใช้ได้เลย:

ตอบตรง ๆ ไม่ต้องเกริ่น ไม่ต้องชมก่อนตอบ ไม่ต้องพูดซ้ำคำถาม ถ้าไม่แน่ใจให้ถามก่อน ถ้าเป็นงานธุรกิจให้คิดแบบ CEO ถ้าเป็นงานเขียนให้ใช้โทนกันเอง ถ้างานซับซ้อนให้แตกเป็นขั้นตอน

ข้อนี้สำคัญมาก เพราะทำให้ Claude ไม่ตอบตาม default แต่ตอบในแบบที่เหมาะกับเราจริง ๆ

4. อย่าใช้ Claude เหมือน Google

Claude ไม่ได้เก่งสุดที่การตอบนิยาม แต่เก่งมากตอนช่วยคิด วิเคราะห์ และตัดสินใจ

❌ แบบที่ได้แค่นิยาม: > “Prompt caching คืออะไร?”

✅ แบบที่ได้งานจริง: > “ผมทำ workflow ที่เรียก Claude 20 ครั้งต่อ session ช่วยวิเคราะห์ว่า prompt caching จะลดต้นทุนได้จริงไหม และควรออกแบบ flow ยังไง”

ให้ context + ปัญหาจริงไปด้วย แล้วคำตอบจะต่างกันเยอะมาก

5. ก่อนเริ่มงานใหญ่ ให้ Claude ถามก่อน

งานซับซ้อนอย่างเขียนอีเมลขายของ วางแผนธุรกิจ หรือวางระบบ — อย่าให้มันทำทันที

ใช้ prompt นี้ก่อนเริ่มงานสำคัญทุกครั้ง:

“ก่อนเริ่ม ช่วยถามผม 5 คำถามที่จำเป็นที่สุด เพื่อให้งานนี้ออกมาดีที่สุด”

Claude จะไม่ต้องเดาเองว่า context คืออะไร ผลลัพธ์ที่ได้จะตรงกว่าเดิมมาก

6. ให้ Claude clone สไตล์การเขียนของเรา

ถ้าให้เขียนโดยไม่มีตัวอย่าง งานที่ได้จะดีแบบ AI แต่ไม่เหมือนเรา

วิธีทำ: เอางานเขียนเก่า 3–5 ชิ้นให้มันดู แล้วสั่งว่า:

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

ทำครั้งเดียว ใช้ได้ตลอด Project

7. ใช้ Claude เป็นคนเถียง ไม่ใช่แค่คนช่วยคิด

AI มักตอบเห็นด้วยกับเราเสมอ ถ้าจะใช้ให้คุ้ม ต้องให้มันช่วย “ทุบไอเดีย” ด้วย

เวลามีแผนธุรกิจหรือกำลังตัดสินใจเรื่องใหญ่ ใช้ 2 prompt นี้ต่อกัน:

รอบแรก — หาจุดอ่อน: > “ช่วยทำลายแผนนี้หน่อย หาจุดอ่อน สมมติฐานที่อาจผิด วิธีที่มันจะล้มเหลว และเหตุผลว่าทำไมผมอาจคิดผิด”

รอบสอง — เสริมให้แข็ง: > “ตอนนี้ช่วย steelman ฝั่งผม ทำให้ไอเดียนี้แข็งแรงที่สุดเท่าที่จะเป็นไปได้”

เห็นทั้งด้านที่แย่ที่สุดและด้านที่แข็งแกร่งที่สุด ก่อนตัดสินใจจริง

8. ใช้ Extended Thinking กับงานที่ต้องคิดหนัก

งานง่าย ๆ ไม่จำเป็นต้องใช้ แต่ถ้าเป็นงานพวกนี้ให้เปิด Extended Thinking:

• วิเคราะห์ธุรกิจ / ตัดสินใจลงทุน
• วางระบบหรือแก้ปัญหาเชิงกลยุทธ์
• เปรียบเทียบหลายทางเลือก
• หาจุดเสี่ยงของแผน

หรือบอกตรง ๆ ใน prompt ว่า “คิดแบบละเอียดก่อนตอบ อย่ารีบสรุป” — ผลลัพธ์จะดีกว่าการให้มันตอบเร็ว ๆ เยอะมาก

9. ให้ Claude เขียน prompt ให้ Claude เอง

ถ้าไม่รู้จะสั่งยังไงให้ได้งานดี ถามมันตรง ๆ เลย:

“ผมอยากให้ Claude ช่วยทำ [งานนี้] ช่วยเขียน prompt ที่ดีที่สุดให้หน่อย ใส่ role, context, format, และ constraints ให้ครบ แล้วใช้ prompt นั้นทำงานต่อทันที”

หลายครั้งปัญหาไม่ได้อยู่ที่ Claude ไม่เก่ง แต่อยู่ที่เรายังอธิบายโจทย์ไม่ดีพอ

10. กำหนดความยาวคำตอบทุกครั้ง

ถ้าไม่บอก Claude จะตอบยาวกว่าที่ต้องการเสมอ บอกชัด ๆ ไปเลยว่า:

• “ตอบไม่เกิน 3 ประโยค”
• “ขอ 5 bullet points”
• “เขียนไม่เกิน 150 คำ”
• “เอาเฉพาะข้อสรุป ไม่ต้องอธิบาย”

ช่วยประหยัดทั้งเวลาอ่านและ token โดยเฉพาะคนที่ใช้ Claude บ่อย

11. ตัดคำเกริ่นที่ไม่จำเป็นออก

Claude มักเริ่มด้วย “เป็นคำถามที่ดีมาก” / “เข้าใจครับ” / “มาดูกันทีละส่วน” — ถ้าไม่ต้องการ ใส่ไว้ใน Custom Instructions เลยว่า:

“ไม่ต้องเกริ่น ไม่ต้องชม ไม่ต้องพูดซ้ำคำถาม เข้าคำตอบทันที และไม่ต้องสรุปท้ายถ้าไม่ได้ขอ”

เล็กน้อยแต่ทำให้คำตอบสะอาดขึ้นเยอะ

12. อย่าอธิบายตัวเองซ้ำทุกแชท

ถ้าต้อง paste ข้อมูลตัวเองทุกครั้ง แปลว่า setup ยังไม่ดี

ข้อมูลที่ใช้บ่อยควรอยู่ใน Project Instructions ไม่ใช่ copy-paste ใหม่ทุกแชท เพราะยิ่งใช้บ่อย ยิ่งเปลืองเวลา ยิ่งเปลือง token และ Claude ก็ยังตอบไม่สม่ำเสมออยู่ดี

13. ถ้าเปลี่ยนเรื่อง ให้เปิดแชทใหม่ใน Project เดิม

คุยทุกอย่างในแชทเดียวนาน ๆ context จะยาวเกินไป Claude เริ่มเอาเรื่องเก่ามาปนเรื่องใหม่

ถ้าเปลี่ยนหัวข้อชัด ๆ เช่น จากงานเขียนไปวางระบบ หรือจากธุรกิจไปเรื่องส่วนตัว — เปิดแชทใหม่ใน Project เดิม ยังได้ context ของ Project แต่ไม่แบกข้อมูลเก่าที่ไม่เกี่ยวเข้ามาด้วย

14. ให้ Claude อธิบายเรื่องยากด้วย Feynman Method

อยากเข้าใจเรื่องยากจริง ๆ อย่าให้มันอธิบายด้วยศัพท์เทคนิค ใช้ prompt นี้แทน:

“อธิบายเรื่องนี้ด้วย analogy และตัวอย่างในชีวิตประจำวัน ห้ามใช้ศัพท์ยาก สมมติว่าผมไม่มีพื้นฐานเลย แล้วถามผมกลับทีละคำถามเพื่อเช็กว่าผมเข้าใจจริงไหม”

เหมาะกับทุกเรื่องที่ยาก เช่น การเงิน การลงทุน ระบบ API AI ฟิสิกส์ เพราะเป้าหมายไม่ใช่แค่จำคำตอบ แต่เข้าใจจนพูดเองได้

15. ใช้ Claude วางแผนเที่ยวแบบเข้ากับสไตล์เราจริง ๆ

อย่าถามแค่ “ไปญี่ปุ่น 5 วัน เที่ยวไหนดี” — บอกสไตล์การเที่ยวด้วย:

“ผมชอบตื่นสาย เที่ยวชิล ๆ ไม่แน่น ชอบร้าน local มากกว่าร้านดัง งบวันละ X บาท ไปสองคน เดินเยอะได้ อยากเลี่ยง tourist trap ช่วยวางแผน 5 วันในโตเกียวให้หน่อย”

ได้ itinerary ที่เหมาะกับเราจริง ๆ ไม่ใช่ template ทั่วไป

16. ใช้ Claude วิเคราะห์รายจ่ายแบบมีข้อสรุปจริง

เอารายจ่ายทั้งเดือนให้ Claude ดู แต่ต้องบอกเป้าหมายทางการเงินด้วย เช่น อยากเก็บเงิน ลดหนี้ หรืออยากรู้ว่าเงินหายไปกับอะไร

แล้วให้มันวิเคราะห์: - หมวดไหนใช้เยอะที่สุด - ค่าใช้จ่ายไหนผิดปกติ - อะไรตัดได้โดยไม่กระทบชีวิตมาก - การเปลี่ยนแปลงหนึ่งอย่างที่กระทบการเงินมากที่สุดคืออะไร

ดีกว่าแค่ดู statement แล้วรู้สึกผิดอยู่คนเดียว

17. ใช้ Claude เป็น personal thinking partner

บางเรื่องเราไม่ได้ต้องการคำตอบทันที แต่ต้องการคนช่วยถาม ช่วยสะท้อน และช่วยให้เราคิดชัดขึ้น

บอก Claude ตรง ๆ ว่า:

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

เหมาะกับเรื่องชีวิต งาน ความสัมพันธ์ หรือการตัดสินใจที่ติดอยู่ในหัวนาน ๆ

18. ใช้ Claude stress-test ไอเดียธุรกิจก่อนลงเงินจริง

ก่อนเอาเวลาและเงินไปลงกับไอเดียไหน ให้ Claude ช่วยหารูรั่วก่อน:

“ช่วยถามและวิเคราะห์ไอเดียนี้ให้ผม: สมมติฐานไหนอาจผิด ลูกค้าอาจไม่จ่ายเพราะอะไร คู่แข่งคือใครและเราจะแพ้ตรงไหน อะไรคือปัญหาใหญ่ที่สุด และต้องปรับยังไงถึงจะเวิร์กขึ้น”

เจอปัญหาก่อนเสียเงินจริง — คุ้มมากสำหรับคนทำธุรกิจ

เลือกใช้สถิติแบบไหนดี?

ในการวิเคราะห์ข้อมูลแบบจับคู่ เรามักจะเลือกระหว่างสถิติ 2 ตัวหลักๆ ขึ้นอยู่กับลักษณะการแจกแจงของข้อมูล (Data Distribution):

1. Paired T-test (Parametric): หากข้อมูลที่เก็บมา (เช่น ผลผลิตต่อไร่, ความสูงของต้น) มีการกระจายตัวแบบปกติ (Normal Distribution) สถิติตัวนี้จะช่วยให้นักวิจัยมองเห็น “ส่วนต่างเฉลี่ย” ที่เพิ่มขึ้นหรือลดลงอย่างชัดเจน
2. Wilcoxon Signed-Rank Test (Non-parametric): หากข้อมูลเป็นประเภทลำดับขั้น (Ordinal) เช่น คะแนนความเข้มของสีใบ (ระดับ 1-6) หรือข้อมูลที่มีการแจกแจงไม่ปกติ (Non-normal Distribution) เพราะสามารถช่วยยืนยันได้ว่า “วิธีใหม่” ให้ผลลัพธ์ที่ดีกว่า “วิธีของเกษตรกร” อย่างมีนัยสำคัญหรือไม่ โดยไม่ต้องสนใจ assumption เรื่องการแจกแจงปกติ

ตัวอย่างการวิเคราะห์ด้วย R (R Code Example)

ด้านล่างนี้คือตัวอย่างการจำลองข้อมูลเปรียบเทียบคะแนนความเข้มสีใบพืช (ระดับ 1-6) ระหว่างวิธีของเกษตรกรและวิธีการใหม่ พร้อมการแสดงผลด้วยกราฟและการตั้งสมมติฐานทางสถิติ

# โหลดแพ็กเกจที่จำเป็นสำหรับการจัดการข้อมูลและสร้างกราฟ
library(dplyr)
library(tidyr)
library(ggplot2)

# 1. เตรียมข้อมูลจำลอง (Mockup Data)
# สมมติเราลงพื้นที่ประเมินเกษตรกร 12 ราย วัดค่าความเข้มสีใบ (คะแนน 1-6)
set.seed(123) # ล็อคค่าสุ่มเพื่อให้ผลรันเหมือนเดิมทุกครั้ง

data <- data.frame(
  Farmer_ID = paste0("Farmer_", 1:12),
  Farmer_Method = c(3, 4, 3, 2, 4, 3, 3, 4, 2, 3, 4, 3), # วิธีของเกษตรกร
  Our_Method = c(4, 5, 4, 3, 5, 4, 4, 6, 3, 4, 5, 4)     # วิธีการทดลองใหม่
)

# 2. จัดรูปแบบข้อมูลดิบจาก Wide เป็น Long format สำหรับสร้างกราฟ
data_long <- data %>%
  pivot_longer(cols = c("Farmer_Method", "Our_Method"),
               names_to = "Method",
               values_to = "Score") %>%
  mutate(Method = factor(Method, levels = c("Farmer_Method", "Our_Method"),
                         labels = c("วิธีเกษตรกร", "วิธีใหม่")))

# 3. สร้างกราฟแสดงผลแบบคู่ (Slope Graph / Paired Plot)
# ช่วยให้เห็นแนวโน้มการเปลี่ยนแปลงของเกษตรกรแต่ละรายได้ชัดเจนขึ้น
ggplot(data_long, aes(x = Method, y = Score, group = Farmer_ID)) +
  geom_point(aes(color = Method), size = 4, alpha = 0.8) +
  geom_line(color = "gray60", alpha = 0.6, linewidth = 0.8) +
  theme_minimal(base_size = 14) +
  labs(title = "เปรียบเทียบระดับความเข้มสีใบของพืช (รายแปลง)",
       subtitle = "เส้นเชื่อมแสดงความแตกต่างภายในแปลงของเกษตรกรรายเดียวกัน",
       x = "วิธีการปลูก",
       y = "คะแนนความเข้มสีใบ (1-6)") +
  scale_color_manual(values = c("วิธีเกษตรกร" = "#E69F00", "วิธีใหม่" = "#009E73")) +
  theme(legend.position = "none")

# 4. การประเมินผลทางสถิติ
# เนื่องจากข้อมูลลักษณะนี้เป็นระดับคะแนน (Ordinal score 1-6)
# การใช้ Wilcoxon Signed-Rank Test แบบจับคู่จึงเป็นวิธีที่เหมาะสมที่สุด
wilcox_result <- wilcox.test(data$Our_Method, data$Farmer_Method, paired = TRUE)
wilcox_result

# อย่างไรก็ตาม หากข้อมูลเป็นตัวเลขความต่อเนื่อง (เช่น น้ำหนัก, ส่วนสูง)
# และแจกแจงแบบปกติ สามารถใช้ Paired t-test ได้ดังนี้
t_result <- t.test(data$Our_Method, data$Farmer_Method, paired = TRUE)
t_result

🛠️ 0. เตรียมกระเป๋าเครื่องมือ (2026 Essentials)

ในปี 2026 เราเปลี่ยนมาใช้เครื่องมือที่เร็วและฉลาดกว่าเดิม ก่อนเริ่มควรติดตั้งสิ่งเหล่านี้ให้ครบ:

# ติดตั้ง pak ก่อนเป็นอันดับแรก
install.packages("pak")

# จากนั้นใช้ pak ติดตั้งทุกอย่างพร้อมกัน (เร็วมาก)
pak::pkg_install(c("devtools", "usethis", "testthat", "roxygen2", "quarto"))

⚙️ 0.5 ตั้งค่า .Rprofile เพื่อความสะดวกสูงสุด

เพื่อให้ R โหลดเครื่องมือพัฒนาโดยอัตโนมัติทุกครั้งที่เปิดโปรเจกต์ ให้ตั้งค่า .Rprofile ไว้ล่วงหน้าสักครั้ง แล้วจะไม่ต้องรัน library(devtools) เองอีกเลย

เปิดไฟล์ตั้งค่า:

usethis::edit_r_profile()

เพิ่ม Code นี้ลงไป:

if (interactive()) {
  suppressMessages(library(devtools))
  suppressMessages(library(usethis))
}

ผลที่ได้: คุณสามารถใช้คีย์ลัดอย่าง Ctrl + Shift + L ได้ทันทีทุกครั้งที่เปิด RStudio หรือ Positron โดยไม่ต้องรัน library() เองก่อน

🏗️ 1. ก่อสร้างโครงสร้างพื้นฐาน (Setup)

usethis::create_package("path/to/YourPackageName")

YourPackageName/
├── DESCRIPTION      # ข้อมูล Package (ชื่อ, เวอร์ชัน, Dependencies)
├── NAMESPACE        # ควบคุมว่าฟังก์ชันไหนเป็น Public/Private
├── R/               # 📁 โฟลเดอร์สำหรับวางโค้ด R ทุกไฟล์
└── YourPackageName.Rproj

usethis::use_git()                              # เริ่มต้น Git repository
usethis::use_github()                           # Push ขึ้น GitHub
usethis::use_github_action_check_standard()    # ตั้ง CI: ตรวจโค้ดอัตโนมัติทุกครั้งที่ Push

usethis::use_mit_license("Your Name")   # MIT เป็น License ที่นิยมมากสำหรับ Open-source

🔄 2. วงจรการพัฒนา (The Modern Dev Loop)

หัวใจสำคัญของการพัฒนา R Package คือ “The Golden Cycle” ซึ่งในปี 2026 ทำได้ลื่นไหลและเร็วขึ้น:

Edit code → Load All → Test in Console → Repeat

usethis::use_r("my_cool_function")

devtools::load_all()

# หรือใช้ Shortcut ที่เร็วกว่า:
# Windows: Ctrl + Shift + L
# Mac:     Cmd  + Shift + L

📝 3. การทำคู่มือ (AI-Assisted Documentation)

เรายังคงใช้ Roxygen2 เป็น standard แต่ในปี 2026 AI ช่วยร่างได้เบื้องต้น เหลือแค่ให้เราตรวจสอบและเติมรายละเอียดสำคัญ

#' คำนวณค่าเฉลี่ยรายวัน
#'
#' ฟังก์ชันนี้รับ Vector ตัวเลขและคืนค่าเฉลี่ย โดยสามารถเลือก
#' กำจัด NA ออกก่อนคำนวณได้
#'
#' @param x Numeric vector ที่ต้องการคำนวณ
#' @param na.rm Logical ถ้าเป็น TRUE (ค่าเริ่มต้น) จะกำจัด NA ก่อนคำนวณ
#'
#' @return ค่าเฉลี่ยของ Vector ที่รับเข้ามา (Numeric scalar)
#'
#' @export
#'
#' @examples
#' daily_mean(c(10, 20, 30))
#' daily_mean(c(10, NA, 30), na.rm = TRUE)
daily_mean <- function(x, na.rm = TRUE) {
  mean(x, na.rm = na.rm)
}

devtools::document()

# Shortcut: Ctrl + Shift + D (Windows) / Cmd + Shift + D (Mac)

📦 4. การจัดการ Dependencies (Fast Path)

# ลงทะเบียนว่า Package ของคุณต้องการ dplyr
usethis::use_package("dplyr")

# ✅ วิธีที่ถูกต้อง — ระบุ Package ที่มาอย่างชัดเจน
my_function <- function(df) {
  dplyr::mutate(df, new_col = value * 2)
}

usethis::use_import_from("dplyr", "mutate")

✅ 5. การตรวจสอบคุณภาพ (The Final Boss)

usethis::use_test("my_cool_function")
# จะสร้างไฟล์ tests/testthat/test-my_cool_function.R

# ไฟล์: tests/testthat/test-daily_mean.R

test_that("daily_mean คำนวณค่าเฉลี่ยได้ถูกต้อง", {
  expect_equal(daily_mean(c(10, 20, 30)), 20)
})

test_that("daily_mean จัดการ NA ได้", {
  expect_equal(daily_mean(c(10, NA, 30), na.rm = TRUE), 20)
  expect_true(is.na(daily_mean(c(10, NA, 30), na.rm = FALSE)))
})

test_that("daily_mean รับได้เฉพาะตัวเลข", {
  expect_error(daily_mean("ข้อความ"))
})

devtools::test()

# Shortcut: Ctrl + Shift + T (Windows) / Cmd + Shift + T (Mac)

devtools::check()

# Shortcut: Ctrl + Shift + E (Windows) / Cmd + Shift + E (Mac)

── R CMD check results ─────────────────────────────────
Duration: 23.4s

0 errors ✔ | 0 warnings ✔ | 0 notes ✔

R CMD check succeeded

.github/workflows/R-CMD-check.yaml

#' @examples
#' \donttest{
#' get_production_index_month(year_th = 2568, month = 12)
#' }

usethis::use_build_ignore(".claude")

(คำสั่งนี้จะไปเติมชื่อโฟลเดอร์ลงในไฟล์ .Rbuildignore ให้อัตโนมัติครับ)

📄 6. README และ Vignettes ด้วย Quarto

ในปี 2026 Quarto (.qmd) ได้เข้ามาแทนที่ R Markdown อย่างเต็มตัวใน Workflow การพัฒนา Package:

# สร้าง README.qmd (แนะนำ) หรือ README.Rmd แบบเก่า
usethis::use_readme_qmd()

usethis::use_vignette("getting-started")
# จะสร้างไฟล์ vignettes/getting-started.qmd

🌐 8. สร้างเว็บ Documentation ด้วย pkgdown

ในปี 2026 ไม่ให้ Package ใดไม่มี Documentation Website pkgdown คือเครื่องมือมาตรฐานที่จะแปลง Roxygen comments, Vignettes และ README ของคุณให้กลายเป็นเว็บไซต์ที่สวยงาม เหมือนที่คุณเห็นใน Package ชั้นนำทุกตัวบน CRAN

# ติดตั้ง pkgdown
pak::pkg_install("pkgdown")

# สร้างไฟล์ตั้งค่าพื้นฐาน
pkgdown::init()

url: https://yourusername.github.io/YourPackageName
title: YourPackageName

template:
  bootstrap: 5

reference:
- title: "ฟังก์ชันหลัก"
  contents:
  - daily_mean
  - my_cool_function

articles:
- title: "คู่มือ"
  contents:
  - getting-started

# Build และ Preview เว็บบนเครื่อง
pkgdown::build_site()

usethis::use_pkgdown_github_pages()

template:
  bootstrap: 5
  bootswatch: flatly    # เลือก theme: cerulean, cosmo, flatly, journal, และอื่นๆ
  bslib:
    pkgdown-nav-height: 70px
    primary: "#2c3e50"   # เปลี่ยนสีหลักตาม Brand ของคุณ

home:
  title: "YourPackageName"
  description: |
    คำอธิบายสั้นๆ ว่า Package นี้ทำอะไร
  strip_header: true

template:
  logo: path/to/logo.png    # รูป logo (แนะนำ 200x200px)
  favicon: path/to/favicon.ico

🚀 9. สรุปคีย์ลัด (2026 Quick Reference)

เก็บตารางนี้ไว้เป็น Cheat Sheet ในการพัฒนา:

🗺️ สรุปภาพรวม Workflow

usethis::create_package()       # 1. สร้าง Package
    ↓
usethis::use_git() + use_github() # 2. เชื่อม Git & GitHub
    ↓
usethis::use_r("func_name")     # 3. สร้างไฟล์ฟังก์ชัน
    ↓
devtools::load_all()  ←──────── # 4. (วนซ้ำ) โหลด → แก้ไข → โหลด
    ↓
roxygen2 + devtools::document() # 5. เขียนและสร้างคู่มือ
    ↓
usethis::use_test() + devtools::test() # 6. เขียนและรัน Tests
    ↓
devtools::check()               # 7. Check ก่อน Release
    ↓
devtools::install() / pak::pkg_install() # 8. ติดตั้งใช้งานจริง
    ↓
pkgdown::build_site()           # 9. Build เว็บ documentation (เสร็จแล้ว Deploy อัตโนมัติ)

1. Open-Meteo (ง่ายที่สุด ยืดหยุ่นที่สุด)

Open-Meteo เป็น API ที่เปิดให้ใช้ฟรี แค่ระบุพิกัด Latitude/Longitude ก็ดึงข้อมูลสภาพอากาศทั้งอดีตและพยากรณ์ล่วงหน้าได้เลย ข้อดีคือใช้แค่แพ็กเกจ jsonlite ตัวเดียว

# ติดตั้งแพ็กเกจ: install.packages("jsonlite")
library(jsonlite)

get_hourly_weather <- function(lat, lon, start_date, end_date) {
  base_url <- "https://api.open-meteo.com/v1/forecast"
  params <- paste0(
    "?latitude=", lat, "&longitude=", lon,
    "&start_date=", start_date, "&end_date=", end_date,
    "&hourly=temperature_2m,relative_humidity_2m&timezone=auto"
  )
  
  weather_data <- fromJSON(paste0(base_url, params))
  
  data.frame(
    datetime = as.POSIXct(weather_data$hourly$time, format="%Y-%m-%dT%H:%M"),
    temperature_c = weather_data$hourly$temperature_2m,
    humidity_percent = weather_data$hourly$relative_humidity_2m
  )
}

## ตัวอย่างการดึงข้อมูลพิกัดกรุงเทพฯ
bkk_weather <- get_hourly_weather(13.7563, 100.5018, "2026-03-01", "2026-03-07")
head(bkk_weather)

2. NASA POWER (ข้อมูลดาวเทียมระดับโลก)

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

# ติดตั้งแพ็กเกจ: install.packages("nasapower")
library(nasapower)

# ดึงข้อมูลอุณหภูมิ (T2M) และความชื้น (RH2M)
nasa_weather <- get_power(
  community = "ag",
  lonlat = c(100.5018, 13.7563), # Longitude, Latitude
  pars = c("T2M", "RH2M"),       
  dates = c("2026-03-01", "2026-03-07"),
  temporal_api = "hourly"
)

head(nasa_weather)

3. ข้อมูลสถานีจริงจากสนามบิน (IEM / riem)

ถ้าไม่ชอบข้อมูลจากการประมาณค่าด้วยดาวเทียม และอยากได้ “ข้อมูลที่วัดจากเซ็นเซอร์จริง” เราสามารถดึงข้อมูลจากสถานีตรวจอากาศของสนามบินในไทยได้ผ่านแพ็กเกจ riem

• VTBS = สุวรรณภูมิ
• VTBD = ดอนเมือง
• VTCC = เชียงใหม่

# ติดตั้งแพ็กเกจ: install.packages("riem")
library(riem)

# ดึงข้อมูลของสนามบินดอนเมือง (รหัส VTBD)
airport_weather <- riem_measures(
  station = "VTBD",
  date_start = "2026-03-01",
  date_end = "2026-03-07"
)

# ข้อมูลจะมีคอลัมน์ tmpf (อุณหภูมิฟาเรนไฮต์) และ relh (ความชื้น)
head(airport_weather)

4. MET Norway (สถาบันอุตุนิยมวิทยานอร์เวย์)

แหล่งข้อมูลเบื้องหลังแอปพยากรณ์อากาศชื่อดังอย่าง Yr.no แม่นยำมาก แต่มีกฎเหล็กคือ ต้องใส่ User-Agent เพื่อระบุตัวตนเสมอ

# ติดตั้งแพ็กเกจ: install.packages(c("httr", "jsonlite"))
library(httr)
library(jsonlite)

url <- "https://api.met.no/weatherapi/locationforecast/2.0/compact?lat=13.75&lon=100.50"

# เปลี่ยน User-Agent เป็นอีเมลของคุณ
response <- GET(url, user_agent("MyWeatherScript/1.0 (your_email@example.com)"))

if (status_code(response) == 200) {
  weather_data <- content(response, "text", encoding = "UTF-8") %>% fromJSON()
  times <- weather_data$properties$timeseries$time
  details <- weather_data$properties$timeseries$data$instant$details
  
  met_df <- data.frame(
    datetime = as.POSIXct(times, format="%Y-%m-%dT%H:%M:%SZ", tz="UTC"),
    temperature_c = details$air_temperature,
    humidity_percent = details$relative_humidity
  )
  head(met_df)
}

1. สร้างฟังก์ชันดึงค่าความชื้นในดินด้วย R

เรามาเริ่มด้วยการเขียนฟังก์ชันสั้นๆ ใน R ที่รับค่าละติจูด (Latitude) และลองจิจูด (Longitude) แล้ววิ่งไปดึงข้อมูลจาก API กลับมา:

# ติดตั้งแพ็กเกจ: install.packages(c("jsonlite", "dplyr", "purrr"))
library(jsonlite)
library(tidyverse)
library(purrr)

get_current_soil_moisture <- function(lat, lon) {
  
  # ระบุพิกัดและโมเดลความชื้น 3-9 cm
  url <- paste0("https://api.open-meteo.com/v1/forecast?latitude=", lat, 
                "&longitude=", lon, 
                "&hourly=soil_moisture_3_to_9cm&forecast_days=1")
  
  # ดึงข้อมูลจาก API
  res <- tryCatch(fromJSON(url), error = function(e) NULL)
  
  # หน่วงเวลาเล็กน้อยป้องกันการรัว Request จนโดนบล็อก (Polite Scraping)
  Sys.sleep(0.2)
  
  # เช็คว่า API ส่งข้อมูล soil_moisture_3_to_9cm กลับมาไหม ถ้าเกิดพังให้คืนค่า NA
  if (is.null(res) || is.null(res$hourly$soil_moisture_3_to_9cm)) {
    return(NA_real_) 
  }
  
  # หยิบค่าความชื้นชั่วโมงปัจจุบันใบแรกมาใช้
  val <- res$hourly$soil_moisture_3_to_9cm[1]
  
  if (is.null(val) || is.na(val)) {
    return(NA_real_)
  }
  
  # ส่งค่าความชื้นที่มีหน่วยเป็น m³/m³ กลับไป
  return(as.numeric(val))
}

ฟังก์ชันนี้จะส่งคืนเป็นตัวเลข (ความชื้นดินในหน่วยลูกบาศก์เมตรต่อน้ำ 1 ลูกบาศก์เมตร หรือ ) กลับมา ถ้าเกิดโหลดจาก API ไม่ได้ก็จะส่งกลับเป็น NA ครับ

2. ประยุกต์ใช้กับตำแหน่งหลายๆ ฟาร์มพร้อมกัน

ทีนี้ ถ้าเรามีข้อมูลแปลงผักหรือฟาร์มหลายกระจายอยู่ทั่วประเทศ เราจะมานั่งลูป for ก็อาจจะดูยืดยาดไป ลองใช้พลังของ purrr::map2_dbl() จาก tidyverse จัดการกันเลยครับ

# สมมติรายชื่อและพิกัดของฟาร์ม 3 แห่ง
my_farms <- data.frame(
  farm_name = c("ฟาร์มรังสิต (ปทุมธานี)", "ฟาร์มดอยอินทนนท์ (เชียงใหม่)", "ฟาร์มปากช่อง (โคราช)"),
  lat = c(14.02, 18.58, 14.70),
  lon = c(100.62, 98.48, 101.41)
)

# ใช้ mutate และ map2_dbl โยนละติจูด, ลองจิจูด แต่ละแถวเข้าไปในฟังก์ชัน
my_farms_updated <- my_farms |>
  mutate(
    current_moisture_m3_m3 = map2_dbl(lat, lon, get_current_soil_moisture)
  )

# ดูผลลัพธ์ว่าฟาร์มไหนความชื้นเป็นยังไงบ้าง
print(my_farms_updated)

ผลลัพธ์ที่ได้จะเป็นตารางแบบนี้:

                     farm_name   lat    lon current_moisture_m3_m3
1        ฟาร์มรังสิต (ปทุมธานี) 14.02 100.62                  0.342
2 ฟาร์มดอยอินทนนท์ (เชียงใหม่) 18.58  98.48                  0.415
3         ฟาร์มปากช่อง (โคราช) 14.70 101.41                  0.198

แค่นี้เราก็สามารถรู้ความชื้นดินเบื้องต้นของพื้นที่แปลงเกษตรของเรา แล้วเอาไปตั้งเงื่อนไขต่อได้ว่า ถ้าน้อยกว่า 0.2 ให้แจ้งเตือนเข้า LINE หรือให้ส่งสัญญาณเปิดปั๊มน้ำอัตโนมัติก็ทำได้แล้วครับ! สนุกกับการปลูกผักอัจฉริยะนะครับ 🌱

💻 R Function สำหรับประเมินระยะเปียกใบเบื้องต้น

ก่อนใช้งาน ต้องติดตั้ง package ที่จำเป็นก่อนนะครับ โดยรันคำสั่ง:

install.packages(c("httr", "jsonlite", "dplyr", "lubridate"))

# โหลด Libraries ที่จำเป็น
library(httr)
library(jsonlite)
library(dplyr)
library(lubridate)

#' ฟังก์ชันดึงและคำนวณข้อมูลระยะเปียกใบ (Leaf Wetness Duration) รายวัน
#' 
#' @param lat ละติจูด (เช่น 14.0205)
#' @param lon ลองจิจูด (เช่น 100.7299)
#' @param start_date วันที่เริ่มต้น รูปแบบ "YYYY-MM-DD"
#' @param end_date วันที่สิ้นสุด รูปแบบ "YYYY-MM-DD"
#' @param rh_threshold เกณฑ์ความชื้นสัมพัทธ์ที่ทำให้เกิดน้ำค้าง (ค่าเริ่มต้น 90%)
#' @return Dataframe สรุประยะเวลาเปียกใบ (ชั่วโมง/วัน)
get_leaf_wetness <- function(lat, lon, start_date, end_date, rh_threshold = 90) {
  
  # 1. สร้าง URL เพื่อดึงข้อมูล API ของ Open-Meteo Historical Data
  url <- paste0(
    "https://archive-api.open-meteo.com/v1/archive?",
    "latitude=", lat,
    "&longitude=", lon,
    "&start_date=", start_date,
    "&end_date=", end_date,
    "&hourly=precipitation,relative_humidity_2m",
    "&timezone=auto"
  )
  
  # 2. ดึงข้อมูลผ่าน API
  response <- GET(url)
  
  if (status_code(response) != 200) {
    stop("เกิดข้อผิดพลาดในการดึงข้อมูล กรุณาตรวจสอบพิกัด อินเทอร์เน็ต หรือวันที่")
  }
  
  # แปลง JSON เป็น Data Frame
  data_json <- fromJSON(content(response, "text", encoding = "UTF-8"))
  
  # 3. จัดการข้อมูลรายชั่วโมง
  hourly_data <- data.frame(
    # Open-Meteo ส่งเวลามาในรูปแบบ "2024-01-01T00:00"
    time = ymd_hm(data_json$hourly$time),
    precipitation = data_json$hourly$precipitation,
    relative_humidity = data_json$hourly$relative_humidity_2m
  )
  
  # 4. ประเมินระยะเปียกใบ (Leaf Wetness) ในแต่ละชั่วโมง
  # ให้ชั่วโมงนั้นมีค่า = 1 หากมีฝนตก หรือ ความชื้นสัมพัทธ์สูงกว่าเกณฑ์
  hourly_data <- hourly_data %>%
    mutate(
      is_wet = ifelse(
        (!is.na(precipitation) & precipitation > 0) | 
        (!is.na(relative_humidity) & relative_humidity >= rh_threshold),
        1, 0 # 1 คือเปียก, 0 คือแห้ง
      ),
      date = as.Date(time) # สกัดเฉพาะวันที่เพื่อใช้ออกรายงาน
    )
  
  # 5. สรุปผลเป็นรายวัน (ชั่วโมงเปียกใบรวมใน 1 วัน)
  daily_lwd <- hourly_data %>%
    group_by(date) %>%
    summarise(
      leaf_wetness_hours = sum(is_wet, na.rm = TRUE),
      avg_humidity_percent = round(mean(relative_humidity, na.rm = TRUE), 2),
      total_precip_mm = sum(precipitation, na.rm = TRUE)
    )
  
  return(daily_lwd)
}

# ==========================================
# 📌 ตัวอย่างการใช้งาน (Example Usage)
# ==========================================
# สมมติใช้พิกัดรังสิต ปทุมธานี ช่วงวันที่ 1 - 7 มีนาคม 2026

# lat_example <- 14.0205
# lon_example <- 100.7299
# result <- get_leaf_wetness(
#   lat = lat_example, 
#   lon = lon_example, 
#   start_date = "2026-03-01", 
#   end_date = "2026-03-07"
# )

# print(result)

📊 สิ่งที่คุณจะได้จาก Function นี้

Dataframe ที่ Return กลับมาจะมีข้อมูลตามนี้ครับ: - date: วันที่ - leaf_wetness_hours: เป้าหมายหลัก คือจำนวนชั่วโมงที่ใบเปียกใน 1 วัน (เต็มที่คือ 24 ชั่วโมง) - avg_humidity_percent: ความชื้นสัมพัทธ์เฉลี่ยของวันนั้น - total_precip_mm: ปริมาณน้ำฝนรวมในวันนั้น

ข้อควรระวัง: ฟังก์ชันนี้ประเมินระยะเปียกใบจาก “สภาพอากาศระดับมหภาค (Macroclimate)” แต่ในแปลงปลูกจริง (Microclimate) ระยะเวลาที่ใบแห้งหรือเปียกอาจแตกต่างกันตามความหนาแน่นของทรงพุ่มหรือทิศทางลม หากคุณต้องการความแม่นยำสูงระดับร้อยเปอร์เซ็นต์ อาจต้องปรับตัวแปร rh_threshold ให้เหมาะสมกับชนิดพืชของคุณดูครับ (บางงานวิจัยใช้ที่ 85% หรือ 92%)

การทำ Advanced Leaf Wetness Duration สำหรับนาข้าว

การประเมินระยะเปียกใบใหัแม่นยำระดับนำไปใช้งานจริงกับ “นาข้าว” นั้น มีความท้าทายเฉพาะตัวครับ เนื่องจากข้าวเป็นพืชที่มีทรงพุ่มหนาแน่นและปลูกในสภาพน้ำขัง (Paddy field) การใช้แค่เกณฑ์ความชื้นสัมพัทธ์ (RH) แบบพื้นฐานอาจคลาดเคลื่อนได้ง่าย นี่คือข้อมูลเจาะลึกและแนวทางยกระดับความแม่นยำครับ

💻 R Function: Advanced Leaf Wetness Duration

# โหลด Libraries ที่จำเป็น
library(httr)
library(jsonlite)
library(dplyr)
library(lubridate)

#' ฟังก์ชันประเมินระยะเปียกใบขั้นสูง (Advanced LWD) สำหรับนาข้าว

get_advanced_lwd <- function(lat, lon, start_date, end_date) {
  
  # 1. กำหนด URL ดึงข้อมูล 6 ตัวแปร (ฝน, ความชื้น, อุณหภูมิ, จุดน้ำค้าง, ลม, รังสีดวงอาทิตย์)
  url <- paste0(
    "https://archive-api.open-meteo.com/v1/archive?",
    "latitude=", lat,
    "&longitude=", lon,
    "&start_date=", start_date,
    "&end_date=", end_date,
    "&hourly=precipitation,relative_humidity_2m,temperature_2m,dew_point_2m,wind_speed_10m,shortwave_radiation",
    "&timezone=auto"
  )
  
  # 2. ดึงข้อมูล API
  response <- GET(url)
  if (status_code(response) != 200) {
    stop("เกิดข้อผิดพลาดในการเชื่อมต่อ API กรุณาตรวจสอบข้อมูลนำเข้า")
  }
  
  data_json <- fromJSON(content(response, "text", encoding = "UTF-8"))
  
  # 3. จัดรูป Dataframe
  hourly_data <- data.frame(
    time = ymd_hm(data_json$hourly$time),
    precip = data_json$hourly$precipitation,
    rh = data_json$hourly$relative_humidity_2m,
    temp = data_json$hourly$temperature_2m,
    dew = data_json$hourly$dew_point_2m,
    wind = data_json$hourly$wind_speed_10m,
    solar = data_json$hourly$shortwave_radiation
  )
  
  # 4. ประเมิน LWD ตามตรรกะ Improved Empirical Model
  hourly_data <- hourly_data %>%
    mutate(
      dew_depression = temp - dew, # คำนวณส่วนต่างอุณหภูมิและจุดน้ำค้าง
      is_wet = case_when(
        # เงื่อนไขที่ 1: ฝนตก
        !is.na(precip) & precip > 0 ~ 1,
        # เงื่อนไขที่ 2: น้ำค้าง (ชื้นสูง + อุณหภูมิใกล้จุดน้ำค้าง + ลมสงบ + ไม่มีแดด)
        (!is.na(rh) & rh >= 85) & 
        (!is.na(dew_depression) & dew_depression <= 2.0) & 
        (!is.na(wind) & wind < 3.0) & 
        (!is.na(solar) & solar < 50) ~ 1,
        # นอกนั้นถือว่าแห้ง
        TRUE ~ 0 
      ),
      date = as.Date(time)
    )
  
  # 5. สรุปผลเป็นรายวัน
  daily_summary <- hourly_data %>%
    group_by(date) %>%
    summarise(
      lwd_hours = sum(is_wet, na.rm = TRUE),
      total_precip_mm = sum(precip, na.rm = TRUE),
      avg_temp_c = round(mean(temp, na.rm = TRUE), 1),
      avg_rh_percent = round(mean(rh, na.rm = TRUE), 1)
    )
  
  return(daily_summary)
}

# ==========================================
# 📌 ตัวอย่างการใช้งาน
# ==========================================
# พิกัด รังสิต ปทุมธานี
# df_result <- get_advanced_lwd(14.0205, 100.7299, "2026-03-01", "2026-03-10")
# print(df_result)

ข้อดีของโมเดลนี้: - ลดความคลาดเคลื่อนในช่วงกลางวัน: โมเดลเก่าที่ใช้แค่ความชื้น บางครั้งฟ้าหลัวความชื้นสูงตอนบ่าย โมเดลอาจนับว่าเปียก แต่โมเดลใหม่มีค่ารังสีดวงอาทิตย์ (solar < 50) มาคอยบังคับไว้ว่าถ้ามีแดด ใบข้าวจะแห้งแน่นอน - สมจริงกับสภาพภูมิอากาศมากขึ้น: การนำลม (wind < 3.0) มาคิด ช่วยให้สะท้อนความเป็นจริงที่ว่า คืนไหนลมแรง น้ำค้างจะไม่ค่อยเกาะใบ

ตัวเลขเกณฑ์ต่างๆ (เช่น ลม < 3, ความชื้น ≥ 85) เป็นค่ากลางจากเปเปอร์วิจัยที่ใช้ได้ดีในเขตร้อนชื้นครับ แต่ถ้าคุณมีข้อมูลสภาพแวดล้อมเฉพาะเจาะจงในแปลง ก็สามารถเข้าไปแก้ตัวเลขใน case_when ได้เลย ลองเอาไปปรับใช้กับฟาร์มของคุณดูนะครับ 🌱

เอกสารอ้างอิง

• Gleason, M. L., et al. (1994). “A nonparametric empirical model for estimating leaf wetness duration.” Phytopathology.
• Kim, J., et al. (2019). “Leaf Wetness Duration Models Using Advanced Machine Learning Algorithms: Application to Farms in Gyeonggi Province, South Korea.” Water (MDPI).
• Sentelhas, P. C., et al. (2006). “Evaluation of a Penman-Monteith approach to provide ‘reference’ and crop canopy leaf wetness duration estimates.” Agricultural and Forest Meteorology.
• Magarey, R. D., et al. (2005). “What Is Leaf Wetness?” Plant Disease (APS Journals).

Claude Skills คืออะไร และต่างจาก CLAUDE.md ยังไง?

ก่อนอื่นต้องทำความเข้าใจก่อนว่า Claude Code มีวิธีให้ “บอก” ให้ Claude รู้บริบทของงานอยู่สองแบบ

CLAUDE.md คือไฟล์ที่ใช้เมื่ออยากให้ Claude รู้ข้อมูลบางอย่างตลอดเวลาในทุกงานของ project นั้น เช่น รูปแบบการเขียนโค้ด, naming convention, หรือโครงสร้าง project

Claude Skills ต่างออกไปตรงที่มันถูกออกแบบมาให้ทำงาน เฉพาะเมื่อต้องการ ข้อดีคือไม่เปลืองพื้นที่ใน context window โดยไม่จำเป็น เปรียบได้กับ SOP ที่ดึงออกมาใช้เฉพาะตอนทำงานนั้น ๆ แทนที่จะต้องวางทิ้งไว้บนโต๊ะตลอดเวลา

โดยทางเทคนิค Skill คือ Markdown ไฟล์ที่วางไว้ในโฟลเดอร์ .claude/skills/ ในระดับ project หรือ ~/.claude/skills/ ในระดับ personal และ Claude Code จะ “หยิบ” มันขึ้นมาใช้เองโดยอัตโนมัติเมื่อเนื้องานเกี่ยวข้อง

Skills ที่น่าสนใจสำหรับนักวิจัยที่ใช้ R

# ติดตั้งผ่าน Claude Code
/plugin marketplace add ab604/claude-code-r-skills
/plugin install r-skills@r-skills

# เพิ่ม marketplace
/plugin marketplace add posit-dev/skills

# ติดตั้งตาม category ที่ต้องการ
/plugin install r-lib@posit-dev-skills
/plugin install quarto@posit-dev-skills
/plugin install shiny@posit-dev-skills

# หรือใช้ npx
npx skills add posit-dev/skills --list               # ดูก่อน
npx skills add posit-dev/skills --skill quarto        # ติดตั้ง quarto
npx skills add posit-dev/skills --agent claude-code --global  # ติดตั้ง global

# ตัวอย่าง _brand.yml เบื้องต้น
color:
  palette:
    primary-blue: "#1B4F8A"
  primary: primary-blue
typography:
  fonts:
    - family: Sarabun
      source: google
  base: Sarabun

วิธีติดตั้งและเริ่มใช้งาน

# เพิ่ม marketplace ก่อน
/plugin marketplace add posit-dev/skills

# ติดตั้ง Skills ที่ต้องการ
/plugin install quarto@posit-dev-skills
/plugin install r-lib@posit-dev-skills
/plugin install shiny@posit-dev-skills

/plugin add /path/to/skill-directory

# Personal (ใช้ได้ทุก project)
~/.claude/skills/ชื่อ-skill/

# Project-level (ใช้เฉพาะ project นี้)
.claude/skills/ชื่อ-skill/

# ดู Skills ทั้งหมดที่มีก่อน
npx skills add posit-dev/skills --list

# ติดตั้งแบบ interactive menu
npx skills add posit-dev/skills --all

# ติดตั้งแบบเจาะจง
npx skills add posit-dev/skills --skill cli --skill lifecycle

# ติดตั้ง global สำหรับ Claude Code
npx skills add posit-dev/skills --agent claude-code --global

เชื่อมเข้ากับ workflow ได้ยังไง?

สำหรับนักวิจัยหรือนักวิชาการที่ใช้ R เป็นหลัก Skills ช่วยได้จริงในสามจุด

ทำ Skill เองได้ไหม?

ได้เลย และไม่ยากอย่างที่คิด

🔗 Anthropic: How to create custom Skills
🔗 anthropics/skills — repository ตัวอย่าง

โครงสร้างพื้นฐานของ Skill แค่นี้เอง:

my-skill/
└── SKILL.md        # ไฟล์หลัก มี YAML frontmatter + instructions

---
name: my-r-epidemiology-skill
description: >
  Guides Claude to use modern R patterns for plant disease
  epidemiology analysis including spatial stats and time series.
  Use when working with disease incidence, severity, or GPS data.
---

# Plant Disease Epidemiology Skill

## Guidelines
- Use sf and terra for spatial data
- Use tidyverse patterns throughout
- Prefer native pipe |>
...

วิธีที่ง่ายที่สุดคือดูตัวอย่าง Skill ที่คนอื่นทำแล้วปรับให้เข้ากับงานของตัวเอง หรือจะลองให้ Claude Code ช่วย generate Skill ใหม่จากตัวอย่างและคำอธิบายที่เราให้ก็ได้เช่นกัน

สรุป Quick Reference

อ้างอิง

• Isabella Velásquez (2026). A Few Claude Skills for R Users. R Works / R-bloggers.
• Anthropic Claude Skills Documentation
• Posit Claude Skills Repository
• anthropics/skills Repository

ทำไม AI ถึงทำให้เราเรียนรู้ได้น้อยลง?

ก่อนพูดถึงวิธีแก้ ต้องเข้าใจปัญหาก่อน Cat Hicks อธิบายไว้ผ่าน 5 กลไกทางจิตวิทยา ที่ AI coding tools ทำให้เกิดขึ้นโดยไม่รู้ตัว

แนวคิดหลัก: Dynamic Textbook

Cat Hicks เรียก Skill ของเขาว่า “dynamic textbook” แนวคิดคือแทนที่จะให้ Claude ทำทุกอย่างแทนเรา Skill นี้ทำให้ Claude เปลี่ยนบทบาทเป็น โค้ชการเรียนรู้ ที่:

• รอให้เราทำงานสำคัญเสร็จก่อน
• แล้วเสนอ exercise สั้น ๆ 10–15 นาที
• หยุดรอคำตอบจากเรา แทนที่จะตอบแทน
• ให้ feedback ที่เชื่อมความคิดของเรากับสิ่งที่เกิดขึ้นจริง

กฎเหล็กของ Skill นี้: Claude ถามคำถามแล้วหยุด ไม่ hint ไม่ให้ตัวอย่าง ไม่บอกคำตอบ รอให้เราตอบก่อนเท่านั้น

เมื่อไหร่ Skill จะ Activate

Claude จะเสนอ exercise หลังจากเราทำงานต่อไปนี้เสร็จ:

• สร้างไฟล์หรือ module ใหม่
• เปลี่ยน database schema
• ตัดสินใจด้าน architecture หรือทำ refactor
• implement pattern ที่ไม่คุ้นเคย
• ช่วงที่เราถามคำถาม “ทำไม” ระหว่าง session

Claude จะถามว่า:

“Would you like to do a quick learning exercise on [หัวข้อนั้น]? About 10–15 minutes.”

เราสามารถปฏิเสธได้ตลอด และ Claude จะไม่เสนออีกในเซสชั่นนั้น (หรือถ้าทำ exercise ไปแล้ว 2 ครั้งในเซสชั่นเดียวกัน)

Exercise ทั้ง 6 แบบ พร้อมตัวอย่าง

Claude: "You just created a function using group_by() and summarise().
What do you predict will happen if one of the grouping variables
has NA values? (Take your best guess — wrong predictions are useful data.)"

[รอคำตอบเรา]

[หลังเราตอบ]
Claude: เดินผ่าน behavior จริงของ dplyr กับ NA ใน group_by()
แล้วถาม: "What surprised you about how dplyr handles this?"

Claude: "Before I show you how we're reading the GPS coordinates CSV,
sketch out how you'd approach validating that latitude is between
-90 and 90, and longitude between -180 and 180."

[รอคำตอบเรา — เราเขียน approach คร่าว ๆ]

[หลังเราตอบ]
Claude: แสดง implementation จริงที่ใช้ dplyr::filter() กับ between()
แล้วถาม: "What's similar to your approach? What did we handle differently?"

Claude: "We have a data frame with 1,000 rice field observations.
Severity scores are 0–4. We run: df |> filter(severity > 2) |>
group_by(province) |> summarise(mean_sev = mean(severity))

The data enters filter(). What happens next?"

[รอคำตอบเรา]

[หลังตอบ]
Claude: "Now it enters group_by(). What does group_by() actually
do to the data frame at this point?"

[รอคำตอบเรา]
...และเดินต่อไปทีละขั้น

# Claude แสดงโค้ดนี้:
calculate_disease_index <- function(incidence, severity) {
  (incidence * severity) / 100
}

Claude: "What would go wrong here if someone passes
incidence = 110 (which shouldn't be possible but might happen
from data entry errors)? Why is that a problem?"

[รอคำตอบเรา]

Claude: "How would you add input validation to prevent this?"

Claude: "Explain how our spatial join between disease survey points
and province boundaries works — as if you're onboarding
a new research assistant who knows R but hasn't seen this code."

[รอคำอธิบายของเรา]

Claude: [ให้ feedback ว่าอธิบายได้ดีตรงไหน และขาดอะไร]

Skill คู่หู: Learning Goal

Learning Goal Skill ออกแบบมาทำงานคู่กับ Learning Opportunities โดยตรง ถ้า Learning Opportunities คือ “how to practice” ตัวนี้คือ “what to learn and why”

ใช้เทคนิคที่เรียกว่า MCII (Mental Contrasting with Implementation Intentions) ซึ่งเป็น intervention ที่ Cat Hicks ทดสอบกับคนหลายร้อยคนในที่ทำงานจริง และวัดผลได้ว่าเพิ่ม behavioral follow-through ได้จริง

วิธีติดตั้ง

# 1. เพิ่ม marketplace
/plugin marketplace add https://github.com/DrCatHicks/learning-opportunities.git

# 2. ติดตั้ง plugin
/plugin install learning-opportunities@learning-opportunities

# 3. Restart Claude Code

/plugin install learning-opportunities-auto@learning-opportunities

/plugin marketplace add https://github.com/DrCatHicks/learning-goal.git
/plugin install learning-goal@learning-goal

วิธีปรับ Skill ให้เข้ากับงานของตัวเอง

Cat Hicks เขียนไว้ชัดเจนใน README ว่า Skill นี้ออกแบบมาให้ปรับได้ มีแนวทางดังนี้:

บอก Claude เรื่องระดับความรู้ของตัวเอง เพื่อให้ exercise เริ่มที่ระดับที่เหมาะสม เช่น เพิ่มใน CLAUDE.md ของ project:

## Learning Context
- ภาษา R: เชี่ยวชาญ เน้น tidyverse และ spatial analysis
- ภาษา Python: กำลังเรียนรู้ ยังต้องการคำอธิบาย syntax
- เป้าหมาย: เขียน geopandas workflow ได้โดยไม่ดู documentation

ปรับ trigger conditions ถ้าอยากให้ Claude เสนอ exercise ต่างจาก default เช่น เฉพาะเมื่อสร้างไฟล์ใหม่ ไม่ใช่ทุก refactor

เพิ่มจำนวน exercise สูงสุดต่อ session default คือ 2 ครั้ง ถ้าอยากเรียนมากกว่านั้นก็ได้

ใส่ domain-specific retrieval questions เช่น ถ้าทำงานด้านระบาดวิทยาโรคพืช อาจบอก Claude ว่าให้ถาม check-in เรื่อง spatial stats หรือ disease incidence formula

ตัวอย่าง Session จริง: สำหรับนักวิจัยที่ใช้ R

สมมติว่ากำลังสร้าง function วิเคราะห์ข้อมูลความรุนแรงของโรคในแปลงนา และเพิ่งเขียนเสร็จ

Claude เสนอ: > “You just implemented a disease severity calculator using weighted incidence. Would you like a quick learning exercise on how R handles the NA values in your severity scores? About 10–15 minutes.”

เลือก Yes:

Claude: “Before we test it — what do you predict will happen when severity_score contains NA and you run mean(severity_score)? (Take your best guess — wrong predictions are useful data.)”

[เราตอบ: "น่าจะคืน NA กลับมา"]

Claude: “Correct. Now — what do you predict mean(severity_score, na.rm = TRUE) will return, and is that always the right choice for your disease index calculation?”

[เราตอบ]

Claude: [อธิบาย implication ของ na.rm = TRUE ในบริบทของ disease index และถามต่อ]
“What would you do differently if NA meant ‘field not surveyed’ vs ‘data entry error’?”

นี่คือ exercise แบบ Prediction → Observation → Reflection ที่เชื่อม concept ทั่วไปกับบริบทงานจริงของเรา

ทำไม Skill นี้ถึงพิเศษกว่า Skill อื่น

Skills ส่วนใหญ่ในโลกของ Claude Code ออกแบบมาเพื่อให้ Claude ทำงานได้ ดีขึ้น หรือ ถูกต้องขึ้น

Learning Opportunities Skill ออกแบบมาเพื่อให้ เรา เรียนรู้ได้มากขึ้นระหว่างใช้ AI — นั่นคือเป้าหมายที่ต่างกันโดยพื้นฐาน

Cat Hicks เขียนไว้ใน README อย่างตรงไปตรงมาว่า Skill นี้จะ “รู้สึกต่างจาก highly fluent agentic coding” และนั่นคือตั้งใจ เพราะความ “ลื่น” คือสิ่งที่ทำให้เราไม่ได้เรียนรู้

สำหรับนักวิชาการหรือนักวิจัยที่อยากใช้ AI เป็นเครื่องมือแต่ยังอยากรักษาและพัฒนาทักษะที่แท้จริงไปด้วย — อันนี้คือคำตอบที่มีหลักวิทยาศาสตร์รองรับมากที่สุดที่พี่เจอมา

อ้างอิง

• DrCatHicks/learning-opportunities — GitHub repo (CC-BY 4.0)
• DrCatHicks/learning-goal — Learning Goal Skill (CC-BY 4.0)
• drcathicks.com — เว็บไซต์ Cat Hicks
• Fight for the Human newsletter — newsletter ของ Cat Hicks เรื่อง psychology of software teams
• Hicks, C.M. et al. (2025). The New Developer: AI Skill Threat, Identity Change & Developer Thriving. doi:10.31234/osf.io/2gej5_v2
• Soderstrom, N.C. & Bjork, R.A. (2015). Learning versus performance: An integrative review. Perspectives on Psychological Science, 10(2), 176–199.
• Dunlosky, J. et al. (2013). Improving students’ learning with effective learning techniques. Psychological Science in the Public Interest, 14(1), 4–58.

ANOVA มีประเภทด้วยหรือ แล้วมีกี่ประเภท แตกต่างกันอย่างไร

ในโลกของการวิเคราะห์สถิติ และถ้าไปเกี่ยวพันเข้ากับแบบจำลองเชิงเส้น การเข้าใจความแตกต่างของ ANOVA (Type I, II และ III) นั้นสำคัญมาก เพราะแต่ละประเภทจะแตกต่างกันที่ “วิธีการคำนวณค่า Sum of Squares (SS)” หรือการจัดสรรความแปรปรวนให้กับตัวแปรต่าง ๆ ในโมเดล โดยเฉพาะเมื่อบรบทของของข้อมูลที่ไม่สมดุล

1. Type I ANOVA (Sequential Sum of Squares)

หลักการ: เป็นการวิเคราะห์แบบ “ลำดับก่อนหลัง” (Sequential)

การทำงาน: โปรแกรมจะคำนวณนัยสำคัญของตัวแปรตามลำดับที่คุณใส่ในโมเดล เช่น หากคุณใส่โมเดลเป็น Yield ~ A + B โปรแกรมจะทดสอบอิทธิพลของ A ก่อน จากนั้นจึงทดสอบ B โดยดูว่า B ช่วยอธิบายความแปรปรวนที่เหลือจาก A ได้มากน้อยแค่ไหน

ข้อควรระวัง: ลำดับการใส่ตัวแปรมีผลมาก หากสลับที่กัน ค่าสถิติ (F-test และ p-value) อาจเปลี่ยนไปทันทีในกรณีที่ข้อมูลไม่สมดุล

เหมาะสำหรับ: งานวิจัยที่มีลำดับความสำคัญชัดเจน เช่น ต้องคุมตัวแปรสภาพแวดล้อมก่อนดูผลของพันธุ์ข้าว

2. Type II ANOVA (Hierarchical Sum of Squares) หลักการ: เป็นการวิเคราะห์แบบ “ลำดับชั้น” (Hierarchical) ที่ไม่ขึ้นกับลำดับการใส่ตัวแปร

การทำงาน: ทดสอบอิทธิพลหลัก (Main Effect) แต่ละตัวโดยคำนึงถึงอิทธิพลหลักตัวอื่น ๆ ในโมเดล แต่จะ ไม่พิจารณาปฏิสัมพันธ์ (Interaction)

จุดเด่น: ให้ผลลัพธ์ที่คงที่ไม่ว่าจะสลับลำดับตัวแปรอย่างไร เหมาะมากสำหรับโมเดลที่มีเฉพาะอิทธิพลหลัก (Main effects only)

3. Type III ANOVA (Marginal Sum of Squares)

หลักการ: เป็นการวิเคราะห์แบบ “ส่วนขอบ” (Marginal)

การทำงาน: ทดสอบอิทธิพลหลักแต่ละตัวโดยคำนึงถึงตัวแปรอื่น ๆ ทั้งหมด ในโมเดล รวมถึงปฏิสัมพันธ์ (Interaction) ด้วย

จุดเด่น: เป็นวิธีที่นิยมใช้ที่สุดเมื่อโมเดลมี Interaction (เช่น พันธุ์ x ปุ๋ย) และข้อมูลไม่สมดุล เพราะมีความทนทาน (Robust) ต่อลำดับของตัวแปรในโมเดล.

ผล ANOVA แตกต่างกัน เมื่อ

เพื่อให้คุณเห็นภาพชัดเจนว่าทำไมเราถึงต้องเลือกใช้ประเภทของ ANOVA ให้ถูกกาลเทศะครับ

ประเด็นสำคัญคือความแตกต่างของผลลัพธ์จะขึ้นอยู่กับ “ความสมดุลของข้อมูล” (Balance of Data) เป็นหลักครับ โดยสรุปได้ดังนี้:

1. ข้อมูลที่สมดุล (Balanced Datasets) สถานการณ์: คือการทดลองที่ทุกกลุ่ม (Treatment) มีจำนวนซ้ำเท่ากัน เช่น พันธุ์ข้าว A มี 4 ซ้ำ พันธุ์ B ก็มี 4 ซ้ำ

ผลลัพธ์: ในกรณีนี้ ANOVA ทั้ง 3 Type มักจะให้ผลลัพธ์ “เหมือนกัน” ดังนั้นคุณจะใช้คำสั่งไหนก็ได้ ผลสรุปงานวิจัยจะไม่ต่างกันครับ

2. ข้อมูลที่ไม่สมดุล (Unbalanced Datasets)ความต่างจะปรากฏชัดเจนเมื่อข้อมูลไม่สมดุล (เช่น บางซ้ำในบางแปลงเสียหายไป หรือเก็บข้อมูลได้ไม่เท่ากัน)
   • เรื่องลำดับของตัวแปร (Order of terms)
   • Type I: ผลลัพธ์จะ “เปลี่ยนไปตามลำดับ” ของตัวแปรที่คุณใส่ในโมเดล เช่น ถ้าคุณใส่ พันธุ์ข้าว + ปุ๋ย ผลอาจต่างจาก ปุ๋ย + พันธุ์ข้าว
   • Type II และ III: จะให้ผลลัพธ์ที่ “คงเดิมเสมอ” ไม่ว่าคุณจะสลับลำดับตัวแปรอย่างไร

• เรื่องปฏิสัมพันธ์ (Interactions)
  • Type III: จะทำการ “ปรับค่าอิทธิพลหลัก” (Adjust main effects) โดยคำนึงถึงอิทธิพลของปฏิสัมพันธ์ (Interaction) เข้าไปด้วย ทำให้ผลลัพธ์ของอิทธิพลหลัก (Main effect) มักจะต่างจาก Type II เมื่อโมเดลนั้นมีตัวแปรปฏิสัมพันธ์ (เช่น ) อยู่ด้วย
  • Type II: จะทดสอบอิทธิพลหลักโดยไม่พิจารณาปฏิสัมพันธ์

ตัวอย่าง

In this example, our model includes an interaction term between two factors, ‘N’ and ‘G’. As said before, Type III adjusts main effects for interactions, leading to different outcomes than Type II.

mod1 <- lm(yield ~ gen + block, data = dat)
mod2 <- lm(yield ~ block + gen, data = dat)

library(tidyverse)
library(broom)
library(car)

dat <- data.frame(
  gen = c(
    "st", "14", "26", "ci", "17", "wa", "22", "13", "st", "ci", "04", "15", "30",
    "03", "wa", "24", "st", "18", "27", "ci", "25", "28", "05", "wa", "st", "09",
    "06", "ci", "wa", "20", "11", "23", "st", "02", "21", "wa", "ci", "10", "08",
    "16", "st", "29", "07", "ci", "01", "wa", "12", "19"
  ),
  yield = c(
    2972L, 2405L, 2855L, 2592L, 2572L, 2608L, 2705L, 2391L, 3122L,
    3023L, 3018L, 2477L, 2955L, 3055L, 2477L, 2783L, 2260L, 2603L,
    2857L, 2918L, 2825L, 1903L, 2065L, 3107L, 3348L, 2268L, 2148L,
    2940L, 2850L, 2670L, 3380L, 2770L, 1315L, 1055L, 1688L, 1625L, 
    1398L, 1293L, 1253L, 1495L, 3538L, 2915L, 3265L, 3483L, 3013L,
    3400L, 2385L, 3643L),
  block = rep(c("I", "II", "III", "IV", "V", "VI"), each = 8L),
  row = c(
    1L, 2L, 3L, 4L, 5L, 6L, 7L, 8L, 1L, 2L, 3L, 4L, 5L, 6L, 7L,
    8L, 1L, 2L, 3L, 4L, 5L, 6L, 7L, 8L, 9L, 10L, 11L, 12L, 13L, 14L,
    15L, 16L, 9L, 10L, 11L, 12L, 13L, 14L, 15L, 16L, 9L, 10L, 11L,
    12L, 13L, 14L, 15L, 16L),
  col = rep(rep(1:3, 2), each = 8L)
)

# Define models
mod1 <- lm(yield ~ gen + block, data = dat)
mod2 <- lm(yield ~ block + gen, data = dat)

# Your get_p_values function
get_p_values <- function(mymodel, myterm, mytype) {
  if (mytype == "I") {
    x <- broom::tidy(stats::anova(mymodel))
  } else {
    x <- broom::tidy(car::Anova(mymodel, type = mytype))
  }
  x %>% filter(term == myterm) %>% pull(p.value)
}

# Define terms and types
terms <- c("gen", "block")
types <- c("I", "II", "III")
models <- list(mod1 = mod1, mod2 = mod2)

# Creating the combined tibble
crossing(model = names(models), term = terms, type = types) %>%
  rowwise() %>%
  mutate(
    p = get_p_values(models[[model]], term, type)
  ) %>%
  ungroup() %>% 
  pivot_wider(
    names_from = term,
    values_from = p
  )

ผล

# A tibble: 6 × 4
  model type       block     gen
  <chr> <chr>      <dbl>   <dbl>
1 mod1  I     0.000208   0.00911
2 mod1  II    0.000208   0.293  
3 mod1  III   0.000208   0.293  
4 mod2  I     0.00000576 0.293  
5 mod2  II    0.000208   0.293  
6 mod2  III   0.000208   0.293  

a Type I ANOVA there is a difference between the following two models, while for Type II and Type III it does not make a difference.

ในเคสของ Interaction กัน In this example, our model includes an interaction term between two factors, ‘N’ and ‘G’. As said before, Type III adjusts main effects for interactions, leading to different outcomes than Type II.

mod <- lm(yield ~ N + G + N:G, data = dat)

library(tidyverse)
library(broom)
library(car)

dat <- data.frame(
  N = c(
    "Koopa", "Peach", "Yoshi", "Koopa", "Peach", "Toad", "Toad", "Koopa", "Yoshi",
    "Goomba", "Toad", "Yoshi", "Yoshi", "Toad", "Koopa", "Peach", "Yoshi",
    "Koopa", "Goomba", "Goomba", "Diddy", "Koopa", "Goomba", "Goomba", "Toad",
    "Peach", "Yoshi", "Diddy", "Peach", "Diddy", "Peach", "Peach", "Koopa",
    "Diddy", "Koopa", "Goomba", "Toad", "Toad", "Yoshi", "Yoshi", "Diddy",
    "Yoshi", "Koopa", "Peach", "Diddy", "Diddy", "Diddy", "Goomba"
  ),
  G = c(
    "Simba", "Nala", "Pumba", "Timon", "Nala", "Nala", "Simba", "Simba", "Nala",
    "Nala", "Simba", "Simba", "Simba", "Pumba", "Nala", "Pumba", "Nala", "Nala",
    "Nala", "Simba", "Simba", "Pumba", "Pumba", "Timon", "Timon", "Timon", "Nala",
    "Nala", "Simba", "Pumba", "Timon", "Pumba", "Timon", "Timon", "Pumba",
    "Simba", "Pumba", "Simba", "Pumba", "Timon", "Nala", "Timon", "Simba",
    "Simba", "Timon", "Simba", "Simba", "Pumba"
  ),
  yield = c(
    6162, 6318, 1690, 4948, 5736, 7072, 6192, 5598, 6666, 5044, 7146, 7578, 7642,
    2504, 6682, 2338, 6324, 5316, 4034, 4030, 6600, 5372, 4216, 3554, 5970, 5684,
    7862, 6732, 9012, 5924, 7302, 1560, 6094, 5904, 4694, 4520, 5126, 6860, 1594,
    6392, 5738, 7260, 5256, 8548, 5974, 6794, 5806, 4212
  )
)

mod <- lm(yield ~ N*G, data = dat)

anova_type_I <- broom::tidy(stats::anova(mod)) %>%
  select(term, typeI = p.value)

anova_type_II <- broom::tidy(car::Anova(mod, type = "II")) %>% 
  select(term, typeII = p.value)

anova_type_III <- broom::tidy(car::Anova(mod, type = "III")) %>% 
  select(term, typeIII = p.value)

list(anova_type_I, anova_type_II, anova_type_III) %>% 
  reduce(full_join, by = "term") %>% 
  filter(term %in% c("N", "G", "N:G")) %>% 
  mutate(across(starts_with("type"), ~insight::format_p(., name = NULL)))

ผล

# A tibble: 3 × 4
  term  typeI  typeII typeIII
  <chr> <chr>  <chr>  <chr>  
1 N     < .001 0.001  0.019  
2 G     < .001 < .001 0.872  
3 N:G   < .001 < .001 < .001 

1. โหลด package ที่จำเป็น

# packages
pacman::p_load(
  tidyverse, # data import and handling
  conflicted, # handling function conflicts
  emmeans,
  multcomp,
  multcompView, # adjusted mean comparisons
  ggplot2,
  effectsize, # effect size calculation
  desplot, # for plotting experimental designs
  rstatix,
  ggdist,
  performance,
  see
) # plots

# conflicts between functions with the same name
conflict_prefer("filter", "dplyr")
conflict_prefer("select", "dplyr")

pacman::p_load เป็น package ที่ช่วยให้เราโหลด package ได้ง่ายขึ้น โดยไม่ต้องโหลดทีละตัว

tidyverse ช่วยจัดการข้อมูลได้ง่ายขึ้น conflicted ช่วยจัดการ function conflicts ซึ่ง เมื่อประกาศใช้ tidyverse แล้ว จะมี function ซ้ำกันหลายตัวกับ R base อยู่ เพื่อไม่ให้เกิดความขัดแย้งกันเองก็เลือกเลยว่าจะให้อะไรจาก package ไหน

emmeans ช่วยให้เราจัดการ adjusted mean comparisons ได้ง่ายขึ้น multcomp ช่วยให้เราจัดการ adjusted mean comparisons ได้ง่ายขึ้น multcompView ช่วยให้เราจัดการ adjusted mean comparisons ได้ง่ายขึ้น effectsize ช่วยให้เราจัดการ effect size calculation ได้ง่ายขึ้น

เพื่อตรวจสอบสมมุติฐานของ ANOVA

desplot ช่วยให้เราจัดการ for plotting experimental designs ได้ง่ายขึ้น

rstatix ช่วยให้เราจัดการ rstatix ได้ง่ายขึ้น

ggdist ช่วยให้เราจัดการ ggdist ได้ง่ายขึ้น

performance ช่วยให้เราจัดการ performance ได้ง่ายขึ้น

see ช่วยให้เราจัดการ see ได้ง่ายขึ้น

2. การนำเข้าข้อมูล

ตัวอย่างข้อมูลที่นำมาให้ใช้ เป็น ข้อมูลที่มาทำได้เป็นงานวิจัยทดสอบผลผลิตเมลอน ตีพิมพ์ Mead et al. (1993, p.52) โดยการทดลองมีพันธุ์เมลอน 4 พันธุ์ แต่ละพันธุ์ได้รับการทดสอบในแปลงทดลองจำนวน 6 แปลง ออกแบบการทดสอบแบบ สุ่มสมบูรณ์ (CRD) จาก “Example 4.3” หนังสือ “Quantitative Methods in Biosciences (3402-420)” by Prof. Dr. Hans-Peter Piepho

#| label : "Import data"
dataURL <- "https://raw.githubusercontent.com/SchmidtPaul/DSFAIR/master/data/Mead1993.csv"
dat <- read_csv(dataURL)
dat %>% head()

ผลลัพธ์ที่ได้

variety yield   row   col
   <chr>   <dbl> <dbl> <dbl>
 1 v1       25.1     4     2
 2 v1       17.2     1     6
 3 v1       26.4     4     1
 4 v1       16.1     1     4

และต่อไปเราเพื่อที่จะวิเคราะห์ ANOVA จะต้องแปลง variety ให้เป็น factor ก่อน

dat <- dat %>%
  mutate(variety = as.factor(variety))

ได้

# A tibble: 24 × 4
   variety yield   row   col
   <fct>   <dbl> <dbl> <dbl>
 1 v1       25.1     4     2
 2 v1       17.2     1     6
 3 v1       26.4     4     1
 4 v1       16.1     1     4

ขอดูกราฟก่อนว่า หน้าตาของข้อมูลเป็นอย่างไร

ggplot(data = dat, aes(y = yield, x = variety)) +
  geom_point() + # scatter plot
  ylim(0, NA) + # force y-axis to start at 0
  theme_classic() # clearer plot format

จากตรงนี้ก็พอจะเห็นอะไรบ้างว่าพันธุ์แต่ละพันธุ์นั้น มีแนวโน้มที่ให้ผลผลิตที่แตกต่างกัน

3. วิเคราะห์ ANOVA

อันนี้แหละ ที่เป้นประเด็น ในการเรื่องการวิเคราะห์ ANOVA Modern ANOVA = car::Anova(type = 3)

fit <- lm(yield ~ variety, data = dat)
car::Anova(fit, type = 3)

ถ้าเป็น code แบบ classic ก็ใช้ aov(yield ~ variety, data = dat) ซึ่ง ถ้าเป็น ปัจจุบันตอนนี้ เราจะนิยมและปลอดภัยสุด หรือ ANOVA type จาก Data Science for Agriculture in R

In most cases it’s probably best to conduct a Type III ANOVA, e.g. via car::Anova(model, type = "III").

classic ANOVA

แบบ ANOVA จาก R base ก็ใช้ได้เช่นกัน นะ

#| eval : false
aov.model <- aov(yield ~ variety, data = dat)
summary(aov.model)

ถ้า ไม่ sig เราก็ จะรายงาน เท่านี้ แต่ถ้าไม่ ส่วนใหญ่ เราก็จะไปทดสอบต่อ อย่างที่เรา เรียกกัน postpoc

performance::check_homogeneity(fit)
performance::check_homogeneity(fit) %>% plot()

performance::check_heteroscedasticity(fit)
performance::check_heteroscedasticity(fit) %>% plot()

performance::check_normality(fit)
performance::check_normality(fit) %>% plot()

check_outliers(fit) %>% plot()

effectsize::eta_squared(fit)
effectsize::omega_squared(fit)

post-hoc test

แม้ปัจจุบัน นักสถิติหลายคน ไม่ค่อย สนับสนุนให้ ทำ CLD(compact letter dusplay) เพราะว่า … แล้ว แต่ในสาขาเกษตรหรือชีววิทยา ก็ยังคงนิยมเพระาว่า ง่ายในการอธิบายผล ดังนั้น เราจะยังใช้

emm <- emmeans(fit, ~variety)
contrast(emm, "pairwise", adjust = "tukey")

mean_comparisons <- fit %>%
  emmeans(specs = "variety") %>%
  cld(adjust = "tukey", Letters = letters)

mean_comparisons

ggplot(mean_comparisons, aes(variety, emmean)) +
  ggdist::geom_pointinterval(
    aes(ymin = lower.CL, ymax = upper.CL)
  ) +
  labs(
    x = "Treatment",
    y = "Estimated mean (95% CI)",
    title = "CRD: EMMs + 95% CI"
  ) +
  theme_minimal(base_size = 13)

my_caption <- "Black dots = raw data (jittered). Red dots/bars = adjusted means with 95% CIs per variety. Letters share = not different (Tukey)."

ggplot() +
  aes(x = variety) +

  # จุดดิบ: jitter ป้องกันทับกัน + alpha ให้โปร่ง
  geom_point(
    data = dat,
    aes(y = yield),
    position = position_jitter(width = 0.08, height = 0),
    alpha = 0.6,
    size = 1.9
  ) +

  # ค่ากลางและช่วงเชื่อมั่น (ใช้ pointrange แทน point + errorbar แยก)
  geom_pointrange(
    data = mean_comparisons,
    aes(y = emmean, ymin = lower.CL, ymax = upper.CL),
    color = "red",
    fatten = 1.1,
    size = 0.6,
    position = position_nudge(x = 0.12)
  ) +

  # ตัวอักษร CLD: ขยับไปขวาอีกหน่อย และยกขึ้นเล็กน้อย
  geom_text(
    data = mean_comparisons,
    aes(y = emmean, label = .group),
    color = "red",
    position = position_nudge(x = 0.24),
    hjust = 0,
    vjust = -0.3,
    fontface = "bold",
    size = 3.6
  ) +

  # แกนและสเกล
  scale_x_discrete(name = "Variety", expand = expansion(mult = c(0.02, 0.22))) +
  scale_y_continuous(
    name = "Yield",
    limits = c(0, NA),
    expand = expansion(mult = c(0, 0.08))
  ) +

  # ธีมสะอาด + ระยะขอบเผื่อข้อความ
  theme_classic(base_size = 12) +
  theme(
    plot.margin = margin(t = 8, r = 24, b = 8, l = 8),
    axis.text.x = element_text(angle = 0, vjust = 1, hjust = 0.5),
    plot.caption = ggtext::element_textbox_simple(margin = margin(t = 6)),
    plot.caption.position = "plot"
  ) +
  labs(caption = my_caption) +
  coord_cartesian(clip = "off")

วิธีรายงานผล

รายงาน ความต่างเฉลี่ยที่สนใจ พร้อมค่า 95% CI และวิธี post-hoc test (เช่น Tukey) ใส่ขนาดเอฟเฟกต์ (เช่น partial η² หรือ ω²) เพื่อสื่อสาร

ทางออกเชิงปฏิบัติ: The “Concatenation” Strategy (Treatment Combination)

หากคุณต้องการความเรียบง่าย ประสิทธิภาพ และการสื่อสารที่ตรงไปตรงมากับผู้ทบทวนบทความ (Reviewers) วิธีที่ได้รับความนิยมสูงในวงการระบาดวิทยาภาคสนามคือการยุบรวมปัจจัย (Factor levels) ให้กลายเป็น “Single Treatment Factor”

วิธีนี้ช่วยให้เราหลีกเลี่ยงความยุ่งยากของ Non-parametric Interaction และมุ่งเน้นไปที่การเปรียบเทียบ “กลุ่มของปัจจัย” ที่ให้ผลดีที่สุดหรือแย่ที่สุดในทางระบาดวิทยาโดยตรง

ตัวอย่างการเขียน R Code สำหรับ Workflow นี้สมมติเราทดลองเรื่อง “ผลของสายพันธุ์พืช (A, B) และระดับความชื้น (High, Low) ต่อความรุนแรงของโรค”

# 1. โหลด Library ที่จำเป็น

library(tidyverse)
library(agricolae) # สำหรับงานเกษตรโดยเฉพาะ

# 2. จำลองข้อมูล (Data Simulation)
set.seed(123)
df <- data.frame(
  Variety = rep(c("V1", "V2"), each = 10),
  Moisture = rep(c("M1", "M2"), times = 10),
  Severity = c(rbeta(10, 2, 5), rbeta(10, 5, 2)) * 100 # ข้อมูลเบ้ (Non-normal)
)

# 3. สร้าง Column ใหม่โดยการ Concatenate (หัวใจของวิธีนี้)
df <- df %>%
  mutate(Trt_Combo = paste(Variety, Moisture, sep = "_"))

# 4. วิเคราะห์ด้วย Kruskal-Wallis (One-way approach)
# เหมือนเราทำ CRD ปกติ
k_test <- kruskal(df$Severity, df$Trt_Combo, alpha = 0.05, p.adj = "bonferroni", group = TRUE)

# 5. ดูผลลัพธ์
print(k_test$statistics) # ค่าสถิติภาพรวม
print(k_test$groups)     # การจัดกลุ่มตัวอักษร (abc)

แม้ว่าวิธี Concatenation จะสะดวก แต่มีข้อแนะนำเพิ่มเติม 3 ประการ:

• Lose of Main Effects: การรวมปัจจัยทำให้คุณเสียความสามารถในการแยกแยะ “Main Effect” ของแต่ละปัจจัยอย่างชัดเจน (เช่น จะบอกไม่ได้ว่าโดยภาพรวมแล้ว Variety A ดีกว่า B แค่ไหน ถ้าไม่ดู Moisture ประกอบ)

• When to use GLM: หากข้อมูลของคุณเป็นสัดส่วน (Proportion/Percentage) ปัจจุบันวงการระบาดวิทยาสมัยใหม่ (เช่น งานของ Garrett หรือ Sparks) นิยมใช้ Beta Regression หรือ GLM with Logit Link ซึ่งรองรับ Factorial และข้อมูล Non-normal ได้ดีกว่าการใช้ Non-parametric แบบดั้งเดิม

• Visualization is Key: การพล็อตข้อมูลจริง (Raw data) ซ้อนทับกับ Boxplot จะช่วยให้ Reviewer เห็นภาพการกระจายของโรคได้ชัดเจนกว่าค่า Rank เพียงอย่างเดียว

4 สถานการณ์ที่ไม่แนะนำให้ใช้ DMRT อย่างเด็ดขาด

1. การทดลองที่มี “จำนวนทรีตเมนต์ (Treatments) เยอะเกินไป”

   นี่คือจุดบอดที่ใหญ่ที่สุดของ DMRT ครับ DMRT ไม่สามารถควบคุม Experiment-wise Error Rate ได้ดีเท่าวิธีอื่น

   • ทำไมถึงห้าม: ยิ่งคุณมีทรีตเมนต์เยอะ (เช่น เทียบข้าว 10 สายพันธุ์) โอกาสที่ DMRT จะบอกว่า “พันธุ์ที่ 1 กับพันธุ์ที่ 10 ต่างกัน” ทั้งที่จริงๆ มันแค่บังเอิญ จะพุ่งสูงขึ้นทะลุหลัก 10-20% (ทั้งที่คุณตั้ง ไว้ที่ 0.05)
   • ทางออกที่ถูกต้อง: ถ้ามีทรีตเมนต์เยอะ (เกิน 5-6 กลุ่มขึ้นไป) Tukey’s HSD คือมาตรฐานทองคำ (Gold Standard) ที่นักสถิติทั่วโลกยอมรับครับ เพราะ Tukey ควบคุม Type I Error ได้ชะงัดนัก

2. ข้อมูลที่มี “จำนวนซ้ำไม่เท่ากัน” (Unbalanced Data)

   สมมติว่าคุณวางแผนไว้ 4 ซ้ำ (Replications) เท่ากันหมด แต่ตอนเก็บข้อมูลดันมีหนูกัดต้นข้าวตายไป 1 แปลง ทำให้บางทรีตเมนต์เหลือ 3 ซ้ำ

   • ทำไมถึงห้าม: สูตรดั้งเดิมของ DMRT ถูกสร้างมาบนสมมติฐานว่าตัวอย่างต้องเท่ากันเป๊ะ (Balanced design) แม้ซอฟต์แวร์บางตัวจะยอมคำนวณให้ (โดยใช้ Harmonic mean มาชดเชย) แต่ค่าความคลาดเคลื่อนจะสูงมาก และผลมักจะเพี้ยน
   • ทางออกที่ถูกต้อง: ควรใช้ Least Square Means (LSMeans) หรือ Tukey-Kramer Test ซึ่งออกแบบมาเพื่อจัดการกับ Unbalanced data โดยเฉพาะ

3. เมื่อเปรียบเทียบทุกกลุ่มกับ “กลุ่มควบคุม (Control)” เท่านั้น

   ถ้าจุดประสงค์ของงานวิจัยคุณ ไม่ได้อยากรู้ว่า ปุ๋ยสูตร A ต่างกับ B ไหม แต่อยากรู้แค่ว่า ปุ๋ยสูตร A, B, C, D ต่างจาก “ไม่ใส่ปุ๋ย (Control)” ไหม

   • ทำไมถึงห้าม: การใช้ DMRT (หรือ Tukey) จะเป็นการเปรียบเทียบแบบ “จับคู่ทุกคู่” (All pairwise) ซึ่งเป็นการสูญเสีย Power ของสถิติไปโดยเปล่าประโยชน์ และทำให้ตรวจสอบความต่างกับ Control ได้ยากขึ้น
   • ทางออกที่ถูกต้อง: ต้องใช้ Dunnett’s Test ครับ สถิติตัวนี้เกิดมาเพื่อเทียบ Treatment ทุกตัวกับ Control โดยเฉพาะ และให้ผลที่แม่นยำกว่ามาก

4. งานวิจัยสายการแพทย์ หรือที่ต้องการความเข้มงวดสูง (Strict Control)

   ถ้าคุณเอา DMRT ไปใช้ในการทดสอบยารักษาโรค หรือการทดสอบสารเคมีตกค้างที่มีผลต่อความปลอดภัยของมนุษย์ เปเปอร์ของคุณมีโอกาสถูกตีตกสูงมากครับ

   • ทำไมถึงห้าม: เพราะวงการนี้รับความเสี่ยงเรื่อง Type I Error ไม่ได้ การที่ DMRT บอกว่ายาสองตัวให้ผลต่างกัน ทั้งที่ความจริงไม่ต่าง อาจหมายถึงความเป็นความตายหรือต้นทุนมหาศาล
   • ทางออกที่ถูกต้อง: ใช้ Bonferroni correction หรือ Tukey’s HSD ครับ