Claude viết mã luôn mắc lỗi? 12 quy tắc này đã giảm tỷ lệ sai sót xuống 3%

marsbitXuất bản vào 2026-05-14Cập nhật gần nhất vào 2026-05-14

Tóm tắt

**Tóm tắt: 12 Quy tắc trong CLAUDE.md Giảm Tỷ lệ Lỗi Code của Claude Xuống 3%** Bài viết mở rộng bộ quy tắc CLAUDE.md nổi tiếng của Andrej Karpathy và Forrest Chang, vốn có 4 quy tắc nhằm giảm lỗi phổ biến khi Claude viết code (như đưa ra giả định thầm lặng, kỹ sư quá mức). Sau 6 tuần thử nghiệm trên 30 kho code, tác giả nhận thấy 4 quy tắc gốc vẫn hiệu quả nhưng chưa đủ cho các tác vụ AI phức tạp hơn xuất hiện từ đầu năm 2026, như Agent đa bước, hook chain hay cộng tác đa kho code. Do đó, tác giả đề xuất thêm 8 quy tắc mới, nâng tổng số lên 12, để giải quyết các lỗi kiểu mới: 5. **Không để model làm công việc phi ngôn ngữ:** (VD: quyết định logic retry API). 6. **Đặt ngân sách token cứng:** Ngăn các vòng lặp debug tốn kém kéo dài vô hạn. 7. **Phơi bày xung đột, không dung hòa trung bình:** Tránh việc Claude trộn lẫn các phong cách/pattern mâu thuẫn trong code. 8. **Đọc trước, viết sau:** Hiểu code hiện có trước khi sửa/viết mới để tránh trùng lặp hoặc phá vỡ logic. 9. **Kiểm thử không phải tùy chọn, nhưng bản thân việc kiểm thử không phải mục tiêu:** Đảm bảo test xác thực logic thực sự, không chỉ đơn giản pass. 10. **Các thao tác chạy dài cần điểm kiểm tra (checkpoint):** Bảo vệ tiến trình trong các tác vụ đa bước, tránh mất toàn bộ nếu một bước lỗi. 11. **Quy ước có trước, sự mới mẻ có sau:** Tuân theo pattern hiện có của codebase thay vì giới thiệu quy ước mới gây rối. 12. **Thất bại phải rõ ràng, không thất bại thầm lặng:** Ưu tiên báo lỗi rõ ràng thay vì để code chạy "...

Lời biên tập: Vào tháng 1 năm 2026, lời phàn nàn của Andrej Karpathy về việc Claude viết mã đã chỉ ra một tệp có vẻ nhỏ nhưng cực kỳ quan trọng trong quy trình lập trình AI: CLAUDE.md. Forrest Chang sau đó đã tổng hợp những vấn đề này thành 4 quy tắc ứng xử, nhằm ràng buộc các lỗi phổ biến của Claude khi viết mã: giả định ngầm định, kỹ thuật hóa quá mức, làm hỏng mã không liên quan và thiếu tiêu chuẩn thành công rõ ràng.

Nhưng vài tháng sau, phạm vi sử dụng Claude Code đã không chỉ còn là "để mô hình viết một đoạn mã". Khi Agent đa bước, kích hoạt chuỗi hook, tải xung đột kỹ năng và cộng tác đa kho mã trở thành tiêu chuẩn, các kiểu thất bại mới cũng bắt đầu xuất hiện: mô hình mất kiểm soát trong nhiệm vụ dài, kiểm tra thông qua nhưng không xác minh logic thực sự, di chuyển hoàn thành nhưng bỏ qua lỗi một cách âm thầm, các phong cách mã khác nhau bị trộn lẫn sai lầm.

Tác giả bài viết này đã thử nghiệm 30 kho mã trong 6 tuần và thêm 8 quy tắc mới dựa trên 4 quy tắc gốc của Karpathy, nhằm bao quát các vấn đề mới khi lập trình AI chuyển từ việc bổ sung đơn lẻ sang hợp tác hóa Agent.

Dưới đây là bài viết gốc:

Cuối tháng 1 năm 2026, Andrej Karpathy đã đăng một chuỗi tweet, phàn nàn về cách Claude viết mã. Ông chỉ ra ba vấn đề điển hình: đưa ra giả định sai lầm mà không có giải thích, phức tạp hóa quá mức, và gây ra sự phá hủy không liên quan đối với mã lẽ ra không nên sửa đổi.

Forrest Chang thấy chuỗi tweet này, đã tổng hợp những lời phàn nàn thành 4 quy tắc ứng xử, viết vào một tệp CLAUDE.md riêng biệt và đăng lên GitHub. Dự án này đạt được 5.828 Star ngay trong ngày đầu tiên, được 60.000 lần lưu trong hai tuần, và hiện nay đã có 120.000 Star, trở thành kho mã đơn tệp phát triển nhanh nhất năm 2026.

Sau đó, tôi đã dùng 30 kho mã để kiểm tra nó trong 6 tuần.

4 quy tắc này thực sự hiệu quả. Xác suất xuất hiện lỗi trước đây khoảng 40%, trong các nhiệm vụ mà các quy tắc này phát huy tác dụng, đã giảm xuống dưới 3%. Nhưng vấn đề là, mẫu ban đầu này được tạo ra để giải quyết các lỗi xuất hiện khi Claude viết mã vào tháng 1.

Đến tháng 5 năm 2026, các vấn đề mà hệ sinh thái Claude Code phải đối mặt đã khác: các Agent xung đột lẫn nhau, kích hoạt chuỗi hook, xung đột tải kỹ năng, và gián đoạn quy trình công việc đa bước xuyên phiên.

Vì vậy, tôi đã thêm 8 quy tắc nữa. Dưới đây là bản CLAUDE.md đầy đủ với 12 quy tắc: lý do tại sao mỗi quy tắc đáng để thêm vào, và bản mẫu gốc của Karpathy sẽ thất bại thầm lặng ở 4 điểm nào.

Nếu bạn muốn bỏ qua giải thích và sao chép sử dụng ngay, tệp đầy đủ được đặt ở cuối bài.

Tại sao điều này quan trọng

CLAUDE.md của Claude Code là tệp bị đánh giá thấp nhất trong toàn bộ ngăn xếp công nghệ lập trình AI. Hầu hết các nhà phát triển thường mắc ba loại sai lầm:

Thứ nhất, coi nó như thùng rác sở thích, nhồi nhét tất cả thói quen của mình vào, cuối cùng phình to đến hơn 4000 token, tỷ lệ tuân thủ quy tắc giảm xuống 30%.

Thứ hai, hoàn toàn không sử dụng, mỗi lần đều nhắc lại. Điều này gây lãng phí token gấp 5 lần, và thiếu tính nhất quán giữa các phiên khác nhau.

