AI

🤖 【具身智能日报】2026-09-10 17:10 📡 新华网：走向实用，具身智能机器人还要闯几关？ （摘要）2026世界机器人大会集中展出373家企业3000余款前沿产品，首发新品311件。宇树科技、智元、傅利叶等企业展示人形机器人快递分拣、煮面打包等作业能力。展台上机器人从"能跑会跳"迈向真实场景作业演示。产业正进入规模化应用关键期。 💡 亮点：由中国兵器工业集团牵头的"中央企业机器人创新联合体"集结48家央企，展示从基础材料到数据底座、智能模型的全链条自主攻关成果。 📡 2026杭州国际人工智能应用与机器人创新博览会 （摘要）博览会今日（9月10日）至12日在杭州国际博览中心举行。杭州已集聚机器人整机及零部件相关企业超200家，2025年具身智能机器人产业集群规上工业总产值达1068.3亿元，四足机器人市场份额超80%，人形机器人市场份额超50%。 💡 亮点：全国首部具身智能机器人领域地方性法规《杭州市促进具身智能机器人产业发展条例》已于2025年12月获批施行。 📡 新华网：两部门联合开展人形机器人与具身智能实景实训专项行动 （摘要）工业和信息化部、国务院国资委印发通知，明确到2026年底人形机器人等重点产品在代表性场景中率先完成应用验证和常态部署，开启"作业模式"。凝练形成百个以上高价值场景。 💡 亮点：专项行动以"以场练机，实训迭代"为方向，依托实景实训体系为产业化铺路。 今日观察：元年已至，三道坎待跨 2026年被行业公认为"具身智能规模化应用元年"。然而数据揭示现实差距：中国人形机器人累计交付约1.5万台，市场规模20余亿元，而传统工业机器人出口额早已突破百亿元。中关村智友研究院院长王田苗指出，产业跨越规模化临界点仍需迈过三道坎： 其一，大脑不够可靠。 99%的任务成功率看似不低，但意味着机器人走出去100次有1次"掉链子"。具身大模型技术路线尚未收敛，暂不具备量产工程化前提。宇树科技创始人王兴兴认为，具身智能的"ChatGPT时刻"——在80%陌生场景中通过自然指令完成80%任务——快则2-3年，慢则5-10年。 其二，身体硬件拖后腿。 在设备自重受限前提下，机器人需同时满足负重、高低温适配、持续工作时长等客户底线性能要求，硬件性能指标难以达标仍是场景落地的核心障碍。 其三，大规模生产不易。 缺乏统一工艺和检测标准，企业难以单纯依靠增加人力提升制造效率，行业尚缺体系保证产品一致性。 商业化路线图初步浮现： 优先切入巡检安防、应急消防等高刚需场景完成商业验证；再拓展至通用工业与商业服务；最后进军家庭市场。京东推出三年产业计划，目标扶持100个具身智能品牌各实现十亿元营收，并启动大规模数据采集项目为技术落地构建数据底座。 来源：新华网、杭州市政府官网 | 时间：2026-09-10

