无尘阁日记

无尘阁日记

把整套系统喂给 GPT 做需求改造的标准提问模板
2026-04-08

可以。下面这份是我给你整理的企业系统改造标准提问模板。
你以后只要按这个格式，把系统信息、旧逻辑、新需求贴进去，GPT输出的质量会稳定很多。

企业系统改造标准提问模板

一、适用场景

这套模板适用于这些需求：

  • 购买的现成系统要二开

  • 老系统新增功能

  • 旧流程改造

  • 接口对接调整

  • 数据表新增或变更

  • 主键、业务键、状态流转调整

  • 日志、审批、同步、绑定类逻辑改造

二、标准总模板

你现在是一名资深系统架构师、资深后端开发工程师、资深数据库设计工程师，擅长阅读老系统、定位需求影响面、设计最小改动方案，并输出可直接落地的代码。

我现在有一个【现成系统二次开发/老系统改造】需求，请你基于我提供的系统信息、现有代码、表结构、业务规则，帮我完成需求分析与改造方案设计。

你的目标不是空泛讲思路，而是：
1. 先读懂现有逻辑
2. 判断这次需求应该改哪里
3. 判断要不要新增表/字段/索引
4. 输出改造方案
5. 必要时直接输出完整代码和SQL
6. 最后做一次自检，检查是否有遗漏点和风险点

请严格按我要求的输出结构回答，不要跳步，不要省略关键影响面。

【一、项目背景】
- 系统类型：
- 技术栈：
- 框架：
- 数据库：
- 缓存/消息队列：
- 这是买来的系统还是自研系统：
- 当前改造模块名称：
- 当前需求属于：新增 / 修改 / 重构 / 兼容旧逻辑 / 接口对接 / 数据迁移

【二、业务背景】
- 当前业务是做什么的：
- 本次改造想解决什么问题：
- 为什么要改：
- 业务上最重要的约束：
- 哪些旧逻辑不能破坏：
- 是否要求兼容历史数据：
- 是否要求兼容旧接口：

【三、当前系统现状】
请先理解当前系统的已有逻辑：
- 当前核心流程：
- 当前入口方法/接口：
- 当前主要Service：
- 当前主要Model：
- 当前涉及的表：
- 当前主键/业务主键：
- 当前状态流转：
- 当前日志记录方式：
- 当前是否有事务：
- 当前是否有幂等/去重/防重逻辑：

【四、我提供给你的材料】
以下材料请你结合起来分析：
1. 表结构
2. 关键代码
3. 接口入参与出参
4. 旧逻辑说明
5. 新需求说明
6. 特殊业务规则
7. 示例数据（如有）

【五、现有表结构】
（把相关CREATE TABLE语句贴在这里）

【六、现有关键代码】
（把controller / service / model / repository / helper等关键代码贴在这里）

【七、旧逻辑说明】
请先按我给的内容理解当前逻辑，不要脑补系统不存在的调用链：
- 当前是怎么创建的：
- 当前是怎么更新的：
- 当前是怎么查询的：
- 当前是怎么删除/解绑的：
- 当前依赖哪些字段：
- 当前哪些字段看起来像主键，但实际上不是：
- 当前有哪些隐含规则：

【八、新需求说明】
本次需求如下：
- 要新增什么：
- 要修改什么：
- 要废弃什么：
- 要兼容什么：
- 哪些字段要新增：
- 哪些字段要改为新的业务主关联键：
- 哪些地方要写日志：
- 哪些地方要加校验：
- 哪些地方要保留旧逻辑兜底：

【九、技术约束】
- 只能新增，尽量不要大改旧代码 / 或允许重构
- 是否允许加表：
- 是否允许加字段：
- 是否允许改索引：
- 是否允许改接口入参出参：
- 是否允许数据迁移：
- 命名空间要求：
- 代码风格要求：
- 是否要求直接给可运行代码：

【十、你的输出要求】
请按以下顺序输出，不要打乱：

第一部分：需求理解
- 用通俗但专业的话，复述你理解的当前系统逻辑
- 复述你理解的新需求
- 明确指出这次改造的核心变化是什么

