有了 API 之后，开发什么产品？

从"把电机装进旧工厂"到"发明流水线"——AI 原生应用的思考、实践与落地。

---

一、核心类比：电机 → 工厂 → 流水线

100 多年前，工厂主们以为买来电机、替换掉蒸汽机，就是"现代化"了。但福特想的不是"如何给手工坊装电机"，而是如何让汽车流动起来——他因此发明了流水线，彻底改变了世界。

现在的 AI 应用，大多数还停留在"把电机装进旧工厂"的阶段：

• 用 AI 聊天窗口、AI 代码补全、AI 写邮件
• 工作流本身还是原来的样子
• 电灯代替了煤气灯，但房间结构没变

革命性改变不会来自"更好的电机"，而是来自围绕 AI 能力重新设计的流程、产品和人机协作模式。

---

二、从"单点替换"到"流程重构"的三种范式

范式	类比	例子	局限
嵌入现有流程（单点增效）	装电机	AI 写邮件、Copilot 写代码、ChatGPT 查资料	提升有限，不改变业务结构
重构子流程（局部自动化）	电机驱动传送带	AI 自动生成日报、自动回复客服、自动审查合同	显著减少重复劳动，仍需人监督
重塑业务逻辑（范式转移）	流水线	Notion AI 重新定义文档创作、Perplexity 重新定义搜索、GitHub Copilot Workspace 重新定义编码	用户行为、商业模型、价值交付方式全变了

判断标准：不是"这个功能能不能加个 AI"，而是：

“这个需求，如果让一个拥有无限耐心、超强记忆、能不间断工作的数字助手来满足，它会以什么形式存在？”

那个形式，就是你该动手的方向。

---

三、规范驱动：AI 真正的不可替代性

3.1 人的困境：价值观和执行力天然矛盾

人有价值观、有做事准则、有行业规范、有团队公约——这些都是经过反复讨论、深思熟虑后制定的。但问题在于：

• 人会累：加班到晚上 10 点，commit message 随便写一句 “fix bug” 就提交了
• 人会妥协：代码审查发现小问题，“算了这次先过，下次再说”
• 人会看人下菜：关系好的同事 PR 就松一点，不对付的就严一点
• 人会遗忘：三周前定的代码规范，写到一半就忘了，想起来时已经提交了
• 人会情绪化：今天心情不好，客户问题敷衍了事

规范写得再好，最终执行规范的也是人——而人是最不稳定的执行器。

这就是为什么很多团队的"规范"最终都沦为文档库里的装饰品。不是规范不好，是执行链条在人的环节断掉了。

3.2 AI 的特质：无条件的规范执行者

AI 恰恰弥补了这个缺陷。它不是智商有多高——它真正的不可替代性在于：

人的弱点	AI 的对应优势
会累，会偷懒	永不疲倦，第 1 次和第 1000 次执行标准完全一致
会被情绪左右	零情绪，不会因为心情不好降低标准
会被关系影响	不可贿赂，没有 Favoritism，对所有人都一个标准
会遗忘规则	超强记忆，所有规范一次性注入，永久生效
会嫌麻烦跳过步骤	任劳任怨，多复杂的检查清单都完整执行

这就是**规范驱动（Spec-Driven Development）**的核心：把人的价值观、做事规则、质量标准，编码成 AI 的 system prompt 和工具约束，让 AI 无条件、零偏差地执行。

人对规范的"忠诚度"永远不可能 100%。AI 可以。

3.3 这为什么是革命性的

回头看"电机和流水线"的类比：

• 电机替换了蒸汽机，但没有改变工人"想怎么拧螺丝就怎么拧"的事实
• 流水线真正改变的是——传送带设定了节奏，工人必须跟着节奏走。不是人在控制流程，是流程在控制人。

AI 就是知识工作的"传送带"。它不只是一台更快的电机，它是一个不会走神、不会偷懒、不会偏心、不会遗忘的流程守护者。

以前你和同事说"提交信息要按规范写"——这是人在要求人，执行靠自律。现在你把规范写进 Wingman 的 gitCommit 命令里，AI 每次都按同样的模板、同样的标准生成，人只需要确认。规范从"靠人自觉"变成了"靠系统保证"。

这就是革命性改变的真正引擎：不是 AI 比人聪明，而是 AI 比人可靠。

3.4 如何落地：把自己团队的规范"编码"进 AI

团队规范/价值观
      ↓
System Prompt（告诉 AI 你的标准是什么）
      ↓
工具约束（告诉 AI 能做什么、不能做什么）
      ↓
人在环审批（人做最终决策，AI 做执行和检查）

Wingman 的 gitCommit 命令已经实现了这个链条：

1. 提交信息规范写进配置（settings.json / CLAUDE.md / 默认格式）
2. AI 严格按模板生成（不会写 “fix bug”，一定会写 “fix(scope): 描述”）
3. 人在弹窗中确认或修改（人保留最终决策权）

下一步可以扩展的方向：

• 代码审查规范驱动：写死团队的 CR checklist 到 system prompt，AI 逐条检查
• 客户回复规范驱动：写死话术模板和红线规则，AI 生成回复绝不越界
• 测试用例规范驱动：写死覆盖率要求和边界条件模板，AI 生成用例从不遗漏

