工具

AGENTS.md 写对一次 ≈ 一次模型升级：60k 仓库总结的 5 段结构、6 个模式、5 类反模式 一句话定位：README 写给人看，AGENTS.md 写给 AI Agent 看。 AGENTS.md 不是文档，是 Prompt。你不是在写文档，是在做上下文工程。 —— Augment Code 工程博客 【关键词：#AGENTSmd #AI编程 #上下文工程】 01｜和模型强弱到底是什么关系：三种打架的结论 "我用了 Claude Opus 还需要写 AGENTS.md 吗？"——最近这一两个月，被问到这一句的次数，比过去一年加起来还多。 网上数据打架，我整理出三种主流结论。 我的判断一：好的 AGENTS.md ≈ 一次模型升级。Vercel 的 Next.js Evals 这套基准是所有数据里跑得最干净的——没有 AGENTS.md 的时候，Claude Sonnet 4.6 通过率只有 67%；加一份好的 AGENTS.md 之后直接到 100%。GPT 5.3 Codex 同样从 86% 拉到 100%。最反直觉的一行：——一份好文档的杠杆，比一次模型升级还大。 判断二：弱模型受益更大，但强模型也吃这套。The Prompt Shelf 综合 60k+ 仓库数据后画了一条更细的线——弱模型缺乏世界知识，必须靠显式上下文才能在同一个代码库上工作；前沿模型能自己推断大部分约定，但对非显而易见的项目约定（部署步骤、内部 API、仓库特有坑）仍然需要 AGENTS.md。边际价值不同，但没有哪个模型可以裸奔。 判断三：差的 AGENTS.md 比没有还糟。Augment Code 的实测 有点打脸：同一份 AGENTS.md，任务 A 提升了 25%，任务 B 反倒掉了 30%。——规则一旦自相矛盾，模型就开始犯傻。 ...

WorkBuddy 专家完全指南：从角色锚定原理，到按目标挑人、正确发任务、避开代价，一篇讲透 封面由 AI 辅助生成；按平台规则发布时保留 AI 生成内容标识。 原文：专家｜WorkBuddy 功能说明 作者：腾讯 WorkBuddy 官方（产品帮助文档） 来源：WorkBuddy 帮助中心，发布日期未查到可靠信息；本文核对于 2026 年 09 月 16 日 我把 WorkBuddy 5.5.2 客户端的专家中心、本机角色卡片、推荐任务和官方帮助文档全部翻了一遍，又把官方"AI 专家团 全场景办公"的设计哲学和自己用通用 LLM 的体感对照过，最终把'为什么 WorkBuddy 要给 AI 指定专家身份 + 怎么挑、怎么用、什么时候别用'这件事拆成一篇讲透。 【关键词：#腾讯WorkBuddy #专家团 #角色锚定 #AI协作】 01｜先把概念掰开：Skill / 专家 / 专家团 的关系 进 WorkBuddy 之前，我建议先把这三个词的关系理清。我自己的理解是：Skill 是一件具体工具；专家是带着方法和工具链的岗位角色；专家团则由多个专家一起做，团长先拆任务、分配工作，最后把成员结果收回来。 任务特征 优先选择 判断例子 缺少一种具体工具能力 Skill 或连接器 读取表格、调用外部服务、生成某种文件 一个岗位可以独立完成 专家 改一篇文案、评审一版 UI、分析一份销售表 两个以上岗位必须接力 专家团 研究→撰写→审稿，或需求→架构→开发→测试 这是看交付链——不是看名字。下面所有判断都从这张表开始。 02｜为什么给 AI 指定身份更靠谱：角色锚定机制 WorkBuddy 给 AI 指定专家身份这件事，不是营销话术，是有底层机制的。我把它翻译成大白话： ...

