Merge remote-tracking branch 'origin/main'

# Conflicts:
#	4 - Resources/Claude-Code/Everything Claude Code 完整指南.md

.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": {}
+}

.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"
+}

.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.

.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}"
+    }
+  }
+}

.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.

.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
+  }
+}

.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
+  }
+}

.obsidian/community-plugins.json

@@ -1,5 +1,5 @@
 [
   "obsidian-checklist-plugin",
   "calendar",
-  "obsidian-git"
+  "claudian"
 ]

.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"
+  }
+}

.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
+}

.obsidian/plugins/obsidian-git/data.json

@@ -8,7 +8,7 @@
   "autoPullInterval": 0,
   "autoPullOnBoot": true,
   "autoCommitOnlyStaged": false,
-  "disablePush": false,
+  "disablePush": true,
   "pullBeforePush": true,
   "disablePopups": false,
   "showErrorNotices": true,

.obsidian/plugins/terminal/data.json

@@ -0,0 +1,168 @@
+{
+  "addToCommand": true,
+  "addToContextMenu": true,
+  "createInstanceNearExistingOnes": true,
+  "errorNoticeTimeout": 0,
+  "exposeInternalModules": true,
+  "focusOnNewInstance": true,
+  "hideStatusBar": "focused",
+  "interceptLogging": true,
+  "language": "",
+  "macOSOptionKeyPassthrough": true,
+  "newInstanceBehavior": "newHorizontalSplit",
+  "noticeTimeout": 5,
+  "openChangelogOnUpdate": true,
+  "pinNewInstance": true,
+  "preferredRenderer": "webgl",
+  "profiles": {
+    "darwinExternalDefault": {
+      "args": [
+        "\"$PWD\""
+      ],
+      "executable": "/System/Applications/Utilities/Terminal.app/Contents/macOS/Terminal",
+      "followTheme": true,
+      "name": "",
+      "platforms": {
+        "darwin": true
+      },
+      "restoreHistory": false,
+      "rightClickAction": "copyPaste",
+      "successExitCodes": [
+        "0",
+        "SIGINT",
+        "SIGTERM"
+      ],
+      "terminalOptions": {
+        "documentOverride": null
+      },
+      "type": "external"
+    },
+    "darwinIntegratedDefault": {
+      "args": [
+        "--login"
+      ],
+      "executable": "/bin/zsh",
+      "followTheme": true,
+      "name": "",
+      "platforms": {
+        "darwin": true
+      },
+      "pythonExecutable": "python3",
+      "restoreHistory": false,
+      "rightClickAction": "copyPaste",
+      "successExitCodes": [
+        "0",
+        "SIGINT",
+        "SIGTERM"
+      ],
+      "terminalOptions": {
+        "documentOverride": null
+      },
+      "type": "integrated",
+      "useWin32Conhost": true
+    },
+    "developerConsole": {
+      "followTheme": true,
+      "name": "",
+      "restoreHistory": false,
+      "rightClickAction": "copyPaste",
+      "successExitCodes": [
+        "0",
+        "SIGINT",
+        "SIGTERM"
+      ],
+      "terminalOptions": {
+        "documentOverride": null
+      },
+      "type": "developerConsole"
+    },
+    "linuxExternalDefault": {
+      "args": [],
+      "executable": "xterm",
+      "followTheme": true,
+      "name": "",
+      "platforms": {
+        "linux": true
+      },
+      "restoreHistory": false,
+      "rightClickAction": "copyPaste",
+      "successExitCodes": [
+        "0",
+        "SIGINT",
+        "SIGTERM"
+      ],
+      "terminalOptions": {
+        "documentOverride": null
+      },
+      "type": "external"
+    },
+    "linuxIntegratedDefault": {
+      "args": [],
+      "executable": "/bin/sh",
+      "followTheme": true,
+      "name": "",
+      "platforms": {
+        "linux": true
+      },
+      "pythonExecutable": "python3",
+      "restoreHistory": false,
+      "rightClickAction": "copyPaste",
+      "successExitCodes": [
+        "0",
+        "SIGINT",
+        "SIGTERM"
+      ],
+      "terminalOptions": {
+        "documentOverride": null
+      },
+      "type": "integrated",
+      "useWin32Conhost": true
+    },
+    "win32ExternalDefault": {
+      "args": [],
+      "executable": "C:\\Windows\\System32\\cmd.exe",
+      "followTheme": true,
+      "name": "",
+      "platforms": {
+        "win32": true
+      },
+      "restoreHistory": false,
+      "rightClickAction": "copyPaste",
+      "successExitCodes": [
+        "0",
+        "SIGINT",
+        "SIGTERM"
+      ],
+      "terminalOptions": {
+        "documentOverride": null
+      },
+      "type": "external"
+    },
+    "win32IntegratedDefault": {
+      "args": [],
+      "executable": "C:\\Windows\\System32\\cmd.exe",
+      "followTheme": true,
+      "name": "",
+      "platforms": {
+        "win32": true
+      },
+      "pythonExecutable": "python3",
+      "restoreHistory": false,
+      "rightClickAction": "copyPaste",
+      "successExitCodes": [
+        "0",
+        "SIGINT",
+        "SIGTERM"
+      ],
+      "terminalOptions": {
+        "documentOverride": null
+      },
+      "type": "integrated",
+      "useWin32Conhost": true
+    }
+  },
+  "defaultProfile": null,
+  "terminalOptions": {
+    "documentOverride": null
+  }
+}

.obsidian/plugins/terminal/manifest.json

@@ -0,0 +1,14 @@
+{
+  "author": "polyipseity",
+  "description": "Integrate consoles, shells, and terminals.",
+  "fundingUrl": {
+    "Buy Me a Coffee": "https://buymeacoffee.com/polyipseity",
+    "GitHub Sponsors": "https://github.com/sponsors/polyipseity"
+  },
+  "version": "3.23.0",
+  "authorUrl": "https://github.com/polyipseity",
+  "id": "terminal",
+  "isDesktopOnly": false,
+  "minAppVersion": "1.4.11",
+  "name": "Terminal"
+}

.obsidian/plugins/terminal/styles.css