当规范变成代码、执行交给 AI，团队才真正从"人治"走向"法治"。

---

四、可着手的产品方向

方向一：个人/团队的"第二大脑"——本地知识引擎

痛点：每天消费和产生大量信息（文档、代码、聊天记录），90% 都流失了。现有工具基于关键词搜索或手动整理。

重构思路：不再是"搜索"，而是提问。所有数字痕迹自动被索引，随时用自然语言召回、总结、关联。

MVP：Ollama 本地模型 + 向量数据库（Chroma）+ 本地文件监控 → 私人知识助手。完全本地运行，不联网，隐私无忧。

方向二：本地 AI Agent——数字分身

痛点：很多周期性或条件触发的小任务，现在要靠多个工具 + 人脑记忆。

重构思路：不是"我打开软件去完成任务"，而是告诉 Agent 一个意图，它自己去组织工具、执行动作、汇报结果。

MVP：本地模型做意图识别 + Python 脚本调用系统 API，例如"帮我关注 arXiv 上关于 RAG 的最新论文，下载并写摘要发到邮箱"。

方向三：垂直领域的"AI 原生工具"

痛点：很多专业领域的工具还是"填空式"的，人花大量时间格式化和遵循规范。

重构思路：不让用户适应工具，而是用户说人话，AI 直接生成符合规范的完整交付物。

MVP：例如"AI 驱动的技术方案生成器"——输入需求，输出含架构图、技术选型、风险点的完整文档。

---

五、VSCode Agent 产品：由浅入深三级跳

Level 1：任务辅助型——“智能管道工”

AI 负责建议、检查、生成，但不直接改动代码。最低风险、最高实用价值。

产品	描述
AI 代码审查员	选中代码 → 右键 → “AI Review”，指出 bug、性能问题、优化建议
智能提交信息生成器	一键分析 git diff → 生成规范的 Commit Message
代码解读助手	选中晦涩代码 → 自然语言解释，生成 Mermaid 流程图
API/库用法问答	选中函数名 → 提问"怎么用？给个例子" → 回答写入注释或侧边栏

技术核心：VSCode API 获取选区 → 调用 AI API → 结果插入编辑区 / 注释 / Webview 面板。

最小量级：在已有插件上加一个命令，选中文本发给模型，返回写入新文件或输出通道。一晚上就能做出来。

Level 2：上下文感知型——“工作搭档”

AI 理解你的项目，能关联多个文件和历史，不只是看当前打开的文件。

产品	描述
项目问答助手	侧边栏聊天，只关于当前项目。"这个项目的认证逻辑怎么写？"→ 自动检索相关文件回答
智能 TODO 追踪器	扫描 TODO/FIXME 注释 → 生成任务卡片，列出涉及文件、建议优先级、解决草案
跨文件重构建议	修改函数签名 → 自动查找所有调用处 → 展示影响范围和同步修改建议

技术核心：RAG（本地向量数据库 Chroma/FAISS）+ VSCode 文件系统监听。本地 Ollama 做 embedding（保护代码隐私，零成本），云模型做复杂推理。

Level 3：自主 Agent 型——“AI 实习生”

AI 接受模糊的自然语言任务，自主规划步骤、读写文件、执行命令，人在循环中监督。这就是 Claude Code / Cline / Aider 的玩法。

产品	描述
任务驱动开发助手	"在 services 下新建 payment 模块，包含微信支付和退款方法，更新路由"→ Agent 分解任务、创建文件、运行编译、自动修复错误
Bug 修复工作流	粘贴报错日志 → Agent 搜索相关文件 → 定位问题 → 生成 fix → 编译验证 → 展示 diff
Docker 化一条龙	"让这个项目能 Docker 部署"→ 分析项目类型 → 生成 Dockerfile + docker-compose.yml → 尝试构建验证

技术核心：Agent 循环（计划 → 执行 → 观察 → 修订），工具集（读写文件、执行 Shell、搜索代码），VSCode diff/apply 接口，人在环中审批。

---

六、技术栈搭配

功能	本地 Ollama（qwen2.5:1.5b）	云 API（DeepSeek V4 等）
代码摘要、注释生成、简单解释	✅ 够用且极快	复杂情况做后备
跨文件重构建议、项目级问答	✅ 检索和筛选相关文件	✅ 需要强推理时使用
复杂逻辑解读、安全漏洞分析	—	✅ 需要深度理解
文件索引（embedding）	✅ 全本地，保护隐私	不需要
Agent 复杂规划与工具调用	可能不够	✅ 主流方案用强模型

关键 VSCode API：

• vscode.window.activeTextEditor — 获取编辑器
• vscode.workspace.fs — 读写文件
• vscode.commands.executeCommand — 执行内置命令
• vscode.window.createWebviewPanel — 创建侧边栏
• vscode.window.showInformationMessage + Modal — 审批交互

辅助库：openai（调用 DeepSeek/Ollama）、chromadb / lanceDB（本地向量数据库）、tree-sitter（代码 AST 解析）

---

七、实战：Wingman 插件开发

