AI 写代码越来越快，但开发会议上被问「这个功能的状态有哪些」时答不上来、产品改需求时发现流程根本没想全——这种尴尬不是个人能力问题，是产品架构没搭好。本周掘金上一篇产品方法论文章把这件事讲得很具体：一张功能清单表，四张图（信息架构、功能架构、业务流程、状态机），就能把任何产品的骨架理清楚。我们注意到，这件事在 AI 时代反而比过去更值得讨论。

这是什么

文章来自掘金作者「怕浪猫」，是产品经理系列教程的第 5 章，核心主张是：产品架构的本质是「把产品的所有要素组织起来的结构」，它的价值不在于交付文档，而在于强迫你把脑子里的 200 个功能点、50 个流程节点、30 个角色理清楚。

作者给出一套可操作模板：

  • 1 张表：功能清单/需求矩阵，包含 ID、模块、功能名称、用户角色、优先级、依赖关系六列。模块划分有两种思路——按业务域（适合复杂 B 端）或按页面入口（适合 C 端）。
  • 信息架构图：回答「产品里有哪些信息，信息之间什么关系」，是数据库设计的基础。
  • 功能架构图：用分层结构（基础能力层→内容供给层→运营层→展示层）回答「哪些功能可以复用」，避免重复造轮子。
  • 业务流程图：把用户走每一步的分支（包括异常分支）全部穷举，没有这张图，上线后就会出现各种没想到的 bug。
  • 状态机图：回答「一个对象有哪些状态，状态之间怎么切换」，文章在截断处戛然而止。

行业怎么看

支持的声音认为，AI 编码工具（如 Cursor、Copilot）确实把「写代码」从瓶颈挪开了，但 PRD（产品需求文档）评审时开发问一句「状态有哪些、边界条件是什么」，AI 帮不了——这些判断必须来自产品经理的架构思维。一位资深产品总监在我们采访里说：「AI 越强，越暴露产品经理的短板。」

但也有反对意见值得听。一位独立开发者认为，把架构画到这种颗粒度本身是过度设计，早期产品一天改三次方向，画四张图的成本远超收益；应该先用低保真原型跑通验证，再补架构图。另一些声音指出，这套方法论高度依赖业务域稳定，对 SaaS（订阅制软件）和 AIGC（AI 生成内容）这类边界不断变的产品，模块划分「按业务域」会很快失效。

对普通人的影响

对企业 IT：如果你们公司正在做 AI 转型、内部系统重构，这件事比「用哪个大模型」更值得优先讨论——架构不清晰，AI 再强也是给混乱加速。

对个人职场：产品经理、需求分析师、解决方案顾问这类岗位，「能不能画清楚」正在替代「能不能写清楚」成为新的硬通货。

对消费市场：短期内不会有直接影响，但你会更快地用上更稳定、更少 bug 的 App 和 SaaS 工具——前提是背后的产品经理在认真画图。