X 官方正式托管了两枚 MCP 服务器，从此你无需再依赖第三方桥接程序，就能让 AI 客户端直接读写你自己的 X 账户：服务器侧保留 OAuth 授权，客户端只负责发起请求，令牌由你本地环境缓存并自动刷新。

这就意味着，无论是 Cursor、Claude Desktop、Grok Build、VS Code 还是任何兼容 MCP 的客户端，都可以直接完成三项关键任务：在 X 上搜索帖子、管理书签、读取趋势与新闻，甚至利用你账户的权限起草并发布文章。

对于已经在使用 MCP 客户端的开发者，这是接入 X 最短的路径；而对于完全没有 OAuth 2.0 配置经验的纯新手，门槛自然比一般的 SaaS 集成高出不少。

X 官方 MCP 服务器的出现，本质上就是将 AI 客户端与 X 账号之间那层被反复构建的授权与数据面，收敛为一个标准化上下文层。

在你安装任何 Cursor 插件、Claude 技能或 VS Code 扩展之前，X 就已经预示了一个事实：所有需要实时获取 X 帖子、书签、趋势或 API 文档的 AI 代理系统，都不应再靠爬虫或私有封装来维持连接。MCP（Model Context Protocol）是 Anthropic 力推的开放协议，X 此次直接用官方托管服务接入，无异于将「AI 读取 X 数据」这一条主线数据源从第三方手里收回。

两大MCP服务器各司其职

官方公告中直接列出了两个托管 MCP 服务器。第一个是 X MCP，地址为 https://api.x.com/mcp，它面向的是需要 X 平台实时内容的 AI 代理。其可执行的四大类操作分别是：搜索帖子、管理书签、读取趋势和新闻，以及用你的账户权限起草或发布文章。第二个是 Docs MCP，地址是 https://docs.x.com/mcp，面向的是需要 X Developer API 文档的开发者代理。它不执行写操作，设计为只读服务，用来在 Cursor、Claude 等客户端内实时检索 X API 文档页面和 OpenAPI 规范。

继《科创板日报》率先披露后，阿里全面禁用ClaudeCode的消息迅速被多家媒体跟进报道。这一决策背后的逻辑，远不止一次简单的内部工具调整，而是为整个行业敲响了关于AI代码助手安全的警钟。

我让AI对消息来源进行了快速溯源，确认了信息的原始出处：

原始报道页面清晰地记录了阿里此次内部通告的核心内容：

详情可查阅《科创板日报》原文：https://www.chinastarmarket.cn/detail/2416378

目前尚无法预测该事件是否会进一步酝酿扩大，但从近期趋势来看，这很可能不是一个孤立的企业选择。过去，一款工具受欢迎与否，程序员的双脚会自动投票；当工具好用、能有效提升效率时，开发者会自发地将其纳入日常开发流程。然而，一旦被贴上“风险”这一显性标签，企业决策的天平就立刻倾向于预先切断潜在隐患。可以预见，后续会有越来越多的公司公开表明态度，明确禁止在办公环境下使用类似的外部AI编码工具。

对大多数普通用户而言，真正的遗憾在于，他们也许还没来得及深入体验这类高效工具的便捷，就需要面对一道突然落下的闸门。特别是当相关问题被摆上台面、公开讨论之后，全面禁用的可能性就骤然增大。如果真到了那一步，Claude Code连同它背后的模型，恐怕会被重新界定为具有安全隐患的危险工具，届时不仅使用受限，整个生态与创新节奏也将受到深远影响。

事情要从一顿饭说起。

前几天跟朋友吃饭，他掏出手机给我看——里面整整齐齐装了四个AI工具，豆包、Kimi、DeepSeek、千问，一个都不少。我问他平时用哪个最多。

他想了想说：“都差不多，哪个先回我消息就用哪个。”

我当场愣住了。

你琢磨一下这画面：同样的问题，复制粘贴到四个对话框，然后像等外卖一样盯着屏幕，看谁先弹出结果。是不是带着点荒谬感？

不过说实话，类似的傻事我也干过。DeepSeek最近热度高，就切到DeepSeek；豆包出了新功能，又忍不住换回豆包；听说Kimi处理长文档厉害，赶紧去试试；千问能直连钉钉，顺手也装上了。工具越装越多，实际产出速度却并没有飞跃。

坦白讲，这不叫选AI，这叫碰运气。

一个普通上班族想用好AI，根本不用上来就纠结哪个最强、哪个参数碾压。你只需要根据手头的活儿，判断它属于四个场景里的哪一个：「想」「做」「读」「查」。

01 场景一：「想」

