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

推荐订阅源

宝玉的分享
宝玉的分享
T
Threat Research - Cisco Blogs
H
Hacker News: Front Page
N
News and Events Feed by Topic
Know Your Adversary
Know Your Adversary
Cisco Talos Blog
Cisco Talos Blog
SecWiki News
SecWiki News
C
Cisco Blogs
D
Darknet – Hacking Tools, Hacker News & Cyber Security
T
Tor Project blog
K
Kaspersky official blog
Forbes - Security
Forbes - Security
Webroot Blog
Webroot Blog
Schneier on Security
Schneier on Security
P
Privacy & Cybersecurity Law Blog
H
Heimdal Security Blog
Y
Y Combinator Blog
The GitHub Blog
The GitHub Blog
S
SegmentFault 最新的问题
V
Vulnerabilities – Threatpost
T
Tenable Blog
T
Tailwind CSS Blog
P
Privacy International News Feed
WordPress大学
WordPress大学
大猫的无限游戏
大猫的无限游戏
小众软件
小众软件
博客园 - Franky
Hacker News: Ask HN
Hacker News: Ask HN
Jina AI
Jina AI
C
Cybersecurity and Infrastructure Security Agency CISA
CTFtime.org: upcoming CTF events
CTFtime.org: upcoming CTF events
雷峰网
雷峰网
Vercel News
Vercel News
A
About on SuperTechFans
爱范儿
爱范儿
Simon Willison's Weblog
Simon Willison's Weblog
AWS News Blog
AWS News Blog
The Last Watchdog
The Last Watchdog
Engineering at Meta
Engineering at Meta
Spread Privacy
Spread Privacy
Security Archives - TechRepublic
Security Archives - TechRepublic
博客园 - 司徒正美
量子位
博客园 - 三生石上(FineUI控件)
J
Java Code Geeks
Hacker News - Newest:
Hacker News - Newest: "LLM"
Recorded Future
Recorded Future
H
Hackread – Cybersecurity News, Data Breaches, AI and More
Martin Fowler
Martin Fowler
Project Zero
Project Zero

人人都是产品经理

为什么你的产品找不到差异化?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

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

题图来自作者提供