惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

D
Docker
AI
AI
博客园 - 三生石上(FineUI控件)
腾讯CDC
freeCodeCamp Programming Tutorials: Python, JavaScript, Git & More
Y
Y Combinator Blog
大猫的无限游戏
大猫的无限游戏
H
Hackread – Cybersecurity News, Data Breaches, AI and More
雷峰网
雷峰网
NISL@THU
NISL@THU
S
Schneier on Security
T
Threatpost
T
Tenable Blog
Application and Cybersecurity Blog
Application and Cybersecurity Blog
IT之家
IT之家
宝玉的分享
宝玉的分享
T
Tailwind CSS Blog
C
Cybersecurity and Infrastructure Security Agency CISA
P
Privacy & Cybersecurity Law Blog
I
Intezer
Microsoft Azure Blog
Microsoft Azure Blog
月光博客
月光博客
T
Threat Research - Cisco Blogs
SecWiki News
SecWiki News
AWS News Blog
AWS News Blog
博客园 - Franky
钛媒体:引领未来商业与生活新知
钛媒体:引领未来商业与生活新知
P
Proofpoint News Feed
V
V2EX
Recorded Future
Recorded Future
Microsoft Security Blog
Microsoft Security Blog
S
Secure Thoughts
Google DeepMind News
Google DeepMind News
MongoDB | Blog
MongoDB | Blog
Apple Machine Learning Research
Apple Machine Learning Research
Project Zero
Project Zero
PCI Perspectives
PCI Perspectives
G
GRAHAM CLULEY
Help Net Security
Help Net Security
Cloudbric
Cloudbric
Recent Announcements
Recent Announcements
V
Visual Studio Blog
Hacker News: Ask HN
Hacker News: Ask HN
N
News and Events Feed by Topic
C
CERT Recently Published Vulnerability Notes
The Cloudflare Blog
Forbes - Security
Forbes - Security
C
Cisco Blogs
O
OpenAI News
www.infosecurity-magazine.com
www.infosecurity-magazine.com

人人都是产品经理