WorkBuddy 一周实测：个人工作和小团队，到底能用它做什么？ 实测环境：macOS，WorkBuddy 5.2.7，连续使用一周。 信息复核：2026 年 9 月 9 日。官方更新日志显示，桌面端最新版本为 5.5.3。本文中的耗时、资源占用和识别效果，都是我在 5.2.7 上的单次或少量测试记录，不代表官方承诺。版本与价格以 WorkBuddy 更新日志 和 腾讯云计费说明 为准。 我把 WorkBuddy 装到 Mac 上时，没打算拿它“颠覆工作”。我只是受够了来回搬东西：飞书里翻聊天记录，复制到文档，再把表格数据塞进 PPT，还要单独写一封邮件。WorkBuddy 和普通聊天工具最不一样的地方，不是它更会说，而是它能在我授权后读文件、跑工具、生成文档，再把结果交到下一个应用里。官方把它叫“全场景职场 AI 智能体桌面工作台”，我用了一周后的说法更土：它像一个坐在我电脑里的执行型实习生。任务说清楚，它能省掉不少机械操作；任务说含糊，它也会一本正经地跑偏。【关键词：#WorkBuddy #AI智能体 #个人效率 #小团队协作】 我最先跑通的是周报。 周一早上，我把一周的会议纪要、零散待办和几份项目文档放进同一个工作区，要求它按“已完成、风险、下周计划”整理，不准碰两个敏感项目。那次三分钟出了初稿，我又花五分钟改人名和优先级。省下来的不是写字时间，而是从十几个窗口里捞信息的烦躁。可我第一次下指令时只写了“帮我整理本周工作”，它把私人备忘也扫进去了。这个翻车让我定下一条规矩：先圈目录，再说任务；先写禁区，再点运行。后来我把个人任务收成五类，效果稳定了不少： 长文档压缩。 我拿一份 80 页产品白皮书，让它输出 300 字摘要、关键参数表和三条待确认问题。普通文本版约 90 秒就完成，够我拿去开内部会。换成扫描 PDF 后，表格和页脚开始串行。原稿里我写过“识别率掉到 60%”，这个数字只来自那一份样本，不该当成产品能力。我的处理办法很简单：先做 OCR，再让它摘要；关键参数回到原页核一遍。 PPT 起稿。 我先给客户类型、演示时长、听众最关心的问题，再让它出 12 页结构和视觉草稿。那次从空白页到可讨论版本，比我自己从零搭快很多。没有客户画像时，它默认按中小企业写，整套方案方向都偏了。AI 能补页面，补不了我没说出口的业务背景。 批量整理邮件。 我让它给 200 封未读邮件做“客户、同事、订阅、待删除”分类，并把涉及付款、合同、交付日期的邮件单独列出。五分钟左右分完，少数客户群发信被扔进订阅类。我没有让它自动删除，也没有让它直接回信。发邮件、删邮件这类动作，我都保留临门一脚的人工确认。 代码和表格杂活。 一份约 200 行的 Python 脚本，它两分钟找出两个真问题，也塞给我五条偏风格的建议。我只修能复现的错误。把客户资料从一个表搬到另一个表时，它能做字段映射，但“公司简称”和“客户名称”猜错过一次。批量写入前先拿五行试跑，比事后清两百行脏数据轻松得多。 公众号初稿。 我给主题、读者、真实案例和禁用词，让它先搭草稿。十分钟能有一版，但“过渡词加升华收尾”的味道还是会冒出来。现在我只让它整理材料和找结构，真正的判断、情绪和具体经历自己写。能交付文件，不等于能替我表达。 小团队场景比个人场景更考验边界。 我和两个同事把它当“团队实习生”用了三天。最顺的一次，是把三份 Word 会议纪要拆成待办，再写进协作表格。我们事先约定四个字段：负责人、截止日期、动作、优先级；没有负责人就标“待认领”，不让它猜。十二分钟后表格能直接发群。最糟的一次，是让它“自行选择合适工具”，它连续调了一串 Skill，任务做完了，积分也掉得肉疼。官方技能文档建议只启用当前任务需要的 Skill，我很认同。Skill 本质上是脚本和工作流，会在授权范围内读写文件、调用第三方服务；部分 Skill 还会把输入发给第三方。别把“装得多”当成“能力强”，闲置 Skill 该关就关。连接器也一样。官方连接器文档列出了邮箱、腾讯文档、腾讯会议、TAPD 等接入场景，飞书、钉钉等也有单独的助理接入指引，但每个连接器能读什么、能写什么，要看实际授权。我的做法是把团队任务拆成下面这条链： ...

