夜雨聆风AGENT-009 · Day 3 副文 B
网上流传的工作流教程，通常只给你提示词，不解释为什么这样写。
照着用能跑，但遇到你自己的情况就不知道怎么改。
这篇把五个最实用的工作流逐一拆开——不是转述提示词，而是分析每一个设计决策的理由。看懂了逻辑，才能举一反三。
工作流 1：订阅审计
做什么：扫描过去的邮件，找出所有正在扣费的订阅，算出每月总支出，推荐哪些该取消。
关键决策一：为什么扫描 60 天，不是 30 天？
订阅服务大多是月付，但扣费日不统一。如果只扫最近 30 天，很可能漏掉上个月底才扣的费。60 天覆盖了两个完整的月付周期，确保每一笔订阅都至少出现过一次。
年付订阅是个特例——60 天也可能覆盖不到。所以设计好的订阅审计工作流，会额外搜索「annual renewal」「yearly subscription」这类关键词，单独列出年付项目。
关键决策二：为什么「从不打开」比「费用高」更重要的取消依据？
费用高但每天在用的服务，取消了你会难受。费用低但三个月没打开的服务，留着纯粹是惰性。「使用频率」比「费用金额」更能准确判断一个订阅值不值得留。
这个逻辑反映在工作流的分类里：把订阅按「从不打开 / 很少打开 / 正在使用」排序，优先推荐「从不打开」那一组取消，而不是「最贵的」那一组。
国内场景改造：gws 扫描的是 Gmail 扣费通知。如果你用支付宝/微信支付，这些通知在 App 里，不在邮件里。替代方案：月初导出上月支付宝账单（支持 CSV），发给 Agent 让它分析，提示词逻辑完全一致，只是数据来源从邮件变成了账单文件。
工作流 2：账单追踪
做什么：每周一早上，扫描邮件里的账单通知，按紧急程度分四级，重点标出近 3 天到期且没有自动扣款的项目。
关键决策一：为什么分四级而不是直接列清单？
逾期 / 本周到期 / 本月到期 / 自动扣款——这四级对应四种不同的行动要求。
「逾期」需要立刻处理；「本周到期」需要今天确认；「本月到期」是信息性的，扫一眼就行；「自动扣款」根本不需要看，放在最后就是告诉你它已经被处理了。
一个平铺的清单迫使你为每一条做「需不需要处理」的判断。分级之后，你的注意力直接落在最上面的那几条，其余的只是背景信息。
关键决策二：3 天这个阈值怎么来的？
银行转账通常需要 1-2 个工作日到账。3 天是给你留出「发现问题 → 处理问题 → 等待到账」这个完整链路的最小余量。
如果你用的是可以即时到账的支付方式，这个阈值可以改成 1 天。在 Rules 里写明：警报阈值：X 天内到期且无自动扣款，自己调数字。
国内场景改造：国内账单通知格式各异。水电煤通知多半是短信；信用卡还款提醒可能来自银行 App；花呗/白条账单在 App 内。这种场景下，工作流的最佳用法是：你手动整理一份本月账单清单（一个简单的文本列表），发给 Agent，它帮你做分级和提醒逻辑，而不是试图让它自动抓取这些渠道。
工作流 3：预算追踪
做什么：每周五扫描本周的消费记录，按类别汇总，对比预算目标，标出超支的类别。
关键决策一：为什么用邮件收据，而不是连接银行 API？
银行 API 连接涉及 OAuth 授权、数据安全和隐私问题。大多数银行的 API 接口复杂，而且国内银行对第三方接入极不友好。
邮件收据是一个更务实的方案：你在淘宝下单、用微信支付、收快递——每一个都有确认邮件或短信通知发到你的邮箱。这些信息虽然不像银行账单那样完整，但覆盖了大部分消费。
更重要的是，用邮件收据不需要给 Agent 任何金融账户的访问权限，边界更清晰。
关键决策二：「无评判语气」这条 Rule 有什么实际作用？
AI 有一种习惯：在分析类报告里加入主观评价，比如「本周餐饮支出明显偏高，建议控制」「购物类消费需要反思」。
这些评语没有帮助，只有冒犯。你知道自己花了多少钱，不需要 AI 来教育你。
在 Rules 里写明「输出只包含数字和事实，不加任何主观评价或建议」，工作流的输出会干净很多——一张表，数字，你自己判断。
自定义预算基准线：工作流默认的预算数字（比如餐饮每月 200 块）是示例，不是建议。在 references/ 文件夹里放一个 my-budget.md，写上你自己的每类预算数字，SKILL.md 里引用这个文件，每次运行都用你的实际数字对比。
工作流 4：周计划生成
做什么：每周日晚上，读取下周日历，生成一份结构化的周计划，标注重要事项和需要保留的深度工作时间块。
关键决策一：为什么是周日晚上，不是周一早上？
周一早上你已经在执行模式里了——第一个会议可能九点就开始，你没有时间和心情做完整的周规划。
周日晚上是规划的正确时机：下周的全貌已经清晰（日历基本定了），但你还没开始执行，思维处于「规划者」而不是「执行者」的状态。这个时间差，让你能做出真正的优先级决策，而不是在执行压力下的临时应对。
关键决策二：「每天保留 2 小时深度工作」这个硬性约束从哪来？
这是 Cal Newport 在《深度工作》里反复强调的数字——对大多数知识工作者，每天能进入真正深度专注状态的时间上限大约是 4 小时，2 小时是一个保守但可持续的目标。
在 Rules 里加这条约束，意味着 Agent 在生成周计划时，会主动检查每天的日程，如果没有 2 小时的连续空白，会标红警告，而不是给你一份看起来满的计划。
飞书日历改造：飞书有完整的开放 API，可以替代 gws 读取日历数据。接入方式：在飞书开放平台创建一个自建应用，获取读取日历的权限，把 API 调用方式写进 TOOLS.md。工作流逻辑完全一样，只是把 gws 的日历命令换成飞书 API 的调用格式。
工作流 5：48 小时日历预警
做什么：每天早上 8 点和晚上 6 点，扫描未来 48 小时的日历，按重要性三级分类，给出每个会议的准备建议。
关键决策一：为什么要分红/黄/绿三级？
不同类型的会议，准备成本差距很大。
内部例会（绿）：站会、周同步——大概率不需要任何准备，看一眼日程知道要讲什么就行。
需要准备的会议（黄）：有正式议程的工作会议、1:1——花 10-15 分钟准备一下，效果明显更好。
高优先级（红）：外部客户会议、演示、有高层参与的会议——不准备是有代价的。
三级分类让你一眼看出哪些会议需要现在就做准备，而不是对所有 12 个会议都产生同等焦虑。
关键决策二：「外部会议默认高优先级」的逻辑
和公司外部人员的会议，无论内容是什么，都有一个共同特征：你的准备状态直接影响外部对你和公司的印象。内部会议准备不足顶多被同事说句没准备好，外部会议准备不足可能影响客户关系或合作机会。
所以不管会议内容如何，只要对方是外部人员，就默认红色优先级，触发准备提醒。这不是过度紧张，是把有限的准备时间分配给影响最大的场合。
加入自定义规则：在 references/ 里放一个 important-people.md，列出对你重要的人名或公司名。工作流读取这个文件，凡是日历里出现这些名字的会议，不管类型是什么，直接升为红色优先级。这个文件你自己维护，不需要改 SKILL.md 本身。
五个工作流看下来，设计决策的模式是一致的：时间窗口的选择基于真实的业务逻辑、分类方式对应不同的行动要求、硬性约束保护你的核心资源、数据来源在安全和便利之间取权衡。
把这个思路带进你自己的工作流设计里，而不只是复制别人的提示词。
