Hi，我是穆伽罗 Nick，Product Maker。 我的经历很杂，本硕分别学过信息管理、金融与人机交互；也在实战中做过市场营销、产品管理与用户体验相关的工作。这些广泛的尝试，让我逐渐形成了一种更复合的工作方式：站在 PM、UX、Design Engineer 与 GTM 的交界处，把问题从用户、商业、设计与技术几个角度同时看清楚。 我不太执着于单一的岗位标签，而是更关注两个全局目标： - 如何借助 AI，减少市场、产品、设计和工程之间的转译损耗，让一个好想法更快进入可感知、可测试、可迭代的状态。 - 如何重新理解 AI Native 产品：当 Agent 成为体验的一部分，而不只是被嵌入界面的功能时，我们应该如何设计新的交互、工作流和产品判断方式。 如果你也在思考 AI 新的产品形态，通过 Agent 工作流如何提升传统团队效率，亦或是对我的经历背景感兴趣，都欢迎联系我：[me@nickmu.com](mailto:me@nickmu.com)，[小红书](https://www.xiaohongshu.com/user/profile/60014282000000000101f69b)，[LinkedIn](https://www.linkedin.com/in/nickmu/)，[X.com](https://x.com/lofinickisme)。 [简历附件](https://typst.app/project/rilmnBqQ0Mu87FHcjBo3WV) ## AI 时代的 Product Maker 企业存在的一个重要原因，是为了降低外部交易成本：当外部协作的交易成本过高时，企业会把这些协作内化到组织内部（[Ronald Coase, “The Nature of the Firm,” 1937](https://onlinelibrary.wiley.com/doi/full/10.1111/j.1468-0335.1937.tb00002.x)）。但在传统软件工程里，组织内部同样会产生新的成本：沟通、协作、交接、排期和反复对齐。团队越大，这些摩擦往往越明显。《人月神话》讨论的也是类似的问题：真正拖慢事情的，很多时候不是技术本身，而是组织内部不断累积的协调成本。 AI 真正改变的，不只是生产效率，而是角色之间的边界以及团队概念的重新定义。过去需要 PM、设计、GTM 等角色反复流转的事情，在很多早期探索和原型阶段，已经可以收敛到更小更快的个人回路中。 这是我把自己定位为 Product Maker 的原因。相比于单纯做市场调研、产品设计、UX 原型或需求文档，我更在意“解决问题”本身：能不能减少转译损耗，把市场洞察、用户需求、产品设计和原型实验压缩在同一条低摩擦链路中；能不能用 AI、设计和代码，把一个模糊想法更快推到可感知、可测试、可讨论的状态。 Product Maker 的价值，不只是更快完成任务，而是更快形成判断，并更快把判断转化为可验证的价值。我把这种角色变化理解为：原本分散在多个岗位之间的判断、设计与实现，正在被重新压缩进更小的个人闭环中。 ![newrole](https://nickmu.com/image.png) *图示参考 [@goocarlos](https://x.com/goocarlos/status/2041612990869598276) 的观点* ## 新的 Benchmark 在 AI 时代，单一任务的成本正在快速下降。真正稀缺的，不再只是“会不会做”，而是“能不能更快发现值得做的事，并把它验证出来”。所以我更看重的，不是单个任务完成得多快，而是两个更上层的飞轮： ![doublediamond|right](https://nickmu.com/content-assets/image-1.png) *来源 [designcouncil](https://www.designcouncil.org.uk/our-resources/the-double-diamond/)* - **Time to Insight**：从观察、理解、实验到形成判断的速度 - **Time to Value**：从判断到产出真实价值，并被继续验证的速度 这意味着，好的产品工程不只是提速旧流程，而是让这两个飞轮转得更快。设计和研究的价值，不只是产出方案或报告，而是帮助我们更快抽象需求、形成判断，并把这些判断推进到可验证的产品演化中。 这也意味着，产品判断不能完全依赖层层转译后的二手信息。用户反馈、市场信号、实验结果和技术约束都很重要，但它们最好能在同一个高密度的认知闭环中被快速吸收、重组和验证，而不是在过长的协作链路里逐层损耗。 今天，AI 放大了个体闭环的半径。从用户调研、原型规划、界面交互到技术验证，一切都能够在同一个高吞吐量、低内部摩擦的工作流中连续发生。因此，我的实践并不只是“用 AI 做得更快”，而是围绕一套新的产品工作系统，分别加速 insight 飞轮和 value 飞轮，并让二者互相反哺。 这套工作系统主要落在两个方向上：一类是对现有工作流的重组与优化，另一类是对 AI Native 产品形态的持续探索。 ## 我的产品工作系统 我更习惯把产品工作理解成两个可以持续加速的飞轮，而不是线性的分工链路。这个系统的核心载体，是我正在实践的 repo convention：EDF 2.0。更完整的工作系统页面请看 [work-system](https://nickmu.com/zh/work-system)。 EDF 的全称是 Executable Design File。它不是另一个 PRD 模板，也不是单纯的 Design-to-Code 工具，而是一套把产品判断、业务逻辑、数据契约、界面表达、代码实现和验证机制放进同一个 repo 里的工作系统。这个名字背后的目标，是让设计文件不再只是静态交付物，而是成为 Agent 可以读取、调用、修改、验证，并最终推动实现的可执行产品资产。 ### 把产品上下文沉淀为单事实来源 在传统流程里，洞察、定义、设计、开发和验证，往往分散在不同角色、文档和工具之间。信息在流转中不断被转译，判断也容易在交接中被稀释。EDF 2.0 想解决的正是这个问题：让产品上下文不只停留在会议、聊天记录或设计稿里，而是沉淀成 Agent 和人都能反复读取、审阅和更新的单事实来源（SSOT）。 它把产品工作压缩成两个互相咬合的飞轮：一个负责更快形成判断，另一个负责更快把判断推向可验证的价值。 概念结构： ```text Time to Insight 飞轮 Signal / Why → Judgment / What 用户、市场、实验和技术信号 → 问题定义、状态流转、产品假设 ↓ 推动 Time to Value 飞轮 Interface → Prototype / Src → Feedback / Test 界面表达 → 可运行实现 → 使用反馈、自动化验证、跨层校验 ↺ 反哺 新的反馈和实验结果回到 Time to Insight 飞轮 ``` ### 让产品内容进入 Agent 可操作的上下文 所以，EDF 2.0 的目标不是让 AI 简单参与某一个环节，而是让产品工作中不同形式的内容，都变成 AI Coding Agent 可以读取、调用、修改和验证的对象：文档、状态机、设计稿、接口契约、代码、测试，都不再只是各自孤立的产物，而是可以被纳入同一个工作系统的上下文材料。 更重要的是，它试图把工作流里原本分散在不同工具、格式和角色之间的内容，转换到一个互相兼容、可以被持续压缩和重建的 context window 里。这样一来，产品判断、界面表达、技术实现和反馈验证就能在同一个上下文中快速迭代，而不是每一步都重新解释、重新交接、重新对齐。 ## 两个实践方向 基于这个目标，我的实践主要分成两个方向：一类是优化现有工作流，减少设计、产品、开发和 GTM 之间的上下文损耗；另一类是探索 AI Native 产品形态，思考当 Agent 本身成为用户体验的一部分时，产品应该如何被重新设计。 ### 1. 优化现有工作流 第一类实践，是用 EDF 2.0 重新组织已有工作流。这里的重点不是把某个单点步骤自动化，而是减少产品、设计、开发和 GTM 之间反复转译的损耗。传统协作里，一个想法往往要经历多次格式转换：用户反馈被整理成需求，需求被写成 PRD，PRD 被翻译成设计稿，设计稿再被翻译成代码，代码上线后反馈又重新回到文档和会议里。每一次转换都会损失一部分上下文，也会让最初的判断变得越来越间接。在这里，EDF 2.0 更像一层活在 Git repo 里的产品工作约定：它把不同形式的内容放进同一个上下文，让它们可以被 Agent 读取、转换、对齐和校验。 工作流结构： ```text 不同入口 用户反馈 / GTM 文案 / 设计草稿 / 代码原型 / 市场观察 ↓ 进入 EDF 2.0 Context Why / What / Interface / Src / Test ↓ Agent 操作 读取、转换、补全、抽取、校验 ↓ 可运行产物 页面、原型、接口、测试、文档 ↓ Guardrails 预览、测试、Diff、人工审阅 ↺ 回到 EDF 2.0 Context ``` 这里我主要关注三种工作原则。它们不是独立功能，而是为了回答同一个问题：不同形式的产品内容，如何进入、回收并持续校验到同一个上下文里。 1. **Any-Point Entry** 解决“从哪里开始”的问题。视觉强的问题可以从 Interface 进入，业务逻辑强的问题可以从 What 进入，已经有原型的问题可以从 Src 进入，市场和用户问题则可以从 Why 进入。 2. **Reverse Extraction** 解决“如何沉淀回来”的问题。当原型或页面先跑起来后，Agent 可以从已有代码、界面和交互中反向抽取状态流转、接口契约、设计约束和异常分支，把一次性的实现重新沉淀为可复用的产品资产。 3. **Guardrails** 解决“如何避免跑偏”的问题。通过测试、契约校验、跨层 Diff 和人工审阅，持续检查代码实现、界面状态和最初产品判断之间是否发生漂移。AI 可以快速生成和改写，但它需要被明确的产品上下文约束。 #### 实例 一个典型例子是 Design to Front-end Dev。过去设计稿到前端代码之间通常需要大量口头解释、标注、组件对齐和返工；在 EDF 2.0 的思路里，设计表面不只是给人看的图，而是包含布局、状态、组件语义和交互意图的可读写材料。Agent 可以读取这些材料，并结合 repo 里的组件、接口契约和实现约束，生成更贴近真实代码库的前端实现。 > 需要补充具体示例，注意颗粒度，提到 agent 用了什么？具体工具软件实现？不要写成理论分析。[IMPORTANT]。 > Design to Front-end Dev（paper / specs api (spec-based dev?)<-> coding agent + repo <-> front-end code） 另一个例子是 GTM 到 Product Design 的反向迭代。很多市场反馈、用户话术和定位实验，原本只停留在文档、邮件或发布内容里；但它们其实包含了对用户需求和产品价值的判断。通过 EDF 2.0，这些信号可以回到 Why 和 What 层，继续影响信息架构、界面表达、功能优先级和实验方向。 > *这里具体讲一到两个案例，目的是讲清楚，基于 edf 2.0, 在整个工作流中，不同分工间的上下文损耗与反复转译是怎么减少的。[IMPORTANT] 所以，优化现有工作流的目标，不是让人退出流程，而是把产品进化拆成两个可以更快旋转的飞轮：一个加速 **Time to Insight**，更快从市场、用户、实验和技术变化中形成判断；另一个加速 **Time to Value**，更快把判断推进到可运行、可验证、可迭代的产品结果。 设计和研究的本质，是抽象需求并推动产品进化。但当某些进化可以通过 A/B test、翻转实验、快速原型或真实使用反馈更快达成时，设计和研究就不必总是作为漫长的前置流程，而可以成为两个飞轮中的高频输入。我的任务，是尽量减少转译损耗，让 insight 和 value 的循环速度在量级上变快。 ### 2. 探索 AI Native 产品 第二类实践，是探索那些不是“给旧产品加一个 AI 功能”，而是从模型能力、Agent 行为和人机协作关系出发重新生成的产品形态。 这一方向更偏向 **Time to Insight**：通过快速原型和实验，理解 AI Native 产品的边界、交互模式和真实价值。 ## Taste is a subtle art. 当 AI 大幅降低执行成本，当 efficiency 变成 baseline，真正稀缺的反而变成了判断与品味。因为当大多数人都能更快地产出界面、文案、代码和方案时，差异不再只来自“能不能做”，而来自“知道什么值得做、做到什么程度、以什么质感呈现”。 我理解的 craftsmanship，不只是视觉上的精致，而是对信息密度、交互节奏、状态反馈、边界处理和整体气质的持续打磨。AI 可以放大产能，但产品最终是否值得被使用，仍然取决于这些细微但关键的判断。 ## 欢迎联系 [me@nickmu.com](mailto:me@nickmu.com) [小红书](https://www.xiaohongshu.com/user/profile/60014282000000000101f69b) [LinkedIn](https://www.linkedin.com/in/nickmu/) [X.com](https://x.com/lofinickisme) 如果你正在思考 AI 产品、Agent 工作流，或者对这些问题有相似兴趣，欢迎和我交流。