一、 项目背景与技术选型
前几天领导让我开发一个商品的出入库系统，用来管理我们的一些产品，这样就能抛弃原有的腾讯文档了。
当时给了我两个文档，说上面就是我们的需求，按照这个文档进行开发即可。直接进行全栈开发，后端可以使用 Node，于是乎我选定前端 Vue + 后端 NestJS 的组合。说实话我不会 Nest，虽然我使用 Nest 写过后端，但终究不是很熟练。
我们这个没有参考的项目、没有设计图，看完文档之后我把文档给了默默（AI助手的名字），分析完毕之后我们确定了流程：
- 入库链路：录入商品 →\rightarrow→ 采购 →\rightarrow→ 审核入库
- 出库链路：申领 / 置换商品 →\rightarrow→ 审核 →\rightarrow→ 出库
- 支撑模块：角色、权限、路由日志……
二、 核心问题与明确解法（逐项复盘）
问题一：UI 框架选型失误导致全量重构
- 踩坑现象：
最开始的时候由于没有使用第三方的后台框架，我就想平时使用的都是 Element Plus，有没有其他的框架？之后默默给我推荐了 Naive，我一想应该可以吧，之前也听过这个，然后那就开搞！！
之后在项目快要做完的时候问题暴露出来了：那就是这个 UI 表格居然还是使用tr、td去手搭，看到一个页面还在这样写并且还要手写很多 CSS。最后没办法，在项目快要做好的时候又重新切换回了 Element Plus。 - 根本原因：
当时想换个好看点的组件库试试，结果复杂表格还不如 Element Plus - 明确解决办法：
技术选型切忌拍脑袋，核心组件库必须在立项之初就固定锁死。对于中后台管理系统，优先选择生态最成熟、表格与表单封装度最高的组件库（如 Element Plus），绝不在项目半途做跨 UI 框架的大迁徙。
问题二：单文件代码爆炸与组件未抽离（动辄两三千行）
- 踩坑现象：
开发的时候没有考虑那么多：抽屉的提取、表格组件的抽离等等，这就导致一个页面中所有组件、弹窗等等都在一个文件里，这使得文件代码爆炸式增长，一个页面的代码甚至超过了一两千行！
尽管里面有一半可能是 CSS，说到 CSS 这也是一个问题点。那就是因为页面进行了大量的美化所以 CSS 也有很多，但是在最开始我并没有使用 Tailwind CSS，这里我有两点考虑：第一就是太过相信 Naive；第二就是觉得全部改为行内之后代码可读性太差了，放眼望去全是类名。
说这些也是吐槽：直接使用 AI 梭哈如果没有提前规划好架构，那就是一个文件直接写到底，代码行数会极度暴涨！ 当然这在我们公司既有项目中也有体现，就比如一个弹窗一共有六个步骤，最后这一个弹窗组件的代码足足有 3000 行…… - 根本原因：
缺少模块拆分规范，AI 默认倾向于在单一文件里“就地堆砌”所有弹窗、抽屉和内联样式。 - 明确解决办法：
强制组件物理拆分与样式规范：- 页面主文件只保留主表格与查询过滤，所有的弹窗（Modal）、详情/编辑抽屉（Drawer）必须抽离为独立的子组件（
components/）； - 样式要么通过全局主题类统一，要么严格约束大弹窗分步骤拆解，单个组件文件行数严格控制在 300~500 行以内。
- 页面主文件只保留主表格与查询过滤，所有的弹窗（Modal）、详情/编辑抽屉（Drawer）必须抽离为独立的子组件（
问题三：公共工具库缺失与局部重复造轮子
- 踩坑现象：
商品在采购或者是入库的时候需要计算价格，这里没有使用第三方的精度计算包，而是采用千分法计算来避免小数相加结果错误。但是有多个页面涉及了计算，然后就是一个页面写一个函数……
另外还有些地方涉及了时间格式的转换，然后 AI 梭哈使用的还是原生的 JS 方法。在我看来，凡是涉及时间相关的场景，正常都应该统一使用dayjs这一类成熟库来处理……
这确实，到最后整个项目做下来会发现：除了 UI 库，别的任何实用插件/工具库都没有下载！ - 根本原因：
项目前期基建准备不足，没有在公共层封装通用函数，AI 面临单页指令时只能局部自产自销原生方法。 - 明确解决办法：
“基建先行”，前置提取公共约束：
在正式写业务代码前，先建立src/utils/目录，安装并配置好标准的日期工具（如dayjs）、金额/精度运算工具（如big.js或公共千分计算封装）、图片压缩上传封装等。写好基础规范后，AI 直接调用公共工具函数，杜绝逐页重复实现。
问题四：“三无项目”导致需求严重漂移与无休止返工
- 踩坑现象：
项目做完之后，产品开始测试的时候，然后就是这点不是想要的，那一点不是想要的，接着就是开始无情的返工。
没有设计图、没有专业产品参与、什么都没有，只有一个最开始的简单文档。结果就是最后做好的东西，跟最初的文档已经完全不是一个东西了…… - 根本原因：
只有文字文档而无具象化界面，导致前期所有人对界面的理解各自脑补，直到页面真正做出来后才开始实质性“提需求”。 - 明确解决办法：
先出草图 / 原型图（构建项目可视化骨架）：
之后的项目应该先出一个很草的设计图或者原型图，我现在觉得这是必不可少的。对于我们这次遇到的问题：一个文件就是一个页面、公共方法没有提取、对于一些表格甚至表单的限制（就比如日期选择的时间范围限制、图片上传压缩等）。
有了哪怕是潦草的原型图，我们也能直观、可视化地知道项目是干什么的、哪里需要什么东西。我认为这如同骨架，能让我们有清晰向下开发的方向，并提前做好全局架构设计。
问题五：多线作战下的“AI 工期压缩悖论”与代码失控
- 踩坑现象：
代码全部由默默编写，我是一行没有管！如果问为什么？那么只能说如果时间充裕，谁不想好好看看然后进行仔细的代码审查？
那时候项目很急，而且我还要开发另外的项目。所以那几天的情况是这样：默默在这个项目写代码之后，另一个项目也需要开始同步开发……
基于这次“全栈”开发，我想到了🐶领导的那句话：“如果你们使用 AI 写代码不带一点产品思维，那我为什么不直接使用 AI？到时候给你们开除使用 AI 算了！”
现在回过头来看：前半句我认可，如果从零开始做确实需要深度思考；后半句我不认可，因为这🐶根本不会愿意出钱使用 AI 的，AI 可是预付费的哦！尽管公司买了 Cursor，但是十几个人共用两个账号……之后工期还直接按照“你使用了 AI”的极致压缩工期来算，所以这就是为什么我之前说“根本没时间去仔细看默默的代码”的核心原因之一了。 - 根本原因：
工期太紧，没空分模块；基建又没做，每个页面只能从零梭哈 - 明确解决办法：
按模块拆分独立会话，开启“蛛网式”并行编织：
根据不同的模块，使用单独的会话进行开发。这次项目我全程使用的是同一个会话（依赖上下文自动压缩），虽然我也注意到并没有出现太多记忆丢失的情况（毕竟一个页面梭哈也不需要跨太长的历史记忆），但我认为更优雅的做法是：按不同模块单独启动新会话，实现多会话并行开发。
这种模式的前提，就是前期先把业务文档和接口契约写好、分配清楚。这就如同织一张蛛网，每个节点之间的链接自己都需要清晰，这样才能从几个方向同时开工，慢慢编织成一张完整而坚固的大网。
三、 下次实战落地速查清单（Checklist）
| 阶段 | 核心任务 | 具体落地动作 |
|---|---|---|
| 1. 骨架期 | 草图与需求对齐 | 哪怕手绘也必须先出一套潦草原型图，框定字段、按钮、限制条件与审核流 |
| 2. 选型期 | 技术栈固化 | 坚决选用最熟练、封装最全的 UI 框架（Element Plus），中途严禁变更 |
| 3. 基建期 | 公共库前置配置 | 提前配置 dayjs、金额精度计算、图片压缩、统一网络请求等 utils |
| 4. 规范期 | 组件拆分规则 | 单文件禁止堆砌弹窗，强制将 Drawer、Dialog、Form 拆至子目录 |
| 5. 施工期 | 蛛网式分会话开发 | 按采购、入库、出库等独立模块开启不同 AI 会话，节点化并行编码 |
| 6. 交付期 | 边界审查与回归 | 重点核验历史变更、数据关联（如商品改名、跨仓出入库流水的追溯一致性） |
我始终认为我们每个人都是一个不完美的程序，需要经常复盘->升级->再复盘->再升级......也许这次总结的经验没用，但这正是我们下次升级时需要验证的东西。