Trae、WorkBuddy 和 Agent:搞懂这三者,非程序员也能玩转 AI 我电脑里同时装着 Trae 和 WorkBuddy。一个长得像 VS Code,打开就是一整屏代码;一个长得像微信,打开就是个对话框。同一个"AI 助手"的名号,干的活差着十万八千里。关键词:#workbuddy #trae #agent 而 Agent 是另一回事儿。它不是一个产品,是个概念。你可以把它想成"汽车"这个品类——Trae 和 WorkBuddy 都是车,但一辆是越野车,一辆是家用 SUV。 先说最重要的一句话:Agent 是一个概念,Trae 和 WorkBuddy 是两个产品。 我用个不太恰当但好懂的比喻:Agent 相当于"汽车"这个品类,而 Trae 是"越野车"、WorkBuddy 是"家用 SUV"。都是车,但干不同的活儿。 那 Agent 到底是什么? Agent 直译过来是"智能体"。它和咱们平时聊的 ChatGPT、豆包、文心一言这类聊天机器人(Chatbot)不一样。 聊天机器人,你问一句它答一句,本质是"问答"。 而 Agent 是"干活"。你说"帮我订明天北京到上海的高铁,上午十点左右,二等座",它会自己拆任务、自己查车次、自己下单、自己填地址。整个过程你不用一步一步指挥。 一个能真正干活的 Agent,需要三样东西: 大脑:大模型(比如 DeepSeek、豆包、混元),负责理解和决策; 记忆:能记住你之前说过啥、做过啥,不会聊两句就忘; 工具:能调浏览器、调表格、调你电脑上的软件,这是干活的"手脚"。 缺任何一样,它就只能"陪聊",干不了正事。 那 Trae 和 WorkBuddy 又是啥? 懂了 Agent 是"汽车品类"之后,Trae 和 WorkBuddy 就好理解了——它们都是 Agent 的具体实现,但定位完全不同。 Trae 是字节跳动在 2025 年初推出的 AI 原生 IDE。所谓 IDE,就是程序员写代码用的"大本营"。它底层基于 VS Code,打开就能用,内置了 Claude、GPT、豆包等多个大模型,主打"中文体验最好、对开发者最友好"。 ...

我现在的「AI 工作台」：codex + Cindy + openclaw + kilo 最近被朋友反复问同一个问题：你这四个 AI 工具到底是怎么分工的？codex、Cindy、openclaw、kilo，光听名字确实都像"AI 助手"，凭什么不全用同一个？我自己也花了不少时间才把这套组合理顺。这篇文章只讲一件小事：在我手里，这四个工具分别占住了不同的工作位，缺谁我都会别扭。 我写代码的"主驾"是 codex。这里的"主驾"很具体：跨多文件、需要持续迭代、上下文一旦断了就接不回去的那一类项目。我把 codex 一直挂着，它不像一个"一次性问答工具"，更像一个能跟项目同呼吸的搭档——它看过的文件、改过的 diff、跑过的命令，会变成下一轮决策的依据。规矩只有三条：把 codex 当"项目主驾"而不是"问答工具"，给它持续的事实而不是一次性的提示；用里程碑切会话，长会话里它会慢慢漂移，里程碑一过就 reset，让它从干净的事实开始；看 diff 而不是看回答，它给的"通过"只是参考，最终那一下"合不合"必须人来定。 Cindy 站的是另一个位。她不只是"另一个 AI"，更像是四个工具之间的调度位。一半的时间我在做办公——写周报、整会议纪要、做汇报材料、起草对外的邮件——这摊事她是我的主力。但更让我离不开的，是她无缝衔接 Pi、codex、Claude的能力。我经常是这样跑工作流的：先用 Cindy 把需求讲清楚、列好要点；遇到需要长链路推理的，把上下文接力给 Pi；进入真正的工程实施阶段，再接力给 codex；想换一个视角听反馈或做对照，再回到 Cindy 或转 Claude 跑一遍。整条链路的纪律是：办公是基本盘，周报、会议纪要、对外邮件这一摊她是主力；调度是放大器，她和 Pi / codex / Claude 接力，让上下文在工具之间流动，我不用复制粘贴、不用重新解释背景；接力链路过长是陷阱，两到三跳最舒服，再多，信息的损耗就会显出来，必须切回 Cindy 重整。 再往下是 openclaw。它在我这里干的是"不入主线"的杂活。什么叫杂活？一次性脚本、临时数据清洗、批量改个文件名、跑个不痛不痒的小爬虫、把一段音频转成文字、给一张图换个尺寸、临时翻译一段不要求精度的文字——这些事不会上 GitHub、不会进生产、也不会被任何会议引用，但不做又会卡住主线进度。openclaw 就是这种"轻骑兵"，打开就能用、用完就走。规矩是：任务的边界是"不入主线"，都是它的活；价值在"快"和"不打断心流"，不在"严谨"和"可追溯"，别把它的输出直接当交付物；用完就走，它不占心智位，也不抢主线位。 kilo 的角色最简单：在 VSCode 里用的那个。很多写代码的时间是碎片化的——我在 IDE 里写到一个函数、卡住、想问一下；改到一半想确认某个 API 的用法；review 一段刚写的逻辑想找人挑刺。这时候我不想切窗口、不想开新 tab、不想跳出当前文件，kilo 就在侧栏里直接接住。规矩也很简单：位置在 VSCode 侧栏，随手就能用，不切窗口；任务是碎片化的"边写边问"，卡住的函数、API 用法、刚写完的逻辑想挑刺，kilo 就在手边；不要在 kilo 里跑长链路任务，它的定位是"边写边问"，不是"项目级搭档"，那个位是 codex 的。

