第二十二章 救火

一

裁员风波还没完全平息，一个紧急项目就砸了过来。

一个新客户——一家连锁药店——要做一套"智能库存管理系统"。需求不算特别复杂，但客户给的时间极其紧张：两周。

两周，从零开始，做一套包含库存预测、自动补货、效期管理、报表分析的系统。

正常情况下，这至少需要六周。

但公司刚丢了大客户，急需新的收入来源。这个项目如果做成了，客户承诺签三年的长期合同。

周旋经理在紧急会议上说："这个项目必须拿下。谁来负责？"

会议室里安静了几秒。

王志远举了手："我来。"

二

他知道两周做完一个完整的系统是不可能的。但他也知道，两周做出一个能用的最小版本是有可能的。

这就是 MVP（Minimum Viable Product）——最小可行产品。

他在白板上画了一个表格：

"两周内，我们交付 P0 和 P1 的功能。P2 的功能放到后续迭代。"他对周旋说。"客户最急需的是库存管理和效期预警——药品过期是他们最大的痛点。库存预测和报表分析可以后面再加。"

周旋想了想："客户能接受吗？"

"我跟客户沟通一下。关键是让他们看到——两周后他们能用上一个解决核心痛点的系统，而不是等六周才能看到一个什么都有但什么都不完善的系统。"

周旋点了点头："好，你去跟客户谈。"

三

王志远跟客户的项目负责人开了一个电话会议。

他没有承诺"两周做完所有功能"，而是诚实地说："两周内我们可以交付一个核心版本，解决你们最急迫的库存管理和效期预警问题。其他功能我们会在后续迭代中逐步添加。"

客户犹豫了一下："但我们需要库存预测功能……"

"库存预测需要历史数据来训练模型。系统上线后，先积累两到四周的数据，然后我们再加入预测功能，效果会比现在硬做好得多。"

这个理由说服了客户。

挂了电话后，王志远开始拆分任务。

四

他把两周的时间拆成了四个阶段：

第 1-2 天：技术方案 + 数据库设计 + 项目骨架
第 3-7 天：核心功能开发（库存 CRUD + 入库出库 + 效期预警）
第 8-10 天：补货建议 + 前端页面 + 联调
第 11-12 天：测试 + 修 bug + 部署
第 13-14 天：客户验收 + 修改

他把任务分配给了三个人：自己负责后端核心逻辑和架构，张小龙负责数据库和 API 开发，苏薇主动请缨帮忙做 Code Review 和技术把关。

"苏薇姐，你不用写代码，帮我们把关质量就行。"王志远说。"两周的项目最容易出质量问题，有你在我放心。"

苏薇点了点头："行。但有一个条件——不管多赶，测试不能省。"

"绝对不省。"

五

这次项目，王志远做了一个大胆的决定——大规模使用 AI 辅助开发。

不是像马德华那样把整段代码交给 AI 生成然后不审查。而是一种有策略的人机协作方式。

他把 AI 的使用分成了三个层次：

第一层：脚手架生成。

他用 AI 生成了项目的基础骨架——Spring Boot 项目结构、数据库实体类、基础的 CRUD 接口、Swagger 文档配置。这些代码是重复性的、模式化的，AI 生成的质量足够好。

他花了半天时间审查和调整 AI 生成的骨架代码，确保符合团队的编码规范。

第二层：接口文档和测试用例。

他把需求文档喂给 AI，让 AI 生成 API 接口文档的初稿和测试用例的框架。然后他逐一审查，修正了 AI 理解错误的地方，补充了 AI 遗漏的边界场景。

第三层：核心业务逻辑——自己写。

效期预警的计算逻辑、补货建议的算法、库存扣减的并发控制——这些核心业务逻辑，他全部自己写。

"AI 能帮你搭个架子，但承重墙得你自己砌。"他对张小龙说。"架子歪了，调调就行。承重墙塌了，那就是线上事故。"

六

这种人机协作的方式，效率惊人。

以前搭一个项目骨架需要两天，现在半天就搞定了。以前写接口文档需要一天，现在两小时出初稿，再花两小时审查修改。以前写测试用例的框架需要半天，现在一小时。

省下来的时间，全部用在了核心业务逻辑上。

第一周结束的时候，核心功能已经开发完成——库存 CRUD、入库出库、效期预警，全部跑通。

苏薇 Review 了所有代码，提了十几条意见，但没有发现架构层面的问题。她说了一句："AI 生成的骨架还凑合，但你自己写的核心逻辑明显更好。一眼就能看出来哪些是你写的，哪些是 AI 写的。"

