AI 时代项目管理手册
还是那个旅游网站项目(PC/H5/小程序/App + PHP + Vue + MySQL + 原生 App),但这次——全部交给 AI 来完成。作为老板,你如何掌控?
一、AI 时代的团队怎么搭
1.1 角色变化:从"写代码"到"管 AI"
传统项目团队 9-10 人,AI 驱动项目可以压缩到 3-4 人,但角色职责变了:
| 角色 | 传统项目 | AI 驱动项目 | 人数 |
|---|---|---|---|
| 项目经理 | 管进度、管需求、管沟通 | 管 Prompt、管 AI 输出质量、管上下文 | 1 人 |
| 后端 PHP 开发 | 2 人写代码 | 0.5 人写 Prompt + 审查 AI 代码 | 1 人兼顾前后端审查 |
| PC/H5 前端(Vue) | 2 人 | 0.5 人 | ↑ |
| 小程序开发 | 1 人 | 0.5 人 | ↑ |
| iOS 开发 | 1 人 | 0.5 人(AI 可生成大部分) | 1 人(主攻 App 审核+原生特有逻辑) |
| Android 开发 | 1 人 | 0.5 人 | |
| UI 设计师 | 1 人 | 1 人(AI 辅助出图) | 1 人(产出加快,但要定风格规范) |
| 测试 | 1-2 人 | 1 人(AI 帮忙写测试用例) | 1 人 |
AI 时代最小团队配置:4 人
项目经理(1人):需求管理 + Prompt 策略 + 进度管控全栈审查员(1人):审查所有端 AI 生成的代码(最核心角色)设计师(1人):UI 规范 + 视觉稿 + AI 出图测试(1人):功能测试 + AI 测试脚本 + 验收1.2 核心角色:全栈审查员
AI 时代最重要的不是"谁写代码最快",而是**"谁能最快看出 AI 写的代码有没有问题"**。
全栈审查员需要的能力:
- 看得懂 PHP、Vue、iOS Swift、Android Kotlin(不用精通,但要能发现问题)
- 知道常见的安全漏洞(SQL 注入、XSS、CSRF)
- 能判断 AI 生成的代码是否合理、是否引入了不存在的库
- 能把业务需求翻译成 AI 能理解的 Prompt
如果找不到这样的人,AI 项目的风险比传统项目更高——因为 AI 生成代码的速度快,出问题的速度也一样快。
1.3 AI 工具矩阵
不同端、不同任务用不同的 AI 工具,作为老板要知道选什么:
| 任务 | 推荐工具 | 理由 |
|---|---|---|
| 全栈代码生成(主力) | Cursor / Windsurf | 集成 IDE,上下文管理强,可读项目文件 |
| 后端 API + MySQL | Cursor + Claude | PHP 生成质量高,复杂逻辑可拆步骤 |
| Vue 前端(PC + H5) | Cursor + Claude | 组件生成、响应式自适应 |
| 小程序 | 通义灵码 / Cursor | 国内生态理解更好 |
| iOS App(Swift) | Cursor / GitHub Copilot | 原生代码生成 |
| Android App(Kotlin) | Cursor / GitHub Copilot | 原生代码生成 |
| UI 设计 | Midjourney / Figma AI | 生成视觉稿、图标、素材 |
| 测试用例 | AI 直接生成 | 基于代码自动生成单元测试 |
| API 文档 | AI 自动生成 | 基于代码生成接口文档 |
老板决策建议:
- 不要只依赖一个 AI 工具——出现服务中断或质量下降时,要有备选
- Cursor + Claude 是目前全栈项目的最佳组合——上下文管理强,代码质量高
- 写 Prompt 的能力比选工具更重要——同样的工具,Prompt 不同结果天差地别
二、AI 开发工作流
2.1 流程对比:传统 vs AI
传统项目流程(串行):需求 → 设计 → 后端写 API → 前端开发 → 联调 → 测试 → 上线 ↑ 联调是最容易卡住的环节AI 项目流程(并行加速):需求 → AI 出设计文档 → 你确认 → AI 并行生成各端代码(后端/PC/H5/小程序/App 同时进行) → 全栈审查员审查 → AI 修复 → 测试 → 上线AI 带来的关键变化:
| 环节 | 传统项目 | AI 项目 | 变化 |
|---|---|---|---|
| 需求确认 | 2 周 | 1 周 | AI 帮写 PRD、竞品分析、原型 |
| 设计稿 | 2 周 | 1 周 | AI 辅助出图、生成组件规范 |
| 后端 API 开发 | 3-4 周 | 1-2 周 | AI 生成 API 只需写 Prompt |
| 前端开发 | 3-4 周 | 1-2 周 | AI 同时生成各端代码 |
| App 开发 | 4-6 周 | 2-3 周 | AI 生成原生代码框架+业务逻辑 |
| 联调 | 2-3 周 | 1 周 | AI 严格按 API 文档生成,兼容性更好 |
| 测试 | 2 周 | 1-2 周 | AI 生成测试用例、自动化测试 |
2.2 AI 项目工作流详解
阶段 1:需求定义(项目经理 + AI) ├─ AI 输出需求清单 + 用户故事 ├─ AI 输出竞品分析 └─ 老板确认 → 进入设计阶段 2:设计出稿(设计师 + AI) ├─ AI 生成页面布局方案 ├─ 设计师定品牌色、组件规范 ├─ AI 批量生成各端页面视觉稿 └─ 客户确认 → 进入开发阶段 3:AI 编码(全栈审查员 + AI) ├─ 第一步:AI 输出详细技术设计文档 ├─ 第二步:全栈审查员确认设计文档 ├─ 第三步:AI 按模块生成代码(后端正产→各端并行) ├─ 第四步:全栈审查员逐模块审查 └─ 第五步:AI 修复审查发现的问题阶段 4:测试(测试 + AI) ├─ AI 生成测试用例 ├─ AI 执行自动化测试 ├─ 测试补充手动测试(特别是兼容性) └─ Bug 修复:跑回阶段 3 的修复流程阶段 5:上线(项目经理 + AI) ├─ AI 生成部署文档、上线 checklist ├─ AI 生成数据迁移脚本 └─ 人执行上线操作2.3 AI 项目的核心工作流原则
原则 1:先出文档,再出代码
不管功能多简单,先让 AI 输出设计文档,人确认后再生成代码。这一步是 AI 项目最重要的质量关卡。
好的 Prompt:请先输出「收藏功能」的设计文档。 包含数据库设计、API 接口定义、前端组件结构。 我确认后再生成代码。坏的 Prompt:帮我写一个收藏功能。原则 2:一次只做一个模块
AI 的上下文窗口有限。一次塞入"用户注册、线路展示、下单支付、评论系统",AI 会顾此失彼。
正确做法:第一轮 Prompt:只做「用户注册功能」 确认代码 → Git 提交第二轮 Prompt:做「用户登录功能」 确认代码 → Git 提交第三轮 Prompt:做「线路列表接口」 ...原则 3:人的审查不可跳过
不管 AI 多强,AI 生成的代码必须经过人审查才能合并到主分支。
审查清单:□ 逻辑是否正确□ 有没有安全漏洞□ 有没有使用不存在的库/API□ 代码风格是否统一□ 异常处理是否覆盖□ 有没有硬编码原则 4:上下文是 AI 的生命线
AI 不记得昨天你让它做了什么。每次对话、每个模块都要给它足够的上下文。
上下文管理策略:
- 项目核心约定写在一个 CONTEXT.md 文件里
- 每次开始新模块前,让 AI 先读这个文件
- 关键变更同步更新到 CONTEXT.md
三、项目管理怎么变
3.1 排期估算新方法
传统排期靠经验估人天,AI 项目的排期看轮次:
一个功能模块的时间 = Prompt 设计(0.5-1 小时) + AI 生成(5-30 ��钟) + 人工审查(1-3 小时) + 修复轮次(每轮 0.5-1 小时,平均 2-3 轮)一个中等复杂度的功能(如用户注册+登录),AI 驱动的估算:
| 步骤 | 时间 | 说明 |
|---|---|---|
| 写 Prompt(含上下文准备) | 30 分钟 | 越精细,后续返工越少 |
| AI 第一次生成 | 5 分钟 | — |
| 审查代码 | 1 小时 | 看逻辑、安全、风格 |
| 修复第 1 轮 | 30 分钟 | AI 修改问题 |
| 再审查 | 30 分钟 | 确认修复到位 |
| 写入 Git + 文档 | 15 分钟 | — |
| 合计 | 约 3 小时 | 传统开发可能要 1-2 天 |
3.2 里程碑对比:传统 vs AI
| 里程碑 | 传统项目 | AI 项目 | 节省 |
|---|---|---|---|
| M1 需求确认 | 第 2 周末 | 第 1 周末 | 1 周 |
| M2 设计定稿 | 第 4 周末 | 第 2 周末 | 2 周 |
| M3 API 就绪 | 第 6 周末 | 第 3 周末 | 3 周 |
| M4 各端联调完成 | 第 10 周末 | 第 4 周末 | 6 周 |
| M5 测试完成 | 第 13 周末 | 第 5 周末 | 8 周 |
| M6 上线发布 | 第 14 周末 | 第 6 周末 | 8 周 |
核心结论:AI 驱动的项目可以把 14 周压缩到 4-6 周,主要节省在:
- 后端 API 生成速度(3-4 周 → 1 周)
- 各端并行生成(各端不再依赖前端等后端)
- 联调时间(AI 严格按 API 文档生成,兼容性好)
- Bug 修复快(AI 修复比人快得多)
3.3 AI 项目 6 周排期示例
| 周次 | 项目经理 | 全栈审查员 | 设计师 | 测试 |
|---|---|---|---|---|
| W1 | 需求确认、Prompt 策略设计、搭建 CONTEXT.md | 技术方案评审、API 文档 Prompt | 品牌规范、核心页面设计 | 准备测试计划、AI 生成测试用例模板 |
| W2 | 管理 AI 输出后端 API + 生成 API 文档 | 审查后端代码 + 数据库设计 | 各端页面设计稿 | 开始 API 测试 |
| W3 | 管理 AI 生成 PC/H5 前端、小程序、App | 审查各端代码 | 切图交付 | 各端功能测试 |
| W4 | 联调跟进 | 联调 Bug 修复(AI 辅助) | 设计稿补充/调整 | 全流程回归测试 |
| W5 | 性能优化 Prompt、安全审查 Prompt | 安全审计、性能优化 | 上线素材 | 验收测试 |
| W6 | 上线管理、部署文档(AI 生成) | 上线支持 | 上线素材交付 | 上线前回归 |
3.4 进度追踪方法
传统项目用"代码完成度"估算进度。AI 项目可以用更精确的方法:
每功能模块的进度状态:□ D1 - Prompt 已写好□ D2 - AI 第一次生成完成□ D3 - 审查完成(待修复)□ D4 - 所有修复轮次完成□ D5 - 已合并到主分支□ D6 - 测试通过项目经理每天统计各模块的状态分布,一眼看出进度:
W2 周五进度快照:用户模块: D6 ✅ 已完成线路列表: D6 ✅ 已完成线路详情: D4 ✅ 已审查,AI 修复中下单流程: D2 ⚠️ 刚进入 AI 生成支付集成: D1 ⏳ Prompt 设计中后台管理: D1 ⏳ Prompt 设计中四、AI 代码的质量管控
4.1 审查机制
AI 项目最容易被忽略但最重要的环节:代码审查。
AI 代码审查流程:AI 生成代码 → 全栈审查员审查 ├─ 通过 → 合并到主分支 ├─ 小问题 → 让 AI 修复,再审查一次 └─ 大问题 → 回退 Prompt,重新生成审查优先级:
| 优先级 | 审查重点 | 说明 |
|---|---|---|
| P0 | 安全漏洞 | SQL 注入、XSS、CSRF、权限绕过、敏感信息泄露 |
| P0 | 业务逻辑 | 核心流程是否跟需求一致,条件判断是否正确 |
| P1 | 代码合理性 | 是否有幻觉(用了不存在的 API/库)、死代码 |
| P1 | 性能 | N+1 查询、死循环、不必要的重复请求 |
| P2 | 代码风格 | 命名规范、注释质量、目录结构 |
| P2 | 异常处理 | 边界情况、错误提示、日志记录 |
4.2 AI 代码常见问题清单
作为老板,让团队重点关注 AI 代码的这些"老毛病":
| 问题类型 | 表现 | 概率 | 如何发现 |
|---|---|---|---|
| API 幻觉 | 调用了不存在的 API 方法或参数 | �� | 编译/运行时报错 |
| 版本幻觉 | 用了不存在的库版本或有 Breaking Change 的 API | 中 | 检查依赖版本号 |
| 逻辑跳跃 | 跳过了一些边界判断,假设数据"一定存在" | 中 | 审查时关注 if-else |
| 安全遗漏 | 没做权限校验、没做输入过滤 | 高 | 逐行检查接口权限 |
| 过度复杂 | 为了"通用"写了远超需求的抽象代码 | 中 | 看代码量是否远大于需求 |
| 不一致 | 不同模块风格差异大(命名、格式) | 高 | 统一审查标准 |
| 硬编码 | 配置项写死在代码里 | 中 | 审查时标注 |
4.3 安全性专项审计
AI 生成的代码在安全性方面需要特别关注。以下场景必须人工逐行审查:
高风险审查清单:□ 用户输入的 SQL 拼接——有没有用参数化查询?□ 用户输入的 HTML 输出——有没有做 XSS 过滤?□ 接口权限——未登录用户能否访问需要登录的接口?□ 金额计算——浮点数精度问题、前端传金额有没有后端验证?□ 文件上传——文件类型限制、大小限制、路径穿越防护?□ 密码存储——有没有用 bcrypt 等安全哈希?□ Token 管理——过期机制、刷新机制、签名密钥强度?□ 第三方回调验证——支付回调有没有验证签名?老板要记住:AI 不会主动做安全防护,除非你明确要求。每次 Prompt 里都要加一句:
要求:所有用户输入必须做参数校验和 XSS 过滤。所有需要登录的接口必须鉴权。所有 SQL 查询使用参数化查询,禁止字符串拼接。4.4 测试策略
AI 项目测试可以大量用 AI 生成:
AI 生成测试用例 → 人确认 → AI 生成测试代码 → 人审查 → 执行| 测试类型 | AI 能做的 | 人需要做的 |
|---|---|---|
| 单元测试 | 基于代码自动生成 90% 的用例 | 补充边界情况 |
| API 测试 | 自动生成接口测试脚本 | 确认业务逻辑正确 |
| UI 测试 | 生成 E2E 测试框架代码 | 跑不同浏览器/真机 |
| 性能测试 | 生成 JMeter 脚本 | 分析瓶颈 |
| 安全测试 | 生成常见漏洞测试用例 | 专项安全审计 |
五、Prompt 工程管理
5.1 Prompt = 公司资产
传统项目积累的是代码库,AI 项目积累的是 Prompt 库 + 上下文文档。
代码可以用完即弃,但好的 Prompt 可以复用——同类型的模块(用户注册、商品列表、支付),Prompt 修修改改就能用在下一个项目。
# 公司 Prompt 资产目录(示例)/ai-prompts ├── backend/ │ ├── user-module.prompt.md # 用户模块 Prompt │ ├── order-module.prompt.md # 订单模块 Prompt │ └── payment.prompt.md # 支付模块 Prompt ├── frontend/ │ ├── pc-page.prompt.md # PC 端页面 Prompt │ └── h5-page.prompt.md # H5 端页面 Prompt ├── app/ │ ├── ios-screen.prompt.md # iOS 页面 Prompt │ └── android-screen.prompt.md # Android 页面 Prompt └── templates/ ├── code-review.prompt.md # Code Review Prompt ├── bug-fix.prompt.md # Bug 修复 Prompt └── api-doc.prompt.md # API 文档 Prompt5.2 项目级 Prompt 标准化
同一个项目,不同人写 Prompt 风格差异大,输出质量也不稳定。需要标准化:
# 【标准化 Prompt 模板】## 项目上下文(每次都让 AI 先读这个文件)→ 技术栈、数据库、目录结构、编码规范## 功能描述→ 一句话概括 + 用户操作流程## 输出要求→ 文件路径、代码风格、注释规范## 约束→ 禁止使用 xxx、必须处理 xxx## 示例(可选)→ 类似功能已有的代码示例## 质量要求→ 安全性、异常处理、性能要求5.3 上下文管理
AI 项目的成败系于上下文管理。一个做得好 vs 做得差的对比:
❌ 做差了: 每次开新对话,项目经理重新口述一遍需求, AI 不知道项目背景,生成的代码跟已有代码不兼容。✅ 做好了: 项目有一个 CONTEXT.md,包含了: - 技术栈声明(PHP 8.2 / Vue 3.4 / MySQL 8) - 编码规范(PSR-12 / Composition API / 禁止 any) - 数据库表结构 - 已有 API 列表 - 目录树 - 关键约定(统一返回格式、JWT 鉴权方式等) 每次新功能对话前,先让 AI 读 CONTEXT.md → 再提需求CONTEXT.md 的结构建议:
# 项目上下文## 基本信息- 项目:旅游网站- 技术栈:PHP 8.2 + Vue 3 + MySQL 8 + Redis- 四端:PC / H5 / 微信小程序 / iOS & Android App## 编码规范- PHP:PSR-12,控制器不写业务逻辑- Vue:Composition API + TypeScript 严格模式- 所有 API 统一返回:{ code, message, data }- 数据库命名:全小写+下划线## 数据库- 全部使用 InnoDB- 主键统一为 id(自增)- 每表有 created_at、updated_at- 不物理删除(用 status 字段)## 目录结构(略,用 tree 命令输出)## 已完成的模块- [x] 用户注册登录- [x] 线路列表- [/] 线路详情(开发中)六、AI 特有的风险
6.1 风险矩阵
| 风险类别 | 风险项 | 概率 | 影响 | 应对措施 |
|---|---|---|---|---|
| 质量风险 | AI 幻觉——生成不存在的 API、库、方法 | 高 | 高 | 逐行审查、关键代码手动验证 |
| 质量风险 | 上下文失控——AI 忘记之前生成的代码结构 | 高 | 高 | CONTEXT.md 维护、模块化开发 |
| 质量风险 | 代码不一致——各端代码风格混乱 | 高 | 中 | Prompt 模板标准化 |
| 安全风险 | 安全遗漏——未处理输入校验、权限校验 | 高 | 极高 | AI Code Review + 人工安全审计 |
| 安全风险 | 敏感信息泄露——API Key、密码被写入代码 | 中 | 极高 | 关键词扫描、.env 分离配置 |
| 技术风险 | 版本幻觉——引用了不存在的库版本 | 中 | 高 | 生成后验证依赖可安装 |
| 技术风险 | 供应商锁定——依赖某 AI 工具的独家功能 | 低 | 高 | 储备备选 AI 工具 |
| 进度风险 | AI 生成质量波动——同 Prompt 不同结果 | 中 | 中 | 多生成几次取最优、标准 Prompt |
| 进度风险 | AI 服务不可用——API 中断或限流 | 低 | 高 | 备选工具、本地模型 |
| 人员风险 | 审查员跟不上 AI 的速度 | 高 | 高 | 审查员数量跟上 AI 产出速度 |
| 版权风险 | AI 训练数据版权问题 | 低 | 中 | 不直接复制开源代码、走标准流程 |
6.2 AI 项目最致命的三个坑
致命坑 1:审查员是瓶颈
AI 生成代码的速度远快于人审查的速度。AI 可能 10 分钟生成了一个模块,审查要 2 小时。如果审查跟不上,要么代码堆积、要么审查敷衍了事。
解决思路:- 审查员数量要跟上 AI 速度(1 个 AI 配 1-2 个审查员)- 用 AI 审查 AI 生成的部分代码(自动化安全检查)- 核心模块精审,工具类/模板代码快速过致命坑 2:上下文丢失导致返工
AI 工作到第 3 周,上下文窗口里的早期约定被"挤出去"了。新生成的代码不符合早期的架构约定,导致大范围返工。
解决思路:- ALL CAPS 原则:Anything Large, Lost Context, Always Put Summary- 每次新对话开头,先让 AI 读 CONTEXT.md- ���键决策写入文档,不要只存在对话历史里- 定期"对话压缩":让 AI 总结已完成的工作,生成新版本 CONTEXT.md致命坑 3:出了问题不知道是 AI 的锅还是人的锅
Bug 出现后,AI 可能说"这是你给我的 Prompt 有问题",人也可能说"AI 生成的代码我没仔细看"。
解决思路:- 所有 ai-generated 代码在 PR 中标注来源- Bug 根因分析时区分"Prompt 写的不够好"vs"审查没发现"vs"AI 明知故犯"- 每次出问题,优化三个方面: 1. Prompt 是否写清楚了 2. 审查流程是否到位 3. AI 工具是否需要更换6.3 回滚策略
AI 项目回滚比传统项目多一个维度:
| 回滚层级 | 操作 | 适用场景 |
|---|---|---|
| L1 - 代码回滚 | Git revert 到上一版本 | AI 生成的代码有 Bug |
| L2 - Prompt 回滚 | 回到上一版 Prompt | Prompt 改坏了导致 AI 输出质量下降 |
| L3 - 上下文回滚 | 回到上一个 CONEXT.md 版本 | 上下文文档更新导致 AI 误解 |
建议:CONEXT.md 和重要 Prompt 统一用 Git 管理版本。
七、AI 项目实战推演
7.1 旅游网站 AI 开发实战流程
以旅游网站的核心模块"线路列表"为例,展示 AI 开发的完整闭环:
Step 1:项目经理写 PromptPrompt 示例:# 项目上下文(此处贴 CONTEXT.md)# 需求描述实现旅游线路列表页面的 API 接口。## 功能要求1. GET /api/routes — 分页获取线路列表 - 支持参数:page, pageSize, keyword, category_id, price_min, price_max - 返回:线路ID、标题、封面图、价格、评分、出发城市2. GET /api/routes/{id} — 获取线路详情 - 返回:完整详情(图文内容、行程安排、费用说明、用户评价)## 技术约束- 使用 PHP 8.2 + ThinkPHP 8- 数据库表:routes(线路主表)- 分页统一格式:{ list[], page, pageSize, total }- 图片 URL 返回完整地址(不要相对路径)## 输出要求- 生成文件:Controller、Service、Model、路由配置- 代码风格:PSR-12- 异常处理:全局异常捕获,不 try-catch 业务逻辑## 质量要求- SQL 防注入(参数化查询)- 没上架的线路不对用户展示- 搜索关键词防 XSSStep 2:AI 生成代码Step 3:全栈审查员审查代码 ├─ 发现问题 1:关键词搜索没有做防 SQL 注入 ├─ 发现问题 2:价格排序没有做防篡改 └─ 发现问题 3:未登录用户的访问次数限制没做Step 4���审查员写修复 Prompt修复 Prompt:请修复以下问题,只改涉及到的文件:1. 关键词搜索使用参数化查询,不要字符串拼接2. 价格参数在服务端做范围校验(不能为负数、不能超过 999999)3. 未登录用户每小时最多调用 100 次该接口(用 Redis 计数)Step 5:AI 修复 → 审查员确认 → 合并到主分支7.2 各端生成的 Prompt 策略
同一个功能(线路列表),不同端的 Prompt 不同:
| 端 | Prompt 要点 | 差异 |
|---|---|---|
| 后端 API | 数据库查询、分页、权限、缓存 | 核心:数据层 |
| PC 前端 | 多列列表布局、分页组件、Hover 效果 | 信息密度高 |
| H5 前端 | 单列卡片、无限滚动加载、触摸友好 | 纵向滚动、大点击区域 |
| 小程序 | 微信原生组件、下拉刷新、分享 | 微信生态集成 |
| iOS App | SwiftUI/UIKit、原生动画、推送 | 原生体验 |
| Android App | Jetpack Compose、原生导航、推送 | 原生体验 |
AI 的优势:同一功能,各端 Prompt 的核心逻辑(业务规则、API 调用)是一样的,只是 UI 层和平台特性不同。先让 AI 生成后端 API → 各端基于 API 并行生成 → 效率极高。
7.3 典型 AI 开发日节奏
09:00 - 09:15 项目经理准备今天要做的功能 Prompt09:15 - 09:30 全栈审查员安排今天审查优先级09:30 - 10:30 AI 生成上午的功能代码10:30 - 12:00 审查员审查 + AI 修复14:00 - 15:00 AI 生成下午的功能代码15:00 - 16:30 审查员审查 + AI 修复16:30 - 17:00 提交 Git、更新进度、整理第二天的 Prompt一天大约完成 2-3 个中等复杂度的功能模块(传统团队一天做 0.5-1 个)。
八、老板决策指南
8.1 什么阶段用什么策略
AI 不是万能的。不同阶段 AI 的适用度不同:
| 阶段 | AI 适用度 | 做法 |
|---|---|---|
| 需求分析 | ★★★★★ | AI 帮写 PRD、竞品分析、用户故事 |
| UI 设计 | ★★★★☆ | AI 出初稿方案,设计师调整定稿 |
| 后端 API | ★★★★★ | AI 生成 90%,审查员确认 |
| 前端页面 | ★★★★★ | AI 生成 80%,前端微调 |
| 小程序 | ★★★★★ | AI 生成 85%,适配+支付手工处理 |
| App 原生 | ★★★★☆ | AI 生成 70% 代码,原生特有逻辑(推送/支付SDK)手工处理 |
| 数据库设计 | ★★★★☆ | AI 出初版,审查员确认索引和关联 |
| 安全审计 | ★★☆☆☆ | AI 辅助扫描,人工逐行审查高敏代码 |
| 性能优化 | ★★★☆☆ | AI 定位问题,方案需要人判断 |
| 项目上线 | ★★☆☆☆ | AI 生成部署文档和脚本,操作人执行 |
8.2 投入产出比判断
| 团队规模 | 传统项目 | AI 项目 | 节省 |
|---|---|---|---|
| 人数 | 9-10 人 | 3-4 人 | 60-70% |
| 周期 | 14 周 | 4-6 周 | 60-70% |
| 成本 | 100% | 35-45% | 55-65% |
但要注意:AI 项目的质量风险更高,如果交付质量不好,返工成本也更高。
老板决策三问:
- 团队里有合格的全栈审查员吗? — 如果没有,AI 的风险 > 收益
- 项目对安全性和稳定性要求高吗? — 涉及支付、用户数据,需要更严格的人工审查
- 你有时间维护 Prompt 资产吗? — AI 项目前期投入在 Prompt,后期才有回报
8.3 AI 项目管理 10 条铁律
1. 先出文档,再出代码 —— AI 的设计文档省掉 90% 的返工2. 一次只做一个模块 —— AI 的上下文不是无限的3. 审查不可跳过 —— AI 生成的每一行代码都要有人看过4. 上下文是生命线 —— 写在文档里,不要存在 AI 的记忆里5. Prompt 要标准化 —— 不是写代码,是写"让 AI 写代码的指令"6. 安全审查不能信 AI —— 涉及钱/隐私的部分,自己看7. Git 每模块提交一次 —— AI 改崩了能回滚8. 保留备选 AI 工具 —— 一家挂了换另一家9. 审查员跟不上 = 项目崩塌 —— 审查员的数量和质量决定了项目质量10. AI 是加速器,你仍然是导演 —— 方向和判断还是人的事附:AI 项目老板速查清单
项目启动
□ 团队最小配置确认(项目经理 + 全栈审查员 + 设计师 + 测试)□ 全栈审查员到位 —— 这是 AI 项目最关键的角色□ CONTEXT.md 已写好 —— AI 的"项目说明书"□ AI 工具已选定(主力 + 备选)□ Prompt 模板标准化已完成□ AI 工具账号和权限已准备好每日检查
□ 今天 AI 生成了多少代码?是否超出了审查能力?□ 有没有发现 AI 幻觉(不存在的 API/库)?□ CONTEXT.md 需不需要更新?□ 有没有遇到 AI 工具的问题?每周复盘
□ 本周完成的模块数 vs 计划□ AI 代码的质量评分(Bug 数、返工轮次)□ Prompt 是否需要优化(同一个问题重复出现两次就说明 Prompt 有问题)□ 审查员是否跟得上进度?□ AI 工具是否有异常(限流、质量下降)?上线前
□ AI 生成的代码已经全部经过审查□ 核心流程(浏览→下单→支付)人肉走了一遍□ 安全审计已完成(SQL 注入、XSS、权限校验)□ 所有 API Key 和密钥已从代码中移除(放到 .env)□ 各端 AI 生成的代码已通过编译/构建□ 部署文档和回滚方案已就绪总结
AI 让软件开发从"手工作坊"进入"工业化生产"——速度提升了数倍,但对管理提出了新要求。
管好一个 AI 驱动的项目,核心三件事:
- 管好上下文——CONTEXT.md 是 AI 的"大脑",它不知道自己不知道什么,项目上下文全靠你喂给它
- 管好质量——审查员是 AI 项目的"质检员",AI 生成速度快,但质量靠人来兜底
- 管好 Prompt——Prompt 不仅是给 AI 的指令,更是公司的知识资产。标准化、版本化、复用化
AI 不是取代了人,而是重新定义了人的角色。
- 以前:人写代码,机器运行
- 现在:人写 Prompt,AI 写代码,人审查 AI 写的代码
- 未来:人负责"判断什么值得做",AI 负责"怎么做"
作为老板,你的职责没变——确保项目在正确的轨道上。 变的只是:以前管人,现在管 AI + 管管 AI 的人。