纳瓦尔宝典：AI 时代，借 AI 之力撬动个人能力与财富的复利 原文：The Almanack of Naval Ravikant: A Guide to Wealth and Happiness 作者：Naval Ravikant（硅谷天使投资人，AngelList 创始人） 编撰：Eric Jorgenson 来源：Magrathea Publishing，发布于 2020 年 09 月 中文版：中信出版社，2022 年 05 月，赵灿 译 最近在重读《纳瓦尔宝典》，一句话反复击中我——「财富 ≠ 劳动」。但这次重读的体感，和前几次很不一样：以前我把这句话当成一种「价值观提醒」，告诉自己别太累；现在 AI 全面进入工作流之后，我才发现纳瓦尔讲的其实是一种「杠杆公式」，而 AI，是 21 世纪最便宜、最高倍的那一种杠杆。这篇文章，我想把纳瓦尔关于「财富 / 杠杆 / 判断力」的核心观点重新梳理一遍，并把它们放进 AI 时代这个新变量里，回答一个更现实的问题——作为没有任何特殊资源、也没有团队背书的普通人，我们怎么借 AI 之力，以最小付出去撬动个人能力与财富的双重复利？ 一、AI 改变的，不是「杠杆本身」，而是「杠杆的门槛」。 纳瓦尔反复讲一句话：「我们这代人最被高估的东西，就是劳动本身。」劳动只能线性放大你的时间，而 财富是指数级增长的——他给出了一个非常冷静的区分：劳动是用时间换钱，金钱只是财富的流通形式，真正的 财富，是你睡觉时依然在为你工作的东西。在他那本《宝典》里，他把放大劳动的工具分成「劳动力 / 资本 / 代码 / 媒体」四类杠杆，并指出：前两类需要别人「许可」，后两类才是普通人的金矿。但放到 2024 年之后，这件事又变了一次：AI 出现之后，「代码」和「媒体」这两条无许可杠杆的门槛，被一次性打到了地板。以前你想写一个工具，需要学一门语言、搭环境、踩无数的坑；现在你只需要把需求说清楚，AI 就能给你一个能跑的版本。以前你想持续生产内容，需要文笔、时间、选题、拍摄；现在 AI 可以帮你写初稿、配图、剪辑、校对。门槛下降，杠杆率反而在上升——这才是 AI 真正改变的事。 二、AI 时代，普通人能用的「五种新杠杆」。 纳瓦尔讲的是四类「杠杆」，结合我自己的 AI 使用经验，我把它们重新整理为「五种更接地气的杠杆」，并按「普通人友好度」排序： AI 杠杆的能力外骨骼——你不是变强了，你是装上了外骨骼。写作、设计、分析、翻译、代码、PPT，这些过去需要多年训练的能力，现在 AI 都能给你一个 70 分的起点。你不是不能做，只是过去做一次的成本太高。 AI 杠杆的内容生产——一个人 = 一家内容公司。选题、写作、配图、排版、分发，过去需要一个小团队；现在一个人 + AI 工作流就能稳定产出。这是「媒体杠杆」的 AI 加持版。 AI 杠杆的产品制造——一个人 = 一家小产品公司。无代码 + AI 辅助开发 + AI 辅助运营，让「做一个自己的小产品」从过去的半年变成现在的两周。这是「代码杠杆」的 AI 平民版。 AI 杠杆的信息差消除——以前你做判断，靠经验和信息差；现在 AI 可以几秒钟内帮你拉齐行业资料、对比方案、列出反例。判断力没变，但判断的依据变厚了。 AI 杠杆的人际连接——AI 帮你整理客户、读邮件、写回复、做会议纪要；你不再被事务性工作淹没，可以把时间花在「真正需要人的地方」——关系、信任、长期价值。 纳瓦尔反复强调：杠杆只是放大器，方向错了，杠杆越大，摔得越狠。在 AI 时代，这句话变成了一个更具体的提醒：如果你用 AI 加速了一件错误的事，你只会更快地失败。 ...

