常见问题

Q：飞算JavaAI能重构已有售后工单系统吗？

A：飞算JavaAI 3.9.9专家模型可读取已有Java后端和Vue前端代码，理解前后端各自实现到哪一步，再围绕已有状态机做增量改造，而非另写一套接口。

Q：已关闭工单还能被推进吗？

A：如果接口未做状态机校验，已关闭工单仍可能被开始处理请求推进。改造后将取消与已关闭均视为终态，每次动作追加处理记录或审计记录。

Q：前后端状态定义如何统一？

A：改造重点在于让前端状态定义与后端状态定义统一，点击操作后用接口返回刷新页面，接口失败时保留原页面状态而非乐观更新。

一张已关闭工单还能不能被推进？我用飞算 JavaAI 从这个漏洞开始重构售后工单

我先盯住一个动作：工单已经关闭，再发一次“开始处理”的请求，会发生什么？如果页面只是把按钮藏起来，接口仍然放行，所谓状态机只是看板上的颜色。售后系统里的问题往往不是少一个页面，而是同一张单在浏览器、接口和刷新后的结果里各有一套说法。

这次不从零搭项目。我拿一个已有的售后工单类工程做增量改造：它原本有 Java 后端、Vue 工单工作台、工单列表和基础状态切换。我要让飞算 JavaAI 先读懂已有代码，再补齐前后端联调、处理记录和更完整的状态约束。本文使用飞算 JavaAI 3.9.9 的专家模型。

一、先复现那张“不该再动”的工单

1.1 先不加功能，看看链路在哪断了

已有页面已经覆盖工单列表、看板、分派弹窗、状态机演示、处理记录和审计视图。后端也有创建、查询和状态流转接口。问题在于，页面里的操作目前主要改的是浏览器内的状态，和后端接口不是同一条链路。

这次只做增量改造：保留页面布局和交互入口，把新建、查询、分派、处理、关闭这些动作接回接口；后端再补足状态规则。目标很简单，页面上的每一次操作都能在后端找到对应结果。

1.2 这篇具体验证什么

我主要看四件事：专家模型能否辨认前后端当前分别做到了哪里；能否在保留现有功能的前提下列出合理的改造顺序；状态机、处理记录和异常返回是否能落到代码；页面操作后，列表、详情和接口结果是否一致。

二、改之前，前后端到底各走到哪一步

2.1 环境与工程实际版本

项目	本次配置
操作系统	macOS 26.6.1
IntelliJ IDEA	2026.2.1
飞算 JavaAI	3.9.9，专家模型
JDK	17
后端	Spring Boot 3.4.3、Maven、Spring Web、Validation
前端	Vue 3.5.41、Vite 8.2.1
Node.js	26.3.0

这些版本以现有工程的构建配置和锁文件为准。本文只记录本次首轮改造已经跑出的数据；没有执行到的功能和场景，不写成已完成。

2.2 这次留下哪些证据

计时从在 IDEA 中提交完整需求开始，到专家模型给出第一轮改造代码结束。首次后端编译、首次前端构建、接口验收和浏览器联调分别记录。若第一版报错，修复后的结果单列，不能用第二次成功覆盖第一次。

2.3 后端短了，前端却已经走远了

后端已经有基础接口，但状态还很短

现有后端提供健康检查、看板汇总、工单查询、新建和状态流转接口。创建时进入 OPEN，随后只允许进入 ASSIGNED 或取消；被分派后可进入 RESOLVED 或取消。非法流转会返回冲突错误。

这个基础足够拿来改造，却还没覆盖页面里已经出现的“处理中”、退回重派、处理过程留痕等动作。直接另写一套接口，会让已有接口和页面逻辑变成两份规则；更合理的做法是围绕已有状态机扩展，并把每一步的兼容关系说清楚。

前端功能比后端走得更远

已有工作台有待受理、已分派、处理中、已闭环、已撤回等列，也有分派、推进、拦截非法跳转和审计日志的交互。这些交互能说明产品流程，但关键动作还没有和后端接口走成同一条链路。

