要让Claude写项目提案,需要提供你要解决的问题、提案是给谁看的以及你需要对方做出什么决定、你的真实约束条件(团队规模、大致时间表、预算范围),以及要求将草案结构化为问题陈述、建议方案、范围、时间表和成功指标的指示。粘贴你已有的任何背景材料、以前的提案或笔记,并让Claude标出哪些部分太笼统,无法变成具体计划。
发布于
免费课时 · 无需注册账号认识 Claude为什么是 Claude？6分钟开始免费课时要点总结
- 说明这份提案是给谁看的,以及你需要对方做出什么决定。一份供自己团队规划用的提案,读法和一份请高管批准预算的提案不同。
- 把你的真实约束条件告诉Claude:团队规模、大致时间表、预算范围。基于编造约束条件写出的方案,一旦有人用真实数字去读,就必须重写。
- 具体要求成功指标,而不只是工作内容的描述。一份没说清楚如何判断是否成功的提案更难获批,日后也更难追踪。
- 粘贴你已有的背景材料:以前的提案、会议笔记、一份粗略大纲。Claude能整理和打磨你给它的内容,但编不出你这个具体项目背后的来龙去脉。
- 发送前要特别仔细读一遍范围部分。比你真实意图更模糊或更宽泛的范围,是提案日后出问题最常见的原因。
复制即用
今天就能用的提示词
从一个粗略想法写出第一份完整草案
我想提议[用一两句话描述你的项目想法]。这份提案是给[提案是给谁看的以及你需要对方做出什么决定]看的。以下是我实际能动用的资源:团队规模[规模],大致时间表[时间范围],预算大约[范围,或"尚未确定"]。写一份提案草案,包含问题陈述、建议方案、范围(包括明确排除在范围之外的内容)、大致时间表和成功指标。标出任何因为我没给够细节而你不得不猜测的地方。
对预算这类你还不清楚的事情保持坦诚,比编造一个数字去填补空白,能得到更有用的草案。
把杂乱的构思变成问题陈述
这是我关于一个想解决的问题的粗略、没有整理的笔记:[粘贴你的笔记]。把这些变成一段简洁的问题陈述,两到三句话,解释为什么这件事重要、谁会受影响,先不要描述解决方案。我希望在提出解决方案之前,把问题先清楚地框定出来。
让问题陈述与解决方案分开;直接跳到解决方案的提案,常常会失去那些还没被说服"确实存在一个值得解决的问题"的读者。
界定范围,包括哪些排除在外
这是我提议的项目:[描述它]。写一个范围部分,清楚说明这个项目将包括什么、不包括什么,至少列出三项明确排除在范围之外的具体内容。我想避免提案被理解得比我的本意更宽泛。
一份明确列出范围之外内容的清单,往往是提案中最能防止日后混乱的部分。
在发送前对提案进行压力测试
把这份提案草案当作决定是否批准的利益相关者来读:[粘贴你的草案]。在批准之前你会有什么问题?时间表、范围或成功指标在哪里显得不现实或不清楚?请具体说明缺了什么,不只是哪里错了。
这个方法在发送提案前使用效果最好,作为最后一道检查,而不是早期草稿阶段的步骤。
为不同受众调整提案的语气
这是我为自己团队写的一份项目提案:[粘贴你的草案]。把它改写给需要批准预算的高管受众:以商业论证和成本开头,把技术细节保持简短,把实施细节移到最后的附录部分。
同一个项目常常需要两个不同版本,取决于谁在读以及这个人需要做出什么决定。
结构
提案提示词需要的五个部分
这五个要素把一个模糊的想法变成利益相关者真正能据此行动的东西。
在解决方案之前,先有问题陈述
在描述解决方案之前,先陈述问题以及它为什么重要。一个还没被说服存在问题的读者,不会认真对待为此提出的解决方案。
范围,包括明确排除的内容
说明项目将做什么,同样重要的是,不会做什么。没有明确范围的提案,往往会在每个人心里膨胀成他们自己以为的意思。
真实的约束条件,而非编造的
把你真实的团队规模、大致时间表和预算范围告诉Claude,即使部分内容仍不确定。基于编造数字写出的方案,一旦真实数字出现就必须重做。
明确说明的成功指标
说明你将如何判断项目是否成功。没有成功指标的提案更难有把握地获批,即便获批了,也更难在六个月后去追踪核实。
了解你的读者
同一个项目,面对不同受众需要不同的提案
一份写给自己团队用于规划的提案,和一份写来争取高管批准预算的提案,即便描述的是同一个项目,完成的也是不同的任务。团队版本可以深入实施细节,因为读者已经关心这些内容。高管版本需要以商业论证和成本开头,因为那才是那位读者真正需要做出的决定,不必要的细节只会拖延你所要求的那个决定。
明确告诉Claude谁在读,以及你需要对方做出什么决定。"这是给我团队用来规划下个季度的"和"这需要一位不了解技术细节的副总裁批准预算",即便是同一个项目,也会把Claude引向两份不同的草案,提前指明受众能让你避免写出一个版本,事后才发现它不适合真正的读者。
如果你确实需要两个版本,通常先写好给团队用的详细版本,再让Claude为高管受众调整它,比从零开始分别写两份更快。底层事实不会改变,改变的只是强调什么、什么内容挪到附录里。
常见错误
什么会让提案卡住而不是获得批准
这些空白会把一个合理的想法变成一份被晾在一边、没有回音的提案。
范围比你的真实意图更宽泛
如果你不说明哪些内容在范围之外,读者会用自己的假设去填补空白,这些假设往往比你本想提议的范围更大。明确说明这个项目不会包含什么。
没有为读者说明要做的决定
一份没有说明你到底在请求什么的提案,是批准、预算、人员,还是开始的许可,会让读者不清楚你需要他给出什么回应。
用编造的数字代替真实约束条件
因为你没有提供而由Claude猜出的时间表或预算,听起来会很确定,但其实是虚构的,而知道真实数字的人会发现提案和现实不符。
没有办法事后判断是否成功
没有成功指标的提案很难让人有把握地批准,就算获批了,也没有一种双方认可的方式,能在六个月后核实项目是否真的交付了成果。
利用你已有的资料
粘贴你的背景材料,而不是从零开始
如果你有一份类似项目的旧提案、关于这个问题的粗略会议笔记,或者哪怕只是一份写了一半的大纲,把它粘贴进去,而不是凭记忆重新描述项目。Claude整理和打磨你已有的材料,会比它凭一句话的描述去编造你这个真实项目的具体背景、历史和约束条件可靠得多。
这一点对问题陈述尤其重要。如果这个问题是在某次会议中、某个客户的投诉中,或者之前一次类似的失败尝试中冒出来的,那段背景就应该写进提示词里。仅靠你目前对问题的概括总结写出的问题陈述,往往会丢掉那些让问题显得真实、值得解决的具体细节。
约束条件也是同理。如果你的组织已经有标准的提案模板、这类项目的典型预算范围,或者惯常的时间表惯例,就直接把它告诉Claude,而不是让它默认套用一个通用结构。一份已经符合你组织期望看到的这类文档格式的提案,比一份读起来像是别处模板的提案,会被更认真地对待。
值得保留一个持续更新的文件夹,收集你所在组织通过的提案(哪怕只是非正式通过的),并在可能的时候把一份成功的提案和你自己的草稿放在一起对照。Claude能识别出通常容易被通过的模式,比如特定的正式程度、偏好用短段落而不是长段落,或者习惯先讲风险缓解措施,然后把同样的模式应用到你当前的草稿上,而不是默认套用一个不符合你工作单位实际情况的通用结构。
发送之前
提案送到读者手上之前要检查什么
先读范围部分,问自己它是否准确描述了你真正打算做的事,不多也不少。这是日后最容易出问题的部分,如果它比你的真实意图更模糊或更宽泛,因为一旦项目启动,它就会成为所有人回头指认的那个基准点。
把每个数字都对照现实检查一遍:时间表、团队规模、预算。一份听起来很有把握、实际上基于猜测数字的计划,比一句诚实的"时间表尚未最终确定"更糟,因为前者一旦被人读到,就会被当作一种承诺来对待。
这里的结构能让你快速得到一份扎实的草案;但你的组织和读者在这份具体提案上真正需要什么,这个判断在发送之前仍然是你的责任。
常见问题
在Claude起草提案之前,最重要的是告诉它什么?
这份提案是给谁看的,以及你需要对方做出什么决定。一份供自己团队规划用的提案,和一份请高管批准预算的提案,即便是同一个项目,也需要不同的框架。
如果我还没有预算数字,应该给Claude一个数字吗?
不应该。说明预算尚未确定,而不是让Claude猜一个数字。一个听起来很有把握、实际编造的数字,一旦被知道真实数字的人看到,就会被当作一种承诺。
为什么提案需要一个明确说明范围之外内容的部分?
如果没有,读者会用自己对项目包含内容的假设去填补空白,这些假设往往比你的真实意图更宽泛。明确说明排除的内容可以防止这种偏离。
我该如何写一份同时适用于我的团队和一位高管的提案?
先为你的团队写详细版本,然后让Claude为高管读者调整它:以商业论证和成本开头,精简技术细节,把实施相关的具体内容移到附录。
我可以使用以前提案或会议的笔记,而不是从零开始吗?
可以,而且你应该这样做。粘贴你已有的背景材料。Claude整理和打磨真实材料的能力,远胜过它凭空编造你项目具体背景的能力。
为什么提案需要成功指标?
没有明确说明衡量成功的方式,提案就更难让人有把握地批准,而且之后也没有一种双方认可的方式,能核实项目是否真正实现了承诺的内容。
发送给利益相关者之前,我应该如何检查草案?
让Claude像利益相关者那样阅读,列出他们在批准之前会有的问题。然后在发送前,单独把草案中的每个数字对照你的真实约束条件检查一遍。
如果我的组织已经有标准的提案模板怎么办?
直接把它告诉Claude,而不是让草案默认套用一个通用结构。一份已经符合你组织预期格式的提案,会比不符合的提案被更认真地对待。