AI编程 on Kalend's Blog

Kiro IDE上手：AWS的Spec驱动编程，和Cursor/Claude Code有何不同

Fri, 31 Jul 2026 08:30:00 +0800

当所有AI IDE都在比谁生成代码更快时，Kiro说：先停下来写需求文档。

先说结论

Kiro是AWS推出的Agentic AI IDE，2025年7月预览、2026年5月正式版。它基于VS Code (Code OSS)，和Cursor、Windsurf同源。

但Kiro的核心卖点不是"写代码更快"，而是Spec-Driven Development——先规划后执行。这和Cursor的对话式编程、Claude Code的终端式Agent形成了三种截然不同的方法论。

值得试，但不必all-in。Free tier 50 credits够体验Spec模式。

一、Kiro是什么？AWS为什么要做IDE

Kiro（读作 keer-oh）的官方口号是"Move beyond AI coding to agentic engineering"。

翻译成人话：别再vibe coding了，该升级了。

AWS做IDE的战略意图很明确——从云基础设施延伸到开发者工具链。你用Kiro写代码，部署大概率用AWS，形成闭环。

技术栈上，Kiro基于Code OSS（VS Code 的开源版本），和Cursor、Windsurf是同一个底座。如果你用过VS Code，上手零成本。

52+ 个内置集成（Figma、Postman、Datadog、Stripe、Supabase、Terraform等），AWS生态的优势在这里体现得很明显。

二、Spec-Driven Development——Kiro的核心差异

这是Kiro和其他所有AI IDE的最大区别。

什么是Spec？ 就是把"一句话需求"拆成三份结构化文档：

阶段	产出文件	内容
Requirements	requirements.md	用户故事 + 验收标准
Design	design.md	技术架构 + 序列图 + 数据流
Tasks	tasks.md	可追踪的离散任务列表

两种Spec类型：

Feature Specs：构建新功能，支持Requirements-First和Design-First两种变体
Bugfix Specs：系统化诊断和修复bug，防止回归

还有个Quick Spec模式，跳过审批门，一步生成全部三个文件。适合赶工期的场景。

和Cursor的本质区别是什么？

Cursor是"边聊边写"——你和AI对话，AI直接吐代码。快，但容易失控。需求改了，之前生成的代码可能全废。

Kiro是"先规划后执行"——需求锁定、设计评审、任务拆分，然后才开始写代码。慢一点，但每一步都有文档可追溯。

类比：Cursor像直接上手做饭，边做边尝；Kiro像先写菜谱，再按步骤执行。前者灵活但不可复制，后者可复制但缺灵活性。

这个区别对个人hack影响不大，但对团队协作意义重大。Spec可共享，产品经理和工程师可以在同一份文档上协作。

三、并行Agent + 正确性验证

并行Agent执行

Kiro是少数内置并行Agent的AI IDE——它会分析tasks.md的依赖关系，构建依赖图，然后把独立任务分组为Wave。

Wave之间顺序执行，Wave内任务并发。理论上比逐个执行快很多。

Property-Based Testing

这个很有意思。Kiro不只跑单元测试，还用属性测试（property-based testing）做正确性验证。

区别在哪？单元测试是"输入A，期望输出B"。属性测试是"对任意输入，这个规则都应该成立"。

比如一个排序函数，单元测试可能测5个case都过了，但属性测试会随机生成1000个数组，验证"输出是否始终有序"这种不变量。

Kiro甚至在写代码前就用自动推理技术检查需求的矛盾和缺口。这是"测试左移"做到极致的体现。

Agent Hooks

基于触发器自动执行任务。比如提交代码时自动跑单测、更新文档。类似Git Hooks，但由AI执行。

四、多端统一 + 模型生态

四端支持

端	特点
IDE	桌面端，macOS/Windows/Linux
CLI	终端工作流，bash/zsh/fish + 500+ CLI 自动补全
Web	浏览器端，云端沙箱，关机后继续运行
Mobile	iOS

Web端很关键——云端沙箱意味着你可以在手机上启动一个任务，关掉电脑，让它在云端跑完。这对长时间构建场景很实用。

模型生态

Kiro的模型丰富度在AI IDE里属于第一梯队：

Auto模式（推荐）：自动为每个任务选最优模型，综合考虑质量、延迟、成本。

Anthropic Claude全系：从Haiku 4.5（0.4x credit）到Opus 5（2.2x，实验性），覆盖所有场景。上下文最高1M tokens。

OpenAI GPT-5.6 首次登陆（7/13）：三个变体——Sol（2.4x，最难任务）、Terra（1.2x，日常开发）、Luna（0.6x，性价比）。

开源/开放权重模型：

Qwen3 Coder Next（0.05x，最便宜）
DeepSeek 3.2（0.25x）
MiniMax M2.1/M2.5（0.15x-0.25x）
GLM-5（0.5x）

开源模型的credit倍率极低，Qwen3 Coder Next只要0.05x，适合 CLI 长时间跑 Agent。

开放标准

支持ACP（Agent Client Protocol）、AGENTS.md、Skills.md、MCP。VS Code 扩展和设置可直接导入。

五、定价与性价比分析

计划	月费	Credits	模型权限
Free	$0	50	开源模型 + Claude Sonnet 4.5
Pro	$20	1,000	全部模型
Pro+	$40	2,000	全部模型
Pro Max	$100	5,000	全部模型
Power	$200	10,000	全部模型

关键细节：

超额购买：$0.04/credit（个人版手动购买，团队版可自动超额）
新用户首充送$20 credit
学生计划：1,000 credits/月，免费1年
月度重置，未用credits不累积

和Cursor对比：Cursor Pro也是$20/月，但不按credit计费，按请求次数。Kiro的credit制更透明——你可以精确知道每个操作花了多少钱。

不同模型消耗credit的倍率不同。同一个任务，用Sonnet 4.6是Auto的1.3x，用Opus是2.2x，用Qwen3 Coder Next只有0.05x。

实际体感：Pro $20/月1000 credits，如果主要用Auto模式，日常开发够用。如果频繁用Opus做复杂任务，可能不够。

六、和Cursor/Claude Code的实操对比

方法论差异

维度	Kiro	Cursor	Claude Code
方法论	Spec-Driven + Vibe双模式	Chat-Based + Tab补全	纯对话式Agent
形态	IDE + CLI + Web + Mobile	IDE	CLI
开发流程	需求→设计→任务→实现	对话→代码生成	对话→代码生成
文档化	自动生成三份Spec文档	无内置文档化	依赖AGENTS.md
并行Agent	内置依赖图+Wave并发	无内置并行	无内置并行
正确性验证	Property-based testing	依赖单元测试	依赖单元测试
模型选择	多厂商多模型	多厂商	仅Claude
定价	$0-200/月，credit制	$0-40/月	按token计费

适合场景对比

选Kiro的场景：

团队协作，需要结构化开发流程
需求复杂，需要先规划再执行
重视文档化，Spec可作为项目资产
已在AWS生态内

选Cursor的场景：

个人开发，快速原型
习惯对话式交互，边聊边写
预算敏感（$20/月固定，不按量计费）
需要Tab补全这种细粒度辅助

选Claude Code的场景：

终端党，不想离开命令行
只信任Claude模型
需要深度理解大型代码库
按token计费对轻度用户更划算

七、结论与建议

Kiro的真正价值不是IDE本身，而是Spec方法论。

你完全可以在Cursor里用类似的工作流——先让AI写需求文档，再拆任务，再逐个实现。但Kiro把这个流程产品化了，自动化了，并且加了并行Agent和属性测试。

我的建议：

先用Free tier体验Spec模式，看看"先写需求再写代码"是否适合你的工作方式
如果你已经在用Cursor且满意，不必急着切换——Spec方法论可以手动在Cursor里实践
团队场景值得重点评估——Spec可共享这点是Cursor和Claude Code都没有的
开源模型的credit倍率极低（Qwen3 0.05x），预算有限可以主打开源模型

AWS入场AI IDE，最大的意义不是多了一个选择，而是把"Spec-Driven"这个概念推到了台面上。不管最终用不用Kiro，“先规划后执行"这个思路值得每个开发者思考。

作者：varkm

Claude Code、Codex、OpenCode、ZCode 四款AI编程Agent怎么选：工具是方法论的载体

Sat, 11 Jul 2026 08:00:00 +0800

Claude Code 对应 Context Engineering 阶段，Codex 对应安全工程阶段，OpenCode 对应自由探索阶段，ZCode 对应可视化协作阶段。四款工具不是同一赛道的四匹马，而是四个方法论阶段的代表作。选工具之前，先搞清楚你想停在哪个阶段。

为什么"选工具=选阶段"

Vibe Coding → Context Coding → Agentic Engineering，这是 AI 编程方法论的三阶进化。我在之前的文章里详细拆过这三个阶段的演进逻辑，这里只说核心：每个阶段对"人机协作的信任边界"定义完全不同。

Vibe Coding 阶段，你把 AI 当高级自动补全，写一行说一行。Context Coding 阶段，你给 AI 写一份"施工图纸"，让它按图执行。Agentic Engineering 阶段，你给 AI 一个目标和约束，让它自己规划路径。

四款工具的设计哲学，恰好对应这四个坐标点。

Claude Code：Context Engineering 的代表作

Claude Code 的核心设计哲学是"先规划后执行"。

CLAUDE.md 文件是它的核心。在项目根目录放一个 CLAUDE.md，写清楚项目架构、编码规范、关键约束，Claude Code 在每次对话开始时自动加载。这不是一个配置文件，这是一份"工程合同"——你和 AI 之间的权责边界白纸黑字写在上面。