为什么你的产品找不到差异化?90%的失败都卡在第一步上(下) – 人人都是产品经理, 3年从30万到1300万用户、获2200万美元融资,这个AI教育产品用“抽卡”破解了获客难题 – 人人都是产品经理, 园区招商系统怎么做才能真正帮到去化?我加了这一个功能,推广链接转发400次阅读过万 – 人人都是产品经理, AI大事件:OpenAI发完网络安全模型又搞药物研发,小鹏汽车要抓”DeepSeek时刻” – 人人都是产品经理, 电商不是卖货,是一场更残酷的产品经理实战 – 人人都是产品经理, 没想到,活动营销又回来了! – 人人都是产品经理, 为何All-in海外KOC:一场关于AI时代窗口期的豪赌 – 人人都是产品经理, 重新理解企业的内部协作 – 人人都是产品经理, 苹果的 AI 战略到底是什么? – 人人都是产品经理, 医疗智能体·第2讲——合规护城河:等保、PIPL与HIPAA的架构实战 – 人人都是产品经理, 向量知识库五步法:从“答非所问”到“精准回复” – 人人都是产品经理, 鸿蒙PC三方库构建总指挥HPKBUILD(sha)库为例 – 人人都是产品经理, 何时该用LLM?AI产品经理的LLM设计指南 – 人人都是产品经理, 医疗信息领域的需求方、决策方、准入方以及关注点(二) – 人人都是产品经理, 即梦涨价:一场被误读的「傲慢」 – 人人都是产品经理, 面试AI PM必答题:Hermes和OpenClaw的区别,如何讲清楚业务价值 – 人人都是产品经理, AI的下一张船票:世界模型——AI产品经理必须理解的技术拐点 – 人人都是产品经理, 小红书做GEO,怎么让AI信你?记住这 3 个重要信息 – 人人都是产品经理, 5 家印度 AI 初创公司,看看印度 AI 再做什么 – 人人都是产品经理, AI项目跨团队协作:产品技术业务如何不打架 – 人人都是产品经理, Agentic Workflow(智能体工作流):让AI从”答案生成器”变成”数字员工” – 人人都是产品经理, lycium_plusplus 项目全景解读:OpenHarmony 三方库构建的“大管家” – 人人都是产品经理, 从爆单救火到前置履约:两套预采策略,把生鲜大促履约效率拉满 – 人人都是产品经理, 什么时候该补货?我用一轮数据做了一个决定 – 人人都是产品经理, 从“机械兜底”到“动态分流”:AI客服重复进线治理的4大底层逻辑 – 人人都是产品经理, 抖音拼效率,红书拼洞察 – 人人都是产品经理, 全民狂欢与退潮——为什么龙虾这波热潮冷却得如此之快? – 人人都是产品经理, Stripe押注!MPP重塑全球支付 – 人人都是产品经理, 小红书GEO:AI引用你的内容,不是因为你对,而是因为你看起来可信 – 人人都是产品经理, 前百度副总裁押注办公Agent,日韩付费爆发,Manus迎来强劲对手 – 人人都是产品经理, 企事业单位数字化的业务供需本质 – 人人都是产品经理, 医疗智能体·第1讲——医疗信息化重构:从“辅助软件”到“自主智能体”的范式转移 – 人人都是产品经理, 粉丝量就是空气!!! – 人人都是产品经理, 用户说“薯片碎了”,机器回“要买吗?”:意图识别的翻车与破局 – 人人都是产品经理, RAG召回准确率从75到90 我做对了这三件事 – 人人都是产品经理, AI大事件:Anthropic改收费、OpenAI发安全版、手术机器人纳入医保、阿里发布”秒悟” – 人人都是产品经理, Chrome 推出 Skills 新功能,Agent 重塑上网方式 – 人人都是产品经理, GitHub前创始人拿了a16z的1700万美元,做Agent时代的Git – 人人都是产品经理 拷贝或克隆其他 Flutter OH 项目到本地后无法运行 – 人人都是产品经理, 优惠券设计:优惠券创建 – 人人都是产品经理, 不用死磕文档!AI 助手 1 小时搞定飞书 CLI 安装 + 配置 + 知识库 – 人人都是产品经理, 用小龙虾做竞品分析报告:从2天到20分钟,我是怎么做到的 – 人人都是产品经理 用小龙虾做市场分析报告:搞懂这3个公式,市场规模不再靠猜 – 人人都是产品经理, 你早就在做 Harness 工程,只是不知道它叫这个名字 – 人人都是产品经理, Think Long就够?你可能想多了! – 人人都是产品经理, 货代SRM实战:供应商准入怎么做,才能让资源池不是通讯录而是可交付网络? – 人人都是产品经理, 如何做好用户调研?详解基本技巧 – 人人都是产品经理, 木鸟、途家、美团对打,平台春天行动开“卷” – 人人都是产品经理, 入职才发现公司不靠谱?小红书从业者求职避坑指南 – 人人都是产品经理, 美国 AI 三巨头联手封堵,中国 AI 突围之路在何方 – 人人都是产品经理, 小红书,放在需求对面的镜子 – 人人都是产品经理, AI 会带来大规模失业吗? – 人人都是产品经理, 从出单到补货前,我第一次犹豫:该不该放大? – 人人都是产品经理, Flutter 三方库鸿蒙化适配:5 种高效检查方式,快速判断是否需要适配 – 人人都是产品经理, 从做产品进阶拿结果:医美机构产品经理转岗科室运营经理 – 人人都是产品经理, 阿里HappyHorse,一场关于“Token经济”的阳谋 – 人人都是产品经理, To B AI:客户留存落地的观察与思考 – 人人都是产品经理, AI产品的“生命线”——数据采集、标注、清洗的产品化设计 – 人人都是产品经理, 谈谈AI Agent(二):当“孩子”能自己“体验世界”时,你该学什么? – 人人都是产品经理, UI/UX设计师的3层能力进阶,前两层让你活下来,第三层…才是真正的分水岭 – 人人都是产品经理, 2分钟 → 30秒,效率提升75%:B端产品经理如何用「规则枷锁」驯服AI幻觉? – 人人都是产品经理, 还没来得及学OpenClaw,来了个更猛的:Hermes Agent – 人人都是产品经理, AI日报:宇树机器人跑出10m/s刷新世界纪录 – 人人都是产品经理, 一文说透基金互金如何用情绪价值引导用户决策做转化 – 人人都是产品经理, 当浏览器开始替你”看”网页:AI 浏览器正在亲手拆掉它脚下的那张网 – 人人都是产品经理, 0代码,一天时间我Vibe Coding了个网站 – 人人都是产品经理, Hermes 和 OpenClaw 之争,Agent 的能力应该“装上去”还是“长出来”? – 人人都是产品经理 视频生成的“桌子”,字节Seedance 2掀完,阿里快乐马掀 – 人人都是产品经理, 从听不懂到完全信任:我的 Codex 深度产品体验 – 人人都是产品经理, 当虚拟偶像有了北京户口,与真人偶像还有什么区别? – 人人都是产品经理, 会说,远远比会做更重要 —— 对 SBTI 爆火现象的五层观察 – 人人都是产品经理, AI产品经理必看:当“搭环境”比“选模型”更重要,你的认知还在2024年吗? – 人人都是产品经理, 2026年AI产品商业化核心逻辑:从功能demo到规模化营收的3个必破卡点 – 人人都是产品经理, 京东围绕供应链,卷起裤腿下场的那些事儿 – 人人都是产品经理, SBTI一夜刷屏:它赢在了“太会说人话” – 人人都是产品经理, 折扣零售的真相:不是便宜,而是价值感! – 人人都是产品经理, 和甲方吵了一架,最后加钱做了——我学到的ToB产品经理生存法则 – 人人都是产品经理, 和几位小红书操盘手聊了8小时,干货全在这 – 人人都是产品经理, 智谱GLM-5.1登场,开源模型首超Opus4.6!!! – 人人都是产品经理 Anthropic收入凭什么反超OpenAI,终于有人把这事说清楚了 – 人人都是产品经理, 史上最有故事感的技术报告——Claude最强模型Mythos 7个极其精彩的细节 – 人人都是产品经理, 模型不是壁垒,Harness 也不是 – 人人都是产品经理, 抖音本地生活业务思考21 – 人人都是产品经理, Superpowers:145k Star的AI编码框架,到底是什么来头? Superpowers:145k Star的AI编码框架,到底是什么来头? – 人人都是产品经理, OpenAI 的路走错了,Anthropic Harness 解法启示:模型需要实践专科生 – 人人都是产品经理, 画原型图的前一步:设计站点地图 – 人人都是产品经理, 给 DeepSeek 的最后一封催更信 – 人人都是产品经理, 手把手教你用 Claude Code 搭建 AI 营销团队:5 个 Agent、12 项技能,独立完成研究、写作、设计全流程 – 人人都是产品经理, 你以为大模型在学语言?不,它在重新发明语言学 – 人人都是产品经理 所谓Skill,不过是AI时代的工业垃圾 – 人人都是产品经理, 聊一聊内容传播的几个方法 – 人人都是产品经理, 当平台开始吃掉生态:从 OpenClaw 被封杀,读懂 Anthropic 的这盘棋 – 人人都是产品经理, 你装了 10 个 AI 插件,Obsidian 还是一个文件夹 – 人人都是产品经理 关于AI智能体架构演进的系统性思考:从单体试水到多体协同的重构 – 人人都是产品经理, 当“人”变成Skill,我们又该何去何从? – 人人都是产品经理 Mythos 事件:前沿 AI 治理的意外实验 – 人人都是产品经理, 货代CRM:信用与风险管理怎么做,才能把坏账风险拦在放货之前? – 人人都是产品经理, 从HR收集自拍照到员工自助录入——我见证了园区人脸识别从”不可用”到”真好用”的全过程 – 人人都是产品经理 千问闯关AI混沌期:阿里画靶,吴嘉张弓,马云射箭? – 人人都是产品经理,
YC 合伙人:AI 原生公司应该怎么搭建 – 人人都是产品经理,
张艾拉 · 2026-05-09 · via 人人都是产品经理

