Điểm mù của AI – Những điểm mù của LLM được phát hiện khi lập trình với AI

 (ezyang.github.io)
12 điểm bởi GN⁺ 2025-03-20 | 1 bình luận | Chia sẻ qua WhatsApp

Những điểm mù của LLM được phát hiện khi lập trình với AI. Dựa trên Claude Sonnet

  1. Stop Digging → Khó đổi hướng khi gặp vấn đề
  2. Use Static Types → Cần thiết lập kiểu tĩnh
  3. Black Box Testing → Phụ thuộc quá mức vào chi tiết triển khai
  4. Use MCP Servers → Vấn đề về thiết lập và độ an toàn của máy chủ MCP
  5. Preparatory Refactoring → Có thể thực hiện refactor không cần thiết
  6. Mise en Place → Dễ phát sinh vấn đề khi thiết lập môi trường thất bại
  7. Stateless Tools → Phát sinh vấn đề với công cụ phụ thuộc trạng thái
  8. Respect the Spec → Khả năng vi phạm đặc tả cao
  9. Bulldozer Method → Thực hiện quá nhiều tác vụ lặp lại
  10. Memento → Phát sinh vấn đề do thiếu hiểu biết ngữ cảnh
  11. Requirements, not Solutions → Cần làm rõ yêu cầu
  12. Scientific Debugging → Dễ phát sinh vấn đề khi sửa theo kiểu phỏng đoán
  13. Use Automatic Code Formatting → Phát sinh tình trạng không đồng nhất về style code
  14. The Tail Wagging the Dog → Ám ảnh với vấn đề nhỏ nhặt hơn là công việc quan trọng
  15. Keep Files Small → Dễ phát sinh vấn đề khi sửa các file lớn
  16. Know Your Limits → Mô hình thiếu nhận thức về giới hạn của chính mình
  17. Read the Docs → Dễ mắc lỗi với thông tin ngoài phần kiến thức đã học
  18. Culture Eats Strategy → Thiếu tính nhất quán trong style code
  19. Walking Skeleton → Cần ưu tiên cho hệ thống tối thiểu hoạt động được
  20. Rule of Three → Cần refactor khi có trùng lặp code

Không đào sâu vào vấn đề (Stop Digging)

  • Các LLM hiện nay còn thiếu khả năng tự dừng lại và đổi hướng khi gặp sự cố trong lúc làm việc
    • Ví dụ: khi đang triển khai tính năng X nhưng phát hiện cần làm tính năng Y trước, LLM vẫn cố hoàn thành công việc ban đầu (X)
    • Đây là điểm mạnh ở chỗ LLM thực hiện lệnh rất sát, nhưng lại khó tự nhận ra vấn đề và chuyển hướng
  • Chiến lược để tránh vấn đề này
    • Ở bước lập kế hoạch, dùng mô hình suy luận để xác định thứ tự ưu tiên công việc và các tác vụ tiên quyết
    • LLM dạng agent như Sonnet sẽ đọc file và lập kế hoạch công việc → có thể nhận ra tác vụ cần thiết ngay cả khi người dùng không chỉ định rõ
  • Lý tưởng nhất là LLM có thể nhận ra vấn đề và hỏi lại người dùng để xác nhận
    • Tuy nhiên điều này làm tiêu tốn context, nên có thể sẽ tốt hơn nếu một LLM giám sát riêng xử lý việc đó

  • Example

    • Sau khi sửa cách lấy mẫu số ngẫu nhiên của mô phỏng Monte Carlo, đã yêu cầu Claude Code sửa test
      • Vì cách triển khai mới là không xác định, kết quả test lúc pass lúc fail một cách ngẫu nhiên
      • Claude Code không nhận ra điều đó và cố giải quyết bằng cách nới lỏng điều kiện test
      • Thay vào đó, nó nên đề xuất refactor để mô phỏng trở nên có tính quyết định