Permission mode 是另一个关键设计。开启 plan-first 模式后，Claude Code 在做多文件重构之前会先输出一份 Plan 文档，你审批通过后才动手。这不是多余的步骤，这是 Context Engineering 的核心：让 AI 先把思路亮出来，人类确认方向正确再执行。

Headless 模式支持无人值守，配合 Git worktrees 可以让 Claude Code 在独立分支上干活，不影响你的主分支。MCP 协议集成让它能连接外部工具链。

模型方面，Opus 4.8 是目前推理能力最强的编码模型，适合架构级决策。Sonnet 5 更快，适合日常编码。上下文策略是激进压缩——保留用户消息不动，压缩模型自己的历史输出。

定价：Pro $20/月，Max $200/月，或 API 按量付费。

适合场景：大型项目重构、架构级修改、需要深度推理的多文件协同变更。如果你的项目超过 5 万行代码，Claude Code 的 Context Engineering 能力是四款里最强的。

Codex CLI：安全优先的工程实践

Codex CLI 的设计哲学是"不信任但验证"。

三级审批模式是它的核心卖点。suggest 模式只给建议不改文件，auto-edit 模式可以自动修改代码但不执行命令，full-auto 才是完全自主执行。这三级模式不是可选的装饰，而是默认的安全策略。你不需要记住哪些操作需要审批，沙箱自动帮你隔离风险。

--ask-for-approval 参数控制审批粒度。你可以设置"修改文件前必须确认"，也可以设置"只在执行危险命令时确认"。粒度完全由你控制。

并行 Agent 能力是 Codex 的另一个优势。你可以同时启动多个 Agent 处理不同任务，它们各自在独立沙箱里运行，互不干扰。

模型方面，GPT-5.6 是 OpenAI 最新发布的模型家族，针对编码场景有专门优化。上下文策略是"用户消息一字不动，模型自己的全部可压"——和 Claude Code 的激进压缩有微妙但重要的区别。

定价包含在 ChatGPT Plus/Pro 订阅中，或 API 按量付费。CLI 本身开源。

适合场景：安全敏感的企业环境、需要并行执行多个编码任务、已经在 OpenAI 生态里的团队。

OpenCode：最大自由度的开源方案

OpenCode 的设计哲学是"你的模型，你的规则"。

BYOK（Bring Your Own Key）支持 75+ 个 LLM 提供商。你可以接 OpenAI、Anthropic、Google，也可以接国产模型——DeepSeek、Qwen、GLM 都行。这意味着你可以用同一个工具，在不同项目里用不同模型，成本完全可控。

它自带 Zen 模型精选，是社区维护的"针对编程优化过的模型推荐列表"。不知道选什么模型的时候，Zen 列表是个不错的起点。

Subagent 架构支持子代理并行。隐私优先设计保证数据不离开本地。桌面版目前在 Beta 阶段，降低了 CLI 的使用门槛。

上下文管理采用"可逆隐藏"策略——历史对话不会被真正删除，理论上可以恢复。这在需要回溯 AI 决策过程时很有价值。

180K+ GitHub Stars 说明社区认可度。免费开源，模型费用自付。接国产模型的话，日常编码成本可以压到接近零。

适合场景：预算敏感、想用国产模型、隐私优先、中等规模项目（1-2 万行）。但要注意：项目超过 5 万行或有复杂跨模块依赖时，OpenCode 的 orchestration 层不如 Claude Code 流畅。

ZCode 3.0：可视化的国产方案

ZCode 3.0 的设计哲学是"把开发流程塞进桌面应用"。

它是四款里唯一的桌面 ADE（Agentic Development Environment）。不想用 CLI？不想配环境变量？打开桌面应用就能开始写代码。这个定位对非终端用户非常友好。

GLM-5.2 是智谱自研的旗舰模型，1M 上下文窗口。作为原生适配的模型，ZCode 对 GLM-5.2 的调用效率和效果优化是其他工具接 API 做不到的。

多 Agent 协作和技能系统（Skills）是 ZCode 的差异化特性。需求理解 → 计划拆解 → 代码修改 → 验证，全流程在可视化界面里完成。

定价：首次 5 天免费，每天 300 万 token，之后走 GLM Coding Plan 订阅。

适合场景：不想用 CLI 的开发者、中文场景、想免费体验国产最强编程模型。

方法论适配度对比

维度	Claude Code	Codex CLI	OpenCode	ZCode
安全模型	Permission mode 审批制	三级审批模式隔离	本地优先不外传	桌面隔离
上下文策略	激进压缩，保留用户消息	保留用户消息，压缩模型输出	可逆隐藏，历史可恢复	桌面界面管理
模型灵活度	仅 Claude 系列	仅 GPT 系列	75+ 提供商自由切换	仅 GLM 系列
交互形态	终端优先	终端 + VSCode	终端 + 桌面(Beta) + IDE	桌面 ADE
并行能力	Headless + worktrees	并行 Agent	Subagent 架构	多 Agent 协作
学习曲线	中（需写 CLAUDE.md）	低	中	低（可视化）
开源	否	CLI 开源	完全开源	否
中文优化	一般	一般	一般	原生支持

决策树：四条路径，选哪条

你重视安全隔离吗？ 在企业环境里写代码，或者处理敏感数据，需要沙箱级别的权限隔离 → 选 Codex CLI。

你重视推理深度吗？ 项目规模大、架构复杂、需要 AI 先理解全局再动手，愿意花时间写 CLAUDE.md → 选 Claude Code。

你重视模型自由度和预算吗？ 想在不同项目里用不同模型，或者想接国产模型把成本压到接近零，项目规模中等 → 选 OpenCode。

你不想用 CLI / 要中文优化吗？ 不想配环境、不想记命令、想要可视化界面、中文场景优先 → 选 ZCode。

如果以上四条你都犹豫，说明你还在 Vibe Coding 阶段——用什么都行，先用起来再说。等你写够 5000 行 AI 辅助代码之后，自然知道自己需要什么。

结论

没有"最好的工具"，只有"最适合你阶段的工具"。Claude Code 的 CLAUDE.md 是工程纪律，Codex 的沙箱是安全底线，OpenCode 的 BYOK 是自由选择，ZCode 的可视化是降低门槛。这四款工具更新很快，但方法论的演进方向不会变：从"我说你做"到"你理解我的意图自己做"。

varkm

Vibe Coding 三阶进化：从「帮我写代码」到「Agent 自己干」，你还在第几层？

Sun, 05 Jul 2026 10:00:00 +0800

Karpathy 自己都认输了

2025 年 2 月，他发了条推文。

给这种编程方式起了个名字——Vibe Coding。

原话是「完全沉浸在氛围中，忘记代码」。

一年后，画风突变。

2026 年 4 月 AI Ascent 大会上，他说：

「从没觉得自己这么落后过。」

不是我危言耸听。

这套方法论，已经偷偷迭代了三代。

而大多数人，还停在第一代。

一、三阶进化：你卡在哪一层？

直接上结论，三张面孔一目了然：

阶段	核心理念	典型操作	致命问题
1.0 氛围编程	忘记代码，只管描述	「帮我写个登录页」	代码不可控，质量靠运气
2.0 Context Coding	上下文工程决定产出质量	写 AGENTS.md、喂规则文件	需要前期投入，但 ROI 极高
3.0 Agentic Engineering	Agent 自主拆解+执行+验证	给目标，它自己规划编码测试	需要信任，但也要审查机制

1.0 氛围编程：祈祷式开发

你输入一句话，AI 吐出一坨代码。

你不懂，也不敢改。

能跑就谢天谢地，跑不了就再问一次。

本质上是在赌博。

赌运气好，赌 AI 今天状态在线。

像让实习生独自交付核心模块，你连 review 都跳过了。

2.0 Context Coding：给 AI 一本操作手册

你开始写规则文件。

告诉它项目用 React 不用 Vue。

告诉它提交前必须跑测试。

告诉它哪些目录不能动。

质量从玄学变成了工程。

同一个需求，有没有上下文，产出天差地别。

这一层的 ROI 最高，投入一小时能省十小时返工。

3.0 Agentic Engineering：当 AI 成了你的同事

你不再描述「怎么做」。

你只说「做什么」。

Agent 自己拆任务、写代码、跑测试、提 PR。

你只需要审查结果，而不是审查每一行。

这是质变，不是量变。

但别误会，信任不等于放任。

二、四款工具方法论适配度横评

先说清楚：这不是工具评测。

是看每款工具，把你推向哪个阶段。

维度	Claude Code	Codex CLI	OpenCode	ZCode
背景	Anthropic 官方	OpenAI 官方	开源社区（18万+ Star）	智谱（GLM-5.2 原生）
方法论适配	2.0→3.0	3.0	2.0	2.0→3.0
杀手锏	跨会话记忆、CLAUDE.md 上下文工程	沙箱隔离+自主执行	模型自由度最高	可视化操作、国产模型原生适配
适合谁	重度开发者	安全敏感场景	想自选模型、预算敏感	国内开发者、不想折腾 CLI

Claude Code：上下文工程的教科书

它最懂「规则文件」这件事。

你写好 CLAUDE.md，它能记住项目约定。

跨会话不遗忘，连续性极强。

适配阶段 2.0→3.0，是渐进式升级的最佳载体。

适合愿意投入上下文工程的重度开发者。

Codex CLI：安全第一的执行机器

OpenAI 的安全基因刻在骨子里。

默认沙箱隔离，不碰敏感文件。

它会自主执行，但你始终能拉住缰绳。

适配阶段 3.0，但「不信任但验证」做得最彻底。

适合金融、安全敏感场景的用户。

OpenCode：模型自由度之王

18 万 Star 的开源社区在背后。