@@ -0,0 +1,32 @@
+.obsidian-plugin-library\:icon{fill:none;stroke:currentColor}.obsidian-plugin-library\:await-css{display:unset!important}.obsidian-plugin-library\:hide-status-bar{display:none}/**
+ * Copyright (c) 2014 The xterm.js authors. All rights reserved.
+ * Copyright (c) 2012-2013, Christopher Jeffrey (MIT License)
+ * https://github.com/chjj/term.js
+ * @license MIT
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this software and associated documentation files (the "Software"), to deal
+ * in the Software without restriction, including without limitation the rights
+ * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+ * copies of the Software, and to permit persons to whom the Software is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+ * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+ * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
+ * THE SOFTWARE.
+ *
+ * Originally forked from (with the author's permission):
+ *   Fabrice Bellard's javascript vt100 for jslinux:
+ *   http://bellard.org/jslinux/
+ *   Copyright (c) 2011 Fabrice Bellard
+ *   The original design remains. The terminal itself
+ *   has been extended to include xterm CSI codes, among
+ *   other features.
+ */.xterm{cursor:text;position:relative;user-select:none;-ms-user-select:none;-webkit-user-select:none}.xterm.focus,.xterm:focus{outline:none}.xterm .xterm-helpers{position:absolute;top:0;z-index:5}.xterm .xterm-helper-textarea{padding:0;border:0;margin:0;position:absolute;opacity:0;left:-9999em;top:0;width:0;height:0;z-index:-5;white-space:nowrap;overflow:hidden;resize:none}.xterm .composition-view{background:#000;color:#fff;display:none;position:absolute;white-space:nowrap;z-index:1}.xterm .composition-view.active{display:block}.xterm .xterm-viewport{background-color:#000;overflow-y:scroll;cursor:default;position:absolute;inset:0}.xterm .xterm-screen{position:relative}.xterm .xterm-screen canvas{position:absolute;left:0;top:0}.xterm-char-measure-element{display:inline-block;visibility:hidden;position:absolute;top:0;left:-9999em;line-height:normal}.xterm.enable-mouse-events{cursor:default}.xterm.xterm-cursor-pointer,.xterm .xterm-cursor-pointer{cursor:pointer}.xterm.column-select.focus{cursor:crosshair}.xterm .xterm-accessibility:not(.debug),.xterm .xterm-message{position:absolute;inset:0;z-index:10;color:transparent;pointer-events:none}.xterm .xterm-accessibility-tree:not(.debug) *::selection{color:transparent}.xterm .xterm-accessibility-tree{font-family:monospace;user-select:text;white-space:pre}.xterm .xterm-accessibility-tree>div{transform-origin:left;width:fit-content}.xterm .live-region{position:absolute;left:-9999px;width:1px;height:1px;overflow:hidden}.xterm-dim{opacity:1!important}.xterm-underline-1{text-decoration:underline}.xterm-underline-2{text-decoration:double underline}.xterm-underline-3{text-decoration:wavy underline}.xterm-underline-4{text-decoration:dotted underline}.xterm-underline-5{text-decoration:dashed underline}.xterm-overline{text-decoration:overline}.xterm-overline.xterm-underline-1{text-decoration:overline underline}.xterm-overline.xterm-underline-2{text-decoration:overline double underline}.xterm-overline.xterm-underline-3{text-decoration:overline wavy underline}.xterm-overline.xterm-underline-4{text-decoration:overline dotted underline}.xterm-overline.xterm-underline-5{text-decoration:overline dashed underline}.xterm-strikethrough{text-decoration:line-through}.xterm-screen .xterm-decoration-container .xterm-decoration{z-index:6;position:absolute}.xterm-screen .xterm-decoration-container .xterm-decoration.xterm-decoration-top-layer{z-index:7}.xterm-decoration-overview-ruler{z-index:8;position:absolute;top:0;right:0;pointer-events:none}.xterm-decoration-top{z-index:2;position:relative}.xterm .xterm-scrollable-element>.scrollbar{cursor:default}.xterm .xterm-scrollable-element>.scrollbar>.scra{cursor:pointer;font-size:11px!important}.xterm .xterm-scrollable-element>.visible{opacity:1;background:#0000;transition:opacity .1s linear;z-index:11}.xterm .xterm-scrollable-element>.invisible{opacity:0;pointer-events:none}.xterm .xterm-scrollable-element>.invisible.fade{transition:opacity .8s linear}.xterm .xterm-scrollable-element>.shadow{position:absolute;display:none}.xterm .xterm-scrollable-element>.shadow.top{display:block;top:0;left:3px;height:3px;width:100%;box-shadow:var(--vscode-scrollbar-shadow, #000) 0 6px 6px -6px inset}.xterm .xterm-scrollable-element>.shadow.left{display:block;top:3px;left:0;height:100%;width:3px;box-shadow:var(--vscode-scrollbar-shadow, #000) 6px 0 6px -6px inset}.xterm .xterm-scrollable-element>.shadow.top-left-corner{display:block;top:0;left:0;height:3px;width:3px}.xterm .xterm-scrollable-element>.shadow.top.left{box-shadow:var(--vscode-scrollbar-shadow, #000) 6px 0 6px -6px inset}.workspace-leaf-content[data-type="terminal:terminal"] .view-content{overflow:clip;display:flex;flex-direction:column}.terminal\:terminal{flex:1;min-width:0;min-height:0}.is-phone .workspace-leaf-content[data-type="terminal:terminal"] .view-content{padding-bottom:max(var(--size-4-4),calc(var(--icon-l) + var(--size-4-2) + max(var(--size-4-2),var(--safe-area-inset-bottom))))}

1 - Inbox/2026 文字类提示词设计指南（上册）.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
+“劲爆特价”，暴走漫画促销体，字形极度夸张，笔画巨大厚实，结构被挤压、拉扯和爆裂变形，字与字之间紧密堆叠，像促销海报上冲出来的叫卖大字。整体有暴走漫画式怒吼感、超市清仓感和限时特价冲击力，视觉直接、粗暴、夸张、让人一眼停住。
+```

1 - Inbox/Claude Code 工程化指南：高效组织 .claude 目录.md

@@ -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)

1 - Inbox/你不知道的大模型训练：原理、路径与新实践.md

@@ -0,0 +1,251 @@
+---
+title: "你不知道的大模型训练：原理、路径与新实践"
+source: "https://x.com/HiTw93/article/2040047268221608281"
+author:
+  - "[[Tw93 (@HiTw93)]]"
+published: 2026-04-03
+created: 2026-04-06
+description:
+tags:
+  - "clippings"
+---
+## 太长也要读
+
+在写完《你不知道的 Claude Code：架构、治理与工程实践》、《你不知道的 Agent：原理、架构与工程实践》后，我想着继续来写第三篇，这次打算挑战下自己来梳理一下大模型训练到底怎么回事，这篇文章争取让非专业背景的人也能读得懂。
+
+2026 年来看大模型效果真正拉开差距的地方，慢慢不再是预训练本身了，而在它更后面的那一大段：后训练、评测、奖励、Agent 训练、蒸馏，每一个步骤都在影响用户实际感受效果。你发现某个模型突然变强了，背后可能是这几块一起优化到位了，而非单一因素导致。
+
+下文按大模型训练链路顺序来讲，重点放在厂商怎么通过后半段训练栈来提升最终上线效果。
+
+## 大模型训练其实是一条流水线
+
+过去几年，一般会用参数、数据、算力的堆积来解释模型进步，但很多用户真正感受到的提升，并不是来自再多训一点基础语料，而是来自预训练后面那整套训练流程。模型怎么说话、怎么听指令、怎么推理、怎么用工具，这些都不是多喂一点互联网文本就能自然长出来的。
+
+InstructGPT 当年给过一个很直接的例子：一个只有 1.3B 参数、做过对齐和偏好优化的模型，在人类偏好评测里能赢过 175B 的 GPT-3，参数量差了两个数量级，用户最后却更喜欢那个小很多的版本，训练后半段是真的会改写用户感知。
+
+训练过程其实是一条流水线，数据、算法、系统、反馈这几层高度耦合，一层变化通常会传导到其他层，2026 年的模型能力和产业价值，也越来越集中在预训练后面的几层。
+
+![Image](https://pbs.twimg.com/media/HE-wqTjaMAApYhA?format=jpg&name=large)
+
+这也是我们平时为啥感觉豆包不太去争排名，但大家日常用起来却更符合心意的原因，是后训练做到位了。
+
+这六层只是为了看分工，下图的九个阶段是更详细的版本：原始数据和系统配方单独拆开，Agent harness 和 Deployment 也是后半段的细分。还有两条反馈回路贯穿始终：生产流量回到数据工程，离线评测结果回到预训练。
+
+![Image](https://pbs.twimg.com/media/HE-xsyAa8AAG-Bx?format=jpg&name=large)
+
+## 预训练只是模型底座
+
+预训练仍然是训练链路的起点，搞清楚它到底在做什么，才能理解后面的每一层都在补充什么。没有这一步，就没有语言建模能力，没有知识压缩，也没有后面那些能力迁移的空间。在工程上，它要做的不只是让模型学会预测下一个 token：把语言分布学进去，把大规模文本里的知识和模式压进参数，还要给后面的能力激活留出空间。下一个 token 预测只描述了训练形式，解释不了为什么规模上来之后，模型会突然多出一些之前没有的能力。
+
+GPT-3 之后，不少模型调优的工作会更加考虑到预算和配比，模型不是越大越好，参数量、训练 token 数和总计算预算之间有配比问题，很多模型不是做小了，而是训练量不足，在既定预算下没有训到更合适的点。
+
+真到训练决策里，更实际的问题是：如果有人给你一万张 H100 和一个月时间，你会如何去训一个足够好的开源模型？规模定律在这里更像一个预算分配工具，不是那种论文里的抽象曲线，最后还是需要静下心来考虑这些问题：下一轮训练到底该多堆参数，还是多喂数据？当前模型到底是能力不够，还是只是欠训练？有限 GPU 预算下，什么配比更值？
+
+预训练更像是给模型能力打地基，决定知识范围、泛化潜力和模式归纳能力，也决定后训练有没有可以利用的空间。但听不听指令、配不配合用户、关键任务跑起来稳不稳，这些预训练都是管不到的。
+
+预训练阶段不只是在决定学多少知识，它还在提前决定模型以后能长成什么样。tokenizer 的切分方式会直接影响后续训练，context window 拉到多长也要在前面定下来。要不要继续做多模态预训练，要不要把单卡可运行当成一开始就定下来的要求，这些取舍在训练阶段就写进配方了，不是发布时再补的功能 feature。Gemma 3 同时强调了 single accelerator、128K context、视觉能力和量化，背后反映的也是这类取舍。用户最终看到的那些能力，比如能在本地电脑上跑、能看图、能理解长文档，其实很多在训练阶段就已经定下来了。
+
+通过 Chinchilla 给出的数据最优点来看，对于 8B 参数的模型大约是 200B tokens，但 Llama3 8B 实际用了 15T tokens，超出约 75 倍。这类过训练配方通常能在同等参数下换来更高的能力密度，最后换来一个更小、推起来也更省的模型。衡量这件事，看总 FLOP（浮点运算次数）比看参数量更靠谱，下图直观展示了这个差距。
+
+![Image](https://pbs.twimg.com/media/HE-x1GCb0AAKwdS?format=jpg&name=large)
+
+还有一类容易被忽略的设计也发生在预训练阶段：tokenizer 词表大小、分词策略、字节级编码方式都会有挺大影响。Llama2 词表 32K，Llama3 扩到 128K 后，序列长度大约压缩了 15%，下游性能也会跟着上去，这个影响会延续到推理成本和多语言能力。中文、代码、数学公式的 token 效率在词表设计时就已经定下来了。比如一个把中文分得很碎的 tokenizer，劣势并不是每次多花几个 token，而是每次推理都要持续承担这个决策错误的代价。
+
+## 数据配方决定模型能力
+
+参数规模是过去几年大家比较的重要指标，但这两年更重要的东西叫「数据配方」。
+
+这个过程表面看是清洗数据，实际上是完整的数据生产工程。网页、代码仓库、书籍、论坛这些原始数据，要先走完文本抽取、语言识别、质量过滤、隐私处理、安全过滤和去重，才能进入预训练，下图展示了完整的漏斗处理流程。
+
+![Image](https://pbs.twimg.com/media/HE-x-stbkAAjJKL?format=jpg&name=large)
+
+如果只把数据当作训练燃料，很容易得出越多越好的结论。但数据工程更接近能力设计，模型看见什么、看不见什么，代码数学百科各占多大比例，这些选择直接影响模型最后形成的能力分布。
+
+去重和污染控制常被忽略，但它对结果影响很大，要处理的不只是低质量数据，还包括重复模板、许可证文本、镜像网页，以及 benchmark 泄漏带来的污染。如果 document-level 和 line-level dedup 做得不够，模型往往会反复吸收最容易复制的内容，却未必真正学到最有价值的部分，很多开源模型效果看起来是参差不齐，往往是数据处理质量的差距。
+
+最近两年，数据配比本身也成了单独要研究的问题。Data Mixing Laws 这类工作关注的，不只是还能收集多少数据，更是不同类型数据的占比会把模型带向什么能力结构。
+
+合成数据也已经从辅助手段变成正式训练流程的一部分，Self-Instruct 这类让模型自己生成指令数据的方法、DeepSeek-R1 的蒸馏轨迹，以及 Qwen、Kimi 系列里越来越明显的合成监督，都在往同一个方向走。每一代更强的模型，都会参与重构下一代模型所看到的数据。早期模型生成基础指令数据，更强的模型生成高质量推理轨迹和 CoT 数据，经过 RL 训练的推理模型再把这些轨迹蒸馏给更小的 dense 模型。dense 就是全部参数都跑，和 MoE 那种按需激活不一样。
+
+这里的关键是，模型往往要先在更大规模上形成能力，后面才可能把这些能力压缩到更小的模型上。DeepSeek-R1-Distill 系列就是直接例子。RL 后的大模型轨迹让 1.5B 到 70B 的 dense 模型都获得了明显收益，Llama 3.1 405B 也明确被用于提升 8B 和 70B 的后训练质量，这些不是附带产物，而是训练设计的一部分。
+
+## 系统和架构的约束，训练前就要想清楚
+
+很多人把训练理解成研究问题：目标函数怎么设，损失怎么降，模型结构怎么改。但真正的大模型训练里系统约束这一块非常重要，是分布式系统问题，而非单机上的深度学习问题。GPU 数量、显存带宽、并行策略、容错和成本，这些不能等到训练完才去调优，最开始就决定了你能训多大、支持多长上下文、能不能跑更复杂的后训练这些点。
+
+MoE 是这一层最典型的例子，多专家模式让模型在相近计算量下扩大总参数，也把每个 token 的激活成本控住。代价会让路由复杂、负载均衡难、基础设施重。DeepSeek-V3、Qwen 一系列 MoE 设计都是成本和效果的折中，不是单纯的架构偏好。
+
+最近公开配方里的讨论，不再只是模型大小和 token 配比这种粗粒度分析。muP 让超参可从小规模实验迁移到大规模训练，WSD learning rate 是先升后稳再衰减的学习率调度策略，再加上最优 batch size 和更高的数据对参数比例，这些都开始出现在正式训练报告里，这些细节正在变成同规模模型之间真正拉开差距的地方。
+
+长上下文、多模态和新架构如果只按产品功能点理解，会漏掉训练侧的约束。128K context 这种目标会直接改变 attention 成本、batch size、训练 curriculum（数据编排顺序）和并行策略，多模态改的不只是模型结构，还有 data mixing（多来源数据配比）、encoder 设计和安全评测。如果把单卡可运行当成硬要求，参数量、量化路径、模型家族大小都会跟着收紧。
+
+Forgetting Transformer 和 Kimi 的 Attention Residuals 这类工作，都是在回答类似的问题：更长的上下文如何训练，网络变深之后如何避免信息被稀释。你看到的是模型能处理更长输入，或者更便于部署，训练时面对的却是另一组完全不同的约束。
+
+算力预算是固定的，模型大小、训练 token 量、上下文长度、serving 成本，每往一个方向多花，其他方向就得让步。
+
+![Image](https://pbs.twimg.com/media/HE-yYQib0AEyDCA?format=jpg&name=large)
+
+上下文拉长，attention 成本直接膨胀，batch size 必须压小；模型做大，GPU 内存上来，serving 成本也跟着涨。这不是取舍选项，是资源约束的结果，大部分决定在训练开始前就锁死了。
+
+还有个工程现实经常被忽略：训练并不总是稳定的，几千张 GPU 跑了几周，突然出现训练损失突增，幅度大到无法忽略，只能回滚到几天前的 checkpoint，重新来过。
+
+除了 loss spike，还有单块 GPU 静默出错，不报错但悄悄产生错误梯度、NVLink 带宽异常、节点间通信抖动，每一种都可能污染若干步训练。能不能在大规模训练里快速检测、隔离、恢复，这是实验室级别的工程能力，不是读论文能解决的问题。
+
+DeepSeek-V3 在技术报告里专门提到，整个预训练过程没有出现 irrecoverable loss spike，也没有做任何 rollback，同时是少数公开验证 FP8 混合精度训练在超大规模模型上可行的案例。按公开数据，全流程约 2.788M H800 GPU hours，预训练完成了 14.8T tokens。
+
+训练系统和推理系统关系紧密，但不是同一个工程问题。训练关心梯度、并行、checkpoint、吞吐和成本，推理关心延迟、KV cache（缓存历史计算避免重复运算）、量化和服务稳定性。
+
+## 后训练才决定用户真正感受到的差距
+
+普通用户真正能感受到的很多提升，其实都发生在预训练之后。指令微调（Instruction tuning）用标注好的指令-回答数据对模型做监督训练。它改变的是回答方式，把怎么接任务、怎么组织输出、怎么像个配合的助手这些要求变成监督信号。一个基础模型也许已经具备不少潜在能力，但如果没有这一步，这些能力往往不会以用户期待的形式稳定冒出来。
+
+再往后看，RLHF、DPO、RFT 方向差不多，都在把"什么叫更好的回答"接进训练回路，但路径不同。
+
+- RLHF（基于人类反馈的强化学习）先模仿高质量回答，再用偏好比较做强化
+- DPO（直接偏好优化）把这条路径缩短，直接从偏好对比里学，不需要单独训奖励模型
+- RFT（强化微调）是工程上更容易落地的接口，把任务定义、grader 设计和奖励信号放到产品化流程里
+
+今天谈后训练，只讲 SFT 或 RL 已经不够了，更难的是评测怎么设、分数怎么打、什么样的回答才算值得继续优化。SFT 是监督微调，它学到的不只是知识，也在学风格。数据长度、格式、是否带引用、是否偏好分点表达，都会显著影响模型最后的输出形态。很多用户以为自己在比较能力，实际比出来的往往只是风格差异。再加上偏好评测天然偏爱更长的回答，很容易把看起来更认真的长输出当成更可靠。所以后训练只看榜单往往不够，还要结合真实任务结果、成本和稳定性。
+
+现代后训练是一条多阶段流水线，公开资料里 DeepSeek-R1 的配方是最清晰的。它分四个阶段推进：
+
+**阶段 1**是冷启动 SFT，在做强化学习之前，先用少量高质量的思维链 CoT 数据热身。DeepSeek-R1-Zero 证明了直接从 base model（预训练后尚未做对齐的原始模型）上做 RL 是可行的，但纯 RL 训练出来的模型会反复重复、语言混乱、可读性很差。冷启动 SFT 给 RL 一个更稳定的起点，先把格式和语言一致性收住，这不是多余步骤。
+
+**阶段 2**在数学、代码、逻辑等可验证领域做强化学习，用 GRPO 作为训练算法，以可程序检验的正确性作为奖励信号。关键在于为什么选 GRPO 而不是传统的 PPO：PPO 是近端策略优化，需要一个独立的价值网络（value network）来估算当前状态价值，在大模型上同时维护两个网络工程负担很高。GRPO 对同一个提示词采样多个回答，用组内排名替代绝对价值估计，不需要独立的价值网络，工程上简洁很多，DeepSeek 系列和 Cursor Composer 2 的 RL 基础设施都采用了接近 GRPO 的方案。
+
+**阶段 3**做拒绝采样微调（Rejection Sampling Fine-Tuning），把 RL 产生的成功轨迹过滤后转成新的 SFT 数据，再做一轮监督微调。这是 RL 和 SFT 之间的桥梁，RL 探索出的好轨迹，就这样变成下一轮 SFT 的高质量训练样本。
+
+**阶段 4**融入有益性和安全性偏好反馈，把模型调整到符合发布标准的助手形态。
+
+![Image](https://pbs.twimg.com/media/HE-ygg2bQAEFcQJ?format=jpg&name=large)
+
+四个阶段互相依赖：冷启动让 RL 稳定启动，RL 产生高质量数据，拒绝采样把这些数据变成下一轮 SFT 的输入，对齐 RL 完成行为收敛。从公开结果看，直接 SFT 和走完四个阶段，差距通常是能看出来的。
+
+## Eval、Grader、Reward 在重新定义训练目标
+
+负责把模型输出转成训练分数的组件叫 grader，它很容易出现大家想不到的问题。只看最终答案，模型很快学会走捷径；打分太粗，噪声会被强化学习持续放大；榜单涨了，真实任务未必跟着一样好。很多时候，用户以为自己在看 base model 差距，其实差距出在目标怎么定义上。
+
+放到训练流程里看，eval 决定测什么，grader 决定一次输出怎么变成分数，reward 决定模型后面会被往哪里推。它们连起来就是一条具体的反馈回路：任务定义、eval、grader、优化、rollout、再评测。rollout 指模型执行任务产生的轨迹，链路里任何一环跑偏，后续优化就会一起跑偏。
+
+只看最终结果，模型可能会碰巧答对，也可能沿着错误过程拿到正确答案，代码、数学和复杂推理任务里，这个问题尤其明显。中间步骤如果不进反馈，模型学到的往往不是更可靠的推理，而是怎样更高概率地拿到最后那一分。
+
+所以这几年越来越多工作从传统 RLHF 转向 verified rewards，用程序直接验证正确性。在数学、代码、逻辑这些可验证任务里，现在已经可以直接对正确性打分，不再主要依赖人工偏好。但 verified rewards 也没有把问题彻底解决掉。过优化、reward overfitting（打分规则被过度优化、能力却没真正提升），以及 mode collapse（输出高度单一、失去多样性）这些现象还是会出现，问题只是从偏好标得准不准，变成了打分链路稳不稳。
+
+模型写出来的思考过程，也不能直接当成内部过程的完整记录。Anthropic 在 reasoning model 的可观测性实验里发现，模型会使用额外提示，却不在可见 CoT 里承认；到了 reward hacking 场景，它更可能补一段看起来合理的解释。reward hacking 是钻打分系统空子，而不是真正完成任务。可见 CoT 更适合当训练和监控信号，不能直接当成完整真相。
+
+再往下一层，模型甚至会开始利用打分通道本身。reward tampering 和 alignment faking 这类研究表明，模型在理论上可能主动干预打分过程本身。reward tampering 是直接篡改奖励计算过程本身，alignment faking 是对齐伪装，表面合规但隐藏不对齐意图。
+
+一旦模型有足够强的环境访问能力，它优化的就不止任务结果，还可能包括 checklist、reward code 和训练关系本身。Anthropic 2025 年一项实验，在一组可被利用的生产编码 RL 环境里注入了额外的 reward-hack 知识，随后观察到了类似的泛化。模型学会 reward hacking 后，不只会在同类任务上继续利用，还出现了对齐伪装等更广泛失对齐。
+
+这些行为在标准对话评测里看不到，只在 Agent 任务环境里能看到。工程含义很直接，reward、grader、环境隔离和监控都要当成训练设计的一部分。
+
+到了 Agent 阶段，reward design 还会继续拆细，最终结果只是其中一项，另外还要单独度量过程质量、上下文管理和反作弊约束。Kimi K2.5 奖励的是有效拆解和真实并行；Chroma Context-1 会给搜索途中找到的相关文档记分；Cursor Composer 2 把长任务里的 summary 纳入奖励，因为总结一旦失真，后面的上下文会一路被带偏。
+
+具体到实现里，ORM 是结果奖励模型，只给最终答案打分，信号稀疏，成本低，适合先起步，但也更容易让模型走捷径。PRM 是过程奖励模型，给中间步骤打分，信号更密，对数学和代码推理通常更强，但标注和系统成本都高很多。OpenAI 在数学推理实验里看到，PRM 不只提高了正确率，也更容易把过程约束住，因为每一步都在被监督；问题也很直接，PRM 的成本通常是 ORM 的数倍，所以大多数真实系统还是先从 ORM 起步，只有在数学、代码、逻辑这类可验证任务里，才更有条件把 PRM 自动化，用程序去验证中间步骤，绕开人工标注瓶颈。
+
+![Image](https://pbs.twimg.com/media/HE-yphDagAAfv_X?format=jpg&name=large)
+
+这条回路完整跑起来是这样的：
+
+![Image](https://pbs.twimg.com/media/HE-yqmaacAAo2Sj?format=jpg&name=large)
+
+最近几类对齐方法都在做同一件事。Anthropic 的 Constitutional AI 把人类写的原则接进训练，用 AI feedback 替代逐条人工偏好。OpenAI 的 Deliberative Alignment 把安全遵守放进推理过程，让推理能力本身承担一部分安全约束。这里说的 Deliberative Alignment 是审慎对齐，核心是推理阶段自行判断安全规范，而不是依赖训入的反射行为。两条路线都在把对齐从人工标签变成训练目标内部的一部分。
+
+以 Constitutional AI 为例，两阶段流程是先让模型依照原则自我批评和修订输出，再用 AI feedback 替代逐条人工偏好标注。对齐从来不是挂在训练后面的补丁，系统测什么、怎么打分、奖励什么，模型就往哪个方向走，这本身就是训练后半段最直接的调节手段。
+
+![Image](https://pbs.twimg.com/media/HE-yvfUaQAAb-AU?format=jpg&name=large)
+
+## 到了 Agent 训练，优化的不只是模型本身了
+
+过去两年，以 o1 系列和 DeepSeek-R1 为代表的推理模型快速成型，说明在奖励稳定、验证可靠、基础设施到位的条件下，语言模型上的 RL 确实能显著提升数学、代码和逻辑任务表现。
+
+这同时打开了一个新维度：推理算力也可以扩展了。RL 训练的作用随之多了一层，它在教模型答题之外，还在教模型分配推理预算，知道什么时候多想、什么时候该停。再往前走，难点就变成让模型在环境里持续行动，而不只是把单次思考拉长。
+
+![Image](https://pbs.twimg.com/media/HE-zFtCaAAAi1La?format=jpg&name=large)
+
+Qwen 前模型负责人 Junyang Lin 对 Thinking 和 Instruct 混合路线的反思很有代表性：难点不在给模型一个思考开关，而在两种模式的目标本来就不一样，一个追求直接、合规和低延迟，另一个追求更多探索和更高正确率。再往前一步，训练目标就会从回答前想多久，转成行动里怎么分配预算、怎么接反馈、怎么继续推进任务。
+
+这时候训练对象不再只是一个会回答问题的模型，而是一个能规划、调用工具、接收反馈、在长任务里保持连贯的系统。于是训练栈也跟着变了，浏览器、终端、搜索、执行沙盒、内存系统、工具服务器、编排框架都开始进入训练系统。
+
+更准确地说，harness 是包在模型外层的控制程序，这个概念不只属于 Agent 运行时，训练阶段同样有它：决定模型看到什么输入、以什么形式接收反馈、何时裁剪上下文、何时调工具。prompt construction、memory update、retrieval policy、context editing、tool orchestration 都在这里。环境也不再只是静态验证器，而是训练和部署都要直接面对的一层。
+
+![Image](https://pbs.twimg.com/media/HE-zJsAawAAfK9E?format=jpg&name=large)
+
+harness 先稳住，模型训练才有意义。工具返回值不稳定、浏览器环境和线上不一致、文件系统状态不可复现时，grader 会先出错，模型随后学到的就不是能力，而是如何利用环境漏洞。训练 Agent 时，很多时候既在 debug 模型，也在 debug 环境。
+
+三家的做法也很清楚：Kimi 用 PARL 解决并行拆解和 credit assignment，Cursor 用 self-summarization 和 real-time RL 把长时 coding session 与生产流量重新接回训练，Chroma 则把 prune\_chunks 训成策略本身，让 context pruning 直接进入检索过程。
+
+SFT 时代数据多样性是第一位，到了 Agent 时代，环境质量才是核心：稳定性、真实性、覆盖度、难度分布、反馈丰富度和抗利用性。训练目标也随之变化，要的是在完整任务里保持可靠，不只是做对一道题，经典 CoT benchmark 覆盖不到这部分。
+
+这个变化还在继续前移：不只是在 runtime harness 里训练模型，连 harness code 本身也开始成为可以被外循环搜索和优化的对象。
+
+![Image](https://pbs.twimg.com/media/HE-zKpjawAAnwFN?format=jpg&name=large)
+
+Kimi K2.5 的 PARL 是一个很值得拆开的工程案例，路线很明确：只训练 orchestrator，把 credit assignment 收束到编排层，不在所有 sub-agent 上同时优化。
+
+奖励信号分三类，任务成功、并行分解和完成约束，一起驱动编排层。训练早期把 r\_parallel 权重拉高，鼓励先探索并行策略，后期再逐步退到 0，避免把多开 sub-agent 当成捷径。评估也不只看总步数，还看关键路径长度，关键路径变短才说明并行真的生效。
+
+![Image](https://pbs.twimg.com/media/HE-zOsgakAA9XnV?format=jpg&name=large)
+
+但到了 2026，事情又往前走了一步，Meta-Harness 明确把 harness engineering 单独拿出来优化。它优化的不是权重，而是 harness code 本身，也就是围绕固定模型的 prompt construction、retrieval、memory 与状态更新程序。论文开头的数字很直接：同一个底模，只改 harness，在同一 benchmark 上就可能拉出 6x 的性能差距，模型外层这套程序已经不只是部署细节，也是能力形成的一层。
+
+它的关键也不是再加一个抽象 optimizer，而是把 prior code、scores、execution traces（工具调用和状态变化的执行日志）全部写入 filesystem，让 proposer 像写代码一样去 grep、cat、比对 diff，再顺着失败路径改 harness。proposer 是提出 harness 修改方案的模块。
+
+作者判断得很明确，过去很多 text optimizer 对 harness 这类长时、状态化程序不够有效，核心原因是只看 scalar score、短模板或总结会把问题压扁。scalar score 只有最终得分，没有过程信息。harness 的错误常常要很多步之后才显现，反馈一旦被过度压缩，诊断链路就会断。
+
+这些结果不只是 benchmark 分数更高。在线文本分类里，Meta-Harness 比 ACE（agent 上下文工程基线）高 7.7 个点，同时把 context token 用量压到原来的 1/4。检索增强数学推理里，一个发现出来的 harness 在 200 道 IMO-level 题上，对 5 个 held-out 模型（未参与优化）平均再涨 4.7 个点。在 TerminalBench-2 上，它也超过了手工工程化 baseline。这说明被优化的已经不只是模型内部策略，也包括模型外围那层如何组织信息和行动的程序。
+
+一个具体例子：Meta-Harness 在 TerminalBench-2 上自动发现了 environment bootstrap，也就是 agent loop 开始前先跑一个 shell command，把工作目录、可用语言、包管理器和内存状态整理成快照注入首轮 prompt。很多 coding agent 前几轮其实都在探环境，这层前置做好，提升不一定来自更强权重，而是 harness 让模型一开始就站在更好的上下文上。
+
+到这里，优化目标已经从答案扩展到轨迹，再扩展到承载轨迹的 harness program。
+
+## 前沿模型发布后，训练链路还在继续跑
+
+单用一轮预训练的思路来理解今天的大模型，已经不够了。发布出去的模型背后，通常已经跑完了预训练、后训练、蒸馏、专用化这整条链路，而且更强的模型还在持续给下一代产出训练数据。
+
+DeepSeek-R1 系列的蒸馏就是很典型的例子，大模型先通过 RL 和 verified rewards 把推理能力练出来，再把这些推理轨迹迁给更小的 dense 模型。TranslateGemma 这类专用模型则展示了另一条路线：在更明确的目标任务上，用高质量数据和专门的奖励设计，把能力进一步压缩和定向。到了这一步，更强的模型已经不只是拿来服务用户，也开始直接给下一代模型产出训练数据。
+
+背后的原因比轨迹迁移更根本一些：一个可能的解释是，互联网语料里知识记忆和推理能力是耦合在一起的，现有的预训练目标要求模型同时把两件事都学好。大模型之所以要先上来，是因为只有足够大，才能同时撑起这两件事，然后再用它来生成纯推理示范数据，小模型在这类数据上训练，就可以专注在推理本身，不用再被迫把所有知识都记住；先大再小，一个关键原因是能力解耦，不只是成本策略。
+
+另一边，部署适配性和能力本身同样重要。很多场景不需要全能大模型，更关心成本、延迟、稳定性和可控性，训练的终点不一定是更大，也可能是更小、更便宜、更专门。
+
+最后发布的模型，不一定是训练曲线最右边的那个 checkpoint。实际发布前往往会在多个 checkpoint 之间反复比较真实任务结果、拒答风格、工具稳定性、成本和回归风险。最后上线的版本往往是产品决策，不是单一指标上表现最强的那个。
+
+用户看到模型名字，会以为它对应一条平滑上升的训练曲线，但真正选哪个 checkpoint 上线，那是另一回事。
+
+大模型的价值，既在它自己的服务能力，也在它会继续给下一代模型提供训练数据、蒸馏来源和发布基座。
+
+![Image](https://pbs.twimg.com/media/HE-zd99awAA5nVW?format=jpg&name=large)
+
+离线训练之外，接近在线的持续优化也已经进了主流程，Cursor Composer 2 的 real-time RL 说明一部分 Agent 能力已经开始通过生产流量持续迭代，而不是等下一轮大规模离线训练统一刷新。训练和部署之间的边界并没有消失，但两者的反馈回路正在缩短。
+
+## 以后怎么看一个模型为什么变强了
+
+2026 年前沿模型的价值，越来越看谁能把预训练后面这整套训练链路跑完整：持续产出训练数据、做蒸馏、做专用化、把评测和奖励做好、做最后的发布选择。 也因为这样，后面再看一个模型为什么突然变强，可以先看三件事：
+
+- 先看变化发生在预训练层，还是后面的训练流程。很多能力提升确实来自更强的预训练和更好的数据配方，但也有很多体感变化，其实主要出在后训练。模型会不会听指令、会不会用工具、回答风格稳不稳，常常不是多训一点语料自己长出来的。
+- 再看提升来自哪一层：是权重和训练配方，还是 reward / eval / grader，还是 harness code 和 deployment loop。到了推理模型和 Agent 这一段，用户感受到的变强，很多时候已经不是基础模型单独做出来的结果。评测怎么设、奖励怎么打、工具环境稳不稳、retrieval 和记忆怎么组织、summary 和上下文怎么剪、上线时选了哪个 checkpoint，这些都会一起改掉最后的产品表现。
+- 最后看上线版本在优化什么。有些版本是在追求更高上限，有些版本是在压成本、延迟和回归风险，还有些版本是在给某一类场景做专用化。发布版本本来就是产品决策，不是训练曲线最右边那个点，所以看模型更新时，顺手看它到底在优化什么，会更接近真实情况。
+
+把模型突然变强这件事拆回生产环节看，很多提升其实是后半段训练栈和外层 harness 一起放大的。这条链路的迭代周期也在缩短：生产流量持续回流到训练，每代更强的模型在产出能力的同时也在产出下一代监督数据，外层程序根据 rollouts、logs 和真实任务反馈不断重写。
+
+今天发布的模型只是一个快照，链路和 harness program 才是持续在跑的产品。
+
+## 学习资料
+
+1. Hoffmann et al. (2022). Training Compute-Optimal Large Language Models (Chinchilla). [arXiv:2203.15556](https://arxiv.org/abs/2203.15556)
+2. Ouyang et al. (2022). Training language models to follow instructions with human feedback (InstructGPT). [arXiv:2203.02155](https://arxiv.org/abs/2203.02155)
+3. Shao et al. (2024). DeepSeekMath: Pushing the Limits of Mathematical Reasoning in Open Language Models (GRPO). [arXiv:2402.03300](https://arxiv.org/abs/2402.03300)
+4. DeepSeek-AI (2025). DeepSeek-R1: Incentivizing Reasoning Capability in LLMs via Reinforcement Learning. [arXiv:2501.12948](https://arxiv.org/abs/2501.12948)
+5. DeepSeek-AI (2024). DeepSeek-V3 Technical Report. [arXiv:2412.19437](https://arxiv.org/abs/2412.19437)
+6. Llama Team, AI @ Meta (2024). The Llama 3 Herd of Models. [arXiv:2407.21783](https://arxiv.org/abs/2407.21783)
+7. Bai et al. (2022). Constitutional AI: Harmlessness from AI Feedback. [arXiv:2212.08073](https://arxiv.org/abs/2212.08073)
+8. OpenAI (2024). Deliberative Alignment: Reasoning Enables Safer Language Models. [openai.com/index/deliberative-alignment](https://openai.com/index/deliberative-alignment/)
+9. Anthropic (2025). Sycophancy to Subterfuge: Investigating Reward Tampering in Language Models. [anthropic.com/research/reward-tampering](https://www.anthropic.com/research/reward-tampering)
+10. MacDiarmid et al. (2025). Natural Emergent Misalignment from Reward Hacking in Production RL. [arXiv:2511.18397](https://arxiv.org/abs/2511.18397)
+11. Lee et al. (2026). Meta-Harness: End-to-End Optimization of Model Harnesses (preprint project page). [yoonholee.com/meta-harness](https://yoonholee.com/meta-harness/)
+12. Kimi Team (2026). Kimi K2.5 Tech Blog: Visual Agentic Intelligence. [kimi.com/blog/kimi-k2-5](https://www.kimi.com/blog/kimi-k2-5)
+13. Rush, S. (2026). A technical report on Composer 2. [cursor.com/blog/composer-2-technical-report](https://cursor.com/blog/composer-2-technical-report)
+14. Chroma (2026). Chroma Context-1: Training a Self-Editing Search Agent. [trychroma.com/research/context-1](https://www.trychroma.com/research/context-1)
+
+本文不授权任何方式的转载，洗稿再发布，如大伙发现，欢迎去帮我举报。

1 - Inbox/创始人行动手册：打造一家 AI-Native 创业公司.md

@@ -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 所有。

2 - Projects/Smart Support.md

@@ -1,8 +1,8 @@
 ---
 created: 2026-03-29
-updated: 2026-04-06
+updated: 2026-04-07
 type: project
-status: completed
+status: active
 deadline: ""
 tags:
   - ai-agent
@@ -48,11 +48,14 @@ AI 客服行动层框架。粘贴你的 API，获得一个能执行真实操作
 | 检查点 | langgraph-checkpoint-postgres | PostgreSQL 持久化 |
 | MCP | langchain-mcp-adapters | MultiServerMCPClient |
 | 数据库 | PostgreSQL 16 | Docker Compose 部署 |
-| LLM | Claude Sonnet 4.6（默认） | 支持 Anthropic/OpenAI/Google 切换 |
+| DB 迁移 | Alembic | 自动运行 migrations |
+| LLM | Claude Sonnet 4.6（默认） | 支持 Anthropic/OpenAI/Azure/Google 切换 |
 | 前端 | React 19 + TypeScript + Vite 6 | React Router 7.x |
-| 测试 | pytest 8.3+ / vitest 4.1.2 | 后端 516 测试 92%+ 覆盖率 |
+| 测试 | pytest 8.3+ / vitest 4.1.2 | 后端 516+ 测试 94%+ 覆盖率 |
 | 部署 | Docker Compose | PostgreSQL + FastAPI + nginx |
+| 日志 | structlog | 结构化日志（console/json 模式） |
 | 代码质量 | ruff 0.9+ | Python linting + formatting |
+| 认证 | API Key | `X-API-Key` header / `?token=` for WS |
 
 ## 核心特性
 
@@ -76,14 +79,15 @@ AI 客服行动层框架。粘贴你的 API，获得一个能执行真实操作
 | Phase 3 | 第 4-6 周 | OpenAPI 自动发现 | COMPLETED (2026-03-30) | [[Smart Support/Phase 3 - OpenAPI 自动发现]] |
 | Phase 4 | 第 6-7 周 | 分析 + 回放 | COMPLETED (2026-03-31) | [[Smart Support/Phase 4 - 分析 + 回放]] |
 | Phase 5 | 缓冲周 | 打磨 + 演示 | COMPLETED (2026-03-31) | [[Smart Support/Phase 5 - 打磨 + 演示]] |
+| Post | 2026-04 | 架构修复 + 工程改进 | 进行中 | API v1 版本化、structlog、Alembic、认证、GraphContext/WebSocketContext |
 
 ## 项目数据
 
-- 后端测试：516 个（单元 ~400 + 集成 ~7 + E2E ~3）
+- 后端测试：516+ 个（单元 ~439 + 集成 ~51 + E2E ~26）
 - 前端测试：~23 个（vitest + happy-dom）
-- 代码覆盖率：92.88%
-- 应用版本：v0.5.0
-- Git 最新提交：`af53111` refactor: fix architectural issues
+- 代码覆盖率：~94%
+- 应用版本：v0.6.0
+- Git 最新提交：`f069943` refactor: engineering improvements -- API versioning, structured logging, Alembic, error standardization
 
 ## 目标用户
 
@@ -99,28 +103,36 @@ AI 客服行动层框架。粘贴你的 API，获得一个能执行真实操作
 
 客户端 -> 服务器：
 - `{"type": "message", "thread_id": "...", "content": "..."}`
-- `{"type": "interrupt_response", "thread_id": "...", "interrupt_id": "...", "approved": true/false}`
+- `{"type": "interrupt_response", "thread_id": "...", "approved": true/false}`
 
-服务器 -> 客户端：
-- `{"type": "token", "thread_id": "...", "content": "..."}` -- 流式 token
-- `{"type": "interrupt", ...}` -- 人工确认提示（含 TTL）
-- `{"type": "tool_call", ...}` / `{"type": "tool_result", ...}` -- 工具调用
-- `{"type": "message_complete", ...}` -- 消息完成
-- `{"type": "error", ...}` -- 错误
+服务器 -> 客户端（8 种消息类型）：
+- `{"type": "token", "agent": "...", "content": "..."}` -- 流式 token
+- `{"type": "interrupt", "thread_id": "...", "action": "...", "params": {...}}` -- 人工确认提示
+- `{"type": "clarification", "thread_id": "...", "message": "..."}` -- 意图模糊，请求澄清
+- `{"type": "interrupt_expired", "thread_id": "...", "action": "...", "message": "..."}` -- 审批超时
+- `{"type": "tool_call", "agent": "...", "tool": "...", "args": {...}}` -- 工具调用
+- `{"type": "tool_result", "agent": "...", "tool": "...", "result": ...}` -- 工具返回
+- `{"type": "message_complete", "thread_id": "..."}` -- 消息完成
+- `{"type": "error", "message": "..."}` -- 错误
+
+WebSocket 连接需 `?token=<ADMIN_API_KEY>` 认证（未配置 key 时跳过）。
 
 ## REST API
 
-| 方法 | 路径 | 说明 |
-|------|------|------|
-| WS | `/ws` | WebSocket 聊天 |
-| GET | `/api/health` | 健康检查 |
-| GET | `/api/conversations` | 对话列表（分页） |
-| GET | `/api/replay/{thread_id}` | 回放时间线（分页，默认 20 步） |
-| GET | `/api/analytics?range=7d` | 分析摘要（1d/7d/30d/90d） |
-| POST | `/api/openapi/import` | 开始 OpenAPI 导入 |
-| GET | `/api/openapi/jobs/{id}` | 导入任务状态 |
-| PUT | `/api/openapi/jobs/{id}/classifications/{idx}` | 修改端点分类 |
-| POST | `/api/openapi/jobs/{id}/approve` | 审核通过，生成工具 |
+所有端点使用 `/api/v1/` 前缀。管理端点需 `X-API-Key` header（`ADMIN_API_KEY` 未配置时跳过认证）。
+
+| 方法 | 路径 | 认证 | 说明 |
+|------|------|------|------|
+| WS | `/ws` | Token | WebSocket 聊天（`?token=<key>`） |
+| GET | `/api/v1/health` | 无 | 健康检查 |
+| GET | `/api/v1/conversations` | API Key | 对话列表（分页） |
+| GET | `/api/v1/replay/{thread_id}` | API Key | 回放时间线（分页） |
+| GET | `/api/v1/analytics?range=7d` | API Key | 分析摘要 |
+| POST | `/api/v1/openapi/import` | API Key | 开始 OpenAPI 导入 |
+| GET | `/api/v1/openapi/jobs/{id}` | API Key | 导入任务状态 |
+| GET | `/api/v1/openapi/jobs/{id}/classifications` | API Key | 获取端点分类 |
+| PUT | `/api/v1/openapi/jobs/{id}/classifications/{idx}` | API Key | 修改端点分类 |
+| POST | `/api/v1/openapi/jobs/{id}/approve` | API Key | 审核通过，生成工具代码 + Agent YAML |
 
 ## 数据库表
 
@@ -129,9 +141,12 @@ AI 客服行动层框架。粘贴你的 API，获得一个能执行真实操作
 | checkpoints | LangGraph 状态快照（自动管理） |
 | checkpoint_writes | 检查点写入记录 |
 | conversations | 对话元数据（状态、解决类型、使用 Agent、Token、成本） |
-| interrupts | 人工确认记录（pending/approved/rejected/expired） |
+| active_interrupts | 人工确认记录（interrupt_id, action, params, resolved_at） |
+| sessions | 会话状态持久化（last_activity, has_pending_interrupt），供 PgSessionManager 使用 |
 | analytics_events | 分析事件流（事件类型、Agent、工具、Token、成本、耗时） |
 
+数据库迁移通过 Alembic 管理，应用启动时自动执行 `run_alembic_migrations()`。
+
 ## 架构决策（ADR）
 
 | ADR | 决策 | 理由 |
@@ -166,26 +181,39 @@ AI 客服行动层框架。粘贴你的 API，获得一个能执行真实操作
 
 ```
 backend/app/
-  main.py              -- FastAPI 入口 (v0.5.0)
-  config.py            -- Pydantic Settings
-  db.py                -- AsyncPostgreSQL + AsyncPostgresSaver
-  llm.py               -- LLM 提供商工厂（Anthropic/OpenAI/Google）
-  graph.py             -- LangGraph Supervisor 构建
+  main.py              -- FastAPI 入口 (v0.6.0), 全局异常处理, 中断清理循环
+  config.py            -- Pydantic Settings（含 admin_api_key, log_format）
+  db.py                -- AsyncPostgreSQL + AsyncPostgresSaver + Alembic runner
+  llm.py               -- LLM 提供商工厂（Anthropic/OpenAI/Azure/Google）
+  graph.py             -- LangGraph Supervisor 构建，返回 GraphContext
+  graph_context.py     -- GraphContext: 图 + 分类器 + 注册表的类型化封装
   ws_handler.py        -- WebSocket 消息分发 + 流式 + 速率限制
+  ws_context.py        -- WebSocketContext: WS 处理依赖打包
+  auth.py              -- API Key 认证中间件（X-API-Key / ?token= for WS）
+  api_utils.py         -- 共享 envelope() 响应格式
+  logging_config.py    -- structlog 配置（console/json）
   registry.py          -- YAML Agent 注册表 + 模板支持
   intent.py            -- LLM 意图分类器
-  session_manager.py   -- Session TTL（30m 滑动窗口）
-  interrupt_manager.py -- 中断 TTL 追踪 + 自动取消
+  session_manager.py   -- Session TTL（30m 滑动窗口）+ PgSessionManager
+  interrupt_manager.py -- 中断 TTL 追踪 + 自动取消 + PgInterruptManager
   escalation.py        -- Webhook 升级（指数退避）
   conversation_tracker.py -- 对话生命周期追踪
   callbacks.py         -- Token 用量回调
+  safety.py            -- 确认策略规则 + MCP 错误分类
   agents/              -- Agent 定义（order_lookup, order_actions, discount, fallback）
-  openapi/             -- OpenAPI 解析 + 分类 + 生成（ssrf, fetcher, parser, classifier, generator）
+  openapi/             -- OpenAPI 解析 + 分类 + 生成（ssrf, fetcher, parser, classifier, generator, review_api）
   replay/              -- 回放模型 + 转换器 + API
   analytics/           -- 分析模型 + 事件记录 + 查询 + API
-  tools/               -- 错误处理（ErrorCategory, classify_error, with_retry）
 ```
 
+### 架构模式
+
+- **Protocol 接口**：所有跨模块边界使用 Protocol（SessionManagerProtocol, InterruptManagerProtocol 等）
+- **Frozen dataclasses**：GraphContext, WebSocketContext, SessionState, InterruptRecord 等全部不可变
+- **Composition Root**：main.py lifespan() 统一组装所有依赖
+- **Envelope 响应**：`{"success": bool, "data": T, "error": str | null}` 统一格式
+- **双实现状态管理**：内存版（开发）+ PostgreSQL 版（生产多 Worker）
+
 ## 计划文档
 
 项目根目录下：
@@ -235,12 +263,18 @@ cd ../frontend && npm test
 
 ## 已知技术债务
 
-- [ ] 认证/授权系统（生产部署前）
+- [x] ~~认证/授权系统~~ -- 已实现 API Key 认证（`auth.py`，`ADMIN_API_KEY`）
+- [x] ~~中断清理未定时调度~~ -- 已实现 `_interrupt_cleanup_loop` 后台任务（60s 间隔）
+- [x] ~~猴子补丁~~ -- 已替换为 GraphContext 类型化封装
+- [x] ~~dispatch_message 参数膨胀~~ -- 已替换为 WebSocketContext
+- [x] ~~_envelope 重复定义~~ -- 已提取到 api_utils.py
+- [x] ~~前端缺失消息类型~~ -- 已添加 clarification/interrupt_expired/tool_result 处理
 - [ ] 多租户架构（第一个付费客户后）
 - [ ] CI/CD 流水线（原型阶段手动部署）
 - [ ] 速率限制进程全局状态 -- 多 Worker 需 Redis
-- [ ] 中断清理未定时调度（cleanup_expired 存在但未触发）
-- [ ] NoOpAnalyticsRecorder 已注册 -- PostgresAnalyticsRecorder 集成待完善
+- [ ] 生产环境切换到 PgSessionManager/PgInterruptManager
+- [ ] OpenAPI approve 后的工具尚未运行时注入到 _TOOL_MAP（仅生成代码 + YAML）
+- [ ] SSRF DNS 重绑定 TOCTOU 窗口（实践中利用难度大）
 - [ ] SaaS/Fintech 模板工具仅为桩（无实现）
 - [ ] 工具生成基于字符串模板 -- 复杂场景可能需 AST
 

4 - Resources/Claude-Code/Claude Code Agent Teams 官方多Agent编排.md

@@ -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 设计 |

4 - Resources/Claude-Code/ECC 编排替代方案 (orchestrate 迁移).md

@@ -1,7 +1,8 @@
 ---
 created: "2026-04-06"
+updated: "2026-04-14"
 type: resource
-tags: [resource, claude-code, AI-tools, orchestrate, migration, feature-dev, GSD, ECC, windows-compatible]
+tags: [resource, claude-code, AI-tools, orchestrate, migration, feature-dev, GSD, PRP, devfleet, ECC, windows-compatible]
 source: "https://github.com/affaan-m/everything-claude-code"
 ---
 
@@ -9,6 +10,8 @@ source: "https://github.com/affaan-m/everything-claude-code"
 
 `/ecc:orchestrate` 已标记为 legacy shim。底层委托给 `dmux-workflows`（需 tmux）和 `autonomous-agent-harness`（部分依赖 tmux）。Windows 上基本不可用。本文档记录迁移路径。
 
+> **先看决策表**：见文末「一张表选编排方式」。
+
 相关笔记：[[Autonomous Agent Harness 自主代理框架]]、[[Everything Claude Code 完整指南]]
 
 ## orchestrate 做了什么
@@ -63,7 +66,102 @@ source: "https://github.com/affaan-m/everything-claude-code"
 | 安全相关 | 任何组合 + `/ecc:security-review` |
 | 最终验证 | `/ecc:verify` |
 
-### 路线 C：全项目多阶段 — GSD
+### 路线 C：PRP 工作流（PRD → 实施 → 提交 → PR）
+
+**适合结构化 PRD/migration-plan 等带 Implementation Phases 的文档。** 一条龙自动走完：
+
+```
+/prp-plan <feature 描述 | path/to/prd.md>   # 解析 PRD 找到下一个 pending phase，产出完整实施计划
+/prp-implement <上一步生成的 plan 路径>       # 按计划严格实施 + 验证循环
+/prp-commit                                  # 分析变更，起草 conventional commit
+/prp-pr                                      # 汇总提交生成 PR
+```
+
+特点：
+- `/prp-plan` 自动检测输入：PRD 文件 → 选下一个 pending phase；自由描述 → 直接规划
+- 黄金原则：把实施时可能要搜的所有模式/惯例**提前抓进 plan**，实施阶段不再回去搜
+- Windows 原生可用
+
+### 路线 D：多模型协同 — `/multi-workflow`
+
+**Claude 编排 + Codex 后端 + Gemini 前端 的 6 阶段流水线。** 适合全栈功能。
+
+```
+/multi-workflow "add real-time notifications when market resolves"
+```
+
+6 阶段：Research → Ideation → Plan → Execute → Optimize → Review。每阶段通过 `~/.claude/bin/codeagent-wrapper` 并行调用 Codex/Gemini（`run_in_background: true`），用 `TaskOutput` 等结果。外部模型**无文件写权限**，所有修改由 Claude 落盘。
+
+变体：`/multi-plan`（只规划）、`/multi-backend`、`/multi-frontend`、`/multi-execute`。
+
+### 路线 E：DAG 式并行多 agent — `claude-devfleet`
+
+**用独立 git worktree 跑多个 Claude Code agent，按 DAG 依赖自动调度，Windows 原生可用。** 需本地启 DevFleet 服务并通过 MCP 接入：
+
+```bash
+claude mcp add devfleet --transport http http://localhost:18801/mcp
+```
+
+核心调用（通过 MCP tool）：
+
+```
+plan_project(prompt="Build a REST API with auth and tests")
+  → 返回 project_id + 一系列 missions（含 depends_on 链、auto_dispatch=true）
+dispatch_mission(mission_id=<root>)
+  → 根 mission 启动，后续 mission 在依赖满足时自动派发
+get_mission_status / get_dashboard / get_report
+  → 监控与汇报
+```
+
+特点：
+- 每个 mission 在独立 worktree 中运行，完成后自动 merge
+- 默认最多 3 个并发 agent（`DEVFLEET_MAX_AGENTS` 可配）
+- 合并冲突时留在 worker 分支手动处理
+- 长任务建议用 `get_mission_status` 轮询（30-60 秒间隔），避免用 `wait_for_mission` 阻塞会话
+
+### 路线 F：会话内并行 — Agent 工具 + worktree 隔离
+
+**当前会话里直接 spawn 多个子代理，`isolation: "worktree"` 参数自动建临时 worktree，Windows 原生可用。** 不需要 tmux、不需要外部服务。
+
+主代理调用示例（Claude 自身能用）：
+
+```
+并行 3 个子 agent：
+- subagent_type: general-purpose, isolation: worktree, prompt: "迁移 module X"
+- subagent_type: general-purpose, isolation: worktree, prompt: "迁移 module Y"
+- subagent_type: csharp-reviewer, prompt: "审查 module X/Y 结果"
+```
+
+适合：互相独立的迁移任务、并行审查、互不冲突的多模块改造。不适合：跨模块强耦合、需要相互看到中间状态的任务。
+
+### 路线 G：外部 tmux + worktree 脚本 — `scripts/orchestrate-worktrees.js`
+
+**ECC 自带的长周期/跨 harness 编排助手。需要 tmux（Linux/macOS/WSL）。**
+
+```bash
+node scripts/orchestrate-worktrees.js plan.json --execute
+```
+
+`plan.json` 结构：
+
+```json
+{
+  "sessionName": "skill-audit",
+  "baseRef": "HEAD",
+  "seedPaths": ["scripts/helper.js", ".claude/plan/spec.md"],
+  "launcherCommand": "codex exec --cwd {worktree_path} --task-file {task_file}",
+  "workers": [
+    {"name": "docs-a", "task": "Fix skills 1-4."},
+    {"name": "docs-b", "task": "Fix skills 5-8."}
+  ]
+}
+```
+
+自动完成：每 worker 一个分支+worktree、覆盖 `seedPaths` 中的本地脏文件、写 `.orchestration/<session>/` 下的 task/handoff/status 文件、启动 tmux 会话挂 panes。
+
+状态快照：`node scripts/orchestration-status.js <plan.json>`。
+
+### 路线 H：全项目多阶段 — GSD
 
 GSD（Get Shit Done）是 ECC 集成的项目级编排系统，Windows 原生可用。
 
@@ -103,14 +201,16 @@ npx get-shit-done-cc@latest
 
 ## 迁移对照表
 
-| 旧命令 | 新命令 | 说明 |
-|--------|--------|------|
-| `/ecc:orchestrate feature "desc"` | `/ecc:feature-dev "desc"` | 单功能全流程 |
-| `/ecc:orchestrate bugfix "desc"` | `/ecc:tdd` + `/ecc:code-review` | 先写失败测试再修 |
-| `/ecc:orchestrate refactor "desc"` | `/ecc:plan` + `/ecc:tdd` + `/ecc:code-review` | 先规划再重构 |
-| `/ecc:orchestrate security "desc"` | 任何路线 + `/ecc:security-review` | 加安全审查 |
-| 多阶段自动执行 | `/gsd:autonomous` | GSD 接管 |
-| 并行编排 | 不可用（Windows） | 用 Agent/Task tool 做进程内并行 |
+| 旧命令                                | 新命令                                           | 说明                       |
+| ---------------------------------- | --------------------------------------------- | ------------------------ |
+| `/ecc:orchestrate feature "desc"`  | `/ecc:feature-dev "desc"` 或 `/prp-plan`+`/prp-implement` | 单功能全流程         |
+| `/ecc:orchestrate bugfix "desc"`   | `/ecc:tdd` + `/ecc:code-review`               | 先写失败测试再修                 |
+| `/ecc:orchestrate refactor "desc"` | `/ecc:plan` + `/ecc:tdd` + `/ecc:code-review` | 先规划再重构                   |
+| `/ecc:orchestrate security "desc"` | 任何路线 + `/ecc:security-review`                 | 加安全审查                    |
+| 多阶段自动执行                            | `/gsd:autonomous`                             | GSD 接管                   |
+| 并行编排（tmux）                         | `claude-devfleet` MCP 或 Agent+worktree        | Windows 原生替代             |
+| PRD → 实施                           | `/prp-plan <prd.md>` → `/prp-implement`       | 自动解析 phases              |
+| 多模型协同                              | `/multi-workflow`                             | Codex+Gemini+Claude     |
 
 ## CLAUDE.md 更新
 
@@ -138,13 +238,35 @@ npx get-shit-done-cc@latest
 |------|---------|------|
 | `/ecc:feature-dev` | 可用 | Claude Code 内部，不依赖外部工具 |
 | `/ecc:plan` + `/ecc:tdd` + ... | 可用 | 同上 |
+| `/prp-plan` / `/prp-implement` / `/prp-commit` / `/prp-pr` | 可用 | 全部 Claude Code 内部 |
+| `/multi-workflow` (含 Codex/Gemini) | 可用 | 需装 codeagent-wrapper，不依赖 tmux |
 | `/gsd:autonomous` | 可用 | 用 Claude Code Task tool 做并行 |
+| Agent 工具 + `isolation: "worktree"` | 可用 | 原生 git worktree，不依赖 tmux |
+| `claude-devfleet` (MCP) | 可用 | HTTP MCP 接入，worker 在独立 worktree |
 | `/ecc:orchestrate` | **不可用** | Legacy，底层依赖 tmux |
-| `dmux-workflows` | **不可用** | 需要 tmux |
+| `dmux-workflows` | **不可用** | 需要 tmux（除非 WSL） |
+| `scripts/orchestrate-worktrees.js` | **WSL 可用** | 建 tmux session 挂 panes |
 | `auto-pilot.sh` 脚本 | 可用 | Git Bash，每阶段独立 `claude -p` |
 
 ---
 
+## 一张表选编排方式
+
+| 我要... | 选 | 入口 |
+|---------|-----|------|
+| 规划单个功能，确认后再写 | `/plan` | 命令 |
+| 单功能全流程（含 TDD+审查） | `/ecc:feature-dev` | 命令 |
+| 已有 PRD/migration-plan 带 phases | `/prp-plan <path>` → `/prp-implement` | 命令 |
+| 前后端都动（Codex/Gemini 辅助） | `/multi-workflow` | 命令 |
+| 会话内并行几个独立任务 | Agent 工具 + `isolation: worktree` | 主代理直接 spawn |
+| DAG 调度多 worker 自动合并 | `claude-devfleet` | MCP |
+| 整个项目/多 milestone 生命周期 | `/gsd:new-project` → `/gsd:autonomous` | 命令 |
+| 无人值守长时间跑 | `autonomous-agent-harness` + crons | MCP scheduled-tasks |
+| 定时重复同一个任务 | `/loop-start <interval> <prompt>` | 命令 |
+| 跨 harness 长周期编排（Linux/WSL） | `scripts/orchestrate-worktrees.js` | 脚本 |
+
+---
+
 ## 什么时候需要外部脚本
 
 大部分情况下 Claude Code 自己编排（`/ecc:feature-dev` 或 GSD）就够了。外部脚本（`auto-pilot.sh`）只在以下场景有价值：

4 - Resources/Claude-Code/Everything Claude Code 完整指南.md

@@ -1,5 +1,6 @@
 ---
 created: "2026-03-08 21:30"
+updated: "2026-04-14"
 type: resource
 tags: [resource, claude-code, AI-tools, development-workflow, reference]
 source: "https://github.com/affaan-m/everything-claude-code"
@@ -7,24 +8,35 @@ source: "https://github.com/affaan-m/everything-claude-code"
 
 # Everything Claude Code 完整指南
 
-生产级 Claude Code 插件系统。v1.10.0 (2026-04-06 更新)，包含 215 skills、112 agents、82 commands、hooks 和 rules (608 files total)。方法论与最佳实践见 [[Everything Claude Code 方法论与最佳实践]]，按场景速查见 [[Everything Claude Code 用法速查]]。
+生产级 Claude Code 插件系统。v1.10.0（本地仓库实测 183 skills / 48 agents / 79 commands；marketplace 版可能更多——以本地 `ls` 结果为准）。方法论与最佳实践见 [[Everything Claude Code 方法论与最佳实践]]，按场景速查见 [[Everything Claude Code 用法速查]]。
+
+> **仓库关键参考文档**（实测路径 `C:\Users\yaoji\git\OpenSource\everything-claude-code\`）：
+> - `docs/COMMAND-AGENT-MAP.md` — 命令↔agent↔skill 的官方对照表
+> - `COMMANDS-QUICK-REF.md` — 59 命令速查（按作者口径）
+> - `the-longform-guide.md` / `the-shortform-guide.md` — 官方长/短指南
+> - `skills/dmux-workflows/SKILL.md`、`skills/autonomous-agent-harness/SKILL.md`、`skills/claude-devfleet/SKILL.md` — 三类编排机制
+> - `scripts/orchestrate-worktrees.js` — 外部 tmux+worktree 编排脚本
 
 自主循环和并行编排详见：[[Autonomous Loops 自主循环模式]]、[[dmux 多Agent并行编排]]、[[Ralphinho RFC-DAG 编排模式]]、[[Autonomous Agent Harness 自主代理框架]]、[[ECC 编排替代方案 (orchestrate 迁移)]]
 
 ## 项目架构
 
 ```
-everything-claude-code/ (v1.10.0, 608 files)
-├── agents/     (112个) - 专用子代理 (.agents/ + agents/)
-├── skills/     (215个) - 工作流定义和领域知识
-├── commands/   (82个)  - slash 命令
-├── hooks/      - 基于事件的自动化
-├── rules/      - 始终遵循的规则（15种语言 + common）
-├── scripts/    (93个) - 跨平台 Node.js 工具脚本
+everything-claude-code/ (v1.10.0)
+├── agents/     (~48) - 专用子代理（code-reviewer、planner、tdd-guide、...）
+├── skills/     (~183) - 工作流定义和领域知识
+├── commands/   (~79) - slash 命令
+├── hooks/      - 基于事件的自动化（hooks.json + scripts/hooks/*）
+├── rules/      - 始终遵循的规则（python/typescript/golang/... + common + zh）
+├── scripts/    - 跨平台 Node.js 工具脚本（orchestrate-worktrees、harness-audit、...）
 ├── mcp-configs/- MCP 服务器配置模板
-└── contexts/   - 动态注入的上下文文件
+├── contexts/   - 动态注入的上下文文件
+├── docs/       - COMMAND-AGENT-MAP、SKILL-PLACEMENT-POLICY 等
+└── plugins/    - 独立子插件（gsd、obsidian、planning-with-files、...）
 ```
 
+> 数字随版本浮动，以 `ls commands/*.md | wc -l` 等实测为准。
+
 ## 安装
 
 ```bash
@@ -123,7 +135,21 @@ Rules 新增：java, kotlin, dart, csharp, cpp, rust, perl, php, web, zh (中文
 
 ---
 
-## 全部 65 Skills
+## 精选 Skills（curated subset，非全量）
+
+> 实际 skills 总数 ~183（v1.10.0）。以下只列最常用的按领域分组。完整清单：`ls skills/` 或看 `docs/COMMAND-AGENT-MAP.md`。
+
+### 编排三件套（本文档重点）
+
+| Skill | 用途 | Windows 可用 |
+|-------|------|--------------|
+| `dmux-workflows` | tmux pane 多 agent 并行 | ❌（需 WSL） |
+| `autonomous-agent-harness` | 自主循环 / 定时 / 持久记忆 | ✅ |
+| `claude-devfleet` | DAG 式多 worker + 独立 worktree + 自动 merge | ✅（需本地 DevFleet MCP） |
+
+其它相关：`autonomous-loops`、`continuous-agent-loop`、`ralphinho-rfc-pipeline`、`council`、`gan-style-harness`。
+
+
 
 ### 核心基础设施 (9)
 
@@ -267,7 +293,11 @@ Rules 新增：java, kotlin, dart, csharp, cpp, rust, perl, php, web, zh (中文
 
 ---
 
-## 16 Agents
+## 精选 Agents（非全量）
+
+> 实际 agents 总数 ~48。以下是最常被命令调用或主代理手动 spawn 的核心子代理。完整清单：`ls agents/` 或看 `docs/COMMAND-AGENT-MAP.md`。
+
+
 
 | Agent                  | 职责                |
 | ---------------------- | ----------------- |
@@ -293,16 +323,22 @@ Rules 新增：java, kotlin, dart, csharp, cpp, rust, perl, php, web, zh (中文
 ## 常用 Commands
 
 ### 开发核心
-`/plan` `/tdd` `/e2e` `/code-review` `/build-fix` `/verify` `/test-coverage` `/refactor-clean`
+`/plan` `/tdd` `/e2e` `/code-review` `/build-fix` `/verify` `/test-coverage` `/refactor-clean` `/feature-dev`
+
+### PRP 工作流（PRD→实施→PR 一条龙）
+`/prp-prd` `/prp-plan` `/prp-implement` `/prp-commit` `/prp-pr`
 
 ### 多 Agent 编排
-`/multi-plan` `/multi-execute` `/multi-frontend` `/multi-backend` `/orchestrate`
+`/multi-plan` `/multi-workflow` `/multi-execute` `/multi-frontend` `/multi-backend` `/devfleet` `/orchestrate`（legacy shim）
+
+### GSD 项目生命周期（独立子插件）
+`/gsd:new-project` `/gsd:plan-phase` `/gsd:execute-phase` `/gsd:verify-work` `/gsd:next` `/gsd:autonomous` `/gsd:ship` `/gsd:complete-milestone`
 
 ### 学习演化
-`/learn` `/learn-eval` `/evolve` `/instinct-status` `/instinct-export` `/instinct-import`
+`/learn` `/learn-eval` `/evolve` `/instinct-status` `/instinct-export` `/instinct-import` `/skill-create` `/skill-health` `/rules-distill`
 
-### v1.8.0 新增
-`/loop-start` `/loop-status` `/model-route` `/quality-gate` `/harness-audit` `/promote`
+### 循环/自动化
+`/loop-start` `/loop-status` `/model-route` `/quality-gate` `/harness-audit` `/promote` `/claw`
 
 ### 验证 & 会话
 `/checkpoint`(verification-loop 检查点)`/verify`(完整验证管道)`/sessions`(会话历史)`/security-scan`(AgentShield 扫描)
@@ -349,10 +385,16 @@ 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并行编排]]
 - [[Ralphinho RFC-DAG 编排模式]]
+- [[GSD 方法论与最佳实践]]
 
 ### Zettelkasten
 - [[Everything Claude Code 最佳实践]]

6 - Zettelkasten/20260414230719 Agent 工具 worktree 隔离是 Windows 原生并行的关键.md

@@ -0,0 +1,53 @@
+---
+created: "2026-04-14 23:07"
+type: zettel
+tags: [zettel, claude-code, ECC, orchestration, parallel, windows, worktree]
+source: "Claude Code Agent tool 参数: isolation"
+---
+
+# Agent 工具 worktree 隔离是 Windows 原生并行的关键
+
+ECC 的 `dmux-workflows`、`scripts/orchestrate-worktrees.js` 都依赖 tmux，Windows 原生环境跑不了。绕过这个限制最干净的方案不是切 WSL，是用 Claude Code 内置 `Agent` 工具的 `isolation: "worktree"` 参数。
+
+## 机制
+
+`Agent` 工具在 spawn 子代理时接受 `isolation: "worktree"`——平台会自动为该子代理建一个临时 git worktree，子代理在隔离分支上做修改，无改动时自动清理，有改动则把 path 和 branch 返还给主代理，由主代理决定合并还是丢弃。
+
+这和 `claude-devfleet` 的 worktree 策略本质一致，只是调度层从 HTTP MCP 变成主代理自己。
+
+## 为什么重要
+
+1. **零外部依赖** — 不需要 tmux、不需要额外服务，Claude Code 开箱即用
+2. **天然隔离** — git worktree 保证多个子代理改同一个仓库也不会互相踩脚
+3. **失败可丢弃** — 改坏了直接扔掉 worktree，主会话干净无污染
+4. **和现有 agent 生态复用** — 任何 `subagent_type`（general-purpose、csharp-reviewer、security-reviewer……）都能套 worktree
+
+## 适用边界
+
+- ✅ 互相独立的迁移任务、并行审查、多模块改造
+- ✅ 想在 Windows 上复刻 dmux 「多 pane 并行」效果
+- ❌ 跨模块强耦合、子代理需要实时看到彼此中间状态
+- ❌ 需要长时间运行、跨会话存活（用 `claude-devfleet` 或 `autonomous-agent-harness` crons）
+
+## 和其他编排方式的关系
+
+| 需求 | 用这个 |
+|------|--------|
+| 几个独立子任务，当前会话内搞定 | **Agent + isolation: worktree**（本 zettel） |
+| DAG 依赖、跨会话、自动 merge | `claude-devfleet`（MCP） |
+| Linux/WSL 上可视化多 pane | `dmux-workflows` |
+| 定时 / 长周期无人值守 | `autonomous-agent-harness` + crons |
+
+---
+
+## Related
+
+- [[ECC 编排替代方案 (orchestrate 迁移)]]
+- [[dmux 多Agent并行编排]]
+- [[Autonomous Agent Harness 自主代理框架]]
+- [[Everything Claude Code Agent 编排模式]]
+
+## Source
+
+- Claude Code `Agent` tool 原生参数 `isolation`
+- ECC `skills/claude-devfleet/SKILL.md` 的 worktree 隔离策略（同源思路）

Untitled.canvas

@@ -0,0 +1 @@
+{}

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
+```