Sử dụng kiểu tĩnh (Use Static Types)

  • Tranh luận giữa hệ thống kiểu động và kiểu tĩnh thực chất là bài toán cân bằng giữa sự dễ dàng khi prototyping và khả năng bảo trì lâu dài
    • Vì LLM có thể xử lý boilerplate code và refactor, gánh nặng khi chọn ngôn ngữ phù hợp cho prototyping giảm đi
    • Do đó có thể chọn ngôn ngữ có lợi hơn cho việc bảo trì dài hạn thay vì chỉ tối ưu cho prototyping
  • Chiến lược sửa lỗi kiểu
    • Cấu hình agent để LLM nhận biết các lỗi kiểu phát sinh sau khi thay đổi
    • Nhờ đó cũng có thể dễ dàng xác định các file khác cần sửa
  • Điểm cần lưu ý
    • Với Python và JavaScript, do dùng hệ thống kiểu dần dần nên cần cấu hình type checker một cách nghiêm ngặt
    • Rust về nguyên tắc rất phù hợp với LLM, nhưng hiện tại chưa được sinh tốt bằng Python/JavaScript

Kiểm thử hộp đen (Black Box Testing)

  • Kiểm thử hộp đen là cách kiểm tra chức năng của một component mà không cần biết cấu trúc bên trong của nó
    • Vì file triển khai được đưa vào context, LLM khó tuân thủ nguyên tắc kiểm thử hộp đen
    • Với Sonnet 3.7 (dùng trong Cursor), nó có xu hướng cố giữ tính nhất quán của code → thường tìm cách loại bỏ trùng lặp trong file test
      • Nhưng trong kiểm thử hộp đen, giữ lại phần trùng lặp lại có lợi hơn cho việc phát hiện bug
  • Giải pháp lý tưởng
    • Cần cho phép LLM che giấu hoặc tóm tắt các chi tiết triển khai từ những file đã được tải
    • Kiến trúc sư cần xác định rõ ranh giới che giấu thông tin

  • Example

    • Khi sửa một test bị fail, Sonnet 3.7 đã sửa hằng số hardcode thành giá trị được tính từ thuật toán gốc
      • Trong khi lẽ ra phải giữ nguyên hằng số đó

Sử dụng máy chủ MCP (Use MCP Servers)

  • Máy chủ Model Context Protocol (MCP) cung cấp giao diện tiêu chuẩn để LLM tương tác với môi trường
    • Chế độ agent của Cursor và Claude Code sử dụng máy chủ MCP rất rộng rãi
    • Không cần hệ thống RAG riêng, LLM vẫn có thể tìm và sửa các file cần thiết bằng lời gọi MCP
    • Sau khi mô hình chạy test hoặc build, nó có thể sửa vấn đề ngay lập tức
  • Các điểm cần cân nhắc khi viết máy chủ MCP tùy chỉnh
    • Trong Cursor, sau khi bật chế độ YOLO có thể thêm lệnh shell vào quy tắc của Cursor
      • Điều này nguy hiểm → lệnh shell tùy ý có thể làm hỏng môi trường
    • Giải pháp thay thế: viết máy chủ MCP tùy chỉnh chỉ phơi bày một số lệnh nhất định → tăng độ an toàn
      • Tuy nhiên, tính đến tháng 3/2025, việc cấu hình máy chủ MCP theo từng dự án trong Cursor vẫn còn hạn chế

  • Example

    • Sonnet 3.7 đã dùng MCP để kiểm tra kiểu và sửa lỗi trong dự án TypeScript
      • Có thể tự động xử lý mà không cần copy-paste đầu ra terminal thủ công
      • Tuy vậy, đôi khi mô hình vẫn suy luận ra lệnh sai như npm run typecheck

