AI-First 产品经理实录：我的 Agent 编队与无人值守工作流

先看一组数字

最近整理工作记录时，我统计了过去四个月的使用情况：

  • 81 个 Codex 工作线程（每个对应一个独立任务或项目）；
  • 峰值时期一周 22 个活跃会话；
  • Cherry Studio 里维护着 17 个项目专属 Agent；
  • 沉淀出多个可复用的 Skill（邮件草稿、周报生成、任务追踪……）。

我不是工程师，我是一名 AI 产品经理。但这些数字背后的工作方式，可能比任何一篇方法论文章都更”AI-First”。

第一步：给 Agent 一个身份

一切从一个简单的配置开始。我的全局 Agent 指令里写着：

  • 助手名字：Friday
  • 称呼我为 Dylan
  • 默认中文，除非任务明显需要其他语言
  • 简洁直接，少客套
  • 交付物能用 HTML 就不用 Markdown

最后一条尤其重要——它来自我真实的挫败感：让 Agent 生成周报表格，Markdown 表格贴到邮箱里格式全乱。反复纠正几次之后，我意识到不该每次口头纠正，而该把偏好写进制度。于是”HTML 优先”进入了全局指令，从此所有交付物默认邮件友好。

这是我的第一个心得：AI-First 不是”多用 AI”，而是把你的偏好、习惯、规范，逐步固化成 Agent 可执行的制度。

第二步：一个项目一个 Agent

我的 Agent 编队按项目线组建，每个 Agent 只服务一个领域：

  • 周报工具人——周报生成专用；
  • 产品反馈——用户反馈收集与分类；
  • 深圳本地化项目改造——ToB 交付项目专属上下文；
  • WorkBuddy 生态合作、火山 Agent Mesh——渠道合作各一个；
  • 深知可信搜索 / 可信咨询 / 可信 PPT——每个 Skill 产品一个，专门做对应产品的优化。

好处是上下文隔离：每个 Agent 的记忆、知识库、指令都是为那条业务线定制的，不会互相污染。我在哪个项目上工作，就唤醒哪个 Agent，它带着那个项目的全部背景。

周报流水线的三次进化

周报是产品经理的例行公事，也是我改造得最彻底的一条流程。它经历了三个版本：

V1：手工时代。 每天整理日报素材，周五合并成周报。痛苦且容易遗漏。

V2：Agent 辅助。 日常把工作记录追加到一个 markdown 文件，周五让 Agent 归并成”本周总结/下周计划”。好了一些，但每天的记录仍然是手工的。

V3：会话即记录。 有一天我突然想通了——我的工作本身就发生在 Agent 会话里，会话记录就是最完整的工作日志。于是流程变成：周五把这一周活跃过的会话 ID 发给 Agent，它逐个读取、去重、按项目线归并，生成周报初稿。

从那以后，我再也不”写”周报了。数据也顺手自动化：写周报前，一个定时任务会在 17:30 静默触发数据采集——Agent 自己跑采集脚本、确认成功、拉取数据，失败也只记在记忆里，不打扰我。等我坐下来写周报时，数据已经躺在仓库里了。

让 AI 当评审员：14 篇文案的排序

公司征集了一批产品文案，需要评审排序。我的做法不是自己逐篇读，而是设计了一套 AI 评审机制——而这个机制本身迭代了三轮：

  1. 第一版：AI 给出排序。我看了一眼反馈：“有点太简单了，还是得说明理由，最好有评分机制。”
  2. 第二版：每维度 5 分制。区分度不够。
  3. 第三版：5 个维度 × 每维 10 分——案例质量、创意亮点、表达清晰度、实用价值、客户展示价值——满分 50，表格化 HTML 邮件直接可发。

最终产出了 14 篇的完整评分、排序和推荐名单。人工评审核对个别争议项即可。

注意我做的事：我不是在用 AI，我是在设计评审制度。AI 只是执行器，评分维度、分制、区分度、输出形态，每个产品决策都是我的。

用 AI 校对自己的理解

还有一个我特别推荐的习惯：让 AI 复核你对关键信息的理解。

有一次和老板开完产品策略会，我把钉钉听记的原始日志和整理出的纪要一起丢给 Agent：“看看有没有我理解错的或者漏了的工作。”

结果真找到了好几处理解偏差：我把”垂直领域”（税务、公积金、社保这些）记成了”专利领域”；把 MCP 上架的目的理解为功能覆盖，实际核心目的是获得曝光。这些偏差如果不修正，接下来一周的工作方向就会跑偏。

会议听记会有噪声，人脑过滤噪声时会引入偏差，而 AI 对照原始文本复核的成本几乎为零。向上对齐的准确性，是执行力的地基。

把重复劳动沉淀成 Skill

最后一次出现同样的麻烦，就是该写个 Skill 的信号。

我的经典案例是邮件草稿：用命令行邮件客户端保存草稿时，总会在草稿箱里产生重复副本。第一次我手动清理；第二次我让 Agent 清理；第三次我说：

“能不能基于这个命令行邮件客户端做个 Skill？保存草稿可能是我之后经常要干的事。”

于是有了 himalaya-mail-drafts：保存前查重、保存后复查、去重保一封、默认不发、留 .eml 备份。后来”周报表格用 HTML”、“邮件末尾自动带签名”这些规则也逐条加了进去。

之前我写过一篇跨会话任务记忆的设计，思路一脉相承：一次性的纠正 if 出现第二次，就值得变成制度；制度 if 反复被执行，就值得变成 Skill。

这套工作方式的边界

最后说说不那么光鲜的部分：

  • 判断不能外包。 AI 给的优化清单，我会一条一条过，用”现在能跑说明没问题”否决大量理论性风险。全盘接受 AI 建议的人，会被建议淹没。
  • 基础设施要自己扛。 高强度使用 Agent 的前提是网络、代理、VPN 这些底层设施稳定。我花过整整两天排查代理链路——那两天没有任何”产出”，但换来了之后每天十几个会话的顺畅。
  • 保密与边界。 公司内部数据用内部工具跑，公开素材才进个人工作流。这个边界必须清晰。

写在最后

四个月 81 个线程，回头看，真正值钱的不是任何一个具体产出，而是这条不断进化的循环：

遇到麻烦 → 设计流程 → 流程自动化 → 偏好固化成制度 → 制度沉淀成 Skill。

每转一圈，我的”固定成本”就少一点，留给判断和创造的时间就多一点。AI-First 的本质不是让 AI 替你工作，而是把你自己的工作方式，逐步编译成一套可以无人值守运行的系统。