在 gfast 项目中，业务模块并不总能直接交给 tools_gen_table 代码生成器处理。复杂表单、特殊交互、既有业务表改造，往往需要开发者手写前后端代码。gfast-module-dev 的价值在于：让 AI 在手写模块时仍遵循项目生成器的目录、分层、接口和页面风格，并复用富文本、上传、选择器、字典与权限等既有组件。
这不是另一套开发框架，而是一份项目级开发约束。它把“生成器产物长什么样、已有组件怎样接入”固化为 AI 可执行的技能，使手写代码不会逐渐偏离项目惯例。
一致性比快速生成更重要
代码生成器通常隐含了一系列团队约定：GoFrame 后端的控制器、服务和数据访问如何组织；Vue3 页面如何拆分查询区、表格、弹窗与权限按钮；列表接口和保存接口采用什么字段命名；字典值怎样渲染；上传结果如何保存。
如果业务模块绕开这些约定，即使功能可以运行，也会带来长期成本：
- 新页面的权限判断方式不统一，按钮可能展示却无权操作。
- 富文本和上传字段各自处理，数据格式在不同模块中漂移。
- 选择器、字典标签和状态筛选重复实现，后续组件升级难以覆盖。
- 后端接口风格与
tools_gen_table产物不同，维护者需要在多个套路之间切换。
gfast-module-dev 的目标是让 AI 先读取项目现有实现，再按生成器的模式扩展，而不是凭通用经验临时拼出一个 CRUD 页面。
让 AI 先对齐“参照物”
使用这类项目级技能时，最有效的输入不是一句“帮我生成商品管理”，而是明确业务模型、相似模块和组件需求。AI 需要从仓库中确认真实组件 API、路由约定和权限标识，不能把其他 Vue 项目的写法直接搬进来。
可以把需求整理成一个可直接交给 AI 的任务说明：
请使用 gfast-module-dev 为 product 表手写商品管理模块。
字段：id、name、category_id、status、cover_url、content、sort、created_at。
要求：
1. 后端与 tools_gen_table 生成模块保持同一目录和接口风格。
2. category_id 使用项目现有选择器组件，不自行请求并拼装树。
3. status 复用现有字典；列表和编辑弹窗均按项目已有写法处理。
4. cover_url 使用现有上传组件；content 使用现有富文本组件。
5. 查询、新增、编辑、删除、批量删除和导出遵循相邻模块的权限控制方式。
6. 先查找一个最接近的现有模块，说明将复用哪些模式，再开始修改文件。
这段说明的关键在于“先找相似模块”。技能负责引导 AI 按项目规范工作，但具体组件的属性、事件、返回值和字段结构，仍必须以当前仓库中的可运行代码为准。
组件复用不是只把控件放进页面
富文本、上传、选择器、字典和权限组件通常横跨表单展示、接口传参和列表回显三个环节。只完成其中一个环节，页面看起来可用，数据却可能无法正确保存或还原。
以封面上传为例，需要确认上传组件最终写入的是 URL、文件 ID，还是对象数组；编辑时又需要把数据库中的值转换成组件所接受的初始值。富文本也要确认是保存 HTML、JSON 文档还是其他序列化格式。
字典字段同样不能只在编辑页做下拉框。一个完整模块至少要统一：
- 查询条件中的筛选值；
- 编辑表单的可选项与提交值；
- 列表表格中的标签或文本回显；
- 后端对非法字典值的校验策略。
权限处理也应沿用项目已有边界。前端按钮权限用于减少无效操作，后端接口权限才是实际保护点。手写模块时，按钮标识、路由权限和服务端鉴权应与生成器模块保持对应关系。
可以这样实践：用参照模块驱动一次开发
下面的命令适合在开始编码前执行。它不假设仓库的具体目录，而是帮助开发者快速找到生成器产物、组件调用和权限写法，再把结果作为 gfast-module-dev 的上下文。
# 在仓库根目录执行：定位生成器产物和已有组件调用
rg -n "tools_gen_table|permission|dict|upload|editor|selector" \
--glob '*.go' --glob '*.vue' --glob '*.ts' .
# 再按业务关键词寻找最接近的模块，例如分类、内容或商品
rg -n "category_id|content|cover_url|status" \
--glob '*.go' --glob '*.vue' .
找到参照模块后，可以建立一份小型映射清单，再让 AI 依此实现新模块：
# module-plan.yaml
module: product
reference_module: article
fields:
category_id:
component: existing-category-selector
storage: integer
status:
component: existing-dictionary-select
dictionary: common_status
cover_url:
component: existing-upload
storage: string
content:
component: existing-rich-text-editor
storage: html
permissions:
list: system:product:list
add: system:product:add
edit: system:product:edit
delete: system:product:delete
这里的组件名、字典编码和权限标识只是规划格式，不应当被当作仓库事实。实施时应替换成项目内已经存在的组件名称和真实权限字符串。这样做的好处是，业务字段与实现决策先被显式确认，AI 不会在编码过程中擅自猜测。
把“像生成器产物”变成验收条件
模块完成后，不要只验收页面是否能增删改查。更可靠的检查方式，是拿它与一个 tools_gen_table 生成模块并排比较：目录结构是否一致，控制器和服务职责是否一致，分页和批量操作是否沿用同一模式，表单关闭和列表刷新是否符合已有交互。
上线前可以重点检查以下事项：
- 新增后列表能正确回显字典、选择器和上传字段。
- 编辑已有记录时，上传和富文本组件能恢复原始值。
- 没有前端权限时按钮不可操作；直接调用接口时仍受到后端权限约束。
- 删除、批量删除、导出等操作使用项目既有确认、提示和审计方式。
- 新模块没有引入一套平行的组件封装或接口命名规则。
gfast-module-dev 适合处理“生成器覆盖不到，但仍必须像生成器一样”的开发工作。它并不能替代对业务规则、数据迁移和权限模型的设计；它解决的是实现层的一致性。把相似模块和真实组件 API 提供给 AI，再用生成器风格做验收，手写模块才能既满足个性化需求，也不会成为项目中的异类。