Refactor chuẩn bị (Preparatory Refactoring)

  • Refactor chuẩn bị là chiến lược refactor trước khi thực hiện thay đổi để giúp công việc trở nên dễ hơn
    • Vì refactor là công việc bảo toàn ngữ nghĩa, nó dễ được đánh giá hơn so với thay đổi thực tế
    • Refactor trước rồi mới thực hiện thay đổi → giúp việc review và sửa lỗi dễ hơn
  • Vấn đề của LLM hiện nay
    • Có xu hướng xử lý mọi thứ trong một lần mà không qua bước refactor chuẩn bị
    • Thậm chí còn làm cả các công việc dọn dẹp không cần thiết → có thể dẫn đến refactor quá mức
    • Cursor Sonnet 3.7 có độ chính xác khi thực hiện lệnh chưa cao → có thể phát sinh refactor không liên quan
  • Hướng cải thiện
    • Cần chỉ thị rõ ràng để LLM chỉ sửa code trong giai đoạn refactor trước khi chỉnh sửa chính thức
    • Xác định rõ phạm vi code mà LLM được phép chỉnh sửa → tránh thay đổi không cần thiết

  • Example

    • Đã yêu cầu LLM sửa lỗi import → sau khi sửa xong, nó còn thêm chú thích kiểu cho các hàm lambda
      • Một số chú thích được thêm sai, dẫn đến vòng lặp agent

Mise en Place

  • Trong nấu ăn, mise en place là việc chuẩn bị và sắp xếp sẵn mọi nguyên liệu, dụng cụ trước khi bắt đầu
  • Với LLM, mise en place là việc thiết lập đầy đủ các quy tắc, MCP và môi trường phát triển cần thiết trước khi làm việc
    • Sonnet 3.7 yếu trong việc sửa một môi trường đã bị hỏng
    • Nó có thể cố giải quyết bằng cách copy-paste lệnh từ StackOverflow → có nguy cơ làm hỏng môi trường
    • Cần thiết lập môi trường đúng ngay từ trước để Sonnet không rơi vào vòng lặp debug

  • Example

    • Do vấn đề npm link, VSCode không nhận diện được import từ một dự án local khác
      • Cursor đã ám ảnh với việc giải quyết vấn đề này trong lúc sửa lint và test, nhưng không nhận ra cần chạy npm unlink

Sử dụng công cụ không trạng thái (Stateless Tools)

  • Công cụ nên chạy độc lập mỗi lần mà không lưu trạng thái
    • Shell phụ thuộc vào trạng thái thư mục làm việc hiện tại → có thể gây nhầm lẫn do lưu trạng thái
    • Sonnet 3.7 không thể theo dõi chính xác trạng thái thư mục làm việc hiện tại
    • Cần thiết lập để mọi lệnh đều có thể chạy từ thư mục gốc của dự án
  • Hướng cải thiện
    • Giảm thiểu việc dùng các lệnh công cụ cần thay đổi trạng thái
    • Nếu bắt buộc phải có trạng thái, hãy liên tục cung cấp trạng thái hiện tại cho mô hình để giữ tính nhất quán

  • Ví dụ

    • Nếu một dự án TypeScript gồm ba mô-đun common, backend và frontend
      • Khi Cursor chạy từ thư mục gốc, cần cd vào đúng thư mục → dễ gây nhầm lẫn về thư mục
      • Mở từng mô-đun như các workspace riêng biệt để làm việc thì vấn đề được giải quyết

Tuân thủ đặc tả (Respect the Spec)

  • Khi thay đổi hệ thống, cần phân biệt rõ phần nào có thể sửa và phần nào không thể sửa
    • Khi sửa public API, cần tránh làm vỡ tính tương thích ngược
    • Khi tích hợp với hệ thống bên ngoài, phải khớp với API thực sự tồn tại → không thể sửa theo ý muốn
    • Khi test thất bại, không được xóa test → phải tìm nguyên nhân và sửa
  • Vấn đề của LLM
    • Khả năng vi phạm đặc tả cao → tự do xóa test, thay đổi API, v.v.
    • Việc tuân thủ đặc tả là điều hiển nhiên, nhưng có thể vẫn phải ghi rõ trong prompt
    • Một số ranh giới chỉ có thể phát hiện qua code review

  • Ví dụ

    • Sau khi Sonnet sửa test thất bại, nó thay nội dung test bằng assert True
    • Một hàm public trả về dict chứa khóa pass → Sonnet cố đổi thành pass_ (vấn đề từ khóa dành riêng)

