yisen123

实时可视化你这个库的代码架构图看着很酷 https://scan.sentrux.dev/scan/timqian/snoreman

@HeyWeGo 你好，刚刚网页已加入了极细的线帮助阅读，谢谢反馈！

@HeyHudy 很酷！！

@xxlsize 主要的价值是给出代码质量分数，ai agent 有了这个分数以后从 mcp 获取，可以改进代码质量

@zhady009 你好，可以先用桌面版测试一下， 桌面版测出来是好的，这可能是 rust 以及 webassembly 的一个 bug ，我们正在修复网页版中，桌面版是好的

@009694

这不是悖论，这是 P vs NP 。
检测循环依赖 = O(V+E)，Tarjan 算法跑一遍就知道 A→B→C→A 有环。
修复循环依赖 = 要理解代码语义才能决定：是让 A 不依赖 B ？还是 B 不依赖 C ？还是抽一个共享模块 D ？ D 里放什么？
测量是多项式时间的，改进是需要语义理解的。温度计能告诉你 39 度发烧了，但不能开药方。开药方需要理解发烧的原因，不是量个温度就行。
这正是为什么需要大模型——传感器负责"发现哪里有问题"，大模型负责"理解代码语义然后决定怎么改"。两个能力不在同一个复杂度层面上。

@yusf 说得很好，几个点回一下：

MCP 不够友好这个认同，我们在考虑更轻量的接入方式。

关于"低分但在我项目就应该这样写"——这正是为什么我们只量根因不量规则。sentrux 不会说"你的函数太长"或"耦合太高"这种主观判断。它量的是图论属性：依赖图是否有环、模块是否自然分簇、复杂度是否集中。这些是数学事实不是风格偏好——不管你是 feature-first 还是分层架构，循环依赖就是循环依赖，god file 就是 god file 。

但你说的"项目自己的工程要求"确实是需要的——这就是规则引擎做的事。你可以在 .sentrux/rules.toml 里定义你项目的架构约束，比如哪些层不能依赖哪些层、最大允许循环数。这部分是你定义的，不是我们定义的。

至于 sub-agent 来评判修改必要性——我觉得这个应该是 agent 自己的判断，不是传感器的职责。传感器只负责给信号，agent 自己决定要不要改、怎么改。跟温度计一样，温度计不决定你要不要开空调。

@bybyte

对，完全正确。一句话总结就是这个。
没有传感器的时候，agent 只能靠自己判断代码好不好——但它的判断依赖上下文，上下文烂了判断就不准了。
有了传感器，agent 有了一个跟自身判断独立的、基于数学的客观信号。方向明确了，改进就收敛了。

@p1094358629 好问题。重启后 agent 的"记忆"没了，但改善是沉淀在代码本身里的。
agent 上次重构了代码 → 代码结构变好了 → 这个改善永久保存在你的代码库里 → 下次新会话 agent 读到的就是更好的代码 → 它自然写得更好。
所以不需要 agent 记住"技巧"。代码库本身就是记忆。好的代码结构 = 好的上下文 = agent 下次表现更好。
这也是为什么叫"递归自我改进"——改善不是存在 agent 脑子里，是存在代码里，而代码就是 agent 下次的输入。