WorkBuddy 不会用？110 条能直接干活的办公提示词库 + 5 段式黄金结构（10 年程序员视角重写）
核心结论：很多人第一次用 WorkBuddy，会直接说"帮我写个周报"、"分析一下数据"、"约个会"——WorkBuddy 当然能回答，但它不知道该读取哪些材料，也不知道结果要交给谁。本文给你一套5 段式黄金结构（工作对象 + 可用材料 + 具体动作 + 交付物 + 检查规则）+ 11 类 110 条直接可复用的提示词——每一条都写清了数据范围、交付物、验收条件，涉及发消息、改数据、创建任务时都默认"先预览后执行"。你不需要背 110 条，只需要按场景分类挑、用前换方括号、跑前先预览——WorkBuddy 就能从"会回答问题的 AI"变成"能接住具体任务的工作搭档"。
3 分钟摘要：
- 90% 的人用 WorkBuddy 失败的原因 = 只给"愿望"、不给"任务"
- 5 段式黄金结构 = 工作对象 + 可用材料 + 具体动作 + 交付物 + 检查规则
- 核心安全线 = 写入前先给预览（邮件、任务、自动化必须遵守）
- 11 类 110 条提示词完整覆盖：个人工作台 / 会议协作 / 文档知识库 / 邮件沟通 / 项目推进 / 数据表格 / 内容市场 / 招聘团队 / 财务采购 / 研发运维 / 自动化工作流
- 3 类常见错误 = 给太少材料 / 没说验收标准 / 直接执行未预览
- 正确打开方式 = 先选 1 类最常用的 5 条、跑通 5 次、再扩到 11 类
缘起：最近读到萝卜哥写的《WorkBuddy 不会用？我写了 110 条能直接干活的办公提示词》，作为 10 年程序员 + 2 年独立开发者 + 1 年 AI 重度用户，我必须说：这套提示词库是我见过最接地气、最工程化、最能直接落地的一套。5 段式结构本质上和软件工程的需求文档结构完全一致——工作对象 = 需求方、可用材料 = 输入数据、具体动作 = 业务流程、交付物 = 输出物、检查规则 = 验收标准。本文完整保留 110 条提示词，重新解读 5 段式结构背后的工程思想，并加上3 类常见错误示范 + 1 套从 5 条到 110 条的渐进式落地路径。
一、5 段式黄金结构（程序员视角重写）
萝卜哥给出的核心结构是：
工作对象 + 可用材料 + 具体动作 + 交付物 + 检查规则
作为一个写过 10 年代码的程序员，我看到这个结构立刻想到了软件工程的需求文档——这 5 段本质上和 PRD（产品需求文档）的 5 个核心字段完全对应。
1.1 5 段式的工程解读
| 5 段式结构 | 软件工程对应 | 现实意义 |
|---|---|---|
| 工作对象 | 需求方 / 业务背景 | 告诉 AI "为谁做" |
| 可用材料 | 输入数据 / 接口 | 告诉 AI "从哪找数据" |
| 具体动作 | 业务流程 / 业务逻辑 | 告诉 AI "怎么一步步做" |
| 交付物 | 输出物 / 交付格式 | 告诉 AI "结果长什么样" |
| 检查规则 | 验收标准 / 异常处理 | 告诉 AI "什么算合格" |
这 5 段 = 1 份"AI 也能读懂的需求文档"。
1.2 实际改写示范（before / after）
改写前（90% 用户的写法）：
帮我写个周报
改写后（5 段式写法）：
读取我本周有权访问的任务和日程，范围只限本周一至周五。
将已经办结和仍在推进的事项按项目归组，生成一份 600 字以内的周报。
正文写出实际进展、当前阻塞和下一步动作。
找不到依据的成绩不要补写，缺失信息放进待确认区。
先输出预览稿，不要发送。
5 段式拆解：
- 工作对象：本周一至周五的任务和日程
- 可用材料：本周所有任务状态、日程记录
- 具体动作：按项目归组、提取进展 / 阻塞 / 下一步
- 交付物：600 字以内周报
- 检查规则：找不到依据不补写、先给预览
任务还是那个任务——但 WorkBuddy 需要猜的地方已经少了很多。
1.3 黄金结构背后的工程思想
5 段式 = 把"模糊愿望"翻译成"具体任务"——这和软件工程的本质完全一致。
软件工程的核心是消除歧义：
- 一个 bug 描述不清 → 程序员返工
- 一个需求写得不具体 → 产品上线失败
- 一个 AI 提示词不具体 → AI 输出随机
5 段式 = 把"AI 输出随机"变成"AI 输出可控"。
二、核心安全线：先预览，后执行
这一条是 110 条提示词里最重要的一条——比任何分类都重要。
2.1 为什么"先预览后执行"是核心防线
WorkBuddy 可能会接触文件、任务系统、日历和邮件——账号接入情况不同，它能做的动作也会不同。
核心风险：
- ❌ 直接发邮件给客户 → 不可撤回
- ❌ 直接删除文件 → 不可恢复
- ❌ 直接修改数据库 → 不可逆
- ❌ 直接触发自动化 → 可能产生连锁反应
这就是为什么所有 110 条都默认遵守一条规则：
读取前先确认范围，写入前先给预览。没有权限就说明限制，不能用猜测补齐数据。
2.2 必须遵守的 3 条操作边界
如果你要自己写提示词，把这段放在末尾——百试百灵：
- 先确认你能访问的数据和工具
- 缺少关键信息时列出待补内容，不要自行编造
- 涉及发送、创建、修改或删除时，先给预览和影响范围，得到确认后再执行
这 3 条 = AI Agent 的"权限审计 + 异常处理 + 人工把关"。
和软件工程的对应：
- "先确认你能访问的数据和工具" = 权限审计
- "缺少关键信息时列出待补内容" = 输入校验
- "涉及发送、创建、修改、删除时先给预览" = 写操作前的人工 review
AI Agent 的工程化 = 权限审计 + 输入校验 + 写操作 review。
三、110 条 WorkBuddy 办公提示词（完整库）
下面 110 条按 11 类组织，所有方括号 [...] 内的内容都要换成你的真实信息。
一、个人工作台
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｜审计现有自动化
列出我有权查看的自动化规则，检查触发条件、写入范围和最近运行状态。找出长期未使用或权限过大的规则，先生成审计报告，不要停用或删除。
四、3 类常见错误示范
很多人用 110 条提示词还是失败，99% 是犯了下面 3 类错误。
4.1 错误 1：给太少材料
❌ 错误示范：
"帮我写个周报"
✅ 正确示范（5 段式）：
"读取我本周有权访问的任务和日程，范围只限本周一至周五。
将已经办结和仍在推进的事项按项目归组，生成一份 600 字以内的周报。
正文写出实际进展、当前阻塞和下一步动作。
找不到依据的成绩不要补写，缺失信息放进待确认区。
先输出预览稿，不要发送。"
错误本质：用户没说"我有哪些任务和日程"、没说"周报给谁看"、没说"600 字以内"。
5 段式 = 把"AI 必须猜"变成"AI 直接照做"。
4.2 错误 2：没说验收标准
❌ 错误示范：
"分析一下销售数据"
✅ 正确示范（5 段式）：
"分析【时间范围】内的销售数据，标出异常波动和发生时间。
区分数据异常与业务变化，只根据现有数据给出可能原因。
相关性不能写成因果关系。
先生成分析预览，不直接修改原始数据。"
错误本质：用户没说"找什么"（异常波动）、没说"判断标准"（数据异常 vs 业务变化）、没说"红线"（不能写成因果）。
5 段式 = 把"AI 自由发挥"变成"AI 按规则输出"。
4.3 错误 3：直接执行未预览
❌ 错误示范：
"给客户发一封邮件报价"
✅ 正确示范（5 段式）：
"根据【背景材料】写一封发给【客户角色】的报价邮件。
正文先说结论，再写报价明细和有效期。
语气保持专业克制，先给草稿不要发送。
涉及金额或合同条款时必须先给预览。"
错误本质：用户没说"先给草稿"、没说"不要发送"、没说"合同条款需预览"——AI 直接发出去就不可撤回。
5 段式 = 把"AI 自动执行"变成"AI 草稿 + 人工把关"。
五、把这套提示词库变成自己的工作系统
5.1 渐进式落地路径
110 条看着很多，但真用起来不需要全部收藏。推荐 4 周渐进式落地：
| 周 | 动作 | 目标 |
|---|---|---|
| 第 1 周 | 选 1 类最常用（如"个人工作台"）+ 挑 5 条最贴合 | 跑通 5 次 |
| 第 2 周 | 在第 1 周 5 条基础上微调、加入团队工作场景 | 熟练使用 |
| 第 3 周 | 扩展到 2-3 类（加"会议协作"和"邮件沟通"） | 覆盖核心场景 |
| 第 4 周 | 扩展到 5 类（加"项目推进"和"数据表格"） | 覆盖 80% 日常 |
90 天后再回头看，你已经形成自己的工作流。
5.2 提示词微调的 3 个原则
原则 1：根据业务术语改方括号
每个团队的术语不一样——比如"项目"在你团队可能是"工单"、"需求"、"OKR"。
不要直接套用 110 条——把方括号换成你团队的真实术语。
原则 2：根据交付物改格式
每条提示词都留了"交付物"的位置——改成你团队真实要的格式。
比如"周报"——你们团队可能要求"先写亮点、再写阻塞、最后写风险"——直接加到 5 段式里。
原则 3：根据操作权限加边界
每条提示词都默认"先预览后执行"——根据你的实际权限再细化：
- 邮件类 → "先给草稿" + "不发送" + "不抄送其他人"
- 任务类 → "先给清单" + "不直接改状态" + "不改负责人"
- 自动化类 → "先给流程图" + "不连接生产环境" + "不启用"
5.3 让 WorkBuddy 真正成为"工作搭档"
3 个让提示词越用越好的习惯：
习惯 1：每次跑完后，回头改提示词
跑完一次后，回头看输出哪些不满意——直接加到 5 段式里。
比如跑完周报觉得"少了风险预警"——下次加一句"写出本周新出现的风险"。
习惯 2：把高频场景沉淀成"模板提示词"
高频场景（如周报、纪要、邮件）沉淀成你自己的 1-2 条模板提示词——比 110 条通用版更精准。
习惯 3：第一次永远先预览
涉及发消息、改数据、创建任务时——第一次必须先看预览。
预览 = AI Agent 的人工 review 环节——省掉一次不可逆操作。
六、5 段式结构的 3 个常见变形
实际工作中 5 段式不一定每次都用，根据场景可以变形：
6.1 极简版（3 段式）
适合简单任务（如"今天该做什么"）：
对象 + 动作 + 交付物
例：
读取今天的日程和未办结任务，按时间排序输出今日清单。
6.2 标准版（5 段式）
适合大部分办公任务：
对象 + 材料 + 动作 + 交付物 + 验收
例：
读取本周的任务和日程，提取已办结和进行中事项，
按项目归组，生成 600 字以内周报，先输出预览稿。
6.3 复杂版（7 段式）
适合复杂任务（如"做一次完整复盘"）：
对象 + 材料 + 动作 + 交付物 + 验收 + 边界 + 异常处理
例：
读取 Q3 的项目计划、任务记录和财务数据，
对比原目标做复盘，生成 1 页管理层摘要 + 1 页详细分析。
开头给结论，相关性不写成因果，先给预览。
涉及内部数据时不要外传，没有依据的评价不要写。
5 段式是标准版——简单任务用 3 段、复杂任务用 7 段。
关键点回顾
| 关键点 | 错误做法 | 正确做法 |
|---|---|---|
| 5 段式结构 | 只说"帮我做 X" | 工作对象 + 可用材料 + 具体动作 + 交付物 + 检查规则 |
| 写入操作 | 直接发邮件 / 改数据 | 先给预览，得到确认后再执行 |
| 材料不足 | 让 AI 自己编 | 列出待补内容，不要自行编造 |
| 验收标准 | 不说 | 每条都说"什么算合格" |
| 方括号替换 | 直接套用 | 换成自己的真实信息和业务术语 |
| 从 5 条到 110 条 | 一次性全用 | 第 1 周 5 条、第 2 周 5 条、第 4 周 20 条 |
| 每次用完 | 用完就忘 | 回头改提示词 + 沉淀模板 |
| 第一次运行 | 信任 AI 自动执行 | 第一次必须先看预览 |
写在最后
写完这篇的时候，我又把萝卜哥的 110 条提示词完整看了一遍。
5 段式结构 = 把"AI 输出随机"变成"AI 输出可控"——这和软件工程的需求文档本质完全一致。
"先预览后执行" = AI Agent 的核心安全线——没有这条，再聪明的 AI 也会变成"不可控的自动化"。
如果你已经用上 WorkBuddy（或者任何 AI 工具）：
- 第一步：选 1 类最常用的（如"个人工作台"）+ 挑 5 条最贴合
- 第二步：用 5 段式结构改写你过去用得最多的 5 个提示词
- 第三步：跑通 5 次 + 每次回头改
- 第四步：扩展到 11 类、110 条
90 天后，你会有一套完全属于你自己的提示词库——比任何通用版本都更精准、更高效。
AI Agent 出的结果好不好，决定权是你投喂给它的东西是否给力。110 条是起点，不是终点。
常见问题 FAQ
WorkBuddy 和 ChatGPT / Claude 有什么区别？
WorkBuddy 是能"接触你的工作系统"的 AI Agent——它能读取日历、任务、邮件、文档、数据库。ChatGPT / Claude 是隔离的 AI——它们只能根据你粘贴的内容回答。所以 WorkBuddy 的提示词必须更严格——因为它的"操作"会真正影响你的工作系统。
这 110 条提示词能直接用在 ChatGPT / Claude 上吗？
大部分能直接用——5 段式结构和"先预览后执行"是通用的。但涉及"读取我的任务"等操作权限的提示词在 ChatGPT / Claude 上无效——因为这些 AI 没有你的数据访问权限。把"读取我..."改为"根据我提供的..."，就能用在通用 AI 上。
5 段式结构和软件工程的需求文档有什么关系？
5 段式 = 需求文档的核心 5 个字段：
- 工作对象 = 需求方
- 可用材料 = 输入数据
- 具体动作 = 业务流程
- 交付物 = 输出物
- 检查规则 = 验收标准
所以 5 段式 = 把"软件工程的需求文档"翻译成"AI 也能读懂的语言"。
怎么判断 AI 的输出能不能直接用？
3 个自检问题：
- 每个数据点都能在材料里找到依据？→ 如果不能，进"待确认区"
- AI 是不是在做"我没让它做的事"？→ 比如"我只让它写周报，它开始改任务状态"
- AI 是不是漏了我说的边界？→ 比如"我说了不要发邮件，它还是发出去了"
任何 1 个不通过 → 不接受输出。
为什么"先预览后执行"这么重要？
3 个真实风险：
- AI 误判数据范围 → 删除了不该删的文件
- AI 误解操作意图 → 邮件发给了错误的客户
- AI 触发了连锁反应 → 自动化被错误启用，污染了数据库
"先预览" = 给 AI 加一道"人工 review"环节——把不可逆操作变成可逆操作。
110 条提示词应该怎么排序使用？
按使用频率排序：
- 最高频（每天用）：个人工作台（001-010）+ 邮件沟通（031-040）
- 中频（每周用）：会议协作（011-020）+ 项目推进（041-050）
- 低频（每月用）：数据表格（051-060）+ 内容市场（061-070）
- 专项（按需用）：招聘团队（071-080）+ 财务采购（081-090）
- 工程专用（开发团队）：研发运维（091-100）+ 自动化工作流（101-110）
新手先从"最高频"开始——90 天后扩展到全部。
怎么把通用提示词改成我团队的专用提示词？
3 个步骤：
- 替换业务术语——把"项目"换成"工单"、"周报"换成"双周 OKR 回顾"
- 增加具体场景——比如周报必须包含"风险预警"、"客户反馈"、"下周重点"
- 加入权限边界——比如"涉及合同金额时必须等财务确认"
改 3-5 次后，每条提示词都变成你团队的"专属模板"。
WorkBuddy 提示词和普通 prompt 的核心区别是什么？
普通 prompt（ChatGPT / Claude） = "给我个答案"——AI 自由发挥 WorkBuddy 提示词 = "给我个答案 + 限制操作"——AI 只能读、不能写（除非预览确认）
WorkBuddy 提示词 = prompt + 权限边界 + 操作规则——这是 AI Agent 时代的核心新规则。
没有 WorkBuddy，能用这 110 条吗？
能——5 段式结构和"先预览后执行"适用于所有 AI 工具。只要你的 AI 工具支持"读写权限分离"（如 ChatGPT 配合自定义 GPTs、Claude 配合 Projects、Cursor 配合 Agent 模式），就能用上。但效果取决于你 AI 工具的"权限精细度"——权限越细，能直接用的提示词越多。
怎么判断 AI 提示词工程到底学得怎么样？
3 个阶段：
- L1 入门：能套用 5 段式改写自己的提示词（覆盖 80% 日常）
- L2 熟练：能根据场景变形（3 段 / 5 段 / 7 段），能识别 AI 输出问题
- L3 精通：能搭建"AI 工作流"（多 AI 协作 + 自动化 + 权限审计），能从 110 条通用版沉淀出 11 条团队专属版
达到 L2 = 你的提示词能力超过 90% 职场人。 达到 L3 = 你可以教别人用 AI。