Phương pháp ủi phẳng (Bulldozer Method)

  • Phương pháp ủi phẳng là chiến lược giải quyết vấn đề bằng các thao tác lặp đi lặp lại đơn giản và tăng tốc nhờ hiệu ứng học hỏi
    • AI coding vốn mạnh ở công việc lặp lại → nếu dùng đủ token thì có thể thực hiện refactor quy mô lớn
    • Những vấn đề mà con người bỏ cuộc vì "khối lượng công việc quá lớn" thì LLM vẫn có thể xử lý
    • Tuy nhiên, LLM có thể lặp lại cùng một thao tác, nên cần xem xét nó thực sự đang làm gì

  • Ví dụ

    • Khi sửa hàm cốt lõi trong Haskell hoặc Rust, thường cần refactor trên diện rộng
      • LLM có thể tự động hóa quy trình đọc lỗi biên dịch → sửa → biên dịch lại
    • Khi sửa các giá trị test được hardcode, LLM có thể chạy lại test rồi tự động chỉnh sửa

Memento

  • LLM không thể ghi nhớ trạng thái → ở mỗi tác vụ đều phải hiểu lại codebase từ đầu
    • Chỉ làm việc dựa trên prompt, ngữ cảnh tường minh/ngầm định và các file mà mô hình đã tải trong agent mode
    • Việc phải hiểu lại codebase ở mỗi lần làm việc khiến khả năng hoạt động sai tăng cao nếu thiết lập ban đầu thất bại
  • Chiến lược ngăn ngừa vấn đề
    • Cung cấp rõ ràng các tài liệu mà LLM có thể tham chiếu
    • Thiết lập để mô hình dễ tìm thấy thông tin cần thiết
    • Cung cấp bối cảnh toàn bộ dự án trước rồi mới yêu cầu thay đổi quan trọng

  • Ví dụ

    • Yêu cầu Sonnet 3.7 lập kế hoạch kiểm thử end-to-end cho một dự án hiện có
      • Nó hiểu nhầm rằng mục đích tổng thể của dự án là kiểm thử → sửa README theo hướng tập trung vào test

Làm rõ yêu cầu (Requirements, not Solutions)

  • Một sai lầm phổ biến trong kỹ thuật phần mềm là chưa định nghĩa rõ yêu cầu đã vội đề xuất giải pháp
    • Nếu không gian vấn đề được giới hạn đủ chặt, chỉ cần định nghĩa rõ yêu cầu thì giải pháp gần như tự được quyết định
    • Nếu yêu cầu không rõ ràng, có thể phát sinh tranh cãi không cần thiết về giải pháp
  • Vấn đề của LLM
    • LLM không biết yêu cầu thực sự là gì → tạo ra câu trả lời có xác suất cao nhất theo các mẫu đã được huấn luyện
    • Nếu yêu cầu tác vụ mà không có đặc tả rõ ràng, có thể tạo ra kết quả lệch hướng
    • Có thể sửa cách diễn giải sai bằng cách chỉnh prompt → nhưng nếu cách hiểu sai đã lưu lại trong ngữ cảnh thì sẽ khó sửa
  • Hướng cải thiện
    • Nếu cần một cách giải quyết cụ thể, hãy chỉ định rõ ràng
    • LLM tuân lệnh rất chính xác, nên nếu chỉ dẫn sai cách thì có thể tạo ra kết quả không chính xác

  • Ví dụ

    • Khi yêu cầu Sonnet tạo hình trực quan hóa, mặc định nó sẽ tạo SVG
      • Nếu ghi rõ "có thể tương tác", nó sẽ tạo ứng dụng dựa trên React → chỉ một từ khóa cũng tạo ra khác biệt lớn

