做项目排期这件事，我自己踩过的坑实在不少。有一回带一个内容运营项目，前期觉得任务挺清楚，真到排期表上就乱了套。谁先做、谁等谁、哪块能并行、哪块卡脖子，全靠拍脑袋。后来团队人一多，沟通成本上来，排期表变成摆设，每天站会都在对同一件事。那种感觉挺无力的。
我慢慢意识到，排期拆分不是简单地把任务列出来。它更像一次翻译，把模糊的项目目标翻译成可执行的任务网络。翻译得好，团队跑得顺；翻译得糙，后面全是补丁。这一章我想聊聊排期拆分到底难在哪，提示词能帮上什么忙，以及它管不到的地方。
1.1 项目排期拆分的核心目标与常见难点
排期拆分的核心目标说白了就一句话：让每个人知道什么时候该做什么，以及做完之后交给谁。听起来简单，做起来复杂。我见过太多排期表只写了任务名称和截止日期，没写依赖关系，没写交付标准，结果到了截止那天才发现上游没交付，下游干等着。好的排期拆分要同时解决三件事——任务边界清晰、依赖关系明确、时间估算有依据。
难点往往出在三个地方。一个是任务粒度失控，拆得太粗，一个任务拖两周，中间发生什么没人知道；拆得太细，任务条目上百条，维护成本比执行成本还高。另一个是依赖关系被忽略，尤其跨团队协作的项目，A团队以为B团队会先给数据，B团队以为A团队会先给方案，两边都在等。还有一个是工期估算靠感觉，没有历史数据支撑，也没有缓冲机制，一旦某个环节延误，整个排期像多米诺骨牌一样倒下去。
我自己最头疼的是第一版排期表出来之后的调整。项目刚启动时信息不全，排期表注定要改，可每改一次，团队就要重新对齐一次，士气也跟着波动。后来我想明白了，排期拆分本来就不是一次性动作，它是一个持续迭代的过程。接受这一点之后，我反而没那么焦虑了。
1.2 提示词在排期拆分中的角色、价值与边界
第一次用AI帮我拆排期，其实是抱着试试看的心态。我把项目背景和交付物丢给它，让它给我列个任务清单。结果出来的时候我有点意外，它把一些我没想到的关联任务也列进去了，比如「需求评审后的文档归档」这种容易被忽略的收尾动作。提示词的价值就在这里——它像一个不知疲倦的助手，帮你把脑子里那些默认忽略的环节翻出来。
提示词在排期拆分中扮演的角色，我理解是「结构化思维的外包」。你给它清晰的输入，它帮你把任务分层、标注依赖、估算工期。它不会替你决策，但它能把你从空白页面的焦虑中拉出来。尤其是项目刚开始、信息还很散的时候，让AI先出一版草稿，你再在上面改，比从零开始写要快得多。
边界也得说清楚。AI不知道你团队里谁最近在休假，不知道某个供应商上个月刚出过交付问题，也不知道老板对某个里程碑有特殊执念。这些隐性约束只有你自己清楚。提示词能处理的是显性信息，那些藏在组织肌理里的东西，得靠人来补。我一般会把AI的输出当作起点，而不是终点。
1.3 项目排期拆分提示词的关键构成要素
一个能用的排期拆分提示词，我总结下来至少得包含四块内容。项目背景和目标得说清楚，不然AI不知道你要干什么，拆出来的任务容易跑偏。范围边界也要给，哪些做、哪些不做、哪些是二期再说，这些信息直接影响任务清单的长度和深度。交付物清单是另一个关键，每个交付物对应一组任务，这是拆解的锚点。
约束条件这块很多人会漏掉。团队规模、可用人力、关键资源、硬性截止日期、优先级排序，这些信息给得越具体，AI排出来的工期越靠谱。我一般还会加上输出格式的要求，比如用表格、包含哪些字段、任务层级怎么表示。格式约束不是吹毛求疵，它直接决定你拿到结果之后能不能直接用。
还有一点容易被忽视——验收标准。每个任务或者每个里程碑，做到什么程度算完成，这个信息如果不在提示词里体现，AI给出的任务描述会很泛。我习惯在提示词里加一句「每个任务需附带可验证的完成标准」，出来的结果会实在很多。
1.4 相关搜索需求解析：提示词模板、AI任务拆解与可执行排期
我观察过身边同事搜这类内容时的关键词，翻来覆去就是那么几个：提示词模板、AI任务拆解、可执行排期。搜模板的人多半是想找个现成框架，填进去就能用。搜任务拆解的人更关注AI怎么把一个大目标拆成小任务。搜可执行排期的人，往往已经试过AI生成的结果，发现不太落地，想找方法优化。
这三个需求其实指向同一个痛点——大家想要的不是理论，是能直接上手的东西。模板要能复制粘贴，拆解方法要步骤清晰，排期结果要能直接贴进项目管理工具。我写这一章的时候一直在提醒自己，别讲太多虚的，多给具体例子和字段说明。
可执行排期这个需求特别值得展开说。AI生成的排期表经常有两个毛病，一个是任务之间没有依赖标注，另一个是工期估算过于平均。前者导致你没法判断关键路径，后者让你误以为一切顺利。要解决这两个问题，提示词里就得明确要求AI标注前后置关系，并且给出工期估算的依据或者区间。这些细节在后面章节会展开讲，这里先提一嘴，让你有个印象。
说实话，我一开始用AI做排期拆分的时候，拿到的结果看着挺像回事，真拿去用就发现处处不对劲。任务列了一堆，但该细的地方粗，该粗的地方细；工期全标个三天五天，问它依据是什么，它也说不出来。踩过几次坑之后我慢慢摸出了一些门道，这一章就把这些设计原则摊开说说。
2.1 目标对齐：范围、里程碑、交付物与验收标准
我吃过最大的亏就是没跟AI把目标说透。有一回做一个内部工具开发项目，我扔给AI一句话“帮我拆一下开发排期”，它倒好，给我列了一堆通用任务——需求分析、UI设计、后端开发、测试上线，跟网上的项目模板没啥区别。问题出在我自己身上，我没告诉它这个工具是给哪个部门用的、要解决什么具体问题、什么叫做完了。后来我补了一段背景说明，把范围边界画清楚——只做核心功能，报表模块二期再说——再让它重新拆，出来的任务清单明显靠谱多了。
里程碑这个东西有点像项目的骨架。我喜欢在提示词里把关键节点先锚定下来，比如“第三周完成原型评审”“第五周交付可测试版本”，让AI围绕这些节点往回倒推任务。这样拆出来的排期有节奏感，不会是一盘散沙。交付物清单也得给，每个交付物对应什么任务组，这个映射关系在提示词里写明白，AI就知道该往哪个方向使劲。
验收标准是我后来才加进去的。以前AI给出的任务描述特别泛，比如“完成用户登录功能”，到底算不算完成，谁也说不准。现在我习惯在提示词里加一句“每个任务需要附带可验证的完成条件”，出来的描述就实诚多了，像“用户可用手机号加验证码登录，错误提示明确，连续三次失败触发锁定”——这种东西拿到开发面前，他能直接干活。
2.2 任务粒度控制：WBS、依赖关系与工期估算
任务粒度这件事，我自己来回摇摆过好几次。早期拆得太粗，一个任务叫“完成前端开发”，两个礼拜过去了，问进度怎么样，对方说还在做。后来学乖了，拆细一点，结果又掉进另一个坑——清单上一百二十个任务，光维护更新就耗掉半条命。我现在找的平衡点是：单个任务原则上不超过三天工时，如果一个任务看起来要一周以上，那就得再往下切一层；同时任务条目总数控制在三十到五十条之间，太多了说明你管得太细，太少了说明漏了东西。
WBS分层我一般让AI按三到四层来拆，项目目标算第一层，阶段或模块算第二层，具体工作包算第三层，如果碰到复杂模块再拆出第四层操作步骤。依赖关系是很多人容易忽略的，但我跟AI反复强调这块。我在提示词里会明确说“请标注每个任务的前置任务编号，没有依赖的写无”，这样出来的表格能直接看出关键路径在哪，哪些任务可以并行跑。
工期估算我吃过亏。早前AI给我的估算清一色是三天五天，看着特别整齐，实际根本对不上。后来我换了个问法，让它“按乐观、最可能、悲观三种场景分别给出工期区间”，再要求“标注估算依据，比如参考历史项目或行业常见工作量”，结果就真实多了。有些任务它自己也会标“估算不确定性高，建议增加缓冲”，这种标注我特别看重，因为它在主动告诉我哪里需要人再拍个板。
2.3 约束条件表达：资源、优先级、风险与缓冲
资源约束这块我得坦白说，AI知道的信息永远比你以为的少。你团队里那个前端最近在忙另一个项目，某个后端对某某模块特别熟但下周要休假，这些事AI一概不知。我的做法是把能想到的全写进提示词，团队几个人、各自能投入多少比例、谁的技能匹配哪类任务、有没有外部供应商卡着时间点，写得越细，AI排出来的东西越贴地。
优先级排序也得给。我一般会分三级——必须按时交付的、应该完成的、可以灵活调整的，让AI在排期里打上标记。这个动作不大，但效果挺明显，项目中期一旦资源紧张，你就能快速判断砍哪些任务不伤筋动骨。风险这块我习惯让AI单独列个清单，识别出潜在风险点，然后追问一句“针对每个风险，建议预留多少缓冲时间”，它给的缓冲建议虽然不一定全对，但至少给你提了个醒。
缓冲机制我是被现实教会的。有一回排期太理想化，中间某个接口联调拖了四天，后面全线往后推。现在我一般在总工期里留出百分之十五到二十的缓冲，明确标注为“管理储备”，不分配给具体任务，谁那边出问题了就从这里补。跟AI提要求的时候直接说“请在排期末尾附加缓冲时间，并说明缓冲总量的分配原则”，出来的结果会更像一个有经验的人做的排期，而不是机器算出来的。
2.4 输出格式约束：表格字段、层级结构与可追踪性
格式这件事看着小，实际影响巨大。我早期让AI输出排期，它给我一段一段的文字描述，我看了半天还得自己手动往表格里搬。后来我学乖了，直接在提示词里把字段列清楚：任务编号、任务名称、所属阶段、负责人角色、工期估算、前置任务、交付物、优先级、状态。九列一张表，拿到就能贴进飞书多维表格或者Excel里用。
层级结构我也要求明确。任务编号用01、01.01、01.01.01这种格式，一眼就能看出从属关系。状态字段留空，方便后续跟催进度。我还会让AI加一列“备注”，把估算依据或者风险提示往里塞。这种格式约束不是吹毛求疵——你想想，如果AI每次给的格式都不一样，你每次拿到结果都得重新整理一遍，本来省下来的时间又搭进去了。
可追踪性是最近我开始强调的。每个任务后面跟上它对应的交付物编号，交付物再跟里程碑关联，形成一条从任务到里程碑的追溯链。有人可能觉得这个太麻烦，但项目中期甲方问你“这个功能到底影响哪个节点”，你能三秒钟翻出来答案，那种感觉挺爽的。跟AI沟通的时候直接说“任务、交付物、里程碑要能互相追溯，编号体系保持一致”，它就能把结构搭出来。
2.5 多轮追问与结果校验机制
只靠一轮提示词拿到满意结果，这种事我碰到的不多。更常见的情况是第一轮出来个框架，我看看哪里不对劲，追问几句，第二轮好一些，第三轮才基本能用。我现在的习惯是三轮节奏——第一轮要全局，看任务框架和阶段划分对不对；第二轮抠细节，补上遗漏的任务，调整不合理的工期；第三轮做校验，让它自己检查前后矛盾的地方。
追问的措辞有讲究。比如我看到某个模块的任务只有两条，觉得太粗了，我不会说“帮我细化一下”，太模糊。我一般说“模块X的任务拆分粒度和其他模块不一致，请按同样标准补充到至少四条子任务，每条附上工期估算”。这种指令指向明确，AI执行起来不容易跑偏。再比如工期明显不对，我会说“任务07的工期估算为两天，但它包含接口开发和联调，请重新评估并说明依据”。
自我校验这一步是我最近才加进流程的。我会在提示词末尾补一段：“在输出排期后，请自行检查以下三项——是否有任务缺少前置依赖标注、是否有任务工期明显偏离同类任务均值、是否有交付物未关联到任何任务。如有问题请标注并修正。”这个动作有点像让AI自己当一回审稿人，虽然不能百分百可靠，但确实抓出过几次遗漏。校验完我还会挑两三个关键任务，人工再核一遍，毕竟最终责任还是在我这儿。
前两章聊了思路和原则，这一章上点硬货。我把自己反复用、反复改的那几套提示词模板摊开来，一套一套说清楚每个字段是干嘛的、为什么这么设计、哪个字段容易写歪。你拿到可以直接改改就用，但建议先看完字段说明，不然改错了地方反而更麻烦。
3.1 基础模板：角色、背景、目标、输入、步骤与输出
我把基础模板理解成一个骨架，所有具体的排期拆解提示词都是从这个骨架长出来的。它包含六块内容：角色设定、背景交代、目标描述、输入材料、拆解步骤、输出格式。每一块都有它存在的理由，缺一块AI给你的东西就差点意思。
角色这块很多人写得敷衍，就一句“你是一个项目经理”，我觉得浪费了。我一般会写得更具体一些，比如“你是一位有八年经验的研发项目经理，熟悉敏捷开发和瀑布模型的排期方法，擅长把模糊需求转化成可执行的任务清单”。角色写得越具体，AI在后续回答里调用的知识框架越偏向项目管理的实操方向，而不是泛泛而谈。
背景和目标经常被我合并成一段来写，但心里分得很清楚。背景是“我们为什么要做这个项目、目前什么情况”，目标是“这次拆解要达成什么”。举个例子，背景我写“团队六个人，三个后端两个前端一个测试，之前用Excel手工排期，经常漏任务”，目标写“为即将启动的会员系统重构项目生成一份可执行的四周排期表”。两句话，AI就明白约束条件和产出物了。
输入部分我踩过一个坑，就是什么都往里塞。早期我把需求文档全文三四千字直接贴进去，AI回答倒是挺长，但抓不住重点。现在我一般做一层预处理，输入只放三样东西：范围说明、关键交付物清单、已知约束。范围说明控制在两百字以内，交付物清单用列表形式，约束条件一行一条。干净利落。
步骤和输出我习惯放在模板末尾，而且写得像操作指令。步骤一般分四到五步，比如“第一步识别项目阶段，第二步按阶段拆解任务，第三步标注依赖关系和工期，第四步检查任务粒度和覆盖面，第五步按指定格式输出”。输出格式我会把完整的表头和字段说明都写进去，不给AI自由发挥的空间。这套基础模板看起来笨重，用熟了之后你会发现它省下来的返工时间远超写模板花的几分钟。
3.2 排期表模板：任务编号、负责人、工期、依赖与里程碑
排期表模板是我用得最频繁的一个，几乎每个项目启动前都要跑一遍。核心字段我固定在十列：任务编号、任务名称、所属阶段、任务描述、负责人角色、工期（天）、前置任务、交付物、优先级、里程碑标记。这十列是我试了十几版之后定下来的，多一列嫌累赘，少一列总觉得缺点什么。
任务编号的规则我在模板里写死了，采用两位一级、两位二级的格式，比如01、01.01、01.01.03。有人喜欢用纯数字排序，我试过，一旦中间插入新任务就得全体重编号，烦得要命。分层编号的好处是插入任务不影响已有编号，比如01.01和01.02之间要加一个，编成01.01.01就行了，别的任务不用动。
负责人角色这个字段我特意写成“角色”而不是“人名”。原因是排期阶段具体谁干往往还没定，写角色让AI能按职能分配任务，等排期确认后再把人名填进去。角色一般分这么几类：产品经理、UI设计师、前端开发、后端开发、测试工程师、运维。工期字段我要求AI给的是“工作日”不是“自然日”，这个小细节很多人不注意，到手才发现差了周末两天。
依赖和里程碑是排期表模板里我最看重的两个字段。前置任务我要求写任务编号，多个依赖用逗号隔开，没有依赖的明确写“无”。里程碑标记就两种值——是或空，凡是标了“是”的任务，它对应的交付物会直接挂到项目里程碑上。我在模板末尾加了一句“请确保关键路径上的任务在里程碑栏有标记”，这样AI会自动去梳理哪些任务是卡脖子环节。
实际用的时候我会根据项目大小微调字段。小项目把任务描述列去掉，省地方；大项目增加一列“跨团队依赖说明”，把外部供应商或兄弟团队的协作事项写进去。模板是死的，人是活的，别被字段绑住手脚。
3.3 WBS任务拆解模板：从项目目标到工作包
WBS模板跟排期表模板是配套使用的，前者负责拆散，后者负责排布。我在WBS模板里明确要求AI按三到四层来展开，并且每一层都给了命名规则。第一层是项目名称本身，第二层是阶段或模块，第三层是工作包，第四层是具体活动步骤。举个例子，第一层“会员系统重构项目”，第二层“用户模块”，第三层“注册登录流程改造”，第四层“手机号验证码登录接口开发”。
模板里有个要求我特意加粗写了：“每个工作包必须有一个可交付的结果，用动词加名词的形式描述。”这句话是我从一次失败中总结出来的。之前AI给我拆的工作包叫“登录功能优化”，这算什么？优化到什么程度算完？后来改成“完成手机号加验证码登录接口开发并通过联调测试”，看着就踏实了。
我在WBS模板里还埋了一个自查指令，要求AI在完成拆解后自己检查两件事：每个第三层工作包下面是不是至少有两条第四层活动，以及第四层活动有没有超过五条的。低于两条说明拆得不够细，超过五条说明这个工作包还可以再往上提一层。这个自查机制是我在一次项目复盘时想到的，当时发现某个模块的任务数量异常膨胀，追查下去是拆解层级没控制好，同一个模块被拆了两遍。
WBS模板的输入部分我喜欢让AI先做一步“范围确认”。我在提示词里写“请先复述你理解的项目范围和边界，等我确认后再开始拆解”。这个动作花不了几秒钟，但能避免AI在错误理解上狂奔几百字。有次我漏了这个确认步骤，AI把不在范围内的报表模块也拆进去了，整份WBS作废重来，那叫一个郁闷。
3.4 风险与缓冲模板：识别不确定性与排期余量
风险与缓冲模板单独拎出来说，因为它跟排期表模板的使用节奏不太一样。排期表是项目启动时用一次，风险模板我在项目全周期里会反复调用。模板结构分两块：风险识别和缓冲分配。风险识别部分我让AI从五个维度扫一遍——技术风险、资源风险、依赖风险、需求变更风险、外部环境风险。每个维度要求列出至少一条潜在风险，并标注发生概率和影响程度。
概率和影响我用高中低三档来标，不让AI搞什么百分比，太假了。标完之后我追问一句“针对高概率高影响的风险，请给出具体的应对建议和触发条件”。触发条件这个概念是我从风险管理书里学来的，意思是“出现什么信号说明这个风险正在变成现实”。比如“核心开发人员连续请假超过两天”就是一个触发条件，项目经理想不注意到都难。
缓冲分配部分我在模板里写得很直接：“请在排期表末尾增加管理储备时间，总量为总工期的百分之十五到二十，并说明缓冲的使用规则。”AI一般会给出一个总天数，然后建议“优先用于关键路径上的高风险任务”。这个建议我基本采纳，但会补一条自己的规矩——缓冲时间的使用需要我签字确认，不分配给任何人自行支配。这个规矩吃过亏才定下来的，之前有个项目缓冲被团队成员当成了理所当然的延期额度，半个月的余量十天就用光了。
模板里还有个我特别喜欢的字段叫“缓冲触发条件”，要求AI为每个高风险任务写出“什么情况下可以动用缓冲”。比如某个接口联调任务，触发条件写“对方系统接口文档延迟提供超过三天”，这种条件写出来之后，团队里谁都知道什么时候该来找我申请缓冲，不用每次都扯皮。
3.5 模板复用与参数化：项目类型、团队规模与交付周期
这几套模板我用了快一年，最大的感受是它们得跟着项目变。我现在的做法是把模板拆成固定部分和可变部分，固定部分不动，可变部分用参数化的方式留出接口。具体做法是模板末尾加一个“参数区”，把项目类型、团队规模、交付周期、技术栈复杂度这几个变量单独列出来，用的时候只改变量，主体提示词不用动。
项目类型这个参数影响挺大的。我做过的项目大概分三类：全新产品开发、现有系统改造、短期活动页面。三类项目在WBS模板里的拆解逻辑完全不同。全新产品要拆调研和设计，系统改造要拆兼容性评估和数据迁移，活动页面要拆营销素材对接和紧急上线流程。我在参数区写“项目类型：全新产品开发”，AI就会自动调整拆解策略，不用我每次手动改模板正文。
团队规模参数主要影响任务分配和负责人字段的写法。五六个人的小团队，负责人角色可以合并，比如“前端开发”统管所有前端任务。二十人以上的团队，角色得拆细，“前端架构师”“前端开发工程师”“初级前端”得分着写，不然排期表拿到团队里没法用。我在模板里留了一句“若团队人数超过十五人，请按技能等级细分开发角色”，AI会自觉执行。
交付周期参数决定工期估算的松紧程度。四周的短周期项目，我要求AI把任务粒度拆到一天以内，估算按小时给。三个月的长周期项目，任务粒度可以放到三天，估算按天给。这个参数特别实用，以前同一个模板跑不同项目，出来的工期估算要么全挤在一起要么全散着，加上周期参数之后整齐多了。
模板复用还有个隐性好处，就是版本管理方便。我每个模板都留了版本号，v1.0、v1.1、v2.0这样往下排。每次修改模板，我会在文件头写一行变更说明，比如“v1.2：增加缓冲触发条件字段，调整任务编号规则”。这种习惯看着有点正式，真到出问题要回溯的时候特别管用。有回某个项目的排期表格式明显不对，一查版本号发现我误用了半年前的旧模板，五分钟定位问题，不然得从头排查。
参数化这块我还留了一个自定义扩展位，名字叫“特殊约束”。这个字段平时空着，碰到怪项目就往里写。比如之前做过一个跟政府部门对接的项目，验收流程特别长，我在特殊约束里写“验收环节预留十个工作日，排期表需体现政府方审核节点”，AI就乖乖把审核环节拆成了三个子任务。这种一次性需求不适合写进模板正文，用扩展位接住最合适。
这套模板体系我已经迭代到第三轮了，每轮都是被项目逼出来的。用完记得回来改，好用的模板都是改出来的，不是一开始就设计完美的。
上一章把模板骨架搭好了，这一章聊的是怎么用这些模板把一句模糊的项目需求变成一份能直接发到群里的任务清单。我带的项目里，从需求到任务清单这个环节最容易出岔子，要么是AI拆出来的任务没人认领，要么是清单列完了发现漏了半个模块。这章就把我反复调试过的那套写法拆开讲。
4.1 明确项目背景与交付边界
我写任务拆解提示词的时候，背景部分从来不敢省。有人觉得背景写多了AI记不住，我的经验恰恰相反，背景写得越具体，AI拆出来的任务越贴合实际。我一般会把三件事塞进背景里：项目要解决什么问题、目前团队什么状态、之前有没有踩过类似的坑。
拿上个月做的一个社区团购小程序改造来说，我的背景是这么写的：“现有小程序日活三千左右，下单流程要经过五个页面，用户反馈最多的是支付环节卡顿。团队四个开发一个测试，之前做过一次改版，因为没理清第三方支付接口的兼容问题导致上线延期一周。”这段话里其实藏了三个约束：团队小、支付是重点、有过延期教训。AI读到这些会自动在拆解时把支付相关任务拆得更细，也会在排期上留出联调时间。你要是不给这些信息，AI就按标准流程平铺一遍，出来的清单看着挺全，细看全是通用货。
交付边界这个事我得单独拎出来说。边界不是范围，边界是“什么不做”。我每次写提示词都会加一行“以下内容不在此次拆解范围内”，然后把容易混淆的模块列进去。比如刚才那个小程序改造，我明确写了“本次不涉及商品管理后台、不涉及会员积分体系、不涉及配送路线规划”。这三个模块跟下单流程挨得很近，AI很容易顺手就给拆进去。你不划这条线，它拆完了你还得一条条删，浪费时间不说，有时候删漏了发到团队里更尴尬。
背景和边界写完之后我会让AI做一件事——用自己的话复述一遍它理解的项目目标。这个动作我固定在提示词的第二段里，原话是“请先用两句话概括你理解的项目目标和边界，我确认后再开始拆解”。这招是从写WBS模板那会儿延续过来的，特别管用。有一回我写边界的时候手滑多写了一个模块，AI复述的时候把它列进去了，我一眼就瞅出来不对劲，赶紧改。要是直接让它拆，拆到一半才发现边界写错了，前面那些功夫全白费。
4.2 用分层拆解指令引导AI生成WBS
分层拆解这个指令我写得比较“啰嗦”，因为不啰嗦不行。AI默认的拆解习惯是平铺，一个项目下面直接甩出二三十条任务，看着热闹，拿过来没法排期。我在提示词里会把层数、每层的命名规则、每层之间的关系全写清楚。
常用的写法是这么一段：“请按四层结构拆解：第一层是项目名称，第二层是阶段或模块，第三层是工作包，第四层是具体活动。每个工作包用动词加名词描述，比如‘完成支付接口联调’而不是‘支付接口’。每个工作包下面至少有两个活动，最多不超过五个活动。”
这段话里“动词加名词”这个要求是我踩坑踩出来的。之前AI给我拆过一个工作包叫“订单模块优化”，我拿着这条去问开发这周能完成吗，开发反问我“优化到什么程度算完”。后来我改成“将订单列表加载时间从三秒降到一点五秒以内”，立马就清楚了。你在提示词里把描述规范定死，AI就不会给你模棱两可的东西。
还有个技巧是让AI先拆阶段再拆任务。我在提示词里分两步走：“第一步，识别本项目包含哪些阶段或模块，列出来等我确认；第二步，针对每个阶段分别拆解工作包和活动。”这种两步走的写法比一步到位稳得多。有次做ERP系统迁移，AI第一步列了六个阶段，我一看少了数据清洗阶段，补上之后第二步拆出来的任务就完整了。要是让它一口气拆完，数据清洗相关的任务很可能散落在各个模块里，找都找不出来。
分层拆解的时候我还会在提示词末尾加一句“拆解完成后请说明每个阶段的任务数量分布”。这个要求看着不起眼，其实是个预警机制。正常项目各阶段的任务数量应该大致均衡，某个阶段突然冒出四十条任务，要么是这个阶段确实复杂，要么是拆解粒度失控了。上个月一个项目，测试阶段拆了五十三条任务，我一看就知道AI把测试用例的每个步骤都当成独立任务了，赶紧让它合并。
4.3 要求AI标注依赖、优先级、工时与负责人角色
任务清单光有任务名没用，得带上依赖、优先级、工时和负责人角色这四样东西才能用。我在提示词里对这四个字段的要求写得很具体，每一条都有明确的格式规范，不给AI自由发挥的余地。
依赖关系我要求写成“前置任务编号”的格式，并且加了一条规则：“如果某个任务依赖外部团队交付，请在依赖字段中注明‘外部-某某团队’”。这条规则是跟兄弟团队协作时逼出来的。之前做物流系统对接，AI只标了内部任务依赖，没提对方物流公司提供接口文档这个前置条件，排期表看着挺顺，实际执行时卡在等文档上等了十天。现在我会在提示词里特别强调外部依赖的标注方式，让AI养成习惯。
优先级我用的是三档制——P0、P1、P2，对应必须完成、应该完成、可以延后。提示词里会写清楚判定标准：“P0指阻塞其他任务或影响里程碑的任务，P1指关键路径上的任务，P2指非关键路径的常规任务。”不给标准的话，AI经常把简单任务标成P0，难啃的骨头标成P2，排序完全反了。
工时估算我要求AI按“人天”给，并且加了一句约束：“单个任务的工时估算不超过五天，超过五天的任务请继续拆分。”这条约束在实战里特别有用。AI有个毛病，碰到复杂任务不愿意继续拆，直接给个“二十人天”了事。你拿这种数字去排期根本没法安排人力，没人能连着二十天只干一件事。加上这条约束之后，AI会老老实实把大任务拆成小任务，每个控制在五天以内。
负责人角色这个字段我写得最细。提示词里会列出角色清单，比如“产品经理、交互设计师、视觉设计师、前端开发、后端开发、测试工程师、运维工程师”，并且要求AI“根据任务性质分配最匹配的角色，不要把所有开发任务都分给‘开发工程师’”。刚开始我没写这么细，AI图省事把所有任务都标成“开发”或“测试”，拿到团队里分配的时候还得我自己一条条改。现在它会区分“前端开发-支付模块”和“后端开发-订单模块”，省了我不少二次加工的时间。
4.4 设计校验追问：遗漏任务、重复任务与工期合理性
AI生成的清单头一遍看往往挺顺眼，仔细看问题不少。我的做法是生成之后立刻追加一段校验追问，让AI自己给自己挑毛病。这段追问我固定成三个方向：遗漏检查、重复检查、工期合理性检查。
遗漏检查的追问话术是这样的：“请检查清单中是否遗漏了以下类别的任务：环境搭建、数据迁移、安全测试、上线部署、用户培训、文档编写。”这几个类别是项目里最容易漏的，尤其是环境搭建和文档编写。AI默认只关注功能开发，周边配套任务经常忘。我有一次上线前一天才发现AI根本没拆部署任务，运维那边完全没准备，临时拉了两个人搞到半夜。后来我把这几类任务写进校验清单，每次让它逐项确认。
重复检查我用的问法是：“请找出清单中描述相似或存在包含关系的任务，说明是否应该合并。”AI有时候会犯一种错，同一个任务在不同层级各出现一次。比如第三层有个“支付接口开发”，第四层活动里又拆出一个“支付接口编码实现”，这俩明显是一回事。你让它自己查，它一般能揪出来。揪不出来的时候我会补一句“请特别检查跨阶段的重复任务”，因为同一个阶段内的重复好发现，跨阶段的重复容易漏。
工期合理性检查我盯得最紧。追问原话是“请检查每个任务的工期估算是否合理，特别关注工时少于半天或超过三天的任务，给出调整建议”。工时太短的任务往往可以合并，工时太长的任务需要继续拆。还有一种情况是同类任务的工期差异过大，比如两个相似的前端页面开发，一个估了一天一个估了四天，这明显有问题。我让AI自己解释差异原因，解释不通的就让它重新估。
这套校验追问跑完一遍，清单的质量能提升一大截。我现在的习惯是每份任务清单至少跑两轮校验，第一轮让它自检，第二轮我拿着自检结果挑几条问它“这条你确定没漏吗”。有时候它能补出一些边角任务，有时候它会嘴硬说没漏，那我就自己补。跟AI较劲的过程其实也是我自己查漏补缺的过程，挺有意思的。
4.5 将任务清单转化为甘特图、看板或迭代计划
任务清单确认之后还有一步——转成团队实际用的视图。不同团队用的工具不一样，有人用甘特图看整体节奏，有人用看板管日常推进，有人用迭代计划管两周节奏。我在提示词里会让AI把同一份清单用三种形式各输出一遍，团队要哪种拿哪种。
转甘特图的提示词我写得比较技巧化。直接让AI画甘特图它画不出来，我换了个说法：“请按周为单位输出排期视图，每行一个任务，列出开始周次、结束周次、持续周数和前置任务。”这个格式导出到Excel或者项目管理工具里可以直接生成甘特图。我还会加一句“请标出关键路径上的任务，用星号标注在任务名称前面”。关键路径这个概念AI理解得不错，标出来的结果我核对过几次，基本靠谱。
转看板的提示词我按状态来分列：“请将所有任务按‘待办、进行中、待测试、已完成’四列归类，归类依据是任务当前的进展状态。”刚拆完的清单所有任务都在待办列，这个没关系，看板的价值在于后续推进时挪动卡片。我让AI顺便给每个任务加一个“卡住风险”标记，把依赖外部团队或者技术难度高的任务标出来，团队站会的时候一眼能看到哪些卡片容易卡住。
转迭代计划我一般按两周一个迭代来切。提示词里写“请将任务按两周一个迭代进行分组，每个迭代标注迭代目标和主要交付物”。AI分组的时候会考虑任务依赖和优先级，把P0任务排在前面，把有前置依赖的任务往后放。有个细节我特意写进了提示词：“每个迭代的总工时不超过团队可用人天的百分之八十，留出百分之二十应对插队需求。”这个比例是我们团队磨合出来的，写进去之后AI排出来的迭代计划至少不会从一开始就爆掉。
三种视图各有各的用处。甘特图给管理层看整体节奏，看板给执行团队管日常推进，迭代计划给产品经理对齐交付预期。我一般会在提示词最后加一句“请说明三种视图之间的对应关系，确保同一任务在不同视图中的名称和编号一致”。这句话防的是AI在转换视图的时候把任务名改了，到时候对不上号还得手动核对，烦得很。
任务清单转视图这一步做完，整个从需求到任务清单的链路就算跑通了。我自己的习惯是存一份原始清单、一份甘特图、一份迭代计划，看板直接在工具里建。原始清单用来追溯，甘特图用来汇报，迭代计划用来管节奏，各司其职。下一章聊应用流程，我会拿一个完整项目从头到尾跑一遍，把前面这些零散的技巧串起来。
前四章把提示词的写法、模板和任务拆解技巧都过了一遍。这一章我拿一个真实项目从头到尾跑一遍，把之前那些零散的方法串起来。上个月接了个内部CRM系统升级的活，销售团队天天催，老板给了个死线，我硬着头皮带着三个开发一个测试往前推。项目不算大，但杂事多，正好拿来当案例。
5.1 输入准备：项目目标、范围、资源与约束
动手写提示词之前，我花了大概四十分钟把输入材料捋了一遍。这个环节我从来不省，材料准备得糙，后面AI给你的东西就是一团浆糊，来回返工的时间够你准备三遍。
我往提示词里塞的第一块内容是项目目标。CRM升级这个事说白了就三个诉求：销售线索分配要自动化、客户跟进记录要能实时同步到企业微信、报表模块要支持自定义维度。我把这三条写成了一段话，没有用任何专业术语，“让销售拿到线索后不用手动复制粘贴到表格里”这种大白话反而更管用。AI看到这种描述，拆出来的任务会更贴近实际使用场景，不会给你整一堆“架构优化”之类的虚活。
范围这块我写的是正反两面。正面是“本次升级覆盖线索池模块、客户档案模块、报表模块”，反面我加了句“本次不涉及合同审批流、不涉及财务管理模块、不涉及外部供应商系统对接”。反面这三条特别关键，销售那边一直以为升级会顺便把合同审批也改了，我提前把这锅甩出去，后面省得扯皮。资源约束我写得也直白：三个后端一个前端，测试只有一个人，每周实际可用工时按四天算，因为每周五花半天开例会。交付周期给了六周，硬邦邦的截止日期。技术栈写了“现有系统是PHP的，新模块用Java Spring Boot，数据库继续用MySQL”。这些约束一股脑全塞进提示词，AI排期的时候会自动把这些条件考虑进去，后面改起来省事。
5.2 首轮生成：任务分解与初步排期
第一轮提示词我复制了第三章那个基础模板，改巴改巴就用上了。角色设定写的是“你是一位有十年经验的技术项目经理”，背景部分直接把上一步整理的那些材料粘进去。目标那段我写了句“请将本次CRM升级拆解为可执行的任务清单，每个任务控制在五天以内，标注负责人角色、预计工时和前置依赖”。
AI第一轮吐出来的结果比我预想的好一些，但问题也不少。它拆了四十二个任务，分了五个阶段：需求确认、设计、开发、测试、上线。看着挺规整，我挨条扫了一遍，揪出几个毛病。需求确认阶段只有两条任务，“需求调研”和“需求文档编写”，每条都给了三天工时，这明显是拆不动了硬凑的。设计阶段把UI设计和数据库设计混在一个任务里，工时给了五天，实际上这俩活完全不是一个工种干的。开发阶段倒是一口气拆了二十二条，但有些任务描述太虚，比如有一条叫“线索池核心逻辑开发”，我拿着这条问后端这活怎么干，他反问我“核心逻辑指什么”。
最让我头疼的是它把测试和上线排得太乐观。测试阶段只给了六天，包括功能测试、回归测试和性能测试三块。上线阶段就两天，部署加验证。我一看这排期就知道按这个走肯定要翻车，我们测试就一个人，六天跑完所有功能测试加回归根本不可能。AI这么排是因为我没在提示词里明确说测试资源只有一个人，它默认有完整测试团队。这种默认值坑死人，你不说它不问，按标准配置给你排，拿到团队里一执行就崩。
5.3 二轮优化：依赖梳理、关键路径与资源平衡
拿着第一轮的结果我没急着重写提示词，而是先自己列了个修改清单。哪些任务要拆细，哪些工期要压，哪些依赖没标出来，列了大概十几条。然后我把这些意见揉成一段追问，追加给AI。
追问的话术是这样的：“请根据以下反馈调整任务清单：第一，需求确认阶段增加‘干系人访谈’和‘现有流程梳理’两条任务，每条工时压缩到一天半以内。第二，将UI设计和数据库设计拆分为独立任务，UI设计分给视觉设计师，数据库设计分给后端开发。第三，开发阶段所有任务描述改为‘动词加名词’格式，比如‘开发线索自动分配算法’而不是‘核心逻辑开发’。第四，测试阶段总工期从六天调整为十天，测试负责人角色改为‘测试工程师-单人’。第五，补充所有任务之间的前置依赖编号。”
AI接到这段反馈之后重新生成了一版，任务数量从四十二个变成了五十六个。乍一看变多了，其实质量高了不少。需求确认阶段从两条变成了五条，每条工时都控制在两天以内。开发阶段的任务描述全变成了“开发XX接口”“实现XX页面”这种能直接派活的格式。依赖关系也补上了，每条任务后面都跟着一个“前置任务编号”字段，我看了一眼，大部分标得合理。有一条任务是“开发企业微信消息推送接口”，前置依赖填的是“申请企业微信API权限”，这个依赖我们之前真忘了，差点栽跟头。
关键路径是我在二轮优化里特意让AI标的。提示词里加了句“请用星号标注关键路径上的任务，并说明关键路径的总工期”。AI标完之后我核对了一下，关键路径是从需求确认到线索池开发再到联调测试最后到上线，总工期三十四天。我们实际只有六周，按每周四天算也就二十四个工作日，明显兜不住。这说明有些任务可以并行走，AI虽然标了关键路径，但没主动安排并行。我补了句“请将非关键路径任务与关键路径任务并行安排，给出并行方案”，它才把报表模块的开发跟线索池开发排到了同一时间段。
资源平衡这块我也做了调整。AI最初把所有后端任务平均分给了三个开发，每个人大概都有七八条任务同时在进行。实际干活不可能这样，同一个人手头同时跟三件事就转不动了。我让AI按“每个人同一时间最多并行两个任务”的规则重新排了一版，排出来的结果清爽多了，每个开发的任务串成了一条线，前一个做完后一个接上，中间只有少量重叠。测试资源就一个人，我把所有需要测试介入的任务集中在最后两周的冲刺里，前面三周测试同事可以先帮忙写测试用例和搭环境，后面集中跑功能测试和回归。
5.4 三轮校验：风险缓冲、里程碑与验收口径
二轮排完已经挺像回事了，但我还是加了一轮校验。这轮校验我重点盯三件事：风险有没有标出来、里程碑划得合不合理、验收口径写没写清楚。
风险的追问我用的原话是：“请识别本排期中的三个最大风险，并给出每个风险的缓冲方案和预留天数。”AI给了三个风险：企业微信接口审批周期不确定、测试资源单人可能导致回归不充分、报表模块依赖业务方确认指标定义。这三个都挺准的，尤其是第一个，我们之前做项目就卡在企业微信接口审批上过一次，等了快两周。AI建议给接口审批留三天缓冲，测试回归留两天缓冲，指标定义确认留两天缓冲。总共七天的缓冲加进排期之后总工期变成了三十五个人天，但六周的时间窗口还能兜得住，因为有些任务可以并行压缩。
里程碑我让AI按周来划。提示词里写“请将项目划分为四个里程碑，每个里程碑对应一周的节点，标注里程碑名称和验收标准”。AI给的四个里程碑是：需求与设计定稿、线索池模块开发完成、全模块联调完成、上线部署完成。验收标准写得很具体，比如线索池开发完成的标准是“线索自动分配逻辑通过单元测试，前端页面可演示完整流程”。这种写法比“完成线索池开发”这种空话强太多了，团队周会上对着验收标准逐条过，没人能含糊。
验收口径这个事我单独让AI细化了一遍。原始提示词里我只写了“报表模块支持自定义维度”，这个描述太模糊。追问之后AI把它拆成了三条可验收的标准：支持按时间、区域、产品三个维度组合筛选，报表加载时间不超过三秒，导出Excel格式数据不丢字段。拿着这三条去跟业务方对齐，他们当场补了一条“要支持保存筛选方案”，我又加了个任务进去。你看，验收口径写细了，连需求遗漏都能提前发现。
5.5 输出落地：排期表、责任矩阵与沟通说明
三轮跑完之后我让AI一次性输出了三份东西，每份对应不同的使用场景。排期表给管理层和PMO看，责任矩阵给团队内部用，沟通说明用来跟销售和老板同步进度。
排期表我要求AI按甘特图的格式输出，字段包括任务编号、任务名称、负责人角色、开始周次、结束周次、持续天数、前置任务、是否关键路径。导出到Excel之后我手动调了下列宽和颜色，关键路径标红，里程碑标黄，直接发到项目群里当周知材料。责任矩阵用的是RACI格式，AI列了任务、负责人、审批人、协助人、知会人五列。这个矩阵我贴着工位墙上了，谁负责哪块抬头就能看见，省得每周开会问“这个事该找谁”。
沟通说明我让AI用一段话总结项目目标、整体工期、关键里程碑和主要风险，控制在两百字以内。这份说明我稍作修改就发给了销售负责人，回复是“这次总算说清楚要改什么了”。你看，前面四轮折腾没白费，说到底就是为了让相关方一眼看明白这项目要干什么、什么时候能干完、中间有什么坑。
整个流程跑下来我算了下时间，输入准备四十分钟，首轮生成加我自己消化大概半小时，二轮追问改了两轮加起来一个小时，三轮校验半小时，输出整理二十分钟。满打满算不到三个小时，拿到了一份五十六个任务、带依赖关系、关键路径和缓冲方案的排期表。这活以前纯手工干怎么也得一天，而且排出来的东西还没这么细。提示词不是让AI替你想，是让AI帮你把脑子里那些零散的想法快速整理成能落地的东西，省下来的时间你可以拿去干点更值钱的活。
上回那个CRM升级的项目收尾之后，我把整套提示词存档了，想着下回再遇到排期的事直接调出来改改就能用。结果两个月后接了个电商促销活动页的项目，我把那份提示词原封不动搬过去，出来的东西简直没法看。这事让我琢磨了很久，一套提示词在某个项目上跑得通，换个项目就拉胯，问题到底出在哪。
后来想明白了，提示词这东西跟工具一样，用久了得磨，磨之前得知道哪里钝了。这一章我就聊聊怎么判断一套排期拆分提示词到底好不好用，以及怎么让它越用越顺手。
6.1 评估指标：完整性、可执行性、一致性与可追踪性
拿到AI生成的排期表，我一般先逐条扫一遍任务清单，看看有没有明显缺失的环节。这种扫法凭的是经验直觉，但看多了也能总结出几个硬指标。完整性是第一个要盯的，说白了就是该有的活有没有全列出来。有个笨办法但特别管用：拿项目范围里的每个交付物去对任务清单，一个交付物至少对应一条开发任务一条测试任务。CRM项目里“报表模块”这个交付物，AI最初只给了一条“开发报表功能”，后来又补了三条筛选维度的任务和两条导出格式的任务才算完整。少了这些细节，到验收的时候业务方一句“我要按区域筛”就得返工。
可执行性这块我的判断标准很粗暴：随便挑五条任务，找对应的负责人问一句“这活你知道怎么干吗”。如果对方反问“这写的是什么意思”，那就是不可执行。像“优化系统性能”“完善用户模块”这种描述直接打回去重写，必须改成“将客户列表接口响应时间从五秒降到两秒以内”“开发用户权限校验接口并补充对应单元测试”。我自己定了个规矩，每条任务的描述里必须有一个明确的动作动词和一个可验证的产出物，缺一条就让AI补。
一致性和可追踪性经常被混在一起说，其实侧重不同。一致性看的是格式和口径有没有漂移，比如第一条任务写着“负责人：后端开发”，第四十条突然变成“负责人：Java工程师”，这就叫漂移。我每次拿到结果先筛一遍负责人字段和工期单位，有混用的直接让AI统一。可追踪性看的是任务之间能不能串起来，每条任务最好都带“前置任务编号”，里程碑验收标准能对应到具体任务。我有个小技巧，让AI给每条任务编一个层级式的编号，比如“2.3.1”代表第二里程碑第三个工作包的第一个子任务，这样查起来一目了然。
6.2 常见问题：任务过粗、工期失真、依赖遗漏与格式漂移
我刚才说的那四个指标，对应的是四类特别爱犯的毛病。任务过粗是头号问题，AI天生喜欢给你整大词。有一回我让它拆一个后台管理系统，它给我列了“用户管理模块开发”一条任务，工时给了十五天。我找后端一看，这活至少能拆成登录、角色权限、用户列表、密码重置、操作日志五个子任务，每个两三天。这种粗颗粒度的任务放在排期表里看着整齐，一落到人头上就抓瞎。
工期失真这事更隐蔽，因为AI给的数字看着都挺合理。三天的任务、五天的任务、两天的任务，排列得整整齐齐。但你把这些人天加起来一算，跟日历周期对不上。问题出在AI默认每个人都是全职投入、没有请假、没有会议、没有上下文切换的成本。我们团队每周五花半天开复盘会，周一上午基本在回邮件和处理上周遗留问题，真正能干活的就三天半。我在提示词里加了一条“按每人每周实际可用3.5天计算工期”，排出来的日历周期才靠谱。测试资源单人导致的工期压缩也是类似道理，你不告诉AI测试就一个人，它默认你有个三到五人的测试团队。
依赖遗漏是最容易埋雷的地方。AI能标出明显的开发依赖，比如前端页面依赖后端接口，但那些跨团队的、审批性质的、需要外部配合的依赖经常漏掉。那次电商活动页的项目，AI把设计和开发排得严丝合缝，完全没考虑设计稿需要品牌方审核这一环。品牌方走流程最快三天，慢的时候一周，这个依赖没标出来，后面全得等。我现在会让AI专门跑一轮“依赖补充”，提示词写“请识别排期中所有需要外部审批、跨部门协作或第三方交付的任务，标注这些任务对整体进度的影响”。这轮跑完通常能多抓出三到五个隐藏依赖。
格式漂移在长排期表里特别常见。AI生成到后半段容易疲劳，字段开始少填或者乱填。我见过最离谱的一次，任务编号从T001变成1、然后变成A1、最后干脆没编号了。这事靠人眼查太累，我一般让AI自己加一道检查：“请在输出最后附一份格式自检清单，列出每条任务是否包含全部必填字段，缺失的标红。”虽然AI的自检不一定全对，但能挡掉七八成的格式问题。
6.3 提示词迭代：基于反馈的版本管理与效果对比
我刚开始用提示词的时候是流水账式改法，想起来一句加一句，改到最后自己都记不清哪版是哪版。后来学乖了，每版提示词开头加个版本号和日期，比如“v1.3 2024-03-12 CRM项目版”，存在一个专门的文件夹里。每次改完顺手在文件名后面加六个字的修改备注，像“v1.4 增加缓冲规则”。
版本管理真正有用是在对比效果的时候。CRM项目二轮优化时我改了两版提示词，v1.2删掉了“请尽量详细”这种含混指令，v1.3增加了“每个任务工期不超过五天”的硬约束。两版跑同一个项目，v1.2出来的任务平均工期七天，v1.3出来的是四点三天。这个对比让我确信一件事：模糊的指令不如一个具体的数字管用。后来我把所有“尽量”“适当”“合理”这类词全从提示词里清出去了，换成了“不超过五天”“至少两条测试任务”“缓冲天数按总工期百分之十预留”这种能量化的表述。
团队里其他人用我的提示词跑出来的结果跟我自己跑的有时候差不少。我让同事跑一遍，然后对比两版结果找差异点。有个同事跑出来的排期表里任务数量比我多出二十条，我一看，他把我提示词里“请将任务拆解到工作包级别”改成了“请尽量拆细”。这就是差别所在。我把常见的不靠谱改法收集了七八条，每条前面加个“×”，标准写法前面加个“√”，附在提示词模板的引言里。这个做法是从我们写代码注释的习惯里搬过来的，挺土但管用。
效果对比我一般看三个数：任务总数、关键路径总工期、缓冲天数占比。跑同一个项目的同一条提示词，如果改版之后任务总数暴增但关键路径没缩短，说明拆出来的都是碎活，粒度过细了。如果关键路径明显缩短但缓冲天数没变，得看看是不是依赖标错了。这三个数我记在一个Excel表里，横轴是提示词版本号，竖轴是三个指标加一列“最终排期是否按期交付”。跑够五六个项目之后，哪版提示词真能打一目了然。
6.4 与项目管理工具和团队协作流程结合
AI吐出来的排期表再漂亮，落不到团队日常用的工具里就是废纸一张。我们团队用飞书多维表格管排期，所以我要求AI输出的字段名跟飞书表头一模一样：任务名称、负责人、开始日期、截止日期、状态、优先级、前置任务、备注。第一次跑的时候我让AI输出“开始周次”，导进飞书还得手动换算成日期，麻烦得要死。后来直接在提示词里写“所有日期按YYYY-MM-DD格式输出”，省了每天手动调格式的十分钟。
工具层面的对接不只改字段名这么简单。我们有条规矩，任何工期超过五天的任务进飞书之前必须拆成两个子任务，否则负责人会在周报里写“本周继续推进中”这种废话。这条规矩我写进了提示词：“请将所有工期超过五天的任务自动拆为两个或以上子任务，每个子任务标注独立的前置依赖和验收标准。”跑出来的结果导进飞书之后直接就是可跟踪的状态，不用再开个会挨个拆。
跟团队协作流程结合这事，我踩过的坑更值钱。最初我把AI生成的排期表直接扔到项目群里，配文“排期已出，各位查收”。结果两天里收到七条私信问各种问题：“我这个任务前置依赖是谁做完？”“联调时间是第几周？”“上线窗口跟另一个项目撞了怎么办？”从那以后我每次输出三件套：给管理层的甘特图版、给执行团队的责任矩阵版、给相关方的两百字文字说明。文字说明里专门留一行写“关键依赖与外部等待项”，把那些跨团队的事拎出来单说。
周会对接流程也调了一版。以前周会上对着排期表挨个过任务进度，一个项目过半小时。现在改成分三步：先让AI根据上周的实际完成情况重新算一遍关键路径和剩余工期，再让各负责人只汇报“卡住的依赖”和“需要调整的工期”，最后对照里程碑验收标准确认偏差。这样周会时间压到十五分钟，而且每次迭代AI都会给一版更新后的排期表存档，项目结束后翻看每周变化，哪周任务堆积了哪周人力空转了，一清二楚。
6.5 进阶场景：多项目排期、跨团队依赖与动态调整
单项目排期捋顺之后，我手贱试了试多项目同时排的情况。当时手头压着三个项目：CRM升级收尾、电商活动页开发、移动端App埋点改造。三个项目共用三个后端一个前端。我把三个项目的范围说明和资源约束打包塞进一条提示词，让它出一版统一排期。
AI给的结果乍看挺专业，三个项目按周排开，资源分配表也给了。细看发现大问题：它把同一个后端在同一个时间段排进了两个项目的开发任务里，还没标冲突。更麻烦的是三个项目各自的关键路径合在一起变成了一个网状结构，哪个项目拖一天会影响哪个项目，它没算出来。我追加了一轮追问：“请识别多项目并行下的资源冲突，输出冲突清单并给出调整方案，调整时优先保障对外承诺截止日期最近的项目。”调整后的版本把电商活动页排在优先位，CRM收尾往后挪了一周，因为活动页的对外发布日期是死的，CRM可以内部协调。这个优先级规则要是不提前说清楚，AI会按任务数量多少来排，完全不看业务价值。
跨团队依赖在多项目场景下特别要命。活动页项目依赖品牌方审核设计稿，CRM收尾依赖企业微信接口审批，App埋点依赖数据团队提供埋点规范。三个外部依赖分散在三个项目里，哪个先到位哪个后到位直接影响排期串联方式。我专门让AI跑了一个“外部依赖追踪表”，字段包括依赖事项、提供方、预计到位时间、影响项目、影响任务、延迟应对方案。这表我每周更新一次到位状态，哪条延迟了就在排期表里自动把受影响的任务往后推，推完再让AI重新算关键路径。
动态调整这块我试过一个偷懒的法子，在飞书里设了个自动化规则：每周五把各任务的实际状态导出来，粘进提示词里加一句“请根据实际进度更新排期表，重新计算关键路径，标注进度偏差超过两天的任务并给出追赶方案”。跑了两周效果还行，AI能识别出哪些任务拖了、拖了几天、要不要加人或者拆分任务。但它有个盲区，不擅长判断“该不该砍需求”。有一回报表模块确实来不及了，AI给的方案是加两天班赶出来，实际上业务方同意把“自定义维度”砍到只剩时间维度，工作量直接降了一半。这事的教训是动态调整的提示词里得留一道人工判断的口子，写上一句“如果发现某模块按当前资源无法在截止日期前完成，请列出可以裁剪的功能点供人工决策”。AI负责算账，砍不砍、怎么砍，还得人拍板。
这几个进阶场景跑下来，我对提示词的态度反而比刚开始用的时候更谨慎了。一套提示词在单项目、单团队、单依赖源的场景下表现稳定，换个环境就得从头调参数。但好在评估维度是通用的，完整性、可执行性、一致性、可追踪性这四个尺子量什么项目都管用。迭代逻辑也是通的，加约束、去模糊、留人工口子。排期这事说到底不是让AI替你做决定，是让它帮你把选项摆清楚、代价算明白，然后你签字画押。提示词就是那个摆选项和算代价的加速器，加速器本身好不好使，得靠实际跑出来的排期表按时交付率来检验。