所谓“想”，就是把一堆零散的信息消化透、理清逻辑，再输出成结构化内容——周报、汇报、方案、邮件，全是这个类型。

我的主力一直是DeepSeek。它有一种本事，别的工具很难替代：搭结构。你丢给它一段毫无章法的工作记录，想到哪写到哪那种，它能帮你拆出背景、进展、问题、下一步，逻辑清清楚楚。

但并不是所有需要“写”的工作都得动用DeepSeek。回个客户消息、发条群公告、写句活动文案这一类不太需要烧脑的轻活儿，豆包反而更快更自然。它的语气更贴近日常交流，不会动不动就给你写小作文。

还有一个容易被忽视的技巧：如果需要啃大量资料再产出深度报告，可以让Kimi先把材料“吃”一遍提炼关键信息，再把精华丢给DeepSeek搭框架。别指望单一工具包打天下。

02 场景二：「做」

做PPT、做表格、整理文件——这是我个人最烦的一类工作，不需要多深度的思考，却会消耗大量时间，一堆乱糟糟的材料等着你变成能交差的东西。

豆包今年6月上线的「办公任务模式」，我试过一次后觉得确实有点东西。你只需说一句“做一份Q2复盘PPT”，它就会自己打开Excel分析数据、打开PPT进行排版，直接交付成品。

当然也不是什么PPT都一股脑儿丢给豆包。遇到战略复盘这类有深度的内容，更稳妥的做法是先让DeepSeek理清楚整体架构，豆包再负责排版和图表，各自发挥长处。

03 场景三：「读」

看合同、看论文、啃行业报告、研读竞品资料——真正动笔写的时候往往很快，但前面这个“读”的阶段，能耗得人筋疲力尽。

Kimi的本质就是一个专吃文档的工具。

我有一位做律师的朋友，把六份几十页的合同一起丢进去，要求它逐条对比条款差异、标注潜在风险。原本三四天才能干完的活儿，三个小时就收拾利索了。对于特定岗位来说，这种能力真的是刚需。

但也别什么“读”都上Kimi。

一两页的会议纪要、十来页的周报，DeepSeek和豆包都能轻松消化，没必要专门切到Kimi。Kimi的不可替代感，只有在你要读的东西多到自己根本读不完的时候才会真正显露出来。

04 场景四：「查」

这里的“查”，跟你平时打开搜索引擎敲关键词不完全一样。它更像是：你需要摸清一个行业正在发生什么，几家公司各自是什么策略，政策最近又有什么变化，然后再把这些信息消化成自己的判断。

我自己反复试验后用得最顺手的一套流程，是“豆包搜 + DeepSeek分析”的组合拳。

先让豆包去做源头搜索，再把结果喂给DeepSeek，让它拆成行业现状、变化方向、对你的影响，以及能直接写进汇报的三句话。一套流程走下来，拿到的成果几乎可以直接用。

如果公司本身在钉钉、阿里云体系里，千问当然最顺手，查资料、发文档到钉钉群一条龙。不在这个体系里的，千问当成候补选手就行。

有一点我必须放在前面强调：凡是要对外发布、要写进合同、要放入正式汇报的任何内容，务必自己点开原始来源看一眼，不要盲信。AI给的答案当草稿非常好，直接当终稿却很危险。

最后的话

实话实说，四个工具全装真的没必要。来回切换的隐性成本，比你以为的高得多。

我的建议很简单：选一个主力，再加一个补位。

主力用DeepSeek。免费、有头脑、什么都能聊，日常工作里80%的活儿它都能稳稳接住。你先拿它老老实实写一周的周报、方案、邮件，一个星期之后，你自然就能感觉到哪里还不太够用。

然后，根据你最大的痛点去补那第二个工具。

如果天天跟PPT、表格打交道，补豆包。如果成天读合同、啃论文，补Kimi。如果公司深度绑在钉钉体系里，补千问。

一周之后要是还不确定该补谁，那就别补了。一个DeepSeek，已经够你用很久。

还有三个坑，我提前帮你踩过一遍。

第一，别一上来就付费。免费版真的够用，与其给工具充会员，不如把精力花在提升自身的AI技能上。2026年之后你会慢慢发现，会用AI正在变成和会用Word一样的默认技能，简历上多一行实打实的背书，比冲个会员划算多了。

第二，别把公司的敏感信息往上贴。道理都懂，但真的有人会忘。

第三，同一个任务别反复换工具尝试。很多时候问题不出在工具身上，而是你给它的指令不够清晰。先把prompt改明白，比在三个工具之间来回碰运气有效率得多。

当财政部长开始谈论模型水印，AI竞争就从实验室搬到了制裁清单上。

01 蒸馏：一个技术术语如何变成制裁借口