AI 原生公司的未来已经到来,但真正变革的不仅是工具层的效率提升,而是公司运作机制的彻底重构。YC 合伙人 Diana Hu 揭示了从信息路由到组织架构的颠覆性改变:当 AI 成为公司的操作系统,中层管理将如何被重新定义?闭环系统如何让企业经验不再流失?创业公司又该如何抓住这波组织范式迁移的红利?

假期了,有时间好好看看播客,今天分享 YC 合伙人的一期讲 AI 原生公司该如何搭建和管理的播客。

Diana Hu在这期 Startup School 里讲的重点可以概括成:

AI 带来的变化,不只是团队更高效,而是公司本身应该被重新设计。

她的判断是:AI 不应该只是公司里某个工具,而应该变成公司运行的底层系统。

公司里的会议、需求、销售、客户反馈、研发排期、招聘、运营数据,都应该被记录下来、结构化起来,并且持续被 AI 读取、分析和反馈。

Diana Hu 讨论的是如何让公司变得“可查询”,让智能体能在各个职能里持续改进,以及为什么传统管理层级会被新的智能层替代。

这句话听起来又是个宏大话题,但如果拆开看,其实还挺具体的。

过去公司管理靠人传信息:

员工汇报给主管,主管汇总给负责人,负责人再同步给老板。信息一层层往上传,一层层往下分。

