Output style: đổi giọng và cách trình bày của agent

Trả lời nhanh: Cách trình bày kết quả (output style) là phần cấu hình đổi giọng và định dạng trả lời của agent, độc lập với việc nó làm gì. Ba trường hợp đáng chỉnh: bạn muốn ngắn gọn hơn vì đã quen việc và không cần giải thích dài; bạn cần kết quả theo mẫu cố định để dán thẳng vào tài liệu công ty; hoặc bạn đang hướng dẫn người mới và muốn nó giải thích kỹ hơn. Đây là thay đổi nhỏ nhưng cảm nhận rõ trong công việc hằng ngày.

Nhiều người khó chịu vì agent giải thích quá dài trước khi vào việc, nhưng lại nghĩ đó là điều không đổi được. Thực ra đổi được, và với người dùng cả ngày thì việc cắt bớt phần thừa cộng dồn thành khác biệt đáng kể. Bài này nói cách chỉnh và những chỗ không nên chỉnh.

Cách trình bày khác gì với luật dự án

Phân biệt cho rõ ba thứ hay bị gộp:

• File quy ước dự án nói agent phải tuân theo chuẩn nào khi viết code, theo bài CLAUDE.md.
• Skill dạy nó quy trình làm một việc cụ thể.
• Cách trình bày chỉ đổi hình thức trả lời: dài hay ngắn, có giải thích hay không, theo mẫu nào.

Nói cách khác, hai thứ đầu ảnh hưởng tới chất lượng công việc, thứ thứ ba ảnh hưởng tới trải nghiệm đọc của bạn. Đừng dùng cách trình bày để ép chất lượng, và đừng nhét quy ước code vào đó.

Ba kiểu đáng dùng

Kiểu gọn cho người quen việc. Bỏ phần mở đầu và phần tóm tắt lại việc vừa làm, đi thẳng vào kết quả và những gì cần bạn quyết.

Trả lời thật gọn. Không mở đầu, không tóm tắt lại yêu cầu.Sau khi sửa xong, chỉ liệt kê file đã đổi kèm một dòng mô tả.Nêu ngay những chỗ cần tôi quyết, đặt ở đầu chứ không ở cuối.Vẫn giữ nguyên phần cảnh báo rủi ro nếu có.

Kiểu giải thích cho người mới. Hợp khi bạn dùng agent để học một phần công nghệ chưa quen, hoặc khi hướng dẫn thành viên mới.

Giải thích vì sao chọn cách này trước khi đưa code.Với mỗi khái niệm lạ, thêm một câu định nghĩa ngắn.Cuối câu trả lời, gợi ý một chỗ tôi nên đọc thêm trong chính repo.

Kiểu theo mẫu công ty. Hữu ích khi kết quả sẽ được dán vào tài liệu chung, ví dụ mô tả thay đổi hay báo cáo rà soát.

Định dạng theo mẫu để dán thẳng

Đây là kiểu tiết kiệm thời gian nhất mà ít người dùng tới. Nếu đội bạn có mẫu mô tả thay đổi cố định, hãy khai báo nó:

Khi tôi yêu cầu viết mô tả thay đổi, dùng đúng mẫu này: ## Mục đích(một đoạn ngắn, nói vấn đề chứ không nói giải pháp) ## Thay đổi chính(danh sách gạch đầu dòng, mỗi dòng một thay đổi) ## Ảnh hưởng(phần nào của hệ thống bị ảnh hưởng, có cần chạy migration không) ## Cách kiểm thử(các bước để người xem lại tự kiểm chứng)

Kết quả ra đúng khuôn, dán thẳng vào hệ thống quản lý mã nguồn không phải sửa. Nếu bạn làm việc này hằng ngày, hãy gói thành một lệnh tắt theo bài về lệnh tắt, khi đó chỉ cần gõ một chữ.

Những gì không nên cắt

Khi chỉnh cho gọn, dễ cắt nhầm những phần thật sự quan trọng:

• Cảnh báo rủi ro. Khi agent nói thay đổi này có thể ảnh hưởng tới dữ liệu hiện có, đó chính là câu bạn cần đọc.
• Những chỗ nó không chắc. Rất giá trị vì đó là nơi bạn nên kiểm lại.
• Danh sách file đã sửa. Không có nó thì bạn không biết phạm vi thay đổi mà xem lại.
• Câu hỏi làm rõ. Nếu bạn ép nó không được hỏi, nó sẽ tự đoán, và đoán sai thì tốn hơn nhiều.

Nguyên tắc gọn lại: cắt phần kể lể, giữ phần phán đoán. Phần kể lể là những câu tóm tắt lại yêu cầu của bạn hoặc mô tả lại code vừa viết. Phần phán đoán là những gì nó nghĩ có thể sai, và đó là giá trị thật.

Đặt ở đâu và đổi khi nào

Cách trình bày thường nên nằm trong cấu hình cá nhân vì nó là sở thích của bạn, không phải luật của dự án. Nhưng có hai ngoại lệ đáng đặt trong repo:

• Mẫu tài liệu chung của đội, ví dụ mẫu mô tả thay đổi, vì cả đội nên dùng chung một khuôn.
• Yêu cầu về ngôn ngữ, ví dụ mọi giải thích và mọi chú thích trong code phải bằng tiếng Việt có dấu. Đây là quy ước dự án chứ không phải sở thích.

Về thời điểm đổi: hãy đổi khi bạn thấy mình liên tục lướt qua cùng một loại nội dung để tìm phần cần đọc. Đó là dấu hiệu định dạng hiện tại không khớp với cách bạn làm việc. Ranh giới giữa phần chung và phần riêng giống hệt mọi thứ khác trong công cụ này, đã nói ở bài về cấu hình.

Những gì không nên cắt dù chọn kiểu trình bày nào

Ưu tiên trình bày ngắn gọn là tốt, nhưng bốn thứ trên là thông tin an toàn chứ không phải phần trang trí. Nếu kiểu trình bày bạn chọn cắt mất chúng thì đó là kiểu sai.

Cách trình bày khác gì với tệp luật dự án

Hai thứ này độc lập. Đổi kiểu trình bày không làm mã tốt lên; đổi tệp luật không làm câu trả lời gọn hơn. Nhiều người nhầm và viết yêu cầu về cách trình bày vào tệp luật, làm loãng phần quan trọng.

Ba kiểu trình bày và lúc dùng từng kiểu

• Ngắn gọn cho việc quen thuộc: chỉ nêu đã làm gì và tệp nào đổi. Dùng khi bạn đã biết rõ mình muốn gì.
• Giải thích cho việc mới: nêu lý do và các lựa chọn khác. Dùng khi bạn đang học phần đó của dự án.
• Theo mẫu cố định: khi bạn cần dán kết quả vào tài liệu hoặc vào hệ thống theo dõi công việc. Kiểu này tiết kiệm nhiều thao tác sao chép sửa lại nhất.

Đặt ở cấu hình cá nhân, không đặt ở dự án

# Kieu trinh bay nen dat o cau hinh ca nhan, khong dat o cau hinh du an.# Ly do: day la so thich cua tung nguoi, khong phai quy tac cua doi. # Ngoai le: neu ca doi can ket qua theo mot mau cu the# de dan vao he thong theo doi cong viec, thi dat o cau hinh du an. # Doi kieu khi doi loai viec, khong doi lien tuc:# doi qua lai lam ban kho quen minh dang o kieu nao