Il y a souvent des gens qui m'envoient des messages en demandant : comment distinguer un projet qui travaille vraiment d'un projet qui est juste un PPT ?

Pour être honnête, j'ai aussi payé des frais de scolarité. Maintenant, j'ai une méthode simple : peu importe à quel point il se vante, demandez-vous simplement : a-t-il des produits à montrer ?

Même si c'est une version bêta ou un projet à moitié terminé, cela fonctionne. Au moins, cela prouve que l'équipe est en train d'écrire du code et ne se contente pas d'écrire des histoires. Qui ne peut pas dessiner des promesses dans un livre blanc ? La clé est de savoir si le démo peut fonctionner.

Il y a une astuce : comparez horizontalement des projets similaires. Il dit qu'il est rapide ? Alors parlons des données - combien de TPS, quel est le temps de création de bloc en secondes, comment les nœuds sont-ils conçus. Se dit innovant ? Alors il faut voir s'il s'agit d'une architecture de base complètement nouvelle comme SOL ou SUI, ou s'il ne s'agit que d'un changement de peau pour continuer à réchauffer un plat déjà connu.

J'ai découvert une règle : dans les projets qui travaillent réellement, il est impossible de cacher le véritable savoir-faire dans les détails. Les produits sont opérationnels, les soumissions de code sur GitHub sont fréquentes, la documentation est régulièrement mise à jour, le nombre de partenaires écologiques augmente, et même l'atmosphère de la communauté est différente - on discute d'améliorations fonctionnelles plutôt que de simples appels à l'achat.

En revanche, les choses vides peuvent être perçues en dix minutes : des slogans à foison, des promesses creuses et une chronologie floue.

En fait, ce n'est pas si compliqué. Retenez ces quatre mots : peut courir, peut utiliser, peut comparer, peut expliquer. Si vous respectez ces points, vous pourrez essentiellement éviter 80 % des pièges. Le reste dépendra de votre capacité à comprendre la véritable valeur, et non à être emporté par vos émotions.