这个过程慢,而且一定会丢失信息。

现在 AI 可以做另一件事:把公司每天产生的工作痕迹直接“吃”进去。

不是等人开会汇报,而是让系统自己知道:

这个需求为什么排期、客户反馈了什么、销售承诺了什么、工程师实际交付了什么、哪些事情卡住了、下一步应该怎么调整。

这才是她说的 AI 原生公司:

不是每个人都用一个 AI 助手,是公司有了一个可以持续理解业务、持续更新状态、持续推动决策的中枢系统。

01 AI 真正改变的,是公司怎么运转

现在很多公司用 AI,还是在给原来的工作流打补丁:

写文档慢,就用 AI 写文档;代码写得慢,就用代码助手。

客服回复慢,就上客服机器人;会议纪要没人整理,就开个 AI 会议记录。

这些都有用,但都还停留在工具层。

原来的组织结构、工作方式、决策链路没有变,只是每个环节稍微快了一点。

Diana Hu 认为,这个理解太浅了。

她在播客里说,AI 的重点不是让已有流程快一点,而是带来新的能力。

一个会用 AI 的人,现在可以做过去一个小团队才能完成的事情,甚至可以做以前根本做不了的事情。

这会改变公司最底层的设计逻辑。

过去公司要做一件事,通常靠加人。研发不够就招工程师,销售不够就招销售,管理跟不上就加主管,信息太乱就加项目经理。

AI 之后,公司不一定要先加人,而是要先问:

这件事能不能被系统记录?能不能被 AI 理解?能不能形成反馈?能不能越跑越准?

这也是她说的AI 要成为公司的操作系统。

这个说法可以说得更直白一点:

厉害的 AI 公司,不只是产品里有 AI,而是公司自己也是用 AI 跑起来的。

02 公司要从“开环”变成“闭环”

Diana Hu 用了一个很重要的概念:闭环。

开环的意思是,公司做了一个决定,执行完了,但结果没有被系统性记录,也没有反过来改进流程。

很多公司其实都是这样运转的。

开会讨论一个需求,产品写文档,研发排期,销售去跟客户沟通,客户反馈散落在邮件、微信群、Slack、飞书、CRM、会议纪要里。

最后项目做完了,大家可能复盘一下,也可能根本没复盘。

下一次再做类似事情,又重新来一遍。

问题不是大家不努力,而是信息没有真正沉淀下来。公司每天都在产生经验,但这些经验没有变成系统能力。

闭环公司不一样。

每一次沟通、每一个需求、每一次客户反馈、每一轮开发、每一个结果,都应该变成系统可以读取的材料。

AI 能看到输入,也能看到输出,还能看到中间过程。这样它才知道什么做对了,什么做错了,下一次该怎么调整。

