一些关于AI的基础知识和一些使用心得

2024-2026 年，AI 工具从最初的单一对话机器人演变成了完整的生态系统。API 协议也从一家独大演变为现在的百花齐放。本文聊一下我对 AI 使用的一些心得与部署整合网关的一些与避坑指南。

一、使用途径

1. Web 聊天 —— 体验为主，不适合工程场景

定位

Web 聊天本质上是各大厂商封装好的 GUI 产品，面向普通用户或轻度用户。其底层调用的是同一套 API，但前端做了大量体验优化：流式输出、会话管理、多模态交互、自定义指令等。

Web聊天与 API 的核心差异

上下文窗口：网页端通常有人为限制（如 GPT-4o 网页版限制 128k 上下文，但 API 可用 200k）
Rate Limit：网页端限速更严格，API 端可以通过多 Key 水平扩展
功能可用性：网页端优先获得官方新功能（如 GPTs、Canvas），API 端更偏向基础能力
数据策略：网页端用户内容可能用于模型训练（除非开启 Data Controls），API 端默认不训练

工程视角的结论

Web 聊天适合产品体验和 POC，不适合作为工程系统的 AI 能力来源。其核心问题：

无法程序化调用
无法保证 SLA
无法做批量处理
多账号管理成本高

2. Coding Plan

什么是 Coding Plan

Coding Plan 是 AI 厂商推出的订阅制套餐，最初为自家 IDE 插件导流，后来逐步演变为独立产品。典型形态：

月付/年付固定费用
内含高级模型配额（非无限，有 Soft Limit）
绑定自家工具生态
通常附带一定量 API 调用额度（通常很少）

适合场景

日均使用量在配额 50% 以下的个人用户
需要稳定体验、不想被限速折腾的开发者
团队协作场景（Team 套餐支持管理后台）
作为生产环境的备用通道

3. API 调用

API 调用基础

API（Application Programming Interface）是程序与 AI 模型交互的标准方式，直接调用 API 所产生的费用通常比较昂贵。核心流程：

TEXT

开发者程序
    │
    ▼
HTTP POST https://api.provider.com/v1/chat/completions
Headers: Authorization: Bearer sk-xxx
Content-Type: application/json
    │
    ▼
AI 服务商服务器（鉴权 → 计费 → 模型推理 → 响应）
    │
    ▼
返回 JSON / Stream

主流 API 协议对比

这是最容易踩坑的地方。各家协议差异巨大，以下是大概的对比：

服务商	Endpoint	认证	model 参数格式	system 处理	max_tokens	流式格式
OpenAI	`/v1/chat/completions`	`Bearer sk-xxx`	`"gpt-4o"`	在 messages 里	支持	`text/event-stream`
Anthropic	`/v1/messages`	`x-api-key: sk-ant-xxx`	`"claude-sonnet-4-20250514"`	独立 `system` 字段	必须指定	`application/x-ndjson`
Google	`/v1/models/{model}:generateContent`	`key=xxx` 或 OAuth	`"models/gemini-1.5-pro"`	独立 `system_instruction`	`maxOutputTokens`	`application/x-json-stream`
Cohere	`/v1/chat`	`Authorization: Bearer xxx`	`"command-r-plus"`	独立 `preamble`	`max_tokens`	`text/event-stream`
本地 Ollama	`/api/chat`	无或 `Authorization`	`"llama3:8b"`	在 messages 里	`num_predict`	`application/x-ndjson`

这些协议差异为什么重要

如果你想在同一个项目中同时使用多个 AI 服务商会非常痛苦：

TEXT

方案 A: 为每个服务商写独立适配器
├── openai_adapter.py      # 200 行
├── anthropic_adapter.py   # 180 行
├── gemini_adapter.py      # 220 行
└── unified_interface.py    # 50 行
维护成本：每个新模型需要更新对应适配器

方案 B: 使用网关统一协议层
├── 一个 OpenAI 兼容 endpoint
├── 实际调用任意 AI 服务商
└── 代码只需对接一个接口