7月21日，美国财政部长贝森特在福克斯商业频道的节目中放话，特朗普政府将调查中国AI模型是否通过“蒸馏”手段窃取了美国模型的能力。他警告说：“如果我们发现海外模型在抄袭我们伟大的公司，我们有能力因此对其进行制裁。”

所谓蒸馏，本是AI领域一种常见的训练技巧：用一个强大模型的输出来训练一个更小、更低成本的模型。就好比学生不啃原版教材，只抄老师的答案来学习——效率高，成本却只有零头。Meta、Google等美国公司都公开发表过蒸馏研究，所以它本身是公开的技术。

争议的焦点在于：是否未经授权，直接使用特定商业模型的输出数据来训练竞争对手的模型。贝森特将这一技术问题推向了制裁的雷区。

02 Anthropic指控阿里巴巴发动“最大规模蒸馏攻击”

贝森特的言论并非没有源头。6月24日，人工智能公司Anthropic向美国参议院银行委员会提交了一封信，指控阿里巴巴对其展开了“已知最大规模的蒸馏攻击”。信中使用了“公然地”和“非法地”这样严厉的措辞，称阿里巴巴大量调用Claude API，系统性地抽取模型能力，并将其用于训练自家的通义千问系列模型。

贝森特还补刀：“我们正在许多中国模型上发现美国大语言模型的水印，这无法接受。接下来几天或几周内，我们将仔细审查此事。”这里所说的“水印”，是AI公司悄悄植入模型输出中的隐蔽标记，就像纸币中的防伪图案。如果竞品模型里检测到这些标记，就强烈暗示其训练数据包含了原模型的输出。

03 Kimi K3：2.8万亿参数直逼第一梯队

制裁威胁的背后，是中国开放权重模型正迅速缩小与美国的差距。7月17日，月之暗面推出Kimi K3，参数规模高达2.8万亿，成为中国迄今最大的AI模型。在编码和通用智能体等多项基准测试中，K3超越了Claude Opus 4.8和GPT-5.5，不过仍落后于两家公司的旗舰模型Claude Fable 5和GPT-5.6 Sol。

月之暗面在5月刚完成20亿美元融资，估值突破200亿美元，投资者包括阿里巴巴和腾讯。中国模型的成本优势正在吸引西方开发者——执行同样任务，调用中国模型的花费可能只有美国模型的几分之一。需要说明的是，“开放权重”指的是公开训练后的参数供下载使用，而底层代码与训练数据仍处于保密状态，这并不等同于完全开源的模式。

04 美国公司的版权旧账与双重标准

贝森特将蒸馏定性为“IP偷窃”，但美国AI巨头自身也难逃类似的争议。2025年9月，Anthropic同意支付15亿美元，以了结作家提起的集体诉讼——这些作家指控Anthropic从盗版数据库非法下载书籍用来训练模型。更早在2023年12月，《纽约时报》起诉OpenAI和微软，指控其使用版权内容训练模型，该案至今悬而未决。

这里显然存在一个双重标准：美国公司用公开文本训练模型，背负的是“版权侵权”的指控；而中国公司用模型输出训练竞品，却被直接认作“偷窃”。两种行为的法律边界都还没有在法庭上最终划定，却已被打上了截然不同的标签。

05 9月谈判桌：制裁落定还是暂时搁置？

据路透社7月21日报道，中美计划于9月举行专门的人工智能谈判，贝森特将代表美方出席。这意味着蒸馏争议不会停留在口头阶段。如果美方在谈判前完成水印检测并公布结果，制裁极有可能从姿态变为实际行动。

届时，最核心的技术事实将成为谈判桌上的首议题：中国模型是否真的嵌有美国水印？检测方法是否经得起推敲？对于开发者和企业用户来说，眼下更紧迫的则是合规风险。一旦制裁落地，那些使用中国开放权重模型进行二次训练或商业部署的团队，将首当其冲。

来源：CNBC，《Bessent says U.S. could sanction China over AI model theft》，2026-07-21；CNBC，《Anthropic accuses Alibaba of campaign to brazenly and illicitly extract AI capabilities》，2026-06-24；CNBC，《Chinese AI has leveled up, and brought renewed focus on the open weight model shift》，2026-07-17。

在一次 Web 服务测试中，我突发奇想将端口号指定为 10080，结果网页无论如何都打不开。

让 AI 辅助排查，它也一头雾水，给出的都是“一切正常”的答复。我用 curl 测试，响应确实没问题，但浏览器就是无法访问。

换了不同的机器和浏览器，在 Chrome 中看到的提示如下：

Firefox 给出的错误信息则是：

把 Firefox 的提示截图喂给 AI 后，它终于恍然大悟：