这件事听起来像管理方法,实际上是公司能力的差别。

一个开环公司,靠人传递经验;一个闭环公司,靠系统沉淀经验。

人会离职,会忘记,会理解偏差;系统如果设计得好,会持续积累,而且越用越完整。

所以 Diana Hu 提到,AI 原生公司要让每一个重要流程都形成闭环:

信息被捕捉,结果被反馈,流程被改进。

03 公司要变得“可查询”

播客里反复提到一个关键词:queryable,我觉得中文可以理解成:公司要变得可查询。

这不是说公司要多做几个数据库,也不是简单地把文件放到知识库里。

它的意思是,公司每天发生的重要事情,都要让 AI 能看懂、能调用、能分析。

比如会议不要只靠人记脑子里,要有记录。

重要讨论不要散落在私聊里,要尽量进入公开频道或可检索系统。

客户反馈不要只停留在销售的个人理解里,要进入系统。

研发排期、需求变更、产品规划、上线结果、客户投诉,都要变成 AI 可以读取的材料。

Diana Hu 举了一个研发管理的例子。

如果一个智能体能看到 Linear 里的任务、Slack 里的工程讨论、客户邮件里的反馈、GitHub 里的代码变化、Notion 或 Google Doc 里的规划、销售电话记录、每日站会内容,它就可以分析上一轮迭代到底交付了什么,是否真的满足了客户需求。

下一步,它还可以帮团队提出更准确的研发计划。

这件事对创业公司很重要。

过去研发管理很依赖中间层:项目经理追进度,主管开会问状态,负责人再向上汇报。

每一层都在做信息压缩,信息压缩一定会失真。

客户原本表达的是“这个功能影响采购决策”,传到产品那里可能就变成“客户想要这个功能”;

再传到研发那里,可能只剩一个任务标题;做到最后,大家以为交付了,客户并不觉得问题解决了。

如果公司是可查询的,AI 可以直接看到更多上下文。

它不只看任务,也看客户原话、销售场景、需求来源、历史承诺、实际交付结果。

这样,管理就不再只是“问进度”,而是系统能更早发现问题。

谁卡住了,哪里偏了,客户真实需求有没有被误读,下一轮排期是否合理,这些都可以提前浮出来。

Diana Hu 说,她看到一些团队用这种方式把工程迭代周期缩短一半,在同样时间里完成接近 10 倍的工作量。

这个数字来自她在播客里的观察表述,更适合理解为 YC 视角下的创业公司案例经验,不宜当成严格行业统计。

也就是说:信息越完整,AI 越有用;公司越可查询,执行越快。

04 “软件工厂”会改变产品开发方式

Diana Hu 还提到一个正在出现的新模式:AI 软件工厂。

这个概念可以说得简单一点:

人负责定义要做什么,AI 负责把代码写出来、跑测试、反复修改,直到结果符合要求。

过去写软件,核心动作是工程师写代码。

现在更高效的方式可能是:人先写清楚需求规格和测试标准,告诉系统什么叫成功,然后让 AI 智能体生成实现方案、写代码、跑测试、修 bug。

人主要负责判断方向和验收结果。

这和测试驱动开发有点像:

以前是工程师先写测试,再写代码让测试通过;现在是人写规格和测试,AI 写代码和迭代。

这会让工程师的工作也发生变化。

以前厉害的工程师,是自己能写很多高质量代码。

以后厉害的工程师,更像是能设计好问题、拆清楚系统、写出准确测试、调动一组 AI 智能体完成开发。

代码本身的重要性还在,但人的价值会更多前移到“定义目标”和“判断质量”。

这也是为什么她提到“1000 倍工程师”。

这个说法听起来夸张,但它想表达的不是某个人突然变成超人,而是一个工程师身边有了一整套智能体系统:

一个写代码,一个跑测试,一个查文档,一个改接口,一个做验证,一个持续迭代。

人不再是单独写代码,而是在指挥一条自动化生产线。

这样一来,一个人能做的事就变多了。

这对创业公司尤其关键。以前一个早期团队可能因为工程人手不够,很多想法只能排队。