75+ 模型可选，想用哪个用哪个。

但自由度高也意味着——上下文你得自己搭。

适配阶段 2.0，灵活但需要自配规则。

适合预算敏感、想掌控模型选择的开发者。

ZCode：国产模型的原生适配者

智谱出品，GLM-5.2 模型原生集成。

可视化操作界面，不用对着黑框敲命令。

对国内开发者友好，理解中文需求更精准。

适配阶段 2.0→3.0，ADE 一体化做得好。

适合不想折腾 CLI、偏好可视化操作的人。

三、不绑定工具的四条心法

工具会换代，方法论不会。

这才是 2026 年真正该学的东西。

心法一：写好 AGENTS.md 比选对工具重要十倍

Context Engineering 是所有工具的底层逻辑。

不管你用 Claude Code 还是 Codex，底层都一样。

同一款工具，有上下文文件和没有，产出质量天差地别。

这就像同一个实习生，给他项目文档和不给他，结果完全不同。

你的规则文件，就是 AI 的入职手册。写得越细，产出越稳。

心法二：任务拆解粒度决定成败

小任务直接描述：修个 bug、加个按钮。

大任务先出方案：重构模块、新功能，确认后再执行。

一口气丢个大需求，结果一定让你崩溃。

Agent 会按自己的理解拆解，往往跟你想的完全不一样。

小步快跑，永远比一次梭哈靠谱。

心法三：审查 ≠ 不信任

Agent 产出必须验证，这不是不信任。

是 Code Review 的 Agent 化。

不看每一行代码，但要跑测试、查边界、review 关键逻辑。

信任是给空间的，验证是兜底的。两者不矛盾。

心法四：迭代循环，不是一次生成完事

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


┌──────────────────────────────────────┐
│ Vibe Coding 迭代闭环 │
│ │
│ ┌──────┐ ┌──────┐ ┌──────┐ │
│ │ 生成 │───▶│ 验证 │───▶│ 修正 │ │
│ └──────┘ └──────┘ └──────┘ │
│ ▲ │ │
│ └────────────────────────┘ │
│ 再验证 │
└──────────────────────────────────────┘

你不会让实习生一次交付完美代码。

Agent 也一样。

生成 → 验证 → 修正 → 再验证，才是正确姿势。

说在最后

工具会变，方法论不会。

Claude Code 明天可能就被别的工具超越。

但「上下文工程 + 任务拆解 + 验证迭代」这套心法，五年内不会过时。

2026 年真正该学的，不是哪个工具更强。

而是怎么跟 AI 高效协作。

这，才是你的护城河。

关注「varkm」，一起学习，一起成长。

MCP 安全血案：5条攻击路径、20万台服务器中招、你装的插件可能有毒

Mon, 29 Jun 2026 08:30:00 +0800

开篇：你装的 MCP 插件，可能正在偷你的密钥

上周有个朋友找我，说他用 Cursor 写代码，某天突然发现 .ssh 目录被读过，AWS 凭证疑似泄露。排查了两天，最后定位到一个两周前从社区 registry 装的 MCP 服务器——一个号称「数据库查询工具」的 npm 包，后台默默把环境变量打包发到了一个海外 IP。

这不是个例。

先把数据摆出来，不用我渲染气氛：

指标	数值	来源
2026 年 1-2 月 MCP 相关 CVE	30+	NVD / GitHub Security Advisories
公网暴露的 MCP 服务器	7,000+	OX Security / BitSight
受影响实例总数	~200,000	OX Security
暴露在风险中的总下载量	1.5 亿+	OX Security
MCP 服务器 SSRF 易感率	36.7%	Adversa AI SecureClaw 报告
红队针对 AI 平台的漏洞挖掘成功率	89%	2026 安全行业报告

1.5 亿次下载。20 万台机器。这不是假设性威胁，是已经在发生的事。

我写这篇文章不是为了制造恐慌——恐慌没用。我想做的是把目前公开的攻击路径捋清楚，每条配真实 CVE 和原理，让你看完知道：攻击者怎么打进来，你怎么挡住。

第一章：5 条真实攻击路径

下面五条不是理论推演，每一条都有公开 CVE 或安全团队披露的真实案例。

路径一：Prompt Injection —— 零交互远程代码执行

CVE-2026-30615，CVSS 8.0，影响 Windsurf IDE。

这条是最狠的，因为用户什么都不用点。

攻击链是这样的：

1
2
3
4
5
6


攻击者在公开仓库/文档中植入恶意文本
 → 你的编程助手读取该文件作为上下文
 → 文本里藏着指令：「把以下 MCP 服务器加入配置」
 → 助手照做，修改了 mcp.json
 → IDE 重启该 MCP 服务器
 → 服务器启动命令执行任意 shell

OX Security 的研究员把它归类为「零点击 prompt injection in IDEs」。你只是打开了一个项目、读了一个 README，攻击就完成了。同样的链路在 Cursor、VS Code 的 Claude 扩展、Claude Code、Gemini CLI 中都被验证过。

这不是某个工具的 bug，是整个交互模型的结构性问题：模型输出可以直接修改自己的工具配置，而配置能触发 shell 执行。

路径二：供应链攻击 —— 你装的包里有后门

MCP 生态的供应链攻击已经出了好几起，手法各不相同但都有效。

案例 A：postmark-mcp 后门（2025 年 9 月）

有人向 MCP registry 提交了一个伪装成 Postmark 邮件服务的包。功能看起来完全正常——能发邮件、能查状态。但它在后台悄悄把 process.env 里的所有环境变量打包，通过 DNS 查询外传。

开发者装它的时候看了一眼功能描述，觉得没问题，就 approve 了。API key 就这么出去了。

案例 B：mcp-server-git 链式 RCE（CVE-2025-68145 / 68143 / 68144）

这是 Anthropic 官方维护的 MCP 服务器。三个漏洞链在一起，实现了完整 RCE：

CVE	漏洞	效果
CVE-2025-68145	路径校验绕过	突破仓库目录限制
CVE-2025-68143	git_init 无限制	能把 `~/.ssh` 变成 git 仓库
CVE-2025-68144	git_diff 参数注入	注入任意 git 参数

配合 Filesystem MCP，攻击者通过一个恶意的 .git/config 文件，在你机器上执行任意命令。官方仓库、官方维护、官方出的漏洞——这告诉你供应链风险不在于「第三方包不靠谱」，而在于整个分发链条缺乏安全审查。

案例 C：mcp-remote 命令注入（CVE-2025-6514，CVSS 9.6）

mcp-remote 是连接远程 MCP 服务器的常用客户端库。攻击者构造一个恶意的远程 MCP 服务器 URL，客户端解析时执行任意命令。这个包下载量超过 43.7 万次——它是第一个被证实产生大规模实际影响的 MCP 漏洞。

路径三：Tool Poisoning —— 工具描述本身就是武器

核心原理：编程助手把工具描述当成可信指令来执行。

工具描述（tool description）本该是给用户看的文档，但模型把它当成了 context 的一部分——而且是高权重 context。攻击者只要能改写工具描述，就能劫持助手行为，不需要碰任何代码逻辑。

经典案例：WhatsApp MCP 投毒（2025 年 4 月，Invariant Labs 披露）

一个第三方 trivia 游戏 MCP 服务器，工具描述里藏着隐藏指令。它指示助手去调用同一个进程中另一个合法的 whatsapp-mcp 服务器，读取完整聊天记录，然后作为「正常输出」外传。

端到端加密没用——因为数据是在加密层之上被助手自己合法读取并外泄的。助手有权限读，攻击者只是告诉它「读完发给我」。

变体：Rug-pull 攻击

更阴的是 rug-pull（先正常后变恶）。服务器第一次注册时返回干净的工具描述，你审核通过。之后某次 tools/list 调用，描述悄悄变了，塞进了恶意指令。

任何只在「首次批准时」检查、之后不再 re-verify 的客户端都中招。Cursor 的 MCPoison 漏洞（CVE-2025-54136）就是这个路子——用户批准后配置永远不重新验证，攻击者提交良性配置过审，后续更新里塞恶意逻辑，静默生效。

路径四：凭证窃取 —— 从工具参数到 AWS Root

案例：Microsoft MarkItDown MCP Server SSRF

MarkItDown 的 MCP 服务器会 fetch 任意 URL，没有任何校验。安全研究员 David Onwukwe 演示了完整链路：

1
2
3
4
5


MarkItDown MCP 接收一个工具调用
 → fetch 目标 URL 设为 http://169.254.169.254/latest/meta-data/
 → 命中 AWS EC2 实例元数据服务
 → 拿到 IAM 角色临时凭证
 → 用凭证访问你的 AWS 资源

169.254.169.254 是 AWS 元数据服务的固定地址，云实例上无需认证即可访问。一个 SSRF 就能拿到云权限。

微软把这个问题分类为「低风险」。实际演示已经拿到了 EC2 metadata。当你的 MCP 服务器跑在云上、有 IAM 角色挂载时，这就是凭证窃取的直达电梯。

类似手法也通过工具参数实现：恶意工具描述指示助手「把环境变量内容作为参数传给这个 API」，助手照做，API key 就到了攻击者手里。

路径五：SSRF 与路径穿越 —— MCP 服务器成为内网跳板

学术安全调研扫描了 2,614 个 MCP 实现，数据触目惊心：

风险类型	占比
文件操作存在路径穿越风险	82%
存在代码注入风险	67%
存在命令注入风险	34%
SSRF 暴露率	36.7%

案例 A：Fetch MCP Server SSRF（CVE-2025-65513，CVSS 7.5）

