这是一篇基于某位产品负责人 7.5 万字内部复盘长文《置身钉内》的精华摘录。原文记录了一位产品经理入职某头部企业协作平台 300 多天，全程参与一款战略级 AI 产品从核心保密期到发布会高光，再到收缩运营的完整过程。

原文太长，不适合直接发布。我从中提炼出 12 条产品启示，涵盖 AI 落地、用户定位、敏捷开发、组织管理等维度。每一条都来自真实战场的血泪教训。

启示一：智能是平权的，但 context 是不平权的

LLM 本身没有偏见，谁调都能用。但 LLM 要有效服务，有两个条件：

1. 必要条件：足够的数据基建和 context
2. 充分条件：用户想要消费的对象本身，最好是 LLM 生产的产物

在电商场景里，用户最终要的是"更好"或"更有性价比"的商品，LLM 只是一个路径。AI 可以加速体验，但不会动摇"商品"这个本质。

而在企业协作场景里，AI 会真正颠覆人们组织办公的方式。因为这里的信息流本身就是工作内容——消息、日程、待办、文档、审批，这些恰恰是 LLM 最擅长处理的文本和结构化数据。

有 context，才能判断用户的背景和偏好，才能提供用户想消费的商品/服务/内容。

这也是为什么掌握真实工作现场的产品，天然比一个单独的聊天机器人更有机会。

启示二：发心决定产品的基因

产品也有产品的"发心"，就是它的发起人最原始的出发点：

• 解决某个尚未被解决的具体问题
• 提升解决某个问题的效率
• 服务好某个具体的人群
• 推广某种理念
• 销售某种资源

越靠前的发心，越有可能诞生有历史价值的产品，因为发心越纯粹。

虽然产品会混合多种发心，但好产品只有一个主发心。大道至简，这和投资人提倡的"一句话说清产品价值"异曲同工。

当一个产品的发心又多又没有主次的时候，就会成为一个贪心而焦虑的产品。贪心是七宗罪之一。什么都想要，容易什么都得不到。

启示三：定位是捆柴的绳

发心是起念，是马丁路德金的 “I have a dream”，发散，抒情。一个产品真正进入开发，要回答的不是"想做什么"，甚至不是"要做什么"，而是"先做什么"。

如果把一个产品从虚到实的过程比作拾柴点火，发心是选柴，定位就是捆柴的绳。 柴选得好，只说明有得烧；捆不好，设计进来就是到处点火，看着热闹，风一吹就散。

说清产品定位，需要明确回答四个问题：

当这四个问题能一句话说清时，产品才有了清晰的定位。

启示四：老板和员工，服务谁？

企业协作平台上，老板和员工是截然不同的画像：

• 管理者：工作的发起者，需要对接更多员工，督办、催办完成任务；有大量日程，处理审批，布置待办。
• 员工：承接方和任务完成方。打卡考勤，接受监督，提出审批请求，完成待办。

面对两种不同的用户画像，先服务好谁的诉求，必须有所取舍。

先服务员工，是因为目标是大 DAU 和高频用户操作。如果只服务"塔尖"用户，就达不成带量或卖 tokens 的目的。

但为什么要服务老板呢？因为企业购买 SaaS 产品的本质，就是为了更好地组织和管理自己的员工。同时，信息枢纽绝大多数还是管理层——他们有最多的 IM 消息、日程、待办、审批。

一个产品如果带着"薛定谔的用户"出发，后面的设计、用户反馈和开发节奏，处处都会失焦。

启示五：发信人立场 vs 收信人立场

企业协作产品有一个根本性的分野：

• 微信的立场是"收信人"：为了保护收信人不受打扰，可以克制地不做已读未读，不做强触达。
• 某协作平台的基因从诞生第一天起，就是站在"发信人"立场、为"发信人"所驱策的。

管理者购买协作产品的核心痛点，是消解"我说的话，对方到底看见没有；我交代的事，到底有没有往前走"的确定性焦虑。

当 AI 成为发信人的超级代理人，自动整理出待办、未读并呈现在移动端时，收信人（普通员工）感受到的并不是"智能的平权"，而是**“被凝视的加剧”**。AI 削弱了员工在工作流中用于喘息的"心理缓冲带"。

一个产品如果骨子里流淌着"发信人立场"的强控制基因，却在对外叙事上试图扮演体贴"收信人"的超级秘书——这种基因与愿景的底层拉扯，从一开始就埋下了失焦的隐患。

启示六：共创用户不等于真实用户

共创用户愿意给时间，愿意反馈，愿意理解产品尚未成熟的地方，也更容易被产品团队的叙事、演示和陪伴影响。

但共创用户不等于真实大量使用产品的用户：

• 共创用户见过产品经理，普通用户只见到入口。
• 共创用户知道我们想做什么，普通用户只知道这个东西有没有在三秒内帮到他。
• 共创用户可以被密集运营，真实用户只能被产品本身运营。
• 内测玩家会替产品补全意义，正式用户只验收眼前价值。前者体验的是产品加服务，后者体验的仅仅是产品本身。

这就是为什么很多共创里"还可以"的设计，上线后会显得突然刺眼。共创中的解释、陪伴和耐心，在正式用户那里都消失了。剩下的只有一个入口、一张卡片、一次误触、一个关不掉的模块。

启示七：不要问用户"你觉得我的想法好不好"

做用户研究，最容易犯的错，是把用户说的话当成事实。

这里的"谎言"，不是说用户有意欺骗。更多时候，用户是礼貌的、想象中的、处在组织关系里的。尤其在企业共创里，用户面对的不是一个冷冰冰的问卷，而是一个合作关系、一个供应商、一个平台方。他说话时，会天然留余地。