20260904｜我如何把 Pi Agent 接进 Office/WPS 办公流程：从安装到 Excel 长任务 我最初接触 Pi Agent 时，也只是把它当成一个写代码的终端工具。真正让我觉得它适合办公，是我把一项复杂任务拆开之后发现：办公里最耗时间的部分，往往不是写一段话，而是把邮件、会议记录、网页、表格和历史文件里的信息拼起来，再按一套不够明确的规则反复处理，最后还要证明结果没有改错。 关键词：#Office #WPS #Pi 对经常使用 Office 或 WPS 的人，我更愿意把 Pi 理解成一个坐在旁边的办公助理：它不替我换掉 Word、Excel、PowerPoint 或 WPS，而是帮我在多个文件之间找信息、整理内容、生成草稿、执行低风险的重复动作。它可以在本地的“办公工作区”——也就是我专门放这项工作的文件夹——里读取资料、调用工具、保存一次连续的工作记录，并把中间结果留下来。但它不是“按一下就全自动”的魔法，也不是替我做业务判断的数字员工。 本文先把安装对象和桌面适配讲清楚，再用 Excel 月报这个长任务说明我如何让它参与办公，以及我为什么坚持把验证和最终提交留给自己。先把名字理顺：大家口中的“pi-agent”，对普通使用者来说通常指的是会安装出 pi 命令的 @earendil-works/pi-coding-agent；@earendil-works/pi-agent-core 是底层运行时库，不是新手第一步要装的客户端。下面的命令和版本判断以我在 2026 年 9 月 4 日查到的官方快速开始文档、官方仓库和相关 package 资料为准。 下面看到的黑色窗口命令，主要只在安装和整理文件时使用；装好以后，我仍然可以继续用熟悉的 Excel、Word、PPT 或 WPS 图形界面办公。对不熟悉命令行的朋友，我建议把它理解成“给办公助理下达准备工作指令”，先照着复制执行即可。 先准备运行环境：当前官方仓库的 package.json声明 Node.js >=22.19.0。Node.js 是 Pi 运行所依赖的基础环境，我会先用 node --version 检查版本；低于这个版本就先升级 Node.js。旧文章里如果还写着 @mariozechner/pi-coding-agent，以当前官方文档使用的 @earendil-works/pi-coding-agent 为准。然后安装并验证： npm install -g --ignore-scripts @earendil-works/pi-coding-agent pi --version macOS 或 Linux 也可以使用官方安装脚本 curl -fsSL https://pi.dev/install.sh | sh；Windows 则建议先安装 Git for Windows，因为 Pi 默认通过 Git Bash 执行 Bash 命令，官方也支持在设置里指定 shellPath。安装成功后，进入我准备给它工作的目录再启动： ...

