每隔一段时间都需要对抗一下“人生无意义”这道难题😮‍💨

处理系统问题，有时就跟做心内科医生差不多。

看着系统的监控图，就像在看病人的心电图。先根据异常指标判断哪里出了问题，再顺着日志、链路和上下游一点点定位原因，对症下药。问题处理完之后，还得继续做压测，不断把压力往上加，看系统从什么时候开始出现异常，最终摸清它真正的性能边界和极限。

团队缺几位 AI 工程师，一起建设面向企业智能办公场景的 AI 基础能力，有资深/专家岗，base杭州，欢迎推荐和自荐。

有生产级 AI 应用经验、高流量系统稳定性治理经验、AI 辅助研发的系统实践者优先。

所处环境决定了认知输入和判断框架。

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

团队五月做的“AI 实习生”，跟 Claude Tag 的表现基本一致，全程自主端到端完成需求的挖掘、研发、验收、发布、监控和用户反馈，几乎不需要人参与，自主性极强，Context 极广，工具和权限也极高，基本等同人的权限和视野。

Claude Tag 这个产品会适合小团队，大团队用起来，权限风险和成本都扛不住，还有很大的进化空间。

一个真正参与项目的数字人，最基础的能力，是认识人、了解事情，并且能够从各种上下文里判断自己是谁、正在做什么、接下来应该做好哪些事情。

所以对一个数字人来说，首先需要有明确的身份和目标。甚至应该像真实员工一样，给他设定明确的 OKR、里程碑和阶段计划，让他知道长期目标是什么，当前阶段要推进什么，什么事情做完了才算完成。只有这样，他才能持续、有序地把事情往前推进，而不是每次都等着人给他一个 Prompt。

这里最复杂的一个问题，是数字人会同时进入很多场景，面对不同的人，以不同的角色处理不同的事情。怎么保证它不串台、不产生幻觉，同时始终在对应角色的职责和权限范围内把事情做好，这可能才是数字人真正进入生产环境之后最难的地方。

不同角色需要的 Context、能力和权限完全不同。

比如质量角色，需要给他手、脚和眼睛。让他能够看懂屏幕、操作软件、理解需求，能够真正像一个测试工程师一样去使用产品、发现问题、验证结果。

SRE 角色，需要把机器数据、业务数据、日志、监控、部署状态这些 Context 持续提供给他。这样他才能判断什么时候应该扩缩容，什么时候需要补监控，什么时候应该重启机器，什么时候一个异常背后其实还有更深层的问题。

客服角色，需要让他明确知道自己回答问题的边界，同时拥有足够完整的产品和技术 Context。一个真正好的客服数字人，甚至应该能够读取完整的代码、文档、历史问题和线上状态。代码可以给只读权限，但 Context 应该足够完整。这样很多问题它不需要猜，可以直接从系统事实里找答案。

所以真正要解决的，已经不只是怎么让 Agent 会调用工具、会执行任务。工具调用这件事情会越来越简单，难的是让一个数字人在长期运行过程中，一直知道自己是谁、当前负责什么、手里有哪些信息、能做到什么程度、哪些事情不能碰，以及做到什么程度才算把事情做好。

只有这些东西逐渐被约束清楚，数字人才有可能真正进入项目，承担一个稳定角色，而不是每次都作为一个临时被叫过来的助手。

软件研发未来一定会走向一个黑盒验收时代。

过去每一个功能、每一个 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”完成协作。细分工种会不断收敛，人的责任边界会越来越大，专家能力也会越来越深。

今年最大的感受是，别内耗，做完的决策，立刻忘记掉，继续往前看。再痛苦的事情，也就痛几秒钟，过去了也结束了。