Tại sao Đặt tên quan trọng hơn Prompt khi Lập trình với AI
Tên biến của bạn chính là prompt tốt nhất. Các identifier cụ thể ngăn AI sinh ra code sai, và tại sao 'data' là cái tên tệ nhất bạn có thể đặt.
Khi bạn lập trình với AI, tên biến của bạn chính là prompt tốt nhất. Không phải prompt hệ thống. Không phải hướng dẫn. Mà là những cái tên bạn đặt cho hàm, tham số và biến.
Tại sao ư: AI đọc code từng token một. Mỗi cái tên nó gặp sẽ giới hạn những gì nó tạo ra tiếp theo. Hàm handleData() không đặt ra bất kỳ giới hạn nào cho AI. Hàm dispatchWebRTCOmnichannelUIEvent() gần như không cho nó cơ hội sai.
Tôi xây dựng các hệ thống agentic AI với cách tiếp cận này, và sự khác biệt về chất lượng đầu ra là rất lớn.
Vấn đề của tên chung chung
Phần lớn developer đặt tên một cách tắc trách. data, temp, result, id, msg. Trong lập trình truyền thống, đây là thói quen xấu nhưng vẫn chấp nhận được — bạn có autocomplete của IDE, tài liệu nhóm và trí nhớ của chính mình.
Khi làm việc với AI, những cái tên tắc trách này actively hại bạn. AI coi mỗi tên như một phân bố xác suất. msg có thể có nghĩa bất kỳ gì — tin nhắn chat, email, thông báo hệ thống, một dòng log. Nên AI chọn cái nào phù hợp lỏng lẻo nhất với ngữ cảnh xung quanh, và bạn nhận được code về mặt kỹ thuật hoạt động nhưng làm sai việc.
Thử thí nghiệm này: yêu cầu AI “triển khai một notification handler” không có ngữ cảnh. Sau đó yêu cầu lại, nhưng đặt tên hàm là dispatchWebRTCOmnichannelUIEvent(). Lần đầu sẽ ra thứ gì đó chung chung và có lẽ sai. Lần hai sẽ ra code WebSockets với xử lý event độ trễ thấp — vì cái tên đã nói chính xác cần xây gì.
Cách đặt tên giới hạn sự tạo code của AI
Các mô hình AI xử lý code dưới dạng chuỗi token. Mỗi token thu hẹp không gian xác suất cho token tiếp theo. Khi bạn dùng tên cụ thể, bạn đang giảm số lượng khả năng tiếp diễn.
incomingOmnichannelChatMessage có lẽ chỉ vài trăm cách hoàn thành hợp lý trong dữ liệu huấn luyện. msg có hàng triệu. Cái tên càng cụ thể, không gian xác suất càng hẹp, kết quả tạo ra càng chính xác.
Đây không phải lý thuyết. Đây là cách kiến trúc transformer hoạt động.
Ví dụ thực tế từ QuotyAI
Trong codebase của chúng tôi không có tên chung chung. Mỗi tên hàm mang trọng tải ngữ nghĩa:
-
Hạ tầng kỹ thuật:
dispatchWebRTCOmnichannelUIEvent()nói với AI rằng đây là sự kiện client-side thời gian thực, độ trễ thấp. Không phải batch job. Không phải email. Sự kiện WebSocket. MDN WebSockets API trở thành tài liệu tham khảo rõ ràng. -
Logic nghiệp vụ:
postNewOrderToManagementChannel(paidOrderId, platform)buộc AI tạo code tích hợp — gọi Slack SDK, webhook payloads, định tuyến kênh. Không phải log ra console. Không phải insert database. -
Phân tích:
triggerTenantProvisioningEmailCampaign(tenantDetails)đặt AI vào đúng lĩnh vực tự động hóa email. Drip sequences, onboarding flows, render template.
Quy luật: cái tên càng cụ thể, AI càng ít phải đoán.
Test là chưa đủ
Một cách tiếp cận phổ biến: viết test trước, để AI làm cho test pass. Test pass rồi, nên code chắc chắn tốt.
Sai. Test kiểm tra code của bạn làm đúng những gì test mô tả. Nếu test mập mờ — expect(result).toBeDefined() — AI sẽ tạo code pass test nhưng không làm gì hữu ích. Bạn có thanh xanh và code bị hỏng.
Test ngăn sụp đổ cấu trúc. Đặt tên quyết định code thực sự trở thành gì.
Khi bạn đổi tên handleStuff() thành calculateMonthlyRecurringRevenue(subscriptionId, billingCycle), AI đột nhiên biết cần: tra cứu subscription, tìm billing cycle, tính MRR, và trả về số. Test sau đó có thể assert trên logic nghiệp vụ thực, không chỉ “nó trả về cái gì đó”.
Bài test grep
Thử điều này trong codebase có tên chung chung:
grep -r "notify" .
Bạn nhận 400 kết quả. Không cái nào là cái bạn cần. Bạn đọc từng cái, cố tìm xem notify nào xử lý Slack, email, push hay webhook.
Giờ thử với tên cụ thể:
grep -r "dispatchWebRTCOmnichannelUIEvent" .
Ba kết quả. Định nghĩa, nơi gọi và test. Chỉ vậy thôi.
Tên cụ thể làm codebase dễ điều hướng cho cả bạn và AI. Khi AI cần tìm nơi某物 được định nghĩa, tên cụ thể cho kết quả chính xác. Tename chung chung cho danh sách phỏng đoán.
Mẹo refactoring
Đây là thủ thuật thực tế nhất: khi AI tạo code sai, đừng viết lại prompt. Đổi tên biến.
Nếu AI tạo hàm nhầm lẫn authentication token với session ID, đổi userId thành firebaseAuthUid và sessionId thành livekitWebRTCToken. AI thường sẽ tự sửa ở lần tạo tiếp — tên mới giới hạn output đúng phạm vi.
Điều này hoạt động vì bạn đang cho AI tín hiệu tốt hơn với mỗi token. Nhanh hơn viết prompt dài hơn, và hiệu ứng tích lũy: mỗi lần đổi tên làm codebase rõ ràng hơn cho các lần tạo tiếp theo của AI.
export class CrossTenantAnalyticalEventNotificationService {
private readonly logger = getLogger(CrossTenantAnalyticalEventNotificationService.name);
constructor(
private readonly telegramSdkService: TelegramSdkService,
private readonly facebookSdkService: FacebookSdkService
) {}
// The class name alone tells the AI this handles cross-tenant notifications
// via Telegram and Facebook. No further context needed.
}
Ba quy tắc đặt tên thân thiện với AI
-
Cụ thể, không phải thông minh:
calculateMonthlyRecurringRevenue()hơncalcMRR()và hạ gụccalculateStuff(). AI cần từ đầy đủ để hiểu ý định. -
Dùng thuật ngữ领域, không phải thuật ngữ hạ tầng:
orderCreatedSlackNotification()hơnsendAlert(). AI biết Slack có SDK cụ thể, format tin nhắn cụ thể, API limits cụ thể.alertcó thể có nghĩa bất kỳ gì. -
Khi output AI sai, đổi tên trước khi viết prompt: Sửa tên biến trong code. Thường nhanh hơn viết prompt tốt hơn, và fixes này tồn tại cho mọi lần tạo tiếp theo.
Câu hỏi thường gặp
Tại sao trợ lý lập trình AI của tôi lại tạo ra các hàm sai?
AI gặp vấn đề khi tên biến quá chung chung. Các tên như id hoặc data không cung cấp bối cảnh nào, nên AI phải дог. Các tên cụ thể như firebaseUserId hoặc incomingOmnichannelChatMessage nói chính xác dữ liệu là gì, giảm các giả định sai.
Làm thế nào để ngăn AI tạo ra code ảo giác?
Thay các tham số chung chung bằng tham số cụ thể. Thay vì truyền (userId), hãy truyền (firebaseUserId, webrtcSessionId). Các tên cụ thể giới hạn những gì AI tạo ra — nó sẽ không nhầm lẫn authentication ID với session token.
Tên biến có quan trọng hơn prompt không? Đối với việc tạo code bằng AI, có. Prompt thiết lập bối cảnh, nhưng tên biến là bối cảnh không đổi mà AI đọc với mỗi dòng code. Một hàm được đặt tên đúng hướng dẫn AI qua hàng trăm dòng code được tạo mà không cần lặp lại hướng dẫn.
Bài viết hữu ích? Hãy chia sẻ.
Bài viết liên quan
Kỹ Năng Có Thể Thực Thi Cho Agents Tốt Hơn Tài Liệu
Tài liệu được xây dựng cho con người. Bây giờ AI agents đọc nó. Chúng không cần văn xuôi — chúng cần mã có thể thực thi. Tại sao skills tốt hơn tài liệu.
Đọc bài viếtSpec-Driven vs Code-First vs Chat-to-Code: Ba Triết Lý Dạy AI Về Doanh Nghiệp Của Bạn
Ba cách tiếp cận xây dựng kiến thức cho AI agent — phát triển spec-driven, tài liệu code-first, và tạo code từ chat. So sánh Spec Kit, OpenWiki, Mintlify, và QuotyAI với các cạm bẫy thực tế, sản phẩm, và tín hiệu hội tụ.
Đọc bài viếtOpenWiki vs QuotyAI: Hai Dự Án LangChain DeepAgents, Hai Kiến Trúc
OpenWiki sử dụng LangChain DeepAgents để tạo tài liệu agent cho codebase. QuotyAI sử dụng cùng API createDeepAgent để tạo business logic TypeScript có thể thực thi. So sánh kỹ thuật về kiến trúc agent, pattern subagent, và runtime execution.
Đọc bài viết