这就是 New API / One API 这类工具存在的意义。

二、整合网关

1. 为什么需要整合网关

多服务商管理的痛苦

当你的团队同时使用多个 AI 服务商时，会遇到以下问题：

问题	描述	影响
多 Key 管理	OpenAI、Claude、Gemini 各有独立 Key	泄露风险增加，轮换困难
协议不统一	OpenAI 用 messages，Anthropic 用 system	代码重复，维护困难
限速单点	单 Key 触发 Rate Limit	服务不稳定
费用黑盒	不知道钱花在哪了	账单爆炸
路由困难	不知道该用哪个模型	成本/效果不匹配

整合网关的核心价值

统一入口：一个 endpoint 对外，内部路由到多个服务商
负载均衡：多 Key 轮询，单点限速变分布式
智能路由：按模型/用量自动选择通道
协议转换：对外 OpenAI 协议，内部转换给 Anthropic/Gemini
成本监控：每个 Key 的用量、费用一目了然

2. 主流方案对比

方案一：New API / One API

开源的 AI API 网关项目，GitHub Stars 超过 20k，是目前最成熟的选择。

方案二：开源本地模型 + 商业 API 混用

适合对数据隐私有要求或想降低成本的场景：

方案三：API 管理平台（SaaS）

缺点：

数据经过第三方服务器
费用比自己部署贵
定制化能力受限

三、我的 Token 来源

ChatGPT Plus 号池提供廉价 GPT 系列模型额度 + GitHub Copilot Pro 提供 Claude Opus + New API 统一管理 = 高性价比 AI Coding 环境

注意事项

号源安全：账号有被封风险，建议分散购买、不要放在一个服务商
反代稳定性：选择稳定的反代服务，避免关键时刻额度抽风
网络环境：尽量选择干净稳定的网络环境，避免账号封控

适合场景：

高强度 Vibe Coding
对成本敏感的学生/个人开发者
需要不同模型处理不同复杂度任务的开发者

四、我使用的工具与一些经验

这一部分我想单独列出来，因为很多新手会把“模型”和“工具”混在一起。实际上，模型只是底层能力，真正决定你日常体验的，往往是上层工具链是否顺手。

1. Claude Code

Claude Code 是我现在最常用的 AI Coding 工具。它的强项不是单纯“补全代码”，而是在整个工程上下文里工作：

可以直接读文件、改文件、查引用
适合做重构、排查 bug、理解陌生项目
对多文件修改、代码审查、架构梳理很有帮助
在终端里工作，适合已经习惯命令行的人
非常适合处理复杂任务，尤其是需要跨多个文件、需要先理解再修改的场景

对我来说，Claude Code 更像一个“工程型代理”，而不是一个简单的聊天框。尤其是在处理中大型项目、复杂需求、长链路修改时，它比普通聊天式工具高效很多。

2. Codex

虽然Claude Code 有的功能 Codex 都有，但就使用体验上来讲，我个人认为 Codex 更适合高频、快速、偏局部的 Coding 任务，尤其是 桌面版本的操作界面非常友好，很适合日常使用。比如：

写一个函数
修一个局部 bug
生成样板代码
快速补测试
做一些重复性的改写
处理一些简单的编码任务

如果说 Claude Code 更擅长“理解整个项目再动手”，那 Codex 更像是“快速施工队”。它的优势在于上手成本低、交互轻量、适合随开随用，我常会用它写一下脚本之类的东西。

所以我的习惯一般是：

复杂任务、跨文件任务：优先 Claude Code
日常写代码、补代码、快修、写脚本：优先 Codex

3. cc-switch

我会用 cc-switch 这类切换工具来统一配置AI 编程工具，包括但不限于安装MCP、Skill和切换模型。这样在 Claude Code、Codex 或其它 AI 编程工具里就不用频繁改配置文件。

这个工具特别适合下面几种场景：