原来，Chrome 和 Firefox 的内部代码中都硬编码了一份受限制的端口黑名单，而 10080 恰恰在其中。

将端口号改为 18080 后，网页立刻恢复正常加载：

这是我这两天搭建的一个内部服务，用于查询火山引擎 coding plan 使用量，部署在内网环境。

浏览器内置的受限端口完整列表可参考规范：

https://fetch.spec.whatwg.org/#port-blocking

在搭建 Web 服务时，务必避开上面列出的这些端口，因为它们已经直接写进了 Chrome 和 Firefox 的源代码中，稍不注意浏览器就可能拒绝连接。

波兰的集体焦虑，从来不只是领土问题——它是一个关于「大使馆何时会变成议会厅」的建筑学问题。

Mateusz Zwijacz 在 Bartlett 建筑学院的毕业设计中提出了一座跨越芝加哥肯尼迪高速公路的波兰大使馆。这个方案的核心矛盾在于：当一个国家历史上频繁由流亡政府执政，大使馆就必须同时满足外交安保与侨民社区公共性的双重需求，而这两者在空间逻辑上天然对立。Zwijacz 的回答是：用数字制造重新翻译波兰乡土装饰，让纹样同时承担文化标识与空间组织框架的双重功能。

波兰大使馆概念渲染：建筑跨越肯尼迪高速公路，将被基础设施割裂的波兰三角区与周边社区重新缝合。

以高速公路为线的城市缝合

芝加哥肯尼迪高速公路既是城市最繁忙的动脉，也是一道物理屏障，它把历史上波兰移民聚合的「波兰三角区」与毗邻的波兰社区分割开来。Zwijacz 把大使馆直接架设在高速公路上方，并非为了制造地标，而是让建筑本身充当一条「城市缝线」，重新接通被基础设施切断的街道网络。

这一策略在建筑史上并非孤例——柏林的 Sony Center、首尔的东大门设计广场都曾尝试用大跨度结构弥合城市肌理。但大使馆项目叠加了安全维度：外交建筑需遵循联邦安保标准，高速公路的噪音和振动又对结构设计提出了额外约束。Zwijacz 的方案将这些约束转化为设计条件：高速公路的线性特征被吸收进建筑的平面组织，安保动线与公共动线在垂直方向上实现清晰分离。

Goral 木雕纹样转型：从山区木构到 CNC 铝板幕墙

项目的建筑语言源自波兰南部山区 Goral 族群的木雕装饰传统。原本，Goral 装饰出现在木屋的门楣、窗框和家具上，以几何化的植物纹样和对称构图著称。Zwijacz 将这些手工纹样转译为 CNC（数控机床）可加工的参数化系统，使装饰从手工艺产品蜕变为数字制造的建筑构件。

这种转译绝非简单的图案放大。在传统语境中，Goral 装饰服务于木结构的构造逻辑：纹样的凹凸对应木板的搭接方式，雕刻深度影响着排水与防腐。当纹样脱离木构语境、进入钢铝幕墙系统时，原始的构造关联被切断，装饰演变为纯粹的视觉符号。Zwijacz 的做法是先承认这一断裂，再于新材料系统中重新建立起纹样与构造的对应关系：CNC 加工的铝板折边既是装饰纹样的载体，也同时扮演着幕墙排水构造的角色。

同届 Archie Koe 的巴斯温泉站同样探讨了传统结构逻辑（罗纹扇形拱顶）在当代材料中的转译，其木材-石材复合系统展示了乡土构造的现代路径。

双重模式：一座大使馆如何兼具外交堡垒与侨民议会厅

Zwijacz 在项目描述中提出了一个极少被讨论的大使馆功能假设：如果波兰再次陷入地缘政治危机，大使馆需要转变为临时议会厅。这并非空想——波兰历史上曾多次在境外维持政府运作，从 19 世纪的流亡政府到二战期间的伦敦波兰政府。因此，大使馆的空间设计必须兼容两套截然不同的功能模式：日常外交模式（低安保密度、开放的文化展示空间）和危机模式（高安保密度、可承载政府运作的封闭空间）。

建筑通过装饰纹样的多尺度操作来兑现这种双重性。在建筑外观上，Goral 纹样提供文化标识，使大使馆在芝加哥建筑群中具有清晰可辨性；在内部空间层面，纹样的疏密变化界定出安保等级——纹样越密集的区域安保等级越高，越稀疏则越开放。这种做法将安保分区从传统的「禁止进入」门禁逻辑转化为「视觉密度渐变」的空间引导逻辑。

