怎么用：AI 项目按「立项→执行→变更→验收」四个环节走，每个环节有一份必备文档，下面给了清单和可直接填写的模板。新项目开工前花 1 小时把立项单填完，后面照表推进就行。
先说清楚：为什么要「像管工程一样管」
AI 项目最常见的烂尾方式是：一开始说得很热闹，做着做着需求一直变，最后没人说得清做完没有。
工程化的意思就是：每个环节有文档、每次变动有记录、做没做完有标准。不是为了走形式，是为了出了分歧时有东西可以对照。
四个环节文档总览
| 环节 | 必备文档 | 谁写 | 谁签字确认 | 不做的后果 |
|---|---|---|---|---|
| 立项 | 立项单 | 项目负责人 | 老板 / 需求方 | 目标不清，做到一半各说各话 |
| 执行 | 周进度表 + 问题清单 | 项目负责人 | 需求方每周看 | 进度靠嘴说，问题拖到最后爆 |
| 变更 | 变更申请单 | 提出变更的人 | 老板 / 需求方 | 需求越改越多，工期和预算失控 |
| 验收 | 验收单 | 项目负责人 | 需求方 | 永远「差一点」，没法收尾 |
一、立项单模板
项目名称：【例：客服常见问题 AI 起草回复】 要解决的问题：【一句话，例：客服每天花 3 小时回重复问题】 范围（做什么）：【例：只覆盖售前咨询的 50 个常见问题】 范围（不做什么）：【例：不处理售后退款、不接入电话客服】 成功标准：【可量化，例：试运行两周后，AI 起草回复的采纳率达到【 】】 时间：开始【 】，试运行【 】，验收【 】 预算：【人力、工具费用】 负责人：【 】 需求方对接人：【 】 需要对方提供的资料：【例：近三个月客服聊天记录、价格表、售后政策】 风险预估：【例：资料整理不及时会推迟上线】 签字确认：需求方【 】 日期【 】
立项单最关键的一栏是「不做什么」，写清楚了，后面能省一半扯皮。
二、执行：周进度表
| 周次 | 本周计划 | 实际完成 | 完成度 | 卡在哪 | 需要谁配合 | 下周计划 |
|---|---|---|---|---|---|---|
| 第 1 周 | 【 】 | 【 】 | 【 】 | 【 】 | 【 】 | 【 】 |
| 第 2 周 | 【 】 | 【 】 | 【 】 | 【 】 | 【 】 | 【 】 |
问题清单（问题一出现就登记，不要攒）
| # | 问题描述 | 发现日期 | 影响程度（高/中/低） | 负责人 | 计划解决日期 | 状态 |
|---|---|---|---|---|---|---|
| 1 | 【 】 | 【 】 | 【 】 | 【 】 | 【 】 | □ 待处理 □ 处理中 □ 已解决 |
三、变更申请单
变更内容：【例：增加售后退款问题的回复】 提出人：【 】 日期：【 】 为什么要变：【 】 对工期的影响：【例：延后 1 周】 对费用的影响：【例：增加【 】元 / 不增加】 对已完成部分的影响：【例：需要重新测试】 决定：□ 同意，本期做 □ 同意，放到下一期 □ 不做 签字：【 】
变更时这么说，直接复制：
「这个想法很好，我先登记到变更单里。它会让工期多出【 】天，我建议放到第二期做，先把这一期的目标跑通，您看行吗？」
四、验收单
| 验收项（来自立项单的成功标准） | 目标值 | 实际值 | 是否达标 | 证据（截图/记录/表格） |
|---|---|---|---|---|
| 【例：AI 起草回复采纳率】 | 【 】 | 【 】 | □ 达标 □ 未达标 | 【 】 |
| 【例：每日回复耗时】 | 【 】 | 【 】 | □ 达标 □ 未达标 | 【 】 |
| 【使用培训已完成】 | 全员 | 【 】 | □ 达标 □ 未达标 | 【签到表】 |
| 【交接文档已提供】 | 有 | 【 】 | □ 达标 □ 未达标 | 【文档链接】 |
验收结论：□ 通过 □ 有条件通过（遗留问题见下） □ 不通过 遗留问题及处理时间：【 】 需求方签字：【 】 日期：【 】
开工前自查清单
用完之后：照着做完还卡在哪一步，评论区或私信告诉我，我帮你看。
出品：帅厂长｜增长飞轮AI · 帮企业用 AI 搭一套自己会转的增长系统