Help shape Maka’s roadmap: what are you trying to accomplish? / 一起规划 Maka：你正在努力完成什么？

[M4n5ter]

English

Why this discussion

We’re beginning to plan the next phase of Maka.

Before discussing features, we want to understand the real work people want Maka to help them accomplish: the tasks, frustrations, constraints, and outcomes that matter to you.

We’d especially like to hear from you if you:

• use Maka regularly;
• tried Maka but stopped;
• are considering Maka but have not found the right use case yet; or
• use another tool or workflow that Maka could learn from.

You do not need to write a product proposal. A concrete recent experience is more useful than a long feature wishlist, and answering even one question is helpful.

Tell us about one real need

1. What were you trying to accomplish?
   If possible, describe a recent task, project, or situation.

2. How do you handle it today?
   What tools, people, or manual workarounds are involved?

3. Where is the biggest friction?
   What is slow, repetitive, fragile, confusing, or requires too much supervision?

4. What would a great outcome look like?
   How would you know that Maka had meaningfully improved the experience?

5. What must Maka get right before you would trust it?
   For example: reliability, control, privacy, transparency, cost, speed, platform support, or integration with existing tools.

6. If you have tried Maka, what made you continue—or stop—using it?

If you already have a feature in mind, please share it, but also tell us about the underlying problem it would solve.

For example, instead of only saying “add a mobile app,” you might say:

I start long-running work at my desk, but I need to check progress and approve important actions while I’m away. Today I have to wait until I return to my computer. A good outcome would let me safely review and redirect the work from another device.

Optional reply template

What I’m trying to accomplish:

What I do today:

The biggest friction:

What a great outcome would look like:

What I need in order to trust it:

My experience with Maka, if any:

Anything else:

How we’ll use your feedback

We’ll look for recurring goals, blockers, underserved workflows, and important trade-offs. We plan to summarize the themes in a follow-up and use them as input when shaping Maka’s roadmap.

This is not a feature vote or a promise that every request will be implemented. It is a way for the community and maintainers to make roadmap decisions with a clearer understanding of what people actually need.

Feel free to reply in English or Chinese, and feel free to ask follow-up questions on other people’s experiences.

Thank you for helping us decide what Maka should become next.

简体中文

为什么发起这个讨论

我们正在开始规划 Maka 下一阶段的方向。

在讨论具体功能之前，我们希望先理解大家真正想让 Maka 帮助完成的事情：你面对的任务、困扰、限制，以及对你真正有价值的结果。

无论你属于下面哪种情况，我们都很希望听到你的反馈：

• 正在经常使用 Maka；
• 尝试过 Maka，但后来停止使用；
• 对 Maka 感兴趣，但还没有找到合适的使用场景；
• 正在使用其他工具或工作流，其中有 Maka 值得学习的地方。

你不需要写一份完整的产品方案。一个最近真实发生的具体经历，通常比一长串功能愿望更有帮助。哪怕只回答下面的一个问题，也很有价值。

和我们分享一个真实需求

1. 你当时想完成什么？
   如果可以，请描述一个最近发生的任务、项目或具体场景。

2. 你现在是怎么完成它的？
   其中涉及哪些工具、人员或手动变通方案？

3. 最大的阻力在哪里？
   哪些环节缓慢、重复、脆弱、难以理解，或者需要你不断盯着？

4. 理想的结果是什么？
   发生什么变化，才会让你认为 Maka 真正改善了这段体验？

5. Maka 必须做好什么，你才愿意信任它？
   例如可靠性、可控性、隐私、透明度、成本、速度、平台支持，或者与现有工具的集成。

6. 如果你使用过 Maka，是什么让你继续使用，或者最终放弃？

如果你已经想到了某个功能，也非常欢迎提出；不过请同时告诉我们，这个功能背后真正要解决的问题是什么。

例如，与其只说“增加移动端”，你可以这样描述：

我会在电脑前启动一个耗时较长的任务，但离开电脑后仍然需要查看进度，并批准重要操作。现在我只能等回到电脑旁再处理。理想的结果是，我可以从另一台设备上安全地检查并调整任务。