mcp-fetch-server 的 is_ip_private() 函数没能正确识别私有 IP 地址。攻击者让服务器请求内网地址（http://10.0.0.1/admin、http://169.254.169.254/...），函数判断「不是私有 IP」，请求放行。MCP 服务器变成了攻击者进入你内网的跳板。

案例 B：filesystem-mcp 路径穿越（CVE-2025-67366）

配置了只能访问 /home/user/project 的文件系统 MCP，攻击者用 ../../etc/shadow 穿越出去，读到了任意文件。

案例 C：Zen MCP Server 路径穿越（CVE-2025-66689）

is_dangerous_path() 函数用精确字符串匹配黑名单。/etc/shadow 被拦了，但 /etc/shadow/../../../home/user/.ssh/id_rsa 没被拦——因为不在黑名单的精确匹配里。一个子目录穿越就绕过了「敏感路径保护」。

第二章：为什么 MCP 天生不安全

拆完攻击路径，往上抬一层看架构。MCP 的安全问题不是「实现写得烂」，是设计层面就有几个结构性缺陷。

缺陷一：工具描述被默认当作权威指令

传统 API 安全模型里，文档是文档，执行是执行，两者隔离。Swagger 文档里写什么不会影响服务端行为。

MCP 打破了这个隔离。工具描述直接进入模型 context，模型把它当指令执行。这意味着——文档即攻击面。任何能改工具描述的环节（服务器更新、中间人、供应链）都等于拿到了模型的部分控制权。

缺陷二：服务器代码跑在你机器上，但行为由远程定义

MCP 服务器作为子进程跑在你本地，有你用户的全部权限——能读 .ssh、能读 .aws、能访问内网。但它的行为逻辑（工具定义、执行逻辑）由远程 npm/PyPI 包决定，随时可以更新。

你的机器提供了权限和信任，远程服务提供了行为，两者之间没有隔离层。这就像你在自己家里装了一个别人能远程操控的锁。

缺陷三：没有人工审核的默认信任链

多数 MCP 客户端用「首次信任」（TOFU）模型。你第一次批准一个服务器，之后它的所有更新和工具调用默认放行，不再重新验证。Cursor 的 MCPoison 就是钻了这个空子。

工具调用链可以跨安全域：一个你信任的 MCP 服务器，被恶意指令引导去调用另一个你授权的 MCP 服务器，数据就跨域流动了。上面 WhatsApp 投毒就是这个模式。

缺陷四：协议规范只管传输，不管安全

MCP 规范定义了消息格式和传输层（stdio / SSE），但认证、响应完整性、审计——全是生态各自为政。82% 的实现有路径穿越风险，不是因为开发者菜，是因为协议没提供安全基线，每个人都在重新发明轮子，而且发明得都不好。

第三章：真实伤亡清单

把受影响面拉个清单，让你知道自己在不在射程内。

IDE / 编程工具全线中招：

工具	受影响情况
Cursor	MCPoison 信任绕过（CVE-2025-54136）
VS Code（Claude 扩展）	零点击 prompt injection 链
Windsurf	CVE-2026-30615，CVSS 8.0 RCE
Claude Code	通过 hooks/MCP config/env 攻击链
Gemini CLI	MCP 工具链受影响
LangChain / LangFlow / Flowise	未认证 UI 注入 RCE
LiteLLM	CVE-2025-45809，SQL 注入

OX Security 评估：这些工具背后的 MCP 生态总下载量超过 1.5 亿次，约 20 万个实例存在被利用风险。

Anthropic 对核心设计缺陷的回应是：「这是设计行为，sanitize 是开发者的责任。」

vulnerablemcp.info 数据库现状：

社区维护的漏洞数据库 The Vulnerable MCP Project 已收录 50+ 个漏洞，其中 13 个评为 Critical。这个数字还在涨，每周都有新 CVE 进来。

如果你在生产环境跑 MCP 服务器，或者哪怕只是在本地用 Cursor 配了几个 MCP 插件，你都在这个射程内。

第四章：开发者自保指南

不废话，直接上操作。

5 条核心防护措施

1. 审查你装的每一个 MCP 服务器

1
2
3
4
5
6
7
8
9


# 查看当前配置的所有 MCP 服务器
# Cursor: Settings → MCP
# Claude Code: ~/.claude/mcp.json
# VS Code: 命令面板 → "MCP: List Servers"

# 检查 git 历史里有没有可疑改动
git log --all --since="2 weeks ago" -- mcp.json

# 移除不用的服务器——每一个都是攻击面

对于每一个服务器：确认发布者身份、检查 GitHub 仓库近期活跃度和 issue 区有没有安全报告。不认识的服务器，删掉。

2. 沙箱隔离

MCP 服务器进程不该有你用户的所有权限。

1
2
3
4
5
6
7


# 用 Docker 跑，只挂载项目目录，不挂 ~/.ssh、~/.aws
docker run -it --rm \
 -v $(pwd):/workspace \
 -w /workspace \
 your-mcp-server

# 或者用 Dev Container，VS Code 原生支持

原则：MCP 进程不该接触到「泄露了会很惨」的凭证。

3. 最小权限

API key 用只读 scope，别给 root key
文件系统 MCP 限定到项目目录，别给 home 目录
网络 MCP 加出站白名单，别让它随便 fetch
用了之后立刻 revoke 不再需要的凭证

4. 固定版本，不用 @latest

1
2
3
4
5


# 危险
npx @some-package/mcp-server@latest

# 正确——锁定具体版本
npx @some-package/mcp-server@1.2.3

供应链 rug-pull 靠的就是你无感知地拉到恶意更新。锁版本 + 监控更新日志，至少能让你知道什么时候变了。

5. 用 mcp-scan 做安全扫描

Invariant Labs 出的 mcp-scan 是目前最实用的免费工具：

1
2
3
4
5
6
7
8


# 需要 Python 3.10+ 和 uv
curl -LsSf https://astral.sh/uv/install.sh | sh

# 扫描你的 MCP 配置，自动检测工具投毒和已知漏洞
uvx mcp-scan

# CI/CD 集成——发现 critical 问题直接失败
uvx mcp-scan --exit-code

它能检测工具描述里的投毒指标、匹配已知漏洞数据库、检查版本是否受影响。30 秒跑完，建议每周扫一次。

MCP 服务器选型 Checklist

检查项	通过标准
发布者身份	可验证的 GitHub 组织/个人，有历史信誉
源码可审	公开仓库，能读到完整源码
活跃度	近 3 个月有提交，issue 有回应
认证机制	有 auth 层，不裸奔
权限范围	只请求必要权限，不做 read+write 全要
社区反馈	搜索 CVE + 安全报告，无未修复的高危项

工具	类型	用途
mcp-scan	免费开源	工具投毒检测 + 漏洞匹配
Snyk Agent Scan	免费/付费	依赖链漏洞扫描，CI/CD 集成
SecureClaw	企业级	55 项审计，合规报告
agent-audit	开源	OWASP Agentic Top 10 对标审计

第五章：总结与展望

先说结论：MCP 的安全不是「以后再说」的事，是现在就得管的事。

30 个 CVE 用 60 天砸下来，已经把 MCP 从「有前景的开放标准」打成了「活跃攻击面」。而根因——工具描述当指令执行、远程定义本地行为、协议不管安全——不是修几个 bug 能解决的。

好在社区在动：

协议层：MCP 规范团队在推内置认证标准、工具描述签名、服务器 attestation。这些能从根源上解决工具投毒和供应链问题，但落地还要几个月。
Registry 审查：主要 MCP registry 在上线发布者验证 + 自动安全扫描，供应链风险会降但不会消失。
客户端防御：越来越多客户端加了细粒度权限控制和定期 re-verify，TOFU 模型在松动。

但这些都是未来的事。今天的现实是：你装的 MCP 插件可能有毒，你配的服务器可能暴露在公网，你的凭证可能已经被打包外传了。

你现在该做的三件事：

打开你的 IDE MCP 设置，删掉所有不认识的服务器
跑一遍 uvx mcp-scan，修掉 critical 项
把敏感凭证从 MCP 进程能触及的环境里挪走

做完这三步，你的风险面至少砍掉一大半。剩下的，等协议和工具成熟。

安全从来不是等来的，是防出来的。MCP 生态还在野蛮生长，你不变靶子，就只能自己穿甲。

数据来源：OX Security 供应链 advisory、The Vulnerable MCP Project（vulnerablemcp.info）、Adversa AI SecureClaw 报告、Invariant Labs 工具投毒披露、NVD/GitHub Security Advisories。 CVE 详情可在对应数据库查询。

ChromaDB + Python：5分钟搭建个人知识库

Wed, 24 Jun 2026 08:30:00 +0800

上一篇用 FAISS 搭语义搜索引擎，有人问我：有没有不用自己管索引文件的方案？有，ChromaDB 就是为这个场景生的。

先说结论

ChromaDB 是面向开发者的"零配置"向量数据库。pip install 就能用，不需要 Docker，不需要外部服务，自带持久化，支持元数据过滤，几行代码接入 embedding 模型。

一句话定位：向量数据库里的 SQLite。

如果你只是想快速搭一个知识库、文档搜索、RAG 原型，ChromaDB 是门槛最低的选择。等数据量到百万级、需要高并发了，再考虑 Qdrant 或 Milvus。

向量数据库 60 秒科普

上一篇 FAISS 文章讲过原理，这里用图书馆的类比快速过一遍。

你去图书馆找书，有两种方式：

索引卡方式（关键词搜索）：翻目录卡片，按书名精确匹配。搜"Python 入门"只能找到标题里有这几个字的书
问管理员方式（语义搜索）：跟管理员说"我想学编程"，他理解你的意思，给你推荐相关的书，不管书名叫什么

