总是有种感觉就是和 ai 一起推进一个项目，和 ai 一起讨论，各种方案研究，一起推进，推着推着就退不动了，要么就是觉得 ai 莫名的越来越笨，

要么就是 ai 调用工具比如检索查看一些文件或者信息的时候似乎越来越不准，效率越来越低
要么就是 ai 写一些测试的时候，测试的越来越不准，
或者说要 ai 修 bug ，他说修好了，可是问题还在，这样的现象随着我们的项目越来越大以后就越来越明显

所以导致大到一定程度，积累了很多的技术债，导致很难继续，或者改变。

在 AI 之前的时代，我们打开 IDE ，每一行代码、每一个文件、每一个引用、每一个函数都是我们自己写的。当出现 bug 的时候，我们非常清楚问题在哪，可以快速地去调试，很有掌控感。

但在 AI 时代，我们在终端或 AI Agent 上，只能看到它以机器的速度快速修改各种文件。我们只能看到具体改了哪些文件的名字，以及非常局部的改动内容，这使我们失去了对整个代码的大局观。

很多人在整个用 AI Web Coding 的生命周期里，甚至从始至终都没有看过文件夹下面的内容：

它到底创造了什么？
它们之间的关系是什么？
整体结构是什么？

我们对此一无所知，只能盲目地相信 AI 做的事情。那么当出现 bug 的时候，我们更加无能为力，只能继续依赖 AI 去找 bug 、查 bug 、改 bug 。这也是目前的痛点之一。

在信息学的理论里面有熵增定律。由于我们目前的 AI 属于生成式 AI ，AI 写的代码是生成式代码，这就不可避免地会从原理上让我们——如果只依赖于 AI 的话——会让我们的代码结构变得更加冗余和复杂。

目前整个行业很有可能是在以一个错误的方式去解决这个问题。

在一些很火的开源项目（比如 GitHub 出品的 SpecKit ）中，这类工具非常依赖于开发者在项目开始前，就彻彻底底想好整个代码结构、要实现的功能以及具体内容。

但真正在 AI Coding 的时候，我们的做法其实恰恰相反。在自然的情况下，我们使用 AI 写代码更倾向于一种“交谈启发式”的流程：

我们并不会提前规划好所有细节，而是从零开始，让 AI 快速生成原型。
像甲方和乙方一样，在交互中不断修改方案。
同时进行一些深刻的探讨，启发我们想到更好的产品方案或技术路线。

在这样的循环推进方式下，AI 不可避免地会生成一些架构很乱的“脏代码”。最终在一轮又一轮的 Prompt 之后，它确实可能给出一个外在功能完美的运行结果，但内部架构可能是极其混乱的。

正是因为架构的混乱，会导致开篇那样让人抓狂的东西，很多致命的情况： (a) 当 AI 调用工具指令搜索函数时，可能会找到好几个函数名相同但实现形式或算法不同的结果。 (b) 当 AI 修复 Bug 时，它以为修好了一处，但由于架构混乱，它实际修掉的可能是别的地方。

俗话说，好的体系让坏人也可以做好事，坏的体系可以让好人也变成坏人。这就意味着，在一个好的架构下，即便水平稍低一些的 AI 都可以写出高质量的代码。

所以，架构是非常重要的。

所以这个 repo 可以同时帮助人做以上两个事情，可以理解为可视化文件系统，以及给 AI 一个传感器，就是架构传感器，帮助 ai 自我循环加速写好的代码。

这样可以理解为这个 project 是反向的 speckit ，

无论你用什么自然的方式开始 vibe coding ，都可以在 sentrux 的帮助下，最后弄出来很好，很高水准的代码，

纯 rust 高性能

https://github.com/sentrux/sentrux

yisen123

3 月 14 日

@beyondstars 这个项目非常适合那种 vibe coding 时代，自己做项目从小到大那种：

在一些很火的开源项目（比如 GitHub 出品的 SpecKit ）中，这类工具非常依赖于开发者在项目开始前，就彻彻底底想好整个代码结构、要实现的功能以及具体内容。

但真正在 AI Coding 的时候，我们的做法其实恰恰相反。在自然的情况下，我们使用 AI 写代码更倾向于一种“交谈启发式”的流程：

我们并不会提前规划好所有细节，而是从零开始，让 AI 快速生成原型。
像甲方和乙方一样，在交互中不断修改方案。
同时进行一些深刻的探讨，启发我们想到更好的产品方案或技术路线。
在这样的循环推进方式下，AI 不可避免地会生成一些架构很乱的“脏代码”。最终在一轮又一轮的 Prompt 之后，它确实可能给出一个外在功能完美的运行结果，但内部架构可能是极其混乱的。

随着 AI 写代码的复杂度越来越高，项目越来越难以推动和理解，这个反 speckit 工具可以解决这个问题