昨晚发给 AI 的一段提示词，早上起床有惊喜： 在我的电脑上，配置好 Pi、DSH、Super-Agent 等开源项目，将它们组合成一个能够主动提供服务的超级智能。 首先，充分探索当前系统已经具备的能力，包括各种 CLI、MCP、Skills、浏览器自动化工具，以及本地和云端的 Agent 执行环境。尽可能利用现有的工具生态，把研发、信息检索、文档处理、项目管理、日程管理、沟通协作等能力都集成进来。 整个过程中，需要主动调研 GitHub 上最优秀的开源项目，优先复用成熟的技术成果。将调研内容、架构设计、配置方案、依赖资源、工具使用经验等整理保存，做好版本管理，确保整个系统能够持续迭代、方便迁移。 接下来，构建一套主动感知机制，定时巡检我的消息、邮件、日历、文档、代码仓库、项目任务等信息源，结合我的个人工作上下文，理解我正在做什么、关注什么、有哪些尚未完成的事情，以及哪些事情值得主动推进。 去互联网寻找类似 Multica 的开源项目或成熟方案，在本地构建一个统一的任务中心，将发现的待办事项、潜在问题、项目机会和需要决策的内容梳理出来，统一放进 Inbox。 任务中心需要对所有事项进行分类，并建立 L1 到 L5 的自主执行等级。Level 越高，意味着这件事情越容易被 AI 独立推进。 * L1：理解和整理信息，提取待办、总结背景。 * L2：分析问题，提供建议和执行方案。 * L3：能够完成部分工作，生成可交付的中间成果。 * L4：能够自主完成大部分工作，关键环节需要人工确认。 * L5：能够端到端完成任务，自主验证结果并交付成果。 系统需要能够根据任务类型、上下文、工具能力和权限，自动判断哪些事情可以由 AI 推进，哪些事情需要我参与。 对于能够自主完成的任务，要主动制定计划、调用工具、执行操作、验证结果，并持续跟进。对于复杂任务，需要自动拆解成多个子任务，交给不同的 Agent 并行处理，同时管理任务之间的依赖关系。 另外，设计好 HITL（Human-in-the-loop）机制。涉及重要决策、对外沟通、内容发布、敏感操作等事项，需要先进入 Outbox，等待我的确认。通过消息通知等方式，将需要我决策的内容主动推送给我，并提供必要的背景、建议和可执行选项。获得授权后，再继续推进后续工作。 这个系统的建设存在一定的复杂度。你需要充分利用 Codex 等高能力编码 Agent，让它们对整个工程进行系统性的设计和任务拆分，再将具体任务交给独立的子 Agent 处理。能够并行的任务尽可能并行，能够复用的能力尽可能复用。 要求整个执行过程不能偷懒，不能只停留在架构设计、生成代码或者 Demo 阶段。要真正把生态能力用起来，必要时自己编写代码，完成真实环境下的集成、测试和验证，确保每个核心模块都能正常工作。 整个系统的架构要清晰、简洁、可移植，稳定性要足够强。需要考虑任务持久化、异常恢复、失败重试、权限隔离、数据安全、执行成本和资源管理，保证 Agent 能够长期稳定运行。 同时，为整个执行过程建设一套监控看板，能够直观查看 Inbox、Outbox、任务状态、Agent 执行进度、工具调用记录、执行日志、异常信息和最终交付成果。支持调试、任务重试、人工干预和历史回溯。 你还需要持续理解和更新我的个人上下文，包括我的工作职责、正在推进的项目、长期目标、技术兴趣、日常习惯和个人偏好。让 Agent 能够基于这些信息主动判断事情的优先级，并发现潜在的工作机会。 整个建设过程需要自主完成调研、架构设计、任务拆分、并行开发、集成测试和部署运行。遇到问题主动寻找解决方案，只有真正需要我决策或者授权的事情才来找我。 系统建设完成后，还需要通过真实任务进行端到端自测，验证从信息发现、任务识别、自动规划、自主执行、人工确认到成果交付的完整闭环。确保它能够在后台持续运行，真正主动替我完成工作。 最终，我希望得到一个能够长期运行、主动感知信息、理解个人上下文、自主发现任务、持续推进工作、交付真实成果的超级智能。 我只需要关注目标和关键决策，剩下的事情，尽可能交给 AI 自己完成。

