产品设计 on 文艺技术笔记

AI 时代产品经理的能力重塑：从需求洞察到大模型产品设计方法论

Thu, 18 Jun 2026 22:45:00 +0800

产品经理的日常工作，正在被 AI 重新定义

过去十年，产品经理的核心动作是：调研需求、画原型、写 PRD、拉评审、跟开发、看数据。这套流程建立在确定性之上——用户行为可预测，功能逻辑可穷举，AB 测试能给出明确结论。

大模型打破了这个前提。当你设计一个 AI 产品时，你面对的不是"这个按钮放哪里"的问题，而是"这个模型在 30% 的情况下会给出错误输出，产品该怎么兜底"的问题。输出不确定、用户预期管理复杂、质量评估维度从功能正确性变成了体验可接受性。产品经理的日常决策模型，从"做不做这个功能"变成了"怎么让一个概率性系统看起来可靠"。

具体来说，你周一的例会不再只是讨论功能优先级，而是要和算法工程师一起分析评估集的表现，判断哪些 bad case 需要 Prompt 调整、哪些需要产品层面兜底。你写的需求文档里开始出现"意图识别准确率不低于 90%“这样的指标，而不是"支持 XX 功能”。你和设计师讨论的不再只是界面布局，而是"模型思考了三秒还没返回结果时，界面上应该展示什么"。

这不是小修小补，而是能力结构的重建。如果你还在用写 PRD、画原型、看漏斗这套打法做 AI 产品，大概率会在上线三个月后发现：功能都做了，用户不买单，因为模型输出的质量根本撑不起你设计的那个"完美体验"。

传统 PM 与 AI PM 能力模型对比

维度	传统 PM	AI PM
核心关注	功能完整性、用户旅程	模型能力边界、人机协作模式
需求定义方式	用户故事 + 验收标准	意图分类 + 容错策略 + 兜底设计
技术理解深度	前后端架构概念	模型推理逻辑、Prompt 结构、RAG 流程
质量评判	Bug 率、功能覆盖率	幻觉率、任务完成率、用户信任度
迭代依据	AB 测试数据	评估集 + 人工标注 + 线上反馈闭环
与工程师协作	PRD 驱动	Eval 驱动，共同定义"好"的标准
风险意识	工期、资源、竞品	模型失效、合规风险、用户误解 AI 输出

传统 PM 不需要"懂算法"，但 AI PM 必须理解模型的能力上限在哪里。你不需要自己训练模型，但你要能判断一个场景用 Prompt 就能解决，还是需要 Fine-tuning，还是根本不该用大模型。更关键的是，传统 PM 的需求文档是"规定性"的——告诉开发做什么；AI PM 的需求文档是"约束性"的——定义系统在什么范围内是可接受的。这个转变听起来很小，实际上意味着你要重新学习怎么写需求、怎么做评审、怎么验收。

三个新增核心能力

一、Prompt 工程素养

不是会写 Prompt，而是能系统性地设计 Prompt 策略。这包括：理解 System Prompt 和 Few-shot 的作用边界，知道什么时候该拆分成多步 Chain-of-Thought，能判断一个效果问题是 Prompt 不够好还是模型能力本身不够。你还要理解 Temperature、Top-P 这些采样参数对产品体验的影响——创意写作场景需要高随机性，而客服问答需要高度确定性。这是 AI PM 和算法工程师高效沟通的基础语言，不懂这些你连需求都提不清楚。

二、模型评估能力

传统产品看转化漏斗，AI 产品看评估集。你需要参与定义 Eval 数据集的构成——哪些 case 是核心场景必须覆盖的，哪些是长尾但高风险的。你要理解准确率、召回率、相关性这些指标在不同场景下的权重差异：客服场景宁可多给一个保守回答也不该瞎编，而创意写作场景则可以容忍更高的自由度。更要命的是，很多 AI 产品的质量没有金标准——“好的回答"是什么，需要 PM 联合业务专家来定义，而不是交给工程师一个人拍脑袋。

三、数据飞轮思维

