Posts

我把小米电视交给 AI 改造：一次远程桌面替换的 18 项验收 我家那台 Redmi X65，桌面首页常年堆着剧集推荐和会员角标，关不掉。2026 年 11 月 1 日，我把这活儿整个交给了电脑上的 AI：它读文档、下安装包、连电视、装 App、授权、最后逐条验收，我只负责在电视上按几个遥控器键，以及决定哪些事不能做。【关键词：#Aerial #ADB #小米电视】 01｜我的活儿只有一句话，剩下的是它的 我给 AI 的任务很短：把开源桌面 Aerial 装到我家电视上，让它接管开机和主页键，别动我原来的任何系统应用。 之所以交给 AI，而不是自己照着文档敲，是因为这类活儿有一个特点：步骤都不难，难的是不出错。查系统版本、选对应的包、给权限、确认守护服务真的挂上了、跑完 18 条验收还要逐条比对输出——人做会累，做漏一条也不知道漏在哪。AI 做这件事刚好合适，它不会因为「第 9 条看着没问题」就跳过去。 选 Aerial 的理由也很实在：它参照 tvOS 做了 Android TV 桌面，没有广告和推荐流，只有 App、壁纸和 Apple TV 的 114 段航拍屏保；Kotlin 写的，MIT 许可证；仓库 2026 年 10 月 20 日建仓，到 11 月 1 日已经 8377 星、697 个 fork，1.75、1.76 一天内各发一版。官网是 aerial.qust.me。 ...

AI 还在输出，我能插话吗？背后的两类协议 我想做一个 AI（人工智能）应用：它持续输出，我能中途补一句“换个方向”，还得保存任务进度。研究这个需求，先要分清两件事：消息怎么传，新指令什么时候执行。【关键词：#流式输出 #SSE #WebSocket】 01｜持续输出，靠什么传？ 常见的是两类协议： SSE（服务器发送事件）：基于 HTTP，服务端在同一条响应里持续发送增量内容。文字逐段出现，不用等整篇生成完。 WebSocket（双向通信协议）：连接建立后，双方都能主动发消息，适合频繁交互和实时音视频。 厂商要按具体接口区分，不能一个名字概括全部： 官方接口 使用的传输方式 OpenAI Responses：HTTP 流式模式 SSE Anthropic Messages：流式模式 SSE OpenAI Responses：WebSocket 模式 WebSocket Google Gemini Live：预览版 WebSocket SSE 负责单向下发，也能搭配另一条 HTTP 请求接收用户指令。能插话，不代表必须用 WebSocket。 02｜消息发到了，AI 就会马上改吗？ 我更关心的是这一层。假设 AI 正在写方案，我补一句“预算减半”，应用可以有三种处理方式： 打断：请求停止当前生成，再带着新要求继续。已完成的工具操作需要另行处理，取消生成不会自动撤销它们。 中途调整：接收新要求，到合适的执行边界再改方向。 排队：当前任务做完，再处理下一件事。 具体机制各家不同。例如，OpenAI 的中途调整接口使用 response.steer：先确认收到，等当前输出项和已运行的托管工具收尾，再在后继响应中加入新要求。收到指令，不等于指令已经生效。 SSE、WebSocket 解决传输；打断、调整、排队，属于任务调度。协议不会替应用做决定。 03｜连接断了，任务还在不在？ 还得看应用保存了什么。 我会把用户指令、已公开的输出、任务状态和事件序号存下来。重新连接时，先恢复记录，再补发缺失事件；重复送达的指令要去重。长连接不能充当数据库。 对我这个以文字任务为主的需求，我会先选“HTTP 提交指令 + SSE 接收输出”，把任务调度与保存做好。需要实时音视频或频繁双向交互时，再考虑 WebSocket。 聊天框里多一个输入入口很容易；让一句新要求在正确的时机生效，才是这件事的核心。 作者：猫咪不吃愚 资料核查：2026 年 10 月 29 日。本文为方案分析，未做接口实测；AI 辅助检索与起草，封面由 AI 生成。 ...

