Chinese foundation models and their coding tools are moving quickly, but parameter counts and claims of being “close to a flagship model” do not replace project acceptance tests.
Do not choose a tool by parameter count alone. What matters is whether it works reliably in your network, account, payment, and development environment, and whether it leaves changes and test results that can be inspected.
For those in China who want to use AI to turn ideas into products, the tool threshold is indeed much lower than before.
It’s no longer just overseas models that are an option. Account stability, network conditions, and payment methods all affect the actual experience, making domestically available Chinese models a more realistic route.
Reported active-user counts, growth, or product outcomes can be interesting, but they are not independent proof that a workflow works. What matters here is a build path that any beginner can inspect.
Without a traditional programming background, a product can still be built through a sequence of checkable actions: choose the tool, set the boundaries, establish version control, complete one end-to-end path, test locally, and only then decide whether to launch.
This path is for a first product. It is deliberately simple, not universal; hosting, security, and engineering requirements vary by product.
What is provided here is just a path that is simple enough to go from zero to official launch, not the only answer.
Start with the smallest step.
1 one. First, choose a Coding Plan package from a domestic large AI model.
You need an AI that can help you write code.
Kimi, GLM, and Qwen can all be considered as candidates. Don’t argue about the rankings first; first confirm the budget, available regions, call limits, and the actual tasks you want to accomplish.
2 . Install the official Agent programming product that matches the model you selected.
After finalizing the Coding Plan, download the corresponding Agent programming product from the official channel.
ZCode, Qoder, Kimi Code, and similar products can all be evaluated. Compare official model support, tool permissions, project compatibility, and validation features instead of assuming that a vendor’s own agent must be the best fit.
Check the name before writing code. Review the primary domain, common extensions, trademark conflicts, and social handles. If the ideal domain is unaffordable, renaming early is easier than migrating after launch.
The steps below use a cloud server as an easy-to-follow example. Static sites and lightweight products may be better served by Serverless, managed cloud development, or a hosting platform; maintaining a server is not the default.
Before buying a server, compare expected users, region, bandwidth, storage, backup, and renewal price. Introductory offers and plans change, so confirm the current vendor page before paying.
You can let the Agent help you compare configurations, but purchasing, payment, and account authorization should be confirmed by yourself.
6 . If providing website services to mainland China, also confirm the ICP filing requirements.
This item will directly affect the launch time.
In mainland China, if your domain name is to provide external services, you must complete ICP filing. Without filing, domain resolution will be directly blocked by operators, and users won’t be able to access your website.
Submit identity, domain, and website information through the hosting provider’s filing process. Review times vary, so treat this as an external dependency in the schedule rather than promising a fixed duration.
Make sure to coordinate with development at the same time, don’t wait until the product is finished to think about filing.
An overseas product is not exempt from obligations. Choose a region near the intended users and still check local privacy, payment, content, and data-processing requirements.
7 . Create a dedicated project folder
Once you are ready, you should have clarified the domain, operating environment, filing status, and the AI programming tools you are using.
Now, create a folder on your computer.
That’s it. Create a folder with the same name as your product and place it wherever you like.
This folder will be the home for your product from now on: place code, configurations, and documents here.
8 . Let the Agent start working only in this project directory
Open the Agent programming product you installed in step two, and point the working directory to the folder you just created.
The specific operation varies slightly for each product, but it’s generally "choose a working directory" and then start the conversation.
From this moment on, your AI is stationed in your project. It can see your files, help you create new files, write code, run code, and debug code.
9 . Save versions using GitHub
GitHub is a commonly used code hosting platform. Code should not be kept on just one computer; otherwise, hard drive failures or device loss could make the project unrecoverable.
Therefore, you can register a GitHub account (free), have your Agent help you connect to your GitHub account, and then push your code to a private repository on GitHub. Note that it should be a private repository, not public.
You only need to tell your Agent one sentence. "Initialize a Git repository, connect it to my GitHub account, create a private GitHub repository, and submit the first initial version."
Now, the collaboration between you and your Agent officially begins.
10 First, open Plan mode and clarify the smallest goal.
Most Agent programming products have a Plan mode (also called planning mode). Use plain language to tell the AI what you want to do, and it will first help you figure out what needs to be done and list a checklist. Don’t start executing directly.
What you need to do at this step is to describe your product in the simplest and most straightforward language.
Note, don’t overthink it. You don’t need to draw prototypes, write requirement documents, or list all functions. Just mention the core thing you really want. Additional features can be added later, but the first version can be relatively simple.
Seeing positive feedback from that product first is stronger than anything else.
AI will generate a planning document based on your description. Take a look to see if it is in the direction you want, and once confirmed, proceed to the next step.
11 . Have the Agent implement in stages according to the Plan
Start execution only after the Plan is confirmed. It can create project structures, write code, and install dependencies, but it should stop after each segment to check modifications, command outputs, and current results.
12 . First accept locally
After the Agent has developed to a certain extent, it will give you a local preview address, most likely something like localhost: 3001 like this.
Open this address in your browser, and you will be able to see what your product looks like.
There’s no need to rush to deploy online at this time. Just work in this local environment, adjust things slowly. If the UI doesn’t look good, have the AI modify it; if the functional logic is incorrect, have the AI fix it, until you’re satisfied.
You’re responsible for defining the acceptance criteria, and the AI is responsible for execution. Don’t rely solely on visual impressions; the core paths, data saving, and error states all need to be tested in practice.
13 . Use the cleanliness.skill to unify and organize documents and code
When project documents begin to contradict one another, use a cleanup Skill to reconcile code rules, project state, and agent memory files.
During your previous development process, you may have had many rounds of conversations with AI and made many changes. Your code and documentation are likely a bit messy, and there may even be contradictions.
At this time, this is where the neatness.skill comes into play. Its sole purpose is to standardize and organize all your project documents, code rules, and AI memory files.
Because AI’s memory is limited, if you start a new conversation, it will forget a lot of the things discussed earlier. Without a clean, contradiction-free project document to fall back on, the AI will start to make things up. It will forget your previous design decisions and your product logic, then produce a mess of code that completely contradicts what was done before.
Open source address:
https://github.com/KKKKhazix/khazix-skills/tree/main/neat-freak
After running the cleanliness.skill, you end this conversation.
In the future, each time a new conversation starts, the AI only needs to read the documents in the project once to quickly restore context, understand the status of your project, and know what to do next.
14 . Gradually complete the necessary terminology in the project
At this step, you already have a runnable product, a clean code repository, and a basic version control process.
You don’t need to understand code, but you need to understand some terms, because the subsequent processes will use them frequently.
For example, Git, branches, main branch (main), PR, CI, testing processes, and so on.
You can directly ask the Agent to explain it to you.
You don’t need to learn everything at once, but at least you need to know what these terms refer to; otherwise, it will be difficult to verify later and hard to clearly explain the process.
15 . Establish a set of test processes that can be run repeatedly
The faster the Agent writes code, the more important automated testing and manual verification become.
You can directly tell your Agent, ‘Help me set up a complete testing process based on my project.’
If a private repository needs branch protection, first check whether the current GitHub plan and repository type support the required rules, then decide whether an account upgrade is necessary.
The core reason for buying this membership is just one thing: it allows you to enable branch protection in private repositories.
After you set the rules, no one, including yourself, can directly push code to the main branch. All changes must go through a PR, and the PR must pass CI tests before it can be merged.
Without branch protection, you or your agent might accidentally push problematic code directly to the main branch, causing the live system to crash, or you end up working against yourself by maintaining a very complicated set of scripts.
With branch protection, that path is blocked.
After purchasing, you can tell your agent, "I bought a GitHub Pro membership, help me enable branch protection, and set up a comprehensive, standardized, and professional testing process for my project."
Of course, it’s okay not to buy it; it’s just that once the project matures in the future, if you want to iterate rapidly, it will become a bit troublesome.
For deployment, start a clean conversation, provide only the minimum information required, and confirm backup, rollback, permissions, and health checks first. Never expose passwords or long-lived secrets in the conversation.
An agent can run commands and help diagnose problems, but a person must confirm the purpose, permissions, and result of every step. When cloud-console access is needed, expose only the necessary page and minimum permissions.
Then, your code will automatically run on your server twenty-four/seven.
Finally, it’s no longer local code.
17 . Connect the domain name, security certificate, and project
Tell the Agent what your domain name is, let it help you point the domain to your server, then get a free certificate and set up HTTPS.
All of this remains the same, you don’t need to handle it; just let your Agent do it.
After it’s done, enter your domain name in the browser, and you should be able to see your product.
It’s a real URL that anyone in the world can access.
Opening the product through its real domain is satisfying, but “the page loads” is not a sufficient launch check. Verify HTTPS, error pages, logs, backups, and rollback as well.
18 . Fix subsequent revisions into a roll-backable iteration cycle
Going live is not the end; it’s the beginning. From this step, your daily workflow is likely to become fixed. Create a new branch → state your requirements → Agent completes development → run through the O.C.D. skill unified documentation → submit a PR for CI testing → merge into the main branch → deploy online. Every revision, every new feature, every bug fix goes through this cycle. The process may seem complicated, but after two or three rounds, you’ll have muscle memory. The biggest advantage of this workflow is safety, because every change is on a branch and does not directly affect the main branch. If something goes wrong, you can discard that branch and start over, while the main branch always remains a stable, running version. It also allows you to stably handle three or four tasks concurrently.
19 . You may not be able to write code, but you must understand how the system operates
The most important part is not a command; it is retaining judgment over the system. You do not need to write every line, but you must know which endpoint a page calls, where data is stored, how permissions are decided, and how failure is recovered. Require the AI to explain the proposal, trade-offs, and risks. If the explanation is not clear, do not approve execution. Vibe Coding delegates execution to tools, not judgment.
20 After going online, gradually make up for basic operations and maintenance knowledge.
When a product just goes online, there might only be dozens of users, and the server can handle it easily.
But when your user base slowly grows, some things become different.
Cache mechanisms, anti-scraping, anti-DDoS, cost control for traffic and bandwidth—these things you don’t need to worry about in the early stage, but once the number of users passes a certain level, if you don’t manage them, they will come to bite you.
Don’t wait until someone racks up a four thousand yuan bill in one day to start learning; the awareness for prevention should come early.
This is a huge pit, you can learn it gradually.
Operations knowledge can be learned gradually, but monitoring, backups, cost alerts, and basic protection should be added before the risk arrives.
Written at the end
When something is unclear, give the agent the exact step, error, and expected result. Ask it to explain the concept, list the options, and provide a way to verify the answer.
Building a launchable product once meant crossing several separate barriers: programming, frameworks, databases, and operations.
Today’s tools lower the starting barrier, but an idea and an AI coding account do not equal a product. Scope, version control, testing, security, deployment, and maintenance still have to be handled deliberately.
Then, just start doing it.
AI will help you solve many execution problems, but acceptance, security, and trade-offs still belong to you.
Tools are easier to obtain; what is truly scarce is the patience to see an idea through to completion. The so-called golden age should start with a small, verifiable delivery.
For the first local implementation, follow this order to wrap things up.
Start by answering four questions on a single page: Who will use it, what needs to be accomplished, what counts as minimal success, and what will definitely not be done in this version. For complex projects, first explore and plan, then implement and verify; tests, screenshots, or expected outputs can all serve as proxy success criteria.
Then only implement a single end-to-end path. For example, a user submits a piece of data, and after refreshing the page, it still exists, and if there’s an error, a comprehensible message is shown. Do not expand to all pages at once, and do not consider fixed dummy data, invalid buttons, or states existing only in memory as completion.
When handling web pages, documents, or third-party dependencies, treat them as untrusted input, review commands, limit permissions, and double-check critical files.Codex can read project conventions and test commands from AGENTS.md; the more specific these instructions are, the easier it is for agents to work under the same standards.
At the finishing stage, have a human review the generated code, run tests, and manually walk through critical paths. If you cannot explain where the data is stored, how permissions are determined, or how errors are recovered, it is not yet ready for release.