某个上游限流了，要快速切备用通道
某个任务更适合 Claude Opus，而另一个任务更适合 GPT-5.4
想测试不同 provider 的实际效果差异

4. Skill：要用，但不要贪多

我很推荐 Skill 体系，因为它本质上是在给模型提供“任务模板”和“执行约束”。它的好处是：

让模型更快进入正确上下文
降低重复提示词成本
在固定场景下更稳定
比纯自然语言临时描述更容易复用

我比较推荐的 Skill 类型

虽然不同平台名字不一样，但我推荐优先准备这几类：

1）commit / review 类

适合生成 commit message
适合做 PR review
适合在提交前检查改动是否合理

2）debug / trace 类

适合排查报错
适合分析日志
适合快速定位问题范围

3）refactor / simplify 类

适合让模型做局部重构
适合压缩重复代码
适合在不改变行为的前提下做整理

4）test / verify 类

适合补测试
适合生成测试用例
适合让模型检查边界条件

5）doc / explain 类

适合理解陌生代码
适合把实现解释给团队成员
适合快速产出技术说明

不要开太多 Skill

虽然大多数框架都支持“渐进式披露（progressive disclosure）”，意思是工具很多没关系，只要按需调用就行。从设计上说这没问题，但我自己的使用体验是：Skill 数量一多，模型就更容易幻觉。

我推测原因通常有几个：

候选动作太多 模型在面对一个任务时，如果可选 Skill 太多，会更容易“误判”当前任务该调用哪个模板。
上下文竞争 每个 Skill 都会携带一部分额外提示或约束。Skill 一多，这些约束会在上下文里互相竞争，导致模型抓不住重点。
错误泛化 模型有时会把某个 Skill 的适用边界错误扩展到其它任务里，出现“这个问题也应该套那个模板”的幻觉。
输出更像在表演，而不是解决问题 Skill 太多时，模型有时会更关注“是否符合某个模板”，而不是先把任务本身做对。

所以我的建议很简单：

Skill 要少而精，围绕高频任务来配，不要把它做成插件市场。

更具体一点：

常用 Skill 保持在少量核心集合
一个 Skill 只解决一类明确问题
不要做大量功能重叠的 Skill
能用自然语言清楚描述的简单任务，没必要强行上 Skill

5. MCP：非常有用，但要克制接入

MCP 的价值很高，因为它让模型真正“连到外部系统”。比如：

读取文档站
接入 GitHub
查询数据库或日志系统
访问内部知识库
调用浏览器、设计稿、任务系统

有了 MCP 之后，模型不只是“会说”，而是真的能“查”。这对工程任务帮助非常大。

我比较推荐的 MCP 类型

1）GitHub / GitLab MCP

看 PR
看 issue
查提交记录
做代码评审时特别有用

2）文档检索 MCP

查官方文档
查内部文档
查 API 说明
很适合配合 debug、集成、升级类任务

3）日志 / 监控 MCP

查报错日志
看服务状态
定位线上问题
适合运维和后端排障

4）数据库查询 MCP

验证数据状态
查某条记录是否符合预期
做问题排查时特别有效

不要挂太多 MCP

MCP 和 Skill 一样，也不是越多越好。理论上，更多 MCP = 更多能力；但实际使用里，经常会变成：更多噪音、更多误调用、更多幻觉。

常见问题包括：

模型不知道该用哪个 MCP
本来只需要读代码，却错误地跑去查外部系统
上下文里混入太多无关信息
一个简单任务被工具链复杂化

特别是在 Coding 场景下，如果你给模型同时挂太多：

GitHub
文档站
浏览器
数据库
日志系统
项目管理系统

模型很容易把一个本来应该“直接改代码”的任务，做成“到处查询一圈”的复杂流程。这样不但更慢，还更容易产生错误判断。

6. 我的原则：工具按任务选，不要全开

这是我自己总结下来最重要的一条：