AI 写了 90% 代码后，Anthropic 怎么把 code review 做不崩 原文：How the Claude Code team does code review 作者：Addy Osmani, Morgan Westlee Lunt, Qing Wang（Anthropic Claude Code 团队） 来源：claude.dev 官方博客，发布于 2026 年 10 月 15 日 【关键词：#ClaudeCode #代码审查 #AI编程】 原文开篇连着问三个问题：每天 agent 产出这么多量，该怎么 review？还有人在读代码吗？真出事了谁来兜？ 这问题问得很准，因为 Claude Code 团队自己就是那个极端案例——Claude 写了约 90% 的 Claude Code 代码。我把原文和配套的工程博客、官方文档全过了一遍，最有价值的部分整理在这里。 01｜先看场景：AI 是主要作者时，review 为什么崩 三个数字摆出来，问题的量级就清楚了： Claude 自己写 Claude Code 约 90% 的代码 Anthropic 的 monorepo 每天落地的变更数，从 5 月的约 2,500 涨到 9 月的 30,000+（Claude Code 在独立仓库，不在这个 monorepo 里，但同样在承压） 6 月到 9 月，Claude Code 自己仓库的合并 PR 翻了一倍多，而需要 revert 的比例下降超过 40% 九成代码由 AI 写、每天三万次变更落地，人力逐行 review 在这个量级下不是"困难"，是"不可能"。 ...

Pi 的 Agent 循环：159 行，两个 while，四条退路 原文：pi-agent-core · agent-loop.ts 作者：Mario Zechner（pi-mono / pi-ai 作者） 来源：earendil-works/pi 仓库，@earendil-works/pi-agent-core v1.4.0 阅读环境：2026-10-26 对照 v1.4.0（2026-10-22 发布），agent-loop.ts 第 172–330 行 2026 年 10 月，我想把 Pi 接到自己项目里，顺手翻了一遍它的 agent 循环。 这个仓库半年里从 v0.62.0 涨到 v1.4.0，核心那个 runLoop 从 78 行长到 159 行，骨架却一个字没动。多出来的 80 多行，全是留给上层插嘴的。 【关键词：#Pi #Agent循环 #源码阅读】 01｜骨架：两个 while，各管一件事 Pi Agent 循环骨架：外层管队列，内层管 turn 函数叫 runLoop，在 packages/agent/src/agent-loop.ts 第 172 到 330 行。一个 while (true)（188 行）管外层，一个 while (hasMoreToolCalls || pendingMessages.length > 0)（192 行）管内层。 ...

