L1ch404

@gorvey 能详细讲讲吗，是哪一块的领域？有没有项目地址呀 我去瞧瞧

@kneo 哈哈哈 不至于，joLink 其实真正服务的对象是 AI ，我们作为第二用户可能比较难理解和看到他的用处，你可以把 joLink 的 github 地址发给你经常用的大模型 让他去客观的评判下有没用、怎么看待 joLink 的

@quxiaojuncuiyue 你说的增量编译不是新问题、验证方法属于 Agent 的工作规则，这两点我认同。我前面把开发理念和工具实现放在一起讲了，容易让人理解成“加个 MCP 就能让 AI 学会测试”，这个确实不是 joLink 做的事情。
joLink 更具体的定位，是给 Agent 用的无界面 Java 开发环境。它从 Maven ／ Gradle 取得项目的源码、依赖和编译配置，再维护一个持久的 JDT 工作区，后续修改复用已有编译状态。增量编译用的就是现有 JDT 技术，不是我发明的新算法，也不是说原生命令行做不到增量编译。
它做的不只有编译。比如应用已经启动，Agent 改完代码后，可以让 joLink 增量编译并应用修改，适合的用 HotSwap ，需要重新初始化的就重启；遇到问题，还可以在同一个托管应用上设置断点、读取调用栈和变量。这里管理的是实际的编译状态、应用进程和调试会话，不只是告诉模型“你应该运行一下”。
至于测什么、怎么造数据、什么结果才算符合需求，仍然需要开发者或 Agent 根据业务设计。配套规则只指导这个过程，joLink 不会自动替业务定义正确答案。MCP 则只是把运行、测试、调试这些操作接给 Agent 的接口，不是在协议里封装一套通用测试理论。
规则加命令行当然可以完成这些工作，已有脚本或者 IDE 集成也可以。如果一个项目的现有流程已经很顺，确实未必需要 joLink 。我想做的是把这部分能力整理成可复用的组件，让不同 Agent 可以直接接入，而不是各自组织一套。具体能不能减少操作和等待、值不值得多装一层，要看实际项目的对比，不能只因为用了 MCP 就说更好。

@crazy0x
@lsls931011
@refear99
@moyupai
@fovecifer
@alamaya
@wantDoraemon
@JasonYip 我上面表达的有问题，不是说跑不起来，只是启动一个企业级多模块的 Java 项目还是比较麻烦，可以用 classpath 拼接依赖包或者先编译再用 jar 、war 的方式启动，在我有限的测试中发现 ai 不太愿意这样做，这个东西就是给了 AI 一个快捷的启动、测试入口，其次启动前的编译也会快些，并不是说开创了一个什么东西，只是想在这方面做了一个尝试而已，想探索一下 让 ai 快捷的启动、测试对于 vibe coding 这件事情有没有帮助，最后感谢大家的回复，我没有一一回复 我就找了相同疑问的评论一起回复了🙏🏻

@chenluo0429 怎么说呢，能用和好用之间还是有些区别的，joLink 更像是给 AI 做的一个 IDE 吧，就是提供了一些方便的入口吧，如果 java bin 去启动一个企业级的 Java 项目还是比较麻烦的，也不说不能，就像以前古法编程一样 用记事本一样可以写代码 只是不好用而已，不过我也没有说 joLink 一定有用或者怎么样，我只是想探索一下，毕竟失败的探索也是有意义的，最后感谢你的回复

@ricciz 哈哈哈，你说的这点没毛病，没准未来 AI 能力大幅度提升、非常智能的话 joLink 确实是没多大意义，不过我觉得 joLink 能做出来就已经很不错了

@ryougifujino 感谢回复，是可以这样做，joLink 主要还提供了一套更方便 更快捷的能力供 AI 去启动、测试，就有点像现在大家写代码都用 IDE ，如果脱离 IDE 也能写，只不过没那么方便而已

@fridaythx 不是 agent ，是一个 mcp ，是给 agent 提功能能力的，可以接入目前市面大部分 agent

@ricciz 感谢您的评论，确实是会，我在做 A\B 测试的时候发现这个现象了，只不过可能比较慢而已，joLink 提供了一套更方便快捷的方式去执行单元测试