不要追求“全都接上”，而要追求“当前任务最合适的那几个工具”。

我的经验是：

写代码时，优先保证代码工具链干净
查文档时，再挂文档类 MCP
看 PR 时，再启用 GitHub 类 MCP
排障时，再启用日志 / 数据库类 MCP

这样做的好处：

上下文更干净：模型更容易聚焦当前问题
幻觉更少：减少无关工具对模型决策的干扰
速度更快：少掉很多不必要的工具判断
输出更稳定：模型更像一个工程助手，而不是一个乱翻工具箱的人

保持工具链最小可用，围绕任务逐步增加能力，而不是先把所有能力都打开。

7. 一个实用的最小组合

如果让我给一个足够实用、又不过度复杂的组合，我会推荐：

Claude Code：负责中大型工程任务
Codex：负责高频日常 Coding
cc-switch / cc-claude：负责切换后端
少量核心 Skill：commit、debug、review、test
少量核心 MCP：GitHub、文档检索

这套组合已经能覆盖绝大多数开发场景了。后面真遇到明确需求，再继续加工具，不要一开始就堆满。

8. 不要把判断权完全交给 AI

这一点非常重要！这一点非常重要！这一点非常重要！因为它不是“效率技巧”，而是一个很现实的安全建议。

在让 AI 完成任务之前，自己最好先理解这个任务，至少脑子里要有一个大概方向。你不一定要先把代码写出来，但最好知道：

这次修改大概要改哪里
哪些文件可能会被影响
你希望它往哪个方向改
什么结果是你能接受的，什么结果是不能接受的

最稳妥的做法通常有两种：

第一种：你先有方向，再让 AI 顺着这个方向改。 这样 AI 更像是你的执行助手，而不是替你做决定的人。

第二种：先让 AI 给方案，再自己判断方案是否可行。 尤其是涉及重构、批量修改、自动执行命令的时候，先停一下，自己过一遍逻辑，很有必要。

我自己的经验是：

永远不要太过于相信 AI，至少在目前这个阶段不要。

原因很简单，AI 现在已经足够强，可以做很多事，但它还远远没有强到“可以替你承担最终判断”。

它会：

理解错你的意图
漏看上下文
在看起来合理的情况下做出危险操作
因为权限过大而把错误放大

这不是理论问题，而是实际会发生的事。

这是一个过来人的忠告： 很多坑我见过，也踩过，把权限放得太开、过度相信 AI，最后本地仓库被直接清空。你在让 AI 拥有更强执行能力的同时，也是在放大它犯错时的破坏力。

所以我的建议是：

先想清楚任务目标，再让 AI 动手（本质上是在做约束）
重要任务先让 AI 出方案，不要直接执行
涉及删除、覆盖、批量修改、git 操作时格外谨慎
不要轻易给“完全自动执行”的权限
AI 给出的方案，自己至少要能看懂、能判断

你可以把 AI 当成一个非常能干、但偶尔会犯低级错误的助手； 不要把它当成一个永远正确的高级工程师。

一、使用途径

1. Web 聊天 —— 体验为主，不适合工程场景

定位

Web聊天与 API 的核心差异

上下文窗口：网页端通常有人为限制（如 GPT-4o 网页版限制 128k 上下文，但 API 可用 200k）
Rate Limit：网页端限速更严格，API 端可以通过多 Key 水平扩展
功能可用性：网页端优先获得官方新功能（如 GPTs、Canvas），API 端更偏向基础能力
数据策略：网页端用户内容可能用于模型训练（除非开启 Data Controls），API 端默认不训练

工程视角的结论

Web 聊天适合产品体验和 POC，不适合作为工程系统的 AI 能力来源。其核心问题：

无法程序化调用
无法保证 SLA
无法做批量处理
多账号管理成本高

2. Coding Plan

什么是 Coding Plan

Coding Plan 是 AI 厂商推出的订阅制套餐，最初为自家 IDE 插件导流，后来逐步演变为独立产品。典型形态：

