macro-inc/macro

解决什么问题

小团队的工具栈是一堆各自为政的优秀产品：聊天、文档、任务、邮箱、CRM 谁也不认识谁，只能靠 Zapier、MCP、复制链接硬连起来。结果是「为什么做这件事」到「谁做完了」这条链路断在原地。Macro 的做法是把这些界面全部重建在同一个后端上，共享一张双向关联图，人 和 agent 共用团队级记忆。

有什么不同

常见路线是分别买 Slack、Notion、Linear 再粘起来，或者选一个本质是文档工具加数据库的轻量「全家桶」。Macro 的核心主张是每个界面都为自身场景专门设计，但共用一张图：邮件可以在文档里被 @ 引用，任务能从频道消息一键创建并追溯到关闭它的 PR，CRM 联系人可以直接在收件箱里查。第二个差异是 agent 被当作一等成员，拥有跨工作区的检索能力——README 举例说 agent 可以直接搜从邮件里解析出的 PDF 附件，而不是先翻邮件线程。第三是任务刻意做轻、贴着聊天走，直接押注「专用 issue tracker 不如轻量任务」这一判断。

适合谁

大约 10 到 50 人、被五六个 SaaS 的集成成本折磨、愿意把整个公司搬进一个产品里的创业团队最合适。工程驱动的团队尤其受益，因为聊天和任务天然挨着代码链接。反过来说，已经在 Jira、Salesforce 或几百个集成的 Slack 工作区里沉淀了深度定制流程的团队应该避开：它的卖点是整合，把一个成熟流程迁进年轻产品恰恰是反整合。需要私有化部署的团队要先确认自托管方案再决定。

上手成本

这是整个工作台的替换，真正的成本在迁移和重新培训，而不是安装。技术栈是 Rust 加 SolidJS，AGPL-3.0 许可：内部自用没问题，但如果你想嵌入或换皮发布就会受限。项目很年轻（2025 年 11 月创建），README 更像产品导览而非部署文档，自托管细节、数据导出保证、API 稳定性都得去翻官方文档；版本控制等功能明确标注为 v1。

点评

Macro 是一个全新项目而非成熟项目：约 350 天、4,902 star，只在趋势榜上出现过 2 天，本周 +202 star。这说明有初期关注，但还谈不上被验证的增长曲线，唯一一条 8 分的 Show HN 帖子也说明受众仍小。但「邮件、聊天、文档、任务、CRM 共用一张图」确实抓住了工具碎片化这个真问题，一个 ~15 人团队两年的自用，比 star 数更有参考价值。把公司的操作系统押在它上面，意味着接受 AGPL、承担迁移成本，以及承受一个年轻产品随时变化的风险；建议先在一个团队里试用，别一上来就全量搬迁。