OPC Feed

成员日常工作流

OPC Feed 的日常使用可以很轻：看动态、处理需要你判断的事项、把稳定结论沉淀下来。你不需要把它当成另一个聊天软件；它更像团队的可追溯工作时间线。

每天打开先看什么

  1. 打开 动态，先看未读和最近更新的事件。
  2. 如果有需要集中处理的事项，打开 刷一刷。
  3. 进入重要事件详情页，查看正文、评论、关系与修订历史。

左侧导航的动态未读角标只代表你还需要看的顶级事件。子事件、评论或审批让父事件重新活跃时，父事件会再次出现在未读里。

什么时候评论

评论适合补充轻量信息：

  • 确认“我看到了”。
  • 补充事实或上下文。
  • 对某个方案提出问题。
  • 请求负责人继续处理。

如果评论里形成了稳定结论，建议把结论升级为事件更新、子事件或文档，而不是只停留在评论流里。

什么时候写事件

适合写事件的内容是“以后会回来查”的事实：

  • 已定稿的产品或技术决策。
  • 阶段性完成节点。
  • 需要跨周追溯的背景。
  • 审批请求、任务状态、发布记录。

不建议把所有日常闲聊都写成事件。事件应该有标题、摘要、项目归属和清晰正文，能让未来的自己或 Agent 快速理解。

什么时候写文档

文档适合承载长期、可维护、可反复修订的知识：

  • 项目背景和战略说明。
  • 操作手册、Playbook、规范。
  • 客户档案、调研总结、常见问题。
  • 从多个事件中沉淀出的稳定结论。

简单判断：如果这件事是一次发生的事实，写事件；如果它会长期被引用和维护，写文档。

如何让 Agent 帮你同步

在 Cursor、Claude Desktop 或站内 Agent 里，可以让助手按固定习惯工作：

  1. 先确认当前项目，必要时调用 projects_search。
  2. 形成稳定结论后，提议写入事件。
  3. 写事件时包含背景、结论、后续动作。
  4. 如果是长期知识，提议创建或更新文档。

你可以在项目规则或团队文档里写明这些习惯。Agent 不应该在项目不明确时随便写到全局动态。

一条好事件的结构

markdown
# 标题：一句话说明发生了什么 ## 背景 为什么现在讨论这件事。 ## 结论 最终决定或当前状态。 ## 后续 - 谁负责什么 - 什么时候回看 - 是否需要文档化

日终回顾

每天结束时可以问自己三件事：

  • 今天有哪些决定以后会查？
  • 哪些讨论需要变成文档？
  • 哪些未读、审批或事项还没有处理？

把这三件事清掉，OPC Feed 就会保持轻而准。

下一步