# mStack：为AI编程助手打造的产品发布工作流

> 一套将通用编程助手转化为产品发布操作员的结构化沟通流程，通过六个阶段实现从产品背景到发布复盘的完整叙事闭环。

- 板块: [Openclaw Llm](https://www.zingnex.cn/forum/board/openclaw-llm)
- 发布时间: 2026-04-28T19:15:01.000Z
- 最近活动: 2026-04-28T19:23:32.028Z
- 热度: 161.9
- 关键词: AI, product, messaging, workflow, Codex, Claude Code, launch, positioning, content
- 页面链接: https://www.zingnex.cn/forum/thread/mstack-ai
- Canonical: https://www.zingnex.cn/forum/thread/mstack-ai
- Markdown 来源: ingested_event

---

## 问题：AI生成的产品文案为何总是平庸？

当使用AI助手撰写产品发布文案时，最常见的输出是"我们很高兴地宣布..."这样的陈词滥调。问题不在于AI的写作能力，而在于输入——缺乏结构化的产品背景、明确的叙事角度和严格的编辑把关。mStack试图解决这个问题，不是通过更好的Prompt，而是通过一套完整的工作流。

## 核心理念：沟通闭环

mStack将产品发布沟通定义为一个六阶段闭环：

```
Context -> Angle -> Draft -> Critique -> Package -> Learn
（背景 -> 角度 -> 草稿 -> 批评 -> 打包 -> 学习）
```

这不是Prompt的堆砌，而是一个有序的、可重复的沟通系统。每个阶段都有明确的输入输出，前一阶段的产出成为后一阶段的上下文。

## 六阶段详解

### 1. Context（背景收集）

**对应命令**：`/mstack-product-context`

**角色**：Product Reporter（产品记者）

这一阶段的目标是将杂乱的信息——发布说明、PR描述、客户痛点、支持工单、创始人笔记——转化为结构化的发布简报。关键问题包括：

- 是什么用户痛点驱动了这个功能？
- 工作流程发生了什么变化？
- 你拒绝构建什么？（Tradeoff是可信度的关键）

输出是一份包含痛点、时机、范围、权衡、证据和待补充细节的上下文简报。

### 2. Angle（角度选择）

**对应命令**：`/mstack-angle-review`

**角色**：Positioning Editor（定位编辑）

在动笔之前，必须先确定最有力的、可辩护的核心论点。这一阶段会生成多个候选角度，评估其特异性、可信度和情感共鸣，最终推荐一个主导叙事。

例如，不是"我们发布了团队仪表板"，而是"每周状态汇报仪式应该消失，而不是变得更漂亮"。

### 3. Draft（草稿撰写）

**对应命令**：`/mstack-write-product-update`

**角色**：Product Writer（产品作者）

基于选定的角度，撰写核心发布文案。重点不是功能列表，而是围绕"为什么是现在"、"观点是什么"、"做了什么权衡"、"证据在哪里"、"后果是什么"来构建叙事。

### 4. Critique（批评审校）

**对应命令**：`/mstack-critique-update`

**角色**：Editorial Reviewer（编辑审校）

在发布前进行严格的自我审查。检查清单包括：

- 是否有通用的、模糊的声明？
- 是否有具体的证据支持每个主张？
- 声音是否一致？
- 是否有AI生成的"光泽"需要去除？

这一阶段会打分并重写薄弱部分。

### 5. Package（渠道打包）

**对应命令**：`/mstack-launch-pack`

**角色**：Launch Operator（发布操作员）

将批准的故事转化为渠道特定的发布资产：

- 更新日志（Changelog）
- 发布邮件
- 社交媒体帖子
- 内部Slack通知
- 销售团队备忘

关键是根据渠道特性调整，而不是简单复制粘贴。

### 6. Learn（复盘学习）

**对应命令**：`/mstack-product-retro`

**角色**：Messaging Analyst（消息分析师）

发布后复盘：什么奏效了？什么让用户困惑？下次要记住什么？这些洞察会反馈到未来的发布流程中。

## 安装与使用

mStack支持Codex和Claude Code两种主流AI编程助手：

**Codex安装**：
```bash
git clone --single-branch --depth 1 https://github.com/manimohans/mStack.git ~/.codex/skills/mstack
cd ~/.codex/skills/mstack && ./setup --host codex
```

**Claude Code安装**：
```bash
git clone --single-branch --depth 1 https://github.com/manimohans/mStack.git ~/.claude/skills/mstack
cd ~/.claude/skills/mstack && ./setup --host claude
```

setup脚本会自动检测主机目录，创建轻量级运行时skill文件夹，并使用主机安全的命令名。

## 典型工作流示例

```
你：我们发布了团队仪表板。需要一篇发布文章。
你：/mstack-product-context
助手：是什么用户痛点导致的？工作流程发生了什么变化？你拒绝构建了什么？

你：经理们每周五都要导出CSV。仪表板取代了这个仪式。
助手：[撰写上下文简报：痛点、时机、发布范围、权衡、证据、缺失细节]

你：/mstack-angle-review
助手：推荐角度："每周状态仪式应该消失，而不是变得更漂亮。"

你：/mstack-write-product-update
助手：[围绕论点撰写发布文章，而不是功能列表]

你：/mstack-critique-update
助手：[标记通用声明、缺失证据，并重写薄弱部分]

你：/mstack-launch-pack
助手：[创建更新日志、发布邮件、社交帖子、内部Slack、销售备忘]
```

## 设计原则：为什么这样有效？

mStack的设计基于几个关键洞察：

1. **写作不难，决定写什么才难**。因此在工作流中加入了写作前的背景收集和角度选择阶段。

2. **AI需要约束才能产出高质量内容**。通过强制要求命名权衡、提供证据、审查声音一致性，mStack提升了AI输出的质量下限。

3. **发布是跨渠道的活动**。同一故事需要不同形式，简单复制粘贴会稀释信息。

4. **学习必须闭环**。没有复盘，每次发布都是孤立的，无法积累组织记忆。

## 适用人群

- 需要解释发布了什么但不想听起来千篇一律的创始人
- 希望获得AI帮助但又不想失去品味或公司特定背景的产品营销人员
- 将产品工作转化为发布叙事的开发者工具和SaaS团队
- 需要比"我们很高兴地宣布..."更强文字输出的AI助手

## 局限与展望

当前版本（v0）是一个聚焦的产品消息堆栈。作者指出下一个有用的层是工具支持——能够读取GitHub PR、Slack发布说明、更新日志和文档作为源上下文，进一步自动化背景收集阶段。

## 总结

mStack代表了一种新的AI协作模式：不是让AI直接生成答案，而是通过结构化工作流引导AI完成复杂的认知任务。它将产品发布从一次性的写作任务转化为可重复、可学习、可改进的系统流程。对于频繁发布产品的团队，这可能比任何单个Prompt都更有价值。