HotGo V2: a Go and Vue admin framework whose AI claim is a file in the repository

The pitch leads with AI, and the feature list contains none of it

Both the repository description and the platform blurb open the same way. The project describes itself as an AI-empowered enterprise full-stack platform for separated front and back end development and mobile applications, and the platform section says it is an enterprise AI-empowered base development platform with built-in AI development standards, adapted to mainstream AI development tools, for human and machine collaborative development. That is a claim about the development process rather than about the software, and the feature list is where the difference becomes obvious. There are twenty-three numbered built-in capabilities, and reading through them finds user management, department trees, roles, menus, dictionaries, three kinds of log, payments, a wallet, online users, scheduled tasks, code generation, plugins, service monitoring, file uploads across seven storage drivers, a TCP service, four message queue backends, WebSocket notices, Chinese region codes and a utility toolkit. Not one of them involves a model, an inference call or a prompt. So the AI story is a workflow claim, and the artefact that makes it concrete is the contributor instruction file at the top of the repository, which is what an AI coding tool reads when it opens the project. If that is the kind of project you want to build with, the claim is honest and the file is there to read. If you read the description expecting an AI platform, the feature list will correct you, and it is worth reading that list in full before anything else, because it is the actual product and it is unusually complete for a starter framework.

Four entry points and a microkernel of plugins

The architecture is described in four bullets and they are the most important ones in the readme. The first is multi-entry: an administrative entry, a front end page entry, an external general API entry, and a WebSocket entry for instant messaging, with different businesses going in through different entries. That is a real architectural decision rather than a folder layout, because it means the admin interface, the public API and the real-time channel are separate deployables with separate surfaces, and a feature belongs in exactly one of them. The second is the plugin system, described as a microkernel architecture with feature isolation and high customisability, supporting both progressive development and several people working at once, with one-click creation of a plugin template and one-click install, update and uninstall, and migration of a plugin into a new project. Those four verbs are the substance: a plugin is not a folder you copy, it is a unit with a lifecycle, which is what makes the multi-person claim plausible. The third is the productivity claim, that a skeleton application can be stood up in minutes, which is code generation and gets its own section. The fourth is the technical line worth noting: the design is modular and interface oriented, and API documentation is generated without annotations because the underlying framework registers routes in a standardised way. That last point has a real consequence for anyone integrating. If your routes are registered through the framework's mechanism, you get documentation for free and you cannot document a route you registered by hand, so a project that departs from the convention departs from the documentation too.

Create a table, get a CRUD, and tick the boxes for the form controls

The code generation feature is stated twice, in the feature list and in the built-in functions, and the second statement is more specific. It supports generating front and back end code automatically, and the list of what it generates includes the ordinary create-read-update-delete screens for related tables, tree-structured tables, message queue handlers and scheduled tasks, all from one action. The feature list adds the detail that makes it usable: you do not write code, you create a table and do some simple configuration, and the form controls the generated page needs are selected by ticking them. That is the whole promise of this class of framework, and it is worth judging precisely. What it genuinely saves you is the first afternoon of a screen: the list view, the form, the validation, the wiring between the two, and the service layer on the other side. What it does not save you is the work that follows, because generated CRUD has no domain vocabulary, no error handling that matches your application, no tests, and a table structure that reflects the database rather than your problem. So the honest way to use it is as a starting point you rename and rewrite, and the number of screens you intend to generate is a better measure of the return than the feature's presence. The tree table case is worth singling out because it is the one that takes longest by hand, a hierarchical structure with expand and collapse behaviour, and the readme lists it as a first-class output rather than an afterthought. The same generator also covers the message queue and the scheduled task, which means the plumbing for those two, not just the screen, comes out of the same action.

JWT for who you are, casbin for what you may do, and an unanswered question

The authentication design is stated in one line and it is a sensible split. User state is carried in a signed token, and permissions are evaluated by a dedicated policy library rather than by role checks scattered through the code. The permission model itself is spread across four of the built-in features, and together they describe a fairly complete administrative model. Departments configure the organisation as a tree of companies, departments and posts, and the tree is what supports data permissions. Menus configure the visible structure plus operation permissions and button-level permission identifiers, which is the mechanism that hides an action the current user may not perform. Roles assign menu permissions and, separately, define a data scope, and the readme is precise that a data scope can be set by organisation or by parent and child relationship, which is the distinction between seeing your own department and seeing a subtree. Dictionaries cover frequently used values, with both enumerated and custom-method dictionaries. That is a coherent design and it is the part of this framework most likely to be the reason you adopt it. The unanswered question is where the button-level identifier is checked. A button permission is a front end concept: the interface uses it to decide whether to draw a control, and a control that is not drawn is not a control that is forbidden. Whether the same identifier is also enforced on the server for the corresponding request is a different question, and the readme does not say. For a framework you will build an internal tool on, that is the first thing to check in the generated code and in the middleware, because an admin framework that relies on the interface to enforce permissions is an admin framework where every authenticated user is an administrator.

Payment gateways and a wallet ship in the box, and the homepage is a public demo

