GitHub的Spec Kit上线三年， slash命令（斜杠指令）依然是唯一交互方式。用户想生成需求文档，得先记住/speckit.specify，看完输出再敲/speckit.plan——全程无进度条、无审批流、无视觉反馈。Amazon的Kiro倒是做了可视化，但强制绑定自家大模型，还得抛弃VS Code转投定制版编辑器。
一个独立开发者算过账：前者 workflow（工作流）残缺，后者自由受限。他花了数周写出一个170KB的插件，把可视化、多模型切换、企业级权限全塞进原生VS Code。上线两周，这款叫Caramelo的工具在开发者社群被反复提及。
「宪法」先于代码：把团队规矩写进AI上下文
Caramelo的第一步不是生成需求，而是让用户定义「宪法」——那些不可协商的原则。手动输入或让AI生成均可，比如「所有功能必须包含错误处理」「TDD强制要求」「引入外部依赖需 justification（正当理由）」。
这些原则会自动注入每一次AI生成的上下文。开发者不再需要反复粘贴同样的prompt（提示词）。一位早期用户反馈，团队把代码审查 checklist（检查清单）写进宪法后，AI生成的任务描述通过率从60%跳到90%。
对比Spec Kit的 slash 命令链，Caramelo把流程拆成五个可视化阶段：需求定义→技术规格→实施计划→任务拆解→验证清单。每个阶段必须人工点击批准，下游才会解锁。如果回头修改上游内容，下游阶段会被标记为「过期」——这个状态同步机制用颜色变化和图标提示实现，无需阅读文档即可感知。
实时渲染是另一个差异点。LLM输出内容时，用户看到的是逐字流式呈现，而非等待完整响应。批准前可随时手动编辑，或要求重新生成。这种「半自动」模式介于完全手动和全自动之间，被设计者称为「人在回路中的最小必要干预」。
多模型切换：个人API密钥与企业代理共存
Caramelo的模型配置界面允许同一服务商的多份凭证并存。典型场景是：「Claude Personal」走个人API密钥，「Claude MyCompany」走企业代理——不同端点、不同鉴权头、不同前缀。点击圆点指示器即可切换，模型列表从API实时拉取，或手动输入并自动校验。
技术实现上，开发者只写了约150行流式代码，覆盖两类LLM接口：OpenAI兼容格式和Anthropic原生格式，外加Copilot的vscode.lm API。他提到一个被低估的痛点：企业LLM接入的混乱程度。「不同API管理器使用不同的鉴权头名称和前缀」，让每提供商可配置这些参数，是获得企业用户的关键。
体积控制是刻意为之。整个插件打包后约170KB，核心依赖VS Code的WebviewView API——单个webview面板替代了原本需要三个TreeView（树形视图）才能实现的功能。表单、进度环、任务清单、行内编辑，全部用纯HTML/CSS完成，没有引入前端框架。
状态驱动渲染是另一个技术取舍。早期版本尝试通过postMessage注入表单元素，但refresh()会销毁事件监听器导致崩溃。最终方案是把编辑状态存入状态机，由状态变化触发重绘——代码量变多，但稳定性大幅提升。
Jira集成与任务可执行性：从文档到工单
对于使用Jira的团队，Caramelo在规格卡片上显示关联的Jira徽章，点击直接跳转对应issue（事务）。生成的任务不是静态文档，而是包含验收标准、预估工时、依赖关系的结构化数据——足够直接导入项目管理工具。
验证阶段提供三种检查：规格与原始需求的一致性、代码实现与规格的匹配度、测试覆盖率是否达标。全部功能收敛在编辑器工具栏的猫形图标下拉菜单中，保持界面整洁。
开发者透露，这个设计来自对「工具栏污染」的执念。VS Code扩展生态的通病是各自抢占工具栏空间，Caramelo选择用单一下拉菜单聚合所有入口，即使功能持续增加，视觉负担不线性增长。
GitHub Spec Kit的团队尚未公开回应这款第三方工具。一个值得观察的变量是：微软是否会将类似的可视化workflow纳入官方路线图——毕竟Caramelo证明，在原生VS Code内实现这些功能，技术上并无障碍。
你现在用的AI编程工具，是更喜欢 slash 命令的简洁，还是可视化的可控？
热门跟贴