Thứ ba, sao chép một mẫu rồi không bao giờ động đến nữa. Nó có thể hiệu quả trong hai tuần, nhưng khi kho mã thay đổi, nó sẽ thất bại mà bạn không hề hay biết.

Tài liệu chính thức của Anthropic nói rất rõ: về bản chất, CLAUDE.md chỉ mang tính khuyến nghị. Claude sẽ tuân theo nó khoảng 80% thời gian. Một khi vượt quá 200 dòng, tỷ lệ tuân thủ sẽ giảm rõ rệt vì các quy tắc quan trọng bị chìm trong tiếng ồn.

Mẫu của Karpathy đã giải quyết vấn đề này: một tệp, 65 dòng, 4 quy tắc. Đây là mức chuẩn tối thiểu.

Nhưng mức trần có thể cao hơn. Sau khi thêm 8 quy tắc dưới đây, nó không chỉ bao quát các vấn đề viết mã mà Karpathy phàn nàn vào tháng 1 năm 2026, mà còn cả các vấn đề điều phối Agent xuất hiện vào tháng 5 năm 2026 - những vấn đề chưa tồn tại khi mẫu gốc được viết.

4 quy tắc gốc

Nếu bạn chưa xem kho của Forrest Chang, hãy xem phiên bản cơ bản này trước:

Quy tắc 1: Suy nghĩ trước khi viết mã.

Không ngầm định giả định. Hãy nêu rõ giả định của bạn, phơi bày các điểm đánh đổi. Hỏi trước khi đoán. Khi có giải pháp đơn giản hơn, hãy chủ động đưa ra ý kiến phản đối.

Quy tắc 2: Ưu tiên đơn giản.
Sử dụng mã ít nhất có thể giải quyết vấn đề. Không thêm các tính năng tưởng tượng. Không thiết kế lớp trừu tượng cho mã một lần. Nếu một kỹ sư kỳ cựu cho rằng nó quá phức tạp, thì nên được đơn giản hóa.

Quy tắc 3: Sửa đổi như phẫu thuật.
Chỉ sửa phần phải sửa. Đừng tùy tiện "tối ưu hóa" mã, chú thích hoặc định dạng liền kề. Đừng tái cấu trúc thứ chưa hỏng. Giữ phong cách nhất quán với hiện có.

Quy tắc 4: Thực thi hướng mục tiêu.
Trước tiên định nghĩa tiêu chuẩn thành công, sau đó lặp đi lặp lại cho đến khi hoàn thành xác minh. Đừng bảo Claude phải làm từng bước như thế nào, mà hãy bảo nó kết quả thành công nên trông ra sao, để nó tự lặp.

4 quy tắc này có thể giải quyết khoảng 40% kiểu thất bại mà tôi thấy trong các phiên Claude Code không có giám sát. Khoảng 60% vấn đề còn lại ẩn trong các khoảng trống dưới đây.

8 quy tắc tôi đã thêm, và lý do

Mỗi quy tắc đều đến từ một khoảnh khắc thực tế: 4 quy tắc gốc của Karpathy đã không đủ dùng. Dưới đây tôi sẽ nói về bối cảnh đó trước, sau đó đưa ra quy tắc tương ứng.

Quy tắc 5: Đừng để mô hình làm công việc phi ngôn ngữ

Quy tắc của Karpathy không bao quát điểm này. Do đó, mô hình bắt đầu quyết định những vấn đề lẽ ra nên do mã xác định xử lý: có nên thử lại một lần gọi API không, làm thế nào để định tuyến một tin nhắn, khi nào nên nâng cấp xử lý. Kết quả là, mỗi tuần phán đoán đều khác nhau. Bạn nhận được một câu lệnh if-else không ổn định, tính phí theo mỗi token 0,003 đô la.

Khoảnh khắc đó là như thế này: có một đoạn mã gọi Claude để "phán đoán khi gặp lỗi 503 có nên thử lại không". Ban đầu nó chạy rất tốt, kéo dài hai tuần, sau đó đột nhiên trở nên không ổn định, vì mô hình bắt đầu coi thân yêu cầu như ngữ cảnh phán đoán. Chiến lược thử lại trở nên ngẫu nhiên, vì bản thân prompt đã ngẫu nhiên.

Quy tắc 6: Đặt ngân sách token cứng, không có ngoại lệ

CLAUDE.md không có ràng buộc ngân sách, tương đương với một tấm séc trắng. Mỗi vòng lặp đều có thể mất kiểm soát, biến thành một đợt đổ ngữ cảnh 50.000 token. Mô hình sẽ không tự dừng lại.

Khoảnh khắc đó là như thế này: một phiên gỡ lỗi kéo dài 90 phút. Mô hình cứ lặp đi lặp lại xung quanh cùng một thông báo lỗi 8KB, và dần quên mất mình đã thử các phương án sửa chữa nào. Cuối cùng, nó bắt đầu đề xuất các phương án mà tôi đã bác bỏ từ 40 tin nhắn trước. Nếu có ngân sách token, quá trình này đã nên bị chấm dứt ở phút thứ 12.

Quy tắc 7: Phơi bày xung đột, đừng dung hòa trung bình

Khi hai phần trong kho mã mâu thuẫn với nhau, Claude sẽ cố gắng làm hài lòng cả hai bên, kết quả viết ra một mớ mã không mạch lạc.

Khoảnh khắc đó là như thế này: một kho mã tồn tại hai mẫu xử lý lỗi, một mẫu là async/await kèm try/catch rõ ràng, mẫu kia là ranh giới lỗi toàn cục. Mã mới Claude viết ra sử dụng cả hai mẫu. Kết quả là xử lý lỗi bị làm hai lần. Tôi mất 30 phút mới hiểu tại sao lỗi bị nuốt hai lần.

Quy tắc 8: Đọc trước, viết sau

Quy tắc "Sửa đổi như phẫu thuật" của Karpathy bảo Claude đừng sửa mã liền kề. Nhưng nó không bảo Claude: trước tiên hãy hiểu mã liền kề. Không có điều này, Claude sẽ viết ra mã mới xung đột với mã hiện có cách đó 30 dòng.

Khoảnh khắc đó là như thế này: Claude thêm một hàm mới có chức năng hoàn toàn giống bên cạnh một hàm đã có, vì nó không đọc hàm cũ trước. Hai hàm làm cùng một việc. Nhưng do thứ tự import, hàm mới ghi đè hàm cũ, mà hàm cũ đã tồn tại như tiêu chuẩn duy nhất trên thực tế trong 6 tháng.

