AI 时代,我认为比较重要的三个方向
一个前端开发者在 AI 浪潮里的观察与思考:数据是护城河、产品与平台的 Agent 化、AI 观测平台,以及 AI 给普通人带来的最大红利。
最近在学习和探索 AI 的过程中,有一些感悟想整理出来分享。
这不是方法论,也不是行业综述,只是一个前端开发者的真实观察,有些地方可能是错的,欢迎一起讨论。
前置洞察:找对方向,比卷具体实现更重要
在聊三个方向之前,先说一个个人感觉:很多 AI 化的东西,看似合理,其实是伪需求,或者迟早会被大模型的能力直接覆盖。
AI 发展太快了。我们在工程层面做的很多"补偿性"建设,本质上是在弥补模型当时的不足。但随着模型能力迅速提升,这些工程反而可能变成累赘——过多消耗 token 和上下文空间,并没有真正增加价值。
如何让那些加入的工程化内容,在模型能力提升的过程中自动化地退出和消亡,会越来越重要。这也是一个值得认真思考的问题。
我去年做的那些"无效工具"
去年我做了不少 AI 化的工具,当时觉得很有价值,现在回头看……
- 代码自动化 Code Review — 当时做的时候感觉很好,能帮团队自动检查代码质量。但现在各大平台(GitHub Copilot、Cursor 等)以及我们自己的代码仓库已经内置了更好的能力,我们做的那套反而是重复建设。
- 公共组件 AI 化集成 — 把常用组件包装成 AI 可调用的形式,出发点是对的,但模型现在理解代码上下文的能力已经足够强,这一层封装的必要性大大降低了。
- 项目脚手架 AI 化等等,类似的事情做了不少……
在当时来说这些可能是还不错的选择,但现在来看意义不是很大。这不是浪费,而是一种学费——让我更清楚地知道,什么方向才是不会被覆盖的。
另外分享一篇文章的核心观点,觉得很有共鸣:
大多数公司只是把 AI 硬接到现有流程上。整个工作流并没有变化,效率提升 10%~20%,但结构上没有任何改变,这只是 AI 辅助。AI-first 意味着,你要围绕"AI 是主要构建者"这一前提,重新设计流程、架构和组织。你不再问"AI 怎样帮助工程师",而是开始问"我们怎样重构一切,让 AI 负责构建,而工程师负责方向与判断"。快速写代码的能力每个月都在贬值,评估、批判并引导 AI 的能力则越来越值钱。
— 原文链接
当然以上在不同场景下并不全对,但确实值得深思。
方向一:数据是不会被覆盖的护城河
不管 AI 如何向前迭代,公司内部的数据,是模型永远无法获取训练的。
这是这个方向最根本的逻辑:AI 的能力是通用的,但数据是私有的。同样一个问题,通用模型给出的回答,和基于公司内部数据增强后的回答,差距是数量级的。
所以,我们不需要过多去做编码层面的优化,或者流程化的工程建设——如何优雅地梳理内部数据,然后把它交给 AI,才是当前内部基建最核心、最重要的事。AI 不管如何向前迭代,只要数据梳理得合适、持续更新,给到 AI,我们就能很方便地做很多事情。
数据梳理的四个层次
- 数据分层 + 结构化存储 — 以项目维度为起点,把数据向量化 + JSON 化,建立可供语义检索的知识底座。这是整个体系的地基。
- LLMWiki 动态更新 — 数据不是一次性的快照,而是要跟着业务持续演进。静态数据库会过时,动态维护才有长期价值。
- Graph 索引 — 向量检索有一个核心缺陷:语义相似但逻辑关系错误。Graph 索引补全了数据之间的关联关系,解决幻觉问题,让 AI 真正"理解"数据。
当前进展
和瑞峰以及组内一些同学,已经一起探讨并跑了一些 MVP 来验证方向。起点是项目维度的数据梳理——先以项目为单位,把数据向量化存储、做结构化的 JSON 化,同时结合 Graph 索引维护数据关系,用 LLMWiki 的机制来保证持续更新。
目前 MVP 已经有初步结果,接下来会持续完善。数据底座扎实了,上面的东西才能真正落地,而不是在沙滩上建楼。
方向二:产品与平台的 Agent 化
把产品或平台的能力包装成 Agent,我觉得是目前来看或许比较不错的方向。
但要坦诚地说:如何挖掘产品和平台,做出合适的 Agent 化,是比较考验个人产品能力和产品 Sense 的。我目前也没有特别好的方向,这是需要一起去探索的事情。
这里有几个值得想清楚的问题:
- 哪些产品场景,真的因为 Agent 化而变得更好?而不是"看起来很酷"?
- 哪些是伪需求,用户根本不需要,或者大模型能力提升后会直接覆盖?
- Agent 化的价值,应该让用户感受到效率提升,而不只是技术展示。
飞书 CLI 给了我很大的启发
最近深度使用了飞书的 CLI 工具,这让我看到了一种非常有意思的思路:把平台能力聚合,包装成 CLI 的形式提供出去。
这和传统意义上的"做一个 App"完全不同。它不需要 UI,不需要用户去学操作界面——你告诉 AI 你想做什么,CLI 就把平台的能力调用起来帮你完成。
除了 MCP Skills 这种方向之外,飞书 CLI 这种聚合平台能力、提供给 AI 调用的方式,或许是一个更值得探索的产品形态。可以是内部工具,也可以是开放出去的外部产品。
一个未来猜想
随着硬件和手机的升级,AI 手机和 AI 设备会越来越普及。在这个场景下,用户可能不需要打开一个个 App,而是直接和 AI 对话——AI 会去调用合适的 CLI 工具或接口来完成用户的需求。
也许有一天,产品不会以 App 的形式存在,而是以 CLI 这种形式存在,提供给 AI 手机来使用。
当然,这是猜想,不是判断。但提前往这个方向看一看、试一试,风险不大,潜在收益可能很大。
方向三:AI 观测——新时代的日志与告警
如果说数据是地基,Agent 化是应用,那观测就是整个体系的监控系统。
在传统开发体系里,日志和告警帮助我们快速找到问题、定位问题。AI 时代同样需要这样一套系统——帮我们观测 Agent 的行为,定位幻觉的成因,理解 Agent 在真实场景下的表现。
这个方向的定位非常清楚:不是锦上添花,而是必须有的基础设施。 没有观测,你不知道 Agent 在用户侧到底发生了什么。
为什么这件事比想象中难
Agent 在真实 C 端场景下,和我们个人测试时完全不一样。
我们测试的时候,会按照预设路径走,输入都是"正常的"。但真实用户的输入是极度随机的——他们会说奇怪的话,会走完全意想不到的路径,会触发我们从来没想过的场景。这和以前"点点点"的操作是完全不同的维度。
传统 log 是确定性的,一行日志对应一个确定的行为。但 Agent 的轨迹是概率分布的——同一个输入,不同时刻可能走完全不同的路径。
- 如何通用化地观测各类不同 Agent,是核心难题
- 如何判断哪次是"好的输出",哪次是幻觉,需要新的评估语义
- 幻觉的成因分析,比找到幻觉本身更难、更有价值
瑞峰已经在往这个方向做了一些工作,等数据这块做完之后,很期待能加入进去一起做这件事。
总结:三个方向,一个共同的底层逻辑
回过头来看,这三个方向其实都指向同一件事:找到那些不会被模型能力覆盖的、真正有长期价值的事情去做。
- 数据 — 内部数据是私有的,无论模型多强都无法替代。梳理好数据,就等于掌握了一个持续有效的杠杆。
- Agent 化 — 不是所有东西都值得 Agent 化。关键是找到那些真正能提升用户体验的场景,而不是为了 AI 而 AI。
- AI 观测 — Agent 上线之后,你需要一套眼睛,帮你看到用户侧真实发生了什么,快速定位和修复问题。
这三件事,是我现在认为前端和 AI 结合最值得投入的方向。当然这只是个人判断,欢迎大家一起讨论,我也可能是错的。
题外话:AI 给普通人最大的红利
有个问题想问大家:AI 时代对我们程序员最大的好处是什么?
我的答案是:极强的辅助学习能力。
去年一年的成长,比我前三年加起来还多(当然,我前三年确实有点混)。AI 把学习的门槛,从"你需要先建立完整的知识体系",直接降到了**「只需要有一个想法」**。
以前学一门新框架,要先看官方文档,搞懂配置,踩一堆坑才能起项目,时间成本很高,挫败感很强。现在,我直接告诉 AI:"用这个技术框架帮我跑一个 MVP",然后边做需求边学——学习速度快,而且每一步都有成就感,完全没有挫败感。
两个亲身经历
📦 新框架上手
我现在几乎不看官方文档了,直接告诉 AI 用某个技术跑一个 MVP,边学边做需求。速度快,成就感也大得多。
🍓 树莓派·一周
之前完全没接触过硬件,硬件对我是一个完全的黑盒。但我告诉 AI:"我想做一个语音控制的小车",它从怎么买材料、怎么刷机开始,一步一步教我。
不到一周,就用树莓派接入耳机,实现了语音输入输出——这是我大学时代就想做却不知道怎么入手的事情。
(代价:正负极接反,把屏幕插冒烟了……硬件还是有些门槛的。)
AI 的到来确实给了我们很大的危机感,但同样也给了我们非常大的机会。
这是一个让人既害怕又兴奋的时代。
评论区