@zeyue0329/xiaoma-cli 1.0.49 → 1.6.4

package/docs/zh-cn/_STYLE_GUIDE.md

@@ -0,0 +1,370 @@
+---
+title: "Documentation Style Guide"
+description: Project-specific documentation conventions based on Google style and Diataxis structure
+---
+
+This project adheres to the [Google Developer Documentation Style Guide](https://developers.google.com/style) and uses [Diataxis](https://diataxis.fr/) to structure content. Only project-specific conventions follow.
+
+## Project-Specific Rules
+
+| Rule                             | Specification                            |
+| -------------------------------- | ---------------------------------------- |
+| No horizontal rules (`---`)      | Fragments reading flow                   |
+| No `####` headers                | Use bold text or admonitions instead     |
+| No "Related" or "Next:" sections | Sidebar handles navigation               |
+| No deeply nested lists           | Break into sections instead              |
+| No code blocks for non-code      | Use admonitions for dialogue examples    |
+| No bold paragraphs for callouts  | Use admonitions instead                  |
+| 1-2 admonitions per section max  | Tutorials allow 3-4 per major section    |
+| Table cells / list items         | 1-2 sentences max                        |
+| Header budget                    | 8-12 `##` per doc; 2-3 `###` per section |
+
+## Admonitions (Starlight Syntax)
+
+```md
+:::tip[Title]
+Shortcuts, best practices
+:::
+
+:::note[Title]
+Context, definitions, examples, prerequisites
+:::
+
+:::caution[Title]
+Caveats, potential issues
+:::
+
+:::danger[Title]
+Critical warnings only — data loss, security issues
+:::
+```
+
+### Standard Uses
+
+| Admonition               | Use For                       |
+| ------------------------ | ----------------------------- |
+| `:::note[Prerequisites]` | Dependencies before starting  |
+| `:::tip[Quick Path]`     | TL;DR summary at document top |
+| `:::caution[Important]`  | Critical caveats              |
+| `:::note[Example]`       | Command/response examples     |
+
+## Standard Table Formats
+
+**Phases:**
+
+```md
+| Phase | Name     | What Happens                                 |
+| ----- | -------- | -------------------------------------------- |
+| 1     | Analysis | Brainstorm, research *(optional)*            |
+| 2     | Planning | Requirements — PRD or tech-spec *(required)* |
+```
+
+**Commands:**
+
+```md
+| Command      | Agent   | Purpose                              |
+| ------------ | ------- | ------------------------------------ |
+| `brainstorm` | Analyst | Brainstorm a new project             |
+| `prd`        | PM      | Create Product Requirements Document |
+```
+
+## Folder Structure Blocks
+
+Show in "What You've Accomplished" sections:
+
+````md
+```
+your-project/
+├── _xiaoma/                                   # XiaoMa configuration
+├── _xiaoma-output/
+│   ├── planning-artifacts/
+│   │   └── PRD.md                           # Your requirements document
+│   ├── implementation-artifacts/
+│   └── project-context.md                   # Implementation rules (optional)
+└── ...
+```
+````
+
+## Tutorial Structure
+
+```text
+1. Title + Hook (1-2 sentences describing outcome)
+2. Version/Module Notice (info or warning admonition) (optional)
+3. What You'll Learn (bullet list of outcomes)
+4. Prerequisites (info admonition)
+5. Quick Path (tip admonition - TL;DR summary)
+6. Understanding [Topic] (context before steps - tables for phases/agents)
+7. Installation (optional)
+8. Step 1: [First Major Task]
+9. Step 2: [Second Major Task]
+10. Step 3: [Third Major Task]
+11. What You've Accomplished (summary + folder structure)
+12. Quick Reference (commands table)
+13. Common Questions (FAQ format)
+14. Getting Help (community links)
+15. Key Takeaways (tip admonition)
+```
+
+### Tutorial Checklist
+
+- [ ] Hook describes outcome in 1-2 sentences
+- [ ] "What You'll Learn" section present
+- [ ] Prerequisites in admonition
+- [ ] Quick Path TL;DR admonition at top
+- [ ] Tables for phases, commands, agents
+- [ ] "What You've Accomplished" section present
+- [ ] Quick Reference table present
+- [ ] Common Questions section present
+- [ ] Getting Help section present
+- [ ] Key Takeaways admonition at end
+
+## How-To Structure
+
+```text
+1. Title + Hook (one sentence: "Use the `X` workflow to...")
+2. When to Use This (bullet list of scenarios)
+3. When to Skip This (optional)
+4. Prerequisites (note admonition)
+5. Steps (numbered ### subsections)
+6. What You Get (output/artifacts produced)
+7. Example (optional)
+8. Tips (optional)
+9. Next Steps (optional)
+```
+
+### How-To Checklist
+
+- [ ] Hook starts with "Use the `X` workflow to..."
+- [ ] "When to Use This" has 3-5 bullet points
+- [ ] Prerequisites listed
+- [ ] Steps are numbered `###` subsections with action verbs
+- [ ] "What You Get" describes output artifacts
+
+## Explanation Structure
+
+### Types
+
+| Type              | Example                       |
+| ----------------- | ----------------------------- |
+| **Index/Landing** | `core-concepts/index.md`      |
+| **Concept**       | `what-are-agents.md`          |
+| **Feature**       | `quick-flow.md`               |
+| **Philosophy**    | `why-solutioning-matters.md`  |
+| **FAQ**           | `established-projects-faq.md` |
+
+### General Template
+
+```text
+1. Title + Hook (1-2 sentences)
+2. Overview/Definition (what it is, why it matters)
+3. Key Concepts (### subsections)
+4. Comparison Table (optional)
+5. When to Use / When Not to Use (optional)
+6. Diagram (optional - mermaid, 1 per doc max)
+7. Next Steps (optional)
+```
+
+### Index/Landing Pages
+
+```text
+1. Title + Hook (one sentence)
+2. Content Table (links with descriptions)
+3. Getting Started (numbered list)
+4. Choose Your Path (optional - decision tree)
+```
+
+### Concept Explainers
+
+```text
+1. Title + Hook (what it is)
+2. Types/Categories (### subsections) (optional)
+3. Key Differences Table
+4. Components/Parts
+5. Which Should You Use?
+6. Creating/Customizing (pointer to how-to guides)
+```
+
+### Feature Explainers
+
+```text
+1. Title + Hook (what it does)
+2. Quick Facts (optional - "Perfect for:", "Time to:")
+3. When to Use / When Not to Use
+4. How It Works (mermaid diagram optional)
+5. Key Benefits
+6. Comparison Table (optional)
+7. When to Graduate/Upgrade (optional)
+```
+
+### Philosophy/Rationale Documents
+
+```text
+1. Title + Hook (the principle)
+2. The Problem
+3. The Solution
+4. Key Principles (### subsections)
+5. Benefits
+6. When This Applies
+```
+
+### Explanation Checklist
+
+- [ ] Hook states what document explains
+- [ ] Content in scannable `##` sections
+- [ ] Comparison tables for 3+ options
+- [ ] Diagrams have clear labels
+- [ ] Links to how-to guides for procedural questions
+- [ ] 2-3 admonitions max per document
+
+## Reference Structure
+
+### Types
+
+| Type              | Example               |
+| ----------------- | --------------------- |
+| **Index/Landing** | `workflows/index.md`  |
+| **Catalog**       | `agents/index.md`     |
+| **Deep-Dive**     | `document-project.md` |
+| **Configuration** | `core-tasks.md`       |
+| **Glossary**      | `glossary/index.md`   |
+| **Comprehensive** | `bmgd-workflows.md`   |
+
+### Reference Index Pages
+
+```text
+1. Title + Hook (one sentence)
+2. Content Sections (## for each category)
+   - Bullet list with links and descriptions
+```
+
+### Catalog Reference
+
+```text
+1. Title + Hook
+2. Items (## for each item)
+   - Brief description (one sentence)
+   - **Commands:** or **Key Info:** as flat list
+3. Universal/Shared (## section) (optional)
+```
+
+### Item Deep-Dive Reference
+
+```text
+1. Title + Hook (one sentence purpose)
+2. Quick Facts (optional note admonition)
+   - Module, Command, Input, Output as list
+3. Purpose/Overview (## section)
+4. How to Invoke (code block)
+5. Key Sections (## for each aspect)
+   - Use ### for sub-options
+6. Notes/Caveats (tip or caution admonition)
+```
+
+### Configuration Reference
+
+```text
+1. Title + Hook
+2. Table of Contents (jump links if 4+ items)
+3. Items (## for each config/task)
+   - **Bold summary** — one sentence
+   - **Use it when:** bullet list
+   - **How it works:** numbered steps (3-5 max)
+   - **Output:** expected result (optional)
+```
+
+### Comprehensive Reference Guide
+
+```text
+1. Title + Hook
+2. Overview (## section)
+   - Diagram or table showing organization
+3. Major Sections (## for each phase/category)
+   - Items (### for each item)
+   - Standardized fields: Command, Agent, Input, Output, Description
+4. Next Steps (optional)
+```
+
+### Reference Checklist
+
+- [ ] Hook states what document references
+- [ ] Structure matches reference type
+- [ ] Items use consistent structure throughout
+- [ ] Tables for structured/comparative data
+- [ ] Links to explanation docs for conceptual depth
+- [ ] 1-2 admonitions max
+
+## Glossary Structure
+
+Starlight generates right-side "On this page" navigation from headers:
+
+- Categories as `##` headers — appear in right nav
+- Terms in tables — compact rows, not individual headers
+- No inline TOC — right sidebar handles navigation
+
+### Table Format
+
+```md
+## Category Name
+
+| Term         | Definition                                                                               |
+| ------------ | ---------------------------------------------------------------------------------------- |
+| **Agent**    | Specialized AI persona with specific expertise that guides users through workflows.      |
+| **Workflow** | Multi-step guided process that orchestrates AI agent activities to produce deliverables. |
+```
+
+### Definition Rules
+
+| Do                            | Don't                                       |
+| ----------------------------- | ------------------------------------------- |
+| Start with what it IS or DOES | Start with "This is..." or "A [term] is..." |
+| Keep to 1-2 sentences         | Write multi-paragraph explanations          |
+| Bold term name in cell        | Use plain text for terms                    |
+
+### Context Markers
+
+Add italic context at definition start for limited-scope terms:
+
+- `*Quick Flow only.*`
+- `*XiaoMa Method/Enterprise.*`
+- `*Phase N.*`
+- `*BMGD.*`
+- `*Established projects.*`
+
+### Glossary Checklist
+
+- [ ] Terms in tables, not individual headers
+- [ ] Terms alphabetized within categories
+- [ ] Definitions 1-2 sentences
+- [ ] Context markers italicized
+- [ ] Term names bolded in cells
+- [ ] No "A [term] is..." definitions
+
+## FAQ Sections
+
+```md
+## Questions
+
+- [Do I always need architecture?](#do-i-always-need-architecture)
+- [Can I change my plan later?](#can-i-change-my-plan-later)
+
+### Do I always need architecture?
+
+Only for XiaoMa Method and Enterprise tracks. Quick Flow skips to implementation.
+
+### Can I change my plan later?
+
+Yes. The SM agent has a `correct-course` workflow for handling scope changes.
+
+**Have a question not answered here?** [Open an issue](...) or ask in [Discord](...).
+```
+
+## Validation Commands
+
+Before submitting documentation changes:
+
+```bash
+npm run docs:fix-links            # Preview link format fixes
+npm run docs:fix-links -- --write # Apply fixes
+npm run docs:validate-links       # Check links exist
+npm run docs:build                # Verify no build errors
+```

package/docs/zh-cn/explanation/advanced-elicitation.md

@@ -0,0 +1,62 @@
+---
+title: "高级启发"
+description: 使用结构化推理方法推动 LLM 重新思考其工作
+sidebar:
+  order: 6
+---
+
+让 LLM 重新审视它刚刚生成的内容。你选择一种推理方法，它将该方法应用于自己的输出，然后你决定是否保留改进。
+
+## 什么是高级启发？
+
+结构化的第二轮处理。与其要求 AI "再试一次" 或 "做得更好"，不如选择一种特定的推理方法，让 AI 通过该视角重新审视自己的输出。
+
+这种区别很重要。模糊的请求会产生模糊的修订。命名的方法会强制采用特定的攻击角度，揭示出通用重试会遗漏的见解。
+
+## 何时使用
+
+- 在工作流生成内容后，你想要替代方案
+- 当输出看起来还可以，但你怀疑还有更深层次的内容
+- 对假设进行压力测试或发现弱点
+- 对于重新思考有帮助的高风险内容
+
+工作流在决策点提供高级启发——在 LLM 生成某些内容后，系统会询问你是否要运行它。
+
+## 工作原理
+
+1. LLM 为你的内容建议 5 种相关方法
+2. 你选择一种（或重新洗牌以获取不同选项）
+3. 应用方法，显示改进
+4. 接受或丢弃，重复或继续
+
+## 内置方法
+
+有数十种推理方法可用。几个示例：
+
+- **事前复盘** - 假设项目已经失败，反向推导找出原因
+- **第一性原理思维** - 剥离假设，从基本事实重建
+- **逆向思维** - 询问如何保证失败，然后避免这些事情
+- **红队对蓝队** - 攻击你自己的工作，然后为它辩护
+- **苏格拉底式提问** - 用"为什么？"和"你怎么知道？"挑战每个主张
+- **约束移除** - 放下所有约束，看看有什么变化，然后有选择地加回
+- **利益相关者映射** - 从每个利益相关者的角度重新评估
+- **类比推理** - 在其他领域找到平行案例并应用其教训
+
+还有更多。AI 会为你的内容选择最相关的选项——你选择运行哪一个。
+
+:::tip[从这里开始]
+对于任何规范或计划，事前复盘都是一个很好的首选。它始终能找到标准审查会遗漏的空白。
+:::
+
+---
+## 术语说明
+
+- **LLM**：大语言模型。一种基于深度学习的自然语言处理模型，能够理解和生成人类语言。
+- **elicitation**：启发。在人工智能与提示工程中，指通过特定方法引导模型生成更高质量或更符合预期的输出。
+- **pre-mortem analysis**：事前复盘。一种风险管理技术，假设项目已经失败，然后反向推导可能的原因，以提前识别和预防潜在问题。
+- **first principles thinking**：第一性原理思维。一种将复杂问题分解为最基本事实或假设，然后从这些基本要素重新构建解决方案的思维方式。
+- **inversion**：逆向思维。通过思考如何导致失败来避免失败，从而找到成功路径的思维方式。
+- **red team vs blue team**：红队对蓝队。一种模拟对抗的方法，红队负责攻击和发现问题，蓝队负责防御和解决问题。
+- **socratic questioning**：苏格拉底式提问。一种通过连续提问来揭示假设、澄清概念和深入思考的对话方法。
+- **stakeholder mapping**：利益相关者映射。识别并分析项目中所有利益相关者及其利益、影响和关系的系统性方法。
+- **analogical reasoning**：类比推理。通过将当前问题与已知相似领域的问题进行比较，从而借鉴解决方案或见解的推理方式。

package/docs/zh-cn/explanation/adversarial-review.md

@@ -0,0 +1,71 @@
+---
+title: "对抗性评审"
+description: 防止懒惰"看起来不错"评审的强制推理技术
+sidebar:
+  order: 5
+---
+
+通过要求发现问题来强制进行更深入的分析。
+
+## 什么是对抗性评审？
+
+一种评审技术，评审者*必须*发现问题。不允许"看起来不错"。评审者采取怀疑态度——假设问题存在并找到它们。
+
+这不是为了消极。而是为了强制进行真正的分析，而不是对提交的内容进行草率浏览并盖章批准。
+
+**核心规则：**你必须发现问题。零发现会触发停止——重新分析或解释原因。
+
+## 为什么有效
+
+普通评审容易受到确认偏差的影响。你浏览工作，没有发现突出的问题，就批准了它。"发现问题"的指令打破了这种模式：
+
+- **强制彻底性**——在你足够努力地查看以发现问题之前，不能批准
+- **捕捉遗漏**——"这里缺少什么？"成为一个自然的问题
+- **提高信号质量**——发现是具体且可操作的，而不是模糊的担忧
+- **信息不对称**——在新的上下文中运行评审（无法访问原始推理），以便你评估的是工件，而不是意图
+
+## 在哪里使用
+
+对抗性评审出现在 XiaoMa 工作流程的各个地方——代码评审、实施就绪检查、规范验证等。有时它是必需步骤，有时是可选的（如高级启发或派对模式）。该模式适应任何需要审查的工件。
+
+## 需要人工过滤
+
+因为 AI 被*指示*要发现问题，它就会发现问题——即使问题不存在。预期会有误报：伪装成问题的吹毛求疵、对意图的误解，或完全幻觉化的担忧。
+
+**你决定什么是真实的。**审查每个发现，忽略噪音，修复重要的内容。
+
+## 示例
+
+而不是：
+
+> "身份验证实现看起来合理。已批准。"
+
+对抗性评审产生：
+
+> 1. **高** - `login.ts:47` - 失败尝试没有速率限制
+> 2. **高** - 会话令牌存储在 localStorage 中（易受 XSS 攻击）
+> 3. **中** - 密码验证仅在客户端进行
+> 4. **中** - 失败登录尝试没有审计日志
+> 5. **低** - 魔法数字 `3600` 应该是 `SESSION_TIMEOUT_SECONDS`
+
+第一个评审可能会遗漏安全漏洞。第二个发现了四个。
+
+## 迭代和收益递减
+
+在处理发现后，考虑再次运行。第二轮通常会捕获更多。第三轮也不总是无用的。但每一轮都需要时间，最终你会遇到收益递减——只是吹毛求疵和虚假发现。
+
+:::tip[更好的评审]
+假设问题存在。寻找缺失的内容，而不仅仅是错误的内容。
+:::
+
+---
+## 术语说明
+
+- **adversarial review**：对抗性评审。一种强制评审者必须发现问题的评审技术，旨在防止草率批准。
+- **confirmation bias**：确认偏差。倾向于寻找、解释和记忆符合自己已有信念的信息的心理倾向。
+- **information asymmetry**：信息不对称。交易或评审中一方拥有比另一方更多或更好信息的情况。
+- **false positives**：误报。错误地将不存在的问题识别为存在的问题。
+- **diminishing returns**：收益递减。在投入持续增加的情况下，产出增长逐渐减少的现象。
+- **XSS**：跨站脚本攻击（Cross-Site Scripting）。一种安全漏洞，攻击者可在网页中注入恶意脚本。
+- **localStorage**：本地存储。浏览器提供的 Web Storage API，用于在客户端存储键值对数据。
+- **magic number**：魔法数字。代码中直接出现的未命名数值常量，缺乏语义含义。

package/docs/zh-cn/explanation/brainstorming.md

@@ -0,0 +1,43 @@
+---
+title: "头脑风暴"
+description: 使用 60+ 种经过验证的构思技术进行互动创意会议
+sidebar:
+  order: 2
+---
+
+通过引导式探索释放你的创造力。
+
+## 什么是头脑风暴？
+
+运行 `brainstorming`，你就拥有了一位创意引导者，帮助你从自身挖掘想法——而不是替你生成想法。AI 充当教练和向导，使用经过验证的技术，创造让你最佳思维涌现的条件。
+
+**适用于：**
+
+- 突破创意瓶颈
+- 生成产品或功能想法
+- 从新角度探索问题
+- 将原始概念发展为行动计划
+
+## 工作原理
+
+1. **设置** - 定义主题、目标、约束
+2. **选择方法** - 自己选择技术、获取 AI 推荐、随机选择或遵循渐进式流程
+3. **引导** - 通过探索性问题和协作式教练引导完成技术
+4. **组织** - 将想法按主题分组并确定优先级
+5. **行动** - 为顶级想法制定下一步和成功指标
+
+所有内容都会被记录在会议文档中，你可以稍后参考或与利益相关者分享。
+
+:::note[你的想法]
+每个想法都来自你。工作流程创造洞察的条件——你是源头。
+:::
+
+---
+## 术语说明
+
+- **brainstorming**：头脑风暴。一种集体或个人的创意生成方法，通过自由联想和发散思维产生大量想法。
+- **ideation**：构思。产生想法、概念或解决方案的过程。
+- **facilitator**：引导者。在会议或工作坊中引导讨论、促进参与并帮助达成目标的人。
+- **creative blocks**：创意瓶颈。在创意过程中遇到的思维停滞或灵感枯竭状态。
+- **probing questions**：探索性问题。旨在深入挖掘信息、激发思考或揭示潜在见解的问题。
+- **stakeholders**：利益相关者。对项目或决策有利益关系或受其影响的个人或群体。

package/docs/zh-cn/explanation/established-projects-faq.md

@@ -0,0 +1,60 @@
+---
+title: "既有项目常见问题"
+description: 关于在既有项目上使用 XiaoMa 方法的常见问题
+sidebar:
+  order: 8
+---
+关于使用 XiaoMa 方法（BMM）在既有项目上工作的常见问题的快速解答。
+
+## 问题
+
+- [我必须先运行 document-project 吗？](#do-i-have-to-run-document-project-first)
+- [如果我忘记运行 document-project 怎么办？](#what-if-i-forget-to-run-document-project)
+- [我可以在既有项目上使用快速流程吗？](#can-i-use-quick-flow-for-established-projects)
+- [如果我的现有代码不遵循最佳实践怎么办？](#what-if-my-existing-code-doesnt-follow-best-practices)
+
+### 我必须先运行 document-project 吗？
+
+强烈推荐，特别是如果：
+
+- 没有现有文档
+- 文档已过时
+- AI 智能体需要关于现有代码的上下文
+
+如果你拥有全面且最新的文档，包括 `docs/index.md`，或者将使用其他工具或技术来帮助智能体发现现有系统，则可以跳过此步骤。
+
+### 如果我忘记运行 document-project 怎么办？
+
+不用担心——你可以随时执行。你甚至可以在项目期间或项目之后执行，以帮助保持文档最新。
+
+### 我可以在既有项目上使用快速流程吗？
+
+可以！快速流程在既有项目上效果很好。它将：
+
+- 自动检测你的现有技术栈
+- 分析现有代码模式
+- 检测约定并请求确认
+- 生成尊重现有代码的上下文丰富的技术规范
+
+非常适合现有代码库中的错误修复和小功能。
+
+### 如果我的现有代码不遵循最佳实践怎么办？
+
+快速流程会检测你的约定并询问："我应该遵循这些现有约定吗？"你决定：
+
+- **是** → 与当前代码库保持一致
+- **否** → 建立新标准（在技术规范中记录原因）
+
+BMM 尊重你的选择——它不会强制现代化，但会提供现代化选项。
+
+**有未在此处回答的问题吗？** 请[提出问题](https://github.com/xiaoma-code-org/XiaoMa-Cli/issues)或在 [Discord](https://discord.gg/gk8jAdXWmj) 中提问，以便我们添加它！
+
+---
+## 术语说明
+
+- **agent**：智能体。在人工智能与编程文档中，指具备自主决策或执行能力的单元。
+- **Quick Flow**：快速流程。XiaoMa 方法中的一种工作流程，用于快速处理既有项目。
+- **tech-spec**：技术规范。描述技术实现细节和标准的文档。
+- **stack**：技术栈。项目所使用的技术组合，包括框架、库、工具等。
+- **conventions**：约定。代码库中遵循的编码风格、命名规则等规范。
+- **modernization**：现代化。将旧代码或系统更新为更现代的技术和最佳实践的过程。

package/docs/zh-cn/explanation/party-mode.md

@@ -0,0 +1,79 @@
+---
+title: "派对模式"
+description: 多智能体协作——将所有 AI 智能体汇聚到一次对话中
+sidebar:
+  order: 7
+---
+
+将所有 AI 智能体汇聚到一次对话中。
+
+## 什么是 Party Mode？
+
+运行 `party-mode`，你的整个 AI 团队就齐聚一堂——PM、架构师、开发者、UX 设计师，任何你需要的人。XiaoMa Master 负责编排，根据每条消息选择相关的智能体。智能体以角色身份回应，彼此同意、反对，并在彼此的想法基础上继续构建。
+
+对话可以持续到你想要的时间。提出追问、对答案提出质疑、引导讨论方向——这是与智能体之间真正的来回交流，直到你完成目标。
+
+**适用于：**
+
+- 需要权衡的重大决策
+- 头脑风暴会议
+- 出现问题时的复盘
+- 冲刺回顾与规划
+
+## 示例
+
+### 指出糟糕的架构
+
+**You:** "好了团队，我们上个冲刺是一场灾难。认证服务宕机了三次。谁搞砸了这件事？"
+
+**Architect:** "设计本身是合理的——分布式认证，有适当的回退机制。如果实现偏离了规范……"
+
+**Dev:** "我完全按照架构文档执行的。规范没有考虑到并发会话失效的竞态条件。"
+
+**PM:** "你们两个都忽略了更大的问题——我们没有在 PRD 中验证会话管理需求。这是我的错，没有发现这一点。"
+
+**TEA:** "我也应该在集成测试中发现这一点。测试场景没有覆盖并发失效。"
+
+### 创意头脑风暴
+
+**You:** "我们如何让入职体验变得神奇，而不是无聊？"
+
+**UX Designer:** "从渐进式披露开始——在用户需要时揭示功能，而不是在教程中一次性展示所有内容。"
+
+**Storyteller:** "如果入职是一个故事会怎样？每一步都揭示一个角色的旅程——用户就是英雄。"
+
+**Game Designer:** "在此基础上——如果第一个'任务'实际上是解决一个真实的用户问题会怎样？他们通过做有价值的事情来学习。"
+
+### 技术决策
+
+**You:** "MVP 用单体还是微服务？"
+
+**Architect:** "从单体开始。微服务会增加你在 1000 用户时不需要的复杂性。"
+
+**PM:** "同意。上市时间比理论上的可扩展性更重要。"
+
+**Dev:** "单体，但要有清晰的模块边界。如果需要，我们以后可以提取服务。"
+
+:::tip[Better Decisions]
+通过多元视角做出更好的决策。欢迎来到 party mode。
+:::
+
+---
+## 术语说明
+
+- **agent**：智能体。在人工智能与编程文档中，指具备自主决策或执行能力的单元。
+- **PM**：产品经理（Product Manager）。
+- **Architect**：架构师。
+- **Dev**：开发者（Developer）。
+- **UX Designer**：用户体验设计师。
+- **TEA**：测试工程师（Test Engineer/Automation）。
+- **PRD**：产品需求文档（Product Requirements Document）。
+- **MVP**：最小可行产品（Minimum Viable Product）。
+- **monolith**：单体架构。一种将应用程序构建为单一、统一单元的架构风格。
+- **microservices**：微服务。一种将应用程序构建为一组小型、独立服务的架构风格。
+- **progressive disclosure**：渐进式披露。一种交互设计模式，仅在用户需要时显示信息或功能。
+- **post-mortem**：复盘。对事件或项目进行事后分析，以了解发生了什么以及如何改进。
+- **sprint**：冲刺。敏捷开发中的固定时间周期，通常为 1-4 周。
+- **race condition**：竞态条件。当多个进程或线程同时访问和操作共享数据时，系统行为取决于执行顺序的一种情况。
+- **fallback**：回退机制。当主要方法失败时使用的备用方案。
+- **time to market**：上市时间。产品从概念到推向市场所需的时间。