Quy tắc 9: Kiểm tra không phải tùy chọn, nhưng bản thân kiểm tra không phải mục tiêu

Quy tắc "Thực thi hướng mục tiêu" của Karpathy ngụ ý kiểm tra có thể là tiêu chuẩn thành công. Nhưng trong thực tế, Claude sẽ coi "kiểm tra thông qua" là mục tiêu duy nhất, từ đó viết ra một số mã có thể thông qua kiểm tra nông cạn, nhưng lại phá hỏng thứ khác.

Khoảnh khắc đó là như thế này: Claude viết 12 bài kiểm tra cho một hàm xác thực, tất cả đều thông qua. Nhưng logic xác thực trong môi trường sản xuất hỏng. Những bài kiểm tra đó chỉ xác minh hàm "trả về cái gì đó", chứ không xác minh nó có trả về đúng thứ không. Hàm có thể thông qua kiểm tra vì nó trả về một hằng số.

Quy tắc 10: Thao tác chạy lâu cần điểm kiểm tra

Mẫu của Karpathy mặc định tương tác là một lần. Nhưng công việc Claude Code thực tế thường là đa bước: tái cấu trúc xuyên 20 tệp, xây dựng tính năng trong một phiên, gỡ lỗi xuyên nhiều commit. Nếu không có điểm kiểm tra, một bước sai, toàn bộ tiến độ trước đó đều có thể mất.

Khoảnh khắc đó là như thế này: một nhiệm vụ tái cấu trúc 6 bước sai ở bước thứ 4. Khi tôi phát hiện, Claude đã tiếp tục hoàn thành bước 5 và 6 trên trạng thái sai. Thời gian tháo gỡ sửa chữa còn dài hơn thời gian làm lại toàn bộ nhiệm vụ. Nếu có điểm kiểm tra, bước 4 đã có thể phát hiện vấn đề.

Quy tắc 11: Quy ước ưu tiên hơn sáng tạo mới

Trong một kho mã đã có mẫu trưởng thành, Claude thích giới thiệu cách viết của riêng nó. Dù cách viết của nó "tốt hơn", nhưng việc giới thiệu mẫu thứ hai, bản thân nó đã tệ hơn bất kỳ mẫu đơn lẻ nào.

Khoảnh khắc đó là như thế này: Claude giới thiệu hooks vào một kho mã React dựa trên class component. Nó thực sự chạy được. Nhưng đồng thời nó phá hỏng mẫu kiểm tra vốn có của kho mã, vì những bài kiểm tra đó phụ thuộc vào componentDidMount. Cuối cùng mất nửa ngày mới xóa và viết lại nó.

Quy tắc 12: Thất bại rõ ràng, đừng thất bại thầm lặng

Thất bại đắt giá nhất của Claude, thường là những thất bại trông giống như thành công. Một hàm "chạy được", nhưng trả về dữ liệu sai; một lần migration "hoàn thành", nhưng bỏ qua 30 bản ghi; một bài kiểm tra "thông qua", nhưng chỉ vì bản thân khẳng định là sai.

Khoảnh khắc đó là như thế này: Claude nói một lần di chuyển cơ sở dữ liệu "hoàn thành thành công". Nhưng thực tế, nó đã thầm lặng bỏ qua 14% bản ghi kích hoạt xung đột ràng buộc. Hành vi bỏ qua được ghi vào nhật ký, nhưng không được phơi bày rõ ràng. 11 ngày sau, khi dữ liệu báo cáo bắt đầu bất thường, chúng tôi mới phát hiện vấn đề.

Kết quả dữ liệu

Tôi đã theo dõi cùng một nhóm 50 nhiệm vụ đại diện trong 6 tuần, bao phủ 30 kho mã, kiểm tra ba cấu hình.

Tỷ lệ lỗi đề cập đến: nhiệm vụ cần được sửa chữa hoặc viết lại, để khớp với ý định ban đầu. Các lỗi tính bao gồm: giả định sai lầm thầm lặng, kỹ thuật hóa quá mức, phá hủy không liên quan, thất bại thầm lặng, vi phạm quy ước, dung hòa xung đột, bỏ lỡ điểm kiểm tra.

Tỷ lệ tuân thủ đề cập đến: khi một quy tắc nào đó áp dụng, xác suất Claude sẽ áp dụng rõ ràng quy tắc đó là bao nhiêu.

Kết quả thực sự thú vị, không chỉ là tỷ lệ lỗi giảm từ 41% xuống 3%. Quan trọng hơn, từ 4 quy tắc mở rộng thành 12 quy tắc, hầu như không tăng gánh nặng tuân thủ, tỷ lệ tuân thủ chỉ từ 78% giảm xuống 76%, nhưng tỷ lệ lỗi lại giảm thêm 8 điểm phần trăm. Các quy tắc mới bổ sung bao phủ các kiểu thất bại mà 4 quy tắc cũ chưa xử lý, chúng không tranh giành cùng một ngân sách chú ý.

Mẫu của Karpathy sẽ thất bại thầm lặng ở những đâu

Ngay cả không thêm quy tắc mới, mẫu 4 quy tắc gốc cũng ít nhất không đủ dùng ở 4 điểm.

Thứ nhất, nhiệm vụ Agent chạy lâu.
Quy tắc của Karpathy chủ yếu nhắm vào thời điểm Claude đang viết mã. Nhưng khi Claude đang chạy một pipeline đa bước, điều gì sẽ xảy ra? Mẫu gốc không có quy tắc ngân sách, không có quy tắc điểm kiểm tra, cũng không có quy tắc "thất bại lớn tiếng". Do đó pipeline sẽ dần trôi dạt.

Thứ hai, tính nhất quán đa kho mã.
"Khớp phong cách hiện có" mặc định chỉ có một phong cách. Nhưng trong một monorepo có 12 dịch vụ, Claude phải chọn khớp phong cách nào. Quy tắc gốc không bảo nó cách chọn. Do đó nó hoặc chọn ngẫu nhiên, hoặc trộn lẫn trung bình một vài phong cách.

Thứ ba, chất lượng kiểm tra.
"Thực thi hướng mục tiêu" sẽ coi "kiểm tra thông qua" là thành công, nhưng không nói rõ bản thân kiểm tra phải có ý nghĩa. Kết quả là, Claude viết ra một số bài kiểm tra hầu như không xác minh gì, nhưng những bài kiểm tra này khiến nó lầm tưởng mình rất tự tin.

Thứ tư, sự khác biệt giữa môi trường sản xuất và giai đoạn nguyên mẫu.
Cùng 4 quy tắc, có thể ngăn mã sản xuất bị kỹ thuật hóa quá mức, nhưng cũng có thể làm chậm phát triển nguyên mẫu. Vì đôi khi giai đoạn nguyên mẫu thực sự cần 100 dòng giàn giáo thăm dò, trước tiên tìm ra hướng đi. Quy tắc "Ưu tiên đơn giản" của Karpathy dễ kích hoạt quá mức trong mã giai đoạn đầu.

