文章目录
- 每日一句正能量
- 前言
- 一、我把顺序当建议，它把顺序当流程
- 二、第一道工序：它先让我把话说清楚
- 三、文档在前面压着，代码才敢在后面跑
- 四、卡住那次，它是往回走的
- 五、同源生成，是这条链路给我的意外之喜
每日一句正能量
“时光，浓淡相宜，人心，远近相安。” 日子有浓烈精彩的篇章，也有平淡如水的日常，都能安然接受，视作恰到好处的安排。人际关系的亲疏有其自然分寸，不强行靠近，也不忧虑疏远，让彼此都在舒适的距离里感到安心。
前言
九月初，我接了个图书管理系统的活：借书还书、图书编目、读者管理，一个典型的小型中后台。搁以前这种活至少排两个人，这回我打算一个人扛——用飞算JavaAI 把它从需求做到能跑。它是装在 IDEA 里的 Java 编程智能体，9 月上线了全栈功能，需求进去，设计文档和前后端代码出来，全程跑在本地，代码不上云。
第一周我把四条指令跑顺了，也跑错了一次。
一、我把顺序当建议，它把顺序当流程
智能会话里是四条指令：**需求分析、前后端设计、后端开发、前端开发。**需求分析产出需求文档和业务设计文档，落在 docs 里；前后端设计定技术栈、表结构和接口契约，吃的正是那两份文档——这两条是硬串行。后两条松——两端代码引用同一份契约，先后端还是先前端我自己挑，两个窗口各开一条也行。
跑了一阵我才明白它不是一根直线，是两段：文档段必须按顺序走，代码段随便挑。真正不能跳的是前面那两层。
图：项目里打开智能会话，左边是工程，右边是会话窗口
我的第一反应是老开发的老毛病：流程是给不熟的人准备的，我熟，能不能插队。
于是我开了个新窗口，跳过前两条，直接说"把借阅模块的后端代码生成了"。它倒是听话，真的开始建 Controller。建到一半停了，问我要借阅规则的细节：逾期怎么算、一个读者能借几本、要不要分读者等级。
这些问题本该在需求文档里有答案。我现编了三条规则让它接着跑，跑出来的代码字段命名跟前面模块对不上，接口返回的包装结构也是另一套——同一个系统里长出了两种代码风格，因为我让它猜了两次，它猜出了两个版本。
那一刻我明白了一件事：它不是在走形式，这四条指令是它的上下文供应链。前面每一步的产出，都是后面生成代码时它引用的依据。我砍掉前面，后面就只剩它在猜。
二、第一道工序：它先让我把话说清楚
回头老老实实从需求分析开始。我给的也是一句话：“做一个图书管理系统。”
它没有直接开干。它先回了判定：原始需求输入明显简陋，触发强制澄清。然后列了一串问题——系统给谁用、要不要分角色、借阅期限和超期规则、访问量预估。
图：它把"为什么要点名让我澄清"的判定过程先贴出来，再列问题
说实话，这一步有点戳人。我写了六年 Java，需求文档没写过几份，都是口头对接产品。现在轮到我对着一个工具交代需求，还得一条条答。
但它问的都是我嘴上说得出、落到纸面答不准的东西。比如访问量，我随口说"不大"，转念一想，开学季高峰一个系的学生同时来借，这叫不大还是大？被它问过一轮，需求才算是从脑子里搬到了纸面上。
答完这一轮我才意识到，这四条指令里最不像"工具用法"的反而是第一条——它不教你任何操作，只要求你把话说完整。后面三条指令能跑多顺，全看第一条答得多实。
三、文档在前面压着，代码才敢在后面跑
澄清完，需求分析在 docs 下生成了 requirement.md 和业务设计文档。前后端设计接着跑：先确认前端技术栈——它给了推荐项，Vue 加 Vite，UI 组件库选 Element Plus，我确认了。然后是表结构、接口契约、目录结构，一样一样落进文档。
图：到这一步它在跟我确认技术栈，不是替我决定
接口契约那部分我看得最慢。一张表列着接口路径、请求方式、入参名和类型、返回结构、错误码，每个字段的命名和含义都写死了。以前这些内容散在口头约定和别人的记忆里，现在是一份能翻的文档。
我盯着那几份文档看了一遍，改了两处：借阅上限从它推断的 5 本改成 3 本，另外补了一条"编目员和普通读者权限分开"。改的是文档，花了两分钟。
后面生成代码的时候，这两处改动原样出现在了代码里。借阅上限的常量定义在服务层，权限校验的注解挂在接口上，位置、命名、调用关系，全按文档来。这时候我才体会到"文档在前面压着"是什么意思：改动发生在便宜的阶段，而不是昂贵的阶段。
要是按我第一次的跑法，这两处改动得改代码——牵扯实体、接口、页面三处，来回对。
四、卡住那次，它是往回走的
真正让我服气的是另一次。后端开发跑到一半，我临时想给"图书预约"加个模块。它没有硬编，停了下来，说预约涉及新的业务规则，当前设计文档里没有，建议先回需求分析补文档，再回设计层更新表结构和接口，然后继续。
图：后端生成完成时的文件树，实体、服务、控制器各归各位
这就是飞算JavaAI 那条链路里我觉得最值钱的设计：**开发卡住，回退补设计文档；设计卡住，回退补需求文档。**返工发生在文档层，一分钟几毛钱的事；要是发生在代码层，就是半天的活。
我按它的建议回了需求分析，补了预约规则，再一路确认下来。前后大概二十分钟，预约模块的代码是补完文档之后重新生成的，字段和接口跟前面的模块一个风格——没有出现第一次那种"两种代码风格"的裂痕。
还有个细节：它停下来的时候，前面生成的代码没有被动过。我一度担心回退会把已完成的部分清掉，实际是原地保留、缺什么补什么。
这个设计让我敢在中途改主意——如果每次改主意都要从零重跑，我大概会硬着头皮把错的东西做完。
五、同源生成，是这条链路给我的意外之喜
还有一件当时没留意、复盘时才反应过来的事：前后端代码出自同一份契约文档。
我后来专门抽查过。前端请求借阅列表时传的分页参数，跟后端接口声明的参数，同名同义；后端返回的记录字段，跟前端页面绑定的字段，一字不差。分页、排序、时间格式，三样最容易扯皮的地方，全部天然对齐。
**以前带前端做项目，光是"这个字段叫什么、那个参数怎么传"就要来回确认好几轮。**这次我翻遍了聊天记录，没有一轮是干这个的——不是我们默契，是没有"两边"可对，它们本来就长在同一份文档上。
得说句实的：对齐的是数据这一层，样式层没这个待遇。页面上的间距、颜色、交互手感，前端生成出来跟我想的不是一回事，只能我自己在会话里描述着调。同源解决的是"对不上"，解决不了"不好看"。
图：最后跑起来的登录页。前后端第一次握手就成功，靠的不是联调，是同源
六、每条指令跑完，产物都摊在我面前
四条指令跑下来，我养成了一个习惯：每步做完先看它把东西放哪了。
需求分析那步，产物落在项目根目录的 docs 下，requirement.md 和业务设计文档两份。前后端设计那步，技术栈、表结构、接口契约、目录结构，一样样写进设计文档，还是 docs。
后端开发那步，Entity、Mapper、Service、Controller，各归各位进 src/main/java。前端开发那步的落点不一样，产物不在这个工程里——它落到另一个目录，一个从 0 到 1 搭起来的前端工程。
前面的产物是文档，最后的产物是两套能跑的代码，中间没有一步是"看不见的"。
它也让我的提问方式变了。以前遇到问题，我在会话里说"页面有点问题"；现在我会先问自己一句"这是哪一层的事"——是文档没写清，还是生成没照文档走。问题先在层里定位，再在层里解决。
七、后来多了一条指令，把四个环节串成一次输入
这个项目的四步跑完没多久，指令列表里多了一条：全栈。
我拿同一个图书管理系统试了一次。选「全栈」，把需求丢进去，然后就没我什么事了——需求分析完自己进设计，设计完自己往下走，除了需求没说清那次弹出来的澄清，我一次都没手动触发下一步。我敲的字只有第一段需求，后面的流转全是它串的。
跟四步比有两处不同。一处是顺序：四步里前后端谁先做我自己挑，全栈按内置顺序跑。一处是工程形态：四步出来是前后端分离，两个工程各在各的目录；全栈默认给一体化项目，前端代码落在后端工程里。想分开也行，路径和名字得在开跑前给它，晚了没用。
**默认给的是最省事的那个，不是最合适的那个。**要交别人维护、或者有独立的部署链路，就得在开跑前想清楚。
这里有一件事得挑明：**全栈把四个环节合成了一条指令，没有把四个环节合成一个环节。**执行顺序从手里收走了，依赖关系还在。所以我现在还是分着用——全栈给的是结果，四步给的是四个能停下来说话的关口。
八、现在我把这个顺序抄进了自己的工单
图书管理系统最后跑起来了，前后端都在本地，启动、登录、借还书，一条链路通的。整个过程里我写的代码行数是零，确认过的文档是四份。后来拿全栈指令重跑，账还是那个账：零行代码，四份文档，中间敲的字少了一大半。
有人会问，这不就是把写代码变成了点确认？我原来也这么嘀咕。真跑完一个项目，想法变了：**写代码这一段本来就是整件事里最确定的部分，贵的是前面那些没说清楚的部分。**工具把最确定的部分接走了，把不确定的部分明晃晃摆到我面前，逼我在便宜的阶段处理掉。
这个顺序我已经抄进组里的工单模板了：需求、设计、再动手。以前是我劝别人这么干，别人嫌麻烦；现在是工具替我坚持这个顺序，谁也跳不过去。
有人问我这套东西算不算"AI 把代码全写了"。不算。它写的是代码，我写的是每一层的输入——需求里那几条规则、设计里那两个字段的取舍、技术栈上那两分钟的犹豫。
代码是这套输入的产物，输入乱，产出的代码就乱，这个因果关系一天都没变过。
上周组里新来的实习生想直接要代码，窗口里弹出来的还是那句"建议先完成需求分析"。他问我能不能跳过，我把这个月跑错的那次讲给他听。他没跳。
转载自：https://blog.csdn.net/u014727709/article/details/166491529 欢迎 👍点赞✍评论⭐收藏，欢迎指正
