第 26 章 岗位路线图：把 buddyme 用成你的岗位伙伴
岗位应用不应从「这个岗位有哪些提示词」开始，而应从三个问题开始：哪些工作重复发生，哪些产物有稳定标准，哪些决定必须由人承担责任。
本章为产品经理、运营市场、销售售前、HR 行政、财务法务、研发 IT 六类岗位各画一张路线图：从典型痛点出发，给出 buddyme 的具体用法与第一周的行动清单。
岗位应用的四级成熟度
同一个岗位，用 buddyme 的深度可以差出四个层次。不是用得越深越好，而是找到与你的工作性质匹配的那一级：
| 等级 | 工作方式 | 典型形态 | 进入下一级的条件 |
|---|---|---|---|
| L1 单次辅助 | 人给完整材料，AI 生成草稿 | 纪要、摘要、表格、PPT | 输出可验收，连续成功 3 次 |
| L2 固定模板 | 使用任务卡和标准输出 | 周报、复盘、客户简报 | 输入字段和验收规则稳定 |
| L3 工作流 | Skill、资料库、连接器协作 | 内容流、知识流、报表流 | 有负责人、日志和异常处理 |
| L4 团队能力 | 项目、专家团和自动化运行 | 部门级数字员工 | 权限、成本和资产治理到位 |
要求：L1-L4 四级表格的可视化版本（阶梯图或对照卡片），由设计制作，无需截图
每一级都有明确的升级条件，不是时间到了就自然升上去的：
- L1 → L2：核心是"重复"。当你发现自己第三次输入几乎相同的指令，就该把它固化成任务卡；
- L2 → L3：核心是"连接"。当单个模板开始需要从多个系统取数据、输出要落到多个去处，就到了引入 Skill 和连接器的时候；
- L3 → L4：核心是"治理"。当这套流程不再只服务你一个人，权限、成本、责任人这些组织问题就走到了技术问题前面。
每个岗位都应从 L1 的低风险任务开始。不是所有任务都要进入 L4；低频、差异大或责任重的工作，保持"AI 辅助 + 人工决策"更合理。成熟度的高低，不看工具用得多花哨，而看一条朴素的检验：这套做法换一个人接手，能不能照着跑起来。能，说明它已经从"你的技巧"变成了"岗位的资产"。
本章后面各节，按岗位给出典型痛点、具体用法和第一周的起步路径，均从 L1 起步、指向 L3。
产品经理：证据的搬运工，判断的主人
产品经理的日常，一半在收集证据（用户说什么、竞品在做什么、数据在变什么），一半在把证据组织成判断（优先级、方案、路线图）。前者极度耗时，后者必须自己拿主意——这正好是 buddyme 最理想的分工线。
典型痛点
- 用户访谈做了十场，录音转写堆在文件夹里，"用户原话"要靠回忆拼凑；
- 竞品信息散在收藏夹和截图里，三个月后要做对比表时全都过时了；
- 版本复盘时想不起当时为什么这么决策，缺一份当时的证据快照。
buddyme 的用法
| 场景 | 输入 | 交付物 |
|---|---|---|
| 用户访谈整理 | 录音转写、访谈提纲 | 痛点、原话、待验证问题 |
| 反馈聚类与版本复盘 | 工单、评论、埋点摘要 | 问题分类、影响范围、证据表 |
| 竞品证据库 | 官网、定价、更新日志、评论 | 可追溯对比表和定期简报 |
| 产品发现工作流 | 反馈、数据、竞品、业务目标 | 机会地图和决策材料 |
要求：任务运行中的对话区，可见输入的访谈整理提示词与 buddyme 产出的痛点/原话/假设列表，无需标注
以访谈整理为例，提示词可以这样写：
这是 3 场用户访谈的转写文字。请整理成统一格式：
1. 每位用户的核心痛点（带原话引用）；
2. 跨用户重复出现的问题（标注出现在几场）；
3. 与我们现有方案的冲突点；
4. 值得下轮访谈验证的 3 个假设。
区分"用户明确说的"和"我推测的"，不要混在一起。最后一句是关键——产品决策最怕的不是没信息，而是把推测当成用户原话。
先用起来的第一周
- 第一天：把手头最新一份访谈转写丢给 buddyme，跑上面那段提示词，看看产出能不能直接进你的需求文档；
- 第三天：建一个竞品对比表（3 个竞品、5 个维度起步），让 buddyme 填初稿，你补内部信息；
- 第五天：把本周的工单导出交给它做聚类，输出"本周用户最在意的 3 件事"。
一周下来，你会得到两三份能直接用的证据材料，以及一个判断：你的证据收集工作里，哪些适合长期交给这位伙伴。
运营与市场：一篇内容，十个平台
运营与市场是内容产出密度最高的岗位：一篇长文要拆成十个平台的素材，一个选题要配标题、封面、多版本文案。产量压力之下，最痛的不是写，而是"改写"和"适配"——同一件事说十遍，每一遍还得不一样。
典型痛点
- 一篇公众号长文改小红书笔记，改到手软，还容易越改越走样；
- 标题想不出新的，翻来覆去用老三样；
- 选题靠临时刷平台找灵感，没有沉淀，下周又要从零开始。
buddyme 的用法
| 场景 | 输入 | 交付物 |
|---|---|---|
| 内容改写、素材盘点 | 已审长文、图片目录 | 平台草稿、素材清单 |
| 标题、封面与平台适配 | 已审事实包、品牌规范 | 标题池、公众号封面、小红书长图、口播稿 |
| 选题与内容中台 | 资讯源、评论、品牌规范、历史内容 | 候选池、证据表、内容日历、复盘库 |
| 内容专家团 | 热点、产品资料、渠道数据 | 研究、脚本、分镜、多平台草稿、复盘 |
要求：结果区文件树，可见同一内容生成的多平台版本文件（公众号/小红书/微博等），无需标注
多平台适配的提示词示例：
把这篇已定稿的公众号长文改写成小红书笔记。
要求：
1. 保留所有事实和数据，不得新增或夸大；
2. 标题给 3 个备选，每个不超过 20 字；
3. 正文用短段落，适合手机阅读，控制在 500 字内；
4. 标注出 5 个适合做封面图的句子；
5. 结尾给一个互动引导问题。注意"已定稿"三个字——让 buddyme 只做形态转换，不做事实增删。改写类任务的信任，就是这样一次次"没给你加戏"攒出来的。
先用起来的第一周
- 第一天：挑一篇表现最好的旧文，跑上面的改写提示词，产出第一份小红书草稿；
- 第三天：让 buddyme 为下一篇文章生成 10 个标题备选，并按风格分组（悬念型 / 数字型 / 对比型），你只做挑选；
- 第五天：把手头的内容排期表交给它，请它按"平台 × 选题类型"盘点缺口，输出下两周的内容日历草案。
运营岗位升级最快：第二周开始，你就会想把"每周素材盘点"和"标题池"固化成任务卡——那就是从 L1 走向 L2 的时刻。
销售与售前：把时间还给客户
销售的时间花在客户身上才值钱，可现实中大量时间耗在会前准备和会后整理上：客户资料临场搜、会议纪要拖三天才发、方案文档从旧项目里东拼西凑。这些恰恰是 buddyme 能整段接走的部分——而这个岗位对准确性要求极高，每一处人工检查点都不能省。
典型痛点
- 拜访前想快速摸清客户背景，搜出来的资料真假难辨、新旧混杂；
- 会后凭记忆写纪要，客户随口提的需求细节全丢了；
- 方案初稿要得急，从历史方案里改，改到一半发现口径对不上。
buddyme 的用法
| 场景 | 交付物 | 风险点 |
|---|---|---|
| 会后纪要 | 需求、异议、待办、负责人 | 把推测写成客户承诺 |
| 客户研究 | 画像、公开动态、机会假设 | 使用过时或同名公司资料 |
| 方案与演示 | 方案大纲、演示脚本、FAQ | 虚构能力、价格和案例 |
| 跟进工作流 | CRM 草稿、提醒、材料更新 | 未确认写入和外发 |
要求：结果区预览状态，可见生成的客户调研简报文档结构，无需标注
会前客户研究的提示词示例：
调研 [公司名称]（注意核实：注册地 [城市]、行业 [行业]，避免同名公司）。
输出：
1. 公司基本情况（主营业务、规模、近期动态）；
2. 与我们产品相关的业务场景假设；
3. 可能的切入点，标注哪些是公开信息、哪些是推测；
4. 每条信息附来源链接和日期。
找不到的信息直接说没有，不要硬凑。销售场景的铁律：buddyme 只产出草稿和假设，所有对外的承诺、报价和事实，发出前必须过你的眼睛。它的价值是让你准备得更充分，不是替你担保。
先用起来的第一周
- 第一天：选一位下周要拜访的客户，跑上面的调研提示词，花十分钟核验产出；
- 第三天：把最近一次会议录音转写交给 buddyme，按"需求 / 异议 / 待办 / 负责人"四栏出纪要，当天发给与会者确认；
- 第五天：让 buddyme 基于你最近一份成交方案，生成一份可复用的方案骨架模板，标注哪些段落需要每次更新。
一周后你会发现：变化最大的不是省下的时间，而是响应速度——纪要当天出、方案隔天有初稿，客户感知到的专业度是完全不同的。
HR 与行政：让制度知识活起来
HR 和行政是公司的"制度守门人"：员工的问题十有八九在制度文件里有答案，但翻文件费时，凭记忆回答又怕说错版本。这个岗位用 buddyme 的核心思路，是让制度知识"能被问到、答得准、可追溯"，同时守住一条红线——涉及人的判断和决定，永远留给人做。
典型痛点
- 同样的问题（年假怎么算、报销流程、试用期规定）每个月都要回答几十遍；
- 制度文件一更新，旧版 FAQ 就成了误导源；
- 入职材料准备靠人肉清单，漏一项新员工要多跑一趟。
buddyme 的用法
| 场景 | 推荐做法 | 必须控制 |
|---|---|---|
| 制度摘要、材料检查 | 基于批准文件生成 FAQ | 版本日期和适用范围 |
| 入职与培训 | 生成学习路径、课件和清单 | 员工数据最小化 |
| HR 知识助手 | 连接制度库回答常见问题 | 权限、引用与升级人工 |
| 人事流程辅助 | 提醒、材料完整性、报表 | 不自动做雇佣决策 |
要求：对话区中提问与 buddyme 基于制度文档的回答，可见引用来源，无需标注
制度问答的提示词示例：
基于《员工手册》2026 年 3 月版（文件已上传），回答以下问题：
员工入职满一年后年假有几天？
要求：
1. 引用具体条款编号；
2. 如果手册中有例外情况（如司龄分段、岗位差异），一并列出；
3. 如果手册中没有明确规定，直接说"制度未覆盖，建议咨询 HRBP"，
不要给出通用做法。这段提示词里最重要的是第 3 条——制度问答的信任建立在"不知道就说不知道"上，一旦它编造过一次答案，员工就不敢再用了。
先用起来的第一周
- 第一天：上传现行员工手册，跑上面的问答提示词，测试你最常被问到的 5 个问题；
- 第三天：让它基于手册生成一份"新员工最常问 30 题"FAQ 初稿，你逐条核对后挂到内部文档；
- 第五天：把入职材料清单交给它，做成可以按岗位自动勾选的检查表模板。
记得给所有产物打上制度版本号。制度一更新，先跑一遍"新旧版本差异"，再决定哪些 FAQ 要重做——版本控制是这个岗位用好 AI 的第一课。
财务与法务：它找全，你看准
财务与法务是全公司对准确性要求最苛刻的岗位：一个数字、一个条款的偏差，代价可能是真金白银，甚至法律责任。这决定了这个岗位使用 buddyme 的姿态——大胆用它做"核对和整理"，谨慎让它碰"判断和签署"。它的最佳位置是缩短机械工作的时间，把专业精力留给真正的判断。
典型痛点
- 发票、账单、合同，格式五花八门，人工录入和对账占满月初月末；
- 合同审阅时，要在一百页文档里找出与标准模板偏离的条款；
- 每次月结都是一次大型材料搬运：从五六个系统导数据、拼表格、核口径。
buddyme 的用法
| 财务场景 | 法务场景 | 人工关口 |
|---|---|---|
| 发票识别、账单整理 | 条款提取、版本对照 | 金额与原文复核 |
| 预算差异、异常清单 | 标准条款偏离清单 | 口径和风险判断 |
| 月结材料流水线 | 合同知识库、审阅工作台 | 专业人员签字 |
| 受控系统回写 | 合同流程提醒 | 付款、申报、签署确认 |
要求：结果区打开的 Excel 台账预览，可见发票字段列与汇总行，无需标注
合同条款比对的提示词示例：
对比这份供应商合同与我们的标准模板（两份文件已上传）。
输出一份偏离清单：
1. 逐条列出与模板不一致的条款，标注双方版本原文；
2. 按风险高低排序（付款条件、责任限制、终止条款优先）；
3. 只做差异呈现和风险提示，不修改条款、不给出法律意见。
每一处差异必须能定位到原文页码和条款号。两个岗位共同的检查习惯：让 buddyme 负责找全，你负责看准。它列出的每一条差异都要能回溯到原文——凡是定位不到原文位置的结论，一律当作没有。
先用起来的第一周
- 第一天：拿一叠已处理的发票（扫描件）让它批量识别关键字段，与你的手工结果比对准确率；
- 第三天：选一份即将审阅的合同，跑上面的比对提示词，用它当"第二双眼睛"扫一遍你可能漏掉的偏离；
- 第五天：把上个月结的取数和拼表过程写成一个任务卡，让 buddyme 按卡执行一遍，和正式报表核对。
第一天建立的"准确率印象"很重要：哪个环节它做到了零差错，就可以逐步放手；哪个环节错得多，就保持人工。这两个岗位的 AI 应用不是信任问题，是程序问题——核对留痕、关口明确，效率就上来了。
研发与 IT：不知疲倦的初级同事
研发与 IT 同学对 AI 不陌生，但多数用法停留在"问代码问题"。真正值得开发的，是把 buddyme 当成一位不知疲倦的初级同事：代码理解、测试补位、文档补课、巡检值守——这些"重要但没人爱干"的活，正好是它的主场。
典型痛点
- 接手一个没有文档的老项目，光读懂结构就要一周；
- 测试覆盖常年欠账，补测试的优先级永远排在开发后面；
- IT 巡检和告警摘要靠人肉值守，夜里告警没人看得懂上下文。
buddyme 的用法
| 场景 | 交付物 | 检查点 |
|---|---|---|
| 代码理解、技术文档 | 架构图、README、模块清单 | 与实际代码一致 |
| 测试与缺陷分析 | 测试矩阵、复现步骤、修复建议 | 测试通过、代码评审 |
| 开发工作流 | 分支改动、CI 诊断、发布说明 | 合并和部署确认 |
| IT 自动化 | 巡检、告警摘要、知识库 | 生产权限和事故响应 |
要求：任务运行中对代码库提问、buddyme 输出技术文档的对话区，无需标注
老项目代码梳理的提示词示例：
梳理这个仓库（已授权访问）。
输出：
1. 一页架构说明：模块划分、依赖关系、入口在哪；
2. README 初稿：如何跑起来、如何跑测试；
3. 五个"新人最容易踩的坑"（基于代码中的注释、TODO 和提交历史）；
4. 标注哪些结论是从代码直接读出的，哪些是你的推测。两条使用纪律：给 buddyme 的代码权限按"只读优先"原则授予，生产环境的写操作必须留在人手里；它产出的文档和测试，走和人类同事一样的评审——代码评审的门槛不因作者是 AI 而降低。
先用起来的第一周
- 第一天：挑一个你最怕接手的模块，跑上面的梳理提示词，验证它对你们项目的理解准确度；
- 第三天：选一个测试覆盖薄弱的函数，让它补一组单元测试，走正常评审流程合入；
- 第五天：把本周的 CI 失败日志交给它做归因摘要，输出"失败原因分类 + 高频故障点"。
研发岗位的进阶路径最为顺滑：第一周验证的代码梳理、测试补位、日志归因三件事，第二周就能封装成团队共享的 Skill——这正是从 L2 走向 L3 的路。
部门推广：从一个人到一个团队
个人用得好，不等于部门推得开。部门推广 buddyme 最常见的失败方式，是发一封"大家都可以用 AI 了"的邮件，然后石沉大海。有效的推广路径只有一条：每个岗位先选一个场景，把它跑成可复制的样板，再由点及面。
每个岗位先选一个场景，填写下面这张卡：
| 项目 | 填写内容 |
|---|---|
| 原流程 | 谁在什么时间，用哪些系统，花多久 |
| 输入 | 文件、字段、权限、质量问题 |
| 输出 | 文件、系统记录、通知对象 |
| 验收 | 准确性、完整性、时效和风险 |
| 人工关口 | 谁确认，什么情况下必须暂停 |
| 指标 | 基线、目标值、观察周期 |
| 负责人 | 业务、技术、资产维护人 |
要求：部门内共享的 buddyme 工作空间或任务列表界面，可见多人复用的任务结构，无需标注
填写时有三个诀窍：
- 首选"每周都疼"的场景：原流程一栏写不出来的，说明这个场景要么不够频繁、要么没有被认真度量——都不是好起点。好起点是那种"每周五下午大家都皱着眉做"的事；
- 指标一栏要诚实地写基线："现在花 3 小时"和"目标 40 分钟"必须都有数字。没有基线的改进，最后谁也说不清到底有没有效果，推广也就没有下一批受众；
- 人工关口一栏由岗位负责人自己填：这既是风险控制，也是心理安全——知道自己随时能踩刹车，人才敢把活交给 AI。
推广的节奏建议按"1 → 3 → 9"走：第一个月只做一个岗位一个场景，把任务卡跑顺、指标立住；第二个月让这个岗位的同事各认领一个相邻场景（此时有样板可抄，阻力最小）；第三个月跨岗位复制，用第一批的实测数据（"周报从 3 小时缩到 40 分钟"）代替动员口号。
岗位落地的终点不是"每个人都会问 AI"，而是形成一批能被新人复用、由负责人维护、出了问题能追溯的标准工作流。