AI 产品最大的护城河不是模型，是数据闭环。每一次用户交互都是标注机会：用户点了"有用"就是正样本，用户重新提问就是负样本，用户手动修改了 AI 的输出就是最精准的修正标注。PM 要设计产品机制来持续收集这些信号，反哺模型优化。比如设计一个轻量的反馈入口，让用户在不知不觉中帮你完成标注工作。没有飞轮意识的 AI 产品，上线第一天就是它最好的时候，之后只会越来越差——因为用户场景在演化，而你的模型还停留在训练数据的世界里。

大模型产品设计的三种范式

Chat-based（对话式）：最直觉的交互形态，用户用自然语言描述需求，模型直接响应。适合探索性任务、内容生成、信息检索。核心设计挑战在于如何引导用户给出足够清晰的意图——大部分用户的提问都是模糊的，产品需要通过追问、选项推荐、上下文补全来缩小意图范围。同时要设计好"模型不确定时"的表达方式，避免用户把概率性输出当成确定性结论。

Agent-based（智能体式）：模型不只是回答问题，而是自主规划和执行多步任务。比如"帮我分析这个月销售数据并生成报告”，Agent 会自动拆解为数据查询、分析、可视化、文档生成等步骤。PM 需要设计任务边界、权限控制和中间确认节点——哪些操作 Agent 可以自主执行，哪些必须用户确认后才能继续。避免 Agent 做出用户意料之外的操作是最关键的安全设计。

Copilot-based（副驾驶式）：模型嵌入已有工作流，在用户操作过程中提供建议或自动补全。代码编辑器里的 Copilot 是典型例子，但这种模式正在扩展到写作、设计、数据分析等各个领域。PM 的核心工作是定义"什么时候介入"和"如何不打断用户"。过度主动会烦人，过于沉默又失去价值。需要根据用户行为信号（停顿、删除、重复操作）来动态调整介入时机。

三种范式不是互斥的，一个成熟产品往往会混合使用。但每种范式的用户体验预期、容错设计和评估标准都不同，PM 需要在设计阶段就做出明确选择。一个实用的判断方法：如果你的用户需要探索空间，用 Chat；如果任务步骤明确且可自动化，用 Agent；如果用户已有成熟工作流不想被打断，用 Copilot。选错了范式，再好的模型也救不回来。

AI 产品质量评估框架

评估维度	衡量指标	采集方式
准确性	事实正确率、幻觉率	评估集自动测试 + 人工抽检
有用性	任务完成率、用户采纳率	线上行为埋点
安全性	有害内容生成率、合规违规率	红队测试 + 自动过滤
一致性	同类输入输出稳定性	回归测试集
响应速度	首 token 延迟、总生成时长	系统监控
用户信任	重新提问率、人工介入率	交互日志分析

注意：这些指标之间经常互相矛盾。追求准确性可能牺牲有用性（模型过于保守，什么都不敢说），追求速度可能牺牲一致性（流式生成容易跑偏），追求安全性可能牺牲体验（过滤太严导致正常问题也被拦截）。PM 的价值就在于做这些 trade-off 决策，而不是把选择权丢给工程师。

建议的做法是：为每个产品阶段设定不同的指标权重。上线初期优先保证安全性和基本准确性，宁可少做场景也不要出错；稳定期转向有用性和用户信任度，逐步扩大覆盖场景；成熟期关注一致性和响应速度，打磨体验细节。没有一套固定权重适合所有阶段。

构建 AI 产品的常见错误

❌ 把模型当功能来做：在 PRD 里写"接入大模型"，却没有定义具体场景和容错策略。结果是工程师接了个 API，产品体验一塌糊涂。

✅ 正确做法：先定义用户场景和失败边界，再选择合适的模型方案。模型是手段，不是目标。写清楚"当模型无法回答时，展示什么兜底内容"比写"接入 GPT-4"重要十倍。

❌ 过度承诺 AI 能力：让用户以为 AI 什么都能做，结果模型输出不靠谱时信任崩塌。

✅ 正确做法：明确告知用户 AI 的能力范围和局限性，设计优雅的降级路径。“这个问题我暂时无法准确回答，建议你咨询专业人士"比一个看似自信但错误的回答好一百倍。

❌ 忽视评估体系直接上线：没有评估集就上线，出了问题只能靠用户投诉来发现。

✅ 正确做法：上线前至少建立 200+ 条评估用例，覆盖核心场景和边界情况，每次模型或 Prompt 变更都跑一遍回归。这不是可选项，是最低要求。