同届 Lia Penela Failde 的 Bishopsgate Low Level 项目关注基础设施隐藏空间的公共化，通过“可见、不可见与可能”之间的阈值设计，揭示被忽视的城市层积。

Chanunchida Phonoi 的「隐藏河流的解剖」将水基础设施重新构想为公共浴场，其操作过程通过使用与占用保持可见，与大使馆项目共享着“让隐藏系统变得可感知”的设计策略。

屋顶「礼物山」：以公共空间换取政治合法性的设计修辞

项目中还有一个容易被忽略的细节：Zwijacz 把大使馆屋顶设计为可步行的公共公园，并命名为「礼物山」。这是对后共产主义波兰从美国获得建筑赠礼的回应。冷战结束后，美国曾向波兰赠送过若干公共建筑项目。Zwijacz 把大使馆构想为“回赠给芝加哥的礼物”，将波兰南部山区的山地形态转化成城市中的步行公园。

这一设计动作的政治修辞意味浓厚：大使馆不再是单向的外交窗口，而是双向的文化交换节点。屋顶公园的公共性削弱了大使馆的防御感，让侨民社区即使在没有外交事务时也能使用这栋建筑。从建筑策略来看，这走的是一条“以公共性换取合法性”的路径——一旦大使馆成为社区基础设施的一部分，其安保需求便更容易获得社区的理解与支持。

Bartlett 夏季展观察：一千名学生的推测性设计实验

Zwijacz 的项目来自 Bartlett 建筑学院 2026 年夏季展，展览时间为 6 月 25 日至 7 月 12 日，近千名学生参展。今年适逢 UCL（伦敦大学学院）建校 200 周年，参展项目广泛覆盖住房、教育、文化、基础设施、工业和公共生活等议题。Dezeen 作为合作媒体，从参展作品中筛选了十余个项目进行报道，波兰大使馆位列其中。

AI圈又炸了——Claude Fable 5 和 ChatGPT-5.6 Sol 相继发布。

换作过去，任意一条消息就足以让整个圈子沸腾。论坛瞬间被刷屏，公众号连夜赶工输出解读长文，群聊消息疯狂滚动，到处都在喊“这个模型又碾压全场了”“再不用你的AI就要被淘汰了”。那种氛围逼着你觉得自己再不上手，就真的被时代甩在了后面。

可结果呢？Fable 5 用了没几天就被美国一纸禁令掐断，Sol 则只对极少数获批准的合作伙伴开放，我们连边都碰不到。

按理说，这应该让人更焦虑才对。最顶尖的模型明明就在那里，但就是轮不到你。

然而这次，大家的反应异常平淡。朋友圈没有哀鸿遍野，论坛听不到骂声，连平时最爱追新的几个群友也集体静默。

我也是这样。打开新闻扫了一眼，知道有这么回事，转身继续做手头的事。

这种平静不是突然降临的，而是一点点长出来的。

想想是从什么时候开始变的呢？

对我而言，大概是从真正开始拿 AI 干活那一刻。

Codex 的 ChatGPT 毫无疑问是编程能力最强的模型之一，这点没争议。但它有个硬伤——贵，而且额度少得可怜。五小时额度，一个复杂点的任务就可能直接耗光。按照这个消耗速度，我差不多一周用完四次会话，Codex 就只能关掉。

而且我还发现，Codex 总爱把简单问题复杂化，有些我一眼就能看穿的小事，它能绕上大半个小时。

但这些都还不是最关键的。

更要紧的是，我意识到自己根本用不到它的上限。

我做的工作——写方案、写文章、处理 Excel——Deepseek 全能接住。CodeBuddy、Workbuddy 也能接住，GLM 同样可以。第一版生成出来，质量也许差一点，效果也许没那么惊艳，但胜在速度飞快，看完马上就能按你的要求接着改。

再说到我正在做的项目：原型设计、架构搭建、改代码。这些事 Codex 确实做得更漂亮，可你用 CodeBuddy 不是不能做，无非架构没那么稳，代码质量稍微欠点儿。

但对于我经手的这些项目来说，那根本不叫问题。我又不是在造航母，差的那一丁点压根感觉不出来。

说句实在话，Deepseek V4 Flash 的编程水平已经能吊打你们公司最好的程序员了。在没有 AI 之前，这种水平的程序员得高薪供着，平时什么都不用干，就等关键时刻来解决关键问题。

至于 GLM 5.2，那种级别压根不是你这个小公司能消化的，只有传说中的大厂才有资格养着。

再回头看看你公司现在折腾的这些项目，需要大厂级的程序员来操刀吗？说难听点，这项目根本不配。

道理再明显不过，但我花了快一整年才想透。

