This document explains what problems the system solves, what the platform and each product are responsible for,
how content flows through the system, what each part can do, and exactly how to work in the admin panel.You can read it without a technical background. If you just want to get started quickly, skip straight to Section 7, “Day-to-Day Workflow.”
Document | What It Covers |
|---|---|
This document | The problems the system solves, the boundaries between the platform and products, how content flows, what each part can do, and day-to-day workflows |
Publishing Workflow | The full draft → test → production workflow, what publishing checks cover, going live and taking content offline, and the differences between landing pages and blog posts |
Component Library | Why we moved from configuring entire pages to building with modular components, where components come from, and what they protect you from |
Roles and Permissions | What you can see and do, how operations and development responsibilities are divided, and how to sign in |
Frequently Asked Questions | When something goes wrong, troubleshoot it by following “symptom → cause → solution” |
A shared content platform for multiple products.
It is not meant to solve a lack of editors, but five problems that are already slowing everyone down.
Previously, every product’s admin panel was packed into the same system. Integrating a new product meant changing code, adding menus, and adding permission checks, then releasing the entire system again. This created three forms of tight coupling:
Coupled release schedules — A small feature for Product A had to wait for a shared release window; a bug in Product B could block Product A’s release
Coupled blast radii — A crash or memory leak in any module could spread to every product’s admin panel
Coupled technology stacks — A new product’s admin logic had to be written in that system, preventing the product from using its own repository and release cadence
As a result, integrating a product became increasingly expensive. Eventually, no one wanted to do it, so each team built its own system—bringing us back to a collection of separately maintained admin panels.
Now: Each product is deployed independently, and the platform communicates with it only through interfaces and sign-in. Integration requires no platform code changes and takes up no release window; a product issue cannot spread to the platform, and the platform cannot access the product’s business data or secrets.
Previously, permissions were approximated using “the ids of the products you can view.” This could not express “张三 works in operations for Product A, in development for Product B, and has read-only access to Product C,” let alone whether 张三 could access the production environment.
Conventions and people’s memories were the only safeguards, creating a high risk of unauthorized access and making incidents difficult to explain.
Now: Permissions are defined across three dimensions—product × role × environment—and denied by default; the operations and development domains are isolated from each other.
Every product needs landing pages, SEO, multilingual content, and structured data, so these capabilities were rewritten for every new product. Implementations were inconsistent, and SEO behaved differently in Product A and Product B; sitemap was hard-coded, and operations had to ask development to release a new version just to change landing-page copy.
Now: These capabilities are built once in the platform and shared by every product. Operations can make and publish changes independently, and production updates automatically after publication, with no product redeployment required.
Previously, each landing page had its own configuration, which hard-coded the sections included on that page. That configuration belonged only to that page: Changing the order, removing a section, or adding an introduction required changing the configuration structure or even the code; If page B needed a section built for page A, the only option was to copy it. The two copies would then evolve independently and become increasingly different.
The more pages there were, the more fragmented the configurations became and the more expensive changes were.
Now, a page is not a single configuration but a sequence of component instances. Product teams turn reusable sections into components, while operations teams drag components onto a page, arrange them, and add content — they can add a section, remove one, or change the order themselves. The same component can be reused across any number of pages, so every improvement benefits them all. The same applies to blog posts, where components can be inserted directly into the body.
(See the component library for details.)
Previously, there was no unified audit trail or single sign-on — each admin system had its own login, and each product maintained its own accounts.
Now: one login, with a complete audit trail for every action.
One of this system's design goals is to ensure that integrating another product is no longer an engineering project.
Before | Now | |
|---|---|---|
Platform code | Modify the shared admin system, add menus, and add permission checks | No changes |
Deployment | Redeploy the entire shared admin system, with multiple products queued and handled sequentially | Not required |
Content admin system (landing pages/blogs/SEO/localization) | Build it separately for each product | No need to build it — the platform provides it for everyone |
The product's own database | Create a set of content tables | No tables to create |
Account system | Build its own login and permissions system | Integrate with the platform's single sign-on |
What must be built for a new product | Admin system + content capabilities + login | Only define what its own pages look like |
The fourth row is not an estimate but a measured result: in one real project that has already been integrated, its own database contains only 2 tables (and both are used for visitor login on its public site), with 1 database migration script file. Landing pages, blogs, categories and tags, SEO, and every language version are all stored on the platform.
This has two direct benefits: integration is lightweight, and integration is reversible — if the product stops using the platform one day, its database remains clean.
Whether the operations team can manage content independently depends on what happens when something goes wrong. This system uses several structural safeguards to minimize the cost of errors:
Mechanism | What It Prevents |
|---|---|
Two environments with sequential promotion only | Content cannot reach the production site until it has been verified on the test site |
Automated pre-publish checks | Structure, component availability, multilingual completeness, categories, and SEO are all checked at once; publishing is blocked if any blocking issue is found |
Forms generated from component declarations | The product team defines what can be entered, the permitted length, and whether each field is required, making the forms impossible to break through data entry |
Production component versions are locked | If the product team breaks a component, pages already in production remain unaffected |
Reference checks before deletion | This prevents scenarios where deleting a component suddenly leaves a page blank |
Permissions by product × role × environment | Anything not explicitly permitted is off-limits; the operations and development domains are mutually isolated |
Complete audit trail | You can see who changed what and when |
As a result, the operations team can update copy without waiting for an engineering release. Production updates automatically after publication, so the product team does not need to redeploy either.
The system intentionally draws a clear boundary:
Managed by the Platform | Managed by the Product Team | |
|---|---|---|
Content (landing pages, blog posts, categories, SEO, and multiple languages) | ✅ Stored on the platform and maintained in the platform admin | — |
How pages look (layout, styling, and components) | — | ✅ Defined in the product team's own code |
Business data (users, orders, etc.) | — | ✅ Neither stored by nor accessible to the platform |
Sign in | ✅ Provided out of the box | Connect it and start using it—there is no need to build a separate system |
The platform does not create any content tables in the product database.
In one real-world project that has already been integrated, its own database has only 2 tables, both used for visitor sign-in on the frontend; there is only 1 database migration file. Landing pages, blog posts, categories and tags, SEO, and all language versions are stored on the platform.
This makes the integration reversible—if you stop using it one day, the product database remains clean.
The platform manages content, while the product manages its own business operations (the platform cannot and should not access users, orders, or similar data).
The product's own admin panel does not need to be replaced. It can be embedded in the platform: open “Project Admin” from the sidebar, and the product's own admin interface runs there, with the platform carrying over the signed-in session—no need to sign in again.
For users, content and business operations are in one place, so there is no need to switch back and forth between systems.
This section lays the foundation for everything that follows. Four rules apply throughout the site.
你在后台改 → 发布到测试站 → 升级到生产站
（草稿） （自己验收） （用户可见）
You cannot skip testing and push directly to production. The version in production is always the version that was verified in testing.
This is the easiest rule to overlook: after you make and save changes in the admin panel, the live site does not update immediately—you need to publish them.
The same applies to categories and tags. Selecting a category for a post changes the draft; the live site will not reflect the change until the post is published again. The interface displays a notice telling you that “there are unpublished changes.”
Each page or post has a primary language (labeled “Baseline” in the interface).
A field that has not been edited separately → automatically follows the primary language and changes whenever the primary-language content changes
A field that has been edited or translated → becomes independent from that point on, and subsequent changes to the primary language will not overwrite it
There is no need to maintain a “Follow primary language” toggle—the system determines whether a field should follow based on the field's content itself.
When you click Publish, the system first checks structural integrity, whether the components used are available in the current environment, whether all languages intended for release are complete, whether categories are valid, and whether the SEO and structured data are valid.
Any issues are listed, and blocking issues must be fixed first. Each one includes a link that takes you directly to where it can be fixed. After publishing succeeds, the live site updates automatically, and the product does not need to be redeployed.
Build a page from components. The page structure is on the left, a live preview is in the center, and the fields for the currently selected component are on the right.
You can:
Create a new page, or select **“Duplicate as New Landing Page”** from an existing page
Drag and drop components to reorder them. You can also choose which components to place in fixed positions such as the header and footer (called slots in the interface).
Fill in SEO and structured data
Full-page AI copy: review all the text on the page at once
Excel import and export: export an entire page or a single component to a spreadsheet, make your changes, and import it again — ideal for bulk copy edits and adding multiple languages in bulk
Write body content just as you would in a document editor, and insert components directly into the body (such as quote blocks, key-point cards, and pricing tables).
The four tabs on the right are:
Content — article title, summary, path, cover image, categories and tags, and display preferences
Table of contents — automatically generated from headings in the body; click an entry to jump to it
SEO — search title, description, and keywords; social sharing card copy; and structured data
Components — select a component in the body, then fill in its fields here. Plugin slots, such as those in the sidebar and footer, are also configured here
You can upload a cover image or generate one with AI.
See which components the product has, which fields each component contains, and which pages use them (“Usage locations”).
Components are declared in the product's own code, and the platform generates forms from those declarations. This means:
You can't enter invalid content — the declaration determines what you can enter, how long it can be, and whether it is required
The version currently used in production is locked — if the product team breaks something, the live site remains unaffected
Before deleting a component, you'll be told where it's used — so you won't “delete a component and suddenly find a page empty”
When the product team updates a component, click “Sync Components” here to pull in the update.
Categories are hierarchical, and you can create subcategories. Blog posts must be assigned to the lowest level; landing pages can be assigned to any level
The identifier (slug) is optional — if provided, the product can use it for routing or filtering; otherwise, it is used only for internal categorization in the admin
Categories and tags have their own test/production status, shown by two small dots in each row: test on the left and production on the right (gray = unpublished, green/blue = published, amber = changed but not yet republished)
When you publish content, the categories it uses are automatically published with it, so you don't need to publish them separately first
You can't unpublish a category while content that uses it is still live — otherwise, that content would suddenly disappear from archive pages
Switch languages at the top of the editor. To translate, open “AI Assistant” and switch to “Translate.” Available scopes:
Scope | What gets translated |
|---|---|
Components/plugins only | Only fields in components on the page or in the body |
Body only | Only text in the body |
Page content | Titles and summaries |
Page SEO | Copy in the SEO fields |
Entire article | All |
There is also a **“Correct to Current Language”** option: if a field contains text in another language, click it to convert the text in place to the current language.
Translation does not alter the structure. Code blocks, inline code, and link URLs in long-form content remain unchanged character for character before and after translation; images and category tags are not translated either.
Capability | Description |
|---|---|
Write, rewrite, and polish copy | Entire landing pages, blog content, component fields, titles, and summaries |
Translate | See the previous section |
Optimize SEO | Search titles, descriptions, and keywords + social card copy—all seven fields at once |
Generate images | Save images directly to the project's image storage and set them as the cover image |
Add category and tag names in other languages | Complete them with one click under “Categories / Tags” |
AI does not touch non-copy fields such as link URLs, image URLs, code, or prices—so it cannot break the page.
Configure and switch providers under “AI Settings”: OpenAI, Anthropic, Google, DeepSeek, OpenRouter, Fal, and Replicate. You can choose separate providers for copywriting and image generation.
The structured data (JSON-LD) section is not generated by AI—it recommends content according to rules based on the page's existing content. Just click “Generate with One Click”; it is more accurate than asking a model to guess.
Publish from the editor: select a language → run checks → publish. Because content must pass the checks before going live, publishing can only be initiated from the editor.
Unpublish directly from the list: each language, staging site, and production site is managed independently, and you must confirm the action.
The top button accurately reflects the status: 发布到测试 / 重新发布到测试 / 已发布到测试
Using a multilingual blog post as an example, here is the process from scratch to launch:
Create—click “New Post” in the blog list to open the editor.
Write in the primary language—confirm at the top that the current language is labeled “Baseline,” then write the title, summary, and body content.
Featured image — Upload a cover image in the “Content” tab on the right, or click “AI Generate” (Describe a scene in the prompt; don’t write “based on the article content”—the AI can’t see the article body during generation.)
Insert components — Use “Insert” to add components to the article body. After selecting a component, fill in its fields in the “Component” tab on the right.
Categorize — Select categories and tags in the “Content” tab.
Add SEO — In the “SEO” tab, click “AI Optimize SEO” to generate all seven fields at once, then click “Generate with One Click” to add structured data.
Translate — Switch to another language, then select “AI Assistant” → “Translate” → choose “Entire Article” as the scope → select the target language → send → apply.
Preview — Click “Preview” at the top. You can switch between desktop and mobile views, and between light and dark modes.
Publish to test — Click “Publish to Test” at the top, select the languages, and publish after the checks pass.
Review — Check it on the test site.
Promote to production — Select “Promote to Production.” Only languages that are live on the test site and whose content exactly matches the test version can be promoted.
(The interface labels these as Test exact online.)
The landing page workflow is the same, except that steps 2~4 involve dragging in components and filling in fields.
Long-form writing: Creating and rewriting entire articles are currently supported. Outline planning and section-by-section continuation could be added in the future.
Terminology consistency: Translation currently preserves structure and links. A site-wide glossary could be added in the future to keep proper nouns consistent across articles.
More relevant images: Images are currently generated from prompts. In the future, the generator could use the article content when creating them.
Want to fully understand the publishing pipeline? → Publishing Workflow
Want to understand how pages are built? → Component Library
Want to know what you can do and why some things can’t be changed? → Roles and Permissions
Have a specific issue? → Frequently Asked Questions
