我怎么让 AI 接手后台文章管理页，而不是复制出第二套后台

摘要：本文探讨了在后台开发中如何有效利用 AI 进行协作，核心在于构建并复用统一的页面基座（如 ModuleListShell 组件和 useArticleTable 等 composable），而非让 AI 从零开始复制第二套后台页面。通过 Sourcelin Blog 项目实例，文章展示了如何将查询、表格、表单等通用逻辑模块化，使 AI 只需填充配置即可快速生成新管理页面，从而提升开发效率、保证代码一致性，并避免权限、API 契约等体系被破坏。

后台页面如果做多了，很容易进入一种很熟悉的状态：
每个页面看起来都差不多，真正不同的只有字段、操作按钮和少量业务规则，但代码却越写越散。

Sourcelin Blog 这套后台，我后面最想收住的一件事，就是别再让 AI 帮我“再复制一套后台页”，而是让它先学会复用现有页面壳和模块化结构。

如果说前台最容易把逻辑和展示缠在一起，那后台最容易犯的错就是：
每来一个页面，就复制一套查询表单、表格、分页、弹窗和提交逻辑。

Sourcelin Blog 的后台，后面我比较重视的一件事，就是把这种“重复页面”收进共享壳里。
这样 AI 介入后台时，就不会每次都从零开始拼一套表格页。

这个项目后台文章管理的入口

相关文件在这里：

• sourcelin-ui/sourcelin-ui-admin/src/views/blog/article/index.vue
• sourcelin-ui/sourcelin-ui-admin/src/views/blog/composables/useArticleTable.ts
• sourcelin-ui/sourcelin-ui-admin/src/views/blog/shared/ModuleListShell.vue
• sourcelin-ui/sourcelin-ui-admin/src/api/blog/article.ts

其中 API 层非常薄：

import { createBlogCrudApi } from "./base";
import type { ArticleItem, BlogQueryParams } from "@/types/api";

const ArticleAPI = createBlogCrudApi<ArticleItem, BlogQueryParams>("/blog/admin/article");

export default ArticleAPI;

这段代码很适合当后台 AI Coding 的例子，因为它说明了一件事：
后台很多能力已经不是“从零写 URL”，而是建立在统一 CRUD 基座上。

后台真正有价值的地方，在 useArticleTable.ts

这层把查询字段、表格列、表单字段、状态更新和选项加载都收进了 composable：

const queryFields = computed(() => [
  { prop: "keywords", label: "关键字", type: "input", placeholder: "标题/摘要" },
  { prop: "categoryId", label: "分类", type: "select", options: categoryOptions.value },
  { prop: "status", label: "状态", type: "select", options: ARTICLE_STATUS_OPTIONS },
]);

这种写法最大的好处是，页面本身就会很轻。
AI 做后台页时，也更容易在一个固定模式里工作。

页面层为什么越来越适合交给 AI

因为像评论管理、文章管理、分类管理这类页面，本质上都是一个变体：

• 查询区
• 表格区
• 分页
• 弹窗表单
• 行级操作

这个项目里对应的壳已经存在了：

<ModuleListShell
  title="评论管理"
  description="评论审核、来源追踪与删除治理。"
  :module-api="CommentAPI"
  :query-fields="queryFields"
  :columns="columns"
  :form-fields="formFields"
  :row-actions="rowActions"
/>

这意味着你再让 AI 做一个新的后台管理页时，它不是从空白页开始，而是在既有壳上填配置和少量业务逻辑。

我一般怎么给 AI 下这种后台任务

请在 Sourcelin Blog 管理后台中新增或调整一个 blog 模块管理页面。
要求：
1. 页面只放在 src/views/blog/** 下
2. 接口统一走 src/api/blog/**
3. 优先复用 ModuleListShell 和现有共享组件
4. 查询字段、列配置、表单字段拆到 composable
5. 不改变现有权限逻辑
6. 最后执行 pnpm run type-check 和 pnpm run lint

我自己现在更看重后台 AI Coding 的什么

不是“能不能帮我做出一个页面”，而是：

• 有没有复用现有壳
• 有没有沿用权限体系
• 有没有继续遵守 API 契约
• 有没有避免复制粘贴出第二套页面协议

这几个点，比单纯生成一个表格页重要得多。

这类任务里 AI 最容易跑偏的点

• 不看共享壳，直接重写一套页面
• 页面里散落太多 UI 状态和请求逻辑
• 忽略按钮权限、菜单权限的既有体系
• 改动了 API 消费方式，导致联调返工

后台这类场景其实很适合 AI，前提是你先有一个稳定的页面基座。
Sourcelin Blog 里这层基座已经有了，所以后面的迭代速度会快很多，也更适合持续写成系列内容。

项目地址

• 在线演示：http://sourcelin.cn
• Gitee：https://gitee.com/my_lyq/sourcelin-cloud-blog
• GitHub：https://github.com/SourceLin/sourcelin-cloud-blog

如果你刚好在找一个：

• 微服务博客系统
• Spring Cloud Alibaba 实战项目
• Vue 3 + Java 全栈项目
• 毕设 / 课程设计参考项目
• 支持 AI 协作开发的开源仓库

可以看一下这个项目。欢迎试用、提 Issue，也欢迎点个 Star 支持一下。