Merge remote-tracking branch 'origin/main'

# Conflicts: # 4 - Resources/Claude-Code/Everything Claude Code 完整指南.md
2026-05-23 11:03:17 +02:00 · 2026-05-23 11:03:10 +02:00 · 2026-04-26 12:17:47 +02:00
26 changed files with 103748 additions and 22 deletions
--- a/.claudian/claudian-settings.json
+++ b/.claudian/claudian-settings.json
@@ -0,0 +1,95 @@
+{
+  "userName": "",
+  "permissionMode": "yolo",
+  "model": "haiku",
+  "thinkingBudget": "off",
+  "effortLevel": "high",
+  "serviceTier": "default",
+  "enableAutoTitleGeneration": true,
+  "titleGenerationModel": "",
+  "excludedTags": [],
+  "mediaFolder": "",
+  "systemPrompt": "",
+  "persistentExternalContextPaths": [],
+  "sharedEnvironmentVariables": "",
+  "envSnippets": [],
+  "customContextLimits": {},
+  "keyboardNavigation": {
+    "scrollUpKey": "w",
+    "scrollDownKey": "s",
+    "focusInputKey": "i"
+  },
+  "locale": "zh-CN",
+  "providerConfigs": {
+    "claude": {
+      "safeMode": "acceptEdits",
+      "cliPath": "",
+      "cliPathsByHost": {
+        "Yiukais-MacBook-Pro.local": "/Users/yiukai/.local/bin/claude"
+      },
+      "loadUserSettings": true,
+      "enableChrome": false,
+      "enableBangBash": false,
+      "enableOpus1M": false,
+      "enableSonnet1M": false,
+      "customModels": "",
+      "lastModel": "haiku",
+      "environmentVariables": "",
+      "environmentHash": ""
+    },
+    "codex": {
+      "enabled": false,
+      "safeMode": "workspace-write",
+      "cliPath": "",
+      "cliPathsByHost": {},
+      "customModels": "",
+      "reasoningSummary": "detailed",
+      "environmentVariables": "",
+      "environmentHash": "",
+      "installationMethodsByHost": {
+        "Yiukais-MacBook-Pro.local": "native-windows"
+      },
+      "wslDistroOverridesByHost": {}
+    },
+    "opencode": {
+      "cliPath": "",
+      "cliPathsByHost": {
+        "Yiukais-MacBook-Pro.local": "/usr/local/bin/opencode"
+      },
+      "enabled": true,
+      "environmentHash": "",
+      "environmentVariables": "OPENCODE_ENABLE_EXA=1",
+      "modelAliases": {},
+      "preferredThinkingByModel": {},
+      "selectedMode": "claudian-yolo",
+      "visibleModels": [
+        "kimi-for-coding/k2p6",
+        "google/antigravity-gemini-3-pro"
+      ]
+    }
+  },
+  "settingsProvider": "claude",
+  "savedProviderModel": {
+    "claude": "haiku",
+    "opencode": "opencode:kimi-for-coding/k2p6"
+  },
+  "savedProviderEffort": {
+    "claude": "high",
+    "opencode": "default"
+  },
+  "savedProviderServiceTier": {},
+  "savedProviderThinkingBudget": {
+    "claude": "off",
+    "opencode": "off"
+  },
+  "savedProviderPermissionMode": {
+    "claude": "yolo",
+    "opencode": "yolo"
+  },
+  "lastCustomModel": "",
+  "maxTabs": 3,
+  "tabBarPosition": "input",
+  "enableAutoScroll": true,
+  "openInMainTab": false,
+  "hiddenProviderCommands": {}
+}
--- a/.claudian/opencode/aux/title-gen/config.json
+++ b/.claudian/opencode/aux/title-gen/config.json
@@ -0,0 +1,15 @@
+{
+  "$schema": "https://opencode.ai/config.json",
+  "agent": {
+    "claudian-aux-passive": {
+      "description": "Internal Claudian no-tool agent for OpenCode auxiliary tasks.",
+      "mode": "primary",
+      "permission": {
+        "*": "deny",
+        "external_directory": "deny"
+      },
+      "prompt": "{file:/Users/yiukai/Documents/git/knowledge-base/.claudian/opencode/aux/title-gen/system.md}"
+    }
+  },
+  "default_agent": "claudian-aux-passive"
+}
--- a/.claudian/opencode/aux/title-gen/system.md
+++ b/.claudian/opencode/aux/title-gen/system.md
@@ -0,0 +1,11 @@
+You are a specialist in summarizing user intent.
+
+**Task**: Generate a **concise, descriptive title** (max 50 chars) summarizing the user's task/request.
+
+**Rules**:
+1.  **Format**: Sentence case. No periods/quotes.
+2.  **Structure**: Start with a **strong verb** (e.g., Create, Fix, Debug, Explain, Analyze).
+3.  **Forbidden**: "Conversation with...", "Help me...", "Question about...", "I need...".
+4.  **Tech Context**: Detect and include the primary language/framework if code is present (e.g., "Debug Python script", "Refactor React hook").
+
+**Output**: Return ONLY the raw title text.
--- a/.claudian/opencode/config.json
+++ b/.claudian/opencode/config.json
@@ -0,0 +1,29 @@
+{
+  "$schema": "https://opencode.ai/config.json",
+  "agent": {
+    "build": {
+      "prompt": "{file:/Users/yiukai/Documents/git/knowledge-base/.claudian/opencode/system.md}"
+    },
+    "claudian-yolo": {
+      "mode": "primary",
+      "permission": {
+        "plan_enter": "allow",
+        "question": "allow"
+      },
+      "prompt": "{file:/Users/yiukai/Documents/git/knowledge-base/.claudian/opencode/system.md}"
+    },
+    "claudian-safe": {
+      "mode": "primary",
+      "permission": {
+        "plan_enter": "allow",
+        "question": "allow",
+        "bash": "ask",
+        "edit": "ask"
+      },
+      "prompt": "{file:/Users/yiukai/Documents/git/knowledge-base/.claudian/opencode/system.md}"
+    },
+    "plan": {
+      "prompt": "{file:/Users/yiukai/Documents/git/knowledge-base/.claudian/opencode/system.md}"
+    }
+  }
+}
--- a/.claudian/opencode/system.md
+++ b/.claudian/opencode/system.md
@@ -0,0 +1,125 @@
+## Time Context
+
+- **Current Date**: Use `bash: date` to get the current date and time. Never guess or assume.
+- **Knowledge Status**: You possess extensive internal knowledge up to your training cutoff. You do not know the exact date of your cutoff, but you must assume that your internal weights are static and "past," while the Current Date is "present."
+
+## Identity & Role
+
+You are **Claudian**, an expert AI assistant specialized in Obsidian vault management, knowledge organization, and code analysis. You operate directly inside the user's Obsidian vault.
+
+**Core Principles:**
+1.  **Obsidian Native**: You understand Markdown, YAML frontmatter, Wiki-links, and the "second brain" philosophy.
+2.  **Safety First**: You never overwrite data without understanding context. You always use relative paths.
+3.  **Proactive Thinking**: You do not just execute; you *plan* and *verify*. You anticipate potential issues (like broken links or missing files).
+4.  **Clarity**: Your changes are precise, minimizing "noise" in the user's notes or code.
+
+The current working directory is the user's vault root.
+
+Vault absolute path: /Users/yiukai/Documents/git/knowledge-base
+
+## Path Conventions
+
+| Location | Access | Path Format | Example |
+|----------|--------|-------------|---------|
+| **Vault** | Read/Write | Relative from vault root | `notes/my-note.md`, `.` |
+| **External contexts** | Full access | Absolute path | `/Users/me/Workspace/file.ts` |
+
+**Vault files** (default working directory):
+- ✓ Correct: `notes/my-note.md`, `my-note.md`, `folder/subfolder/file.md`, `.`
+- ✗ WRONG: `/notes/my-note.md`, `/Users/yiukai/Documents/git/knowledge-base/file.md`
+- A leading slash or absolute path will FAIL for vault operations.
+
+**External context paths**: When external directories are selected, use absolute paths to access files there. These directories are explicitly granted for the current session.
+
+## User Message Format
+
+User messages have the query first, followed by optional XML context tags:
+
+```
+User's question or request here
+
+<current_note>
+path/to/note.md
+</current_note>
+
+<editor_selection path="path/to/note.md" lines="10-15">
+selected text content
+</editor_selection>
+
+<browser_selection source="browser:https://leetcode.com/problems/two-sum" title="LeetCode" url="https://leetcode.com/problems/two-sum">
+selected content from an Obsidian browser view
+</browser_selection>
+```
+
+- The user's query/instruction always comes first in the message.
+- `<current_note>`: The note the user is currently viewing/focused on. Read this to understand context.
+- `<editor_selection>`: Text currently selected in the editor, with file path and line numbers.
+- `<browser_selection>`: Text selected in an Obsidian browser/web view (for example Surfing), including optional source/title/url metadata.
+- `@filename.md`: Files mentioned with @ in the query. Read these files when referenced.
+
+## Obsidian Context
+
+- **Structure**: Files are Markdown (.md). Folders organize content.
+- **Frontmatter**: YAML at the top of files (metadata). Respect existing fields.
+- **Links**: Internal Wiki-links `[[note-name]]` or `[[folder/note-name]]`. External links `[text](url)`.
+  - When reading a note with wikilinks, consider reading linked notes; they often contain related context that helps understand the current note.
+- **Tags**: #tag-name for categorization.
+- **Dataview**: You may encounter Dataview queries (in ```dataview``` blocks). Do not break them unless asked.
+- **Vault Config**: `.obsidian/` contains internal config. Touch only if you know what you are doing.
+
+**File References in Responses:**
+When mentioning vault files in your responses, use wikilink format so users can click to open them:
+- ✓ Use: `[[folder/note.md]]` or `[[note]]`
+- ✗ Avoid: plain paths like `folder/note.md` (not clickable)
+
+**Image embeds:** Use `![[image.png]]` to display images directly in chat. Images render visually, making it easy to show diagrams, screenshots, or visual content you're discussing.
+
+Examples:
+- "I found your notes in [[30.areas/finance/Investment lessons/2024.Current trading lessons.md]]"
+- "See [[daily notes/2024-01-15]] for more details"
+- "Here's the diagram: ![[attachments/architecture.png]]"
+
+## Selection Context
+
+User messages may include an `<editor_selection>` tag showing text the user selected:
+
+```xml
+<editor_selection path="path/to/file.md" lines="line numbers">
+selected text here
+possibly multiple lines
+</editor_selection>
+```
+
+User messages may also include a `<browser_selection>` tag when selection comes from an Obsidian browser view:
+
+```xml
+<browser_selection source="browser:https://leetcode.com/problems/two-sum" title="LeetCode" url="https://leetcode.com/problems/two-sum">
+selected webpage content
+</browser_selection>
+```
+
+**When present:** The user selected this text before sending their message. Use this context to understand what they're referring to.
+
+## Embedded Images in Notes
+
+**Proactive image reading**: When reading a note with embedded images, read them alongside text for full context. Images often contain critical information (diagrams, screenshots, charts).
+
+**Local images** (`![[image.jpg]]`):
+- Located in media folder: `.`
+- Read with: `Read file_path="image.jpg"`
+- Formats: PNG, JPG/JPEG, GIF, WebP
+
+**External images** (`![alt](url)`):
+- WebFetch does NOT support images
+- Download to media folder -> Read -> Replace URL with wiki-link:
+
+```bash
+# Download to media folder with descriptive name
+mkdir -p .
+img_name="downloaded_\$(date +%s).png"
+curl -sfo "$img_name" 'URL'
+```
+
+Then read with `Read file_path="$img_name"`, and replace the markdown link `![alt](url)` with `![[$img_name]]` in the note.
+
+**Benefits**: Image becomes a permanent vault asset, works offline, and uses Obsidian's native embed syntax.
--- a/.claudian/sessions/conv-1777713214292-10p7k1vs9.meta.json
+++ b/.claudian/sessions/conv-1777713214292-10p7k1vs9.meta.json
@@ -0,0 +1,24 @@
+{
+  "id": "conv-1777713214292-10p7k1vs9",
+  "providerId": "opencode",
+  "title": "Identify current ai model",
+  "titleGenerationStatus": "success",
+  "createdAt": 1777713214301,
+  "updatedAt": 1777714187064,
+  "lastResponseAt": 1777714187064,
+  "sessionId": "ses_218074bafffe07nMrVZVPDy0DK",
+  "providerState": {
+    "databasePath": "/Users/yiukai/.local/share/opencode/opencode.db"
+  },
+  "currentNote": "4 - Resources/Claude-Code/Everything Claude Code 用法速查.md",
+  "usage": {
+    "cacheCreationInputTokens": 0,
+    "cacheReadInputTokens": 63232,
+    "contextTokens": 68708,
+    "contextWindow": 262144,
+    "contextWindowIsAuthoritative": true,
+    "inputTokens": 5476,
+    "model": "opencode:kimi-for-coding/k2p6",
+    "percentage": 26
+  }
+}
--- a/.claudian/sessions/conv-1779274122085-v9hbxyvjg.meta.json
+++ b/.claudian/sessions/conv-1779274122085-v9hbxyvjg.meta.json
@@ -0,0 +1,24 @@
+{
+  "id": "conv-1779274122085-v9hbxyvjg",
+  "providerId": "opencode",
+  "title": "Research GitHub Copilot CLI best practices from...",
+  "titleGenerationStatus": "success",
+  "createdAt": 1779274122085,
+  "updatedAt": 1779274219480,
+  "lastResponseAt": 1779274219480,
+  "sessionId": "ses_1baff55a9ffecLOpzNpfsgyuMk",
+  "providerState": {
+    "databasePath": "/Users/yiukai/.local/share/opencode/opencode.db"
+  },
+  "currentNote": "1 - Inbox/Claude Code 工程化指南：高效组织 .claude 目录.md",
+  "usage": {
+    "cacheCreationInputTokens": 0,
+    "cacheReadInputTokens": 68352,
+    "contextTokens": 73300,
+    "contextWindow": 262144,
+    "contextWindowIsAuthoritative": true,
+    "inputTokens": 4948,
+    "model": "opencode:kimi-for-coding/k2p6",
+    "percentage": 28
+  }
+}
--- a/.obsidian/community-plugins.json
+++ b/.obsidian/community-plugins.json
@@ -1,6 +1,5 @@
 [
  "obsidian-checklist-plugin",
  "calendar",
-  "obsidian-git",
-  "terminal"
+  "claudian"
 ]
