跳转至

前沿 AI 工具综合指南

AI 工具已经从“输入一句话、得到一段文字”的聊天框，演变为能够阅读文件、检索网络、执行代码、操作浏览器、分析数据、生成图片和视频，并在较长时间内持续推进任务的工作环境。工具数量迅速增加，但真正决定使用效果的并不是记住多少产品名称，而是能否判断任务属于哪种类型、应该给系统开放哪些上下文和权限、怎样验证输出，以及何时必须由人接管。

本章以 2026 年 7 月的产品形态为观察基线。具体模型名称、套餐额度和界面按钮会频繁变化，因此正文不把“某个版本暂时领先”当成长期结论，而是讲清楚稳定的能力层次和选择方法。文中提到 ChatGPT、Claude、Gemini、Microsoft Copilot、Perplexity、NotebookLM、OpenAI Codex、Claude Code、GitHub Copilot cloud agent、Gemini CLI、Cursor Agent、Windsurf Cascade、Ollama、llama.cpp 和 vLLM 等产品，是为了帮助读者把方法映射到现实工具，而不是给出一份永久不变的排行榜。

先记住最重要的边界

生成式 AI 输出的是基于上下文和概率生成的候选结果，不是事实数据库，也不是天然可信的执行者。它可以提高检索、归纳、生成和操作速度，但事实责任、权限责任和发布责任仍然属于使用者。

1. 前沿 AI 工具正在解决什么问题

传统软件要求用户先学会菜单、命令和固定流程，再把意图翻译成软件能够识别的操作。现代 AI 工具试图把顺序反过来：用户先描述目标，模型再理解上下文、拆解任务、选择工具并生成结果。这个变化可以概括为从“人调用功能”走向“人描述目标，系统组合功能”。

一个 AI 工作系统通常包含五层。最底层是模型，它负责理解、推理和生成；模型之上是上下文层，保存对话、文件、代码库、检索结果和用户偏好；再往上是工具层，为模型提供搜索、代码执行、数据库、浏览器和业务 API；控制层决定何时继续、何时调用工具、何时请求审批；最外层是应用界面，包括聊天网页、IDE、终端、办公软件和自动化平台。只比较底层模型而忽略其他四层，往往无法解释为什么同一个模型在不同工具里的实际效果差异很大。

flowchart TB
    U["人的目标与责任"] --> C["控制层：计划、权限、审批、重试"]
    C --> X["上下文层：对话、文件、记忆、检索"]
    C --> T["工具层：搜索、代码、浏览器、API"]
    X --> M["模型层：理解、推理、生成"]
    T --> M
    M --> O["候选结果与行动"]
    O --> V["验证：事实、测试、安全、质量"]
    V --> U

当前前沿主要集中在六个方向。第一是推理能力增强，系统会在回答前进行更充分的中间计算，并利用搜索、代码解释器等工具验证步骤。第二是原生多模态，文字、图片、音频、视频和屏幕不再是彼此隔离的输入。第三是长上下文与检索，工具能够围绕大型代码库、资料库或项目空间持续工作。第四是计算机操作，Agent 可以操作终端、浏览器或桌面应用。第五是异步长任务，任务可以在隔离环境中运行数分钟甚至更久，并在完成后返回结果。第六是协议化互操作，MCP 等协议正在降低模型连接数据和工具的成本，A2A 一类协议则尝试解决 Agent 之间的发现和协作问题。

这些进步并没有消除幻觉、上下文污染、提示注入和误操作。恰恰相反，当模型从“只说话”升级为“能行动”，一次错误可能从一段不准确文字变成错误提交、误发邮件或数据损坏。因此，前沿使用能力的标志不是让 AI 获得尽可能大的权限，而是用最小权限、可观察过程和可恢复操作把能力放进工程边界。

2. 按任务选择工具，而不是按热度选择