Gỡ lỗi theo phương pháp khoa học (Scientific Debugging)

  • Có hai kiểu sửa bug
    • Thử sửa ngẫu nhiên rồi phó mặc cho may mắn
    • Phân tích logic cách hệ thống hoạt động để xác định nguyên nhân gây ra sự khác biệt giữa trạng thái thực tế và trạng thái kỳ vọng
    • Gỡ lỗi theo phương pháp khoa học (phân tích logic) là cách tiếp cận tốt hơn về dài hạn
  • Vấn đề của LLM
    • LLM thiếu khả năng suy luận nên khó áp dụng cách tiếp cận khoa học
    • "Đoán đáp án đúng" rồi lập tức thử sửa → nếu thất bại thì lặp lại các chỉnh sửa ngẫu nhiên (agent loop)
    • Với debug, các mô hình suy luận như Grok 3, DeepSeek-R1 phù hợp hơn
  • Hướng cải thiện
    • Ra lệnh cho mô hình phân tích nguyên nhân hoặc người dùng cung cấp nguyên nhân → tăng tỷ lệ sửa thành công
    • Nếu cho biết chính xác nguyên nhân của vấn đề, mô hình có thể đề xuất cách giải quyết tốt hơn

  • Ví dụ

    • Sonnet 3.7 gặp lỗi cài package trong môi trường uv mặc định không có pip
      • Không xác định được nguyên nhân rồi lặp lại các thử nghiệm ngẫu nhiên → lãng phí token và debug thất bại

Sử dụng định dạng mã tự động (Use Automatic Code Formatting)

  • Các công cụ định dạng mã tự động như gofmt, rustfmt, black, v.v. rất hữu ích để giữ code style nhất quán
    • LLM yếu trong việc tuân thủ các quy tắc máy móc như không có khoảng trắng ở dòng trống, giới hạn 78 ký tự mỗi dòng, v.v.
    • Nên giao việc format cho công cụ và để LLM tập trung vào các tác vụ phức tạp
  • Nguyên tắc tương tự cũng áp dụng cho việc sửa lint
    • Khuyến nghị dùng các lint có thể tự động sửa
    • Hãy để tài nguyên của LLM tập trung vào việc giải quyết các vấn đề phức tạp

Cái đuôi vẫy con chó (The Tail Wagging the Dog)

  • Chỉ tình huống mà một vấn đề nhỏ nhặt lại chi phối vấn đề quan trọng hơn
    • Có thể xảy ra việc quá ám ảnh với xử lý vấn đề cấp thấp mà quên mất mục đích tổng thể của việc viết mã
    • LLM đưa mọi thông tin trong phiên chat vào ngữ cảnh → khó đánh giá mức độ quan trọng
  • Hướng cải thiện
    • Cung cấp prompt rõ ràng ngay từ đầu → giúp LLM tập trung vào việc quan trọng
    • Claude Code dùng sub-agent để xử lý tác vụ cụ thể, tránh làm ô nhiễm ngữ cảnh toàn cục

  • Ví dụ

    • Khi yêu cầu LLM suy nghĩ về cách thực hiện một tác vụ cụ thể, nó có thể cố làm luôn tác vụ đó thay vì chỉ suy nghĩ

Giữ kích thước file nhỏ (Keep Files Small)

  • Tranh luận về kích thước file mã nguồn đã tồn tại từ lâu
    • Áp dụng nguyên tắc trách nhiệm đơn lẻ (mỗi file một class) so với việc chấp nhận file lớn tùy tình huống
    • Nếu file quá lớn, có thể phát sinh vấn đề khi hệ thống RAG tải ngữ cảnh theo đơn vị file
    • Trong các IDE như Cursor, có thể thất bại khi áp dụng patch → ngay cả khi thành công cũng mất nhiều thời gian
      • Ví dụ: trong Cursor 0.45.17, việc áp dụng 55 chỉnh sửa trên file 64KB mất khá nhiều thời gian
    • Sonnet 3.7 khó sửa các file lớn hơn 128KB (giới hạn cửa sổ ngữ cảnh 200K token)
  • Hướng cải thiện
    • Giữ kích thước file nhỏ → LLM có thể tự động xử lý các phần như import

  • Ví dụ

    • Sonnet 3.7 cố di chuyển một lớp test nhỏ trong file Python 471KB
      • Chỉnh sửa thì nhỏ, nhưng bộ vá của Cursor không thể áp dụng thay đổi