月付/年付固定费用
内含高级模型配额（非无限，有 Soft Limit）
绑定自家工具生态
通常附带一定量 API 调用额度（通常很少）

适合场景

日均使用量在配额 50% 以下的个人用户
需要稳定体验、不想被限速折腾的开发者
团队协作场景（Team 套餐支持管理后台）
作为生产环境的备用通道

3. API 调用

API 调用基础

API（Application Programming Interface）是程序与 AI 模型交互的标准方式，直接调用 API 所产生的费用通常比较昂贵。核心流程：

TEXT

开发者程序
    │
    ▼
HTTP POST https://api.provider.com/v1/chat/completions
Headers: Authorization: Bearer sk-xxx
Content-Type: application/json
    │
    ▼
AI 服务商服务器（鉴权 → 计费 → 模型推理 → 响应）
    │
    ▼
返回 JSON / Stream

主流 API 协议对比

这是最容易踩坑的地方。各家协议差异巨大，以下是大概的对比：

服务商	Endpoint	认证	model 参数格式	system 处理	max_tokens	流式格式
OpenAI	`/v1/chat/completions`	`Bearer sk-xxx`	`"gpt-4o"`	在 messages 里	支持	`text/event-stream`
Anthropic	`/v1/messages`	`x-api-key: sk-ant-xxx`	`"claude-sonnet-4-20250514"`	独立 `system` 字段	必须指定	`application/x-ndjson`
Google	`/v1/models/{model}:generateContent`	`key=xxx` 或 OAuth	`"models/gemini-1.5-pro"`	独立 `system_instruction`	`maxOutputTokens`	`application/x-json-stream`
Cohere	`/v1/chat`	`Authorization: Bearer xxx`	`"command-r-plus"`	独立 `preamble`	`max_tokens`	`text/event-stream`
本地 Ollama	`/api/chat`	无或 `Authorization`	`"llama3:8b"`	在 messages 里	`num_predict`	`application/x-ndjson`

这些协议差异为什么重要

如果你想在同一个项目中同时使用多个 AI 服务商会非常痛苦：

TEXT

方案 A: 为每个服务商写独立适配器
├── openai_adapter.py      # 200 行
├── anthropic_adapter.py   # 180 行
├── gemini_adapter.py      # 220 行
└── unified_interface.py    # 50 行
维护成本：每个新模型需要更新对应适配器

方案 B: 使用网关统一协议层
├── 一个 OpenAI 兼容 endpoint
├── 实际调用任意 AI 服务商
└── 代码只需对接一个接口

这就是 New API / One API 这类工具存在的意义。

二、整合网关

1. 为什么需要整合网关

多服务商管理的痛苦

当你的团队同时使用多个 AI 服务商时，会遇到以下问题：

问题	描述	影响
多 Key 管理	OpenAI、Claude、Gemini 各有独立 Key	泄露风险增加，轮换困难
协议不统一	OpenAI 用 messages，Anthropic 用 system	代码重复，维护困难
限速单点	单 Key 触发 Rate Limit	服务不稳定
费用黑盒	不知道钱花在哪了	账单爆炸
路由困难	不知道该用哪个模型	成本/效果不匹配

整合网关的核心价值

统一入口：一个 endpoint 对外，内部路由到多个服务商
负载均衡：多 Key 轮询，单点限速变分布式
智能路由：按模型/用量自动选择通道
协议转换：对外 OpenAI 协议，内部转换给 Anthropic/Gemini
成本监控：每个 Key 的用量、费用一目了然

2. 主流方案对比

方案一：New API / One API

开源的 AI API 网关项目，GitHub Stars 超过 20k，是目前最成熟的选择。

方案二：开源本地模型 + 商业 API 混用

适合对数据隐私有要求或想降低成本的场景：

方案三：API 管理平台（SaaS）

缺点：

数据经过第三方服务器
费用比自己部署贵
定制化能力受限