选型之前先回答四个问题：输入是什么，输出是什么，是否需要外部事实，是否允许系统产生外部副作用。输入可能是简短问题，也可能是几十份文档、一个代码库或实时屏幕；输出可能是建议、可编辑草稿、程序补丁、图片、视频或已执行的业务操作；外部事实决定是否必须联网检索；副作用则决定是否需要沙箱和人工审批。

任务类型 合适的工具形态 核心优势 主要风险
解释、改写、构思 通用对话助手 低门槛、迭代快 编造事实、风格趋同
基于多份资料回答 文件工作区、NotebookLM、知识库助手 输出可与给定资料绑定 资料缺失、引用错配
开放网络调研 Deep Research、研究型搜索助手 多轮检索与来源汇总 来源质量不一、旧信息
代码解释和补全 IDE 助手 紧贴当前文件和编辑位置 局部正确、整体不兼容
跨文件开发和排错 编程 Agent 能搜索仓库、运行测试和修改文件 误改、命令权限过大
表格和数据分析 带代码执行的数据助手 可重复计算、可画图 口径错误、数据泄露
图片、音频、视频 多模态生成工具 快速探索视觉和声音方案 版权、肖像和真实性风险
跨系统重复流程 自动化平台或自建 Agent 能连接 API 并持续执行 凭据泄露、重复执行

从当前产品版图看，通用入口以 ChatGPT、Claude、Gemini 和 Microsoft Copilot 为代表，它们逐步把搜索、文件、代码、语音和图像整合到同一会话；研究层包括各家的 Deep Research、Perplexity Research 和以指定资料为边界的 NotebookLM；编程层同时存在 IDE 内 Agent、终端 Agent 和云端异步 Agent；视觉层包括 Sora、Veo、Adobe Firefly、Runway、Midjourney 等不同定位的生成平台；私有推理层由 Ollama、llama.cpp、vLLM 等运行时支撑；系统开发层则包括 OpenAI Agents SDK、Claude Agent SDK、Google ADK、Microsoft Agent Framework、LangGraph、PydanticAI、MCP 和 A2A。名称很多，但可以归纳为“交互入口、模型能力、上下文、工具连接、运行控制、基础设施”六个可替换层。

前沿产品还在快速融合 computer use 能力：模型读取屏幕或页面状态，再发出点击、输入、滚动和导航动作。这使旧系统在没有专用 API 时也能被自动化，但视觉定位容易受布局、弹窗、网络延迟和登录状态影响。只要存在稳定 API，就应优先 API；必须使用界面操作时，使用测试账号、隔离浏览器、域名白名单、动作上限和关键操作确认，并保存操作前后的可审计状态。

选择时可以用一个简单的效用函数强迫自己明确权衡。设质量得分为 \(Q\)，直接成本为 \(C\)，完成时间为 \(T\)，风险预期损失为 \(R\)，则工具方案的效用可以写成：

\[ U = w_q Q - w_c C - w_t T - w_r R \]

\(w_q,w_c,w_t,w_r\) 反映当前场景的优先级。写私人头脑风暴时，风险权重可以较低；处理生产数据库、法律材料或未公开代码时，\(w_r\) 必须显著提高。这个公式不是为了算出绝对精确的小数，而是为了避免只看输出“聪不聪明”，却忘记成本、时延和错误后果。

如果工具需要处理敏感材料，还要继续询问：数据是否用于训练，保留多久，位于哪个地区，管理员能否配置留存策略，第三方连接器会获得什么权限，删除账户后数据如何处理。免费版、个人版、团队版和 API 往往采用不同的数据政策，不能因为产品名称相同就假设规则相同。正式使用前应查看当前服务条款和隐私文档，而不是依赖社交媒体摘要。

3. 通用助手：把聊天变成可验证的工作台

ChatGPT、Claude、Gemini 和 Microsoft Copilot 等通用助手正在融合文字生成、文件阅读、图像理解、语音、网络搜索、代码执行和项目记忆。它们最适合完成目标仍需要人来定义、结果仍需要人来判断的工作，例如解释概念、生成初稿、对比方案、提取文档结构、辅助分析和准备会议材料。