上述 Level 1 的理论，已经落地为第一个 VSCode 插件——Wingman。以下是其工程结构和核心设计。

7.1 插件概览

项目	说明
插件名	Wingman — “Your AI coding wingman”
核心能力	选中代码 → 右键 → AI 解释 / AI 生成提交信息
调用模型	DeepSeek API（deepseek-chat）
交互方式	右键菜单（编辑器 + 文件资源管理器双入口）

7.2 工程结构

my-first-plug/
├── package.json              ← 命令注册 + 右键菜单 + 配置项
└── src/
    ├── extension.ts          ← 插件入口，统一注册所有命令
    ├── deepseek.ts           ← DeepSeek API 客户端封装（共享模块）
    ├── logger.ts             ← 统一日志输出到 OutputChannel "Wingman"
    └── commands/
        ├── uppercase/        ← 入门练手命令（选中文本转大写）
        ├── explainCode/      ← AI 解释代码
        └── gitCommit/        ← AI 生成提交信息并提交

每个命令独立一个目录，共享模块（deepseek.ts、logger.ts）放在 src/ 根目录，避免重复代码。

7.3 三个命令

① wingman.uppercase — 入门练手

选中文本 → 右键 → 转换成大写。用于验证插件框架跑通，不涉及 AI。

② wingman.explainCode — 代码解释（Level 1）

选中代码 → 右键 → "Wingman: DeepSeek 解释代码"
  → 进度条提示 "DeepSeek 正在解释代码..."
  → 新标签页打开结果（原始代码 + 中文解释）

核心流程：editor.selection 获取代码 → openai.chat.completions.create 调用 DeepSeek → workspace.openTextDocument 展示结果。

③ wingman.gitCommit — 智能提交（Level 1 + 人在环）

右键菜单 → "Wingman: AI 生成提交信息并提交"
  → 检查是否为 Git 仓库
  → 获取 git diff（含未跟踪文件）
  → 调用 DeepSeek 生成符合规范的提交信息
  → 弹窗展示，用户选择：确认提交 / 修改后提交 / 取消
  → 自动 git add + git commit

7.4 关键设计决策

右键菜单双入口：在 package.json 中同时注册 editor/context（编辑器右键）和 explorer/context（文件浏览器右键），gitCommit 两个入口都可用。

"menus": {
  "editor/context": [
    { "command": "wingman.explainCode", "group": "navigation", "when": "editorHasSelection" },
    { "command": "wingman.gitCommit",     "group": "navigation" }
  ],
  "explorer/context": [
    { "command": "wingman.gitCommit",     "group": "navigation" }
  ]
}

提交信息格式的三级优先级：

settings.json 中 wingman.commitFormat 配置（最高优先级）
  ↓ 未配置
工作区 CLAUDE.md 中的 "Git 提交信息格式" 段落
  ↓ 未找到
内置默认格式（约定式提交 + 中文 + 关键文件列表）

人在环审批：AI 生成提交信息后，弹出模态对话框让用户确认/修改/取消，不跳过人直接提交。这是 Level 1 产品的核心安全边界。

全链路日志：所有命令关键节点都通过 log() 输出到 OutputChannel Wingman（Ctrl+Shift+U 可查看），同时写 console.log。方便调试和排查 API 调用失败原因。

7.5 从模板到产品的演进

这个插件的开发路径，就是文档前面描述的 Level 1 起步路线：从最简单的 uppercase 验证框架 → explainCode 跑通 AI 调用 → gitCommit 加上人在环审批和配置系统。三周计划的第一周目标已经达成。

下一步演进方向（Level 2）：为插件加上项目上下文感知——用本地 Ollama 做文件索引，让 explainCode 不再是孤立看一段代码，而是能关联项目中的相关文件给出更准确的解释。

---

八、具体启动路线

第一周：Level 1 起步 ✅

• 选一个每天遇到的痛点（写 commit message 烦/看代码累）
• 跑通最小闭环：命令注册 → 右键菜单 → 调用 API → 展示结果
• 目标：在 VSCode 里能跑，自己真的用起来

第二周：Level 2 升级

• 用本地 Ollama 做 embedding，把项目文件索引到 Chroma（全本地，零成本）
• 目标：能针对项目提问，回答能指出相关文件路径和代码片段

第三周：Level 3 探索

• 从"解释"变成"生成"，完成一个"接收指令 → 修改/创建文件 → 展示 diff → 用户可接受"的最小 Agent
• 目标：跑通完整闭环

---

九、核心理念

不要去想"这个功能能不能加个 AI"，而是想：

“这个需求，如果让一个拥有无限耐心、超强记忆、能不间断工作的数字助手来满足，它会以什么形式存在？”

那个形式，就是你该动手的方向。

从一个小环节开始，把它做到极致，让它成为自己和身边人离不开的东西。Wingman 插件的 gitCommit 命令就是一个例子——它重构了"写 commit message"这个子流程：从对着 diff 绞尽脑汁 → AI 生成草案 → 人审核确认。你不需要一上来就造整条流水线，从一个小环节改起，就能亲眼看到"小提升"如何汇聚成一场静悄悄的变革。

---