人工智能
招人,才是最贵的技术决策
Posted by quentin 在 Saturday, 22 August 2026AI产品谁都能做,但谁来做判断?
Posted by quentin 在 Tuesday, 18 August 2026工程师的中间层正在消失
Posted by quentin 在 Friday, 14 August 2026不接受「事情就是这样」——聊聊第一性原理
Posted by quentin 在 Thursday, 13 August 2026产出翻倍,然后呢?
Posted by quentin 在 Thursday, 13 August 2026上周跟一个做技术管理的朋友吃饭,聊到一个让他头疼的事。
季度绩效评估,团队里有人用 AI 工具写了以前三倍量的代码,需求交付速度飞快。按传统标准,这绝对是高绩效。但他总觉得哪里不对。
"代码是写了挺多,但上线后 bug 也比以前多了。而且有些代码,他自己都说不清楚为什么这么写。"
这不是个案。当 AI 编码工具把"写代码"这件事的门槛拉到极低,传统的工程师绩效评估框架,基本上已经失效了。
以前的标准为什么不灵了
过去评估工程师,核心维度无非几个:代码质量、技术难度、问题排查能力、架构贡献。这些都建立在一个前提上——代码是人写的,写得好不好直接反映能力。
AI 改变了这个前提。
现在一个中级工程师借助 AI 工具,一天能产出以前三天的代码量。代码看着像模像样,命名规范、注释齐全、测试也有。但你仔细看,会发现有些实现绕了远路,有些边界条件没覆盖,有些设计决策——根本没有决策,AI 给了什么就用了什么。
产出的量上去了,但产出中"人"的含量变了。
资深工程师还值钱吗
Posted by quentin 在 Wednesday, 12 August 2026最近跟几个技术管理者聊天,发现一个有意思的现象:大家都在重新考虑招人的标准。
原因很简单——AI编码工具太强了。Cursor、Copilot、Codex这些工具,让一个中级工程师的输出量接近以前的高级工程师。团队不再缺"手快"的人,缺的是"能判断"的人。
这个变化,正在悄悄改变技术招聘的底层逻辑。
编码速度,曾经是硬通货
做了很多年技术,见过不少高P工程师的核心竞争力,说白了就是"手快"——需求来了能迅速出方案,别人三天的活他一天搞定。在编码为主的年代,这种能力确实值钱。
但这个优势正在被稀释。AI工具写得越来越像样,大部分情况下能直接给出80分的代码,改改就能用。当编码速度不再是瓶颈,手快的优势就没那么突出了。
这不是说技术能力不重要了,而是"会写代码"这个能力的市场价值在下降。就像Excel普及后,打字员这个岗位消失了一样。
资深工程师的真正壁垒
资深工程师的价值,从来就不只在写代码上。真正的壁垒是判断力——在信息不完整、约束条件模糊时做出正确选择的能力。
举个常见场景:系统选型,三个方案各有优劣,参数对比AI可以做,但最终选哪个,要考虑合规要求、团队技术储备、未来三年的业务增长方向。这些判断依赖经验和对业务的理解,AI帮不上忙。
什么是AI Native
Posted by quentin 在 Tuesday, 11 August 2026什么是 AI Native
过去两年,大多数公司做的事情是"AI+"——在已有产品上叠加一层 AI 能力。搜索加个对话框,客服加个机器人,IDE 加个 Copilot。本质上,产品架构没变,AI 只是一个插件。
AI Native 完全不同。它不是"给产品加 AI",而是"用 AI 重新定义产品"。
区别在哪里?
- AI+ 产品:传统搜索引擎 + AI 摘要 = 还是搜索引擎
- AI Native 产品:Perplexity = 答案引擎,搜索这个概念本身被重新定义了
前者是增量优化,后者是范式转移。
AI Native 的三个核心特征
1. 交互范式的重构
传统软件的交互模型是命令式的:用户点击按钮、填写表单、执行操作。每一步都需要用户理解系统的抽象模型。
AI Native 产品的交互模型是意图式的:用户表达目标,系统理解意图并执行。用户不需要知道系统内部有多少模块、多少步骤。
从聊天到成交
Posted by quentin 在 Sunday, 9 August 2026飞猪上周发了新一代 AI 产品 V10,定位是"消费 Agent"。大部分报道的标题集中在"AI 帮你订机票"上,但我觉得真正值得技术管理者关注的,不是这个产品本身,而是飞猪 CTO 陈烨在评测会上抛出的一个判断:当前 AI 行业的价值高度集中在模型和算力层,应用层还没有出现足够多能承接价值的产品。
翻译成大白话就是:模型越来越强,但能用模型把事真正办完的产品,还是太少了。
这个问题我在金融科技领域也反复遇到。不少团队做智能客服、智能投顾,Demo 做出来很漂亮,聊天界面里 AI 对答如流。但用户真正需要的不是"被回答",而是"被解决"。从"问答"到"交易"之间,隔着一条远比想象中宽的鸿沟。
Coding Agent 为什么先跑通了
陈烨提到一个观点,我觉得说到了问题的本质:Coding Agent 之所以率先找到产品市场匹配,不是因为写代码比做业务简单,而是因为代码世界有一个天然的验证闭环——代码能不能跑、测试通不通得过,答案是确定的、即时的。
谁在真正驾驭AI
Posted by quentin 在 Friday, 7 August 2026团队全面接入AI编码工具三个月了。表面上看,大家都在用Copilot、Cursor,代码产出量几乎翻倍。但最近我开始有一种不安:这种繁荣是真的吗?
事情起因是上周的代码审查。一个资深同事的代码,风格和架构都挺好,但AI生成的痕迹很重。另一个年轻同事,产出数字不太好看,但每段代码都看得出是思考过的。
我突然意识到,自己犯了一个管理错误:把工具使用量当成了能力指标。
用得最多,不等于用得最好
大部分团队在推广AI工具时,管理者都会看一个数字:采纳率。多少人用了?用了多少次?代码生成占比多少?
这些指标容易量化,向上汇报也好听。但它们掩盖了一个事实:用得多不代表用得好。
我的观察是,团队在使用AI工具时,大致分成了三类人:
第一类:喂料型。把需求描述扔给AI,拿到结果复制粘贴。代码能跑就行,不深究实现逻辑。这类人看起来产出很高,但代码质量和架构一致性埋了不少隐患。
第二类:对话型。会反复调整prompt,审查AI的每一行输出,根据自己的理解做修改和取舍。产出速度不一定最快,但代码质量稳定,出了问题能自己排查。