Nhận biết giới hạn (Know Your Limits)

  • Cần nhận ra vấn đề và yêu cầu hỗ trợ khi thiếu công cụ hoặc gặp giới hạn về năng lực
    • Sonnet 3.7 yếu trong việc nhận biết giới hạn của chính mình
    • Khi được cung cấp prompt rõ ràng, mô hình có thể nhận ra giới hạn → cần thiết lập cảnh báo về khả năng ảo giác ở các chủ đề cụ thể
  • Vấn đề
    • Sonnet 3.7 hiểu nhầm rằng mình có thể thực thi lệnh shell
      • Khi không có shell command, nó có thể cố tạo script shell ngẫu nhiên → có nguy cơ làm hỏng môi trường
      • Sau khi nói "sẽ chạy X", nó có thể lại tạo ra lời gọi cho một Y hoàn toàn khác
  • Cách cải thiện
    • Sửa prompt hoặc cung cấp công cụ chuyên dụng chỉ thực hiện đúng tác vụ mong muốn
      • Khi cung cấp công cụ cụ thể, có thể ngăn các lệnh gọi shell sai lệch

  • Example

    • Sonnet 3.7 đã cố tạo một script shell không liên quan khi cấp quyền thực thi cho tệp
      • Sau khi lỗi lệnh xảy ra, nó tiếp tục lặp lại các lần sửa sai

Đọc tài liệu (Read the Docs)

  • Khi học framework hoặc library mới, có thể xử lý các tác vụ đơn giản bằng cách chỉnh sửa mã tutorial
    • Nhưng về lâu dài vẫn cần đọc tài liệu từ đầu đến cuối để hiểu cách toàn bộ hệ thống vận hành
  • Điểm mạnh của LLM
    • Với các framework phổ biến, chúng thường đã được tiền huấn luyện nên ghi nhớ phần lớn cách sử dụng
    • Tuy nhiên, với các công cụ ít phổ biến hoặc xuất hiện sau mốc cắt kiến thức, mô hình có thể bị ảo giác
    • Sonnet không hỗ trợ tìm kiếm web → cần cung cấp tài liệu thủ công
      • Trong Cursor, khi cung cấp URL thì có thể tự động đưa vào context

  • Example

    • Khi yêu cầu LLM viết YAML cho function calling trong Python, nó đã tạo ra cấu hình sai
      • Sau khi được cung cấp tài liệu, nó sửa thành công và cải thiện định dạng đầu ra

Văn hóa thắng chiến lược (Culture Eats Strategy)

  • Văn hóa của nhóm ảnh hưởng mang tính quyết định đến khả năng thực thi chiến lược
    • LLM tạo mã dựa trên phong cách đã được học trước và cửa sổ ngữ cảnh
    • Nó ưu tiên các library hoặc phong cách xuất hiện thường xuyên trong context
      • Nếu không được chỉ định rõ, nó sẽ áp dụng phong cách mặc định
  • Chiến lược điều chỉnh phong cách của LLM
    • Chỉnh sửa quy tắc Cursor (thay đổi prompt)
    • Refactor phong cách mã hiện có theo hướng mong muốn → ảnh hưởng đến việc dự đoán token tiếp theo
    • Quy mô codebase có ảnh hưởng lớn hơn prompt → sửa codebase là giải pháp gốc rễ

  • Example

    • Sonnet 3.7 có xu hướng ưu tiên mã đồng bộ trong Python
      • Để tạo mã bất đồng bộ, nhóm đã chuyển phần lớn mã hiện có sang async và thành công

Walking Skeleton

  • Walking Skeleton là chiến lược triển khai một hệ thống end-to-end ở mức tối thiểu
    • Dù chưa hoàn hảo, trước hết hãy làm cho toàn bộ hệ thống chạy được rồi mới cải thiện chi tiết
    • Trong thời đại lập trình với LLM, việc nhanh chóng dựng toàn bộ hệ thống trở nên dễ hơn
    • Khi hệ thống đã hoạt động, bước tiếp theo sẽ rõ ràng hơn → điều quan trọng là đạt đến trạng thái chạy được thật nhanh
    • Vì LLM không thể trực tiếp sử dụng đoạn mã mà nó viết ra, việc bảo đảm trạng thái hoạt động là rất quan trọng