Two of the built-in capabilities deserve more attention than a starter framework usually gives them. The payment gateway integrates several payment methods including the two dominant Chinese mobile wallets and a third, and is described as needing only simple configuration. Funds management follows it, covering online top-up, order requests and refunds along the original payment route, withdrawals, and detailed records of changes to balances and points. Together those two are a money-handling surface: a wallet, a ledger, refunds and a payment integration, sitting in the same repository as your user management. A framework that shipped only the first would be neutral; one that ships both is making a statement about what it is for, and it is a statement worth accepting or declining consciously. The payment integration is not hidden, and that helps: the acknowledgements at the end of the readme credit a unified payment library for those gateways, so the code you are inheriting is identifiable and you can read it. The readme also says the project began as an exchange for mutual learning with no profit motive, and the demonstration environment is published with an administrator account and a six digit password. That last detail interacts with the repository metadata, because the declared homepage for this project is not a site or a documentation page, it is the demonstration system's admin login. So the first thing anyone evaluating this clicks is a shared instance they can log into as administrator. That is a reasonable thing to do for a demo and a poor first impression for anything else, and it is also the reason the installation documentation is a link rather than a page you land on.

Seven storage drivers, four queue backends, switchable at runtime

The infrastructure features follow a consistent pattern, and the pattern is the thing to evaluate. Attachment management supports file and image upload, chunked upload of large files with resumption after interruption, and a set of storage drivers covering local disk and five named object storage services plus a self-hosted one, switchable from the admin interface, with a file picker integrated. The message queue section says the same thing about a different subsystem: four backends, including two distributed brokers and a disk-backed queue, switchable to whichever suits the scenario. Scheduled tasks can be added, edited and deleted online and keep a log of execution results. Service monitoring watches processor, memory, disk, network and heap, and the service log section is unusually specific about capturing warnings, exceptions and crashes with their stack traces. The benefit of the switchable pattern is real. It means the same code runs against local disk in development and object storage in production, and that you are not committing to a storage vendor before you have one. The cost is equally real and nobody mentions it in the readme. Every driver is a code path, and each one has its own credential handling, its own retry behaviour and its own failure modes, and the configuration lives in the admin database where a bug in the configuration screen is a storage outage. The resumable upload is the feature most worth understanding before you rely on it, because chunked uploads hold partial files and a resume protocol has to reconcile them, and that is where the interesting bugs live. For most teams the sensible configuration is the boring one, and the value of the switch is that it is there if a future requirement forces a change.

Documentation in Chinese, the version on a branch, and no repository releases

Practical adoption facts, none of which are in the feature list. The documentation is four files inside the repository and all four are in Chinese: an installation guide, a local guide, an update history and a frequently asked questions page. There is no English documentation and no documentation site, so the code is readable in any language and the instructions are not, which is a real barrier for a team outside that market and a solvable one if you are willing to translate four documents. Versioning is unusual in a way that will bite you. The default branch is named for the release line rather than for a stable trunk, and the repository publishes no tagged releases at all, so there is no version to pin in a dependency declaration and no release notes to read except the update history page in the documentation. The practical consequence is that you track a branch, and a branch moves, so reproducibility depends on recording the commit you deployed rather than the version you read about. Two smaller signs of an ageing repository. The topic tags still describe the previous generation of this kind of framework, naming admin frameworks built on a different component library and a different major version of the front end library than the badges at the top of the readme claim, so search by the topic and you will find the wrong family. And the top-level file list has no workflow directory, so there is no visible continuous integration, no pull request template and no issue template, in a project that asks for contributions and describes multi-person collaboration as a feature.

MIT with a retention duty, and a disclaimer that points outward

The licensing note is longer than most and has two parts worth separating. The first is the grant: the project is free and open source under the MIT licence, which the note says means you pay nothing and need no permission to apply it to your own product, that you must retain all copyright information, and that the copyright of third party source and binaries bundled in the project is marked separately. Retaining the copyright notice is the attribution obligation the MIT licence imposes, so the second sentence is a restatement of the licence rather than an extra restriction. The notice also carries an all rights reserved line and a copyright range, and an all rights reserved phrase next to a permissive grant is a wording artefact rather than a change in terms; the MIT text is what governs. If your compliance process needs a single identifier, this one is unambiguous. The second part is the disclaimer, and it leans outward. The project states it is an open source learning project with no profit motive, that all commercial activity is unrelated to it, that users must not use it for illegal activity, that the project may cooperate with authorities if it finds such use, that it accepts no liability for damage caused by illegal use, and that the user must compensate third parties for any harm. A clause about cooperating with investigations is unusual in a framework readme and is worth noting as a fact about the project's posture rather than as a prediction. Two closing details. Support runs through a numbered chat group rather than through the forge, so prior answers are not searchable in the place you would look for them. And the readme acknowledges a free licence for the Go development environment, which suggests the maintainers work on this in an editor that would otherwise cost money.

Editorial conclusion

HotGo is a reasonable starting point if your team already works in this ecosystem, reads Chinese documentation without difficulty, and wants an admin system with users, departments, roles, menus, dictionaries, logs and scheduled tasks already assembled, because that list is long, coherent and the one thing the project has clearly optimised for. Two things should shape your evaluation. The AI positioning describes how you are expected to build with the framework rather than anything it does at runtime, so judge it on the generated-code and plugin story instead. And the payment gateway and wallet modules are bundled in rather than left to you, which makes the framework a less neutral base than it looks and puts a money-handling surface behind your login before you have written a line of business logic. Verify three things before building on it. Where permissions are actually enforced, since button-level permission identifiers are a front end concept and the readme does not say the API checks them. Which storage and queue backends you intend to use, since each one is a driver you inherit. And whether the branch you clone is the version you deploy, since the default branch is named for the release line and the repository publishes no tagged releases.

Frequently asked questions

Official sources

1. bufanyun/hotgo on GitHub
2. Issues
3. License: MIT
4. Project website
5. README