在企业内部，将基础设施和应用服务能力转换成 MCP、CLI、Skills 等形式，经常用一个词来概括，叫「上翻」。 它有点像 IoC（Inversion of Control，控制反转），将底层能力的控制权和编排权交给上层 Agent。 在 Claude Code 爆火之前，企业内部 Agent 生态还处于起步阶段，上翻也才刚刚开始。但大半年过去之后，很多公司的内部生态已经变得非常 AI Friendly，大量基础设施和业务应用都开始主动向 Agent 开放自己的能力。 这个时候再通过 Context 驱动企业内部的 AI 资源，将这些能力组合起来，构建能够真正交付工作的数字员工，会是一个比较好的契机。 回到 C 端市场，做 Personal Agent 也是类似的逻辑。 越来越多的应用已经开始将自己变成插件或工具服务，供给到 ChatGPT、Grok 等 AI 平台，或者通过 MCP、Function Calling 等方式，将自己的原子能力拆解了出来。随着 DSH、Super-agent 这类项目开源，Agent 的工程执行能力又得到一波巩固，当前的 AI 已经完全可以胜任复杂任务了。 2026 年底，就会进入到一个重要的转折点。市场的关注点，会从 AI 能做事，到能交付结果，个人为任务执行结果付费，企业为经营结果付费。想一想，明年又是互联网从业者惨烈的一年😂

关于 Personal Agent 的两个根本性问题： 1、用户可能不需要一个 AI 健康管家，但是他希望少生病、睡得好；用户可能不需要一个 AI 助理，但希望自己的事情能自动处理好。AI 产品如果要求用户主动提出任务、持续管理 Agent，本身就创造了新的使用成本。一个每月只能帮我节省半小时，却需要我花一小时配置和检查的 AI 助理，缺少足够的经济价值。 2、早期的电力革命催生了冰箱、洗衣机和空调，解决的是高频、刚需的物理世界问题。AI 当前的价值更多集中在认知和决策领域，比如让孩子拥有私人教师、让家庭拥有健康管家、让每个人拥有私人事务助理。但普通人真的需要这么多专业服务吗？供给能力的爆炸，并不一定带来需求的爆炸。我们可能严重高估了人类对 AI 服务的需求。 Personal Agent 的最大竞争对手，可能是用户什么都不做😂。宁愿忍受一些低效率，也不愿意为解决这些问题额外投入精力。

AI 已经发展快四年了，可以说几乎完全渗透进了软件行业。但再去观察这个行业从业者的基本情况，会发现工资并没有普遍大幅增长。 AI 当前的经济价值，更多体现在替代人工解决已知问题、创造已知价值。 过去一个工程师每个月交付 10 个需求，现在可以交付 20 个。如果公司确实需要这 20 个需求，并因此增加了营收，那么工程师的绩效可能会提升，但工资未必同步增长；如果公司只需要 10 个需求，那么工程师空闲的时间就变多了，企业甚至可能因此减少招聘或裁员。 人的收入增长，需要更多增量价值来支撑。例如利用 AI 独立开发产品，面向市场销售，获得新的商业回报，这是个人产能向市场价值的溢出。那么对企业来说，如何获得这种价值的溢出呢？🐶

有时候会想，我们每天这么着急，到底是为了什么？ 着急送孩子上学，着急赶到公司，着急处理工作，着急把一件又一件事情做完，就连电视剧都要着急三倍速刷完。好像所有事情都有一个必须赶上的时间点。 可如果因为赶时间，失去了跟孩子好好走一段路的心情，那我们究竟是在节省时间，还是在消耗生活？

从公司 IT 学到一个冷知识，Mac 长期不关机，MagSafe 插口容易出现疑似接触不良甚至充不进电的问题。 另外一个冷知识，关机 30s 以后重试，可以解决这个问题。 查了下原理，关机等待 30s，会让 Mac 的电源管理相关电路充分掉电、硬件残余状态被清除，从而让充电控制器在下次上电时重新初始化。😃

Team 的运转离不开三类人。第一，能够持续去定义问题，做什么，不做什么。第二，对结果负责的 owner，他能够牵引团队，以正确的方式拿到结果。第三，领域专家，他的技能是确保团队在复杂任务之下，依然可以良好运转。AI 很容易让这三类特性同时落在一个人头上，因此出现了大量的超级个体、OPC。

OpenClaw 凉了么？从 Star 趋势来看，差不多了，社区讨论热度也几乎没有了。 但从 PR、Issue 等贡献来看，还是相当活跃的。它已经从一个全民围观的现象级项目，退回成了一个大型 Agent 开源基础设施项目。 玩 🦞 的人，基本都是各种 Skills、Memory、Tools 折腾一遍，然后就会面临一个灵魂拷问：“所以我到底每天让它干嘛？” 如果没有稳定、高频、可衡量的任务，Agent 就会从生产力工具退化成一个昂贵的电子宠物。 OpenClaw 当前的命运，已经是从个人生产力场景走向企业严肃办公场景，重新挖掘它在企业里的价值。