最顶尖的模型，卷的是数学和编程的极限。那些真正触碰极限的人，是在做大模型训练，在做前沿算法研究，在攻克某个行业级的硬骨头。而我每天干的——写个 API 接口、调个页面样式、写几句 SQL、整理一份项目文档、回复几条客户消息——这些事用 Deepseek 绰绰有余。

那我还慌什么？

坦率讲，焦虑的根源是那种“被时代抛弃”的恐惧。朋友圈里天天有人晒 AI 新进展，公众号每天推送“Opus 4.6 来了，程序员即将被淘汰”“ChatGPT 5.3 出世，全人类面临失业”。看多了，你慢慢相信自己要是没用上最好的，就会跟不上时代。

但你真要停一停想一想：跟上时代，跟用上更好的模型之间，真有必然联系吗？

没有。

说得更直白些，大模型发展到今天，早已超越了绝大多数人的工作需求。让一个行政管理人员去用 Claude Fable 5 和 Deepseek V4，他感觉不出任何区别。让一个写公众号的人用哪个模型写初稿，出来的稿子也就是那个水平。让一个小程序程序员用哪个 IDE 的 AI 写代码，写出来的东西大差不差。

尽管日记App赛道看似拥挤，但Rose Diary的诞生源于一名产品经理独特的视角。这款以结构化复盘模板为骨架、强调审美差异的轻量应用，在434次下载和18元定价的现实中，重新标定了“需求验证”的边界。本文将从市场热点的捕捉、用户教育代价，到全链路决策失误，深度拆解一次从零到一的产品实战。

可能你有所耳闻，我最近亲自从零到一完成了一款名为 Rose Diary 的日记 App。

概括来说，它是一款带有复盘模板的轻量级日记工具，通过几个结构化的引导模板，帮助用户更轻松地完成记录与反思。下面放一张截图，让你对它有直观的印象。

截至目前，Rose Diary 已经获得了 434 次下载，也积累到十几位付费用户。

这个成绩与我的预期仍有差距。但正好借此机会，复盘我在“需求验证”这件事情上的思考。如果你也打算从零到一开发一款 App，相信这些体会能给你一些启发。

一、Rose Diary 的诞生：从需求发现到决策落地

这个过程可以拆成两块：首先是捕捉需求，然后是下定决心去做。

我是如何发现这个需求的？主要靠两点

1. 我在市面上看到卖得很火的“觉察日记”实体书，说明记录类需求有实物验证。
2. 对比了一圈现有的日记 App，确认“用户通过 App 书写日记”这个行为需求本身是成立的。

在需求筛选这个阶段，我直接把它当作 MVP 通过了——实体书和大量竞品已经帮我验证：需求客观存在。

为什么决定动手？当时有３个推动力

1. 我的个人优势
   作为 F 人，又在澳企担任产品经理，我相信自己在审美和产品理念上有一定的长处。当时浏览了大量竞品日记 App，就是觉得它们的设计都不够好看，这正好是我的切入口。

2. 市场热点正在升温
   “频繁记录可以改命”这个话题当时正处于上升期，其底层方法论恰恰是结构化复盘和模板，和我想要打造的产品方向高度重合。

3. 在能力范围内
   调研下来，一款小型日记 App 的开发难度和成本都比较低，完全处在“我能搞定”的区间。

综合以上，需求存在 ✓ 市场上升 ✓ 个人有优势 ✓ 能力可覆盖 ✓
于是，我便启动了 Rose Diary。

二、上线后的复盘：我遇到了哪些棘手问题？

理论中，产品经理应当始终把“用户”与“场景”放在第一位。但坦白说，在开发初期我对用户画像并不清晰，只能模糊地定义成：女性、刚开始接触复盘、对仪式感有一定需求。

为了弥补这一盲区，我在 V1.0.0 版本上线后陆续访谈了大约十位用户。如今回头看，依旧踩了不少坑：

1. 刚需程度与心理价位的错配

需求存在，并不等于需求足够刚。写日记这件事情的刚需程度其实没那么高——不是每个人都能坚持，除非遇到了某个触发契机，或者本身就有习惯。刚需的低频也直接反映在价格预期上。受访用户普遍表示，对一款日记 App 的心理价位并不高。而我们 V1.0.0 版本的内容极为精简，连 iCloud 同步都尚未完善，我一开始却标价 68 元。在了解到用户的真实预期后，我把价格下调到 18 元，这才迎来了第一位付费用户。

产品经理在日常工作中往往面临完美架构与紧迫业务之间的持续拉扯。如何在保持系统可扩展性的同时满足业务快速上线的诉求，是许多产品人反复遇到的挑战。本文借助真实案例，分析业务侧与产品架构侧的深层考量，并给出分层兼容设计的解法，帮助你在短期交付与长期演进之间找到可落地的专业方法论。

