项目开始搭建的初衷

这个项目一开始就不是为了再造一个传统意义上的“开发环境”。如果只是把一堆功能塞进 GUI，再让人用鼠标点来点去，那还是旧时代的工作流：人围着工具转，工具把复杂性包装成按钮，再把大量重复劳动丢回给人。

在 agent 发展这么快的现在，还继续把核心开发流程绑死在传统 IDE 和图形界面里，我真的觉得有点太傻逼了。不是说 GUI 没有价值，调试、观察、配置、可视化这些场景当然需要图形界面；但高频、可组合、可自动化、可复现的工程动作，就应该下沉到 CLI。

因为 CLI 才是能被脚本调用、能被日志记录、能被流水线复现、也能被 agent 理解和执行的接口。一个按钮点下去发生了什么，人都未必记得清楚；但一条命令、一组参数、一次输出，却可以被保存、复盘、组合，甚至交给智能体继续扩展。

这也是我开始搭这个项目的原因：我不想再做一个只能服务于人的工具，而是想做一个人和 agent 都能调用的工程系统。

为什么不是传统 IDE 思路

传统 IDE 的问题不在于它弱，而在于它把太多能力锁在界面里。很多时候，配置藏在窗口深处，构建藏在菜单后面，调试流程依赖某个工程文件，换一台机器就开始各种玄学报错。人在这种体系里做久了，会误以为“开发”就是打开软件、配置路径、点按钮、等结果。

现代工程不应该这样。它应该像一套可描述的协议：初始化怎么做，依赖怎么检查，项目怎么生成，固件怎么构建，产物在哪里，失败原因怎么定位，下一步怎么恢复。这些动作都应该可以被明确表达，而不是依赖某个人记住某个软件里第几个选项该怎么点。

agent 出现之后，这个问题被放大了。一个只能靠人肉点按钮推进的工程，对 agent 来说几乎就是黑箱；一个由 CLI 暴露能力的工程，才有机会被智能体接管、协作和扩展。

所以这个项目从一开始就应该围绕 CLI 搭，而不是围绕界面搭。CLI 是底座，文档是说明书，skill 负责把经验、约束和操作流程封装给 agent。

普通文档是写给人看的，skill 更像是写给智能体看的工程手册。它不只是告诉 agent “这个项目能干什么”，还要告诉它：

这样一来，agent 就不是在项目里盲人摸象，而是能按流程做事。人负责判断方向、定义边界、审查结果；agent 负责执行重复流程、补全文档、检查环境、跑构建、定位错误。这个分工才符合现在的生产力水平。

我越来越不想把时间浪费在那些低级重复劳动上。路径错了、依赖缺了、命令忘了、工程模板又要重新配一遍，这些事情做一次是学习，做十次就是惩罚。它们不应该继续占用人的主要精力。

值得人做的，是判断项目应该抽象成什么结构，哪些流程必须稳定，哪些接口要暴露给机器，哪些经验应该沉淀成 skill。人不该只是代码搬运工，而是工作流设计者。

这也是我对这个项目的期待：它不是某个单点工具，而是一套面向未来工程协作方式的底座。它应该先服务 CLI，再服务 agent，最后反过来让人从大量重复流程里解放出来。

以后开发一个项目，不应该再是“打开某个 IDE，然后靠记忆点一堆按钮”。更合理的方式应该是：给出目标，让 agent 调用 skill，由 CLI 执行确定的工程动作，最后把结果、日志和问题反馈回来。

这是我想要的开发方式。

不是人被工具驯化，而是工具被组织成系统；不是让 agent 假装全能，而是把工程流程写到它真的能调用的位置。