VS Code 这次没重做 UI：它把 Agents 窗口那套设计系统搬回了编辑器 原文：Modernizing the VS Code UI 作者：Lee Murray（VS Code 团队；具体职位未在博客中注明） 来源：Visual Studio Code Blog，发布于 2026 年 10 月 15 日 我读 Lee Murray 在 2026 年 10 月 15 日发布的《Modernizing the VS Code UI》，先找的是改版目的。官方给出的方向很明确：理清十余年累积的界面层级、减少干扰，用同一套设计基础承接手动编辑和 AI 智能体（agent）会话，同时保留信息密度、定制能力和熟悉的操作习惯。【关键词：#VSCode #现代UI #Agents】 顺着这个目的，我更关心的是：这套设计为什么先在 Agents 窗口落地，搬回编辑器后，又为老用户改了什么。下文依据博客发布时的预览状态解读，设置建议未经本地实测。 01｜我先分清：这次改的是哪一层 我先看了博客里的时间线：2015 年首发预览，2016 年加入编辑器标签页，2019 年更新树状控件，2023 年推出 Dark Modern / Light Modern 主题。今天看着理所当然的界面，其实是一块块加上来的。 原文把这种演进叫作逐个组件推进。工作台（workbench，也就是包围代码区的导航、面板、标签等界面）里的各个部分，未必遵循同一套间距、字号和控件规则。我把它理解成一间不断添家具的书房：每件家具单看都能用，放在一起，尺寸和动线却未必协调。 我理解这次改版的边界是：保留文件编辑方式，改造工作台外壳。 密集的文件导航、多编辑器分组和已有操作习惯，都要继续照顾。沿着原文，我把推进过程串成三步： 颜色先动：以 Dark 2026 / Light 2026 两个新主题为起点，一起考虑工作台配色和代码语法高亮。 共享设计系统在 Agents 窗口里跑通：这个窗口在 2026 年早些时候进入 Stable（稳定版），当时仍是 Preview（预览功能）。它围绕发起智能体会话、跟踪进度、检查结果组织界面，为统一间距、字号、界面底色和控件规则提供了落地场景。 把同一套规则铺到编辑器外壳：活动栏（Activity Bar）、侧边栏、编辑器组、面板、标签、状态栏，成为应用共享规则的区域。 读到这里，我才把 Agents 窗口和这次改版连起来：直接编辑文件时，重点是快速找文件、切分组；委托智能体做事时，重点是看会话状态、下一步动作和修改结果。两种工作流需要不同布局，但字体、间距、颜色和控件可以共用一套规则。Agents 窗口是实验室，编辑器外壳是推广地，并不意味着要把编辑器也摆成一个聊天窗口。 ...

AI 泡沫会怎么破？我担心的是回本太慢 我看好 AI 对生产力的长期影响，但对这轮资本投入有个担忧：技术进步的速度，和投资者赚回钱的速度，可能差得很远。【关键词：#AI泡沫 #生产力 #投资回报】 01｜用了多少，还不等于赚了多少 截至 2026 年 10 月 4 日，美国人口普查局调查中，23.8% 的企业报告过去两周使用过 AI。口径是任一业务职能，写邮件也可能算，不能理解成近四分之一的企业已经完成业务改造。官方数据 这个比例说明普及仍有空间，却不能单独证明泡沫。真正让我在意的是：使用能否持续，扣掉接入、审核和返工成本，还能省多少钱。 02｜需求是真的，投入也不小 微软 2026 年 7 月 29 日披露，Microsoft 365 Copilot 已超过 3000 万付费席位。愿意掏钱的需求确实存在。微软财报 同次披露中，第四财季资本开支达 410 亿美元，约三分之二投向以 CPU、GPU 为主的短寿命资产。这包含非 AI 业务，不能全算成 AI 的账，但设备更新的成本躲不过。财报电话会 假设 AI 帮企业省下 100 元，企业可能只愿付 10 元。竞争再把价格压低，生产力红利就更多留在用户手里。AI 很有用，供应商也可能赚不到预想的利润。 03｜泡沫可能破在预期落空时 如果这轮泡沫发生明显调整，我更倾向于这样的过程：企业续费和扩容低于预期，融资转冷，部分公司削减算力采购，扩建项目随之推迟。 不必等到收入下降。市场按翻倍增长给价，实际只增长五成，也足以触发估值下修。资金薄、债务重、客户集中的公司，会更难熬。 目前这些数据还不足以证明整个行业都被高估。我担心的是，资本把多年后的利润，提前算进了今天的价格。 所以我会继续用 AI，也继续看好它的长期价值；评价投资时，则更关心续费、毛利和现金流。技术值得期待，回本的账仍要一笔笔算。 资料核查截至 2026 年 10 月 19 日；本文含 AI 辅助检索与起草。 作者：猫咪不吃愚