第二部分：影响面分析
请按以下维度逐项分析：
1. 数据库层
2. Model层
3. Service层
4. Controller/API层
5. 日志层
6. 状态流转层
7. 历史数据兼容层
8. 风险点与边界条件

第三部分：数据库改造方案
- 是否需要新表
- 是否需要新增字段
- 是否需要新增索引
- 是否需要唯一约束
- 是否需要数据迁移
- 输出对应SQL

第四部分：代码改造方案
- 哪些类要改
- 哪些方法要改
- 哪些方法建议新增
- 每个改动点的目的是什么
- 先给改造说明，再给代码

第五部分：完整代码
如果信息充分，请直接输出完整可落地代码：
- Model
- Service
- Controller
- SQL
- 公共方法
- 常量/枚举
- 日志处理
- 事务处理

第六部分：自检清单
请你最后强制检查以下问题是否遗漏：
1. 是否有旧字段遗漏引用
2. 是否有查询条件和更新条件不一致
3. 是否有主键和业务主键混用
4. 是否遗漏日志
5. 是否遗漏事务
6. 是否遗漏幂等/防重
7. 是否遗漏历史数据兼容
8. 是否遗漏空值判断
9. 是否遗漏异常处理
10. 是否遗漏索引优化
11. 是否遗漏回滚/兜底逻辑

【十一、重要要求】
- 不允许脱离我给的代码和表结构乱猜
- 如果某个地方信息不足，请明确标注“待确认”
- 不要只讲概念，尽量落到具体表、具体字段、具体方法
- 不要只给伪代码，能完整就完整
- 所有结论要尽量能映射到我给的代码、表结构或需求描述
- 如果你发现我的需求本身可能有坑，请直接指出

三、最好用的分阶段模板

上面那个是“总模板”。
但更推荐你实际使用时，分四轮问。这样质量更高。

第一轮：先做影响分析

你现在是一名资深老系统改造专家。

我会给你现有系统的表结构、关键代码、旧逻辑和新需求。
请你先不要急着写代码。

你的第一目标是：
1. 读懂当前逻辑
2. 判断这次需求改动会影响哪些地方
3. 判断要不要新增表、字段、索引
4. 找出最容易漏改的地方
5. 明确哪些信息已经足够，哪些地方还待确认

请按以下结构输出：
1. 你对当前逻辑的理解
2. 你对新需求的理解
3. 本次改造的核心变化
4. 影响面分析（数据库、Model、Service、Controller、日志、状态、兼容）
5. 风险点
6. 待确认点

以下是材料：
（粘贴表结构、关键代码、旧逻辑、新需求）

第二轮：专门做数据库方案

基于上面已经确认的影响面，请你现在只做数据库改造方案，不要输出业务代码。

请完成以下内容：
1. 判断是否需要新增表
2. 判断是否需要新增字段
3. 判断是否需要加索引或唯一约束
4. 判断是否需要做历史数据迁移
5. 判断字段类型是否合理
6. 判断命名是否清晰
7. 输出完整SQL

输出结构：
1. 数据库改造总说明
2. 表级别改造建议
3. 字段级别改造建议
4. 索引建议
5. 数据迁移建议
6. 最终SQL

以下是上下文：
（粘贴已确认的信息）

第三轮：专门做代码改造方案

基于前面已经确认的需求和数据库方案，请你现在只输出代码改造方案，不要急着一次性给全部完整代码。

请按以下结构输出：
1. 哪些类要改
2. 哪些方法要改
3. 哪些方法建议新增
4. 每个改动点的目的
5. 每个改动点的输入输出变化
6. 哪些逻辑要兼容旧流程
7. 哪些地方需要事务
8. 哪些地方需要日志
9. 哪些地方需要异常处理
10. 哪些地方最容易漏

上下文如下：
（粘贴前面的分析结果和数据库方案）

第四轮：再让它输出完整代码

现在请基于前面已经确定的改造方案，直接输出完整可落地代码。

要求：
1. 代码风格与现有项目一致
2. 命名空间按我给的来
3. 能复用旧逻辑的尽量复用
4. 关键地方加注释
5. 不能只给伪代码
6. 包含必要的事务、异常处理、日志处理、空值判断

请按以下顺序输出：
1. SQL
2. Model
3. Service
4. Controller
5. 公共方法
6. 常量/枚举
7. 如有必要，补充调用示例

