写在前面
这个部分内容有些多，主要是我的一些想法和一些考虑吧，不想看可以跳过，不影响使用 Hunea。
但是还是建议看一下 闲言碎语-1，因为涉及到 Hunea 后续的一些开发和路线想法，如果你对 Hunea 感兴趣，或者想要支持 Hunea 更好的活着的话，可以简单看看。
闲言碎语-1
开发 Hunea 及其配套的姊妹项目 Nostra（截至 2026 年 8 月 4 日我写这篇文章时，Nostra 仍在开发中，尚未正式上线），其实是一个让我感到迷茫的过程。
我一开始的目标很简单，就是想做一个自己用得顺手的 TUI 产品。因为主要靠 AI 来开发，起初有些随意，为了快速和方便，就用了 go + bubble tea 来实现。
一开始还算顺利，但越往后越觉得不对劲。可能是因为当时没有太在意和关注，不知不觉就"跑偏"了，折腾了一两个月后，最终以失败告终。
我后来又想了想，也许是一开始方向没选好。于是重振旗鼓，再创了一个项目继续迭代。第二次比第一次顺利不少，技术栈依然是 go + bubble tea。
不过到了四月初，我总觉得有些奇怪，却又说不上来。也许是 AI 迟迟没能解决输入框超长内容输入的卡顿问题，我突发奇想，是不是换到 Rust 更合适？
于是让 AI 花了一个下午，把代码从 go 迁移到了 rust（如果你翻看最早的几次提交记录，会发现它们都是在同一个下午完成的）。迁移过程很顺利，之前在 go 上实现并验证的功能，迁移到 rust 后工作得很好，这也给了我不少信心。
后续的流程是，我选定一个方向，让 AI 推进并测试，实现后再由我进行人工测试……
不过我还有一个不太好的习惯，就是明明用的 AI 速度本来就不快，我却总要在它完成功能后反复审查，直到没有错误为止。
这导致我一天下来可能只推进了一个功能，但审查却要好几天，一天审查十多次是常态。（可能还是有些没审查到、没发现的潜在问题，限于心力，希望大家多多包涵。）
这也是为什么过了这么久，我才提交了 400 余次。我的效率其实不算高，有时还会被 AI 或其他事情"打败"，一整天都提不起劲。
与此同时，我的钱包也在"日益消瘦"，只能无奈叹息。因为我并没有稳定的收入，开始这个项目时我甚至还没毕业（现在其实也才刚刚毕业哈哈）。哪里有公益站或可以争取额度的地方，我都会去尝试，实在没办法就只能付费使用。（在此也非常感谢那些公益站站长们，Hunea 能走到今天，离不开你们的付出，在此不一一致谢。我可以问心无愧地说，我一直是一个人、一个窗口、一个 Agent 在使用；开发 Hunea 时，我没有或极少使用过子代理功能。希望没有给维持公益站的朋友们添麻烦，也非常感谢你们的无私奉献。）
其实在开发过程中，虽然是 AI 代劳，但我仍会进行不少测试，尽量发现各种潜在问题。所以 git 提交里相当一部分都是在修复问题。
为了追求更好的显示效果和渲染性能，我也做了不少努力。
期间的事情，就不再一一列出来了。
明明晚上胡思乱想时想到了很多想说的话，可一落笔却不知从何说起。
。。。。。。
要不就先写这么多吧，我也不知道怎样才能把这些话说完。也许是我的一腔热血？或者是一厢情愿罢了……
可能还是有些不太甘心吧，所以就一直坚持到了现在哈哈～不过现在确实迷茫的很，因为不知道如果真的 Hunea 发布正式版了，我设想的功能都实现的话，会是什么情况呢？
也许 Hunea 会继续开发和维护下去，我希望它能被大家接受和喜爱。我有很多想尽快实现的功能，也许以后会专门开一个区域，用来分享这些想法。
比如：
- 修复我明明记在记事本上，但是我一直没有修复的问题
- 增加实现各种我想到的一些设计和想法（比如针对各个模型的不同的工具集和提示词设计，采用匹配或者变体或者指定的方式对不同的模型进行不同的专属定制，达到更好的效果，这个也是未来核心目标之一；因为我有时候也是常在各种模型直接切换，我发现各家的 CLI 设计和模型适配等都五花八门的，要是可以都吸收进来或者进行切换或者扩展就好了哈哈）
- 打造一个非常易用美观的 TUI 体验！
- 做其他的姊妹项目，致力于提供更完善的体验（比如类似 pi 那样的统一生态管理。还有统一的其他的工具的接入等等！）
- 完成"慢速开始"部分
- 全平台的实现和统一，Nostra 就是在尝试 GUI 啦！因为 TUI 不是人人都喜欢呀！
- 因为想法太多，暂且不一一列出！
当然，也非常欢迎大家的参与，让 Hunea 变得更好！（不过我可能会看的很慢，因为我个人其实没有什么时间，但是我会尽力的）
最后特别感谢（如有雷同，纯属巧合）
- Gxx-5.1、Gxx-5.2、Gxx-5.4、Gxx-5.x、Gxx-5.x-Sxx（均为 xhigh 或同等甚至更高思考预算）
80% - Cxxxxx Oxxx 4.6、Fxxxx 5、Cxxxxx Oxxx 5（均为 xhigh 等思考预算）
10% - Gxx 5.2
- Gxxx 4.5
- Qxxx 3.7 Max
- Kxxx 2.6
闲言碎语-2
实际上是先有 2 后有 1 的，所以 2 的部分内容会和 1 有重复
不过这一篇主要是写 Hunea 想解决什么问题吧～
做这个工具的想法早在去年（指 2025 年）年底 12 月份到今年（指 2026 年）年初就有了。
而在那个时候早已经有了不少成熟的 TUI 工具，比如我们耳熟能详的 claude code（不过其实这个我用的不多），还有其他的我用过的一些，比如 droid（factory 公司）、codex cli（OpenAI 公司，用的最多最久）、opencode（那个时候应该已经有了吧？有点不太记得了）等，还有其他的不少的国产的比如当时还用过一段时间的 iflow cli（这个可能知道的人多些？不过这个早在 26 年 4 月 17 日停止了运营，当时我还推荐给我同学用过，我自己用过一点点）还有 qoder cli（这个当时好像已经有了？），还有 neovate（体验了一下，可惜现在也不更新了好像），还有什么来着我也不太记得了。
不过对我而言这类工具或多或少有不少体验上的问题，当然，也是因为当时刚出没多久，截止文档撰写时也就是 2026 年 7 月份已经很完善了。可是在一些使用上还是让我觉得有些不太舒服，比如输入框的输入操作，还有对消息的查看和复制等等我上面展示的一些核心功能。灵感要说有无来源，我觉得 codex cli 对我的帮助很大，可以看到整体上的 TUI 样式设计是贴近 codex cli 的，只是融入了我自己对于其他的 cli 工具的观察和设计等。不过要说我这个就十全十美么？那肯定是不可能的，只是说我自己想做一个自己用的还不错的工具而已，具体能发展成什么样，这个我真不好说。而且大家对于 TUI 工具认可度有多高，我也不敢打包票。我个人是优先使用 TUI 工具的，其实也没有什么特别的原因，主要是轻量然后不用往电脑上装太多东西而已，还有就是我可以在远程服务器上使用。
一开始也就是 26 年 1 到 3 月份，其实使用的是 go + bubble tea 生态来进行实现的。当时觉得开发很快。而且界面设计还不错。但是一开始就犯了一个架构上的设计错误，后面导致只能彻底弃坑。这个架构错误就不多赘述了。
后面进行了仔细思考，决定切换到 rust 生态，并且选择了 altscreen 的方式。但是我没有采用 opencode 或者其他的 TUI 产品那样，就在底部固定一个输入框，诚然，这样的体验似乎也不错。毕竟大家好像也习惯了底部一个输入的设计。但是我不太喜欢，因为我觉得底部的输入框占据了我的内容阅读空间，我不得不调整我的终端模拟器窗口高度，才能多看一些内容。并且，我更不喜欢的是当我输入内容过多的时候，在输入框内部进行滚动！导致我不得不使用外部编辑器比如 nvim 查看我之前到底输入了什么。（但是底部固定输入框这个设计可能会作为可选功能进行加入，还有一些其他的设计也有可能会考虑，不过不会是强制固定选择，而是在配置中可以切换）
还有其他的，比如到处都是的提示信息等，都严重干扰了我的使用体验……当然也许可能是我的原因，总之我不太喜欢这样的设计。
所以我其实是从这种对我不好的体验来找灵感的。所以才有了 Hunea 的简洁美观统一的 TUI 设计，和易用的输入框组件（而且是无界输入的，也就是随便输入多少内容都不会折叠或者内部滚动，我知道可以打开外部编辑器，但是我就是想保持一个一致的体验不想到处"跑"，因此也设计了鼠标点击和选区替换等更易用的配套操作）还有各种体验优化的方案。
还有就是提示词装配和发送内容查看还有等等功能，是为了解决"黑盒"问题。因为我想要更为完整全面的掌握我的输入和 assistent 的输出情况。当然可能有人说，你这个不是可以用抓包软件或者什么方式在其他的 cli 工具中实现吗？
说的在理，但是我不想付出这么大的行为成本。并且有些工具，比如 claude code，或者什么的，怎么可能有如此高的自定义程度？完全是个黑盒。而且，一些工具的核心提示词，是完全不可以替换的。但是 Hunea 可以，不但可以替换，还可以多项目同步（有 project 和 global 的设计区别等，后续可能会有更多设计，不过当前应该是够用了），甚至可以完全禁用！你完全可以掌握自己发送了什么，收到了什么，发出去了什么。没有任何黑盒，完全透明。代码也是开源的，不会有任何小动作。你想定义自己的提示词，或者什么都不改，就想开箱即用，完全 OK。或者你想使用别人现成的，完全可以（后续会用更易用的方式进行实现）。
而且我想要实现的和 /prompt 的配套功能，就是对于不同模型有不同的工具集和提示词设计，也会尽快上线，就是为了发挥不同模型的习惯和能力上限。比如 GPT 喜欢用 patch 工具，claude 模型喜欢什么什么，还有 kimi 或者 glm 有什么特点，DeepSeek 要怎么去引导才舒服什么的（不过这个应该不容易，毕竟我也不会收集数据，所以可能到后面再考虑怎么优化吧）。
这些都会进行专门定制（当然这个任务量有些大）。而不是用一套单一的提示词和工具集去套所有的模型。
总之想法是很多的，但是我也致力于减少使用和理解成本，所以也不需要担心用起来很繁琐，这些繁琐的工作都会做好，开箱即用少配置也是我的追求。
简单综合一下想解决的问题：
- 工具不透明问题。Hunea 透明、公开、没有任何后门或者小动作。发送了什么提示词，和收到了什么，是什么就是什么
- 简洁、易用、心智负担低。很少或者近乎没有上手难度。因为我想在当今时代，也许很多工具都是给 AI 用的，但是我觉得，还是要有给我们人使用的顺手的工具
- 速度快，占用小，而且跨平台，这也是我选择 TUI 而非 web 或者 GUI 的原因，而且我做了不少优化，致力于在 TUI 上也有更好的体验，但是后两个平台等也会纳入考虑范围，不过这个是更长远的计划了
- 自由可扩展，这个后续都会进行放开和实现，我的想法是甚至内核都可以完全自定义，不过这个可能还早先记着
- 等其他我可能忘记说的问题，因为上面内容都是纯手打，有些糊涂了忘记了……
其实一开始开发的时候想法很简单，只是想给自己一个好用的 TUI 界面。
我甚至一开始没有想做一个完整的 Agent 功能的，我当时想用 ACP 协议来做一个 TUI 壳子，把其他工具，比如 claude code 什么的改用我的 TUI 来使用（也可以从我的提交记录看到我之前就是这样做的，但是后面我完全重构清理掉了）。
但是弊端太多了，先不说 ACP 本身就是"不全面"的，而且各家支持也不是很理想。更重要的是，没有解决我想要的一些更透明化的问题。我想要用我的产品之前，我还要先装好其他的产品，这岂不是太抽象了？而且我不知道其他的产品到底做了什么。而且各家的实现方式又不一样，与其我一个个去定制，还不如我自己写一个更自由更统一的平台。
而且也算是补一下国内这方面的短板吧（吹一下无伤大雅）。国内虽然也有不少大厂开发的 TUI 工具，但坦白说，用起来体验确实还有提升空间。我知道商业化产品需要优先考虑盈利，只是从个人使用者角度，还是希望能有一个用起来更顺手的工具。
最后就是 TUI 我觉得用起来更轻量方便，用户也不需要装各种各样的 vscode 或者浏览器在自己的电脑上，不过 TUI 确实看起来好像是上手难度高一些诶，不过也没关系，这个不是有"慢速开始"么？这也是要有个过程了～就是 Windows 用户可能当前用起来会别扭，因为我还没有为 Windows 用户做优化，所以还是建议先放在 wsl2 或者虚拟机中装好一个合适的 Linux 发行版然后进行使用吧。
但是当然，Windows 用户也是优先级很高的，谁说 Windows 不适合开发呢？我觉得 Windows 真的挺好用的哈哈，不过可能要等段时间才行。