用OpenCode把AI从聊天搭子升级为工作搭档

你肯定有过这种感觉： 和 AI 聊了半天，说得都对，但就是落不了地。让它写文案，改了五版还是不对味；让它分析问题，分析得头头是道，可问题依旧；让它帮忙整理资料，它一句“你把资料贴给我”就能把人噎住——手头几十份资料，难道要一份份贴到对话框里？ 问题出在哪？ 答案很直接：你一直在和 AI 聊天，从来没让它真正干活。聊天框里的 AI，再聪明也只是“嘴上说说”。真要它做事，你得给它找一个能行动的环境。 这篇文章，我们就来聊聊这件事。 --- ## 一、为什么聊天框里的 AI 干不了活 先打破一个常见误解：不是 AI 不够聪明，是你把它放错了地方。 想象一下，一个人再能干，你把他扔进一间空屋子，只给一部手机跟他聊天，他能完成什么任务？他看不见你的文件，碰不到你的工具，也不了解你做事的方式和规矩。除了陪你聊天，他什么都做不了。 AI 也一样。聊天框里的 AI，就像那个被关在空屋里的人——它的信息仅来源于你刚刚输入的那几句话，除此之外一无所知，也寸步难行。 要让 AI 真正干活，得给它配备三样东西： 第一，**它能看见你的资料**。不用你每次手动粘贴复制，它自己能搜索、翻阅、读取。 第二，**它能使用你的工具**。它能编辑文件、执行指令、对接外部系统，而不是只停留在嘴皮子上。 第三，**它得了解你的规矩**。它知道你做事的方式、预期的输出格式、什么可以做、什么不能碰。 有了这三项，AI 才能从“陪你聊天”的角色，转变为“和你一起工作”的伙伴。 --- ## 二、OpenCode 是什么 OpenCode 就是这样一个能让 AI 动真格的环境。 你可以把它理解成——给你的 AI 搭档配备的一张大工作台。这张台上，集中了它干活所需的一切： * 你的项目文件、源代码、文档，它可以自由访问； * 读写文件、跑命令、调用工具，它都能自主操作； * 你设定的规则，比如 AGENTS.md 里的要求，它会严格遵守。 感兴趣的话，可以直接参阅官方文档，这里不展开技术细节。我们关注的核心是：为什么有了这张工作台，AI 就能从“空谈”变成“实干”？ 听起来好像也没什么特别？不就是个 AI 版的 IDE 吗？ 不对。 核心差异在于工作模式：聊天框里的 AI 是被动的，你问一句它接一句；而 OpenCode 中的 AI 是主动的——你给它一个目标，它会自己规划步骤、动手执行、检验成果，并最终向你汇报。如果在过程中偏离方向或出错，它会自我反省、自行修正。 这正是智能体（Agent）的完整执行闭环：目标、计划、行动、观察、调整、验证。 在聊天的对话框里，根本没有这个闭环。你推一步，它走一步；你停下来，它也原地踏步。 这不只是“更强的 AI”，而是一种截然不同的工作方式。就像同一个人，在路边和你聊天是一种状态，坐在工位上认真工作是另一种状态。环境变了，他的行为模式自然就变了。 --- ## 三、跟着跑一遍：让搭档帮你整理项目文档 理论说再多，都不如动手实践一次。 我们用一个人人都能理解的场景来演示：让 AI 帮你整理一个项目的 README 文档。 别小看这个任务，它包含了读取文件、理解项目结构、组织语言、输出成果——是一个完整的闭环流程。 ### 第一步：告诉搭档你要做什么 打开 OpenCode，选定你的项目目录，然后发出指令： “帮我完善一下这个项目的 README。” 就这么一句话。 注意，你不需要事先详细介绍项目背景，也不需要把文件内容贴给它。 为什么？因为它自己就能浏览工作区里的所有文件。这，就是它和聊天框模式最根本的差别。 ### 第二步：看搭档如何独立工作 指令发出后，你只需静静观察——它会自动开始工作：先扫描项目里的文件，理解项目性质和现状；然后阅读已有的 README，评估它写了什么、缺了什么；接着，基于项目结构，重新组织内容；最后，它直接修改 README 文件，并生成变更记录，说明改了什么、为什么这么改。 整个过程，你无需插一句话。 它自己找资料、自己做判断、自己动手执行。 你只需在最后做一件事：检查成果，告诉它哪里需要调整。 ### 第三步：你验收，它优化 如果对某一部分不满意，直接说： “这部分顺序不对，把安装步骤放在示例前面。” 它马上就改。 改完再给你看，你再验收。 经过几轮迭代，直到结果完全符合你的预期。 发现没有？这才是真正“搭档”的感觉——不是你问一句、它答一句，而是你们两个共同把一件事情做成。 --- ## 四、这个搭档为什么能干活？ 读到这里，你可能会想：不就是 AI 能读取文件吗？有什么了不起的？ 实际上，远不止“能读取文件”那么简单。能看资料只是第一步，真正让它从“聊天者”转变为“行动者”，是三个关键因素同时到位：**能看见资料、能使用工具、通晓规则**。 只要缺了任何一个，它都无法胜任工作。 ### 先说能看见资料 前面提到一个比喻：AI 每次只能“看一张纸”。纸上有什么，直接决定了它能做到什么程度。 在聊天框里，AI 手里那张纸上只有你刚敲进去的几句话——除非你说，否则它不知道；除非你贴资料，否则它没资料可用。 但在 OpenCode 里，AI 手里的“纸”充满了全局信息——整个项目的目录结构、README、代码文件，甚至是工作区中设定的 AGENTS.md，它都能即时获取和阅读，还能记住之前的对话上下文。这完全是两个量级的信息基础。 所以，你不需要反复解释“这个项目是做什么的”，不需要把资料一份份贴给它，更不需要每次从头介绍背景。它自己会查、会看、会用。 这件事说起来好像不值一提，但实际使用时效果完全不同。就像你跟一个对项目一无所知的人沟通，和跟一个已经深度参与半年的同事协作——效率能一样吗？ ### 再说能使用工具 光有资料也不够。你让它整理文档，它总不能在对话框里“口述”一遍修改方案吧？最后还是得你自己复制粘贴、自己找文件、自己改。 这叫安排工作吗？这不过是“你指挥，它出主意，苦力活还是你来干”。 在 OpenCode 里情况完全不同。它有“手”有“脚”。读写文件是最基本的操作，修改代码、运行命令也都是其基本能力。你让它整理 README，它直接动手把文件改好，你只需打开查看即可，无需人工搬运。 这还只是最基础的“工具”（Tool）。 更上一层是“技能”（Skill）。比如，它可以根据你的风格来整理文档、能遵守团队的代码规范、能进行代码审查。这些能力并非天生具备，而是有人将经验打包封装，变成了 AI 可以调用的专业模块。 如果再连接到 MCP（Model Context Protocol），它的能力就更强了。它可以直接接入你的飞书文档、数据库，甚至公司内部系统。你让它“把整理好的文档发送到飞书群”，它瞬间就能完成，无需你下载再上传。 可以看到，AI 从“会说”到“会干”，中间差距的并不是更聪明的大脑，而是能够触及真实世界的“手”和“脚”。 ### 最后是通晓规则 有资料、有工具，就一定能做好工作吗？ 不一定。这种现象你一定遇到过：明明交代清楚了任务，但 AI 给出的结果就是“不对味”——格式不对、风格不对、重点错位。 为什么？因为它不理解你心里的规矩。你说“帮我整理一下文档”，你心里想的“整理”是“按照团队模板，分为四个部分，语言简洁明了”；但 AI 理解的“整理”，可能仅仅是“把内容重新排序，再润色一下”。 认知的偏差就在这里。 那么，规矩如何建立呢？ 小的规矩，可以写在你每次的指令里。 比如，“按四个大部分来写，语言要简洁”。这是为单项任务定立的契约，只要说清楚，AI 就会照做。 大的规矩，则写入 AGENTS.md 文件中。 比如，这个项目使用什么架构、代码风格如何、提交信息怎么写、文档模板的格式是什么。这些长期有效的规则，只需设置一次，AI 在每次作业时都会遵守。 小契约 + 大契约，共同构成了 AI 行动的“边界”。 边界越清晰，它的产出就越可靠。边界越模糊，就越容易“自由发挥”——而那些发挥的结果，很可能不是你想要的模样。 这也是为什么前文提到：别再迷恋“提示词模板”了。模板解决不了根本问题。问题的本质是：你有没有把任务的边界、成果的格式、验收的标准，清楚无误地告诉 AI。 在 OpenCode 环境中，这个逻辑被进一步放大——不只是一句 Prompt 是契约，整个工作区的规则都构成了契约。 --- ## 五、这个搭档还能干嘛？ 整理 README 只是它能力的一个缩影。 只要你愿意尝试，它能帮你做的事情非常多。随便举几个日常工作中的例子： * 将一堆杂乱无章的笔记扔给它，它会按主题分类归纳，还能生成一个内容索引。 * 把会议录音转好的文字稿交给它，它能帮你提炼成结构清晰的会议纪要，把每个人的待办事项和截止日期都整理得明明白白。 * 修改简历、优化文案、润色邮件等等，更是小事一桩。把你的风格要求和偏好告诉它，它可以帮你反复调整，直到找到满意的版本。 * 甚至，读一篇长文章时不想从头到尾啃，可以把它扔给 AI，让它提炼核心观点，或者针对具体问题在文章中精准搜索信息。 如果你是工程师，它的用武之地就更多了。 接手一个陌生的新项目？让它梳理一下代码结构，给你讲清楚核心流程和关键模块，比自己一头扎进程序中快得多。 编写代码时，向它交代清楚项目的架构约定和风格规范，它生成的代码至少在格式和结构上不会跑偏。 遇到 bug 了？把报错信息和相关代码给它，让它帮忙定位问题、分析原因，甚至提供修复思路。虽然不能保证每次都对，但至少能提供一个方向，比自己一个人苦思冥想有效率。 至于编写单元测试、撰写接口文档、执行代码审查……这些重复性劳动，都可以先交给它打个底稿，你再做最后的审核。 当然，这并不是说 AI 无所不能。 它真正擅长的，是那些**目标明确、规则清晰、结果可验证**的任务。 越是模糊不清、需要做决策的、没有标准答案的工作，它就越力不从心（至少在当前阶段如此）。 但话说回来，我们日常工作中，有多少是真正需要“拍板定方向”的终极决策呢？ 绝大多数时候，我们缺少的不是创意，而是一个能帮我们把那些繁琐但关键的事情，踏实做完的人。 这，就是“搭档”的价值所在。 --- ## 六、普通人怎么上手，工程师能玩多深 不同背景的人，使用这个“搭档”的方式也全然不同。 如果你只是想用它来节省时间，提升效率，不需要掌握复杂的技术，记住三件事就够了。 **第一件事：别把所有事情都放在一个对话框里谈。** 写文章就在文章专属的工作区，做项目就在项目的工作区，个人琐事单独开一个专用空间。不同的事情分开放，AI 才不会混淆。 **第二件事：把要求说清楚。** 不要只说“帮我整理一下”。“整理成什么样子？给谁看？需要多长篇幅？按照什么结构？”你说得越明白，它做得越到位。你的指令模棱两可，它就只能靠猜来完成任务。 **第三件事：学会验收和提出修改意见。** 第一版结果不满意太正常了。千万别用了一次觉得不行就放弃。指出哪里不对、希望怎么改，它会立刻调整。经过几次迭代，最终会达到你想要的效果。 总而言之，这三件事，不需要你会编程，不需要你懂任何技术，任何人都能轻松上手。 如果你是工程师，或者希望玩得更深入，那可以拓展的领域就非常广阔了。 最基础的操作，就是为每个项目编写一份 AGENTS.md 文件，把项目的架构约定、代码风格规范、提交信息规则都写进去。一次性投入，以后 AI 在这个项目中运行都会自觉遵守。 更进一步，你还可以创建自己的“技能”（Skill）。也就是说，把你擅长的流程、你的检查清单、你的专业方法论，封装成一个 AI 能调用的自动化能力。从此，AI 会依照你的方法工作，而不是自行摸索。 再进一步，接入 MCP 的话，它就不再仅仅是你的代码助手——它可以直连你的数据库、调用你的 API、在飞书群发消息、查询 Jira 工单。整个研发流程中的重复性工作，都能交给它处理。 最后，你甚至可以搭建一个由多个 AI 组成的“多 Agent 工作流”。一个负责写代码，一个负责执行审查，一个负责撰写文档。各司其职，你只需最后拍板签字。 从“用它省点时间”到“让它为你组建一个 AI 驱动的虚拟团队”，这中间的空间非常大。你想走多远，完全由你自己决定。 --- ## 写在最后 回到最初的问题：为什么你总觉得和 AI 聊天“差点意思”？ 因为 AI 的价值从来不在沟通本身，而在于做事的过程。 你真正需要的，不是一个更能聊天的 AI。 你真正需要的，是一个能和你一起，把事做成、做好的**搭档**。 未来，真正会使用 AI 的人，未必是“写提示词最牛”的人，也未必是最懂硬核技术的极客。而是那些最懂得如何为 AI **找准位置、设定规则、分配任务**的人。 这就好比你找搭档，最重要的不是找最厉害的，而是找最合适、能和自己一起把事情办成的。 下一篇，我们来探讨一个更深入的问题：这个搭档干完活后，它能记住上一次的结论吗？难道每次都要重新开始？这就是关于“分层记忆”所要解决的问题。