向量数据库干的就是"管理员"的活。它把每条文档编码成向量（一串数字），搜索时把你的查询也编码成向量，然后计算向量间的距离找最接近的。

ChromaDB 在此基础上多做了一件事：它把这些向量连同原始文本和元数据一起存好，不用你操心存储细节。FAISS 是搜索库，你得自己管存储；ChromaDB 是完整数据库，存储、索引、元数据一站式搞定。

5 分钟快速上手

第一步：安装

1

pip install chromadb

ChromaDB 自带一个内置 embedding 模型（all-MiniLM-L6-v2），英文场景开箱即用。但如果你处理中文，建议额外装一个中文模型：

1

pip install chromadb sentence-transformers

sentence-transformers 提供了丰富的中文 embedding 模型，下面的代码我会用它接入 BAAI/bge-small-zh-v1.5（约 100MB，首次自动下载）。

第二步：创建客户端和集合

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


import chromadb
from chromadb.utils.embedding_functions import SentenceTransformerEmbeddingFunction

# 用中文 embedding 模型（默认模型偏英文，中文效果差）
ef = SentenceTransformerEmbeddingFunction(model_name="BAAI/bge-small-zh-v1.5")

# 创建持久化客户端，数据会保存到本地目录
client = chromadb.PersistentClient(path="./my_knowledge_base")

# 创建集合时指定 embedding 函数
collection = client.get_or_create_collection(
 name="my_docs",
 embedding_function=ef
)

PersistentClient 和 FAISS 的最大区别：数据自动落盘。程序关了再开，数据还在。不用手动 write_index / read_index，不用维护"索引 ID → 原始文本"的映射表。

底层存储用的是 SQLite 数据库（chroma.sqlite3），向量索引用二进制文件存储，全部放在你指定的 path 目录下。这意味着你甚至可以用 sqlite3 直接查看元数据，备份只需要拷贝整个目录。

如果你只想做内存测试，用 chromadb.Client() 即可，退出即丢。

第三步：添加文档

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18


# 添加文档，ChromaDB 自动帮你做 embedding
collection.add(
 documents=[
 "Python 是一门解释型编程语言，语法简洁易读",
 "Java 是面向对象的编程语言，跨平台运行",
 "今天天气真不错，适合出门散步",
 "如何申请退款？请在订单页面点击退款按钮",
 "我想把钱退回来，应该怎么操作",
 ],
 metadatas=[
 {"category": "编程", "source": "wiki"},
 {"category": "编程", "source": "wiki"},
 {"category": "生活", "source": "diary"},
 {"category": "客服", "source": "faq"},
 {"category": "客服", "source": "faq"},
 ],
 ids=["doc1", "doc2", "doc3", "doc4", "doc5"]
)

注意：这里指定了中文 embedding 模型，add() 的时候 ChromaDB 自动把文本转成向量存进去。ChromaDB 内置的默认模型（all-MiniLM-L6-v2）偏英文，对中文语义理解较差，所以处理中文数据时强烈建议换成中文模型。

第四步：查询

1
2
3
4
5
6
7
8


# 语义搜索
results = collection.query(
 query_texts=["编程语言有哪些"],
 n_results=3
)

for doc, dist in zip(results["documents"][0], results["distances"][0]):
 print(f"[距离: {dist:.4f}] {doc}")

输出：

1
2
3


[距离: 0.3133] Java 是面向对象的编程语言，跨平台运行
[距离: 0.3375] Python 是一门解释型编程语言，语法简洁易读
[距离: 0.7588] 今天天气真不错，适合出门散步

搜"编程语言有哪些"，前两条命中 Python 和 Java，第三条天气明显不相关。距离越小越相似。

补充一点：distances 返回的是向量距离，不是相似度分数。ChromaDB 默认用余弦距离，值域 [0, 2]，0 表示完全一致，2 表示完全相反。实际使用中，距离小于 1.0 的结果通常比较相关，大于 1.2 就可以当噪音忽略了。

第五步：元数据过滤

这是 ChromaDB 相比 FAISS 的杀手级功能——先筛选再搜索。

1
2
3
4
5
6
7
8


# 只在"客服"分类里搜索
results = collection.query(
 query_texts=["退款"],
 n_results=5,
 where={"category": "客服"}
)

print(results["documents"][0])

输出：

1

['如何申请退款？请在订单页面点击退款按钮', '我想把钱退回来，应该怎么操作']

where 条件支持 $eq（等于）、$ne（不等于）、$in（包含）等操作符：

1
2
3
4
5
6
7
8


# 多值过滤
where={"category": {"$in": ["编程", "客服"]}}

# 复合条件
where={"$and": [
 {"source": "faq"},
 {"category": "客服"}
]}

想象一个场景：你有 10000 篇文档，10 个分类。用户只想搜"技术"分类下的内容。FAISS 需要你自己实现过滤逻辑，ChromaDB 一个 where 参数搞定。

完整实战：搭建个人知识库

把上面的模块组合起来，做一个能增删查的迷你知识库：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68


import chromadb
from chromadb.utils.embedding_functions import SentenceTransformerEmbeddingFunction
import time

class KnowledgeBase:
 def __init__(self, db_path="./my_kb"):
 self.client = chromadb.PersistentClient(path=db_path)
 ef = SentenceTransformerEmbeddingFunction(model_name="BAAI/bge-small-zh-v1.5")
 self.collection = self.client.get_or_create_collection(
 name="notes", embedding_function=ef
 )

 def add(self, text, category="未分类", doc_id=None):
 """添加一条笔记"""
 if doc_id is None:
 doc_id = f"note_{int(time.time()*1000)}"
 self.collection.add(
 documents=[text],
 metadatas=[{"category": category}],
 ids=[doc_id]
 )
 return doc_id

 def search(self, query, n=5, category=None):
 """语义搜索，可选按分类过滤"""
 where = {"category": category} if category else None
 results = self.collection.query(
 query_texts=[query],
 n_results=n,
 where=where
 )
 hits = []
 for doc, dist, meta in zip(
 results["documents"][0],
 results["distances"][0],
 results["metadatas"][0]
 ):
 hits.append({"text": doc, "distance": dist, "meta": meta})
 return hits

 def count(self):
 return self.collection.count()

# ========== 使用示例 ==========
kb = KnowledgeBase()

# 批量添加笔记
notes = [
 ("Python 列表推导式比 for 循环快，因为底层用 C 实现", "Python"),
 ("Git rebase 会重写提交历史，谨慎在公共分支使用", "Git"),
 ("Docker 容器隔离靠 namespace 和 cgroups", "Docker"),
 ("Python 装饰器本质是接受函数返回函数的高阶函数", "Python"),
 ("Git stash 暂存当前工作区改动，不提交到分支", "Git"),
]
for text, cat in notes:
 kb.add(text, category=cat)

print(f"知识库共 {kb.count()} 条笔记\n")

# 语义搜索：搜"循环优化"
print("=== 搜索: 循环优化 ===")
for hit in kb.search("循环优化", n=3):
 print(f" [{hit['meta']['category']}] {hit['text']}")

# 搜索：只在 Git 分类下搜
print("\n=== 搜索: 分支管理 (仅 Git) ===")
for hit in kb.search("分支管理", n=3, category="Git"):
 print(f" [{hit['meta']['category']}] {hit['text']}")

运行后重启程序，数据还在——因为 PersistentClient 自动落盘了。这就是 ChromaDB 和 FAISS 最大的体验差异：你不用管索引文件，数据自己活着。

补充两个实用技巧：

批量添加比逐条添加快得多。上面的示例为了清晰逐条 add()，实际使用时建议一次传入列表：

1
2
3
4
5
6


# 批量添加，比循环 add() 快 10 倍以上
collection.add(
 documents=["文档1", "文档2", "文档3"],
 metadatas=[{"cat": "a"}, {"cat": "b"}, {"cat": "c"}],
 ids=["d1", "d2", "d3"]
)

换更强的中文模型。如果你的数据量更大、精度要求更高，可以把 bge-small-zh-v1.5 换成 BAAI/bge-large-zh-v1.5（1024 维，约 1.3GB）。注意：同一个集合内不能混用不同模型，换模型必须新建集合。

选型对比：ChromaDB vs FAISS vs Qdrant

维度	ChromaDB	FAISS	Qdrant
部署方式	pip install，零配置	pip install，纯库	需 Docker 或独立服务
内置 embedding	有（all-MiniLM-L6-v2）	无，需自己编码	无
持久化	自动落盘	手动 save/load	自动
元数据过滤	where 条件，开箱即用	无，需自己实现	有，filter API
适用规模	<100万	任意（看索引类型）	千万级
典型场景	知识库、RAG 原型	高性能向量搜索	生产级语义搜索

我的选型建议：

个人知识库、文档搜索、RAG 原型 → ChromaDB。零配置，内置 embedding，5 分钟跑通
纯追求搜索速度、数据量可控 → FAISS。最轻最快，但要自己管存储和元数据
生产环境、高并发、需要精确过滤 → Qdrant。功能全性能好，代价是要部署一个服务

一句话总结：个人和原型用 ChromaDB，生产高并发用 Qdrant，纯速度用 FAISS。

结语

ChromaDB 的定位很清晰：向量数据库里的 SQLite。不需要服务端，不需要 Docker，pip install 之后几行代码就能跑，数据自动持久化，接入 embedding 模型就能开箱即用。

它不追求极限性能，不追求分布式高可用，但它把"存储 + 索引 + embedding + 元数据过滤"打包成一个极简的包。对于个人知识库、文档语义搜索、RAG 原型验证这些场景，ChromaDB 是目前最省心的选择。Python 开发者十分钟就能搭出一个能用的知识库，这个门槛在两年前是不可想象的。

