为什么我们需要代码索引工程

我最近也打算问大佬这个问题，比如我想给disucz论坛写一个插件，我用codex直接把这个论坛文件夹拖进codex列表吗？那他是不是会把discuz这个论坛全部读一遍？那得浪费多少token？所以是要做索引吗？在codex里我还没看到有入口，之前用vscode的klio插件里倒是看到可以添加索引

codex使用bash和read工具去像人类一样去扫描目录 去读相关内容 去找到与之最相关的代码块 并不会全量读取。

代码索引工程只是可以尽可能的节省重复的步骤以及节约成本。

谢谢答复，我猜AI也不想像我想的那么蠢去全读一遍 ^-^

趁着今天token多，先把文件夹拖进去先。

grep 和索引两种方式现在卡在有一好没两好的状态

也不知道 fast-context 会不会过一阵子也收掉

原本 mcp 常常遇到一轮内某些调用回传错误格式

用 rust 重构后想水水文，结果发不出来 ^-^

嘛… 你别说 我写文章也都是先输一堆驴头不对马嘴的话 让llm生成完 再改回自己驴头不对马嘴的话。

感觉越来越难自己写文章了。

目前我的看法就是fast-context和ace这种东西到最后还是不得不自己维护一套。逆向的东西终究不长久，忍忍短痛一下吧。

发 github 要审核

只是这两天头昏脑胀的，物理上的头疼

看规则也没看出哪里有问题，版主也忙，索性作罢哈哈

fast-context 前景堪忧，模型底子不好

感觉没有要训新特化模型的打算，然后 devin 新的 subagent 又不好用

而 relace 在搓怪东西，morph 太贵

难道真的要回头搞索引了吗 ^-^

ennnnnn，用过 OpenSpec 没，我还在搓自己的Agent和Agent进行项目开发的辅助规范，我的东西还没完善，暂时是在用OpenSpec，感觉体验还行，暂时在搭配提示词工程来一定程度的达到期望效果，虽然也不太理想

其实ace的这套也就到头了，模型能力再强也没有办法再提升质量了。

最终其实还是又得回到repo based 基于repo的分析。

我目前在做的那个panthera就是用这种想法进行实现的。效果很好，但是不太适合实时的代码索引。可能更适合企业的代码资产审计 漏洞扫描 或者合规化检查之类的。

对于实时性的代码索引和记忆管理，我现在也等于是回到finetune模型的纯embed思路上来了。

我应该是没有用过，但是在工作流开发的情况下 一个合适的spec规范是有必要的。

但是这个不在我们主题的讨论范畴之内。

喔，你说的重点是实时高速低耗的工程索引能力是叭，，这玩意儿确实太TM有用了

差不多，我想聊的实际上是在开发时如何能够快速的找到需要更改或者要确认的内容。无论是在计划实施前还是计划编写还是在开始编写还是在review。

如果可以用经济且快速的方法去找到的话 那么就会让token和context足够的节约 成本也会降下很多。