Go 语言架构｜Google ADK Go 深入拆解：把 Agent 写进 Go 的工程流水线 原文：Agent Development Kit (ADK) for Go 作者：Google ADK Go 团队（Google 官方开源项目维护者） 来源：GitHub，发布于 2025 年 11 月 06 日 我最近重新看了一遍 Google 的 ADK Go。它吸引我的地方，并不是“Go 也有一个 AI 框架”，而是它试图回答一个更实际的问题：一个会调用模型、工具和其他 Agent 的系统，能不能像普通 Go 服务一样被编译、被测试、被部署和被审查？ 这篇文章不打算把官方 API 逐个翻译一遍。我会沿着自己的理解，把 Agent、工具、工作流、协议、状态和上下文串起来，也会特别标出 v1 与 v2 的边界。文中的蓝色表示工具或事实，绿色表示我的实践判断，红色表示容易踩的坑，黄色底色表示可以直接拿去用的做法。 先看 ADK Go 为什么值得单独关注。 我认为，ADK Go 的重点不是证明“Go 比 Python 快”，而是让 Agent 代码进入成熟的软件工程流程。Go 项目已有的编译器、静态检查、单元测试、依赖管理、CI 和容器化能力，都可以继续使用。 ...

20260903 OpenCode 和 KiloCode 的主要区别是什么？为什么我会选择 KiloCode？ 最近 OpenCode 和 KiloCode 经常被放在一起讨论：一个让我在终端里专注完成任务，一个把多个 Agent、隔离工作区和代码审查组织进 IDE。很多朋友真正想问的其实不是“谁更强”，而是“我现在的工作方式，应该把哪一个放在手边”。这篇文章记录我最近一次切换工具的原因，也把我认为最影响选择的差异讲清楚。蓝色高亮表示工具事实，绿色高亮表示我的判断，红色高亮表示容易踩的坑，黄色高亮表示可以直接尝试的做法。文中的产品信息按 2026 年 9 月 3 日查阅到的官方文档整理，后续可能随版本变化。 先说我的结论：如果你主要在终端里工作，喜欢自己控制会话、目录和模型，OpenCode 依然是一把很顺手的工具；如果你经常同时推进多个任务，希望在 VS Code 或 JetBrains 里集中看状态、diff 和工作区，KiloCode 更贴合我的习惯。更准确地说，Kilo CLI 是 OpenCode 的 fork；Kilo 的 IDE 插件和 Agent Manager 则是 Kilo 另行组织的产品层。所以它们不是两个完全无关的竞品，也不是同一个产品换了两个皮肤。 我为什么又换了一次？上一篇文章里，我写过自己怎样把 OpenCode 接进日常开发，那些经验现在仍然有效：终端里可以跑命令，配合 LSP（语言服务协议）理解代码，也可以通过 MCP（模型上下文协议）接入外部工具，项目规则则写进 AGENTS.md。后来我的任务从“一个人在终端里重构 Go 服务”，变成了同时推进重构、补测试、写文档、审 PR 和修 bug，还要在 VS Code 与 JetBrains 之间来回切换。OpenCode 的多 session 能力并不弱，只是我需要自己安排目录、创建 git worktree（并行分支工作区），再盯住每个会话的进度。KiloCode 的 Agent Manager 把这部分协调工作做成了看板：每个 Agent 可以在独立 worktree 里运行，我只需要负责拆任务和合并结果。 ...

