ไดอะแกรมที่เชื่อมโยงกับโค้ด
Eraser และ Whimsical วาดกล่องสวย ๆ ได้ แต่สุดท้ายวิศวกรของคุณก็ยังสร้างสิ่งที่พอจะทันเดดไลน์อยู่ดี ไดอะแกรมของ Bob จะกลายเป็นโครงสร้างไฟล์และขอบเขตของโมดูลที่ Alex ใช้งานจริงใน codebase
Bob·Architectเอเจนต์สถาปนิก AI ที่ออกแบบระบบให้ทีมของคุณสร้าง
Bob วาดระบบ เลือกสแตก และส่งมอบโครงสร้างให้ Alex เพื่อให้สถาปัตยกรรมของคุณกลายเป็นโค้ดเบส ไม่ใช่เอกสารที่ถูกลืม
แผนภาพที่สอดคล้องกับโค้ด ไม่ใช่แค่ภาพสวยๆ
ได้รับความไว้วางใจจากบิลเดอร์ที่
เหตุใดเอกสารสถาปัตยกรรมจึงล้าสมัยตั้งแต่วันที่เขียน
ไดอะแกรมสวยแต่ไม่มีใครนำไปใช้จริง
Eraser และ Whimsical สร้างกล่องและลูกศรที่สวยงาม แต่วิศวกรของคุณก็ยังสร้างอะไรก็ตามที่พอจะทันเดดไลน์อยู่ดี ไดอะแกรมของ Bob กลายเป็นโครงสร้างไฟล์และขอบเขตของโมดูลที่ Alex ใช้งานจริง
เลือกสแตกตามกระแส
"เราเลือก Mongo เพราะมันกำลังนิยม" Bob อธิบายว่าทำไมถึงเลือก Postgres แทน Mongo ทำไมถึงใช้ queue แทน direct calls และทำไม Redis vs Memcached เหตุผลทั้งหมดถูกเขียนไว้เป็นลายลักษณ์อักษร เพื่อให้คุณสามารถตั้งคำถามกับมันได้
สถาปัตยกรรมกับโค้ดค่อยๆ แยกจากกัน
ไดอะแกรมในวิกิเป็นของ sprint 1 แต่โค้ดเป็นของ sprint 14 ไม่มีใครอัปเดตอย่างใดอย่างหนึ่งให้ตรงกัน Bob ตรวจทานระบบปัจจุบันและอัปเดตเอกสารสถาปัตยกรรมให้สะท้อนสิ่งที่ถูกส่งมอบจริง
ความต้องการที่ไม่ใช่เชิงฟังก์ชันถูกพบหลังเปิดใช้งาน
Performance, security และ observability ถูกนำมาเสริมทีหลังหลังจาก outage แรก Bob วางแผนสิ่งเหล่านี้ตั้งแต่ขั้นออกแบบ โดยอิงตามข้อกำหนดด้านการขยายระบบของ Emma และรูปแบบการเข้าถึงที่ data model ของคุณต้องรองรับ
หนึ่งวันกับ Bob
ตั้งแต่พรอมป์แรกของคุณไปจนถึงผลลัพธ์ที่พร้อมปล่อยใช้งาน — นี่คือวิธีที่ Bob ทำงานจริง
- 01
อ่าน PRD ของ Emma
Bob เริ่มจากขอบเขตที่จำกัด เพื่อให้สถาปัตยกรรมสอดคล้องกับผลิตภัณฑ์ ไม่ใช่กลับกัน
ส่งต่องานให้ Emma - 02
เลือกสแตกด้วยเหตุผลที่ชัดเจน
ฐานข้อมูล เฟรมเวิร์ก คิว แคช — ทุกตัวเลือกมาพร้อมคำอธิบายข้อแลกเปลี่ยนเป็นลายลักษณ์อักษรที่คุณสามารถโต้แย้งได้
- 03
ทำแผนผังโมเดลข้อมูลและขอบเขตของโมดูล
เอนทิตี ความสัมพันธ์ ความเป็นเจ้าของ เส้นทางการเขียน — สิ่งที่เจ็บปวดเมื่อต้องมารีแฟกเตอร์ทีหลัง
- 04
วาดไดอะแกรมระบบที่สอดคล้องกับโค้ด
กล่องและลูกศรสะท้อนโมดูลและการพึ่งพาที่เกิดขึ้นจริง โดยไดอะแกรมจะซิงค์อยู่เสมอเมื่อมีการเพิ่มโค้ด
- 05
ส่งโครงสร้างให้ Alex
Alex สร้างงานภายในขอบเขตที่ Bob วางไว้ — ไม่มีหนี้เทคนิคแบบ "เดี๋ยวอีกสามเดือนค่อยรีแฟกเตอร์" ฝังมาแต่ต้น
ส่งต่องานให้ Alex
ทุกสิ่งที่ Bob ต้องการเพื่อออกแบบระบบที่มั่นคง
แผนภาพสถาปัตยกรรม
แผนภาพบริการ การไหลของข้อมูล และการผสานรวมที่สร้างใน Editor ไม่ใช่ในเครื่องมือแยกต่างหาก
คำแนะนำด้านเทคโนโลยีสแตก
ตัวเลือกสแตกที่มีเหตุผลรองรับตามข้อจำกัดของคุณ ไม่ได้เลือกตามกระแสหรือความคุ้นเคย
การออกแบบโมเดลข้อมูล
สคีมาและความสัมพันธ์ที่ออกแบบตามรูปแบบการเข้าถึงจริงของผลิตภัณฑ์ของคุณ
การวางแผนด้านที่ไม่ใช่ฟังก์ชัน
ประสิทธิภาพ ความปลอดภัย และการสังเกตการณ์ถูกนำมาพิจารณาตั้งแต่ขั้นตอนการออกแบบ ไม่ใช่หลังเปิดใช้งาน
บันทึกการตัดสินใจ
การตัดสินใจด้านสถาปัตยกรรมถูกบันทึกเป็นลายลักษณ์อักษรพร้อมเหตุผล เพื่อให้ตัวคุณในอนาคตสามารถย้อนกลับมาทบทวนได้
การแมประหว่างโครงสร้างกับโค้ด
แผนภาพเชื่อมโยงกับโครงสร้างไฟล์และขอบเขตของโมดูลที่ Alex ใช้สร้าง
การทบทวนสถาปัตยกรรม
Bob สามารถทบทวนระบบที่มีอยู่และแนะนำการเปลี่ยนแปลงพร้อมเหตุผลที่ชัดเจน
อะไรจะเปลี่ยนไปเมื่อ Bob อยู่ในทีมของคุณ
เวิร์กโฟลว์ที่ประกอบขึ้นเองแบบแมนนวลนั้นช้า ต้องใช้แรงคน และพึ่งพาเครื่องมือมากเกินไป ลากเมาส์ไปเหนือการ์ดใดก็ได้เพื่อดูว่าทำไมแต่ละประโยชน์จึงสำคัญ
ทำไมเหล่าบิลเดอร์จึงเลือก Bob แทนตัวเลือกอื่น
เปรียบเทียบกับ
ย้ายมาจาก Eraser AI ใช่ไหม? นี่คือจุดที่ Bob เหนือกว่า
เลือกสแตกด้วยเหตุผล ไม่ใช่กระแส
ChatGPT จะแนะนำเฟรมเวิร์กที่มันพบเห็นบ่อยที่สุดในข้อมูลฝึกสอน ส่วน Bob จะอธิบายว่าทำไมต้อง Postgres แทน Mongo ทำไมต้องใช้คิวแทนการเรียกตรง ทำไมต้อง Redis แทน Memcached — พร้อมเหตุผลที่คุณโต้แย้งได้ และการตัดสินใจที่คุณกลับมาทบทวนได้
สถาปัตยกรรมที่คงความทันสมัยอยู่เสมอ
ไดอะแกรมในวิกิมักล้าสมัยภายในสปรินต์ที่ 3 Bob ตรวจสอบโค้ดจริงและอัปเดตสถาปัตยกรรมให้ตรงกับสิ่งที่ส่งมอบไปแล้ว — ดังนั้นเอกสารจึงไม่กลายเป็นเรื่องเพ้อฝัน และการออนบอร์ดวิศวกรใหม่ใช้เวลาเพียง 1 วัน ไม่ใช่ 1 เดือน
Atoms เทียบกับ Eraser AI: เปรียบเทียบฟีเจอร์ ราคา และความสามารถ
| ฟีเจอร์ | Atoms แนะนำ | Eraser AI |
|---|---|---|
| ผลลัพธ์ | สถาปัตยกรรมที่ถ่ายทอดเป็นโค้ดได้ | ไดอะแกรมในวิกิ |
| การเลือกสแตกอย่างมีเหตุผล | การแลกเปลี่ยนที่เขียนไว้เป็นลายลักษณ์อักษร | คำแนะนำทั่วไป |
| ซิงก์อยู่เสมอเมื่อโค้ดถูกปล่อย | รีเฟรชตามโค้ดเบสแล้ว | ล้าสมัยภายในสปรินต์ 3 |
| เชื่อมต่อกับทีมวิศวกรรม | ส่งต่องานให้ Alex | ส่งต่องานผ่านการส่งออก |
| การสร้างไดอะแกรม | สร้างโดยอัตโนมัติ | สร้างโดยอัตโนมัติ |
Bob ทำงานร่วมกับทีม AI ที่เหลือของคุณอย่างไร
Bob ไม่ได้ทำงานเพียงลำพัง นี่คือวิธีที่การส่งต่องานเกิดขึ้นเมื่อคุณสร้างร่วมกับทีมครบชุด
BobAlex
Bob ออกแบบระบบ ส่วน Alex เป็นคนสร้าง โดยไม่มีหนี้เทคนิคที่ฝังมาล่วงหน้าแบบ "ค่อยรีแฟกเตอร์ในอีก 6 เดือนเมื่อระบบเริ่มสเกล"
ดูวิธีการ Alex ใช้งานได้BobEmma
Bob ปรับสถาปัตยกรรมให้สอดคล้องกับขอบเขตผลิตภัณฑ์ของ Emma ไม่มีระบบที่ออกแบบเกินความจำเป็นสำหรับฟีเจอร์ง่าย ๆ
ดูวิธีการ Emma ใช้งานได้BobDavid
Bob ออกแบบโมเดลข้อมูลเพื่อให้ David สามารถคิวรีได้อย่างเป็นระเบียบ การวิเคราะห์เป็นองค์ประกอบหลัก ไม่ใช่ส่วนเสริม
ดูวิธีการ David ใช้งานได้สิ่งที่ Bob ออกแบบสำหรับผู้สร้าง
งานสถาปัตยกรรมคอนกรีตที่ Bob สร้างขึ้นซึ่งเชื่อมโยงกับโค้ดจริง
- ออกแบบระบบ
การออกแบบระบบ Greenfield
ออกแบบระบบตั้งแต่เริ่มต้นพร้อมให้เหตุผลในการเลือกสแต็กตามข้อจำกัดของคุณ
- เลือกสแต็ก
การเลือกสแต็ก
เปรียบเทียบตัวเลือกสแต็กสำหรับโปรเจกต์ของคุณและเลือกสิ่งที่เหมาะกับทีมและขนาดการใช้งานของคุณ
- ออกแบบสคีมา
การออกแบบโมเดลข้อมูล
ออกแบบสคีมา ความสัมพันธ์ และดัชนีให้เหมาะกับคิวรีที่ผลิตภัณฑ์ของคุณจะใช้งานจริง
- แมปการผสานรวม
การแมปการผสานรวม
วางแผนบริการจากภายนอก เว็บฮุก และการไหลของข้อมูลก่อนเริ่มงานผสานรวม
- วางแผนรองรับการขยาย
แผนประสิทธิภาพและการขยายระบบ
ระบุคอขวดและวางแผนสำหรับการเติบโตในระดับถัดไปก่อนที่จะกระทบกับระบบ production
- ทบทวนความปลอดภัย
การทบทวนด้านความปลอดภัยและการปฏิบัติตามข้อกำหนด
ระบุประเด็นด้านการยืนยันตัวตน ข้อมูล และความเป็นส่วนตัว และจัดการตั้งแต่ขั้นออกแบบแทนที่จะรอหลังเปิดใช้งาน
ลองใช้พรอมต์เหล่านี้กับ Bob
ออกแบบระบบตั้งแต่ต้น
@Bob ออกแบบสถาปัตยกรรมสำหรับ SaaS แบบหลายผู้เช่าที่มีการคิดค่าบริการตามการใช้งาน รองรับผู้เช่าที่คาดไว้ 10k ราย และการจ่ายเงินผ่าน Stripe Connect เลือกสแตก วาดไดอะแกรมบริการ และส่งมอบโครงสร้างไฟล์ให้ Alex
เลือกสแตกพร้อมเหตุผลประกอบ
@Bob เรากำลังเลือกระหว่าง Postgres + Prisma และ PlanetScale + Drizzle สำหรับผลิตภัณฑ์ใหม่ เปรียบเทียบทั้งสองตัวตามข้อจำกัดของเรา (การอ่านหลายภูมิภาค, วิศวกรคนเดียว, 100ms p95) และแนะนำหนึ่งตัวพร้อมระบุข้อแลกเปลี่ยนอย่างชัดเจน
ทบทวนสถาปัตยกรรมที่มีอยู่
@Bob ตรวจสอบเลเยอร์ API ปัจจุบันของเรา ขณะนี้เราเห็นค่า p95 ที่ 800ms บน dashboard endpoint และต้องการขยายให้รองรับทราฟฟิกเพิ่มขึ้น 10 เท่า ระบุคอขวด เสนอการเปลี่ยนแปลง และเขียนแผนการย้ายระบบให้ Alex
ออกแบบโมเดลข้อมูลสำหรับฟีเจอร์
@Bob ออกแบบสคีมาสำหรับโปรแกรมแนะนำต่อใน PRD ของ Emma จัดทำแมปเอนทิตี ความสัมพันธ์ และดัชนีสำหรับคิวรีที่เราจะใช้งานจริง ส่งมอบสคีมาและแผน migration ให้ Alex
พบกับสมาชิกทีม AI คนอื่น ๆ ของ Bob
ไม่มีเอเจนต์คนไหนทำงานลำพัง แตะเพื่อนร่วมทีมคนใดก็ได้เพื่อดูว่าพวกเขาจัดการส่วนของผลิตภัณฑ์ของคุณอย่างไร
คำถามที่พบบ่อย
ให้บ๊อบลงมือทำงาน
เลิกวาดไดอะแกรมที่ไม่มีใครนำไปใช้จริง ให้ Bob ออกแบบระบบที่ทีม AI ของคุณสามารถสร้างและซิงก์ให้ตรงกันภายใน Atoms ได้
