Barret李靖 (@Barret_China)

提供主动服务的 Agent，需要进行大量自主决策。在信息不足、环境动态变化的情况下，难免产生错误决策，甚至引发大量无效的行动和尝试。 想要提高决策质量，降低无效决策和行动的成本，我认为需要做好几件事情： 1）让 AI 在问题早期，甚至预防阶段就开始决策和产出，持续维护决策依据和结果。当问题暴露时，能够结合新增信息，快速补充和修正已有决策。 2）系统具备所见即所得的能力，能够沿着不同决策路径进行分支推演，直观呈现结果，评估不同路径的收益、成本和风险，减少实际执行中的无效尝试。 3）动态调整和更新目标，让 AI 根据目标和环境的变化，持续更新决策条件和逻辑，及时调整或终止偏离目标的行动。 4）针对决策和执行，构建自验证的环境能力，持续对比实际结果与预期目标，发现偏差并修正决策。必要时，通过简洁的交互反馈机制，让人低成本地参与关键决策。 更多的思考、推演和尝试，未必带来更好的结果。Agent 还需要学会判断何时继续探索、何时执行、何时停止，以及何时需要人介入。 为系统构建 RSI 的能力，接下来会是一个火热得命题，也会是一件非常有趣且有挑战的事情，😄

提供主动服务的 Agent，需要进行大量自主决策。在信息不足、环境动态变化的情况下，难免产生错误决策，甚至引发大量无效的行动和尝试。 想要提高决策质量，降低无效决策和行动的成本，我认为需要做好几件事情： 1）让 AI 在问题早期，甚至预防阶段就开始决策和产出，持续维护决策依据和结果。当问题暴露时，能够结合新增信息，快速补充和修正已有决策。 2）系统具备所见即所得的能力，能够沿着不同决策路径进行分支推演，直观呈现结果，评估不同路径的收益、成本和风险，减少实际执行中的无效尝试。 3）动态调整和更新目标，让 AI 根据目标和环境的变化，持续更新决策条件和逻辑，及时调整或终止偏离目标的行动。 4）针对决策和执行，构建自验证的环境能力，持续对比实际结果与预期目标，发现偏差并修正决策。必要时，通过简洁的交互反馈机制，让人低成本地参与关键决策。 更多的思考、推演和尝试，未必带来更好的结果。Agent 还需要学会判断何时继续探索、何时执行、何时停止，以及何时需要人介入。 为系统构建 RSI 的能力，接下来会是一个火热得命题，也会是一件非常有趣且有挑战的事情，😄

当你无法理解一个人的时候，可以试着看一看，是不是彼此思考问题的视角不一样。 就拿做产品来说吧，思考问题的视角就有很多。一个老板，可能更多站在公司的视角；一个产品经理，可能更多站在平台的视角；而一个一线研发，极有可能更多站在用户的视角。 大家关注的问题不同，表达方式也会有所差异。每个人都希望交付有价值的东西，只是对于价值的理解，以及实现价值的路径，可能并不相同。

Getting Things Done，很多时候不如 Do It Now。 花十几二十分钟，Stop the World，暂时屏蔽外界的干扰，把注意力完全集中在眼前的那件事情上，一口气把它做完、做好。 很多时候，这远比把事情记录在纸上，放进 Todo List，等着明天、下周再来处理更加高效。

所处环境决定了认知输入和判断框架。 每天和什么人交流，在讨论什么问题，接触什么信息，身边人在为什么事情而兴奋、焦虑、下注，这些东西会不断改变自己对什么重要，什么可能，以及什么值得投入的判断。

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

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

软件研发未来一定会走向一个黑盒验收时代。 过去每一个功能、每一个 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。软件尚未做到自构建，更无法主动去洞察用户端的需求。

梁文锋的克制，是当下能做多大的事儿，就扛多大的事儿，不贪功冒进，稳扎稳打。克制的源头，是对团队有足够的自信，是对 AGI 这条路有足够的坚定。 在 AGI 这条路上，也随时都会超越和被超越，人才、模型、算力，全都是变量，谁也不敢说自己能稳稳称霸两年。 所以克制，也意味着，不会一次性把子弹全部打光，攒着，慢慢打，这是一场持久战。

2026 半年提交的代码，快超过过去两年。AI Coding 容易让人陷入疯狂。 最近也在思考一个问题。AI Coding 时，人到底是一个需求口喷角色，还是系统架构设计角色？也在反问自己，我对我的系统是越来越了解了，还是越来越生疏了？ 我的答案是，想做的事情越来越明确了，但对做出来的那堆东西，却越来越生疏了。 对着 Coding Agent 发号施令已经成为常态。那种建应用的感觉就像，刚开始在建大坝，日日赶工，雏形也越修越好；等到真的大雨降临时，却发现东边有窟窿，西边墙面也不稳。于是，整日的工作，又变成了修修补补，拆东墙补西墙。 大多数人在开始 AI Coding 的第一天，就忽视了一个点。 软件工程里，除了支撑业务需求的代码，更多的是支撑稳定性、性能、质量、成本、安全的代码。要把系统建好，分配给后者的 AI 注意力，随着时间推移，占比通常会越来越高；当达到某一个临界点后，系统就需要面临一次重构。完成重构之后，重心才能重新回到前者。 从真实的实践来看，AI Coding 会把软件工程，从白盒精细化治理，逐步推向黑盒管理。人没有那么多精力去 Review AI 写的每一行代码，因此搭需求积木的职责，会逐步从人转移到 AI，人也会逐渐丧失对系统运行细节的理解。 如果黑盒会成为常态，那如何治理黑盒，就会成为一个新的命题。 AI 写代码时，也要关注质量工程、关注架构设计、关注领域模型抽象、关注无效代码下线、关注性能和稳定……如何让 AI 持续做好这些事情，如何在黑盒模式下继续保持代码收敛，以及系统的可持续运转，我觉得会成为未来软件工程新的挑战。

OpenAI 最近疯狂重置 Token 额度，还放开了 5 小时限制，盲猜背后的几个原因。 1）算力供给发生了变化。可能拿到了更多 GPU 资源，或与云厂商达成了更激进的合作，把闲置算力快速转化成用户增长和模型训练资源。算力闲着也是闲着，不如让用户跑起来。 2）Agent 的竞争已经开始从模型能力转向真实使用数据。o 系列长任务能力已经很强，但决定下一代 Agent 上限的，还得是大量真实世界的任务轨迹、工具调用、失败案例和反馈数据。用户用得越多，可用于持续优化的数据就越多。所以免费的，往往也是最贵的。😅 3）高价值用户的争夺进入白热化。Anthropic、Google、xAI 都在快速推进，今天比拼的已经不只是模型分数，还有谁能成为用户每天都会打开、持续运行 Agent 的平台。额度越宽松，迁移成本越高，用户习惯也越容易形成。 未来单靠模型强很难形成护城河，谁的 Token 在市面上流通得越多，产生的数据越多，Agent 就能够越成熟，与此同时，开发者生态也能越稳当，最终才能形成正反馈飞轮。 Anthropic 上一波爆发式增长让 OpenAI 感到了威胁。但从实际情况看，还是 OpenAI 现金流和算力弹药更充足呀。😃