现在,如果团队能把规格、测试、反馈和部署流程组织好,产品试错速度会快很多。

但这里也有一个前提:公司本身得有足够清楚的流程和足够好的上下文。

AI 不是凭空变强的。

你给它一堆模糊需求,它只能产出一堆看似能跑、实际不一定好用的东西。

你给它明确目标、真实客户反馈、清晰测试标准、完整上下文,它才可能像一个可靠的生产系统。

所以软件工厂的本质,不是 AI 自动写代码这么简单,它要求公司先把产品开发过程变得更清楚。

05 中层管理最先被重新定义

我认为这期播客里最有冲击力的部分,是她对组织结构的判断。

Diana Hu 认为,如果公司已经足够可查询,信息都能被 AI 读取和分析,那传统中层管理的很多价值会下降。

更准确地说,是很多管理动作会被系统拿走。

过去中层管理做什么?

收集信息,整理信息,开会同步,判断优先级,向上汇报,向下分配,协调资源,提醒进度。

这些动作的核心,其实是信息路由。

公司越大,信息越复杂,就越需要人站在中间转发、压缩和解释。

但如果 AI 能持续看到公司里的真实工作状态,很多信息路由就不需要靠人一层层传了。

传统层级组织本质上是为了解决信息协调问题。

现在 AI 第一次有机会维护一套持续更新的公司运行模型,并承担过去由管理层级完成的信息协调功能。

也就是说,AI 不只是提高效率的工具,而是一个能理解公司运转、协调工作流的系统。

以后公司里可能会更强调三类人:

第一类是直接做事的人。

不只是研发,销售、运营、客服、市场都要能直接使用 AI 工具,把想法做成东西。

以后开会不应该只带 PPT,而是带原型、带数据、带已经跑起来的方案。

第二类是对结果负责的人。

这个人不是传统主管,不是每天盯大家进度的人,而是对一个明确结果负责。比如某个客户增长指标、某条产品线、某个交付结果。

责任要清楚,结果要可衡量,不能藏在层级后面。

第三类是 AI 原生的创始人或负责人。

这类人不能只在嘴上说重视 AI,然后把 AI 战略丢给下面的人。

他自己要用,要试,要知道工具能做到什么程度,也要让团队看到新的工作方式到底长什么样。

这对创始人要求很高,因为 AI 原生公司不是买几个工具就能建成的。

它需要创始人亲自改变公司怎么开会、怎么写需求、怎么记录信息、怎么评估结果、怎么招人、怎么设岗位。

如果老板自己还按旧方式工作,公司很难真的变成 AI 原生。

06 未来拼的可能不是人头,而是 token

Diana Hu 在播客里有一个说法很有意思:公司应该最大化 token 使用,而不是最大化员工人数。

这句话换成更直白的话,就是:

以后公司要敢于把钱花在模型调用和自动化系统上,而不是一有事情就加人。

过去公司 API 账单太高,老板会紧张。

但如果这些调用替代的是一个更大的工程团队、设计团队、运营团队、行政团队,那高 API 账单未必是坏事。

它可能说明公司正在用系统能力替代一部分组织膨胀。

这对早期公司尤其重要。

创业公司最怕的不是人少,而是人多以后动作变慢。

人一多,会议变多,沟通变多,管理变重,很多精力消耗在同步和协调上。

AI 原生公司的理想状态,是用更小的团队完成更大的产出。

这不是简单地压缩人力成本,而是改变资源配置方式。

以前你要做一个功能,可能要产品、设计、前端、后端、测试、项目经理一起排期。

现在一个会用 AI 的人,可能先做出可运行原型,再让系统补代码、跑测试、生成文档、整理反馈。

团队当然还需要人,但人的数量和结构会变。

少一些纯传话、纯协调、纯整理的人;

多一些能定义问题、调动工具、判断结果、直接推进业务的人。

这件事对很多公司会很难,因为它不只是工具升级,而是岗位价值重估。

07 大公司很难,小公司反而有机会

Diana Hu 最后讲到一个很重要的判断:早期创业公司在这件事上有天然优势。

原因很简单,大公司有历史系统,有组织惯性,有几千几万人要培训,有已经跑了很多年的流程。