❌ 只看单次交互不看飞轮：产品上线后不收集反馈信号，模型无法持续优化。

✅ 正确做法：从第一天就设计反馈采集机制——点赞/踩、重新提问、编辑修正——这些信号是产品进化的燃料。越早建立闭环，竞争对手越难追赶。

产品经理是模型能力与用户价值之间的桥梁

大模型本身不创造用户价值。一个千亿参数的模型，如果没有好的产品定义，就是一个昂贵的玩具。AI PM 的核心职责不是学会调 API，而是回答三个问题：这个模型能力解决谁的什么问题？用户愿意为这个结果付出多少信任？系统出错时我们怎么兜住？

技术决定了模型能做什么，产品决定了用户愿意用什么。这两者之间的距离，就是 AI PM 存在的意义。很多团队把 AI 产品做砸了，不是因为模型不够强，而是 PM 没有做好"翻译"工作——把模型的概率性能力翻译成用户可预期的产品体验。

能力重塑不是一蹴而就的事情。但从今天开始，认真对待每一个 Prompt、每一份评估集、每一次用户反馈，就是在构建你作为 AI PM 的基本功。这个领域没有现成的方法论可以照搬，最好的老师是你自己产品的线上数据和用户的真实行为。最后说一句实话：AI 产品经理最稀缺的能力不是懂技术，而是在技术不确定性的前提下，依然能做出清晰的产品决策。这种能力，只有在实战中才能长出来。

为什么几乎所有 AI IDE 都长得像 VS Code——从代码编辑器到开发者心智的垄断

Wed, 17 Jun 2026 22:00:00 +0800

如果你最近试过任何一款 AI 编程工具——Cursor、Windsurf、Trae、Void、Augment——你大概会有同一个感受：

“这不就是 VS Code 吗？”

侧边栏的文件树、命令面板、终端面板、插件市场、快捷键……几乎是同一个模子刻出来的。换了个 logo，换了个名字，但骨子里就是 VS Code。

这不是错觉。几乎所有主流 AI IDE 都是基于 VS Code 的开源版本（VS Code OSS）构建的。

问题是：为什么？

一、VS Code 的护城河：不只是编辑器

在讨论 AI IDE 之前，先理解 VS Code 为什么能统治代码编辑器市场。

市场份额

截至 2026 年，VS Code 在开发者中的使用率超过 75%（Stack Overflow Developer Survey 数据）。这不是"最受欢迎"，这是"默认选择"。

JetBrains 系列（IntelliJ、PyCharm、WebStorm）加起来不到 30%。Vim/Neovim 社区稳定在 10% 左右。其他编辑器（Sublime、Atom、Emacs）已经边缘化。

护城河的三层结构

第一层：技术护城河

Electron + Monaco Editor：基于 Web 技术的桌面应用，跨平台，渲染引擎成熟
LSP（Language Server Protocol）：微软提出的语言服务协议，让编辑器可以通过标准化接口对接任何编程语言的智能提示。这意味着 VS Code 不需要为每种语言写一套语法分析，只需要对接 LSP Server
Extension API：极其成熟的插件体系，超过 40,000 个插件覆盖几乎所有开发场景

第二层：生态护城河

插件市场：40,000+ 插件，开发者已经习惯了 VS Code 的插件生态
主题市场：数千个主题，开发者的视觉偏好已经固化
教程和社区：几乎所有编程教程都以 VS Code 为默认编辑器

第三层：心智护城河

这是最深层、最难被打破的护城河。

开发者每天在编辑器里工作 8 小时以上。编辑器的界面布局、快捷键、操作习惯，已经变成了肌肉记忆。切换到新编辑器意味着重新建立肌肉记忆，这个成本远比表面上看起来高。

一个简单的例子：Ctrl+Shift+P 打开命令面板。这个快捷键已经刻进了千万开发者的手指里。任何不提供这个快捷键的编辑器，都会在第一天就失去大部分用户。

二、AI IDE 的集体选择：Fork VS Code

理解了 VS Code 的护城河，AI IDE 的选择就很清晰了。

技术路线对比