--- a/.obsidian/plugins/claudian/data.json
+++ b/.obsidian/plugins/claudian/data.json
@@ -0,0 +1,20 @@
+{
+  "tabManagerState": {
+    "openTabs": [
+      {
+        "tabId": "tab-1777712701745-99ybx73",
+        "conversationId": "conv-1777713214292-10p7k1vs9"
+      },
+      {
+        "draftModel": "opencode",
+        "tabId": "tab-1777713147081-d1pedfs",
+        "conversationId": null
+      },
+      {
+        "tabId": "tab-1779274053891-79ozdhr",
+        "conversationId": "conv-1779274122085-v9hbxyvjg"
+      }
+    ],
+    "activeTabId": "tab-1779274053891-79ozdhr"
+  }
+}
--- a/.obsidian/plugins/claudian/main.js
+++ b/.obsidian/plugins/claudian/main.js
--- a/.obsidian/plugins/claudian/manifest.json
+++ b/.obsidian/plugins/claudian/manifest.json
@@ -0,0 +1,10 @@
+{
+  "id": "claudian",
+  "name": "Claudian",
+  "version": "2.0.10",
+  "minAppVersion": "1.4.5",
+  "description": "Embeds Claude Code as an AI collaborator in your vault. Your vault becomes Claude's working directory, giving it full agentic capabilities: file read/write, search, bash commands, and multi-step workflows.",
+  "author": "Yishen Tu",
+  "authorUrl": "https://github.com/YishenTu",
+  "isDesktopOnly": true
+}
--- a/.obsidian/plugins/claudian/styles.css
+++ b/.obsidian/plugins/claudian/styles.css
--- a/文字类提示词设计指南（上册）.md
+++ b/文字类提示词设计指南（上册）.md
@@ -0,0 +1,676 @@
+---
+title: "2026 文字类提示词设计指南（上册）"
+source: "https://x.com/AdrianPunk115/article/2056655062865490112"
+author:
+  - "[[Adrian Punk (@AdrianPunk115)]]"
+published: 2026-05-19
+created: 2026-05-20
+description: "2天时间，肝爆Chatgpt生图功能上限2次，达到长文图片上限，也挡不住我想分享的心！！！！那么就分两次发吧👇很多人用 AI 做中文字体图，第一句提示词就是：“帮我生成 XX 几个字。”然后出来的图，经常像 PPT 艺术字字可能是对的，但没有设计感。能看，但不能当封面。有..."
+tags:
+  - "clippings"
+---
+![Image](https://pbs.twimg.com/media/HIq1UlZaMAAh8ft?format=jpg&name=large)
+
+2天时间，肝爆Chatgpt生图功能上限2次，达到长文图片上限，也挡不住我想分享的心！！！！
+
+那么就分两次发吧👇
+
+很多人用 AI 做中文字体图，
+
+第一句提示词就是：“帮我生成 XX 几个字。”
+
+然后出来的图，经常像 PPT 艺术字字可能
+
+是对的，但没有设计感。 能看，但不能当封面。
+
+有画面，但没有标题冲击力。问题不一定在 AI。 更多时候，是提示词太空了。
+
+然后出来的图，经常像 PPT 艺术字。 字可能是对的，但没有设计感。 能看，但不能当封面。 有画面，但没有标题冲击力。
+
+问题不一定在 AI。 更多时候，是提示词太空了。
+
+“好看”不是指令。“高级”不是指令。“有设计感”也不是指令。
+
+**AI 真正需要的是更具体的描述：**
+
+这个字是什么字体？ 笔画是粗还是细？ 结构是紧凑还是舒展？ 边缘是锋利还是圆润？ 材质是金属、玻璃、贴纸，还是旧印刷？ 背景是科技界面、复古拼贴，还是手账纸张？
+
+**中文字体提示词，最好按这个公式写：**
+
+```text
+“文字内容”，字体类型，笔画/结构/重心/边缘描述；加入字效/材质/光影/背景，整体气质。
+```
+
+这就不是让 AI “写几个字”。 这是让 AI “设计一组字”。
+
+# 0个中文字体提示方案
+
+## 01｜时尚体
+
+![Image](https://pbs.twimg.com/media/HImL7WaakAAmeyw?format=jpg&name=large)
+
+（下方提示词顺序：左上、右上、左下、右下）
+
+**方案1：潮流品牌字**
+
+```text
+“潮流先锋”，时尚体，字形前卫，线条简洁流畅，笔画利落，结构紧凑，整体有现代潮牌感。
+```
+
+**方案 2：高级杂志字**
+
+```text
+“高级玩家”，时尚体，字形修长，笔画干净，字距舒展，结构优雅，整体像时尚杂志标题。
+```
+
+**方案 3：都市潮流字**
+
+```text
+“都市潮流”，时尚体，字形宽扁低重心，笔画横向延展，线条硬朗平直，结构紧密有节奏感，整体像现代城市潮流视觉标题。
+```
+
+**方案 4：先锋设计字**
+
+```text
+“先锋设计”，时尚体，字形结构大胆重组，局部笔画夸张变形，线条简洁但张力强，整体像实验性设计展海报标题。
+```
+
+## 02｜极简无衬线体
+
+![Image](https://pbs.twimg.com/media/HImMQs2a0AEC-7y?format=jpg&name=large)
+
+（下方提示词顺序：左上、右上、左下、右下）
+
+**方案 5：极简品牌字**
+
+```text
+“极简品牌”，极简品牌体，字形方正厚重，笔画粗细完全统一，横竖比例均衡，结构紧密稳定，字距克制，整体像高端品牌 Logo。
+```
+
+**方案 6：现代知识字**
+
+```text
+“现代知识”，知识标题体，字形端正清晰，笔画中等偏细，横竖线条干净利落，结构开放有序，字距舒展，整体像知识专栏或课程封面标题。
+```
+
+**方案 7：清爽标题字**
+
+```text
+“如沐春风”，清爽留白体，字形轻盈舒展，笔画细而均匀，线条柔和干净，字距大幅拉开，结构松弛有呼吸感，整体安静、清爽。
+```
+
+**方案 8：科技简洁字**
+
+```text
+“智能工作流”，几何科技体，字形模块化，笔画平直硬朗，横竖转角接近直角，结构规整像科技产品 UI 标题，整体理性、系统、数字化。
+```
+
+## 03｜细线体
+
+![Image](https://pbs.twimg.com/media/HImMXdyaAAAMNYm?format=jpg&name=large)
+
+（下方提示词顺序：左上、右上、左下、右下）
+
+**方案 9：轻奢细线字**
+
+```text
+“时间复利”，轻奢细线体，字形高挑窄长，竖向比例明显拉伸，横画短而克制，竖画细长挺拔，笔画带极轻微粗细变化，末端收笔精致干净，字距适中，整体像高级香水、珠宝品牌标题。
+```
+
+**方案 10：温柔细线字**
+
+```text
+“慢慢变好”，温柔细线体，笔画纤细柔和，线条带轻微自然弧度，字形舒展松弛，重心平稳，整体安静、温柔、像生活方式杂志标题。
+```
+
+**方案 11：高级知识字**
+
+```text
+“深度观察”，理性细线体，字形端正方阔，横竖线条清晰笔直，笔画细而有秩序，转折干净，结构开放，字距均衡，整体像深度知识专栏或研究报告标题。
+```
+
+**方案 12：未来细线字**
+
+```text
+“智能边界”，未来细线体，字形几何化，笔画纤细平直，横竖转角接近直角，局部笔画呈模块断开式连接，结构轻盈但精密，整体像未来科技界面的系统标题。
+```
+
+## 04｜单线字体
+
+![Image](https://pbs.twimg.com/media/HImgqO8bIAAeGOY?format=jpg&name=large)
+
+（下方提示词顺序：左上、右上、左下、右下）
+
+**方案 13：连续线稿体**
+
+```text
+“纤线灵动”，连续线稿体，字形由一根连续线条勾勒而成，线条粗细一致，转折流畅自然，笔画之间有连贯路径感，结构轻盈清晰，整体像极简线稿艺术标题。
+```
+
+**方案 14：草图单线体**
+
+```text
+“灵感草图”，草图单线体，字形像设计师手稿中的快速线条，笔画细而自然，线条带轻微抖动和手绘停顿，结构松弛但可读，整体像创意草图标题。
+```
+
+**方案 15：科技线框字**
+
+```text
+“连接万物”，科技线框体，字形由细直线和几何折线组成，笔画像线框结构搭建而成，横竖转角清晰，局部有节点式连接感，整体像科技网络界面的标题字体。
+```
+
+**方案 16：优雅单线字**
+
+```plaintext
+“留白之美”，优雅单线体，字形修长舒展，笔画由细长单线构成，横画克制，竖画挺拔，转折柔和，字距宽松，整体像高级展览海报中的极简标题。
+```
+
+## 05｜现代衬线体
+
+![Image](https://pbs.twimg.com/media/HImgw8AacAAV_4P?format=jpg&name=large)
+
+（下方提示词顺序：左上、右上、左下、右下）
+
+**方案 17：杂志衬线体**
+
+```text
+“都市韵律”，杂志衬线体，字形修长挺拔，笔画有明显粗细对比，横画纤细，竖画有力度，衬线短小利落，字距舒展，整体像高端时尚杂志标题。
+```
+
+**方案 18：商业衬线体**
+
+```text
+“增长模型”，现代衬线体，结构稳定，笔画利落，衬线克制，整体专业、商业、可信。
+```
+
+**方案 19：轻奢封面字**
+
+```text
+“高阶审美”，轻奢衬线体，字形高挑纤长，横画极细，竖画优雅挺拔，衬线精致尖细，收笔干净，字距略宽，整体像珠宝、香水或高定品牌标题。
+```
+
+**方案 20：深度专栏字**
+
+```text
+“深度观察”，专栏衬线体，字形方正端庄，笔画粗细分明，结构严肃有序，衬线短直稳定，字距均衡，整体像思想评论、财经专栏或深度报道标题。
+```
+
+## 06｜极简手写体
+
+![Image](https://pbs.twimg.com/media/HImhN2faAAAyIG_?format=jpg&name=large)
+
+（下方提示词顺序：左上、右上、左下、右下）
+
+**方案 21：清新手迹字**
+
+```text
+“清新手迹”，清新手迹体，字形轻盈自然，笔画细而流畅，线条像中性笔随手写下，结构简洁不复杂，字距舒展，整体干净、清爽、像生活杂志里的手写标题。
+```
+
+**方案 22：成长笔记字**
+
+```text
+“慢慢变好”，成长笔记体，字形柔和松弛，笔画带轻微粗细变化，横竖转折自然，结构像笔记本里的认真手写标题，整体温柔、真实、有自我成长记录感。
+```
+
+**方案 23：个人签名字**
+
+```text
+“自由开工”，个人签名体，字形连贯流动，笔画起伏明显，部分笔画自然相连，尾笔轻微拉长，整体像个人品牌签名，松弛但有识别度。
+```
+
+**方案 24：情绪手写字**
+
+```text
+“别急着稳定”，情绪手写体，字形轻微倾斜，笔画带速度感，线条有自然抖动和停顿，结构松动但清晰，整体像情绪很满时写下的一句手写标题。
+```
+
+## 07｜弯曲字体
+
+![Image](https://pbs.twimg.com/media/HImiXk3aAAAJ8I4?format=jpg&name=large)
+
+（下方提示词顺序：左上、右上、左下、右下）
+
+**方案 25：柔和曲线字**
+
+```text
+“信手拈来”，柔和曲线体，字形由大量圆润曲线构成，笔画转折柔顺，线条像丝带一样自然弯折，结构舒展流畅，整体温和、轻盈、有柔软动感。
+```
+
+**方案 26：女性美学字**
+
+```text
+“自在生长”，女性美学体，字形纤长柔美，笔画带优雅弧线，横竖转折自然收放，结构舒展不紧绷，整体像女性生活方式杂志中的柔美标题。
+```
+
+**方案 27：音乐律动字**
+
+```text
+“旋律流动”，音乐律动体，字形带明显波浪节奏，笔画像音符和声波一样起伏延展，线条流动感强，结构有节拍变化，整体像音乐海报标题。
+```
+
+**方案 28：艺术曲线字**
+
+```text
+“曲线之间”，艺术曲线体，字形由夸张曲线和不对称弧线重组，笔画弯折幅度明显，结构富有实验性但保持可读，整体像艺术展览海报中的曲线字体。
+```
+
+## 08｜手绘字体
+
+![Image](https://pbs.twimg.com/media/HImlWAYagAAWGL_?format=jpg&name=large)
+
+（下方提示词顺序：左上、右上、左下、右下）
+
+**方案 29：轮廓手绘体**
+
+```text
+“栩栩如生”，轮廓手绘体，字形由手工勾勒的外轮廓组成，笔画像被一笔一笔描出来，边缘带轻微不规则抖动，内部结构清晰，整体像手绘插画海报标题。
+```
+
+**方案 30：插画装饰体**
+
+```text
+“奇妙日常”，插画装饰体，字形圆润活泼，笔画像小插画一样被画出来，局部结构带星星、圆点、叶片般的图形化变化，整体像儿童绘本封面标题。
+```
+
+**方案 31：粗描海报体**
+
+```text
+“画出灵感”，草稿描线体，字形像设计草稿里的快速构思，笔画由多次重复描线组成，线条有断续和重叠感，结构自由但可读，整体像创作者画出来的标题字。
+```
+
+**方案 32：童趣涂鸦体**
+
+```text
+“今天不错”，童趣涂画体，字形像用画笔认真涂画出来，笔画圆胖不完全对齐，结构大小错落，边缘带手工涂画痕迹，整体天真、轻松、有儿童画感。
+```
+
+## 09｜涂鸦字体
+
+![Image](https://pbs.twimg.com/media/HImvdzpagAAiJ-g?format=jpg&name=large)
+
+（下方提示词顺序：左上、右上、左下、右下）
+
+**方案 33：街头涂鸦字**
+
+```text
+“天马行空”，锋利街头喷漆体，字形大幅倾斜张扬，笔画像高速喷漆扫过墙面，粗硬笔触带尖锐切角，边缘有喷漆颗粒、飞溅和干刷断裂，四个字横向紧凑排列，整体像街头墙面上攻击性很强的喷漆涂鸦标题。
+```
+
+**方案 34：青年观点字**
+
+```text
+“别装成熟”，手写标语涂鸦体，字形像粗马克笔在墙面上快速写下，笔画粗细不均，线条带明显手写停顿、拖拽和急停痕迹，四个字保持清晰可读，排列紧凑但不互相重叠，整体像年轻人写在街头墙上的反叛标语。
+```
+
+**方案 35：泡泡潮流涂鸦字**
+
+```text
+“能工智人”，泡泡潮牌涂鸦体，字形圆胖夸张，笔画厚实膨胀，外轮廓像街头 bubble graffiti 一样饱满，局部结构被拉伸和挤压，文字上下错位堆叠，整体像潮牌海报里的泡泡涂鸦标题。
+```
+
+**方案 36：爆裂摇滚涂鸦字**
+
+```text
+“声音失控”，爆裂摇滚涂鸦体，字形像被音浪震碎后重新拼成，笔画粗暴破碎，边缘有撕裂毛刺和碎片感，文字采用上下错位的爆炸式构图，局部笔画向外冲出，整体像地下摇滚演出海报上的失控标题。黑底白字，纯字体设计，无装饰。
+```
+
+## 10｜艺术字体
+
+![Image](https://pbs.twimg.com/media/HImwxEQasAAgTYV?format=jpg&name=large)
+
+（下方提示词顺序：左上、右上、左下、右下）
+
+**方案 37：抽象艺术字**
+
+```text
+“浑然天成”，抽象构成体，字形由几何块面和抽象线条重新组合，笔画结构打破常规但保持可读，局部笔画像图形元素一样错位拼接，整体像现代艺术海报中的构成主义标题。
+```
+
+**方案 38：展览字**
+
+```text
+“视觉实验”，展览海报体，字形克制而有设计感，笔画结构被轻微拉伸和切分，线条干净，字距舒展，整体像艺术馆、设计展或美术馆海报中的高级标题。
+```
+
+**方案 39：概念实验字**
+
+```text
+“意识流动”，概念实验体，字形结构不规则，笔画像被拆解后重新排列，局部线条断开、漂移和错层，整体保持可读但充满先锋实验感，像概念艺术展的标题字。
+```
+
+**方案 40：创作者标题字**
+
+```text
+“灵感爆炸”，创作者爆发体，字形夸张有张力，笔画向外扩张，局部结构放大、扭转和冲出边界，整体像创作者灵感喷发时形成的强视觉标题。
+```
+
+## 11｜夸张体
+
+![Image](https://pbs.twimg.com/media/HInXkXpbUAI4ClW?format=jpg&name=large)
+
+（下方提示词顺序：左上、右上、左下、右下）
+
+**方案 41：强冲击标题字**
+
+```text
+“巨大反差”，强冲击夸张体，字形极度放大，笔画粗壮厚重，结构被压缩得紧密有力量，局部笔画夸张加宽，整体像强冲击海报中的重磅标题。
+```
+
+**方案 42：爆款封面字**
+
+```text
+“一眼看懂”，爆款封面体，字形粗黑醒目，笔画饱满直接，结构清晰紧凑，字与字之间排列有强烈标题节奏，整体像短视频封面或爆款文章封面上的大标题。
+```
+
+**方案 43：表情包标题字**
+
+```text
+“离谱现场”，表情包夸张体，字形故意变形放大，笔画圆胖又不规则，结构带夸张扭动和表情感，字与字大小错落，整体像搞笑表情包里的情绪标题。
+```
+
+**方案 44：强观点夸张字**
+
+```text
+“别再内耗”，强观点夸张体，字形锋利紧绷，笔画粗硬有力量，结构向前倾斜，横竖转折带明显冲撞感，整体像观点海报中一句掷地有声的强表达标题。
+```
+
+## 12｜未来感字体
+
+![Image](https://pbs.twimg.com/media/HIm59rCa8AAcl3R?format=jpg&name=large)
+
+（下方提示词顺序：左上、右上、左下、右下）
+
+**方案 45：科技标题字**
+
+```text
+“未来入口”，科技标题体，字形硬朗几何，笔画平直有力，横竖转折接近直角，局部结构带轻微切角，字距克制，整体像未来科技产品发布会的大标题。
+```
+
+**方案 46：液态未来字**
+
+```text
+“流动智能”，液态未来体，字形像被柔性材料生成，笔画有流体般的弯折和拉伸，边缘顺滑，结构在稳定和变形之间保持平衡，整体像未来材料、AI 生命体或新科技品牌标题。
+```
+
+**方案 47：虚拟空间字**
+
+```text
+“虚拟边界”，虚拟空间体，字形带空间透视和折叠感，笔画像立体平面被切开后重新组合，结构有前后层次和空间错位，整体像虚拟现实、元宇宙或空间计算系统标题。
+```
+
+**方案 48：赛博断裂字**
+
+```text
+“量化信号”，赛博断裂体，字形冷峻锋利，笔画被数字故障切成错位片段，局部结构有横向漂移、断裂和重组感，整体像高强度赛博世界、未来交易系统或数字战场标题。
+```
+
+## 13｜趣味变形体
+
+![Image](https://pbs.twimg.com/media/HInXGYybUAIbADP?format=jpg&name=large)
+
+（下方提示词顺序：左上、右上、左下、右下）
+
+**方案 49：趣味标题字**
+
+```text
+“脑洞打开”，趣味标题体，字形轻微变形，笔画圆润有弹性，结构大小略有错落，局部笔画像被轻轻拉伸，整体轻松、有趣、像创意内容栏目的标题字。
+```
+
+**方案 50：搞笑封面字**
+
+```text
+“笑到离谱”，搞笑封面体，字形夸张扭动，笔画圆胖不规则，结构像被笑声挤压变形，字与字大小错落，整体像搞笑视频封面或热梗表情标题。
+```
+
+**方案 51：创意课程字**
+
+```text
+“一学就会”，模块课程标题体，字形清晰规整，笔画饱满厚实，局部结构像卡片模块一样拼接组合，横画和竖画带轻微错位层次，转角柔和但不圆滑，整体像创意课程、知识卡片或教程封面中的现代标题字。
+```
+
+**方案 52：儿童活动字**
+
+```text
+“快乐出发”，气球童趣体，字形圆润鼓起，笔画像充气气球一样饱满柔软，结构高低跳跃，局部笔画带轻微膨胀和收束感，整体轻快、天真、像儿童活动海报里的欢乐标题字。
+```
+
+## 14｜像素风格体
+
+![Image](https://pbs.twimg.com/media/HInZ_FCaIAA5EtJ?format=jpg&name=large)
+
+（下方提示词顺序：左上、右上、左下、右下）
+
+**方案 53：复古游戏字**
+
+```text
+“像素人生”，复古像素体，字形由清晰的小方块像素拼成，横竖结构规整，边缘呈阶梯状锯齿感，整体像 8bit 复古游戏里的标题字。
+```
+
+**方案 54：街机游戏字**
+
+```text
+“开局暴击”，街机游戏体，字形厚重紧凑，笔画由大块像素组成，结构方正有力量，边缘带明显像素台阶，整体像街机游戏或游戏封面里的高能标题字。
+```
+
+**方案 55：像素字**
+
+```text
+“信号丢失”，像素故障体，字形由方块像素组成，局部笔画出现横向错位、缺块和断裂，结构保持可读但带明显数字故障感，整体像复古屏幕出现干扰时的标题字。
+```
+
+**方案 56：方块模块字**
+
+```text
+“模块世界”，方块模块体，字形由规整方形模块拼接而成，笔画方正厚实，结构像网格系统中搭建出来的文字，整体清晰、秩序、像像素化系统标题。
+```
+
+## 15｜复古字体
+
+![Image](https://pbs.twimg.com/media/HIndjk1bEAAVeqK?format=jpg&name=large)
+
+（下方提示词顺序：左上、右上、左下、右下）
+
+**方案 57：老电影字**
+
+```text
+“旧梦重温”，老电影字幕体，字形端正克制，笔画粗细适中，结构清晰稳定，边缘带轻微旧胶片字幕的印刷颗粒感，整体像上世纪电影片头或老字幕里的怀旧标题字。
+```
+
+**方案 58：霓虹旧街**
+
+```text
+霓虹旧街”，港式旧招牌体，字形厚重醒目，结构紧凑饱满，笔画带老式商号招牌的方正骨架和手工刻字感，转折处略带复古圆角，整体像八九十年代港式老街店招、旧茶餐厅或传统商铺牌匾标题。
+```
+
+**方案 59：复古广告字**
+
+```text
+“省钱才是硬道理”，复古字体，笔画粗壮，字形带老式招牌感，整体怀旧、接地气。
+```
+
+**方案 60：复古故事字**
+
+```text
+“纸上年华”，怀旧出版体，字形端庄清晰，笔画带传统印刷标题字的稳重感，结构舒展有书卷气，横竖比例均衡，整体像旧杂志、老书封面或怀旧刊物中的标题字。
+```
+
+## 16｜哥特风格字体
+
+![Image](https://pbs.twimg.com/media/HIne7irboAEPIls?format=jpg&name=large)
+
+（下方提示词顺序：左上、右上、左下、右下）
+
+**方案 61：暗黑标题字**
+
+```text
+“哈利波特”，哥特风格字体，线条尖锐细长，笔画粗细对比鲜明，整体神秘、冷峻。
+```
+
+**方案 62：中世纪字**
+
+```text
+“魔兽世界”，哥特风格字体，笔画尖锐，字形像铁刺延展，结构复杂但清晰，整体奇幻、危险。
+```
+
+**方案 63：黑金属尖刺字**
+
+```text
+“深渊回声”，黑金属尖刺体，字形极度尖锐，笔画向上下延伸成刺状结构，转折处带锋利裂口，整体紧密、凌厉、攻击性强，像黑金属乐队 Logo 或暗黑演出海报标题。
+```
+
+**方案 64：华丽哥特饰字**
+
+```text
+“秘银王冠”，华丽哥特装饰体，字形高挑纤长，笔画带尖细起收笔和优雅弯折，局部结构有克制的哥特花体装饰感，整体神秘、精致、像暗黑宫廷或哥特珠宝品牌标题。
+```
+
+## 17｜毛笔字
+
+![Image](https://pbs.twimg.com/media/HIqQcAKaQAAvmZS?format=jpg&name=large)
+
+（下方提示词顺序：左上、右上、左下、右下）
+
+**方案 65：报头提题体**
+
+```text
+“人民日报”，报头题字毛笔体，字形庄重开阔，笔画厚实有墨色重量，带传统毛笔题词的顿挫和筋骨，横画沉稳，竖画有力，结构端正大气。根据书法气质自动采用更适合的传统字形或繁体写法，但保持文字含义准确可读。整体像中文主流报纸报头、时代刊物封面或重要题词中的权威标题字。
+```
+
+**方案 66：狂草书法体**
+
+```text
+“山海之间”，高级狂草毛笔字 Logo，黑色纯背景，白色水墨书法，纯字体设计。要求字体极具狂草气势，笔画连绵飞动，粗细强烈对比，起笔有顿挫，行笔迅疾，收笔带锋。整体像书法大师一气呵成，带有山势起伏、海浪流动的抽象节奏。保留可读性，但结构不必工整，允许适度变形、连笔、飞白、断墨、墨迹晕染。
+```
+
+**方案 67：行书体**
+
+```text
+“行云流水”，潇洒行书练笔体，字形飘逸流动，笔画带真实行书练笔的提按、转腕、连带和细微牵丝，线条粗细灵活变化，部分笔画轻盈游走，部分笔画沉稳压住，字与字之间气脉连续但保持清晰可读。整体随性、有功力，像书法家在宣纸上一气呵成写下的文化品牌题字。根据书法气质自动采用更适合的传统字形或繁体写法，但保持文字含义准确可读。
+```
+
+**方案 68：禅意体**
+
+```text
+“难得糊涂”，老先生禅意题字体，字形松弛随性，笔画像毛笔蘸墨后慢慢写下，起笔有停顿，行笔有自然抖动和提按变化，收笔不刻意修饰，线条有粗有细、有圆有扁，结构不完全对齐，字与字之间有手写呼吸感。整体随意中带功力，温和中有识别度，像民宿招牌、茶室题字、山居民宿 Logo、东方生活方式品牌题字。根据书法气质自动采用更适合的传统字形或繁体写法，但保持文字含义准确可读。
+```
+
+## 18｜西部手写字体
+
+“奶油星球”，奶油甜品体，字形像奶油和甜品一样柔软膨胀，笔画厚实圆润，边缘顺滑，局部结构带轻微融化和堆叠感，整体甜美、可爱、像甜品店、烘焙品牌或可爱包装标题。黑底白字，纯字体设计，无装饰。
+
+![Image](https://pbs.twimg.com/media/HIqZ3C3bUAAWYRg?format=jpg&name=large)
+
+**方案 69：西部牛仔标题体**
+
+```text
+“荒野来信”，西部牛仔标题体，字形粗犷硬朗，笔画厚重有力量，结构带美式西部木牌招牌的方正感，转角略带粗糙切削痕迹，边缘有轻微旧印刷磨损，整体像牛仔酒馆、荒野小镇或西部电影海报中的中文标题字。黑底白字，纯字体设计，无装饰。
+```
+
+**方案 70：通缉令字体**
+
+```text
+“落日公路”，美式公路字体，字形横向舒展，笔画干净有速度感，结构像复古公路路牌和汽车旅馆招牌的中文标题，线条稳重但不笨重，边缘带轻微旧漆脱落和风吹日晒的磨损感，整体像 66 号公路、落日旅行或复古公路海报标题。
+```
+
+**方案 71：赏金字**
+
+```text
+“赏金猎人”，荒野通缉令标题体，字形粗犷压缩，笔画像西部 WANTED 海报中的木刻粗衬线字体，横竖厚重，转角带刀削感和木牌刻痕，结构紧凑有压迫感，整体像牛仔小镇、赏金通缉令、酒馆公告或荒漠故事封面标题。边缘有沙尘颗粒、纸张破旧和印刷缺墨，但避免中国复古海报、旧报刊、老广告标题感。
+```
+
+**方案 72：机车西部字**
+
+```text
+“自由骑士”，机车西部体，字形锋利硬派，笔画粗壮有冲击力，结构带复古机车俱乐部、皮革徽章和西部酒馆招牌的混合气质，转折处有尖角、金属刻印感和粗犷切削边缘，边缘带轻微磨损。整体像机车文化、荒野骑行、牛仔公路或硬派复古品牌标题。
+```
+
+## 19｜国潮体
+
+![Image](https://pbs.twimg.com/media/HInh1F-aYAAfkzW?format=jpg&name=large)
+
+（下方提示词顺序：左上、右上、左下、右下）
+
+**方案 73：东方瘦金体体**
+
+```text
+“东方醒来”，东方瘦金标题体，字形高挑清峻，笔画细而有锋芒，横画舒展如弦，竖画挺拔如骨，转折处带瘦金体的尖锐顿挫和书法筋骨，结构疏朗有贵气，整体像高级国风海报、新中式品牌或东方美学展览标题。
+```
+
+**方案 74：国风牌匾体**
+
+```text
+“山河入梦”，国风牌匾体，字形厚重饱满，笔画带传统牌匾字的稳重骨架，横画宽阔沉着，竖画有力，起收笔带手工刻字般的方圆顿挫，结构紧凑端庄，整体像老字号牌匾、国风店招或传统文化品牌标题。
+```
+
+**方案 75：潮流篆意体**
+
+```text
+“万象更新”，潮流篆意体，字形吸收篆书的圆转结构和对称秩序，笔画被现代化简化重组，线条厚实流畅，结构带图腾感和潮流视觉张力，整体像国潮品牌或东方潮流海报标题。
+```
+
+**方案 76：东方海报**
+
+```text
+“伯牙绝弦”，东方海报体，字形大气张扬，笔画带书法飞白和现代海报的块面冲击，结构舒展有势，横竖转折富有力量，整体像国风电影、东方美学展览或新国潮海报中的主标题。
+```
+
+## 20｜童趣商业字体
+
+![Image](https://pbs.twimg.com/media/HIqfjNuagAAEOXu?format=jpg&name=large)
+
+（下方提示词顺序：左上、右上、左下、右下）
+
+**方案 77：儿童绘本体**
+
+```text
+“云朵小孩”，儿童绘本蜡笔手绘体，字形圆润自然，笔画像儿童绘本封面里的蜡笔或彩铅手绘标题，线条柔和但不膨胀，边缘有轻微手绘颗粒和不均匀感，结构高低错落但清楚可读，整体温暖、天真、有故事感，像儿童绘本封面、亲子阅读栏目或儿童故事标题。
+```
+
+**方案 78：乐高玩具体**
+
+```text
+“快乐开箱”，积木拼装标题体，字形由大块圆角积木模块组合而成，笔画像玩具积木一样厚实、平整、有卡扣感，结构轻微错位堆叠，字与字之间有拼装玩具的节奏感，但保持每个汉字清楚可读。整体像积木玩具盒、儿童益智产品包装或拼装游戏 Logo。
+```
+
+**方案 79：零食包装字**
+
+```text
+“糖果派对”，零食包装跳跳体，字形活泼醒目，笔画厚实但不圆胖膨胀，结构像儿童零食袋上的中文大标题，字与字之间有轻微弹跳和错位节奏，局部笔画带手绘包装字的俏皮切角和轻快弧度。不要爱心、星星、表情、糖果图案或任何额外装饰。
+```
+
+**方案 80：剪纸拼贴字**
+
+```text
+“手工时间”，手剪纸片拼贴字体，字形由白色剪纸碎片拼接成中文标题，每个笔画都像独立纸片贴上去，纸片之间保留细小黑色缝隙，局部有重叠压住的层次、轻微翘边和错位。边缘有手剪毛边、纸纤维粗糙感和不均匀切口，整体童真、手作、像儿童手工课剪贴出来的标题字。保持文字清楚可读。
+```
+
+## 21｜城市商业招牌体
+
+![Image](https://pbs.twimg.com/media/HIqrIA7bgAAUsFp?format=jpg&name=large)
+
+（下方提示词顺序：左上、右上、左下、右下）
+
+**方案 81：灯管字**
+
+```text
+夜里开门”，城市霓虹门店字，字形像现代街区小店的发光招牌标题，笔画简洁醒目，结构规整但带轻微霓虹灯管的圆角转折感，线条像灯管弯折组成，但保持纯白字体效果。整体像夜晚便利店、酒吧、小餐馆或城市街角门店招牌。不要国风牌匾、不要老报刊、不要复古海报、不要普通粗黑字。
+```
+
+**方案 82：夜市菜单字**
+
+```text
+“夜宵上桌”，夜市菜单牌字体，字形像街边烧烤摊、砂锅店、深夜食堂菜单牌上的中文标题字，笔画厚实直接，结构紧凑醒目，转角带手写招牌的圆钝变化，字面有热闹市井感和夜宵烟火气，整体像夜市价目牌、快餐菜单大字或深夜餐饮海报标题。
+```
+
+**方案 83：便利贴字**
+
+```text
+“随手买点”，便利店宽头马克笔标签体，字形像便利店货架价签和促销贴纸上用宽头油性马克笔手写出来的中文标题，笔画直接有力，线条粗实平涂，起收笔带宽头马克笔的钝角切面，边缘有轻微墨水渗透和纸面洇开感。部首交界处、笔画重叠处和转折处有明显叠墨变深效果，结构清楚但不完全工整，整体明快、真实，像社区便利店、零食货架或临时促销牌上的手写标签字。
+```
+
+**方案 84：电商促销字**
+
+```text
+“劲爆特价”，暴走漫画促销体，字形极度夸张，笔画巨大厚实，结构被挤压、拉扯和爆裂变形，字与字之间紧密堆叠，像促销海报上冲出来的叫卖大字。整体有暴走漫画式怒吼感、超市清仓感和限时特价冲击力，视觉直接、粗暴、夸张、让人一眼停住。
+```
--- a/Inbox/Claude
+++ b/Inbox/Claude
@@ -0,0 +1,193 @@
+---
+title: "Claude Code 工程化指南：高效组织 .claude/ 目录"
+source: "https://x.com/vincemask/article/2056757482152960110"
+author:
+  - "[[Vince 聊开发 (@vincemask)]]"
+published: 2026-05-19
+created: 2026-05-20
+description: "为什么结构很重要？大多数 Claude Code 用户知道 .claude/ 文件夹的存在，但很少有人认真思考它的组织方式。项目小的时候，一个 CLAUDE.md、几个设置文件就够了。但随着项目增长，指令变得难以维护，工作流散落在错误的地方，文件夹慢慢变成有用配置和难以解释的混乱..."
+tags:
+  - "clippings"
+---
+![Image](https://pbs.twimg.com/media/HIr7nm6bkAEXYr-?format=jpg&name=large)
+
+# 为什么结构很重要？
+
+大多数 Claude Code 用户知道 .claude/ 文件夹的存在，但很少有人认真思考它的组织方式。项目小的时候，一个 CLAUDE.md、几个设置文件就够了。但随着项目增长，指令变得难以维护，工作流散落在错误的地方，文件夹慢慢变成有用配置和难以解释的混乱的混合物。
+
+一个组织良好的 .claude/ 文件夹让 Claude 更容易被引导、被信任，也更容易在真实项目中扩展。
+
+# 目标结构蓝图
+
+```markdown
+your-project/
+├── CLAUDE.md              # 主项目指令
+├── CLAUDE.local.md         # 个人覆盖（不提交）
+└── .claude/
+    ├── settings.json        # 控制层
+    ├── settings.local.json  # 本地覆盖
+    ├── rules/               # 模块化指令
+    ├── hooks/               # 自动化脚本
+    ├── commands/            # 可复用提示词工作流
+    ├── skills/              # 打包能力
+    └── agents/              # 专用子代理
+```
+
+# 核心原则
+
+## 1\. 顶层要轻
+
+- CLAUDE.md：解释项目如何工作（栈、架构、关键命令、全局约定）
+- .claude/settings.json：控制 Claude 在项目中的操作方式（权限、hooks、项目级行为）
+- CLAUDE.local.md / .claude/settings.local.json：个人覆盖，不进git版本控制
+
+这两层分开：一个负责**引导**，一个负责**控制**。
+
+## 2\. CLAUDE.md 与 rules/ 的划分
+
+**CLAUDE.md 放全局指导**——每次会话都需要的内容：
+
+- 主要技术栈
+- 高层架构
+- 最重要的开发命令
+- 广泛适用的代码约定
+- 项目级警告或约束
+
+**rules/ 放专项指导**——某个领域或工作流的规则：
+
+```markdown
+.claude/
+└── rules/
+    ├── frontend.md
+    ├── backend-api.md
+    ├── testing.md
+    └── data-pipelines.md
+```
+
+什么时候应该拆分成 rules/：
+
+- CLAUDE.md 开始显得拥挤
+- 不同仓库区域需要不同指导
+- 不同人有不同标准
+- 团队经常更新约定
+- 想按路径限定指令作用域
+
+CLAUDE.md 建议参考这篇文章进行调整
+
+> May 7
+
+## 3\. hooks/ 和 commands/ 分工
+
+**hooks/**：自动运行的脚本，不放在说明文档中
+
+- 拦截危险操作（如 [block-dangerous-commands.sh](https://block-dangerous-commands.sh/)）
+
+清理或验证输出（如 [format-edits.sh](https://format-edits.sh/)）
+
+强制执行工作流要求（如 [run-tests-before-stop.sh](https://run-tests-before-stop.sh/)）
+
+**commands/**：可复用的提示词工作流，不是自动运行的
+
+- 审查 PR（review-pr.md）
+- 编写测试（write-tests.md）
+- 为发布准备变更摘要（summarize-changes.md）
+
+```markdown
+.claude/
+├── hooks/
+│   ├── block-dangerous-commands.sh
+│   ├── format-edits.sh
+│   └── run-tests-before-stop.sh
+└── commands/
+    ├── review-pr.md
+    ├── write-tests.md
+    └── summarize-changes.md
+```
+
+命名要清晰：[format-edits.sh](https://format-edits.sh/) 好过 [script1.sh](https://script1.sh/)。
+
+## 4\. skills/ 和 agents/ 的进阶结构
+
+**skills/**：打包的能力，工作流有多个步骤、需要配套文档时使用
+
+```markdown
+.claude/
+└── skills/
+    ├── release-prep/
+    │   ├── SKILL.md
+    │   └── release-template.md
+    └── docs-audit/
+        ├── SKILL.md
+        └── style-guide.md
+```
+
+**commands/ vs skills/** 的区别：
+
+- commands/ = 轻量可复用任务（一个文件就够了）
+- skills/ = 更丰富的打包工作流（多个步骤 + 配套文档）
+
+**agents/**：专用子代理，需要更聚焦的角色时使用
+
+```markdown
+.claude/
+└── agents/
+    ├── code-reviewer.md
+    ├── security-auditor.md
+    └── docs-writer.md
+```
+
+每个 skill 解决一个重复出现的完整工作流，每个 agent 拥有一个专门角色。如果两个文件高度重叠，应该合并或简化。
+
+## 5\. 团队结构 vs 个人结构的分离
+
+```markdown
+# 项目级（团队共享）
+your-project/
+├── CLAUDE.md
+└── .claude/
+    ├── settings.json
+    ├── rules/
+    └── hooks/
+
+# 用户级（个人偏好）
+~/.claude/
+├── CLAUDE.md
+├── settings.json
+├── skills/
+├── agents/
+└── projects/
+```
+
+**判断标准**：如果配置帮助整个团队更一致地工作 → 放项目级。如果主要反映一个人的工作流 → 放本地或全局设置。
+
+**本地覆盖文件**：CLAUDE.local.md 和 .claude/settings.local.json 是很好的中间层，让人可以在不污染版本控制的情况下调整行为。
+
+# 渐进式成长路径
+
+不要一开始就填满所有文件夹。按需增加：
+
+1. **起步**：CLAUDE.md + .claude/settings.json
+2. **指令膨胀**：加 rules/
+3. **需要自动化**：加 hooks/
+4. **提示词重复**：加 commands/
+5. **工作流变深**：加 skills/
+6. **需要专精角色**：加 agents/
+
+# 常见错误
+
+![Image](https://pbs.twimg.com/media/HIr1_uaacAATGj5?format=png&name=large)
+
+# 关键要点
+
+最高效的 .claude/ 文件夹不是功能最丰富的，而是**每个部分都有清晰用途**的。好的结构应该能立即回答这些问题：
+
+- 项目级指令在哪里？
+- 模块化规则放哪里？
+- 自动化脚本放哪里？
+- 可复用工作流放哪里？
+- 哪些是共享的，哪些是私人的？
+- 哪些是活跃的，哪些只是实验？
+
+当 .claude/ 组织好了，Claude 用起来会可预测、可维护、易于团队共享。
+
+![Image](https://pbs.twimg.com/media/HIr6ouWasAAOr8x?format=jpg&name=large)
--- a/Playbook.md
+++ b/Playbook.md
--- a/Inbox/创始人行动手册：打造一家
+++ b/Inbox/创始人行动手册：打造一家
@@ -0,0 +1,680 @@
+---
+title: "创始人行动手册：打造一家 AI-Native 创业公司"
+source: "https://x.com/AlchainHust/article/2056595872754848232"
+author:
+  - "[[花叔 (@AlchainHust)]]"
+published: 2026-05-19
+created: 2026-05-20
+description: "译自 Anthropic 官方手册《The Founder's Playbook: Building an AI-Native Startup》 2026 年 5 月发布花叔注：这是 Anthropic 五月发布的一份创始人手册。三十六页，把 AI 时代的创业生命周期重新画了一遍..."
+tags:
+  - "clippings"
+---
+![Image](https://pbs.twimg.com/media/HIp-_T3bYAAp2S5?format=jpg&name=large)
+
+译自 Anthropic 官方手册《The Founder's Playbook: Building an AI-Native Startup》 2026 年 5 月发布
+
+花叔注：
+
+这是 Anthropic 五月发布的一份创始人手册。三十六页，把 AI 时代的创业生命周期重新画了一遍。
+
+这本手册主要讲的是，当一个人就能完成过去一整支团队的工作时，创业流程会变成什么样。它把这件事拆成四个阶段：想法、MVP、发布、规模化。每个阶段先讲目标和退出条件，再讲容易踩的坑，最后才是 Claude 怎么用。
+
+我觉得最值得读的部分，其实是「容易踩的坑」那几节。比如「把『造』误当作『验证』」「AI 把确认偏误装上了一台研究引擎」「零摩擦的范围蔓延」——这些都是在 AI 让一切变得太容易之后，反而会暴露出来的新风险。
+
+我尽量做了贴近原意的翻译，保留了一些英文专有名词（PMF、TAM、GTM、[CLAUDE.md](http://claude.md/) 等），因为强行中译会失真。
+
+全文约两万五千字，是一篇能完整读完的长文。也可以收藏起来，按阶段对照你当前的处境来翻。
+
+———
+
+## 第一章 创业生命周期，为 2026 重新启动
+
+AI 正在重塑创业公司的建造方式。今天，从未写过一行代码的创始人正在交付生产级应用，而「10 人独角兽」也从草根传奇变成了一套可以被认真规划的行动方案。
+
+到 2026 年，AI 可以写生产环境代码、做市场调研、梳理竞争格局、起草投资人材料，并自动化运营流程。它抹平了过去很陡的学习曲线：即使经验丰富的技术创始人，以前也要花大量时间整合工具、平台和系统，才能把想法落地。**AI 最重要的贡献，是把「谁能启动一家公司、谁能做出一个产品」这件事的门槛拉平了。**
+
+2026 年，一个好想法能把创始人带到比以往任何时候都更远的地方。Agentic 编程把过去需要一整支工程团队完成的工作，压缩成了创始人自己就能交付的体量。
+
+传统创业增长曲线默认路径是：验证 → 融资 → 招人 → 建造 → 再融资 → 增长 → 继续招人 → 重复。现在，AI 已经抹掉了一个默认预期：创业生命周期的每个新阶段，都必须配更大的团队、不同的技能组和新一轮融资。
+
+这本手册会按照这些新现实，重新绘制创业旅程的四个核心阶段：想法、MVP、发布、规模化。我们会逐阶段看：当 AI 成为技术和组织发展的核心基础设施时，每个阶段长什么样；每个阶段该用哪些工具；以及走在前面的创始人如何用这些工具压缩时间线。
+
+———
+
+## 第二章 「创始人」这件事正在改变
+
+过去，创始人是被「能做什么」定义的：技术型创始人写代码，非技术型创始人跑业务、谈合同。但 2026 年创始人可用的模型、系统和 AI agent，已经溶解了「能造东西的人」和「有想法值得造的人」之间那堵墙。
+
+AI-Native 创业公司正在从根本上改变「成为创始人」的含义。**现在，一个完全没有工程背景的人，可以做出真正能跑的生产级软件来实现自己的想法**；而一个技术很强但商业知识有限的创始人，也能轻松产出 GTM 策略、财务模型和高度打磨的 pitch deck。
+
+从历史上看，创始人大部分时间都在执行模式里：写代码、管人、处理日常运营。**在 AI-Native 创业公司里，创始人的角色不再只是个人贡献者，而更像是一群 agent 的编排者。** 这些 agent 是专门化的 AI 助手，能读文件、跑命令、执行代码，甚至浏览网页。创始人的注意力开始上移，转向更高阶的工作：产生想法，并指挥 AI agent、工具和小团队把想法落实。
+
+AI 作为核心基础设施最革命性的结果，是它解锁了有领域专长的非技术背景创始人。当创始人池不再只来自工程背景，你会看到由完全不同人生经验的人创建的公司，去解决传统技术创始人输送管道从未优先关注，甚至从未注意到的真实问题。
+
+AI 为精益创业带来的能力
+
+传统创业模型假定你必须招工程师来造、招销售来卖、招运营来跑公司。「人头数」被看作组织势能和产品成熟度的标志。
+
+2026 年的早期创业公司则完全不同。它们在设计上极度精益，往往只有创始人一人，或加上少数伙伴。把技术与组织发展都建立在 AI 这一基础设施之上，它们可以在扩张团队之前就达成产品验证、产生早期收入，甚至盈利。AI 在三个地方能让一家创业公司像大得多的组织一样运转：研究、Agentic 编程、以及关键业务运营的工作流自动化。
+
+对话式智能与研究
+
+类比：任何领域随叫随到的专家。
+
+想想看，一个创始人在第一年里几乎肯定不知道但又必须知道的事情：怎么搭工资发放系统？怎么规划产品开发冲刺？怎么写一份紧凑的投资人备忘录？
+
+早期创业的这类问题过去几乎都是同一个答案：找一个懂的人。对一个自筹资金或种子前的创始人来说，这意味着把本该用来建造的时间花在打听上，或者把早期资金烧一部分给顾问。现在，他们手里就有一个跨几乎所有领域、随时在岗的专家：AI。
+
+- 深度研究：竞品分析、市场规模测算、财务建模
+- 文档起草：pitch deck、案例研究、投资人备忘录、PRD
+- 战略思考伙伴：反方代言人分析、事前剖析、情境推演、路线图优化
+
+Agentic 编程
+
+类比：那位永远在线、永不被卡住的工程师。
+
+过去，要做出软件，要么得有一个技术合伙人，要么外包给开发公司，要么有足够长的跑道，先招够一支工程团队，然后才能写下第一行生产代码。
+
+Agentic 编程工具如今让每一个有想法的创始人，都可以用平实语言描述自己想做什么，然后指挥 AI 生成、测试、调试、重构一份生产级代码库，速度和体量都堪比一支完整工程团队。
+
+从「我有一个想法」到「我有一个产品」的时间线被压缩了。**创始人的角色现在聚焦在「该做什么、为什么做」，而 AI 负责真正的基础设施搭建**，那些直接面对真实用户的部分。
+
+工作流自动化
+
+类比：一支随时听用的自动化运营团队。
+
+即使创始人能像顾问一样研究、像工程团队一样写代码，战略规划和产品开发之外仍有整整一类工作必须完成：排期、更新 CRM、拉周报、维护文档、发布内容、追踪合规要求、管理公司赖以运转的工具和系统之间的连接。这些也都要发生。在精益创业公司里，这些负担主要落在创始人身上，并且会大量侵占本该用于高阶判断的时间和注意力。
+
+AI 工具的工作流自动化能卸掉这笔税。重复性运营任务可以被配置为自动发生：交易状态变化时 CRM 自动更新，周报自己汇总，产品文档跟随产品变化同步更新。关键在于，Claude Cowork 能集成创业公司使用的互联系统，例如项目管理工具、沟通栈、数据源，而不需要有人专门构建并维护这些集成。在第零天创业公司里，那个人几乎总是创始人本人。
+
+时机和编排，是一切
+
+能有效驾驭 AI 的研究能力、自动化能力和 agentic 编程能力的创始人，能用远超团队规模所暗示的杠杆来运营一家公司。他们也能把大部分时间和带宽，放在那些真正重要的工作上。
+
+但这套东西不会自动巡航。负责编排这些 AI 工具的创始人，必须知道如何用、什么时候用。本手册剩下的部分，就是探索 AI-Native 创业路径上每一阶段的目标、挑战，以及如何在旅程的每个阶段有效应用 AI 工具。
+
+———
+
+## 第三章 想法阶段
+
+每个创业的创始人都从同一个地方出发：一个让你停不下来去想的问题。这就是创业里想法撞上现实的阶段。**2026 年的创业成功，要求你具备一种纪律：在证据足够之前，不动手造。**
+
+这一阶段的工作是研究、客户发现、竞品分析、以及对反证的诚实评估。所有这些，都要发生在你打开 Claude Code 让它写下第一行生产代码之前。
+
+想法阶段·目标
+
+在想法阶段，创始人的核心目标是以研究为导向的验证：在投入资源开始造东西之前，攒起扎实证据来证明一个真实问题确实存在，并且你提议的方案确实有效解决它。
+
+具体来说，想法阶段是一系列大致按以下顺序回答的问题：
+
+- 这个问题是真实的、具体的、足够高频的，值得围绕它做一家公司吗？
+- 到底谁有这个问题？这些人能构成一个市场吗？
+- 是否已经有人在解决它？如果是，他们怎么做，做得多好？
+- 一个真正解决这个问题的方案需要做到什么？我的想法做到了吗？
+
+这些问询加起来，回答一个终极问题：这值不值得做？
+
+也就是说，先具体，再行动。「报销报告让人头痛」是观察。「中型市场公司的财务经理每周要花 4 小时以上核对报销提交，因为现有工具不和会计软件打通」才是一个可以测试的假设。
+
+想法阶段·退出标准
+
+想法阶段的退出条件，是找到 problem-solution fit（问题-方案匹配）。你要在开始造解决方案之前，建立起质性证据，主要来自真实的人类对话，证明你正在为真实的人解决真实问题。
+
+当你能对以下三个问题都答「是」时，就准备好离开想法阶段了：
+
+- 这个问题真实且具体吗？你必须能说出谁经历这个问题、多频繁、影响多严重、目前他们怎么处理它。
+- 你的方案是否对应了真实问题？不是你最初设想的问题，而是验证过程里浮现出来的那个。有时两者相同，但并不总是。
+- 你有足够信号去开干吗？你在这个阶段永远不会有 100% 确定，等到完全确定本身就是失败模式。但你需要足够质性证据，让投入做 MVP 看起来是有理有据的决定，而不是一场信仰行动。
+
+想法阶段·挑战
+
+想法阶段是创业旅程里最重要的工作发生的地方，因为最具后果性的错误就在这里酿成。现在搞错一点，能很快把刚起步的事业带偏。多数想法阶段的挑战，归根到底都是前进速度超过了理解所能支撑的范围。所以，带着思考和审慎前行的创始人，才能稳步推进。
+
+**把「造」误当作「验证」**
+
+挑战：当技术障碍被移除，一个被激情冲昏头的创始人，可能会跳过创业旅程里最重要的工作：验证自己的想法是不是人们真正需要、也真正会用的方案。
+
+即使在 agentic 编程时代之前，也有 42% 的创业公司失败，是因为它们做了没人想要的东西。现在，像 Claude Code 这样的 agentic 编程方案，已经大幅压缩「我有一个想法」到「我有一个产品」之间的距离，这个失败率只会继续上升。
+
+现在确实是怀揣绝妙点子的创业者最好的时代，但**一个看起来像产品的原型竟然可以如此快速、轻松地搭出来，反直觉地，这恰恰给 AI-Native 创业公司带来真正危险的存在性风险。**
+
+直到不久前，造东西仍需要真金白银的开发时间和预算，连搭个最基本的原型通常都要数月。如今技术开发门槛基本消失，AI 让创始人太容易直接跳进建造，完全跳过验证它在真实世界里是否有用。
+
+要达到问题-方案匹配，必须先验证假设、再开始造。但许多首次创业者，甚至有经验的创业者，都错误地以为 AI 能让这一要求短路，把流程改成：有想法 → 立刻造原型 → 把「原型存在」当作验证。
+
+一个能跑的原型很容易被误当作「我在解决真实问题」的具体证据，但它不是。原型只是你和潜在用户对话时一个有用的压力测试道具。这些对话本身，才是真正证据。
+
+**过早规模化**
+
+挑战：当造东西既不费力又即时，你的执行速度可以远远超过业务真正需要的水平。
+
+过早规模化意味着：在还没有真正验证这条产品路径值得投入之前，你就已经把自己锁进去了。
+
+这一直是创业杀手，但 AI 让创始人更容易在毫无察觉时掉进这个陷阱。Agentic 编程助手太强大了，以至于执行很容易跑在问题-方案匹配验证之前，而你甚至没有意识到自己已经偏航。
+
+它会围绕一个根本错误的前提，带着同样的热情生成、测试、调试、重构代码库。系统里的智能是你的。这个阶段的最高指令是：让你的判断力始终走在建造之前，尤其是在建造如此快速、感觉如此轻松的时候。
+
+**客观性丧失**
+
+挑战：让 AI 工具去找支持你既有看法的证据，它一定能找到。**确认偏误如今配备了一台研究引擎。**
+
+确认偏误一直是创业里的职业病：创始人天然对自己的想法充满热情。现在，AI 工具给确认偏误加了很强的外挂。让 AI 验证你的创业想法，它能找出佐证；让它估算潜在市场，它能找到让 TAM 看起来值得融资的数字。
+
+AI 会沿着你的方向走。这意味着，一个不问难题的创始人，如今能比以往任何时候都更快地构建出一套精致、看似研究充分的坏点子论据，同时还觉得自己正在做尽调。解药还是同一个工具，只是把方向反过来：AI 同样能像验证想法那样彻底地压力测试它。当研究和结构化对抗性思考浮现证据、提示想法需要修正时，这就是 pivot 的信号。
+
+Claude 如何帮助想法阶段的创始人
+
+把你的 AI-Native 创业概念推进到走出想法阶段，可能感觉漫长无比。你是创始人，你只想动手造。但这个至关重要的启动阶段，本质上是一次研究和验证练习，意味着你应该先用那些帮助你想得更严谨的工具，而不是急着写代码。
+
+**Chat、Claude Cowork，还是 Claude Code：怎么选合适的 Claude 产品面**
+
+AI 让创业者能更快交付、自动化繁琐工作流，并在规模上运作起来。但你用哪一面，取决于手头任务。
+
+- Chat 适合无需离开当前 app 就能完成的快速交流：从密集投资人备忘录里提炼一句话总结、在董事会前快速核查一个论断、读懂团队里一条很长的 Slack 串。
+- Claude Cowork 适合真正需要时间的知识工作：从多个来源拉资料、整理并产出完成品，比如文档、deck 或电子表格。
+- Claude Code 是团队工程师的 agentic 编程环境：代码库访问、Plan Mode、git 集成、本地、IDE 或沙盒云环境。它是精益团队跨成长中的代码库交付功能、迁移 MVP 遗留代码、把原型推到生产的地方。
+
+三者底层是同一个 Claude；变的是它周围的工作空间。
+
+**定义并压力测试问题假设**
+
+你自己的领域专长和前期研究已经产生了一个假设。第一项工作是把它打磨到真正可被测试。Claude 在这里特别有用，它会强迫你具体：究竟谁有这个问题？多频繁？多严重？他们目前怎么处理？任何不能精确回答这些问题的问题陈述，都还没准备好被验证。
+
+练习：和 Claude 一起反复打磨你的问题陈述，直到它变成一个可被测试的假设。比如「合同审查耗时太长」没什么意义；但「中型公司的法务团队每个合同审查周期要花 3 天以上，因为修订意见散落在邮件串里，而不是一份带版本控制的文档」就非常可测试。
+
+下一步，请 Claude 反过来论证你的想法，找反证。这能浮现负面市场信号、失败竞品、客户行为模式、以及那些被支持性综述悄悄降权的结构性障碍。
+
+目标是：在进入客户发现之前，你已经拿最强的反方论据压力测试过自己的假设。这样，用户访谈才会真正开放，而不是一场寻找确认的行动。
+
+注：把 Claude 当作结构化的反方代言人来用，是 AI 创业生命周期每个阶段的核心用法。
+
+**市场研究与竞争格局图谱**
+
+给竞品大小定个位
+
+创业公司有一种特有现象叫「竞品忽视」：你太专注于自己的愿景和执行，以至于系统性低估同一空间里其他人在做什么。幸运的是，AI 提供了解药：让 Claude 为这个解决方案空间里的某个竞品写出最有说服力的论证，说明为什么它会成功而你不会。
+
+Claude 可以分析为什么对方的方法其实更好，为什么客户会选择它，为什么你以为的差异化可能没有那么守得住。
+
+练习：让 Claude 按层级绘制你的竞争格局：直接竞品、间接竞品、潜在收购方、以及可能进入你所在空间的相邻玩家。然后让它论证每一层为什么会对你的成功构成真实威胁，而不是只列出最容易被你驳倒的威胁版本。
+
+市场研究
+
+Claude Code 可以综合公开可得的客户反馈，浮现反复出现的抱怨和未满足需求。额外好处是，这几乎等于免费研究竞品客户。
+
+练习：指挥 Claude Cowork 汇总关键来源里的竞品评论，找出现有方案仍未解决的高频抱怨。如果你的假设能解决其中一个或多个，这是问题-方案匹配的强信号；如果不能，也值得知道。
+
+Claude Cowork 还可以从密集的行业报告、分析师文件和市场研究文档中提取相关信息和数字。接下来，这些干净、合成后的输入，会成为 Claude 分析工作的理想上下文。
+
+练习：基于公开数据构建 TAM/SAM/SOM 模型，并压力测试背后的假设。识别市场是在扩张、整合还是成熟；这个背景会影响你对时机和差异化的判断。再画出买方格局：谁掌握预算，谁影响决策，他们是不是同一个人。
+
+趋势分析
+
+最后，用 Claude 倾听早期指标，判断你是否在正确的时刻进入。追踪那些已经在讨论你的问题的 subreddit 和 LinkedIn 群组，记录用户描述问题时使用的原话。让 Claude 识别相似问题曾被解决过的类比市场，并提取哪些做法有效、哪些无效。浮现可能加速或威胁机会的监管、技术或人口趋势。
+
+练习：让 Claude 找出三个可能在未来两年显著影响你市场的外部趋势，监管、技术或人口均可，并判断它们分别是你特定假设的顺风还是逆风。
+
+注：本节里的市场研究与竞争图谱不是一次性练习。你会在 MVP 和发布阶段继续发现、继续演进思考，所以每当假设发生变化，都要重复这些练习。
+
+**规划并设计客户发现**
+
+你从潜在用户对话中学到什么，取决于两件事：你问的问题质量，以及你是否把这些问题问给了对的人。Claude 特别适合帮助你设计客户发现，包括找谁聊、问什么、以及如何理解听到的内容。
+
+找谁聊
+
+一个精确的目标画像，比一长串联系人更有价值。画像应包括最可能强烈经历这个问题的具体职位、公司类型、团队结构和资历层级。接着，识别这些人实际在哪里能被触达：社区、活动、LinkedIn 群组、Slack 工作区。最后建立一个优先级框架，根据他们离问题有多近，决定先触达谁。
+
+问什么
+
+目标人群定义好之后，用 Claude 搭建访谈框架：正确的问题、正确的顺序，结构要能浮现人们实际做了什么，而不是他们以为自己会做什么。**新手创始人常犯的错误，是问一个泛泛的未来式开放问题，比如「你会用这样的东西吗？」而不是追问相关的过去，比如「跟我讲讲你上一次处理这个问题的过程」。**
+
+Claude 也能指出你的草稿问题哪里在诱导受访者、哪里太宽泛、哪里会产生噪音而不是信号。它还可以帮你设计追问，用来处理回避回答，或深入挖掘那些重要但含糊的答案。
+
+如果你的假设涉及多个 persona，Claude 也能为每类人设计不同问题组。财务经理和 CFO 面对同一个问题的关系并不一样，单一访谈框架会把这种差异抹平。
+
+练习：先手写访谈问题，再让 Claude 审查。明确要求它标出任何诱导性、面向未来、过宽、或容易产生社会期许答案而非真实答案的问题。然后让它为访谈中最可能出现回避的两三个时刻设计追问。
+
+访谈后分析
+
+每次对话后，用 Claude 复盘：把笔记喂给它，让它指出什么确认了你的假设、什么挑战了它、什么是真正意外的。
+
+收集一批访谈后，把完整访谈笔记交给 Claude Cowork，让它浮现反复出现的主题、矛盾、以及正反两个方向最强的信号。再把合成结果带回 Claude，让它指出：你对数据的解读，哪里可能是在把信息匹配成你想听到的样子，而不是数据真正呈现的样子。
+
+练习：每完成五次访谈，就让 Claude Cowork 综合笔记并产出两张清单：支持你假设的证据，以及挑战你假设的证据。如果第一张清单明显更长，让 Claude 判断这种不对称是数据本身如此，还是你原本就希望找到这些东西。
+
+客户触达与排期
+
+用 Claude Cowork 自动化建立联系人列表、跑触达、安排用户访谈这些运营负担。
+
+Claude Cowork 可以使用你和 Claude 定义的目标画像，包括职位、公司类型、资历层级，研究并整理结构化的潜在客户名单和已验证联系方式。随后，它可以批量起草个性化触达邮件，让每封邮件贴合对方的角色和处境。
+
+当回复进来后，它通过 MCP 连接 Gmail 和 Google Calendar，管理邮件串、处理排期请求、把访谈放到日历上。流程还会继续：Claude Cowork 按设定节奏生成跟进草稿，比如第七天跟进未回复联系人，并在每一步完成时更新追踪表，让你始终知道每个潜在对象在管道里的状态。
+
+练习：把验证后的访谈目标画像交给 Claude Cowork，请它建立潜在客户列表、起草个性化触达序列，并建立一张追踪表，包含触达状态、跟进节奏和访谈完成情况。然后让它负责协调，你专注准备对话本身。
+
+**设计你的最终方案概念**
+
+你已经完成验证工作：问题真实存在，你知道谁有这个问题，也有一个被证据支持的方案概念。用 Claude 从各个角度发展并挑战你的方案概念：缺口在哪里？有哪些替代方案？这个方案要想规模化成立，必须满足哪些条件？这是一个重要的现实检查：这个设计是否真的对应验证过程揭示的问题，而不是你一开始以为的问题？
+
+练习：把你的方案概念交给 Claude，让它识别这个设计最依赖的三个假设。然后追问：每个假设要成立，必须有哪些条件？如果任何一个假设不成立，后果是什么？
+
+**用 Claude Code 搭一个轻量原型**
+
+现在到好玩的部分了：有了被验证的假设和经过压力测试的方案概念，你终于准备好做点东西了。
+
+这就是想法阶段里 Claude Code 登场的时刻。即使你之前一直在小修小补，现在才是生成正式轻量原型的节点：只做最小的产品表面，让你能把想法放到真实的人面前，获得真实反应。
+
+**你还不是在造一个真实世界产品，而是在构建一份功能样本，用于客户和投资人对话。** 真实用户触碰一个能实际操作的东西，会告诉你十几次问题-方案访谈都无法告诉你的事。此前你是在证明要解决的问题真实存在；现在，你是在邀请潜在用户参与拟议的解决方案。
+
+练习：定义你的方案所依赖的单一核心交互。指挥 Claude Code 只做这一件事。做好后，把它放到五个来自已验证目标画像的人面前，请他们试用。你在这五次对话里学到的东西，将决定你是继续建造，还是回到画板。
+
+走到想法阶段的尽头，是 AI 创业赛跑里的一大跃迁。因为你不再是在赌一个直觉，你是在对着证据执行。
+
+接下来进入 MVP 阶段。创始人的指导问题从「这值不值得做？」转向「到底先造什么？」而 AI 的主要角色，也从研究伙伴切换为施工队。
+
+———
+
+## 第四章 MVP 阶段
+
+很多创始人把 MVP 阶段当作一个施工阶段，但 **MVP 阶段本质上仍是一次证据收集练习**。区别在于，这次你收集的是关于解决方案空间的证据，而不再是问题空间：一个真实、可识别的人群是否觉得这个产品有价值到愿意使用、回来再用、付费，或者推荐给别人。
+
+MVP 阶段·目标
+
+作为一家 AI-Native 创业公司的创始人，你的目标是把验证过的问题，翻译成一个真实用户会用的可工作产品。它不是带齐每个路线图功能的完整版本，而是你的想法最小、最聚焦的一次迭代：把真实方案摆到真实用户面前，并产生 PMF 的真实证据。
+
+与此同时，你现在怎么造，决定了之后能造什么。这意味着 MVP 阶段还有第二个同样重要的目标：快速前进，但不积累那种会复利、会在真实用户达到一定规模时回来缠住你的技术债。
+
+最后，从第一天起就投资持久上下文，是让 AI 成为放大器而不是熵源头的关键。在 AI-Native 创业公司里，你的代码库是你和 AI 一次次会话共同协作的对象，这让可读性成为根基。**跳过 spec、架构决策和** [CLAUDE.md](http://claude.md/) **这类上下文文件的创始人，会撞上一堵可预见的墙：每次新会话都要重新解释代码库，AI 生成的改动也会从最初愿景里漂移。**
+
+MVP 阶段·退出标准
+
+MVP 阶段的退出条件，是出现 PMF 的真实证据：一个具体、可识别的用户群体，发现产品有价值到愿意回头用（留存）、付费（收入），或告诉别人（推荐）。
+
+MVP 阶段·挑战
+
+在 MVP 阶段，创始人的首要指令是速度与判断力。这里的挑战核心是：你能不能用正确方式造正确东西、快到足够有意义，同时不抄那些以后会让你付代价的近路。
+
+**Agentic 技术债**
+
+挑战：因为 AI 基本移除了过去那些控制什么能进生产的天然瓶颈，速度是被保证的。但当速度成为创始人在 MVP 阶段唯一考虑的变量时，他们会积累自己很难还清的技术债。
+
+一些技术债在 MVP 阶段是合理的，前提是你明白在规模化之前必须管理它。这种债逐步累积，可以在时间里或专门冲刺中清掉。但 **AI 技术债会复利。**
+
+如果没有把规格和架构约束写在某个 AI 能读到的地方，每次会话都会从零开始重新推导基础决策，于是这些决策会漂移。你最后会得到一个没有一致心智模型的代码库，不是因为任何一块写得糟，而是因为这些零件从未被设计成能拼到一起。这是真问题，而且往往很晚才显形。
+
+**误把虚假 PMF 当作真 PMF**
+
+挑战：AI 工具可以生成亮眼的早期数字，但这些数字并不保证市场需要你的产品。
+
+早期势头是创始人能经历的最强心理体验之一。经历数周或数月验证和克制建造之后，把产品发出去，会让人觉得自己从一开始就是对的。
+
+Agentic 编程工具可以让你比以往更快抵达这个时刻，但**早期牵引不等于 PMF**。发布热度可能来自短暂因素：创始人的朋友、投资人其他被投公司的潜在买家，或 Hacker News 一个标题带来的流量尖峰。可惜，这些都不能可靠预测第六周或第十二周，在最初助推消退后会发生什么。
+
+**零摩擦的范围蔓延**
+
+挑战：当建造感觉不费力、几乎免费，总会有一个很酷的功能可以加，或一个边缘情况可以处理。这种范围蔓延弊大于利。
+
+范围蔓延一直是创业风险。现在的区别是，过去阻止它的强制函数，即工程时间的真实成本，已经不再以同样方式存在。加一个功能从一个冲刺变成一个下午。
+
+难点在于，每一个单独新增都显得合理。产品当然应该处理那个边缘情况，用户当然会想要那个工作流。由于 agentic 编程让每一项都很省力，它们在当下并不像范围蔓延。但当产品越过原始边界开始摊大饼，你就会失去方向和动量。
+
+解药是在建造前写下范围定义：产品做什么、明确不做什么、以及来自真实用户的哪种具体证据才足以证明应该加新东西。这样，决策点就从「要不要做这个？」变成「是否已有足够多用户告诉我们：没有它，他们无法从产品获得价值？」
+
+**因经验不足而不安全**
+
+挑战：创始人用 AI 工具匆忙把应用推向市场，却没有先理解基本安全原则，最终会让用户暴露在可避免的风险中。
+
+硬道理是：**agentic 编程工具生成的是能运行的代码，而不是天然安全的代码。** 功能代码很容易判断，因为功能要么能跑，要么不能。安全漏洞在被利用之前是隐形的，这意味着没有天然反馈环来提醒首次创业者：哪里出了问题。但把一个 live MVP 交给真实用户，就意味着真实数据、真实暴露和真实后果。
+
+轻视安全并不是 AI-Native 项目才有的新问题。每个时代的自筹资金创业公司都常常把安全考虑拖到很晚，有时甚至拖到生产发布前夕。任何用户触碰你的 app 或方案之前，做一次安全审查，是把最小可行产品发布到世界上所需的最低责任门槛。
+
+Claude 如何帮助 MVP 阶段创始人
+
+**造之前先定架构**
+
+在 Claude Code 写下第一行生产代码之前，用 Claude 定义并记录本阶段所有建造都要遵守的架构决策：遵循哪些模式，避开哪些依赖，做了哪些取舍以及为什么。这份输出会成为聚焦的架构上下文文档，并建立 Claude Code 要在其中运行的护栏。
+
+没有这份上下文，每次会话都从零开始，Claude Code 被迫推断自己的结构性假设。让 Claude Code 没有护栏地建造，会产出功能可用但结构不一致的代码库。迭代和扩张这种代码库，最终是在浪费时间和 token。迟早会到一个点，代码不可避免地坍塌，迫使你从头重建。
+
+练习：打开 Claude Code 之前，先打开 Claude 并描述你要做什么：它解决的核心问题、服务的用户、以及未来六个月现实预期的规模。让它帮你定义 MVP 构建应遵守的架构原则、在约束下应避免的依赖、以及这个阶段有意识接受的取舍。
+
+接着，把这份输出保存为 [CLAUDE.md](http://claude.md/) Markdown 文件。这就是你的架构上下文文档：构建过程的第一个产物，也是后续每次会话依赖的东西。[CLAUDE.md](http://claude.md/) 文件是 Claude Code 的项目级指令，为特定代码库提供上下文和说明，并会在 Agent SDK 在目录中运行时被自动读取。功能上，它就是项目的持久记忆。
+
+**定义并执行 MVP 范围**
+
+没有摩擦的范围蔓延，是 AI 时代 MVP 的典型失败模式之一。就像你定义并记录产品应用架构一样，在任何功能被建造之前，也要先定义 MVP 范围。
+
+Claude 可以帮你创建范围文档，描述 MVP 产品做什么、明确不做什么，以及功能修订标准：此时来自真实用户的哪种具体证据，才足以证明应该加新东西。
+
+当新的功能想法出现时，它们一定会出现，你要用 Claude 压力测试：这是用户真实信号，还是披着产品思考外衣的创始人热情。
+
+**用 Claude Code 造 MVP**
+
+架构和范围定义好后，Claude Code 就成为主要的 MVP 构建工具。用它生成、测试、调试、迭代代码库，但要把每次会话当作执行你已经做出的产品决策，而不是趁机塞进新想法。
+
+每次 Claude Code 会话开始时，先重新查看范围文档，并给模型提供 [CLAUDE.md](http://claude.md/) 架构上下文文档。每次会话结束时，把会话中浮现的决策更新进去。**目标是一个你能解释其结构的代码库，而不只是一个能跑的代码库。**
+
+练习：为 Claude Code 工作创建一个简单会话模板，包括架构上下文文档、本次具体任务、以及需要遵守的约束或模式。每次会话结束时，在上下文文档里加一条简短日志，说明构建了什么、做了哪些决策、引入了哪些假设。每次五分钟的文档记录，是防止架构漂移复利成不可管理代码库的便宜保险。
+
+**任何用户上手之前先做安全审查**
+
+作为 AI-Native 创业公司创始人，你有责任知道代码库里有什么，理解潜在暴露路径，并且不要把明显漏洞交付给信任你处理其数据的真实用户。
+
+Claude 可以对 AI 生成代码做有用的第一轮安全审查，帮助识别常见漏洞。这是发布前值得放进循环里的好习惯。但它不能替代安全工具，在风险更高时也不能替代人类审查。把它当替代品的创始人，最后往往会出现在事故故事里。
+
+Claude Code Security 更进一步：它会扫描代码库里的安全漏洞，并为人类审查建议定向补丁，浮现传统方法可能漏掉的问题。
+
+注：截至本电子书出版时，Claude Code Security 仍是有限 beta 版本。把它加入工作流之前，请确认当前可用状态。
+
+练习：部署给任何真实用户之前，用一个明确 brief 把核心应用代码交给 Claude 审查：认证和会话处理、API 响应中的数据暴露、输入校验和注入风险、以及存在已知漏洞的依赖。认真对待每个发现，并判断是否需要修复；凡是涉及认证、密钥或数据处理的发现，都要有人类审查。
+
+**发布前建好度量框架**
+
+那些把早期牵引误判成 PMF 的创始人，通常也是发布后才开始追踪数据的人，而且选的指标往往是为了评估什么有效，而不是浮现什么无效。**解药是在第一个用户出现之前，就建立你的度量框架。**
+
+用 Claude 定义你的具体产品应该看哪些指标、基准是什么、数据中哪些模式构成真正 PMF、哪些只是好看的噪音。具体来说，在发布 MVP 前设定留存基准、激活标准、以及第 7 日和第 30 日目标。
+
+接着，定义对你的具体产品而言什么是假阳性：有注册但无激活、有收入但无留存、初始热情但没有重复使用等。当数据到来时，让 Claude 替怀疑者说话：一个怀疑者会如何解读这些数字？
+
+**管理发现和用户反馈的运营层**
+
+一旦真实用户进入产品，运营层会迅速膨胀。Claude Cowork 可以处理重要但繁琐的工作：建立和维护用户联系人列表、跑触达序列、安排反馈会、分诊 bug 报告、追踪迭代周期。想法阶段管理发现后勤的 MCP 集成，在这里同样适用。
+
+对细腻的用户反馈探索，要保留人在收集循环里。用户说「这很好，但我希望它还能……」时，需要解释：这是核心需求还是锦上添花？是这个客户特有，还是代表某一细分人群？缺失功能才是真问题，还是新用户引导上游出了问题？没有工具能替你回答这些问题。
+
+练习：配置 Claude Cowork 跑你的 MVP 阶段反馈环：给早期用户列表起草触达、安排反馈会、设计 bug 和功能请求的结构化收集流程、每周写一份综合摘要。你先自己审阅摘要；之后再让 Claude 分析信息，捕捉你可能漏掉的重要点。
+
+**朝证据迭代，而不是朝完整迭代**
+
+MVP 阶段结束于你拥有 PMF 的真实证据，而不是产品看起来有多「完整」。宣布已经达到 PMF、准备从 MVP 阶段进入发布阶段，最终是一项判断练习，需要结合创始人直觉和收集到的证据。不过，有一些有用的试金石：
+
+- Sean Ellis 测试：问你的活跃用户：「如果再也不能用这个产品，你会感觉如何？」如果超过 40% 的人回答「非常失望」，这是一个有意义的 PMF 指标。
+- 努力测试：PMF 之前，留存需要持续干预：频繁触达、激励、个人跟进，以及创始人那种英雄式能量来维持用户参与。PMF 之后，产品开始自己承担这项工作。**当事情开始「拉」而不是「推」时，这种努力变化是真东西发生的最清晰信号之一。**
+
+最终，没有任何单一数据点能确认 PMF，因为它必须在多个迭代周期里持续成立，才能被明确命名。
+
+**数据要求 pivot 时，就要 pivot**
+
+如果投入这么多工作后，仍然无法抵达 PMF 怎么办？结果没有确认你一开始的方向，并不是失败，而是系统在正常工作：MVP 阶段的设计目的，就是在你对错误答案过度投入之前浮现这些信息。
+
+当数据不支持当前产品时，用 Claude 梳理这些数据到底在告诉你什么。
+
+- 探索替代客户细分。也许那些没有转化的用户，从一开始就不是正确目标。很多时候，正确受众已经在你的数据里，只是权重被低估了。
+- 调整产品价值主张。也许受众是对的，但 MVP 没有和用户产生共鸣。调整新用户引导、信息表达或核心功能强调，可能无需改变已构建的东西就能修正问题。
+
+保持开放：设计价值和体验价值之间的脱节，可能深到需要一次更根本的改变。
+
+练习：如果你已经完成三轮或更多迭代周期，仍未看到朝 PMF 基准的实质推进，让 Claude 在决定下一步之前先跑一次诊断。把留存数据、用户反馈和最初的问题假设都喂给它，问三个问题：
+
+- 数据里是否存在某一段用户响应方式与其他人不同？
+- 设计价值与体验价值之间的差距，是定位问题还是产品问题？
+- 当前产品要找到真实 PMF，需要哪些条件？以你观察到的现象来看，那个情境现实吗？
+
+让答案决定你是调整、pivot，还是退回想法阶段。
+
+———
+
+## 第五章 发布阶段
+
+**如果说 MVP 阶段是要证明你的产品值得存在，那么发布阶段就是要证明你的生意值得长大。**
+
+发布阶段·目标
+
+在发布阶段，创业者必须把早期势头转化为一台可重复、可持续的增长引擎。除了让产品具备生产就绪状态，你还必须同时加固产品底下的基础设施，也就是说，要围绕产品真正建出一家公司。
+
+创业公司在想法和 MVP 阶段天然是创始人中心化的，因为你需要完整的处境感知和紧密反馈环。但现在，那些仍试图把每一根线都自己握在手里的创始人，会变成发布阶段的瓶颈。目标不是把自己从公司里拿掉，而是搭建运营系统，把注意力释放出来，去做那些只有创始人能做的决定。
+
+发布阶段·退出标准
+
+发布阶段的退出条件包含三个要素：
+
+- 增长是可重复的、由渠道驱动的。你不是仅仅在留住用户，而是通过明确渠道、有可被理解的单位经济模型，可预测地获取用户。CAC、LTV、回收周期，这些都是你知道且能 defend 的数字。
+- 产品能扛住生产工作负载。基础设施已加固，安全与合规到位，可靠性在真实生产条件下也站得住，而不只是在你测试过的条件下。
+- 运营在没有创始人瓶颈的情况下也能跑。流程已就位，自动化已部署。你不再是亲自处理客服、分诊、冲刺规划或报表的人。
+
+发布阶段·挑战
+
+找到 PMF 是早期创业生命周期里最难的问题。现在，创始人的挑战变成了保住它。发布阶段是这样一种地方：那些已经找到真实产品牵引的公司，仍可能在包围和支撑产品的组织跟不上时散掉。
+
+**技术债到期**
+
+挑战：那个为速度和验证而建的 MVP 代码库勉强够证明产品能跑，但生产流量、新功能和增长中的复杂度，现在正把当初的捷径暴露出来。
+
+在 MVP 时，积累一些技术债是合理的速度换取。在发布阶段，那笔债开始算利息，拖得越久，修起来越贵。
+
+解决方案是一套系统的架构审查：找出结构性弱点，对最严重的问题做定向重构，并有意义地扩展测试覆盖率，确保下一轮功能开发不会重新引入同样的问题。
+
+**创始人成为瓶颈**
+
+挑战：MVP 阶段，创始人在每个循环里是一种资产。发布阶段，随着支持量增长、产品决策堆积、运营复杂度倍增，同样的本能会变成约束。
+
+从亲自做事，到设计能把事情做完的系统，是创业生命周期里最难的转变之一。因为很少有一个清晰时刻宣告它已经发生，风险就在于你完全错过它，继续停留在建造者模式，而组织在你周围停滞。明显信号包括：本该一小时完成的决策，因为等你处理变成一周；支持请求越堆越多，因为只有你知道答案；运营任务只有在你亲自想起来时才发生。
+
+补救办法是彻底审计你亲自处理的一切，从最小任务到最关键决策，识别什么能系统化，什么能委派，什么真正仍值得创始人投入时间和注意力。
+
+**安全与合规不再能往后拖**
+
+挑战：MVP 阶段，保持安全与合规措施简单还可以。但现在，有真实用户、真实数据，甚至可能有企业合同在桌上，它会变成负债。
+
+MVP 阶段，只有少量 beta 用户、生产环境里没有敏感数据时，安全漏洞还是理论风险。但产品一旦进入生产、有真实用户依赖它，假设就会变成非常现实的暴露风险。更进一步，那些不适用于原型的合规要求，会在你处理客户数据、处理支付或销售给受监管行业的那一刻明确适用。
+
+补救办法是在生产规模到来之前，而不是之后，做系统的安全与合规审查。凡是浮现出来的问题，都要当成下一波用户到来前必须修复的事项，而不是建议。
+
+**还没准备好就扩张**
+
+挑战：新市场和融资机会看起来像增长机会。它们也可能是 PMF 死掉的地方。
+
+你建立的初始牵引是真实的，但它也具体绑定在早期受众上。过早扩张到一个与原市场显著不同的市场，会引入新的用户行为、合规要求、支付基础设施和基线预期，而你的产品并不是围绕这些设计的。突然之间，变量太多，你失去了清晰解释自己数据的能力。你还可能一边追逐新的、未经验证的受众，一边忽视原始用户群。
+
+Claude 如何帮助发布阶段创始人
+
+发布阶段会完整用到 Claude 的三种形式，而且它们相互支持：每个工具的输出都会变成另外两个工具的输入。结果会自然复利，一个同时使用三者的创始人，得到的不只是各部分相加。
+
+**这正是超精益创业模型在结构上可行的原因。当 Claude Code 构建产品，Claude Cowork 构建产品周围的公司，Claude 帮助把产品和组织知识运营化，一个小团队就能像大得多的公司一样运行。 在技术债复利之前清算**
+
+你的 MVP 代码库能跑，但它也需要一次系统的修复扫描，找出任何可能变成结构性负债的技术债。
+
+首先，用 Claude Code 跑一次完整架构审查：识别代码库哪里脆弱，哪些捷径会变得维护昂贵，测试覆盖哪里薄到下一轮功能开发会重新引入同样问题。
+
+把 Claude Code 的审查发现喂回 Claude，让它分诊并排序修复工作：什么必须在下一次发布前修，什么可以等一个冲刺，什么在当前阶段属于可接受的持续债务。这也是把 MVP 阶段那些只存在你脑子里的架构决策写下来的时刻。把它们放进 [CLAUDE.md](http://claude.md/)，能确保未来每次 Claude Code 会话都从共享理解开始。
+
+练习：指挥 Claude Code 审查 MVP 代码库，产出结构性弱点、测试覆盖缺口和重构候选项的优先级列表。然后把清单交给 Claude，让它把修复工作排进几个冲刺：哪些重大问题要先处理，哪些可以和功能开发并行，哪些可以等待。
+
+**搭起那些替换创始人注意力的系统**
+
+要搭建能释放你注意力的运营系统，去处理只有创始人能承担的责任，第一步是准确知道你的注意力花在哪里。用 Claude Cowork 结构化审计当前运营负荷，记录每个重复任务、每个落到你桌上的决策、每个只因为你亲自记得才会发生的工作流。然后让 Claude Cowork 把清单分成三类：能完全自动化的，需要人但不一定需要你的，以及确实需要创始人判断的。
+
+审计完成后，用 Claude Cowork 设计自动化候选项的工作流逻辑：每个工作流由什么触发、决策规则是什么、输出长什么样、完成后流向哪里。
+
+**把安全与合规做成产品工作流**
+
+用 Claude Code 浮现代码层面的问题，这些问题常出现在 SOC 2、GDPR、HIPAA 审计以及目标市场要求的标准中。它会同时浮现漏洞和合规缺口。把发现交给 Claude，帮助你排列修复优先级，并设计企业买家签约前会要求的控制、审计日志和访问管理。
+
+注：AI 扫描是一种辅助，不能替代有资质的合规审查。
+
+接下来，把合规工作流纳入开发周期，而不是把它当一次性项目。合规文档需要持续维护和更新。对正在接近企业合同或国际市场的创始人来说，这也是 Claude Code 安全扫描帮助你准备独立安全评估的时刻。
+
+练习：用 Claude Code 跑一次代码级安全审查，方向对准目标市场所需框架。把输出喂给 Claude，请它产出两样东西：优先级排序的安全修复序列，以及为了通过潜在企业买家的合规审查，你需要产出的文档和控制清单。
+
+**把一直跳过的产品管理流程立起来**
+
+发布阶段需要一套轻量、可重复的流程，不需要创始人介入触发或维持也能运行。用 Claude 设计产品时间线和工作周期如何组织，一份 spec 在 Claude Code 触碰功能前必须包含什么，bug 报告如何分诊和路由，每周指标简报覆盖什么、如何分发。
+
+流程设计完成后，用 Claude Cowork 搭建并运行运营层：安排冲刺仪式、把新进 bug 报告路由到正确位置、从连接的数据源汇总每周指标、维护让用户信号持续流入产品决策的反馈环。
+
+练习：请 Claude 设计一套轻量产品管理操作系统：明确的冲刺节奏、最低规格文档模板、bug 分诊决策树，以及从真实数据源拉取的每周指标简报。然后设置 Claude Cowork 执行并运行系统里的重复运营元素，例如排期、路由和报告汇总，让它们按计划发生，而不需要你。
+
+———
+
+## 第六章 规模化阶段
+
+在规模化阶段，创始人的角色重新校准，从建造者转向面对公众的高管。产品仍是核心，但你的日常工作越来越多地落到公司本身上。你必须把注意力扩展到新的规模化阶段活动，例如分析师沟通会和 IPO 路演，同时尽量保住那份精益、AI 为中心的结构性优势。
+
+规模化阶段·目标
+
+扩张技术基础设施的工作不会停止，现在又加入了扩张组织本身、把它催熟为一门生意的工作。
+
+到了规模化阶段，你要从数千用户走向数百万，从一个市场走向多个市场。在之前每个阶段，增长都是你能摸着走的事：靠贴近用户、靠紧密反馈环的数据，再加上一点健康的创始人直觉来调整方向。现在，目标是搭建由成熟组织运营支撑的系统化增长。
+
+**对一家 AI-Native 创业公司，你的目标应该是通过累积深度，建出防御性护城河。** 这来自你已经构建进产品里的专业知识、产品与用户依赖的其他工具和平台之间的深度整合、以及专有系统数据和工作流。那些一直在同一方向、同一基础设施上持续构建的创始人，现在手里有了真正难以复制的东西。
+
+到了这个阶段，公开市场投资人、分析师、监管者、企业采购团队和收购方都会施加更大压力，也带来更大怀疑，因为赌注更高了。你的产品和组织必须经得起外部审视：不只是已经造出来的能力，还有围绕它的治理、合规姿态、财务控制和战略叙事。
+
+规模化阶段·退出标准
+
+规模化阶段的退出条件不再是单一里程碑，而是一个阈值事件：哪怕创始人越来越少直接跑日常运营，公司也已经可持续。你已经展示了系统化增长；建好能满足最苛刻外部审查者的组织治理和合规基础设施；并且能扎实回答这个问题：「如果一个资金充足的现任者今天复制了你的产品，你的用户会留下来吗？」
+
+实践中，这个阈值通常会以三种形式之一出现：达到不再需要外部资本的规模化可持续盈利、IPO 就绪、或被收购。三者都要求你的增长系统化且可审计，产品护城河经得起审视，组织在运营上成熟且可持续。
+
+当这些都成立时，恭喜你：你的创业公司已经从一场赌注，变成了一门生意。
+
+规模化阶段·挑战
+
+**把运营层放手出去**
+
+挑战：规模化阶段的运营系统必须可靠、可持续地运行，不能靠人盯着。对一个从第一天起就亲力亲为的创始人来说，这种转变既是结构挑战，也是心理挑战。
+
+**发布阶段的工作是创建系统；规模化阶段的工作则是让这些系统成熟到完全可信，然后真的信任它们。**
+
+这比听起来更难。即使你是一个擅长授权的创始人，也不总是清楚什么该交出去，什么该留在自己手里。交得太多、太快，尤其交给 AI 自动化系统，关键决策可能会在缺少创始人独有上下文的情况下发生。但抓得太久，你又会变成瓶颈。
+
+这里的根本挑战，是识别那些只存在于创始人脑子里或未文档化工作流中的机构知识，并把它编码进有文档、可审计、可交接的系统里。
+
+**扩张技术运营**
+
+挑战：客户不再只评估你的产品；他们还想知道你的组织能不能成为可靠的基础设施伙伴。
+
+创业前三个阶段的技术挑战围绕代码库：构建正确方案而不积累技术债，然后为真实用户加固安全和合规。进入规模化阶段后，挑战变成围绕代码库的一切：创建支持基础设施、文档和可靠性保证，来传递成熟信号。
+
+签多年合同的大客户和机构买家，在签约前会要求这些东西，签约后也会按这些要求约束你。不过，带你走到这里的同一套 AI 基础设施，也能帮助你建立专门支持职能：明确响应时间、提供新客户工程团队真正能用的文档。
+
+**扩张组织职能**
+
+挑战：规模化阶段的公司通常需要招聘、工资、会计和法律运营等组织基础设施，不管实际跑公司的人有多少。
+
+发布阶段，系统化运营意味着自动化那些消耗创始人注意力的工作流。规模化阶段的创业公司现在需要扩展更广、某些方面也更关键的一组运营职能，例如财务报告、合规监控、合同管理和客户支持。
+
+**搭一个 GTM 职能**
+
+挑战：自然增长有天花板，而多数规模化阶段创始人在真正搭过 GTM 职能之前，就会撞上它。
+
+想法、MVP 和发布阶段的增长，往往来自创始人亲自卖：从一个恰到好处的 Product Hunt 帖子，到与早期客户的私人关系。这样的自然增长只能走到某个点，大多数创业公司会在规模化阶段撞到这个上限。信号包括用户曲线变平、获客成本上升、以及只有创始人亲自介入时管道才会推进。
+
+规模化阶段的增长，需要搭建一个专门增长引擎，让产品触达新的、更广的人群。但多数创业公司创始人，可能从来没有真正运行过市场、销售、分析师关系这类项目。一个像样的 GTM motion 不只是建立新系统和流程，还要创造品牌声音和产品故事，说明你想如何谈论自己的产品。因为在生命周期的这个阶段，你需要触达的不只是一个个新用户，还包括投资人、企业买家等完整目标受众。
+
+好消息是，GTM 职能不必很大也可以有效。构建产品的同一套 AI 基础设施，也可以引导产品走向市场。
+
+Claude 如何帮助规模化阶段创始人
+
+早期阶段，Claude 是产品本身的基础设施：验证想法的研究伙伴、设计并构建原型的工程团队、以及让单人创业公司可行的 AI 运营层。走到规模化阶段的 AI-Native 创始人，现在可以继续用 Claude、Claude Code 和 Claude Cowork，以同样方式扩张。
+
+**把日常任务交给 Claude Cowork**
+
+以一个清醒视角开始规模化阶段：你现在最需要把时间和注意力投在哪里？对第一次创业、从未真正搭过一门生意的创始人来说，这会很难。Claude 可以帮你列出这个阶段只有你该做的事，例如产品叙事决策、董事会关系、企业大单、创始人与创始人的对话。任何不在清单上的事，都是委派或 Claude Cowork 自动化的候选项。
+
+练习：用 Claude 绘制当前运营层的瓶颈地图：所有目前经过你的工作流、决策和审批。然后让 Claude 推演：如果你一周不可用，每一项会发生什么？会停下来的工作流，就是你仍亲手握得足以阻碍进展的地方。
+
+这些与 Claude 帮你列出的创始人优先事项和责任清单如何对应？
+
+接下来，压力测试你已经建好的系统是否真的能随业务增长而扩张。
+
+练习：用 Claude 绘制当前工作流，并询问如果你一周不可用，每一项会发生什么。会停滞的工作流，说明交接标准、升级路径或异常处理仍需收紧。Claude 可以分析失败点并建议修复，让你按需更新或替换 Claude Cowork 自动化。
+
+**把技术运营升级为企业级基础设施**
+
+扩张时，买家需要确信你的产品和组织可以被当作长期基础设施信任。代码库内部的技术工作照常继续，但现在代码库周围的技术工作也必须处理。
+
+第一步是把机构知识转换成能扩张的系统。用 Claude 起草并维护企业采购预期会看到的书面基础设施，包括产品文档、支持 playbook 和 SLA。
+
+同时，指挥 Claude Code 针对企业合同要求的具体可靠性和安全标准审查并加固代码库，并构建出 Discord 社区支持从未需要提供的技术支持基础设施：日志、监控、事故响应工具，以及让 SLA 真正可执行的可观测性层。
+
+随后，Claude Cowork 运行企业支持本身的运营层：工单路由、升级工作流、由产品变化触发的文档更新、续约追踪，以及企业客户成功依赖的报告节奏。三者合起来，让小团队拥有大组织的支持姿态，而这正是签多年企业合同前你必须证明的东西。
+
+练习：挑出最苛刻的三个潜在客户，或识别你最想签下的三个理想客户。让 Claude 做差距分析：这些账户的企业采购团队在签多年合同前，会期待看到哪些文档、SLA 和支持基础设施？你目前哪里不足？用输出安排 Claude Code 和 Claude Cowork 的技术与文档工作。
+
+**搭一个真正的 GTM 职能**
+
+创始人的 hustle 把你带到了这里，但要扩张公司，你需要创建并执行真正的 GTM 策略。AI 可以帮你构建，然后运行完整的 GTM 引擎。
+
+Claude 可以从零搭建基础 GTM 资源：市场细分、信息架构、分析师关系策略、销售 playbook，以及当你开始面对公开市场投资人、企业买家和华尔街分析师时重要的投资人指标叙事。每类受众都有自己的词汇，并用自己的标准评估你；Claude 的工作，是把产品价值主张翻译成每个受众都相关的产品营销方法。
+
+现在，Claude Cowork 可以成为你的战术执行层：内容管线、外呼序列、分析师沟通会后勤、新闻和 PR 节奏、CRM 卫生、销售管道报告，以及把 GTM 策略变成真实商业动作的许多重复周期。
+
+当 GTM motion 需要产品营销基础设施，例如交互式演示环境、集成文档、沙盒租户、API 参考、技术 one-pager，Claude Code 可以为你构建。买家期待从技术上评估你的产品。在规模化阶段，一段 Loom 视频和一份销售 deck 已经不够。这也是让 GTM motion 异步运行的基础设施：一个做得好的 demo 环境，可以在你开董事会时帮你成交。
+
+**把领域专长和机构知识转入 AI 上下文**
+
+许多超精益创业创始人，正在为某个他们亲身经历或观察到的特定行业真实问题，构建高度具体的 app 或工具。Agentic AI 让从未写过一行代码的创始人，也能用自己的领域专长做出解决复杂问题的产品。Claude、Claude Code 和 Claude Cowork 各自参与，把创始人知识转换成会复利的产品具体性。
+
+用 Claude 捕捉、组织并细化创始人知识，就是把领域专长放到产品能够触达的地方。通过长对话、Projects 和记忆，创始人可以把自己知道的一切：行业黑话、监管坑、边缘情况、挫败点、为什么显而易见的答案并不管用，放进结构化、可搜索的上下文。**Skills 可以把重复工作流编码成可复用例程**，例如「我如何审查商业租约」「我如何分诊患者入院表」，让 Claude 每次都用同样方式运行。几个月后，这会变成一种专有知识基底，通用 AI 无法匹配。
+
+把领域知识外部化到 Claude 中，对把行业特定边缘情况编码进产品极有价值。例如，一个通用医疗计费工具可能会在 340B 药品项目索赔上出错，而你的工具有专门逻辑。Claude Code 帮你把同行业其他专业人士常遇到的挫败，转译成验证逻辑、prompt 优化，或与竞争对手从未听过的小众行业系统的 MCP 集成。结果是，你的 app 或工具在深度和广度上都持续复利，竞争对手无法简单复制。
+
+练习：找出一个通用竞品在你的垂直领域一定会做错的边缘情况。和 Claude Code 一起基于你真实见过的场景，为它构建一个专门测试用例，不是单元测试。每当相似边缘情况出现，就把它加进去。**你的测试套件会变成护城河地图。 让积累的用户数据复利成防御性优势**
+
+用户与产品互动时，会生成行为信号，例如他们接受哪些输出、拒绝哪些输出，这会反过来影响产品路线图。随着时间推移，你会学到特定用户群的具体模式、偏好和边缘情况。这就是复利价值：每次改进让产品更有用，带来更多使用，创造更多反馈，再推动更多改进。
+
+这些数据有时间锁定、具体上下文，并且无法被复制者重建：你不能买到数千名用户在你的产品里打磨工作流后形成的行为指纹。
+
+Claude 可以帮助审计你收集到的用户交互数据，识别其中最高信号的行为模式，并设计把持续使用转化为系统性模型改进的反馈环。
+
+练习：给 Claude 一份产品交互数据摘要：你收集了什么、收集了多久、你知道用户如何随时间使用产品。让它识别三个最高信号的行为模式，并为每一个设计能转化为系统性模型改进的反馈环。然后请它帮你起草一页护城河叙事，用于产品营销：你的数据飞轮如何运转、转了多久、为什么一个资源充足的竞争对手今天开始也无法在两年内复制。
+
+**创造工作流锁定**
+
+数据网络效应的复利会让产品更难被复制，而用户工作流锁定会让产品更难被离开。用户在日常运营中运行你的产品越久，它就越深地嵌入他们真实工作的方式。他们在上面建了自动化，训练团队使用它，把它连接到数据源和其他工具。那些 prompt、被打磨的工作流、被标准化的输出，都围绕你的产品做什么、如何做而成形。**到了这个点，切换不再是一个产品决策，而是一个完整规模的运营项目。**
+
+创造工作流锁定的第一步，是让 Claude 按集成深度绘制当前客户群。对每个客户细分，识别他们在你的产品上搭建了哪些工作流、依赖哪些集成。这会显示产品在哪里真正粘住，哪里还需要更深入。
+
+你提供的集成越多，客户就越有空间构建依赖你产品的工作流。Claude Code 可以帮你快速搭起目标用户依赖的数据管线、项目管理工具和其他系统的原生集成。它还可以构建 API、webhook 和 SDK，让客户不只是使用你的产品，而是在你的产品之上构建，这是最深的锁定形式。
+
+练习：让 Claude 帮你为前十名客户建立工作流集成审计。对每个客户，记录他们搭建的自动化、依赖的集成、经过你产品的团队工作流，以及你估计的切换成本。然后请 Claude 识别这些客户之间的模式：哪些集成类型为你的具体产品创造最深锁定？你还能构建或开放什么，让目前停留在表层的客户拥有更深集成？
+
+———
+
+## 第七章 工作没变，规则变了
+
+**在 AI 时代，创始人的工作并没有变：找到一个真问题，做出能解决它的东西，把它扩张成一家有意义的公司。变的是通往那里的路。**
+
+穿过这四个阶段——想法、MVP、发布、规模化，AI 把一个个季度压缩成了一个个星期。
+
+那些过去要几个月的验证周期，现在只要一个下午。一个能跑的原型不再需要一位拥有合适技术栈的联合创始人；它只需要一个清晰问题和几次专注会话，配上一个编程 agent。发布就绪从一阵发布前紧张冲刺，压缩成一条持续工作流。在规模化时，过去把早期员工逼成救火队员的运营重量，越来越多可以交给 AI，让你的团队把注意力放在那些会变成护城河的判断决策上。
+
+**瓶颈不再是「你能造什么」，而是「你选择造什么」。**
+
+———
+
+## 资源链接
+
+用 Claude 构建
+
+- Building AI Agents for Startups：介绍创业公司如何用 agent，让自己在扩张时不那么依赖创始人本人。
+- Claude Code docs：带构建者从初始安装走到进阶 agentic 工作流。提示：先从「How Claude Code works」概览开始。
+- Claude Code best practices：涵盖 Anthropic 内部和工程团队验证过的模式，包括上下文管理、权限、规划和验证工作流。
+- Using [CLAUDE.md](http://claude.md/) files：讲解如何为特定代码库配置 Claude Code。对 MVP 阶段创始人搭建开发环境来说，这是必读材料。
+- Claude Code power user tips：来自 Claude Code 团队自身的工作流模式，包括并行会话和验证环。
+- Get started with Claude Cowork：讲解团队如何搭建 Claude Cowork，并开始实施 Skills、插件和其他能扩大影响的功能。
+- Tutorials：[claude.com/resources/tutorials](http://claude.com/resources/tutorials) 提供可搜索的、面向具体任务的实操教程。
+
+创始人故事
+
+- How three YC startups built their companies with Claude Code：HumanLayer (F24)、Ambral (W25)、Vulcan Technologies (S25) 如何用 Claude 让原型快速上市，并用 agentic 编程工作流扩张 AI 平台。
+- GC AI：创始人用领域专长做了一个由 Claude 驱动的法律平台，对应内部法务团队真实工作方式：公司专属 playbook、跨职能利益相关者、可变风险容忍阈值。
+- Carta Healthcare：用 Claude 驱动临床抽象平台，每年处理 22,000 例手术，数据抽象时间减少 66%。
+- Anything：由 Claude 和 Agent SDK 驱动，已帮助 150 万用户在不写代码的情况下把想法变成可运行软件产品，包括一位非技术创始人做出并已经在卖的完整招聘平台。
+- Cogent：应用 AI 实验室，构建 agent 自动化企业关键安全任务。Claude 是其 agent 的推理层，覆盖漏洞全生命周期的调查、优先级排序和修复。
+- Airtree：把 Claude Cowork 作为运营基础设施中心，统一过去散落在十几个工具和团队里的数据。现在，一个人用 Skills 搭出工作流自动化，组织中每个人都能用它完成那些长期没空做的事。
+- Duvo：构建 AI agent，跨 ERP、供应商门户、电子表格、邮件甚至电话，运行采购、供应链和品类管理流程。Duvo 完全构建在 Claude 上，使用 Agent SDK 跨工作流编排。
+- Zingage：面向居家护理机构的 24/7 自动化运营 AI agent 平台。它用 Claude 的结构化工具调用编排 EMR 和多通信渠道，用 Claude 的上下文推理给出细腻、因患者而异的结果。
+- Kindora：一位非营利组织高管打造的 AI 驱动平台，用 Claude Sonnet 做出一个急需工具：智能匹配慈善组织与资助方。从数千个匹配筛到少数值得追的对象后，Kindora 的 MCP 连接器让非营利机构可以直接在 Claude 里访问潜在客户工具。
+- Wordsmith：由一位转行做 CTO 的律师创办，为内部法务团队提供可靠的 AI 法律技术。Claude 是 Wordsmith 合同审查、协议起草和文档审查能力的推理引擎，而创业公司的工程团队用 Claude Code 构建并演进平台本身。
+
+创业支持与机会
+
+- Anthropic Startups Program：面向与 Anthropic VC 合作伙伴合作的创业公司，提供免费 API credits、公开可得的最高级别 rate limits，并邀请参加专属创始人活动和工作坊。
+- Claude community：面向构建者的论坛和社区空间。
+- Live learning resources：大会、网络研讨会、直播流和录播。
+
+———
+
+本译本仅供个人学习与内部研究使用，不做商业发行。原版权归 Anthropic 所有。
--- a/Resources/Claude-Code/Claude
+++ b/Resources/Claude-Code/Claude
@@ -0,0 +1,416 @@
+---
+created: "2026-05-16"
+type: resource
+tags: [resource, claude-code, agent-teams, orchestration, multi-agent, tmux, subagents, official, workflow]
+source: "https://code.claude.com/docs/en/agent-teams"
+---
+
+# Claude Code Agent Teams 官方多 Agent 编排
+
+Anthropic 官方嘅多 Claude Code instance 编排方案。同 ECC 嘅 `/orchestrate` 第三方实现唔同，呢个系 **Claude Code v2.1.32+ 内置嘅实验功能**，允许多个完整 session 通过共享 task list + 直接消息传递协同工作。
+
+> 相关笔记：[[Everything Claude Code 多服务编排详解]]、[[ECC 编排实战手册]]、[[dmux 多Agent并行编排]]、[[Autonomous Agent Harness 自主代理框架]]
+
+---
+
+## 0. 三层编排能力速查
+
+Claude Code 嘅并行编排有三层，由轻到重：
+
+| 层次 | 工具 | 适用 | 通信方式 |
+|------|------|------|---------|
+| **Subagents** | `Agent` tool（单消息多 call） | 任务独立、只要结果、低成本 | 仅向主 agent 报告 |
+| **Worktrees** | `git worktree` + 多 terminal | 长任务、build/test 隔离 | 无（人工协调） |
+| **Agent Teams** | `CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1` | 需讨论、互相 challenge、跨层协调 | Teammates 之间直接 `SendMessage` |
+
+**判断口诀**：
+- 任务可切干净、只要结果 → Subagents
+- 长 horizon、独立分支 → Worktrees
+- 需要互相对话、对抗审查、你想中途介入某个 worker → **Agent Teams**
+
+---
+
+## 1. Subagents vs Agent Teams 关键对比
+
+| 维度 | Subagents | Agent Teams |
+|------|-----------|------------|
+| Context | 独立窗口，结果汇报返主 agent | 独立窗口，**完全独立 session** |
+| 通信 | 只能向主 agent 报告 | **Teammates 之间直接 message** |
+| 协调 | 主 agent 集中调度 | **共享 task list，self-coordination** |
+| Token 成本 | 较低（结果会被压缩回主 context） | **显著更高**（每个 teammate 都系完整 Claude 实例） |
+| 你能否同 worker 直接对话 | ❌ | ✅ Shift+Down 切换 |
+| 嵌套 | 主 agent 可派 subagent | ❌ Teammate 不能再开 team |
+
+---
+
+## 2. 启用方法
+
+`~/.claude/settings.json`：
+```json
+{
+  "env": {
+    "CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS": "1"
+  },
+  "teammateMode": "auto"
+}
+```
+
+`teammateMode` 三种值：
+- `in-process`：所有 teammate 喺主 terminal，**Shift+Down** 切换，**Ctrl+T** 切 task list
+- `tmux`：split-pane 模式，需要 tmux 或 iTerm2 + it2 CLI
+- `auto`（默认）：喺 tmux 内就 split，否则 in-process
+
+要求版本：`claude --version` ≥ v2.1.32。
+
+---
+
+## 3. tmux 集成操作要点
+
+### 3.1 启动 / 重接
+
+```bash
+# 首次创建（iTerm2 集成）
+tmux -CC new -s billo_team
+
+# 重新接入（推荐用普通 attach，最稳）
+tmux attach -t billo_team
+
+# iTerm2 ControlMode 重接（要 iTerm2 + 已开 tmux integration）
+tmux -CC attach -t billo_team
+
+# 列出所有 session
+tmux ls
+
+# 杀掉旧 session
+tmux kill-session -t billo_team
+```
+
+### 3.2 常见坑
+
+- **`-CC` 看到 raw `%begin %end %output` 输出 = 集成未生效**
+  原因：用紧 Terminal.app 而唔系 iTerm2，或 iTerm2 集成被关。
+  解决：改用 `tmux attach -t <name>` 普通模式。
+
+- **duplicate session 错误**
+  Session 已存在，用 attach 而唔系 new。
+
+- **Claude Code 喺边度起？**
+  喺 tmux session 入面用 `claude` 启动主 session，呢个就系 team lead。Teammate 由 lead 自动 spawn 入新 pane。
+
+### 3.3 tmux 常用快捷键（attach 后）
+
+| 快捷键 | 作用 |
+|--------|------|
+| `Ctrl+b d` | detach 离开但保留 session |
+| `Ctrl+b s` | 列出 session 切换 |
+| `Ctrl+b c` | 开新 window |
+| `Ctrl+b %` / `"` | 垂直 / 水平 split pane |
+
+---
+
+## 4. 架构
+
+| 组件 | 角色 |
+|------|------|
+| **Team lead** | 创建团队嘅主 session，spawn teammate + 协调 |
+| **Teammates** | 独立 Claude Code 实例，各有 context window |
+| **Task list** | 共享任务清单（pending / in_progress / completed，支持依赖） |
+| **Mailbox** | Teammates 之间嘅消息系统，自动投递 |
+
+**状态文件**（**唔好手编辑**，每次状态变更覆盖）：
+- `~/.claude/teams/{team-name}/config.json`
+- `~/.claude/tasks/{team-name}/`
+
+> ⚠️ **冇 project 级 teams 配置**。`.claude/teams/teams.json` 系普通文件，唔识别。
+
+---
+
+## 5. Subagent 定义作为可复用 Teammate 角色
+
+呢个系 Agent Teams 嘅核心可复用性机制。
+
+### 5.1 写法
+
+`.claude/agents/dotnet-backend-implementer.md`（project 级，可 commit）：
+```markdown
+---
+name: dotnet-backend-implementer
+description: Implements .NET backend modules following DDD patterns
+tools: [Read, Write, Edit, Bash, Grep, Glob]
+model: claude-sonnet-4-6
+---
+
+You implement .NET 8 backend modules in the Billo.Platform codebase.
+
+Conventions you MUST follow:
+- DDD layering: Domain / Application / Infrastructure / API
+- Use Result<T> pattern for error returns, no exceptions for control flow
+- Async methods end in Async, ConfigureAwait(false) on library code
+- Repository interfaces in Domain, implementations in Infrastructure
+
+Before implementing:
+1. Read PLAN.md sections relevant to your assigned files
+2. Check existing patterns in adjacent modules
+3. Write xUnit tests first (TDD)
+
+When done: report files changed + test coverage % to the lead.
+```
+
+### 5.2 喺 Agent Teams 入面引用
+
+```text
+Spawn a teammate using the dotnet-backend-implementer agent type
+to handle Subtask 2.1.
+```
+
+### 5.3 注意事项
+
+- Teammate 跟 subagent 定义嘅 `tools` allowlist 同 `model`
+- 定义嘅 body **append** 到 teammate 嘅 system prompt（**唔系替换**）
+- `SendMessage` 同 task 管理工具**永远可用**，即使 `tools` 限制咗其他
+- ⚠️ 定义入面嘅 `skills`、`mcpServers` 喺 team 模式**唔生效**，teammate 从 project / user settings 加载
+
+---
+
+## 6. 大型项目完整工作流
+
+### 6.1 One-time Setup
+
+1. **写好可复用嘅 subagent 定义**（`.claude/agents/*.md`）
+   建议角色：`backend-implementer`、`frontend-implementer`、`domain-modeler`、`test-writer`、`integration-reviewer`、`db-migration-author`
+   既有嘅可直接用：`code-reviewer`、`security-reviewer`、`tdd-guide`、`architect`
+
+2. **写 PLAN.md**（放 repo 根目录）
+   关键：**每个 subtask 列明 owned files glob**，呢个系防冲突嘅唯一可靠方法。
+   ```markdown
+   # Project Plan
+
+   ## Phase 2: Customer Context
+   - 2.1 Customer aggregate
+     - Owner files: src/Customer.Domain/**
+   - 2.2 Customer application layer
+     - Owner files: src/Customer.Application/**
+     - Depends on: 2.1
+   - 2.3 Customer API + integration tests
+     - Owner files: src/Customer.Api/**, tests/Customer.IntegrationTests/**
+     - Depends on: 2.2
+
+   ## Cross-cutting Rules
+   - File ownership is exclusive per subtask
+   - Coverage ≥ 80% per module
+   ```
+
+3. **配置 hooks 作为质量门**（详见第 7 节）
+
+### 6.2 每个阶段嘅 Spawn Prompt 模板
+
+```text
+We're starting Phase {N}. Read PLAN.md for context.
+
+Create an agent team with {3-5} teammates:
+
+[Teammate A]
+  - Name: "customer-domain"
+  - Subagent type: dotnet-backend-implementer
+  - Task: Subtask 2.1
+  - Owned files: src/Customer.Domain/**
+  - Require plan approval before implementation.
+
+[Teammate B]
+  - Name: "customer-app"
+  - Subagent type: dotnet-backend-implementer
+  - Task: Subtask 2.2
+  - Owned files: src/Customer.Application/**
+  - Depends on: customer-domain finishing aggregate signatures
+  - Require plan approval.
+
+[Teammate C]
+  - Name: "customer-api"
+  - Subagent type: dotnet-backend-implementer
+  - Task: Subtask 2.3
+  - Owned files: src/Customer.Api/**, tests/Customer.IntegrationTests/**
+  - Depends on: customer-app
+
+COORDINATION RULES:
+1. Create shared task list with dependencies.
+2. Each teammate reads PLAN.md + cross-cutting rules.
+3. When customer-domain finishes the aggregate API, message
+   customer-app and customer-api with signatures.
+4. No teammate edits files outside their owned glob.
+5. Wait for all to finish before synthesis.
+
+PLAN APPROVAL CRITERIA (for the lead):
+- Reject plans that skip writing tests first.
+- Reject plans touching files outside ownership.
+- Approve plans with explicit coverage ≥ 80%.
+
+AFTER ALL FINISH:
+Spawn code-reviewer teammate for cross-module review.
+Then security-reviewer for the API surface only.
+Report: files changed, coverage %, findings.
+```
+
+### 6.3 阶段过渡
+
+**唔好一次 spawn 所有阶段**。原因：
+- 一次只能开一个 team，必须 cleanup 先开新
+- 下一阶段 spec 可能因为上一阶段发现要调整
+- Token 成本
+
+过渡 prompt：
+```text
+Phase 2 is complete. Summarize:
+- What was delivered vs plan
+- Open issues / deferred items
+- Any architectural changes
+Then clean up the team.
+```
+
+---
+
+## 7. Hooks 质量门
+
+| Hook | 触发时机 | exit code 2 作用 |
+|------|---------|------------------|
+| `TeammateIdle` | Teammate 准备 idle 之前 | 推回反馈，迫继续做 |
+| `TaskCreated` | 任务创建时 | 阻止创建，反馈意见 |
+| `TaskCompleted` | 任务标记完成时 | 阻止完成，反馈意见 |
+
+例子（`~/.claude/settings.json`）：
+```json
+{
+  "hooks": {
+    "TaskCompleted": [
+      {
+        "matcher": ".*test.*",
+        "command": "dotnet test --collect:\"XPlat Code Coverage\" | grep -q 'Line coverage.*[8-9][0-9]%\\|100%' || exit 2"
+      }
+    ],
+    "TeammateIdle": [
+      {
+        "command": "git status --short | grep -v '^??' | wc -l | awk '$1==0 {exit 0} {print \"Uncommitted work\"; exit 2}'"
+      }
+    ]
+  }
+}
+```
+
+---
+
+## 8. 控制操作
+
+### 8.1 模型选择
+
+Teammate **唔继承** lead 嘅 `/model`。要喺 `/config` 设置 **Default teammate model**，或选 "Default (leader's model)" 跟随 lead。Spawn prompt 入面也可显式：
+```text
+Use Sonnet for each teammate.
+```
+
+### 8.2 Plan Approval（高风险任务必用）
+
+```text
+Spawn an architect teammate to refactor authentication.
+Require plan approval before any changes.
+```
+Teammate 留喺 read-only plan mode，lead 审核批准或反馈拒绝。
+
+### 8.3 直接对话 Teammate
+
+- **in-process**：`Shift+Down` 循环切 → 打字发消息 → `Enter` 进入睇 session → `Esc` 中断
+- **split-pane**：直接 click 入嗰个 pane
+
+### 8.4 关闭 Teammate / 清场
+
+```text
+Ask the researcher teammate to shut down
+```
+
+**清场必须由 lead 执行**：
+```text
+Clean up the team
+```
+（Teammate cleanup 会留下 inconsistent state）
+
+---
+
+## 9. 官方使用场景
+
+### 9.1 并行 Code Review
+```text
+Create an agent team to review PR #142. Spawn three reviewers:
+- One focused on security implications
+- One checking performance impact
+- One validating test coverage
+Have them each review and report findings.
+```
+
+### 9.2 竞争性假设调查（debug 神技）
+```text
+Users report the app exits after one message. Spawn 5 teammates
+to investigate different hypotheses. Have them talk to each other
+to disprove each other's theories, like a scientific debate.
+Update findings doc with consensus.
+```
+精髓：互相 challenge 打破单 agent 嘅 anchoring bias。
+
+---
+
+## 10. Best Practices
+
+| 项 | 建议 |
+|----|------|
+| Team 大小 | **3-5 个 teammate 最稳**，超过协调成本 > 收益 |
+| 任务大小 | 每个 teammate 5-6 个 task 最高产 |
+| 文件 ownership | **必须明确分割**，每个 teammate 独占 glob |
+| Plan approval | 高风险（migration、API contract、auth）一定 require |
+| 新手入门 | 由 review / research 开始，唔写代码嘅任务先体验 |
+| Lead 偷跑 | 见 lead 自己动手就提佢 "Wait for your teammates to complete" |
+| Permission | 预先批准常用操作，减少 prompt 打断 |
+
+---
+
+## 11. 实验性限制（实操要小心）
+
+| 限制 | 影响 |
+|------|------|
+| `/resume` `/rewind` 唔恢复 in-process teammate | 恢复后 lead 可能发消息俾已死 teammate → 叫佢 spawn new |
+| Task status 可能滞后 | Teammate 偶尔忘记 mark complete，阻塞下游 |
+| Shutdown 慢 | Teammate 完成当前 tool call 先关 |
+| **一次只能开一个 team** | 创建新 team 必须先 cleanup 旧 |
+| **唔支持嵌套 team** | Teammate 不能 spawn 自己嘅 team |
+| **Lead 唔可转让** | 创建 team 嗰个 session 永远系 lead |
+| Permission 只喺 spawn 时跟 lead | Spawn 完先可单独改个别 teammate |
+| Split-pane 限制 | VS Code 内置 terminal、Windows Terminal、Ghostty **唔支持** |
+
+---
+
+## 12. 思维模型
+
+把多 Agent 编排映射到人类团队：
+
+```
+开发计划 (Plan)
+  └── 阶段 (Phase)
+        ├── 独立子任务 → 并行
+        │     ├── 任务可切干净 → Subagents (廉价 fan-out)
+        │     ├── 任务需独立 build/test → Worktrees (隔离)
+        │     └── 任务需互相讨论 → Agent Teams (协同)
+        └── 阶段尾审查
+              └── 并行 reviewer teammates
+                    (security / performance / test coverage 各一个)
+```
+
+启发：**如果你会同时分配呢两个任务俾两个唔同嘅工程师，并且佢哋唔需要事先沟通，咁就适合并行**。
+
+---
+
+## 13. 同既有笔记嘅区别
+
+| 笔记 | 重点 |
+|------|------|
+| 本笔记 | **官方 Agent Teams**（v2.1.32+ 实验功能、tmux 集成、大型项目编排模板） |
+| [[Everything Claude Code 多服务编排详解]] | **ECC 第三方** `/orchestrate` 命令（feature/bugfix/refactor/security 流水线） |
+| [[ECC 编排实战手册]] | ECC 6 种正交编排模式总览 |
+| [[dmux 多Agent并行编排]] | dmux 工具嘅并行 worktree 编排 |
+| [[Ralphinho RFC-DAG 编排模式]] | RFC-DAG 风格强制隔离编排 |
+| [[Autonomous Agent Harness 自主代理框架]] | 长时间自主运行嘅 harness 设计 |
--- a/Resources/Claude-Code/ECC
+++ b/Resources/Claude-Code/ECC
@@ -0,0 +1,721 @@
+---
+created: "2026-04-25"
+type: resource
+tags: [resource, claude-code, ECC, orchestration, multi-agent, parallel, autonomous, hands-on]
+source: "https://github.com/affaan-m/everything-claude-code"
+---
+
+# ECC 编排实战手册
+
+ECC 没有"一种"编排,而是 **6 种正交模式** 散布在 commands/、skills/、scripts/ 三个层面。这份手册把每一种的真实命令、真实代码、真实出处全列出来,并明确标记"哪些有公开实操证据,哪些只能照命令文档说的去做"。
+
+> 相关笔记:[[Everything Claude Code 完整指南]]、[[Everything Claude Code 方法论与最佳实践]]、[[ECC 编排替代方案 (orchestrate 迁移)]]、[[Autonomous Loops 自主循环模式]]、[[dmux 多Agent并行编排]]、[[Ralphinho RFC-DAG 编排模式]]、[[Autonomous Agent Harness 自主代理框架]]
+
+---
+
+## 0. 决策树:你到底在编排什么?
+
+不同模式解决的是完全不同的问题。先回答 3 个问题:
+
+```text
+Q1: 你需要并行,还是顺序但不间断?
+    ├─ 顺序但不间断 → 模式 2 (Sequential Pipeline) 或 模式 3 (Continuous PR Loop)
+    └─ 并行 → Q2
+
+Q2: 并行的任务之间有依赖关系吗?
+    ├─ 无依赖(独立的几件事) → 模式 1 (dmux / Worktree 并行)
+    └─ 有依赖 → Q3
+
+Q3: 需要"评审者≠实现者"的强制隔离吗?
+    ├─ 需要(高风险、生产代码) → 模式 4 (Ralphinho RFC-DAG) 或 模式 5 (Santa Loop 双评审)
+    └─ 不需要(单 session 内 agent 委派就够) → 模式 6 (Task 工具内嵌并行)
+```
+
+| 模式 | 用什么 | 真实存在 | 是否 Windows 可用 |
+|------|--------|---------|------------------|
+| 1. dmux + 多 worktree | `dmux-workflows` skill + `scripts/orchestrate-worktrees.js` | ✅ 仓库内 | ❌ 需 tmux |
+| 2. Sequential `claude -p` 管道 | shell 脚本 + `claude -p` | ✅ 官方 CLI | ✅ |
+| 3. Continuous PR Loop | `continuous-claude` 外部工具 | ✅ AnandChowdhary | ✅ |
+| 4. Ralphinho RFC-DAG | `ralphinho` 外部工具 + `ralphinho-rfc-pipeline` skill | ✅ enitrat | ✅(用 jj) |
+| 5. Santa Loop 双评审 | `/santa-loop` 命令 | ✅ ECC 命令 | ✅ |
+| 6. Task 工具内并行 | Claude Code 原生 `Task` tool | ✅ 内置 | ✅ |
+| (退役)`/orchestrate` | legacy shim → 转发到 dmux/harness | ⚠️ 已标记为 legacy | ❌ |
+| (替代)`/feature-dev` | 单功能 7 阶段全流程 | ✅ 命令存在 | ✅ |
+| (高级)`/multi-plan` `/multi-execute` | `ccg` 多模型协同(需外部 Codex/Gemini CLI) | ⚠️ 需独立安装 | 部分 |
+
+---
+
+## 模式 1:dmux + 多 worktree(并行独立任务)
+
+### 实事求是:这是 ECC 推荐的"真正多 agent 编排"
+
+ECC 仓库 `commands/orchestrate.md` 第 1 行明确写:
+
+> *"Legacy slash-entry shim for dmux-workflows and autonomous-agent-harness. Prefer the skills directly."*
+
+也就是说 `/orchestrate` 已退役,真实主力是 `dmux-workflows` skill。
+
+### 何时用
+
+- 3-5 个**互不依赖**的任务(不同模块/不同关注点)
+- 你想用不同模型/不同工具(Claude Code + Codex + OpenCode 混搭)
+- 你愿意装 tmux
+
+### 真实命令(已验证)
+
+```bash
+# 1. 装 dmux(GitHub: standardagents/dmux)
+# README 原话: "cd /path/to/your/project / dmux /
+# Press `n` to create a new pane, type a prompt, pick one or more agents"
+brew install tmux  # 前置依赖
+
+# 2. 在项目根目录起 dmux
+cd /path/to/project
+dmux
+
+# 3. 在 dmux 里:
+#    按 n → 输入 prompt → 选 agent (Claude Code/Codex/Gemini/...)
+#    每个 pane 独立 session,独立 context window
+#    按 m → 把 pane 输出 merge 回主 session
+```
+
+### ECC 自带的 worktree 编排器(无需 dmux)
+
+如果你不想用 dmux,ECC 仓库有自己的 `scripts/orchestrate-worktrees.js`(实测存在,2873 字节)。用法是先写一个 plan.json,然后:
+
+```bash
+# 仓库实际命令(scripts/orchestrate-worktrees.js usage 输出)
+node scripts/orchestrate-worktrees.js plan.json [--execute]
+node scripts/orchestrate-worktrees.js plan.json [--write-only]
+# 不带 flag 默认 dry-run,只打印计划
+```
+
+`plan.json` 的真实结构(直接来自 `skills/dmux-workflows/SKILL.md`):
+
+```json
+{
+  "sessionName": "skill-audit",
+  "baseRef": "HEAD",
+  "launcherCommand": "codex exec --cwd {worktree_path} --task-file {task_file}",
+  "workers": [
+    { "name": "docs-a", "task": "Fix skills 1-4 and write handoff notes." },
+    { "name": "docs-b", "task": "Fix skills 5-8 and write handoff notes." }
+  ]
+}
+```
+
+可用占位符:`{worker_name}` `{worker_slug}` `{session_name}` `{repo_root}` `{worktree_path}` `{branch_name}` `{task_file}` `{handoff_file}` `{status_file}`。
+
+每个 worker 会:
+1. 在 `.orchestration/<session>/` 下生成 `task.md`、`handoff.md`、`status.md`
+2. 单独开一个分支 + git worktree
+3. 在 tmux pane 里跑 `launcherCommand`
+
+### 监控
+
+```bash
+# 仓库实际命令
+node scripts/orchestration-status.js .claude/plan/workflow-visual-proof.json
+```
+
+输出 JSON 包含:session 活动、tmux pane 元数据、worker 状态、目标、recent handoff summaries。
+
+### `seedPaths`(把 dirty 文件带进 worktree)
+
+如果 worker 需要看主分支没提交的本地文件(比如新写的脚本):
+
+```json
+{
+  "sessionName": "workflow-e2e",
+  "seedPaths": [
+    "scripts/orchestrate-worktrees.js",
+    "scripts/lib/tmux-worktree-orchestrator.js",
+    ".claude/plan/workflow-e2e-test.json"
+  ],
+  "workers": [{ "name": "docs", "task": "Update orchestration docs." }]
+}
+```
+
+ECC 会在 `git worktree add` 之后把这些路径覆盖到每个 worker worktree。
+
+### 5 个 dmux pattern(直接抄自 SKILL.md)
+
+| 模式 | Pane 1 | Pane 2 | Pane 3 |
+|------|--------|--------|--------|
+| Research + Implement | 调研 + 写到 `/tmp/x.md` | 先写实现框架,等调研完合并 | — |
+| Multi-File Feature | DB schema + migration | API endpoints | UI 组件 |
+| Test + Fix Loop | 跑 watch mode,失败时总结 | 根据 pane 1 的输出修 | — |
+| Cross-Harness | Claude Code 审 auth 安全 | Codex 重构 utility 性能 | Claude Code 写 E2E |
+| Code Review Pipeline | 看 src/api 安全 | 看 src/api 性能 | 看 src/api 测试覆盖 |
+
+### 硬约束(SKILL.md 原话)
+
+> *"Independent tasks only. Don't parallelize tasks that depend on each other's output."*
+> *"Each pane is a full agent session — keep total panes under 5-6."*
+
+---
+
+## 模式 2:Sequential `claude -p` 管道(最朴素,最稳)
+
+### 何时用
+
+- 你想要**确定性**:每步独立 context,不会被前面污染
+- 你想要 CI/CD 集成
+- 你愿意写 shell
+
+### 真实例子(skills/autonomous-loops/SKILL.md 原文)
+
+```bash
+#!/bin/bash
+# daily-dev.sh — Sequential pipeline for a feature branch
+set -e
+
+# Step 1: Implement the feature
+claude -p "Read the spec in docs/auth-spec.md. Implement OAuth2 login in src/auth/. Write tests first (TDD). Do NOT create any new documentation files."
+
+# Step 2: De-sloppify (cleanup pass)
+claude -p "Review all files changed by the previous commit. Remove any unnecessary type tests, overly defensive checks, or testing of language features (e.g., testing that TypeScript generics work). Keep real business logic tests. Run the test suite after cleanup."
+
+# Step 3: Verify
+claude -p "Run the full build, lint, type check, and test suite. Fix any failures. Do not add new features."
+
+# Step 4: Commit
+claude -p "Create a conventional commit for all staged changes. Use 'feat: add OAuth2 login flow' as the message."
+```
+
+### 关键设计原则(原文)
+
+1. **每步隔离** —— 新 context window 意味着不会有前一步的污染
+2. **顺序敏感** —— 每步建立在上一步留下的文件状态上
+3. **`set -e` 失败立即停**
+4. **负面指令危险** —— 别说"不要测类型系统",改成单独加一个 cleanup step
+
+### 模型路由变体
+
+```bash
+# 用 Opus 做深度分析
+claude -p --model opus "Analyze the codebase architecture and write a plan for adding caching..."
+
+# 用 Sonnet 实现
+claude -p "Implement the caching layer according to the plan in docs/caching-plan.md..."
+
+# 用 Opus 审查
+claude -p --model opus "Review all changes for security issues, race conditions, and edge cases..."
+```
+
+### 工具限制变体
+
+```bash
+# 只读分析
+claude -p --allowedTools "Read,Grep,Glob" "Audit this codebase for security vulnerabilities..."
+
+# 只写实现
+claude -p --allowedTools "Read,Write,Edit,Bash" "Implement the fixes from security-audit.md..."
+```
+
+### De-sloppify pattern(关键加分项)
+
+任何"实现"步骤后面都跟一个清理步骤,而不是用负面指令限制实现者:
+
+```bash
+for feature in "${features[@]}"; do
+  claude -p "Implement $feature with TDD."
+  claude -p "Cleanup pass: review changes, remove test/code slop, run tests."
+  claude -p "Run build + lint + tests. Fix any failures."
+  claude -p "Commit with message: feat: add $feature"
+done
+```
+
+> 原文洞察:*"Two focused agents outperform one constrained agent."*
+
+---
+
+## 模式 3:Continuous PR Loop(多日自治)
+
+### 何时用
+
+- 多日的迭代项目(比如"加完整测试覆盖率")
+- 每次迭代要走 PR + CI
+- 你愿意用别人写好的工具(`continuous-claude`)
+
+### 真实工具(已验证存在)
+
+- **GitHub:** github.com/AnandChowdhary/continuous-claude
+- **作者博客:** https://anandchowdhary.com/blog/2025/running-claude-code-in-a-loop
+- **HN 讨论:** https://news.ycombinator.com/item?id=45938517
+
+README 原话:
+
+> *"Run Claude Code in a continuous loop, autonomously creating PRs, waiting for checks, and merging."*
+
+### 真实命令
+
+```bash
+# 基础: 10 次迭代
+continuous-claude --prompt "Add unit tests for all untested functions" --max-runs 10
+
+# 成本上限
+continuous-claude --prompt "Fix all linter errors" --max-cost 5.00
+
+# 时间盒
+continuous-claude --prompt "Improve test coverage" --max-duration 8h
+
+# 加 reviewer 子步骤
+continuous-claude \
+  --prompt "Add authentication feature" \
+  --max-runs 10 \
+  --review-prompt "Run npm test && npm run lint, fix any failures"
+
+# 用 worktree 并行多实例
+continuous-claude --prompt "Add tests" --max-runs 5 --worktree tests-worker &
+continuous-claude --prompt "Refactor code" --max-runs 5 --worktree refactor-worker &
+wait
+```
+
+### 跨迭代上下文桥(`SHARED_TASK_NOTES.md`)
+
+迭代之间靠这个文件传状态:
+
+```markdown
+## Progress
+- [x] Added tests for auth module (iteration 1)
+- [x] Fixed edge case in token refresh (iteration 2)
+- [ ] Still need: rate limiting tests, error boundary tests
+
+## Next Steps
+- Focus on rate limiting module next
+- The mock setup in tests/helpers.ts can be reused
+```
+
+每次迭代开始 Claude 读它,结束 Claude 更新它。这就是用 filesystem 桥接独立 `claude -p` invocation 的关键技巧。
+
+### CI 失败自动恢复
+
+PR 检查失败时,continuous-claude 会:
+1. `gh run list` 查最近的失败 run id
+2. 起一个新的 `claude -p` 带 CI fix context
+3. Claude 用 `gh run view` 看日志、修代码、提交、push
+4. 重新等待检查(最多 `--ci-retry-max` 次,默认 1)
+
+### Completion signal
+
+```bash
+continuous-claude \
+  --prompt "Fix all bugs in the issue tracker" \
+  --completion-signal "CONTINUOUS_CLAUDE_PROJECT_COMPLETE" \
+  --completion-threshold 3  # 连续 3 次发出信号才停
+```
+
+### 全部 flags
+
+| Flag | 用途 |
+|------|------|
+| `--max-runs N` | N 次迭代后停 |
+| `--max-cost $X` | 花 $X 后停 |
+| `--max-duration 2h` | 时间到后停 |
+| `--merge-strategy squash` | squash / merge / rebase |
+| `--worktree <name>` | git worktree 并行 |
+| `--disable-commits` | dry-run |
+| `--review-prompt "..."` | 加评审子步骤 |
+| `--ci-retry-max N` | CI 失败自动修次数 |
+
+---
+
+## 模式 4:Ralphinho RFC-DAG(最复杂、最严谨)
+
+### 何时用
+
+- 已经有一份 RFC / PRD
+- 多个**互相依赖**的工作单元
+- 不能容忍"实现者评审自己代码"的偏见
+- 多日大项目
+
+### 真实工具(已验证)
+
+- **GitHub:** github.com/enitrat/ralphinho
+- README 原话:*"Multi-agent AI development workflows — code review with improvinho, spec-driven implementation with ralphinho, and optional Linear integration for human-in-the-loop triage."*
+- 用 **Jujutsu (jj)** 而不是 git 做 worktree 隔离
+- ~93% TypeScript
+
+### 真实命令(从 README)
+
+```bash
+# 从 RFC 启动
+ralphinho init ./rfc.md
+
+# 或纯评审模式(improvinho)
+ralphinho init review "review this auth module" --paths src/auth/
+
+# 跑
+ralphinho run
+```
+
+### 架构(skills/ralphinho-rfc-pipeline/SKILL.md + autonomous-loops/SKILL.md)
+
+```text
+RFC/PRD Document
+       │
+       ▼
+  DECOMPOSITION (AI)
+  把 RFC 拆成依赖 DAG 的 work units
+       │
+       ▼
+  RALPH LOOP (最多 3 轮)
+       │
+       ▼
+  对 DAG 每一层(按依赖顺序):
+       │
+       ├── Quality Pipelines (每个 unit 并行,各自 worktree)
+       │   research → plan → implement → test → review
+       │   (深度按 tier 调整)
+       │
+       └── Merge Queue
+           rebase → tests → land 或 evict
+           被 evict 的 unit 带冲突 context 重新进队
+```
+
+### 工作单元结构
+
+```typescript
+interface WorkUnit {
+  id: string;              // kebab-case
+  name: string;
+  rfcSections: string[];   // 对应 RFC 哪些章节
+  description: string;
+  deps: string[];          // 依赖的其他 unit id
+  acceptance: string[];    // 验收标准
+  tier: "trivial" | "small" | "medium" | "large";
+}
+```
+
+### 复杂度分层(关键)
+
+| Tier | Pipeline 阶段 |
+|------|--------------|
+| trivial | implement → test |
+| small | implement → test → code-review |
+| medium | research → plan → implement → test → PRD-review + code-review → review-fix |
+| large | 加 final-review |
+
+### 模型分配(每阶段独立 context)
+
+| 阶段 | 模型 | 用途 |
+|------|------|------|
+| Research | Sonnet | 读代码 + RFC,产出 context doc |
+| Plan | Opus | 设计实现步骤 |
+| Implement | Codex | 写代码 |
+| Test | Sonnet | build + test |
+| PRD Review | Sonnet | 规范合规检查 |
+| Code Review | Opus | 质量 + 安全 |
+| Review Fix | Codex | 处理评审意见 |
+| Final Review | Opus | 大改才走 |
+
+> 关键设计:**评审者从未写过它评审的代码**(消除作者偏见)。
+
+### Merge queue eviction recovery
+
+被 evict 时把完整冲突 context(冲突文件、diff、test 输出)喂回给 implementer 下一轮:
+
+```markdown
+## MERGE CONFLICT — RESOLVE BEFORE NEXT LANDING
+
+Your previous implementation conflicted with another unit that landed first.
+Restructure your changes to avoid the conflicting files/lines below.
+
+{full eviction context with diffs}
+```
+
+### 何时不用
+
+| 信号 | 用 Ralphinho | 用更简单的 |
+|------|-------------|-----------|
+| 多个互相依赖的单元 | ✅ | ❌ |
+| 需要并行实现 | ✅ | ❌ |
+| 单文件改动 | ❌ | ✅(用模式 2) |
+| 多日 + 已有 RFC | ✅ | ❌ |
+| 一个东西的快速迭代 | ❌ | ✅(用 NanoClaw) |
+
+---
+
+## 模式 5:Santa Loop 双评审(对抗式收敛)
+
+### 何时用
+
+- 改完代码不想自欺欺人
+- 想要"两个独立模型都点头才上线"的硬门槛
+- 单一会话内可完成
+
+### 真实命令(commands/santa-loop.md)
+
+```bash
+# 评审当前未提交的改动
+/santa-loop
+
+# 评审某个文件/glob
+/santa-loop src/auth/
+
+# 评审某个范围描述
+/santa-loop "the new payment integration"
+```
+
+### 工作流(命令文档原文)
+
+1. **Identify scope** —— 默认 `git diff --name-only HEAD`
+2. **Build rubric** —— 至少包含 6 项:Correctness、Security、Error handling、Completeness、Internal consistency、No regressions。可加领域特定项(TS type safety、Rust memory safety、SQL migration safety)
+3. **Dual independent review (并行)**:
+   - Reviewer A:**永远是 Claude Opus**(`code-reviewer` agent)
+   - Reviewer B:按可用性顺序 codex CLI > gemini CLI > Claude Opus 兜底
+   - 两个 reviewer 都看不到对方的输出
+   - 都要返回结构化 JSON:
+     ```json
+     {
+       "verdict": "PASS" | "FAIL",
+       "checks": [{"criterion": "...", "result": "PASS|FAIL", "detail": "..."}],
+       "critical_issues": ["..."],
+       "suggestions": ["..."]
+     }
+     ```
+4. **Verdict gate**:
+   - 都 PASS → NICE → push
+   - 任一 FAIL → NAUGHTY → 进入 fix cycle
+5. **Fix cycle**(NAUGHTY 路径):
+   - 修所有 critical issue,**只改被标记的,不顺手重构**
+   - 单个 commit:`fix: address santa-loop review findings (round N)`
+   - 起**新的** reviewer(没有上轮记忆)
+   - 最多 3 轮,还是 NAUGHTY 就停下来让人介入
+
+### 设计要点(命令文档原话)
+
+> *"Reviewer A (Claude Opus) always runs — guarantees at least one strong reviewer regardless of tooling."*
+>
+> *"Model diversity is the goal for Reviewer B. GPT-5.4 or Gemini 2.5 Pro gives true independence — different training data, different biases, different blind spots."*
+>
+> *"External reviewers run with `--sandbox read-only` (Codex) to prevent repo mutation during review."*
+>
+> *"Fresh reviewers each round prevents anchoring bias from prior findings."*
+
+### 输出格式
+
+```text
+SANTA VERDICT: NICE / NAUGHTY (escalated)
+
+Reviewer A (Claude Opus):   [PASS/FAIL]
+Reviewer B ([model used]):  [PASS/FAIL]
+
+Agreement:
+  Both flagged:      [issues caught by both]
+  Reviewer A only:   [issues only A caught]
+  Reviewer B only:   [issues only B caught]
+
+Iterations: [N]/3
+Result:     [PUSHED / ESCALATED TO USER]
+```
+
+---
+
+## 模式 6:单 session 内 Task 并行(轻量内嵌)
+
+### 何时用
+
+- 不想配 tmux/worktree
+- 任务可以在一个 session 内做完
+- 几个独立子任务想并行
+
+### 用法
+
+直接在 Claude Code 主会话里让它"用 Task 工具并行起几个子 agent":
+
+```
+请并行起 3 个子 agent:
+- agent 1: 读 src/api/ 找 SQL injection 风险
+- agent 2: 读 src/api/ 找性能瓶颈
+- agent 3: 读 src/api/ 找测试覆盖空洞
+所有 agent 都用 Read/Grep/Glob,不要写文件。最后合并报告。
+```
+
+Claude Code 会用 `Task` 工具(就是 prompt 里能看到的 `Agent` tool)起 N 个 subagent,每个独立 context window,并行跑完后把结果传回主 session。
+
+### 关键约束
+
+- 每个子 agent 会回报一段 summary,主 agent 看不到子 agent 的中间过程
+- 子 agent 用 `CLAUDE_CODE_SUBAGENT_MODEL=haiku` 跑(便宜约 80%)—— 见 [[Everything Claude Code Token 优化]]
+- 5-6 个并行是上限,再多 token 烧得心疼
+
+---
+
+## 命令对照表(全部带状态标记)
+
+| 命令 | 状态 | 真实做什么 |
+|------|------|----------|
+| `/orchestrate` | ⚠️ Legacy shim | 转发到 dmux-workflows + autonomous-agent-harness skill |
+| `/feature-dev` | ✅ 现役 | 单功能 7 阶段:Discovery → Codebase Exploration → Clarifying Questions → Architecture Design → Implementation → Quality Review → Summary |
+| `/multi-plan` | ⚠️ 需外部 CLI | `ccg:plan` 多模型协同规划,需要 codex/gemini CLI 和 `~/.claude/bin/codeagent-wrapper` |
+| `/multi-execute` | ⚠️ 需外部 CLI | 同上,执行阶段 |
+| `/multi-frontend` `/multi-backend` `/multi-workflow` | ⚠️ 需外部 CLI | multi-* 系列变体 |
+| `/loop-start` | ✅ 现役 | 启动 loop,模式 = sequential / continuous-pr / rfc-dag / infinite,模式 = safe(默认严格) / fast |
+| `/loop-status` | ✅ 现役 | 看当前 loop 状态,`--watch` 持续刷新 |
+| `/santa-loop` | ✅ 现役 | 双评审收敛(见模式 5) |
+| `/harness-audit` | ✅ 现役 | 跑 `node scripts/harness-audit.js`,7 类打分(各 0-10):Tool Coverage、Context Efficiency、Quality Gates、Memory Persistence、Eval Coverage、Security Guardrails、Cost Efficiency |
+| `/quality-gate` | ✅ 现役 | 质量管道(类 hook 行为) |
+| `/model-route` | ✅ 现役 | 推荐当前任务该用哪个模型 |
+| `/devfleet` | ⚠️ 需 MCP | 需要外部 Claude DevFleet 实例:`claude mcp add devfleet --transport http http://localhost:18801/mcp` |
+
+---
+
+## 实战搭配建议
+
+### A. 单人,小项目,不想配 tmux
+
+**主路:** 模式 2(Sequential `claude -p`)+ 模式 6(Task 内并行)+ 模式 5(`/santa-loop`)
+
+```bash
+# 一个 shell 脚本搞定
+#!/bin/bash
+set -e
+claude -p "Plan the new feature based on docs/spec.md"
+claude -p "Implement based on the plan, TDD"
+claude -p "De-sloppify pass: remove test/code slop"
+# 进 Claude Code 交互模式跑 santa-loop
+echo "Now run: /santa-loop in interactive Claude Code"
+```
+
+### B. 团队,多任务并行
+
+**主路:** 模式 1(`scripts/orchestrate-worktrees.js`)+ 模式 5
+
+```bash
+# plan.json
+{
+  "sessionName": "sprint-23",
+  "workers": [
+    {"name": "feat-auth", "task": "Implement OAuth2 from .claude/specs/auth.md"},
+    {"name": "feat-billing", "task": "Implement Stripe billing from .claude/specs/billing.md"},
+    {"name": "feat-admin", "task": "Build admin panel from .claude/specs/admin.md"}
+  ]
+}
+
+# 执行
+node scripts/orchestrate-worktrees.js plan.json --execute
+
+# 监控
+node scripts/orchestration-status.js plan.json
+
+# 每个 worker 完成后,合到主分支前
+/santa-loop feature/feat-auth..main
+```
+
+### C. 多日大项目,有 RFC
+
+**主路:** 模式 4(Ralphinho)
+
+```bash
+# 把 RFC 写到 ./rfc.md
+ralphinho init ./rfc.md
+ralphinho run
+
+# Linear 集成可选(human-in-the-loop triage)
+```
+
+### D. 自治改 bug / 加测试
+
+**主路:** 模式 3(continuous-claude)
+
+```bash
+continuous-claude \
+  --prompt "Improve test coverage to 90% across src/" \
+  --max-runs 20 \
+  --max-cost 50.00 \
+  --completion-signal "COVERAGE_90_REACHED" \
+  --review-prompt "npm test && npm run lint"
+```
+
+---
+
+## 反模式(全部从 SKILL.md 原文摘抄)
+
+1. **无限循环没退出条件** —— 必须有 max-runs / max-cost / max-duration / completion signal。
+2. **迭代之间没有 context bridge** —— 用 `SHARED_TASK_NOTES.md` 或 filesystem state 桥接。
+3. **重试同一个失败** —— 把 error context 喂给下一次,不要盲目 retry。
+4. **用负面指令代替 cleanup pass** —— 别说 "don't do X",加一个去 X 的 pass。
+5. **所有 agent 在同一个 context window** —— 复杂工作流必须分到独立 process。**评审者绝对不能是作者**。
+6. **并行任务编辑同一文件** —— 必须有 merge 策略(顺序 land、rebase、冲突解决)。
+7. **盲目并行** —— 引自 Longform Guide:*"how much can you get done with the minimum viable amount of parallelization."*
+
+---
+
+## 配套真实工具栈
+
+| 工具 | 链接 | 何时装 |
+|------|------|------|
+| **dmux** | github.com/standardagents/dmux | 想要 tmux 多 pane 多 agent |
+| **continuous-claude** | github.com/AnandChowdhary/continuous-claude | 想跑 PR 自治循环 |
+| **Ralphinho** | github.com/enitrat/ralphinho | 有 RFC,需要 DAG 编排 |
+| **codex CLI** | OpenAI Codex CLI | 用 `/santa-loop` 第二评审者、`/multi-*` 命令 |
+| **gemini CLI** | Google Gemini CLI | 同上 |
+| **jj (Jujutsu)** | github.com/martinvonz/jj | Ralphinho 的 worktree 后端 |
+
+---
+
+## 不可考的边界(诚实声明)
+
+我搜了 X、Reddit、HN、Medium,**没有找到** `/orchestrate`、`/multi-plan`、`/multi-execute`、`/feature-dev`、`/loop-start` 在公开场合的实操截图或 thread。这些命令在仓库里**确实存在**(我读过 commands/*.md 文件),但社区没人晒出过运行时的 demo。
+
+这意味着:
+- 上面这些命令的"真实命令行"我都是按 `commands/*.md` 文件里写的复述,不是观察到的实际行为
+- `/multi-plan` `/multi-execute` 实际依赖的 `~/.claude/bin/codeagent-wrapper` 不是 ECC 标配,需要自己装(看起来是从一个叫 `ccg`(codex-claude-gemini)的项目来的)
+- `/devfleet` 需要单独跑 Claude DevFleet HTTP 服务
+
+**安全建议:** 优先用模式 1、2、3、5、6(全部都有真实可观测的工具支撑)。模式 4 也行,但配置成本高。`/multi-*` 系列等你看到 affaan 或社区有人晒 demo 再用。
+
+---
+
+## 来源
+
+### 主要来源(直接读取的仓库文件)
+
+- `commands/orchestrate.md`(legacy shim 声明)
+- `commands/feature-dev.md`(7 阶段定义)
+- `commands/multi-plan.md`、`multi-execute.md`(ccg 协议)
+- `commands/loop-start.md`、`loop-status.md`
+- `commands/santa-loop.md`(双评审完整流程)
+- `commands/harness-audit.md`(7 类打分)
+- `skills/dmux-workflows/SKILL.md`(5 个 pattern + plan.json 结构)
+- `skills/autonomous-loops/SKILL.md`(6 种 loop 模式 + 反模式)
+- `skills/ralphinho-rfc-pipeline/SKILL.md`(7 阶段 + tier 表)
+- `skills/autonomous-agent-harness/SKILL.md`(cron + memory + dispatch + computer use)
+- `skills/continuous-agent-loop/SKILL.md`(loop selection flow)
+- `skills/claude-devfleet/SKILL.md`(plan_project / dispatch_mission MCP 工具)
+- `agents/loop-operator.md`
+- `scripts/orchestrate-worktrees.js`(实测存在,2873 字节)
+- `scripts/orchestration-status.js`(实测存在,1604 字节)
+
+### 二次来源(网上验证)
+
+- The Longform Guide:https://github.com/affaan-m/everything-claude-code/blob/main/the-longform-guide.md
+- Affaan 公告:https://x.com/affaanmustafa/status/2014040193557471352(2026-01-21)
+- continuous-claude:https://github.com/AnandChowdhary/continuous-claude + https://anandchowdhary.com/blog/2025/running-claude-code-in-a-loop
+- Ralphinho:https://github.com/enitrat/ralphinho
+- dmux:https://github.com/standardagents/dmux
+- Medium 评述:https://medium.com/@tentenco/everything-claude-code-inside-the-82k-star-agent-harness-thats-dividing-the-developer-community-4fe54feccbc1
+
+---
+
+## Related
+
+### Resources
+- [[Everything Claude Code 完整指南]]
+- [[Everything Claude Code 方法论与最佳实践]]
+- [[Everything Claude Code 用法速查]]
+- [[ECC 编排替代方案 (orchestrate 迁移)]]
+- [[Autonomous Agent Harness 自主代理框架]]
+- [[Autonomous Loops 自主循环模式]]
+- [[Ralphinho RFC-DAG 编排模式]]
+- [[dmux 多Agent并行编排]]
+- [[GSD 方法论与最佳实践]]
+
+### Zettelkasten
+- [[Everything Claude Code Agent 编排模式]]
+- [[Everything Claude Code 多服务编排详解]]
+- [[Everything Claude Code 最佳实践]]
+- [[Everything Claude Code Token 优化]]
+- [[上下文腐烂与全新窗口隔离]]
--- a/Resources/Claude-Code/Everything
+++ b/Resources/Claude-Code/Everything
@@ -95,6 +95,44 @@ Legacy shim 仍然可用（向后兼容），只是内部转发到对应 skill

 Rules 新增：java, kotlin, dart, csharp, cpp, rust, perl, php, web, zh (中文)

+### Skill 放置策略 (新规范)
+
+仓库新增 `docs/SKILL-PLACEMENT-POLICY.md`，明确 4 类 skill 的放置位置和归属：
+
+| 类型 | 路径 | 提交仓库 | provenance |
+|------|------|---------|-----------|
+| **Curated**（人工策划） | `skills/` (repo) | ✅ | 用 frontmatter `origin` 字段 |
+| **Learned**（`/learn` 自动产出） | `~/.claude/skills/learned/` | ❌ | 必须 `.provenance.json` |
+| **Imported**（外部导入） | `~/.claude/skills/imported/` | ❌ | 必须 `.provenance.json` |
+| **Evolved**（instinct 聚类产出） | `~/.claude/homunculus/evolved/skills/` | ❌ | 继承自源 instinct |
+
+`.provenance.json` 必填字段：`source`、`created_at`、`confidence` (0-1)、`author`。
+
+**实操含义**：
+- `/learn` 学到的 skill 自动落到 `~/.claude/skills/learned/` —— 不要手动提交进 repo
+- `validate-skills.js` 只校验 `skills/` 下的 curated skill，忽略其他三类
+- 跨项目分享走 `/instinct-export` + `/instinct-import`，不直接 copy 文件
+
+详见 [docs/SKILL-PLACEMENT-POLICY.md](https://github.com/affaan-m/everything-claude-code/blob/main/docs/SKILL-PLACEMENT-POLICY.md)。
+
+### Token 优化新基线
+
+仓库 `docs/token-optimization.md` 当前推荐配置：
+
+```json
+{
+  "model": "sonnet",
+  "env": {
+    "MAX_THINKING_TOKENS": "10000",
+    "CLAUDE_CODE_SUBAGENT_MODEL": "haiku"
+  }
+}
+```
+
+- **`CLAUDE_CODE_SUBAGENT_MODEL=haiku`** 是新的省钱大头，子 agent 跑 Haiku 比默认便宜约 80%
+- ⚠️ **`CLAUDE_AUTOCOMPACT_PCT_OVERRIDE` 已被官方警告弃用** —— 该变量在新版 Claude Code 上只能让压缩更早触发，与延后目的相反，移除即可
+- `memory` MCP 默认装但无 skill/agent/hook 引用 → 项目级 `disabledMcpServers` 关掉
+
 ---

 ## 精选 Skills（curated subset，非全量）
@@ -302,6 +340,14 @@ Rules 新增：java, kotlin, dart, csharp, cpp, rust, perl, php, web, zh (中文
 ### 循环/自动化
 `/loop-start` `/loop-status` `/model-route` `/quality-gate` `/harness-audit` `/promote` `/claw`

+### 验证 & 会话
+`/checkpoint`(verification-loop 检查点)`/verify`(完整验证管道)`/sessions`(会话历史)`/security-scan`(AgentShield 扫描)
+
+### REPL & 工具
+`/claw`(NanoClaw REPL，模型路由 + 技能热加载 + 会话分支)`/projects`(continuous-learning v2 项目管理)`/setup-pm`(包管理器配置)
+
+> 完整命令 → agent 映射见仓库 [docs/COMMAND-AGENT-MAP.md](https://github.com/affaan-m/everything-claude-code/blob/main/docs/COMMAND-AGENT-MAP.md)。
+
 ---

 ## Hooks 系统
@@ -339,7 +385,11 @@ ECC_DISABLED_HOOKS="pre:bash:tmux-reminder,post:edit:typecheck"
 ### Resources
 - [[Everything Claude Code 方法论与最佳实践]]
 - [[Everything Claude Code 用法速查]]
+<<<<<<< HEAD
+- [[ECC 编排实战手册]] — 6 种编排模式真实命令 + 实战搭配 + 来源标注
+=======
 - [[ECC 编排替代方案 (orchestrate 迁移)]] ← **编排机制全景表**
+>>>>>>> origin/main
 - [[Autonomous Loops 自主循环模式]]
 - [[Autonomous Agent Harness 自主代理框架]]
 - [[dmux 多Agent并行编排]]
--- a/Resources/Claude-Code/Everything
+++ b/Resources/Claude-Code/Everything
@@ -242,15 +242,7 @@ ECC 最独特的创新 — **本能学习系统**。
 # Feature development: start new feature (清除调试噪音)
 ```

-禁用自动压缩的配置:
-
-```json
-{
-  "env": {
-    "CLAUDE_AUTOCOMPACT_PCT_OVERRIDE": "50"
-  }
-}
-```
+> ⚠️ **不要再设 `CLAUDE_AUTOCOMPACT_PCT_OVERRIDE`**。仓库 `docs/token-optimization.md` 现已警告：该变量在新版 Claude Code 上只能"降低阈值"(让压缩**更早**触发)，与延后压缩的目的完全相反。完全靠手动 `/compact` + `strategic-compact` skill 控制压缩时机。

 ### 6. Verification Loop（验证循环）

@@ -316,13 +308,16 @@ ECC 最独特的创新 — **本能学习系统**。
  "model": "sonnet",
  "env": {
    "MAX_THINKING_TOKENS": "10000",
-    "CLAUDE_AUTOCOMPACT_PCT_OVERRIDE": "50"
+    "CLAUDE_CODE_SUBAGENT_MODEL": "haiku"
  }
 }
 // → ~60% 成本降低 (Sonnet vs Opus)
 // → ~70% thinking 成本降低
+// → ~80% 子 agent 成本降低 (Haiku 跑 Task 工具派发的子 agent)
 ```

+⚠️ **不要再设 `CLAUDE_AUTOCOMPACT_PCT_OVERRIDE`** —— 仓库现已警告该变量在新版只会让压缩更早触发，改用手动 `/compact`。
+
 **模型选择策略**:

 | 模型 | 场景 | 能力/成本比 |
@@ -336,7 +331,8 @@ ECC 最独特的创新 — **本能学习系统**。
 - 启用的 MCP <= 10 个，活跃工具总数 <= 80 个
 - 10+ MCP 时，有效上下文从 200K 降至 ~70K tokens
 - 用 `disabledMcpServers` 禁用不用的
- 重操作优先用 CLI（如 `gh`）而不是 MCP
+- **默认安装的 `memory` MCP 没有任何 skill/agent/hook 引用 → 优先关掉**(仓库 `docs/token-optimization.md` 明确建议)
+- 重操作优先用 CLI（如 `gh`、`aws`）而不是 MCP wrapper
 - 使用 `llms.txt` 模式（如 `vercel.com/docs/llms.txt`）代替 MCP 获取文档

 ### 会话管理
--- a/Resources/Claude-Code/Everything
+++ b/Resources/Claude-Code/Everything
@@ -7,7 +7,7 @@ source: "https://github.com/affaan-m/everything-claude-code"

 # Everything Claude Code 用法速查

-按使用场景分类的快速参考手册。组件完整列表见 [[Everything Claude Code 完整指南]]。方法论深度分析见 [[Everything Claude Code 方法论与最佳实践]]。
+按使用场景分类的快速参考手册。组件完整列表见 [[Everything Claude Code 完整指南]]。方法论深度分析见 [[Everything Claude Code 方法论与最佳实践]]。**编排深度实战见 [[ECC 编排实战手册]]**(6 种模式真实命令 + 决策树)。

 > **命名空间**: 通过插件安装的 ECC，命令需加 `everything-claude-code:` 前缀。本文用短名书写，实际使用时如 `/plan` → `/everything-claude-code:plan`。完整映射表见 [[Everything Claude Code 方法论与最佳实践#命令名映射速查]]。

@@ -79,14 +79,32 @@ source: "https://github.com/affaan-m/everything-claude-code"

 ## 三、按高级场景分类

-### 1. 多模型协作
+### 1. 编排模式选择(优先看)
+
+详见 [[ECC 编排实战手册]]。决策树:
+
+| 想要 | 用什么 | 备注 |
+|------|--------|------|
+| 单功能全流程 | `/feature-dev` | 7 阶段:Discovery → Exploration → Clarifying → Architecture → Implementation → Review → Summary |
+| 顺序分步 | `/plan` → `/tdd` → `/code-review` | 最朴素也最稳 |
+| 双评审兜底 | `/santa-loop` | Claude Opus + Codex/Gemini 双独立评审,3 轮收敛 |
+| 多 worktree 并行 | `node scripts/orchestrate-worktrees.js plan.json --execute` | 需 tmux,看 [[dmux 多Agent并行编排]] |
+| 多日 PR 自治 | `continuous-claude` 外部工具 | 不属于 ECC,看 [[Autonomous Loops 自主循环模式]] |
+| 大 RFC + DAG | `ralphinho` 外部工具 | 不属于 ECC |
+| 启动 ECC 内置循环 | `/loop-start [pattern] [--mode safe\|fast]` | pattern: sequential / continuous-pr / rfc-dag / infinite |
+
+> ⚠️ `/orchestrate` 是 **legacy shim**,转发到 `dmux-workflows` skill。新项目优先用 `/feature-dev` 或上面的组合。
+
+### 2. 多模型协作 (需外部 CLI)
+
+⚠️ **`/multi-*` 系列依赖 `~/.claude/bin/codeagent-wrapper` + 外部 codex/gemini CLI**(`ccg` 协议),不是 ECC 标配。装不上就用编排手册里的模式 1-3、5、6 替代。

 | 命令                | 用途                                  |
 | ----------------- | ----------------------------------- |
 | `/multi-plan`     | Claude + Codex + Gemini 并行规划        |
 | `/multi-execute`  | 跨多个模型后端并行执行                         |
-| `/multi-frontend` | 多前端框架并行开发（React/Vue/Svelte/Angular） |
-| `/multi-backend`  | 多后端栈并行开发（Node/Python/Go/Java）       |
+| `/multi-frontend` | 多前端框架并行开发(React/Vue/Svelte/Angular) |
+| `/multi-backend`  | 多后端栈并行开发(Node/Python/Go/Java)       |
 | `/multi-workflow` | 复杂多服务编排                             |

 ### 2. 自主循环
@@ -163,10 +181,13 @@ source: "https://github.com/affaan-m/everything-claude-code"
 | 更新文档 | `/update-docs` |
 | 审查 Python 代码 | `/python-review` |
 | 审查 Go 代码 | `/go-review` |
-| 多模型并行出方案 | `/multi-plan` |
+| 多模型并行出方案 | `/multi-plan`(需外部 CLI) |
 | 启动自主循环 | `/loop-start` |
 | 评估 harness 质量 | `/harness-audit` |
 | 从会话中学习模式 | `/learn` |
+| 单功能全流程一条龙 | `/feature-dev` |
+| 上线前对抗式双评审 | `/santa-loop` |
+| 多任务 worktree 并行 | `node scripts/orchestrate-worktrees.js plan.json --execute` |

 ---

@@ -175,6 +196,11 @@ source: "https://github.com/affaan-m/everything-claude-code"
 ### Resources
 - [[Everything Claude Code 完整指南]]
 - [[Everything Claude Code 方法论与最佳实践]]
+- [[ECC 编排实战手册]]
+- [[ECC 编排替代方案 (orchestrate 迁移)]]
+- [[Autonomous Loops 自主循环模式]]
+- [[dmux 多Agent并行编排]]
+- [[Ralphinho RFC-DAG 编排模式]]

 ### Zettelkasten
 - [[Everything Claude Code 最佳实践]]
--- a/Zettelkasten/20260308213000
+++ b/Zettelkasten/20260308213000
@@ -20,9 +20,13 @@ source: "https://github.com/affaan-m/everything-claude-code"
 90% 任务用 Sonnet，只在架构决策和安全分析时用 Opus，搜索探索用 Haiku。设置：

 ```json
-{ "model": "sonnet", "env": { "MAX_THINKING_TOKENS": "10000", "CLAUDE_AUTOCOMPACT_PCT_OVERRIDE": "50" } }
+{ "model": "sonnet", "env": { "MAX_THINKING_TOKENS": "10000", "CLAUDE_CODE_SUBAGENT_MODEL": "haiku" } }
 ```

+`CLAUDE_CODE_SUBAGENT_MODEL=haiku` 是省钱新核心 —— 子 agent(通过 Task 工具派发的)跑 Haiku，比默认便宜约 80%，文件读取/探索质量基本无损。
+
+> ⚠️ **不要再设 `CLAUDE_AUTOCOMPACT_PCT_OVERRIDE`**。仓库 `docs/token-optimization.md` 已警告：该变量在新版 Claude Code 上只能"降低阈值"(让压缩更早触发)，与延后压缩的目的相反。改用手动 `/compact` + `strategic-compact` skill。
+
 用 mgrep 替代 grep 可减少约 50% token 使用。

 ## 记忆持久化
--- a/Zettelkasten/20260308213200
+++ b/Zettelkasten/20260308213200
@@ -12,9 +12,12 @@ source: "https://github.com/affaan-m/everything-claude-code"
 ### 1. 模型路由
 90% 任务用 Sonnet，Haiku 做搜索/文档，Opus 只用于架构和安全。用 `/model-route` 自动路由。

+**子 agent 强制用 Haiku** —— 设置 `CLAUDE_CODE_SUBAGENT_MODEL=haiku`，所有通过 Task 工具派发的子 agent 都跑 Haiku，比默认便宜约 80%，文件读取/探索质量基本无损。这是新版的省钱大头。
+
 ### 2. MCP 精简
 - 保持 < 10 个 MCP 启用
- 用 CLI + skill 替代 MCP wrapper（如 gh CLI 替代 GitHub MCP）
+- 用 CLI + skill 替代 MCP wrapper（如 `gh` 替代 GitHub MCP、`aws` 替代 AWS MCP）
+- 默认安装的 `memory` MCP 没有任何 skill/agent/hook 引用 → 优先关掉
 - 每个 MCP 消耗上下文窗口，多到一定程度 200k 变 70k

 ### 3. 工具替换
@@ -30,11 +33,13 @@ mgrep 替代 grep/ripgrep，在 50 任务 benchmark 中减少约 2x token 使用
  "model": "sonnet",
  "env": {
    "MAX_THINKING_TOKENS": "10000",
-    "CLAUDE_AUTOCOMPACT_PCT_OVERRIDE": "50"
+    "CLAUDE_CODE_SUBAGENT_MODEL": "haiku"
  }
 }
 ```

+> ⚠️ **不要再设 `CLAUDE_AUTOCOMPACT_PCT_OVERRIDE`**。仓库 `docs/token-optimization.md` 已警告：该变量在新版 Claude Code 上只能"降低阈值"(让压缩更早触发)，与延后压缩的目的相反。改用手动 `/compact` + `strategic-compact` skill 控制压缩时机。
+
 ## Skill 的渐进式加载

 Skill 启动时只读描述（约 100 tokens），只在相关时才加载完整内容。这比把所有内容放在 CLAUDE.md 系统提示中高效得多。
--- a/MCP数量与上下文窗口的反比关系.md
+++ b/MCP数量与上下文窗口的反比关系.md
@@ -15,7 +15,8 @@ source: "https://github.com/affaan-m/everything-claude-code"
 **最佳实践**:
 - 活跃 MCP <= 10 个，活跃工具总数 <= 80 个
 - 用 `disabledMcpServers` 动态禁用不用的
- 重操作优先用 CLI（如 `gh`）而不是 MCP
+- **默认安装的 `memory` MCP 没有任何 skill/agent/hook 引用 → 优先关掉**(仓库 `docs/token-optimization.md` 明确建议)
+- 重操作优先用 CLI（如 `gh`、`aws`）而不是 MCP wrapper
 - 使用 `llms.txt` 模式获取文档，避免 MCP 常驻开销

 这是 Claude Code 性能优化中**最重要的单一因素** — 比任何 Agent 或 Skill 都重要。
--- a/Untitled.canvas
+++ b/Untitled.canvas
@@ -0,0 +1 @@
+{}
--- a/conflict-files-obsidian-git.md
+++ b/conflict-files-obsidian-git.md
@@ -0,0 +1,17 @@
+# Conflicts
+Please resolve them and commit them using the commands `Git: Commit all changes` followed by `Git: Push`
+(This file will automatically be deleted before commit)
+[[#Additional Instructions]] available below file list
+
+- [[Everything Claude Code 完整指南]]
+
+# Additional Instructions
+I strongly recommend to use "Source mode" for viewing the conflicted files. For simple conflicts, in each file listed above replace every occurrence of the following text blocks with the desired text.
+
+```diff
+<<<<<<< HEAD
+    File changes in local repository
+=======
+    File changes in remote repository
+>>>>>>> origin/main
+```