OpenCode，别急着上手，分享我的自用经验 最近一段时间 OpenCode 的话题度很高，公众号和推上每隔几天就有人晒"一天配置、终身起飞"。我也凑过几次热闹，但说实话，真正把它当成日常开发工具并接入 AI 用，是在吃了几次亏、调过几次规则之后才稳定下来的。这一篇不是官方文档的搬运，也不是"hello world 教程"，我会先讲我为什么把 OpenCode 作为日常开发工具并接入 AI 用，列 8 条最容易踩的注意事项——尤其是"装上第一天别急着写规则"。如果你正在评估 OpenCode、或者已经装上却不知道从哪一步开始，这篇可能比"快速上手"那一份更值得花十分钟读完。蓝色高亮表示工具或事实，绿色高亮表示我的使用判断，红色高亮表示容易踩的坑，黄色高亮表示可以直接抄走的最小可用集。、 先把"为什么用"想清楚：换模型不被绑架、过程可观察、本地运行——这三条都满足了，再谈下一步。 从最小可用集开始：一份简短 AGENTS.md + 一个稳定 Provider + 一个默认 build 角色 + 启用的 LSP。够用就好。 复杂任务先 plan 再 build：跨文件的改动，先看 diff 再下手，能避免一整轮返工。 规则要可验证、规则要文件化：机器能判的才叫规则，读不懂的只是愿望。 审查用只读 agent：把"看"和"改"分开，是让 AI 报告客观的前提。 接入 MCP 时按"只读 → 受限可写 → 状态变更"分步放权：每一步都先想清楚"最危险的事是什么"。 不要让关键检查静默失败：可见、可追溯、有人负责，三条缺一不可。 把 AI 当草稿作者，把自己当责任编辑：最终交付的责任，不能下放给工具。 一、把 OpenCode 放进工作流之前，我给自己提过三个问题：它能不能让我换模型不被绑架？它能不能把每一步操作摊在我眼前？它能不能在我自己的机器上跑，而不是把代码交给一个远端托管？ OpenCode 在这三个问题上都给出了让我愿意留下来的答案，这也是我后来把它接入 AI 用作日常开发工具的真正原因。我把这三个答案按顺序写下来，因为它们不只是在"功能上"成立，更是OpenCode 与同类工具最明显的差异点： 开源、可审计、不绑定单一供应商：OpenCode 的客户端代码是公开的，关键行为可以在源码里核对；Provider（也就是模型供应商）走的是开放协议，我可以在同一个配置里同时挂上 OpenAI、Anthropic、本地 Ollama、自建代理，换模型不需要重写工作流，更不需要换一份订阅。对我来说这意味着两件事：第一，今天贵/限流的模型，明天可以被另一个模型接住；第二，今天数据合规的顾虑，明天可以通过本地模型或者自建网关绕过。这条不是装饰，它直接决定了我愿不愿意把生产代码交给它。 把"工具调用 + 文件编辑 + 命令执行"收进一个 TUI：比起网页聊天窗口，OpenCode 的好处是上下文连续。一次会话里，它可以直接读写我的文件、跑我的命令、调用我的 LSP，并把每一步的结果作为下一步输入。传统聊天窗口要靠我在不同窗口之间复制粘贴，OpenCode 把这些步骤变成了同一个会话里的多轮工具调用。对我而言这比"模型写得多聪明"更重要：我能在同一个界面里看见它读了什么、改了什么、跑过哪些命令、回滚时还能回到哪一步。信任不是靠宣传词建立的，是靠"可观察"建立的。 配置即文档，规则可以在 review 里被讨论：OpenCode 的绝大部分约定都放在纯文本文件里：项目根的 AGENTS.md 写规则，commands/*.md 写命令模板，agents/*.md 写角色，skills/*.md 写沉淀下来的做事方法。最常见的错误是把 AGENTS.md 当成无所不包的"价值观大全"，其实它的价值恰恰相反——把"我想要的工作方式"显式写下来，让工具按文件读，而不是每次新会话都让我重新解释一遍。规则在哪一步生效、谁负责什么，可以被同事直接读到，也可以在 review 里被讨论。这就是我把 OpenCode 当成"开发工具并接入 AI 用"的核心原因——AI 第一次成为工作流的一部分，而不是一个聊天侧栏。 二、装上 OpenCode 之后，先别急着让它"做项目"。我会先定一个最小可用集，把"模型 + 规则 + 角色 + 编辑器反馈"四件事按顺序配齐，再开始干正事。顺序不能乱，因为规则没写好之前，模型越强越容易跑偏。下面这 8 条技巧，前 4 条是"装好就能用"的最小集，后 4 条是"日常真正省时间"的核心姿势，全部按顺序展开，每一条都尽量具体到"打开哪个文件、敲哪条命令、看哪个输出"。我会刻意把"我踩过的坑"嵌在技巧后面写，而不是单独列一节，这样读起来不会割裂。 ...

工信部、国资委联合启动人形机器人实景实训专项行动，明确2026年底开启「作业模式」；行业半年融资935亿、8家企业估值破200亿，但修路者已开始倒下。