出了问题找谁，多久修
利益声明：本文作者参与了 wescode 的开发。文中涉及 wescode 的技术描述基于内部测试数据；涉及其他工具的描述基于各家公开文档和社区反馈。
选一个开发工具，最怕的不是功能少，是出了问题没人理。这篇说清楚 wescode 的支持体系和响应承诺——也不回避一个年轻产品的真实局限。
Q: wescode 是开源的吗？出了 bug 找谁？
wescode 基于 VS Code 开源代码 Fork，编辑器基座是开源的。AI 引擎（wesgine）和前端组件库（wesui）的架构设计文档公开在各仓库的 AGENTS.md 和 design/ 目录下。
报 bug 和反馈的渠道：
| 渠道 | 适合场景 | 响应速度 | 要求 |
|---|---|---|---|
| GitHub Issues | 可复现的 bug、功能建议 | 通常 1-3 个工作日首次响应 | 提供复现步骤 |
| 微信社区群 | 使用问题、配置疑问、交流 | 社区成员随时互助 | 加群见官网 |
| 企业客户支持 | 企业部署、定制需求、SLA | 专人对接，协商响应时间 | 签约企业 |
| 官网反馈表单 | 不方便公开的反馈 | 3 个工作日内回复 | 留联系方式 |
谁在维护： wescode 由 weisyn 团队全职维护——不是兼职开源项目，是我们的主线产品。bug 修复不依赖社区志愿者的时间表。
Q: 报 bug 的最佳方式？
一份好的 bug 报告能让修复速度快 10 倍。推荐按这个模板来：
## Bug 描述
[一句话说明现象]
## 复现步骤
1. 打开 wescode，加载项目 xxx
2. 在 Chat 面板输入 "..."
3. 点击 xxx 按钮
4. 观察到 xxx 异常现象
## 期望行为
[应该发生什么]
## 实际行为
[实际发生了什么]
## 环境信息
- wescode 版本：[Help → About 里查看]
- 操作系统：macOS 15.3 / Ubuntu 24.04 / Windows 11
- 使用的模型：Claude Sonnet 4 / GPT-4o / 本地 Ollama
- Provider 类型：BYOK / WES 账户
## 附加信息
- 错误日志：[从 ~/.local/share/wescode/logs/ 复制相关片段]
- 截图/录屏：[如有]
关键提示： wescode 的日志文件在以下位置——
| 系统 | 路径 |
|---|---|
| macOS | ~/Library/Application Support/wescode/logs/wescode.log |
| Linux | ~/.local/share/wescode/logs/wescode.log |
日志里不含你的代码内容或 API Key，可以安全提交。
Q: bug 修复通常多快？
按严重程度分级：
P0——影响正常使用的阻断性 bug
- 例如：打开项目崩溃、AI 对话完全不响应、数据丢失
- 目标响应时间：24 小时内确认，72 小时内发布修复或临时方案
- 实际情况：这类 bug 极少出现，因为 wescode 的核心链路（编辑器 + 引擎）有持续的集成测试覆盖
P1——功能异常但有 workaround
- 例如：某个语言的 CKG 解析不准确、某个模型的流式响应偶尔中断
- 目标响应时间：一周内确认，两周内修复
P2——体验优化和小问题
- 例如：UI 文案、快捷键冲突、日志格式
- 随版本迭代修复，不单独出 hotfix
诚实说明： 以上是目标，不是 SLA。作为一个小团队，极端情况下（比如同时有多个 P0）响应可能会慢于目标。企业客户可以签约获取有约束力的 SLA。
Q: 遇到问题怎么自己先排查？
大部分常见问题不需要等官方回复——这里是 Top 5 问题和一行排查法：
问题 1：CKG 索引卡住了，状态栏一直转
# 检查是不是某个超大文件卡住了 tree-sitter
# 打开 wescode 日志查看最后在解析哪个文件
tail -50 ~/Library/Application\ Support/wescode/logs/wescode.log | grep "index"
# 解法：把大文件（proto 生成、SQL dump、打包产物）加到 files.exclude
问题 2：模型连接失败，AI 对话报错
# 最快的验证：直接 curl 你的 API 端点
curl -s https://api.deepseek.com/v1/models -H "Authorization: Bearer sk-your-key"
# 返回 JSON 说明 Key 没问题，是 wescode 配置问题
# 返回 401/403 说明 Key 本身有问题或过期了
问题 3：VS Code 插件装上了但不工作
排查路径：Help → Toggle Developer Tools → Console 看有没有插件报错。最常见的原因是插件版本不兼容 wescode 的基座版本——降级一个大版本试试。
问题 4：内存占用异常高（> 2GB）
# 检查是不是 CKG 索引了不该索引的目录
# 常见原因：node_modules 或 vendor 没被排除
# 解法：在 .vscode/settings.json 加 files.exclude
问题 5：CKG 调用图结果不准（漏掉了明显的调用方）
先确认你的语言在 CKG 深度支持列表里（Go/TS/Python/Java），然后检查文件扩展名是否被正确识别（状态栏右下角显示语言类型）。如果显示 "Plain Text"——装对应的 language extension 就好。
Q: 产品更新频率是多少？
wescode 目前处于快速迭代期，每 1-2 周发布一个版本。更新通过编辑器内置机制推送——跟 VS Code 的更新体验一样，弹窗提醒，点击重启即可。
你可以选择：
- 自动更新——始终保持最新版（推荐个人开发者）
- 手动更新——看到更新日志后决定是否升级
- 锁定版本——企业客户可以锁定特定版本，跳过不需要的更新（推荐生产环境）
版本号规则： 语义化版本号 MAJOR.MINOR.PATCH。MINOR 版本可能包含新功能和小的行为变化；PATCH 只修 bug。我们不会在 PATCH 版本里偷偷加新功能。
路线图透明度： wescode 的设计文档（design/ 目录）公开在代码仓库中。你能看到我们在做什么、为什么这么做、下一步计划是什么。这不是 marketing 路线图——是真实的工程设计文档，包含内部讨论和决策理由。
Q: 如果 wescode 团队跑路了怎么办？
合理的担忧。任何小团队产品都有这个风险。wescode 的几个结构性保障：
第一，你的数据全在本地。 wescode 的所有数据（CKG 索引、对话记忆、项目配置、会话历史）都是本地 SQLite 文件。即使 wescode 明天停止更新，这些数据你都能直接读取——它是标准的 SQLite 数据库，任何数据库工具都能打开。
第二，编辑器基座是 VS Code。 如果 wescode 不再维护，你可以随时切回 VS Code，装回原来的插件。你的代码、Git 历史、项目配置不受任何影响。
第三，BYOK 意味着没有锁定。 你的 API Key 是你的，模型供应商的合约是你签的。wescode 停了，Key 还能用在其他工具上。
第四，迁移成本极低。 wescode → VS Code 的迁移就是"打开 VS Code，安装之前的插件"。不存在导出数据、转换格式、适配接口这些问题。快捷键、设置、扩展——几乎所有东西都兼容。
Q: 跟 Cursor 的支持体系比呢？
Cursor 是一家融了大钱的硅谷公司，团队规模和资源都比 wescode 大得多——这是事实。他们的 bug 修复速度和产品迭代也很快。
但有几个结构性差异值得注意：
| 维度 | wescode | Cursor |
|---|---|---|
| 退出成本 | 极低——数据全在本地 | 索引和记忆跟 Cursor 账号绑定 |
| 中文支持 | 原生中文 bug 报告和社区 | 英文论坛 + Discord |
| 路线图透明度 | 设计文档公开，工程决策可追溯 | 对外不公开 |
| 数据留存 | 全部本地 SQLite | 部分数据在 Cursor 服务端 |
| 企业级 SLA | 可协商 | Business 版有 |
选型建议：如果你英语流利、不介意数据路径经过 Cursor 服务器、且预算充足，Cursor 的支持体系更成熟。如果你需要中文支持、数据不出本机、或者团队预算敏感，wescode 更适合。
Q: 企业客户有什么额外支持？
企业部署场景（内网部署、私有化模型、合规审计）提供：
- 专人技术支持——对接群、邮件、电话，不走公开社区
- 部署协助——内网环境下的 wescode + 本地模型集群部署
- SLA 承诺——可协商的响应时间和修复时间，白纸黑字
- 版本管理——企业版本分支，稳定优先，验证后再推送
- 安全审计——提供安全白皮书、数据流向说明、合规证明
具体方案根据企业规模和需求定制，通过官网联系获取报价。
Q: 工具本身有安全漏洞怎么办？
wescode 基于 VS Code 开源代码，VS Code 是全世界使用最广泛的编辑器之一，安全漏洞发现和修复的响应链非常成熟。wescode 定期跟进 VS Code 上游的安全修复。
wescode 自己的安全层面：
- CKG 引擎和 wesgine 完全在本地运行，不暴露任何网络端口（除非你手动配置了 HTTP 服务模式）
- API Key 存储 使用 AES-256-GCM 加密（
spec.key），即使数据文件被拷走也无法直接读取密钥 - 代码不出设备 的架构意味着攻击面比云端工具小得多——不存在"服务端被攻破泄露用户代码"的风险
Q: 我能不能参与 wescode 的开发？
可以。几种参与方式：
- 报 bug / 提建议——GitHub Issues 是最直接的方式
- 贡献 Skill——如果你写了好用的 AI 编程 Skill，可以提交到社区 Skill 库
- 写文档和教程——帮助更多人上手
- 参与测试——在新版本发布前帮忙验证
- 翻译和本地化——帮助支持更多语言
我们不避讳 wescode 是一个年轻的产品。社区小意味着反馈环路短——你今天报的 bug，明天可能就有人在改了。大产品的 issue 沉在几百个 open issue 里等排期；小团队的 issue 可能当天就被 assign。
Q: 从提 Issue 到用上修复版本，完整流程是什么？
一个真实的 bug 修复时间线（以 P1 级别为例）：
Day 1 上午：你在 GitHub 提了 Issue，附上复现步骤和日志
Day 1 下午：维护者确认 bug、标记优先级、开始排查
Day 2-3：修复代码、写测试、内部验证
Day 3-5：合入主线、构建新版本
Day 5-7：新版本发布（你会收到 Issue 通知）
如果你不想等正式版本： 你可以从 GitHub 的 main 分支自行构建最新版——修复合入主线后立刻可用，不需要等正式 release。
如果你有临时绕过方案： 大部分 P1 bug 都有 workaround（比如"某个语言的 CKG 不准"→ 暂时用 grep 兜底）。维护者在确认 Issue 时会给出临时方案。