一、产品经理的常态：一边追求体系化，一边被推向快速落地

做产品越久，越容易陷入同一个两难：是固守规范、可扩展的产品架构，还是优先满足业务，以最快速度落地？

小蓝近期的设计经历就很典型。从长期演进出发，他希望搭建一套通用、可扩展的产品体系，能够适配未来多样化的规则迭代与跨场景复用。

但业务方给出了明确诉求：当下只需要简单的二选一配置，不需要复杂的能力延展，核心目标是使用极简化、快速上线、保障现有业务正常运转。

最终团队选择了适配业务、优先落地的极简配置方案。功能如期交付，业务端表示满意，可小蓝心里始终有些放不下。

这种不适并非纠结于对错，而是一种产品直觉：短期看似完美的交付，背后可能埋下长期的产品隐患。

接下来，一起看看小蓝是如何在产品和业务之间找到平衡点的。

二、拆解产品视角与业务视角的不同侧重

在这种情境下，产品经理的价值本质在于协调两类截然不同的诉求，这也是设计纠结的根源。

1、业务侧：重当前效率，重操作易用

业务更关心当下流转是否顺畅、一线操作是否简单、客户有没有学习负担，天然排斥过度设计。

实际场景举例：

• 用户场景：一线运营需要日常配置客户审核规则，99% 的情况下只用固定的两种审核模式；
• 功能设计：业务希望页面上只出现两个固定选项，无需多余配置、不需要下拉、也不需要拓展组合；
• 架构实现：业务倾向直接固化两套逻辑，以实现快速上线和零学习成本。

2、产品架构侧：重长期规范，重系统可持续

产品更关注统一标准、逻辑可复用、未来可迭代，希望避免碎片化定制所累积的债务，否则后续一旦出现更多场景，改动成本会非常大。

实际场景举例：

• 用户场景：后续不同客户、不同业务线会陆续增加差异化的审核规则，甚至需要同时按多个规则组合配置；
• 功能设计：需要支持新增配置项、规则灵活切换、条件组合拓展；
• 架构实现：需要统一通用的配置底层架构，用一套结构支撑所有同类规则，避免重复开发。

许多产品经理容易走两个极端：要么死守架构规范，忽略业务落地效率；要么一味迁就业务，无底线地定制，最终系统失控、债务堆积。

三、产品解法：构建分层兼容设计

成熟产品的最优解不是取舍，而是分层解耦：表层适配业务，底层守住架构。让所有方案都可控、不产生债务、且可持续迭代。

1、底层采用通用架构，守住产品底线

底层的表结构、规则引擎、配置架构完全按照通用标准搭建，不因为短期需求而降级架构，提前规避未来重构风险。

实际场景举例：

• 用户场景：当前只需要二选一，但未来规则增量不确定；
• 功能设计：后台支持多配置项、多规则组合、条件联动；
• 架构实现：采用动态配置表结构，预留字段、通用分支逻辑、可扩展枚举，但在本期只支持二选一。

2、上层极简适配业务，保障用户体验

在底层通用架构不变的前提下，前端只暴露当下必需的能力，做到极致简单的操作。

实际场景举例：

• 用户场景：一线用户只需要快速二选一切换，不希望看到复杂界面；
• 功能设计：前端隐藏多余配置，仅展示两个核心选项，界面干净极简；
• 架构实现：底层全量能力保留，可支持后续新增配置项，以及按组合选项进行的配置开发。

四、面对现实，产品经理如何做出“对”的选择？

面对现实与完美的冲突，可以按照以下四步来决策：

第一步：优先保障业务交付

先满足当下核心业务流转，不因追求完美架构而耽误上线节奏。

第二步：打造用户极简体验

不为了预留能力，强行增加用户操作步骤和复杂配置。

第三步：死守底层架构红线

可以在界面层定制，但底层绝不写死、绝不使用一次性逻辑、绝不破坏统一标准。

第四步：预留兜底扩展策略

所有临时适配，都要留出扩展位、留下迭代方案，不产生永久性债务。

五、总结

产品真正的专业度，不是从不妥协，而是妥协有边界、让步有兜底、短期适配不牺牲长期架构。

学会取舍、做好分层设计、接受可控的不完美，是产品经理从执行走向架构、从功能走向体系的核心能力。

过去，产品经理的价值来自哪里？会做需求分析，会写PRD，会画原型，会推进项目，会理解业务，会协调资源……这些能力定义了整整一代产品经理。但从AI真正走进实际业务场景开始，很多事情都在迅速变化。