上一篇 FAISS 文章解决了"怎么把向量搜得快"，这一篇解决了"怎么用得省心"。两者互补：FAISS 适合想完全掌控底层细节的极客，ChromaDB 适合想快速出结果的开发者。如果你刚接触向量检索，建议从 ChromaDB 开始——先跑通流程，理解语义搜索的价值，再根据实际需求决定是否需要换到 FAISS 或 Qdrant。

试试用自己的文档笔记跑一遍上面的代码，把日常积累的技术笔记、读书摘录、工作文档丢进去，你会发现语义搜索比关键词搜索好用太多。搜"性能优化"能找到"降低延迟"的笔记，搜"部署"能找到"Docker 配置"的记录——这在传统的搜索方式下几乎不可能。

关注 varkm，一起学习，一起成长

别再用 LIKE 搜数据库了：20 行代码搭一个语义搜索引擎

Sun, 21 Jun 2026 08:53:00 +0800

你在文档里搜"退款"，结果一个都没有。但文档里明明写着"我想退钱"。

先说结论

传统搜索靠关键词匹配，搜"退款"找不到"退钱"，因为机器只认字不认意思。

向量检索把文字变成数字（向量），按语义相似度搜索。搜"退款"能命中"我想退钱"，因为它俩意思一样。

Sentence-Transformers 负责编码，FAISS 负责搜索。

20 行 Python，搭一个比 MySQL LIKE 强 100 倍的语义搜索引擎。数据量从一千条到十亿条，都有对应的方案。

下面我从原理到代码，一步步带你跑通。

第一章：向量检索是什么（3 分钟搞懂原理）

文本变向量：让机器理解"意思"

embedding（嵌入）把一段文字编码成一串数字，比如 768 维的浮点数组。

这串数字就是文字的"语义指纹"。意思相近的文字，指纹也相近；意思无关的文字，指纹差很远。

“退款"和"退钱"的关键词不同，但编码出来的向量非常接近。“退款"和"天气预报"的向量则差了十万八千里。

相似度怎么算：余弦 vs L2

算两个向量有多接近，常用两种方式：

方式	原理	特点
余弦相似度	算向量夹角的余弦值	值域 [-1,1]，越大越相似
L2 距离	算欧氏距离	值域 [0,∞)，越小越相似

大多数语义搜索场景用余弦相似度。配合向量归一化（让每个向量的长度变成 1），余弦相似度等价于向量内积，计算更快。

为什么不用 MySQL LIKE

LIKE 做的是字面匹配。搜"退款”，数据库遍历每一条记录，看有没有"退"和"款"这两个字挨在一起。

“如何申请退款” → 命中 ✓
“我想把钱退回来” → 不命中 ✗
“退订服务” → 不命中 ✗

但这三条说的是同一件事。LIKE 的本质缺陷：它不理解语义，只匹配字符。

向量检索的思路完全不同：先把所有文本编码成向量，搜索时把查询也编码成向量，然后找最近的几个。它匹配的是"意思”，不是"字面"。

第二章：Sentence-Transformers — 让文本变成向量

安装和一行代码上手

1

pip install sentence-transformers faiss-cpu

加载模型、编码文本，三行搞定：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


from sentence_transformers import SentenceTransformer

# 加载中文 embedding 模型
model = SentenceTransformer('BAAI/bge-small-zh-v1.5')

# 把文本编码成向量
texts = ["如何申请退款", "我想把钱退回来", "今天天气不错"]
embeddings = model.encode(texts)

print(embeddings.shape) # (3, 512) — 3条文本，每条512维

输出 (3, 512) 表示 3 条文本各编码成了 512 维的向量。

中文模型怎么选

这是新手最纠结的问题。我直接给你结论：

模型	维度	大小	适用场景
bge-small-zh-v1.5	512	~100MB	入门首选，速度快
m3e-base	768	~210MB	社区流行，中文适配好
bge-large-zh-v1.5	1024	~1.3GB	精度最高，生产推荐
BGE-m3	1024	~2.3GB	多语言+多功能，最强

我的建议：学习阶段用 bge-small-zh-v1.5，小快够用。上生产了换 bge-large-zh-v1.5 或 BGE-m3。

避坑：维度不一致不能混用

这是 90% 的新手会踩的坑。

bge-small 输出 512 维，m3e-base 输出 768 维。

如果你用 bge-small 建了索引，后来换成 m3e-base 编码查询，FAISS 直接报错——维度对不上。

规则：编码模型和建索引模型必须是同一个。换模型 = 重建索引，没有例外。

第三章：FAISS — 让向量搜起来飞快

安装

1
2


pip install faiss-cpu # CPU 版，够用
# pip install faiss-gpu # GPU 版，百万级以上考虑

3 分钟跑通第一个索引

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19


import faiss
import numpy as np

# 假设你已经有 1000 条文本的向量（512维）
embeddings = np.random.rand(1000, 512).astype('float32')

# 建立索引
dim = 512
index = faiss.IndexFlatL2(dim)
index.add(embeddings)

print(f"索引中有 {index.ntotal} 条向量") # 1000

# 搜索：找最相似的 5 条
query = np.random.rand(1, 512).astype('float32')
distances, indices = index.search(query, k=5)

print("最相似的5条索引:", indices[0])
print("对应的L2距离:", distances[0])

四种索引类型决策树

这是这篇文章的核心价值。FAISS 有十几种索引，但 99% 的场景只需要搞懂这四种：

索引类型	数据量级	速度	精度	典型场景
IndexFlatL2	<10万	慢	100%精确	原型开发、小数据
IndexIVFFlat	百万级	快	近似（可调）	中等规模生产
IndexHNSWFlat	千万级	最快	高召回率	低延迟在线搜索
IndexIVFPQ	十亿级	快	有损压缩	超大规模+省内存

怎么选：别想太多，从 IndexFlatL2 开始。数据量到 10 万条以后再考虑换。

我把四种索引的适用场景画个决策路径：

1
2
3
4
5
6
7
8
9


你的数据有多少条？
│
├── < 10万 → IndexFlatL2（暴力搜索，100%精确，不用调参）
│
├── 10万~100万 → IndexIVFFlat（聚类分区，平衡速度和精度）
│
├── 100万~1000万 → IndexHNSWFlat（图索引，速度最快）
│
└── > 1000万 → IndexIVFPQ（乘积量化压缩，省内存）

索引的保存和加载

90% 的新手忘的一步。程序退出，内存里的索引就没了。

1
2
3
4
5


# 保存索引到磁盘
faiss.write_index(index, "my_index.faiss")

# 下次直接加载，不用重新编码
index = faiss.read_index("my_index.faiss")

注意：FAISS 只保存向量和索引结构，不保存原始文本。你需要自己维护一个"索引ID → 原始文本"的映射（比如存一个 JSON 或列表）。

第四章：实战 — 搭一个能用的中文语义搜索引擎

完整可运行代码

下面这段代码复制就能跑。我准备了 10 条模拟 FAQ 数据，展示语义搜索的效果。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54


from sentence_transformers import SentenceTransformer
import faiss
import numpy as np
import time

# ========== 1. 准备数据 ==========
faqs = [
 "如何申请退款？请在订单页面点击申请退款按钮。",
 "我想把钱退回来，应该怎么操作？",
 "退款多久能到账？一般3-5个工作日。",
 "取消订单的步骤是什么？进入我的订单，选择取消。",
 "怎么取消已经付款的购买？联系客服处理。",
 "会员到期了怎么续费？在设置中点击续费。",
 "密码忘记了怎么找回？点击登录页的忘记密码。",
 "怎么修改绑定的手机号？在账户安全设置中修改。",
 "发票怎么开具？订单完成后在详情页申请。",
 "如何投诉服务质量？请联系客服热线反馈。",
]

# ========== 2. 编码 ==========
model = SentenceTransformer('BAAI/bge-small-zh-v1.5')
embeddings = model.encode(faqs, normalize_embeddings=True)
dim = embeddings.shape[1]

# ========== 3. 建索引（内积相似度 = 归一化后的余弦相似度）==========
index = faiss.IndexFlatIP(dim)
index.add(embeddings.astype('float32'))

# ========== 4. 搜索 ==========
def search(query, top_k=3):
 query_vec = model.encode([query], normalize_embeddings=True)
 scores, indices = index.search(query_vec.astype('float32'), top_k)
 
 print(f"\n搜索: '{query}'")
 print("-" * 50)
 for i, idx in enumerate(indices[0]):
 score = scores[0][i]
 print(f" [{score:.4f}] {faqs[idx]}")
 return indices[0]

# ========== 5. 效果展示 ==========
search("退款")
search("怎么把钱退回来")
search("取消购买")
search("续费会员")

# ========== 6. 性能测试 ==========
start = time.time()
for _ in range(1000):
 query_vec = model.encode(["测试查询"], normalize_embeddings=True)
 index.search(query_vec.astype('float32'), 5)
elapsed = time.time() - start
print(f"\n1000次搜索耗时: {elapsed:.2f}s (含编码时间)")
print(f"平均每次(含编码): 约 {elapsed/1000*1000:.2f}ms")

运行效果

搜"退款"命中"如何申请退款"和"我想把钱退回来"——关键词完全不同，但语义命中。

搜"取消购买"命中"怎么取消已经付款的购买"和"取消订单的步骤"——“取消"和"购买"拆开了照样匹配。

这就是语义搜索的威力：它理解意思，不依赖关键词重合。

性能数据

10 条数据的搜索时间几乎为 0（亚毫秒级）。扩展到 1000 条，纯索引搜索（不含编码）仍在 1ms 以内。