用户还会说一种"想象中的真话"。 比如学习内容——理论上，没有人会反对学习；理论上，paper、行业资讯、管理知识都很有价值。可当用户正在处理消息、日程和待办时，系统突然把他带进一个学习流，实际感受可能就是"像广告"“占地方"“工作时不想看”。

他并没有撒谎。他只是在两个不同场景里，给出了两个都真实的答案。

产品研究里最诚实的答案，常常不在嘴上，而在这些成本里。

启示八：敏捷是一把很快的刀

敏捷从来不是抽象的。组织总是对某些人、某些事、某些信号更敏捷。问题并不是"团队敏不敏捷”，而是"团队对谁敏捷"。

当某个信息流成为最高优先级队列，团队就会天然围着它转。被他看见的问题，会迅速进入战时处理；没有被他看见的问题，即使用户反复提、产品反复想，也容易留在"重要不紧急"。

于是，敏捷像一把很快的刀。它能切开眼前的结，也能把长期问题切碎，分散到每天的改动里。

每天交付的机制，偏爱：今天能看见的，今天能截图的，今天能被验收的，今天能写进 changelog 的。

它不喜欢：需要长期建模的，需要打通底层数据的，需要反复验证才有效的，一开始看不出效果、但半年后决定上限的。

这不是某个人的错，是机制本身的偏好。于是，正确问题被留在旁边。每天交付的，是更容易被看见的变化。

启示九：“90 分 Agent"的陷阱

Agent 不能只在 demo 里聪明，也要在真实业务里交付一个用户愿意承认的结果。这个方向当然重要。

问题在于，90 分究竟评的是什么，以及，是不是要为了短期快速达到这个 90 分，对产品削足适履。

如果评的是短期交付效果，团队很容易自然地收窄场景、减少变量、提高命中率。为了让功能更像 90 分，系统选择了最容易得分的一类关系。题答对了，场景却变小了。

这就是削足适履最隐蔽的地方。它看起来是在追求交付，实际上是在把用户的脚修成鞋的形状。

90 分 Agent 应该追求稳定交付，但不能为了稳定，把真实世界改造成适合考试的题目。企业 AI 最难的地方，恰恰在于真实世界不干净：信息散在不同系统里，责任藏在人际关系里，流程有例外，权限有边界，用户还有情绪。

一个高分小题，未必是一个好产品。

启示十：AI 的本质是"奢侈服务的下放”

奢华酒店会记住客人的偏好：喜欢什么水果、枕头要多高、欢迎卡写什么称呼、上一次住在哪一间房。普通酒店通常做不到。不是不想做，而是成本不允许。一个人能被记住，是因为他足够重要，或者付了足够多的钱。

工作系统里也是一样。老板、核心客户、关键人物，天然有人替他筛信息、排优先级、做提醒、记偏好。他们已经享受了人工个性化服务。普通员工没有。

AI 的一大价值，是把奢侈品级别的服务下放给普通人。

越是已经被人肉个性化服务的人，越不容易意识到普通用户为什么需要"自定义自己的产品入口"。他的反馈链路、人工解释、问题响应、产品修补，天然围绕着他转。对他来说，系统不够个性化，不构成强痛点；对普通用户来说，这恰恰是 AI 最应该补上的差距。

大多数人的工作，并不是少数关键人物工作方式的缩小版。用户真正需要的，可能不是又一个统一硬规则，而是一个逐渐学会"我是谁"的入口。

AI 如果只能把老板级体验再送给老板，价值并不大；它更该做的，是把过去只有少数人享受得起的贴身服务，变成每个普通工作者也能拥有的日常。

启示十一：什么工作养人，什么工作耗人

判断一份工作对人是滋养还是消耗，要看它最后把人带到哪里去：是让人练成技艺、养好身体、健全尊严，还是只让人变得疲惫浑浊、学会应付了事。

学徒不是柴火。柴火烧完就算，学徒要长手艺。一个人如果在一段工作里只被燃烧，没有长出判断、技艺、眼界和更稳定的内心，这段燃烧就要重新估价。

启示十二：做泰坦尼克号的水手

职业和岗位 JD 是对经验的归纳，描述的是求职市场上企业在一段时间内认为需要的员工画像；需求本来就是动态的。

一句话概括：过去经验的持续正确，无法预测未来的系统性毁灭。

但泰坦尼克号的沉没，不影响船上的水手找到下一份工作。因为：

1. 水手能够上船，说明上船前的能力得到了检验和认可。
2. 水手在船上做过切实的工作，船的沉没也不一定和这部分工作紧密相关。
3. 沉船经验世界上多少人能有？——何况塌这么大的一艘船。这是多么宝贵的经验。

最后，为什么一定要写下这篇复盘呢？我只是惶恐，如果无人记录，许多事情就会乘着"调整"“收缩"“组织优化"“方向变化"这些轻飘飘的词汇飞走消失。可那些事真正发生过的，是一个个具体的人、具体的房间、具体的夜晚、具体的会议、具体的沉默、具体的荒诞和具体的学到啊。

写在最后

有人提出过，新能源汽车的发展可以分为两个阶段：电动化是上半场，智能化是下半场。

同样地，AI 产品的开发也可以分为两个阶段：做出来是上半场，做对是下半场。

这篇文章记录的，恰好是一个产品如何在"做出来"和"做对"之间挣扎的全过程。它没有标准答案，但有足够多的真实颗粒度——那些在正式复盘里不容易出现的东西：真实的犹豫、判断的代价、组织的惯性，以及一个产品人在现场里倍速积累的经验。

希望这份摘录，能给所有正在或希望从事 AI 产品开发的读者，提供一汪小小的经验池。