8 quy tắc mới bổ sung này không nhằm thay thế 4 quy tắc gốc của Karpathy, mà là sửa chữa các khoảng trống của chúng: mẫu gốc tương ứng với bối cảnh viết mã kiểu tự động bổ sung vào tháng 1 năm 2026; còn đến tháng 5 năm 2026, Claude Code đã bước vào môi trường cộng tác đa bước, đa kho mã do Agent điều khiển, vấn đề mà hai bên đối mặt không giống nhau.

Những phương pháp nào không hiệu quả

Trước khi quyết định cuối cùng 12 quy tắc này, tôi cũng đã thử một số phương án khác.

Thêm các quy tắc tôi thấy trên Reddit / X.
Trong số đó, hầu hết hoặc chỉ lặp lại 4 quy tắc gốc của Karpathy bằng cách diễn đạt khác, hoặc là các quy tắc đặc thù miền không thể khái quát hóa, như "luôn sử dụng class Tailwind". Cuối cùng đều xóa.

Vượt quá 12 quy tắc.
Tôi kiểm tra tối đa đến 18 quy tắc. Sau khi vượt quá 14 quy tắc, tỷ lệ tuân thủ từ 76% giảm xuống 52%. Giới hạn 200 dòng là có thật. Sau khi vượt quá độ dài này, Claude sẽ bắt đầu khớp mẫu thành "ở đây có quy tắc", thay vì thực sự đọc từng quy tắc.

Quy tắc phụ thuộc vào sự tồn tại của một số công cụ.
Ví dụ: "luôn sử dụng eslint", một khi dự án không cài đặt eslint, quy tắc này sẽ thất bại, và là thất bại thầm lặng. Sau đó tôi đổi nó thành cách diễn đạt không phụ thuộc công cụ cụ thể, ví dụ đổi "sử dụng eslint" thành "tuân theo phong cách đã được thực thi trong kho mã".

Đặt ví dụ trong CLAUDE.md, thay vì quy tắc.
Ví dụ chiếm nhiều ngữ cảnh hơn quy tắc. Ba ví dụ tiêu thụ ngữ cảnh, tương đương với khoảng 10 quy tắc, và Claude dễ quá khớp với ví dụ. Quy tắc là trừu tượng, ví dụ là cụ thể. Vì vậy, nên sử dụng quy tắc.

"Cẩn thận một chút" "suy nghĩ nghiêm túc" "tập trung một chút".
Đây đều là tiếng ồn. Tỷ lệ tuân thủ loại chỉ dẫn này giảm xuống khoảng 30%, vì chúng không thể kiểm tra được. Sau đó tôi thay thế chúng bằng các quy tắc mệnh lệnh cụ thể hơn, như "nêu rõ giả định".

Bảo Claude hãy giống như "kỹ sư kỳ cựu".
Điều này không hiệu quả. Claude vốn đã nghĩ mình giống kỹ sư kỳ cựu. Vấn đề thực sự không nằm ở chỗ nó có nghĩ như vậy không, mà ở chỗ nó có thực thi như vậy không. Quy tắc mệnh lệnh có thể thu hẹp khoảng cách này, từ ngữ nhắc danh tính không thể.

Bản CLAUDE.md đầy đủ 12 quy tắc

Dưới đây là phiên bản đầy đủ có thể sao chép dán sử dụng ngay.

Tạm thời không thể hiển thị nội dung này bên ngoài tài liệu Feishu

Lưu nó thành CLAUDE.md trong thư mục gốc kho mã. Dưới 12 quy tắc này, thêm các quy tắc chuyên biệt dự án, như ngăn xếp kỹ thuật, lệnh kiểm tra, mẫu lỗi, v.v. Tổng thể không vượt quá 200 dòng, sau khi vượt quá, tỷ lệ tuân thủ quy tắc sẽ giảm rõ rệt.

Cách cài đặt

Chỉ hai bước:

1. Nối 4 quy tắc cơ bản của Karpathy vào CLAUDE.md của bạn
curl https://raw.githubusercontent.com/forrestchang/andrej-karpathy-skills/main/CLAUDE.md >> CLAUDE.md


2. Dán các quy tắc 5–12 trong bài viết này vào bên dưới

Lưu tệp trong thư mục gốc kho mã. Ký hiệu >> ở đây rất quan trọng, tác dụng của nó là nối thêm vào CLAUDE.md đã có, thay vì ghi đè các quy tắc chuyên biệt dự án bạn đã viết.

Mô hình tâm trí

CLAUDE.md không phải danh sách mong muốn, mà là một hợp đồng hành vi, dùng để bịt các kiểu thất bại cụ thể bạn đã quan sát thấy.

Mỗi quy tắc nên trả lời một câu hỏi: Nó ngăn chặn lỗi gì?

4 quy tắc của Karpathy, ngăn các kiểu thất bại ông thấy vào tháng 1 năm 2026: giả định thầm lặng, kỹ thuật hóa quá mức, phá hủy không liên quan, tiêu chuẩn thành công yếu. Chúng là cơ sở, đừng bỏ qua.

8 quy tắc tôi thêm, ngăn các kiểu thất bại mới xuất hiện sau tháng 5 năm 2026: vòng lặp Agent không ràng buộc ngân sách, nhiệm vụ đa bước không điểm kiểm tra, kiểm tra trông có vẻ kiểm tra nhưng thực ra không kiểm tra logic then chốt, và vấn đề đóng gói thất bại thầm lặng thành thành công thầm lặng. Chúng là bản vá tăng cường.

Tất nhiên, hiệu quả cụ thể khác nhau tùy người. Nếu bạn không chạy pipeline đa bước, quy tắc 10 không quá quan trọng với bạn. Nếu kho mã của bạn chỉ có một phong cách thống nhất, và đã được lint thực thi, quy tắc 11 là thừa. Sau khi đọc 12 quy tắc này, giữ lại các quy tắc thực sự tương ứng với lỗi bạn thực tế mắc phải, xóa phần còn lại.

Một bản CLAUDE.md 6 quy tắc được tùy chỉnh cho kiểu thất bại thực tế, tốt hơn một bản có 12 quy tắc, trong đó 6 quy tắc bạn không bao giờ dùng đến.

Kết luận

Tweet của Karpathy vào tháng 1 năm 2026, về bản chất là một lời phàn nàn. Forrest Chang biến nó thành 4 quy tắc. Cuối cùng, 12 vạn nhà phát triển đã Star kết quả này. Và trong số đó, hầu hết mọi người, ngày nay vẫn chỉ sử dụng 4 quy tắc đó.