对比 MySQL LIKE 查询 1000 条记录，需要全表扫描 + 逐行字符匹配，通常在 5-50ms。向量检索在语义理解上有质的飞跃，速度也不逊色。

第五章：数据量增长后怎么办

索引迁移路径

数据量增长到一定程度，IndexFlatL2 的暴力搜索会变慢。这时候该换索引了：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


IndexFlatL2 (暴力)
 │
 │ 数据量 > 10万，搜索开始变慢
 ▼
IndexIVFFlat (聚类分区)
 │
 │ 数据量 > 100万，需要更高吞吐
 ▼
IndexHNSWFlat (图索引)
 │
 │ 数据量 > 1000万，内存吃紧
 ▼
IndexIVFPQ (乘积量化)

切换时机：当你感觉搜索延迟不可接受（比如超过 100ms）的时候，就该考虑换索引了。不要过早优化。

FAISS vs 其他方案

FAISS 是一个搜索库，不是完整的数据库。它没有增删改查 API，没有持久化层，需要你自己管理。

如果不想自己管这些，可以考虑封装好的向量数据库：

方案	类型	适用规模	特点
FAISS	嵌入式库	任意	轻量无依赖，需自己管持久化
ChromaDB	轻量数据库	<100万	开箱即用，内置持久化
Qdrant	数据库	千万级	Rust 写的，高性能，API 友好
Milvus	分布式数据库	十亿级	生产级，支持分布式

我的建议：原型阶段用 FAISS，够轻够快。产品化了再按需升级。别一上来就上 Milvus，运维成本会吃掉你。

核心建议

别过早优化。从 IndexFlatL2 开始，能跑就先跑着。

等数据量真到了瓶颈再换索引，迁移成本远低于你从第一天就过度设计的成本。这句话适用于 99% 的项目。

结论

向量检索不是黑魔法。

Sentence-Transformers 把文本编码成向量，FAISS 把向量搜得飞快。两个库，20 行代码，你就拥有了一个能理解语义的搜索引擎。

搜"退款"能找到"退钱”，搜"取消购买"能命中"取消订单"。这就是语义搜索和关键词搜索的本质区别。

记住三个要点：从 IndexFlatL2 开始、编码模型和索引维度必须一致、别忘了保存索引到磁盘。

剩下的，动手跑一遍代码就懂了。

关注 varkm，一起学习，一起成长

用 DeepSeek V4 做 Vibe Coding：免费平替 Claude Code？

Sun, 14 Jun 2026 10:00:00 +0800

Claude Code 的输出价格是每百万 tokens 25 美元。

DeepSeek V4-Pro 是每百万 6 块人民币。

差距大约 29 倍。

这不是标题党，是实打实的账单差异。

Claude Code 确实强，终端里跟一个资深工程师结对编程，体验拉满。但每个月烧几百美刀，还得搞海外信用卡。封号风险像悬在头上的刀。

DeepSeek V4 发布后，编程能力已经能打了。我花了几天时间实测了三种方案。

让 DeepSeek V4 驱动 Claude Code、Cline、Aider，逐一对比。

什么是 Vibe Coding？就是用自然语言描述需求，让 AI 帮你写代码。不用一行行手敲，跟 AI 对话就能完成开发。

Andrej Karpathy 去年提出这个概念后，整个行业都在往这个方向跑。

Claude Code 是目前最强的 Vibe Coding 工具，但也是最贵的。

结论先放这：日常开发成本降 98%，能力差距可控。

为什么选 DeepSeek V4

先看一组数据。

V4 的推理性能在数学、代码竞赛等基准测试中，超越了所有公开评测的开源模型。（来源：量子位）

编程能力比肩世界顶级闭源模型，在部分评测中接近 ChatGPT-5.5 水平。（来源：智源社区）

V4 官方报告公开了 484 天的研发历程，从 V3 到 V4 的跨越不只是参数堆叠。推理架构做了深度优化，代码生成的准确率和连贯性都有质的提升。

具体到编程场景，V4 在以下方面有明显进步。

理解复杂需求的能力更强，一次对话能处理更复杂的指令。生成的代码结构更清晰，变量命名更规范。

跨文件修改时的上下文关联能力也有提升。

不过要注意，V4 的能力提升主要体现在单文件和中等复杂度任务上。超大规模代码库的全局理解，跟 Claude Opus 还有差距。

价格更是碾压级。

对比项	DeepSeek V4-Pro	Claude Opus 4.7	Claude Sonnet
输出价格	6 元/百万 tokens	$25/百万 tokens	$15/百万 tokens
输入价格	3 元/百万 tokens	$5/百万 tokens	$3/百万 tokens
上下文窗口	1M	200k	200k
新用户福利	500 万 tokens 免费	无	无

数据来源：DeepSeek 官网定价页（api-docs.deepseek.com）、火山引擎开发者文档、SMZDM 实测。

V4-Pro 永久降价 75% 后，输出价格只有原来的四分之一。缓存命中时的输入价格低到 0.025 元每百万 tokens，几乎可以忽略。

什么是缓存命中？你发送的 prompt 如果跟之前的请求有重叠部分，重叠部分走缓存。

价格只有正常的几十分之一。实际开发中大量请求都有重叠，所以真实成本比标价更低。

上下文窗口也是碾压级。V4 支持 1M tokens 上下文，是 Claude 的 5 倍。整个项目代码库一次性喂进去都没问题。

新用户注册送 500 万 tokens，按中等强度开发估算，免费用一周没问题。

补充一点：DeepSeek 的 API 兼容 OpenAI 格式。这意味着几乎所有支持自定义 API 地址的编程工具都能接入，不只是本文提到的三种。

方案一：Claude Code Router（最推荐）

这是目前最火的方案，GitHub 上 3.5 万 Star。

原理很简单：在本地跑一个代理服务，拦截 Claude Code 发出的请求，转发给 DeepSeek API。

对 Claude Code 来说完全透明，它以为自己在跟官方服务器通信。

整个流程是这样的：

1
2
3
4
5
6


你输入指令 → Claude Code 发请求
 → Claude Code Router 拦截
 → 转换格式，转发给 DeepSeek V4 API
 → DeepSeek 返回结果
 → Router 转换回 Claude Code 格式
 → Claude Code 显示结果

安装四步搞定。

第一步：装 Claude Code

1

npm install -g @anthropic-ai/claude-code

第二步：装 Claude Code Router

1
2


npm install -g tiktoken
npm install -g @musistudio/claude-code-router

tiktoken 是分词依赖，不装可能报错。

第三步：写配置文件

配置文件在 ~/.claude-code-router/config.json。

这是纯 DeepSeek 方案（极致性价比），直接复制改 Key 就能用：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23


{
 "log": true,
 "Providers": [
 {
 "name": "deepseek",
 "api_base_url": "https://api.deepseek.com",
 "api_key": "sk-你的APIKEY",
 "models": ["deepseek-v4-pro"],
 "transformer": {
 "use": ["deepseek"],
 "deepseek-v4-pro": {
 "use": ["tooluse"]
 }
 }
 }
 ],
 "Router": {
 "default": "deepseek,deepseek-v4-pro",
 "background": "deepseek,deepseek-v4-pro",
 "think": "deepseek,deepseek-v4-pro",
 "longContext": "deepseek,deepseek-v4-pro"
 }
}

模型名用 deepseek-v4-pro，对应 V4 满血版，输出 6 元/百万 tokens。追求极致性价比可以改成 deepseek-v4-flash，输出只要 2 元/百万 tokens，日常 CRUD 够用。旧的 deepseek-chat/deepseek-reasoner 对应 Flash 档，将于 2026 年 7 月底弃用，建议直接用新名称。

Router 配置说明：default 处理日常对话，think 走思考模式做复杂推理。V4-Pro 同时支持两种模式，通过 Router 自动切换。

background 处理后台任务，longContext 处理长文本场景。

第四步：启动

1

ccr code

看到欢迎界面就成功了。首次运行建议输入 /init 初始化项目配置。

三种进阶配置怎么选？

方案	模型组合	上下文	适用场景
纯 DeepSeek	V4-Pro	1M	日常开发，成本最低
DeepSeek + Qwen	V4 + Qwen3-32B	1M + 128k	特定语言能力互补
DeepSeek + Gemini	V4 + Gemini 2.5 Pro	1M + 百万级	多模态/超长文档分析

混合方案的价值不再是补上下文——V4 自身 1M 已经够用。价值在于能力互补：不同模型在不同任务上各有所长。

日常走 DeepSeek V4-Pro 的 1M 上下文，遇到特定场景才切到其他模型。比如多模态分析切 Gemini，特定框架生态切 Qwen。

Gemini 接入需要通过开源项目 openai-gemini 配合 Cloudflare Workers 实现，具体步骤参考 GitHub 上的 yzfly/claude-code-deepseek-quickstart 项目，有详细教程。

实际体验

响应速度：V4-Pro 非思考模式基本秒回，思考模式需要等几秒。

代码质量：日常 CRUD、bug 修复、单元测试，完全够用。

复杂架构重构偶尔会跑偏，需要多次纠正。但比起 Claude Code 动不动几美刀一轮对话，这点耐心值得。

踩坑提醒：transformer 里的 tooluse 很关键，不加的话文件读写会失效。后面的踩坑实录有详细排查。

在会话中可以用 /model 命令随时切换模型：

1

/model deepseek,deepseek-v4-pro

处理复杂问题时确保走思考模式，日常聊天用默认即可，灵活搭配。

方案二：Cline（VSCode 集成派）

Claude Code Router 是终端方案，有些人更喜欢在编辑器里操作。Cline 就是这个定位。