高质量使用不是“写一个神奇提示词”，而是构造一个清晰的任务合同。合同至少包含目标、上下文、约束、交付格式和验证方法。例如，与其说“帮我分析这份日志”，不如给出：系统背景、故障发生时间、日志时区、已知正常行为、希望定位的问题、禁止泄露的字段，以及结果必须包含证据行和不确定性。下面的模板可以适用于多数通用助手：

目标：判断 10:00—10:20 的登录失败是客户端、网络还是服务端问题。

上下文：附件包含网关日志和认证服务日志，时间均为 UTC+8。
已知事实：10:08 发布了版本 2.4.1；10:15 已回滚。

约束：
1. 不要猜测日志中没有出现的事件。
2. 每个结论都引用对应时间戳和日志字段。
3. 将“事实”“推断”“仍需验证”分开。

交付：先给 5 句话以内的结论，再给时间线、证据和下一步命令。
验证：指出哪条新证据会推翻当前判断。

这个模板有效，是因为它把模型最容易混淆的内容分开了。事实来自输入，推断是对事实的解释，建议是未来行动。要求模型主动写出“什么证据会推翻判断”，相当于让它进行一次轻量的反证检查，可以减少过度自信。

长对话还会出现上下文漂移。对话越长，并不意味着模型记得越准确；旧要求可能被后续内容稀释，错误假设也会不断累积。较稳妥的做法是在阶段边界生成一份“工作状态”：已经确认的事实、未决问题、当前约束、文件清单和下一步。开启新会话时只带入这份经过人工检查的状态，而不是无差别复制全部聊天记录。

4. 搜索与深度研究：从“给答案”转向“给证据链”

普通联网搜索通常只进行少量查询并快速回答；深度研究工具会先制定检索计划，分多轮查询网页和文件，再综合生成带来源的报告。ChatGPT Deep Research、Gemini Deep Research、Perplexity Research 以及其他研究型产品都属于这一形态。NotebookLM 更偏向“基于用户指定资料进行研究和解释”，它与开放网络搜索的边界不同。

研究工具的关键不在报告长度，而在证据链。一个可信的研究结果至少应该说明来源是谁、资料何时发布、原始事实是什么、结论如何由事实推出，以及哪些内容仍有争议。引用数量多并不等于可靠：十篇互相转载的文章可能只有一个原始来源。对技术问题，应优先使用官方文档、标准、论文和源码；对政策或统计，应优先使用主管机构和原始数据集；对新闻事件，要区分报道发布时间和事件发生时间。

可以把来源质量粗略表达为：

\[ S = \alpha A + \beta P + \gamma R + \delta I - \eta D \]

其中 \(A\) 表示权威性，\(P\) 表示与问题的直接相关性，\(R\) 表示时效性，\(I\) 表示来源之间的独立性，\(D\) 表示传播链距离。原始标准文档的 \(D\) 较小，层层转载的摘要 \(D\) 较大。权重应随问题变化：查询历史事实时，时效性权重可以较低；查询 API 和法规时，时效性必须很高。

给深度研究工具的任务应限定范围和截止日期。例如“比较所有 AI 编程工具”几乎一定会得到泛泛而谈的市场综述；“基于截至 2026-07-21 的官方文档，对比这些工具是否支持本地仓库读取、终端执行、异步任务、MCP、企业策略控制，并注明无法确认的项目”更容易得到可审计结果。

研究完成后至少执行以下验证：打开最关键的三到五个来源；检查引用是否真的支持紧邻的句子；确认数字的单位、时间范围和样本口径；搜索反方材料；对关键结论做一次独立查询。医疗、法律、财务和安全决策不能只依赖自动研究报告，应由合格专业人员复核。

5. 编程 Agent：从代码补全到仓库级执行