发现一个有意思的现象，运营商会在城域网部署策略，精准拦截中转站的流量。难怪最近在家 codex 总是连不上。 具体表现是，从中转站服务器看日志，发现是客户端主动断连（ client prematurely closed connection），客户端看报错是服务端主动断连（server reset）。实际上是中间网络环节伪造了报文，分别给服务器和客户端注入了 RST。 命中策略：codex/cc 发出的请求指纹 + 部署在云服务器的 IP + SNI 嗅探识别是中转站域名。

在 AI 转型面前，所有人都是从零开始，这是最大的公平。但一定有人跑得更快，也有人开始掉队，甚至迷路，后者缺少的往往是一个好的环境和良善的指引。 我的建议是，持续去找比当下环境更 AI Native 的工作模式、工作伙伴和工作氛围，融入进去，学会主动为自己营造环境。

软件研发未来一定会走向一个黑盒验收时代。 过去每一个功能、每一个 PR，都需要人来 Review 和验证。但随着生产端的速度越来越快，验收逐渐跟不上生产，这个时候，人就会成为最大的瓶颈。 所以 AI 必须参与到代码审查和功能验收里，甚至还要进一步完成自部署、自监控。 这件事情实施难度很高吗？其实并没有。 只要把过去每个工种积累下来的经验和技能蒸馏给 AI，让 AI 把它们转化成有效的 Workflow、Skills 和 Scheduled Task，基本上整条链路都可以逐渐走通。 举个例子，线上监控大盘的搭建，过去一直是人在做。但仔细拆开来看，大盘本质上就是对日志、指标等数据格式化之后，通过接口查询，再进行图形化表达。 而 AI 在写 SQL、理解数据结构、生成查询逻辑这些事情上，本身就非常擅长。 我们团队的实践，就是把搭建监控大盘所需要的基础能力全部让 AI 学明白，然后让它围绕机器、业务、数据库、中间件，建立全面的总视图、分视图、Top 榜视图和各种监控视图。 这些事情 AI 做得特别好。 真正麻烦的是前面的链路打通。这里面涉及大量权限问题、接口问题、调试问题、数据问题等等。 但这些工作大多是一次性的。 一旦把能力建设好，后面就可以在各种场景里持续复用。 一个月搞通一个角色的大部分工作，三五个月下来，整条研发工作链路都会变得无比通畅。 到那个时候，AI 的工作会越来越少需要人直接干预。人的职责也会随之发生变化，从亲自参与每一个研发流程，逐渐转向建设这些自动化流程，维护这些 Workflow、Skills 和基础设施。 研发团队真正重要的能力，就是持续把人的经验变成 AI 可以稳定执行的系统能力。

很多人觉得 AI 做不好验收工作，当下确实是这样的，因为它缺少判断的准则。人可以教它，但无法穷尽所有情况。 可 AI 有一个优势，它在边界思考上往往比人更全面、更多维。所以理论上，在进行测试的时候，AI 完全有机会测得比人更完善。 对 AI 测试来说，首先需要从两个关键能力入手。 第一，它要完整理解需求。 AI 应该针对需求和目标去测试，而不是只针对功能去测试。 未来的测试方法，会更偏向 BDD，而不是 TDD，甚至是 Goal Driven Verification。先理解这个需求为什么要做，最终希望解决什么问题，用户应该获得什么结果，再围绕这个目标去设计测试。 第二，它需要具备足够的手、脚、眼。 让 AI 真正能够看清软件、看懂软件，能够像一个人一样在界面上完成操作。 它需要学会编写 E2E 测试用例，通过 OCR、模拟点击、滑动、截图、录屏等方式，不断丰富自己对界面的认知，然后基于目标和需求，持续改善测试用例的完整性和鲁棒性。 我们团队现在实践的时候也是这么做的。 每一次迭代发版，AI 都会先把这个迭代所有的代码 diff 拿出来，理解一次这次核心改动的功能点到底是什么，然后开始编写对应的 E2E 测试用例。 刚开始写出来的时候，大部分测试其实都跑不过。 它会自己执行，再根据执行过程不断修正测试用例里的问题，直到整条链路能够真正跑通。 在整个验收过程中，它所有的点击、滑动、输入等操作都会被记录下来，同时保留截图和录屏，最终产生一篇完整的 E2E 测试用例文档和测试报告。 这篇文档里的信息其实非常丰富。 它会包含这次测试的目标、操作路径、操作截图、操作录屏、操作反馈，以及每一步执行之后软件真实呈现出来的结果。 然后 AI 会再回过头去理解这篇文档，重新判断整个过程是否真的达到了最开始的目标。 我觉得这才是 AI 测试真正应该走的方向。 测试不应该只是验证代码有没有跑通，也不应该只是验证某个按钮能不能点。它最终验证的是，这次改动有没有真正完成需求，有没有达到目标。

