linux.do

[开源项目] 我做了一个可视化 Spec 和 Context 管理工具

大家都说下一个开发范式是 Spec 驱动，其实我很久以前就和朋友讨论过，如果将每个功能点都用语言定义得非常清晰，技术架构、数据结构也都写好，那么 AI 是不是可以一次性就完成整个项目？
然而实践告诉我们，大部分情况下都是不行的 - 其中不可控的因素太多，例如有时候 Spec 本身也不一定对，需要更新，如果 AI 盲目遵从反而做错了。除非是对技术栈非常熟悉且项目难度不大，否则 Spec 是很难完全覆盖 AI 在实际编码中遇到的卡点的。这里还有个权衡，如果文档量小（也即人类的思考量少），AI 犯错的概率就会变大，如果文档量大，就很难维护，做着做着，代码和文档就分道扬镳了。
虽然无法一次性完成整个项目，但随着现在基础模型的能力越来越强，我们可以实现一次性就完成一个定义良好的功能点。但是问题又来了，我们会发现，vibe coding 的速度和项目的复杂程度成反比，现有的代码量越大，写新功能就越困难。这个困难分两个部分，规划的困难和工程实践的困难。

● 规划的过程需要考虑到系统的各个组件，代码的各个部分，这时候如果“偷懒”不去看完重要的代码的话，提出的方案可能是隐含 bug，甚至完全不符合整体架构的。
● 工程的困难在于 LLM 的记忆窗口有限，如果一个功能不能在它一次记忆窗口中解决的话，就会遗忘掉重要信息，比如忘记“我已经做了什么”，“我以前定义过什么工具函数”，从而导致代码冗余。

为了解决这些问题，我这次尝试做了一个可视化的 context 管理和 spec 管理工具，前端完全基于 React Flow 构建，可以定义 LLM 工作流，精准管理从需求文档到代码实现的“翻译”过程，以及给 Code Agent 提供的上下文信息。目前我的用法是这样，在一个 instruction 节点中输入自己想要实现的功能，然后通过相关代码查找、聚合、LLM 分析来给出最后的一个“深思熟虑后的实现方案”。

然后我会把这个“方案”当成 prompt 直接甩给上下文完全清空的 codex 或者 claude code，让他们来实现代码，成功率还是挺高的。

目前代码库相关文件查找（或者说 “RAG”）的功能完全依赖于 Relace AI 的 “Fast Agentic Search” API，他们使用了专门训练的模型来进行代码库的搜索，速度非常快，且非常稳定。它是并行读很多文件，比 Claude Code 要快得多。有朋友和我说 Augment Code 的 SDK 也不错，我还没有比较过。

最后的代码实现规划我用的是 Opus 4.5。其实这里可以设计很复杂的工作流，甚至做成多 Agent “辩论”的形式。这里没必要节省 token 和时间，毕竟后面代码实现和测试才是大头。所以尽量提高方案的质量。

使用工作流的方式来组织需求、代码 context 的好处是组合方便，缓存很直观，某些要不断服用的信息例如项目的整体目录树结构、todoList 都可以自然地保存为一个节点的输出，被后续的工作流不断地复用。如果觉得信息旧了想要更新的时候，只要重新运行下这个节点就好。

项目地址：
GitHub - shuxueshuxue/SpexFlow

目前已支持中英双语切换（点右上角设置就能看到）。时间仓促，前端目前是 Web 实现，之后可能会用 Electron.
我自己总体使用起来感觉就是非常的省心，终于能有条理地 vibe coding 了！
附一张梗图

28 posts - 16 participants

Read full topic

via LINUX DO - 热门话题 (author: Jeffry)

Invalid media:
image
image

48 views16:19