Mô hình đã tiến bộ, hệ sinh thái cũng đã thay đổi. Agent đa bước, kích hoạt chuỗi hook, tải kỹ năng, cộng tác đa kho mã - những thứ này đều không tồn tại khi Karpathy viết tweet đó. 4 quy tắc cũ không giải quyết những vấn đề này. Chúng không sai, mà là không đầy đủ.

Thêm 8 quy tắc. 6 tuần thời gian, kiểm tra bao phủ 30 kho mã. Tỷ lệ lỗi từ 41% giảm xuống 3%.

Tối nay hãy lưu bài viết này, dán 12 quy tắc này vào CLAUDE.md của bạn. Nếu nó giúp bạn tránh được một tuần vòng vo với Claude, hãy chia sẻ.

Câu hỏi Liên quan

QAndrej Karpathy đã phàn nàn về những vấn đề cụ thể nào khi Claude viết code vào tháng 1 năm 2026?

AAndrej Karpathy đã phàn nàn về ba loại vấn đề chính: Claude đưa ra giả định sai mà không giải thích, làm phức tạp hóa vấn đề một cách không cần thiết, và gây ra những thay đổi phá vỡ không liên quan đến các phần code không nên bị chạm tới.

Q4 quy tắc gốc trong mẫu CLAUDE.md của Karpathy (do Forrest Chang tổng hợp) là gì và chúng nhắm giải quyết vấn đề gì?

A4 quy tắc gốc là: 1. Suy nghĩ trước khi code (tránh giả định thầm lặng). 2. Ưu tiên sự đơn giản (dùng ít code nhất có thể). 3. Sửa đổi có chọn lọc như phẫu thuật (chỉ sửa phần cần thiết). 4. Thực thi hướng mục tiêu (xác định tiêu chí thành công rõ ràng). Chúng nhằm giải quyết các lỗi phổ biến như giả định sai, kỹ thuật quá mức, phá vỡ code không liên quan và thiếu tiêu chuẩn thành công rõ ràng.

QTác giả bài viết đã thêm 8 quy tắc mới dựa trên những thất bại nào mà mẫu cũ không bao phủ?

A8 quy tắc mới giải quyết các thất bại mới nảy sinh trong môi trường lập trình AI hiện đại, như: Mô hình đưa ra quyết định phi ngôn ngữ (Rule 5), vòng lặp Agent không có ngân sách token (Rule 6), dung hòa mâu thuẫn thay vì làm rõ (Rule 7), không đọc code hiện có trước khi viết (Rule 8), viết test vô nghĩa chỉ để đạt mục tiêu (Rule 9), tác vụ dài hạn thiếu điểm kiểm tra (Rule 10), phá vỡ quy ước codebase (Rule 11), và thất bại trong im lặng (Rule 12).

QKết quả thử nghiệm 6 tuần với 12 quy tắc cho thấy điều gì về tỷ lệ tuân thủ và tỷ lệ lỗi?

ASau 6 tuần thử nghiệm trên 30 codebase, việc áp dụng 12 quy tắc đã giảm tỷ lệ lỗi từ 41% xuống còn 3%. Đáng chú ý, tỷ lệ tuân thủ (khi quy tắc áp dụng) chỉ giảm nhẹ từ 78% (với 4 quy tắc) xuống 76% (với 12 quy tắc), cho thấy các quy tắc mới bổ sung phạm vi lỗi mới mà không làm quá tải sự chú ý của mô hình.

QTheo bài viết, có những phương pháp nào đã được thử nghiệm nhưng không hiệu quả khi xây dựng CLAUDE.md?

AMột số phương pháp không hiệu quả bao gồm: Thêm quá nhiều quy tắc (trên 14 quy tắc làm giảm tỷ lệ tuân thủ), đưa ra các quy tắc phụ thuộc vào công cụ cụ thể (như 'luôn dùng eslint'), sử dụng nhiều ví dụ thay vì quy tắc trừu tượng, dùng chỉ dẫn chung chung như 'cẩn thận một chút', và bảo Claude 'hãy như một kỹ sư kỳ cựu' thay vì đưa ra các quy tắc hành động cụ thể.

Nội dung Liên quan

Bitwise Tranh Luận: Bitcoin Có Thể Hưởng Lợi Từ Cuộc Thanh Toán Nợ Toàn Cầu

Bitwise cho rằng Bitcoin có thể hưởng lợi từ cuộc khủng hoảng nợ toàn cầu, với gần 30 nghìn tỷ USD nợ cần tái cấp vốn vào năm 2026. Công ty lập luận rằng áp lực nợ công và lãi suất thực giảm có thể khiến tài sản phi chủ quyền như Bitcoin trở nên hấp dẫn. Báo cáo đề cập đến đợt tăng giá tháng 5 của Bitcoin lên trên 83.000 USD trước khi giảm về vùng 70.000 USD do dòng tiền ra từ ETF và tâm lý thị trường giảm sút. Vùng 80.000-85.000 USD được xem là ngưỡng phân chia quan trọng. Về phía cung, các nhà đầu tư dài hạn đang nắm giữ kỷ lục 73% tổng nguồn cung lưu hành, với phần lớn Bitcoin không di chuyển trong hơn một năm, làm thắt chặt nguồn cung sẵn có. Bitwise cũng chỉ ra Bitcoin vẫn có vẻ rẻ hơn so với cổ phiếu công nghệ Mỹ. Các mức giá then chốt cần theo dõi là hỗ trợ 73.000 USD, kháng cự 78.000-80.000 USD, trần chính 83.000-85.000 USD và mục tiêu tăng tiếp theo là 95.000 USD. Tại thời điểm báo cáo, Bitcoin giao dịch quanh 69.460 USD.

bitcoinist19 phút trước

Bitwise Tranh Luận: Bitcoin Có Thể Hưởng Lợi Từ Cuộc Thanh Toán Nợ Toàn Cầu

bitcoinist19 phút trước

Top 3 Meme Coin Có Thể Làm Tài Sản Của Bạn Tăng Chóng Mặt Vào Năm 2026

