夜雨聆风
这是“酱+”的第9篇。加个AI外挂，让你的PM能力原地升级。今天投的料是——
用AI做项目论证。
项目失败的原因，绝大多数是启动之前就已经埋下了雷。所谓的风险，有的时候也可以理解为，是每一步做的不踏实的细小缝隙，在偶然的条件下带来的局部放大。
目标是一句口号，范围是一页PPT，预算是拍脑袋的数字，ROI是一张Excel表里的公式。所有人在立项会上点头，但没有人真正关心过：这个项目到底值不值得做、有没有能力做、做完之后谁来用。
千里之堤，溃于蚁穴。以小见大，草灰蛇线。
然而命运专戏PM，虽然往往不参与立项决策，但是，却要承担立项草率的全部后果（俗称：背锅）。按照常规流程，项目交到手上时，章程已经签了，范围已经定了，资源已经“原则上支持”了。此时再追问“为什么要做这个项目”，可能被视为挑战决策。但如果不问，那些立项阶段被忽略的问题，会在执行阶段成倍放大——
一个未被澄清的目标，会衍生出十次需求变更。一个未被验证的假设，会造成一轮方向调整。一个未被识别的约束条件，会让整个排期形同虚设。
于是PM发展出一种隐性能力：在接到项目后、启动会之前，用极短的时间快速做一轮自我论证。不是走流程，不是写报告，是把那些“立项时没人问、但执行时一定会碰到”的问题先捋一遍。这份功课不在任何流程文件里，但每个经验丰富PM的基操。
AI来了，PM终于有了强大的后盾，不再孤单~
一、项目论证：从“走过场”到“真问题”
正式的项目论证流程存在于文件夹中，具体怎么执行在管理层和PMO手中。比如商业论证、可行性分析、投资回报测算，属于决策层工具。但当项目交到执行层PM手上时，需要另一套更务实的论证框架——不回答“值不值得投资”，而是回答“能不能顺利交付”。
这两层论证的差异如下表所示。
执行层论证不改变决策层论证的结果，但能揭示决策层论证中那些“被假设成立、但实际可能不成立”的前提条件。
这种“去伪存真”，至关重要。否则，进入执行阶段后，因为前提构想不细致带来的风险和问题，都可能归咎于项目经理的个人能力上（俗称：背锅）。
二、AI辅助项目论证的四个维度
执行层论证需要覆盖四个维度。重心不再商业分析的严谨性，而是PM执行视角下的可操作性。
第一维：目标可验证性。
项目目标最常见的问题并不一定是错的，而是“无法验证”。一个目标如果是“提升用户体验”，项目做完后无法判断是否达成。可验证的目标需要满足SMART标准——具体、可衡量、可达成、与战略相关、有时间边界。
AI在这一维度的角色是：逐条审查目标陈述，标注模糊表述，要求定义对应的衡量指标。
第二维：范围边界。
范围定义中最有价值的部分不是“包含什么”，而是“明确排除什么”。未明确排除的内容，在项目执行中默认为“可以加”。这是范围变更的根本原因之一。
AI在这一维度的角色是：扮演“最激进的需求方”，模拟未来可能出现的范围扩展请求，测试当前范围边界的抗压能力。
第三维：关键假设。
项目计划可行的前提是，推演出一组可行的假设条件。比如关键人员按时到位、第三方接口按时交付、需求冻结后不再变更、预算不缩减。这些假设通常不被明确列出，因为它们是“常识”和默认。但项目延误最多的原因，正是常识被打破。
AI在这一维度的角色是：从项目计划中提取所有隐含假设，逐一评估其失效概率和失效影响。
第四维：历史相似性。
每个项目都有各有特色，但失败模式往往相同。一个PM最多同时记住几个项目的经验教训，但AI可以遍阅所有历史复盘记录，在数秒内找出“和这个项目特征最接近的项目，最容易在哪个阶段出什么事”。
AI在这一维度的角色是：基于历史项目经验库，对新项目进行相似性比对，输出“这类项目最常见的风险模式”。
四个维度构成一个逻辑闭环：
目标定义了“要做什么”，范围定义了“做多少”，假设定义了“前提是什么”，历史相似性提供了“可能在哪翻车”。
三、完整提示词组合
第一维提示词：目标可验证性审查
你是一位项目论证顾问。以下是一个项目的目标陈述。请逐条审查，完成以下工作：
标注模糊词汇。指出目标中无法被第三方客观验证的表述（如“提升”“优化”“完善”“增强”），并说明为什么该表述不可验证。
对每个模糊表述，追问一个澄清性问题。问题的目的是迫使目标制定者定义出可衡量的标准。
如果目标中已包含量化指标，检验该指标是否满足以下条件：有明确的计算方法、有可采集的数据来源、有可判断“达成/未达成”的阈值。
项目目标陈述：[粘贴]
第二维提示词：范围边界压力测试
你正在扮演一个“最激进的需求方”。你的立场是：尽量推动项目范围扩大，不断寻找目标陈述和范围说明中的模糊地带，要求将其纳入项目范围内。
以下是该项目的目标陈述和范围说明。请开始你的压力测试：
逐条列出你认为可以“合理要求”加入范围的新增内容。每条需附带理由——为什么你认为它属于本项目。
对每条新增内容，标注它对应了原始范围说明中哪一处未说清楚的边界。
你的输出不是为了真的扩大范围，而是为了测试现有范围边界的清晰程度。请在输出末尾，用“边界加固建议”的形式，列出此次压力测试暴露出的范围定义薄弱点，以及对应的修订建议。
[项目目标+范围说明粘贴]
第三维提示词：关键假设审查
以下是一份项目计划。请提取其中所有隐含假设。隐含假设的定义：计划中未明确陈述、但计划的有效性依赖其成立的任何条件。
对每一条提取出的假设，标注：
假设内容
如果该假设不成立，对项目的影响程度（高/中/低）
该假设失效的概率（高/中/低）
失效的早期预警信号（什么现象出现时，说明这个假设正在动摇）
建议的应对预案（如果假设即将失效，PM应在什么时间点采取什么动作）
按“影响程度×失效概率”的乘积从高到低排序输出。
[项目计划粘贴]
第四维提示词：历史相似性比对
以下分两部分提供给你：
第一部分：新项目的核心特征——行业、项目类型、规模、周期、涉及部门、关键技术或业务特征。第二部分：历史项目的复盘记录库（经验条目表）。
你的任务：
在历史记录中寻找与第一部分特征相近的项目。
识别这些历史项目中最常出现的三类问题。
对每类问题，输出：问题描述、在哪些历史项目中出现、对新项目的适用性评估（该类问题在新项目中出现的可能性及理由）。
综合以上，输出一份“启动前应重点关注的风险清单”。
[第一部分：新项目特征][第二部分：历史项目经验条目]
四、论证结果的应用：与启动会材料衔接
论证不是独立工序，它的产出应直接流入启动过程。四维论证与启动会材料之间的对应关系如下：
目标审查的产出→直接写入项目章程的“成功标准”栏。被AI标注为模糊的表述，在章程中替换为量化指标。
范围压力测试的产出→直接写入范围说明书“明确排除的内容”部分。AI暴露出的边界薄弱点，逐条列为排除项。
假设审查的产出→直接进入启动会风险预案。假设失效的概率和影响排序，决定风险预案的优先级。
历史相似性比对的产出→形成启动会上的“经验提示”环节。用历史项目的实际案例，而非抽象说教，向团队说明风险的存在。
论证的输出成为启动会材料的输入。PM在启动会上呈现的，是一套经过事前检验、基于历史经验、有预案支撑的项目起点。
酱缸笔记
项目论证不是走流程，是在启动前给自己和团队一个交底的机会——我们有权利，真正关心项目，是否真的已经做好开始执行的准备。
AI不直接做决策，但在做决策之前，可以确保该问的问题都被问了——假设没用被遗漏，经验教训已经get，不可控因素也都被讨论过，甚至风险，大家都心里有数。
这才是火候到了，可以做了，而不是deadline到了，必须做了。
所以，PM们，下次接到新项目，先别着急开（背）工（锅），先自我论证一番：
让项目，先过了你这一关再说。
明天继续投料：论证后的下一个关——用AI辅助项目启动会，事半功倍。
一口酱缸，三种发酵。酱+做加法，酱×做乘法，酱∞探无穷。工作日加料造物，周末沉下来想清楚。
如果这篇对你有用，点个「在看」，让更多PM一起入缸。还没关注的，点个关注，这口缸里还会酿出更多东西。
