什么是 Almirant？
想象这样一个场景：清晨查看应用时，你发现了三处可以改进的地方。你对连接到 Almirant 的助手说：“为这里加一个按钮、把这个做得更大、让这个功能按这种方式工作，各创建一条 Seed。”三条想法都会被记录下来。然后你开启一次规划会话，AI 会分析项目上下文、合并重复内容、研究代码库，并提出带有具体 definition of done 的任务。你批准后，在云端启动实现。你去健身房。回来时，PR 已在等待审查。
这就是 Almirant。
真正的问题
我们使用的工具，如 Jira、Linear 和 Notion，是为由人类执行工作的团队设计的。当 AI 代理加入团队后，这个模型就会失效：
- 碎片化：多个窗口、纸质笔记，没有一个统一位置可以捕捉工作中出现的想法
- 跨项目丢失上下文：如果同时处理三个项目，没有系统就几乎不可能知道每个项目进展到了哪里
- 协作断裂：没有共享上下文，每次 AI 会话都从零开始。你和同事共同做出的决定对代理而言并不存在
- 被终端束缚：要让代理实现某项功能，你必须在场，打开终端并盯着屏幕。代理承诺的是自主性；实际中，你只是把写代码换成了监视别人写代码
- 没有可见性：启动一个代理后它就像消失了。你不知道它是否在工作、是否卡住，或是半小时前就已经完成
Almirant 是什么
Almirant 是人类与 AI 代理共同工作的中心，覆盖从想法到实现的全过程。
它不是在 Jira 上简单加了一层 AI，而是从一开始就为完整周期设计的工具：
| 阶段 | Almirant 的作用 |
|---|---|
| 捕捉 | Seeds：随手记录想法，即使在移动中、没有打开电脑时也可以 |
| 规划 | Ideate：AI 分析、分组、研究代码库并提出具体任务 |
| 实现 | 本地或云端（OnCloud）实现技能 |
| 验证 | Validate：确认实现符合原始规范 |
| 文档化 | Document：自动生成变更文档 |
上下文存在于中心，而不是某次会话中。每个代理启动时都拥有完整的项目地图，而不是面对一张白纸。
Almirant 适合谁
同时处理多个项目的自由职业者和个体创业者
他们最容易在项目之间切换时丢失上下文。Almirant 是首个让你同时处理三个项目却不失去任何一个项目脉络的工具。你可以在移动中捕捉 Seeds、批量规划、在云端启动实现，并在回来后审查结果。
小型开发团队
当人类与代理并行工作时，没有协调就必然混乱。Almirant 提供共享结构：谁在做什么、每项任务处于什么状态、团队做了哪些决定以及原因。团队成员更替时，机构记忆不会消失。
小型团队和产品团队
你管理一个由人类和代理并行工作的团队。你需要了解每个代理正在做什么、协调存在依赖关系的任务，并保留在团队成员变化后仍然存在的共享记忆。
Almirant 是人类与代理汇聚在一起、推动产品前进的地方。
核心概念
| 概念 | 说明 |
|---|---|
| 项目 | 汇集看板、工作项、文档和配置的主要容器 |
| 看板 | 具有可配置列、用于展示工作流的 Kanban 看板 |
| 工作项 | 分层的工作单元：Epic > Feature > Story > Task |
| Sprint | 具有开始/结束日期、目标和进度报告的迭代 |
| Goal | 汇集工作项并跟踪百分比进度的宏观目标 |
| Seed | 用于构思的原材料：为规划会话提供输入的原始想法 |
| 规划会话 | 使用 AI 进行规划的聊天：描述你的需求，AI 会生成结构 |
| Todo | 不需要完整工作项的轻量级个人任务 |
| 费用 | 项目成本记录：订阅、托管和 AI 成本 |
| MCP | Model Context Protocol：Almirant 与 AI IDE 之间的双向连接 |
| Skill | 由 AI 执行的自动化命令（/implement、/review-task、/validate、/test-task、/pr、/ideate） |
快速入门
- 创建账户并登录：使用 Google 注册并配置组织
- 第一个项目：从零创建和配置项目
- 第一个看板和工作项：配置 Kanban 看板并创建首批任务
- 连接 Claude Code：通过 MCP 将 IDE 与 Almirant 集成
- 第一个 AI 工作流：从 Seeds 到云端实现的完整周期
已有项目管理工具使用经验？
直接前往第一个 AI 工作流了解完整周期；如果已有项目并希望连接 AI，请前往连接 Claude Code。