最后再附一份“改动自检清单”。

以下是完整上下文：
（粘贴最终确认后的信息）

四、你最该补充的关键信息

你以后喂系统时，最少要补这几类，不然它很容易“看起来懂了，其实没真懂”。

1. 表结构

最重要。至少给：

  • 主表

  • 关系表

  • 日志表

  • 配置表

  • 状态表

  • 版本表

2. 核心代码

最少给：

  • Controller

  • Service

  • Model

  • 公共方法

  • 当前需求直接相关的方法

3. 当前逻辑说明

一定要人工补一句，不然它容易误判。

例如：

  • 当前虽然有 project_code，但不能当稳定业务主键

  • 真正业务主关联键是 norming_project_id

  • 更新逻辑必须优先按 norming_project_id 查

  • 查不到时才能按 project_code 兜底

  • 日志展示可保留 project_code，但关联不可以再依赖它

这种话非常关键。

4. 新需求的边界

例如：

  • 是完全替换旧逻辑，还是兼容旧逻辑

  • 是只新增字段，还是允许改字段

  • 是最小改动，还是允许重构

  • 是只改查询，还是查改写都改

  • 是只处理新数据，还是历史数据也要补齐

五、你可以直接复制的极简版模板

如果你不想每次写那么长，就用这个短版。

你现在是一名资深老系统改造专家、资深后端工程师、资深数据库设计工程师。

我现在要改一个现成系统，请你根据我给你的表结构、关键代码、旧逻辑和新需求，帮我做：
1. 当前逻辑理解
2. 需求理解
3. 影响面分析
4. 数据库改造方案
5. 代码改造方案
6. 完整SQL
7. 完整代码
8. 最后做自检，检查是否有遗漏点

注意：
- 不要脱离我给的信息乱猜
- 信息不足的地方请明确标注“待确认”
- 重点分析：要改哪些表、哪些字段、哪些方法、哪些接口、哪些日志、哪些状态流转
- 注意旧逻辑兼容、事务、幂等、异常处理、空值判断、索引优化

以下是材料：
【表结构】
（贴SQL）

【关键代码】
（贴代码）

【旧逻辑】
（贴说明）

【新需求】
（贴说明）

【约束】
（贴约束）

六、我建议你固定加上的一句话

这句话非常有用，建议你以后每次都放进去：

不要根据“看起来合理”来补全系统调用链，只能基于我给的代码、表结构、业务说明来判断；如果判断依据不足，请明确写“待确认”，不要脑补。

因为这是防止它“自作聪明”的关键一句。

七、再给你一个“代码审查模板”

当它已经给你代码后，你可以再追问一轮，让它自己审自己。

请你现在站在资深代码审查专家的角度，检查你刚才给出的改造方案和代码，重点检查：

1. 是否有漏改的表
2. 是否有漏改的方法
3. 是否有旧字段残留引用
4. 是否有查询、更新、日志口径不一致
5. 是否有主键和业务主键混用
6. 是否遗漏事务
7. 是否遗漏日志
8. 是否遗漏异常处理
9. 是否遗漏空值兼容
10. 是否遗漏历史数据兼容
11. 是否有索引风险
12. 是否有潜在并发问题
13. 是否有接口兼容问题

请按“问题 -> 原因 -> 建议修正方式”的格式输出。

八、最实用的使用原则

1. 先分析，后写代码

不要一上来就说“给我全部完整代码”。
先让它判断影响面，成功率更高。

2. 按链路喂，不要按文件夹乱扔

围绕一个需求链路喂：

  • 入口

  • service

  • model

  • 表

  • 日志

  • 状态

这样最准。

3. 把“隐含业务规则”写出来

很多坑不是代码坑，是业务坑。

4. 每轮只解决一个问题

例如这轮只做：

  • 影响分析
    或者

  • 数据库方案
    或者

  • 完整代码

不要所有目标同时压上。

九、最后给你一句最实战的话

你以后可以把 GPT 当成：

“懂代码、懂表结构、懂需求分析、会写方案、会写代码、还能自查遗漏的高级技术副手。”

但前提是：
你给它的信息要成体系，提问要分阶段。