最近一个非常明显的变化是，测试和前端开发这些细分工种，正在逐渐被收敛。 今天很多研发流程依然是 Human in the Loop，人还深度参与在工作流中。但我们更想看到的状态是 Human over the Loop，人逐渐脱离具体工作流，让任务能够自循环、自验证、自进化。 这里核心要解决两个问题。 第一个是验证。 AI 的生产速度一定会超过人的验收速度。如果每一份 AI 产出最后都需要人来 Review、测试和验收，那么 AI 生产得越快，人反而越容易成为整个系统的瓶颈。要真正实现 Human over the Loop，验证本身也必须交给 AI。人负责定义目标、标准和边界，AI 负责执行，同时完成验证、反馈和修正。 第二个问题也随之而来。当大量任务的生产和验收都开始发生在 Agent 之间，我们还需要那么多面向人的前端表达吗？ 过去的软件大量服务于 Human Computer Interaction，所以需要非常丰富的界面、交互和前端工程。未来人机交互会减少，机机交互会越来越多。很多过去通过页面、按钮、表单完成的操作，会变成 Agent 之间的协议调用、状态传递和任务协同。 所以前端的工作也会发生迁移，从“怎么让人更好地操作系统”，逐渐转向“怎么让人更好地控制 Agent，以及让 Agent 之间更好地协同”。 而 Agent 之间这一层协同，本身又天然适合自动化。Agent 能够理解目标，能够调用工具，也能够根据反馈继续执行。所以从这个视角往下推，测试、前端这些高度依附于传统软件生产流程的细分工种，会最先受到冲击。 再往后看，未来的人才结构可能会逐渐收敛到两类。 一类是端到端交付的人。他们面对的是业务问题，从需求洞察开始，一直到方案、研发、验证、上线和运营，对最终结果负责。 另一类是领域专家。他们解决的是足够深的专业问题，包括架构、性能、安全、基础设施，以及 AI Harness 等复杂工程能力，把自己的专业知识沉淀成工具、规则、评测体系和 Agent 可以复用的能力。 这两类人都不可或缺。一个负责把事情做成，一个负责把某一类事情做到足够深。 过去组织通过大量细分工种完成协作，未来更多会通过“端到端交付者 + 领域专家 + Agent”完成协作。细分工种会不断收敛，人的责任边界会越来越大，专家能力也会越来越深。

组织朝 AI 转型，首先要解决的是人的意识问题。 以前做事情，都会有明确的分工，因为术业有专攻，每个人擅长的点也不一样。AI 出现以后，一个很大的变化是，它开始补齐人的短板。长板可以更长，短板也能够被不断补齐，所以越来越多的人开始具备端到端的交付能力。 这里的端到端，不仅仅是全栈技术能力，还包括技术之前的需求洞察，以及技术之后的产品运营和市场推广。 如果人的意识还停留在“我有我的地盘，你有你的地盘”，依然沿着过去的专业分工推进工作，那么协作模式就还会停留在过去，最终的交付模式也不会发生本质变化。AI 用上了，组织却还是原来的组织。 意识真正转变之后，每个人考虑的问题都会往前后延伸一步：我的上游是什么，我的下游是什么，怎么把它们衔接起来；哪些过去需要依赖别人完成的工作，可以让 AI 帮我补齐；我自己的经验和技能，又怎么转化成 AI 可以理解、可以执行、可以复用的工作流和方法论。 AI 最擅长的事情之一，就是粘合、衔接、串联和自动化。人开始对更完整的结果负责。

寻求共识的成本是巨大的，意味着需要无数次对齐，也会产生无数次摩擦。 梁文锋会在团队内寻求共识，允许团队只有低于 50% 的战斗力“干正事”，也就是“自上而下”做事，而剩下的部分，都是“自下而上”地做事。 共识的好处是，能够凝聚群众的智慧，也可以形成合力，让力量叠加后的最终效果趋近于想达成的目标。 共识之下也必然存在妥协，AI 时代，一家公司能够持续往前跑，很大程度不在共识，而在非共识之下的个体差异性上，它能够“滋生”创新，也会最大化人的主观能动性。 这才是梁文锋团队持续保持稳定的根本，1）目标明确节奏清晰，2）有个体成长和发挥的空间，3）还能保持五点下班，😄

对高质量算力拥有方来说，卡资源永远是瓶颈，全球真正在用算力的人不足 0.3%，而AI 未来会支撑至少 10% 的全球 GDP，也就是说，未来需求端还会持续蓬勃增长。 智能的前沿临界点，是所有模型公司的必争之地，下一个阶段，是 Agent 自进化，再下一个阶段，是 Agent 学会提问题。暂时落后的公司，未来还有很多弯道超车的机会。 从这个视角再重新看 Coding Agent，似乎也没有达到所谓的 AGI。软件尚未做到自构建，更无法主动去洞察用户端的需求。