# WorkBuddy不会用？我写了110条能直接干活的办公提示词，还不收藏？ > 大家好，我是萝卜哥～ 这两天，我在给 WorkBuddy 写办公提示词。刚开始只是想解决几个常见问题，比如周报怎么写、会议怎么约、项目任务怎么拆等等。 但是写着写着，发现需要覆盖的场景越来越多。 - 作者：zhouluobo - 出处：X（@zhouluobo） - 原文：https://x.com/zhouluobo/status/2084631524469604453 - 发布：2026-08-04 - 存档：https://fav.zhudong.net/p/78rgy4 --- 大家好，我是萝卜哥～ 这两天，我在给 WorkBuddy 写办公提示词。刚开始只是想解决几个常见问题，比如周报怎么写、会议怎么约、项目任务怎么拆等等。 但是写着写着，发现需要覆盖的场景越来越多。 因为很多时候我们遇到的麻烦，都是一整条工作链。前面刚把会议开完，后面还得追行动项。数据刚分析完，接着又要写成管理层能看懂的结论。 所以我把高频办公需求拆成 11 类，一口气写了 110 条提示词。每一条都尽量写清数据范围、交付物和验收条件，涉及发消息、改数据或创建任务时，还给执行动作加了一道保险来确认。 这篇文章前半段讲提示词怎么改，后半段直接放完整提示词库。大家肯定不用从头背，只需要在碰到什么事的时候，去对应分类里挑一条就好了。 好提示词，要把一句愿望改成一份任务 很多人第一次用 WorkBuddy，会直接说“帮我写个周报”“分析一下数据”“约个会”。WorkBuddy 当然能回答，可它不知道该读取哪些材料，也不知道结果要交给谁。 让 AI 盲目的干活，和让下属漫无目的的忙活是一样的，效果都不会太好。 我现在更常用下面这套结构来给 AI 分配任务。它不复杂，但是可以逼着你把一件事从头到尾说清楚，也方便后面检查结果能不能直接交付。 比如“帮我写个周报”，可以改成下面这样。 任务还是那个任务，WorkBuddy 需要猜的地方已经少了很多。后面检查时也能逐项对照，不满意就知道该改哪里。 能执行的 AI，更要先写清操作边界 WorkBuddy 可能会接触文件、任务系统、日历和邮件。账号接入情况不同，它能做的动作也会不同。 所以后面的提示词都默认遵守一条规则，读取前先确认范围，写入前先给预览。没有权限就说明限制，不能用猜测补齐数据。 如果你准备自己写提示词，可以把这段放在末尾，百试百灵啊。 方法说到这里其实已经足够了。下面这 110 条，我已经按使用场景分好，把方括号里的内容换成自己的信息，就能直接用。 110 条 WorkBuddy 办公提示词 一个人工作台 001｜生成今日行动清单 读取我今天的日程和未办结任务，按截止时间与业务影响排序。只保留今天确实需要推进的事项，为每项写出预计用时和下一步动作。发现时间冲突时先提示，不要直接改日程。 002｜规划本周重点 读取我本周的日程、任务和项目节点，选出最需要关注的工作。按项目归组，写出本周目标、关键动作和可能卡住我的问题。找不到截止时间的任务放进待确认区。 003｜拆解复杂任务 将任务【任务名称】拆成可以独立推进的子任务。每项写出交付物、前置条件、预计用时和验收方式。先给拆解预览，等我确认后再创建任务。 004｜清理逾期任务 查询我当前所有逾期任务，按逾期天数和业务影响排序。判断哪些应该继续、延期或关闭，并说明依据。涉及修改状态和截止日期时先给操作清单。 005｜检查个人负载 统计我未来【时间范围】内的会议时长和任务预计工时。找出负载最高的日期，并给出一版调整建议。不要移动已有日程，只生成预览。 006｜生成下班前复盘 根据我今天的任务状态和日程记录，生成一份简短复盘。写出今天推进了什么、还卡在哪里，以及明天最先处理哪件事。没有记录支持的内容不要补写。 007｜把聊天内容变成待办 从我提供的聊天记录中提取承诺、截止时间和责任人。将信息写成待办预览，并标出存在歧义的地方。责任人或日期不清楚时先提问。 008｜设置专注时间 查看我【日期】的空闲时段，为任务【任务名称】寻找一段连续的专注时间。避开已有会议，并说明选择该时段的理由。得到我确认后再创建日程。 009｜设计重复任务 将工作【重复工作】改写成周期任务。写清触发时间、执行内容、交付结果和异常处理方式。先输出规则预览，不要直接启用。 010｜建立个人决策记录 根据我提供的讨论材料，写一份决策记录。保留问题背景、最终选择、主要理由和后续复查日期。无法从材料确认的结论标记为待确认。 二会议与协作 011｜寻找共同空闲时间 查看【参会人】在【日期范围】内有权共享的忙闲信息，找出两个可用时段。每个时段说明冲突情况和参会覆盖率，等我选择后再创建会议。 012｜生成决策型议程 为会议【会议主题】写一份【时长】分钟的议程。围绕本次必须做出的决定分配时间，注明每个议题的负责人和所需材料。删除只汇报进展且无需讨论的部分。 013｜准备会前材料 读取与【会议主题】相关的指定文档，生成一页会前阅读材料。写清背景、当前分歧和需要参会人提前思考的问题，并附上使用到的文件名称。 014｜生成会议邀请预览 为【会议主题】写会议邀请。说明开会目的、参会人需要准备的材料和预期产出。先给标题、正文和参会名单预览，不要发送。 015｜从记录中生成纪要 根据我提供的会议记录生成纪要。区分已经确认的决定与仍在讨论的问题，行动项要写责任人和截止日期。材料里没有的信息不要推测。 016｜提取会议行动项 从【会议记录】中提取所有行动项，按责任人归组。每项保留原始依据、截止日期和交付标准。日期不清楚时标记为待确认。 017｜追踪会后进展 查询会议【会议名称】产生的行动项，列出当前状态和逾期风险。先生成提醒消息草稿，语气保持简洁，等我确认后再发送。 018｜压缩低效会议 阅读【会议议程】，判断哪些内容可以改成异步同步。给出一版压缩后的议程，并说明节省时间的依据。不要直接取消或缩短现有会议。 019｜处理会议时间冲突 检查会议【会议名称】与参会人的已有日程冲突。给出保留原时间和更换时间两套方案，说明各自影响。等我选择后再修改日程。 020｜生成异步站会 为团队【团队名称】生成一份异步站会模板。成员需要填写当前进展、下一步动作和阻塞问题，回复控制在 150 字以内。附上汇总规则和未回复提醒方式。 三文档与知识库 021｜压缩长文档 阅读文档【文档名称】，生成一份适合【目标读者】阅读的摘要。保留关键结论和重要数据，每条结论标注对应章节。无法验证的内容不要改写成事实。 022｜比较两个版本 对比文档【版本 A】和【版本 B】，列出新增内容、删除内容和含义发生变化的地方。按影响程度排序，并指出需要人工确认的修改。 023｜从资料生成大纲 阅读我指定的材料，为主题【主题】生成文章或报告大纲。每个章节写出要回答的问题和可以引用的材料来源，不要加入资料外的数据。 024｜把流程写成 SOP 根据【流程材料】写一份可执行的 SOP。每一步写触发条件、操作动作和检查结果，异常情况单独说明。涉及权限操作时标出负责人。 025｜生成内部 FAQ 从【产品文档或聊天记录】中提取高频问题，写成内部 FAQ。答案保持简短，并附上依据来源。材料没有覆盖的问题放入待补列表。 026｜建立术语表 阅读【资料范围】，提取容易混淆的业务术语。为每个术语写通俗解释和使用示例，并标出存在多个定义的词。 027｜检查文档缺口 审查文档【文档名称】，从目标读者和使用场景出发寻找信息缺口。列出缺少的证据、跳跃的结论和无法执行的描述，不要直接改写全文。 028｜改写成管理层版本 将【文档名称】改写成管理层阅读版。开头先给结论，正文保留影响决策的数据和风险，技术细节放到附录。所有数字保持原值。 029｜生成知识卡片 从【文档或会议记录】中提取可复用知识，写成知识卡片。每张卡片只讲一个问题，包含适用场景和原始来源，重复内容合并。 030｜设计归档规则 根据【文件夹】里的文件名称和修改时间，生成归档方案。先列出建议目录、命名规则和重复文件，不要移动或删除任何文件。 四邮件与沟通 031｜生成邮件优先级清单 读取我有权访问的未读邮件，按紧急程度和业务影响分组。每封邮件用一句话说明需要我做什么，不要自动回复或改变邮件状态。 032｜撰写客户邮件 根据【背景材料】写一封发给【客户角色】的邮件。正文先说结论，再写需要对方确认的事项。语气保持专业克制，先给草稿不要发送。 033｜回复模糊需求 阅读邮件【邮件主题】，找出需求中缺少的信息。生成一封澄清邮件，只询问会影响交付的关键问题，并给对方一个方便回复的格式。 034｜礼貌拒绝请求 为请求【请求内容】写一封拒绝邮件。说明当前无法接受的原因，同时给出一个可行替代方案。不要承诺未经确认的时间和资源。 035｜催促对方回复 根据邮件线程生成一封跟进邮件。简要回顾等待确认的事项和对进度的影响，给出希望回复的日期。语气坚定但不施压，先给草稿。 036｜生成项目升级邮件 根据【问题记录】写一封升级邮件。只写已经确认的事实、当前影响和需要管理层做出的决定。附上原始材料名称，不要夸大风险。 037｜提取邮件承诺 从【邮件范围】中提取双方已经确认的承诺，写出责任人、交付内容和日期。存在冲突时并列展示对应邮件依据，不要替任何一方做决定。 038｜生成邮件摘要 将主题【邮件主题】下的邮件线程压缩成一页摘要。保留最新结论、尚未解决的问题和下一步动作，重复引用只保留一次。 039｜改写邮件语气 检查下面这封邮件的语气，在不改变事实和要求的前提下，改得更简洁、更容易执行。输出修改稿，并说明最重要的一处变化。 040｜准备批量通知 为事件【事件名称】写一份批量通知。根据收件人名单检查称呼和信息差异，先生成发送预览。名单或随附文件不完整时停止发送并提示我。 五项目推进 041｜写项目启动卡 根据【项目背景】生成项目启动卡。写清目标、范围边界、主要交付物和决策人。信息不足的部分保持空白并列出待确认问题。 042｜生成里程碑计划 将项目【项目名称】拆成里程碑。每个里程碑写交付物、负责人、前置条件和验收日期。没有工时依据时不要虚构精确日期。 043｜识别项目依赖 阅读【项目计划】，找出任务之间的依赖关系。标出会影响整体进度的关键依赖，并写出依赖未按时满足时的处理建议。 044｜建立风险台账 根据【项目材料】建立风险台账。为每项风险写触发信号、可能影响、负责人和应对动作。推测出的风险要标注为待验证。 045｜评估变更请求 分析变更【变更内容】对项目范围、时间和资源的影响。给出接受、延期或拒绝的判断依据，先生成评估报告，不要修改项目计划。 046｜检查团队负载 读取项目成员在【时间范围】内的任务分配，找出可能过载或空档的成员。给出一版资源调整预览，保留现有分配不变。 047｜生成项目周报 根据本周任务状态和项目记录生成周报。重点写实际进展、偏离计划的原因和需要决策的问题。每项结论附上数据来源或任务链接。 048｜准备迭代计划 从待办池中筛选适合进入【迭代周期】的任务。结合优先级、依赖关系和团队容量给出建议，先输出候选清单，不要修改任务状态。 049｜生成验收清单 根据需求文档【文档名称】生成验收清单。每项写测试动作和通过条件，无法从需求中推导的标准标记为待产品负责人确认。 050｜写项目复盘 根据项目计划、任务记录和结果数据写一份复盘。对照原目标说明差距，区分可复用经验与偶然结果。缺少证据的评价不要写成结论。 六数据与表格 051｜检查数据质量 读取表格【文件名称】，检查空值、重复记录和格式不一致。先生成问题清单与影响行数，不要直接修改当前文件。 052｜生成字段说明 根据数据表【表名】生成字段字典。写出字段含义、数据类型、示例值和可能的质量问题。无法判断含义的字段标记为待业务确认。 053｜寻找异常波动 分析指标【指标名称】在【时间范围】内的变化，标出异常波动和发生时间。区分数据异常与业务变化，只根据现有数据给出可能原因。 054｜生成数据透视方案 根据业务问题【问题】设计数据透视表。说明行字段、列字段和计算指标，先给结构预览，得到确认后再新建工作表。 055｜选择合适图表 阅读数据【数据范围】，根据我要表达的结论推荐图表。说明选择理由和容易造成误解的展示方式，先给图表方案不要改文件。 056｜写管理层数据摘要 根据【分析结果】写一页管理层摘要。开头给最需要关注的结论，随后写业务影响和建议动作。相关性不能写成因果关系。 057｜做用户分组分析 根据【用户数据】和目标【业务目标】设计分组规则。说明每组特征和样本数量，样本过少时给出提示，不要强行下结论。 058｜生成趋势预测说明 基于【历史数据】生成趋势预测方案。写清采用的方法、数据限制和误差来源，输出预测区间，不要只给单一数字。 059｜编写只读 SQL 根据需求【查询需求】编写只读 SQL。注明使用的表和过滤条件，先给查询语句与预期返回字段，不要执行更新或删除操作。 060｜设计数据看板 为业务主题【主题】设计一页数据看板。每个指标写明计算口径和更新频率，优先展示能推动行动的数据，先输出布局说明。 七内容与市场 061｜提炼目标用户 根据【访谈、评论或销售记录】提炼目标用户特征。区分材料中直接出现的事实和推测，不要凭空补年龄、收入或职业。 062｜生成内容选题库 围绕主题【主题】生成内容选题。每个选题写目标读者、要解决的问题和可使用的现有材料，删除只有热词却没有内容支撑的题目。 063｜规划内容日历 为【平台】规划【时间范围】的内容日历。结合已有素材和发布时间，先给主题节奏与每篇内容目标，不要直接发布。 064｜改写标题 根据正文【正文内容】生成标题候选。标题要准确反映内容，不使用无法证明的数字和夸张承诺。每个标题说明它吸引哪类读者。 065｜生成长文大纲 围绕主题【主题】生成公众号文章大纲。先写全文唯一主线，再让每个章节回答一个读者问题。没有证据支撑的章节不要硬加。 066｜适配不同平台 将内容【原内容】改写给【目标平台】。保留事实和核心观点，根据平台阅读习惯调整长度与开头，输出改动说明。 067｜做竞品材料对比 只根据我提供的竞品材料，比较【产品 A】与【产品 B】。统一比较口径，标出资料缺口，不要把营销文案当成已验证能力。 068｜写落地页文案 根据【产品资料】写落地页文案。开头说清用户问题，随后解释产品如何工作，所有效果数字必须能在材料中找到依据。 069｜准备用户访谈 为目标【访谈目标】设计用户访谈提纲。问题保持开放，避免诱导用户赞同预设结论，并写出每个问题想验证的假设。 070｜复盘内容表现 根据【内容数据】复盘表现。把曝光、互动和转化分开分析，找出可以被数据支持的变化。样本不足时只写观察，不下长期结论。 八招聘与团队 071｜撰写岗位需求 根据【业务需求】写岗位说明。区分必须具备的能力和可以入职后学习的内容，删除与实际工作无关的空泛要求。 072｜生成简历初筛表 根据岗位说明生成简历初筛表。评分只使用与工作相关的经历和技能，不推测候选人的年龄、家庭情况或其他敏感信息。 073｜设计面试问题 为岗位【岗位名称】设计面试问题。每个问题对应一项岗位能力，并写出观察点。避免询问与工作无关的个人隐私。 074｜生成面试评分卡 根据【岗位要求】生成面试评分卡。为每项能力写可观察的行为标准，评分依据保持一致，不使用“感觉不错”这类模糊描述。 075｜制定入职首周计划 为岗位【岗位名称】生成入职首周计划。写清需要认识的人、需要开通的权限和首个可交付任务，时间冲突处标记为待确认。 076｜准备一对一沟通 根据【工作记录】生成一对一沟通提纲。关注最近进展、遇到的阻塞和需要的支持，不根据零散信息推测员工态度。 077｜改写绩效反馈 将【反馈草稿】改写成基于事实的绩效反馈。保留具体行为和影响，删除人格判断，并给出可执行的下一步期待。 078｜设计培训计划 根据团队当前能力缺口【能力缺口】生成培训计划。每个模块对应一个真实工作问题，并写出培训后如何检查是否学会。 079｜检查团队任务分配 读取【团队】在【时间范围】内的任务数据，找出负载不均和职责冲突。先给调整建议，不要直接改负责人。 080｜生成离职交接清单 根据岗位职责和当前项目生成交接清单。写出文件位置、接手人和待解决问题，涉及账号权限时只列操作建议，不记录密码。 九财务与采购 081｜分析费用变化 对比【时间范围】内的费用数据，找出变化较大的科目。说明变化金额和占比，只根据现有记录分析原因，不补写业务解释。 082｜检查预算偏差 将实际支出与预算表对比，列出超预算和使用不足的项目。按影响金额排序，并标出需要负责人说明的部分。 083｜生成现金流预览 根据已确认的应收、应付和账户余额生成【时间范围】现金流预览。所有假设单独列出，不确定日期使用区间表达。 084｜比较供应商方案 根据我提供的报价和服务材料比较供应商。统一计算口径，写出价格、交付条件和主要风险。缺少的条款不要自行推测。 085｜撰写采购申请 根据需求【采购需求】生成采购申请草稿。写清使用目的、数量依据和预算来源，先给预览，不要提交审批。 086｜检查发票信息 对照订单和验收记录检查发票【发票范围】。列出金额、主体或日期不一致的项目，不要修改原始记录。 087｜准备价格谈判 根据历史采购记录和本次报价生成谈判准备稿。写出可以确认的价格差异、优先争取的条款和不能突破的预算边界。 088｜评估投入回报 根据【投资项目】的成本与收益假设生成回报测算。把已知数据和假设分开，展示不同情景下的结果，不给出保证性结论。 089｜判断服务是否续费 根据【服务名称】的使用数据、费用和业务影响生成续费评估。写出继续使用与停止使用的影响，先给建议，不要发起续费。 090｜生成合规抽查清单 为【费用或采购范围】生成抽查清单。检查凭证、审批记录和重复报销风险，先列抽查规则，不要删除或更改财务数据。 十研发与运维 091｜分流问题单 读取问题单【问题范围】，按影响用户、紧急程度和可复现性分组。信息不足的问题列出需要补充的日志和环境信息，不要直接关闭。 092｜生成代码审查清单 根据变更说明和代码差异生成审查清单。重点检查错误处理、安全边界和测试覆盖，结论要引用具体文件或代码位置。 093｜写架构决策记录 根据【技术问题】写一份架构决策记录。比较候选方案的约束和代价，保留被放弃方案的原因，未知性能数据标记为待验证。 094｜生成测试用例 根据需求【需求内容】生成测试用例。覆盖正常流程和关键异常，每条写输入、操作和预期结果。需求没有说明的行为不要自行定义。 095｜准备发布检查 根据版本【版本名称】生成发布检查清单。写出变更范围、验证动作和回滚条件，先给预览，不要触发发布。 096｜生成故障排查路径 根据故障现象【现象】生成只读排查路径。优先检查日志、指标和近期变更，任何可能修改系统状态的命令都要单独标记并等待确认。 097｜压缩日志信息 阅读【日志范围】，按时间顺序提取关键错误和关联事件。保留原始时间戳与错误码，不要把同时发生写成因果关系。 098｜生成接口文档 根据【接口代码或说明】生成接口文档。写清请求字段、返回结构和错误情况，示例数据不得包含真实密钥或个人信息。 099｜检查安全风险 审查【代码或配置】中的安全风险。为每项问题写影响、证据位置和修复建议，不要自动修改生产配置或暴露敏感数据。 100｜写故障复盘 根据事件时间线、日志和处理记录写故障复盘。区分直接原因和待验证假设，写出可执行的后续动作，不追责个人。 十一自动化工作流 101｜把邮件转成任务 设计一条规则，从满足【邮件条件】的邮件中提取任务名称、负责人和日期。先用历史邮件生成模拟结果，等我确认后再创建自动化。 102｜同步会议行动项 设计会议纪要到任务系统的同步流程。只同步已经确认的行动项，责任人或日期缺失时进入待确认队列，不要自动创建。 103｜生成每周工作摘要 设计每周【时间】运行的摘要任务，读取指定项目的任务和日程，生成周报预览。写清数据范围、接收人和失败后的通知方式。 104｜把表单接入审批 根据表单【表单名称】设计审批流程。写出触发条件、审批人选择规则和退回处理方式，先输出流程图文字版，不要启用。 105｜监控任务状态 为项目【项目名称】设计状态监控。只在任务逾期或关键依赖变化时提醒，说明提醒对象和免打扰时间，先给规则预览。 106｜监控文档变化 设计文档【文档范围】的变更提醒。摘要只包含修改位置和主要内容，敏感文档不得发送正文，先确认接收人权限。 107｜自动追踪待回复事项 从指定邮件和会议行动项中识别等待他人回复的事项。生成跟进清单和提醒草稿，达到【等待天数】后才提示，不要自动发送。 108｜设计数据同步流程 为【数据源】到【目标系统】设计同步方案。写清字段映射、更新频率和冲突处理方式，先用样例数据验证，不要连接生产环境。 109｜补上失败处理机制 审查自动化【自动化名称】，补充失败重试、停止条件和通知规则。重复执行可能产生副作用时禁止自动重试，并说明人工介入方式。 110｜审计现有自动化 列出我有权查看的自动化规则，检查触发条件、写入范围和最近运行状态。找出长期未使用或权限过大的规则，先生成审计报告，不要停用或删除。 把提示词库变成自己的工作系统 110 条看着很多，但是真用起来不需要全部收藏。先挑和你工作生活最接近的两类，把里面的任务对象和交付格式换成日常真实用法，先跑起来再说。 如果团队周报有固定栏目，就直接写进周报提示词。如果会议纪要必须记录决策人，也可以放进会议模板。使用的过程当中要不断的优化提示词，根据自己的要求来磨练 WorkBuddy 的工作流程，这样时间长了，整个流程就都属于你了，用起来就会越来越顺。 还有一个习惯很有用。第一次先让 WorkBuddy 预演，确认它找对材料、理解范围，再让它写入系统。尤其是邮件、日程和自动化任务，多看一眼预览，能省很多不必要的麻烦。 写在最后 这次我分享的海量提示词的价值，是让你遇到任务时能立刻找到起点。但是真正决定结果的，还是提示词里有没有你的业务材料、交付要求和操作边界。 说白了就是 AI Agent 出的结果好不好，决定权还是你自己投喂给它的东西是否给力。 所以这 110 条可以直接复制，也值得你继续改。先挑一条今天就要做的工作，把方括号换成真实信息，再加上“先预览，后执行”。 只有提示词开始贴合你的工作习惯，WorkBuddy 才会从一个会回答问题的 AI，慢慢变成能接住具体任务的工作搭档。