任何一个核心流程改动,都可能影响现有业务。

所以大公司即使用 AI,也经常只能先从局部开始:某个团队试点,某个流程自动化,某个部门上工具。

但早期公司没有这些包袱。

一家公司刚开始,就可以把所有工作流按 AI 原生方式设计:

会议怎么记录,客户反馈怎么进入系统,研发任务怎么和销售信息打通,所有结果怎么沉淀,AI 智能体怎么参与日常工作。

这件事越早做,越容易。

如果公司已经有 500 人,再想让大家少用私聊、多留记录、所有流程可查询、所有决策有反馈,难度会非常高。

如果公司只有 5 个人、10 个人,从第一天就这么干,反而很自然。

所以 AI 原生公司最早出现的地方,很可能不是大公司的转型部门,而是新一代创业公司。

它们没有老系统要维护,没有复杂层级要安抚,也没有太多“以前我们都是这么做的”。

它们可以直接用新的方式搭公司。

08 这件事对普通公司也有启发

这篇内容虽然讲的是创业公司,但对很多普通公司也有参考价值。

不管你是不是 AI 公司,接下来都要面对一个问题:

公司的经验,到底沉淀在人身上,还是沉淀在系统里?

  • 如果一个客户为什么成交,只有销售知道;
  • 如果一个产品为什么延期,只有项目经理知道;
  • 如果一个需求为什么被砍,只有老板记得;
  • 如果一次失败为什么发生,没人记录,也没人复盘;

那这家公司再买多少 AI 工具都没用。

因为 AI 没有上下文。

它不知道公司发生过什么,也不知道过去哪些判断对、哪些判断错,更不知道下一次应该怎么改。

真正要做的是把公司变成一个能被理解的系统:

  • 重要事情尽量留下记录;
  • 关键过程尽量形成结构;
  • 客户反馈尽量进入统一系统;
  • 决策和结果尽量能对应起来;

让 AI 不只是帮你写东西,而是能读懂你的业务。

这一步很基础,但也很难,因为它要求公司改变很多习惯:

少一点口头同步,少一点私聊决策,少一点只靠人脑记忆,多一点过程记录,多一点结果反馈,多一点系统沉淀。

AI 原生公司,听起来像一个很新的概念,但落到执行上,其实就是一件事:

公司每天产生的经验,不能再白白流失。

09 AI 原生公司的核心,是重新分配人的位置

AI 对公司的影响不只是写代码、写文案、做客服。

它会影响公司怎么流动信息,怎么做决策,怎么分配责任,怎么定义岗位,怎么判断一个人有没有价值。

过去,公司靠层级组织人。

以后,公司可能靠智能系统组织信息,再让人站在更靠近业务和客户的位置上。

这会带来一个很明显的变化:

公司不再奖励“我知道很多信息,所以我有价值”。

公司会更奖励“我能定义问题、推动结果、判断质量,所以我有价值”。

这对很多人是不舒服的。

因为过去很多岗位的安全感,来自信息差、流程控制和协调位置。

AI 把信息打平以后,这些位置会变薄。

但对真正能做事的人,这是机会。

  • 一个销售可以带着 AI 做客户研究、生成方案、跟进线索、复盘成交。
  • 一个运营可以搭自动化流程、监控数据、发现异常、推动改进。
  • 一个产品经理可以直接做原型、写规格、跑测试、整理反馈。
  • 一个工程师可以同时调动多个智能体写代码、查问题、补测试、做验证。

每个人的边界都被打开了。

但前提是,公司要允许这种变化发生。

如果公司还是老流程、老汇报、老审批、老层级,AI 只能变成一个更快的文档工具。

如果公司愿意从底层重做,AI 才可能真的变成新的组织能力。

这也是 Diana Hu 这期播客真正想说的事:

AI 原生公司,不是把 AI 加进公司,是用 AI 重新搭一家公司。

以上,祝你今天开心。

作者:张艾拉 公众号:Fun AI Everyday

本文由 @张艾拉 原创发布于人人都是产品经理。未经作者许可,禁止转载

题图来自作者提供