Bài viết đề xuất ba loại meme coin có tiềm năng tăng trưởng mạnh mẽ vào năm 2026. **Little Pepe (LILPEPE)** đang ở giai đoạn 13 của đợt bán trước, với giá $0.0022, đã huy động được hơn 28 triệu USD và bán gần hết token. Dự án này được hỗ trợ bởi mạng Lớp 2 meme, cung cấp khả năng chống sniper bot, không phí mua/bán và phí giao dịch thấp, hướng tới xây dựng một hệ sinh thái toàn diện. **Bonk (BONK)**, meme coin nổi tiếng trên Solana, đã tăng hơn 2000% trong tuần đầu giao dịch. Mặc dù giá hiện tại ($0.000006) thấp hơn đỉnh lịch sử, động lực giảm phát từ việc đốt token và mua lại dự kiến sẽ hỗ trợ giá. **SPX6900**, tự xưng là "S&P 500 của các meme coin", hiện cách đỉnh khoảng 84%. Dự án này sở hữu cộng đồng mạnh với hàng nghìn ví nắm giữ lớn, và một số dự báo lạc quan cho rằng nó có thể chạm mức $1.15 vào cuối năm 2026. Tóm lại, mỗi dự án mang một đặc điểm khác biệt: Little Pepe với đợt bán trước sắp kết thúc, Bonk với cơ chế giảm phát, và SPX6900 với cộng đồng holder vững mạnh. Bài viết nhấn mạnh việc nhà đầu tư cần tự nghiên cứu kỹ trước khi ra quyết định.

TheNewsCrypto1 giờ trước

Top 3 Meme Coin Có Thể Làm Tài Sản Của Bạn Tăng Chóng Mặt Vào Năm 2026

TheNewsCrypto1 giờ trước

Chủ Tịch Ethereum Foundation Lên Tiếng Về Nhiệm Vụ Mới Và Căng Thẳng Nội Bộ

Chủ tịch Quỹ Ethereum (Ethereum Foundation - EF) Aya Miyaguchi đã công bố tầm nhìn về nhiệm vụ mới của tổ chức, nhấn mạnh sự chuyển hướng cần thiết sau những căng thẳng nội bộ và áp lực phải đảm nhiệm quá nhiều vai trò. Bà cho biết EF đang hướng tới một cấu trúc nhỏ gọn, tập trung hơn, hoạt động như một "nút" trong hệ sinh thái Ethereum rộng lớn chứ không phải là trung tâm điều khiển. Nguyên nhân của sự thay đổi này bắt nguồn từ những tranh luận kỹ thuật ngày càng mang tính chính trị và cá nhân, cùng với những kỳ vọng trái chiều về vai trò của EF. Miyaguchi tin rằng việc cố gắng đáp ứng tất cả sẽ khiến EF không đạt được mục tiêu nào. Thay vào đó, nhiệm vụ cốt lõi mới là bảo tồn và tăng tốc các giá trị độc đáo của Ethereum, tập trung vào chủ quyền người dùng và sự phối hợp tự chủ. Bà cũng phản bác ý kiến cho rằng EF tập trung hơn sẽ ít quan tâm đến việc áp dụng công nghệ, khẳng định điều ngược lại là đúng. Việc áp dụng, kể cả từ các tổ chức, vẫn là một phần công việc, nhưng phải phù hợp với sứ mệnh mới. Sự tái cấu trúc đi kèm với làn sóng ra đi của nhiều nhân sự cấp cao trong năm 2026. Miyaguchi thừa nhận đây là hệ quả tất yếu khi EF trở nên tập trung và có lập trường rõ ràng hơn, đồng thời cho biết các nhà lãnh đạo mới đang tiếp quản và cơ cấu chiến lược mới sẽ được công bố chi tiết trong vài tuần tới. Những chia sẻ của bà diễn ra sau bài đăng của người đồng sáng lập Vitalik Buterin, người cũng mô tả tương lai của EF là tinh gọn và ít tập trung quyền lực hơn.

bitcoinist1 giờ trước

Chủ Tịch Ethereum Foundation Lên Tiếng Về Nhiệm Vụ Mới Và Căng Thẳng Nội Bộ

bitcoinist1 giờ trước

Robinhood Thâm Nhập Thị Trường Tiền Điện Tử Canada Thông Qua Việc Mua Lại WonderFi

Vào thứ Hai, Robinhood Markets đã hoàn tất việc mua lại WonderFi, một công ty dịch vụ tài sản số ở Toronto, với giá 180 triệu USD. WonderFi điều hành Bitbuy và Coinsquare, hai nền tảng tiền mã hóa được cấp phép và thuộc hàng lớn nhất tại Canada, quản lý hơn 2,1 tỷ CAD tài sản. Thông qua thương vụ này, Robinhood tiếp quản khoảng 300.000 người dùng, nâng tổng số khách hàng được tài trợ bên ngoài Mỹ của họ lên trên 1 triệu. Johann Kerbrat của Robinhood nhận định WonderFi là đối tác lý tưởng để đẩy nhanh mục tiêu tại Canada nhờ kinh nghiệm vận hành các nền tảng có quy định, phục vụ cả người mới và khách hàng giàu kinh nghiệm. Thương vụ cũng củng cố hoạt động kinh doanh thể chế của Robinhood sau khi mua Bitstamp năm ngoái. Nhân viên WonderFi sẽ gia nhập đội ngũ Robinhood tại Canada. Ban đầu dự kiến đóng vào nửa cuối năm 2025, thời điểm hoàn tất đã được lùi lại để Robinhood xin giấy phép quy định và triển khai công nghệ độc quyền tại thị trường này.

TheNewsCrypto2 giờ trước

Robinhood Thâm Nhập Thị Trường Tiền Điện Tử Canada Thông Qua Việc Mua Lại WonderFi

TheNewsCrypto2 giờ trước

a16z Crypto mới nhất phát hành: Tại sao chúng ta cần thị trường dự đoán?

Thị trường dự đoán cho phép mọi người giao dịch dựa trên kết quả sự kiện tương lai, từ địa chính trị đến giải trí. Về bản chất, chúng là công cụ tổng hợp thông tin: thông qua cơ chế giá, thị trường tập hợp nhận thức của người tham gia để đưa ra tín hiệu xác suất cho một sự kiện cụ thể. Thị trường dự đoán có nhiều ưu điểm so với các phương pháp khác như thăm dò ý kiến. Chúng cung cấp trực tiếp ước tính xác suất, cập nhật theo thời gian thực và quan trọng nhất là có cơ chế khuyến khích bằng tiền, thúc đẩy người tham gia đưa ra quyết định dựa trên thông tin có căn cứ. Điều này cũng khuyến khích họ tự nghiên cứu để thu lợi nhuận. Ngoài ra, thị trường dự đoán có thể bao phủ các vấn đề chuyên biệt mà thị trường truyền thống không phản ánh được, chẳng hạn như so sánh hiệu suất các mô hình AI. Tuy nhiên, để phát huy tiềm năng, thị trường dự đoán cần giải quyết một số thách thức. Về cơ sở hạ tầng, cần có cơ chế xác minh sự kiện minh bạch, có thể kiểm toán và xử lý thanh toán hợp đồng quy mô lớn. Về thiết kế thị trường, cần thu hút đa dạng người tham gia có thông tin; nếu chỉ có người không am hiểu hoặc người nắm thông tin nội bộ có thể thao túng kết quả, thị trường sẽ mất hiệu quả. Một rủi ro khác là việc lợi dụng thị trường để thao túng nhận thức công chúng, dù thị trường có khả năng tự điều chỉnh nhất định. Khi được thiết kế tốt với sự quản lý rõ ràng và minh bạch, thị trường dự đoán có thể trở thành công cụ mạnh mẽ để dự báo tương lai, khai thác "trí tuệ đám đông" một cách có tổ chức và được khuyến khích.