AI IDE	底层技术	基于 VS Code？
Cursor	VS Code OSS Fork	✅ 是
Windsurf (Codeium)	VS Code OSS Fork	✅ 是
Trae (字节跳动)	VS Code OSS Fork	✅ 是
Void	VS Code OSS Fork	✅ 是
Augment	VS Code Extension	✅ 插件形式
GitHub Copilot	VS Code Extension	✅ 插件形式
Zed	Rust + 自研引擎	❌ 独立架构
JetBrains AI	IntelliJ 平台	❌ JetBrains 生态

绝大多数 AI IDE 选择了 Fork VS Code，只有极少数走了独立路线。

为什么 Fork 而不是从头做

原因一：开发成本

从零做一个代码编辑器需要多少工作量？

文件树、标签页、搜索替换、Git 集成、终端、调试器、语言智能提示、代码格式化……
保守估计：10 人团队，2-3 年

Fork VS Code OSS 呢？

开箱即用的完整编辑器
在此基础上只需要做 AI 功能的增量开发
开发周期缩短到 6-12 个月

原因二：用户迁移成本

如果做一个全新的 AI IDE，用户需要：

学习新的界面布局
重新配置快捷键
重新安装所有插件（如果新 IDE 不兼容 VS Code 插件）
重新配置调试器、语言服务器、代码格式化工具

这个迁移成本足以让 90% 的潜在用户直接放弃。

Fork VS Code 则完全不同：用户打开 Cursor 或 Windsurf，发现界面、快捷键、插件全部兼容，唯一的变化是多了 AI 功能。迁移成本趋近于零。

原因三：插件生态

VS Code 的 40,000+ 插件生态是任何新编辑器都无法在短期内复制的。

Python 开发者需要 Pylance
前端开发者需要 ESLint + Prettier
Java 开发者需要 Language Support for Java
Go 开发者需要 Go extension

如果 AI IDE 不兼容这些插件，就等于要求用户放弃他们依赖的所有工具链。

Fork VS Code 天然兼容整个插件市场，用户不需要做任何额外配置。

原因四：LSP 协议

Language Server Protocol 是微软为 VS Code 设计的语言服务协议，但现在已经成为行业标准。

LSP 的价值在于：编辑器不需要自己实现每种语言的语法分析、代码补全、跳转定义等功能，而是通过标准化协议对接外部的 Language Server。

如果从零做一个新编辑器，需要自己实现 LSP Client，对接所有主流语言的 Language Server。这是一个巨大的工程。

Fork VS Code，LSP Client 已经内置，开箱即用。

三、VS Code OSS：微软的开放策略

AI IDE 能 Fork VS Code，是因为微软把 VS Code 开源了。

VS Code 的开源结构

1

VS Code = VS Code OSS (开源) + 微软专有组件

开源部分（MIT 协议）：

编辑器核心（Monaco Editor）
文件管理、搜索、Git 集成
Extension API
LSP Client
终端集成
调试器协议

微软专有部分（不开源）：

VS Code 品牌和图标
微软插件市场的认证体系
遥测数据收集
自动更新服务
部分 AI 功能（Copilot 深度集成）

微软为什么允许别人 Fork

这看似矛盾——微软花了十年打造 VS Code，为什么允许竞争对手免费使用？

答案：VS Code 本身不是微软的产品目标，而是生态战略。

微软的核心利益是：

Azure 云服务 — 开发者用 VS Code 越多，越可能用 Azure
GitHub — VS Code + GitHub 是微软的开发者生态闭环
TypeScript — VS Code 推动了 TypeScript 的普及，TypeScript 增强了微软在 Web 开发领域的影响力
.NET — VS Code 对 .NET 的一流支持

让别人 Fork VS Code 做 AI IDE，反而会扩大 VS Code 的生态影响力。每一个基于 VS Code 的 AI IDE，都在帮微软巩固"开发者默认编辑器"的地位。

这是一种典型的平台战略：开放核心，锁定生态。

就像 Android 开源，但 Google 通过 GMS（Google Mobile Services）控制生态。VS Code OSS 开源，但微软通过品牌和生态锁定用户。

四、Fork 的代价：创新困境

虽然 Fork VS Code 是最理性的选择，但它也有代价。

代价一：界面同质化

当所有 AI IDE 都长得一样时，用户很难区分它们。