三、我的 Token 来源

ChatGPT Plus 号池提供廉价 GPT 系列模型额度 + GitHub Copilot Pro 提供 Claude Opus + New API 统一管理 = 高性价比 AI Coding 环境

注意事项

号源安全：账号有被封风险，建议分散购买、不要放在一个服务商
反代稳定性：选择稳定的反代服务，避免关键时刻额度抽风
网络环境：尽量选择干净稳定的网络环境，避免账号封控

适合场景：

高强度 Vibe Coding
对成本敏感的学生/个人开发者
需要不同模型处理不同复杂度任务的开发者

四、我使用的工具与一些经验

1. Claude Code

Claude Code 是我现在最常用的 AI Coding 工具。它的强项不是单纯“补全代码”，而是在整个工程上下文里工作：

可以直接读文件、改文件、查引用
适合做重构、排查 bug、理解陌生项目
对多文件修改、代码审查、架构梳理很有帮助
在终端里工作，适合已经习惯命令行的人
非常适合处理复杂任务，尤其是需要跨多个文件、需要先理解再修改的场景

2. Codex

写一个函数
修一个局部 bug
生成样板代码
快速补测试
做一些重复性的改写
处理一些简单的编码任务

所以我的习惯一般是：

复杂任务、跨文件任务：优先 Claude Code
日常写代码、补代码、快修、写脚本：优先 Codex

3. cc-switch

这个工具特别适合下面几种场景：

某个上游限流了，要快速切备用通道
某个任务更适合 Claude Opus，而另一个任务更适合 GPT-5.4
想测试不同 provider 的实际效果差异

4. Skill：要用，但不要贪多

我很推荐 Skill 体系，因为它本质上是在给模型提供“任务模板”和“执行约束”。它的好处是：

让模型更快进入正确上下文
降低重复提示词成本
在固定场景下更稳定
比纯自然语言临时描述更容易复用

我比较推荐的 Skill 类型

虽然不同平台名字不一样，但我推荐优先准备这几类：

1）commit / review 类

适合生成 commit message
适合做 PR review
适合在提交前检查改动是否合理

2）debug / trace 类

适合排查报错
适合分析日志
适合快速定位问题范围

3）refactor / simplify 类

适合让模型做局部重构
适合压缩重复代码
适合在不改变行为的前提下做整理

4）test / verify 类

适合补测试
适合生成测试用例
适合让模型检查边界条件

5）doc / explain 类

适合理解陌生代码
适合把实现解释给团队成员
适合快速产出技术说明

不要开太多 Skill

我推测原因通常有几个：

候选动作太多 模型在面对一个任务时，如果可选 Skill 太多，会更容易“误判”当前任务该调用哪个模板。
上下文竞争 每个 Skill 都会携带一部分额外提示或约束。Skill 一多，这些约束会在上下文里互相竞争，导致模型抓不住重点。
错误泛化 模型有时会把某个 Skill 的适用边界错误扩展到其它任务里，出现“这个问题也应该套那个模板”的幻觉。
输出更像在表演，而不是解决问题 Skill 太多时，模型有时会更关注“是否符合某个模板”，而不是先把任务本身做对。

所以我的建议很简单：

Skill 要少而精，围绕高频任务来配，不要把它做成插件市场。

更具体一点：

常用 Skill 保持在少量核心集合
一个 Skill 只解决一类明确问题
不要做大量功能重叠的 Skill
能用自然语言清楚描述的简单任务，没必要强行上 Skill

5. MCP：非常有用，但要克制接入

MCP 的价值很高，因为它让模型真正“连到外部系统”。比如：

读取文档站
接入 GitHub
查询数据库或日志系统
访问内部知识库
调用浏览器、设计稿、任务系统

有了 MCP 之后，模型不只是“会说”，而是真的能“查”。这对工程任务帮助非常大。

我比较推荐的 MCP 类型

1）GitHub / GitLab MCP