marsbit2 giờ trước

a16z Crypto mới nhất phát hành: Tại sao chúng ta cần thị trường dự đoán?

marsbit2 giờ trước

Giao dịch

Giao ngay
Hợp đồng Tương lai

Bài viết Nổi bật

AGENT S là gì

Agent S: Tương Lai của Tương Tác Tự Động trong Web3 Giới thiệu Trong bối cảnh không ngừng phát triển của Web3 và tiền điện tử, các đổi mới đang liên tục định nghĩa lại cách mà cá nhân tương tác với các nền tảng kỹ thuật số. Một dự án tiên phong như vậy, Agent S, hứa hẹn sẽ cách mạng hóa tương tác giữa con người và máy tính thông qua khung tác nhân mở của nó. Bằng cách mở đường cho các tương tác tự động, Agent S nhằm đơn giản hóa các nhiệm vụ phức tạp, cung cấp các ứng dụng chuyển đổi trong trí tuệ nhân tạo (AI). Cuộc khám phá chi tiết này sẽ đi sâu vào những phức tạp của dự án, các tính năng độc đáo của nó và những tác động đối với lĩnh vực tiền điện tử. Agent S là gì? Agent S đứng vững như một khung tác nhân mở đột phá, được thiết kế đặc biệt để giải quyết ba thách thức cơ bản trong việc tự động hóa các nhiệm vụ máy tính: Thu thập Kiến thức Cụ thể theo Miền: Khung này học một cách thông minh từ nhiều nguồn kiến thức bên ngoài và kinh nghiệm nội bộ. Cách tiếp cận kép này giúp nó xây dựng một kho lưu trữ phong phú về kiến thức cụ thể theo miền, nâng cao hiệu suất của nó trong việc thực hiện nhiệm vụ. Lập Kế Hoạch Qua Các Tầm Nhìn Nhiệm Vụ Dài Hạn: Agent S sử dụng lập kế hoạch phân cấp tăng cường kinh nghiệm, một cách tiếp cận chiến lược giúp phân chia và thực hiện các nhiệm vụ phức tạp một cách hiệu quả. Tính năng này nâng cao đáng kể khả năng quản lý nhiều nhiệm vụ con một cách hiệu quả và hiệu suất. Xử Lý Các Giao Diện Động, Không Đều: Dự án giới thiệu Giao Diện Tác Nhân-Máy Tính (ACI), một giải pháp đổi mới giúp nâng cao tương tác giữa các tác nhân và người dùng. Sử dụng các Mô Hình Ngôn Ngữ Lớn Đa Phương Thức (MLLMs), Agent S có thể điều hướng và thao tác các giao diện người dùng đồ họa đa dạng một cách liền mạch. Thông qua những tính năng tiên phong này, Agent S cung cấp một khung vững chắc giải quyết các phức tạp liên quan đến việc tự động hóa tương tác giữa con người với máy móc, mở ra nhiều ứng dụng trong AI và hơn thế nữa. Ai là Người Tạo ra Agent S? Mặc dù khái niệm về Agent S là hoàn toàn đổi mới, thông tin cụ thể về người sáng lập vẫn còn mơ hồ. Người sáng lập hiện vẫn chưa được biết đến, điều này làm nổi bật giai đoạn sơ khai của dự án hoặc sự lựa chọn chiến lược để giữ kín các thành viên sáng lập. Bất chấp sự ẩn danh, sự chú ý vẫn tập trung vào khả năng và tiềm năng của khung này. Ai là Các Nhà Đầu Tư của Agent S? Vì Agent S còn tương đối mới trong hệ sinh thái mã hóa, thông tin chi tiết về các nhà đầu tư và những người tài trợ tài chính của nó không được ghi chép rõ ràng. Sự thiếu vắng thông tin công khai về các nền tảng đầu tư hoặc tổ chức hỗ trợ dự án dấy lên câu hỏi về cấu trúc tài trợ và lộ trình phát triển của nó. Hiểu biết về sự hỗ trợ là rất quan trọng để đánh giá tính bền vững và tác động tiềm năng của dự án. Agent S Hoạt Động Như Thế Nào? Tại cốt lõi của Agent S là công nghệ tiên tiến cho phép nó hoạt động hiệu quả trong nhiều bối cảnh khác nhau. Mô hình hoạt động của nó được xây dựng xung quanh một số tính năng chính: Tương Tác Giống Như Con Người: Khung này cung cấp lập kế hoạch AI tiên tiến, cố gắng làm cho các tương tác với máy tính trở nên trực quan hơn. Bằng cách bắt chước hành vi của con người trong việc thực hiện nhiệm vụ, nó hứa hẹn nâng cao trải nghiệm người dùng. Ký Ức Tường Thuật: Được sử dụng để tận dụng các trải nghiệm cấp cao, Agent S sử dụng ký ức tường thuật để theo dõi lịch sử nhiệm vụ, từ đó nâng cao quy trình ra quyết định của nó. Ký Ức Tình Huống: Tính năng này cung cấp cho người dùng hướng dẫn từng bước, cho phép khung này cung cấp hỗ trợ theo ngữ cảnh khi các nhiệm vụ diễn ra. Hỗ Trợ OpenACI: Với khả năng chạy cục bộ, Agent S cho phép người dùng duy trì quyền kiểm soát đối với các tương tác và quy trình làm việc của họ, phù hợp với tinh thần phi tập trung của Web3. Tích Hợp Dễ Dàng với Các API Bên Ngoài: Tính linh hoạt và khả năng tương thích với nhiều nền tảng AI khác nhau đảm bảo rằng Agent S có thể hòa nhập liền mạch vào các hệ sinh thái công nghệ hiện có, làm cho nó trở thành lựa chọn hấp dẫn cho các nhà phát triển và tổ chức. Những chức năng này cùng nhau góp phần vào vị trí độc đáo của Agent S trong không gian tiền điện tử, khi nó tự động hóa các nhiệm vụ phức tạp, nhiều bước với sự can thiệp tối thiểu của con người. Khi dự án phát triển, các ứng dụng tiềm năng của nó trong Web3 có thể định nghĩa lại cách mà các tương tác kỹ thuật số diễn ra. Thời Gian Phát Triển của Agent S Sự phát triển và các cột mốc của Agent S có thể được tóm tắt trong một dòng thời gian nêu bật các sự kiện quan trọng của nó: 27 tháng 9, 2024: Khái niệm về Agent S được ra mắt trong một bài nghiên cứu toàn diện mang tên “Một Khung Tác Nhân Mở Sử Dụng Máy Tính Như Một Con Người,” trình bày nền tảng cho dự án. 10 tháng 10, 2024: Bài nghiên cứu được công bố công khai trên arXiv, cung cấp một cái nhìn sâu sắc về khung và đánh giá hiệu suất của nó dựa trên tiêu chuẩn OSWorld. 12 tháng 10, 2024: Một video trình bày được phát hành, cung cấp cái nhìn trực quan về khả năng và tính năng của Agent S, thu hút thêm sự quan tâm từ người dùng và nhà đầu tư tiềm năng. Những dấu mốc trong dòng thời gian không chỉ minh họa sự tiến bộ của Agent S mà còn chỉ ra cam kết của nó đối với sự minh bạch và sự tham gia của cộng đồng. Những Điểm Chính Về Agent S Khi khung Agent S tiếp tục phát triển, một số thuộc tính chính nổi bật, nhấn mạnh tính đổi mới và tiềm năng của nó: Khung Đổi Mới: Được thiết kế để cung cấp cách sử dụng máy tính trực quan giống như tương tác của con người, Agent S mang đến một cách tiếp cận mới cho việc tự động hóa nhiệm vụ. Tương Tác Tự Động: Khả năng tương tác tự động với máy tính thông qua GUI đánh dấu một bước tiến tới các giải pháp tính toán thông minh và hiệu quả hơn. Tự Động Hóa Nhiệm Vụ Phức Tạp: Với phương pháp mạnh mẽ của nó, nó có thể tự động hóa các nhiệm vụ phức tạp, nhiều bước, làm cho các quy trình nhanh hơn và ít sai sót hơn. Cải Tiến Liên Tục: Các cơ chế học tập cho phép Agent S cải thiện từ các trải nghiệm trước đó, liên tục nâng cao hiệu suất và hiệu quả của nó. Tính Linh Hoạt: Khả năng thích ứng của nó trên các môi trường hoạt động khác nhau như OSWorld và WindowsAgentArena đảm bảo rằng nó có thể phục vụ một loạt các ứng dụng rộng rãi. Khi Agent S định vị mình trong bối cảnh Web3 và tiền điện tử, tiềm năng của nó để nâng cao khả năng tương tác và tự động hóa quy trình đánh dấu một bước tiến quan trọng trong công nghệ AI. Thông qua khung đổi mới của mình, Agent S minh họa cho tương lai của các tương tác kỹ thuật số, hứa hẹn một trải nghiệm liền mạch và hiệu quả hơn cho người dùng trên nhiều ngành công nghiệp khác nhau. Kết luận Agent S đại diện cho một bước nhảy vọt táo bạo trong sự kết hợp giữa AI và Web3, với khả năng định nghĩa lại cách chúng ta tương tác với công nghệ. Mặc dù vẫn còn ở giai đoạn đầu, những khả năng cho ứng dụng của nó là rộng lớn và hấp dẫn. Thông qua khung toàn diện của mình giải quyết các thách thức quan trọng, Agent S nhằm đưa các tương tác tự động lên hàng đầu trong trải nghiệm kỹ thuật số. Khi chúng ta tiến sâu hơn vào các lĩnh vực tiền điện tử và phi tập trung, các dự án như Agent S chắc chắn sẽ đóng một vai trò quan trọng trong việc định hình tương lai của công nghệ và sự hợp tác giữa con người với máy tính.

