# email-design.md: ส่งบรีฟแบรนด์ให้เอเจนต์อีเมล

URL หลัก: https://brew.new/th/blog/email-design-md
ผู้เขียน: Thomas Park
เผยแพร่: 2026-06-15
อัปเดต: 2026-09-28

รหัสสี hex บอกเอเจนต์อีเมลได้ว่าต้องใช้สีน้ำเงินเฉดไหน แต่ไม่ได้บอกว่าทำไมแบรนด์จึงวางป้ายตัวอักษร monospace ขนาดเล็กไว้เหนือพาดหัวทุกอัน หรือทำไมเส้นแบ่งจึงเป็นเส้นบาง ๆ แทนที่จะเป็นกรอบ

นั่นคือปัญหาของโมเดลแบรนด์รุ่นแรกที่เราใช้ใน Brew เราเก็บค่าต่าง ๆ ไว้มากมาย แต่ก็ยังพลาดรายละเอียดที่ทำให้คนจำแบรนด์ได้

## ออบเจ็กต์มีฟิลด์สำหรับแทบทุกอย่าง

ตอนเริ่มต้น เรามองแบรนด์เป็นข้อมูลแบบมีโครงสร้าง เราสร้างโมเดลของสี ตัวอักษร แอสเซต และคุณสมบัติด้านสไตล์อีกจำนวนมาก ครอว์เลอร์เติมข้อมูลลงในฟิลด์ต่าง ๆ จากนั้นขั้นตอนการสร้างอีเมลก็รวบรวมฟิลด์เหล่านั้นเป็นบริบทให้เอเจนต์อีเมล

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

นักออกแบบจะเขียนคู่มือ โดยใส่ค่าที่แน่นอนในจุดที่สำคัญ ใส่ตัวอย่างในจุดที่ช่วยให้เข้าใจ และเขียนอธิบายเหตุผลของการตัดสินใจต่าง ๆ ไว้ระหว่างนั้น

เราจึงเปลี่ยนสิ่งที่ให้เอเจนต์ดึงข้อมูลแบรนด์สร้างขึ้นมา

## เอกสารนี้คือบรีฟ

เราเรียกเอกสารนี้ว่า `email-design.md` ซึ่งเป็นเอกสาร Markdown ที่แก้ไขได้ และอธิบายว่าแบรนด์หนึ่ง ๆ ควรปรากฏในอีเมลอย่างไร

นี่คือตัวอย่างสมมติแบบย่อ:

```markdown
# Acme email design

## Voice

Write for engineers who want the setup instructions first.
Use short explanations and name the product action precisely.

## Signature details

- Put a small monospace label above the main headline.
- Use thin dividers between sections, without drop shadows.
- Reserve the accent color for the primary action.
- Use one product screenshot when it explains the task.

## Assets

Use the approved logo URL from the asset list.
Do not invent product images or customer logos.
```

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

![Brew แสดงไฟล์ email-design.md ที่แก้ไขได้ข้างบทสนทนาเรื่องแบรนด์](/blog/email-design-md-editor.png)

*คำแนะนำเรื่องแบรนด์มองเห็นได้ชัด และการแก้ไขแต่ละครั้งจะกลายเป็นส่วนหนึ่งของบรีฟครั้งถัดไป*

Markdown มีประโยชน์ในกรณีนี้เพราะคนอ่านและแก้ไขได้โดยไม่ต้องใช้ฟอร์มพิเศษ หัวข้อทำให้เอกสารมีโครงสร้าง และการเพิ่มกฎการออกแบบใหม่ก็ไม่ต้องเพิ่มฟิลด์ในฐานข้อมูล นี่เป็นการเลือกรูปแบบไฟล์ด้วยเหตุผลเชิงปฏิบัติ ไม่ได้อ้างว่า Markdown ใช้โทเค็นน้อยกว่า JSON เสมอ หรือว่าทุกโมเดลถูกฝึกด้วย Markdown เป็นหลัก

## อีเมลต้องมีคำแนะนำการออกแบบของตัวเอง

เว็บไซต์กับอีเมลมีข้อจำกัดในการแสดงผลต่างกัน การรองรับฟอนต์ เลย์เอาต์ และโหมดมืดแตกต่างกันไปในแต่ละแอปอีเมล ดีไซน์ที่ดูถูกต้องในตัวอย่างบนเบราว์เซอร์จึงยังต้องทดสอบในอินบ็อกซ์จริง

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

ภาพมีข้อกำหนดที่ต่างออกไป Brew จึงใช้ `image-style.md` สำหรับคำแนะนำเรื่องรูปภาพด้วย การแยกสองเรื่องนี้ออกจากกันให้ชัดเจนง่ายกว่าการให้รายการโทเค็นดีไซน์ชุดเดียวอธิบายทุกสื่อ

## เริ่มจากข้อมูลที่คุณเชื่อถืออยู่แล้ว

เว็บไซต์ที่ใช้งานอยู่เป็นหลักฐานที่มีประโยชน์ แต่ไม่ได้เป็นแหล่งอ้างอิงที่ถูกต้องที่สุดเสมอไป เว็บไซต์อาจมีแคมเปญเก่าหรือสไตล์ที่ทีมแบรนด์เคยลองแล้วเลิกใช้ไปแล้ว

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

![ฟอร์มตั้งค่าแบรนด์ที่มีช่องกรอกเว็บไซต์และพื้นที่สำหรับไฟล์ประกอบ](/blog/email-design-md-ingest.png)

*โดเมนและไฟล์ที่อนุมัติแล้วให้หลักฐานคนละแบบแก่กระบวนการดึงข้อมูลแบรนด์*

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

## สิ่งที่การเปลี่ยนแปลงนี้พิสูจน์ได้และพิสูจน์ไม่ได้

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

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

อีเมลที่สร้างขึ้นยังต้องผ่านการตรวจทั้งข้อเท็จจริงและหน้าตา ให้อ่านคำกล่าวอ้างเทียบกับบรีฟ ทดสอบลิงก์ และตรวจผลลัพธ์ในอินบ็อกซ์ [คู่มือการบรีฟอีเมล](/th/blog/how-to-brief-an-email-agent)อธิบายการส่งต่องานช่วงนี้ไว้

## เอเจนต์ที่เชื่อมต่อก็ใช้บริบทเดียวกันได้

[เซิร์ฟเวอร์ MCP](/th/mcp) ของ Brew พร้อมใช้งานแล้ว ผู้ช่วย AI ที่รองรับทำงานกับ Brew ผ่านเครื่องมือที่มีเอกสารกำกับได้ โดยใช้ข้อมูลแบรนด์ชุดเดียวกับในแอป [ประกาศเปิดตัว MCP](/th/blog/brew-mcp) และ[เอกสารการตั้งค่า](https://docs.brew.new/api-reference/mcp/overview)อธิบายวิธีเชื่อมต่อไว้

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