看 PR
看 issue
查提交记录
做代码评审时特别有用

2）文档检索 MCP

查官方文档
查内部文档
查 API 说明
很适合配合 debug、集成、升级类任务

3）日志 / 监控 MCP

查报错日志
看服务状态
定位线上问题
适合运维和后端排障

4）数据库查询 MCP

验证数据状态
查某条记录是否符合预期
做问题排查时特别有效

不要挂太多 MCP

MCP 和 Skill 一样，也不是越多越好。理论上，更多 MCP = 更多能力；但实际使用里，经常会变成：更多噪音、更多误调用、更多幻觉。

常见问题包括：

模型不知道该用哪个 MCP
本来只需要读代码，却错误地跑去查外部系统
上下文里混入太多无关信息
一个简单任务被工具链复杂化

特别是在 Coding 场景下，如果你给模型同时挂太多：

GitHub
文档站
浏览器
数据库
日志系统
项目管理系统

模型很容易把一个本来应该“直接改代码”的任务，做成“到处查询一圈”的复杂流程。这样不但更慢，还更容易产生错误判断。

6. 我的原则：工具按任务选，不要全开

这是我自己总结下来最重要的一条：

不要追求“全都接上”，而要追求“当前任务最合适的那几个工具”。

我的经验是：

写代码时，优先保证代码工具链干净
查文档时，再挂文档类 MCP
看 PR 时，再启用 GitHub 类 MCP
排障时，再启用日志 / 数据库类 MCP

这样做的好处：

上下文更干净：模型更容易聚焦当前问题
幻觉更少：减少无关工具对模型决策的干扰
速度更快：少掉很多不必要的工具判断
输出更稳定：模型更像一个工程助手，而不是一个乱翻工具箱的人

保持工具链最小可用，围绕任务逐步增加能力，而不是先把所有能力都打开。

7. 一个实用的最小组合

如果让我给一个足够实用、又不过度复杂的组合，我会推荐：

Claude Code：负责中大型工程任务
Codex：负责高频日常 Coding
cc-switch / cc-claude：负责切换后端
少量核心 Skill：commit、debug、review、test
少量核心 MCP：GitHub、文档检索

这套组合已经能覆盖绝大多数开发场景了。后面真遇到明确需求，再继续加工具，不要一开始就堆满。

8. 不要把判断权完全交给 AI

这一点非常重要！这一点非常重要！这一点非常重要！因为它不是“效率技巧”，而是一个很现实的安全建议。

在让 AI 完成任务之前，自己最好先理解这个任务，至少脑子里要有一个大概方向。你不一定要先把代码写出来，但最好知道：

这次修改大概要改哪里
哪些文件可能会被影响
你希望它往哪个方向改
什么结果是你能接受的，什么结果是不能接受的

最稳妥的做法通常有两种：

第一种：你先有方向，再让 AI 顺着这个方向改。 这样 AI 更像是你的执行助手，而不是替你做决定的人。

第二种：先让 AI 给方案，再自己判断方案是否可行。 尤其是涉及重构、批量修改、自动执行命令的时候，先停一下，自己过一遍逻辑，很有必要。

我自己的经验是：

永远不要太过于相信 AI，至少在目前这个阶段不要。

原因很简单，AI 现在已经足够强，可以做很多事，但它还远远没有强到“可以替你承担最终判断”。

它会：

理解错你的意图
漏看上下文
在看起来合理的情况下做出危险操作
因为权限过大而把错误放大

这不是理论问题，而是实际会发生的事。

所以我的建议是：

先想清楚任务目标，再让 AI 动手（本质上是在做约束）
重要任务先让 AI 出方案，不要直接执行
涉及删除、覆盖、批量修改、git 操作时格外谨慎
不要轻易给“完全自动执行”的权限
AI 给出的方案，自己至少要能看懂、能判断

你可以把 AI 当成一个非常能干、但偶尔会犯低级错误的助手； 不要把它当成一个永远正确的高级工程师。