做企业软件项目, AI 到底该帮什么忙?

四象限一｜我对这件事到底懂多少

① 我知道我知道｜帮我把判断做扎实

有些事，项目经理心里已经有判断。AI 不需要替你拍板，适合帮你把证据理顺，再从旁边挑挑刺。

项目里的例子：项目延期，我基本判断是主数据迟迟没有定稿，关键用户又一直被日常工作占用。与其问 AI“项目为什么延期”，不如把计划、问题单和会议记录给它，让它检查我的判断有没有漏掉范围变化、接口联调或资源投入的问题。

我的做法：判断自己下，材料让 AI 整理，反例让 AI 来找，最后还是自己拍板。

② 我不知道我知道｜把经验问出来

老项目经理常常一进会场，就能感觉这个项目能不能按时上线，但让他说判断标准，未必一下说得完整。这些经验都在，只是还没写出来。

项目里的例子：看到客户一把手很少出席、关键用户总说“再内部确认一下”、数据模板反复退回，经验丰富的项目经理会立刻警觉。让 AI 拿几个成功和失败项目逐个追问，就能慢慢整理出一张可复用的上线风险检查表。

我的做法：不急着让 AI 给结论，先让它问，我负责讲真实案例，最后一起把经验写成检查项。

③ 我知道我不知道｜先帮我补课

知道自己哪块不懂，其实已经很好办。先补最影响项目判断的那部分，不必一口气把整个领域学完。

项目里的例子：我负责总体交付，但对财务月结、成本结转不够熟。碰到 ERP 财务上线方案时，我会先让 AI 把月结流程、关键凭证、前后依赖和常见失败点讲清楚，再拿这些问题去找财务顾问和客户财务负责人核实。

我的做法：先弄懂一张业务地图，再带着问题找专业的人确认，不能学了几个概念就直接做决定。

④ 我不知道我不知道｜帮项目组找漏项

项目最容易出大问题的地方，往往不是清单上已经写出来的风险，而是所有人都没想到的那一项。

项目里的例子：上线计划把功能、培训和数据迁移都排得很细，却没人问上线当天是否正好撞上月底关账，老系统接口有没有调用上限，仓库夜班的网络和打印设备能不能撑住。AI 可以按业务、数据、接口、权限、设备和组织准备逐项扫一遍，帮团队把没问过的问题翻出来。

我的做法：让 AI 帮忙找漏项，找出来以后，再由项目组逐项核实，不能把它列出的风险直接当事实。

四象限二｜我与 AI 的知识组合

① 我知道 × AI 知道｜适合交给 AI 先做

规则清楚、重复度高、做完还能检查的工作，可以大胆交出去。省下来的时间，用来盯真正影响交付的事。

项目里的例子：会议纪要转待办、周报汇总、问题单分类、测试案例初稿、培训材料改写，这些项目经理和顾问都会做，AI 也能做。只要模板、口径和检查标准明确，就让它先出第一版，人负责复核。

重点不是自己会不会做，而是能不能把要求说清、把结果验好。

② 我知道 × AI 不知道｜先把项目背景问清

客户内部关系、合同里的历史承诺、哪个关键用户在抵触、老板真正盯什么，这些都不在通用知识里。你不说，AI 只能猜。

项目里的例子：客户说“按标准产品做”，但销售阶段其实承诺过几项特殊功能；信息部门支持上线，业务部门却担心新系统让工作更麻烦。AI 如果不知道这些背景，给出的推进方案一定很平。先把关键人、历史承诺和真实阻力讲清楚，再让它帮忙整理沟通方案。

信息不够时，先让 AI 提问，别急着让它写方案。

③ 我不知道 × AI 知道｜AI 先讲，懂行的人来核

这一格最容易吃亏：自己不熟，看 AI 说得头头是道，就以为可以直接拿去用。越是不懂，越要留一道核实。

项目里的例子：项目经理不熟 SQL，AI 很快写出一段数据修复脚本；顾问不熟某个行业，AI 也能列出一套流程。脚本必须先在备份数据上验证，行业流程也要找客户业务负责人确认。听起来专业，不等于适合这个项目。

可以让 AI 先讲、先做，但上线动作、数据处理和业务口径必须由懂行的人确认。

④ 我不知道 × AI 不知道｜先试点，别装有答案

遇到从来没跑过的新模式，项目组没有现成答案，AI 也没有。这时最忌讳硬凑一个看上去完整的方案。

项目里的例子：客户想把原来靠老师傅经验排产的方式，直接改成系统自动排产。规则能不能覆盖现场变化，车间愿不愿意用，大家都没把握。先选一条产线、一个班次做试点，把人工调整原因记录下来，再决定规则怎么改，比直接全厂上线稳得多。

没有答案就先做小试点：提一个假设，拿真实数据验证，再决定下一步。

整理员纪要、周报、问题单和材料初稿，让它先做。

采访者通过追问，把老项目经理脑中的经验写出来。

讲解员遇到不熟的业务和技术，先帮我补一张地图。

排查员按不同角度扫一遍，找出项目组没问到的问题。

陪练没有成熟答案时，帮忙列假设、设计小范围验证。