1. 从写提示词到搭回路Loop Engineering 到底在解决什么问题大多数人用 AI 编程工具的方式还停留在我问一句、它答一句的阶段。你打开 Claude Code 或者 Cursor敲一段需求等它吐出一坨代码复制粘贴跑一下报错了再回去追问。这种交互模式在写一个函数、改一个 bug 的时候够用但一旦任务变成给整个项目加一套鉴权体系或者把现有 API 从 REST 迁移到 GraphQL你就会发现——来回对话几十轮之后上下文丢了它开始忘记前面定好的约定甚至把之前改好的文件又改回去。Loop Engineering 要解决的就是这个问题。它不是某个具体的工具或框架而是一套让 AI 编程助手在闭环中自主迭代的工程方法论。核心思路是你不再扮演逐句指挥的角色而是设计一个回路Loop——定义目标、约束、验证条件和反馈机制——让 AI 在这个回路里自己跑自己检查自己修正直到满足退出条件。打个比方。传统的提示词工程像是你手把手教一个实习生改代码每一步都要盯着Loop Engineering 则是你给这个实习生一份清晰的 SOP、一套自动化测试、一个代码规范检查工具然后告诉他跑通所有测试、通过 lint 检查、覆盖率不低于 80%就算完成。你设计的是流程和环境而不是每一句话。这套方法论之所以现在火起来跟三个东西的成熟直接相关Claude Code 的 Agent 能力它能直接读写文件、执行终端命令、运行测试具备感知-行动-验证的物理条件。Codex 的沙箱执行环境它可以在隔离环境里跑代码、看结果、自我修正不需要你手动搬运输出。Cursor 的项目级上下文理解它能索引整个代码库理解跨文件的依赖关系让回路有足够的上下文支撑。这三个工具各有侧重但底层逻辑是一致的AI 编程正在从对话式辅助转向目标驱动的自主执行。而 Loop Engineering 就是驾驭这种转变的方法论。注意Loop Engineering 不是让你完全放手不管。回路设计得好不好直接决定了 AI 是在高效产出还是在高效制造技术债。后面的章节会详细拆解怎么设计一个靠谱的回路。这篇文章适合两类人一是已经在用 Claude Code、Codex 或 Cursor但感觉效率提升有限的开发者二是刚接触 AI 编程工具想从一开始就建立正确使用习惯的新手。我会从环境搭建讲起到回路设计的核心原则再到三个工具的具体实战配置最后分享一些踩坑经验。2. 环境准备Claude Code、Codex、Cursor 的安装与基础配置在聊回路设计之前得先把工具跑起来。这一章覆盖三个主流工具的安装、配置和常见问题。如果你已经装好了可以跳到第 3 章但建议扫一眼配置部分——有些默认设置不改的话后面做回路会很别扭。2.1 Claude Code 的安装与终端集成Claude Code 目前有两种使用形态一种是作为独立 CLI 工具另一种是作为 VS Code 插件。两者能力基本一致但 CLI 版本在脚本化和自动化方面更灵活推荐做 Loop Engineering 时优先用 CLI。安装方式取决于你的操作系统。macOS 和 Linux 下官方推荐通过包管理器安装# macOS (Homebrew) brew install anthropic/tap/claude-code # 或者通过 npm 全局安装 npm install -g anthropic-ai/claude-codeWindows 用户目前建议在 WSL2 环境下使用原生 Windows 支持还在完善中。安装完成后第一次运行claude会引导你完成登录和 API 配置。VS Code 用户可以直接在扩展市场搜索 Claude Code 安装插件。装好之后在 VS Code 的设置里找到 Claude Code 相关配置项把默认模型、工作目录、权限模式调一下。权限模式这一项特别关键——默认情况下 Claude Code 每次执行终端命令都会问你是否允许这在做回路的时候会把你逼疯。你可以在设置里把它改成自动批准安全命令或者配置一个白名单把npm test、git diff、ls这类只读或测试命令加进去。Ubuntu 用户如果遇到权限问题通常是 npm 全局目录的权限没配好。可以这样处理mkdir -p ~/.npm-global npm config set prefix ~/.npm-global echo export PATH~/.npm-global/bin:$PATH ~/.bashrc source ~/.bashrc然后再执行安装命令。这个坑我踩过好几次每次在新机器上配环境都要重新查一遍。2.2 Codex 的安装与配置文件解析Codex 的安装相对直接官网下载安装包或者通过命令行工具安装都可以。Windows 桌面版和 macOS 版都有Linux 用户目前主要通过 CLI 使用。安装完成后Codex 的核心配置集中在一个配置文件里。这个文件通常位于用户目录下的.codex文件夹中格式是 TOML 或 JSON取决于版本。配置文件里几个关键字段值得关注配置项作用推荐值model指定使用的模型根据任务复杂度选择sandbox沙箱执行模式workspace-write或danger-full-accessapproval_policy命令审批策略回路场景下建议on-failuremax_turns单次会话最大轮次20-50视任务而定timeout单条命令超时时间300 秒起步sandbox这个字段特别重要。它决定了 Codex 能在多大范围内操作你的文件系统。做回路的时候你希望它能自由读写项目文件、执行测试但又不想它碰到系统关键目录。workspace-write模式允许它在工作目录内自由操作是比较平衡的选择。有些用户反馈 Codex 登录不上或者无法加载组织设置这类问题通常跟网络环境或账号权限有关。如果是个人使用确认账号状态正常即可如果是团队账号可能需要管理员在后台开通相应权限。2.3 Cursor 的中文设置与项目索引优化Cursor 是基于 VS Code 二次开发的编辑器所以它的很多操作逻辑跟 VS Code 一致。中文设置很简单打开设置面板搜索 language把显示语言改成 中文简体 即可。如果搜索不到中文选项可能需要先安装中文语言包插件。但 Cursor 真正影响 Loop Engineering 体验的是它的项目索引功能。Cursor 会对你打开的项目建立向量索引这样 AI 在回答问题时能引用整个代码库的上下文。索引质量直接决定了回路中 AI 的理解力。几个优化建议在项目根目录放一个.cursorignore文件把node_modules、dist、.git这些不需要索引的目录排除掉。索引这些目录不仅浪费时间还会稀释有效上下文。保持项目结构清晰。Cursor 的索引对目录结构敏感如果你的代码文件散落在各种奇怪的路径下索引效果会打折扣。定期重建索引。项目大改之后手动触发一次重建确保 AI 看到的是最新代码。Cursor 的免费额度有限做回路的时候消耗会比较快。如果打算长期用建议提前了解付费方案。另外有用户反馈 Cursor 响应速度慢这通常跟项目规模、索引状态和网络延迟有关。把.cursorignore配好、关掉不用的插件能明显改善。2.4 三个工具的定位差异与选择逻辑很多人问Cursor 和 Claude Code 是什么关系其实它们不是替代关系而是互补关系。我自己的用法是Cursor 负责写它的编辑器体验好补全快适合日常编码和快速修改。Claude Code 负责跑它的终端集成强适合执行测试、跑构建、做自动化任务。Codex 负责验它的沙箱环境适合做隔离验证尤其是需要跑一些有副作用的命令时。当然这不是绝对的。你也可以只用其中一个工具完成所有事情但理解它们的差异有助于你在回路设计时做出更合理的分工。3. 回路设计的五个核心组件目标、约束、验证、反馈、退出工具装好了接下来是重头戏怎么设计一个能跑的回路。我把它拆成五个组件缺一不可。3.1 目标定义把帮我改一下翻译成可执行的指令回路的第一要素是目标。但目标这个词太抽象了AI 需要的是可验证的完成条件。对比一下这两种说法模糊目标帮我优化一下这个 API 的性能可执行目标把/api/users接口的 P95 响应时间降到 200ms 以下方法是给users表的email字段加索引并缓存重复查询结果。完成后运行npm run benchmark验证。第二种说法包含了三个关键信息具体指标P95 200ms、实现路径加索引 缓存、验证方式跑 benchmark。AI 拿到这样的目标才知道什么时候算做完了。我通常用一个模板来写目标目标[一句话描述要达成什么] 验收标准 1. [可量化的指标] 2. [可运行的验证命令] 3. [必须通过的测试] 约束条件 - [不能改动的文件/模块] - [必须遵守的代码规范] - [性能/安全方面的硬性要求]这个模板看起来简单但能过滤掉 80% 的模糊需求。你写不出验收标准说明你自己还没想清楚要什么这时候让 AI 去跑只会浪费 token。3.2 约束设置告诉 AI 什么不能碰约束是回路的护栏。没有约束的 AI 就像没有交通规则的路口迟早出事。常见的约束类型文件级约束禁止修改package.json、禁止动migrations目录、禁止改.env文件。依赖级约束不允许引入新的第三方库或者只允许引入指定的几个库。风格级约束必须用函数式组件、必须写 JSDoc 注释、变量命名用 camelCase。安全级约束不允许在代码里硬编码密钥、不允许关闭现有的安全检查。在 Claude Code 里你可以把这些约束写进项目根目录的CLAUDE.md文件它会在每次会话开始时自动读取。Codex 类似可以在配置文件里指定一个instructions文件。Cursor 则可以通过.cursorrules文件来设置。我自己的CLAUDE.md里常年放着这几条## 硬性约束 - 不要修改 package.json 中的依赖版本 - 不要删除任何现有的测试用例 - 所有新函数必须有 JSDoc 注释 - 提交前必须通过 npm run lint 和 npm test - 如果遇到不确定的架构决策先停下来问我最后一条特别重要。AI 有时候会自作主张做一些它觉得合理的改动比如重构一个它认为设计不好的模块。加一条不确定就问的约束能避免很多意外。3.3 验证机制让 AI 自己检查作业验证是回路的核心。没有验证AI 就是在盲跑。验证机制分三层第一层自动化测试。这是最可靠的验证。你的项目里有多少测试AI 就有多少自动检查点。如果测试覆盖率低回路的效果会大打折扣。所以在做 Loop Engineering 之前先把测试补一补这是值得的投资。第二层静态检查。Lint 工具、类型检查器、格式化工具这些能在不运行代码的情况下发现大量问题。把eslint、prettier、tsc --noEmit这些命令配好让 AI 每次改完代码都跑一遍。第三层自定义验证脚本。有些验证逻辑没法用现成工具表达比如检查所有 API 路由都有对应的错误处理。这时候可以写一个简单的脚本让 AI 在回路中调用。在回路中验证命令的执行顺序建议是先跑快的lint、类型检查再跑慢的单元测试、集成测试。这样 AI 能快速得到反馈不用等几分钟才发现一个拼写错误。3.4 反馈循环AI 拿到错误信息之后怎么处理反馈循环是回路活起来的关键。AI 跑完验证拿到错误信息然后根据错误信息修正代码再跑验证——这个循环的质量取决于两个因素错误信息的可读性和修正策略的合理性。错误信息方面尽量让验证工具输出结构化、可读的结果。比如 Jest 的--verbose模式、ESLint 的--format json都比默认输出更容易被 AI 理解。修正策略方面你可以在约束文件里加一些指导## 错误处理策略 - 如果测试失败先读测试用例理解预期行为再改代码 - 如果同一个测试连续失败 3 次停下来分析根因不要继续盲目修改 - 如果 lint 报错优先修复而不是禁用规则 - 如果遇到类型错误先检查类型定义是否正确再改实现这些策略能显著减少 AI 的无效尝试。我见过太多情况是 AI 在一个错误上反复横跳改了 A 导致 B 报错改了 B 又导致 A 报错陷入死循环。加一条连续失败 3 次就停的规则能及时止损。3.5 退出条件什么时候算跑完了退出条件必须明确否则回路要么提前退出任务没完成要么永远不退出AI 一直在微调。退出条件通常包括成功退出所有验收标准都满足所有测试通过lint 无错误。失败退出达到最大轮次限制或者连续 N 次验证失败。人工介入退出AI 遇到不确定的决策主动请求人工确认。在 Claude Code 里你可以用--max-turns参数限制最大轮次。Codex 的配置文件里有max_turns字段。Cursor 目前没有直接的轮次限制但你可以通过提示词约定如果 5 轮之内没搞定就停下来汇报。我一般把最大轮次设在 15-25 之间。太少了任务跑不完太多了浪费资源。具体数值取决于任务复杂度简单任务 10 轮够了复杂重构可能需要 30 轮以上。4. 实战用 Claude Code 搭建一个自动修 Bug 的回路理论讲完了来看一个完整的实战案例。场景是项目里有一批失败的测试需要 AI 自动修复。4.1 回路设计从失败测试到通过测试的完整链路这个回路的逻辑很简单运行测试收集失败列表逐个分析失败原因修改代码重新运行测试如果还有失败回到第 2 步全部通过退出但实际执行起来有几个细节需要处理测试之间可能有依赖关系修好一个可能影响另一个有些失败是测试本身写错了不是代码的问题有些失败需要改多个文件才能修复所以回路设计要加上一些判断逻辑。我在CLAUDE.md里这样写## Bug 修复回路 1. 运行 npm test 获取失败列表 2. 对每个失败的测试 a. 读测试文件理解预期行为 b. 读相关源码定位问题 c. 判断是代码问题还是测试问题 d. 如果是代码问题修改代码如果是测试问题先问我 e. 单独运行该测试验证修复 3. 所有单个测试通过后运行完整测试套件 4. 如果完整套件有失败重复步骤 2 5. 最多重复 5 轮超过则停止并汇报这个流程的关键在于先单独验证再整体验证。如果每次改完都跑完整套件速度会很慢。先跑单个测试快速确认最后再跑全套效率高很多。4.2 提示词模板怎么把回路逻辑写进 CLAUDE.mdCLAUDE.md是 Claude Code 的项目级指令文件放在项目根目录每次会话自动加载。它的写法直接影响回路的效果。我的模板大致长这样# 项目上下文 这是一个 Node.js TypeScript 的 REST API 项目使用 Express 框架Jest 做测试。 # 常用命令 - 安装依赖npm install - 运行测试npm test - 运行单个测试npm test -- --testPathPattern文件名 - 类型检查npx tsc --noEmit - Lintnpm run lint # 回路规则 - 每次修改代码后必须运行相关测试 - 测试通过后运行类型检查和 lint - 如果类型检查或 lint 报错先修复再继续 - 不要修改测试文件来让测试通过除非我明确要求 - 遇到不确定的情况停下来问我 # 代码规范 - 使用 2 空格缩进 - 函数名用 camelCase类名用 PascalCase - 所有导出函数必须有 JSDoc - 错误处理用 try-catch不要吞掉异常这个文件不需要写得很长但每一条都要具体、可执行。写好的代码这种话没用所有导出函数必须有 JSDoc才有用。4.3 执行过程观察 AI 的每一步决策配置好之后启动 Claude Code输入运行 npm test找出所有失败的测试逐个修复直到全部通过。然后你就可以观察它的执行过程了。一个典型的执行链路是这样的[读取 CLAUDE.md] [执行 npm test] [发现 3 个失败测试] [读取第一个失败的测试文件] [读取相关源码] [分析缺少空值检查] [修改源码添加空值检查] [运行单个测试] [通过] [处理第二个失败测试] ... [运行完整测试套件] [全部通过] [运行类型检查] [通过] [运行 lint] [发现 2 个警告] [修复警告] [重新运行 lint] [通过] [汇报完成]整个过程可能持续几分钟到十几分钟取决于任务复杂度。你不需要盯着看可以去干别的事回来看结果就行。4.4 效果评估哪些 Bug 修得好哪些修不了实测下来这个回路对以下几类 Bug 修复效果很好空值/边界条件问题AI 很擅长发现缺少 null 检查、数组越界这类问题。类型错误TypeScript 的类型报错AI 基本能自己修好。简单的逻辑错误比如条件判断写反了、循环边界不对。API 签名不匹配函数调用参数不对AI 能根据类型定义修正。但以下几类AI 往往搞不定或者修得很勉强业务逻辑错误需要理解业务背景才能判断对错的问题。并发/竞态问题这类问题测试很难稳定复现AI 也难定位。性能问题测试通过不代表性能达标AI 容易忽略性能维度。需要外部依赖的测试比如依赖数据库、第三方 API 的测试AI 在沙箱里跑不了。遇到这些情况回路会卡住。所以我在CLAUDE.md里加了连续失败 3 次就停下来问我的规则避免它浪费时间。5. Codex 沙箱验证与 Cursor 项目级重构的回路差异Claude Code 的回路偏重执行-验证Codex 和 Cursor 的回路则各有侧重。这一章讲清楚它们的差异以及怎么针对性地设计回路。5.1 Codex 沙箱模式下的回路设计要点Codex 最大的特点是沙箱执行。它在一个隔离环境里跑代码不会直接影响你的工作目录除非你配置成直接写入。这个特性在做探索性回路时特别有用。什么叫探索性回路就是你不确定方案是否可行想让 AI 先试试看。比如我想把这个模块从回调风格改成 Promise 风格但不确定会影响哪些地方。这种任务如果直接在项目里跑改坏了还得回滚。用 Codex 的沙箱模式它可以先在一个副本里试试成功了再把改动同步回来。Codex 的配置文件里sandbox字段控制这个行为[sandbox] mode workspace-write # 允许在工作目录内读写 network false # 禁止网络访问 timeout 300 # 单条命令超时 300 秒network false这一项值得展开说。做回路的时候你通常不希望 AI 去访问外部网络——一是慢二是不可控。把网络关掉强制它用本地资源回路会稳定很多。Codex 的另一个特点是它的审批策略。默认情况下它执行某些命令前会请求批准。做回路时建议把approval_policy设成on-failure意思是只在命令失败时才请求人工介入。这样正常流程不会被打断出问题了才找你。5.2 Cursor 的项目索引如何影响重构回路Cursor 的强项是项目级理解。它的索引能覆盖整个代码库所以在做跨文件重构时Cursor 的回路设计跟 Claude Code 和 Codex 不太一样。重构回路的核心是影响面分析。你改一个函数签名需要知道哪些地方调用了它你改一个数据结构需要知道哪些地方依赖它。Cursor 的索引能帮 AI 快速回答这些问题。我的做法是在.cursorrules里加一条## 重构规则 - 修改任何导出函数/类之前先用 Cursor 的 Find All References 功能找出所有调用点 - 修改数据结构之前先搜索所有使用该结构的地方 - 每次重构后运行完整测试套件 - 如果重构涉及超过 5 个文件先列出改动计划让我确认最后一条是防止 AI改嗨了。有时候它会把一个局部重构扩大成全局重构改了几十个文件最后你 review 都 review 不过来。加一条文件数量限制能控制影响面。Cursor 的另一个优势是实时反馈。你在编辑器里能看到 AI 的每一步改动可以随时打断、纠正。这跟 Claude Code 的批处理模式不同。做重构回路时我倾向于用 Cursor因为重构需要频繁的人工判断完全放手风险太大。5.3 三个工具的回路能力对比维度Claude CodeCodexCursor执行能力强直接操作终端强沙箱隔离中主要通过编辑器上下文范围项目级会话级项目级索引自动化程度高高中人工介入便利性中低高适合场景批量任务、自动化探索性任务、验证重构、日常编码回路设计重点验证机制沙箱配置影响面控制这个表格不是绝对的实际使用中三个工具可以混用。比如用 Cursor 做重构用 Claude Code 跑测试用 Codex 做验证。关键是理解每个工具的特长在回路的不同阶段用合适的工具。5.4 混合使用什么时候该切换工具我自己的切换逻辑是这样的需要快速迭代、频繁人工判断用 Cursor。比如 UI 调整、交互逻辑修改。需要批量执行、自动化验证用 Claude Code。比如批量修复 lint 错误、批量更新依赖。需要隔离验证、探索方案用 Codex。比如尝试新的架构方案、验证性能优化效果。切换的时机通常是当一个工具在某个环节卡住时换另一个试试。比如 Claude Code 在某个测试上反复失败可以切到 Cursor用它的索引能力看看是不是有跨文件的依赖问题没考虑到。6. 踩坑实录回路跑偏的六种典型场景与修复方案这一章是我自己踩过的坑以及从社区里收集到的常见问题。每个坑都给出排查思路和修复方案。6.1 上下文溢出AI 改到后面忘了前面现象回路跑到一半AI 开始做出跟前面约定矛盾的改动。比如前面说好不要改测试文件跑到第 10 轮它开始改测试了。根因上下文窗口有限。当对话轮次多了早期的指令会被挤出去AI 就忘了。排查观察 AI 的改动是否跟CLAUDE.md里的约束矛盾。如果是基本就是上下文溢出。修复把关键约束放在CLAUDE.md里而不是只在对话里说。CLAUDE.md每次会话都会重新加载不受上下文窗口影响。控制单次回路的轮次。超过 15 轮的任务拆成多个子任务分别跑。用/clear命令定期清理对话历史让 AI 重新加载项目指令。6.2 验证命令写错AI 在错误的反馈上迭代现象AI 一直在修复一个问题但问题始终存在。仔细一看它跑的验证命令是错的。根因验证命令的路径、参数或环境不对。比如测试命令写成了npm run test但实际是npm test或者测试文件路径不对。排查手动跑一遍 AI 用的验证命令看输出是否正常。修复在CLAUDE.md里明确写出正确的命令不要依赖 AI 自己猜。验证命令先在终端里手动跑通再交给 AI。如果项目有多个测试命令单元测试、集成测试、端到端测试分别写清楚。6.3 无限循环AI 在两个错误之间反复横跳现象AI 改了 A 文件B 测试失败改了 B 文件A 测试失败。来回好几次问题没解决。根因两个测试的预期行为互相矛盾或者 AI 的修复策略有问题。排查看 AI 的修改历史找出它反复改动的文件。修复加连续失败 3 次就停的规则。检查测试之间是否有依赖关系如果有调整测试顺序或隔离测试。如果是测试本身写错了人工修正测试。6.4 权限拒绝AI 想执行命令但被拦住了现象AI 尝试执行某个命令但被权限系统拦住回路卡住。根因命令不在白名单里或者沙箱模式限制了操作范围。排查看 AI 的报错信息确认是哪个命令被拦了。修复把常用命令加到白名单里。调整沙箱模式给 AI 更多权限但要权衡安全风险。如果是危险命令比如rm -rf不要加白名单而是修改回路逻辑避免需要执行这类命令。6.5 测试污染AI 改了测试让它们通过现象测试确实通过了但你一看 diff发现 AI 把测试的断言改了。根因AI 发现改代码很难让测试通过就走捷径改测试。排查review diff 时特别关注测试文件的改动。修复在约束里明确写不要修改测试文件。用 git hook 或 CI 检查测试文件的改动如果有改动就报警。如果确实需要改测试让 AI 先说明理由人工确认后再改。6.6 性能退化功能对了但慢了十倍现象所有测试通过但代码性能明显下降。根因AI 只关注功能正确性忽略了性能。比如它可能加了一个 O(n²) 的循环或者引入了不必要的同步操作。排查跑性能测试对比改动前后的指标。修复在验收标准里加上性能指标。在回路里加入性能测试步骤。在约束里写明不允许引入 O(n²) 以上的复杂度虽然 AI 不一定能准确判断但能起到提醒作用。7. 让回路越跑越顺我的日常使用习惯与工具链搭配最后分享一些日常使用中的习惯这些不是必须的但能让 Loop Engineering 的体验好很多。第一保持项目可验证。回路的效果跟项目的可验证性成正比。测试覆盖率高、lint 规则完善、类型检查严格的项目回路跑起来顺畅得多。反过来一个没有测试的项目AI 跑完你也不知道对不对。所以花时间补测试、配 lint是 Loop Engineering 的前置投资。第二约束文件要持续维护。CLAUDE.md、.cursorrules这些文件不是写一次就完了。每次遇到 AI 犯的新错误就加一条约束进去。用久了这个文件就成了项目的AI 使用手册新来的 AI 会话一加载就知道规矩。第三回路任务要小步快跑。不要设计一个重构整个项目的大回路而是拆成重构用户模块、重构订单模块这样的小回路。每个回路跑完人工 review 一下确认没问题再跑下一个。这样即使某个回路跑偏了影响面也可控。第四保留人工介入的通道。完全放手的回路听起来很美好但实际上风险很大。我的做法是在关键节点设置检查点比如修改超过 5 个文件就停下来汇报、涉及数据库 schema 改动就停下来汇报。这些检查点不会太频繁地打断流程但能在关键时刻让你介入。第五记录回路的执行日志。Claude Code 和 Codex 都会输出执行日志把这些日志保存下来定期回顾。你会发现一些模式哪些类型的任务 AI 做得好哪些容易出问题。根据这些模式调整你的回路设计。第六工具链搭配要灵活。我现在的工作流大致是Cursor 做日常编码和重构Claude Code 跑自动化任务和测试修复Codex 做探索性验证。三个工具各司其职通过 git 仓库同步改动。这个搭配不是最优解但适合我的工作习惯。你可以根据自己的情况调整。关于 Codex 接入其他模型、Claude Code 的在线升级、Cursor 的插件生态这些话题展开讲又是另一篇文章了。核心思路是一样的理解工具的能力边界设计合适的回路让 AI 在可控范围内自主执行。回路设计得好AI 就是高效的执行者设计得不好就是在高效地制造混乱。这个平衡点需要在实际使用中慢慢摸索。