Tổng lượt xem 842Xuất bản vào 2025.01.14Cập nhật vào 2025.01.14

AGENT S là gì

Làm thế nào để Mua S

Chào mừng bạn đến với HTX.com! Chúng tôi đã làm cho mua Sonic (S) trở nên đơn giản và thuận tiện. Làm theo hướng dẫn từng bước của chúng tôi để bắt đầu hành trình tiền kỹ thuật số của bạn.Bước 1: Tạo Tài khoản HTX của BạnSử dụng email hoặc số điện thoại của bạn để đăng ký tài khoản miễn phí trên HTX. Trải nghiệm hành trình đăng ký không rắc rối và mở khóa tất cả tính năng. Nhận Tài khoản của tôiBước 2: Truy cập Mua Crypto và Chọn Phương thức Thanh toán của BạnThẻ Tín dụng/Ghi nợ: Sử dụng Visa hoặc Mastercard của bạn để mua Sonic (S) ngay lập tức.Số dư: Sử dụng tiền từ số dư tài khoản HTX của bạn để giao dịch liền mạch.Bên thứ ba: Chúng tôi đã thêm những phương thức thanh toán phổ biến như Google Pay và Apple Pay để nâng cao sự tiện lợi.P2P: Giao dịch trực tiếp với người dùng khác trên HTX.Thị trường mua bán phi tập trung (OTC): Chúng tôi cung cấp những dịch vụ được thiết kế riêng và tỷ giá hối đoái cạnh tranh cho nhà giao dịch.Bước 3: Lưu trữ Sonic (S) của BạnSau khi mua Sonic (S), lưu trữ trong tài khoản HTX của bạn. Ngoài ra, bạn có thể gửi đi nơi khác qua chuyển khoản blockchain hoặc sử dụng để giao dịch những tiền kỹ thuật số khác.Bước 4: Giao dịch Sonic (S)Giao dịch Sonic (S) dễ dàng trên thị trường giao ngay của HTX. Chỉ cần truy cập vào tài khoản của bạn, chọn cặp giao dịch, thực hiện giao dịch và theo dõi trong thời gian thực. Chúng tôi cung cấp trải nghiệm thân thiện với người dùng cho cả người mới bắt đầu và người giao dịch dày dạn kinh nghiệm.

Tổng lượt xem 1.5kXuất bản vào 2025.01.15Cập nhật vào 2026.06.02

Làm thế nào để Mua S

Thảo luận

Chào mừng đến với Cộng đồng HTX. Tại đây, bạn có thể được thông báo về những phát triển nền tảng mới nhất và có quyền truy cập vào thông tin chuyên sâu về thị trường. Ý kiến ​​của người dùng về giá của S (S) được trình bày dưới đây.

活动图片

Danh mục Phổ biếnright-arrow

Thẻ Nổi bậtright-arrow