1. 从“给AI发电脑”说起这件事到底在解决什么问题OpenAI 给 AI 发了台电脑——这句话听起来像个段子但它精准概括了当下智能体领域最核心的一次范式转移。过去我们跟大模型打交道基本停留在“你问我答”的层面我贴一段代码让它改它改完我复制走我描述一个需求让它写方案它写完我手动落地。整个过程里AI 是个“顾问”不是“员工”。而“发电脑”这个动作的本质是把执行权交了出去——AI 不再只是给建议它能自己打开终端、跑命令、读写文件、装依赖、跑测试最后把结果交回来。这就是 Codex 这类命令行编码智能体真正在做的事。它把模型能力封装进一个可以自主操作开发环境的循环里理解任务、规划步骤、执行命令、观察输出、修正错误、继续推进。你给它的不再是一句 prompt而是一个“工位”——有文件系统、有 shell、有网络、有工具链。它缺的不是智力是“派活”的方法。我之所以想聊这个话题是因为过去大半年里我见过太多人拿到这类工具后的第一反应是“就这”——他们输入一句“帮我做个电商网站”然后盯着屏幕等奇迹三分钟后骂骂咧咧地关掉。问题不在工具在于他们还在用“聊天”的思维去驱动一个“干活”的系统。派活是一门手艺给 AI 派活更是。这篇文章想做的就是把“怎么给一个拥有电脑的 AI 派活”这件事拆开揉碎讲清楚它的运行逻辑是什么、任务该怎么拆、指令该怎么写、坑都在哪里、怎么判断它干得对不对。适合读这篇的人很明确已经在用或准备用命令行编码智能体的人、带团队做智能体落地的技术负责人、以及所有对“AI 员工”这个概念既兴奋又不知道怎么下手的人。不需要你是算法专家但需要你对终端、代码仓库、基本开发流程有概念。下面所有内容都围绕一个核心问题展开——当 AI 有了电脑你该怎么当一个合格的“派活的人”。2. 智能体拿到电脑之后运行逻辑到底变了什么2.1 从“单轮问答”到“感知-决策-执行”闭环传统大模型交互是一个开环输入 prompt输出文本结束。模型不知道自己的输出有没有被采纳也不知道执行结果对不对。而命令行编码智能体的核心变化是把这个开环变成了闭环。它内部跑的是一个“感知-决策-执行-观察”的循环读取当前工作目录状态、理解任务目标、决定下一步动作比如运行某条命令或修改某个文件、执行、拿到输出、判断是否达成目标、没达成则继续循环。这个循环听起来简单但它是“AI 员工”和“AI 顾问”的分水岭。顾问只负责说员工要负责做完。做完意味着它必须能处理执行过程中的意外命令报错了、依赖缺失了、文件路径不对了、测试没通过了。这些在传统问答里根本不会出现因为传统问答压根不执行。而一旦执行错误就是常态容错和自纠就成了核心能力。我实测下来一个成熟的编码智能体在遇到报错时通常会先读错误信息、定位是环境问题还是代码问题、尝试修复、重跑。这个过程中它可能会走弯路比如反复装同一个依赖、在错误的方向上改代码。这时候“派活的人”的价值就体现出来了——你要在它卡住之前给出约束而不是等它绕了十圈才介入。2.2 为什么“给电脑”比“给提示词”难得多给提示词是单向的你写清楚就行。给电脑是双向的你要考虑它拿到电脑后会做什么、能做什么、不该做什么。这里面的难点至少有三层。第一层是权限边界。AI 有了 shell就意味着它能执行任意命令。你让它“清理一下临时文件”它可能真的去删东西。你让它“优化一下构建流程”它可能改掉你的 CI 配置。所以派活的第一原则不是“说清楚要什么”而是“说清楚不能碰什么”。我一般会在任务描述里明确写死不要修改某目录、不要执行某类命令、不要动某配置文件。这不是不信任这是工程纪律。第二层是上下文供给。人干活的时候很多信息是“在场”的——你知道这个项目的历史、知道哪个模块是雷区、知道上次为什么回滚。AI 不知道。它只能看到你给它的和它能读到的。所以派活时要主动补上下文这个仓库是干什么的、当前分支是什么状态、相关文件在哪、有没有已知的坑。你补得越准它跑偏的概率越低。第三层是验收标准。人干活你知道怎么验收AI 干活你更得知道。因为它会“自信地交付一个错的东西”。所以每个任务都要有可验证的完成条件测试通过、构建成功、某个命令输出符合预期。没有验收标准的任务等于没派。2.3 一个典型任务的完整生命周期我拿一个真实场景走一遍。假设我要让智能体给一个 Python 项目加一个命令行参数--dry-run要求是不实际执行写操作只打印将要做什么。任务派下去之后它的典型生命周期是这样的先读项目结构找到入口文件和参数解析部分然后读相关代码理解现有参数是怎么定义的接着修改代码加入新参数和分支逻辑再跑一遍现有测试确认没破坏东西然后自己写一个临时脚本或直接运行命令验证--dry-run行为符合预期最后把改动汇总告诉你改了哪些文件、验证结果如何。这个链条里任何一环出问题都会导致任务失败。比如它没找到入口文件、比如它改错了参数解析库、比如它跑测试时环境缺依赖。而“派活的人”要做的是在派活时就把这些风险点尽量前置消除告诉它入口文件大概在哪、告诉它项目用的是哪个参数库、告诉它测试怎么跑。你多写三行上下文它可能少绕十分钟。3. 派活的核心手艺任务拆解与指令设计3.1 为什么“帮我做个网站”必然失败这是最常见的翻车现场。用户输入一句宏大目标期待智能体自己拆解、自己规划、自己执行到底。结果通常是智能体要么卡在第一步不知道从哪开始要么随便选个技术栈闷头写写出一堆跑不起来的东西要么反复问你“你想用什么框架”直到你崩溃。根本原因在于智能体的规划能力是有边界的。它擅长在明确约束下执行不擅长在模糊目标下做产品决策。“做个网站”里面藏着几十个决策什么类型的网站、给谁用、什么技术栈、要不要数据库、部署到哪里、界面长什么样。这些决策你不做它就得猜猜错的概率极高。正确的做法是把“做个网站”拆成它能在单次循环里完成的任务。比如第一步“在当前目录初始化一个 Vite React 项目使用 TypeScript不要装额外依赖完成后告诉我目录结构。”这一步目标单一、验收明确、不需要产品决策。它做完你验收再派下一步。这就是“派活”和“许愿”的区别。3.2 任务拆解的粒度怎么把握拆得太粗它跑偏拆得太细你比自己干还累。我的经验是一个任务应该满足三个条件单次可完成、结果可验证、失败可回滚。单次可完成意思是这个任务不需要跨越多个决策点。比如“实现用户登录”就太粗因为里面包含选认证方式、设计表结构、写接口、写前端多个决策。“在现有 User 模型上加一个 last_login 字段并写迁移脚本”就刚好目标单一。结果可验证意思是任务完成后有一个明确的判断标准。比如“优化代码性能”不可验证“把某函数的循环改成批量查询跑测试确认通过”就可验证。失败可回滚意思是如果它做砸了你能干净地退回去。所以派活前确保工作区是干净的、有版本控制、或者你先打个快照。我习惯在派大任务前先 commit 一次这样它改乱了我一个命令就能回滚。粒度上还有个实用技巧按文件或按函数派活。比如“修改src/utils/parse.ts里的parseConfig函数让它支持嵌套配置”就比“改一下配置解析”精确得多。精确的定位能大幅降低它读错文件、改错地方的概率。3.3 指令里必须写清楚的五件事我总结了一个派活模板每次派任务前对照检查基本能避免八成翻车。这五件事是目标、范围、约束、验收、汇报格式。目标是“要达成什么”一句话说清。范围是“可以动哪些文件/目录”防止它到处乱改。约束是“不能做什么”比如不能装新依赖、不能改测试、不能动某配置。验收是“怎么算完成”比如某命令输出某结果、某测试通过。汇报格式是“完成后告诉我什么”比如改了哪些文件、跑了什么验证、有没有遗留问题。举个例子一个合格的派活指令长这样目标给src/cli.py增加--dry-run参数。范围只修改src/cli.py和tests/test_cli.py。约束不新增第三方依赖不改动其他文件。验收pytest tests/test_cli.py全部通过且手动运行python src/cli.py --dry-run时打印[dry-run]前缀且不执行写操作。汇报列出修改的文件、测试结果、以及你对 dry-run 分支的处理方式。这个指令里没有一句废话但每一句都在缩小它的决策空间。它不需要猜只需要执行。这就是派活的手艺。3.4 上下文注入把“在场知识”翻译给它前面说过AI 缺的是“在场知识”。派活时主动注入上下文能显著提升成功率。我一般会注入这几类信息项目背景这是什么项目、用什么技术栈、当前状态在哪个分支、有没有未提交改动、相关文件位置入口在哪、配置在哪、测试在哪、已知坑点某依赖版本有 bug、某目录是自动生成的别动。注入方式可以写在任务描述里也可以让它先读某个说明文件。我习惯在项目根目录放一个AGENT.md里面写清楚项目结构、常用命令、禁区、验收方式。每次派活前让它先读这个文件相当于给它做了一次入职培训。这个做法实测下来非常稳尤其是对反复派活的项目一次写好后面省很多口舌。4. 实操全流程从零派一个可验证的任务4.1 环境准备与工作区快照动手之前先把地基打好。第一步确认智能体工具已经装好、能正常启动、能连上模型。第二步确认工作区干净git status没有未提交改动或者你先 commit 一次。第三步确认基础命令可用项目能构建、测试能跑、依赖齐全。这三步任何一步没做好后面出问题你都分不清是它的锅还是环境的锅。我踩过的一个坑是工作区有未提交改动时派活它改完我发现分不清哪些是它改的、哪些是我之前改的。后来我养成习惯派活前必 commit或者至少git stash。这样它交付后我git diff一看清清楚楚。4.2 写一份它读得懂的派活指令接着按上一节的五要素写指令。这里有个细节用它能精确匹配的路径和命令。别说“改一下配置文件”要说“修改config/settings.yaml第 12 行的timeout值”。别说“跑一下测试”要说“运行npm test -- --grep auth”。精确的路径和命令能减少它的搜索成本也能减少它改错地方的概率。指令写完后自己读一遍问三个问题目标是否单一验收是否可执行约束是否明确三个都是“是”再派出去。4.3 观察执行过程与关键介入点派出去之后不是就不管了。我一般会盯着它的执行输出重点看三个信号它读的文件对不对、它跑的命令对不对、它有没有开始绕圈。读的文件不对说明它理解偏了这时候早点打断比让它跑完再返工划算。跑的命令不对比如它开始装一堆无关依赖也要及时叫停。开始绕圈是最危险的信号——同一个错误反复出现、同一个文件反复改、开始尝试各种奇怪方案。这时候果断介入给它更明确的提示或者直接接管。介入的时机很关键。太早介入它还没机会自己解决你等于在替它干活。太晚介入它已经改乱一堆文件回滚成本高。我的经验是第一次报错让它自己试第二次同类报错给它一点提示第三次还不行就接管。这个节奏实测比较平衡。4.4 验收怎么判断它真的干完了它说“完成了”不算完成你得自己验。验收分三层它自己跑的验证、你复跑的验证、边界情况验证。它自己跑的验证看它汇报里有没有跑测试、跑的是什么、结果如何。你复跑的验证是你亲自跑一遍它说的验收命令确认结果一致。边界情况验证是它没覆盖到的场景比如空输入、异常输入、并发情况。前两层是基本要求第三层是区分“能跑”和“可靠”的关键。我遇到过一次它说测试全过我复跑也全过但边界情况一测就崩——它只处理了正常路径没处理异常。所以边界验证不能省尤其是对可靠性要求高的任务。5. 常见翻车现场与排查速查5.1 它读错文件、改错地方怎么办这是最高频的问题。原因通常是路径不明确或项目结构复杂。排查思路先看它读了哪些文件确认是不是你期望的如果读错了在指令里把路径写得更死如果项目有多个同名文件用完整相对路径区分。预防手段是在AGENT.md里写清楚目录结构和关键文件位置。5.2 它反复装依赖、环境越搞越乱怎么办常见于它遇到缺依赖时的本能反应是“装一个”。但装依赖可能改 lock 文件、可能引入版本冲突。预防手段是在约束里写死“不新增依赖缺什么先报告”。如果确实需要装让它先列出要装什么、为什么装你确认后再装。5.3 它自信地交付错误结果怎么办这是最隐蔽的坑。它会用很确定的语气告诉你“已完成”但实际是错的。对抗手段只有一个强制验收标准。每个任务都必须有可执行的验收命令它跑完你复跑。没有验收标准的任务不派。另外让它汇报时附上原始命令输出而不是只给结论。5.4 任务太大它中途迷失怎么办表现是它做着做着开始做无关的事或者反复回到起点。根因是任务粒度太粗。解决办法是拆小拆到单次可完成。如果已经派了大任务发现它迷失果断叫停回滚重新拆。翻车现象可能原因排查动作预防手段读错文件路径不明确看它读了哪些文件指令写死完整路径反复装依赖缺依赖时本能安装看它装了什么约束里禁止新增依赖自信交付错误无验收标准复跑验收命令强制可执行验收中途迷失任务粒度过粗看它是否绕圈拆到单次可完成改乱工作区无快照git diff 看改动派活前 commit5.5 几个我踩过的坑和对应技巧第一个坑没写汇报格式它交付时只给一句“完成了”我得自己翻 diff 找改了什么。后来我在指令里强制要求列出修改文件清单和验证结果省了很多事。第二个坑让它“优化一下”结果它大改特改把能跑的代码改崩了。后来我学会把“优化”翻译成具体动作比如“把某函数的循环查询改成批量查询保持接口不变”。第三个坑多个任务连着派它把上一个任务的临时文件带到了下一个任务里。后来我养成习惯每个任务开始前确认工作区状态必要时清理临时产物。6. 从“会用”到“会派”一些个人体会我用了大半年这类工具最大的体会是它的上限不取决于模型多强取决于派活的人多清楚自己要什么。一个能把任务拆清楚、约束写明白、验收定严格的人用中等模型也能拿到稳定产出一个只会许愿的人用最强模型也是天天翻车。另一个体会是派活这件事本身是可以积累的。每次翻车后把原因记下来下次派活前对照检查。我现在的派活指令模板就是从几十次翻车里长出来的。你不需要一开始就写得多完美但每次都要比上次多写清楚一点。最后一个实用建议先派小任务建立信任再派大任务。别一上来就让它重构整个项目。先让它改一个函数、加一个参数、修一个 bug看它的执行风格、看它怎么处理报错、看它汇报是否靠谱。摸清脾气之后再逐步放大任务粒度。这个过程跟带新人一模一样——你先给他一个小活试试水靠谱了再给重要的活。给 AI 发电脑这件事工具已经就位了。剩下的是派活的人要补的课。