编程 AI 大致经历了三种形态。第一种是行内补全，根据光标附近内容预测后续代码；第二种是对话式 IDE 助手，可以解释文件并提出修改；第三种是编程 Agent，它能够搜索整个仓库、编辑多个文件、运行命令和测试、查看失败结果，再继续修正。OpenAI Codex、Claude Code、GitHub Copilot cloud agent、Gemini CLI、Cursor Agent 和 Windsurf Cascade 都体现了第三种方向，但它们在本地或云端执行、审批模式、沙箱、上下文索引和企业控制方面存在差异。

使用编程 Agent 前，先把仓库变成“可被验证的环境”。项目应有明确的安装命令、构建命令、测试命令、格式化规则和贡献说明；否则 Agent 即使生成正确代码，也无法判断是否破坏了系统。一个良好的任务描述应给出可观察的验收条件，而不是只写“优化登录”。例如：

修复：密码连续输错 5 次后锁定账号 15 分钟。

必须保持：现有 JWT 格式和成功登录接口响应不变。
需要新增：并发请求下仍正确计数的测试、锁定到期测试、审计日志。
禁止修改：数据库迁移历史和生产配置。
验证命令：npm test -- auth && npm run lint && npm run build
交付说明：列出修改文件、威胁模型、测试结果和回滚方式。

让 Agent 先读后改通常比立即生成补丁可靠。第一阶段要求它说明入口文件、调用链、数据模型和现有测试；第二阶段让它提出最小修改方案；确认后再授权编辑和测试。大型任务应切成可以独立验证的小提交，避免一次对几十个文件进行不可审计的重写。

终端型编程 Agent 通常可通过包管理器安装。下面给出常见官方 CLI 的典型形式；执行前仍应查看各项目当前安装说明，并使用 --version 确认实际版本：

# OpenAI Codex CLI
npm install -g @openai/codex
codex --version

# Anthropic Claude Code
npm install -g @anthropic-ai/claude-code
claude --version

# Google Gemini CLI
npm install -g @google/gemini-cli
gemini --version

不要在包含生产凭据的主目录直接启动未知权限模式。先进入目标仓库，检查 git status，创建分支，确认忽略文件，再让 Agent 工作：

git status --short
git switch -c feature/agent-assisted-change
git diff --stat

# Agent 修改后进行人工审阅和本地验证
git diff --check
git diff
npm test

Agent 生成的测试也需要审查，因为它可能同时修改实现和测试，使二者共同满足一个错误假设。尤其要检查测试是否真的覆盖失败路径、权限边界、并发、空值、编码和时区，而不是只验证“函数能够运行”。依赖升级、数据库迁移、基础设施和认证代码应采用更严格审批。

需要进一步配置 Codex、Claude Code、Kimi Code，或把 GLM、DeepSeek 接入编程客户端时，请继续阅读 AI 编程 Agent 进阶使用指南。该章集中说明项目规则与记忆、插件、Skill、MCP、权限、非交互自动化，以及使用 Agent 维护 Markdown 文档的完整方法。

6. 多模态工具：图片、音频、视频和实时交互

多模态系统能够在同一个任务中处理文字、截图、图表、语音和视频。它们的价值不只是“生成一张漂亮图片”，更重要的是让视觉信息进入可交互工作流：读取错误截图、理解界面布局、从会议录音提取行动项、根据分镜生成素材、对视频内容进行索引，或者通过实时语音完成低延迟协作。

视觉任务应区分理解与生成。视觉理解要求模型准确描述已有内容，适合 OCR、界面检查、图表解释和文档提取；视觉生成要求模型创造新像素，适合概念图、营销素材和原型。对包含数字的图表、网络拓扑和工程架构，代码原生的 Mermaid、SVG 或绘图库通常比纯图片生成更可靠，因为文字、节点和连接可被审查与修改。生成式图片更适合氛围图、插画和视觉探索。

