By Tag: project-management

管理包含多个并行工作流的复杂项目令人筋疲力尽。你不断切换上下文，跨工具追踪状态，手动协调交接。 这个用例实现了一种去中心化的项目管理模式——子智能体自主处理任务，通过共享状态文件进行协调，而不是依赖中央调度器。 痛点 传统的调度器模式会产生瓶颈——主智能体变成了交通警察。对于复杂项目（多仓库重构、研究冲刺、内容流水线），你需要能够并行工作、无需持续监督的智能体。 功能 去中心化协调：智能体读写共享的 STATE.yaml 文件 并行执行：多个子智能体同时处理独立任务 无调度器开销：主会话保持精简（CEO 模式——仅负责策略） 自我文档化：所有任务状态持久化存储在版本控制文件中 核心模式：STATE.yaml 每个项目维护一个 STATE.yaml 文件作为唯一真相源： # STATE.yaml - 项目协调文件 project: website-redesign updated: 2026-02-10T14:30:00Z tasks: - id: homepage-hero status: in_progress owner: pm-frontend started: 2026-02-10T12:00:00Z notes: "正在处理响应式布局" - id: api-auth status: done owner: pm-backend completed: 2026-02-10T14:00:00Z ...

你刚开完一个 45 分钟的团队电话会议。现在你需要写总结、提取行动项、分发给 Jira、Linear 或 Todoist——手动操作。等你做完，下一个会议就开始了。如果纪录一落地，你的智能体就能处理所有这些呢？ 这个用例将任何会议记录转化为结构化笔记，并自动在你的项目管理工具中创建任务。 痛点 会议纪要是枯燥但关键的工作。大多数人要么跳过（从而丢失上下文），要么花 20 多分钟来写。行动项因为存在于某人的脑子里或被埋在聊天记录中而被遗忘。这个智能体消除了"我们讨论了这个问题"和"它已被跟踪和分配"之间的差距。 功能 监视新的会议记录（通过 Otter.ai 导出、Google Meet 记录、Zoom 会议摘要，或简单的粘贴到聊天中） 提取关键决策、讨论主题和行动项及其负责人和截止日期 创建任务到 Jira、Linear、Todoist 或 Notion——分配给正确的人，附带会议上下文 发布摘要到 Slack 或 Discord，使整个团队都有记录 跟进——可选地在截止日期前通过定时提醒催办相关人员 所需技能 Jira、Linear、Todoist 或 Notion 集成（用于创建任务） Slack 或 Discord 集成（用于发布摘要） 文件系统访问（用于读取记录文件） 定时 / cron（用于跟进提醒） 可选：Otter.ai、Fireflies.ai 或 Google Meet API 用于自动获取记录 设置方法 选择你的记录来源。最简单的方法是将记录直接粘贴到聊天中。如需自动化，可设置文件夹监视或 API 集成。 提示 OpenClaw： 我刚开完一个会议。以下是记录： [粘贴记录或指向文件路径] 从这次会议中提取： 1. 讨论的关键主题 2. 做出的决策 3. 行动项（负责人 + 截止日期） 对于每个行动项，在我的任务管理器中创建一个任务。 然后，将摘要发布到 #meetings Slack 频道。 试试看： 这是我的会议记录文件。为我整理并创建任务： ~/meetings/standup-2025-01-15.txt 设置自动提取： 监视 ~/meetings/ 目录中的新 .txt 文件。 当出现新文件时，处理记录，提取行动项，创建任务，发布摘要， 并将文件移动到 ~/meetings/processed/。 跟进： 检查我本周创建的所有会议行动项。 对于即将到期或已逾期的任务，给我一个列表。 小贴士 真正的价值不在于摘要——而在于自动任务创建。不转化为已跟踪任务的会议笔记只是文档表演。 将此与 Todoist 任务管理器 用例搭配使用，可全面了解智能体创建的任务。 Zoom 或 Google Meet 的 VTT/SRT 字幕文件作为输入效果很好——它们包含时间戳，有助于智能体识别发言者。 从简单的开始（粘贴记录，获取摘要），逐步自动化。在验证输出质量之前，不要过度设计流水线。 相关链接 Otter.ai API Jira REST API Linear...

传统的看板是静态的，需要手动更新。你会忘记移动卡片，在会话之间丢失上下文，无法跟踪状态变更背后的"原因"。项目在缺乏清晰可见性的情况下漂移。 这个工作流用事件驱动的系统取代看板，自动跟踪项目状态： • 将项目状态存储在具有完整历史的数据库中 • 捕获上下文：决策、阻塞项、下一步、关键洞察 • 事件驱动更新："刚完成 X，阻塞在 Y" → 自动状态转换 • 自然语言查询："[项目] 的状态如何？"，"为什么我们在 [功能] 上转型了？" • 每日站会摘要：昨天发生了什么，今天计划什么，什么阻塞了 • Git 集成：将提交链接到项目事件以实现可追溯性 痛点 看板对于独立开发者来说并不好用，原因有三： 你必须在编写代码时停下来更新卡片 默认情况下，状态变更没有附加上下文（"为什么我们把这个移到进行中？"） 孤立的看板不反映你的实际工作——Git 提交、松弛对话和设计决策 所需技能 文件系统访问 可选的 Git 集成 可选的 Discord/Telegram 用于每日摘要 设置方法 告诉 OpenClaw 你想要事件驱动的项目跟踪： 我希望你使用事件驱动的日志而不是看板来跟踪项目状态。 每次我完成某事、改变方向或遇到阻塞时，记录事件。 定义你的事件类型： 使用这些事件类型： - feature_started - feature_completed - blocker - decision - priority_change - bug_found - bug_fixed 每个事件记录： - 时间戳 - 项目/功能名称 - 事件类型 - 描述 - 关联的提交或链接（如果适用） 设置每日摘要： 每天早上，给我一份项目状态摘要： - 自昨天以来完成的事项 - 当前阻塞项 - 今天的推荐优先级 - 任何需要注意的趋势 使其成为习惯： 当我说"状态更新"时，提示我记录当前状态。 为每个事件使用一致的格式，以便我可以查询它们。 小贴士 避免系统过度设计。目标是少操心项目管理，而不是多操心。 使用自然语言。不要创建严格的命令——只需自然地对你的助手说话。系统会捕获一切。 相关链接 事件溯源模式 为什么看板对独立开发者无效 ...