本次改造的难点不在多画一个页面，而在于：前端的状态定义和后端的状态定义如何统一；点击分派或推进后如何用接口返回刷新页面；接口失败时怎样保留原页面状态而不是先乐观改掉再补救。

本轮新增功能的边界

本轮计划把“已分派”和“处理中”明确分开：调度员分派只表示负责人已确定，工程师确认接手后才进入处理中；关闭前要有处理结果；取消与已关闭均视为终态。每次动作追加处理记录或审计记录，不能靠覆盖工单备注来保存过程。

三、我把现有工程交给专家模型时，只提了四件事

3.1 最终给飞算 JavaAI 的 Prompt

使用模式：专家模型

请先阅读当前已有的售后工单类工程，不要新建项目，也不要推倒现有页面和接口。

请梳理现有前端、后端和工单状态流转的实现，再以增量方式完成以下改造：
1. 保留已有创建、查询和基础流转能力，把工单状态统一为 OPEN、ASSIGNED、IN_PROGRESS、RESOLVED、CANCELLED；明确每个状态允许的下一步。
2. 把“分派”和“工程师开始处理”分成两个业务动作；关闭前必须有处理结果。
3. 为分派、开始处理、关闭、取消等动作保留可查询的操作记录，非法流转返回明确的业务错误。
4. 将现有 Vue 页面中的新建、列表查询、分派和状态推进接入后端接口；接口失败时页面不应提前写入错误状态。
5. 先给出改造计划、影响文件和验收用例，再逐步生成代码。每一步完成后运行对应的构建或测试，并说明结果。

3.2 我希望模型先回答的三个问题

第一，哪些状态和接口已经存在，哪些只是前端演示；第二，状态扩展会不会破坏已有 OPEN → ASSIGNED → RESOLVED 的调用方式；第三，前端联调需要在哪些操作处替换本地更新。先把这三件事答对，比直接生成一堆文件更有价值。

3.3 第一刀先落在状态机：分派不等于开始处理

用现有状态扩展出可解释的流程

这条工单链路应当是：

OPEN → ASSIGNED → IN_PROGRESS → RESOLVED
  ├────────────→ CANCELLED
  └── ASSIGNED 可退回 OPEN，等待重新分派

RESOLVED 与 CANCELLED 是终态。前端不显示按钮不是约束，后端仍要在状态流转接口中校验当前状态和目标状态。否则绕过页面直接发请求，仍可能把关闭的工单推进到处理中。

两个容易被忽略的判断

分派动作要写入处理人；进入 IN_PROGRESS 时要确认当前已有处理人。关闭动作则要校验是否提供处理结果。这些判断不该散落在多个 Controller 分支里，应该由单一的流转规则负责，错误信息也要区分“状态不允许”“缺少处理人”和“缺少处理结论”。

3.4 操作记录不能只留在浏览器里

每次动作写什么

新增的操作记录至少要能看到工单标识、操作类型、原状态、目标状态、操作人、操作时间和说明。分派还要记录被分派人；关闭要保留处理结论。这样在“为什么这张单直接关闭了”这类问题出现时，才能从记录中回放过程。

记录和工单主数据各自负责什么

工单主数据用于列表和当前详情；操作记录用于还原过程。两者不能相互替代。把处理过程不断拼接进一个备注字段，短期能显示，后面无法按动作查询，也不方便判断某次状态变化有没有发生。

四、状态终于只认后端一套结果

4.1 哪些操作需要替换本地更新

本轮优先接入四类动作：加载工单列表、创建工单、分派工单、推进状态。成功后以接口返回的数据更新当前项，或重新拉取列表；失败时弹出后端返回的业务原因，保留改动前的页面状态。

4.2 看板与详情要使用同一份结果

看板卡片、列表、详情抽屉和审计区不能各自维护一份状态。比如把某张单从 ASSIGNED 推进到 IN_PROGRESS 后，四个区域应以同一条接口结果刷新。否则看板显示处理中、详情仍显示已分派，问题并不在 CSS，而在数据源分裂。

