项目状态管理系统：事件驱动的看板替代方案
传统的看板是静态的，需要手动更新。您会忘记移动卡片，在会话之间丢失上下文，无法追踪状态变化的"原因"。项目在缺乏清晰可见性的情况下逐渐失控。
此工作流程用事件驱动的系统取代看板，自动追踪项目状态：
• 在数据库中存储项目状态及完整历史 • 捕获上下文：决策、阻碍、下一步、关键洞察 • 事件驱动更新："刚完成 X，被 Y 阻塞" → 自动状态转换 • 自然语言查询："[项目] 的状态是什么？"，"为什么我们要在 [功能] 上 pivot？" • 每日站会摘要：昨天发生了什么，今天计划做什么，什么被阻塞了 • Git 集成：将提交链接到项目事件以实现可追溯性
痛点
看板会变得过时。您浪费时间更新卡片而不是做工作。上下文丢失——三个月后，您不记得为什么做出关键决策。代码变更与项目进度之间没有自动关联。
功能介绍
不是拖动卡片，而是与您的助手聊天："完成了认证流程，开始做仪表板。"系统记录事件、更新项目状态并保留上下文。当您问"仪表板进行得怎么样？"时，它会给您完整的故事：完成了什么，下一步是什么，什么在阻塞您，以及为什么。
Git 提交会自动扫描并链接到项目。您的每日站会摘要会自动生成。
所需技能
postgres或 SQLite 用于项目状态数据库github（gh CLI）用于提交追踪- Discord 或 Telegram 用于更新和查询
- 定时任务用于每日摘要
- 子代理用于并行项目分析
如何设置
- 设置项目状态数据库：
sql
CREATE TABLE projects (
id SERIAL PRIMARY KEY,
name TEXT UNIQUE,
status TEXT, -- 例如 "active", "blocked", "completed"
current_phase TEXT,
last_update TIMESTAMPTZ DEFAULT NOW()
);
CREATE TABLE events (
id SERIAL PRIMARY KEY,
project_id INTEGER REFERENCES projects(id),
event_type TEXT, -- 例如 "progress", "blocker", "decision", "pivot"
description TEXT,
context TEXT,
timestamp TIMESTAMPTZ DEFAULT NOW()
);
CREATE TABLE blockers (
id SERIAL PRIMARY KEY,
project_id INTEGER REFERENCES projects(id),
blocker_text TEXT,
status TEXT DEFAULT 'open', -- "open", "resolved"
created_at TIMESTAMPTZ DEFAULT NOW(),
resolved_at TIMESTAMPTZ
);创建 Discord 频道用于项目更新（例如 #project-state）。
指示 OpenClaw：
text
您是我的项目状态管理器。不是看板，我会通过对话的方式告诉您我在做什么。
当我说类似这样的话时：
- "完成了 [任务]" → 记录 "progress" 事件，更新项目状态
- "被 [问题] 阻塞" → 创建 blocker 条目，更新项目状态为 "blocked"
- "开始 [新任务]" → 记录 "progress" 事件，更新当前阶段
- "决定 [决定]" → 记录 "decision" 事件，包含完整上下文
- "转向 [新方法]" → 记录 "pivot" 事件，包含原因
当我问时：
- "[项目] 的状态是什么？" → 获取最新事件、blocker 和当前阶段
- "为什么我们决定 [X]？" → 搜索事件中的决策上下文
- "什么在阻塞我们？" → 列出所有项目中打开的 blocker
每天早上 9 点，运行定时任务来：
1. 扫描过去 24 小时的 git 提交（通过 gh CLI）
2. 根据分支名称或提交消息将提交链接到项目
3. 在 Discord #project-state 发布每日站会摘要：
- 昨天发生了什么（事件 + 提交）
- 今天计划做什么（基于当前阶段和最近的对话）
- 什么被阻塞了（打开的 blocker）
当我在规划 sprint 时，生成子代理来分析每个项目状态并提出优先级建议。- 与您的工作流集成：只需自然地与您的助手谈论您正在做的事情。系统会捕获一切。