AI 来得太快了。就像春晚舞台上突然涌现的具身智能机器人，仿佛一夜之间就铺满了全场。回想 2025 年，讨论的焦点还是霍金，而到了 2026 年，话题已经变成了霍元甲。大模型与机器人工程以惊人的速度迭代，终端工具一天之内就能更新好几个版本。
我个人对此从未抱怨过，无论是豆包、元宝，还是各类 AI IDE，只要见更新，我立马就跟上，从不犹豫。这两年，技术实践的范式也在飞速变迁。两年前，我们还在用 AI 辅助问答来解决具体的编程问题，不停地敲着 Tab 键补全代码。仅仅过了一年，就开始尝试用 AI 来搭建小型工程，虽然生成的代码偶尔像“屎山”，但改改总能让它跑起来。再到后来，落地一些简单的业务逻辑，做 Agent，训练 Skill，一切都在加速。
如今，连腾讯门口都开始排队安装 OpenClaw 了。这几天券商的金融工程研报，更是铺天盖地全是关于 OpenClaw 的安装与投研应用分析。
这一切都在告诉我们，AI 对技术团队及相关工作的影响，已经真正、实质性地到来了。摆在每个技术人员面前的，似乎只有三条路：躺平，被技术革命推着走；跟上，努力踩准技术的节奏；或者主动出击，用新技术重新布局自己的职业版图。
回顾自己这两年多的 AI 实践，这篇文章不打算长篇大论，只记录一些零散但关键的观察与思考。
1. Qwen 团队重建：组织的阵痛与变革
当一个深层次的变革发生时，总会先以各种现象层面的“八卦”呈现出来。比如之前 Qwen 核心团队的重建，从表面看，这可能是一场大厂的权力之争，或是技术角色在业务中话语权不足的体现。
但现象背后，折射出的其实是技术公司基于 AI 变革，必须对团队组织架构进行的调整。这涉及对团队、个人岗位、职责的重新定义。这个问题，小的软件公司或许可以暂时无视，但大厂必须切实行动，走在行业前面。
在传统开发模式下，产品经理和技术人员、技术和测试人员之间，总有扯不完的皮，理不清的问题。当 AI 应用普及后，个体的短板（比如文档写作、基础编码）能迅速被 AI 补齐，我们曾强调的“团队协作”可能会向更内聚的“个人全能”模式演进。如果新的团队组织形式跟不上这种变化，带来的可能就是个人能力提升了，团队整体效率反而下降的新困境。
另一个角度看，这次事件也体现了更深层面的问题：类似科学家那样的研究人员，在当前的商业环境中面临的现实困境。过去，互联网大厂和技术公司，无论用了多么高深的技术，最终解决的还是一个明确的用户故事、软件需求或产品目标。但 AI 领域的硬核研究，要解决的全是未知问题，结果同样是未知的。
这点我在投入量化工作后深有体会。面对纯研究或偏实验性的事情，只能投入大量时间去做各种思考和分析，一顿操作猛如虎，结果可能毫无用处。这时候，面对公司和领导的 KPI，只能红着脸应付；面对团队的成本、投入产出比要求，更是深感无力。这是大多数公司在做偏硬核研究时面临的普遍问题。
所以有人说，中国的创新不缺资本，缺乏的是信心以及如何组织高密度的人才。如果还用传统软件开发的思维来解今天的 AI 问题，只会适得其反。当然，可能有些技术公司连功能产品的开发团队怎么组织都没弄明白，面对新的 AI 驱动的技术架构更是完全懵圈。
在传统团队里，一个技术鬼才，我们总想改变他，希望他变得八面玲珑。但在 AI 这种硬核研究中，我们必须明白，天才就是天才。他是躺着思考还是坐着，是在办公桌上还是在厕所，都应该给予最大的自由。但这往往与 HR 规则中的公司制度、流程——“不能因为一个人破坏规矩”——产生矛盾。
事件发生后不久，谷歌在 AI 开源社区最活跃的开发者 Omar Sanseviero 在社交媒体上发出了邀请：
他，或许才是一个 AI 时代合格的 HR。在充满创造力、探索力和未知的领域，我们用传统的条条框框，用一个个精准数字构成的 KPI 来思考问题，与科研层面的热情、理想、开源、贡献精神，显得如此格格不入。
同样，核心研究和前台业务应用的矛盾，在传统软件开发中也屡见不鲜。一些公司的研究院提供的底层技术，业务部门拿去做项目时，总会扯皮各种分成和配合问题。在 AI 时代，这类问题必然存在，只是解法可能完全不同。
综上，AI 给技术团队带来的最大思考是：AI 并非简单地把 5 个人的工作变成 1 个人来做这么初级。它引发的是团队岗位、人员职责如何变化，如何制定有效的 KPI，如何评估新组织下的绩效等一系列体系性问题，而不仅仅是采购一个 AI 编程软件、用 AI 跑通一段代码这种单点问题。
2. AI 对技术岗位到底有哪些影响？
腾讯开发者曾有几篇文章写得很好，其核心观点是：在 AI 大行其道的当下，大模型仍旧无法取代程序员的两类关键技能：业务理解能力和架构设计能力。
这两项，就是 AI 时代程序员的核心竞争力。我个人非常认可，因为这说的就是我自己，体会也尤为深刻。过去几年，我一直深耕在非常具体的量化领域。直到去年底开始琢磨 AI 的实际应用时，才发现自己在业务、产品思路上的明显匮乏。沉下心集中思考一段时间后，思路才慢慢清晰，心里渐渐有了自己的“剑谱”。
这时再看 AI，它就不再仅仅是一个工具，而是你手中的倚天剑、屠龙刀。那种一夜之间就能将想法落地的体验，真的太震撼、太激动了。这是腾讯文章中提到的核心内容：
3. 如何在技术工作中使用 AI 工具？
在技术工作，如果仅限定为软件开发，目前 UI 设计、产品原型设计、需求编写、技术文档编写、架构搭建、功能代码开发、测试、自动化运维部署脚本，甚至软件配套的路演 PPT，都可以通过 AI 协作完成。
其中，编程工具的引入是技术工作中最重要的一环。上周开始，使用 trae 首次出现排队；腾讯的 CodeBuddy CN，阿里的阿里云百炼 Coding Plan 也开始走付费模式。对企业来说，则会采购 AI 开发工具的企业版本。
工具都能用钱搞定，难的是前面说的“怎么用”，以及如何量化其带来的价值。目前许多公司可能只是员工作为个人需求在使用，没有从公司整体层面进行思考。
最近一篇论文指出，通过分析真实的协作案例，最常见的人机协作模式是“导师-学徒”关系：人类程序员担任导师，AI 助手扮演学徒。AI 提出初步方案，人类负责审查、指导和完善。比如在项目中，AI IDE 自动检测到一段可能引发崩溃的代码并给出修复方案，但开发人员审核后发现方案过于简单，可能引发新隐患，于是提出更稳健的优化思路，AI 在下一次迭代中就能吸收建议，生成更可靠的方案。
这里说两个小点：
- AI 在编程中有时会“偷懒”。比如调用某些接口报错时，它自己会写一些
mock 代码构建模拟数据，如果不仔细看，很容易误认为真的跑通了。
- 在 AI 工作时，我们自己做什么？是看着它思考发呆，还是切换做其他事？能不能同时推进多个任务？这都不是能一刀切回答的。
比如写非常复杂的业务逻辑时，AI 可能只是个“体力工”，只干了重复性的活，我们需要关注每个实现细节。但如果解决的是一个单点、明确的需求，那就可以无脑交给 AI，我们只确保结果达标即可。至于如何区分“复杂”和“具体”，这就靠我们自己的专业能力了。
综上，从生产力维度分析，相关研究证实 AI 编程辅助工具在特定场景下能显著提升效率，尤其在重复性工作、生成基础框架、代码重构等环节。这使得团队能将更多精力聚焦于架构设计、方案规划等高价值工作。但也需警惕潜在风险，AI 生成的代码在安全性、异常处理、边界覆盖等方面可能仍存不足，这就要求团队建立对应的代码质量审核与保障机制。
4. AI 改变的是知识宽度，未必是深度
AI 编程助手的普及，正在重塑技术人员的知识边界，但这种改变更多体现在宽度上，而非深度。
所谓宽度，是指 AI 能快速填补技术人员跨领域、跨场景的知识空白，让原本专注单一领域的人，快速触及更多相关技能。例如，一个精通 Java 和 Spring 的后端程序员，借助 AI 可以快速生成前端 Vue 页面代码，了解移动端适配技巧，甚至完成简单的测试脚本，短期内就能独立负责小型全栈项目。
而深度，即对技术本质、底层逻辑的理解与掌控，仍需个人长期沉淀，AI 短期难以替代。当遇到前端复杂的性能优化、移动端底层兼容性问题，或后端框架的源码级 bug 时，AI 给出的往往是常规方案，无法解决核心痛点。此时，仍需要程序员凭借对技术原理的深度理解来拆解和优化问题。
同理，数据分析师能借 AI 快速掌握多种可视化工具，却未必能吃透统计模型的底层逻辑；运维工程师能靠 AI 快速排查常规故障，却未必能精通系统架构的核心设计。AI 像一本万能词典，能拓宽视野，却无法替代在某一领域的深耕细作。知识的深度，终究需要时间与实践的沉淀。
5. Agent 的场景和价值
在实践中，搭建一个基础 Agent 非常容易，但关键在于建立自己业务的评估体系：对于你的 Agent 经常执行的任务，该怎么量化评价每次执行结果的好坏？有了量化指标，才能谈优化。
至于以什么形式沉淀能力，如果你把 AI 定位为“临时工”，每次都是一锤子买卖（比如临时的代码助手），那么 Skill 和 Rule 比较合适；如果定位是“长工”，需要它自身成长，则还需要依赖记忆模块。一个成熟可用的 Agent 应该是：建立反馈闭环和自我优化机制。就像我们在投资中应用强化学习一样，只有 Agent 自身能完成有效的交易决策，才算是真正的落地。
同样，腾讯开发者的文章提到了一个很好的思路：结合元认知和本体论思想来设计 Agent，一方面依托本体知识库赋予 Agent 理解世界的能力，另一方面依托元认知赋予 Agent 对思考本身进行思考和进化的能力。
6. OpenClaw 成为现象级开源产品
截至 2026 年 2 月 21 日，OpenClaw 在 GitHub 上的星标已超过 21.5 万，且关注度仍在持续攀升。OpenClaw 是一款开源、本地优先、可执行任务的 AI 自动化代理引擎。它以自然语言指令驱动，在本地或私有云环境中完成文件操作、流程编排、浏览器自动化、多 IM 平台交互等任务，实现了从“对话式建议”到“自动化执行”的跨越。
与传统以“生成内容”为核心的对话式 AI 不同，OpenClaw 以“任务执行”为核心，通过“意图解析 → 任务规划 → 工具调用 → 结果反馈”的闭环，直接完成真实操作。在 AI 自动编程场景中，比如 trae 的 solo 模式，在解决某些特定问题时，trae 和 OpenClaw 可以做同样的事情。
某券商研报列举了通过 OpenClaw 可以落地的 17 种场景，涵盖信息获取、工具扩展、办公自动化、金融量化等多个方面。这让我想起之前看到的一个量化私募的 AI 投研计划：
- 产智 Agent：锚定投资方向，生成策略初步构想；
- 研能 Agent：结合多源数据，深挖因子与策略逻辑；
- 开发 Agent：基于端到端强化学习等 AI 技术，搭建策略模型；
- 落地 Agent：将模型转化为可执行的交易策略；
- 实盘 Agent：策略上线运行；
- 绩效 Agent：基于实盘表现反向优化模型，形成循环迭代。
OpenClaw 作为一个开创性的开源平台，其核心价值在于成功将大语言模型的认知能力与本地系统的执行能力深度融合。在证券投资领域，对于主动投研人员，它能大幅降低各类工具、数据和策略的构建难度；对于量化投研人员，它能高效完成因子研究、策略复现、组合测试等工作，大幅提升工作效率。
这值得每一位技术从业者关注和思考。技术的浪潮从未停歇，与其焦虑，不如躬身入局，在 云栈社区 这样的地方，与同行一起探索和驾驭这些新工具，找到属于自己的新定位。
发表于 前天 02:19
|
查看: 15|
回复: 0
