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

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

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

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

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

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

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

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

เราเรียกเอกสารนี้ว่า email-design.md ซึ่งเป็นเอกสาร 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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

เซิร์ฟเวอร์ MCP ของ Brew พร้อมใช้งานแล้ว ผู้ช่วย AI ที่รองรับทำงานกับ Brew ผ่านเครื่องมือที่มีเอกสารกำกับได้ โดยใช้ข้อมูลแบรนด์ชุดเดียวกับในแอป ประกาศเปิดตัว MCP และเอกสารการตั้งค่าอธิบายวิธีเชื่อมต่อไว้

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