"怎么看出来的？"

"AI 写的代码太'规矩'了——变量命名完美、注释详尽、结构工整，像教科书。你写的代码有'人味'——有些地方会用更简洁的写法，有些地方会加一个只有理解业务才会加的判断。"

王志远笑了："这算夸我还是损我？"

"夸你。有'人味'的代码说明你理解了业务，不是在机械地翻译需求。"

七

第二周，赵北辰回来支援了。

他听说了这个紧急项目，主动跟他的新项目经理请了两天假，回来帮忙。

"赵哥，你不用——"

"少废话。"赵北辰坐到了工位上，打开电脑。"你负责后端，我帮你搞定部署和运维。CI/CD 流水线、Docker 容器化、监控告警，我来。"

有赵北辰在，王志远的心一下子就定了。

赵北辰看了一下王志远的代码和项目结构，然后看了一下 AI 生成的部分和手写的部分。

他沉默了一会儿，然后说了一句让王志远印象深刻的话：

"你终于学会驾驭工具，而不是被工具驾驭了。"

"什么意思？"

"你让 AI 搭脚手架、写文档，但核心逻辑自己写。你分得清什么该交出去，什么得自己扛。这就叫'驾驭'——你是主人，AI 是工具。马德华当初的问题是反过来了——他让 AI 牵着鼻子走，自己倒成了工具人。"

八

第十二天，系统部署到了测试环境。

第十三天，客户来验收。

客户的项目负责人带了两个药店的店长一起来。他们坐在会议室里，王志远现场演示了系统的功能。

当他演示"效期预警"功能的时候——系统自动扫描所有药品的有效期，把即将过期的药品标红，并生成处理建议——两个店长的眼睛亮了。

"这个功能太好了！"一个店长说。"我们以前都是人工检查效期，每个月要花两天时间。有了这个系统，几秒钟就能看到所有快过期的药品。"

另一个店长问："能不能加一个功能——快过期的药品自动打折促销？"

王志远笑了："这个功能在我们的后续迭代计划里。下个月就能上线。"

客户的项目负责人很满意："两周能做到这个程度，超出预期。后续的功能我们慢慢加，不急。"

验收通过。

九

项目上线后，周旋在周会上表扬了王志远的团队。

张总也在年度总结会上提到了这个项目："智能库存管理系统是咱们拥抱 AI 的标杆项目。两周交付，客户非常满意。这说明啥？AI 不是来抢咱饭碗的，是来帮咱干活的。"

王志远坐在台下，心里很平静。

他知道这个项目的成功不是因为 AI 有多厉害，而是因为他做对了几件事：

1. MVP 思维：不贪多，先解决核心痛点
2. 合理拆分：把两周的时间拆成四个阶段，每个阶段有明确的交付物
3. 人机协作：AI 做重复性工作，人做创造性工作
4. 质量把关：再赶也不省测试，苏薇的 Review 是质量的最后一道防线
5. 团队协作：张小龙、苏薇、赵北辰，每个人都在关键时刻发挥了作用

这些，都是他这一年学到的东西。

十

那天晚上，王志远瘫在椅子上，两周的紧绷终于松了下来。客户满意，项目交付，测试全绿。

赵北辰在群里发了一句："你终于学会驾驭工具，而不是被工具驾驭了。"

他盯着这句话看了很久。这次项目他让 AI 搭脚手架、生成接口文档，但核心业务逻辑一行一行自己敲，测试一个不省。说白了——AI 搭架子，人砌承重墙。各干各的活儿。

两周前他还觉得不可能完成。现在回头看，一个人做不到的事情，一群人可以。

:::{admonition} 小胖的笔记 :class: tip

本章知识卡片：紧急项目管理与 AI 协作

1. MVP（最小可行产品）

所有功能 ──→ 按优先级排序 ──→ 只做 P0 + P1 ──→ 快速交付 ──→ 迭代添加

MVP 的原则： - 解决核心痛点，不追求完美 - 先让用户用起来，再根据反馈改进 - 80% 的价值来自 20% 的功能

2. 紧急项目的任务拆分

总工期：2 周
├── 第 1-2 天：方案设计 + 项目骨架
├── 第 3-7 天：核心功能开发
├── 第 8-10 天：次要功能 + 联调
├── 第 11-12 天：测试 + 部署
└── 第 13-14 天：验收 + 修改

每个阶段都要有明确的交付物，不能模糊。

3. AI 辅助开发的分层策略

原则：AI 搭框架，人砌承重墙。框架错了改改就行，承重墙错了房子会塌。

4. 紧急项目的质量保障

:::