一、项目背景
今年 7 月，公司接了一个新项目
开发人员：我一个。辅助：AI。
我给自己设了一个规则：能用 AI 做的，绝不用手。从售前的标书技术方案，到需求分析、开发计划、代码编写、测试，再到验收阶段的用户手册和验收报告——全链路交给 AI。我负责审查、修正和兜底。
项目已经完成了 5 个阶段。下面是一手的复盘——AI 在真实项目中到底行不行。
二、我先给 AI 定了三个角色
一个项目不是只有写代码。项目经理、开发、测试——三件事都需要人盯着。我一个人不可能同时干三个角色，但我可以让 AI 分别扮演：
| 角色 | AI 做什么 | 我不让它做什么 |
|---|---|---|
| 角色一：项目经理 | 读需求 → 分析影响范围 → 写执行计划 → Code Review | ❌ 不碰代码 |
| 角色二：全栈开发 | 按计划写前后端代码 | ❌ 改之前必须让我确认 |
| 角色三：测试 | 生成测试用例 → 测试脚本 → 执行 → 出测试报告 | ❌ 不能偷懒缩减用例 |
这些角色不是口头说说——我把每个角色的职责边界写进了项目的 CLAUDE.md 全局规范里。AI 每次打开新会话先读它，知道自己是什么角色、什么能做什么不能做。
角色一：项目经理
本会话为项目经理角色，只负责规划和 Review，不操作代码，不执行文件修改。
职责边界：
- 理解需求，分析可行性和影响范围
- 编写执行计划（输出到 需求提示词/ 对应阶段的 md 文件）
- 新模块开发前先写执行计划，用户确认后才能进入开发
- 代码 Review：检查与执行计划的一致性、规范符合度、bug 风险，输出审查报告
- 识别问题后只指出，给出修改建议，不直接修改代码
角色二：全栈开发
负责前后端代码实现。每个阶段一个独立会话。
核心规则：
- 收到需求后先确定修改内容和修改逻辑，确认后才能开始修改代码
- 每次修改代码之前都要跟用户确认，不要做完计划就直接修改
- 优先复用已有代码和框架能力，不引入不必要的依赖
- 保持代码风格与现有项目一致（参考编码规范）
- 收到缺陷反馈时，禁止在原有错误代码上增量修补，根因修复
- 主动识别并删除无效、冲突、重复代码，禁止新旧逻辑共存
- 修改文件优先输出完整文件内容，不提供零散代码片段
- 必须包含异常处理、参数校验
- 更新开发计划时保持原始计划结构，末尾追加"实际执行记录"章节
角色定义里有一句"保持代码风格与现有项目一致（参考编码规范）"。这句如果不写清楚，AI 就会按自己的习惯写——你得到的是"标准 Java"，不一定是"符合你这个项目的 Java"。所以我单独写了编码规范：
## 通用
- 文件编码统一 UTF-8
- 不提交无用注释、调试代码（新增代码不加 console.log、System.out.println）
- 变量/方法命名使用业务语义，避免 temp、data2 等无意义命名
## Java
- 不重复造轮子：优先使用平台提供的基类和工具类
（BaseController, BaseService, BaseDao, JsonResult, PageInfo, PageUtils）
- 异常统一通过平台异常机制处理，不吞异常
- MyBatis-Plus 3.0.5 的 update(entity, wrapper) 不允许 entity 为 null，
必须 new Entity() 后 setXxx
## Vue
- 新增/编辑表单统一使用右侧滑出抽屉（.side-panel），禁止使用 el-dialog
- 全局样式复用 page-common.scss 的公共类
- 表单校验必须用 <el-form-item prop="xxx">，自定义 div 不参与校验
- 删除操作使用 $postForm + FormData 传参，不要用 $get 或 plain object
角色三：测试
负责生成测试用例、测试脚本、执行测试、输出测试报告。
核心规则：
- 必须遵守测试规范的最低标准，不得偷懒缩减
- 测试用例/脚本/报告/截图的数量和格式见测试规范
- 每个模块独立满足最低标准，禁止以"和其他模块类似"为由缩减内容
- 文件名、目录结构按目录结构规范命名
光说"遵守测试规范"，AI 也会偷懒。所以我又单写了一个 测试规范.md，把最低标准钉死：
## 最低数量要求（节选）
| 模块类型 | 最少用例数 | 最少截图数 |
| 标准CRUD | 6个 | 5张 |
| 树形CRUD | 7个 | 6张 |
| 含子表/关联 | 6个 | 6张 |
## 必须覆盖的场景
1. 页面加载 — 列表正常渲染、列头和数据正确
2. 新增 — 抽屉 → 必填校验 → 提交 → 列表刷新
3. 编辑 — 数据回填正确 → 修改 → 提交
4. 删除 — 确认弹窗 → 有子节点时拦截
5. 空值提交校验 — 每个必填字段为空 → 红色提示
6. 唯一性校验 — 重复编码 → 拒绝
## 红线（缺一不可）
- 新增用例未测"空值提交校验" → 不合格
- 编辑用例未测"数据回填正确性" → 不合格
- 有子节点的树形模块没测"删除校验" → 不合格
- 函数体小于5行 → 不合格（不够完整）
- 无字段断言 → 不合格
- 通过率100%但无边界测试覆盖 → 怀疑偷懒，要求补测
- 测试报告无"发现问题"章节 → 不合格（全通过也要写"无问题"）
有了这套规范之后，AI 测试角色的产出质量明显上去了。以前没有规范的时候，AI 会偷懒——用例覆盖不全、报告缺章节、截图数量不够。现在每项都有明确的数字红线，AI 不敢省。
最关键的一条——三个角色在不同的会话中工作。 项目经理一个会话、开发一个会话、测试一个会话。不是在一个聊天里来回切换角色，那样 AI 很容易混淆上下文。
规范写好了，接下来就是执行。工作流是固定的——每个模块都按这套走：
┌─────────────────────────────────────────────────────────┐
│ 1. 项目经理角色 → 读需求 → 生成执行计划 │
│ ↓ │
│ 2. 我来确认计划的可行性和风险点（有问题打回去重改） │
│ ↓ │
│ 3. 全栈开发角色（新会话）→ 按计划写前后端代码 │
│ ↓ │
│ 4. 我来快速检查代码，修掉基础错误（编译不过、服务起不来等） │
│ ↓ │
│ 5. 测试角色 → 生成测试用例 → 测试脚本 → 执行 → 出测试报告 │
│ ↓ │
│ 6. 全栈开发角色根据测试报告修 bug │
│ ↓ │
│ 7. 重复测试。注意：AI 连续改 2 次修不好 → 人工介入 │
│ ↓ │
│ 8. 阶段完成 → 更新实际执行记录 → 生成经验总结 → 更新避坑速查表 │
│ ↓ │
│ 9. 项目经理 Code Review → 提交 SVN │
└─────────────────────────────────────────────────────────┘
几个实践的细节：
- 项目经理和测试用同一个会话。 这样才能保证业务理解的连续性。会话太长时，用 memory 功能传递上下文：老会话梳理核心内容 → 新会话读取 memory → 继续。
- 开发每个阶段独立会话。 不同阶段之间关联不大，没必要保持一个会话——会话太长反而影响响应速度和 token 消耗。
- 不要自动循环"测→改→测"。 AI 连续 2 次修不好同一个问题就得人工干预，否则容易修了 A 坏了 B，无限循环。
所有提示词文件都按版本管理，提交到 SVN。每个模块有：需求提示词、执行计划、测试用例、测试脚本、测试报告、测试截图——整套链路。
三、比我想的快：AI 确实让我一个人顶了一个团队
3.1 开发计划：从"我自己想"到"AI 生成，我确认"
以前我做项目计划，要自己梳理需求、拆功能模块、排优先级、预估工期——现在我把需求文档扔给 AI，让它输出结构化计划，我只看重要的判断：阶段顺序对不对？关键风险有没有漏？
项目经理角色的第一个输出就是 8 个阶段的完整开发计划。每个阶段拆到模块级别，每个模块列出了：后端代码位置、Entity 关键字段、API 接口清单、前端界面结构、路由注册方式。
我做的： 确认阶段顺序（先建表、再系统管理、再基础数据——这个是经验判断）、标注哪些阶段要先做（Token 启用必须在用户管理之后）、删掉不必要的内容。
3.2 执行计划：细到可以直接照着写代码
这是阶段 2.1 组织管理的执行计划。AI 写了 200 行，包含：
- 后端：Entity 字段定义、6 个 API 接口的路径和入参、树形查询的内存组装逻辑、删除校验的业务规则
- 前端：组件目录结构、el-table 的 key 配置、新增/编辑弹窗的字段布局、routeDev.js 注册代码示例
- 注意事项：根节点不可删除、orgCode 格式建议、不需要鉴权（阶段 4 才启用 Token）
我没写的： 树形数据的内存组装逻辑——AI 写了"一次查出所有节点，通过 parentId 在内存中递归，不用递归 SQL"。我自己写也会这么写，但要花 20 分钟组织语言和查 API。AI 10 秒。
3.3 测试：从"写完就完了"到"每个模块有完整测试链路"
以前做定制项目，测试靠人肉点。这个项目我第一次有了完整的测试产出：
- 22 条测试用例（正常路径 + 边界 + 权限）
- JS 测试脚本（E2E，可反复跑）
- 5 张测试截图（主页面、表单字段、校验提示、回填、删除确认）
- 测试报告（通过率、失败用例、发现的问题、截图索引）
22 条用例通过 21 条，失败 1 条——orgCode 空值未校验。AI 测试角色检测到后端 Service 层缺少 orgCode 的非空校验，开发角色漏了这个——这是真实开发中会漏的边界问题，AI 帮你发现。
我做的： 看报告中的失败条目，确认是 bug 然后修。测试执行和报告编写是 AI 做的。
3.4 标书：从"憋两周"到"半天微调"
这个项目其实还没写第一行代码之前，AI 就已经参与了。
售前阶段要投标。把原始需求文档扔给 AI，直接生成了标书技术部分——系统架构图描述、功能设计、15 张表的数据库设计、原型页面说明。结合 Claude Code 的相关 skill 生成后，略微修改就能用。
以前写标书技术方案，从整理需求到画架构图到写技术路线，我一个人至少憋一两周。这次半天搞定。
3.5 验收文档：测试跑完了，文档自然就有了
做过定制项目的都懂——最烦的不是写代码，是写文档。用户手册、验收报告、运维手册，项目越大文档越厚。
但这个项目每个模块都有完整的测试产出：测试用例、测试脚本、测试截图、测试报告。这些东西本身就是文档的原材料——把测试用例和截图扔给 AI，自动生成用户操作手册；把测试报告汇总，自动生成验收文档。
不是"额外花时间写文档"。是测试跑完，文档自然就有了。
四、比我想的笨：那些 AI 反复翻车的地方
说完了"快"，说"笨"。这些是真实踩坑记录——项目里专门有一个文档叫《阶段1-经验总结》，写了 265 行，记录了 20+ 个坑。
4.1 它不知道你的项目里有哪些潜规则
AI 输出的执行计划里写着"用 MyBatis-Plus 的 @TableLogic 实现软删除"——这是标准做法，没问题。
但实际： 项目的 BaseDao 不支持 @TableLogic。删除是真删除，查询不自动过滤 del_flag=0。
AI 不知道你的 BaseDao 是谁写的、有没有注册 LogicSqlInjector、项目的 MyBatis-Plus 是 3.0.5 这个老版本。这些东西不在文档里——在你脑子里。
修正： 手动在 MybatisPlusConfig 里注册 LogicSqlInjector Bean。AI 不会想到这一步。
4.2 它猜不到 UI 问题的根因——盲调 10 次
前端表格编辑列下方出现一条白线。AI 尝试了 10+ 次 CSS 覆盖——调固定列背景、调 body-wrapper、调 content-box——全是无效猜测。
最后我打开浏览器 F12，悬停在白线上，发现那根本不是什么 table 内部元素——是滚动条 ::-webkit-scrollbar-thumb 的颜色。AI 全程不知道这条白线从哪来的，因为它看不到浏览器的实际渲染。
教训：UI 问题必须人先定位，AI 只能帮你修，不能帮你找。
4.3 计划赶不上变化——执行中出现的偏差
组织管理模块执行计划的"实际执行记录"里有5 条偏差：
| 计划 | 实际 |
|---|---|
| 扁平树形表格 | 原型是左树 + 右卡片布局 → 重写 |
@TableLogic 标准做法 | BaseDao 不支持 → 手动注册 LogicSqlInjector |
update_time 字段 | DDL 没定义 → ALTER TABLE 补列 |
$postForm({primary: id}) | plain object 序列化失败 → 改用 FormData |
<div class="form-row"> | Element UI 不校验 → 全部改成 el-form-item |
每一条都是 AI 按"标准做法"生成的——实际项目里总有不标准的。AI 可以生成标准方案，但不能替你做非标准环境的适配。 适配的是你。
4.4 它改代码时会"做了 A，忘了 B"
- AI 知道
$postJson需要 reject，但只改了那一个方法——$get、$postForm、$formData三个同样的 bug 留在那没碰 - AI 给
config.headers[token]设了 null 值——没考虑到 axios 会把 null 转成字符串 "null" 发过去，后端收到非空的 "null" 就开始解析 JWT
这些不是 AI 的错——是"缺乏全局意识"的错。你不会让一个实习生自己决定改哪些文件——你需要告诉他"所有类似的地方都改"。对 AI 来说也一样。
五、真正的教训
5.1 AI 是好用的火车，但铁轨得你自己铺
AI 可以生成完整的执行计划、写出标准的 Controller/Service/Dao 代码、跑测试用例。但：
- 项目里的潜规则（BaseDao 不支持 @TableLogic、uxdb 用 PostgreSQL 驱动） ——只有你知道
- UI 问题的根因定位（白线是滚动条不是 div 背景） ——只有你能做
- 非标准环境的适配（麒麟 OS 的路径、国产数据库的兼容） ——只有你能处理
AI 不知道这些。它只能按"标准做法"输出。标准做法的覆盖率大概是 70%，剩下 30% 的坑，是你的价值。
5.2 提示词不只是写——要管
项目中所有提示词都按版本管理、提交了 SVN。每个模块的开发计划、测试用例、测试报告形成一个完整的追溯链。需求变了 → 提示词升版 → 执行计划升版 → 测试用例升版——整个链路一致。
现在项目做到第 5 阶段，前面 4 个阶段的提示词库如果在二期项目里复用，开发速度还能再快一倍。
这是我在上一篇里讲的"提示词是数据资产"——这个项目就是最好的例子。
5.3 一个人能做完，不等于一个人该做完
这个系统是我一个人用 AI 辅助开发的，前端后端数据库测试全栈。但关键业务决策——表结构怎么设计、工业协议怎么对接、数据采集怎么调度——是我自己最终决策。
AI 让"一个人写代码"变成了可能。但"一个人做决策"这件事不会变。 你省下的时间，应该花在更难的事情上——理解业务、做对决策、保证质量。
六、总结
这个项目还没做完。KPI 看板和现场对接还要等数据上来。
但到目前阶段 5 为止，结论是清楚的：
- AI 让一个 Java 老兵变成了一个团队。 从售前标书到验收文档，全链路覆盖。
- 但 AI 不是自动驾驶。 它是一个不知疲倦的实习生——干活快，能覆盖标准场景的 70%，剩下的 30% 靠你的经验兜底。
我能一个人管一个项目，不是因为 AI 够强——是因为每次 AI 翻车的时候，我知道往哪找答案。
上一篇：提示词写了半年才明白：怎么写只是第一步，怎么管才是真正的竞争力
下一篇预告：把离职同事的 QT 代码扔给 AI 是什么体验