我用 WorkBuddy 给股票做作业：从看好一只票到心里有底，一份散户能复制的完整 SOP 【关键词：#腾讯 WorkBuddy #股票分析 #散户工具】 原文：[怎么用 workbuddy 分析理财投资的目标公司？完整教程] 作者：猫咪不吃愚（科技从业者 / 程序员 / 运动爱好者 / 业余理财党） 来源：Cindy 会话实录，2026 年 9 月 买股票踩过的最大坑——复盘才发现：连这家公司是干什么的、卖什么产品、赚不赚钱、跟同行比怎么样，全都没搞清楚。那次之后我给自己立了个规矩——任何一只股票在买入之前，必须先做一份"作业 PPT"，看不懂的票不下手。 这篇文章把我用本地版 WorkBuddy（v5.5.2，2026-09-08 发布）给目标公司做作业的完整流程全公开。从"看好一只票"的念头，到"心里有底敢下单"的 PPT，每一步给你拆开讲，你照着做就能给任何一家公司做出一份 18 页的深度调研——总耗时 2 小时出头，比你刷一天雪球帖子有用得多。 01｜先讲结论：WorkBuddy 给股票做作业 PPT 真的有用吗？ 我的回答：有用，但有一个前提——你自己得先有"想搞清楚的问题"。 AI 不是股神，它不能告诉你"这只票会涨还是会跌"，但它能帮你把一家公司从里到外梳理清楚： 这家公司到底是干什么的？卖什么产品？赚谁的钱？ 最近几年赚不赚钱？收入是在涨还是在跌？ 行业里排第几？跟同行比是强还是弱？ 老板和团队靠不靠谱？有没有什么负面新闻？ 现在买入贵不贵？最近为什么涨 / 跌？ 最坏的情况会怎样？万一亏了能承受多少？ WorkBuddy 在这里最合适的角色不是"算命先生"，而是"陪你看资料的助手"——你说要看哪家公司，它帮你把财报、新闻、雪球帖子、年报全整理一遍，最后出一份你看得懂的报告。 我这次跑的完整流程是：选定公司 → 收集资料 → 一句话指令 → AI 出大纲 → 选模板 → 生成 .pptx → 迭代优化 → 自己精修 → 决定是否买入。下面一步步拆给你看。 ...

腾讯 WorkBuddy 我用了一周，从跑数据到写广告：终于搞懂它到底牛在哪、哪些坑别踩 【关键词：#腾讯 WorkBuddy #AI 办公自动化 #专家与连接器】 最近一周我几乎把所有"重复劳动"都丢给了一个叫 WorkBuddy（腾讯出品的桌面 AI 助手）——它是装在 Mac 上的客户端，v5.5.2（2026-09-08 发布），背后挂着腾讯混元 + 一整套"专家/技能/连接器"体系。这篇文章不是软文，是我自己真用了一周之后的复盘：哪些功能是真香、哪些是噱头、数据分析和写广告两个真实任务的完整产出、还有我踩过的坑。你看完整篇文章，至少能省下你"摸索 WorkBuddy 到底能干嘛"的 3 小时。 一、先一句话讲清楚：WorkBuddy 是什么、不是什么 很多人把它当成"国产版 Cursor"或者"另一个 ChatGPT 桌面客户端"，都不太对。我自己的理解是——WorkBuddy 不是聊天工具，它是"AI 员工"：你招进来一群虚拟岗位（专家），给它们配 SOP（技能）和外接系统（连接器），然后让它们 7×24 替你干活。 它做的事可以压缩成一句话：把"AI + 工作流 + 外部数据"打包在一起，让你不用自己造轮子。和 ChatGPT/Claude/Gemini 的纯对话不一样，WorkBuddy 一上来就预设了 12 大领域、100+ 个虚拟专家（产品经理、数据分析师、抖音策略师、HR、法务……），还内置了 50+ 个官方连接器（飞书、企微、腾讯文档、GitHub、自选股、企查查……）。它不是要你"学会 prompt"，而是要你"指挥一群 AI 员工"。 一句话总结：WorkBuddy = 100 个 AI 员工 + 一堆工具 + 自动化调度，本地客户端 + 云端托管，关掉电脑任务也在跑。**** 我一开始也是抱着试试看的心态装的，毕竟腾讯自家出品、又有"AI 全家桶"的背景，但用了一周之后老实说——它不是完美的，有些功能很糙（配图质量、配图审美、长文逻辑偶尔抽风），但它的"自动化 + 真实接外部系统"这个组合拳，确实是当下国产桌面 AI 里最完整的一套。 二、日常办公 8 大功能：这张图我建议你先存下来 我先把 WorkBuddy 能干的活分成 8 大类，这是我自己用了一周摸出来的，不是抄官网： ...

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 的。

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。安装成功后，进入我准备给它工作的目录再启动： ...

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 条是"日常真正省时间"的核心姿势，全部按顺序展开，每一条都尽量具体到"打开哪个文件、敲哪条命令、看哪个输出"。我会刻意把"我踩过的坑"嵌在技巧后面写，而不是单独列一节，这样读起来不会割裂。 ...