多模态提示需要补充视觉约束：画面比例、主体、构图、材质、光线、色彩、镜头、文字区域和禁止元素。连续制作时，还要保存角色设定、品牌色、参考图和随机种子等信息。单纯反复说“更高级一点”无法形成稳定控制。

涉及真人时必须考虑肖像权、知情同意和深度伪造风险；涉及品牌、角色和艺术风格时要检查许可；用于新闻、教育和决策的合成内容应明确标识。不要把生成图当作真实事件证据，也不要利用声音克隆绕过身份认证。

7. 本地模型与私有部署：控制、成本和能力的交换

Ollama、llama.cpp、vLLM 等工具让用户能够在本地设备或自有服务器上运行开放权重模型。选择本地部署通常不是因为它在所有能力上都优于云端模型，而是因为数据控制、离线运行、固定吞吐成本、可定制性或低延迟更重要。

模型能否运行主要受参数量、量化位宽、上下文缓存和并发影响。仅估算权重内存时，可以使用：

\[ M_{weights} \approx \frac{N \times b}{8} \]

其中 \(N\) 是参数数量，\(b\) 是每个参数的位数。一个 8B 参数、4 bit 量化模型仅权重理论下限约为 \(8\times10^9\times4/8=4\) GB，但实际还需要 KV cache、运行时缓冲区和系统内存。上下文越长、并发越高，额外内存越大，因此“权重文件能装下”不等于“能够稳定服务”。

吞吐量通常用 tokens/s 衡量，首 token 延迟反映用户等待回答开始的时间。交互式应用看重首 token 延迟，批处理看重总体吞吐。部署前应使用自己的提示长度、输出长度和并发量测试，而不是照搬硬件宣传数据。

本地模型同样需要安全治理。开放权重不等于没有许可证，离线不等于没有数据风险，自建服务也可能因端口暴露、日志记录或未授权 API 导致泄露。模型下载应核对来源和校验值，服务默认只绑定本地或内网地址，外部访问增加认证、TLS、速率限制和审计。

8. 上下文工程：比“提示词技巧”更重要的系统能力

提示工程关注如何写当前输入，上下文工程关注模型在这一轮究竟能看到什么。对于复杂任务，后者通常更重要。上下文包括系统规则、用户目标、历史消息、文件片段、检索结果、工具返回、时间和环境状态。如果上下文错误、冲突或过量，再好的措辞也无法保证结果。

上下文窗口可以看作有限预算：

\[ B = T_{system}+T_{history}+T_{files}+T_{retrieval}+T_{tools}+T_{output} \]

总 token 数必须不超过模型上限，而且接近上限时并不一定获得更高质量。大量无关文本会稀释关键信号，并增加成本和延迟。应优先提供与当前决策直接相关的材料，对长文件先建立结构和摘要，再按需检索原文片段。

可靠上下文通常分三层。稳定层保存长期规则，例如代码规范和安全政策；任务层保存当前目标、验收条件和相关文件；即时层保存刚刚执行的命令输出和局部错误。三层混在一段无限增长的聊天记录里，会增加冲突。支持项目空间或规则文件的工具，应把稳定规则放在可版本控制的位置，而不是要求用户每次重复粘贴。

外部网页和文档属于不可信输入。它们可能包含“忽略之前要求”“上传某个文件”等提示注入文本。系统应该把资料内容当作数据，而不是高优先级指令；工具调用参数必须经过策略检查，敏感操作必须请求人工确认。仅靠一句“不要被提示注入攻击”不能替代权限隔离。

9. 从个人使用到自动化工作流

当一个任务需要反复执行时，可以把稳定步骤从聊天迁移到自动化。典型流程是：事件触发，读取结构化输入，调用模型进行分类或提取，按规则选择后续系统，执行操作，记录结果，异常时进入人工队列。n8n、Zapier、Make、Power Automate 以及各类云端 Agent 平台都能组合这类流程，自建服务则提供更强控制。