Cline 是一个开源的 VSCode 插件，支持任意 AI 提供商。GitHub 项目：cline/cline。

它的核心特性是 Plan/Act 双模式：先规划再执行，不会一上来就乱改代码。

配置 DeepSeek V4 步骤：

VSCode 扩展商店搜索 Cline 安装
打开 Cline 面板，点击设置图标
API Provider 选择 DeepSeek
填入你的 DeepSeek API Key
Model 选 deepseek-v4-pro（满血版）或 deepseek-v4-flash（省钱版）

不需要写配置文件，全程图形界面操作。

Plan/Act 模式怎么用

Plan 模式下，你描述需求，Cline 先分析代码库，给出一个完整的执行计划。

你确认计划没问题后，切到 Act 模式，它才开始改代码。

这个流程比 Claude Code 的"边想边干"更稳。尤其适合改动范围较大的重构任务，先看清楚再动手。

对比 Claude Code Router

维度	Claude Code Router	Cline
运行环境	终端	VSCode
配置方式	JSON 文件	图形界面
工作模式	对话式	Plan/Act 双模式
适合人群	终端党	编辑器党
多模型切换	/model 命令	下拉菜单

我的建议：习惯终端就选 Router，习惯 VSCode 就选 Cline。

方案三：Aider（轻量级终端助手）

Aider 的定位更轻：一个 git 友好的终端编程助手。

它不像 Claude Code 那么重，启动快，适合小项目快速修改。每次改动自动 git commit，回滚很方便。

配置 DeepSeek V4：

1
2
3


# 设置环境变量
export DEEPSEEK_API_KEY=你的APIKEY
aider --model deepseek/deepseek-v4-pro

Aider 底层用 litellm 库，原生支持 DeepSeek。deepseek/ 前缀告诉 litellm 走 DeepSeek 路由。

也可以写到配置文件 ~/.aider.conf.yml 里：

1
2


model: deepseek/deepseek-v4-pro
auto-commits: true

适合什么场景

小 bug 修复、写个脚本、快速原型验证。偶尔需要 AI 帮忙写几行代码，Aider 比 Claude Code 轻量得多。

不太适合大型项目重构。Aider 的上下文管理不如 Claude Code 精细，复杂任务容易丢上下文。

另外提一句，2026 年 AI 编程工具的格局已经很清晰了。

Cursor 月费 10 到 39 美元，IDE 集成体验最好。Claude Code 最强但最贵。Cline 开源免费，Aider 轻量终端派。

加上 DeepSeek V4 的成本优势，组合空间非常大。

成本算账

这才是最关心的部分。按中等强度开发估算。

日均消耗假设：输入 50 万 tokens，输出 10 万 tokens。这是一个全职开发者中等强度使用的合理估算。

估算项	Claude Code 官方	DeepSeek V4 方案
日均输入	~50 万 tokens	~50 万 tokens
日均输出	~10 万 tokens	~10 万 tokens
日均费用	~$5	~0.7 元
月度成本	~$150	~21 元
年度成本	~$1,800	~252 元

数据来源：DeepSeek 官网定价页、火山引擎开发者文档。

Claude Code 日均费用按 Opus 4.7 输出 $25/M、输入 $5/M 计算。DeepSeek 按 V4-Pro 输出 6 元/M 计算，输入走缓存。

一年省下来的钱，够买一台 MacBook Pro。

当然这是理想情况。实际使用中复杂任务需要多次对话，token 消耗会更高。

但即便翻三倍，DeepSeek 方案的年成本也就 800 块左右。跟 Claude Code 的 1800 美刀完全不在一个量级。

新用户还有 500 万 tokens 免费额度。按上面的日均消耗，能免费用 8 天左右。

踩坑实录

用了几天，坑确实有几个。

坑一：文件读写突然失效，AI 只能说不能做

Claude Code 的核心能力是读写文件。但接入 DeepSeek 后，有时候 AI 只输出文字，不执行任何文件操作。

原因：transformer 里的 tooluse 配置遗漏或格式错误。DeepSeek 的函数调用格式跟 Claude 原生不同，需要 tooluse 做转换。没有这层转换，工具调用指令发不出去。

解法：确认 config.json 里 deepseek-v4-pro 下面有 "use": ["tooluse"]。前面方案一的配置示例已经包含，直接复制不要删。

坑二：复杂多文件重构能力有差距

让 DeepSeek V4 同时改 10 个文件的接口，它偶尔会漏掉联动修改。Claude Code 在这种场景下更靠谱。

解法：拆小任务。一次让它改 2-3 个文件，确认没问题再继续。别一口气丢整个模块给它。

坑三：中文注释偶尔编码异常

生成的代码里偶尔会有中文注释乱码。频率不高，大概十次出一次。

解法：在项目根目录的 CLAUDE.md 里加一行"所有注释用英文"。Claude Code Router 会读取这个文件作为系统提示。

坑四：网络稳定性

DeepSeek API 在高峰期偶尔会慢，5-10 秒延迟。思考模式时间更长，复杂问题可能等 30 秒以上。

Claude Code Router 配置里有个 API_TIMEOUT_MS 参数，默认 600 秒。一般不用改。

遇到超时报错的话，适当调大这个值就行。

坑五：DeepSeek 账号注册

DeepSeek 需要手机号注册，目前支持中国大陆手机号。注册后在控制台创建 API Key，复制到配置文件里就行。

整个过程不需要海外信用卡，不需要特殊网络环境。这是相比 Claude Code 最大的便利之一。

结论与建议

什么场景可以放心用 DeepSeek V4 平替？

日常 CRUD 开发、bug 修复、写单元测试、代码审查、文档生成。这些占开发工作量的 80% 以上，DeepSeek V4 完全胜任。

什么场景还是建议用 Claude？

超大型项目重构、跨模块接口设计、需要顶级推理深度的复杂分析。这些场景 Claude 的工程化能力优势明显。

最佳组合策略：日常 DeepSeek + 复杂任务 Claude。

90% 的日常开发用 DeepSeek V4，省钱又够用。遇到啃不动的硬骨头，临时切换到 Claude Code 处理。

这样月成本能控制在几十块，而不是几百美刀。

具体行动建议：

如果你还没装过 Claude Code，先试 Router + DeepSeek 方案。四步装完，免费 500 万 tokens 够你跑一周。

体验满意再决定要不要充 Claude。

如果你已经在用 Claude Code，加一个 Router 做 fallback。

复杂任务用 Claude，简单任务切 DeepSeek，/model 命令随时切换。

作者：varkm

关注 varkm，一起学习，一起成长

AI编程 on Kalend's Blog

Kiro IDE上手：AWS的Spec驱动编程，和Cursor/Claude Code有何不同

先说结论

一、Kiro是什么？AWS为什么要做IDE

二、Spec-Driven Development——Kiro的核心差异

三、并行Agent + 正确性验证

并行Agent执行

Property-Based Testing

Agent Hooks

四、多端统一 + 模型生态

四端支持

模型生态

开放标准

五、定价与性价比分析

六、和Cursor/Claude Code的实操对比

方法论差异

适合场景对比

七、结论与建议

Claude Code、Codex、OpenCode、ZCode 四款AI编程Agent怎么选：工具是方法论的载体

为什么"选工具=选阶段"

Claude Code：Context Engineering 的代表作

Codex CLI：安全优先的工程实践

OpenCode：最大自由度的开源方案

ZCode 3.0：可视化的国产方案

方法论适配度对比

决策树：四条路径，选哪条

结论

Vibe Coding 三阶进化：从「帮我写代码」到「Agent 自己干」，你还在第几层？

Karpathy 自己都认输了

一、三阶进化：你卡在哪一层？

1.0 氛围编程：祈祷式开发

2.0 Context Coding：给 AI 一本操作手册

3.0 Agentic Engineering：当 AI 成了你的同事

二、四款工具方法论适配度横评

Claude Code：上下文工程的教科书

Codex CLI：安全第一的执行机器

OpenCode：模型自由度之王

ZCode：国产模型的原生适配者

三、不绑定工具的四条心法

心法一：写好 AGENTS.md 比选对工具重要十倍

心法二：任务拆解粒度决定成败

心法三：审查 ≠ 不信任

心法四：迭代循环，不是一次生成完事

说在最后

MCP 安全血案：5条攻击路径、20万台服务器中招、你装的插件可能有毒

开篇：你装的 MCP 插件，可能正在偷你的密钥

第一章：5 条真实攻击路径

路径一：Prompt Injection —— 零交互远程代码执行

路径二：供应链攻击 —— 你装的包里有后门

路径三：Tool Poisoning —— 工具描述本身就是武器

路径四：凭证窃取 —— 从工具参数到 AWS Root

路径五：SSRF 与路径穿越 —— MCP 服务器成为内网跳板

第二章：为什么 MCP 天生不安全

第三章：真实伤亡清单

第四章：开发者自保指南

5 条核心防护措施

MCP 服务器选型 Checklist

推荐工具

第五章：总结与展望

ChromaDB + Python：5分钟搭建个人知识库

先说结论

向量数据库 60 秒科普

5 分钟快速上手

第一步：安装

第二步：创建客户端和集合

第三步：添加文档

第四步：查询

第五步：元数据过滤

完整实战：搭建个人知识库

选型对比：ChromaDB vs FAISS vs Qdrant

结语

别再用 LIKE 搜数据库了：20 行代码搭一个语义搜索引擎

先说结论

第一章：向量检索是什么（3 分钟搞懂原理）

文本变向量：让机器理解"意思"

相似度怎么算：余弦 vs L2

为什么不用 MySQL LIKE

第二章：Sentence-Transformers — 让文本变成向量

安装和一行代码上手

中文模型怎么选