问题描述：

本帖使用社区开源推广，符合推广要求。我申明并遵循社区要求的以下内容：

• 我的帖子已经打上 开源推广 标签： 是
• 我的开源项目完整开源，无未开源部分： 是
• 我的开源项目已链接认可 LINUX DO 社区： 是
• 我帖子内的项目介绍，AI生成、润色内容部分已截图发出： 是
• 以上选择我承诺是永久有效的，接受社区和佬友监督： 是

以下为项目介绍正文内容，AI生成、润色内容已使用截图方式发出

---

前言

一开始是想做一个集成的三个功能

1. 从0开始初始化项目
2. 扫描已有代码生成结构化上下文
3. 根据简短的需求，阅读结构化上下文生成完善的需求方案，以便于AI IDE直接消费

目前1和2已经有了，3后面实现起来遇到了困难后来一想，直接让现有的cc或者codex这类工具干就行没必要再造轮子，干脆直接砍掉了

一个小工具，相比站内很多热门工具感觉还是太小了，甚至有的工具已经覆盖了我的工具的功能（ccg似乎有这个类似的功能），感觉代码质量和工具作用不是很大，单纯分享一下，有佬友感兴趣的话可以看看 ，如果点个star就更好了

（不过后期跟朋友测试了一下，效果出乎意料，对于小需求更新有显著效果，感谢 @sakuralovesmile 的初期测试和建议，后面的预期效果是通过提示词限制来提高国产模型的可用性，目前来看初始化项目相对于比较大的 superpowers 这类工具效果还是跟不上，但速度很可观，效果相对折中，如果两者结合起来一起用或许更好）

朋友的使用体验反馈

那其实基本能看出来了 执行速度 openspec > kontext > ccw > 直接运行 指令遵循 kontext = ccw > openspec > 直接运行 简易程度 直接运行 = openspec > kontext > ccw

目前工具处于刚开发不久，可能有一些比较多的使用问题或者bug，欢迎各位佬友反馈 （有些地方由于拼接的上下文太长导致失败）

刚开始接触Go语言不久，算是我的一个练手项目（AI辅助），代码质量方面也不是很高，不完善，也欢迎佬友提出建议意见

---

开源地址

github.com

GitHub - W1ndys/kontext: 🧠 Kontext 是一个面向 AI 辅助研发场景的 Go...

🧠 Kontext 是一个面向 AI 辅助研发场景的 Go 命令行工具。它的目标不是直接帮你写代码，而是先把一个项目的关键知识编译成结构化上下文，供大模型或 AI 编程工具直接消费。

测试产物地址（还在更新测试中）

github.com

GitHub - W1ndys/kontext-test: Kontext 产物测试仓库，用于测试在 kontext 环境下和非 kontext...

Kontext 产物测试仓库，用于测试在 kontext 环境下和非 kontext 环境下的开发效果对比

Kontext

Kontext 是一个面向 AI 辅助研发场景的 Go 命令行工具。它的核心能力是将项目的关键知识（架构、规范、模块契约等）编译为结构化上下文，沉淀到项目内的 .kontext/ 目录中，供 AI 编程工具直接读取和理解。

简单说，它解决的是这类问题：

• AI 不知道项目整体结构，每次都要重新解释

• 项目规范、模块边界、架构约束通常散落在代码、文档和人脑里

• 同一个任务换一个模型、换一个对话窗口，就得重复补上下文

• 全量喂代码成本高，而且效果并不稳定

Kontext 的做法是把这些信息沉淀到项目内的 .kontext/ 目录中，AI 编程工具（Claude Code、Codex 等）可以直接读取这些结构化制品来理解项目。

它是干什么的

从代码实现和 .kontext/ 中的工程说明看，Kontext 可以概括为一个”面向 AI 开发工作流的上下文编译器”：

• init：初始化 .kontext/，生成项目清单、架构图、编码约定、模块契约等上下文文件

• validate：校验 .kontext/ 里的 JSON 配置是否合法

• update：检测项目源码变化，按需更新 .kontext/ 中的物料

• config：管理全局 LLM 配置

• pack：已弃用。此前用于按任务打包 Markdown Prompt，现在推荐让 AI 编程工具直接读取 .kontext/ 目录

它既支持”交互式初始化”，也支持”扫描源码自动生成配置”，生成的上下文制品可被 AI 编程工具直接读取使用。

核心产物

Kontext 主要围绕项目根目录下的 .kontext/ 工作。当前实现里最核心的产物包括：

• .kontext/PROJECT_MANIFEST.json

项目全局清单，描述项目定位、业务背景、核心流程、技术栈、当前阶段

• .kontext/ARCHITECTURE_MAP.json

项目的分层结构、模块归属和架构规则

• .kontext/CONVENTIONS.json

编码规范、错误处理规则、AI 协作约束

• .kontext/module_contracts/*.json

每个模块的职责边界、依赖关系、对外接口和修改规则（文件名基于模块相对路径，如 internal_config.json）

• .kontext/.cache/

init --scan 的阶段缓存和断点恢复数据

项目结构概览

仓库当前是一个标准的 Go CLI 工程，入口和分层比较清晰：

• main.go

程序入口

• cmd/

Cobra 命令层，对外暴露 init、validate、update、config

• internal/generator/

初始化与扫描生成流程

• internal/updater/

变更检测与物料更新

• internal/schema/

.kontext 各类 JSON 的结构定义、加载和校验

• internal/llm/

OpenAI 兼容接口封装、结构化输出和重试逻辑

• internal/config/

全局 LLM 配置加载与保存

• internal/cache/

扫描缓存与检查点恢复

• templates/

提示词模板，使用 Go embed 打包进二进制

• docs/

设计记录和方案演进文档

• .kontext/

当前仓库自身的 Kontext 配置，可作为理解项目的参考样本

工作流程

典型使用流程如下：

1. 配置 LLM

2. 运行 kontext init 或 kontext init --scan

3. 检查并补充 .kontext/ 中的 JSON 内容

4. 运行 kontext validate

5. 在 AI 编程工具（Claude Code、Codex 等）中告知 LLM 可以读取 .kontext/ 目录获取项目上下文

6. 代码变更后运行 kontext update 保持上下文同步

---

篇幅有点长我删减了一下，更多内容欢迎参考 README

网友解答：

---

--【壹】--：

支持大佬

---

--【贰】--：

还真是，现在要求20个字符才能回复。。。

---

--【叁】--：

好用！期待后续优化！
实测能让 minimaxM2.7 这垃圾模型正常使用

---

--【肆】--：

CC或者codex直接init不就行了

---

--【伍】--：

感谢大佬

---

--【陆】--：

不是同一类东西
那个是全局上下文很宽泛

---

--【柒】--：

膜拜大佬。

现在不好谁贴了，字符限制20个。

---

--【捌】--：

感谢大佬分享（努力再Linuxdo凑够20字）