自动化最适合输入和输出边界清楚的任务，例如工单分类、会议纪要草稿、文档字段抽取和代码仓库例行检查。不适合直接全自动处理高风险、不可逆且标准模糊的决策。将“AI 能给建议”误解为“AI 应该直接执行”，是自动化事故的常见来源。

一个安全的发布流程可以设计为：

flowchart LR
    A["收到需求"] --> B["AI 生成草稿"]
    B --> C["规则与事实检查"]
    C -->|"不通过"| B
    C -->|"通过"| D["人工审批"]
    D -->|"拒绝"| B
    D -->|"批准"| E["受限凭据发布"]
    E --> F["审计日志与回滚点"]

每个外部写操作都应设计幂等键，避免重试造成重复发送或重复扣款。创建任务时可以使用业务唯一 ID；更新操作先读取版本号；批量操作设置上限；失败重试采用指数退避；超过阈值进入人工处理。模型负责语义判断，确定性代码负责权限、金额、数量和状态机约束。

10. 隐私、安全与版权边界

AI 工具的风险可以沿数据流检查：输入了什么，系统保存什么，模型输出什么，工具执行什么，结果被发送到哪里。任何一步涉及敏感数据，都应有明确控制。

输入前进行数据分级。公开资料通常可以使用公开服务；内部资料应使用组织批准的企业环境；机密代码、个人身份信息、健康数据、密钥和未发布财务数据必须遵循专门政策。API key、私钥、会话 cookie、生产配置和数据库导出不应直接粘贴进聊天框。日志可以先脱敏：替换姓名、邮箱、令牌、IP 或业务 ID，同时保留分析所需结构。

# 提交给外部工具前，先寻找常见秘密模式；结果仍需人工判断
rg -n --hidden \
  '(BEGIN .*PRIVATE KEY|api[_-]?key|secret|password|token)' \
  --glob '!node_modules/**' --glob '!.git/**' .

# 检查即将交给编程 Agent 的仓库状态
git status --short
git ls-files | rg '(\.env|credentials|secret|private)'

输出也可能带来版权和合规问题。模型生成的文字、代码或图像可能与训练材料、检索来源或现有作品相似。用于商业发布前应进行来源、许可证、商标和相似性审查。代码 Agent 引入依赖时要查看许可证与供应链风险，不能因为代码“由 AI 生成”就跳过安全扫描。

Agent 的工具权限应遵循最小权限。读取和写入分开，测试环境和生产环境分开，浏览器登录态与自动化沙箱分开。删除、付款、发布、权限变更、发送消息和合并代码属于高风险操作，应在执行前展示目标、参数和影响，并要求人工确认。

11. 质量、成本与速度如何一起评估

AI 工具的评估必须使用自己的任务集。公开基准能够提供参考，却不能替代真实工作中的文件格式、语言、业务规则和失败成本。可以从过去任务中抽取 20 到 100 个代表性样本，为每个样本记录输入、期望结果、允许误差和风险级别，然后让候选工具在相同条件下运行。

最简单的综合得分可以写成加权平均：

\[ Q = \frac{\sum_{i=1}^{n} w_i s_i}{\sum_{i=1}^{n}w_i} \]

\(s_i\) 是第 \(i\) 个样本得分，\(w_i\) 是重要性。高风险样本应给更大权重，不能让大量简单问题掩盖少量严重错误。除了最终正确率，还应记录引用准确率、工具调用成功率、人工修改时间、首响应延迟、总耗时和成本。

API 场景的单次近似成本为：

\[ C_{run}=\frac{T_{in}}{10^6}P_{in}+\frac{T_{out}}{10^6}P_{out}+C_{tools}+C_{infra} \]

其中 \(T_{in},T_{out}\) 是输入和输出 token 数，\(P_{in},P_{out}\) 是每百万 token 价格，\(C_{tools}\) 是搜索、浏览器或其他工具费用，\(C_{infra}\) 是运行沙箱、向量库和日志系统的成本。实际价格必须查阅当前官方定价页。对长任务，还要计算失败重试和人工复核成本。

