本文内容整理自相关技术讨论与问答记录，仅作为个人学习笔记存档。
一、职业选择的核心原则：在上升期，让你的技能成为"利润中心"
1.1 硬件公司与软件公司的"技能错配"
在一个以某类技术为主营业务的公司里，做"非主流"岗位时，价值如何被评估、如何被对待，是一个核心问题。
| 场景 | 含义 | 作者观点 |
|---|---|---|
| 在硬件公司里干软件 | 去华为、大疆、小米等以硬件产品为核心的公司做软件开发 | 不推荐（职业上升期） |
| 在软件公司里干硬件 | 去字节、阿里、腾讯等以软件/互联网服务为核心的公司做硬件设计 | 比上一种好一些，但仍非最优 |
核心原因：硬件与软件的成本属性不同。
- 硬件成本倾向在"物"：一次性、可分摊、可库存。做一块电路板节省了1元成本，就是1元利润。价值容易被量化。
- 软件成本倾向在"人"：持续发生、不可库存。开发人员的工资每月都要付，代码本身复制几乎零成本，但人的时间很贵。在硬件公司里，软件常被看作"固定费用"，总被问"能不能少几个人"。
1.2 为什么硬件价值容易被量化，软件容易被"赠送"
| 维度 | 硬件 | 软件 |
|---|---|---|
| 成本特征 | 一次性、可分摊、可库存 | 持续发生、不可库存 |
| 边际成本 | 递减（做第1000个比第1个便宜） | 几乎为零（但固定成本高） |
| 责任追溯 | 坏了就是物料或工艺问题 | 一个bug可能跟架构、需求、沟通有关 |
| 管理思维 | 把硬件成本当成"资产/物料"来管理 | 把软件成本当成"人力费用"来管理 |
结果：在硬件公司里，软件团队被当作"费用项"，价值容易被压缩；在软件公司里，硬件团队反而变成"可量产的物"，利润清晰，不容易被忽视。
1.3 上升期 vs 下降期的策略反转
| 周期 | 策略 | 原因 |
|---|---|---|
| 上升期 | 去以你的专业为核心业务的公司 | 你的技能成为"利润中心"而非"成本附庸" |
| 下降期 | 反向操作 | 硬件公司为了降本增效，会愿意用软件优化替代部分硬件；软件公司收缩时会先砍非核心硬件团队 |
1.4 苹果是例外，不是规律
苹果本质上是硬件公司（营收约80%来自硬件销售），但其软件（iOS、macOS）不是"附赠"，而是"硬件溢价的原因"。用户因为软件而买硬件，软件直接驱动硬件销量和售价。
判断一家硬件公司的软件岗位是否值得去，关键两问：
这家公司去掉软件，产品最多降价多少？
- <10% → 软件是附件，危险
- 30% → 软件有定价权，安全
软件团队的成本，在财务报表里属于"研发费用"，还是被分摊到"物料成本"中？
- 纯费用项 → 容易被砍
- 部分能体现到BOM价值里 → 相对安全
二、信息过载时代的认知策略：跟着一个人建立框架
2.1 前沿方向的致命特点
跟踪前沿方向时，容易迷失自己。信息量巨大，观点迥异，且因为太新，行业还没有形成任何共识，也没有很好的评价框架可以参考。
前沿方向的三个致命特点：
- 信息过载：每天几十篇论文、上百条解读
- 信噪比极低：90%是重复、炒作、臆测
- 没有权威裁判：没人能告诉你谁对谁错
2.2 "跟着一个人"的省力路线
核心方法：挑一个经常在媒体中出现的行业大佬，公司背景最好和自己所在公司是同行或紧密上下游关系，学识能力也是自己认可的。搜他/她近两年的全部讲话和访谈，一一看过来。
| 步骤 | 动作 | 目的 |
|---|---|---|
| 1 | 选一个人 | 限定信息源，避免迷失 |
| 2 | 搜近2年全部讲话/访谈 | 获取时间序列上的思考脉络 |
| 3 | 看演讲 → 总结行业框架 | 知道"有哪些板块、谁是玩家" |
| 4 | 看访谈 → 总结评价框架 | 知道"用什么标准判断好坏" |
| 5 | 琢磨背后的思考逻辑 | 学会像他一样推理，而不只是记结论 |
| 6 | 再扩大阅读面 | 用他人观点修正单一偏见 |
关键洞察：2-3天就能建立一个底子——这比漫无目的地刷几个月信息高效得多。
2.3 实操中的坑与应对
| 坑 | 表现 | 对策 |
|---|---|---|
| 选了错的人 | 网红型大佬，观点反复、追热点 | 优先选投资人、行业分析师、退休后的大佬 |
| 把"大佬的预测"当真理 | 大佬也会错，而且错得离谱 | 重点学他的框架，而不是结论 |
| 只看一家之言 | 没有"修正机制" | 再找一个角色对立的大佬，对比分歧点 |
| 时间滞后性 | 近2年的访谈可能已经是2年前的信息 | 优先找播客和近期财报电话会 |
进阶心法：同时跟踪2-3个彼此之间有真实观点碰撞的大佬。看到的不只是结论，而是论证过程的对决——学会的是"判断判断的能力"，而不是单纯记忆。
三、判断"好公司"的可操作指标
3.1 核心逻辑："好公司"没有标准答案，但针对具体问题有可操作指标
| 场景 | 判断方法 | 核心逻辑 |
|---|---|---|
| 产品策略——学谁？ | 行业老大守正（成熟方案），行业老二创新（新方向） | 老大的优势是规模化，老二的生存靠差异化 |
| 行业趋势——往哪走？ | 参考比自己高一层的相邻行业 | 上游/更前沿的行业已验证的方向，会下沉到本行业 |
| 跳槽——去哪家公司？ | 看RPE（人均营收）+ "扛金锄头"行业 | 人均营收高，公司有钱分；资本密集型行业，员工待遇更稳 |
3.2 RPE（人均营收）与"扛金锄头"
RPE = Revenue per Employee = 公司年营收 ÷ 员工人数
RPE高 → 每个员工创造的收入高 → 公司有能力付高工资
RPE低 → 劳动密集型，人多但产出有限 → 工资容易被压缩
"扛金锄头"行业：你拿的工具（硬件/设备/资本）本身就很贵，那么作为使用这个工具的人，待遇不会太差。因为工具贵 → 需要靠谱的人操作 → 对人的投资相对"便宜"。
| 公司/行业 | 硬件/资本投入 | 员工工资 | 比例（资本:人力） | 员工待遇预期 |
|---|---|---|---|---|
| DeepSeek（AI公司） | 约1万张A100+4000张H800，三年摊下来资本投入高 | 工资高但相对资本投入低 | 约4:1 | 非常好 |
| 中田健身房（典型） | 门店总投资50万，三年摊 | 店长年薪12万 | 约1:1 | 一般 |
核心洞察：资本投入 >> 人力投入 → 公司会"善待"员工（因为不差这点工资钱）；资本投入 ≈ 人力投入 → 公司会压缩人力成本（因为这是主要的可变成本）。
四、文档写作的三个核心原则
4.1 原则一：可以回溯
任何一个文档，都要有作者、版本号和时间。如果有引用数据/文献，要给引用的出处。如果引用第三方的观点/数据，也要给注释。
目标：20年后你自己翻资料翻到这篇文档，能不能引用这篇文章中的数字、观点，并且对比当时的数字、观点，还能给出差距的原因。
为什么要这样做？
- 产品决策经常需要回溯："当时为什么选A不选B？"→ 没有出处的文档等于没说
- 数据会过期，观点会被推翻，但有了出处，就知道当初的假设是什么，才能分析偏差原因
- 版本号和时间是"决策锚点"：某年某月的数据，对应某个版本的逻辑，不能混用
4.2 原则二：盲读
一个文档，按照"有人可以盲读"的目标来写。盲读，就是他不认识你，也不能取得你的联系方式，而且他周围的人也不能给他任何参考意见，他只有你的文档可读。
盲读能做到的标志：
- 不用解释"当时我说过什么"，文档里都写了
- 不用补充"这个术语在我们公司指什么"，文档里有定义或链接
- 不用追问"这个数字是怎么来的"，文档里有计算过程或出处
4.3 原则三：魔鬼在细节
一篇对外的文档，大内容一般都是正确的。文档质量，全在细节。标点符号、空格、字体、错别字、图表标号……每一处都重要，都代表公司体面。
高质量文档的保障：多轮审阅流程。大公司出精品，一个文档过10轮审阅流程，肯定质量高于过2轮审阅的。
| 原则 | 解决的问题 | 核心目标 |
|---|---|---|
| 可回溯 | 时间久了忘记为什么做 | 决策可追责、可复盘 |
| 盲读 | 别人看不懂、要追着你问 | 信息可独立传播 |
| 魔鬼在细节 | 小错误摧毁信任 | 体现专业和体面 |
三条合在一起：你的文档应该像一个"可独立站立的人"——有来历、能说清、体面整洁。
五、OpenAI商业模式对AI芯片公司的影响
5.1 核心数据拆解
根据纽约时报报道（2024年9月），OpenAI按8月收入3亿美元推测年收入为37亿美元：
| 收入来源 | 金额 | 占比 | 说明 |
|---|---|---|---|
| ChatGPT Plus订阅费（1000万用户 × $20/月） | ~$2.5B | ~68% | 按月收费，固定收入 |
| 其他订阅相关 | ~$0.4B | ~11% | 企业版等 |
| API收入（卖token） | ~$0.51B | ~15% | 按使用量收费 |
| 其他 | ~$0.2B | ~6% | - |
| 总计（2024年预估） | ~$3.7B | 100% |
关键发现：API收入只占15%，绝大部分是靠用户按月付费。
5.2 为什么作者"失望"？
两种商业模式对硬件的要求完全不同：
| 模式 | 赚钱逻辑 | 对硬件的要求 | 硬件公司的处境 |
|---|---|---|---|
| 订阅费 | 用户每月付固定钱，不管用多少次 | 降低成本（只要能满足基本体验，越便宜越好） | 芯片公司被压价，追求"够用就好" |
| API卖token | 按使用量收费，用得越多赚越多 | 提升性能/性价比（每美元能跑多少token） | 芯片公司被激励做更强的芯片 |
作者担心的是：OpenAI现在主要靠订阅费赚钱 → 它的最大动机是把硬件成本压下来（因为反正用户付固定月费，用多用少都一样），而不是追求极致性能。
5.3 对未来的期待
“如果在2029年的1000亿美元中，有50%来自API，我会更开心。”
这意味着：只有API收入占比大幅提升，OpenAI才会真正成为推动硬件性能进步的客户，而不是压榨硬件成本的客户。
六、产品经理的"数字防飘"法则
6.1 什么叫"做飘了"
产品经理喜欢讲：用户体验、场景、痛点、闭环、赋能、心智……这些词本身没错，但如果没有数字支撑，就会变成谁嗓门大谁有理，无法验证、无法对比、无法决策。
“飘” = 浮在概念层，落不到执行层。
6.2 不同岗位的数字精度要求
| 岗位 | 精度要求 | 举例 | 为什么？ |
|---|---|---|---|
| 市场 | 量级不错 | “这个市场大约10亿左右” | 市场是粗颗粒度的，精准到万没有意义 |
| 产品 | 精确到个位 | “日活用户 1,247,563 人” | 产品决策需要知道趋势、对比、目标 |
| 研发 | 小数点后2-6位 | “延迟 2.34ms” | 技术细节里，小数点是性能和可靠性的分界线 |
核心洞察：产品经理不需要像研发那样精确到小数点后4位，但也不能像市场那样只说"大概几亿"。精度是"够用就好"，不是越精确越好。
6.3 数字化自查清单
| 常见"飘"的说法 | 数字化的追问 |
|---|---|
| “用户反馈挺多的” | 多少条反馈？占总用户比例？NPS多少？ |
| “这个功能很重要” | 多少用户会用到？使用频率？影响多少GMV？ |
| “竞品也这么做的” | 竞品数据如何？我们和竞品的差距是百分之几？ |
| “用户体验不好” | 哪个环节？跳出率多少？完成任务的时长是几秒？ |
| “我们要提升转化率” | 从多少提到多少？多长时间？怎么测？ |
七、标准化的两面性：Intel vs. Nvidia的护城河策略
7.1 硬件产品经理的根本性两难
| 角色 | 对标准化的态度 | 原因 |
|---|---|---|
| 作为"买家"（采购上游零件） | 爱标准化 | 标准件 = 多家供应商可选 = 随时可替换 = 成本低 |
| 作为"卖家"（把产品卖给下游） | 恨标准化 | 不希望自己的产品变成标准件（可替代 → 只能拼价格） |
矛盾的本质：对上游，你爱标准化；对下游，你恨标准化。你的利润，就藏在这个"双标"的缝隙里。
7.2 三种产品类型的竞争格局
| 产品类型 | 特点 | 竞争格局 | 例子 |
|---|---|---|---|
| 超级标准化 | 所有零件可互换，性能参数透明 | 无止境性价比竞争，后来者无数，利润极薄 | USB线、电源适配器 |
| 中间产品 | 部分标准化，部分定制 | 需要巧妙平衡，单点突破 | 大多数硬件模块、板卡 |
| 高度差异化 | 客户紧耦合，切换成本极高 | 护城河深，利润高 | Nvidia的GPU+CUDA |
可怕之处：如果产品完全标准化 → 赛道里会出现"巨鳄"，用机枪扫射的方式尝试所有排列组合，选出最优解，然后靠体量拉成本，干死所有人。
7.3 两种典型的护城河策略
| 策略 | 代表 | 核心逻辑 | 护城河来源 |
|---|---|---|---|
| Intel策略：定标准，做老大 | Intel（PCIe标准） | 主动给供应商、同行制订标准，让大家按你的规则玩 | 标准制定权 + 规模效应 |
| Nvidia策略：守小市场，做垂直整合 | Nvidia（CUDA生态） | 不立标准，不与任何人平摊研发费用，10多年打造软件生态 | 软件生态 + 紧耦合 + 先发积累 |
关键洞察：
- Intel式护城河 = 让别人按你的规则玩（横向扩张）
- Nvidia式护城河 = 让用户离不开你的系统（纵向深耕）
7.4 软件生态是"长坡滚雪球"
Nvidia的例子：第一个100万开发者用了13年，第二个100万只用了2-3年。一旦跨过临界点，速度会指数级加快。
生态的临界点：你的生态解决了其他方案解决不了的问题 + 用户迁移成本极高。
八、评价体系：产品经理的"定义权"
8.1 为什么"评价体系"这么重要
没有评价体系 → 需求合不合理全凭感觉 → 产品经理和研发天天吵架
有评价体系 → 所有人用同一把尺子 → 优先级、权衡、拍板都有依据
8.2 两个成熟评价体系案例
案例一：芯片 → PPAC
| 维度 | 含义 |
|---|---|
| P = Power | 功耗 |
| P = Performance | 性能 |
| A = Area | 面积 |
| C = Cost | 成本 |
无论多先进的架构、多牛的算法，最终落到具体应用上，这四个维度拉出来一比，高下立判。
案例二：AI能力 → 与人类平均水平比较
| 应用场景 | AI表现 | 人类表现 | 结果 |
|---|---|---|---|
| CV（计算机视觉） | 准确率97.3% | 95% | 停车场收费员被替代 |
| 自动驾驶 | Waymo碰撞率0.41/百万英里 | 人类2.78/百万英里 | 先取代运营车辆，再取代家用车 |
评价体系的威力：一旦AI在某条线上超过人类平均水平，那条线上的人类工作就"理论上"消失了。不相信的人需要自己承担高昂保险费用（市场机制会倒逼接受）。
8.3 赢家公式
“如果一个新产品，在产品经理自定义的评价体系中占有明显优势。产品经理和公司，又有能力把这个自定义的评价体系推成行业标准。那就是妥妥赢家。”
| 条件 | 含义 | 例子 |
|---|---|---|
| 1. 自己的产品在新体系中占优 | 你定义的尺子，量出来你最好 | 苹果说"用户体验"比跑分重要 → iPhone在体验维度占优 |
| 2. 有能力推成行业标准 | 让市场接受你的尺子 | 英伟达让所有人都用"CUDA生态"作为评价AI芯片的标准 |
只满足条件1：自嗨（你自己说你好，没人认）
只满足条件2：为他人做嫁衣（你定义了标准，但别人的产品更符合）
两个都满足：赢家通吃
8.4 评价体系的来源与战略选择
| 来源 | 做法 | 优点 | 缺点 | 什么时候用 |
|---|---|---|---|---|
| 历史（行业惯例） | 沿用行业过去几十年用的评价体系 | 所有人都在用，沟通成本低 | 可能已经过时，固化竞争格局 | 成熟品类、稳定技术、你只是追随者 |
| 权威（第三方机构） | 采用权威机构发布的评价标准 | 有公信力，客户信任 | 权威可能被收买，更新慢 | 你的产品在权威体系里表现好 |
| 对我方有利（战略选择） | 主动设计一套评价体系，让自家产品占优 | 让你在竞争中"重新定义战场" | 容易被质疑"自卖自夸" | 新产品品类，或旧体系里吃亏 |
核心洞察：评价体系不是"客观真理"，而是一种战略选择。你选哪套体系、给每个维度多少权重、是否能推广出去，决定了你的产品在市场上的位置。
九、框架与Checklist：从执行者到定义者的分水岭
9.1 什么是框架？
框架是思考的边界（理论上限、下限、边界）。
| 要素 | 含义 | 例子（以芯片市场为例） |
|---|---|---|
| 理论上限 | 最好能到什么程度 | 某类芯片的理论最高算力（物理极限） |
| 工程上限 | 现实能到什么程度 | 当前工艺、成本、散热约束下的最高算力 |
| 下限和边界 | 不能低于什么，不能超出哪里 | 成本不能超过X元，功耗不能超过Y瓦 |
框架的作用：让你知道"我们在哪儿"、“能去哪儿”、“不能去哪儿”。大家在一个框架下讨论，才能形成共识。
9.2 什么是Checklist？
“一个人在没有和你直接交流的情况下，拿着这个checklist，能有质量地重复出checklist中指导的过程/产品/操作。”
Checklist的特点：
- 它是精简的，不是事无巨细的说明书
- 它是可重复的，换一个人也能做出同样质量的结果
- 它是执行层面的保底机制，防止遗漏关键步骤
9.3 框架 vs Checklist 的本质区别
| 维度 | 框架 | Checklist |
|---|---|---|
| 作用 | 界定思考边界、指导方向 | 确保执行不遗漏 |
| 内容 | 上限、下限、边界、关键变量 | 步骤、要点、检查项 |
| 谁用 | 定义者、决策者 | 执行者 |
| 可替代性 | 不可替代（错了全盘皆输） | 可被优化/迭代 |
核心洞察：框架决定上限，Checklist决定下限。
9.4 从执行者到定义者的职业分层
| 层级 | 角色 | 能力要求 | 典型状态 |
|---|---|---|---|
| 底层 | 执行者 | 能看懂并执行Checklist | “你告诉我做什么，我做” |
| 中层 | 优化者 | 能改进现有Checklist | “这个步骤可以更高效” |
| 高层 | 定义者/作者 | 能从框架中提炼出Checklist | “这是我们的标准流程” |
大多数人一辈子停在第一层。少数人能到第二层。只有极少数人能到第三层。
9.5 芯片设计行业的框架 + Checklist 实例
框架（以AI加速芯片为例）：
| 维度 | 理论上限 | 工程上限 | 下限 | 边界 |
|---|---|---|---|---|
| 算力 | 某工艺下晶体管全部用于计算 | 考虑缓存占比、片上网络开销后的可达算力 | 10 TOPS @ INT8 | 散热方案限制：风冷 ≤ 25W |
| 能效 | 无漏电、无动态功耗 | 当前工艺典型值 + DVFS策略 | 2 TOPS/W | 工业级温度范围 |
| 频率 | 单个反相器的理论振荡频率 | PVT最差条件下稳定运行的最大频率 | 500 MHz | 某代工厂某工艺 |
| 面积 | 整个光罩最大尺寸 | 预算内的Die Size（考虑良率） | - | 封装引脚 ≤ 400 |
Checklist（流片前最终签核）：
- 设计检查：RTL代码已freeze、Lint检查0 error、CDC检查通过、形式验证通过
- 物理检查：时序收敛、功耗分析、IR drop分析、DRC/LVS通过
- 验证检查：功能覆盖率 ≥ 99.5%、代码覆盖率 ≥ 98%、所有测试用例pass
- 软件/固件检查：驱动代码就绪、至少一个应用场景端到端测试通过
- 制造检查：GDSII文件通过foundry预审、封装图纸匹配、测试程序已编写
- 文档与签字：变更记录完整、已知bug清单已评审、设计评审记录齐全、签署"流片放行单"
框架与Checklist的关系：框架决定芯片做什么、做到什么程度；Checklist保证别犯低级错误，顺利做出来。
十、产品经理的知识结构与心态：“什么都懂一点"与"大家都是聪明人”
10.1 "什么都懂一点"是为了什么
| 懂到什么程度 | 不用懂到什么程度 |
|---|---|
| 知道某个功能实现起来大概需要多少资源（人/周） | 不需要知道具体用哪个API |
| 知道某个技术方案的边界和限制（什么能做、什么不能做） | 不需要知道底层算法细节 |
| 知道业界动态：别人在做什么、做对了什么、做错了什么 | 不需要成为那个领域的专家 |
| 知道从自己的产品到最终用户的整条路径上，每个环节在做什么 | 不需要每个环节都能亲自上手 |
核心目的：防止自己做错（选错方向），防止自己漏做（别人做了你没做）。最可怕的不是"大家都错了"，而是"有部分人做对了而你不知道"。
10.2 “最核心的是懂得最终用户在买什么”
芯片不直接卖给最终用户。链条是：芯片 → 模组厂 → 方案商 → 品牌商 → 渠道 → 最终用户。
例子：做一颗蓝牙音频芯片。直接客户（方案商）要更多的EQ调节参数、更多的音效模式。但最终用户买耳机时，最关心的是"连接稳不稳"、“延迟低不低”、“续航长不长”。如果跟着客户做了一堆复杂音效，但连接稳定性没做好，最终用户不会买账 → 芯片卖不动。
10.3 "大家都是聪明人"的心态
| 你的感觉 | 大概率是 | 为什么 |
|---|---|---|
| “我好聪明，竟然发现了这个漏洞” | ❌ 你错了 | 这条路径上的专家早就看过了，当前方案是权衡后的最优解 |
| “这个空缺大家都知道，但没人愿意做，因为初期吃力不讨好” | ✅ 有可能是对的 | 这不是"别人笨没发现"，而是"别人聪明但不愿意做" |
深层道理：
- 在一个被很多人反复审视的领域，留下"傻方案"的概率极低
- 如果你觉得自己发现了明显的漏洞，大概率是你懂的还不够深，没看到背后的权衡
- 真正的机会往往不是"别人没发现"，而是"别人知道但不愿意做（因为短期看不到收益）"
10.4 判断"我发现的空缺是不是真机会"的四步法
- 写下你的发现：“我发现XX领域有一个空缺：没有人做Y。”
- 假设别人都是聪明的：“如果有人已经想到了Y，为什么他没做？”
- 列出所有可能的原因：技术不可行？成本不划算？时机未到？有法律风险？需要太长时间回报？
- 逐一验证：如果所有原因都可以被反驳或解决 → 可能是真机会；如果"确实很难解决，但我有独特解法" → 也可能是真机会
一个简单的自检方法：每当你心里冒出"我好聪明，竟然发现这个"的时候，强制自己说下一句话："但是，比我聪明100倍的人在这个领域研究了10年，他们为什么没做？"然后去找到答案。找不到答案之前，默认自己错了。
本文内容整理自相关技术讨论与问答记录，仅作为个人学习笔记存档。
参考资料