可选的回复模板

我想完成的事情：

我现在的处理方式：

最大的阻力：

理想的结果：

要让我信任它，Maka 必须做到：

我使用 Maka 的经历（如有）：

其他想说的：

我们会如何使用这些反馈

我们会从反馈中整理反复出现的目标、阻碍、尚未被满足的工作流，以及重要的取舍，并计划在后续讨论中发布总结。这些内容将成为 Maka roadmap 的重要输入。

这不是一次简单的功能投票，也不代表每项需求都会被实现。我们希望通过这个讨论，让社区和维护者能够在真正理解用户需求的基础上决定 Maka 接下来应该做什么。

你可以使用中文或英文回复，也欢迎针对其他人的经历继续提问和讨论。

感谢你帮助我们思考 Maka 接下来应该成为怎样的产品。

[yihanzhu]

我想完成的事情：

我是从源码启动 Maka 的新用户，同时也希望之后能参与项目贡献。我想先用 Maka 在一个真实项目里完成一个小任务，例如修改代码、运行测试并查看结果，借此理解它和 Codex、Claude Code、OpenCode 等工具相比，真正独特的价值是什么。

我现在的处理方式：

使用其他 coding agent 时，我通常只需要打开项目、描述任务，然后查看代码修改和测试结果。整个开始路径比较明确，不需要先理解工具内部有哪些模块或架构概念。

最大的阻力：

第一次打开 Maka 时，我不太清楚下一步应该做什么。

Settings 里同时出现了 Models、Subagents、Memory、Remote Access、Web Search、Usage、Import tasks、Daily Review、Data、Permissions、Health 等很多选项。在还不知道 Maka 最适合帮我完成什么之前，我就需要先理解大量配置和内部概念，这让我有些无从下手。

配置好模型后，主要界面仍然是 sidebar、chat、composer、model picker 和 tool cards。从第一次使用的感受来看，它和其他 agent/harness 的界面比较相似，我没有很快感受到 Maka 的核心差异。

阅读文档后，我才了解到 Maka 很重视 recoverability、auditability、Runtime Event Log、Artifacts 和长期任务。但这些优势并没有在第一次真实任务中自然地呈现出来。如果不主动阅读架构文档，我可能不会发现它们。

理想的结果：

我希望新用户可以在十分钟内完成一次完整、可验证的首次任务：

1. 选择模型和项目；
2. Maka 在任务开始前说明当前是否 ready，以及是否有需要修复的问题；
3. 完成一个小而真实的任务；
4. 清楚展示任务是 running、waiting、blocked 还是 completed；
5. 展示代码修改、测试结果、Artifacts 和其他完成证据；
6. 如果任务中断，解释哪些工作已经确认完成、哪些可以安全恢复、哪些需要重新验证。

我不确定最好的解决办法是不是单独增加一个 onboarding。也许更重要的是让第一次任务本身承担 onboarding 的作用，让用户在实际使用过程中理解 Maka。

Settings 也可以考虑 progressive disclosure：默认只展示 Model、Workspace、Permissions 等开始使用所必需的设置，其余能力放到 Advanced，或者在用户真正需要时再逐步出现。

要让我信任它，Maka 必须做到：

• 明确展示当前任务状态；
• 完成声明有实际的验证证据；
• 清楚说明权限和本地数据边界；
• 中断后诚实说明哪些内容可以恢复、哪些需要重新验证；
• 不要求用户通过阅读大量原始工具日志，才能判断任务是否真的完成。

我使用 Maka 的感受：

目前让我犹豫的并不是缺少某一个具体功能，而是产品还没有在第一次使用时清楚告诉我：

• 我应该先完成什么；
• Maka 最适合解决什么问题；
• 它最值得使用的差异化能力是什么。

如果这些能力已经存在，那么可能说明它们在首次体验中还不够容易被发现。

[uzqw]

What I’m trying to accomplish:

希望使用 Maka 扫描和理解我的代码库，并帮助我定位和修复一些实际的代码问题。我希望它最终可以成为日常开发中的主力 coding agent，而不仅仅是偶尔使用的工具。

What I do today:

我的主要开发环境是 Windows + WSL。安装 Maka 之后，我一开始不太清楚应该如何让 Maka Desktop 连接并操作 WSL 中的开发环境。最后借助其他 agent 完成了配置，目前基本可以使用，但 Desktop 端仍然会持续出现一些报错。

The biggest friction:

最大的阻力主要有两个：

1. WSL / 远程开发环境的接入过程不够直接，我花了比较多时间才完成配置。
2. 配置完成以后，Desktop 端仍然会出现错误，模型适配错误导致的停止、工具使用出错导致停止、ui层崩溃我都碰到过。我安装的windows版本，在我碰到这些问题以后我没办法通过其他agent改好代码并且重新运行，这会非常的麻烦，需要编译一个windows版的包。

我尝试了在wsl里面运行编译，但是使用效果不好，因为我没办法输入中文和显示中文。最后我只能使用tui版本。

对我来说，开发工具最好能够尽量降低环境配置成本，并且在出现异常以后尽可能自动恢复，减少人工介入。

What a great outcome would look like:

我希望远程环境的接入可以非常简单。

例如，我提供目标机器的 SSH 地址、用户名以及认证方式，Maka 就可以自动完成 daemon 的安装、启动、连接和后续升级，而不需要我手动处理较多环境配置。

理想情况下应该类似：

提供 SSH 信息 → 自动部署 daemon → 自动检查环境 → 可以直接开始任务

WSL、Linux 服务器以及其他远程开发环境最好能够使用相近的接入方式。

What I need in order to trust it:

对我来说最重要的是执行任务时的稳定性。

我可以接受任务过程中出现错误，但希望 Maka 能够：

• 明确告诉我失败发生在哪一步；
• 尽可能自动重试或恢复；
• 不因为一个中间步骤失败就直接终止整个任务；

相比增加更多功能，我目前会更看重这些基础执行能力的可靠性。

My experience with Maka, if any:

我之前至少有三次因为比较认可 Maka 的产品方向，它的benchmark吸引了我，准备把它作为自己的主力 coding agent，但最后都没有真正迁移过去。

主要原因不是功能不足，而是我通常无法在大约两个小时内把环境调整到一个让我觉得足够顺畅、可以长期使用的状态。

目前我的主力工具是 pi-agent，通过 pi-web 使用 https://pi-web.dev/

我比较喜欢 pi-agent 的一点是，它在权限方面给我的操作阻力比较小。相比之下，我使用 Maka 时比较频繁地遇到 sandbox / permission 相关提示，需要先处理权限问题才能继续任务。

权限本身我可以接受，真正影响体验的是：完成权限配置以后，如果任务执行过程中再次遇到错误，有时任务会直接停止。这会让我对长任务的可靠性缺乏信心。

我的预期不是“永远不出错”，而是：

出现错误 → 能识别问题 → 自动恢复 / 重试 → 尽量继续完成任务

如果做不到自动恢复，也希望能够非常明确地告诉我当前状态以及如何继续。

Anything else:

我个人会更希望 Maka 现阶段优先把核心开发体验做得简单和稳定，即使因此暂时减少一些功能也没关系。

例如，我认为目前比较值得优先投入的方向是：

• Windows / WSL / Linux / SSH 等跨平台开发环境的接入；
• daemon 的自动安装、升级和故障恢复；
• sandbox / permission 的配置体验；
• 长任务执行的稳定性和自动恢复；
• 错误信息、日志和任务状态的可观测性。

至于 PC 原生控制能力，我理解这是一个有潜力的长期方向，但以我目前的使用场景来看，它带来的价值还没有开发环境和任务稳定性那么直接。随着未来模型的 computer-use 能力继续提升，再进一步投入这部分可能也会更有价值。

如果只能选择一个方向，我目前最希望 Maka 做好的其实很简单：

让我能够很容易地连接到任何开发环境，然后放心地把一个任务交给它执行，并且即使中间发生错误，也尽可能自己恢复并继续完成。

[M4n5ter]

@uzqw 非常感谢这些反馈，我正在推进#3228 ，不久的未来应该能显著改善你所说的场景！