这半年看下来，我反而更愿意先把云端 AI 代理用上 原文：OpenAI DevDay 2026 作者：Sam Altman 及 OpenAI DevDay 2026 keynote 团队 来源：OpenAI DevDay 2026，主旨演讲于 2026 年 9 月 29 日，旧金山 2026 年 9 月 29 日 OpenAI 把 Dot 推到台前那天，我就把 DevDay 完整回放看了两遍。我是个 30 岁的中国程序员——之前在互联网大厂烒过 996，现在在国企云厂上班；我关注这一年的体感，谈对"云端 agent"和"手机 agent"两条路线的取舍。你不同意完全没问题，下面这些都是我自己的体感、或看到了身边朋友跑过之后留下的证据。【关键词：#云端 AI 代理 #常驻智能体 #OpenAI Dot】 01｜云端 agent 到底是什么、和手机代理为什么差那么多 这一篇谈的"云端 agent"，我先把它的定义讲清楚——是一种常驻式的 AI 助手，但装在厂商分配给你的远程电脑上，不是装在你本地设备。你授权账号之后，它能直接登进 GitHub / 邮箱 / 企业 SaaS 这些云端服务，按你给的步骤替你跑任务：可以是一次性的（"今天帮我抓 30 个 trending 项目"），可以是长时盯梢（"盯着这张机票，低于 4500 美元就叫我"），也可以是每天早上 8 点做一份昨晚邮件摘要这样的连续工作。它最不寻常的一点是：你关掉 ChatGPT 它也在跑，你换台设备登录它仍在原来的上下文里——这一条就把"AI 跟你聊天"与"AI 帮你办事"完全划开了。 ...

适应 AI 时代：提高判断力和品味，让产出变多，也让自己变强 2026 年 10 月 2 日晚上，我和几位算法、产品同行吃饭，聊到很多校招面试人很会用 AI，却判断不了它的成果。这让我琢磨：借助 AI 做更多事的同时，自己的能力怎么跟上。【关键词：#AI协作 #判断力 #个人成长】 我更愿意把精力放在四件事上：选值得做的问题，判断方案的好坏，补自己的短板，把经验变成下次能用的工具。 01｜先选问题，再追速度 AI 能帮忙执行，目标却需要说清楚：为谁解决什么问题，做到什么程度就够了，哪些代价不能接受。 OpenAI 在 2026 年 9 月 16 日公布的研究中，持续观察约 6,200 名美国 ChatGPT 用户：涉及此前用过的跨职业任务的消息，占职业特定 AI 消息的平均比例，从 4 月的 13.1% 升至 7 月的 25.9%。这反映该样本的使用变化，不代表专业能力或生产率翻倍。研究报告 值得尝试的，是用 AI 扩大任务范围：例如程序员借助它分析用户反馈，再用真实需求检验。先选有价值、能验证的小任务，不急着给自己换个“全能”的头衔。 先判断事情有没有价值，再让 AI 放大投入的效果。 02｜基础检查对错，品味权衡取舍 判断力检查结果是否可靠；品味决定方案是否值得采用。Ethan Mollick 在 2026 年 9 月 18 日的博文中强调，深厚专长、跨领域知识、品味与主动探索，能帮助人更好地利用 AI。这是他的观点，并非就业保证。原文 拿一个假设的订单服务举例。接口能下单，还得检查重试会不会重复扣库存、写入失败怎么恢复。理解并发和数据一致性，才知道该查哪里。 维护成本不会因为架构图漂亮就打折。用户少绕路、团队好维护，都是比“看起来高级”更具体的取舍依据。 两个模型都说对，不等于两份独立证据。关键判断仍要回到资料、实验和用户反馈上。 03｜交付借力，学习保留练习 熟悉的任务，知道怎么验收，就让 AI 多做。自己解释不清的概念，先独立想一遍，再请它挑错。 Anthropic 在 2026 年 1 月 29 日公布的编程学习实验中发现，AI 辅助组的即时理解测试表现更低；主动追问概念、要求解释等使用方式表现较好。这是小样本、短期实验，不能推断长期能力必然下降。研究说明、论文 ...