Quy tắc số ba (Rule of Three)

  • Có thể chấp nhận sao chép cùng một đoạn mã tối đa hai lần, đến lần thứ ba thì cần refactor
    • Đây là phiên bản cải tiến của nguyên tắc DRY (Don't Repeat Yourself)
    • Nó làm rõ thời điểm loại bỏ trùng lặp → refactor ở lần sao chép thứ ba
  • Vấn đề của LLM
    • LLM có xu hướng tạo mã trùng lặp
    • Nếu yêu cầu sửa mà không có prompt cụ thể, nó sẽ sao chép lại toàn bộ mã rồi chỉnh sửa
    • Việc loại bỏ trùng lặp chỉ xảy ra khi mô hình tự quyết định làm vậy → cần chỉ thị rõ ràng
  • Cách cải thiện
    • Cần chỉ thị rõ ràng việc loại bỏ trùng lặp
    • Nếu mã hiện có đã có nhiều phần trùng lặp, mô hình có thể tiếp tục tạo thêm trùng lặp

  • Example

    • Khi yêu cầu LLM viết mã kiểm thử, cùng một logic đã bị lặp lại trong nhiều bài kiểm thử
      • Vấn đề được giải quyết sau khi chỉ thị rõ ràng cho nó tạo phương thức hỗ trợ
      • Chế độ agent

Bài viết liên quan

1 bình luận

 
GN⁺ 2025-03-20
Ý kiến trên Hacker News

  • LLM mắc lỗi theo cách khác con người, nên khó phát hiện

    • Chúng ta đã có nhiều năm kinh nghiệm để bắt lỗi của con người, nhưng rất khó hiểu cách LLM suy nghĩ
    • Khó thiết kế hệ thống để phát hiện lỗi của LLM

  • Khi không biết yêu cầu, LLM sẽ điền vào câu trả lời có khả năng cao nhất từ dữ liệu huấn luyện

    • Muốn AI thay thế lập trình viên thì khách hàng phải mô tả chính xác điều họ muốn

  • Trong kỹ nghệ phần mềm, việc làm rõ yêu cầu là rất quan trọng

    • Khi yêu cầu rõ ràng thì lời giải thường tự nhiên được quyết định
    • Khi học framework hoặc library mới, nên đọc tài liệu thật kỹ
    • Khi sửa bug, điều quan trọng là xem xét có hệ thống các giả định của hệ thống
    • Khi sự trùng lặp mã xuất hiện lần thứ ba, nên refactor

  • LLM có năng lực lập trình ở mức "lập trình viên mới vào nghề rất thông minh"

    • Thiếu khả năng nhìn bức tranh lớn, và chỉ làm đúng phần được yêu cầu
    • Dự kiến mô hình sẽ tiếp tục được cải thiện

  • LLM cố gắng trả lời quá nhiều

    • Nếu không được cung cấp đủ dữ liệu, nó sẽ tạo ra câu trả lời sai
    • Sẽ tốt hơn nếu LLM có thể nói "cần thêm thông tin"

  • Khi số lượng bài viết trên blog tăng lên, cần phải sắp xếp lại

    • Vẫn chưa tìm được hệ thống tổ chức tốt

  • Một số lời khuyên hữu ích khi lập trình cùng LLM

    • Có khác biệt quan điểm về việc dùng kiểu tĩnh
    • Clojure cho kết quả tốt hơn Typescript
    • LLM phù hợp hơn với cách tiếp cận xoay quanh hàm

  • LLM yếu ở tính toán và số học

    • Khi sinh mã, điều quan trọng là lấy con số ở đúng vị trí chính xác
    • Việc debug mã do LLM tạo ra tốn thời gian

  • Những điểm cần cân nhắc cùng với lập trình viên con người

    • Quản lý sản phẩm cũng nên chú ý

  • Trường hợp ba LLM phát hiện một "bug" không tồn tại

    • Mã không được tối ưu, nhưng không phải bug
    • Khoảng cách giữa các khối mã là ngắn