• 以前花两天的行业调研，现在AI几十分钟就能产出一份完整的初稿；
• 以前需要反复研读、梳理的竞品分析，现在AI可以快速拆解结构、识别差异、提炼结论；
• 以前熬夜写PRD、整理会议纪要、手绘高保真原型的日日夜夜，现在AI都能深度参与，甚至主导初稿；
• 更让人惊讶的是，以前必须靠研发、设计、运营多方配合才能做出的小工具、小应用，现在产品经理借助AI，就可以独自完成一个可交互的Demo。

这引出了一个真正值得深思的问题：当AI已经能够参与产品经理的绝大多数日常工作时，未来的产品经理，什么样的才真正不可或缺？

我们的判断非常直接：不管你过去是做C端、B端、后台、中台还是做数字化产品，只要你不理解AI、不会用AI重塑自己的工作流，从能力底色的角度来说，你就是“传统产品经理”。

传统产品经理，正在被重新定义，也在被加速淘汰。未来真正有竞争力的产品经理，只会剩下两类。

类型一：将AI深度嵌入工作流的产品经理

这一类产品经理，不一定身处在AI公司，也未必在做AI原生产品。他们很可能依然在传统企业、互联网公司的ToB部门、业务部门或者数字化团队中工作。

但他们和普通PM最大的区别在于：他们有意识地把AI深度融入自己的一整套工作流。他们不是在“偶尔用一下AI”，也不是让AI“帮我生成一份PRD”，而是知道如何让AI系统化地承担行业研究、需求拆解、原型构思、知识库搭建、客服系统设计，甚至自动化完成一部分重复性工作。

举个例子，当老板突然问：“我们现在的业务流程能不能接入AI？”普通PM只能说“我再研究一下，找个技术聊聊”。而深度使用AI的PM，可以马上判断这个场景的可行性：需要用大模型直接生成，还是走RAG方案？是不是要接入知识库？能不能先用低代码平台跑出一个Demo？背后需要哪些数据支撑？

这类产品经理最大的价值，是帮助非AI原生企业完成AI化的渐进改造。

未来的很长一段时间里，70%到80%的公司依旧是传统企业或传统业务，它们不会在一夜之间变成AI公司，但它们都迫切需要被AI改造。而这中间，正是深度使用AI的产品经理们释放价值的巨大空间。

类型二：AI原生产品经理

如果说第一类产品经理，是用AI来“改进已有业务”和“优化现有工作流”，那么第二类产品经理，就是直接面向AI时代，去构思、定义、交付原生于AI的产品。

他们思考问题的原点，已经不是“我要设计一个页面、一个功能、一个流程”，而是：

• 这个产品中，AI该扮演怎样的角色？
• 哪些任务应该由Agent自主完成？
• 产品如何安全高效地调用外部工具、接入数据、编排自动化动作？
• 哪些环节需要RAG？哪些环节适合用Workflow配置？
• 如何设计一套能够持续学习、持续进化的AI产品体验？

过去的产品经理，更多是在设计“确定性的功能”：按下按钮，一定会跳转到某个页面；提交表单后，一定进入某一条预设流程；用户输入，系统返回一个固定的结果。

但AI原生产品完全不同。它的核心，是让系统具备理解、生成、推理、调用外部工具，并最终完成任务的能力。这意味着，产品经理不仅要深刻理解用户和业务，还必须掌握大模型、Agent、上下文工程、MCP、Skill、AI IDE等等概念背后的产品逻辑，并能在产品设计中真正运用它们。

这一类应用型AI产品经理、AI原生应用产品经理，一定会成长为未来产品岗位里增长最快、前景最广阔的一类人。因为他们不只是“写需求的人”，他们更像是AI产品的设计者、组织者和创造者。

从更长的周期来看，越来越多的传统公司将被AI改造，而越来越多新公司会直接以AI原生的方式诞生。产品经理能力演进的最终方向，就是向AI原生产品经理不断靠近和跃迁。

如何向这两类AI产品经理进化？

方向其实已经非常清晰了。

短期而言，先让自己成为一个真正会用AI的产品经理，在日常真实工作场景中把AI融进去，用它去提高效率、提升质量、放大个人产出。

长期来看，向AI原生产品经理持续进阶：理解AI产品的底层逻辑，掌握Agent、RAG、API、Skill以及AI编程等关键能力，并且能够亲手做出一个可展示、可运行、能清晰讲清楚逻辑的AI项目。

AI时代，产品经理这个岗位不会消失，但传统产品经理注定会被重新筛选。未来真正有价值的产品经理，要么能深度使用AI，把工作效率和产出质量拉升到全新的层级；要么能理解AI原生产品的设计方法，真正参与到新一代产品的创造和落地中去。