国庆假日里想明白一件事：编程语言对 AI 来说，可能本身就是低效的，我们还在纠结编程语言吗？ 国庆第 1 天，没怎么出远门。下午我看着窗外，想着最近半年跟 agent 协作下来的体感，正好网上还在争论"AI 写 Java / Python / Go 哪个质量好"，忽然意识到一件事——这些争论，可能问错了。编程语言对 AI 来说，从一开始就不是它的母语。【关键词：#AI编程 #AI原生工程师 #上下文设计】 maybe，我们未来不再关心使用什么编程语言，AI的对语言的学习和使用是远胜于人类的，只要AI逻辑严密，AI或许会有自己的语言去驱动及驱动机器执行二进制程序吧。 01｜编程语言从来不是给 AI 设计的 打开 IDE 看到的 Python、Go、Java、JS 这些语言，它们被人为的"可读性、命名空间、类型系统、设计模式"绑了一身——这些是好东西，让我们能跨团队协作、能 review、能维护。 但 AI 不吃这一套。它不读注释、不在意缩进、也不会被你精心取的命名打动——它真正消耗的是 token、是上下文、是注意力分布。 最近一次让我愣住的：我让 Codex 改一段 Go 的并发代码，它把 channel、mutex、context 整段翻完，最后只用了两行；而我换成一段伪代码 + 关键约束描述喂过去，它一次就跑对了。 那一刻我才反应过来：AI 时代的"语言"，正在从"语法正确、人类可读"悄悄转向"信息密度高、上下文清晰"。Anthropic 内部数据里那 27% 的"agent 原本不会做的新工作量"——翻译需求、设计 prompt、整理上下文，本身正在变成新工种（Anthropic 研究页）。 02｜AI-native 工程师的默认单位，悄悄变了 借假期想明白的第二件事，跟我自己更相关——所谓 AI-native，不是会用 Cursor/Codex，是你脑子里默认的颗粒度变了。 老一代工程师脑子里装的是行、函数、模块；我自己这半年越来越意识到，AI-native 工程师脑子里装的应该是上下文窗口、任务切片、可验证的契约。 具体到每天的工作里，是三件事： 任务切片——把一个模糊需求拆成 agent 一次能跑完的小块，而不是把 2000 行的 PR 整段扔过去； 可验证的契约——每个任务都自带验收标准：什么算"做对"、什么算"做错"，让 agent 自己跑测试； 上下文设计——知道哪些信息 agent 必须看到、哪些是噪音、出错时才补什么。 说白了，AI-native 工程师写的不再是代码，是给 agent 跑的"剧本"。 ...

用了半年 Agent 之后，我对工作开发与运营的 5 点新观察 马上要国庆了，简单回顾下过去半年的AI Coding：我是 2026 年 3 月开始把 Codex + Cindy 当主力、混着 GLM5.2（国产）和自建 agent 编排一起用的开发者。下面 5 点，全是我身边真实发生、或交叉核实过数据的事。【关键词：#Agent #岗位变化 #代码开发 #AI趋势】 01｜前后端 title 在合并，但合并方向不是"更全栈"，是"更靠近 agent" 放数据：Salesforce CEO Benioff 2025 年公开不再招新工程师（Times of India）；Cognition 团队 15 人，每人带 5 个 Devin 跑任务，自家代码库 89% 提交来自 agent（agentmarketcap.ai）；Anthropic 内部 60% 工作有 Claude 参与、27% 是 agent 原本不会做的新工作量（Anthropic 研究）。 title 在合并，意味着"更靠近 agent 的工作方式"。 02｜中间层不是被"砍掉"，是被"打散" GitLab 2025 年裁 14%、退 22 国，研发团队从 30 个重组为 60 个跨职能 pod（LinkedIn 报道）；Skai 砍中间层效率从 7–12% 跳到 500%；HaxiTAG 33 个工程师只配 1 个 team lead。 中间层没消失，是被打散到 pod 里去了——"管人"的中层在贬值，"管 agent + 管判断"的中层在升值。 ...