“Cursor 和 Windsurf 的区别是什么？”

如果你问一个普通开发者，大部分人答不上来。因为它们的界面几乎一模一样，差异只在 AI 功能的细节上。

这导致了品牌辨识度低的问题——用户记不住自己用的是哪个 AI IDE。

代价二：创新受限

Fork VS Code 意味着继承了 VS Code 的架构约束：

Electron 的性能开销：内存占用大（动辄 1-2GB），启动速度慢
单窗口设计：VS Code 的窗口管理不如 JetBrains 的 Project 概念灵活
文本优先：VS Code 的设计哲学是"一切皆文本"，对于可视化编程、低代码场景支持有限

Zed 选择了不同的路线（Rust + 自研渲染引擎），在性能上有明显优势。但它面临的用户迁移成本问题，限制了它的普及速度。

代价三：升级依赖

Fork VS Code 意味着需要持续跟进 VS Code 的更新。

VS Code 每月发布一个新版本，包含 bug 修复、新功能、安全补丁。Fork 的项目需要定期合并上游更新，否则会逐渐落后。

这是一个持续的工程投入。如果团队太小，可能跟不上上游的更新节奏，导致自己的产品逐渐与 VS Code 主线产生分歧。

五、AI 功能的真正差异化在哪

既然界面都一样，AI IDE 的竞争焦点就转移到了 AI 功能本身：

维度一：上下文理解

AI 编程助手的核心能力是理解代码上下文。不同产品在这个维度上有明显差异：

Cursor：深度代码库索引，支持全仓库级别的上下文理解
Windsurf：Cascade 功能，可以跨文件追踪代码变更
Copilot：基于 GitHub 代码库的训练数据，对开源项目理解更深

维度二：Agent 能力

新一代 AI IDE 正在从"补全助手"进化为"编程 Agent"：

不只是补全代码，而是能理解需求、规划步骤、执行修改、运行测试
能自主创建文件、修改配置、安装依赖
能根据测试结果自动修复 bug

这是目前各家竞争最激烈的方向。

维度三：模型选择

自带模型：部分 AI IDE 训练了自己的代码模型
接入第三方：对接 Claude、GPT-4o、Gemini 等通用模型
本地模型：支持在本地运行开源代码模型，保护隐私

维度四：定价策略

免费增值：基础功能免费，高级 AI 功能付费
按量计费：按 Token 使用量收费
包月制：固定月费，不限量使用

六、未来会怎样

短期（1-2 年）：同质化加剧

更多 AI IDE 会基于 VS Code Fork 出现，界面差异越来越小，竞争聚焦在 AI 能力和定价上。

中期（2-3 年）：整合与分化

整合：大量同质化产品被淘汰或被收购，市场集中到 3-5 家
分化：少数产品开始尝试非 VS Code 的架构，提供差异化的编辑体验

长期：编辑器可能不再是核心

一个更大胆的预测：当 AI 编程能力足够强大时，代码编辑器本身的重要性会下降。

如果 AI 能直接根据需求描述生成完整项目、自动修复 bug、自动重构代码，那么开发者花 8 小时盯着编辑器写代码的场景会大幅减少。

编辑器可能会从一个"主力工作工具"变成一个"审核和微调界面"——开发者大部分时间在审阅 AI 生成的代码，而不是自己写代码。

到那时，编辑器的界面是否像 VS Code，就不再重要了。

写在最后

几乎所有 AI IDE 都长得像 VS Code，这不是偷懒，而是理性选择：

开发成本低 — 不需要从零造轮子
用户迁移成本低 — 界面、快捷键、插件全部兼容
生态复用 — 40,000+ 插件开箱即用
心智垄断 — 开发者已经习惯了 VS Code 的操作方式

但这也带来了一个隐忧：当所有工具都长得一样时，开发者的创造力和想象力也在被同一个模子塑造。

VS Code 定义了"代码编辑器应该长什么样"。AI IDE 们正在定义"AI 编程工具应该长什么样"——而答案居然是"和代码编辑器一样"。

这到底是务实的最优解，还是想象力的贫乏？

也许两者兼有。但有一点可以确定：谁能在 VS Code 的外壳下，做出真正差异化的 AI 体验，谁就能赢得下一个十年。