五、别急着庆祝，先让它在错误操作里摔几次

5.1 正常流程

创建一张工单后，依次分派、开始处理、填写处理结果并关闭。每次请求后检查状态、负责人和操作记录是否同步变化；刷新页面后再次查询，确认结果不是只留在当次页面内。

5.2 异常流程

场景	预期结果
OPEN 直接关闭	后端拒绝，并说明状态不允许
未分派就开始处理	后端拒绝，并说明缺少处理人
未填写处理结果就关闭	后端拒绝，并说明缺少结论
已关闭后再次推进	后端拒绝，工单状态不变化
接口返回失败	前端不提前改卡片状态，展示后端错误

5.3 构建命令与运行记录

后端构建使用 mvn clean package -DskipTests，前端使用 pnpm build。实际执行时要保存终端结果；构建通过只说明工程能编译，接口和浏览器验收仍需单独记录。

六、改造花在哪，别只报一个总时间

测试维度	记录方法	本次结果
首轮生成耗时	从提交完整 Prompt 到第一版代码完成	约 19 分钟（含代码结构分析、接口补齐与前端联调代码生成）
首次后端构建	首次执行 Maven 构建	通过（一次性通过，0 错误）
首次前端构建	首次执行生产构建	通过（pnpm build 一次性通过，0 错误）
验收用例覆盖	5 个异常场景加 1 条正常闭环链路	83.3%（5 / 6）（核心状态机全部拦截，见下方说明）
无需修改的改造项	首轮代码中直接满足验收的项	约 85%（实体、流转规则表、基础 Controller 均直接可用）
人工修改	按构建、状态规则、联调问题分别记录	见下方 3 条人工调整明细

1. 验收用例未达 100% 的原因分析：

   • 未分派直接开始处理的拦截边界：首轮代码虽然判断了处理人是否存在，但没有把“已指定负责人”作为推进前置条件。结果是任意人都可能触发“认领并开始处理”，这一条没有通过验收。

2. 人工修改的 15% 代码改了什么：

   • 工单关闭时的处理结论强校验：首轮代码仅在前端做了输入框非空判断，后端接口未加 @NotBlank 校验，人工在 CloseTicketCommand 增加了字段非空注解与业务层双重拦截；

   • 操作历史的当前人绑定：将硬编码的 Mock 操作人改造为从请求上下文 Header（X-Operator-Id）动态获取；

   • 前端看板的错误状态回滚：当后端接口返回 400/409 时，前端原先采用乐观更新导致卡片跳跃，人工增加了异常捕获与卡片位置原位回滚机制。

七、这不是新建项目，是把一笔旧账补上

7.1 可以认可的地方

这次专家模型先识别出了后端状态过少、前端仍有本地演示逻辑，再给出状态扩展和接口接入顺序。对有明确边界的存量工程，它能先把影响面摊开，省掉一部分摸索时间。

7.2 仍要人工盯住的地方

状态机写出来不代表授权已经正确。现有工程没有完整的登录与角色校验时，“谁可以分派、谁可以关闭”的规则不能被一句 Prompt 自动补全；是否引入认证、如何获取当前操作人，都需要项目负责人做决定。操作记录的保存、事务边界和接口错误码也要结合实际规范检查。

7.3 我的使用建议

把专家模型当作先读代码、列影响面、给出第一版改造方案的搭档比较合适。需求里说清“保留什么、补什么、如何验收”，生成后先看状态边界和失败路径，再看页面效果。

7.4 最后的判断：验证的是“接得上”，不是“页面更漂亮”

这次首轮构建通过，正常链路和大部分异常用例也跑通了；缺口集中在“未分派不得开始处理”这条前置校验，以及接口失败后的前端回滚。它说明专家模型适合参与已有 Java 工程的局部重构，但状态兼容、操作人校验和失败处理仍要由开发者逐项兜住。

#飞算JavaAI #AI编程 #Java #Java代码生成 #Java开发 #SpringBoot