更快并不总是更好。头脑风暴可以优先低延迟模型，最终审计可以使用更强推理和更多验证。成熟系统常采用模型路由：简单分类走小模型，复杂推理走强模型，高风险结果追加独立校验。路由规则应基于评测，而不是凭直觉设置。

12. 常见失败及排查方法

当回答事实错误时，先检查模型是否获得可靠来源，而不是立即反复改写提示词。要求它标记引用，打开原文核对；若资料没有答案，应允许系统回答“不知道”。当回答遗漏约束时，缩短上下文，把验收条件放在清晰位置，并要求输出前逐项检查。

当编程 Agent 越改越乱时，立即停止自动循环，查看 git diff 和执行日志。恢复到最近可验证状态，把任务缩小为一个失败测试或一个文件，再继续。不要在未知状态下继续追加“请修好”，这会让错误假设和补丁一起扩大。

当工具调用反复失败时，区分模型选错工具、参数格式错误、权限不足、服务超时和业务规则拒绝。每种失败需要不同处理：参数错误应改 schema；权限不足应明确告知而不是盲目重试；超时可以退避重试；业务拒绝必须返回可理解原因。

当费用异常升高时，检查历史消息是否无限增长、文件是否被重复发送、Agent 是否在循环、输出上限是否过大、缓存是否生效。设置最大步骤、最大 token、最大工具次数和单任务预算，在达到上限时返回当前状态，而不是继续消耗。

当结果看起来“很专业”但无法落地时，通常是交付格式和验收条件不清。让系统输出具体文件、表格字段、命令、证据或决策记录，并说明怎样验证。可执行的中间产物比修辞完整的长文更有价值。

13. 一套可复用的 AI 工作方法

第一步是定义问题。写清楚要改变什么现实状态、谁使用结果、截止时间和错误代价。第二步是准备上下文，只提供必要资料，标注可信来源和未知项。第三步是选择工具形态：无需外部事实用通用助手，需要来源用研究工具，需要修改仓库用编程 Agent，需要跨系统操作用受控自动化。

第四步是先小样本运行。观察系统怎样解释目标、调用了什么工具、哪里需要人工补充。第五步是建立验证：文字核对来源，代码运行测试，数据复算指标，图片检查细节与授权，操作确认目标和参数。第六步才是扩大自动化，并增加日志、预算、审批和回滚。

可以把每次重要任务的记录保存为以下结构：

任务名称：
目标与验收条件：
数据分级：公开 / 内部 / 机密
使用工具与版本：
输入来源：
模型生成内容：
工具执行内容：
人工修改：
验证结果：
成本与耗时：
遗留风险：

持续记录能够把“感觉这个工具不错”转化为组织经验。工具更新后，用同一批任务重新评测，就能知道变化是否真的带来收益。

14. 常用工具与选择速查

需求 优先考虑 使用前检查 完成后检查
快速解释和草稿 通用对话助手 是否需要最新事实 逻辑、事实、语气
基于资料问答 文件工作区、NotebookLM、RAG 资料是否完整可信 每个引用是否匹配
行业调研 Deep Research、研究搜索 截止日期、来源范围 原始来源与反例
局部写代码 IDE 助手 当前文件与接口约束 类型、lint、单测
仓库级改动 编程 Agent 分支、权限、验证命令 diff、测试、安全
私有离线推理 Ollama、llama.cpp、vLLM 许可证、显存、吞吐 质量、端口、日志
重复业务流程 自动化平台、自建 Agent 凭据、幂等、审批 审计、告警、回滚
视觉创作 图片/视频生成工具 授权、参考素材 文字、人物、版权

无论使用哪一种工具，都不要跳过三条底线：重要事实必须有可打开的来源，重要代码必须有可运行的验证，高风险行动必须在执行前确认。

15. 延伸阅读