commit e31a75d2bbde5a1d03c2c2ef88286a2d995e1b60 Author: qiaoxinjiu Date: Wed May 27 15:40:32 2026 +0800 Add under-anything knowledge dashboard diff --git a/Understand-Anything-main/.claude-plugin/marketplace.json b/Understand-Anything-main/.claude-plugin/marketplace.json new file mode 100644 index 0000000..39a8451 --- /dev/null +++ b/Understand-Anything-main/.claude-plugin/marketplace.json @@ -0,0 +1,15 @@ +{ + "name": "understand-anything", + "metadata": { + "description": "LLM-powered codebase analysis producing interactive knowledge graphs, guided tours, and deep-dive explanations" + }, + "owner": { + "name": "Lum1104" + }, + "plugins": [ + { + "name": "understand-anything", + "source": "./understand-anything-plugin" + } + ] +} diff --git a/Understand-Anything-main/.claude-plugin/plugin.json b/Understand-Anything-main/.claude-plugin/plugin.json new file mode 100644 index 0000000..5c75bd7 --- /dev/null +++ b/Understand-Anything-main/.claude-plugin/plugin.json @@ -0,0 +1,18 @@ +{ + "name": "understand-anything", + "description": "AI-powered codebase understanding — analyze, visualize, and explain any project", + "version": "2.7.5", + "author": { + "name": "Lum1104" + }, + "homepage": "https://github.com/Lum1104/Understand-Anything", + "repository": "https://github.com/Lum1104/Understand-Anything", + "license": "MIT", + "keywords": [ + "codebase-analysis", + "knowledge-graph", + "architecture", + "onboarding", + "dashboard" + ] +} diff --git a/Understand-Anything-main/.copilot-plugin/plugin.json b/Understand-Anything-main/.copilot-plugin/plugin.json new file mode 100644 index 0000000..b18679d --- /dev/null +++ b/Understand-Anything-main/.copilot-plugin/plugin.json @@ -0,0 +1,14 @@ +{ + "name": "understand-anything", + "description": "AI-powered codebase understanding — analyze, visualize, and explain any project", + "version": "2.7.5", + "author": { + "name": "Lum1104" + }, + "homepage": "https://github.com/Lum1104/Understand-Anything", + "repository": "https://github.com/Lum1104/Understand-Anything", + "license": "MIT", + "keywords": ["codebase-analysis", "knowledge-graph", "architecture", "onboarding", "dashboard"], + "skills": "./understand-anything-plugin/skills/", + "agents": "./understand-anything-plugin/agents/" +} diff --git a/Understand-Anything-main/.cursor-plugin/plugin.json b/Understand-Anything-main/.cursor-plugin/plugin.json new file mode 100644 index 0000000..075114d --- /dev/null +++ b/Understand-Anything-main/.cursor-plugin/plugin.json @@ -0,0 +1,15 @@ +{ + "name": "understand-anything", + "displayName": "Understand Anything", + "description": "AI-powered codebase understanding — analyze, visualize, and explain any project", + "version": "2.7.5", + "author": { + "name": "Lum1104" + }, + "homepage": "https://github.com/Lum1104/Understand-Anything", + "repository": "https://github.com/Lum1104/Understand-Anything", + "license": "MIT", + "keywords": ["codebase-analysis", "knowledge-graph", "architecture", "onboarding", "dashboard"], + "skills": "./understand-anything-plugin/skills/", + "agents": "./understand-anything-plugin/agents/" +} diff --git a/Understand-Anything-main/.github/FUNDING.yml b/Understand-Anything-main/.github/FUNDING.yml new file mode 100644 index 0000000..cb75fdf --- /dev/null +++ b/Understand-Anything-main/.github/FUNDING.yml @@ -0,0 +1 @@ +patreon: Lum1104 diff --git a/Understand-Anything-main/.github/workflows/ci.yml b/Understand-Anything-main/.github/workflows/ci.yml new file mode 100644 index 0000000..69771eb --- /dev/null +++ b/Understand-Anything-main/.github/workflows/ci.yml @@ -0,0 +1,36 @@ +name: CI + +on: + pull_request: + +jobs: + ci: + runs-on: ubuntu-latest + steps: + - uses: actions/checkout@v4 + + - uses: pnpm/action-setup@v4 + + - uses: actions/setup-node@v4 + with: + node-version: 22 + cache: pnpm + cache-dependency-path: pnpm-lock.yaml + + - name: Install dependencies + run: pnpm install + + - name: Lint + run: pnpm lint + + - name: Build core + run: pnpm --filter @understand-anything/core build + + - name: Build skill + run: pnpm --filter @understand-anything/skill build + + - name: Test core + run: pnpm --filter @understand-anything/core test + + - name: Test skill + run: pnpm test diff --git a/Understand-Anything-main/.github/workflows/deploy-homepage.yml b/Understand-Anything-main/.github/workflows/deploy-homepage.yml new file mode 100644 index 0000000..d6df0d9 --- /dev/null +++ b/Understand-Anything-main/.github/workflows/deploy-homepage.yml @@ -0,0 +1,68 @@ +name: Deploy Homepage + +on: + push: + branches: [main] + paths: + - 'homepage/**' + - 'understand-anything-plugin/packages/dashboard/**' + - 'understand-anything-plugin/packages/core/**' + - '.github/workflows/deploy-homepage.yml' + workflow_dispatch: + +permissions: + contents: read + pages: write + id-token: write + +concurrency: + group: pages + cancel-in-progress: true + +jobs: + build: + runs-on: ubuntu-latest + steps: + - uses: actions/checkout@v4 + + - uses: pnpm/action-setup@v4 + + - uses: actions/setup-node@v4 + with: + node-version: 22 + cache: pnpm + cache-dependency-path: pnpm-lock.yaml + + - name: Install dependencies + run: pnpm install + + - name: Build homepage + working-directory: homepage + run: pnpm build + + - name: Build core + run: pnpm --filter @understand-anything/core build + + - name: Build demo dashboard + run: pnpm --filter @understand-anything/dashboard build:demo + env: + VITE_GRAPH_URL: ${{ vars.DEMO_GRAPH_URL }} + VITE_DOMAIN_GRAPH_URL: ${{ vars.DEMO_DOMAIN_GRAPH_URL }} + VITE_META_URL: ${{ vars.DEMO_META_URL }} + + - name: Merge demo into homepage output + run: cp -r understand-anything-plugin/packages/dashboard/dist homepage/dist/demo + + - uses: actions/upload-pages-artifact@v3 + with: + path: homepage/dist + + deploy: + needs: build + runs-on: ubuntu-latest + environment: + name: github-pages + url: ${{ steps.deployment.outputs.page_url }} + steps: + - id: deployment + uses: actions/deploy-pages@v4 diff --git a/Understand-Anything-main/.gitignore b/Understand-Anything-main/.gitignore new file mode 100644 index 0000000..8087a9e --- /dev/null +++ b/Understand-Anything-main/.gitignore @@ -0,0 +1,16 @@ +node_modules +dist +.understand-anything +*.tsbuildinfo +.DS_Store +.env +.env.* +coverage/ +*.log +__pycache__/ +.claude/ +.worktrees/ +homepage/public/demo/ +.private/ +__pycache__/ +*.pyc diff --git a/Understand-Anything-main/.npmrc b/Understand-Anything-main/.npmrc new file mode 100644 index 0000000..3e6c04e --- /dev/null +++ b/Understand-Anything-main/.npmrc @@ -0,0 +1,2 @@ +shamefully-hoist=false +strict-peer-dependencies=false diff --git a/Understand-Anything-main/CLAUDE.md b/Understand-Anything-main/CLAUDE.md new file mode 100644 index 0000000..bed0248 --- /dev/null +++ b/Understand-Anything-main/CLAUDE.md @@ -0,0 +1,98 @@ +# Understand Anything + +## Project Overview +An open-source tool combining LLM intelligence + static analysis to produce interactive dashboards for understanding codebases. + +## Prerequisites +- Node.js >= 22 (developed on v24) +- pnpm >= 10 (pinned via `packageManager` field in root `package.json`) + +## Architecture +- **Monorepo** with pnpm workspaces +- **understand-anything-plugin/** — Claude Code plugin containing all source code: + - **packages/core** — Shared analysis engine (types, persistence, tree-sitter, search, schema, tours, plugins) + - **packages/dashboard** — React + TypeScript web dashboard (React Flow, Zustand, TailwindCSS v4) + - **src/** — Skill TypeScript source for `/understand-chat`, `/understand-diff`, `/understand-explain`, `/understand-onboard` + - **skills/** — Skill definitions (`/understand`, `/understand-dashboard`, etc.) + - **agents/** — Agent definitions (project-scanner, file-analyzer, architecture-analyzer, tour-builder, graph-reviewer) + +## Dashboard +- Dark luxury theme: deep blacks (#0a0a0a), gold/amber accents (#d4a574), DM Serif Display typography +- Graph-first layout: 75% graph + 360px right sidebar +- No ChatPanel or Monaco Editor +- Sidebar tabs: `Info` (ProjectOverview default → NodeInfo when node selected → LearnPanel in Learn persona, composing) and `Files` (FileExplorer tree built from the structural graph) +- Code viewer: prism-react-renderer source viewer that slides up from the bottom on file node click; an expand button promotes it into a full-screen modal. Source content is fetched from the dev server's `/file-content.json` endpoint, gated by access token + a graph-derived path allowlist +- Schema validation on graph load with error banner + +## Agent Pipeline +- Agents write intermediate results to `.understand-anything/intermediate/` on disk (not returned to context) +- Agent model field is omitted from frontmatter so each platform falls back to its configured default — `inherit` was a Claude Code-only keyword that opencode (and similar tools) treated as a literal model id and rejected with `ProviderModelNotFoundError` (see #167) +- `/understand` auto-triggers `/understand-dashboard` after completion +- Intermediate files cleaned up after graph assembly + +## Key Commands +- `pnpm install` — Install all dependencies +- `pnpm --filter @understand-anything/core build` — Build the core package +- `pnpm --filter @understand-anything/core test` — Run core tests +- `pnpm --filter @understand-anything/skill build` — Build the plugin package +- `pnpm test` — Run all tests (skill tests live at repo-root `tests/skill/`, picked up by root `vitest.config.ts`) +- `pnpm --filter @understand-anything/dashboard build` — Build the dashboard +- `pnpm dev:dashboard` — Start dashboard dev server +- `pnpm lint` — Run ESLint across the project + +## Conventions +- TypeScript strict mode everywhere +- Vitest for testing +- ESM modules (`"type": "module"`) +- Knowledge graph JSON lives in `.understand-anything/` directory of analyzed projects +- Core uses subpath exports (`./search`, `./types`, `./schema`) to avoid pulling Node.js modules into browser + +## Gotchas +- **tree-sitter**: Uses `web-tree-sitter` (WASM) instead of native `tree-sitter` — native bindings fail on darwin/arm64 + Node 24 +- **Dashboard imports**: Dashboard must only import from core's browser-safe subpath exports (`./search`, `./types`, `./schema`), never the main entry point which pulls in Node.js modules + +## Scripts +- `scripts/generate-large-graph.mjs` — Generates a fake knowledge graph for performance testing (e.g. large-graph layout). Writes to `.understand-anything/knowledge-graph.json`. Usage: `node scripts/generate-large-graph.mjs [nodeCount]` (default: 3000 nodes). Not part of the production pipeline. + +## Versioning +When pushing to remote, bump the version in **all five** of these files (keep them in sync): +- `understand-anything-plugin/package.json` → `"version"` field +- `understand-anything-plugin/.claude-plugin/plugin.json` → `"version"` field +- `.claude-plugin/plugin.json` → `"version"` field +- `.cursor-plugin/plugin.json` → `"version"` field +- `.copilot-plugin/plugin.json` → `"version"` field + +Note: `.claude-plugin/marketplace.json` does **not** carry a version — the `plugins[]` entry only supports `name` and `source`, and adding other fields causes marketplace schema validation failures. + +## Testing Local Plugin Changes + +Claude Code caches installed plugins at `~/.claude/plugins/cache/understand-anything/understand-anything//`. Symlinks don't work because Claude's Search/Glob tools can't follow them. To test local changes: + +1. **Build the packages:** + ```bash + pnpm --filter @understand-anything/core build + pnpm --filter @understand-anything/skill build + ``` + +2. **Find the installed version** (must match what the marketplace currently serves): + ```bash + ls ~/.claude/plugins/cache/understand-anything/understand-anything/ + ``` + +3. **Copy your local plugin into the cache**, replacing `` with the version from step 2: + ```bash + rm -rf ~/.claude/plugins/cache/understand-anything/understand-anything/ + cp -R ./understand-anything-plugin ~/.claude/plugins/cache/understand-anything/understand-anything/ + ``` + +4. **Start a fresh Claude Code session** (existing sessions cache the old prompts in context). + +5. **Run `/understand --full`** in the target project to verify. + +**Re-sync after further changes:** +```bash +pnpm --filter @understand-anything/core build && \ +cp -R ./understand-anything-plugin/* ~/.claude/plugins/cache/understand-anything/understand-anything// +``` + +**To revert to upstream:** Uninstall and reinstall the plugin from the marketplace — it repopulates the cache from the upstream repo. diff --git a/Understand-Anything-main/CONTRIBUTING.md b/Understand-Anything-main/CONTRIBUTING.md new file mode 100644 index 0000000..a6b4386 --- /dev/null +++ b/Understand-Anything-main/CONTRIBUTING.md @@ -0,0 +1,274 @@ +# Contributing to Understand Anything + +Thank you for your interest in contributing to Understand Anything! This document provides guidelines and instructions for contributing to the project. + +## 🌟 Ways to Contribute + +- **Bug Reports**: Found a bug? Open an issue with detailed reproduction steps +- **Feature Requests**: Have an idea? Share it in the issues section +- **Documentation**: Improve or translate documentation +- **Code**: Fix bugs, add features, or improve performance +- **Testing**: Write tests to improve code coverage + +## 🚀 Getting Started + +### Prerequisites + +- Node.js >= 22 (developed on v24) +- pnpm >= 10 (pinned via `packageManager` field in root `package.json`) +- Git for version control + +### Setup + +1. **Fork and Clone** + ```bash + git clone https://github.com/YOUR_USERNAME/Understand-Anything.git + cd Understand-Anything + ``` + +2. **Install Dependencies** + ```bash + pnpm install + ``` + +3. **Build Core Package** + ```bash + pnpm --filter @understand-anything/core build + ``` + +4. **Run Tests** + ```bash + pnpm --filter @understand-anything/core test + pnpm --filter @understand-anything/skill test + ``` + +5. **Start Dashboard (Optional)** + ```bash + pnpm dev:dashboard + ``` + +## 📝 Development Workflow + +### 1. Create a Branch + +Create a descriptive branch name: +```bash +git checkout -b feat/my-feature # For new features +git checkout -b fix/bug-description # For bug fixes +git checkout -b docs/update-readme # For documentation +``` + +### 2. Make Changes + +- Write clean, readable code +- Follow existing code style and conventions +- Add tests for new functionality +- Update documentation as needed + +### 3. Test Your Changes + +```bash +# Run all tests +pnpm --filter @understand-anything/core test +pnpm --filter @understand-anything/skill test + +# Run linter +pnpm lint + +# Build packages +pnpm build +``` + +### 4. Commit Your Changes + +Write clear, descriptive commit messages: +```bash +git add . +git commit -m "feat: add keyboard shortcuts to dashboard" +``` + +**Commit Message Convention:** +- `feat:` - New feature +- `fix:` - Bug fix +- `docs:` - Documentation changes +- `style:` - Code style changes (formatting, etc.) +- `refactor:` - Code refactoring +- `test:` - Adding or updating tests +- `chore:` - Maintenance tasks + +### 5. Push and Create Pull Request + +```bash +git push origin your-branch-name +``` + +Then open a Pull Request on GitHub with: +- Clear title describing the change +- Detailed description of what changed and why +- Link to related issues (if any) +- Screenshots (for UI changes) + +## 🧪 Testing Guidelines + +### Writing Tests + +- Use Vitest for testing +- Place tests in `__tests__` directories or `*.test.ts` files +- Aim for high test coverage for new features +- Test edge cases and error conditions + +Example test structure: +```typescript +import { describe, it, expect } from 'vitest'; + +describe('MyFeature', () => { + it('should do something', () => { + // Arrange + const input = 'test'; + + // Act + const result = myFunction(input); + + // Assert + expect(result).toBe('expected'); + }); +}); +``` + +### Running Tests + +```bash +# Run all tests +pnpm test + +# Run tests for specific package +pnpm --filter @understand-anything/core test + +# Run tests in watch mode +pnpm --filter @understand-anything/core test --watch +``` + +## 📚 Code Style Guidelines + +### TypeScript + +- Use TypeScript strict mode +- Define explicit types for function parameters and return values +- Avoid `any` type - use `unknown` if type is truly unknown +- Use interfaces for object shapes +- Use type aliases for unions and complex types + +### Formatting + +- The project uses ESLint for code quality +- Consistent indentation (2 spaces) +- Use meaningful variable and function names +- Keep functions small and focused + +### React/Dashboard + +- Use functional components with hooks +- Keep components focused and single-purpose +- Use Zustand for state management +- Follow the existing component structure + +### Tech Stack + +TypeScript, pnpm workspaces, React 18, Vite, TailwindCSS v4, React Flow, Zustand, web-tree-sitter, Fuse.js, Zod, Dagre + +### File Organization + +``` +understand-anything-plugin/ +├── packages/ +│ ├── core/ # Core analysis engine +│ │ ├── src/ +│ │ └── package.json +│ └── dashboard/ # React dashboard +│ ├── src/ +│ │ ├── components/ +│ │ ├── utils/ +│ │ └── store.ts +│ └── package.json +├── src/ # Plugin skills implementation +├── agents/ # AI agent prompts +└── skills/ # Skill definitions +``` + +## 🌍 Translation Guidelines + +### Adding a New Language + +1. Create `README.{language-code}.md` (e.g., `README.fr-FR.md`) +2. Translate all sections while maintaining formatting +3. Update main `README.md` to include language link +4. Keep technical terms in English where appropriate +5. Ensure all links still work + +Example: +```markdown +English | Français +``` + +## 🐛 Bug Reports + +When reporting bugs, include: + +- **Description**: Clear description of the issue +- **Steps to Reproduce**: Detailed steps to reproduce the bug +- **Expected Behavior**: What you expected to happen +- **Actual Behavior**: What actually happened +- **Environment**: OS, Node version, pnpm version +- **Screenshots**: If applicable +- **Error Messages**: Full error output + +## 💡 Feature Requests + +When requesting features: + +- **Use Case**: Describe the problem you're trying to solve +- **Proposed Solution**: How you envision the feature working +- **Alternatives**: Other solutions you've considered +- **Additional Context**: Any other relevant information + +## 📋 Pull Request Checklist + +Before submitting a PR, ensure: + +- [ ] Code follows the project's style guidelines +- [ ] All tests pass (`pnpm test`) +- [ ] New code has test coverage +- [ ] Documentation is updated (if needed) +- [ ] Commit messages follow convention +- [ ] PR description clearly explains changes +- [ ] No console.log or debug code left behind +- [ ] Branch is up to date with main + +## 🤝 Code Review Process + +1. **Automated Checks**: CI runs tests and linting +2. **Maintainer Review**: Project maintainers review the code +3. **Feedback**: Address any requested changes +4. **Approval**: Once approved, PR will be merged +5. **Cleanup**: Delete your branch after merge + +## 📞 Getting Help + +- **Issues**: For bugs and feature requests +- **Discussions**: For questions and general discussion +- **Documentation**: Check existing docs first + +## 📄 License + +By contributing, you agree that your contributions will be licensed under the MIT License. + +## 🙏 Recognition + +Contributors will be recognized in: +- GitHub contributors list +- Release notes (for significant contributions) +- Special mentions for exceptional contributions + +--- + +**Thank you for contributing to Understand Anything! Your contributions help make code understanding accessible to everyone.** 🚀 diff --git a/Understand-Anything-main/LICENSE b/Understand-Anything-main/LICENSE new file mode 100644 index 0000000..87c7ab2 --- /dev/null +++ b/Understand-Anything-main/LICENSE @@ -0,0 +1,21 @@ +MIT License + +Copyright (c) 2026 Yuxiang Lin + +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. diff --git a/Understand-Anything-main/README.md b/Understand-Anything-main/README.md new file mode 100644 index 0000000..3bdb4db --- /dev/null +++ b/Understand-Anything-main/README.md @@ -0,0 +1,348 @@ +

Understand Anything

+ +

+ Turn any codebase, knowledge base, or docs into an interactive knowledge graph you can explore, search, and ask questions about. +
+ Works with Claude Code, Codex, Cursor, Copilot, Gemini CLI, and more. +

+ +

+ Lum1104%2FUnderstand-Anything | Trendshift +

+ +

+ English | 简体中文 | 繁體中文 | 日本語 | 한국어 | Español | Türkçe | Русский +

+ +

+ Quick Start + License: MIT + Claude Code + Codex + Copilot + Copilot CLI + Gemini CLI + OpenCode + Vibe CLI + Trae + Homepage + Live Demo +

+ +

+ Understand Anything — Turn any codebase into an interactive knowledge graph +

+ +

+ 💬 Join the Discord community → +
+ Ask questions, share what you've built, get help from the community. +

+ +--- + +**You just joined a new team. The codebase is 200,000 lines of code. Where do you even start?** + +Understand Anything is a [Claude Code Plugin](https://code.claude.com/docs/en/plugins-reference#plugins-reference) that analyzes your project with a multi-agent pipeline, builds a knowledge graph of every file, function, class, and dependency, then gives you an interactive dashboard to explore it all visually. Stop reading code blind. Start seeing the big picture. + +> **The goal isn't a graph that wows you with how complex your codebase is — it's a graph that quietly teaches you how every piece fits together.** + +--- + +## ✨ Features + +> [!NOTE] +> **Want to skip the reading?** Try the [live demo](https://understand-anything.com/demo/) in our [homepage](https://understand-anything.com/) — a fully interactive dashboard you can pan, zoom, search, and explore right in your browser. + +### Explore the structural graph + +Navigate your codebase as an interactive knowledge graph — every file, function, and class is a node you can click, search, and explore. Select any node to see plain-English summaries, relationships, and guided tours. + +### Understand business logic + +Switch to the domain view and see how your code maps to real business processes — domains, flows, and steps laid out as a horizontal graph. + +### Analyze knowledge bases + +Point `/understand-knowledge` at a [Karpathy-pattern LLM wiki](https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f) and get a force-directed knowledge graph with community clustering. The deterministic parser extracts wikilinks and categories from `index.md`, then LLM agents discover implicit relationships, extract entities, and surface claims — turning your wiki into a navigable graph of interconnected ideas. + + + + + + + + + + + + + + +
+

🧭 Guided Tours

+

Auto-generated walkthroughs of the architecture, ordered by dependency. Learn the codebase in the right order.

+ 		+

🔍 Fuzzy & Semantic Search

+

Find anything by name or by meaning. Search "which parts handle auth?" and get relevant results across the graph.

+
+

📊 Diff Impact Analysis

+

See which parts of the system your changes affect before you commit. Understand ripple effects across the codebase.

+ 		+

🎭 Persona-Adaptive UI

+

The dashboard adjusts its detail level based on who you are — junior dev, PM, or power user.

+
+

🏗️ Layer Visualization

+

Automatic grouping by architectural layer — API, Service, Data, UI, Utility — with color-coded legend.

+ 		+

📚 Language Concepts

+

12 programming patterns (generics, closures, decorators, etc.) explained in context wherever they appear.

+
+ +--- + +## 🚀 Quick Start + +### 1. Install the plugin + +```bash +/plugin marketplace add Lum1104/Understand-Anything +/plugin install understand-anything +``` + +### 2. Analyze your codebase + +```bash +/understand +``` + +A multi-agent pipeline scans your project, extracts every file, function, class, and dependency, then builds a knowledge graph saved to `.understand-anything/knowledge-graph.json`. + +**Localized output:** Use `--language` to generate content in your preferred language: + +```bash +# Generate Chinese content (知识图节点描述和 Dashboard UI) +/understand --language zh + +# Supported languages: en (default), zh, zh-TW, ja, ko, ru +``` + +The `--language` parameter affects: +- Node summaries and descriptions in the knowledge graph +- Dashboard UI labels, buttons, and tooltips +- Guided tour explanations + +### 3. Explore the dashboard + +```bash +/understand-dashboard +``` + +An interactive web dashboard opens with your codebase visualized as a graph — color-coded by architectural layer, searchable, and clickable. Select any node to see its code, relationships, and a plain-English explanation. + +### 4. Keep learning + +```bash +# Ask anything about the codebase +/understand-chat How does the payment flow work? + +# Analyze impact of your current changes +/understand-diff + +# Deep-dive into a specific file or function +/understand-explain src/auth/login.ts + +# Generate an onboarding guide for new team members +/understand-onboard + +# Extract business domain knowledge (domains, flows, steps) +/understand-domain + +# Analyze a Karpathy-pattern LLM wiki knowledge base +/understand-knowledge ~/path/to/wiki + +# Re-run anytime — incremental by default (only re-analyzes changed files) +/understand + +# Auto-update on every commit via a post-commit hook +/understand --auto-update + +# Scope to a subdirectory (for huge monorepos) +/understand src/frontend +``` + +--- + +## 🌐 Multi-Platform Installation + +Understand-Anything works across multiple AI coding platforms. + +### Claude Code (Native) + +```bash +/plugin marketplace add Lum1104/Understand-Anything +/plugin install understand-anything +``` + +### One-line install (Codex / OpenCode / OpenClaw / Antigravity / Gemini CLI / Pi Agent / Vibe CLI / VS Code Copilot / Hermes / Cline / KIMI CLI / Trae) + +**macOS / Linux:** +```bash +curl -fsSL https://raw.githubusercontent.com/Lum1104/Understand-Anything/main/install.sh | bash +# or skip the prompt by passing the platform: +curl -fsSL https://raw.githubusercontent.com/Lum1104/Understand-Anything/main/install.sh | bash -s codex +``` + +**Windows (PowerShell):** +```powershell +iwr -useb https://raw.githubusercontent.com/Lum1104/Understand-Anything/main/install.ps1 | iex +``` + +The installer clones the repo to `~/.understand-anything/repo` and creates the right symlinks for the chosen platform. Restart your CLI/IDE afterwards. + +- Supported `` values: `gemini`, `codex`, `opencode`, `pi`, `openclaw`, `antigravity`, `vibe`, `vscode`, `hermes`, `cline`, `kimi`, `trae` +- Update later: `./install.sh --update` +- Uninstall: `./install.sh --uninstall ` + +### Cursor + +Cursor auto-discovers the plugin via `.cursor-plugin/plugin.json` when this repo is cloned. No manual installation needed — just clone and open in Cursor. + +If auto-discovery doesn't pick it up, install it manually: open **Cursor Settings → Plugins**, paste `https://github.com/Lum1104/Understand-Anything` into the search field, and add it from there. + +### VS Code + GitHub Copilot + +VS Code with GitHub Copilot (v1.108+) auto-discovers the plugin via `.copilot-plugin/plugin.json` when this repo is cloned. No manual installation needed — just clone and open in VS Code. + +For personal skills (available across all projects), run the `install.sh` above with the `vscode` platform. + +### Copilot CLI + +```bash +copilot plugin install Lum1104/Understand-Anything:understand-anything-plugin +``` + +### Platform Compatibility + +| Platform | Status | Install Method | +|----------|--------|----------------| +| Claude Code | ✅ Native | Plugin marketplace | +| Cursor | ✅ Supported | Auto-discovery | +| VS Code + GitHub Copilot | ✅ Supported | Auto-discovery | +| Copilot CLI | ✅ Supported | Plugin install | +| Codex | ✅ Supported | `install.sh codex` | +| OpenCode | ✅ Supported | `install.sh opencode` | +| OpenClaw | ✅ Supported | `install.sh openclaw` | +| Antigravity | ✅ Supported | `install.sh antigravity` | +| Gemini CLI | ✅ Supported | `install.sh gemini` | +| Pi Agent | ✅ Supported | `install.sh pi` | +| Vibe CLI | ✅ Supported | `install.sh vibe` | +| Hermes | ✅ Supported | `install.sh hermes` | +| Cline | ✅ Supported | `install.sh cline` | +| KIMI CLI | ✅ Supported | `install.sh kimi` | +| Trae | ✅ Supported | `install.sh trae` | + +--- + +## 📦 Share the Graph with Your Team + +The graph is just JSON — **commit it once, and teammates skip the pipeline**. Good for onboarding, PR reviews, and docs-as-code. + +> **Example:** [GoogleCloudPlatform/microservices-demo (fork)](https://github.com/Lum1104/microservices-demo) — Go / Java / Python / Node reference with a committed graph. + +**What to commit:** everything in `.understand-anything/` *except* `intermediate/` and `diff-overlay.json` (those are local scratch). + +```gitignore +.understand-anything/intermediate/ +.understand-anything/diff-overlay.json +``` + +**Keep it fresh:** enable `/understand --auto-update` — a post-commit hook incrementally patches the graph so each commit lands with a matching graph. Or re-run `/understand` manually before releases. + +**Large graphs (10 MB+):** track with **git-lfs**. + +```bash +git lfs install +git lfs track ".understand-anything/*.json" +git add .gitattributes .understand-anything/ +``` + +--- + +## 🔧 Under the Hood + +### Tree-sitter + LLM hybrid + +Static analysis and LLMs do what each does best: + +- **Tree-sitter (deterministic)** — parses source into a concrete syntax tree and extracts structural facts: imports, exports, function/class definitions, call sites, inheritance. Pre-resolved into an `importMap` during the scan phase and passed to file-analyzers so they don't re-derive imports from source. Same input → same output, every run. Also powers fingerprint-based change detection for incremental updates. +- **LLM (semantic)** — reads the parsed structure alongside the original source to produce what parsers can't: plain-English summaries, tags, architectural layer assignments, business-domain mapping, guided tours, language concept callouts. + +This split is why the graph is reproducible on the structural side (the same code always yields the same edges) while still capturing intent on the semantic side (what a file is *for*, not just what it imports). + +### Multi-Agent Pipeline + +The `/understand` command orchestrates 5 specialized agents, and `/understand-domain` adds a 6th: + +| Agent | Role | +|-------|------| +| `project-scanner` | Discover files, detect languages and frameworks | +| `file-analyzer` | Extract functions, classes, imports; produce graph nodes and edges | +| `architecture-analyzer` | Identify architectural layers | +| `tour-builder` | Generate guided learning tours | +| `graph-reviewer` | Validate graph completeness and referential integrity (runs inline by default; use `--review` for full LLM review) | +| `domain-analyzer` | Extract business domains, flows, and process steps (used by `/understand-domain`) | +| `article-analyzer` | Extract entities, claims, and implicit relationships from wiki articles (used by `/understand-knowledge`) | + +File analyzers run in parallel (up to 5 concurrent, 20-30 files per batch). Supports incremental updates — only re-analyzes files that changed since the last run. + +--- + +## 🎥 Community + +A community-made walkthrough by **Better Stack**. + +

+ Community walkthrough by Better Stack — watch on YouTube +
+ Watch on YouTube → +

+ +Made a video, blog post, or tutorial? Open an issue or PR — happy to feature it here. + +--- + +## 🤝 Contributing + +Contributions are welcome! Here's how to get started: + +1. Fork the repository +2. Create a feature branch (`git checkout -b feature/my-feature`) +3. Run the tests (`pnpm --filter @understand-anything/core test`) +4. Commit your changes and open a pull request + +Please open an issue first for major changes so we can discuss the approach. + +--- + +

+ Stop reading code blind. Start understanding everything. +

+ +## Star History + + + + + + Star History Chart + + + +

+ Thanks to everyone who's used and contributed — knowing this saves people time is what made it worth building. +

+ +

+ MIT License © Lum1104 +

diff --git a/Understand-Anything-main/READMEs/README.es-ES.md b/Understand-Anything-main/READMEs/README.es-ES.md new file mode 100644 index 0000000..542d83b --- /dev/null +++ b/Understand-Anything-main/READMEs/README.es-ES.md @@ -0,0 +1,344 @@ +

Understand Anything

+

+ Convierte cualquier código fuente, base de conocimiento o documentación en un grafo de conocimiento interactivo que puedes explorar, buscar y consultar. +
+ Compatible con Claude Code, Codex, Cursor, Copilot, Gemini CLI y más. +

+ +

+ Lum1104%2FUnderstand-Anything | Trendshift +

+ +

+ English | 简体中文 | 繁體中文 | 日本語 | 한국어 | Español | Türkçe | Русский +

+ +

+ Quick Start + License: MIT + Claude Code + Codex + Copilot + Copilot CLI + Gemini CLI + OpenCode + Homepage + Live Demo +

+ +

+ Understand Anything — Convierte cualquier código fuente en un grafo de conocimiento interactivo +

+ +

+ 💬 Únete a la comunidad de Discord → +
+ Pregunta, comparte lo que construyes y recibe ayuda de la comunidad. +

+ +--- + +**Acabas de unirte a un nuevo equipo. El código tiene 200,000 líneas. ¿Por dónde empiezas?** + +Understand Anything es un [Claude Code Plugin](https://code.claude.com/docs/en/plugins-reference#plugins-reference) que analiza tu proyecto con un pipeline multi-agente, construye un grafo de conocimiento de cada archivo, función, clase y dependencia, y luego te ofrece un panel interactivo para explorarlo visualmente. Deja de leer código a ciegas. Empieza a ver el panorama completo. + +> **El objetivo no es un grafo que te impresione mostrándote lo complejo que es tu código — es un grafo que, sin alardes, te enseña cómo encaja cada pieza.** + +--- + +## ✨ Características + +> [!NOTE] +> **¿Quieres probarlo directamente?** Prueba la [demo en vivo](https://understand-anything.com/demo/) en nuestra [página principal](https://understand-anything.com/) — un panel interactivo donde puedes navegar, hacer zoom, buscar y explorar directamente en tu navegador. + +### Explora el grafo estructural + +Navega tu código como un grafo de conocimiento interactivo: cada archivo, función y clase es un nodo que puedes hacer clic, buscar y explorar. Selecciona cualquier nodo para ver resúmenes en lenguaje natural, relaciones y recorridos guiados. + +### Comprende la lógica de negocio + +Cambia a la vista de dominio y observa cómo tu código se mapea a procesos de negocio reales: dominios, flujos y pasos representados como un grafo horizontal. + +### Analiza bases de conocimiento + +Apunta `/understand-knowledge` a un [wiki LLM con patrón Karpathy](https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f) y obtén un grafo de conocimiento dirigido por fuerzas con agrupación por comunidad. El parser determinístico extrae wikilinks y categorías de `index.md`, luego los agentes LLM descubren relaciones implícitas, extraen entidades y revelan afirmaciones, convirtiendo tu wiki en un grafo navegable de ideas interconectadas. + + + + + + + + + + + + + + +
+

🧭 Recorridos Guiados

+

Recorridos generados automáticamente de la arquitectura, ordenados por dependencia. Aprende el código en el orden correcto.

+ 		+

🔍 Búsqueda Difusa y Semántica

+

Encuentra cualquier cosa por nombre o por significado. Busca "¿qué partes manejan la autenticación?" y obtén resultados relevantes en todo el grafo.

+
+

📊 Análisis de Impacto de Cambios

+

Visualiza qué partes del sistema afectan tus cambios antes de hacer commit. Comprende los efectos en cascada a través del código.

+ 		+

🎭 Interfaz Adaptativa por Persona

+

El panel ajusta su nivel de detalle según quién eres: desarrollador junior, PM o usuario avanzado.

+
+

🏗️ Visualización por Capas

+

Agrupación automática por capa arquitectónica — API, Servicio, Datos, UI, Utilidades — con leyenda codificada por colores.

+ 		+

📚 Conceptos del Lenguaje

+

12 patrones de programación (genéricos, closures, decoradores, etc.) explicados en contexto donde aparecen.

+
+ +--- + +## 🚀 Inicio Rápido + +### 1. Instala el plugin + +```bash +/plugin marketplace add Lum1104/Understand-Anything +/plugin install understand-anything +``` + +### 2. Analiza tu código + +```bash +/understand +``` + +Un pipeline multi-agente escanea tu proyecto, extrae cada archivo, función, clase y dependencia, y construye un grafo de conocimiento guardado en `.understand-anything/knowledge-graph.json`. + +**Salida localizada:** Usa `--language` para generar contenido en tu idioma preferido: + +```bash +# Genera contenido en el idioma preferido (descripciones de nodos y UI del dashboard) +/understand --language en + +# Idiomas soportados: en (default), zh, zh-TW, ja, ko, ru +``` + +El parámetro `--language` afecta: +- Resúmenes y descripciones de nodos en el grafo de conocimiento +- Etiquetas, botones y tooltips de la UI del dashboard +- Explicaciones de los tours guiados + +### 3. Explora el panel + +```bash +/understand-dashboard +``` + +Se abre un panel web interactivo con tu código visualizado como un grafo, codificado por colores según la capa arquitectónica, con funciones de búsqueda y clic. Selecciona cualquier nodo para ver su código, relaciones y una explicación en lenguaje natural. + +### 4. Sigue aprendiendo + +```bash +# Pregunta cualquier cosa sobre el código +/understand-chat How does the payment flow work? + +# Analiza el impacto de tus cambios actuales +/understand-diff + +# Profundiza en un archivo o función específica +/understand-explain src/auth/login.ts + +# Genera una guía de incorporación para nuevos miembros del equipo +/understand-onboard + +# Extrae conocimiento de dominio de negocio (dominios, flujos, pasos) +/understand-domain + +# Analiza un wiki LLM con patrón Karpathy +/understand-knowledge ~/path/to/wiki + +# Vuelve a ejecutarlo cuando quieras — incremental por defecto (solo archivos modificados) +/understand + +# Instala un hook post-commit para actualizaciones incrementales automáticas +/understand --auto-update + +# Acota el análisis a un subdirectorio (útil para monorepos enormes) +/understand src/frontend +``` + +--- + +## 🌐 Instalación Multiplataforma + +Understand-Anything funciona en múltiples plataformas de codificación con IA. + +### Claude Code (Nativo) + +```bash +/plugin marketplace add Lum1104/Understand-Anything +/plugin install understand-anything +``` + +### Instalación de una línea (Codex / OpenCode / OpenClaw / Antigravity / Gemini CLI / Pi Agent / Vibe CLI / VS Code Copilot / Hermes / Cline / KIMI CLI) + +**macOS / Linux:** +```bash +curl -fsSL https://raw.githubusercontent.com/Lum1104/Understand-Anything/main/install.sh | bash +# o pasa la plataforma directamente para saltar el prompt: +curl -fsSL https://raw.githubusercontent.com/Lum1104/Understand-Anything/main/install.sh | bash -s codex +``` + +**Windows (PowerShell):** +```powershell +iwr -useb https://raw.githubusercontent.com/Lum1104/Understand-Anything/main/install.ps1 | iex +``` + +El instalador clona el repositorio en `~/.understand-anything/repo` y crea los enlaces simbólicos correspondientes para la plataforma elegida. Reinicia tu CLI/IDE al terminar. + +- Valores soportados de ``: `gemini`, `codex`, `opencode`, `pi`, `openclaw`, `antigravity`, `vibe`, `vscode`, `hermes`, `cline`, `kimi` +- Actualizar más adelante: `./install.sh --update` +- Desinstalar: `./install.sh --uninstall ` + +### Cursor + +Cursor detecta automáticamente el plugin a través de `.cursor-plugin/plugin.json` cuando se clona este repositorio. No requiere instalación manual: simplemente clona y abre en Cursor. + +Si la detección automática no lo reconoce, instálalo manualmente: abre **Cursor Settings → Plugins**, pega `https://github.com/Lum1104/Understand-Anything` en el campo de búsqueda y añádelo desde allí. + +### VS Code + GitHub Copilot + +VS Code con GitHub Copilot (v1.108+) detecta automáticamente el plugin a través de `.copilot-plugin/plugin.json` cuando se clona este repositorio. No requiere instalación manual: simplemente clona y abre en VS Code. + +Para habilidades personales (disponibles en todos los proyectos), ejecuta el `install.sh` de arriba con la plataforma `vscode`. + +### Copilot CLI + +```bash +copilot plugin install Lum1104/Understand-Anything:understand-anything-plugin +``` + +### Compatibilidad de Plataformas + +| Plataforma | Estado | Método de Instalación | +|----------|--------|----------------| +| Claude Code | ✅ Nativo | Marketplace de plugins | +| Cursor | ✅ Soportado | Detección automática | +| VS Code + GitHub Copilot | ✅ Soportado | Detección automática | +| Copilot CLI | ✅ Soportado | Instalación de plugin | +| Codex | ✅ Soportado | `install.sh codex` | +| OpenCode | ✅ Soportado | `install.sh opencode` | +| OpenClaw | ✅ Soportado | `install.sh openclaw` | +| Antigravity | ✅ Soportado | `install.sh antigravity` | +| Gemini CLI | ✅ Soportado | `install.sh gemini` | +| Pi Agent | ✅ Soportado | `install.sh pi` | +| Vibe CLI | ✅ Soportado | `install.sh vibe` | +| Hermes | ✅ Soportado | `install.sh hermes` | +| Cline | ✅ Soportado | `install.sh cline` | +| KIMI CLI | ✅ Soportado | `install.sh kimi` | + +--- + +## 📦 Comparte el Grafo con tu Equipo + +El grafo es solo JSON — **confírmalo una vez y tus compañeros se saltan el pipeline**. Ideal para onboarding, revisiones de PR y flujos docs-as-code. + +> **Ejemplo:** [GoogleCloudPlatform/microservices-demo (fork)](https://github.com/Lum1104/microservices-demo) — referencia políglota (Go / Java / Python / Node) con el grafo ya confirmado. + +**Qué confirmar:** todo lo que hay en `.understand-anything/` *excepto* `intermediate/` y `diff-overlay.json` (archivos temporales locales). + +```gitignore +.understand-anything/intermediate/ +.understand-anything/diff-overlay.json +``` + +**Mantenlo al día:** activa `/understand --auto-update` — un hook post-commit parchea el grafo de forma incremental, así cada commit llega con su grafo correspondiente. O vuelve a ejecutar `/understand` manualmente antes de cada release. + +**Grafos grandes (10 MB o más):** úsalos con **git-lfs**. + +```bash +git lfs install +git lfs track ".understand-anything/*.json" +git add .gitattributes .understand-anything/ +``` + +--- + +## 🔧 Bajo el Capó + +### Híbrido Tree-sitter + LLM + +Lo determinista lo hace el análisis estático, lo semántico lo hace el LLM: + +- **Tree-sitter (determinista)** — parsea el código a un árbol de sintaxis concreto y extrae hechos estructurales: imports, exports, definiciones de funciones/clases, llamadas, herencia. Se preresuelve como `importMap` en la fase de escaneo y se pasa al file-analyzer para que no tenga que volver a derivar los imports desde el código fuente. La misma entrada siempre produce la misma salida, y también es la base de los fingerprints usados para las actualizaciones incrementales. +- **LLM (semántico)** — lee la estructura parseada junto con el código original para producir lo que los parsers no pueden: resúmenes en lenguaje natural, etiquetas, asignaciones de capa arquitectónica, mapeo de dominios de negocio, tours guiados, notas sobre conceptos del lenguaje. + +Esta división es la que hace que el grafo sea reproducible en lo estructural (el mismo código siempre genera las mismas aristas) y a la vez capture intención en lo semántico (para *qué* sirve un archivo, no solo qué importa). + +### Pipeline Multi-Agente + +El comando `/understand` orquesta 5 agentes especializados, y `/understand-domain` añade un sexto: + +| Agente | Rol | +|-------|------| +| `project-scanner` | Descubre archivos, detecta lenguajes y frameworks | +| `file-analyzer` | Extrae funciones, clases e importaciones; produce nodos y aristas del grafo | +| `architecture-analyzer` | Identifica capas arquitectónicas | +| `tour-builder` | Genera recorridos de aprendizaje guiados | +| `graph-reviewer` | Valida la completitud y la integridad referencial del grafo (se ejecuta inline por defecto; usa `--review` para una revisión completa con LLM) | +| `domain-analyzer` | Extrae dominios de negocio, flujos y pasos de proceso (usado por `/understand-domain`) | +| `article-analyzer` | Extrae entidades, afirmaciones y relaciones implícitas de artículos wiki (usado por `/understand-knowledge`) | + +Los analizadores de archivos se ejecutan en paralelo (hasta 5 concurrentes, 20-30 archivos por lote). Soporta actualizaciones incrementales: solo reanaliza los archivos que cambiaron desde la última ejecución. + +--- + +## 🎥 Comunidad + +Un recorrido en video hecho por la comunidad de **Better Stack**. + +

+ Recorrido en video por la comunidad de Better Stack — haz clic para ver en YouTube +
+ Ver en YouTube → +

+ +¿Has hecho un video, post o tutorial? Abre un issue o PR — estaremos encantados de mostrarlo aquí. + +--- + +## 🤝 Contribuir + +¡Las contribuciones son bienvenidas! Así puedes empezar: + +1. Haz fork del repositorio +2. Crea una rama de funcionalidad (`git checkout -b feature/my-feature`) +3. Ejecuta las pruebas (`pnpm --filter @understand-anything/core test`) +4. Haz commit de tus cambios y abre un pull request + +Para cambios importantes, abre primero un issue para que podamos discutir el enfoque. + +--- + +

+ Deja de leer código a ciegas. Empieza a entenderlo todo. +

+ +## Historial de Stars + + + + + + Star History Chart + + + +

+ Gracias a todas las personas que lo han usado y han contribuido — saber que les ahorra tiempo es lo que hizo que valiera la pena construirlo. +

+ +

+ Licencia MIT © Lum1104 +

diff --git a/Understand-Anything-main/READMEs/README.ja-JP.md b/Understand-Anything-main/READMEs/README.ja-JP.md new file mode 100644 index 0000000..cbe8a43 --- /dev/null +++ b/Understand-Anything-main/READMEs/README.ja-JP.md @@ -0,0 +1,345 @@ +

Understand Anything

+ +

+ あらゆるコードベース、ナレッジベース、ドキュメントを、探索・検索・質問ができるインタラクティブなナレッジグラフに変換します。 +
+ Claude Code、Codex、Cursor、Copilot、Gemini CLI など、マルチプラットフォーム対応。 +

+ +

+ Lum1104%2FUnderstand-Anything | Trendshift +

+ +

+ English | 简体中文 | 繁體中文 | 日本語 | 한국어 | Español | Türkçe | Русский +

+ +

+ クイックスタート + License: MIT + Claude Code + Codex + Copilot + Copilot CLI + Gemini CLI + OpenCode + ホームページ + ライブデモ +

+ +

+ Understand Anything — あらゆるコードベースをインタラクティブなナレッジグラフに変換 +

+ +

+ 💬 Discord コミュニティに参加 → +
+ 質問・作品の共有・コミュニティとの交流はこちらから。 +

+ +--- + +**新しいチームに参加したばかり。コードベースは20万行。どこから手をつければいいのか？** + +Understand Anything は [Claude Code Plugin](https://code.claude.com/docs/en/plugins-reference#plugins-reference) です。マルチエージェントパイプラインでプロジェクトを分析し、すべてのファイル・関数・クラス・依存関係のナレッジグラフを構築して、インタラクティブなダッシュボードで視覚的に探索できるようにします。コードを闇雲に読むのはやめて、全体像を把握しましょう。 + +> **目指すのは、コードベースの複雑さで圧倒するグラフではなく、すべてのパーツがどう噛み合っているかを静かに教えてくれるグラフ。** + +--- + +## ✨ 機能 + +> [!NOTE] +> **すぐに試したいですか？** [ホームページ](https://understand-anything.com/)で[ライブデモ](https://understand-anything.com/demo/)をお試しください — パン、ズーム、検索、探索ができる完全インタラクティブなダッシュボードです。 + +### コード構造グラフを探索 + +コードベースをインタラクティブなナレッジグラフとして表示——すべてのファイル、関数、クラスがクリック・検索・探索可能なノードです。ノードを選択すると、わかりやすい要約、依存関係、ガイド付きツアーが表示されます。 + +### ビジネスロジックを理解 + +ドメインビューに切り替えると、コードが実際のビジネスプロセスにどう対応するかが一目でわかります——ドメイン、フロー、ステップが横方向のグラフとして表示されます。 + +### ナレッジベースを分析 + +`/understand-knowledge` を [Karpathy パターンの LLM Wiki](https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f) に向けると、コミュニティクラスタリング付きのフォースディレクテッドナレッジグラフが生成されます。決定論的パーサーが `index.md` から wikilinks とカテゴリを抽出し、LLM エージェントが暗黙の関係を発見、エンティティを抽出、主張を浮き彫りにして、wiki をナビゲート可能な相互接続されたアイデアのグラフに変換します。 + + + + + + + + + + + + + + +
+

🧭 ガイドツアー

+

依存関係順に並べられた、自動生成のアーキテクチャウォークスルー。正しい順序でコードベースを学べます。

+ 		+

🔍 ファジー＆セマンティック検索

+

名前や意味で何でも検索できます。「認証を処理する部分は？」と検索すれば、グラフ全体から関連する結果が得られます。

+
+

📊 差分影響分析

+

コミット前に、変更がシステムのどの部分に影響するかを確認。コードベース全体への波及効果を把握できます。

+ 		+

🎭 ペルソナ適応型UI

+

ダッシュボードは、ジュニア開発者・PM・パワーユーザーなど、ユーザーに応じて詳細レベルを調整します。

+
+

🏗️ レイヤー可視化

+

API・Service・Data・UI・Utilityなどのアーキテクチャ層ごとに自動グループ化。色分けされた凡例付き。

+ 		+

📚 言語コンセプト

+

ジェネリクス・クロージャ・デコレータなど12のプログラミングパターンが、出現箇所のコンテキストで説明されます。

+
+ +--- + +## 🚀 クイックスタート + +### 1. プラグインをインストール + +```bash +/plugin marketplace add Lum1104/Understand-Anything +/plugin install understand-anything +``` + +### 2. コードベースを分析 + +```bash +/understand +``` + +マルチエージェントパイプラインがプロジェクトをスキャンし、すべてのファイル・関数・クラス・依存関係を抽出して、`.understand-anything/knowledge-graph.json` にナレッジグラフを保存します。 + +**ローカライズされた出力：** `--language` を使用して、希望の言語でコンテンツを生成： + +```bash +# 日本語でコンテンツを生成（ナレッジグラフのノード説明とダッシュボードUI） +/understand --language ja + +# サポート言語：en（デフォルト）、zh、zh-TW、ja、ko、ru +``` + +`--language` パラメータは以下に影響します： +- ナレッジグラフのノードサマリーと説明 +- ダッシュボードUIのラベル、ボタン、ツールチップ +- ガイド付きツアーの説明 + +### 3. ダッシュボードで探索 + +```bash +/understand-dashboard +``` + +インタラクティブなWebダッシュボードが開き、コードベースがグラフとして可視化されます。アーキテクチャ層ごとに色分けされ、検索やクリックが可能です。ノードを選択すると、コード・関連関係・平易な説明が表示されます。 + +### 4. さらに学ぶ + +```bash +# コードベースについて何でも質問 +/understand-chat 支払いフローはどう動いているの？ + +# 現在の変更の影響を分析 +/understand-diff + +# 特定のファイルや関数を詳しく調べる +/understand-explain src/auth/login.ts + +# 新メンバー向けのオンボーディングガイドを生成 +/understand-onboard + +# ビジネスドメイン知識を抽出（ドメイン、フロー、ステップ） +/understand-domain + +# Karpathy パターンの LLM Wiki ナレッジベースを分析 +/understand-knowledge ~/path/to/wiki + +# いつでも再実行 —— デフォルトでインクリメンタル（変更ファイルのみ再分析） +/understand + +# post-commit フックをインストールしてコミットごとに自動更新 +/understand --auto-update + +# 巨大なモノレポでも安心 —— サブディレクトリにスコープを絞る +/understand src/frontend +``` + +--- + +## 🌐 マルチプラットフォームインストール + +Understand-Anythingは複数のAIコーディングプラットフォームで動作します。 + +### Claude Code（ネイティブ） + +```bash +/plugin marketplace add Lum1104/Understand-Anything +/plugin install understand-anything +``` + +### ワンラインインストール（Codex / OpenCode / OpenClaw / Antigravity / Gemini CLI / Pi Agent / Vibe CLI / VS Code Copilot / Hermes / Cline / KIMI CLI） + +**macOS / Linux：** +```bash +curl -fsSL https://raw.githubusercontent.com/Lum1104/Understand-Anything/main/install.sh | bash +# プラットフォームを直接指定して対話プロンプトをスキップすることもできます： +curl -fsSL https://raw.githubusercontent.com/Lum1104/Understand-Anything/main/install.sh | bash -s codex +``` + +**Windows（PowerShell）：** +```powershell +iwr -useb https://raw.githubusercontent.com/Lum1104/Understand-Anything/main/install.ps1 | iex +``` + +インストーラーはリポジトリを `~/.understand-anything/repo` にクローンし、選択したプラットフォーム用のシンボリックリンクを作成します。完了後はCLI/IDEを再起動してください。 + +- サポートされる `` 値：`gemini`、`codex`、`opencode`、`pi`、`openclaw`、`antigravity`、`vibe`、`vscode`、`hermes`、`cline`、`kimi` +- 後で更新：`./install.sh --update` +- アンインストール：`./install.sh --uninstall ` + +### Cursor + +Cursorはこのリポジトリをクローンすると `.cursor-plugin/plugin.json` 経由でプラグインを自動検出します。手動インストールは不要です — クローンしてCursorで開くだけです。 + +自動検出されない場合は、手動でインストールしてください：**Cursor Settings → Plugins** を開き、検索欄に `https://github.com/Lum1104/Understand-Anything` を貼り付けて追加します。 + +### VS Code + GitHub Copilot + +GitHub Copilot拡張機能（v1.108+）をインストールしたVS Codeは、`.copilot-plugin/plugin.json` 経由でプラグインを自動検出します。クローンしてVS Codeで開くだけで、手動インストールは不要です。 + +全プロジェクトで使用するパーソナルスキルとして導入したい場合は、上記の `install.sh` を `vscode` プラットフォームで実行してください。 + +### Copilot CLI + +```bash +copilot plugin install Lum1104/Understand-Anything:understand-anything-plugin +``` + +### プラットフォーム互換性 + +| プラットフォーム | ステータス | インストール方法 | +|----------|--------|----------------| +| Claude Code | ✅ ネイティブ | プラグインマーケットプレイス | +| Cursor | ✅ サポート | 自動検出 | +| VS Code + GitHub Copilot | ✅ サポート | 自動検出 | +| Copilot CLI | ✅ サポート | プラグインインストール | +| Codex | ✅ サポート | `install.sh codex` | +| OpenCode | ✅ サポート | `install.sh opencode` | +| OpenClaw | ✅ サポート | `install.sh openclaw` | +| Antigravity | ✅ サポート | `install.sh antigravity` | +| Gemini CLI | ✅ サポート | `install.sh gemini` | +| Pi Agent | ✅ サポート | `install.sh pi` | +| Vibe CLI | ✅ サポート | `install.sh vibe` | +| Hermes | ✅ サポート | `install.sh hermes` | +| Cline | ✅ サポート | `install.sh cline` | +| KIMI CLI | ✅ サポート | `install.sh kimi` | + +--- + +## 📦 チームでグラフを共有する + +グラフは単なる JSON ファイルです——**一度コミットすれば、チームメンバーはパイプラインを実行せずに済みます**。オンボーディング、PR レビュー、docs-as-code ワークフローに最適です。 + +> **例：** [GoogleCloudPlatform/microservices-demo（fork）](https://github.com/Lum1104/microservices-demo) —— コミット済みのグラフを含む Go / Java / Python / Node のリファレンスプロジェクト。 + +**コミット対象：** `.understand-anything/` 内のすべてのファイル。ただし `intermediate/` と `diff-overlay.json` は除きます（これらはローカルの一時ファイルです）。 + +```gitignore +.understand-anything/intermediate/ +.understand-anything/diff-overlay.json +``` + +**最新状態を保つ：** `/understand --auto-update` を有効にすると、post-commit フックがグラフを増分的に更新し、各コミットに対応するグラフが揃います。またはリリース前に `/understand` を手動で再実行します。 + +**大きなグラフ（10 MB 以上）：** **git-lfs** で管理します。 + +```bash +git lfs install +git lfs track ".understand-anything/*.json" +git add .gitattributes .understand-anything/ +``` + +--- + +## 🔧 内部の仕組み + +### Tree-sitter + LLM ハイブリッド + +決定論的にできることは静的解析、意味理解が必要なことは LLM、と役割を分けています： + +- **Tree-sitter（決定論的）** —— ソースコードを具象構文木にパースし、構造的事実を抽出します：import、export、関数／クラス定義、呼び出し位置、継承関係。スキャンフェーズで `importMap` として事前解決し、file-analyzer に渡すことで、ソースから再度 import を導出する必要をなくしています。同じ入力からは常に同じ出力が得られ、インクリメンタル更新のフィンガープリントの基盤にもなります。 +- **LLM（意味的）** —— パース済みの構造と原文ソースを併せて読み、パーサーには出せないものを生成します：plain-English の要約、タグ、アーキテクチャレイヤの割当、業務ドメインマッピング、ガイド付きツアー、言語コンセプトの注釈。 + +この分担により、構造面ではグラフが再現可能（同じコードからは常に同じエッジが出る）でありながら、意味面ではそのファイルが「何のために」あるのかという意図を捉えられます。 + +### マルチエージェントパイプライン + +`/understand` コマンドは5つの専門エージェントをオーケストレーションし、`/understand-domain` は6つ目を追加します： + +| エージェント | 役割 | +|-------|------| +| `project-scanner` | ファイルの検出、言語やフレームワークの検出 | +| `file-analyzer` | 関数・クラス・インポートの抽出、グラフノードとエッジの生成 | +| `architecture-analyzer` | アーキテクチャ層の特定 | +| `tour-builder` | ガイド学習ツアーの生成 | +| `graph-reviewer` | グラフの完全性と参照整合性の検証 | +| `domain-analyzer` | ビジネスドメイン、フロー、処理ステップの抽出（`/understand-domain` で使用） | +| `article-analyzer` | wiki 記事からエンティティ、主張、暗黙の関係を抽出（`/understand-knowledge` で使用） | + +ファイルアナライザーは並列実行されます（最大3つ同時）。インクリメンタル更新に対応しており、前回の実行から変更されたファイルのみを再分析します。 + +--- + +## 🎥 コミュニティ + +**Better Stack** によるコミュニティ製ウォークスルー動画。 + +

+ Better Stack によるコミュニティ製ウォークスルー動画 — クリックして YouTube で視聴 +
+ YouTube で視聴 → +

+ +動画、ブログ、チュートリアルを作成しましたか?Issue または PR を開いてください — ここで紹介させていただきます。 + +--- + +## 🤝 コントリビュート + +コントリビュートを歓迎します！始め方は以下の通りです： + +1. リポジトリをフォーク +2. フィーチャーブランチを作成（`git checkout -b feature/my-feature`） +3. テストを実行（`pnpm --filter @understand-anything/core test`） +4. 変更をコミットしてプルリクエストを作成 + +大きな変更については、まずIssueを作成してアプローチを議論してください。 + +--- + +

+ コードを闇雲に読むのはやめよう。すべてを理解しよう。 +

+ +## Star History + + + + + + Star History Chart + + + +

+ 使ってくれた、貢献してくれたすべての方へ ── 少しでも時間を節約できていると知ること、それがこれを作って良かったと思える理由です。 +

+ +

+ MIT License © Lum1104 +

diff --git a/Understand-Anything-main/READMEs/README.ko-KR.md b/Understand-Anything-main/READMEs/README.ko-KR.md new file mode 100644 index 0000000..2e51742 --- /dev/null +++ b/Understand-Anything-main/READMEs/README.ko-KR.md @@ -0,0 +1,344 @@ +

Understand Anything

+

+ 모든 코드베이스, 지식 베이스 또는 문서를 탐색, 검색, 질문할 수 있는 인터랙티브 지식 그래프로 변환합니다. +
+ Claude Code, Codex, Cursor, Copilot, Gemini CLI 등 다양한 플랫폼을 지원합니다. +

+ +

+ Lum1104%2FUnderstand-Anything | Trendshift +

+ +

+ English | 简体中文 | 繁體中文 | 日本語 | 한국어 | Español | Türkçe | Русский +

+ +

+ Quick Start + License: MIT + Claude Code + Codex + Copilot + Copilot CLI + Gemini CLI + OpenCode + Homepage + Live Demo +

+ +

+ Understand Anything — 모든 코드베이스를 인터랙티브 지식 그래프로 변환 +

+ +

+ 💬 Discord 커뮤니티 참여하기 → +
+ 질문하고, 만든 것을 공유하고, 커뮤니티의 도움을 받으세요. +

+ +--- + +**새 팀에 합류했습니다. 코드베이스가 20만 줄입니다. 어디서부터 시작하시겠습니까?** + +Understand Anything은 [Claude Code Plugin](https://code.claude.com/docs/en/plugins-reference#plugins-reference)으로, 멀티 에이전트 파이프라인을 통해 프로젝트를 분석하고, 모든 파일, 함수, 클래스, 의존성에 대한 지식 그래프를 구축한 뒤, 이를 시각적으로 탐색할 수 있는 인터랙티브 대시보드를 제공합니다. 더 이상 코드를 맹목적으로 읽지 마세요. 전체 그림을 파악하세요. + +> **목표는 코드베이스의 복잡함으로 감탄을 자아내는 그래프가 아니라, 각 조각이 어떻게 맞물리는지 조용히 가르쳐주는 그래프입니다.** + +--- + +## ✨ 주요 기능 + +> [!NOTE] +> **바로 체험해보세요!** [홈페이지](https://understand-anything.com/)에서 [라이브 데모](https://understand-anything.com/demo/)를 사용해보세요 — 팬, 줌, 검색, 탐색이 가능한 완전한 인터랙티브 대시보드입니다. + +### 구조 그래프 탐색 + +코드베이스를 인터랙티브 지식 그래프로 탐색하세요. 모든 파일, 함수, 클래스가 클릭, 검색, 탐색 가능한 노드입니다. 노드를 선택하면 이해하기 쉬운 요약, 관계, 가이드 투어를 확인할 수 있습니다. + +### 비즈니스 로직 이해 + +도메인 뷰로 전환하면 코드가 실제 비즈니스 프로세스에 어떻게 매핑되는지 확인할 수 있습니다. 도메인, 흐름, 단계가 수평 그래프로 표시됩니다. + +### 지식 베이스 분석 + +`/understand-knowledge`를 [Karpathy 패턴 LLM 위키](https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f)에 연결하면 커뮤니티 클러스터링이 적용된 힘 기반 지식 그래프를 생성합니다. 결정론적 파서가 `index.md`에서 위키링크와 카테고리를 추출한 후, LLM 에이전트가 암묵적 관계를 발견하고, 엔티티를 추출하며, 주장을 도출하여 위키를 탐색 가능한 상호 연결된 아이디어 그래프로 변환합니다. + + + + + + + + + + + + + + +
+

🧭 가이드 투어

+

의존성 순서에 따라 자동 생성되는 아키텍처 워크스루입니다. 올바른 순서로 코드베이스를 학습하세요.

+ 		+

🔍 퍼지 및 시맨틱 검색

+

이름 또는 의미로 무엇이든 검색하세요. "인증을 처리하는 부분은?" 같은 질문으로 그래프 전체에서 관련 결과를 얻을 수 있습니다.

+
+

📊 변경 영향 분석

+

커밋 전에 변경 사항이 시스템의 어떤 부분에 영향을 미치는지 확인하세요. 코드베이스 전반의 파급 효과를 이해하세요.

+ 		+

🎭 페르소나 적응형 UI

+

사용자 유형(주니어 개발자, PM, 파워 유저)에 따라 대시보드의 상세 수준이 자동으로 조정됩니다.

+
+

🏗️ 레이어 시각화

+

아키텍처 레이어별 자동 그룹화 — API, 서비스, 데이터, UI, 유틸리티 — 색상 코드 범례가 함께 제공됩니다.

+ 		+

📚 프로그래밍 개념

+

12가지 프로그래밍 패턴(제네릭, 클로저, 데코레이터 등)이 코드에 등장하는 맥락에서 설명됩니다.

+
+ +--- + +## 🚀 빠른 시작 + +### 1. 플러그인 설치 + +```bash +/plugin marketplace add Lum1104/Understand-Anything +/plugin install understand-anything +``` + +### 2. 코드베이스 분석 + +```bash +/understand +``` + +멀티 에이전트 파이프라인이 프로젝트를 스캔하고, 모든 파일, 함수, 클래스, 의존성을 추출한 뒤, `.understand-anything/knowledge-graph.json`에 지식 그래프를 저장합니다. + +**로컬라이즈된 출력:** `--language`를 사용하여 원하는 언어로 내용을 생성: + +```bash +# 한국어로 내용 생성 (지식 그래프 노드 설명과 대시보드 UI) +/understand --language ko + +# 지원 언어: en(기본값), zh, zh-TW, ja, ko, ru +``` + +`--language` 매개변수는 다음에 영향합니다: +- 지식 그래프의 노드 요약과 설명 +- 대시보드 UI의 레이블, 버튼, 툴팁 +- 가이드 투어의 설명 + +### 3. 대시보드 탐색 + +```bash +/understand-dashboard +``` + +코드베이스가 그래프로 시각화된 인터랙티브 웹 대시보드가 열립니다. 아키텍처 레이어별로 색상이 구분되어 있으며, 검색과 클릭이 가능합니다. 노드를 선택하면 코드, 관계, 이해하기 쉬운 설명을 확인할 수 있습니다. + +### 4. 더 깊이 탐구하기 + +```bash +# 코드베이스에 대해 무엇이든 질문하기 +/understand-chat How does the payment flow work? + +# 현재 변경 사항의 영향 분석 +/understand-diff + +# 특정 파일이나 함수를 심층 분석 +/understand-explain src/auth/login.ts + +# 새 팀원을 위한 온보딩 가이드 생성 +/understand-onboard + +# 비즈니스 도메인 지식 추출 (도메인, 흐름, 단계) +/understand-domain + +# Karpathy 패턴 LLM 위키 지식 베이스 분석 +/understand-knowledge ~/path/to/wiki + +# 언제든 다시 실행 — 기본값은 증분 업데이트(변경된 파일만 재분석) +/understand + +# post-commit 훅을 설치해 매 커밋마다 자동 증분 업데이트 +/understand --auto-update + +# 거대한 모노레포라면 하위 디렉터리로 범위 제한 +/understand src/frontend +``` + +--- + +## 🌐 멀티 플랫폼 설치 + +Understand-Anything은 다양한 AI 코딩 플랫폼에서 사용할 수 있습니다. + +### Claude Code (네이티브) + +```bash +/plugin marketplace add Lum1104/Understand-Anything +/plugin install understand-anything +``` + +### 한 줄 설치 (Codex / OpenCode / OpenClaw / Antigravity / Gemini CLI / Pi Agent / Vibe CLI / VS Code Copilot / Hermes / Cline / KIMI CLI) + +**macOS / Linux:** +```bash +curl -fsSL https://raw.githubusercontent.com/Lum1104/Understand-Anything/main/install.sh | bash +# 플랫폼 이름을 직접 전달하여 프롬프트를 건너뛸 수도 있습니다: +curl -fsSL https://raw.githubusercontent.com/Lum1104/Understand-Anything/main/install.sh | bash -s codex +``` + +**Windows (PowerShell):** +```powershell +iwr -useb https://raw.githubusercontent.com/Lum1104/Understand-Anything/main/install.ps1 | iex +``` + +설치 스크립트는 저장소를 `~/.understand-anything/repo`에 클론하고 선택한 플랫폼에 맞는 심볼릭 링크를 생성합니다. 설치 후 CLI 또는 IDE를 재시작하세요. + +- 지원되는 `` 값: `gemini`, `codex`, `opencode`, `pi`, `openclaw`, `antigravity`, `vibe`, `vscode`, `hermes`, `cline`, `kimi` +- 이후 업데이트: `./install.sh --update` +- 제거: `./install.sh --uninstall ` + +### Cursor + +이 저장소를 클론하면 Cursor가 `.cursor-plugin/plugin.json`을 통해 플러그인을 자동으로 인식합니다. 수동 설치가 필요 없습니다. 클론 후 Cursor에서 열기만 하면 됩니다. + +자동 인식이 되지 않으면 수동으로 설치하세요: **Cursor Settings → Plugins**를 열고 검색란에 `https://github.com/Lum1104/Understand-Anything`를 붙여넣은 뒤 추가하세요. + +### VS Code + GitHub Copilot + +GitHub Copilot(v1.108+)이 설치된 VS Code는 `.copilot-plugin/plugin.json`을 통해 플러그인을 자동으로 인식합니다. 수동 설치가 필요 없습니다. 클론 후 VS Code에서 열기만 하면 됩니다. + +모든 프로젝트에서 사용하는 개인 스킬로 설치하려면 위 `install.sh`를 `vscode` 플랫폼으로 실행하세요. + +### Copilot CLI + +```bash +copilot plugin install Lum1104/Understand-Anything:understand-anything-plugin +``` + +### 플랫폼 호환성 + +| 플랫폼 | 상태 | 설치 방법 | +|----------|--------|----------------| +| Claude Code | ✅ 네이티브 | 플러그인 마켓플레이스 | +| Cursor | ✅ 지원 | 자동 인식 | +| VS Code + GitHub Copilot | ✅ 지원 | 자동 인식 | +| Copilot CLI | ✅ 지원 | 플러그인 설치 | +| Codex | ✅ 지원 | `install.sh codex` | +| OpenCode | ✅ 지원 | `install.sh opencode` | +| OpenClaw | ✅ 지원 | `install.sh openclaw` | +| Antigravity | ✅ 지원 | `install.sh antigravity` | +| Gemini CLI | ✅ 지원 | `install.sh gemini` | +| Pi Agent | ✅ 지원 | `install.sh pi` | +| Vibe CLI | ✅ 지원 | `install.sh vibe` | +| Hermes | ✅ 지원 | `install.sh hermes` | +| Cline | ✅ 지원 | `install.sh cline` | +| KIMI CLI | ✅ 지원 | `install.sh kimi` | + +--- + +## 📦 팀과 그래프 공유하기 + +그래프는 단지 JSON 파일입니다 — **한 번만 커밋하면 팀원은 파이프라인을 건너뛸 수 있습니다**. 온보딩, PR 리뷰, docs-as-code 워크플로에 적합합니다. + +> **예시:** [GoogleCloudPlatform/microservices-demo (fork)](https://github.com/Lum1104/microservices-demo) — 커밋된 그래프를 포함한 Go / Java / Python / Node 레퍼런스 프로젝트. + +**커밋할 대상:** `.understand-anything/` 내부의 모든 파일. 단, `intermediate/` 와 `diff-overlay.json` 은 제외합니다 (이들은 로컬 임시 파일입니다). + +```gitignore +.understand-anything/intermediate/ +.understand-anything/diff-overlay.json +``` + +**최신 상태 유지:** `/understand --auto-update` 를 활성화하면 post-commit 훅이 그래프를 증분 업데이트하여 각 커밋마다 일치하는 그래프가 유지됩니다. 또는 릴리스 전에 `/understand` 를 수동으로 다시 실행하세요. + +**대용량 그래프 (10 MB 이상):** **git-lfs** 로 추적합니다. + +```bash +git lfs install +git lfs track ".understand-anything/*.json" +git add .gitattributes .understand-anything/ +``` + +--- + +## 🔧 작동 원리 + +### Tree-sitter + LLM 하이브리드 + +결정적으로 처리할 수 있는 일은 정적 분석이, 의미 이해가 필요한 일은 LLM 이 담당합니다: + +- **Tree-sitter(결정적)** — 소스 코드를 구체 구문 트리로 파싱해 구조적 사실을 추출합니다: import, export, 함수/클래스 정의, 호출 위치, 상속. 스캔 단계에서 `importMap` 으로 사전 해석해 file-analyzer 에 전달하므로, 소스에서 다시 import 를 유도할 필요가 없습니다. 같은 입력은 항상 같은 출력을 내며, 증분 업데이트의 핑거프린트 기반이기도 합니다. +- **LLM(의미적)** — 파싱된 구조와 원본 소스를 함께 읽어 파서가 만들 수 없는 것들을 생성합니다: plain-English 요약, 태그, 아키텍처 레이어 할당, 비즈니스 도메인 매핑, 가이드 투어, 언어 개념 주석. + +이 분담 덕분에 그래프는 구조 측면에서는 재현 가능하면서(같은 코드는 항상 같은 엣지를 만든다), 의미 측면에서는 의도를 포착할 수 있습니다(파일이 단지 무엇을 import 하는지가 아니라 *무엇을 위해* 존재하는지). + +### 멀티 에이전트 파이프라인 + +`/understand` 명령은 5개의 전문 에이전트를 조율하며, `/understand-domain`은 6번째 에이전트를 추가합니다: + +| 에이전트 | 역할 | +|-------|------| +| `project-scanner` | 파일 탐색, 언어 및 프레임워크 감지 | +| `file-analyzer` | 함수, 클래스, 임포트 추출; 그래프 노드 및 엣지 생성 | +| `architecture-analyzer` | 아키텍처 레이어 식별 | +| `tour-builder` | 가이드 학습 투어 생성 | +| `graph-reviewer` | 그래프 완전성 및 참조 무결성 검증 (기본적으로 인라인 실행; 전체 LLM 검토는 `--review` 사용) | +| `domain-analyzer` | 비즈니스 도메인, 흐름 및 프로세스 단계 추출 (`/understand-domain`에서 사용) | +| `article-analyzer` | 위키 문서에서 엔티티, 주장 및 암묵적 관계 추출 (`/understand-knowledge`에서 사용) | + +파일 분석기는 병렬로 실행됩니다(최대 5개 동시, 배치당 20~30개 파일). 증분 업데이트를 지원하여 마지막 실행 이후 변경된 파일만 재분석합니다. + +--- + +## 🎥 커뮤니티 + +**Better Stack**에서 만든 커뮤니티 워크스루 영상. + +

+ Better Stack에서 만든 커뮤니티 워크스루 영상 — 클릭하여 YouTube에서 시청 +
+ YouTube에서 보기 → +

+ +영상, 블로그 글, 튜토리얼을 만드셨나요? 이슈나 PR을 열어주세요 — 여기서 소개해드릴게요. + +--- + +## 🤝 기여하기 + +기여를 환영합니다! 시작하는 방법은 다음과 같습니다: + +1. 저장소를 Fork합니다 +2. 기능 브랜치를 생성합니다 (`git checkout -b feature/my-feature`) +3. 테스트를 실행합니다 (`pnpm --filter @understand-anything/core test`) +4. 변경 사항을 커밋하고 Pull Request를 생성합니다 + +주요 변경 사항의 경우, 먼저 Issue를 열어 접근 방식을 논의해 주세요. + +--- + +

+ 더 이상 코드를 맹목적으로 읽지 마세요. 모든 것을 이해하세요. +

+ +## Star 히스토리 + + + + + + Star History Chart + + + +

+ 이 도구를 사용해 주시고 기여해 주신 모든 분들께 감사드립니다 — 누군가의 시간을 아껴드리고 있다는 사실이, 이걸 만들 가치가 있게 만든 이유였습니다. +

+ +

+ MIT 라이선스 © Lum1104 +

diff --git a/Understand-Anything-main/READMEs/README.ru-RU.md b/Understand-Anything-main/READMEs/README.ru-RU.md new file mode 100644 index 0000000..3b11cb3 --- /dev/null +++ b/Understand-Anything-main/READMEs/README.ru-RU.md @@ -0,0 +1,345 @@ +

Understand Anything

+ +

+ Превращай любую кодовую базу, базу знаний или документацию в интерактивный граф знаний, который можно исследовать, искать в нём и задавать вопросы. +
+ Работает с Claude Code, Codex, Cursor, Copilot, Gemini CLI и другими. +

+ +

+ Lum1104%2FUnderstand-Anything | Trendshift +

+ +

+ English | 简体中文 | 繁體中文 | 日本語 | 한국어 | Español | Türkçe | Русский +

+ +

+ Quick Start + License: MIT + Claude Code + Codex + Copilot + Copilot CLI + Gemini CLI + OpenCode + Homepage + Live Demo +

+ +

+ Understand Anything — Превратите любую кодовую базу в интерактивный граф знаний +

+ +

+ 💬 Присоединяйтесь к сообществу в Discord → +
+ Задавайте вопросы, делитесь тем, что вы построили, получайте помощь от сообщества. +

+ +--- + +**Вы только что присоединились к новой команде. Кодовая база — 200 000 строк. С чего вообще начинать?** + +Understand Anything — это [плагин для Claude Code](https://code.claude.com/docs/en/plugins-reference#plugins-reference), который анализирует ваш проект с помощью мультиагентного пайплайна, строит граф знаний из всех файлов, функций, классов и зависимостей, а затем предоставляет интерактивную панель, чтобы исследовать всё это визуально. Хватит читать код вслепую. Пора увидеть общую картину. + +> **Цель — не граф, который поражает сложностью вашей кодовой базы, а граф, который ненавязчиво объясняет, как все части складываются вместе.** + +--- + +## ✨ Возможности + +> [!NOTE] +> **Хотите пропустить чтение?** Попробуйте [живое демо](https://understand-anything.com/demo/) на нашем [сайте](https://understand-anything.com/) — полностью интерактивная панель, по которой можно перемещаться, масштабировать, искать и исследовать прямо в браузере. + +### Исследуйте структурный граф + +Перемещайтесь по своему коду как по интерактивному графу знаний — каждый файл, функция и класс является узлом, который можно кликнуть, найти и изучить. Выберите любой узел, чтобы увидеть понятные описания, связи и пошаговые обзоры. + +### Понимайте бизнес-логику + +Переключитесь на доменное представление и увидите, как ваш код отображается на реальные бизнес-процессы — домены, потоки и шаги, выстроенные в виде горизонтального графа. + +### Анализируйте базы знаний + +Направьте `/understand-knowledge` на [LLM-вики в стиле Карпати](https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f) и получите force-directed граф знаний с кластеризацией по сообществам. Детерминированный парсер извлекает wikilinks и категории из `index.md`, а LLM-агенты находят неявные связи, извлекают сущности и выявляют утверждения — превращая вашу вики в навигируемый граф взаимосвязанных идей. + + + + + + + + + + + + + + +
+

🧭 Пошаговые обзоры

+

Автоматически создаваемые экскурсии по архитектуре, упорядоченные по зависимостям. Изучайте кодовую базу в правильном порядке.

+ 		+

🔍 Нечёткий и семантический поиск

+

Находите что угодно по имени или по смыслу. Поищите «какие части отвечают за авторизацию?» и получите релевантные результаты по всему графу.

+
+

📊 Анализ влияния изменений

+

Смотрите, какие части системы затрагивают ваши изменения, ещё до коммита. Понимайте каскадные эффекты по всей кодовой базе.

+ 		+

🎭 UI, адаптирующийся к роли

+

Панель подстраивает уровень детализации под пользователя — junior-разработчика, PM или продвинутого пользователя.

+
+

🏗️ Визуализация слоёв

+

Автоматическая группировка по архитектурным слоям — API, Service, Data, UI, Utility — с цветовой легендой.

+ 		+

📚 Концепции языка

+

12 шаблонов программирования (дженерики, замыкания, декораторы и т.д.) объясняются в контексте там, где они встречаются.

+
+ +--- + +## 🚀 Быстрый старт + +### 1. Установите плагин + +```bash +/plugin marketplace add Lum1104/Understand-Anything +/plugin install understand-anything +``` + +### 2. Проанализируйте кодовую базу + +```bash +/understand +``` + +Мультиагентный пайплайн сканирует ваш проект, извлекает каждый файл, функцию, класс и зависимость, а затем строит граф знаний и сохраняет его в `.understand-anything/knowledge-graph.json`. + +**Локализованный вывод:** используйте `--language`, чтобы генерировать контент на нужном языке: + +```bash +# Генерация контента на русском (описания узлов графа знаний и UI панели) +/understand --language ru + +# Поддерживаемые языки: en (по умолчанию), zh, zh-TW, ja, ko, ru +``` + +Параметр `--language` влияет на: +- Резюме и описания узлов в графе знаний +- Подписи, кнопки и подсказки UI панели +- Объяснения в пошаговых обзорах + +### 3. Откройте панель + +```bash +/understand-dashboard +``` + +Открывается интерактивная веб-панель с визуализацией вашей кодовой базы в виде графа — с цветовой кодировкой по архитектурным слоям, поиском и кликабельными узлами. Выберите любой узел, чтобы увидеть его код, связи и описание простым языком. + +### 4. Продолжайте учиться + +```bash +# Задайте любой вопрос о кодовой базе +/understand-chat How does the payment flow work? + +# Проанализируйте влияние ваших текущих изменений +/understand-diff + +# Подробно разберитесь с конкретным файлом или функцией +/understand-explain src/auth/login.ts + +# Сгенерируйте онбординг-гайд для новых членов команды +/understand-onboard + +# Извлеките знания о бизнес-доменах (домены, потоки, шаги) +/understand-domain + +# Проанализируйте LLM-вики в стиле Карпати +/understand-knowledge ~/path/to/wiki + +# Перезапускайте когда угодно — по умолчанию инкрементально (только изменённые файлы) +/understand + +# Установите post-commit хук для автоматических инкрементальных обновлений +/understand --auto-update + +# Огромный монорепозиторий? Ограничьте анализ подкаталогом +/understand src/frontend +``` + +--- + +## 🌐 Установка на разных платформах + +Understand-Anything работает с несколькими платформами AI-разработки. + +### Claude Code (нативно) + +```bash +/plugin marketplace add Lum1104/Understand-Anything +/plugin install understand-anything +``` + +### Установка одной командой (Codex / OpenCode / OpenClaw / Antigravity / Gemini CLI / Pi Agent / Vibe CLI / VS Code Copilot / Hermes / Cline / KIMI CLI) + +**macOS / Linux:** +```bash +curl -fsSL https://raw.githubusercontent.com/Lum1104/Understand-Anything/main/install.sh | bash +# или передайте платформу, чтобы пропустить интерактивный выбор: +curl -fsSL https://raw.githubusercontent.com/Lum1104/Understand-Anything/main/install.sh | bash -s codex +``` + +**Windows (PowerShell):** +```powershell +iwr -useb https://raw.githubusercontent.com/Lum1104/Understand-Anything/main/install.ps1 | iex +``` + +Установщик клонирует репозиторий в `~/.understand-anything/repo` и создаёт нужные симлинки для выбранной платформы. После установки перезапустите свой CLI/IDE. + +- Поддерживаемые значения ``: `gemini`, `codex`, `opencode`, `pi`, `openclaw`, `antigravity`, `vibe`, `vscode`, `hermes`, `cline`, `kimi` +- Обновление: `./install.sh --update` +- Удаление: `./install.sh --uninstall ` + +### Cursor + +Cursor автоматически обнаруживает плагин через `.cursor-plugin/plugin.json` при клонировании этого репозитория. Ручная установка не требуется — просто склонируйте и откройте в Cursor. + +Если автообнаружение не сработало, установите вручную: откройте **Cursor Settings → Plugins**, вставьте `https://github.com/Lum1104/Understand-Anything` в поле поиска и добавьте оттуда. + +### VS Code + GitHub Copilot + +VS Code с GitHub Copilot (v1.108+) автоматически обнаруживает плагин через `.copilot-plugin/plugin.json` при клонировании этого репозитория. Ручная установка не требуется — просто склонируйте и откройте в VS Code. + +Для персональных skills (доступных во всех проектах) запустите `install.sh` выше с платформой `vscode`. + +### Copilot CLI + +```bash +copilot plugin install Lum1104/Understand-Anything:understand-anything-plugin +``` + +### Совместимость с платформами + +| Платформа | Статус | Способ установки | +|----------|--------|----------------| +| Claude Code | ✅ Нативно | Marketplace плагинов | +| Cursor | ✅ Поддерживается | Автообнаружение | +| VS Code + GitHub Copilot | ✅ Поддерживается | Автообнаружение | +| Copilot CLI | ✅ Поддерживается | Установка плагина | +| Codex | ✅ Поддерживается | `install.sh codex` | +| OpenCode | ✅ Поддерживается | `install.sh opencode` | +| OpenClaw | ✅ Поддерживается | `install.sh openclaw` | +| Antigravity | ✅ Поддерживается | `install.sh antigravity` | +| Gemini CLI | ✅ Поддерживается | `install.sh gemini` | +| Pi Agent | ✅ Поддерживается | `install.sh pi` | +| Vibe CLI | ✅ Поддерживается | `install.sh vibe` | +| Hermes | ✅ Поддерживается | `install.sh hermes` | +| Cline | ✅ Поддерживается | `install.sh cline` | +| KIMI CLI | ✅ Поддерживается | `install.sh kimi` | + +--- + +## 📦 Поделитесь графом с командой + +Граф — это просто JSON. **Зафиксируйте его один раз, и коллеги смогут пропустить весь пайплайн.** Полезно для онбординга, ревью PR и подхода docs-as-code. + +> **Пример:** [GoogleCloudPlatform/microservices-demo (форк)](https://github.com/Lum1104/microservices-demo) — мультиязыковой проект (Go / Java / Python / Node) с уже зафиксированным графом. + +**Что коммитить:** всё содержимое `.understand-anything/`, *кроме* `intermediate/` и `diff-overlay.json` (это локальные временные файлы). + +```gitignore +.understand-anything/intermediate/ +.understand-anything/diff-overlay.json +``` + +**Держите граф в актуальном состоянии:** включите `/understand --auto-update` — post-commit хук будет инкрементально обновлять граф, так что каждый коммит сопровождается соответствующим графом. Либо запускайте `/understand` вручную перед релизами. + +**Большие графы (10 МБ+):** храните через **git-lfs**. + +```bash +git lfs install +git lfs track ".understand-anything/*.json" +git add .gitattributes .understand-anything/ +``` + +--- + +## 🔧 Под капотом + +### Гибрид Tree-sitter + LLM + +Детерминированную работу делает статический анализ, семантическое понимание — LLM: + +- **Tree-sitter (детерминированно)** — парсит исходный код в конкретное синтаксическое дерево и извлекает структурные факты: import'ы, export'ы, определения функций/классов, точки вызова, наследование. На фазе сканирования заранее разрешается в `importMap` и передаётся file-analyzer'ам, чтобы они не выводили import'ы из исходника заново. Одинаковый ввод всегда даёт одинаковый вывод; это же лежит в основе fingerprint'ов для инкрементальных обновлений. +- **LLM (семантически)** — читает разобранную структуру вместе с исходным текстом и производит то, что не способны парсеры: понятные человеку резюме, теги, назначение архитектурных слоёв, отображение бизнес-доменов, ведомые туры, заметки о концепциях языка. + +Именно благодаря этому разделению граф воспроизводим со стороны структуры (один и тот же код всегда даёт одни и те же рёбра) и одновременно улавливает намерение со стороны семантики (для *чего* существует файл, а не только что он импортирует). + +### Мультиагентный пайплайн + +Команда `/understand` оркестрирует 5 специализированных агентов, а `/understand-domain` добавляет шестого: + +| Агент | Роль | +|-------|------| +| `project-scanner` | Обнаружение файлов, определение языков и фреймворков | +| `file-analyzer` | Извлечение функций, классов, импортов; создание узлов и рёбер графа | +| `architecture-analyzer` | Определение архитектурных слоёв | +| `tour-builder` | Генерация пошаговых обучающих обзоров | +| `graph-reviewer` | Проверка полноты и целостности ссылок графа (по умолчанию выполняется inline; используйте `--review` для полного ревью с участием LLM) | +| `domain-analyzer` | Извлечение бизнес-доменов, потоков и шагов процессов (используется командой `/understand-domain`) | +| `article-analyzer` | Извлечение сущностей, утверждений и неявных связей из статей вики (используется командой `/understand-knowledge`) | + +Анализаторы файлов работают параллельно (до 5 одновременно, 20–30 файлов на батч). Поддерживаются инкрементальные обновления — повторно анализируются только файлы, изменившиеся с прошлого запуска. + +--- + +## 🎥 Сообщество + +Обзорное видео от сообщества, созданное **Better Stack**. + +

+ Обзорное видео от сообщества Better Stack — нажмите, чтобы посмотреть на YouTube +
+ Смотреть на YouTube → +

+ +Сделали видео, статью или руководство? Откройте issue или PR — с удовольствием добавим сюда. + +--- + +## 🤝 Вклад в проект + +Будем рады вашим контрибьюшенам! Как начать: + +1. Сделайте форк репозитория +2. Создайте ветку для фичи (`git checkout -b feature/my-feature`) +3. Запустите тесты (`pnpm --filter @understand-anything/core test`) +4. Закоммитьте изменения и откройте pull request + +Для крупных изменений сначала откройте issue, чтобы можно было обсудить подход. + +--- + +

+ Хватит читать код вслепую. Начните понимать всё. +

+ +## История звёзд + + + + + + Star History Chart + + + +

+ Спасибо всем, кто пользовался проектом и вкладывался в него — знание того, что это экономит людям время, и было главной причиной, ради которой стоило его делать. +

+ +

+ Лицензия MIT © Lum1104 +

diff --git a/Understand-Anything-main/READMEs/README.tr-TR.md b/Understand-Anything-main/READMEs/README.tr-TR.md new file mode 100644 index 0000000..7f3168d --- /dev/null +++ b/Understand-Anything-main/READMEs/README.tr-TR.md @@ -0,0 +1,345 @@ +

Understand Anything

+ +

+ Herhangi bir kod tabanını, bilgi tabanını veya dokümantasyonu keşfedebileceğin, arayabileceğin ve hakkında sorular sorabileceğin interaktif bir bilgi grafiğine dönüştür. +
+ Claude Code, Codex, Cursor, Copilot, Gemini CLI ve daha fazlasıyla çalışır. +

+ +

+ Lum1104%2FUnderstand-Anything | Trendshift +

+ +

+ English | 简体中文 | 繁體中文 | 日本語 | 한국어 | Español | Türkçe | Русский +

+ +

+ Hızlı Başlangıç + Lisans: MIT + Claude Code + Codex + Copilot + Copilot CLI + Gemini CLI + OpenCode + Ana Sayfa + Canlı Demo +

+ +

+ Understand Anything — Herhangi bir kod tabanını interaktif bir bilgi grafiğine dönüştür +

+ +

+ 💬 Discord topluluğuna katıl → +
+ Sorular sor, yaptıklarını paylaş, topluluktan yardım al. +

+ +--- + +**Yeni bir ekibe katıldın. Kod tabanı 200.000 satır kod. Nereden başlayacaksın bile bilemiyorsun?** + +Understand Anything, projenizi çok-ajan hattıyla analiz eden, her dosya, fonksiyon, sınıf ve bağımlılığın bilgi grafiğini oluşturan ve hepsini görsel olarak keşfetmen için interaktif bir kontrol paneli sunan bir [Claude Code Plugin](https://code.claude.com/docs/en/plugins-reference#plugins-reference)'dir. Kodu körü körüne okumayı bırak. Büyük resmi görmeye başla. + +> **Amaç, kod tabanının ne kadar karmaşık olduğunu görkemle gösteren bir grafik değil — her parçanın nasıl birbirine geçtiğini sessizce öğreten bir grafik.** + +--- + +## ✨ Özellikler + +> [!NOTE] +> **Hemen denemek ister misiniz?** [Ana sayfamızda](https://understand-anything.com/) [canlı demoyu](https://understand-anything.com/demo/) deneyin — doğrudan tarayıcınızda kaydırma, yakınlaştırma, arama ve keşfetme yapabileceğiniz tam etkileşimli bir kontrol paneli. + +### Yapısal grafiği keşfedin + +Kod tabanınızı interaktif bir bilgi grafiği olarak görüntüleyin — her dosya, fonksiyon ve sınıf tıklanabilir, aranabilir ve keşfedilebilir bir düğümdür. Herhangi bir düğümü seçerek anlaşılır özetleri, bağımlılıkları ve rehberli turları görün. + +### İş mantığını anlayın + +Alan görünümüne geçin ve kodunuzun gerçek iş süreçleriyle nasıl eşleştiğini görün — alanlar, akışlar ve adımlar yatay bir grafik olarak sunulur. + +### Bilgi tabanlarını analiz et + +`/understand-knowledge` komutunu bir [Karpathy deseni LLM Wiki'sine](https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f) yönlendirin ve topluluk kümeleme ile kuvvet yönelimli bir bilgi grafiği elde edin. Deterministik ayrıştırıcı `index.md`'den wikilinkleri ve kategorileri çıkarır, ardından LLM ajanları örtük ilişkileri keşfeder, varlıkları çıkarır ve iddiaları ortaya çıkarır — wiki'nizi gezinilebilir, birbirine bağlı fikirler grafiğine dönüştürür. + + + + + + + + + + + + + + +
+

🧭 Rehberli Turlar

+

Bağımlılığa göre sıralanmış, mimarinin otomatik oluşturulmuş gözden geçirmeleri. Kod tabanını doğru sırayla öğren.

+ 		+

🔍 Bulanık ve Anlamsal Arama

+

İsme veya anlamına göre her şeyi bul. "Kimlik doğrulamayı hangi parçalar yönetiyor?" ara ve grafik boyunca ilgili sonuçları al.

+
+

📊 Diff Etki Analizi

+

Değişikliklerinin sistemin hangi bölümlerini etkilediğini commit etmeden önce gör. Kod tabanı boyunca dalgalanma etkilerini anla.

+ 		+

🎭 Kişiye Uyarlanabilir UI

+

Kontrol paneli, kim olduğuna göre ayrıntı seviyesini ayarlar — junior geliştirici, ürün yöneticisi veya güçlü kullanıcı.

+
+

🏗️ Katman Görselleştirmesi

+

Mimari katmana göre otomatik gruplama — API, Servis, Veri, UI, Yardımcı — renk kodlu efsaneyle.

+ 		+

📚 Dil Kavramları

+

12 programlama deseni (generikler, kapanışlar, dekoratörler, vb.) göründükleri her yerde bağlam içinde açıklanır.

+
+ +--- + +## 🚀 Hızlı Başlangıç + +### 1. Eklentiyi yükle + +```bash +/plugin marketplace add Lum1104/Understand-Anything +/plugin install understand-anything +``` + +### 2. Kod tabanını analiz et + +```bash +/understand +``` + +Çok-ajan hattı projenizi tarar, her dosya, fonksiyon, sınıf ve bağımlılığı çıkarır, ardından `.understand-anything/knowledge-graph.json` dosyasına kaydedilen bir bilgi grafiği oluşturur. + +**Yerelleştirilmiş çıktı:** İstediğiniz dilde içerik oluşturmak için `--language` kullanın: + +```bash +# İstediğiniz dilde içerik oluştur (düğüm açıklamaları ve dashboard UI) +/understand --language en + +# Desteklenen diller: en (varsayılan), zh, zh-TW, ja, ko, ru +``` + +`--language` parametresi şunları etkiler: +- Bilgi grafiğindeki düğüm özetleri ve açıklamalar +- Dashboard UI etiketleri, butonlar ve araç ipuçları +- Rehberli tur açıklamaları + +### 3. Kontrol panelini keşfet + +```bash +/understand-dashboard +``` + +Kod tabanın bir grafik olarak görselleştirilmiş, mimari katmana göre renklendirilmiş, aranabilir ve tıklanabilir interaktif bir web kontrol paneli açılır. Kodunu, ilişkilerini ve sade Türkçe açıklamasını görmek için herhangi bir düğüm seç. + +### 4. Öğrenmeye devam et + +```bash +# Kod tabanı hakkında her şeyi sor +/understand-chat Ödeme akışı nasıl çalışır? + +# Mevcut değişikliklerinin etkisini analiz et +/understand-diff + +# Belirli bir dosya veya fonksiyona derinlemesine dal +/understand-explain src/auth/login.ts + +# Yeni ekip üyeleri için bir işe alıştırma rehberi oluştur +/understand-onboard + +# İş alanı bilgisini çıkar (alanlar, akışlar, adımlar) +/understand-domain + +# Karpathy deseni LLM Wiki bilgi tabanını analiz et +/understand-knowledge ~/path/to/wiki + +# İstediğin zaman tekrar çalıştır — varsayılan olarak artımlıdır (yalnızca değişen dosyaları analiz eder) +/understand + +# Her commit'te otomatik artımlı güncelleme için post-commit kancası kur +/understand --auto-update + +# Devasa monorepo'larda analizi bir alt dizinle sınırla +/understand src/frontend +``` + +--- + +## 🌐 Çoklu Platform Kurulumu + +Understand-Anything birden fazla AI kodlama platformunda çalışır. + +### Claude Code (Yerli) + +```bash +/plugin marketplace add Lum1104/Understand-Anything +/plugin install understand-anything +``` + +### Tek satırlık kurulum (Codex / OpenCode / OpenClaw / Antigravity / Gemini CLI / Pi Agent / Vibe CLI / VS Code Copilot / Hermes / Cline / KIMI CLI) + +**macOS / Linux:** +```bash +curl -fsSL https://raw.githubusercontent.com/Lum1104/Understand-Anything/main/install.sh | bash +# veya platformu doğrudan geçirerek soruyu atla: +curl -fsSL https://raw.githubusercontent.com/Lum1104/Understand-Anything/main/install.sh | bash -s codex +``` + +**Windows (PowerShell):** +```powershell +iwr -useb https://raw.githubusercontent.com/Lum1104/Understand-Anything/main/install.ps1 | iex +``` + +Kurulum betiği depoyu `~/.understand-anything/repo` dizinine klonlar ve seçilen platform için uygun sembolik bağlantıları oluşturur. Sonrasında CLI/IDE'ni yeniden başlat. + +- Desteklenen `` değerleri: `gemini`, `codex`, `opencode`, `pi`, `openclaw`, `antigravity`, `vibe`, `vscode`, `hermes`, `cline`, `kimi` +- Daha sonra güncelle: `./install.sh --update` +- Kaldır: `./install.sh --uninstall ` + +### Cursor + +Bu depo klonlandığında Cursor, eklentiyi `.cursor-plugin/plugin.json` aracılığıyla otomatik olarak keşfeder. Manuel kurulum gerekmez — sadece klonla ve Cursor'da aç. + +Otomatik keşif çalışmazsa manuel kur: **Cursor Settings → Plugins**'i aç, arama alanına `https://github.com/Lum1104/Understand-Anything` yapıştır ve oradan ekle. + +### VS Code + GitHub Copilot + +GitHub Copilot uzantısı (v1.108+) yüklü VS Code, `.copilot-plugin/plugin.json` aracılığıyla eklentiyi otomatik keşfeder. Manuel kurulum gerekmez — sadece klonla ve VS Code'da aç. + +Tüm projelerde kullanmak için kişisel beceri olarak kurmak istersen yukarıdaki `install.sh`'ı `vscode` platformuyla çalıştır. + +### Copilot CLI + +```bash +copilot plugin install Lum1104/Understand-Anything:understand-anything-plugin +``` + +### Platform Uyumluluğu + +| Platform | Durum | Kurulum Yöntemi | +|----------|--------|----------------| +| Claude Code | ✅ Yerli | Eklenti pazarı | +| Cursor | ✅ Destekleniyor | Otomatik keşif | +| VS Code + GitHub Copilot | ✅ Destekleniyor | Otomatik keşif | +| Copilot CLI | ✅ Destekleniyor | Eklenti kurulumu | +| Codex | ✅ Destekleniyor | `install.sh codex` | +| OpenCode | ✅ Destekleniyor | `install.sh opencode` | +| OpenClaw | ✅ Destekleniyor | `install.sh openclaw` | +| Antigravity | ✅ Destekleniyor | `install.sh antigravity` | +| Gemini CLI | ✅ Destekleniyor | `install.sh gemini` | +| Pi Agent | ✅ Destekleniyor | `install.sh pi` | +| Vibe CLI | ✅ Destekleniyor | `install.sh vibe` | +| Hermes | ✅ Destekleniyor | `install.sh hermes` | +| Cline | ✅ Destekleniyor | `install.sh cline` | +| KIMI CLI | ✅ Destekleniyor | `install.sh kimi` | + +--- + +## 📦 Grafı Ekibinizle Paylaşın + +Graf yalnızca bir JSON dosyasıdır — **bir kez commit'leyin, ekip arkadaşlarınız pipeline'ı çalıştırmadan kullansın**. Yeni üye oryantasyonu, PR incelemeleri ve docs-as-code iş akışları için idealdir. + +> **Örnek:** [GoogleCloudPlatform/microservices-demo (fork)](https://github.com/Lum1104/microservices-demo) — commit'lenmiş grafı içeren Go / Java / Python / Node çok dilli referans projesi. + +**Neyi commit'leyin:** `.understand-anything/` içindeki her şey, *ancak* `intermediate/` ve `diff-overlay.json` hariç (bunlar yerel geçici dosyalardır). + +```gitignore +.understand-anything/intermediate/ +.understand-anything/diff-overlay.json +``` + +**Güncel tutun:** `/understand --auto-update` etkinleştirin — bir post-commit kancası grafı artımlı olarak yamalar, böylece her commit eşleşen bir grafla birlikte gelir. Veya sürümden önce `/understand` komutunu elle yeniden çalıştırın. + +**Büyük graflar (10 MB+):** **git-lfs** ile takip edin. + +```bash +git lfs install +git lfs track ".understand-anything/*.json" +git add .gitattributes .understand-anything/ +``` + +--- + +## 🔧 Kaputun Altında + +### Tree-sitter + LLM hibriti + +Deterministik olarak yapılabilecek işleri statik analiz, anlam çıkarımı gerektiren işleri LLM üstlenir: + +- **Tree-sitter (deterministik)** — kaynak kodu somut sözdizimi ağacına ayrıştırır ve yapısal gerçekleri çıkarır: import'lar, export'lar, fonksiyon/sınıf tanımları, çağrı noktaları, kalıtım. Tarama aşamasında önceden çözülmüş `importMap` olarak file-analyzer'a iletilir, böylece import'ları kaynaktan tekrar türetmek zorunda kalmaz. Aynı girdi her zaman aynı çıktıyı verir; ayrıca artımlı güncellemelerin parmak izlerinin de temelidir. +- **LLM (anlamsal)** — ayrıştırılmış yapıyı ve orijinal kaynağı birlikte okuyarak ayrıştırıcıların üretemediği şeyleri üretir: düz dilde özetler, etiketler, mimari katman atamaları, iş alanı eşlemeleri, rehberli turlar, dil kavramı notları. + +Bu ayrım sayesinde graf yapısal tarafta yeniden üretilebilir kalırken (aynı kod her zaman aynı kenarları üretir) anlamsal tarafta niyeti yakalayabilir (bir dosya yalnızca neyi import ettiği değil, *ne için* var olduğu da görülür). + +### Çok-Ajan Hattı + +`/understand` komutu 5 özel ajan düzenler ve `/understand-domain` 6. ajanı ekler: + +| Ajan | Rol | +|-------|------| +| `project-scanner` | Dosyaları keşfet, dilleri ve çerçeveleri tespit et | +| `file-analyzer` | Fonksiyonları, sınıfları, içe aktarmaları çıkar; grafik düğümleri ve kenarları üret | +| `architecture-analyzer` | Mimari katmanları tanımla | +| `tour-builder` | Rehberli öğrenme turları oluştur | +| `graph-reviewer` | Grafik bütünlüğünü ve referans bütünlüğünü doğrula | +| `domain-analyzer` | İş alanları, akışlar ve işlem adımlarını çıkar (`/understand-domain` tarafından kullanılır) | +| `article-analyzer` | Wiki makalelerinden varlıkları, iddiaları ve örtük ilişkileri çıkar (`/understand-knowledge` tarafından kullanılır) | + +Dosya analizörleri paralel çalışır (en fazla 3 eşzamanlı). Artımlı güncellemeleri destekler — yalnızca son çalıştırmadan bu yana değişen dosyaları yeniden analiz eder. + +--- + +## 🎥 Topluluk + +**Better Stack** tarafından hazırlanan topluluk tanıtım videosu. + +

+ Better Stack tarafından hazırlanan topluluk tanıtım videosu — YouTube'da izlemek için tıklayın +
+ YouTube'da izle → +

+ +Bir video, blog yazısı veya eğitim hazırladınız mı? Issue veya PR açın — burada yer vermekten mutluluk duyarız. + +--- + +## 🤝 Katkıda Bulunma + +Katkılar memnuniyetle karşılanır! Başlamak için: + +1. Depoyu fork'la +2. Bir özellik dalı oluştur (`git checkout -b feature/benim-ozellligim`) +3. Testleri çalıştır (`pnpm --filter @understand-anything/core test`) +4. Değişikliklerini commit et ve bir pull request aç + +Büyük değişiklikler için lütfen önce bir issue aç ki yaklaşımı tartışalım. + +--- + +

+ Kodu körü körüne okumayı bırak. Her şeyi anlamaya başla. +

+ +## Star Geçmişi + + + + + + Star Geçmişi Grafiği + + + +

+ Kullanan ve katkıda bulunan herkese teşekkürler — bunun insanlara zaman kazandırdığını bilmek, yapmaya değer kılan tek şeydi. +

+ +

+ MIT Lisansı © Lum1104 +

diff --git a/Understand-Anything-main/READMEs/README.zh-CN.md b/Understand-Anything-main/READMEs/README.zh-CN.md new file mode 100644 index 0000000..87fedc6 --- /dev/null +++ b/Understand-Anything-main/READMEs/README.zh-CN.md @@ -0,0 +1,344 @@ +

Understand Anything

+

+ 将任意代码库、知识库或文档转化为可探索、可搜索、可对话的交互式知识图谱 +
+ 支持 Claude Code、Codex、Cursor、Copilot、Gemini CLI 等多平台。 +

+ +

+ Lum1104%2FUnderstand-Anything | Trendshift +

+ +

+ English | 简体中文 | 繁體中文 | 日本語 | 한국어 | Español | Türkçe | Русский +

+ +

+ Quick Start + License: MIT + Claude Code + Codex + Copilot + Copilot CLI + Gemini CLI + OpenCode + Homepage + Live Demo +

+ +

+ Understand Anything — 将任何代码库转换为交互式知识图谱 +

+ +

+ 💬 加入 Discord 社区 → +
+ 来提问、分享你的项目、和社区一起讨论。 +

+ +--- + +**当你刚加入一个新团队，面对 20 万行代码，你从哪里开始？** + +Understand Anything 是一个 [Claude Code Plugin](https://code.claude.com/docs/en/plugins-reference#plugins-reference)，通过多智能体（multi-agent）架构分析你的项目，构建包含文件、函数、类以及依赖关系的知识图谱，并提供一个可视化交互界面，帮助你理解整个系统。不再”盲读代码”，而是从全局视角理解系统结构。 + +> **目标不是用代码库的复杂程度来惊艳你 —— 而是默默告诉你每一块是怎么拼在一起的。** + +--- + +## ✨ 核心功能 + +> [!NOTE] +> **想直接体验？** 在我们的[主页](https://understand-anything.com/)试试[在线演示](https://understand-anything.com/demo/) — 一个可以平移、缩放、搜索和探索的全交互式仪表盘。 + +### 探索代码结构图 + +将你的代码库以交互式知识图谱的形式呈现——每个文件、函数和类都是可点击、可搜索、可探索的节点。选择任意节点即可查看通俗易懂的摘要、依赖关系和引导式学习路径。 + +### 理解业务逻辑 + +切换到领域视图，查看代码如何映射到真实的业务流程——以水平图的形式展示领域、流程和步骤。 + +### 分析知识库 + +将 `/understand-knowledge` 指向一个 [Karpathy 模式的 LLM Wiki](https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f)，即可获得带有社区聚类的力导向知识图谱。确定性解析器从 `index.md` 中提取 wikilinks 和分类，然后 LLM 代理发现隐式关系、提取实体并挖掘论断——将你的 wiki 转化为可导航的互联思想图谱。 + + + + + + + + + + + + + + +
+

🧭 引导式学习

+

自动生成架构学习路径，按依赖顺序学习。

+ 		+

🔍 语义搜索

+

支持模糊搜索 + 语义搜索，例如搜索"哪些部分处理身份验证？"即可在整个图中获取相关结果。

+
+

📊 变更影响分析

+

提交更改前，查看更改会影响系统的哪些部分。了解更改对整个代码库的连锁反应。

+ 		+

🎭 用户角色自适应 UI

+

根据用户类型（初级开发 / 项目经理 / 高级用户）调整其详细程度。

+
+

🏗️ 层级可视化

+

按架构层级自动分组 — API，服务，数据，UI, 系统工具 — 并附有颜色编码图例。

+ 		+

📚 语言概念

+

12 种编程模式（泛型、闭包、装饰器等）将在上下文中逐一解释。

+
+ +--- + +## 🚀 快速开始 + +### 1. 安装插件 + +```bash +/plugin marketplace add Lum1104/Understand-Anything +/plugin install understand-anything +``` + +### 2. 分析你的代码库 + +```bash +/understand +``` + +多智能体（multi-agent）架构会：扫描你的项目，提取函数 / 类 / 依赖，构建知识图谱保存至`.understand-anything/knowledge-graph.json`. + +**本地化输出：** 使用 `--language` 参数生成中文内容： + +```bash +# 生成中文内容（知识图节点描述和 Dashboard UI） +/understand --language zh + +# 支持的语言：en（默认）、zh、zh-TW、ja、ko、ru +``` + +`--language` 参数会影响： +- 知识图谱中的节点摘要和描述 +- Dashboard UI 的标签、按钮和提示 +- 导览路线的解释说明 + +### 3. 打开数据看板 + +```bash +/understand-dashboard +``` + +打开交互式网页数据看板，您的代码库将以图表形式呈现 — 按架构层级进行颜色编码，支持搜索和点击。选择任意节点即可查看其代码、关系以及简明易懂的解释。 + +### 4. 深度使用 + +```bash +# 询问任意代码库的问题 +/understand-chat How does the payment flow work? + +# 分析当前修改的影响 +/understand-diff + +# 深入理解某个文件 +/understand-explain src/auth/login.ts + +# 为新团队成员生成指南 +/understand-onboard + +# 提取业务领域知识（领域、流程、步骤） +/understand-domain + +# 分析 Karpathy 模式的 LLM Wiki 知识库 +/understand-knowledge ~/path/to/wiki + +# 直接重跑即可 —— 默认增量更新，只分析变更的文件 +/understand + +# 安装 post-commit 钩子，每次提交自动增量更新 +/understand --auto-update + +# 大型 monorepo？把分析范围限定到某个子目录 +/understand src/frontend +``` + +--- + +## 🌐 多平台支持 + +Understand-Anything 可在多个 AI 编码平台上运行。 + +### Claude Code（原生） + +```bash +/plugin marketplace add Lum1104/Understand-Anything +/plugin install understand-anything +``` + +### 一行命令安装（Codex / OpenCode / OpenClaw / Antigravity / Gemini CLI / Pi Agent / Vibe CLI / VS Code Copilot / Hermes / Cline / KIMI CLI） + +**macOS / Linux：** +```bash +curl -fsSL https://raw.githubusercontent.com/Lum1104/Understand-Anything/main/install.sh | bash +# 也可以直接传入平台名跳过交互提示： +curl -fsSL https://raw.githubusercontent.com/Lum1104/Understand-Anything/main/install.sh | bash -s codex +``` + +**Windows（PowerShell）：** +```powershell +iwr -useb https://raw.githubusercontent.com/Lum1104/Understand-Anything/main/install.ps1 | iex +``` + +安装脚本会将仓库克隆到 `~/.understand-anything/repo`，并为所选平台创建相应的符号链接。安装完成后请重启 CLI 或 IDE。 + +- 支持的 `` 取值：`gemini`、`codex`、`opencode`、`pi`、`openclaw`、`antigravity`、`vibe`、`vscode`、`hermes`、`cline`、`kimi` +- 后续更新：`./install.sh --update` +- 卸载：`./install.sh --uninstall ` + +### Cursor + +克隆此仓库后，Cursor 会自动通过 `.cursor-plugin/plugin.json`文件发现插件。无需手动安装 — 只需克隆并在 Cursor 中打开即可。 + +若自动发现未生效，可手动安装：打开 **Cursor Settings → Plugins**，在搜索框中粘贴 `https://github.com/Lum1104/Understand-Anything` 并添加。 + +### VS Code + GitHub Copilot + +安装 GitHub Copilot 扩展（v1.108+）后，VS Code 会通过 `.copilot-plugin/plugin.json` 自动发现插件，克隆后直接在 VS Code 中打开即可，无需手动安装。 + +若需要在所有项目中使用（个人技能），运行上面的 `install.sh` 并选择 `vscode` 平台即可。 + +### Copilot CLI + +```bash +copilot plugin install Lum1104/Understand-Anything:understand-anything-plugin +``` + +### 多平台兼容 + +| 平台 | 状态 | 安装方式 | +|----------|--------|----------------| +| Claude Code | ✅ 原生 | 插件市场 | +| Cursor | ✅ 支持 | 自动发现 | +| VS Code + GitHub Copilot | ✅ 支持 | 自动发现 | +| Copilot CLI | ✅ 支持 | 插件安装 | +| Codex | ✅ 支持 | `install.sh codex` | +| OpenCode | ✅ 支持 | `install.sh opencode` | +| OpenClaw | ✅ 支持 | `install.sh openclaw` | +| Antigravity | ✅ 支持 | `install.sh antigravity` | +| Gemini CLI | ✅ 支持 | `install.sh gemini` | +| Pi Agent | ✅ 支持 | `install.sh pi` | +| Vibe CLI | ✅ 支持 | `install.sh vibe` | +| Hermes | ✅ 支持 | `install.sh hermes` | +| Cline | ✅ 支持 | `install.sh cline` | +| KIMI CLI | ✅ 支持 | `install.sh kimi` | + +--- + +## 📦 与团队共享知识图谱 + +图谱就是一份 JSON 文件——**提交一次，团队成员就可以跳过整条流水线**。适合新人上手、PR 评审和 docs-as-code 工作流。 + +> **示例：** [GoogleCloudPlatform/microservices-demo（fork）](https://github.com/Lum1104/microservices-demo) —— 包含已提交图谱的 Go / Java / Python / Node 多语言参考项目。 + +**需要提交的内容：** `.understand-anything/` 下的全部文件，*除了* `intermediate/` 和 `diff-overlay.json`（这些是本地临时文件）。 + +```gitignore +.understand-anything/intermediate/ +.understand-anything/diff-overlay.json +``` + +**保持最新：** 启用 `/understand --auto-update` —— 一个 post-commit 钩子会增量更新图谱，每次提交都能得到匹配的图谱版本。也可以在发布前手动重跑 `/understand`。 + +**大型图谱（10 MB 以上）：** 使用 **git-lfs** 跟踪。 + +```bash +git lfs install +git lfs track ".understand-anything/*.json" +git add .gitattributes .understand-anything/ +``` + +--- + +## 🔧 技术原理 + +### Tree-sitter + LLM 混合分析 + +把确定性的事情交给静态分析，把需要语义理解的事情交给 LLM： + +- **Tree-sitter（确定性）** —— 将源码解析为具体语法树，提取结构性事实：导入、导出、函数 / 类定义、调用点、继承关系。在 scan 阶段预先解析为 `importMap` 并传给 file-analyzer，避免它们再从源码推导一次 import。同样的输入永远得到同样的输出，并作为增量更新的指纹基础。 +- **LLM（语义）** —— 读取解析后的结构以及原始源码，生成解析器做不了的事：plain-English 摘要、标签、架构层归属、业务领域映射、引导路径、语言概念标注。 + +正因为这个分工，图谱在结构层面是可复现的（同样的代码总是产生同样的边），同时在语义层面又能捕捉意图（一个文件是「为了什么」存在，而不仅仅是它 import 了什么）。 + +### 多智能体架构 + +`/understand` 命令调用 5 个 agent，`/understand-domain` 额外增加第 6 个： + +| Agent | 职责 | +|-------|------| +| `project-scanner` | 扫描项目文件，检测语言和框架 | +| `file-analyzer` | 提取代码结构（函数、类和导入），生成图节点和边 | +| `architecture-analyzer` | 识别架构层 | +| `tour-builder` | 生成引导式学习路径 | +| `graph-reviewer` | 验证图的完整性和引用完整性 | +| `domain-analyzer` | 提取业务领域、流程和处理步骤（由 `/understand-domain` 使用） | +| `article-analyzer` | 从 wiki 文章中提取实体、论断和隐式关系（由 `/understand-knowledge` 使用） | + +文件分析器并行运行（最多 3 个并发）。支持增量更新 — 仅重新分析自上次运行以来发生更改的文件。 + +--- + +## 🎥 社区 + +由 **Better Stack** 制作的社区视频教程。 + +

+ Better Stack 制作的社区视频教程 —— 点击在 YouTube 观看 +
+ 在 YouTube 上观看 → +

+ +写过视频、博客或教程?提个 issue 或 PR —— 我们很乐意把它放在这里。 + +--- + +## 🤝 贡献 + +欢迎贡献！以下是贡献指南： + +1. Fork 项目 +2. 新建分支 (`git checkout -b feature/my-feature`) +3. 运行测试 (`pnpm --filter @understand-anything/core test`) +4. 提交更改并创建一个PR请求 + +对于重大变更，请先提交 issue，以便我们讨论解决方案。 + +--- + +

+ 不再盲读代码，而是理解整个系统 +

+ +## Star 历史记录 + + + + + + Star History Chart + + + +

+ 感谢每一位使用过、贡献过的朋友 —— 知道它替你们省下了一些时间，就是当初做它最值得的理由。 +

+ +

+ MIT 许可证 © Lum1104 +

diff --git a/Understand-Anything-main/READMEs/README.zh-TW.md b/Understand-Anything-main/READMEs/README.zh-TW.md new file mode 100644 index 0000000..0b4ef96 --- /dev/null +++ b/Understand-Anything-main/READMEs/README.zh-TW.md @@ -0,0 +1,344 @@ +

Understand Anything

+

+ 將任意程式碼庫、知識庫或文件轉化為可探索、可搜尋、可對話的互動式知識圖譜 +
+ 支援 Claude Code、Codex、Cursor、Copilot、Gemini CLI 等多平台。 +

+ +

+ Lum1104%2FUnderstand-Anything | Trendshift +

+ +

+ English | 简体中文 | 繁體中文 | 日本語 | 한국어 | Español | Türkçe | Русский +

+ +

+ Quick Start + License: MIT + Claude Code + Codex + Copilot + Copilot CLI + Gemini CLI + OpenCode + Homepage + Live Demo +

+ +

+ Understand Anything — 將任何程式碼庫轉換為互動式知識圖譜 +

+ +

+ 💬 加入 Discord 社群 → +
+ 來提問、分享你的專案、和社群一起討論。 +

+ +--- + +**當你剛加入一個新團隊，面對 20 萬行程式碼，你從哪裡開始？** + +Understand Anything 是一個 [Claude Code Plugin](https://code.claude.com/docs/en/plugins-reference#plugins-reference)，透過多智能體（multi-agent）架構分析你的專案，建構包含檔案、函式、類別以及相依關係的知識圖譜，並提供一個視覺化互動介面，幫助你理解整個系統。不再「盲讀程式碼」，而是從全局視角理解系統結構。 + +> **目標不是用程式碼庫的複雜程度驚豔你 —— 而是默默告訴你每一塊是怎麼拼在一起的。** + +--- + +## ✨ 核心功能 + +> [!NOTE] +> **想直接體驗？** 在我們的[首頁](https://understand-anything.com/)試試[線上演示](https://understand-anything.com/demo/) — 一個可以平移、縮放、搜尋和探索的全互動式儀表盤。 + +### 探索程式碼結構圖 + +將你的程式碼庫以互動式知識圖譜呈現——每個檔案、函式和類別都是可點擊、可搜尋、可探索的節點。選取任意節點即可檢視淺顯易懂的摘要、依賴關係和引導式學習路徑。 + +### 理解業務邏輯 + +切換到領域視圖，查看程式碼如何對應到真實的業務流程——以水平圖的形式展示領域、流程和步驟。 + +### 分析知識庫 + +將 `/understand-knowledge` 指向一個 [Karpathy 模式的 LLM Wiki](https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f)，即可獲得帶有社群聚類的力導向知識圖譜。確定性解析器從 `index.md` 中提取 wikilinks 和分類，然後 LLM 代理發現隱式關係、提取實體並挖掘論斷——將你的 wiki 轉化為可導航的互聯思想圖譜。 + + + + + + + + + + + + + + +
+

🧭 引導式學習

+

自動產生架構學習路徑，按相依順序學習。

+ 		+

🔍 語意搜尋

+

支援模糊搜尋 + 語意搜尋，例如搜尋「哪些部分處理身分驗證？」即可在整個圖中獲取相關結果。

+
+

📊 變更影響分析

+

提交變更前，查看變更會影響系統的哪些部分。了解變更對整個程式碼庫的連鎖反應。

+ 		+

🎭 使用者角色自適應 UI

+

根據使用者類型（初級開發 / 專案經理 / 進階使用者）調整其詳細程度。

+
+

🏗️ 層級視覺化

+

按架構層級自動分組 — API、服務、資料、UI、系統工具 — 並附有顏色編碼圖例。

+ 		+

📚 語言概念

+

12 種程式設計模式（泛型、閉包、裝飾器等）將在上下文中逐一解釋。

+
+ +--- + +## 🚀 快速開始 + +### 1. 安裝外掛程式 + +```bash +/plugin marketplace add Lum1104/Understand-Anything +/plugin install understand-anything +``` + +### 2. 分析你的程式碼庫 + +```bash +/understand +``` + +多智能體（multi-agent）架構會：掃描你的專案，提取函式 / 類別 / 相依關係，建構知識圖譜並儲存至 `.understand-anything/knowledge-graph.json`。 + +**在地化輸出：** 使用 `--language` 參數產生中文內容： + +```bash +# 產生繁體中文內容（知識圖節點描述和 Dashboard UI） +/understand --language zh-TW + +# 支援的語言：en（預設）、zh、zh-TW、ja、ko、ru +``` + +`--language` 參數會影響： +- 知識圖譜中的節點摘要和描述 +- Dashboard UI 的標籤、按鈕和提示 +-導覽路線的解釋說明 + +### 3. 開啟資料看板 + +```bash +/understand-dashboard +``` + +開啟互動式網頁資料看板，你的程式碼庫將以圖表形式呈現 — 按架構層級進行顏色編碼，支援搜尋和點擊。選擇任意節點即可查看其程式碼、關係以及簡明易懂的解釋。 + +### 4. 深度使用 + +```bash +# 詢問任意程式碼庫的問題 +/understand-chat 付款流程是怎麼運作的？ + +# 分析目前修改的影響 +/understand-diff + +# 深入理解某個檔案 +/understand-explain src/auth/login.ts + +# 為新團隊成員產生指南 +/understand-onboard + +# 提取業務領域知識（領域、流程、步驟） +/understand-domain + +# 分析 Karpathy 模式的 LLM Wiki 知識庫 +/understand-knowledge ~/path/to/wiki + +# 直接重跑即可 —— 預設增量更新，只分析變更的檔案 +/understand + +# 安裝 post-commit 掛鉤，每次提交自動增量更新 +/understand --auto-update + +# 大型 monorepo？把分析範圍限定到某個子目錄 +/understand src/frontend +``` + +--- + +## 🌐 多平台支援 + +Understand-Anything 可在多個 AI 編碼平台上執行。 + +### Claude Code（原生） + +```bash +/plugin marketplace add Lum1104/Understand-Anything +/plugin install understand-anything +``` + +### 一行指令安裝（Codex / OpenCode / OpenClaw / Antigravity / Gemini CLI / Pi Agent / Vibe CLI / VS Code Copilot / Hermes / Cline / KIMI CLI） + +**macOS / Linux：** +```bash +curl -fsSL https://raw.githubusercontent.com/Lum1104/Understand-Anything/main/install.sh | bash +# 也可以直接傳入平台名稱跳過互動提示： +curl -fsSL https://raw.githubusercontent.com/Lum1104/Understand-Anything/main/install.sh | bash -s codex +``` + +**Windows（PowerShell）：** +```powershell +iwr -useb https://raw.githubusercontent.com/Lum1104/Understand-Anything/main/install.ps1 | iex +``` + +安裝指令稿會將儲存庫複製到 `~/.understand-anything/repo`，並為所選平台建立相應的符號連結。安裝完成後請重新啟動 CLI 或 IDE。 + +- 支援的 `` 取值：`gemini`、`codex`、`opencode`、`pi`、`openclaw`、`antigravity`、`vibe`、`vscode`、`hermes`、`cline`、`kimi` +- 後續更新：`./install.sh --update` +- 解除安裝：`./install.sh --uninstall ` + +### Cursor + +複製此儲存庫後，Cursor 會自動透過 `.cursor-plugin/plugin.json` 檔案發現外掛程式。無需手動安裝 — 只需複製並在 Cursor 中開啟即可。 + +若自動發現未生效，可手動安裝：開啟 **Cursor Settings → Plugins**，在搜尋框中貼上 `https://github.com/Lum1104/Understand-Anything` 並新增。 + +### VS Code + GitHub Copilot + +安裝 GitHub Copilot 擴充功能（v1.108+）後，VS Code 會透過 `.copilot-plugin/plugin.json` 自動發現外掛程式，複製後直接在 VS Code 中開啟即可，無需手動安裝。 + +若需要在所有專案中使用（個人技能），執行上面的 `install.sh` 並選擇 `vscode` 平台即可。 + +### Copilot CLI + +```bash +copilot plugin install Lum1104/Understand-Anything:understand-anything-plugin +``` + +### 多平台相容性 + +| 平台 | 狀態 | 安裝方式 | +|----------|--------|----------------| +| Claude Code | ✅ 原生 | 外掛程式市集 | +| Cursor | ✅ 支援 | 自動發現 | +| VS Code + GitHub Copilot | ✅ 支援 | 自動發現 | +| Copilot CLI | ✅ 支援 | 外掛程式安裝 | +| Codex | ✅ 支援 | `install.sh codex` | +| OpenCode | ✅ 支援 | `install.sh opencode` | +| OpenClaw | ✅ 支援 | `install.sh openclaw` | +| Antigravity | ✅ 支援 | `install.sh antigravity` | +| Gemini CLI | ✅ 支援 | `install.sh gemini` | +| Pi Agent | ✅ 支援 | `install.sh pi` | +| Vibe CLI | ✅ 支援 | `install.sh vibe` | +| Hermes | ✅ 支援 | `install.sh hermes` | +| Cline | ✅ 支援 | `install.sh cline` | +| KIMI CLI | ✅ 支援 | `install.sh kimi` | + +--- + +## 📦 與團隊共享知識圖譜 + +圖譜就是一份 JSON 檔案——**提交一次，團隊成員就可以跳過整條流水線**。適合新人上手、PR 審查和 docs-as-code 工作流程。 + +> **範例：** [GoogleCloudPlatform/microservices-demo（fork）](https://github.com/Lum1104/microservices-demo) —— 包含已提交圖譜的 Go / Java / Python / Node 多語言參考專案。 + +**需要提交的內容：** `.understand-anything/` 底下的全部檔案，*除了* `intermediate/` 與 `diff-overlay.json`（這些是本機暫存檔）。 + +```gitignore +.understand-anything/intermediate/ +.understand-anything/diff-overlay.json +``` + +**保持最新：** 啟用 `/understand --auto-update` —— 一個 post-commit 掛鉤會增量更新圖譜，讓每次提交都有對應的圖譜版本。也可以在發布前手動重跑 `/understand`。 + +**大型圖譜（10 MB 以上）：** 使用 **git-lfs** 追蹤。 + +```bash +git lfs install +git lfs track ".understand-anything/*.json" +git add .gitattributes .understand-anything/ +``` + +--- + +## 🔧 技術原理 + +### Tree-sitter + LLM 混合分析 + +把確定性的事情交給靜態分析，把需要語意理解的事情交給 LLM： + +- **Tree-sitter（確定性）** —— 將原始碼解析為具體語法樹，提取結構性事實：import、export、函式 / 類別定義、呼叫點、繼承關係。在 scan 階段預先解析為 `importMap` 並傳給 file-analyzer，避免它們再從原始碼推導一次 import。相同的輸入永遠得到相同的輸出，並作為增量更新的指紋基礎。 +- **LLM（語意）** —— 讀取解析後的結構以及原始碼，產生解析器做不到的事：plain-English 摘要、標籤、架構層歸屬、業務領域映射、導覽路徑、語言概念標註。 + +正是這個分工讓圖譜在結構層面具備可重現性（同樣的程式碼總是產生同樣的邊），同時在語意層面也能捕捉意圖（一個檔案是「為了什麼」而存在，不只是它 import 了什麼）。 + +### 多智能體架構 + +`/understand` 指令呼叫 5 個 agent，`/understand-domain` 額外增加第 6 個： + +| Agent | 職責 | +|-------|------| +| `project-scanner` | 掃描專案檔案，偵測語言和框架 | +| `file-analyzer` | 提取程式碼結構（函式、類別和匯入），產生圖節點和邊 | +| `architecture-analyzer` | 識別架構層 | +| `tour-builder` | 產生引導式學習路徑 | +| `graph-reviewer` | 驗證圖的完整性和參考完整性 | +| `domain-analyzer` | 提取業務領域、流程和處理步驟（由 `/understand-domain` 使用） | +| `article-analyzer` | 從 wiki 文章中提取實體、論斷和隱式關係（由 `/understand-knowledge` 使用） | + +檔案分析器並行執行（最多 3 個並發）。支援增量更新 — 僅重新分析自上次執行以來發生變更的檔案。 + +--- + +## 🎥 社群 + +由 **Better Stack** 製作的社群影片導覽。 + +

+ Better Stack 製作的社群影片導覽 —— 點擊在 YouTube 觀看 +
+ 在 YouTube 上觀看 → +

+ +寫過影片、部落格或教學?開一個 issue 或 PR —— 我們很樂意將它放在這裡。 + +--- + +## 🤝 貢獻 + +歡迎貢獻！以下是貢獻指南： + +1. Fork 專案 +2. 新建分支（`git checkout -b feature/my-feature`） +3. 執行測試（`pnpm --filter @understand-anything/core test`） +4. 提交變更並建立 PR + +對於重大變更，請先提交 issue，以便我們討論解決方案。 + +--- + +

+ 不再盲讀程式碼，而是理解整個系統 +

+ +## Star 歷史記錄 + + + + + + Star History Chart + + + +

+ 感謝每一位使用過、貢獻過的朋友 —— 知道它替你們省下了一些時間，就是當初做它最值得的理由。 +

+ +

+ MIT 授權條款 © Lum1104 +

diff --git a/Understand-Anything-main/assets/hero.png b/Understand-Anything-main/assets/hero.png new file mode 100644 index 0000000..1f1f3f6 Binary files /dev/null and b/Understand-Anything-main/assets/hero.png differ diff --git a/Understand-Anything-main/assets/overview.png b/Understand-Anything-main/assets/overview.png new file mode 100644 index 0000000..2bdb095 Binary files /dev/null and b/Understand-Anything-main/assets/overview.png differ diff --git a/Understand-Anything-main/docs/superpowers/plans/2026-03-14-phase1-implementation.md b/Understand-Anything-main/docs/superpowers/plans/2026-03-14-phase1-implementation.md new file mode 100644 index 0000000..c85b24a --- /dev/null +++ b/Understand-Anything-main/docs/superpowers/plans/2026-03-14-phase1-implementation.md @@ -0,0 +1,2469 @@ +# Understand Anything — Phase 1 Implementation Plan + +> **For Claude:** REQUIRED SUB-SKILL: Use superpowers:executing-plans to implement this plan task-by-task. + +**Goal:** Build the foundational MVP — a pnpm monorepo with a core analysis engine (LLM + tree-sitter), a `/understand` skill command, and a basic React dashboard with graph view and code viewer. + +**Architecture:** Monorepo with 3 packages (core, skill, dashboard) sharing a knowledge graph JSON schema. The core package handles analysis and persistence. The skill invokes core and launches the dashboard. The dashboard reads the JSON and renders a multi-panel workspace. + +**Tech Stack:** TypeScript, pnpm workspaces, Vitest, React 18, Vite, @xyflow/react (React Flow v12), @monaco-editor/react, Zustand, TailwindCSS, tree-sitter + +--- + +## Task 1: Project Scaffolding — Monorepo Root + +**Files:** +- Create: `package.json` +- Create: `pnpm-workspace.yaml` +- Create: `tsconfig.json` +- Create: `.gitignore` +- Create: `.npmrc` + +**Step 1: Create root package.json** + +```json +{ + "name": "understand-anything", + "private": true, + "type": "module", + "packageManager": "pnpm@10.6.2", + "scripts": { + "build": "pnpm -r build", + "test": "vitest", + "dev:dashboard": "pnpm --filter @understand-anything/dashboard dev", + "lint": "eslint ." + }, + "devDependencies": { + "typescript": "^5.7.0", + "vitest": "^3.1.0" + } +} +``` + +**Step 2: Create pnpm-workspace.yaml** + +```yaml +packages: + - 'packages/*' +``` + +**Step 3: Create root tsconfig.json** + +```json +{ + "compilerOptions": { + "target": "ES2022", + "module": "ESNext", + "lib": ["ES2022"], + "moduleResolution": "bundler", + "strict": true, + "esModuleInterop": true, + "skipLibCheck": true, + "forceConsistentCasingInFileNames": true, + "resolveJsonModule": true, + "declaration": true, + "declarationMap": true, + "sourceMap": true, + "outDir": "dist", + "rootDir": "src" + } +} +``` + +**Step 4: Create .gitignore** + +``` +node_modules/ +dist/ +.understand-anything/ +*.tsbuildinfo +.DS_Store +``` + +**Step 5: Create .npmrc** + +``` +shamefully-hoist=false +strict-peer-dependencies=false +``` + +**Step 6: Run pnpm install** + +Run: `pnpm install` +Expected: lockfile created, no errors + +**Step 7: Commit** + +```bash +git add package.json pnpm-workspace.yaml tsconfig.json .gitignore .npmrc pnpm-lock.yaml +git commit -m "chore: scaffold monorepo root with pnpm workspaces" +``` + +--- + +## Task 2: Core Package — Scaffolding & Knowledge Graph Types + +**Files:** +- Create: `packages/core/package.json` +- Create: `packages/core/tsconfig.json` +- Create: `packages/core/src/index.ts` +- Create: `packages/core/src/types.ts` + +**Step 1: Create packages/core/package.json** + +```json +{ + "name": "@understand-anything/core", + "version": "0.1.0", + "type": "module", + "main": "dist/index.js", + "types": "dist/index.d.ts", + "scripts": { + "build": "tsc", + "test": "vitest run" + }, + "devDependencies": { + "typescript": "^5.7.0", + "vitest": "^3.1.0" + } +} +``` + +**Step 2: Create packages/core/tsconfig.json** + +```json +{ + "extends": "../../tsconfig.json", + "compilerOptions": { + "outDir": "dist", + "rootDir": "src" + }, + "include": ["src"] +} +``` + +**Step 3: Create packages/core/src/types.ts** + +This is the full Knowledge Graph type system from the design doc: + +```typescript +// === Edge Types === + +export type EdgeType = + // Structural + | "imports" + | "exports" + | "contains" + | "inherits" + | "implements" + // Behavioral + | "calls" + | "subscribes" + | "publishes" + | "middleware" + // Data flow + | "reads_from" + | "writes_to" + | "transforms" + | "validates" + // Dependencies + | "depends_on" + | "tested_by" + | "configures" + // Semantic + | "related" + | "similar_to"; + +// === Graph Node === + +export interface GraphNode { + id: string; + type: "file" | "function" | "class" | "module" | "concept"; + name: string; + filePath?: string; + lineRange?: [number, number]; + summary: string; + tags: string[]; + complexity: "simple" | "moderate" | "complex"; + languageNotes?: string; +} + +// === Graph Edge === + +export interface GraphEdge { + source: string; + target: string; + type: EdgeType; + direction: "forward" | "backward" | "bidirectional"; + description?: string; + weight: number; +} + +// === Layer === + +export interface Layer { + id: string; + name: string; + description: string; + nodeIds: string[]; +} + +// === Tour Step === + +export interface TourStep { + order: number; + title: string; + description: string; + nodeIds: string[]; + languageLesson?: string; +} + +// === Project Metadata === + +export interface ProjectMeta { + name: string; + languages: string[]; + frameworks: string[]; + description: string; + analyzedAt: string; + gitCommitHash: string; +} + +// === Knowledge Graph (root) === + +export interface KnowledgeGraph { + version: string; + project: ProjectMeta; + nodes: GraphNode[]; + edges: GraphEdge[]; + layers: Layer[]; + tour: TourStep[]; +} + +// === Analysis Metadata === + +export interface AnalysisMeta { + lastAnalyzedAt: string; + gitCommitHash: string; + version: string; + analyzedFiles: number; +} + +// === Plugin Interface === + +export interface StructuralAnalysis { + functions: Array<{ + name: string; + lineRange: [number, number]; + params: string[]; + returnType?: string; + }>; + classes: Array<{ + name: string; + lineRange: [number, number]; + methods: string[]; + properties: string[]; + }>; + imports: Array<{ + source: string; + specifiers: string[]; + lineNumber: number; + }>; + exports: Array<{ + name: string; + lineNumber: number; + }>; +} + +export interface ImportResolution { + source: string; + resolvedPath: string; + specifiers: string[]; +} + +export interface CallGraphEntry { + caller: string; + callee: string; + lineNumber: number; +} + +export interface AnalyzerPlugin { + name: string; + languages: string[]; + analyzeFile(filePath: string, content: string): StructuralAnalysis; + resolveImports(filePath: string, content: string): ImportResolution[]; + extractCallGraph?(filePath: string, content: string): CallGraphEntry[]; +} +``` + +**Step 4: Create packages/core/src/index.ts** + +```typescript +export * from "./types.js"; +``` + +**Step 5: Run pnpm install and build** + +Run: `cd /path/to/project && pnpm install && pnpm --filter @understand-anything/core build` +Expected: Compiles with no errors, `packages/core/dist/` created + +**Step 6: Write a type validation test** + +Create: `packages/core/src/types.test.ts` + +```typescript +import { describe, it, expect } from "vitest"; +import type { + KnowledgeGraph, + GraphNode, + GraphEdge, + ProjectMeta, +} from "./types.js"; + +describe("KnowledgeGraph types", () => { + it("should create a valid empty knowledge graph", () => { + const graph: KnowledgeGraph = { + version: "1.0.0", + project: { + name: "test-project", + languages: ["typescript"], + frameworks: [], + description: "A test project", + analyzedAt: new Date().toISOString(), + gitCommitHash: "abc123", + }, + nodes: [], + edges: [], + layers: [], + tour: [], + }; + + expect(graph.version).toBe("1.0.0"); + expect(graph.nodes).toHaveLength(0); + }); + + it("should create valid graph nodes", () => { + const node: GraphNode = { + id: "node-1", + type: "function", + name: "handleLogin", + filePath: "src/auth/login.ts", + lineRange: [10, 25], + summary: "Handles user login with email and password", + tags: ["auth", "login", "api"], + complexity: "moderate", + languageNotes: "Uses async/await for API calls", + }; + + expect(node.type).toBe("function"); + expect(node.tags).toContain("auth"); + }); + + it("should create valid graph edges", () => { + const edge: GraphEdge = { + source: "node-1", + target: "node-2", + type: "calls", + direction: "forward", + description: "handleLogin calls validateCredentials", + weight: 0.8, + }; + + expect(edge.type).toBe("calls"); + expect(edge.weight).toBeGreaterThan(0); + expect(edge.weight).toBeLessThanOrEqual(1); + }); +}); +``` + +**Step 7: Run tests** + +Run: `pnpm --filter @understand-anything/core test` +Expected: All 3 tests PASS + +**Step 8: Commit** + +```bash +git add packages/core/ +git commit -m "feat(core): add knowledge graph type system and validation tests" +``` + +--- + +## Task 3: Core Package — JSON Persistence + +**Files:** +- Create: `packages/core/src/persistence/index.ts` +- Create: `packages/core/src/persistence/persistence.test.ts` + +**Step 1: Write the failing test** + +Create: `packages/core/src/persistence/persistence.test.ts` + +```typescript +import { describe, it, expect, beforeEach, afterEach } from "vitest"; +import { writeFileSync, mkdirSync, rmSync, existsSync } from "node:fs"; +import { join } from "node:path"; +import { tmpdir } from "node:os"; +import { loadGraph, saveGraph, loadMeta, saveMeta } from "./index.js"; +import type { KnowledgeGraph, AnalysisMeta } from "../types.js"; + +describe("Persistence", () => { + let testDir: string; + + beforeEach(() => { + testDir = join(tmpdir(), `ua-test-${Date.now()}`); + mkdirSync(testDir, { recursive: true }); + }); + + afterEach(() => { + rmSync(testDir, { recursive: true, force: true }); + }); + + const makeGraph = (): KnowledgeGraph => ({ + version: "1.0.0", + project: { + name: "test", + languages: ["typescript"], + frameworks: [], + description: "test project", + analyzedAt: new Date().toISOString(), + gitCommitHash: "abc123", + }, + nodes: [ + { + id: "n1", + type: "file", + name: "index.ts", + summary: "Entry point", + tags: ["entry"], + complexity: "simple", + }, + ], + edges: [], + layers: [], + tour: [], + }); + + it("saveGraph writes knowledge-graph.json", () => { + const graph = makeGraph(); + saveGraph(testDir, graph); + + const filePath = join(testDir, ".understand-anything", "knowledge-graph.json"); + expect(existsSync(filePath)).toBe(true); + }); + + it("loadGraph reads back the saved graph", () => { + const graph = makeGraph(); + saveGraph(testDir, graph); + const loaded = loadGraph(testDir); + + expect(loaded).not.toBeNull(); + expect(loaded!.project.name).toBe("test"); + expect(loaded!.nodes).toHaveLength(1); + }); + + it("loadGraph returns null when no graph exists", () => { + const loaded = loadGraph(testDir); + expect(loaded).toBeNull(); + }); + + it("saveMeta writes meta.json", () => { + const meta: AnalysisMeta = { + lastAnalyzedAt: new Date().toISOString(), + gitCommitHash: "abc123", + version: "1.0.0", + analyzedFiles: 5, + }; + saveMeta(testDir, meta); + + const filePath = join(testDir, ".understand-anything", "meta.json"); + expect(existsSync(filePath)).toBe(true); + }); + + it("loadMeta reads back saved meta", () => { + const meta: AnalysisMeta = { + lastAnalyzedAt: new Date().toISOString(), + gitCommitHash: "def456", + version: "1.0.0", + analyzedFiles: 10, + }; + saveMeta(testDir, meta); + const loaded = loadMeta(testDir); + + expect(loaded).not.toBeNull(); + expect(loaded!.gitCommitHash).toBe("def456"); + expect(loaded!.analyzedFiles).toBe(10); + }); + + it("loadMeta returns null when no meta exists", () => { + const loaded = loadMeta(testDir); + expect(loaded).toBeNull(); + }); +}); +``` + +**Step 2: Run test to verify it fails** + +Run: `pnpm --filter @understand-anything/core test` +Expected: FAIL — module `./index.js` not found + +**Step 3: Implement persistence module** + +Create: `packages/core/src/persistence/index.ts` + +```typescript +import { readFileSync, writeFileSync, mkdirSync, existsSync } from "node:fs"; +import { join } from "node:path"; +import type { KnowledgeGraph, AnalysisMeta } from "../types.js"; + +const UA_DIR = ".understand-anything"; +const GRAPH_FILE = "knowledge-graph.json"; +const META_FILE = "meta.json"; + +function ensureDir(projectRoot: string): string { + const dir = join(projectRoot, UA_DIR); + if (!existsSync(dir)) { + mkdirSync(dir, { recursive: true }); + } + return dir; +} + +export function saveGraph(projectRoot: string, graph: KnowledgeGraph): void { + const dir = ensureDir(projectRoot); + const filePath = join(dir, GRAPH_FILE); + writeFileSync(filePath, JSON.stringify(graph, null, 2), "utf-8"); +} + +export function loadGraph(projectRoot: string): KnowledgeGraph | null { + const filePath = join(projectRoot, UA_DIR, GRAPH_FILE); + if (!existsSync(filePath)) return null; + const content = readFileSync(filePath, "utf-8"); + return JSON.parse(content) as KnowledgeGraph; +} + +export function saveMeta(projectRoot: string, meta: AnalysisMeta): void { + const dir = ensureDir(projectRoot); + const filePath = join(dir, META_FILE); + writeFileSync(filePath, JSON.stringify(meta, null, 2), "utf-8"); +} + +export function loadMeta(projectRoot: string): AnalysisMeta | null { + const filePath = join(projectRoot, UA_DIR, META_FILE); + if (!existsSync(filePath)) return null; + const content = readFileSync(filePath, "utf-8"); + return JSON.parse(content) as AnalysisMeta; +} +``` + +**Step 4: Update packages/core/src/index.ts** + +```typescript +export * from "./types.js"; +export * from "./persistence/index.js"; +``` + +**Step 5: Run tests** + +Run: `pnpm --filter @understand-anything/core test` +Expected: All 6 persistence tests PASS + 3 type tests PASS = 9 total + +**Step 6: Commit** + +```bash +git add packages/core/src/persistence/ packages/core/src/index.ts +git commit -m "feat(core): add JSON persistence for knowledge graph and meta" +``` + +--- + +## Task 4: Core Package — Tree-sitter Analyzer Plugin + +**Files:** +- Create: `packages/core/src/plugins/tree-sitter-plugin.ts` +- Create: `packages/core/src/plugins/tree-sitter-plugin.test.ts` + +**Step 1: Install tree-sitter dependencies** + +Run: `pnpm --filter @understand-anything/core add tree-sitter tree-sitter-javascript tree-sitter-typescript` +Expected: packages installed + +**Step 2: Write the failing test** + +Create: `packages/core/src/plugins/tree-sitter-plugin.test.ts` + +```typescript +import { describe, it, expect } from "vitest"; +import { TreeSitterPlugin } from "./tree-sitter-plugin.js"; + +describe("TreeSitterPlugin", () => { + const plugin = new TreeSitterPlugin(); + + describe("analyzeFile — TypeScript", () => { + const tsCode = ` +import { Request, Response } from "express"; +import { db } from "../db/connection"; + +export function handleLogin(req: Request, res: Response): void { + const { email, password } = req.body; + validateCredentials(email, password); +} + +function validateCredentials(email: string, password: string): boolean { + return email.length > 0 && password.length > 0; +} + +export class AuthService { + private secret: string; + + constructor(secret: string) { + this.secret = secret; + } + + verify(token: string): boolean { + return token.length > 0; + } + + refresh(token: string): string { + return token; + } +} +`; + + it("extracts function declarations", () => { + const result = plugin.analyzeFile("src/auth.ts", tsCode); + const funcNames = result.functions.map((f) => f.name); + expect(funcNames).toContain("handleLogin"); + expect(funcNames).toContain("validateCredentials"); + }); + + it("extracts class declarations with methods", () => { + const result = plugin.analyzeFile("src/auth.ts", tsCode); + expect(result.classes).toHaveLength(1); + expect(result.classes[0].name).toBe("AuthService"); + expect(result.classes[0].methods).toContain("verify"); + expect(result.classes[0].methods).toContain("refresh"); + }); + + it("extracts import statements", () => { + const result = plugin.analyzeFile("src/auth.ts", tsCode); + const sources = result.imports.map((i) => i.source); + expect(sources).toContain("express"); + expect(sources).toContain("../db/connection"); + }); + + it("extracts export names", () => { + const result = plugin.analyzeFile("src/auth.ts", tsCode); + const exportNames = result.exports.map((e) => e.name); + expect(exportNames).toContain("handleLogin"); + expect(exportNames).toContain("AuthService"); + }); + }); + + describe("analyzeFile — JavaScript", () => { + const jsCode = ` +const express = require("express"); + +function middleware(req, res, next) { + next(); +} + +module.exports = { middleware }; +`; + + it("extracts functions from JavaScript", () => { + const result = plugin.analyzeFile("src/app.js", jsCode); + const funcNames = result.functions.map((f) => f.name); + expect(funcNames).toContain("middleware"); + }); + }); + + describe("resolveImports", () => { + const code = ` +import { foo } from "./utils"; +import bar from "../lib/bar"; +import * as path from "path"; +`; + + it("resolves relative import paths", () => { + const imports = plugin.resolveImports("src/index.ts", code); + const paths = imports.map((i) => i.source); + expect(paths).toContain("./utils"); + expect(paths).toContain("../lib/bar"); + expect(paths).toContain("path"); + }); + }); + + describe("languages", () => { + it("supports typescript and javascript", () => { + expect(plugin.languages).toContain("typescript"); + expect(plugin.languages).toContain("javascript"); + }); + }); +}); +``` + +**Step 3: Run test to verify it fails** + +Run: `pnpm --filter @understand-anything/core test` +Expected: FAIL — module not found + +**Step 4: Implement the tree-sitter plugin** + +Create: `packages/core/src/plugins/tree-sitter-plugin.ts` + +```typescript +import Parser from "tree-sitter"; +import TypeScript from "tree-sitter-typescript"; +import JavaScript from "tree-sitter-javascript"; +import type { + AnalyzerPlugin, + StructuralAnalysis, + ImportResolution, + CallGraphEntry, +} from "../types.js"; + +const tsParser = new Parser(); +tsParser.setLanguage(TypeScript.typescript); + +const jsParser = new Parser(); +jsParser.setLanguage(JavaScript); + +function getParser(filePath: string): Parser { + if (filePath.endsWith(".ts") || filePath.endsWith(".tsx")) return tsParser; + return jsParser; +} + +function traverse( + node: Parser.SyntaxNode, + callback: (node: Parser.SyntaxNode) => void, +): void { + callback(node); + for (let i = 0; i < node.childCount; i++) { + traverse(node.child(i)!, callback); + } +} + +export class TreeSitterPlugin implements AnalyzerPlugin { + name = "tree-sitter"; + languages = ["typescript", "javascript"]; + + analyzeFile(filePath: string, content: string): StructuralAnalysis { + const parser = getParser(filePath); + const tree = parser.parse(content); + const root = tree.rootNode; + + const functions: StructuralAnalysis["functions"] = []; + const classes: StructuralAnalysis["classes"] = []; + const imports: StructuralAnalysis["imports"] = []; + const exports: StructuralAnalysis["exports"] = []; + + traverse(root, (node) => { + // Function declarations + if ( + node.type === "function_declaration" || + node.type === "function_signature" + ) { + const nameNode = node.childByFieldName("name"); + if (nameNode) { + functions.push({ + name: nameNode.text, + lineRange: [node.startPosition.row + 1, node.endPosition.row + 1], + params: this.extractParams(node), + }); + } + } + + // Arrow functions assigned to variables + if ( + node.type === "lexical_declaration" || + node.type === "variable_declaration" + ) { + for (let i = 0; i < node.childCount; i++) { + const child = node.child(i); + if (child?.type === "variable_declarator") { + const nameNode = child.childByFieldName("name"); + const valueNode = child.childByFieldName("value"); + if (nameNode && valueNode?.type === "arrow_function") { + functions.push({ + name: nameNode.text, + lineRange: [ + node.startPosition.row + 1, + node.endPosition.row + 1, + ], + params: this.extractParams(valueNode), + }); + } + } + } + } + + // Class declarations + if (node.type === "class_declaration") { + const nameNode = node.childByFieldName("name"); + const bodyNode = node.childByFieldName("body"); + if (nameNode && bodyNode) { + const methods: string[] = []; + const properties: string[] = []; + + for (let i = 0; i < bodyNode.childCount; i++) { + const member = bodyNode.child(i); + if (member?.type === "method_definition") { + const methodName = member.childByFieldName("name"); + if (methodName && methodName.text !== "constructor") { + methods.push(methodName.text); + } + } + if ( + member?.type === "public_field_definition" || + member?.type === "property_definition" + ) { + const propName = member.childByFieldName("name"); + if (propName) properties.push(propName.text); + } + } + + classes.push({ + name: nameNode.text, + lineRange: [ + node.startPosition.row + 1, + node.endPosition.row + 1, + ], + methods, + properties, + }); + } + } + + // Import statements + if (node.type === "import_statement") { + const sourceNode = node.children.find( + (c) => c.type === "string" || c.type === "string_fragment", + ); + let source = ""; + if (sourceNode) { + source = sourceNode.text.replace(/['"]/g, ""); + } + // Try to find string_fragment inside string + if (!source) { + traverse(node, (child) => { + if (child.type === "string_fragment" || child.type === "string_content") { + source = child.text; + } + }); + } + + const specifiers: string[] = []; + traverse(node, (child) => { + if (child.type === "import_specifier") { + const nameChild = child.childByFieldName("name"); + if (nameChild) specifiers.push(nameChild.text); + } + if (child.type === "identifier" && child.parent?.type === "import_clause") { + specifiers.push(child.text); + } + if (child.type === "namespace_import") { + const nameChild = child.children.find((c) => c.type === "identifier"); + if (nameChild) specifiers.push(`* as ${nameChild.text}`); + } + }); + + if (source) { + imports.push({ + source, + specifiers, + lineNumber: node.startPosition.row + 1, + }); + } + } + + // Export statements + if (node.type === "export_statement") { + // export function / export class + for (let i = 0; i < node.childCount; i++) { + const child = node.child(i); + if ( + child?.type === "function_declaration" || + child?.type === "class_declaration" + ) { + const nameNode = child.childByFieldName("name"); + if (nameNode) { + exports.push({ + name: nameNode.text, + lineNumber: node.startPosition.row + 1, + }); + } + } + if (child?.type === "lexical_declaration") { + traverse(child, (grandchild) => { + if (grandchild.type === "variable_declarator") { + const nameNode = grandchild.childByFieldName("name"); + if (nameNode) { + exports.push({ + name: nameNode.text, + lineNumber: node.startPosition.row + 1, + }); + } + } + }); + } + } + } + }); + + return { functions, classes, imports, exports }; + } + + resolveImports(filePath: string, content: string): ImportResolution[] { + const analysis = this.analyzeFile(filePath, content); + return analysis.imports.map((imp) => ({ + source: imp.source, + resolvedPath: imp.source, // Basic — full resolution needs fs access + specifiers: imp.specifiers, + })); + } + + extractCallGraph(filePath: string, content: string): CallGraphEntry[] { + const parser = getParser(filePath); + const tree = parser.parse(content); + const entries: CallGraphEntry[] = []; + + // Find all function scopes and call expressions within them + const functionScopes: Array<{ + name: string; + node: Parser.SyntaxNode; + }> = []; + + traverse(tree.rootNode, (node) => { + if (node.type === "function_declaration") { + const nameNode = node.childByFieldName("name"); + if (nameNode) { + functionScopes.push({ name: nameNode.text, node }); + } + } + }); + + for (const scope of functionScopes) { + traverse(scope.node, (node) => { + if (node.type === "call_expression") { + const funcNode = node.childByFieldName("function"); + if (funcNode) { + const callee = + funcNode.type === "member_expression" + ? funcNode.text + : funcNode.text; + entries.push({ + caller: scope.name, + callee, + lineNumber: node.startPosition.row + 1, + }); + } + } + }); + } + + return entries; + } + + private extractParams(node: Parser.SyntaxNode): string[] { + const params: string[] = []; + const paramsNode = node.childByFieldName("parameters"); + if (paramsNode) { + for (let i = 0; i < paramsNode.childCount; i++) { + const param = paramsNode.child(i); + if ( + param && + param.type !== "," && + param.type !== "(" && + param.type !== ")" + ) { + const nameNode = param.childByFieldName("name") || + param.childByFieldName("pattern"); + if (nameNode) params.push(nameNode.text); + else if (param.type === "identifier") params.push(param.text); + } + } + } + return params; + } +} +``` + +**Step 5: Update packages/core/src/index.ts** + +```typescript +export * from "./types.js"; +export * from "./persistence/index.js"; +export { TreeSitterPlugin } from "./plugins/tree-sitter-plugin.js"; +``` + +**Step 6: Run tests** + +Run: `pnpm --filter @understand-anything/core test` +Expected: All tree-sitter tests PASS. Some tests may need adjustment based on exact tree-sitter parse output — iterate until green. + +**Step 7: Commit** + +```bash +git add packages/core/src/plugins/ packages/core/src/index.ts packages/core/package.json pnpm-lock.yaml +git commit -m "feat(core): add tree-sitter analyzer plugin for TS/JS" +``` + +--- + +## Task 5: Core Package — LLM Analysis Engine + +**Files:** +- Create: `packages/core/src/analyzer/llm-analyzer.ts` +- Create: `packages/core/src/analyzer/llm-analyzer.test.ts` +- Create: `packages/core/src/analyzer/graph-builder.ts` +- Create: `packages/core/src/analyzer/graph-builder.test.ts` + +**Step 1: Write the graph builder test** + +The graph builder takes structural analysis + LLM summaries and assembles a KnowledgeGraph. + +Create: `packages/core/src/analyzer/graph-builder.test.ts` + +```typescript +import { describe, it, expect } from "vitest"; +import { GraphBuilder } from "./graph-builder.js"; +import type { StructuralAnalysis } from "../types.js"; + +describe("GraphBuilder", () => { + it("creates file nodes from file list", () => { + const builder = new GraphBuilder("test-project", "abc123"); + + builder.addFile("src/index.ts", { + summary: "Application entry point", + tags: ["entry", "main"], + complexity: "simple" as const, + }); + + const graph = builder.build(); + expect(graph.nodes).toHaveLength(1); + expect(graph.nodes[0].type).toBe("file"); + expect(graph.nodes[0].name).toBe("index.ts"); + expect(graph.nodes[0].filePath).toBe("src/index.ts"); + }); + + it("creates function nodes from structural analysis", () => { + const builder = new GraphBuilder("test-project", "abc123"); + const analysis: StructuralAnalysis = { + functions: [ + { name: "handleLogin", lineRange: [5, 15], params: ["req", "res"] }, + ], + classes: [], + imports: [], + exports: [], + }; + + builder.addFileWithAnalysis("src/auth.ts", analysis, { + summaries: { handleLogin: "Handles user login" }, + fileSummary: "Authentication module", + tags: ["auth"], + complexity: "moderate" as const, + }); + + const graph = builder.build(); + const funcNodes = graph.nodes.filter((n) => n.type === "function"); + expect(funcNodes).toHaveLength(1); + expect(funcNodes[0].name).toBe("handleLogin"); + expect(funcNodes[0].summary).toBe("Handles user login"); + }); + + it("creates contains edges between files and their functions", () => { + const builder = new GraphBuilder("test-project", "abc123"); + const analysis: StructuralAnalysis = { + functions: [ + { name: "foo", lineRange: [1, 5], params: [] }, + ], + classes: [], + imports: [], + exports: [], + }; + + builder.addFileWithAnalysis("src/utils.ts", analysis, { + summaries: { foo: "A utility function" }, + fileSummary: "Utility functions", + tags: ["utils"], + complexity: "simple" as const, + }); + + const graph = builder.build(); + const containsEdges = graph.edges.filter((e) => e.type === "contains"); + expect(containsEdges).toHaveLength(1); + expect(containsEdges[0].direction).toBe("forward"); + }); + + it("creates import edges from structural analysis", () => { + const builder = new GraphBuilder("test-project", "abc123"); + + builder.addFile("src/index.ts", { + summary: "Entry", + tags: [], + complexity: "simple" as const, + }); + builder.addFile("src/utils.ts", { + summary: "Utils", + tags: [], + complexity: "simple" as const, + }); + + builder.addImportEdge("src/index.ts", "src/utils.ts"); + + const graph = builder.build(); + const importEdges = graph.edges.filter((e) => e.type === "imports"); + expect(importEdges).toHaveLength(1); + }); + + it("sets project metadata correctly", () => { + const builder = new GraphBuilder("my-project", "def456"); + const graph = builder.build(); + + expect(graph.project.name).toBe("my-project"); + expect(graph.project.gitCommitHash).toBe("def456"); + expect(graph.version).toBe("1.0.0"); + }); +}); +``` + +**Step 2: Run test to verify it fails** + +Run: `pnpm --filter @understand-anything/core test` +Expected: FAIL — module not found + +**Step 3: Implement GraphBuilder** + +Create: `packages/core/src/analyzer/graph-builder.ts` + +```typescript +import type { + KnowledgeGraph, + GraphNode, + GraphEdge, + StructuralAnalysis, +} from "../types.js"; + +interface FileMeta { + summary: string; + tags: string[]; + complexity: "simple" | "moderate" | "complex"; +} + +interface FileAnalysisMeta extends FileMeta { + summaries: Record; // function/class name -> summary + fileSummary: string; +} + +function fileId(filePath: string): string { + return `file:${filePath}`; +} + +function funcId(filePath: string, funcName: string): string { + return `func:${filePath}:${funcName}`; +} + +function classId(filePath: string, className: string): string { + return `class:${filePath}:${className}`; +} + +export class GraphBuilder { + private nodes: GraphNode[] = []; + private edges: GraphEdge[] = []; + private projectName: string; + private gitHash: string; + private languages: Set = new Set(); + + constructor(projectName: string, gitHash: string) { + this.projectName = projectName; + this.gitHash = gitHash; + } + + addFile(filePath: string, meta: FileMeta): void { + const ext = filePath.split(".").pop() || ""; + this.detectLanguage(ext); + + const name = filePath.split("/").pop() || filePath; + this.nodes.push({ + id: fileId(filePath), + type: "file", + name, + filePath, + summary: meta.summary, + tags: meta.tags, + complexity: meta.complexity, + }); + } + + addFileWithAnalysis( + filePath: string, + analysis: StructuralAnalysis, + meta: FileAnalysisMeta, + ): void { + // Add the file node + this.addFile(filePath, { + summary: meta.fileSummary, + tags: meta.tags, + complexity: meta.complexity, + }); + + const fId = fileId(filePath); + + // Add function nodes + for (const func of analysis.functions) { + const id = funcId(filePath, func.name); + this.nodes.push({ + id, + type: "function", + name: func.name, + filePath, + lineRange: func.lineRange, + summary: meta.summaries[func.name] || `Function ${func.name}`, + tags: meta.tags, + complexity: meta.complexity, + }); + + // File contains function + this.edges.push({ + source: fId, + target: id, + type: "contains", + direction: "forward", + weight: 1.0, + }); + } + + // Add class nodes + for (const cls of analysis.classes) { + const id = classId(filePath, cls.name); + this.nodes.push({ + id, + type: "class", + name: cls.name, + filePath, + lineRange: cls.lineRange, + summary: meta.summaries[cls.name] || `Class ${cls.name}`, + tags: meta.tags, + complexity: meta.complexity, + }); + + // File contains class + this.edges.push({ + source: fId, + target: id, + type: "contains", + direction: "forward", + weight: 1.0, + }); + } + } + + addImportEdge(fromFile: string, toFile: string): void { + this.edges.push({ + source: fileId(fromFile), + target: fileId(toFile), + type: "imports", + direction: "forward", + weight: 0.7, + }); + } + + addCallEdge( + callerFile: string, + callerFunc: string, + calleeFile: string, + calleeFunc: string, + ): void { + this.edges.push({ + source: funcId(callerFile, callerFunc), + target: funcId(calleeFile, calleeFunc), + type: "calls", + direction: "forward", + weight: 0.8, + }); + } + + build(): KnowledgeGraph { + return { + version: "1.0.0", + project: { + name: this.projectName, + languages: Array.from(this.languages), + frameworks: [], + description: "", + analyzedAt: new Date().toISOString(), + gitCommitHash: this.gitHash, + }, + nodes: this.nodes, + edges: this.edges, + layers: [], + tour: [], + }; + } + + private detectLanguage(ext: string): void { + const langMap: Record = { + ts: "typescript", + tsx: "typescript", + js: "javascript", + jsx: "javascript", + py: "python", + go: "go", + rs: "rust", + java: "java", + c: "c", + cpp: "cpp", + h: "c", + }; + if (langMap[ext]) this.languages.add(langMap[ext]); + } +} +``` + +**Step 4: Run tests** + +Run: `pnpm --filter @understand-anything/core test` +Expected: All GraphBuilder tests PASS + +**Step 5: Create the LLM analyzer interface** + +Create: `packages/core/src/analyzer/llm-analyzer.ts` + +This defines the interface for LLM-based analysis. The actual LLM calls happen via the skill (which has access to the Claude session). The core package defines the prompts and expected response format. + +```typescript +/** + * LLM Analyzer — defines prompts and response parsing for LLM-based code analysis. + * + * The actual LLM invocation is handled by the caller (skill or dashboard with API key). + * This module provides the prompt templates and response parsers. + */ + +export interface LLMFileAnalysis { + fileSummary: string; + tags: string[]; + complexity: "simple" | "moderate" | "complex"; + functionSummaries: Record; + classSummaries: Record; + languageNotes?: string; +} + +export interface LLMProjectSummary { + description: string; + frameworks: string[]; + layers: Array<{ + name: string; + description: string; + filePatterns: string[]; + }>; +} + +/** + * Generates the prompt for analyzing a single file. + */ +export function buildFileAnalysisPrompt( + filePath: string, + content: string, + projectContext: string, +): string { + return `You are analyzing a source code file as part of a codebase understanding tool. + +Project context: ${projectContext} + +File: ${filePath} + +\`\`\` +${content} +\`\`\` + +Analyze this file and respond with ONLY valid JSON (no markdown, no explanation): + +{ + "fileSummary": "One-sentence plain-English description of what this file does", + "tags": ["tag1", "tag2"], + "complexity": "simple|moderate|complex", + "functionSummaries": { + "functionName": "What this function does in plain English" + }, + "classSummaries": { + "className": "What this class does in plain English" + }, + "languageNotes": "Optional: any language-specific patterns worth noting for someone unfamiliar with this language" +}`; +} + +/** + * Generates the prompt for a project-level summary. + */ +export function buildProjectSummaryPrompt( + fileList: string[], + sampleFiles: Array<{ path: string; content: string }>, +): string { + const fileListStr = fileList.map((f) => ` - ${f}`).join("\n"); + const sampleStr = sampleFiles + .map((f) => `### ${f.path}\n\`\`\`\n${f.content.slice(0, 500)}\n\`\`\``) + .join("\n\n"); + + return `You are analyzing a software project to generate a high-level understanding. + +File list: +${fileListStr} + +Sample files: +${sampleStr} + +Analyze this project and respond with ONLY valid JSON: + +{ + "description": "2-3 sentence description of what this project does", + "frameworks": ["framework1", "library1"], + "layers": [ + { + "name": "Layer Name", + "description": "What this layer handles", + "filePatterns": ["src/api/**", "src/routes/**"] + } + ] +}`; +} + +/** + * Parses the LLM response for file analysis. Handles common LLM output issues. + */ +export function parseFileAnalysisResponse( + response: string, +): LLMFileAnalysis | null { + try { + // Strip markdown code fences if present + let cleaned = response.trim(); + if (cleaned.startsWith("```")) { + cleaned = cleaned.replace(/^```(?:json)?\n?/, "").replace(/\n?```$/, ""); + } + const parsed = JSON.parse(cleaned); + + return { + fileSummary: parsed.fileSummary || "No summary available", + tags: Array.isArray(parsed.tags) ? parsed.tags : [], + complexity: ["simple", "moderate", "complex"].includes(parsed.complexity) + ? parsed.complexity + : "moderate", + functionSummaries: parsed.functionSummaries || {}, + classSummaries: parsed.classSummaries || {}, + languageNotes: parsed.languageNotes, + }; + } catch { + return null; + } +} + +/** + * Parses the LLM response for project summary. + */ +export function parseProjectSummaryResponse( + response: string, +): LLMProjectSummary | null { + try { + let cleaned = response.trim(); + if (cleaned.startsWith("```")) { + cleaned = cleaned.replace(/^```(?:json)?\n?/, "").replace(/\n?```$/, ""); + } + const parsed = JSON.parse(cleaned); + + return { + description: parsed.description || "", + frameworks: Array.isArray(parsed.frameworks) ? parsed.frameworks : [], + layers: Array.isArray(parsed.layers) ? parsed.layers : [], + }; + } catch { + return null; + } +} +``` + +**Step 6: Write tests for LLM analyzer** + +Create: `packages/core/src/analyzer/llm-analyzer.test.ts` + +```typescript +import { describe, it, expect } from "vitest"; +import { + buildFileAnalysisPrompt, + parseFileAnalysisResponse, + buildProjectSummaryPrompt, + parseProjectSummaryResponse, +} from "./llm-analyzer.js"; + +describe("LLM Analyzer", () => { + describe("buildFileAnalysisPrompt", () => { + it("includes file path and content", () => { + const prompt = buildFileAnalysisPrompt( + "src/auth.ts", + "function login() {}", + "A web app", + ); + expect(prompt).toContain("src/auth.ts"); + expect(prompt).toContain("function login() {}"); + expect(prompt).toContain("A web app"); + }); + }); + + describe("parseFileAnalysisResponse", () => { + it("parses valid JSON response", () => { + const response = JSON.stringify({ + fileSummary: "Handles authentication", + tags: ["auth", "login"], + complexity: "moderate", + functionSummaries: { login: "Logs user in" }, + classSummaries: {}, + }); + + const result = parseFileAnalysisResponse(response); + expect(result).not.toBeNull(); + expect(result!.fileSummary).toBe("Handles authentication"); + expect(result!.tags).toContain("auth"); + }); + + it("handles markdown-wrapped JSON", () => { + const response = '```json\n{"fileSummary": "Test", "tags": [], "complexity": "simple", "functionSummaries": {}, "classSummaries": {}}\n```'; + + const result = parseFileAnalysisResponse(response); + expect(result).not.toBeNull(); + expect(result!.fileSummary).toBe("Test"); + }); + + it("returns null for invalid JSON", () => { + const result = parseFileAnalysisResponse("not json at all"); + expect(result).toBeNull(); + }); + + it("defaults complexity to moderate for unknown values", () => { + const response = JSON.stringify({ + fileSummary: "Test", + tags: [], + complexity: "unknown", + functionSummaries: {}, + classSummaries: {}, + }); + + const result = parseFileAnalysisResponse(response); + expect(result!.complexity).toBe("moderate"); + }); + }); + + describe("buildProjectSummaryPrompt", () => { + it("includes file list", () => { + const prompt = buildProjectSummaryPrompt( + ["src/index.ts", "src/auth.ts"], + [{ path: "src/index.ts", content: "console.log('hi')" }], + ); + expect(prompt).toContain("src/index.ts"); + expect(prompt).toContain("src/auth.ts"); + }); + }); + + describe("parseProjectSummaryResponse", () => { + it("parses valid response", () => { + const response = JSON.stringify({ + description: "A REST API", + frameworks: ["express"], + layers: [{ name: "API", description: "HTTP layer", filePatterns: ["src/routes/**"] }], + }); + + const result = parseProjectSummaryResponse(response); + expect(result).not.toBeNull(); + expect(result!.frameworks).toContain("express"); + expect(result!.layers).toHaveLength(1); + }); + }); +}); +``` + +**Step 7: Update packages/core/src/index.ts** + +```typescript +export * from "./types.js"; +export * from "./persistence/index.js"; +export { TreeSitterPlugin } from "./plugins/tree-sitter-plugin.js"; +export { GraphBuilder } from "./analyzer/graph-builder.js"; +export { + buildFileAnalysisPrompt, + buildProjectSummaryPrompt, + parseFileAnalysisResponse, + parseProjectSummaryResponse, +} from "./analyzer/llm-analyzer.js"; +export type { + LLMFileAnalysis, + LLMProjectSummary, +} from "./analyzer/llm-analyzer.js"; +``` + +**Step 8: Run all tests** + +Run: `pnpm --filter @understand-anything/core test` +Expected: All tests PASS + +**Step 9: Commit** + +```bash +git add packages/core/src/analyzer/ packages/core/src/index.ts +git commit -m "feat(core): add graph builder and LLM analysis prompt system" +``` + +--- + +## Task 6: Dashboard Package — Scaffolding with Vite + React + +**Files:** +- Create: `packages/dashboard/` (via Vite scaffold, then customize) + +**Step 1: Scaffold React app with Vite** + +Run: `cd packages && pnpm create vite dashboard --template react-ts` +Then: Remove boilerplate (App.css, etc.), keep structure. + +**Step 2: Install dashboard dependencies** + +Run: `cd packages/dashboard && pnpm add @xyflow/react @monaco-editor/react zustand && pnpm add -D tailwindcss @tailwindcss/vite` + +**Step 3: Configure TailwindCSS** + +Update `packages/dashboard/vite.config.ts`: + +```typescript +import { defineConfig } from "vite"; +import react from "@vitejs/plugin-react"; +import tailwindcss from "@tailwindcss/vite"; + +export default defineConfig({ + plugins: [react(), tailwindcss()], +}); +``` + +Replace `packages/dashboard/src/index.css`: + +```css +@import "tailwindcss"; +``` + +**Step 4: Add workspace dependency on core** + +Add to `packages/dashboard/package.json` dependencies: + +```json +"@understand-anything/core": "workspace:*" +``` + +Run: `pnpm install` + +**Step 5: Create the Zustand store** + +Create: `packages/dashboard/src/store.ts` + +```typescript +import { create } from "zustand"; +import type { KnowledgeGraph, GraphNode } from "@understand-anything/core"; + +interface DashboardStore { + graph: KnowledgeGraph | null; + selectedNodeId: string | null; + searchQuery: string; + searchResults: string[]; // node IDs + + setGraph: (graph: KnowledgeGraph) => void; + selectNode: (nodeId: string | null) => void; + setSearchQuery: (query: string) => void; +} + +export const useDashboardStore = create()((set, get) => ({ + graph: null, + selectedNodeId: null, + searchQuery: "", + searchResults: [], + + setGraph: (graph) => set({ graph }), + + selectNode: (nodeId) => set({ selectedNodeId: nodeId }), + + setSearchQuery: (query) => { + const graph = get().graph; + if (!graph || !query.trim()) { + set({ searchQuery: query, searchResults: [] }); + return; + } + + const lower = query.toLowerCase(); + const results = graph.nodes + .filter( + (node) => + node.name.toLowerCase().includes(lower) || + node.summary.toLowerCase().includes(lower) || + node.tags.some((tag) => tag.toLowerCase().includes(lower)), + ) + .map((n) => n.id); + + set({ searchQuery: query, searchResults: results }); + }, +})); +``` + +**Step 6: Commit** + +```bash +git add packages/dashboard/ +git commit -m "feat(dashboard): scaffold React + Vite app with Tailwind, Zustand, and core dependency" +``` + +--- + +## Task 7: Dashboard — Graph View Panel with React Flow + +**Files:** +- Create: `packages/dashboard/src/components/GraphView.tsx` +- Create: `packages/dashboard/src/components/CustomNode.tsx` + +**Step 1: Create the custom node component** + +Create: `packages/dashboard/src/components/CustomNode.tsx` + +```tsx +import { Handle, Position } from "@xyflow/react"; +import type { NodeProps } from "@xyflow/react"; + +interface CustomNodeData { + label: string; + nodeType: "file" | "function" | "class" | "module" | "concept"; + summary: string; + complexity: "simple" | "moderate" | "complex"; + isHighlighted: boolean; + isSelected: boolean; + [key: string]: unknown; +} + +const typeColors: Record = { + file: "bg-blue-900 border-blue-500", + function: "bg-green-900 border-green-500", + class: "bg-purple-900 border-purple-500", + module: "bg-orange-900 border-orange-500", + concept: "bg-pink-900 border-pink-500", +}; + +const complexityBadge: Record = { + simple: "bg-green-700 text-green-100", + moderate: "bg-yellow-700 text-yellow-100", + complex: "bg-red-700 text-red-100", +}; + +export function CustomNode({ data }: NodeProps) { + const colorClass = typeColors[data.nodeType] || "bg-gray-900 border-gray-500"; + const highlightClass = data.isHighlighted + ? "ring-2 ring-yellow-400 shadow-lg shadow-yellow-400/20" + : ""; + const selectedClass = data.isSelected + ? "ring-2 ring-white shadow-lg" + : ""; + + return ( +
+ + +
+ + {data.nodeType} + + + {data.complexity} + +
+ +
+ {data.label} +
+ +
+ {data.summary} +
+ + +
+ ); +} +``` + +**Step 2: Create the GraphView component** + +Create: `packages/dashboard/src/components/GraphView.tsx` + +```tsx +import { useCallback, useMemo } from "react"; +import { + ReactFlow, + useNodesState, + useEdgesState, + Background, + Controls, + MiniMap, +} from "@xyflow/react"; +import type { Node, Edge, NodeMouseHandler } from "@xyflow/react"; +import "@xyflow/react/dist/style.css"; +import { useDashboardStore } from "../store"; +import { CustomNode } from "./CustomNode"; +import type { KnowledgeGraph } from "@understand-anything/core"; + +const nodeTypes = { custom: CustomNode }; + +function graphToReactFlow( + graph: KnowledgeGraph, + searchResults: string[], + selectedNodeId: string | null, +) { + const nodes: Node[] = graph.nodes.map((node, index) => ({ + id: node.id, + type: "custom", + position: { + x: (index % 5) * 280, + y: Math.floor(index / 5) * 160, + }, + data: { + label: node.name, + nodeType: node.type, + summary: node.summary, + complexity: node.complexity, + isHighlighted: searchResults.includes(node.id), + isSelected: node.id === selectedNodeId, + }, + })); + + const edges: Edge[] = graph.edges.map((edge, index) => ({ + id: `e-${index}`, + source: edge.source, + target: edge.target, + label: edge.type, + animated: edge.type === "calls", + style: { stroke: searchResults.length > 0 ? "#555" : "#888" }, + })); + + return { nodes, edges }; +} + +export function GraphView() { + const graph = useDashboardStore((s) => s.graph); + const searchResults = useDashboardStore((s) => s.searchResults); + const selectedNodeId = useDashboardStore((s) => s.selectedNodeId); + const selectNode = useDashboardStore((s) => s.selectNode); + + const { initialNodes, initialEdges } = useMemo(() => { + if (!graph) return { initialNodes: [], initialEdges: [] }; + const { nodes, edges } = graphToReactFlow( + graph, + searchResults, + selectedNodeId, + ); + return { initialNodes: nodes, initialEdges: edges }; + }, [graph, searchResults, selectedNodeId]); + + const [nodes, setNodes, onNodesChange] = useNodesState(initialNodes); + const [edges, setEdges, onEdgesChange] = useEdgesState(initialEdges); + + const onNodeClick: NodeMouseHandler = useCallback( + (_event, node) => { + selectNode(node.id); + }, + [selectNode], + ); + + if (!graph) { + return ( +
+ No knowledge graph loaded. Run /understand first. +
+ ); + } + + return ( + + + + + + ); +} +``` + +**Step 3: Commit** + +```bash +git add packages/dashboard/src/components/ +git commit -m "feat(dashboard): add graph view with React Flow and custom nodes" +``` + +--- + +## Task 8: Dashboard — Code Viewer Panel with Monaco Editor + +**Files:** +- Create: `packages/dashboard/src/components/CodeViewer.tsx` + +**Step 1: Create the CodeViewer component** + +Create: `packages/dashboard/src/components/CodeViewer.tsx` + +```tsx +import Editor from "@monaco-editor/react"; +import { useDashboardStore } from "../store"; + +const extToLanguage: Record = { + ts: "typescript", + tsx: "typescript", + js: "javascript", + jsx: "javascript", + py: "python", + go: "go", + rs: "rust", + java: "java", + json: "json", + md: "markdown", + css: "css", + html: "html", +}; + +function detectLanguage(filePath: string): string { + const ext = filePath.split(".").pop() || ""; + return extToLanguage[ext] || "plaintext"; +} + +export function CodeViewer() { + const graph = useDashboardStore((s) => s.graph); + const selectedNodeId = useDashboardStore((s) => s.selectedNodeId); + + const selectedNode = graph?.nodes.find((n) => n.id === selectedNodeId); + + if (!selectedNode || !selectedNode.filePath) { + return ( +
+ Select a node to view its source code. +
+ ); + } + + // In MVP, we show a placeholder message directing to file path + // Full implementation will load file content via API or embedded data + const placeholder = `// File: ${selectedNode.filePath} +// Lines: ${selectedNode.lineRange ? `${selectedNode.lineRange[0]}-${selectedNode.lineRange[1]}` : "all"} +// +// ${selectedNode.summary} +// +// To view the actual source code, the dashboard needs access to the project files. +// This will be connected in the next phase via a local API server.`; + + return ( +
+
+ + {selectedNode.type.toUpperCase()} + + {selectedNode.name} + + {selectedNode.filePath} + +
+
+ +
+
+ ); +} +``` + +**Step 2: Commit** + +```bash +git add packages/dashboard/src/components/CodeViewer.tsx +git commit -m "feat(dashboard): add code viewer panel with Monaco Editor" +``` + +--- + +## Task 9: Dashboard — Search Bar and Main Layout + +**Files:** +- Create: `packages/dashboard/src/components/SearchBar.tsx` +- Create: `packages/dashboard/src/components/NodeInfo.tsx` +- Modify: `packages/dashboard/src/App.tsx` + +**Step 1: Create SearchBar component** + +Create: `packages/dashboard/src/components/SearchBar.tsx` + +```tsx +import { useDashboardStore } from "../store"; + +export function SearchBar() { + const searchQuery = useDashboardStore((s) => s.searchQuery); + const searchResults = useDashboardStore((s) => s.searchResults); + const setSearchQuery = useDashboardStore((s) => s.setSearchQuery); + + return ( +
+ + + + setSearchQuery(e.target.value)} + placeholder='Search: "authentication", "api layer", "database"...' + className="flex-1 bg-transparent text-white placeholder-gray-500 outline-none text-sm" + /> + {searchQuery && ( + + {searchResults.length} results + + )} +
+ ); +} +``` + +**Step 2: Create NodeInfo panel (placeholder for chat + learn panels)** + +Create: `packages/dashboard/src/components/NodeInfo.tsx` + +```tsx +import { useDashboardStore } from "../store"; + +export function NodeInfo() { + const graph = useDashboardStore((s) => s.graph); + const selectedNodeId = useDashboardStore((s) => s.selectedNodeId); + + const selectedNode = graph?.nodes.find((n) => n.id === selectedNodeId); + + if (!selectedNode) { + return ( +
+ Select a node to see details. Chat and Learn panels coming in Phase 2. +
+ ); + } + + // Find connected nodes + const connectedEdges = graph?.edges.filter( + (e) => e.source === selectedNodeId || e.target === selectedNodeId, + ) || []; + + return ( +
+

+ {selectedNode.name} +

+
+ + {selectedNode.type} + + + {selectedNode.complexity} + +
+ +

{selectedNode.summary}

+ + {selectedNode.languageNotes && ( +
+
Language Note
+

{selectedNode.languageNotes}

+
+ )} + + {selectedNode.tags.length > 0 && ( +
+
Tags
+
+ {selectedNode.tags.map((tag) => ( + + {tag} + + ))} +
+
+ )} + + {connectedEdges.length > 0 && ( +
+
+ Connections ({connectedEdges.length}) +
+
+ {connectedEdges.map((edge, i) => { + const otherId = + edge.source === selectedNodeId ? edge.target : edge.source; + const otherNode = graph?.nodes.find((n) => n.id === otherId); + const direction = + edge.source === selectedNodeId ? "\u2192" : "\u2190"; + return ( +
+ {direction} {edge.type}: {otherNode?.name || otherId} +
+ ); + })} +
+
+ )} +
+ ); +} +``` + +**Step 3: Create the main App layout** + +Replace: `packages/dashboard/src/App.tsx` + +```tsx +import { useEffect } from "react"; +import { SearchBar } from "./components/SearchBar"; +import { GraphView } from "./components/GraphView"; +import { CodeViewer } from "./components/CodeViewer"; +import { NodeInfo } from "./components/NodeInfo"; +import { useDashboardStore } from "./store"; +import type { KnowledgeGraph } from "@understand-anything/core"; + +// Load graph from a JSON file served at /knowledge-graph.json +// In production, this comes from .understand-anything/knowledge-graph.json +async function loadGraphData(): Promise { + try { + const response = await fetch("/knowledge-graph.json"); + if (!response.ok) return null; + return (await response.json()) as KnowledgeGraph; + } catch { + return null; + } +} + +function App() { + const setGraph = useDashboardStore((s) => s.setGraph); + const graph = useDashboardStore((s) => s.graph); + + useEffect(() => { + loadGraphData().then((g) => { + if (g) setGraph(g); + }); + }, [setGraph]); + + return ( +
+ {/* Header */} +
+

+ UNDERSTAND ANYTHING +

+ {graph && ( + + {graph.project.name} · {graph.nodes.length} nodes ·{" "} + {graph.edges.length} edges + + )} +
+ + {/* Search */} + + + {/* Main workspace: 2x2 grid */} +
+ {/* Top-left: Graph View */} +
+ +
+ + {/* Top-right: Code Viewer */} +
+ +
+ + {/* Bottom-left: Chat Panel (placeholder) */} +
+ Chat panel — coming in Phase 2 +
+ + {/* Bottom-right: Node Info / Learn Panel */} +
+ +
+
+
+ ); +} + +export default App; +``` + +**Step 4: Run the dashboard** + +Run: `pnpm --filter @understand-anything/dashboard dev` +Expected: Vite dev server starts at localhost:5173. Dashboard renders with "No knowledge graph loaded" message. + +**Step 5: Test with sample data** + +Create `packages/dashboard/public/knowledge-graph.json` with a sample graph for testing: + +```json +{ + "version": "1.0.0", + "project": { + "name": "sample-project", + "languages": ["typescript"], + "frameworks": ["express"], + "description": "A sample Express API", + "analyzedAt": "2026-03-14T00:00:00.000Z", + "gitCommitHash": "abc123" + }, + "nodes": [ + { + "id": "file:src/index.ts", + "type": "file", + "name": "index.ts", + "filePath": "src/index.ts", + "summary": "Application entry point, starts the Express server", + "tags": ["entry", "server"], + "complexity": "simple" + }, + { + "id": "file:src/auth/login.ts", + "type": "file", + "name": "login.ts", + "filePath": "src/auth/login.ts", + "summary": "Handles user authentication and login flow", + "tags": ["auth", "login"], + "complexity": "moderate" + }, + { + "id": "func:src/auth/login.ts:handleLogin", + "type": "function", + "name": "handleLogin", + "filePath": "src/auth/login.ts", + "lineRange": [10, 35], + "summary": "Validates credentials and returns a JWT token", + "tags": ["auth", "jwt"], + "complexity": "moderate" + }, + { + "id": "func:src/auth/login.ts:validateEmail", + "type": "function", + "name": "validateEmail", + "filePath": "src/auth/login.ts", + "lineRange": [37, 42], + "summary": "Checks if an email address is valid using regex", + "tags": ["validation", "email"], + "complexity": "simple" + }, + { + "id": "file:src/db/connection.ts", + "type": "file", + "name": "connection.ts", + "filePath": "src/db/connection.ts", + "summary": "Database connection pool using PostgreSQL", + "tags": ["database", "postgres"], + "complexity": "moderate" + } + ], + "edges": [ + { + "source": "file:src/index.ts", + "target": "file:src/auth/login.ts", + "type": "imports", + "direction": "forward", + "weight": 0.7 + }, + { + "source": "file:src/auth/login.ts", + "target": "func:src/auth/login.ts:handleLogin", + "type": "contains", + "direction": "forward", + "weight": 1.0 + }, + { + "source": "file:src/auth/login.ts", + "target": "func:src/auth/login.ts:validateEmail", + "type": "contains", + "direction": "forward", + "weight": 1.0 + }, + { + "source": "func:src/auth/login.ts:handleLogin", + "target": "func:src/auth/login.ts:validateEmail", + "type": "calls", + "direction": "forward", + "description": "handleLogin calls validateEmail to check the email format", + "weight": 0.8 + }, + { + "source": "file:src/auth/login.ts", + "target": "file:src/db/connection.ts", + "type": "imports", + "direction": "forward", + "weight": 0.7 + } + ], + "layers": [], + "tour": [] +} +``` + +**Step 6: Verify in browser** + +Open: `http://localhost:5173` +Expected: Dashboard loads, graph renders 5 nodes with edges, clicking a node shows details in the info panel and placeholder in code viewer. Search works. + +**Step 7: Commit** + +```bash +git add packages/dashboard/ +git commit -m "feat(dashboard): add main layout with search bar, graph view, code viewer, and node info panels" +``` + +--- + +## Task 10: Integration — Wire Everything Together + README + +**Files:** +- Create: `README.md` +- Create: `CLAUDE.md` + +**Step 1: Create README.md** + +```markdown +# Understand Anything + +An open-source tool that combines LLM intelligence with static analysis to help anyone understand any codebase — from junior developers to product managers. + +## Features + +- **Knowledge Graph** — Automatically maps your codebase into an interactive graph of files, functions, classes, and their relationships +- **Multi-Panel Dashboard** — Graph view, code viewer, chat, and learn panels in a workspace layout +- **Natural Language Search** — Search your codebase with plain English: "which parts handle authentication?" +- **Tree-sitter Analysis** — Accurate structural analysis for TypeScript, JavaScript (more languages coming) +- **LLM-Powered Summaries** — Every node gets a plain-English description of what it does and why + +## Quick Start + +```bash +# Install dependencies +pnpm install + +# Build the core package +pnpm --filter @understand-anything/core build + +# Start the dashboard dev server +pnpm dev:dashboard +``` + +## Project Structure + +``` +packages/ + core/ — Analysis engine: types, persistence, tree-sitter, LLM prompts + dashboard/ — React + TypeScript web dashboard + skill/ — Claude Code skill (coming soon) +``` + +## Tech Stack + +- TypeScript, pnpm workspaces +- React 18, Vite, TailwindCSS +- React Flow (graph visualization) +- Monaco Editor (code viewer) +- Zustand (state management) +- tree-sitter (static analysis) + +## License + +MIT +``` + +**Step 2: Create CLAUDE.md** + +```markdown +# Understand Anything + +## Project Overview +An open-source tool combining LLM intelligence + static analysis to produce interactive dashboards for understanding codebases. + +## Architecture +- **Monorepo** with pnpm workspaces +- **packages/core** — Shared analysis engine (types, persistence, tree-sitter plugin, LLM prompt templates) +- **packages/dashboard** — React + TypeScript web dashboard (React Flow, Monaco Editor, Zustand, TailwindCSS) +- **packages/skill** — Claude Code skill (not yet implemented) + +## Key Commands +- `pnpm install` — Install all dependencies +- `pnpm --filter @understand-anything/core build` — Build the core package +- `pnpm --filter @understand-anything/core test` — Run core tests +- `pnpm dev:dashboard` — Start dashboard dev server + +## Conventions +- TypeScript strict mode everywhere +- Vitest for testing +- ESM modules (`"type": "module"`) +- Knowledge graph JSON lives in `.understand-anything/` directory of analyzed projects +``` + +**Step 3: Commit** + +```bash +git add README.md CLAUDE.md +git commit -m "docs: add README and CLAUDE.md with project overview and conventions" +``` + +--- + +## Verification Checklist + +After completing all 10 tasks: + +1. **`pnpm install`** — No errors +2. **`pnpm --filter @understand-anything/core build`** — Compiles clean +3. **`pnpm --filter @understand-anything/core test`** — All tests pass (types, persistence, tree-sitter, graph builder, LLM analyzer) +4. **`pnpm dev:dashboard`** — Dashboard starts at localhost:5173 +5. **Dashboard with sample data** — Loads `knowledge-graph.json`, graph renders, nodes clickable, search works, code viewer shows node info +6. **Git log** — Clean history with 10 logical commits diff --git a/Understand-Anything-main/docs/superpowers/plans/2026-03-14-phase2-implementation.md b/Understand-Anything-main/docs/superpowers/plans/2026-03-14-phase2-implementation.md new file mode 100644 index 0000000..5fd1aaf --- /dev/null +++ b/Understand-Anything-main/docs/superpowers/plans/2026-03-14-phase2-implementation.md @@ -0,0 +1,1847 @@ +# Understand Anything — Phase 2 (Intelligence) Implementation Plan + +> **For Claude:** REQUIRED SUB-SKILL: Use superpowers:executing-plans to implement this plan task-by-task. + +**Goal:** Add the "Intelligence" layer — enhanced search, staleness detection, layer auto-detection, `/understand-chat` skill command, and a dashboard chat panel with context-aware Q&A. + +**Architecture:** Extends the existing monorepo (packages/core, packages/dashboard) with a new packages/skill package. Core gets search engine, staleness detection, and layer detection. Dashboard gets auto-layout, enhanced search UX, and chat panel. Skill package provides the `/understand-chat` Claude Code command. + +**Tech Stack:** Existing stack + fuse.js (fuzzy search), zod (schema validation), @dagrejs/dagre (graph layout) + +--- + +## Task 1: Zod Schema Validation for Graph Loading + +**Files:** +- Create: `packages/core/src/schema.ts` +- Modify: `packages/core/src/persistence/index.ts` +- Modify: `packages/core/package.json` +- Create: `packages/core/src/__tests__/schema.test.ts` + +**Context:** Currently `loadGraph` does `JSON.parse()` with no validation. Corrupted or incompatible graph files silently produce broken data. Add zod schemas matching every type in `types.ts`, and validate on load. This is foundational — all Phase 2 features rely on correct graph data. + +**Step 1: Install zod** + +```bash +cd packages/core && pnpm add zod +``` + +**Step 2: Write failing tests** + +```typescript +// packages/core/src/__tests__/schema.test.ts +import { describe, it, expect } from 'vitest'; +import { KnowledgeGraphSchema, validateGraph } from '../schema.js'; + +describe('schema validation', () => { + it('validates a correct knowledge graph', () => { + const valid = { + version: '1.0.0', + project: { + name: 'test', + languages: ['typescript'], + frameworks: [], + description: 'A test project', + analyzedAt: '2026-03-14T00:00:00Z', + gitCommitHash: 'abc123', + }, + nodes: [{ + id: 'file:src/index.ts', + type: 'file', + name: 'index.ts', + filePath: 'src/index.ts', + summary: 'Main entry', + tags: ['entry'], + complexity: 'simple', + }], + edges: [{ + source: 'file:src/index.ts', + target: 'file:src/utils.ts', + type: 'imports', + direction: 'forward', + weight: 0.7, + }], + layers: [], + tour: [], + }; + const result = validateGraph(valid); + expect(result.success).toBe(true); + }); + + it('rejects graph with missing required fields', () => { + const invalid = { version: '1.0.0' }; // missing everything else + const result = validateGraph(invalid); + expect(result.success).toBe(false); + expect(result.errors).toBeDefined(); + expect(result.errors!.length).toBeGreaterThan(0); + }); + + it('rejects node with invalid type', () => { + const invalid = { + version: '1.0.0', + project: { + name: 'test', languages: [], frameworks: [], + description: '', analyzedAt: '', gitCommitHash: '', + }, + nodes: [{ + id: 'x', type: 'invalid_type', name: 'x', + summary: '', tags: [], complexity: 'simple', + }], + edges: [], layers: [], tour: [], + }; + const result = validateGraph(invalid); + expect(result.success).toBe(false); + }); + + it('rejects edge with invalid EdgeType', () => { + const invalid = { + version: '1.0.0', + project: { + name: 'test', languages: [], frameworks: [], + description: '', analyzedAt: '', gitCommitHash: '', + }, + nodes: [], + edges: [{ + source: 'a', target: 'b', type: 'fake_edge', + direction: 'forward', weight: 0.5, + }], + layers: [], tour: [], + }; + const result = validateGraph(invalid); + expect(result.success).toBe(false); + }); + + it('coerces weight out of range to clamped value', () => { + const graph = { + version: '1.0.0', + project: { + name: 'test', languages: [], frameworks: [], + description: '', analyzedAt: '', gitCommitHash: '', + }, + nodes: [], + edges: [{ + source: 'a', target: 'b', type: 'imports', + direction: 'forward', weight: 1.5, + }], + layers: [], tour: [], + }; + const result = validateGraph(graph); + // weight > 1 should fail validation + expect(result.success).toBe(false); + }); +}); +``` + +**Step 3: Run tests to verify they fail** + +```bash +pnpm --filter @understand-anything/core test +``` +Expected: FAIL — `schema.ts` does not exist yet. + +**Step 4: Implement schema.ts** + +```typescript +// packages/core/src/schema.ts +import { z } from 'zod'; + +const EdgeTypeSchema = z.enum([ + 'imports', 'exports', 'contains', 'inherits', 'implements', + 'calls', 'subscribes', 'publishes', 'middleware', + 'reads_from', 'writes_to', 'transforms', 'validates', + 'depends_on', 'tested_by', 'configures', + 'related', 'similar_to', +]); + +const GraphNodeSchema = z.object({ + id: z.string(), + type: z.enum(['file', 'function', 'class', 'module', 'concept']), + name: z.string(), + filePath: z.string().optional(), + lineRange: z.tuple([z.number(), z.number()]).optional(), + summary: z.string(), + tags: z.array(z.string()), + complexity: z.enum(['simple', 'moderate', 'complex']), + languageNotes: z.string().optional(), +}); + +const GraphEdgeSchema = z.object({ + source: z.string(), + target: z.string(), + type: EdgeTypeSchema, + direction: z.enum(['forward', 'backward', 'bidirectional']), + description: z.string().optional(), + weight: z.number().min(0).max(1), +}); + +const LayerSchema = z.object({ + id: z.string(), + name: z.string(), + description: z.string(), + nodeIds: z.array(z.string()), +}); + +const TourStepSchema = z.object({ + order: z.number(), + title: z.string(), + description: z.string(), + nodeIds: z.array(z.string()), + languageLesson: z.string().optional(), +}); + +const ProjectMetaSchema = z.object({ + name: z.string(), + languages: z.array(z.string()), + frameworks: z.array(z.string()), + description: z.string(), + analyzedAt: z.string(), + gitCommitHash: z.string(), +}); + +export const KnowledgeGraphSchema = z.object({ + version: z.string(), + project: ProjectMetaSchema, + nodes: z.array(GraphNodeSchema), + edges: z.array(GraphEdgeSchema), + layers: z.array(LayerSchema), + tour: z.array(TourStepSchema), +}); + +export interface ValidationResult { + success: boolean; + data?: z.infer; + errors?: string[]; +} + +export function validateGraph(data: unknown): ValidationResult { + const result = KnowledgeGraphSchema.safeParse(data); + if (result.success) { + return { success: true, data: result.data }; + } + return { + success: false, + errors: result.error.issues.map( + (i) => `${i.path.join('.')}: ${i.message}` + ), + }; +} +``` + +**Step 5: Wire validation into persistence loadGraph** + +Modify `packages/core/src/persistence/index.ts`: + +Add an optional `validate` parameter (default `true`) to `loadGraph`. When true, run `validateGraph` on the parsed JSON. If validation fails, throw an error with details. Keep backward compat by defaulting to validated. + +```typescript +import { validateGraph } from '../schema.js'; + +export function loadGraph( + baseDir: string, + options?: { validate?: boolean } +): KnowledgeGraph | null { + const graphPath = path.join(baseDir, '.understand-anything', 'knowledge-graph.json'); + if (!fs.existsSync(graphPath)) return null; + const data = JSON.parse(fs.readFileSync(graphPath, 'utf-8')); + if (options?.validate !== false) { + const result = validateGraph(data); + if (!result.success) { + throw new Error( + `Invalid knowledge graph: ${result.errors?.join('; ')}` + ); + } + return result.data as KnowledgeGraph; + } + return data as KnowledgeGraph; +} +``` + +**Step 6: Update barrel export** + +Add to `packages/core/src/index.ts`: +```typescript +export { KnowledgeGraphSchema, validateGraph, type ValidationResult } from './schema.js'; +``` + +**Step 7: Run tests to verify they pass** + +```bash +pnpm --filter @understand-anything/core test +``` +Expected: ALL PASS + +**Step 8: Commit** + +```bash +git add packages/core/src/schema.ts packages/core/src/__tests__/schema.test.ts packages/core/src/persistence/index.ts packages/core/src/index.ts packages/core/package.json pnpm-lock.yaml +git commit -m "feat(core): add zod schema validation for knowledge graph loading" +``` + +--- + +## Task 2: Enhanced Search Engine with Fuzzy Matching + +**Files:** +- Create: `packages/core/src/search.ts` +- Create: `packages/core/src/__tests__/search.test.ts` +- Modify: `packages/core/src/index.ts` +- Modify: `packages/core/package.json` + +**Context:** The current dashboard store has basic case-insensitive substring search across name/summary/tags. Phase 2 needs fuzzy matching and relevance scoring. We build a reusable `SearchEngine` in core (used by both dashboard and skill), powered by Fuse.js. The dashboard store will switch to using this engine in a later task. + +**Step 1: Install fuse.js** + +```bash +cd packages/core && pnpm add fuse.js +``` + +**Step 2: Write failing tests** + +```typescript +// packages/core/src/__tests__/search.test.ts +import { describe, it, expect } from 'vitest'; +import { SearchEngine } from '../search.js'; +import type { GraphNode } from '../types.js'; + +const makeNode = (overrides: Partial): GraphNode => ({ + id: 'test', + type: 'file', + name: 'test', + summary: '', + tags: [], + complexity: 'simple', + ...overrides, +}); + +describe('SearchEngine', () => { + it('returns empty results for empty query', () => { + const engine = new SearchEngine([makeNode({ id: 'a', name: 'foo' })]); + expect(engine.search('')).toEqual([]); + }); + + it('finds exact name match', () => { + const nodes = [ + makeNode({ id: 'a', name: 'AuthController' }), + makeNode({ id: 'b', name: 'UserService' }), + ]; + const engine = new SearchEngine(nodes); + const results = engine.search('AuthController'); + expect(results.length).toBe(1); + expect(results[0].nodeId).toBe('a'); + }); + + it('finds fuzzy name match', () => { + const nodes = [ + makeNode({ id: 'a', name: 'AuthenticationController' }), + makeNode({ id: 'b', name: 'DatabaseConnection' }), + ]; + const engine = new SearchEngine(nodes); + const results = engine.search('auth contrl'); + expect(results.some(r => r.nodeId === 'a')).toBe(true); + }); + + it('searches across summary field', () => { + const nodes = [ + makeNode({ id: 'a', name: 'handler.ts', summary: 'Handles WebSocket communication' }), + makeNode({ id: 'b', name: 'utils.ts', summary: 'General utilities' }), + ]; + const engine = new SearchEngine(nodes); + const results = engine.search('communication'); + expect(results[0].nodeId).toBe('a'); + }); + + it('searches across tags', () => { + const nodes = [ + makeNode({ id: 'a', name: 'x.ts', tags: ['authentication', 'security'] }), + makeNode({ id: 'b', name: 'y.ts', tags: ['database'] }), + ]; + const engine = new SearchEngine(nodes); + const results = engine.search('security'); + expect(results[0].nodeId).toBe('a'); + }); + + it('ranks name matches higher than summary matches', () => { + const nodes = [ + makeNode({ id: 'a', name: 'utils.ts', summary: 'Contains the auth function' }), + makeNode({ id: 'b', name: 'auth.ts', summary: 'Some utility functions' }), + ]; + const engine = new SearchEngine(nodes); + const results = engine.search('auth'); + expect(results[0].nodeId).toBe('b'); // name match ranks higher + }); + + it('returns scored results', () => { + const nodes = [makeNode({ id: 'a', name: 'foo' })]; + const engine = new SearchEngine(nodes); + const results = engine.search('foo'); + expect(results[0]).toHaveProperty('score'); + expect(typeof results[0].score).toBe('number'); + }); + + it('can update nodes and re-index', () => { + const engine = new SearchEngine([makeNode({ id: 'a', name: 'old' })]); + engine.updateNodes([makeNode({ id: 'b', name: 'new' })]); + const results = engine.search('new'); + expect(results[0].nodeId).toBe('b'); + expect(engine.search('old')).toEqual([]); + }); + + it('filters by node type', () => { + const nodes = [ + makeNode({ id: 'a', name: 'auth', type: 'file' }), + makeNode({ id: 'b', name: 'auth', type: 'function' }), + ]; + const engine = new SearchEngine(nodes); + const results = engine.search('auth', { types: ['function'] }); + expect(results.length).toBe(1); + expect(results[0].nodeId).toBe('b'); + }); +}); +``` + +**Step 3: Run tests to verify they fail** + +```bash +pnpm --filter @understand-anything/core test +``` +Expected: FAIL — `search.ts` does not exist. + +**Step 4: Implement SearchEngine** + +```typescript +// packages/core/src/search.ts +import Fuse from 'fuse.js'; +import type { GraphNode } from './types.js'; + +export interface SearchResult { + nodeId: string; + score: number; // 0 = perfect match, 1 = worst match +} + +export interface SearchOptions { + types?: GraphNode['type'][]; + limit?: number; +} + +export class SearchEngine { + private fuse: Fuse; + private nodes: GraphNode[]; + + constructor(nodes: GraphNode[]) { + this.nodes = nodes; + this.fuse = this.createIndex(nodes); + } + + private createIndex(nodes: GraphNode[]): Fuse { + return new Fuse(nodes, { + keys: [ + { name: 'name', weight: 0.4 }, + { name: 'tags', weight: 0.3 }, + { name: 'summary', weight: 0.2 }, + { name: 'languageNotes', weight: 0.1 }, + ], + threshold: 0.4, + includeScore: true, + ignoreLocation: true, + }); + } + + search(query: string, options?: SearchOptions): SearchResult[] { + if (!query.trim()) return []; + + let results = this.fuse.search(query); + + if (options?.types?.length) { + results = results.filter((r) => options.types!.includes(r.item.type)); + } + + const limit = options?.limit ?? 50; + + return results.slice(0, limit).map((r) => ({ + nodeId: r.item.id, + score: r.score ?? 1, + })); + } + + updateNodes(nodes: GraphNode[]): void { + this.nodes = nodes; + this.fuse = this.createIndex(nodes); + } +} +``` + +**Step 5: Update barrel export** + +Add to `packages/core/src/index.ts`: +```typescript +export { SearchEngine, type SearchResult, type SearchOptions } from './search.js'; +``` + +**Step 6: Run tests to verify they pass** + +```bash +pnpm --filter @understand-anything/core test +``` +Expected: ALL PASS + +**Step 7: Commit** + +```bash +git add packages/core/src/search.ts packages/core/src/__tests__/search.test.ts packages/core/src/index.ts packages/core/package.json pnpm-lock.yaml +git commit -m "feat(core): add fuzzy search engine with Fuse.js" +``` + +--- + +## Task 3: Dagre Auto-Layout for Graph View + +**Files:** +- Create: `packages/dashboard/src/utils/layout.ts` +- Modify: `packages/dashboard/src/components/GraphView.tsx` +- Modify: `packages/dashboard/package.json` + +**Context:** Currently GraphView positions nodes in a simple `(index % 3) * 300` grid. This produces chaotic graphs for real projects. Add dagre (hierarchical graph layout) to compute positions respecting edge direction. Nodes flow top-to-bottom, with edges determining hierarchy. + +**Step 1: Install dagre** + +```bash +cd packages/dashboard && pnpm add @dagrejs/dagre +``` + +**Step 2: Create layout utility** + +```typescript +// packages/dashboard/src/utils/layout.ts +import dagre from '@dagrejs/dagre'; +import type { Node, Edge } from '@xyflow/react'; + +const NODE_WIDTH = 280; +const NODE_HEIGHT = 120; + +export function applyDagreLayout( + nodes: Node[], + edges: Edge[], + direction: 'TB' | 'LR' = 'TB' +): { nodes: Node[]; edges: Edge[] } { + const g = new dagre.graphlib.Graph(); + g.setDefaultEdgeLabel(() => ({})); + g.setGraph({ + rankdir: direction, + nodesep: 60, + ranksep: 80, + marginx: 20, + marginy: 20, + }); + + nodes.forEach((node) => { + g.setNode(node.id, { width: NODE_WIDTH, height: NODE_HEIGHT }); + }); + + edges.forEach((edge) => { + g.setEdge(edge.source, edge.target); + }); + + dagre.layout(g); + + const layoutedNodes = nodes.map((node) => { + const pos = g.node(node.id); + return { + ...node, + position: { + x: pos.x - NODE_WIDTH / 2, + y: pos.y - NODE_HEIGHT / 2, + }, + }; + }); + + return { nodes: layoutedNodes, edges }; +} +``` + +**Step 3: Update GraphView to use dagre layout** + +Replace the `(index % 3) * 300` grid positioning in `GraphView.tsx` with a call to `applyDagreLayout`. The key changes: + +1. Import `applyDagreLayout` from `../utils/layout.js` +2. Build flow nodes/edges from graph data (without position) +3. Pass through `applyDagreLayout` to get positioned nodes +4. Use `useMemo` to recompute layout only when graph/search changes + +The component should keep all existing functionality (custom nodes, search highlighting, selection, controls, minimap). + +**Step 4: Verify manually** + +```bash +pnpm dev:dashboard +``` +Open http://localhost:5173 — graph should display nodes in a hierarchical layout following edge direction, not in a flat grid. + +**Step 5: Commit** + +```bash +git add packages/dashboard/src/utils/layout.ts packages/dashboard/src/components/GraphView.tsx packages/dashboard/package.json pnpm-lock.yaml +git commit -m "feat(dashboard): add dagre auto-layout for hierarchical graph visualization" +``` + +--- + +## Task 4: Staleness Detection + Incremental Updates + +**Files:** +- Create: `packages/core/src/staleness.ts` +- Create: `packages/core/src/__tests__/staleness.test.ts` +- Modify: `packages/core/src/index.ts` + +**Context:** The design doc specifies an auto-sync flow: read `meta.json` → git diff against last hash → re-analyze only changed files → merge into existing graph. This task builds the staleness detection and graph merging logic. It does NOT invoke LLM or tree-sitter (that's orchestration, done by the skill). It provides the building blocks: detect changed files, merge updated nodes/edges into an existing graph. + +**Step 1: Write failing tests** + +```typescript +// packages/core/src/__tests__/staleness.test.ts +import { describe, it, expect, vi, beforeEach } from 'vitest'; +import { + getChangedFiles, + isStale, + mergeGraphUpdate, +} from '../staleness.js'; +import type { KnowledgeGraph, GraphNode, GraphEdge } from '../types.js'; + +// Mock child_process.execSync for git commands +vi.mock('child_process', () => ({ + execSync: vi.fn(), +})); + +import { execSync } from 'child_process'; +const mockExecSync = vi.mocked(execSync); + +describe('staleness detection', () => { + beforeEach(() => { + vi.resetAllMocks(); + }); + + describe('getChangedFiles', () => { + it('returns changed file list from git diff', () => { + mockExecSync.mockReturnValue(Buffer.from('src/a.ts\nsrc/b.ts\n')); + const files = getChangedFiles('/project', 'abc123'); + expect(files).toEqual(['src/a.ts', 'src/b.ts']); + expect(mockExecSync).toHaveBeenCalledWith( + 'git diff abc123..HEAD --name-only', + expect.objectContaining({ cwd: '/project' }) + ); + }); + + it('returns empty array when no changes', () => { + mockExecSync.mockReturnValue(Buffer.from('')); + const files = getChangedFiles('/project', 'abc123'); + expect(files).toEqual([]); + }); + + it('returns empty array on git error', () => { + mockExecSync.mockImplementation(() => { throw new Error('git error'); }); + const files = getChangedFiles('/project', 'abc123'); + expect(files).toEqual([]); + }); + }); + + describe('isStale', () => { + it('returns stale when files have changed', () => { + mockExecSync.mockReturnValue(Buffer.from('src/a.ts\n')); + const result = isStale('/project', 'abc123'); + expect(result.stale).toBe(true); + expect(result.changedFiles).toEqual(['src/a.ts']); + }); + + it('returns not stale when no files changed', () => { + mockExecSync.mockReturnValue(Buffer.from('')); + const result = isStale('/project', 'abc123'); + expect(result.stale).toBe(false); + expect(result.changedFiles).toEqual([]); + }); + }); + + describe('mergeGraphUpdate', () => { + const baseGraph: KnowledgeGraph = { + version: '1.0.0', + project: { + name: 'test', + languages: ['typescript'], + frameworks: [], + description: '', + analyzedAt: '2026-01-01T00:00:00Z', + gitCommitHash: 'old', + }, + nodes: [ + { id: 'file:src/a.ts', type: 'file', name: 'a.ts', filePath: 'src/a.ts', summary: 'old', tags: [], complexity: 'simple' }, + { id: 'file:src/b.ts', type: 'file', name: 'b.ts', filePath: 'src/b.ts', summary: 'unchanged', tags: [], complexity: 'simple' }, + { id: 'func:src/a.ts:foo', type: 'function', name: 'foo', filePath: 'src/a.ts', summary: 'old foo', tags: [], complexity: 'simple' }, + ], + edges: [ + { source: 'file:src/a.ts', target: 'file:src/b.ts', type: 'imports', direction: 'forward', weight: 0.7 }, + { source: 'file:src/a.ts', target: 'func:src/a.ts:foo', type: 'contains', direction: 'forward', weight: 1.0 }, + ], + layers: [], + tour: [], + }; + + it('replaces nodes for changed files', () => { + const newNodes: GraphNode[] = [ + { id: 'file:src/a.ts', type: 'file', name: 'a.ts', filePath: 'src/a.ts', summary: 'updated', tags: ['new'], complexity: 'moderate' }, + { id: 'func:src/a.ts:bar', type: 'function', name: 'bar', filePath: 'src/a.ts', summary: 'new func', tags: [], complexity: 'simple' }, + ]; + const newEdges: GraphEdge[] = [ + { source: 'file:src/a.ts', target: 'func:src/a.ts:bar', type: 'contains', direction: 'forward', weight: 1.0 }, + ]; + + const merged = mergeGraphUpdate(baseGraph, ['src/a.ts'], newNodes, newEdges, 'newHash'); + + // Old a.ts nodes removed, new ones added + expect(merged.nodes.find(n => n.id === 'func:src/a.ts:foo')).toBeUndefined(); + expect(merged.nodes.find(n => n.id === 'func:src/a.ts:bar')).toBeDefined(); + expect(merged.nodes.find(n => n.id === 'file:src/a.ts')?.summary).toBe('updated'); + + // b.ts unchanged + expect(merged.nodes.find(n => n.id === 'file:src/b.ts')?.summary).toBe('unchanged'); + + // Git hash updated + expect(merged.project.gitCommitHash).toBe('newHash'); + }); + + it('removes edges originating from changed files', () => { + const newNodes: GraphNode[] = [ + { id: 'file:src/a.ts', type: 'file', name: 'a.ts', filePath: 'src/a.ts', summary: 'updated', tags: [], complexity: 'simple' }, + ]; + const newEdges: GraphEdge[] = [ + { source: 'file:src/a.ts', target: 'file:src/b.ts', type: 'imports', direction: 'forward', weight: 0.9 }, + ]; + + const merged = mergeGraphUpdate(baseGraph, ['src/a.ts'], newNodes, newEdges, 'newHash'); + + // Old contains edge removed, new imports edge present with new weight + const importEdge = merged.edges.find(e => e.source === 'file:src/a.ts' && e.target === 'file:src/b.ts'); + expect(importEdge?.weight).toBe(0.9); + expect(merged.edges.find(e => e.type === 'contains')).toBeUndefined(); + }); + + it('updates analyzedAt timestamp', () => { + const merged = mergeGraphUpdate(baseGraph, ['src/a.ts'], [], [], 'newHash'); + expect(merged.project.analyzedAt).not.toBe('2026-01-01T00:00:00Z'); + }); + }); +}); +``` + +**Step 3: Run tests to verify they fail** + +```bash +pnpm --filter @understand-anything/core test +``` +Expected: FAIL — `staleness.ts` does not exist. + +**Step 4: Implement staleness.ts** + +```typescript +// packages/core/src/staleness.ts +import { execSync } from 'child_process'; +import type { KnowledgeGraph, GraphNode, GraphEdge } from './types.js'; + +export interface StalenessResult { + stale: boolean; + changedFiles: string[]; +} + +export function getChangedFiles(projectDir: string, lastCommitHash: string): string[] { + try { + const output = execSync(`git diff ${lastCommitHash}..HEAD --name-only`, { + cwd: projectDir, + encoding: 'utf-8', + }); + return output.trim().split('\n').filter(Boolean); + } catch { + return []; + } +} + +export function isStale(projectDir: string, lastCommitHash: string): StalenessResult { + const changedFiles = getChangedFiles(projectDir, lastCommitHash); + return { + stale: changedFiles.length > 0, + changedFiles, + }; +} + +export function mergeGraphUpdate( + existingGraph: KnowledgeGraph, + changedFilePaths: string[], + newNodes: GraphNode[], + newEdges: GraphEdge[], + newCommitHash: string, +): KnowledgeGraph { + const changedSet = new Set(changedFilePaths); + + // Remove old nodes belonging to changed files + const keptNodes = existingGraph.nodes.filter( + (node) => !node.filePath || !changedSet.has(node.filePath) + ); + + // Remove old edges where source node belongs to a changed file + const changedNodeIds = new Set( + existingGraph.nodes + .filter((n) => n.filePath && changedSet.has(n.filePath)) + .map((n) => n.id) + ); + const keptEdges = existingGraph.edges.filter( + (edge) => !changedNodeIds.has(edge.source) + ); + + return { + ...existingGraph, + project: { + ...existingGraph.project, + gitCommitHash: newCommitHash, + analyzedAt: new Date().toISOString(), + }, + nodes: [...keptNodes, ...newNodes], + edges: [...keptEdges, ...newEdges], + }; +} +``` + +**Step 5: Update barrel export** + +Add to `packages/core/src/index.ts`: +```typescript +export { + getChangedFiles, + isStale, + mergeGraphUpdate, + type StalenessResult, +} from './staleness.js'; +``` + +**Step 6: Run tests to verify they pass** + +```bash +pnpm --filter @understand-anything/core test +``` +Expected: ALL PASS + +**Step 7: Commit** + +```bash +git add packages/core/src/staleness.ts packages/core/src/__tests__/staleness.test.ts packages/core/src/index.ts +git commit -m "feat(core): add staleness detection and incremental graph merging" +``` + +--- + +## Task 5: Layer Auto-Detection + +**Files:** +- Create: `packages/core/src/analyzer/layer-detector.ts` +- Create: `packages/core/src/__tests__/layer-detector.test.ts` +- Modify: `packages/core/src/index.ts` + +**Context:** Layer detection groups nodes into logical layers (e.g., "API Layer", "Data Layer", "UI Layer") based on file paths, naming patterns, and edge structure. This uses a heuristic approach: analyze file paths for common patterns (routes/, controllers/, models/, services/, etc.) and node connectivity. An LLM prompt builder is provided for enhanced detection when LLM is available, but the heuristic works standalone. Layers populate the `layers[]` field in the KnowledgeGraph. + +**Step 1: Write failing tests** + +```typescript +// packages/core/src/__tests__/layer-detector.test.ts +import { describe, it, expect } from 'vitest'; +import { detectLayers, buildLayerDetectionPrompt, parseLayerDetectionResponse } from '../analyzer/layer-detector.js'; +import type { KnowledgeGraph } from '../types.js'; + +const makeGraph = (nodes: Array<{ id: string; filePath: string; name: string }>): KnowledgeGraph => ({ + version: '1.0.0', + project: { + name: 'test', languages: ['typescript'], frameworks: [], + description: '', analyzedAt: '', gitCommitHash: '', + }, + nodes: nodes.map((n) => ({ + ...n, + type: 'file' as const, + summary: '', + tags: [], + complexity: 'simple' as const, + })), + edges: [], + layers: [], + tour: [], +}); + +describe('layer detection (heuristic)', () => { + it('detects API/routes layer', () => { + const graph = makeGraph([ + { id: 'file:src/routes/users.ts', filePath: 'src/routes/users.ts', name: 'users.ts' }, + { id: 'file:src/routes/auth.ts', filePath: 'src/routes/auth.ts', name: 'auth.ts' }, + { id: 'file:src/models/user.ts', filePath: 'src/models/user.ts', name: 'user.ts' }, + ]); + const layers = detectLayers(graph); + const apiLayer = layers.find((l) => l.name.toLowerCase().includes('api') || l.name.toLowerCase().includes('route')); + expect(apiLayer).toBeDefined(); + expect(apiLayer!.nodeIds).toContain('file:src/routes/users.ts'); + }); + + it('detects data/model layer', () => { + const graph = makeGraph([ + { id: 'file:src/models/user.ts', filePath: 'src/models/user.ts', name: 'user.ts' }, + { id: 'file:src/models/post.ts', filePath: 'src/models/post.ts', name: 'post.ts' }, + { id: 'file:src/index.ts', filePath: 'src/index.ts', name: 'index.ts' }, + ]); + const layers = detectLayers(graph); + const dataLayer = layers.find((l) => l.name.toLowerCase().includes('data') || l.name.toLowerCase().includes('model')); + expect(dataLayer).toBeDefined(); + expect(dataLayer!.nodeIds).toContain('file:src/models/user.ts'); + }); + + it('puts unmatched files in a general layer', () => { + const graph = makeGraph([ + { id: 'file:src/foo.ts', filePath: 'src/foo.ts', name: 'foo.ts' }, + ]); + const layers = detectLayers(graph); + expect(layers.length).toBeGreaterThan(0); + expect(layers.some((l) => l.nodeIds.includes('file:src/foo.ts'))).toBe(true); + }); + + it('assigns unique IDs to layers', () => { + const graph = makeGraph([ + { id: 'file:src/routes/a.ts', filePath: 'src/routes/a.ts', name: 'a.ts' }, + { id: 'file:src/models/b.ts', filePath: 'src/models/b.ts', name: 'b.ts' }, + ]); + const layers = detectLayers(graph); + const ids = layers.map((l) => l.id); + expect(new Set(ids).size).toBe(ids.length); + }); + + it('only assigns file nodes to layers', () => { + const graph: KnowledgeGraph = { + ...makeGraph([{ id: 'file:src/routes/a.ts', filePath: 'src/routes/a.ts', name: 'a.ts' }]), + nodes: [ + { id: 'file:src/routes/a.ts', type: 'file', filePath: 'src/routes/a.ts', name: 'a.ts', summary: '', tags: [], complexity: 'simple' }, + { id: 'func:src/routes/a.ts:handler', type: 'function', filePath: 'src/routes/a.ts', name: 'handler', summary: '', tags: [], complexity: 'simple' }, + ], + }; + const layers = detectLayers(graph); + const allNodeIds = layers.flatMap((l) => l.nodeIds); + expect(allNodeIds).not.toContain('func:src/routes/a.ts:handler'); + }); +}); + +describe('LLM layer detection prompt', () => { + it('builds a prompt containing file paths', () => { + const graph = makeGraph([ + { id: 'file:src/routes/a.ts', filePath: 'src/routes/a.ts', name: 'a.ts' }, + ]); + const prompt = buildLayerDetectionPrompt(graph); + expect(prompt).toContain('src/routes/a.ts'); + expect(prompt).toContain('JSON'); + }); + + it('parses a valid LLM response', () => { + const response = JSON.stringify({ + layers: [ + { name: 'API Layer', description: 'HTTP routes', filePatterns: ['src/routes/'] }, + { name: 'Data Layer', description: 'Models', filePatterns: ['src/models/'] }, + ], + }); + const result = parseLayerDetectionResponse(response); + expect(result).not.toBeNull(); + expect(result!.length).toBe(2); + expect(result![0].name).toBe('API Layer'); + }); + + it('returns null for invalid response', () => { + expect(parseLayerDetectionResponse('not json')).toBeNull(); + }); +}); +``` + +**Step 3: Run tests to verify they fail** + +```bash +pnpm --filter @understand-anything/core test +``` +Expected: FAIL — `layer-detector.ts` does not exist. + +**Step 4: Implement layer-detector.ts** + +```typescript +// packages/core/src/analyzer/layer-detector.ts +import type { KnowledgeGraph, Layer } from '../types.js'; + +// Heuristic layer patterns: directory path substring → layer info +const LAYER_PATTERNS: Array<{ patterns: string[]; name: string; description: string }> = [ + { + patterns: ['route', 'controller', 'handler', 'endpoint', 'api/'], + name: 'API Layer', + description: 'HTTP routes, controllers, and API endpoint handlers', + }, + { + patterns: ['service', 'usecase', 'use-case', 'business'], + name: 'Service Layer', + description: 'Business logic and service orchestration', + }, + { + patterns: ['model', 'entity', 'schema', 'database', 'db/', 'migration', 'repository', 'repo'], + name: 'Data Layer', + description: 'Data models, database schemas, and persistence', + }, + { + patterns: ['component', 'view', 'page', 'screen', 'layout', 'widget', 'ui/'], + name: 'UI Layer', + description: 'User interface components and views', + }, + { + patterns: ['middleware', 'interceptor', 'guard', 'filter', 'pipe'], + name: 'Middleware Layer', + description: 'Request processing middleware and interceptors', + }, + { + patterns: ['util', 'helper', 'lib/', 'common/', 'shared/'], + name: 'Utility Layer', + description: 'Shared utilities, helpers, and common code', + }, + { + patterns: ['test', 'spec', '__test__', '__spec__'], + name: 'Test Layer', + description: 'Tests and test utilities', + }, + { + patterns: ['config', 'setting', 'env'], + name: 'Configuration Layer', + description: 'Application configuration and environment settings', + }, +]; + +export function detectLayers(graph: KnowledgeGraph): Layer[] { + const fileNodes = graph.nodes.filter((n) => n.type === 'file' && n.filePath); + + const layerMap = new Map(); + const assignedNodes = new Set(); + + // Match file paths against patterns + for (const node of fileNodes) { + const fp = node.filePath!.toLowerCase(); + for (const layerDef of LAYER_PATTERNS) { + if (layerDef.patterns.some((p) => fp.includes(p))) { + if (!layerMap.has(layerDef.name)) { + layerMap.set(layerDef.name, { + name: layerDef.name, + description: layerDef.description, + nodeIds: [], + }); + } + layerMap.get(layerDef.name)!.nodeIds.push(node.id); + assignedNodes.add(node.id); + break; // First matching pattern wins + } + } + } + + // Unassigned files go to "Core" layer + const unassigned = fileNodes.filter((n) => !assignedNodes.has(n.id)); + if (unassigned.length > 0) { + layerMap.set('Core', { + name: 'Core', + description: 'Core application files and entry points', + nodeIds: unassigned.map((n) => n.id), + }); + } + + // Convert to Layer[] with unique IDs + return Array.from(layerMap.values()).map((entry, i) => ({ + id: `layer:${entry.name.toLowerCase().replace(/\s+/g, '-')}`, + name: entry.name, + description: entry.description, + nodeIds: entry.nodeIds, + })); +} + +// --- LLM-enhanced layer detection --- + +export function buildLayerDetectionPrompt(graph: KnowledgeGraph): string { + const filePaths = graph.nodes + .filter((n) => n.type === 'file' && n.filePath) + .map((n) => n.filePath!); + + return `Analyze this project's file structure and identify logical architectural layers. + +File paths: +${filePaths.map((f) => `- ${f}`).join('\n')} + +Respond with JSON only: +{ + "layers": [ + { + "name": "Layer Name", + "description": "What this layer does", + "filePatterns": ["path/prefix/"] + } + ] +} + +Rules: +- Identify 3-7 logical layers +- Each layer should have a clear architectural purpose +- filePatterns are path prefixes that match files in that layer +- Common layers: API, Service/Business Logic, Data/Models, UI, Middleware, Utility, Configuration, Tests`; +} + +interface LLMLayerResponse { + name: string; + description: string; + filePatterns: string[]; +} + +export function parseLayerDetectionResponse(response: string): LLMLayerResponse[] | null { + try { + // Handle markdown fences + let cleaned = response.trim(); + if (cleaned.startsWith('```')) { + cleaned = cleaned.replace(/^```\w*\n?/, '').replace(/\n?```$/, ''); + } + const parsed = JSON.parse(cleaned); + if (!parsed.layers || !Array.isArray(parsed.layers)) return null; + return parsed.layers.map((l: Record) => ({ + name: String(l.name || ''), + description: String(l.description || ''), + filePatterns: Array.isArray(l.filePatterns) ? l.filePatterns.map(String) : [], + })); + } catch { + return null; + } +} + +/** + * Convert LLM layer response into Layer[] by matching file patterns against graph nodes. + */ +export function applyLLMLayers( + graph: KnowledgeGraph, + llmLayers: LLMLayerResponse[], +): Layer[] { + const fileNodes = graph.nodes.filter((n) => n.type === 'file' && n.filePath); + const assignedNodes = new Set(); + + const layers: Layer[] = llmLayers.map((ll) => { + const matching = fileNodes.filter((n) => { + if (assignedNodes.has(n.id)) return false; + return ll.filePatterns.some((p) => n.filePath!.includes(p)); + }); + matching.forEach((n) => assignedNodes.add(n.id)); + return { + id: `layer:${ll.name.toLowerCase().replace(/\s+/g, '-')}`, + name: ll.name, + description: ll.description, + nodeIds: matching.map((n) => n.id), + }; + }); + + // Unassigned files + const unassigned = fileNodes.filter((n) => !assignedNodes.has(n.id)); + if (unassigned.length > 0) { + layers.push({ + id: 'layer:other', + name: 'Other', + description: 'Files not matching any detected layer', + nodeIds: unassigned.map((n) => n.id), + }); + } + + return layers.filter((l) => l.nodeIds.length > 0); +} +``` + +**Step 5: Update barrel export** + +Add to `packages/core/src/index.ts`: +```typescript +export { + detectLayers, + buildLayerDetectionPrompt, + parseLayerDetectionResponse, + applyLLMLayers, +} from './analyzer/layer-detector.js'; +``` + +**Step 6: Run tests to verify they pass** + +```bash +pnpm --filter @understand-anything/core test +``` +Expected: ALL PASS + +**Step 7: Commit** + +```bash +git add packages/core/src/analyzer/layer-detector.ts packages/core/src/__tests__/layer-detector.test.ts packages/core/src/index.ts +git commit -m "feat(core): add heuristic and LLM-based layer auto-detection" +``` + +--- + +## Task 6: Skill Package Scaffolding + `/understand-chat` Command + +**Files:** +- Create: `packages/skill/package.json` +- Create: `packages/skill/tsconfig.json` +- Create: `packages/skill/src/understand-chat.ts` +- Create: `packages/skill/src/context-builder.ts` +- Create: `packages/skill/src/__tests__/context-builder.test.ts` +- Create: `packages/skill/.claude/skills/understand-chat.md` (the skill definition file) + +**Context:** This is the first Claude Code skill command. `/understand-chat` provides in-terminal Q&A using the knowledge graph. As a Claude Code skill, it needs: (1) a skill markdown file that Claude loads, (2) a context-builder that extracts relevant graph context for a user query, (3) the prompt template that combines context + query. The skill reads the persisted `.understand-anything/knowledge-graph.json` and uses the active Claude session for LLM — no separate API call needed. + +**Step 1: Create skill package.json** + +```json +{ + "name": "@understand-anything/skill", + "version": "0.1.0", + "type": "module", + "main": "dist/index.js", + "types": "dist/index.d.ts", + "scripts": { + "build": "tsc", + "test": "vitest run" + }, + "dependencies": { + "@understand-anything/core": "workspace:*" + }, + "devDependencies": { + "@types/node": "^22.0.0", + "typescript": "^5.7.0", + "vitest": "^3.1.0" + } +} +``` + +**Step 2: Create skill tsconfig.json** + +```json +{ + "extends": "../../tsconfig.json", + "compilerOptions": { + "outDir": "dist", + "rootDir": "src" + }, + "include": ["src"] +} +``` + +**Step 3: Write failing tests for context-builder** + +```typescript +// packages/skill/src/__tests__/context-builder.test.ts +import { describe, it, expect } from 'vitest'; +import { buildChatContext, formatContextForPrompt } from '../context-builder.js'; +import type { KnowledgeGraph } from '@understand-anything/core'; + +const sampleGraph: KnowledgeGraph = { + version: '1.0.0', + project: { + name: 'test-project', + languages: ['typescript'], + frameworks: ['express'], + description: 'A sample web API', + analyzedAt: '2026-03-14T00:00:00Z', + gitCommitHash: 'abc123', + }, + nodes: [ + { id: 'file:src/auth/login.ts', type: 'file', name: 'login.ts', filePath: 'src/auth/login.ts', summary: 'Handles user authentication and login flow', tags: ['auth', 'login', 'security'], complexity: 'moderate' }, + { id: 'func:src/auth/login.ts:authenticate', type: 'function', name: 'authenticate', filePath: 'src/auth/login.ts', summary: 'Validates credentials and returns JWT', tags: ['auth', 'jwt'], complexity: 'complex' }, + { id: 'file:src/routes/api.ts', type: 'file', name: 'api.ts', filePath: 'src/routes/api.ts', summary: 'Express API route definitions', tags: ['routes', 'api', 'express'], complexity: 'simple' }, + { id: 'file:src/db/connection.ts', type: 'file', name: 'connection.ts', filePath: 'src/db/connection.ts', summary: 'Database connection pooling', tags: ['database', 'connection'], complexity: 'moderate' }, + ], + edges: [ + { source: 'file:src/routes/api.ts', target: 'file:src/auth/login.ts', type: 'imports', direction: 'forward', weight: 0.7 }, + { source: 'func:src/auth/login.ts:authenticate', target: 'file:src/db/connection.ts', type: 'reads_from', direction: 'forward', weight: 0.6 }, + ], + layers: [ + { id: 'layer:api', name: 'API Layer', description: 'HTTP routes', nodeIds: ['file:src/routes/api.ts'] }, + { id: 'layer:auth', name: 'Auth Layer', description: 'Authentication', nodeIds: ['file:src/auth/login.ts', 'func:src/auth/login.ts:authenticate'] }, + ], + tour: [], +}; + +describe('buildChatContext', () => { + it('finds relevant nodes for a query', () => { + const context = buildChatContext(sampleGraph, 'how does authentication work?'); + expect(context.relevantNodes.some((n) => n.id.includes('auth'))).toBe(true); + }); + + it('includes connected nodes', () => { + const context = buildChatContext(sampleGraph, 'authentication'); + const nodeIds = context.relevantNodes.map((n) => n.id); + // Should include auth nodes AND their connections (db/connection, routes/api) + expect(nodeIds.length).toBeGreaterThan(1); + }); + + it('includes project metadata', () => { + const context = buildChatContext(sampleGraph, 'anything'); + expect(context.projectName).toBe('test-project'); + expect(context.projectDescription).toBe('A sample web API'); + }); + + it('includes relevant layers', () => { + const context = buildChatContext(sampleGraph, 'authentication'); + expect(context.relevantLayers.length).toBeGreaterThan(0); + }); +}); + +describe('formatContextForPrompt', () => { + it('produces a string containing node summaries', () => { + const context = buildChatContext(sampleGraph, 'authentication'); + const formatted = formatContextForPrompt(context); + expect(formatted).toContain('login.ts'); + expect(formatted).toContain('authentication'); + }); + + it('includes edge descriptions', () => { + const context = buildChatContext(sampleGraph, 'authentication'); + const formatted = formatContextForPrompt(context); + expect(formatted).toContain('imports'); + }); +}); +``` + +**Step 4: Run tests to verify they fail** + +```bash +pnpm install && pnpm --filter @understand-anything/skill test +``` +Expected: FAIL — files don't exist yet. + +**Step 5: Implement context-builder.ts** + +```typescript +// packages/skill/src/context-builder.ts +import { SearchEngine } from '@understand-anything/core'; +import type { KnowledgeGraph, GraphNode, GraphEdge, Layer } from '@understand-anything/core'; + +export interface ChatContext { + projectName: string; + projectDescription: string; + languages: string[]; + frameworks: string[]; + relevantNodes: GraphNode[]; + relevantEdges: GraphEdge[]; + relevantLayers: Layer[]; + query: string; +} + +export function buildChatContext( + graph: KnowledgeGraph, + query: string, + maxNodes: number = 15, +): ChatContext { + const searchEngine = new SearchEngine(graph.nodes); + const searchResults = searchEngine.search(query, { limit: maxNodes }); + + // Collect directly matching nodes + const relevantNodeIds = new Set(searchResults.map((r) => r.nodeId)); + + // Expand to connected nodes (1 hop) + for (const edge of graph.edges) { + if (relevantNodeIds.has(edge.source)) relevantNodeIds.add(edge.target); + if (relevantNodeIds.has(edge.target)) relevantNodeIds.add(edge.source); + } + + const relevantNodes = graph.nodes.filter((n) => relevantNodeIds.has(n.id)); + const relevantEdges = graph.edges.filter( + (e) => relevantNodeIds.has(e.source) && relevantNodeIds.has(e.target) + ); + + // Find layers that contain any relevant nodes + const relevantLayers = graph.layers.filter((l) => + l.nodeIds.some((id) => relevantNodeIds.has(id)) + ); + + return { + projectName: graph.project.name, + projectDescription: graph.project.description, + languages: graph.project.languages, + frameworks: graph.project.frameworks, + relevantNodes, + relevantEdges, + relevantLayers, + query, + }; +} + +export function formatContextForPrompt(context: ChatContext): string { + const sections: string[] = []; + + sections.push(`## Project: ${context.projectName}`); + sections.push(context.projectDescription); + if (context.languages.length) { + sections.push(`Languages: ${context.languages.join(', ')}`); + } + if (context.frameworks.length) { + sections.push(`Frameworks: ${context.frameworks.join(', ')}`); + } + + if (context.relevantLayers.length) { + sections.push('\n## Relevant Layers'); + for (const layer of context.relevantLayers) { + sections.push(`### ${layer.name}\n${layer.description}`); + } + } + + sections.push('\n## Relevant Code Components'); + for (const node of context.relevantNodes) { + const parts = [`**${node.name}** (${node.type}, ${node.complexity})`]; + if (node.filePath) parts.push(` File: ${node.filePath}`); + parts.push(` ${node.summary}`); + if (node.tags.length) parts.push(` Tags: ${node.tags.join(', ')}`); + if (node.languageNotes) parts.push(` Note: ${node.languageNotes}`); + sections.push(parts.join('\n')); + } + + if (context.relevantEdges.length) { + sections.push('\n## Relationships'); + for (const edge of context.relevantEdges) { + const sourceNode = context.relevantNodes.find((n) => n.id === edge.source); + const targetNode = context.relevantNodes.find((n) => n.id === edge.target); + const sourceName = sourceNode?.name ?? edge.source; + const targetName = targetNode?.name ?? edge.target; + sections.push(`- ${sourceName} --[${edge.type}]--> ${targetName}${edge.description ? ` (${edge.description})` : ''}`); + } + } + + return sections.join('\n'); +} +``` + +**Step 6: Implement understand-chat.ts (prompt template)** + +```typescript +// packages/skill/src/understand-chat.ts +import { formatContextForPrompt, buildChatContext } from './context-builder.js'; +import type { KnowledgeGraph } from '@understand-anything/core'; + +export function buildChatPrompt(graph: KnowledgeGraph, query: string): string { + const context = buildChatContext(graph, query); + const formattedContext = formatContextForPrompt(context); + + return `You are a knowledgeable assistant that helps developers understand a codebase. +You have access to a knowledge graph analysis of the project. Use the context below to answer the user's question accurately and helpfully. + +If the question relates to code, reference specific files and functions. +If the question is about architecture, describe the layers and relationships. +If you're unsure, say so rather than guessing. + +${formattedContext} + +## User Question +${query}`; +} +``` + +**Step 7: Create the Claude Code skill definition file** + +```markdown + +--- +name: understand-chat +description: Ask questions about the current codebase using the knowledge graph +arguments: query +--- + +# /understand-chat + +Answer questions about this codebase using the knowledge graph at `.understand-anything/knowledge-graph.json`. + +## Instructions + +1. Read the knowledge graph file at `.understand-anything/knowledge-graph.json` in the current project root +2. If the file doesn't exist, tell the user to run `/understand` first to analyze the project +3. Use the knowledge graph context to answer the user's query: "${ARGUMENTS}" +4. Reference specific files, functions, and relationships from the graph +5. If the project has layers defined, explain which layer(s) are relevant +6. Be concise but thorough — link concepts to actual code locations +``` + +**Step 8: Create barrel export** + +```typescript +// packages/skill/src/index.ts +export { buildChatContext, formatContextForPrompt, type ChatContext } from './context-builder.js'; +export { buildChatPrompt } from './understand-chat.js'; +``` + +**Step 9: Run tests to verify they pass** + +```bash +pnpm install && pnpm --filter @understand-anything/skill test +``` +Expected: ALL PASS + +**Step 10: Commit** + +```bash +git add packages/skill/ +git commit -m "feat(skill): scaffold skill package with /understand-chat command" +``` + +--- + +## Task 7: Dashboard Search Enhancement + Store Integration + +**Files:** +- Modify: `packages/dashboard/src/store.ts` +- Modify: `packages/dashboard/src/components/SearchBar.tsx` +- Modify: `packages/dashboard/src/components/GraphView.tsx` + +**Context:** Wire the core `SearchEngine` into the dashboard. Replace the simple substring filter in the Zustand store with `SearchEngine` from core. Enhance the SearchBar to show scored results with node type icons. Enhance the GraphView to highlight search results with varying intensity based on relevance score. + +**Step 1: Update the Zustand store** + +Replace the search logic in `packages/dashboard/src/store.ts`: + +```typescript +import { SearchEngine } from '@understand-anything/core'; +import type { KnowledgeGraph, SearchResult } from '@understand-anything/core'; + +interface DashboardStore { + graph: KnowledgeGraph | null; + selectedNodeId: string | null; + searchQuery: string; + searchResults: SearchResult[]; // Changed from string[] to SearchResult[] + searchEngine: SearchEngine | null; + + setGraph: (graph: KnowledgeGraph) => void; + selectNode: (nodeId: string | null) => void; + setSearchQuery: (query: string) => void; +} + +export const useDashboardStore = create()((set, get) => ({ + graph: null, + selectedNodeId: null, + searchQuery: '', + searchResults: [], + searchEngine: null, + + setGraph: (graph) => { + const searchEngine = new SearchEngine(graph.nodes); + set({ graph, searchEngine }); + }, + + selectNode: (nodeId) => set({ selectedNodeId: nodeId }), + + setSearchQuery: (query) => { + const { searchEngine } = get(); + if (!searchEngine || !query.trim()) { + set({ searchQuery: query, searchResults: [] }); + return; + } + const results = searchEngine.search(query); + set({ searchQuery: query, searchResults: results }); + }, +})); +``` + +**Step 2: Update SearchBar component** + +Update `SearchBar.tsx` to display result scores and show a dropdown of top matches: + +- Show result count with "fuzzy" label +- Display top 5 results as clickable items below the search input (name + type + score) +- Clicking a result selects that node and scrolls graph to it + +**Step 3: Update GraphView to use scored highlighting** + +Update `GraphView.tsx`: +- Search highlighting intensity varies by score (lower score = better match = brighter highlight) +- Best matches: bright yellow ring; weaker matches: dimmer yellow +- Pass the search score as data to CustomNode so it can adjust its appearance + +**Step 4: Verify manually** + +```bash +pnpm dev:dashboard +``` +Test: type "auth" in search → verify fuzzy results, scored highlighting, clickable results. + +**Step 5: Commit** + +```bash +git add packages/dashboard/src/store.ts packages/dashboard/src/components/SearchBar.tsx packages/dashboard/src/components/GraphView.tsx +git commit -m "feat(dashboard): wire core SearchEngine with fuzzy matching and scored highlighting" +``` + +--- + +## Task 8: Dashboard Chat Panel + +**Files:** +- Create: `packages/dashboard/src/components/ChatPanel.tsx` +- Modify: `packages/dashboard/src/store.ts` +- Modify: `packages/dashboard/src/App.tsx` + +**Context:** Replace the "Chat — coming soon" placeholder with a working chat panel. For the standalone dashboard (no Claude Code session), the user provides a Claude API key. The chat is context-aware: it automatically includes the selected node's context and nearby graph relationships. Uses the `@anthropic-ai/sdk` package with streaming for real-time responses. The chat panel shows a message list and input, with messages from both user and assistant. + +**Step 1: Install Anthropic SDK** + +```bash +cd packages/dashboard && pnpm add @anthropic-ai/sdk +``` + +**Step 2: Add chat state to the Zustand store** + +Add to `packages/dashboard/src/store.ts`: + +```typescript +interface ChatMessage { + role: 'user' | 'assistant'; + content: string; +} + +// Add to DashboardStore interface: +apiKey: string; +chatMessages: ChatMessage[]; +chatLoading: boolean; +setApiKey: (key: string) => void; +sendChatMessage: (message: string) => Promise; +clearChat: () => void; +``` + +The `sendChatMessage` implementation: +1. Gets the current `graph`, `selectedNodeId`, and `apiKey` from store +2. Uses `buildChatContext` + `formatContextForPrompt` from `@understand-anything/core` (or inline the same logic since the skill package uses core) +3. Builds a system prompt with the graph context +4. Calls Claude API with the `@anthropic-ai/sdk` +5. Streams the response, updating `chatMessages` as chunks arrive +6. Sets `chatLoading` during the call + +**Step 3: Create ChatPanel component** + +```typescript +// packages/dashboard/src/components/ChatPanel.tsx +// Key features: +// 1. API key input (shown once, stored in zustand, persisted to localStorage) +// 2. Message list with user/assistant styling +// 3. Input field with send button +// 4. "Context: " indicator when a node is selected +// 5. Loading spinner during API calls +// 6. Auto-scroll to latest message +// 7. Markdown rendering for assistant messages (basic: bold, code blocks, lists) +``` + +The component layout: +``` +┌─ Chat Panel ────────────────────┐ +│ [🔑 Enter API key...] │ ← Only shown if no key +├─────────────────────────────────┤ +│ Context: auth/login.ts │ ← Shows selected node +├─────────────────────────────────┤ +│ User: How does auth work? │ +│ │ +│ Assistant: The authentication │ +│ flow starts in login.ts... │ +│ │ +│ User: What calls it? │ +│ │ +│ Assistant: The API routes in │ +│ routes/api.ts import and call...│ +├─────────────────────────────────┤ +│ [Ask about this codebase...] 📤│ +└─────────────────────────────────┘ +``` + +**Step 4: Wire ChatPanel into App.tsx** + +Replace the placeholder `div` in the bottom-left grid cell: +```typescript +// In App.tsx, replace: +
Chat — coming soon
+// With: + +``` + +**Step 5: Verify manually** + +```bash +pnpm dev:dashboard +``` +Test: +1. Enter a Claude API key +2. Select a node in the graph +3. Ask "what does this do?" → verify contextual answer +4. Ask a follow-up → verify conversation history is maintained + +**Step 6: Commit** + +```bash +git add packages/dashboard/src/components/ChatPanel.tsx packages/dashboard/src/store.ts packages/dashboard/src/App.tsx packages/dashboard/package.json pnpm-lock.yaml +git commit -m "feat(dashboard): add context-aware chat panel with Claude API integration" +``` + +--- + +## Task 9: Dashboard Layer Visualization + +**Files:** +- Modify: `packages/dashboard/src/store.ts` +- Modify: `packages/dashboard/src/components/GraphView.tsx` +- Create: `packages/dashboard/src/components/LayerLegend.tsx` +- Modify: `packages/dashboard/src/App.tsx` + +**Context:** When the knowledge graph has layers defined, the dashboard should visually group nodes by layer. Use React Flow's built-in group node feature — create parent nodes for each layer with a colored background, and assign layer member nodes as children. Add a toggleable layer legend showing layer colors and descriptions. + +**Step 1: Add layer state to the store** + +Add to `packages/dashboard/src/store.ts`: +```typescript +// Add to DashboardStore interface: +showLayers: boolean; +toggleLayers: () => void; +``` + +**Step 2: Update GraphView for layer grouping** + +When `showLayers` is true and graph has layers: +1. Create a "group" type React Flow node for each layer (large background rectangle) +2. Set layer nodes as `parentId` of their member nodes +3. Apply distinct background colors per layer (semi-transparent) +4. Use dagre layout with subgraph support, or position layer groups in columns +5. Show layer name as label on the group node + +When `showLayers` is false, render normally without groups. + +**Step 3: Create LayerLegend component** + +```typescript +// packages/dashboard/src/components/LayerLegend.tsx +// Shows: +// - Toggle button "Show Layers" / "Hide Layers" +// - List of layers with color dot, name, node count +// - Click layer name to filter graph to that layer +``` + +**Step 4: Wire into App.tsx** + +Add `LayerLegend` to the header area, next to SearchBar. + +**Step 5: Verify manually** + +```bash +pnpm dev:dashboard +``` +Update the sample `knowledge-graph.json` in `packages/dashboard/public/` to include layers, then verify layer grouping renders correctly. + +**Step 6: Commit** + +```bash +git add packages/dashboard/src/components/LayerLegend.tsx packages/dashboard/src/components/GraphView.tsx packages/dashboard/src/store.ts packages/dashboard/src/App.tsx packages/dashboard/public/knowledge-graph.json +git commit -m "feat(dashboard): add layer visualization with grouping and legend" +``` + +--- + +## Task 10: Integration Polish — Sample Data, Build Verification, README Update + +**Files:** +- Modify: `packages/dashboard/public/knowledge-graph.json` +- Modify: `CLAUDE.md` +- Modify: `README.md` +- Modify: `packages/core/src/index.ts` (ensure all exports clean) + +**Context:** Final task: create a richer sample knowledge graph that exercises all Phase 2 features (layers, many nodes, varied types). Verify the full build succeeds. Update documentation. + +**Step 1: Create rich sample knowledge graph** + +Update `packages/dashboard/public/knowledge-graph.json` with a realistic sample: +- 15-20 nodes across all 5 types (file, function, class, module, concept) +- 20+ edges across multiple EdgeTypes +- 4-5 layers (API, Service, Data, UI, Utility) +- Varied complexity levels +- Realistic summaries and tags + +This serves as both demo data and manual test fixture. + +**Step 2: Verify full build** + +```bash +pnpm install +pnpm --filter @understand-anything/core build +pnpm --filter @understand-anything/skill build +pnpm --filter @understand-anything/core test +pnpm --filter @understand-anything/skill test +pnpm dev:dashboard +``` + +All should pass/run without errors. + +**Step 3: Update CLAUDE.md** + +Add Phase 2 context: +```markdown +## Key Commands (updated) +- `pnpm --filter @understand-anything/skill build` — Build skill package +- `pnpm --filter @understand-anything/skill test` — Run skill tests + +## Phase 2 Features +- Fuzzy search via Fuse.js (SearchEngine in core) +- Zod schema validation on graph loading +- Staleness detection + incremental graph merging +- Layer auto-detection (heuristic + LLM prompt) +- `/understand-chat` skill command +- Dashboard chat panel (Claude API integration) +- Dagre auto-layout for graph visualization +- Layer visualization with grouping and legend +``` + +**Step 4: Update README.md** + +Add Phase 2 feature descriptions, updated screenshots section placeholder, new commands. + +**Step 5: Commit** + +```bash +git add packages/dashboard/public/knowledge-graph.json CLAUDE.md README.md packages/core/src/index.ts +git commit -m "docs: update sample data, CLAUDE.md, and README for Phase 2" +``` + +--- + +## Verification Checklist + +After all tasks complete: + +1. **Schema validation**: Load a corrupted JSON → verify it throws with clear error message +2. **Fuzzy search**: Type "auth contrl" in search → verify it finds "AuthController" or similar +3. **Auto-layout**: Open dashboard → verify nodes arranged hierarchically, not in grid +4. **Staleness**: Call `isStale('/project', 'oldHash')` → verify it detects changes +5. **Layer detection**: Call `detectLayers(graph)` on a project with routes/models/services → verify layers populated +6. **`/understand-chat`**: Verify skill file exists at `packages/skill/.claude/skills/understand-chat.md` +7. **Chat panel**: Enter API key, select node, ask question → verify contextual response +8. **Layer visualization**: Toggle layers on → verify colored group nodes appear +9. **All tests pass**: `pnpm --filter @understand-anything/core test && pnpm --filter @understand-anything/skill test` +10. **Full build**: `pnpm -r build` succeeds + +--- + +## Dependency Graph + +``` +Task 1 (zod schema) ─────────────────────────────┐ +Task 2 (search engine) ──┬── Task 7 (dashboard │ +Task 3 (dagre layout) ───┤ search + store) │ + │ │ +Task 4 (staleness) ──────┤ │ + │ │ +Task 5 (layers) ─────────┼── Task 9 (layer viz) ──┤ + │ ├── Task 10 (polish) +Task 6 (skill pkg) ──────┼── Task 8 (chat panel) ─┤ + │ │ +Task 7 ──────────────────┘ │ +Task 8 ────────────────────────────────────────────┘ +Task 9 ────────────────────────────────────────────┘ +``` + +**Safe parallel groups:** +- Tasks 1, 2, 3, 4, 5, 6 are all independent (but run sequentially per subagent-driven-dev) +- Task 7 depends on Tasks 2 + 3 +- Task 8 depends on Task 6 +- Task 9 depends on Tasks 3 + 5 +- Task 10 depends on all others diff --git a/Understand-Anything-main/docs/superpowers/plans/2026-03-14-phase3-implementation.md b/Understand-Anything-main/docs/superpowers/plans/2026-03-14-phase3-implementation.md new file mode 100644 index 0000000..1bf4c8a --- /dev/null +++ b/Understand-Anything-main/docs/superpowers/plans/2026-03-14-phase3-implementation.md @@ -0,0 +1,1658 @@ +# Understand Anything — Phase 3 (Learn Mode) Implementation Plan + +> **For Claude:** REQUIRED SUB-SKILL: Use superpowers:executing-plans to implement this plan task-by-task. + +**Goal:** Add the "Learn Mode" layer — tour generation, contextual explanations, language-specific lessons, and persona modes (non-technical / junior / experienced). + +**Architecture:** Extends the existing monorepo. Core gets tour generation and language lesson prompt builders. Dashboard gets a new LearnPanel component, persona selector, and enhanced node explanation. The existing 4-panel layout becomes persona-adaptive. + +**Tech Stack:** No new dependencies required. Uses existing react-markdown, @anthropic-ai/sdk, zustand, @xyflow/react, tailwindcss. + +--- + +## Dependency Graph + +``` +Task 1 (Tour Gen Core) ──────────────┐ + ├─→ Task 3 (Tour Player + Highlights) +Task 2 (LearnPanel + Store) ─────────┘ │ + │ +Task 4 (Node Explanations) ─── (independent) ───┤ + │ +Task 5 (Language Lesson Core) ───────────────────┤ + ├─→ Task 7 (Persona Modes) +Task 6 (Language Lesson Display) ────────────────┘ +``` + +Tasks 1, 2, 4, 5 can be developed in any order. Task 3 depends on Task 2. Task 6 depends on Task 5. Task 7 depends on Tasks 2+3+6 being complete. + +--- + +## Task 1: Tour Generation Engine (Core) + +**Files:** +- Create: `packages/core/src/analyzer/tour-generator.ts` +- Create: `packages/core/src/__tests__/tour-generator.test.ts` +- Modify: `packages/core/src/index.ts` (add exports) + +**Context:** The `TourStep` schema already exists in `packages/core/src/types.ts` (order, title, description, nodeIds, languageLesson?). The sample `knowledge-graph.json` already has 6 tour steps with language lessons. This task builds the engine that GENERATES those tours: an LLM prompt builder + response parser, and a heuristic fallback that creates tours without an LLM by using graph topology (entry-point detection → topological sort → group by layers). + +**Step 1: Write failing tests** + +```typescript +// packages/core/src/__tests__/tour-generator.test.ts +import { describe, it, expect } from "vitest"; +import { + buildTourGenerationPrompt, + parseTourGenerationResponse, + generateHeuristicTour, +} from "../analyzer/tour-generator.js"; +import type { KnowledgeGraph } from "../types.js"; + +const sampleGraph: KnowledgeGraph = { + version: "1.0.0", + project: { + name: "test-project", + languages: ["typescript"], + frameworks: ["express"], + description: "A test project", + analyzedAt: "2026-03-14T00:00:00Z", + gitCommitHash: "abc123", + }, + nodes: [ + { + id: "file:src/index.ts", + type: "file", + name: "index.ts", + filePath: "src/index.ts", + summary: "Application entry point", + tags: ["entry", "server"], + complexity: "simple", + }, + { + id: "file:src/routes.ts", + type: "file", + name: "routes.ts", + filePath: "src/routes.ts", + summary: "Route definitions", + tags: ["routes", "api"], + complexity: "moderate", + }, + { + id: "file:src/service.ts", + type: "file", + name: "service.ts", + filePath: "src/service.ts", + summary: "Business logic", + tags: ["service"], + complexity: "complex", + }, + { + id: "file:src/db.ts", + type: "file", + name: "db.ts", + filePath: "src/db.ts", + summary: "Database connection", + tags: ["database"], + complexity: "simple", + }, + { + id: "concept:auth-flow", + type: "concept", + name: "Auth Flow", + summary: "Authentication concept", + tags: ["concept", "auth"], + complexity: "moderate", + }, + ], + edges: [ + { source: "file:src/index.ts", target: "file:src/routes.ts", type: "imports", direction: "forward", weight: 0.9 }, + { source: "file:src/routes.ts", target: "file:src/service.ts", type: "calls", direction: "forward", weight: 0.8 }, + { source: "file:src/service.ts", target: "file:src/db.ts", type: "reads_from", direction: "forward", weight: 0.7 }, + ], + layers: [ + { id: "layer:api", name: "API Layer", description: "HTTP routes", nodeIds: ["file:src/index.ts", "file:src/routes.ts"] }, + { id: "layer:service", name: "Service Layer", description: "Business logic", nodeIds: ["file:src/service.ts"] }, + { id: "layer:data", name: "Data Layer", description: "Database", nodeIds: ["file:src/db.ts"] }, + ], + tour: [], +}; + +describe("tour-generator", () => { + describe("buildTourGenerationPrompt", () => { + it("includes project name and description", () => { + const prompt = buildTourGenerationPrompt(sampleGraph); + expect(prompt).toContain("test-project"); + expect(prompt).toContain("A test project"); + }); + + it("includes all node summaries", () => { + const prompt = buildTourGenerationPrompt(sampleGraph); + expect(prompt).toContain("index.ts"); + expect(prompt).toContain("routes.ts"); + expect(prompt).toContain("service.ts"); + }); + + it("includes layer information", () => { + const prompt = buildTourGenerationPrompt(sampleGraph); + expect(prompt).toContain("API Layer"); + expect(prompt).toContain("Service Layer"); + }); + + it("requests JSON output format", () => { + const prompt = buildTourGenerationPrompt(sampleGraph); + expect(prompt).toContain("JSON"); + }); + }); + + describe("parseTourGenerationResponse", () => { + it("parses valid JSON response with tour steps", () => { + const response = JSON.stringify({ + steps: [ + { order: 1, title: "Entry Point", description: "Start here", nodeIds: ["file:src/index.ts"] }, + { order: 2, title: "Routing", description: "Routes next", nodeIds: ["file:src/routes.ts"], languageLesson: "Express uses middleware" }, + ], + }); + const steps = parseTourGenerationResponse(response); + expect(steps).toHaveLength(2); + expect(steps[0].title).toBe("Entry Point"); + expect(steps[1].languageLesson).toBe("Express uses middleware"); + }); + + it("extracts JSON from markdown code blocks", () => { + const response = "Here is the tour:\n```json\n" + JSON.stringify({ + steps: [{ order: 1, title: "Step 1", description: "Desc", nodeIds: ["n1"] }], + }) + "\n```"; + const steps = parseTourGenerationResponse(response); + expect(steps).toHaveLength(1); + }); + + it("returns empty array for unparseable response", () => { + const steps = parseTourGenerationResponse("not json at all"); + expect(steps).toEqual([]); + }); + + it("filters out steps with missing required fields", () => { + const response = JSON.stringify({ + steps: [ + { order: 1, title: "Valid", description: "OK", nodeIds: ["n1"] }, + { order: 2, description: "Missing title", nodeIds: ["n2"] }, + { order: 3, title: "Missing desc", nodeIds: ["n3"] }, + ], + }); + const steps = parseTourGenerationResponse(response); + expect(steps).toHaveLength(1); + expect(steps[0].title).toBe("Valid"); + }); + }); + + describe("generateHeuristicTour", () => { + it("starts with entry-point nodes", () => { + const tour = generateHeuristicTour(sampleGraph); + expect(tour.length).toBeGreaterThan(0); + // index.ts has no incoming edges → entry point + expect(tour[0].nodeIds).toContain("file:src/index.ts"); + }); + + it("follows topological order", () => { + const tour = generateHeuristicTour(sampleGraph); + const allNodeIds = tour.flatMap((s) => s.nodeIds); + const indexPos = allNodeIds.indexOf("file:src/index.ts"); + const routesPos = allNodeIds.indexOf("file:src/routes.ts"); + const servicePos = allNodeIds.indexOf("file:src/service.ts"); + // entry → routes → service (topological order) + expect(indexPos).toBeLessThan(routesPos); + expect(routesPos).toBeLessThan(servicePos); + }); + + it("includes concept nodes in separate steps", () => { + const tour = generateHeuristicTour(sampleGraph); + const conceptStep = tour.find((s) => + s.nodeIds.includes("concept:auth-flow"), + ); + expect(conceptStep).toBeDefined(); + }); + + it("assigns order numbers sequentially", () => { + const tour = generateHeuristicTour(sampleGraph); + tour.forEach((step, i) => { + expect(step.order).toBe(i + 1); + }); + }); + + it("groups nodes by layer when layers exist", () => { + const tour = generateHeuristicTour(sampleGraph); + // Steps should roughly follow layer boundaries + expect(tour.length).toBeGreaterThanOrEqual(3); + }); + + it("produces valid TourStep objects", () => { + const tour = generateHeuristicTour(sampleGraph); + for (const step of tour) { + expect(step).toHaveProperty("order"); + expect(step).toHaveProperty("title"); + expect(step).toHaveProperty("description"); + expect(step).toHaveProperty("nodeIds"); + expect(step.title.length).toBeGreaterThan(0); + expect(step.description.length).toBeGreaterThan(0); + expect(step.nodeIds.length).toBeGreaterThan(0); + } + }); + + it("handles graph with no edges gracefully", () => { + const isolated = { ...sampleGraph, edges: [] }; + const tour = generateHeuristicTour(isolated); + expect(tour.length).toBeGreaterThan(0); + }); + + it("handles graph with no layers", () => { + const noLayers = { ...sampleGraph, layers: [] }; + const tour = generateHeuristicTour(noLayers); + expect(tour.length).toBeGreaterThan(0); + }); + }); +}); +``` + +**Step 2: Run tests to verify they fail** + +```bash +cd packages/core && pnpm test -- --reporter verbose src/__tests__/tour-generator.test.ts +``` + +Expected: FAIL — module not found + +**Step 3: Implement tour-generator.ts** + +```typescript +// packages/core/src/analyzer/tour-generator.ts +import type { KnowledgeGraph, TourStep, GraphNode, GraphEdge } from "../types.js"; + +/** + * Build an LLM prompt that asks for a guided tour of the project. + */ +export function buildTourGenerationPrompt(graph: KnowledgeGraph): string { + const { project, nodes, edges, layers } = graph; + + const nodeList = nodes + .map((n) => `- [${n.type}] ${n.name}${n.filePath ? ` (${n.filePath})` : ""}: ${n.summary}`) + .join("\n"); + + const edgeList = edges + .slice(0, 50) // cap to avoid overly long prompts + .map((e) => { + const src = nodes.find((n) => n.id === e.source)?.name ?? e.source; + const tgt = nodes.find((n) => n.id === e.target)?.name ?? e.target; + return `- ${src} --[${e.type}]--> ${tgt}`; + }) + .join("\n"); + + const layerList = layers.length > 0 + ? layers.map((l) => `- ${l.name}: ${l.description} (${l.nodeIds.length} nodes)`).join("\n") + : "No layers defined"; + + return [ + `You are generating a guided tour for a software project called "${project.name}".`, + ``, + `Project description: ${project.description}`, + `Languages: ${project.languages.join(", ")}`, + `Frameworks: ${project.frameworks.join(", ")}`, + ``, + `## Nodes`, + nodeList, + ``, + `## Relationships`, + edgeList, + ``, + `## Layers`, + layerList, + ``, + `## Instructions`, + `Create a guided tour of this project. Each step should:`, + `1. Focus on 1-4 nodes that belong together conceptually`, + `2. Have a clear, engaging title (like "Where It All Begins" not "Step 1")`, + `3. Explain in plain English what these components do and WHY they exist`, + `4. Follow the natural execution flow (entry point → routing → business logic → data)`, + `5. Include a languageLesson field for steps that use language-specific concepts`, + ` (e.g., middleware, generics, async/await, decorators — explain them simply)`, + ``, + `Return JSON in exactly this format:`, + `\`\`\`json`, + `{`, + ` "steps": [`, + ` {`, + ` "order": 1,`, + ` "title": "Engaging Step Title",`, + ` "description": "Markdown explanation of what these nodes do.",`, + ` "nodeIds": ["node-id-1", "node-id-2"],`, + ` "languageLesson": "Optional: explain a language concept used here"`, + ` }`, + ` ]`, + `}`, + `\`\`\``, + ``, + `Create 4-8 steps covering the full project. Use actual node IDs from the list above.`, + ].join("\n"); +} + +/** + * Parse the LLM response into TourStep[]. + * Handles raw JSON, JSON in markdown code blocks, and graceful fallback. + */ +export function parseTourGenerationResponse(response: string): TourStep[] { + let json: string = response; + + // Extract from markdown code blocks if present + const codeBlockMatch = response.match(/```(?:json)?\s*\n?([\s\S]*?)\n?```/); + if (codeBlockMatch) { + json = codeBlockMatch[1]; + } + + try { + const parsed = JSON.parse(json); + const rawSteps: unknown[] = Array.isArray(parsed) ? parsed : parsed?.steps; + if (!Array.isArray(rawSteps)) return []; + + return rawSteps.filter((s): s is TourStep => { + if (typeof s !== "object" || s === null) return false; + const step = s as Record; + return ( + typeof step.order === "number" && + typeof step.title === "string" && + step.title.length > 0 && + typeof step.description === "string" && + step.description.length > 0 && + Array.isArray(step.nodeIds) && + step.nodeIds.length > 0 + ); + }).map((s) => ({ + order: s.order, + title: s.title, + description: s.description, + nodeIds: s.nodeIds, + ...(s.languageLesson ? { languageLesson: s.languageLesson } : {}), + })); + } catch { + return []; + } +} + +/** + * Generate a tour using heuristics only (no LLM required). + * + * Strategy: + * 1. Find entry-point nodes (no incoming edges, or named index/main/app) + * 2. Topological sort from entry points + * 3. Group by layer (if layers exist) or by execution depth + * 4. Add concept nodes as separate explanatory steps + */ +export function generateHeuristicTour(graph: KnowledgeGraph): TourStep[] { + const { nodes, edges, layers } = graph; + + // Separate concept nodes from code nodes + const codeNodes = nodes.filter((n) => n.type !== "concept"); + const conceptNodes = nodes.filter((n) => n.type === "concept"); + + // Build adjacency info + const incomingCount = new Map(); + const adjacency = new Map(); + for (const node of codeNodes) { + incomingCount.set(node.id, 0); + adjacency.set(node.id, []); + } + for (const edge of edges) { + if (!incomingCount.has(edge.source) || !incomingCount.has(edge.target)) continue; + adjacency.get(edge.source)!.push(edge.target); + incomingCount.set(edge.target, (incomingCount.get(edge.target) ?? 0) + 1); + } + + // Find entry points: nodes with 0 incoming edges + const entryPoints = codeNodes.filter((n) => (incomingCount.get(n.id) ?? 0) === 0); + + // Topological sort (Kahn's algorithm) + const sorted: GraphNode[] = []; + const queue = [...entryPoints]; + const visited = new Set(); + + while (queue.length > 0) { + const node = queue.shift()!; + if (visited.has(node.id)) continue; + visited.add(node.id); + sorted.push(node); + + for (const targetId of adjacency.get(node.id) ?? []) { + const count = (incomingCount.get(targetId) ?? 1) - 1; + incomingCount.set(targetId, count); + const targetNode = codeNodes.find((n) => n.id === targetId); + if (targetNode && count <= 0 && !visited.has(targetId)) { + queue.push(targetNode); + } + } + } + + // Add any unvisited nodes (cycles or disconnected) + for (const node of codeNodes) { + if (!visited.has(node.id)) { + sorted.push(node); + } + } + + // Group sorted nodes into tour steps + const steps: TourStep[] = []; + + if (layers.length > 0) { + // Group by layer, in topological order of first appearance + const layerOrder: string[] = []; + const layerNodes = new Map(); + const nodeToLayer = new Map(); + + for (const layer of layers) { + layerNodes.set(layer.id, []); + for (const nid of layer.nodeIds) { + nodeToLayer.set(nid, layer.id); + } + } + + // Determine layer order based on topological sort + for (const node of sorted) { + const lid = nodeToLayer.get(node.id); + if (lid) { + if (!layerOrder.includes(lid)) layerOrder.push(lid); + layerNodes.get(lid)!.push(node.id); + } + } + + // Unlayered nodes + const unlayered = sorted.filter((n) => !nodeToLayer.has(n.id)).map((n) => n.id); + + for (const lid of layerOrder) { + const layer = layers.find((l) => l.id === lid)!; + const nids = layerNodes.get(lid) ?? []; + if (nids.length === 0) continue; + + steps.push({ + order: steps.length + 1, + title: layer.name, + description: `${layer.description}. This layer contains: ${nids.map((id) => nodes.find((n) => n.id === id)?.name ?? id).join(", ")}.`, + nodeIds: nids, + }); + } + + if (unlayered.length > 0) { + steps.push({ + order: steps.length + 1, + title: "Supporting Components", + description: `Additional components that support the main architecture: ${unlayered.map((id) => nodes.find((n) => n.id === id)?.name ?? id).join(", ")}.`, + nodeIds: unlayered, + }); + } + } else { + // No layers: group by depth/batch (up to 3 nodes per step) + const batchSize = 3; + for (let i = 0; i < sorted.length; i += batchSize) { + const batch = sorted.slice(i, i + batchSize); + const names = batch.map((n) => n.name).join(", "); + steps.push({ + order: steps.length + 1, + title: i === 0 ? "Entry Points" : `Components: ${names}`, + description: batch.map((n) => `**${n.name}** — ${n.summary}`).join("\n\n"), + nodeIds: batch.map((n) => n.id), + }); + } + } + + // Add concept nodes as a final explanatory step + if (conceptNodes.length > 0) { + steps.push({ + order: steps.length + 1, + title: "Key Concepts", + description: conceptNodes + .map((n) => `**${n.name}** — ${n.summary}`) + .join("\n\n"), + nodeIds: conceptNodes.map((n) => n.id), + }); + } + + return steps; +} +``` + +**Step 4: Run tests to verify they pass** + +```bash +cd packages/core && pnpm test -- --reporter verbose src/__tests__/tour-generator.test.ts +``` + +Expected: All tests PASS + +**Step 5: Add exports to index.ts** + +Add to `packages/core/src/index.ts`: +```typescript +export { + buildTourGenerationPrompt, + parseTourGenerationResponse, + generateHeuristicTour, +} from "./analyzer/tour-generator.js"; +``` + +**Step 6: Verify build** + +```bash +cd packages/core && pnpm build +``` + +**Step 7: Commit** + +```bash +git add packages/core/src/analyzer/tour-generator.ts packages/core/src/__tests__/tour-generator.test.ts packages/core/src/index.ts +git commit -m "feat(core): add tour generation engine with heuristic and LLM strategies" +``` + +--- + +## Task 2: LearnPanel Component + Tour Store State (Dashboard) + +**Files:** +- Create: `packages/dashboard/src/components/LearnPanel.tsx` +- Modify: `packages/dashboard/src/store.ts` (add tour state + actions) +- Modify: `packages/dashboard/src/App.tsx` (replace bottom-right NodeInfo with tabbed panel) + +**Context:** The dashboard currently has a 4-panel layout: GraphView (top-left), CodeViewer (top-right), ChatPanel (bottom-left), NodeInfo (bottom-right). This task adds tour state to the Zustand store and creates a LearnPanel component. The bottom-right panel becomes a tabbed view switching between NodeInfo and LearnPanel. The LearnPanel shows the tour step list and current step content. + +**Step 1: Add tour state to the Zustand store** + +In `packages/dashboard/src/store.ts`, add to the `DashboardStore` interface: + +```typescript +// Add these fields to the interface +tourActive: boolean; +currentTourStep: number; +tourHighlightedNodeIds: string[]; + +// Add these actions +startTour: () => void; +stopTour: () => void; +setTourStep: (step: number) => void; +nextTourStep: () => void; +prevTourStep: () => void; +``` + +Add to the store implementation: + +```typescript +tourActive: false, +currentTourStep: 0, +tourHighlightedNodeIds: [], + +startTour: () => { + const graph = get().graph; + if (!graph || graph.tour.length === 0) return; + const firstStep = graph.tour[0]; + set({ + tourActive: true, + currentTourStep: 0, + tourHighlightedNodeIds: firstStep.nodeIds, + selectedNodeId: null, + }); +}, + +stopTour: () => set({ + tourActive: false, + currentTourStep: 0, + tourHighlightedNodeIds: [], +}), + +setTourStep: (step) => { + const graph = get().graph; + if (!graph || step < 0 || step >= graph.tour.length) return; + set({ + currentTourStep: step, + tourHighlightedNodeIds: graph.tour[step].nodeIds, + }); +}, + +nextTourStep: () => { + const { graph, currentTourStep } = get(); + if (!graph) return; + const next = currentTourStep + 1; + if (next < graph.tour.length) { + set({ + currentTourStep: next, + tourHighlightedNodeIds: graph.tour[next].nodeIds, + }); + } +}, + +prevTourStep: () => { + const { graph, currentTourStep } = get(); + if (!graph) return; + const prev = currentTourStep - 1; + if (prev >= 0) { + set({ + currentTourStep: prev, + tourHighlightedNodeIds: graph.tour[prev].nodeIds, + }); + } +}, +``` + +**Step 2: Create the LearnPanel component** + +```tsx +// packages/dashboard/src/components/LearnPanel.tsx +import ReactMarkdown from "react-markdown"; +import { useDashboardStore } from "../store"; + +export default function LearnPanel() { + const graph = useDashboardStore((s) => s.graph); + const tourActive = useDashboardStore((s) => s.tourActive); + const currentTourStep = useDashboardStore((s) => s.currentTourStep); + const startTour = useDashboardStore((s) => s.startTour); + const stopTour = useDashboardStore((s) => s.stopTour); + const setTourStep = useDashboardStore((s) => s.setTourStep); + const nextTourStep = useDashboardStore((s) => s.nextTourStep); + const prevTourStep = useDashboardStore((s) => s.prevTourStep); + + const tourSteps = graph?.tour ?? []; + + if (tourSteps.length === 0) { + return ( +
+

No tour available for this project

+
+ ); + } + + if (!tourActive) { + return ( +
+
+

Project Tour

+

+ {tourSteps.length} steps to understand this codebase +

+

+ Follow a guided walkthrough of the project architecture +

+
+ + {/* Step list preview */} +
+ {tourSteps.map((step, i) => ( +
+ {step.order}. + {step.title} +
+ ))} +
+
+ ); + } + + const step = tourSteps[currentTourStep]; + const isFirst = currentTourStep === 0; + const isLast = currentTourStep === tourSteps.length - 1; + + return ( +
+ {/* Header with progress */} +
+

+ Tour +

+
+ + {currentTourStep + 1} / {tourSteps.length} + + +
+
+ + {/* Progress bar */} +
+
+
+ + {/* Step content */} +
+

{step.title}

+ +
+

{children}

, + strong: ({ children }) => {children}, + code: ({ children }) => ( + {children} + ), + ul: ({ children }) =>
    {children}
, + ol: ({ children }) =>
    {children}
, + }} + > + {step.description} + +
+ + {/* Language lesson */} + {step.languageLesson && ( +
+

+ Language Concept +

+

+ {step.languageLesson} +

+
+ )} + + {/* Referenced nodes */} +
+

+ Referenced Components +

+
+ {step.nodeIds.map((nodeId) => { + const node = graph?.nodes.find((n) => n.id === nodeId); + return ( + + {node?.name ?? nodeId} + + ); + })} +
+
+
+ + {/* Step navigation */} +
+ {/* Step dots */} +
+ {tourSteps.map((_, i) => ( +
+ + {/* Prev/Next buttons */} +
+ + +
+
+
+ ); +} +``` + +**Step 3: Add tabbed bottom-right panel to App.tsx** + +Replace the bottom-right panel in `packages/dashboard/src/App.tsx`. Add import for `LearnPanel` and a `useState` for the active tab. The bottom-right `
` becomes: + +```tsx +import LearnPanel from "./components/LearnPanel"; +// ... in App component, add state: +const hasTour = (graph?.tour ?? []).length > 0; + +// Replace the bottom-right panel div: +{/* Bottom-right: Node Info / Learn Panel */} +
+ {hasTour && ( +
+ + +
+ )} +
+ {useDashboardStore.getState().tourActive ? : } +
+
+``` + +Note: The implementer should use the Zustand store selectors properly with `useDashboardStore((s) => s.tourActive)` instead of `getState()` — the above is a sketch. The tab state should be reactive. + +**Step 4: Verify dashboard compiles and renders** + +```bash +cd packages/dashboard && pnpm build +``` + +**Step 5: Commit** + +```bash +git add packages/dashboard/src/components/LearnPanel.tsx packages/dashboard/src/store.ts packages/dashboard/src/App.tsx +git commit -m "feat(dashboard): add LearnPanel component with tour state management" +``` + +--- + +## Task 3: Tour Player — Graph Highlighting + Node Focus + +**Files:** +- Modify: `packages/dashboard/src/components/GraphView.tsx` (highlight tour nodes) +- Modify: `packages/dashboard/src/components/CustomNode.tsx` (tour highlight style) + +**Context:** When a tour is active, the GraphView must visually distinguish the nodes referenced by the current tour step. This task adds a `isTourHighlighted` prop to CustomNode and wires it through GraphView using the `tourHighlightedNodeIds` from the store. Tour-highlighted nodes get a distinct pulsing blue ring (different from search highlights which are yellow). + +**Step 1: Add isTourHighlighted to CustomNode data** + +In `packages/dashboard/src/components/CustomNode.tsx`, add to `CustomNodeData`: + +```typescript +export interface CustomNodeData extends Record { + label: string; + nodeType: string; + summary: string; + complexity: string; + isHighlighted: boolean; + searchScore?: number; + isSelected: boolean; + isTourHighlighted: boolean; // NEW +} +``` + +Add tour highlight ring logic (takes priority over search highlight but not selection): + +```typescript +let ringClass = ""; +if (data.isSelected) { + ringClass = "ring-2 ring-white"; +} else if (data.isTourHighlighted) { + ringClass = "ring-2 ring-blue-400 animate-pulse"; +} else if (data.isHighlighted) { + const score = data.searchScore ?? 1; + if (score <= 0.1) { + ringClass = "ring-2 ring-yellow-300"; + } else if (score <= 0.3) { + ringClass = "ring-2 ring-yellow-400"; + } else { + ringClass = "ring-2 ring-yellow-500/60"; + } +} +``` + +**Step 2: Pass tourHighlightedNodeIds through GraphView** + +In `packages/dashboard/src/components/GraphView.tsx`, add the store selector: + +```typescript +const tourHighlightedNodeIds = useDashboardStore((s) => s.tourHighlightedNodeIds); +``` + +Add `tourHighlightedNodeIds` to the `useMemo` dependency array. In the `flowNodes` mapping, add: + +```typescript +isTourHighlighted: tourHighlightedNodeIds.includes(node.id), +``` + +**Step 3: Verify dashboard compiles** + +```bash +cd packages/dashboard && pnpm build +``` + +**Step 4: Commit** + +```bash +git add packages/dashboard/src/components/GraphView.tsx packages/dashboard/src/components/CustomNode.tsx +git commit -m "feat(dashboard): highlight tour-referenced nodes in graph view" +``` + +--- + +## Task 4: Contextual Node Explanation (Dashboard) + +**Files:** +- Modify: `packages/dashboard/src/store.ts` (add explanation state + action) +- Modify: `packages/dashboard/src/components/NodeInfo.tsx` (add Explain button + display) + +**Context:** Users should be able to click "Explain" on any node to get a detailed plain-English explanation generated by Claude. This reuses the same Anthropic SDK pattern from the ChatPanel but targets a single node. The explanation includes what the node does, why it exists, how it connects to the rest of the project, and any notable patterns. The explanation is cached per node ID to avoid re-calling the API. + +**Step 1: Add explanation state to the store** + +In `packages/dashboard/src/store.ts`, add to the interface: + +```typescript +nodeExplanation: string | null; +nodeExplanationLoading: boolean; +nodeExplanationCache: Record; +explainNode: (nodeId: string) => Promise; +``` + +Add to the implementation: + +```typescript +nodeExplanation: null, +nodeExplanationLoading: false, +nodeExplanationCache: {}, + +explainNode: async (nodeId) => { + const { apiKey, graph, nodeExplanationCache } = get(); + if (!apiKey || !graph) return; + + // Check cache first + if (nodeExplanationCache[nodeId]) { + set({ nodeExplanation: nodeExplanationCache[nodeId] }); + return; + } + + const node = graph.nodes.find((n) => n.id === nodeId); + if (!node) return; + + set({ nodeExplanationLoading: true, nodeExplanation: null }); + + try { + const connections = graph.edges.filter( + (e) => e.source === nodeId || e.target === nodeId, + ); + const connDetails = connections + .map((e) => { + const isSource = e.source === nodeId; + const otherId = isSource ? e.target : e.source; + const otherNode = graph.nodes.find((n) => n.id === otherId); + return `${isSource ? "->" : "<-"} [${e.type}] ${otherNode?.name ?? otherId}`; + }) + .join("\n"); + + const layer = graph.layers.find((l) => l.nodeIds.includes(nodeId)); + + const prompt = [ + `Explain the following code component in plain English. Be thorough but accessible.`, + ``, + `**Component:** ${node.name}`, + `**Type:** ${node.type}`, + `**File:** ${node.filePath ?? "N/A"}`, + `**Summary:** ${node.summary}`, + `**Complexity:** ${node.complexity}`, + `**Tags:** ${node.tags.join(", ") || "none"}`, + layer ? `**Layer:** ${layer.name} — ${layer.description}` : "", + ``, + `**Connections:**`, + connDetails || " none", + ``, + `Explain:`, + `1. What this component does and WHY it exists`, + `2. How it fits into the larger architecture`, + `3. Key relationships with other components`, + `4. Any patterns or concepts worth understanding`, + ``, + `Keep the explanation concise (2-4 paragraphs). Use markdown formatting.`, + ].join("\n"); + + const client = new Anthropic({ apiKey, dangerouslyAllowBrowser: true }); + const response = await client.messages.create({ + model: "claude-sonnet-4-20250514", + max_tokens: 512, + messages: [{ role: "user", content: prompt }], + }); + + const text = response.content[0].type === "text" + ? response.content[0].text + : "Unable to generate explanation."; + + set((state) => ({ + nodeExplanation: text, + nodeExplanationLoading: false, + nodeExplanationCache: { ...state.nodeExplanationCache, [nodeId]: text }, + })); + } catch (err) { + set({ + nodeExplanation: `Error: ${err instanceof Error ? err.message : "Failed to generate explanation"}`, + nodeExplanationLoading: false, + }); + } +}, +``` + +Don't forget to add `import Anthropic from "@anthropic-ai/sdk"` if not already imported (it is in the current store.ts). + +Also add to `selectNode` action — clear explanation when switching nodes: + +```typescript +selectNode: (nodeId) => set({ selectedNodeId: nodeId, nodeExplanation: null }), +``` + +**Step 2: Add Explain button and display to NodeInfo** + +In `packages/dashboard/src/components/NodeInfo.tsx`, add store selectors and the UI: + +```typescript +const apiKey = useDashboardStore((s) => s.apiKey); +const nodeExplanation = useDashboardStore((s) => s.nodeExplanation); +const nodeExplanationLoading = useDashboardStore((s) => s.nodeExplanationLoading); +const explainNode = useDashboardStore((s) => s.explainNode); +``` + +Add after the summary paragraph, before tags: + +```tsx +{/* Explain button + explanation */} +{apiKey && ( +
+ {!nodeExplanation && !nodeExplanationLoading && ( + + )} + {nodeExplanationLoading && ( +
+ Generating explanation... +
+ )} + {nodeExplanation && ( +
+

{children}

, + strong: ({ children }) => {children}, + code: ({ children }) => ( + {children} + ), + }} + > + {nodeExplanation} + +
+ )} +
+)} +``` + +Don't forget to add `import ReactMarkdown from "react-markdown"` to NodeInfo. + +**Step 3: Verify dashboard compiles** + +```bash +cd packages/dashboard && pnpm build +``` + +**Step 4: Commit** + +```bash +git add packages/dashboard/src/store.ts packages/dashboard/src/components/NodeInfo.tsx +git commit -m "feat(dashboard): add contextual node explanation with Claude API" +``` + +--- + +## Task 5: Language Lesson Prompt Builder (Core) + +**Files:** +- Create: `packages/core/src/analyzer/language-lesson.ts` +- Create: `packages/core/src/__tests__/language-lesson.test.ts` +- Modify: `packages/core/src/index.ts` (add exports) + +**Context:** The `languageNotes` field on `GraphNode` and `languageLesson` field on `TourStep` are designed for language-specific teaching. This task builds the LLM prompt templates that generate these lessons — explaining language concepts (async/await, generics, middleware patterns, decorators, etc.) in the context of the user's actual code. This is what makes "Learn Mode" unique: you learn Go/Rust/TypeScript concepts by seeing them explained in YOUR project. + +**Step 1: Write failing tests** + +```typescript +// packages/core/src/__tests__/language-lesson.test.ts +import { describe, it, expect } from "vitest"; +import { + buildLanguageLessonPrompt, + parseLanguageLessonResponse, + detectLanguageConcepts, +} from "../analyzer/language-lesson.js"; +import type { GraphNode, GraphEdge } from "../types.js"; + +const sampleNode: GraphNode = { + id: "func:auth:verifyToken", + type: "function", + name: "verifyToken", + filePath: "src/auth/verify.ts", + lineRange: [10, 35], + summary: "Verifies JWT tokens and extracts user payload using async/await", + tags: ["auth", "jwt", "async"], + complexity: "moderate", +}; + +const sampleEdges: GraphEdge[] = [ + { source: "func:auth:verifyToken", target: "file:src/config.ts", type: "reads_from", direction: "forward", weight: 0.6 }, + { source: "file:src/middleware.ts", target: "func:auth:verifyToken", type: "calls", direction: "forward", weight: 0.8 }, +]; + +describe("language-lesson", () => { + describe("buildLanguageLessonPrompt", () => { + it("includes the node name and summary", () => { + const prompt = buildLanguageLessonPrompt(sampleNode, sampleEdges, "typescript"); + expect(prompt).toContain("verifyToken"); + expect(prompt).toContain("JWT tokens"); + }); + + it("includes the target language", () => { + const prompt = buildLanguageLessonPrompt(sampleNode, sampleEdges, "typescript"); + expect(prompt).toContain("TypeScript"); + }); + + it("includes relationship context", () => { + const prompt = buildLanguageLessonPrompt(sampleNode, sampleEdges, "typescript"); + expect(prompt).toContain("reads_from"); + }); + + it("requests JSON output", () => { + const prompt = buildLanguageLessonPrompt(sampleNode, sampleEdges, "typescript"); + expect(prompt).toContain("JSON"); + }); + }); + + describe("parseLanguageLessonResponse", () => { + it("parses a valid response", () => { + const response = JSON.stringify({ + languageNotes: "This function uses async/await for non-blocking JWT verification.", + concepts: [ + { name: "async/await", explanation: "TypeScript's way of handling asynchronous operations." }, + ], + }); + const result = parseLanguageLessonResponse(response); + expect(result.languageNotes).toContain("async/await"); + expect(result.concepts).toHaveLength(1); + }); + + it("extracts JSON from code blocks", () => { + const response = "```json\n" + JSON.stringify({ + languageNotes: "Uses generics.", + concepts: [], + }) + "\n```"; + const result = parseLanguageLessonResponse(response); + expect(result.languageNotes).toContain("generics"); + }); + + it("returns empty result for invalid response", () => { + const result = parseLanguageLessonResponse("not json"); + expect(result.languageNotes).toBe(""); + expect(result.concepts).toEqual([]); + }); + }); + + describe("detectLanguageConcepts", () => { + it("detects async patterns from tags", () => { + const concepts = detectLanguageConcepts(sampleNode, "typescript"); + expect(concepts).toContain("async/await"); + }); + + it("detects middleware pattern", () => { + const node: GraphNode = { + ...sampleNode, + tags: ["middleware", "express"], + summary: "Express middleware that validates requests", + }; + const concepts = detectLanguageConcepts(node, "typescript"); + expect(concepts).toContain("middleware pattern"); + }); + + it("returns empty for nodes with no detectable concepts", () => { + const node: GraphNode = { + ...sampleNode, + tags: ["config"], + summary: "Simple configuration file", + }; + const concepts = detectLanguageConcepts(node, "typescript"); + expect(concepts.length).toBeLessThanOrEqual(1); + }); + }); +}); +``` + +**Step 2: Run tests to verify they fail** + +```bash +cd packages/core && pnpm test -- --reporter verbose src/__tests__/language-lesson.test.ts +``` + +**Step 3: Implement language-lesson.ts** + +```typescript +// packages/core/src/analyzer/language-lesson.ts +import type { GraphNode, GraphEdge } from "../types.js"; + +export interface LanguageLessonResult { + languageNotes: string; + concepts: Array<{ name: string; explanation: string }>; +} + +// Concept detection patterns — maps keywords/tags to concept names +const CONCEPT_PATTERNS: Record = { + "async/await": ["async", "await", "promise", "asynchronous"], + "middleware pattern": ["middleware", "interceptor", "pipe"], + "generics": ["generic", "type parameter", "template"], + "decorators": ["decorator", "@", "annotation"], + "dependency injection": ["inject", "provider", "container", "di"], + "observer pattern": ["subscribe", "publish", "event", "observable", "listener"], + "singleton": ["singleton", "instance", "shared client"], + "type guards": ["type guard", "is", "narrowing", "discriminated union"], + "higher-order functions": ["callback", "factory", "higher-order", "closure"], + "error handling": ["try/catch", "error boundary", "exception", "Result type"], + "streams": ["stream", "pipe", "transform", "readable", "writable"], + "concurrency": ["goroutine", "channel", "thread", "worker", "mutex"], +}; + +/** + * Detect language concepts likely used in a node based on tags and summary. + */ +export function detectLanguageConcepts(node: GraphNode, language: string): string[] { + const text = [ + ...node.tags, + node.summary.toLowerCase(), + node.languageNotes?.toLowerCase() ?? "", + ].join(" "); + + const detected: string[] = []; + for (const [concept, keywords] of Object.entries(CONCEPT_PATTERNS)) { + if (keywords.some((kw) => text.includes(kw))) { + detected.push(concept); + } + } + + return detected; +} + +/** + * Build an LLM prompt to generate language-specific lessons for a node. + */ +export function buildLanguageLessonPrompt( + node: GraphNode, + edges: GraphEdge[], + language: string, +): string { + const capitalLang = language.charAt(0).toUpperCase() + language.slice(1); + const detectedConcepts = detectLanguageConcepts(node, language); + + const edgeContext = edges + .map((e) => { + const dir = e.source === node.id ? "->" : "<-"; + const other = e.source === node.id ? e.target : e.source; + return ` ${dir} [${e.type}] ${other}`; + }) + .join("\n"); + + return [ + `You are a programming teacher. Explain the ${capitalLang} concepts used in this code component.`, + `The reader may not know ${capitalLang} — explain concepts as if teaching them for the first time,`, + `but in the context of THIS specific code, not abstractly.`, + ``, + `## Component`, + `- Name: ${node.name}`, + `- Type: ${node.type}`, + `- File: ${node.filePath ?? "N/A"}`, + `- Summary: ${node.summary}`, + `- Tags: ${node.tags.join(", ")}`, + ``, + `## Relationships`, + edgeContext || " none", + ``, + detectedConcepts.length > 0 + ? `## Detected Concepts (explain these)\n${detectedConcepts.map((c) => `- ${c}`).join("\n")}` + : `## Note\nIdentify and explain any ${capitalLang}-specific patterns used in this component.`, + ``, + `Return JSON:`, + `\`\`\`json`, + `{`, + ` "languageNotes": "2-3 sentence summary of language concepts used here",`, + ` "concepts": [`, + ` { "name": "concept name", "explanation": "1-2 sentence explanation in context of this code" }`, + ` ]`, + `}`, + `\`\`\``, + ].join("\n"); +} + +/** + * Parse the LLM response into a LanguageLessonResult. + */ +export function parseLanguageLessonResponse(response: string): LanguageLessonResult { + let json = response; + const codeBlockMatch = response.match(/```(?:json)?\s*\n?([\s\S]*?)\n?```/); + if (codeBlockMatch) { + json = codeBlockMatch[1]; + } + + try { + const parsed = JSON.parse(json); + return { + languageNotes: typeof parsed.languageNotes === "string" ? parsed.languageNotes : "", + concepts: Array.isArray(parsed.concepts) + ? parsed.concepts.filter( + (c: unknown): c is { name: string; explanation: string } => + typeof c === "object" && + c !== null && + typeof (c as Record).name === "string" && + typeof (c as Record).explanation === "string", + ) + : [], + }; + } catch { + return { languageNotes: "", concepts: [] }; + } +} +``` + +**Step 4: Run tests** + +```bash +cd packages/core && pnpm test -- --reporter verbose src/__tests__/language-lesson.test.ts +``` + +**Step 5: Add exports to index.ts** + +```typescript +export { + buildLanguageLessonPrompt, + parseLanguageLessonResponse, + detectLanguageConcepts, + type LanguageLessonResult, +} from "./analyzer/language-lesson.js"; +``` + +**Step 6: Build + full test suite** + +```bash +cd packages/core && pnpm build && pnpm test +``` + +**Step 7: Commit** + +```bash +git add packages/core/src/analyzer/language-lesson.ts packages/core/src/__tests__/language-lesson.test.ts packages/core/src/index.ts +git commit -m "feat(core): add language lesson prompt builder and concept detector" +``` + +--- + +## Task 6: Enhanced Language Lesson Display (Dashboard) + +**Files:** +- Modify: `packages/dashboard/src/components/NodeInfo.tsx` (enhanced languageNotes display) +- Modify: `packages/dashboard/src/components/LearnPanel.tsx` (rich language lesson in tour) + +**Context:** The `languageNotes` field on nodes and `languageLesson` on tour steps already exist in the data. NodeInfo currently shows `languageNotes` as plain text in a blue box. This task upgrades both displays: NodeInfo gets a collapsible "Language Concepts" section with detected concept pills, and LearnPanel's language lesson section gets a more structured layout with concept cards. + +**Step 1: Enhance NodeInfo languageNotes display** + +Replace the existing `languageNotes` section in `packages/dashboard/src/components/NodeInfo.tsx` with: + +```tsx +{node.languageNotes && ( +
+ + {languageExpanded && ( +
+

+ {node.languageNotes} +

+
+ )} +
+)} +``` + +Add `const [languageExpanded, setLanguageExpanded] = useState(true);` at the top of the component. + +**Step 2: Enhance LearnPanel language lesson display** + +The `languageLesson` section in LearnPanel is already created in Task 2. Make sure it matches this enhanced styling with an icon and visual distinction. No changes needed if Task 2 was implemented correctly. + +**Step 3: Verify dashboard compiles** + +```bash +cd packages/dashboard && pnpm build +``` + +**Step 4: Commit** + +```bash +git add packages/dashboard/src/components/NodeInfo.tsx packages/dashboard/src/components/LearnPanel.tsx +git commit -m "feat(dashboard): enhance language lesson display with collapsible sections" +``` + +--- + +## Task 7: Persona Mode System (Dashboard) + +**Files:** +- Create: `packages/dashboard/src/components/PersonaSelector.tsx` +- Modify: `packages/dashboard/src/store.ts` (add persona state) +- Modify: `packages/dashboard/src/App.tsx` (persona-adaptive layout) +- Modify: `packages/dashboard/src/components/GraphView.tsx` (filter nodes by persona) + +**Context:** The design doc specifies three persona modes that change what the dashboard shows. This is the largest task in Phase 3, as it affects the layout, node filtering, and panel visibility. The three modes are: + +1. **Non-technical** — Hide CodeViewer, show only concept + module nodes in graph, expand LearnPanel to full right side. For PMs, designers, stakeholders. +2. **Junior dev** — Full 4-panel layout with LearnPanel prominent (instead of NodeInfo). Show all nodes with complexity indicators. For developers learning the codebase. +3. **Experienced dev** — Full 4-panel layout with CodeViewer and ChatPanel prominent, NodeInfo instead of LearnPanel. For senior devs doing deep dives. + +**Step 1: Add persona state to the store** + +In `packages/dashboard/src/store.ts`: + +```typescript +// Add to interface +persona: "non-technical" | "junior" | "experienced"; +setPersona: (persona: "non-technical" | "junior" | "experienced") => void; + +// Add to implementation +persona: "junior", // sensible default +setPersona: (persona) => set({ persona }), +``` + +**Step 2: Create PersonaSelector component** + +```tsx +// packages/dashboard/src/components/PersonaSelector.tsx +import { useDashboardStore } from "../store"; + +const personas = [ + { + id: "non-technical" as const, + label: "Overview", + description: "High-level architecture view", + }, + { + id: "junior" as const, + label: "Learn", + description: "Full dashboard with guided learning", + }, + { + id: "experienced" as const, + label: "Deep Dive", + description: "Code-focused with chat", + }, +]; + +export default function PersonaSelector() { + const persona = useDashboardStore((s) => s.persona); + const setPersona = useDashboardStore((s) => s.setPersona); + + return ( +
+ {personas.map((p) => ( + + ))} +
+ ); +} +``` + +**Step 3: Add PersonaSelector to App.tsx header** + +Import `PersonaSelector` and add it to the header bar, between the project info and search. + +**Step 4: Make App.tsx layout persona-adaptive** + +The 4-panel grid changes based on persona: + +```tsx +const persona = useDashboardStore((s) => s.persona); +const tourActive = useDashboardStore((s) => s.tourActive); + +// Non-technical: 2-column layout (graph + learn panel, no code viewer) +// Junior: 4-panel with LearnPanel in bottom-right +// Experienced: 4-panel with NodeInfo in bottom-right + +{persona === "non-technical" ? ( +
+
+ +
+
+
+ +
+
+ +
+
+
+) : ( +
+
+ +
+
+ +
+
+ +
+
+ {persona === "junior" || tourActive ? : } +
+
+)} +``` + +**Step 5: Filter graph nodes by persona in GraphView** + +In `packages/dashboard/src/components/GraphView.tsx`, add persona-based node filtering: + +```typescript +const persona = useDashboardStore((s) => s.persona); + +// Inside the useMemo, after creating flowNodes: +const filteredGraphNodes = persona === "non-technical" + ? graph.nodes.filter((n) => n.type === "concept" || n.type === "module" || n.type === "file") + : graph.nodes; + +// Use filteredGraphNodes instead of graph.nodes for building flowNodes +``` + +For non-technical mode, only show concept, module, and file-level nodes (skip function/class for simplicity). Also filter edges to only include those where both source and target are in the filtered set. + +**Step 6: Verify dashboard compiles** + +```bash +cd packages/dashboard && pnpm build +``` + +**Step 7: Commit** + +```bash +git add packages/dashboard/src/components/PersonaSelector.tsx packages/dashboard/src/store.ts packages/dashboard/src/App.tsx packages/dashboard/src/components/GraphView.tsx +git commit -m "feat(dashboard): add persona mode system (Overview / Learn / Deep Dive)" +``` + +--- + +## Verification Checklist + +After all tasks are complete: + +1. `cd packages/core && pnpm build && pnpm test` — all tests pass (existing 92 + new ~20) +2. `cd packages/dashboard && pnpm build` — compiles without errors +3. `pnpm dev:dashboard` — tour works end-to-end with sample data: + - Start Tour button appears in bottom-right + - Steps navigate with Prev/Next + - Graph nodes highlight per step + - Language lessons display in tour steps +4. Persona selector in header switches layouts correctly: + - Non-technical: 2-column, no CodeViewer, only high-level nodes + - Junior/Learn: 4-panel with LearnPanel + - Experienced/Deep Dive: 4-panel with NodeInfo +5. "Explain This" button on NodeInfo generates contextual explanation via Claude API +6. All existing Phase 1 + Phase 2 features still work (search, chat, layers, dagre layout) diff --git a/Understand-Anything-main/docs/superpowers/plans/2026-03-14-phase4-implementation.md b/Understand-Anything-main/docs/superpowers/plans/2026-03-14-phase4-implementation.md new file mode 100644 index 0000000..5c0837c --- /dev/null +++ b/Understand-Anything-main/docs/superpowers/plans/2026-03-14-phase4-implementation.md @@ -0,0 +1,1872 @@ +# Understand Anything — Phase 4 (Advanced) Implementation Plan + +> **For Claude:** REQUIRED SUB-SKILL: Use superpowers:executing-plans to implement this plan task-by-task. + +**Goal:** Add the "Advanced" layer — three new skill commands (`/understand-diff`, `/understand-explain`, `/understand-onboard`), a community plugin system, and optional embedding-based semantic search. + +**Architecture:** Extends the skill package with three new Claude Code skill definitions + supporting core utilities. Adds a plugin registry to core for community extensibility. Optionally adds embedding-based search as an upgrade path from the existing fuse.js search. + +**Tech Stack:** No new dependencies for Tasks 1-5. Task 6-7 (embedding search) adds a vector similarity library or uses raw cosine calculation. + +--- + +## Dependency Graph + +``` +Task 1 (understand-diff) ─── (independent) +Task 2 (understand-explain) ─── (independent) +Task 3 (understand-onboard) ─── (independent) +Task 4 (Plugin Registry Core) ───→ Task 5 (Plugin CLI Integration) +Task 6 (Embedding Search Core) ───→ Task 7 (Embedding Dashboard) +``` + +Tasks 1, 2, 3, 4, 6 are fully independent and can be implemented in any order. + +--- + +## Task 1: /understand-diff Skill — PR/Diff Analysis + +**Files:** +- Create: `packages/skill/src/diff-analyzer.ts` +- Create: `packages/skill/src/__tests__/diff-analyzer.test.ts` +- Create: `packages/skill/.claude/skills/understand-diff.md` +- Modify: `packages/skill/src/index.ts` (add exports) + +**Context:** The `/understand-diff` skill analyzes the current git diff (or PR) against the knowledge graph. It maps changed files to affected nodes, identifies impacted relationships and layers, and generates a structured analysis of changes, affected areas, and risks. This is designed to run inside Claude Code where the LLM can read the analysis and explain it to the user. + +**Step 1: Write failing tests** + +```typescript +// packages/skill/src/__tests__/diff-analyzer.test.ts +import { describe, it, expect } from "vitest"; +import { buildDiffContext, formatDiffAnalysis } from "../diff-analyzer.js"; +import type { KnowledgeGraph } from "@understand-anything/core"; + +const sampleGraph: KnowledgeGraph = { + version: "1.0.0", + project: { + name: "test-project", + languages: ["typescript"], + frameworks: ["express"], + description: "A test project", + analyzedAt: "2026-03-14T00:00:00Z", + gitCommitHash: "abc123", + }, + nodes: [ + { id: "file:src/index.ts", type: "file", name: "index.ts", filePath: "src/index.ts", summary: "Entry point", tags: ["entry"], complexity: "simple" }, + { id: "file:src/routes.ts", type: "file", name: "routes.ts", filePath: "src/routes.ts", summary: "Routes", tags: ["routes"], complexity: "moderate" }, + { id: "file:src/service.ts", type: "file", name: "service.ts", filePath: "src/service.ts", summary: "Service", tags: ["service"], complexity: "complex" }, + { id: "func:src/service.ts:process", type: "function", name: "process", filePath: "src/service.ts", lineRange: [10, 30], summary: "Process function", tags: ["core"], complexity: "complex" }, + { id: "file:src/db.ts", type: "file", name: "db.ts", filePath: "src/db.ts", summary: "Database", tags: ["db"], complexity: "simple" }, + ], + edges: [ + { source: "file:src/index.ts", target: "file:src/routes.ts", type: "imports", direction: "forward", weight: 0.9 }, + { source: "file:src/routes.ts", target: "file:src/service.ts", type: "calls", direction: "forward", weight: 0.8 }, + { source: "file:src/service.ts", target: "func:src/service.ts:process", type: "contains", direction: "forward", weight: 1.0 }, + { source: "file:src/service.ts", target: "file:src/db.ts", type: "reads_from", direction: "forward", weight: 0.7 }, + ], + layers: [ + { id: "layer:api", name: "API Layer", description: "HTTP routes", nodeIds: ["file:src/index.ts", "file:src/routes.ts"] }, + { id: "layer:service", name: "Service Layer", description: "Business logic", nodeIds: ["file:src/service.ts", "func:src/service.ts:process"] }, + { id: "layer:data", name: "Data Layer", description: "Database", nodeIds: ["file:src/db.ts"] }, + ], + tour: [], +}; + +describe("diff-analyzer", () => { + describe("buildDiffContext", () => { + it("identifies directly changed nodes", () => { + const ctx = buildDiffContext(sampleGraph, ["src/service.ts"]); + expect(ctx.changedNodes.map((n) => n.id)).toContain("file:src/service.ts"); + }); + + it("identifies child nodes of changed files", () => { + const ctx = buildDiffContext(sampleGraph, ["src/service.ts"]); + expect(ctx.changedNodes.map((n) => n.id)).toContain("func:src/service.ts:process"); + }); + + it("identifies affected nodes via edges (1-hop)", () => { + const ctx = buildDiffContext(sampleGraph, ["src/service.ts"]); + // routes.ts calls service.ts, so it's affected + expect(ctx.affectedNodes.map((n) => n.id)).toContain("file:src/routes.ts"); + // db.ts is read by service.ts, so it's affected + expect(ctx.affectedNodes.map((n) => n.id)).toContain("file:src/db.ts"); + }); + + it("identifies affected layers", () => { + const ctx = buildDiffContext(sampleGraph, ["src/service.ts"]); + expect(ctx.affectedLayers.map((l) => l.name)).toContain("Service Layer"); + }); + + it("identifies impacted edges", () => { + const ctx = buildDiffContext(sampleGraph, ["src/service.ts"]); + expect(ctx.impactedEdges.length).toBeGreaterThan(0); + }); + + it("handles files not in the graph gracefully", () => { + const ctx = buildDiffContext(sampleGraph, ["src/unknown.ts"]); + expect(ctx.changedNodes).toHaveLength(0); + expect(ctx.unmappedFiles).toContain("src/unknown.ts"); + }); + + it("handles empty diff", () => { + const ctx = buildDiffContext(sampleGraph, []); + expect(ctx.changedNodes).toHaveLength(0); + expect(ctx.affectedNodes).toHaveLength(0); + }); + + it("de-duplicates affected nodes (not in changed set)", () => { + const ctx = buildDiffContext(sampleGraph, ["src/service.ts"]); + const changedIds = new Set(ctx.changedNodes.map((n) => n.id)); + for (const affected of ctx.affectedNodes) { + expect(changedIds.has(affected.id)).toBe(false); + } + }); + }); + + describe("formatDiffAnalysis", () => { + it("produces structured markdown", () => { + const ctx = buildDiffContext(sampleGraph, ["src/service.ts"]); + const analysis = formatDiffAnalysis(ctx); + expect(analysis).toContain("## Changed Components"); + expect(analysis).toContain("## Affected Components"); + expect(analysis).toContain("## Affected Layers"); + }); + + it("includes risk assessment section", () => { + const ctx = buildDiffContext(sampleGraph, ["src/service.ts"]); + const analysis = formatDiffAnalysis(ctx); + expect(analysis).toContain("## Risk Assessment"); + }); + + it("lists unmapped files when present", () => { + const ctx = buildDiffContext(sampleGraph, ["src/unknown.ts"]); + const analysis = formatDiffAnalysis(ctx); + expect(analysis).toContain("src/unknown.ts"); + }); + }); +}); +``` + +**Step 2: Run tests to verify they fail** + +```bash +cd packages/skill && pnpm test -- --reporter verbose src/__tests__/diff-analyzer.test.ts +``` + +**Step 3: Implement diff-analyzer.ts** + +```typescript +// packages/skill/src/diff-analyzer.ts +import type { KnowledgeGraph, GraphNode, GraphEdge, Layer } from "@understand-anything/core"; + +export interface DiffContext { + projectName: string; + changedFiles: string[]; + changedNodes: GraphNode[]; + affectedNodes: GraphNode[]; + impactedEdges: GraphEdge[]; + affectedLayers: Layer[]; + unmappedFiles: string[]; +} + +/** + * Map a list of changed file paths to knowledge graph nodes and + * identify the ripple effect (affected nodes, layers, edges). + */ +export function buildDiffContext( + graph: KnowledgeGraph, + changedFiles: string[], +): DiffContext { + const { nodes, edges, layers } = graph; + + // Map files to directly changed nodes + const changedNodeIds = new Set(); + const unmappedFiles: string[] = []; + + for (const file of changedFiles) { + let mapped = false; + for (const node of nodes) { + if (node.filePath === file) { + changedNodeIds.add(node.id); + mapped = true; + } + } + if (!mapped) { + unmappedFiles.push(file); + } + } + + // Also include "contains" children of changed file nodes + for (const edge of edges) { + if (edge.type === "contains" && changedNodeIds.has(edge.source)) { + changedNodeIds.add(edge.target); + } + } + + const changedNodes = nodes.filter((n) => changedNodeIds.has(n.id)); + + // Find affected nodes: 1-hop neighbors of changed nodes (excluding already changed) + const affectedNodeIds = new Set(); + const impactedEdges: GraphEdge[] = []; + + for (const edge of edges) { + const sourceChanged = changedNodeIds.has(edge.source); + const targetChanged = changedNodeIds.has(edge.target); + + if (sourceChanged || targetChanged) { + impactedEdges.push(edge); + if (sourceChanged && !changedNodeIds.has(edge.target)) { + affectedNodeIds.add(edge.target); + } + if (targetChanged && !changedNodeIds.has(edge.source)) { + affectedNodeIds.add(edge.source); + } + } + } + + const affectedNodes = nodes.filter((n) => affectedNodeIds.has(n.id)); + + // Find affected layers: any layer containing a changed or affected node + const allImpactedIds = new Set([...changedNodeIds, ...affectedNodeIds]); + const affectedLayers = layers.filter((layer) => + layer.nodeIds.some((id) => allImpactedIds.has(id)), + ); + + return { + projectName: graph.project.name, + changedFiles, + changedNodes, + affectedNodes, + impactedEdges, + affectedLayers, + unmappedFiles, + }; +} + +/** + * Format the diff analysis as structured markdown for LLM or human consumption. + */ +export function formatDiffAnalysis(ctx: DiffContext): string { + const lines: string[] = []; + + lines.push(`# Diff Analysis: ${ctx.projectName}`); + lines.push(""); + + // Changed components + lines.push("## Changed Components"); + lines.push(""); + if (ctx.changedNodes.length === 0) { + lines.push("No mapped components found for changed files."); + } else { + for (const node of ctx.changedNodes) { + lines.push(`- **${node.name}** (${node.type}) — ${node.summary}`); + if (node.filePath) lines.push(` - File: \`${node.filePath}\``); + lines.push(` - Complexity: ${node.complexity}`); + } + } + lines.push(""); + + // Affected components (ripple effect) + lines.push("## Affected Components"); + lines.push(""); + if (ctx.affectedNodes.length === 0) { + lines.push("No downstream impact detected."); + } else { + lines.push("These components are connected to changed code and may need attention:"); + lines.push(""); + for (const node of ctx.affectedNodes) { + lines.push(`- **${node.name}** (${node.type}) — ${node.summary}`); + } + } + lines.push(""); + + // Affected layers + lines.push("## Affected Layers"); + lines.push(""); + if (ctx.affectedLayers.length === 0) { + lines.push("No layers affected."); + } else { + for (const layer of ctx.affectedLayers) { + lines.push(`- **${layer.name}**: ${layer.description}`); + } + } + lines.push(""); + + // Impacted relationships + if (ctx.impactedEdges.length > 0) { + lines.push("## Impacted Relationships"); + lines.push(""); + for (const edge of ctx.impactedEdges) { + lines.push(`- ${edge.source} --[${edge.type}]--> ${edge.target}`); + } + lines.push(""); + } + + // Unmapped files + if (ctx.unmappedFiles.length > 0) { + lines.push("## Unmapped Files"); + lines.push(""); + lines.push("These changed files are not yet in the knowledge graph:"); + lines.push(""); + for (const f of ctx.unmappedFiles) { + lines.push(`- \`${f}\``); + } + lines.push(""); + } + + // Risk assessment + lines.push("## Risk Assessment"); + lines.push(""); + const complexChanges = ctx.changedNodes.filter((n) => n.complexity === "complex"); + const crossLayerCount = new Set(ctx.affectedLayers.map((l) => l.id)).size; + + if (complexChanges.length > 0) { + lines.push(`- **High complexity**: ${complexChanges.length} complex component(s) changed: ${complexChanges.map((n) => n.name).join(", ")}`); + } + if (crossLayerCount > 1) { + lines.push(`- **Cross-layer impact**: Changes span ${crossLayerCount} architectural layers`); + } + if (ctx.affectedNodes.length > 5) { + lines.push(`- **Wide blast radius**: ${ctx.affectedNodes.length} components affected downstream`); + } + if (ctx.unmappedFiles.length > 0) { + lines.push(`- **New/unmapped files**: ${ctx.unmappedFiles.length} files not in the knowledge graph (may need re-analysis)`); + } + if (complexChanges.length === 0 && crossLayerCount <= 1 && ctx.affectedNodes.length <= 5 && ctx.unmappedFiles.length === 0) { + lines.push("- **Low risk**: Changes are localized with limited downstream impact."); + } + lines.push(""); + + return lines.join("\n"); +} +``` + +**Step 4: Run tests** + +```bash +cd packages/skill && pnpm test -- --reporter verbose src/__tests__/diff-analyzer.test.ts +``` + +**Step 5: Add exports to index.ts** + +```typescript +export { + buildDiffContext, + formatDiffAnalysis, + type DiffContext, +} from "./diff-analyzer.js"; +``` + +**Step 6: Create the skill definition** + +```markdown + +--- +name: understand-diff +description: Analyze current git diff or PR against the knowledge graph to identify changes, impact, and risks +--- + +# /understand-diff + +Analyze the current code changes against the knowledge graph at `.understand-anything/knowledge-graph.json`. + +## Instructions + +1. Read the knowledge graph file at `.understand-anything/knowledge-graph.json` in the current project root +2. If the file doesn't exist, tell the user to run `/understand` first +3. Get the current diff: + - If on a branch with uncommitted changes: `git diff --name-only` + - If on a feature branch: `git diff main...HEAD --name-only` (or the base branch) + - If the user specifies a PR number: get the diff from that PR +4. For each changed file, identify: + - Which nodes in the knowledge graph correspond to that file + - Which other nodes are connected (imports, calls, depends_on, etc.) + - Which architectural layers are affected +5. Provide a structured analysis: + - **Changed Components**: What was directly modified + - **Affected Components**: What might be impacted by the changes + - **Affected Layers**: Which architectural layers are touched + - **Risk Assessment**: Complexity, cross-layer impact, blast radius +6. Suggest what to review carefully and any potential issues +``` + +**Step 7: Build + test** + +```bash +cd packages/skill && pnpm build && pnpm test +``` + +**Step 8: Commit** + +```bash +git add packages/skill/src/diff-analyzer.ts packages/skill/src/__tests__/diff-analyzer.test.ts packages/skill/src/index.ts packages/skill/.claude/skills/understand-diff.md +git commit -m "feat(skill): add /understand-diff command for PR/diff analysis" +``` + +--- + +## Task 2: /understand-explain Skill — Deep-Dive on Files + +**Files:** +- Create: `packages/skill/src/explain-builder.ts` +- Create: `packages/skill/src/__tests__/explain-builder.test.ts` +- Create: `packages/skill/.claude/skills/understand-explain.md` +- Modify: `packages/skill/src/index.ts` (add exports) + +**Context:** The `/understand-explain ` skill provides a deep-dive explanation of a specific file or function. It gathers all nodes that belong to that file, their connections, layer membership, and constructs a comprehensive context for the LLM to explain the component. This differs from `/understand-chat` which answers any question — `/understand-explain` is focused on thorough explanation of a single component. + +**Step 1: Write failing tests** + +```typescript +// packages/skill/src/__tests__/explain-builder.test.ts +import { describe, it, expect } from "vitest"; +import { buildExplainContext, formatExplainPrompt } from "../explain-builder.js"; +import type { KnowledgeGraph } from "@understand-anything/core"; + +const sampleGraph: KnowledgeGraph = { + version: "1.0.0", + project: { + name: "test-project", + languages: ["typescript"], + frameworks: ["express"], + description: "A test project", + analyzedAt: "2026-03-14T00:00:00Z", + gitCommitHash: "abc123", + }, + nodes: [ + { id: "file:src/auth.ts", type: "file", name: "auth.ts", filePath: "src/auth.ts", summary: "Auth module", tags: ["auth"], complexity: "complex" }, + { id: "func:src/auth.ts:login", type: "function", name: "login", filePath: "src/auth.ts", lineRange: [10, 30], summary: "Login handler", tags: ["auth", "login"], complexity: "moderate" }, + { id: "func:src/auth.ts:verify", type: "function", name: "verify", filePath: "src/auth.ts", lineRange: [32, 50], summary: "Token verification", tags: ["auth", "jwt"], complexity: "moderate" }, + { id: "file:src/db.ts", type: "file", name: "db.ts", filePath: "src/db.ts", summary: "Database", tags: ["db"], complexity: "simple" }, + ], + edges: [ + { source: "file:src/auth.ts", target: "func:src/auth.ts:login", type: "contains", direction: "forward", weight: 1.0 }, + { source: "file:src/auth.ts", target: "func:src/auth.ts:verify", type: "contains", direction: "forward", weight: 1.0 }, + { source: "func:src/auth.ts:login", target: "file:src/db.ts", type: "reads_from", direction: "forward", weight: 0.8 }, + ], + layers: [ + { id: "layer:auth", name: "Auth Layer", description: "Authentication", nodeIds: ["file:src/auth.ts", "func:src/auth.ts:login", "func:src/auth.ts:verify"] }, + ], + tour: [], +}; + +describe("explain-builder", () => { + describe("buildExplainContext", () => { + it("finds the file node by path", () => { + const ctx = buildExplainContext(sampleGraph, "src/auth.ts"); + expect(ctx.targetNode?.id).toBe("file:src/auth.ts"); + }); + + it("includes child nodes (functions/classes in the file)", () => { + const ctx = buildExplainContext(sampleGraph, "src/auth.ts"); + expect(ctx.childNodes.map((n) => n.name)).toContain("login"); + expect(ctx.childNodes.map((n) => n.name)).toContain("verify"); + }); + + it("includes connected nodes", () => { + const ctx = buildExplainContext(sampleGraph, "src/auth.ts"); + const allIds = ctx.connectedNodes.map((n) => n.id); + expect(allIds).toContain("file:src/db.ts"); + }); + + it("includes the layer", () => { + const ctx = buildExplainContext(sampleGraph, "src/auth.ts"); + expect(ctx.layer?.name).toBe("Auth Layer"); + }); + + it("returns null targetNode for unknown paths", () => { + const ctx = buildExplainContext(sampleGraph, "src/unknown.ts"); + expect(ctx.targetNode).toBeNull(); + }); + + it("finds function nodes by partial path match", () => { + const ctx = buildExplainContext(sampleGraph, "src/auth.ts:login"); + expect(ctx.targetNode?.name).toBe("login"); + }); + }); + + describe("formatExplainPrompt", () => { + it("produces structured markdown for valid context", () => { + const ctx = buildExplainContext(sampleGraph, "src/auth.ts"); + const prompt = formatExplainPrompt(ctx); + expect(prompt).toContain("auth.ts"); + expect(prompt).toContain("login"); + expect(prompt).toContain("Auth Layer"); + }); + + it("produces helpful message for unknown path", () => { + const ctx = buildExplainContext(sampleGraph, "src/unknown.ts"); + const prompt = formatExplainPrompt(ctx); + expect(prompt).toContain("not found"); + }); + }); +}); +``` + +**Step 2: Run tests to verify they fail** + +```bash +cd packages/skill && pnpm test -- --reporter verbose src/__tests__/explain-builder.test.ts +``` + +**Step 3: Implement explain-builder.ts** + +```typescript +// packages/skill/src/explain-builder.ts +import type { KnowledgeGraph, GraphNode, GraphEdge, Layer } from "@understand-anything/core"; + +export interface ExplainContext { + projectName: string; + path: string; + targetNode: GraphNode | null; + childNodes: GraphNode[]; + connectedNodes: GraphNode[]; + relevantEdges: GraphEdge[]; + layer: Layer | null; +} + +/** + * Build a context for explaining a specific file or function. + * Supports file paths ("src/auth.ts") and path:function ("src/auth.ts:login"). + */ +export function buildExplainContext( + graph: KnowledgeGraph, + path: string, +): ExplainContext { + const { nodes, edges, layers } = graph; + + // Try exact filePath match first, then name-based matching + let targetNode: GraphNode | null = null; + + // Check for path:function format + const colonIdx = path.lastIndexOf(":"); + if (colonIdx > 0 && !path.includes("://")) { + const filePath = path.slice(0, colonIdx); + const funcName = path.slice(colonIdx + 1); + targetNode = nodes.find( + (n) => n.filePath === filePath && n.name === funcName, + ) ?? null; + } + + // Fall back to file path match + if (!targetNode) { + targetNode = nodes.find((n) => n.filePath === path) ?? null; + } + + if (!targetNode) { + return { + projectName: graph.project.name, + path, + targetNode: null, + childNodes: [], + connectedNodes: [], + relevantEdges: [], + layer: null, + }; + } + + // Find child nodes (contained by this node) + const childNodes = nodes.filter((n) => + edges.some( + (e) => e.source === targetNode!.id && e.target === n.id && e.type === "contains", + ), + ); + + // Also include children of children (e.g., file → class → methods) + const allRelatedIds = new Set([targetNode.id, ...childNodes.map((n) => n.id)]); + + // Find connected nodes (1-hop, excluding children) + const connectedIds = new Set(); + const relevantEdges: GraphEdge[] = []; + + for (const edge of edges) { + if (allRelatedIds.has(edge.source) || allRelatedIds.has(edge.target)) { + relevantEdges.push(edge); + if (allRelatedIds.has(edge.source) && !allRelatedIds.has(edge.target)) { + connectedIds.add(edge.target); + } + if (allRelatedIds.has(edge.target) && !allRelatedIds.has(edge.source)) { + connectedIds.add(edge.source); + } + } + } + + const connectedNodes = nodes.filter((n) => connectedIds.has(n.id)); + + // Find layer + const layer = layers.find((l) => l.nodeIds.includes(targetNode!.id)) ?? null; + + return { + projectName: graph.project.name, + path, + targetNode, + childNodes, + connectedNodes, + relevantEdges, + layer, + }; +} + +/** + * Format the explain context as a structured prompt for LLM consumption. + */ +export function formatExplainPrompt(ctx: ExplainContext): string { + if (!ctx.targetNode) { + return [ + `# Component Not Found`, + ``, + `The path "${ctx.path}" was not found in the knowledge graph for ${ctx.projectName}.`, + ``, + `Possible reasons:`, + `- The file hasn't been analyzed yet — try running /understand first`, + `- The path may be different in the graph — check the exact file path`, + `- The file may have been deleted or renamed since the last analysis`, + ].join("\n"); + } + + const { targetNode, childNodes, connectedNodes, relevantEdges, layer } = ctx; + const lines: string[] = []; + + lines.push(`# Deep Dive: ${targetNode.name}`); + lines.push(""); + lines.push(`**Type:** ${targetNode.type} | **Complexity:** ${targetNode.complexity}`); + if (targetNode.filePath) lines.push(`**File:** \`${targetNode.filePath}\``); + if (targetNode.lineRange) lines.push(`**Lines:** ${targetNode.lineRange[0]}-${targetNode.lineRange[1]}`); + lines.push(""); + lines.push(`**Summary:** ${targetNode.summary}`); + lines.push(""); + + if (layer) { + lines.push(`## Architectural Layer: ${layer.name}`); + lines.push(layer.description); + lines.push(""); + } + + if (childNodes.length > 0) { + lines.push("## Internal Components"); + for (const child of childNodes) { + lines.push(`- **${child.name}** (${child.type}): ${child.summary}`); + } + lines.push(""); + } + + if (connectedNodes.length > 0) { + lines.push("## Connected Components"); + for (const node of connectedNodes) { + lines.push(`- **${node.name}** (${node.type}): ${node.summary}`); + } + lines.push(""); + } + + if (relevantEdges.length > 0) { + const nodeMap = new Map( + [...[targetNode], ...childNodes, ...connectedNodes].map((n) => [n.id, n]), + ); + lines.push("## Relationships"); + for (const edge of relevantEdges) { + if (edge.type === "contains") continue; // skip containment (shown above) + const src = nodeMap.get(edge.source)?.name ?? edge.source; + const tgt = nodeMap.get(edge.target)?.name ?? edge.target; + const desc = edge.description ? ` — ${edge.description}` : ""; + lines.push(`- ${src} --[${edge.type}]--> ${tgt}${desc}`); + } + lines.push(""); + } + + if (targetNode.languageNotes) { + lines.push("## Language Notes"); + lines.push(targetNode.languageNotes); + lines.push(""); + } + + lines.push("## Instructions"); + lines.push("Provide a thorough explanation of this component:"); + lines.push("1. What it does and why it exists in the project"); + lines.push("2. How data flows through it (inputs, processing, outputs)"); + lines.push("3. How it interacts with connected components"); + lines.push("4. Any patterns, idioms, or design decisions worth noting"); + lines.push("5. Potential gotchas or areas of complexity"); + lines.push(""); + + return lines.join("\n"); +} +``` + +**Step 4: Run tests** + +```bash +cd packages/skill && pnpm test -- --reporter verbose src/__tests__/explain-builder.test.ts +``` + +**Step 5: Add exports + create skill definition** + +Add to `packages/skill/src/index.ts`: +```typescript +export { + buildExplainContext, + formatExplainPrompt, + type ExplainContext, +} from "./explain-builder.js"; +``` + +Create `packages/skill/.claude/skills/understand-explain.md`: +```markdown +--- +name: understand-explain +description: Deep-dive explanation of a specific file or function using the knowledge graph +arguments: path +--- + +# /understand-explain + +Provide a thorough, in-depth explanation of a specific code component. + +## Instructions + +1. Read the knowledge graph file at `.understand-anything/knowledge-graph.json` +2. If it doesn't exist, tell the user to run `/understand` first +3. Find the component matching the path: "${ARGUMENTS}" + - Supports file paths: `src/auth/login.ts` + - Supports function notation: `src/auth/login.ts:verifyToken` +4. Analyze the component in context: + - Its role in the architecture (which layer, why it exists) + - Internal structure (functions, classes it contains) + - External connections (what it imports, what calls it, what it depends on) + - Data flow (inputs → processing → outputs) +5. Explain clearly, assuming the reader may not know the programming language +6. Highlight any patterns, idioms, or complexity worth understanding +``` + +**Step 6: Build + test** + +```bash +cd packages/skill && pnpm build && pnpm test +``` + +**Step 7: Commit** + +```bash +git add packages/skill/src/explain-builder.ts packages/skill/src/__tests__/explain-builder.test.ts packages/skill/src/index.ts packages/skill/.claude/skills/understand-explain.md +git commit -m "feat(skill): add /understand-explain command for deep-dive file analysis" +``` + +--- + +## Task 3: /understand-onboard Skill — Onboarding Guide Generation + +**Files:** +- Create: `packages/skill/src/onboard-builder.ts` +- Create: `packages/skill/src/__tests__/onboard-builder.test.ts` +- Create: `packages/skill/.claude/skills/understand-onboard.md` +- Modify: `packages/skill/src/index.ts` (add exports) + +**Context:** The `/understand-onboard` skill generates a structured onboarding guide for new team members. It synthesizes the knowledge graph — project overview, architecture layers, key concepts, tour steps, and complexity hotspots — into a comprehensive document. The output is a well-structured markdown guide that can be committed to the repo or shared in a wiki. + +**Step 1: Write failing tests** + +```typescript +// packages/skill/src/__tests__/onboard-builder.test.ts +import { describe, it, expect } from "vitest"; +import { buildOnboardingGuide } from "../onboard-builder.js"; +import type { KnowledgeGraph } from "@understand-anything/core"; + +const sampleGraph: KnowledgeGraph = { + version: "1.0.0", + project: { + name: "test-project", + languages: ["typescript", "python"], + frameworks: ["express", "prisma"], + description: "A test REST API", + analyzedAt: "2026-03-14T00:00:00Z", + gitCommitHash: "abc123", + }, + nodes: [ + { id: "file:src/index.ts", type: "file", name: "index.ts", filePath: "src/index.ts", summary: "Entry point", tags: ["entry"], complexity: "simple" }, + { id: "file:src/service.ts", type: "file", name: "service.ts", filePath: "src/service.ts", summary: "Core service", tags: ["service"], complexity: "complex" }, + { id: "concept:auth", type: "concept", name: "Auth Flow", summary: "JWT-based authentication", tags: ["concept", "auth"], complexity: "complex" }, + ], + edges: [ + { source: "file:src/index.ts", target: "file:src/service.ts", type: "imports", direction: "forward", weight: 0.8 }, + ], + layers: [ + { id: "layer:api", name: "API Layer", description: "Routes and handlers", nodeIds: ["file:src/index.ts"] }, + { id: "layer:service", name: "Service Layer", description: "Business logic", nodeIds: ["file:src/service.ts"] }, + ], + tour: [ + { order: 1, title: "Start Here", description: "Begin with index.ts", nodeIds: ["file:src/index.ts"] }, + { order: 2, title: "Core Logic", description: "Service layer", nodeIds: ["file:src/service.ts"] }, + ], +}; + +describe("onboard-builder", () => { + it("includes project overview section", () => { + const guide = buildOnboardingGuide(sampleGraph); + expect(guide).toContain("# test-project"); + expect(guide).toContain("A test REST API"); + }); + + it("lists languages and frameworks", () => { + const guide = buildOnboardingGuide(sampleGraph); + expect(guide).toContain("typescript"); + expect(guide).toContain("express"); + }); + + it("includes architecture layers section", () => { + const guide = buildOnboardingGuide(sampleGraph); + expect(guide).toContain("## Architecture"); + expect(guide).toContain("API Layer"); + expect(guide).toContain("Service Layer"); + }); + + it("includes key concepts section", () => { + const guide = buildOnboardingGuide(sampleGraph); + expect(guide).toContain("## Key Concepts"); + expect(guide).toContain("Auth Flow"); + }); + + it("includes getting started / tour section", () => { + const guide = buildOnboardingGuide(sampleGraph); + expect(guide).toContain("## Getting Started"); + expect(guide).toContain("Start Here"); + }); + + it("includes complexity hotspots", () => { + const guide = buildOnboardingGuide(sampleGraph); + expect(guide).toContain("## Complexity Hotspots"); + expect(guide).toContain("service.ts"); + }); + + it("includes file map section", () => { + const guide = buildOnboardingGuide(sampleGraph); + expect(guide).toContain("## File Map"); + }); + + it("handles graph with no layers gracefully", () => { + const noLayers = { ...sampleGraph, layers: [] }; + const guide = buildOnboardingGuide(noLayers); + expect(guide).toContain("# test-project"); + }); + + it("handles graph with no tour gracefully", () => { + const noTour = { ...sampleGraph, tour: [] }; + const guide = buildOnboardingGuide(noTour); + expect(guide).toContain("# test-project"); + }); +}); +``` + +**Step 2: Run tests to verify they fail** + +```bash +cd packages/skill && pnpm test -- --reporter verbose src/__tests__/onboard-builder.test.ts +``` + +**Step 3: Implement onboard-builder.ts** + +```typescript +// packages/skill/src/onboard-builder.ts +import type { KnowledgeGraph } from "@understand-anything/core"; + +/** + * Generate a structured onboarding guide from the knowledge graph. + * Output is standalone markdown suitable for a README, wiki, or docs. + */ +export function buildOnboardingGuide(graph: KnowledgeGraph): string { + const { project, nodes, edges, layers, tour } = graph; + const lines: string[] = []; + + // --- Project Overview --- + lines.push(`# ${project.name}`); + lines.push(""); + lines.push(`> ${project.description}`); + lines.push(""); + lines.push(`| | |`); + lines.push(`|---|---|`); + lines.push(`| **Languages** | ${project.languages.join(", ")} |`); + lines.push(`| **Frameworks** | ${project.frameworks.join(", ")} |`); + lines.push(`| **Components** | ${nodes.length} nodes, ${edges.length} relationships |`); + lines.push(`| **Last Analyzed** | ${project.analyzedAt} |`); + lines.push(""); + + // --- Architecture --- + if (layers.length > 0) { + lines.push("## Architecture"); + lines.push(""); + lines.push("The project is organized into the following layers:"); + lines.push(""); + for (const layer of layers) { + const memberNames = layer.nodeIds + .map((id) => nodes.find((n) => n.id === id)?.name) + .filter(Boolean); + lines.push(`### ${layer.name}`); + lines.push(""); + lines.push(layer.description); + lines.push(""); + if (memberNames.length > 0) { + lines.push(`Key components: ${memberNames.join(", ")}`); + lines.push(""); + } + } + } + + // --- Key Concepts --- + const conceptNodes = nodes.filter((n) => n.type === "concept"); + if (conceptNodes.length > 0) { + lines.push("## Key Concepts"); + lines.push(""); + lines.push("Important architectural and domain concepts to understand:"); + lines.push(""); + for (const concept of conceptNodes) { + lines.push(`### ${concept.name}`); + lines.push(""); + lines.push(concept.summary); + lines.push(""); + } + } + + // --- Getting Started (Tour) --- + if (tour.length > 0) { + lines.push("## Getting Started"); + lines.push(""); + lines.push("Follow this guided tour to understand the codebase:"); + lines.push(""); + for (const step of tour) { + const stepNodes = step.nodeIds + .map((id) => nodes.find((n) => n.id === id)) + .filter(Boolean); + lines.push(`### ${step.order}. ${step.title}`); + lines.push(""); + lines.push(step.description); + lines.push(""); + if (stepNodes.length > 0) { + lines.push("**Files to look at:**"); + for (const node of stepNodes) { + if (node!.filePath) { + lines.push(`- \`${node!.filePath}\` — ${node!.summary}`); + } + } + lines.push(""); + } + if (step.languageLesson) { + lines.push(`> **Language Tip:** ${step.languageLesson}`); + lines.push(""); + } + } + } + + // --- File Map --- + const fileNodes = nodes.filter((n) => n.type === "file" && n.filePath); + if (fileNodes.length > 0) { + lines.push("## File Map"); + lines.push(""); + lines.push("| File | Purpose | Complexity |"); + lines.push("|------|---------|------------|"); + for (const node of fileNodes) { + lines.push(`| \`${node.filePath}\` | ${node.summary} | ${node.complexity} |`); + } + lines.push(""); + } + + // --- Complexity Hotspots --- + const complexNodes = nodes.filter((n) => n.complexity === "complex"); + if (complexNodes.length > 0) { + lines.push("## Complexity Hotspots"); + lines.push(""); + lines.push("These components are the most complex and deserve extra attention:"); + lines.push(""); + for (const node of complexNodes) { + lines.push(`- **${node.name}** (${node.type}): ${node.summary}`); + } + lines.push(""); + } + + // --- Footer --- + lines.push("---"); + lines.push(""); + lines.push(`*Generated by [Understand Anything](https://github.com/anthropics/understand-anything) from knowledge graph v${graph.version}*`); + lines.push(""); + + return lines.join("\n"); +} +``` + +**Step 4: Run tests** + +```bash +cd packages/skill && pnpm test -- --reporter verbose src/__tests__/onboard-builder.test.ts +``` + +**Step 5: Add exports + create skill definition** + +Add to `packages/skill/src/index.ts`: +```typescript +export { buildOnboardingGuide } from "./onboard-builder.js"; +``` + +Create `packages/skill/.claude/skills/understand-onboard.md`: +```markdown +--- +name: understand-onboard +description: Generate a structured onboarding guide for new team members using the knowledge graph +--- + +# /understand-onboard + +Generate a comprehensive onboarding guide from the project's knowledge graph. + +## Instructions + +1. Read the knowledge graph at `.understand-anything/knowledge-graph.json` +2. If it doesn't exist, tell the user to run `/understand` first +3. Generate a structured onboarding guide that includes: + - Project overview (name, languages, frameworks, description) + - Architecture layers and their responsibilities + - Key concepts to understand + - Guided tour (step-by-step walkthrough) + - File map (what each key file does) + - Complexity hotspots (what to be careful with) +4. Format as clean markdown +5. Offer to save the guide to `docs/ONBOARDING.md` in the project +6. Suggest the user commit it to the repo for the team +``` + +**Step 6: Build + test** + +```bash +cd packages/skill && pnpm build && pnpm test +``` + +**Step 7: Commit** + +```bash +git add packages/skill/src/onboard-builder.ts packages/skill/src/__tests__/onboard-builder.test.ts packages/skill/src/index.ts packages/skill/.claude/skills/understand-onboard.md +git commit -m "feat(skill): add /understand-onboard command for team onboarding guides" +``` + +--- + +## Task 4: Plugin Registry + Loader (Core) + +**Files:** +- Create: `packages/core/src/plugins/registry.ts` +- Create: `packages/core/src/__tests__/plugin-registry.test.ts` +- Modify: `packages/core/src/index.ts` (add exports) + +**Context:** The `AnalyzerPlugin` interface already exists in `packages/core/src/types.ts`. Currently only `TreeSitterPlugin` implements it. This task creates a plugin registry that discovers, registers, and manages analyzer plugins. The registry maps file extensions to plugins and provides a unified `analyzeFile` entrypoint. This is the foundation for community plugins. + +**Step 1: Write failing tests** + +```typescript +// packages/core/src/__tests__/plugin-registry.test.ts +import { describe, it, expect } from "vitest"; +import { PluginRegistry } from "../plugins/registry.js"; +import type { AnalyzerPlugin, StructuralAnalysis, ImportResolution } from "../types.js"; + +const emptyAnalysis: StructuralAnalysis = { + functions: [], + classes: [], + imports: [], + exports: [], +}; + +function createMockPlugin(name: string, languages: string[]): AnalyzerPlugin { + return { + name, + languages, + analyzeFile: () => ({ ...emptyAnalysis }), + resolveImports: () => [], + }; +} + +describe("PluginRegistry", () => { + it("registers a plugin", () => { + const registry = new PluginRegistry(); + const plugin = createMockPlugin("test", ["typescript"]); + registry.register(plugin); + expect(registry.getPlugins()).toHaveLength(1); + }); + + it("finds plugin by language", () => { + const registry = new PluginRegistry(); + const plugin = createMockPlugin("ts-plugin", ["typescript", "javascript"]); + registry.register(plugin); + expect(registry.getPluginForLanguage("typescript")).toBe(plugin); + expect(registry.getPluginForLanguage("javascript")).toBe(plugin); + }); + + it("returns null for unsupported language", () => { + const registry = new PluginRegistry(); + registry.register(createMockPlugin("ts-plugin", ["typescript"])); + expect(registry.getPluginForLanguage("python")).toBeNull(); + }); + + it("finds plugin by file extension", () => { + const registry = new PluginRegistry(); + const plugin = createMockPlugin("ts-plugin", ["typescript"]); + registry.register(plugin); + expect(registry.getPluginForFile("src/index.ts")).toBe(plugin); + expect(registry.getPluginForFile("src/app.tsx")).toBe(plugin); + }); + + it("maps common extensions to languages", () => { + const registry = new PluginRegistry(); + const plugin = createMockPlugin("multi", ["python", "go", "rust"]); + registry.register(plugin); + expect(registry.getPluginForFile("main.py")).toBe(plugin); + expect(registry.getPluginForFile("main.go")).toBe(plugin); + expect(registry.getPluginForFile("main.rs")).toBe(plugin); + }); + + it("lists all registered plugins", () => { + const registry = new PluginRegistry(); + registry.register(createMockPlugin("a", ["typescript"])); + registry.register(createMockPlugin("b", ["python"])); + expect(registry.getPlugins()).toHaveLength(2); + }); + + it("lists supported languages", () => { + const registry = new PluginRegistry(); + registry.register(createMockPlugin("a", ["typescript", "javascript"])); + registry.register(createMockPlugin("b", ["python"])); + const langs = registry.getSupportedLanguages(); + expect(langs).toContain("typescript"); + expect(langs).toContain("python"); + }); + + it("unregisters a plugin by name", () => { + const registry = new PluginRegistry(); + registry.register(createMockPlugin("removable", ["typescript"])); + expect(registry.getPlugins()).toHaveLength(1); + registry.unregister("removable"); + expect(registry.getPlugins()).toHaveLength(0); + }); + + it("later registration takes priority for same language", () => { + const registry = new PluginRegistry(); + const first = createMockPlugin("first", ["typescript"]); + const second = createMockPlugin("second", ["typescript"]); + registry.register(first); + registry.register(second); + // Second registration wins + expect(registry.getPluginForLanguage("typescript")?.name).toBe("second"); + }); + + it("analyzeFile delegates to correct plugin", () => { + const registry = new PluginRegistry(); + const plugin = createMockPlugin("ts-plugin", ["typescript"]); + plugin.analyzeFile = () => ({ + ...emptyAnalysis, + functions: [{ name: "hello", lineRange: [1, 5], params: [] }], + }); + registry.register(plugin); + + const result = registry.analyzeFile("src/test.ts", "const x = 1;"); + expect(result).not.toBeNull(); + expect(result!.functions).toHaveLength(1); + }); + + it("analyzeFile returns null for unsupported files", () => { + const registry = new PluginRegistry(); + registry.register(createMockPlugin("ts-plugin", ["typescript"])); + const result = registry.analyzeFile("main.py", "print('hello')"); + expect(result).toBeNull(); + }); +}); +``` + +**Step 2: Run tests to verify they fail** + +```bash +cd packages/core && pnpm test -- --reporter verbose src/__tests__/plugin-registry.test.ts +``` + +**Step 3: Implement registry.ts** + +```typescript +// packages/core/src/plugins/registry.ts +import type { AnalyzerPlugin, StructuralAnalysis, ImportResolution } from "../types.js"; + +// Map file extensions to language names +const EXTENSION_TO_LANGUAGE: Record = { + ts: "typescript", + tsx: "typescript", + js: "javascript", + jsx: "javascript", + py: "python", + go: "go", + rs: "rust", + rb: "ruby", + java: "java", + kt: "kotlin", + cs: "csharp", + cpp: "cpp", + c: "c", + swift: "swift", + php: "php", +}; + +/** + * Registry for analyzer plugins. Maps languages to plugins and provides + * a unified interface for analyzing files across languages. + */ +export class PluginRegistry { + private plugins: AnalyzerPlugin[] = []; + private languageMap = new Map(); + + /** + * Register an analyzer plugin. Later registrations take priority + * for overlapping languages. + */ + register(plugin: AnalyzerPlugin): void { + this.plugins.push(plugin); + for (const lang of plugin.languages) { + this.languageMap.set(lang, plugin); + } + } + + /** + * Remove a plugin by name. + */ + unregister(name: string): void { + const plugin = this.plugins.find((p) => p.name === name); + if (!plugin) return; + + this.plugins = this.plugins.filter((p) => p.name !== name); + + // Rebuild language map + this.languageMap.clear(); + for (const p of this.plugins) { + for (const lang of p.languages) { + this.languageMap.set(lang, p); + } + } + } + + /** + * Get plugin for a language name (e.g., "typescript", "python"). + */ + getPluginForLanguage(language: string): AnalyzerPlugin | null { + return this.languageMap.get(language) ?? null; + } + + /** + * Get plugin for a file path based on its extension. + */ + getPluginForFile(filePath: string): AnalyzerPlugin | null { + const ext = filePath.split(".").pop()?.toLowerCase(); + if (!ext) return null; + const language = EXTENSION_TO_LANGUAGE[ext]; + if (!language) return null; + return this.getPluginForLanguage(language); + } + + /** + * Analyze a file using the appropriate plugin. + * Returns null if no plugin supports the file type. + */ + analyzeFile(filePath: string, content: string): StructuralAnalysis | null { + const plugin = this.getPluginForFile(filePath); + if (!plugin) return null; + return plugin.analyzeFile(filePath, content); + } + + /** + * Resolve imports for a file using the appropriate plugin. + * Returns null if no plugin supports the file type. + */ + resolveImports(filePath: string, content: string): ImportResolution[] | null { + const plugin = this.getPluginForFile(filePath); + if (!plugin) return null; + return plugin.resolveImports(filePath, content); + } + + /** + * Get all registered plugins. + */ + getPlugins(): AnalyzerPlugin[] { + return [...this.plugins]; + } + + /** + * Get all supported languages across all plugins. + */ + getSupportedLanguages(): string[] { + return [...this.languageMap.keys()]; + } +} +``` + +**Step 4: Run tests** + +```bash +cd packages/core && pnpm test -- --reporter verbose src/__tests__/plugin-registry.test.ts +``` + +**Step 5: Add exports to index.ts** + +```typescript +export { PluginRegistry } from "./plugins/registry.js"; +``` + +**Step 6: Build + full test suite** + +```bash +cd packages/core && pnpm build && pnpm test +``` + +**Step 7: Commit** + +```bash +git add packages/core/src/plugins/registry.ts packages/core/src/__tests__/plugin-registry.test.ts packages/core/src/index.ts +git commit -m "feat(core): add plugin registry for community analyzer plugins" +``` + +--- + +## Task 5: Plugin Configuration + Discovery + +**Files:** +- Create: `packages/core/src/plugins/discovery.ts` +- Create: `packages/core/src/__tests__/plugin-discovery.test.ts` +- Modify: `packages/core/src/index.ts` (add exports) + +**Context:** The plugin registry from Task 4 manages runtime plugins, but we also need a way to discover and configure plugins from the project's `.understand-anything/` directory. This task adds a plugin configuration file schema and a discovery mechanism that scans for installed plugins and auto-registers them. + +**Step 1: Write failing tests** + +```typescript +// packages/core/src/__tests__/plugin-discovery.test.ts +import { describe, it, expect } from "vitest"; +import { + parsePluginConfig, + type PluginConfig, + type PluginEntry, + DEFAULT_PLUGIN_CONFIG, +} from "../plugins/discovery.js"; + +describe("plugin-discovery", () => { + describe("parsePluginConfig", () => { + it("parses valid config JSON", () => { + const json = JSON.stringify({ + plugins: [ + { name: "tree-sitter", enabled: true, languages: ["typescript", "javascript"] }, + { name: "python-ast", enabled: false, languages: ["python"] }, + ], + }); + const config = parsePluginConfig(json); + expect(config.plugins).toHaveLength(2); + expect(config.plugins[0].name).toBe("tree-sitter"); + expect(config.plugins[1].enabled).toBe(false); + }); + + it("returns default config for invalid JSON", () => { + const config = parsePluginConfig("not json"); + expect(config).toEqual(DEFAULT_PLUGIN_CONFIG); + }); + + it("returns default config for empty string", () => { + const config = parsePluginConfig(""); + expect(config).toEqual(DEFAULT_PLUGIN_CONFIG); + }); + + it("filters out entries missing required fields", () => { + const json = JSON.stringify({ + plugins: [ + { name: "valid", enabled: true, languages: ["typescript"] }, + { enabled: true, languages: ["python"] }, // missing name + { name: "no-langs", enabled: true }, // missing languages + ], + }); + const config = parsePluginConfig(json); + expect(config.plugins).toHaveLength(1); + expect(config.plugins[0].name).toBe("valid"); + }); + + it("defaults enabled to true when omitted", () => { + const json = JSON.stringify({ + plugins: [ + { name: "tree-sitter", languages: ["typescript"] }, + ], + }); + const config = parsePluginConfig(json); + expect(config.plugins[0].enabled).toBe(true); + }); + }); + + describe("DEFAULT_PLUGIN_CONFIG", () => { + it("includes tree-sitter as enabled by default", () => { + expect(DEFAULT_PLUGIN_CONFIG.plugins).toHaveLength(1); + expect(DEFAULT_PLUGIN_CONFIG.plugins[0].name).toBe("tree-sitter"); + expect(DEFAULT_PLUGIN_CONFIG.plugins[0].enabled).toBe(true); + }); + }); +}); +``` + +**Step 2: Run tests to verify they fail** + +```bash +cd packages/core && pnpm test -- --reporter verbose src/__tests__/plugin-discovery.test.ts +``` + +**Step 3: Implement discovery.ts** + +```typescript +// packages/core/src/plugins/discovery.ts + +export interface PluginEntry { + name: string; + enabled: boolean; + languages: string[]; + options?: Record; +} + +export interface PluginConfig { + plugins: PluginEntry[]; +} + +export const DEFAULT_PLUGIN_CONFIG: PluginConfig = { + plugins: [ + { + name: "tree-sitter", + enabled: true, + languages: ["typescript", "javascript"], + }, + ], +}; + +/** + * Parse a plugin config JSON string. + * Returns DEFAULT_PLUGIN_CONFIG if parsing fails. + */ +export function parsePluginConfig(jsonString: string): PluginConfig { + if (!jsonString.trim()) return { ...DEFAULT_PLUGIN_CONFIG }; + + try { + const parsed = JSON.parse(jsonString); + if (!parsed || !Array.isArray(parsed.plugins)) { + return { ...DEFAULT_PLUGIN_CONFIG }; + } + + const plugins = parsed.plugins + .filter((entry: unknown): entry is Record => { + if (typeof entry !== "object" || entry === null) return false; + const e = entry as Record; + return ( + typeof e.name === "string" && + e.name.length > 0 && + Array.isArray(e.languages) && + e.languages.length > 0 + ); + }) + .map((e: Record): PluginEntry => ({ + name: e.name as string, + enabled: typeof e.enabled === "boolean" ? e.enabled : true, + languages: e.languages as string[], + ...(e.options ? { options: e.options as Record } : {}), + })); + + return { plugins }; + } catch { + return { ...DEFAULT_PLUGIN_CONFIG }; + } +} + +/** + * Serialize a plugin config to JSON for saving. + */ +export function serializePluginConfig(config: PluginConfig): string { + return JSON.stringify(config, null, 2); +} +``` + +**Step 4: Run tests** + +```bash +cd packages/core && pnpm test -- --reporter verbose src/__tests__/plugin-discovery.test.ts +``` + +**Step 5: Add exports** + +```typescript +export { + parsePluginConfig, + serializePluginConfig, + DEFAULT_PLUGIN_CONFIG, + type PluginConfig, + type PluginEntry, +} from "./plugins/discovery.js"; +``` + +**Step 6: Build + test** + +```bash +cd packages/core && pnpm build && pnpm test +``` + +**Step 7: Commit** + +```bash +git add packages/core/src/plugins/discovery.ts packages/core/src/__tests__/plugin-discovery.test.ts packages/core/src/index.ts +git commit -m "feat(core): add plugin configuration and discovery system" +``` + +--- + +## Task 6: Embedding-Based Semantic Search (Core) + +**Files:** +- Create: `packages/core/src/embedding-search.ts` +- Create: `packages/core/src/__tests__/embedding-search.test.ts` +- Modify: `packages/core/src/index.ts` (add exports) + +**Context:** The current `SearchEngine` uses fuse.js for fuzzy keyword matching. Embedding-based search enables true semantic queries like "find code that handles authentication" even if the word "authentication" doesn't appear in the node data. This task adds a `SemanticSearchEngine` that stores and searches vector embeddings. The embeddings themselves are generated externally (by calling an embedding API) — this module handles storage and cosine similarity search. It falls back to the existing `SearchEngine` when no embeddings are available. + +**Step 1: Write failing tests** + +```typescript +// packages/core/src/__tests__/embedding-search.test.ts +import { describe, it, expect } from "vitest"; +import { SemanticSearchEngine, cosineSimilarity } from "../embedding-search.js"; +import type { GraphNode } from "../types.js"; + +const nodes: GraphNode[] = [ + { id: "n1", type: "file", name: "auth.ts", summary: "Authentication module", tags: ["auth"], complexity: "moderate" }, + { id: "n2", type: "file", name: "db.ts", summary: "Database connection", tags: ["db"], complexity: "simple" }, + { id: "n3", type: "function", name: "login", summary: "User login handler", tags: ["auth", "login"], complexity: "moderate" }, +]; + +// Simple unit vectors for testing +const embeddings: Record = { + n1: [1, 0, 0, 0], + n2: [0, 1, 0, 0], + n3: [0.9, 0, 0.1, 0], +}; + +describe("embedding-search", () => { + describe("cosineSimilarity", () => { + it("returns 1 for identical vectors", () => { + expect(cosineSimilarity([1, 0, 0], [1, 0, 0])).toBeCloseTo(1); + }); + + it("returns 0 for orthogonal vectors", () => { + expect(cosineSimilarity([1, 0, 0], [0, 1, 0])).toBeCloseTo(0); + }); + + it("returns high similarity for similar vectors", () => { + const sim = cosineSimilarity([1, 0, 0], [0.9, 0.1, 0]); + expect(sim).toBeGreaterThan(0.9); + }); + + it("handles zero vectors", () => { + expect(cosineSimilarity([0, 0, 0], [1, 0, 0])).toBe(0); + }); + }); + + describe("SemanticSearchEngine", () => { + it("returns results sorted by similarity", () => { + const engine = new SemanticSearchEngine(nodes, embeddings); + const queryEmbedding = [1, 0, 0, 0]; // most similar to n1 and n3 + const results = engine.search(queryEmbedding); + expect(results[0].nodeId).toBe("n1"); + }); + + it("respects limit parameter", () => { + const engine = new SemanticSearchEngine(nodes, embeddings); + const results = engine.search([1, 0, 0, 0], { limit: 2 }); + expect(results).toHaveLength(2); + }); + + it("respects threshold parameter", () => { + const engine = new SemanticSearchEngine(nodes, embeddings); + const results = engine.search([1, 0, 0, 0], { threshold: 0.5 }); + // n2 has 0 similarity, should be filtered out + const ids = results.map((r) => r.nodeId); + expect(ids).not.toContain("n2"); + }); + + it("filters by node type", () => { + const engine = new SemanticSearchEngine(nodes, embeddings); + const results = engine.search([1, 0, 0, 0], { types: ["function"] }); + expect(results.every((r) => { + const node = nodes.find((n) => n.id === r.nodeId); + return node?.type === "function"; + })).toBe(true); + }); + + it("returns empty for nodes without embeddings", () => { + const engine = new SemanticSearchEngine(nodes, {}); + const results = engine.search([1, 0, 0, 0]); + expect(results).toHaveLength(0); + }); + + it("hasEmbeddings returns true when embeddings exist", () => { + const engine = new SemanticSearchEngine(nodes, embeddings); + expect(engine.hasEmbeddings()).toBe(true); + }); + + it("hasEmbeddings returns false when empty", () => { + const engine = new SemanticSearchEngine(nodes, {}); + expect(engine.hasEmbeddings()).toBe(false); + }); + + it("addEmbedding updates the search index", () => { + const engine = new SemanticSearchEngine(nodes, {}); + expect(engine.hasEmbeddings()).toBe(false); + engine.addEmbedding("n1", [1, 0, 0, 0]); + expect(engine.hasEmbeddings()).toBe(true); + }); + }); +}); +``` + +**Step 2: Run tests to verify they fail** + +```bash +cd packages/core && pnpm test -- --reporter verbose src/__tests__/embedding-search.test.ts +``` + +**Step 3: Implement embedding-search.ts** + +```typescript +// packages/core/src/embedding-search.ts +import type { GraphNode } from "./types.js"; +import type { SearchResult } from "./search.js"; + +export interface SemanticSearchOptions { + limit?: number; + threshold?: number; + types?: string[]; +} + +/** + * Compute cosine similarity between two vectors. + * Returns 0 if either vector has zero magnitude. + */ +export function cosineSimilarity(a: number[], b: number[]): number { + let dot = 0; + let magA = 0; + let magB = 0; + + for (let i = 0; i < a.length; i++) { + dot += a[i] * b[i]; + magA += a[i] * a[i]; + magB += b[i] * b[i]; + } + + magA = Math.sqrt(magA); + magB = Math.sqrt(magB); + + if (magA === 0 || magB === 0) return 0; + return dot / (magA * magB); +} + +/** + * Semantic search engine using vector embeddings. + * Stores pre-computed embeddings for graph nodes and performs + * cosine similarity search against query embeddings. + */ +export class SemanticSearchEngine { + private nodes: GraphNode[]; + private embeddings: Map; + + constructor(nodes: GraphNode[], embeddings: Record) { + this.nodes = nodes; + this.embeddings = new Map(Object.entries(embeddings)); + } + + /** + * Check if any embeddings are loaded. + */ + hasEmbeddings(): boolean { + return this.embeddings.size > 0; + } + + /** + * Add or update an embedding for a node. + */ + addEmbedding(nodeId: string, embedding: number[]): void { + this.embeddings.set(nodeId, embedding); + } + + /** + * Search nodes by similarity to a query embedding. + * Returns SearchResult[] compatible with the existing search interface. + */ + search( + queryEmbedding: number[], + options?: SemanticSearchOptions, + ): SearchResult[] { + const limit = options?.limit ?? 10; + const threshold = options?.threshold ?? 0; + const typeFilter = options?.types; + + const scored: Array<{ nodeId: string; score: number }> = []; + + for (const node of this.nodes) { + // Type filter + if (typeFilter && !typeFilter.includes(node.type)) continue; + + const embedding = this.embeddings.get(node.id); + if (!embedding) continue; + + const similarity = cosineSimilarity(queryEmbedding, embedding); + if (similarity >= threshold) { + // Convert similarity (0-1, higher=better) to score (0-1, lower=better) + // to match the SearchResult interface convention from fuse.js + scored.push({ nodeId: node.id, score: 1 - similarity }); + } + } + + // Sort by score ascending (lower = more similar) + scored.sort((a, b) => a.score - b.score); + + return scored.slice(0, limit); + } + + /** + * Update the node list (e.g., after graph reload). + */ + updateNodes(nodes: GraphNode[]): void { + this.nodes = nodes; + } +} +``` + +**Step 4: Run tests** + +```bash +cd packages/core && pnpm test -- --reporter verbose src/__tests__/embedding-search.test.ts +``` + +**Step 5: Add exports** + +```typescript +export { + SemanticSearchEngine, + cosineSimilarity, + type SemanticSearchOptions, +} from "./embedding-search.js"; +``` + +**Step 6: Build + test** + +```bash +cd packages/core && pnpm build && pnpm test +``` + +**Step 7: Commit** + +```bash +git add packages/core/src/embedding-search.ts packages/core/src/__tests__/embedding-search.test.ts packages/core/src/index.ts +git commit -m "feat(core): add embedding-based semantic search engine" +``` + +--- + +## Task 7: Embedding Search Dashboard Integration + +**Files:** +- Modify: `packages/dashboard/src/store.ts` (add semantic search state) +- Modify: `packages/dashboard/src/components/SearchBar.tsx` (semantic search toggle) + +**Context:** This task integrates the `SemanticSearchEngine` into the dashboard. When the knowledge graph includes pre-computed embeddings (stored as a separate field or companion file), the SearchBar offers a toggle between "Fuzzy" and "Semantic" search modes. The semantic mode uses vector similarity for queries like "where is authentication handled" even if those exact words aren't in any node. For MVP, we'll add the UI toggle and wiring — actual embedding generation requires an API call that would be part of the analysis pipeline. + +**Step 1: Add semantic search state to the store** + +In `packages/dashboard/src/store.ts`: + +```typescript +// Add to interface +searchMode: "fuzzy" | "semantic"; +setSearchMode: (mode: "fuzzy" | "semantic") => void; + +// Add to implementation +searchMode: "fuzzy", +setSearchMode: (mode) => set({ searchMode: mode }), +``` + +Update `setSearchQuery` to check `searchMode`: +```typescript +setSearchQuery: (query) => { + const engine = get().searchEngine; + const mode = get().searchMode; + if (!engine || !query.trim()) { + set({ searchQuery: query, searchResults: [] }); + return; + } + // Currently both modes use the same fuzzy engine + // When embeddings are available, "semantic" mode will use SemanticSearchEngine + const searchResults = engine.search(query); + set({ searchQuery: query, searchResults }); +}, +``` + +**Step 2: Add search mode toggle to SearchBar** + +In `packages/dashboard/src/components/SearchBar.tsx`, add: + +```tsx +const searchMode = useDashboardStore((s) => s.searchMode); +const setSearchMode = useDashboardStore((s) => s.setSearchMode); + +// Add toggle next to the search input: +
+ + +
+``` + +**Step 3: Verify dashboard compiles** + +```bash +cd packages/dashboard && pnpm build +``` + +**Step 4: Commit** + +```bash +git add packages/dashboard/src/store.ts packages/dashboard/src/components/SearchBar.tsx +git commit -m "feat(dashboard): add fuzzy/semantic search mode toggle" +``` + +--- + +## Verification Checklist + +After all tasks are complete: + +1. `cd packages/core && pnpm build && pnpm test` — all tests pass (existing + ~35 new) +2. `cd packages/skill && pnpm build && pnpm test` — all tests pass (existing 14 + ~25 new) +3. `cd packages/dashboard && pnpm build` — compiles without errors +4. Skill definitions exist: + - `packages/skill/.claude/skills/understand-diff.md` + - `packages/skill/.claude/skills/understand-explain.md` + - `packages/skill/.claude/skills/understand-onboard.md` +5. Plugin registry works: + - `PluginRegistry.register()`, `getPluginForFile()`, `analyzeFile()` + - `parsePluginConfig()` handles valid/invalid JSON +6. Semantic search: + - `cosineSimilarity()` produces correct values + - `SemanticSearchEngine.search()` returns sorted results + - Dashboard toggle renders and switches modes +7. All existing Phase 1 + Phase 2 + Phase 3 features still work diff --git a/Understand-Anything-main/docs/superpowers/plans/2026-03-15-homepage-implementation.md b/Understand-Anything-main/docs/superpowers/plans/2026-03-15-homepage-implementation.md new file mode 100644 index 0000000..4f82f32 --- /dev/null +++ b/Understand-Anything-main/docs/superpowers/plans/2026-03-15-homepage-implementation.md @@ -0,0 +1,1238 @@ +# Homepage Implementation Plan + +> **For Claude:** REQUIRED SUB-SKILL: Use superpowers:executing-plans to implement this plan task-by-task. + +**Goal:** Build a cinematic, scroll-driven project homepage for Understand Anything using Astro, deployed to GitHub Pages via `gh-pages` branch. + +**Architecture:** Astro SSG project in `homepage/` on main. Self-hosted fonts (DM Serif Display, Inter, JetBrains Mono) with robust fallbacks. Pure CSS animations triggered by `IntersectionObserver`. GitHub Actions workflow builds and deploys to `gh-pages` on push. + +**Tech Stack:** Astro 5, CSS custom properties, vanilla JS, GitHub Actions + +**Design doc:** `docs/plans/2026-03-15-homepage-design.md` + +--- + +### Task 1: Scaffold Astro Project + +**Files:** +- Create: `homepage/package.json` +- Create: `homepage/astro.config.mjs` +- Create: `homepage/tsconfig.json` +- Create: `homepage/src/pages/index.astro` (placeholder) +- Create: `homepage/src/layouts/Layout.astro` (placeholder) +- Create: `homepage/public/.gitkeep` + +**Step 1: Initialize Astro project** + +```bash +cd /Users/yuxianglin/Desktop/opensource/Understand-Anything +mkdir -p homepage +cd homepage +pnpm create astro@latest . -- --template minimal --no-install --no-git --typescript strict +``` + +If the interactive prompt blocks, create files manually instead. + +**Step 2: Configure Astro for GitHub Pages** + +Edit `homepage/astro.config.mjs`: + +```js +import { defineConfig } from 'astro/config'; + +export default defineConfig({ + site: 'https://lum1104.github.io', + base: '/Understand-Anything', +}); +``` + +**Step 3: Verify the project builds** + +```bash +cd /Users/yuxianglin/Desktop/opensource/Understand-Anything/homepage +pnpm install +pnpm build +``` + +Expected: Build succeeds, `dist/` directory created. + +**Step 4: Commit** + +```bash +git add homepage/ +git commit -m "feat(homepage): scaffold Astro project with GitHub Pages config" +``` + +--- + +### Task 2: Self-Host Fonts & Base CSS + +**Files:** +- Create: `homepage/public/fonts/DMSerifDisplay-Regular.woff2` +- Create: `homepage/public/fonts/Inter-Regular.woff2` +- Create: `homepage/public/fonts/Inter-SemiBold.woff2` +- Create: `homepage/public/fonts/JetBrainsMono-Regular.woff2` +- Create: `homepage/src/styles/global.css` + +**Step 1: Download font files** + +Download the WOFF2 files from Google Fonts API (or fontsource). Place them in `homepage/public/fonts/`. Required files: +- DM Serif Display Regular (woff2) +- Inter Regular + SemiBold (woff2) +- JetBrains Mono Regular (woff2) + +Use curl to download from fontsource CDN or Google Fonts CSS API. Example: + +```bash +mkdir -p homepage/public/fonts +# Download from fontsource (reliable CDN) +curl -L "https://cdn.jsdelivr.net/fontsource/fonts/dm-serif-display@latest/latin-400-normal.woff2" -o homepage/public/fonts/DMSerifDisplay-Regular.woff2 +curl -L "https://cdn.jsdelivr.net/fontsource/fonts/inter@latest/latin-400-normal.woff2" -o homepage/public/fonts/Inter-Regular.woff2 +curl -L "https://cdn.jsdelivr.net/fontsource/fonts/inter@latest/latin-600-normal.woff2" -o homepage/public/fonts/Inter-SemiBold.woff2 +curl -L "https://cdn.jsdelivr.net/fontsource/fonts/jetbrains-mono@latest/latin-400-normal.woff2" -o homepage/public/fonts/JetBrainsMono-Regular.woff2 +``` + +If download fails, try alternative URLs or use `npx fontsource` to install locally. + +**Step 2: Create global CSS with design tokens and font-face declarations** + +Create `homepage/src/styles/global.css`: + +```css +/* Font declarations — self-hosted, no external CDN dependency */ +@font-face { + font-family: 'DM Serif Display'; + src: url('/Understand-Anything/fonts/DMSerifDisplay-Regular.woff2') format('woff2'); + font-weight: 400; + font-style: normal; + font-display: swap; +} + +@font-face { + font-family: 'Inter'; + src: url('/Understand-Anything/fonts/Inter-Regular.woff2') format('woff2'); + font-weight: 400; + font-style: normal; + font-display: swap; +} + +@font-face { + font-family: 'Inter'; + src: url('/Understand-Anything/fonts/Inter-SemiBold.woff2') format('woff2'); + font-weight: 600; + font-style: normal; + font-display: swap; +} + +@font-face { + font-family: 'JetBrains Mono'; + src: url('/Understand-Anything/fonts/JetBrainsMono-Regular.woff2') format('woff2'); + font-weight: 400; + font-style: normal; + font-display: swap; +} + +/* Design tokens */ +:root { + --bg: #0a0a0a; + --surface: #141414; + --border: #1a1a1a; + --accent: #d4a574; + --accent-glow: rgba(212, 165, 116, 0.15); + --text: #e8e2d8; + --text-muted: #8a8578; + + --font-heading: 'DM Serif Display', Georgia, 'Times New Roman', serif; + --font-body: 'Inter', -apple-system, BlinkMacSystemFont, 'Segoe UI', sans-serif; + --font-code: 'JetBrains Mono', 'SF Mono', 'Cascadia Code', 'Fira Code', monospace; +} + +/* Reset & base */ +*, *::before, *::after { + margin: 0; + padding: 0; + box-sizing: border-box; +} + +html { + scroll-behavior: smooth; +} + +body { + font-family: var(--font-body); + background-color: var(--bg); + color: var(--text); + line-height: 1.6; + -webkit-font-smoothing: antialiased; + overflow-x: hidden; +} + +/* Noise texture overlay */ +body::before { + content: ''; + position: fixed; + inset: 0; + pointer-events: none; + z-index: 9999; + opacity: 0.03; + background-image: url("data:image/svg+xml,%3Csvg viewBox='0 0 256 256' xmlns='http://www.w3.org/2000/svg'%3E%3Cfilter id='noise'%3E%3CfeTurbulence type='fractalNoise' baseFrequency='0.9' numOctaves='4' stitchTiles='stitch'/%3E%3C/filter%3E%3Crect width='100%25' height='100%25' filter='url(%23noise)'/%3E%3C/svg%3E"); +} + +/* Scroll-reveal animation */ +@keyframes fadeSlideUp { + from { + opacity: 0; + transform: translateY(30px); + } + to { + opacity: 1; + transform: translateY(0); + } +} + +.reveal { + opacity: 0; +} + +.reveal.visible { + animation: fadeSlideUp 0.8s ease-out forwards; +} + +/* Stagger delays for feature cards */ +.reveal-delay-1 { animation-delay: 0.1s; } +.reveal-delay-2 { animation-delay: 0.25s; } +.reveal-delay-3 { animation-delay: 0.4s; } + +a { + color: var(--accent); + text-decoration: none; +} + +a:hover { + text-decoration: underline; +} +``` + +**Step 3: Import global CSS in Layout** + +Update `homepage/src/layouts/Layout.astro`: + +```astro +--- +interface Props { + title: string; +} + +const { title } = Astro.props; +--- + + + + + + + + + {title} + + + + + + + +``` + +**Step 4: Build and verify fonts load** + +```bash +cd /Users/yuxianglin/Desktop/opensource/Understand-Anything/homepage +pnpm build +``` + +Expected: Build succeeds. Check `dist/fonts/` contains the woff2 files. + +**Step 5: Commit** + +```bash +git add homepage/public/fonts/ homepage/src/styles/global.css homepage/src/layouts/Layout.astro +git commit -m "feat(homepage): add self-hosted fonts and design token CSS" +``` + +--- + +### Task 3: Nav Bar Component + +**Files:** +- Create: `homepage/src/components/Nav.astro` + +**Step 1: Create the nav component** + +Create `homepage/src/components/Nav.astro`: + +```astro +--- +const githubUrl = 'https://github.com/Lum1104/Understand-Anything'; +--- + + + + + + +``` + +**Step 2: Add Nav to index.astro (temporary test)** + +Update `homepage/src/pages/index.astro`: + +```astro +--- +import Layout from '../layouts/Layout.astro'; +import Nav from '../components/Nav.astro'; +--- + + +
+ ); +} diff --git a/Understand-Anything-main/understand-anything-plugin/packages/dashboard/src/components/MobileLayout.tsx b/Understand-Anything-main/understand-anything-plugin/packages/dashboard/src/components/MobileLayout.tsx new file mode 100644 index 0000000..27e4801 --- /dev/null +++ b/Understand-Anything-main/understand-anything-plugin/packages/dashboard/src/components/MobileLayout.tsx @@ -0,0 +1,233 @@ +import { lazy, Suspense, useEffect, useState } from "react"; +import type { GraphIssue } from "@understand-anything/core/schema"; +import { useDashboardStore } from "../store"; +import { useI18n } from "../contexts/I18nContext"; +import GraphView from "./GraphView"; +import DomainGraphView from "./DomainGraphView"; +import KnowledgeGraphView from "./KnowledgeGraphView"; +import SearchBar from "./SearchBar"; +import NodeInfo from "./NodeInfo"; +import ProjectOverview from "./ProjectOverview"; +import FileExplorer from "./FileExplorer"; +import WarningBanner from "./WarningBanner"; +import MobileBottomNav from "./MobileBottomNav"; +import type { MobileTab } from "./MobileBottomNav"; +import MobileDrawer from "./MobileDrawer"; + +const CodeViewer = lazy(() => import("./CodeViewer")); +const LearnPanel = lazy(() => import("./LearnPanel")); +const PathFinderModal = lazy(() => import("./PathFinderModal")); +const KeyboardShortcutsHelp = lazy(() => import("./KeyboardShortcutsHelp")); + +interface Props { + accessToken: string; + showKeyboardHelp: boolean; + setShowKeyboardHelp: (value: boolean) => void; + loadError: string | null; + allIssues: GraphIssue[]; + shortcuts: import("../hooks/useKeyboardShortcuts").KeyboardShortcut[]; +} + +export default function MobileLayout({ + accessToken, + showKeyboardHelp, + setShowKeyboardHelp, + loadError, + allIssues, + shortcuts, +}: Props) { + const graph = useDashboardStore((s) => s.graph); + const selectedNodeId = useDashboardStore((s) => s.selectedNodeId); + const tourActive = useDashboardStore((s) => s.tourActive); + const persona = useDashboardStore((s) => s.persona); + const viewMode = useDashboardStore((s) => s.viewMode); + const domainGraph = useDashboardStore((s) => s.domainGraph); + const codeViewerOpen = useDashboardStore((s) => s.codeViewerOpen); + const closeCodeViewer = useDashboardStore((s) => s.closeCodeViewer); + const pathFinderOpen = useDashboardStore((s) => s.pathFinderOpen); + const togglePathFinder = useDashboardStore((s) => s.togglePathFinder); + const { t } = useI18n(); + + const [activeTab, setActiveTab] = useState("graph"); + const [drawerOpen, setDrawerOpen] = useState(false); + const [searchOpen, setSearchOpen] = useState(false); + + // Auto-pivot to Info when a node is selected — keeps feedback visible + // on a small screen where graph and sidebar can't coexist + useEffect(() => { + if (selectedNodeId) setActiveTab("info"); + }, [selectedNodeId]); + + // When a code viewer opens (e.g. from the Files tab) keep focus there + useEffect(() => { + if (codeViewerOpen) setSearchOpen(false); + }, [codeViewerOpen]); + + const isLearnMode = tourActive || persona === "junior"; + const infoContent = ( + <> + {selectedNodeId && } + {isLearnMode && ( + + + + )} + {!selectedNodeId && !isLearnMode && } + + ); + + return ( +
+ {/* Top bar */} +
+ + +

+ {graph?.project.name ?? t.common.appName} +

+ + +
+ + {/* Search (collapsible) */} + {searchOpen && } + + {/* Validation warnings */} + {allIssues.length > 0 && !loadError && } + + {/* Load error */} + {loadError && ( +
+ {loadError} +
+ )} + + {/* Tabbed content — all panes stay mounted to preserve layout/state. + Inactive panes are kept in the layout (not display:none) so that + ReactFlow keeps real dimensions and pinch/pan don't collapse on + tab switch. */} +
+
+ {viewMode === "knowledge" ? ( + + ) : viewMode === "domain" && domainGraph ? ( + + ) : ( + + )} +
+ +
+ {infoContent} +
+ +
+ +
+
+ + {/* Bottom tab nav */} + + + {/* Drawer */} + setDrawerOpen(false)} + onTogglePathFinder={togglePathFinder} + onShowKeyboardHelp={() => setShowKeyboardHelp(true)} + /> + + {/* Code viewer — always fullscreen on mobile */} + {codeViewerOpen && ( +
+
event.stopPropagation()} + > + + + +
+
+ )} + + {/* Keyboard help (mobile reads it as a quick reference too) */} + {showKeyboardHelp && ( + + setShowKeyboardHelp(false)} + /> + + )} + + {/* Path finder */} + {pathFinderOpen && ( + + + + )} +
+ ); +} diff --git a/Understand-Anything-main/understand-anything-plugin/packages/dashboard/src/components/NodeInfo.tsx b/Understand-Anything-main/understand-anything-plugin/packages/dashboard/src/components/NodeInfo.tsx new file mode 100644 index 0000000..5685df0 --- /dev/null +++ b/Understand-Anything-main/understand-anything-plugin/packages/dashboard/src/components/NodeInfo.tsx @@ -0,0 +1,536 @@ +import { useState } from "react"; +import { useDashboardStore } from "../store"; +import { useI18n } from "../contexts/I18nContext"; +import type { NodeType, EdgeType, KnowledgeGraph, GraphNode } from "@understand-anything/core/types"; + +// Badge color classes keyed by NodeType — must be kept in sync with core NodeType union. +const typeBadgeColors: Record = { + file: "text-node-file border border-node-file/30 bg-node-file/10", + function: "text-node-function border border-node-function/30 bg-node-function/10", + class: "text-node-class border border-node-class/30 bg-node-class/10", + module: "text-node-module border border-node-module/30 bg-node-module/10", + concept: "text-node-concept border border-node-concept/30 bg-node-concept/10", + config: "text-node-config border border-node-config/30 bg-node-config/10", + document: "text-node-document border border-node-document/30 bg-node-document/10", + service: "text-node-service border border-node-service/30 bg-node-service/10", + table: "text-node-table border border-node-table/30 bg-node-table/10", + endpoint: "text-node-endpoint border border-node-endpoint/30 bg-node-endpoint/10", + pipeline: "text-node-pipeline border border-node-pipeline/30 bg-node-pipeline/10", + schema: "text-node-schema border border-node-schema/30 bg-node-schema/10", + resource: "text-node-resource border border-node-resource/30 bg-node-resource/10", + domain: "text-node-concept border border-node-concept/30 bg-node-concept/10", + flow: "text-node-pipeline border border-node-pipeline/30 bg-node-pipeline/10", + step: "text-node-function border border-node-function/30 bg-node-function/10", + article: "text-node-article border border-node-article/30 bg-node-article/10", + entity: "text-node-entity border border-node-entity/30 bg-node-entity/10", + topic: "text-node-topic border border-node-topic/30 bg-node-topic/10", + claim: "text-node-claim border border-node-claim/30 bg-node-claim/10", + source: "text-node-source border border-node-source/30 bg-node-source/10", +}; + +const complexityBadgeColors: Record = { + simple: "text-node-function border border-node-function/30 bg-node-function/10", + moderate: "text-accent-dim border border-accent-dim/30 bg-accent-dim/10", + complex: "text-[#c97070] border border-[#c97070]/30 bg-[#c97070]/10", +}; + +function getDirectionalLabel(edgeType: string, isSource: boolean, t: ReturnType["t"]): string { + const labels = t.edgeLabels[edgeType as EdgeType]; + if (!labels) { + const formatted = edgeType.replace(/_/g, " ").replace(/\b\w/g, (c) => c.toUpperCase()); + return isSource ? formatted : `${formatted} (reverse)`; + } + return isSource ? labels.forward : labels.backward; +} + +function KnowledgeNodeDetails({ node, graph }: { node: GraphNode; graph: KnowledgeGraph }) { + const navigateToNode = useDashboardStore((s) => s.navigateToNode); + const { t } = useI18n(); + const meta = node.knowledgeMeta; + + // Wikilinks (outgoing related edges) + const wikilinks = graph.edges + .filter((e) => e.type === "related" && e.source === node.id) + .map((e) => graph.nodes.find((n) => n.id === e.target)) + .filter((n): n is GraphNode => n !== undefined); + + // Backlinks (incoming related edges) + const backlinks = graph.edges + .filter((e) => e.type === "related" && e.target === node.id) + .map((e) => graph.nodes.find((n) => n.id === e.source)) + .filter((n): n is GraphNode => n !== undefined); + + // Category + const categoryEdge = graph.edges.find( + (e) => e.type === "categorized_under" && e.source === node.id + ); + const categoryNode = categoryEdge + ? graph.nodes.find((n) => n.id === categoryEdge.target) + : null; + + return ( +
+ {categoryNode && ( +
+

{t.nodeInfo.category}

+ +
+ )} + {meta?.wikilinks && meta.wikilinks.length > 0 && ( +
+

+ {t.nodeInfo.wikilinks} ({wikilinks.length}) +

+
+ {wikilinks.map((n) => ( + + ))} +
+
+ )} + {backlinks.length > 0 && ( +
+

+ {t.nodeInfo.backlinks} ({backlinks.length}) +

+
+ {backlinks.map((n) => ( + + ))} +
+
+ )} + {meta?.content && ( +
+

{t.common.preview}

+
+ {meta.content} +
+
+ )} +
+ ); +} + +function DomainNodeDetails({ node, graph }: { node: GraphNode; graph: KnowledgeGraph }) { + const navigateToDomain = useDashboardStore((s) => s.navigateToDomain); + const selectNode = useDashboardStore((s) => s.selectNode); + const { t } = useI18n(); + const meta = node.domainMeta; + + if (node.type === "domain") { + const flows = graph.edges + .filter((e) => e.type === "contains_flow" && e.source === node.id) + .map((e) => graph.nodes.find((n) => n.id === e.target)) + .filter((n): n is GraphNode => n !== undefined); + + return ( +
+ {Array.isArray(meta?.entities) && meta.entities.length > 0 ? ( +
+

{t.nodeInfo.entities}

+
+ {meta.entities.map((e) => ( + {e} + ))} +
+
+ ) : null} + {Array.isArray(meta?.businessRules) && meta.businessRules.length > 0 ? ( +
+

{t.nodeInfo.businessRules}

+
    + {meta.businessRules.map((r, i) => ( +
  • -{r}
    • + ))} +
+
+ ) : null} + {Array.isArray(meta?.crossDomainInteractions) && meta.crossDomainInteractions.length > 0 ? ( +
+

{t.nodeInfo.crossDomain}

+
    + {meta.crossDomainInteractions.map((c, i) => ( +
  • {c}
    • + ))} +
+
+ ) : null} + {flows.length > 0 && ( +
+

{t.nodeInfo.flows}

+
+ {flows.map((f) => ( + + ))} +
+
+ )} +
+ ); + } + + if (node.type === "flow") { + const steps = graph.edges + .filter((e) => e.type === "flow_step" && e.source === node.id) + .sort((a, b) => a.weight - b.weight) + .map((e) => graph.nodes.find((n) => n.id === e.target)) + .filter((n): n is GraphNode => n !== undefined); + + return ( +
+ {meta?.entryPoint ? ( +
+

{t.nodeInfo.entryPoint}

+
{meta.entryPoint}
+
+ ) : null} + {steps.length > 0 && ( +
+

{t.nodeInfo.steps}

+
    + {steps.map((s, i) => ( +
  1. + +
    2. + ))} +
+
+ )} +
+ ); + } + + if (node.type === "step") { + if (!node.filePath) return null; + return ( +
+
+

{t.nodeInfo.implementation}

+
+ {node.filePath} + {node.lineRange && :{node.lineRange[0]}-{node.lineRange[1]}} +
+
+
+ ); + } + + return null; +} + +export default function NodeInfo() { + const graph = useDashboardStore((s) => s.graph); + const selectedNodeId = useDashboardStore((s) => s.selectedNodeId); + const nodeHistory = useDashboardStore((s) => s.nodeHistory); + const goBackNode = useDashboardStore((s) => s.goBackNode); + const [languageExpanded, setLanguageExpanded] = useState(true); + const { t } = useI18n(); + + const navigateToNode = useDashboardStore((s) => s.navigateToNode); + const navigateToHistoryIndex = useDashboardStore((s) => s.navigateToHistoryIndex); + const setFocusNode = useDashboardStore((s) => s.setFocusNode); + const openCodeViewer = useDashboardStore((s) => s.openCodeViewer); + const focusNodeId = useDashboardStore((s) => s.focusNodeId); + const viewMode = useDashboardStore((s) => s.viewMode); + const domainGraph = useDashboardStore((s) => s.domainGraph); + + const activeGraph = viewMode === "domain" && domainGraph ? domainGraph : graph; + const node = activeGraph?.nodes.find((n) => n.id === selectedNodeId) ?? null; + + // Resolve history node names for the breadcrumb trail + const historyNodes = nodeHistory.map((id) => { + const n = activeGraph?.nodes.find((gn) => gn.id === id); + return { id, name: n?.name ?? id }; + }); + + if (!node) { + return ( +
+

{t.common.selectNode}

+
+ ); + } + + const allEdges = activeGraph?.edges ?? []; + const connections = allEdges.filter( + (e) => e.source === node.id || e.target === node.id, + ); + + // Separate child nodes (contained IN this file) from other connections + const childEdges = connections.filter( + (e) => e.type === "contains" && e.source === node.id, + ); + const otherConnections = connections.filter( + (e) => !(e.type === "contains" && e.source === node.id), + ); + + // Resolve child nodes + const childNodes = childEdges + .map((e) => activeGraph?.nodes.find((n) => n.id === e.target)) + .filter((n): n is GraphNode => n !== undefined); + + const knownType = node.type as NodeType; + const typeBadge = typeBadgeColors[knownType] ?? typeBadgeColors.file; + const complexityBadge = + complexityBadgeColors[node.complexity] ?? complexityBadgeColors.simple; + + if (import.meta.env.DEV && !(knownType in typeBadgeColors)) { + console.warn(`[NodeInfo] Unknown node type "${node.type}" — using "file" badge colors`); + } + + return ( +
+ {/* Navigation history trail */} + {historyNodes.length > 0 && ( +
+ + │ + {historyNodes.slice(-3).map((h, i, arr) => ( + + + {i < arr.length - 1 && ( + › + )} + + ))} + › + + {node.name} + +
+ )} + +
+ + {node.type} + + + {node.complexity} + +
+ +
+

{node.name}

+ +
+ +

+ {node.summary} +

+ + {node.filePath && ( +
+
+
+
{t.common.file}
+
+ {node.filePath} + {node.lineRange && ( + + L{node.lineRange[0]}-{node.lineRange[1]} + + )} +
+
+ +
+
+ )} + + {node.languageNotes && ( +
+ + {languageExpanded && ( +
+

+ {node.languageNotes} +

+
+ )} +
+ )} + + {node.tags.length > 0 && ( +
+

+ {t.common.tags} +

+
+ {node.tags.map((tag) => ( + + {tag} + + ))} +
+
+ )} + + {/* Knowledge-specific details */} + {activeGraph && node && (node.type === "article" || node.type === "entity" || node.type === "topic" || node.type === "claim" || node.type === "source" || node.knowledgeMeta) && ( + + )} + + {/* Domain-specific details */} + {activeGraph && node && (node.type === "domain" || node.type === "flow" || node.type === "step") && ( + + )} + + {/* Child classes/functions within this file */} + {childNodes.length > 0 && ( +
+

+ {t.nodeInfo.definedInThisFile} ({childNodes.length}) +

+
+ {childNodes.map((child) => { + if (!child) return null; + const childTypeBadge = typeBadgeColors[child.type as NodeType] ?? typeBadgeColors.file; + const childComplexity = complexityBadgeColors[child.complexity] ?? complexityBadgeColors.simple; + return ( +
navigateToNode(child.id)} + > +
+ + {child.type} + + {child.name} + + {child.complexity} + +
+ {child.summary && ( +

+ {child.summary} +

+ )} +
+ ); + })} +
+
+ )} + + {/* Other connections (excluding "contains" children) */} + {otherConnections.length > 0 && ( +
+

+ {t.common.connections} ({otherConnections.length}) +

+
+ {otherConnections.map((edge, i) => { + const isSource = edge.source === node.id; + const otherId = isSource ? edge.target : edge.source; + const otherNode = activeGraph?.nodes.find((n) => n.id === otherId); + const dirLabel = getDirectionalLabel(edge.type, isSource, t); + const arrow = isSource ? "\u2192" : "\u2190"; + + return ( +
{ + navigateToNode(otherId); + }} + > + {arrow} + {dirLabel} + + {otherNode?.name ?? otherId} + +
+ ); + })} +
+
+ )} +
+ ); +} diff --git a/Understand-Anything-main/understand-anything-plugin/packages/dashboard/src/components/NodeTooltip.tsx b/Understand-Anything-main/understand-anything-plugin/packages/dashboard/src/components/NodeTooltip.tsx new file mode 100644 index 0000000..ebdafa7 --- /dev/null +++ b/Understand-Anything-main/understand-anything-plugin/packages/dashboard/src/components/NodeTooltip.tsx @@ -0,0 +1,124 @@ +import { useEffect, useState } from "react"; +import type { CustomNodeData } from "./CustomNode"; + +interface NodeTooltipProps { + data: CustomNodeData; + nodeId: string; + incomingCount: number; + outgoingCount: number; + tags?: string[]; +} + +export default function NodeTooltip({ + data, + nodeId, + incomingCount, + outgoingCount, + tags = [], +}: NodeTooltipProps) { + const [position, setPosition] = useState({ x: 0, y: 0 }); + const [visible, setVisible] = useState(false); + + useEffect(() => { + const handleMouseMove = (e: Event) => { + const me = e as globalThis.MouseEvent; + setPosition({ x: me.clientX, y: me.clientY }); + }; + + const showTooltip = () => setVisible(true); + const hideTooltip = () => setVisible(false); + + // Find the node element via data-id (React Flow convention) + const nodeElement = document.querySelector(`[data-id="${CSS.escape(nodeId)}"]`); + if (nodeElement) { + nodeElement.addEventListener("mouseenter", showTooltip); + nodeElement.addEventListener("mouseleave", hideTooltip); + nodeElement.addEventListener("mousemove", handleMouseMove); + + return () => { + nodeElement.removeEventListener("mouseenter", showTooltip); + nodeElement.removeEventListener("mouseleave", hideTooltip); + nodeElement.removeEventListener("mousemove", handleMouseMove); + }; + } + }, [nodeId]); + + if (!visible) return null; + + const totalConnections = incomingCount + outgoingCount; + + return ( +
+
+ {/* Header */} +
+ + {data.nodeType} + + {data.complexity && ( + + {data.complexity} + + )} +
+ + {/* Name */} +

+ {data.label} +

+ + {/* Connections */} +
+
+ + + + {incomingCount} in +
+
+ + + + {outgoingCount} out +
+
+ + + + {totalConnections} +
+
+ + {/* Summary */} + {data.summary && ( +

+ {data.summary.length > 120 ? data.summary.slice(0, 120) + "..." : data.summary} +

+ )} + + {/* Tags */} + {tags.length > 0 && ( +
+ {tags.slice(0, 3).map((tag) => ( + + {tag} + + ))} + {tags.length > 3 && ( + +{tags.length - 3} + )} +
+ )} +
+
+ ); +} diff --git a/Understand-Anything-main/understand-anything-plugin/packages/dashboard/src/components/OnboardingOverlay.tsx b/Understand-Anything-main/understand-anything-plugin/packages/dashboard/src/components/OnboardingOverlay.tsx new file mode 100644 index 0000000..a377a12 --- /dev/null +++ b/Understand-Anything-main/understand-anything-plugin/packages/dashboard/src/components/OnboardingOverlay.tsx @@ -0,0 +1,256 @@ +import { useEffect, useState } from "react"; +import { useI18n } from "../contexts/I18nContext"; + +/** + * First-visit onboarding overlay (controlled). + * + * Parent owns the visibility + persistence state (see App.tsx). This component + * only renders the modal and reports the user's intent via onDismiss: + * - onDismiss(true) → "Skip" / Finish — parent should persist. + * - onDismiss(false) → backdrop click / Escape — parent should close without persisting. + * + * Force-show is handled by the parent (see `shouldShowOnboarding` in App.tsx). + */ + +interface Props { + onDismiss: (remember: boolean) => void; +} + +const TITLE_ID = "ua-onboarding-title"; + +export default function OnboardingOverlay({ onDismiss }: Props) { + const { t } = useI18n(); + const STEPS = t.onboarding.steps; + const [stepIdx, setStepIdx] = useState(0); + + // Capture-phase Escape handler — runs before the global keydown chain so we + // can stopPropagation() and prevent it from also firing. + useEffect(() => { + const handler = (e: KeyboardEvent) => { + if (e.key === "Escape") { + e.stopPropagation(); + onDismiss(false); + } + }; + document.addEventListener("keydown", handler, true); + return () => document.removeEventListener("keydown", handler, true); + }, [onDismiss]); + + const isFirst = stepIdx === 0; + const isLast = stepIdx === STEPS.length - 1; + const step = STEPS[stepIdx]; + + return ( +
{ + if (e.target === e.currentTarget) onDismiss(false); + }} + > + +
+
+ 0{stepIdx + 1} + / 0{STEPS.length} + + {t.onboarding.header} +
+ +

+ {step.title} +

+

{step.body}

+ {step.hint && ( +
+ · + {step.hint} +
+ )} + +
+ {STEPS.map((_, i) => ( +
+ ))} +
+ +
+ +
+ {!isFirst && ( + + )} + {!isLast ? ( + + ) : ( + + )} +
+
+
+ ); +} + +const KEYFRAMES = `@keyframes ua-fade-in { from { opacity: 0 } to { opacity: 1 } }`; + +const overlayStyle: React.CSSProperties = { + position: "fixed", + inset: 0, + background: "rgba(0, 0, 0, 0.78)", + backdropFilter: "blur(6px)", + zIndex: 9999, + display: "flex", + alignItems: "center", + justifyContent: "center", + padding: 16, + fontFamily: "var(--font-sans)", + animation: "ua-fade-in 0.4s cubic-bezier(0.22, 1, 0.36, 1)", +}; + +const cardStyle: React.CSSProperties = { + background: "var(--color-elevated)", + color: "var(--color-text-primary)", + maxWidth: 580, + width: "100%", + padding: "48px 48px 36px", + border: "1px solid var(--color-border-subtle)", + borderTop: "2px solid var(--color-accent)", + position: "relative", +}; + +const tagStyle: React.CSSProperties = { + fontSize: "0.72rem", + letterSpacing: "0.3em", + color: "var(--color-text-muted)", + textTransform: "uppercase", + marginBottom: 24, + display: "flex", + alignItems: "center", + flexWrap: "wrap", + gap: 4, +}; + +const numStyle: React.CSSProperties = { + fontFamily: "var(--font-heading)", + color: "var(--color-accent)", + fontSize: "0.9rem", + letterSpacing: "0.1em", + marginRight: 4, +}; + +const dotStyle: React.CSSProperties = { + width: 4, + height: 4, + background: "var(--color-accent)", + borderRadius: "50%", + margin: "0 12px", +}; + +const titleStyle: React.CSSProperties = { + fontFamily: "var(--font-heading)", + fontSize: "1.7rem", + fontWeight: 400, + letterSpacing: "0.02em", + lineHeight: 1.3, + marginBottom: 16, + color: "var(--color-text-primary)", +}; + +const bodyStyle: React.CSSProperties = { + fontSize: "0.98rem", + lineHeight: 1.7, + color: "var(--color-text-secondary)", + marginBottom: 0, +}; + +const hintStyle: React.CSSProperties = { + margin: "20px 0 0", + padding: "12px 18px", + borderLeft: "2px solid var(--color-border-medium)", + background: "var(--color-accent-overlay-bg)", + fontSize: "0.86rem", + color: "var(--color-accent)", + fontStyle: "italic", +}; + +const progressTrackStyle: React.CSSProperties = { + display: "flex", + gap: 6, + marginTop: 36, + marginBottom: 28, +}; + +const dotProgressStyle: React.CSSProperties = { + height: 4, + borderRadius: 2, + transition: "width 0.5s cubic-bezier(0.22, 1, 0.36, 1), background 0.3s", +}; + +const btnRowStyle: React.CSSProperties = { + display: "flex", + alignItems: "center", + gap: 10, +}; + +const btnStyle: React.CSSProperties = { + padding: "10px 22px", + fontSize: "0.82rem", + letterSpacing: "0.12em", + textTransform: "uppercase", + border: "1px solid", + cursor: "pointer", + fontFamily: "inherit", + transition: "all 0.3s cubic-bezier(0.22, 1, 0.36, 1)", + fontWeight: 400, +}; + +const btnGhostStyle: React.CSSProperties = { + background: "transparent", + borderColor: "var(--color-border-medium)", + color: "var(--color-text-muted)", +}; + +const btnPrimaryStyle: React.CSSProperties = { + background: "var(--color-accent)", + borderColor: "var(--color-accent)", + color: "var(--color-root)", + fontWeight: 500, +}; diff --git a/Understand-Anything-main/understand-anything-plugin/packages/dashboard/src/components/PathFinderModal.tsx b/Understand-Anything-main/understand-anything-plugin/packages/dashboard/src/components/PathFinderModal.tsx new file mode 100644 index 0000000..3e0e3c0 --- /dev/null +++ b/Understand-Anything-main/understand-anything-plugin/packages/dashboard/src/components/PathFinderModal.tsx @@ -0,0 +1,311 @@ +import { useEffect, useRef, useState } from "react"; +import { useDashboardStore } from "../store"; + +interface PathFinderModalProps { + isOpen: boolean; + onClose: () => void; +} + +export default function PathFinderModal({ isOpen, onClose }: PathFinderModalProps) { + const graph = useDashboardStore((s) => s.graph); + const selectNode = useDashboardStore((s) => s.selectNode); + const [fromNodeId, setFromNodeId] = useState(""); + const [toNodeId, setToNodeId] = useState(""); + const [path, setPath] = useState(null); + const [searching, setSearching] = useState(false); + const modalRef = useRef(null); + + // Close on outside click + useEffect(() => { + if (!isOpen) return; + + const handleClickOutside = (e: MouseEvent) => { + if (modalRef.current && !modalRef.current.contains(e.target as Node)) { + onClose(); + } + }; + + document.addEventListener("mousedown", handleClickOutside); + return () => document.removeEventListener("mousedown", handleClickOutside); + }, [isOpen, onClose]); + + // Close on Escape + useEffect(() => { + if (!isOpen) return; + + const handleEscape = (e: KeyboardEvent) => { + if (e.key === "Escape") { + onClose(); + } + }; + + document.addEventListener("keydown", handleEscape); + return () => document.removeEventListener("keydown", handleEscape); + }, [isOpen, onClose]); + + if (!isOpen || !graph) return null; + + const nodes = graph.nodes; + const edges = graph.edges; + + // BFS to find shortest path + const findPath = () => { + if (!fromNodeId || !toNodeId || fromNodeId === toNodeId) { + setPath(null); + return; + } + + setSearching(true); + + // Build adjacency list (bidirectional traversal for path finding) + const adjacency = new Map(); + for (const edge of edges) { + if (!adjacency.has(edge.source)) { + adjacency.set(edge.source, []); + } + adjacency.get(edge.source)!.push(edge.target); + // Also traverse in reverse so we can find paths through backward edges + if (!adjacency.has(edge.target)) { + adjacency.set(edge.target, []); + } + adjacency.get(edge.target)!.push(edge.source); + } + + // BFS + const queue: Array<{ nodeId: string; path: string[] }> = [ + { nodeId: fromNodeId, path: [fromNodeId] }, + ]; + const visited = new Set([fromNodeId]); + + while (queue.length > 0) { + const { nodeId, path: currentPath } = queue.shift()!; + + if (nodeId === toNodeId) { + setPath(currentPath); + setSearching(false); + return; + } + + const neighbors = adjacency.get(nodeId) ?? []; + for (const neighbor of neighbors) { + if (!visited.has(neighbor)) { + visited.add(neighbor); + queue.push({ nodeId: neighbor, path: [...currentPath, neighbor] }); + } + } + } + + // No path found + setPath([]); + setSearching(false); + }; + + const handleNodeClick = (nodeId: string) => { + selectNode(nodeId); + onClose(); + }; + + const nodeMap = new Map(nodes.map((n) => [n.id, n])); + + return ( +
+
+ {/* Header */} +
+
+ + + +

Dependency Path Finder

+
+ +
+ + {/* Body */} +
+

+ Find the shortest path between two nodes in the dependency graph. +

+ + {/* From Node */} +
+ + +
+ + {/* To Node */} +
+ + +
+ + {/* Find Path Button */} + + + {/* Path Result */} + {path !== null && ( +
+ {path.length === 0 ? ( +
+ + + +

No path found between these nodes.

+
+ ) : ( +
+
+ + + +

+ Path Found ({path.length} nodes) +

+
+
+ {path.map((nodeId, idx) => { + const node = nodeMap.get(nodeId); + if (!node) return null; + + const isLast = idx === path.length - 1; + + return ( +
+ + {!isLast && ( +
+ + + +
+ )} +
+ ); + })} +
+
+ )} +
+ )} +
+ + {/* Footer */} +
+ +
+
+
+ ); +} diff --git a/Understand-Anything-main/understand-anything-plugin/packages/dashboard/src/components/PersonaSelector.tsx b/Understand-Anything-main/understand-anything-plugin/packages/dashboard/src/components/PersonaSelector.tsx new file mode 100644 index 0000000..941e3a2 --- /dev/null +++ b/Understand-Anything-main/understand-anything-plugin/packages/dashboard/src/components/PersonaSelector.tsx @@ -0,0 +1,46 @@ +import { useDashboardStore } from "../store"; +import { useI18n } from "../contexts/I18nContext"; +import type { Persona } from "../store"; + +export default function PersonaSelector() { + const persona = useDashboardStore((s) => s.persona); + const setPersona = useDashboardStore((s) => s.setPersona); + const { t } = useI18n(); + + const personas: { id: Persona; label: string; description: string }[] = [ + { + id: "non-technical", + label: t.personaSelector.overview, + description: t.personaSelector.overviewDesc, + }, + { + id: "junior", + label: t.personaSelector.learn, + description: t.personaSelector.learnDesc, + }, + { + id: "experienced", + label: t.personaSelector.deepDive, + description: t.personaSelector.deepDiveDesc, + }, + ]; + + return ( +
+ {personas.map((p) => ( + + ))} +
+ ); +} diff --git a/Understand-Anything-main/understand-anything-plugin/packages/dashboard/src/components/PortalNode.tsx b/Understand-Anything-main/understand-anything-plugin/packages/dashboard/src/components/PortalNode.tsx new file mode 100644 index 0000000..04f9421 --- /dev/null +++ b/Understand-Anything-main/understand-anything-plugin/packages/dashboard/src/components/PortalNode.tsx @@ -0,0 +1,64 @@ +import { memo } from "react"; +import { Handle, Position } from "@xyflow/react"; +import type { NodeProps, Node } from "@xyflow/react"; +import { getLayerColor } from "./LayerLegend"; + +export interface PortalNodeData extends Record { + targetLayerId: string; + targetLayerName: string; + connectionCount: number; + layerColorIndex: number; + onNavigate: (layerId: string) => void; +} + +export type PortalFlowNode = Node; + +function PortalNode({ + data, +}: NodeProps) { + const color = getLayerColor(data.layerColorIndex); + + return ( +
data.onNavigate(data.targetLayerId)} + > + + +
+
+
+ + + {data.targetLayerName} + +
+ → +
+
+ {data.connectionCount} connection{data.connectionCount !== 1 ? "s" : ""} +
+
+ + +
+ ); +} + +export default memo(PortalNode); diff --git a/Understand-Anything-main/understand-anything-plugin/packages/dashboard/src/components/ProjectOverview.tsx b/Understand-Anything-main/understand-anything-plugin/packages/dashboard/src/components/ProjectOverview.tsx new file mode 100644 index 0000000..c9cb478 --- /dev/null +++ b/Understand-Anything-main/understand-anything-plugin/packages/dashboard/src/components/ProjectOverview.tsx @@ -0,0 +1,222 @@ +import { useDashboardStore } from "../store"; +import { useI18n } from "../contexts/I18nContext"; + +export default function ProjectOverview() { + const graph = useDashboardStore((s) => s.graph); + const startTour = useDashboardStore((s) => s.startTour); + const { t } = useI18n(); + + if (!graph) { + return ( +
+

{t.common.loading}

+
+ ); + } + + const { project, nodes, edges, layers } = graph; + const hasTour = graph.tour.length > 0; + + const typeCounts: Record = {}; + for (const node of nodes) { + typeCounts[node.type] = (typeCounts[node.type] ?? 0) + 1; + } + + const complexityCounts: Record = { simple: 0, moderate: 0, complex: 0 }; + for (const node of nodes) { + if (node.complexity) { + complexityCounts[node.complexity] = (complexityCounts[node.complexity] ?? 0) + 1; + } + } + + const nodeConnections = new Map(); + for (const edge of edges) { + nodeConnections.set(edge.source, (nodeConnections.get(edge.source) ?? 0) + 1); + nodeConnections.set(edge.target, (nodeConnections.get(edge.target) ?? 0) + 1); + } + const topNodes = Array.from(nodeConnections.entries()) + .sort((a, b) => b[1] - a[1]) + .slice(0, 5) + .map(([nodeId, count]) => { + const node = nodes.find((n) => n.id === nodeId); + return { id: nodeId, name: node?.name ?? nodeId, count }; + }); + + const avgConnections = nodes.length > 0 ? (edges.length * 2 / nodes.length).toFixed(1) : "0"; + + const categoryBreakdown = [ + { label: t.projectOverview.code, color: "var(--color-node-file)", count: (typeCounts["file"] ?? 0) + (typeCounts["function"] ?? 0) + (typeCounts["class"] ?? 0) + (typeCounts["module"] ?? 0) + (typeCounts["concept"] ?? 0) }, + { label: t.projectOverview.config, color: "var(--color-node-config)", count: typeCounts["config"] ?? 0 }, + { label: t.projectOverview.docs, color: "var(--color-node-document)", count: typeCounts["document"] ?? 0 }, + { label: t.projectOverview.infra, color: "var(--color-node-service)", count: (typeCounts["service"] ?? 0) + (typeCounts["resource"] ?? 0) + (typeCounts["pipeline"] ?? 0) }, + { label: t.projectOverview.data, color: "var(--color-node-table)", count: (typeCounts["table"] ?? 0) + (typeCounts["endpoint"] ?? 0) + (typeCounts["schema"] ?? 0) }, + { label: t.projectOverview.domain, color: "var(--color-node-concept)", count: (typeCounts["domain"] ?? 0) + (typeCounts["flow"] ?? 0) + (typeCounts["step"] ?? 0) }, + ]; + const hasNonCodeNodes = categoryBreakdown.some((c) => c.label !== t.projectOverview.code && c.count > 0); + + return ( +
+ {/* Project name */} +

{project.name}

+

{project.description}

+ + {/* Stats grid */} +
+
+
{nodes.length}
+
{t.projectOverview.nodes}
+
+
+
{edges.length}
+
{t.projectOverview.edges}
+
+
+
{layers.length}
+
{t.projectOverview.layers}
+
+
+
{Object.keys(typeCounts).length}
+
{t.projectOverview.types}
+
+
+ + {/* File Types breakdown */} + {hasNonCodeNodes && ( +
+

{t.projectOverview.fileTypes}

+
+ {categoryBreakdown.filter((c) => c.count > 0).map((cat) => ( +
+ + {cat.label} + {cat.count} +
+ ))} +
+
+ )} + + {/* Languages */} + {project.languages.length > 0 && ( +
+

{t.projectOverview.languages}

+
+ {project.languages.map((lang) => ( + + {lang} + + ))} +
+
+ )} + + {/* Frameworks */} + {project.frameworks.length > 0 && ( +
+

{t.projectOverview.frameworks}

+
+ {project.frameworks.map((fw) => ( + + {fw} + + ))} +
+
+ )} + + {/* Node Type Breakdown */} +
+

{t.projectOverview.nodeTypeDistribution}

+
+ {Object.entries(typeCounts) + .sort((a, b) => b[1] - a[1]) + .map(([type, count]) => { + const percentage = ((count / nodes.length) * 100).toFixed(0); + return ( +
+
+ {type} + {count} ({percentage}%) +
+
+
+
+
+ ); + })} +
+
+ + {/* Complexity Breakdown */} + {Object.values(complexityCounts).some((c) => c > 0) && ( +
+

{t.projectOverview.complexityDistribution}

+
+
+
{complexityCounts.simple}
+
{t.projectOverview.simple}
+
+
+
{complexityCounts.moderate}
+
{t.projectOverview.moderate}
+
+
+
{complexityCounts.complex}
+
{t.projectOverview.complex}
+
+
+
+ )} + + {/* Top Connected Nodes */} + {topNodes.length > 0 && ( +
+

{t.projectOverview.mostConnectedNodes}

+
+ {topNodes.map((node, idx) => ( +
+
+ {idx + 1} +
+ {node.name} + {node.count} +
+ ))} +
+
+ )} + + {/* Average Connections */} +
+
+ {t.projectOverview.avgConnectionsPerNode} + {avgConnections} +
+
+ + {/* Analyzed at */} +
+ {t.common.analyzed}: {new Date(project.analyzedAt).toLocaleDateString(undefined, { year: 'numeric', month: 'short', day: 'numeric' })} +
+ + {/* Start Tour button */} + {hasTour && ( + + )} +
+ ); +} diff --git a/Understand-Anything-main/understand-anything-plugin/packages/dashboard/src/components/RagAssistant.tsx b/Understand-Anything-main/understand-anything-plugin/packages/dashboard/src/components/RagAssistant.tsx new file mode 100644 index 0000000..6198ef3 --- /dev/null +++ b/Understand-Anything-main/understand-anything-plugin/packages/dashboard/src/components/RagAssistant.tsx @@ -0,0 +1,328 @@ +import { useMemo, useState } from "react"; +import { useDashboardStore } from "../store"; + +type AnswerMode = "search" | "llm"; + +interface MatchReason { + type: string; + field?: string; + message: string; + score: number; +} + +interface RagHit { + chunkId: string; + nodeId: string; + docTitle: string; + docPath: string; + sectionTitle: string; + chunkType: string; + layer: string; + score: number; + scores: { + exact: number; + fuzzy: number; + semantic: number; + titleBoost: number; + sectionBoost: number; + directoryBoost: number; + chunkTypeBoost: number; + }; + snippet: string; + evidenceContent?: string; + reasons: MatchReason[]; +} + +interface LlmSettings { + enabled: boolean; + provider: "auto" | "openai" | "routin-plan"; + endpoint: string; + model: string; + apiKey: string; +} + +interface EvidenceDecision { + allowed: boolean; + confidence: "high" | "medium" | "low" | "none"; + reason: string; +} + +interface RequestStatus { + stage?: string; + startedAt?: string; + endpoint?: string; + protocol?: string; + elapsedMs?: number; + rawShape?: string[]; +} + +interface RagResponse { + ok: boolean; + mode?: string; + query?: unknown; + decision?: EvidenceDecision; + answer?: string; + hits?: RagHit[]; + requestStatus?: RequestStatus; + error?: { + message?: string; + name?: string; + status?: number; + }; +} + +const SETTINGS_KEY = "ua-rag-llm-settings-v2"; + +function loadSettings(): LlmSettings { + if (typeof window === "undefined") return { enabled: false, provider: "auto", endpoint: "http://localhost:11434/v1", model: "qwen2.5:7b", apiKey: "" }; + try { + const raw = window.localStorage.getItem(SETTINGS_KEY); + if (raw) return { enabled: false, provider: "auto", endpoint: "http://localhost:11434/v1", model: "qwen2.5:7b", apiKey: "", ...JSON.parse(raw) }; + } catch { + } + return { enabled: false, provider: "auto", endpoint: "http://localhost:11434/v1", model: "qwen2.5:7b", apiKey: "" }; +} + +function saveSettings(settings: LlmSettings): void { + if (typeof window === "undefined") return; + window.localStorage.setItem(SETTINGS_KEY, JSON.stringify(settings)); +} + +function stageLabel(stage?: string): string { + switch (stage) { + case "search": return "本地检索中"; + case "evidence_rejected": return "证据不足，未调用模型"; + case "local_answer": return "本地回答"; + case "llm_done": return "模型回答完成"; + case "llm_failed": return "模型调用失败"; + default: return stage || "待请求"; + } +} + +async function postJson(url: string, payload: unknown): Promise<{ status: number; data: T }> { + const response = await fetch(url, { + method: "POST", + headers: { "Content-Type": "application/json" }, + body: JSON.stringify(payload), + }); + const text = await response.text(); + let data: T; + try { + data = text ? JSON.parse(text) as T : {} as T; + } catch { + data = { ok: false, error: { message: text || "响应不是 JSON" } } as T; + } + return { status: response.status, data }; +} + +export default function RagAssistant({ onClose }: { onClose: () => void }) { + const graph = useDashboardStore((s) => s.graph); + const navigateToNodeInLayer = useDashboardStore((s) => s.navigateToNodeInLayer); + const [question, setQuestion] = useState(""); + const [submittedQuestion, setSubmittedQuestion] = useState(""); + const [mode, setMode] = useState("search"); + const [settings, setSettings] = useState(loadSettings); + const [answer, setAnswer] = useState(""); + const [hits, setHits] = useState([]); + const [decision, setDecision] = useState(null); + const [requestStatus, setRequestStatus] = useState({}); + const [loading, setLoading] = useState(false); + const [testing, setTesting] = useState(false); + const [error, setError] = useState(null); + const [showSettings, setShowSettings] = useState(false); + const [selectedHit, setSelectedHit] = useState(null); + + const nodeCount = graph?.nodes.length ?? 0; + const docCount = useMemo(() => graph?.nodes.filter((node) => node.id.startsWith("doc:")).length ?? 0, [graph]); + + const updateSettings = (patch: Partial) => { + const next = { ...settings, ...patch }; + setSettings(next); + saveSettings(next); + }; + + const submit = async () => { + const trimmed = question.trim(); + setSubmittedQuestion(trimmed); + setError(null); + setAnswer(""); + setHits([]); + setSelectedHit(null); + setDecision(null); + setRequestStatus({ stage: mode === "llm" ? "search" : "search", startedAt: new Date().toISOString() }); + if (!trimmed) { + setAnswer("请输入要检索或提问的内容。"); + return; + } + setLoading(true); + try { + const endpoint = mode === "llm" ? "/api/rag/answer" : "/api/rag/search"; + const { status, data } = await postJson(endpoint, { + query: trimmed, + topK: 16, + llm: settings, + }); + setRequestStatus(data.requestStatus || { stage: mode === "llm" ? "llm_done" : "local_answer" }); + setDecision(data.decision || null); + setHits(data.hits || []); + setAnswer(data.answer || "暂无该需求描述。"); + if (!data.ok) { + const message = data.error?.message || `请求失败：HTTP ${status}`; + setError(message); + } + } catch (err) { + setError(err instanceof Error ? err.message : String(err)); + setRequestStatus({ stage: "llm_failed" }); + setAnswer("请求失败，未能获取检索结果。"); + } finally { + setLoading(false); + } + }; + + const testModel = async () => { + setTesting(true); + setError(null); + setRequestStatus({ stage: "模型连接测试中", startedAt: new Date().toISOString() }); + try { + const { status, data } = await postJson("/api/llm/test", settings); + if (!data.ok) { + setRequestStatus({ stage: "llm_failed", endpoint: data.endpoint, elapsedMs: data.elapsedMs }); + setError(data.error?.message || `模型连接测试失败：HTTP ${status}`); + } else { + setRequestStatus({ stage: "llm_done", endpoint: data.endpoint, elapsedMs: data.elapsedMs }); + setAnswer(`模型连接成功。\nEndpoint：${data.endpoint || settings.endpoint}\n耗时：${data.elapsedMs ?? "?"} ms\n返回：${data.answer || ""}`); + } + } catch (err) { + setRequestStatus({ stage: "llm_failed" }); + setError(err instanceof Error ? err.message : String(err)); + } finally { + setTesting(false); + } + }; + + return ( +
+
event.stopPropagation()}> +
+
+

知识库混合 RAG 检索 / 问答

+

前端只发请求到本地后端；后端先检索证据，再代理调用模型并返回明确错误。

+
+ +
+ +
+
+ + + +
图谱节点：{nodeCount}，文档节点：{docCount}
+
+ + {showSettings && ( +
+ + + updateSettings({ endpoint: e.target.value })} placeholder="Base URL；RoutIn Plan 填 https://api.routin.ai/plan/v1" className="bg-surface text-text-primary text-xs rounded px-2 py-1.5 border border-border-subtle focus:outline-none focus:border-accent/50" /> + updateSettings({ model: e.target.value })} placeholder="model" className="bg-surface text-text-primary text-xs rounded px-2 py-1.5 border border-border-subtle focus:outline-none focus:border-accent/50" /> + +
+
plan- key 会走 /messages
+ updateSettings({ apiKey: e.target.value })} placeholder="API Key；通过本地后端代理发送，不从浏览器直连模型" className="md:col-span-3 bg-surface text-text-primary text-xs rounded px-2 py-1.5 border border-border-subtle focus:outline-none focus:border-accent/50" /> +
+ )} + +
+ \n
\n ${renderSourceNote()}\n `;\n document.getElementById(\"modalFoot\").innerHTML = `\n \n \n `;\n document.getElementById(\"modalMask\").classList.add(\"open\");\n document.getElementById(\"modal\").classList.add(\"open\");\n }\n\n function closeModal() {\n document.getElementById(\"modalMask\").classList.remove(\"open\");\n document.getElementById(\"modal\").classList.remove(\"open\");\n }\n\n function showToast(message) {\n const toast = document.getElementById(\"toast\");\n const item = document.createElement(\"div\");\n item.className = \"toast-item\";\n item.textContent = message;\n toast.appendChild(item);\n window.setTimeout(() => item.remove(), 2600);\n }\n\n function render() {\n renderNav();\n const content = document.getElementById(\"content\");\n updateTopContext();\n if (state.route === \"dashboard\") {\n content.innerHTML = renderDashboard();\n } else {\n content.innerHTML = renderListPage(state.route);\n }\n }\n\n function updateTopContext() {\n const routeMeta = routes.find((item) => item.id === state.route);\n const title = document.getElementById(\"topPageTitle\");\n const subtitle = document.getElementById(\"topPageSubtitle\");\n if (title && routeMeta) title.textContent = routeMeta.label === \"工作台\" ? \"经营总览\" : routeMeta.label;\n if (subtitle) {\n const scopeText = {\n all: \"全部部门\",\n amazon: \"Amazon 运营\",\n user_ops: \"用户运营\",\n support: \"客服\"\n }[state.scope] || \"全部部门\";\n subtitle.textContent = `系统管理员（最高权限） · ${scopeText}`;\n }\n document.querySelectorAll(\".top-period button\").forEach((button) => {\n button.classList.toggle(\"active\", button.dataset.period === state.period);\n });\n }\n\n function bindEvents() {\n document.body.addEventListener(\"click\", (event) => {\n const target = event.target.closest(\"button\");\n if (!target) return;\n const route = target.dataset.route;\n if (route) {\n setRoute(route, target.dataset.tab || \"all\");\n return;\n }\n if (target.dataset.tab) {\n state.activeTab = target.dataset.tab;\n render();\n return;\n }\n if (target.dataset.detail) {\n openDrawer(target.dataset.detail, target.dataset.id);\n return;\n }\n const action = target.dataset.action;\n if (action === \"toggle-status\") {\n state.statusExpanded = !state.statusExpanded;\n render();\n showToast(state.statusExpanded ? \"核心看板已展开全部事项\" : \"核心看板已收起次要事项\");\n return;\n }\n if (action === \"priority-status\") {\n state.statusPriorityFirst = !state.statusPriorityFirst;\n render();\n showToast(state.statusPriorityFirst ? \"已按重要度优先排序\" : \"已恢复原始顺序\");\n return;\n }\n if (action === \"close-drawer\") closeDrawer();\n if (action === \"close-modal\") closeModal();\n if (action === \"open-modal\") openModal(target.dataset.modal, target.dataset.target);\n if (action === \"submit-modal\") {\n closeModal();\n showToast(target.dataset.message || \"操作成功\");\n }\n if (action === \"toast\") showToast(target.dataset.message || \"已执行\");\n });\n\n document.getElementById(\"drawerMask\").addEventListener(\"click\", closeDrawer);\n document.getElementById(\"modalMask\").addEventListener(\"click\", closeModal);\n document.getElementById(\"globalSearch\").addEventListener(\"input\", (event) => {\n state.keyword = event.target.value;\n });\n document.getElementById(\"scopeSelect\").addEventListener(\"change\", (event) => {\n state.scope = event.target.value;\n updateTopContext();\n showToast(`已切换数据范围：${event.target.options[event.target.selectedIndex].text}`);\n });\n document.body.addEventListener(\"change\", (event) => {\n const input = event.target.closest(\"[data-time]\");\n if (!input) return;\n const key = input.dataset.time;\n if (key === \"startDate\" || key === \"endDate\") {\n state[key] = input.value;\n showToast(`时间范围已更新：${state.startDate} 至 ${state.endDate}`);\n }\n });\n document.body.addEventListener(\"click\", (event) => {\n const target = event.target.closest(\"[data-period]\");\n if (!target) return;\n state.period = target.dataset.period;\n render();\n showToast(`已切换为${state.period === \"day\" ? \"日\" : state.period === \"week\" ? \"周\" : \"月\"}视角`);\n });\n window.addEventListener(\"hashchange\", readHash);\n }\n\n function readHash() {\n const hash = window.location.hash.replace(\"#\", \"\");\n if (!hash) return;\n const [route, tab] = hash.split(\":\");\n if (routes.some((item) => item.id === route)) {\n state.route = route;\n state.activeTab = tab || \"all\";\n render();\n }\n }\n\n bindEvents();\n readHash();\n render();\n \n\n\n", + "wikilinks": [], + "category": "layer-requirements" + } + }, + { + "id": "doc:05_需求文档/20260517_USER评价业务闭环_共用能力图与渠道专属流程_v2.2", + "type": "document", + "name": "USER 评价业务闭环 — 共用能力图与渠道专属流程 v2.2", + "filePath": "05_需求文档/20260517_USER评价业务闭环_共用能力图与渠道专属流程_v2.2.md", + "summary": "USER 评价业务闭环 — 共用能力图与渠道专属流程 v2.2 文件信息 文件名称： 20260517 USER评价业务闭环 共用能力图与渠道专属流程 v2.2.md 项目路径： C:\\XCODE\\USER 当前版本： v2.2 最近更新： 2026 05 17 上游基线： 工作基线 v1.2 20260517 USER评价业务闭环主流程与后续工作基线 v1", + "tags": [ + "05_需求文档", + "需求文档" + ], + "complexity": "complex", + "knowledgeMeta": { + "content": "# USER 评价业务闭环 — 共用能力图与渠道专属流程 v2.2\n\n## 文件信息\n\n- 文件名称：`20260517_USER评价业务闭环_共用能力图与渠道专属流程_v2.2.md`\n- 项目路径：`C:\\XCODE\\USER`\n- 当前版本：`v2.2`\n- 最近更新：`2026-05-17`\n- 上游基线：[工作基线 v1.2](20260517_USER评价业务闭环主流程与后续工作基线_v1.2.md)\n- 前一版本：\n - `20260517_USER评价业务闭环_共用能力图与渠道专属流程_v1.1.md`\n - `20260517_USER评价业务闭环点击操作模拟_v2.1.md`\n- 文件目的：在基线 v1.2 确认的额度规则和真实人体系上，拆出系统级共用能力图与 IM / EDM / APP / TEL / 客服 / KOC-KOL 六条渠道的专属执行流程，每个节点标注 查 / 写 / 状态 / 提醒 / 拦截。\n- 资料依据：IM 推送业务流脑图、电话业务流程知识库、客服相关模块、后台回评工作流对接事项、状态机 v4、页面设计 v4、原型 HTML。\n- 使用方式：先读基线 v1.2，再读本文件；第三步数据流设计直接引用本文件的节点规则表和数据对象建议。本文件取代 `v1.1` 与 `v2.1` 作为当前第二步主稿。\n\n---\n\n### 1. 总览\n\n```mermaid\nflowchart LR\n A[\"销售 / ASIN数据形成\"] --> B[\"需求触发\"]\n B --> C[\"用户运营评估\"]\n C --> D{\"计划类型\"}\n D --> E[\"评价型计划
推新 / 回评\"]\n D --> F[\"免评计划\"]\n E --> G[\"执行拆解\"]\n F --> G\n G --> SHARED[\"共用能力层\"]\n SHARED --> I1[\"IM\"]\n SHARED --> I2[\"EDM\"]\n SHARED --> I3[\"APP\"]\n SHARED --> I4[\"TEL\"]\n SHARED --> I5[\"客服\"]\n SHARED --> I6[\"KOC / KOL\"]\n I1 & I2 & I3 & I4 & I5 --> J[\"用户互动 / 服务 / 跟进\"]\n J --> K[\"用户真实提交评价\"]\n K --> L[\"计入累计评价额度（12）\"]\n L --> M[\"Amazon展示确认\"]\n M --> N[\"ASIN / 计划 / 用户 / 风险结果回流\"]\n I6 --> O[\"免评结果跟踪\"]\n O --> N\n N --> C\n\n style SHARED fill:#f5f5f5,stroke:#333,stroke-width:3px\n```\n\n#### 节点审查标准\n\n每个关键节点按以下 8 问审：\n\n| ## | 问题 | 标注 |\n| --- | --- | --- |\n| 1 | 入口是什么 | 触发条件 |\n| 2 | 先查什么 | **查** |\n| 3 | 判断什么 | 分岔条件 |\n| 4 | 写什么 | **写** |\n| 5 | 状态怎么变 | **状态** |\n| 6 | 何时提醒 | **提醒** |\n| 7 | 何时拦截 | **拦截** |\n| 8 | 何时转人工 | **转人工** |\n\n---\n\n## 第一部分：共用能力图\n\n### 2. 共用能力一：真实人识别与用户上下文卡\n\n#### 2.1 流程图\n\n```mermaid\nflowchart TB\n A[\"新互动 / 新订单 / 新任务\"] --> B[\"读取身份线索\"]\n B --> B1[\"JOYHUB ID\"]\n B --> B2[\"邮箱\"]\n B --> B3[\"电话\"]\n B --> B4[\"设备号\"]\n B --> B5[\"订单号\"]\n B --> B6[\"姓名 + 地址\"]\n\n B1 & B2 & B3 & B4 & B5 & B6 --> C[\"归并真实人\"]\n C --> D{\"匹配结果\"}\n D -->|\"标准化姓名+地址一致\"| E[\"强关联 → 同一真实人\"]\n D -->|\"地址一致姓名不同\"| F[\"家庭/关联风险 → 不直接合并\"]\n D -->|\"多线索交叉\"| G[\"按设备/电话/邮箱/收款信息权重合并\"]\n\n E & F & G --> H[\"生成 / 更新真实人 ID\"]\n H --> I[\"拉取用户上下文卡\"]\n\n I --> J[\"历史交易
订单/购买/退款/返款/ASIN\"]\n I --> K[\"历史服务
工单/聊天/电话/承诺/提醒\"]\n I --> L[\"历史风险
黑名单/诈骗/关联/异常\"]\n I --> M[\"当前设备
型号/版本/换机记录\"]\n I --> N[\"触达历史
IM/EDM/APP/TEL 近期记录\"]\n\n J & K & L & M & N --> O[\"上下文卡快照 → 供客服/运营/风险使用\"]\n```\n\n#### 2.2 用户上下文卡字段组\n\n| 字段组 | 具体内容 |\n| --- | --- |\n| 当前身份 | JOYHUB ID、邮箱、电话、当前订单、真实人 ID |\n| 真实人归并 | 姓名+地址（标准化）、设备号、电话、邮箱、Profile ID、收款信息、关联账号列表 |\n| 历史交易 | 历史订单、购买频次、最近购买、历史退款、历史返款、目标 ASIN 购买记录 |\n| 历史服务 | 历史工单、聊天记录、通话记录、已承诺事项、已发送提醒、工单关闭原因 |\n| 历史风险 | 黑名单标记、强关联记录、弱关联记录、疑似诈骗、双重退款、异常订单 |\n| 当前设备 | 设备号摘要、设备型号/类型、系统版本、APP 版本、最近设备变化（换机/多设备） |\n| 触达历史 | IM 最近触达/回复/退订、EDM 最近打开/点击/退订、APP 最近 Push、TEL 最近拨打 |\n\n#### 2.3 节点规则\n\n| 节点 | 查 | 写 | 状态 | 提醒 | 拦截 |\n| --- | --- | --- | --- | --- | --- |\n| 归并真实人 | JOYHUB、邮箱、电话、设备、订单、地址 | 真实人匹配结果、匹配证据、置信度 | 新真实人 / 已存在 | 标准化姓名+地址一致时强提示 | - |\n| 拉取上下文卡 | 交易、工单、风险、设备、触达全量记录 | 上下文快照（含快照时间） | 首次生成 / 增量更新 | 命中黑名单/异常时高亮 | 严重风险标记时阻止自动通过 |\n| 设备变化识别 | 设备号、型号、系统版本、APP版本 | 设备变化记录、变化时间 | 设备正常 / 近期换机 / 多设备 | 近期换机或同设备多账号提示 | - |\n\n---\n\n### 3. 共用能力二：人群生成与画像拆解\n\n#### 3.1 流程图\n\n```mermaid\nflowchart TB\n A[\"计划进入人群生成\"] --> B[\"基础过滤\"]\n B --> B1[\"硬排除：国家/站点/可达性/退订/黑名单/未关闭工单\"]\n\n B1 --> C[\"画像匹配\"]\n C --> C1[\"基础画像：国家/语言/性别/年龄段/注册时间\"]\n C --> C2[\"产品关系：绑定玩具/绑定数量/绑定品类/目标产品\"]\n C --> C3[\"交易画像：历史订单/购买频次/是否买过目标ASIN\"]\n C --> C4[\"行为画像：活跃度/打开率/点击率/历史回评率/配合率\"]\n C --> C5[\"触达画像：各渠道可达性/最近触达/退订\"]\n C --> C6[\"风险画像：黑名单/设备关联/地址关联/退款异常\"]\n C --> C7[\"计划画像：是否参加过推新/回评/免评/最近结果\"]\n\n C1 & C2 & C3 & C4 & C5 & C6 & C7 --> D[\"历史行为评分\"]\n\n D --> E[\"额度与频控校验
（进入 §4 共用能力三）\"]\n E --> F[\"风险复检
（进入 §6 共用能力五）\"]\n F --> G[\"生成候选人群快照 + 排除快照\"]\n```\n\n#### 3.2 画像字段的三类用途\n\n| 类型 | 作用 | 示例字段 |\n| --- | --- | --- |\n| **硬过滤** | 决定能不能进池 | 国家、可达性、黑名单、退订、未关闭工单、额度超限 |\n| **匹配条件** | 决定是否适合当前计划 | 绑定玩具、目标品类、年龄、性别、是否买过目标 ASIN |\n| **排序权重** | 决定触达优先级 | 活跃度、历史回评率、历史配合率、最近互动时间 |\n\n#### 3.3 节点规则\n\n| 节点 | 查 | 写 | 状态 | 提醒 | 拦截 |\n| --- | --- | --- | --- | --- | --- |\n| 基础过滤 | 国家、站点、可达性、退订、黑名单、未关闭工单 | 排除原因记录 | 入池 / 排除 | - | 黑名单/退订/强关联直接排除 |\n| 画像匹配 | 7 组画像字段 | 匹配分组与得分 | 匹配 / 不匹配 / 待补全 | 画像缺失可补全 | - |\n| 历史行为评分 | 活跃、点击、回复、回评率、配合率、投诉 | 评分结果、排序权重 | 高分 / 中分 / 低分 | 低活跃用户降级提醒 | - |\n| 生成快照 | 过滤、匹配、评分、额度、风险全量结果 | 人群快照、排除快照、快照时间 | 已生成 | 排除比例异常时提醒 | 快照为空时拦截 |\n\n---\n\n### 4. 共用能力三：额度台账与频控控制\n\n#### 4.1 已确认额度规则\n\n| 规则 | 统计对象 | 计数口径 | 计数时点 |\n| --- | --- | --- | --- |\n| 每月测评最多 4 次 | 真实人 | 已完成 + 进行中 + 已预占 | - |\n| 每月免评最多 4 次 | 真实人 | 已完成 + 进行中 + 已预占 | - |\n| 累计真实提交评价最多 12 个 | 真实人 | 用户真实提交评价后立即计数 | 用户真实提交评价时 |\n\n#### 4.2 流程图\n\n```mermaid\nflowchart TB\n A[\"识别真实人\"] --> B[\"读取额度台账\"]\n B --> B1[\"本月测评：已完成 / 进行中 / 已预占\"]\n B --> B2[\"本月免评：已完成 / 进行中 / 已预占\"]\n B --> B3[\"累计真实提交：当前 / 上限 12\"]\n B --> B4[\"并发占用：跨计划重复入选检测\"]\n\n B1 & B2 & B3 & B4 --> C{\"额度判断\"}\n C -->|\"剩余 ≥ 本次拟发送\"| D[\"进入普通候选池
→ 预占额度\"]\n C -->|\"剩余不足但 > 0\"| E[\"进入预警池
→ 预占额度 → 发送前人工复核\"]\n C -->|\"已用 + 预占 + 本次 ≥ 上限\"| F[\"排除自动推送\"]\n\n D --> G[\"写入预占记录\"]\n E --> G\n\n G --> H[\"频控复核\"]\n H --> H1[\"渠道频控：IM/EDM/APP/TEL 最近触达间隔\"]\n H --> H2[\"单 ASIN 短期触达次数\"]\n H --> H3[\"用户反感度/投诉/退订状态\"]\n\n H1 & H2 & H3 --> I{\"频控判断\"}\n I -->|通过| J[\"进入发送队列\"]\n I -->|不通过| K[\"延后 / 降频 / 排除\"]\n\n J --> L[\"发送前再次读取最新额度 + 风险\"]\n L --> M{\"最终校验\"}\n M -->|通过| N[\"发送\"]\n M -->|新增超限/风险| O[\"撤出本批次\"]\n```\n\n#### 4.3 额度 vs 频控的区别\n\n| 类别 | 统计维度 | 周期 | 拦截时机 |\n| --- | --- | --- | --- |\n| **渠道频控** | 单渠道触达次数/间隔 | 按日/周/月 | 发送前 |\n| **月度业务额度** | 真实人测评 4 / 免评 4 | 自然月 | 人群生成 + 发送前 |\n| **累计评价额度** | 真实人累计 12 | 永久累计 | 用户提交评价时更新、下次人群生成时判断 |\n| **并发占用控制** | 进行中 + 已预占 + 跨计划重复 | 实时 | 人群生成 + 预占时 |\n\n#### 4.4 节点规则\n\n| 节点 | 查 | 写 | 状态 | 提醒 | 拦截 |\n| --- | --- | --- | --- | --- | --- |\n| 读取额度台账 | 本月测评/免评、累计提交、进行中、已预占 | 当前额度快照 | - | 剩余 ≤ 1 或本批次将打满时预警 | - |\n| 预占额度 | 候选计划、预计发送量、当前剩余 | 额度预占记录 | 已预占 | - | 预计超限阻止进入自动发送 |\n| 频控复核 | IM/EDM/APP/TEL 最近触达、ASIN频次、退订/投诉 | 频控校验结果 | 通过 / 降频 / 排除 | 接近频控上限时提醒 | 超频直接排除 |\n| 发送前终校 | 最新额度、最新风险、最新未关闭工单 | 发送前校验结果 | 准入 / 撤出 | 任何新增异常立即提示 | 新增超限/风险撤出本批次 |\n\n---\n\n### 5. 共用能力四：每次有效互动复检\n\n#### 5.1 流程图\n\n```mermaid\nflowchart TB\n A[\"触发复检的事件\"] --> A1[\"主动推送后回复\"]\n A --> A2[\"再次联系\"]\n A --> A3[\"补充订单号\"]\n A --> A4[\"客服回访\"]\n A --> A5[\"电话来电\"]\n A --> A6[\"退款/返款/继续推送前\"]\n\n A1 & A2 & A3 & A4 & A5 & A6 --> X[\"重新读取四组数据\"]\n\n X --> X1[\"身份：真实人/JOYHUB/邮箱/电话/设备/订单/地址\"]\n X --> X2[\"历史：订单/工单/触达/退款/返款\"]\n X --> X3[\"额度：本月测评/免评/累计提交/进行中/预占\"]\n X --> X4[\"风险：黑名单/强弱关联/双重退款/异常订单\"]\n\n X1 & X2 & X3 & X4 --> Y{\"判断结果\"}\n Y -->|正常 + 额度充足| Z[\"继续业务\"]\n Y -->|弱风险 / 接近额度上限| W[\"继续但显著提示 → 人工关注\"]\n Y -->|强风险 / 额度超限| V[\"暂停当前动作 → 转风险中心或人工复核\"]\n```\n\n#### 5.2 节点规则\n\n| 节点 | 查 | 写 | 状态 | 提醒 | 拦截 |\n| --- | --- | --- | --- | --- | --- |\n| 身份复检 | JOYHUB、邮箱、电话、设备、订单、地址是否变化 | 身份变化记录 | 未变 / 新增关联 / 冲突 | 设备变化/地址变化提示 | - |\n| 历史复检 | 是否有新订单、新工单、新触达、新退款 | 历史变化记录 | 无变化 / 有更新 | 新退款/新工单提示 | - |\n| 额度复检 | 最新测评/免评/累计额度 | 最新额度快照 | 充足 / 预警 / 超限 | 接近上限预警 | 超限拦截 |\n| 风险复检 | 黑名单、强弱关联、双重退款、异常 | 最新风险结果 | 正常 / 弱风险 / 强风险 | 任何命中高亮提醒 | 强关联暂停自动操作 |\n\n---\n\n### 6. 共用能力五：风险判断与黑名单\n\n#### 6.1 风险分层\n\n| 风险类型 | 关联项 | 处理原则 |\n| --- | --- | --- |\n| **强关联** | 邮箱、设备号、电话、收件人姓名+地址、订单号、聊天记录、Profile ID、收款信息 | 一旦命中，直接进入高风险或黑名单链路 |\n| **弱关联** | IP 单独命中、姓名单独命中、同址异名 | 进入高风险观察 + 人工复核，不直接认定诈骗 |\n\n#### 6.2 流程图\n\n```mermaid\nflowchart TB\n A[\"风险信号进入
（新订单同步/触达回应/用户接入/退款申请/再次跟进）\"] --> B[\"强弱关联判断\"]\n\n B --> C{\"关联等级\"}\n C -->|强关联| D[\"高风险 / 黑名单链路\"]\n C -->|弱关联| E[\"高风险观察 + 人工复核\"]\n C -->|无关联| F[\"正常继续\"]\n\n D --> D1[\"拦截继续推送\"]\n D --> D2[\"拦截自动退款\"]\n D --> D3[\"拦截自动放行\"]\n D1 & D2 & D3 --> G[\"回写工单 / 推送 / 计划状态\"]\n G --> H[\"提醒客服 / 用户运营 / 审核人员\"]\n\n E --> E1[\"显著风险提醒\"]\n E1 --> E2[\"人工复核\"]\n E2 --> E3{\"复核结论\"}\n E3 -->|确认风险| D\n E3 -->|排除风险| F\n```\n\n#### 6.3 已确认业务问题\n\n1. **双重退款**：APP/OA 已退款 + 用户又向 Amazon 申请退款 → 需要 Amazon 退款与 OA 返款自动比对\n2. **高风险用户**：一旦标记，支付/返款需要人工复核\n3. **风险可见性**：客服、审核、退款等环节必须都能看到风险提醒\n4. **非 APP 用户盲区**：直接走邮件退款，缺设备/注册邮箱等维度，识别能力下降\n5. **每次互动重判**：风险判断不是一次性的，每次有效互动都要重新执行\n\n#### 6.4 节点规则\n\n| 节点 | 查 | 写 | 状态 | 提醒 | 拦截 |\n| --- | --- | --- | --- | --- | --- |\n| 强弱关联判断 | 邮箱/设备/电话/地址/订单/ProfileID/收款信息/IP | 关联结果、命中维度列表 | 强关联 / 弱关联 / 无 | 命中时高亮命中维度 | - |\n| 高风险链路 | 当前推送/退款/返款状态 | 风险事件、拦截记录 | 已拦截 / 待复核 | 通知所有关联环节 | 拦截继续推送/自动退款/自动放行 |\n| 双重退款检测 | Amazon退款记录 + OA返款记录 | 匹配结果、差异 | 无重复 / 疑似重复 / 确认重复 | 确认重复时强告警 | 确认重复时阻止后续返款 |\n\n---\n\n### 7. 共用能力六：审批工作流\n\n```mermaid\nflowchart LR\n PLAN[\"计划草案\"] --> R1{\"计划类型\"}\n R1 -->|测评计划| A1[\"Amazon运营总监审批\"]\n R1 -->|回评计划| A2[\"Amazon运营总监或指定负责人\"]\n R1 -->|免评计划| A3[\"Amazon运营总监 + 用户负责人\"]\n R1 -->|紧急计划| A4[\"Amazon运营负责人 + 用户负责人 + 主管\"]\n\n A1 & A2 & A3 & A4 --> NEXT[\"周/月推送计划\"]\n NEXT --> N1[\"用户负责人审批\"]\n N1 --> N2[\"渠道负责人审批\"]\n N2 --> APPROVED[\"已批准 → 执行\"]\n```\n\n#### 7.1 审批节点规则\n\n| 节点 | 查 | 写 | 状态 | 提醒 | 拦截 |\n| --- | --- | --- | --- | --- | --- |\n| Amazon运营总监审批 | 计划详情、ASIN健康、风险提醒 | 审批结果、审批意见 | 通过 / 驳回 / 待补充 | 驳回时通知提交人 | - |\n| 用户负责人审批 | 人群快照、额度占用、频控结果 | 审批结果 | 通过 / 驳回 | 额度接近上限时预警 | - |\n| 渠道负责人审批 | 渠道容量、素材、合规 | 审批结果 | 通过 / 驳回 | 素材/文案风险提醒 | 合规风险时拦截 |\n\n---\n\n### 8. 共用能力七：审计与通知中心\n\n| 模块 | 职责 | 关键记录内容 |\n| --- | --- | --- |\n| 状态变更审计 | 所有业务对象的状态流转留痕 | 对象ID、旧状态、新状态、操作人、时间、原因 |\n| 敏感字段访问 | 涉密字段的每次读取记录 | 访问人、访问时间、访问字段、访问上下文 |\n| 导出操作 | 所有数据导出行为留痕 | 导出人、时间、范围、原因、是否含敏感字段 |\n| 人工复核操作 | 所有人工干预决策留痕 | 决策人、决策内容、决策依据、决策时间 |\n| **规则风控提醒** | 触发规则/审核/风控阈值时通知 | 同一ASIN频控过高、同一用户多次推送、设备/邮箱异常、站点任务过密 |\n| **紧急Listing预警** | 评分接近4.2时通知 | ASIN、当前评分、差评摘要、建议动作 |\n| **客服超时提醒** | 工单/答应配合超时通知 | 工单ID、超时类型、超时时长、责任人 |\n| **额度预警** | 额度接近上限时通知 | 真实人、额度类型、已用/上限、受影响计划 |\n\n---\n\n## 第二部分：渠道专属流程图\n\n### 9. 渠道一：IM 推送专属流程\n\n#### 9.1 用户分层与推送策略\n\n```mermaid\nflowchart TB\n U[\"用户注册 + 绑定玩具\"] --> L1{\"识别用户分层\"}\n\n L1 -->|\"A 未参与过
从未走过回评/测评\"| A1[\"推送前校验\"]\n A1 --> A1a[\"查：JOYHUB ID、设备ID、黑名单、绑定产品\"]\n A1 --> A1b{\"设备ID在黑名单？\"}\n A1b -->|是| A2[\"写：打标'长期测评人'
拦截：不推回评/测评卡片
推送：免评产品卡片\"]\n A1b -->|否| A3[\"推送：对应绑定产品的回评卡片
写：推送记录\"]\n\n L1 -->|\"B 已参与过
真实人累计真实提交评价 < 12\"| B1[\"优先催评\"]\n B1 --> B1a[\"查：未回评测评单、真实人累计评价数、标签\"]\n B1 --> B1b[\"推送：催评卡片/消息\"]\n B1b --> B2{\"完成好评提交？\"}\n B2 -->|是| B3[\"写：重新计算真实人累计评价数\"]\n B3 --> B4{\"累计真实提交评价仍 < 12？\"}\n B4 -->|是| B5[\"推送：当日测评计划对应卡片
写：二次转化记录\"]\n B4 -->|否| B6[\"写：打标'长期测评人'→ 推送免评产品\"]\n\n L1 -->|\"C 长期测评人
真实人累计真实提交评价 ≥ 12\"| C1[\"拦截：不推送普通回评/测评卡片
推送：当日免评补单产品
写：免评推送记录\"]\n\n style A2 fill:#fce4ec\n style C1 fill:#fff3e0\n```\n\n#### 9.2 IM 用户提交后的核验与流转\n\n```mermaid\nflowchart TB\n SUBMIT[\"入口：用户在IM中提交回评/测评信息\"] --> ITEMS[\"提交内容：订单号 + 返款账号 + 评论截图/链接\"]\n\n ITEMS --> AUTO[\"查：当前用户标签、关联计划
写：系统自动登记提交记录
状态：待核验\"]\n\n AUTO --> VERIFY[\"订单号核实\"]\n VERIFY --> V1{\"查：是否测评单？\"}\n VERIFY --> V2{\"查：是否为公司产品？\"}\n VERIFY --> V3{\"查：单号格式 xxx-xxxxxxx-xxxxxxx？\"}\n\n V1 & V2 & V3 -->|全部通过| PASS[\"写：登记进系统
状态：已登记\"]\n V1 & V2 & V3 -->|任一不通过| CS[\"转人工：推送客服
状态：待客服处理\"]\n\n CS --> CS1[\"客服沟通用户 → 补充/修正信息\"]\n CS1 --> CS2[\"写：修正记录 → 回到核验\"]\n\n PASS --> CHECK{\"信息完整？\"}\n CHECK -->|完整| FINANCE[\"写：推送财务返款提醒
状态：待返款\"]\n CHECK -->|缺返款账号| TAG1[\"写：打标'xx产品待返款'
提醒：自动通知用户补充
状态：信息待补全\"]\n CHECK -->|缺评论截图/链接| TAG2[\"写：打标'xx产品待回评'
提醒：自动通知用户补充
状态：信息待补全\"]\n\n FINANCE --> PAY[\"查：付款凭证
写：自动推送返款/礼品卡通知
状态：已返款\"]\n PAY --> DONE[\"状态：回评流程走完\"]\n DONE --> TAG3[\"写：打标'xx产品已回评用户'
推送：测评卡片（二次转化）\"]\n\n style SUBMIT fill:#e8f5e9\n style PASS fill:#c8e6c9\n style CS fill:#fff3e0\n style DONE fill:#e3f2fd\n```\n\n#### 9.3 IM 新测评流程\n\n```mermaid\nflowchart TB\n START[\"入口：用户收到测评卡片 → 提交测评信息\"] --> VFY[\"查：订单号是否撤销、是否退款
查：真实人月度测评额度与累计真实提交评价\"]\n\n VFY -->|\"额度允许 + 订单有效\"| REG[\"写：登记进系统
写：打标'xx产品测评单登记'
状态：已登记\"]\n\n REG --> INFO{\"信息完整？\"}\n INFO -->|只有订单号
缺返款账号+截图| TAG_A[\"写：打标'xx产品测评待返款'
提醒：自动通知用户
状态：待补全\"]\n INFO -->|只有截图+链接
缺订单号+返款账号| TAG_B[\"写：打标'xx产品测评单待回评'
提醒：自动通知用户
状态：待补全\"]\n INFO -->|完整| COMP[\"状态：测评流程走完\"]\n\n COMP --> RECALC[\"查：重新计算 review 数量
写：review 数量更新\"]\n RECALC -->|\"累计真实提交评价 ≥ 12\"| LC[\"写：打标'长期测评人'
推送：免评产品卡片\"]\n RECALC -->|\"≤ 12 review\"| NEXT[\"推送：当日测评计划对应卡片
写：二次转化记录\"]\n\n style COMP fill:#c8e6c9\n style LC fill:#fff3e0\n```\n\n#### 9.4 IM 核心标签汇总\n\n| 分类 | 标签 | 触发时机 | 后续动作 |\n| --- | --- | --- | --- |\n| **用户层级** | 未参与过用户 (A) | 注册+绑定后首次识别 | 推送回评卡片 |\n| | 参与过用户 (B) | 已有回评/测评记录，review < 12 | 优先催评 → 二次转化 |\n| | 长期测评人 (C) | review > 12 | 仅推送免评产品 |\n| **回评流程** | xx产品已回评用户 | 回评流程走完 | 推送测评卡片 |\n| | xx产品待回评用户 | 缺截图/链接 | 自动通知补全 |\n| | xx产品待返款 | 缺返款账号 | 自动通知补全 |\n| **测评流程** | xx产品测评单登记 | 订单核实通过 | 继续信息补全 |\n| | xx产品测评待返款用户 | 测评缺返款 | 自动通知补全 |\n| | xx产品测评单待回评 | 测评缺截图 | 自动通知补全 |\n| | xx产品测评单 | 测评流程走完 | review重算 |\n| **免评流程** | xx产品的免评 | 长期测评人参与免评单 | 不再推回评/测评 |\n\n#### 9.5 IM 推送动作与流转动作\n\n| 动作类型 | 动作 | 说明 |\n| --- | --- | --- |\n| **推送** | 回评卡片 | A类用户首次推送 |\n| | 测评卡片 | B类二次转化 / A类设备在黑名单 |\n| | 免评产品卡片 | C类用户 / 黑名单命中用户 |\n| | 催评消息 | B类优先催评 / 紧急催评 |\n| | 返款/礼品卡通知 | 财务有凭证后推送 |\n| **流转** | 推送客服 | 订单号不符合 / 异常 |\n| | 推送财务 | 订单登记完成后 |\n| | 自动打标 | 各流程节点完成时 |\n| | 二次转化 | 回评完成 → 推送测评卡片 |\n\n---\n\n### 10. 渠道二：EDM 邮件推送专属流程\n\n#### 10.1 流程图\n\n```mermaid\nflowchart TB\n START[\"入口：计划已批准，进入EDM执行拆解\"] --> POOL[\"筛选EDM目标用户池\"]\n\n POOL --> COND{\"查：用户条件\"}\n COND -->|\"非APP用户\"| NON[\"进入EDM队列\"]\n COND -->|\"APP低活跃\"| LOW[\"查：IM频控通过后进入EDM队列\"]\n COND -->|\"APP活跃\"| SKIP[\"拦截：跳过EDM，走IM/APP\"]\n\n NON --> PRECHK[\"推送前检查\"]\n LOW --> PRECHK\n\n PRECHK --> C1[\"查：身份——是否有有效邮箱\"]\n PRECHK --> C2[\"查：风险——邮箱是否命中黑名单\"]\n PRECHK --> C3[\"查：退订——是否已退订/硬退信\"]\n PRECHK --> C4[\"查：资格——OA是否有资格\"]\n PRECHK --> C5[\"查：国家——站点与邮箱类型匹配\"]\n\n C1 & C2 & C3 & C4 & C5 -->|全部通过| BEHAVIOR[\"行为筛选\"]\n C1 & C2 & C3 & C4 & C5 -->|任一不通过| EXCLUDE[\"写：排除原因
拦截：不发送\"]\n\n BEHAVIOR --> B1[\"查：最近打开时间、总打开次数\"]\n BEHAVIOR --> B2[\"查：最近3/5次是否连续0打开\"]\n BEHAVIOR --> B3[\"查：最近回复时间、回复后又发送数\"]\n BEHAVIOR --> B4[\"查：是否点击评论链接但未回复\"]\n BEHAVIOR --> B5[\"查：单月收信次数、各邮件类型发送次数\"]\n\n B1 & B2 & B3 & B4 & B5 --> RHYTHM{\"节奏判断\"}\n RHYTHM -->|适合触达| SEND[\"发送EDM
写：发送记录
状态：已发送\"]\n RHYTHM -->|需降频| DELAY[\"写：延后标记
状态：观察中\"]\n RHYTHM -->|不适合| SWITCH[\"切换其他渠道或排除\"]\n\n SEND --> TRACK[\"追踪回收\"]\n TRACK --> T1[\"送达 → 写：送达时间\"]\n T1 --> T2[\"打开 → 写：打开时间、打开次数+1\"]\n T2 --> T3[\"点击 → 写：点击时间、点击目标\"]\n T3 --> T4[\"跳转至APP下载页/产品页\"]\n T4 --> RESULT{\"用户行为\"}\n RESULT -->|\"下载并注册APP\"| TO_IM[\"写：用户渠道升级
后续走IM主流程\"]\n RESULT -->|\"直接回复邮件\"| TO_CS[\"写：生成客服工单
走客服执行流程\"]\n RESULT -->|\"未响应\"| RETRY[\"写：进入再触达队列
（遵循频控间隔）\"]\n RESULT -->|\"退订\"| UNSUB[\"写：退订标记
拦截：该渠道永久排除\"]\n\n SEND --> METRICS[\"写：EDM指标
发送数/送达率/打开率/点击率/回复率/转化数/退订数\"]\n\n style EXCLUDE fill:#fce4ec\n style UNSUB fill:#fce4ec\n style TO_IM fill:#e3f2fd\n style TO_CS fill:#fff3e0\n```\n\n#### 10.2 EDM 专属行为指标\n\n| 字段组 | 具体指标 | 用途 |\n| --- | --- | --- |\n| **打开行为** | 最近打开时间、总打开次数、最近3/5次0打开 | 判断活跃度 → 决定是否继续发 |\n| **回复行为** | 最近回复时间、回复后又发送封数 | 判断兴趣度 → 决定触达节奏 |\n| **点击行为** | 是否点击评论链接、点击后未回复时长 | 判断意向 → 决定是否追加触达 |\n| **触达频率** | 单月收信次数、各邮件类型发送次数 | 频控 → 防止疲劳 |\n| **邮件属性** | 邮件类型、邮箱后缀标签、国家站点 | 匹配 → 确定发送内容 |\n| **排除项** | 风险用户、黑名单、退订、硬退信、OA无资格 | 硬过滤 → 不进池 |\n\n#### 10.3 EDM vs IM 关键差异\n\n| 维度 | IM | EDM |\n| --- | --- | --- |\n| 用户身份强度 | 强（JOYHUB ID + 设备 + 订单绑定） | 弱（仅邮箱，可能无JOYHUB ID） |\n| 风险识别能力 | 高（多维度交叉） | 低（缺设备/注册邮箱等维度） |\n| 转化路径 | 直接提交 → 核验 → 返款 | 引导注册APP → 再进入IM链路 |\n| 退订机制 | 社区屏蔽/消息免打扰 | 邮件退订链接 + 硬退信 |\n| 频控周期 | 按日/按类目 | 按周/按月 |\n| 行为信号 | 绑定/活跃/点击/回复/标签 | 打开/点击/回复/退订/连续0打开 |\n\n---\n\n### 11. 渠道三：APP Push 专属流程\n\n#### 11.1 流程图\n\n```mermaid\nflowchart TB\n START[\"触发源\"] --> T1[\"用户绑定新玩具\"]\n START --> T2[\"用户长期未活跃（7天+）\"]\n START --> T3[\"测评/回评计划到期\"]\n START --> T4[\"Listing健康紧急\"]\n START --> T5[\"活动/促销通知\"]\n\n T1 & T2 & T3 & T4 & T5 --> FILTER[\"查：共用能力过滤\"]\n\n FILTER --> F1[\"查：身份——JOYHUB ID + 设备在线\"]\n FILTER --> F2[\"查：风险——黑名单 + 关联检测\"]\n FILTER --> F3[\"查：频控——当日Push次数 + 用户通知设置\"]\n FILTER --> F4[\"查：标签——匹配推送策略\"]\n\n F1 & F2 & F3 & F4 -->|通过| PUSH[\"发送APP Push
写：推送记录
状态：已发送\"]\n F1 & F2 & F3 & F4 -->|不通过| SKIP[\"写：跳过原因
状态：已跳过\"]\n\n PUSH --> USER{\"用户响应\"}\n USER -->|\"点击打开\"| IN_APP[\"进入APP → 落地页\"]\n USER -->|\"忽略/关闭\"| NOOP[\"写：曝光记录
拦截：短期内不重复推\"]\n USER -->|\"卸载/禁用通知\"| UNINSTALL[\"写：不可再推送标记
降级：转入EDM候选池\"]\n\n IN_APP --> ACT{\"APP内动作\"}\n ACT -->|\"提交回评/测评\"| IM_FLOW[\"走IM提交核验流程（§9.2）\"]\n ACT -->|\"联系客服\"| CS_FLOW[\"生成客服工单（§12）\"]\n ACT -->|\"仅浏览\"| TAG[\"写：记录行为，更新活跃标签\"]\n\n style IN_APP fill:#e3f2fd\n style UNINSTALL fill:#fce4ec\n```\n\n#### 11.2 APP Push 与 IM 的分工\n\n| 场景 | 用 APP Push | 用 IM |\n| --- | --- | --- |\n| 新绑定玩具 → 引导测评 | - | 推送回评/测评卡片 |\n| 用户7天未活跃 | 推送召回通知 | - |\n| 测评计划到期提醒 | - | 推送催评消息 |\n| Listing 紧急 | 推送紧急通知 | 推送紧急催评卡片 |\n| 返款已到账 | 推送到账通知 | - |\n| 活动/促销 | 推送活动通知 | - |\n\n#### 11.3 APP 必查字段\n\n| 字段组 | 内容 |\n| --- | --- |\n| 用户资料 | 注册邮箱、JOYHUB ID、国家、语言 |\n| 设备上下文 | 设备号、设备型号/类型、APP版本、系统版本 |\n| 产品关系 | 绑定玩具、绑定时间、目标产品关系 |\n| 行为数据 | 活跃、打开、点击、回复、站内浏览、广告互动 |\n\n---\n\n### 12. 渠道四：TEL 电话专属流程\n\n#### 12.1 流程图\n\n```mermaid\nflowchart TB\n START[\"触发电话任务\"] --> S1[\"用户答应配合但超时未提交\"]\n START --> S2[\"高价值用户需深度跟进\"]\n START --> S3[\"复杂售后无法文字解决\"]\n START --> S4[\"IM/EDM多次触达无响应\"]\n START --> S5[\"紧急Listing需人工沟通\"]\n START --> S6[\"Amazon页面/说明书来电\"]\n START --> S7[\"计划生成的外呼任务\"]\n\n S1 & S2 & S3 & S4 & S5 & S6 & S7 --> TICKET[\"写：生成电话类客服工单
状态：待分配\"]\n\n TICKET --> PREPARE[\"拨打前准备（必须）\"]\n PREPARE --> P1[\"查：用户完整画像
（身份/订单/历史/标签/风险）\"]\n PREPARE --> P2[\"查：风险状态
拦截：强关联命中 → 暂停拨打 → 先复核\"]\n PREPARE --> P3[\"查：历史沟通记录
（避免重复询问）\"]\n PREPARE --> P4[\"写：准备话术和问题清单\"]\n\n P1 & P2 & P3 & P4 --> CONTACT[\"客服电话联系用户
写：拨打记录
状态：处理中\"]\n\n CONTACT --> RESULT{\"通话结果\"}\n RESULT -->|\"接通-售后问题\"| AFTERSALE[\"先解决售后
查：订单/产品/凭证
写：处理方案
状态：售后处理中\"]\n RESULT -->|\"接通-直接配合\"| COOP[\"确认评价提交时间
写：登记答应配合
状态：答应配合\"]\n RESULT -->|\"接通-拒绝\"| REJECT[\"写：记录拒绝原因
状态：已关闭\"]\n RESULT -->|\"接通-疑似诈骗\"| FRAUD[\"创建诈骗事件
写：诈骗记录
转风险链路（§6）\"]\n RESULT -->|\"未接通\"| RETRY[\"写：拨打次数+1
提醒：安排重试\"]\n\n AFTERSALE --> SAT{\"是否解决/满意？\"}\n SAT -->|是| INVITE[\"引导回评/邀请测评\"]\n SAT -->|否| ESCALATE[\"升级处理 → 转组长/负责人\"]\n\n INVITE --> FOLLOW[\"写：进入答应配合跟进
状态：待提醒\"]\n COOP --> FOLLOW\n FOLLOW --> UPDATE[\"写：更新工单 + 用户标签\"]\n\n RETRY --> DECIDE{\"重试策略\"}\n DECIDE -->|\"< 3次\"| CONTACT\n DECIDE -->|\"≥ 3次未接通\"| DOWNGRADE[\"写：降级至EDM/放弃
状态：待关闭\"]\n\n CONTACT --> RECORD[\"写：通话记录
来电时间/来源/联系方式/订单号
问题类型/描述/处理方案
是否解决/是否邀请测评/用户是否接受\"]\n\n style CONTACT fill:#fff3e0,stroke:#ef6c00\n style FRAUD fill:#fce4ec,stroke:#c62828\n style AFTERSALE fill:#e3f2fd\n```\n\n#### 12.2 TEL 必填记录字段\n\n| 类别 | 字段 | 涉密 |\n| --- | --- | --- |\n| 来电基础 | 来电时间、来源（Amazon页/说明书/外呼）、客服、联系方式 | - |\n| 订单信息 | Amazon订单号、产品型号/款式/颜色、购买时间 | 订单号涉密 |\n| 问题信息 | 问题类型、问题描述、图片/视频凭证 | - |\n| 处理信息 | 处理方案、是否解决、是否需要后续跟进 | - |\n| 评价相关 | 是否邀请回评/测评、用户是否接受、是否涉及差评 | - |\n| 拨打统计 | 拨打次数、通话时长、接通状态 | - |\n\n---\n\n### 13. 渠道五：客服工单执行流程\n\n#### 13.1 流程图\n\n```mermaid\nflowchart TB\n A[\"入口：用户消息 / 推送转人工 / 电话后续 / 风险触发\"] --> B[\"写：生成工单
状态：待分配\"]\n\n B --> C[\"查：班次、在线状态、当前负载、最大工单数
写：自动分配到客服组
状态：已分配\"]\n\n C --> D[\"客服组长分派到组员
状态：处理中\"]\n\n D --> E[\"查：展示用户上下文卡
（身份/历史/风险/设备/触达）\"]\n\n E --> F[\"客服开始处理\"]\n\n F --> G{\"处理结果\"}\n G -->|\"等待用户回复\"| H[\"状态：等待用户
提醒：超时提醒机制\"]\n G -->|\"等待内部协同\"| I[\"状态：等待内部
提醒：超时升级\"]\n G -->|\"用户答应配合\"| J[\"写：生成跟进任务
状态：答应配合
进入答应配合状态机\"]\n G -->|\"疑似诈骗\"| K[\"写：诈骗疑似标记
提醒：组长/负责人复核
转风险链路（§6）\"]\n G -->|\"问题已解决\"| L[\"写：解决记录
状态：已解决\"]\n\n H --> F\n I --> F\n\n J --> M[\"提醒/再联系/等待提交\"]\n M --> N[\"用户提交评价或反馈
状态：已提交评价/已提交反馈\"]\n\n K --> P[\"组长/负责人复核\"]\n P --> Q{\"复核结论\"}\n Q -->|确认诈骗| R[\"转风险链路 → 同步黑名单\"]\n Q -->|退回继续处理| F\n\n L --> S[\"写：关闭工单
状态：已关闭\"]\n```\n\n#### 13.2 三套并行状态\n\n| 状态体系 | 典型状态 | 说明 |\n| --- | --- | --- |\n| **工单状态** | 待分配 → 已分配 → 处理中 → 等待用户/等待内部 → 已解决 / 疑似诈骗 → 已关闭 | 工单生命周期 |\n| **答应配合状态** | 已答应配合 → 待分配负责人 → 待提醒 → 等待提交 → 已提交评价/已提交反馈 → 超时 → 需再次联系 → 已关闭 | 防止承诺用户流失 |\n| **风险状态** | 无异常 → 弱关联高风险 → 强关联高风险 → 疑似诈骗 → 已确认诈骗 → 已同步黑名单 | 风险独立跟踪 |\n\n---\n\n### 14. 客服管理支撑流程\n\n#### 14.1 流程图\n\n```mermaid\nflowchart LR\n A[\"排班设置\"] --> B[\"在线客服池\"]\n C[\"出勤记录\"] --> B\n B --> D[\"工单自动分配
查：在线状态/排班/当前负载/最大工单数\"]\n D --> E[\"回复效率统计\"]\n D --> F[\"转化统计\"]\n F --> G[\"目标完成统计\"]\n E --> H[\"主管看板\"]\n F --> H\n G --> H\n```\n\n#### 14.2 管理指标\n\n| 模块 | 指标 |\n| --- | --- |\n| **出勤** | 应出勤、实际出勤、出勤率、迟到、早退、请假、缺勤 |\n| **回复效率** | 回复用户数、处理工单数、发送消息数、首次回复时长（平均/中位数/最大/最小） |\n| **转化** | RSO回评登记订单数、RDO测评登记订单数、获取评价数、评价完成率 |\n| **目标** | 月目标、当前完成、完成率、历史趋势 |\n\n---\n\n### 15. 评价完成流程\n\n#### 15.1 流程图\n\n```mermaid\nflowchart TB\n A[\"用户提交评价\"] --> B[\"写：记录真实提交事实
状态：已提交待核验\"]\n B --> C[\"写：更新真实人累计评价额度（+1）
提醒：接近12时预警\"]\n\n C --> D{\"查：Amazon是否展示 / 是否可核验\"}\n D -->|\"展示或可核验\"| E[\"写：计入计划完成
状态：已确认展示\"]\n D -->|\"未展示 / 暂不可核验\"| F[\"写：保留已提交事实
状态：未展示待观察\"]\n\n E --> G[\"写：更新ASIN健康与计划完成度\"]\n F --> H[\"进入异常观察队列
提醒：定期复查\"]\n\n G --> I[\"结果回流：更新经营层数据\"]\n```\n\n#### 15.2 必须拆开的两个事实\n\n| 事实 | 是否计入累计12额度 | 是否计入计划完成 | 计数时点 |\n| --- | --- | --- | --- |\n| 用户真实提交评价 | **是** | 还不一定 | 提交时立即计数 |\n| Amazon 展示确认 | 已在上一步计过 | **是** | 展示确认时 |\n\n---\n\n### 16. 渠道六：KOC/KOL 协作专属流程（免评核心通道）\n\n#### 16.1 流程图\n\n```mermaid\nflowchart TB\n START[\"入口：免评计划 / 推新计划已批准\"] --> PLAN[\"查：计划参数
写：拆解KOC/KOL执行方案\"]\n\n PLAN --> STEP1[\"匹配合作对象\"]\n STEP1 --> S1A[\"查：按国家/平台/粉丝量/历史效果筛选\"]\n STEP1 --> S1B[\"查：按产品类目匹配KOC/KOL专长\"]\n STEP1 --> S1C[\"查：合作对象风险（历史纠纷/违约）
提醒：有风险记录时提示\"]\n\n S1A & S1B & S1C --> STEP2[\"写：分配Code/素材/内容Brief\"]\n STEP2 --> STEP3[\"KOC/KOL内容发布\"]\n\n STEP3 --> TRACK[\"跟踪执行结果\"]\n TRACK --> T1[\"查：内容发布链接\"]\n TRACK --> T2[\"查：点击/跳转数据\"]\n TRACK --> T3[\"查：Code使用量\"]\n TRACK --> T4[\"查：带货订单\"]\n TRACK --> T5[\"查：转化销量\"]\n TRACK --> T6[\"查：Listing权重变化\"]\n\n T1 & T2 & T3 & T4 & T5 & T6 --> SYNC[\"从JOYCOLLAB同步数据至USER
写：同步记录
提醒：同步失败时告警\"]\n\n SYNC --> EVAL{\"执行评估\"}\n EVAL -->|\"达标\"| DONE[\"写：结果回流
更新ASIN健康/计划完成度
状态：已完成\"]\n EVAL -->|\"未达标\"| ADJUST[\"调整策略
写：调整记录
更换KOC/调整素材/追加Code\"]\n\n SYNC --> FINANCE[\"财务侧
查：提成计算/返点核算/提款记录
提醒：财务数据独立权限\"]\n```\n\n#### 16.2 KOC/KOL 与评价型渠道的本质差异\n\n| 维度 | 评价型（IM/EDM/APP/TEL） | KOC/KOL |\n| --- | --- | --- |\n| 执行主体 | 系统 + 客服 | 外部KOC/KOL + 运营协同 |\n| 终点 | 用户提交评价 | 内容发布/Code使用/带货销量/权重 |\n| 用户关系 | 平台 ↔ 买家 | 品牌 ↔ 达人 ↔ 达人粉丝 |\n| 数据源 | USER系统内部 | JOYCOLLAB同步 |\n| 财务 | 返款（固定金额） | 提成+返点（按效果） |\n| 风险关注 | 诈骗/双重退款 | 合作纠纷/违约/虚假流量 |\n\n#### 16.3 IM/EDM/APP 在免评中的协同角色\n\n| 协同动作 | 渠道 | 说明 |\n| --- | --- | --- |\n| KOC内容二次分发 | IM/APP | 将KOC发布的优质内容推送给站内用户 |\n| 免评Code触达 | IM/EDM | 将免评Code分发给符合条件的站内用户 |\n| 活动引流 | APP Push | 推送活动通知引导用户进入KOC内容页 |\n| 结果通知 | IM/APP | 通知用户Code到账、订单确认 |\n\n#### 16.4 免评核心结果组\n\n| 结果组 | 跟踪内容 |\n| --- | --- |\n| 内容 | 发布状态、链接、发布时间、互动数据 |\n| 引流 | 点击量、跳转量、Code使用量 |\n| 成交 | 订单数、转化量、销量 |\n| 经营 | 权重变化、ASIN健康变化、品牌搜索变化 |\n\n---\n\n### 17. 店铺紧急催评流程（IM渠道专属子流程）\n\n```mermaid\nflowchart TB\n TRIGGER[\"触发条件
查：店铺当日掉评/差评/需紧急拿好评稳评分
状态：紧急触发\"] --> CALC[\"计算推送量
目标好评数 ÷ 2% = 需触达用户数
写：推送方案\"]\n\n CALC --> EXEC[\"执行\"]\n EXEC --> E1[\"查：筛选可触达用户
写：推送紧急催评消息\"]\n EXEC --> E2[\"查：优先触达高完成率用户\"]\n EXEC --> E3[\"查：持续跟踪回评提交状态\"]\n\n E1 & E2 & E3 --> RESULT{\"结果\"}\n RESULT -->|\"已提交好评\"| R1[\"写：更新已回评/测评完成
状态：已完成\"]\n RESULT -->|\"未提交\"| R2[\"写：保留在待催评池
状态：待催评\"]\n RESULT -->|\"异常\"| R3[\"转人工：推送客服跟进
状态：转客服\"]\n\n style TRIGGER fill:#fce4ec,stroke:#c62828\n```\n\n---\n\n## 第三部分：渠道交叉与协同规则\n\n### 18. 渠道优先级路由\n\n```mermaid\nflowchart LR\n USER_IN[\"同一个用户\"] --> D1{\"查：用户状态\"}\n D1 -->|\"APP注册 + 活跃 + 已绑定\"| IM[\"IM 优先\"]\n D1 -->|\"APP注册 + 低活跃\"| APP_PUSH[\"APP Push优先 + IM补充\"]\n D1 -->|\"未注册APP\"| EDM[\"EDM优先 → 引导注册后转IM\"]\n D1 -->|\"高价值 + 多次无响应\"| TEL[\"TEL人工\"]\n D1 -->|\"长期测评人（C类）\"| IM_FREE[\"IM免评卡片 + KOC/KOL协同\"]\n\n style IM fill:#e3f2fd\n style EDM fill:#fff3e0\n style TEL fill:#fce4ec\n```\n\n### 19. 渠道间去重规则\n\n| 规则 | 说明 |\n| --- | --- |\n| 同一计划同一用户 | 不重复通过多渠道路由，优先走最高优先级渠道 |\n| 用户已在客服工单中 | 暂停自动触达，等待工单关闭后再判断 |\n| 用户已提交评价（待核验） | 所有渠道暂停催评，等待核验结果 |\n| 用户已退订某渠道 | 该渠道永久排除，不影响其他渠道 |\n| 用户命中强关联风险 | **所有渠道暂停自动触达**，进入人工复核 |\n| 用户命中弱关联风险 | 降频 + 提示后继续，但需人工关注 |\n\n### 20. 用户状态 × 渠道可用性矩阵\n\n| 用户状态 | IM | EDM | APP Push | TEL | KOC/KOL |\n| --- | --- | --- | --- | --- | --- |\n| APP活跃 + 已绑定 | **首选** | 不送 | 补充 | - | - |\n| APP活跃 + 未绑定 | 引导绑定 | - | 活动通知 | - | - |\n| APP低活跃 | 降频 | 补充 | **召回** | - | - |\n| 未注册APP | - | **首选** | - | 高价值时 | - |\n| 已答应配合 | 提醒 | - | 到期提醒 | **超时拨打** | - |\n| 长期测评人 (C) | **仅免评** | - | - | - | 可协同 |\n| 黑名单/强关联 | **全暂停** | **全暂停** | **全暂停** | **需复核** | **暂停** |\n| 弱关联风险 | 降频+提示 | 降频+提示 | 降频+提示 | 提示后执行 | 提示 |\n| 累计接近12 | 预警+人工 | 预警+人工 | 预警+人工 | 可正常服务；涉及普通测评邀请时需人工复核 | - |\n| 累计已满12 | 仅免评 | 仅免评 | 仅免评 | 可正常服务；不得绕过普通测评限制 | 可协同 |\n\n---\n\n## 第四部分：第三步数据对象建议\n\n### 21. 第三步建议优先产出的数据对象\n\n| 优先级 | 对象 | 来源能力/渠道 |\n| --- | --- | --- |\n| **P0** | `person_profiles`（真实人） | §2 真实人识别 |\n| **P0** | `person_identity_links`（身份关联） | §2 真实人识别 |\n| **P0** | `contact_context_snapshots`（用户上下文快照） | §2 用户上下文卡 |\n| **P0** | `person_quota_ledgers`（额度台账） | §4 额度台账 |\n| **P0** | `quota_reservations`（额度预占） | §4 额度台账 |\n| **P0** | `risk_signals`（风险信号） | §6 风险判断 |\n| **P0** | `risk_cases`（风险事件） | §6 风险判断 |\n| **P0** | `blacklist_entities`（黑名单实体） | §6 风险判断 |\n| **P0** | `audience_snapshots`（人群快照） | §3 人群生成 |\n| **P0** | `audience_exclusions`（人群排除记录） | §3 人群生成 |\n| **P0** | `channel_route_decisions`（渠道路由决策） | §18 渠道优先级 |\n| **P0** | `channel_dedup_records`（渠道去重记录） | §19 渠道间去重 |\n| **P1** | `im_interaction_records`（IM交互记录） | §9 IM |\n| **P1** | `im_flow_tags`（IM流程标签） | §9 IM |\n| **P1** | `edm_message_events`（EDM事件） | §10 EDM |\n| **P1** | `edm_user_behavior_profiles`（EDM用户行为画像） | §10 EDM |\n| **P1** | `app_touch_events`（APP触达事件） | §11 APP |\n| **P1** | `tel_call_records`（TEL通话记录） | §12 TEL |\n| **P1** | `support_tickets`（客服工单） | §13 客服 |\n| **P1** | `support_followups`（答应配合跟进） | §13 客服 |\n| **P1** | `support_assignment_logs`（工单分配日志） | §13 客服 |\n| **P1** | `review_submission_records`（评价提交记录） | §15 评价完成 |\n| **P1** | `review_display_checks`（评价展示核验） | §15 评价完成 |\n| **P1** | `exemption_plan_tasks`（免评计划任务） | §16 KOC/KOL |\n| **P1** | `creator_content_records`（KOC内容记录） | §16 KOC/KOL |\n| **P1** | `amazon_refund_records`（Amazon退款记录） | §6 双重退款 |\n| **P1** | `oa_refund_records`（OA返款记录） | §6 双重退款 |\n| **P1** | `refund_match_results`（退款比对结果） | §6 双重退款 |\n| **P2** | `attendance_records`（出勤记录） | §14 客服管理 |\n| **P2** | `shift_schedules`（排班表） | §14 客服管理 |\n| **P2** | `support_goal_records`（客服目标） | §14 客服管理 |\n| **P2** | `support_performance_snapshots`（绩效快照） | §14 客服管理 |\n| **P2** | `interaction_audit_logs`（互动审计日志） | §8 审计 |\n| **P2** | `manual_review_tasks`（人工复核任务） | §5/§6 复检与风险 |\n\n---\n\n### 22. 与基线 v1.2 的关系\n\n本文件是基线 v1.2 的下游细化产物：\n\n| 基线 v1.2 章节 | 本文件对应 |\n| --- | --- |\n| §6.1 主动触达支线 | §9 IM、§10 EDM、§11 APP Push |\n| §6.2 免评执行支线 | §16 KOC/KOL + §16.3 协同角色 |\n| §6.3 被动售后与TEL支线 | §12 TEL |\n| §6.4 风险/诈骗拦截支线 | §6 风险判断与黑名单 |\n| §6.5 客服工单与客服管理支线 | §13 客服工单、§14 客服管理 |\n| §7 真实人识别、用户上下文与额度规则 | §2 真实人识别、§4 额度台账 |\n| §8 渠道专属补充事实 | §9-§16 各渠道专属流程 |\n| §11 第二步新入口 | 本文件整体 |\n\n---\n\n### 23. 本版结论\n\nv2.2 吸收了前序文档中的以下优势：\n\n1. **额度体系**（测评4/免评4/累计12）作为独立共用能力，含台账/预占/预警/拦截\n2. **画像拆解**为 7 组字段 × 3 类用途\n3. **节点规则表**统一用 查/写/状态/提醒/拦截/转人工 格式\n4. **EDM 专属行为指标**（3/5次0打开、点击未回复时长、单月收信次数）\n5. **客服管理支撑流**（排班/出勤/绩效/目标）\n6. **评价完成流程**中拆开\"提交即计12\"vs\"展示才计完成\"\n7. **P0/P1/P2 数据对象**优先级\n\n同时保留了我版的核心优势：\n\n1. **IM A/B/C 三层用户完整流转**（提交核验、测评流程、标签汇总、推送/流转动作表）\n2. **渠道交叉与协同规则**（优先级路由、去重规则、用户状态 × 渠道可用性矩阵）\n3. **KOC/KOL JOYCOLLAB 同步链路**及免评协同角色表\n4. **TEL 拨打前准备五步 + 重试策略**\n5. **店铺紧急催评**独立子流程\n6. **三套并行客服状态**（工单/答应配合/风险）\n\n并完成以下收口：\n\n1. 将 IM 里残留的 `Amazon 账号 < / > 12 review` 全部改为 `真实人累计真实提交评价` 口径\n2. 明确 TEL 可继续服务，但不能绕开普通测评额度限制\n3. 补齐渠道路由、渠道去重、IM 流程标签和 EDM 行为画像对应的数据对象\n", + "wikilinks": [], + "category": "layer-requirements" + } + }, + { + "id": "doc:05_需求文档/20260517_USER评价业务闭环主流程与后续工作基线_v1.2", + "type": "document", + "name": "USER 评价业务闭环主流程与后续工作基线 v1.2", + "filePath": "05_需求文档/20260517_USER评价业务闭环主流程与后续工作基线_v1.2.md", + "summary": "USER 评价业务闭环主流程与后续工作基线 v1.2 文件信息 文件名称： 20260517 USER评价业务闭环主流程与后续工作基线 v1.2.md 项目路径： C:\\XCODE\\USER 当前版本： v1.2 最近更新： 2026 05 17 前一版本： 20260517 USER评价业务闭环主流程与后续工作基线 v1.1.md 文件目的：在既有销售到评", + "tags": [ + "05_需求文档", + "需求文档" + ], + "complexity": "moderate", + "knowledgeMeta": { + "content": "# USER 评价业务闭环主流程与后续工作基线 v1.2\n\n## 文件信息\n\n- 文件名称：`20260517_USER评价业务闭环主流程与后续工作基线_v1.2.md`\n- 项目路径：`C:\\XCODE\\USER`\n- 当前版本：`v1.2`\n- 最近更新：`2026-05-17`\n- 前一版本：`20260517_USER评价业务闭环主流程与后续工作基线_v1.1.md`\n- 文件目的：在既有销售到评价闭环基线上，补入真实人识别、测评 / 免评额度、用户历史上下文、IM / EDM / TEL / 客服细化口径，作为新版第二步和后续数据流设计的统一依据。\n- 适用范围：当前阶段的 Amazon 业务闭环设计；如后续扩展到独立站或非 Amazon 评价体系，需要在本文件基础上另行增补。\n- 使用方式：下一次继续本项目时，先读取本文件，再读取 `20260517_USER评价业务闭环_共用能力图与渠道专属流程_v2.2.md`，不要再从旧版页面链路重新推导业务主干。\n\n---\n\n## 版本记录\n\n| 版本 | 日期 | 说明 |\n| --- | --- | --- |\n| v1 | 2026-05-17 | 首次固化销售到评价完成的 USER 业务闭环主流程 |\n| v1.1 | 2026-05-17 | 将免评改为独立闭环；明确每次有效互动都要重新做身份与风险判断；明确当前版本不单列商家角色 |\n| v1.2 | 2026-05-17 | 补入用户历史与设备上下文、真实人级 `测评4 / 免评4 / 累计真实提交评价12` 规则、IM / EDM / TEL / 客服新增细节，并把第二步入口改为“共用能力 + 渠道专属流程” |\n\n---\n\n## 1. 已确认目标\n\n1. 系统要支持 USER 部门工作，而不是只做一个回评记录工具。\n2. 业务流必须从“销售发生 / 需求形成”开始，而不是从“推送”开始。\n3. Amazon 运营既可以人工提需求，系统也可以因 Listing 健康或评价缺口自动触发需求。\n4. 用户运营是“需求评估 + 计划调度中心”，负责把需求转成可执行计划并跟踪结果。\n5. 计划类型必须正式保留：\n - 推新计划\n - 回评计划\n - 免评计划\n6. `免评计划` 不是边缘例外，而是需要正式保留的关键业务类型；其与 KOC / KOL、社媒带货、站外流量和 Amazon 权重有关。\n7. 用户提交评价与系统确认评价完成必须拆成两个节点：\n - 用户已真实提交评价\n - Amazon 已展示 / 系统已确认计入计划完成\n8. `真实人` 是后续额度、风险、历史和用户画像的核心对象，不应只围绕某个 JOYHUB ID、邮箱或 Amazon 账号看用户。\n9. 已确认的额度规则为：\n - 同一真实人每月最多参与 `4 次测评`\n - 同一真实人每月最多参与 `4 次免评`\n - 同一真实人累计最多计入 `12 个真实提交的评价`\n10. `12` 的计数时点是 `用户真实提交评价`，不是 `Amazon 展示评价`。\n11. 每次有效互动都要重新做身份、历史、额度和风险判断；主动推送后的回复也不例外。\n12. 客服接入时必须能快速看到用户历史、订单历史、设备上下文、既往风险和当前提醒，而不是只看到当前对话。\n13. 后续系统设计顺序已经确定：\n 1. 先定业务流\n 2. 再做点击操作模拟\n 3. 最后根据业务需求整合现有数据，形成新的数据流和中间表需求\n\n---\n\n## 2. 当前边界与资料依据\n\n### 2.1 当前纳入范围\n\n- Amazon 业务\n- 销售到评价闭环\n- 推新、回评、免评\n- IM、EDM、APP、TEL、KOC / KOL\n- 售后接入\n- 客服执行与客服管理支撑\n- 黑名单与诈骗风险\n- ASIN 健康回流\n\n### 2.2 当前不作为本版主流程展开的内容\n\n- 独立站全链路\n- 完整 BI / 财务 / ROI 系统\n- 完整 KOC / KOL 结算系统\n- 所有历史后台页面逐页重构\n- 数据库最终物理设计\n\n### 2.3 资料依据\n\n本文件基于以下材料整理：\n\n1. `C:\\XCODE\\USER\\评价业务流闭环项目架构文档_v0.8.docx`\n2. `C:\\XCODE\\USER\\docs\\evaluation-business-architecture.md`\n3. `C:\\XCODE\\USER\\docs\\project-phase-one-plan.md`\n4. `C:\\XCODE\\USER\\output\\docs\\20260503_USER后台ERP一期功能与页面设计_v4.md`\n5. `C:\\XCODE\\USER\\output\\docs\\20260503_USER后台ERP自动推送与计划状态机_v4.md`\n6. `C:\\XCODE\\USER\\output\\docs\\20260503_USER后台ERP一期页面原型说明_v4.md`\n7. `C:\\XCODE\\USER\\output\\docs\\20260503_USER后台ERP_MVP角色首页UI规划_v1.md`\n8. `C:\\tcode\\飞书\\飞书聊天记录库\\cloud_files` 中当前主原型 HTML 与 `客服执行.html`\n9. `C:\\Users\\wu_zh\\Downloads\\20260407-法国诈骗问题（已扩散美国）.docx`\n10. `C:\\Users\\wu_zh\\Desktop\\表头.xlsx`\n11. `C:\\Users\\wu_zh\\Downloads\\IM 推送业务流.mm`\n12. `C:\\Users\\wu_zh\\Downloads\\后台回评工作流对接事项.docx`\n13. `C:\\Users\\wu_zh\\Downloads\\客服相关模块.docx`\n14. `C:\\Users\\wu_zh\\Downloads\\电话业务流程知识库.docx`\n15. 用户在当前对话中补充确认的业务规则\n\n若历史资料与当前对话确认口径冲突，以当前对话中最新确认口径为准。\n\n---\n\n## 3. 角色与职责\n\n| 角色 | 核心职责 |\n| --- | --- |\n| Amazon 运营 | 依据销售、ASIN、评价目标提出推新 / 回评 / 免评需求 |\n| Amazon 运营总监 | 审批相关计划，确认优先级与业务必要性 |\n| 品牌运营 | 负责品牌推广、站外节奏和与用户运营 / 内容运营协同 |\n| 内容运营 | 承接社区广告、APP 广告位、内容流量等侧向支持 |\n| 用户运营 | 评估需求、生成计划、分配资源、协调渠道、跟踪结果 |\n| 用户运营负责人 / 组长 | 复核计划、分配组员、处理重点风险和异常 |\n| 菲律宾客服负责人 | 关注工单压力、分配客服组、处理升级工单、查看绩效 |\n| 菲律宾客服组长 | 分配组内工单、复核升级、控制逾期和重点工单 |\n| 菲律宾客服组员 | 实际接待、电话沟通、记录、回复、回访、提交疑似诈骗 |\n| 风险 / 黑名单相关人员 | 接收诈骗疑似、复核、同步黑名单、维护风险口径 |\n| KOC / KOL 运营 | 承接站外带货、合作关系、内容和导购协同 |\n\n当前版本不单列“商家 / 商家运营”角色。这里的“商家”如出现，均按 Amazon 卖家侧语义理解，由 Amazon 运营承接；品牌商当前也只纳入 Amazon 内评价相关协同。\n\n---\n\n## 4. 总体业务结构\n\n### 4.1 主流程\n\n```mermaid\nflowchart LR\n A[\"销售发生 / ASIN销售数据形成\"] --> B[\"需求触发\"]\n B --> B1[\"Amazon运营人工提需求\"]\n B --> B2[\"系统按评价缺口或Listing健康自动触发\"]\n B1 --> C[\"用户运营评估需求\"]\n B2 --> C\n C --> D[\"形成业务计划\"]\n D --> D1[\"推新计划\"]\n D --> D2[\"回评计划\"]\n D --> D3[\"免评计划\"]\n D1 --> E[\"规则 / 风险 / 额度复核\"]\n D2 --> E\n D3 --> E\n E --> F[\"审批通过\"]\n F --> G[\"执行拆解\"]\n G --> H1[\"评价型执行闭环\"]\n G --> H2[\"免评型执行闭环\"]\n H1 --> I1[\"IM / EDM / APP / TEL / 客服协同\"]\n I1 --> J1[\"用户被触达或主动进入\"]\n J1 --> K1[\"每次有效互动均重做身份 / 历史 / 额度 / 风险核验\"]\n K1 --> L1[\"服务 / 售后 / 跟进\"]\n L1 --> M1[\"用户真实提交评价\"]\n M1 --> N1[\"计入真实人累计评价额度\"]\n N1 --> O1[\"Amazon是否展示 / 系统是否确认完成\"]\n O1 --> P[\"结果回流\"]\n H2 --> I2[\"KOC / KOL为核心，IM / EDM / APP等协同参与\"]\n I2 --> J2[\"内容发布 / 站外引流 / 带货执行\"]\n J2 --> K2[\"跟踪点击、Code、订单、转化与权重结果\"]\n K2 --> P\n P --> Q[\"更新ASIN健康、计划完成度、用户画像、流量结果、风险记录\"]\n Q --> C\n```\n\n### 4.2 五个业务层\n\n| 业务层 | 说明 |\n| --- | --- |\n| 经营层 | 销售、ASIN、需求、品牌 / 内容 / KOC-KOL 侧影响 |\n| 计划层 | 推新、回评、免评、审批、规则、额度、风险 |\n| 执行层 | IM、EDM、APP、TEL、客服工单、KOC / KOL 协作 |\n| 服务与身份层 | 用户接入、真实人归并、订单核验、用户上下文、售后处理 |\n| 结果与风险层 | 用户真实提交评价、Amazon 展示确认、免评结果、黑名单、诈骗、结果回流 |\n\n---\n\n## 5. 主流程详细说明\n\n| 阶段 | 业务说明 | 必须检查 | 主要输出 |\n| --- | --- | --- | --- |\n| 1. 销售与需求形成 | 销售发生后，Amazon 运营根据目标或系统根据健康度触发需求 | 销售、ASIN、评分、评价缺口、历史计划 | 新需求 |\n| 2. 用户运营评估 | 判断需求是否成立、是否可做、优先级如何 | ASIN 健康、目标数量、历史完成、当前资源、风险 | 已确认需求 / 待补充 / 驳回 |\n| 3. 计划生成 | 将需求转为推新、回评或免评计划 | 用户池、渠道容量、目标、周期 | 计划草案 |\n| 4. 计划复核与审批 | 对计划做规则、额度和风险复核，再进入审批 | 黑名单、频控、渠道风险、真实人额度、审批权限 | 已批准计划 |\n| 5. 执行拆解 | 把计划拆成渠道任务和人工任务 | 可触达用户、素材、客服负载、KOC / KOL协作 | 推送任务 / TEL任务 / 客服工单 / 协作任务 |\n| 6A. 评价型执行 | 推新、回评进入用户触达、服务与评价链路 | 真实人、订单、历史、额度、风险、售后情况 | 当前处理路径 |\n| 6B. 免评型执行 | 免评以 KOC / KOL 与站外流量为核心，同时可由 IM / EDM / APP 等协同参与 | 合作对象、内容、Code、渠道、素材、节奏、免评额度 | 内容任务 / 引流任务 / 带货任务 |\n| 7A. 用户真实提交评价 | 记录用户是否已经实际提交评价 | 用户反馈、提交证据、对应计划、真实人累计额度 | 已提交评价事实 |\n| 7B. 免评结果跟踪 | 记录免评计划的执行结果 | 内容发布、点击、Code、订单、转化、销量、权重变化 | 免评执行结果 |\n| 8. 评价确认 | 区分用户提交与 Amazon 展示结果 | Amazon 是否展示、是否能核验、是否属本计划 | 计入完成 / 待确认 |\n| 9. 结果回流 | 把评价结果与免评结果重新反馈给经营与计划层 | 计划完成、ASIN 健康、流量结果、风险变化、用户标签 | 新一轮决策输入 |\n\n---\n\n## 6. 关键业务支线\n\n### 6.1 主动触达支线\n\n```mermaid\nflowchart LR\n A[\"计划通过\"] --> B[\"筛选可触达用户池\"]\n B --> C[\"真实人识别 + 人群画像 + 额度校验\"]\n C --> D[\"渠道分配\"]\n D --> D1[\"IM\"]\n D --> D2[\"EDM\"]\n D --> D3[\"APP\"]\n D --> D4[\"TEL\"]\n D1 --> E[\"用户回应\"]\n D2 --> E\n D3 --> E\n D4 --> E\n E --> F[\"每次回应都重做身份 / 历史 / 额度 / 风险核验\"]\n F --> G[\"订单核验\"]\n G --> H[\"服务 / 跟进\"]\n H --> I[\"用户真实提交评价\"]\n```\n\n#### 关键规则\n\n1. IM、EDM、APP 可自动化；TEL 属于人工执行渠道。\n2. `IM` 需要识别用户分层、绑定玩具、设备、测评 / 免评额度和标签流转。\n3. `EDM` 需要识别最近打开、最近回复、点击评论链接但未回复、月度收信次数、最近 3 / 5 次 0 打开、邮箱类型、退订和硬退信。\n4. 计划生成前必须先检查：\n - 用户是否可触达\n - 是否命中风险\n - 是否超频\n - 是否符合站点 / 国家 / 产品目标\n - 是否接近或达到真实人额度上限\n5. 用户回应后，不能沿用上一次判断结果，必须重新检查当前身份、订单、设备、地址、历史、额度与风险状态。\n\n### 6.2 免评执行支线\n\n```mermaid\nflowchart LR\n A[\"免评计划通过\"] --> B[\"拆解执行方案\"]\n B --> C1[\"KOC / KOL协作\"]\n B --> C2[\"IM / EDM / APP辅助触达\"]\n B --> C3[\"内容 / 运营协同\"]\n C1 --> D[\"内容发布 / Code使用 / 站外引流\"]\n C2 --> D\n C3 --> D\n D --> E[\"跟踪点击、跳转、Code、订单、转化、销量与权重变化\"]\n E --> F[\"结果回流到ASIN健康与后续计划\"]\n```\n\n#### 关键规则1\n\n1. 免评计划不是评价型计划的弱化版本，而是以站外流量、带货、销量和权重结果为终点的独立闭环。\n2. KOC / KOL 是免评计划的核心执行通道，但 IM、EDM、APP 等也可以参与协同。\n3. 同一真实人每月最多参与 `4 次免评`；免评额度也要做预警、预占和拦截。\n4. 免评计划不以“用户提交评价”作为完成条件，必须另行跟踪内容发布、Code、点击、订单、转化、销量和权重变化。\n5. 如果免评执行过程中发生用户互动、售后或返款等行为，仍须进入统一的身份与风险判断机制。\n\n### 6.3 被动售后与 TEL 支线\n\n```mermaid\nflowchart LR\n A[\"用户主动联系 / 电话呼入\"] --> B[\"接入即预查\"]\n B --> C[\"识别来源、身份、订单、历史、风险\"]\n C --> D{\"是否有售后问题\"}\n D -->|有| E[\"问题分类与解决方案\"]\n E --> F[\"确认是否解决 / 是否满意\"]\n F --> G[\"满意后进入回评 / 测评邀请\"]\n D -->|无| H[\"确认无其他需求\"]\n H --> I[\"可进入测评邀请\"]\n G --> J[\"记录电话 / 工单 / 后续跟进\"]\n I --> J\n```\n\n#### 关键规则2\n\n1. TEL 当前至少包含两类入口：\n - 计划生成后的人工外呼任务\n - 用户从 Amazon 页面或说明书主动呼入\n2. 有售后问题时，必须先解决售后，再谈评价或测评邀请。\n3. 电话中需要尽量确认：\n - 购买平台\n - 订单号\n - 产品型号 / 款式 / 颜色\n - 购买时间\n - 问题类型\n - 是否有图片、视频或其他凭证\n4. 每通电话结束后，至少要记录：\n - 来电时间\n - 来源\n - 联系方式\n - 订单号\n - 问题类型和描述\n - 处理方案\n - 是否已解决\n - 是否需要后续跟进\n - 是否邀请测评 / 回评\n - 用户是否接受\n5. 当前电话业务的核心是：\n - 自然单回评转化\n - 充分利用电话用户的测评资源\n\n### 6.4 风险 / 诈骗拦截支线\n\n```mermaid\nflowchart LR\n A[\"新订单同步 / 主动触达回应 / 用户接入 / 退款申请 / 再次跟进\"] --> B[\"重新做风险识别\"]\n B --> C{\"是否命中强关联\"}\n C -->|是| D[\"直接进入高风险或黑名单链路\"]\n C -->|否| E{\"是否命中弱关联\"}\n E -->|是| F[\"进入高风险观察 + 人工复核\"]\n E -->|否| G[\"继续正常流程\"]\n D --> H[\"拦截自动退款、继续推送、自动放行\"]\n F --> H\n H --> I[\"提醒客服 / 用户运营 / 审核人员\"]\n```\n\n#### 已确认风险口径\n\n| 风险类型 | 关联项 | 处理原则 |\n| --- | --- | --- |\n| 强关联 | 邮箱、设备号、电话、收件人姓名+地址、订单号、聊天记录、Profile ID、收款信息 | 一旦命中，可直接进入高风险或黑名单链路 |\n| 弱关联 | IP 单独命中、姓名单独命中、同址异名 | 进入高风险观察，不直接认定诈骗 |\n\n#### 已确认业务问题\n\n1. 当前真实事故中存在“双重退款”风险：\n - APP / OA 已退款\n - 用户又向 Amazon 申请退款\n2. 需要把 Amazon 退款与 OA 返款自动比对。\n3. 高风险用户一旦标记，支付 / 返款需要人工复核。\n4. 客服、审核、退款等环节必须都能看到风险提醒。\n5. 非 APP 用户如果直接走邮件退款，因缺少设备、注册邮箱等维度，风险识别能力明显下降。\n6. 风险判断不是一次性的接入动作，而是每次有效互动都要重新执行。\n\n### 6.5 客服工单与客服管理支线\n\n```mermaid\nflowchart LR\n A[\"用户消息进入 / 推送转人工 / 售后触发 / 风险触发\"] --> B[\"生成工单\"]\n B --> C[\"按班次、在线状态、当前负载自动分配\"]\n C --> D[\"客服处理\"]\n D --> E{\"处理结果\"}\n E -->|等待用户| F[\"等待用户回复\"]\n E -->|等待内部| G[\"等待内部协同\"]\n E -->|答应配合| H[\"生成后续跟进\"]\n E -->|疑似诈骗| I[\"转风险链路\"]\n E -->|已解决| J[\"关闭工单\"]\n D --> K[\"回复效率 / 转化 / 目标完成统计\"]\n```\n\n#### 工单与管理事实\n\n1. 客服相关模块不只包括工单，还包括：\n - 出勤管理\n - 排班管理\n - 回复效率统计\n - 转化统计\n - 目标管理\n2. `排班` 与 `在线状态` 会直接影响自动分配。\n3. `工单状态`、`答应配合状态`、`风险状态` 必须拆开存。\n4. 客服转化要区分：\n - RSO 回评\n - RDO 测评\n5. 回复效率至少要统计：\n - 回复用户数\n - 处理工单数\n - 发送消息数\n - 平均 / 中位数 / 最大 / 最小首次回复时长\n6. 转化统计至少要看：\n - 登记订单数\n - 获取评价数\n - 评价完成率\n7. 主管需要看到出勤、排班、绩效、目标完成和工单分配，而不是只看单个会话。\n\n---\n\n## 7. 真实人识别、用户上下文与额度规则\n\n### 7.1 真实人识别原则\n\n1. 当前系统不应只围绕 `JOYHUB ID` 看用户，而应同时围绕：\n - 账号\n - 订单\n - 实际收件人\n - 设备\n - 联系方式\n - 风险关系\n2. 如果用户在 JOYHUB 内提交订单，则订单可直接关联到当前 JOYHUB ID。\n3. 如果用户通过邮件联系：\n - 先问是否有 JOYHUB ID\n - 再用注册邮箱与 JOYHUB ID 做关系查询\n4. 如果用户通过电话联系：\n - 先确认是否注册 APP\n - 结合电话、订单、收件人、地址、设备、邮箱继续识别\n5. 非 APP 用户如需继续参与相关流程，应优先引导注册 APP，再继续后续动作。\n\n### 7.2 实际收件人判定\n\n| 情况 | 处理原则 |\n| --- | --- |\n| 标准化后姓名 + 地址完全一致 | 直接认为是同一实际收件人 |\n| 地址一致但姓名不同 | 只认为存在家庭 / 关联风险，不直接判定同一人 |\n| 邮箱不同、JOYHUB ID 不同 | 不能单独否定“同一实际人” |\n| 订单号命中历史异常 | 应立即拉出历史上下文和风险记录 |\n\n### 7.3 用户上下文卡\n\n客服和用户运营在必要节点应能看到：\n\n| 字段组 | 例子 |\n| --- | --- |\n| 当前身份 | JOYHUB ID、邮箱、电话、真实人 ID、当前订单 |\n| 历史交易 | 历史订单、最近购买、退款 / 返款、目标 ASIN 购买情况 |\n| 历史服务 | 历史工单、聊天、电话、承诺、提醒、关闭原因 |\n| 历史风险 | 黑名单、关联账号、疑似诈骗、双重退款、异常订单 |\n| 当前设备 | 设备号摘要、设备型号 / 类型、系统版本、APP 版本、最近设备变化 |\n| 触达历史 | IM / EDM / APP / TEL 最近触达、回复、退订、投诉 |\n\n### 7.4 额度规则\n\n| 规则 | 统计对象 | 计数口径 |\n| --- | --- | --- |\n| 月度测评最多 4 次 | 真实人 | 已完成 + 进行中 + 已预占 |\n| 月度免评最多 4 次 | 真实人 | 已完成 + 进行中 + 已预占 |\n| 累计真实提交评价最多 12 个 | 真实人 | 用户真实提交评价后立即计数 |\n\n### 7.5 额度控制原则\n\n1. 额度判断必须放在 `真实人识别` 之后，而不是只看单一账号。\n2. 系统不能等到真正超限才提示，必须在接近上限时提前预警。\n3. 一旦 `已用 + 进行中 + 已预占 + 本次拟发送` 会导致超限，就不能进入自动推送。\n4. `Amazon 未展示` 不影响 12 次累计额度，因为口径已经确认按 `真实提交` 计数。\n\n---\n\n## 8. 渠道专属补充事实\n\n### 8.1 IM\n\n- 用户需要分层：未参与过、参与过、长期测评人。\n- 触发条件包括注册 App、绑定玩具、识别绑定产品。\n- 需要校验设备 ID、黑名单、绑定产品、额度与标签。\n- 用户提交订单号、返款账号、评论截图 / 链接后，要继续做订单核验和资格登记。\n\n### 8.2 EDM\n\n- EDM 不是简单“发邮件”，而是独立的筛选与节奏引擎。\n- 需要支持：\n - 最近打开时间\n - 最近回复时间\n - 打开次数\n - 最近 3 / 5 次推送 0 打开\n - 点击评论链接但未回复时长\n - 单月收信次数\n - 各邮件类型发送次数\n - 邮箱后缀标签\n - 国家站点\n - 退订、硬退信、风险用户、黑名单、OA 无资格用户排除\n\n### 8.3 APP\n\n- APP 侧至少要纳入：\n - 注册邮箱\n - 设备号\n - 设备型号 / 类型\n - APP 版本\n - 系统版本\n - 用户行为数据\n - 绑定玩具\n - 活跃与点击行为\n- APP 不只是触达渠道，也是身份识别、设备变化和行为画像的重要来源。\n\n### 8.4 TEL\n\n- TEL 同时承担主动外呼和被动来电。\n- 其价值不只是“打电话”，而是：\n - 解决售后\n - 捕捉自然单回评机会\n - 充分利用电话用户的测评资源\n\n---\n\n## 9. 评价结果规则\n\n### 9.1 必须拆开的两个节点\n\n```mermaid\nflowchart LR\n A[\"用户已真实提交评价\"] --> B[\"计入真实人累计评价额度\"]\n B --> C{\"Amazon是否展示 / 是否可核验\"}\n C -->|展示或可核验| D[\"计入计划完成\"]\n C -->|未展示 / 暂不可核验| E[\"保留用户已提交事实\"]\n E --> F[\"进入待确认 / 异常观察\"]\n D --> G[\"更新ASIN健康与计划完成度\"]\n```\n\n### 9.2 原因\n\n1. 用户可能确实已经提交评价。\n2. Amazon 可能因为其他原因不展示该评价。\n3. `额度计数` 与 `计划完成确认` 不是同一个业务事实。\n4. 如果系统只保留一个“评价完成”状态，会把平台展示问题错误归因给执行人员或用户。\n\n---\n\n## 10. 贯穿全程的数据检查点\n\n| 检查点 | 发生时机 | 核心检查 |\n| --- | --- | --- |\n| 经营检查 | 需求形成前 | 销售、ASIN、评分、评价缺口、历史计划 |\n| 计划检查 | 生成计划前 | 人群、渠道、容量、规则、黑名单 |\n| 画像检查 | 生成人群时 | 国家、站点、性别、年龄、绑定玩具、产品关系、活跃、历史行为 |\n| 额度检查 | 生成人群、发送前、继续推进前 | 测评 4、免评 4、累计真实提交 12、进行中与已预占 |\n| 身份检查 | 首次接入与每次有效互动时 | JOYHUB、邮箱、电话、设备、订单、地址、历史记录 |\n| 互动复检 | 主动触达回应、再次联系、补充订单号、客服回访时 | 关键属性是否变化，是否出现新订单、新地址、新设备、新返款记录 |\n| 风险检查 | 每次有效互动、退款、返款、继续推送前 | 双重退款、强弱关联、黑名单、历史异常 |\n| 结果检查 | 评价提交与确认后 | 首评 / 回评、是否属本计划、是否展示、ASIN 健康变化 |\n\n---\n\n## 11. 第二步的新入口\n\n第二步不再按旧版页面链路推进，而改成：\n\n### 11.1 共用能力图\n\n1. 真实人识别与用户上下文卡\n2. 人群生成与画像拆解\n3. 额度与频控控制\n4. 每次有效互动复检\n5. 风险与黑名单\n\n### 11.2 渠道 / 模块专属流程图\n\n1. IM\n2. EDM\n3. APP\n4. TEL\n5. 客服工单\n6. 客服管理支撑\n7. 评价完成\n8. 免评执行\n\n### 11.3 每张图都必须回答\n\n- 进入条件是什么\n- 要先查什么\n- 如何判断\n- 写入什么\n- 状态怎么变\n- 何时提醒\n- 何时拦截\n- 何时转人工\n\n---\n\n## 12. 下一次继续工作时的直接提示\n\n1. 先读取本文件。\n2. 不要重新讨论“是否从销售开始”“是否保留免评”“评价提交与展示是否拆开”，这些已确认。\n3. 额度口径按当前版本执行：\n - 测评每月最多 4\n - 免评每月最多 4\n - 同一真实人累计真实提交评价最多 12\n4. 不要再把风险判断理解成“首次接入才做一次”；每次有效互动都需要重做判断。\n5. 不要再把第二步按页面链路拆；直接进入 `20260517_USER评价业务闭环_共用能力图与渠道专属流程_v2.2.md`。\n6. 旧版 `v1` / `v1.1` 保留为历史版本，不再作为后续主口径。\n\n---\n\n## 13. 本版结论\n\nUSER 部门未来系统的核心，不是单独记录“谁评价了”，而是把以下内容放进同一条可追踪闭环中：\n\n1. 销售与需求\n2. 计划生成与审批\n3. 真实人识别与用户上下文\n4. 测评 / 免评 / 累计评价额度控制\n5. IM / EDM / APP / TEL / 客服协同\n6. 用户身份与订单核验\n7. 售后服务与评价引导\n8. 免评执行与站外流量结果\n9. 用户真实提交评价\n10. Amazon 展示与系统确认\n11. ASIN 健康回流\n12. 风险与黑名单拦截\n\n只有这条闭环建立起来，后续的点击设计、页面设计和数据设计才不会彼此脱节。\n", + "wikilinks": [], + "category": "layer-requirements" + } + }, + { + "id": "doc:05_需求文档/客服执行", + "type": "document", + "name": "客服执行看板", + "filePath": "05_需求文档/客服执行.html", + "summary": "客服执行看板", + "tags": [ + "05_需求文档", + "需求文档" + ], + "complexity": "complex", + "knowledgeMeta": { + "content": "\n\n \n \n \n 客服执行看板\n \n \n \n
\n \n \n\r\n", + "wikilinks": [], + "category": "layer-requirements" + } + }, + { + "id": "doc:05_需求文档/用户运营系统-单文件", + "type": "document", + "name": "USER评价业务闭环系统", + "filePath": "05_需求文档/用户运营系统-单文件.html", + "summary": "USER评价业务闭环系统", + "tags": [ + "05_需求文档", + "需求文档" + ], + "complexity": "complex", + "knowledgeMeta": { + "content": "\n\n \n \n \n USER评价业务闭环系统\n \n \n \n \n
\n \n\n", + "wikilinks": [ + "10,15", + "^\\", + "^\\", + "^\\", + "^\\", + "3,9", + "r,n", + "1,0", + "1,\"rgba(207,212,219,0.2)\"", + "\"rect\"", + "e", + "0,0", + "t,t", + "o.x,o.y", + "s.x,s.y", + "1,\"#E6EBF8\"" + ], + "category": "layer-requirements" + } + }, + { + "id": "doc:05_需求文档/evaluation-business-architecture", + "type": "document", + "name": "评价业务流闭环项目架构文档", + "filePath": "05_需求文档/evaluation-business-architecture.md", + "summary": "评价业务流闭环项目架构文档 版本：v0.7 更新时间：2026 04 26 当前阶段：业务框架搭建与部门业务梳理 1. 文档目标 本文档用于沉淀评价业务流闭环的业务结构、部门职责、核心数据、看板规划和后续项目规划依据。 当前重点不是直接进入系统设计，而是先明确： 业务闭环如何运转 各部门在闭环中的职责边界 每个部门需要哪些看板与数据字段 APP 与亚马逊运营", + "tags": [ + "05_需求文档", + "需求文档" + ], + "complexity": "complex", + "knowledgeMeta": { + "content": "# 评价业务流闭环项目架构文档\n\n版本：v0.7 \n更新时间：2026-04-26 \n当前阶段：业务框架搭建与部门业务梳理\n\n## 1. 文档目标\n\n本文档用于沉淀评价业务流闭环的业务结构、部门职责、核心数据、看板规划和后续项目规划依据。\n\n当前重点不是直接进入系统设计，而是先明确：\n\n- 业务闭环如何运转\n- 各部门在闭环中的职责边界\n- 每个部门需要哪些看板与数据字段\n- APP 与亚马逊运营、品牌运营、内容运营、用户运营、客服运营之间的数据关系\n- 后续项目需要支持哪些管理动作、数据归因和异常预警\n\n## 2. 总体业务闭环\n\n### 2.1 当前业务主链路\n\n亚马逊运营、品牌运营、内容运营负责拉新与引流。 \n主要带来曝光和点击，其中当前主要流量来源于亚马逊，小部分开始来源于社媒与网站宣发。\n\n↓\n\n亚马逊运营负责亚马逊渠道转化与成交，品牌运营负责独立站转化与成交。\n\n↓\n\n成交后产生订单与成交数据。\n\n↓\n\n用户运营基于成交用户、绑定用户、活跃用户进行触达推送与索评。 \n同时，用户运营或评价运营需要维护 ASIN 健康度，核心依赖回评结果。\n\n↓\n\n客服运营收集售后问题、用户反馈、负面反馈和评价相关问题，并执行处理与改善动作。\n\n↓\n\n数据层和管理层进行复盘，调整产品策略、销售策略、推送策略、评价策略和人员分工。\n\n### 2.2 闭环中的核心角色\n\n| 角色/部门 | 主要职责 | 当前定位 |\n|---|---|---|\n| 亚马逊运营 | 亚马逊销售、产品销售管理、测评计划需求、免评计划需求、关键词推新、评价健康维护协同 | 当前 APP 用户最主要、最优质来源 |\n| 品牌运营 | 独立站品牌宣发、独立站销售转化、社媒品牌形象、品牌推广、新品宣发、活动宣发、粉丝互动 | 品牌侧销售与推广主责方，协助亚马逊扩大品牌市场份额 |\n| 内容运营 | 售前社区广告计划、APP 广告位、社区内容分发、帖子加权、新帖推流、固定流量池管理、用户 KOC/KCO 对接 | 配合亚马逊运营与品牌运营做销售前期宣发和社区流量承接 |\n| 用户运营 | 测评计划落地、用户触达、IM/EDM/TEL 推送、索评、回评跟进、社区互动、合作伙伴渠道管理 | 系统核心使用者，连接销售需求、用户资源、评价结果与客服执行 |\n| 客服运营 | 售后接待、登记、回复、问题完结、负面反馈处理 | 归属用户部门管理，承接售后与评价问题改善 |\n| 数据层/管理层 | 指标复盘、异常监控、成本分析、策略调整 | 统一看板、归因和管理决策 |\n\n## 3. 基础指标与统一数据口径\n\n### 3.1 销售核心指标\n\n- 销量：日销量、月销量、总销量\n- 绑定数：总用户数、月活、日活、产品绑定用户数\n- 评价数：测评数、回评数、每日每产品评价数、计划所需数量、实际完成数量、差评数\n- 成本：产品成本、返现成本、人力成本、提成、管理成本\n\n### 3.2 基础数据维度\n\n| 数据维度 | 说明 |\n|---|---|\n| 渠道影响力 | 衡量各渠道内容、活动、广告位、推送计划的效果 |\n| 用户属性 | 发帖人属性、用户行为、性别、活跃状态、风险标记 |\n| 时间维度 | 每日、每周、每月、活动周期、新品周期 |\n| 产品维度 | 国家、品牌、类目、二级类目、ASIN、产品绑定情况 |\n| 漏斗维度 | 曝光、点击、跳转、转化、成交、绑定、触达、评价 |\n| 风险维度 | 风险标记用户数、差评数、ASIN 健康风险、异常推送效果 |\n\n### 3.3 建议统一主键\n\n后续系统设计应优先统一以下主键，避免销售、用户、评价、售后数据无法串联：\n\n- 用户 ID\n- 订单 ID\n- 产品 ID\n- ASIN\n- 品牌 ID\n- 国家/站点\n- 渠道 ID\n- 推送 ID\n\n## 4. 第一部分：亚马逊运营相关业务\n\n### 4.1 亚马逊运营在闭环中的定位\n\n亚马逊运营负责在亚马逊平台上进行电商销售工作，是当前 APP 用户最主要、最优质的来源。\n\nAPP 与亚马逊运营之间的核心关系是：\n\n1. 亚马逊销售带来订单和用户来源。\n2. APP 需要识别这些购买用户是否下载安装并绑定产品。\n3. 当前每卖出 10 个玩具，约 40% 用户下载并绑定 APP。\n4. 需要亚马逊运营在 Listing、说明书、官网、售后触点等位置配合提升 APP 下载率和产品绑定率。\n5. 亚马逊运营需要提出测评计划、免评计划、推新计划和回评计划相关需求。\n6. APP 内现有用户资源需要根据产品重要级、推新节奏和评价健康度进行分配。\n\n### 4.2 亚马逊运营核心业务模块\n\n| 模块 | 业务内容 | 与 APP 的关系 |\n|---|---|---|\n| 销售管理 | 亚马逊站点销售、销量监控、产品销售报表 | 提供销量、成交、站点、产品数据 |\n| 产品聚合管理 | 按品牌、国家、类目聚合新品、重点产品、清仓产品 | APP 侧需要计算绑定率和用户覆盖情况 |\n| 绑定率提升 | Listing、说明书、官网等触点引导下载与绑定 APP | APP 提供绑定率数据，亚马逊运营优化触点 |\n| 测评计划 | 亚马逊运营根据销售需求提出测评需求和节奏 | 用户运营负责实际实现，品牌运营参与协同 |\n| 免评计划 | 关键词 + 实时销量策略，定时下单，主要承接补单诉求 | 需单独纳入合规与风险监控 |\n| 推新计划 | 面向 S 级或当期重点产品，结合关键词进行推广 | APP 内推送资源分配需要与推新计划匹配 |\n| 回评计划 | 维护链接评价数、回评数和评分等级 | 主要由亚马逊运营与用户运营协作，品牌运营参与协同 |\n| 品牌推广协同 | 亚马逊运营同步品牌推广计划，并在亚马逊站内承接品牌调性 | 品牌运营为亚马逊站外品牌推广主责方 |\n\n### 4.3 独立看板一：产品销量与绑定率看板\n\n#### 4.3.1 看板目标\n\n用于从亚马逊运营视角监控不同品牌、国家、类目、产品类型下的销量与 APP 绑定情况。\n\n该看板需要支持：\n\n- 品牌聚合\n- 国家/站点聚合\n- 类目与二级类目聚合\n- 新品、重点产品、清仓产品拆分\n- 销量与绑定率对比\n- 异常数据报警\n- 对应人员责任归属\n\n#### 4.3.2 产品类型\n\n| 产品类型 | 说明 |\n|---|---|\n| 新品 | 新上市产品，需要重点关注销量、绑定率、评价启动速度 |\n| 重点产品 | 当期重点销售或重点维护产品，如 S 级产品 |\n| 清仓产品 | 需要配合库存、促销、清仓节奏进行销售与触达 |\n\n#### 4.3.3 字段规划\n\n| 字段 | 说明 |\n|---|---|\n| 产品名 | 产品展示名称 |\n| 国家 | 销售国家或市场 |\n| 品牌 | 所属品牌 |\n| 对应人员 | 负责该产品或站点的运营人员 |\n| 二级类目 | 产品所属二级类目 |\n| ASIN | 亚马逊 ASIN |\n| 产品类型 | 新品、重点产品、清仓产品 |\n| 各站点销量 | 各亚马逊站点销量，详细数据涉密 |\n| 总销量 | 汇总销量 |\n| APP 绑定数 | APP 可识别的、已绑定指定玩具的用户数 |\n| 绑定率 | APP 可识别的绑定了指定玩具的用户数 / 销售数 |\n| 异常状态 | 是否出现销量异常、绑定率异常、数据缺失等 |\n| 异常原因 | 异常说明或系统识别原因 |\n| 最近更新时间 | 数据刷新时间 |\n\n#### 4.3.4 重点指标\n\n- 产品销量\n- APP 绑定数\n- APP 绑定率\n- 新品绑定率爬坡情况\n- 重点产品绑定率\n- 清仓产品触达与绑定情况\n- 低绑定率产品列表\n- 异常站点/异常国家/异常类目\n\n#### 4.3.5 异常报警建议\n\n| 异常类型 | 触发逻辑 |\n|---|---|\n| 绑定率过低 | 产品销量正常，但 APP 绑定率低于目标值 |\n| 销量异常波动 | 单日或单周销量较基准值显著上升或下降 |\n| 站点数据缺失 | 某国家/站点销量或绑定数据未同步 |\n| 新品启动异常 | 新品有销量但绑定数或评价启动明显滞后 |\n| 重点产品风险 | S 级或重点产品绑定率、评价数、评分低于目标 |\n\n### 4.4 独立看板二：推新计划与 APP 推送资源分配看板\n\n#### 4.4.1 看板目标\n\n用于管理亚马逊推新计划和 APP 内现有推送资源之间的配合关系。\n\n推新计划的核心是关键词相关的重点产品推广，尤其是当期周度、月度重点产品，如 S 级产品。\n\nAPP 侧需要根据现有用户资源，在 APP 内用户中进行定向推送、曝光、点击、回复、登记和评价转化跟踪。\n\n#### 4.4.2 推新业务结构\n\n| 层级 | 内容 |\n|---|---|\n| 当期重点产品 | 周度、月度重点产品表，例如 S 级产品 |\n| 关键词策略 | 每个重点产品关联的关键词方向 |\n| 推新算法 | 基于产品重要级、用户资源、活跃度、绑定数、历史效果进行推送分配 |\n| APP 推送资源 | APP 内用户、社区消息、广告位、图片点击、活动曝光等 |\n| 效果回收 | 曝光、点击、回复、登记、评价、回评 |\n\n#### 4.4.3 字段规划\n\n| 字段 | 说明 |\n|---|---|\n| 产品名 | 推新产品名称 |\n| ASIN | 对应亚马逊 ASIN |\n| 产品重要级 | 如 S 级、A级、普通等 |\n| 关键词 | 推新关联关键词 |\n| 推送方案 | 当前采用的推送策略或资源组合 |\n| 推送 ID | APP 内推送任务 ID |\n| 关联图片点击率 | 推送图片或关联素材点击率 |\n| 产品绑定数 | 已绑定该产品的用户数 |\n| 总用户数 | APP 总用户数或目标用户池总数 |\n| 当月活跃用户数 | 当月活跃用户规模 |\n| 当月活跃率 | 当月活跃用户数 / 总用户数 |\n| 推送数 | 实际推送数量 |\n| 曝光数 | 用户实际看到的曝光数量 |\n| 点击数 | 用户点击数量 |\n| 回复数 | 用户回复数量 |\n| 登记数 | 用户登记或报名数量 |\n| 评价数 | 最终产生的评价数量 |\n| 回评数 | 最终产生的回评数量 |\n| 推送状态 | 未开始、进行中、已结束、暂停、异常 |\n| 负责人 | 推新或推送负责人 |\n\n#### 4.4.4 核心计算指标\n\n- 曝光率 = 曝光数 / 推送数\n- 点击率 = 点击数 / 曝光数\n- 回复率 = 回复数 / 点击数\n- 登记率 = 登记数 / 点击数\n- 评价转化率 = 评价数 / 登记数\n- 回评转化率 = 回评数 / 评价数\n- 活跃用户覆盖率 = 推送数 / 当月活跃用户数\n\n#### 4.4.5 当前推新资源分配口径\n\n当前推新计划先采用基础规则，后续逐步引入模型。\n\n现阶段基本逻辑：\n\n- S 级产品需求需要最大程度满足。\n- 当前流量池预计约 50% 分配给核心 S 级产品。\n- A 级、B 级及其他产品共同占用剩余约 50% 流量。\n- 产品数量比例上，S 级约 10 来个，其他产品约 200 来个。\n- 后续建议计划需要综合关键词需求、GEO 需求、销量、产品重要级和突发事件生成。\n\n### 4.5 独立看板三：测评计划与免评计划看板\n\n#### 4.5.1 看板目标\n\n用于管理亚马逊运营、用户运营与品牌运营协同的核心评价业务，包括测评计划和免评计划。\n\n协作关系：\n\n- 亚马逊运营：根据亚马逊销售需求提出测评计划、免评计划和回评目标。\n- 用户运营：负责实际触达、推送、登记、索评、回评跟进和结果回收。\n- 品牌运营：由于了解亚马逊运营需求，参与协同对接，但不是实际执行主责方。\n\n其中：\n\n- 测评计划：主要用于新品、重点产品的评价启动、评价数量建设和关键词推广配合。\n- 免评计划：主要基于关键词和实时销量策略进行定时下单，当前主要承接补单诉求。\n\n#### 4.5.2 字段规划\n\n| 字段 | 说明 |\n|---|---|\n| 计划 ID | 测评或免评计划唯一标识 |\n| 计划类型 | 测评计划、免评计划 |\n| 产品名 | 关联产品 |\n| ASIN | 关联 ASIN |\n| 国家/站点 | 亚马逊站点 |\n| 品牌 | 所属品牌 |\n| 产品类型 | 新品、重点、清仓 |\n| 产品重要级 | S 级、A级等 |\n| 关键词 | 计划关联关键词 |\n| 计划周期 | 周、月或指定活动周期 |\n| 计划数量 | 计划执行数量 |\n| 实际完成数量 | 已完成数量 |\n| 完成率 | 实际完成数量 / 计划数量 |\n| APP 配合方式 | 推送、广告位、社区触达、客服触达等 |\n| 风险等级 | 低、中、高 |\n| 审批状态 | 待审批、已审批、执行中、已结束、暂停 |\n| 负责人 | 亚马逊运营负责人 |\n| 协同负责人 | APP 或用户运营负责人 |\n\n#### 4.5.3 审批流口径\n\n测评计划、回评计划、免评计划需要建立审批流。\n\n流程口径：\n\n1. 亚马逊运营提出测评、回评、免评计划。\n2. 亚马逊运营总监审批确认。\n3. 审批通过后进入用户运营执行排期。\n4. 用户运营根据用户池、渠道资源和频控规则制定可执行计划。\n\n#### 4.5.4 风险说明\n\n免评计划、补单诉求、返现或强索评相关动作应进入风险管理与审批机制，不能只作为普通运营动作处理。\n\n建议后续单独规划：\n\n- 合规风险字段\n- 审批流\n- ASIN 风险状态\n- 账号风险状态\n- 高风险动作留痕\n\n### 4.6 独立看板四：回评计划与 ASIN 评价健康度看板\n\n#### 4.6.1 看板目标\n\n用于保障亚马逊链接的评价数和评分等级，尤其是新品爆款周期内，需要评价数量和评价等级与销售节奏匹配。\n\n核心目标：\n\n- 保障链接评价数\n- 保障评分等级\n- 支撑新品爆款周期\n- 识别 ASIN 评价健康风险\n- 区分新品、重点产品、清仓产品的回评需求\n\n#### 4.6.2 评价健康标准\n\n当前业务描述中的核心标准：\n\n- 评价数要与新品爆款周期匹配，原则上数量要多。\n- 评价等级需要维持在较高水平。\n- 新品或爆款产品期望评价等级原则上应达到 4.8 以上。\n- 4.8 属于很健康。\n- 4.5 属于健康。\n- 4.2 属于高风险，需要加强对未回评用户的回评推送。\n\n#### 4.6.3 字段规划\n\n| 字段 | 说明 |\n|---|---|\n| ASIN | 亚马逊 ASIN |\n| 产品名 | 产品名称 |\n| 国家/站点 | 销售国家或亚马逊站点 |\n| 品牌 | 所属品牌 |\n| 产品类型 | 新品、重点、清仓 |\n| 产品重要级 | S 级、A级等 |\n| 当月计划回评数 | 当月计划获得的回评数量 |\n| 实际回评数 | 当月实际回评数量 |\n| 回评完成率 | 实际回评数 / 当月计划回评数 |\n| 期望评价等级 | 目标评分等级 |\n| 实际评价等级 | 当前实际评分等级 |\n| 当前评价数 | 当前累计评价数量 |\n| 当月新增评价数 | 当月新增评价数量 |\n| 差评数 | 当前或当月差评数量 |\n| 差评率 | 差评数 / 评价数 |\n| 健康状态 | 健康、关注、风险、严重风险 |\n| 负责人 | ASIN 负责人 |\n\n#### 4.6.4 产品类型下的回评管理\n\n| 产品类型 | 回评管理重点 |\n|---|---|\n| 新品 | 评价启动速度、评价数量爬坡、评分稳定性、爆款周期匹配 |\n| 重点产品 | 评分等级维护、差评预警、持续回评目标达成 |\n| 清仓产品 | 根据清仓节奏决定是否继续投入回评资源，避免资源浪费 |\n\n#### 4.6.5 ASIN 评价健康等级\n\n| 实际评价等级 | 健康状态 | 处理建议 |\n|---|---|---|\n| 4.8 及以上 | 很健康 | 维持正常回评节奏，重点保障新品爆款周期 |\n| 4.5-4.79 | 健康 | 保持监控，按计划推进回评 |\n| 4.2-4.49 | 高风险 | 加强对未回评用户的回评推送 |\n| 低于 4.2 | 严重风险 | 需要升级处理，结合客服、用户运营和亚马逊运营共同干预 |\n\n### 4.7 亚马逊运营协同品牌推广计划\n\n品牌推广计划由亚马逊运营与品牌运营协同完成。\n\n除亚马逊站内的品牌承接和销售动作外，以下工作以品牌运营为主进行决策，亚马逊运营同步即可：\n\n- JOYHUB 内推广\n- 社媒互动\n- 新品宣发\n- 活动宣发\n- 粉丝互动管理\n- 销售管理\n- 独立站推广\n- 新品推广\n- 社媒数据\n- KOL 互动数据\n\n#### 4.7.1 品牌推广协同数据\n\n| 字段 | 说明 |\n|---|---|\n| 推广计划 ID | 品牌推广计划唯一标识 |\n| 推广类型 | JOYHUB、社媒、新品宣发、活动宣发、KOL、独立站等 |\n| 产品名 | 关联产品 |\n| ASIN | 关联 ASIN |\n| 品牌 | 所属品牌 |\n| 国家 | 推广国家 |\n| 渠道 | 推广渠道 |\n| 曝光数 | 推广曝光 |\n| 点击数 | 推广点击 |\n| 跳转数 | 跳转到亚马逊或独立站的数量 |\n| 转化数 | 产生转化数量 |\n| 成交数 | 产生订单数量 |\n| 互动数 | 点赞、评论、私信、粉丝互动等 |\n| KOL 信息 | 合作达人或账号 |\n| 负责人 | 推广负责人 |\n\n## 5. 第二部分：品牌运营相关业务\n\n### 5.1 品牌运营在闭环中的定位\n\n品牌运营与亚马逊运营不在同一个办公区，但需要协助亚马逊运营共同建立销售体系。\n\n品牌运营的核心定位是：\n\n1. 负责独立站品牌宣发。\n2. 负责在社媒建立品牌形象。\n3. 负责独立站成交与品牌侧销售管理。\n4. 协助亚马逊运营在亚马逊平台上提高品牌调性。\n5. 协助亚马逊运营扩大品牌在亚马逊上的市场份额。\n6. 与亚马逊运营共同参与品牌推广计划。\n7. 在亚马逊站外品牌推广相关事项上，品牌运营为主责决策方，亚马逊运营同步。\n\n### 5.2 品牌运营与亚马逊运营的分工边界\n\n| 业务事项 | 主责方 | 协同方 | 说明 |\n|---|---|---|---|\n| 亚马逊站内销售 | 亚马逊运营 | 品牌运营 | 品牌运营协助提高品牌调性和市场份额 |\n| 亚马逊站内品牌承接 | 亚马逊运营 | 品牌运营 | Listing、品牌内容、品牌调性需要双方协同 |\n| 独立站品牌宣发 | 品牌运营 | 亚马逊运营同步 | 独立站推广和转化由品牌运营主责 |\n| 独立站成交 | 品牌运营 | 亚马逊运营同步 | 独立站销售数由品牌运营负责 |\n| 社媒品牌形象 | 品牌运营 | 亚马逊运营同步 | 包含账号内容、互动、粉丝维护 |\n| JOYHUB 内推广 | 品牌运营 | 亚马逊运营同步 | 实际为品牌运营工作，亚马逊运营了解进度 |\n| 新品宣发 | 品牌运营 | 亚马逊运营同步 | 站外宣发主责在品牌运营 |\n| 活动宣发 | 品牌运营 | 亚马逊运营同步 | 活动口径需要与销售节奏同步 |\n| 粉丝互动管理 | 品牌运营 | 亚马逊运营同步 | 社媒与品牌用户关系维护 |\n| KOL 互动 | 品牌运营 | 亚马逊运营同步 | KOL 数据和互动效果由品牌运营负责 |\n| AMZ 测评计划 | 亚马逊运营、用户运营 | 品牌运营协同 | 亚马逊运营提需求，用户运营实现，品牌运营参与协同 |\n| 回评计划 | 亚马逊运营、用户运营 | 品牌运营协同 | 主要服务 ASIN 评价健康度 |\n\n### 5.3 品牌运营核心业务模块\n\n| 模块 | 业务内容 | 输出 |\n|---|---|---|\n| 品牌宣发 | 独立站、社媒、JOYHUB、新品、活动等品牌曝光 | 品牌推广计划、宣发内容、渠道效果 |\n| 社媒运营 | 建立品牌形象、粉丝互动、社媒内容发布 | 社媒访问、点击、互动、转化数据 |\n| 独立站推广 | 独立站访问、点击、转化、成交管理 | 独立站销售数、转化漏斗 |\n| 新品推广 | 新品宣发、站外曝光、内容传播 | 新品推广数据、用户兴趣数据 |\n| 活动推广 | 活动宣发、活动页面、粉丝触达 | 活动曝光、点击、转化、成交 |\n| KOL 合作 | KOL 互动、达人合作、内容发布 | KOL 互动数据、访问与转化效果 |\n| 品牌销售管理 | 独立站成交、品牌侧销售数据管理 | 销售数、成交数、转化数 |\n| 亚马逊协同 | 协助亚马逊提升品牌调性和市场份额 | 品牌素材、推广节奏、协同反馈 |\n\n### 5.4 独立看板五：品牌影响力与独立站销售看板\n\n#### 5.4.1 看板目标\n\n用于衡量品牌运营在独立站、社媒、JOYHUB、KOL、新品宣发和活动宣发等渠道中的影响力、转化效果和销售结果。\n\n该看板以品牌运营为主责，亚马逊运营同步查看，用于判断站外品牌推广对亚马逊销售和独立站销售的辅助效果。\n\n#### 5.4.2 字段规划\n\n| 字段 | 说明 |\n|---|---|\n| 品牌 | 所属品牌 |\n| 国家 | 推广国家或市场 |\n| 渠道来源 | 独立站、社媒、JOYHUB、KOL、新品宣发、活动宣发等 |\n| 推广类型 | 新品、活动、日常内容、KOL、粉丝互动等 |\n| 产品名 | 关联产品 |\n| ASIN | 如有关联亚马逊产品，则记录 ASIN |\n| 负责人 | 品牌运营负责人 |\n| 访问数 | 各来源访问量 |\n| 点击数 | 各来源点击量 |\n| 转化数 | 各来源转化数量 |\n| 销售数 | 独立站或品牌侧销售数量，由品牌运营负责 |\n| 成交数 | 实际成交订单数量 |\n| 互动数 | 点赞、评论、分享、私信、粉丝互动等 |\n| KOL 信息 | 合作达人或账号信息 |\n| 内容/活动 ID | 关联内容、活动或投放任务 |\n| 跳转目标 | 亚马逊、独立站、APP、活动页等 |\n| 数据周期 | 日、周、月、活动周期 |\n\n#### 5.4.3 核心指标\n\n- 访问数\n- 点击数\n- 转化数\n- 销售数\n- 成交数\n- 社媒互动数\n- KOL 互动数据\n- 独立站转化率\n- 渠道访问贡献\n- 品牌活动转化效果\n\n#### 5.4.4 品牌影响力评估口径\n\n品牌影响力从两方面评估：\n\n1. 各渠道转化，包括独立站转化、亚马逊跳转转化、APP 承接转化等。\n2. 社媒影响力与调研反馈，包括互动、评论、粉丝反馈和品牌认知反馈。\n\n通过品牌活动前往亚马逊形成的转化，也归属品牌运营 OKR 结果。\n\n### 5.5 独立看板六：品牌推广计划协同看板\n\n#### 5.5.1 看板目标\n\n用于管理品牌运营与亚马逊运营共同参与的品牌推广计划。\n\n该看板需要明确：\n\n- 品牌运营在站外推广中的主责地位\n- 亚马逊运营在亚马逊站内承接品牌调性与销售转化的职责\n- 品牌推广与亚马逊销售、独立站销售、APP 用户增长之间的关系\n- 品牌推广计划与 AMZ 测评计划之间的协同关系\n\n#### 5.5.2 字段规划\n\n| 字段 | 说明 |\n|---|---|\n| 推广计划 ID | 品牌推广计划唯一标识 |\n| 推广计划名称 | 计划名称 |\n| 主责部门 | 品牌运营 |\n| 协同部门 | 亚马逊运营、用户运营、内容运营等 |\n| 推广类型 | JOYHUB、社媒、新品宣发、活动宣发、KOL、独立站等 |\n| 品牌 | 所属品牌 |\n| 国家 | 推广国家 |\n| 产品名 | 关联产品 |\n| ASIN | 关联亚马逊 ASIN |\n| 独立站链接 | 独立站承接地址 |\n| 亚马逊链接 | 亚马逊承接地址 |\n| APP 承接方式 | 是否需要 APP 内承接、推送或活动页 |\n| 计划开始时间 | 推广开始时间 |\n| 计划结束时间 | 推广结束时间 |\n| 预算 | 推广预算 |\n| 访问数 | 推广访问量 |\n| 点击数 | 推广点击量 |\n| 转化数 | 推广转化数量 |\n| 销售数 | 品牌侧销售数量 |\n| 成交数 | 实际成交订单 |\n| 亚马逊同步状态 | 未同步、已同步、需调整 |\n| 计划状态 | 草稿、待确认、执行中、已结束、暂停 |\n\n### 5.6 品牌运营参与 AMZ 测评计划的协作关系\n\nAMZ 测评计划由三方协作完成：\n\n| 角色 | 职责 |\n|---|---|\n| 亚马逊运营 | 根据亚马逊平台销售需求提出测评计划、回评计划、关键词和产品优先级需求 |\n| 品牌运营 | 理解并同步亚马逊运营需求，协同亚马逊运营与用户运营对接 |\n| 用户运营 | 负责实际实现，包括用户触达、推送、登记、索评、回评跟进和结果反馈 |\n\n需要明确的是：\n\n- 测评计划和回评计划的主要协作方是亚马逊运营与用户运营。\n- 品牌运营参与协同，但不是实际落地执行主责方。\n- 品牌运营的核心主责仍然是品牌宣发、社媒品牌形象、独立站成交和站外推广管理。\n\n### 5.7 APP 内资源协同边界\n\n| 资源类型 | 管理分配方 | 品牌运营角色 |\n|---|---|---|\n| APP 内社区资源 | 内容运营分配，品牌运营与内容运营协同 | 将亚马逊运营和品牌运营需求与内容运营协商 |\n| 用户推送资源 | 用户运营管理分配 | 将亚马逊运营和品牌运营需求与用户运营协商 |\n\n品牌运营熟悉内容运营和用户运营两侧资源，负责把亚马逊运营需求和品牌运营自身需求同步给相关部门，并推动协商解决。\n\n### 5.8 品牌运营与其他部门的数据关系\n\n| 数据流向 | 内容 | 用途 |\n|---|---|---|\n| 品牌运营 → 亚马逊运营 | 品牌推广计划、社媒/KOL 数据、新品宣发节奏、活动宣发数据 | 帮助亚马逊站内承接品牌调性和销售转化 |\n| 亚马逊运营 → 品牌运营 | 亚马逊销售需求、重点 ASIN、推新节奏、测评需求、关键词方向 | 品牌运营理解销售重点并做站外协同 |\n| 品牌运营 → 用户运营 | 推广计划、活动节奏、需要 APP 承接的用户触达需求 | APP 内推送、活动承接、用户触达 |\n| 用户运营 → 品牌运营 | APP 用户反馈、触达数据、活动参与、评价反馈 | 优化品牌内容和活动策略 |\n| 品牌运营 → 数据层/管理层 | 访问、点击、转化、销售数、互动数、KOL 数据 | 品牌影响力、渠道 ROI、独立站销售复盘 |\n\n## 6. 第三部分：用户运营相关业务\n\n### 6.1 用户运营在闭环中的定位\n\n用户运营是该系统的核心使用者。客服部门实际也归属用户部门管理。\n\n用户运营的核心定位是：\n\n1. 接收亚马逊运营与品牌运营协同后的销售数据和测评需求。\n2. 根据关键词、销量、产品重要级、ASIN 评价健康度共同制定可执行的测评计划。\n3. 基于 APP 用户、绑定用户、活跃用户、社区用户、非 APP 或低活跃用户进行分层触达。\n4. 在社区中与用户互动，鼓励测评人参与。\n5. 负责推送、登记、索评、回评跟进和结果回收。\n6. 按 ASIN 评价健康度动态调整触达资源和回评节奏。\n7. 管理 TEL、EDM、KOC/KOL/PR、短信、社区、非评价推送等多渠道触达。\n8. 管理客服售后相关执行数据，并将售后反馈纳入触达策略优化。\n\n### 6.2 用户运营核心业务模块\n\n| 模块 | 业务内容 | 输出 |\n|---|---|---|\n| 测评计划执行 | 根据亚马逊销售需求、关键词、销量、产品重要级制定可执行测评计划 | 推送计划、登记数据、评价数、计划完成度 |\n| 用户社区互动 | 在 APP 社区中与用户互动，鼓励用户参与新玩具测评 | 回复数、登记数、评价数 |\n| 回评计划跟进 | 根据 ASIN 评价健康度跟进回评目标 | 回评完成度、风险等级、ASIN 健康状态 |\n| IM 社区消息推送 | 推动新玩具购买与买后索评 | 曝光、点击、回复、登记、出评 |\n| 已成交索评 | 针对已绑定、已购买玩具的用户进行索评 | 实际回评数、评价等级改善 |\n| TEL 电话售后 | 接听售后和呼出电话 | 接听售后数据、呼出数据、售后原因 |\n| EDM 邮件推送 | 针对非 APP 或低 APP 活跃用户进行邮件触达 | 打开、点击、回复、转化 |\n| KOC/KOL/PR 合作 | 通过 JOYCOLLAB 网站管理合作伙伴体系 | 合作伙伴效果、带货链接、销售与提成数据 |\n| 其他触达渠道 | 短信、社区、非评价推送等仍在搭建中的渠道 | 新增测评渠道、内容改善、用户反感度控制 |\n\n### 6.3 测评计划执行数据\n\n用户运营根据亚马逊运营和品牌运营协同后的需求，结合销售数据、关键词和销量生成可执行的测评计划。\n\n测评计划的关键是把“销售侧需求”转化为“用户侧可执行动作”。\n\n#### 6.3.1 字段规划\n\n| 字段 | 说明 |\n|---|---|\n| 产品名 | 关联产品 |\n| ASIN | 亚马逊 ASIN |\n| 产品重要级 | S 级、重点、普通等 |\n| 关键词 | 亚马逊运营提出的关键词方向 |\n| 推送方案 | 用户运营制定的触达策略 |\n| 推送 ID | 推送任务唯一标识 |\n| 关联图片点击率 | 推送图片或素材点击率 |\n| 产品绑定数 | 已绑定该产品的用户数 |\n| 总用户数 | 可触达用户总数 |\n| 当月活跃用户数 | 当月活跃用户规模 |\n| 当月活跃率 | 当月活跃用户数 / 总用户数 |\n| 推送数 | 实际推送数量 |\n| 曝光数 | 实际曝光数量 |\n| 点击数 | 实际点击数量 |\n| 回复数 | 用户回复数量 |\n| 登记数 | 用户报名、登记或确认参与数量 |\n| 评价数 | 最终产生的评价数量 |\n\n### 6.4 ASIN 评价健康度与回评计划\n\n用户运营需要根据随时更新的 Listing 健康状况和 ASIN 评价健康度跟进回评计划。\n\n核心原则：\n\n- 新品爆款周期需要与评价数量和评价等级匹配。\n- 新品和爆款原则上评价数量要多。\n- 新品和爆款的期望评价等级原则上应达到 4.8 以上。\n- 常规产品需要保障链接评价数和评分等级。\n- 回评计划需要区分新品、重点产品、清仓产品。\n\n#### 6.4.1 字段规划\n\n| 字段 | 说明 |\n|---|---|\n| ASIN | 亚马逊 ASIN |\n| 产品名 | 关联产品 |\n| 产品类型 | 新品、重点、清仓 |\n| 当月计划回评数 | 当月计划回评数量 |\n| 实际回评数 | 当月实际完成回评数量 |\n| 期望评价等级 | 目标评价等级 |\n| 实际评价等级 | 当前实际评价等级 |\n| 回评完成率 | 实际回评数 / 当月计划回评数 |\n| 风险等级 | 健康、关注、风险、严重风险 |\n| 跟进人 | 用户运营负责人 |\n\n### 6.5 独立看板七：IM 社区消息推送计划看板\n\n#### 6.5.1 业务场景\n\nIM 社区消息推送主要用于推动新玩具测评。\n\n当用户没有购买我们想推动的新玩具时，用户运营通过 IM 社区消息推送促使用户购买新玩具，并在购买后进行索评。\n\n#### 6.5.2 看板目标\n\n按地区、品牌、类目、策略观察不同推送计划的效果。\n\n#### 6.5.3 字段规划\n\n| 字段 | 说明 |\n|---|---|\n| 推送 ID | 推送任务唯一标识 |\n| 关联产品 | 推送关联产品 |\n| ASIN | 关联 ASIN |\n| 国家/地区 | 推送覆盖地区 |\n| 品牌 | 所属品牌 |\n| 类目 | 产品类目 |\n| 策略 | 推送策略 |\n| 曝光 | 推送曝光数 |\n| 点击 | 用户点击数 |\n| 回复 | 用户回复数 |\n| 登记 | 用户登记数 |\n| 出评 | 最终产生评价数 |\n| 转化率 | 出评或登记转化率 |\n| 计划完成度 | 实际完成 / 计划目标 |\n| 订单号 | 订单号，含亚马逊来源和独立站来源，涉密字段 |\n| 订单来源 | 亚马逊、独立站等 |\n| profile ID | 用户 Profile 标识，涉密字段 |\n| joyhub ID | JOYHUB 用户标识，涉密字段 |\n\n### 6.6 独立看板八：已成交索评与回评计划完成度看板\n\n#### 6.6.1 业务场景\n\n当用户已经绑定某个玩具时，APP 能识别用户购买了哪个玩具。用户运营可以针对已有玩具进行已成交索评。\n\n该看板与 ASIN 评价健康度直接关联，用于确保亚马逊链接健康。\n\n#### 6.6.2 字段规划\n\n| 字段 | 说明 |\n|---|---|\n| 产品类型 | 新品、重点、清仓 |\n| 产品名 | 关联产品 |\n| ASIN | 关联 ASIN |\n| 产品计划回评数 | 当前产品计划回评数量 |\n| 实际回评数 | 当前产品实际回评数量 |\n| 回评完成率 | 实际回评数 / 产品计划回评数 |\n| 当前 ASIN 评价等级 | 当前 ASIN 星级或评分 |\n| 风险等级 | 健康、关注、风险、严重风险 |\n| 负责人 | 用户运营负责人 |\n\n### 6.7 独立看板九：TEL 电话售后渠道看板\n\n#### 6.7.1 业务场景\n\nTEL 电话售后渠道包括接听售后和呼出电话，主要用于改善服务、收集售后问题、支撑索评和降低负面反馈。\n\n#### 6.7.2 字段规划\n\n| 字段 | 说明 |\n|---|---|\n| 电话号码 | 高度涉密字段 |\n| 国家 | 用户国家 |\n| 品牌 | 关联品牌 |\n| 产品 | 关联产品 |\n| 售后原因 | 用户咨询或售后原因 |\n| 呼出数 | 呼出电话数量 |\n| 接听数 | 接听电话数量 |\n| 订单号 | 涉密字段 |\n| 跟进人 | 客服或用户运营负责人 |\n| 处理状态 | 待处理、处理中、已完结、需升级 |\n\n### 6.8 独立看板十：EDM 邮件推送渠道看板\n\n#### 6.8.1 业务场景\n\nEDM 邮件推送主要面向非 APP 用户或低 APP 活跃用户，用于补充 APP 内推送触达能力。\n\n#### 6.8.2 看板目标\n\n用于持续改善 EDM 计划，包括邮件打开、点击、回复和转化效果。\n\n#### 6.8.3 字段规划\n\n| 字段 | 说明 |\n|---|---|\n| 国家 | 用户国家 |\n| 地区 | 用户地区 |\n| 邮件服务商 | 邮件服务商 |\n| 用户邮箱 | 高度涉密字段 |\n| USER ID | 非 APP 用户 ID |\n| 推送 ID | EDM 推送任务 ID |\n| 点击数 | 邮件点击数量 |\n| 打开数 | 邮件打开数量 |\n| 回复数 | 邮件回复数量 |\n| 转化数 | 由邮件触达带来的转化数量 |\n| 计划状态 | 草稿、执行中、已结束、异常 |\n\n### 6.9 独立看板十一：KOC/KOL/PR 合作伙伴效果看板\n\n#### 6.9.1 业务场景\n\nKOC、KOL、PR 渠道用于合作伙伴对接和带货推广。合作伙伴体系通过 JOYCOLLAB 网站承接。\n\nKOC 在 JOYCOLLAB 上的带货数据原则上先在 JOYCOLLAB 网站内处理，再同步到大用户后台。财务也会参与销售数据、提成数据和交易金额的核算或校验。\n\n#### 6.9.2 看板目标\n\n用于改善合作伙伴效果，观察合作伙伴在不同国家、平台、产品和带货链路上的实际贡献。\n\n#### 6.9.3 字段规划\n\n| 字段 | 说明 |\n|---|---|\n| 合作伙伴 ID | 合作伙伴唯一标识 |\n| 国家 | 合作伙伴所在国家 |\n| 姓名 | 合作伙伴姓名，涉密字段 |\n| 时间 | 合作或跟进时间 |\n| 平台 | 合作平台 |\n| 粉丝 | 粉丝数量或粉丝规模 |\n| 备注 | 合作备注 |\n| 跟进人 | 用户运营或合作伙伴负责人 |\n| 合作产品 | 合作推广产品 |\n| 带货链接 | 合作伙伴带货链接 |\n| 销售数据 | 通过带货链接产生的销售数据 |\n| 提成数据 | 合作伙伴提成数据，涉密字段 |\n| 交易金额 | 产生的交易金额 |\n\n### 6.10 其他触达渠道\n\n其他渠道包括：\n\n- 短信\n- 社区\n- 非评价推送\n\n这些渠道仍在搭建当中，目标包括：\n\n1. 继续增加测评渠道。\n2. 改善内容触达效果。\n3. 降低用户对高频推送、索评、活动通知的反感。\n4. 为非评价类推送沉淀策略，例如活动、内容、售后提醒、品牌互动。\n\n### 6.11 用户识别、黑名单与频控口径\n\n#### 6.11.1 用户识别主标识\n\n订单号和 JOYHUB ID 是用户索评与黑名单查询中的两个主要标识。\n\n订单号包括：\n\n- 亚马逊来源订单号\n- 独立站来源订单号\n\n当用户注册后，必然有 JOYHUB ID。 \n当用户提供订单号时，JOYHUB ID 和订单号建立关联。\n\nAPP 侧还会保留注册邮箱、用户基础 IP、设备号、用户行为数据等信息。订单号可以关联用户地址、姓名、用户名等信息。\n\n#### 6.11.2 邮箱、账号与风险关联\n\n注册用户的 JOYHUB ID 和邮箱必然关联。部分用户可能使用多个邮箱注册多个账号，每个账号都有独立 JOYHUB ID。\n\n系统需要通过 IP、设备号等信息做黑名单关联。关联后，多个账号可被认定为关联账号，或在后台被划入高度风险关联，并按单一用户处理。\n\n#### 6.11.3 多渠道统一频控\n\nTEL、EDM、IM、社区、短信等渠道需要统一控制触达频率，并统一了解对用户的骚扰程度，避免过于频繁触达导致用户反感。\n\n### 6.12 用户运营与其他部门的数据关系\n\n| 数据流向 | 内容 | 用途 |\n|---|---|---|\n| 亚马逊运营 → 用户运营 | 销售数据、关键词、重点产品、测评需求、回评目标、ASIN 健康状态 | 制定可执行测评计划和回评计划 |\n| 品牌运营 → 用户运营 | 品牌推广计划、活动节奏、站外触达需求、APP 承接需求 | 配合品牌推广进行 APP 内触达 |\n| 用户运营 → 亚马逊运营 | 推送效果、登记数、评价数、回评数、ASIN 风险反馈 | 调整测评计划、推新计划和评价健康策略 |\n| 用户运营 → 品牌运营 | 用户反馈、触达效果、活动参与、转化结果 | 优化品牌内容、活动和独立站推广 |\n| 用户运营 → 客服运营 | 待跟进用户、售后触达需求、负面反馈线索 | 电话售后、问题处理和服务改善 |\n| 客服运营 → 用户运营 | 接听售后数据、呼出数据、售后原因、处理结果 | 优化推送策略、索评节奏和用户分层 |\n| 用户运营 → 数据层/管理层 | 推送、登记、评价、回评、TEL、EDM、合作伙伴数据 | 复盘渠道效果、人效、成本和风险 |\n\n## 7. 第四部分：菲律宾客服相关业务\n\n### 7.1 菲律宾客服在闭环中的定位\n\n菲律宾客服直接接受用户运营指导工作。\n\n当亚马逊运营存在短期需求变动时，不直接绕过用户运营调整客服工作，而是通过用户运营转达和排期。这样可以保证测评计划、回评计划、售后触达、人员安排和成本统计在同一套用户运营口径下管理。\n\n菲律宾客服的核心定位是：\n\n1. 执行用户运营下发的评价、登记、回复、售后跟进等具体任务。\n2. 承接各渠道用户接待与基础沟通。\n3. 配合评价计划落地，提升评价转化和完结评价数。\n4. 反馈客服侧接待、登记、回复、完结情况。\n5. 支撑用户运营进行成本管理、人效管理和渠道效果复盘。\n\n### 7.2 核心指标\n\n| 指标 | 说明 |\n|---|---|\n| 客源 | 来自不同渠道的用户来源或待处理线索 |\n| 转化数 | 从接待、登记、回复到评价完成的转化数量 |\n| 转化率 | 评价转化数 / 客源或登记数 |\n| 节约成本 | 通过客服执行、人效提升、渠道优化节约的成本 |\n\n### 7.3 独立看板十二：菲律宾客服人员管理看板\n\n#### 7.3.1 看板目标\n\n用于管理菲律宾客服人员、出勤、每日工作量和各渠道执行情况。\n\n#### 7.3.2 字段规划\n\n| 字段 | 说明 |\n|---|---|\n| 人员 | 客服人员姓名或账号 |\n| 团队/组别 | 所属客服小组 |\n| 出勤 | 出勤状态、出勤天数或工时 |\n| 日期 | 工作日期 |\n| 渠道 | IM、TEL、EDM、社区、KOC/KOL/PR、其他 |\n| 接待数 | 当日接待用户数量 |\n| 登记数 | 当日登记数量 |\n| 回复数 | 当日回复数量 |\n| 每日评价数 | 当日产生评价数量 |\n| 完结评价数 | 当日完结评价数量，按各渠道统计 |\n| 待处理数 | 尚未处理或未完结任务数量 |\n| 负责人 | 用户运营或客服主管 |\n\n### 7.4 独立看板十三：菲律宾客服评价计划管理看板\n\n#### 7.4.1 看板目标\n\n用于跟踪菲律宾客服执行评价计划的过程和结果，重点观察客源、登记、回复、出评和计划完成度。\n\n#### 7.4.2 字段规划\n\n| 字段 | 说明 |\n|---|---|\n| 评价计划 ID | 关联测评或回评计划 |\n| 推送 ID | 关联用户运营推送任务 |\n| 产品名 | 关联产品 |\n| ASIN | 关联 ASIN |\n| 产品类型 | 新品、重点、清仓 |\n| 渠道 | IM、TEL、EDM、社区、其他 |\n| 客源数 | 进入客服处理池的用户数量 |\n| 接待数 | 客服实际接待数量 |\n| 登记数 | 用户登记或确认参与数量 |\n| 回复数 | 用户回复数量 |\n| 每日评价数 | 每日产生评价数量 |\n| 完结评价数 | 完成闭环的评价数量 |\n| 转化数 | 从客源到评价完成的转化数量 |\n| 转化率 | 转化数 / 客源数或登记数 |\n| 计划完成度 | 实际完成 / 计划目标 |\n| 跟进人 | 菲律宾客服人员 |\n| 指导人 | 用户运营负责人 |\n\n### 7.5 独立看板十四：菲律宾客服成本管理看板\n\n#### 7.5.1 看板目标\n\n用于管理菲律宾客服相关人力成本、财务表和成本节约效果。\n\n#### 7.5.2 字段规划\n\n| 字段 | 说明 |\n|---|---|\n| 人员 | 客服人员 |\n| 出勤 | 出勤天数或工时 |\n| 人力成本 | 人员工资、补贴或对应成本 |\n| 提成 | 如存在评价、转化或完结相关提成，则单独记录 |\n| 管理成本 | 管理、培训、工具等分摊成本 |\n| 完结评价数 | 该人员或团队完成评价数量 |\n| 单评成本 | 总成本 / 完结评价数 |\n| 转化数 | 产生的有效转化数量 |\n| 单转化成本 | 总成本 / 转化数 |\n| 节约成本 | 因流程改善、人效提升或渠道优化节约的成本 |\n| 财务表 | 人事或财务表关联记录 |\n\n### 7.6 菲律宾客服与其他部门的数据关系\n\n| 数据流向 | 内容 | 用途 |\n|---|---|---|\n| 用户运营 → 菲律宾客服 | 评价计划、待跟进用户、推送任务、短期需求变动、售后跟进要求 | 指导客服执行 |\n| 菲律宾客服 → 用户运营 | 出勤、接待、登记、回复、每日评价、完结评价数、售后反馈 | 用户运营复盘渠道效果、人效和计划完成情况 |\n| 亚马逊运营 → 用户运营 → 菲律宾客服 | 亚马逊运营短期测评、回评或售后需求变动 | 通过用户运营统一转达，避免执行口径混乱 |\n| 菲律宾客服 → 数据层/管理层 | 人员、人效、评价转化、成本、财务表数据 | 成本管理、绩效评估和管理复盘 |\n\n## 8. 第五部分：内容运营相关业务\n\n### 8.1 内容运营在闭环中的定位\n\n内容运营在当前以用户运营为核心的业务需求中，主要负责配合亚马逊运营与品牌运营，在销售前期为产品做宣发和社区内流量承接。\n\n内容运营的核心定位是：\n\n1. 配合亚马逊运营和品牌运营做产品售前宣发。\n2. 管理 APP 内广告资源，包括开屏、弹窗、文末、ME、评论末等位置。\n3. 在社区内配合用户 KOC/KCO 对接，支持产品内容传播和测评前期预热。\n4. 执行售前社区广告计划。\n5. 通过推流管理提升重点产品、重点帖子、活动内容的曝光和点击。\n6. 管理加权、新帖、固定位置和固定流量池资源。\n7. 监控曝光、点击、打开、跳转、成交和互动数据，并识别风险。\n\n### 8.2 内容运营核心业务模块\n\n| 模块 | 业务内容 | 输出 |\n|---|---|---|\n| 售前社区广告计划 | 配合产品上市、活动、测评计划做社区前期宣发 | 广告计划、曝光、点击、跳转、成交数据 |\n| APP 广告管理 | 管理开屏、弹窗、文末、ME、评论末等广告位 | 广告位排期、用户行为数据、转化数据 |\n| 推流管理 | 对帖子加权、新帖扶持、固定位置投放、固定流量池管理 | 帖子曝光、点击、打开、互动、风险数据 |\n| KOC/KCO 对接 | 在社区中与用户或内容参与者对接 | 内容互动、测评预热、社区反馈 |\n| 风险识别 | 识别异常用户、异常互动、内容风险或投流风险 | 风险标记、处理建议 |\n\n### 8.3 独立看板十五：APP 广告管理看板\n\n#### 8.3.1 看板目标\n\n用于管理 APP 内广告位资源，支撑亚马逊运营和品牌运营在销售前期进行产品宣发、活动宣发和售前社区触达。\n\n广告位包括：\n\n- 开屏\n- 弹窗\n- 文末\n- ME\n- 评论末\n\n#### 8.3.2 字段规划\n\n| 字段 | 说明 |\n|---|---|\n| 月份 | 月度统计周期 |\n| 日期 | 每日统计周期 |\n| 产品 | 关联产品 |\n| ASIN | 如关联亚马逊产品，则记录 ASIN |\n| 品牌 | 所属品牌 |\n| 国家/地区 | 投放国家或地区 |\n| 广告位 | 开屏、弹窗、文末、ME、评论末等 |\n| 绑定情况 | 产品绑定用户数、绑定率或绑定状态 |\n| 用户行为 | 浏览、点击、打开、跳转、互动、购买等行为 |\n| 性别 | 用户性别 |\n| 其他标记用户数 | 风险用户、重点用户、异常用户或其他业务标记用户数 |\n| 曝光 | 广告曝光数 |\n| 点击 | 广告点击数 |\n| 打开 | 广告打开数 |\n| 跳转 | 跳转到产品页、亚马逊、独立站、活动页或 APP 页面数量 |\n| 成交数 | 由广告触达带来的成交数量 |\n| 负责人 | 内容运营负责人 |\n\n#### 8.3.3 核心指标\n\n- 曝光数\n- 点击数\n- 打开数\n- 跳转数\n- 成交数\n- 点击率\n- 打开率\n- 跳转率\n- 成交转化率\n- 不同广告位效果对比\n\n### 8.4 独立看板十六：推流管理看板\n\n#### 8.4.1 看板目标\n\n用于管理社区内容推流，包括帖子加权、新帖推流、固定位置和固定流量池。\n\n该看板服务于售前社区广告计划，帮助重点产品和重点内容获得更稳定的曝光与互动。\n\n#### 8.4.2 推流动作\n\n| 动作 | 说明 |\n|---|---|\n| 加权 | 对重点帖子或产品内容增加推荐权重 |\n| 新帖 | 对新发布内容进行启动流量扶持 |\n| 固定位置 | 将内容投放到指定社区位置 |\n| 固定流量池管理 | 管理固定流量池分配和资源占用 |\n\n#### 8.4.3 字段规划\n\n| 字段 | 说明 |\n|---|---|\n| 帖子 ID | 社区帖子唯一标识 |\n| 产品 | 关联产品 |\n| ASIN | 如关联亚马逊产品，则记录 ASIN |\n| 品牌 | 所属品牌 |\n| 发帖人属性 | 发帖人身份、用户类型、KOC/KCO、普通用户等 |\n| 帖子周期 | 新帖期、加权期、稳定期、结束期等 |\n| 投流等级 | 投流优先级或资源等级 |\n| 流量等级 | 实际分配的流量层级 |\n| 固定位置 | 是否使用固定位置及位置名称 |\n| 固定流量池 | 是否占用固定流量池及流量池名称 |\n| 曝光 | 帖子曝光数 |\n| 点击 | 帖子点击数 |\n| 打开 | 帖子打开数 |\n| 互动数 | 点赞、评论、收藏、分享、回复等互动总数 |\n| 各互动数 | 各类型互动明细 |\n| 风险 | 内容风险、用户风险、异常互动或投流风险 |\n| 负责人 | 内容运营负责人 |\n\n### 8.5 内容运营与其他部门的数据关系\n\n| 数据流向 | 内容 | 用途 |\n|---|---|---|\n| 亚马逊运营 → 内容运营 | 重点产品、ASIN、推新节奏、售前宣发需求、测评前期需求 | 安排社区广告和推流资源 |\n| 品牌运营 → 内容运营 | 品牌推广计划、新品宣发、活动宣发、素材与口径 | 统一品牌内容和社区投放 |\n| 用户运营 → 内容运营 | 用户触达节奏、测评计划、用户反馈、频控要求 | 避免内容触达与用户推送冲突 |\n| 内容运营 → 亚马逊运营/品牌运营 | 广告曝光、点击、打开、跳转、成交、帖子互动、风险数据 | 复盘售前宣发效果和销售辅助效果 |\n| 内容运营 → 数据层/管理层 | APP 广告、推流、互动、风险、成交归因数据 | 管理社区资源效率和内容投流效果 |\n\n## 9. 亚马逊运营与其他部门的数据关系\n\n| 数据流向 | 内容 | 用途 |\n|---|---|---|\n| 亚马逊运营 → APP/用户运营 | 销量、订单、ASIN、产品、国家、站点、成交用户 | 绑定率计算、用户触达、索评 |\n| APP/用户运营 → 亚马逊运营 | 绑定数、绑定率、活跃用户、推送效果、评价结果 | Listing/说明书/官网优化，评价计划调整 |\n| 亚马逊运营 → 评价运营 | 重点产品、推新计划、测评计划、回评目标 | 制定评价数量和评分维护策略 |\n| 评价运营 → 亚马逊运营 | 实际评价数、回评数、评分、差评、ASIN 健康状态 | 判断链接健康度和销售风险 |\n| 客服运营 → 亚马逊运营 | 售后问题、负面反馈、用户投诉、问题类型 | 优化产品、Listing、说明书和售后策略 |\n| 品牌/内容运营 → 亚马逊运营 | 品牌推广、内容曝光、社媒/KOL 数据 | 辅助亚马逊销售转化和新品启动 |\n\n## 10. 已确认问题与业务口径\n\n| 编号 | 已确认口径 | 后续影响 |\n|---|---|---|\n| Q1 | 绑定率 = APP 可识别的绑定了指定玩具的用户数 / 销售数。 | 绑定率看板按产品和 ASIN 计算。 |\n| Q2 | 支持在权限控制下查看明细，明细需要具体到每个 ASIN。 | 需要做 ASIN 级权限和涉密销量明细权限。 |\n| Q3 | S、A 级重要性由公司领导约 2-3 人和亚马逊核心总监确认，由用户运营指定人员维护。 | 产品重要级需要维护入口、确认记录和变更日志。 |\n| Q4 | 推新先用基础规则，后续逐步引入模型。当前 S 级需求最大程度满足，约 50% 流量给核心 S 级产品，其余 A/B 等产品共享约 50% 流量。 | 推新算法一期用规则引擎，二期再考虑模型。 |\n| Q5 | 测评、回评、免评计划需要审批流。亚马逊运营提出计划，亚马逊运营总监审批确认。 | 需要建立计划审批状态、审批人和审批记录。 |\n| Q6 | 4.8 很健康，4.5 健康，4.2 高风险；4.2 时需要加强对未回评用户的回评推送。 | ASIN 健康看板需要按评分阈值报警。 |\n| Q7 | 用户提供订单号时进行关联。APP 有 JOYHUB ID、注册邮箱、基础 IP、设备号、用户行为数据等；订单号可关联用户地址、姓名、用户名等。 | 用户识别需要订单号 + JOYHUB ID 双主标识，并保留辅助识别信息。 |\n| Q8 | 品牌影响力核心从两方面评估：各渠道转化、社媒影响力与调研反馈。 | 品牌看板需要同时支持转化数据和影响力反馈数据。 |\n| Q9 | 通过品牌活动前往亚马逊形成的转化，也归属品牌运营 OKR 结果。 | 销售归因需要支持品牌活动到亚马逊转化。 |\n| Q10 | APP 内社区资源由品牌运营与内容运营协同、内容运营分配；用户推送资源由用户运营管理分配。品牌运营负责将亚马逊和品牌需求与内容运营、用户运营协商解决。 | 资源排期需要区分社区资源和用户推送资源。 |\n| Q11 | 需要逐步根据亚马逊平台算法，把关键词需求、GEO 需求同步到测评计划中，综合销量、重要级、突发事件生成建议计划，再调动 IM、EDM、电话、KOC、KOL 等渠道。 | 后续需要计划生成引擎和多渠道资源调度。 |\n| Q12 | 订单号和 JOYHUB ID 是两个主要标识。订单号包括亚马逊来源和独立站来源。用户注册后必然有 JOYHUB ID，提供订单号后两者关联。 | 修正字段为“订单号”，不再使用 OA 订单号。 |\n| Q13 | 各渠道需要统一控制频率，并统一了解对用户的骚扰程度，避免过于频繁。 | 需要建设跨渠道频控和用户反感度监控。 |\n| Q14 | 注册用户的 JOYHUB ID 和邮箱必然关联；多个邮箱多账号可通过 IP、设备号等做黑名单关联，后台可按单一用户处理。 | 需要账号关联、黑名单和高风险关联用户机制。 |\n| Q15 | JOYCOLLAB 和财务都会参与。原则上 KOC 在 JOYCOLLAB 上的带货数据在网站内处理后同步到大用户后台。 | KOC/KOL/PR 看板需要支持 JOYCOLLAB 同步和财务核算校验。 |\n\n## 11. 进入项目规划前的系统设计问题\n\n当前业务链条已经基本清晰，可以进入项目规划与系统模块拆分。进入 ERP 系统设计前，需要把以下问题作为系统设计约束统一管理。\n\n### 11.1 角色权限\n\n需要明确不同角色的数据可见范围、操作权限和审批权限。\n\n重点问题：\n\n- 谁能查看销售明细？\n- 谁能查看用户邮箱、电话、订单号、地址、姓名等高度涉密字段？\n- 谁能审批、修改、暂停测评计划、回评计划、免评计划？\n- 菲律宾客服能看到哪些用户字段？\n- 内容运营能看到哪些用户行为和成交归因字段？\n\n### 11.2 计划流程状态\n\n测评、回评、免评、推送、内容投流、客服任务都需要统一状态流。\n\n建议基础状态：\n\n- 草稿\n- 待审批\n- 已审批\n- 执行中\n- 暂停\n- 异常\n- 已完成\n- 已复盘\n\n### 11.3 数据来源\n\n需要在系统层面明确每类数据的来源、同步方式、刷新频率和权限等级。\n\n| 数据类型 | 可能来源 |\n|---|---|\n| 亚马逊销量/订单 | 亚马逊运营数据源、导入表、API 或报表 |\n| 独立站订单 | 独立站系统 |\n| APP 绑定 | JOYHUB/APP 用户系统 |\n| 用户资料 | JOYHUB ID、注册邮箱、IP、设备号、用户行为数据 |\n| EDM 数据 | 邮件服务商 |\n| TEL 数据 | 电话系统或客服登记 |\n| JOYCOLLAB 数据 | JOYCOLLAB 网站 |\n| 财务/人事数据 | 财务表、人事表、成本表 |\n| 内容广告数据 | APP 广告位、社区内容系统 |\n\n### 11.4 核心业务对象\n\n后续建系统时，至少需要统一以下核心对象：\n\n- 用户\n- 订单\n- 产品\n- ASIN\n- 品牌\n- 国家/站点\n- 推送计划\n- 测评计划\n- 回评计划\n- 免评计划\n- 内容投流计划\n- 广告位\n- 客服任务\n- 合作伙伴\n- 成本记录\n- 风险用户/黑名单\n\n### 11.5 计划生成规则\n\n推新和测评计划一期建议先采用规则引擎，后续再逐步引入模型。\n\n仍需继续细化：\n\n- S/A/B 级产品资源比例是否固定，还是允许人工调整？\n- 突发事件如何插队？\n- 一个用户多久不能被重复触达？\n- 一个 ASIN 高风险时是否自动提升优先级？\n- GEO 需求如何进入计划生成？\n- 关键词需求如何与用户池匹配？\n\n### 11.6 评价健康报警\n\n评分阈值已经初步明确，但还需要补充数量类和进度类报警。\n\n待细化：\n\n- 回评数低于计划多少算异常？\n- 新品多少天内必须达到多少评价？\n- 差评率达到多少触发客服或用户运营介入？\n- ASIN 评分下降多少需要升级？\n- 评价健康报警是否自动触发回评推送计划？\n\n### 11.7 成本口径\n\n成本口径需要统一，否则无法做真实 ROI 和人效复盘。\n\n待细化：\n\n- 单评成本如何计算？\n- 返现成本是否纳入单评成本？\n- 菲律宾客服人力成本如何分摊到产品、ASIN、计划？\n- KOC/KOL 提成如何归因到订单？\n- 管理成本如何分摊？\n\n### 11.8 归因规则\n\n多渠道触达一定会发生交叉，归因规则需要系统化。\n\n典型场景：\n\n用户先看到 APP 内容广告，再收到 EDM，最后通过亚马逊购买。\n\n待确定：\n\n- 采用首触归因、末触归因、主要贡献渠道，还是多渠道权重归因？\n- 品牌活动到亚马逊成交如何归因？\n- 内容广告和用户推送都参与时如何拆分贡献？\n- KOC/KOL 带货链接与后续 APP 触达如何处理归因冲突？\n\n### 11.9 黑名单与风险用户处理\n\n黑名单与风险用户需要成为系统基础能力。\n\n待细化：\n\n- 谁能加入黑名单？\n- 黑名单是否影响推送、返现、测评资格？\n- 高风险用户是否允许客服继续跟进？\n- 多账号关联后是否自动合并为单一风险用户？\n- 黑名单查询是否支持订单号和 JOYHUB ID 双入口？\n\n### 11.10 一期项目边界建议\n\n一期不宜追求一次性覆盖所有 ERP 能力，应优先建设评价业务闭环的主干。\n\n建议一期优先：\n\n1. 产品/ASIN 看板\n2. 测评计划、回评计划、免评计划审批流\n3. 用户推送计划\n4. ASIN 评价健康看板\n5. 菲律宾客服执行看板\n6. 基础权限与涉密字段控制\n7. 基础数据导入和统一主键\n\n后续二期及以后再逐步扩展模型化计划生成、多渠道归因、复杂成本核算、内容广告优化、JOYCOLLAB 深度集成和管理层经营分析。\n\n## 12. 修改记录\n\n| 版本 | 日期 | 修改内容 | 记录人 |\n|---|---|---|---|\n| v0.7 | 2026-04-26 | 将业务链条确认后的系统设计问题写入文档；补充角色权限、计划状态流、数据来源、核心业务对象、计划生成规则、评价健康报警、成本口径、归因规则、黑名单与风险用户处理和一期项目边界建议。 | Codex |\n| v0.6 | 2026-04-26 | 追加内容运营相关业务；明确内容运营配合亚马逊运营与品牌运营进行销售前期宣发、售前社区广告计划和社区 KOC/KCO 对接；新增 APP 广告管理看板和推流管理看板，覆盖开屏、弹窗、文末、ME、评论末、加权、新帖、固定位置、固定流量池、用户行为、互动与风险字段。 | Codex |\n| v0.5 | 2026-04-26 | 追加菲律宾客服相关业务；明确菲律宾客服直接接受用户运营指导，亚马逊运营短期需求变动通过用户运营转达；新增核心指标客源、转化数、转化率、节约成本；新增人员管理、评价计划管理、成本管理三个看板及字段；补充菲律宾客服与用户运营、亚马逊运营、数据层/管理层的数据关系。 | Codex |\n| v0.4 | 2026-04-26 | 回答并固化 Q1-Q15 业务口径；明确绑定率公式、ASIN 明细权限、产品重要级确认与维护、推新资源规则、测评/回评/免评审批流、ASIN 评价健康阈值、订单号与 JOYHUB ID 双主标识、品牌影响力评估、品牌活动归因、APP 社区与用户推送资源边界、测评计划建议生成方向、跨渠道频控、黑名单关联和 JOYCOLLAB/财务数据来源。 | Codex |\n| v0.3 | 2026-04-26 | 追加用户运营相关业务；明确用户运营为系统核心使用者，客服部门归属用户部门管理；新增测评计划执行、ASIN 评价健康与回评计划、IM 社区消息推送、已成交索评、TEL 电话售后、EDM 邮件推送、KOC/KOL/PR 合作伙伴、其他触达渠道等模块；新增用户运营与其他部门的数据关系和待确认问题。 | Codex |\n| v0.2 | 2026-04-26 | 追加品牌运营相关业务；明确品牌运营与亚马逊运营不在同一办公区但共同建立销售体系；修正品牌推广计划归属为品牌运营主责、亚马逊运营同步；明确 AMZ 测评计划由亚马逊运营提需求、品牌运营协同、用户运营实际实现；新增品牌影响力与独立站销售看板、品牌推广计划协同看板、品牌运营数据关系和待确认问题。 | Codex |\n| v0.1 | 2026-04-26 | 建立评价业务流闭环项目架构文档；整理总体业务闭环、基础指标、亚马逊运营相关业务；新增销量与绑定率看板、推新计划与 APP 推送资源分配看板、测评与免评计划看板、回评计划与 ASIN 评价健康度看板、品牌推广协同数据和待确认问题。 | Codex |\n", + "wikilinks": [], + "category": "layer-requirements" + } + }, + { + "id": "doc:05_需求文档/user_erp_mvp_admin_prototype_v10", + "type": "document", + "name": "USER 后台 ERP MVP · 管理员总览原型 v10", + "filePath": "05_需求文档/user_erp_mvp_admin_prototype_v10.html", + "summary": "USER 后台 ERP MVP · 管理员总览原型 v10 JOYHUB Ops 💬 3 IM 消息 当前模块 经营总览 系统管理员最高权限视图 常用跳转 21 重要事项 3 审核类 4 字段关系 5 问题总结 9 经营总览 系统管理员 · 最高权限 · 全部部门 搜索 至 日 周 月 全部部门 Amazon 运营 用户运营 客服 系统管理员（最高权限） ", + "tags": [ + "05_需求文档", + "需求文档" + ], + "complexity": "complex", + "knowledgeMeta": { + "content": "\n\n\n \n \n USER 后台 ERP MVP · 管理员总览原型 v10\n \n\n\n
\n \n\n
\n
\n
\n
\n 经营总览\n 系统管理员 · 最高权限 · 全部部门\n
\n
\n 搜索\n \n
\n
\n
\n
\n \n 至\n \n
\n
\n \n \n \n
\n \n \n \n
\n
\n\n
\n
\n
\n\n
\n \n\n
\n
\n
\n

操作确认

\n \n
\n
\n
\n
\n\n
\n\n
\n \n\n \n\n\n", + "wikilinks": [], + "category": "layer-requirements" + } + }, + { + "id": "doc:05_需求文档/user_erp_mvp_admin_prototype_v10(1)", + "type": "document", + "name": "USER 后台 ERP MVP · 管理员总览原型 v10", + "filePath": "05_需求文档/user_erp_mvp_admin_prototype_v10(1).html", + "summary": "USER 后台 ERP MVP · 管理员总览原型 v10 JOYHUB Ops 模拟数据 第一期模拟 数据 当前模块 经营总览 系统管理员最高权限视图 常用跳转 21 重要事项 3 审核类 4 字段关系 5 问题总结 9 经营总览 系统管理员 · 最高权限 · 全部部门 搜索 至 日 周 月 全部部门 Amazon 运营 用户运营 客服 系统管理员（最高权", + "tags": [ + "05_需求文档", + "需求文档" + ], + "complexity": "complex", + "knowledgeMeta": { + "content": "\n\n\n \n \n USER 后台 ERP MVP · 管理员总览原型 v10\n \n\n\n
\n \n\n
\n
\n
\n
\n 经营总览\n 系统管理员 · 最高权限 · 全部部门\n
\n
\n 搜索\n \n
\n
\n
\n
\n \n 至\n \n
\n
\n \n \n \n
\n \n \n \n
\n
\n\n
\n
\n
\n\n
\n \n\n
\n
\n
\n

操作确认

\n \n
\n
\n
\n
\n\n
\n\n \n\n\n", + "wikilinks": [], + "category": "layer-requirements" + } + } + ], + "edges": [ + { + "source": "flow:layer-overview", + "target": "flow:layer-requirements", + "type": "documents", + "direction": "forward", + "description": "知识库主流程", + "weight": 1 + }, + { + "source": "flow:layer-requirements", + "target": "flow:layer-milestones", + "type": "documents", + "direction": "forward", + "description": "知识库主流程", + "weight": 1 + }, + { + "source": "flow:layer-milestones", + "target": "flow:layer-technical", + "type": "documents", + "direction": "forward", + "description": "知识库主流程", + "weight": 1 + }, + { + "source": "flow:layer-technical", + "target": "flow:layer-testing", + "type": "documents", + "direction": "forward", + "description": "知识库主流程", + "weight": 1 + }, + { + "source": "flow:layer-testing", + "target": "flow:layer-agent", + "type": "documents", + "direction": "forward", + "description": "知识库主流程", + "weight": 1 + }, + { + "source": "flow:layer-overview", + "target": "doc:00_首页/Agent问答入口", + "type": "documents", + "direction": "forward", + "description": "本层文档", + "weight": 0.65 + }, + { + "source": "flow:layer-overview", + "target": "doc:00_首页/知识地图", + "type": "documents", + "direction": "forward", + "description": "本层文档", + "weight": 0.65 + }, + { + "source": "flow:layer-overview", + "target": "doc:00_首页/知识库首页", + "type": "documents", + "direction": "forward", + "description": "本层文档", + "weight": 0.65 + }, + { + "source": "flow:layer-overview", + "target": "doc:欢迎", + "type": "documents", + "direction": "forward", + "description": "本层文档", + "weight": 0.65 + }, + { + "source": "flow:layer-overview", + "target": "doc:知识库使用说明", + "type": "documents", + "direction": "forward", + "description": "本层文档", + "weight": 0.65 + }, + { + "source": "flow:layer-requirements", + "target": "doc:05_需求文档/20260517_USER评价业务闭环_第三步_数据流与中间对象设计_v3", + "type": "documents", + "direction": "forward", + "description": "本层文档", + "weight": 0.65 + }, + { + "source": "flow:layer-requirements", + "target": "doc:05_需求文档/README", + "type": "documents", + "direction": "forward", + "description": "本层文档", + "weight": 0.65 + }, + { + "source": "flow:layer-requirements", + "target": "doc:05_需求文档/需求文档索引", + "type": "documents", + "direction": "forward", + "description": "本层文档", + "weight": 0.65 + }, + { + "source": "flow:layer-milestones", + "target": "doc:02_项目管理流程/AI驱动内部系统开发流程_V3_总览", + "type": "documents", + "direction": "forward", + "description": "本层文档", + "weight": 0.65 + }, + { + "source": "flow:layer-milestones", + "target": "doc:02_项目管理流程/README", + "type": "documents", + "direction": "forward", + "description": "本层文档", + "weight": 0.65 + }, + { + "source": "flow:layer-milestones", + "target": "doc:02_项目管理流程/常见问题FAQ", + "type": "documents", + "direction": "forward", + "description": "本层文档", + "weight": 0.65 + }, + { + "source": "flow:layer-milestones", + "target": "doc:02_项目管理流程/角色职责矩阵", + "type": "documents", + "direction": "forward", + "description": "本层文档", + "weight": 0.65 + }, + { + "source": "flow:layer-milestones", + "target": "doc:02_项目管理流程/阶段0_项目入口分级", + "type": "documents", + "direction": "forward", + "description": "本层文档", + "weight": 0.65 + }, + { + "source": "flow:layer-milestones", + "target": "doc:02_项目管理流程/阶段1_业务需求完整形成", + "type": "documents", + "direction": "forward", + "description": "本层文档", + "weight": 0.65 + }, + { + "source": "flow:layer-milestones", + "target": "doc:02_项目管理流程/阶段2.5_测试提前补漏", + "type": "documents", + "direction": "forward", + "description": "本层文档", + "weight": 0.65 + }, + { + "source": "flow:layer-milestones", + "target": "doc:02_项目管理流程/阶段2_高保真模型与业务对象确认", + "type": "documents", + "direction": "forward", + "description": "本层文档", + "weight": 0.65 + }, + { + "source": "flow:layer-milestones", + "target": "doc:02_项目管理流程/阶段3_研发协作与正式开发", + "type": "documents", + "direction": "forward", + "description": "本层文档", + "weight": 0.65 + }, + { + "source": "flow:layer-milestones", + "target": "doc:02_项目管理流程/阶段4_测试培训上线回流", + "type": "documents", + "direction": "forward", + "description": "本层文档", + "weight": 0.65 + }, + { + "source": "flow:layer-milestones", + "target": "doc:02_项目管理流程/阶段交付物清单", + "type": "documents", + "direction": "forward", + "description": "本层文档", + "weight": 0.65 + }, + { + "source": "flow:layer-milestones", + "target": "doc:02_项目管理流程/项目检查清单", + "type": "documents", + "direction": "forward", + "description": "本层文档", + "weight": 0.65 + }, + { + "source": "flow:layer-milestones", + "target": "doc:06_里程碑/README", + "type": "documents", + "direction": "forward", + "description": "本层文档", + "weight": 0.65 + }, + { + "source": "flow:layer-milestones", + "target": "doc:06_里程碑/里程碑索引", + "type": "documents", + "direction": "forward", + "description": "本层文档", + "weight": 0.65 + }, + { + "source": "flow:layer-milestones", + "target": "doc:06_里程碑/里程碑评审记录", + "type": "documents", + "direction": "forward", + "description": "本层文档", + "weight": 0.65 + }, + { + "source": "flow:layer-milestones", + "target": "doc:06_里程碑/阶段计划模板", + "type": "documents", + "direction": "forward", + "description": "本层文档", + "weight": 0.65 + }, + { + "source": "flow:layer-technical", + "target": "doc:07_技术文档/README", + "type": "documents", + "direction": "forward", + "description": "本层文档", + "weight": 0.65 + }, + { + "source": "flow:layer-technical", + "target": "doc:07_技术文档/技术决策记录", + "type": "documents", + "direction": "forward", + "description": "本层文档", + "weight": 0.65 + }, + { + "source": "flow:layer-technical", + "target": "doc:07_技术文档/技术文档索引", + "type": "documents", + "direction": "forward", + "description": "本层文档", + "weight": 0.65 + }, + { + "source": "flow:layer-technical", + "target": "doc:07_技术文档/接口说明模板", + "type": "documents", + "direction": "forward", + "description": "本层文档", + "weight": 0.65 + }, + { + "source": "flow:layer-technical", + "target": "doc:07_技术文档/系统架构说明模板", + "type": "documents", + "direction": "forward", + "description": "本层文档", + "weight": 0.65 + }, + { + "source": "flow:layer-testing", + "target": "doc:08_测试相关/README", + "type": "documents", + "direction": "forward", + "description": "本层文档", + "weight": 0.65 + }, + { + "source": "flow:layer-testing", + "target": "doc:08_测试相关/上线检查模板", + "type": "documents", + "direction": "forward", + "description": "本层文档", + "weight": 0.65 + }, + { + "source": "flow:layer-testing", + "target": "doc:08_测试相关/测试用例模板", + "type": "documents", + "direction": "forward", + "description": "本层文档", + "weight": 0.65 + }, + { + "source": "flow:layer-testing", + "target": "doc:08_测试相关/测试用例索引", + "type": "documents", + "direction": "forward", + "description": "本层文档", + "weight": 0.65 + }, + { + "source": "flow:layer-testing", + "target": "doc:08_测试相关/测试计划模板", + "type": "documents", + "direction": "forward", + "description": "本层文档", + "weight": 0.65 + }, + { + "source": "flow:layer-testing", + "target": "doc:08_测试相关/缺陷记录模板", + "type": "documents", + "direction": "forward", + "description": "本层文档", + "weight": 0.65 + }, + { + "source": "flow:layer-testing", + "target": "doc:08_测试相关/验收记录模板", + "type": "documents", + "direction": "forward", + "description": "本层文档", + "weight": 0.65 + }, + { + "source": "flow:layer-agent", + "target": "doc:04_Agent检索/关键词索引", + "type": "documents", + "direction": "forward", + "description": "本层文档", + "weight": 0.65 + }, + { + "source": "flow:layer-agent", + "target": "doc:04_Agent检索/同义词表", + "type": "documents", + "direction": "forward", + "description": "本层文档", + "weight": 0.65 + }, + { + "source": "flow:layer-agent", + "target": "doc:04_Agent检索/来源文件索引", + "type": "documents", + "direction": "forward", + "description": "本层文档", + "weight": 0.65 + }, + { + "source": "flow:layer-agent", + "target": "doc:04_Agent检索/检索说明", + "type": "documents", + "direction": "forward", + "description": "本层文档", + "weight": 0.65 + }, + { + "source": "flow:layer-agent", + "target": "doc:04_Agent检索/知识库持续更新与验证流程", + "type": "documents", + "direction": "forward", + "description": "本层文档", + "weight": 0.65 + }, + { + "source": "flow:layer-agent", + "target": "doc:04_Agent检索/问答提示词", + "type": "documents", + "direction": "forward", + "description": "本层文档", + "weight": 0.65 + }, + { + "source": "doc:04_Agent检索/知识库持续更新与验证流程", + "target": "doc:00_首页/Agent问答入口", + "type": "depends_on", + "direction": "forward", + "description": "文档引用关系", + "weight": 0.7 + }, + { + "source": "doc:05_需求文档/需求文档索引", + "target": "doc:00_首页/Agent问答入口", + "type": "depends_on", + "direction": "forward", + "description": "文档引用关系", + "weight": 0.7 + }, + { + "source": "doc:08_测试相关/测试用例索引", + "target": "doc:00_首页/Agent问答入口", + "type": "depends_on", + "direction": "forward", + "description": "文档引用关系", + "weight": 0.7 + }, + { + "source": "doc:02_项目管理流程/AI驱动内部系统开发流程_V3_总览", + "target": "doc:04_Agent检索/关键词索引", + "type": "depends_on", + "direction": "forward", + "description": "文档引用关系", + "weight": 0.7 + }, + { + "source": "doc:02_项目管理流程/角色职责矩阵", + "target": "doc:04_Agent检索/关键词索引", + "type": "depends_on", + "direction": "forward", + "description": "文档引用关系", + "weight": 0.7 + }, + { + "source": "doc:02_项目管理流程/阶段0_项目入口分级", + "target": "doc:04_Agent检索/关键词索引", + "type": "depends_on", + "direction": "forward", + "description": "文档引用关系", + "weight": 0.7 + }, + { + "source": "doc:02_项目管理流程/阶段1_业务需求完整形成", + "target": "doc:04_Agent检索/关键词索引", + "type": "depends_on", + "direction": "forward", + "description": "文档引用关系", + "weight": 0.7 + }, + { + "source": "doc:02_项目管理流程/阶段2.5_测试提前补漏", + "target": "doc:04_Agent检索/关键词索引", + "type": "depends_on", + "direction": "forward", + "description": "文档引用关系", + "weight": 0.7 + }, + { + "source": "doc:02_项目管理流程/阶段2_高保真模型与业务对象确认", + "target": "doc:04_Agent检索/关键词索引", + "type": "depends_on", + "direction": "forward", + "description": "文档引用关系", + "weight": 0.7 + }, + { + "source": "doc:02_项目管理流程/阶段3_研发协作与正式开发", + "target": "doc:04_Agent检索/关键词索引", + "type": "depends_on", + "direction": "forward", + "description": "文档引用关系", + "weight": 0.7 + }, + { + "source": "doc:02_项目管理流程/阶段4_测试培训上线回流", + "target": "doc:04_Agent检索/关键词索引", + "type": "depends_on", + "direction": "forward", + "description": "文档引用关系", + "weight": 0.7 + }, + { + "source": "doc:02_项目管理流程/阶段交付物清单", + "target": "doc:04_Agent检索/关键词索引", + "type": "depends_on", + "direction": "forward", + "description": "文档引用关系", + "weight": 0.7 + }, + { + "source": "doc:02_项目管理流程/项目检查清单", + "target": "doc:04_Agent检索/关键词索引", + "type": "depends_on", + "direction": "forward", + "description": "文档引用关系", + "weight": 0.7 + }, + { + "source": "doc:04_Agent检索/知识库持续更新与验证流程", + "target": "doc:04_Agent检索/关键词索引", + "type": "depends_on", + "direction": "forward", + "description": "文档引用关系", + "weight": 0.7 + }, + { + "source": "doc:02_项目管理流程/角色职责矩阵", + "target": "doc:04_Agent检索/同义词表", + "type": "depends_on", + "direction": "forward", + "description": "文档引用关系", + "weight": 0.7 + }, + { + "source": "doc:02_项目管理流程/阶段0_项目入口分级", + "target": "doc:04_Agent检索/同义词表", + "type": "depends_on", + "direction": "forward", + "description": "文档引用关系", + "weight": 0.7 + }, + { + "source": "doc:02_项目管理流程/阶段1_业务需求完整形成", + "target": "doc:04_Agent检索/同义词表", + "type": "depends_on", + "direction": "forward", + "description": "文档引用关系", + "weight": 0.7 + }, + { + "source": "doc:02_项目管理流程/阶段2.5_测试提前补漏", + "target": "doc:04_Agent检索/同义词表", + "type": "depends_on", + "direction": "forward", + "description": "文档引用关系", + "weight": 0.7 + }, + { + "source": "doc:02_项目管理流程/阶段2_高保真模型与业务对象确认", + "target": "doc:04_Agent检索/同义词表", + "type": "depends_on", + "direction": "forward", + "description": "文档引用关系", + "weight": 0.7 + }, + { + "source": "doc:02_项目管理流程/阶段3_研发协作与正式开发", + "target": "doc:04_Agent检索/同义词表", + "type": "depends_on", + "direction": "forward", + "description": "文档引用关系", + "weight": 0.7 + }, + { + "source": "doc:02_项目管理流程/阶段4_测试培训上线回流", + "target": "doc:04_Agent检索/同义词表", + "type": "depends_on", + "direction": "forward", + "description": "文档引用关系", + "weight": 0.7 + }, + { + "source": "doc:02_项目管理流程/阶段交付物清单", + "target": "doc:04_Agent检索/同义词表", + "type": "depends_on", + "direction": "forward", + "description": "文档引用关系", + "weight": 0.7 + }, + { + "source": "doc:02_项目管理流程/项目检查清单", + "target": "doc:04_Agent检索/同义词表", + "type": "depends_on", + "direction": "forward", + "description": "文档引用关系", + "weight": 0.7 + }, + { + "source": "doc:04_Agent检索/知识库持续更新与验证流程", + "target": "doc:04_Agent检索/同义词表", + "type": "depends_on", + "direction": "forward", + "description": "文档引用关系", + "weight": 0.7 + }, + { + "source": "doc:02_项目管理流程/AI驱动内部系统开发流程_V3_总览", + "target": "doc:04_Agent检索/来源文件索引", + "type": "depends_on", + "direction": "forward", + "description": "文档引用关系", + "weight": 0.7 + }, + { + "source": "doc:02_项目管理流程/常见问题FAQ", + "target": "doc:04_Agent检索/来源文件索引", + "type": "depends_on", + "direction": "forward", + "description": "文档引用关系", + "weight": 0.7 + }, + { + "source": "doc:02_项目管理流程/角色职责矩阵", + "target": "doc:04_Agent检索/来源文件索引", + "type": "depends_on", + "direction": "forward", + "description": "文档引用关系", + "weight": 0.7 + }, + { + "source": "doc:02_项目管理流程/阶段0_项目入口分级", + "target": "doc:04_Agent检索/来源文件索引", + "type": "depends_on", + "direction": "forward", + "description": "文档引用关系", + "weight": 0.7 + }, + { + "source": "doc:02_项目管理流程/阶段1_业务需求完整形成", + "target": "doc:04_Agent检索/来源文件索引", + "type": "depends_on", + "direction": "forward", + "description": "文档引用关系", + "weight": 0.7 + }, + { + "source": "doc:02_项目管理流程/阶段2.5_测试提前补漏", + "target": "doc:04_Agent检索/来源文件索引", + "type": "depends_on", + "direction": "forward", + "description": "文档引用关系", + "weight": 0.7 + }, + { + "source": "doc:02_项目管理流程/阶段2_高保真模型与业务对象确认", + "target": "doc:04_Agent检索/来源文件索引", + "type": "depends_on", + "direction": "forward", + "description": "文档引用关系", + "weight": 0.7 + }, + { + "source": "doc:02_项目管理流程/阶段3_研发协作与正式开发", + "target": "doc:04_Agent检索/来源文件索引", + "type": "depends_on", + "direction": "forward", + "description": "文档引用关系", + "weight": 0.7 + }, + { + "source": "doc:02_项目管理流程/阶段4_测试培训上线回流", + "target": "doc:04_Agent检索/来源文件索引", + "type": "depends_on", + "direction": "forward", + "description": "文档引用关系", + "weight": 0.7 + }, + { + "source": "doc:02_项目管理流程/阶段交付物清单", + "target": "doc:04_Agent检索/来源文件索引", + "type": "depends_on", + "direction": "forward", + "description": "文档引用关系", + "weight": 0.7 + }, + { + "source": "doc:02_项目管理流程/项目检查清单", + "target": "doc:04_Agent检索/来源文件索引", + "type": "depends_on", + "direction": "forward", + "description": "文档引用关系", + "weight": 0.7 + }, + { + "source": "doc:04_Agent检索/知识库持续更新与验证流程", + "target": "doc:04_Agent检索/来源文件索引", + "type": "depends_on", + "direction": "forward", + "description": "文档引用关系", + "weight": 0.7 + }, + { + "source": "doc:05_需求文档/需求文档索引", + "target": "doc:04_Agent检索/来源文件索引", + "type": "depends_on", + "direction": "forward", + "description": "文档引用关系", + "weight": 0.7 + }, + { + "source": "doc:02_项目管理流程/AI驱动内部系统开发流程_V3_总览", + "target": "doc:04_Agent检索/检索说明", + "type": "depends_on", + "direction": "forward", + "description": "文档引用关系", + "weight": 0.7 + }, + { + "source": "doc:02_项目管理流程/常见问题FAQ", + "target": "doc:04_Agent检索/检索说明", + "type": "depends_on", + "direction": "forward", + "description": "文档引用关系", + "weight": 0.7 + }, + { + "source": "doc:02_项目管理流程/角色职责矩阵", + "target": "doc:04_Agent检索/检索说明", + "type": "depends_on", + "direction": "forward", + "description": "文档引用关系", + "weight": 0.7 + }, + { + "source": "doc:02_项目管理流程/阶段2.5_测试提前补漏", + "target": "doc:04_Agent检索/检索说明", + "type": "depends_on", + "direction": "forward", + "description": "文档引用关系", + "weight": 0.7 + }, + { + "source": "doc:02_项目管理流程/阶段2_高保真模型与业务对象确认", + "target": "doc:04_Agent检索/检索说明", + "type": "depends_on", + "direction": "forward", + "description": "文档引用关系", + "weight": 0.7 + }, + { + "source": "doc:02_项目管理流程/阶段交付物清单", + "target": "doc:04_Agent检索/检索说明", + "type": "depends_on", + "direction": "forward", + "description": "文档引用关系", + "weight": 0.7 + }, + { + "source": "doc:02_项目管理流程/项目检查清单", + "target": "doc:04_Agent检索/检索说明", + "type": "depends_on", + "direction": "forward", + "description": "文档引用关系", + "weight": 0.7 + }, + { + "source": "doc:04_Agent检索/关键词索引", + "target": "doc:04_Agent检索/检索说明", + "type": "depends_on", + "direction": "forward", + "description": "文档引用关系", + "weight": 0.7 + }, + { + "source": "doc:04_Agent检索/同义词表", + "target": "doc:04_Agent检索/检索说明", + "type": "depends_on", + "direction": "forward", + "description": "文档引用关系", + "weight": 0.7 + }, + { + "source": "doc:05_需求文档/需求文档索引", + "target": "doc:04_Agent检索/检索说明", + "type": "depends_on", + "direction": "forward", + "description": "文档引用关系", + "weight": 0.7 + }, + { + "source": "doc:06_里程碑/里程碑索引", + "target": "doc:04_Agent检索/检索说明", + "type": "depends_on", + "direction": "forward", + "description": "文档引用关系", + "weight": 0.7 + }, + { + "source": "doc:07_技术文档/技术文档索引", + "target": "doc:04_Agent检索/检索说明", + "type": "depends_on", + "direction": "forward", + "description": "文档引用关系", + "weight": 0.7 + }, + { + "source": "doc:07_技术文档/接口说明模板", + "target": "doc:04_Agent检索/检索说明", + "type": "depends_on", + "direction": "forward", + "description": "文档引用关系", + "weight": 0.7 + }, + { + "source": "doc:08_测试相关/上线检查模板", + "target": "doc:04_Agent检索/检索说明", + "type": "depends_on", + "direction": "forward", + "description": "文档引用关系", + "weight": 0.7 + }, + { + "source": "doc:08_测试相关/测试用例索引", + "target": "doc:04_Agent检索/检索说明", + "type": "depends_on", + "direction": "forward", + "description": "文档引用关系", + "weight": 0.7 + }, + { + "source": "doc:08_测试相关/缺陷记录模板", + "target": "doc:04_Agent检索/检索说明", + "type": "depends_on", + "direction": "forward", + "description": "文档引用关系", + "weight": 0.7 + }, + { + "source": "doc:08_测试相关/验收记录模板", + "target": "doc:04_Agent检索/检索说明", + "type": "depends_on", + "direction": "forward", + "description": "文档引用关系", + "weight": 0.7 + }, + { + "source": "doc:04_Agent检索/关键词索引", + "target": "doc:04_Agent检索/知识库持续更新与验证流程", + "type": "depends_on", + "direction": "forward", + "description": "文档引用关系", + "weight": 0.7 + }, + { + "source": "doc:04_Agent检索/同义词表", + "target": "doc:04_Agent检索/知识库持续更新与验证流程", + "type": "depends_on", + "direction": "forward", + "description": "文档引用关系", + "weight": 0.7 + }, + { + "source": "doc:04_Agent检索/来源文件索引", + "target": "doc:04_Agent检索/知识库持续更新与验证流程", + "type": "depends_on", + "direction": "forward", + "description": "文档引用关系", + "weight": 0.7 + }, + { + "source": "doc:05_需求文档/需求文档索引", + "target": "doc:04_Agent检索/知识库持续更新与验证流程", + "type": "depends_on", + "direction": "forward", + "description": "文档引用关系", + "weight": 0.7 + }, + { + "source": "doc:02_项目管理流程/角色职责矩阵", + "target": "doc:04_Agent检索/问答提示词", + "type": "depends_on", + "direction": "forward", + "description": "文档引用关系", + "weight": 0.7 + }, + { + "source": "doc:02_项目管理流程/阶段交付物清单", + "target": "doc:04_Agent检索/问答提示词", + "type": "depends_on", + "direction": "forward", + "description": "文档引用关系", + "weight": 0.7 + }, + { + "source": "doc:02_项目管理流程/项目检查清单", + "target": "doc:04_Agent检索/问答提示词", + "type": "depends_on", + "direction": "forward", + "description": "文档引用关系", + "weight": 0.7 + }, + { + "source": "doc:04_Agent检索/关键词索引", + "target": "doc:05_需求文档/README", + "type": "depends_on", + "direction": "forward", + "description": "文档引用关系", + "weight": 0.7 + }, + { + "source": "doc:04_Agent检索/同义词表", + "target": "doc:05_需求文档/README", + "type": "depends_on", + "direction": "forward", + "description": "文档引用关系", + "weight": 0.7 + }, + { + "source": "doc:04_Agent检索/来源文件索引", + "target": "doc:05_需求文档/README", + "type": "depends_on", + "direction": "forward", + "description": "文档引用关系", + "weight": 0.7 + }, + { + "source": "doc:04_Agent检索/知识库持续更新与验证流程", + "target": "doc:05_需求文档/README", + "type": "depends_on", + "direction": "forward", + "description": "文档引用关系", + "weight": 0.7 + }, + { + "source": "doc:05_需求文档/需求文档索引", + "target": "doc:05_需求文档/README", + "type": "depends_on", + "direction": "forward", + "description": "文档引用关系", + "weight": 0.7 + }, + { + "source": "doc:00_首页/知识地图", + "target": "doc:知识库使用说明", + "type": "depends_on", + "direction": "forward", + "description": "文档引用关系", + "weight": 0.7 + }, + { + "source": "doc:02_项目管理流程/README", + "target": "doc:知识库使用说明", + "type": "depends_on", + "direction": "forward", + "description": "文档引用关系", + "weight": 0.7 + }, + { + "source": "doc:02_项目管理流程/阶段交付物清单", + "target": "doc:知识库使用说明", + "type": "depends_on", + "direction": "forward", + "description": "文档引用关系", + "weight": 0.7 + }, + { + "source": "doc:02_项目管理流程/项目检查清单", + "target": "doc:知识库使用说明", + "type": "depends_on", + "direction": "forward", + "description": "文档引用关系", + "weight": 0.7 + }, + { + "source": "doc:04_Agent检索/来源文件索引", + "target": "doc:知识库使用说明", + "type": "depends_on", + "direction": "forward", + "description": "文档引用关系", + "weight": 0.7 + }, + { + "source": "doc:04_Agent检索/检索说明", + "target": "doc:知识库使用说明", + "type": "depends_on", + "direction": "forward", + "description": "文档引用关系", + "weight": 0.7 + }, + { + "source": "doc:05_需求文档/README", + "target": "doc:知识库使用说明", + "type": "depends_on", + "direction": "forward", + "description": "文档引用关系", + "weight": 0.7 + }, + { + "source": "doc:05_需求文档/需求文档索引", + "target": "doc:知识库使用说明", + "type": "depends_on", + "direction": "forward", + "description": "文档引用关系", + "weight": 0.7 + }, + { + "source": "doc:06_里程碑/README", + "target": "doc:知识库使用说明", + "type": "depends_on", + "direction": "forward", + "description": "文档引用关系", + "weight": 0.7 + }, + { + "source": "doc:06_里程碑/里程碑索引", + "target": "doc:知识库使用说明", + "type": "depends_on", + "direction": "forward", + "description": "文档引用关系", + "weight": 0.7 + }, + { + "source": "doc:07_技术文档/README", + "target": "doc:知识库使用说明", + "type": "depends_on", + "direction": "forward", + "description": "文档引用关系", + "weight": 0.7 + }, + { + "source": "doc:07_技术文档/技术文档索引", + "target": "doc:知识库使用说明", + "type": "depends_on", + "direction": "forward", + "description": "文档引用关系", + "weight": 0.7 + }, + { + "source": "doc:08_测试相关/README", + "target": "doc:知识库使用说明", + "type": "depends_on", + "direction": "forward", + "description": "文档引用关系", + "weight": 0.7 + }, + { + "source": "doc:08_测试相关/上线检查模板", + "target": "doc:知识库使用说明", + "type": "depends_on", + "direction": "forward", + "description": "文档引用关系", + "weight": 0.7 + }, + { + "source": "doc:08_测试相关/测试用例索引", + "target": "doc:知识库使用说明", + "type": "depends_on", + "direction": "forward", + "description": "文档引用关系", + "weight": 0.7 + }, + { + "source": "doc:08_测试相关/缺陷记录模板", + "target": "doc:知识库使用说明", + "type": "depends_on", + "direction": "forward", + "description": "文档引用关系", + "weight": 0.7 + }, + { + "source": "doc:欢迎", + "target": "doc:知识库使用说明", + "type": "depends_on", + "direction": "forward", + "description": "文档引用关系", + "weight": 0.7 + }, + { + "source": "flow:layer-requirements", + "target": "doc:05_需求文档/00-系统总览", + "type": "documents", + "direction": "forward", + "description": "本层文档", + "weight": 0.65 + }, + { + "source": "flow:layer-requirements", + "target": "doc:05_需求文档/01-子系统-用户身份与上下文", + "type": "documents", + "direction": "forward", + "description": "本层文档", + "weight": 0.65 + }, + { + "source": "flow:layer-requirements", + "target": "doc:05_需求文档/02-子系统-需求与计划管理", + "type": "documents", + "direction": "forward", + "description": "本层文档", + "weight": 0.65 + }, + { + "source": "flow:layer-requirements", + "target": "doc:05_需求文档/03-子系统-额度与频控", + "type": "documents", + "direction": "forward", + "description": "本层文档", + "weight": 0.65 + }, + { + "source": "flow:layer-requirements", + "target": "doc:05_需求文档/04-子系统-多渠道触达引擎", + "type": "documents", + "direction": "forward", + "description": "本层文档", + "weight": 0.65 + }, + { + "source": "flow:layer-requirements", + "target": "doc:05_需求文档/05-子系统-客服工单与管理", + "type": "documents", + "direction": "forward", + "description": "本层文档", + "weight": 0.65 + }, + { + "source": "flow:layer-requirements", + "target": "doc:05_需求文档/06-子系统-风险与反欺诈", + "type": "documents", + "direction": "forward", + "description": "本层文档", + "weight": 0.65 + }, + { + "source": "flow:layer-requirements", + "target": "doc:05_需求文档/07-子系统-评价结果追踪", + "type": "documents", + "direction": "forward", + "description": "本层文档", + "weight": 0.65 + }, + { + "source": "flow:layer-requirements", + "target": "doc:05_需求文档/08-子系统-KOC-KOL协作", + "type": "documents", + "direction": "forward", + "description": "本层文档", + "weight": 0.65 + }, + { + "source": "flow:layer-requirements", + "target": "doc:05_需求文档/09-子系统-审计与通知中心", + "type": "documents", + "direction": "forward", + "description": "本层文档", + "weight": 0.65 + }, + { + "source": "flow:layer-requirements", + "target": "doc:05_需求文档/20260504_USER后台ERP_MVP管理员首页高保真原型_v7", + "type": "documents", + "direction": "forward", + "description": "本层文档", + "weight": 0.65 + }, + { + "source": "flow:layer-requirements", + "target": "doc:05_需求文档/20260517_USER评价业务闭环_共用能力图与渠道专属流程_v2.2", + "type": "documents", + "direction": "forward", + "description": "本层文档", + "weight": 0.65 + }, + { + "source": "flow:layer-requirements", + "target": "doc:05_需求文档/20260517_USER评价业务闭环主流程与后续工作基线_v1.2", + "type": "documents", + "direction": "forward", + "description": "本层文档", + "weight": 0.65 + }, + { + "source": "flow:layer-requirements", + "target": "doc:05_需求文档/客服执行", + "type": "documents", + "direction": "forward", + "description": "本层文档", + "weight": 0.65 + }, + { + "source": "flow:layer-requirements", + "target": "doc:05_需求文档/用户运营系统-单文件", + "type": "documents", + "direction": "forward", + "description": "本层文档", + "weight": 0.65 + }, + { + "source": "flow:layer-requirements", + "target": "doc:05_需求文档/evaluation-business-architecture", + "type": "documents", + "direction": "forward", + "description": "本层文档", + "weight": 0.65 + }, + { + "source": "flow:layer-requirements", + "target": "doc:05_需求文档/user_erp_mvp_admin_prototype_v10", + "type": "documents", + "direction": "forward", + "description": "本层文档", + "weight": 0.65 + }, + { + "source": "flow:layer-requirements", + "target": "doc:05_需求文档/user_erp_mvp_admin_prototype_v10(1)", + "type": "documents", + "direction": "forward", + "description": "本层文档", + "weight": 0.65 + } + ], + "layers": [ + { + "id": "layer-overview", + "name": "知识库入口", + "description": "知识库使用说明、首页、知识地图和问答入口。先从这里理解知识库结构与检索方式。", + "nodeIds": [ + "flow:layer-overview", + "doc:00_首页/Agent问答入口", + "doc:00_首页/知识地图", + "doc:00_首页/知识库首页", + "doc:欢迎", + "doc:知识库使用说明" + ] + }, + { + "id": "layer-requirements", + "name": "需求文档", + "description": "所有正式需求、业务规则、需求变更和需求索引。点击本层可查看全部需求文档并检索。", + "nodeIds": [ + "flow:layer-requirements", + "doc:05_需求文档/20260517_USER评价业务闭环_第三步_数据流与中间对象设计_v3", + "doc:05_需求文档/README", + "doc:05_需求文档/需求文档索引", + "doc:05_需求文档/00-系统总览", + "doc:05_需求文档/01-子系统-用户身份与上下文", + "doc:05_需求文档/02-子系统-需求与计划管理", + "doc:05_需求文档/03-子系统-额度与频控", + "doc:05_需求文档/04-子系统-多渠道触达引擎", + "doc:05_需求文档/05-子系统-客服工单与管理", + "doc:05_需求文档/06-子系统-风险与反欺诈", + "doc:05_需求文档/07-子系统-评价结果追踪", + "doc:05_需求文档/08-子系统-KOC-KOL协作", + "doc:05_需求文档/09-子系统-审计与通知中心", + "doc:05_需求文档/20260504_USER后台ERP_MVP管理员首页高保真原型_v7", + "doc:05_需求文档/20260517_USER评价业务闭环_共用能力图与渠道专属流程_v2.2", + "doc:05_需求文档/20260517_USER评价业务闭环主流程与后续工作基线_v1.2", + "doc:05_需求文档/客服执行", + "doc:05_需求文档/用户运营系统-单文件", + "doc:05_需求文档/evaluation-business-architecture", + "doc:05_需求文档/user_erp_mvp_admin_prototype_v10", + "doc:05_需求文档/user_erp_mvp_admin_prototype_v10(1)" + ] + }, + { + "id": "layer-milestones", + "name": "里程碑", + "description": "项目阶段计划、里程碑节点、评审记录、准入准出和交付物节奏。", + "nodeIds": [ + "flow:layer-milestones", + "doc:02_项目管理流程/AI驱动内部系统开发流程_V3_总览", + "doc:02_项目管理流程/README", + "doc:02_项目管理流程/常见问题FAQ", + "doc:02_项目管理流程/角色职责矩阵", + "doc:02_项目管理流程/阶段0_项目入口分级", + "doc:02_项目管理流程/阶段1_业务需求完整形成", + "doc:02_项目管理流程/阶段2.5_测试提前补漏", + "doc:02_项目管理流程/阶段2_高保真模型与业务对象确认", + "doc:02_项目管理流程/阶段3_研发协作与正式开发", + "doc:02_项目管理流程/阶段4_测试培训上线回流", + "doc:02_项目管理流程/阶段交付物清单", + "doc:02_项目管理流程/项目检查清单", + "doc:06_里程碑/README", + "doc:06_里程碑/里程碑索引", + "doc:06_里程碑/里程碑评审记录", + "doc:06_里程碑/阶段计划模板" + ] + }, + { + "id": "layer-technical", + "name": "技术文档", + "description": "系统架构、数据模型、接口说明、技术方案和技术决策。", + "nodeIds": [ + "flow:layer-technical", + "doc:07_技术文档/README", + "doc:07_技术文档/技术决策记录", + "doc:07_技术文档/技术文档索引", + "doc:07_技术文档/接口说明模板", + "doc:07_技术文档/系统架构说明模板" + ] + }, + { + "id": "layer-testing", + "name": "测试相关", + "description": "测试计划、测试用例、缺陷记录、验收记录和上线检查。", + "nodeIds": [ + "flow:layer-testing", + "doc:08_测试相关/README", + "doc:08_测试相关/上线检查模板", + "doc:08_测试相关/测试用例模板", + "doc:08_测试相关/测试用例索引", + "doc:08_测试相关/测试计划模板", + "doc:08_测试相关/缺陷记录模板", + "doc:08_测试相关/验收记录模板" + ] + }, + { + "id": "layer-agent", + "name": "Agent检索", + "description": "检索说明、关键词、同义词、来源索引和持续更新验证流程。", + "nodeIds": [ + "flow:layer-agent", + "doc:04_Agent检索/关键词索引", + "doc:04_Agent检索/同义词表", + "doc:04_Agent检索/来源文件索引", + "doc:04_Agent检索/检索说明", + "doc:04_Agent检索/知识库持续更新与验证流程", + "doc:04_Agent检索/问答提示词" + ] + } + ], + "tour": [ + { + "order": 1, + "title": "知识库入口", + "description": "知识库使用说明、首页、知识地图和问答入口。先从这里理解知识库结构与检索方式。", + "nodeIds": [ + "flow:layer-overview" + ] + }, + { + "order": 2, + "title": "需求文档", + "description": "所有正式需求、业务规则、需求变更和需求索引。点击本层可查看全部需求文档并检索。", + "nodeIds": [ + "flow:layer-requirements" + ] + }, + { + "order": 3, + "title": "里程碑", + "description": "项目阶段计划、里程碑节点、评审记录、准入准出和交付物节奏。", + "nodeIds": [ + "flow:layer-milestones" + ] + }, + { + "order": 4, + "title": "技术文档", + "description": "系统架构、数据模型、接口说明、技术方案和技术决策。", + "nodeIds": [ + "flow:layer-technical" + ] + }, + { + "order": 5, + "title": "测试相关", + "description": "测试计划、测试用例、缺陷记录、验收记录和上线检查。", + "nodeIds": [ + "flow:layer-testing" + ] + }, + { + "order": 6, + "title": "Agent检索", + "description": "检索说明、关键词、同义词、来源索引和持续更新验证流程。", + "nodeIds": [ + "flow:layer-agent" + ] + } + ] +} diff --git a/wishfulfilled-dashboard/meta.json b/wishfulfilled-dashboard/meta.json new file mode 100644 index 0000000..f9e650f --- /dev/null +++ b/wishfulfilled-dashboard/meta.json @@ -0,0 +1,10 @@ +{ + "lastAnalyzedAt": "2026-05-27T07:14:45.072Z", + "gitCommitHash": "", + "version": "1.0.0", + "analyzedFiles": 60, + "theme": { + "presetId": "dark", + "accentId": "cyan" + } +} diff --git a/wishfulfilled-wiki/.obsidian/app.json b/wishfulfilled-wiki/.obsidian/app.json new file mode 100644 index 0000000..9e26dfe --- /dev/null +++ b/wishfulfilled-wiki/.obsidian/app.json @@ -0,0 +1 @@ +{} \ No newline at end of file diff --git a/wishfulfilled-wiki/.obsidian/appearance.json b/wishfulfilled-wiki/.obsidian/appearance.json new file mode 100644 index 0000000..4be7969 --- /dev/null +++ b/wishfulfilled-wiki/.obsidian/appearance.json @@ -0,0 +1,3 @@ +{ + "theme": "obsidian" +} \ No newline at end of file diff --git a/wishfulfilled-wiki/.obsidian/core-plugins.json b/wishfulfilled-wiki/.obsidian/core-plugins.json new file mode 100644 index 0000000..639b90d --- /dev/null +++ b/wishfulfilled-wiki/.obsidian/core-plugins.json @@ -0,0 +1,33 @@ +{ + "file-explorer": true, + "global-search": true, + "switcher": true, + "graph": true, + "backlink": true, + "canvas": true, + "outgoing-link": true, + "tag-pane": true, + "footnotes": false, + "properties": true, + "page-preview": true, + "daily-notes": true, + "templates": true, + "note-composer": true, + "command-palette": true, + "slash-command": false, + "editor-status": true, + "bookmarks": true, + "markdown-importer": false, + "zk-prefixer": false, + "random-note": false, + "outline": true, + "word-count": true, + "slides": false, + "audio-recorder": false, + "workspaces": false, + "file-recovery": true, + "publish": false, + "sync": true, + "bases": true, + "webviewer": false +} \ No newline at end of file diff --git a/wishfulfilled-wiki/.obsidian/graph.json b/wishfulfilled-wiki/.obsidian/graph.json new file mode 100644 index 0000000..ad48efa --- /dev/null +++ b/wishfulfilled-wiki/.obsidian/graph.json @@ -0,0 +1,22 @@ +{ + "collapse-filter": true, + "search": "", + "showTags": false, + "showAttachments": false, + "hideUnresolved": false, + "showOrphans": true, + "collapse-color-groups": false, + "colorGroups": [], + "collapse-display": false, + "showArrow": false, + "textFadeMultiplier": 0, + "nodeSizeMultiplier": 1, + "lineSizeMultiplier": 1, + "collapse-forces": true, + "centerStrength": 0.518713248970312, + "repelStrength": 10, + "linkStrength": 1, + "linkDistance": 250, + "scale": 0.9999999999999976, + "close": true +} \ No newline at end of file diff --git a/wishfulfilled-wiki/.obsidian/workspace.json b/wishfulfilled-wiki/.obsidian/workspace.json new file mode 100644 index 0000000..ebaced2 --- /dev/null +++ b/wishfulfilled-wiki/.obsidian/workspace.json @@ -0,0 +1,226 @@ +{ + "main": { + "id": "cbc7833e6ae0e16b", + "type": "split", + "children": [ + { + "id": "80711f127ce5a470", + "type": "tabs", + "children": [ + { + "id": "ff990f59633b7f33", + "type": "leaf", + "state": { + "type": "markdown", + "state": { + "file": "02_项目管理流程/AI驱动内部系统开发流程_V3_总览.md", + "mode": "source", + "source": false + }, + "icon": "lucide-file", + "title": "AI驱动内部系统开发流程_V3_总览" + } + } + ] + } + ], + "direction": "vertical" + }, + "left": { + "id": "ee9f886dd5e7ad74", + "type": "split", + "children": [ + { + "id": "a5fafeb928030213", + "type": "tabs", + "children": [ + { + "id": "5f88809baca22f4f", + "type": "leaf", + "state": { + "type": "file-explorer", + "state": { + "sortOrder": "alphabetical", + "autoReveal": false + }, + "icon": "lucide-folder-closed", + "title": "文件列表" + } + }, + { + "id": "444c717a69f391f1", + "type": "leaf", + "state": { + "type": "search", + "state": { + "query": "", + "matchingCase": false, + "explainSearch": false, + "collapseAll": false, + "extraContext": false, + "sortOrder": "alphabetical" + }, + "icon": "lucide-search", + "title": "搜索" + } + }, + { + "id": "6cdb50be8fd92385", + "type": "leaf", + "state": { + "type": "bookmarks", + "state": {}, + "icon": "lucide-bookmark", + "title": "书签" + } + } + ] + } + ], + "direction": "horizontal", + "width": 300 + }, + "right": { + "id": "d76d00fd901f4d51", + "type": "split", + "children": [ + { + "id": "c6e93b7c0a6b53a5", + "type": "tabs", + "children": [ + { + "id": "a3ca721552c50754", + "type": "leaf", + "state": { + "type": "backlink", + "state": { + "file": "02_项目管理流程/AI驱动内部系统开发流程_V3_总览.md", + "collapseAll": false, + "extraContext": false, + "sortOrder": "alphabetical", + "showSearch": false, + "searchQuery": "", + "backlinkCollapsed": false, + "unlinkedCollapsed": true + }, + "icon": "links-coming-in", + "title": "AI驱动内部系统开发流程_V3_总览 的反向链接列表" + } + }, + { + "id": "ffebe63020b4e178", + "type": "leaf", + "state": { + "type": "outgoing-link", + "state": { + "file": "02_项目管理流程/AI驱动内部系统开发流程_V3_总览.md", + "linksCollapsed": false, + "unlinkedCollapsed": true + }, + "icon": "links-going-out", + "title": "AI驱动内部系统开发流程_V3_总览 的出链列表" + } + }, + { + "id": "a137bd7bdab1bff0", + "type": "leaf", + "state": { + "type": "tag", + "state": { + "sortOrder": "frequency", + "useHierarchy": true, + "showSearch": false, + "searchQuery": "" + }, + "icon": "lucide-tags", + "title": "标签" + } + }, + { + "id": "9806bfea20ade829", + "type": "leaf", + "state": { + "type": "all-properties", + "state": { + "sortOrder": "frequency", + "showSearch": false, + "searchQuery": "" + }, + "icon": "lucide-archive", + "title": "添加笔记属性" + } + }, + { + "id": "adfd00e3ffdd3411", + "type": "leaf", + "state": { + "type": "outline", + "state": { + "file": "02_项目管理流程/AI驱动内部系统开发流程_V3_总览.md", + "followCursor": false, + "showSearch": false, + "searchQuery": "" + }, + "icon": "lucide-list", + "title": "AI驱动内部系统开发流程_V3_总览 的大纲" + } + } + ] + } + ], + "direction": "horizontal", + "width": 300, + "collapsed": true + }, + "left-ribbon": { + "hiddenItems": { + "switcher:打开快速切换": false, + "graph:查看关系图谱": false, + "canvas:新建白板": false, + "daily-notes:打开/创建今天的日记": false, + "templates:插入模板": false, + "command-palette:打开命令面板": false, + "bases:新建数据库": false + } + }, + "active": "ff990f59633b7f33", + "lastOpenFiles": [ + "00_首页/知识地图.md", + "05_需求文档/20260517_USER评价业务闭环_第三步_数据流与中间对象设计_v3.md", + "Git使用说明.md", + "02_项目管理流程/AI驱动内部系统开发流程_V3_总览.md", + "20260517_USER评价业务闭环_共用能力图与渠道专属流程_v2.2.md", + "未命名.canvas", + "08_测试相关/上线检查模板.md", + "08_测试相关/验收记录模板.md", + "08_测试相关/缺陷记录模板.md", + "08_测试相关/测试计划模板.md", + "08_测试相关/测试用例模板.md", + "08_测试相关/测试用例索引.md", + "08_测试相关/README.md", + "07_技术文档/技术决策记录.md", + "07_技术文档/接口说明模板.md", + "07_技术文档/系统架构说明模板.md", + "07_技术文档/技术文档索引.md", + "07_技术文档/README.md", + "06_里程碑/里程碑评审记录.md", + "06_里程碑/阶段计划模板.md", + "06_里程碑/里程碑索引.md", + "06_里程碑/README.md", + "08_测试相关", + "07_技术文档", + "06_里程碑", + "02_项目管理流程/阶段1_业务需求完整形成.md", + "05_需求文档/需求文档索引.md", + "05_需求文档/README.md", + "05_需求文档", + "01_业务流程/业务补充验证记录.md", + "04_Agent检索/知识库持续更新与验证流程.md", + "99_归档", + "04_Agent检索", + "03_规范与模板", + "02_项目管理流程", + "01_业务流程", + "00_首页" + ] +} \ No newline at end of file diff --git a/wishfulfilled-wiki/.understand-anything/intermediate/assembled-graph.json b/wishfulfilled-wiki/.understand-anything/intermediate/assembled-graph.json new file mode 100644 index 0000000..92db686 --- /dev/null +++ b/wishfulfilled-wiki/.understand-anything/intermediate/assembled-graph.json @@ -0,0 +1,2951 @@ +{ + "version": "1.0.0", + "kind": "knowledge", + "project": { + "name": "知识地图", + "languages": [ + "markdown" + ], + "frameworks": [ + "karpathy-wiki" + ], + "description": "Knowledge graph for 知识地图", + "analyzedAt": "2026-05-27T02:58:24.412854+00:00", + "gitCommitHash": "" + }, + "nodes": [ + { + "id": "article:00_首页/Agent问答入口", + "type": "article", + "name": "Agent 问答入口", + "filePath": "00_首页\\Agent问答入口.md", + "summary": "当用户询问业务或项目流程时，Agent 应先检索本知识库 Markdown 文件，再组织回答。", + "tags": [ + "00_首页", + "[Agent", + "检索]", + "问答" + ], + "complexity": "simple", + "knowledgeMeta": { + "wikilinks": [], + "content": "---\ntype: agent_entry\ntags: [Agent, 问答, 检索]\naliases: [问答入口, Agent入口]\nsource: manual\nstatus: active\nowner: 内部技术团队\nupdated: 2026-05\n---\n\n# Agent 问答入口\n\n当用户询问业务或项目流程时，Agent 应先检索本知识库 Markdown 文件，再组织回答。\n\n## 推荐检索顺序\n\n1. `05_需求文档/`：持续新增的业务需求、业务规则、需求变更。\n2. `06_里程碑/`：项目节点、阶段计划、阶段评审、上线节奏。\n3. `07_技术文档/`：架构、接口、数据模型、实现方案、技术决策。\n4. `08_测试相关/`：测试计划、测试用例、缺陷、验收、上线检查。\n5. `02_项目管理流程/`：阶段、角色、交付物、门禁、检查清单。\n6. `01_业务流程/`：具体业务流程、业务对象、业务规则。\n7. `04_Agent检索/`：关键词、同义词、回答规则、来源索引。\n8. `03_规范与模板/`：需要产出文档或表单时检索。\n\n## 回答格式\n\n- 先给结论。\n- 再按阶段、负责人、输入、关键动作、输出、检查点说明。\n- 最后注明来源文件。\n- 若知识库没有明确记录，回答“知识库未明确记录”，并说明建议补充到哪个文件。\n\n## 示例问题\n\n- 一个内部系统需求从提出到上线要走哪些阶段？\n- 阶段2.5测试提前补漏要产出什么？\n- 业务主管在项目入口分级中负责什么？\n- 什么时候需要前端提前参与需求收敛？\n- 新增一条业务规则后，怎么验证 Agent 能搜到？\n- 某个业务规则应该补充到哪个模板里？\n- 某个需求对应哪些测试用例？\n- 某个模块有哪些接口说明？\n- 这个项目当前处在哪个里程碑？\n\n## 业务补充验证入口\n\n- 需求文档目录：`05_需求文档/`\n- 里程碑目录：`06_里程碑/`\n- 技术文档目录：`07_技术文档/`\n- 测试相关目录：`08_测试相关/`\n- 需求文档索引：`05_需求文档/需求文档索引.md`\n- 测试用例索引：`08_测试相关/测试用例索引.md`\n- 模板：`03_规范与模板/业务规则与需求补充模板.md`\n- 流程：`04_Agent检索/知识库持续更新与验证流程.md`\n- 记录：`01_业务流程/业务补充验证记录.md`\n", + "backlinks": [ + "article:00_首页/知识库首页", + "article:欢迎", + "article:知识库使用说明", + "article:知识库使用说明" + ] + } + }, + { + "id": "article:00_首页/知识地图", + "type": "article", + "name": "知识地图", + "filePath": "00_首页\\知识地图.md", + "summary": "- [[../知识库使用说明|知识库使用说明]] - [[../Git使用说明|Git 使用说明]]", + "tags": [ + "00_首页", + "[知识地图", + "导航]" + ], + "complexity": "complex", + "knowledgeMeta": { + "wikilinks": [ + "../知识库使用说明", + "../Git使用说明", + "../05_需求文档/README", + "../05_需求文档/需求文档索引", + "../03_规范与模板/需求说明模板", + "../03_规范与模板/业务规则与需求补充模板", + "../01_业务流程/业务规则索引", + "../01_业务流程/业务对象字典", + "../06_里程碑/README", + "../06_里程碑/里程碑索引", + "../06_里程碑/阶段计划模板", + "../06_里程碑/里程碑评审记录", + "../02_项目管理流程/AI驱动内部系统开发流程_V3_总览", + "../02_项目管理流程/阶段交付物清单", + "../02_项目管理流程/项目检查清单", + "../07_技术文档/README", + "../07_技术文档/技术文档索引", + "../07_技术文档/系统架构说明模板", + "../07_技术文档/接口说明模板", + "../07_技术文档/技术决策记录", + "../08_测试相关/README", + "../08_测试相关/测试用例索引", + "../08_测试相关/测试用例模板", + "../08_测试相关/测试计划模板", + "../08_测试相关/缺陷记录模板", + "../08_测试相关/验收记录模板", + "../08_测试相关/上线检查模板", + "../02_项目管理流程/阶段2.5_测试提前补漏", + "../02_项目管理流程/阶段4_测试培训上线回流", + "../04_Agent检索/检索说明", + "../04_Agent检索/问答提示词", + "../04_Agent检索/关键词索引", + "../04_Agent检索/同义词表", + "../04_Agent检索/来源文件索引", + "../04_Agent检索/知识库持续更新与验证流程" + ], + "content": "---\ntype: map\ntags: [知识地图, 导航]\naliases: [知识库地图]\nsource: manual\nstatus: active\nowner: 内部技术团队\nupdated: 2026-05\n---\n\n# 知识地图\n\n## 使用说明\n\n- [[../知识库使用说明|知识库使用说明]]\n- [[../Git使用说明|Git 使用说明]]\n\n## 需求文档\n\n- [[../05_需求文档/README|需求文档入口]]\n- [[../05_需求文档/需求文档索引|需求文档索引]]\n- [[../03_规范与模板/需求说明模板|需求说明模板]]\n- [[../03_规范与模板/业务规则与需求补充模板|业务规则与需求补充模板]]\n- [[../01_业务流程/业务规则索引|业务规则索引]]\n- [[../01_业务流程/业务对象字典|业务对象字典]]\n\n## 里程碑\n\n- [[../06_里程碑/README|里程碑入口]]\n- [[../06_里程碑/里程碑索引|里程碑索引]]\n- [[../06_里程碑/阶段计划模板|阶段计划模板]]\n- [[../06_里程碑/里程碑评审记录|里程碑评审记录]]\n- [[../02_项目管理流程/AI驱动内部系统开发流程_V3_总览|项目管理流程总览]]\n- [[../02_项目管理流程/阶段交付物清单|阶段交付物清单]]\n- [[../02_项目管理流程/项目检查清单|项目检查清单]]\n\n## 技术文档\n\n- [[../07_技术文档/README|技术文档入口]]\n- [[../07_技术文档/技术文档索引|技术文档索引]]\n- [[../07_技术文档/系统架构说明模板|系统架构说明模板]]\n- [[../07_技术文档/接口说明模板|接口说明模板]]\n- [[../07_技术文档/技术决策记录|技术决策记录]]\n\n## 测试相关\n\n- [[../08_测试相关/README|测试相关入口]]\n- [[../08_测试相关/测试用例索引|测试用例索引]]\n- [[../08_测试相关/测试用例模板|测试用例模板]]\n- [[../08_测试相关/测试计划模板|测试计划模板]]\n- [[../08_测试相关/缺陷记录模板|缺陷记录模板]]\n- [[../08_测试相关/验收记录模板|验收记录模板]]\n- [[../08_测试相关/上线检查模板|上线检查模板]]\n- [[../02_项目管理流程/阶段2.5_测试提前补漏|阶段2.5 测试提前补漏]]\n- [[../02_项目管理流程/阶段4_测试培训上线回流|阶段4 测试培训上线回流]]\n\n## Agent 检索\n\n- [[../04_Agent检索/检索说明|检索说明]]\n- [[../04_Agent检索/问答提示词|问答提示词]]\n- [[../04_Agent检索/关键词索引|关键词索引]]\n- [[../04_Agent检索/同义词表|同义词表]]\n- [[../04_Agent检索/来源文件索引|来源文件索引]]\n- [[../04_Agent检索/知识库持续更新与验证流程|持续更新与验证流程]]\n", + "backlinks": [ + "article:00_首页/知识库首页", + "article:欢迎", + "article:知识库使用说明", + "article:知识库使用说明" + ] + } + }, + { + "id": "article:00_首页/知识库首页", + "type": "article", + "name": "如愿知识库首页", + "filePath": "00_首页\\知识库首页.md", + "summary": "本知识库用于沉淀如愿内部系统建设中的业务流程、项目管理流程、角色职责、交付物、检查清单与 Agent 检索问答规范。", + "tags": [ + "00_首页", + "[知识库", + "如愿]", + "首页" + ], + "complexity": "moderate", + "knowledgeMeta": { + "wikilinks": [ + "../知识库使用说明", + "知识地图", + "Agent问答入口", + "../05_需求文档/README", + "../06_里程碑/README", + "../07_技术文档/README", + "../08_测试相关/README", + "../04_Agent检索/检索说明" + ], + "content": "---\ntype: index\ntags: [知识库, 首页, 如愿]\naliases: [如愿知识库首页, 知识库入口]\nsource: manual\nstatus: active\nowner: 内部技术团队\nupdated: 2026-05\n---\n\n# 如愿知识库首页\n\n本知识库用于沉淀如愿内部系统建设中的业务流程、项目管理流程、角色职责、交付物、检查清单与 Agent 检索问答规范。\n\n## 快速入口\n\n- [[../知识库使用说明|知识库使用说明]]\n- [[知识地图]]\n- [[Agent问答入口]]\n- [[../05_需求文档/README|需求文档]]\n- [[../06_里程碑/README|里程碑]]\n- [[../07_技术文档/README|技术文档]]\n- [[../08_测试相关/README|测试相关]]\n- [[../04_Agent检索/检索说明|Agent 检索说明]]\n\n## 当前权威来源\n\n- 项目管理流程：`AI_驱动_内部系统开发流程_V3.docx`\n- 适用范围：ERP、内部系统、小型业务系统、运营工具、AI 辅助开发项目。\n\n## 使用原则\n\n1. 需求类问题先查需求文档。\n2. 进度、节点、准入问题先查里程碑。\n3. 技术实现、接口、架构问题先查技术文档。\n4. 测试范围、用例、验收、缺陷问题先查测试相关。\n5. Agent 回答必须说明来源文件。\n6. 知识库没有明确记录时，不要猜测，应提示补充位置。\n", + "backlinks": [ + "article:欢迎", + "article:知识库使用说明" + ] + } + }, + { + "id": "article:01_业务流程/README", + "type": "article", + "name": "业务流程", + "filePath": "01_业务流程\\README.md", + "summary": "本目录用于沉淀真实业务流程。第一阶段先建立模板、业务对象字典和业务规则索引，后续按流程逐条补充。", + "tags": [ + "01_业务流程", + "[业务流程", + "入口]" + ], + "complexity": "simple", + "knowledgeMeta": { + "wikilinks": [ + "业务流程模板", + "业务对象字典", + "业务规则索引", + "../02_项目管理流程/阶段1_业务需求完整形成", + "../02_项目管理流程/阶段2_高保真模型与业务对象确认" + ], + "content": "---\ntype: index\ntags: [业务流程, 入口]\naliases: [业务流程入口]\nsource: manual\nstatus: active\nowner: 业务主管\nupdated: 2026-05\n---\n\n# 业务流程\n\n本目录用于沉淀真实业务流程。第一阶段先建立模板、业务对象字典和业务规则索引，后续按流程逐条补充。\n\n## 当前文件\n\n- [[业务流程模板]]\n- [[业务对象字典]]\n- [[业务规则索引]]\n\n## 录入要求\n\n每条业务流程至少补充：流程名称、适用角色、触发条件、主流程、分支流程、异常处理、输入数据、输出结果、相关系统、业务规则、常见问题、关联项目管理阶段。\n\n## 与项目管理流程的关系\n\n业务流程内容主要用于支撑 [[../02_项目管理流程/阶段1_业务需求完整形成|阶段1 业务需求完整形成]] 和 [[../02_项目管理流程/阶段2_高保真模型与业务对象确认|阶段2 高保真模型与业务对象确认]]。\n", + "backlinks": [] + } + }, + { + "id": "article:01_业务流程/业务对象字典", + "type": "article", + "name": "业务对象字典", + "filePath": "01_业务流程\\业务对象字典.md", + "summary": "用于沉淀业务对象、字段、状态和生命周期，是页面、接口、数据库、测试、AI 提示词的共同基础。", + "tags": [ + "01_业务流程", + "[业务对象", + "字典]", + "数据对象" + ], + "complexity": "simple", + "knowledgeMeta": { + "wikilinks": [ + "../02_项目管理流程/阶段2_高保真模型与业务对象确认", + "../02_项目管理流程/阶段交付物清单" + ], + "content": "---\ntype: dictionary\ntags: [业务对象, 数据对象, 字典]\naliases: [业务对象模型, 对象字典]\nsource: manual\nstatus: draft\nowner: 业务主管\nupdated: 2026-05\n---\n\n# 业务对象字典\n\n用于沉淀业务对象、字段、状态和生命周期，是页面、接口、数据库、测试、AI 提示词的共同基础。\n\n## 对象清单\n\n| 业务对象 | 定义 | 关键字段 | 状态 | 关联流程 | 备注 |\n|---|---|---|---|---|---|\n| | | | | | |\n\n## 维护规则\n\n- 阶段2必须确认统一业务对象模型。\n- 新增页面、接口、数据库表或测试用例时，应回查本字典。\n- 字段含义、状态枚举和对象关系不明确时，不应进入正式开发。\n\n## 关联条目\n\n- [[../02_项目管理流程/阶段2_高保真模型与业务对象确认]]\n- [[../02_项目管理流程/阶段交付物清单]]\n", + "backlinks": [ + "article:01_业务流程/README", + "article:知识库使用说明" + ] + } + }, + { + "id": "article:01_业务流程/业务流程模板", + "type": "article", + "name": "业务流程模板", + "filePath": "01_业务流程\\业务流程模板.md", + "summary": "- 流程名称： - 适用部门： - 适用角色： - 相关系统： - 流程负责人： - 当前状态：draft / active / deprecated", + "tags": [ + "01_业务流程", + "[业务流程", + "模板]" + ], + "complexity": "simple", + "knowledgeMeta": { + "wikilinks": [ + "../02_项目管理流程/阶段1_业务需求完整形成", + "../02_项目管理流程/阶段2_高保真模型与业务对象确认" + ], + "content": "---\ntype: template\ntags: [业务流程, 模板]\naliases: [业务流程梳理模板]\nsource: manual\nstatus: active\nowner: 业务主管\nupdated: 2026-05\n---\n\n# 业务流程模板\n\n## 基本信息\n\n- 流程名称：\n- 适用部门：\n- 适用角色：\n- 相关系统：\n- 流程负责人：\n- 当前状态：draft / active / deprecated\n\n## 触发条件\n\n说明什么情况下进入该流程。\n\n## 前置条件\n\n说明流程开始前必须满足的条件、权限、数据或审批。\n\n## 主流程\n\n1. \n2. \n3. \n\n## 分支流程\n\n| 分支场景 | 判断条件 | 处理方式 | 负责人 | 输出 |\n|---|---|---|---|---|\n| | | | | |\n\n## 异常处理\n\n| 异常场景 | 发现方式 | 处理方式 | 升级路径 |\n|---|---|---|---|\n| | | | |\n\n## 输入数据\n\n| 数据项 | 来源 | 必填 | 说明 |\n|---|---|---|---|\n| | | | |\n\n## 输出结果\n\n| 输出物 | 接收方 | 用途 |\n|---|---|---|\n| | | |\n\n## 业务规则\n\n- \n\n## 常见问题\n\n- 问：\n 答：\n\n## 关联项目管理阶段\n\n- [[../02_项目管理流程/阶段1_业务需求完整形成]]\n- [[../02_项目管理流程/阶段2_高保真模型与业务对象确认]]\n", + "backlinks": [ + "article:01_业务流程/README" + ] + } + }, + { + "id": "article:01_业务流程/业务补充验证记录", + "type": "article", + "name": "业务补充验证记录", + "filePath": "01_业务流程\\业务补充验证记录.md", + "summary": "每次新增或修订 `01_业务流程/` 下的业务规则、需求或流程文档后，在此记录 Agent 检索验证结果。", + "tags": [ + "01_业务流程", + "Agent检索]", + "[业务流程", + "业务规则", + "验证记录" + ], + "complexity": "simple", + "knowledgeMeta": { + "wikilinks": [], + "content": "---\ntype: validation_log\ntags: [业务流程, 业务规则, 验证记录, Agent检索]\naliases: [业务补充验证, Agent问答验证记录]\nsource: manual\nstatus: active\nowner: 产品经理 / 内部技术团队\nupdated: 2026-05\n---\n\n# 业务补充验证记录\n\n## 使用说明\n\n每次新增或修订 `01_业务流程/` 下的业务规则、需求或流程文档后，在此记录 Agent 检索验证结果。\n\n## 验证记录\n\n| 日期 | 业务域 | 新增/修订文件 | 验证问题 | 是否命中 | 来源文件 | 结果 | 待补充 |\n|---|---|---|---|---|---|---|---|\n| | | | | 是/否 | | 通过/失败 | |\n\n## 验证结论模板\n\n```markdown\n### YYYY-MM-DD 业务域_规则或需求名称\n\n- 新增/修订文件：\n- 已更新索引：业务规则索引 / 业务对象字典 / 关键词索引 / 同义词表 / 来源文件索引\n- 验证问题：\n 1. \n 2. \n 3. \n- 结论：通过 / 失败\n- 待补充：\n```\n", + "backlinks": [] + } + }, + { + "id": "article:01_业务流程/业务规则索引", + "type": "article", + "name": "业务规则索引", + "filePath": "01_业务流程\\业务规则索引.md", + "summary": "用于集中记录跨流程复用的业务规则，避免规则散落在需求、页面和测试用例中。", + "tags": [ + "01_业务流程", + "[业务规则", + "索引]" + ], + "complexity": "simple", + "knowledgeMeta": { + "wikilinks": [], + "content": "---\ntype: index\ntags: [业务规则, 索引]\naliases: [规则索引]\nsource: manual\nstatus: draft\nowner: 业务主管\nupdated: 2026-05\n---\n\n# 业务规则索引\n\n用于集中记录跨流程复用的业务规则，避免规则散落在需求、页面和测试用例中。\n\n| 规则编号 | 规则名称 | 适用流程 | 规则说明 | 来源 | 状态 |\n|---|---|---|---|---|---|\n| BR-001 | | | | | draft |\n\n## 维护要求\n\n- 规则必须能追溯到业务流程或项目文档。\n- 涉及权限、状态流转、金额、时间、审批、异常处理的规则应优先沉淀。\n- 规则变更后，应同步检查测试用例和上线培训材料。\n- 新增规则建议使用 `03_规范与模板/业务规则与需求补充模板.md`。\n- 新增或修订后，按 `04_Agent检索/知识库持续更新与验证流程.md` 执行 Agent 检索验证。\n", + "backlinks": [ + "article:01_业务流程/README", + "article:知识库使用说明" + ] + } + }, + { + "id": "article:02_项目管理流程/AI驱动内部系统开发流程_V3_总览", + "type": "article", + "name": "AI 驱动内部系统开发流程 V3 总览", + "filePath": "02_项目管理流程\\AI驱动内部系统开发流程_V3_总览.md", + "summary": "本流程适用于公司当前阶段的 ERP、内部系统、小型业务系统、运营工具、AI 辅助开发项目。", + "tags": [ + "02_项目管理流程", + "AI驱动开发", + "ERP", + "[项目管理流程", + "内部系统]" + ], + "complexity": "moderate", + "knowledgeMeta": { + "wikilinks": [ + "阶段0_项目入口分级", + "阶段1_业务需求完整形成", + "阶段2_高保真模型与业务对象确认", + "阶段2.5_测试提前补漏", + "阶段3_研发协作与正式开发", + "阶段4_测试培训上线回流", + "角色职责矩阵", + "阶段交付物清单", + "项目检查清单" + ], + "content": "---\ntype: process_overview\ntags: [项目管理流程, AI驱动开发, ERP, 内部系统]\naliases: [AI驱动内部系统开发流程, 内部系统开发流程V3, ERP开发流程]\nsource: AI_驱动_内部系统开发流程_V3.docx\nstatus: active\nowner: 内部技术团队\nupdated: 2026-05\n---\n\n# AI 驱动内部系统开发流程 V3 总览\n\n## 版本定位\n\n本流程适用于公司当前阶段的 ERP、内部系统、小型业务系统、运营工具、AI 辅助开发项目。\n\n核心目标不是让流程变复杂，而是解决以下问题：\n\n- 业务需求说不清。\n- AI 生成内容不完整。\n- 前端模型介入太晚。\n- 后端数据库设计被页面倒逼。\n- 测试太晚才发现需求漏项。\n- 项目完成后留下大量重复代码和技术债。\n\n## 总体阶段\n\n| 阶段 | 阶段名称 | 核心目标 | 核心负责人 |\n|---|---|---|---|\n| 阶段0 | 项目入口分级 | 判断项目是否值得做、走轻流程还是完整流程 | 业务主管 / 技术负责人 |\n| 阶段1 | 业务需求完整形成 | 业务侧通过 Vibe Coding 跑完整需求 | 业务主管 / 业务人员 |\n| 阶段2 | 高保真模型与业务对象确认 | 把完整但粗糙的需求收敛成可开发模型 | 前端 / 产品经理 |\n| 阶段2.5 | 测试提前补漏 | 在开发前用测试视角发现需求漏洞 | 测试 |\n| 阶段3 | 研发协作与正式开发 | 基于高保真模型进行模块化、安全、可维护开发 | 前端 / 后端 / 算法 |\n| 阶段4 | 测试、培训、上线、回流 | 完成测试、培训、上线验收和问题回流 | 测试 / 业务主管 |\n| 阶段5 | 技术债治理与能力沉淀 | 清理 AI 冗余代码并沉淀复用能力 | 技术负责人 |\n\n## 阶段门禁\n\n| 门禁 | 通过标准 |\n|---|---|\n| Gate 0 | 项目入口通过：确认值得做，确认项目类型。 |\n| Gate 1 | 需求完整通过：主流程、分支、页面、按钮、字段、状态大致完整。 |\n| Gate 2 | 高保真模型通过：页面收敛、按钮行为、业务对象、状态、V1/V2 明确。 |\n| Gate 2.5 | 测试补漏：测试用例初稿发现的阻塞问题已处理。 |\n| Gate 3 | 开发联调通过：前后端、数据库、权限、安全、主要流程联调完成。 |\n| Gate 4 | 上线验收通过：测试通过、业务确认、培训完成。 |\n| Gate 5 | 技术债治理完成：重复代码、组件、接口、数据结构完成治理或进入债务池。 |\n\n## 完整版文件结构\n\n- `00_项目入口分级.md`\n- `01_主流程说明.md`\n- `02_日常操作页面结构.md`\n- `03_功能页面按钮盘点表.md`\n- `04_分支流程_XXX.md`\n- `05_异常流程_XXX.md`\n- `06_VibeCoding页面验证记录.md`\n- `07_高保真模型.html`\n- `07_高保真模型说明.md`\n- `08_项目周期与版本确认.md`\n- `09_前端技术评审.md`\n- `10_技术预检记录.md`\n- `10A_统一业务对象模型.md`\n- `10B_按钮行为矩阵.md`\n- `11_测试用例初稿与需求补漏.md`\n- `12_研发任务拆分与协作计划.md`\n- `13_技术实现对接.md`\n- `14_代码治理与安全规范.md`\n- `15_开发问题与联调记录.md`\n- `16_正式测试报告.md`\n- `17_内部培训手册.md`\n- `18_上线验收记录.md`\n- `19_上线问题与回流需求.md`\n- `20_技术债清单.md`\n- `21_业务原子能力沉淀清单.md`\n- `22_组件库与服务复用清单.md`\n- `23_AI开发上下文模板更新记录.md`\n\n## 轻量版文件结构\n\n小项目可以使用轻量版：\n\n- `00_项目入口分级.md`\n- `01_业务需求包.md`\n- `02_高保真模型包.md`\n- `03_项目版本与技术预检.md`\n- `04_测试用例初稿与需求补漏.md`\n- `05_研发协作与技术实现包.md`\n- `06_代码治理与安全规范.md`\n- `07_测试培训上线包.md`\n- `08_技术债与能力沉淀包.md`\n\n## 最终核心原则\n\n- 先分级，再开发。\n- 阶段1追求需求完整，不追求产品完善。\n- Vibe Coding 页面只是需求原型，不直接进入生产。\n- 阶段2追求模型高效，前端必须深度参与。\n- 高保真模型确认后，才允许正式开发。\n- 统一业务对象模型是页面、接口、数据库、测试、AI 提示词的共同基础。\n- 性能、安全、权限、并发、日志、可回滚必须提前预检。\n- 测试提前补漏，不只是上线前找 Bug。\n- 研发阶段以代码质量、模块化、安全性、可维护性为中心。\n- AI 代码必须治理，不能直接堆进生产。\n- 每个项目都要沉淀业务原子能力。\n- 每完成 3-4 个项目，必须进行技术债治理。\n\n## 一句话总结\n\n这套流程不是为了让 AI 替代开发，而是让 AI 帮业务更快形成完整需求，让前端和产品把需求收敛成高保真模型，让研发团队基于模型高质量开发，让测试和技术债治理保障系统长期可用。\n\n## 关联条目\n\n- [[阶段0_项目入口分级]]\n- [[阶段1_业务需求完整形成]]\n- [[阶段2_高保真模型与业务对象确认]]\n- [[阶段2.5_测试提前补漏]]\n- [[阶段3_研发协作与正式开发]]\n- [[阶段4_测试培训上线回流]]\n- [[角色职责矩阵]]\n- [[阶段交付物清单]]\n- [[项目检查清单]]\n", + "backlinks": [ + "article:02_项目管理流程/README", + "article:02_项目管理流程/常见问题FAQ", + "article:02_项目管理流程/常见问题FAQ", + "article:02_项目管理流程/角色职责矩阵", + "article:02_项目管理流程/阶段0_项目入口分级", + "article:02_项目管理流程/阶段交付物清单", + "article:02_项目管理流程/项目检查清单", + "article:知识库使用说明" + ] + } + }, + { + "id": "article:02_项目管理流程/README", + "type": "article", + "name": "项目管理流程", + "filePath": "02_项目管理流程\\README.md", + "summary": "本目录基于 `AI_驱动_内部系统开发流程_V3.docx` 拆解，用于指导 ERP、内部系统、小型业务系统、运营工具、AI 辅助开发项目。", + "tags": [ + "02_项目管理流程", + "AI驱动开发]", + "[项目管理流程" + ], + "complexity": "moderate", + "knowledgeMeta": { + "wikilinks": [ + "AI驱动内部系统开发流程_V3_总览", + "阶段0_项目入口分级", + "阶段1_业务需求完整形成", + "阶段2_高保真模型与业务对象确认", + "阶段2.5_测试提前补漏", + "阶段3_研发协作与正式开发", + "阶段4_测试培训上线回流", + "角色职责矩阵", + "阶段交付物清单", + "项目检查清单", + "常见问题FAQ" + ], + "content": "---\ntype: index\ntags: [项目管理流程, AI驱动开发]\naliases: [项目管理流程入口, 开发流程入口]\nsource: AI_驱动_内部系统开发流程_V3.docx\nstatus: active\nowner: 内部技术团队\nupdated: 2026-05\n---\n\n# 项目管理流程\n\n本目录基于 `AI_驱动_内部系统开发流程_V3.docx` 拆解，用于指导 ERP、内部系统、小型业务系统、运营工具、AI 辅助开发项目。\n\n## 阶段文件\n\n- [[AI驱动内部系统开发流程_V3_总览]]\n- [[阶段0_项目入口分级]]\n- [[阶段1_业务需求完整形成]]\n- [[阶段2_高保真模型与业务对象确认]]\n- [[阶段2.5_测试提前补漏]]\n- [[阶段3_研发协作与正式开发]]\n- [[阶段4_测试培训上线回流]]\n\n## 重组索引\n\n- [[角色职责矩阵]]\n- [[阶段交付物清单]]\n- [[项目检查清单]]\n- [[常见问题FAQ]]\n\n## 核心原则\n\n先分级，再开发。阶段1追求需求完整，不追求产品完善。高保真模型确认后，才允许正式开发。测试要提前补漏。AI 代码必须治理，不能直接堆进生产。\n", + "backlinks": [] + } + }, + { + "id": "article:02_项目管理流程/常见问题FAQ", + "type": "article", + "name": "常见问题 FAQ", + "filePath": "02_项目管理流程\\常见问题FAQ.md", + "summary": "通常经过阶段0项目入口分级、阶段1业务需求完整形成、阶段2高保真模型与业务对象确认、阶段2.5测试提前补漏、阶段3研发协作与正式开发、阶段4测试培训上线回流。文档还定义了阶段5技术债治理与能力沉淀。", + "tags": [ + "02_项目管理流程", + "FAQ", + "[项目管理流程", + "问答]" + ], + "complexity": "moderate", + "knowledgeMeta": { + "wikilinks": [ + "AI驱动内部系统开发流程_V3_总览", + "阶段0_项目入口分级", + "角色职责矩阵", + "阶段1_业务需求完整形成", + "阶段2.5_测试提前补漏", + "阶段2.5_测试提前补漏", + "阶段交付物清单", + "阶段2_高保真模型与业务对象确认", + "阶段3_研发协作与正式开发", + "阶段4_测试培训上线回流", + "项目检查清单", + "阶段1_业务需求完整形成", + "AI驱动内部系统开发流程_V3_总览" + ], + "content": "---\ntype: faq\ntags: [项目管理流程, FAQ, 问答]\naliases: [流程常见问题, 项目管理问答]\nsource: AI_驱动_内部系统开发流程_V3.docx\nstatus: active\nowner: 内部技术团队\nupdated: 2026-05\n---\n\n# 常见问题 FAQ\n\n## 一个内部系统需求从提出到上线要走哪些阶段？\n\n通常经过阶段0项目入口分级、阶段1业务需求完整形成、阶段2高保真模型与业务对象确认、阶段2.5测试提前补漏、阶段3研发协作与正式开发、阶段4测试培训上线回流。文档还定义了阶段5技术债治理与能力沉淀。\n\n来源：[[AI驱动内部系统开发流程_V3_总览]]\n\n## 阶段0项目入口分级由谁负责？\n\n由业务主管和技术负责人共同负责。业务主管判断业务价值和范围，技术负责人判断技术复杂度和风险。\n\n来源：[[阶段0_项目入口分级]]、[[角色职责矩阵]]\n\n## 业务需求完整形成阶段的目标是什么？\n\n业务侧通过 Vibe Coding 跑完整需求。阶段1追求需求完整，不追求产品完善。\n\n来源：[[阶段1_业务需求完整形成]]\n\n## 阶段2.5测试提前补漏应该在什么时候发生？\n\n发生在高保真模型确认后、正式开发前。\n\n来源：[[阶段2.5_测试提前补漏]]\n\n## 阶段2.5测试提前补漏要产出什么？\n\n主要产出 `11_测试用例初稿与需求补漏.md`，并形成需求补漏记录、阻塞问题清单和已关闭问题清单。\n\n来源：[[阶段2.5_测试提前补漏]]、[[阶段交付物清单]]\n\n## 什么时候需要前端提前参与需求收敛？\n\n阶段2必须由前端深度参与。若需求涉及多页面、复杂交互、权限、状态流转、数据结构或组件复用，前端应在需求收敛时提前参与。\n\n来源：[[阶段2_高保真模型与业务对象确认]]\n\n## 研发协作与正式开发阶段如何保证模块化、安全和可维护？\n\n依赖统一业务对象模型、研发任务拆分、技术实现对接、代码治理与安全规范、开发问题与联调记录。AI 代码必须经过治理，不能直接堆进生产。\n\n来源：[[阶段3_研发协作与正式开发]]\n\n## 上线前需要检查哪些事项？\n\n至少检查正式测试、主流程、分支流程、权限、异常、数据边界、内部培训手册、业务确认、上线问题回流机制。\n\n来源：[[阶段4_测试培训上线回流]]、[[项目检查清单]]\n\n## Vibe Coding 页面能不能直接进入生产？\n\n不能。Vibe Coding 页面只是需求原型，不直接进入生产。\n\n来源：[[阶段1_业务需求完整形成]]、[[AI驱动内部系统开发流程_V3_总览]]\n", + "backlinks": [ + "article:02_项目管理流程/README" + ] + } + }, + { + "id": "article:02_项目管理流程/角色职责矩阵", + "type": "article", + "name": "角色职责矩阵", + "filePath": "02_项目管理流程\\角色职责矩阵.md", + "summary": "| 角色 | 主要负责阶段 | 核心职责 | 典型产出 | |---|---|---|---| | 业务主管 | 阶段0、阶段1、阶段4 | 判断项目价值、明确主流程、确认业务完整性、上线验收 | 项目入口分级、主流程说明、业务验收口径、上线验收记录 | | 业务人员 | 阶段1 | 补充分支流程、提供样本数据、验证真实操作路径 | 分支流程、异常流程、Vibe Coding 页面验证记录 ...", + "tags": [ + "02_项目管理流程", + "RACI]", + "[项目管理流程", + "角色职责" + ], + "complexity": "simple", + "knowledgeMeta": { + "wikilinks": [ + "AI驱动内部系统开发流程_V3_总览", + "阶段0_项目入口分级", + "阶段1_业务需求完整形成", + "阶段2.5_测试提前补漏", + "阶段4_测试培训上线回流" + ], + "content": "---\ntype: responsibility_matrix\ntags: [项目管理流程, 角色职责, RACI]\naliases: [角色职责, 职责矩阵, RACI]\nsource: AI_驱动_内部系统开发流程_V3.docx\nstatus: active\nowner: 内部技术团队\nupdated: 2026-05\n---\n\n# 角色职责矩阵\n\n## 总览\n\n| 角色 | 主要负责阶段 | 核心职责 | 典型产出 |\n|---|---|---|---|\n| 业务主管 | 阶段0、阶段1、阶段4 | 判断项目价值、明确主流程、确认业务完整性、上线验收 | 项目入口分级、主流程说明、业务验收口径、上线验收记录 |\n| 业务人员 | 阶段1 | 补充分支流程、提供样本数据、验证真实操作路径 | 分支流程、异常流程、Vibe Coding 页面验证记录 |\n| 产品经理 | 阶段2 | 收敛需求、组织高保真模型、明确版本范围 | 高保真模型说明、项目周期与版本确认 |\n| 前端 | 阶段2、阶段3 | 深度参与模型收敛、页面结构、按钮行为、组件复用、前端开发 | 高保真模型、前端技术评审、按钮行为矩阵、前端实现 |\n| 后端 | 阶段3 | 设计接口、数据库、权限、安全、日志、回滚和服务能力 | 技术实现对接、后端服务、接口和数据库方案 |\n| 算法 | 阶段3 | 判断是否需要 AI，设计输入输出、置信度、人工审核和风险控制 | 算法适用性判断、算法输入输出说明、置信度规则 |\n| 测试 | 阶段2.5、阶段4 | 提前写测试用例、发现需求漏洞、正式测试、培训材料、上线反馈 | 测试用例初稿、正式测试报告、内部培训手册、上线问题回流 |\n| 技术负责人 | 阶段0、阶段5 | 技术分级、风险判断、技术债治理和能力沉淀 | 技术债清单、业务原子能力沉淀清单、组件库与服务复用清单 |\n\n## 业务主管\n\n业务主管保证方向正确、主流程清楚、需求不漏大块。\n\n职责：\n\n- 判断项目是否值得做。\n- 定义主流程。\n- 定义日常操作入口。\n- 明确业务人员每天先看什么页面。\n- 拆分分支流程，指定业务人员补充。\n- 确认异常流程。\n- 确认业务完整性。\n- 参与业务验收。\n\n## 业务人员\n\n业务人员负责具体分支流程和真实操作细节。\n\n职责：\n\n- 补充分支流程。\n- 提供样本数据，例如 ASIN、订单、评论、用户、表格等真实样本。\n- 使用 Vibe Coding 跑页面，验证是否符合真实操作。\n- 补充异常场景。\n\n## 算法\n\n算法保证 AI 能力可控、可解释、可人工审核。\n\n职责：\n\n- 判断是否需要 AI，避免为了 AI 而 AI。\n- 设计算法输入，明确模型需要哪些数据。\n- 设计算法输出，明确 AI 返回什么结果。\n- 制定置信度规则。\n- 制定人工审核机制。\n- 设计风险控制，确保 AI 判断错误时可以回退和纠正。\n\n## 测试\n\n测试不只是最后找 Bug，还要提前补漏，并负责内部培训材料。\n\n职责：\n\n- 高保真模型出来后先写测试用例。\n- 用测试视角发现流程、按钮、权限遗漏。\n- 正式测试主流程、分支流程、权限、异常和数据。\n- 输出验收报告。\n- 将测试用例转成业务操作手册。\n- 记录上线问题并回流需求池。\n\n## 关联条目\n\n- [[AI驱动内部系统开发流程_V3_总览]]\n- [[阶段0_项目入口分级]]\n- [[阶段1_业务需求完整形成]]\n- [[阶段2.5_测试提前补漏]]\n- [[阶段4_测试培训上线回流]]\n", + "backlinks": [ + "article:02_项目管理流程/AI驱动内部系统开发流程_V3_总览", + "article:02_项目管理流程/README", + "article:02_项目管理流程/常见问题FAQ", + "article:02_项目管理流程/阶段0_项目入口分级", + "article:02_项目管理流程/阶段1_业务需求完整形成" + ] + } + }, + { + "id": "article:02_项目管理流程/阶段0_项目入口分级", + "type": "article", + "name": "阶段0 项目入口分级", + "filePath": "02_项目管理流程\\阶段0_项目入口分级.md", + "summary": "不是所有需求都应该进入完整开发流程。阶段0用于判断项目是否值得做，以及走轻流程还是完整流程。", + "tags": [ + "02_项目管理流程", + "[项目管理流程", + "分级", + "立项]", + "阶段0", + "项目入口" + ], + "complexity": "simple", + "knowledgeMeta": { + "wikilinks": [ + "AI驱动内部系统开发流程_V3_总览", + "角色职责矩阵", + "阶段交付物清单" + ], + "content": "---\ntype: process_stage\ntags: [项目管理流程, 阶段0, 项目入口, 分级, 立项]\naliases: [项目入口分级, 入口分级, Gate 0, 立项分级]\nsource: AI_驱动_内部系统开发流程_V3.docx\nstatus: active\nowner: 业务主管 / 技术负责人\nupdated: 2026-05\n---\n\n# 阶段0 项目入口分级\n\n## 核心目标\n\n不是所有需求都应该进入完整开发流程。阶段0用于判断项目是否值得做，以及走轻流程还是完整流程。\n\n## 负责人\n\n- 业务主管\n- 技术负责人\n\n## 输入\n\n- 业务提出的问题或机会。\n- 现有系统痛点。\n- 业务收益、风险、范围的初步判断。\n\n## 项目分类\n\n| 类型 | 适用场景 | 流程要求 |\n|---|---|---|\n| S 类 | 小需求，单页面、小改动、无复杂数据 | 可简化阶段1和阶段2。 |\n| M 类 | 中等需求，涉及多个页面、多个角色或状态流转 | 建议走完整阶段0-4。 |\n| L 类 | 大型需求，涉及核心流程、多个部门、复杂权限、数据模型或算法 | 必须走完整流程，并强化技术预检和阶段门禁。 |\n\n## 关键动作\n\n- 判断需求是否值得做。\n- 判断项目影响范围。\n- 判断是否需要完整流程。\n- 判断是否涉及复杂数据、权限、算法、外部系统或高风险流程。\n- 初步指定业务负责人和技术负责人。\n\n## 输出/交付物\n\n- `00_项目入口分级.md`\n- 项目类型：S / M / L。\n- 是否进入完整流程的结论。\n- 初步负责人。\n- 初步范围和风险。\n\n## 检查清单\n\n- [ ] 是否确认需求要解决的真实业务问题？\n- [ ] 是否确认该需求值得做？\n- [ ] 是否确认项目类型？\n- [ ] 是否确认走轻流程还是完整流程？\n- [ ] 是否识别复杂权限、数据、算法、并发、安全或外部系统风险？\n- [ ] 是否明确业务主管和技术负责人？\n\n## 风险点\n\n- 小需求被过度流程化，降低效率。\n- 大需求被当成小需求处理，后续返工。\n- 没有识别权限、数据、安全、算法风险。\n- 没有业务负责人，需求持续漂移。\n\n## Gate 0 通过标准\n\n项目入口通过：确认值得做，确认项目类型。\n\n## 常见问题\n\n### 阶段0由谁负责？\n\n由业务主管和技术负责人共同负责。业务主管判断业务价值和业务范围，技术负责人判断技术复杂度和风险。\n\n### 小需求是否必须走完整流程？\n\n不一定。S 类小需求可以简化阶段1和阶段2，但仍应保留基本入口判断、测试和上线验收。\n\n## 关联条目\n\n- [[AI驱动内部系统开发流程_V3_总览]]\n- [[角色职责矩阵]]\n- [[阶段交付物清单]]\n", + "backlinks": [ + "article:02_项目管理流程/AI驱动内部系统开发流程_V3_总览", + "article:02_项目管理流程/README", + "article:02_项目管理流程/常见问题FAQ", + "article:02_项目管理流程/角色职责矩阵", + "article:02_项目管理流程/阶段1_业务需求完整形成" + ] + } + }, + { + "id": "article:02_项目管理流程/阶段1_业务需求完整形成", + "type": "article", + "name": "阶段1 业务需求完整形成", + "filePath": "02_项目管理流程\\阶段1_业务需求完整形成.md", + "summary": "业务侧通过 Vibe Coding 跑完整需求。阶段1追求需求完整，不追求产品完善。", + "tags": [ + "02_项目管理流程", + "VibeCoding", + "[项目管理流程", + "业务需求", + "阶段1", + "需求完整]" + ], + "complexity": "simple", + "knowledgeMeta": { + "wikilinks": [ + "阶段0_项目入口分级", + "阶段2_高保真模型与业务对象确认", + "角色职责矩阵", + "阶段交付物清单" + ], + "content": "---\ntype: process_stage\ntags: [项目管理流程, 阶段1, 业务需求, VibeCoding, 需求完整]\naliases: [业务需求完整形成, 提需求, 需求梳理, Gate 1]\nsource: AI_驱动_内部系统开发流程_V3.docx\nstatus: active\nowner: 业务主管 / 业务人员\nupdated: 2026-05\n---\n\n# 阶段1 业务需求完整形成\n\n## 核心目标\n\n业务侧通过 Vibe Coding 跑完整需求。阶段1追求需求完整，不追求产品完善。\n\n## 负责人\n\n- 业务主管\n- 业务人员\n\n## 输入\n\n- 阶段0入口分级结论。\n- 业务痛点、业务目标、现有流程。\n- 业务人员真实操作经验。\n\n## 关键动作\n\n- 梳理主流程。\n- 明确日常操作页面结构。\n- 盘点功能页面和按钮。\n- 补充分支流程。\n- 补充异常流程。\n- 使用 Vibe Coding 生成或验证需求原型。\n- 记录页面验证结果。\n\n## 输出/交付物\n\n- `01_主流程说明.md`\n- `02_日常操作页面结构.md`\n- `03_功能页面按钮盘点表.md`\n- `04_分支流程_XXX.md`\n- `05_异常流程_XXX.md`\n- `06_VibeCoding页面验证记录.md`\n\n## 检查清单\n\n- [ ] 主流程是否能从开始走到结束？\n- [ ] 日常操作入口是否清楚？\n- [ ] 页面、按钮、字段是否大致完整？\n- [ ] 分支流程是否由真实业务人员补充？\n- [ ] 异常流程是否覆盖无负责人、超时、数据缺失等情况？\n- [ ] Vibe Coding 原型是否经过业务侧走查？\n- [ ] 是否明确哪些内容只是原型，不可直接进入生产？\n\n## 风险点\n\n- 只描述主流程，漏掉分支和异常。\n- 把 Vibe Coding 页面当成可生产代码。\n- 业务主管只给方向，没有安排业务人员补充真实操作细节。\n- 页面、按钮、字段未盘点，导致阶段2和开发阶段返工。\n\n## Gate 1 通过标准\n\n需求完整通过：主流程、分支、页面、按钮、字段、状态大致完整。\n\n## 常见问题\n\n### 阶段1追求什么？\n\n追求需求完整，不追求产品完善。页面可以粗糙，但业务流程、分支、异常、按钮、字段不能漏大块。\n\n### Vibe Coding 页面能不能直接上线？\n\n不能。Vibe Coding 页面只是需求原型，不直接进入生产。\n\n## 关联条目\n\n- [[阶段0_项目入口分级]]\n- [[阶段2_高保真模型与业务对象确认]]\n- [[角色职责矩阵]]\n- [[阶段交付物清单]]\n", + "backlinks": [ + "article:02_项目管理流程/AI驱动内部系统开发流程_V3_总览", + "article:02_项目管理流程/README", + "article:02_项目管理流程/常见问题FAQ", + "article:02_项目管理流程/常见问题FAQ", + "article:02_项目管理流程/角色职责矩阵", + "article:02_项目管理流程/阶段2_高保真模型与业务对象确认" + ] + } + }, + { + "id": "article:02_项目管理流程/阶段2.5_测试提前补漏", + "type": "article", + "name": "阶段2.5 测试提前补漏", + "filePath": "02_项目管理流程\\阶段2.5_测试提前补漏.md", + "summary": "在开发前用测试视角发现需求漏洞。测试提前补漏，不只是上线前找 Bug。", + "tags": [ + "02_项目管理流程", + "[项目管理流程", + "测试", + "测试用例]", + "阶段2.5", + "需求补漏" + ], + "complexity": "simple", + "knowledgeMeta": { + "wikilinks": [ + "阶段2_高保真模型与业务对象确认", + "阶段3_研发协作与正式开发", + "项目检查清单" + ], + "content": "---\ntype: process_stage\ntags: [项目管理流程, 阶段2.5, 测试, 需求补漏, 测试用例]\naliases: [测试提前补漏, 开发前测试, Gate 2.5, 测试用例初稿]\nsource: AI_驱动_内部系统开发流程_V3.docx\nstatus: active\nowner: 测试\nupdated: 2026-05\n---\n\n# 阶段2.5 测试提前补漏\n\n## 核心目标\n\n在开发前用测试视角发现需求漏洞。测试提前补漏，不只是上线前找 Bug。\n\n## 负责人\n\n- 测试\n\n## 输入\n\n- 高保真模型。\n- 高保真模型说明。\n- 统一业务对象模型。\n- 按钮行为矩阵。\n- 项目周期与版本确认。\n\n## 关键动作\n\n- 基于高保真模型先写测试用例初稿。\n- 从主流程、分支流程、权限、异常、数据、按钮行为视角检查遗漏。\n- 标记阻塞开发的问题。\n- 将需求漏洞回流给业务、产品、前端补齐。\n- 确认阻塞问题处理后再进入正式开发。\n\n## 输出/交付物\n\n- `11_测试用例初稿与需求补漏.md`\n- 需求补漏记录。\n- 阻塞问题清单。\n- 已关闭问题清单。\n\n## 检查清单\n\n- [ ] 是否已基于高保真模型编写测试用例初稿？\n- [ ] 是否覆盖主流程？\n- [ ] 是否覆盖分支流程？\n- [ ] 是否覆盖权限？\n- [ ] 是否覆盖异常场景？\n- [ ] 是否覆盖关键数据和状态？\n- [ ] 是否覆盖按钮行为？\n- [ ] 测试发现的阻塞问题是否已关闭？\n\n## 风险点\n\n- 测试只在上线前介入，导致需求漏洞在开发后才暴露。\n- 测试用例只覆盖主流程，漏掉权限、异常、分支和数据边界。\n- 阻塞问题没有关闭就进入开发。\n\n## Gate 2.5 通过标准\n\n测试补漏：测试用例初稿发现的阻塞问题已处理。\n\n## 常见问题\n\n### 阶段2.5应该在什么时候发生？\n\n发生在高保真模型确认后、正式开发前。\n\n### 阶段2.5要产出什么？\n\n主要产出 `11_测试用例初稿与需求补漏.md`，并形成需求补漏记录、阻塞问题清单和已关闭问题清单。\n\n## 关联条目\n\n- [[阶段2_高保真模型与业务对象确认]]\n- [[阶段3_研发协作与正式开发]]\n- [[项目检查清单]]\n", + "backlinks": [ + "article:02_项目管理流程/AI驱动内部系统开发流程_V3_总览", + "article:02_项目管理流程/README", + "article:02_项目管理流程/常见问题FAQ", + "article:02_项目管理流程/常见问题FAQ", + "article:02_项目管理流程/角色职责矩阵", + "article:02_项目管理流程/阶段2_高保真模型与业务对象确认", + "article:02_项目管理流程/阶段3_研发协作与正式开发" + ] + } + }, + { + "id": "article:02_项目管理流程/阶段2_高保真模型与业务对象确认", + "type": "article", + "name": "阶段2 高保真模型与业务对象确认", + "filePath": "02_项目管理流程\\阶段2_高保真模型与业务对象确认.md", + "summary": "把完整但粗糙的需求收敛成可开发模型。阶段2追求模型高效，前端必须深度参与。", + "tags": [ + "02_项目管理流程", + "[项目管理流程", + "业务对象", + "产品]", + "前端", + "阶段2", + "高保真模型" + ], + "complexity": "simple", + "knowledgeMeta": { + "wikilinks": [ + "阶段1_业务需求完整形成", + "阶段2.5_测试提前补漏", + "../01_业务流程/业务对象字典", + "阶段交付物清单" + ], + "content": "---\ntype: process_stage\ntags: [项目管理流程, 阶段2, 高保真模型, 业务对象, 前端, 产品]\naliases: [高保真模型确认, 业务对象确认, Gate 2, 统一业务对象模型]\nsource: AI_驱动_内部系统开发流程_V3.docx\nstatus: active\nowner: 前端 / 产品经理\nupdated: 2026-05\n---\n\n# 阶段2 高保真模型与业务对象确认\n\n## 核心目标\n\n把完整但粗糙的需求收敛成可开发模型。阶段2追求模型高效，前端必须深度参与。\n\n## 负责人\n\n- 前端\n- 产品经理\n\n## 输入\n\n- 阶段1形成的主流程、页面结构、按钮盘点、分支流程、异常流程和 Vibe Coding 验证记录。\n\n## 关键动作\n\n- 将业务原型收敛为高保真模型。\n- 明确页面结构、交互、按钮行为和状态变化。\n- 确认业务对象、字段、状态和对象关系。\n- 明确 V1/V2 范围和项目周期。\n- 进行前端技术评审和技术预检。\n- 识别性能、安全、权限、并发、日志、可回滚等风险。\n\n## 输出/交付物\n\n- `07_高保真模型.html`\n- `07_高保真模型说明.md`\n- `08_项目周期与版本确认.md`\n- `09_前端技术评审.md`\n- `10_技术预检记录.md`\n- `10A_统一业务对象模型.md`\n- `10B_按钮行为矩阵.md`\n\n## 检查清单\n\n- [ ] 页面是否已经从粗糙原型收敛成可开发模型？\n- [ ] 按钮行为是否明确？\n- [ ] 业务对象、字段、状态、对象关系是否明确？\n- [ ] V1/V2 范围是否明确？\n- [ ] 是否完成前端技术评审？\n- [ ] 是否完成性能、安全、权限、并发、日志、可回滚预检？\n- [ ] 是否明确高保真模型确认后才允许正式开发？\n\n## 风险点\n\n- 前端介入太晚，导致页面、接口、数据库互相倒逼。\n- 高保真模型只画页面，没有确认业务对象和状态。\n- 没有按钮行为矩阵，开发和测试无法对齐。\n- 未提前识别性能、安全、权限、并发、日志、回滚风险。\n\n## Gate 2 通过标准\n\n高保真模型通过：页面收敛、按钮行为、业务对象、状态、V1/V2 明确。\n\n## 常见问题\n\n### 什么时候需要前端提前参与？\n\n阶段2必须由前端深度参与。若需求涉及多页面、复杂交互、权限、状态流转、数据结构或组件复用，前端应在需求收敛时提前参与。\n\n### 统一业务对象模型为什么重要？\n\n统一业务对象模型是页面、接口、数据库、测试、AI 提示词的共同基础。\n\n## 关联条目\n\n- [[阶段1_业务需求完整形成]]\n- [[阶段2.5_测试提前补漏]]\n- [[../01_业务流程/业务对象字典]]\n- [[阶段交付物清单]]\n", + "backlinks": [ + "article:02_项目管理流程/AI驱动内部系统开发流程_V3_总览", + "article:02_项目管理流程/README", + "article:02_项目管理流程/常见问题FAQ", + "article:02_项目管理流程/阶段1_业务需求完整形成", + "article:02_项目管理流程/阶段2.5_测试提前补漏" + ] + } + }, + { + "id": "article:02_项目管理流程/阶段3_研发协作与正式开发", + "type": "article", + "name": "阶段3 研发协作与正式开发", + "filePath": "02_项目管理流程\\阶段3_研发协作与正式开发.md", + "summary": "基于高保真模型进行模块化、安全、可维护开发。研发阶段以代码质量、模块化、安全性、可维护性为中心。", + "tags": [ + "02_项目管理流程", + "[项目管理流程", + "代码治理", + "安全]", + "正式开发", + "研发协作", + "阶段3" + ], + "complexity": "simple", + "knowledgeMeta": { + "wikilinks": [ + "阶段2.5_测试提前补漏", + "阶段4_测试培训上线回流", + "阶段交付物清单" + ], + "content": "---\ntype: process_stage\ntags: [项目管理流程, 阶段3, 研发协作, 正式开发, 代码治理, 安全]\naliases: [研发协作, 正式开发, Gate 3, 开发联调]\nsource: AI_驱动_内部系统开发流程_V3.docx\nstatus: active\nowner: 前端 / 后端 / 算法\nupdated: 2026-05\n---\n\n# 阶段3 研发协作与正式开发\n\n## 核心目标\n\n基于高保真模型进行模块化、安全、可维护开发。研发阶段以代码质量、模块化、安全性、可维护性为中心。\n\n## 负责人\n\n- 前端\n- 后端\n- 算法\n\n## 输入\n\n- 高保真模型。\n- 统一业务对象模型。\n- 按钮行为矩阵。\n- 测试用例初稿与需求补漏结果。\n- 技术预检记录。\n\n## 关键动作\n\n- 拆分研发任务与协作计划。\n- 进行前端、后端、算法技术实现对接。\n- 明确接口、数据库、权限、安全、日志和回滚方案。\n- 按代码治理与安全规范开发。\n- 记录开发问题与联调结果。\n- 治理 AI 生成代码，不能直接堆进生产。\n\n## 输出/交付物\n\n- `12_研发任务拆分与协作计划.md`\n- `13_技术实现对接.md`\n- `14_代码治理与安全规范.md`\n- `15_开发问题与联调记录.md`\n\n## 检查清单\n\n- [ ] 研发任务是否已拆分？\n- [ ] 前后端、数据库、权限、安全、主要流程是否联调完成？\n- [ ] 是否按统一业务对象模型设计接口和数据库？\n- [ ] 是否处理权限、安全、日志、可回滚？\n- [ ] AI 生成代码是否经过人工审查和治理？\n- [ ] 是否避免重复代码和不可维护堆叠？\n\n## 风险点\n\n- 开发直接从 Vibe Coding 原型开始，跳过高保真模型。\n- AI 生成代码未经治理直接进入生产。\n- 缺少模块边界、权限、安全、日志和回滚方案。\n- 前后端、数据库、测试使用的业务对象不一致。\n\n## Gate 3 通过标准\n\n开发联调通过：前后端、数据库、权限、安全、主要流程联调完成。\n\n## 常见问题\n\n### 阶段3如何保证模块化、安全和可维护？\n\n依赖统一业务对象模型、研发任务拆分、技术实现对接、代码治理与安全规范、开发问题与联调记录。AI 代码必须经过治理，不能直接堆进生产。\n\n## 关联条目\n\n- [[阶段2.5_测试提前补漏]]\n- [[阶段4_测试培训上线回流]]\n- [[阶段交付物清单]]\n", + "backlinks": [ + "article:02_项目管理流程/AI驱动内部系统开发流程_V3_总览", + "article:02_项目管理流程/README", + "article:02_项目管理流程/常见问题FAQ", + "article:02_项目管理流程/阶段2.5_测试提前补漏", + "article:02_项目管理流程/阶段4_测试培训上线回流" + ] + } + }, + { + "id": "article:02_项目管理流程/阶段4_测试培训上线回流", + "type": "article", + "name": "阶段4 测试培训上线回流", + "filePath": "02_项目管理流程\\阶段4_测试培训上线回流.md", + "summary": "完成测试、培训、上线验收和问题回流。测试保证系统真实可用，并帮助业务人员正确使用。", + "tags": [ + "02_项目管理流程", + "[项目管理流程", + "上线", + "回流]", + "培训", + "测试", + "阶段4" + ], + "complexity": "simple", + "knowledgeMeta": { + "wikilinks": [ + "阶段3_研发协作与正式开发", + "项目检查清单", + "阶段交付物清单" + ], + "content": "---\ntype: process_stage\ntags: [项目管理流程, 阶段4, 测试, 培训, 上线, 回流]\naliases: [测试培训上线回流, 上线验收, Gate 4]\nsource: AI_驱动_内部系统开发流程_V3.docx\nstatus: active\nowner: 测试 / 业务主管\nupdated: 2026-05\n---\n\n# 阶段4 测试培训上线回流\n\n## 核心目标\n\n完成测试、培训、上线验收和问题回流。测试保证系统真实可用，并帮助业务人员正确使用。\n\n## 负责人\n\n- 测试\n- 业务主管\n\n## 输入\n\n- 开发联调完成的系统。\n- 测试用例。\n- 高保真模型和业务对象模型。\n- 开发问题与联调记录。\n\n## 关键动作\n\n- 进行正式测试。\n- 验证主流程、分支流程、权限、异常和数据。\n- 输出正式测试报告。\n- 将测试用例转成业务操作手册或内部培训材料。\n- 组织业务确认和上线验收。\n- 记录上线问题并回流需求池。\n\n## 输出/交付物\n\n- `16_正式测试报告.md`\n- `17_内部培训手册.md`\n- `18_上线验收记录.md`\n- `19_上线问题与回流需求.md`\n\n## 检查清单\n\n- [ ] 正式测试是否通过？\n- [ ] 主流程是否验证通过？\n- [ ] 分支流程是否验证通过？\n- [ ] 权限是否验证通过？\n- [ ] 异常和数据边界是否验证通过？\n- [ ] 内部培训手册是否完成？\n- [ ] 业务主管是否完成上线确认？\n- [ ] 上线问题是否记录并回流？\n\n## 风险点\n\n- 只测功能，不测权限、异常、数据和实际操作路径。\n- 没有培训材料，业务人员不会用。\n- 上线问题没有进入回流需求池。\n- 业务主管未验收就上线。\n\n## Gate 4 通过标准\n\n上线验收通过：测试通过、业务确认、培训完成。\n\n## 常见问题\n\n### 上线前需要检查哪些事项？\n\n至少检查正式测试、主流程、分支流程、权限、异常、数据边界、内部培训手册、业务确认、上线问题回流机制。\n\n## 关联条目\n\n- [[阶段3_研发协作与正式开发]]\n- [[项目检查清单]]\n- [[阶段交付物清单]]\n", + "backlinks": [ + "article:02_项目管理流程/AI驱动内部系统开发流程_V3_总览", + "article:02_项目管理流程/README", + "article:02_项目管理流程/常见问题FAQ", + "article:02_项目管理流程/角色职责矩阵", + "article:02_项目管理流程/阶段3_研发协作与正式开发" + ] + } + }, + { + "id": "article:02_项目管理流程/阶段交付物清单", + "type": "article", + "name": "阶段交付物清单", + "filePath": "02_项目管理流程\\阶段交付物清单.md", + "summary": "| 阶段 | 交付物 | |---|---| | 阶段0 | `00_项目入口分级.md` | | 阶段1 | `01_主流程说明.md`、`02_日常操作页面结构.md`、`03_功能页面按钮盘点表.md`、`04_分支流程_XXX.md`、`05_异常流程_XXX.md`、`06_VibeCoding页面验证记录.md` | | 阶段2 | `07_高保真模型.html`、`07_高保真...", + "tags": [ + "02_项目管理流程", + "[项目管理流程", + "交付物", + "文件清单]" + ], + "complexity": "simple", + "knowledgeMeta": { + "wikilinks": [ + "AI驱动内部系统开发流程_V3_总览", + "项目检查清单" + ], + "content": "---\ntype: deliverable_index\ntags: [项目管理流程, 交付物, 文件清单]\naliases: [交付物清单, 文件结构, 产出物]\nsource: AI_驱动_内部系统开发流程_V3.docx\nstatus: active\nowner: 内部技术团队\nupdated: 2026-05\n---\n\n# 阶段交付物清单\n\n## 完整版交付物\n\n| 阶段 | 交付物 |\n|---|---|\n| 阶段0 | `00_项目入口分级.md` |\n| 阶段1 | `01_主流程说明.md`、`02_日常操作页面结构.md`、`03_功能页面按钮盘点表.md`、`04_分支流程_XXX.md`、`05_异常流程_XXX.md`、`06_VibeCoding页面验证记录.md` |\n| 阶段2 | `07_高保真模型.html`、`07_高保真模型说明.md`、`08_项目周期与版本确认.md`、`09_前端技术评审.md`、`10_技术预检记录.md`、`10A_统一业务对象模型.md`、`10B_按钮行为矩阵.md` |\n| 阶段2.5 | `11_测试用例初稿与需求补漏.md` |\n| 阶段3 | `12_研发任务拆分与协作计划.md`、`13_技术实现对接.md`、`14_代码治理与安全规范.md`、`15_开发问题与联调记录.md` |\n| 阶段4 | `16_正式测试报告.md`、`17_内部培训手册.md`、`18_上线验收记录.md`、`19_上线问题与回流需求.md` |\n| 阶段5 | `20_技术债清单.md`、`21_业务原子能力沉淀清单.md`、`22_组件库与服务复用清单.md`、`23_AI开发上下文模板更新记录.md` |\n\n## 轻量版交付物\n\n| 阶段包 | 交付物 |\n|---|---|\n| 入口 | `00_项目入口分级.md` |\n| 需求 | `01_业务需求包.md` |\n| 模型 | `02_高保真模型包.md` |\n| 预检 | `03_项目版本与技术预检.md` |\n| 测试补漏 | `04_测试用例初稿与需求补漏.md` |\n| 研发 | `05_研发协作与技术实现包.md` |\n| 治理 | `06_代码治理与安全规范.md` |\n| 上线 | `07_测试培训上线包.md` |\n| 沉淀 | `08_技术债与能力沉淀包.md` |\n\n## 关联条目\n\n- [[AI驱动内部系统开发流程_V3_总览]]\n- [[项目检查清单]]\n", + "backlinks": [ + "article:02_项目管理流程/AI驱动内部系统开发流程_V3_总览", + "article:02_项目管理流程/README", + "article:02_项目管理流程/常见问题FAQ", + "article:02_项目管理流程/阶段0_项目入口分级", + "article:02_项目管理流程/阶段1_业务需求完整形成", + "article:02_项目管理流程/阶段2_高保真模型与业务对象确认", + "article:02_项目管理流程/阶段3_研发协作与正式开发", + "article:02_项目管理流程/阶段4_测试培训上线回流", + "article:02_项目管理流程/项目检查清单" + ] + } + }, + { + "id": "article:02_项目管理流程/项目检查清单", + "type": "article", + "name": "项目检查清单", + "filePath": "02_项目管理流程\\项目检查清单.md", + "summary": "- [ ] 确认项目值得做。 - [ ] 确认项目类型：S / M / L。 - [ ] 确认走轻流程还是完整流程。 - [ ] 确认业务主管和技术负责人。", + "tags": [ + "02_项目管理流程", + "[项目管理流程", + "检查清单", + "门禁]" + ], + "complexity": "simple", + "knowledgeMeta": { + "wikilinks": [ + "AI驱动内部系统开发流程_V3_总览", + "阶段交付物清单" + ], + "content": "---\ntype: checklist\ntags: [项目管理流程, 检查清单, 门禁]\naliases: [项目门禁检查, 上线检查, 流程检查]\nsource: AI_驱动_内部系统开发流程_V3.docx\nstatus: active\nowner: 内部技术团队\nupdated: 2026-05\n---\n\n# 项目检查清单\n\n## Gate 0 项目入口\n\n- [ ] 确认项目值得做。\n- [ ] 确认项目类型：S / M / L。\n- [ ] 确认走轻流程还是完整流程。\n- [ ] 确认业务主管和技术负责人。\n\n## Gate 1 需求完整\n\n- [ ] 主流程完整。\n- [ ] 分支流程完整。\n- [ ] 页面、按钮、字段大致完整。\n- [ ] 状态大致完整。\n- [ ] Vibe Coding 页面已验证。\n\n## Gate 2 高保真模型\n\n- [ ] 页面已经收敛。\n- [ ] 按钮行为明确。\n- [ ] 业务对象明确。\n- [ ] 状态明确。\n- [ ] V1/V2 明确。\n- [ ] 性能、安全、权限、并发、日志、可回滚已预检。\n\n## Gate 2.5 测试补漏\n\n- [ ] 测试用例初稿已完成。\n- [ ] 主流程、分支、权限、异常、数据、按钮行为已检查。\n- [ ] 阻塞开发的问题已处理。\n\n## Gate 3 开发联调\n\n- [ ] 前后端联调完成。\n- [ ] 数据库联调完成。\n- [ ] 权限和安全联调完成。\n- [ ] 主要流程联调完成。\n- [ ] AI 代码已治理。\n\n## Gate 4 上线验收\n\n- [ ] 正式测试通过。\n- [ ] 业务确认完成。\n- [ ] 培训完成。\n- [ ] 上线问题回流机制明确。\n\n## Gate 5 技术债治理\n\n- [ ] 技术债已分类。\n- [ ] 必须立即处理的已处理。\n- [ ] 可延后的进入技术债池。\n- [ ] 可复用组件已沉淀。\n- [ ] 可复用后端服务已沉淀。\n- [ ] AI 开发上下文模板已更新。\n\n## 关联条目\n\n- [[AI驱动内部系统开发流程_V3_总览]]\n- [[阶段交付物清单]]\n", + "backlinks": [ + "article:02_项目管理流程/AI驱动内部系统开发流程_V3_总览", + "article:02_项目管理流程/README", + "article:02_项目管理流程/常见问题FAQ", + "article:02_项目管理流程/阶段2.5_测试提前补漏", + "article:02_项目管理流程/阶段4_测试培训上线回流", + "article:02_项目管理流程/阶段交付物清单" + ] + } + }, + { + "id": "article:03_规范与模板/上线检查模板", + "type": "article", + "name": "上线检查模板", + "filePath": "03_规范与模板\\上线检查模板.md", + "summary": "- 项目名称： - 上线版本： - 上线时间： - 负责人：", + "tags": [ + "03_规范与模板", + "[模板", + "上线检查]" + ], + "complexity": "simple", + "knowledgeMeta": { + "wikilinks": [], + "content": "---\ntype: template\ntags: [模板, 上线检查]\naliases: [上线模板, 验收模板]\nsource: manual\nstatus: active\nowner: 测试 / 业务主管\nupdated: 2026-05\n---\n\n# 上线检查模板\n\n## 基本信息\n\n- 项目名称：\n- 上线版本：\n- 上线时间：\n- 负责人：\n\n## 上线前检查\n\n- [ ] 正式测试通过。\n- [ ] 主流程通过。\n- [ ] 分支流程通过。\n- [ ] 权限通过。\n- [ ] 异常和数据边界通过。\n- [ ] 培训材料完成。\n- [ ] 业务主管确认。\n- [ ] 回滚方案明确。\n\n## 上线验收\n\n| 验收项 | 验收人 | 结果 | 备注 |\n|---|---|---|---|\n| | | | |\n\n## 上线问题回流\n\n| 问题 | 影响 | 处理优先级 | 负责人 | 状态 |\n|---|---|---|---|---|\n| | | | | |\n", + "backlinks": [ + "article:08_测试相关/README" + ] + } + }, + { + "id": "article:03_规范与模板/业务流程梳理模板", + "type": "article", + "name": "业务流程梳理模板", + "filePath": "03_规范与模板\\业务流程梳理模板.md", + "summary": "见 [[../01_业务流程/业务流程模板]]。", + "tags": [ + "03_规范与模板", + "[模板", + "业务流程]" + ], + "complexity": "simple", + "knowledgeMeta": { + "wikilinks": [ + "../01_业务流程/业务流程模板" + ], + "content": "---\ntype: template\ntags: [模板, 业务流程]\naliases: [流程梳理模板]\nsource: manual\nstatus: active\nowner: 业务主管\nupdated: 2026-05\n---\n\n# 业务流程梳理模板\n\n见 [[../01_业务流程/业务流程模板]]。\n\n使用时复制该模板，并按真实业务流程命名保存到 `01_业务流程/` 下。\n", + "backlinks": [] + } + }, + { + "id": "article:03_规范与模板/业务规则与需求补充模板", + "type": "article", + "name": "业务规则与需求补充模板", + "filePath": "03_规范与模板\\业务规则与需求补充模板.md", + "summary": "| 字段 | 内容 | |---|---| | 业务域 | | | 规则/需求名称 | | | 提出人 | | | 负责部门 | | | 适用角色 | | | 关联系统 | | | 版本 | v1.0 | | 生效状态 | draft / active / deprecated | | 生效时间 | | | 最近更新时间 | |", + "tags": [ + "03_规范与模板", + "Agent检索]", + "[模板", + "业务规则", + "需求补充" + ], + "complexity": "simple", + "knowledgeMeta": { + "wikilinks": [], + "content": "---\ntype: template\ntags: [模板, 业务规则, 需求补充, Agent检索]\naliases: [业务补充模板, 规则补充模板, 需求增量模板]\nsource: manual\nstatus: active\nowner: 业务主管 / 产品经理\nupdated: 2026-05\n---\n\n# 业务规则与需求补充模板\n\n> 使用方式：每次新增或修订业务规则时，复制本模板到 `01_业务流程/` 下，并按 `业务域_规则或需求名称_YYYYMMDD.md` 命名。\n\n## 1. 基本信息\n\n| 字段 | 内容 |\n|---|---|\n| 业务域 | |\n| 规则/需求名称 | |\n| 提出人 | |\n| 负责部门 | |\n| 适用角色 | |\n| 关联系统 | |\n| 版本 | v1.0 |\n| 生效状态 | draft / active / deprecated |\n| 生效时间 | |\n| 最近更新时间 | |\n\n## 2. 背景与目标\n\n- 当前问题：\n- 业务目标：\n- 不解决的问题：\n\n## 3. 适用范围\n\n- 适用场景：\n- 不适用场景：\n- 前置条件：\n\n## 4. 业务规则\n\n| 编号 | 规则描述 | 触发条件 | 处理结果 | 优先级 | 例外情况 |\n|---|---|---|---|---|---|\n| BR-001 | | | | 高/中/低 | |\n\n## 5. 业务流程\n\n### 5.1 主流程\n\n1. \n2. \n3. \n\n### 5.2 分支流程\n\n| 分支场景 | 判断条件 | 处理方式 | 输出结果 |\n|---|---|---|---|\n| | | | |\n\n### 5.3 异常处理\n\n| 异常场景 | 识别方式 | 处理方式 | 负责人 |\n|---|---|---|---|\n| | | | |\n\n## 6. 数据与业务对象\n\n| 业务对象 | 字段 | 字段含义 | 必填 | 来源 | 去向 |\n|---|---|---|---|---|---|\n| | | | 是/否 | | |\n\n## 7. 权限与操作\n\n| 角色 | 可见范围 | 可执行操作 | 禁止操作 |\n|---|---|---|---|\n| | | | |\n\n## 8. 验收口径\n\n| 验收点 | 通过标准 | 测试问题 |\n|---|---|---|\n| | | |\n\n## 9. Agent 检索字段\n\n### 9.1 推荐关键词\n\n- \n\n### 9.2 同义词/口语问法\n\n| 用户可能问法 | 标准术语 | 推荐命中文件 |\n|---|---|---|\n| | | |\n\n### 9.3 标准问答\n\n| 问题 | 期望答案要点 | 来源章节 |\n|---|---|---|\n| | | |\n\n## 10. 关联条目\n\n- 关联业务流程：\n- 关联项目管理阶段：\n- 关联需求说明：\n- 关联测试用例：\n\n## 11. 变更记录\n\n| 日期 | 版本 | 变更内容 | 变更人 |\n|---|---|---|---|\n| | v1.0 | 新增 | |\n", + "backlinks": [] + } + }, + { + "id": "article:03_规范与模板/会议纪要模板", + "type": "article", + "name": "会议纪要模板", + "filePath": "03_规范与模板\\会议纪要模板.md", + "summary": "- 会议主题： - 时间： - 参会人： - 记录人：", + "tags": [ + "03_规范与模板", + "[模板", + "会议纪要]" + ], + "complexity": "simple", + "knowledgeMeta": { + "wikilinks": [], + "content": "---\ntype: template\ntags: [模板, 会议纪要]\naliases: [会议记录模板]\nsource: manual\nstatus: active\nowner: 内部技术团队\nupdated: 2026-05\n---\n\n# 会议纪要模板\n\n## 基本信息\n\n- 会议主题：\n- 时间：\n- 参会人：\n- 记录人：\n\n## 结论\n\n| 编号 | 结论 | 负责人 | 截止时间 |\n|---|---|---|---|\n| | | | |\n\n## 待办\n\n| 事项 | 负责人 | 截止时间 | 状态 |\n|---|---|---|---|\n| | | | |\n\n## 风险与问题\n\n| 问题 | 影响 | 处理方式 |\n|---|---|---|\n| | | |\n", + "backlinks": [] + } + }, + { + "id": "article:03_规范与模板/需求说明模板", + "type": "article", + "name": "需求说明模板", + "filePath": "03_规范与模板\\需求说明模板.md", + "summary": "- 背景： - 要解决的问题： - 目标用户： - 预期收益：", + "tags": [ + "03_规范与模板", + "[模板", + "需求说明]" + ], + "complexity": "simple", + "knowledgeMeta": { + "wikilinks": [], + "content": "---\ntype: template\ntags: [模板, 需求说明]\naliases: [需求模板, 业务需求包]\nsource: manual\nstatus: active\nowner: 产品经理 / 业务主管\nupdated: 2026-05\n---\n\n# 需求说明模板\n\n## 背景与目标\n\n- 背景：\n- 要解决的问题：\n- 目标用户：\n- 预期收益：\n\n## 范围\n\n- V1 范围：\n- V2 范围：\n- 不包含范围：\n\n## 主流程\n\n1. \n2. \n3. \n\n## 页面与按钮\n\n| 页面 | 按钮/操作 | 行为说明 | 权限 | 备注 |\n|---|---|---|---|---|\n| | | | | |\n\n## 业务对象\n\n| 对象 | 字段 | 状态 | 说明 |\n|---|---|---|---|\n| | | | |\n\n## 分支与异常\n\n| 场景 | 处理方式 | 负责人 |\n|---|---|---|\n| | | |\n\n## 验收口径\n\n- \n", + "backlinks": [] + } + }, + { + "id": "article:04_Agent检索/关键词索引", + "type": "article", + "name": "关键词索引", + "filePath": "04_Agent检索\\关键词索引.md", + "summary": "| 关键词 | 推荐检索文件 | |---|---| | 内部系统开发流程 | `02_项目管理流程/AI驱动内部系统开发流程_V3_总览.md` | | ERP 开发流程 | `02_项目管理流程/AI驱动内部系统开发流程_V3_总览.md` | | 项目入口 | `02_项目管理流程/阶段0_项目入口分级.md` | | 项目分级 | `02_项目管理流程/阶段0_项目入口分级.md` ...", + "tags": [ + "04_Agent检索", + "[Agent", + "关键词", + "索引]" + ], + "complexity": "simple", + "knowledgeMeta": { + "wikilinks": [], + "content": "---\ntype: keyword_index\ntags: [Agent, 关键词, 索引]\naliases: [关键词映射]\nsource: manual\nstatus: active\nowner: 内部技术团队\nupdated: 2026-05\n---\n\n# 关键词索引\n\n| 关键词 | 推荐检索文件 |\n|---|---|\n| 内部系统开发流程 | `02_项目管理流程/AI驱动内部系统开发流程_V3_总览.md` |\n| ERP 开发流程 | `02_项目管理流程/AI驱动内部系统开发流程_V3_总览.md` |\n| 项目入口 | `02_项目管理流程/阶段0_项目入口分级.md` |\n| 项目分级 | `02_项目管理流程/阶段0_项目入口分级.md` |\n| S 类 / M 类 / L 类 | `02_项目管理流程/阶段0_项目入口分级.md` |\n| 业务需求 | `02_项目管理流程/阶段1_业务需求完整形成.md` |\n| Vibe Coding | `02_项目管理流程/阶段1_业务需求完整形成.md` |\n| 高保真模型 | `02_项目管理流程/阶段2_高保真模型与业务对象确认.md` |\n| 业务对象 | `02_项目管理流程/阶段2_高保真模型与业务对象确认.md`、`01_业务流程/业务对象字典.md` |\n| 按钮行为 | `02_项目管理流程/阶段2_高保真模型与业务对象确认.md` |\n| 测试提前补漏 | `02_项目管理流程/阶段2.5_测试提前补漏.md` |\n| 测试用例初稿 | `02_项目管理流程/阶段2.5_测试提前补漏.md` |\n| 正式开发 | `02_项目管理流程/阶段3_研发协作与正式开发.md` |\n| 研发协作 | `02_项目管理流程/阶段3_研发协作与正式开发.md` |\n| 代码治理 | `02_项目管理流程/阶段3_研发协作与正式开发.md`、`02_项目管理流程/AI驱动内部系统开发流程_V3_总览.md` |\n| 上线验收 | `02_项目管理流程/阶段4_测试培训上线回流.md` |\n| 内部培训 | `02_项目管理流程/阶段4_测试培训上线回流.md` |\n| 问题回流 | `02_项目管理流程/阶段4_测试培训上线回流.md` |\n| 技术债 | `02_项目管理流程/AI驱动内部系统开发流程_V3_总览.md`、`02_项目管理流程/项目检查清单.md` |\n| 门禁 | `02_项目管理流程/项目检查清单.md` |\n| 交付物 | `02_项目管理流程/阶段交付物清单.md` |\n| 谁负责 | `02_项目管理流程/角色职责矩阵.md` |\n| 业务规则补充 | `03_规范与模板/业务规则与需求补充模板.md`、`04_Agent检索/知识库持续更新与验证流程.md` |\n| 需求补充 | `03_规范与模板/业务规则与需求补充模板.md`、`03_规范与模板/需求说明模板.md` |\n| 新增业务流程 | `03_规范与模板/业务规则与需求补充模板.md`、`03_规范与模板/业务流程梳理模板.md` |\n| 检索验证 | `04_Agent检索/知识库持续更新与验证流程.md`、`01_业务流程/业务补充验证记录.md` |\n| Agent 问答验证 | `04_Agent检索/知识库持续更新与验证流程.md`、`01_业务流程/业务补充验证记录.md` |\n", + "backlinks": [ + "article:知识库使用说明", + "article:知识库使用说明", + "article:知识库使用说明" + ] + } + }, + { + "id": "article:04_Agent检索/同义词表", + "type": "article", + "name": "同义词表", + "filePath": "04_Agent检索\\同义词表.md", + "summary": "| 用户说法 | 标准术语 | 推荐检索文件 | |---|---|---| | 提需求 | 业务需求完整形成 / 项目入口分级 | `阶段1_业务需求完整形成.md`、`阶段0_项目入口分级.md` | | 立项 | 项目入口分级 | `阶段0_项目入口分级.md` | | 原型 | Vibe Coding 页面 / 高保真模型 | `阶段1_业务需求完整形成.md`、`阶段2_高保真模型...", + "tags": [ + "04_Agent检索", + "[Agent", + "同义词", + "检索]" + ], + "complexity": "simple", + "knowledgeMeta": { + "wikilinks": [], + "content": "---\ntype: synonym_table\ntags: [Agent, 同义词, 检索]\naliases: [口语映射, 术语映射]\nsource: manual\nstatus: active\nowner: 内部技术团队\nupdated: 2026-05\n---\n\n# 同义词表\n\n| 用户说法 | 标准术语 | 推荐检索文件 |\n|---|---|---|\n| 提需求 | 业务需求完整形成 / 项目入口分级 | `阶段1_业务需求完整形成.md`、`阶段0_项目入口分级.md` |\n| 立项 | 项目入口分级 | `阶段0_项目入口分级.md` |\n| 原型 | Vibe Coding 页面 / 高保真模型 | `阶段1_业务需求完整形成.md`、`阶段2_高保真模型与业务对象确认.md` |\n| 页面模型 | 高保真模型 | `阶段2_高保真模型与业务对象确认.md` |\n| 字段字典 | 业务对象模型 | `阶段2_高保真模型与业务对象确认.md`、`业务对象字典.md` |\n| 开发前测试 | 测试提前补漏 | `阶段2.5_测试提前补漏.md` |\n| 测试先看 | 测试提前补漏 | `阶段2.5_测试提前补漏.md` |\n| 开发怎么开始 | 研发协作与正式开发 | `阶段3_研发协作与正式开发.md` |\n| 上线前要做什么 | 测试培训上线回流 / Gate 4 | `阶段4_测试培训上线回流.md`、`项目检查清单.md` |\n| 谁来做 | 角色职责 | `角色职责矩阵.md` |\n| 要交什么 | 阶段交付物 | `阶段交付物清单.md` |\n| 检查点 | 阶段门禁 / 项目检查清单 | `项目检查清单.md` |\n| AI 写的代码 | AI 代码治理 | `阶段3_研发协作与正式开发.md` |\n| 加一条业务规则 | 业务规则补充 | `业务规则与需求补充模板.md`、`知识库持续更新与验证流程.md` |\n| 补需求 | 需求补充 | `业务规则与需求补充模板.md`、`需求说明模板.md` |\n| 新规则怎么写 | 业务规则与需求补充 | `业务规则与需求补充模板.md` |\n| 怎么验证能不能搜到 | Agent 检索验证 | `知识库持续更新与验证流程.md`、`业务补充验证记录.md` |\n", + "backlinks": [ + "article:知识库使用说明" + ] + } + }, + { + "id": "article:04_Agent检索/来源文件索引", + "type": "article", + "name": "来源文件索引", + "filePath": "04_Agent检索\\来源文件索引.md", + "summary": "| 来源文件 | 路径 | 用途 | 状态 | |---|---|---|---| | AI_驱动_内部系统开发流程_V3.docx | `D:\\\\AIcoding\\\\WishFulfilled\\\\知识库\\\\AI_驱动_内部系统开发流程_V3.docx` | 项目管理流程权威来源 | active |", + "tags": [ + "04_Agent检索", + "Agent]", + "[来源", + "索引" + ], + "complexity": "simple", + "knowledgeMeta": { + "wikilinks": [], + "content": "---\ntype: source_index\ntags: [来源, 索引, Agent]\naliases: [来源索引, 原始文件]\nsource: manual\nstatus: active\nowner: 内部技术团队\nupdated: 2026-05\n---\n\n# 来源文件索引\n\n## 原始来源\n\n| 来源文件 | 路径 | 用途 | 状态 |\n|---|---|---|---|\n| AI_驱动_内部系统开发流程_V3.docx | `D:\\\\AIcoding\\\\WishFulfilled\\\\知识库\\\\AI_驱动_内部系统开发流程_V3.docx` | 项目管理流程权威来源 | active |\n\n## 拆解后的知识条目\n\n| 条目 | 来源 |\n|---|---|\n| `02_项目管理流程/AI驱动内部系统开发流程_V3_总览.md` | AI_驱动_内部系统开发流程_V3.docx |\n| `02_项目管理流程/阶段0_项目入口分级.md` | AI_驱动_内部系统开发流程_V3.docx |\n| `02_项目管理流程/阶段1_业务需求完整形成.md` | AI_驱动_内部系统开发流程_V3.docx |\n| `02_项目管理流程/阶段2_高保真模型与业务对象确认.md` | AI_驱动_内部系统开发流程_V3.docx |\n| `02_项目管理流程/阶段2.5_测试提前补漏.md` | AI_驱动_内部系统开发流程_V3.docx |\n| `02_项目管理流程/阶段3_研发协作与正式开发.md` | AI_驱动_内部系统开发流程_V3.docx |\n| `02_项目管理流程/阶段4_测试培训上线回流.md` | AI_驱动_内部系统开发流程_V3.docx |\n| `02_项目管理流程/角色职责矩阵.md` | AI_驱动_内部系统开发流程_V3.docx |\n| `02_项目管理流程/阶段交付物清单.md` | AI_驱动_内部系统开发流程_V3.docx |\n| `02_项目管理流程/项目检查清单.md` | AI_驱动_内部系统开发流程_V3.docx |\n| `02_项目管理流程/常见问题FAQ.md` | AI_驱动_内部系统开发流程_V3.docx |\n\n## 业务补充来源\n\n| 来源文件 | 路径 | 用途 | 状态 |\n|---|---|---|---|\n| 需求文档目录 | `05_需求文档/` | 持续存放新增业务需求、业务规则和需求变更文档 | active |\n| 需求文档索引.md | `05_需求文档/需求文档索引.md` | 登记新增需求文档及 Agent 检索验证状态 | active |\n| 业务规则与需求补充模板.md | `03_规范与模板/业务规则与需求补充模板.md` | 新增业务规则、需求、流程的标准模板 | active |\n| 知识库持续更新与验证流程.md | `04_Agent检索/知识库持续更新与验证流程.md` | 规范新增文档后的索引同步和 Agent 检索验证 | active |\n| 业务补充验证记录.md | `01_业务流程/业务补充验证记录.md` | 记录新增业务文档是否能被 Agent 检索并回答 | active |\n| 里程碑目录 | `06_里程碑/` | 存放里程碑计划、阶段评审和项目节点材料 | active |\n| 技术文档目录 | `07_技术文档/` | 存放架构、接口、数据模型、实现方案和技术决策 | active |\n| 测试相关目录 | `08_测试相关/` | 存放测试计划、测试用例、缺陷、验收和上线检查材料 | active |\n\n## 维护要求\n\n- 从原始 docx 更新流程时，需要同步更新阶段文件、角色职责矩阵、交付物清单、检查清单、FAQ、关键词索引和同义词表。\n- 新增业务规则、需求或流程文档时，原始需求文档统一放入 `05_需求文档/`，并同步更新需求文档索引、业务规则索引、业务对象字典、关键词索引、同义词表和本来源文件索引。\n- 新增里程碑材料统一放入 `06_里程碑/`，并同步更新里程碑索引。\n- 新增技术材料统一放入 `07_技术文档/`，并同步更新技术文档索引。\n- 新增测试材料统一放入 `08_测试相关/`，并同步更新测试用例索引或对应测试记录。\n- Agent 回答项目管理流程问题时，应优先引用拆解后的 Markdown 文件。\n- Agent 回答具体业务规则和需求问题时，应优先引用 `05_需求文档/` 下的正式需求文档；稳定流程可再引用 `01_业务流程/` 下的业务流程条目。\n", + "backlinks": [ + "article:知识库使用说明", + "article:知识库使用说明", + "article:知识库使用说明", + "article:知识库使用说明" + ] + } + }, + { + "id": "article:04_Agent检索/检索说明", + "type": "article", + "name": "Agent 检索说明", + "filePath": "04_Agent检索\\检索说明.md", + "summary": "让 Agent 在回答业务流程和项目管理流程问题时，优先基于本地 Markdown 知识库检索，而不是凭空回答。", + "tags": [ + "04_Agent检索", + "[Agent", + "检索", + "规则]" + ], + "complexity": "simple", + "knowledgeMeta": { + "wikilinks": [ + "知识库持续更新与验证流程" + ], + "content": "---\ntype: agent_retrieval_guide\ntags: [Agent, 检索, 规则]\naliases: [Agent检索说明, 检索规则]\nsource: manual\nstatus: active\nowner: 内部技术团队\nupdated: 2026-05\n---\n\n# Agent 检索说明\n\n## 目标\n\n让 Agent 在回答业务流程和项目管理流程问题时，优先基于本地 Markdown 知识库检索，而不是凭空回答。\n\n## 检索优先级\n\n1. `05_需求文档/`：持续新增的业务需求、业务规则、需求变更和补充说明。\n2. `06_里程碑/`：项目节点、阶段计划、阶段评审和上线节奏。\n3. `07_技术文档/`：系统架构、数据模型、接口说明、实现方案和技术决策。\n4. `08_测试相关/`：测试计划、测试用例、缺陷记录、验收记录和上线检查。\n5. `02_项目管理流程/`：内部系统开发流程、阶段、角色、门禁、交付物、检查清单。\n6. `01_业务流程/`：真实业务流程、业务对象、业务规则。\n7. `04_Agent检索/`：关键词、同义词、来源索引、回答规则。\n8. `03_规范与模板/`：需要产出模板或文档时使用。\n\n## 问题类型与命中文件\n\n| 问题类型 | 优先文件 |\n|---|---|\n| 流程阶段 | `AI驱动内部系统开发流程_V3_总览.md`、各阶段文件 |\n| 角色职责 | `角色职责矩阵.md` |\n| 交付物 | `阶段交付物清单.md` |\n| 门禁/检查 | `项目检查清单.md` |\n| 常见问答 | `常见问题FAQ.md` |\n| 业务对象 | `01_业务流程/业务对象字典.md`、`阶段2_高保真模型与业务对象确认.md` |\n| 业务规则 | `05_需求文档/`、`05_需求文档/需求文档索引.md`、`01_业务流程/业务规则索引.md` |\n| 业务需求 | `05_需求文档/`、`05_需求文档/需求文档索引.md` |\n| 项目里程碑 | `06_里程碑/`、`06_里程碑/里程碑索引.md` |\n| 技术实现 | `07_技术文档/`、`07_技术文档/技术文档索引.md` |\n| 接口/数据模型 | `07_技术文档/接口说明模板.md`、具体接口文档、具体数据模型文档 |\n| 测试用例 | `08_测试相关/`、`08_测试相关/测试用例索引.md` |\n| 缺陷/验收/上线检查 | `08_测试相关/缺陷记录模板.md`、`08_测试相关/验收记录模板.md`、`08_测试相关/上线检查模板.md` |\n\n## 回答规则\n\n- 先回答结论，再展开依据。\n- 流程问题按“阶段、负责人、输入、动作、输出、检查点”组织。\n- 角色问题按“负责阶段、核心职责、典型产出”组织。\n- 交付物问题列出文件名。\n- 业务规则和需求问题优先检索 `05_需求文档/` 下的正式需求文档，再检索 `05_需求文档/需求文档索引.md`、`01_业务流程/业务规则索引.md`、`关键词索引.md` 和 `同义词表.md`。\n- 里程碑问题优先检索 `06_里程碑/` 和 `06_里程碑/里程碑索引.md`。\n- 技术问题优先检索 `07_技术文档/` 和 `07_技术文档/技术文档索引.md`。\n- 测试问题优先检索 `08_测试相关/` 和 `08_测试相关/测试用例索引.md`。\n- 必须注明来源文件名。\n- 如果知识库未明确记录，不要推测，应回答“知识库未明确记录”，并建议补充到具体文件。\n\n## 持续更新验证\n\n新增业务规则、需求或流程文档后，按 [[知识库持续更新与验证流程]] 执行验证。\n新增文档应使用 `03_规范与模板/业务规则与需求补充模板.md`，正式需求文档保存到 `05_需求文档/`，验证结果记录到 `05_需求文档/需求文档索引.md` 和 `01_业务流程/业务补充验证记录.md`。\n\n## 引用格式\n\n建议在回答末尾使用：\n\n> 来源：`02_项目管理流程/阶段2.5_测试提前补漏.md`\n", + "backlinks": [ + "article:欢迎", + "article:知识库使用说明", + "article:知识库使用说明" + ] + } + }, + { + "id": "article:04_Agent检索/知识库持续更新与验证流程", + "type": "article", + "name": "知识库持续更新与验证流程", + "filePath": "04_Agent检索\\知识库持续更新与验证流程.md", + "summary": "确保业务规则、业务需求和流程补充后，Agent 能通过文件检索命中新内容，并基于知识库给出可追溯回答。", + "tags": [ + "04_Agent检索", + "[Agent", + "检索", + "知识库更新", + "验证流程]" + ], + "complexity": "simple", + "knowledgeMeta": { + "wikilinks": [], + "content": "---\ntype: validation_process\ntags: [Agent, 检索, 知识库更新, 验证流程]\naliases: [知识库更新验证, Agent检索验证, 补充文档验证流程]\nsource: manual\nstatus: active\nowner: 内部技术团队 / 产品经理\nupdated: 2026-05\n---\n\n# 知识库持续更新与验证流程\n\n## 1. 目标\n\n确保业务规则、业务需求和流程补充后，Agent 能通过文件检索命中新内容，并基于知识库给出可追溯回答。\n\n## 2. 更新入口\n\n业务新增或修订时，优先使用：\n\n- `03_规范与模板/业务规则与需求补充模板.md`\n- `03_规范与模板/需求说明模板.md`\n- `03_规范与模板/业务流程梳理模板.md`\n\n补充后的正式需求文档统一保存到：\n\n- `05_需求文档/`\n\n如果文档已经沉淀为稳定业务流程，再同步拆解或引用到：\n\n- `01_业务流程/`\n\n推荐命名：\n\n```text\n业务域_规则或需求名称_YYYYMMDD.md\n```\n\n示例：\n\n```text\n采购_供应商准入规则_20260526.md\n库存_出入库审批规则_20260526.md\n销售_客户授信额度规则_20260526.md\n```\n\n## 3. 标准更新流程\n\n### 步骤 1：新增补充文档\n\n1. 复制 `业务规则与需求补充模板.md`。\n2. 保存到 `05_需求文档/`。\n3. 补全 Frontmatter：`type`、`tags`、`aliases`、`source`、`status`、`owner`、`updated`。\n4. 补全正文中的业务规则、流程、异常、权限、验收口径和 Agent 检索字段。\n\n### 步骤 2：更新索引\n\n新增业务文档后，同步更新：\n\n| 文件 | 更新内容 |\n|---|---|\n| `05_需求文档/需求文档索引.md` | 增加需求/规则名称、业务域、来源文件、状态和验证状态 |\n| `01_业务流程/业务规则索引.md` | 增加规则名称、业务域、适用场景、来源文件 |\n| `01_业务流程/业务对象字典.md` | 增加新增或变更的业务对象、字段、状态 |\n| `04_Agent检索/关键词索引.md` | 增加关键词到新文件的映射 |\n| `04_Agent检索/同义词表.md` | 增加口语问法与标准术语映射 |\n| `04_Agent检索/来源文件索引.md` | 登记新增知识条目来源 |\n\n### 步骤 3：执行文件级检查\n\n检查项：\n\n- 文件是否位于 `05_需求文档/`。\n- 文件名是否包含业务域、规则/需求名称、日期。\n- Frontmatter 是否完整。\n- 是否包含 `业务规则`、`业务流程`、`验收口径`、`Agent 检索字段`。\n- 索引文件是否已同步更新。\n\n### 步骤 4：执行关键词检索验证\n\n用新增文档中的关键词、别名、口语问法进行检索。\n\n验证标准：\n\n- 至少 1 个正式关键词能命中新文档。\n- 至少 1 个口语问法能通过 `同义词表.md` 或 `关键词索引.md` 定位到新文档。\n- 检索结果能定位到具体文件，而不是只命中模板。\n\n### 步骤 5：执行 Agent 问答验证\n\n每次新增文档至少准备 3 类问题：\n\n| 类型 | 示例 | 通过标准 |\n|---|---|---|\n| 规则类 | `供应商准入有什么条件？` | 能回答规则条件、触发条件、处理结果 |\n| 流程类 | `供应商准入流程怎么走？` | 能按步骤回答主流程和分支流程 |\n| 异常类 | `供应商资料不完整怎么办？` | 能回答异常处理方式和负责人 |\n\nAgent 回答必须满足：\n\n1. 结论来自新增文档或已索引文件。\n2. 回答末尾注明来源文件名。\n3. 如果文档未记录，明确回答“知识库未明确记录”。\n4. 不得凭经验补充没有来源的业务规则。\n\n### 步骤 6：记录验证结果\n\n在新增业务文档末尾的 `变更记录` 或单独验证记录中记录：\n\n| 日期 | 验证问题 | 是否命中 | 来源文件 | 结果 | 待补充 |\n|---|---|---|---|---|---|\n| | | 是/否 | | 通过/失败 | |\n\n## 4. 验证用例模板\n\n复制以下内容到新增业务文档的 `Agent 检索字段` 或验证记录中：\n\n```markdown\n## Agent 检索验证\n\n| 编号 | 用户问题 | 期望命中文件 | 期望答案要点 | 实际结果 | 状态 |\n|---|---|---|---|---|---|\n| Q1 | | | | | 未验证 |\n| Q2 | | | | | 未验证 |\n| Q3 | | | | | 未验证 |\n```\n\n## 5. 通过/失败判定\n\n### 通过\n\n- 新文档能被关键词检索到。\n- Agent 能引用新文档回答至少 3 个验证问题。\n- 回答没有明显幻觉。\n- 来源文件引用正确。\n\n### 失败\n\n出现任一情况视为失败：\n\n- 新文档只保存了，但没有更新关键词索引或同义词表。\n- Agent 命中了旧文件，未命中新文档。\n- Agent 回答没有引用来源。\n- Agent 编造了文档中不存在的业务规则。\n- 问题能检索到模板，但不能检索到正式业务文档。\n\n失败后处理：\n\n1. 补充 `aliases`、`tags`、推荐关键词和同义词。\n2. 更新 `关键词索引.md` 和 `同义词表.md`。\n3. 将标准问答补充到新增文档的 `Agent 检索字段`。\n4. 重新执行验证。\n\n## 6. Agent 验证提示词\n\n```text\n请只基于 D:\\AIcoding\\WishFulfilled\\知识库\\如愿知识库 下的 Markdown 文件回答。\n优先检索 05_需求文档、01_业务流程、02_项目管理流程、04_Agent检索。\n如果知识库没有明确记录，请回答“知识库未明确记录”，并说明建议补充到哪个文件。\n回答末尾必须列出来源文件。\n现在验证问题是：{用户问题}\n```\n", + "backlinks": [ + "article:04_Agent检索/检索说明", + "article:知识库使用说明" + ] + } + }, + { + "id": "article:04_Agent检索/问答提示词", + "type": "article", + "name": "问答提示词", + "filePath": "04_Agent检索\\问答提示词.md", + "summary": "你是如愿内部知识库问答 Agent。你必须优先检索本地 Markdown 知识库，再回答业务流程、项目管理流程、角色职责、交付物、检查清单和模板相关问题。", + "tags": [ + "04_Agent检索", + "[Agent", + "提示词", + "问答]" + ], + "complexity": "simple", + "knowledgeMeta": { + "wikilinks": [], + "content": "---\ntype: agent_prompt\ntags: [Agent, 提示词, 问答]\naliases: [Agent提示词, 知识库问答Prompt]\nsource: manual\nstatus: active\nowner: 内部技术团队\nupdated: 2026-05\n---\n\n# 问答提示词\n\n## 系统提示词\n\n你是如愿内部知识库问答 Agent。你必须优先检索本地 Markdown 知识库，再回答业务流程、项目管理流程、角色职责、交付物、检查清单和模板相关问题。\n\n回答要求：\n\n1. 不要凭空编造知识库未记录的信息。\n2. 优先检索 `02_项目管理流程` 和 `01_业务流程`。\n3. 流程类问题按阶段、负责人、输入、关键动作、输出、检查点回答。\n4. 角色类问题优先检索 `角色职责矩阵.md`。\n5. 交付物类问题优先检索 `阶段交付物清单.md`。\n6. 门禁和检查类问题优先检索 `项目检查清单.md`。\n7. 每次回答末尾必须注明来源文件。\n8. 如果没有明确答案，回答“知识库未明确记录”，并说明建议补充到哪个文件。\n\n## 用户问题改写规则\n\n- “提需求”可映射为“项目入口分级”或“业务需求完整形成”。\n- “开发前测试”可映射为“阶段2.5 测试提前补漏”。\n- “原型”可映射为“Vibe Coding 页面”或“高保真模型”，需结合上下文区分。\n- “上线前检查”可映射为“Gate 4 上线验收”和“项目检查清单”。\n- “谁负责”优先查角色职责矩阵。\n\n## 标准回答模板\n\n结论：\n\n要点：\n\n1. 阶段/角色：\n2. 输入：\n3. 关键动作：\n4. 输出：\n5. 检查点：\n\n来源：\n", + "backlinks": [] + } + }, + { + "id": "article:05_需求文档/20260517_USER评价业务闭环_第三步_数据流与中间对象设计_v3", + "type": "article", + "name": "USER 评价业务闭环 — 第三步：数据流与中间对象设计 v3", + "filePath": "05_需求文档\\20260517_USER评价业务闭环_第三步_数据流与中间对象设计_v3.md", + "summary": "- 文件名称：`20260517_USER评价业务闭环_第三步_数据流与中间对象设计_v3.md` - 项目路径：`C:\\XCODE\\USER` - 当前版本：`v3` - 最近更新：`2026-05-17` - 上游文档： - [工作基线 v1.2](20260517_USER评价业务闭环主流程与后续工作基线_v1.2.md) — 业务规则与额度口径 - [共用能力图与渠道专属流程 v2....", + "tags": [ + "05_需求文档" + ], + "complexity": "simple", + "knowledgeMeta": { + "wikilinks": [], + "content": "# USER 评价业务闭环 — 第三步：数据流与中间对象设计 v3\n\n## 文件信息\n\n- 文件名称：`20260517_USER评价业务闭环_第三步_数据流与中间对象设计_v3.md`\n- 项目路径：`C:\\XCODE\\USER`\n- 当前版本：`v3`\n- 最近更新：`2026-05-17`\n- 上游文档：\n - [工作基线 v1.2](20260517_USER评价业务闭环主流程与后续工作基线_v1.2.md) — 业务规则与额度口径\n - [共用能力图与渠道专属流程 v2.2](20260517_USER评价业务闭环_共用能力图与渠道专属流程_v2.2.md) — 每个节点的 查/写/状态/提醒/拦截\n- 前置版本：\n - `数据流与中间对象需求_v1`（Codex，六层架构骨架）\n - `数据流与中间对象设计_v1.1`（Codex，字段字典最全版）\n - `第三步_数据流与中间表设计_v1`（字段级展开 + 流转时序）\n - `第三步_数据流与中间表设计_v2`（吸收 Codex 优点的合并版）\n- 合并策略：以 Codex v1.1 为主骨架（保留其完整字段字典和免评对象），补入 v2 的流转时序表、写入顺序图和快照策略。\n- 文件目的：作为第三步最终主稿，后续数据库物理设计、接口设计和页面点击读写设计均以此为准。\n\n---\n\n## 1. 第三步的目标\n\n第三步不再回答\"流程怎么走\"，而是回答：\n\n1. 现有系统里已经有哪些数据可以复用。\n2. 为什么仅靠现有 `users / amazon_orders / review_plans / push_tasks / support_tickets / fraud_events` 不够。\n3. 必须新增哪些中间对象。\n4. 哪些是正式事务表，哪些只是快照，哪些可以先做成视图。\n5. 从需求形成到结果回流，数据怎样一层一层往下走。\n\n---\n\n## 2. 本步先给出的结论\n\n### 2.1 不能再只围绕单一账号建模\n\n后续所有关键判断都应围绕 **真实人**，而不是只看 JOYHUB ID / 邮箱 / 电话 / Amazon 账号 / 单次订单。JOYHUB 用户只是身份线索之一，真实人才是额度、历史、风险、跨渠道去重和客服上下文的主对象。\n\n### 2.2 现有表能承载业务记录，但承载不了跨流程判断\n\n既有表更接近\"某一模块自己的账\"，但前两步已确认的新需求需要额外的中间层：真实人跨账号归并、每次互动重判、人群入选/排除解释、额度预占与跨渠道去重、客服上下文、评价提交与展示拆分、退款比对。\n\n### 2.3 第三步最重要的是把对象分层\n\n本文件把数据对象分为六层：\n\n```\n源数据层 → 主实体层 → 桥接层 → 事件层 → 快照与决策层 → 结果回流层\n```\n\n---\n\n## 3. 数据设计原则\n\n| 原则 | 说明 |\n| --- | --- |\n| 先识别真实人，再做额度与风险 | 否则 4/4/12 规则都会被多账号绕开 |\n| 事件与快照分离 | 事件是原始事实，快照是某个时点的判断结果 |\n| 当前态与历史态分离 | 当前视图可重算，历史决策必须留痕 |\n| 计划、渠道、客服、风险状态分离 | 不能压成一个字段 |\n| 用户提交与平台展示分离 | 真实提交计额度，Amazon 展示计计划完成 |\n| 能解释\"为什么\" | 入选、排除、拦截、转人工都要能追溯 |\n| 先复用现有对象，再补最小中间层 | 不为了建模漂亮重造全部旧表 |\n| 对敏感数据分层处理 | 原值、标准化值、哈希/指纹、脱敏展示值应区分 |\n\n---\n\n# 第一部分：现有数据源分析\n\n## 4. 现有数据源盘点\n\n| 数据源 | 当前可用内容 | 主要缺口 |\n| --- | --- | --- |\n| 现有 ERP 用户管理 | 用户 ID、用户名、注册时间、最近活跃、国家、性别、邮箱、绑定产品数、标签 | 仍是账号视角，不是真实人视角 |\n| APP / 用户数据库 | JOYHUB ID、邮箱、设备号、设备型号/类型、系统版本、APP版本、绑定玩具、活跃与点击行为 | 需要设备变更轨迹和与订单/客服联动 |\n| Amazon 订单 | 订单号、ASIN、站点、购买时间、订单状态、Profile ID、收件人姓名、收件地址等 | 需要标准化姓名/地址和收件人指纹 |\n| Amazon 评价/Listing | ASIN、评分、评价数、差评数、评价缺口、展示结果 | 用户真实提交与平台展示要拆成两条事实 |\n| 推送系统 | Push 计划、素材、任务、打开、点击、回复、投诉、退订 | IM/EDM/APP 语义不同，不能只用一套粗糙 push 结果 |\n| 客服/TEL | 工单、通话、售后、答应配合、问题处理 | 需要和上下文卡、风险复检、跟进状态联动 |\n| 黑名单/诈骗资料 | 黑名单、诈骗事件、双重退款、强弱关联 | 需要把风险信号与确认案件拆开 |\n| OA 返款/Amazon 退款 | 内部返款与 Amazon 退款 | 缺统一比对对象 |\n| JOYCOLLAB | KOC/KOL、内容、Code、点击、订单、转化、佣金 | 需要和 USER 计划/ASIN 结果打通 |\n\n### 4.1 Amazon 订单字段明细（结合表头.xlsx）\n\n| 字段 | 主要用途 | 涉密 |\n| --- | --- | --- |\n| 订单号 | 订单核验、真实人关联、退款比对 | 是 |\n| 订单状态 | 判断是否撤销、退款、退货、换货 | - |\n| 买家姓名 / 买家邮箱 | 身份关联 | 是 |\n| 收件人 / 电话 | 真实人归并、风险判断 | 是 |\n| 地址 / 城市 / 州 / 邮编 | 收件人归并、同址异名识别 | 是 |\n| ASIN / MSKU / SKU / 品名 / 标题 | 产品匹配、计划归属 | - |\n| 订购日期 / 发货时间 / 结算时间 | 时序判断 | - |\n| 数量 / 单价 / 订单总金额 / 销售额 | 交易画像 | 是 |\n| 是否退款 / 退款总金额 | 双重退款检测 | 是 |\n| 请求评论状态 | 评价缺口判断 | - |\n| 店铺 / 国家 / 销售渠道 | 站点匹配 | - |\n| Order Item ID | 订单行级关联 | - |\n\n### 4.2 订单侧必须补的派生字段\n\n| 字段 | 说明 |\n| --- | --- |\n| `recipient_name_normalized` | 标准化后的收件人姓名 |\n| `recipient_address_normalized` | 标准化后的地址 |\n| `recipient_fingerprint` | 由标准化姓名+地址生成的稳定指纹 |\n| `address_fingerprint` | 仅地址指纹，用于识别同址异名 |\n\n---\n\n## 5. 全局数据流\n\n```mermaid\nflowchart LR\n subgraph S[\"源数据层\"]\n S1[\"现有ERP用户/标签/身份\"", + "backlinks": [] + } + }, + { + "id": "article:05_需求文档/README", + "type": "article", + "name": "需求文档", + "filePath": "05_需求文档\\README.md", + "summary": "本目录用于集中存放后续持续补充的业务需求文档、业务规则文档、流程补充文档和需求变更文档。", + "tags": [ + "05_需求文档", + "Agent]", + "[需求文档", + "知识库更新", + "需求收集" + ], + "complexity": "simple", + "knowledgeMeta": { + "wikilinks": [], + "content": "---\ntype: requirement_inbox\ntags: [需求文档, 需求收集, 知识库更新, Agent]\naliases: [需求文档目录, 需求收集目录, 需求入口]\nsource: manual\nstatus: active\nowner: 产品经理 / 业务主管\nupdated: 2026-05\n---\n\n# 需求文档\n\n本目录用于集中存放后续持续补充的业务需求文档、业务规则文档、流程补充文档和需求变更文档。\n\n## 使用方式\n\n1. 所有新增需求文档优先放入本目录。\n2. 建议使用 `03_规范与模板/需求说明模板.md` 或 `03_规范与模板/业务规则与需求补充模板.md` 创建文档。\n3. 文档确认有效后，同步更新业务流程索引和 Agent 检索索引。\n4. Agent 回答具体业务需求时，应优先检索本目录。\n\n## 推荐命名\n\n```text\n业务域_需求或规则名称_YYYYMMDD.md\n```\n\n示例：\n\n```text\n采购_供应商准入规则_20260526.md\n库存_出入库审批规则_20260526.md\n销售_客户授信额度需求_20260526.md\n```\n\n## 文档状态\n\n每个需求文档建议在 Frontmatter 中维护 `status`：\n\n| 状态 | 含义 |\n|---|---|\n| draft | 草稿，尚未确认 |\n| reviewing | 评审中 |\n| active | 已确认，可作为 Agent 回答依据 |\n| deprecated | 已废弃，仅归档参考 |\n\n## 必填内容\n\n每个需求文档至少包含：\n\n- 需求背景\n- 适用范围\n- 涉及角色\n- 业务规则\n- 业务流程\n- 异常处理\n- 权限要求\n- 验收口径\n- Agent 检索字段\n- 变更记录\n\n## 索引维护\n\n新增或修改需求文档后，需要同步更新：\n\n- `05_需求文档/需求文档索引.md`\n- `01_业务流程/业务规则索引.md`\n- `01_业务流程/业务对象字典.md`\n- `04_Agent检索/关键词索引.md`\n- `04_Agent检索/同义词表.md`\n- `04_Agent检索/来源文件索引.md`\n\n## 验证流程\n\n新增需求文档后，按 `04_Agent检索/知识库持续更新与验证流程.md` 执行验证，并将验证结果记录到：\n\n- `05_需求文档/需求文档索引.md`\n- `01_业务流程/业务补充验证记录.md`\n", + "backlinks": [ + "article:欢迎", + "article:知识库使用说明" + ] + } + }, + { + "id": "article:05_需求文档/需求文档索引", + "type": "article", + "name": "需求文档索引", + "filePath": "05_需求文档\\需求文档索引.md", + "summary": "本文件记录 `05_需求文档/` 下所有正式需求文档，供人工维护和 Agent 检索定位。", + "tags": [ + "05_需求文档", + "Agent检索]", + "[需求文档", + "索引" + ], + "complexity": "simple", + "knowledgeMeta": { + "wikilinks": [], + "content": "---\ntype: requirement_index\ntags: [需求文档, 索引, Agent检索]\naliases: [需求索引, 需求文档清单, 需求清单]\nsource: manual\nstatus: active\nowner: 产品经理 / 业务主管\nupdated: 2026-05\n---\n\n# 需求文档索引\n\n本文件记录 `05_需求文档/` 下所有正式需求文档，供人工维护和 Agent 检索定位。\n\n## 需求文档清单\n\n| 编号 | 业务域 | 需求/规则名称 | 文件 | 状态 | 负责人 | 更新时间 | 验证状态 |\n|---|---|---|---|---|---|---|---|\n| | | | | | | | 未验证 |\n\n## Agent 检索关键词\n\n| 关键词/问法 | 标准术语 | 命中文件 | 答案要点 |\n|---|---|---|---|\n| | | | |\n\n## 维护规则\n\n1. 新增需求文档后，必须在“需求文档清单”新增一行。\n2. 每个需求文档至少维护 3 个可检索问法。\n3. `状态=active` 的文档可作为 Agent 回答依据。\n4. `status=draft/reviewing` 的文档只能作为草稿参考，Agent 回答时需说明尚未确认。\n5. `status=deprecated` 的文档不得作为当前规则依据，只能说明历史背景。\n\n## 验证记录摘要\n\n| 日期 | 文件 | 验证问题数 | 通过数 | 失败数 | 结论 |\n|---|---|---:|---:|---:|---|\n| | | | | | |\n", + "backlinks": [ + "article:知识库使用说明", + "article:知识库使用说明" + ] + } + }, + { + "id": "article:06_里程碑/README", + "type": "article", + "name": "里程碑", + "filePath": "06_里程碑\\README.md", + "summary": "本目录用于存放项目阶段计划、里程碑节点、阶段评审记录和上线节奏说明。", + "tags": [ + "06_里程碑", + "[里程碑", + "知识库]", + "项目管理" + ], + "complexity": "moderate", + "knowledgeMeta": { + "wikilinks": [ + "里程碑索引", + "阶段计划模板", + "里程碑评审记录", + "../05_需求文档/README", + "../02_项目管理流程/AI驱动内部系统开发流程_V3_总览", + "../08_测试相关/README" + ], + "content": "---\ntype: milestone_home\ntags: [里程碑, 项目管理, 知识库]\naliases: [里程碑入口, 项目里程碑]\nsource: manual\nstatus: active\nowner: 项目经理\nupdated: 2026-05\n---\n\n# 里程碑\n\n本目录用于存放项目阶段计划、里程碑节点、阶段评审记录和上线节奏说明。\n\n## 二级入口\n\n- [[里程碑索引]]\n- [[阶段计划模板]]\n- [[里程碑评审记录]]\n\n## 存放内容\n\n- 项目启动节点\n- 需求评审节点\n- 原型/高保真确认节点\n- 开发启动节点\n- 测试准入节点\n- 上线检查节点\n- 复盘回流节点\n\n## 命名建议\n\n```text\n项目名_里程碑计划_YYYYMMDD.md\n项目名_阶段评审记录_YYYYMMDD.md\n```\n\n## 关联目录\n\n- 需求依据：[[../05_需求文档/README|需求文档]]\n- 流程依据：[[../02_项目管理流程/AI驱动内部系统开发流程_V3_总览|项目管理流程]]\n- 测试准入：[[../08_测试相关/README|测试相关]]\n", + "backlinks": [ + "article:欢迎", + "article:知识库使用说明" + ] + } + }, + { + "id": "article:06_里程碑/里程碑索引", + "type": "article", + "name": "里程碑索引", + "filePath": "06_里程碑\\里程碑索引.md", + "summary": "| 项目 | 里程碑名称 | 文件 | 阶段 | 负责人 | 计划时间 | 当前状态 | |---|---|---|---|---|---|---| | | | | | | | |", + "tags": [ + "06_里程碑", + "Agent检索]", + "[里程碑", + "索引" + ], + "complexity": "simple", + "knowledgeMeta": { + "wikilinks": [], + "content": "---\ntype: milestone_index\ntags: [里程碑, 索引, Agent检索]\naliases: [里程碑清单, 项目节点索引]\nsource: manual\nstatus: active\nowner: 项目经理\nupdated: 2026-05\n---\n\n# 里程碑索引\n\n## 里程碑文档清单\n\n| 项目 | 里程碑名称 | 文件 | 阶段 | 负责人 | 计划时间 | 当前状态 |\n|---|---|---|---|---|---|---|\n| | | | | | | |\n\n## Agent 检索关键词\n\n| 问法 | 标准术语 | 命中文件 | 答案要点 |\n|---|---|---|---|\n| | | | |\n\n## 维护规则\n\n- 新增里程碑计划后，在本索引登记。\n- 每个里程碑应关联至少一个需求文档或项目管理阶段。\n- Agent 回答项目进度、节点、准入问题时，应引用本索引或具体里程碑文件。\n", + "backlinks": [ + "article:06_里程碑/README", + "article:知识库使用说明" + ] + } + }, + { + "id": "article:06_里程碑/里程碑评审记录", + "type": "article", + "name": "里程碑评审记录", + "filePath": "06_里程碑\\里程碑评审记录.md", + "summary": "| 日期 | 项目 | 阶段 | 评审结论 | 遗留问题 | 负责人 | 后续动作 | |---|---|---|---|---|---|---| | | | | | | | |", + "tags": [ + "06_里程碑", + "[里程碑", + "记录]", + "评审" + ], + "complexity": "simple", + "knowledgeMeta": { + "wikilinks": [], + "content": "---\ntype: milestone_review_log\ntags: [里程碑, 评审, 记录]\naliases: [阶段评审记录, 里程碑评审]\nsource: manual\nstatus: active\nowner: 项目经理\nupdated: 2026-05\n---\n\n# 里程碑评审记录\n\n| 日期 | 项目 | 阶段 | 评审结论 | 遗留问题 | 负责人 | 后续动作 |\n|---|---|---|---|---|---|---|\n| | | | | | | |\n", + "backlinks": [ + "article:06_里程碑/README" + ] + } + }, + { + "id": "article:06_里程碑/阶段计划模板", + "type": "article", + "name": "阶段计划模板", + "filePath": "06_里程碑\\阶段计划模板.md", + "summary": "| 项目 | 内容 | |---|---| | 项目名称 | | | 关联需求 | | | 当前阶段 | | | 负责人 | | | 计划开始 | | | 计划结束 | |", + "tags": [ + "06_里程碑", + "[里程碑", + "模板]", + "阶段计划" + ], + "complexity": "simple", + "knowledgeMeta": { + "wikilinks": [], + "content": "---\ntype: milestone_template\ntags: [里程碑, 阶段计划, 模板]\naliases: [阶段计划, 里程碑模板]\nsource: manual\nstatus: active\nowner: 项目经理\nupdated: 2026-05\n---\n\n# 阶段计划模板\n\n## 基本信息\n\n| 项目 | 内容 |\n|---|---|\n| 项目名称 | |\n| 关联需求 | |\n| 当前阶段 | |\n| 负责人 | |\n| 计划开始 | |\n| 计划结束 | |\n\n## 阶段目标\n\n\n## 输入材料\n\n- 需求文档：\n- 业务流程：\n- 技术文档：\n- 测试材料：\n\n## 关键任务\n\n| 任务 | 负责人 | 截止时间 | 输出物 | 状态 |\n|---|---|---|---|---|\n| | | | | |\n\n## 阶段交付物\n\n\n## 准入/准出条件\n\n\n## 风险与阻塞\n\n\n## Agent 检索字段\n\n- 关键词：\n- 同义词：\n- 典型问法：\n", + "backlinks": [ + "article:06_里程碑/README" + ] + } + }, + { + "id": "article:07_技术文档/README", + "type": "article", + "name": "技术文档", + "filePath": "07_技术文档\\README.md", + "summary": "本目录用于存放系统架构、数据模型、接口说明、实现方案、部署说明和技术决策记录。", + "tags": [ + "07_技术文档", + "[技术文档", + "开发", + "架构", + "知识库]" + ], + "complexity": "moderate", + "knowledgeMeta": { + "wikilinks": [ + "技术文档索引", + "系统架构说明模板", + "接口说明模板", + "技术决策记录", + "../05_需求文档/README", + "../08_测试相关/README", + "../06_里程碑/README" + ], + "content": "---\ntype: technical_docs_home\ntags: [技术文档, 架构, 开发, 知识库]\naliases: [技术文档入口, 技术资料]\nsource: manual\nstatus: active\nowner: 技术负责人\nupdated: 2026-05\n---\n\n# 技术文档\n\n本目录用于存放系统架构、数据模型、接口说明、实现方案、部署说明和技术决策记录。\n\n## 二级入口\n\n- [[技术文档索引]]\n- [[系统架构说明模板]]\n- [[接口说明模板]]\n- [[技术决策记录]]\n\n## 存放内容\n\n- 系统架构说明\n- 模块设计说明\n- 数据表/业务对象设计\n- API 接口说明\n- 权限与安全设计\n- 部署与配置说明\n- 技术决策记录\n\n## 命名建议\n\n```text\n系统或模块_技术方案_YYYYMMDD.md\n系统或模块_接口说明_YYYYMMDD.md\n系统或模块_数据模型_YYYYMMDD.md\n```\n\n## 关联目录\n\n- 需求依据：[[../05_需求文档/README|需求文档]]\n- 测试依据：[[../08_测试相关/README|测试相关]]\n- 里程碑：[[../06_里程碑/README|里程碑]]\n", + "backlinks": [ + "article:欢迎", + "article:知识库使用说明" + ] + } + }, + { + "id": "article:07_技术文档/技术决策记录", + "type": "article", + "name": "技术决策记录", + "filePath": "07_技术文档\\技术决策记录.md", + "summary": "| 日期 | 决策主题 | 背景 | 决策结论 | 影响范围 | 关联需求/技术文档 | |---|---|---|---|---|---| | | | | | | |", + "tags": [ + "07_技术文档", + "ADR]", + "[技术文档", + "技术决策" + ], + "complexity": "simple", + "knowledgeMeta": { + "wikilinks": [], + "content": "---\ntype: adr_log\ntags: [技术文档, 技术决策, ADR]\naliases: [技术决策, ADR]\nsource: manual\nstatus: active\nowner: 技术负责人\nupdated: 2026-05\n---\n\n# 技术决策记录\n\n| 日期 | 决策主题 | 背景 | 决策结论 | 影响范围 | 关联需求/技术文档 |\n|---|---|---|---|---|---|\n| | | | | | |\n", + "backlinks": [ + "article:07_技术文档/README" + ] + } + }, + { + "id": "article:07_技术文档/技术文档索引", + "type": "article", + "name": "技术文档索引", + "filePath": "07_技术文档\\技术文档索引.md", + "summary": "| 模块/系统 | 文档类型 | 文件 | 关联需求 | 负责人 | 更新时间 | 状态 | |---|---|---|---|---|---|---| | | | | | | | |", + "tags": [ + "07_技术文档", + "Agent检索]", + "[技术文档", + "索引" + ], + "complexity": "simple", + "knowledgeMeta": { + "wikilinks": [], + "content": "---\ntype: technical_docs_index\ntags: [技术文档, 索引, Agent检索]\naliases: [技术索引, 技术资料清单]\nsource: manual\nstatus: active\nowner: 技术负责人\nupdated: 2026-05\n---\n\n# 技术文档索引\n\n## 技术文档清单\n\n| 模块/系统 | 文档类型 | 文件 | 关联需求 | 负责人 | 更新时间 | 状态 |\n|---|---|---|---|---|---|---|\n| | | | | | | |\n\n## Agent 检索关键词\n\n| 问法 | 标准术语 | 命中文件 | 答案要点 |\n|---|---|---|---|\n| | | | |\n\n## 维护规则\n\n- 新增技术方案、接口说明、数据模型后，在本索引登记。\n- 技术文档必须关联需求文档或业务流程。\n- Agent 回答技术实现、接口、数据结构问题时，应优先检索本目录。\n", + "backlinks": [ + "article:07_技术文档/README", + "article:知识库使用说明", + "article:知识库使用说明" + ] + } + }, + { + "id": "article:07_技术文档/接口说明模板", + "type": "article", + "name": "接口说明模板", + "filePath": "07_技术文档\\接口说明模板.md", + "summary": "| 项目 | 内容 | |---|---| | 接口名称 | | | 所属模块 | | | 关联需求 | | | 负责人 | | | 状态 | draft |", + "tags": [ + "07_技术文档", + "[技术文档", + "接口", + "模板]" + ], + "complexity": "simple", + "knowledgeMeta": { + "wikilinks": [], + "content": "---\ntype: api_template\ntags: [技术文档, 接口, 模板]\naliases: [接口模板, API说明模板]\nsource: manual\nstatus: active\nowner: 技术负责人\nupdated: 2026-05\n---\n\n# 接口说明模板\n\n## 基本信息\n\n| 项目 | 内容 |\n|---|---|\n| 接口名称 | |\n| 所属模块 | |\n| 关联需求 | |\n| 负责人 | |\n| 状态 | draft |\n\n## 接口用途\n\n\n## 请求说明\n\n| 字段 | 类型 | 必填 | 说明 | 示例 |\n|---|---|---|---|---|\n| | | | | |\n\n## 响应说明\n\n| 字段 | 类型 | 说明 | 示例 |\n|---|---|---|---|\n| | | | |\n\n## 业务规则\n\n\n## 异常码\n\n| 异常码 | 含义 | 处理方式 |\n|---|---|---|\n| | | |\n\n## Agent 检索字段\n\n- 关键词：\n- 同义词：\n- 典型问法：\n", + "backlinks": [ + "article:07_技术文档/README" + ] + } + }, + { + "id": "article:07_技术文档/系统架构说明模板", + "type": "article", + "name": "系统架构说明模板", + "filePath": "07_技术文档\\系统架构说明模板.md", + "summary": "| 项目 | 内容 | |---|---| | 系统/模块 | | | 关联需求 | | | 负责人 | | | 状态 | draft |", + "tags": [ + "07_技术文档", + "[技术文档", + "架构", + "模板]" + ], + "complexity": "simple", + "knowledgeMeta": { + "wikilinks": [], + "content": "---\ntype: architecture_template\ntags: [技术文档, 架构, 模板]\naliases: [架构说明模板]\nsource: manual\nstatus: active\nowner: 技术负责人\nupdated: 2026-05\n---\n\n# 系统架构说明模板\n\n## 基本信息\n\n| 项目 | 内容 |\n|---|---|\n| 系统/模块 | |\n| 关联需求 | |\n| 负责人 | |\n| 状态 | draft |\n\n## 背景与目标\n\n\n## 架构说明\n\n\n## 模块划分\n\n| 模块 | 职责 | 输入 | 输出 | 依赖 |\n|---|---|---|---|---|\n| | | | | |\n\n## 数据模型\n\n\n## 接口关系\n\n\n## 权限与安全\n\n\n## 异常与边界\n\n\n## 部署与配置\n\n\n## Agent 检索字段\n\n- 关键词：\n- 同义词：\n- 典型问法：\n", + "backlinks": [ + "article:07_技术文档/README" + ] + } + }, + { + "id": "article:08_测试相关/README", + "type": "article", + "name": "测试相关", + "filePath": "08_测试相关\\README.md", + "summary": "本目录用于存放测试计划、测试用例、测试报告、缺陷记录、验收记录和上线检查材料。", + "tags": [ + "08_测试相关", + "[测试", + "测试用例", + "知识库]", + "验收" + ], + "complexity": "moderate", + "knowledgeMeta": { + "wikilinks": [ + "测试用例索引", + "测试用例模板", + "测试计划模板", + "缺陷记录模板", + "验收记录模板", + "上线检查模板", + "../05_需求文档/README", + "../07_技术文档/README", + "../06_里程碑/README", + "../02_项目管理流程/阶段2.5_测试提前补漏", + "../02_项目管理流程/阶段4_测试培训上线回流" + ], + "content": "---\ntype: testing_home\ntags: [测试, 测试用例, 验收, 知识库]\naliases: [测试相关入口, 测试文档]\nsource: manual\nstatus: active\nowner: 测试负责人\nupdated: 2026-05\n---\n\n# 测试相关\n\n本目录用于存放测试计划、测试用例、测试报告、缺陷记录、验收记录和上线检查材料。\n\n## 二级入口\n\n- [[测试用例索引]]\n- [[测试用例模板]]\n- [[测试计划模板]]\n- [[缺陷记录模板]]\n- [[验收记录模板]]\n- [[上线检查模板]]\n\n## 存放内容\n\n- 测试计划\n- 测试用例\n- 测试执行记录\n- 缺陷记录\n- 验收记录\n- 上线检查记录\n- 回归测试说明\n\n## 命名建议\n\n```text\n项目或模块_测试用例_YYYYMMDD.md\n项目或模块_测试计划_YYYYMMDD.md\n项目或模块_缺陷记录_YYYYMMDD.md\n项目或模块_验收记录_YYYYMMDD.md\n```\n\n## 关联目录\n\n- 需求依据：[[../05_需求文档/README|需求文档]]\n- 技术依据：[[../07_技术文档/README|技术文档]]\n- 里程碑依据：[[../06_里程碑/README|里程碑]]\n- 流程依据：[[../02_项目管理流程/阶段2.5_测试提前补漏|阶段2.5 测试提前补漏]]、[[../02_项目管理流程/阶段4_测试培训上线回流|阶段4 测试培训上线回流]]\n", + "backlinks": [ + "article:欢迎", + "article:知识库使用说明" + ] + } + }, + { + "id": "article:08_测试相关/上线检查模板", + "type": "article", + "name": "上线检查模板", + "filePath": "08_测试相关\\上线检查模板.md", + "summary": "| 项目 | 内容 | |---|---| | 项目/模块 | | | 关联需求 | | | 关联里程碑 | | | 负责人 | | | 检查日期 | |", + "tags": [ + "08_测试相关", + "[上线检查", + "模板]", + "测试" + ], + "complexity": "simple", + "knowledgeMeta": { + "wikilinks": [], + "content": "---\ntype: go_live_checklist_template\ntags: [上线检查, 测试, 模板]\naliases: [上线检查, 发布检查]\nsource: manual\nstatus: active\nowner: 测试负责人 / 项目经理\nupdated: 2026-05\n---\n\n# 上线检查模板\n\n## 基本信息\n\n| 项目 | 内容 |\n|---|---|\n| 项目/模块 | |\n| 关联需求 | |\n| 关联里程碑 | |\n| 负责人 | |\n| 检查日期 | |\n\n## 上线前检查项\n\n| 检查项 | 负责人 | 结果 | 备注 |\n|---|---|---|---|\n| 需求已确认 | | | |\n| 测试用例已执行 | | | |\n| P0/P1 缺陷已关闭 | | | |\n| 用户培训已完成 | | | |\n| 回滚方案已确认 | | | |\n| 数据备份已确认 | | | |\n\n## 上线结论\n\n\n## 回滚条件\n\n\n## Agent 检索字段\n\n- 关键词：\n- 同义词：\n- 典型问法：\n", + "backlinks": [] + } + }, + { + "id": "article:08_测试相关/测试用例模板", + "type": "article", + "name": "测试用例模板", + "filePath": "08_测试相关\\测试用例模板.md", + "summary": "| 项目 | 内容 | |---|---| | 项目/模块 | | | 关联需求 | | | 关联技术文档 | | | 测试负责人 | | | 状态 | draft |", + "tags": [ + "08_测试相关", + "[测试用例", + "模板]", + "测试" + ], + "complexity": "simple", + "knowledgeMeta": { + "wikilinks": [], + "content": "---\ntype: test_case_template\ntags: [测试用例, 测试, 模板]\naliases: [用例模板, 测试用例]\nsource: manual\nstatus: active\nowner: 测试负责人\nupdated: 2026-05\n---\n\n# 测试用例模板\n\n## 基本信息\n\n| 项目 | 内容 |\n|---|---|\n| 项目/模块 | |\n| 关联需求 | |\n| 关联技术文档 | |\n| 测试负责人 | |\n| 状态 | draft |\n\n## 测试范围\n\n\n## 前置条件\n\n\n## 测试用例\n\n| 用例编号 | 场景 | 前置条件 | 操作步骤 | 预期结果 | 优先级 | 状态 |\n|---|---|---|---|---|---|---|\n| TC-001 | | | | | P1 | 未执行 |\n\n## 边界与异常场景\n\n\n## 验收口径\n\n\n## Agent 检索字段\n\n- 关键词：\n- 同义词：\n- 典型问法：\n", + "backlinks": [ + "article:08_测试相关/README" + ] + } + }, + { + "id": "article:08_测试相关/测试用例索引", + "type": "article", + "name": "测试用例索引", + "filePath": "08_测试相关\\测试用例索引.md", + "summary": "| 编号 | 项目/模块 | 用例集名称 | 文件 | 关联需求 | 关联技术文档 | 负责人 | 状态 | 更新时间 | |---|---|---|---|---|---|---|---|---| | | | | | | | | 未验证 | |", + "tags": [ + "08_测试相关", + "Agent检索]", + "[测试用例", + "测试", + "索引" + ], + "complexity": "simple", + "knowledgeMeta": { + "wikilinks": [], + "content": "---\ntype: test_case_index\ntags: [测试用例, 测试, 索引, Agent检索]\naliases: [测试用例清单, 用例索引]\nsource: manual\nstatus: active\nowner: 测试负责人\nupdated: 2026-05\n---\n\n# 测试用例索引\n\n## 测试用例清单\n\n| 编号 | 项目/模块 | 用例集名称 | 文件 | 关联需求 | 关联技术文档 | 负责人 | 状态 | 更新时间 |\n|---|---|---|---|---|---|---|---|---|\n| | | | | | | | 未验证 | |\n\n## Agent 检索关键词\n\n| 问法 | 标准术语 | 命中文件 | 答案要点 |\n|---|---|---|---|\n| | | | |\n\n## 维护规则\n\n- 新增测试用例后，必须在本索引登记。\n- 每个测试用例文件必须关联至少一个需求文档。\n- 若测试用例依赖接口、数据模型或技术方案，应关联技术文档。\n- Agent 回答测试范围、验收口径、缺陷复现问题时，应优先检索本目录。\n", + "backlinks": [ + "article:08_测试相关/README", + "article:知识库使用说明", + "article:知识库使用说明" + ] + } + }, + { + "id": "article:08_测试相关/测试计划模板", + "type": "article", + "name": "测试计划模板", + "filePath": "08_测试相关\\测试计划模板.md", + "summary": "| 项目 | 内容 | |---|---| | 项目/模块 | | | 关联需求 | | | 关联里程碑 | | | 测试负责人 | | | 计划周期 | |", + "tags": [ + "08_测试相关", + "[测试计划", + "模板]", + "测试" + ], + "complexity": "simple", + "knowledgeMeta": { + "wikilinks": [], + "content": "---\ntype: test_plan_template\ntags: [测试计划, 测试, 模板]\naliases: [测试计划模板]\nsource: manual\nstatus: active\nowner: 测试负责人\nupdated: 2026-05\n---\n\n# 测试计划模板\n\n## 基本信息\n\n| 项目 | 内容 |\n|---|---|\n| 项目/模块 | |\n| 关联需求 | |\n| 关联里程碑 | |\n| 测试负责人 | |\n| 计划周期 | |\n\n## 测试目标\n\n\n## 测试范围\n\n\n## 不在范围内\n\n\n## 测试资源\n\n\n## 测试安排\n\n| 阶段 | 时间 | 负责人 | 输出物 |\n|---|---|---|---|\n| | | | |\n\n## 准入条件\n\n\n## 准出条件\n\n\n## 风险\n\n\n## Agent 检索字段\n\n- 关键词：\n- 同义词：\n- 典型问法：\n", + "backlinks": [ + "article:08_测试相关/README" + ] + } + }, + { + "id": "article:08_测试相关/缺陷记录模板", + "type": "article", + "name": "缺陷记录模板", + "filePath": "08_测试相关\\缺陷记录模板.md", + "summary": "| 项目 | 内容 | |---|---| | 缺陷编号 | BUG- | | 项目/模块 | | | 关联需求 | | | 关联用例 | | | 严重级别 | | | 当前状态 | open | | 负责人 | |", + "tags": [ + "08_测试相关", + "[缺陷", + "模板]", + "测试" + ], + "complexity": "simple", + "knowledgeMeta": { + "wikilinks": [], + "content": "---\ntype: defect_template\ntags: [缺陷, 测试, 模板]\naliases: [Bug记录模板, 缺陷记录]\nsource: manual\nstatus: active\nowner: 测试负责人\nupdated: 2026-05\n---\n\n# 缺陷记录模板\n\n## 基本信息\n\n| 项目 | 内容 |\n|---|---|\n| 缺陷编号 | BUG- |\n| 项目/模块 | |\n| 关联需求 | |\n| 关联用例 | |\n| 严重级别 | |\n| 当前状态 | open |\n| 负责人 | |\n\n## 问题描述\n\n\n## 复现步骤\n\n1. \n2. \n3. \n\n## 实际结果\n\n\n## 预期结果\n\n\n## 影响范围\n\n\n## 修复结论\n\n\n## 回归验证\n\n\n## Agent 检索字段\n\n- 关键词：\n- 同义词：\n- 典型问法：\n", + "backlinks": [ + "article:08_测试相关/README" + ] + } + }, + { + "id": "article:08_测试相关/验收记录模板", + "type": "article", + "name": "验收记录模板", + "filePath": "08_测试相关\\验收记录模板.md", + "summary": "| 项目 | 内容 | |---|---| | 项目/模块 | | | 关联需求 | | | 关联测试用例 | | | 验收负责人 | | | 验收日期 | | | 验收结论 | |", + "tags": [ + "08_测试相关", + "[验收", + "模板]", + "测试" + ], + "complexity": "simple", + "knowledgeMeta": { + "wikilinks": [], + "content": "---\ntype: acceptance_template\ntags: [验收, 测试, 模板]\naliases: [验收记录, UAT模板]\nsource: manual\nstatus: active\nowner: 测试负责人 / 业务负责人\nupdated: 2026-05\n---\n\n# 验收记录模板\n\n## 基本信息\n\n| 项目 | 内容 |\n|---|---|\n| 项目/模块 | |\n| 关联需求 | |\n| 关联测试用例 | |\n| 验收负责人 | |\n| 验收日期 | |\n| 验收结论 | |\n\n## 验收范围\n\n\n## 验收结果\n\n| 验收项 | 预期结果 | 实际结果 | 结论 | 备注 |\n|---|---|---|---|---|\n| | | | | |\n\n## 遗留问题\n\n\n## 上线建议\n\n\n## Agent 检索字段\n\n- 关键词：\n- 同义词：\n- 典型问法：\n", + "backlinks": [ + "article:08_测试相关/README" + ] + } + }, + { + "id": "article:20260517_USER评价业务闭环_共用能力图与渠道专属流程_v2.2", + "type": "article", + "name": "20260517_USER评价业务闭环_共用能力图与渠道专属流程_v2.2", + "filePath": "20260517_USER评价业务闭环_共用能力图与渠道专属流程_v2.2.md", + "summary": "Wiki article: 20260517_USER评价业务闭环_共用能力图与渠道专属流程_v2.2", + "tags": [], + "complexity": "simple", + "knowledgeMeta": { + "wikilinks": [], + "content": "", + "backlinks": [] + } + }, + { + "id": "article:欢迎", + "type": "article", + "name": "欢迎使用如愿知识库", + "filePath": "欢迎.md", + "summary": "请从 [[00_首页/知识库首页]] 开始。", + "tags": [ + "[知识库", + "入口]" + ], + "complexity": "moderate", + "knowledgeMeta": { + "wikilinks": [ + "00_首页/知识库首页", + "知识库使用说明", + "00_首页/知识地图", + "00_首页/Agent问答入口", + "05_需求文档/README", + "06_里程碑/README", + "07_技术文档/README", + "08_测试相关/README", + "04_Agent检索/检索说明" + ], + "content": "---\ntype: index\ntags: [知识库, 入口]\naliases: [欢迎, 首页]\nsource: manual\nstatus: active\nowner: 内部技术团队\nupdated: 2026-05\n---\n\n# 欢迎使用如愿知识库\n\n请从 [[00_首页/知识库首页]] 开始。\n\n常用入口：\n\n- [[知识库使用说明]]\n- [[00_首页/知识地图]]\n- [[00_首页/Agent问答入口]]\n- [[05_需求文档/README|需求文档]]\n- [[06_里程碑/README|里程碑]]\n- [[07_技术文档/README|技术文档]]\n- [[08_测试相关/README|测试相关]]\n- [[04_Agent检索/检索说明]]", + "backlinks": [ + "article:知识库使用说明" + ] + } + }, + { + "id": "article:知识库使用说明", + "type": "article", + "name": "如愿知识库使用说明", + "filePath": "知识库使用说明.md", + "summary": "本文档说明如愿知识库的用途、目录结构、文档存放规则、索引维护规则、Obsidian 图谱使用方式，以及 Agent 如何基于知识库回答问题。", + "tags": [ + "Agent检索]", + "Obsidian", + "[知识库", + "使用说明" + ], + "complexity": "complex", + "knowledgeMeta": { + "wikilinks": [ + "欢迎", + "00_首页/知识库首页", + "00_首页/知识地图", + "00_首页/Agent问答入口", + "04_Agent检索/检索说明", + "00_首页/知识地图", + "00_首页/Agent问答入口", + "05_需求文档/README", + "06_里程碑/README", + "07_技术文档/README", + "08_测试相关/README", + "02_项目管理流程/AI驱动内部系统开发流程_V3_总览", + "04_Agent检索/检索说明", + "04_Agent检索/来源文件索引", + "05_需求文档/需求文档索引", + "01_业务流程/业务规则索引", + "01_业务流程/业务对象字典", + "04_Agent检索/关键词索引", + "04_Agent检索/来源文件索引", + "06_里程碑/里程碑索引", + "07_技术文档/技术文档索引", + "04_Agent检索/关键词索引", + "04_Agent检索/来源文件索引", + "08_测试相关/测试用例索引", + "05_需求文档/需求文档索引", + "07_技术文档/技术文档索引", + "08_测试相关/测试用例索引", + "05_需求文档/xxx需求文档", + "07_技术文档/xxx技术方案", + "08_测试相关/xxx测试用例", + "04_Agent检索/关键词索引", + "04_Agent检索/同义词表", + "04_Agent检索/来源文件索引", + "04_Agent检索/知识库持续更新与验证流程" + ], + "content": "---\ntype: knowledge_base_guide\ntags: [知识库, 使用说明, Obsidian, Agent检索]\naliases: [如愿知识库使用说明, 知识库操作说明, 知识库维护说明]\nsource: manual\nstatus: active\nowner: 内部技术团队\nupdated: 2026-05\n---\n\n# 如愿知识库使用说明\n\n本文档说明如愿知识库的用途、目录结构、文档存放规则、索引维护规则、Obsidian 图谱使用方式，以及 Agent 如何基于知识库回答问题。\n\n## 1. 知识库定位\n\n如愿知识库用于沉淀内部系统建设过程中的：\n\n- 业务需求\n- 业务规则\n- 业务流程\n- 项目里程碑\n- 技术方案\n- 测试用例\n- 缺陷与验收记录\n- Agent 检索规则\n\n知识库不是单纯存文件，而是要形成可检索、可追溯、可被 Agent 引用回答的知识网络。\n\n## 2. 推荐打开方式\n\n推荐使用 Obsidian 打开以下目录作为 Vault：\n\n```text\nD:\\AIcoding\\WishFulfilled\\知识库\\如愿知识库\n```\n\n打开后建议从以下入口开始：\n\n1. [[欢迎]]\n2. [[00_首页/知识库首页]]\n3. [[00_首页/知识地图]]\n4. [[00_首页/Agent问答入口]]\n5. [[04_Agent检索/检索说明]]\n\n## 3. 主目录说明\n\n```text\n如愿知识库/\n├─ 00_首页/ # 首页、知识地图、Agent 问答入口\n├─ 01_业务流程/ # 业务流程、业务对象、业务规则、补充验证记录\n├─ 02_项目管理流程/ # 项目阶段、角色职责、交付物、检查清单、FAQ\n├─ 03_规范与模板/ # 需求、业务规则、会议、上线检查等模板\n├─ 04_Agent检索/ # 检索说明、关键词、同义词、来源文件索引\n├─ 05_需求文档/ # 正式需求文档、需求索引\n├─ 06_里程碑/ # 里程碑计划、阶段计划、评审记录\n├─ 07_技术文档/ # 技术方案、系统架构、接口说明、技术决策\n├─ 08_测试相关/ # 测试用例、测试计划、缺陷、验收、上线检查\n├─ 99_归档/ # 历史文档、废弃文档、仅供参考内容\n├─ 欢迎.md # Obsidian 入口页\n├─ 知识库使用说明.md # 本文档\n└─ Git使用说明.md # Git 仓库协作说明\n```\n\n## 4. 日常使用入口\n\n| 使用场景 | 优先入口 |\n|---|---|\n| 想了解知识库整体结构 | [[00_首页/知识地图]] |\n| 想让 Agent 回答业务问题 | [[00_首页/Agent问答入口]] |\n| 查看或新增需求 | [[05_需求文档/README]] |\n| 查看或新增里程碑 | [[06_里程碑/README]] |\n| 查看或新增技术方案 | [[07_技术文档/README]] |\n| 查看或新增测试用例 | [[08_测试相关/README]] |\n| 查看项目管理阶段 | [[02_项目管理流程/AI驱动内部系统开发流程_V3_总览]] |\n| 查看 Agent 检索规则 | [[04_Agent检索/检索说明]] |\n| 查看来源依据 | [[04_Agent检索/来源文件索引]] |\n\n## 5. 文档应该放在哪里\n\n### 5.1 需求文档\n\n放入：\n\n```text\n05_需求文档/\n```\n\n适合存放：\n\n- 正式需求说明\n- 业务规则说明\n- 需求变更说明\n- 业务补充说明\n- 产品口径说明\n\n推荐命名：\n\n```text\n业务域_需求或规则名称_YYYYMMDD.md\n```\n\n示例：\n\n```text\nUSER评价业务闭环_数据流与中间对象设计_20260517.md\n采购_供应商准入规则_20260526.md\n库存_出入库审批规则_20260526.md\n```\n\n新增后应同步维护：\n\n- [[05_需求文档/需求文档索引]]\n- [[01_业务流程/业务规则索引]]，如涉及业务规则\n- [[01_业务流程/业务对象字典]]，如涉及新增业务对象\n- [[04_Agent检索/关键词索引]]，如需要 Agent 检索命中\n- [[04_Agent检索/来源文件索引]]，如是新的权威来源\n\n### 5.2 里程碑文档\n\n放入：\n\n```text\n06_里程碑/\n```\n\n适合存放：\n\n- 项目里程碑计划\n- 阶段计划\n- 阶段评审记录\n- 上线节奏\n- 准入/准出记录\n\n推荐命名：\n\n```text\n项目名_里程碑计划_YYYYMMDD.md\n项目名_阶段评审记录_YYYYMMDD.md\n```\n\n新增后应同步维护：\n\n- [[06_里程碑/里程碑索引]]\n\n### 5.3 技术文档\n\n放入：\n\n```text\n07_技术文档/\n```\n\n适合存放：\n\n- 系统架构说明\n- 数据模型说明\n- 接口说明\n- 模块设计\n- 技术方案\n- 部署说明\n- 技术决策记录\n\n推荐命名：\n\n```text\n系统或模块_技术方案_YYYYMMDD.md\n系统或模块_接口说明_YYYYMMDD.md\n系统或模块_数据模型_YYYYMMDD.md\n```\n\n新增后应同步维护：\n\n- [[07_技术文档/技术文档索引]]\n- [[04_Agent检索/关键词索引]]，如需要 Agent 检索\n- [[04_Agent检索/来源文件索引]]，如是新的技术依据\n\n### 5.4 测试相关文档\n\n放入：\n\n```text\n08_测试相关/\n```\n\n适合存放：\n\n- 测试计划\n- 测试用例\n- 缺陷记录\n- 验收记录\n- 上线检查\n- 回归测试记录\n\n推荐命名：\n\n```text\n项目名_模块名_测试计划_YYYYMMDD.md\n项目名_模块名_测试用例_YYYYMMDD.md\n项目名_模块名_缺陷记录_YYYYMMDD.md\n项目名_模块名_验收记录_YYYYMMDD.md\n```\n\n新增后应同步维护：\n\n- [[08_测试相关/测试用例索引]]\n- 关联需求文档\n- 关联里程碑或测试阶段\n\n测试用例必须能追溯到需求来源。\n\n### 5.5 业务流程文档\n\n放入：\n\n```text\n01_业务流程/\n```\n\n适合存放：\n\n- 已稳定的业务流程\n- 业务对象定义\n- 业务规则索引\n- 业务补充验证记录\n\n如果是新需求或尚未确认的业务规则，优先放入 `05_需求文档/`，确认稳定后再沉淀到 `01_业务流程/`。\n\n### 5.6 模板文档\n\n放入：\n\n```text\n03_规范与模板/\n```\n\n适合存放：\n\n- 需求说明模板\n- 业务规则补充模板\n- 会议纪要模板\n- 上线检查模板\n- 通用文档模板\n\n模板只用于复用格式，不应存放具体项目内容。\n\n### 5.7 归档文档\n", + "backlinks": [ + "article:欢迎" + ] + } + }, + { + "id": "topic:使用说明", + "type": "topic", + "name": "使用说明", + "summary": "Category from index: 使用说明 (2 articles)", + "tags": [ + "category" + ], + "complexity": "simple" + }, + { + "id": "topic:需求文档", + "type": "topic", + "name": "需求文档", + "summary": "Category from index: 需求文档 (6 articles)", + "tags": [ + "category" + ], + "complexity": "simple" + }, + { + "id": "topic:里程碑", + "type": "topic", + "name": "里程碑", + "summary": "Category from index: 里程碑 (7 articles)", + "tags": [ + "category" + ], + "complexity": "simple" + }, + { + "id": "topic:技术文档", + "type": "topic", + "name": "技术文档", + "summary": "Category from index: 技术文档 (5 articles)", + "tags": [ + "category" + ], + "complexity": "simple" + }, + { + "id": "topic:测试相关", + "type": "topic", + "name": "测试相关", + "summary": "Category from index: 测试相关 (9 articles)", + "tags": [ + "category" + ], + "complexity": "simple" + }, + { + "id": "topic:agent-检索", + "type": "topic", + "name": "Agent 检索", + "summary": "Category from index: Agent 检索 (6 articles)", + "tags": [ + "category" + ], + "complexity": "simple" + }, + { + "id": "source:AI_驱动_内部系统开发流程_V3", + "type": "source", + "name": "AI_驱动_内部系统开发流程_V3.docx", + "filePath": "raw\\AI_驱动_内部系统开发流程_V3.docx", + "summary": "Raw source (.docx, 36 KB)", + "tags": [ + "raw", + "docx" + ], + "complexity": "simple" + }, + { + "id": "doc:05_需求文档/00-系统总览", + "type": "document", + "name": "如愿 · 系统总览 v1.0", + "filePath": "05_需求文档/00-系统总览.md", + "summary": "如愿 · 系统总览 v1.0 2 文件信息 4 文件名称： 00 系统总览.md 项目代号： 如愿 工作目录： /root/user business/ 当前版本： v1.0 创建日期： 2026 05 22 上游基线： docs from business/20260517 USER评价业务闭环主流程与后续工作基线 v1.2.md docs from bu", + "tags": [ + "05_需求文档", + "需求文档" + ], + "complexity": "complex", + "knowledgeMeta": { + "content": "# 如愿 · 系统总览 v1.0\n 2|\n## 文件信息\n 4|\n- 文件名称：`00-系统总览.md`\n- 项目代号：**如愿**\n- 工作目录：`/root/user-business/`\n- 当前版本：`v1.0`\n- 创建日期：`2026-05-22`\n- 上游基线：\n - `docs-from-business/20260517_USER评价业务闭环主流程与后续工作基线_v1.2.md`\n - `docs-from-business/20260517_USER评价业务闭环_共用能力图与渠道专属流程_v2.2.md`\n 13|\n## 目录\n 15|\n1. [项目目标与原则](#1-项目目标与原则)\n2. [系统总边界](#2-系统总边界)\n3. [子系统划分](#3-子系统划分)\n4. [子系统间依赖关系](#4-子系统间依赖关系)\n5. [角色 → 独立前端映射](#5-角色--独立前端映射)\n6. [子系统内外边界明细](#6-子系统内外边界明细)\n7. [总系统级业务澄清问题清单](#7-总系统级业务澄清问题清单)\n8. [待确认的内外边界](#8-待确认的内外边界)\n9. [附录：子系统文档索引](#9-附录子系统文档索引)\n 25|\n---\n 27|\n## 1. 项目目标与原则\n 29|\n### 1.1 项目代号：\"如愿\"\n\n> 取名\"如愿\"——系统做好能做的所有事（身份识别、需求评估、计划调度、渠道协同、风险拦截、结果追踪），让每一次运营投入都如愿转化为真实的评价提升和 ASIN 健康增长。Amazon 是否展示评价有平台的不确定性，但系统必须把可控环节做到极致。\n 33|\n### 1.2 核心架构目标\n 35|\n| # | 目标 | 说明 |\n| --- | --- | --- |\n| G1 | 前端分离 | 不同角色拥有独立前端应用，按需集成子系统能力 |\n| G2 | 清晰系统边界 | 明确系统内外边界，区分内部可控与外部依赖 |\n| G3 | 子系统解耦 | 子系统通过 API 契约通信，支持独立开发、独立部署 |\n| G4 | 并行开发 | 子系统之间尽量减少串行依赖，允许多团队并行推进 |\n| G5 | 独立角色前端 | Amazon 运营、用户运营、客服、风险管理、KOC/KOL 运营各自拥有独立前端 |\n 43|\n### 1.3 架构原则\n 45|\n| 原则 | 说明 |\n| --- | --- |\n| **单一数据源** | 每个业务事实只有一个子系统负责写入（Owner），其他子系统只读或通过 API 调用 |\n| **API 契约优先** | 子系统间通过明确 API 契约通信，先定义契约再实现 |\n| **真实人为核心** | 所有额度、风险、历史判断围绕「真实人」而非单一账号 |\n| **每次互动重判** | 身份、额度、风险不是一次性的，每次有效互动需重做判断 |\n| **审计不可少** | 所有状态变更、敏感访问、人工干预必须留痕 |\n 53|\n---\n 55|\n## 2. 系统总边界\n 57|\n### 2.1 边界总图\n 59|\n```\n┌─────────────────────────────────────────────────────────────────────┐\n│ 如愿 系统边界 │\n│ │\n│ ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐ │\n│ │ Amazon │ │ 用户运营 │ │ Amazon │ │ 风险/黑名 │ │\n│ │ 运营前端 │ │ 前端 │ │ 运营总监 │ │ 单前端 │ │\n│ └────┬─────┘ └────┬─────┘ └────┬─────┘ └────┬─────┘ │\n│ │ │ │ │ │\n│ ┌────┴─────┐ ┌────┴─────┐ ┌────┴─────┐ ┌────┴─────┐ │\n│ │ 客服前端 │ │ 客服管理 │ │ KOC/KOL │ │ 管理驾驶 │ │\n│ │ │ │ 前端 │ │ 运营前端 │ │ 舱 │ │\n│ └────┬─────┘ └────┬─────┘ └────┬─────┘ └────┬─────┘ │\n│ │ │ │ │ │\n│ ═════╪══════════════╪══════════════╪══════════════╪══════ API网关 │\n│ │ │ │ │ │\n│ ┌────┴──────────────┴──────────────┴──────────────┴─────┐ │\n│ │ 内部子系统 │ │\n│ │ ┌────────┐ ┌────────┐ ┌────────┐ ┌────────┐ │ │\n│ │ │ 用户身 │ │需求与计│ │额度与频│ │多渠道触│ │ │\n│ │ │份上下文│ │划管理 │ │ 控 │ │达引擎 │ │ │\n│ │ └───┬────┘ └───┬────┘ └───┬────┘ └───┬────┘ │ │\n│ │ ┌───┴────┐ ┌───┴────┐ ┌───┴────┐ ┌───┴────┐ │ │\n│ │ │客服工单│ │风险与反│ │评价结果│ │KOC/KOL │ │ │\n│ │ │与管理 │ │ 欺诈 │ │ 追踪 │ │ 协作 │ │ │\n│ │ └───┬────┘ └───┬────┘ └───┬────┘ └───┬────┘ │ │\n│ │ ┌───┴────┐ │ │\n│ │ │审计与通│ │ │\n│ │ │知中心 │ │ │\n│ │ └────────┘ │ │\n│ └───────────────────────────────────────────────────────────┘ │\n│ │\n└─────────────────────────────────────────────────────────────────────┘\n 93|\n ║ 外部系统 ║\n 95|\n┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐\n│ Amazon │ │ JOYHUB │ │JOYCOLLAB │ │ 邮件服务 │ │ 财务系统 │\n│ Marketplace│ │ 用户平台 │ │ KOC平台 │ │ (ESP) │ │(返款/退款)│\n└──────────┘ └──────────┘ └──────────┘ └──────────┘ └──────────┘\n```\n 101|\n### 2.2 系统内部（如愿系统）\n 103|\n| # | 子系统 | 代号 | 核心职责 | 详情文档 |\n| --- | --- | --- | --- | --- |\n| S1 | 用户身份与上下文 | `identity` | 真实人识别、身份线索归并、用户上下文卡 | [01-用户身份与上下文](01-子系统-用户身份与上下文.md) |\n| S2 | 需求与计划管理 | `planning` | 需求触发（人工/自动）、计划生成（推新/回评/免评）、审批工作流 | [02-需求与计划管理](02-子系统-需求与计划管理.md) |\n| S3 | 额度与频控 | `quota` | 月度测评/免评额度台账、累计评价额度、频控、预占 | [03-额度与频控](03-子系统-额度与频控.md) |\n| S4 | 多渠道触达引擎 | `outreach` | IM/EDM/APP Push/TEL 渠道调度、路由、去重、发送 | [04-多渠道触达引擎](04-子系统-多渠道触达引擎.md) |\n| S5 | 客服工单与管理 | `support` | 工单生命周期、自动分配、排班出勤、绩效统计 | [05-客服工单与管理](05-子系统-客服工单与管理.md) |\n| S6 | 风险与反欺诈 | `risk` | 强弱关联判断、黑名单、双重退款检测、风险事件 | [06-风险与反欺诈](06-子系统-风险与反欺诈.md) |\n| S7 | 评价结果追踪 | `review` | 评价提交记录、Amazon 展示核验、ASIN 健康回流 | [07-评价结果追踪](07-子系统-评价结果追踪.md) |\n| S8 | KOC/KOL 协作 | `creator` | KOC/KOL 匹配、内容跟踪、Code 管理、JOYCOLLAB 同步 | [08-KOC-KOL协作](08-子系统-KOC-KOL协作.md) |\n| S9 | 审计与通知中心 | `audit` | 状态变更审计、敏感访问日志、多类型通知/告警 | [09-审计与通知中心](09-子系统-审计与通知中心.md) |\n 115|\n### 2.3 系统外部（外部依赖）\n 117|\n| # | 外部系统 | 说明 | 交互方式 | 确认状态 |\n| --- | --- | --- | --- | --- |\n| E1 | **Amazon Marketplace** | 订单数据、评价数据、ASIN/Listing 健康数据、退款数据 | API 拉取 / 爬取 | ⚠️ 待确认 |\n| E2 | **JOYHUB 用户平台** | JOYHUB ID、设备信息、APP 行为数据、绑定玩具数据 | API 同步 | ⚠️ 待确认 |\n| E3 | **JOYCOLLAB** | KOC/KOL 内容数据、Code 使用数据、带货订单数据 | API 同步 | ⚠️ 待确认 |\n| E4 | **邮件服务 (ESP)** | EDM 发送、送达/打开/点击追踪、退订/硬退信 | SMTP + Webhook | ⚠️ 待确认 |\n| E5 | **财务系统** | 返款执行、返款状态、退款记录（OA 侧） | API 调用 | ⚠️ 待确认 |\n| E6 | **APP Push 服务** | APP 推送通道（FCM/APNs） | SDK / API | ⚠️ 待确认 |\n| E7 | **电话系统** | 外呼能力、来电识别、通话记录 | API / SIP | ⚠️ 待确认 |\n| E8 | **IM 平台 (WhatsApp?)** | IM 消息收发 | API | ⚠️ 待确认 |\n 128|\n---\n 130|\n## 3. 子系统划分\n 132|\n### 3.1 划分依据\n 134|\n子系统按照**业务域内聚**原则划分，每个子系统：\n 136|\n1. 拥有明确的数据所有权（该子系统是某些核心数据对象的唯一写入方）\n2. 对外暴露清晰的 API 契约\n3. 可以独立开发、测试、部署\n4. 尽量减少对其他子系统的强依赖（启动依赖）\n 141|\n### 3.2 各子系统数据所有权\n 143|\n| 子系统 | 拥有（写入）的核心数据对象 |\n| --- | --- |\n| identity | `person_profiles`、`person_identity_links`、`contact_context_snapshots`、`device_records` |\n| planning | `demands`、`plans`、`plan_items`、`approval_records`、`asin_catalog` |\n| quota | `person_quota_ledgers`、`quota_reservations`、`frequency_control_records` |\n| outreach | `channel_route_decisions`、`channel_dedup_records`、`im_interaction_records`、`edm_message_events`、`app_touch_events`、`tel_call_records` |\n| support | `support_tickets`、`support_followups`、`support_assignment_logs`、`attendance_records`、`shift_schedules`、`support_performance_snapshots` |\n| risk | `risk_signals`、`risk_cases`、`blacklist_entities`、`refund_match_results` |\n| review | `review_submission_records`、`review_display_checks`、`review_results` |\n| creator | `exemption_plan_tasks`、`creator_content_records`、`creator_profiles`、`code_records` |\n| audit | `interaction_audit_logs`、`notification_records`、`manual_review_tasks` |\n 155|\n---\n 157|\n## 4. 子系统间依赖关系\n 159|\n### 4.1 依赖图\n 161|\n```\n ┌─────────────────────────────────────────────┐\n │ audit (审计与通知) │\n │ ← 所有子系统向 audit 发送事件 │\n └─────────────────────────────────────────────┘\n ↑\n ┌─────────┬─────────┬─────┼─────┬─────────┬─────────┐\n │ │ │ │ │ │ │\n┌───┴───┐ ┌───┴───┐ ┌───┴───┐ │ ┌───┴───┐ ┌───┴───┐ ┌───┴───┐\n│ review│ │creator│ │support│ │ │ risk │ │ quota │ │outreach│\n│(评价) │ │(KOC) │ │(客服) │ │ │(风险) │ │(额度) │ │(触达) │\n└───┬───┘ └───┬───┘ └───┬───┘ │ └───┬───┘ └───┬───┘ └───┬───┘\n │ │ │ │ │ │ │\n └─────────┼─────────┼─────┼─────┼─────────┼─────────┘\n │ │ │ │ │\n ┌────┴─────────┴─────┼─────┼─────────┴────────┐\n │ │ │ │\n ▼ ▼ ▼ ▼\n ┌─────────┐ ┌──────────────┐ ┌─────────┐\n │planning │←─────────│ identity │─────────→│ quota │\n │(计划) │ │ (用户身份) │ │ (额度) │\n └─────────┘ └──────────────┘ └─────────┘\n```\n 185|\n### 4.2 依赖矩阵\n 187|\n| ↓ 消费者 \\ 提供者 → | identity | planning | quota | outreach | support | risk | review | creator | audit |\n| --- |:---:|:---:|:---:|:---:|:---:|:---:|:---:|:---:|:---:|\n| **identity** | - | - | - | - | - | R | - | - | E |\n| **planning** | **R** | - | R | - | - | R | R | - | E |\n| **quota** | **R** | - | - | - | - | - | R | - | E |\n| **outreach** | R | R | R | - | - | R | - | - | E |\n| **support** | R | - | - | - | - | R | - | - | E |\n| **risk** | R | - | - | - | - | - | - | - | E |\n| **review** | R | R | - | - | - | - | - | R | E |\n| **creator** | - | R | R | - | - | - | - | - | E |\n| **audit** | - | - | - | - | - | - | - | - | - |\n 199|\n**图例：** `R` = 只读依赖（通过 API 查询），`E` = 事件发送（fire-and-forget），`-` = 无依赖\n 201|\n### 4.3 启动依赖（必须就绪才能工作）\n 203|\n| 子系统 | 启动依赖 | 说明 |\n| --- | --- | --- |\n| identity | 无硬依赖 | 可独立启动（需要 JOYHUB 数据同步） |\n| planning | identity（软依赖） | 无 identity 时可先操作，但无法做人群匹配 |\n| quota | identity（软依赖） | 额度按真实人计算，未归并时按单一账号 |\n| outreach | identity, planning, quota（软依赖） | 无依赖时可先建渠道基础设施 |\n| support | identity（软依赖） | 无用户上下文卡时可先跑工单 |\n| risk | identity（软依赖） | 强/弱关联依赖身份数据 |\n| review | identity, planning（软依赖） | 评价需关联计划和用户 |\n| creator | planning（软依赖） | 免评计划入口 |\n| audit | 无硬依赖 | 完全独立 |\n 215|\n> **软依赖** = 可降级运行，核心功能不受阻。例如 outreach 在 identity 不可用时仍可发送消息，但缺少用户上下文。\n 217|\n---\n 219|\n## 5. 角色 → 独立前端映射\n 221|\n### 5.1 前端应用矩阵\n 223|\n| 前端应用 | 目标角色 | 集成的子系统 | 部署形态 |\n| --- | --- | --- | --- |\n| **运营工作台** | Amazon 运营、Amazon 运营总监 | planning + review + quota (查询) | Web SPA |\n| **用户运营中心** | 用户运营、用户运营负责人/组长 | planning + outreach + quota + review | Web SPA |\n| **客服工作台** | 菲律宾客服组员 | support + identity (上下文卡) + outreach (TEL) | Web SPA / 桌面端 |\n| **客服管理台** | 菲律宾客服负责人、客服组长 | support (管理模块) + audit | Web SPA |\n| **风险控制台** | 风险/黑名单相关人员 | risk + identity (上下文卡) + audit | Web SPA |\n| **达人协作台** | KOC/KOL 运营 | creator + outreach (协同) + review (免评结果) | Web SPA |\n| **管理驾驶舱** | 运营总监、用户运营负责人 | 跨子系统聚合看板 (planning + outreach + support + review) | Web SPA |\n 233|\n### 5.2 角色-功能矩阵\n 235|\n| 功能 \\ 角色 | Amazon运营 | 运营总监 | 用户运营 | 用户负责人 | 客服组员 | 客服组长 | 客服负责人 | 风险人员 | KOC运营 |\n| --- |:---:|:---:|:---:|:---:|:---:|:---:|:---:|:---:|:---:|\n| 提需求（推新/回评/免评） | ✓ | ✓ | - | - | - | - | - | - | - |\n| 审批计划 | - | ✓ | - | ✓ | - | - | - | - | - |\n| 评估需求 | - | - | ✓ | ✓ | - | - | - | - | - |\n| 生成计划/调资源 | - | - | ✓ | ✓ | - | - | - | - | - |\n| 查看 ASIN 健康 | ✓ | ✓ | ✓ | - | - | - | - | - | - |\n| 处理工单 | - | - | - | - | ✓ | ✓ | - | - | - |\n| 分配工单 | - | - | - | - | - | ✓ | ✓ | - | - |\n| 电话外呼/接听 | - | - | - | - | ✓ | - | - | - | - |\n| 查看排班出勤 | - | - | - | - | - | ✓ | ✓ | - | - |\n| 绩效统计 | - | - | - | - | - | ✓ | ✓ | - | - |\n| 风险审核 | - | - | - | - | - | - | - | ✓ | - |\n| 黑名单管理 | - | - | - | - | - | - | - | ✓ | - |\n| KOC/KOL 匹配 | - | - | - | - | - | - | - | - | ✓ |\n| 内容跟踪 | - | - | ✓ | - | - | - | - | - | ✓ |\n 252|\n---\n 254|\n## 6. 子系统内外边界明细\n 256|\n### 6.1 identity — 用户身份与上下文\n 258|\n| 维度 | 说明 |\n| --- | --- |\n| **对内** | 管理真实人归并逻辑、身份线索关联（JOYHUB ID↔邮箱↔电话↔设备↔订单→真实人ID）、用户上下文卡聚合与快照、设备变化识别 |\n| **对外（提供给其他子系统）** | `GET /api/identity/person/{context}` — 按线索查真实人；`GET /api/identity/context/{person_id}` — 用户上下文卡；`POST /api/identity/merge` — 归并请求 |\n| **依赖外部系统** | JOYHUB（用户基础数据）、APP（设备数据） |\n| **待确认边界** | 真实人归并是自动还是人工确认？归并拆分（合并错了如何回退）？非 APP 用户的身份线索从哪里同步（ESM 的邮箱清洗？） |\n 265|\n### 6.2 planning — 需求与计划管理\n 267|\n| 维度 | 说明 |\n| --- | --- |\n| **对内** | 需求触发（人工提交 + 自动触发规则）、需求评估、计划创建（推新/回评/免评）、审批工作流、ASIN 基础信息管理 |\n| **对外（提供给其他子系统）** | `GET /api/plans/{id}` — 计划详情；`GET /api/plans?status=approved` — 待执行计划；`POST /api/demands` — 创建需求 |\n| **依赖外部系统** | Amazon（ASIN 数据、销售数据、评价缺口） |\n 273|\n### 6.3 quota — 额度与频控\n 275|\n| 维度 | 说明 |\n| --- | --- |\n| **对内** | 额度台账（测评4/免评4/累计12）、额度预占与释放、频控规则引擎、发送前终校 |\n| **对外（提供给其他子系统）** | `GET /api/quota/check/{person_id}?type=测评` — 额度查询+预占；`POST /api/quota/reserve` — 预占；`POST /api/quota/commit` — 确认占用 |\n| **依赖外部系统** | 无直接外部系统依赖 |\n| **待确认边界** | 额度预占有效期多长？跨月额度如何处理（月末最后一天预占，下月一号释放还是保留？） |\n 282|\n### 6.4 outreach — 多渠道触达引擎\n 284|\n| 维度 | 说明 |\n| --- | --- |\n| **对内** | 渠道路由决策、渠道去重、IM 推送（分层 A/B/C）、EDM 发送与行为追踪、APP Push、TEL 任务生成 |\n| **对外（提供给其他子系统）** | `POST /api/outreach/send` — 发送触达；`GET /api/outreach/history/{person_id}` — 触达历史 |\n| **依赖外部系统** | JOYHUB（IM 通道）、ESP（EDM）、FCM/APNs（APP Push）、电话系统（TEL） |\n| **待确认边界** | IM 具体是什么平台（WhatsApp/自研 IM）？EDM 模板管理在 outreach 内还是独立内容管理？APP Push 是否复用 JOYHUB 现有 Push 通道？ |\n 291|\n### 6.5 support — 客服工单与管理\n 293|\n| 维度 | 说明 |\n| --- | --- |\n| **对内** | 工单生命周期、自动分配（按排班/在线/负载）、答应配合状态机、出勤/排班/绩效 |\n| **对外（提供给其他子系统）** | `POST /api/tickets` — 创建工单；`GET /api/tickets/{id}` — 工单详情；`GET /api/support/stats` — 绩效数据 |\n| **依赖外部系统** | 无直接外部系统依赖（电话记录来自 outreach TEL 模块） |\n| **待确认边界** | 客服是否使用独立 IM 工具还是复用 outreach 的 IM 通道？排班数据是否与现有 HR 系统对接？ |\n 300|\n### 6.6 risk — 风险与反欺诈\n 302|\n| 维度 | 说明 |\n| --- | --- |\n| **对内** | 强弱关联判断、黑名单实体管理、风险事件管理、双重退款检测（Amazon退款 vs OA返款） |\n| **对外（提供给其他子系统）** | `GET /api/risk/check/{person_id}` — 风险查询；`POST /api/risk/report` — 上报风险信号 |\n| **依赖外部系统** | Amazon（退款数据）、财务系统（OA 返款数据） |\n 308|\n### 6.7 review — 评价结果追踪\n 310|\n| 维度 | 说明 |\n| --- | --- |\n| **对内** | 用户真实提交评价记录、Amazon 展示核验、ASIN 健康更新回流、计划完成度计算 |\n| **对外（提供给其他子系统）** | `POST /api/reviews/submission` — 记录提交；`GET /api/reviews/status/{plan_id}` — 计划评价进度 |\n| **依赖外部系统** | Amazon（评价展示状态、ASIN 评分数据） |\n 316|\n### 6.8 creator — KOC/KOL 协作\n 318|\n| 维度 | 说明 |\n| --- | --- |\n| **对内** | KOC/KOL 匹配筛选、内容 Brief/Code 分配、内容发布跟踪、带货结果跟踪 |\n| **对外（提供给其他子系统）** | `GET /api/creators/match?plan_id=` — 匹配推荐；`POST /api/creators/tasks` — 创建协作任务 |\n| **依赖外部系统** | JOYCOLLAB（KOC/KOL 数据、内容数据、Code 使用、带货订单） |\n 324|\n### 6.9 audit — 审计与通知中心\n 326|\n| 维度 | 说明 |\n| --- | --- |\n| **对内** | 所有子系统的状态变更审计、敏感字段访问日志、多类型通知（额度预警/超时提醒/紧急 Listing 告警/审批通知） |\n| **对外（提供给其他子系统）** | `POST /api/audit/event` — 上报审计事件；`POST /api/notifications/send` — 发送通知 |\n| **依赖外部系统** | 通知可能通过 IM/EDM/APP Push 等通道（可复用 outreach 通道或独立） |\n| **待确认边界** | 审计日志保留策略？通知模板管理在 audit 内还是需要独立内容管理？ |\n 333|\n---\n 335|\n## 7. 总系统级业务澄清问题清单\n 337|\n> 以下问题需要与业务方确认，涉及跨子系统边界、关键业务规则和外部系统对接。\n 339|\n### 7.1 外部系统对接（8 项）\n 341|\n| # | 问题 | 涉及外部系统 | 优先级 |\n| --- | --- | --- | --- |\n| Q-E1 | Amazon 数据以什么方式接入？（MWS/SP-API 授权拉取、爬虫、CSV 导入、已有中间表？） | Amazon | **P0** |\n| Q-E2 | JOYHUB 现有数据有哪些可用？是否有现成 API？JOYHUB ID ↔ 邮箱 ↔ 设备 ↔ 订单 的关联数据是否已存储？ | JOYHUB | **P0** |\n| Q-E3 | JOYCOLLAB 数据同步方向是单向（COLLAB→USER）还是双向？同步频率？Code 生成是在 COLLAB 还是 USER？ | JOYCOLLAB | **P0** |\n| Q-E4 | 当前 EDM 使用什么邮件服务？（SendGrid / Mailchimp / SES / 自建？）是否有现成的送达/打开/点击追踪？ | ESP | **P0** |\n| Q-E5 | OA 返款系统是哪个？是否有 API 可以查询返款状态和返款记录？（用于双重退款比对） | 财务系统 | **P0** |\n| Q-E6 | APP Push 是否复用 JOYHUB 现有 Push 通道还是需要独立接入 FCM/APNs？ | APP Push | P1 |\n| Q-E7 | 电话系统用什么方案？（自建 SIP / 第三方云呼叫中心？）是否已有通话记录存储？ | 电话系统 | P1 |\n| Q-E8 | IM 平台具体是什么？（WhatsApp Business API / 自研 IM / Facebook Messenger？） | IM 平台 | P1 |\n 352|\n### 7.2 用户身份体系（5 项）\n 354|\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| Q-I1 | 「真实人」归并是完全自动还是需要人工确认？自动归并错误时如何拆分？（拆分会影响到已关联的历史评价和额度） | **P0** |\n| Q-I2 | 非 APP 用户（只知道邮箱）如何建立真实人？没有设备号仅凭邮箱+收件地址归并，置信度阈值如何定？ | **P0** |\n| Q-I3 | JOYHUB ID 与真实人是 1:1 还是 N:1？（一个真实人可能拥有多个 JOYHUB ID） | P1 |\n| Q-I4 | 设备变化的「换机」判定标准是什么？（同一 JOYHUB ID 下设备号变化？多久内变化算换机？） | P1 |\n| Q-I5 | 用户上下文卡的「快照」是否需要保留历史版本？（每次互动生成新快照 vs 覆盖上次） | P2 |\n 362|\n### 7.3 额度与频控规则（6 项）\n 364|\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| Q-Q1 | 月度额度按自然月还是按 30 天滚动？如果是自然月，预占在月末最后一天是否需要特殊处理？ | **P0** |\n| Q-Q2 | 「测评 4 次」的「次」定义：是指参与 4 个不同的测评计划，还是提交 4 次评价？（如果一次计划要求用户提交多条评价怎么算） | **P0** |\n| Q-Q3 | 「累计 12 个评价」是永久上限还是可以重置？（例如用户长期优质，是否可以放宽？） | P1 |\n| Q-Q4 | 额度预占的有效期多长？如果预占后用户始终未响应，多久释放额度？ | P1 |\n| Q-Q5 | 频控规则中的「渠道频控」具体阈值是多少？（IM 每日最多推几次？EDM 每周最多几封？） | P1 |\n| Q-Q6 | 「接近上限时提前预警」——预警阈值是还剩 1 次还是还剩 N%？ | P2 |\n 373|\n### 7.4 计划与审批流程（5 项）\n 375|\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| Q-P1 | 自动触发需求的条件是什么？（ASIN 评分低于多少？评价缺口多少条？Listing 健康到什么程度？） | **P0** |\n| Q-P2 | 审批链中的「指定负责人」如何确定？（系统自动按规则还是人工指定？规则是什么？） | **P0** |\n| Q-P3 | 计划审批后是否可以修改？修改是否需要重新审批？ | P1 |\n| Q-P4 | 计划之间是否有互斥关系？（同一个 ASIN 同时跑推新和回评计划是否可以？） | P1 |\n| Q-P5 | 「紧急计划」的判定标准和特殊审批流程？（谁可以标记为紧急？是否跳过某些审批节点？） | P1 |\n 383|\n### 7.5 渠道协同与去重（5 项）\n 385|\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| Q-C1 | 渠道优先级路由规则是否需要可配置？（例如针对某类用户调整 IM > EDM 的优先级） | **P0** |\n| Q-C2 | 用户已在客服工单中时「暂停自动触达」——是所有渠道暂停还是仅暂停与当前工单相关的渠道？ | P1 |\n| Q-C3 | EDM 引导注册 APP 后，如何识别「该 EDM 邮箱对应该 APP 用户」？靠什么字段关联？ | P1 |\n| Q-C4 | 渠道去重中「同一计划同一用户不重复通过多渠道路由」——如果高优先级渠道发送失败（退信/未送达），是否自动降级到下一渠道？ | P1 |\n| Q-C5 | IM 推送中的「催评卡片」和 APP Push 中的「催评推送」如何协调？（两者会不会同时推送给同一用户？） | P1 |\n 393|\n### 7.6 客服与工单（5 项）\n 395|\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| Q-S1 | 工单自动分配算法——「当前负载」如何计算？（按未关闭工单数？按最近 N 小时处理量？） | **P0** |\n| Q-S2 | 客服的「在线状态」如何获取？（手动切换在线/离线，还是自动检测活跃度？） | P1 |\n| Q-S3 | 「答应配合」的超时判定——答应后多少天未提交算超时？超时后提醒频率？ | P1 |\n| Q-S4 | 出勤排班是否与本系统内的排班模块管理还是对接外部 HR 系统？ | P1 |\n| Q-S5 | 客服转化统计中的 RSO（回评）和 RDO（测评）如何区分？（按工单来源？按最终结果？） | P2 |\n 403|\n### 7.7 风险与反欺诈（4 项）\n 405|\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| Q-R1 | 「强关联」中哪些维度的命中可以直接自动化拦截，哪些需要人工复核？（文档说一旦命中直接进入高风险，但实际执行中是否所有强关联都自动拦截？） | **P0** |\n| Q-R2 | 双重退款检测——Amazon 退款数据如何及时获取？（T+1 同步？实时 Webhook？手动导入？） | **P0** |\n| Q-R3 | 黑名单是否有过期/申诉/解除机制？什么条件下可以从黑名单中移除？ | P1 |\n| Q-R4 | 风险信号的「弱关联」观察期多长？观察期过后是自动解除还是人工确认？ | P1 |\n 412|\n### 7.8 评价结果与回流（4 项）\n 414|\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| Q-V1 | Amazon 评价展示的核验方式是什么？（定时爬取 Amazon 页面？手动录入？用户上传截图？API？） | **P0** |\n| Q-V2 | 「Amazon 未展示 / 暂不可核验」的评价进入异常观察队列后，观察多久？复查频率？ | P1 |\n| Q-V3 | ASIN 健康「回流」的具体含义是什么？（更新 ASIN 评分/评价数到 planning 子系统，触发新一轮需求？） | P1 |\n| Q-V4 | 一个用户可能为多个 ASIN 提交评价——这些评价是否都计入同一个计划的完成度？ | P1 |\n 421|\n### 7.9 KOC/KOL 协作（4 项）\n 423|\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| Q-K1 | JOYCOLLAB 中 KOC/KOL 数据字段有哪些？（粉丝量、平台、国家、历史效果——文档提到但需确认完整字段） | **P0** |\n| Q-K2 | 「匹配 KOC/KOL」是运营人工选择还是系统自动推荐？推荐算法依赖什么数据？ | P1 |\n| Q-K3 | Code 是 JOYCOLLAB 生成还是 USER 系统生成？是一对一（每个 KOC 独立 Code）还是一对多？ | P1 |\n| Q-K4 | KOC/KOL 的财务结算（提成/返点）是完全在财务系统还是在 USER 系统内触发？ | P1 |\n 430|\n### 7.10 数据迁移与历史兼容（3 项）\n 432|\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| Q-D1 | 现有 USER 后台 ERP 系统（`C:\\XCODE\\USER`）是否完全废弃还是部分模块保留？新旧系统切换策略？ | **P0** |\n| Q-D2 | 历史数据（已有评价记录、用户数据、工单记录）是否需要迁移到新系统？迁移范围和清洗策略？ | **P0** |\n| Q-D3 | 旧系统中存在的用户额度数据如何初始化？（历史测评次数、免评次数、累计评价数如何确定？） | **P0** |\n 438|\n### 7.11 项目分期与 MVP 范围（5 项）\n 440|\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| Q-M1 | 项目一期（MVP）的最小范围是什么？9 个子系统中哪些是必须的、哪些可以二期再做？ | **P0** |\n| Q-M2 | MVP 先支持哪个 Amazon 站点？（.com？还是多站点？）先支持哪种计划类型？（推新/回评/免评全部 or 先做回评？） | **P0** |\n| Q-M3 | 前端应用的优先级——7 个前端中哪些是 MVP 必须有？（客服工作台+运营工作台？还是全部都要？） | **P0** |\n| Q-M4 | 项目整体时间线和里程碑约束？（6 个月？1 年？是否有硬性 deadline？） | P1 |\n| Q-M5 | 开发团队规模和结构？（几个后端开发？几个前端？是否有专职 QA？）是否支持 9 个子系统并行开发？ | P1 |\n 448|\n### 7.12 基础设施与部署（6 项）\n 450|\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| Q-IN1 | 部署环境？（云厂商 AWS/阿里云？自建机房？）是否已有 Kubernetes 集群或考虑容器化部署？ | **P0** |\n| Q-IN2 | 数据库选型？（PostgreSQL / MySQL？）每子系统独立数据库还是共享数据库？是否已有数据库团队和规范？ | **P0** |\n| Q-IN3 | 子系统间异步通信方案？（消息队列：Kafka/RabbitMQ/Redis？还是全部同步 HTTP？） | **P0** |\n| Q-IN4 | API 网关选型？（Kong/Nginx/自研？）认证鉴权方案？（JWT/OAuth2/SSO？） | P1 |\n| Q-IN5 | 日志、监控、链路追踪方案？（ELK/Prometheus+Grafana/Jaeger？）是否已有公司级基础设施可复用？ | P1 |\n| Q-IN6 | 灾备和容灾要求？（RPO/RTO 目标？是否需要多可用区/异地容灾？数据备份频率？） | P2 |\n 459|\n### 7.13 安全与合规（5 项）\n 461|\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| Q-SC1 | 是否有需要通过的安全合规认证？（SOC2 / ISO 27001 / 等保？）对系统架构有何约束？ | P1 |\n| Q-SC2 | 用户个人数据（邮箱、电话、地址、设备号）的保留和删除策略？（GDPR 的「被遗忘权」如何处理？） | P1 |\n| Q-SC3 | Amazon 的 API 使用条款（SP-API Acceptable Use Policy）对数据存储和使用的限制？（评价数据是否可以长期存储？） | P1 |\n| Q-SC4 | 系统权限模型？（RBAC？角色和权限的粒度？是否需要支持数据行级权限——例如不同站点的运营只看自己的 ASIN？） | P1 |\n| Q-SC5 | 敏感数据（收款信息、设备号）的加密存储方案？传输加密（TLS）要求？ | P2 |\n 469|\n### 7.14 技术栈与规范（4 项）\n 471|\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| Q-TS1 | 后端技术栈偏好？（Python/FastAPI？Go？Node.js？Java？）是否有公司技术栈约束？ | P1 |\n| Q-TS2 | 前端技术栈偏好？（React/Vue/Angular？）是否有公司前端组件库或设计系统可复用？ | P1 |\n| Q-TS3 | API 规范标准？（OpenAPI 3.0？gRPC？）是否需要 BFF（Backend for Frontend）层？ | P2 |\n| Q-TS4 | 代码仓库策略？（Monorepo or Polyrepo？9 个子系统分仓库还是一仓库？CI/CD 工具？） | P2 |\n 478|\n### 7.15 多站点与多市场（4 项）\n 480|\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| Q-MS1 | 系统需要支持多少个 Amazon 站点？（.com / .co.uk / .de / .fr / .it / .es / .jp / .ca？）不同站点的业务流程是否一致？ | **P0** |\n| Q-MS2 | 多站点下「真实人」归并是否跨站点？（同一个真实人在 .com 和 .co.uk 用不同邮箱/账号——是否归并为同一人？） | P1 |\n| Q-MS3 | 额度规则是否跨站点？（测评 4 次是每个站点独立还是全局？累计 12 个评价呢？） | P1 |\n| Q-MS4 | 未来是否扩展到 Amazon 以外的平台（eBay/Walmart/独立站）？架构上需要预留扩展点吗？ | P2 |\n 487|\n### 7.16 内容与素材管理（3 项）\n 489|\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| Q-CM1 | EDM 模板、IM 推送话术、APP Push 文案的创建和维护由谁负责？（内容运营？用户运营？）是否需要独立的内容管理子系统？ | P1 |\n| Q-CM2 | 多语言内容策略？（面向美国用户的英文消息、面向德国用户的德语消息——模板由谁翻译和维护？系统是否需要自动翻译？） | P1 |\n| Q-CM3 | 图片/视频素材（产品图片、测评指引图）的存储和管理？是否需要 CDN？ | P2 |\n 495|\n### 7.17 业务量级预估（4 项）\n 497|\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| Q-BV1 | 系统需要管理的 ASIN 数量级？（几十个？几百个？几千个？） | P1 |\n| Q-BV2 | 日活跃用户数（APP 端）？日触达消息量（IM+EDM+APP Push+TEL）？ | P1 |\n| Q-BV3 | 客服团队规模？（几个组？每组多少人？峰值工单量？） | P1 |\n| Q-BV4 | 峰值场景预估？（Prime Day / Black Friday 期间流量和触达量是平时的几倍？） | P2 |\n 504|\n### 7.18 外部系统对接细节（4 项）\n 506|\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| Q-EX1 | 各外部系统的 SLA 和可用性？（Amazon SP-API 的 rate limit？JOYHUB 的响应时间？）当外部系统不可用时的降级策略？ | P1 |\n| Q-EX2 | 外部系统的认证方式？（Amazon SP-API 的 OAuth 授权流程？JOYHUB 的 API Key？）谁负责管理这些凭证？ | P1 |\n| Q-EX3 | 数据同步的增量 or 全量策略？（Amazon 订单是增量拉取最近 N 天还是全量同步？JOYHUB 用户数据呢？） | P1 |\n| Q-EX4 | 外部系统数据格式和字段映射是否已有文档？（Amazon 订单字段→系统内部字段的映射关系？） | P2 |\n 513|\n---\n 515|\n## 8. 待确认的内外边界\n 517|\n> 以下边界由于文档信息不足，标记为「待确认」，需要在后续与业务方或技术团队确认。\n 519|\n| # | 边界问题 | 影响范围 | 建议确认方式 |\n| --- | --- | --- | --- |\n| B1 | **内容/素材管理归属**：EDM 模板、IM 推送话术、APP Push 文案由哪个子系统管理？是 outreach 内的内容模块，还是独立的内容管理子系统？ | outreach | 与内容运营角色确认工作流 |\n| B2 | **品牌/内容运营角色**：文档提到品牌运营和内容运营但目前不展开。他们是否需要独立前端？需求何时明确？ | planning / creator | 与业务方确认是否一期纳入 |\n| B3 | **数据仓库/BI 边界**：文档明确「完整 BI/财务/ROI 系统」不在本版主流程，但管理驾驶舱涉及聚合看板。看板数据是子系统直接提供聚合 API 还是走独立数据仓库？ | 全部 | 与数据团队确认数据架构 |\n| B4 | **外部系统降级策略**：Amazon API 不可用时，哪些功能可以降级运行？JOYHUB 不可用时用户身份如何兜底？ | identity / planning / review | 制定 SLA 和降级方案 |\n| B5 | **多语言支持**：系统前端是否只面向菲律宾客服（英文？）还是国内团队也使用（中文？） | 所有前端 | 确认各前端的语言需求 |\n| B6 | **定时任务归属**：自动需求触发、EDM 批处理、超时检测、评价核验等定时任务在各子系统内实现还是有统一调度器？ | 多个子系统 | 确认是否引入统一任务调度 |\n 528|\n---\n 530|\n## 9. 附录：子系统文档索引\n 532|\n| 文档 | 描述 |\n| --- | --- |\n| [01-子系统-用户身份与上下文](01-子系统-用户身份与上下文.md) | 真实人归并、用户上下文卡、设备识别 |\n| [02-子系统-需求与计划管理](02-子系统-需求与计划管理.md) | 需求触发、计划生命周期、审批工作流 |\n| [03-子系统-额度与频控](03-子系统-额度与频控.md) | 额度台账、频控引擎、预占释放 |\n| [04-子系统-多渠道触达引擎](04-子系统-多渠道触达引擎.md) | IM/EDM/APP/TEL 调度与执行 |\n| [05-子系统-客服工单与管理](05-子系统-客服工单与管理.md) | 工单管理、客服管理支撑 |\n| [06-子系统-风险与反欺诈](06-子系统-风险与反欺诈.md) | 风险判断、黑名单、双重退款 |\n| [07-子系统-评价结果追踪](07-子系统-评价结果追踪.md) | 评价提交、展示核验、结果回流 |\n| [08-子系统-KOC-KOL协作](08-子系统-KOC-KOL协作.md) | KOC/KOL 匹配、内容跟踪、JOYCOLLAB 同步 |\n| [09-子系统-审计与通知中心](09-子系统-审计与通知中心.md) | 审计日志、多类型通知告警 |\n 544|", + "wikilinks": [], + "category": "layer-requirements" + } + }, + { + "id": "doc:05_需求文档/01-子系统-用户身份与上下文", + "type": "document", + "name": "子系统 01 — 用户身份与上下文 (`identity`) v1.0", + "filePath": "05_需求文档/01-子系统-用户身份与上下文.md", + "summary": "子系统 01 — 用户身份与上下文 identity v1.0 子系统概述 维度 说明 代号 identity 核心职责 真实人识别与归并、身份线索关联、用户上下文卡生成 数据所有权 person profiles , person identity links , contact context snapshots , device records 启动依", + "tags": [ + "05_需求文档", + "需求文档" + ], + "complexity": "moderate", + "knowledgeMeta": { + "content": "# 子系统 01 — 用户身份与上下文 (`identity`) v1.0\n\n## 子系统概述\n\n| 维度 | 说明 |\n| --- | --- |\n| 代号 | `identity` |\n| 核心职责 | 真实人识别与归并、身份线索关联、用户上下文卡生成 |\n| 数据所有权 | `person_profiles`, `person_identity_links`, `contact_context_snapshots`, `device_records` |\n| 启动依赖 | 无硬依赖（需 JOYHUB 数据同步到位） |\n| 外部系统依赖 | JOYHUB（用户数据）、APP（设备数据） |\n\n---\n\n## 1. 模块划分\n\n### 整体模块图\n\n```\n┌─────────────────────────────────────────────────────────────┐\n│ identity 子系统 │\n│ │\n│ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │\n│ │ M1: 身份线索 │ │ M2: 真实人 │ │ M3: 用户上下 │ │\n│ │ 采集与同步 │→│ 归并引擎 │→│ 文卡服务 │ │\n│ └──────┬───────┘ └──────┬───────┘ └──────┬───────┘ │\n│ │ │ │ │\n│ ▼ ▼ ▼ │\n│ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │\n│ │ M4: 设备变化 │ │ M5: 身份管理 │ │ M6: 对外 API │ │\n│ │ 识别 │ │ Admin │ │ Gateway │ │\n│ └──────────────┘ └──────────────┘ └──────────────┘ │\n│ │\n└─────────────────────────────────────────────────────────────┘\n```\n\n### 模块明细\n\n| # | 模块 | 代号 | 职责 |\n| --- | --- | --- | --- |\n| M1 | 身份线索采集与同步 | `identity-ingest` | 从 JOYHUB、APP 等外部系统拉取/接收身份线索（JOYHUB ID、邮箱、电话、设备号、订单关联） |\n| M2 | 真实人归并引擎 | `person-merge` | 按标准姓名+地址、多线索交叉权重归并，生成/更新真实人 ID |\n| M3 | 用户上下文卡服务 | `context-card` | 聚合身份+交易+服务+风险+设备+触达全量数据生成上下文快照 |\n| M4 | 设备变化识别 | `device-tracker` | 识别设备号变化、换机、多设备场景，记录设备变化日志 |\n| M5 | 身份管理 Admin | `identity-admin` | 人工归并/拆分操作、归并冲突处理、身份数据校正 |\n| M6 | 对外 API Gateway | `identity-api` | 向其他子系统提供真实人查询、上下文卡查询、归并请求等 API |\n\n---\n\n## 2. 各模块内外说明\n\n### 2.1 M1: 身份线索采集与同步\n\n| 维度 | 说明 |\n| --- | --- |\n| **对内** | 管理外部系统的数据同步任务（定时拉取 JOYHUB 用户数据、设备数据）；解析和标准化各来源的身份线索（邮箱规范化、电话格式化、地址标准化）；写入 `person_identity_links` 表 |\n| **对外接口** | `POST /internal/identity/ingest — 接收上游推送的身份线索`；同步调度器可配置频率 |\n| **数据写入** | `person_identity_links`（线索类型 + 线索值 + 来源系统 + 采集时间） |\n\n### 2.2 M2: 真实人归并引擎\n\n| 维度 | 说明 |\n| --- | --- |\n| **对内** | 执行归并规则：标准姓名+地址一致→同一真实人；多线索交叉（设备+电话+邮箱+收款信息）按权重打分；地址一致姓名不同→标记家庭关联但不合并；生成真实人 ID、归并证据、置信度 |\n| **对外接口** | `POST /api/identity/merge — 触发归并`；返回归并结果（真实人 ID + 置信度） |\n| **数据写入** | `person_profiles`（真实人创建/更新）、`person_identity_links`（关联关系更新） |\n| **关键规则** | 邮箱不同+JOYHUB ID 不同不能单独否定「同一真实人」；订单号命中历史异常需拉出风险记录 |\n\n### 2.3 M3: 用户上下文卡服务\n\n| 维度 | 说明 |\n| --- | --- |\n| **对内** | 聚合 6 组字段（当前身份、真实人归并、历史交易、历史服务、历史风险、当前设备、触达历史）；生成上下文快照（含快照时间）；首次生成 vs 增量更新 |\n| **对外接口** | `GET /api/identity/context/{person_id} — 获取用户上下文卡`；返回聚合后的全量上下文 |\n| **数据写入** | `contact_context_snapshots` |\n| **依赖其他子系统** | 交易数据来自 planning；服务数据来自 support；风险数据来自 risk；触达数据来自 outreach（通过 API 聚合或事件） |\n\n### 2.4 M4: 设备变化识别\n\n| 维度 | 说明 |\n| --- | --- |\n| **对内** | 监控同一 JOYHUB ID 下设备号变化；记录换机/多设备事件；关联设备型号、系统版本、APP 版本变化 |\n| **对外接口** | 内部事件 `device.changed` 供其他模块消费 |\n| **数据写入** | `device_records`（设备变化时间、变化类型） |\n| **待确认** | 多久内的设备变化算「近期换机」？多设备同时活跃如何标记？ |\n\n### 2.5 M5: 身份管理 Admin\n\n| 维度 | 说明 |\n| --- | --- |\n| **对内** | 提供人工归并操作界面（两个真实人合并为一个）；归并拆分（合并错了如何回退）；冲突处理（系统自动归并 vs 人工判定不一致时） |\n| **对外接口** | 管理 API（不对其他子系统暴露） |\n| **数据写入** | 所有身份相关表（权限控制） |\n\n### 2.6 M6: 对外 API Gateway\n\n| 维度 | 说明 |\n| --- | --- |\n| **对内** | 统一对外 API 认证、限流、日志 |\n| **对外接口** | `GET /api/identity/person?线索类型=&线索值=` — 按线索查真实人；`GET /api/identity/context/{person_id}` — 用户上下文卡；`POST /api/identity/batch-check` — 批量身份查询 |\n\n---\n\n## 3. 对外 API 契约（草案）\n\n| 接口 | 方法 | 输入 | 输出 | 消费者 |\n| --- | --- | --- | --- | --- |\n| 按线索查真实人 | `GET /api/identity/person` | `?type=email&value=xxx@yy.com` 或 `?type=joyhub_id&value=123` | `{person_id, confidence, matched_clues[]}` | 所有子系统 |\n| 获取用户上下文卡 | `GET /api/identity/context/{person_id}` | `person_id` | `{identity, transactions, services, risks, devices, outreach_history}` | support, risk, outreach |\n| 批量身份查询 | `POST /api/identity/batch-check` | `[{type, value}, ...]` | `[{person_id, confidence}, ...]` | planning, outreach |\n| 触发归并 | `POST /api/identity/merge` | `{clues: [{type, value}, ...]}` | `{person_id, is_new, confidence}` | outreach（每次互动时调用） |\n\n---\n\n## 4. 数据对象（本子系统写入）\n\n| 对象 | 核心字段 | 说明 |\n| --- | --- | --- |\n| `person_profiles` | person_id, status, created_at, updated_at, merge_evidence | 真实人主表 |\n| `person_identity_links` | person_id, clue_type (JOYHUB_ID/EMAIL/PHONE/DEVICE/ORDER_NAME_ADDRESS), clue_value, source, confidence, linked_at | 身份线索关联表 |\n| `contact_context_snapshots` | person_id, snapshot_time, identity_snapshot, transaction_snapshot, service_snapshot, risk_snapshot, device_snapshot, outreach_snapshot | 上下文快照 |\n| `device_records` | person_id, joyhub_id, device_id, device_model, os_version, app_version, change_type (NEW/SWITCH/MULTI), recorded_at | 设备变化记录 |\n\n---\n\n## 5. 业务澄清问题清单 — identity\n\n### 5.1 真实人归并规则（4 项）\n\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| I-01 | 标准姓名+地址的「标准化」规则是什么？（大小写、空格、缩写如 St./Street、middle name 处理？）标准化在哪个模块做？ | **P0** |\n| I-02 | 归并是多线索交叉权重打分——各维度的权重如何设定？（邮箱=0.3、设备=0.4、电话=0.2、收款=0.5？由谁定义？可否动态调整？） | **P0** |\n| I-03 | 归并是完全自动执行还是部分需要人工审核？触发人工审核的条件是什么？（置信度 < 多少？涉及风险用户？） | **P0** |\n| I-04 | 自动归并错误后如何拆分？拆分时如何处理已关联的历史评价和额度数据？（评价归属、额度扣减是否回滚？） | **P0** |\n\n### 5.2 非 APP 用户处理（3 项）\n\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| I-05 | 非 APP 用户的邮箱从哪里来？（Amazon 订单中的买家邮箱？EDM 列表？客服录入？）邮箱质量/有效性如何保证？ | **P0** |\n| I-06 | 只有邮箱没有设备号的非 APP 用户，归并置信度是否单独设置较低阈值？这种情况下如何确定是同一真实人？ | P1 |\n| I-07 | EDM 引导用户注册 APP 后——如何识别「这个新 APP 用户就是之前那个 EDM 邮箱用户」？（注册时要求填同一邮箱？设备号关联？） | P1 |\n\n### 5.3 设备与多账号（3 项）\n\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| I-08 | 「同设备多账号」的风险判断——同一个设备号关联了多个 JOYHUB ID，哪些情况正常（家庭共用）哪些算风险信号？ | P1 |\n| I-09 | 设备号变化的识别窗口——同一个 JOYHUB ID 下，设备号变化间隔多久内算「近期换机」？ | P1 |\n| I-10 | APP 卸载重装导致设备号变化怎么处理？（卸载重装可能生成新设备号） | P2 |\n\n### 5.4 用户上下文卡（3 项）\n\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| I-11 | 上下文卡的「快照」保留几份？每次互动生成新快照（保留历史）还是覆盖（只保留最新一份）？保留历史的话保留多久？ | P1 |\n| I-12 | 上下文卡中的历史交易、历史服务等数据是从其他子系统实时拉取还是从本地冗余存储读取？（涉及跨子系统数据一致性） | P1 |\n| I-13 | 上下文卡是否需要在某个条件触发时预生成（如用户接入前），还是每次实时生成？ | P2 |\n\n### 5.5 数据同步（2 项）\n\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| I-14 | JOYHUB 数据同步频率？（实时/每小时/每天？）同步方式？（API 拉取 / 消息队列 / 数据库直连？） | **P0** |\n| I-15 | JOYHUB 和 APP 端的数据字段完整清单是否已有？（注册邮箱、设备号、设备型号、APP 版本、系统版本、绑定玩具、活跃行为——文档已列出但需确认是否有遗漏） | **P0** |\n\n### 5.6 身份数据生命周期（4 项）\n\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| I-16 | 用户数据保留策略——身份线索和历史快照保留多久？（6个月？1年？永久？）超出保留期后是归档还是删除？ | P1 |\n| I-17 | 用户注销/数据删除请求如何处理？（用户要求删除所有个人数据——如何标记而不是物理删除以保持额度/风险记录的完整性？） | P1 |\n| I-18 | 「被遗忘权」实操——删除真实人记录后，与之关联的额度、风险、评价如何处理？（匿名化保留？还是级联删除？） | P1 |\n| I-19 | 用户主动修改关键身份信息（换邮箱、换电话）——系统如何感知和响应？（自动触发重新归并？还是保持原关联？） | P1 |\n\n### 5.7 多站点与跨平台身份（3 项）\n\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| I-20 | 同一个自然人在 Amazon.com 和 Amazon.co.uk 用不同邮箱和地址——是否跨站点归并为同一个「真实人」？ | P1 |\n| I-21 | 未来扩展到非 Amazon 平台（eBay/Walmart/独立站）——真实人体系是否需要跨平台？架构预留？ | P2 |\n| I-22 | 不同国家站点的地址标准化规则不同（US→州/邮编、UK→郡/邮编、DE→邮编/城市）——标准化引擎如何处理？ | P2 |\n\n### 5.8 归并冲突与人工干预（3 项）\n\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| I-23 | 系统自动归并和人工判定冲突时，以谁为准？（人工优先？系统告警→人工确认？）冲突记录保留多久？ | P1 |\n| I-24 | 人工拆分归并的操作是否需要审批？（谁来审批？审批流程？）拆分的审计记录保留什么字段？ | P1 |\n| I-25 | 是否存在「不确定」状态的真实人？（置信度太低无法归并，标记为「待定」——如何流转到人工审核？） | P1 |\n\n### 5.9 实施层面（3 项）\n\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| I-26 | 身份归并是实时还是异步？（用户接入时实时归并→阻塞用户体验 vs 异步归并→可能用旧数据？） | P1 |\n| I-27 | 上下文卡聚合的性能要求——单次查询需要在多少 ms 内返回？（涉及跨子系统调用时的超时和降级） | P2 |\n| I-28 | 如果 JOYHUB 数据同步中断，identity 子系统如何降级？（用缓存数据？标记为「数据可能过期」？） | P1 |\n", + "wikilinks": [], + "category": "layer-requirements" + } + }, + { + "id": "doc:05_需求文档/02-子系统-需求与计划管理", + "type": "document", + "name": "子系统 02 — 需求与计划管理 (`planning`) v1.0", + "filePath": "05_需求文档/02-子系统-需求与计划管理.md", + "summary": "子系统 02 — 需求与计划管理 planning v1.0 子系统概述 维度 说明 代号 planning 核心职责 需求触发（人工/自动）、需求评估、计划生成（推新/回评/免评）、审批工作流、ASIN 基础信息管理 数据所有权 demands , plans , plan items , approval records , asin catalog 启", + "tags": [ + "05_需求文档", + "需求文档" + ], + "complexity": "moderate", + "knowledgeMeta": { + "content": "# 子系统 02 — 需求与计划管理 (`planning`) v1.0\n\n## 子系统概述\n\n| 维度 | 说明 |\n| --- | --- |\n| 代号 | `planning` |\n| 核心职责 | 需求触发（人工/自动）、需求评估、计划生成（推新/回评/免评）、审批工作流、ASIN 基础信息管理 |\n| 数据所有权 | `demands`, `plans`, `plan_items`, `approval_records`, `asin_catalog` |\n| 启动依赖 | identity（软依赖，无 identity 可操作但无法做人群匹配） |\n| 外部系统依赖 | Amazon（ASIN 数据、销售数据、评价缺口） |\n\n---\n\n## 1. 模块划分\n\n```\n┌─────────────────────────────────────────────────────────────┐\n│ planning 子系统 │\n│ │\n│ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │\n│ │ M1: 需求管理 │ │ M2: 计划引擎 │ │ M3: 审批工作 │ │\n│ │ (Demand) │→│ (Plan) │→│ 流 │ │\n│ └──────┬───────┘ └──────┬───────┘ └──────┬───────┘ │\n│ │ │ │ │\n│ ▼ ▼ ▼ │\n│ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │\n│ │ M4: 自动触发 │ │ M5: ASIN管理 │ │ M6: 对外 API │ │\n│ │ 规则引擎 │ │ │ │ Gateway │ │\n│ └──────────────┘ └──────────────┘ └──────────────┘ │\n│ │\n└─────────────────────────────────────────────────────────────┘\n```\n\n| # | 模块 | 代号 | 职责 |\n| --- | --- | --- | --- |\n| M1 | 需求管理 | `demand-mgr` | 需求创建、评估（成立/待补充/驳回）、优先级管理、需求与 ASIN 关联 |\n| M2 | 计划引擎 | `plan-engine` | 从已确认需求生成计划（推新/回评/免评）、计划生命周期管理、计划项拆解 |\n| M3 | 审批工作流 | `approval-workflow` | 计划审批链（Amazon 运营总监→用户负责人→渠道负责人）、审批记录 |\n| M4 | 自动触发规则引擎 | `auto-trigger` | 按 ASIN 健康度、评价缺口自动触发需求；定时评估触发条件 |\n| M5 | ASIN 管理 | `asin-catalog` | ASIN 基础信息、评分、评价数、Listing 健康状态维护 |\n| M6 | 对外 API Gateway | `planning-api` | 向其他子系统提供计划查询、ASIN 查询、审批状态查询 API |\n\n---\n\n## 2. 各模块内外说明\n\n### 2.1 M1: 需求管理\n\n| 维度 | 说明 |\n| --- | --- |\n| **对内** | Amazon 运营人工提需求（选择 ASIN、指定类型：推新/回评/免评、目标数量、周期）；用户运营评估需求（查 ASIN 健康、目标数量、历史完成、当前资源）；评估结果：已确认/待补充/驳回 |\n| **对外接口** | `POST /api/demands` — 创建需求；`PUT /api/demands/{id}/evaluate` — 评估需求 |\n| **数据写入** | `demands` |\n| **依赖** | `GET /api/identity/person` — 评估时可能需要运营人员身份 |\n| **待确认** | 需求是否有优先级字段（P0/P1/P2）？驳回后是否允许重新提交？ |\n\n### 2.2 M2: 计划引擎\n\n| 维度 | 说明 |\n| --- | --- |\n| **对内** | 从已确认需求生成计划草案（类型：推新/回评/免评）；计划参数（目标 ASIN、目标数量、周期、预算、备注）；计划状态流转；计划项拆解（将计划拆成可分配给渠道的执行单元） |\n| **对外接口** | `POST /api/plans` — 创建计划；`PUT /api/plans/{id}/status` — 更新状态；`GET /api/plans/{id}/items` — 获取计划项 |\n| **数据写入** | `plans`, `plan_items` |\n| **依赖** | `GET /api/quota/check` — 生成人群前查询额度；`GET /api/risk/check` — 计划复核时查询风险 |\n| **待确认** | 计划是否可以包含多个 ASIN？推新和回评是否可以合并为一个计划？ |\n\n### 2.3 M3: 审批工作流\n\n| 维度 | 说明 |\n| --- | --- |\n| **对内** | 按计划类型路由不同审批链：（测评→Amazon运营总监 / 回评→总监或指定负责人 / 免评→总监+用户负责人 / 紧急→运营负责人+用户负责人+主管）；周/月推送计划审批（用户负责人→渠道负责人）；审批节点（通过/驳回/待补充） |\n| **对外接口** | `POST /api/approvals/{plan_id}/submit` — 提交审批；`PUT /api/approvals/{plan_id}/review` — 审批决策 |\n| **数据写入** | `approval_records` |\n| **依赖** | `GET /api/identity/person` — 获取审批人身份 |\n| **待确认** | 审批链是否可以动态配置（不同站点/国家不同审批人）？驳回后修改再提交是否需要重新走完整审批链？ |\n\n### 2.4 M4: 自动触发规则引擎\n\n| 维度 | 说明 |\n| --- | --- |\n| **对内** | 定时扫描 ASIN 健康状态（评分、评价数、差评比例）；当满足触发条件时自动创建需求（无需人工干预）；触发规则可配置 |\n| **对外接口** | 内部定时任务，不对外暴露 |\n| **数据写入** | `demands`（自动生成的需求） |\n| **依赖** | `GET /api/reviews/asin-health` 或本地 ASIN 数据 |\n| **待确认** | 自动触发后是否需要人工确认还是直接进入评估？自动触发的优先级如何设定？ |\n\n### 2.5 M5: ASIN 管理\n\n| 维度 | 说明 |\n| --- | --- |\n| **对内** | ASIN 基础信息（ASIN 码、标题、品类、站点）；评分、评价总数、差评数；Listing 健康状态（活跃/风险/下架）；与计划的关联关系 |\n| **对外接口** | `GET /api/asins/{asin}` — ASIN 详情；`GET /api/asins?status=at_risk` — 需关注的 ASIN 列表 |\n| **数据写入** | `asin_catalog` |\n| **依赖** | Amazon 数据同步（外部系统） |\n| **待确认** | ASIN 数据是否已在 JOYHUB 或其他系统中维护？是否需要新建还是复用？ |\n\n### 2.6 M6: 对外 API Gateway\n\n| 维度 | 说明 |\n| --- | --- |\n| **对内** | 统一对外 API 认证、限流、日志 |\n| **对外接口** | `GET /api/plans?status=approved` — 待执行计划（outreach 消费）；`GET /api/plans/{id}` — 计划详情（review 消费）；`GET /api/asins/{asin}` — ASIN 查询 |\n\n---\n\n## 3. 对外 API 契约（草案）\n\n| 接口 | 方法 | 输入 | 输出 | 消费者 |\n| --- | --- | --- | --- | --- |\n| 创建需求 | `POST /api/demands` | `{asin, type, target_count, period, priority}` | `{demand_id, status}` | 运营前端 |\n| 评估需求 | `PUT /api/demands/{id}/evaluate` | `{decision, reason}` | `{status}` | 用户运营前端 |\n| 创建计划 | `POST /api/plans` | `{demand_id, type, params}` | `{plan_id}` | 用户运营前端 |\n| 待执行计划列表 | `GET /api/plans?status=approved` | 无 | `[{plan_id, type, items}]` | outreach |\n| 计划详情 | `GET /api/plans/{id}` | `plan_id` | 完整计划含审批记录 | review / outreach |\n| ASIN 查询 | `GET /api/asins/{asin}` | `asin` | ASIN 详情+健康状态 | 所有子系统 |\n\n---\n\n## 4. 数据对象\n\n| 对象 | 核心字段 | 说明 |\n| --- | --- | --- |\n| `demands` | demand_id, asin, type (NEW/REVIEW/EXEMPTION), target_count, period, status (PENDING/EVALUATING/CONFIRMED/REJECTED/WAITING), priority, created_by, evaluated_by, created_at | 需求主表 |\n| `plans` | plan_id, demand_id, type, status (DRAFT/REVIEW/APPROVED/EXECUTING/COMPLETED/CANCELLED), target_count, period, created_at | 计划主表 |\n| `plan_items` | item_id, plan_id, asin, item_type, target_count, assigned_channel, status | 计划执行项 |\n| `approval_records` | approval_id, plan_id, approver, decision, comment, decided_at, step_order | 审批记录 |\n| `asin_catalog` | asin, title, category, marketplace, rating, review_count, negative_count, health_status, last_synced_at | ASIN 信息 |\n\n---\n\n## 5. 业务澄清问题清单 — planning\n\n### 5.1 需求与计划模型（5 项）\n\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| P-01 | 一个需求是否可以生成多个计划？（例如一个回评需求拆分到 IM 计划和 EDM 计划）还是一对一？ | **P0** |\n| P-02 | 计划是否可以跨 ASIN？（一个推新计划覆盖 3 个新 ASIN）还是每个计划只针对一个 ASIN？ | **P0** |\n| P-03 | 计划中的「目标数量」是指目标评价数还是目标触达用户数？（如果转化率 2%，要得到 10 个评价需触达 500 人） | **P0** |\n| P-04 | 计划的「周期」是什么粒度？（周/月/自定义日期范围？）周期结束后未完成的计划如何处理？ | P1 |\n| P-05 | 需求是否有优先级？（P0/P1/P2 或高/中/低？）优先级影响什么？（审批速度？资源分配？） | P1 |\n\n### 5.2 审批流程（4 项）\n\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| P-06 | 文档提到「免评计划 → Amazon 运营总监 + 用户负责人」审批——是两者都必须通过（会签）还是任一通过即可（或签）？ | **P0** |\n| P-07 | 「指定负责人」的指定规则是什么？（按 ASIN 品类？按站点？按当前负载？人工指定？） | P1 |\n| P-08 | 审批超时如何处理？（审批人 N 天未处理，自动通过？自动驳回？升级到上级？） | P1 |\n| P-09 | 审批驳回后修改再提交，审批链是否重置还是从当前节点继续？ | P1 |\n\n### 5.3 自动触发（3 项）\n\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| P-10 | 自动触发的具体阈值是什么？（① ASIN 评分低于多少？② 差评在最近 N 天新增多少？③ 评价总数 < 目标值？） | **P0** |\n| P-11 | 自动触发是每天跑一次还是实时监控？（如果是实时，高频变化的 ASIN 会不会重复触发？） | P1 |\n| P-12 | 自动触发生成的需求是否自动进入评估环节还是需要人工确认后才进入？ | P2 |\n\n### 5.4 ASIN 管理（3 项）\n\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| P-13 | ASIN 数据来源和更新频率？（从 Amazon API 拉取？T+1？实时？手动导入？） | **P0** |\n| P-14 | ASIN 的「Listing 健康状态」如何定义？（评分 ≥ 4.2 = 健康？差评率 < X%？）健康度是否有多个等级？ | P1 |\n| P-15 | ASIN 是否有关联关系？（变体 ASIN、父 ASIN-子 ASIN）关联合并还是独立管理？ | P2 |\n\n### 5.5 计划执行衔接（2 项）\n\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| P-16 | 计划审批通过后如何流转到 outreach 子系统？（planning 主动推送？outreach 定时拉取？事件通知？） | P1 |\n| P-17 | 计划执行过程中是否可以调整目标数量或周期？调整是否需要重新审批？ | P2 |\n\n### 5.6 计划模板与复用（3 项）\n\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| P-18 | 是否需要计划模板功能？（对常推的 ASIN 创建可复用的计划模板——模板包含预设的渠道/目标数/周期？） | P1 |\n| P-19 | 周期性计划（如「每月 1 号自动对 ASIN X 发起回评计划」）是否支持？谁有权限创建？ | P2 |\n| P-20 | 计划是否可以暂停/恢复？（执行中因库存或供应链原因需暂停——暂停期间已触达的用户如何处理？） | P1 |\n\n### 5.7 预算与资源管理（3 项）\n\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| P-21 | 计划是否有预算字段？（返款金额、Code 成本、KOC 费用——是否需要预算审批？超出预算如何处理？） | P1 |\n| P-22 | 资源容量规划——同时可执行的计划数是否有上限？（受限于客服人力/EDM发送额度/IM频控？） | P1 |\n| P-23 | 是否需要计划执行成本的 ROI 计算？（返款总额 / 获得的评价数 = 单评价成本——系统自动计算还是手动录入？） | P2 |\n\n### 5.8 季节性/大促处理（3 项）\n\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| P-24 | Prime Day / Black Friday 等大促期间的计划是否有特殊处理？（提前锁定额度、加大推送量、豁免某些频控规则？） | P1 |\n| P-25 | 大促前的「预热计划」和大促后的「回评计划」是否需要在系统中作为计划间的依赖关系来管理？ | P2 |\n| P-26 | 季节性产品（圣诞装饰、夏季用品）的计划是否有时间敏感度标记？（错过季节窗口的计划自动降级？） | P2 |\n\n### 5.9 多站点/多市场（3 项）\n\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| P-27 | 不同 Amazon 站点的计划是否可以统一管理？（同一个 ASIN 在不同站点是独立计划还是关联计划？） | P1 |\n| P-28 | 多站点的审批人是否不同？（.com 的运营总监和 .co.uk 的运营总监可能是不同人） | P1 |\n| P-29 | 跨站点需求的冲突检测？（.com 和 .de 同时对同一真实的同一用户做了不同计划——算不算冲突？） | P2 |\n\n### 5.10 实施层面（3 项）\n\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| P-30 | 自动触发生成的需求如果无人处理（评估超时），是否自动驳回还是升级通知？ | P1 |\n| P-31 | 审批工作流引擎——是否有现成的审批引擎可复用？（还是需要从零开发状态机？） | P2 |\n| P-32 | 计划执行过程中用户反馈「不想再收到」——是标记为退订（outreach 处理）还是需要回写到 planning 的计划状态中？ | P1 |\n", + "wikilinks": [], + "category": "layer-requirements" + } + }, + { + "id": "doc:05_需求文档/03-子系统-额度与频控", + "type": "document", + "name": "子系统 03 — 额度与频控 (`quota`) v1.0", + "filePath": "05_需求文档/03-子系统-额度与频控.md", + "summary": "子系统 03 — 额度与频控 quota v1.0 2 子系统概述 4 维度 说明 代号 quota 核心职责 额度台账（测评4/免评4/累计12）、额度预占与释放、频控规则引擎、发送前终校 数据所有权 person quota ledgers , quota reservations , frequency control records 启动依赖 ide", + "tags": [ + "05_需求文档", + "需求文档" + ], + "complexity": "moderate", + "knowledgeMeta": { + "content": "# 子系统 03 — 额度与频控 (`quota`) v1.0\n 2|\n## 子系统概述\n 4|\n| 维度 | 说明 |\n| --- | --- |\n| 代号 | `quota` |\n| 核心职责 | 额度台账（测评4/免评4/累计12）、额度预占与释放、频控规则引擎、发送前终校 |\n| 数据所有权 | `person_quota_ledgers`, `quota_reservations`, `frequency_control_records` |\n| 启动依赖 | identity（软依赖，额度按真实人计算，未归并时按单一账号） |\n| 外部系统依赖 | 无直接外部依赖 |\n 12|\n---\n 14|\n## 1. 模块划分\n 16|\n```\n┌─────────────────────────────────────────────────────────────┐\n│ quota 子系统 │\n│ │\n│ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │\n│ │ M1: 额度台账 │ │ M2: 预占管理 │ │ M3: 频控引擎 │ │\n│ │ (Ledger) │→│ (Reservation)│ │ (FreqCtrl) │ │\n│ └──────┬───────┘ └──────┬───────┘ └──────┬───────┘ │\n│ │ │ │ │\n│ ▼ ▼ ▼ │\n│ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │\n│ │ M4: 终校服务 │ │ M5: 额度管理 │ │ M6: 对外 API │ │\n│ │ (FinalCheck)│ │ Admin │ │ Gateway │ │\n│ └──────────────┘ └──────────────┘ └──────────────┘ │\n│ │\n└─────────────────────────────────────────────────────────────┘\n```\n 34|\n| # | 模块 | 代号 | 职责 |\n| --- | --- | --- | --- |\n| M1 | 额度台账 | `quota-ledger` | 维护真实人三层额度（测评4/免评4/累计12）、已用/进行中/已预占计数 |\n| M2 | 预占管理 | `reservation-mgr` | 额度预占创建、确认占用、超时释放；跨计划重复入选检测 |\n| M3 | 频控引擎 | `freq-control` | 渠道频控（IM/EDM/APP/TEL 最近触达间隔）、单 ASIN 短期触达次数、退订/投诉屏蔽 |\n| M4 | 终校服务 | `final-check` | 发送前合并校验（最新额度 + 最新风险 + 最新未关闭工单），准入/撤出决策 |\n| M5 | 额度管理 Admin | `quota-admin` | 额度手动调整、额度重置、额度审计 |\n| M6 | 对外 API Gateway | `quota-api` | 供 planning（人群生成）、outreach（发送前校验）、review（提交后确认）调用 |\n 43|\n---\n 45|\n## 2. 各模块内外说明\n 47|\n### 2.1 M1: 额度台账\n 49|\n| 维度 | 说明 |\n| --- | --- |\n| **对内** | 按真实人维护三种额度：月度测评（已完成+进行中+已预占）、月度免评（同上）、累计真实提交评价（永久累计）；额度计数时点明确（提交评价立即计数12、不会因 Amazon 未展示回退）；接近上限时预警 |\n| **对外接口** | `GET /api/quota/ledger/{person_id}` — 读取当前台账 |\n| **数据写入** | `person_quota_ledgers` |\n| **依赖** | `GET /api/identity/person` — 获取真实人 ID |\n 56|\n### 2.2 M2: 预占管理\n 58|\n| 维度 | 说明 |\n| --- | --- |\n| **对内** | 人群生成时预占额度（测评/免评）；计算：已用+进行中+已预占+本次拟发送 > 上限 → 拦截；剩余不足但>0 → 预警池 → 发送前人工复核；预占有效期管理，超时自动释放；并发占用控制（同一真实人跨计划重复入选检测） |\n| **对外接口** | `POST /api/quota/reserve` — 创建预占；`POST /api/quota/commit` — 确认占用；`POST /api/quota/release` — 释放预占 |\n| **数据写入** | `quota_reservations` |\n 64|\n### 2.3 M3: 频控引擎\n 66|\n| 维度 | 说明 |\n| --- | --- |\n| **对内** | 四种频控维度：①渠道频控（IM/EDM/APP/TEL 最近触达间隔）②单 ASIN 短期内触达同一用户次数 ③用户反感度（投诉/退订状态）④用户在客服工单中暂不触达；频控规则可配置 |\n| **对外接口** | `GET /api/quota/freq-check/{person_id}?channel=IM&asin=xxx` — 频控检查 |\n| **数据写入** | `frequency_control_records` |\n| **依赖** | 触达历史来自 outreach（`GET /api/outreach/history/{person_id}`） |\n 73|\n### 2.4 M4: 终校服务\n 75|\n| 维度 | 说明 |\n| --- | --- |\n| **对内** | 发送前做最终校验：①重新读取最新额度（防止发送和预占之间额度变化）②重新读取最新风险状态 ③重新读取最新未关闭工单；三者全部通过→准入发送；任一新增超限/风险/工单→撤出本批次 |\n| **对外接口** | `POST /api/quota/final-check` — 批量终校（输入 person_ids + plan_id，返回每个的准入/撤出决策） |\n| **数据写入** | 终校结果写入审计日志 |\n| **依赖** | `GET /api/risk/check/{person_id}`；`GET /api/tickets?person_id=&status=open` |\n 82|\n### 2.5 M5: 额度管理 Admin\n 84|\n| 维度 | 说明 |\n| --- | --- |\n| **对内** | 额度手动调整（运营确认某次测评不计入额度等）；额度重置（新月份额度初始化）；额度审计（谁改了什么额度） |\n| **对外接口** | 管理 API |\n 89|\n### 2.6 M6: 对外 API Gateway\n 91|\n| 维度 | 说明 |\n| --- | --- |\n| **对外接口** | `GET /api/quota/check/{person_id}?type=测评` — 额度查询+可用判断；`POST /api/quota/reserve` — 预占；`POST /api/quota/commit` — 确认；`POST /api/quota/release` — 释放；`POST /api/quota/final-check` — 终校 |\n 95|\n---\n 97|\n## 3. 对外 API 契约（草案）\n 99|\n| 接口 | 方法 | 输入 | 输出 | 消费者 |\n| --- | --- | --- | --- | --- |\n| 额度查询 | `GET /api/quota/check/{person_id}?type=REVIEW` | person_id + 额度类型 | `{used, in_progress, reserved, remaining, status(sufficient/warning/exceeded)}` | planning, outreach |\n| 批量预占 | `POST /api/quota/reserve` | `[{person_id, type, plan_id, count}]` | `[{person_id, success, reservation_id}]` | planning（人群生成时） |\n| 确认占用 | `POST /api/quota/commit` | `[{reservation_id}]` | `[{reservation_id, committed}]` | review（用户提交评价后） |\n| 释放预占 | `POST /api/quota/release` | `[{reservation_id}]` | `[{success}]` | planning（计划取消时） |\n| 频控检查 | `GET /api/quota/freq-check/{person_id}?channel=&asin=` | person_id + 渠道 + ASIN | `{allowed, reason, cooldown_until}` | outreach（发送前） |\n| 发送前终校 | `POST /api/quota/final-check` | `[{person_id, plan_id}]` | `[{person_id, decision: APPROVED/WITHDRAWN, reasons}]` | outreach（发送前最后一步） |\n 108|\n---\n 110|\n## 4. 数据对象\n 112|\n| 对象 | 核心字段 | 说明 |\n| --- | --- | --- |\n| `person_quota_ledgers` | ledger_id, person_id, quota_type (MONTHLY_REVIEW/MONTHLY_EXEMPTION/LIFETIME_SUBMISSION), period, used, in_progress, reserved, limit_value, status | 三层额度台账 |\n| `quota_reservations` | reservation_id, person_id, ledger_id, plan_id, count, status (RESERVED/COMMITTED/RELEASED/EXPIRED), reserved_at, expires_at | 额度预占记录 |\n| `frequency_control_records` | freq_id, person_id, channel, asin, last_contact_at, contact_count_period, status | 频控记录 |\n 118|\n---\n 120|\n## 5. 业务澄清问题清单 — quota\n 122|\n### 5.1 额度规则细化（5 项）\n 124|\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| Q-01 | 月度额度按自然月还是 30 天滚动？如果是自然月：①预占在 1 月 31 日，2 月 1 日释放还是保留？②1 月 31 日晚 23:59 的预占跨月怎么处理？ | **P0** |\n| Q-02 | 「测评 4 次」中的「次」定义：是指参与 4 个不同的测评计划，还是提交 4 条评价？（如果 1 个计划要求用户提交 3 条评价，占 3 次还是 1 次？） | **P0** |\n| Q-03 | 「累计 12 个真实提交评价」是永久上限还是可以动态调整？（例如用户长期优质且评价质量高，是否可以人工放宽？放宽流程？） | P1 |\n| Q-04 | 测评和免评额度是否独立？（测评 4 次 + 免评 4 次 = 同一真实人一月最多参与 8 个计划？）还是测评和免评共享总额度？ | P1 |\n| Q-05 | 额度计算中「进行中」的定义——什么状态才算进行中？（已生成人群？已发送触达？用户已回应？已提交评价待核验？） | P1 |\n 132|\n### 5.2 预占机制（4 项）\n 134|\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| Q-06 | 预占有效期多长？（预占后用户始终未响应，多久释放？1 天？7 天？计划周期结束？） | **P0** |\n| Q-07 | 预占释放后是否可以自动重新分配给同一计划的其他用户？是否触发重新生成人群？ | P1 |\n| Q-08 | 跨计划并发占用检测——同一真实人在计划 A 和计划 B 同时被入选，谁先预占谁得？还是按计划优先级？ | P1 |\n| Q-09 | 预占是否可手动取消/释放？（运营发现某用户不应计入某计划时） | P2 |\n 141|\n### 5.3 频控规则（4 项）\n 143|\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| Q-10 | 各渠道频控的具体阈值是什么？（IM 每日最多 X 次？EDM 每周最多 Y 封？APP Push 每日最多 Z 条？TEL 每日最多 N 通？） | **P0** |\n| Q-11 | 频控规则是否区分计划类型？（紧急催评是否可以突破频控？） | P1 |\n| Q-12 | 频控是全局统一配置还是按用户层级可调整？（A 类和 C 类用户频控规则是否不同？） | P1 |\n| Q-13 | 「单 ASIN 短期触达次数」——多少天内触达多少次算超标？ | P2 |\n 150|\n### 5.4 预警与异常（3 项）\n 152|\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| Q-14 | 预警阈值如何设定？（剩余 1 次时预警？剩余 N% 时预警？不同类型额度预警阈值是否不同？） | P1 |\n| Q-15 | 终校中「新增风险」的判断——距离上次风险检查超过多少时间需重查？还是每次终校都实时查 risk？ | P1 |\n| Q-16 | 额度数据异常时的处理策略？（台账数据与预占记录不一致、预占未释放导致额度泄漏——系统如何自动发现和修复？） | P2 |\n 158|\n### 5.5 额度异常与纠错（4 项）\n\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| Q-17 | 用户反馈「我明明只参与了 3 次测评，系统说我已用 4 次」——申诉流程？谁有权限查台账和修正？ | P1 |\n| Q-18 | 额度台账的审计追踪——每次额度变更（预占/确认/释放/手动调整）是否记录完整操作人和原因？保留多久？ | P1 |\n| Q-19 | 数据异常自动检测——台账数据与预占记录之和是否需要对账？系统是否定期自动化对账并报告差异？ | P1 |\n| Q-20 | 如果发现「额度泄漏」（预占未释放导致额度永久被占），系统如何自动发现和修复？（定时扫描过期预占？手动触发对账？） | P2 |\n\n### 5.6 紧急/例外处理（4 项）\n\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| Q-21 | 大促期间（Prime Day/Black Friday）是否需要临时额度提升？（测评 4→8？）由谁审批？临时额度有效期？ | P1 |\n| Q-22 | 高价值用户是否可以突破额度限制？（例如 KOC 级别的用户需要超额参与——人工审批流程？） | P1 |\n| Q-23 | 「紧急计划」是否可以跳过频控？（例如 Listing 评分暴跌至 3.8 需要紧急大量催评——是否豁免部分频控规则？） | P1 |\n| Q-24 | 额度手动调整是否需要审批？审批权限？（谁可以手动给某人加/减可用额度？） | P2 |\n\n### 5.7 跨站点/跨平台额度（3 项）\n\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| Q-25 | 额度是否跨 Amazon 站点？（.com 参与了 2 次测评 + .co.uk 参与了 3 次 → 全局算 5 次还是各自独立？） | P1 |\n| Q-26 | 累计 12 个评价是否跨站点统计？（在 .com 提交了 8 个 + .co.uk 提交了 5 个 → 是否算 13 个超限？） | P1 |\n| Q-27 | 未来扩展到非 Amazon 平台，额度体系是否独立？（eBay 的测评额度与 Amazon 的额度是否共享？） | P2 |\n\n### 5.8 额度可见性（2 项）\n\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| Q-28 | 用户是否能看到自己的额度状态？（APP 端显示「本月还可参与 2 次测评」——是否对用户可见？） | P2 |\n| Q-29 | 运营视角的额度看板——能否看到「全局额度使用率」「各真实人的额度分布」「额度预警用户列表」？ | P1 |\n\n### 5.9 实施层面（3 项）\n\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| Q-30 | 终校服务的性能要求——批量终校（一次可能几百人）需要在多少 ms 内完成？（涉及跨子系统调用 risk + support） | P2 |\n| Q-31 | 频控规则是否需要热更新（不重启服务即可调整阈值）？配置管理方案？ | P1 |\n| Q-32 | 额度台账历史数据的初始化——旧系统的数据如何映射到三层额度模型？（无「真实人」概念的老数据如何归入？） | P1 |", + "wikilinks": [], + "category": "layer-requirements" + } + }, + { + "id": "doc:05_需求文档/04-子系统-多渠道触达引擎", + "type": "document", + "name": "子系统 04 — 多渠道触达引擎 (`outreach`) v1.0", + "filePath": "05_需求文档/04-子系统-多渠道触达引擎.md", + "summary": "子系统 04 — 多渠道触达引擎 outreach v1.0 2 子系统概述 4 维度 说明 代号 outreach 核心职责 渠道路由决策、渠道去重、IM/EDM/APP Push/TEL 渠道调度执行、触达历史管理 数据所有权 channel route decisions , channel dedup records , im interaction", + "tags": [ + "05_需求文档", + "需求文档" + ], + "complexity": "moderate", + "knowledgeMeta": { + "content": "# 子系统 04 — 多渠道触达引擎 (`outreach`) v1.0\n 2|\n## 子系统概述\n 4|\n| 维度 | 说明 |\n| --- | --- |\n| 代号 | `outreach` |\n| 核心职责 | 渠道路由决策、渠道去重、IM/EDM/APP Push/TEL 渠道调度执行、触达历史管理 |\n| 数据所有权 | `channel_route_decisions`, `channel_dedup_records`, `im_interaction_records`, `im_flow_tags`, `edm_message_events`, `edm_user_behavior_profiles`, `app_touch_events`, `tel_call_records` |\n| 启动依赖 | identity / planning / quota（均为软依赖） |\n| 外部系统依赖 | JOYHUB（IM 通道）、ESP（EDM）、FCM/APNs（APP Push）、电话系统（TEL） |\n 12|\n---\n 14|\n## 1. 模块划分\n 16|\n```\n┌─────────────────────────────────────────────────────────────┐\n│ outreach 子系统 │\n│ │\n│ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │\n│ │ M1: 渠道路由 │ │ M2: 渠道去重 │ │ M3: IM 执行 │ │\n│ │ + 优先级 │→│ │→│ 引擎 │ │\n│ └──────────────┘ └──────────────┘ └──────┬───────┘ │\n│ │ │\n│ ┌──────────────┐ ┌──────────────┐ ┌──────┴───────┐ │\n│ │ M4: EDM 执行 │ │ M5: APP Push │ │ M6: TEL 执行 │ │\n│ │ 引擎 │ │ 引擎 │ │ 引擎 │ │\n│ └──────────────┘ └──────────────┘ └──────────────┘ │\n│ │\n│ ┌──────────────┐ ┌──────────────┐ │\n│ │ M7: 触达历史 │ │ M8: 对外 API │ │\n│ │ 服务 │ │ Gateway │ │\n│ └──────────────┘ └──────────────┘ │\n│ │\n└─────────────────────────────────────────────────────────────┘\n```\n 38|\n| # | 模块 | 职责 |\n| --- | --- | --- |\n| M1 | 渠道路由+优先级 | 按用户状态路由到最优渠道（APP活跃→IM优先 / 未注册→EDM优先 / 高价值无响应→TEL / C类→IM免评卡片） |\n| M2 | 渠道去重 | 同一计划同一用户不重复走多渠道路由；工单中暂停自动触达；已提交待核验暂停催评 |\n| M3 | IM 执行引擎 | IM 推送、用户分层（A未参与/B参与过/C长期测评人）、回评/测评/免评卡片推送、催评、提交核验、返款通知 |\n| M4 | EDM 执行引擎 | EDM 发送、送达/打开/点击追踪、行为画像、节奏控制、退订/硬退信处理 |\n| M5 | APP Push 引擎 | APP 推送、触发源管理（绑定玩具/不活跃/计划到期/Listing紧急/活动）、响应追踪 |\n| M6 | TEL 执行引擎 | 电话任务生成、拨打前准备（用户画像+风险检查+历史沟通）、通话记录、重试策略 |\n| M7 | 触达历史服务 | 统一触达历史查询（跨渠道聚合）、供 quota（频控）、identity（上下文卡）调用 |\n| M8 | 对外 API Gateway | 统一对外 API |\n 49|\n---\n 51|\n## 2. 各模块内外说明\n 53|\n### 2.1 M1: 渠道路由+优先级\n 55|\n| 维度 | 说明 |\n| --- | --- |\n| **对内** | 接收 planning 的已批准计划，按用户状态矩阵决定渠道：APP活跃+已绑定→IM首选；APP低活跃→EDM补充+APP Push召回；未注册→EDM首选→引导注册后转IM；高价值+多次无响应→TEL；C类（累计≥12）→IM免评卡片+KOC/KOL协同 |\n| **对外接口** | `POST /api/outreach/route` — 输入计划+用户，返回路由决策 |\n| **数据写入** | `channel_route_decisions` |\n| **依赖** | `GET /api/identity/context/{person_id}` — 用户状态 |\n 62|\n### 2.2 M2: 渠道去重\n 64|\n| 维度 | 说明 |\n| --- | --- |\n| **对内** | 执行去重规则（同一计划同一用户首选渠道、工单中暂停、已提交评价暂停、退订某渠道永久排除、强关联风险全暂停、弱关联降频+提示） |\n| **对外接口** | `GET /api/outreach/dedup-check?person_id=&plan_id=` |\n| **数据写入** | `channel_dedup_records` |\n| **依赖** | `GET /api/tickets?person_id=&status=open`（support）；`GET /api/risk/check/{person_id}`（risk） |\n 71|\n### 2.3 M3: IM 执行引擎\n 73|\n| 维度 | 说明 |\n| --- | --- |\n| **对内** | 用户分层逻辑（A未参与/B参与过但<12/C≥12长期测评人）；分层推送策略（A推回评卡片/B先催评再二次转化/C仅免评）；提交后的核验与流转（订单号核实→登记→补全信息→返款→二次转化）；标签管理（9 种核心标签如「xx产品已回评用户」「xx产品测评待返款用户」等） |\n| **对外接口** | `POST /api/outreach/im/send` — 发送 IM 消息 |\n| **数据写入** | `im_interaction_records`, `im_flow_tags` |\n| **依赖** | JOYHUB（IM 通道）；`GET /api/quota/check/{person_id}` |\n| **待确认** | IM 是 WhatsApp 还是自研 IM？通道对接方式？ |\n 81|\n### 2.4 M4: EDM 执行引擎\n 83|\n| 维度 | 说明 |\n| --- | --- |\n| **对内** | 推送前检查（身份→风险→退订→资格→国家）；行为筛选（打开/点击/回复/频率）；节奏判断（适合触达/需降频/不适合）；发送后追踪（送达→打开→点击→回复→退订）；转化路径（下载注册APP→转IM / 直接回复邮件→生成客服工单 / 未响应→再触达队列） |\n| **对外接口** | `POST /api/outreach/edm/send` — 发送 EDM |\n| **数据写入** | `edm_message_events`, `edm_user_behavior_profiles` |\n| **依赖** | ESP 邮件服务 |\n| **待确认** | EDM 模板在哪里管理？模板变量（用户名/产品名/链接）如何填充？ |\n 91|\n### 2.5 M5: APP Push 引擎\n 93|\n| 维度 | 说明 |\n| --- | --- |\n| **对内** | 5 种触发源（绑定新玩具/不活跃/计划到期/Listing紧急/活动）；推送前过滤（身份+风险+频控+标签）；响应追踪（点击打开→落地页 / 忽略→短期不重复推 / 卸载→转EDM候选池）；APP 内动作分流（提交回评/测评→IM核验 / 联系客服→工单 / 浏览→更新活跃标签） |\n| **对外接口** | `POST /api/outreach/app/push` — 发送 APP Push |\n| **数据写入** | `app_touch_events` |\n| **依赖** | FCM/APNs |\n| **待确认** | 是否复用 JOYHUB 现有 Push 通道？ |\n 101|\n### 2.6 M6: TEL 执行引擎\n 103|\n| 维度 | 说明 |\n| --- | --- |\n| **对内** | 7 种触发场景（答应配合超时/高价值跟进/复杂售后/多次无响应/紧急Listing/Amazon来电/外呼任务）；拨打前准备 5 步（查用户完整画像→查风险→查历史沟通→准备话术→生成电话工单）；通话结果 5 种（售后问题解决→引导回评 / 直接配合→登记答应配合 / 拒绝→记录 / 疑似诈骗→转风险 / 未接通→重试）；重试策略（<3次重拨 / ≥3次降级EDM或关闭） |\n| **对外接口** | `POST /api/outreach/tel/task` — 创建 TEL 任务 |\n| **数据写入** | `tel_call_records` |\n| **依赖** | 电话系统（外呼/来电） |\n 110|\n### 2.7 M7: 触达历史服务\n 112|\n| 维度 | 说明 |\n| --- | --- |\n| **对内** | 跨渠道聚合触达历史（IM/EDM/APP/TEL）；提供统一查询接口供 quota（频控）和 identity（上下文卡）消费 |\n| **对外接口** | `GET /api/outreach/history/{person_id}` |\n| **数据写入** | 只读聚合 |\n 118|\n---\n 120|\n## 3. 对外 API 契约（草案）\n 122|\n| 接口 | 方法 | 输入 | 输出 | 消费者 |\n| --- | --- | --- | --- | --- |\n| 触达历史 | `GET /api/outreach/history/{person_id}` | person_id | `{im[], edm[], app[], tel[]}` | quota（频控）, identity（上下文卡） |\n| 执行触达 | `POST /api/outreach/send` | `{plan_id, person_ids[], channel, content}` | `{task_id, status}` | planning |\n| 渠道路由决策 | `POST /api/outreach/route` | `{person_id, plan_id}` | `{recommended_channel, alternatives[]}` | planning |\n| IM 消息发送 | `POST /api/outreach/im/send` | `{person_id, msg_type, content}` | `{message_id}` | 内部 |\n 129|\n---\n 131|\n## 4. 数据对象\n 133|\n| 对象 | 核心字段 | 说明 |\n| --- | --- | --- |\n| `channel_route_decisions` | decision_id, person_id, plan_id, selected_channel, reason, decided_at | 渠道路由决策 |\n| `channel_dedup_records` | dedup_id, person_id, plan_id, channel, status(BLOCKED/ALLOWED), block_reason | 渠道去重记录 |\n| `im_interaction_records` | interaction_id, person_id, msg_type(PUSH_CARD/REVIEW_CARD/EXEMPTION_CARD/REMINDER/REFUND_NOTICE), direction(OUTBOUND/INBOUND), content, status, created_at | IM 交互记录 |\n| `im_flow_tags` | tag_id, person_id, tag_type, tag_value, tagged_at | IM 流程标签（如 xx产品待返款等） |\n| `edm_message_events` | event_id, person_id, email, event_type(SENT/DELIVERED/OPENED/CLICKED/REPLIED/UNSUBSCRIBED/HARD_BOUNCED), occurred_at | EDM 事件 |\n| `edm_user_behavior_profiles` | profile_id, person_id, email, last_opened_at, total_opens, consecutive_no_open, last_replied_at, monthly_received, status | EDM 用户行为画像 |\n| `app_touch_events` | event_id, person_id, trigger_type, push_status, response, occurred_at | APP Push 事件 |\n| `tel_call_records` | call_id, person_id, ticket_id, direction(OUTBOUND/INBOUND), call_status, duration, outcome, retry_count, recorded_at | TEL 通话记录 |\n 144|\n---\n 146|\n## 5. 业务澄清问题清单 — outreach\n 148|\n### 5.1 渠道优先级路由（4 项）\n 150|\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| O-01 | 路由规则是否可配置？（例如针对某个站点用户调整 IM > EDM 的优先级）配置界面在 outreach 内还是在独立配置管理？ | **P0** |\n| O-02 | 「APP 低活跃」的判定标准是什么？（N 天未打开？N 天未点击推送？）阈值是否可配置？ | P1 |\n| O-03 | 高优先级渠道发送失败（退信/未送达）后，是否自动降级到下一渠道？降级是否有冷却时间？ | P1 |\n| O-04 | C 类用户（累计≥12）只推免评——如果免评计划也没有，是完全不推还是推品牌/活动内容？ | P2 |\n 157|\n### 5.2 IM 通道（4 项）\n 159|\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| O-05 | IM 使用的具体平台是什么？（WhatsApp Business API / 自研 JOYHUB IM / Messenger？）不同平台的 API 能力和限制？ | **P0** |\n| O-06 | IM 的「分层」是系统自动判断还是人工可干预？（一个 B 类用户会不会被错误标记为 C 类？如何修正？） | **P0** |\n| O-07 | IM 推送中「测评卡片」的具体形式是什么？（带按钮的消息模板？需要用户填表单？）模板在哪里管理？ | P1 |\n| O-08 | IM 中的「订单号核实」——核实的数据源是什么？（比对内部订单表？Amazon 订单 API？）核实失败的转人工流程？ | P1 |\n 166|\n### 5.3 EDM 通道（4 项）\n 168|\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| O-09 | 当前使用的邮件服务是什么？（SendGrid/Mailchimp/SES/自建？）有没有现成 API 和 Webhook 追踪？ | **P0** |\n| O-10 | EDM 模板（邮件内容、样式、多语言）在哪里管理？属于 outreach 还是独立内容管理子系统？ | P1 |\n| O-11 | 「EDM 行为画像」中的「最近 3/5 次 0 打开」——3 次和 5 次是两个独立指标还是二选一？各自对应什么策略？ | P1 |\n| O-12 | EDM 发送量和频控——单日最大发送量有限制吗？（ESP 的每日限额？） | P1 |\n 175|\n### 5.4 APP Push（3 项）\n 177|\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| O-13 | APP Push 是否复用 JOYHUB 的现有推送通道？还是需要独立接入 FCM（Android）和 APNs（iOS）？ | **P0** |\n| O-14 | APP Push 和 IM 消息的分工——文档第 11.2 节给了对照表，但边界是否绝对？（例如\"计划到期提醒\"是否可能同时走 APP Push 和 IM？） | P1 |\n| O-15 | APP 落地页——推送点击后跳转到哪个页面？（APP 内的测评页？IM 对话页？）落地页由哪个团队/子系统负责？ | P2 |\n 183|\n### 5.5 TEL 通道（3 项）\n 185|\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| O-16 | 电话系统使用什么方案？（自建 SIP PBX / Twilio / 其他云呼叫中心？）是否已有通话记录？ | **P0** |\n| O-17 | 「拨打前准备」第 2 步「查风险：强关联命中→暂停拨打→先复核」——复核由谁来做？（风险人员？客服组长？）复核时长预期？ | P1 |\n| O-18 | 电话中「尽量确认」的字段（购买平台、订单号、产品型号、购买时间、问题类型、凭证）如果用户不愿意/无法提供——哪些是必须确认的？哪些可以跳过？ | P1 |\n 191|\n### 5.6 消息内容与合规（4 项）\n\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| O-19 | 消息内容是否需要审核？（IM 推送文案、EDM 邮件内容、APP Push——上线前是否需要审核？审核流程？） | P1 |\n| O-20 | EDM 合规要求——是否遵守 CAN-SPAM Act（美国）、GDPR（欧洲）、CASL（加拿大）？退订机制是否满足法律要求？ | P1 |\n| O-21 | IM 平台的合规限制——WhatsApp 等平台禁止垃圾消息和特定类型内容（如测评引导）——是否有合规风险？ | P1 |\n| O-22 | 消息发送的时区感知——美国用户、英国用户、德国用户的推送时间是否需要本地化？（用户当地时间的白天而非半夜） | P1 |\n\n### 5.7 消息策略与实验（3 项）\n\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| O-23 | 是否需要 A/B 测试能力？（同一计划的两组用户收到不同文案/不同发送时间——对比转化率？） | P2 |\n| O-24 | 消息打开率/点击率/转化率的追踪和报表？是否需要自动优化发送策略（高打开率的文案模板优先使用）？ | P2 |\n| O-25 | 用户反馈「消息太频繁/内容不相关」——是否有投诉/退订统计和预警？（投诉率超过 X% 暂停该类型推送？） | P1 |\n\n### 5.8 IM 通道补充（3 项）\n\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| O-26 | IM 消息的「已读」状态是否能获取？（WhatsApp 的蓝色双勾——能否用于判断用户是否看到消息？） | P1 |\n| O-27 | IM 用户提交的「评论截图/链接」——如何自动验证截图的真实性？（防止用户 PS 假截图？是否需要 OCR 识别截图内容？） | P1 |\n| O-28 | IM 中的返款通知——返款是系统自动触发还是人工触发？返款状态如何回写到 outreach？ | P1 |\n\n### 5.9 EDM 通道补充（3 项）\n\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| O-29 | EDM 的「硬退信」和「投诉」是否自动同步到 identity 的风险标记？（硬退信用户是否需要进入风险观察？） | P1 |\n| O-30 | EDM 引导用户下载 APP——是否在邮件中嵌入归因链接（deferred deep link）以追踪转化来源？ | P2 |\n| O-31 | EDM 的发送域名和 IP 预热策略？（新域名/IP 直接大批量发送会被 ESP 判定为垃圾邮件——需要渐进式预热？） | P2 |\n\n### 5.10 TEL 通道补充（3 项）\n\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| O-32 | 电话录音是否需要存储？存储多久？谁有权调取录音？（涉及合规和隐私） | P1 |\n| O-33 | 不同国家的电话合规要求——美国需提前告知录音、德国的 GDPR 限制——如何处理？ | P1 |\n| O-34 | TEL 任务的优先级和分配——多个外呼任务同时存在时，客服按什么顺序拨打？（先打高价值用户？先打答应配合超时的？） | P1 |\n\n### 5.11 实施层面（4 项）\n\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| O-35 | 各外部通道的 rate limit 和计费模式？（WhatsApp 按消息数计费？EDM 按发送量计费？）是否需要成本控制？ | P1 |\n| O-36 | 消息发送是同步还是异步？（用户点「发送」后立即返回还是后台队列处理？失败重试策略？） | P1 |\n| O-37 | 多渠道消息的发送顺序保证？（「先发 IM 提醒→24h 后无回复再发 EDM」——这种时序依赖如何实现？定时任务？延迟队列？） | P2 |\n| O-38 | 异常场景——如果某渠道 100% 发送失败（ESP 宕机/WhatsApp API 限流）——是否自动切换备用渠道？ | P2 |", + "wikilinks": [], + "category": "layer-requirements" + } + }, + { + "id": "doc:05_需求文档/05-子系统-客服工单与管理", + "type": "document", + "name": "子系统 05 — 客服工单与管理 (`support`) v1.0", + "filePath": "05_需求文档/05-子系统-客服工单与管理.md", + "summary": "子系统 05 — 客服工单与管理 support v1.0 2 子系统概述 4 维度 说明 代号 support 核心职责 工单生命周期管理、自动分配、答应配合状态机、排班出勤管理、绩效统计 数据所有权 support tickets , support followups , support assignment logs , attendance rec", + "tags": [ + "05_需求文档", + "需求文档" + ], + "complexity": "moderate", + "knowledgeMeta": { + "content": "# 子系统 05 — 客服工单与管理 (`support`) v1.0\n 2|\n## 子系统概述\n 4|\n| 维度 | 说明 |\n| --- | --- |\n| 代号 | `support` |\n| 核心职责 | 工单生命周期管理、自动分配、答应配合状态机、排班出勤管理、绩效统计 |\n| 数据所有权 | `support_tickets`, `support_followups`, `support_assignment_logs`, `attendance_records`, `shift_schedules`, `support_performance_snapshots` |\n| 启动依赖 | identity（软依赖，无上下文卡时可先跑工单） |\n| 外部系统依赖 | 无直接外部依赖（电话记录来自 outreach TEL 模块） |\n 12|\n---\n 14|\n## 1. 模块划分\n 16|\n```\n┌─────────────────────────────────────────────────────────────┐\n│ support 子系统 │\n│ │\n│ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │\n│ │ M1: 工单管理 │ │ M2: 自动分配 │ │ M3: 答应配合 │ │\n│ │ (Ticket) │→│ (Assign) │ │ 状态机 │ │\n│ └──────┬───────┘ └──────┬───────┘ └──────┬───────┘ │\n│ │ │ │ │\n│ ▼ ▼ ▼ │\n│ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │\n│ │ M4: 排班出勤 │ │ M5: 绩效统计 │ │ M6: 对外 API │ │\n│ │ 管理 │ │ │ │ Gateway │ │\n│ └──────────────┘ └──────────────┘ └──────────────┘ │\n│ │\n└─────────────────────────────────────────────────────────────┘\n```\n 34|\n| # | 模块 | 职责 |\n| --- | --- | --- |\n| M1 | 工单管理 | 工单创建、分类、状态流转（待分配→已分配→处理中→等待用户/等待内部→已解决/疑似诈骗→已关闭） |\n| M2 | 自动分配 | 按班次+在线状态+当前负载+最大工单数自动分配到客服组；组长再分派到组员 |\n| M3 | 答应配合状态机 | 独立的答应配合状态流转（已答应→待分配→待提醒→等待提交→已提交/超时→需再次联系→关闭） |\n| M4 | 排班出勤管理 | 排班设置、出勤记录（应出勤/实际出勤/迟到/早退/请假/缺勤）、在线客服池维护 |\n| M5 | 绩效统计 | 回复效率（回复用户数/处理工单数/首次回复时长分布）；转化统计（RSO回评/RDO测评登记订单数/获取评价数/完成率）；目标完成统计 |\n| M6 | 对外 API Gateway | 供其他子系统创建工单、查询工单状态、查询绩效数据 |\n 43|\n---\n 45|\n## 2. 各模块内外说明\n 47|\n### 2.1 M1: 工单管理\n 49|\n| 维度 | 说明 |\n| --- | --- |\n| **对内** | 5 种入口（用户消息进入/推送转人工/售后触发/风险触发/电话后续）；工单状态流转（待分配→已分配→处理中→等待用户/等待内部→已解决/疑似诈骗→已关闭）；5 种处理结果（等待用户回复/等待内部协同/答应配合/疑似诈骗/已解决） |\n| **对外接口** | `POST /api/tickets` — 创建工单；`PUT /api/tickets/{id}/status` — 更新状态 |\n| **数据写入** | `support_tickets` |\n| **依赖** | `GET /api/identity/context/{person_id}` — 展示用户上下文卡 |\n| **待确认** | 工单类型分类维度？（售后/催评/风险/其他？是否需要自定义分类？） |\n 57|\n### 2.2 M2: 自动分配\n 59|\n| 维度 | 说明 |\n| --- | --- |\n| **对内** | 分配算法（查班次+在线状态+当前负载+最大工单数→自动分配到客服组）；组长可在组内重新分派到具体组员；分配日志记录 |\n| **对外接口** | 内部服务 |\n| **数据写入** | `support_assignment_logs` |\n| **依赖** | M4 排班出勤数据 |\n| **待确认** | 「当前负载」按什么计算？（未关闭工单数？最近 N 小时处理量？两者加权？） |\n 67|\n### 2.3 M3: 答应配合状态机\n 69|\n| 维度 | 说明 |\n| --- | --- |\n| **对内** | 独立于工单状态的状态机（已答应配合→待分配负责人→待提醒→等待提交→已提交评价/已提交反馈→超时→需再次联系→已关闭）；防止承诺用户流失；超时提醒机制 |\n| **对外接口** | `POST /api/support/followups` — 创建跟进任务；`PUT /api/support/followups/{id}` — 更新状态 |\n| **数据写入** | `support_followups` |\n| **待确认** | 答应配合后多少天未提交算超时？超时后提醒频率？多次提醒无果后是否降级？ |\n 76|\n### 2.4 M4: 排班出勤管理\n 78|\n| 维度 | 说明 |\n| --- | --- |\n| **对内** | 排班设置（按日/周的班次安排）；出勤记录（应出勤/实际出勤/出勤率/迟到/早退/请假/缺勤）；在线客服池（排班+在线状态→可用客服列表） |\n| **对外接口** | `GET /api/support/available-agents` — 查询当前可用客服 |\n| **数据写入** | `attendance_records`, `shift_schedules` |\n| **待确认** | 排班是否对接外部 HR 系统还是独立管理？客服手动签入/签出？ |\n 85|\n### 2.5 M5: 绩效统计\n 87|\n| 维度 | 说明 |\n| --- | --- |\n| **对内** | 回复效率（回复用户数、处理工单数、发送消息数、首次回复时长：平均/中位数/最大/最小）；转化统计（RSO 回评登记订单数、RDO 测评登记订单数、获取评价数、评价完成率）；目标完成（月目标、当前完成、完成率、历史趋势）；主管看板 |\n| **对外接口** | `GET /api/support/stats?agent_id=&period=` — 绩效数据查询 |\n| **数据写入** | `support_performance_snapshots`（定时快照） |\n| **待确认** | 绩效统计周期（日/周/月？）主管看板是否需要实时数据还是 T+1 汇总？ |\n 94|\n---\n 96|\n## 3. 对外 API 契约（草案）\n 98|\n| 接口 | 方法 | 输入 | 输出 | 消费者 |\n| --- | --- | --- | --- | --- |\n| 创建工单 | `POST /api/tickets` | `{person_id, source, type, description}` | `{ticket_id}` | outreach（TEL→工单/EDM回复→工单）、risk（诈骗→工单） |\n| 工单详情 | `GET /api/tickets/{id}` | ticket_id | 完整工单+上下文卡 | 客服前端 |\n| 查询用户打开工单 | `GET /api/tickets?person_id=&status=open` | person_id | `[{ticket_id, status}]` | outreach（渠道去重）、quota（终校） |\n| 客服可用性 | `GET /api/support/available-agents` | 无 | `[{agent_id, current_load}]` | outreach（分配参考） |\n| 绩效查询 | `GET /api/support/stats?agent_id=&period=` | agent_id + 周期 | 绩效数据 | 客服管理前端 |\n 106|\n---\n 108|\n## 4. 数据对象\n 110|\n| 对象 | 核心字段 | 说明 |\n| --- | --- | --- |\n| `support_tickets` | ticket_id, person_id, source, type, status, assigned_agent, assigned_group, created_at, resolved_at | 工单主表 |\n| `support_followups` | followup_id, ticket_id, person_id, status(PROMISED/ASSIGNED/WAITING/SUBMITTED/TIMEOUT/RECONTACT/CLOSED), promised_at, deadline_at, reminded_at | 答应配合跟进 |\n| `support_assignment_logs` | log_id, ticket_id, from_agent, to_agent, reason, assigned_at | 工单分配日志 |\n| `attendance_records` | record_id, agent_id, date, status(PRESENT/LATE/EARLY/ABSENT/LEAVE), check_in, check_out | 出勤记录 |\n| `shift_schedules` | shift_id, agent_id, date, shift_type, start_time, end_time | 排班表 |\n| `support_performance_snapshots` | snapshot_id, agent_id, period, tickets_handled, messages_sent, avg_first_reply, rso_orders, rdo_orders, reviews_obtained, completion_rate | 绩效快照 |\n 119|\n---\n 121|\n## 5. 业务澄清问题清单 — support\n 123|\n### 5.1 工单管理（5 项）\n 125|\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| S-01 | 工单的来源分类有哪些？（IM 转人工 / 电话后续 / EDM 回复 / 用户主动联系 / 风险触发 / 其他？）每种来源的优先级是否不同？ | **P0** |\n| S-02 | 工单状态「等待用户」和「等待内部」的超时分别是多少？超时后谁来提醒？提醒方式（IM/系统通知）？ | **P0** |\n| S-03 | 三套并行状态（工单状态/答应配合状态/风险状态）的交互规则？例如：风险状态变为「确认诈骗」时工单是否自动关闭？（目前文档说是独立拆开的） | P1 |\n| S-04 | 工单关闭后是否允许重新打开？什么条件可重开？ | P1 |\n| S-05 | 工单是否有 SLA（服务级别协议）？不同来源/类型的工单 SLA 不同？ | P2 |\n 133|\n### 5.2 自动分配（4 项）\n 135|\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| S-06 | 「当前负载」如何精确计算？（未关闭工单数 × 权重？最近 N 小时处理量？工单类型权重不同？） | **P0** |\n| S-07 | 「最大工单数」是什么？（每个客服同时最多持有 X 个工单？）这个值是否统一还是按级别不同？ | **P0** |\n| S-08 | 在线状态如何判定？（手动签入/签出？系统自动检测活跃度？N 分钟无操作自动离线？） | P1 |\n| S-09 | 自动分配如果分配给了离线/满载的客服，兜底机制是什么？（自动转移给组长？放入公共池？） | P1 |\n 142|\n### 5.3 答应配合（3 项）\n 144|\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| S-10 | 答应配合后多少天未提交算超时？超时后的提醒频率？（第 1/3/7 天各提醒一次？）多次提醒无果后关闭还是降级？ | **P0** |\n| S-11 | 用户答应配合但最终提交了错误的 ASIN 评价——算不算配合完成？如何处理？ | P1 |\n| S-12 | 答应配合状态是否只针对客服工单场景？IM 直推中用户答应的算不算？ | P1 |\n 150|\n### 5.4 排班出勤（3 项）\n 152|\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| S-13 | 排班管理是否对接外部 HR 系统？还是独立在 support 子系统内管理？ | P1 |\n| S-14 | 菲律宾客服团队的工作制度？（班次类型：早班/中班/晚班？每班时长？每周几天？） | P1 |\n| S-15 | 出勤异常（迟到/早退/缺勤）是否需要自动通知主管？通知方式？ | P2 |\n 158|\n### 5.5 绩效统计（3 项）\n 160|\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| S-16 | 转化统计中 RSO（回评）和 RDO（测评）如何区分？（按工单来源？按关联计划类型？按客服标记？） | P1 |\n| S-17 | 「首次回复时长」从什么时候开始计时？（工单分配给客服的时间？用户消息到达时间？） | P1 |\n| S-18 | 评价完成率的分母是什么？（答应配合数？登记订单数？触达数？） | P2 |\n 166|\n### 5.6 多语言与国际化（3 项）\n\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| S-19 | 客服工作台需要支持哪些语言？（菲律宾客服用英语+Tagalog？面向用户的消息是否需要自动翻译？） | P1 |\n| S-20 | 用户消息的多语言处理——用户用德语/法语/西语发消息时，客服如何理解？（是否需要集成翻译工具？） | P2 |\n| S-21 | 系统管理界面（排班/绩效/设置）是否需要多语言？面向中国管理团队的是中文界面？ | P2 |\n\n### 5.7 知识库与话术（3 项）\n\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| S-22 | 是否需要集成知识库/FAQ？（客服在处理售后时快速查找产品信息、常见问题解答？） | P2 |\n| S-23 | 是否需要「快捷回复」功能？（预设常用回复模板——「请提供你的订单号」「我们将在 24h 内处理你的退款」等） | P1 |\n| S-24 | 快捷回复模板是否支持按场景/产品分类？（不同产品的售后话术不同——模板管理和权限？） | P2 |\n\n### 5.8 客服质量管控（4 项）\n\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| S-25 | 是否需要客户满意度（CSAT）调查？（工单关闭后推送满意度评分——评分方式？计入绩效？） | P2 |\n| S-26 | 是否需要质检功能？（组长抽查客服的对话记录进行评分——质检抽样比例？质检标准？） | P2 |\n| S-27 | 客服技能分组——不同客服擅长不同类型工单（售后/催评/风控）——是否需要基于技能的自动分配？ | P1 |\n| S-28 | 升级工单的处理流程——什么条件下工单升级到组长/负责人？（超时？用户投诉？疑似诈骗？） | P1 |\n\n### 5.9 排班与出勤补充（3 项）\n\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| S-29 | 排班是否支持轮班制？（周一到周日每天不同的班次安排）排班变更的通知方式？ | P1 |\n| S-30 | 临时调班/换班请求——客服之间是否可以自助换班？是否需要审批？ | P2 |\n| S-31 | 节假日/特殊日期的排班策略？（当地节假日——菲律宾假日 vs 美国假日 vs 中国假日——按哪国日历？） | P1 |\n\n### 5.10 绩效统计补充（3 项）\n\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| S-32 | 绩效考核周期？（日/周/月/季度？）绩效数据是否需要导出为报表？ | P1 |\n| S-33 | 绩效目标是否可自定义？（不同组的目标不同？新人目标低于老员工？）目标由谁设置？ | P1 |\n| S-34 | 绩效看板是否需要实时数据还是 T+1 汇总？（主管需要实时看到当前客服处理了多少工单？） | P2 |\n\n### 5.11 实施层面（3 项）\n\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| S-35 | 客服使用的 IM 工具——是独立于 outreach 的客服专用 IM 还是嵌入在客服工作台内的 Web IM？ | P1 |\n| S-36 | 工单数据是否需要与 outreach 的交互记录打通？（同一个用户在 IM 的聊天记录是否需要关联到工单？） | P1 |\n| S-37 | 客服工作台的实时性要求——新工单到达后多少秒内需要在客服界面显示？（WebSocket 推送 vs 轮询？） | P2 |", + "wikilinks": [], + "category": "layer-requirements" + } + }, + { + "id": "doc:05_需求文档/06-子系统-风险与反欺诈", + "type": "document", + "name": "子系统 06 — 风险与反欺诈 (`risk`) v1.0", + "filePath": "05_需求文档/06-子系统-风险与反欺诈.md", + "summary": "子系统 06 — 风险与反欺诈 risk v1.0 2 子系统概述 4 维度 说明 代号 risk 核心职责 强弱关联判断、黑名单实体管理、风险事件管理、双重退款检测 数据所有权 risk signals , risk cases , blacklist entities , refund match results 启动依赖 identity（软依赖） 外", + "tags": [ + "05_需求文档", + "需求文档" + ], + "complexity": "moderate", + "knowledgeMeta": { + "content": "# 子系统 06 — 风险与反欺诈 (`risk`) v1.0\n 2|\n## 子系统概述\n 4|\n| 维度 | 说明 |\n| --- | --- |\n| 代号 | `risk` |\n| 核心职责 | 强弱关联判断、黑名单实体管理、风险事件管理、双重退款检测 |\n| 数据所有权 | `risk_signals`, `risk_cases`, `blacklist_entities`, `refund_match_results` |\n| 启动依赖 | identity（软依赖） |\n| 外部系统依赖 | Amazon（退款数据）、财务系统（OA 返款数据） |\n 12|\n---\n 14|\n## 1. 模块划分\n 16|\n```\n┌─────────────────────────────────────────────────────────────┐\n│ risk 子系统 │\n│ │\n│ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │\n│ │ M1: 关联判断 │ │ M2: 黑名单 │ │ M3: 双重退款 │ │\n│ │ 引擎 │→│ 管理 │ │ 检测 │ │\n│ └──────┬───────┘ └──────┬───────┘ └──────┬───────┘ │\n│ │ │ │ │\n│ ▼ ▼ ▼ │\n│ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │\n│ │ M4: 风险事件 │ │ M5: 风险审核 │ │ M6: 对外 API │ │\n│ │ 管理 │ │ Admin │ │ Gateway │ │\n│ └──────────────┘ └──────────────┘ └──────────────┘ │\n│ │\n└─────────────────────────────────────────────────────────────┘\n```\n 34|\n| # | 模块 | 职责 |\n| --- | --- | --- |\n| M1 | 关联判断引擎 | 对每次风险信号做强弱关联判断（强：邮箱/设备/电话/地址/订单号/ProfileID/收款信息 命中→高风险；弱：IP单独/姓名单独/同址异名→观察+复核） |\n| M2 | 黑名单管理 | 黑名单实体管理（添加/移除/过期）、黑名单同步、命中查询 |\n| M3 | 双重退款检测 | Amazon 退款记录 vs OA 返款记录的自动比对，检测重复退款 |\n| M4 | 风险事件管理 | 风险事件创建、状态流转、关联工单/推送/计划状态回写 |\n| M5 | 风险审核 Admin | 人工复核弱关联风险、确认/排除诈骗、黑名单操作 |\n| M6 | 对外 API Gateway | 供所有子系统查询风险状态、上报风险信号 |\n 43|\n---\n 45|\n## 2. 各模块内外说明\n 47|\n### 2.1 M1: 关联判断引擎\n 49|\n| 维度 | 说明 |\n| --- | --- |\n| **对内** | 每次风险信号进入时执行：8 项强关联维度（邮箱/设备号/电话/收件人姓名+地址/订单号/聊天记录/Profile ID/收款信息）→任一命中→高风险；3 项弱关联维度（IP单独/姓名单独/同址异名）→高风险观察+人工复核；判断结果：强关联/弱关联/无关联 |\n| **对外接口** | `GET /api/risk/check/{person_id}` — 风险查询（含关联判断结果） |\n| **数据写入** | `risk_signals` |\n| **依赖** | `GET /api/identity/context/{person_id}` — 获取身份线索用于关联判断 |\n| **关键规则** | 风险判断不是一次性，每次有效互动都要重做；非 APP 用户缺设备/注册邮箱等维度→风险识别能力下降 |\n 57|\n### 2.2 M2: 黑名单管理\n 59|\n| 维度 | 说明 |\n| --- | --- |\n| **对内** | 黑名单实体 CRUD（邮箱/设备/电话/地址/收款信息）；黑名单命中查询（任何子系统查询用户是否在黑名单）；黑名单同步（确认诈骗后同步到黑名单）；黑名单过期/申诉机制 |\n| **对外接口** | `GET /api/risk/blacklist/check?type=EMAIL&value=xxx` — 黑名单命中检查 |\n| **数据写入** | `blacklist_entities` |\n| **待确认** | 黑名单是否有过期时间？申诉/移除流程？ |\n 66|\n### 2.3 M3: 双重退款检测\n 68|\n| 维度 | 说明 |\n| --- | --- |\n| **对内** | 采集 Amazon 退款记录（外部系统同步）+ OA 返款记录（财务系统同步）；按订单号/用户/金额/时间自动比对；匹配结果：无重复/疑似重复/确认重复；确认重复时强告警+阻止后续返款 |\n| **对外接口** | `GET /api/risk/double-refund-check/{person_id}` — 双重退款检测 |\n| **数据写入** | `refund_match_results` |\n| **依赖** | Amazon 退款数据（外部）、OA 返款数据（外部财务系统） |\n| **待确认** | Amazon 退款数据如何及时获取？OA 返款记录是否已有 API？ |\n 76|\n### 2.4 M4: 风险事件管理\n 78|\n| 维度 | 说明 |\n| --- | --- |\n| **对内** | 风险事件创建（客服上报疑似诈骗 / 双重退款检测 / 关联判断命中）；事件状态流转（待复核→复核中→确认风险/排除风险）；高风险链路动作（拦截继续推送/拦截自动退款/拦截自动放行）；回写关联工单/推送/计划状态 |\n| **对外接口** | `POST /api/risk/report` — 上报风险信号（客服、系统自动均可调用） |\n| **数据写入** | `risk_cases` |\n 84|\n### 2.5 M5: 风险审核 Admin\n 86|\n| 维度 | 说明 |\n| --- | --- |\n| **对内** | 人工复核弱关联风险；确认/排除诈骗判定；黑名单手动操作；风险口径维护 |\n| **对外接口** | 管理 API |\n| **待确认** | 复核时效要求？（N 分钟内必须复核？） |\n 92|\n---\n 94|\n## 3. 对外 API 契约（草案）\n 96|\n| 接口 | 方法 | 输入 | 输出 | 消费者 |\n| --- | --- | --- | --- | --- |\n| 风险查询 | `GET /api/risk/check/{person_id}` | person_id | `{risk_level(NONE/WEAK/STRONG), signals[], cases[]}` | 所有子系统（每次互动时调用） |\n| 上报风险信号 | `POST /api/risk/report` | `{person_id, signal_type, evidence, reported_by}` | `{signal_id}` | support（客服上报诈骗）、outreach（异常互动） |\n| 黑名单命中 | `GET /api/risk/blacklist/check?type=&value=` | 维度类型+值 | `{hit, entity}` | outreach（发送前）、identity（身份归并时） |\n| 双重退款检测 | `GET /api/risk/double-refund-check/{person_id}` | person_id | `{status, matched_refunds[]}` | outreach（返款前）、support（退款处理前） |\n 103|\n---\n 105|\n## 4. 数据对象\n 107|\n| 对象 | 核心字段 | 说明 |\n| --- | --- | --- |\n| `risk_signals` | signal_id, person_id, signal_type, hit_dimensions[], risk_level(STRONG/WEAK), detected_at | 风险信号（每次互动生成的判断） |\n| `risk_cases` | case_id, person_id, source, status(PENDING_REVIEW/REVIEWING/CONFIRMED_RISK/RULED_OUT), reviewer, created_at, resolved_at | 风险事件 |\n| `blacklist_entities` | entity_id, entity_type(EMAIL/DEVICE/PHONE/ADDRESS/PAYMENT), entity_value, status(ACTIVE/EXPIRED/APPEALED), added_at, added_by | 黑名单实体 |\n| `refund_match_results` | match_id, person_id, amazon_refund_id, oa_refund_id, match_status(NO_DUPLICATE/SUSPECTED/CONFIRMED), matched_at | 双重退款比对结果 |\n 114|\n---\n 116|\n## 5. 业务澄清问题清单 — risk\n 118|\n### 5.1 强弱关联规则（4 项）\n 120|\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| R-01 | 8 项强关联维度中，每个维度的命中是独立判断还是组合判断？（例如仅「设备号命中」是否就足够判定强关联？还是需要「设备号 + 电话」同时命中？） | **P0** |\n| R-02 | 「强关联→直接进入高风险或黑名单链路」——这里的「直接」是指全自动化拦截无需人工确认？还是系统先拦截再人工审核？（涉及自动化力度） | **P0** |\n| R-03 | 弱关联的「观察期」多长？观察期过后是自动解除还是必须人工确认？观察期内用户继续参与互动如何处理？ | P1 |\n| R-04 | 风险判断中「IP 单独命中」列为弱关联——IP 从哪里获取？（JOYHUB APP？EDM 邮件头？客服系统？）不同来源的 IP 可靠性不同 | P1 |\n 127|\n### 5.2 双重退款（4 项）\n 129|\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| R-05 | Amazon 退款数据如何获取？（SP-API 实时拉取？T+1 同步？手动导入 CSV？）同步频率决定检测时效 | **P0** |\n| R-06 | OA 返款系统是哪个？是否有 API？如果没有 API，返款记录怎么录入？（财务手动录入？CSV 导入？） | **P0** |\n| R-07 | 「双重退款」比对的关键字段是什么？（订单号？金额？用户？时间窗口？）匹配精度？（金额完全相等还是 ±X%？时间窗口多宽？） | P1 |\n| R-08 | 确认重复退款后，阻止后续返款——「阻止」是指系统自动拦截返款指令，还是只发告警让人工决定？ | P1 |\n 136|\n### 5.3 黑名单管理（3 项）\n 138|\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| R-09 | 黑名单是否有过期/申诉/解除机制？（例如用户被误标后如何申诉？谁有权解除？） | P1 |\n| R-10 | 黑名单是否需要与外部系统同步？（例如 JOYHUB 的黑名单？Amazon 的欺诈标记？）同步方向？ | P1 |\n| R-11 | 黑名单的粒度——是标记「真实人」还是「某个维度的值」？（标记的是真实人 ID 还是具体的邮箱/设备？） | P1 |\n 144|\n### 5.4 风险可见性（3 项）\n 146|\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| R-12 | 文档要求「客服、审核、退款等环节必须都能看到风险提醒」——风险提醒的展现形式是什么？（红色标签？弹窗？工单页顶部横幅？） | P1 |\n| R-13 | 风险状态的「提醒」通过什么通道发送？（audit 通知中心？IM 消息？系统内消息？） | P1 |\n| R-14 | 风险人员角色是否需要独立的风险控制台前端？该前端需要哪些功能？（事件列表/审核工作台/黑名单管理/统计报表？） | P2 |\n 152|\n### 5.5 高级风险检测能力（4 项）\n\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| R-15 | 是否需要行为速度检测？（同一真实人短时间内大量注册/大量申请退款/大量提交评价→触发异常行为告警？） | P1 |\n| R-16 | 是否需要设备指纹/浏览器指纹？（识别同一设备换账号、模拟器、虚拟机等欺诈行为？） | P2 |\n| R-17 | 是否需要地理位置异常检测？（同一账号短期内从不同国家/城市登录→触发告警？） | P2 |\n| R-18 | 风险评分模型——是否需要一个综合风险分数（0-100）而非二元判断（强/弱/无）？评分模型的因子和权重？ | P1 |\n\n### 5.6 风险事件处理流程（3 项）\n\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| R-19 | 风险事件的优先级（P0/P1/P2）如何定义？（双重退款确认→P0？单次弱关联→P2？）不同优先级的响应 SLA？ | P1 |\n| R-20 | 风险人员的工作台——是否需要「待审核队列」「审核中」「已处理」等看板视图？是否需要分配给具体审核人？ | P1 |\n| R-21 | 同一个人短时间内触发多次风险信号——是每次生成新事件还是合并到已有事件？合并规则？ | P1 |\n\n### 5.7 黑名单管理补充（3 项）\n\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| R-22 | 黑名单的生效范围——加入黑名单后是「全系统拦截」还是「只拦截某些操作」？（是否还允许正常购买？只拦截测评参与？） | P1 |\n| R-23 | 黑名单是否需要分级？（一级黑名单→全拦截 / 二级黑名单→降频+人工审核 / 三级黑名单→仅标记提醒） | P1 |\n| R-24 | 黑名单是否需要与外部欺诈数据库同步？（如行业共享的欺诈黑名单？Amazon 的 abuse 标记？） | P2 |\n\n### 5.8 非 APP 用户风险盲区（2 项）\n\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| R-25 | 文档已明确「非 APP 用户识别能力下降」——是否需要额外的风控措施？（例如非 APP 用户的返款额度降低？首次返款必须人工审核？） | P1 |\n| R-26 | 是否计划引导非 APP 用户注册 APP 以补全风险画像？（EDM/客服主动引导注册——注册转化跟踪？） | P2 |\n\n### 5.9 实施层面（3 项）\n\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| R-27 | 风险判断的实时性要求——每次互动时实时调用 risk API？（性能 overhead？需要缓存策略？） | P1 |\n| R-28 | 双重退款检测的时效——Amazon 退款数据（外部）同步延迟 vs OA 返款实时——T+N 的延迟是否可接受？ | P1 |\n| R-29 | 风险事件的数据保留策略？（已解决的诈骗案件数据保留多久？用于后续模型训练还是定期清理？） | P2 |", + "wikilinks": [], + "category": "layer-requirements" + } + }, + { + "id": "doc:05_需求文档/07-子系统-评价结果追踪", + "type": "document", + "name": "子系统 07 — 评价结果追踪 (`review`) v1.0", + "filePath": "05_需求文档/07-子系统-评价结果追踪.md", + "summary": "子系统 07 — 评价结果追踪 review v1.0 2 子系统概述 4 维度 说明 代号 review 核心职责 用户真实提交评价记录、Amazon 展示核验、ASIN 健康/计划完成度更新回流 数据所有权 review submission records , review display checks , review results 启动依赖 id", + "tags": [ + "05_需求文档", + "需求文档" + ], + "complexity": "moderate", + "knowledgeMeta": { + "content": "# 子系统 07 — 评价结果追踪 (`review`) v1.0\n 2|\n## 子系统概述\n 4|\n| 维度 | 说明 |\n| --- | --- |\n| 代号 | `review` |\n| 核心职责 | 用户真实提交评价记录、Amazon 展示核验、ASIN 健康/计划完成度更新回流 |\n| 数据所有权 | `review_submission_records`, `review_display_checks`, `review_results` |\n| 启动依赖 | identity / planning（软依赖） |\n| 外部系统依赖 | Amazon（评价展示状态、ASIN 评分数据） |\n 12|\n---\n 14|\n## 1. 模块划分\n 16|\n```\n┌─────────────────────────────────────────────────────────────┐\n│ review 子系统 │\n│ │\n│ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │\n│ │ M1: 评价提交 │ │ M2: 展示核验 │ │ M3: 结果回流 │ │\n│ │ 记录 │→│ │→│ 引擎 │ │\n│ └──────┬───────┘ └──────┬───────┘ └──────┬───────┘ │\n│ │ │ │ │\n│ ▼ ▼ ▼ │\n│ ┌──────────────┐ ┌──────────────┐ │\n│ │ M4: 异常观察 │ │ M5: 对外 API │ │\n│ │ 队列 │ │ Gateway │ │\n│ └──────────────┘ └──────────────┘ │\n│ │\n└─────────────────────────────────────────────────────────────┘\n```\n 34|\n| # | 模块 | 职责 |\n| --- | --- | --- |\n| M1 | 评价提交记录 | 记录用户真实提交评价的事实（提交时点、提交证据、关联计划、关联 ASIN） |\n| M2 | 展示核验 | 核查 Amazon 是否展示该评价 / 是否可核验 |\n| M3 | 结果回流引擎 | 将评价结果反馈给 planning（计划完成度）、identity（用户标签）、audit |\n| M4 | 异常观察队列 | 用户已提交但 Amazon 未展示 / 暂不可核验的评价，进入定期复查队列 |\n| M5 | 对外 API Gateway | 供 outreach、planning 查询评价进度、提交评价 |\n 42|\n---\n 44|\n## 2. 各模块内外说明\n 46|\n### 2.1 M1: 评价提交记录\n 48|\n| 维度 | 说明 |\n| --- | --- |\n| **对内** | 记录两个核心事实：①用户真实提交评价（时间、ASIN、评论内容/截图/链接、关联计划）；②提交后立即更新真实人累计评价额度（调用 quota 子系统 `commit`） |\n| **对外接口** | `POST /api/reviews/submission` — 记录评价提交 |\n| **数据写入** | `review_submission_records` |\n| **依赖** | `POST /api/quota/commit` — 确认额度占用（提交后立即计数12） |\n| **关键规则** | 「用户真实提交评价」和「Amazon 展示确认」是两个独立事实；额度计数按前者，计划完成按后者 |\n 56|\n### 2.2 M2: 展示核验\n 58|\n| 维度 | 说明 |\n| --- | --- |\n| **对内** | 核查 Amazon 是否展示该评价 / 是否可核验；核验方式（待确认：爬取 / 手动 / API / 截图？）；核验结果：①展示或可核验→计入计划完成 ②未展示/暂不可核验→保留已提交事实→进入异常观察 |\n| **对外接口** | `POST /api/reviews/verify` — 触发核验（或定时核验） |\n| **数据写入** | `review_display_checks` |\n| **依赖** | Amazon（评价展示数据） |\n| **待确认** | 核验是自动还是人工？核验频率？ |\n 66|\n### 2.3 M3: 结果回流引擎\n 68|\n| 维度 | 说明 |\n| --- | --- |\n| **对内** | 评价确认展示后：①通知 planning 更新计划完成度 ②通知 identity 更新用户标签（例如标记为「已回评用户」）③写入审计日志；免评结果回流：①更新 ASIN 健康与权重变化 ②更新计划完成度 ③通知 planning |\n| **对外接口** | 内部事件发布 |\n| **数据写入** | `review_results` |\n| **依赖** | `PUT /api/plans/{id}/status`（更新计划状态） |\n 75|\n### 2.4 M4: 异常观察队列\n 77|\n| 维度 | 说明 |\n| --- | --- |\n| **对内** | 用户已提交但 Amazon 未展示/暂不可核验的评价，进入异常观察队列；定期复查（例如每天查一次 Amazon 是否已展示）；超过观察期仍未展示→标记异常→通知运营 |\n| **数据写入** | `review_display_checks`（更新状态） |\n| **待确认** | 观察周期多长？复查频率？观察期满后如何处理？ |\n 83|\n---\n 85|\n## 3. 对外 API 契约（草案）\n 87|\n| 接口 | 方法 | 输入 | 输出 | 消费者 |\n| --- | --- | --- | --- | --- |\n| 记录评价提交 | `POST /api/reviews/submission` | `{person_id, asin, plan_id, evidence, submitted_at}` | `{submission_id, quota_updated}` | outreach（IM 核验后/客服确认后） |\n| 查询计划评价进度 | `GET /api/reviews/status/{plan_id}` | plan_id | `{total_submissions, verified, pending, completion_rate}` | planning |\n| 查询用户评价历史 | `GET /api/reviews/history/{person_id}` | person_id | `[{submission_id, asin, status, submitted_at}]` | identity（上下文卡） |\n| ASIN 评价统计 | `GET /api/reviews/asin-stats/{asin}` | asin | `{submission_count, verified_count, pending_count}` | planning |\n 94|\n---\n 96|\n## 4. 数据对象\n 98|\n| 对象 | 核心字段 | 说明 |\n| --- | --- | --- |\n| `review_submission_records` | submission_id, person_id, asin, plan_id, evidence_type, evidence, submitted_at, quota_updated | 评价提交记录（核心事实一） |\n| `review_display_checks` | check_id, submission_id, asin, check_method, check_result(DISPLAYED/NOT_DISPLAYED/UNVERIFIABLE), checked_at, retry_count, status(OBSERVING/CONFIRMED/ABNORMAL) | 展示核验记录（核心事实二） |\n| `review_results` | result_id, plan_id, asin, submission_count, verified_count, completion_rate, asin_health_change, updated_at | 评价结果汇总 |\n 104|\n---\n 106|\n## 5. 业务澄清问题清单 — review\n 108|\n### 5.1 评价提交记录（3 项）\n 110|\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| V-01 | 「用户真实提交评价」的证据形式是什么？（用户上传的截图？Amazon 评论链接？系统自动检测？）不同形式如何验证真伪？ | **P0** |\n| V-02 | 一个用户为同一个 ASIN 提交多条评价（如果 Amazon 允许）——每一条都独立计入累计12额度吗？ | **P0** |\n| V-03 | 评价提交记录是 outreach（IM/客服）写入还是用户直接提交？（系统内提交 vs 系统外提交的区别）系统外提交如何登记？ | P1 |\n 116|\n### 5.2 展示核验（4 项）\n 118|\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| V-04 | Amazon 评价展示的核验方式是？（定时爬取 Amazon 产品页？SP-API 拉取评价列表？用户上传截图人工审核？混合方式？） | **P0** |\n| V-05 | 如果通过爬取核验——爬取频率？（小时级？天级？）如何识别「哪条评价是本次计划用户提交的」？（靠评论者名字匹配？靠时间窗口？） | **P0** |\n| V-06 | 「暂不可核验」的常见原因有哪些？（Amazon 审核中/延迟展示/被 Amazon 删除？）每种原因的处理策略是否不同？ | P1 |\n| V-07 | 核验失败的兜底机制——如果 Amazon API 不可用或爬取失败，是否允许人工确认？ | P1 |\n 125|\n### 5.3 异常观察队列（2 项）\n 127|\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| V-08 | 异常观察队列的观察期多长？（1 天？7 天？30 天？）复查频率？（每天？每周？）观察期满后未展示→如何处理？ | P1 |\n| V-09 | 多少条评价进入异常观察算异常阈值？（单计划 10% 未展示→通知？单用户多次未展示→标记？） | P2 |\n 132|\n### 5.4 结果回流（3 项）\n 134|\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| V-10 | ASIN 健康「回流」的具体动作是什么？（更新 ASIN 评分/评价数到 planning？触发新一轮需求评估？更新 outreach 的触达策略？） | P1 |\n| V-11 | 计划完成度的计算方式——「评价确认展示」即算完成？还是需要确认展示 + 关联到本计划用户？（如何确保那条展示的评价确实是本计划用户的？） | P1 |\n| V-12 | 免评结果的「权重变化」如何量化？（Amazon 不直接提供权重数据——如何通过间接指标判断？） | P2 |\n 140|\n### 5.5 评价质量管理（4 项）\n\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| V-13 | 是否需要评价内容分析？（好评/中评/差评？评价字数？是否含图片/视频？——这些影响评价质量评分？） | P2 |\n| V-14 | 差评检测和响应——用户提交了差评（1-2 星）是否需要自动触发售后工单？（「差评补救」流程？） | P1 |\n| V-15 | 虚假评价检测——用户提交的评价是否可能被 Amazon 判定为虚假评价并删除？（系统是否需要内部质量评分来预测被删风险？） | P2 |\n| V-16 | 评价的 ASIN 匹配校验——用户声称对 ASIN A 提交了评价但实际是对 ASIN B 提交的——如何检测和处理？ | P1 |\n\n### 5.6 异常观察队列补充（3 项）\n\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| V-17 | 评价提交后 Amazon 展示的预期时间窗口？（通常 24-48h？最长多久？）超出预期窗口后的自动通知？ | P1 |\n| V-18 | Amazon 删除评价（违反社区准则）vs 用户删除评价 vs 评价被折叠——是否能区分？分别如何处理？ | P2 |\n| V-19 | 大量评价同时进入异常观察（例如 Amazon 评价系统故障导致全站延迟）——系统如何处理？（自动暂停观察队列？人工干预？） | P2 |\n\n### 5.7 ASIN 健康回流补充（3 项）\n\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| V-20 | ASIN 健康更新的频率？（每次评价确认展示就更新？每天汇总更新一次？） | P2 |\n| V-21 | 如果多人同时对同一 ASIN 提交了评价，是否对 ASIN 健康有复合影响？（例如 5 条 5 星好评 vs 1 条 1 星差评——权重不同） | P2 |\n| V-22 | ASIN 健康数据的来源——是 Amazon 直接提供的数据还是系统内部计算？（Amazon 评分 vs 系统追踪到的评价评分可能有差异） | P1 |\n\n### 5.8 实施层面（2 项）\n\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| V-23 | 评价展示核验如果是爬取 Amazon 页面——爬取频率和多 ASIN 并行爬取能力？（需要爬取几百个 ASIN 时的时间和资源开销） | P1 |\n| V-24 | 评价数据是否需要在系统间同步？（outreach 需要知道「用户已提交」→暂停触达；planning 需要知道「评价已确认」→更新计划完成度）数据一致性的保证？ | P1 |", + "wikilinks": [], + "category": "layer-requirements" + } + }, + { + "id": "doc:05_需求文档/08-子系统-KOC-KOL协作", + "type": "document", + "name": "子系统 08 — KOC/KOL 协作 (`creator`) v1.0", + "filePath": "05_需求文档/08-子系统-KOC-KOL协作.md", + "summary": "子系统 08 — KOC/KOL 协作 creator v1.0 2 子系统概述 4 维度 说明 代号 creator 核心职责 KOC/KOL 匹配筛选、内容 Brief/Code 分配、内容发布跟踪、带货结果跟踪、JOYCOLLAB 数据同步 数据所有权 exemption plan tasks , creator content records , c", + "tags": [ + "05_需求文档", + "需求文档" + ], + "complexity": "moderate", + "knowledgeMeta": { + "content": "# 子系统 08 — KOC/KOL 协作 (`creator`) v1.0\n 2|\n## 子系统概述\n 4|\n| 维度 | 说明 |\n| --- | --- |\n| 代号 | `creator` |\n| 核心职责 | KOC/KOL 匹配筛选、内容 Brief/Code 分配、内容发布跟踪、带货结果跟踪、JOYCOLLAB 数据同步 |\n| 数据所有权 | `exemption_plan_tasks`, `creator_content_records`, `creator_profiles`, `code_records` |\n| 启动依赖 | planning（软依赖，免评计划入口） |\n| 外部系统依赖 | JOYCOLLAB（KOC/KOL 数据、内容数据、Code 使用、带货订单） |\n 12|\n---\n 14|\n## 1. 模块划分\n 16|\n```\n┌─────────────────────────────────────────────────────────────┐\n│ creator 子系统 │\n│ │\n│ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │\n│ │ M1: KOC/KOL │ │ M2: 内容/Code│ │ M3: 结果跟踪 │ │\n│ │ 匹配筛选 │→│ 管理 │→│ │ │\n│ └──────┬───────┘ └──────┬───────┘ └──────┬───────┘ │\n│ │ │ │ │\n│ ▼ ▼ ▼ │\n│ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │\n│ │ M4: JOYCOLLAB│ │ M5: IM/EDM/ │ │ M6: 对外 API │ │\n│ │ 数据同步 │ │ APP 协同 │ │ Gateway │ │\n│ └──────────────┘ └──────────────┘ └──────────────┘ │\n│ │\n└─────────────────────────────────────────────────────────────┘\n```\n 34|\n| # | 模块 | 职责 |\n| --- | --- | --- |\n| M1 | KOC/KOL 匹配筛选 | 按国家/平台/粉丝量/产品类目/历史效果筛选匹配合作对象；检查合作对象风险（历史纠纷/违约） |\n| M2 | 内容/Code 管理 | 分配内容 Brief、分配 Code、管理 Code 使用量、素材管理 |\n| M3 | 结果跟踪 | 跟踪内容发布状态、点击/跳转数据、Code 使用量、带货订单、转化销量、权重变化 |\n| M4 | JOYCOLLAB 数据同步 | 从 JOYCOLLAB 拉取 KOC/KOL 数据、内容数据、Code 使用、带货订单；同步失败告警 |\n| M5 | IM/EDM/APP 协同 | KOC 内容二次分发、免评 Code 触达站内用户、活动引流、结果通知 |\n| M6 | 对外 API Gateway | 供 planning、outreach、review 查询 |\n 43|\n---\n 45|\n## 2. 各模块内外说明\n 47|\n### 2.1 M1: KOC/KOL 匹配筛选\n 49|\n| 维度 | 说明 |\n| --- | --- |\n| **对内** | 免评计划进入后：①按国家/平台/粉丝量/历史效果筛选 KOC/KOL ②按产品类目匹配专长 ③检查合作对象风险（历史纠纷/违约）→有风险记录时提示 |\n| **对外接口** | `GET /api/creators/match?plan_id=` — 获取匹配推荐列表 |\n| **数据写入** | `creator_profiles`（从 JOYCOLLAB 同步的 KOC/KOL 画像缓存） |\n| **待确认** | 匹配是完全自动推荐还是运营人工选择？推荐算法依赖哪些权重？ |\n 56|\n### 2.2 M2: 内容/Code 管理\n 58|\n| 维度 | 说明 |\n| --- | --- |\n| **对内** | 分配内容 Brief（产品信息/要求/素材/发布时间）；Code 分配（每个 KOC 独立 Code 还是一对多？）；Code 使用量监控 |\n| **对外接口** | `POST /api/creators/tasks` — 创建协作任务（含 Brief + Code） |\n| **数据写入** | `exemption_plan_tasks`, `code_records` |\n| **待确认** | Code 是 JOYCOLLAB 生成还是 USER 系统生成？Code 是优惠码还是追踪码？ |\n 65|\n### 2.3 M3: 结果跟踪\n 67|\n| 维度 | 说明 |\n| --- | --- |\n| **对内** | 跟踪 6 组结果：①内容发布状态/链接/互动数据 ②点击/跳转量 ③Code 使用量 ④带货订单数 ⑤转化销量 ⑥Listing 权重变化；执行评估：达标→结果回流 / 未达标→调整策略（更换KOC/调整素材/追加Code） |\n| **对外接口** | `GET /api/creators/results/{plan_id}` — 免评计划执行结果 |\n| **数据写入** | `creator_content_records` |\n| **依赖** | JOYCOLLAB 数据同步 |\n 74|\n### 2.4 M4: JOYCOLLAB 数据同步\n 76|\n| 维度 | 说明 |\n| --- | --- |\n| **对内** | 从 JOYCOLLAB 同步：KOC/KOL 画像数据、内容发布数据、Code 使用数据、带货订单数据；同步记录（时间/成功/失败）；同步失败告警 |\n| **对外接口** | 内部定时任务 |\n| **数据写入** | 本地缓存表（`creator_profiles`, `creator_content_records`） |\n| **待确认** | 同步方向是单向（COLLAB→USER）还是双向？同步频率？ |\n 83|\n### 2.5 M5: IM/EDM/APP 协同\n 85|\n| 维度 | 说明 |\n| --- | --- |\n| **对内** | 4 种协同动作：①KOC 内容二次分发（IM/APP 推送优质内容）②免评 Code 触达（IM/EDM 分发 Code 给站内用户）③活动引流（APP Push 引导用户进入 KOC 内容页）④结果通知（IM/APP 通知用户 Code 到账/订单确认） |\n| **对外接口** | 调用 outreach API：`POST /api/outreach/im/send` 等 |\n| **数据写入** | 协同记录 |\n 91|\n---\n 93|\n## 3. 对外 API 契约（草案）\n 95|\n| 接口 | 方法 | 输入 | 输出 | 消费者 |\n| --- | --- | --- | --- | --- |\n| KOC/KOL 匹配推荐 | `GET /api/creators/match?plan_id=` | plan_id | `[{creator_id, score, match_reason}]` | planner 前端 |\n| 创建协作任务 | `POST /api/creators/tasks` | `{creator_id, plan_id, brief, code, deadline}` | `{task_id}` | planner 前端 |\n| 免评执行结果 | `GET /api/creators/results/{plan_id}` | plan_id | `{content, clicks, codes, orders, sales, weight_change}` | review（结果回流）, planning |\n| KOC/KOL 画像查询 | `GET /api/creators/{creator_id}` | creator_id | KOC/KOL 完整画像 | planner 前端 |\n 102|\n---\n 104|\n## 4. 数据对象\n 106|\n| 对象 | 核心字段 | 说明 |\n| --- | --- | --- |\n| `exemption_plan_tasks` | task_id, plan_id, creator_id, brief, code, status, assigned_at, deadline | 免评计划协作任务 |\n| `creator_content_records` | record_id, task_id, creator_id, content_url, publish_time, engagement_data, synced_at | KOC 内容发布记录 |\n| `creator_profiles` | creator_id, name, platform, country, follower_count, category, historical_performance, risk_notes, synced_at | KOC/KOL 画像（从 JOYCOLLAB 同步的本地缓存） |\n| `code_records` | code_id, task_id, code_value, code_type, usage_count, usage_limit, status | Code 记录 |\n 113|\n---\n 115|\n## 5. 业务澄清问题清单 — creator\n 117|\n### 5.1 JOYCOLLAB 对接（4 项）\n 119|\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| K-01 | JOYCOLLAB 中 KOC/KOL 的完整数据字段有哪些？（平台/粉丝量/国家/类目/历史合作效果/历史纠纷/违约——文档部分列出，需确认完整字段清单和 API 可用性） | **P0** |\n| K-02 | 数据同步方向是单向（COLLAB→USER）还是双向？（USER 分配的 Brief/Code 是否需要回写到 COLLAB？） | **P0** |\n| K-03 | 同步频率？（实时 Webhook？每小时？每天？）同步失败时谁来处理？重试策略？ | P1 |\n| K-04 | JOYCOLLAB 是否有现成 API？是 REST API 还是需要开发新的同步接口？ | P1 |\n 126|\n### 5.2 KOC/KOL 匹配（3 项）\n 128|\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| K-05 | 匹配是运营人工选择还是系统自动推荐？推荐算法的权重？（粉丝量 vs 历史效果 vs 类目匹配 vs 报价？） | P1 |\n| K-06 | KOC/KOL 是否有评级/分层体系？（头部/腰部/尾部？）不同层级对应的计划类型是否不同？ | P1 |\n| K-07 | 「合作对象风险（历史纠纷/违约）」——风险数据从哪里来？（JOYCOLLAB？人工标记？）什么程度的风险需要拦截？ | P1 |\n 134|\n### 5.3 Code 与内容（3 项）\n 136|\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| K-08 | Code 是 JOYCOLLAB 生成还是 USER 系统生成？Code 类型？（优惠码/追踪码/专属链接？）一对一还是可以多人共用？ | P1 |\n| K-09 | KOC 发布的内容是否需要审核？（Brief 交付后→KOC 创作→审核→发布？）审核流程在哪个系统？ | P2 |\n| K-10 | KOC 内容二次分发到 IM/APP——分发策略是什么？（所有优质内容都分发？按产品/地区筛选？） | P2 |\n 142|\n### 5.4 财务结算（2 项）\n 144|\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| K-11 | KOC/KOL 的提成/返点结算在哪个系统执行？（JOYCOLLAB？财务系统？还是 USER 内触发结算指令？）USER 的责任边界？ | P1 |\n| K-12 | 结算数据（提成计算/返点核算/提款记录）是否需要同步到 USER？权限控制（财务数据独立权限）？ | P2 |\n 149|\n### 5.5 KOC/KOL 分层与定价（3 项）\n\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| K-13 | KOC/KOL 是否有分层体系？（头部/腰部/尾部——按粉丝量划分？按历史带货效果划分？）不同分层的合作价格和权益？ | P1 |\n| K-14 | KOC/KOL 的报价/定价数据是否在系统中维护？（用于预算计算和 ROI 分析？） | P2 |\n| K-15 | KOC/KOL 是否有签约/合同管理？排他性协议？（签约期内只能推广本品牌产品？）排他性信息是否需要系统记录？ | P2 |\n\n### 5.6 内容与权益管理（3 项）\n\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| K-16 | KOC/KOL 发布内容的使用权和授权期限？（品牌是否可以二次使用、广告投放、修改？授权条款在系统中管理还是走线下合同？） | P2 |\n| K-17 | 内容审核流程——KOC/KOL 创作的内容是否需要品牌方审核后才能发布？（审核不通过→修改→重新审核的流程？） | P1 |\n| K-18 | 内容效果评估——除了点击/Code/订单数据外，是否需要评估内容质量？（互动率、完播率、正向评论比例？） | P2 |\n\n### 5.7 多平台 KOC/KOL 管理（3 项）\n\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| K-19 | KOC/KOL 涉及哪些平台？（YouTube / TikTok / Instagram / Facebook / 博客 / Amazon 站内 Influencer Program？）每个平台的数据来源？ | P1 |\n| K-20 | 同一 KOC/KOL 在多个平台有账号——是否在系统中关联为同一个人？（类似 identity 的归并逻辑？） | P2 |\n| K-21 | 不同平台的内容格式和指标不同（YouTube 视频 vs Instagram 帖子 vs TikTok 短视频）——结果跟踪如何统一？ | P2 |\n\n### 5.8 Code 管理补充（2 项）\n\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| K-22 | Code 的类型？（一次性折扣码 / 多次使用码 / 追踪链接 / 专属落地页？）不同类型的生成和追踪逻辑？ | P1 |\n| K-23 | Code 的有效期管理？（计划结束后 Code 自动失效？还是保留一段时间？）Code 是否可重复使用？ | P1 |\n\n### 5.9 实施层面（3 项）\n\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| K-24 | JOYCOLLAB 数据同步失败时的降级策略？（用本地缓存数据？标记为「数据可能过期」？暂停新的协作任务？） | P1 |\n| K-25 | KOC/KOL 匹配算法的性能——如果 JOYCOLLAB 有几千个 KOC，匹配需要多少时间？是否有预筛选+精排的两阶段设计？ | P2 |\n| K-26 | KOC/KOL 的任务状态如何与 planning 的计划状态联动？（协作任务完成→计划完成度增加→计划状态更新？） | P1 |", + "wikilinks": [], + "category": "layer-requirements" + } + }, + { + "id": "doc:05_需求文档/09-子系统-审计与通知中心", + "type": "document", + "name": "子系统 09 — 审计与通知中心 (`audit`) v1.0", + "filePath": "05_需求文档/09-子系统-审计与通知中心.md", + "summary": "子系统 09 — 审计与通知中心 audit v1.0 2 子系统概述 4 维度 说明 代号 audit 核心职责 状态变更审计、敏感字段访问日志、多类型通知/告警 数据所有权 interaction audit logs , notification records , manual review tasks 启动依赖 无硬依赖，完全独立 外部系统依赖 通", + "tags": [ + "05_需求文档", + "需求文档" + ], + "complexity": "moderate", + "knowledgeMeta": { + "content": "# 子系统 09 — 审计与通知中心 (`audit`) v1.0\n 2|\n## 子系统概述\n 4|\n| 维度 | 说明 |\n| --- | --- |\n| 代号 | `audit` |\n| 核心职责 | 状态变更审计、敏感字段访问日志、多类型通知/告警 |\n| 数据所有权 | `interaction_audit_logs`, `notification_records`, `manual_review_tasks` |\n| 启动依赖 | 无硬依赖，完全独立 |\n| 外部系统依赖 | 通知可能通过 IM/EDM/APP Push 等通道（可复用 outreach 通道或独立） |\n 12|\n---\n 14|\n## 1. 模块划分\n 16|\n```\n┌─────────────────────────────────────────────────────────────┐\n│ audit 子系统 │\n│ │\n│ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │\n│ │ M1: 状态变更 │ │ M2: 敏感操作 │ │ M3: 通知分发 │ │\n│ │ 审计 │ │ 审计 │ │ 引擎 │ │\n│ └──────┬───────┘ └──────┬───────┘ └──────┬───────┘ │\n│ │ │ │ │\n│ ▼ ▼ ▼ │\n│ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │\n│ │ M4: 通知模板 │ │ M5: 人工复核 │ │ M6: 对外 API │ │\n│ │ 管理 │ │ 任务 │ │ Gateway │ │\n│ └──────────────┘ └──────────────┘ └──────────────┘ │\n│ │\n└─────────────────────────────────────────────────────────────┘\n```\n 34|\n| # | 模块 | 职责 |\n| --- | --- | --- |\n| M1 | 状态变更审计 | 记录所有业务对象的状态流转（对象ID/旧状态/新状态/操作人/时间/原因） |\n| M2 | 敏感操作审计 | 敏感字段访问记录、数据导出记录、人工复核操作留痕 |\n| M3 | 通知分发引擎 | 按通知类型路由到不同通道（系统内通知/IM/EDM/APP Push）；通知优先级管理 |\n| M4 | 通知模板管理 | 各类通知的模板（额度预警/Listing 预警/超时提醒/审批通知/风险告警） |\n| M5 | 人工复核任务 | 管理需要人工复核的任务（弱关联风险/额度预警池/异常评价），供风险/运营人员消费 |\n| M6 | 对外 API Gateway | 接收所有子系统上报的审计事件和通知请求 |\n 43|\n---\n 45|\n## 2. 各模块内外说明\n 47|\n### 2.1 M1: 状态变更审计\n 49|\n| 维度 | 说明 |\n| --- | --- |\n| **对内** | 接收所有子系统的状态变更事件（fire-and-forget）；记录：对象类型（plan/ticket/risk_case/review…）、对象ID、旧状态、新状态、操作人、操作时间、操作原因；审计日志不可篡改（append-only）；支持按对象ID/操作人/时间范围检索 |\n| **对外接口** | `POST /api/audit/event` — 上报审计事件 |\n| **数据写入** | `interaction_audit_logs` |\n| **典型事件** | 计划状态变更（草稿→审批→执行→完成）、工单分配/关闭、风险事件确认/排除、额度手动调整、审批决策 |\n 56|\n### 2.2 M2: 敏感操作审计\n 58|\n| 维度 | 说明 |\n| --- | --- |\n| **对内** | 三类敏感操作：①敏感字段访问（用户上下文卡中的涉密字段→记录访问人/时间/字段/上下文）②数据导出操作（导出人/时间/范围/原因/是否含敏感字段）③人工复核操作（决策人/决策内容/决策依据/时间） |\n| **对外接口** | `POST /api/audit/sensitive-access` — 上报敏感访问 |\n| **数据写入** | `interaction_audit_logs`（带 sensitivity 标记） |\n 64|\n### 2.3 M3: 通知分发引擎\n 66|\n| 维度 | 说明 |\n| --- | --- |\n| **对内** | 接收通知请求→按通知类型路由：①系统内通知（Web 前端轮询/WebSocket）②IM 通知（通过 outreach）③EDM 通知 ④APP Push；优先级管理（紧急 Listing 预警 > 超时提醒 > 额度预警）；通知去重（同一用户同一类型短时间内不重复发） |\n| **对外接口** | `POST /api/notifications/send` — 发送通知 |\n| **依赖** | outreach（IM/EDM/APP Push 通道） |\n 72|\n### 2.4 M4: 通知模板管理\n 74|\n| 维度 | 说明 |\n| --- | --- |\n| **对内** | 通知类型与模板：①额度预警（「真实人 X 的测评额度仅剩 1 次」）②紧急 Listing 预警（「ASIN X 评分接近 4.2，建议紧急催评」）③客服超时提醒（「工单 #123 已超时 N 小时未回复」）④审批通知（「计划 X 等待您的审批」）⑤规则风控提醒（「ASIN X 频控过高」）⑥风险告警（「用户 X 命中强关联风险」） |\n| **对外接口** | 管理 API |\n| **数据写入** | `notification_records` |\n| **待确认** | 模板是否需要多语言（中文/英文/菲律宾语）？模板管理界面在 audit 内部还是独立？ |\n 81|\n### 2.5 M5: 人工复核任务\n 83|\n| 维度 | 说明 |\n| --- | --- |\n| **对内** | 统一管理需人工复核的任务：弱关联风险复核、额度预警池复核、异常评价复核、诈骗疑似复核；任务分配/认领/完成/超时 |\n| **对外接口** | `POST /api/audit/review-task` — 创建复核任务；`GET /api/audit/review-tasks?assignee=` — 查询待复核任务 |\n| **数据写入** | `manual_review_tasks` |\n 89|\n---\n 91|\n## 3. 对外 API 契约（草案）\n 93|\n| 接口 | 方法 | 输入 | 输出 | 消费者 |\n| --- | --- | --- | --- | --- |\n| 上报审计事件 | `POST /api/audit/event` | `{object_type, object_id, old_status, new_status, operator, reason}` | `{event_id}` | 所有子系统（状态变更时调用） |\n| 上报敏感访问 | `POST /api/audit/sensitive-access` | `{operator, field, context, accessed_at}` | `{event_id}` | identity（上下文卡访问） |\n| 发送通知 | `POST /api/notifications/send` | `{recipient, type, template_id, params}` | `{notification_id}` | 所有子系统 |\n| 创建复核任务 | `POST /api/audit/review-task` | `{task_type, target_id, priority, description}` | `{task_id}` | risk, quota |\n 100|\n---\n 102|\n## 4. 数据对象\n 104|\n| 对象 | 核心字段 | 说明 |\n| --- | --- | --- |\n| `interaction_audit_logs` | log_id, object_type, object_id, old_status, new_status, operator, operation, reason, sensitivity_level, logged_at | 审计日志（append-only） |\n| `notification_records` | notification_id, recipient, type, template_id, channel, sent_at, status(SENT/DELIVERED/READ/FAILED) | 通知记录 |\n| `manual_review_tasks` | task_id, task_type, target_id, status(PENDING/ASSIGNED/IN_REVIEW/RESOLVED/TIMEOUT), assignee, priority, created_at, resolved_at | 人工复核任务 |\n 110|\n---\n 112|\n## 5. 业务澄清问题清单 — audit\n 114|\n### 5.1 审计范围与保留（4 项）\n 116|\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| A-01 | 审计日志的保留策略？（保留多久？1 年？永久？到期后归档还是删除？） | **P0** |\n| A-02 | 审计日志的存储量预估？（日产生多少条？是否需要分库分表/冷热分离？） | P1 |\n| A-03 | 审计日志是否需要支持导出/报表？（合规审计时需要导出给外部审计？） | P1 |\n| A-04 | 「敏感字段」的定义范围？（订单号、收款信息、设备号——还有哪些？谁来确定完整清单？） | **P0** |\n 123|\n### 5.2 通知策略（4 项）\n 125|\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| A-05 | 通知发送通道的优先级？（紧急告警用什么通道？IM？系统内通知？邮件？） | P1 |\n| A-06 | 通知去重规则？（同一用户同一类型通知 N 分钟内不重复发？） | P1 |\n| A-07 | 通知是否需要用户偏好设置？（用户可以选择不接收某类通知？公告类通知是否强制发送？） | P2 |\n| A-08 | 通知模板是否需要多语言支持？（中文/英文/菲律宾语？）模板由谁来维护？ | P2 |\n 132|\n### 5.3 人工复核任务（2 项）\n 134|\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| A-09 | 人工复核任务的时效要求？（不同任务类型 SLA？弱关联风险 N 小时内复核？额度预警池 N 分钟内复核？） | P1 |\n| A-10 | 复核任务超时后的升级机制？（自动分配给上级？通知主管？） | P2 |\n 139|\n### 5.4 与其他子系统的协作（2 项）\n 141|\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| A-11 | 通知通道是否完全复用 outreach？（IM/EDM/APP Push）还是 audit 独立对接通知通道？（如果 outreach 不可用，audit 仍需要能发告警） | P1 |\n| A-12 | 审计事件是同步上报还是异步？（同步→影响业务链路性能 / 异步→可能丢失事件） | P1 |\n 146|\n### 5.5 合规与认证（3 项）\n\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| A-13 | 系统是否需要通过合规认证？（SOC2 Type II / ISO 27001？）认证对审计日志的完整性、不可篡改性、保留期限有何具体要求？ | P1 |\n| A-14 | 数据导出请求（DSR）——用户或监管机构要求导出所有个人数据时，系统如何响应？（需要哪些子系统的数据？导出格式？响应时限？） | P1 |\n| A-15 | 审计日志是否需要对第三方审计开放？（外部审计师需要查看审计日志时——权限控制和数据脱敏？） | P2 |\n\n### 5.6 日志保留与归档（3 项）\n\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| A-16 | 审计日志的分级保留策略？（状态变更日志保留 X 年 / 敏感访问日志保留 Y 年 / 通知记录保留 Z 月？） | P1 |\n| A-17 | 日志归档方案？（超过保留期的日志是删除还是归档到冷存储？归档后是否仍可检索？） | P2 |\n| A-18 | 日志存储量预估？（日产生日志条数 × 保留天数 = 需要的存储空间——是否需要分库分表/分区？） | P2 |\n\n### 5.7 敏感数据脱敏（3 项）\n\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| A-19 | 审计日志中是否允许记录敏感字段的明文？（例如「谁在何时查看了用户 X 的收款信息」——收款信息是否脱敏存储？） | P1 |\n| A-20 | 日志查询权限——谁可以查审计日志？（管理员？审计员？）是否需要限制只能查自己相关的日志？ | P1 |\n| A-21 | 生产环境的日志是否可以包含 PII（个人可识别信息）？（邮箱/电话/地址——是否在写入日志时自动脱敏？） | P1 |\n\n### 5.8 通知可靠性（3 项）\n\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| A-22 | 通知的可靠性保证——紧急告警（如 Listing 评分暴跌）是否需要确保送达？（有送达确认机制吗？发送失败后重试？） | P1 |\n| A-23 | 通知通道的优先级切换——IM 通知失败后是否自动切换到 EDM 或系统通知？ | P2 |\n| A-24 | 通知的聚合/摘要——同一个用户短时间收到多条同类通知是否合并？（「您有 3 个待审批计划」而不是 3 条独立通知） | P2 |\n\n### 5.9 实施层面（4 项）\n\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| A-25 | 审计事件是同步写入还是异步写入？（同步→影响业务链路 RT / 异步→可能丢失事件——如何取舍？） | P1 |\n| A-26 | 审计日志的查询性能——是否需要支持全文搜索？（按操作人/对象ID/时间范围检索是否需要在秒级返回？） | P2 |\n| A-27 | 通知通道的可靠性——如果 audit 子系统本身宕机，其他子系统的通知请求是否丢失？（是否需要消息队列做缓冲？） | P1 |\n| A-28 | audit 子系统是否需要独立的数据库？（与其他子系统共享数据库会在高峰期互相影响——是否独立部署数据库？） | P2 |", + "wikilinks": [], + "category": "layer-requirements" + } + }, + { + "id": "doc:05_需求文档/20260504_USER后台ERP_MVP管理员首页高保真原型_v7", + "type": "document", + "name": "USER 后台 ERP MVP · 管理员总览原型 v7", + "filePath": "05_需求文档/20260504_USER后台ERP_MVP管理员首页高保真原型_v7.html", + "summary": "USER 后台 ERP MVP · 管理员总览原型 v7 U USER 后台 ERP MVP 一期 v7 · 模拟数据 待办提醒 21 重要事项 3 审核类 4 紧急 Listing 7 问题总结 9 经营总览 系统管理员 · 最高权限 · 全部部门 搜索 至 日 周 月 全部部门 Amazon 运营 用户运营 客服 系统管理员（最高权限） Amazon 运", + "tags": [ + "05_需求文档", + "需求文档" + ], + "complexity": "complex", + "knowledgeMeta": { + "content": "\n\n\n \n \n USER 后台 ERP MVP · 管理员总览原型 v7\n \n\n\n
\n \n\n
\n
\n
\n
\n 经营总览\n 系统管理员 · 最高权限 · 全部部门\n
\n
\n 搜索\n \n
\n
\n
\n
\n \n 至\n \n
\n
\n \n \n \n
\n \n \n \n
\n
\n\n
\n
\n
\n\n
\n \n\n
\n
\n
\n

操作确认

\n \n
\n
\n
\n
\n\n
\n\n \n\n\n", + "wikilinks": [], + "category": "layer-requirements" + } + }, + { + "id": "doc:05_需求文档/20260517_USER评价业务闭环_共用能力图与渠道专属流程_v2.2", + "type": "document", + "name": "USER 评价业务闭环 — 共用能力图与渠道专属流程 v2.2", + "filePath": "05_需求文档/20260517_USER评价业务闭环_共用能力图与渠道专属流程_v2.2.md", + "summary": "USER 评价业务闭环 — 共用能力图与渠道专属流程 v2.2 文件信息 文件名称： 20260517 USER评价业务闭环 共用能力图与渠道专属流程 v2.2.md 项目路径： C:\\XCODE\\USER 当前版本： v2.2 最近更新： 2026 05 17 上游基线： 工作基线 v1.2 20260517 USER评价业务闭环主流程与后续工作基线 v1", + "tags": [ + "05_需求文档", + "需求文档" + ], + "complexity": "complex", + "knowledgeMeta": { + "content": "# USER 评价业务闭环 — 共用能力图与渠道专属流程 v2.2\n\n## 文件信息\n\n- 文件名称：`20260517_USER评价业务闭环_共用能力图与渠道专属流程_v2.2.md`\n- 项目路径：`C:\\XCODE\\USER`\n- 当前版本：`v2.2`\n- 最近更新：`2026-05-17`\n- 上游基线：[工作基线 v1.2](20260517_USER评价业务闭环主流程与后续工作基线_v1.2.md)\n- 前一版本：\n - `20260517_USER评价业务闭环_共用能力图与渠道专属流程_v1.1.md`\n - `20260517_USER评价业务闭环点击操作模拟_v2.1.md`\n- 文件目的：在基线 v1.2 确认的额度规则和真实人体系上，拆出系统级共用能力图与 IM / EDM / APP / TEL / 客服 / KOC-KOL 六条渠道的专属执行流程，每个节点标注 查 / 写 / 状态 / 提醒 / 拦截。\n- 资料依据：IM 推送业务流脑图、电话业务流程知识库、客服相关模块、后台回评工作流对接事项、状态机 v4、页面设计 v4、原型 HTML。\n- 使用方式：先读基线 v1.2，再读本文件；第三步数据流设计直接引用本文件的节点规则表和数据对象建议。本文件取代 `v1.1` 与 `v2.1` 作为当前第二步主稿。\n\n---\n\n### 1. 总览\n\n```mermaid\nflowchart LR\n A[\"销售 / ASIN数据形成\"] --> B[\"需求触发\"]\n B --> C[\"用户运营评估\"]\n C --> D{\"计划类型\"}\n D --> E[\"评价型计划
推新 / 回评\"]\n D --> F[\"免评计划\"]\n E --> G[\"执行拆解\"]\n F --> G\n G --> SHARED[\"共用能力层\"]\n SHARED --> I1[\"IM\"]\n SHARED --> I2[\"EDM\"]\n SHARED --> I3[\"APP\"]\n SHARED --> I4[\"TEL\"]\n SHARED --> I5[\"客服\"]\n SHARED --> I6[\"KOC / KOL\"]\n I1 & I2 & I3 & I4 & I5 --> J[\"用户互动 / 服务 / 跟进\"]\n J --> K[\"用户真实提交评价\"]\n K --> L[\"计入累计评价额度（12）\"]\n L --> M[\"Amazon展示确认\"]\n M --> N[\"ASIN / 计划 / 用户 / 风险结果回流\"]\n I6 --> O[\"免评结果跟踪\"]\n O --> N\n N --> C\n\n style SHARED fill:#f5f5f5,stroke:#333,stroke-width:3px\n```\n\n#### 节点审查标准\n\n每个关键节点按以下 8 问审：\n\n| ## | 问题 | 标注 |\n| --- | --- | --- |\n| 1 | 入口是什么 | 触发条件 |\n| 2 | 先查什么 | **查** |\n| 3 | 判断什么 | 分岔条件 |\n| 4 | 写什么 | **写** |\n| 5 | 状态怎么变 | **状态** |\n| 6 | 何时提醒 | **提醒** |\n| 7 | 何时拦截 | **拦截** |\n| 8 | 何时转人工 | **转人工** |\n\n---\n\n## 第一部分：共用能力图\n\n### 2. 共用能力一：真实人识别与用户上下文卡\n\n#### 2.1 流程图\n\n```mermaid\nflowchart TB\n A[\"新互动 / 新订单 / 新任务\"] --> B[\"读取身份线索\"]\n B --> B1[\"JOYHUB ID\"]\n B --> B2[\"邮箱\"]\n B --> B3[\"电话\"]\n B --> B4[\"设备号\"]\n B --> B5[\"订单号\"]\n B --> B6[\"姓名 + 地址\"]\n\n B1 & B2 & B3 & B4 & B5 & B6 --> C[\"归并真实人\"]\n C --> D{\"匹配结果\"}\n D -->|\"标准化姓名+地址一致\"| E[\"强关联 → 同一真实人\"]\n D -->|\"地址一致姓名不同\"| F[\"家庭/关联风险 → 不直接合并\"]\n D -->|\"多线索交叉\"| G[\"按设备/电话/邮箱/收款信息权重合并\"]\n\n E & F & G --> H[\"生成 / 更新真实人 ID\"]\n H --> I[\"拉取用户上下文卡\"]\n\n I --> J[\"历史交易
订单/购买/退款/返款/ASIN\"]\n I --> K[\"历史服务
工单/聊天/电话/承诺/提醒\"]\n I --> L[\"历史风险
黑名单/诈骗/关联/异常\"]\n I --> M[\"当前设备
型号/版本/换机记录\"]\n I --> N[\"触达历史
IM/EDM/APP/TEL 近期记录\"]\n\n J & K & L & M & N --> O[\"上下文卡快照 → 供客服/运营/风险使用\"]\n```\n\n#### 2.2 用户上下文卡字段组\n\n| 字段组 | 具体内容 |\n| --- | --- |\n| 当前身份 | JOYHUB ID、邮箱、电话、当前订单、真实人 ID |\n| 真实人归并 | 姓名+地址（标准化）、设备号、电话、邮箱、Profile ID、收款信息、关联账号列表 |\n| 历史交易 | 历史订单、购买频次、最近购买、历史退款、历史返款、目标 ASIN 购买记录 |\n| 历史服务 | 历史工单、聊天记录、通话记录、已承诺事项、已发送提醒、工单关闭原因 |\n| 历史风险 | 黑名单标记、强关联记录、弱关联记录、疑似诈骗、双重退款、异常订单 |\n| 当前设备 | 设备号摘要、设备型号/类型、系统版本、APP 版本、最近设备变化（换机/多设备） |\n| 触达历史 | IM 最近触达/回复/退订、EDM 最近打开/点击/退订、APP 最近 Push、TEL 最近拨打 |\n\n#### 2.3 节点规则\n\n| 节点 | 查 | 写 | 状态 | 提醒 | 拦截 |\n| --- | --- | --- | --- | --- | --- |\n| 归并真实人 | JOYHUB、邮箱、电话、设备、订单、地址 | 真实人匹配结果、匹配证据、置信度 | 新真实人 / 已存在 | 标准化姓名+地址一致时强提示 | - |\n| 拉取上下文卡 | 交易、工单、风险、设备、触达全量记录 | 上下文快照（含快照时间） | 首次生成 / 增量更新 | 命中黑名单/异常时高亮 | 严重风险标记时阻止自动通过 |\n| 设备变化识别 | 设备号、型号、系统版本、APP版本 | 设备变化记录、变化时间 | 设备正常 / 近期换机 / 多设备 | 近期换机或同设备多账号提示 | - |\n\n---\n\n### 3. 共用能力二：人群生成与画像拆解\n\n#### 3.1 流程图\n\n```mermaid\nflowchart TB\n A[\"计划进入人群生成\"] --> B[\"基础过滤\"]\n B --> B1[\"硬排除：国家/站点/可达性/退订/黑名单/未关闭工单\"]\n\n B1 --> C[\"画像匹配\"]\n C --> C1[\"基础画像：国家/语言/性别/年龄段/注册时间\"]\n C --> C2[\"产品关系：绑定玩具/绑定数量/绑定品类/目标产品\"]\n C --> C3[\"交易画像：历史订单/购买频次/是否买过目标ASIN\"]\n C --> C4[\"行为画像：活跃度/打开率/点击率/历史回评率/配合率\"]\n C --> C5[\"触达画像：各渠道可达性/最近触达/退订\"]\n C --> C6[\"风险画像：黑名单/设备关联/地址关联/退款异常\"]\n C --> C7[\"计划画像：是否参加过推新/回评/免评/最近结果\"]\n\n C1 & C2 & C3 & C4 & C5 & C6 & C7 --> D[\"历史行为评分\"]\n\n D --> E[\"额度与频控校验
（进入 §4 共用能力三）\"]\n E --> F[\"风险复检
（进入 §6 共用能力五）\"]\n F --> G[\"生成候选人群快照 + 排除快照\"]\n```\n\n#### 3.2 画像字段的三类用途\n\n| 类型 | 作用 | 示例字段 |\n| --- | --- | --- |\n| **硬过滤** | 决定能不能进池 | 国家、可达性、黑名单、退订、未关闭工单、额度超限 |\n| **匹配条件** | 决定是否适合当前计划 | 绑定玩具、目标品类、年龄、性别、是否买过目标 ASIN |\n| **排序权重** | 决定触达优先级 | 活跃度、历史回评率、历史配合率、最近互动时间 |\n\n#### 3.3 节点规则\n\n| 节点 | 查 | 写 | 状态 | 提醒 | 拦截 |\n| --- | --- | --- | --- | --- | --- |\n| 基础过滤 | 国家、站点、可达性、退订、黑名单、未关闭工单 | 排除原因记录 | 入池 / 排除 | - | 黑名单/退订/强关联直接排除 |\n| 画像匹配 | 7 组画像字段 | 匹配分组与得分 | 匹配 / 不匹配 / 待补全 | 画像缺失可补全 | - |\n| 历史行为评分 | 活跃、点击、回复、回评率、配合率、投诉 | 评分结果、排序权重 | 高分 / 中分 / 低分 | 低活跃用户降级提醒 | - |\n| 生成快照 | 过滤、匹配、评分、额度、风险全量结果 | 人群快照、排除快照、快照时间 | 已生成 | 排除比例异常时提醒 | 快照为空时拦截 |\n\n---\n\n### 4. 共用能力三：额度台账与频控控制\n\n#### 4.1 已确认额度规则\n\n| 规则 | 统计对象 | 计数口径 | 计数时点 |\n| --- | --- | --- | --- |\n| 每月测评最多 4 次 | 真实人 | 已完成 + 进行中 + 已预占 | - |\n| 每月免评最多 4 次 | 真实人 | 已完成 + 进行中 + 已预占 | - |\n| 累计真实提交评价最多 12 个 | 真实人 | 用户真实提交评价后立即计数 | 用户真实提交评价时 |\n\n#### 4.2 流程图\n\n```mermaid\nflowchart TB\n A[\"识别真实人\"] --> B[\"读取额度台账\"]\n B --> B1[\"本月测评：已完成 / 进行中 / 已预占\"]\n B --> B2[\"本月免评：已完成 / 进行中 / 已预占\"]\n B --> B3[\"累计真实提交：当前 / 上限 12\"]\n B --> B4[\"并发占用：跨计划重复入选检测\"]\n\n B1 & B2 & B3 & B4 --> C{\"额度判断\"}\n C -->|\"剩余 ≥ 本次拟发送\"| D[\"进入普通候选池
→ 预占额度\"]\n C -->|\"剩余不足但 > 0\"| E[\"进入预警池
→ 预占额度 → 发送前人工复核\"]\n C -->|\"已用 + 预占 + 本次 ≥ 上限\"| F[\"排除自动推送\"]\n\n D --> G[\"写入预占记录\"]\n E --> G\n\n G --> H[\"频控复核\"]\n H --> H1[\"渠道频控：IM/EDM/APP/TEL 最近触达间隔\"]\n H --> H2[\"单 ASIN 短期触达次数\"]\n H --> H3[\"用户反感度/投诉/退订状态\"]\n\n H1 & H2 & H3 --> I{\"频控判断\"}\n I -->|通过| J[\"进入发送队列\"]\n I -->|不通过| K[\"延后 / 降频 / 排除\"]\n\n J --> L[\"发送前再次读取最新额度 + 风险\"]\n L --> M{\"最终校验\"}\n M -->|通过| N[\"发送\"]\n M -->|新增超限/风险| O[\"撤出本批次\"]\n```\n\n#### 4.3 额度 vs 频控的区别\n\n| 类别 | 统计维度 | 周期 | 拦截时机 |\n| --- | --- | --- | --- |\n| **渠道频控** | 单渠道触达次数/间隔 | 按日/周/月 | 发送前 |\n| **月度业务额度** | 真实人测评 4 / 免评 4 | 自然月 | 人群生成 + 发送前 |\n| **累计评价额度** | 真实人累计 12 | 永久累计 | 用户提交评价时更新、下次人群生成时判断 |\n| **并发占用控制** | 进行中 + 已预占 + 跨计划重复 | 实时 | 人群生成 + 预占时 |\n\n#### 4.4 节点规则\n\n| 节点 | 查 | 写 | 状态 | 提醒 | 拦截 |\n| --- | --- | --- | --- | --- | --- |\n| 读取额度台账 | 本月测评/免评、累计提交、进行中、已预占 | 当前额度快照 | - | 剩余 ≤ 1 或本批次将打满时预警 | - |\n| 预占额度 | 候选计划、预计发送量、当前剩余 | 额度预占记录 | 已预占 | - | 预计超限阻止进入自动发送 |\n| 频控复核 | IM/EDM/APP/TEL 最近触达、ASIN频次、退订/投诉 | 频控校验结果 | 通过 / 降频 / 排除 | 接近频控上限时提醒 | 超频直接排除 |\n| 发送前终校 | 最新额度、最新风险、最新未关闭工单 | 发送前校验结果 | 准入 / 撤出 | 任何新增异常立即提示 | 新增超限/风险撤出本批次 |\n\n---\n\n### 5. 共用能力四：每次有效互动复检\n\n#### 5.1 流程图\n\n```mermaid\nflowchart TB\n A[\"触发复检的事件\"] --> A1[\"主动推送后回复\"]\n A --> A2[\"再次联系\"]\n A --> A3[\"补充订单号\"]\n A --> A4[\"客服回访\"]\n A --> A5[\"电话来电\"]\n A --> A6[\"退款/返款/继续推送前\"]\n\n A1 & A2 & A3 & A4 & A5 & A6 --> X[\"重新读取四组数据\"]\n\n X --> X1[\"身份：真实人/JOYHUB/邮箱/电话/设备/订单/地址\"]\n X --> X2[\"历史：订单/工单/触达/退款/返款\"]\n X --> X3[\"额度：本月测评/免评/累计提交/进行中/预占\"]\n X --> X4[\"风险：黑名单/强弱关联/双重退款/异常订单\"]\n\n X1 & X2 & X3 & X4 --> Y{\"判断结果\"}\n Y -->|正常 + 额度充足| Z[\"继续业务\"]\n Y -->|弱风险 / 接近额度上限| W[\"继续但显著提示 → 人工关注\"]\n Y -->|强风险 / 额度超限| V[\"暂停当前动作 → 转风险中心或人工复核\"]\n```\n\n#### 5.2 节点规则\n\n| 节点 | 查 | 写 | 状态 | 提醒 | 拦截 |\n| --- | --- | --- | --- | --- | --- |\n| 身份复检 | JOYHUB、邮箱、电话、设备、订单、地址是否变化 | 身份变化记录 | 未变 / 新增关联 / 冲突 | 设备变化/地址变化提示 | - |\n| 历史复检 | 是否有新订单、新工单、新触达、新退款 | 历史变化记录 | 无变化 / 有更新 | 新退款/新工单提示 | - |\n| 额度复检 | 最新测评/免评/累计额度 | 最新额度快照 | 充足 / 预警 / 超限 | 接近上限预警 | 超限拦截 |\n| 风险复检 | 黑名单、强弱关联、双重退款、异常 | 最新风险结果 | 正常 / 弱风险 / 强风险 | 任何命中高亮提醒 | 强关联暂停自动操作 |\n\n---\n\n### 6. 共用能力五：风险判断与黑名单\n\n#### 6.1 风险分层\n\n| 风险类型 | 关联项 | 处理原则 |\n| --- | --- | --- |\n| **强关联** | 邮箱、设备号、电话、收件人姓名+地址、订单号、聊天记录、Profile ID、收款信息 | 一旦命中，直接进入高风险或黑名单链路 |\n| **弱关联** | IP 单独命中、姓名单独命中、同址异名 | 进入高风险观察 + 人工复核，不直接认定诈骗 |\n\n#### 6.2 流程图\n\n```mermaid\nflowchart TB\n A[\"风险信号进入
（新订单同步/触达回应/用户接入/退款申请/再次跟进）\"] --> B[\"强弱关联判断\"]\n\n B --> C{\"关联等级\"}\n C -->|强关联| D[\"高风险 / 黑名单链路\"]\n C -->|弱关联| E[\"高风险观察 + 人工复核\"]\n C -->|无关联| F[\"正常继续\"]\n\n D --> D1[\"拦截继续推送\"]\n D --> D2[\"拦截自动退款\"]\n D --> D3[\"拦截自动放行\"]\n D1 & D2 & D3 --> G[\"回写工单 / 推送 / 计划状态\"]\n G --> H[\"提醒客服 / 用户运营 / 审核人员\"]\n\n E --> E1[\"显著风险提醒\"]\n E1 --> E2[\"人工复核\"]\n E2 --> E3{\"复核结论\"}\n E3 -->|确认风险| D\n E3 -->|排除风险| F\n```\n\n#### 6.3 已确认业务问题\n\n1. **双重退款**：APP/OA 已退款 + 用户又向 Amazon 申请退款 → 需要 Amazon 退款与 OA 返款自动比对\n2. **高风险用户**：一旦标记，支付/返款需要人工复核\n3. **风险可见性**：客服、审核、退款等环节必须都能看到风险提醒\n4. **非 APP 用户盲区**：直接走邮件退款，缺设备/注册邮箱等维度，识别能力下降\n5. **每次互动重判**：风险判断不是一次性的，每次有效互动都要重新执行\n\n#### 6.4 节点规则\n\n| 节点 | 查 | 写 | 状态 | 提醒 | 拦截 |\n| --- | --- | --- | --- | --- | --- |\n| 强弱关联判断 | 邮箱/设备/电话/地址/订单/ProfileID/收款信息/IP | 关联结果、命中维度列表 | 强关联 / 弱关联 / 无 | 命中时高亮命中维度 | - |\n| 高风险链路 | 当前推送/退款/返款状态 | 风险事件、拦截记录 | 已拦截 / 待复核 | 通知所有关联环节 | 拦截继续推送/自动退款/自动放行 |\n| 双重退款检测 | Amazon退款记录 + OA返款记录 | 匹配结果、差异 | 无重复 / 疑似重复 / 确认重复 | 确认重复时强告警 | 确认重复时阻止后续返款 |\n\n---\n\n### 7. 共用能力六：审批工作流\n\n```mermaid\nflowchart LR\n PLAN[\"计划草案\"] --> R1{\"计划类型\"}\n R1 -->|测评计划| A1[\"Amazon运营总监审批\"]\n R1 -->|回评计划| A2[\"Amazon运营总监或指定负责人\"]\n R1 -->|免评计划| A3[\"Amazon运营总监 + 用户负责人\"]\n R1 -->|紧急计划| A4[\"Amazon运营负责人 + 用户负责人 + 主管\"]\n\n A1 & A2 & A3 & A4 --> NEXT[\"周/月推送计划\"]\n NEXT --> N1[\"用户负责人审批\"]\n N1 --> N2[\"渠道负责人审批\"]\n N2 --> APPROVED[\"已批准 → 执行\"]\n```\n\n#### 7.1 审批节点规则\n\n| 节点 | 查 | 写 | 状态 | 提醒 | 拦截 |\n| --- | --- | --- | --- | --- | --- |\n| Amazon运营总监审批 | 计划详情、ASIN健康、风险提醒 | 审批结果、审批意见 | 通过 / 驳回 / 待补充 | 驳回时通知提交人 | - |\n| 用户负责人审批 | 人群快照、额度占用、频控结果 | 审批结果 | 通过 / 驳回 | 额度接近上限时预警 | - |\n| 渠道负责人审批 | 渠道容量、素材、合规 | 审批结果 | 通过 / 驳回 | 素材/文案风险提醒 | 合规风险时拦截 |\n\n---\n\n### 8. 共用能力七：审计与通知中心\n\n| 模块 | 职责 | 关键记录内容 |\n| --- | --- | --- |\n| 状态变更审计 | 所有业务对象的状态流转留痕 | 对象ID、旧状态、新状态、操作人、时间、原因 |\n| 敏感字段访问 | 涉密字段的每次读取记录 | 访问人、访问时间、访问字段、访问上下文 |\n| 导出操作 | 所有数据导出行为留痕 | 导出人、时间、范围、原因、是否含敏感字段 |\n| 人工复核操作 | 所有人工干预决策留痕 | 决策人、决策内容、决策依据、决策时间 |\n| **规则风控提醒** | 触发规则/审核/风控阈值时通知 | 同一ASIN频控过高、同一用户多次推送、设备/邮箱异常、站点任务过密 |\n| **紧急Listing预警** | 评分接近4.2时通知 | ASIN、当前评分、差评摘要、建议动作 |\n| **客服超时提醒** | 工单/答应配合超时通知 | 工单ID、超时类型、超时时长、责任人 |\n| **额度预警** | 额度接近上限时通知 | 真实人、额度类型、已用/上限、受影响计划 |\n\n---\n\n## 第二部分：渠道专属流程图\n\n### 9. 渠道一：IM 推送专属流程\n\n#### 9.1 用户分层与推送策略\n\n```mermaid\nflowchart TB\n U[\"用户注册 + 绑定玩具\"] --> L1{\"识别用户分层\"}\n\n L1 -->|\"A 未参与过
从未走过回评/测评\"| A1[\"推送前校验\"]\n A1 --> A1a[\"查：JOYHUB ID、设备ID、黑名单、绑定产品\"]\n A1 --> A1b{\"设备ID在黑名单？\"}\n A1b -->|是| A2[\"写：打标'长期测评人'
拦截：不推回评/测评卡片
推送：免评产品卡片\"]\n A1b -->|否| A3[\"推送：对应绑定产品的回评卡片
写：推送记录\"]\n\n L1 -->|\"B 已参与过
真实人累计真实提交评价 < 12\"| B1[\"优先催评\"]\n B1 --> B1a[\"查：未回评测评单、真实人累计评价数、标签\"]\n B1 --> B1b[\"推送：催评卡片/消息\"]\n B1b --> B2{\"完成好评提交？\"}\n B2 -->|是| B3[\"写：重新计算真实人累计评价数\"]\n B3 --> B4{\"累计真实提交评价仍 < 12？\"}\n B4 -->|是| B5[\"推送：当日测评计划对应卡片
写：二次转化记录\"]\n B4 -->|否| B6[\"写：打标'长期测评人'→ 推送免评产品\"]\n\n L1 -->|\"C 长期测评人
真实人累计真实提交评价 ≥ 12\"| C1[\"拦截：不推送普通回评/测评卡片
推送：当日免评补单产品
写：免评推送记录\"]\n\n style A2 fill:#fce4ec\n style C1 fill:#fff3e0\n```\n\n#### 9.2 IM 用户提交后的核验与流转\n\n```mermaid\nflowchart TB\n SUBMIT[\"入口：用户在IM中提交回评/测评信息\"] --> ITEMS[\"提交内容：订单号 + 返款账号 + 评论截图/链接\"]\n\n ITEMS --> AUTO[\"查：当前用户标签、关联计划
写：系统自动登记提交记录
状态：待核验\"]\n\n AUTO --> VERIFY[\"订单号核实\"]\n VERIFY --> V1{\"查：是否测评单？\"}\n VERIFY --> V2{\"查：是否为公司产品？\"}\n VERIFY --> V3{\"查：单号格式 xxx-xxxxxxx-xxxxxxx？\"}\n\n V1 & V2 & V3 -->|全部通过| PASS[\"写：登记进系统
状态：已登记\"]\n V1 & V2 & V3 -->|任一不通过| CS[\"转人工：推送客服
状态：待客服处理\"]\n\n CS --> CS1[\"客服沟通用户 → 补充/修正信息\"]\n CS1 --> CS2[\"写：修正记录 → 回到核验\"]\n\n PASS --> CHECK{\"信息完整？\"}\n CHECK -->|完整| FINANCE[\"写：推送财务返款提醒
状态：待返款\"]\n CHECK -->|缺返款账号| TAG1[\"写：打标'xx产品待返款'
提醒：自动通知用户补充
状态：信息待补全\"]\n CHECK -->|缺评论截图/链接| TAG2[\"写：打标'xx产品待回评'
提醒：自动通知用户补充
状态：信息待补全\"]\n\n FINANCE --> PAY[\"查：付款凭证
写：自动推送返款/礼品卡通知
状态：已返款\"]\n PAY --> DONE[\"状态：回评流程走完\"]\n DONE --> TAG3[\"写：打标'xx产品已回评用户'
推送：测评卡片（二次转化）\"]\n\n style SUBMIT fill:#e8f5e9\n style PASS fill:#c8e6c9\n style CS fill:#fff3e0\n style DONE fill:#e3f2fd\n```\n\n#### 9.3 IM 新测评流程\n\n```mermaid\nflowchart TB\n START[\"入口：用户收到测评卡片 → 提交测评信息\"] --> VFY[\"查：订单号是否撤销、是否退款
查：真实人月度测评额度与累计真实提交评价\"]\n\n VFY -->|\"额度允许 + 订单有效\"| REG[\"写：登记进系统
写：打标'xx产品测评单登记'
状态：已登记\"]\n\n REG --> INFO{\"信息完整？\"}\n INFO -->|只有订单号
缺返款账号+截图| TAG_A[\"写：打标'xx产品测评待返款'
提醒：自动通知用户
状态：待补全\"]\n INFO -->|只有截图+链接
缺订单号+返款账号| TAG_B[\"写：打标'xx产品测评单待回评'
提醒：自动通知用户
状态：待补全\"]\n INFO -->|完整| COMP[\"状态：测评流程走完\"]\n\n COMP --> RECALC[\"查：重新计算 review 数量
写：review 数量更新\"]\n RECALC -->|\"累计真实提交评价 ≥ 12\"| LC[\"写：打标'长期测评人'
推送：免评产品卡片\"]\n RECALC -->|\"≤ 12 review\"| NEXT[\"推送：当日测评计划对应卡片
写：二次转化记录\"]\n\n style COMP fill:#c8e6c9\n style LC fill:#fff3e0\n```\n\n#### 9.4 IM 核心标签汇总\n\n| 分类 | 标签 | 触发时机 | 后续动作 |\n| --- | --- | --- | --- |\n| **用户层级** | 未参与过用户 (A) | 注册+绑定后首次识别 | 推送回评卡片 |\n| | 参与过用户 (B) | 已有回评/测评记录，review < 12 | 优先催评 → 二次转化 |\n| | 长期测评人 (C) | review > 12 | 仅推送免评产品 |\n| **回评流程** | xx产品已回评用户 | 回评流程走完 | 推送测评卡片 |\n| | xx产品待回评用户 | 缺截图/链接 | 自动通知补全 |\n| | xx产品待返款 | 缺返款账号 | 自动通知补全 |\n| **测评流程** | xx产品测评单登记 | 订单核实通过 | 继续信息补全 |\n| | xx产品测评待返款用户 | 测评缺返款 | 自动通知补全 |\n| | xx产品测评单待回评 | 测评缺截图 | 自动通知补全 |\n| | xx产品测评单 | 测评流程走完 | review重算 |\n| **免评流程** | xx产品的免评 | 长期测评人参与免评单 | 不再推回评/测评 |\n\n#### 9.5 IM 推送动作与流转动作\n\n| 动作类型 | 动作 | 说明 |\n| --- | --- | --- |\n| **推送** | 回评卡片 | A类用户首次推送 |\n| | 测评卡片 | B类二次转化 / A类设备在黑名单 |\n| | 免评产品卡片 | C类用户 / 黑名单命中用户 |\n| | 催评消息 | B类优先催评 / 紧急催评 |\n| | 返款/礼品卡通知 | 财务有凭证后推送 |\n| **流转** | 推送客服 | 订单号不符合 / 异常 |\n| | 推送财务 | 订单登记完成后 |\n| | 自动打标 | 各流程节点完成时 |\n| | 二次转化 | 回评完成 → 推送测评卡片 |\n\n---\n\n### 10. 渠道二：EDM 邮件推送专属流程\n\n#### 10.1 流程图\n\n```mermaid\nflowchart TB\n START[\"入口：计划已批准，进入EDM执行拆解\"] --> POOL[\"筛选EDM目标用户池\"]\n\n POOL --> COND{\"查：用户条件\"}\n COND -->|\"非APP用户\"| NON[\"进入EDM队列\"]\n COND -->|\"APP低活跃\"| LOW[\"查：IM频控通过后进入EDM队列\"]\n COND -->|\"APP活跃\"| SKIP[\"拦截：跳过EDM，走IM/APP\"]\n\n NON --> PRECHK[\"推送前检查\"]\n LOW --> PRECHK\n\n PRECHK --> C1[\"查：身份——是否有有效邮箱\"]\n PRECHK --> C2[\"查：风险——邮箱是否命中黑名单\"]\n PRECHK --> C3[\"查：退订——是否已退订/硬退信\"]\n PRECHK --> C4[\"查：资格——OA是否有资格\"]\n PRECHK --> C5[\"查：国家——站点与邮箱类型匹配\"]\n\n C1 & C2 & C3 & C4 & C5 -->|全部通过| BEHAVIOR[\"行为筛选\"]\n C1 & C2 & C3 & C4 & C5 -->|任一不通过| EXCLUDE[\"写：排除原因
拦截：不发送\"]\n\n BEHAVIOR --> B1[\"查：最近打开时间、总打开次数\"]\n BEHAVIOR --> B2[\"查：最近3/5次是否连续0打开\"]\n BEHAVIOR --> B3[\"查：最近回复时间、回复后又发送数\"]\n BEHAVIOR --> B4[\"查：是否点击评论链接但未回复\"]\n BEHAVIOR --> B5[\"查：单月收信次数、各邮件类型发送次数\"]\n\n B1 & B2 & B3 & B4 & B5 --> RHYTHM{\"节奏判断\"}\n RHYTHM -->|适合触达| SEND[\"发送EDM
写：发送记录
状态：已发送\"]\n RHYTHM -->|需降频| DELAY[\"写：延后标记
状态：观察中\"]\n RHYTHM -->|不适合| SWITCH[\"切换其他渠道或排除\"]\n\n SEND --> TRACK[\"追踪回收\"]\n TRACK --> T1[\"送达 → 写：送达时间\"]\n T1 --> T2[\"打开 → 写：打开时间、打开次数+1\"]\n T2 --> T3[\"点击 → 写：点击时间、点击目标\"]\n T3 --> T4[\"跳转至APP下载页/产品页\"]\n T4 --> RESULT{\"用户行为\"}\n RESULT -->|\"下载并注册APP\"| TO_IM[\"写：用户渠道升级
后续走IM主流程\"]\n RESULT -->|\"直接回复邮件\"| TO_CS[\"写：生成客服工单
走客服执行流程\"]\n RESULT -->|\"未响应\"| RETRY[\"写：进入再触达队列
（遵循频控间隔）\"]\n RESULT -->|\"退订\"| UNSUB[\"写：退订标记
拦截：该渠道永久排除\"]\n\n SEND --> METRICS[\"写：EDM指标
发送数/送达率/打开率/点击率/回复率/转化数/退订数\"]\n\n style EXCLUDE fill:#fce4ec\n style UNSUB fill:#fce4ec\n style TO_IM fill:#e3f2fd\n style TO_CS fill:#fff3e0\n```\n\n#### 10.2 EDM 专属行为指标\n\n| 字段组 | 具体指标 | 用途 |\n| --- | --- | --- |\n| **打开行为** | 最近打开时间、总打开次数、最近3/5次0打开 | 判断活跃度 → 决定是否继续发 |\n| **回复行为** | 最近回复时间、回复后又发送封数 | 判断兴趣度 → 决定触达节奏 |\n| **点击行为** | 是否点击评论链接、点击后未回复时长 | 判断意向 → 决定是否追加触达 |\n| **触达频率** | 单月收信次数、各邮件类型发送次数 | 频控 → 防止疲劳 |\n| **邮件属性** | 邮件类型、邮箱后缀标签、国家站点 | 匹配 → 确定发送内容 |\n| **排除项** | 风险用户、黑名单、退订、硬退信、OA无资格 | 硬过滤 → 不进池 |\n\n#### 10.3 EDM vs IM 关键差异\n\n| 维度 | IM | EDM |\n| --- | --- | --- |\n| 用户身份强度 | 强（JOYHUB ID + 设备 + 订单绑定） | 弱（仅邮箱，可能无JOYHUB ID） |\n| 风险识别能力 | 高（多维度交叉） | 低（缺设备/注册邮箱等维度） |\n| 转化路径 | 直接提交 → 核验 → 返款 | 引导注册APP → 再进入IM链路 |\n| 退订机制 | 社区屏蔽/消息免打扰 | 邮件退订链接 + 硬退信 |\n| 频控周期 | 按日/按类目 | 按周/按月 |\n| 行为信号 | 绑定/活跃/点击/回复/标签 | 打开/点击/回复/退订/连续0打开 |\n\n---\n\n### 11. 渠道三：APP Push 专属流程\n\n#### 11.1 流程图\n\n```mermaid\nflowchart TB\n START[\"触发源\"] --> T1[\"用户绑定新玩具\"]\n START --> T2[\"用户长期未活跃（7天+）\"]\n START --> T3[\"测评/回评计划到期\"]\n START --> T4[\"Listing健康紧急\"]\n START --> T5[\"活动/促销通知\"]\n\n T1 & T2 & T3 & T4 & T5 --> FILTER[\"查：共用能力过滤\"]\n\n FILTER --> F1[\"查：身份——JOYHUB ID + 设备在线\"]\n FILTER --> F2[\"查：风险——黑名单 + 关联检测\"]\n FILTER --> F3[\"查：频控——当日Push次数 + 用户通知设置\"]\n FILTER --> F4[\"查：标签——匹配推送策略\"]\n\n F1 & F2 & F3 & F4 -->|通过| PUSH[\"发送APP Push
写：推送记录
状态：已发送\"]\n F1 & F2 & F3 & F4 -->|不通过| SKIP[\"写：跳过原因
状态：已跳过\"]\n\n PUSH --> USER{\"用户响应\"}\n USER -->|\"点击打开\"| IN_APP[\"进入APP → 落地页\"]\n USER -->|\"忽略/关闭\"| NOOP[\"写：曝光记录
拦截：短期内不重复推\"]\n USER -->|\"卸载/禁用通知\"| UNINSTALL[\"写：不可再推送标记
降级：转入EDM候选池\"]\n\n IN_APP --> ACT{\"APP内动作\"}\n ACT -->|\"提交回评/测评\"| IM_FLOW[\"走IM提交核验流程（§9.2）\"]\n ACT -->|\"联系客服\"| CS_FLOW[\"生成客服工单（§12）\"]\n ACT -->|\"仅浏览\"| TAG[\"写：记录行为，更新活跃标签\"]\n\n style IN_APP fill:#e3f2fd\n style UNINSTALL fill:#fce4ec\n```\n\n#### 11.2 APP Push 与 IM 的分工\n\n| 场景 | 用 APP Push | 用 IM |\n| --- | --- | --- |\n| 新绑定玩具 → 引导测评 | - | 推送回评/测评卡片 |\n| 用户7天未活跃 | 推送召回通知 | - |\n| 测评计划到期提醒 | - | 推送催评消息 |\n| Listing 紧急 | 推送紧急通知 | 推送紧急催评卡片 |\n| 返款已到账 | 推送到账通知 | - |\n| 活动/促销 | 推送活动通知 | - |\n\n#### 11.3 APP 必查字段\n\n| 字段组 | 内容 |\n| --- | --- |\n| 用户资料 | 注册邮箱、JOYHUB ID、国家、语言 |\n| 设备上下文 | 设备号、设备型号/类型、APP版本、系统版本 |\n| 产品关系 | 绑定玩具、绑定时间、目标产品关系 |\n| 行为数据 | 活跃、打开、点击、回复、站内浏览、广告互动 |\n\n---\n\n### 12. 渠道四：TEL 电话专属流程\n\n#### 12.1 流程图\n\n```mermaid\nflowchart TB\n START[\"触发电话任务\"] --> S1[\"用户答应配合但超时未提交\"]\n START --> S2[\"高价值用户需深度跟进\"]\n START --> S3[\"复杂售后无法文字解决\"]\n START --> S4[\"IM/EDM多次触达无响应\"]\n START --> S5[\"紧急Listing需人工沟通\"]\n START --> S6[\"Amazon页面/说明书来电\"]\n START --> S7[\"计划生成的外呼任务\"]\n\n S1 & S2 & S3 & S4 & S5 & S6 & S7 --> TICKET[\"写：生成电话类客服工单
状态：待分配\"]\n\n TICKET --> PREPARE[\"拨打前准备（必须）\"]\n PREPARE --> P1[\"查：用户完整画像
（身份/订单/历史/标签/风险）\"]\n PREPARE --> P2[\"查：风险状态
拦截：强关联命中 → 暂停拨打 → 先复核\"]\n PREPARE --> P3[\"查：历史沟通记录
（避免重复询问）\"]\n PREPARE --> P4[\"写：准备话术和问题清单\"]\n\n P1 & P2 & P3 & P4 --> CONTACT[\"客服电话联系用户
写：拨打记录
状态：处理中\"]\n\n CONTACT --> RESULT{\"通话结果\"}\n RESULT -->|\"接通-售后问题\"| AFTERSALE[\"先解决售后
查：订单/产品/凭证
写：处理方案
状态：售后处理中\"]\n RESULT -->|\"接通-直接配合\"| COOP[\"确认评价提交时间
写：登记答应配合
状态：答应配合\"]\n RESULT -->|\"接通-拒绝\"| REJECT[\"写：记录拒绝原因
状态：已关闭\"]\n RESULT -->|\"接通-疑似诈骗\"| FRAUD[\"创建诈骗事件
写：诈骗记录
转风险链路（§6）\"]\n RESULT -->|\"未接通\"| RETRY[\"写：拨打次数+1
提醒：安排重试\"]\n\n AFTERSALE --> SAT{\"是否解决/满意？\"}\n SAT -->|是| INVITE[\"引导回评/邀请测评\"]\n SAT -->|否| ESCALATE[\"升级处理 → 转组长/负责人\"]\n\n INVITE --> FOLLOW[\"写：进入答应配合跟进
状态：待提醒\"]\n COOP --> FOLLOW\n FOLLOW --> UPDATE[\"写：更新工单 + 用户标签\"]\n\n RETRY --> DECIDE{\"重试策略\"}\n DECIDE -->|\"< 3次\"| CONTACT\n DECIDE -->|\"≥ 3次未接通\"| DOWNGRADE[\"写：降级至EDM/放弃
状态：待关闭\"]\n\n CONTACT --> RECORD[\"写：通话记录
来电时间/来源/联系方式/订单号
问题类型/描述/处理方案
是否解决/是否邀请测评/用户是否接受\"]\n\n style CONTACT fill:#fff3e0,stroke:#ef6c00\n style FRAUD fill:#fce4ec,stroke:#c62828\n style AFTERSALE fill:#e3f2fd\n```\n\n#### 12.2 TEL 必填记录字段\n\n| 类别 | 字段 | 涉密 |\n| --- | --- | --- |\n| 来电基础 | 来电时间、来源（Amazon页/说明书/外呼）、客服、联系方式 | - |\n| 订单信息 | Amazon订单号、产品型号/款式/颜色、购买时间 | 订单号涉密 |\n| 问题信息 | 问题类型、问题描述、图片/视频凭证 | - |\n| 处理信息 | 处理方案、是否解决、是否需要后续跟进 | - |\n| 评价相关 | 是否邀请回评/测评、用户是否接受、是否涉及差评 | - |\n| 拨打统计 | 拨打次数、通话时长、接通状态 | - |\n\n---\n\n### 13. 渠道五：客服工单执行流程\n\n#### 13.1 流程图\n\n```mermaid\nflowchart TB\n A[\"入口：用户消息 / 推送转人工 / 电话后续 / 风险触发\"] --> B[\"写：生成工单
状态：待分配\"]\n\n B --> C[\"查：班次、在线状态、当前负载、最大工单数
写：自动分配到客服组
状态：已分配\"]\n\n C --> D[\"客服组长分派到组员
状态：处理中\"]\n\n D --> E[\"查：展示用户上下文卡
（身份/历史/风险/设备/触达）\"]\n\n E --> F[\"客服开始处理\"]\n\n F --> G{\"处理结果\"}\n G -->|\"等待用户回复\"| H[\"状态：等待用户
提醒：超时提醒机制\"]\n G -->|\"等待内部协同\"| I[\"状态：等待内部
提醒：超时升级\"]\n G -->|\"用户答应配合\"| J[\"写：生成跟进任务
状态：答应配合
进入答应配合状态机\"]\n G -->|\"疑似诈骗\"| K[\"写：诈骗疑似标记
提醒：组长/负责人复核
转风险链路（§6）\"]\n G -->|\"问题已解决\"| L[\"写：解决记录
状态：已解决\"]\n\n H --> F\n I --> F\n\n J --> M[\"提醒/再联系/等待提交\"]\n M --> N[\"用户提交评价或反馈
状态：已提交评价/已提交反馈\"]\n\n K --> P[\"组长/负责人复核\"]\n P --> Q{\"复核结论\"}\n Q -->|确认诈骗| R[\"转风险链路 → 同步黑名单\"]\n Q -->|退回继续处理| F\n\n L --> S[\"写：关闭工单
状态：已关闭\"]\n```\n\n#### 13.2 三套并行状态\n\n| 状态体系 | 典型状态 | 说明 |\n| --- | --- | --- |\n| **工单状态** | 待分配 → 已分配 → 处理中 → 等待用户/等待内部 → 已解决 / 疑似诈骗 → 已关闭 | 工单生命周期 |\n| **答应配合状态** | 已答应配合 → 待分配负责人 → 待提醒 → 等待提交 → 已提交评价/已提交反馈 → 超时 → 需再次联系 → 已关闭 | 防止承诺用户流失 |\n| **风险状态** | 无异常 → 弱关联高风险 → 强关联高风险 → 疑似诈骗 → 已确认诈骗 → 已同步黑名单 | 风险独立跟踪 |\n\n---\n\n### 14. 客服管理支撑流程\n\n#### 14.1 流程图\n\n```mermaid\nflowchart LR\n A[\"排班设置\"] --> B[\"在线客服池\"]\n C[\"出勤记录\"] --> B\n B --> D[\"工单自动分配
查：在线状态/排班/当前负载/最大工单数\"]\n D --> E[\"回复效率统计\"]\n D --> F[\"转化统计\"]\n F --> G[\"目标完成统计\"]\n E --> H[\"主管看板\"]\n F --> H\n G --> H\n```\n\n#### 14.2 管理指标\n\n| 模块 | 指标 |\n| --- | --- |\n| **出勤** | 应出勤、实际出勤、出勤率、迟到、早退、请假、缺勤 |\n| **回复效率** | 回复用户数、处理工单数、发送消息数、首次回复时长（平均/中位数/最大/最小） |\n| **转化** | RSO回评登记订单数、RDO测评登记订单数、获取评价数、评价完成率 |\n| **目标** | 月目标、当前完成、完成率、历史趋势 |\n\n---\n\n### 15. 评价完成流程\n\n#### 15.1 流程图\n\n```mermaid\nflowchart TB\n A[\"用户提交评价\"] --> B[\"写：记录真实提交事实
状态：已提交待核验\"]\n B --> C[\"写：更新真实人累计评价额度（+1）
提醒：接近12时预警\"]\n\n C --> D{\"查：Amazon是否展示 / 是否可核验\"}\n D -->|\"展示或可核验\"| E[\"写：计入计划完成
状态：已确认展示\"]\n D -->|\"未展示 / 暂不可核验\"| F[\"写：保留已提交事实
状态：未展示待观察\"]\n\n E --> G[\"写：更新ASIN健康与计划完成度\"]\n F --> H[\"进入异常观察队列
提醒：定期复查\"]\n\n G --> I[\"结果回流：更新经营层数据\"]\n```\n\n#### 15.2 必须拆开的两个事实\n\n| 事实 | 是否计入累计12额度 | 是否计入计划完成 | 计数时点 |\n| --- | --- | --- | --- |\n| 用户真实提交评价 | **是** | 还不一定 | 提交时立即计数 |\n| Amazon 展示确认 | 已在上一步计过 | **是** | 展示确认时 |\n\n---\n\n### 16. 渠道六：KOC/KOL 协作专属流程（免评核心通道）\n\n#### 16.1 流程图\n\n```mermaid\nflowchart TB\n START[\"入口：免评计划 / 推新计划已批准\"] --> PLAN[\"查：计划参数
写：拆解KOC/KOL执行方案\"]\n\n PLAN --> STEP1[\"匹配合作对象\"]\n STEP1 --> S1A[\"查：按国家/平台/粉丝量/历史效果筛选\"]\n STEP1 --> S1B[\"查：按产品类目匹配KOC/KOL专长\"]\n STEP1 --> S1C[\"查：合作对象风险（历史纠纷/违约）
提醒：有风险记录时提示\"]\n\n S1A & S1B & S1C --> STEP2[\"写：分配Code/素材/内容Brief\"]\n STEP2 --> STEP3[\"KOC/KOL内容发布\"]\n\n STEP3 --> TRACK[\"跟踪执行结果\"]\n TRACK --> T1[\"查：内容发布链接\"]\n TRACK --> T2[\"查：点击/跳转数据\"]\n TRACK --> T3[\"查：Code使用量\"]\n TRACK --> T4[\"查：带货订单\"]\n TRACK --> T5[\"查：转化销量\"]\n TRACK --> T6[\"查：Listing权重变化\"]\n\n T1 & T2 & T3 & T4 & T5 & T6 --> SYNC[\"从JOYCOLLAB同步数据至USER
写：同步记录
提醒：同步失败时告警\"]\n\n SYNC --> EVAL{\"执行评估\"}\n EVAL -->|\"达标\"| DONE[\"写：结果回流
更新ASIN健康/计划完成度
状态：已完成\"]\n EVAL -->|\"未达标\"| ADJUST[\"调整策略
写：调整记录
更换KOC/调整素材/追加Code\"]\n\n SYNC --> FINANCE[\"财务侧
查：提成计算/返点核算/提款记录
提醒：财务数据独立权限\"]\n```\n\n#### 16.2 KOC/KOL 与评价型渠道的本质差异\n\n| 维度 | 评价型（IM/EDM/APP/TEL） | KOC/KOL |\n| --- | --- | --- |\n| 执行主体 | 系统 + 客服 | 外部KOC/KOL + 运营协同 |\n| 终点 | 用户提交评价 | 内容发布/Code使用/带货销量/权重 |\n| 用户关系 | 平台 ↔ 买家 | 品牌 ↔ 达人 ↔ 达人粉丝 |\n| 数据源 | USER系统内部 | JOYCOLLAB同步 |\n| 财务 | 返款（固定金额） | 提成+返点（按效果） |\n| 风险关注 | 诈骗/双重退款 | 合作纠纷/违约/虚假流量 |\n\n#### 16.3 IM/EDM/APP 在免评中的协同角色\n\n| 协同动作 | 渠道 | 说明 |\n| --- | --- | --- |\n| KOC内容二次分发 | IM/APP | 将KOC发布的优质内容推送给站内用户 |\n| 免评Code触达 | IM/EDM | 将免评Code分发给符合条件的站内用户 |\n| 活动引流 | APP Push | 推送活动通知引导用户进入KOC内容页 |\n| 结果通知 | IM/APP | 通知用户Code到账、订单确认 |\n\n#### 16.4 免评核心结果组\n\n| 结果组 | 跟踪内容 |\n| --- | --- |\n| 内容 | 发布状态、链接、发布时间、互动数据 |\n| 引流 | 点击量、跳转量、Code使用量 |\n| 成交 | 订单数、转化量、销量 |\n| 经营 | 权重变化、ASIN健康变化、品牌搜索变化 |\n\n---\n\n### 17. 店铺紧急催评流程（IM渠道专属子流程）\n\n```mermaid\nflowchart TB\n TRIGGER[\"触发条件
查：店铺当日掉评/差评/需紧急拿好评稳评分
状态：紧急触发\"] --> CALC[\"计算推送量
目标好评数 ÷ 2% = 需触达用户数
写：推送方案\"]\n\n CALC --> EXEC[\"执行\"]\n EXEC --> E1[\"查：筛选可触达用户
写：推送紧急催评消息\"]\n EXEC --> E2[\"查：优先触达高完成率用户\"]\n EXEC --> E3[\"查：持续跟踪回评提交状态\"]\n\n E1 & E2 & E3 --> RESULT{\"结果\"}\n RESULT -->|\"已提交好评\"| R1[\"写：更新已回评/测评完成
状态：已完成\"]\n RESULT -->|\"未提交\"| R2[\"写：保留在待催评池
状态：待催评\"]\n RESULT -->|\"异常\"| R3[\"转人工：推送客服跟进
状态：转客服\"]\n\n style TRIGGER fill:#fce4ec,stroke:#c62828\n```\n\n---\n\n## 第三部分：渠道交叉与协同规则\n\n### 18. 渠道优先级路由\n\n```mermaid\nflowchart LR\n USER_IN[\"同一个用户\"] --> D1{\"查：用户状态\"}\n D1 -->|\"APP注册 + 活跃 + 已绑定\"| IM[\"IM 优先\"]\n D1 -->|\"APP注册 + 低活跃\"| APP_PUSH[\"APP Push优先 + IM补充\"]\n D1 -->|\"未注册APP\"| EDM[\"EDM优先 → 引导注册后转IM\"]\n D1 -->|\"高价值 + 多次无响应\"| TEL[\"TEL人工\"]\n D1 -->|\"长期测评人（C类）\"| IM_FREE[\"IM免评卡片 + KOC/KOL协同\"]\n\n style IM fill:#e3f2fd\n style EDM fill:#fff3e0\n style TEL fill:#fce4ec\n```\n\n### 19. 渠道间去重规则\n\n| 规则 | 说明 |\n| --- | --- |\n| 同一计划同一用户 | 不重复通过多渠道路由，优先走最高优先级渠道 |\n| 用户已在客服工单中 | 暂停自动触达，等待工单关闭后再判断 |\n| 用户已提交评价（待核验） | 所有渠道暂停催评，等待核验结果 |\n| 用户已退订某渠道 | 该渠道永久排除，不影响其他渠道 |\n| 用户命中强关联风险 | **所有渠道暂停自动触达**，进入人工复核 |\n| 用户命中弱关联风险 | 降频 + 提示后继续，但需人工关注 |\n\n### 20. 用户状态 × 渠道可用性矩阵\n\n| 用户状态 | IM | EDM | APP Push | TEL | KOC/KOL |\n| --- | --- | --- | --- | --- | --- |\n| APP活跃 + 已绑定 | **首选** | 不送 | 补充 | - | - |\n| APP活跃 + 未绑定 | 引导绑定 | - | 活动通知 | - | - |\n| APP低活跃 | 降频 | 补充 | **召回** | - | - |\n| 未注册APP | - | **首选** | - | 高价值时 | - |\n| 已答应配合 | 提醒 | - | 到期提醒 | **超时拨打** | - |\n| 长期测评人 (C) | **仅免评** | - | - | - | 可协同 |\n| 黑名单/强关联 | **全暂停** | **全暂停** | **全暂停** | **需复核** | **暂停** |\n| 弱关联风险 | 降频+提示 | 降频+提示 | 降频+提示 | 提示后执行 | 提示 |\n| 累计接近12 | 预警+人工 | 预警+人工 | 预警+人工 | 可正常服务；涉及普通测评邀请时需人工复核 | - |\n| 累计已满12 | 仅免评 | 仅免评 | 仅免评 | 可正常服务；不得绕过普通测评限制 | 可协同 |\n\n---\n\n## 第四部分：第三步数据对象建议\n\n### 21. 第三步建议优先产出的数据对象\n\n| 优先级 | 对象 | 来源能力/渠道 |\n| --- | --- | --- |\n| **P0** | `person_profiles`（真实人） | §2 真实人识别 |\n| **P0** | `person_identity_links`（身份关联） | §2 真实人识别 |\n| **P0** | `contact_context_snapshots`（用户上下文快照） | §2 用户上下文卡 |\n| **P0** | `person_quota_ledgers`（额度台账） | §4 额度台账 |\n| **P0** | `quota_reservations`（额度预占） | §4 额度台账 |\n| **P0** | `risk_signals`（风险信号） | §6 风险判断 |\n| **P0** | `risk_cases`（风险事件） | §6 风险判断 |\n| **P0** | `blacklist_entities`（黑名单实体） | §6 风险判断 |\n| **P0** | `audience_snapshots`（人群快照） | §3 人群生成 |\n| **P0** | `audience_exclusions`（人群排除记录） | §3 人群生成 |\n| **P0** | `channel_route_decisions`（渠道路由决策） | §18 渠道优先级 |\n| **P0** | `channel_dedup_records`（渠道去重记录） | §19 渠道间去重 |\n| **P1** | `im_interaction_records`（IM交互记录） | §9 IM |\n| **P1** | `im_flow_tags`（IM流程标签） | §9 IM |\n| **P1** | `edm_message_events`（EDM事件） | §10 EDM |\n| **P1** | `edm_user_behavior_profiles`（EDM用户行为画像） | §10 EDM |\n| **P1** | `app_touch_events`（APP触达事件） | §11 APP |\n| **P1** | `tel_call_records`（TEL通话记录） | §12 TEL |\n| **P1** | `support_tickets`（客服工单） | §13 客服 |\n| **P1** | `support_followups`（答应配合跟进） | §13 客服 |\n| **P1** | `support_assignment_logs`（工单分配日志） | §13 客服 |\n| **P1** | `review_submission_records`（评价提交记录） | §15 评价完成 |\n| **P1** | `review_display_checks`（评价展示核验） | §15 评价完成 |\n| **P1** | `exemption_plan_tasks`（免评计划任务） | §16 KOC/KOL |\n| **P1** | `creator_content_records`（KOC内容记录） | §16 KOC/KOL |\n| **P1** | `amazon_refund_records`（Amazon退款记录） | §6 双重退款 |\n| **P1** | `oa_refund_records`（OA返款记录） | §6 双重退款 |\n| **P1** | `refund_match_results`（退款比对结果） | §6 双重退款 |\n| **P2** | `attendance_records`（出勤记录） | §14 客服管理 |\n| **P2** | `shift_schedules`（排班表） | §14 客服管理 |\n| **P2** | `support_goal_records`（客服目标） | §14 客服管理 |\n| **P2** | `support_performance_snapshots`（绩效快照） | §14 客服管理 |\n| **P2** | `interaction_audit_logs`（互动审计日志） | §8 审计 |\n| **P2** | `manual_review_tasks`（人工复核任务） | §5/§6 复检与风险 |\n\n---\n\n### 22. 与基线 v1.2 的关系\n\n本文件是基线 v1.2 的下游细化产物：\n\n| 基线 v1.2 章节 | 本文件对应 |\n| --- | --- |\n| §6.1 主动触达支线 | §9 IM、§10 EDM、§11 APP Push |\n| §6.2 免评执行支线 | §16 KOC/KOL + §16.3 协同角色 |\n| §6.3 被动售后与TEL支线 | §12 TEL |\n| §6.4 风险/诈骗拦截支线 | §6 风险判断与黑名单 |\n| §6.5 客服工单与客服管理支线 | §13 客服工单、§14 客服管理 |\n| §7 真实人识别、用户上下文与额度规则 | §2 真实人识别、§4 额度台账 |\n| §8 渠道专属补充事实 | §9-§16 各渠道专属流程 |\n| §11 第二步新入口 | 本文件整体 |\n\n---\n\n### 23. 本版结论\n\nv2.2 吸收了前序文档中的以下优势：\n\n1. **额度体系**（测评4/免评4/累计12）作为独立共用能力，含台账/预占/预警/拦截\n2. **画像拆解**为 7 组字段 × 3 类用途\n3. **节点规则表**统一用 查/写/状态/提醒/拦截/转人工 格式\n4. **EDM 专属行为指标**（3/5次0打开、点击未回复时长、单月收信次数）\n5. **客服管理支撑流**（排班/出勤/绩效/目标）\n6. **评价完成流程**中拆开\"提交即计12\"vs\"展示才计完成\"\n7. **P0/P1/P2 数据对象**优先级\n\n同时保留了我版的核心优势：\n\n1. **IM A/B/C 三层用户完整流转**（提交核验、测评流程、标签汇总、推送/流转动作表）\n2. **渠道交叉与协同规则**（优先级路由、去重规则、用户状态 × 渠道可用性矩阵）\n3. **KOC/KOL JOYCOLLAB 同步链路**及免评协同角色表\n4. **TEL 拨打前准备五步 + 重试策略**\n5. **店铺紧急催评**独立子流程\n6. **三套并行客服状态**（工单/答应配合/风险）\n\n并完成以下收口：\n\n1. 将 IM 里残留的 `Amazon 账号 < / > 12 review` 全部改为 `真实人累计真实提交评价` 口径\n2. 明确 TEL 可继续服务，但不能绕开普通测评额度限制\n3. 补齐渠道路由、渠道去重、IM 流程标签和 EDM 行为画像对应的数据对象\n", + "wikilinks": [], + "category": "layer-requirements" + } + }, + { + "id": "doc:05_需求文档/20260517_USER评价业务闭环_第三步_数据流与中间对象设计_v3", + "type": "document", + "name": "USER 评价业务闭环 — 第三步：数据流与中间对象设计 v3", + "filePath": "05_需求文档/20260517_USER评价业务闭环_第三步_数据流与中间对象设计_v3.md", + "summary": "USER 评价业务闭环 — 第三步：数据流与中间对象设计 v3 文件信息 文件名称： 20260517 USER评价业务闭环 第三步 数据流与中间对象设计 v3.md 项目路径： C:\\XCODE\\USER 当前版本： v3 最近更新： 2026 05 17 上游文档： 工作基线 v1.2 20260517 USER评价业务闭环主流程与后续工作基线 v1.2", + "tags": [ + "05_需求文档", + "需求文档" + ], + "complexity": "complex", + "knowledgeMeta": { + "content": "# USER 评价业务闭环 — 第三步：数据流与中间对象设计 v3\n\n## 文件信息\n\n- 文件名称：`20260517_USER评价业务闭环_第三步_数据流与中间对象设计_v3.md`\n- 项目路径：`C:\\XCODE\\USER`\n- 当前版本：`v3`\n- 最近更新：`2026-05-17`\n- 上游文档：\n - [工作基线 v1.2](20260517_USER评价业务闭环主流程与后续工作基线_v1.2.md) — 业务规则与额度口径\n - [共用能力图与渠道专属流程 v2.2](20260517_USER评价业务闭环_共用能力图与渠道专属流程_v2.2.md) — 每个节点的 查/写/状态/提醒/拦截\n- 前置版本：\n - `数据流与中间对象需求_v1`（Codex，六层架构骨架）\n - `数据流与中间对象设计_v1.1`（Codex，字段字典最全版）\n - `第三步_数据流与中间表设计_v1`（字段级展开 + 流转时序）\n - `第三步_数据流与中间表设计_v2`（吸收 Codex 优点的合并版）\n- 合并策略：以 Codex v1.1 为主骨架（保留其完整字段字典和免评对象），补入 v2 的流转时序表、写入顺序图和快照策略。\n- 文件目的：作为第三步最终主稿，后续数据库物理设计、接口设计和页面点击读写设计均以此为准。\n\n---\n\n## 1. 第三步的目标\n\n第三步不再回答\"流程怎么走\"，而是回答：\n\n1. 现有系统里已经有哪些数据可以复用。\n2. 为什么仅靠现有 `users / amazon_orders / review_plans / push_tasks / support_tickets / fraud_events` 不够。\n3. 必须新增哪些中间对象。\n4. 哪些是正式事务表，哪些只是快照，哪些可以先做成视图。\n5. 从需求形成到结果回流，数据怎样一层一层往下走。\n\n---\n\n## 2. 本步先给出的结论\n\n### 2.1 不能再只围绕单一账号建模\n\n后续所有关键判断都应围绕 **真实人**，而不是只看 JOYHUB ID / 邮箱 / 电话 / Amazon 账号 / 单次订单。JOYHUB 用户只是身份线索之一，真实人才是额度、历史、风险、跨渠道去重和客服上下文的主对象。\n\n### 2.2 现有表能承载业务记录，但承载不了跨流程判断\n\n既有表更接近\"某一模块自己的账\"，但前两步已确认的新需求需要额外的中间层：真实人跨账号归并、每次互动重判、人群入选/排除解释、额度预占与跨渠道去重、客服上下文、评价提交与展示拆分、退款比对。\n\n### 2.3 第三步最重要的是把对象分层\n\n本文件把数据对象分为六层：\n\n```\n源数据层 → 主实体层 → 桥接层 → 事件层 → 快照与决策层 → 结果回流层\n```\n\n---\n\n## 3. 数据设计原则\n\n| 原则 | 说明 |\n| --- | --- |\n| 先识别真实人，再做额度与风险 | 否则 4/4/12 规则都会被多账号绕开 |\n| 事件与快照分离 | 事件是原始事实，快照是某个时点的判断结果 |\n| 当前态与历史态分离 | 当前视图可重算，历史决策必须留痕 |\n| 计划、渠道、客服、风险状态分离 | 不能压成一个字段 |\n| 用户提交与平台展示分离 | 真实提交计额度，Amazon 展示计计划完成 |\n| 能解释\"为什么\" | 入选、排除、拦截、转人工都要能追溯 |\n| 先复用现有对象，再补最小中间层 | 不为了建模漂亮重造全部旧表 |\n| 对敏感数据分层处理 | 原值、标准化值、哈希/指纹、脱敏展示值应区分 |\n\n---\n\n# 第一部分：现有数据源分析\n\n## 4. 现有数据源盘点\n\n| 数据源 | 当前可用内容 | 主要缺口 |\n| --- | --- | --- |\n| 现有 ERP 用户管理 | 用户 ID、用户名、注册时间、最近活跃、国家、性别、邮箱、绑定产品数、标签 | 仍是账号视角，不是真实人视角 |\n| APP / 用户数据库 | JOYHUB ID、邮箱、设备号、设备型号/类型、系统版本、APP版本、绑定玩具、活跃与点击行为 | 需要设备变更轨迹和与订单/客服联动 |\n| Amazon 订单 | 订单号、ASIN、站点、购买时间、订单状态、Profile ID、收件人姓名、收件地址等 | 需要标准化姓名/地址和收件人指纹 |\n| Amazon 评价/Listing | ASIN、评分、评价数、差评数、评价缺口、展示结果 | 用户真实提交与平台展示要拆成两条事实 |\n| 推送系统 | Push 计划、素材、任务、打开、点击、回复、投诉、退订 | IM/EDM/APP 语义不同，不能只用一套粗糙 push 结果 |\n| 客服/TEL | 工单、通话、售后、答应配合、问题处理 | 需要和上下文卡、风险复检、跟进状态联动 |\n| 黑名单/诈骗资料 | 黑名单、诈骗事件、双重退款、强弱关联 | 需要把风险信号与确认案件拆开 |\n| OA 返款/Amazon 退款 | 内部返款与 Amazon 退款 | 缺统一比对对象 |\n| JOYCOLLAB | KOC/KOL、内容、Code、点击、订单、转化、佣金 | 需要和 USER 计划/ASIN 结果打通 |\n\n### 4.1 Amazon 订单字段明细（结合表头.xlsx）\n\n| 字段 | 主要用途 | 涉密 |\n| --- | --- | --- |\n| 订单号 | 订单核验、真实人关联、退款比对 | 是 |\n| 订单状态 | 判断是否撤销、退款、退货、换货 | - |\n| 买家姓名 / 买家邮箱 | 身份关联 | 是 |\n| 收件人 / 电话 | 真实人归并、风险判断 | 是 |\n| 地址 / 城市 / 州 / 邮编 | 收件人归并、同址异名识别 | 是 |\n| ASIN / MSKU / SKU / 品名 / 标题 | 产品匹配、计划归属 | - |\n| 订购日期 / 发货时间 / 结算时间 | 时序判断 | - |\n| 数量 / 单价 / 订单总金额 / 销售额 | 交易画像 | 是 |\n| 是否退款 / 退款总金额 | 双重退款检测 | 是 |\n| 请求评论状态 | 评价缺口判断 | - |\n| 店铺 / 国家 / 销售渠道 | 站点匹配 | - |\n| Order Item ID | 订单行级关联 | - |\n\n### 4.2 订单侧必须补的派生字段\n\n| 字段 | 说明 |\n| --- | --- |\n| `recipient_name_normalized` | 标准化后的收件人姓名 |\n| `recipient_address_normalized` | 标准化后的地址 |\n| `recipient_fingerprint` | 由标准化姓名+地址生成的稳定指纹 |\n| `address_fingerprint` | 仅地址指纹，用于识别同址异名 |\n\n---\n\n## 5. 全局数据流\n\n```mermaid\nflowchart LR\n subgraph S[\"源数据层\"]\n S1[\"现有ERP用户/标签/身份\"]\n S2[\"APP/设备/行为\"]\n S3[\"Amazon订单/评价/Listing\"]\n S4[\"IM/EDM/APP Push/TEL\"]\n S5[\"客服/工单/售后\"]\n S6[\"黑名单/OA返款/Amazon退款\"]\n S7[\"JOYCOLLAB\"]\n end\n\n subgraph M[\"主实体与桥接层\"]\n M1[\"真实人 person_profiles\"]\n M2[\"身份关联 person_identity_links\"]\n M3[\"订单/ASIN/计划/工单\"]\n M4[\"订单关联/路由/去重\"]\n end\n\n subgraph D[\"快照与决策层\"]\n D1[\"画像快照 person_feature_snapshots\"]\n D2[\"上下文卡 contact_context_snapshots\"]\n D3[\"额度台账/预占\"]\n D4[\"风险信号/风险案件\"]\n D5[\"人群快照/排除快照\"]\n D6[\"互动复检/路由决策\"]\n end\n\n subgraph E[\"事件层\"]\n E1[\"渠道事件\"]\n E2[\"客服/TEL事件\"]\n E3[\"退款事件\"]\n E4[\"评价提交事件\"]\n E5[\"免评执行事件\"]\n end\n\n subgraph R[\"结果回流层\"]\n R1[\"评价展示核验\"]\n R2[\"退款比对结果\"]\n R3[\"免评结果\"]\n R4[\"ASIN健康/计划完成\"]\n R5[\"绩效/审计/下一轮需求\"]\n end\n\n S1 & S2 & S3 --> M1\n S1 & S2 & S3 --> M2\n M1 & M2 & M3 --> D1\n M1 & M2 & M3 --> D2\n D1 --> D5\n D3 & D4 --> D5\n D5 --> D6\n D6 --> E1\n S4 --> E1\n S5 --> E2\n S6 --> E3\n E1 & E2 --> E4\n S7 --> E5\n E3 --> R2\n E4 --> R1\n E5 --> R3\n R1 & R2 & R3 --> R4\n R4 --> R5\n R5 --> M3\n```\n\n---\n\n# 第二部分：数据对象分层总表\n\n## 6. 对象分层总表\n\n| 分层 | 对象 | 说明 |\n| --- | --- | --- |\n| 源数据 | `users`、`devices`、`amazon_orders`、`asin_listings`、`push_tasks`、`support_tickets`、`fraud_events`、JOYCOLLAB 数据 | 现有或外部事实来源 |\n| 主实体 | `person_profiles`、`request_tickets`、`review_plans`、`exemption_plans`、`risk_cases`、`blacklist_entities` | 核心业务主体 |\n| 桥接 | `person_identity_links`、`user_order_links`、`plan_task_links`、`channel_route_decisions`、`channel_dedup_records` | 跨主体关系 |\n| 事件 | `im_interaction_records`、`im_flow_tags`、`edm_message_events`、`app_touch_events`、`tel_call_records`、`review_submission_records`、`amazon_refund_records`、`oa_refund_records`、`support_assignment_logs` | 不可丢失的事实 |\n| 快照/决策 | `person_feature_snapshots`、`contact_context_snapshots`、`person_quota_ledgers`、`quota_reservations`、`audience_snapshots`、`audience_exclusions`、`interaction_recheck_records`、`edm_user_behavior_profiles`、`channel_route_decisions`、`channel_dedup_records` | 为某次决策保留当时依据 |\n| 结果/回流 | `review_display_checks`、`refund_match_results`、`exemption_result_snapshots`、`listing_health_snapshots`、`support_performance_snapshots` | 结果与复盘 |\n| 治理 | `interaction_audit_logs`、`manual_review_tasks`、`export_logs`、`audit_logs` | 审计、复核、导出 |\n\n---\n\n## 7. 现有对象如何处理\n\n### 7.1 可以直接复用\n\n| 现有对象 | 处理 |\n| --- | --- |\n| `request_tickets` | 保留，继续作为需求入口 |\n| `amazon_orders` | 保留，补标准化姓名/地址与收件人指纹 |\n| `asin_listings` | 保留，继续作为 ASIN/Listing 主档 |\n| `support_tickets` | 保留，拆出跟进、分派和风险状态辅助表 |\n| `fraud_events` | 保留，上游增加 `risk_signals`，下游衔接 `risk_cases/blacklist_entities` |\n| `audit_logs` | 保留 |\n\n### 7.2 需要扩展\n\n| 现有对象 | 需要补的能力 |\n| --- | --- |\n| `users` | 不再承担真实人主档，只保留 JOYHUB 账号层信息 |\n| `devices` | 补设备型号、系统版本、APP版本、首次/最近出现、设备变化 |\n| `review_plans` | 增加计划族或与 `exemption_plans` 分离 |\n| `push_tasks` | 被更细的渠道事件表补充 |\n| `support_tickets` | 增加与上下文卡、答应配合、风险复核、TEL 记录的关联 |\n\n### 7.3 必须新增\n\n| 对象 | 原因 |\n| --- | --- |\n| `person_profiles` | 真实人主档 |\n| `person_identity_links` | 多线索归并 |\n| `person_feature_snapshots` | 画像解释 |\n| `contact_context_snapshots` | 客服一屏上下文 |\n| `person_quota_ledgers` | 4/4/12 统一额度 |\n| `quota_reservations` | 并发占用与预警 |\n| `audience_snapshots` | 人群生成留痕 |\n| `audience_exclusions` | 排除原因留痕 |\n| `channel_route_decisions` | 渠道路由解释 |\n| `channel_dedup_records` | 跨渠道去重 |\n| `interaction_recheck_records` | 每次有效互动重新判断留痕 |\n| `refund_match_results` | 双重退款识别 |\n| `review_display_checks` | 评价展示拆分 |\n\n---\n\n# 第三部分：P0/P1/P2 优先级\n\n## 8. P0：没有它们，主流程就不可靠\n\n| 对象 | 类型 | 关键用途 |\n| --- | --- | --- |\n| `person_profiles` | 主实体 | 真实人主档 |\n| `person_identity_links` | 桥接 | 账号、邮箱、电话、设备、Profile、收件人归并 |\n| `person_feature_snapshots` | 快照 | 画像依据 |\n| `contact_context_snapshots` | 快照 | 客服上下文卡 |\n| `person_quota_ledgers` | 台账 | 4/4/12 统一额度 |\n| `quota_reservations` | 台账 | 计划并发占用 |\n| `risk_signals` | 事件 | 风险原始信号 |\n| `risk_cases` | 主实体 | 风险案件 |\n| `blacklist_entities` | 主实体 | 确认拦截对象 |\n| `audience_snapshots` | 快照 | 某次人群生成结果 |\n| `audience_exclusions` | 快照 | 排除原因 |\n| `channel_route_decisions` | 决策 | 渠道路由 |\n| `channel_dedup_records` | 决策 | 跨渠道去重 |\n| `interaction_recheck_records` | 决策 | 每次有效互动重判 |\n\n## 9. P1：主流程可走，但没有它们会粗糙且难复盘\n\n| 对象 | 类型 | 关键用途 |\n| --- | --- | --- |\n| `im_interaction_records` | 事件 | IM 细节 |\n| `im_flow_tags` | 事件/派生 | IM 流程流转 |\n| `edm_message_events` | 事件 | EDM 打开/点击/回复/退订 |\n| `edm_user_behavior_profiles` | 快照 | EDM 画像 |\n| `app_touch_events` | 事件 | APP Push 触达 |\n| `tel_call_records` | 事件 | 电话全记录 |\n| `support_followups` | 事务 | 答应配合跟进 |\n| `support_assignment_logs` | 事件 | 分配与升级 |\n| `review_submission_records` | 事件 | 用户真实提交评价 |\n| `review_display_checks` | 结果 | Amazon 展示核验 |\n| `exemption_plans` | 主实体 | 免评计划 |\n| `exemption_plan_tasks` | 事务 | 免评任务 |\n| `creator_content_records` | 事件 | KOC/KOL 内容 |\n| `exemption_result_snapshots` | 结果 | 免评结果 |\n| `amazon_refund_records` | 事件 | Amazon 退款 |\n| `oa_refund_records` | 事件 | OA 返款 |\n| `refund_match_results` | 结果 | 双重退款比对 |\n\n## 10. P2：管理、效率与治理增强\n\n| 对象 | 类型 | 关键用途 |\n| --- | --- | --- |\n| `attendance_records` | 事务 | 出勤 |\n| `shift_schedules` | 事务 | 排班 |\n| `support_goal_records` | 事务 | 目标 |\n| `support_performance_snapshots` | 快照 | 绩效 |\n| `manual_review_tasks` | 事务 | 人工复核 |\n| `interaction_audit_logs` | 审计 | 高敏动作审计 |\n\n---\n\n# 第四部分：完整字段字典\n\n## 11. 真实人与身份层\n\n### 11.1 `person_profiles`\n\n| 字段 | 类型 | 说明 |\n| --- | --- | --- |\n| `person_id` | PK | 真实人唯一标识 |\n| `created_at` | datetime | 首次识别时间 |\n| `updated_at` | datetime | 最近归并更新时间 |\n| `merge_confidence` | enum | 高/中/低 |\n| `status` | enum | 正常/观察中/已确认风险 |\n| `primary_country` | string | 当前主要国家 |\n| `primary_language` | string | 当前主要语言 |\n| `latest_active_at` | datetime | 最近活跃时间 |\n| `lifetime_review_submitted_count` | int | 累计真实提交评价数（跨账号合并） |\n| `current_risk_level` | enum | 当前风险等级 |\n\n### 11.2 `person_identity_links`\n\n| 字段 | 类型 | 说明 |\n| --- | --- | --- |\n| `link_id` | PK | 关联记录 ID |\n| `person_id` | FK → person_profiles | 所属真实人 |\n| `identity_type` | enum | JOYHUB_ID / EMAIL / PHONE / DEVICE / AMAZON_PROFILE / NAME_ADDRESS / PAYMENT / ORDER |\n| `identity_value_hash` | string | 匹配索引 |\n| `identity_value_encrypted` | string | 仅在必要时保存的加密原值 |\n| `link_strength` | enum | 强/弱 |\n| `confidence_score` | decimal | 归并置信度 |\n| `evidence_summary` | text | 命中依据摘要 |\n| `first_seen_at` | datetime | 首次发现时间 |\n| `last_seen_at` | datetime | 最近确认时间 |\n| `source_type` | enum | AMAZON_ORDER / JOYHUB / MANUAL / TEL / EMAIL / CS_TICKET |\n| `is_active` | bool | 是否仍有效 |\n\n### 11.3 归并口径\n\n| 场景 | 数据处理 |\n| --- | --- |\n| 标准化后姓名+地址完全一致 | 直接归并到同一真实人，link_strength=STRONG |\n| 地址一致但姓名不同 | 记录弱关联，不直接合并 |\n| 多个线索交叉命中 | 形成候选归并，记录证据和置信度 |\n| 只有单个弱线索 | 不做直接归并，只写风险信号 |\n\n### 11.4 `contact_context_snapshots`\n\n| 字段组 | 字段 | 来源 |\n| --- | --- | --- |\n| 快照元数据 | `snapshot_id`、`person_id`、`snapshot_at`、`trigger_event` | 系统 |\n| 当前身份 | `joyhub_ids[]`、`emails[]`、`phones[]`、`devices[]`、`amazon_profile_ids[]` | 身份关联 |\n| 归并摘要 | `standardized_name_address`、`linked_person_count`、`merge_confidence` | 真实人/身份关联 |\n| 历史交易 | `total_orders`、`last_order_at`、`total_refunds`、`total_oa_refunds`、`target_asin_purchases[]` | 订单/返款 |\n| 历史服务 | `total_tickets`、`last_ticket_at`、`total_calls`、`last_call_at`、`open_promises[]` | 工单/电话 |\n| 历史风险 | `blacklist_hits`、`strong_associations`、`weak_associations`、`fraud_cases`、`double_refund_flags` | 风险层 |\n| 当前设备 | `device_count`、`latest_device_model`、`app_version`、`recent_device_change` | APP/设备 |\n| 触达历史 | `im_recent[]`、`edm_recent[]`、`app_recent[]`、`tel_recent[]` | 渠道事件 |\n\n---\n\n## 12. 画像、额度与人群层\n\n### 12.1 `person_feature_snapshots`\n\n| 字段组 | 代表字段 |\n| --- | --- |\n| 快照元数据 | `feature_snapshot_id`、`person_id`、`snapshot_at`、`feature_version` |\n| 基础画像 | `country`、`marketplace`、`language`、`gender`、`age_band`、`registered_at` |\n| 产品关系 | `bound_toy_count`、`bound_categories[]`、`target_product_relation` |\n| 交易画像 | `total_orders`、`last_order_at`、`purchase_frequency`、`bought_target_asin` |\n| 行为画像 | `activity_score`、`open_rate`、`click_rate`、`reply_rate`、`review_rate`、`cooperation_rate` |\n| 触达画像 | `im_reachable`、`edm_reachable`、`app_reachable`、`tel_reachable`、`last_touch_at` |\n| 风险画像 | `risk_level`、`blacklist_hit`、`strong_link_count`、`weak_link_count`、`refund_anomaly_flag` |\n| 计划画像 | `joined_plan_types[]`、`last_plan_result`、`lifetime_review_submitted_count` |\n\n### 12.2 三类画像用途\n\n| 用途 | 说明 | 示例 |\n| --- | --- | --- |\n| **硬过滤** | 决定能不能进入人群池 | 黑名单、退订、强关联、超额、站点不符 |\n| **匹配条件** | 决定适不适合当前计划 | 国家、性别、年龄段、绑定玩具、是否买过目标 ASIN |\n| **排序权重** | 决定优先触达谁 | 活跃度、历史配合率、最近互动、打开/点击行为 |\n\n### 12.3 `person_quota_ledgers`\n\n> **HANDOFF：用户运营核心控制规则。** \"4+4+12\"全部按真实人统计，跨所有关联账号合并计算。一个人不管有几个 JOYHUB ID、几个 Amazon 账号——只要归并到同一个真实人，都受同一套额度控制。\n>\n> 示例：真实人关联 3 个 JOYHUB ID（A/B/C），A 上提交 5 个 + B 上提交 4 个 + C 上提交 3 个 = 累计 12，**全部账号停回评/测评，后续仅免评。**\n\n| 字段 | 类型 | 说明 |\n| --- | --- | --- |\n| `ledger_id` | PK | 台账记录 ID |\n| `person_id` | FK → person_profiles | 真实人 |\n| `period_key` | string | 自然月，如 `2026-05` |\n| `quota_type` | enum | MONTHLY_REVIEW / MONTHLY_EXEMPTION / LIFETIME_REVIEW |\n| `quota_limit` | int | 4 / 4 / 12 |\n| `used` | int | 已完成 |\n| `in_progress` | int | 进行中 |\n| `reserved` | int | 已预占 |\n| `available` | int | 剩余可用 = limit - used - in_progress - reserved |\n| `updated_at` | datetime | 最近更新 |\n\n### 12.4 `quota_reservations`\n\n| 字段 | 类型 | 说明 |\n| --- | --- | --- |\n| `reservation_id` | PK | 预占记录 |\n| `person_id` | FK | 真实人 |\n| `plan_id` | FK | 关联计划 |\n| `quota_type` | enum | 测评/免评 |\n| `reserved_count` | int | 预占数量 |\n| `reserved_at` | datetime | 预占时间 |\n| `expires_at` | datetime | 过期释放时间 |\n| `status` | enum | 已预占/已使用/已释放/已过期 |\n\n### 12.5 `audience_snapshots`\n\n| 字段 | 类型 | 说明 |\n| --- | --- | --- |\n| `snapshot_id` | PK | 人群快照 ID |\n| `plan_id` | FK | 计划 |\n| `batch_id` | string | 生成人群批次 |\n| `person_id` | FK | 真实人 |\n| `match_score` | decimal | 匹配得分 |\n| `match_reasons` | JSON | 命中画像条件 |\n| `quota_status` | enum | 充足/预警/超限 |\n| `risk_status` | enum | 正常/弱风险/强风险 |\n| `priority_rank` | int | 触达优先级 |\n| `feature_snapshot_id` | FK | 当时引用的画像快照 |\n| `snapshot_at` | datetime | 快照时间 |\n\n### 12.6 `audience_exclusions`\n\n| 字段 | 类型 | 说明 |\n| --- | --- | --- |\n| `exclusion_id` | PK | 排除记录 |\n| `plan_id` | FK | 计划 |\n| `batch_id` | string | 批次 |\n| `person_id` | FK | 真实人 |\n| `exclusion_reason` | enum | BLACKLIST / UNSUBSCRIBED / QUOTA_EXCEEDED / FREQ_EXCEEDED / OPEN_TICKET / WRONG_COUNTRY / STRONG_RISK |\n| `excluded_at` | datetime | 排除时间 |\n\n### 12.7 为什么一定需要这些中间表\n\n| 对象 | 如果没有会怎样 |\n| --- | --- |\n| `person_feature_snapshots` | 无法解释当时的画像依据 |\n| `audience_snapshots` | 无法复盘某次计划到底选中了谁 |\n| `audience_exclusions` | 无法解释为什么用户没被选中 |\n| `person_quota_ledgers` | 4/4/12 规则无法跨账号统一计算 |\n| `quota_reservations` | 多个计划并发时会重复占用同一人额度 |\n\n---\n\n## 13. 路由与互动复检层\n\n### 13.1 `channel_route_decisions`\n\n| 字段 | 类型 | 说明 |\n| --- | --- | --- |\n| `route_decision_id` | PK | 路由决策 ID |\n| `plan_id` | FK | 计划 |\n| `batch_id` | string | 人群批次 |\n| `person_id` | FK | 真实人 |\n| `candidate_channels` | JSON | 候选渠道 |\n| `selected_channel` | enum | 实际选中渠道 |\n| `excluded_channels` | JSON | 被排除渠道及原因 |\n| `decision_factors` | JSON | 活跃、绑定、可达性、工单、额度、风险 |\n| `decided_at` | datetime | 决策时间 |\n\n### 13.2 `channel_dedup_records`\n\n| 字段 | 类型 | 说明 |\n| --- | --- | --- |\n| `dedup_id` | PK | 去重记录 |\n| `person_id` | FK | 真实人 |\n| `plan_id` | FK | 计划 |\n| `selected_channel` | enum | 保留渠道 |\n| `suppressed_channels` | JSON | 被抑制渠道 |\n| `reason` | text | 去重原因 |\n| `created_at` | datetime | 去重时间 |\n\n### 13.3 `interaction_recheck_records`\n\n每次有效互动后，记录本次重新做过哪些检查、结果是什么、为何继续或拦截。这是\"每次互动重判\"的落地证据。\n\n| 字段 | 类型 | 说明 |\n| --- | --- | --- |\n| `recheck_id` | PK | 复检记录 |\n| `interaction_type` | enum | IM / EDM / APP / TEL / CS / REFUND |\n| `interaction_id` | string | 触发互动 |\n| `person_id` | FK | 真实人 |\n| `context_snapshot_id` | FK | 上下文快照 |\n| `quota_snapshot_ref` | string | 额度快照引用 |\n| `risk_case_id` | FK | 关联风险案件 |\n| `identity_result` | enum | 正常/新增关联/冲突 |\n| `history_result` | enum | 无变化/有更新 |\n| `quota_result` | enum | 充足/预警/超限 |\n| `risk_result` | enum | 正常/弱风险/强风险 |\n| `final_action` | enum | 继续/降级/转人工/暂停 |\n| `checked_at` | datetime | 复检时间 |\n\n---\n\n## 14. 风险层\n\n### 14.1 `risk_signals`\n\n| 字段 | 类型 | 说明 |\n| --- | --- | --- |\n| `signal_id` | PK | 风险信号 ID |\n| `person_id` | FK | 真实人 |\n| `signal_type` | enum | STRONG_HIT / WEAK_HIT / DOUBLE_REFUND / DEVICE_ANOMALY / ADDRESS_ANOMALY / BLACKLIST_HIT |\n| `hit_dimensions` | JSON | 命中维度 |\n| `source_event_id` | string | 触发事件 |\n| `created_at` | datetime | 产生时间 |\n| `resolved_at` | datetime | 解除时间 |\n| `resolution` | enum | 确认风险/误报/观察中 |\n\n### 14.2 `risk_cases`\n\n| 字段 | 类型 | 说明 |\n| --- | --- | --- |\n| `case_id` | PK | 风险案件 |\n| `person_id` | FK | 真实人 |\n| `source_type` | enum | CS_TICKET / TEL_CALL / PUSH_RESPONSE / REFUND / MANUAL |\n| `source_id` | string | 来源对象 |\n| `status` | enum | 待复核/复核中/确认诈骗/排除/已同步黑名单 |\n| `reviewer_id` | FK | 复核人 |\n| `reviewed_at` | datetime | 复核时间 |\n| `sync_status` | enum | 未同步/同步中/已同步/同步失败 |\n\n### 14.3 `blacklist_entities`\n\n| 字段 | 类型 | 说明 |\n| --- | --- | --- |\n| `blacklist_entity_id` | PK | 黑名单实体 |\n| `entity_type` | enum | 邮箱/电话/设备/Profile/收款信息/真实人 |\n| `entity_hash` | string | 匹配索引 |\n| `risk_level` | enum | 风险等级 |\n| `source_case_id` | FK | 来源案件 |\n| `synced_at` | datetime | 同步时间 |\n| `status` | enum | 生效/失效/待复核 |\n\n### 14.4 `manual_review_tasks`\n\n| 字段 | 类型 | 说明 |\n| --- | --- | --- |\n| `task_id` | PK | 人工复核任务 |\n| `person_id` | FK | 真实人 |\n| `source_type` | enum | 风险/额度/渠道/退款 |\n| `source_id` | string | 来源对象 |\n| `task_reason` | text | 复核原因 |\n| `status` | enum | 待处理/处理中/已完成/已关闭 |\n| `owner_id` | FK | 负责人 |\n| `created_at` | datetime | 创建时间 |\n\n---\n\n## 15. 渠道事件层\n\n### 15.1 `im_interaction_records`\n\n| 字段 | 类型 | 说明 |\n| --- | --- | --- |\n| `im_record_id` | PK | IM 记录 |\n| `person_id` | FK | 真实人 |\n| `joyhub_id` | FK | JOYHUB 账号 |\n| `plan_id` | FK | 关联计划 |\n| `action_type` | enum | PUSH_CARD / USER_SUBMIT / USER_REPLY / REMINDER / NOTIFICATION |\n| `card_type` | enum | REVIEW_CARD / EVALUATION_CARD / EXEMPTION_CARD / REMINDER_CARD |\n| `user_submitted_data` | JSON | 订单号/返款账号/截图链接（涉密加密存储） |\n| `order_validation_result` | enum | 通过/非测评单/非公司产品/格式错误/已撤销/已退款 |\n| `tag_changes` | JSON | 本次产生的标签变化 |\n| `created_at` | datetime | 事件时间 |\n\n### 15.2 `im_flow_tags`\n\n| 字段 | 类型 | 说明 |\n| --- | --- | --- |\n| `flow_tag_id` | PK | 流程标签记录 |\n| `person_id` | FK | 真实人 |\n| `tag_code` | string | 流程标签 |\n| `source_im_record_id` | FK | 来源 IM 事件 |\n| `effective_from` | datetime | 生效时间 |\n| `effective_to` | datetime | 失效时间 |\n\n### 15.3 `edm_message_events`\n\n| 字段 | 类型 | 说明 |\n| --- | --- | --- |\n| `edm_event_id` | PK | EDM 事件 |\n| `person_id` | FK | 真实人 |\n| `email_hash` | string | 邮箱索引 |\n| `campaign_id` | FK | 邮件任务 |\n| `event_type` | enum | SENT / DELIVERED / OPENED / CLICKED / REPLIED / BOUNCED / UNSUBSCRIBED / COMPLAINED |\n| `event_at` | datetime | 事件时间 |\n| `click_target` | string | 点击目标 |\n\n### 15.4 `edm_user_behavior_profiles`\n\n| 字段 | 类型 | 说明 |\n| --- | --- | --- |\n| `profile_id` | PK | EDM 行为画像 |\n| `person_id` | FK | 真实人 |\n| `latest_open_at` | datetime | 最近打开 |\n| `latest_reply_at` | datetime | 最近回复 |\n| `open_count_total` | int | 累计打开次数 |\n| `zero_open_last_3` | bool | 最近 3 次 0 打开 |\n| `zero_open_last_5` | bool | 最近 5 次 0 打开 |\n| `clicked_review_link_without_reply_hours` | int | 点击评论链接但未回复时长 |\n| `monthly_receive_count` | int | 当月收信次数 |\n| `mail_type_counts` | JSON | 各邮件类型发送次数 |\n| `mailbox_domain` | string | 邮箱后缀 |\n| `is_unsubscribed` | bool | 是否退订 |\n| `has_hard_bounce` | bool | 是否硬退信 |\n| `snapshot_at` | datetime | 快照时间 |\n\n### 15.5 `app_touch_events`\n\n| 字段 | 类型 | 说明 |\n| --- | --- | --- |\n| `app_event_id` | PK | APP 事件 |\n| `person_id` | FK | 真实人 |\n| `joyhub_id` | FK | JOYHUB 账号 |\n| `push_type` | enum | PUSH / IN_APP / BANNER / POPUP |\n| `event_type` | enum | SENT / DISPLAYED / CLICKED / DISMISSED / UNINSTALLED |\n| `landing_page` | string | 落地页 |\n| `event_at` | datetime | 事件时间 |\n\n### 15.6 `tel_call_records`\n\n| 字段 | 类型 | 说明 | 涉密 |\n| --- | --- | --- | --- |\n| `tel_record_id` | PK | 电话记录 | - |\n| `person_id` | FK | 真实人 | - |\n| `ticket_id` | FK | 关联工单 | - |\n| `call_direction` | enum | INBOUND/OUTBOUND | - |\n| `call_source` | enum | AMAZON_PAGE/MANUAL/PLAN_TASK/FOLLOWUP | - |\n| `phone_hash` | string | 电话索引 | 是 |\n| `call_at` | datetime | 通话时间 | - |\n| `duration_seconds` | int | 通话时长 | - |\n| `call_result` | enum | CONNECTED/NO_ANSWER/WRONG_NUMBER/DECLINED | - |\n| `has_after_sale_issue` | bool | 是否有售后 | - |\n| `issue_type` | enum | 问题类型 | - |\n| `issue_description` | text | 问题描述 | - |\n| `solution` | text | 处理方案 | - |\n| `is_resolved` | bool | 是否解决 | - |\n| `is_satisfied` | bool | 是否满意 | - |\n| `invited_review` | bool | 是否邀请回评/测评 | - |\n| `user_accepted` | bool | 是否接受 | - |\n| `agent_id` | FK | 客服 | - |\n\n---\n\n## 16. 客服层\n\n### 16.1 `support_tickets`\n\n| 字段 | 类型 | 说明 |\n| --- | --- | --- |\n| `ticket_id` | PK | 工单 |\n| `person_id` | FK | 真实人 |\n| `ticket_type` | enum | 差评跟进/测评跟进/回评跟进/紧急Listing/电话/售后/诈骗样品/KOL进度 |\n| `source` | enum | AMAZON_OP/BRAND_OP/SYSTEM_AUTO/PUSH_ESCALATION/USER_REPLY/TEL_INBOUND |\n| `source_id` | string | 来源对象 |\n| `ticket_status` | enum | 待分配/已分配/处理中/等待用户/等待内部/已解决/疑似诈骗/已关闭 |\n| `assigned_team` | FK | 客服组 |\n| `assigned_agent` | FK | 客服 |\n| `created_at` | datetime | 创建时间 |\n| `first_response_at` | datetime | 首次回复 |\n| `resolved_at` | datetime | 解决时间 |\n| `closed_at` | datetime | 关闭时间 |\n| `context_snapshot_id` | FK | 创建时上下文快照 |\n\n### 16.2 `support_followups`\n\n| 字段 | 类型 | 说明 |\n| --- | --- | --- |\n| `followup_id` | PK | 跟进 |\n| `ticket_id` | FK | 工单 |\n| `person_id` | FK | 真实人 |\n| `followup_status` | enum | 已答应配合/待分配/待提醒/等待提交/已提交评价/已提交反馈/超时/需再次联系/已关闭 |\n| `promised_at` | datetime | 承诺时间 |\n| `reminder_count` | int | 已提醒次数 |\n| `last_reminder_at` | datetime | 最近提醒 |\n| `deadline_at` | datetime | 截止时间 |\n| `submitted_at` | datetime | 实际提交 |\n| `submission_type` | enum | 评价/反馈 |\n\n### 16.3 `support_assignment_logs`\n\n| 字段 | 类型 | 说明 |\n| --- | --- | --- |\n| `assignment_log_id` | PK | 分配日志 |\n| `ticket_id` | FK | 工单 |\n| `from_owner_id` | FK | 原负责人 |\n| `to_owner_id` | FK | 新负责人 |\n| `assign_type` | enum | 自动分配/组长分派/转派/升级 |\n| `reason` | text | 原因 |\n| `created_at` | datetime | 分配时间 |\n\n### 16.4 `plan_task_links`\n\n| 字段 | 类型 | 说明 |\n| --- | --- | --- |\n| `link_id` | PK | 桥接 ID |\n| `plan_id` | FK | 计划 |\n| `task_type` | enum | IM_TASK/EDM_TASK/APP_TASK/TEL_TASK/CS_TASK/KOC_TASK |\n| `task_id` | string | 各渠道任务 ID |\n| `created_at` | datetime | 创建时间 |\n\n---\n\n## 17. 评价与退款结果层\n\n### 17.1 `review_submission_records`\n\n| 字段 | 类型 | 说明 |\n| --- | --- | --- |\n| `submission_id` | PK | 提交记录 |\n| `person_id` | FK | 真实人 |\n| `plan_id` | FK | 计划 |\n| `channel` | enum | IM/EDM/APP/TEL/CS |\n| `source_event_id` | string | 来源事件 |\n| `submitted_at` | datetime | 提交时间 |\n| `submission_evidence` | JSON | 截图/链接 |\n| `order_number_hash` | string | 订单索引 |\n| `quota_counted` | bool | 是否已计入 12（提交时即为true） |\n\n### 17.2 `review_display_checks`\n\n| 字段 | 类型 | 说明 |\n| --- | --- | --- |\n| `check_id` | PK | 核验记录 |\n| `submission_id` | FK | 提交记录 |\n| `asin` | string | ASIN |\n| `check_at` | datetime | 核验时间 |\n| `is_displayed` | bool | 是否展示 |\n| `is_verifiable` | bool | 是否可核验 |\n| `display_status` | enum | 展示确认/未展示/待核验 |\n| `plan_completed` | bool | 是否计入计划完成（展示确认后才为true） |\n\n### 17.3 `amazon_refund_records` / `oa_refund_records` / `refund_match_results`\n\n| 对象 | 关键字段 |\n| --- | --- |\n| `amazon_refund_records` | `refund_id`、`order_number_hash`、`asin`、`refund_amount`、`refund_at`、`refund_reason` |\n| `oa_refund_records` | `oa_refund_id`、`person_id`、`order_number_hash`、`refund_amount`、`refund_at` |\n| `refund_match_results` | `match_id`、`order_number_hash`、`amazon_refund_id`、`oa_refund_id`、`match_status`、`amount_diff`、`matched_at` |\n\n---\n\n## 18. 免评结果层\n\n### 18.1 `exemption_plans`\n\n| 字段 | 类型 | 说明 |\n| --- | --- | --- |\n| `exemption_plan_id` | PK | 免评计划 |\n| `source_request_id` | FK | 来源需求 |\n| `asin` | string | ASIN |\n| `marketplace` | string | 站点 |\n| `goal_type` | enum | 内容发布/引流/带货/权重 |\n| `target_metrics` | JSON | 目标点击、Code、订单、销量、权重 |\n| `status` | enum | 草稿/待审批/执行中/已完成/已关闭 |\n\n### 18.2 `exemption_plan_tasks`\n\n| 字段 | 类型 | 说明 |\n| --- | --- | --- |\n| `task_id` | PK | 免评任务 |\n| `exemption_plan_id` | FK | 免评计划 |\n| `task_type` | enum | KOC/KOL/IM/EDM/APP/内容协同 |\n| `owner_id` | FK | 负责人 |\n| `status` | enum | 待执行/执行中/已完成/异常 |\n| `created_at` | datetime | 创建时间 |\n\n### 18.3 `creator_content_records`\n\n| 字段 | 类型 | 说明 |\n| --- | --- | --- |\n| `creator_content_id` | PK | 内容记录 |\n| `exemption_task_id` | FK | 免评任务 |\n| `creator_id` | string | KOC/KOL |\n| `content_url` | string | 内容链接 |\n| `published_at` | datetime | 发布时间 |\n| `code_usage_count` | int | Code 使用量 |\n| `click_count` | int | 点击量 |\n| `order_count` | int | 带货订单 |\n| `sales_amount` | decimal | 销售额 |\n\n### 18.4 `exemption_result_snapshots`\n\n| 字段 | 类型 | 说明 |\n| --- | --- | --- |\n| `snapshot_id` | PK | 免评结果快照 |\n| `exemption_plan_id` | FK | 免评计划 |\n| `snapshot_at` | datetime | 快照时间 |\n| `content_published_count` | int | 内容发布数 |\n| `click_count` | int | 点击 |\n| `code_usage_count` | int | Code 使用 |\n| `order_count` | int | 订单 |\n| `sales_amount` | decimal | 销售额 |\n| `weight_change_summary` | text | 权重变化摘要 |\n\n---\n\n## 19. 客服管理支撑层\n\n| 对象 | 关键字段 |\n| --- | --- |\n| `attendance_records` | `record_id`、`agent_id`、`date`、`scheduled_hours`、`actual_hours`、`status` |\n| `shift_schedules` | `shift_id`、`team_id`、`agent_id`、`date`、`shift_start`、`shift_end`、`max_tickets` |\n| `support_goal_records` | `goal_id`、`agent_id`、`period_key`、`goal_type`、`target_value`、`current_value` |\n| `support_performance_snapshots` | `snapshot_id`、`agent_id`、`period_key`、`tickets_handled`、`messages_sent`、`first_response_avg_sec`、`rso_orders`、`rdo_orders`、`reviews_obtained`、`review_completion_rate`、`monthly_target`、`monthly_completed` |\n\n---\n\n## 20. 逻辑关系总图\n\n```mermaid\nerDiagram\n PERSON_PROFILES ||--o{ PERSON_IDENTITY_LINKS : \"归并\"\n PERSON_PROFILES ||--o{ PERSON_FEATURE_SNAPSHOTS : \"画像\"\n PERSON_PROFILES ||--o{ CONTACT_CONTEXT_SNAPSHOTS : \"上下文\"\n PERSON_PROFILES ||--o{ PERSON_QUOTA_LEDGERS : \"额度台账\"\n PERSON_PROFILES ||--o{ QUOTA_RESERVATIONS : \"额度预占\"\n PERSON_PROFILES ||--o{ RISK_SIGNALS : \"风险信号\"\n PERSON_PROFILES ||--o{ RISK_CASES : \"风险案件\"\n PERSON_PROFILES ||--o{ AUDIENCE_SNAPSHOTS : \"人群入选\"\n PERSON_PROFILES ||--o{ AUDIENCE_EXCLUSIONS : \"人群排除\"\n PERSON_PROFILES ||--o{ CHANNEL_ROUTE_DECISIONS : \"路由\"\n PERSON_PROFILES ||--o{ CHANNEL_DEDUP_RECORDS : \"去重\"\n PERSON_PROFILES ||--o{ INTERACTION_RECHECK_RECORDS : \"互动复检\"\n PERSON_PROFILES ||--o{ IM_INTERACTION_RECORDS : \"IM\"\n PERSON_PROFILES ||--o{ IM_FLOW_TAGS : \"IM标签\"\n PERSON_PROFILES ||--o{ EDM_MESSAGE_EVENTS : \"EDM\"\n PERSON_PROFILES ||--o{ EDM_USER_BEHAVIOR_PROFILES : \"EDM画像\"\n PERSON_PROFILES ||--o{ APP_TOUCH_EVENTS : \"APP\"\n PERSON_PROFILES ||--o{ TEL_CALL_RECORDS : \"TEL\"\n PERSON_PROFILES ||--o{ SUPPORT_TICKETS : \"工单\"\n PERSON_PROFILES ||--o{ SUPPORT_FOLLOWUPS : \"跟进\"\n PERSON_PROFILES ||--o{ REVIEW_SUBMISSION_RECORDS : \"评价提交\"\n PERSON_PROFILES ||--o{ MANUAL_REVIEW_TASKS : \"人工复核\"\n REVIEW_SUBMISSION_RECORDS ||--o{ REVIEW_DISPLAY_CHECKS : \"展示核验\"\n SUPPORT_TICKETS ||--o{ SUPPORT_ASSIGNMENT_LOGS : \"分配\"\n RISK_CASES ||--o{ BLACKLIST_ENTITIES : \"同步\"\n AMAZON_REFUND_RECORDS ||--o{ REFUND_MATCH_RESULTS : \"退款比对\"\n OA_REFUND_RECORDS ||--o{ REFUND_MATCH_RESULTS : \"退款比对\"\n EXEMPTION_PLANS ||--o{ EXEMPTION_PLAN_TASKS : \"任务\"\n EXEMPTION_PLAN_TASKS ||--o{ CREATOR_CONTENT_RECORDS : \"内容\"\n EXEMPTION_PLANS ||--o{ EXEMPTION_RESULT_SNAPSHOTS : \"结果\"\n REVIEW_PLANS ||--o{ PLAN_TASK_LINKS : \"计划任务\"\n SHIFT_SCHEDULES ||--o{ SUPPORT_TICKETS : \"排班分配\"\n ATTENDANCE_RECORDS }o--|| SHIFT_SCHEDULES : \"出勤关联\"\n```\n\n---\n\n# 第五部分：数据流转\n\n## 21. 关键流转时序\n\n| 阶段 | 读（查） | 写 | 说明 |\n| --- | --- | --- | --- |\n| 真实人识别 | person_identity_links（已有线索） | person_profiles + person_identity_links（新线索） | 每次互动都先跑 |\n| 画像生成 | person_profiles + 七组画像数据 + 各渠道事件 | person_feature_snapshots | 定期或触发式刷新 |\n| 人群生成 | person_feature_snapshots + person_quota_ledgers + risk_signals | audience_snapshots + audience_exclusions + quota_reservations | 快照当下状态 |\n| 路由决策 | audience_snapshots + 用户状态 + 渠道可达性 | channel_route_decisions + channel_dedup_records | 选定渠道+去重 |\n| 渠道发送 | channel_route_decisions + quota_reservations + risk_signals（最新） | 各渠道事件表 | 发送前终校 |\n| 用户回应 | person_identity_links + person_quota_ledgers + risk_signals（全部重读） | interaction_recheck_records + 渠道事件表更新 + im_flow_tags | 每次互动复检留痕 |\n| 评价提交 | person_quota_ledgers（累计额度） | review_submission_records + person_quota_ledgers（+1） | 提交即计12 |\n| Amazon 展示确认 | review_submission_records | review_display_checks + 计划完成度更新 | 展示才计完成 |\n| 退款/返款 | amazon_refund_records + oa_refund_records | refund_match_results + risk_signals（如命中） | 双重退款检测 |\n\n## 22. 每次有效互动的标准写入顺序\n\n```mermaid\nflowchart LR\n A[\"互动发生\"] --> B[\"解析真实人
读 person_identity_links\"]\n B --> C[\"生成/更新上下文卡
写 contact_context_snapshots\"]\n C --> D[\"读取最新额度
读 person_quota_ledgers\"]\n D --> E[\"执行风险判断
读 risk_signals + blacklist\"]\n E --> F[\"写 interaction_recheck_records\"]\n F --> G{\"结果\"}\n G -->|正常| H[\"继续业务\"]\n G -->|预警| I[\"继续 + 高亮提醒\"]\n G -->|拦截| J[\"暂停 + 转人工/风险链路\"]\n```\n\n适用场景：主动推送后回复、用户再次联系、补充订单号、客服回访、TEL 来电、退款/返款/再次触达前。\n\n---\n\n# 第六部分：设计决策与边界\n\n## 23. 对象分类\n\n| 类型 | 对象 | 原因 |\n| --- | --- | --- |\n| **正式事务表** | `person_profiles`、`person_identity_links`、`support_tickets`、`support_followups`、`risk_cases`、`review_submission_records`、`quota_reservations` | 需要增删改和业务状态流转 |\n| **不可变事件表** | `im_interaction_records`、`edm_message_events`、`app_touch_events`、`tel_call_records`、`amazon_refund_records`、`oa_refund_records`、`support_assignment_logs`、`im_flow_tags` | 事实一旦发生不应被覆盖 |\n| **快照表** | `person_feature_snapshots`、`contact_context_snapshots`、`audience_snapshots`、`support_performance_snapshots`、`exemption_result_snapshots` | 需要保留某一时点状态以便复盘 |\n| **决策表** | `channel_route_decisions`、`channel_dedup_records`、`interaction_recheck_records`、`refund_match_results` | 保存系统当时为什么这样判断 |\n| **聚合画像** | `edm_user_behavior_profiles` | 由事件聚合推导，定期刷新 |\n| **可先做视图** | 当前剩余额度、当前风险摘要、当前上下文卡、当前人群统计看板、当前绩效看板 | 可由底层对象实时聚合 |\n\n### 判断法\n\n| 问题 | 如果答案是\"是\" |\n| --- | --- |\n| 后续需要追责\"当时为什么这么做\"吗 | 建正式表或决策表 |\n| 数据后来会变，但历史判断不能跟着变吗 | 建快照 |\n| 只是为了当前页面展示吗 | 优先做视图 |\n| 一旦发生就不该被覆盖吗 | 建事件表 |\n\n## 24. 当前还不能只靠\"老表扩列\"解决的事情\n\n| 问题 | 为什么不能只扩列 |\n| --- | --- |\n| 一个真实人多个账号 | `users` 是账号级，不是人级 |\n| 每次互动重判 | 不是用户静态属性，而是一次次决策事实 |\n| 人群为什么入选/排除 | 不是计划表字段，而是某一批次结果 |\n| 多计划并发占额度 | 需要独立预占 |\n| 用户提交与展示拆分 | 不是一个布尔值能表达 |\n| 退款比对 | 需要两个来源事实加一个比对结果 |\n| 客服上下文 | 不是工单表本身，而是跨源聚合视图+快照 |\n\n## 25. 当前可以先不做成物理表的内容\n\n| 内容 | 当前建议 |\n| --- | --- |\n| 当前剩余额度 | 先由 `person_quota_ledgers + quota_reservations` 聚合成视图 |\n| 当前风险摘要 | 先由 `risk_signals + risk_cases + blacklist_entities` 聚合成视图 |\n| 当前客服上下文卡 | 前台读当前视图，关键接入动作时写 `contact_context_snapshots` |\n| 当前人群统计看板 | 先基于 `audience_snapshots / exclusions` 聚合 |\n| 当前绩效看板 | 先基于工单、通话、跟进事件聚合，后续再沉淀快照 |\n\n## 26. 外部数据引用原则\n\n| 外部数据 | 所属系统 | USER 当前做法 |\n| --- | --- | --- |\n| Amazon 订单全量明细 | Amazon API/报表 | 导入关键字段，不把 USER 做成全量订单数仓 |\n| JOYHUB 用户行为明细 | APP/用户系统 | 取摘要或增量同步，用于画像与上下文 |\n| 黑名单全量数据 | 黑名单系统 | 引用并缓存关键维度，不重复建设 |\n| JOYCOLLAB 全量内容与带货明细 | JOYCOLLAB | 同步 USER 闭环所需结果摘要 |\n| 财务/人事原始表 | 财务/人事系统 | 导入必要摘要，不替代源系统 |\n\n## 27. 涉密字段处理\n\n| 涉密字段 | 建议存储 | 建议查询 |\n| --- | --- | --- |\n| 订单号 | 哈希索引 + 加密原值 | 常规用哈希匹配 |\n| 邮箱 | 哈希索引 + 脱敏展示 | 普通页面不暴露明文 |\n| 电话 | 哈希索引 + 加密原值 | 仅授权角色可揭示 |\n| 姓名/地址 | 标准化值 + 哈希/指纹 | 归并与风险用指纹 |\n| 设备号 | 哈希索引 | 归并/风险用哈希 |\n| IP | 脱敏存储 | 仅用于弱关联 |\n| 收款信息 | 加密存储 | 财务/风险授权查看 |\n| 返款金额/提成 | 权限控制 | 财务角色优先 |\n\n## 28. 快照策略\n\n| 快照对象 | 生成时机 | 保留策略 |\n| --- | --- | --- |\n| `person_feature_snapshots` | 定期刷新 + 人群生成前触发 | 保留最近 N 版 + 每次人群生成引用的版本 |\n| `contact_context_snapshots` | 用户接入/工单创建/拨打前/风险升级 | 每次生成新快照，保留全量历史 |\n| `audience_snapshots` | 人群生成时 | 每次计划保留 |\n| `edm_user_behavior_profiles` | EDM 画像定时刷新 | 按刷新批次保留 |\n| `support_performance_snapshots` | 每日/每周/每月 | 按周期聚合保留 |\n| `exemption_result_snapshots` | 免评执行阶段性同步 | 按结果周期保留 |\n\n---\n\n# 第七部分：谁写谁读\n\n## 29. 读写矩阵\n\n| 对象 | 主要写入方 | 主要读取方 | 依赖它的动作 |\n| --- | --- | --- | --- |\n| `person_profiles` | 身份归并服务 | 用户运营、客服、风险 | 所有真实人级判断 |\n| `person_identity_links` | 身份归并服务 | 风险、客服、订单核验 | 真实人识别 |\n| `person_feature_snapshots` | 画像任务 | 人群生成、客服 | 画像筛选 |\n| `contact_context_snapshots` | 上下文聚合服务 | 客服、用户运营 | 接入处理 |\n| `person_quota_ledgers` | 额度服务 | 人群生成、渠道、客服 | 4/4/12 判断 |\n| `quota_reservations` | 人群/计划服务 | 渠道、额度服务 | 发送前拦截 |\n| `audience_snapshots` | 人群生成服务 | 计划、复盘 | 解释入选 |\n| `channel_route_decisions` | 路由服务 | 推送、复盘 | 选渠道 |\n| `interaction_recheck_records` | 互动复检服务 | 客服、风险、审计 | 决定继续/拦截 |\n| `review_submission_records` | 客服/IM/TEL | 额度、计划、客服 | 计入12 |\n| `review_display_checks` | 运营/系统 | 计划、ASIN看板 | 计入完成 |\n| `refund_match_results` | 退款比对服务 | 风险、客服、财务 | 拦截双重退款 |\n\n---\n\n## 30. 还需要确认但不阻塞第三步的事项\n\n| 事项 | 影响 |\n| --- | --- |\n| Amazon 订单同步频率最终是否为 10 分钟 | 影响订单/退款数据新鲜度 |\n| 黑名单系统最终通过 API、表格还是消息同步 | 影响 `blacklist_entities` 同步方式 |\n| Amazon Profile ID 是否稳定获取 | 影响强关联覆盖率 |\n| APP 设备型号能否拿到具体型号还是只到类型 | 影响客服展示颗粒度 |\n| 年龄字段来自注册资料还是推断 | 影响画像可信度 |\n| KOC/KOL 结果同步周期 | 影响免评结果快照频率 |\n\n---\n\n## 31. 第四步入口\n\n1. **把数据对象转成逻辑 ER 图**：以 §20 的 Mermaid ER 图为基础，明确主键、外键、1对多/多对多关系，区分复用旧表和新增表。\n2. **按关键链路补接口读写**：\n 1. 真实人识别与上下文链路\n 2. 人群/额度/路由链路\n 3. 互动复检/风险链路\n 4. 评价提交/展示与退款比对链路\n 5. 免评结果链路\n3. **回到页面，把每一个点击绑定到明确的数据读写**。\n\n---\n\n## 32. 本版结论\n\nv3 以 Codex v1.1 完整字段字典为主骨架，补入 v2 的流转时序表、写入顺序图和快照策略，形成最终统一主稿：\n\n1. 用 **真实人** 统一账号、订单、设备和风险\n2. 用 **画像快照** 解释人群生成\n3. 用 **额度台账+预占** 保护 4/4/12 规则（跨账号合并）\n4. 用 **路由决策+去重记录** 控制多渠道协同\n5. 用 **互动复检记录** 落实\"每次有效互动都重判\"\n6. 用 **退款比对结果** 识别双重退款\n7. 用 **评价提交记录+展示核验** 拆开用户事实和平台结果\n8. 用 **免评计划→任务→内容→结果快照** 让 KOC/KOL 闭环完整进入 USER 系统\n", + "wikilinks": [], + "category": "layer-requirements" + } + }, + { + "id": "doc:05_需求文档/20260517_USER评价业务闭环主流程与后续工作基线_v1.2", + "type": "document", + "name": "USER 评价业务闭环主流程与后续工作基线 v1.2", + "filePath": "05_需求文档/20260517_USER评价业务闭环主流程与后续工作基线_v1.2.md", + "summary": "USER 评价业务闭环主流程与后续工作基线 v1.2 文件信息 文件名称： 20260517 USER评价业务闭环主流程与后续工作基线 v1.2.md 项目路径： C:\\XCODE\\USER 当前版本： v1.2 最近更新： 2026 05 17 前一版本： 20260517 USER评价业务闭环主流程与后续工作基线 v1.1.md 文件目的：在既有销售到评", + "tags": [ + "05_需求文档", + "需求文档" + ], + "complexity": "moderate", + "knowledgeMeta": { + "content": "# USER 评价业务闭环主流程与后续工作基线 v1.2\n\n## 文件信息\n\n- 文件名称：`20260517_USER评价业务闭环主流程与后续工作基线_v1.2.md`\n- 项目路径：`C:\\XCODE\\USER`\n- 当前版本：`v1.2`\n- 最近更新：`2026-05-17`\n- 前一版本：`20260517_USER评价业务闭环主流程与后续工作基线_v1.1.md`\n- 文件目的：在既有销售到评价闭环基线上，补入真实人识别、测评 / 免评额度、用户历史上下文、IM / EDM / TEL / 客服细化口径，作为新版第二步和后续数据流设计的统一依据。\n- 适用范围：当前阶段的 Amazon 业务闭环设计；如后续扩展到独立站或非 Amazon 评价体系，需要在本文件基础上另行增补。\n- 使用方式：下一次继续本项目时，先读取本文件，再读取 `20260517_USER评价业务闭环_共用能力图与渠道专属流程_v2.2.md`，不要再从旧版页面链路重新推导业务主干。\n\n---\n\n## 版本记录\n\n| 版本 | 日期 | 说明 |\n| --- | --- | --- |\n| v1 | 2026-05-17 | 首次固化销售到评价完成的 USER 业务闭环主流程 |\n| v1.1 | 2026-05-17 | 将免评改为独立闭环；明确每次有效互动都要重新做身份与风险判断；明确当前版本不单列商家角色 |\n| v1.2 | 2026-05-17 | 补入用户历史与设备上下文、真实人级 `测评4 / 免评4 / 累计真实提交评价12` 规则、IM / EDM / TEL / 客服新增细节，并把第二步入口改为“共用能力 + 渠道专属流程” |\n\n---\n\n## 1. 已确认目标\n\n1. 系统要支持 USER 部门工作，而不是只做一个回评记录工具。\n2. 业务流必须从“销售发生 / 需求形成”开始，而不是从“推送”开始。\n3. Amazon 运营既可以人工提需求，系统也可以因 Listing 健康或评价缺口自动触发需求。\n4. 用户运营是“需求评估 + 计划调度中心”，负责把需求转成可执行计划并跟踪结果。\n5. 计划类型必须正式保留：\n - 推新计划\n - 回评计划\n - 免评计划\n6. `免评计划` 不是边缘例外，而是需要正式保留的关键业务类型；其与 KOC / KOL、社媒带货、站外流量和 Amazon 权重有关。\n7. 用户提交评价与系统确认评价完成必须拆成两个节点：\n - 用户已真实提交评价\n - Amazon 已展示 / 系统已确认计入计划完成\n8. `真实人` 是后续额度、风险、历史和用户画像的核心对象，不应只围绕某个 JOYHUB ID、邮箱或 Amazon 账号看用户。\n9. 已确认的额度规则为：\n - 同一真实人每月最多参与 `4 次测评`\n - 同一真实人每月最多参与 `4 次免评`\n - 同一真实人累计最多计入 `12 个真实提交的评价`\n10. `12` 的计数时点是 `用户真实提交评价`，不是 `Amazon 展示评价`。\n11. 每次有效互动都要重新做身份、历史、额度和风险判断；主动推送后的回复也不例外。\n12. 客服接入时必须能快速看到用户历史、订单历史、设备上下文、既往风险和当前提醒，而不是只看到当前对话。\n13. 后续系统设计顺序已经确定：\n 1. 先定业务流\n 2. 再做点击操作模拟\n 3. 最后根据业务需求整合现有数据，形成新的数据流和中间表需求\n\n---\n\n## 2. 当前边界与资料依据\n\n### 2.1 当前纳入范围\n\n- Amazon 业务\n- 销售到评价闭环\n- 推新、回评、免评\n- IM、EDM、APP、TEL、KOC / KOL\n- 售后接入\n- 客服执行与客服管理支撑\n- 黑名单与诈骗风险\n- ASIN 健康回流\n\n### 2.2 当前不作为本版主流程展开的内容\n\n- 独立站全链路\n- 完整 BI / 财务 / ROI 系统\n- 完整 KOC / KOL 结算系统\n- 所有历史后台页面逐页重构\n- 数据库最终物理设计\n\n### 2.3 资料依据\n\n本文件基于以下材料整理：\n\n1. `C:\\XCODE\\USER\\评价业务流闭环项目架构文档_v0.8.docx`\n2. `C:\\XCODE\\USER\\docs\\evaluation-business-architecture.md`\n3. `C:\\XCODE\\USER\\docs\\project-phase-one-plan.md`\n4. `C:\\XCODE\\USER\\output\\docs\\20260503_USER后台ERP一期功能与页面设计_v4.md`\n5. `C:\\XCODE\\USER\\output\\docs\\20260503_USER后台ERP自动推送与计划状态机_v4.md`\n6. `C:\\XCODE\\USER\\output\\docs\\20260503_USER后台ERP一期页面原型说明_v4.md`\n7. `C:\\XCODE\\USER\\output\\docs\\20260503_USER后台ERP_MVP角色首页UI规划_v1.md`\n8. `C:\\tcode\\飞书\\飞书聊天记录库\\cloud_files` 中当前主原型 HTML 与 `客服执行.html`\n9. `C:\\Users\\wu_zh\\Downloads\\20260407-法国诈骗问题（已扩散美国）.docx`\n10. `C:\\Users\\wu_zh\\Desktop\\表头.xlsx`\n11. `C:\\Users\\wu_zh\\Downloads\\IM 推送业务流.mm`\n12. `C:\\Users\\wu_zh\\Downloads\\后台回评工作流对接事项.docx`\n13. `C:\\Users\\wu_zh\\Downloads\\客服相关模块.docx`\n14. `C:\\Users\\wu_zh\\Downloads\\电话业务流程知识库.docx`\n15. 用户在当前对话中补充确认的业务规则\n\n若历史资料与当前对话确认口径冲突，以当前对话中最新确认口径为准。\n\n---\n\n## 3. 角色与职责\n\n| 角色 | 核心职责 |\n| --- | --- |\n| Amazon 运营 | 依据销售、ASIN、评价目标提出推新 / 回评 / 免评需求 |\n| Amazon 运营总监 | 审批相关计划，确认优先级与业务必要性 |\n| 品牌运营 | 负责品牌推广、站外节奏和与用户运营 / 内容运营协同 |\n| 内容运营 | 承接社区广告、APP 广告位、内容流量等侧向支持 |\n| 用户运营 | 评估需求、生成计划、分配资源、协调渠道、跟踪结果 |\n| 用户运营负责人 / 组长 | 复核计划、分配组员、处理重点风险和异常 |\n| 菲律宾客服负责人 | 关注工单压力、分配客服组、处理升级工单、查看绩效 |\n| 菲律宾客服组长 | 分配组内工单、复核升级、控制逾期和重点工单 |\n| 菲律宾客服组员 | 实际接待、电话沟通、记录、回复、回访、提交疑似诈骗 |\n| 风险 / 黑名单相关人员 | 接收诈骗疑似、复核、同步黑名单、维护风险口径 |\n| KOC / KOL 运营 | 承接站外带货、合作关系、内容和导购协同 |\n\n当前版本不单列“商家 / 商家运营”角色。这里的“商家”如出现，均按 Amazon 卖家侧语义理解，由 Amazon 运营承接；品牌商当前也只纳入 Amazon 内评价相关协同。\n\n---\n\n## 4. 总体业务结构\n\n### 4.1 主流程\n\n```mermaid\nflowchart LR\n A[\"销售发生 / ASIN销售数据形成\"] --> B[\"需求触发\"]\n B --> B1[\"Amazon运营人工提需求\"]\n B --> B2[\"系统按评价缺口或Listing健康自动触发\"]\n B1 --> C[\"用户运营评估需求\"]\n B2 --> C\n C --> D[\"形成业务计划\"]\n D --> D1[\"推新计划\"]\n D --> D2[\"回评计划\"]\n D --> D3[\"免评计划\"]\n D1 --> E[\"规则 / 风险 / 额度复核\"]\n D2 --> E\n D3 --> E\n E --> F[\"审批通过\"]\n F --> G[\"执行拆解\"]\n G --> H1[\"评价型执行闭环\"]\n G --> H2[\"免评型执行闭环\"]\n H1 --> I1[\"IM / EDM / APP / TEL / 客服协同\"]\n I1 --> J1[\"用户被触达或主动进入\"]\n J1 --> K1[\"每次有效互动均重做身份 / 历史 / 额度 / 风险核验\"]\n K1 --> L1[\"服务 / 售后 / 跟进\"]\n L1 --> M1[\"用户真实提交评价\"]\n M1 --> N1[\"计入真实人累计评价额度\"]\n N1 --> O1[\"Amazon是否展示 / 系统是否确认完成\"]\n O1 --> P[\"结果回流\"]\n H2 --> I2[\"KOC / KOL为核心，IM / EDM / APP等协同参与\"]\n I2 --> J2[\"内容发布 / 站外引流 / 带货执行\"]\n J2 --> K2[\"跟踪点击、Code、订单、转化与权重结果\"]\n K2 --> P\n P --> Q[\"更新ASIN健康、计划完成度、用户画像、流量结果、风险记录\"]\n Q --> C\n```\n\n### 4.2 五个业务层\n\n| 业务层 | 说明 |\n| --- | --- |\n| 经营层 | 销售、ASIN、需求、品牌 / 内容 / KOC-KOL 侧影响 |\n| 计划层 | 推新、回评、免评、审批、规则、额度、风险 |\n| 执行层 | IM、EDM、APP、TEL、客服工单、KOC / KOL 协作 |\n| 服务与身份层 | 用户接入、真实人归并、订单核验、用户上下文、售后处理 |\n| 结果与风险层 | 用户真实提交评价、Amazon 展示确认、免评结果、黑名单、诈骗、结果回流 |\n\n---\n\n## 5. 主流程详细说明\n\n| 阶段 | 业务说明 | 必须检查 | 主要输出 |\n| --- | --- | --- | --- |\n| 1. 销售与需求形成 | 销售发生后，Amazon 运营根据目标或系统根据健康度触发需求 | 销售、ASIN、评分、评价缺口、历史计划 | 新需求 |\n| 2. 用户运营评估 | 判断需求是否成立、是否可做、优先级如何 | ASIN 健康、目标数量、历史完成、当前资源、风险 | 已确认需求 / 待补充 / 驳回 |\n| 3. 计划生成 | 将需求转为推新、回评或免评计划 | 用户池、渠道容量、目标、周期 | 计划草案 |\n| 4. 计划复核与审批 | 对计划做规则、额度和风险复核，再进入审批 | 黑名单、频控、渠道风险、真实人额度、审批权限 | 已批准计划 |\n| 5. 执行拆解 | 把计划拆成渠道任务和人工任务 | 可触达用户、素材、客服负载、KOC / KOL协作 | 推送任务 / TEL任务 / 客服工单 / 协作任务 |\n| 6A. 评价型执行 | 推新、回评进入用户触达、服务与评价链路 | 真实人、订单、历史、额度、风险、售后情况 | 当前处理路径 |\n| 6B. 免评型执行 | 免评以 KOC / KOL 与站外流量为核心，同时可由 IM / EDM / APP 等协同参与 | 合作对象、内容、Code、渠道、素材、节奏、免评额度 | 内容任务 / 引流任务 / 带货任务 |\n| 7A. 用户真实提交评价 | 记录用户是否已经实际提交评价 | 用户反馈、提交证据、对应计划、真实人累计额度 | 已提交评价事实 |\n| 7B. 免评结果跟踪 | 记录免评计划的执行结果 | 内容发布、点击、Code、订单、转化、销量、权重变化 | 免评执行结果 |\n| 8. 评价确认 | 区分用户提交与 Amazon 展示结果 | Amazon 是否展示、是否能核验、是否属本计划 | 计入完成 / 待确认 |\n| 9. 结果回流 | 把评价结果与免评结果重新反馈给经营与计划层 | 计划完成、ASIN 健康、流量结果、风险变化、用户标签 | 新一轮决策输入 |\n\n---\n\n## 6. 关键业务支线\n\n### 6.1 主动触达支线\n\n```mermaid\nflowchart LR\n A[\"计划通过\"] --> B[\"筛选可触达用户池\"]\n B --> C[\"真实人识别 + 人群画像 + 额度校验\"]\n C --> D[\"渠道分配\"]\n D --> D1[\"IM\"]\n D --> D2[\"EDM\"]\n D --> D3[\"APP\"]\n D --> D4[\"TEL\"]\n D1 --> E[\"用户回应\"]\n D2 --> E\n D3 --> E\n D4 --> E\n E --> F[\"每次回应都重做身份 / 历史 / 额度 / 风险核验\"]\n F --> G[\"订单核验\"]\n G --> H[\"服务 / 跟进\"]\n H --> I[\"用户真实提交评价\"]\n```\n\n#### 关键规则\n\n1. IM、EDM、APP 可自动化；TEL 属于人工执行渠道。\n2. `IM` 需要识别用户分层、绑定玩具、设备、测评 / 免评额度和标签流转。\n3. `EDM` 需要识别最近打开、最近回复、点击评论链接但未回复、月度收信次数、最近 3 / 5 次 0 打开、邮箱类型、退订和硬退信。\n4. 计划生成前必须先检查：\n - 用户是否可触达\n - 是否命中风险\n - 是否超频\n - 是否符合站点 / 国家 / 产品目标\n - 是否接近或达到真实人额度上限\n5. 用户回应后，不能沿用上一次判断结果，必须重新检查当前身份、订单、设备、地址、历史、额度与风险状态。\n\n### 6.2 免评执行支线\n\n```mermaid\nflowchart LR\n A[\"免评计划通过\"] --> B[\"拆解执行方案\"]\n B --> C1[\"KOC / KOL协作\"]\n B --> C2[\"IM / EDM / APP辅助触达\"]\n B --> C3[\"内容 / 运营协同\"]\n C1 --> D[\"内容发布 / Code使用 / 站外引流\"]\n C2 --> D\n C3 --> D\n D --> E[\"跟踪点击、跳转、Code、订单、转化、销量与权重变化\"]\n E --> F[\"结果回流到ASIN健康与后续计划\"]\n```\n\n#### 关键规则1\n\n1. 免评计划不是评价型计划的弱化版本，而是以站外流量、带货、销量和权重结果为终点的独立闭环。\n2. KOC / KOL 是免评计划的核心执行通道，但 IM、EDM、APP 等也可以参与协同。\n3. 同一真实人每月最多参与 `4 次免评`；免评额度也要做预警、预占和拦截。\n4. 免评计划不以“用户提交评价”作为完成条件，必须另行跟踪内容发布、Code、点击、订单、转化、销量和权重变化。\n5. 如果免评执行过程中发生用户互动、售后或返款等行为，仍须进入统一的身份与风险判断机制。\n\n### 6.3 被动售后与 TEL 支线\n\n```mermaid\nflowchart LR\n A[\"用户主动联系 / 电话呼入\"] --> B[\"接入即预查\"]\n B --> C[\"识别来源、身份、订单、历史、风险\"]\n C --> D{\"是否有售后问题\"}\n D -->|有| E[\"问题分类与解决方案\"]\n E --> F[\"确认是否解决 / 是否满意\"]\n F --> G[\"满意后进入回评 / 测评邀请\"]\n D -->|无| H[\"确认无其他需求\"]\n H --> I[\"可进入测评邀请\"]\n G --> J[\"记录电话 / 工单 / 后续跟进\"]\n I --> J\n```\n\n#### 关键规则2\n\n1. TEL 当前至少包含两类入口：\n - 计划生成后的人工外呼任务\n - 用户从 Amazon 页面或说明书主动呼入\n2. 有售后问题时，必须先解决售后，再谈评价或测评邀请。\n3. 电话中需要尽量确认：\n - 购买平台\n - 订单号\n - 产品型号 / 款式 / 颜色\n - 购买时间\n - 问题类型\n - 是否有图片、视频或其他凭证\n4. 每通电话结束后，至少要记录：\n - 来电时间\n - 来源\n - 联系方式\n - 订单号\n - 问题类型和描述\n - 处理方案\n - 是否已解决\n - 是否需要后续跟进\n - 是否邀请测评 / 回评\n - 用户是否接受\n5. 当前电话业务的核心是：\n - 自然单回评转化\n - 充分利用电话用户的测评资源\n\n### 6.4 风险 / 诈骗拦截支线\n\n```mermaid\nflowchart LR\n A[\"新订单同步 / 主动触达回应 / 用户接入 / 退款申请 / 再次跟进\"] --> B[\"重新做风险识别\"]\n B --> C{\"是否命中强关联\"}\n C -->|是| D[\"直接进入高风险或黑名单链路\"]\n C -->|否| E{\"是否命中弱关联\"}\n E -->|是| F[\"进入高风险观察 + 人工复核\"]\n E -->|否| G[\"继续正常流程\"]\n D --> H[\"拦截自动退款、继续推送、自动放行\"]\n F --> H\n H --> I[\"提醒客服 / 用户运营 / 审核人员\"]\n```\n\n#### 已确认风险口径\n\n| 风险类型 | 关联项 | 处理原则 |\n| --- | --- | --- |\n| 强关联 | 邮箱、设备号、电话、收件人姓名+地址、订单号、聊天记录、Profile ID、收款信息 | 一旦命中，可直接进入高风险或黑名单链路 |\n| 弱关联 | IP 单独命中、姓名单独命中、同址异名 | 进入高风险观察，不直接认定诈骗 |\n\n#### 已确认业务问题\n\n1. 当前真实事故中存在“双重退款”风险：\n - APP / OA 已退款\n - 用户又向 Amazon 申请退款\n2. 需要把 Amazon 退款与 OA 返款自动比对。\n3. 高风险用户一旦标记，支付 / 返款需要人工复核。\n4. 客服、审核、退款等环节必须都能看到风险提醒。\n5. 非 APP 用户如果直接走邮件退款，因缺少设备、注册邮箱等维度，风险识别能力明显下降。\n6. 风险判断不是一次性的接入动作，而是每次有效互动都要重新执行。\n\n### 6.5 客服工单与客服管理支线\n\n```mermaid\nflowchart LR\n A[\"用户消息进入 / 推送转人工 / 售后触发 / 风险触发\"] --> B[\"生成工单\"]\n B --> C[\"按班次、在线状态、当前负载自动分配\"]\n C --> D[\"客服处理\"]\n D --> E{\"处理结果\"}\n E -->|等待用户| F[\"等待用户回复\"]\n E -->|等待内部| G[\"等待内部协同\"]\n E -->|答应配合| H[\"生成后续跟进\"]\n E -->|疑似诈骗| I[\"转风险链路\"]\n E -->|已解决| J[\"关闭工单\"]\n D --> K[\"回复效率 / 转化 / 目标完成统计\"]\n```\n\n#### 工单与管理事实\n\n1. 客服相关模块不只包括工单，还包括：\n - 出勤管理\n - 排班管理\n - 回复效率统计\n - 转化统计\n - 目标管理\n2. `排班` 与 `在线状态` 会直接影响自动分配。\n3. `工单状态`、`答应配合状态`、`风险状态` 必须拆开存。\n4. 客服转化要区分：\n - RSO 回评\n - RDO 测评\n5. 回复效率至少要统计：\n - 回复用户数\n - 处理工单数\n - 发送消息数\n - 平均 / 中位数 / 最大 / 最小首次回复时长\n6. 转化统计至少要看：\n - 登记订单数\n - 获取评价数\n - 评价完成率\n7. 主管需要看到出勤、排班、绩效、目标完成和工单分配，而不是只看单个会话。\n\n---\n\n## 7. 真实人识别、用户上下文与额度规则\n\n### 7.1 真实人识别原则\n\n1. 当前系统不应只围绕 `JOYHUB ID` 看用户，而应同时围绕：\n - 账号\n - 订单\n - 实际收件人\n - 设备\n - 联系方式\n - 风险关系\n2. 如果用户在 JOYHUB 内提交订单，则订单可直接关联到当前 JOYHUB ID。\n3. 如果用户通过邮件联系：\n - 先问是否有 JOYHUB ID\n - 再用注册邮箱与 JOYHUB ID 做关系查询\n4. 如果用户通过电话联系：\n - 先确认是否注册 APP\n - 结合电话、订单、收件人、地址、设备、邮箱继续识别\n5. 非 APP 用户如需继续参与相关流程，应优先引导注册 APP，再继续后续动作。\n\n### 7.2 实际收件人判定\n\n| 情况 | 处理原则 |\n| --- | --- |\n| 标准化后姓名 + 地址完全一致 | 直接认为是同一实际收件人 |\n| 地址一致但姓名不同 | 只认为存在家庭 / 关联风险，不直接判定同一人 |\n| 邮箱不同、JOYHUB ID 不同 | 不能单独否定“同一实际人” |\n| 订单号命中历史异常 | 应立即拉出历史上下文和风险记录 |\n\n### 7.3 用户上下文卡\n\n客服和用户运营在必要节点应能看到：\n\n| 字段组 | 例子 |\n| --- | --- |\n| 当前身份 | JOYHUB ID、邮箱、电话、真实人 ID、当前订单 |\n| 历史交易 | 历史订单、最近购买、退款 / 返款、目标 ASIN 购买情况 |\n| 历史服务 | 历史工单、聊天、电话、承诺、提醒、关闭原因 |\n| 历史风险 | 黑名单、关联账号、疑似诈骗、双重退款、异常订单 |\n| 当前设备 | 设备号摘要、设备型号 / 类型、系统版本、APP 版本、最近设备变化 |\n| 触达历史 | IM / EDM / APP / TEL 最近触达、回复、退订、投诉 |\n\n### 7.4 额度规则\n\n| 规则 | 统计对象 | 计数口径 |\n| --- | --- | --- |\n| 月度测评最多 4 次 | 真实人 | 已完成 + 进行中 + 已预占 |\n| 月度免评最多 4 次 | 真实人 | 已完成 + 进行中 + 已预占 |\n| 累计真实提交评价最多 12 个 | 真实人 | 用户真实提交评价后立即计数 |\n\n### 7.5 额度控制原则\n\n1. 额度判断必须放在 `真实人识别` 之后，而不是只看单一账号。\n2. 系统不能等到真正超限才提示，必须在接近上限时提前预警。\n3. 一旦 `已用 + 进行中 + 已预占 + 本次拟发送` 会导致超限，就不能进入自动推送。\n4. `Amazon 未展示` 不影响 12 次累计额度，因为口径已经确认按 `真实提交` 计数。\n\n---\n\n## 8. 渠道专属补充事实\n\n### 8.1 IM\n\n- 用户需要分层：未参与过、参与过、长期测评人。\n- 触发条件包括注册 App、绑定玩具、识别绑定产品。\n- 需要校验设备 ID、黑名单、绑定产品、额度与标签。\n- 用户提交订单号、返款账号、评论截图 / 链接后，要继续做订单核验和资格登记。\n\n### 8.2 EDM\n\n- EDM 不是简单“发邮件”，而是独立的筛选与节奏引擎。\n- 需要支持：\n - 最近打开时间\n - 最近回复时间\n - 打开次数\n - 最近 3 / 5 次推送 0 打开\n - 点击评论链接但未回复时长\n - 单月收信次数\n - 各邮件类型发送次数\n - 邮箱后缀标签\n - 国家站点\n - 退订、硬退信、风险用户、黑名单、OA 无资格用户排除\n\n### 8.3 APP\n\n- APP 侧至少要纳入：\n - 注册邮箱\n - 设备号\n - 设备型号 / 类型\n - APP 版本\n - 系统版本\n - 用户行为数据\n - 绑定玩具\n - 活跃与点击行为\n- APP 不只是触达渠道，也是身份识别、设备变化和行为画像的重要来源。\n\n### 8.4 TEL\n\n- TEL 同时承担主动外呼和被动来电。\n- 其价值不只是“打电话”，而是：\n - 解决售后\n - 捕捉自然单回评机会\n - 充分利用电话用户的测评资源\n\n---\n\n## 9. 评价结果规则\n\n### 9.1 必须拆开的两个节点\n\n```mermaid\nflowchart LR\n A[\"用户已真实提交评价\"] --> B[\"计入真实人累计评价额度\"]\n B --> C{\"Amazon是否展示 / 是否可核验\"}\n C -->|展示或可核验| D[\"计入计划完成\"]\n C -->|未展示 / 暂不可核验| E[\"保留用户已提交事实\"]\n E --> F[\"进入待确认 / 异常观察\"]\n D --> G[\"更新ASIN健康与计划完成度\"]\n```\n\n### 9.2 原因\n\n1. 用户可能确实已经提交评价。\n2. Amazon 可能因为其他原因不展示该评价。\n3. `额度计数` 与 `计划完成确认` 不是同一个业务事实。\n4. 如果系统只保留一个“评价完成”状态，会把平台展示问题错误归因给执行人员或用户。\n\n---\n\n## 10. 贯穿全程的数据检查点\n\n| 检查点 | 发生时机 | 核心检查 |\n| --- | --- | --- |\n| 经营检查 | 需求形成前 | 销售、ASIN、评分、评价缺口、历史计划 |\n| 计划检查 | 生成计划前 | 人群、渠道、容量、规则、黑名单 |\n| 画像检查 | 生成人群时 | 国家、站点、性别、年龄、绑定玩具、产品关系、活跃、历史行为 |\n| 额度检查 | 生成人群、发送前、继续推进前 | 测评 4、免评 4、累计真实提交 12、进行中与已预占 |\n| 身份检查 | 首次接入与每次有效互动时 | JOYHUB、邮箱、电话、设备、订单、地址、历史记录 |\n| 互动复检 | 主动触达回应、再次联系、补充订单号、客服回访时 | 关键属性是否变化，是否出现新订单、新地址、新设备、新返款记录 |\n| 风险检查 | 每次有效互动、退款、返款、继续推送前 | 双重退款、强弱关联、黑名单、历史异常 |\n| 结果检查 | 评价提交与确认后 | 首评 / 回评、是否属本计划、是否展示、ASIN 健康变化 |\n\n---\n\n## 11. 第二步的新入口\n\n第二步不再按旧版页面链路推进，而改成：\n\n### 11.1 共用能力图\n\n1. 真实人识别与用户上下文卡\n2. 人群生成与画像拆解\n3. 额度与频控控制\n4. 每次有效互动复检\n5. 风险与黑名单\n\n### 11.2 渠道 / 模块专属流程图\n\n1. IM\n2. EDM\n3. APP\n4. TEL\n5. 客服工单\n6. 客服管理支撑\n7. 评价完成\n8. 免评执行\n\n### 11.3 每张图都必须回答\n\n- 进入条件是什么\n- 要先查什么\n- 如何判断\n- 写入什么\n- 状态怎么变\n- 何时提醒\n- 何时拦截\n- 何时转人工\n\n---\n\n## 12. 下一次继续工作时的直接提示\n\n1. 先读取本文件。\n2. 不要重新讨论“是否从销售开始”“是否保留免评”“评价提交与展示是否拆开”，这些已确认。\n3. 额度口径按当前版本执行：\n - 测评每月最多 4\n - 免评每月最多 4\n - 同一真实人累计真实提交评价最多 12\n4. 不要再把风险判断理解成“首次接入才做一次”；每次有效互动都需要重做判断。\n5. 不要再把第二步按页面链路拆；直接进入 `20260517_USER评价业务闭环_共用能力图与渠道专属流程_v2.2.md`。\n6. 旧版 `v1` / `v1.1` 保留为历史版本，不再作为后续主口径。\n\n---\n\n## 13. 本版结论\n\nUSER 部门未来系统的核心，不是单独记录“谁评价了”，而是把以下内容放进同一条可追踪闭环中：\n\n1. 销售与需求\n2. 计划生成与审批\n3. 真实人识别与用户上下文\n4. 测评 / 免评 / 累计评价额度控制\n5. IM / EDM / APP / TEL / 客服协同\n6. 用户身份与订单核验\n7. 售后服务与评价引导\n8. 免评执行与站外流量结果\n9. 用户真实提交评价\n10. Amazon 展示与系统确认\n11. ASIN 健康回流\n12. 风险与黑名单拦截\n\n只有这条闭环建立起来，后续的点击设计、页面设计和数据设计才不会彼此脱节。\n", + "wikilinks": [], + "category": "layer-requirements" + } + }, + { + "id": "doc:05_需求文档/evaluation-business-architecture", + "type": "document", + "name": "评价业务流闭环项目架构文档", + "filePath": "05_需求文档/evaluation-business-architecture.md", + "summary": "评价业务流闭环项目架构文档 版本：v0.7 更新时间：2026 04 26 当前阶段：业务框架搭建与部门业务梳理 1. 文档目标 本文档用于沉淀评价业务流闭环的业务结构、部门职责、核心数据、看板规划和后续项目规划依据。 当前重点不是直接进入系统设计，而是先明确： 业务闭环如何运转 各部门在闭环中的职责边界 每个部门需要哪些看板与数据字段 APP 与亚马逊运营", + "tags": [ + "05_需求文档", + "需求文档" + ], + "complexity": "complex", + "knowledgeMeta": { + "content": "# 评价业务流闭环项目架构文档\n\n版本：v0.7 \n更新时间：2026-04-26 \n当前阶段：业务框架搭建与部门业务梳理\n\n## 1. 文档目标\n\n本文档用于沉淀评价业务流闭环的业务结构、部门职责、核心数据、看板规划和后续项目规划依据。\n\n当前重点不是直接进入系统设计，而是先明确：\n\n- 业务闭环如何运转\n- 各部门在闭环中的职责边界\n- 每个部门需要哪些看板与数据字段\n- APP 与亚马逊运营、品牌运营、内容运营、用户运营、客服运营之间的数据关系\n- 后续项目需要支持哪些管理动作、数据归因和异常预警\n\n## 2. 总体业务闭环\n\n### 2.1 当前业务主链路\n\n亚马逊运营、品牌运营、内容运营负责拉新与引流。 \n主要带来曝光和点击，其中当前主要流量来源于亚马逊，小部分开始来源于社媒与网站宣发。\n\n↓\n\n亚马逊运营负责亚马逊渠道转化与成交，品牌运营负责独立站转化与成交。\n\n↓\n\n成交后产生订单与成交数据。\n\n↓\n\n用户运营基于成交用户、绑定用户、活跃用户进行触达推送与索评。 \n同时，用户运营或评价运营需要维护 ASIN 健康度，核心依赖回评结果。\n\n↓\n\n客服运营收集售后问题、用户反馈、负面反馈和评价相关问题，并执行处理与改善动作。\n\n↓\n\n数据层和管理层进行复盘，调整产品策略、销售策略、推送策略、评价策略和人员分工。\n\n### 2.2 闭环中的核心角色\n\n| 角色/部门 | 主要职责 | 当前定位 |\n|---|---|---|\n| 亚马逊运营 | 亚马逊销售、产品销售管理、测评计划需求、免评计划需求、关键词推新、评价健康维护协同 | 当前 APP 用户最主要、最优质来源 |\n| 品牌运营 | 独立站品牌宣发、独立站销售转化、社媒品牌形象、品牌推广、新品宣发、活动宣发、粉丝互动 | 品牌侧销售与推广主责方，协助亚马逊扩大品牌市场份额 |\n| 内容运营 | 售前社区广告计划、APP 广告位、社区内容分发、帖子加权、新帖推流、固定流量池管理、用户 KOC/KCO 对接 | 配合亚马逊运营与品牌运营做销售前期宣发和社区流量承接 |\n| 用户运营 | 测评计划落地、用户触达、IM/EDM/TEL 推送、索评、回评跟进、社区互动、合作伙伴渠道管理 | 系统核心使用者，连接销售需求、用户资源、评价结果与客服执行 |\n| 客服运营 | 售后接待、登记、回复、问题完结、负面反馈处理 | 归属用户部门管理，承接售后与评价问题改善 |\n| 数据层/管理层 | 指标复盘、异常监控、成本分析、策略调整 | 统一看板、归因和管理决策 |\n\n## 3. 基础指标与统一数据口径\n\n### 3.1 销售核心指标\n\n- 销量：日销量、月销量、总销量\n- 绑定数：总用户数、月活、日活、产品绑定用户数\n- 评价数：测评数、回评数、每日每产品评价数、计划所需数量、实际完成数量、差评数\n- 成本：产品成本、返现成本、人力成本、提成、管理成本\n\n### 3.2 基础数据维度\n\n| 数据维度 | 说明 |\n|---|---|\n| 渠道影响力 | 衡量各渠道内容、活动、广告位、推送计划的效果 |\n| 用户属性 | 发帖人属性、用户行为、性别、活跃状态、风险标记 |\n| 时间维度 | 每日、每周、每月、活动周期、新品周期 |\n| 产品维度 | 国家、品牌、类目、二级类目、ASIN、产品绑定情况 |\n| 漏斗维度 | 曝光、点击、跳转、转化、成交、绑定、触达、评价 |\n| 风险维度 | 风险标记用户数、差评数、ASIN 健康风险、异常推送效果 |\n\n### 3.3 建议统一主键\n\n后续系统设计应优先统一以下主键，避免销售、用户、评价、售后数据无法串联：\n\n- 用户 ID\n- 订单 ID\n- 产品 ID\n- ASIN\n- 品牌 ID\n- 国家/站点\n- 渠道 ID\n- 推送 ID\n\n## 4. 第一部分：亚马逊运营相关业务\n\n### 4.1 亚马逊运营在闭环中的定位\n\n亚马逊运营负责在亚马逊平台上进行电商销售工作，是当前 APP 用户最主要、最优质的来源。\n\nAPP 与亚马逊运营之间的核心关系是：\n\n1. 亚马逊销售带来订单和用户来源。\n2. APP 需要识别这些购买用户是否下载安装并绑定产品。\n3. 当前每卖出 10 个玩具，约 40% 用户下载并绑定 APP。\n4. 需要亚马逊运营在 Listing、说明书、官网、售后触点等位置配合提升 APP 下载率和产品绑定率。\n5. 亚马逊运营需要提出测评计划、免评计划、推新计划和回评计划相关需求。\n6. APP 内现有用户资源需要根据产品重要级、推新节奏和评价健康度进行分配。\n\n### 4.2 亚马逊运营核心业务模块\n\n| 模块 | 业务内容 | 与 APP 的关系 |\n|---|---|---|\n| 销售管理 | 亚马逊站点销售、销量监控、产品销售报表 | 提供销量、成交、站点、产品数据 |\n| 产品聚合管理 | 按品牌、国家、类目聚合新品、重点产品、清仓产品 | APP 侧需要计算绑定率和用户覆盖情况 |\n| 绑定率提升 | Listing、说明书、官网等触点引导下载与绑定 APP | APP 提供绑定率数据，亚马逊运营优化触点 |\n| 测评计划 | 亚马逊运营根据销售需求提出测评需求和节奏 | 用户运营负责实际实现，品牌运营参与协同 |\n| 免评计划 | 关键词 + 实时销量策略，定时下单，主要承接补单诉求 | 需单独纳入合规与风险监控 |\n| 推新计划 | 面向 S 级或当期重点产品，结合关键词进行推广 | APP 内推送资源分配需要与推新计划匹配 |\n| 回评计划 | 维护链接评价数、回评数和评分等级 | 主要由亚马逊运营与用户运营协作，品牌运营参与协同 |\n| 品牌推广协同 | 亚马逊运营同步品牌推广计划，并在亚马逊站内承接品牌调性 | 品牌运营为亚马逊站外品牌推广主责方 |\n\n### 4.3 独立看板一：产品销量与绑定率看板\n\n#### 4.3.1 看板目标\n\n用于从亚马逊运营视角监控不同品牌、国家、类目、产品类型下的销量与 APP 绑定情况。\n\n该看板需要支持：\n\n- 品牌聚合\n- 国家/站点聚合\n- 类目与二级类目聚合\n- 新品、重点产品、清仓产品拆分\n- 销量与绑定率对比\n- 异常数据报警\n- 对应人员责任归属\n\n#### 4.3.2 产品类型\n\n| 产品类型 | 说明 |\n|---|---|\n| 新品 | 新上市产品，需要重点关注销量、绑定率、评价启动速度 |\n| 重点产品 | 当期重点销售或重点维护产品，如 S 级产品 |\n| 清仓产品 | 需要配合库存、促销、清仓节奏进行销售与触达 |\n\n#### 4.3.3 字段规划\n\n| 字段 | 说明 |\n|---|---|\n| 产品名 | 产品展示名称 |\n| 国家 | 销售国家或市场 |\n| 品牌 | 所属品牌 |\n| 对应人员 | 负责该产品或站点的运营人员 |\n| 二级类目 | 产品所属二级类目 |\n| ASIN | 亚马逊 ASIN |\n| 产品类型 | 新品、重点产品、清仓产品 |\n| 各站点销量 | 各亚马逊站点销量，详细数据涉密 |\n| 总销量 | 汇总销量 |\n| APP 绑定数 | APP 可识别的、已绑定指定玩具的用户数 |\n| 绑定率 | APP 可识别的绑定了指定玩具的用户数 / 销售数 |\n| 异常状态 | 是否出现销量异常、绑定率异常、数据缺失等 |\n| 异常原因 | 异常说明或系统识别原因 |\n| 最近更新时间 | 数据刷新时间 |\n\n#### 4.3.4 重点指标\n\n- 产品销量\n- APP 绑定数\n- APP 绑定率\n- 新品绑定率爬坡情况\n- 重点产品绑定率\n- 清仓产品触达与绑定情况\n- 低绑定率产品列表\n- 异常站点/异常国家/异常类目\n\n#### 4.3.5 异常报警建议\n\n| 异常类型 | 触发逻辑 |\n|---|---|\n| 绑定率过低 | 产品销量正常，但 APP 绑定率低于目标值 |\n| 销量异常波动 | 单日或单周销量较基准值显著上升或下降 |\n| 站点数据缺失 | 某国家/站点销量或绑定数据未同步 |\n| 新品启动异常 | 新品有销量但绑定数或评价启动明显滞后 |\n| 重点产品风险 | S 级或重点产品绑定率、评价数、评分低于目标 |\n\n### 4.4 独立看板二：推新计划与 APP 推送资源分配看板\n\n#### 4.4.1 看板目标\n\n用于管理亚马逊推新计划和 APP 内现有推送资源之间的配合关系。\n\n推新计划的核心是关键词相关的重点产品推广，尤其是当期周度、月度重点产品，如 S 级产品。\n\nAPP 侧需要根据现有用户资源，在 APP 内用户中进行定向推送、曝光、点击、回复、登记和评价转化跟踪。\n\n#### 4.4.2 推新业务结构\n\n| 层级 | 内容 |\n|---|---|\n| 当期重点产品 | 周度、月度重点产品表，例如 S 级产品 |\n| 关键词策略 | 每个重点产品关联的关键词方向 |\n| 推新算法 | 基于产品重要级、用户资源、活跃度、绑定数、历史效果进行推送分配 |\n| APP 推送资源 | APP 内用户、社区消息、广告位、图片点击、活动曝光等 |\n| 效果回收 | 曝光、点击、回复、登记、评价、回评 |\n\n#### 4.4.3 字段规划\n\n| 字段 | 说明 |\n|---|---|\n| 产品名 | 推新产品名称 |\n| ASIN | 对应亚马逊 ASIN |\n| 产品重要级 | 如 S 级、A级、普通等 |\n| 关键词 | 推新关联关键词 |\n| 推送方案 | 当前采用的推送策略或资源组合 |\n| 推送 ID | APP 内推送任务 ID |\n| 关联图片点击率 | 推送图片或关联素材点击率 |\n| 产品绑定数 | 已绑定该产品的用户数 |\n| 总用户数 | APP 总用户数或目标用户池总数 |\n| 当月活跃用户数 | 当月活跃用户规模 |\n| 当月活跃率 | 当月活跃用户数 / 总用户数 |\n| 推送数 | 实际推送数量 |\n| 曝光数 | 用户实际看到的曝光数量 |\n| 点击数 | 用户点击数量 |\n| 回复数 | 用户回复数量 |\n| 登记数 | 用户登记或报名数量 |\n| 评价数 | 最终产生的评价数量 |\n| 回评数 | 最终产生的回评数量 |\n| 推送状态 | 未开始、进行中、已结束、暂停、异常 |\n| 负责人 | 推新或推送负责人 |\n\n#### 4.4.4 核心计算指标\n\n- 曝光率 = 曝光数 / 推送数\n- 点击率 = 点击数 / 曝光数\n- 回复率 = 回复数 / 点击数\n- 登记率 = 登记数 / 点击数\n- 评价转化率 = 评价数 / 登记数\n- 回评转化率 = 回评数 / 评价数\n- 活跃用户覆盖率 = 推送数 / 当月活跃用户数\n\n#### 4.4.5 当前推新资源分配口径\n\n当前推新计划先采用基础规则，后续逐步引入模型。\n\n现阶段基本逻辑：\n\n- S 级产品需求需要最大程度满足。\n- 当前流量池预计约 50% 分配给核心 S 级产品。\n- A 级、B 级及其他产品共同占用剩余约 50% 流量。\n- 产品数量比例上，S 级约 10 来个，其他产品约 200 来个。\n- 后续建议计划需要综合关键词需求、GEO 需求、销量、产品重要级和突发事件生成。\n\n### 4.5 独立看板三：测评计划与免评计划看板\n\n#### 4.5.1 看板目标\n\n用于管理亚马逊运营、用户运营与品牌运营协同的核心评价业务，包括测评计划和免评计划。\n\n协作关系：\n\n- 亚马逊运营：根据亚马逊销售需求提出测评计划、免评计划和回评目标。\n- 用户运营：负责实际触达、推送、登记、索评、回评跟进和结果回收。\n- 品牌运营：由于了解亚马逊运营需求，参与协同对接，但不是实际执行主责方。\n\n其中：\n\n- 测评计划：主要用于新品、重点产品的评价启动、评价数量建设和关键词推广配合。\n- 免评计划：主要基于关键词和实时销量策略进行定时下单，当前主要承接补单诉求。\n\n#### 4.5.2 字段规划\n\n| 字段 | 说明 |\n|---|---|\n| 计划 ID | 测评或免评计划唯一标识 |\n| 计划类型 | 测评计划、免评计划 |\n| 产品名 | 关联产品 |\n| ASIN | 关联 ASIN |\n| 国家/站点 | 亚马逊站点 |\n| 品牌 | 所属品牌 |\n| 产品类型 | 新品、重点、清仓 |\n| 产品重要级 | S 级、A级等 |\n| 关键词 | 计划关联关键词 |\n| 计划周期 | 周、月或指定活动周期 |\n| 计划数量 | 计划执行数量 |\n| 实际完成数量 | 已完成数量 |\n| 完成率 | 实际完成数量 / 计划数量 |\n| APP 配合方式 | 推送、广告位、社区触达、客服触达等 |\n| 风险等级 | 低、中、高 |\n| 审批状态 | 待审批、已审批、执行中、已结束、暂停 |\n| 负责人 | 亚马逊运营负责人 |\n| 协同负责人 | APP 或用户运营负责人 |\n\n#### 4.5.3 审批流口径\n\n测评计划、回评计划、免评计划需要建立审批流。\n\n流程口径：\n\n1. 亚马逊运营提出测评、回评、免评计划。\n2. 亚马逊运营总监审批确认。\n3. 审批通过后进入用户运营执行排期。\n4. 用户运营根据用户池、渠道资源和频控规则制定可执行计划。\n\n#### 4.5.4 风险说明\n\n免评计划、补单诉求、返现或强索评相关动作应进入风险管理与审批机制，不能只作为普通运营动作处理。\n\n建议后续单独规划：\n\n- 合规风险字段\n- 审批流\n- ASIN 风险状态\n- 账号风险状态\n- 高风险动作留痕\n\n### 4.6 独立看板四：回评计划与 ASIN 评价健康度看板\n\n#### 4.6.1 看板目标\n\n用于保障亚马逊链接的评价数和评分等级，尤其是新品爆款周期内，需要评价数量和评价等级与销售节奏匹配。\n\n核心目标：\n\n- 保障链接评价数\n- 保障评分等级\n- 支撑新品爆款周期\n- 识别 ASIN 评价健康风险\n- 区分新品、重点产品、清仓产品的回评需求\n\n#### 4.6.2 评价健康标准\n\n当前业务描述中的核心标准：\n\n- 评价数要与新品爆款周期匹配，原则上数量要多。\n- 评价等级需要维持在较高水平。\n- 新品或爆款产品期望评价等级原则上应达到 4.8 以上。\n- 4.8 属于很健康。\n- 4.5 属于健康。\n- 4.2 属于高风险，需要加强对未回评用户的回评推送。\n\n#### 4.6.3 字段规划\n\n| 字段 | 说明 |\n|---|---|\n| ASIN | 亚马逊 ASIN |\n| 产品名 | 产品名称 |\n| 国家/站点 | 销售国家或亚马逊站点 |\n| 品牌 | 所属品牌 |\n| 产品类型 | 新品、重点、清仓 |\n| 产品重要级 | S 级、A级等 |\n| 当月计划回评数 | 当月计划获得的回评数量 |\n| 实际回评数 | 当月实际回评数量 |\n| 回评完成率 | 实际回评数 / 当月计划回评数 |\n| 期望评价等级 | 目标评分等级 |\n| 实际评价等级 | 当前实际评分等级 |\n| 当前评价数 | 当前累计评价数量 |\n| 当月新增评价数 | 当月新增评价数量 |\n| 差评数 | 当前或当月差评数量 |\n| 差评率 | 差评数 / 评价数 |\n| 健康状态 | 健康、关注、风险、严重风险 |\n| 负责人 | ASIN 负责人 |\n\n#### 4.6.4 产品类型下的回评管理\n\n| 产品类型 | 回评管理重点 |\n|---|---|\n| 新品 | 评价启动速度、评价数量爬坡、评分稳定性、爆款周期匹配 |\n| 重点产品 | 评分等级维护、差评预警、持续回评目标达成 |\n| 清仓产品 | 根据清仓节奏决定是否继续投入回评资源，避免资源浪费 |\n\n#### 4.6.5 ASIN 评价健康等级\n\n| 实际评价等级 | 健康状态 | 处理建议 |\n|---|---|---|\n| 4.8 及以上 | 很健康 | 维持正常回评节奏，重点保障新品爆款周期 |\n| 4.5-4.79 | 健康 | 保持监控，按计划推进回评 |\n| 4.2-4.49 | 高风险 | 加强对未回评用户的回评推送 |\n| 低于 4.2 | 严重风险 | 需要升级处理，结合客服、用户运营和亚马逊运营共同干预 |\n\n### 4.7 亚马逊运营协同品牌推广计划\n\n品牌推广计划由亚马逊运营与品牌运营协同完成。\n\n除亚马逊站内的品牌承接和销售动作外，以下工作以品牌运营为主进行决策，亚马逊运营同步即可：\n\n- JOYHUB 内推广\n- 社媒互动\n- 新品宣发\n- 活动宣发\n- 粉丝互动管理\n- 销售管理\n- 独立站推广\n- 新品推广\n- 社媒数据\n- KOL 互动数据\n\n#### 4.7.1 品牌推广协同数据\n\n| 字段 | 说明 |\n|---|---|\n| 推广计划 ID | 品牌推广计划唯一标识 |\n| 推广类型 | JOYHUB、社媒、新品宣发、活动宣发、KOL、独立站等 |\n| 产品名 | 关联产品 |\n| ASIN | 关联 ASIN |\n| 品牌 | 所属品牌 |\n| 国家 | 推广国家 |\n| 渠道 | 推广渠道 |\n| 曝光数 | 推广曝光 |\n| 点击数 | 推广点击 |\n| 跳转数 | 跳转到亚马逊或独立站的数量 |\n| 转化数 | 产生转化数量 |\n| 成交数 | 产生订单数量 |\n| 互动数 | 点赞、评论、私信、粉丝互动等 |\n| KOL 信息 | 合作达人或账号 |\n| 负责人 | 推广负责人 |\n\n## 5. 第二部分：品牌运营相关业务\n\n### 5.1 品牌运营在闭环中的定位\n\n品牌运营与亚马逊运营不在同一个办公区，但需要协助亚马逊运营共同建立销售体系。\n\n品牌运营的核心定位是：\n\n1. 负责独立站品牌宣发。\n2. 负责在社媒建立品牌形象。\n3. 负责独立站成交与品牌侧销售管理。\n4. 协助亚马逊运营在亚马逊平台上提高品牌调性。\n5. 协助亚马逊运营扩大品牌在亚马逊上的市场份额。\n6. 与亚马逊运营共同参与品牌推广计划。\n7. 在亚马逊站外品牌推广相关事项上，品牌运营为主责决策方，亚马逊运营同步。\n\n### 5.2 品牌运营与亚马逊运营的分工边界\n\n| 业务事项 | 主责方 | 协同方 | 说明 |\n|---|---|---|---|\n| 亚马逊站内销售 | 亚马逊运营 | 品牌运营 | 品牌运营协助提高品牌调性和市场份额 |\n| 亚马逊站内品牌承接 | 亚马逊运营 | 品牌运营 | Listing、品牌内容、品牌调性需要双方协同 |\n| 独立站品牌宣发 | 品牌运营 | 亚马逊运营同步 | 独立站推广和转化由品牌运营主责 |\n| 独立站成交 | 品牌运营 | 亚马逊运营同步 | 独立站销售数由品牌运营负责 |\n| 社媒品牌形象 | 品牌运营 | 亚马逊运营同步 | 包含账号内容、互动、粉丝维护 |\n| JOYHUB 内推广 | 品牌运营 | 亚马逊运营同步 | 实际为品牌运营工作，亚马逊运营了解进度 |\n| 新品宣发 | 品牌运营 | 亚马逊运营同步 | 站外宣发主责在品牌运营 |\n| 活动宣发 | 品牌运营 | 亚马逊运营同步 | 活动口径需要与销售节奏同步 |\n| 粉丝互动管理 | 品牌运营 | 亚马逊运营同步 | 社媒与品牌用户关系维护 |\n| KOL 互动 | 品牌运营 | 亚马逊运营同步 | KOL 数据和互动效果由品牌运营负责 |\n| AMZ 测评计划 | 亚马逊运营、用户运营 | 品牌运营协同 | 亚马逊运营提需求，用户运营实现，品牌运营参与协同 |\n| 回评计划 | 亚马逊运营、用户运营 | 品牌运营协同 | 主要服务 ASIN 评价健康度 |\n\n### 5.3 品牌运营核心业务模块\n\n| 模块 | 业务内容 | 输出 |\n|---|---|---|\n| 品牌宣发 | 独立站、社媒、JOYHUB、新品、活动等品牌曝光 | 品牌推广计划、宣发内容、渠道效果 |\n| 社媒运营 | 建立品牌形象、粉丝互动、社媒内容发布 | 社媒访问、点击、互动、转化数据 |\n| 独立站推广 | 独立站访问、点击、转化、成交管理 | 独立站销售数、转化漏斗 |\n| 新品推广 | 新品宣发、站外曝光、内容传播 | 新品推广数据、用户兴趣数据 |\n| 活动推广 | 活动宣发、活动页面、粉丝触达 | 活动曝光、点击、转化、成交 |\n| KOL 合作 | KOL 互动、达人合作、内容发布 | KOL 互动数据、访问与转化效果 |\n| 品牌销售管理 | 独立站成交、品牌侧销售数据管理 | 销售数、成交数、转化数 |\n| 亚马逊协同 | 协助亚马逊提升品牌调性和市场份额 | 品牌素材、推广节奏、协同反馈 |\n\n### 5.4 独立看板五：品牌影响力与独立站销售看板\n\n#### 5.4.1 看板目标\n\n用于衡量品牌运营在独立站、社媒、JOYHUB、KOL、新品宣发和活动宣发等渠道中的影响力、转化效果和销售结果。\n\n该看板以品牌运营为主责，亚马逊运营同步查看，用于判断站外品牌推广对亚马逊销售和独立站销售的辅助效果。\n\n#### 5.4.2 字段规划\n\n| 字段 | 说明 |\n|---|---|\n| 品牌 | 所属品牌 |\n| 国家 | 推广国家或市场 |\n| 渠道来源 | 独立站、社媒、JOYHUB、KOL、新品宣发、活动宣发等 |\n| 推广类型 | 新品、活动、日常内容、KOL、粉丝互动等 |\n| 产品名 | 关联产品 |\n| ASIN | 如有关联亚马逊产品，则记录 ASIN |\n| 负责人 | 品牌运营负责人 |\n| 访问数 | 各来源访问量 |\n| 点击数 | 各来源点击量 |\n| 转化数 | 各来源转化数量 |\n| 销售数 | 独立站或品牌侧销售数量，由品牌运营负责 |\n| 成交数 | 实际成交订单数量 |\n| 互动数 | 点赞、评论、分享、私信、粉丝互动等 |\n| KOL 信息 | 合作达人或账号信息 |\n| 内容/活动 ID | 关联内容、活动或投放任务 |\n| 跳转目标 | 亚马逊、独立站、APP、活动页等 |\n| 数据周期 | 日、周、月、活动周期 |\n\n#### 5.4.3 核心指标\n\n- 访问数\n- 点击数\n- 转化数\n- 销售数\n- 成交数\n- 社媒互动数\n- KOL 互动数据\n- 独立站转化率\n- 渠道访问贡献\n- 品牌活动转化效果\n\n#### 5.4.4 品牌影响力评估口径\n\n品牌影响力从两方面评估：\n\n1. 各渠道转化，包括独立站转化、亚马逊跳转转化、APP 承接转化等。\n2. 社媒影响力与调研反馈，包括互动、评论、粉丝反馈和品牌认知反馈。\n\n通过品牌活动前往亚马逊形成的转化，也归属品牌运营 OKR 结果。\n\n### 5.5 独立看板六：品牌推广计划协同看板\n\n#### 5.5.1 看板目标\n\n用于管理品牌运营与亚马逊运营共同参与的品牌推广计划。\n\n该看板需要明确：\n\n- 品牌运营在站外推广中的主责地位\n- 亚马逊运营在亚马逊站内承接品牌调性与销售转化的职责\n- 品牌推广与亚马逊销售、独立站销售、APP 用户增长之间的关系\n- 品牌推广计划与 AMZ 测评计划之间的协同关系\n\n#### 5.5.2 字段规划\n\n| 字段 | 说明 |\n|---|---|\n| 推广计划 ID | 品牌推广计划唯一标识 |\n| 推广计划名称 | 计划名称 |\n| 主责部门 | 品牌运营 |\n| 协同部门 | 亚马逊运营、用户运营、内容运营等 |\n| 推广类型 | JOYHUB、社媒、新品宣发、活动宣发、KOL、独立站等 |\n| 品牌 | 所属品牌 |\n| 国家 | 推广国家 |\n| 产品名 | 关联产品 |\n| ASIN | 关联亚马逊 ASIN |\n| 独立站链接 | 独立站承接地址 |\n| 亚马逊链接 | 亚马逊承接地址 |\n| APP 承接方式 | 是否需要 APP 内承接、推送或活动页 |\n| 计划开始时间 | 推广开始时间 |\n| 计划结束时间 | 推广结束时间 |\n| 预算 | 推广预算 |\n| 访问数 | 推广访问量 |\n| 点击数 | 推广点击量 |\n| 转化数 | 推广转化数量 |\n| 销售数 | 品牌侧销售数量 |\n| 成交数 | 实际成交订单 |\n| 亚马逊同步状态 | 未同步、已同步、需调整 |\n| 计划状态 | 草稿、待确认、执行中、已结束、暂停 |\n\n### 5.6 品牌运营参与 AMZ 测评计划的协作关系\n\nAMZ 测评计划由三方协作完成：\n\n| 角色 | 职责 |\n|---|---|\n| 亚马逊运营 | 根据亚马逊平台销售需求提出测评计划、回评计划、关键词和产品优先级需求 |\n| 品牌运营 | 理解并同步亚马逊运营需求，协同亚马逊运营与用户运营对接 |\n| 用户运营 | 负责实际实现，包括用户触达、推送、登记、索评、回评跟进和结果反馈 |\n\n需要明确的是：\n\n- 测评计划和回评计划的主要协作方是亚马逊运营与用户运营。\n- 品牌运营参与协同，但不是实际落地执行主责方。\n- 品牌运营的核心主责仍然是品牌宣发、社媒品牌形象、独立站成交和站外推广管理。\n\n### 5.7 APP 内资源协同边界\n\n| 资源类型 | 管理分配方 | 品牌运营角色 |\n|---|---|---|\n| APP 内社区资源 | 内容运营分配，品牌运营与内容运营协同 | 将亚马逊运营和品牌运营需求与内容运营协商 |\n| 用户推送资源 | 用户运营管理分配 | 将亚马逊运营和品牌运营需求与用户运营协商 |\n\n品牌运营熟悉内容运营和用户运营两侧资源，负责把亚马逊运营需求和品牌运营自身需求同步给相关部门，并推动协商解决。\n\n### 5.8 品牌运营与其他部门的数据关系\n\n| 数据流向 | 内容 | 用途 |\n|---|---|---|\n| 品牌运营 → 亚马逊运营 | 品牌推广计划、社媒/KOL 数据、新品宣发节奏、活动宣发数据 | 帮助亚马逊站内承接品牌调性和销售转化 |\n| 亚马逊运营 → 品牌运营 | 亚马逊销售需求、重点 ASIN、推新节奏、测评需求、关键词方向 | 品牌运营理解销售重点并做站外协同 |\n| 品牌运营 → 用户运营 | 推广计划、活动节奏、需要 APP 承接的用户触达需求 | APP 内推送、活动承接、用户触达 |\n| 用户运营 → 品牌运营 | APP 用户反馈、触达数据、活动参与、评价反馈 | 优化品牌内容和活动策略 |\n| 品牌运营 → 数据层/管理层 | 访问、点击、转化、销售数、互动数、KOL 数据 | 品牌影响力、渠道 ROI、独立站销售复盘 |\n\n## 6. 第三部分：用户运营相关业务\n\n### 6.1 用户运营在闭环中的定位\n\n用户运营是该系统的核心使用者。客服部门实际也归属用户部门管理。\n\n用户运营的核心定位是：\n\n1. 接收亚马逊运营与品牌运营协同后的销售数据和测评需求。\n2. 根据关键词、销量、产品重要级、ASIN 评价健康度共同制定可执行的测评计划。\n3. 基于 APP 用户、绑定用户、活跃用户、社区用户、非 APP 或低活跃用户进行分层触达。\n4. 在社区中与用户互动，鼓励测评人参与。\n5. 负责推送、登记、索评、回评跟进和结果回收。\n6. 按 ASIN 评价健康度动态调整触达资源和回评节奏。\n7. 管理 TEL、EDM、KOC/KOL/PR、短信、社区、非评价推送等多渠道触达。\n8. 管理客服售后相关执行数据，并将售后反馈纳入触达策略优化。\n\n### 6.2 用户运营核心业务模块\n\n| 模块 | 业务内容 | 输出 |\n|---|---|---|\n| 测评计划执行 | 根据亚马逊销售需求、关键词、销量、产品重要级制定可执行测评计划 | 推送计划、登记数据、评价数、计划完成度 |\n| 用户社区互动 | 在 APP 社区中与用户互动，鼓励用户参与新玩具测评 | 回复数、登记数、评价数 |\n| 回评计划跟进 | 根据 ASIN 评价健康度跟进回评目标 | 回评完成度、风险等级、ASIN 健康状态 |\n| IM 社区消息推送 | 推动新玩具购买与买后索评 | 曝光、点击、回复、登记、出评 |\n| 已成交索评 | 针对已绑定、已购买玩具的用户进行索评 | 实际回评数、评价等级改善 |\n| TEL 电话售后 | 接听售后和呼出电话 | 接听售后数据、呼出数据、售后原因 |\n| EDM 邮件推送 | 针对非 APP 或低 APP 活跃用户进行邮件触达 | 打开、点击、回复、转化 |\n| KOC/KOL/PR 合作 | 通过 JOYCOLLAB 网站管理合作伙伴体系 | 合作伙伴效果、带货链接、销售与提成数据 |\n| 其他触达渠道 | 短信、社区、非评价推送等仍在搭建中的渠道 | 新增测评渠道、内容改善、用户反感度控制 |\n\n### 6.3 测评计划执行数据\n\n用户运营根据亚马逊运营和品牌运营协同后的需求，结合销售数据、关键词和销量生成可执行的测评计划。\n\n测评计划的关键是把“销售侧需求”转化为“用户侧可执行动作”。\n\n#### 6.3.1 字段规划\n\n| 字段 | 说明 |\n|---|---|\n| 产品名 | 关联产品 |\n| ASIN | 亚马逊 ASIN |\n| 产品重要级 | S 级、重点、普通等 |\n| 关键词 | 亚马逊运营提出的关键词方向 |\n| 推送方案 | 用户运营制定的触达策略 |\n| 推送 ID | 推送任务唯一标识 |\n| 关联图片点击率 | 推送图片或素材点击率 |\n| 产品绑定数 | 已绑定该产品的用户数 |\n| 总用户数 | 可触达用户总数 |\n| 当月活跃用户数 | 当月活跃用户规模 |\n| 当月活跃率 | 当月活跃用户数 / 总用户数 |\n| 推送数 | 实际推送数量 |\n| 曝光数 | 实际曝光数量 |\n| 点击数 | 实际点击数量 |\n| 回复数 | 用户回复数量 |\n| 登记数 | 用户报名、登记或确认参与数量 |\n| 评价数 | 最终产生的评价数量 |\n\n### 6.4 ASIN 评价健康度与回评计划\n\n用户运营需要根据随时更新的 Listing 健康状况和 ASIN 评价健康度跟进回评计划。\n\n核心原则：\n\n- 新品爆款周期需要与评价数量和评价等级匹配。\n- 新品和爆款原则上评价数量要多。\n- 新品和爆款的期望评价等级原则上应达到 4.8 以上。\n- 常规产品需要保障链接评价数和评分等级。\n- 回评计划需要区分新品、重点产品、清仓产品。\n\n#### 6.4.1 字段规划\n\n| 字段 | 说明 |\n|---|---|\n| ASIN | 亚马逊 ASIN |\n| 产品名 | 关联产品 |\n| 产品类型 | 新品、重点、清仓 |\n| 当月计划回评数 | 当月计划回评数量 |\n| 实际回评数 | 当月实际完成回评数量 |\n| 期望评价等级 | 目标评价等级 |\n| 实际评价等级 | 当前实际评价等级 |\n| 回评完成率 | 实际回评数 / 当月计划回评数 |\n| 风险等级 | 健康、关注、风险、严重风险 |\n| 跟进人 | 用户运营负责人 |\n\n### 6.5 独立看板七：IM 社区消息推送计划看板\n\n#### 6.5.1 业务场景\n\nIM 社区消息推送主要用于推动新玩具测评。\n\n当用户没有购买我们想推动的新玩具时，用户运营通过 IM 社区消息推送促使用户购买新玩具，并在购买后进行索评。\n\n#### 6.5.2 看板目标\n\n按地区、品牌、类目、策略观察不同推送计划的效果。\n\n#### 6.5.3 字段规划\n\n| 字段 | 说明 |\n|---|---|\n| 推送 ID | 推送任务唯一标识 |\n| 关联产品 | 推送关联产品 |\n| ASIN | 关联 ASIN |\n| 国家/地区 | 推送覆盖地区 |\n| 品牌 | 所属品牌 |\n| 类目 | 产品类目 |\n| 策略 | 推送策略 |\n| 曝光 | 推送曝光数 |\n| 点击 | 用户点击数 |\n| 回复 | 用户回复数 |\n| 登记 | 用户登记数 |\n| 出评 | 最终产生评价数 |\n| 转化率 | 出评或登记转化率 |\n| 计划完成度 | 实际完成 / 计划目标 |\n| 订单号 | 订单号，含亚马逊来源和独立站来源，涉密字段 |\n| 订单来源 | 亚马逊、独立站等 |\n| profile ID | 用户 Profile 标识，涉密字段 |\n| joyhub ID | JOYHUB 用户标识，涉密字段 |\n\n### 6.6 独立看板八：已成交索评与回评计划完成度看板\n\n#### 6.6.1 业务场景\n\n当用户已经绑定某个玩具时，APP 能识别用户购买了哪个玩具。用户运营可以针对已有玩具进行已成交索评。\n\n该看板与 ASIN 评价健康度直接关联，用于确保亚马逊链接健康。\n\n#### 6.6.2 字段规划\n\n| 字段 | 说明 |\n|---|---|\n| 产品类型 | 新品、重点、清仓 |\n| 产品名 | 关联产品 |\n| ASIN | 关联 ASIN |\n| 产品计划回评数 | 当前产品计划回评数量 |\n| 实际回评数 | 当前产品实际回评数量 |\n| 回评完成率 | 实际回评数 / 产品计划回评数 |\n| 当前 ASIN 评价等级 | 当前 ASIN 星级或评分 |\n| 风险等级 | 健康、关注、风险、严重风险 |\n| 负责人 | 用户运营负责人 |\n\n### 6.7 独立看板九：TEL 电话售后渠道看板\n\n#### 6.7.1 业务场景\n\nTEL 电话售后渠道包括接听售后和呼出电话，主要用于改善服务、收集售后问题、支撑索评和降低负面反馈。\n\n#### 6.7.2 字段规划\n\n| 字段 | 说明 |\n|---|---|\n| 电话号码 | 高度涉密字段 |\n| 国家 | 用户国家 |\n| 品牌 | 关联品牌 |\n| 产品 | 关联产品 |\n| 售后原因 | 用户咨询或售后原因 |\n| 呼出数 | 呼出电话数量 |\n| 接听数 | 接听电话数量 |\n| 订单号 | 涉密字段 |\n| 跟进人 | 客服或用户运营负责人 |\n| 处理状态 | 待处理、处理中、已完结、需升级 |\n\n### 6.8 独立看板十：EDM 邮件推送渠道看板\n\n#### 6.8.1 业务场景\n\nEDM 邮件推送主要面向非 APP 用户或低 APP 活跃用户，用于补充 APP 内推送触达能力。\n\n#### 6.8.2 看板目标\n\n用于持续改善 EDM 计划，包括邮件打开、点击、回复和转化效果。\n\n#### 6.8.3 字段规划\n\n| 字段 | 说明 |\n|---|---|\n| 国家 | 用户国家 |\n| 地区 | 用户地区 |\n| 邮件服务商 | 邮件服务商 |\n| 用户邮箱 | 高度涉密字段 |\n| USER ID | 非 APP 用户 ID |\n| 推送 ID | EDM 推送任务 ID |\n| 点击数 | 邮件点击数量 |\n| 打开数 | 邮件打开数量 |\n| 回复数 | 邮件回复数量 |\n| 转化数 | 由邮件触达带来的转化数量 |\n| 计划状态 | 草稿、执行中、已结束、异常 |\n\n### 6.9 独立看板十一：KOC/KOL/PR 合作伙伴效果看板\n\n#### 6.9.1 业务场景\n\nKOC、KOL、PR 渠道用于合作伙伴对接和带货推广。合作伙伴体系通过 JOYCOLLAB 网站承接。\n\nKOC 在 JOYCOLLAB 上的带货数据原则上先在 JOYCOLLAB 网站内处理，再同步到大用户后台。财务也会参与销售数据、提成数据和交易金额的核算或校验。\n\n#### 6.9.2 看板目标\n\n用于改善合作伙伴效果，观察合作伙伴在不同国家、平台、产品和带货链路上的实际贡献。\n\n#### 6.9.3 字段规划\n\n| 字段 | 说明 |\n|---|---|\n| 合作伙伴 ID | 合作伙伴唯一标识 |\n| 国家 | 合作伙伴所在国家 |\n| 姓名 | 合作伙伴姓名，涉密字段 |\n| 时间 | 合作或跟进时间 |\n| 平台 | 合作平台 |\n| 粉丝 | 粉丝数量或粉丝规模 |\n| 备注 | 合作备注 |\n| 跟进人 | 用户运营或合作伙伴负责人 |\n| 合作产品 | 合作推广产品 |\n| 带货链接 | 合作伙伴带货链接 |\n| 销售数据 | 通过带货链接产生的销售数据 |\n| 提成数据 | 合作伙伴提成数据，涉密字段 |\n| 交易金额 | 产生的交易金额 |\n\n### 6.10 其他触达渠道\n\n其他渠道包括：\n\n- 短信\n- 社区\n- 非评价推送\n\n这些渠道仍在搭建当中，目标包括：\n\n1. 继续增加测评渠道。\n2. 改善内容触达效果。\n3. 降低用户对高频推送、索评、活动通知的反感。\n4. 为非评价类推送沉淀策略，例如活动、内容、售后提醒、品牌互动。\n\n### 6.11 用户识别、黑名单与频控口径\n\n#### 6.11.1 用户识别主标识\n\n订单号和 JOYHUB ID 是用户索评与黑名单查询中的两个主要标识。\n\n订单号包括：\n\n- 亚马逊来源订单号\n- 独立站来源订单号\n\n当用户注册后，必然有 JOYHUB ID。 \n当用户提供订单号时，JOYHUB ID 和订单号建立关联。\n\nAPP 侧还会保留注册邮箱、用户基础 IP、设备号、用户行为数据等信息。订单号可以关联用户地址、姓名、用户名等信息。\n\n#### 6.11.2 邮箱、账号与风险关联\n\n注册用户的 JOYHUB ID 和邮箱必然关联。部分用户可能使用多个邮箱注册多个账号，每个账号都有独立 JOYHUB ID。\n\n系统需要通过 IP、设备号等信息做黑名单关联。关联后，多个账号可被认定为关联账号，或在后台被划入高度风险关联，并按单一用户处理。\n\n#### 6.11.3 多渠道统一频控\n\nTEL、EDM、IM、社区、短信等渠道需要统一控制触达频率，并统一了解对用户的骚扰程度，避免过于频繁触达导致用户反感。\n\n### 6.12 用户运营与其他部门的数据关系\n\n| 数据流向 | 内容 | 用途 |\n|---|---|---|\n| 亚马逊运营 → 用户运营 | 销售数据、关键词、重点产品、测评需求、回评目标、ASIN 健康状态 | 制定可执行测评计划和回评计划 |\n| 品牌运营 → 用户运营 | 品牌推广计划、活动节奏、站外触达需求、APP 承接需求 | 配合品牌推广进行 APP 内触达 |\n| 用户运营 → 亚马逊运营 | 推送效果、登记数、评价数、回评数、ASIN 风险反馈 | 调整测评计划、推新计划和评价健康策略 |\n| 用户运营 → 品牌运营 | 用户反馈、触达效果、活动参与、转化结果 | 优化品牌内容、活动和独立站推广 |\n| 用户运营 → 客服运营 | 待跟进用户、售后触达需求、负面反馈线索 | 电话售后、问题处理和服务改善 |\n| 客服运营 → 用户运营 | 接听售后数据、呼出数据、售后原因、处理结果 | 优化推送策略、索评节奏和用户分层 |\n| 用户运营 → 数据层/管理层 | 推送、登记、评价、回评、TEL、EDM、合作伙伴数据 | 复盘渠道效果、人效、成本和风险 |\n\n## 7. 第四部分：菲律宾客服相关业务\n\n### 7.1 菲律宾客服在闭环中的定位\n\n菲律宾客服直接接受用户运营指导工作。\n\n当亚马逊运营存在短期需求变动时，不直接绕过用户运营调整客服工作，而是通过用户运营转达和排期。这样可以保证测评计划、回评计划、售后触达、人员安排和成本统计在同一套用户运营口径下管理。\n\n菲律宾客服的核心定位是：\n\n1. 执行用户运营下发的评价、登记、回复、售后跟进等具体任务。\n2. 承接各渠道用户接待与基础沟通。\n3. 配合评价计划落地，提升评价转化和完结评价数。\n4. 反馈客服侧接待、登记、回复、完结情况。\n5. 支撑用户运营进行成本管理、人效管理和渠道效果复盘。\n\n### 7.2 核心指标\n\n| 指标 | 说明 |\n|---|---|\n| 客源 | 来自不同渠道的用户来源或待处理线索 |\n| 转化数 | 从接待、登记、回复到评价完成的转化数量 |\n| 转化率 | 评价转化数 / 客源或登记数 |\n| 节约成本 | 通过客服执行、人效提升、渠道优化节约的成本 |\n\n### 7.3 独立看板十二：菲律宾客服人员管理看板\n\n#### 7.3.1 看板目标\n\n用于管理菲律宾客服人员、出勤、每日工作量和各渠道执行情况。\n\n#### 7.3.2 字段规划\n\n| 字段 | 说明 |\n|---|---|\n| 人员 | 客服人员姓名或账号 |\n| 团队/组别 | 所属客服小组 |\n| 出勤 | 出勤状态、出勤天数或工时 |\n| 日期 | 工作日期 |\n| 渠道 | IM、TEL、EDM、社区、KOC/KOL/PR、其他 |\n| 接待数 | 当日接待用户数量 |\n| 登记数 | 当日登记数量 |\n| 回复数 | 当日回复数量 |\n| 每日评价数 | 当日产生评价数量 |\n| 完结评价数 | 当日完结评价数量，按各渠道统计 |\n| 待处理数 | 尚未处理或未完结任务数量 |\n| 负责人 | 用户运营或客服主管 |\n\n### 7.4 独立看板十三：菲律宾客服评价计划管理看板\n\n#### 7.4.1 看板目标\n\n用于跟踪菲律宾客服执行评价计划的过程和结果，重点观察客源、登记、回复、出评和计划完成度。\n\n#### 7.4.2 字段规划\n\n| 字段 | 说明 |\n|---|---|\n| 评价计划 ID | 关联测评或回评计划 |\n| 推送 ID | 关联用户运营推送任务 |\n| 产品名 | 关联产品 |\n| ASIN | 关联 ASIN |\n| 产品类型 | 新品、重点、清仓 |\n| 渠道 | IM、TEL、EDM、社区、其他 |\n| 客源数 | 进入客服处理池的用户数量 |\n| 接待数 | 客服实际接待数量 |\n| 登记数 | 用户登记或确认参与数量 |\n| 回复数 | 用户回复数量 |\n| 每日评价数 | 每日产生评价数量 |\n| 完结评价数 | 完成闭环的评价数量 |\n| 转化数 | 从客源到评价完成的转化数量 |\n| 转化率 | 转化数 / 客源数或登记数 |\n| 计划完成度 | 实际完成 / 计划目标 |\n| 跟进人 | 菲律宾客服人员 |\n| 指导人 | 用户运营负责人 |\n\n### 7.5 独立看板十四：菲律宾客服成本管理看板\n\n#### 7.5.1 看板目标\n\n用于管理菲律宾客服相关人力成本、财务表和成本节约效果。\n\n#### 7.5.2 字段规划\n\n| 字段 | 说明 |\n|---|---|\n| 人员 | 客服人员 |\n| 出勤 | 出勤天数或工时 |\n| 人力成本 | 人员工资、补贴或对应成本 |\n| 提成 | 如存在评价、转化或完结相关提成，则单独记录 |\n| 管理成本 | 管理、培训、工具等分摊成本 |\n| 完结评价数 | 该人员或团队完成评价数量 |\n| 单评成本 | 总成本 / 完结评价数 |\n| 转化数 | 产生的有效转化数量 |\n| 单转化成本 | 总成本 / 转化数 |\n| 节约成本 | 因流程改善、人效提升或渠道优化节约的成本 |\n| 财务表 | 人事或财务表关联记录 |\n\n### 7.6 菲律宾客服与其他部门的数据关系\n\n| 数据流向 | 内容 | 用途 |\n|---|---|---|\n| 用户运营 → 菲律宾客服 | 评价计划、待跟进用户、推送任务、短期需求变动、售后跟进要求 | 指导客服执行 |\n| 菲律宾客服 → 用户运营 | 出勤、接待、登记、回复、每日评价、完结评价数、售后反馈 | 用户运营复盘渠道效果、人效和计划完成情况 |\n| 亚马逊运营 → 用户运营 → 菲律宾客服 | 亚马逊运营短期测评、回评或售后需求变动 | 通过用户运营统一转达，避免执行口径混乱 |\n| 菲律宾客服 → 数据层/管理层 | 人员、人效、评价转化、成本、财务表数据 | 成本管理、绩效评估和管理复盘 |\n\n## 8. 第五部分：内容运营相关业务\n\n### 8.1 内容运营在闭环中的定位\n\n内容运营在当前以用户运营为核心的业务需求中，主要负责配合亚马逊运营与品牌运营，在销售前期为产品做宣发和社区内流量承接。\n\n内容运营的核心定位是：\n\n1. 配合亚马逊运营和品牌运营做产品售前宣发。\n2. 管理 APP 内广告资源，包括开屏、弹窗、文末、ME、评论末等位置。\n3. 在社区内配合用户 KOC/KCO 对接，支持产品内容传播和测评前期预热。\n4. 执行售前社区广告计划。\n5. 通过推流管理提升重点产品、重点帖子、活动内容的曝光和点击。\n6. 管理加权、新帖、固定位置和固定流量池资源。\n7. 监控曝光、点击、打开、跳转、成交和互动数据，并识别风险。\n\n### 8.2 内容运营核心业务模块\n\n| 模块 | 业务内容 | 输出 |\n|---|---|---|\n| 售前社区广告计划 | 配合产品上市、活动、测评计划做社区前期宣发 | 广告计划、曝光、点击、跳转、成交数据 |\n| APP 广告管理 | 管理开屏、弹窗、文末、ME、评论末等广告位 | 广告位排期、用户行为数据、转化数据 |\n| 推流管理 | 对帖子加权、新帖扶持、固定位置投放、固定流量池管理 | 帖子曝光、点击、打开、互动、风险数据 |\n| KOC/KCO 对接 | 在社区中与用户或内容参与者对接 | 内容互动、测评预热、社区反馈 |\n| 风险识别 | 识别异常用户、异常互动、内容风险或投流风险 | 风险标记、处理建议 |\n\n### 8.3 独立看板十五：APP 广告管理看板\n\n#### 8.3.1 看板目标\n\n用于管理 APP 内广告位资源，支撑亚马逊运营和品牌运营在销售前期进行产品宣发、活动宣发和售前社区触达。\n\n广告位包括：\n\n- 开屏\n- 弹窗\n- 文末\n- ME\n- 评论末\n\n#### 8.3.2 字段规划\n\n| 字段 | 说明 |\n|---|---|\n| 月份 | 月度统计周期 |\n| 日期 | 每日统计周期 |\n| 产品 | 关联产品 |\n| ASIN | 如关联亚马逊产品，则记录 ASIN |\n| 品牌 | 所属品牌 |\n| 国家/地区 | 投放国家或地区 |\n| 广告位 | 开屏、弹窗、文末、ME、评论末等 |\n| 绑定情况 | 产品绑定用户数、绑定率或绑定状态 |\n| 用户行为 | 浏览、点击、打开、跳转、互动、购买等行为 |\n| 性别 | 用户性别 |\n| 其他标记用户数 | 风险用户、重点用户、异常用户或其他业务标记用户数 |\n| 曝光 | 广告曝光数 |\n| 点击 | 广告点击数 |\n| 打开 | 广告打开数 |\n| 跳转 | 跳转到产品页、亚马逊、独立站、活动页或 APP 页面数量 |\n| 成交数 | 由广告触达带来的成交数量 |\n| 负责人 | 内容运营负责人 |\n\n#### 8.3.3 核心指标\n\n- 曝光数\n- 点击数\n- 打开数\n- 跳转数\n- 成交数\n- 点击率\n- 打开率\n- 跳转率\n- 成交转化率\n- 不同广告位效果对比\n\n### 8.4 独立看板十六：推流管理看板\n\n#### 8.4.1 看板目标\n\n用于管理社区内容推流，包括帖子加权、新帖推流、固定位置和固定流量池。\n\n该看板服务于售前社区广告计划，帮助重点产品和重点内容获得更稳定的曝光与互动。\n\n#### 8.4.2 推流动作\n\n| 动作 | 说明 |\n|---|---|\n| 加权 | 对重点帖子或产品内容增加推荐权重 |\n| 新帖 | 对新发布内容进行启动流量扶持 |\n| 固定位置 | 将内容投放到指定社区位置 |\n| 固定流量池管理 | 管理固定流量池分配和资源占用 |\n\n#### 8.4.3 字段规划\n\n| 字段 | 说明 |\n|---|---|\n| 帖子 ID | 社区帖子唯一标识 |\n| 产品 | 关联产品 |\n| ASIN | 如关联亚马逊产品，则记录 ASIN |\n| 品牌 | 所属品牌 |\n| 发帖人属性 | 发帖人身份、用户类型、KOC/KCO、普通用户等 |\n| 帖子周期 | 新帖期、加权期、稳定期、结束期等 |\n| 投流等级 | 投流优先级或资源等级 |\n| 流量等级 | 实际分配的流量层级 |\n| 固定位置 | 是否使用固定位置及位置名称 |\n| 固定流量池 | 是否占用固定流量池及流量池名称 |\n| 曝光 | 帖子曝光数 |\n| 点击 | 帖子点击数 |\n| 打开 | 帖子打开数 |\n| 互动数 | 点赞、评论、收藏、分享、回复等互动总数 |\n| 各互动数 | 各类型互动明细 |\n| 风险 | 内容风险、用户风险、异常互动或投流风险 |\n| 负责人 | 内容运营负责人 |\n\n### 8.5 内容运营与其他部门的数据关系\n\n| 数据流向 | 内容 | 用途 |\n|---|---|---|\n| 亚马逊运营 → 内容运营 | 重点产品、ASIN、推新节奏、售前宣发需求、测评前期需求 | 安排社区广告和推流资源 |\n| 品牌运营 → 内容运营 | 品牌推广计划、新品宣发、活动宣发、素材与口径 | 统一品牌内容和社区投放 |\n| 用户运营 → 内容运营 | 用户触达节奏、测评计划、用户反馈、频控要求 | 避免内容触达与用户推送冲突 |\n| 内容运营 → 亚马逊运营/品牌运营 | 广告曝光、点击、打开、跳转、成交、帖子互动、风险数据 | 复盘售前宣发效果和销售辅助效果 |\n| 内容运营 → 数据层/管理层 | APP 广告、推流、互动、风险、成交归因数据 | 管理社区资源效率和内容投流效果 |\n\n## 9. 亚马逊运营与其他部门的数据关系\n\n| 数据流向 | 内容 | 用途 |\n|---|---|---|\n| 亚马逊运营 → APP/用户运营 | 销量、订单、ASIN、产品、国家、站点、成交用户 | 绑定率计算、用户触达、索评 |\n| APP/用户运营 → 亚马逊运营 | 绑定数、绑定率、活跃用户、推送效果、评价结果 | Listing/说明书/官网优化，评价计划调整 |\n| 亚马逊运营 → 评价运营 | 重点产品、推新计划、测评计划、回评目标 | 制定评价数量和评分维护策略 |\n| 评价运营 → 亚马逊运营 | 实际评价数、回评数、评分、差评、ASIN 健康状态 | 判断链接健康度和销售风险 |\n| 客服运营 → 亚马逊运营 | 售后问题、负面反馈、用户投诉、问题类型 | 优化产品、Listing、说明书和售后策略 |\n| 品牌/内容运营 → 亚马逊运营 | 品牌推广、内容曝光、社媒/KOL 数据 | 辅助亚马逊销售转化和新品启动 |\n\n## 10. 已确认问题与业务口径\n\n| 编号 | 已确认口径 | 后续影响 |\n|---|---|---|\n| Q1 | 绑定率 = APP 可识别的绑定了指定玩具的用户数 / 销售数。 | 绑定率看板按产品和 ASIN 计算。 |\n| Q2 | 支持在权限控制下查看明细，明细需要具体到每个 ASIN。 | 需要做 ASIN 级权限和涉密销量明细权限。 |\n| Q3 | S、A 级重要性由公司领导约 2-3 人和亚马逊核心总监确认，由用户运营指定人员维护。 | 产品重要级需要维护入口、确认记录和变更日志。 |\n| Q4 | 推新先用基础规则，后续逐步引入模型。当前 S 级需求最大程度满足，约 50% 流量给核心 S 级产品，其余 A/B 等产品共享约 50% 流量。 | 推新算法一期用规则引擎，二期再考虑模型。 |\n| Q5 | 测评、回评、免评计划需要审批流。亚马逊运营提出计划，亚马逊运营总监审批确认。 | 需要建立计划审批状态、审批人和审批记录。 |\n| Q6 | 4.8 很健康，4.5 健康，4.2 高风险；4.2 时需要加强对未回评用户的回评推送。 | ASIN 健康看板需要按评分阈值报警。 |\n| Q7 | 用户提供订单号时进行关联。APP 有 JOYHUB ID、注册邮箱、基础 IP、设备号、用户行为数据等；订单号可关联用户地址、姓名、用户名等。 | 用户识别需要订单号 + JOYHUB ID 双主标识，并保留辅助识别信息。 |\n| Q8 | 品牌影响力核心从两方面评估：各渠道转化、社媒影响力与调研反馈。 | 品牌看板需要同时支持转化数据和影响力反馈数据。 |\n| Q9 | 通过品牌活动前往亚马逊形成的转化，也归属品牌运营 OKR 结果。 | 销售归因需要支持品牌活动到亚马逊转化。 |\n| Q10 | APP 内社区资源由品牌运营与内容运营协同、内容运营分配；用户推送资源由用户运营管理分配。品牌运营负责将亚马逊和品牌需求与内容运营、用户运营协商解决。 | 资源排期需要区分社区资源和用户推送资源。 |\n| Q11 | 需要逐步根据亚马逊平台算法，把关键词需求、GEO 需求同步到测评计划中，综合销量、重要级、突发事件生成建议计划，再调动 IM、EDM、电话、KOC、KOL 等渠道。 | 后续需要计划生成引擎和多渠道资源调度。 |\n| Q12 | 订单号和 JOYHUB ID 是两个主要标识。订单号包括亚马逊来源和独立站来源。用户注册后必然有 JOYHUB ID，提供订单号后两者关联。 | 修正字段为“订单号”，不再使用 OA 订单号。 |\n| Q13 | 各渠道需要统一控制频率，并统一了解对用户的骚扰程度，避免过于频繁。 | 需要建设跨渠道频控和用户反感度监控。 |\n| Q14 | 注册用户的 JOYHUB ID 和邮箱必然关联；多个邮箱多账号可通过 IP、设备号等做黑名单关联，后台可按单一用户处理。 | 需要账号关联、黑名单和高风险关联用户机制。 |\n| Q15 | JOYCOLLAB 和财务都会参与。原则上 KOC 在 JOYCOLLAB 上的带货数据在网站内处理后同步到大用户后台。 | KOC/KOL/PR 看板需要支持 JOYCOLLAB 同步和财务核算校验。 |\n\n## 11. 进入项目规划前的系统设计问题\n\n当前业务链条已经基本清晰，可以进入项目规划与系统模块拆分。进入 ERP 系统设计前，需要把以下问题作为系统设计约束统一管理。\n\n### 11.1 角色权限\n\n需要明确不同角色的数据可见范围、操作权限和审批权限。\n\n重点问题：\n\n- 谁能查看销售明细？\n- 谁能查看用户邮箱、电话、订单号、地址、姓名等高度涉密字段？\n- 谁能审批、修改、暂停测评计划、回评计划、免评计划？\n- 菲律宾客服能看到哪些用户字段？\n- 内容运营能看到哪些用户行为和成交归因字段？\n\n### 11.2 计划流程状态\n\n测评、回评、免评、推送、内容投流、客服任务都需要统一状态流。\n\n建议基础状态：\n\n- 草稿\n- 待审批\n- 已审批\n- 执行中\n- 暂停\n- 异常\n- 已完成\n- 已复盘\n\n### 11.3 数据来源\n\n需要在系统层面明确每类数据的来源、同步方式、刷新频率和权限等级。\n\n| 数据类型 | 可能来源 |\n|---|---|\n| 亚马逊销量/订单 | 亚马逊运营数据源、导入表、API 或报表 |\n| 独立站订单 | 独立站系统 |\n| APP 绑定 | JOYHUB/APP 用户系统 |\n| 用户资料 | JOYHUB ID、注册邮箱、IP、设备号、用户行为数据 |\n| EDM 数据 | 邮件服务商 |\n| TEL 数据 | 电话系统或客服登记 |\n| JOYCOLLAB 数据 | JOYCOLLAB 网站 |\n| 财务/人事数据 | 财务表、人事表、成本表 |\n| 内容广告数据 | APP 广告位、社区内容系统 |\n\n### 11.4 核心业务对象\n\n后续建系统时，至少需要统一以下核心对象：\n\n- 用户\n- 订单\n- 产品\n- ASIN\n- 品牌\n- 国家/站点\n- 推送计划\n- 测评计划\n- 回评计划\n- 免评计划\n- 内容投流计划\n- 广告位\n- 客服任务\n- 合作伙伴\n- 成本记录\n- 风险用户/黑名单\n\n### 11.5 计划生成规则\n\n推新和测评计划一期建议先采用规则引擎，后续再逐步引入模型。\n\n仍需继续细化：\n\n- S/A/B 级产品资源比例是否固定，还是允许人工调整？\n- 突发事件如何插队？\n- 一个用户多久不能被重复触达？\n- 一个 ASIN 高风险时是否自动提升优先级？\n- GEO 需求如何进入计划生成？\n- 关键词需求如何与用户池匹配？\n\n### 11.6 评价健康报警\n\n评分阈值已经初步明确，但还需要补充数量类和进度类报警。\n\n待细化：\n\n- 回评数低于计划多少算异常？\n- 新品多少天内必须达到多少评价？\n- 差评率达到多少触发客服或用户运营介入？\n- ASIN 评分下降多少需要升级？\n- 评价健康报警是否自动触发回评推送计划？\n\n### 11.7 成本口径\n\n成本口径需要统一，否则无法做真实 ROI 和人效复盘。\n\n待细化：\n\n- 单评成本如何计算？\n- 返现成本是否纳入单评成本？\n- 菲律宾客服人力成本如何分摊到产品、ASIN、计划？\n- KOC/KOL 提成如何归因到订单？\n- 管理成本如何分摊？\n\n### 11.8 归因规则\n\n多渠道触达一定会发生交叉，归因规则需要系统化。\n\n典型场景：\n\n用户先看到 APP 内容广告，再收到 EDM，最后通过亚马逊购买。\n\n待确定：\n\n- 采用首触归因、末触归因、主要贡献渠道，还是多渠道权重归因？\n- 品牌活动到亚马逊成交如何归因？\n- 内容广告和用户推送都参与时如何拆分贡献？\n- KOC/KOL 带货链接与后续 APP 触达如何处理归因冲突？\n\n### 11.9 黑名单与风险用户处理\n\n黑名单与风险用户需要成为系统基础能力。\n\n待细化：\n\n- 谁能加入黑名单？\n- 黑名单是否影响推送、返现、测评资格？\n- 高风险用户是否允许客服继续跟进？\n- 多账号关联后是否自动合并为单一风险用户？\n- 黑名单查询是否支持订单号和 JOYHUB ID 双入口？\n\n### 11.10 一期项目边界建议\n\n一期不宜追求一次性覆盖所有 ERP 能力，应优先建设评价业务闭环的主干。\n\n建议一期优先：\n\n1. 产品/ASIN 看板\n2. 测评计划、回评计划、免评计划审批流\n3. 用户推送计划\n4. ASIN 评价健康看板\n5. 菲律宾客服执行看板\n6. 基础权限与涉密字段控制\n7. 基础数据导入和统一主键\n\n后续二期及以后再逐步扩展模型化计划生成、多渠道归因、复杂成本核算、内容广告优化、JOYCOLLAB 深度集成和管理层经营分析。\n\n## 12. 修改记录\n\n| 版本 | 日期 | 修改内容 | 记录人 |\n|---|---|---|---|\n| v0.7 | 2026-04-26 | 将业务链条确认后的系统设计问题写入文档；补充角色权限、计划状态流、数据来源、核心业务对象、计划生成规则、评价健康报警、成本口径、归因规则、黑名单与风险用户处理和一期项目边界建议。 | Codex |\n| v0.6 | 2026-04-26 | 追加内容运营相关业务；明确内容运营配合亚马逊运营与品牌运营进行销售前期宣发、售前社区广告计划和社区 KOC/KCO 对接；新增 APP 广告管理看板和推流管理看板，覆盖开屏、弹窗、文末、ME、评论末、加权、新帖、固定位置、固定流量池、用户行为、互动与风险字段。 | Codex |\n| v0.5 | 2026-04-26 | 追加菲律宾客服相关业务；明确菲律宾客服直接接受用户运营指导，亚马逊运营短期需求变动通过用户运营转达；新增核心指标客源、转化数、转化率、节约成本；新增人员管理、评价计划管理、成本管理三个看板及字段；补充菲律宾客服与用户运营、亚马逊运营、数据层/管理层的数据关系。 | Codex |\n| v0.4 | 2026-04-26 | 回答并固化 Q1-Q15 业务口径；明确绑定率公式、ASIN 明细权限、产品重要级确认与维护、推新资源规则、测评/回评/免评审批流、ASIN 评价健康阈值、订单号与 JOYHUB ID 双主标识、品牌影响力评估、品牌活动归因、APP 社区与用户推送资源边界、测评计划建议生成方向、跨渠道频控、黑名单关联和 JOYCOLLAB/财务数据来源。 | Codex |\n| v0.3 | 2026-04-26 | 追加用户运营相关业务；明确用户运营为系统核心使用者，客服部门归属用户部门管理；新增测评计划执行、ASIN 评价健康与回评计划、IM 社区消息推送、已成交索评、TEL 电话售后、EDM 邮件推送、KOC/KOL/PR 合作伙伴、其他触达渠道等模块；新增用户运营与其他部门的数据关系和待确认问题。 | Codex |\n| v0.2 | 2026-04-26 | 追加品牌运营相关业务；明确品牌运营与亚马逊运营不在同一办公区但共同建立销售体系；修正品牌推广计划归属为品牌运营主责、亚马逊运营同步；明确 AMZ 测评计划由亚马逊运营提需求、品牌运营协同、用户运营实际实现；新增品牌影响力与独立站销售看板、品牌推广计划协同看板、品牌运营数据关系和待确认问题。 | Codex |\n| v0.1 | 2026-04-26 | 建立评价业务流闭环项目架构文档；整理总体业务闭环、基础指标、亚马逊运营相关业务；新增销量与绑定率看板、推新计划与 APP 推送资源分配看板、测评与免评计划看板、回评计划与 ASIN 评价健康度看板、品牌推广协同数据和待确认问题。 | Codex |\n", + "wikilinks": [], + "category": "layer-requirements" + } + }, + { + "id": "doc:05_需求文档/README", + "type": "document", + "name": "需求文档", + "filePath": "05_需求文档/README.md", + "summary": "type: requirement inbox tags: 需求文档, 需求收集, 知识库更新, Agent aliases: 需求文档目录, 需求收集目录, 需求入口 source: manual status: active owner: 产品经理 / 业务主管 updated: 2026 05 需求文档 本目录用于集中存放后续持续补充的业务需求文档、业", + "tags": [ + "05_需求文档", + "需求文档", + "需求收集", + "知识库更新", + "Agent" + ], + "complexity": "simple", + "knowledgeMeta": { + "content": "---\ntype: requirement_inbox\ntags: [需求文档, 需求收集, 知识库更新, Agent]\naliases: [需求文档目录, 需求收集目录, 需求入口]\nsource: manual\nstatus: active\nowner: 产品经理 / 业务主管\nupdated: 2026-05\n---\n\n# 需求文档\n\n本目录用于集中存放后续持续补充的业务需求文档、业务规则文档、流程补充文档和需求变更文档。\n\n## 使用方式\n\n1. 所有新增需求文档优先放入本目录。\n2. 建议使用 `03_规范与模板/需求说明模板.md` 或 `03_规范与模板/业务规则与需求补充模板.md` 创建文档。\n3. 文档确认有效后，同步更新业务流程索引和 Agent 检索索引。\n4. Agent 回答具体业务需求时，应优先检索本目录。\n\n## 推荐命名\n\n```text\n业务域_需求或规则名称_YYYYMMDD.md\n```\n\n示例：\n\n```text\n采购_供应商准入规则_20260526.md\n库存_出入库审批规则_20260526.md\n销售_客户授信额度需求_20260526.md\n```\n\n## 文档状态\n\n每个需求文档建议在 Frontmatter 中维护 `status`：\n\n| 状态 | 含义 |\n|---|---|\n| draft | 草稿，尚未确认 |\n| reviewing | 评审中 |\n| active | 已确认，可作为 Agent 回答依据 |\n| deprecated | 已废弃，仅归档参考 |\n\n## 必填内容\n\n每个需求文档至少包含：\n\n- 需求背景\n- 适用范围\n- 涉及角色\n- 业务规则\n- 业务流程\n- 异常处理\n- 权限要求\n- 验收口径\n- Agent 检索字段\n- 变更记录\n\n## 索引维护\n\n新增或修改需求文档后，需要同步更新：\n\n- `05_需求文档/需求文档索引.md`\n- `01_业务流程/业务规则索引.md`\n- `01_业务流程/业务对象字典.md`\n- `04_Agent检索/关键词索引.md`\n- `04_Agent检索/同义词表.md`\n- `04_Agent检索/来源文件索引.md`\n\n## 验证流程\n\n新增需求文档后，按 `04_Agent检索/知识库持续更新与验证流程.md` 执行验证，并将验证结果记录到：\n\n- `05_需求文档/需求文档索引.md`\n- `01_业务流程/业务补充验证记录.md`\n", + "wikilinks": [], + "category": "layer-requirements" + } + }, + { + "id": "doc:05_需求文档/user_erp_mvp_admin_prototype_v10(1)", + "type": "document", + "name": "USER 后台 ERP MVP · 管理员总览原型 v10", + "filePath": "05_需求文档/user_erp_mvp_admin_prototype_v10(1).html", + "summary": "USER 后台 ERP MVP · 管理员总览原型 v10 JOYHUB Ops 模拟数据 第一期模拟 数据 当前模块 经营总览 系统管理员最高权限视图 常用跳转 21 重要事项 3 审核类 4 字段关系 5 问题总结 9 经营总览 系统管理员 · 最高权限 · 全部部门 搜索 至 日 周 月 全部部门 Amazon 运营 用户运营 客服 系统管理员（最高权", + "tags": [ + "05_需求文档", + "需求文档" + ], + "complexity": "complex", + "knowledgeMeta": { + "content": "\n\n\n \n \n USER 后台 ERP MVP · 管理员总览原型 v10\n \n\n\n
\n \n\n
\n
\n
\n
\n 经营总览\n 系统管理员 · 最高权限 · 全部部门\n
\n
\n 搜索\n \n
\n
\n
\n
\n \n 至\n \n
\n
\n \n \n \n
\n \n \n \n
\n
\n\n
\n
\n
\n\n
\n \n\n
\n
\n
\n

操作确认

\n \n
\n
\n
\n
\n\n
\n\n \n\n\n", + "wikilinks": [], + "category": "layer-requirements" + } + }, + { + "id": "doc:05_需求文档/user_erp_mvp_admin_prototype_v10", + "type": "document", + "name": "USER 后台 ERP MVP · 管理员总览原型 v10", + "filePath": "05_需求文档/user_erp_mvp_admin_prototype_v10.html", + "summary": "USER 后台 ERP MVP · 管理员总览原型 v10 JOYHUB Ops 💬 3 IM 消息 当前模块 经营总览 系统管理员最高权限视图 常用跳转 21 重要事项 3 审核类 4 字段关系 5 问题总结 9 经营总览 系统管理员 · 最高权限 · 全部部门 搜索 至 日 周 月 全部部门 Amazon 运营 用户运营 客服 系统管理员（最高权限） A", + "tags": [ + "05_需求文档", + "需求文档" + ], + "complexity": "complex", + "knowledgeMeta": { + "content": "\n\n\n \n \n USER 后台 ERP MVP · 管理员总览原型 v10\n \n\n\n
\n \n\n
\n
\n
\n
\n 经营总览\n 系统管理员 · 最高权限 · 全部部门\n
\n
\n 搜索\n \n
\n
\n
\n
\n \n 至\n \n
\n
\n \n \n \n
\n \n \n \n
\n
\n\n
\n
\n
\n\n
\n \n\n
\n
\n
\n

操作确认

\n \n
\n
\n
\n
\n\n
\n\n
\n \n\n \n\n\n", + "wikilinks": [], + "category": "layer-requirements" + } + }, + { + "id": "doc:05_需求文档/客服执行", + "type": "document", + "name": "客服执行看板", + "filePath": "05_需求文档/客服执行.html", + "summary": "客服执行看板", + "tags": [ + "05_需求文档", + "需求文档" + ], + "complexity": "complex", + "knowledgeMeta": { + "content": "\n\n \n \n \n 客服执行看板\n \n \n \n
\n \n \n\r\n", + "wikilinks": [], + "category": "layer-requirements" + } + }, + { + "id": "doc:05_需求文档/用户运营系统-单文件", + "type": "document", + "name": "USER评价业务闭环系统", + "filePath": "05_需求文档/用户运营系统-单文件.html", + "summary": "USER评价业务闭环系统", + "tags": [ + "05_需求文档", + "需求文档" + ], + "complexity": "complex", + "knowledgeMeta": { + "content": "\n\n \n \n \n USER评价业务闭环系统\n \n \n \n \n
\n \n\n", + "wikilinks": [ + "10,15", + "^\\", + "^\\", + "^\\", + "^\\", + "3,9", + "r,n", + "1,0", + "1,\"rgba(207,212,219,0.2)\"", + "\"rect\"", + "e", + "0,0", + "t,t", + "o.x,o.y", + "s.x,s.y", + "1,\"#E6EBF8\"" + ], + "category": "layer-requirements" + } + }, + { + "id": "doc:05_需求文档/需求文档索引", + "type": "document", + "name": "需求文档索引", + "filePath": "05_需求文档/需求文档索引.md", + "summary": "type: requirement index tags: 需求文档, 索引, Agent检索 aliases: 需求索引, 需求文档清单, 需求清单 source: manual status: active owner: 产品经理 / 业务主管 updated: 2026 05 需求文档索引 本文件记录 05 需求文档/ 下所有正式需求文档，供人工维护和", + "tags": [ + "05_需求文档", + "需求文档", + "索引", + "Agent检索" + ], + "complexity": "simple", + "knowledgeMeta": { + "content": "---\ntype: requirement_index\ntags: [需求文档, 索引, Agent检索]\naliases: [需求索引, 需求文档清单, 需求清单]\nsource: manual\nstatus: active\nowner: 产品经理 / 业务主管\nupdated: 2026-05\n---\n\n# 需求文档索引\n\n本文件记录 `05_需求文档/` 下所有正式需求文档，供人工维护和 Agent 检索定位。\n\n## 需求文档清单\n\n| 编号 | 业务域 | 需求/规则名称 | 文件 | 状态 | 负责人 | 更新时间 | 验证状态 |\n|---|---|---|---|---|---|---|---|\n| | | | | | | | 未验证 |\n\n## Agent 检索关键词\n\n| 关键词/问法 | 标准术语 | 命中文件 | 答案要点 |\n|---|---|---|---|\n| | | | |\n\n## 维护规则\n\n1. 新增需求文档后，必须在“需求文档清单”新增一行。\n2. 每个需求文档至少维护 3 个可检索问法。\n3. `状态=active` 的文档可作为 Agent 回答依据。\n4. `status=draft/reviewing` 的文档只能作为草稿参考，Agent 回答时需说明尚未确认。\n5. `status=deprecated` 的文档不得作为当前规则依据，只能说明历史背景。\n\n## 验证记录摘要\n\n| 日期 | 文件 | 验证问题数 | 通过数 | 失败数 | 结论 |\n|---|---|---:|---:|---:|---|\n| | | | | | |\n", + "wikilinks": [], + "category": "layer-requirements" + } + } + ], + "edges": [ + { + "source": "article:00_首页/知识库首页", + "target": "article:00_首页/知识地图", + "type": "related", + "direction": "forward", + "weight": 0.7 + }, + { + "source": "article:00_首页/知识库首页", + "target": "article:00_首页/Agent问答入口", + "type": "related", + "direction": "forward", + "weight": 0.7 + }, + { + "source": "article:01_业务流程/README", + "target": "article:01_业务流程/业务流程模板", + "type": "related", + "direction": "forward", + "weight": 0.7 + }, + { + "source": "article:01_业务流程/README", + "target": "article:01_业务流程/业务对象字典", + "type": "related", + "direction": "forward", + "weight": 0.7 + }, + { + "source": "article:01_业务流程/README", + "target": "article:01_业务流程/业务规则索引", + "type": "related", + "direction": "forward", + "weight": 0.7 + }, + { + "source": "article:02_项目管理流程/AI驱动内部系统开发流程_V3_总览", + "target": "article:02_项目管理流程/阶段0_项目入口分级", + "type": "related", + "direction": "forward", + "weight": 0.7 + }, + { + "source": "article:02_项目管理流程/AI驱动内部系统开发流程_V3_总览", + "target": "article:02_项目管理流程/阶段1_业务需求完整形成", + "type": "related", + "direction": "forward", + "weight": 0.7 + }, + { + "source": "article:02_项目管理流程/AI驱动内部系统开发流程_V3_总览", + "target": "article:02_项目管理流程/阶段2_高保真模型与业务对象确认", + "type": "related", + "direction": "forward", + "weight": 0.7 + }, + { + "source": "article:02_项目管理流程/AI驱动内部系统开发流程_V3_总览", + "target": "article:02_项目管理流程/阶段2.5_测试提前补漏", + "type": "related", + "direction": "forward", + "weight": 0.7 + }, + { + "source": "article:02_项目管理流程/AI驱动内部系统开发流程_V3_总览", + "target": "article:02_项目管理流程/阶段3_研发协作与正式开发", + "type": "related", + "direction": "forward", + "weight": 0.7 + }, + { + "source": "article:02_项目管理流程/AI驱动内部系统开发流程_V3_总览", + "target": "article:02_项目管理流程/阶段4_测试培训上线回流", + "type": "related", + "direction": "forward", + "weight": 0.7 + }, + { + "source": "article:02_项目管理流程/AI驱动内部系统开发流程_V3_总览", + "target": "article:02_项目管理流程/角色职责矩阵", + "type": "related", + "direction": "forward", + "weight": 0.7 + }, + { + "source": "article:02_项目管理流程/AI驱动内部系统开发流程_V3_总览", + "target": "article:02_项目管理流程/阶段交付物清单", + "type": "related", + "direction": "forward", + "weight": 0.7 + }, + { + "source": "article:02_项目管理流程/AI驱动内部系统开发流程_V3_总览", + "target": "article:02_项目管理流程/项目检查清单", + "type": "related", + "direction": "forward", + "weight": 0.7 + }, + { + "source": "article:02_项目管理流程/README", + "target": "article:02_项目管理流程/AI驱动内部系统开发流程_V3_总览", + "type": "related", + "direction": "forward", + "weight": 0.7 + }, + { + "source": "article:02_项目管理流程/README", + "target": "article:02_项目管理流程/阶段0_项目入口分级", + "type": "related", + "direction": "forward", + "weight": 0.7 + }, + { + "source": "article:02_项目管理流程/README", + "target": "article:02_项目管理流程/阶段1_业务需求完整形成", + "type": "related", + "direction": "forward", + "weight": 0.7 + }, + { + "source": "article:02_项目管理流程/README", + "target": "article:02_项目管理流程/阶段2_高保真模型与业务对象确认", + "type": "related", + "direction": "forward", + "weight": 0.7 + }, + { + "source": "article:02_项目管理流程/README", + "target": "article:02_项目管理流程/阶段2.5_测试提前补漏", + "type": "related", + "direction": "forward", + "weight": 0.7 + }, + { + "source": "article:02_项目管理流程/README", + "target": "article:02_项目管理流程/阶段3_研发协作与正式开发", + "type": "related", + "direction": "forward", + "weight": 0.7 + }, + { + "source": "article:02_项目管理流程/README", + "target": "article:02_项目管理流程/阶段4_测试培训上线回流", + "type": "related", + "direction": "forward", + "weight": 0.7 + }, + { + "source": "article:02_项目管理流程/README", + "target": "article:02_项目管理流程/角色职责矩阵", + "type": "related", + "direction": "forward", + "weight": 0.7 + }, + { + "source": "article:02_项目管理流程/README", + "target": "article:02_项目管理流程/阶段交付物清单", + "type": "related", + "direction": "forward", + "weight": 0.7 + }, + { + "source": "article:02_项目管理流程/README", + "target": "article:02_项目管理流程/项目检查清单", + "type": "related", + "direction": "forward", + "weight": 0.7 + }, + { + "source": "article:02_项目管理流程/README", + "target": "article:02_项目管理流程/常见问题FAQ", + "type": "related", + "direction": "forward", + "weight": 0.7 + }, + { + "source": "article:02_项目管理流程/常见问题FAQ", + "target": "article:02_项目管理流程/AI驱动内部系统开发流程_V3_总览", + "type": "related", + "direction": "forward", + "weight": 0.7 + }, + { + "source": "article:02_项目管理流程/常见问题FAQ", + "target": "article:02_项目管理流程/阶段0_项目入口分级", + "type": "related", + "direction": "forward", + "weight": 0.7 + }, + { + "source": "article:02_项目管理流程/常见问题FAQ", + "target": "article:02_项目管理流程/角色职责矩阵", + "type": "related", + "direction": "forward", + "weight": 0.7 + }, + { + "source": "article:02_项目管理流程/常见问题FAQ", + "target": "article:02_项目管理流程/阶段1_业务需求完整形成", + "type": "related", + "direction": "forward", + "weight": 0.7 + }, + { + "source": "article:02_项目管理流程/常见问题FAQ", + "target": "article:02_项目管理流程/阶段2.5_测试提前补漏", + "type": "related", + "direction": "forward", + "weight": 0.7 + }, + { + "source": "article:02_项目管理流程/常见问题FAQ", + "target": "article:02_项目管理流程/阶段交付物清单", + "type": "related", + "direction": "forward", + "weight": 0.7 + }, + { + "source": "article:02_项目管理流程/常见问题FAQ", + "target": "article:02_项目管理流程/阶段2_高保真模型与业务对象确认", + "type": "related", + "direction": "forward", + "weight": 0.7 + }, + { + "source": "article:02_项目管理流程/常见问题FAQ", + "target": "article:02_项目管理流程/阶段3_研发协作与正式开发", + "type": "related", + "direction": "forward", + "weight": 0.7 + }, + { + "source": "article:02_项目管理流程/常见问题FAQ", + "target": "article:02_项目管理流程/阶段4_测试培训上线回流", + "type": "related", + "direction": "forward", + "weight": 0.7 + }, + { + "source": "article:02_项目管理流程/常见问题FAQ", + "target": "article:02_项目管理流程/项目检查清单", + "type": "related", + "direction": "forward", + "weight": 0.7 + }, + { + "source": "article:02_项目管理流程/角色职责矩阵", + "target": "article:02_项目管理流程/AI驱动内部系统开发流程_V3_总览", + "type": "related", + "direction": "forward", + "weight": 0.7 + }, + { + "source": "article:02_项目管理流程/角色职责矩阵", + "target": "article:02_项目管理流程/阶段0_项目入口分级", + "type": "related", + "direction": "forward", + "weight": 0.7 + }, + { + "source": "article:02_项目管理流程/角色职责矩阵", + "target": "article:02_项目管理流程/阶段1_业务需求完整形成", + "type": "related", + "direction": "forward", + "weight": 0.7 + }, + { + "source": "article:02_项目管理流程/角色职责矩阵", + "target": "article:02_项目管理流程/阶段2.5_测试提前补漏", + "type": "related", + "direction": "forward", + "weight": 0.7 + }, + { + "source": "article:02_项目管理流程/角色职责矩阵", + "target": "article:02_项目管理流程/阶段4_测试培训上线回流", + "type": "related", + "direction": "forward", + "weight": 0.7 + }, + { + "source": "article:02_项目管理流程/阶段0_项目入口分级", + "target": "article:02_项目管理流程/AI驱动内部系统开发流程_V3_总览", + "type": "related", + "direction": "forward", + "weight": 0.7 + }, + { + "source": "article:02_项目管理流程/阶段0_项目入口分级", + "target": "article:02_项目管理流程/角色职责矩阵", + "type": "related", + "direction": "forward", + "weight": 0.7 + }, + { + "source": "article:02_项目管理流程/阶段0_项目入口分级", + "target": "article:02_项目管理流程/阶段交付物清单", + "type": "related", + "direction": "forward", + "weight": 0.7 + }, + { + "source": "article:02_项目管理流程/阶段1_业务需求完整形成", + "target": "article:02_项目管理流程/阶段0_项目入口分级", + "type": "related", + "direction": "forward", + "weight": 0.7 + }, + { + "source": "article:02_项目管理流程/阶段1_业务需求完整形成", + "target": "article:02_项目管理流程/阶段2_高保真模型与业务对象确认", + "type": "related", + "direction": "forward", + "weight": 0.7 + }, + { + "source": "article:02_项目管理流程/阶段1_业务需求完整形成", + "target": "article:02_项目管理流程/角色职责矩阵", + "type": "related", + "direction": "forward", + "weight": 0.7 + }, + { + "source": "article:02_项目管理流程/阶段1_业务需求完整形成", + "target": "article:02_项目管理流程/阶段交付物清单", + "type": "related", + "direction": "forward", + "weight": 0.7 + }, + { + "source": "article:02_项目管理流程/阶段2.5_测试提前补漏", + "target": "article:02_项目管理流程/阶段2_高保真模型与业务对象确认", + "type": "related", + "direction": "forward", + "weight": 0.7 + }, + { + "source": "article:02_项目管理流程/阶段2.5_测试提前补漏", + "target": "article:02_项目管理流程/阶段3_研发协作与正式开发", + "type": "related", + "direction": "forward", + "weight": 0.7 + }, + { + "source": "article:02_项目管理流程/阶段2.5_测试提前补漏", + "target": "article:02_项目管理流程/项目检查清单", + "type": "related", + "direction": "forward", + "weight": 0.7 + }, + { + "source": "article:02_项目管理流程/阶段2_高保真模型与业务对象确认", + "target": "article:02_项目管理流程/阶段1_业务需求完整形成", + "type": "related", + "direction": "forward", + "weight": 0.7 + }, + { + "source": "article:02_项目管理流程/阶段2_高保真模型与业务对象确认", + "target": "article:02_项目管理流程/阶段2.5_测试提前补漏", + "type": "related", + "direction": "forward", + "weight": 0.7 + }, + { + "source": "article:02_项目管理流程/阶段2_高保真模型与业务对象确认", + "target": "article:02_项目管理流程/阶段交付物清单", + "type": "related", + "direction": "forward", + "weight": 0.7 + }, + { + "source": "article:02_项目管理流程/阶段3_研发协作与正式开发", + "target": "article:02_项目管理流程/阶段2.5_测试提前补漏", + "type": "related", + "direction": "forward", + "weight": 0.7 + }, + { + "source": "article:02_项目管理流程/阶段3_研发协作与正式开发", + "target": "article:02_项目管理流程/阶段4_测试培训上线回流", + "type": "related", + "direction": "forward", + "weight": 0.7 + }, + { + "source": "article:02_项目管理流程/阶段3_研发协作与正式开发", + "target": "article:02_项目管理流程/阶段交付物清单", + "type": "related", + "direction": "forward", + "weight": 0.7 + }, + { + "source": "article:02_项目管理流程/阶段4_测试培训上线回流", + "target": "article:02_项目管理流程/阶段3_研发协作与正式开发", + "type": "related", + "direction": "forward", + "weight": 0.7 + }, + { + "source": "article:02_项目管理流程/阶段4_测试培训上线回流", + "target": "article:02_项目管理流程/项目检查清单", + "type": "related", + "direction": "forward", + "weight": 0.7 + }, + { + "source": "article:02_项目管理流程/阶段4_测试培训上线回流", + "target": "article:02_项目管理流程/阶段交付物清单", + "type": "related", + "direction": "forward", + "weight": 0.7 + }, + { + "source": "article:02_项目管理流程/阶段交付物清单", + "target": "article:02_项目管理流程/AI驱动内部系统开发流程_V3_总览", + "type": "related", + "direction": "forward", + "weight": 0.7 + }, + { + "source": "article:02_项目管理流程/阶段交付物清单", + "target": "article:02_项目管理流程/项目检查清单", + "type": "related", + "direction": "forward", + "weight": 0.7 + }, + { + "source": "article:02_项目管理流程/项目检查清单", + "target": "article:02_项目管理流程/AI驱动内部系统开发流程_V3_总览", + "type": "related", + "direction": "forward", + "weight": 0.7 + }, + { + "source": "article:02_项目管理流程/项目检查清单", + "target": "article:02_项目管理流程/阶段交付物清单", + "type": "related", + "direction": "forward", + "weight": 0.7 + }, + { + "source": "article:04_Agent检索/检索说明", + "target": "article:04_Agent检索/知识库持续更新与验证流程", + "type": "related", + "direction": "forward", + "weight": 0.7 + }, + { + "source": "article:06_里程碑/README", + "target": "article:06_里程碑/里程碑索引", + "type": "related", + "direction": "forward", + "weight": 0.7 + }, + { + "source": "article:06_里程碑/README", + "target": "article:06_里程碑/阶段计划模板", + "type": "related", + "direction": "forward", + "weight": 0.7 + }, + { + "source": "article:06_里程碑/README", + "target": "article:06_里程碑/里程碑评审记录", + "type": "related", + "direction": "forward", + "weight": 0.7 + }, + { + "source": "article:07_技术文档/README", + "target": "article:07_技术文档/技术文档索引", + "type": "related", + "direction": "forward", + "weight": 0.7 + }, + { + "source": "article:07_技术文档/README", + "target": "article:07_技术文档/系统架构说明模板", + "type": "related", + "direction": "forward", + "weight": 0.7 + }, + { + "source": "article:07_技术文档/README", + "target": "article:07_技术文档/接口说明模板", + "type": "related", + "direction": "forward", + "weight": 0.7 + }, + { + "source": "article:07_技术文档/README", + "target": "article:07_技术文档/技术决策记录", + "type": "related", + "direction": "forward", + "weight": 0.7 + }, + { + "source": "article:08_测试相关/README", + "target": "article:08_测试相关/测试用例索引", + "type": "related", + "direction": "forward", + "weight": 0.7 + }, + { + "source": "article:08_测试相关/README", + "target": "article:08_测试相关/测试用例模板", + "type": "related", + "direction": "forward", + "weight": 0.7 + }, + { + "source": "article:08_测试相关/README", + "target": "article:08_测试相关/测试计划模板", + "type": "related", + "direction": "forward", + "weight": 0.7 + }, + { + "source": "article:08_测试相关/README", + "target": "article:08_测试相关/缺陷记录模板", + "type": "related", + "direction": "forward", + "weight": 0.7 + }, + { + "source": "article:08_测试相关/README", + "target": "article:08_测试相关/验收记录模板", + "type": "related", + "direction": "forward", + "weight": 0.7 + }, + { + "source": "article:08_测试相关/README", + "target": "article:03_规范与模板/上线检查模板", + "type": "related", + "direction": "forward", + "weight": 0.7 + }, + { + "source": "article:欢迎", + "target": "article:00_首页/知识库首页", + "type": "related", + "direction": "forward", + "weight": 0.7 + }, + { + "source": "article:欢迎", + "target": "article:知识库使用说明", + "type": "related", + "direction": "forward", + "weight": 0.7 + }, + { + "source": "article:欢迎", + "target": "article:00_首页/知识地图", + "type": "related", + "direction": "forward", + "weight": 0.7 + }, + { + "source": "article:欢迎", + "target": "article:00_首页/Agent问答入口", + "type": "related", + "direction": "forward", + "weight": 0.7 + }, + { + "source": "article:欢迎", + "target": "article:05_需求文档/README", + "type": "related", + "direction": "forward", + "weight": 0.7 + }, + { + "source": "article:欢迎", + "target": "article:06_里程碑/README", + "type": "related", + "direction": "forward", + "weight": 0.7 + }, + { + "source": "article:欢迎", + "target": "article:07_技术文档/README", + "type": "related", + "direction": "forward", + "weight": 0.7 + }, + { + "source": "article:欢迎", + "target": "article:08_测试相关/README", + "type": "related", + "direction": "forward", + "weight": 0.7 + }, + { + "source": "article:欢迎", + "target": "article:04_Agent检索/检索说明", + "type": "related", + "direction": "forward", + "weight": 0.7 + }, + { + "source": "article:知识库使用说明", + "target": "article:欢迎", + "type": "related", + "direction": "forward", + "weight": 0.7 + }, + { + "source": "article:知识库使用说明", + "target": "article:00_首页/知识库首页", + "type": "related", + "direction": "forward", + "weight": 0.7 + }, + { + "source": "article:知识库使用说明", + "target": "article:00_首页/知识地图", + "type": "related", + "direction": "forward", + "weight": 0.7 + }, + { + "source": "article:知识库使用说明", + "target": "article:00_首页/Agent问答入口", + "type": "related", + "direction": "forward", + "weight": 0.7 + }, + { + "source": "article:知识库使用说明", + "target": "article:04_Agent检索/检索说明", + "type": "related", + "direction": "forward", + "weight": 0.7 + }, + { + "source": "article:知识库使用说明", + "target": "article:05_需求文档/README", + "type": "related", + "direction": "forward", + "weight": 0.7 + }, + { + "source": "article:知识库使用说明", + "target": "article:06_里程碑/README", + "type": "related", + "direction": "forward", + "weight": 0.7 + }, + { + "source": "article:知识库使用说明", + "target": "article:07_技术文档/README", + "type": "related", + "direction": "forward", + "weight": 0.7 + }, + { + "source": "article:知识库使用说明", + "target": "article:08_测试相关/README", + "type": "related", + "direction": "forward", + "weight": 0.7 + }, + { + "source": "article:知识库使用说明", + "target": "article:02_项目管理流程/AI驱动内部系统开发流程_V3_总览", + "type": "related", + "direction": "forward", + "weight": 0.7 + }, + { + "source": "article:知识库使用说明", + "target": "article:04_Agent检索/来源文件索引", + "type": "related", + "direction": "forward", + "weight": 0.7 + }, + { + "source": "article:知识库使用说明", + "target": "article:05_需求文档/需求文档索引", + "type": "related", + "direction": "forward", + "weight": 0.7 + }, + { + "source": "article:知识库使用说明", + "target": "article:01_业务流程/业务规则索引", + "type": "related", + "direction": "forward", + "weight": 0.7 + }, + { + "source": "article:知识库使用说明", + "target": "article:01_业务流程/业务对象字典", + "type": "related", + "direction": "forward", + "weight": 0.7 + }, + { + "source": "article:知识库使用说明", + "target": "article:04_Agent检索/关键词索引", + "type": "related", + "direction": "forward", + "weight": 0.7 + }, + { + "source": "article:知识库使用说明", + "target": "article:06_里程碑/里程碑索引", + "type": "related", + "direction": "forward", + "weight": 0.7 + }, + { + "source": "article:知识库使用说明", + "target": "article:07_技术文档/技术文档索引", + "type": "related", + "direction": "forward", + "weight": 0.7 + }, + { + "source": "article:知识库使用说明", + "target": "article:08_测试相关/测试用例索引", + "type": "related", + "direction": "forward", + "weight": 0.7 + }, + { + "source": "article:知识库使用说明", + "target": "article:04_Agent检索/同义词表", + "type": "related", + "direction": "forward", + "weight": 0.7 + }, + { + "source": "article:知识库使用说明", + "target": "article:04_Agent检索/知识库持续更新与验证流程", + "type": "related", + "direction": "forward", + "weight": 0.7 + }, + { + "source": "flow:layer-requirements", + "target": "doc:05_需求文档/00-系统总览", + "type": "documents", + "direction": "forward", + "description": "本层文档", + "weight": 0.65 + }, + { + "source": "flow:layer-requirements", + "target": "doc:05_需求文档/01-子系统-用户身份与上下文", + "type": "documents", + "direction": "forward", + "description": "本层文档", + "weight": 0.65 + }, + { + "source": "flow:layer-requirements", + "target": "doc:05_需求文档/02-子系统-需求与计划管理", + "type": "documents", + "direction": "forward", + "description": "本层文档", + "weight": 0.65 + }, + { + "source": "flow:layer-requirements", + "target": "doc:05_需求文档/03-子系统-额度与频控", + "type": "documents", + "direction": "forward", + "description": "本层文档", + "weight": 0.65 + }, + { + "source": "flow:layer-requirements", + "target": "doc:05_需求文档/04-子系统-多渠道触达引擎", + "type": "documents", + "direction": "forward", + "description": "本层文档", + "weight": 0.65 + }, + { + "source": "flow:layer-requirements", + "target": "doc:05_需求文档/05-子系统-客服工单与管理", + "type": "documents", + "direction": "forward", + "description": "本层文档", + "weight": 0.65 + }, + { + "source": "flow:layer-requirements", + "target": "doc:05_需求文档/06-子系统-风险与反欺诈", + "type": "documents", + "direction": "forward", + "description": "本层文档", + "weight": 0.65 + }, + { + "source": "flow:layer-requirements", + "target": "doc:05_需求文档/07-子系统-评价结果追踪", + "type": "documents", + "direction": "forward", + "description": "本层文档", + "weight": 0.65 + }, + { + "source": "flow:layer-requirements", + "target": "doc:05_需求文档/08-子系统-KOC-KOL协作", + "type": "documents", + "direction": "forward", + "description": "本层文档", + "weight": 0.65 + }, + { + "source": "flow:layer-requirements", + "target": "doc:05_需求文档/09-子系统-审计与通知中心", + "type": "documents", + "direction": "forward", + "description": "本层文档", + "weight": 0.65 + }, + { + "source": "flow:layer-requirements", + "target": "doc:05_需求文档/20260504_USER后台ERP_MVP管理员首页高保真原型_v7", + "type": "documents", + "direction": "forward", + "description": "本层文档", + "weight": 0.65 + }, + { + "source": "flow:layer-requirements", + "target": "doc:05_需求文档/20260517_USER评价业务闭环_共用能力图与渠道专属流程_v2.2", + "type": "documents", + "direction": "forward", + "description": "本层文档", + "weight": 0.65 + }, + { + "source": "flow:layer-requirements", + "target": "doc:05_需求文档/20260517_USER评价业务闭环_第三步_数据流与中间对象设计_v3", + "type": "documents", + "direction": "forward", + "description": "本层文档", + "weight": 0.65 + }, + { + "source": "flow:layer-requirements", + "target": "doc:05_需求文档/20260517_USER评价业务闭环主流程与后续工作基线_v1.2", + "type": "documents", + "direction": "forward", + "description": "本层文档", + "weight": 0.65 + }, + { + "source": "flow:layer-requirements", + "target": "doc:05_需求文档/evaluation-business-architecture", + "type": "documents", + "direction": "forward", + "description": "本层文档", + "weight": 0.65 + }, + { + "source": "flow:layer-requirements", + "target": "doc:05_需求文档/README", + "type": "documents", + "direction": "forward", + "description": "本层文档", + "weight": 0.65 + }, + { + "source": "flow:layer-requirements", + "target": "doc:05_需求文档/user_erp_mvp_admin_prototype_v10(1)", + "type": "documents", + "direction": "forward", + "description": "本层文档", + "weight": 0.65 + }, + { + "source": "flow:layer-requirements", + "target": "doc:05_需求文档/user_erp_mvp_admin_prototype_v10", + "type": "documents", + "direction": "forward", + "description": "本层文档", + "weight": 0.65 + }, + { + "source": "flow:layer-requirements", + "target": "doc:05_需求文档/客服执行", + "type": "documents", + "direction": "forward", + "description": "本层文档", + "weight": 0.65 + }, + { + "source": "flow:layer-requirements", + "target": "doc:05_需求文档/用户运营系统-单文件", + "type": "documents", + "direction": "forward", + "description": "本层文档", + "weight": 0.65 + }, + { + "source": "flow:layer-requirements", + "target": "doc:05_需求文档/需求文档索引", + "type": "documents", + "direction": "forward", + "description": "本层文档", + "weight": 0.65 + } + ], + "layers": [ + { + "id": "layer:使用说明", + "name": "使用说明", + "description": "使用说明 (1 nodes)", + "nodeIds": [ + "topic:使用说明" + ] + }, + { + "id": "layer:需求文档", + "name": "需求文档", + "description": "需求文档 (1 nodes)", + "nodeIds": [ + "topic:需求文档" + ] + }, + { + "id": "layer:里程碑", + "name": "里程碑", + "description": "里程碑 (1 nodes)", + "nodeIds": [ + "topic:里程碑" + ] + }, + { + "id": "layer:技术文档", + "name": "技术文档", + "description": "技术文档 (1 nodes)", + "nodeIds": [ + "topic:技术文档" + ] + }, + { + "id": "layer:测试相关", + "name": "测试相关", + "description": "测试相关 (1 nodes)", + "nodeIds": [ + "topic:测试相关" + ] + }, + { + "id": "layer:agent-检索", + "name": "Agent 检索", + "description": "Agent 检索 (1 nodes)", + "nodeIds": [ + "topic:agent-检索" + ] + }, + { + "id": "layer:other", + "name": "Other", + "description": "Uncategorized nodes (54)", + "nodeIds": [ + "article:00_首页/Agent问答入口", + "article:00_首页/知识地图", + "article:00_首页/知识库首页", + "article:01_业务流程/README", + "article:01_业务流程/业务对象字典", + "article:01_业务流程/业务流程模板", + "article:01_业务流程/业务补充验证记录", + "article:01_业务流程/业务规则索引", + "article:02_项目管理流程/AI驱动内部系统开发流程_V3_总览", + "article:02_项目管理流程/README", + "article:02_项目管理流程/常见问题FAQ", + "article:02_项目管理流程/角色职责矩阵", + "article:02_项目管理流程/阶段0_项目入口分级", + "article:02_项目管理流程/阶段1_业务需求完整形成", + "article:02_项目管理流程/阶段2.5_测试提前补漏", + "article:02_项目管理流程/阶段2_高保真模型与业务对象确认", + "article:02_项目管理流程/阶段3_研发协作与正式开发", + "article:02_项目管理流程/阶段4_测试培训上线回流", + "article:02_项目管理流程/阶段交付物清单", + "article:02_项目管理流程/项目检查清单", + "article:03_规范与模板/上线检查模板", + "article:03_规范与模板/业务流程梳理模板", + "article:03_规范与模板/业务规则与需求补充模板", + "article:03_规范与模板/会议纪要模板", + "article:03_规范与模板/需求说明模板", + "article:04_Agent检索/关键词索引", + "article:04_Agent检索/同义词表", + "article:04_Agent检索/来源文件索引", + "article:04_Agent检索/检索说明", + "article:04_Agent检索/知识库持续更新与验证流程", + "article:04_Agent检索/问答提示词", + "article:05_需求文档/20260517_USER评价业务闭环_第三步_数据流与中间对象设计_v3", + "article:05_需求文档/README", + "article:05_需求文档/需求文档索引", + "article:06_里程碑/README", + "article:06_里程碑/里程碑索引", + "article:06_里程碑/里程碑评审记录", + "article:06_里程碑/阶段计划模板", + "article:07_技术文档/README", + "article:07_技术文档/技术决策记录", + "article:07_技术文档/技术文档索引", + "article:07_技术文档/接口说明模板", + "article:07_技术文档/系统架构说明模板", + "article:08_测试相关/README", + "article:08_测试相关/上线检查模板", + "article:08_测试相关/测试用例模板", + "article:08_测试相关/测试用例索引", + "article:08_测试相关/测试计划模板", + "article:08_测试相关/缺陷记录模板", + "article:08_测试相关/验收记录模板", + "article:20260517_USER评价业务闭环_共用能力图与渠道专属流程_v2.2", + "article:欢迎", + "article:知识库使用说明", + "source:AI_驱动_内部系统开发流程_V3" + ] + }, + { + "id": "layer-requirements", + "name": "需求文档", + "description": "所有正式需求、业务规则、需求变更和需求索引。", + "nodeIds": [ + "flow:layer-requirements", + "doc:05_需求文档/00-系统总览", + "doc:05_需求文档/01-子系统-用户身份与上下文", + "doc:05_需求文档/02-子系统-需求与计划管理", + "doc:05_需求文档/03-子系统-额度与频控", + "doc:05_需求文档/04-子系统-多渠道触达引擎", + "doc:05_需求文档/05-子系统-客服工单与管理", + "doc:05_需求文档/06-子系统-风险与反欺诈", + "doc:05_需求文档/07-子系统-评价结果追踪", + "doc:05_需求文档/08-子系统-KOC-KOL协作", + "doc:05_需求文档/09-子系统-审计与通知中心", + "doc:05_需求文档/20260504_USER后台ERP_MVP管理员首页高保真原型_v7", + "doc:05_需求文档/20260517_USER评价业务闭环_共用能力图与渠道专属流程_v2.2", + "doc:05_需求文档/20260517_USER评价业务闭环_第三步_数据流与中间对象设计_v3", + "doc:05_需求文档/20260517_USER评价业务闭环主流程与后续工作基线_v1.2", + "doc:05_需求文档/evaluation-business-architecture", + "doc:05_需求文档/README", + "doc:05_需求文档/user_erp_mvp_admin_prototype_v10(1)", + "doc:05_需求文档/user_erp_mvp_admin_prototype_v10", + "doc:05_需求文档/客服执行", + "doc:05_需求文档/用户运营系统-单文件", + "doc:05_需求文档/需求文档索引" + ] + } + ], + "tour": [ + { + "order": 1, + "title": "使用说明", + "description": "Explore the 使用说明 section (2 articles)", + "nodeIds": [ + "topic:使用说明" + ] + }, + { + "order": 2, + "title": "需求文档", + "description": "Explore the 需求文档 section (6 articles)", + "nodeIds": [ + "topic:需求文档" + ] + }, + { + "order": 3, + "title": "里程碑", + "description": "Explore the 里程碑 section (7 articles)", + "nodeIds": [ + "topic:里程碑" + ] + }, + { + "order": 4, + "title": "技术文档", + "description": "Explore the 技术文档 section (5 articles)", + "nodeIds": [ + "topic:技术文档" + ] + }, + { + "order": 5, + "title": "测试相关", + "description": "Explore the 测试相关 section (9 articles)", + "nodeIds": [ + "topic:测试相关" + ] + }, + { + "order": 6, + "title": "Agent 检索", + "description": "Explore the Agent 检索 section (6 articles)", + "nodeIds": [ + "topic:agent-检索" + ] + } + ] +} diff --git a/wishfulfilled-wiki/.understand-anything/intermediate/scan-manifest.json b/wishfulfilled-wiki/.understand-anything/intermediate/scan-manifest.json new file mode 100644 index 0000000..e8f1fd0 --- /dev/null +++ b/wishfulfilled-wiki/.understand-anything/intermediate/scan-manifest.json @@ -0,0 +1,2287 @@ +{ + "format": "karpathy", + "stats": { + "articles": 53, + "sources": 1, + "topics": 6, + "wikilinks": 183, + "unresolved": 63 + }, + "categories": [ + { + "name": "\u4f7f\u7528\u8bf4\u660e", + "count": 2 + }, + { + "name": "\u9700\u6c42\u6587\u6863", + "count": 6 + }, + { + "name": "\u91cc\u7a0b\u7891", + "count": 7 + }, + { + "name": "\u6280\u672f\u6587\u6863", + "count": 5 + }, + { + "name": "\u6d4b\u8bd5\u76f8\u5173", + "count": 9 + }, + { + "name": "Agent \u68c0\u7d22", + "count": 6 + } + ], + "logEntries": 0, + "nodes": [ + { + "id": "article:00_\u9996\u9875/Agent\u95ee\u7b54\u5165\u53e3", + "type": "article", + "name": "Agent \u95ee\u7b54\u5165\u53e3", + "filePath": "00_\u9996\u9875\\Agent\u95ee\u7b54\u5165\u53e3.md", + "summary": "\u5f53\u7528\u6237\u8be2\u95ee\u4e1a\u52a1\u6216\u9879\u76ee\u6d41\u7a0b\u65f6\uff0cAgent \u5e94\u5148\u68c0\u7d22\u672c\u77e5\u8bc6\u5e93 Markdown \u6587\u4ef6\uff0c\u518d\u7ec4\u7ec7\u56de\u7b54\u3002", + "tags": [ + "00_\u9996\u9875", + "[Agent", + "\u68c0\u7d22]", + "\u95ee\u7b54" + ], + "complexity": "simple", + "knowledgeMeta": { + "wikilinks": [], + "content": "---\ntype: agent_entry\ntags: [Agent, \u95ee\u7b54, \u68c0\u7d22]\naliases: [\u95ee\u7b54\u5165\u53e3, Agent\u5165\u53e3]\nsource: manual\nstatus: active\nowner: \u5185\u90e8\u6280\u672f\u56e2\u961f\nupdated: 2026-05\n---\n\n# Agent \u95ee\u7b54\u5165\u53e3\n\n\u5f53\u7528\u6237\u8be2\u95ee\u4e1a\u52a1\u6216\u9879\u76ee\u6d41\u7a0b\u65f6\uff0cAgent \u5e94\u5148\u68c0\u7d22\u672c\u77e5\u8bc6\u5e93 Markdown \u6587\u4ef6\uff0c\u518d\u7ec4\u7ec7\u56de\u7b54\u3002\n\n## \u63a8\u8350\u68c0\u7d22\u987a\u5e8f\n\n1. `05_\u9700\u6c42\u6587\u6863/`\uff1a\u6301\u7eed\u65b0\u589e\u7684\u4e1a\u52a1\u9700\u6c42\u3001\u4e1a\u52a1\u89c4\u5219\u3001\u9700\u6c42\u53d8\u66f4\u3002\n2. `06_\u91cc\u7a0b\u7891/`\uff1a\u9879\u76ee\u8282\u70b9\u3001\u9636\u6bb5\u8ba1\u5212\u3001\u9636\u6bb5\u8bc4\u5ba1\u3001\u4e0a\u7ebf\u8282\u594f\u3002\n3. `07_\u6280\u672f\u6587\u6863/`\uff1a\u67b6\u6784\u3001\u63a5\u53e3\u3001\u6570\u636e\u6a21\u578b\u3001\u5b9e\u73b0\u65b9\u6848\u3001\u6280\u672f\u51b3\u7b56\u3002\n4. `08_\u6d4b\u8bd5\u76f8\u5173/`\uff1a\u6d4b\u8bd5\u8ba1\u5212\u3001\u6d4b\u8bd5\u7528\u4f8b\u3001\u7f3a\u9677\u3001\u9a8c\u6536\u3001\u4e0a\u7ebf\u68c0\u67e5\u3002\n5. `02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/`\uff1a\u9636\u6bb5\u3001\u89d2\u8272\u3001\u4ea4\u4ed8\u7269\u3001\u95e8\u7981\u3001\u68c0\u67e5\u6e05\u5355\u3002\n6. `01_\u4e1a\u52a1\u6d41\u7a0b/`\uff1a\u5177\u4f53\u4e1a\u52a1\u6d41\u7a0b\u3001\u4e1a\u52a1\u5bf9\u8c61\u3001\u4e1a\u52a1\u89c4\u5219\u3002\n7. `04_Agent\u68c0\u7d22/`\uff1a\u5173\u952e\u8bcd\u3001\u540c\u4e49\u8bcd\u3001\u56de\u7b54\u89c4\u5219\u3001\u6765\u6e90\u7d22\u5f15\u3002\n8. `03_\u89c4\u8303\u4e0e\u6a21\u677f/`\uff1a\u9700\u8981\u4ea7\u51fa\u6587\u6863\u6216\u8868\u5355\u65f6\u68c0\u7d22\u3002\n\n## \u56de\u7b54\u683c\u5f0f\n\n- \u5148\u7ed9\u7ed3\u8bba\u3002\n- \u518d\u6309\u9636\u6bb5\u3001\u8d1f\u8d23\u4eba\u3001\u8f93\u5165\u3001\u5173\u952e\u52a8\u4f5c\u3001\u8f93\u51fa\u3001\u68c0\u67e5\u70b9\u8bf4\u660e\u3002\n- \u6700\u540e\u6ce8\u660e\u6765\u6e90\u6587\u4ef6\u3002\n- \u82e5\u77e5\u8bc6\u5e93\u6ca1\u6709\u660e\u786e\u8bb0\u5f55\uff0c\u56de\u7b54\u201c\u77e5\u8bc6\u5e93\u672a\u660e\u786e\u8bb0\u5f55\u201d\uff0c\u5e76\u8bf4\u660e\u5efa\u8bae\u8865\u5145\u5230\u54ea\u4e2a\u6587\u4ef6\u3002\n\n## \u793a\u4f8b\u95ee\u9898\n\n- \u4e00\u4e2a\u5185\u90e8\u7cfb\u7edf\u9700\u6c42\u4ece\u63d0\u51fa\u5230\u4e0a\u7ebf\u8981\u8d70\u54ea\u4e9b\u9636\u6bb5\uff1f\n- \u9636\u6bb52.5\u6d4b\u8bd5\u63d0\u524d\u8865\u6f0f\u8981\u4ea7\u51fa\u4ec0\u4e48\uff1f\n- \u4e1a\u52a1\u4e3b\u7ba1\u5728\u9879\u76ee\u5165\u53e3\u5206\u7ea7\u4e2d\u8d1f\u8d23\u4ec0\u4e48\uff1f\n- \u4ec0\u4e48\u65f6\u5019\u9700\u8981\u524d\u7aef\u63d0\u524d\u53c2\u4e0e\u9700\u6c42\u6536\u655b\uff1f\n- \u65b0\u589e\u4e00\u6761\u4e1a\u52a1\u89c4\u5219\u540e\uff0c\u600e\u4e48\u9a8c\u8bc1 Agent \u80fd\u641c\u5230\uff1f\n- \u67d0\u4e2a\u4e1a\u52a1\u89c4\u5219\u5e94\u8be5\u8865\u5145\u5230\u54ea\u4e2a\u6a21\u677f\u91cc\uff1f\n- \u67d0\u4e2a\u9700\u6c42\u5bf9\u5e94\u54ea\u4e9b\u6d4b\u8bd5\u7528\u4f8b\uff1f\n- \u67d0\u4e2a\u6a21\u5757\u6709\u54ea\u4e9b\u63a5\u53e3\u8bf4\u660e\uff1f\n- \u8fd9\u4e2a\u9879\u76ee\u5f53\u524d\u5904\u5728\u54ea\u4e2a\u91cc\u7a0b\u7891\uff1f\n\n## \u4e1a\u52a1\u8865\u5145\u9a8c\u8bc1\u5165\u53e3\n\n- \u9700\u6c42\u6587\u6863\u76ee\u5f55\uff1a`05_\u9700\u6c42\u6587\u6863/`\n- \u91cc\u7a0b\u7891\u76ee\u5f55\uff1a`06_\u91cc\u7a0b\u7891/`\n- \u6280\u672f\u6587\u6863\u76ee\u5f55\uff1a`07_\u6280\u672f\u6587\u6863/`\n- \u6d4b\u8bd5\u76f8\u5173\u76ee\u5f55\uff1a`08_\u6d4b\u8bd5\u76f8\u5173/`\n- \u9700\u6c42\u6587\u6863\u7d22\u5f15\uff1a`05_\u9700\u6c42\u6587\u6863/\u9700\u6c42\u6587\u6863\u7d22\u5f15.md`\n- \u6d4b\u8bd5\u7528\u4f8b\u7d22\u5f15\uff1a`08_\u6d4b\u8bd5\u76f8\u5173/\u6d4b\u8bd5\u7528\u4f8b\u7d22\u5f15.md`\n- \u6a21\u677f\uff1a`03_\u89c4\u8303\u4e0e\u6a21\u677f/\u4e1a\u52a1\u89c4\u5219\u4e0e\u9700\u6c42\u8865\u5145\u6a21\u677f.md`\n- \u6d41\u7a0b\uff1a`04_Agent\u68c0\u7d22/\u77e5\u8bc6\u5e93\u6301\u7eed\u66f4\u65b0\u4e0e\u9a8c\u8bc1\u6d41\u7a0b.md`\n- \u8bb0\u5f55\uff1a`01_\u4e1a\u52a1\u6d41\u7a0b/\u4e1a\u52a1\u8865\u5145\u9a8c\u8bc1\u8bb0\u5f55.md`\n", + "backlinks": [ + "article:00_\u9996\u9875/\u77e5\u8bc6\u5e93\u9996\u9875", + "article:\u6b22\u8fce", + "article:\u77e5\u8bc6\u5e93\u4f7f\u7528\u8bf4\u660e", + "article:\u77e5\u8bc6\u5e93\u4f7f\u7528\u8bf4\u660e" + ] + } + }, + { + "id": "article:00_\u9996\u9875/\u77e5\u8bc6\u5730\u56fe", + "type": "article", + "name": "\u77e5\u8bc6\u5730\u56fe", + "filePath": "00_\u9996\u9875\\\u77e5\u8bc6\u5730\u56fe.md", + "summary": "- [[../\u77e5\u8bc6\u5e93\u4f7f\u7528\u8bf4\u660e|\u77e5\u8bc6\u5e93\u4f7f\u7528\u8bf4\u660e]] - [[../Git\u4f7f\u7528\u8bf4\u660e|Git \u4f7f\u7528\u8bf4\u660e]]", + "tags": [ + "00_\u9996\u9875", + "[\u77e5\u8bc6\u5730\u56fe", + "\u5bfc\u822a]" + ], + "complexity": "complex", + "knowledgeMeta": { + "wikilinks": [ + "../\u77e5\u8bc6\u5e93\u4f7f\u7528\u8bf4\u660e", + "../Git\u4f7f\u7528\u8bf4\u660e", + "../05_\u9700\u6c42\u6587\u6863/README", + "../05_\u9700\u6c42\u6587\u6863/\u9700\u6c42\u6587\u6863\u7d22\u5f15", + "../03_\u89c4\u8303\u4e0e\u6a21\u677f/\u9700\u6c42\u8bf4\u660e\u6a21\u677f", + "../03_\u89c4\u8303\u4e0e\u6a21\u677f/\u4e1a\u52a1\u89c4\u5219\u4e0e\u9700\u6c42\u8865\u5145\u6a21\u677f", + "../01_\u4e1a\u52a1\u6d41\u7a0b/\u4e1a\u52a1\u89c4\u5219\u7d22\u5f15", + "../01_\u4e1a\u52a1\u6d41\u7a0b/\u4e1a\u52a1\u5bf9\u8c61\u5b57\u5178", + "../06_\u91cc\u7a0b\u7891/README", + "../06_\u91cc\u7a0b\u7891/\u91cc\u7a0b\u7891\u7d22\u5f15", + "../06_\u91cc\u7a0b\u7891/\u9636\u6bb5\u8ba1\u5212\u6a21\u677f", + "../06_\u91cc\u7a0b\u7891/\u91cc\u7a0b\u7891\u8bc4\u5ba1\u8bb0\u5f55", + "../02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/AI\u9a71\u52a8\u5185\u90e8\u7cfb\u7edf\u5f00\u53d1\u6d41\u7a0b_V3_\u603b\u89c8", + "../02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/\u9636\u6bb5\u4ea4\u4ed8\u7269\u6e05\u5355", + "../02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/\u9879\u76ee\u68c0\u67e5\u6e05\u5355", + "../07_\u6280\u672f\u6587\u6863/README", + "../07_\u6280\u672f\u6587\u6863/\u6280\u672f\u6587\u6863\u7d22\u5f15", + "../07_\u6280\u672f\u6587\u6863/\u7cfb\u7edf\u67b6\u6784\u8bf4\u660e\u6a21\u677f", + "../07_\u6280\u672f\u6587\u6863/\u63a5\u53e3\u8bf4\u660e\u6a21\u677f", + "../07_\u6280\u672f\u6587\u6863/\u6280\u672f\u51b3\u7b56\u8bb0\u5f55", + "../08_\u6d4b\u8bd5\u76f8\u5173/README", + "../08_\u6d4b\u8bd5\u76f8\u5173/\u6d4b\u8bd5\u7528\u4f8b\u7d22\u5f15", + "../08_\u6d4b\u8bd5\u76f8\u5173/\u6d4b\u8bd5\u7528\u4f8b\u6a21\u677f", + "../08_\u6d4b\u8bd5\u76f8\u5173/\u6d4b\u8bd5\u8ba1\u5212\u6a21\u677f", + "../08_\u6d4b\u8bd5\u76f8\u5173/\u7f3a\u9677\u8bb0\u5f55\u6a21\u677f", + "../08_\u6d4b\u8bd5\u76f8\u5173/\u9a8c\u6536\u8bb0\u5f55\u6a21\u677f", + "../08_\u6d4b\u8bd5\u76f8\u5173/\u4e0a\u7ebf\u68c0\u67e5\u6a21\u677f", + "../02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/\u9636\u6bb52.5_\u6d4b\u8bd5\u63d0\u524d\u8865\u6f0f", + "../02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/\u9636\u6bb54_\u6d4b\u8bd5\u57f9\u8bad\u4e0a\u7ebf\u56de\u6d41", + "../04_Agent\u68c0\u7d22/\u68c0\u7d22\u8bf4\u660e", + "../04_Agent\u68c0\u7d22/\u95ee\u7b54\u63d0\u793a\u8bcd", + "../04_Agent\u68c0\u7d22/\u5173\u952e\u8bcd\u7d22\u5f15", + "../04_Agent\u68c0\u7d22/\u540c\u4e49\u8bcd\u8868", + "../04_Agent\u68c0\u7d22/\u6765\u6e90\u6587\u4ef6\u7d22\u5f15", + "../04_Agent\u68c0\u7d22/\u77e5\u8bc6\u5e93\u6301\u7eed\u66f4\u65b0\u4e0e\u9a8c\u8bc1\u6d41\u7a0b" + ], + "content": "---\ntype: map\ntags: [\u77e5\u8bc6\u5730\u56fe, \u5bfc\u822a]\naliases: [\u77e5\u8bc6\u5e93\u5730\u56fe]\nsource: manual\nstatus: active\nowner: \u5185\u90e8\u6280\u672f\u56e2\u961f\nupdated: 2026-05\n---\n\n# \u77e5\u8bc6\u5730\u56fe\n\n## \u4f7f\u7528\u8bf4\u660e\n\n- [[../\u77e5\u8bc6\u5e93\u4f7f\u7528\u8bf4\u660e|\u77e5\u8bc6\u5e93\u4f7f\u7528\u8bf4\u660e]]\n- [[../Git\u4f7f\u7528\u8bf4\u660e|Git \u4f7f\u7528\u8bf4\u660e]]\n\n## \u9700\u6c42\u6587\u6863\n\n- [[../05_\u9700\u6c42\u6587\u6863/README|\u9700\u6c42\u6587\u6863\u5165\u53e3]]\n- [[../05_\u9700\u6c42\u6587\u6863/\u9700\u6c42\u6587\u6863\u7d22\u5f15|\u9700\u6c42\u6587\u6863\u7d22\u5f15]]\n- [[../03_\u89c4\u8303\u4e0e\u6a21\u677f/\u9700\u6c42\u8bf4\u660e\u6a21\u677f|\u9700\u6c42\u8bf4\u660e\u6a21\u677f]]\n- [[../03_\u89c4\u8303\u4e0e\u6a21\u677f/\u4e1a\u52a1\u89c4\u5219\u4e0e\u9700\u6c42\u8865\u5145\u6a21\u677f|\u4e1a\u52a1\u89c4\u5219\u4e0e\u9700\u6c42\u8865\u5145\u6a21\u677f]]\n- [[../01_\u4e1a\u52a1\u6d41\u7a0b/\u4e1a\u52a1\u89c4\u5219\u7d22\u5f15|\u4e1a\u52a1\u89c4\u5219\u7d22\u5f15]]\n- [[../01_\u4e1a\u52a1\u6d41\u7a0b/\u4e1a\u52a1\u5bf9\u8c61\u5b57\u5178|\u4e1a\u52a1\u5bf9\u8c61\u5b57\u5178]]\n\n## \u91cc\u7a0b\u7891\n\n- [[../06_\u91cc\u7a0b\u7891/README|\u91cc\u7a0b\u7891\u5165\u53e3]]\n- [[../06_\u91cc\u7a0b\u7891/\u91cc\u7a0b\u7891\u7d22\u5f15|\u91cc\u7a0b\u7891\u7d22\u5f15]]\n- [[../06_\u91cc\u7a0b\u7891/\u9636\u6bb5\u8ba1\u5212\u6a21\u677f|\u9636\u6bb5\u8ba1\u5212\u6a21\u677f]]\n- [[../06_\u91cc\u7a0b\u7891/\u91cc\u7a0b\u7891\u8bc4\u5ba1\u8bb0\u5f55|\u91cc\u7a0b\u7891\u8bc4\u5ba1\u8bb0\u5f55]]\n- [[../02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/AI\u9a71\u52a8\u5185\u90e8\u7cfb\u7edf\u5f00\u53d1\u6d41\u7a0b_V3_\u603b\u89c8|\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b\u603b\u89c8]]\n- [[../02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/\u9636\u6bb5\u4ea4\u4ed8\u7269\u6e05\u5355|\u9636\u6bb5\u4ea4\u4ed8\u7269\u6e05\u5355]]\n- [[../02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/\u9879\u76ee\u68c0\u67e5\u6e05\u5355|\u9879\u76ee\u68c0\u67e5\u6e05\u5355]]\n\n## \u6280\u672f\u6587\u6863\n\n- [[../07_\u6280\u672f\u6587\u6863/README|\u6280\u672f\u6587\u6863\u5165\u53e3]]\n- [[../07_\u6280\u672f\u6587\u6863/\u6280\u672f\u6587\u6863\u7d22\u5f15|\u6280\u672f\u6587\u6863\u7d22\u5f15]]\n- [[../07_\u6280\u672f\u6587\u6863/\u7cfb\u7edf\u67b6\u6784\u8bf4\u660e\u6a21\u677f|\u7cfb\u7edf\u67b6\u6784\u8bf4\u660e\u6a21\u677f]]\n- [[../07_\u6280\u672f\u6587\u6863/\u63a5\u53e3\u8bf4\u660e\u6a21\u677f|\u63a5\u53e3\u8bf4\u660e\u6a21\u677f]]\n- [[../07_\u6280\u672f\u6587\u6863/\u6280\u672f\u51b3\u7b56\u8bb0\u5f55|\u6280\u672f\u51b3\u7b56\u8bb0\u5f55]]\n\n## \u6d4b\u8bd5\u76f8\u5173\n\n- [[../08_\u6d4b\u8bd5\u76f8\u5173/README|\u6d4b\u8bd5\u76f8\u5173\u5165\u53e3]]\n- [[../08_\u6d4b\u8bd5\u76f8\u5173/\u6d4b\u8bd5\u7528\u4f8b\u7d22\u5f15|\u6d4b\u8bd5\u7528\u4f8b\u7d22\u5f15]]\n- [[../08_\u6d4b\u8bd5\u76f8\u5173/\u6d4b\u8bd5\u7528\u4f8b\u6a21\u677f|\u6d4b\u8bd5\u7528\u4f8b\u6a21\u677f]]\n- [[../08_\u6d4b\u8bd5\u76f8\u5173/\u6d4b\u8bd5\u8ba1\u5212\u6a21\u677f|\u6d4b\u8bd5\u8ba1\u5212\u6a21\u677f]]\n- [[../08_\u6d4b\u8bd5\u76f8\u5173/\u7f3a\u9677\u8bb0\u5f55\u6a21\u677f|\u7f3a\u9677\u8bb0\u5f55\u6a21\u677f]]\n- [[../08_\u6d4b\u8bd5\u76f8\u5173/\u9a8c\u6536\u8bb0\u5f55\u6a21\u677f|\u9a8c\u6536\u8bb0\u5f55\u6a21\u677f]]\n- [[../08_\u6d4b\u8bd5\u76f8\u5173/\u4e0a\u7ebf\u68c0\u67e5\u6a21\u677f|\u4e0a\u7ebf\u68c0\u67e5\u6a21\u677f]]\n- [[../02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/\u9636\u6bb52.5_\u6d4b\u8bd5\u63d0\u524d\u8865\u6f0f|\u9636\u6bb52.5 \u6d4b\u8bd5\u63d0\u524d\u8865\u6f0f]]\n- [[../02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/\u9636\u6bb54_\u6d4b\u8bd5\u57f9\u8bad\u4e0a\u7ebf\u56de\u6d41|\u9636\u6bb54 \u6d4b\u8bd5\u57f9\u8bad\u4e0a\u7ebf\u56de\u6d41]]\n\n## Agent \u68c0\u7d22\n\n- [[../04_Agent\u68c0\u7d22/\u68c0\u7d22\u8bf4\u660e|\u68c0\u7d22\u8bf4\u660e]]\n- [[../04_Agent\u68c0\u7d22/\u95ee\u7b54\u63d0\u793a\u8bcd|\u95ee\u7b54\u63d0\u793a\u8bcd]]\n- [[../04_Agent\u68c0\u7d22/\u5173\u952e\u8bcd\u7d22\u5f15|\u5173\u952e\u8bcd\u7d22\u5f15]]\n- [[../04_Agent\u68c0\u7d22/\u540c\u4e49\u8bcd\u8868|\u540c\u4e49\u8bcd\u8868]]\n- [[../04_Agent\u68c0\u7d22/\u6765\u6e90\u6587\u4ef6\u7d22\u5f15|\u6765\u6e90\u6587\u4ef6\u7d22\u5f15]]\n- [[../04_Agent\u68c0\u7d22/\u77e5\u8bc6\u5e93\u6301\u7eed\u66f4\u65b0\u4e0e\u9a8c\u8bc1\u6d41\u7a0b|\u6301\u7eed\u66f4\u65b0\u4e0e\u9a8c\u8bc1\u6d41\u7a0b]]\n", + "backlinks": [ + "article:00_\u9996\u9875/\u77e5\u8bc6\u5e93\u9996\u9875", + "article:\u6b22\u8fce", + "article:\u77e5\u8bc6\u5e93\u4f7f\u7528\u8bf4\u660e", + "article:\u77e5\u8bc6\u5e93\u4f7f\u7528\u8bf4\u660e" + ] + } + }, + { + "id": "article:00_\u9996\u9875/\u77e5\u8bc6\u5e93\u9996\u9875", + "type": "article", + "name": "\u5982\u613f\u77e5\u8bc6\u5e93\u9996\u9875", + "filePath": "00_\u9996\u9875\\\u77e5\u8bc6\u5e93\u9996\u9875.md", + "summary": "\u672c\u77e5\u8bc6\u5e93\u7528\u4e8e\u6c89\u6dc0\u5982\u613f\u5185\u90e8\u7cfb\u7edf\u5efa\u8bbe\u4e2d\u7684\u4e1a\u52a1\u6d41\u7a0b\u3001\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b\u3001\u89d2\u8272\u804c\u8d23\u3001\u4ea4\u4ed8\u7269\u3001\u68c0\u67e5\u6e05\u5355\u4e0e Agent \u68c0\u7d22\u95ee\u7b54\u89c4\u8303\u3002", + "tags": [ + "00_\u9996\u9875", + "[\u77e5\u8bc6\u5e93", + "\u5982\u613f]", + "\u9996\u9875" + ], + "complexity": "moderate", + "knowledgeMeta": { + "wikilinks": [ + "../\u77e5\u8bc6\u5e93\u4f7f\u7528\u8bf4\u660e", + "\u77e5\u8bc6\u5730\u56fe", + "Agent\u95ee\u7b54\u5165\u53e3", + "../05_\u9700\u6c42\u6587\u6863/README", + "../06_\u91cc\u7a0b\u7891/README", + "../07_\u6280\u672f\u6587\u6863/README", + "../08_\u6d4b\u8bd5\u76f8\u5173/README", + "../04_Agent\u68c0\u7d22/\u68c0\u7d22\u8bf4\u660e" + ], + "content": "---\ntype: index\ntags: [\u77e5\u8bc6\u5e93, \u9996\u9875, \u5982\u613f]\naliases: [\u5982\u613f\u77e5\u8bc6\u5e93\u9996\u9875, \u77e5\u8bc6\u5e93\u5165\u53e3]\nsource: manual\nstatus: active\nowner: \u5185\u90e8\u6280\u672f\u56e2\u961f\nupdated: 2026-05\n---\n\n# \u5982\u613f\u77e5\u8bc6\u5e93\u9996\u9875\n\n\u672c\u77e5\u8bc6\u5e93\u7528\u4e8e\u6c89\u6dc0\u5982\u613f\u5185\u90e8\u7cfb\u7edf\u5efa\u8bbe\u4e2d\u7684\u4e1a\u52a1\u6d41\u7a0b\u3001\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b\u3001\u89d2\u8272\u804c\u8d23\u3001\u4ea4\u4ed8\u7269\u3001\u68c0\u67e5\u6e05\u5355\u4e0e Agent \u68c0\u7d22\u95ee\u7b54\u89c4\u8303\u3002\n\n## \u5feb\u901f\u5165\u53e3\n\n- [[../\u77e5\u8bc6\u5e93\u4f7f\u7528\u8bf4\u660e|\u77e5\u8bc6\u5e93\u4f7f\u7528\u8bf4\u660e]]\n- [[\u77e5\u8bc6\u5730\u56fe]]\n- [[Agent\u95ee\u7b54\u5165\u53e3]]\n- [[../05_\u9700\u6c42\u6587\u6863/README|\u9700\u6c42\u6587\u6863]]\n- [[../06_\u91cc\u7a0b\u7891/README|\u91cc\u7a0b\u7891]]\n- [[../07_\u6280\u672f\u6587\u6863/README|\u6280\u672f\u6587\u6863]]\n- [[../08_\u6d4b\u8bd5\u76f8\u5173/README|\u6d4b\u8bd5\u76f8\u5173]]\n- [[../04_Agent\u68c0\u7d22/\u68c0\u7d22\u8bf4\u660e|Agent \u68c0\u7d22\u8bf4\u660e]]\n\n## \u5f53\u524d\u6743\u5a01\u6765\u6e90\n\n- \u9879\u76ee\u7ba1\u7406\u6d41\u7a0b\uff1a`AI_\u9a71\u52a8_\u5185\u90e8\u7cfb\u7edf\u5f00\u53d1\u6d41\u7a0b_V3.docx`\n- \u9002\u7528\u8303\u56f4\uff1aERP\u3001\u5185\u90e8\u7cfb\u7edf\u3001\u5c0f\u578b\u4e1a\u52a1\u7cfb\u7edf\u3001\u8fd0\u8425\u5de5\u5177\u3001AI \u8f85\u52a9\u5f00\u53d1\u9879\u76ee\u3002\n\n## \u4f7f\u7528\u539f\u5219\n\n1. \u9700\u6c42\u7c7b\u95ee\u9898\u5148\u67e5\u9700\u6c42\u6587\u6863\u3002\n2. \u8fdb\u5ea6\u3001\u8282\u70b9\u3001\u51c6\u5165\u95ee\u9898\u5148\u67e5\u91cc\u7a0b\u7891\u3002\n3. \u6280\u672f\u5b9e\u73b0\u3001\u63a5\u53e3\u3001\u67b6\u6784\u95ee\u9898\u5148\u67e5\u6280\u672f\u6587\u6863\u3002\n4. \u6d4b\u8bd5\u8303\u56f4\u3001\u7528\u4f8b\u3001\u9a8c\u6536\u3001\u7f3a\u9677\u95ee\u9898\u5148\u67e5\u6d4b\u8bd5\u76f8\u5173\u3002\n5. Agent \u56de\u7b54\u5fc5\u987b\u8bf4\u660e\u6765\u6e90\u6587\u4ef6\u3002\n6. \u77e5\u8bc6\u5e93\u6ca1\u6709\u660e\u786e\u8bb0\u5f55\u65f6\uff0c\u4e0d\u8981\u731c\u6d4b\uff0c\u5e94\u63d0\u793a\u8865\u5145\u4f4d\u7f6e\u3002\n", + "backlinks": [ + "article:\u6b22\u8fce", + "article:\u77e5\u8bc6\u5e93\u4f7f\u7528\u8bf4\u660e" + ] + } + }, + { + "id": "article:01_\u4e1a\u52a1\u6d41\u7a0b/README", + "type": "article", + "name": "\u4e1a\u52a1\u6d41\u7a0b", + "filePath": "01_\u4e1a\u52a1\u6d41\u7a0b\\README.md", + "summary": "\u672c\u76ee\u5f55\u7528\u4e8e\u6c89\u6dc0\u771f\u5b9e\u4e1a\u52a1\u6d41\u7a0b\u3002\u7b2c\u4e00\u9636\u6bb5\u5148\u5efa\u7acb\u6a21\u677f\u3001\u4e1a\u52a1\u5bf9\u8c61\u5b57\u5178\u548c\u4e1a\u52a1\u89c4\u5219\u7d22\u5f15\uff0c\u540e\u7eed\u6309\u6d41\u7a0b\u9010\u6761\u8865\u5145\u3002", + "tags": [ + "01_\u4e1a\u52a1\u6d41\u7a0b", + "[\u4e1a\u52a1\u6d41\u7a0b", + "\u5165\u53e3]" + ], + "complexity": "simple", + "knowledgeMeta": { + "wikilinks": [ + "\u4e1a\u52a1\u6d41\u7a0b\u6a21\u677f", + "\u4e1a\u52a1\u5bf9\u8c61\u5b57\u5178", + "\u4e1a\u52a1\u89c4\u5219\u7d22\u5f15", + "../02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/\u9636\u6bb51_\u4e1a\u52a1\u9700\u6c42\u5b8c\u6574\u5f62\u6210", + "../02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/\u9636\u6bb52_\u9ad8\u4fdd\u771f\u6a21\u578b\u4e0e\u4e1a\u52a1\u5bf9\u8c61\u786e\u8ba4" + ], + "content": "---\ntype: index\ntags: [\u4e1a\u52a1\u6d41\u7a0b, \u5165\u53e3]\naliases: [\u4e1a\u52a1\u6d41\u7a0b\u5165\u53e3]\nsource: manual\nstatus: active\nowner: \u4e1a\u52a1\u4e3b\u7ba1\nupdated: 2026-05\n---\n\n# \u4e1a\u52a1\u6d41\u7a0b\n\n\u672c\u76ee\u5f55\u7528\u4e8e\u6c89\u6dc0\u771f\u5b9e\u4e1a\u52a1\u6d41\u7a0b\u3002\u7b2c\u4e00\u9636\u6bb5\u5148\u5efa\u7acb\u6a21\u677f\u3001\u4e1a\u52a1\u5bf9\u8c61\u5b57\u5178\u548c\u4e1a\u52a1\u89c4\u5219\u7d22\u5f15\uff0c\u540e\u7eed\u6309\u6d41\u7a0b\u9010\u6761\u8865\u5145\u3002\n\n## \u5f53\u524d\u6587\u4ef6\n\n- [[\u4e1a\u52a1\u6d41\u7a0b\u6a21\u677f]]\n- [[\u4e1a\u52a1\u5bf9\u8c61\u5b57\u5178]]\n- [[\u4e1a\u52a1\u89c4\u5219\u7d22\u5f15]]\n\n## \u5f55\u5165\u8981\u6c42\n\n\u6bcf\u6761\u4e1a\u52a1\u6d41\u7a0b\u81f3\u5c11\u8865\u5145\uff1a\u6d41\u7a0b\u540d\u79f0\u3001\u9002\u7528\u89d2\u8272\u3001\u89e6\u53d1\u6761\u4ef6\u3001\u4e3b\u6d41\u7a0b\u3001\u5206\u652f\u6d41\u7a0b\u3001\u5f02\u5e38\u5904\u7406\u3001\u8f93\u5165\u6570\u636e\u3001\u8f93\u51fa\u7ed3\u679c\u3001\u76f8\u5173\u7cfb\u7edf\u3001\u4e1a\u52a1\u89c4\u5219\u3001\u5e38\u89c1\u95ee\u9898\u3001\u5173\u8054\u9879\u76ee\u7ba1\u7406\u9636\u6bb5\u3002\n\n## \u4e0e\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b\u7684\u5173\u7cfb\n\n\u4e1a\u52a1\u6d41\u7a0b\u5185\u5bb9\u4e3b\u8981\u7528\u4e8e\u652f\u6491 [[../02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/\u9636\u6bb51_\u4e1a\u52a1\u9700\u6c42\u5b8c\u6574\u5f62\u6210|\u9636\u6bb51 \u4e1a\u52a1\u9700\u6c42\u5b8c\u6574\u5f62\u6210]] \u548c [[../02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/\u9636\u6bb52_\u9ad8\u4fdd\u771f\u6a21\u578b\u4e0e\u4e1a\u52a1\u5bf9\u8c61\u786e\u8ba4|\u9636\u6bb52 \u9ad8\u4fdd\u771f\u6a21\u578b\u4e0e\u4e1a\u52a1\u5bf9\u8c61\u786e\u8ba4]]\u3002\n", + "backlinks": [] + } + }, + { + "id": "article:01_\u4e1a\u52a1\u6d41\u7a0b/\u4e1a\u52a1\u5bf9\u8c61\u5b57\u5178", + "type": "article", + "name": "\u4e1a\u52a1\u5bf9\u8c61\u5b57\u5178", + "filePath": "01_\u4e1a\u52a1\u6d41\u7a0b\\\u4e1a\u52a1\u5bf9\u8c61\u5b57\u5178.md", + "summary": "\u7528\u4e8e\u6c89\u6dc0\u4e1a\u52a1\u5bf9\u8c61\u3001\u5b57\u6bb5\u3001\u72b6\u6001\u548c\u751f\u547d\u5468\u671f\uff0c\u662f\u9875\u9762\u3001\u63a5\u53e3\u3001\u6570\u636e\u5e93\u3001\u6d4b\u8bd5\u3001AI \u63d0\u793a\u8bcd\u7684\u5171\u540c\u57fa\u7840\u3002", + "tags": [ + "01_\u4e1a\u52a1\u6d41\u7a0b", + "[\u4e1a\u52a1\u5bf9\u8c61", + "\u5b57\u5178]", + "\u6570\u636e\u5bf9\u8c61" + ], + "complexity": "simple", + "knowledgeMeta": { + "wikilinks": [ + "../02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/\u9636\u6bb52_\u9ad8\u4fdd\u771f\u6a21\u578b\u4e0e\u4e1a\u52a1\u5bf9\u8c61\u786e\u8ba4", + "../02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/\u9636\u6bb5\u4ea4\u4ed8\u7269\u6e05\u5355" + ], + "content": "---\ntype: dictionary\ntags: [\u4e1a\u52a1\u5bf9\u8c61, \u6570\u636e\u5bf9\u8c61, \u5b57\u5178]\naliases: [\u4e1a\u52a1\u5bf9\u8c61\u6a21\u578b, \u5bf9\u8c61\u5b57\u5178]\nsource: manual\nstatus: draft\nowner: \u4e1a\u52a1\u4e3b\u7ba1\nupdated: 2026-05\n---\n\n# \u4e1a\u52a1\u5bf9\u8c61\u5b57\u5178\n\n\u7528\u4e8e\u6c89\u6dc0\u4e1a\u52a1\u5bf9\u8c61\u3001\u5b57\u6bb5\u3001\u72b6\u6001\u548c\u751f\u547d\u5468\u671f\uff0c\u662f\u9875\u9762\u3001\u63a5\u53e3\u3001\u6570\u636e\u5e93\u3001\u6d4b\u8bd5\u3001AI \u63d0\u793a\u8bcd\u7684\u5171\u540c\u57fa\u7840\u3002\n\n## \u5bf9\u8c61\u6e05\u5355\n\n| \u4e1a\u52a1\u5bf9\u8c61 | \u5b9a\u4e49 | \u5173\u952e\u5b57\u6bb5 | \u72b6\u6001 | \u5173\u8054\u6d41\u7a0b | \u5907\u6ce8 |\n|---|---|---|---|---|---|\n| | | | | | |\n\n## \u7ef4\u62a4\u89c4\u5219\n\n- \u9636\u6bb52\u5fc5\u987b\u786e\u8ba4\u7edf\u4e00\u4e1a\u52a1\u5bf9\u8c61\u6a21\u578b\u3002\n- \u65b0\u589e\u9875\u9762\u3001\u63a5\u53e3\u3001\u6570\u636e\u5e93\u8868\u6216\u6d4b\u8bd5\u7528\u4f8b\u65f6\uff0c\u5e94\u56de\u67e5\u672c\u5b57\u5178\u3002\n- \u5b57\u6bb5\u542b\u4e49\u3001\u72b6\u6001\u679a\u4e3e\u548c\u5bf9\u8c61\u5173\u7cfb\u4e0d\u660e\u786e\u65f6\uff0c\u4e0d\u5e94\u8fdb\u5165\u6b63\u5f0f\u5f00\u53d1\u3002\n\n## \u5173\u8054\u6761\u76ee\n\n- [[../02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/\u9636\u6bb52_\u9ad8\u4fdd\u771f\u6a21\u578b\u4e0e\u4e1a\u52a1\u5bf9\u8c61\u786e\u8ba4]]\n- [[../02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/\u9636\u6bb5\u4ea4\u4ed8\u7269\u6e05\u5355]]\n", + "backlinks": [ + "article:01_\u4e1a\u52a1\u6d41\u7a0b/README", + "article:\u77e5\u8bc6\u5e93\u4f7f\u7528\u8bf4\u660e" + ] + } + }, + { + "id": "article:01_\u4e1a\u52a1\u6d41\u7a0b/\u4e1a\u52a1\u6d41\u7a0b\u6a21\u677f", + "type": "article", + "name": "\u4e1a\u52a1\u6d41\u7a0b\u6a21\u677f", + "filePath": "01_\u4e1a\u52a1\u6d41\u7a0b\\\u4e1a\u52a1\u6d41\u7a0b\u6a21\u677f.md", + "summary": "- \u6d41\u7a0b\u540d\u79f0\uff1a - \u9002\u7528\u90e8\u95e8\uff1a - \u9002\u7528\u89d2\u8272\uff1a - \u76f8\u5173\u7cfb\u7edf\uff1a - \u6d41\u7a0b\u8d1f\u8d23\u4eba\uff1a - \u5f53\u524d\u72b6\u6001\uff1adraft / active / deprecated", + "tags": [ + "01_\u4e1a\u52a1\u6d41\u7a0b", + "[\u4e1a\u52a1\u6d41\u7a0b", + "\u6a21\u677f]" + ], + "complexity": "simple", + "knowledgeMeta": { + "wikilinks": [ + "../02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/\u9636\u6bb51_\u4e1a\u52a1\u9700\u6c42\u5b8c\u6574\u5f62\u6210", + "../02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/\u9636\u6bb52_\u9ad8\u4fdd\u771f\u6a21\u578b\u4e0e\u4e1a\u52a1\u5bf9\u8c61\u786e\u8ba4" + ], + "content": "---\ntype: template\ntags: [\u4e1a\u52a1\u6d41\u7a0b, \u6a21\u677f]\naliases: [\u4e1a\u52a1\u6d41\u7a0b\u68b3\u7406\u6a21\u677f]\nsource: manual\nstatus: active\nowner: \u4e1a\u52a1\u4e3b\u7ba1\nupdated: 2026-05\n---\n\n# \u4e1a\u52a1\u6d41\u7a0b\u6a21\u677f\n\n## \u57fa\u672c\u4fe1\u606f\n\n- \u6d41\u7a0b\u540d\u79f0\uff1a\n- \u9002\u7528\u90e8\u95e8\uff1a\n- \u9002\u7528\u89d2\u8272\uff1a\n- \u76f8\u5173\u7cfb\u7edf\uff1a\n- \u6d41\u7a0b\u8d1f\u8d23\u4eba\uff1a\n- \u5f53\u524d\u72b6\u6001\uff1adraft / active / deprecated\n\n## \u89e6\u53d1\u6761\u4ef6\n\n\u8bf4\u660e\u4ec0\u4e48\u60c5\u51b5\u4e0b\u8fdb\u5165\u8be5\u6d41\u7a0b\u3002\n\n## \u524d\u7f6e\u6761\u4ef6\n\n\u8bf4\u660e\u6d41\u7a0b\u5f00\u59cb\u524d\u5fc5\u987b\u6ee1\u8db3\u7684\u6761\u4ef6\u3001\u6743\u9650\u3001\u6570\u636e\u6216\u5ba1\u6279\u3002\n\n## \u4e3b\u6d41\u7a0b\n\n1. \n2. \n3. \n\n## \u5206\u652f\u6d41\u7a0b\n\n| \u5206\u652f\u573a\u666f | \u5224\u65ad\u6761\u4ef6 | \u5904\u7406\u65b9\u5f0f | \u8d1f\u8d23\u4eba | \u8f93\u51fa |\n|---|---|---|---|---|\n| | | | | |\n\n## \u5f02\u5e38\u5904\u7406\n\n| \u5f02\u5e38\u573a\u666f | \u53d1\u73b0\u65b9\u5f0f | \u5904\u7406\u65b9\u5f0f | \u5347\u7ea7\u8def\u5f84 |\n|---|---|---|---|\n| | | | |\n\n## \u8f93\u5165\u6570\u636e\n\n| \u6570\u636e\u9879 | \u6765\u6e90 | \u5fc5\u586b | \u8bf4\u660e |\n|---|---|---|---|\n| | | | |\n\n## \u8f93\u51fa\u7ed3\u679c\n\n| \u8f93\u51fa\u7269 | \u63a5\u6536\u65b9 | \u7528\u9014 |\n|---|---|---|\n| | | |\n\n## \u4e1a\u52a1\u89c4\u5219\n\n- \n\n## \u5e38\u89c1\u95ee\u9898\n\n- \u95ee\uff1a\n \u7b54\uff1a\n\n## \u5173\u8054\u9879\u76ee\u7ba1\u7406\u9636\u6bb5\n\n- [[../02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/\u9636\u6bb51_\u4e1a\u52a1\u9700\u6c42\u5b8c\u6574\u5f62\u6210]]\n- [[../02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/\u9636\u6bb52_\u9ad8\u4fdd\u771f\u6a21\u578b\u4e0e\u4e1a\u52a1\u5bf9\u8c61\u786e\u8ba4]]\n", + "backlinks": [ + "article:01_\u4e1a\u52a1\u6d41\u7a0b/README" + ] + } + }, + { + "id": "article:01_\u4e1a\u52a1\u6d41\u7a0b/\u4e1a\u52a1\u8865\u5145\u9a8c\u8bc1\u8bb0\u5f55", + "type": "article", + "name": "\u4e1a\u52a1\u8865\u5145\u9a8c\u8bc1\u8bb0\u5f55", + "filePath": "01_\u4e1a\u52a1\u6d41\u7a0b\\\u4e1a\u52a1\u8865\u5145\u9a8c\u8bc1\u8bb0\u5f55.md", + "summary": "\u6bcf\u6b21\u65b0\u589e\u6216\u4fee\u8ba2 `01_\u4e1a\u52a1\u6d41\u7a0b/` \u4e0b\u7684\u4e1a\u52a1\u89c4\u5219\u3001\u9700\u6c42\u6216\u6d41\u7a0b\u6587\u6863\u540e\uff0c\u5728\u6b64\u8bb0\u5f55 Agent \u68c0\u7d22\u9a8c\u8bc1\u7ed3\u679c\u3002", + "tags": [ + "01_\u4e1a\u52a1\u6d41\u7a0b", + "Agent\u68c0\u7d22]", + "[\u4e1a\u52a1\u6d41\u7a0b", + "\u4e1a\u52a1\u89c4\u5219", + "\u9a8c\u8bc1\u8bb0\u5f55" + ], + "complexity": "simple", + "knowledgeMeta": { + "wikilinks": [], + "content": "---\ntype: validation_log\ntags: [\u4e1a\u52a1\u6d41\u7a0b, \u4e1a\u52a1\u89c4\u5219, \u9a8c\u8bc1\u8bb0\u5f55, Agent\u68c0\u7d22]\naliases: [\u4e1a\u52a1\u8865\u5145\u9a8c\u8bc1, Agent\u95ee\u7b54\u9a8c\u8bc1\u8bb0\u5f55]\nsource: manual\nstatus: active\nowner: \u4ea7\u54c1\u7ecf\u7406 / \u5185\u90e8\u6280\u672f\u56e2\u961f\nupdated: 2026-05\n---\n\n# \u4e1a\u52a1\u8865\u5145\u9a8c\u8bc1\u8bb0\u5f55\n\n## \u4f7f\u7528\u8bf4\u660e\n\n\u6bcf\u6b21\u65b0\u589e\u6216\u4fee\u8ba2 `01_\u4e1a\u52a1\u6d41\u7a0b/` \u4e0b\u7684\u4e1a\u52a1\u89c4\u5219\u3001\u9700\u6c42\u6216\u6d41\u7a0b\u6587\u6863\u540e\uff0c\u5728\u6b64\u8bb0\u5f55 Agent \u68c0\u7d22\u9a8c\u8bc1\u7ed3\u679c\u3002\n\n## \u9a8c\u8bc1\u8bb0\u5f55\n\n| \u65e5\u671f | \u4e1a\u52a1\u57df | \u65b0\u589e/\u4fee\u8ba2\u6587\u4ef6 | \u9a8c\u8bc1\u95ee\u9898 | \u662f\u5426\u547d\u4e2d | \u6765\u6e90\u6587\u4ef6 | \u7ed3\u679c | \u5f85\u8865\u5145 |\n|---|---|---|---|---|---|---|---|\n| | | | | \u662f/\u5426 | | \u901a\u8fc7/\u5931\u8d25 | |\n\n## \u9a8c\u8bc1\u7ed3\u8bba\u6a21\u677f\n\n```markdown\n### YYYY-MM-DD \u4e1a\u52a1\u57df_\u89c4\u5219\u6216\u9700\u6c42\u540d\u79f0\n\n- \u65b0\u589e/\u4fee\u8ba2\u6587\u4ef6\uff1a\n- \u5df2\u66f4\u65b0\u7d22\u5f15\uff1a\u4e1a\u52a1\u89c4\u5219\u7d22\u5f15 / \u4e1a\u52a1\u5bf9\u8c61\u5b57\u5178 / \u5173\u952e\u8bcd\u7d22\u5f15 / \u540c\u4e49\u8bcd\u8868 / \u6765\u6e90\u6587\u4ef6\u7d22\u5f15\n- \u9a8c\u8bc1\u95ee\u9898\uff1a\n 1. \n 2. \n 3. \n- \u7ed3\u8bba\uff1a\u901a\u8fc7 / \u5931\u8d25\n- \u5f85\u8865\u5145\uff1a\n```\n", + "backlinks": [] + } + }, + { + "id": "article:01_\u4e1a\u52a1\u6d41\u7a0b/\u4e1a\u52a1\u89c4\u5219\u7d22\u5f15", + "type": "article", + "name": "\u4e1a\u52a1\u89c4\u5219\u7d22\u5f15", + "filePath": "01_\u4e1a\u52a1\u6d41\u7a0b\\\u4e1a\u52a1\u89c4\u5219\u7d22\u5f15.md", + "summary": "\u7528\u4e8e\u96c6\u4e2d\u8bb0\u5f55\u8de8\u6d41\u7a0b\u590d\u7528\u7684\u4e1a\u52a1\u89c4\u5219\uff0c\u907f\u514d\u89c4\u5219\u6563\u843d\u5728\u9700\u6c42\u3001\u9875\u9762\u548c\u6d4b\u8bd5\u7528\u4f8b\u4e2d\u3002", + "tags": [ + "01_\u4e1a\u52a1\u6d41\u7a0b", + "[\u4e1a\u52a1\u89c4\u5219", + "\u7d22\u5f15]" + ], + "complexity": "simple", + "knowledgeMeta": { + "wikilinks": [], + "content": "---\ntype: index\ntags: [\u4e1a\u52a1\u89c4\u5219, \u7d22\u5f15]\naliases: [\u89c4\u5219\u7d22\u5f15]\nsource: manual\nstatus: draft\nowner: \u4e1a\u52a1\u4e3b\u7ba1\nupdated: 2026-05\n---\n\n# \u4e1a\u52a1\u89c4\u5219\u7d22\u5f15\n\n\u7528\u4e8e\u96c6\u4e2d\u8bb0\u5f55\u8de8\u6d41\u7a0b\u590d\u7528\u7684\u4e1a\u52a1\u89c4\u5219\uff0c\u907f\u514d\u89c4\u5219\u6563\u843d\u5728\u9700\u6c42\u3001\u9875\u9762\u548c\u6d4b\u8bd5\u7528\u4f8b\u4e2d\u3002\n\n| \u89c4\u5219\u7f16\u53f7 | \u89c4\u5219\u540d\u79f0 | \u9002\u7528\u6d41\u7a0b | \u89c4\u5219\u8bf4\u660e | \u6765\u6e90 | \u72b6\u6001 |\n|---|---|---|---|---|---|\n| BR-001 | | | | | draft |\n\n## \u7ef4\u62a4\u8981\u6c42\n\n- \u89c4\u5219\u5fc5\u987b\u80fd\u8ffd\u6eaf\u5230\u4e1a\u52a1\u6d41\u7a0b\u6216\u9879\u76ee\u6587\u6863\u3002\n- \u6d89\u53ca\u6743\u9650\u3001\u72b6\u6001\u6d41\u8f6c\u3001\u91d1\u989d\u3001\u65f6\u95f4\u3001\u5ba1\u6279\u3001\u5f02\u5e38\u5904\u7406\u7684\u89c4\u5219\u5e94\u4f18\u5148\u6c89\u6dc0\u3002\n- \u89c4\u5219\u53d8\u66f4\u540e\uff0c\u5e94\u540c\u6b65\u68c0\u67e5\u6d4b\u8bd5\u7528\u4f8b\u548c\u4e0a\u7ebf\u57f9\u8bad\u6750\u6599\u3002\n- \u65b0\u589e\u89c4\u5219\u5efa\u8bae\u4f7f\u7528 `03_\u89c4\u8303\u4e0e\u6a21\u677f/\u4e1a\u52a1\u89c4\u5219\u4e0e\u9700\u6c42\u8865\u5145\u6a21\u677f.md`\u3002\n- \u65b0\u589e\u6216\u4fee\u8ba2\u540e\uff0c\u6309 `04_Agent\u68c0\u7d22/\u77e5\u8bc6\u5e93\u6301\u7eed\u66f4\u65b0\u4e0e\u9a8c\u8bc1\u6d41\u7a0b.md` \u6267\u884c Agent \u68c0\u7d22\u9a8c\u8bc1\u3002\n", + "backlinks": [ + "article:01_\u4e1a\u52a1\u6d41\u7a0b/README", + "article:\u77e5\u8bc6\u5e93\u4f7f\u7528\u8bf4\u660e" + ] + } + }, + { + "id": "article:02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/AI\u9a71\u52a8\u5185\u90e8\u7cfb\u7edf\u5f00\u53d1\u6d41\u7a0b_V3_\u603b\u89c8", + "type": "article", + "name": "AI \u9a71\u52a8\u5185\u90e8\u7cfb\u7edf\u5f00\u53d1\u6d41\u7a0b V3 \u603b\u89c8", + "filePath": "02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b\\AI\u9a71\u52a8\u5185\u90e8\u7cfb\u7edf\u5f00\u53d1\u6d41\u7a0b_V3_\u603b\u89c8.md", + "summary": "\u672c\u6d41\u7a0b\u9002\u7528\u4e8e\u516c\u53f8\u5f53\u524d\u9636\u6bb5\u7684 ERP\u3001\u5185\u90e8\u7cfb\u7edf\u3001\u5c0f\u578b\u4e1a\u52a1\u7cfb\u7edf\u3001\u8fd0\u8425\u5de5\u5177\u3001AI \u8f85\u52a9\u5f00\u53d1\u9879\u76ee\u3002", + "tags": [ + "02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b", + "AI\u9a71\u52a8\u5f00\u53d1", + "ERP", + "[\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b", + "\u5185\u90e8\u7cfb\u7edf]" + ], + "complexity": "moderate", + "knowledgeMeta": { + "wikilinks": [ + "\u9636\u6bb50_\u9879\u76ee\u5165\u53e3\u5206\u7ea7", + "\u9636\u6bb51_\u4e1a\u52a1\u9700\u6c42\u5b8c\u6574\u5f62\u6210", + "\u9636\u6bb52_\u9ad8\u4fdd\u771f\u6a21\u578b\u4e0e\u4e1a\u52a1\u5bf9\u8c61\u786e\u8ba4", + "\u9636\u6bb52.5_\u6d4b\u8bd5\u63d0\u524d\u8865\u6f0f", + "\u9636\u6bb53_\u7814\u53d1\u534f\u4f5c\u4e0e\u6b63\u5f0f\u5f00\u53d1", + "\u9636\u6bb54_\u6d4b\u8bd5\u57f9\u8bad\u4e0a\u7ebf\u56de\u6d41", + "\u89d2\u8272\u804c\u8d23\u77e9\u9635", + "\u9636\u6bb5\u4ea4\u4ed8\u7269\u6e05\u5355", + "\u9879\u76ee\u68c0\u67e5\u6e05\u5355" + ], + "content": "---\ntype: process_overview\ntags: [\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b, AI\u9a71\u52a8\u5f00\u53d1, ERP, \u5185\u90e8\u7cfb\u7edf]\naliases: [AI\u9a71\u52a8\u5185\u90e8\u7cfb\u7edf\u5f00\u53d1\u6d41\u7a0b, \u5185\u90e8\u7cfb\u7edf\u5f00\u53d1\u6d41\u7a0bV3, ERP\u5f00\u53d1\u6d41\u7a0b]\nsource: AI_\u9a71\u52a8_\u5185\u90e8\u7cfb\u7edf\u5f00\u53d1\u6d41\u7a0b_V3.docx\nstatus: active\nowner: \u5185\u90e8\u6280\u672f\u56e2\u961f\nupdated: 2026-05\n---\n\n# AI \u9a71\u52a8\u5185\u90e8\u7cfb\u7edf\u5f00\u53d1\u6d41\u7a0b V3 \u603b\u89c8\n\n## \u7248\u672c\u5b9a\u4f4d\n\n\u672c\u6d41\u7a0b\u9002\u7528\u4e8e\u516c\u53f8\u5f53\u524d\u9636\u6bb5\u7684 ERP\u3001\u5185\u90e8\u7cfb\u7edf\u3001\u5c0f\u578b\u4e1a\u52a1\u7cfb\u7edf\u3001\u8fd0\u8425\u5de5\u5177\u3001AI \u8f85\u52a9\u5f00\u53d1\u9879\u76ee\u3002\n\n\u6838\u5fc3\u76ee\u6807\u4e0d\u662f\u8ba9\u6d41\u7a0b\u53d8\u590d\u6742\uff0c\u800c\u662f\u89e3\u51b3\u4ee5\u4e0b\u95ee\u9898\uff1a\n\n- \u4e1a\u52a1\u9700\u6c42\u8bf4\u4e0d\u6e05\u3002\n- AI \u751f\u6210\u5185\u5bb9\u4e0d\u5b8c\u6574\u3002\n- \u524d\u7aef\u6a21\u578b\u4ecb\u5165\u592a\u665a\u3002\n- \u540e\u7aef\u6570\u636e\u5e93\u8bbe\u8ba1\u88ab\u9875\u9762\u5012\u903c\u3002\n- \u6d4b\u8bd5\u592a\u665a\u624d\u53d1\u73b0\u9700\u6c42\u6f0f\u9879\u3002\n- \u9879\u76ee\u5b8c\u6210\u540e\u7559\u4e0b\u5927\u91cf\u91cd\u590d\u4ee3\u7801\u548c\u6280\u672f\u503a\u3002\n\n## \u603b\u4f53\u9636\u6bb5\n\n| \u9636\u6bb5 | \u9636\u6bb5\u540d\u79f0 | \u6838\u5fc3\u76ee\u6807 | \u6838\u5fc3\u8d1f\u8d23\u4eba |\n|---|---|---|---|\n| \u9636\u6bb50 | \u9879\u76ee\u5165\u53e3\u5206\u7ea7 | \u5224\u65ad\u9879\u76ee\u662f\u5426\u503c\u5f97\u505a\u3001\u8d70\u8f7b\u6d41\u7a0b\u8fd8\u662f\u5b8c\u6574\u6d41\u7a0b | \u4e1a\u52a1\u4e3b\u7ba1 / \u6280\u672f\u8d1f\u8d23\u4eba |\n| \u9636\u6bb51 | \u4e1a\u52a1\u9700\u6c42\u5b8c\u6574\u5f62\u6210 | \u4e1a\u52a1\u4fa7\u901a\u8fc7 Vibe Coding \u8dd1\u5b8c\u6574\u9700\u6c42 | \u4e1a\u52a1\u4e3b\u7ba1 / \u4e1a\u52a1\u4eba\u5458 |\n| \u9636\u6bb52 | \u9ad8\u4fdd\u771f\u6a21\u578b\u4e0e\u4e1a\u52a1\u5bf9\u8c61\u786e\u8ba4 | \u628a\u5b8c\u6574\u4f46\u7c97\u7cd9\u7684\u9700\u6c42\u6536\u655b\u6210\u53ef\u5f00\u53d1\u6a21\u578b | \u524d\u7aef / \u4ea7\u54c1\u7ecf\u7406 |\n| \u9636\u6bb52.5 | \u6d4b\u8bd5\u63d0\u524d\u8865\u6f0f | \u5728\u5f00\u53d1\u524d\u7528\u6d4b\u8bd5\u89c6\u89d2\u53d1\u73b0\u9700\u6c42\u6f0f\u6d1e | \u6d4b\u8bd5 |\n| \u9636\u6bb53 | \u7814\u53d1\u534f\u4f5c\u4e0e\u6b63\u5f0f\u5f00\u53d1 | \u57fa\u4e8e\u9ad8\u4fdd\u771f\u6a21\u578b\u8fdb\u884c\u6a21\u5757\u5316\u3001\u5b89\u5168\u3001\u53ef\u7ef4\u62a4\u5f00\u53d1 | \u524d\u7aef / \u540e\u7aef / \u7b97\u6cd5 |\n| \u9636\u6bb54 | \u6d4b\u8bd5\u3001\u57f9\u8bad\u3001\u4e0a\u7ebf\u3001\u56de\u6d41 | \u5b8c\u6210\u6d4b\u8bd5\u3001\u57f9\u8bad\u3001\u4e0a\u7ebf\u9a8c\u6536\u548c\u95ee\u9898\u56de\u6d41 | \u6d4b\u8bd5 / \u4e1a\u52a1\u4e3b\u7ba1 |\n| \u9636\u6bb55 | \u6280\u672f\u503a\u6cbb\u7406\u4e0e\u80fd\u529b\u6c89\u6dc0 | \u6e05\u7406 AI \u5197\u4f59\u4ee3\u7801\u5e76\u6c89\u6dc0\u590d\u7528\u80fd\u529b | \u6280\u672f\u8d1f\u8d23\u4eba |\n\n## \u9636\u6bb5\u95e8\u7981\n\n| \u95e8\u7981 | \u901a\u8fc7\u6807\u51c6 |\n|---|---|\n| Gate 0 | \u9879\u76ee\u5165\u53e3\u901a\u8fc7\uff1a\u786e\u8ba4\u503c\u5f97\u505a\uff0c\u786e\u8ba4\u9879\u76ee\u7c7b\u578b\u3002 |\n| Gate 1 | \u9700\u6c42\u5b8c\u6574\u901a\u8fc7\uff1a\u4e3b\u6d41\u7a0b\u3001\u5206\u652f\u3001\u9875\u9762\u3001\u6309\u94ae\u3001\u5b57\u6bb5\u3001\u72b6\u6001\u5927\u81f4\u5b8c\u6574\u3002 |\n| Gate 2 | \u9ad8\u4fdd\u771f\u6a21\u578b\u901a\u8fc7\uff1a\u9875\u9762\u6536\u655b\u3001\u6309\u94ae\u884c\u4e3a\u3001\u4e1a\u52a1\u5bf9\u8c61\u3001\u72b6\u6001\u3001V1/V2 \u660e\u786e\u3002 |\n| Gate 2.5 | \u6d4b\u8bd5\u8865\u6f0f\uff1a\u6d4b\u8bd5\u7528\u4f8b\u521d\u7a3f\u53d1\u73b0\u7684\u963b\u585e\u95ee\u9898\u5df2\u5904\u7406\u3002 |\n| Gate 3 | \u5f00\u53d1\u8054\u8c03\u901a\u8fc7\uff1a\u524d\u540e\u7aef\u3001\u6570\u636e\u5e93\u3001\u6743\u9650\u3001\u5b89\u5168\u3001\u4e3b\u8981\u6d41\u7a0b\u8054\u8c03\u5b8c\u6210\u3002 |\n| Gate 4 | \u4e0a\u7ebf\u9a8c\u6536\u901a\u8fc7\uff1a\u6d4b\u8bd5\u901a\u8fc7\u3001\u4e1a\u52a1\u786e\u8ba4\u3001\u57f9\u8bad\u5b8c\u6210\u3002 |\n| Gate 5 | \u6280\u672f\u503a\u6cbb\u7406\u5b8c\u6210\uff1a\u91cd\u590d\u4ee3\u7801\u3001\u7ec4\u4ef6\u3001\u63a5\u53e3\u3001\u6570\u636e\u7ed3\u6784\u5b8c\u6210\u6cbb\u7406\u6216\u8fdb\u5165\u503a\u52a1\u6c60\u3002 |\n\n## \u5b8c\u6574\u7248\u6587\u4ef6\u7ed3\u6784\n\n- `00_\u9879\u76ee\u5165\u53e3\u5206\u7ea7.md`\n- `01_\u4e3b\u6d41\u7a0b\u8bf4\u660e.md`\n- `02_\u65e5\u5e38\u64cd\u4f5c\u9875\u9762\u7ed3\u6784.md`\n- `03_\u529f\u80fd\u9875\u9762\u6309\u94ae\u76d8\u70b9\u8868.md`\n- `04_\u5206\u652f\u6d41\u7a0b_XXX.md`\n- `05_\u5f02\u5e38\u6d41\u7a0b_XXX.md`\n- `06_VibeCoding\u9875\u9762\u9a8c\u8bc1\u8bb0\u5f55.md`\n- `07_\u9ad8\u4fdd\u771f\u6a21\u578b.html`\n- `07_\u9ad8\u4fdd\u771f\u6a21\u578b\u8bf4\u660e.md`\n- `08_\u9879\u76ee\u5468\u671f\u4e0e\u7248\u672c\u786e\u8ba4.md`\n- `09_\u524d\u7aef\u6280\u672f\u8bc4\u5ba1.md`\n- `10_\u6280\u672f\u9884\u68c0\u8bb0\u5f55.md`\n- `10A_\u7edf\u4e00\u4e1a\u52a1\u5bf9\u8c61\u6a21\u578b.md`\n- `10B_\u6309\u94ae\u884c\u4e3a\u77e9\u9635.md`\n- `11_\u6d4b\u8bd5\u7528\u4f8b\u521d\u7a3f\u4e0e\u9700\u6c42\u8865\u6f0f.md`\n- `12_\u7814\u53d1\u4efb\u52a1\u62c6\u5206\u4e0e\u534f\u4f5c\u8ba1\u5212.md`\n- `13_\u6280\u672f\u5b9e\u73b0\u5bf9\u63a5.md`\n- `14_\u4ee3\u7801\u6cbb\u7406\u4e0e\u5b89\u5168\u89c4\u8303.md`\n- `15_\u5f00\u53d1\u95ee\u9898\u4e0e\u8054\u8c03\u8bb0\u5f55.md`\n- `16_\u6b63\u5f0f\u6d4b\u8bd5\u62a5\u544a.md`\n- `17_\u5185\u90e8\u57f9\u8bad\u624b\u518c.md`\n- `18_\u4e0a\u7ebf\u9a8c\u6536\u8bb0\u5f55.md`\n- `19_\u4e0a\u7ebf\u95ee\u9898\u4e0e\u56de\u6d41\u9700\u6c42.md`\n- `20_\u6280\u672f\u503a\u6e05\u5355.md`\n- `21_\u4e1a\u52a1\u539f\u5b50\u80fd\u529b\u6c89\u6dc0\u6e05\u5355.md`\n- `22_\u7ec4\u4ef6\u5e93\u4e0e\u670d\u52a1\u590d\u7528\u6e05\u5355.md`\n- `23_AI\u5f00\u53d1\u4e0a\u4e0b\u6587\u6a21\u677f\u66f4\u65b0\u8bb0\u5f55.md`\n\n## \u8f7b\u91cf\u7248\u6587\u4ef6\u7ed3\u6784\n\n\u5c0f\u9879\u76ee\u53ef\u4ee5\u4f7f\u7528\u8f7b\u91cf\u7248\uff1a\n\n- `00_\u9879\u76ee\u5165\u53e3\u5206\u7ea7.md`\n- `01_\u4e1a\u52a1\u9700\u6c42\u5305.md`\n- `02_\u9ad8\u4fdd\u771f\u6a21\u578b\u5305.md`\n- `03_\u9879\u76ee\u7248\u672c\u4e0e\u6280\u672f\u9884\u68c0.md`\n- `04_\u6d4b\u8bd5\u7528\u4f8b\u521d\u7a3f\u4e0e\u9700\u6c42\u8865\u6f0f.md`\n- `05_\u7814\u53d1\u534f\u4f5c\u4e0e\u6280\u672f\u5b9e\u73b0\u5305.md`\n- `06_\u4ee3\u7801\u6cbb\u7406\u4e0e\u5b89\u5168\u89c4\u8303.md`\n- `07_\u6d4b\u8bd5\u57f9\u8bad\u4e0a\u7ebf\u5305.md`\n- `08_\u6280\u672f\u503a\u4e0e\u80fd\u529b\u6c89\u6dc0\u5305.md`\n\n## \u6700\u7ec8\u6838\u5fc3\u539f\u5219\n\n- \u5148\u5206\u7ea7\uff0c\u518d\u5f00\u53d1\u3002\n- \u9636\u6bb51\u8ffd\u6c42\u9700\u6c42\u5b8c\u6574\uff0c\u4e0d\u8ffd\u6c42\u4ea7\u54c1\u5b8c\u5584\u3002\n- Vibe Coding \u9875\u9762\u53ea\u662f\u9700\u6c42\u539f\u578b\uff0c\u4e0d\u76f4\u63a5\u8fdb\u5165\u751f\u4ea7\u3002\n- \u9636\u6bb52\u8ffd\u6c42\u6a21\u578b\u9ad8\u6548\uff0c\u524d\u7aef\u5fc5\u987b\u6df1\u5ea6\u53c2\u4e0e\u3002\n- \u9ad8\u4fdd\u771f\u6a21\u578b\u786e\u8ba4\u540e\uff0c\u624d\u5141\u8bb8\u6b63\u5f0f\u5f00\u53d1\u3002\n- \u7edf\u4e00\u4e1a\u52a1\u5bf9\u8c61\u6a21\u578b\u662f\u9875\u9762\u3001\u63a5\u53e3\u3001\u6570\u636e\u5e93\u3001\u6d4b\u8bd5\u3001AI \u63d0\u793a\u8bcd\u7684\u5171\u540c\u57fa\u7840\u3002\n- \u6027\u80fd\u3001\u5b89\u5168\u3001\u6743\u9650\u3001\u5e76\u53d1\u3001\u65e5\u5fd7\u3001\u53ef\u56de\u6eda\u5fc5\u987b\u63d0\u524d\u9884\u68c0\u3002\n- \u6d4b\u8bd5\u63d0\u524d\u8865\u6f0f\uff0c\u4e0d\u53ea\u662f\u4e0a\u7ebf\u524d\u627e Bug\u3002\n- \u7814\u53d1\u9636\u6bb5\u4ee5\u4ee3\u7801\u8d28\u91cf\u3001\u6a21\u5757\u5316\u3001\u5b89\u5168\u6027\u3001\u53ef\u7ef4\u62a4\u6027\u4e3a\u4e2d\u5fc3\u3002\n- AI \u4ee3\u7801\u5fc5\u987b\u6cbb\u7406\uff0c\u4e0d\u80fd\u76f4\u63a5\u5806\u8fdb\u751f\u4ea7\u3002\n- \u6bcf\u4e2a\u9879\u76ee\u90fd\u8981\u6c89\u6dc0\u4e1a\u52a1\u539f\u5b50\u80fd\u529b\u3002\n- \u6bcf\u5b8c\u6210 3-4 \u4e2a\u9879\u76ee\uff0c\u5fc5\u987b\u8fdb\u884c\u6280\u672f\u503a\u6cbb\u7406\u3002\n\n## \u4e00\u53e5\u8bdd\u603b\u7ed3\n\n\u8fd9\u5957\u6d41\u7a0b\u4e0d\u662f\u4e3a\u4e86\u8ba9 AI \u66ff\u4ee3\u5f00\u53d1\uff0c\u800c\u662f\u8ba9 AI \u5e2e\u4e1a\u52a1\u66f4\u5feb\u5f62\u6210\u5b8c\u6574\u9700\u6c42\uff0c\u8ba9\u524d\u7aef\u548c\u4ea7\u54c1\u628a\u9700\u6c42\u6536\u655b\u6210\u9ad8\u4fdd\u771f\u6a21\u578b\uff0c\u8ba9\u7814\u53d1\u56e2\u961f\u57fa\u4e8e\u6a21\u578b\u9ad8\u8d28\u91cf\u5f00\u53d1\uff0c\u8ba9\u6d4b\u8bd5\u548c\u6280\u672f\u503a\u6cbb\u7406\u4fdd\u969c\u7cfb\u7edf\u957f\u671f\u53ef\u7528\u3002\n\n## \u5173\u8054\u6761\u76ee\n\n- [[\u9636\u6bb50_\u9879\u76ee\u5165\u53e3\u5206\u7ea7]]\n- [[\u9636\u6bb51_\u4e1a\u52a1\u9700\u6c42\u5b8c\u6574\u5f62\u6210]]\n- [[\u9636\u6bb52_\u9ad8\u4fdd\u771f\u6a21\u578b\u4e0e\u4e1a\u52a1\u5bf9\u8c61\u786e\u8ba4]]\n- [[\u9636\u6bb52.5_\u6d4b\u8bd5\u63d0\u524d\u8865\u6f0f]]\n- [[\u9636\u6bb53_\u7814\u53d1\u534f\u4f5c\u4e0e\u6b63\u5f0f\u5f00\u53d1]]\n- [[\u9636\u6bb54_\u6d4b\u8bd5\u57f9\u8bad\u4e0a\u7ebf\u56de\u6d41]]\n- [[\u89d2\u8272\u804c\u8d23\u77e9\u9635]]\n- [[\u9636\u6bb5\u4ea4\u4ed8\u7269\u6e05\u5355]]\n- [[\u9879\u76ee\u68c0\u67e5\u6e05\u5355]]\n", + "backlinks": [ + "article:02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/README", + "article:02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/\u5e38\u89c1\u95ee\u9898FAQ", + "article:02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/\u5e38\u89c1\u95ee\u9898FAQ", + "article:02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/\u89d2\u8272\u804c\u8d23\u77e9\u9635", + "article:02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/\u9636\u6bb50_\u9879\u76ee\u5165\u53e3\u5206\u7ea7", + "article:02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/\u9636\u6bb5\u4ea4\u4ed8\u7269\u6e05\u5355", + "article:02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/\u9879\u76ee\u68c0\u67e5\u6e05\u5355", + "article:\u77e5\u8bc6\u5e93\u4f7f\u7528\u8bf4\u660e" + ] + } + }, + { + "id": "article:02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/README", + "type": "article", + "name": "\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b", + "filePath": "02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b\\README.md", + "summary": "\u672c\u76ee\u5f55\u57fa\u4e8e `AI_\u9a71\u52a8_\u5185\u90e8\u7cfb\u7edf\u5f00\u53d1\u6d41\u7a0b_V3.docx` \u62c6\u89e3\uff0c\u7528\u4e8e\u6307\u5bfc ERP\u3001\u5185\u90e8\u7cfb\u7edf\u3001\u5c0f\u578b\u4e1a\u52a1\u7cfb\u7edf\u3001\u8fd0\u8425\u5de5\u5177\u3001AI \u8f85\u52a9\u5f00\u53d1\u9879\u76ee\u3002", + "tags": [ + "02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b", + "AI\u9a71\u52a8\u5f00\u53d1]", + "[\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b" + ], + "complexity": "moderate", + "knowledgeMeta": { + "wikilinks": [ + "AI\u9a71\u52a8\u5185\u90e8\u7cfb\u7edf\u5f00\u53d1\u6d41\u7a0b_V3_\u603b\u89c8", + "\u9636\u6bb50_\u9879\u76ee\u5165\u53e3\u5206\u7ea7", + "\u9636\u6bb51_\u4e1a\u52a1\u9700\u6c42\u5b8c\u6574\u5f62\u6210", + "\u9636\u6bb52_\u9ad8\u4fdd\u771f\u6a21\u578b\u4e0e\u4e1a\u52a1\u5bf9\u8c61\u786e\u8ba4", + "\u9636\u6bb52.5_\u6d4b\u8bd5\u63d0\u524d\u8865\u6f0f", + "\u9636\u6bb53_\u7814\u53d1\u534f\u4f5c\u4e0e\u6b63\u5f0f\u5f00\u53d1", + "\u9636\u6bb54_\u6d4b\u8bd5\u57f9\u8bad\u4e0a\u7ebf\u56de\u6d41", + "\u89d2\u8272\u804c\u8d23\u77e9\u9635", + "\u9636\u6bb5\u4ea4\u4ed8\u7269\u6e05\u5355", + "\u9879\u76ee\u68c0\u67e5\u6e05\u5355", + "\u5e38\u89c1\u95ee\u9898FAQ" + ], + "content": "---\ntype: index\ntags: [\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b, AI\u9a71\u52a8\u5f00\u53d1]\naliases: [\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b\u5165\u53e3, \u5f00\u53d1\u6d41\u7a0b\u5165\u53e3]\nsource: AI_\u9a71\u52a8_\u5185\u90e8\u7cfb\u7edf\u5f00\u53d1\u6d41\u7a0b_V3.docx\nstatus: active\nowner: \u5185\u90e8\u6280\u672f\u56e2\u961f\nupdated: 2026-05\n---\n\n# \u9879\u76ee\u7ba1\u7406\u6d41\u7a0b\n\n\u672c\u76ee\u5f55\u57fa\u4e8e `AI_\u9a71\u52a8_\u5185\u90e8\u7cfb\u7edf\u5f00\u53d1\u6d41\u7a0b_V3.docx` \u62c6\u89e3\uff0c\u7528\u4e8e\u6307\u5bfc ERP\u3001\u5185\u90e8\u7cfb\u7edf\u3001\u5c0f\u578b\u4e1a\u52a1\u7cfb\u7edf\u3001\u8fd0\u8425\u5de5\u5177\u3001AI \u8f85\u52a9\u5f00\u53d1\u9879\u76ee\u3002\n\n## \u9636\u6bb5\u6587\u4ef6\n\n- [[AI\u9a71\u52a8\u5185\u90e8\u7cfb\u7edf\u5f00\u53d1\u6d41\u7a0b_V3_\u603b\u89c8]]\n- [[\u9636\u6bb50_\u9879\u76ee\u5165\u53e3\u5206\u7ea7]]\n- [[\u9636\u6bb51_\u4e1a\u52a1\u9700\u6c42\u5b8c\u6574\u5f62\u6210]]\n- [[\u9636\u6bb52_\u9ad8\u4fdd\u771f\u6a21\u578b\u4e0e\u4e1a\u52a1\u5bf9\u8c61\u786e\u8ba4]]\n- [[\u9636\u6bb52.5_\u6d4b\u8bd5\u63d0\u524d\u8865\u6f0f]]\n- [[\u9636\u6bb53_\u7814\u53d1\u534f\u4f5c\u4e0e\u6b63\u5f0f\u5f00\u53d1]]\n- [[\u9636\u6bb54_\u6d4b\u8bd5\u57f9\u8bad\u4e0a\u7ebf\u56de\u6d41]]\n\n## \u91cd\u7ec4\u7d22\u5f15\n\n- [[\u89d2\u8272\u804c\u8d23\u77e9\u9635]]\n- [[\u9636\u6bb5\u4ea4\u4ed8\u7269\u6e05\u5355]]\n- [[\u9879\u76ee\u68c0\u67e5\u6e05\u5355]]\n- [[\u5e38\u89c1\u95ee\u9898FAQ]]\n\n## \u6838\u5fc3\u539f\u5219\n\n\u5148\u5206\u7ea7\uff0c\u518d\u5f00\u53d1\u3002\u9636\u6bb51\u8ffd\u6c42\u9700\u6c42\u5b8c\u6574\uff0c\u4e0d\u8ffd\u6c42\u4ea7\u54c1\u5b8c\u5584\u3002\u9ad8\u4fdd\u771f\u6a21\u578b\u786e\u8ba4\u540e\uff0c\u624d\u5141\u8bb8\u6b63\u5f0f\u5f00\u53d1\u3002\u6d4b\u8bd5\u8981\u63d0\u524d\u8865\u6f0f\u3002AI \u4ee3\u7801\u5fc5\u987b\u6cbb\u7406\uff0c\u4e0d\u80fd\u76f4\u63a5\u5806\u8fdb\u751f\u4ea7\u3002\n", + "backlinks": [] + } + }, + { + "id": "article:02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/\u5e38\u89c1\u95ee\u9898FAQ", + "type": "article", + "name": "\u5e38\u89c1\u95ee\u9898 FAQ", + "filePath": "02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b\\\u5e38\u89c1\u95ee\u9898FAQ.md", + "summary": "\u901a\u5e38\u7ecf\u8fc7\u9636\u6bb50\u9879\u76ee\u5165\u53e3\u5206\u7ea7\u3001\u9636\u6bb51\u4e1a\u52a1\u9700\u6c42\u5b8c\u6574\u5f62\u6210\u3001\u9636\u6bb52\u9ad8\u4fdd\u771f\u6a21\u578b\u4e0e\u4e1a\u52a1\u5bf9\u8c61\u786e\u8ba4\u3001\u9636\u6bb52.5\u6d4b\u8bd5\u63d0\u524d\u8865\u6f0f\u3001\u9636\u6bb53\u7814\u53d1\u534f\u4f5c\u4e0e\u6b63\u5f0f\u5f00\u53d1\u3001\u9636\u6bb54\u6d4b\u8bd5\u57f9\u8bad\u4e0a\u7ebf\u56de\u6d41\u3002\u6587\u6863\u8fd8\u5b9a\u4e49\u4e86\u9636\u6bb55\u6280\u672f\u503a\u6cbb\u7406\u4e0e\u80fd\u529b\u6c89\u6dc0\u3002", + "tags": [ + "02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b", + "FAQ", + "[\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b", + "\u95ee\u7b54]" + ], + "complexity": "moderate", + "knowledgeMeta": { + "wikilinks": [ + "AI\u9a71\u52a8\u5185\u90e8\u7cfb\u7edf\u5f00\u53d1\u6d41\u7a0b_V3_\u603b\u89c8", + "\u9636\u6bb50_\u9879\u76ee\u5165\u53e3\u5206\u7ea7", + "\u89d2\u8272\u804c\u8d23\u77e9\u9635", + "\u9636\u6bb51_\u4e1a\u52a1\u9700\u6c42\u5b8c\u6574\u5f62\u6210", + "\u9636\u6bb52.5_\u6d4b\u8bd5\u63d0\u524d\u8865\u6f0f", + "\u9636\u6bb52.5_\u6d4b\u8bd5\u63d0\u524d\u8865\u6f0f", + "\u9636\u6bb5\u4ea4\u4ed8\u7269\u6e05\u5355", + "\u9636\u6bb52_\u9ad8\u4fdd\u771f\u6a21\u578b\u4e0e\u4e1a\u52a1\u5bf9\u8c61\u786e\u8ba4", + "\u9636\u6bb53_\u7814\u53d1\u534f\u4f5c\u4e0e\u6b63\u5f0f\u5f00\u53d1", + "\u9636\u6bb54_\u6d4b\u8bd5\u57f9\u8bad\u4e0a\u7ebf\u56de\u6d41", + "\u9879\u76ee\u68c0\u67e5\u6e05\u5355", + "\u9636\u6bb51_\u4e1a\u52a1\u9700\u6c42\u5b8c\u6574\u5f62\u6210", + "AI\u9a71\u52a8\u5185\u90e8\u7cfb\u7edf\u5f00\u53d1\u6d41\u7a0b_V3_\u603b\u89c8" + ], + "content": "---\ntype: faq\ntags: [\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b, FAQ, \u95ee\u7b54]\naliases: [\u6d41\u7a0b\u5e38\u89c1\u95ee\u9898, \u9879\u76ee\u7ba1\u7406\u95ee\u7b54]\nsource: AI_\u9a71\u52a8_\u5185\u90e8\u7cfb\u7edf\u5f00\u53d1\u6d41\u7a0b_V3.docx\nstatus: active\nowner: \u5185\u90e8\u6280\u672f\u56e2\u961f\nupdated: 2026-05\n---\n\n# \u5e38\u89c1\u95ee\u9898 FAQ\n\n## \u4e00\u4e2a\u5185\u90e8\u7cfb\u7edf\u9700\u6c42\u4ece\u63d0\u51fa\u5230\u4e0a\u7ebf\u8981\u8d70\u54ea\u4e9b\u9636\u6bb5\uff1f\n\n\u901a\u5e38\u7ecf\u8fc7\u9636\u6bb50\u9879\u76ee\u5165\u53e3\u5206\u7ea7\u3001\u9636\u6bb51\u4e1a\u52a1\u9700\u6c42\u5b8c\u6574\u5f62\u6210\u3001\u9636\u6bb52\u9ad8\u4fdd\u771f\u6a21\u578b\u4e0e\u4e1a\u52a1\u5bf9\u8c61\u786e\u8ba4\u3001\u9636\u6bb52.5\u6d4b\u8bd5\u63d0\u524d\u8865\u6f0f\u3001\u9636\u6bb53\u7814\u53d1\u534f\u4f5c\u4e0e\u6b63\u5f0f\u5f00\u53d1\u3001\u9636\u6bb54\u6d4b\u8bd5\u57f9\u8bad\u4e0a\u7ebf\u56de\u6d41\u3002\u6587\u6863\u8fd8\u5b9a\u4e49\u4e86\u9636\u6bb55\u6280\u672f\u503a\u6cbb\u7406\u4e0e\u80fd\u529b\u6c89\u6dc0\u3002\n\n\u6765\u6e90\uff1a[[AI\u9a71\u52a8\u5185\u90e8\u7cfb\u7edf\u5f00\u53d1\u6d41\u7a0b_V3_\u603b\u89c8]]\n\n## \u9636\u6bb50\u9879\u76ee\u5165\u53e3\u5206\u7ea7\u7531\u8c01\u8d1f\u8d23\uff1f\n\n\u7531\u4e1a\u52a1\u4e3b\u7ba1\u548c\u6280\u672f\u8d1f\u8d23\u4eba\u5171\u540c\u8d1f\u8d23\u3002\u4e1a\u52a1\u4e3b\u7ba1\u5224\u65ad\u4e1a\u52a1\u4ef7\u503c\u548c\u8303\u56f4\uff0c\u6280\u672f\u8d1f\u8d23\u4eba\u5224\u65ad\u6280\u672f\u590d\u6742\u5ea6\u548c\u98ce\u9669\u3002\n\n\u6765\u6e90\uff1a[[\u9636\u6bb50_\u9879\u76ee\u5165\u53e3\u5206\u7ea7]]\u3001[[\u89d2\u8272\u804c\u8d23\u77e9\u9635]]\n\n## \u4e1a\u52a1\u9700\u6c42\u5b8c\u6574\u5f62\u6210\u9636\u6bb5\u7684\u76ee\u6807\u662f\u4ec0\u4e48\uff1f\n\n\u4e1a\u52a1\u4fa7\u901a\u8fc7 Vibe Coding \u8dd1\u5b8c\u6574\u9700\u6c42\u3002\u9636\u6bb51\u8ffd\u6c42\u9700\u6c42\u5b8c\u6574\uff0c\u4e0d\u8ffd\u6c42\u4ea7\u54c1\u5b8c\u5584\u3002\n\n\u6765\u6e90\uff1a[[\u9636\u6bb51_\u4e1a\u52a1\u9700\u6c42\u5b8c\u6574\u5f62\u6210]]\n\n## \u9636\u6bb52.5\u6d4b\u8bd5\u63d0\u524d\u8865\u6f0f\u5e94\u8be5\u5728\u4ec0\u4e48\u65f6\u5019\u53d1\u751f\uff1f\n\n\u53d1\u751f\u5728\u9ad8\u4fdd\u771f\u6a21\u578b\u786e\u8ba4\u540e\u3001\u6b63\u5f0f\u5f00\u53d1\u524d\u3002\n\n\u6765\u6e90\uff1a[[\u9636\u6bb52.5_\u6d4b\u8bd5\u63d0\u524d\u8865\u6f0f]]\n\n## \u9636\u6bb52.5\u6d4b\u8bd5\u63d0\u524d\u8865\u6f0f\u8981\u4ea7\u51fa\u4ec0\u4e48\uff1f\n\n\u4e3b\u8981\u4ea7\u51fa `11_\u6d4b\u8bd5\u7528\u4f8b\u521d\u7a3f\u4e0e\u9700\u6c42\u8865\u6f0f.md`\uff0c\u5e76\u5f62\u6210\u9700\u6c42\u8865\u6f0f\u8bb0\u5f55\u3001\u963b\u585e\u95ee\u9898\u6e05\u5355\u548c\u5df2\u5173\u95ed\u95ee\u9898\u6e05\u5355\u3002\n\n\u6765\u6e90\uff1a[[\u9636\u6bb52.5_\u6d4b\u8bd5\u63d0\u524d\u8865\u6f0f]]\u3001[[\u9636\u6bb5\u4ea4\u4ed8\u7269\u6e05\u5355]]\n\n## \u4ec0\u4e48\u65f6\u5019\u9700\u8981\u524d\u7aef\u63d0\u524d\u53c2\u4e0e\u9700\u6c42\u6536\u655b\uff1f\n\n\u9636\u6bb52\u5fc5\u987b\u7531\u524d\u7aef\u6df1\u5ea6\u53c2\u4e0e\u3002\u82e5\u9700\u6c42\u6d89\u53ca\u591a\u9875\u9762\u3001\u590d\u6742\u4ea4\u4e92\u3001\u6743\u9650\u3001\u72b6\u6001\u6d41\u8f6c\u3001\u6570\u636e\u7ed3\u6784\u6216\u7ec4\u4ef6\u590d\u7528\uff0c\u524d\u7aef\u5e94\u5728\u9700\u6c42\u6536\u655b\u65f6\u63d0\u524d\u53c2\u4e0e\u3002\n\n\u6765\u6e90\uff1a[[\u9636\u6bb52_\u9ad8\u4fdd\u771f\u6a21\u578b\u4e0e\u4e1a\u52a1\u5bf9\u8c61\u786e\u8ba4]]\n\n## \u7814\u53d1\u534f\u4f5c\u4e0e\u6b63\u5f0f\u5f00\u53d1\u9636\u6bb5\u5982\u4f55\u4fdd\u8bc1\u6a21\u5757\u5316\u3001\u5b89\u5168\u548c\u53ef\u7ef4\u62a4\uff1f\n\n\u4f9d\u8d56\u7edf\u4e00\u4e1a\u52a1\u5bf9\u8c61\u6a21\u578b\u3001\u7814\u53d1\u4efb\u52a1\u62c6\u5206\u3001\u6280\u672f\u5b9e\u73b0\u5bf9\u63a5\u3001\u4ee3\u7801\u6cbb\u7406\u4e0e\u5b89\u5168\u89c4\u8303\u3001\u5f00\u53d1\u95ee\u9898\u4e0e\u8054\u8c03\u8bb0\u5f55\u3002AI \u4ee3\u7801\u5fc5\u987b\u7ecf\u8fc7\u6cbb\u7406\uff0c\u4e0d\u80fd\u76f4\u63a5\u5806\u8fdb\u751f\u4ea7\u3002\n\n\u6765\u6e90\uff1a[[\u9636\u6bb53_\u7814\u53d1\u534f\u4f5c\u4e0e\u6b63\u5f0f\u5f00\u53d1]]\n\n## \u4e0a\u7ebf\u524d\u9700\u8981\u68c0\u67e5\u54ea\u4e9b\u4e8b\u9879\uff1f\n\n\u81f3\u5c11\u68c0\u67e5\u6b63\u5f0f\u6d4b\u8bd5\u3001\u4e3b\u6d41\u7a0b\u3001\u5206\u652f\u6d41\u7a0b\u3001\u6743\u9650\u3001\u5f02\u5e38\u3001\u6570\u636e\u8fb9\u754c\u3001\u5185\u90e8\u57f9\u8bad\u624b\u518c\u3001\u4e1a\u52a1\u786e\u8ba4\u3001\u4e0a\u7ebf\u95ee\u9898\u56de\u6d41\u673a\u5236\u3002\n\n\u6765\u6e90\uff1a[[\u9636\u6bb54_\u6d4b\u8bd5\u57f9\u8bad\u4e0a\u7ebf\u56de\u6d41]]\u3001[[\u9879\u76ee\u68c0\u67e5\u6e05\u5355]]\n\n## Vibe Coding \u9875\u9762\u80fd\u4e0d\u80fd\u76f4\u63a5\u8fdb\u5165\u751f\u4ea7\uff1f\n\n\u4e0d\u80fd\u3002Vibe Coding \u9875\u9762\u53ea\u662f\u9700\u6c42\u539f\u578b\uff0c\u4e0d\u76f4\u63a5\u8fdb\u5165\u751f\u4ea7\u3002\n\n\u6765\u6e90\uff1a[[\u9636\u6bb51_\u4e1a\u52a1\u9700\u6c42\u5b8c\u6574\u5f62\u6210]]\u3001[[AI\u9a71\u52a8\u5185\u90e8\u7cfb\u7edf\u5f00\u53d1\u6d41\u7a0b_V3_\u603b\u89c8]]\n", + "backlinks": [ + "article:02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/README" + ] + } + }, + { + "id": "article:02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/\u89d2\u8272\u804c\u8d23\u77e9\u9635", + "type": "article", + "name": "\u89d2\u8272\u804c\u8d23\u77e9\u9635", + "filePath": "02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b\\\u89d2\u8272\u804c\u8d23\u77e9\u9635.md", + "summary": "| \u89d2\u8272 | \u4e3b\u8981\u8d1f\u8d23\u9636\u6bb5 | \u6838\u5fc3\u804c\u8d23 | \u5178\u578b\u4ea7\u51fa | |---|---|---|---| | \u4e1a\u52a1\u4e3b\u7ba1 | \u9636\u6bb50\u3001\u9636\u6bb51\u3001\u9636\u6bb54 | \u5224\u65ad\u9879\u76ee\u4ef7\u503c\u3001\u660e\u786e\u4e3b\u6d41\u7a0b\u3001\u786e\u8ba4\u4e1a\u52a1\u5b8c\u6574\u6027\u3001\u4e0a\u7ebf\u9a8c\u6536 | \u9879\u76ee\u5165\u53e3\u5206\u7ea7\u3001\u4e3b\u6d41\u7a0b\u8bf4\u660e\u3001\u4e1a\u52a1\u9a8c\u6536\u53e3\u5f84\u3001\u4e0a\u7ebf\u9a8c\u6536\u8bb0\u5f55 | | \u4e1a\u52a1\u4eba\u5458 | \u9636\u6bb51 | \u8865\u5145\u5206\u652f\u6d41\u7a0b\u3001\u63d0\u4f9b\u6837\u672c\u6570\u636e\u3001\u9a8c\u8bc1\u771f\u5b9e\u64cd\u4f5c\u8def\u5f84 | \u5206\u652f\u6d41\u7a0b\u3001\u5f02\u5e38\u6d41\u7a0b\u3001Vibe Coding \u9875\u9762\u9a8c\u8bc1\u8bb0\u5f55 ...", + "tags": [ + "02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b", + "RACI]", + "[\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b", + "\u89d2\u8272\u804c\u8d23" + ], + "complexity": "simple", + "knowledgeMeta": { + "wikilinks": [ + "AI\u9a71\u52a8\u5185\u90e8\u7cfb\u7edf\u5f00\u53d1\u6d41\u7a0b_V3_\u603b\u89c8", + "\u9636\u6bb50_\u9879\u76ee\u5165\u53e3\u5206\u7ea7", + "\u9636\u6bb51_\u4e1a\u52a1\u9700\u6c42\u5b8c\u6574\u5f62\u6210", + "\u9636\u6bb52.5_\u6d4b\u8bd5\u63d0\u524d\u8865\u6f0f", + "\u9636\u6bb54_\u6d4b\u8bd5\u57f9\u8bad\u4e0a\u7ebf\u56de\u6d41" + ], + "content": "---\ntype: responsibility_matrix\ntags: [\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b, \u89d2\u8272\u804c\u8d23, RACI]\naliases: [\u89d2\u8272\u804c\u8d23, \u804c\u8d23\u77e9\u9635, RACI]\nsource: AI_\u9a71\u52a8_\u5185\u90e8\u7cfb\u7edf\u5f00\u53d1\u6d41\u7a0b_V3.docx\nstatus: active\nowner: \u5185\u90e8\u6280\u672f\u56e2\u961f\nupdated: 2026-05\n---\n\n# \u89d2\u8272\u804c\u8d23\u77e9\u9635\n\n## \u603b\u89c8\n\n| \u89d2\u8272 | \u4e3b\u8981\u8d1f\u8d23\u9636\u6bb5 | \u6838\u5fc3\u804c\u8d23 | \u5178\u578b\u4ea7\u51fa |\n|---|---|---|---|\n| \u4e1a\u52a1\u4e3b\u7ba1 | \u9636\u6bb50\u3001\u9636\u6bb51\u3001\u9636\u6bb54 | \u5224\u65ad\u9879\u76ee\u4ef7\u503c\u3001\u660e\u786e\u4e3b\u6d41\u7a0b\u3001\u786e\u8ba4\u4e1a\u52a1\u5b8c\u6574\u6027\u3001\u4e0a\u7ebf\u9a8c\u6536 | \u9879\u76ee\u5165\u53e3\u5206\u7ea7\u3001\u4e3b\u6d41\u7a0b\u8bf4\u660e\u3001\u4e1a\u52a1\u9a8c\u6536\u53e3\u5f84\u3001\u4e0a\u7ebf\u9a8c\u6536\u8bb0\u5f55 |\n| \u4e1a\u52a1\u4eba\u5458 | \u9636\u6bb51 | \u8865\u5145\u5206\u652f\u6d41\u7a0b\u3001\u63d0\u4f9b\u6837\u672c\u6570\u636e\u3001\u9a8c\u8bc1\u771f\u5b9e\u64cd\u4f5c\u8def\u5f84 | \u5206\u652f\u6d41\u7a0b\u3001\u5f02\u5e38\u6d41\u7a0b\u3001Vibe Coding \u9875\u9762\u9a8c\u8bc1\u8bb0\u5f55 |\n| \u4ea7\u54c1\u7ecf\u7406 | \u9636\u6bb52 | \u6536\u655b\u9700\u6c42\u3001\u7ec4\u7ec7\u9ad8\u4fdd\u771f\u6a21\u578b\u3001\u660e\u786e\u7248\u672c\u8303\u56f4 | \u9ad8\u4fdd\u771f\u6a21\u578b\u8bf4\u660e\u3001\u9879\u76ee\u5468\u671f\u4e0e\u7248\u672c\u786e\u8ba4 |\n| \u524d\u7aef | \u9636\u6bb52\u3001\u9636\u6bb53 | \u6df1\u5ea6\u53c2\u4e0e\u6a21\u578b\u6536\u655b\u3001\u9875\u9762\u7ed3\u6784\u3001\u6309\u94ae\u884c\u4e3a\u3001\u7ec4\u4ef6\u590d\u7528\u3001\u524d\u7aef\u5f00\u53d1 | \u9ad8\u4fdd\u771f\u6a21\u578b\u3001\u524d\u7aef\u6280\u672f\u8bc4\u5ba1\u3001\u6309\u94ae\u884c\u4e3a\u77e9\u9635\u3001\u524d\u7aef\u5b9e\u73b0 |\n| \u540e\u7aef | \u9636\u6bb53 | \u8bbe\u8ba1\u63a5\u53e3\u3001\u6570\u636e\u5e93\u3001\u6743\u9650\u3001\u5b89\u5168\u3001\u65e5\u5fd7\u3001\u56de\u6eda\u548c\u670d\u52a1\u80fd\u529b | \u6280\u672f\u5b9e\u73b0\u5bf9\u63a5\u3001\u540e\u7aef\u670d\u52a1\u3001\u63a5\u53e3\u548c\u6570\u636e\u5e93\u65b9\u6848 |\n| \u7b97\u6cd5 | \u9636\u6bb53 | \u5224\u65ad\u662f\u5426\u9700\u8981 AI\uff0c\u8bbe\u8ba1\u8f93\u5165\u8f93\u51fa\u3001\u7f6e\u4fe1\u5ea6\u3001\u4eba\u5de5\u5ba1\u6838\u548c\u98ce\u9669\u63a7\u5236 | \u7b97\u6cd5\u9002\u7528\u6027\u5224\u65ad\u3001\u7b97\u6cd5\u8f93\u5165\u8f93\u51fa\u8bf4\u660e\u3001\u7f6e\u4fe1\u5ea6\u89c4\u5219 |\n| \u6d4b\u8bd5 | \u9636\u6bb52.5\u3001\u9636\u6bb54 | \u63d0\u524d\u5199\u6d4b\u8bd5\u7528\u4f8b\u3001\u53d1\u73b0\u9700\u6c42\u6f0f\u6d1e\u3001\u6b63\u5f0f\u6d4b\u8bd5\u3001\u57f9\u8bad\u6750\u6599\u3001\u4e0a\u7ebf\u53cd\u9988 | \u6d4b\u8bd5\u7528\u4f8b\u521d\u7a3f\u3001\u6b63\u5f0f\u6d4b\u8bd5\u62a5\u544a\u3001\u5185\u90e8\u57f9\u8bad\u624b\u518c\u3001\u4e0a\u7ebf\u95ee\u9898\u56de\u6d41 |\n| \u6280\u672f\u8d1f\u8d23\u4eba | \u9636\u6bb50\u3001\u9636\u6bb55 | \u6280\u672f\u5206\u7ea7\u3001\u98ce\u9669\u5224\u65ad\u3001\u6280\u672f\u503a\u6cbb\u7406\u548c\u80fd\u529b\u6c89\u6dc0 | \u6280\u672f\u503a\u6e05\u5355\u3001\u4e1a\u52a1\u539f\u5b50\u80fd\u529b\u6c89\u6dc0\u6e05\u5355\u3001\u7ec4\u4ef6\u5e93\u4e0e\u670d\u52a1\u590d\u7528\u6e05\u5355 |\n\n## \u4e1a\u52a1\u4e3b\u7ba1\n\n\u4e1a\u52a1\u4e3b\u7ba1\u4fdd\u8bc1\u65b9\u5411\u6b63\u786e\u3001\u4e3b\u6d41\u7a0b\u6e05\u695a\u3001\u9700\u6c42\u4e0d\u6f0f\u5927\u5757\u3002\n\n\u804c\u8d23\uff1a\n\n- \u5224\u65ad\u9879\u76ee\u662f\u5426\u503c\u5f97\u505a\u3002\n- \u5b9a\u4e49\u4e3b\u6d41\u7a0b\u3002\n- \u5b9a\u4e49\u65e5\u5e38\u64cd\u4f5c\u5165\u53e3\u3002\n- \u660e\u786e\u4e1a\u52a1\u4eba\u5458\u6bcf\u5929\u5148\u770b\u4ec0\u4e48\u9875\u9762\u3002\n- \u62c6\u5206\u5206\u652f\u6d41\u7a0b\uff0c\u6307\u5b9a\u4e1a\u52a1\u4eba\u5458\u8865\u5145\u3002\n- \u786e\u8ba4\u5f02\u5e38\u6d41\u7a0b\u3002\n- \u786e\u8ba4\u4e1a\u52a1\u5b8c\u6574\u6027\u3002\n- \u53c2\u4e0e\u4e1a\u52a1\u9a8c\u6536\u3002\n\n## \u4e1a\u52a1\u4eba\u5458\n\n\u4e1a\u52a1\u4eba\u5458\u8d1f\u8d23\u5177\u4f53\u5206\u652f\u6d41\u7a0b\u548c\u771f\u5b9e\u64cd\u4f5c\u7ec6\u8282\u3002\n\n\u804c\u8d23\uff1a\n\n- \u8865\u5145\u5206\u652f\u6d41\u7a0b\u3002\n- \u63d0\u4f9b\u6837\u672c\u6570\u636e\uff0c\u4f8b\u5982 ASIN\u3001\u8ba2\u5355\u3001\u8bc4\u8bba\u3001\u7528\u6237\u3001\u8868\u683c\u7b49\u771f\u5b9e\u6837\u672c\u3002\n- \u4f7f\u7528 Vibe Coding \u8dd1\u9875\u9762\uff0c\u9a8c\u8bc1\u662f\u5426\u7b26\u5408\u771f\u5b9e\u64cd\u4f5c\u3002\n- \u8865\u5145\u5f02\u5e38\u573a\u666f\u3002\n\n## \u7b97\u6cd5\n\n\u7b97\u6cd5\u4fdd\u8bc1 AI \u80fd\u529b\u53ef\u63a7\u3001\u53ef\u89e3\u91ca\u3001\u53ef\u4eba\u5de5\u5ba1\u6838\u3002\n\n\u804c\u8d23\uff1a\n\n- \u5224\u65ad\u662f\u5426\u9700\u8981 AI\uff0c\u907f\u514d\u4e3a\u4e86 AI \u800c AI\u3002\n- \u8bbe\u8ba1\u7b97\u6cd5\u8f93\u5165\uff0c\u660e\u786e\u6a21\u578b\u9700\u8981\u54ea\u4e9b\u6570\u636e\u3002\n- \u8bbe\u8ba1\u7b97\u6cd5\u8f93\u51fa\uff0c\u660e\u786e AI \u8fd4\u56de\u4ec0\u4e48\u7ed3\u679c\u3002\n- \u5236\u5b9a\u7f6e\u4fe1\u5ea6\u89c4\u5219\u3002\n- \u5236\u5b9a\u4eba\u5de5\u5ba1\u6838\u673a\u5236\u3002\n- \u8bbe\u8ba1\u98ce\u9669\u63a7\u5236\uff0c\u786e\u4fdd AI \u5224\u65ad\u9519\u8bef\u65f6\u53ef\u4ee5\u56de\u9000\u548c\u7ea0\u6b63\u3002\n\n## \u6d4b\u8bd5\n\n\u6d4b\u8bd5\u4e0d\u53ea\u662f\u6700\u540e\u627e Bug\uff0c\u8fd8\u8981\u63d0\u524d\u8865\u6f0f\uff0c\u5e76\u8d1f\u8d23\u5185\u90e8\u57f9\u8bad\u6750\u6599\u3002\n\n\u804c\u8d23\uff1a\n\n- \u9ad8\u4fdd\u771f\u6a21\u578b\u51fa\u6765\u540e\u5148\u5199\u6d4b\u8bd5\u7528\u4f8b\u3002\n- \u7528\u6d4b\u8bd5\u89c6\u89d2\u53d1\u73b0\u6d41\u7a0b\u3001\u6309\u94ae\u3001\u6743\u9650\u9057\u6f0f\u3002\n- \u6b63\u5f0f\u6d4b\u8bd5\u4e3b\u6d41\u7a0b\u3001\u5206\u652f\u6d41\u7a0b\u3001\u6743\u9650\u3001\u5f02\u5e38\u548c\u6570\u636e\u3002\n- \u8f93\u51fa\u9a8c\u6536\u62a5\u544a\u3002\n- \u5c06\u6d4b\u8bd5\u7528\u4f8b\u8f6c\u6210\u4e1a\u52a1\u64cd\u4f5c\u624b\u518c\u3002\n- \u8bb0\u5f55\u4e0a\u7ebf\u95ee\u9898\u5e76\u56de\u6d41\u9700\u6c42\u6c60\u3002\n\n## \u5173\u8054\u6761\u76ee\n\n- [[AI\u9a71\u52a8\u5185\u90e8\u7cfb\u7edf\u5f00\u53d1\u6d41\u7a0b_V3_\u603b\u89c8]]\n- [[\u9636\u6bb50_\u9879\u76ee\u5165\u53e3\u5206\u7ea7]]\n- [[\u9636\u6bb51_\u4e1a\u52a1\u9700\u6c42\u5b8c\u6574\u5f62\u6210]]\n- [[\u9636\u6bb52.5_\u6d4b\u8bd5\u63d0\u524d\u8865\u6f0f]]\n- [[\u9636\u6bb54_\u6d4b\u8bd5\u57f9\u8bad\u4e0a\u7ebf\u56de\u6d41]]\n", + "backlinks": [ + "article:02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/AI\u9a71\u52a8\u5185\u90e8\u7cfb\u7edf\u5f00\u53d1\u6d41\u7a0b_V3_\u603b\u89c8", + "article:02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/README", + "article:02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/\u5e38\u89c1\u95ee\u9898FAQ", + "article:02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/\u9636\u6bb50_\u9879\u76ee\u5165\u53e3\u5206\u7ea7", + "article:02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/\u9636\u6bb51_\u4e1a\u52a1\u9700\u6c42\u5b8c\u6574\u5f62\u6210" + ] + } + }, + { + "id": "article:02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/\u9636\u6bb50_\u9879\u76ee\u5165\u53e3\u5206\u7ea7", + "type": "article", + "name": "\u9636\u6bb50 \u9879\u76ee\u5165\u53e3\u5206\u7ea7", + "filePath": "02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b\\\u9636\u6bb50_\u9879\u76ee\u5165\u53e3\u5206\u7ea7.md", + "summary": "\u4e0d\u662f\u6240\u6709\u9700\u6c42\u90fd\u5e94\u8be5\u8fdb\u5165\u5b8c\u6574\u5f00\u53d1\u6d41\u7a0b\u3002\u9636\u6bb50\u7528\u4e8e\u5224\u65ad\u9879\u76ee\u662f\u5426\u503c\u5f97\u505a\uff0c\u4ee5\u53ca\u8d70\u8f7b\u6d41\u7a0b\u8fd8\u662f\u5b8c\u6574\u6d41\u7a0b\u3002", + "tags": [ + "02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b", + "[\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b", + "\u5206\u7ea7", + "\u7acb\u9879]", + "\u9636\u6bb50", + "\u9879\u76ee\u5165\u53e3" + ], + "complexity": "simple", + "knowledgeMeta": { + "wikilinks": [ + "AI\u9a71\u52a8\u5185\u90e8\u7cfb\u7edf\u5f00\u53d1\u6d41\u7a0b_V3_\u603b\u89c8", + "\u89d2\u8272\u804c\u8d23\u77e9\u9635", + "\u9636\u6bb5\u4ea4\u4ed8\u7269\u6e05\u5355" + ], + "content": "---\ntype: process_stage\ntags: [\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b, \u9636\u6bb50, \u9879\u76ee\u5165\u53e3, \u5206\u7ea7, \u7acb\u9879]\naliases: [\u9879\u76ee\u5165\u53e3\u5206\u7ea7, \u5165\u53e3\u5206\u7ea7, Gate 0, \u7acb\u9879\u5206\u7ea7]\nsource: AI_\u9a71\u52a8_\u5185\u90e8\u7cfb\u7edf\u5f00\u53d1\u6d41\u7a0b_V3.docx\nstatus: active\nowner: \u4e1a\u52a1\u4e3b\u7ba1 / \u6280\u672f\u8d1f\u8d23\u4eba\nupdated: 2026-05\n---\n\n# \u9636\u6bb50 \u9879\u76ee\u5165\u53e3\u5206\u7ea7\n\n## \u6838\u5fc3\u76ee\u6807\n\n\u4e0d\u662f\u6240\u6709\u9700\u6c42\u90fd\u5e94\u8be5\u8fdb\u5165\u5b8c\u6574\u5f00\u53d1\u6d41\u7a0b\u3002\u9636\u6bb50\u7528\u4e8e\u5224\u65ad\u9879\u76ee\u662f\u5426\u503c\u5f97\u505a\uff0c\u4ee5\u53ca\u8d70\u8f7b\u6d41\u7a0b\u8fd8\u662f\u5b8c\u6574\u6d41\u7a0b\u3002\n\n## \u8d1f\u8d23\u4eba\n\n- \u4e1a\u52a1\u4e3b\u7ba1\n- \u6280\u672f\u8d1f\u8d23\u4eba\n\n## \u8f93\u5165\n\n- \u4e1a\u52a1\u63d0\u51fa\u7684\u95ee\u9898\u6216\u673a\u4f1a\u3002\n- \u73b0\u6709\u7cfb\u7edf\u75db\u70b9\u3002\n- \u4e1a\u52a1\u6536\u76ca\u3001\u98ce\u9669\u3001\u8303\u56f4\u7684\u521d\u6b65\u5224\u65ad\u3002\n\n## \u9879\u76ee\u5206\u7c7b\n\n| \u7c7b\u578b | \u9002\u7528\u573a\u666f | \u6d41\u7a0b\u8981\u6c42 |\n|---|---|---|\n| S \u7c7b | \u5c0f\u9700\u6c42\uff0c\u5355\u9875\u9762\u3001\u5c0f\u6539\u52a8\u3001\u65e0\u590d\u6742\u6570\u636e | \u53ef\u7b80\u5316\u9636\u6bb51\u548c\u9636\u6bb52\u3002 |\n| M \u7c7b | \u4e2d\u7b49\u9700\u6c42\uff0c\u6d89\u53ca\u591a\u4e2a\u9875\u9762\u3001\u591a\u4e2a\u89d2\u8272\u6216\u72b6\u6001\u6d41\u8f6c | \u5efa\u8bae\u8d70\u5b8c\u6574\u9636\u6bb50-4\u3002 |\n| L \u7c7b | \u5927\u578b\u9700\u6c42\uff0c\u6d89\u53ca\u6838\u5fc3\u6d41\u7a0b\u3001\u591a\u4e2a\u90e8\u95e8\u3001\u590d\u6742\u6743\u9650\u3001\u6570\u636e\u6a21\u578b\u6216\u7b97\u6cd5 | \u5fc5\u987b\u8d70\u5b8c\u6574\u6d41\u7a0b\uff0c\u5e76\u5f3a\u5316\u6280\u672f\u9884\u68c0\u548c\u9636\u6bb5\u95e8\u7981\u3002 |\n\n## \u5173\u952e\u52a8\u4f5c\n\n- \u5224\u65ad\u9700\u6c42\u662f\u5426\u503c\u5f97\u505a\u3002\n- \u5224\u65ad\u9879\u76ee\u5f71\u54cd\u8303\u56f4\u3002\n- \u5224\u65ad\u662f\u5426\u9700\u8981\u5b8c\u6574\u6d41\u7a0b\u3002\n- \u5224\u65ad\u662f\u5426\u6d89\u53ca\u590d\u6742\u6570\u636e\u3001\u6743\u9650\u3001\u7b97\u6cd5\u3001\u5916\u90e8\u7cfb\u7edf\u6216\u9ad8\u98ce\u9669\u6d41\u7a0b\u3002\n- \u521d\u6b65\u6307\u5b9a\u4e1a\u52a1\u8d1f\u8d23\u4eba\u548c\u6280\u672f\u8d1f\u8d23\u4eba\u3002\n\n## \u8f93\u51fa/\u4ea4\u4ed8\u7269\n\n- `00_\u9879\u76ee\u5165\u53e3\u5206\u7ea7.md`\n- \u9879\u76ee\u7c7b\u578b\uff1aS / M / L\u3002\n- \u662f\u5426\u8fdb\u5165\u5b8c\u6574\u6d41\u7a0b\u7684\u7ed3\u8bba\u3002\n- \u521d\u6b65\u8d1f\u8d23\u4eba\u3002\n- \u521d\u6b65\u8303\u56f4\u548c\u98ce\u9669\u3002\n\n## \u68c0\u67e5\u6e05\u5355\n\n- [ ] \u662f\u5426\u786e\u8ba4\u9700\u6c42\u8981\u89e3\u51b3\u7684\u771f\u5b9e\u4e1a\u52a1\u95ee\u9898\uff1f\n- [ ] \u662f\u5426\u786e\u8ba4\u8be5\u9700\u6c42\u503c\u5f97\u505a\uff1f\n- [ ] \u662f\u5426\u786e\u8ba4\u9879\u76ee\u7c7b\u578b\uff1f\n- [ ] \u662f\u5426\u786e\u8ba4\u8d70\u8f7b\u6d41\u7a0b\u8fd8\u662f\u5b8c\u6574\u6d41\u7a0b\uff1f\n- [ ] \u662f\u5426\u8bc6\u522b\u590d\u6742\u6743\u9650\u3001\u6570\u636e\u3001\u7b97\u6cd5\u3001\u5e76\u53d1\u3001\u5b89\u5168\u6216\u5916\u90e8\u7cfb\u7edf\u98ce\u9669\uff1f\n- [ ] \u662f\u5426\u660e\u786e\u4e1a\u52a1\u4e3b\u7ba1\u548c\u6280\u672f\u8d1f\u8d23\u4eba\uff1f\n\n## \u98ce\u9669\u70b9\n\n- \u5c0f\u9700\u6c42\u88ab\u8fc7\u5ea6\u6d41\u7a0b\u5316\uff0c\u964d\u4f4e\u6548\u7387\u3002\n- \u5927\u9700\u6c42\u88ab\u5f53\u6210\u5c0f\u9700\u6c42\u5904\u7406\uff0c\u540e\u7eed\u8fd4\u5de5\u3002\n- \u6ca1\u6709\u8bc6\u522b\u6743\u9650\u3001\u6570\u636e\u3001\u5b89\u5168\u3001\u7b97\u6cd5\u98ce\u9669\u3002\n- \u6ca1\u6709\u4e1a\u52a1\u8d1f\u8d23\u4eba\uff0c\u9700\u6c42\u6301\u7eed\u6f02\u79fb\u3002\n\n## Gate 0 \u901a\u8fc7\u6807\u51c6\n\n\u9879\u76ee\u5165\u53e3\u901a\u8fc7\uff1a\u786e\u8ba4\u503c\u5f97\u505a\uff0c\u786e\u8ba4\u9879\u76ee\u7c7b\u578b\u3002\n\n## \u5e38\u89c1\u95ee\u9898\n\n### \u9636\u6bb50\u7531\u8c01\u8d1f\u8d23\uff1f\n\n\u7531\u4e1a\u52a1\u4e3b\u7ba1\u548c\u6280\u672f\u8d1f\u8d23\u4eba\u5171\u540c\u8d1f\u8d23\u3002\u4e1a\u52a1\u4e3b\u7ba1\u5224\u65ad\u4e1a\u52a1\u4ef7\u503c\u548c\u4e1a\u52a1\u8303\u56f4\uff0c\u6280\u672f\u8d1f\u8d23\u4eba\u5224\u65ad\u6280\u672f\u590d\u6742\u5ea6\u548c\u98ce\u9669\u3002\n\n### \u5c0f\u9700\u6c42\u662f\u5426\u5fc5\u987b\u8d70\u5b8c\u6574\u6d41\u7a0b\uff1f\n\n\u4e0d\u4e00\u5b9a\u3002S \u7c7b\u5c0f\u9700\u6c42\u53ef\u4ee5\u7b80\u5316\u9636\u6bb51\u548c\u9636\u6bb52\uff0c\u4f46\u4ecd\u5e94\u4fdd\u7559\u57fa\u672c\u5165\u53e3\u5224\u65ad\u3001\u6d4b\u8bd5\u548c\u4e0a\u7ebf\u9a8c\u6536\u3002\n\n## \u5173\u8054\u6761\u76ee\n\n- [[AI\u9a71\u52a8\u5185\u90e8\u7cfb\u7edf\u5f00\u53d1\u6d41\u7a0b_V3_\u603b\u89c8]]\n- [[\u89d2\u8272\u804c\u8d23\u77e9\u9635]]\n- [[\u9636\u6bb5\u4ea4\u4ed8\u7269\u6e05\u5355]]\n", + "backlinks": [ + "article:02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/AI\u9a71\u52a8\u5185\u90e8\u7cfb\u7edf\u5f00\u53d1\u6d41\u7a0b_V3_\u603b\u89c8", + "article:02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/README", + "article:02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/\u5e38\u89c1\u95ee\u9898FAQ", + "article:02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/\u89d2\u8272\u804c\u8d23\u77e9\u9635", + "article:02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/\u9636\u6bb51_\u4e1a\u52a1\u9700\u6c42\u5b8c\u6574\u5f62\u6210" + ] + } + }, + { + "id": "article:02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/\u9636\u6bb51_\u4e1a\u52a1\u9700\u6c42\u5b8c\u6574\u5f62\u6210", + "type": "article", + "name": "\u9636\u6bb51 \u4e1a\u52a1\u9700\u6c42\u5b8c\u6574\u5f62\u6210", + "filePath": "02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b\\\u9636\u6bb51_\u4e1a\u52a1\u9700\u6c42\u5b8c\u6574\u5f62\u6210.md", + "summary": "\u4e1a\u52a1\u4fa7\u901a\u8fc7 Vibe Coding \u8dd1\u5b8c\u6574\u9700\u6c42\u3002\u9636\u6bb51\u8ffd\u6c42\u9700\u6c42\u5b8c\u6574\uff0c\u4e0d\u8ffd\u6c42\u4ea7\u54c1\u5b8c\u5584\u3002", + "tags": [ + "02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b", + "VibeCoding", + "[\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b", + "\u4e1a\u52a1\u9700\u6c42", + "\u9636\u6bb51", + "\u9700\u6c42\u5b8c\u6574]" + ], + "complexity": "simple", + "knowledgeMeta": { + "wikilinks": [ + "\u9636\u6bb50_\u9879\u76ee\u5165\u53e3\u5206\u7ea7", + "\u9636\u6bb52_\u9ad8\u4fdd\u771f\u6a21\u578b\u4e0e\u4e1a\u52a1\u5bf9\u8c61\u786e\u8ba4", + "\u89d2\u8272\u804c\u8d23\u77e9\u9635", + "\u9636\u6bb5\u4ea4\u4ed8\u7269\u6e05\u5355" + ], + "content": "---\ntype: process_stage\ntags: [\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b, \u9636\u6bb51, \u4e1a\u52a1\u9700\u6c42, VibeCoding, \u9700\u6c42\u5b8c\u6574]\naliases: [\u4e1a\u52a1\u9700\u6c42\u5b8c\u6574\u5f62\u6210, \u63d0\u9700\u6c42, \u9700\u6c42\u68b3\u7406, Gate 1]\nsource: AI_\u9a71\u52a8_\u5185\u90e8\u7cfb\u7edf\u5f00\u53d1\u6d41\u7a0b_V3.docx\nstatus: active\nowner: \u4e1a\u52a1\u4e3b\u7ba1 / \u4e1a\u52a1\u4eba\u5458\nupdated: 2026-05\n---\n\n# \u9636\u6bb51 \u4e1a\u52a1\u9700\u6c42\u5b8c\u6574\u5f62\u6210\n\n## \u6838\u5fc3\u76ee\u6807\n\n\u4e1a\u52a1\u4fa7\u901a\u8fc7 Vibe Coding \u8dd1\u5b8c\u6574\u9700\u6c42\u3002\u9636\u6bb51\u8ffd\u6c42\u9700\u6c42\u5b8c\u6574\uff0c\u4e0d\u8ffd\u6c42\u4ea7\u54c1\u5b8c\u5584\u3002\n\n## \u8d1f\u8d23\u4eba\n\n- \u4e1a\u52a1\u4e3b\u7ba1\n- \u4e1a\u52a1\u4eba\u5458\n\n## \u8f93\u5165\n\n- \u9636\u6bb50\u5165\u53e3\u5206\u7ea7\u7ed3\u8bba\u3002\n- \u4e1a\u52a1\u75db\u70b9\u3001\u4e1a\u52a1\u76ee\u6807\u3001\u73b0\u6709\u6d41\u7a0b\u3002\n- \u4e1a\u52a1\u4eba\u5458\u771f\u5b9e\u64cd\u4f5c\u7ecf\u9a8c\u3002\n\n## \u5173\u952e\u52a8\u4f5c\n\n- \u68b3\u7406\u4e3b\u6d41\u7a0b\u3002\n- \u660e\u786e\u65e5\u5e38\u64cd\u4f5c\u9875\u9762\u7ed3\u6784\u3002\n- \u76d8\u70b9\u529f\u80fd\u9875\u9762\u548c\u6309\u94ae\u3002\n- \u8865\u5145\u5206\u652f\u6d41\u7a0b\u3002\n- \u8865\u5145\u5f02\u5e38\u6d41\u7a0b\u3002\n- \u4f7f\u7528 Vibe Coding \u751f\u6210\u6216\u9a8c\u8bc1\u9700\u6c42\u539f\u578b\u3002\n- \u8bb0\u5f55\u9875\u9762\u9a8c\u8bc1\u7ed3\u679c\u3002\n\n## \u8f93\u51fa/\u4ea4\u4ed8\u7269\n\n- `01_\u4e3b\u6d41\u7a0b\u8bf4\u660e.md`\n- `02_\u65e5\u5e38\u64cd\u4f5c\u9875\u9762\u7ed3\u6784.md`\n- `03_\u529f\u80fd\u9875\u9762\u6309\u94ae\u76d8\u70b9\u8868.md`\n- `04_\u5206\u652f\u6d41\u7a0b_XXX.md`\n- `05_\u5f02\u5e38\u6d41\u7a0b_XXX.md`\n- `06_VibeCoding\u9875\u9762\u9a8c\u8bc1\u8bb0\u5f55.md`\n\n## \u68c0\u67e5\u6e05\u5355\n\n- [ ] \u4e3b\u6d41\u7a0b\u662f\u5426\u80fd\u4ece\u5f00\u59cb\u8d70\u5230\u7ed3\u675f\uff1f\n- [ ] \u65e5\u5e38\u64cd\u4f5c\u5165\u53e3\u662f\u5426\u6e05\u695a\uff1f\n- [ ] \u9875\u9762\u3001\u6309\u94ae\u3001\u5b57\u6bb5\u662f\u5426\u5927\u81f4\u5b8c\u6574\uff1f\n- [ ] \u5206\u652f\u6d41\u7a0b\u662f\u5426\u7531\u771f\u5b9e\u4e1a\u52a1\u4eba\u5458\u8865\u5145\uff1f\n- [ ] \u5f02\u5e38\u6d41\u7a0b\u662f\u5426\u8986\u76d6\u65e0\u8d1f\u8d23\u4eba\u3001\u8d85\u65f6\u3001\u6570\u636e\u7f3a\u5931\u7b49\u60c5\u51b5\uff1f\n- [ ] Vibe Coding \u539f\u578b\u662f\u5426\u7ecf\u8fc7\u4e1a\u52a1\u4fa7\u8d70\u67e5\uff1f\n- [ ] \u662f\u5426\u660e\u786e\u54ea\u4e9b\u5185\u5bb9\u53ea\u662f\u539f\u578b\uff0c\u4e0d\u53ef\u76f4\u63a5\u8fdb\u5165\u751f\u4ea7\uff1f\n\n## \u98ce\u9669\u70b9\n\n- \u53ea\u63cf\u8ff0\u4e3b\u6d41\u7a0b\uff0c\u6f0f\u6389\u5206\u652f\u548c\u5f02\u5e38\u3002\n- \u628a Vibe Coding \u9875\u9762\u5f53\u6210\u53ef\u751f\u4ea7\u4ee3\u7801\u3002\n- \u4e1a\u52a1\u4e3b\u7ba1\u53ea\u7ed9\u65b9\u5411\uff0c\u6ca1\u6709\u5b89\u6392\u4e1a\u52a1\u4eba\u5458\u8865\u5145\u771f\u5b9e\u64cd\u4f5c\u7ec6\u8282\u3002\n- \u9875\u9762\u3001\u6309\u94ae\u3001\u5b57\u6bb5\u672a\u76d8\u70b9\uff0c\u5bfc\u81f4\u9636\u6bb52\u548c\u5f00\u53d1\u9636\u6bb5\u8fd4\u5de5\u3002\n\n## Gate 1 \u901a\u8fc7\u6807\u51c6\n\n\u9700\u6c42\u5b8c\u6574\u901a\u8fc7\uff1a\u4e3b\u6d41\u7a0b\u3001\u5206\u652f\u3001\u9875\u9762\u3001\u6309\u94ae\u3001\u5b57\u6bb5\u3001\u72b6\u6001\u5927\u81f4\u5b8c\u6574\u3002\n\n## \u5e38\u89c1\u95ee\u9898\n\n### \u9636\u6bb51\u8ffd\u6c42\u4ec0\u4e48\uff1f\n\n\u8ffd\u6c42\u9700\u6c42\u5b8c\u6574\uff0c\u4e0d\u8ffd\u6c42\u4ea7\u54c1\u5b8c\u5584\u3002\u9875\u9762\u53ef\u4ee5\u7c97\u7cd9\uff0c\u4f46\u4e1a\u52a1\u6d41\u7a0b\u3001\u5206\u652f\u3001\u5f02\u5e38\u3001\u6309\u94ae\u3001\u5b57\u6bb5\u4e0d\u80fd\u6f0f\u5927\u5757\u3002\n\n### Vibe Coding \u9875\u9762\u80fd\u4e0d\u80fd\u76f4\u63a5\u4e0a\u7ebf\uff1f\n\n\u4e0d\u80fd\u3002Vibe Coding \u9875\u9762\u53ea\u662f\u9700\u6c42\u539f\u578b\uff0c\u4e0d\u76f4\u63a5\u8fdb\u5165\u751f\u4ea7\u3002\n\n## \u5173\u8054\u6761\u76ee\n\n- [[\u9636\u6bb50_\u9879\u76ee\u5165\u53e3\u5206\u7ea7]]\n- [[\u9636\u6bb52_\u9ad8\u4fdd\u771f\u6a21\u578b\u4e0e\u4e1a\u52a1\u5bf9\u8c61\u786e\u8ba4]]\n- [[\u89d2\u8272\u804c\u8d23\u77e9\u9635]]\n- [[\u9636\u6bb5\u4ea4\u4ed8\u7269\u6e05\u5355]]\n", + "backlinks": [ + "article:02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/AI\u9a71\u52a8\u5185\u90e8\u7cfb\u7edf\u5f00\u53d1\u6d41\u7a0b_V3_\u603b\u89c8", + "article:02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/README", + "article:02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/\u5e38\u89c1\u95ee\u9898FAQ", + "article:02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/\u5e38\u89c1\u95ee\u9898FAQ", + "article:02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/\u89d2\u8272\u804c\u8d23\u77e9\u9635", + "article:02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/\u9636\u6bb52_\u9ad8\u4fdd\u771f\u6a21\u578b\u4e0e\u4e1a\u52a1\u5bf9\u8c61\u786e\u8ba4" + ] + } + }, + { + "id": "article:02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/\u9636\u6bb52.5_\u6d4b\u8bd5\u63d0\u524d\u8865\u6f0f", + "type": "article", + "name": "\u9636\u6bb52.5 \u6d4b\u8bd5\u63d0\u524d\u8865\u6f0f", + "filePath": "02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b\\\u9636\u6bb52.5_\u6d4b\u8bd5\u63d0\u524d\u8865\u6f0f.md", + "summary": "\u5728\u5f00\u53d1\u524d\u7528\u6d4b\u8bd5\u89c6\u89d2\u53d1\u73b0\u9700\u6c42\u6f0f\u6d1e\u3002\u6d4b\u8bd5\u63d0\u524d\u8865\u6f0f\uff0c\u4e0d\u53ea\u662f\u4e0a\u7ebf\u524d\u627e Bug\u3002", + "tags": [ + "02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b", + "[\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b", + "\u6d4b\u8bd5", + "\u6d4b\u8bd5\u7528\u4f8b]", + "\u9636\u6bb52.5", + "\u9700\u6c42\u8865\u6f0f" + ], + "complexity": "simple", + "knowledgeMeta": { + "wikilinks": [ + "\u9636\u6bb52_\u9ad8\u4fdd\u771f\u6a21\u578b\u4e0e\u4e1a\u52a1\u5bf9\u8c61\u786e\u8ba4", + "\u9636\u6bb53_\u7814\u53d1\u534f\u4f5c\u4e0e\u6b63\u5f0f\u5f00\u53d1", + "\u9879\u76ee\u68c0\u67e5\u6e05\u5355" + ], + "content": "---\ntype: process_stage\ntags: [\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b, \u9636\u6bb52.5, \u6d4b\u8bd5, \u9700\u6c42\u8865\u6f0f, \u6d4b\u8bd5\u7528\u4f8b]\naliases: [\u6d4b\u8bd5\u63d0\u524d\u8865\u6f0f, \u5f00\u53d1\u524d\u6d4b\u8bd5, Gate 2.5, \u6d4b\u8bd5\u7528\u4f8b\u521d\u7a3f]\nsource: AI_\u9a71\u52a8_\u5185\u90e8\u7cfb\u7edf\u5f00\u53d1\u6d41\u7a0b_V3.docx\nstatus: active\nowner: \u6d4b\u8bd5\nupdated: 2026-05\n---\n\n# \u9636\u6bb52.5 \u6d4b\u8bd5\u63d0\u524d\u8865\u6f0f\n\n## \u6838\u5fc3\u76ee\u6807\n\n\u5728\u5f00\u53d1\u524d\u7528\u6d4b\u8bd5\u89c6\u89d2\u53d1\u73b0\u9700\u6c42\u6f0f\u6d1e\u3002\u6d4b\u8bd5\u63d0\u524d\u8865\u6f0f\uff0c\u4e0d\u53ea\u662f\u4e0a\u7ebf\u524d\u627e Bug\u3002\n\n## \u8d1f\u8d23\u4eba\n\n- \u6d4b\u8bd5\n\n## \u8f93\u5165\n\n- \u9ad8\u4fdd\u771f\u6a21\u578b\u3002\n- \u9ad8\u4fdd\u771f\u6a21\u578b\u8bf4\u660e\u3002\n- \u7edf\u4e00\u4e1a\u52a1\u5bf9\u8c61\u6a21\u578b\u3002\n- \u6309\u94ae\u884c\u4e3a\u77e9\u9635\u3002\n- \u9879\u76ee\u5468\u671f\u4e0e\u7248\u672c\u786e\u8ba4\u3002\n\n## \u5173\u952e\u52a8\u4f5c\n\n- \u57fa\u4e8e\u9ad8\u4fdd\u771f\u6a21\u578b\u5148\u5199\u6d4b\u8bd5\u7528\u4f8b\u521d\u7a3f\u3002\n- \u4ece\u4e3b\u6d41\u7a0b\u3001\u5206\u652f\u6d41\u7a0b\u3001\u6743\u9650\u3001\u5f02\u5e38\u3001\u6570\u636e\u3001\u6309\u94ae\u884c\u4e3a\u89c6\u89d2\u68c0\u67e5\u9057\u6f0f\u3002\n- \u6807\u8bb0\u963b\u585e\u5f00\u53d1\u7684\u95ee\u9898\u3002\n- \u5c06\u9700\u6c42\u6f0f\u6d1e\u56de\u6d41\u7ed9\u4e1a\u52a1\u3001\u4ea7\u54c1\u3001\u524d\u7aef\u8865\u9f50\u3002\n- \u786e\u8ba4\u963b\u585e\u95ee\u9898\u5904\u7406\u540e\u518d\u8fdb\u5165\u6b63\u5f0f\u5f00\u53d1\u3002\n\n## \u8f93\u51fa/\u4ea4\u4ed8\u7269\n\n- `11_\u6d4b\u8bd5\u7528\u4f8b\u521d\u7a3f\u4e0e\u9700\u6c42\u8865\u6f0f.md`\n- \u9700\u6c42\u8865\u6f0f\u8bb0\u5f55\u3002\n- \u963b\u585e\u95ee\u9898\u6e05\u5355\u3002\n- \u5df2\u5173\u95ed\u95ee\u9898\u6e05\u5355\u3002\n\n## \u68c0\u67e5\u6e05\u5355\n\n- [ ] \u662f\u5426\u5df2\u57fa\u4e8e\u9ad8\u4fdd\u771f\u6a21\u578b\u7f16\u5199\u6d4b\u8bd5\u7528\u4f8b\u521d\u7a3f\uff1f\n- [ ] \u662f\u5426\u8986\u76d6\u4e3b\u6d41\u7a0b\uff1f\n- [ ] \u662f\u5426\u8986\u76d6\u5206\u652f\u6d41\u7a0b\uff1f\n- [ ] \u662f\u5426\u8986\u76d6\u6743\u9650\uff1f\n- [ ] \u662f\u5426\u8986\u76d6\u5f02\u5e38\u573a\u666f\uff1f\n- [ ] \u662f\u5426\u8986\u76d6\u5173\u952e\u6570\u636e\u548c\u72b6\u6001\uff1f\n- [ ] \u662f\u5426\u8986\u76d6\u6309\u94ae\u884c\u4e3a\uff1f\n- [ ] \u6d4b\u8bd5\u53d1\u73b0\u7684\u963b\u585e\u95ee\u9898\u662f\u5426\u5df2\u5173\u95ed\uff1f\n\n## \u98ce\u9669\u70b9\n\n- \u6d4b\u8bd5\u53ea\u5728\u4e0a\u7ebf\u524d\u4ecb\u5165\uff0c\u5bfc\u81f4\u9700\u6c42\u6f0f\u6d1e\u5728\u5f00\u53d1\u540e\u624d\u66b4\u9732\u3002\n- \u6d4b\u8bd5\u7528\u4f8b\u53ea\u8986\u76d6\u4e3b\u6d41\u7a0b\uff0c\u6f0f\u6389\u6743\u9650\u3001\u5f02\u5e38\u3001\u5206\u652f\u548c\u6570\u636e\u8fb9\u754c\u3002\n- \u963b\u585e\u95ee\u9898\u6ca1\u6709\u5173\u95ed\u5c31\u8fdb\u5165\u5f00\u53d1\u3002\n\n## Gate 2.5 \u901a\u8fc7\u6807\u51c6\n\n\u6d4b\u8bd5\u8865\u6f0f\uff1a\u6d4b\u8bd5\u7528\u4f8b\u521d\u7a3f\u53d1\u73b0\u7684\u963b\u585e\u95ee\u9898\u5df2\u5904\u7406\u3002\n\n## \u5e38\u89c1\u95ee\u9898\n\n### \u9636\u6bb52.5\u5e94\u8be5\u5728\u4ec0\u4e48\u65f6\u5019\u53d1\u751f\uff1f\n\n\u53d1\u751f\u5728\u9ad8\u4fdd\u771f\u6a21\u578b\u786e\u8ba4\u540e\u3001\u6b63\u5f0f\u5f00\u53d1\u524d\u3002\n\n### \u9636\u6bb52.5\u8981\u4ea7\u51fa\u4ec0\u4e48\uff1f\n\n\u4e3b\u8981\u4ea7\u51fa `11_\u6d4b\u8bd5\u7528\u4f8b\u521d\u7a3f\u4e0e\u9700\u6c42\u8865\u6f0f.md`\uff0c\u5e76\u5f62\u6210\u9700\u6c42\u8865\u6f0f\u8bb0\u5f55\u3001\u963b\u585e\u95ee\u9898\u6e05\u5355\u548c\u5df2\u5173\u95ed\u95ee\u9898\u6e05\u5355\u3002\n\n## \u5173\u8054\u6761\u76ee\n\n- [[\u9636\u6bb52_\u9ad8\u4fdd\u771f\u6a21\u578b\u4e0e\u4e1a\u52a1\u5bf9\u8c61\u786e\u8ba4]]\n- [[\u9636\u6bb53_\u7814\u53d1\u534f\u4f5c\u4e0e\u6b63\u5f0f\u5f00\u53d1]]\n- [[\u9879\u76ee\u68c0\u67e5\u6e05\u5355]]\n", + "backlinks": [ + "article:02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/AI\u9a71\u52a8\u5185\u90e8\u7cfb\u7edf\u5f00\u53d1\u6d41\u7a0b_V3_\u603b\u89c8", + "article:02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/README", + "article:02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/\u5e38\u89c1\u95ee\u9898FAQ", + "article:02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/\u5e38\u89c1\u95ee\u9898FAQ", + "article:02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/\u89d2\u8272\u804c\u8d23\u77e9\u9635", + "article:02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/\u9636\u6bb52_\u9ad8\u4fdd\u771f\u6a21\u578b\u4e0e\u4e1a\u52a1\u5bf9\u8c61\u786e\u8ba4", + "article:02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/\u9636\u6bb53_\u7814\u53d1\u534f\u4f5c\u4e0e\u6b63\u5f0f\u5f00\u53d1" + ] + } + }, + { + "id": "article:02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/\u9636\u6bb52_\u9ad8\u4fdd\u771f\u6a21\u578b\u4e0e\u4e1a\u52a1\u5bf9\u8c61\u786e\u8ba4", + "type": "article", + "name": "\u9636\u6bb52 \u9ad8\u4fdd\u771f\u6a21\u578b\u4e0e\u4e1a\u52a1\u5bf9\u8c61\u786e\u8ba4", + "filePath": "02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b\\\u9636\u6bb52_\u9ad8\u4fdd\u771f\u6a21\u578b\u4e0e\u4e1a\u52a1\u5bf9\u8c61\u786e\u8ba4.md", + "summary": "\u628a\u5b8c\u6574\u4f46\u7c97\u7cd9\u7684\u9700\u6c42\u6536\u655b\u6210\u53ef\u5f00\u53d1\u6a21\u578b\u3002\u9636\u6bb52\u8ffd\u6c42\u6a21\u578b\u9ad8\u6548\uff0c\u524d\u7aef\u5fc5\u987b\u6df1\u5ea6\u53c2\u4e0e\u3002", + "tags": [ + "02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b", + "[\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b", + "\u4e1a\u52a1\u5bf9\u8c61", + "\u4ea7\u54c1]", + "\u524d\u7aef", + "\u9636\u6bb52", + "\u9ad8\u4fdd\u771f\u6a21\u578b" + ], + "complexity": "simple", + "knowledgeMeta": { + "wikilinks": [ + "\u9636\u6bb51_\u4e1a\u52a1\u9700\u6c42\u5b8c\u6574\u5f62\u6210", + "\u9636\u6bb52.5_\u6d4b\u8bd5\u63d0\u524d\u8865\u6f0f", + "../01_\u4e1a\u52a1\u6d41\u7a0b/\u4e1a\u52a1\u5bf9\u8c61\u5b57\u5178", + "\u9636\u6bb5\u4ea4\u4ed8\u7269\u6e05\u5355" + ], + "content": "---\ntype: process_stage\ntags: [\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b, \u9636\u6bb52, \u9ad8\u4fdd\u771f\u6a21\u578b, \u4e1a\u52a1\u5bf9\u8c61, \u524d\u7aef, \u4ea7\u54c1]\naliases: [\u9ad8\u4fdd\u771f\u6a21\u578b\u786e\u8ba4, \u4e1a\u52a1\u5bf9\u8c61\u786e\u8ba4, Gate 2, \u7edf\u4e00\u4e1a\u52a1\u5bf9\u8c61\u6a21\u578b]\nsource: AI_\u9a71\u52a8_\u5185\u90e8\u7cfb\u7edf\u5f00\u53d1\u6d41\u7a0b_V3.docx\nstatus: active\nowner: \u524d\u7aef / \u4ea7\u54c1\u7ecf\u7406\nupdated: 2026-05\n---\n\n# \u9636\u6bb52 \u9ad8\u4fdd\u771f\u6a21\u578b\u4e0e\u4e1a\u52a1\u5bf9\u8c61\u786e\u8ba4\n\n## \u6838\u5fc3\u76ee\u6807\n\n\u628a\u5b8c\u6574\u4f46\u7c97\u7cd9\u7684\u9700\u6c42\u6536\u655b\u6210\u53ef\u5f00\u53d1\u6a21\u578b\u3002\u9636\u6bb52\u8ffd\u6c42\u6a21\u578b\u9ad8\u6548\uff0c\u524d\u7aef\u5fc5\u987b\u6df1\u5ea6\u53c2\u4e0e\u3002\n\n## \u8d1f\u8d23\u4eba\n\n- \u524d\u7aef\n- \u4ea7\u54c1\u7ecf\u7406\n\n## \u8f93\u5165\n\n- \u9636\u6bb51\u5f62\u6210\u7684\u4e3b\u6d41\u7a0b\u3001\u9875\u9762\u7ed3\u6784\u3001\u6309\u94ae\u76d8\u70b9\u3001\u5206\u652f\u6d41\u7a0b\u3001\u5f02\u5e38\u6d41\u7a0b\u548c Vibe Coding \u9a8c\u8bc1\u8bb0\u5f55\u3002\n\n## \u5173\u952e\u52a8\u4f5c\n\n- \u5c06\u4e1a\u52a1\u539f\u578b\u6536\u655b\u4e3a\u9ad8\u4fdd\u771f\u6a21\u578b\u3002\n- \u660e\u786e\u9875\u9762\u7ed3\u6784\u3001\u4ea4\u4e92\u3001\u6309\u94ae\u884c\u4e3a\u548c\u72b6\u6001\u53d8\u5316\u3002\n- \u786e\u8ba4\u4e1a\u52a1\u5bf9\u8c61\u3001\u5b57\u6bb5\u3001\u72b6\u6001\u548c\u5bf9\u8c61\u5173\u7cfb\u3002\n- \u660e\u786e V1/V2 \u8303\u56f4\u548c\u9879\u76ee\u5468\u671f\u3002\n- \u8fdb\u884c\u524d\u7aef\u6280\u672f\u8bc4\u5ba1\u548c\u6280\u672f\u9884\u68c0\u3002\n- \u8bc6\u522b\u6027\u80fd\u3001\u5b89\u5168\u3001\u6743\u9650\u3001\u5e76\u53d1\u3001\u65e5\u5fd7\u3001\u53ef\u56de\u6eda\u7b49\u98ce\u9669\u3002\n\n## \u8f93\u51fa/\u4ea4\u4ed8\u7269\n\n- `07_\u9ad8\u4fdd\u771f\u6a21\u578b.html`\n- `07_\u9ad8\u4fdd\u771f\u6a21\u578b\u8bf4\u660e.md`\n- `08_\u9879\u76ee\u5468\u671f\u4e0e\u7248\u672c\u786e\u8ba4.md`\n- `09_\u524d\u7aef\u6280\u672f\u8bc4\u5ba1.md`\n- `10_\u6280\u672f\u9884\u68c0\u8bb0\u5f55.md`\n- `10A_\u7edf\u4e00\u4e1a\u52a1\u5bf9\u8c61\u6a21\u578b.md`\n- `10B_\u6309\u94ae\u884c\u4e3a\u77e9\u9635.md`\n\n## \u68c0\u67e5\u6e05\u5355\n\n- [ ] \u9875\u9762\u662f\u5426\u5df2\u7ecf\u4ece\u7c97\u7cd9\u539f\u578b\u6536\u655b\u6210\u53ef\u5f00\u53d1\u6a21\u578b\uff1f\n- [ ] \u6309\u94ae\u884c\u4e3a\u662f\u5426\u660e\u786e\uff1f\n- [ ] \u4e1a\u52a1\u5bf9\u8c61\u3001\u5b57\u6bb5\u3001\u72b6\u6001\u3001\u5bf9\u8c61\u5173\u7cfb\u662f\u5426\u660e\u786e\uff1f\n- [ ] V1/V2 \u8303\u56f4\u662f\u5426\u660e\u786e\uff1f\n- [ ] \u662f\u5426\u5b8c\u6210\u524d\u7aef\u6280\u672f\u8bc4\u5ba1\uff1f\n- [ ] \u662f\u5426\u5b8c\u6210\u6027\u80fd\u3001\u5b89\u5168\u3001\u6743\u9650\u3001\u5e76\u53d1\u3001\u65e5\u5fd7\u3001\u53ef\u56de\u6eda\u9884\u68c0\uff1f\n- [ ] \u662f\u5426\u660e\u786e\u9ad8\u4fdd\u771f\u6a21\u578b\u786e\u8ba4\u540e\u624d\u5141\u8bb8\u6b63\u5f0f\u5f00\u53d1\uff1f\n\n## \u98ce\u9669\u70b9\n\n- \u524d\u7aef\u4ecb\u5165\u592a\u665a\uff0c\u5bfc\u81f4\u9875\u9762\u3001\u63a5\u53e3\u3001\u6570\u636e\u5e93\u4e92\u76f8\u5012\u903c\u3002\n- \u9ad8\u4fdd\u771f\u6a21\u578b\u53ea\u753b\u9875\u9762\uff0c\u6ca1\u6709\u786e\u8ba4\u4e1a\u52a1\u5bf9\u8c61\u548c\u72b6\u6001\u3002\n- \u6ca1\u6709\u6309\u94ae\u884c\u4e3a\u77e9\u9635\uff0c\u5f00\u53d1\u548c\u6d4b\u8bd5\u65e0\u6cd5\u5bf9\u9f50\u3002\n- \u672a\u63d0\u524d\u8bc6\u522b\u6027\u80fd\u3001\u5b89\u5168\u3001\u6743\u9650\u3001\u5e76\u53d1\u3001\u65e5\u5fd7\u3001\u56de\u6eda\u98ce\u9669\u3002\n\n## Gate 2 \u901a\u8fc7\u6807\u51c6\n\n\u9ad8\u4fdd\u771f\u6a21\u578b\u901a\u8fc7\uff1a\u9875\u9762\u6536\u655b\u3001\u6309\u94ae\u884c\u4e3a\u3001\u4e1a\u52a1\u5bf9\u8c61\u3001\u72b6\u6001\u3001V1/V2 \u660e\u786e\u3002\n\n## \u5e38\u89c1\u95ee\u9898\n\n### \u4ec0\u4e48\u65f6\u5019\u9700\u8981\u524d\u7aef\u63d0\u524d\u53c2\u4e0e\uff1f\n\n\u9636\u6bb52\u5fc5\u987b\u7531\u524d\u7aef\u6df1\u5ea6\u53c2\u4e0e\u3002\u82e5\u9700\u6c42\u6d89\u53ca\u591a\u9875\u9762\u3001\u590d\u6742\u4ea4\u4e92\u3001\u6743\u9650\u3001\u72b6\u6001\u6d41\u8f6c\u3001\u6570\u636e\u7ed3\u6784\u6216\u7ec4\u4ef6\u590d\u7528\uff0c\u524d\u7aef\u5e94\u5728\u9700\u6c42\u6536\u655b\u65f6\u63d0\u524d\u53c2\u4e0e\u3002\n\n### \u7edf\u4e00\u4e1a\u52a1\u5bf9\u8c61\u6a21\u578b\u4e3a\u4ec0\u4e48\u91cd\u8981\uff1f\n\n\u7edf\u4e00\u4e1a\u52a1\u5bf9\u8c61\u6a21\u578b\u662f\u9875\u9762\u3001\u63a5\u53e3\u3001\u6570\u636e\u5e93\u3001\u6d4b\u8bd5\u3001AI \u63d0\u793a\u8bcd\u7684\u5171\u540c\u57fa\u7840\u3002\n\n## \u5173\u8054\u6761\u76ee\n\n- [[\u9636\u6bb51_\u4e1a\u52a1\u9700\u6c42\u5b8c\u6574\u5f62\u6210]]\n- [[\u9636\u6bb52.5_\u6d4b\u8bd5\u63d0\u524d\u8865\u6f0f]]\n- [[../01_\u4e1a\u52a1\u6d41\u7a0b/\u4e1a\u52a1\u5bf9\u8c61\u5b57\u5178]]\n- [[\u9636\u6bb5\u4ea4\u4ed8\u7269\u6e05\u5355]]\n", + "backlinks": [ + "article:02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/AI\u9a71\u52a8\u5185\u90e8\u7cfb\u7edf\u5f00\u53d1\u6d41\u7a0b_V3_\u603b\u89c8", + "article:02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/README", + "article:02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/\u5e38\u89c1\u95ee\u9898FAQ", + "article:02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/\u9636\u6bb51_\u4e1a\u52a1\u9700\u6c42\u5b8c\u6574\u5f62\u6210", + "article:02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/\u9636\u6bb52.5_\u6d4b\u8bd5\u63d0\u524d\u8865\u6f0f" + ] + } + }, + { + "id": "article:02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/\u9636\u6bb53_\u7814\u53d1\u534f\u4f5c\u4e0e\u6b63\u5f0f\u5f00\u53d1", + "type": "article", + "name": "\u9636\u6bb53 \u7814\u53d1\u534f\u4f5c\u4e0e\u6b63\u5f0f\u5f00\u53d1", + "filePath": "02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b\\\u9636\u6bb53_\u7814\u53d1\u534f\u4f5c\u4e0e\u6b63\u5f0f\u5f00\u53d1.md", + "summary": "\u57fa\u4e8e\u9ad8\u4fdd\u771f\u6a21\u578b\u8fdb\u884c\u6a21\u5757\u5316\u3001\u5b89\u5168\u3001\u53ef\u7ef4\u62a4\u5f00\u53d1\u3002\u7814\u53d1\u9636\u6bb5\u4ee5\u4ee3\u7801\u8d28\u91cf\u3001\u6a21\u5757\u5316\u3001\u5b89\u5168\u6027\u3001\u53ef\u7ef4\u62a4\u6027\u4e3a\u4e2d\u5fc3\u3002", + "tags": [ + "02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b", + "[\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b", + "\u4ee3\u7801\u6cbb\u7406", + "\u5b89\u5168]", + "\u6b63\u5f0f\u5f00\u53d1", + "\u7814\u53d1\u534f\u4f5c", + "\u9636\u6bb53" + ], + "complexity": "simple", + "knowledgeMeta": { + "wikilinks": [ + "\u9636\u6bb52.5_\u6d4b\u8bd5\u63d0\u524d\u8865\u6f0f", + "\u9636\u6bb54_\u6d4b\u8bd5\u57f9\u8bad\u4e0a\u7ebf\u56de\u6d41", + "\u9636\u6bb5\u4ea4\u4ed8\u7269\u6e05\u5355" + ], + "content": "---\ntype: process_stage\ntags: [\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b, \u9636\u6bb53, \u7814\u53d1\u534f\u4f5c, \u6b63\u5f0f\u5f00\u53d1, \u4ee3\u7801\u6cbb\u7406, \u5b89\u5168]\naliases: [\u7814\u53d1\u534f\u4f5c, \u6b63\u5f0f\u5f00\u53d1, Gate 3, \u5f00\u53d1\u8054\u8c03]\nsource: AI_\u9a71\u52a8_\u5185\u90e8\u7cfb\u7edf\u5f00\u53d1\u6d41\u7a0b_V3.docx\nstatus: active\nowner: \u524d\u7aef / \u540e\u7aef / \u7b97\u6cd5\nupdated: 2026-05\n---\n\n# \u9636\u6bb53 \u7814\u53d1\u534f\u4f5c\u4e0e\u6b63\u5f0f\u5f00\u53d1\n\n## \u6838\u5fc3\u76ee\u6807\n\n\u57fa\u4e8e\u9ad8\u4fdd\u771f\u6a21\u578b\u8fdb\u884c\u6a21\u5757\u5316\u3001\u5b89\u5168\u3001\u53ef\u7ef4\u62a4\u5f00\u53d1\u3002\u7814\u53d1\u9636\u6bb5\u4ee5\u4ee3\u7801\u8d28\u91cf\u3001\u6a21\u5757\u5316\u3001\u5b89\u5168\u6027\u3001\u53ef\u7ef4\u62a4\u6027\u4e3a\u4e2d\u5fc3\u3002\n\n## \u8d1f\u8d23\u4eba\n\n- \u524d\u7aef\n- \u540e\u7aef\n- \u7b97\u6cd5\n\n## \u8f93\u5165\n\n- \u9ad8\u4fdd\u771f\u6a21\u578b\u3002\n- \u7edf\u4e00\u4e1a\u52a1\u5bf9\u8c61\u6a21\u578b\u3002\n- \u6309\u94ae\u884c\u4e3a\u77e9\u9635\u3002\n- \u6d4b\u8bd5\u7528\u4f8b\u521d\u7a3f\u4e0e\u9700\u6c42\u8865\u6f0f\u7ed3\u679c\u3002\n- \u6280\u672f\u9884\u68c0\u8bb0\u5f55\u3002\n\n## \u5173\u952e\u52a8\u4f5c\n\n- \u62c6\u5206\u7814\u53d1\u4efb\u52a1\u4e0e\u534f\u4f5c\u8ba1\u5212\u3002\n- \u8fdb\u884c\u524d\u7aef\u3001\u540e\u7aef\u3001\u7b97\u6cd5\u6280\u672f\u5b9e\u73b0\u5bf9\u63a5\u3002\n- \u660e\u786e\u63a5\u53e3\u3001\u6570\u636e\u5e93\u3001\u6743\u9650\u3001\u5b89\u5168\u3001\u65e5\u5fd7\u548c\u56de\u6eda\u65b9\u6848\u3002\n- \u6309\u4ee3\u7801\u6cbb\u7406\u4e0e\u5b89\u5168\u89c4\u8303\u5f00\u53d1\u3002\n- \u8bb0\u5f55\u5f00\u53d1\u95ee\u9898\u4e0e\u8054\u8c03\u7ed3\u679c\u3002\n- \u6cbb\u7406 AI \u751f\u6210\u4ee3\u7801\uff0c\u4e0d\u80fd\u76f4\u63a5\u5806\u8fdb\u751f\u4ea7\u3002\n\n## \u8f93\u51fa/\u4ea4\u4ed8\u7269\n\n- `12_\u7814\u53d1\u4efb\u52a1\u62c6\u5206\u4e0e\u534f\u4f5c\u8ba1\u5212.md`\n- `13_\u6280\u672f\u5b9e\u73b0\u5bf9\u63a5.md`\n- `14_\u4ee3\u7801\u6cbb\u7406\u4e0e\u5b89\u5168\u89c4\u8303.md`\n- `15_\u5f00\u53d1\u95ee\u9898\u4e0e\u8054\u8c03\u8bb0\u5f55.md`\n\n## \u68c0\u67e5\u6e05\u5355\n\n- [ ] \u7814\u53d1\u4efb\u52a1\u662f\u5426\u5df2\u62c6\u5206\uff1f\n- [ ] \u524d\u540e\u7aef\u3001\u6570\u636e\u5e93\u3001\u6743\u9650\u3001\u5b89\u5168\u3001\u4e3b\u8981\u6d41\u7a0b\u662f\u5426\u8054\u8c03\u5b8c\u6210\uff1f\n- [ ] \u662f\u5426\u6309\u7edf\u4e00\u4e1a\u52a1\u5bf9\u8c61\u6a21\u578b\u8bbe\u8ba1\u63a5\u53e3\u548c\u6570\u636e\u5e93\uff1f\n- [ ] \u662f\u5426\u5904\u7406\u6743\u9650\u3001\u5b89\u5168\u3001\u65e5\u5fd7\u3001\u53ef\u56de\u6eda\uff1f\n- [ ] AI \u751f\u6210\u4ee3\u7801\u662f\u5426\u7ecf\u8fc7\u4eba\u5de5\u5ba1\u67e5\u548c\u6cbb\u7406\uff1f\n- [ ] \u662f\u5426\u907f\u514d\u91cd\u590d\u4ee3\u7801\u548c\u4e0d\u53ef\u7ef4\u62a4\u5806\u53e0\uff1f\n\n## \u98ce\u9669\u70b9\n\n- \u5f00\u53d1\u76f4\u63a5\u4ece Vibe Coding \u539f\u578b\u5f00\u59cb\uff0c\u8df3\u8fc7\u9ad8\u4fdd\u771f\u6a21\u578b\u3002\n- AI \u751f\u6210\u4ee3\u7801\u672a\u7ecf\u6cbb\u7406\u76f4\u63a5\u8fdb\u5165\u751f\u4ea7\u3002\n- \u7f3a\u5c11\u6a21\u5757\u8fb9\u754c\u3001\u6743\u9650\u3001\u5b89\u5168\u3001\u65e5\u5fd7\u548c\u56de\u6eda\u65b9\u6848\u3002\n- \u524d\u540e\u7aef\u3001\u6570\u636e\u5e93\u3001\u6d4b\u8bd5\u4f7f\u7528\u7684\u4e1a\u52a1\u5bf9\u8c61\u4e0d\u4e00\u81f4\u3002\n\n## Gate 3 \u901a\u8fc7\u6807\u51c6\n\n\u5f00\u53d1\u8054\u8c03\u901a\u8fc7\uff1a\u524d\u540e\u7aef\u3001\u6570\u636e\u5e93\u3001\u6743\u9650\u3001\u5b89\u5168\u3001\u4e3b\u8981\u6d41\u7a0b\u8054\u8c03\u5b8c\u6210\u3002\n\n## \u5e38\u89c1\u95ee\u9898\n\n### \u9636\u6bb53\u5982\u4f55\u4fdd\u8bc1\u6a21\u5757\u5316\u3001\u5b89\u5168\u548c\u53ef\u7ef4\u62a4\uff1f\n\n\u4f9d\u8d56\u7edf\u4e00\u4e1a\u52a1\u5bf9\u8c61\u6a21\u578b\u3001\u7814\u53d1\u4efb\u52a1\u62c6\u5206\u3001\u6280\u672f\u5b9e\u73b0\u5bf9\u63a5\u3001\u4ee3\u7801\u6cbb\u7406\u4e0e\u5b89\u5168\u89c4\u8303\u3001\u5f00\u53d1\u95ee\u9898\u4e0e\u8054\u8c03\u8bb0\u5f55\u3002AI \u4ee3\u7801\u5fc5\u987b\u7ecf\u8fc7\u6cbb\u7406\uff0c\u4e0d\u80fd\u76f4\u63a5\u5806\u8fdb\u751f\u4ea7\u3002\n\n## \u5173\u8054\u6761\u76ee\n\n- [[\u9636\u6bb52.5_\u6d4b\u8bd5\u63d0\u524d\u8865\u6f0f]]\n- [[\u9636\u6bb54_\u6d4b\u8bd5\u57f9\u8bad\u4e0a\u7ebf\u56de\u6d41]]\n- [[\u9636\u6bb5\u4ea4\u4ed8\u7269\u6e05\u5355]]\n", + "backlinks": [ + "article:02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/AI\u9a71\u52a8\u5185\u90e8\u7cfb\u7edf\u5f00\u53d1\u6d41\u7a0b_V3_\u603b\u89c8", + "article:02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/README", + "article:02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/\u5e38\u89c1\u95ee\u9898FAQ", + "article:02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/\u9636\u6bb52.5_\u6d4b\u8bd5\u63d0\u524d\u8865\u6f0f", + "article:02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/\u9636\u6bb54_\u6d4b\u8bd5\u57f9\u8bad\u4e0a\u7ebf\u56de\u6d41" + ] + } + }, + { + "id": "article:02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/\u9636\u6bb54_\u6d4b\u8bd5\u57f9\u8bad\u4e0a\u7ebf\u56de\u6d41", + "type": "article", + "name": "\u9636\u6bb54 \u6d4b\u8bd5\u57f9\u8bad\u4e0a\u7ebf\u56de\u6d41", + "filePath": "02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b\\\u9636\u6bb54_\u6d4b\u8bd5\u57f9\u8bad\u4e0a\u7ebf\u56de\u6d41.md", + "summary": "\u5b8c\u6210\u6d4b\u8bd5\u3001\u57f9\u8bad\u3001\u4e0a\u7ebf\u9a8c\u6536\u548c\u95ee\u9898\u56de\u6d41\u3002\u6d4b\u8bd5\u4fdd\u8bc1\u7cfb\u7edf\u771f\u5b9e\u53ef\u7528\uff0c\u5e76\u5e2e\u52a9\u4e1a\u52a1\u4eba\u5458\u6b63\u786e\u4f7f\u7528\u3002", + "tags": [ + "02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b", + "[\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b", + "\u4e0a\u7ebf", + "\u56de\u6d41]", + "\u57f9\u8bad", + "\u6d4b\u8bd5", + "\u9636\u6bb54" + ], + "complexity": "simple", + "knowledgeMeta": { + "wikilinks": [ + "\u9636\u6bb53_\u7814\u53d1\u534f\u4f5c\u4e0e\u6b63\u5f0f\u5f00\u53d1", + "\u9879\u76ee\u68c0\u67e5\u6e05\u5355", + "\u9636\u6bb5\u4ea4\u4ed8\u7269\u6e05\u5355" + ], + "content": "---\ntype: process_stage\ntags: [\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b, \u9636\u6bb54, \u6d4b\u8bd5, \u57f9\u8bad, \u4e0a\u7ebf, \u56de\u6d41]\naliases: [\u6d4b\u8bd5\u57f9\u8bad\u4e0a\u7ebf\u56de\u6d41, \u4e0a\u7ebf\u9a8c\u6536, Gate 4]\nsource: AI_\u9a71\u52a8_\u5185\u90e8\u7cfb\u7edf\u5f00\u53d1\u6d41\u7a0b_V3.docx\nstatus: active\nowner: \u6d4b\u8bd5 / \u4e1a\u52a1\u4e3b\u7ba1\nupdated: 2026-05\n---\n\n# \u9636\u6bb54 \u6d4b\u8bd5\u57f9\u8bad\u4e0a\u7ebf\u56de\u6d41\n\n## \u6838\u5fc3\u76ee\u6807\n\n\u5b8c\u6210\u6d4b\u8bd5\u3001\u57f9\u8bad\u3001\u4e0a\u7ebf\u9a8c\u6536\u548c\u95ee\u9898\u56de\u6d41\u3002\u6d4b\u8bd5\u4fdd\u8bc1\u7cfb\u7edf\u771f\u5b9e\u53ef\u7528\uff0c\u5e76\u5e2e\u52a9\u4e1a\u52a1\u4eba\u5458\u6b63\u786e\u4f7f\u7528\u3002\n\n## \u8d1f\u8d23\u4eba\n\n- \u6d4b\u8bd5\n- \u4e1a\u52a1\u4e3b\u7ba1\n\n## \u8f93\u5165\n\n- \u5f00\u53d1\u8054\u8c03\u5b8c\u6210\u7684\u7cfb\u7edf\u3002\n- \u6d4b\u8bd5\u7528\u4f8b\u3002\n- \u9ad8\u4fdd\u771f\u6a21\u578b\u548c\u4e1a\u52a1\u5bf9\u8c61\u6a21\u578b\u3002\n- \u5f00\u53d1\u95ee\u9898\u4e0e\u8054\u8c03\u8bb0\u5f55\u3002\n\n## \u5173\u952e\u52a8\u4f5c\n\n- \u8fdb\u884c\u6b63\u5f0f\u6d4b\u8bd5\u3002\n- \u9a8c\u8bc1\u4e3b\u6d41\u7a0b\u3001\u5206\u652f\u6d41\u7a0b\u3001\u6743\u9650\u3001\u5f02\u5e38\u548c\u6570\u636e\u3002\n- \u8f93\u51fa\u6b63\u5f0f\u6d4b\u8bd5\u62a5\u544a\u3002\n- \u5c06\u6d4b\u8bd5\u7528\u4f8b\u8f6c\u6210\u4e1a\u52a1\u64cd\u4f5c\u624b\u518c\u6216\u5185\u90e8\u57f9\u8bad\u6750\u6599\u3002\n- \u7ec4\u7ec7\u4e1a\u52a1\u786e\u8ba4\u548c\u4e0a\u7ebf\u9a8c\u6536\u3002\n- \u8bb0\u5f55\u4e0a\u7ebf\u95ee\u9898\u5e76\u56de\u6d41\u9700\u6c42\u6c60\u3002\n\n## \u8f93\u51fa/\u4ea4\u4ed8\u7269\n\n- `16_\u6b63\u5f0f\u6d4b\u8bd5\u62a5\u544a.md`\n- `17_\u5185\u90e8\u57f9\u8bad\u624b\u518c.md`\n- `18_\u4e0a\u7ebf\u9a8c\u6536\u8bb0\u5f55.md`\n- `19_\u4e0a\u7ebf\u95ee\u9898\u4e0e\u56de\u6d41\u9700\u6c42.md`\n\n## \u68c0\u67e5\u6e05\u5355\n\n- [ ] \u6b63\u5f0f\u6d4b\u8bd5\u662f\u5426\u901a\u8fc7\uff1f\n- [ ] \u4e3b\u6d41\u7a0b\u662f\u5426\u9a8c\u8bc1\u901a\u8fc7\uff1f\n- [ ] \u5206\u652f\u6d41\u7a0b\u662f\u5426\u9a8c\u8bc1\u901a\u8fc7\uff1f\n- [ ] \u6743\u9650\u662f\u5426\u9a8c\u8bc1\u901a\u8fc7\uff1f\n- [ ] \u5f02\u5e38\u548c\u6570\u636e\u8fb9\u754c\u662f\u5426\u9a8c\u8bc1\u901a\u8fc7\uff1f\n- [ ] \u5185\u90e8\u57f9\u8bad\u624b\u518c\u662f\u5426\u5b8c\u6210\uff1f\n- [ ] \u4e1a\u52a1\u4e3b\u7ba1\u662f\u5426\u5b8c\u6210\u4e0a\u7ebf\u786e\u8ba4\uff1f\n- [ ] \u4e0a\u7ebf\u95ee\u9898\u662f\u5426\u8bb0\u5f55\u5e76\u56de\u6d41\uff1f\n\n## \u98ce\u9669\u70b9\n\n- \u53ea\u6d4b\u529f\u80fd\uff0c\u4e0d\u6d4b\u6743\u9650\u3001\u5f02\u5e38\u3001\u6570\u636e\u548c\u5b9e\u9645\u64cd\u4f5c\u8def\u5f84\u3002\n- \u6ca1\u6709\u57f9\u8bad\u6750\u6599\uff0c\u4e1a\u52a1\u4eba\u5458\u4e0d\u4f1a\u7528\u3002\n- \u4e0a\u7ebf\u95ee\u9898\u6ca1\u6709\u8fdb\u5165\u56de\u6d41\u9700\u6c42\u6c60\u3002\n- \u4e1a\u52a1\u4e3b\u7ba1\u672a\u9a8c\u6536\u5c31\u4e0a\u7ebf\u3002\n\n## Gate 4 \u901a\u8fc7\u6807\u51c6\n\n\u4e0a\u7ebf\u9a8c\u6536\u901a\u8fc7\uff1a\u6d4b\u8bd5\u901a\u8fc7\u3001\u4e1a\u52a1\u786e\u8ba4\u3001\u57f9\u8bad\u5b8c\u6210\u3002\n\n## \u5e38\u89c1\u95ee\u9898\n\n### \u4e0a\u7ebf\u524d\u9700\u8981\u68c0\u67e5\u54ea\u4e9b\u4e8b\u9879\uff1f\n\n\u81f3\u5c11\u68c0\u67e5\u6b63\u5f0f\u6d4b\u8bd5\u3001\u4e3b\u6d41\u7a0b\u3001\u5206\u652f\u6d41\u7a0b\u3001\u6743\u9650\u3001\u5f02\u5e38\u3001\u6570\u636e\u8fb9\u754c\u3001\u5185\u90e8\u57f9\u8bad\u624b\u518c\u3001\u4e1a\u52a1\u786e\u8ba4\u3001\u4e0a\u7ebf\u95ee\u9898\u56de\u6d41\u673a\u5236\u3002\n\n## \u5173\u8054\u6761\u76ee\n\n- [[\u9636\u6bb53_\u7814\u53d1\u534f\u4f5c\u4e0e\u6b63\u5f0f\u5f00\u53d1]]\n- [[\u9879\u76ee\u68c0\u67e5\u6e05\u5355]]\n- [[\u9636\u6bb5\u4ea4\u4ed8\u7269\u6e05\u5355]]\n", + "backlinks": [ + "article:02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/AI\u9a71\u52a8\u5185\u90e8\u7cfb\u7edf\u5f00\u53d1\u6d41\u7a0b_V3_\u603b\u89c8", + "article:02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/README", + "article:02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/\u5e38\u89c1\u95ee\u9898FAQ", + "article:02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/\u89d2\u8272\u804c\u8d23\u77e9\u9635", + "article:02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/\u9636\u6bb53_\u7814\u53d1\u534f\u4f5c\u4e0e\u6b63\u5f0f\u5f00\u53d1" + ] + } + }, + { + "id": "article:02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/\u9636\u6bb5\u4ea4\u4ed8\u7269\u6e05\u5355", + "type": "article", + "name": "\u9636\u6bb5\u4ea4\u4ed8\u7269\u6e05\u5355", + "filePath": "02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b\\\u9636\u6bb5\u4ea4\u4ed8\u7269\u6e05\u5355.md", + "summary": "| \u9636\u6bb5 | \u4ea4\u4ed8\u7269 | |---|---| | \u9636\u6bb50 | `00_\u9879\u76ee\u5165\u53e3\u5206\u7ea7.md` | | \u9636\u6bb51 | `01_\u4e3b\u6d41\u7a0b\u8bf4\u660e.md`\u3001`02_\u65e5\u5e38\u64cd\u4f5c\u9875\u9762\u7ed3\u6784.md`\u3001`03_\u529f\u80fd\u9875\u9762\u6309\u94ae\u76d8\u70b9\u8868.md`\u3001`04_\u5206\u652f\u6d41\u7a0b_XXX.md`\u3001`05_\u5f02\u5e38\u6d41\u7a0b_XXX.md`\u3001`06_VibeCoding\u9875\u9762\u9a8c\u8bc1\u8bb0\u5f55.md` | | \u9636\u6bb52 | `07_\u9ad8\u4fdd\u771f\u6a21\u578b.html`\u3001`07_\u9ad8\u4fdd\u771f...", + "tags": [ + "02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b", + "[\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b", + "\u4ea4\u4ed8\u7269", + "\u6587\u4ef6\u6e05\u5355]" + ], + "complexity": "simple", + "knowledgeMeta": { + "wikilinks": [ + "AI\u9a71\u52a8\u5185\u90e8\u7cfb\u7edf\u5f00\u53d1\u6d41\u7a0b_V3_\u603b\u89c8", + "\u9879\u76ee\u68c0\u67e5\u6e05\u5355" + ], + "content": "---\ntype: deliverable_index\ntags: [\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b, \u4ea4\u4ed8\u7269, \u6587\u4ef6\u6e05\u5355]\naliases: [\u4ea4\u4ed8\u7269\u6e05\u5355, \u6587\u4ef6\u7ed3\u6784, \u4ea7\u51fa\u7269]\nsource: AI_\u9a71\u52a8_\u5185\u90e8\u7cfb\u7edf\u5f00\u53d1\u6d41\u7a0b_V3.docx\nstatus: active\nowner: \u5185\u90e8\u6280\u672f\u56e2\u961f\nupdated: 2026-05\n---\n\n# \u9636\u6bb5\u4ea4\u4ed8\u7269\u6e05\u5355\n\n## \u5b8c\u6574\u7248\u4ea4\u4ed8\u7269\n\n| \u9636\u6bb5 | \u4ea4\u4ed8\u7269 |\n|---|---|\n| \u9636\u6bb50 | `00_\u9879\u76ee\u5165\u53e3\u5206\u7ea7.md` |\n| \u9636\u6bb51 | `01_\u4e3b\u6d41\u7a0b\u8bf4\u660e.md`\u3001`02_\u65e5\u5e38\u64cd\u4f5c\u9875\u9762\u7ed3\u6784.md`\u3001`03_\u529f\u80fd\u9875\u9762\u6309\u94ae\u76d8\u70b9\u8868.md`\u3001`04_\u5206\u652f\u6d41\u7a0b_XXX.md`\u3001`05_\u5f02\u5e38\u6d41\u7a0b_XXX.md`\u3001`06_VibeCoding\u9875\u9762\u9a8c\u8bc1\u8bb0\u5f55.md` |\n| \u9636\u6bb52 | `07_\u9ad8\u4fdd\u771f\u6a21\u578b.html`\u3001`07_\u9ad8\u4fdd\u771f\u6a21\u578b\u8bf4\u660e.md`\u3001`08_\u9879\u76ee\u5468\u671f\u4e0e\u7248\u672c\u786e\u8ba4.md`\u3001`09_\u524d\u7aef\u6280\u672f\u8bc4\u5ba1.md`\u3001`10_\u6280\u672f\u9884\u68c0\u8bb0\u5f55.md`\u3001`10A_\u7edf\u4e00\u4e1a\u52a1\u5bf9\u8c61\u6a21\u578b.md`\u3001`10B_\u6309\u94ae\u884c\u4e3a\u77e9\u9635.md` |\n| \u9636\u6bb52.5 | `11_\u6d4b\u8bd5\u7528\u4f8b\u521d\u7a3f\u4e0e\u9700\u6c42\u8865\u6f0f.md` |\n| \u9636\u6bb53 | `12_\u7814\u53d1\u4efb\u52a1\u62c6\u5206\u4e0e\u534f\u4f5c\u8ba1\u5212.md`\u3001`13_\u6280\u672f\u5b9e\u73b0\u5bf9\u63a5.md`\u3001`14_\u4ee3\u7801\u6cbb\u7406\u4e0e\u5b89\u5168\u89c4\u8303.md`\u3001`15_\u5f00\u53d1\u95ee\u9898\u4e0e\u8054\u8c03\u8bb0\u5f55.md` |\n| \u9636\u6bb54 | `16_\u6b63\u5f0f\u6d4b\u8bd5\u62a5\u544a.md`\u3001`17_\u5185\u90e8\u57f9\u8bad\u624b\u518c.md`\u3001`18_\u4e0a\u7ebf\u9a8c\u6536\u8bb0\u5f55.md`\u3001`19_\u4e0a\u7ebf\u95ee\u9898\u4e0e\u56de\u6d41\u9700\u6c42.md` |\n| \u9636\u6bb55 | `20_\u6280\u672f\u503a\u6e05\u5355.md`\u3001`21_\u4e1a\u52a1\u539f\u5b50\u80fd\u529b\u6c89\u6dc0\u6e05\u5355.md`\u3001`22_\u7ec4\u4ef6\u5e93\u4e0e\u670d\u52a1\u590d\u7528\u6e05\u5355.md`\u3001`23_AI\u5f00\u53d1\u4e0a\u4e0b\u6587\u6a21\u677f\u66f4\u65b0\u8bb0\u5f55.md` |\n\n## \u8f7b\u91cf\u7248\u4ea4\u4ed8\u7269\n\n| \u9636\u6bb5\u5305 | \u4ea4\u4ed8\u7269 |\n|---|---|\n| \u5165\u53e3 | `00_\u9879\u76ee\u5165\u53e3\u5206\u7ea7.md` |\n| \u9700\u6c42 | `01_\u4e1a\u52a1\u9700\u6c42\u5305.md` |\n| \u6a21\u578b | `02_\u9ad8\u4fdd\u771f\u6a21\u578b\u5305.md` |\n| \u9884\u68c0 | `03_\u9879\u76ee\u7248\u672c\u4e0e\u6280\u672f\u9884\u68c0.md` |\n| \u6d4b\u8bd5\u8865\u6f0f | `04_\u6d4b\u8bd5\u7528\u4f8b\u521d\u7a3f\u4e0e\u9700\u6c42\u8865\u6f0f.md` |\n| \u7814\u53d1 | `05_\u7814\u53d1\u534f\u4f5c\u4e0e\u6280\u672f\u5b9e\u73b0\u5305.md` |\n| \u6cbb\u7406 | `06_\u4ee3\u7801\u6cbb\u7406\u4e0e\u5b89\u5168\u89c4\u8303.md` |\n| \u4e0a\u7ebf | `07_\u6d4b\u8bd5\u57f9\u8bad\u4e0a\u7ebf\u5305.md` |\n| \u6c89\u6dc0 | `08_\u6280\u672f\u503a\u4e0e\u80fd\u529b\u6c89\u6dc0\u5305.md` |\n\n## \u5173\u8054\u6761\u76ee\n\n- [[AI\u9a71\u52a8\u5185\u90e8\u7cfb\u7edf\u5f00\u53d1\u6d41\u7a0b_V3_\u603b\u89c8]]\n- [[\u9879\u76ee\u68c0\u67e5\u6e05\u5355]]\n", + "backlinks": [ + "article:02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/AI\u9a71\u52a8\u5185\u90e8\u7cfb\u7edf\u5f00\u53d1\u6d41\u7a0b_V3_\u603b\u89c8", + "article:02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/README", + "article:02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/\u5e38\u89c1\u95ee\u9898FAQ", + "article:02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/\u9636\u6bb50_\u9879\u76ee\u5165\u53e3\u5206\u7ea7", + "article:02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/\u9636\u6bb51_\u4e1a\u52a1\u9700\u6c42\u5b8c\u6574\u5f62\u6210", + "article:02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/\u9636\u6bb52_\u9ad8\u4fdd\u771f\u6a21\u578b\u4e0e\u4e1a\u52a1\u5bf9\u8c61\u786e\u8ba4", + "article:02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/\u9636\u6bb53_\u7814\u53d1\u534f\u4f5c\u4e0e\u6b63\u5f0f\u5f00\u53d1", + "article:02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/\u9636\u6bb54_\u6d4b\u8bd5\u57f9\u8bad\u4e0a\u7ebf\u56de\u6d41", + "article:02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/\u9879\u76ee\u68c0\u67e5\u6e05\u5355" + ] + } + }, + { + "id": "article:02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/\u9879\u76ee\u68c0\u67e5\u6e05\u5355", + "type": "article", + "name": "\u9879\u76ee\u68c0\u67e5\u6e05\u5355", + "filePath": "02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b\\\u9879\u76ee\u68c0\u67e5\u6e05\u5355.md", + "summary": "- [ ] \u786e\u8ba4\u9879\u76ee\u503c\u5f97\u505a\u3002 - [ ] \u786e\u8ba4\u9879\u76ee\u7c7b\u578b\uff1aS / M / L\u3002 - [ ] \u786e\u8ba4\u8d70\u8f7b\u6d41\u7a0b\u8fd8\u662f\u5b8c\u6574\u6d41\u7a0b\u3002 - [ ] \u786e\u8ba4\u4e1a\u52a1\u4e3b\u7ba1\u548c\u6280\u672f\u8d1f\u8d23\u4eba\u3002", + "tags": [ + "02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b", + "[\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b", + "\u68c0\u67e5\u6e05\u5355", + "\u95e8\u7981]" + ], + "complexity": "simple", + "knowledgeMeta": { + "wikilinks": [ + "AI\u9a71\u52a8\u5185\u90e8\u7cfb\u7edf\u5f00\u53d1\u6d41\u7a0b_V3_\u603b\u89c8", + "\u9636\u6bb5\u4ea4\u4ed8\u7269\u6e05\u5355" + ], + "content": "---\ntype: checklist\ntags: [\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b, \u68c0\u67e5\u6e05\u5355, \u95e8\u7981]\naliases: [\u9879\u76ee\u95e8\u7981\u68c0\u67e5, \u4e0a\u7ebf\u68c0\u67e5, \u6d41\u7a0b\u68c0\u67e5]\nsource: AI_\u9a71\u52a8_\u5185\u90e8\u7cfb\u7edf\u5f00\u53d1\u6d41\u7a0b_V3.docx\nstatus: active\nowner: \u5185\u90e8\u6280\u672f\u56e2\u961f\nupdated: 2026-05\n---\n\n# \u9879\u76ee\u68c0\u67e5\u6e05\u5355\n\n## Gate 0 \u9879\u76ee\u5165\u53e3\n\n- [ ] \u786e\u8ba4\u9879\u76ee\u503c\u5f97\u505a\u3002\n- [ ] \u786e\u8ba4\u9879\u76ee\u7c7b\u578b\uff1aS / M / L\u3002\n- [ ] \u786e\u8ba4\u8d70\u8f7b\u6d41\u7a0b\u8fd8\u662f\u5b8c\u6574\u6d41\u7a0b\u3002\n- [ ] \u786e\u8ba4\u4e1a\u52a1\u4e3b\u7ba1\u548c\u6280\u672f\u8d1f\u8d23\u4eba\u3002\n\n## Gate 1 \u9700\u6c42\u5b8c\u6574\n\n- [ ] \u4e3b\u6d41\u7a0b\u5b8c\u6574\u3002\n- [ ] \u5206\u652f\u6d41\u7a0b\u5b8c\u6574\u3002\n- [ ] \u9875\u9762\u3001\u6309\u94ae\u3001\u5b57\u6bb5\u5927\u81f4\u5b8c\u6574\u3002\n- [ ] \u72b6\u6001\u5927\u81f4\u5b8c\u6574\u3002\n- [ ] Vibe Coding \u9875\u9762\u5df2\u9a8c\u8bc1\u3002\n\n## Gate 2 \u9ad8\u4fdd\u771f\u6a21\u578b\n\n- [ ] \u9875\u9762\u5df2\u7ecf\u6536\u655b\u3002\n- [ ] \u6309\u94ae\u884c\u4e3a\u660e\u786e\u3002\n- [ ] \u4e1a\u52a1\u5bf9\u8c61\u660e\u786e\u3002\n- [ ] \u72b6\u6001\u660e\u786e\u3002\n- [ ] V1/V2 \u660e\u786e\u3002\n- [ ] \u6027\u80fd\u3001\u5b89\u5168\u3001\u6743\u9650\u3001\u5e76\u53d1\u3001\u65e5\u5fd7\u3001\u53ef\u56de\u6eda\u5df2\u9884\u68c0\u3002\n\n## Gate 2.5 \u6d4b\u8bd5\u8865\u6f0f\n\n- [ ] \u6d4b\u8bd5\u7528\u4f8b\u521d\u7a3f\u5df2\u5b8c\u6210\u3002\n- [ ] \u4e3b\u6d41\u7a0b\u3001\u5206\u652f\u3001\u6743\u9650\u3001\u5f02\u5e38\u3001\u6570\u636e\u3001\u6309\u94ae\u884c\u4e3a\u5df2\u68c0\u67e5\u3002\n- [ ] \u963b\u585e\u5f00\u53d1\u7684\u95ee\u9898\u5df2\u5904\u7406\u3002\n\n## Gate 3 \u5f00\u53d1\u8054\u8c03\n\n- [ ] \u524d\u540e\u7aef\u8054\u8c03\u5b8c\u6210\u3002\n- [ ] \u6570\u636e\u5e93\u8054\u8c03\u5b8c\u6210\u3002\n- [ ] \u6743\u9650\u548c\u5b89\u5168\u8054\u8c03\u5b8c\u6210\u3002\n- [ ] \u4e3b\u8981\u6d41\u7a0b\u8054\u8c03\u5b8c\u6210\u3002\n- [ ] AI \u4ee3\u7801\u5df2\u6cbb\u7406\u3002\n\n## Gate 4 \u4e0a\u7ebf\u9a8c\u6536\n\n- [ ] \u6b63\u5f0f\u6d4b\u8bd5\u901a\u8fc7\u3002\n- [ ] \u4e1a\u52a1\u786e\u8ba4\u5b8c\u6210\u3002\n- [ ] \u57f9\u8bad\u5b8c\u6210\u3002\n- [ ] \u4e0a\u7ebf\u95ee\u9898\u56de\u6d41\u673a\u5236\u660e\u786e\u3002\n\n## Gate 5 \u6280\u672f\u503a\u6cbb\u7406\n\n- [ ] \u6280\u672f\u503a\u5df2\u5206\u7c7b\u3002\n- [ ] \u5fc5\u987b\u7acb\u5373\u5904\u7406\u7684\u5df2\u5904\u7406\u3002\n- [ ] \u53ef\u5ef6\u540e\u7684\u8fdb\u5165\u6280\u672f\u503a\u6c60\u3002\n- [ ] \u53ef\u590d\u7528\u7ec4\u4ef6\u5df2\u6c89\u6dc0\u3002\n- [ ] \u53ef\u590d\u7528\u540e\u7aef\u670d\u52a1\u5df2\u6c89\u6dc0\u3002\n- [ ] AI \u5f00\u53d1\u4e0a\u4e0b\u6587\u6a21\u677f\u5df2\u66f4\u65b0\u3002\n\n## \u5173\u8054\u6761\u76ee\n\n- [[AI\u9a71\u52a8\u5185\u90e8\u7cfb\u7edf\u5f00\u53d1\u6d41\u7a0b_V3_\u603b\u89c8]]\n- [[\u9636\u6bb5\u4ea4\u4ed8\u7269\u6e05\u5355]]\n", + "backlinks": [ + "article:02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/AI\u9a71\u52a8\u5185\u90e8\u7cfb\u7edf\u5f00\u53d1\u6d41\u7a0b_V3_\u603b\u89c8", + "article:02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/README", + "article:02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/\u5e38\u89c1\u95ee\u9898FAQ", + "article:02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/\u9636\u6bb52.5_\u6d4b\u8bd5\u63d0\u524d\u8865\u6f0f", + "article:02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/\u9636\u6bb54_\u6d4b\u8bd5\u57f9\u8bad\u4e0a\u7ebf\u56de\u6d41", + "article:02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/\u9636\u6bb5\u4ea4\u4ed8\u7269\u6e05\u5355" + ] + } + }, + { + "id": "article:03_\u89c4\u8303\u4e0e\u6a21\u677f/\u4e0a\u7ebf\u68c0\u67e5\u6a21\u677f", + "type": "article", + "name": "\u4e0a\u7ebf\u68c0\u67e5\u6a21\u677f", + "filePath": "03_\u89c4\u8303\u4e0e\u6a21\u677f\\\u4e0a\u7ebf\u68c0\u67e5\u6a21\u677f.md", + "summary": "- \u9879\u76ee\u540d\u79f0\uff1a - \u4e0a\u7ebf\u7248\u672c\uff1a - \u4e0a\u7ebf\u65f6\u95f4\uff1a - \u8d1f\u8d23\u4eba\uff1a", + "tags": [ + "03_\u89c4\u8303\u4e0e\u6a21\u677f", + "[\u6a21\u677f", + "\u4e0a\u7ebf\u68c0\u67e5]" + ], + "complexity": "simple", + "knowledgeMeta": { + "wikilinks": [], + "content": "---\ntype: template\ntags: [\u6a21\u677f, \u4e0a\u7ebf\u68c0\u67e5]\naliases: [\u4e0a\u7ebf\u6a21\u677f, \u9a8c\u6536\u6a21\u677f]\nsource: manual\nstatus: active\nowner: \u6d4b\u8bd5 / \u4e1a\u52a1\u4e3b\u7ba1\nupdated: 2026-05\n---\n\n# \u4e0a\u7ebf\u68c0\u67e5\u6a21\u677f\n\n## \u57fa\u672c\u4fe1\u606f\n\n- \u9879\u76ee\u540d\u79f0\uff1a\n- \u4e0a\u7ebf\u7248\u672c\uff1a\n- \u4e0a\u7ebf\u65f6\u95f4\uff1a\n- \u8d1f\u8d23\u4eba\uff1a\n\n## \u4e0a\u7ebf\u524d\u68c0\u67e5\n\n- [ ] \u6b63\u5f0f\u6d4b\u8bd5\u901a\u8fc7\u3002\n- [ ] \u4e3b\u6d41\u7a0b\u901a\u8fc7\u3002\n- [ ] \u5206\u652f\u6d41\u7a0b\u901a\u8fc7\u3002\n- [ ] \u6743\u9650\u901a\u8fc7\u3002\n- [ ] \u5f02\u5e38\u548c\u6570\u636e\u8fb9\u754c\u901a\u8fc7\u3002\n- [ ] \u57f9\u8bad\u6750\u6599\u5b8c\u6210\u3002\n- [ ] \u4e1a\u52a1\u4e3b\u7ba1\u786e\u8ba4\u3002\n- [ ] \u56de\u6eda\u65b9\u6848\u660e\u786e\u3002\n\n## \u4e0a\u7ebf\u9a8c\u6536\n\n| \u9a8c\u6536\u9879 | \u9a8c\u6536\u4eba | \u7ed3\u679c | \u5907\u6ce8 |\n|---|---|---|---|\n| | | | |\n\n## \u4e0a\u7ebf\u95ee\u9898\u56de\u6d41\n\n| \u95ee\u9898 | \u5f71\u54cd | \u5904\u7406\u4f18\u5148\u7ea7 | \u8d1f\u8d23\u4eba | \u72b6\u6001 |\n|---|---|---|---|---|\n| | | | | |\n", + "backlinks": [ + "article:08_\u6d4b\u8bd5\u76f8\u5173/README" + ] + } + }, + { + "id": "article:03_\u89c4\u8303\u4e0e\u6a21\u677f/\u4e1a\u52a1\u6d41\u7a0b\u68b3\u7406\u6a21\u677f", + "type": "article", + "name": "\u4e1a\u52a1\u6d41\u7a0b\u68b3\u7406\u6a21\u677f", + "filePath": "03_\u89c4\u8303\u4e0e\u6a21\u677f\\\u4e1a\u52a1\u6d41\u7a0b\u68b3\u7406\u6a21\u677f.md", + "summary": "\u89c1 [[../01_\u4e1a\u52a1\u6d41\u7a0b/\u4e1a\u52a1\u6d41\u7a0b\u6a21\u677f]]\u3002", + "tags": [ + "03_\u89c4\u8303\u4e0e\u6a21\u677f", + "[\u6a21\u677f", + "\u4e1a\u52a1\u6d41\u7a0b]" + ], + "complexity": "simple", + "knowledgeMeta": { + "wikilinks": [ + "../01_\u4e1a\u52a1\u6d41\u7a0b/\u4e1a\u52a1\u6d41\u7a0b\u6a21\u677f" + ], + "content": "---\ntype: template\ntags: [\u6a21\u677f, \u4e1a\u52a1\u6d41\u7a0b]\naliases: [\u6d41\u7a0b\u68b3\u7406\u6a21\u677f]\nsource: manual\nstatus: active\nowner: \u4e1a\u52a1\u4e3b\u7ba1\nupdated: 2026-05\n---\n\n# \u4e1a\u52a1\u6d41\u7a0b\u68b3\u7406\u6a21\u677f\n\n\u89c1 [[../01_\u4e1a\u52a1\u6d41\u7a0b/\u4e1a\u52a1\u6d41\u7a0b\u6a21\u677f]]\u3002\n\n\u4f7f\u7528\u65f6\u590d\u5236\u8be5\u6a21\u677f\uff0c\u5e76\u6309\u771f\u5b9e\u4e1a\u52a1\u6d41\u7a0b\u547d\u540d\u4fdd\u5b58\u5230 `01_\u4e1a\u52a1\u6d41\u7a0b/` \u4e0b\u3002\n", + "backlinks": [] + } + }, + { + "id": "article:03_\u89c4\u8303\u4e0e\u6a21\u677f/\u4e1a\u52a1\u89c4\u5219\u4e0e\u9700\u6c42\u8865\u5145\u6a21\u677f", + "type": "article", + "name": "\u4e1a\u52a1\u89c4\u5219\u4e0e\u9700\u6c42\u8865\u5145\u6a21\u677f", + "filePath": "03_\u89c4\u8303\u4e0e\u6a21\u677f\\\u4e1a\u52a1\u89c4\u5219\u4e0e\u9700\u6c42\u8865\u5145\u6a21\u677f.md", + "summary": "| \u5b57\u6bb5 | \u5185\u5bb9 | |---|---| | \u4e1a\u52a1\u57df | | | \u89c4\u5219/\u9700\u6c42\u540d\u79f0 | | | \u63d0\u51fa\u4eba | | | \u8d1f\u8d23\u90e8\u95e8 | | | \u9002\u7528\u89d2\u8272 | | | \u5173\u8054\u7cfb\u7edf | | | \u7248\u672c | v1.0 | | \u751f\u6548\u72b6\u6001 | draft / active / deprecated | | \u751f\u6548\u65f6\u95f4 | | | \u6700\u8fd1\u66f4\u65b0\u65f6\u95f4 | |", + "tags": [ + "03_\u89c4\u8303\u4e0e\u6a21\u677f", + "Agent\u68c0\u7d22]", + "[\u6a21\u677f", + "\u4e1a\u52a1\u89c4\u5219", + "\u9700\u6c42\u8865\u5145" + ], + "complexity": "simple", + "knowledgeMeta": { + "wikilinks": [], + "content": "---\ntype: template\ntags: [\u6a21\u677f, \u4e1a\u52a1\u89c4\u5219, \u9700\u6c42\u8865\u5145, Agent\u68c0\u7d22]\naliases: [\u4e1a\u52a1\u8865\u5145\u6a21\u677f, \u89c4\u5219\u8865\u5145\u6a21\u677f, \u9700\u6c42\u589e\u91cf\u6a21\u677f]\nsource: manual\nstatus: active\nowner: \u4e1a\u52a1\u4e3b\u7ba1 / \u4ea7\u54c1\u7ecf\u7406\nupdated: 2026-05\n---\n\n# \u4e1a\u52a1\u89c4\u5219\u4e0e\u9700\u6c42\u8865\u5145\u6a21\u677f\n\n> \u4f7f\u7528\u65b9\u5f0f\uff1a\u6bcf\u6b21\u65b0\u589e\u6216\u4fee\u8ba2\u4e1a\u52a1\u89c4\u5219\u65f6\uff0c\u590d\u5236\u672c\u6a21\u677f\u5230 `01_\u4e1a\u52a1\u6d41\u7a0b/` \u4e0b\uff0c\u5e76\u6309 `\u4e1a\u52a1\u57df_\u89c4\u5219\u6216\u9700\u6c42\u540d\u79f0_YYYYMMDD.md` \u547d\u540d\u3002\n\n## 1. \u57fa\u672c\u4fe1\u606f\n\n| \u5b57\u6bb5 | \u5185\u5bb9 |\n|---|---|\n| \u4e1a\u52a1\u57df | |\n| \u89c4\u5219/\u9700\u6c42\u540d\u79f0 | |\n| \u63d0\u51fa\u4eba | |\n| \u8d1f\u8d23\u90e8\u95e8 | |\n| \u9002\u7528\u89d2\u8272 | |\n| \u5173\u8054\u7cfb\u7edf | |\n| \u7248\u672c | v1.0 |\n| \u751f\u6548\u72b6\u6001 | draft / active / deprecated |\n| \u751f\u6548\u65f6\u95f4 | |\n| \u6700\u8fd1\u66f4\u65b0\u65f6\u95f4 | |\n\n## 2. \u80cc\u666f\u4e0e\u76ee\u6807\n\n- \u5f53\u524d\u95ee\u9898\uff1a\n- \u4e1a\u52a1\u76ee\u6807\uff1a\n- \u4e0d\u89e3\u51b3\u7684\u95ee\u9898\uff1a\n\n## 3. \u9002\u7528\u8303\u56f4\n\n- \u9002\u7528\u573a\u666f\uff1a\n- \u4e0d\u9002\u7528\u573a\u666f\uff1a\n- \u524d\u7f6e\u6761\u4ef6\uff1a\n\n## 4. \u4e1a\u52a1\u89c4\u5219\n\n| \u7f16\u53f7 | \u89c4\u5219\u63cf\u8ff0 | \u89e6\u53d1\u6761\u4ef6 | \u5904\u7406\u7ed3\u679c | \u4f18\u5148\u7ea7 | \u4f8b\u5916\u60c5\u51b5 |\n|---|---|---|---|---|---|\n| BR-001 | | | | \u9ad8/\u4e2d/\u4f4e | |\n\n## 5. \u4e1a\u52a1\u6d41\u7a0b\n\n### 5.1 \u4e3b\u6d41\u7a0b\n\n1. \n2. \n3. \n\n### 5.2 \u5206\u652f\u6d41\u7a0b\n\n| \u5206\u652f\u573a\u666f | \u5224\u65ad\u6761\u4ef6 | \u5904\u7406\u65b9\u5f0f | \u8f93\u51fa\u7ed3\u679c |\n|---|---|---|---|\n| | | | |\n\n### 5.3 \u5f02\u5e38\u5904\u7406\n\n| \u5f02\u5e38\u573a\u666f | \u8bc6\u522b\u65b9\u5f0f | \u5904\u7406\u65b9\u5f0f | \u8d1f\u8d23\u4eba |\n|---|---|---|---|\n| | | | |\n\n## 6. \u6570\u636e\u4e0e\u4e1a\u52a1\u5bf9\u8c61\n\n| \u4e1a\u52a1\u5bf9\u8c61 | \u5b57\u6bb5 | \u5b57\u6bb5\u542b\u4e49 | \u5fc5\u586b | \u6765\u6e90 | \u53bb\u5411 |\n|---|---|---|---|---|---|\n| | | | \u662f/\u5426 | | |\n\n## 7. \u6743\u9650\u4e0e\u64cd\u4f5c\n\n| \u89d2\u8272 | \u53ef\u89c1\u8303\u56f4 | \u53ef\u6267\u884c\u64cd\u4f5c | \u7981\u6b62\u64cd\u4f5c |\n|---|---|---|---|\n| | | | |\n\n## 8. \u9a8c\u6536\u53e3\u5f84\n\n| \u9a8c\u6536\u70b9 | \u901a\u8fc7\u6807\u51c6 | \u6d4b\u8bd5\u95ee\u9898 |\n|---|---|---|\n| | | |\n\n## 9. Agent \u68c0\u7d22\u5b57\u6bb5\n\n### 9.1 \u63a8\u8350\u5173\u952e\u8bcd\n\n- \n\n### 9.2 \u540c\u4e49\u8bcd/\u53e3\u8bed\u95ee\u6cd5\n\n| \u7528\u6237\u53ef\u80fd\u95ee\u6cd5 | \u6807\u51c6\u672f\u8bed | \u63a8\u8350\u547d\u4e2d\u6587\u4ef6 |\n|---|---|---|\n| | | |\n\n### 9.3 \u6807\u51c6\u95ee\u7b54\n\n| \u95ee\u9898 | \u671f\u671b\u7b54\u6848\u8981\u70b9 | \u6765\u6e90\u7ae0\u8282 |\n|---|---|---|\n| | | |\n\n## 10. \u5173\u8054\u6761\u76ee\n\n- \u5173\u8054\u4e1a\u52a1\u6d41\u7a0b\uff1a\n- \u5173\u8054\u9879\u76ee\u7ba1\u7406\u9636\u6bb5\uff1a\n- \u5173\u8054\u9700\u6c42\u8bf4\u660e\uff1a\n- \u5173\u8054\u6d4b\u8bd5\u7528\u4f8b\uff1a\n\n## 11. \u53d8\u66f4\u8bb0\u5f55\n\n| \u65e5\u671f | \u7248\u672c | \u53d8\u66f4\u5185\u5bb9 | \u53d8\u66f4\u4eba |\n|---|---|---|---|\n| | v1.0 | \u65b0\u589e | |\n", + "backlinks": [] + } + }, + { + "id": "article:03_\u89c4\u8303\u4e0e\u6a21\u677f/\u4f1a\u8bae\u7eaa\u8981\u6a21\u677f", + "type": "article", + "name": "\u4f1a\u8bae\u7eaa\u8981\u6a21\u677f", + "filePath": "03_\u89c4\u8303\u4e0e\u6a21\u677f\\\u4f1a\u8bae\u7eaa\u8981\u6a21\u677f.md", + "summary": "- \u4f1a\u8bae\u4e3b\u9898\uff1a - \u65f6\u95f4\uff1a - \u53c2\u4f1a\u4eba\uff1a - \u8bb0\u5f55\u4eba\uff1a", + "tags": [ + "03_\u89c4\u8303\u4e0e\u6a21\u677f", + "[\u6a21\u677f", + "\u4f1a\u8bae\u7eaa\u8981]" + ], + "complexity": "simple", + "knowledgeMeta": { + "wikilinks": [], + "content": "---\ntype: template\ntags: [\u6a21\u677f, \u4f1a\u8bae\u7eaa\u8981]\naliases: [\u4f1a\u8bae\u8bb0\u5f55\u6a21\u677f]\nsource: manual\nstatus: active\nowner: \u5185\u90e8\u6280\u672f\u56e2\u961f\nupdated: 2026-05\n---\n\n# \u4f1a\u8bae\u7eaa\u8981\u6a21\u677f\n\n## \u57fa\u672c\u4fe1\u606f\n\n- \u4f1a\u8bae\u4e3b\u9898\uff1a\n- \u65f6\u95f4\uff1a\n- \u53c2\u4f1a\u4eba\uff1a\n- \u8bb0\u5f55\u4eba\uff1a\n\n## \u7ed3\u8bba\n\n| \u7f16\u53f7 | \u7ed3\u8bba | \u8d1f\u8d23\u4eba | \u622a\u6b62\u65f6\u95f4 |\n|---|---|---|---|\n| | | | |\n\n## \u5f85\u529e\n\n| \u4e8b\u9879 | \u8d1f\u8d23\u4eba | \u622a\u6b62\u65f6\u95f4 | \u72b6\u6001 |\n|---|---|---|---|\n| | | | |\n\n## \u98ce\u9669\u4e0e\u95ee\u9898\n\n| \u95ee\u9898 | \u5f71\u54cd | \u5904\u7406\u65b9\u5f0f |\n|---|---|---|\n| | | |\n", + "backlinks": [] + } + }, + { + "id": "article:03_\u89c4\u8303\u4e0e\u6a21\u677f/\u9700\u6c42\u8bf4\u660e\u6a21\u677f", + "type": "article", + "name": "\u9700\u6c42\u8bf4\u660e\u6a21\u677f", + "filePath": "03_\u89c4\u8303\u4e0e\u6a21\u677f\\\u9700\u6c42\u8bf4\u660e\u6a21\u677f.md", + "summary": "- \u80cc\u666f\uff1a - \u8981\u89e3\u51b3\u7684\u95ee\u9898\uff1a - \u76ee\u6807\u7528\u6237\uff1a - \u9884\u671f\u6536\u76ca\uff1a", + "tags": [ + "03_\u89c4\u8303\u4e0e\u6a21\u677f", + "[\u6a21\u677f", + "\u9700\u6c42\u8bf4\u660e]" + ], + "complexity": "simple", + "knowledgeMeta": { + "wikilinks": [], + "content": "---\ntype: template\ntags: [\u6a21\u677f, \u9700\u6c42\u8bf4\u660e]\naliases: [\u9700\u6c42\u6a21\u677f, \u4e1a\u52a1\u9700\u6c42\u5305]\nsource: manual\nstatus: active\nowner: \u4ea7\u54c1\u7ecf\u7406 / \u4e1a\u52a1\u4e3b\u7ba1\nupdated: 2026-05\n---\n\n# \u9700\u6c42\u8bf4\u660e\u6a21\u677f\n\n## \u80cc\u666f\u4e0e\u76ee\u6807\n\n- \u80cc\u666f\uff1a\n- \u8981\u89e3\u51b3\u7684\u95ee\u9898\uff1a\n- \u76ee\u6807\u7528\u6237\uff1a\n- \u9884\u671f\u6536\u76ca\uff1a\n\n## \u8303\u56f4\n\n- V1 \u8303\u56f4\uff1a\n- V2 \u8303\u56f4\uff1a\n- \u4e0d\u5305\u542b\u8303\u56f4\uff1a\n\n## \u4e3b\u6d41\u7a0b\n\n1. \n2. \n3. \n\n## \u9875\u9762\u4e0e\u6309\u94ae\n\n| \u9875\u9762 | \u6309\u94ae/\u64cd\u4f5c | \u884c\u4e3a\u8bf4\u660e | \u6743\u9650 | \u5907\u6ce8 |\n|---|---|---|---|---|\n| | | | | |\n\n## \u4e1a\u52a1\u5bf9\u8c61\n\n| \u5bf9\u8c61 | \u5b57\u6bb5 | \u72b6\u6001 | \u8bf4\u660e |\n|---|---|---|---|\n| | | | |\n\n## \u5206\u652f\u4e0e\u5f02\u5e38\n\n| \u573a\u666f | \u5904\u7406\u65b9\u5f0f | \u8d1f\u8d23\u4eba |\n|---|---|---|\n| | | |\n\n## \u9a8c\u6536\u53e3\u5f84\n\n- \n", + "backlinks": [] + } + }, + { + "id": "article:04_Agent\u68c0\u7d22/\u5173\u952e\u8bcd\u7d22\u5f15", + "type": "article", + "name": "\u5173\u952e\u8bcd\u7d22\u5f15", + "filePath": "04_Agent\u68c0\u7d22\\\u5173\u952e\u8bcd\u7d22\u5f15.md", + "summary": "| \u5173\u952e\u8bcd | \u63a8\u8350\u68c0\u7d22\u6587\u4ef6 | |---|---| | \u5185\u90e8\u7cfb\u7edf\u5f00\u53d1\u6d41\u7a0b | `02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/AI\u9a71\u52a8\u5185\u90e8\u7cfb\u7edf\u5f00\u53d1\u6d41\u7a0b_V3_\u603b\u89c8.md` | | ERP \u5f00\u53d1\u6d41\u7a0b | `02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/AI\u9a71\u52a8\u5185\u90e8\u7cfb\u7edf\u5f00\u53d1\u6d41\u7a0b_V3_\u603b\u89c8.md` | | \u9879\u76ee\u5165\u53e3 | `02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/\u9636\u6bb50_\u9879\u76ee\u5165\u53e3\u5206\u7ea7.md` | | \u9879\u76ee\u5206\u7ea7 | `02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/\u9636\u6bb50_\u9879\u76ee\u5165\u53e3\u5206\u7ea7.md` ...", + "tags": [ + "04_Agent\u68c0\u7d22", + "[Agent", + "\u5173\u952e\u8bcd", + "\u7d22\u5f15]" + ], + "complexity": "simple", + "knowledgeMeta": { + "wikilinks": [], + "content": "---\ntype: keyword_index\ntags: [Agent, \u5173\u952e\u8bcd, \u7d22\u5f15]\naliases: [\u5173\u952e\u8bcd\u6620\u5c04]\nsource: manual\nstatus: active\nowner: \u5185\u90e8\u6280\u672f\u56e2\u961f\nupdated: 2026-05\n---\n\n# \u5173\u952e\u8bcd\u7d22\u5f15\n\n| \u5173\u952e\u8bcd | \u63a8\u8350\u68c0\u7d22\u6587\u4ef6 |\n|---|---|\n| \u5185\u90e8\u7cfb\u7edf\u5f00\u53d1\u6d41\u7a0b | `02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/AI\u9a71\u52a8\u5185\u90e8\u7cfb\u7edf\u5f00\u53d1\u6d41\u7a0b_V3_\u603b\u89c8.md` |\n| ERP \u5f00\u53d1\u6d41\u7a0b | `02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/AI\u9a71\u52a8\u5185\u90e8\u7cfb\u7edf\u5f00\u53d1\u6d41\u7a0b_V3_\u603b\u89c8.md` |\n| \u9879\u76ee\u5165\u53e3 | `02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/\u9636\u6bb50_\u9879\u76ee\u5165\u53e3\u5206\u7ea7.md` |\n| \u9879\u76ee\u5206\u7ea7 | `02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/\u9636\u6bb50_\u9879\u76ee\u5165\u53e3\u5206\u7ea7.md` |\n| S \u7c7b / M \u7c7b / L \u7c7b | `02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/\u9636\u6bb50_\u9879\u76ee\u5165\u53e3\u5206\u7ea7.md` |\n| \u4e1a\u52a1\u9700\u6c42 | `02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/\u9636\u6bb51_\u4e1a\u52a1\u9700\u6c42\u5b8c\u6574\u5f62\u6210.md` |\n| Vibe Coding | `02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/\u9636\u6bb51_\u4e1a\u52a1\u9700\u6c42\u5b8c\u6574\u5f62\u6210.md` |\n| \u9ad8\u4fdd\u771f\u6a21\u578b | `02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/\u9636\u6bb52_\u9ad8\u4fdd\u771f\u6a21\u578b\u4e0e\u4e1a\u52a1\u5bf9\u8c61\u786e\u8ba4.md` |\n| \u4e1a\u52a1\u5bf9\u8c61 | `02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/\u9636\u6bb52_\u9ad8\u4fdd\u771f\u6a21\u578b\u4e0e\u4e1a\u52a1\u5bf9\u8c61\u786e\u8ba4.md`\u3001`01_\u4e1a\u52a1\u6d41\u7a0b/\u4e1a\u52a1\u5bf9\u8c61\u5b57\u5178.md` |\n| \u6309\u94ae\u884c\u4e3a | `02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/\u9636\u6bb52_\u9ad8\u4fdd\u771f\u6a21\u578b\u4e0e\u4e1a\u52a1\u5bf9\u8c61\u786e\u8ba4.md` |\n| \u6d4b\u8bd5\u63d0\u524d\u8865\u6f0f | `02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/\u9636\u6bb52.5_\u6d4b\u8bd5\u63d0\u524d\u8865\u6f0f.md` |\n| \u6d4b\u8bd5\u7528\u4f8b\u521d\u7a3f | `02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/\u9636\u6bb52.5_\u6d4b\u8bd5\u63d0\u524d\u8865\u6f0f.md` |\n| \u6b63\u5f0f\u5f00\u53d1 | `02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/\u9636\u6bb53_\u7814\u53d1\u534f\u4f5c\u4e0e\u6b63\u5f0f\u5f00\u53d1.md` |\n| \u7814\u53d1\u534f\u4f5c | `02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/\u9636\u6bb53_\u7814\u53d1\u534f\u4f5c\u4e0e\u6b63\u5f0f\u5f00\u53d1.md` |\n| \u4ee3\u7801\u6cbb\u7406 | `02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/\u9636\u6bb53_\u7814\u53d1\u534f\u4f5c\u4e0e\u6b63\u5f0f\u5f00\u53d1.md`\u3001`02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/AI\u9a71\u52a8\u5185\u90e8\u7cfb\u7edf\u5f00\u53d1\u6d41\u7a0b_V3_\u603b\u89c8.md` |\n| \u4e0a\u7ebf\u9a8c\u6536 | `02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/\u9636\u6bb54_\u6d4b\u8bd5\u57f9\u8bad\u4e0a\u7ebf\u56de\u6d41.md` |\n| \u5185\u90e8\u57f9\u8bad | `02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/\u9636\u6bb54_\u6d4b\u8bd5\u57f9\u8bad\u4e0a\u7ebf\u56de\u6d41.md` |\n| \u95ee\u9898\u56de\u6d41 | `02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/\u9636\u6bb54_\u6d4b\u8bd5\u57f9\u8bad\u4e0a\u7ebf\u56de\u6d41.md` |\n| \u6280\u672f\u503a | `02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/AI\u9a71\u52a8\u5185\u90e8\u7cfb\u7edf\u5f00\u53d1\u6d41\u7a0b_V3_\u603b\u89c8.md`\u3001`02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/\u9879\u76ee\u68c0\u67e5\u6e05\u5355.md` |\n| \u95e8\u7981 | `02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/\u9879\u76ee\u68c0\u67e5\u6e05\u5355.md` |\n| \u4ea4\u4ed8\u7269 | `02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/\u9636\u6bb5\u4ea4\u4ed8\u7269\u6e05\u5355.md` |\n| \u8c01\u8d1f\u8d23 | `02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/\u89d2\u8272\u804c\u8d23\u77e9\u9635.md` |\n| \u4e1a\u52a1\u89c4\u5219\u8865\u5145 | `03_\u89c4\u8303\u4e0e\u6a21\u677f/\u4e1a\u52a1\u89c4\u5219\u4e0e\u9700\u6c42\u8865\u5145\u6a21\u677f.md`\u3001`04_Agent\u68c0\u7d22/\u77e5\u8bc6\u5e93\u6301\u7eed\u66f4\u65b0\u4e0e\u9a8c\u8bc1\u6d41\u7a0b.md` |\n| \u9700\u6c42\u8865\u5145 | `03_\u89c4\u8303\u4e0e\u6a21\u677f/\u4e1a\u52a1\u89c4\u5219\u4e0e\u9700\u6c42\u8865\u5145\u6a21\u677f.md`\u3001`03_\u89c4\u8303\u4e0e\u6a21\u677f/\u9700\u6c42\u8bf4\u660e\u6a21\u677f.md` |\n| \u65b0\u589e\u4e1a\u52a1\u6d41\u7a0b | `03_\u89c4\u8303\u4e0e\u6a21\u677f/\u4e1a\u52a1\u89c4\u5219\u4e0e\u9700\u6c42\u8865\u5145\u6a21\u677f.md`\u3001`03_\u89c4\u8303\u4e0e\u6a21\u677f/\u4e1a\u52a1\u6d41\u7a0b\u68b3\u7406\u6a21\u677f.md` |\n| \u68c0\u7d22\u9a8c\u8bc1 | `04_Agent\u68c0\u7d22/\u77e5\u8bc6\u5e93\u6301\u7eed\u66f4\u65b0\u4e0e\u9a8c\u8bc1\u6d41\u7a0b.md`\u3001`01_\u4e1a\u52a1\u6d41\u7a0b/\u4e1a\u52a1\u8865\u5145\u9a8c\u8bc1\u8bb0\u5f55.md` |\n| Agent \u95ee\u7b54\u9a8c\u8bc1 | `04_Agent\u68c0\u7d22/\u77e5\u8bc6\u5e93\u6301\u7eed\u66f4\u65b0\u4e0e\u9a8c\u8bc1\u6d41\u7a0b.md`\u3001`01_\u4e1a\u52a1\u6d41\u7a0b/\u4e1a\u52a1\u8865\u5145\u9a8c\u8bc1\u8bb0\u5f55.md` |\n", + "backlinks": [ + "article:\u77e5\u8bc6\u5e93\u4f7f\u7528\u8bf4\u660e", + "article:\u77e5\u8bc6\u5e93\u4f7f\u7528\u8bf4\u660e", + "article:\u77e5\u8bc6\u5e93\u4f7f\u7528\u8bf4\u660e" + ] + } + }, + { + "id": "article:04_Agent\u68c0\u7d22/\u540c\u4e49\u8bcd\u8868", + "type": "article", + "name": "\u540c\u4e49\u8bcd\u8868", + "filePath": "04_Agent\u68c0\u7d22\\\u540c\u4e49\u8bcd\u8868.md", + "summary": "| \u7528\u6237\u8bf4\u6cd5 | \u6807\u51c6\u672f\u8bed | \u63a8\u8350\u68c0\u7d22\u6587\u4ef6 | |---|---|---| | \u63d0\u9700\u6c42 | \u4e1a\u52a1\u9700\u6c42\u5b8c\u6574\u5f62\u6210 / \u9879\u76ee\u5165\u53e3\u5206\u7ea7 | `\u9636\u6bb51_\u4e1a\u52a1\u9700\u6c42\u5b8c\u6574\u5f62\u6210.md`\u3001`\u9636\u6bb50_\u9879\u76ee\u5165\u53e3\u5206\u7ea7.md` | | \u7acb\u9879 | \u9879\u76ee\u5165\u53e3\u5206\u7ea7 | `\u9636\u6bb50_\u9879\u76ee\u5165\u53e3\u5206\u7ea7.md` | | \u539f\u578b | Vibe Coding \u9875\u9762 / \u9ad8\u4fdd\u771f\u6a21\u578b | `\u9636\u6bb51_\u4e1a\u52a1\u9700\u6c42\u5b8c\u6574\u5f62\u6210.md`\u3001`\u9636\u6bb52_\u9ad8\u4fdd\u771f\u6a21\u578b...", + "tags": [ + "04_Agent\u68c0\u7d22", + "[Agent", + "\u540c\u4e49\u8bcd", + "\u68c0\u7d22]" + ], + "complexity": "simple", + "knowledgeMeta": { + "wikilinks": [], + "content": "---\ntype: synonym_table\ntags: [Agent, \u540c\u4e49\u8bcd, \u68c0\u7d22]\naliases: [\u53e3\u8bed\u6620\u5c04, \u672f\u8bed\u6620\u5c04]\nsource: manual\nstatus: active\nowner: \u5185\u90e8\u6280\u672f\u56e2\u961f\nupdated: 2026-05\n---\n\n# \u540c\u4e49\u8bcd\u8868\n\n| \u7528\u6237\u8bf4\u6cd5 | \u6807\u51c6\u672f\u8bed | \u63a8\u8350\u68c0\u7d22\u6587\u4ef6 |\n|---|---|---|\n| \u63d0\u9700\u6c42 | \u4e1a\u52a1\u9700\u6c42\u5b8c\u6574\u5f62\u6210 / \u9879\u76ee\u5165\u53e3\u5206\u7ea7 | `\u9636\u6bb51_\u4e1a\u52a1\u9700\u6c42\u5b8c\u6574\u5f62\u6210.md`\u3001`\u9636\u6bb50_\u9879\u76ee\u5165\u53e3\u5206\u7ea7.md` |\n| \u7acb\u9879 | \u9879\u76ee\u5165\u53e3\u5206\u7ea7 | `\u9636\u6bb50_\u9879\u76ee\u5165\u53e3\u5206\u7ea7.md` |\n| \u539f\u578b | Vibe Coding \u9875\u9762 / \u9ad8\u4fdd\u771f\u6a21\u578b | `\u9636\u6bb51_\u4e1a\u52a1\u9700\u6c42\u5b8c\u6574\u5f62\u6210.md`\u3001`\u9636\u6bb52_\u9ad8\u4fdd\u771f\u6a21\u578b\u4e0e\u4e1a\u52a1\u5bf9\u8c61\u786e\u8ba4.md` |\n| \u9875\u9762\u6a21\u578b | \u9ad8\u4fdd\u771f\u6a21\u578b | `\u9636\u6bb52_\u9ad8\u4fdd\u771f\u6a21\u578b\u4e0e\u4e1a\u52a1\u5bf9\u8c61\u786e\u8ba4.md` |\n| \u5b57\u6bb5\u5b57\u5178 | \u4e1a\u52a1\u5bf9\u8c61\u6a21\u578b | `\u9636\u6bb52_\u9ad8\u4fdd\u771f\u6a21\u578b\u4e0e\u4e1a\u52a1\u5bf9\u8c61\u786e\u8ba4.md`\u3001`\u4e1a\u52a1\u5bf9\u8c61\u5b57\u5178.md` |\n| \u5f00\u53d1\u524d\u6d4b\u8bd5 | \u6d4b\u8bd5\u63d0\u524d\u8865\u6f0f | `\u9636\u6bb52.5_\u6d4b\u8bd5\u63d0\u524d\u8865\u6f0f.md` |\n| \u6d4b\u8bd5\u5148\u770b | \u6d4b\u8bd5\u63d0\u524d\u8865\u6f0f | `\u9636\u6bb52.5_\u6d4b\u8bd5\u63d0\u524d\u8865\u6f0f.md` |\n| \u5f00\u53d1\u600e\u4e48\u5f00\u59cb | \u7814\u53d1\u534f\u4f5c\u4e0e\u6b63\u5f0f\u5f00\u53d1 | `\u9636\u6bb53_\u7814\u53d1\u534f\u4f5c\u4e0e\u6b63\u5f0f\u5f00\u53d1.md` |\n| \u4e0a\u7ebf\u524d\u8981\u505a\u4ec0\u4e48 | \u6d4b\u8bd5\u57f9\u8bad\u4e0a\u7ebf\u56de\u6d41 / Gate 4 | `\u9636\u6bb54_\u6d4b\u8bd5\u57f9\u8bad\u4e0a\u7ebf\u56de\u6d41.md`\u3001`\u9879\u76ee\u68c0\u67e5\u6e05\u5355.md` |\n| \u8c01\u6765\u505a | \u89d2\u8272\u804c\u8d23 | `\u89d2\u8272\u804c\u8d23\u77e9\u9635.md` |\n| \u8981\u4ea4\u4ec0\u4e48 | \u9636\u6bb5\u4ea4\u4ed8\u7269 | `\u9636\u6bb5\u4ea4\u4ed8\u7269\u6e05\u5355.md` |\n| \u68c0\u67e5\u70b9 | \u9636\u6bb5\u95e8\u7981 / \u9879\u76ee\u68c0\u67e5\u6e05\u5355 | `\u9879\u76ee\u68c0\u67e5\u6e05\u5355.md` |\n| AI \u5199\u7684\u4ee3\u7801 | AI \u4ee3\u7801\u6cbb\u7406 | `\u9636\u6bb53_\u7814\u53d1\u534f\u4f5c\u4e0e\u6b63\u5f0f\u5f00\u53d1.md` |\n| \u52a0\u4e00\u6761\u4e1a\u52a1\u89c4\u5219 | \u4e1a\u52a1\u89c4\u5219\u8865\u5145 | `\u4e1a\u52a1\u89c4\u5219\u4e0e\u9700\u6c42\u8865\u5145\u6a21\u677f.md`\u3001`\u77e5\u8bc6\u5e93\u6301\u7eed\u66f4\u65b0\u4e0e\u9a8c\u8bc1\u6d41\u7a0b.md` |\n| \u8865\u9700\u6c42 | \u9700\u6c42\u8865\u5145 | `\u4e1a\u52a1\u89c4\u5219\u4e0e\u9700\u6c42\u8865\u5145\u6a21\u677f.md`\u3001`\u9700\u6c42\u8bf4\u660e\u6a21\u677f.md` |\n| \u65b0\u89c4\u5219\u600e\u4e48\u5199 | \u4e1a\u52a1\u89c4\u5219\u4e0e\u9700\u6c42\u8865\u5145 | `\u4e1a\u52a1\u89c4\u5219\u4e0e\u9700\u6c42\u8865\u5145\u6a21\u677f.md` |\n| \u600e\u4e48\u9a8c\u8bc1\u80fd\u4e0d\u80fd\u641c\u5230 | Agent \u68c0\u7d22\u9a8c\u8bc1 | `\u77e5\u8bc6\u5e93\u6301\u7eed\u66f4\u65b0\u4e0e\u9a8c\u8bc1\u6d41\u7a0b.md`\u3001`\u4e1a\u52a1\u8865\u5145\u9a8c\u8bc1\u8bb0\u5f55.md` |\n", + "backlinks": [ + "article:\u77e5\u8bc6\u5e93\u4f7f\u7528\u8bf4\u660e" + ] + } + }, + { + "id": "article:04_Agent\u68c0\u7d22/\u6765\u6e90\u6587\u4ef6\u7d22\u5f15", + "type": "article", + "name": "\u6765\u6e90\u6587\u4ef6\u7d22\u5f15", + "filePath": "04_Agent\u68c0\u7d22\\\u6765\u6e90\u6587\u4ef6\u7d22\u5f15.md", + "summary": "| \u6765\u6e90\u6587\u4ef6 | \u8def\u5f84 | \u7528\u9014 | \u72b6\u6001 | |---|---|---|---| | AI_\u9a71\u52a8_\u5185\u90e8\u7cfb\u7edf\u5f00\u53d1\u6d41\u7a0b_V3.docx | `D:\\\\AIcoding\\\\WishFulfilled\\\\\u77e5\u8bc6\u5e93\\\\AI_\u9a71\u52a8_\u5185\u90e8\u7cfb\u7edf\u5f00\u53d1\u6d41\u7a0b_V3.docx` | \u9879\u76ee\u7ba1\u7406\u6d41\u7a0b\u6743\u5a01\u6765\u6e90 | active |", + "tags": [ + "04_Agent\u68c0\u7d22", + "Agent]", + "[\u6765\u6e90", + "\u7d22\u5f15" + ], + "complexity": "simple", + "knowledgeMeta": { + "wikilinks": [], + "content": "---\ntype: source_index\ntags: [\u6765\u6e90, \u7d22\u5f15, Agent]\naliases: [\u6765\u6e90\u7d22\u5f15, \u539f\u59cb\u6587\u4ef6]\nsource: manual\nstatus: active\nowner: \u5185\u90e8\u6280\u672f\u56e2\u961f\nupdated: 2026-05\n---\n\n# \u6765\u6e90\u6587\u4ef6\u7d22\u5f15\n\n## \u539f\u59cb\u6765\u6e90\n\n| \u6765\u6e90\u6587\u4ef6 | \u8def\u5f84 | \u7528\u9014 | \u72b6\u6001 |\n|---|---|---|---|\n| AI_\u9a71\u52a8_\u5185\u90e8\u7cfb\u7edf\u5f00\u53d1\u6d41\u7a0b_V3.docx | `D:\\\\AIcoding\\\\WishFulfilled\\\\\u77e5\u8bc6\u5e93\\\\AI_\u9a71\u52a8_\u5185\u90e8\u7cfb\u7edf\u5f00\u53d1\u6d41\u7a0b_V3.docx` | \u9879\u76ee\u7ba1\u7406\u6d41\u7a0b\u6743\u5a01\u6765\u6e90 | active |\n\n## \u62c6\u89e3\u540e\u7684\u77e5\u8bc6\u6761\u76ee\n\n| \u6761\u76ee | \u6765\u6e90 |\n|---|---|\n| `02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/AI\u9a71\u52a8\u5185\u90e8\u7cfb\u7edf\u5f00\u53d1\u6d41\u7a0b_V3_\u603b\u89c8.md` | AI_\u9a71\u52a8_\u5185\u90e8\u7cfb\u7edf\u5f00\u53d1\u6d41\u7a0b_V3.docx |\n| `02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/\u9636\u6bb50_\u9879\u76ee\u5165\u53e3\u5206\u7ea7.md` | AI_\u9a71\u52a8_\u5185\u90e8\u7cfb\u7edf\u5f00\u53d1\u6d41\u7a0b_V3.docx |\n| `02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/\u9636\u6bb51_\u4e1a\u52a1\u9700\u6c42\u5b8c\u6574\u5f62\u6210.md` | AI_\u9a71\u52a8_\u5185\u90e8\u7cfb\u7edf\u5f00\u53d1\u6d41\u7a0b_V3.docx |\n| `02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/\u9636\u6bb52_\u9ad8\u4fdd\u771f\u6a21\u578b\u4e0e\u4e1a\u52a1\u5bf9\u8c61\u786e\u8ba4.md` | AI_\u9a71\u52a8_\u5185\u90e8\u7cfb\u7edf\u5f00\u53d1\u6d41\u7a0b_V3.docx |\n| `02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/\u9636\u6bb52.5_\u6d4b\u8bd5\u63d0\u524d\u8865\u6f0f.md` | AI_\u9a71\u52a8_\u5185\u90e8\u7cfb\u7edf\u5f00\u53d1\u6d41\u7a0b_V3.docx |\n| `02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/\u9636\u6bb53_\u7814\u53d1\u534f\u4f5c\u4e0e\u6b63\u5f0f\u5f00\u53d1.md` | AI_\u9a71\u52a8_\u5185\u90e8\u7cfb\u7edf\u5f00\u53d1\u6d41\u7a0b_V3.docx |\n| `02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/\u9636\u6bb54_\u6d4b\u8bd5\u57f9\u8bad\u4e0a\u7ebf\u56de\u6d41.md` | AI_\u9a71\u52a8_\u5185\u90e8\u7cfb\u7edf\u5f00\u53d1\u6d41\u7a0b_V3.docx |\n| `02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/\u89d2\u8272\u804c\u8d23\u77e9\u9635.md` | AI_\u9a71\u52a8_\u5185\u90e8\u7cfb\u7edf\u5f00\u53d1\u6d41\u7a0b_V3.docx |\n| `02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/\u9636\u6bb5\u4ea4\u4ed8\u7269\u6e05\u5355.md` | AI_\u9a71\u52a8_\u5185\u90e8\u7cfb\u7edf\u5f00\u53d1\u6d41\u7a0b_V3.docx |\n| `02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/\u9879\u76ee\u68c0\u67e5\u6e05\u5355.md` | AI_\u9a71\u52a8_\u5185\u90e8\u7cfb\u7edf\u5f00\u53d1\u6d41\u7a0b_V3.docx |\n| `02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/\u5e38\u89c1\u95ee\u9898FAQ.md` | AI_\u9a71\u52a8_\u5185\u90e8\u7cfb\u7edf\u5f00\u53d1\u6d41\u7a0b_V3.docx |\n\n## \u4e1a\u52a1\u8865\u5145\u6765\u6e90\n\n| \u6765\u6e90\u6587\u4ef6 | \u8def\u5f84 | \u7528\u9014 | \u72b6\u6001 |\n|---|---|---|---|\n| \u9700\u6c42\u6587\u6863\u76ee\u5f55 | `05_\u9700\u6c42\u6587\u6863/` | \u6301\u7eed\u5b58\u653e\u65b0\u589e\u4e1a\u52a1\u9700\u6c42\u3001\u4e1a\u52a1\u89c4\u5219\u548c\u9700\u6c42\u53d8\u66f4\u6587\u6863 | active |\n| \u9700\u6c42\u6587\u6863\u7d22\u5f15.md | `05_\u9700\u6c42\u6587\u6863/\u9700\u6c42\u6587\u6863\u7d22\u5f15.md` | \u767b\u8bb0\u65b0\u589e\u9700\u6c42\u6587\u6863\u53ca Agent \u68c0\u7d22\u9a8c\u8bc1\u72b6\u6001 | active |\n| \u4e1a\u52a1\u89c4\u5219\u4e0e\u9700\u6c42\u8865\u5145\u6a21\u677f.md | `03_\u89c4\u8303\u4e0e\u6a21\u677f/\u4e1a\u52a1\u89c4\u5219\u4e0e\u9700\u6c42\u8865\u5145\u6a21\u677f.md` | \u65b0\u589e\u4e1a\u52a1\u89c4\u5219\u3001\u9700\u6c42\u3001\u6d41\u7a0b\u7684\u6807\u51c6\u6a21\u677f | active |\n| \u77e5\u8bc6\u5e93\u6301\u7eed\u66f4\u65b0\u4e0e\u9a8c\u8bc1\u6d41\u7a0b.md | `04_Agent\u68c0\u7d22/\u77e5\u8bc6\u5e93\u6301\u7eed\u66f4\u65b0\u4e0e\u9a8c\u8bc1\u6d41\u7a0b.md` | \u89c4\u8303\u65b0\u589e\u6587\u6863\u540e\u7684\u7d22\u5f15\u540c\u6b65\u548c Agent \u68c0\u7d22\u9a8c\u8bc1 | active |\n| \u4e1a\u52a1\u8865\u5145\u9a8c\u8bc1\u8bb0\u5f55.md | `01_\u4e1a\u52a1\u6d41\u7a0b/\u4e1a\u52a1\u8865\u5145\u9a8c\u8bc1\u8bb0\u5f55.md` | \u8bb0\u5f55\u65b0\u589e\u4e1a\u52a1\u6587\u6863\u662f\u5426\u80fd\u88ab Agent \u68c0\u7d22\u5e76\u56de\u7b54 | active |\n| \u91cc\u7a0b\u7891\u76ee\u5f55 | `06_\u91cc\u7a0b\u7891/` | \u5b58\u653e\u91cc\u7a0b\u7891\u8ba1\u5212\u3001\u9636\u6bb5\u8bc4\u5ba1\u548c\u9879\u76ee\u8282\u70b9\u6750\u6599 | active |\n| \u6280\u672f\u6587\u6863\u76ee\u5f55 | `07_\u6280\u672f\u6587\u6863/` | \u5b58\u653e\u67b6\u6784\u3001\u63a5\u53e3\u3001\u6570\u636e\u6a21\u578b\u3001\u5b9e\u73b0\u65b9\u6848\u548c\u6280\u672f\u51b3\u7b56 | active |\n| \u6d4b\u8bd5\u76f8\u5173\u76ee\u5f55 | `08_\u6d4b\u8bd5\u76f8\u5173/` | \u5b58\u653e\u6d4b\u8bd5\u8ba1\u5212\u3001\u6d4b\u8bd5\u7528\u4f8b\u3001\u7f3a\u9677\u3001\u9a8c\u6536\u548c\u4e0a\u7ebf\u68c0\u67e5\u6750\u6599 | active |\n\n## \u7ef4\u62a4\u8981\u6c42\n\n- \u4ece\u539f\u59cb docx \u66f4\u65b0\u6d41\u7a0b\u65f6\uff0c\u9700\u8981\u540c\u6b65\u66f4\u65b0\u9636\u6bb5\u6587\u4ef6\u3001\u89d2\u8272\u804c\u8d23\u77e9\u9635\u3001\u4ea4\u4ed8\u7269\u6e05\u5355\u3001\u68c0\u67e5\u6e05\u5355\u3001FAQ\u3001\u5173\u952e\u8bcd\u7d22\u5f15\u548c\u540c\u4e49\u8bcd\u8868\u3002\n- \u65b0\u589e\u4e1a\u52a1\u89c4\u5219\u3001\u9700\u6c42\u6216\u6d41\u7a0b\u6587\u6863\u65f6\uff0c\u539f\u59cb\u9700\u6c42\u6587\u6863\u7edf\u4e00\u653e\u5165 `05_\u9700\u6c42\u6587\u6863/`\uff0c\u5e76\u540c\u6b65\u66f4\u65b0\u9700\u6c42\u6587\u6863\u7d22\u5f15\u3001\u4e1a\u52a1\u89c4\u5219\u7d22\u5f15\u3001\u4e1a\u52a1\u5bf9\u8c61\u5b57\u5178\u3001\u5173\u952e\u8bcd\u7d22\u5f15\u3001\u540c\u4e49\u8bcd\u8868\u548c\u672c\u6765\u6e90\u6587\u4ef6\u7d22\u5f15\u3002\n- \u65b0\u589e\u91cc\u7a0b\u7891\u6750\u6599\u7edf\u4e00\u653e\u5165 `06_\u91cc\u7a0b\u7891/`\uff0c\u5e76\u540c\u6b65\u66f4\u65b0\u91cc\u7a0b\u7891\u7d22\u5f15\u3002\n- \u65b0\u589e\u6280\u672f\u6750\u6599\u7edf\u4e00\u653e\u5165 `07_\u6280\u672f\u6587\u6863/`\uff0c\u5e76\u540c\u6b65\u66f4\u65b0\u6280\u672f\u6587\u6863\u7d22\u5f15\u3002\n- \u65b0\u589e\u6d4b\u8bd5\u6750\u6599\u7edf\u4e00\u653e\u5165 `08_\u6d4b\u8bd5\u76f8\u5173/`\uff0c\u5e76\u540c\u6b65\u66f4\u65b0\u6d4b\u8bd5\u7528\u4f8b\u7d22\u5f15\u6216\u5bf9\u5e94\u6d4b\u8bd5\u8bb0\u5f55\u3002\n- Agent \u56de\u7b54\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b\u95ee\u9898\u65f6\uff0c\u5e94\u4f18\u5148\u5f15\u7528\u62c6\u89e3\u540e\u7684 Markdown \u6587\u4ef6\u3002\n- Agent \u56de\u7b54\u5177\u4f53\u4e1a\u52a1\u89c4\u5219\u548c\u9700\u6c42\u95ee\u9898\u65f6\uff0c\u5e94\u4f18\u5148\u5f15\u7528 `05_\u9700\u6c42\u6587\u6863/` \u4e0b\u7684\u6b63\u5f0f\u9700\u6c42\u6587\u6863\uff1b\u7a33\u5b9a\u6d41\u7a0b\u53ef\u518d\u5f15\u7528 `01_\u4e1a\u52a1\u6d41\u7a0b/` \u4e0b\u7684\u4e1a\u52a1\u6d41\u7a0b\u6761\u76ee\u3002\n", + "backlinks": [ + "article:\u77e5\u8bc6\u5e93\u4f7f\u7528\u8bf4\u660e", + "article:\u77e5\u8bc6\u5e93\u4f7f\u7528\u8bf4\u660e", + "article:\u77e5\u8bc6\u5e93\u4f7f\u7528\u8bf4\u660e", + "article:\u77e5\u8bc6\u5e93\u4f7f\u7528\u8bf4\u660e" + ] + } + }, + { + "id": "article:04_Agent\u68c0\u7d22/\u68c0\u7d22\u8bf4\u660e", + "type": "article", + "name": "Agent \u68c0\u7d22\u8bf4\u660e", + "filePath": "04_Agent\u68c0\u7d22\\\u68c0\u7d22\u8bf4\u660e.md", + "summary": "\u8ba9 Agent \u5728\u56de\u7b54\u4e1a\u52a1\u6d41\u7a0b\u548c\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b\u95ee\u9898\u65f6\uff0c\u4f18\u5148\u57fa\u4e8e\u672c\u5730 Markdown \u77e5\u8bc6\u5e93\u68c0\u7d22\uff0c\u800c\u4e0d\u662f\u51ed\u7a7a\u56de\u7b54\u3002", + "tags": [ + "04_Agent\u68c0\u7d22", + "[Agent", + "\u68c0\u7d22", + "\u89c4\u5219]" + ], + "complexity": "simple", + "knowledgeMeta": { + "wikilinks": [ + "\u77e5\u8bc6\u5e93\u6301\u7eed\u66f4\u65b0\u4e0e\u9a8c\u8bc1\u6d41\u7a0b" + ], + "content": "---\ntype: agent_retrieval_guide\ntags: [Agent, \u68c0\u7d22, \u89c4\u5219]\naliases: [Agent\u68c0\u7d22\u8bf4\u660e, \u68c0\u7d22\u89c4\u5219]\nsource: manual\nstatus: active\nowner: \u5185\u90e8\u6280\u672f\u56e2\u961f\nupdated: 2026-05\n---\n\n# Agent \u68c0\u7d22\u8bf4\u660e\n\n## \u76ee\u6807\n\n\u8ba9 Agent \u5728\u56de\u7b54\u4e1a\u52a1\u6d41\u7a0b\u548c\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b\u95ee\u9898\u65f6\uff0c\u4f18\u5148\u57fa\u4e8e\u672c\u5730 Markdown \u77e5\u8bc6\u5e93\u68c0\u7d22\uff0c\u800c\u4e0d\u662f\u51ed\u7a7a\u56de\u7b54\u3002\n\n## \u68c0\u7d22\u4f18\u5148\u7ea7\n\n1. `05_\u9700\u6c42\u6587\u6863/`\uff1a\u6301\u7eed\u65b0\u589e\u7684\u4e1a\u52a1\u9700\u6c42\u3001\u4e1a\u52a1\u89c4\u5219\u3001\u9700\u6c42\u53d8\u66f4\u548c\u8865\u5145\u8bf4\u660e\u3002\n2. `06_\u91cc\u7a0b\u7891/`\uff1a\u9879\u76ee\u8282\u70b9\u3001\u9636\u6bb5\u8ba1\u5212\u3001\u9636\u6bb5\u8bc4\u5ba1\u548c\u4e0a\u7ebf\u8282\u594f\u3002\n3. `07_\u6280\u672f\u6587\u6863/`\uff1a\u7cfb\u7edf\u67b6\u6784\u3001\u6570\u636e\u6a21\u578b\u3001\u63a5\u53e3\u8bf4\u660e\u3001\u5b9e\u73b0\u65b9\u6848\u548c\u6280\u672f\u51b3\u7b56\u3002\n4. `08_\u6d4b\u8bd5\u76f8\u5173/`\uff1a\u6d4b\u8bd5\u8ba1\u5212\u3001\u6d4b\u8bd5\u7528\u4f8b\u3001\u7f3a\u9677\u8bb0\u5f55\u3001\u9a8c\u6536\u8bb0\u5f55\u548c\u4e0a\u7ebf\u68c0\u67e5\u3002\n5. `02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/`\uff1a\u5185\u90e8\u7cfb\u7edf\u5f00\u53d1\u6d41\u7a0b\u3001\u9636\u6bb5\u3001\u89d2\u8272\u3001\u95e8\u7981\u3001\u4ea4\u4ed8\u7269\u3001\u68c0\u67e5\u6e05\u5355\u3002\n6. `01_\u4e1a\u52a1\u6d41\u7a0b/`\uff1a\u771f\u5b9e\u4e1a\u52a1\u6d41\u7a0b\u3001\u4e1a\u52a1\u5bf9\u8c61\u3001\u4e1a\u52a1\u89c4\u5219\u3002\n7. `04_Agent\u68c0\u7d22/`\uff1a\u5173\u952e\u8bcd\u3001\u540c\u4e49\u8bcd\u3001\u6765\u6e90\u7d22\u5f15\u3001\u56de\u7b54\u89c4\u5219\u3002\n8. `03_\u89c4\u8303\u4e0e\u6a21\u677f/`\uff1a\u9700\u8981\u4ea7\u51fa\u6a21\u677f\u6216\u6587\u6863\u65f6\u4f7f\u7528\u3002\n\n## \u95ee\u9898\u7c7b\u578b\u4e0e\u547d\u4e2d\u6587\u4ef6\n\n| \u95ee\u9898\u7c7b\u578b | \u4f18\u5148\u6587\u4ef6 |\n|---|---|\n| \u6d41\u7a0b\u9636\u6bb5 | `AI\u9a71\u52a8\u5185\u90e8\u7cfb\u7edf\u5f00\u53d1\u6d41\u7a0b_V3_\u603b\u89c8.md`\u3001\u5404\u9636\u6bb5\u6587\u4ef6 |\n| \u89d2\u8272\u804c\u8d23 | `\u89d2\u8272\u804c\u8d23\u77e9\u9635.md` |\n| \u4ea4\u4ed8\u7269 | `\u9636\u6bb5\u4ea4\u4ed8\u7269\u6e05\u5355.md` |\n| \u95e8\u7981/\u68c0\u67e5 | `\u9879\u76ee\u68c0\u67e5\u6e05\u5355.md` |\n| \u5e38\u89c1\u95ee\u7b54 | `\u5e38\u89c1\u95ee\u9898FAQ.md` |\n| \u4e1a\u52a1\u5bf9\u8c61 | `01_\u4e1a\u52a1\u6d41\u7a0b/\u4e1a\u52a1\u5bf9\u8c61\u5b57\u5178.md`\u3001`\u9636\u6bb52_\u9ad8\u4fdd\u771f\u6a21\u578b\u4e0e\u4e1a\u52a1\u5bf9\u8c61\u786e\u8ba4.md` |\n| \u4e1a\u52a1\u89c4\u5219 | `05_\u9700\u6c42\u6587\u6863/`\u3001`05_\u9700\u6c42\u6587\u6863/\u9700\u6c42\u6587\u6863\u7d22\u5f15.md`\u3001`01_\u4e1a\u52a1\u6d41\u7a0b/\u4e1a\u52a1\u89c4\u5219\u7d22\u5f15.md` |\n| \u4e1a\u52a1\u9700\u6c42 | `05_\u9700\u6c42\u6587\u6863/`\u3001`05_\u9700\u6c42\u6587\u6863/\u9700\u6c42\u6587\u6863\u7d22\u5f15.md` |\n| \u9879\u76ee\u91cc\u7a0b\u7891 | `06_\u91cc\u7a0b\u7891/`\u3001`06_\u91cc\u7a0b\u7891/\u91cc\u7a0b\u7891\u7d22\u5f15.md` |\n| \u6280\u672f\u5b9e\u73b0 | `07_\u6280\u672f\u6587\u6863/`\u3001`07_\u6280\u672f\u6587\u6863/\u6280\u672f\u6587\u6863\u7d22\u5f15.md` |\n| \u63a5\u53e3/\u6570\u636e\u6a21\u578b | `07_\u6280\u672f\u6587\u6863/\u63a5\u53e3\u8bf4\u660e\u6a21\u677f.md`\u3001\u5177\u4f53\u63a5\u53e3\u6587\u6863\u3001\u5177\u4f53\u6570\u636e\u6a21\u578b\u6587\u6863 |\n| \u6d4b\u8bd5\u7528\u4f8b | `08_\u6d4b\u8bd5\u76f8\u5173/`\u3001`08_\u6d4b\u8bd5\u76f8\u5173/\u6d4b\u8bd5\u7528\u4f8b\u7d22\u5f15.md` |\n| \u7f3a\u9677/\u9a8c\u6536/\u4e0a\u7ebf\u68c0\u67e5 | `08_\u6d4b\u8bd5\u76f8\u5173/\u7f3a\u9677\u8bb0\u5f55\u6a21\u677f.md`\u3001`08_\u6d4b\u8bd5\u76f8\u5173/\u9a8c\u6536\u8bb0\u5f55\u6a21\u677f.md`\u3001`08_\u6d4b\u8bd5\u76f8\u5173/\u4e0a\u7ebf\u68c0\u67e5\u6a21\u677f.md` |\n\n## \u56de\u7b54\u89c4\u5219\n\n- \u5148\u56de\u7b54\u7ed3\u8bba\uff0c\u518d\u5c55\u5f00\u4f9d\u636e\u3002\n- \u6d41\u7a0b\u95ee\u9898\u6309\u201c\u9636\u6bb5\u3001\u8d1f\u8d23\u4eba\u3001\u8f93\u5165\u3001\u52a8\u4f5c\u3001\u8f93\u51fa\u3001\u68c0\u67e5\u70b9\u201d\u7ec4\u7ec7\u3002\n- \u89d2\u8272\u95ee\u9898\u6309\u201c\u8d1f\u8d23\u9636\u6bb5\u3001\u6838\u5fc3\u804c\u8d23\u3001\u5178\u578b\u4ea7\u51fa\u201d\u7ec4\u7ec7\u3002\n- \u4ea4\u4ed8\u7269\u95ee\u9898\u5217\u51fa\u6587\u4ef6\u540d\u3002\n- \u4e1a\u52a1\u89c4\u5219\u548c\u9700\u6c42\u95ee\u9898\u4f18\u5148\u68c0\u7d22 `05_\u9700\u6c42\u6587\u6863/` \u4e0b\u7684\u6b63\u5f0f\u9700\u6c42\u6587\u6863\uff0c\u518d\u68c0\u7d22 `05_\u9700\u6c42\u6587\u6863/\u9700\u6c42\u6587\u6863\u7d22\u5f15.md`\u3001`01_\u4e1a\u52a1\u6d41\u7a0b/\u4e1a\u52a1\u89c4\u5219\u7d22\u5f15.md`\u3001`\u5173\u952e\u8bcd\u7d22\u5f15.md` \u548c `\u540c\u4e49\u8bcd\u8868.md`\u3002\n- \u91cc\u7a0b\u7891\u95ee\u9898\u4f18\u5148\u68c0\u7d22 `06_\u91cc\u7a0b\u7891/` \u548c `06_\u91cc\u7a0b\u7891/\u91cc\u7a0b\u7891\u7d22\u5f15.md`\u3002\n- \u6280\u672f\u95ee\u9898\u4f18\u5148\u68c0\u7d22 `07_\u6280\u672f\u6587\u6863/` \u548c `07_\u6280\u672f\u6587\u6863/\u6280\u672f\u6587\u6863\u7d22\u5f15.md`\u3002\n- \u6d4b\u8bd5\u95ee\u9898\u4f18\u5148\u68c0\u7d22 `08_\u6d4b\u8bd5\u76f8\u5173/` \u548c `08_\u6d4b\u8bd5\u76f8\u5173/\u6d4b\u8bd5\u7528\u4f8b\u7d22\u5f15.md`\u3002\n- \u5fc5\u987b\u6ce8\u660e\u6765\u6e90\u6587\u4ef6\u540d\u3002\n- \u5982\u679c\u77e5\u8bc6\u5e93\u672a\u660e\u786e\u8bb0\u5f55\uff0c\u4e0d\u8981\u63a8\u6d4b\uff0c\u5e94\u56de\u7b54\u201c\u77e5\u8bc6\u5e93\u672a\u660e\u786e\u8bb0\u5f55\u201d\uff0c\u5e76\u5efa\u8bae\u8865\u5145\u5230\u5177\u4f53\u6587\u4ef6\u3002\n\n## \u6301\u7eed\u66f4\u65b0\u9a8c\u8bc1\n\n\u65b0\u589e\u4e1a\u52a1\u89c4\u5219\u3001\u9700\u6c42\u6216\u6d41\u7a0b\u6587\u6863\u540e\uff0c\u6309 [[\u77e5\u8bc6\u5e93\u6301\u7eed\u66f4\u65b0\u4e0e\u9a8c\u8bc1\u6d41\u7a0b]] \u6267\u884c\u9a8c\u8bc1\u3002\n\u65b0\u589e\u6587\u6863\u5e94\u4f7f\u7528 `03_\u89c4\u8303\u4e0e\u6a21\u677f/\u4e1a\u52a1\u89c4\u5219\u4e0e\u9700\u6c42\u8865\u5145\u6a21\u677f.md`\uff0c\u6b63\u5f0f\u9700\u6c42\u6587\u6863\u4fdd\u5b58\u5230 `05_\u9700\u6c42\u6587\u6863/`\uff0c\u9a8c\u8bc1\u7ed3\u679c\u8bb0\u5f55\u5230 `05_\u9700\u6c42\u6587\u6863/\u9700\u6c42\u6587\u6863\u7d22\u5f15.md` \u548c `01_\u4e1a\u52a1\u6d41\u7a0b/\u4e1a\u52a1\u8865\u5145\u9a8c\u8bc1\u8bb0\u5f55.md`\u3002\n\n## \u5f15\u7528\u683c\u5f0f\n\n\u5efa\u8bae\u5728\u56de\u7b54\u672b\u5c3e\u4f7f\u7528\uff1a\n\n> \u6765\u6e90\uff1a`02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/\u9636\u6bb52.5_\u6d4b\u8bd5\u63d0\u524d\u8865\u6f0f.md`\n", + "backlinks": [ + "article:\u6b22\u8fce", + "article:\u77e5\u8bc6\u5e93\u4f7f\u7528\u8bf4\u660e", + "article:\u77e5\u8bc6\u5e93\u4f7f\u7528\u8bf4\u660e" + ] + } + }, + { + "id": "article:04_Agent\u68c0\u7d22/\u77e5\u8bc6\u5e93\u6301\u7eed\u66f4\u65b0\u4e0e\u9a8c\u8bc1\u6d41\u7a0b", + "type": "article", + "name": "\u77e5\u8bc6\u5e93\u6301\u7eed\u66f4\u65b0\u4e0e\u9a8c\u8bc1\u6d41\u7a0b", + "filePath": "04_Agent\u68c0\u7d22\\\u77e5\u8bc6\u5e93\u6301\u7eed\u66f4\u65b0\u4e0e\u9a8c\u8bc1\u6d41\u7a0b.md", + "summary": "\u786e\u4fdd\u4e1a\u52a1\u89c4\u5219\u3001\u4e1a\u52a1\u9700\u6c42\u548c\u6d41\u7a0b\u8865\u5145\u540e\uff0cAgent \u80fd\u901a\u8fc7\u6587\u4ef6\u68c0\u7d22\u547d\u4e2d\u65b0\u5185\u5bb9\uff0c\u5e76\u57fa\u4e8e\u77e5\u8bc6\u5e93\u7ed9\u51fa\u53ef\u8ffd\u6eaf\u56de\u7b54\u3002", + "tags": [ + "04_Agent\u68c0\u7d22", + "[Agent", + "\u68c0\u7d22", + "\u77e5\u8bc6\u5e93\u66f4\u65b0", + "\u9a8c\u8bc1\u6d41\u7a0b]" + ], + "complexity": "simple", + "knowledgeMeta": { + "wikilinks": [], + "content": "---\ntype: validation_process\ntags: [Agent, \u68c0\u7d22, \u77e5\u8bc6\u5e93\u66f4\u65b0, \u9a8c\u8bc1\u6d41\u7a0b]\naliases: [\u77e5\u8bc6\u5e93\u66f4\u65b0\u9a8c\u8bc1, Agent\u68c0\u7d22\u9a8c\u8bc1, \u8865\u5145\u6587\u6863\u9a8c\u8bc1\u6d41\u7a0b]\nsource: manual\nstatus: active\nowner: \u5185\u90e8\u6280\u672f\u56e2\u961f / \u4ea7\u54c1\u7ecf\u7406\nupdated: 2026-05\n---\n\n# \u77e5\u8bc6\u5e93\u6301\u7eed\u66f4\u65b0\u4e0e\u9a8c\u8bc1\u6d41\u7a0b\n\n## 1. \u76ee\u6807\n\n\u786e\u4fdd\u4e1a\u52a1\u89c4\u5219\u3001\u4e1a\u52a1\u9700\u6c42\u548c\u6d41\u7a0b\u8865\u5145\u540e\uff0cAgent \u80fd\u901a\u8fc7\u6587\u4ef6\u68c0\u7d22\u547d\u4e2d\u65b0\u5185\u5bb9\uff0c\u5e76\u57fa\u4e8e\u77e5\u8bc6\u5e93\u7ed9\u51fa\u53ef\u8ffd\u6eaf\u56de\u7b54\u3002\n\n## 2. \u66f4\u65b0\u5165\u53e3\n\n\u4e1a\u52a1\u65b0\u589e\u6216\u4fee\u8ba2\u65f6\uff0c\u4f18\u5148\u4f7f\u7528\uff1a\n\n- `03_\u89c4\u8303\u4e0e\u6a21\u677f/\u4e1a\u52a1\u89c4\u5219\u4e0e\u9700\u6c42\u8865\u5145\u6a21\u677f.md`\n- `03_\u89c4\u8303\u4e0e\u6a21\u677f/\u9700\u6c42\u8bf4\u660e\u6a21\u677f.md`\n- `03_\u89c4\u8303\u4e0e\u6a21\u677f/\u4e1a\u52a1\u6d41\u7a0b\u68b3\u7406\u6a21\u677f.md`\n\n\u8865\u5145\u540e\u7684\u6b63\u5f0f\u9700\u6c42\u6587\u6863\u7edf\u4e00\u4fdd\u5b58\u5230\uff1a\n\n- `05_\u9700\u6c42\u6587\u6863/`\n\n\u5982\u679c\u6587\u6863\u5df2\u7ecf\u6c89\u6dc0\u4e3a\u7a33\u5b9a\u4e1a\u52a1\u6d41\u7a0b\uff0c\u518d\u540c\u6b65\u62c6\u89e3\u6216\u5f15\u7528\u5230\uff1a\n\n- `01_\u4e1a\u52a1\u6d41\u7a0b/`\n\n\u63a8\u8350\u547d\u540d\uff1a\n\n```text\n\u4e1a\u52a1\u57df_\u89c4\u5219\u6216\u9700\u6c42\u540d\u79f0_YYYYMMDD.md\n```\n\n\u793a\u4f8b\uff1a\n\n```text\n\u91c7\u8d2d_\u4f9b\u5e94\u5546\u51c6\u5165\u89c4\u5219_20260526.md\n\u5e93\u5b58_\u51fa\u5165\u5e93\u5ba1\u6279\u89c4\u5219_20260526.md\n\u9500\u552e_\u5ba2\u6237\u6388\u4fe1\u989d\u5ea6\u89c4\u5219_20260526.md\n```\n\n## 3. \u6807\u51c6\u66f4\u65b0\u6d41\u7a0b\n\n### \u6b65\u9aa4 1\uff1a\u65b0\u589e\u8865\u5145\u6587\u6863\n\n1. \u590d\u5236 `\u4e1a\u52a1\u89c4\u5219\u4e0e\u9700\u6c42\u8865\u5145\u6a21\u677f.md`\u3002\n2. \u4fdd\u5b58\u5230 `05_\u9700\u6c42\u6587\u6863/`\u3002\n3. \u8865\u5168 Frontmatter\uff1a`type`\u3001`tags`\u3001`aliases`\u3001`source`\u3001`status`\u3001`owner`\u3001`updated`\u3002\n4. \u8865\u5168\u6b63\u6587\u4e2d\u7684\u4e1a\u52a1\u89c4\u5219\u3001\u6d41\u7a0b\u3001\u5f02\u5e38\u3001\u6743\u9650\u3001\u9a8c\u6536\u53e3\u5f84\u548c Agent \u68c0\u7d22\u5b57\u6bb5\u3002\n\n### \u6b65\u9aa4 2\uff1a\u66f4\u65b0\u7d22\u5f15\n\n\u65b0\u589e\u4e1a\u52a1\u6587\u6863\u540e\uff0c\u540c\u6b65\u66f4\u65b0\uff1a\n\n| \u6587\u4ef6 | \u66f4\u65b0\u5185\u5bb9 |\n|---|---|\n| `05_\u9700\u6c42\u6587\u6863/\u9700\u6c42\u6587\u6863\u7d22\u5f15.md` | \u589e\u52a0\u9700\u6c42/\u89c4\u5219\u540d\u79f0\u3001\u4e1a\u52a1\u57df\u3001\u6765\u6e90\u6587\u4ef6\u3001\u72b6\u6001\u548c\u9a8c\u8bc1\u72b6\u6001 |\n| `01_\u4e1a\u52a1\u6d41\u7a0b/\u4e1a\u52a1\u89c4\u5219\u7d22\u5f15.md` | \u589e\u52a0\u89c4\u5219\u540d\u79f0\u3001\u4e1a\u52a1\u57df\u3001\u9002\u7528\u573a\u666f\u3001\u6765\u6e90\u6587\u4ef6 |\n| `01_\u4e1a\u52a1\u6d41\u7a0b/\u4e1a\u52a1\u5bf9\u8c61\u5b57\u5178.md` | \u589e\u52a0\u65b0\u589e\u6216\u53d8\u66f4\u7684\u4e1a\u52a1\u5bf9\u8c61\u3001\u5b57\u6bb5\u3001\u72b6\u6001 |\n| `04_Agent\u68c0\u7d22/\u5173\u952e\u8bcd\u7d22\u5f15.md` | \u589e\u52a0\u5173\u952e\u8bcd\u5230\u65b0\u6587\u4ef6\u7684\u6620\u5c04 |\n| `04_Agent\u68c0\u7d22/\u540c\u4e49\u8bcd\u8868.md` | \u589e\u52a0\u53e3\u8bed\u95ee\u6cd5\u4e0e\u6807\u51c6\u672f\u8bed\u6620\u5c04 |\n| `04_Agent\u68c0\u7d22/\u6765\u6e90\u6587\u4ef6\u7d22\u5f15.md` | \u767b\u8bb0\u65b0\u589e\u77e5\u8bc6\u6761\u76ee\u6765\u6e90 |\n\n### \u6b65\u9aa4 3\uff1a\u6267\u884c\u6587\u4ef6\u7ea7\u68c0\u67e5\n\n\u68c0\u67e5\u9879\uff1a\n\n- \u6587\u4ef6\u662f\u5426\u4f4d\u4e8e `05_\u9700\u6c42\u6587\u6863/`\u3002\n- \u6587\u4ef6\u540d\u662f\u5426\u5305\u542b\u4e1a\u52a1\u57df\u3001\u89c4\u5219/\u9700\u6c42\u540d\u79f0\u3001\u65e5\u671f\u3002\n- Frontmatter \u662f\u5426\u5b8c\u6574\u3002\n- \u662f\u5426\u5305\u542b `\u4e1a\u52a1\u89c4\u5219`\u3001`\u4e1a\u52a1\u6d41\u7a0b`\u3001`\u9a8c\u6536\u53e3\u5f84`\u3001`Agent \u68c0\u7d22\u5b57\u6bb5`\u3002\n- \u7d22\u5f15\u6587\u4ef6\u662f\u5426\u5df2\u540c\u6b65\u66f4\u65b0\u3002\n\n### \u6b65\u9aa4 4\uff1a\u6267\u884c\u5173\u952e\u8bcd\u68c0\u7d22\u9a8c\u8bc1\n\n\u7528\u65b0\u589e\u6587\u6863\u4e2d\u7684\u5173\u952e\u8bcd\u3001\u522b\u540d\u3001\u53e3\u8bed\u95ee\u6cd5\u8fdb\u884c\u68c0\u7d22\u3002\n\n\u9a8c\u8bc1\u6807\u51c6\uff1a\n\n- \u81f3\u5c11 1 \u4e2a\u6b63\u5f0f\u5173\u952e\u8bcd\u80fd\u547d\u4e2d\u65b0\u6587\u6863\u3002\n- \u81f3\u5c11 1 \u4e2a\u53e3\u8bed\u95ee\u6cd5\u80fd\u901a\u8fc7 `\u540c\u4e49\u8bcd\u8868.md` \u6216 `\u5173\u952e\u8bcd\u7d22\u5f15.md` \u5b9a\u4f4d\u5230\u65b0\u6587\u6863\u3002\n- \u68c0\u7d22\u7ed3\u679c\u80fd\u5b9a\u4f4d\u5230\u5177\u4f53\u6587\u4ef6\uff0c\u800c\u4e0d\u662f\u53ea\u547d\u4e2d\u6a21\u677f\u3002\n\n### \u6b65\u9aa4 5\uff1a\u6267\u884c Agent \u95ee\u7b54\u9a8c\u8bc1\n\n\u6bcf\u6b21\u65b0\u589e\u6587\u6863\u81f3\u5c11\u51c6\u5907 3 \u7c7b\u95ee\u9898\uff1a\n\n| \u7c7b\u578b | \u793a\u4f8b | \u901a\u8fc7\u6807\u51c6 |\n|---|---|---|\n| \u89c4\u5219\u7c7b | `\u4f9b\u5e94\u5546\u51c6\u5165\u6709\u4ec0\u4e48\u6761\u4ef6\uff1f` | \u80fd\u56de\u7b54\u89c4\u5219\u6761\u4ef6\u3001\u89e6\u53d1\u6761\u4ef6\u3001\u5904\u7406\u7ed3\u679c |\n| \u6d41\u7a0b\u7c7b | `\u4f9b\u5e94\u5546\u51c6\u5165\u6d41\u7a0b\u600e\u4e48\u8d70\uff1f` | \u80fd\u6309\u6b65\u9aa4\u56de\u7b54\u4e3b\u6d41\u7a0b\u548c\u5206\u652f\u6d41\u7a0b |\n| \u5f02\u5e38\u7c7b | `\u4f9b\u5e94\u5546\u8d44\u6599\u4e0d\u5b8c\u6574\u600e\u4e48\u529e\uff1f` | \u80fd\u56de\u7b54\u5f02\u5e38\u5904\u7406\u65b9\u5f0f\u548c\u8d1f\u8d23\u4eba |\n\nAgent \u56de\u7b54\u5fc5\u987b\u6ee1\u8db3\uff1a\n\n1. \u7ed3\u8bba\u6765\u81ea\u65b0\u589e\u6587\u6863\u6216\u5df2\u7d22\u5f15\u6587\u4ef6\u3002\n2. \u56de\u7b54\u672b\u5c3e\u6ce8\u660e\u6765\u6e90\u6587\u4ef6\u540d\u3002\n3. \u5982\u679c\u6587\u6863\u672a\u8bb0\u5f55\uff0c\u660e\u786e\u56de\u7b54\u201c\u77e5\u8bc6\u5e93\u672a\u660e\u786e\u8bb0\u5f55\u201d\u3002\n4. \u4e0d\u5f97\u51ed\u7ecf\u9a8c\u8865\u5145\u6ca1\u6709\u6765\u6e90\u7684\u4e1a\u52a1\u89c4\u5219\u3002\n\n### \u6b65\u9aa4 6\uff1a\u8bb0\u5f55\u9a8c\u8bc1\u7ed3\u679c\n\n\u5728\u65b0\u589e\u4e1a\u52a1\u6587\u6863\u672b\u5c3e\u7684 `\u53d8\u66f4\u8bb0\u5f55` \u6216\u5355\u72ec\u9a8c\u8bc1\u8bb0\u5f55\u4e2d\u8bb0\u5f55\uff1a\n\n| \u65e5\u671f | \u9a8c\u8bc1\u95ee\u9898 | \u662f\u5426\u547d\u4e2d | \u6765\u6e90\u6587\u4ef6 | \u7ed3\u679c | \u5f85\u8865\u5145 |\n|---|---|---|---|---|---|\n| | | \u662f/\u5426 | | \u901a\u8fc7/\u5931\u8d25 | |\n\n## 4. \u9a8c\u8bc1\u7528\u4f8b\u6a21\u677f\n\n\u590d\u5236\u4ee5\u4e0b\u5185\u5bb9\u5230\u65b0\u589e\u4e1a\u52a1\u6587\u6863\u7684 `Agent \u68c0\u7d22\u5b57\u6bb5` \u6216\u9a8c\u8bc1\u8bb0\u5f55\u4e2d\uff1a\n\n```markdown\n## Agent \u68c0\u7d22\u9a8c\u8bc1\n\n| \u7f16\u53f7 | \u7528\u6237\u95ee\u9898 | \u671f\u671b\u547d\u4e2d\u6587\u4ef6 | \u671f\u671b\u7b54\u6848\u8981\u70b9 | \u5b9e\u9645\u7ed3\u679c | \u72b6\u6001 |\n|---|---|---|---|---|---|\n| Q1 | | | | | \u672a\u9a8c\u8bc1 |\n| Q2 | | | | | \u672a\u9a8c\u8bc1 |\n| Q3 | | | | | \u672a\u9a8c\u8bc1 |\n```\n\n## 5. \u901a\u8fc7/\u5931\u8d25\u5224\u5b9a\n\n### \u901a\u8fc7\n\n- \u65b0\u6587\u6863\u80fd\u88ab\u5173\u952e\u8bcd\u68c0\u7d22\u5230\u3002\n- Agent \u80fd\u5f15\u7528\u65b0\u6587\u6863\u56de\u7b54\u81f3\u5c11 3 \u4e2a\u9a8c\u8bc1\u95ee\u9898\u3002\n- \u56de\u7b54\u6ca1\u6709\u660e\u663e\u5e7b\u89c9\u3002\n- \u6765\u6e90\u6587\u4ef6\u5f15\u7528\u6b63\u786e\u3002\n\n### \u5931\u8d25\n\n\u51fa\u73b0\u4efb\u4e00\u60c5\u51b5\u89c6\u4e3a\u5931\u8d25\uff1a\n\n- \u65b0\u6587\u6863\u53ea\u4fdd\u5b58\u4e86\uff0c\u4f46\u6ca1\u6709\u66f4\u65b0\u5173\u952e\u8bcd\u7d22\u5f15\u6216\u540c\u4e49\u8bcd\u8868\u3002\n- Agent \u547d\u4e2d\u4e86\u65e7\u6587\u4ef6\uff0c\u672a\u547d\u4e2d\u65b0\u6587\u6863\u3002\n- Agent \u56de\u7b54\u6ca1\u6709\u5f15\u7528\u6765\u6e90\u3002\n- Agent \u7f16\u9020\u4e86\u6587\u6863\u4e2d\u4e0d\u5b58\u5728\u7684\u4e1a\u52a1\u89c4\u5219\u3002\n- \u95ee\u9898\u80fd\u68c0\u7d22\u5230\u6a21\u677f\uff0c\u4f46\u4e0d\u80fd\u68c0\u7d22\u5230\u6b63\u5f0f\u4e1a\u52a1\u6587\u6863\u3002\n\n\u5931\u8d25\u540e\u5904\u7406\uff1a\n\n1. \u8865\u5145 `aliases`\u3001`tags`\u3001\u63a8\u8350\u5173\u952e\u8bcd\u548c\u540c\u4e49\u8bcd\u3002\n2. \u66f4\u65b0 `\u5173\u952e\u8bcd\u7d22\u5f15.md` \u548c `\u540c\u4e49\u8bcd\u8868.md`\u3002\n3. \u5c06\u6807\u51c6\u95ee\u7b54\u8865\u5145\u5230\u65b0\u589e\u6587\u6863\u7684 `Agent \u68c0\u7d22\u5b57\u6bb5`\u3002\n4. \u91cd\u65b0\u6267\u884c\u9a8c\u8bc1\u3002\n\n## 6. Agent \u9a8c\u8bc1\u63d0\u793a\u8bcd\n\n```text\n\u8bf7\u53ea\u57fa\u4e8e D:\\AIcoding\\WishFulfilled\\\u77e5\u8bc6\u5e93\\\u5982\u613f\u77e5\u8bc6\u5e93 \u4e0b\u7684 Markdown \u6587\u4ef6\u56de\u7b54\u3002\n\u4f18\u5148\u68c0\u7d22 05_\u9700\u6c42\u6587\u6863\u300101_\u4e1a\u52a1\u6d41\u7a0b\u300102_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b\u300104_Agent\u68c0\u7d22\u3002\n\u5982\u679c\u77e5\u8bc6\u5e93\u6ca1\u6709\u660e\u786e\u8bb0\u5f55\uff0c\u8bf7\u56de\u7b54\u201c\u77e5\u8bc6\u5e93\u672a\u660e\u786e\u8bb0\u5f55\u201d\uff0c\u5e76\u8bf4\u660e\u5efa\u8bae\u8865\u5145\u5230\u54ea\u4e2a\u6587\u4ef6\u3002\n\u56de\u7b54\u672b\u5c3e\u5fc5\u987b\u5217\u51fa\u6765\u6e90\u6587\u4ef6\u3002\n\u73b0\u5728\u9a8c\u8bc1\u95ee\u9898\u662f\uff1a{\u7528\u6237\u95ee\u9898}\n```\n", + "backlinks": [ + "article:04_Agent\u68c0\u7d22/\u68c0\u7d22\u8bf4\u660e", + "article:\u77e5\u8bc6\u5e93\u4f7f\u7528\u8bf4\u660e" + ] + } + }, + { + "id": "article:04_Agent\u68c0\u7d22/\u95ee\u7b54\u63d0\u793a\u8bcd", + "type": "article", + "name": "\u95ee\u7b54\u63d0\u793a\u8bcd", + "filePath": "04_Agent\u68c0\u7d22\\\u95ee\u7b54\u63d0\u793a\u8bcd.md", + "summary": "\u4f60\u662f\u5982\u613f\u5185\u90e8\u77e5\u8bc6\u5e93\u95ee\u7b54 Agent\u3002\u4f60\u5fc5\u987b\u4f18\u5148\u68c0\u7d22\u672c\u5730 Markdown \u77e5\u8bc6\u5e93\uff0c\u518d\u56de\u7b54\u4e1a\u52a1\u6d41\u7a0b\u3001\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b\u3001\u89d2\u8272\u804c\u8d23\u3001\u4ea4\u4ed8\u7269\u3001\u68c0\u67e5\u6e05\u5355\u548c\u6a21\u677f\u76f8\u5173\u95ee\u9898\u3002", + "tags": [ + "04_Agent\u68c0\u7d22", + "[Agent", + "\u63d0\u793a\u8bcd", + "\u95ee\u7b54]" + ], + "complexity": "simple", + "knowledgeMeta": { + "wikilinks": [], + "content": "---\ntype: agent_prompt\ntags: [Agent, \u63d0\u793a\u8bcd, \u95ee\u7b54]\naliases: [Agent\u63d0\u793a\u8bcd, \u77e5\u8bc6\u5e93\u95ee\u7b54Prompt]\nsource: manual\nstatus: active\nowner: \u5185\u90e8\u6280\u672f\u56e2\u961f\nupdated: 2026-05\n---\n\n# \u95ee\u7b54\u63d0\u793a\u8bcd\n\n## \u7cfb\u7edf\u63d0\u793a\u8bcd\n\n\u4f60\u662f\u5982\u613f\u5185\u90e8\u77e5\u8bc6\u5e93\u95ee\u7b54 Agent\u3002\u4f60\u5fc5\u987b\u4f18\u5148\u68c0\u7d22\u672c\u5730 Markdown \u77e5\u8bc6\u5e93\uff0c\u518d\u56de\u7b54\u4e1a\u52a1\u6d41\u7a0b\u3001\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b\u3001\u89d2\u8272\u804c\u8d23\u3001\u4ea4\u4ed8\u7269\u3001\u68c0\u67e5\u6e05\u5355\u548c\u6a21\u677f\u76f8\u5173\u95ee\u9898\u3002\n\n\u56de\u7b54\u8981\u6c42\uff1a\n\n1. \u4e0d\u8981\u51ed\u7a7a\u7f16\u9020\u77e5\u8bc6\u5e93\u672a\u8bb0\u5f55\u7684\u4fe1\u606f\u3002\n2. \u4f18\u5148\u68c0\u7d22 `02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b` \u548c `01_\u4e1a\u52a1\u6d41\u7a0b`\u3002\n3. \u6d41\u7a0b\u7c7b\u95ee\u9898\u6309\u9636\u6bb5\u3001\u8d1f\u8d23\u4eba\u3001\u8f93\u5165\u3001\u5173\u952e\u52a8\u4f5c\u3001\u8f93\u51fa\u3001\u68c0\u67e5\u70b9\u56de\u7b54\u3002\n4. \u89d2\u8272\u7c7b\u95ee\u9898\u4f18\u5148\u68c0\u7d22 `\u89d2\u8272\u804c\u8d23\u77e9\u9635.md`\u3002\n5. \u4ea4\u4ed8\u7269\u7c7b\u95ee\u9898\u4f18\u5148\u68c0\u7d22 `\u9636\u6bb5\u4ea4\u4ed8\u7269\u6e05\u5355.md`\u3002\n6. \u95e8\u7981\u548c\u68c0\u67e5\u7c7b\u95ee\u9898\u4f18\u5148\u68c0\u7d22 `\u9879\u76ee\u68c0\u67e5\u6e05\u5355.md`\u3002\n7. \u6bcf\u6b21\u56de\u7b54\u672b\u5c3e\u5fc5\u987b\u6ce8\u660e\u6765\u6e90\u6587\u4ef6\u3002\n8. \u5982\u679c\u6ca1\u6709\u660e\u786e\u7b54\u6848\uff0c\u56de\u7b54\u201c\u77e5\u8bc6\u5e93\u672a\u660e\u786e\u8bb0\u5f55\u201d\uff0c\u5e76\u8bf4\u660e\u5efa\u8bae\u8865\u5145\u5230\u54ea\u4e2a\u6587\u4ef6\u3002\n\n## \u7528\u6237\u95ee\u9898\u6539\u5199\u89c4\u5219\n\n- \u201c\u63d0\u9700\u6c42\u201d\u53ef\u6620\u5c04\u4e3a\u201c\u9879\u76ee\u5165\u53e3\u5206\u7ea7\u201d\u6216\u201c\u4e1a\u52a1\u9700\u6c42\u5b8c\u6574\u5f62\u6210\u201d\u3002\n- \u201c\u5f00\u53d1\u524d\u6d4b\u8bd5\u201d\u53ef\u6620\u5c04\u4e3a\u201c\u9636\u6bb52.5 \u6d4b\u8bd5\u63d0\u524d\u8865\u6f0f\u201d\u3002\n- \u201c\u539f\u578b\u201d\u53ef\u6620\u5c04\u4e3a\u201cVibe Coding \u9875\u9762\u201d\u6216\u201c\u9ad8\u4fdd\u771f\u6a21\u578b\u201d\uff0c\u9700\u7ed3\u5408\u4e0a\u4e0b\u6587\u533a\u5206\u3002\n- \u201c\u4e0a\u7ebf\u524d\u68c0\u67e5\u201d\u53ef\u6620\u5c04\u4e3a\u201cGate 4 \u4e0a\u7ebf\u9a8c\u6536\u201d\u548c\u201c\u9879\u76ee\u68c0\u67e5\u6e05\u5355\u201d\u3002\n- \u201c\u8c01\u8d1f\u8d23\u201d\u4f18\u5148\u67e5\u89d2\u8272\u804c\u8d23\u77e9\u9635\u3002\n\n## \u6807\u51c6\u56de\u7b54\u6a21\u677f\n\n\u7ed3\u8bba\uff1a\n\n\u8981\u70b9\uff1a\n\n1. \u9636\u6bb5/\u89d2\u8272\uff1a\n2. \u8f93\u5165\uff1a\n3. \u5173\u952e\u52a8\u4f5c\uff1a\n4. \u8f93\u51fa\uff1a\n5. \u68c0\u67e5\u70b9\uff1a\n\n\u6765\u6e90\uff1a\n", + "backlinks": [] + } + }, + { + "id": "article:05_\u9700\u6c42\u6587\u6863/20260517_USER\u8bc4\u4ef7\u4e1a\u52a1\u95ed\u73af_\u7b2c\u4e09\u6b65_\u6570\u636e\u6d41\u4e0e\u4e2d\u95f4\u5bf9\u8c61\u8bbe\u8ba1_v3", + "type": "article", + "name": "USER \u8bc4\u4ef7\u4e1a\u52a1\u95ed\u73af \u2014 \u7b2c\u4e09\u6b65\uff1a\u6570\u636e\u6d41\u4e0e\u4e2d\u95f4\u5bf9\u8c61\u8bbe\u8ba1 v3", + "filePath": "05_\u9700\u6c42\u6587\u6863\\20260517_USER\u8bc4\u4ef7\u4e1a\u52a1\u95ed\u73af_\u7b2c\u4e09\u6b65_\u6570\u636e\u6d41\u4e0e\u4e2d\u95f4\u5bf9\u8c61\u8bbe\u8ba1_v3.md", + "summary": "- \u6587\u4ef6\u540d\u79f0\uff1a`20260517_USER\u8bc4\u4ef7\u4e1a\u52a1\u95ed\u73af_\u7b2c\u4e09\u6b65_\u6570\u636e\u6d41\u4e0e\u4e2d\u95f4\u5bf9\u8c61\u8bbe\u8ba1_v3.md` - \u9879\u76ee\u8def\u5f84\uff1a`C:\\XCODE\\USER` - \u5f53\u524d\u7248\u672c\uff1a`v3` - \u6700\u8fd1\u66f4\u65b0\uff1a`2026-05-17` - \u4e0a\u6e38\u6587\u6863\uff1a - [\u5de5\u4f5c\u57fa\u7ebf v1.2](20260517_USER\u8bc4\u4ef7\u4e1a\u52a1\u95ed\u73af\u4e3b\u6d41\u7a0b\u4e0e\u540e\u7eed\u5de5\u4f5c\u57fa\u7ebf_v1.2.md) \u2014 \u4e1a\u52a1\u89c4\u5219\u4e0e\u989d\u5ea6\u53e3\u5f84 - [\u5171\u7528\u80fd\u529b\u56fe\u4e0e\u6e20\u9053\u4e13\u5c5e\u6d41\u7a0b v2....", + "tags": [ + "05_\u9700\u6c42\u6587\u6863" + ], + "complexity": "simple", + "knowledgeMeta": { + "wikilinks": [], + "content": "# USER \u8bc4\u4ef7\u4e1a\u52a1\u95ed\u73af \u2014 \u7b2c\u4e09\u6b65\uff1a\u6570\u636e\u6d41\u4e0e\u4e2d\u95f4\u5bf9\u8c61\u8bbe\u8ba1 v3\n\n## \u6587\u4ef6\u4fe1\u606f\n\n- \u6587\u4ef6\u540d\u79f0\uff1a`20260517_USER\u8bc4\u4ef7\u4e1a\u52a1\u95ed\u73af_\u7b2c\u4e09\u6b65_\u6570\u636e\u6d41\u4e0e\u4e2d\u95f4\u5bf9\u8c61\u8bbe\u8ba1_v3.md`\n- \u9879\u76ee\u8def\u5f84\uff1a`C:\\XCODE\\USER`\n- \u5f53\u524d\u7248\u672c\uff1a`v3`\n- \u6700\u8fd1\u66f4\u65b0\uff1a`2026-05-17`\n- \u4e0a\u6e38\u6587\u6863\uff1a\n - [\u5de5\u4f5c\u57fa\u7ebf v1.2](20260517_USER\u8bc4\u4ef7\u4e1a\u52a1\u95ed\u73af\u4e3b\u6d41\u7a0b\u4e0e\u540e\u7eed\u5de5\u4f5c\u57fa\u7ebf_v1.2.md) \u2014 \u4e1a\u52a1\u89c4\u5219\u4e0e\u989d\u5ea6\u53e3\u5f84\n - [\u5171\u7528\u80fd\u529b\u56fe\u4e0e\u6e20\u9053\u4e13\u5c5e\u6d41\u7a0b v2.2](20260517_USER\u8bc4\u4ef7\u4e1a\u52a1\u95ed\u73af_\u5171\u7528\u80fd\u529b\u56fe\u4e0e\u6e20\u9053\u4e13\u5c5e\u6d41\u7a0b_v2.2.md) \u2014 \u6bcf\u4e2a\u8282\u70b9\u7684 \u67e5/\u5199/\u72b6\u6001/\u63d0\u9192/\u62e6\u622a\n- \u524d\u7f6e\u7248\u672c\uff1a\n - `\u6570\u636e\u6d41\u4e0e\u4e2d\u95f4\u5bf9\u8c61\u9700\u6c42_v1`\uff08Codex\uff0c\u516d\u5c42\u67b6\u6784\u9aa8\u67b6\uff09\n - `\u6570\u636e\u6d41\u4e0e\u4e2d\u95f4\u5bf9\u8c61\u8bbe\u8ba1_v1.1`\uff08Codex\uff0c\u5b57\u6bb5\u5b57\u5178\u6700\u5168\u7248\uff09\n - `\u7b2c\u4e09\u6b65_\u6570\u636e\u6d41\u4e0e\u4e2d\u95f4\u8868\u8bbe\u8ba1_v1`\uff08\u5b57\u6bb5\u7ea7\u5c55\u5f00 + \u6d41\u8f6c\u65f6\u5e8f\uff09\n - `\u7b2c\u4e09\u6b65_\u6570\u636e\u6d41\u4e0e\u4e2d\u95f4\u8868\u8bbe\u8ba1_v2`\uff08\u5438\u6536 Codex \u4f18\u70b9\u7684\u5408\u5e76\u7248\uff09\n- \u5408\u5e76\u7b56\u7565\uff1a\u4ee5 Codex v1.1 \u4e3a\u4e3b\u9aa8\u67b6\uff08\u4fdd\u7559\u5176\u5b8c\u6574\u5b57\u6bb5\u5b57\u5178\u548c\u514d\u8bc4\u5bf9\u8c61\uff09\uff0c\u8865\u5165 v2 \u7684\u6d41\u8f6c\u65f6\u5e8f\u8868\u3001\u5199\u5165\u987a\u5e8f\u56fe\u548c\u5feb\u7167\u7b56\u7565\u3002\n- \u6587\u4ef6\u76ee\u7684\uff1a\u4f5c\u4e3a\u7b2c\u4e09\u6b65\u6700\u7ec8\u4e3b\u7a3f\uff0c\u540e\u7eed\u6570\u636e\u5e93\u7269\u7406\u8bbe\u8ba1\u3001\u63a5\u53e3\u8bbe\u8ba1\u548c\u9875\u9762\u70b9\u51fb\u8bfb\u5199\u8bbe\u8ba1\u5747\u4ee5\u6b64\u4e3a\u51c6\u3002\n\n---\n\n## 1. \u7b2c\u4e09\u6b65\u7684\u76ee\u6807\n\n\u7b2c\u4e09\u6b65\u4e0d\u518d\u56de\u7b54\"\u6d41\u7a0b\u600e\u4e48\u8d70\"\uff0c\u800c\u662f\u56de\u7b54\uff1a\n\n1. \u73b0\u6709\u7cfb\u7edf\u91cc\u5df2\u7ecf\u6709\u54ea\u4e9b\u6570\u636e\u53ef\u4ee5\u590d\u7528\u3002\n2. \u4e3a\u4ec0\u4e48\u4ec5\u9760\u73b0\u6709 `users / amazon_orders / review_plans / push_tasks / support_tickets / fraud_events` \u4e0d\u591f\u3002\n3. \u5fc5\u987b\u65b0\u589e\u54ea\u4e9b\u4e2d\u95f4\u5bf9\u8c61\u3002\n4. \u54ea\u4e9b\u662f\u6b63\u5f0f\u4e8b\u52a1\u8868\uff0c\u54ea\u4e9b\u53ea\u662f\u5feb\u7167\uff0c\u54ea\u4e9b\u53ef\u4ee5\u5148\u505a\u6210\u89c6\u56fe\u3002\n5. \u4ece\u9700\u6c42\u5f62\u6210\u5230\u7ed3\u679c\u56de\u6d41\uff0c\u6570\u636e\u600e\u6837\u4e00\u5c42\u4e00\u5c42\u5f80\u4e0b\u8d70\u3002\n\n---\n\n## 2. \u672c\u6b65\u5148\u7ed9\u51fa\u7684\u7ed3\u8bba\n\n### 2.1 \u4e0d\u80fd\u518d\u53ea\u56f4\u7ed5\u5355\u4e00\u8d26\u53f7\u5efa\u6a21\n\n\u540e\u7eed\u6240\u6709\u5173\u952e\u5224\u65ad\u90fd\u5e94\u56f4\u7ed5 **\u771f\u5b9e\u4eba**\uff0c\u800c\u4e0d\u662f\u53ea\u770b JOYHUB ID / \u90ae\u7bb1 / \u7535\u8bdd / Amazon \u8d26\u53f7 / \u5355\u6b21\u8ba2\u5355\u3002JOYHUB \u7528\u6237\u53ea\u662f\u8eab\u4efd\u7ebf\u7d22\u4e4b\u4e00\uff0c\u771f\u5b9e\u4eba\u624d\u662f\u989d\u5ea6\u3001\u5386\u53f2\u3001\u98ce\u9669\u3001\u8de8\u6e20\u9053\u53bb\u91cd\u548c\u5ba2\u670d\u4e0a\u4e0b\u6587\u7684\u4e3b\u5bf9\u8c61\u3002\n\n### 2.2 \u73b0\u6709\u8868\u80fd\u627f\u8f7d\u4e1a\u52a1\u8bb0\u5f55\uff0c\u4f46\u627f\u8f7d\u4e0d\u4e86\u8de8\u6d41\u7a0b\u5224\u65ad\n\n\u65e2\u6709\u8868\u66f4\u63a5\u8fd1\"\u67d0\u4e00\u6a21\u5757\u81ea\u5df1\u7684\u8d26\"\uff0c\u4f46\u524d\u4e24\u6b65\u5df2\u786e\u8ba4\u7684\u65b0\u9700\u6c42\u9700\u8981\u989d\u5916\u7684\u4e2d\u95f4\u5c42\uff1a\u771f\u5b9e\u4eba\u8de8\u8d26\u53f7\u5f52\u5e76\u3001\u6bcf\u6b21\u4e92\u52a8\u91cd\u5224\u3001\u4eba\u7fa4\u5165\u9009/\u6392\u9664\u89e3\u91ca\u3001\u989d\u5ea6\u9884\u5360\u4e0e\u8de8\u6e20\u9053\u53bb\u91cd\u3001\u5ba2\u670d\u4e0a\u4e0b\u6587\u3001\u8bc4\u4ef7\u63d0\u4ea4\u4e0e\u5c55\u793a\u62c6\u5206\u3001\u9000\u6b3e\u6bd4\u5bf9\u3002\n\n### 2.3 \u7b2c\u4e09\u6b65\u6700\u91cd\u8981\u7684\u662f\u628a\u5bf9\u8c61\u5206\u5c42\n\n\u672c\u6587\u4ef6\u628a\u6570\u636e\u5bf9\u8c61\u5206\u4e3a\u516d\u5c42\uff1a\n\n```\n\u6e90\u6570\u636e\u5c42 \u2192 \u4e3b\u5b9e\u4f53\u5c42 \u2192 \u6865\u63a5\u5c42 \u2192 \u4e8b\u4ef6\u5c42 \u2192 \u5feb\u7167\u4e0e\u51b3\u7b56\u5c42 \u2192 \u7ed3\u679c\u56de\u6d41\u5c42\n```\n\n---\n\n## 3. \u6570\u636e\u8bbe\u8ba1\u539f\u5219\n\n| \u539f\u5219 | \u8bf4\u660e |\n| --- | --- |\n| \u5148\u8bc6\u522b\u771f\u5b9e\u4eba\uff0c\u518d\u505a\u989d\u5ea6\u4e0e\u98ce\u9669 | \u5426\u5219 4/4/12 \u89c4\u5219\u90fd\u4f1a\u88ab\u591a\u8d26\u53f7\u7ed5\u5f00 |\n| \u4e8b\u4ef6\u4e0e\u5feb\u7167\u5206\u79bb | \u4e8b\u4ef6\u662f\u539f\u59cb\u4e8b\u5b9e\uff0c\u5feb\u7167\u662f\u67d0\u4e2a\u65f6\u70b9\u7684\u5224\u65ad\u7ed3\u679c |\n| \u5f53\u524d\u6001\u4e0e\u5386\u53f2\u6001\u5206\u79bb | \u5f53\u524d\u89c6\u56fe\u53ef\u91cd\u7b97\uff0c\u5386\u53f2\u51b3\u7b56\u5fc5\u987b\u7559\u75d5 |\n| \u8ba1\u5212\u3001\u6e20\u9053\u3001\u5ba2\u670d\u3001\u98ce\u9669\u72b6\u6001\u5206\u79bb | \u4e0d\u80fd\u538b\u6210\u4e00\u4e2a\u5b57\u6bb5 |\n| \u7528\u6237\u63d0\u4ea4\u4e0e\u5e73\u53f0\u5c55\u793a\u5206\u79bb | \u771f\u5b9e\u63d0\u4ea4\u8ba1\u989d\u5ea6\uff0cAmazon \u5c55\u793a\u8ba1\u8ba1\u5212\u5b8c\u6210 |\n| \u80fd\u89e3\u91ca\"\u4e3a\u4ec0\u4e48\" | \u5165\u9009\u3001\u6392\u9664\u3001\u62e6\u622a\u3001\u8f6c\u4eba\u5de5\u90fd\u8981\u80fd\u8ffd\u6eaf |\n| \u5148\u590d\u7528\u73b0\u6709\u5bf9\u8c61\uff0c\u518d\u8865\u6700\u5c0f\u4e2d\u95f4\u5c42 | \u4e0d\u4e3a\u4e86\u5efa\u6a21\u6f02\u4eae\u91cd\u9020\u5168\u90e8\u65e7\u8868 |\n| \u5bf9\u654f\u611f\u6570\u636e\u5206\u5c42\u5904\u7406 | \u539f\u503c\u3001\u6807\u51c6\u5316\u503c\u3001\u54c8\u5e0c/\u6307\u7eb9\u3001\u8131\u654f\u5c55\u793a\u503c\u5e94\u533a\u5206 |\n\n---\n\n# \u7b2c\u4e00\u90e8\u5206\uff1a\u73b0\u6709\u6570\u636e\u6e90\u5206\u6790\n\n## 4. \u73b0\u6709\u6570\u636e\u6e90\u76d8\u70b9\n\n| \u6570\u636e\u6e90 | \u5f53\u524d\u53ef\u7528\u5185\u5bb9 | \u4e3b\u8981\u7f3a\u53e3 |\n| --- | --- | --- |\n| \u73b0\u6709 ERP \u7528\u6237\u7ba1\u7406 | \u7528\u6237 ID\u3001\u7528\u6237\u540d\u3001\u6ce8\u518c\u65f6\u95f4\u3001\u6700\u8fd1\u6d3b\u8dc3\u3001\u56fd\u5bb6\u3001\u6027\u522b\u3001\u90ae\u7bb1\u3001\u7ed1\u5b9a\u4ea7\u54c1\u6570\u3001\u6807\u7b7e | \u4ecd\u662f\u8d26\u53f7\u89c6\u89d2\uff0c\u4e0d\u662f\u771f\u5b9e\u4eba\u89c6\u89d2 |\n| APP / \u7528\u6237\u6570\u636e\u5e93 | JOYHUB ID\u3001\u90ae\u7bb1\u3001\u8bbe\u5907\u53f7\u3001\u8bbe\u5907\u578b\u53f7/\u7c7b\u578b\u3001\u7cfb\u7edf\u7248\u672c\u3001APP\u7248\u672c\u3001\u7ed1\u5b9a\u73a9\u5177\u3001\u6d3b\u8dc3\u4e0e\u70b9\u51fb\u884c\u4e3a | \u9700\u8981\u8bbe\u5907\u53d8\u66f4\u8f68\u8ff9\u548c\u4e0e\u8ba2\u5355/\u5ba2\u670d\u8054\u52a8 |\n| Amazon \u8ba2\u5355 | \u8ba2\u5355\u53f7\u3001ASIN\u3001\u7ad9\u70b9\u3001\u8d2d\u4e70\u65f6\u95f4\u3001\u8ba2\u5355\u72b6\u6001\u3001Profile ID\u3001\u6536\u4ef6\u4eba\u59d3\u540d\u3001\u6536\u4ef6\u5730\u5740\u7b49 | \u9700\u8981\u6807\u51c6\u5316\u59d3\u540d/\u5730\u5740\u548c\u6536\u4ef6\u4eba\u6307\u7eb9 |\n| Amazon \u8bc4\u4ef7/Listing | ASIN\u3001\u8bc4\u5206\u3001\u8bc4\u4ef7\u6570\u3001\u5dee\u8bc4\u6570\u3001\u8bc4\u4ef7\u7f3a\u53e3\u3001\u5c55\u793a\u7ed3\u679c | \u7528\u6237\u771f\u5b9e\u63d0\u4ea4\u4e0e\u5e73\u53f0\u5c55\u793a\u8981\u62c6\u6210\u4e24\u6761\u4e8b\u5b9e |\n| \u63a8\u9001\u7cfb\u7edf | Push \u8ba1\u5212\u3001\u7d20\u6750\u3001\u4efb\u52a1\u3001\u6253\u5f00\u3001\u70b9\u51fb\u3001\u56de\u590d\u3001\u6295\u8bc9\u3001\u9000\u8ba2 | IM/EDM/APP \u8bed\u4e49\u4e0d\u540c\uff0c\u4e0d\u80fd\u53ea\u7528\u4e00\u5957\u7c97\u7cd9 push \u7ed3\u679c |\n| \u5ba2\u670d/TEL | \u5de5\u5355\u3001\u901a\u8bdd\u3001\u552e\u540e\u3001\u7b54\u5e94\u914d\u5408\u3001\u95ee\u9898\u5904\u7406 | \u9700\u8981\u548c\u4e0a\u4e0b\u6587\u5361\u3001\u98ce\u9669\u590d\u68c0\u3001\u8ddf\u8fdb\u72b6\u6001\u8054\u52a8 |\n| \u9ed1\u540d\u5355/\u8bc8\u9a97\u8d44\u6599 | \u9ed1\u540d\u5355\u3001\u8bc8\u9a97\u4e8b\u4ef6\u3001\u53cc\u91cd\u9000\u6b3e\u3001\u5f3a\u5f31\u5173\u8054 | \u9700\u8981\u628a\u98ce\u9669\u4fe1\u53f7\u4e0e\u786e\u8ba4\u6848\u4ef6\u62c6\u5f00 |\n| OA \u8fd4\u6b3e/Amazon \u9000\u6b3e | \u5185\u90e8\u8fd4\u6b3e\u4e0e Amazon \u9000\u6b3e | \u7f3a\u7edf\u4e00\u6bd4\u5bf9\u5bf9\u8c61 |\n| JOYCOLLAB | KOC/KOL\u3001\u5185\u5bb9\u3001Code\u3001\u70b9\u51fb\u3001\u8ba2\u5355\u3001\u8f6c\u5316\u3001\u4f63\u91d1 | \u9700\u8981\u548c USER \u8ba1\u5212/ASIN \u7ed3\u679c\u6253\u901a |\n\n### 4.1 Amazon \u8ba2\u5355\u5b57\u6bb5\u660e\u7ec6\uff08\u7ed3\u5408\u8868\u5934.xlsx\uff09\n\n| \u5b57\u6bb5 | \u4e3b\u8981\u7528\u9014 | \u6d89\u5bc6 |\n| --- | --- | --- |\n| \u8ba2\u5355\u53f7 | \u8ba2\u5355\u6838\u9a8c\u3001\u771f\u5b9e\u4eba\u5173\u8054\u3001\u9000\u6b3e\u6bd4\u5bf9 | \u662f |\n| \u8ba2\u5355\u72b6\u6001 | \u5224\u65ad\u662f\u5426\u64a4\u9500\u3001\u9000\u6b3e\u3001\u9000\u8d27\u3001\u6362\u8d27 | - |\n| \u4e70\u5bb6\u59d3\u540d / \u4e70\u5bb6\u90ae\u7bb1 | \u8eab\u4efd\u5173\u8054 | \u662f |\n| \u6536\u4ef6\u4eba / \u7535\u8bdd | \u771f\u5b9e\u4eba\u5f52\u5e76\u3001\u98ce\u9669\u5224\u65ad | \u662f |\n| \u5730\u5740 / \u57ce\u5e02 / \u5dde / \u90ae\u7f16 | \u6536\u4ef6\u4eba\u5f52\u5e76\u3001\u540c\u5740\u5f02\u540d\u8bc6\u522b | \u662f |\n| ASIN / MSKU / SKU / \u54c1\u540d / \u6807\u9898 | \u4ea7\u54c1\u5339\u914d\u3001\u8ba1\u5212\u5f52\u5c5e | - |\n| \u8ba2\u8d2d\u65e5\u671f / \u53d1\u8d27\u65f6\u95f4 / \u7ed3\u7b97\u65f6\u95f4 | \u65f6\u5e8f\u5224\u65ad | - |\n| \u6570\u91cf / \u5355\u4ef7 / \u8ba2\u5355\u603b\u91d1\u989d / \u9500\u552e\u989d | \u4ea4\u6613\u753b\u50cf | \u662f |\n| \u662f\u5426\u9000\u6b3e / \u9000\u6b3e\u603b\u91d1\u989d | \u53cc\u91cd\u9000\u6b3e\u68c0\u6d4b | \u662f |\n| \u8bf7\u6c42\u8bc4\u8bba\u72b6\u6001 | \u8bc4\u4ef7\u7f3a\u53e3\u5224\u65ad | - |\n| \u5e97\u94fa / \u56fd\u5bb6 / \u9500\u552e\u6e20\u9053 | \u7ad9\u70b9\u5339\u914d | - |\n| Order Item ID | \u8ba2\u5355\u884c\u7ea7\u5173\u8054 | - |\n\n### 4.2 \u8ba2\u5355\u4fa7\u5fc5\u987b\u8865\u7684\u6d3e\u751f\u5b57\u6bb5\n\n| \u5b57\u6bb5 | \u8bf4\u660e |\n| --- | --- |\n| `recipient_name_normalized` | \u6807\u51c6\u5316\u540e\u7684\u6536\u4ef6\u4eba\u59d3\u540d |\n| `recipient_address_normalized` | \u6807\u51c6\u5316\u540e\u7684\u5730\u5740 |\n| `recipient_fingerprint` | \u7531\u6807\u51c6\u5316\u59d3\u540d+\u5730\u5740\u751f\u6210\u7684\u7a33\u5b9a\u6307\u7eb9 |\n| `address_fingerprint` | \u4ec5\u5730\u5740\u6307\u7eb9\uff0c\u7528\u4e8e\u8bc6\u522b\u540c\u5740\u5f02\u540d |\n\n---\n\n## 5. \u5168\u5c40\u6570\u636e\u6d41\n\n```mermaid\nflowchart LR\n subgraph S[\"\u6e90\u6570\u636e\u5c42\"]\n S1[\"\u73b0\u6709ERP\u7528\u6237/\u6807\u7b7e/\u8eab\u4efd\"", + "backlinks": [] + } + }, + { + "id": "article:05_\u9700\u6c42\u6587\u6863/README", + "type": "article", + "name": "\u9700\u6c42\u6587\u6863", + "filePath": "05_\u9700\u6c42\u6587\u6863\\README.md", + "summary": "\u672c\u76ee\u5f55\u7528\u4e8e\u96c6\u4e2d\u5b58\u653e\u540e\u7eed\u6301\u7eed\u8865\u5145\u7684\u4e1a\u52a1\u9700\u6c42\u6587\u6863\u3001\u4e1a\u52a1\u89c4\u5219\u6587\u6863\u3001\u6d41\u7a0b\u8865\u5145\u6587\u6863\u548c\u9700\u6c42\u53d8\u66f4\u6587\u6863\u3002", + "tags": [ + "05_\u9700\u6c42\u6587\u6863", + "Agent]", + "[\u9700\u6c42\u6587\u6863", + "\u77e5\u8bc6\u5e93\u66f4\u65b0", + "\u9700\u6c42\u6536\u96c6" + ], + "complexity": "simple", + "knowledgeMeta": { + "wikilinks": [], + "content": "---\ntype: requirement_inbox\ntags: [\u9700\u6c42\u6587\u6863, \u9700\u6c42\u6536\u96c6, \u77e5\u8bc6\u5e93\u66f4\u65b0, Agent]\naliases: [\u9700\u6c42\u6587\u6863\u76ee\u5f55, \u9700\u6c42\u6536\u96c6\u76ee\u5f55, \u9700\u6c42\u5165\u53e3]\nsource: manual\nstatus: active\nowner: \u4ea7\u54c1\u7ecf\u7406 / \u4e1a\u52a1\u4e3b\u7ba1\nupdated: 2026-05\n---\n\n# \u9700\u6c42\u6587\u6863\n\n\u672c\u76ee\u5f55\u7528\u4e8e\u96c6\u4e2d\u5b58\u653e\u540e\u7eed\u6301\u7eed\u8865\u5145\u7684\u4e1a\u52a1\u9700\u6c42\u6587\u6863\u3001\u4e1a\u52a1\u89c4\u5219\u6587\u6863\u3001\u6d41\u7a0b\u8865\u5145\u6587\u6863\u548c\u9700\u6c42\u53d8\u66f4\u6587\u6863\u3002\n\n## \u4f7f\u7528\u65b9\u5f0f\n\n1. \u6240\u6709\u65b0\u589e\u9700\u6c42\u6587\u6863\u4f18\u5148\u653e\u5165\u672c\u76ee\u5f55\u3002\n2. \u5efa\u8bae\u4f7f\u7528 `03_\u89c4\u8303\u4e0e\u6a21\u677f/\u9700\u6c42\u8bf4\u660e\u6a21\u677f.md` \u6216 `03_\u89c4\u8303\u4e0e\u6a21\u677f/\u4e1a\u52a1\u89c4\u5219\u4e0e\u9700\u6c42\u8865\u5145\u6a21\u677f.md` \u521b\u5efa\u6587\u6863\u3002\n3. \u6587\u6863\u786e\u8ba4\u6709\u6548\u540e\uff0c\u540c\u6b65\u66f4\u65b0\u4e1a\u52a1\u6d41\u7a0b\u7d22\u5f15\u548c Agent \u68c0\u7d22\u7d22\u5f15\u3002\n4. Agent \u56de\u7b54\u5177\u4f53\u4e1a\u52a1\u9700\u6c42\u65f6\uff0c\u5e94\u4f18\u5148\u68c0\u7d22\u672c\u76ee\u5f55\u3002\n\n## \u63a8\u8350\u547d\u540d\n\n```text\n\u4e1a\u52a1\u57df_\u9700\u6c42\u6216\u89c4\u5219\u540d\u79f0_YYYYMMDD.md\n```\n\n\u793a\u4f8b\uff1a\n\n```text\n\u91c7\u8d2d_\u4f9b\u5e94\u5546\u51c6\u5165\u89c4\u5219_20260526.md\n\u5e93\u5b58_\u51fa\u5165\u5e93\u5ba1\u6279\u89c4\u5219_20260526.md\n\u9500\u552e_\u5ba2\u6237\u6388\u4fe1\u989d\u5ea6\u9700\u6c42_20260526.md\n```\n\n## \u6587\u6863\u72b6\u6001\n\n\u6bcf\u4e2a\u9700\u6c42\u6587\u6863\u5efa\u8bae\u5728 Frontmatter \u4e2d\u7ef4\u62a4 `status`\uff1a\n\n| \u72b6\u6001 | \u542b\u4e49 |\n|---|---|\n| draft | \u8349\u7a3f\uff0c\u5c1a\u672a\u786e\u8ba4 |\n| reviewing | \u8bc4\u5ba1\u4e2d |\n| active | \u5df2\u786e\u8ba4\uff0c\u53ef\u4f5c\u4e3a Agent \u56de\u7b54\u4f9d\u636e |\n| deprecated | \u5df2\u5e9f\u5f03\uff0c\u4ec5\u5f52\u6863\u53c2\u8003 |\n\n## \u5fc5\u586b\u5185\u5bb9\n\n\u6bcf\u4e2a\u9700\u6c42\u6587\u6863\u81f3\u5c11\u5305\u542b\uff1a\n\n- \u9700\u6c42\u80cc\u666f\n- \u9002\u7528\u8303\u56f4\n- \u6d89\u53ca\u89d2\u8272\n- \u4e1a\u52a1\u89c4\u5219\n- \u4e1a\u52a1\u6d41\u7a0b\n- \u5f02\u5e38\u5904\u7406\n- \u6743\u9650\u8981\u6c42\n- \u9a8c\u6536\u53e3\u5f84\n- Agent \u68c0\u7d22\u5b57\u6bb5\n- \u53d8\u66f4\u8bb0\u5f55\n\n## \u7d22\u5f15\u7ef4\u62a4\n\n\u65b0\u589e\u6216\u4fee\u6539\u9700\u6c42\u6587\u6863\u540e\uff0c\u9700\u8981\u540c\u6b65\u66f4\u65b0\uff1a\n\n- `05_\u9700\u6c42\u6587\u6863/\u9700\u6c42\u6587\u6863\u7d22\u5f15.md`\n- `01_\u4e1a\u52a1\u6d41\u7a0b/\u4e1a\u52a1\u89c4\u5219\u7d22\u5f15.md`\n- `01_\u4e1a\u52a1\u6d41\u7a0b/\u4e1a\u52a1\u5bf9\u8c61\u5b57\u5178.md`\n- `04_Agent\u68c0\u7d22/\u5173\u952e\u8bcd\u7d22\u5f15.md`\n- `04_Agent\u68c0\u7d22/\u540c\u4e49\u8bcd\u8868.md`\n- `04_Agent\u68c0\u7d22/\u6765\u6e90\u6587\u4ef6\u7d22\u5f15.md`\n\n## \u9a8c\u8bc1\u6d41\u7a0b\n\n\u65b0\u589e\u9700\u6c42\u6587\u6863\u540e\uff0c\u6309 `04_Agent\u68c0\u7d22/\u77e5\u8bc6\u5e93\u6301\u7eed\u66f4\u65b0\u4e0e\u9a8c\u8bc1\u6d41\u7a0b.md` \u6267\u884c\u9a8c\u8bc1\uff0c\u5e76\u5c06\u9a8c\u8bc1\u7ed3\u679c\u8bb0\u5f55\u5230\uff1a\n\n- `05_\u9700\u6c42\u6587\u6863/\u9700\u6c42\u6587\u6863\u7d22\u5f15.md`\n- `01_\u4e1a\u52a1\u6d41\u7a0b/\u4e1a\u52a1\u8865\u5145\u9a8c\u8bc1\u8bb0\u5f55.md`\n", + "backlinks": [ + "article:\u6b22\u8fce", + "article:\u77e5\u8bc6\u5e93\u4f7f\u7528\u8bf4\u660e" + ] + } + }, + { + "id": "article:05_\u9700\u6c42\u6587\u6863/\u9700\u6c42\u6587\u6863\u7d22\u5f15", + "type": "article", + "name": "\u9700\u6c42\u6587\u6863\u7d22\u5f15", + "filePath": "05_\u9700\u6c42\u6587\u6863\\\u9700\u6c42\u6587\u6863\u7d22\u5f15.md", + "summary": "\u672c\u6587\u4ef6\u8bb0\u5f55 `05_\u9700\u6c42\u6587\u6863/` \u4e0b\u6240\u6709\u6b63\u5f0f\u9700\u6c42\u6587\u6863\uff0c\u4f9b\u4eba\u5de5\u7ef4\u62a4\u548c Agent \u68c0\u7d22\u5b9a\u4f4d\u3002", + "tags": [ + "05_\u9700\u6c42\u6587\u6863", + "Agent\u68c0\u7d22]", + "[\u9700\u6c42\u6587\u6863", + "\u7d22\u5f15" + ], + "complexity": "simple", + "knowledgeMeta": { + "wikilinks": [], + "content": "---\ntype: requirement_index\ntags: [\u9700\u6c42\u6587\u6863, \u7d22\u5f15, Agent\u68c0\u7d22]\naliases: [\u9700\u6c42\u7d22\u5f15, \u9700\u6c42\u6587\u6863\u6e05\u5355, \u9700\u6c42\u6e05\u5355]\nsource: manual\nstatus: active\nowner: \u4ea7\u54c1\u7ecf\u7406 / \u4e1a\u52a1\u4e3b\u7ba1\nupdated: 2026-05\n---\n\n# \u9700\u6c42\u6587\u6863\u7d22\u5f15\n\n\u672c\u6587\u4ef6\u8bb0\u5f55 `05_\u9700\u6c42\u6587\u6863/` \u4e0b\u6240\u6709\u6b63\u5f0f\u9700\u6c42\u6587\u6863\uff0c\u4f9b\u4eba\u5de5\u7ef4\u62a4\u548c Agent \u68c0\u7d22\u5b9a\u4f4d\u3002\n\n## \u9700\u6c42\u6587\u6863\u6e05\u5355\n\n| \u7f16\u53f7 | \u4e1a\u52a1\u57df | \u9700\u6c42/\u89c4\u5219\u540d\u79f0 | \u6587\u4ef6 | \u72b6\u6001 | \u8d1f\u8d23\u4eba | \u66f4\u65b0\u65f6\u95f4 | \u9a8c\u8bc1\u72b6\u6001 |\n|---|---|---|---|---|---|---|---|\n| | | | | | | | \u672a\u9a8c\u8bc1 |\n\n## Agent \u68c0\u7d22\u5173\u952e\u8bcd\n\n| \u5173\u952e\u8bcd/\u95ee\u6cd5 | \u6807\u51c6\u672f\u8bed | \u547d\u4e2d\u6587\u4ef6 | \u7b54\u6848\u8981\u70b9 |\n|---|---|---|---|\n| | | | |\n\n## \u7ef4\u62a4\u89c4\u5219\n\n1. \u65b0\u589e\u9700\u6c42\u6587\u6863\u540e\uff0c\u5fc5\u987b\u5728\u201c\u9700\u6c42\u6587\u6863\u6e05\u5355\u201d\u65b0\u589e\u4e00\u884c\u3002\n2. \u6bcf\u4e2a\u9700\u6c42\u6587\u6863\u81f3\u5c11\u7ef4\u62a4 3 \u4e2a\u53ef\u68c0\u7d22\u95ee\u6cd5\u3002\n3. `\u72b6\u6001=active` \u7684\u6587\u6863\u53ef\u4f5c\u4e3a Agent \u56de\u7b54\u4f9d\u636e\u3002\n4. `status=draft/reviewing` \u7684\u6587\u6863\u53ea\u80fd\u4f5c\u4e3a\u8349\u7a3f\u53c2\u8003\uff0cAgent \u56de\u7b54\u65f6\u9700\u8bf4\u660e\u5c1a\u672a\u786e\u8ba4\u3002\n5. `status=deprecated` \u7684\u6587\u6863\u4e0d\u5f97\u4f5c\u4e3a\u5f53\u524d\u89c4\u5219\u4f9d\u636e\uff0c\u53ea\u80fd\u8bf4\u660e\u5386\u53f2\u80cc\u666f\u3002\n\n## \u9a8c\u8bc1\u8bb0\u5f55\u6458\u8981\n\n| \u65e5\u671f | \u6587\u4ef6 | \u9a8c\u8bc1\u95ee\u9898\u6570 | \u901a\u8fc7\u6570 | \u5931\u8d25\u6570 | \u7ed3\u8bba |\n|---|---|---:|---:|---:|---|\n| | | | | | |\n", + "backlinks": [ + "article:\u77e5\u8bc6\u5e93\u4f7f\u7528\u8bf4\u660e", + "article:\u77e5\u8bc6\u5e93\u4f7f\u7528\u8bf4\u660e" + ] + } + }, + { + "id": "article:06_\u91cc\u7a0b\u7891/README", + "type": "article", + "name": "\u91cc\u7a0b\u7891", + "filePath": "06_\u91cc\u7a0b\u7891\\README.md", + "summary": "\u672c\u76ee\u5f55\u7528\u4e8e\u5b58\u653e\u9879\u76ee\u9636\u6bb5\u8ba1\u5212\u3001\u91cc\u7a0b\u7891\u8282\u70b9\u3001\u9636\u6bb5\u8bc4\u5ba1\u8bb0\u5f55\u548c\u4e0a\u7ebf\u8282\u594f\u8bf4\u660e\u3002", + "tags": [ + "06_\u91cc\u7a0b\u7891", + "[\u91cc\u7a0b\u7891", + "\u77e5\u8bc6\u5e93]", + "\u9879\u76ee\u7ba1\u7406" + ], + "complexity": "moderate", + "knowledgeMeta": { + "wikilinks": [ + "\u91cc\u7a0b\u7891\u7d22\u5f15", + "\u9636\u6bb5\u8ba1\u5212\u6a21\u677f", + "\u91cc\u7a0b\u7891\u8bc4\u5ba1\u8bb0\u5f55", + "../05_\u9700\u6c42\u6587\u6863/README", + "../02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/AI\u9a71\u52a8\u5185\u90e8\u7cfb\u7edf\u5f00\u53d1\u6d41\u7a0b_V3_\u603b\u89c8", + "../08_\u6d4b\u8bd5\u76f8\u5173/README" + ], + "content": "---\ntype: milestone_home\ntags: [\u91cc\u7a0b\u7891, \u9879\u76ee\u7ba1\u7406, \u77e5\u8bc6\u5e93]\naliases: [\u91cc\u7a0b\u7891\u5165\u53e3, \u9879\u76ee\u91cc\u7a0b\u7891]\nsource: manual\nstatus: active\nowner: \u9879\u76ee\u7ecf\u7406\nupdated: 2026-05\n---\n\n# \u91cc\u7a0b\u7891\n\n\u672c\u76ee\u5f55\u7528\u4e8e\u5b58\u653e\u9879\u76ee\u9636\u6bb5\u8ba1\u5212\u3001\u91cc\u7a0b\u7891\u8282\u70b9\u3001\u9636\u6bb5\u8bc4\u5ba1\u8bb0\u5f55\u548c\u4e0a\u7ebf\u8282\u594f\u8bf4\u660e\u3002\n\n## \u4e8c\u7ea7\u5165\u53e3\n\n- [[\u91cc\u7a0b\u7891\u7d22\u5f15]]\n- [[\u9636\u6bb5\u8ba1\u5212\u6a21\u677f]]\n- [[\u91cc\u7a0b\u7891\u8bc4\u5ba1\u8bb0\u5f55]]\n\n## \u5b58\u653e\u5185\u5bb9\n\n- \u9879\u76ee\u542f\u52a8\u8282\u70b9\n- \u9700\u6c42\u8bc4\u5ba1\u8282\u70b9\n- \u539f\u578b/\u9ad8\u4fdd\u771f\u786e\u8ba4\u8282\u70b9\n- \u5f00\u53d1\u542f\u52a8\u8282\u70b9\n- \u6d4b\u8bd5\u51c6\u5165\u8282\u70b9\n- \u4e0a\u7ebf\u68c0\u67e5\u8282\u70b9\n- \u590d\u76d8\u56de\u6d41\u8282\u70b9\n\n## \u547d\u540d\u5efa\u8bae\n\n```text\n\u9879\u76ee\u540d_\u91cc\u7a0b\u7891\u8ba1\u5212_YYYYMMDD.md\n\u9879\u76ee\u540d_\u9636\u6bb5\u8bc4\u5ba1\u8bb0\u5f55_YYYYMMDD.md\n```\n\n## \u5173\u8054\u76ee\u5f55\n\n- \u9700\u6c42\u4f9d\u636e\uff1a[[../05_\u9700\u6c42\u6587\u6863/README|\u9700\u6c42\u6587\u6863]]\n- \u6d41\u7a0b\u4f9d\u636e\uff1a[[../02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/AI\u9a71\u52a8\u5185\u90e8\u7cfb\u7edf\u5f00\u53d1\u6d41\u7a0b_V3_\u603b\u89c8|\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b]]\n- \u6d4b\u8bd5\u51c6\u5165\uff1a[[../08_\u6d4b\u8bd5\u76f8\u5173/README|\u6d4b\u8bd5\u76f8\u5173]]\n", + "backlinks": [ + "article:\u6b22\u8fce", + "article:\u77e5\u8bc6\u5e93\u4f7f\u7528\u8bf4\u660e" + ] + } + }, + { + "id": "article:06_\u91cc\u7a0b\u7891/\u91cc\u7a0b\u7891\u7d22\u5f15", + "type": "article", + "name": "\u91cc\u7a0b\u7891\u7d22\u5f15", + "filePath": "06_\u91cc\u7a0b\u7891\\\u91cc\u7a0b\u7891\u7d22\u5f15.md", + "summary": "| \u9879\u76ee | \u91cc\u7a0b\u7891\u540d\u79f0 | \u6587\u4ef6 | \u9636\u6bb5 | \u8d1f\u8d23\u4eba | \u8ba1\u5212\u65f6\u95f4 | \u5f53\u524d\u72b6\u6001 | |---|---|---|---|---|---|---| | | | | | | | |", + "tags": [ + "06_\u91cc\u7a0b\u7891", + "Agent\u68c0\u7d22]", + "[\u91cc\u7a0b\u7891", + "\u7d22\u5f15" + ], + "complexity": "simple", + "knowledgeMeta": { + "wikilinks": [], + "content": "---\ntype: milestone_index\ntags: [\u91cc\u7a0b\u7891, \u7d22\u5f15, Agent\u68c0\u7d22]\naliases: [\u91cc\u7a0b\u7891\u6e05\u5355, \u9879\u76ee\u8282\u70b9\u7d22\u5f15]\nsource: manual\nstatus: active\nowner: \u9879\u76ee\u7ecf\u7406\nupdated: 2026-05\n---\n\n# \u91cc\u7a0b\u7891\u7d22\u5f15\n\n## \u91cc\u7a0b\u7891\u6587\u6863\u6e05\u5355\n\n| \u9879\u76ee | \u91cc\u7a0b\u7891\u540d\u79f0 | \u6587\u4ef6 | \u9636\u6bb5 | \u8d1f\u8d23\u4eba | \u8ba1\u5212\u65f6\u95f4 | \u5f53\u524d\u72b6\u6001 |\n|---|---|---|---|---|---|---|\n| | | | | | | |\n\n## Agent \u68c0\u7d22\u5173\u952e\u8bcd\n\n| \u95ee\u6cd5 | \u6807\u51c6\u672f\u8bed | \u547d\u4e2d\u6587\u4ef6 | \u7b54\u6848\u8981\u70b9 |\n|---|---|---|---|\n| | | | |\n\n## \u7ef4\u62a4\u89c4\u5219\n\n- \u65b0\u589e\u91cc\u7a0b\u7891\u8ba1\u5212\u540e\uff0c\u5728\u672c\u7d22\u5f15\u767b\u8bb0\u3002\n- \u6bcf\u4e2a\u91cc\u7a0b\u7891\u5e94\u5173\u8054\u81f3\u5c11\u4e00\u4e2a\u9700\u6c42\u6587\u6863\u6216\u9879\u76ee\u7ba1\u7406\u9636\u6bb5\u3002\n- Agent \u56de\u7b54\u9879\u76ee\u8fdb\u5ea6\u3001\u8282\u70b9\u3001\u51c6\u5165\u95ee\u9898\u65f6\uff0c\u5e94\u5f15\u7528\u672c\u7d22\u5f15\u6216\u5177\u4f53\u91cc\u7a0b\u7891\u6587\u4ef6\u3002\n", + "backlinks": [ + "article:06_\u91cc\u7a0b\u7891/README", + "article:\u77e5\u8bc6\u5e93\u4f7f\u7528\u8bf4\u660e" + ] + } + }, + { + "id": "article:06_\u91cc\u7a0b\u7891/\u91cc\u7a0b\u7891\u8bc4\u5ba1\u8bb0\u5f55", + "type": "article", + "name": "\u91cc\u7a0b\u7891\u8bc4\u5ba1\u8bb0\u5f55", + "filePath": "06_\u91cc\u7a0b\u7891\\\u91cc\u7a0b\u7891\u8bc4\u5ba1\u8bb0\u5f55.md", + "summary": "| \u65e5\u671f | \u9879\u76ee | \u9636\u6bb5 | \u8bc4\u5ba1\u7ed3\u8bba | \u9057\u7559\u95ee\u9898 | \u8d1f\u8d23\u4eba | \u540e\u7eed\u52a8\u4f5c | |---|---|---|---|---|---|---| | | | | | | | |", + "tags": [ + "06_\u91cc\u7a0b\u7891", + "[\u91cc\u7a0b\u7891", + "\u8bb0\u5f55]", + "\u8bc4\u5ba1" + ], + "complexity": "simple", + "knowledgeMeta": { + "wikilinks": [], + "content": "---\ntype: milestone_review_log\ntags: [\u91cc\u7a0b\u7891, \u8bc4\u5ba1, \u8bb0\u5f55]\naliases: [\u9636\u6bb5\u8bc4\u5ba1\u8bb0\u5f55, \u91cc\u7a0b\u7891\u8bc4\u5ba1]\nsource: manual\nstatus: active\nowner: \u9879\u76ee\u7ecf\u7406\nupdated: 2026-05\n---\n\n# \u91cc\u7a0b\u7891\u8bc4\u5ba1\u8bb0\u5f55\n\n| \u65e5\u671f | \u9879\u76ee | \u9636\u6bb5 | \u8bc4\u5ba1\u7ed3\u8bba | \u9057\u7559\u95ee\u9898 | \u8d1f\u8d23\u4eba | \u540e\u7eed\u52a8\u4f5c |\n|---|---|---|---|---|---|---|\n| | | | | | | |\n", + "backlinks": [ + "article:06_\u91cc\u7a0b\u7891/README" + ] + } + }, + { + "id": "article:06_\u91cc\u7a0b\u7891/\u9636\u6bb5\u8ba1\u5212\u6a21\u677f", + "type": "article", + "name": "\u9636\u6bb5\u8ba1\u5212\u6a21\u677f", + "filePath": "06_\u91cc\u7a0b\u7891\\\u9636\u6bb5\u8ba1\u5212\u6a21\u677f.md", + "summary": "| \u9879\u76ee | \u5185\u5bb9 | |---|---| | \u9879\u76ee\u540d\u79f0 | | | \u5173\u8054\u9700\u6c42 | | | \u5f53\u524d\u9636\u6bb5 | | | \u8d1f\u8d23\u4eba | | | \u8ba1\u5212\u5f00\u59cb | | | \u8ba1\u5212\u7ed3\u675f | |", + "tags": [ + "06_\u91cc\u7a0b\u7891", + "[\u91cc\u7a0b\u7891", + "\u6a21\u677f]", + "\u9636\u6bb5\u8ba1\u5212" + ], + "complexity": "simple", + "knowledgeMeta": { + "wikilinks": [], + "content": "---\ntype: milestone_template\ntags: [\u91cc\u7a0b\u7891, \u9636\u6bb5\u8ba1\u5212, \u6a21\u677f]\naliases: [\u9636\u6bb5\u8ba1\u5212, \u91cc\u7a0b\u7891\u6a21\u677f]\nsource: manual\nstatus: active\nowner: \u9879\u76ee\u7ecf\u7406\nupdated: 2026-05\n---\n\n# \u9636\u6bb5\u8ba1\u5212\u6a21\u677f\n\n## \u57fa\u672c\u4fe1\u606f\n\n| \u9879\u76ee | \u5185\u5bb9 |\n|---|---|\n| \u9879\u76ee\u540d\u79f0 | |\n| \u5173\u8054\u9700\u6c42 | |\n| \u5f53\u524d\u9636\u6bb5 | |\n| \u8d1f\u8d23\u4eba | |\n| \u8ba1\u5212\u5f00\u59cb | |\n| \u8ba1\u5212\u7ed3\u675f | |\n\n## \u9636\u6bb5\u76ee\u6807\n\n\n## \u8f93\u5165\u6750\u6599\n\n- \u9700\u6c42\u6587\u6863\uff1a\n- \u4e1a\u52a1\u6d41\u7a0b\uff1a\n- \u6280\u672f\u6587\u6863\uff1a\n- \u6d4b\u8bd5\u6750\u6599\uff1a\n\n## \u5173\u952e\u4efb\u52a1\n\n| \u4efb\u52a1 | \u8d1f\u8d23\u4eba | \u622a\u6b62\u65f6\u95f4 | \u8f93\u51fa\u7269 | \u72b6\u6001 |\n|---|---|---|---|---|\n| | | | | |\n\n## \u9636\u6bb5\u4ea4\u4ed8\u7269\n\n\n## \u51c6\u5165/\u51c6\u51fa\u6761\u4ef6\n\n\n## \u98ce\u9669\u4e0e\u963b\u585e\n\n\n## Agent \u68c0\u7d22\u5b57\u6bb5\n\n- \u5173\u952e\u8bcd\uff1a\n- \u540c\u4e49\u8bcd\uff1a\n- \u5178\u578b\u95ee\u6cd5\uff1a\n", + "backlinks": [ + "article:06_\u91cc\u7a0b\u7891/README" + ] + } + }, + { + "id": "article:07_\u6280\u672f\u6587\u6863/README", + "type": "article", + "name": "\u6280\u672f\u6587\u6863", + "filePath": "07_\u6280\u672f\u6587\u6863\\README.md", + "summary": "\u672c\u76ee\u5f55\u7528\u4e8e\u5b58\u653e\u7cfb\u7edf\u67b6\u6784\u3001\u6570\u636e\u6a21\u578b\u3001\u63a5\u53e3\u8bf4\u660e\u3001\u5b9e\u73b0\u65b9\u6848\u3001\u90e8\u7f72\u8bf4\u660e\u548c\u6280\u672f\u51b3\u7b56\u8bb0\u5f55\u3002", + "tags": [ + "07_\u6280\u672f\u6587\u6863", + "[\u6280\u672f\u6587\u6863", + "\u5f00\u53d1", + "\u67b6\u6784", + "\u77e5\u8bc6\u5e93]" + ], + "complexity": "moderate", + "knowledgeMeta": { + "wikilinks": [ + "\u6280\u672f\u6587\u6863\u7d22\u5f15", + "\u7cfb\u7edf\u67b6\u6784\u8bf4\u660e\u6a21\u677f", + "\u63a5\u53e3\u8bf4\u660e\u6a21\u677f", + "\u6280\u672f\u51b3\u7b56\u8bb0\u5f55", + "../05_\u9700\u6c42\u6587\u6863/README", + "../08_\u6d4b\u8bd5\u76f8\u5173/README", + "../06_\u91cc\u7a0b\u7891/README" + ], + "content": "---\ntype: technical_docs_home\ntags: [\u6280\u672f\u6587\u6863, \u67b6\u6784, \u5f00\u53d1, \u77e5\u8bc6\u5e93]\naliases: [\u6280\u672f\u6587\u6863\u5165\u53e3, \u6280\u672f\u8d44\u6599]\nsource: manual\nstatus: active\nowner: \u6280\u672f\u8d1f\u8d23\u4eba\nupdated: 2026-05\n---\n\n# \u6280\u672f\u6587\u6863\n\n\u672c\u76ee\u5f55\u7528\u4e8e\u5b58\u653e\u7cfb\u7edf\u67b6\u6784\u3001\u6570\u636e\u6a21\u578b\u3001\u63a5\u53e3\u8bf4\u660e\u3001\u5b9e\u73b0\u65b9\u6848\u3001\u90e8\u7f72\u8bf4\u660e\u548c\u6280\u672f\u51b3\u7b56\u8bb0\u5f55\u3002\n\n## \u4e8c\u7ea7\u5165\u53e3\n\n- [[\u6280\u672f\u6587\u6863\u7d22\u5f15]]\n- [[\u7cfb\u7edf\u67b6\u6784\u8bf4\u660e\u6a21\u677f]]\n- [[\u63a5\u53e3\u8bf4\u660e\u6a21\u677f]]\n- [[\u6280\u672f\u51b3\u7b56\u8bb0\u5f55]]\n\n## \u5b58\u653e\u5185\u5bb9\n\n- \u7cfb\u7edf\u67b6\u6784\u8bf4\u660e\n- \u6a21\u5757\u8bbe\u8ba1\u8bf4\u660e\n- \u6570\u636e\u8868/\u4e1a\u52a1\u5bf9\u8c61\u8bbe\u8ba1\n- API \u63a5\u53e3\u8bf4\u660e\n- \u6743\u9650\u4e0e\u5b89\u5168\u8bbe\u8ba1\n- \u90e8\u7f72\u4e0e\u914d\u7f6e\u8bf4\u660e\n- \u6280\u672f\u51b3\u7b56\u8bb0\u5f55\n\n## \u547d\u540d\u5efa\u8bae\n\n```text\n\u7cfb\u7edf\u6216\u6a21\u5757_\u6280\u672f\u65b9\u6848_YYYYMMDD.md\n\u7cfb\u7edf\u6216\u6a21\u5757_\u63a5\u53e3\u8bf4\u660e_YYYYMMDD.md\n\u7cfb\u7edf\u6216\u6a21\u5757_\u6570\u636e\u6a21\u578b_YYYYMMDD.md\n```\n\n## \u5173\u8054\u76ee\u5f55\n\n- \u9700\u6c42\u4f9d\u636e\uff1a[[../05_\u9700\u6c42\u6587\u6863/README|\u9700\u6c42\u6587\u6863]]\n- \u6d4b\u8bd5\u4f9d\u636e\uff1a[[../08_\u6d4b\u8bd5\u76f8\u5173/README|\u6d4b\u8bd5\u76f8\u5173]]\n- \u91cc\u7a0b\u7891\uff1a[[../06_\u91cc\u7a0b\u7891/README|\u91cc\u7a0b\u7891]]\n", + "backlinks": [ + "article:\u6b22\u8fce", + "article:\u77e5\u8bc6\u5e93\u4f7f\u7528\u8bf4\u660e" + ] + } + }, + { + "id": "article:07_\u6280\u672f\u6587\u6863/\u6280\u672f\u51b3\u7b56\u8bb0\u5f55", + "type": "article", + "name": "\u6280\u672f\u51b3\u7b56\u8bb0\u5f55", + "filePath": "07_\u6280\u672f\u6587\u6863\\\u6280\u672f\u51b3\u7b56\u8bb0\u5f55.md", + "summary": "| \u65e5\u671f | \u51b3\u7b56\u4e3b\u9898 | \u80cc\u666f | \u51b3\u7b56\u7ed3\u8bba | \u5f71\u54cd\u8303\u56f4 | \u5173\u8054\u9700\u6c42/\u6280\u672f\u6587\u6863 | |---|---|---|---|---|---| | | | | | | |", + "tags": [ + "07_\u6280\u672f\u6587\u6863", + "ADR]", + "[\u6280\u672f\u6587\u6863", + "\u6280\u672f\u51b3\u7b56" + ], + "complexity": "simple", + "knowledgeMeta": { + "wikilinks": [], + "content": "---\ntype: adr_log\ntags: [\u6280\u672f\u6587\u6863, \u6280\u672f\u51b3\u7b56, ADR]\naliases: [\u6280\u672f\u51b3\u7b56, ADR]\nsource: manual\nstatus: active\nowner: \u6280\u672f\u8d1f\u8d23\u4eba\nupdated: 2026-05\n---\n\n# \u6280\u672f\u51b3\u7b56\u8bb0\u5f55\n\n| \u65e5\u671f | \u51b3\u7b56\u4e3b\u9898 | \u80cc\u666f | \u51b3\u7b56\u7ed3\u8bba | \u5f71\u54cd\u8303\u56f4 | \u5173\u8054\u9700\u6c42/\u6280\u672f\u6587\u6863 |\n|---|---|---|---|---|---|\n| | | | | | |\n", + "backlinks": [ + "article:07_\u6280\u672f\u6587\u6863/README" + ] + } + }, + { + "id": "article:07_\u6280\u672f\u6587\u6863/\u6280\u672f\u6587\u6863\u7d22\u5f15", + "type": "article", + "name": "\u6280\u672f\u6587\u6863\u7d22\u5f15", + "filePath": "07_\u6280\u672f\u6587\u6863\\\u6280\u672f\u6587\u6863\u7d22\u5f15.md", + "summary": "| \u6a21\u5757/\u7cfb\u7edf | \u6587\u6863\u7c7b\u578b | \u6587\u4ef6 | \u5173\u8054\u9700\u6c42 | \u8d1f\u8d23\u4eba | \u66f4\u65b0\u65f6\u95f4 | \u72b6\u6001 | |---|---|---|---|---|---|---| | | | | | | | |", + "tags": [ + "07_\u6280\u672f\u6587\u6863", + "Agent\u68c0\u7d22]", + "[\u6280\u672f\u6587\u6863", + "\u7d22\u5f15" + ], + "complexity": "simple", + "knowledgeMeta": { + "wikilinks": [], + "content": "---\ntype: technical_docs_index\ntags: [\u6280\u672f\u6587\u6863, \u7d22\u5f15, Agent\u68c0\u7d22]\naliases: [\u6280\u672f\u7d22\u5f15, \u6280\u672f\u8d44\u6599\u6e05\u5355]\nsource: manual\nstatus: active\nowner: \u6280\u672f\u8d1f\u8d23\u4eba\nupdated: 2026-05\n---\n\n# \u6280\u672f\u6587\u6863\u7d22\u5f15\n\n## \u6280\u672f\u6587\u6863\u6e05\u5355\n\n| \u6a21\u5757/\u7cfb\u7edf | \u6587\u6863\u7c7b\u578b | \u6587\u4ef6 | \u5173\u8054\u9700\u6c42 | \u8d1f\u8d23\u4eba | \u66f4\u65b0\u65f6\u95f4 | \u72b6\u6001 |\n|---|---|---|---|---|---|---|\n| | | | | | | |\n\n## Agent \u68c0\u7d22\u5173\u952e\u8bcd\n\n| \u95ee\u6cd5 | \u6807\u51c6\u672f\u8bed | \u547d\u4e2d\u6587\u4ef6 | \u7b54\u6848\u8981\u70b9 |\n|---|---|---|---|\n| | | | |\n\n## \u7ef4\u62a4\u89c4\u5219\n\n- \u65b0\u589e\u6280\u672f\u65b9\u6848\u3001\u63a5\u53e3\u8bf4\u660e\u3001\u6570\u636e\u6a21\u578b\u540e\uff0c\u5728\u672c\u7d22\u5f15\u767b\u8bb0\u3002\n- \u6280\u672f\u6587\u6863\u5fc5\u987b\u5173\u8054\u9700\u6c42\u6587\u6863\u6216\u4e1a\u52a1\u6d41\u7a0b\u3002\n- Agent \u56de\u7b54\u6280\u672f\u5b9e\u73b0\u3001\u63a5\u53e3\u3001\u6570\u636e\u7ed3\u6784\u95ee\u9898\u65f6\uff0c\u5e94\u4f18\u5148\u68c0\u7d22\u672c\u76ee\u5f55\u3002\n", + "backlinks": [ + "article:07_\u6280\u672f\u6587\u6863/README", + "article:\u77e5\u8bc6\u5e93\u4f7f\u7528\u8bf4\u660e", + "article:\u77e5\u8bc6\u5e93\u4f7f\u7528\u8bf4\u660e" + ] + } + }, + { + "id": "article:07_\u6280\u672f\u6587\u6863/\u63a5\u53e3\u8bf4\u660e\u6a21\u677f", + "type": "article", + "name": "\u63a5\u53e3\u8bf4\u660e\u6a21\u677f", + "filePath": "07_\u6280\u672f\u6587\u6863\\\u63a5\u53e3\u8bf4\u660e\u6a21\u677f.md", + "summary": "| \u9879\u76ee | \u5185\u5bb9 | |---|---| | \u63a5\u53e3\u540d\u79f0 | | | \u6240\u5c5e\u6a21\u5757 | | | \u5173\u8054\u9700\u6c42 | | | \u8d1f\u8d23\u4eba | | | \u72b6\u6001 | draft |", + "tags": [ + "07_\u6280\u672f\u6587\u6863", + "[\u6280\u672f\u6587\u6863", + "\u63a5\u53e3", + "\u6a21\u677f]" + ], + "complexity": "simple", + "knowledgeMeta": { + "wikilinks": [], + "content": "---\ntype: api_template\ntags: [\u6280\u672f\u6587\u6863, \u63a5\u53e3, \u6a21\u677f]\naliases: [\u63a5\u53e3\u6a21\u677f, API\u8bf4\u660e\u6a21\u677f]\nsource: manual\nstatus: active\nowner: \u6280\u672f\u8d1f\u8d23\u4eba\nupdated: 2026-05\n---\n\n# \u63a5\u53e3\u8bf4\u660e\u6a21\u677f\n\n## \u57fa\u672c\u4fe1\u606f\n\n| \u9879\u76ee | \u5185\u5bb9 |\n|---|---|\n| \u63a5\u53e3\u540d\u79f0 | |\n| \u6240\u5c5e\u6a21\u5757 | |\n| \u5173\u8054\u9700\u6c42 | |\n| \u8d1f\u8d23\u4eba | |\n| \u72b6\u6001 | draft |\n\n## \u63a5\u53e3\u7528\u9014\n\n\n## \u8bf7\u6c42\u8bf4\u660e\n\n| \u5b57\u6bb5 | \u7c7b\u578b | \u5fc5\u586b | \u8bf4\u660e | \u793a\u4f8b |\n|---|---|---|---|---|\n| | | | | |\n\n## \u54cd\u5e94\u8bf4\u660e\n\n| \u5b57\u6bb5 | \u7c7b\u578b | \u8bf4\u660e | \u793a\u4f8b |\n|---|---|---|---|\n| | | | |\n\n## \u4e1a\u52a1\u89c4\u5219\n\n\n## \u5f02\u5e38\u7801\n\n| \u5f02\u5e38\u7801 | \u542b\u4e49 | \u5904\u7406\u65b9\u5f0f |\n|---|---|---|\n| | | |\n\n## Agent \u68c0\u7d22\u5b57\u6bb5\n\n- \u5173\u952e\u8bcd\uff1a\n- \u540c\u4e49\u8bcd\uff1a\n- \u5178\u578b\u95ee\u6cd5\uff1a\n", + "backlinks": [ + "article:07_\u6280\u672f\u6587\u6863/README" + ] + } + }, + { + "id": "article:07_\u6280\u672f\u6587\u6863/\u7cfb\u7edf\u67b6\u6784\u8bf4\u660e\u6a21\u677f", + "type": "article", + "name": "\u7cfb\u7edf\u67b6\u6784\u8bf4\u660e\u6a21\u677f", + "filePath": "07_\u6280\u672f\u6587\u6863\\\u7cfb\u7edf\u67b6\u6784\u8bf4\u660e\u6a21\u677f.md", + "summary": "| \u9879\u76ee | \u5185\u5bb9 | |---|---| | \u7cfb\u7edf/\u6a21\u5757 | | | \u5173\u8054\u9700\u6c42 | | | \u8d1f\u8d23\u4eba | | | \u72b6\u6001 | draft |", + "tags": [ + "07_\u6280\u672f\u6587\u6863", + "[\u6280\u672f\u6587\u6863", + "\u67b6\u6784", + "\u6a21\u677f]" + ], + "complexity": "simple", + "knowledgeMeta": { + "wikilinks": [], + "content": "---\ntype: architecture_template\ntags: [\u6280\u672f\u6587\u6863, \u67b6\u6784, \u6a21\u677f]\naliases: [\u67b6\u6784\u8bf4\u660e\u6a21\u677f]\nsource: manual\nstatus: active\nowner: \u6280\u672f\u8d1f\u8d23\u4eba\nupdated: 2026-05\n---\n\n# \u7cfb\u7edf\u67b6\u6784\u8bf4\u660e\u6a21\u677f\n\n## \u57fa\u672c\u4fe1\u606f\n\n| \u9879\u76ee | \u5185\u5bb9 |\n|---|---|\n| \u7cfb\u7edf/\u6a21\u5757 | |\n| \u5173\u8054\u9700\u6c42 | |\n| \u8d1f\u8d23\u4eba | |\n| \u72b6\u6001 | draft |\n\n## \u80cc\u666f\u4e0e\u76ee\u6807\n\n\n## \u67b6\u6784\u8bf4\u660e\n\n\n## \u6a21\u5757\u5212\u5206\n\n| \u6a21\u5757 | \u804c\u8d23 | \u8f93\u5165 | \u8f93\u51fa | \u4f9d\u8d56 |\n|---|---|---|---|---|\n| | | | | |\n\n## \u6570\u636e\u6a21\u578b\n\n\n## \u63a5\u53e3\u5173\u7cfb\n\n\n## \u6743\u9650\u4e0e\u5b89\u5168\n\n\n## \u5f02\u5e38\u4e0e\u8fb9\u754c\n\n\n## \u90e8\u7f72\u4e0e\u914d\u7f6e\n\n\n## Agent \u68c0\u7d22\u5b57\u6bb5\n\n- \u5173\u952e\u8bcd\uff1a\n- \u540c\u4e49\u8bcd\uff1a\n- \u5178\u578b\u95ee\u6cd5\uff1a\n", + "backlinks": [ + "article:07_\u6280\u672f\u6587\u6863/README" + ] + } + }, + { + "id": "article:08_\u6d4b\u8bd5\u76f8\u5173/README", + "type": "article", + "name": "\u6d4b\u8bd5\u76f8\u5173", + "filePath": "08_\u6d4b\u8bd5\u76f8\u5173\\README.md", + "summary": "\u672c\u76ee\u5f55\u7528\u4e8e\u5b58\u653e\u6d4b\u8bd5\u8ba1\u5212\u3001\u6d4b\u8bd5\u7528\u4f8b\u3001\u6d4b\u8bd5\u62a5\u544a\u3001\u7f3a\u9677\u8bb0\u5f55\u3001\u9a8c\u6536\u8bb0\u5f55\u548c\u4e0a\u7ebf\u68c0\u67e5\u6750\u6599\u3002", + "tags": [ + "08_\u6d4b\u8bd5\u76f8\u5173", + "[\u6d4b\u8bd5", + "\u6d4b\u8bd5\u7528\u4f8b", + "\u77e5\u8bc6\u5e93]", + "\u9a8c\u6536" + ], + "complexity": "moderate", + "knowledgeMeta": { + "wikilinks": [ + "\u6d4b\u8bd5\u7528\u4f8b\u7d22\u5f15", + "\u6d4b\u8bd5\u7528\u4f8b\u6a21\u677f", + "\u6d4b\u8bd5\u8ba1\u5212\u6a21\u677f", + "\u7f3a\u9677\u8bb0\u5f55\u6a21\u677f", + "\u9a8c\u6536\u8bb0\u5f55\u6a21\u677f", + "\u4e0a\u7ebf\u68c0\u67e5\u6a21\u677f", + "../05_\u9700\u6c42\u6587\u6863/README", + "../07_\u6280\u672f\u6587\u6863/README", + "../06_\u91cc\u7a0b\u7891/README", + "../02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/\u9636\u6bb52.5_\u6d4b\u8bd5\u63d0\u524d\u8865\u6f0f", + "../02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/\u9636\u6bb54_\u6d4b\u8bd5\u57f9\u8bad\u4e0a\u7ebf\u56de\u6d41" + ], + "content": "---\ntype: testing_home\ntags: [\u6d4b\u8bd5, \u6d4b\u8bd5\u7528\u4f8b, \u9a8c\u6536, \u77e5\u8bc6\u5e93]\naliases: [\u6d4b\u8bd5\u76f8\u5173\u5165\u53e3, \u6d4b\u8bd5\u6587\u6863]\nsource: manual\nstatus: active\nowner: \u6d4b\u8bd5\u8d1f\u8d23\u4eba\nupdated: 2026-05\n---\n\n# \u6d4b\u8bd5\u76f8\u5173\n\n\u672c\u76ee\u5f55\u7528\u4e8e\u5b58\u653e\u6d4b\u8bd5\u8ba1\u5212\u3001\u6d4b\u8bd5\u7528\u4f8b\u3001\u6d4b\u8bd5\u62a5\u544a\u3001\u7f3a\u9677\u8bb0\u5f55\u3001\u9a8c\u6536\u8bb0\u5f55\u548c\u4e0a\u7ebf\u68c0\u67e5\u6750\u6599\u3002\n\n## \u4e8c\u7ea7\u5165\u53e3\n\n- [[\u6d4b\u8bd5\u7528\u4f8b\u7d22\u5f15]]\n- [[\u6d4b\u8bd5\u7528\u4f8b\u6a21\u677f]]\n- [[\u6d4b\u8bd5\u8ba1\u5212\u6a21\u677f]]\n- [[\u7f3a\u9677\u8bb0\u5f55\u6a21\u677f]]\n- [[\u9a8c\u6536\u8bb0\u5f55\u6a21\u677f]]\n- [[\u4e0a\u7ebf\u68c0\u67e5\u6a21\u677f]]\n\n## \u5b58\u653e\u5185\u5bb9\n\n- \u6d4b\u8bd5\u8ba1\u5212\n- \u6d4b\u8bd5\u7528\u4f8b\n- \u6d4b\u8bd5\u6267\u884c\u8bb0\u5f55\n- \u7f3a\u9677\u8bb0\u5f55\n- \u9a8c\u6536\u8bb0\u5f55\n- \u4e0a\u7ebf\u68c0\u67e5\u8bb0\u5f55\n- \u56de\u5f52\u6d4b\u8bd5\u8bf4\u660e\n\n## \u547d\u540d\u5efa\u8bae\n\n```text\n\u9879\u76ee\u6216\u6a21\u5757_\u6d4b\u8bd5\u7528\u4f8b_YYYYMMDD.md\n\u9879\u76ee\u6216\u6a21\u5757_\u6d4b\u8bd5\u8ba1\u5212_YYYYMMDD.md\n\u9879\u76ee\u6216\u6a21\u5757_\u7f3a\u9677\u8bb0\u5f55_YYYYMMDD.md\n\u9879\u76ee\u6216\u6a21\u5757_\u9a8c\u6536\u8bb0\u5f55_YYYYMMDD.md\n```\n\n## \u5173\u8054\u76ee\u5f55\n\n- \u9700\u6c42\u4f9d\u636e\uff1a[[../05_\u9700\u6c42\u6587\u6863/README|\u9700\u6c42\u6587\u6863]]\n- \u6280\u672f\u4f9d\u636e\uff1a[[../07_\u6280\u672f\u6587\u6863/README|\u6280\u672f\u6587\u6863]]\n- \u91cc\u7a0b\u7891\u4f9d\u636e\uff1a[[../06_\u91cc\u7a0b\u7891/README|\u91cc\u7a0b\u7891]]\n- \u6d41\u7a0b\u4f9d\u636e\uff1a[[../02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/\u9636\u6bb52.5_\u6d4b\u8bd5\u63d0\u524d\u8865\u6f0f|\u9636\u6bb52.5 \u6d4b\u8bd5\u63d0\u524d\u8865\u6f0f]]\u3001[[../02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/\u9636\u6bb54_\u6d4b\u8bd5\u57f9\u8bad\u4e0a\u7ebf\u56de\u6d41|\u9636\u6bb54 \u6d4b\u8bd5\u57f9\u8bad\u4e0a\u7ebf\u56de\u6d41]]\n", + "backlinks": [ + "article:\u6b22\u8fce", + "article:\u77e5\u8bc6\u5e93\u4f7f\u7528\u8bf4\u660e" + ] + } + }, + { + "id": "article:08_\u6d4b\u8bd5\u76f8\u5173/\u4e0a\u7ebf\u68c0\u67e5\u6a21\u677f", + "type": "article", + "name": "\u4e0a\u7ebf\u68c0\u67e5\u6a21\u677f", + "filePath": "08_\u6d4b\u8bd5\u76f8\u5173\\\u4e0a\u7ebf\u68c0\u67e5\u6a21\u677f.md", + "summary": "| \u9879\u76ee | \u5185\u5bb9 | |---|---| | \u9879\u76ee/\u6a21\u5757 | | | \u5173\u8054\u9700\u6c42 | | | \u5173\u8054\u91cc\u7a0b\u7891 | | | \u8d1f\u8d23\u4eba | | | \u68c0\u67e5\u65e5\u671f | |", + "tags": [ + "08_\u6d4b\u8bd5\u76f8\u5173", + "[\u4e0a\u7ebf\u68c0\u67e5", + "\u6a21\u677f]", + "\u6d4b\u8bd5" + ], + "complexity": "simple", + "knowledgeMeta": { + "wikilinks": [], + "content": "---\ntype: go_live_checklist_template\ntags: [\u4e0a\u7ebf\u68c0\u67e5, \u6d4b\u8bd5, \u6a21\u677f]\naliases: [\u4e0a\u7ebf\u68c0\u67e5, \u53d1\u5e03\u68c0\u67e5]\nsource: manual\nstatus: active\nowner: \u6d4b\u8bd5\u8d1f\u8d23\u4eba / \u9879\u76ee\u7ecf\u7406\nupdated: 2026-05\n---\n\n# \u4e0a\u7ebf\u68c0\u67e5\u6a21\u677f\n\n## \u57fa\u672c\u4fe1\u606f\n\n| \u9879\u76ee | \u5185\u5bb9 |\n|---|---|\n| \u9879\u76ee/\u6a21\u5757 | |\n| \u5173\u8054\u9700\u6c42 | |\n| \u5173\u8054\u91cc\u7a0b\u7891 | |\n| \u8d1f\u8d23\u4eba | |\n| \u68c0\u67e5\u65e5\u671f | |\n\n## \u4e0a\u7ebf\u524d\u68c0\u67e5\u9879\n\n| \u68c0\u67e5\u9879 | \u8d1f\u8d23\u4eba | \u7ed3\u679c | \u5907\u6ce8 |\n|---|---|---|---|\n| \u9700\u6c42\u5df2\u786e\u8ba4 | | | |\n| \u6d4b\u8bd5\u7528\u4f8b\u5df2\u6267\u884c | | | |\n| P0/P1 \u7f3a\u9677\u5df2\u5173\u95ed | | | |\n| \u7528\u6237\u57f9\u8bad\u5df2\u5b8c\u6210 | | | |\n| \u56de\u6eda\u65b9\u6848\u5df2\u786e\u8ba4 | | | |\n| \u6570\u636e\u5907\u4efd\u5df2\u786e\u8ba4 | | | |\n\n## \u4e0a\u7ebf\u7ed3\u8bba\n\n\n## \u56de\u6eda\u6761\u4ef6\n\n\n## Agent \u68c0\u7d22\u5b57\u6bb5\n\n- \u5173\u952e\u8bcd\uff1a\n- \u540c\u4e49\u8bcd\uff1a\n- \u5178\u578b\u95ee\u6cd5\uff1a\n", + "backlinks": [] + } + }, + { + "id": "article:08_\u6d4b\u8bd5\u76f8\u5173/\u6d4b\u8bd5\u7528\u4f8b\u6a21\u677f", + "type": "article", + "name": "\u6d4b\u8bd5\u7528\u4f8b\u6a21\u677f", + "filePath": "08_\u6d4b\u8bd5\u76f8\u5173\\\u6d4b\u8bd5\u7528\u4f8b\u6a21\u677f.md", + "summary": "| \u9879\u76ee | \u5185\u5bb9 | |---|---| | \u9879\u76ee/\u6a21\u5757 | | | \u5173\u8054\u9700\u6c42 | | | \u5173\u8054\u6280\u672f\u6587\u6863 | | | \u6d4b\u8bd5\u8d1f\u8d23\u4eba | | | \u72b6\u6001 | draft |", + "tags": [ + "08_\u6d4b\u8bd5\u76f8\u5173", + "[\u6d4b\u8bd5\u7528\u4f8b", + "\u6a21\u677f]", + "\u6d4b\u8bd5" + ], + "complexity": "simple", + "knowledgeMeta": { + "wikilinks": [], + "content": "---\ntype: test_case_template\ntags: [\u6d4b\u8bd5\u7528\u4f8b, \u6d4b\u8bd5, \u6a21\u677f]\naliases: [\u7528\u4f8b\u6a21\u677f, \u6d4b\u8bd5\u7528\u4f8b]\nsource: manual\nstatus: active\nowner: \u6d4b\u8bd5\u8d1f\u8d23\u4eba\nupdated: 2026-05\n---\n\n# \u6d4b\u8bd5\u7528\u4f8b\u6a21\u677f\n\n## \u57fa\u672c\u4fe1\u606f\n\n| \u9879\u76ee | \u5185\u5bb9 |\n|---|---|\n| \u9879\u76ee/\u6a21\u5757 | |\n| \u5173\u8054\u9700\u6c42 | |\n| \u5173\u8054\u6280\u672f\u6587\u6863 | |\n| \u6d4b\u8bd5\u8d1f\u8d23\u4eba | |\n| \u72b6\u6001 | draft |\n\n## \u6d4b\u8bd5\u8303\u56f4\n\n\n## \u524d\u7f6e\u6761\u4ef6\n\n\n## \u6d4b\u8bd5\u7528\u4f8b\n\n| \u7528\u4f8b\u7f16\u53f7 | \u573a\u666f | \u524d\u7f6e\u6761\u4ef6 | \u64cd\u4f5c\u6b65\u9aa4 | \u9884\u671f\u7ed3\u679c | \u4f18\u5148\u7ea7 | \u72b6\u6001 |\n|---|---|---|---|---|---|---|\n| TC-001 | | | | | P1 | \u672a\u6267\u884c |\n\n## \u8fb9\u754c\u4e0e\u5f02\u5e38\u573a\u666f\n\n\n## \u9a8c\u6536\u53e3\u5f84\n\n\n## Agent \u68c0\u7d22\u5b57\u6bb5\n\n- \u5173\u952e\u8bcd\uff1a\n- \u540c\u4e49\u8bcd\uff1a\n- \u5178\u578b\u95ee\u6cd5\uff1a\n", + "backlinks": [ + "article:08_\u6d4b\u8bd5\u76f8\u5173/README" + ] + } + }, + { + "id": "article:08_\u6d4b\u8bd5\u76f8\u5173/\u6d4b\u8bd5\u7528\u4f8b\u7d22\u5f15", + "type": "article", + "name": "\u6d4b\u8bd5\u7528\u4f8b\u7d22\u5f15", + "filePath": "08_\u6d4b\u8bd5\u76f8\u5173\\\u6d4b\u8bd5\u7528\u4f8b\u7d22\u5f15.md", + "summary": "| \u7f16\u53f7 | \u9879\u76ee/\u6a21\u5757 | \u7528\u4f8b\u96c6\u540d\u79f0 | \u6587\u4ef6 | \u5173\u8054\u9700\u6c42 | \u5173\u8054\u6280\u672f\u6587\u6863 | \u8d1f\u8d23\u4eba | \u72b6\u6001 | \u66f4\u65b0\u65f6\u95f4 | |---|---|---|---|---|---|---|---|---| | | | | | | | | \u672a\u9a8c\u8bc1 | |", + "tags": [ + "08_\u6d4b\u8bd5\u76f8\u5173", + "Agent\u68c0\u7d22]", + "[\u6d4b\u8bd5\u7528\u4f8b", + "\u6d4b\u8bd5", + "\u7d22\u5f15" + ], + "complexity": "simple", + "knowledgeMeta": { + "wikilinks": [], + "content": "---\ntype: test_case_index\ntags: [\u6d4b\u8bd5\u7528\u4f8b, \u6d4b\u8bd5, \u7d22\u5f15, Agent\u68c0\u7d22]\naliases: [\u6d4b\u8bd5\u7528\u4f8b\u6e05\u5355, \u7528\u4f8b\u7d22\u5f15]\nsource: manual\nstatus: active\nowner: \u6d4b\u8bd5\u8d1f\u8d23\u4eba\nupdated: 2026-05\n---\n\n# \u6d4b\u8bd5\u7528\u4f8b\u7d22\u5f15\n\n## \u6d4b\u8bd5\u7528\u4f8b\u6e05\u5355\n\n| \u7f16\u53f7 | \u9879\u76ee/\u6a21\u5757 | \u7528\u4f8b\u96c6\u540d\u79f0 | \u6587\u4ef6 | \u5173\u8054\u9700\u6c42 | \u5173\u8054\u6280\u672f\u6587\u6863 | \u8d1f\u8d23\u4eba | \u72b6\u6001 | \u66f4\u65b0\u65f6\u95f4 |\n|---|---|---|---|---|---|---|---|---|\n| | | | | | | | \u672a\u9a8c\u8bc1 | |\n\n## Agent \u68c0\u7d22\u5173\u952e\u8bcd\n\n| \u95ee\u6cd5 | \u6807\u51c6\u672f\u8bed | \u547d\u4e2d\u6587\u4ef6 | \u7b54\u6848\u8981\u70b9 |\n|---|---|---|---|\n| | | | |\n\n## \u7ef4\u62a4\u89c4\u5219\n\n- \u65b0\u589e\u6d4b\u8bd5\u7528\u4f8b\u540e\uff0c\u5fc5\u987b\u5728\u672c\u7d22\u5f15\u767b\u8bb0\u3002\n- \u6bcf\u4e2a\u6d4b\u8bd5\u7528\u4f8b\u6587\u4ef6\u5fc5\u987b\u5173\u8054\u81f3\u5c11\u4e00\u4e2a\u9700\u6c42\u6587\u6863\u3002\n- \u82e5\u6d4b\u8bd5\u7528\u4f8b\u4f9d\u8d56\u63a5\u53e3\u3001\u6570\u636e\u6a21\u578b\u6216\u6280\u672f\u65b9\u6848\uff0c\u5e94\u5173\u8054\u6280\u672f\u6587\u6863\u3002\n- Agent \u56de\u7b54\u6d4b\u8bd5\u8303\u56f4\u3001\u9a8c\u6536\u53e3\u5f84\u3001\u7f3a\u9677\u590d\u73b0\u95ee\u9898\u65f6\uff0c\u5e94\u4f18\u5148\u68c0\u7d22\u672c\u76ee\u5f55\u3002\n", + "backlinks": [ + "article:08_\u6d4b\u8bd5\u76f8\u5173/README", + "article:\u77e5\u8bc6\u5e93\u4f7f\u7528\u8bf4\u660e", + "article:\u77e5\u8bc6\u5e93\u4f7f\u7528\u8bf4\u660e" + ] + } + }, + { + "id": "article:08_\u6d4b\u8bd5\u76f8\u5173/\u6d4b\u8bd5\u8ba1\u5212\u6a21\u677f", + "type": "article", + "name": "\u6d4b\u8bd5\u8ba1\u5212\u6a21\u677f", + "filePath": "08_\u6d4b\u8bd5\u76f8\u5173\\\u6d4b\u8bd5\u8ba1\u5212\u6a21\u677f.md", + "summary": "| \u9879\u76ee | \u5185\u5bb9 | |---|---| | \u9879\u76ee/\u6a21\u5757 | | | \u5173\u8054\u9700\u6c42 | | | \u5173\u8054\u91cc\u7a0b\u7891 | | | \u6d4b\u8bd5\u8d1f\u8d23\u4eba | | | \u8ba1\u5212\u5468\u671f | |", + "tags": [ + "08_\u6d4b\u8bd5\u76f8\u5173", + "[\u6d4b\u8bd5\u8ba1\u5212", + "\u6a21\u677f]", + "\u6d4b\u8bd5" + ], + "complexity": "simple", + "knowledgeMeta": { + "wikilinks": [], + "content": "---\ntype: test_plan_template\ntags: [\u6d4b\u8bd5\u8ba1\u5212, \u6d4b\u8bd5, \u6a21\u677f]\naliases: [\u6d4b\u8bd5\u8ba1\u5212\u6a21\u677f]\nsource: manual\nstatus: active\nowner: \u6d4b\u8bd5\u8d1f\u8d23\u4eba\nupdated: 2026-05\n---\n\n# \u6d4b\u8bd5\u8ba1\u5212\u6a21\u677f\n\n## \u57fa\u672c\u4fe1\u606f\n\n| \u9879\u76ee | \u5185\u5bb9 |\n|---|---|\n| \u9879\u76ee/\u6a21\u5757 | |\n| \u5173\u8054\u9700\u6c42 | |\n| \u5173\u8054\u91cc\u7a0b\u7891 | |\n| \u6d4b\u8bd5\u8d1f\u8d23\u4eba | |\n| \u8ba1\u5212\u5468\u671f | |\n\n## \u6d4b\u8bd5\u76ee\u6807\n\n\n## \u6d4b\u8bd5\u8303\u56f4\n\n\n## \u4e0d\u5728\u8303\u56f4\u5185\n\n\n## \u6d4b\u8bd5\u8d44\u6e90\n\n\n## \u6d4b\u8bd5\u5b89\u6392\n\n| \u9636\u6bb5 | \u65f6\u95f4 | \u8d1f\u8d23\u4eba | \u8f93\u51fa\u7269 |\n|---|---|---|---|\n| | | | |\n\n## \u51c6\u5165\u6761\u4ef6\n\n\n## \u51c6\u51fa\u6761\u4ef6\n\n\n## \u98ce\u9669\n\n\n## Agent \u68c0\u7d22\u5b57\u6bb5\n\n- \u5173\u952e\u8bcd\uff1a\n- \u540c\u4e49\u8bcd\uff1a\n- \u5178\u578b\u95ee\u6cd5\uff1a\n", + "backlinks": [ + "article:08_\u6d4b\u8bd5\u76f8\u5173/README" + ] + } + }, + { + "id": "article:08_\u6d4b\u8bd5\u76f8\u5173/\u7f3a\u9677\u8bb0\u5f55\u6a21\u677f", + "type": "article", + "name": "\u7f3a\u9677\u8bb0\u5f55\u6a21\u677f", + "filePath": "08_\u6d4b\u8bd5\u76f8\u5173\\\u7f3a\u9677\u8bb0\u5f55\u6a21\u677f.md", + "summary": "| \u9879\u76ee | \u5185\u5bb9 | |---|---| | \u7f3a\u9677\u7f16\u53f7 | BUG- | | \u9879\u76ee/\u6a21\u5757 | | | \u5173\u8054\u9700\u6c42 | | | \u5173\u8054\u7528\u4f8b | | | \u4e25\u91cd\u7ea7\u522b | | | \u5f53\u524d\u72b6\u6001 | open | | \u8d1f\u8d23\u4eba | |", + "tags": [ + "08_\u6d4b\u8bd5\u76f8\u5173", + "[\u7f3a\u9677", + "\u6a21\u677f]", + "\u6d4b\u8bd5" + ], + "complexity": "simple", + "knowledgeMeta": { + "wikilinks": [], + "content": "---\ntype: defect_template\ntags: [\u7f3a\u9677, \u6d4b\u8bd5, \u6a21\u677f]\naliases: [Bug\u8bb0\u5f55\u6a21\u677f, \u7f3a\u9677\u8bb0\u5f55]\nsource: manual\nstatus: active\nowner: \u6d4b\u8bd5\u8d1f\u8d23\u4eba\nupdated: 2026-05\n---\n\n# \u7f3a\u9677\u8bb0\u5f55\u6a21\u677f\n\n## \u57fa\u672c\u4fe1\u606f\n\n| \u9879\u76ee | \u5185\u5bb9 |\n|---|---|\n| \u7f3a\u9677\u7f16\u53f7 | BUG- |\n| \u9879\u76ee/\u6a21\u5757 | |\n| \u5173\u8054\u9700\u6c42 | |\n| \u5173\u8054\u7528\u4f8b | |\n| \u4e25\u91cd\u7ea7\u522b | |\n| \u5f53\u524d\u72b6\u6001 | open |\n| \u8d1f\u8d23\u4eba | |\n\n## \u95ee\u9898\u63cf\u8ff0\n\n\n## \u590d\u73b0\u6b65\u9aa4\n\n1. \n2. \n3. \n\n## \u5b9e\u9645\u7ed3\u679c\n\n\n## \u9884\u671f\u7ed3\u679c\n\n\n## \u5f71\u54cd\u8303\u56f4\n\n\n## \u4fee\u590d\u7ed3\u8bba\n\n\n## \u56de\u5f52\u9a8c\u8bc1\n\n\n## Agent \u68c0\u7d22\u5b57\u6bb5\n\n- \u5173\u952e\u8bcd\uff1a\n- \u540c\u4e49\u8bcd\uff1a\n- \u5178\u578b\u95ee\u6cd5\uff1a\n", + "backlinks": [ + "article:08_\u6d4b\u8bd5\u76f8\u5173/README" + ] + } + }, + { + "id": "article:08_\u6d4b\u8bd5\u76f8\u5173/\u9a8c\u6536\u8bb0\u5f55\u6a21\u677f", + "type": "article", + "name": "\u9a8c\u6536\u8bb0\u5f55\u6a21\u677f", + "filePath": "08_\u6d4b\u8bd5\u76f8\u5173\\\u9a8c\u6536\u8bb0\u5f55\u6a21\u677f.md", + "summary": "| \u9879\u76ee | \u5185\u5bb9 | |---|---| | \u9879\u76ee/\u6a21\u5757 | | | \u5173\u8054\u9700\u6c42 | | | \u5173\u8054\u6d4b\u8bd5\u7528\u4f8b | | | \u9a8c\u6536\u8d1f\u8d23\u4eba | | | \u9a8c\u6536\u65e5\u671f | | | \u9a8c\u6536\u7ed3\u8bba | |", + "tags": [ + "08_\u6d4b\u8bd5\u76f8\u5173", + "[\u9a8c\u6536", + "\u6a21\u677f]", + "\u6d4b\u8bd5" + ], + "complexity": "simple", + "knowledgeMeta": { + "wikilinks": [], + "content": "---\ntype: acceptance_template\ntags: [\u9a8c\u6536, \u6d4b\u8bd5, \u6a21\u677f]\naliases: [\u9a8c\u6536\u8bb0\u5f55, UAT\u6a21\u677f]\nsource: manual\nstatus: active\nowner: \u6d4b\u8bd5\u8d1f\u8d23\u4eba / \u4e1a\u52a1\u8d1f\u8d23\u4eba\nupdated: 2026-05\n---\n\n# \u9a8c\u6536\u8bb0\u5f55\u6a21\u677f\n\n## \u57fa\u672c\u4fe1\u606f\n\n| \u9879\u76ee | \u5185\u5bb9 |\n|---|---|\n| \u9879\u76ee/\u6a21\u5757 | |\n| \u5173\u8054\u9700\u6c42 | |\n| \u5173\u8054\u6d4b\u8bd5\u7528\u4f8b | |\n| \u9a8c\u6536\u8d1f\u8d23\u4eba | |\n| \u9a8c\u6536\u65e5\u671f | |\n| \u9a8c\u6536\u7ed3\u8bba | |\n\n## \u9a8c\u6536\u8303\u56f4\n\n\n## \u9a8c\u6536\u7ed3\u679c\n\n| \u9a8c\u6536\u9879 | \u9884\u671f\u7ed3\u679c | \u5b9e\u9645\u7ed3\u679c | \u7ed3\u8bba | \u5907\u6ce8 |\n|---|---|---|---|---|\n| | | | | |\n\n## \u9057\u7559\u95ee\u9898\n\n\n## \u4e0a\u7ebf\u5efa\u8bae\n\n\n## Agent \u68c0\u7d22\u5b57\u6bb5\n\n- \u5173\u952e\u8bcd\uff1a\n- \u540c\u4e49\u8bcd\uff1a\n- \u5178\u578b\u95ee\u6cd5\uff1a\n", + "backlinks": [ + "article:08_\u6d4b\u8bd5\u76f8\u5173/README" + ] + } + }, + { + "id": "article:20260517_USER\u8bc4\u4ef7\u4e1a\u52a1\u95ed\u73af_\u5171\u7528\u80fd\u529b\u56fe\u4e0e\u6e20\u9053\u4e13\u5c5e\u6d41\u7a0b_v2.2", + "type": "article", + "name": "20260517_USER\u8bc4\u4ef7\u4e1a\u52a1\u95ed\u73af_\u5171\u7528\u80fd\u529b\u56fe\u4e0e\u6e20\u9053\u4e13\u5c5e\u6d41\u7a0b_v2.2", + "filePath": "20260517_USER\u8bc4\u4ef7\u4e1a\u52a1\u95ed\u73af_\u5171\u7528\u80fd\u529b\u56fe\u4e0e\u6e20\u9053\u4e13\u5c5e\u6d41\u7a0b_v2.2.md", + "summary": "Wiki article: 20260517_USER\u8bc4\u4ef7\u4e1a\u52a1\u95ed\u73af_\u5171\u7528\u80fd\u529b\u56fe\u4e0e\u6e20\u9053\u4e13\u5c5e\u6d41\u7a0b_v2.2", + "tags": [], + "complexity": "simple", + "knowledgeMeta": { + "wikilinks": [], + "content": "", + "backlinks": [] + } + }, + { + "id": "article:\u6b22\u8fce", + "type": "article", + "name": "\u6b22\u8fce\u4f7f\u7528\u5982\u613f\u77e5\u8bc6\u5e93", + "filePath": "\u6b22\u8fce.md", + "summary": "\u8bf7\u4ece [[00_\u9996\u9875/\u77e5\u8bc6\u5e93\u9996\u9875]] \u5f00\u59cb\u3002", + "tags": [ + "[\u77e5\u8bc6\u5e93", + "\u5165\u53e3]" + ], + "complexity": "moderate", + "knowledgeMeta": { + "wikilinks": [ + "00_\u9996\u9875/\u77e5\u8bc6\u5e93\u9996\u9875", + "\u77e5\u8bc6\u5e93\u4f7f\u7528\u8bf4\u660e", + "00_\u9996\u9875/\u77e5\u8bc6\u5730\u56fe", + "00_\u9996\u9875/Agent\u95ee\u7b54\u5165\u53e3", + "05_\u9700\u6c42\u6587\u6863/README", + "06_\u91cc\u7a0b\u7891/README", + "07_\u6280\u672f\u6587\u6863/README", + "08_\u6d4b\u8bd5\u76f8\u5173/README", + "04_Agent\u68c0\u7d22/\u68c0\u7d22\u8bf4\u660e" + ], + "content": "---\ntype: index\ntags: [\u77e5\u8bc6\u5e93, \u5165\u53e3]\naliases: [\u6b22\u8fce, \u9996\u9875]\nsource: manual\nstatus: active\nowner: \u5185\u90e8\u6280\u672f\u56e2\u961f\nupdated: 2026-05\n---\n\n# \u6b22\u8fce\u4f7f\u7528\u5982\u613f\u77e5\u8bc6\u5e93\n\n\u8bf7\u4ece [[00_\u9996\u9875/\u77e5\u8bc6\u5e93\u9996\u9875]] \u5f00\u59cb\u3002\n\n\u5e38\u7528\u5165\u53e3\uff1a\n\n- [[\u77e5\u8bc6\u5e93\u4f7f\u7528\u8bf4\u660e]]\n- [[00_\u9996\u9875/\u77e5\u8bc6\u5730\u56fe]]\n- [[00_\u9996\u9875/Agent\u95ee\u7b54\u5165\u53e3]]\n- [[05_\u9700\u6c42\u6587\u6863/README|\u9700\u6c42\u6587\u6863]]\n- [[06_\u91cc\u7a0b\u7891/README|\u91cc\u7a0b\u7891]]\n- [[07_\u6280\u672f\u6587\u6863/README|\u6280\u672f\u6587\u6863]]\n- [[08_\u6d4b\u8bd5\u76f8\u5173/README|\u6d4b\u8bd5\u76f8\u5173]]\n- [[04_Agent\u68c0\u7d22/\u68c0\u7d22\u8bf4\u660e]]", + "backlinks": [ + "article:\u77e5\u8bc6\u5e93\u4f7f\u7528\u8bf4\u660e" + ] + } + }, + { + "id": "article:\u77e5\u8bc6\u5e93\u4f7f\u7528\u8bf4\u660e", + "type": "article", + "name": "\u5982\u613f\u77e5\u8bc6\u5e93\u4f7f\u7528\u8bf4\u660e", + "filePath": "\u77e5\u8bc6\u5e93\u4f7f\u7528\u8bf4\u660e.md", + "summary": "\u672c\u6587\u6863\u8bf4\u660e\u5982\u613f\u77e5\u8bc6\u5e93\u7684\u7528\u9014\u3001\u76ee\u5f55\u7ed3\u6784\u3001\u6587\u6863\u5b58\u653e\u89c4\u5219\u3001\u7d22\u5f15\u7ef4\u62a4\u89c4\u5219\u3001Obsidian \u56fe\u8c31\u4f7f\u7528\u65b9\u5f0f\uff0c\u4ee5\u53ca Agent \u5982\u4f55\u57fa\u4e8e\u77e5\u8bc6\u5e93\u56de\u7b54\u95ee\u9898\u3002", + "tags": [ + "Agent\u68c0\u7d22]", + "Obsidian", + "[\u77e5\u8bc6\u5e93", + "\u4f7f\u7528\u8bf4\u660e" + ], + "complexity": "complex", + "knowledgeMeta": { + "wikilinks": [ + "\u6b22\u8fce", + "00_\u9996\u9875/\u77e5\u8bc6\u5e93\u9996\u9875", + "00_\u9996\u9875/\u77e5\u8bc6\u5730\u56fe", + "00_\u9996\u9875/Agent\u95ee\u7b54\u5165\u53e3", + "04_Agent\u68c0\u7d22/\u68c0\u7d22\u8bf4\u660e", + "00_\u9996\u9875/\u77e5\u8bc6\u5730\u56fe", + "00_\u9996\u9875/Agent\u95ee\u7b54\u5165\u53e3", + "05_\u9700\u6c42\u6587\u6863/README", + "06_\u91cc\u7a0b\u7891/README", + "07_\u6280\u672f\u6587\u6863/README", + "08_\u6d4b\u8bd5\u76f8\u5173/README", + "02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/AI\u9a71\u52a8\u5185\u90e8\u7cfb\u7edf\u5f00\u53d1\u6d41\u7a0b_V3_\u603b\u89c8", + "04_Agent\u68c0\u7d22/\u68c0\u7d22\u8bf4\u660e", + "04_Agent\u68c0\u7d22/\u6765\u6e90\u6587\u4ef6\u7d22\u5f15", + "05_\u9700\u6c42\u6587\u6863/\u9700\u6c42\u6587\u6863\u7d22\u5f15", + "01_\u4e1a\u52a1\u6d41\u7a0b/\u4e1a\u52a1\u89c4\u5219\u7d22\u5f15", + "01_\u4e1a\u52a1\u6d41\u7a0b/\u4e1a\u52a1\u5bf9\u8c61\u5b57\u5178", + "04_Agent\u68c0\u7d22/\u5173\u952e\u8bcd\u7d22\u5f15", + "04_Agent\u68c0\u7d22/\u6765\u6e90\u6587\u4ef6\u7d22\u5f15", + "06_\u91cc\u7a0b\u7891/\u91cc\u7a0b\u7891\u7d22\u5f15", + "07_\u6280\u672f\u6587\u6863/\u6280\u672f\u6587\u6863\u7d22\u5f15", + "04_Agent\u68c0\u7d22/\u5173\u952e\u8bcd\u7d22\u5f15", + "04_Agent\u68c0\u7d22/\u6765\u6e90\u6587\u4ef6\u7d22\u5f15", + "08_\u6d4b\u8bd5\u76f8\u5173/\u6d4b\u8bd5\u7528\u4f8b\u7d22\u5f15", + "05_\u9700\u6c42\u6587\u6863/\u9700\u6c42\u6587\u6863\u7d22\u5f15", + "07_\u6280\u672f\u6587\u6863/\u6280\u672f\u6587\u6863\u7d22\u5f15", + "08_\u6d4b\u8bd5\u76f8\u5173/\u6d4b\u8bd5\u7528\u4f8b\u7d22\u5f15", + "05_\u9700\u6c42\u6587\u6863/xxx\u9700\u6c42\u6587\u6863", + "07_\u6280\u672f\u6587\u6863/xxx\u6280\u672f\u65b9\u6848", + "08_\u6d4b\u8bd5\u76f8\u5173/xxx\u6d4b\u8bd5\u7528\u4f8b", + "04_Agent\u68c0\u7d22/\u5173\u952e\u8bcd\u7d22\u5f15", + "04_Agent\u68c0\u7d22/\u540c\u4e49\u8bcd\u8868", + "04_Agent\u68c0\u7d22/\u6765\u6e90\u6587\u4ef6\u7d22\u5f15", + "04_Agent\u68c0\u7d22/\u77e5\u8bc6\u5e93\u6301\u7eed\u66f4\u65b0\u4e0e\u9a8c\u8bc1\u6d41\u7a0b" + ], + "content": "---\ntype: knowledge_base_guide\ntags: [\u77e5\u8bc6\u5e93, \u4f7f\u7528\u8bf4\u660e, Obsidian, Agent\u68c0\u7d22]\naliases: [\u5982\u613f\u77e5\u8bc6\u5e93\u4f7f\u7528\u8bf4\u660e, \u77e5\u8bc6\u5e93\u64cd\u4f5c\u8bf4\u660e, \u77e5\u8bc6\u5e93\u7ef4\u62a4\u8bf4\u660e]\nsource: manual\nstatus: active\nowner: \u5185\u90e8\u6280\u672f\u56e2\u961f\nupdated: 2026-05\n---\n\n# \u5982\u613f\u77e5\u8bc6\u5e93\u4f7f\u7528\u8bf4\u660e\n\n\u672c\u6587\u6863\u8bf4\u660e\u5982\u613f\u77e5\u8bc6\u5e93\u7684\u7528\u9014\u3001\u76ee\u5f55\u7ed3\u6784\u3001\u6587\u6863\u5b58\u653e\u89c4\u5219\u3001\u7d22\u5f15\u7ef4\u62a4\u89c4\u5219\u3001Obsidian \u56fe\u8c31\u4f7f\u7528\u65b9\u5f0f\uff0c\u4ee5\u53ca Agent \u5982\u4f55\u57fa\u4e8e\u77e5\u8bc6\u5e93\u56de\u7b54\u95ee\u9898\u3002\n\n## 1. \u77e5\u8bc6\u5e93\u5b9a\u4f4d\n\n\u5982\u613f\u77e5\u8bc6\u5e93\u7528\u4e8e\u6c89\u6dc0\u5185\u90e8\u7cfb\u7edf\u5efa\u8bbe\u8fc7\u7a0b\u4e2d\u7684\uff1a\n\n- \u4e1a\u52a1\u9700\u6c42\n- \u4e1a\u52a1\u89c4\u5219\n- \u4e1a\u52a1\u6d41\u7a0b\n- \u9879\u76ee\u91cc\u7a0b\u7891\n- \u6280\u672f\u65b9\u6848\n- \u6d4b\u8bd5\u7528\u4f8b\n- \u7f3a\u9677\u4e0e\u9a8c\u6536\u8bb0\u5f55\n- Agent \u68c0\u7d22\u89c4\u5219\n\n\u77e5\u8bc6\u5e93\u4e0d\u662f\u5355\u7eaf\u5b58\u6587\u4ef6\uff0c\u800c\u662f\u8981\u5f62\u6210\u53ef\u68c0\u7d22\u3001\u53ef\u8ffd\u6eaf\u3001\u53ef\u88ab Agent \u5f15\u7528\u56de\u7b54\u7684\u77e5\u8bc6\u7f51\u7edc\u3002\n\n## 2. \u63a8\u8350\u6253\u5f00\u65b9\u5f0f\n\n\u63a8\u8350\u4f7f\u7528 Obsidian \u6253\u5f00\u4ee5\u4e0b\u76ee\u5f55\u4f5c\u4e3a Vault\uff1a\n\n```text\nD:\\AIcoding\\WishFulfilled\\\u77e5\u8bc6\u5e93\\\u5982\u613f\u77e5\u8bc6\u5e93\n```\n\n\u6253\u5f00\u540e\u5efa\u8bae\u4ece\u4ee5\u4e0b\u5165\u53e3\u5f00\u59cb\uff1a\n\n1. [[\u6b22\u8fce]]\n2. [[00_\u9996\u9875/\u77e5\u8bc6\u5e93\u9996\u9875]]\n3. [[00_\u9996\u9875/\u77e5\u8bc6\u5730\u56fe]]\n4. [[00_\u9996\u9875/Agent\u95ee\u7b54\u5165\u53e3]]\n5. [[04_Agent\u68c0\u7d22/\u68c0\u7d22\u8bf4\u660e]]\n\n## 3. \u4e3b\u76ee\u5f55\u8bf4\u660e\n\n```text\n\u5982\u613f\u77e5\u8bc6\u5e93/\n\u251c\u2500 00_\u9996\u9875/ # \u9996\u9875\u3001\u77e5\u8bc6\u5730\u56fe\u3001Agent \u95ee\u7b54\u5165\u53e3\n\u251c\u2500 01_\u4e1a\u52a1\u6d41\u7a0b/ # \u4e1a\u52a1\u6d41\u7a0b\u3001\u4e1a\u52a1\u5bf9\u8c61\u3001\u4e1a\u52a1\u89c4\u5219\u3001\u8865\u5145\u9a8c\u8bc1\u8bb0\u5f55\n\u251c\u2500 02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/ # \u9879\u76ee\u9636\u6bb5\u3001\u89d2\u8272\u804c\u8d23\u3001\u4ea4\u4ed8\u7269\u3001\u68c0\u67e5\u6e05\u5355\u3001FAQ\n\u251c\u2500 03_\u89c4\u8303\u4e0e\u6a21\u677f/ # \u9700\u6c42\u3001\u4e1a\u52a1\u89c4\u5219\u3001\u4f1a\u8bae\u3001\u4e0a\u7ebf\u68c0\u67e5\u7b49\u6a21\u677f\n\u251c\u2500 04_Agent\u68c0\u7d22/ # \u68c0\u7d22\u8bf4\u660e\u3001\u5173\u952e\u8bcd\u3001\u540c\u4e49\u8bcd\u3001\u6765\u6e90\u6587\u4ef6\u7d22\u5f15\n\u251c\u2500 05_\u9700\u6c42\u6587\u6863/ # \u6b63\u5f0f\u9700\u6c42\u6587\u6863\u3001\u9700\u6c42\u7d22\u5f15\n\u251c\u2500 06_\u91cc\u7a0b\u7891/ # \u91cc\u7a0b\u7891\u8ba1\u5212\u3001\u9636\u6bb5\u8ba1\u5212\u3001\u8bc4\u5ba1\u8bb0\u5f55\n\u251c\u2500 07_\u6280\u672f\u6587\u6863/ # \u6280\u672f\u65b9\u6848\u3001\u7cfb\u7edf\u67b6\u6784\u3001\u63a5\u53e3\u8bf4\u660e\u3001\u6280\u672f\u51b3\u7b56\n\u251c\u2500 08_\u6d4b\u8bd5\u76f8\u5173/ # \u6d4b\u8bd5\u7528\u4f8b\u3001\u6d4b\u8bd5\u8ba1\u5212\u3001\u7f3a\u9677\u3001\u9a8c\u6536\u3001\u4e0a\u7ebf\u68c0\u67e5\n\u251c\u2500 99_\u5f52\u6863/ # \u5386\u53f2\u6587\u6863\u3001\u5e9f\u5f03\u6587\u6863\u3001\u4ec5\u4f9b\u53c2\u8003\u5185\u5bb9\n\u251c\u2500 \u6b22\u8fce.md # Obsidian \u5165\u53e3\u9875\n\u251c\u2500 \u77e5\u8bc6\u5e93\u4f7f\u7528\u8bf4\u660e.md # \u672c\u6587\u6863\n\u2514\u2500 Git\u4f7f\u7528\u8bf4\u660e.md # Git \u4ed3\u5e93\u534f\u4f5c\u8bf4\u660e\n```\n\n## 4. \u65e5\u5e38\u4f7f\u7528\u5165\u53e3\n\n| \u4f7f\u7528\u573a\u666f | \u4f18\u5148\u5165\u53e3 |\n|---|---|\n| \u60f3\u4e86\u89e3\u77e5\u8bc6\u5e93\u6574\u4f53\u7ed3\u6784 | [[00_\u9996\u9875/\u77e5\u8bc6\u5730\u56fe]] |\n| \u60f3\u8ba9 Agent \u56de\u7b54\u4e1a\u52a1\u95ee\u9898 | [[00_\u9996\u9875/Agent\u95ee\u7b54\u5165\u53e3]] |\n| \u67e5\u770b\u6216\u65b0\u589e\u9700\u6c42 | [[05_\u9700\u6c42\u6587\u6863/README]] |\n| \u67e5\u770b\u6216\u65b0\u589e\u91cc\u7a0b\u7891 | [[06_\u91cc\u7a0b\u7891/README]] |\n| \u67e5\u770b\u6216\u65b0\u589e\u6280\u672f\u65b9\u6848 | [[07_\u6280\u672f\u6587\u6863/README]] |\n| \u67e5\u770b\u6216\u65b0\u589e\u6d4b\u8bd5\u7528\u4f8b | [[08_\u6d4b\u8bd5\u76f8\u5173/README]] |\n| \u67e5\u770b\u9879\u76ee\u7ba1\u7406\u9636\u6bb5 | [[02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/AI\u9a71\u52a8\u5185\u90e8\u7cfb\u7edf\u5f00\u53d1\u6d41\u7a0b_V3_\u603b\u89c8]] |\n| \u67e5\u770b Agent \u68c0\u7d22\u89c4\u5219 | [[04_Agent\u68c0\u7d22/\u68c0\u7d22\u8bf4\u660e]] |\n| \u67e5\u770b\u6765\u6e90\u4f9d\u636e | [[04_Agent\u68c0\u7d22/\u6765\u6e90\u6587\u4ef6\u7d22\u5f15]] |\n\n## 5. \u6587\u6863\u5e94\u8be5\u653e\u5728\u54ea\u91cc\n\n### 5.1 \u9700\u6c42\u6587\u6863\n\n\u653e\u5165\uff1a\n\n```text\n05_\u9700\u6c42\u6587\u6863/\n```\n\n\u9002\u5408\u5b58\u653e\uff1a\n\n- \u6b63\u5f0f\u9700\u6c42\u8bf4\u660e\n- \u4e1a\u52a1\u89c4\u5219\u8bf4\u660e\n- \u9700\u6c42\u53d8\u66f4\u8bf4\u660e\n- \u4e1a\u52a1\u8865\u5145\u8bf4\u660e\n- \u4ea7\u54c1\u53e3\u5f84\u8bf4\u660e\n\n\u63a8\u8350\u547d\u540d\uff1a\n\n```text\n\u4e1a\u52a1\u57df_\u9700\u6c42\u6216\u89c4\u5219\u540d\u79f0_YYYYMMDD.md\n```\n\n\u793a\u4f8b\uff1a\n\n```text\nUSER\u8bc4\u4ef7\u4e1a\u52a1\u95ed\u73af_\u6570\u636e\u6d41\u4e0e\u4e2d\u95f4\u5bf9\u8c61\u8bbe\u8ba1_20260517.md\n\u91c7\u8d2d_\u4f9b\u5e94\u5546\u51c6\u5165\u89c4\u5219_20260526.md\n\u5e93\u5b58_\u51fa\u5165\u5e93\u5ba1\u6279\u89c4\u5219_20260526.md\n```\n\n\u65b0\u589e\u540e\u5e94\u540c\u6b65\u7ef4\u62a4\uff1a\n\n- [[05_\u9700\u6c42\u6587\u6863/\u9700\u6c42\u6587\u6863\u7d22\u5f15]]\n- [[01_\u4e1a\u52a1\u6d41\u7a0b/\u4e1a\u52a1\u89c4\u5219\u7d22\u5f15]]\uff0c\u5982\u6d89\u53ca\u4e1a\u52a1\u89c4\u5219\n- [[01_\u4e1a\u52a1\u6d41\u7a0b/\u4e1a\u52a1\u5bf9\u8c61\u5b57\u5178]]\uff0c\u5982\u6d89\u53ca\u65b0\u589e\u4e1a\u52a1\u5bf9\u8c61\n- [[04_Agent\u68c0\u7d22/\u5173\u952e\u8bcd\u7d22\u5f15]]\uff0c\u5982\u9700\u8981 Agent \u68c0\u7d22\u547d\u4e2d\n- [[04_Agent\u68c0\u7d22/\u6765\u6e90\u6587\u4ef6\u7d22\u5f15]]\uff0c\u5982\u662f\u65b0\u7684\u6743\u5a01\u6765\u6e90\n\n### 5.2 \u91cc\u7a0b\u7891\u6587\u6863\n\n\u653e\u5165\uff1a\n\n```text\n06_\u91cc\u7a0b\u7891/\n```\n\n\u9002\u5408\u5b58\u653e\uff1a\n\n- \u9879\u76ee\u91cc\u7a0b\u7891\u8ba1\u5212\n- \u9636\u6bb5\u8ba1\u5212\n- \u9636\u6bb5\u8bc4\u5ba1\u8bb0\u5f55\n- \u4e0a\u7ebf\u8282\u594f\n- \u51c6\u5165/\u51c6\u51fa\u8bb0\u5f55\n\n\u63a8\u8350\u547d\u540d\uff1a\n\n```text\n\u9879\u76ee\u540d_\u91cc\u7a0b\u7891\u8ba1\u5212_YYYYMMDD.md\n\u9879\u76ee\u540d_\u9636\u6bb5\u8bc4\u5ba1\u8bb0\u5f55_YYYYMMDD.md\n```\n\n\u65b0\u589e\u540e\u5e94\u540c\u6b65\u7ef4\u62a4\uff1a\n\n- [[06_\u91cc\u7a0b\u7891/\u91cc\u7a0b\u7891\u7d22\u5f15]]\n\n### 5.3 \u6280\u672f\u6587\u6863\n\n\u653e\u5165\uff1a\n\n```text\n07_\u6280\u672f\u6587\u6863/\n```\n\n\u9002\u5408\u5b58\u653e\uff1a\n\n- \u7cfb\u7edf\u67b6\u6784\u8bf4\u660e\n- \u6570\u636e\u6a21\u578b\u8bf4\u660e\n- \u63a5\u53e3\u8bf4\u660e\n- \u6a21\u5757\u8bbe\u8ba1\n- \u6280\u672f\u65b9\u6848\n- \u90e8\u7f72\u8bf4\u660e\n- \u6280\u672f\u51b3\u7b56\u8bb0\u5f55\n\n\u63a8\u8350\u547d\u540d\uff1a\n\n```text\n\u7cfb\u7edf\u6216\u6a21\u5757_\u6280\u672f\u65b9\u6848_YYYYMMDD.md\n\u7cfb\u7edf\u6216\u6a21\u5757_\u63a5\u53e3\u8bf4\u660e_YYYYMMDD.md\n\u7cfb\u7edf\u6216\u6a21\u5757_\u6570\u636e\u6a21\u578b_YYYYMMDD.md\n```\n\n\u65b0\u589e\u540e\u5e94\u540c\u6b65\u7ef4\u62a4\uff1a\n\n- [[07_\u6280\u672f\u6587\u6863/\u6280\u672f\u6587\u6863\u7d22\u5f15]]\n- [[04_Agent\u68c0\u7d22/\u5173\u952e\u8bcd\u7d22\u5f15]]\uff0c\u5982\u9700\u8981 Agent \u68c0\u7d22\n- [[04_Agent\u68c0\u7d22/\u6765\u6e90\u6587\u4ef6\u7d22\u5f15]]\uff0c\u5982\u662f\u65b0\u7684\u6280\u672f\u4f9d\u636e\n\n### 5.4 \u6d4b\u8bd5\u76f8\u5173\u6587\u6863\n\n\u653e\u5165\uff1a\n\n```text\n08_\u6d4b\u8bd5\u76f8\u5173/\n```\n\n\u9002\u5408\u5b58\u653e\uff1a\n\n- \u6d4b\u8bd5\u8ba1\u5212\n- \u6d4b\u8bd5\u7528\u4f8b\n- \u7f3a\u9677\u8bb0\u5f55\n- \u9a8c\u6536\u8bb0\u5f55\n- \u4e0a\u7ebf\u68c0\u67e5\n- \u56de\u5f52\u6d4b\u8bd5\u8bb0\u5f55\n\n\u63a8\u8350\u547d\u540d\uff1a\n\n```text\n\u9879\u76ee\u540d_\u6a21\u5757\u540d_\u6d4b\u8bd5\u8ba1\u5212_YYYYMMDD.md\n\u9879\u76ee\u540d_\u6a21\u5757\u540d_\u6d4b\u8bd5\u7528\u4f8b_YYYYMMDD.md\n\u9879\u76ee\u540d_\u6a21\u5757\u540d_\u7f3a\u9677\u8bb0\u5f55_YYYYMMDD.md\n\u9879\u76ee\u540d_\u6a21\u5757\u540d_\u9a8c\u6536\u8bb0\u5f55_YYYYMMDD.md\n```\n\n\u65b0\u589e\u540e\u5e94\u540c\u6b65\u7ef4\u62a4\uff1a\n\n- [[08_\u6d4b\u8bd5\u76f8\u5173/\u6d4b\u8bd5\u7528\u4f8b\u7d22\u5f15]]\n- \u5173\u8054\u9700\u6c42\u6587\u6863\n- \u5173\u8054\u91cc\u7a0b\u7891\u6216\u6d4b\u8bd5\u9636\u6bb5\n\n\u6d4b\u8bd5\u7528\u4f8b\u5fc5\u987b\u80fd\u8ffd\u6eaf\u5230\u9700\u6c42\u6765\u6e90\u3002\n\n### 5.5 \u4e1a\u52a1\u6d41\u7a0b\u6587\u6863\n\n\u653e\u5165\uff1a\n\n```text\n01_\u4e1a\u52a1\u6d41\u7a0b/\n```\n\n\u9002\u5408\u5b58\u653e\uff1a\n\n- \u5df2\u7a33\u5b9a\u7684\u4e1a\u52a1\u6d41\u7a0b\n- \u4e1a\u52a1\u5bf9\u8c61\u5b9a\u4e49\n- \u4e1a\u52a1\u89c4\u5219\u7d22\u5f15\n- \u4e1a\u52a1\u8865\u5145\u9a8c\u8bc1\u8bb0\u5f55\n\n\u5982\u679c\u662f\u65b0\u9700\u6c42\u6216\u5c1a\u672a\u786e\u8ba4\u7684\u4e1a\u52a1\u89c4\u5219\uff0c\u4f18\u5148\u653e\u5165 `05_\u9700\u6c42\u6587\u6863/`\uff0c\u786e\u8ba4\u7a33\u5b9a\u540e\u518d\u6c89\u6dc0\u5230 `01_\u4e1a\u52a1\u6d41\u7a0b/`\u3002\n\n### 5.6 \u6a21\u677f\u6587\u6863\n\n\u653e\u5165\uff1a\n\n```text\n03_\u89c4\u8303\u4e0e\u6a21\u677f/\n```\n\n\u9002\u5408\u5b58\u653e\uff1a\n\n- \u9700\u6c42\u8bf4\u660e\u6a21\u677f\n- \u4e1a\u52a1\u89c4\u5219\u8865\u5145\u6a21\u677f\n- \u4f1a\u8bae\u7eaa\u8981\u6a21\u677f\n- \u4e0a\u7ebf\u68c0\u67e5\u6a21\u677f\n- \u901a\u7528\u6587\u6863\u6a21\u677f\n\n\u6a21\u677f\u53ea\u7528\u4e8e\u590d\u7528\u683c\u5f0f\uff0c\u4e0d\u5e94\u5b58\u653e\u5177\u4f53\u9879\u76ee\u5185\u5bb9\u3002\n\n### 5.7 \u5f52\u6863\u6587\u6863\n", + "backlinks": [ + "article:\u6b22\u8fce" + ] + } + }, + { + "id": "topic:\u4f7f\u7528\u8bf4\u660e", + "type": "topic", + "name": "\u4f7f\u7528\u8bf4\u660e", + "summary": "Category from index: \u4f7f\u7528\u8bf4\u660e (2 articles)", + "tags": [ + "category" + ], + "complexity": "simple" + }, + { + "id": "topic:\u9700\u6c42\u6587\u6863", + "type": "topic", + "name": "\u9700\u6c42\u6587\u6863", + "summary": "Category from index: \u9700\u6c42\u6587\u6863 (6 articles)", + "tags": [ + "category" + ], + "complexity": "simple" + }, + { + "id": "topic:\u91cc\u7a0b\u7891", + "type": "topic", + "name": "\u91cc\u7a0b\u7891", + "summary": "Category from index: \u91cc\u7a0b\u7891 (7 articles)", + "tags": [ + "category" + ], + "complexity": "simple" + }, + { + "id": "topic:\u6280\u672f\u6587\u6863", + "type": "topic", + "name": "\u6280\u672f\u6587\u6863", + "summary": "Category from index: \u6280\u672f\u6587\u6863 (5 articles)", + "tags": [ + "category" + ], + "complexity": "simple" + }, + { + "id": "topic:\u6d4b\u8bd5\u76f8\u5173", + "type": "topic", + "name": "\u6d4b\u8bd5\u76f8\u5173", + "summary": "Category from index: \u6d4b\u8bd5\u76f8\u5173 (9 articles)", + "tags": [ + "category" + ], + "complexity": "simple" + }, + { + "id": "topic:agent-\u68c0\u7d22", + "type": "topic", + "name": "Agent \u68c0\u7d22", + "summary": "Category from index: Agent \u68c0\u7d22 (6 articles)", + "tags": [ + "category" + ], + "complexity": "simple" + }, + { + "id": "source:AI_\u9a71\u52a8_\u5185\u90e8\u7cfb\u7edf\u5f00\u53d1\u6d41\u7a0b_V3", + "type": "source", + "name": "AI_\u9a71\u52a8_\u5185\u90e8\u7cfb\u7edf\u5f00\u53d1\u6d41\u7a0b_V3.docx", + "filePath": "raw\\AI_\u9a71\u52a8_\u5185\u90e8\u7cfb\u7edf\u5f00\u53d1\u6d41\u7a0b_V3.docx", + "summary": "Raw source (.docx, 36 KB)", + "tags": [ + "raw", + "docx" + ], + "complexity": "simple" + } + ], + "edges": [ + { + "source": "article:00_\u9996\u9875/\u77e5\u8bc6\u5e93\u9996\u9875", + "target": "article:00_\u9996\u9875/\u77e5\u8bc6\u5730\u56fe", + "type": "related", + "direction": "forward", + "weight": 0.7 + }, + { + "source": "article:00_\u9996\u9875/\u77e5\u8bc6\u5e93\u9996\u9875", + "target": "article:00_\u9996\u9875/Agent\u95ee\u7b54\u5165\u53e3", + "type": "related", + "direction": "forward", + "weight": 0.7 + }, + { + "source": "article:01_\u4e1a\u52a1\u6d41\u7a0b/README", + "target": "article:01_\u4e1a\u52a1\u6d41\u7a0b/\u4e1a\u52a1\u6d41\u7a0b\u6a21\u677f", + "type": "related", + "direction": "forward", + "weight": 0.7 + }, + { + "source": "article:01_\u4e1a\u52a1\u6d41\u7a0b/README", + "target": "article:01_\u4e1a\u52a1\u6d41\u7a0b/\u4e1a\u52a1\u5bf9\u8c61\u5b57\u5178", + "type": "related", + "direction": "forward", + "weight": 0.7 + }, + { + "source": "article:01_\u4e1a\u52a1\u6d41\u7a0b/README", + "target": "article:01_\u4e1a\u52a1\u6d41\u7a0b/\u4e1a\u52a1\u89c4\u5219\u7d22\u5f15", + "type": "related", + "direction": "forward", + "weight": 0.7 + }, + { + "source": "article:02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/AI\u9a71\u52a8\u5185\u90e8\u7cfb\u7edf\u5f00\u53d1\u6d41\u7a0b_V3_\u603b\u89c8", + "target": "article:02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/\u9636\u6bb50_\u9879\u76ee\u5165\u53e3\u5206\u7ea7", + "type": "related", + "direction": "forward", + "weight": 0.7 + }, + { + "source": "article:02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/AI\u9a71\u52a8\u5185\u90e8\u7cfb\u7edf\u5f00\u53d1\u6d41\u7a0b_V3_\u603b\u89c8", + "target": "article:02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/\u9636\u6bb51_\u4e1a\u52a1\u9700\u6c42\u5b8c\u6574\u5f62\u6210", + "type": "related", + "direction": "forward", + "weight": 0.7 + }, + { + "source": "article:02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/AI\u9a71\u52a8\u5185\u90e8\u7cfb\u7edf\u5f00\u53d1\u6d41\u7a0b_V3_\u603b\u89c8", + "target": "article:02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/\u9636\u6bb52_\u9ad8\u4fdd\u771f\u6a21\u578b\u4e0e\u4e1a\u52a1\u5bf9\u8c61\u786e\u8ba4", + "type": "related", + "direction": "forward", + "weight": 0.7 + }, + { + "source": "article:02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/AI\u9a71\u52a8\u5185\u90e8\u7cfb\u7edf\u5f00\u53d1\u6d41\u7a0b_V3_\u603b\u89c8", + "target": "article:02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/\u9636\u6bb52.5_\u6d4b\u8bd5\u63d0\u524d\u8865\u6f0f", + "type": "related", + "direction": "forward", + "weight": 0.7 + }, + { + "source": "article:02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/AI\u9a71\u52a8\u5185\u90e8\u7cfb\u7edf\u5f00\u53d1\u6d41\u7a0b_V3_\u603b\u89c8", + "target": "article:02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/\u9636\u6bb53_\u7814\u53d1\u534f\u4f5c\u4e0e\u6b63\u5f0f\u5f00\u53d1", + "type": "related", + "direction": "forward", + "weight": 0.7 + }, + { + "source": "article:02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/AI\u9a71\u52a8\u5185\u90e8\u7cfb\u7edf\u5f00\u53d1\u6d41\u7a0b_V3_\u603b\u89c8", + "target": "article:02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/\u9636\u6bb54_\u6d4b\u8bd5\u57f9\u8bad\u4e0a\u7ebf\u56de\u6d41", + "type": "related", + "direction": "forward", + "weight": 0.7 + }, + { + "source": "article:02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/AI\u9a71\u52a8\u5185\u90e8\u7cfb\u7edf\u5f00\u53d1\u6d41\u7a0b_V3_\u603b\u89c8", + "target": "article:02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/\u89d2\u8272\u804c\u8d23\u77e9\u9635", + "type": "related", + "direction": "forward", + "weight": 0.7 + }, + { + "source": "article:02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/AI\u9a71\u52a8\u5185\u90e8\u7cfb\u7edf\u5f00\u53d1\u6d41\u7a0b_V3_\u603b\u89c8", + "target": "article:02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/\u9636\u6bb5\u4ea4\u4ed8\u7269\u6e05\u5355", + "type": "related", + "direction": "forward", + "weight": 0.7 + }, + { + "source": "article:02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/AI\u9a71\u52a8\u5185\u90e8\u7cfb\u7edf\u5f00\u53d1\u6d41\u7a0b_V3_\u603b\u89c8", + "target": "article:02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/\u9879\u76ee\u68c0\u67e5\u6e05\u5355", + "type": "related", + "direction": "forward", + "weight": 0.7 + }, + { + "source": "article:02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/README", + "target": "article:02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/AI\u9a71\u52a8\u5185\u90e8\u7cfb\u7edf\u5f00\u53d1\u6d41\u7a0b_V3_\u603b\u89c8", + "type": "related", + "direction": "forward", + "weight": 0.7 + }, + { + "source": "article:02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/README", + "target": "article:02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/\u9636\u6bb50_\u9879\u76ee\u5165\u53e3\u5206\u7ea7", + "type": "related", + "direction": "forward", + "weight": 0.7 + }, + { + "source": "article:02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/README", + "target": "article:02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/\u9636\u6bb51_\u4e1a\u52a1\u9700\u6c42\u5b8c\u6574\u5f62\u6210", + "type": "related", + "direction": "forward", + "weight": 0.7 + }, + { + "source": "article:02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/README", + "target": "article:02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/\u9636\u6bb52_\u9ad8\u4fdd\u771f\u6a21\u578b\u4e0e\u4e1a\u52a1\u5bf9\u8c61\u786e\u8ba4", + "type": "related", + "direction": "forward", + "weight": 0.7 + }, + { + "source": "article:02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/README", + "target": "article:02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/\u9636\u6bb52.5_\u6d4b\u8bd5\u63d0\u524d\u8865\u6f0f", + "type": "related", + "direction": "forward", + "weight": 0.7 + }, + { + "source": "article:02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/README", + "target": "article:02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/\u9636\u6bb53_\u7814\u53d1\u534f\u4f5c\u4e0e\u6b63\u5f0f\u5f00\u53d1", + "type": "related", + "direction": "forward", + "weight": 0.7 + }, + { + "source": "article:02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/README", + "target": "article:02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/\u9636\u6bb54_\u6d4b\u8bd5\u57f9\u8bad\u4e0a\u7ebf\u56de\u6d41", + "type": "related", + "direction": "forward", + "weight": 0.7 + }, + { + "source": "article:02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/README", + "target": "article:02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/\u89d2\u8272\u804c\u8d23\u77e9\u9635", + "type": "related", + "direction": "forward", + "weight": 0.7 + }, + { + "source": "article:02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/README", + "target": "article:02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/\u9636\u6bb5\u4ea4\u4ed8\u7269\u6e05\u5355", + "type": "related", + "direction": "forward", + "weight": 0.7 + }, + { + "source": "article:02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/README", + "target": "article:02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/\u9879\u76ee\u68c0\u67e5\u6e05\u5355", + "type": "related", + "direction": "forward", + "weight": 0.7 + }, + { + "source": "article:02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/README", + "target": "article:02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/\u5e38\u89c1\u95ee\u9898FAQ", + "type": "related", + "direction": "forward", + "weight": 0.7 + }, + { + "source": "article:02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/\u5e38\u89c1\u95ee\u9898FAQ", + "target": "article:02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/AI\u9a71\u52a8\u5185\u90e8\u7cfb\u7edf\u5f00\u53d1\u6d41\u7a0b_V3_\u603b\u89c8", + "type": "related", + "direction": "forward", + "weight": 0.7 + }, + { + "source": "article:02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/\u5e38\u89c1\u95ee\u9898FAQ", + "target": "article:02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/\u9636\u6bb50_\u9879\u76ee\u5165\u53e3\u5206\u7ea7", + "type": "related", + "direction": "forward", + "weight": 0.7 + }, + { + "source": "article:02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/\u5e38\u89c1\u95ee\u9898FAQ", + "target": "article:02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/\u89d2\u8272\u804c\u8d23\u77e9\u9635", + "type": "related", + "direction": "forward", + "weight": 0.7 + }, + { + "source": "article:02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/\u5e38\u89c1\u95ee\u9898FAQ", + "target": "article:02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/\u9636\u6bb51_\u4e1a\u52a1\u9700\u6c42\u5b8c\u6574\u5f62\u6210", + "type": "related", + "direction": "forward", + "weight": 0.7 + }, + { + "source": "article:02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/\u5e38\u89c1\u95ee\u9898FAQ", + "target": "article:02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/\u9636\u6bb52.5_\u6d4b\u8bd5\u63d0\u524d\u8865\u6f0f", + "type": "related", + "direction": "forward", + "weight": 0.7 + }, + { + "source": "article:02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/\u5e38\u89c1\u95ee\u9898FAQ", + "target": "article:02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/\u9636\u6bb5\u4ea4\u4ed8\u7269\u6e05\u5355", + "type": "related", + "direction": "forward", + "weight": 0.7 + }, + { + "source": "article:02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/\u5e38\u89c1\u95ee\u9898FAQ", + "target": "article:02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/\u9636\u6bb52_\u9ad8\u4fdd\u771f\u6a21\u578b\u4e0e\u4e1a\u52a1\u5bf9\u8c61\u786e\u8ba4", + "type": "related", + "direction": "forward", + "weight": 0.7 + }, + { + "source": "article:02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/\u5e38\u89c1\u95ee\u9898FAQ", + "target": "article:02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/\u9636\u6bb53_\u7814\u53d1\u534f\u4f5c\u4e0e\u6b63\u5f0f\u5f00\u53d1", + "type": "related", + "direction": "forward", + "weight": 0.7 + }, + { + "source": "article:02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/\u5e38\u89c1\u95ee\u9898FAQ", + "target": "article:02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/\u9636\u6bb54_\u6d4b\u8bd5\u57f9\u8bad\u4e0a\u7ebf\u56de\u6d41", + "type": "related", + "direction": "forward", + "weight": 0.7 + }, + { + "source": "article:02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/\u5e38\u89c1\u95ee\u9898FAQ", + "target": "article:02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/\u9879\u76ee\u68c0\u67e5\u6e05\u5355", + "type": "related", + "direction": "forward", + "weight": 0.7 + }, + { + "source": "article:02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/\u89d2\u8272\u804c\u8d23\u77e9\u9635", + "target": "article:02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/AI\u9a71\u52a8\u5185\u90e8\u7cfb\u7edf\u5f00\u53d1\u6d41\u7a0b_V3_\u603b\u89c8", + "type": "related", + "direction": "forward", + "weight": 0.7 + }, + { + "source": "article:02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/\u89d2\u8272\u804c\u8d23\u77e9\u9635", + "target": "article:02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/\u9636\u6bb50_\u9879\u76ee\u5165\u53e3\u5206\u7ea7", + "type": "related", + "direction": "forward", + "weight": 0.7 + }, + { + "source": "article:02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/\u89d2\u8272\u804c\u8d23\u77e9\u9635", + "target": "article:02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/\u9636\u6bb51_\u4e1a\u52a1\u9700\u6c42\u5b8c\u6574\u5f62\u6210", + "type": "related", + "direction": "forward", + "weight": 0.7 + }, + { + "source": "article:02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/\u89d2\u8272\u804c\u8d23\u77e9\u9635", + "target": "article:02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/\u9636\u6bb52.5_\u6d4b\u8bd5\u63d0\u524d\u8865\u6f0f", + "type": "related", + "direction": "forward", + "weight": 0.7 + }, + { + "source": "article:02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/\u89d2\u8272\u804c\u8d23\u77e9\u9635", + "target": "article:02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/\u9636\u6bb54_\u6d4b\u8bd5\u57f9\u8bad\u4e0a\u7ebf\u56de\u6d41", + "type": "related", + "direction": "forward", + "weight": 0.7 + }, + { + "source": "article:02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/\u9636\u6bb50_\u9879\u76ee\u5165\u53e3\u5206\u7ea7", + "target": "article:02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/AI\u9a71\u52a8\u5185\u90e8\u7cfb\u7edf\u5f00\u53d1\u6d41\u7a0b_V3_\u603b\u89c8", + "type": "related", + "direction": "forward", + "weight": 0.7 + }, + { + "source": "article:02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/\u9636\u6bb50_\u9879\u76ee\u5165\u53e3\u5206\u7ea7", + "target": "article:02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/\u89d2\u8272\u804c\u8d23\u77e9\u9635", + "type": "related", + "direction": "forward", + "weight": 0.7 + }, + { + "source": "article:02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/\u9636\u6bb50_\u9879\u76ee\u5165\u53e3\u5206\u7ea7", + "target": "article:02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/\u9636\u6bb5\u4ea4\u4ed8\u7269\u6e05\u5355", + "type": "related", + "direction": "forward", + "weight": 0.7 + }, + { + "source": "article:02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/\u9636\u6bb51_\u4e1a\u52a1\u9700\u6c42\u5b8c\u6574\u5f62\u6210", + "target": "article:02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/\u9636\u6bb50_\u9879\u76ee\u5165\u53e3\u5206\u7ea7", + "type": "related", + "direction": "forward", + "weight": 0.7 + }, + { + "source": "article:02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/\u9636\u6bb51_\u4e1a\u52a1\u9700\u6c42\u5b8c\u6574\u5f62\u6210", + "target": "article:02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/\u9636\u6bb52_\u9ad8\u4fdd\u771f\u6a21\u578b\u4e0e\u4e1a\u52a1\u5bf9\u8c61\u786e\u8ba4", + "type": "related", + "direction": "forward", + "weight": 0.7 + }, + { + "source": "article:02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/\u9636\u6bb51_\u4e1a\u52a1\u9700\u6c42\u5b8c\u6574\u5f62\u6210", + "target": "article:02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/\u89d2\u8272\u804c\u8d23\u77e9\u9635", + "type": "related", + "direction": "forward", + "weight": 0.7 + }, + { + "source": "article:02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/\u9636\u6bb51_\u4e1a\u52a1\u9700\u6c42\u5b8c\u6574\u5f62\u6210", + "target": "article:02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/\u9636\u6bb5\u4ea4\u4ed8\u7269\u6e05\u5355", + "type": "related", + "direction": "forward", + "weight": 0.7 + }, + { + "source": "article:02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/\u9636\u6bb52.5_\u6d4b\u8bd5\u63d0\u524d\u8865\u6f0f", + "target": "article:02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/\u9636\u6bb52_\u9ad8\u4fdd\u771f\u6a21\u578b\u4e0e\u4e1a\u52a1\u5bf9\u8c61\u786e\u8ba4", + "type": "related", + "direction": "forward", + "weight": 0.7 + }, + { + "source": "article:02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/\u9636\u6bb52.5_\u6d4b\u8bd5\u63d0\u524d\u8865\u6f0f", + "target": "article:02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/\u9636\u6bb53_\u7814\u53d1\u534f\u4f5c\u4e0e\u6b63\u5f0f\u5f00\u53d1", + "type": "related", + "direction": "forward", + "weight": 0.7 + }, + { + "source": "article:02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/\u9636\u6bb52.5_\u6d4b\u8bd5\u63d0\u524d\u8865\u6f0f", + "target": "article:02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/\u9879\u76ee\u68c0\u67e5\u6e05\u5355", + "type": "related", + "direction": "forward", + "weight": 0.7 + }, + { + "source": "article:02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/\u9636\u6bb52_\u9ad8\u4fdd\u771f\u6a21\u578b\u4e0e\u4e1a\u52a1\u5bf9\u8c61\u786e\u8ba4", + "target": "article:02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/\u9636\u6bb51_\u4e1a\u52a1\u9700\u6c42\u5b8c\u6574\u5f62\u6210", + "type": "related", + "direction": "forward", + "weight": 0.7 + }, + { + "source": "article:02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/\u9636\u6bb52_\u9ad8\u4fdd\u771f\u6a21\u578b\u4e0e\u4e1a\u52a1\u5bf9\u8c61\u786e\u8ba4", + "target": "article:02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/\u9636\u6bb52.5_\u6d4b\u8bd5\u63d0\u524d\u8865\u6f0f", + "type": "related", + "direction": "forward", + "weight": 0.7 + }, + { + "source": "article:02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/\u9636\u6bb52_\u9ad8\u4fdd\u771f\u6a21\u578b\u4e0e\u4e1a\u52a1\u5bf9\u8c61\u786e\u8ba4", + "target": "article:02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/\u9636\u6bb5\u4ea4\u4ed8\u7269\u6e05\u5355", + "type": "related", + "direction": "forward", + "weight": 0.7 + }, + { + "source": "article:02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/\u9636\u6bb53_\u7814\u53d1\u534f\u4f5c\u4e0e\u6b63\u5f0f\u5f00\u53d1", + "target": "article:02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/\u9636\u6bb52.5_\u6d4b\u8bd5\u63d0\u524d\u8865\u6f0f", + "type": "related", + "direction": "forward", + "weight": 0.7 + }, + { + "source": "article:02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/\u9636\u6bb53_\u7814\u53d1\u534f\u4f5c\u4e0e\u6b63\u5f0f\u5f00\u53d1", + "target": "article:02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/\u9636\u6bb54_\u6d4b\u8bd5\u57f9\u8bad\u4e0a\u7ebf\u56de\u6d41", + "type": "related", + "direction": "forward", + "weight": 0.7 + }, + { + "source": "article:02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/\u9636\u6bb53_\u7814\u53d1\u534f\u4f5c\u4e0e\u6b63\u5f0f\u5f00\u53d1", + "target": "article:02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/\u9636\u6bb5\u4ea4\u4ed8\u7269\u6e05\u5355", + "type": "related", + "direction": "forward", + "weight": 0.7 + }, + { + "source": "article:02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/\u9636\u6bb54_\u6d4b\u8bd5\u57f9\u8bad\u4e0a\u7ebf\u56de\u6d41", + "target": "article:02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/\u9636\u6bb53_\u7814\u53d1\u534f\u4f5c\u4e0e\u6b63\u5f0f\u5f00\u53d1", + "type": "related", + "direction": "forward", + "weight": 0.7 + }, + { + "source": "article:02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/\u9636\u6bb54_\u6d4b\u8bd5\u57f9\u8bad\u4e0a\u7ebf\u56de\u6d41", + "target": "article:02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/\u9879\u76ee\u68c0\u67e5\u6e05\u5355", + "type": "related", + "direction": "forward", + "weight": 0.7 + }, + { + "source": "article:02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/\u9636\u6bb54_\u6d4b\u8bd5\u57f9\u8bad\u4e0a\u7ebf\u56de\u6d41", + "target": "article:02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/\u9636\u6bb5\u4ea4\u4ed8\u7269\u6e05\u5355", + "type": "related", + "direction": "forward", + "weight": 0.7 + }, + { + "source": "article:02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/\u9636\u6bb5\u4ea4\u4ed8\u7269\u6e05\u5355", + "target": "article:02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/AI\u9a71\u52a8\u5185\u90e8\u7cfb\u7edf\u5f00\u53d1\u6d41\u7a0b_V3_\u603b\u89c8", + "type": "related", + "direction": "forward", + "weight": 0.7 + }, + { + "source": "article:02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/\u9636\u6bb5\u4ea4\u4ed8\u7269\u6e05\u5355", + "target": "article:02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/\u9879\u76ee\u68c0\u67e5\u6e05\u5355", + "type": "related", + "direction": "forward", + "weight": 0.7 + }, + { + "source": "article:02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/\u9879\u76ee\u68c0\u67e5\u6e05\u5355", + "target": "article:02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/AI\u9a71\u52a8\u5185\u90e8\u7cfb\u7edf\u5f00\u53d1\u6d41\u7a0b_V3_\u603b\u89c8", + "type": "related", + "direction": "forward", + "weight": 0.7 + }, + { + "source": "article:02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/\u9879\u76ee\u68c0\u67e5\u6e05\u5355", + "target": "article:02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/\u9636\u6bb5\u4ea4\u4ed8\u7269\u6e05\u5355", + "type": "related", + "direction": "forward", + "weight": 0.7 + }, + { + "source": "article:04_Agent\u68c0\u7d22/\u68c0\u7d22\u8bf4\u660e", + "target": "article:04_Agent\u68c0\u7d22/\u77e5\u8bc6\u5e93\u6301\u7eed\u66f4\u65b0\u4e0e\u9a8c\u8bc1\u6d41\u7a0b", + "type": "related", + "direction": "forward", + "weight": 0.7 + }, + { + "source": "article:06_\u91cc\u7a0b\u7891/README", + "target": "article:06_\u91cc\u7a0b\u7891/\u91cc\u7a0b\u7891\u7d22\u5f15", + "type": "related", + "direction": "forward", + "weight": 0.7 + }, + { + "source": "article:06_\u91cc\u7a0b\u7891/README", + "target": "article:06_\u91cc\u7a0b\u7891/\u9636\u6bb5\u8ba1\u5212\u6a21\u677f", + "type": "related", + "direction": "forward", + "weight": 0.7 + }, + { + "source": "article:06_\u91cc\u7a0b\u7891/README", + "target": "article:06_\u91cc\u7a0b\u7891/\u91cc\u7a0b\u7891\u8bc4\u5ba1\u8bb0\u5f55", + "type": "related", + "direction": "forward", + "weight": 0.7 + }, + { + "source": "article:07_\u6280\u672f\u6587\u6863/README", + "target": "article:07_\u6280\u672f\u6587\u6863/\u6280\u672f\u6587\u6863\u7d22\u5f15", + "type": "related", + "direction": "forward", + "weight": 0.7 + }, + { + "source": "article:07_\u6280\u672f\u6587\u6863/README", + "target": "article:07_\u6280\u672f\u6587\u6863/\u7cfb\u7edf\u67b6\u6784\u8bf4\u660e\u6a21\u677f", + "type": "related", + "direction": "forward", + "weight": 0.7 + }, + { + "source": "article:07_\u6280\u672f\u6587\u6863/README", + "target": "article:07_\u6280\u672f\u6587\u6863/\u63a5\u53e3\u8bf4\u660e\u6a21\u677f", + "type": "related", + "direction": "forward", + "weight": 0.7 + }, + { + "source": "article:07_\u6280\u672f\u6587\u6863/README", + "target": "article:07_\u6280\u672f\u6587\u6863/\u6280\u672f\u51b3\u7b56\u8bb0\u5f55", + "type": "related", + "direction": "forward", + "weight": 0.7 + }, + { + "source": "article:08_\u6d4b\u8bd5\u76f8\u5173/README", + "target": "article:08_\u6d4b\u8bd5\u76f8\u5173/\u6d4b\u8bd5\u7528\u4f8b\u7d22\u5f15", + "type": "related", + "direction": "forward", + "weight": 0.7 + }, + { + "source": "article:08_\u6d4b\u8bd5\u76f8\u5173/README", + "target": "article:08_\u6d4b\u8bd5\u76f8\u5173/\u6d4b\u8bd5\u7528\u4f8b\u6a21\u677f", + "type": "related", + "direction": "forward", + "weight": 0.7 + }, + { + "source": "article:08_\u6d4b\u8bd5\u76f8\u5173/README", + "target": "article:08_\u6d4b\u8bd5\u76f8\u5173/\u6d4b\u8bd5\u8ba1\u5212\u6a21\u677f", + "type": "related", + "direction": "forward", + "weight": 0.7 + }, + { + "source": "article:08_\u6d4b\u8bd5\u76f8\u5173/README", + "target": "article:08_\u6d4b\u8bd5\u76f8\u5173/\u7f3a\u9677\u8bb0\u5f55\u6a21\u677f", + "type": "related", + "direction": "forward", + "weight": 0.7 + }, + { + "source": "article:08_\u6d4b\u8bd5\u76f8\u5173/README", + "target": "article:08_\u6d4b\u8bd5\u76f8\u5173/\u9a8c\u6536\u8bb0\u5f55\u6a21\u677f", + "type": "related", + "direction": "forward", + "weight": 0.7 + }, + { + "source": "article:08_\u6d4b\u8bd5\u76f8\u5173/README", + "target": "article:03_\u89c4\u8303\u4e0e\u6a21\u677f/\u4e0a\u7ebf\u68c0\u67e5\u6a21\u677f", + "type": "related", + "direction": "forward", + "weight": 0.7 + }, + { + "source": "article:\u6b22\u8fce", + "target": "article:00_\u9996\u9875/\u77e5\u8bc6\u5e93\u9996\u9875", + "type": "related", + "direction": "forward", + "weight": 0.7 + }, + { + "source": "article:\u6b22\u8fce", + "target": "article:\u77e5\u8bc6\u5e93\u4f7f\u7528\u8bf4\u660e", + "type": "related", + "direction": "forward", + "weight": 0.7 + }, + { + "source": "article:\u6b22\u8fce", + "target": "article:00_\u9996\u9875/\u77e5\u8bc6\u5730\u56fe", + "type": "related", + "direction": "forward", + "weight": 0.7 + }, + { + "source": "article:\u6b22\u8fce", + "target": "article:00_\u9996\u9875/Agent\u95ee\u7b54\u5165\u53e3", + "type": "related", + "direction": "forward", + "weight": 0.7 + }, + { + "source": "article:\u6b22\u8fce", + "target": "article:05_\u9700\u6c42\u6587\u6863/README", + "type": "related", + "direction": "forward", + "weight": 0.7 + }, + { + "source": "article:\u6b22\u8fce", + "target": "article:06_\u91cc\u7a0b\u7891/README", + "type": "related", + "direction": "forward", + "weight": 0.7 + }, + { + "source": "article:\u6b22\u8fce", + "target": "article:07_\u6280\u672f\u6587\u6863/README", + "type": "related", + "direction": "forward", + "weight": 0.7 + }, + { + "source": "article:\u6b22\u8fce", + "target": "article:08_\u6d4b\u8bd5\u76f8\u5173/README", + "type": "related", + "direction": "forward", + "weight": 0.7 + }, + { + "source": "article:\u6b22\u8fce", + "target": "article:04_Agent\u68c0\u7d22/\u68c0\u7d22\u8bf4\u660e", + "type": "related", + "direction": "forward", + "weight": 0.7 + }, + { + "source": "article:\u77e5\u8bc6\u5e93\u4f7f\u7528\u8bf4\u660e", + "target": "article:\u6b22\u8fce", + "type": "related", + "direction": "forward", + "weight": 0.7 + }, + { + "source": "article:\u77e5\u8bc6\u5e93\u4f7f\u7528\u8bf4\u660e", + "target": "article:00_\u9996\u9875/\u77e5\u8bc6\u5e93\u9996\u9875", + "type": "related", + "direction": "forward", + "weight": 0.7 + }, + { + "source": "article:\u77e5\u8bc6\u5e93\u4f7f\u7528\u8bf4\u660e", + "target": "article:00_\u9996\u9875/\u77e5\u8bc6\u5730\u56fe", + "type": "related", + "direction": "forward", + "weight": 0.7 + }, + { + "source": "article:\u77e5\u8bc6\u5e93\u4f7f\u7528\u8bf4\u660e", + "target": "article:00_\u9996\u9875/Agent\u95ee\u7b54\u5165\u53e3", + "type": "related", + "direction": "forward", + "weight": 0.7 + }, + { + "source": "article:\u77e5\u8bc6\u5e93\u4f7f\u7528\u8bf4\u660e", + "target": "article:04_Agent\u68c0\u7d22/\u68c0\u7d22\u8bf4\u660e", + "type": "related", + "direction": "forward", + "weight": 0.7 + }, + { + "source": "article:\u77e5\u8bc6\u5e93\u4f7f\u7528\u8bf4\u660e", + "target": "article:05_\u9700\u6c42\u6587\u6863/README", + "type": "related", + "direction": "forward", + "weight": 0.7 + }, + { + "source": "article:\u77e5\u8bc6\u5e93\u4f7f\u7528\u8bf4\u660e", + "target": "article:06_\u91cc\u7a0b\u7891/README", + "type": "related", + "direction": "forward", + "weight": 0.7 + }, + { + "source": "article:\u77e5\u8bc6\u5e93\u4f7f\u7528\u8bf4\u660e", + "target": "article:07_\u6280\u672f\u6587\u6863/README", + "type": "related", + "direction": "forward", + "weight": 0.7 + }, + { + "source": "article:\u77e5\u8bc6\u5e93\u4f7f\u7528\u8bf4\u660e", + "target": "article:08_\u6d4b\u8bd5\u76f8\u5173/README", + "type": "related", + "direction": "forward", + "weight": 0.7 + }, + { + "source": "article:\u77e5\u8bc6\u5e93\u4f7f\u7528\u8bf4\u660e", + "target": "article:02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/AI\u9a71\u52a8\u5185\u90e8\u7cfb\u7edf\u5f00\u53d1\u6d41\u7a0b_V3_\u603b\u89c8", + "type": "related", + "direction": "forward", + "weight": 0.7 + }, + { + "source": "article:\u77e5\u8bc6\u5e93\u4f7f\u7528\u8bf4\u660e", + "target": "article:04_Agent\u68c0\u7d22/\u6765\u6e90\u6587\u4ef6\u7d22\u5f15", + "type": "related", + "direction": "forward", + "weight": 0.7 + }, + { + "source": "article:\u77e5\u8bc6\u5e93\u4f7f\u7528\u8bf4\u660e", + "target": "article:05_\u9700\u6c42\u6587\u6863/\u9700\u6c42\u6587\u6863\u7d22\u5f15", + "type": "related", + "direction": "forward", + "weight": 0.7 + }, + { + "source": "article:\u77e5\u8bc6\u5e93\u4f7f\u7528\u8bf4\u660e", + "target": "article:01_\u4e1a\u52a1\u6d41\u7a0b/\u4e1a\u52a1\u89c4\u5219\u7d22\u5f15", + "type": "related", + "direction": "forward", + "weight": 0.7 + }, + { + "source": "article:\u77e5\u8bc6\u5e93\u4f7f\u7528\u8bf4\u660e", + "target": "article:01_\u4e1a\u52a1\u6d41\u7a0b/\u4e1a\u52a1\u5bf9\u8c61\u5b57\u5178", + "type": "related", + "direction": "forward", + "weight": 0.7 + }, + { + "source": "article:\u77e5\u8bc6\u5e93\u4f7f\u7528\u8bf4\u660e", + "target": "article:04_Agent\u68c0\u7d22/\u5173\u952e\u8bcd\u7d22\u5f15", + "type": "related", + "direction": "forward", + "weight": 0.7 + }, + { + "source": "article:\u77e5\u8bc6\u5e93\u4f7f\u7528\u8bf4\u660e", + "target": "article:06_\u91cc\u7a0b\u7891/\u91cc\u7a0b\u7891\u7d22\u5f15", + "type": "related", + "direction": "forward", + "weight": 0.7 + }, + { + "source": "article:\u77e5\u8bc6\u5e93\u4f7f\u7528\u8bf4\u660e", + "target": "article:07_\u6280\u672f\u6587\u6863/\u6280\u672f\u6587\u6863\u7d22\u5f15", + "type": "related", + "direction": "forward", + "weight": 0.7 + }, + { + "source": "article:\u77e5\u8bc6\u5e93\u4f7f\u7528\u8bf4\u660e", + "target": "article:08_\u6d4b\u8bd5\u76f8\u5173/\u6d4b\u8bd5\u7528\u4f8b\u7d22\u5f15", + "type": "related", + "direction": "forward", + "weight": 0.7 + }, + { + "source": "article:\u77e5\u8bc6\u5e93\u4f7f\u7528\u8bf4\u660e", + "target": "article:04_Agent\u68c0\u7d22/\u540c\u4e49\u8bcd\u8868", + "type": "related", + "direction": "forward", + "weight": 0.7 + }, + { + "source": "article:\u77e5\u8bc6\u5e93\u4f7f\u7528\u8bf4\u660e", + "target": "article:04_Agent\u68c0\u7d22/\u77e5\u8bc6\u5e93\u6301\u7eed\u66f4\u65b0\u4e0e\u9a8c\u8bc1\u6d41\u7a0b", + "type": "related", + "direction": "forward", + "weight": 0.7 + } + ], + "warnings": [ + "Unresolved wikilink: [[../\u77e5\u8bc6\u5e93\u4f7f\u7528\u8bf4\u660e]] in 00_\u9996\u9875\\\u77e5\u8bc6\u5730\u56fe.md", + "Unresolved wikilink: [[../Git\u4f7f\u7528\u8bf4\u660e]] in 00_\u9996\u9875\\\u77e5\u8bc6\u5730\u56fe.md", + "Unresolved wikilink: [[../05_\u9700\u6c42\u6587\u6863/README]] in 00_\u9996\u9875\\\u77e5\u8bc6\u5730\u56fe.md", + "Unresolved wikilink: [[../05_\u9700\u6c42\u6587\u6863/\u9700\u6c42\u6587\u6863\u7d22\u5f15]] in 00_\u9996\u9875\\\u77e5\u8bc6\u5730\u56fe.md", + "Unresolved wikilink: [[../03_\u89c4\u8303\u4e0e\u6a21\u677f/\u9700\u6c42\u8bf4\u660e\u6a21\u677f]] in 00_\u9996\u9875\\\u77e5\u8bc6\u5730\u56fe.md", + "Unresolved wikilink: [[../03_\u89c4\u8303\u4e0e\u6a21\u677f/\u4e1a\u52a1\u89c4\u5219\u4e0e\u9700\u6c42\u8865\u5145\u6a21\u677f]] in 00_\u9996\u9875\\\u77e5\u8bc6\u5730\u56fe.md", + "Unresolved wikilink: [[../01_\u4e1a\u52a1\u6d41\u7a0b/\u4e1a\u52a1\u89c4\u5219\u7d22\u5f15]] in 00_\u9996\u9875\\\u77e5\u8bc6\u5730\u56fe.md", + "Unresolved wikilink: [[../01_\u4e1a\u52a1\u6d41\u7a0b/\u4e1a\u52a1\u5bf9\u8c61\u5b57\u5178]] in 00_\u9996\u9875\\\u77e5\u8bc6\u5730\u56fe.md", + "Unresolved wikilink: [[../06_\u91cc\u7a0b\u7891/README]] in 00_\u9996\u9875\\\u77e5\u8bc6\u5730\u56fe.md", + "Unresolved wikilink: [[../06_\u91cc\u7a0b\u7891/\u91cc\u7a0b\u7891\u7d22\u5f15]] in 00_\u9996\u9875\\\u77e5\u8bc6\u5730\u56fe.md", + "Unresolved wikilink: [[../06_\u91cc\u7a0b\u7891/\u9636\u6bb5\u8ba1\u5212\u6a21\u677f]] in 00_\u9996\u9875\\\u77e5\u8bc6\u5730\u56fe.md", + "Unresolved wikilink: [[../06_\u91cc\u7a0b\u7891/\u91cc\u7a0b\u7891\u8bc4\u5ba1\u8bb0\u5f55]] in 00_\u9996\u9875\\\u77e5\u8bc6\u5730\u56fe.md", + "Unresolved wikilink: [[../02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/AI\u9a71\u52a8\u5185\u90e8\u7cfb\u7edf\u5f00\u53d1\u6d41\u7a0b_V3_\u603b\u89c8]] in 00_\u9996\u9875\\\u77e5\u8bc6\u5730\u56fe.md", + "Unresolved wikilink: [[../02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/\u9636\u6bb5\u4ea4\u4ed8\u7269\u6e05\u5355]] in 00_\u9996\u9875\\\u77e5\u8bc6\u5730\u56fe.md", + "Unresolved wikilink: [[../02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/\u9879\u76ee\u68c0\u67e5\u6e05\u5355]] in 00_\u9996\u9875\\\u77e5\u8bc6\u5730\u56fe.md", + "Unresolved wikilink: [[../07_\u6280\u672f\u6587\u6863/README]] in 00_\u9996\u9875\\\u77e5\u8bc6\u5730\u56fe.md", + "Unresolved wikilink: [[../07_\u6280\u672f\u6587\u6863/\u6280\u672f\u6587\u6863\u7d22\u5f15]] in 00_\u9996\u9875\\\u77e5\u8bc6\u5730\u56fe.md", + "Unresolved wikilink: [[../07_\u6280\u672f\u6587\u6863/\u7cfb\u7edf\u67b6\u6784\u8bf4\u660e\u6a21\u677f]] in 00_\u9996\u9875\\\u77e5\u8bc6\u5730\u56fe.md", + "Unresolved wikilink: [[../07_\u6280\u672f\u6587\u6863/\u63a5\u53e3\u8bf4\u660e\u6a21\u677f]] in 00_\u9996\u9875\\\u77e5\u8bc6\u5730\u56fe.md", + "Unresolved wikilink: [[../07_\u6280\u672f\u6587\u6863/\u6280\u672f\u51b3\u7b56\u8bb0\u5f55]] in 00_\u9996\u9875\\\u77e5\u8bc6\u5730\u56fe.md", + "Unresolved wikilink: [[../08_\u6d4b\u8bd5\u76f8\u5173/README]] in 00_\u9996\u9875\\\u77e5\u8bc6\u5730\u56fe.md", + "Unresolved wikilink: [[../08_\u6d4b\u8bd5\u76f8\u5173/\u6d4b\u8bd5\u7528\u4f8b\u7d22\u5f15]] in 00_\u9996\u9875\\\u77e5\u8bc6\u5730\u56fe.md", + "Unresolved wikilink: [[../08_\u6d4b\u8bd5\u76f8\u5173/\u6d4b\u8bd5\u7528\u4f8b\u6a21\u677f]] in 00_\u9996\u9875\\\u77e5\u8bc6\u5730\u56fe.md", + "Unresolved wikilink: [[../08_\u6d4b\u8bd5\u76f8\u5173/\u6d4b\u8bd5\u8ba1\u5212\u6a21\u677f]] in 00_\u9996\u9875\\\u77e5\u8bc6\u5730\u56fe.md", + "Unresolved wikilink: [[../08_\u6d4b\u8bd5\u76f8\u5173/\u7f3a\u9677\u8bb0\u5f55\u6a21\u677f]] in 00_\u9996\u9875\\\u77e5\u8bc6\u5730\u56fe.md", + "Unresolved wikilink: [[../08_\u6d4b\u8bd5\u76f8\u5173/\u9a8c\u6536\u8bb0\u5f55\u6a21\u677f]] in 00_\u9996\u9875\\\u77e5\u8bc6\u5730\u56fe.md", + "Unresolved wikilink: [[../08_\u6d4b\u8bd5\u76f8\u5173/\u4e0a\u7ebf\u68c0\u67e5\u6a21\u677f]] in 00_\u9996\u9875\\\u77e5\u8bc6\u5730\u56fe.md", + "Unresolved wikilink: [[../02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/\u9636\u6bb52.5_\u6d4b\u8bd5\u63d0\u524d\u8865\u6f0f]] in 00_\u9996\u9875\\\u77e5\u8bc6\u5730\u56fe.md", + "Unresolved wikilink: [[../02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/\u9636\u6bb54_\u6d4b\u8bd5\u57f9\u8bad\u4e0a\u7ebf\u56de\u6d41]] in 00_\u9996\u9875\\\u77e5\u8bc6\u5730\u56fe.md", + "Unresolved wikilink: [[../04_Agent\u68c0\u7d22/\u68c0\u7d22\u8bf4\u660e]] in 00_\u9996\u9875\\\u77e5\u8bc6\u5730\u56fe.md", + "Unresolved wikilink: [[../04_Agent\u68c0\u7d22/\u95ee\u7b54\u63d0\u793a\u8bcd]] in 00_\u9996\u9875\\\u77e5\u8bc6\u5730\u56fe.md", + "Unresolved wikilink: [[../04_Agent\u68c0\u7d22/\u5173\u952e\u8bcd\u7d22\u5f15]] in 00_\u9996\u9875\\\u77e5\u8bc6\u5730\u56fe.md", + "Unresolved wikilink: [[../04_Agent\u68c0\u7d22/\u540c\u4e49\u8bcd\u8868]] in 00_\u9996\u9875\\\u77e5\u8bc6\u5730\u56fe.md", + "Unresolved wikilink: [[../04_Agent\u68c0\u7d22/\u6765\u6e90\u6587\u4ef6\u7d22\u5f15]] in 00_\u9996\u9875\\\u77e5\u8bc6\u5730\u56fe.md", + "Unresolved wikilink: [[../04_Agent\u68c0\u7d22/\u77e5\u8bc6\u5e93\u6301\u7eed\u66f4\u65b0\u4e0e\u9a8c\u8bc1\u6d41\u7a0b]] in 00_\u9996\u9875\\\u77e5\u8bc6\u5730\u56fe.md", + "Unresolved wikilink: [[../\u77e5\u8bc6\u5e93\u4f7f\u7528\u8bf4\u660e]] in 00_\u9996\u9875\\\u77e5\u8bc6\u5e93\u9996\u9875.md", + "Unresolved wikilink: [[../05_\u9700\u6c42\u6587\u6863/README]] in 00_\u9996\u9875\\\u77e5\u8bc6\u5e93\u9996\u9875.md", + "Unresolved wikilink: [[../06_\u91cc\u7a0b\u7891/README]] in 00_\u9996\u9875\\\u77e5\u8bc6\u5e93\u9996\u9875.md", + "Unresolved wikilink: [[../07_\u6280\u672f\u6587\u6863/README]] in 00_\u9996\u9875\\\u77e5\u8bc6\u5e93\u9996\u9875.md", + "Unresolved wikilink: [[../08_\u6d4b\u8bd5\u76f8\u5173/README]] in 00_\u9996\u9875\\\u77e5\u8bc6\u5e93\u9996\u9875.md", + "Unresolved wikilink: [[../04_Agent\u68c0\u7d22/\u68c0\u7d22\u8bf4\u660e]] in 00_\u9996\u9875\\\u77e5\u8bc6\u5e93\u9996\u9875.md", + "Unresolved wikilink: [[../02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/\u9636\u6bb51_\u4e1a\u52a1\u9700\u6c42\u5b8c\u6574\u5f62\u6210]] in 01_\u4e1a\u52a1\u6d41\u7a0b\\README.md", + "Unresolved wikilink: [[../02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/\u9636\u6bb52_\u9ad8\u4fdd\u771f\u6a21\u578b\u4e0e\u4e1a\u52a1\u5bf9\u8c61\u786e\u8ba4]] in 01_\u4e1a\u52a1\u6d41\u7a0b\\README.md", + "Unresolved wikilink: [[../02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/\u9636\u6bb52_\u9ad8\u4fdd\u771f\u6a21\u578b\u4e0e\u4e1a\u52a1\u5bf9\u8c61\u786e\u8ba4]] in 01_\u4e1a\u52a1\u6d41\u7a0b\\\u4e1a\u52a1\u5bf9\u8c61\u5b57\u5178.md", + "Unresolved wikilink: [[../02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/\u9636\u6bb5\u4ea4\u4ed8\u7269\u6e05\u5355]] in 01_\u4e1a\u52a1\u6d41\u7a0b\\\u4e1a\u52a1\u5bf9\u8c61\u5b57\u5178.md", + "Unresolved wikilink: [[../02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/\u9636\u6bb51_\u4e1a\u52a1\u9700\u6c42\u5b8c\u6574\u5f62\u6210]] in 01_\u4e1a\u52a1\u6d41\u7a0b\\\u4e1a\u52a1\u6d41\u7a0b\u6a21\u677f.md", + "Unresolved wikilink: [[../02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b/\u9636\u6bb52_\u9ad8\u4fdd\u771f\u6a21\u578b\u4e0e\u4e1a\u52a1\u5bf9\u8c61\u786e\u8ba4]] in 01_\u4e1a\u52a1\u6d41\u7a0b\\\u4e1a\u52a1\u6d41\u7a0b\u6a21\u677f.md", + "Unresolved wikilink: [[../01_\u4e1a\u52a1\u6d41\u7a0b/\u4e1a\u52a1\u5bf9\u8c61\u5b57\u5178]] in 02_\u9879\u76ee\u7ba1\u7406\u6d41\u7a0b\\\u9636\u6bb52_\u9ad8\u4fdd\u771f\u6a21\u578b\u4e0e\u4e1a\u52a1\u5bf9\u8c61\u786e\u8ba4.md", + "Unresolved wikilink: [[../01_\u4e1a\u52a1\u6d41\u7a0b/\u4e1a\u52a1\u6d41\u7a0b\u6a21\u677f]] in 03_\u89c4\u8303\u4e0e\u6a21\u677f\\\u4e1a\u52a1\u6d41\u7a0b\u68b3\u7406\u6a21\u677f.md", + "Unresolved wikilink: [[../05_\u9700\u6c42\u6587\u6863/README]] in 06_\u91cc\u7a0b\u7891\\README.md" + ] +} \ No newline at end of file diff --git a/wishfulfilled-wiki/.understand-anything/knowledge-graph.json b/wishfulfilled-wiki/.understand-anything/knowledge-graph.json new file mode 100644 index 0000000..3851b1a --- /dev/null +++ b/wishfulfilled-wiki/.understand-anything/knowledge-graph.json @@ -0,0 +1,2490 @@ +{ + "version": "1.0.0", + "kind": "codebase", + "project": { + "name": "如愿知识库", + "languages": [ + "markdown" + ], + "frameworks": [ + "Understand-Anything", + "Obsidian" + ], + "description": "按需求文档、里程碑、技术文档、测试相关、Agent检索组织的流程式知识库。", + "analyzedAt": "2026-05-27T07:14:44.893Z", + "gitCommitHash": "" + }, + "nodes": [ + { + "id": "doc:00_首页/Agent问答入口", + "type": "document", + "name": "Agent 问答入口", + "filePath": "00_首页/Agent问答入口.md", + "summary": "当用户询问业务或项目流程时，Agent 应先检索本知识库 Markdown 文件，再组织回答。", + "tags": [ + "00_首页", + "Agent检索" + ], + "complexity": "simple", + "knowledgeMeta": { + "content": "---\ntype: agent_entry\ntags: [Agent, 问答, 检索]\naliases: [问答入口, Agent入口]\nsource: manual\nstatus: active\nowner: 内部技术团队\nupdated: 2026-05\n---\n\n# Agent 问答入口\n\n当用户询问业务或项目流程时，Agent 应先检索本知识库 Markdown 文件，再组织回答。\n\n## 推荐检索顺序\n\n1. `05_需求文档/`：持续新增的业务需求、业务规则、需求变更。\n2. `06_里程碑/`：项目节点、阶段计划、阶段评审、上线节奏。\n3. `07_技术文档/`：架构、接口、数据模型、实现方案、技术决策。\n4. `08_测试相关/`：测试计划、测试用例、缺陷、验收、上线检查。\n5. `02_项目管理流程/`：阶段、角色、交付物、门禁、检查清单。\n6. `01_业务流程/`：具体业务流程、业务对象、业务规则。\n7. `04_Agent检索/`：关键词、同义词、回答规则、来源索引。\n8. `03_规范与模板/`：需要产出文档或表单时检索。\n\n## 回答格式\n\n- 先给结论。\n- 再按阶段、负责人、输入、关键动作、输出、检查点说明。\n- 最后注明来源文件。\n- 若知识库没有明确记录，回答“知识库未明确记录”，并说明建议补充到哪个文件。\n\n## 示例问题\n\n- 一个内部系统需求从提出到上线要走哪些阶段？\n- 阶段2.5测试提前补漏要产出什么？\n- 业务主管在项目入口分级中负责什么？\n- 什么时候需要前端提前参与需求收敛？\n- 新增一条业务规则后，怎么验证 Agent 能搜到？\n- 某个业务规则应该补充到哪个模板里？\n- 某个需求对应哪些测试用例？\n- 某个模块有哪些接口说明？\n- 这个项目当前处在哪个里程碑？\n\n## 业务补充验证入口\n\n- 需求文档目录：`05_需求文档/`\n- 里程碑目录：`06_里程碑/`\n- 技术文档目录：`07_技术文档/`\n- 测试相关目录：`08_测试相关/`\n- 需求文档索引：`05_需求文档/需求文档索引.md`\n- 测试用例索引：`08_测试相关/测试用例索引.md`\n- 模板：`03_规范与模板/业务规则与需求补充模板.md`\n- 流程：`04_Agent检索/知识库持续更新与验证流程.md`\n- 记录：`01_业务流程/业务补充验证记录.md`\n", + "wikilinks": [], + "category": "layer-overview" + } + }, + { + "id": "doc:00_首页/知识地图", + "type": "document", + "name": "知识地图", + "filePath": "00_首页/知识地图.md", + "summary": "- [[../知识库使用说明|知识库使用说明]]", + "tags": [ + "00_首页" + ], + "complexity": "simple", + "knowledgeMeta": { + "content": "---\ntype: map\ntags: [知识地图, 导航]\naliases: [知识库地图]\nsource: manual\nstatus: active\nowner: 内部技术团队\nupdated: 2026-05\n---\n\n# 知识地图\n\n## 使用说明\n\n- [[../知识库使用说明|知识库使用说明]]\n- [[../Git使用说明|Git 使用说明]]\n\n## 需求文档\n\n- [[../05_需求文档/README|需求文档入口]]\n- [[../05_需求文档/需求文档索引|需求文档索引]]\n- [[../03_规范与模板/需求说明模板|需求说明模板]]\n- [[../03_规范与模板/业务规则与需求补充模板|业务规则与需求补充模板]]\n- [[../01_业务流程/业务规则索引|业务规则索引]]\n- [[../01_业务流程/业务对象字典|业务对象字典]]\n\n## 里程碑\n\n- [[../06_里程碑/README|里程碑入口]]\n- [[../06_里程碑/里程碑索引|里程碑索引]]\n- [[../06_里程碑/阶段计划模板|阶段计划模板]]\n- [[../06_里程碑/里程碑评审记录|里程碑评审记录]]\n- [[../02_项目管理流程/AI驱动内部系统开发流程_V3_总览|项目管理流程总览]]\n- [[../02_项目管理流程/阶段交付物清单|阶段交付物清单]]\n- [[../02_项目管理流程/项目检查清单|项目检查清单]]\n\n## 技术文档\n\n- [[../07_技术文档/README|技术文档入口]]\n- [[../07_技术文档/技术文档索引|技术文档索引]]\n- [[../07_技术文档/系统架构说明模板|系统架构说明模板]]\n- [[../07_技术文档/接口说明模板|接口说明模板]]\n- [[../07_技术文档/技术决策记录|技术决策记录]]\n\n## 测试相关\n\n- [[../08_测试相关/README|测试相关入口]]\n- [[../08_测试相关/测试用例索引|测试用例索引]]\n- [[../08_测试相关/测试用例模板|测试用例模板]]\n- [[../08_测试相关/测试计划模板|测试计划模板]]\n- [[../08_测试相关/缺陷记录模板|缺陷记录模板]]\n- [[../08_测试相关/验收记录模板|验收记录模板]]\n- [[../08_测试相关/上线检查模板|上线检查模板]]\n- [[../02_项目管理流程/阶段2.5_测试提前补漏|阶段2.5 测试提前补漏]]\n- [[../02_项目管理流程/阶段4_测试培训上线回流|阶段4 测试培训上线回流]]\n\n## Agent 检索\n\n- [[../04_Agent检索/检索说明|检索说明]]\n- [[../04_Agent检索/问答提示词|问答提示词]]\n- [[../04_Agent检索/关键词索引|关键词索引]]\n- [[../04_Agent检索/同义词表|同义词表]]\n- [[../04_Agent检索/来源文件索引|来源文件索引]]\n- [[../04_Agent检索/知识库持续更新与验证流程|持续更新与验证流程]]\n", + "wikilinks": [], + "category": "layer-overview" + } + }, + { + "id": "doc:00_首页/知识库首页", + "type": "document", + "name": "如愿知识库首页", + "filePath": "00_首页/知识库首页.md", + "summary": "本知识库用于沉淀如愿内部系统建设中的业务流程、项目管理流程、角色职责、交付物、检查清单与 Agent 检索问答规范。", + "tags": [ + "00_首页" + ], + "complexity": "simple", + "knowledgeMeta": { + "content": "---\ntype: index\ntags: [知识库, 首页, 如愿]\naliases: [如愿知识库首页, 知识库入口]\nsource: manual\nstatus: active\nowner: 内部技术团队\nupdated: 2026-05\n---\n\n# 如愿知识库首页\n\n本知识库用于沉淀如愿内部系统建设中的业务流程、项目管理流程、角色职责、交付物、检查清单与 Agent 检索问答规范。\n\n## 快速入口\n\n- [[../知识库使用说明|知识库使用说明]]\n- [[知识地图]]\n- [[Agent问答入口]]\n- [[../05_需求文档/README|需求文档]]\n- [[../06_里程碑/README|里程碑]]\n- [[../07_技术文档/README|技术文档]]\n- [[../08_测试相关/README|测试相关]]\n- [[../04_Agent检索/检索说明|Agent 检索说明]]\n\n## 当前权威来源\n\n- 项目管理流程：`AI_驱动_内部系统开发流程_V3.docx`\n- 适用范围：ERP、内部系统、小型业务系统、运营工具、AI 辅助开发项目。\n\n## 使用原则\n\n1. 需求类问题先查需求文档。\n2. 进度、节点、准入问题先查里程碑。\n3. 技术实现、接口、架构问题先查技术文档。\n4. 测试范围、用例、验收、缺陷问题先查测试相关。\n5. Agent 回答必须说明来源文件。\n6. 知识库没有明确记录时，不要猜测，应提示补充位置。\n", + "wikilinks": [], + "category": "layer-overview" + } + }, + { + "id": "doc:02_项目管理流程/AI驱动内部系统开发流程_V3_总览", + "type": "document", + "name": "AI 驱动内部系统开发流程 V3 总览", + "filePath": "02_项目管理流程/AI驱动内部系统开发流程_V3_总览.md", + "summary": "本流程适用于公司当前阶段的 ERP、内部系统、小型业务系统、运营工具、AI 辅助开发项目。", + "tags": [ + "02_项目管理流程" + ], + "complexity": "simple", + "knowledgeMeta": { + "content": "---\ntype: process_overview\ntags: [项目管理流程, AI驱动开发, ERP, 内部系统]\naliases: [AI驱动内部系统开发流程, 内部系统开发流程V3, ERP开发流程]\nsource: AI_驱动_内部系统开发流程_V3.docx\nstatus: active\nowner: 内部技术团队\nupdated: 2026-05\n---\n\n# AI 驱动内部系统开发流程 V3 总览\n\n## 版本定位\n\n本流程适用于公司当前阶段的 ERP、内部系统、小型业务系统、运营工具、AI 辅助开发项目。\n\n核心目标不是让流程变复杂，而是解决以下问题：\n\n- 业务需求说不清。\n- AI 生成内容不完整。\n- 前端模型介入太晚。\n- 后端数据库设计被页面倒逼。\n- 测试太晚才发现需求漏项。\n- 项目完成后留下大量重复代码和技术债。\n\n## 总体阶段\n\n| 阶段 | 阶段名称 | 核心目标 | 核心负责人 |\n|---|---|---|---|\n| 阶段0 | 项目入口分级 | 判断项目是否值得做、走轻流程还是完整流程 | 业务主管 / 技术负责人 |\n| 阶段1 | 业务需求完整形成 | 业务侧通过 Vibe Coding 跑完整需求 | 业务主管 / 业务人员 |\n| 阶段2 | 高保真模型与业务对象确认 | 把完整但粗糙的需求收敛成可开发模型 | 前端 / 产品经理 |\n| 阶段2.5 | 测试提前补漏 | 在开发前用测试视角发现需求漏洞 | 测试 |\n| 阶段3 | 研发协作与正式开发 | 基于高保真模型进行模块化、安全、可维护开发 | 前端 / 后端 / 算法 |\n| 阶段4 | 测试、培训、上线、回流 | 完成测试、培训、上线验收和问题回流 | 测试 / 业务主管 |\n| 阶段5 | 技术债治理与能力沉淀 | 清理 AI 冗余代码并沉淀复用能力 | 技术负责人 |\n\n## 阶段门禁\n\n| 门禁 | 通过标准 |\n|---|---|\n| Gate 0 | 项目入口通过：确认值得做，确认项目类型。 |\n| Gate 1 | 需求完整通过：主流程、分支、页面、按钮、字段、状态大致完整。 |\n| Gate 2 | 高保真模型通过：页面收敛、按钮行为、业务对象、状态、V1/V2 明确。 |\n| Gate 2.5 | 测试补漏：测试用例初稿发现的阻塞问题已处理。 |\n| Gate 3 | 开发联调通过：前后端、数据库、权限、安全、主要流程联调完成。 |\n| Gate 4 | 上线验收通过：测试通过、业务确认、培训完成。 |\n| Gate 5 | 技术债治理完成：重复代码、组件、接口、数据结构完成治理或进入债务池。 |\n\n## 完整版文件结构\n\n- `00_项目入口分级.md`\n- `01_主流程说明.md`\n- `02_日常操作页面结构.md`\n- `03_功能页面按钮盘点表.md`\n- `04_分支流程_XXX.md`\n- `05_异常流程_XXX.md`\n- `06_VibeCoding页面验证记录.md`\n- `07_高保真模型.html`\n- `07_高保真模型说明.md`\n- `08_项目周期与版本确认.md`\n- `09_前端技术评审.md`\n- `10_技术预检记录.md`\n- `10A_统一业务对象模型.md`\n- `10B_按钮行为矩阵.md`\n- `11_测试用例初稿与需求补漏.md`\n- `12_研发任务拆分与协作计划.md`\n- `13_技术实现对接.md`\n- `14_代码治理与安全规范.md`\n- `15_开发问题与联调记录.md`\n- `16_正式测试报告.md`\n- `17_内部培训手册.md`\n- `18_上线验收记录.md`\n- `19_上线问题与回流需求.md`\n- `20_技术债清单.md`\n- `21_业务原子能力沉淀清单.md`\n- `22_组件库与服务复用清单.md`\n- `23_AI开发上下文模板更新记录.md`\n\n## 轻量版文件结构\n\n小项目可以使用轻量版：\n\n- `00_项目入口分级.md`\n- `01_业务需求包.md`\n- `02_高保真模型包.md`\n- `03_项目版本与技术预检.md`\n- `04_测试用例初稿与需求补漏.md`\n- `05_研发协作与技术实现包.md`\n- `06_代码治理与安全规范.md`\n- `07_测试培训上线包.md`\n- `08_技术债与能力沉淀包.md`\n\n## 最终核心原则\n\n- 先分级，再开发。\n- 阶段1追求需求完整，不追求产品完善。\n- Vibe Coding 页面只是需求原型，不直接进入生产。\n- 阶段2追求模型高效，前端必须深度参与。\n- 高保真模型确认后，才允许正式开发。\n- 统一业务对象模型是页面、接口、数据库、测试、AI 提示词的共同基础。\n- 性能、安全、权限、并发、日志、可回滚必须提前预检。\n- 测试提前补漏，不只是上线前找 Bug。\n- 研发阶段以代码质量、模块化、安全性、可维护性为中心。\n- AI 代码必须治理，不能直接堆进生产。\n- 每个项目都要沉淀业务原子能力。\n- 每完成 3-4 个项目，必须进行技术债治理。\n\n## 一句话总结\n\n这套流程不是为了让 AI 替代开发，而是让 AI 帮业务更快形成完整需求，让前端和产品把需求收敛成高保真模型，让研发团队基于模型高质量开发，让测试和技术债治理保障系统长期可用。\n\n## 关联条目\n\n- [[阶段0_项目入口分级]]\n- [[阶段1_业务需求完整形成]]\n- [[阶段2_高保真模型与业务对象确认]]\n- [[阶段2.5_测试提前补漏]]\n- [[阶段3_研发协作与正式开发]]\n- [[阶段4_测试培训上线回流]]\n- [[角色职责矩阵]]\n- [[阶段交付物清单]]\n- [[项目检查清单]]\n", + "wikilinks": [], + "category": "layer-milestones" + } + }, + { + "id": "doc:02_项目管理流程/README", + "type": "document", + "name": "项目管理流程", + "filePath": "02_项目管理流程/README.md", + "summary": "本目录基于 `AI_驱动_内部系统开发流程_V3.docx` 拆解，用于指导 ERP、内部系统、小型业务系统、运营工具、AI 辅助开发项目。", + "tags": [ + "02_项目管理流程" + ], + "complexity": "simple", + "knowledgeMeta": { + "content": "---\ntype: index\ntags: [项目管理流程, AI驱动开发]\naliases: [项目管理流程入口, 开发流程入口]\nsource: AI_驱动_内部系统开发流程_V3.docx\nstatus: active\nowner: 内部技术团队\nupdated: 2026-05\n---\n\n# 项目管理流程\n\n本目录基于 `AI_驱动_内部系统开发流程_V3.docx` 拆解，用于指导 ERP、内部系统、小型业务系统、运营工具、AI 辅助开发项目。\n\n## 阶段文件\n\n- [[AI驱动内部系统开发流程_V3_总览]]\n- [[阶段0_项目入口分级]]\n- [[阶段1_业务需求完整形成]]\n- [[阶段2_高保真模型与业务对象确认]]\n- [[阶段2.5_测试提前补漏]]\n- [[阶段3_研发协作与正式开发]]\n- [[阶段4_测试培训上线回流]]\n\n## 重组索引\n\n- [[角色职责矩阵]]\n- [[阶段交付物清单]]\n- [[项目检查清单]]\n- [[常见问题FAQ]]\n\n## 核心原则\n\n先分级，再开发。阶段1追求需求完整，不追求产品完善。高保真模型确认后，才允许正式开发。测试要提前补漏。AI 代码必须治理，不能直接堆进生产。\n", + "wikilinks": [], + "category": "layer-milestones" + } + }, + { + "id": "doc:02_项目管理流程/常见问题FAQ", + "type": "document", + "name": "常见问题 FAQ", + "filePath": "02_项目管理流程/常见问题FAQ.md", + "summary": "通常经过阶段0项目入口分级、阶段1业务需求完整形成、阶段2高保真模型与业务对象确认、阶段2.5测试提前补漏、阶段3研发协作与正式开发、阶段4测试培训上线回流。文档还定义了阶段5技术债治理与能力沉淀。", + "tags": [ + "02_项目管理流程" + ], + "complexity": "simple", + "knowledgeMeta": { + "content": "---\ntype: faq\ntags: [项目管理流程, FAQ, 问答]\naliases: [流程常见问题, 项目管理问答]\nsource: AI_驱动_内部系统开发流程_V3.docx\nstatus: active\nowner: 内部技术团队\nupdated: 2026-05\n---\n\n# 常见问题 FAQ\n\n## 一个内部系统需求从提出到上线要走哪些阶段？\n\n通常经过阶段0项目入口分级、阶段1业务需求完整形成、阶段2高保真模型与业务对象确认、阶段2.5测试提前补漏、阶段3研发协作与正式开发、阶段4测试培训上线回流。文档还定义了阶段5技术债治理与能力沉淀。\n\n来源：[[AI驱动内部系统开发流程_V3_总览]]\n\n## 阶段0项目入口分级由谁负责？\n\n由业务主管和技术负责人共同负责。业务主管判断业务价值和范围，技术负责人判断技术复杂度和风险。\n\n来源：[[阶段0_项目入口分级]]、[[角色职责矩阵]]\n\n## 业务需求完整形成阶段的目标是什么？\n\n业务侧通过 Vibe Coding 跑完整需求。阶段1追求需求完整，不追求产品完善。\n\n来源：[[阶段1_业务需求完整形成]]\n\n## 阶段2.5测试提前补漏应该在什么时候发生？\n\n发生在高保真模型确认后、正式开发前。\n\n来源：[[阶段2.5_测试提前补漏]]\n\n## 阶段2.5测试提前补漏要产出什么？\n\n主要产出 `11_测试用例初稿与需求补漏.md`，并形成需求补漏记录、阻塞问题清单和已关闭问题清单。\n\n来源：[[阶段2.5_测试提前补漏]]、[[阶段交付物清单]]\n\n## 什么时候需要前端提前参与需求收敛？\n\n阶段2必须由前端深度参与。若需求涉及多页面、复杂交互、权限、状态流转、数据结构或组件复用，前端应在需求收敛时提前参与。\n\n来源：[[阶段2_高保真模型与业务对象确认]]\n\n## 研发协作与正式开发阶段如何保证模块化、安全和可维护？\n\n依赖统一业务对象模型、研发任务拆分、技术实现对接、代码治理与安全规范、开发问题与联调记录。AI 代码必须经过治理，不能直接堆进生产。\n\n来源：[[阶段3_研发协作与正式开发]]\n\n## 上线前需要检查哪些事项？\n\n至少检查正式测试、主流程、分支流程、权限、异常、数据边界、内部培训手册、业务确认、上线问题回流机制。\n\n来源：[[阶段4_测试培训上线回流]]、[[项目检查清单]]\n\n## Vibe Coding 页面能不能直接进入生产？\n\n不能。Vibe Coding 页面只是需求原型，不直接进入生产。\n\n来源：[[阶段1_业务需求完整形成]]、[[AI驱动内部系统开发流程_V3_总览]]\n", + "wikilinks": [], + "category": "layer-milestones" + } + }, + { + "id": "doc:02_项目管理流程/角色职责矩阵", + "type": "document", + "name": "角色职责矩阵", + "filePath": "02_项目管理流程/角色职责矩阵.md", + "summary": "业务主管保证方向正确、主流程清楚、需求不漏大块。", + "tags": [ + "02_项目管理流程" + ], + "complexity": "simple", + "knowledgeMeta": { + "content": "---\ntype: responsibility_matrix\ntags: [项目管理流程, 角色职责, RACI]\naliases: [角色职责, 职责矩阵, RACI]\nsource: AI_驱动_内部系统开发流程_V3.docx\nstatus: active\nowner: 内部技术团队\nupdated: 2026-05\n---\n\n# 角色职责矩阵\n\n## 总览\n\n| 角色 | 主要负责阶段 | 核心职责 | 典型产出 |\n|---|---|---|---|\n| 业务主管 | 阶段0、阶段1、阶段4 | 判断项目价值、明确主流程、确认业务完整性、上线验收 | 项目入口分级、主流程说明、业务验收口径、上线验收记录 |\n| 业务人员 | 阶段1 | 补充分支流程、提供样本数据、验证真实操作路径 | 分支流程、异常流程、Vibe Coding 页面验证记录 |\n| 产品经理 | 阶段2 | 收敛需求、组织高保真模型、明确版本范围 | 高保真模型说明、项目周期与版本确认 |\n| 前端 | 阶段2、阶段3 | 深度参与模型收敛、页面结构、按钮行为、组件复用、前端开发 | 高保真模型、前端技术评审、按钮行为矩阵、前端实现 |\n| 后端 | 阶段3 | 设计接口、数据库、权限、安全、日志、回滚和服务能力 | 技术实现对接、后端服务、接口和数据库方案 |\n| 算法 | 阶段3 | 判断是否需要 AI，设计输入输出、置信度、人工审核和风险控制 | 算法适用性判断、算法输入输出说明、置信度规则 |\n| 测试 | 阶段2.5、阶段4 | 提前写测试用例、发现需求漏洞、正式测试、培训材料、上线反馈 | 测试用例初稿、正式测试报告、内部培训手册、上线问题回流 |\n| 技术负责人 | 阶段0、阶段5 | 技术分级、风险判断、技术债治理和能力沉淀 | 技术债清单、业务原子能力沉淀清单、组件库与服务复用清单 |\n\n## 业务主管\n\n业务主管保证方向正确、主流程清楚、需求不漏大块。\n\n职责：\n\n- 判断项目是否值得做。\n- 定义主流程。\n- 定义日常操作入口。\n- 明确业务人员每天先看什么页面。\n- 拆分分支流程，指定业务人员补充。\n- 确认异常流程。\n- 确认业务完整性。\n- 参与业务验收。\n\n## 业务人员\n\n业务人员负责具体分支流程和真实操作细节。\n\n职责：\n\n- 补充分支流程。\n- 提供样本数据，例如 ASIN、订单、评论、用户、表格等真实样本。\n- 使用 Vibe Coding 跑页面，验证是否符合真实操作。\n- 补充异常场景。\n\n## 算法\n\n算法保证 AI 能力可控、可解释、可人工审核。\n\n职责：\n\n- 判断是否需要 AI，避免为了 AI 而 AI。\n- 设计算法输入，明确模型需要哪些数据。\n- 设计算法输出，明确 AI 返回什么结果。\n- 制定置信度规则。\n- 制定人工审核机制。\n- 设计风险控制，确保 AI 判断错误时可以回退和纠正。\n\n## 测试\n\n测试不只是最后找 Bug，还要提前补漏，并负责内部培训材料。\n\n职责：\n\n- 高保真模型出来后先写测试用例。\n- 用测试视角发现流程、按钮、权限遗漏。\n- 正式测试主流程、分支流程、权限、异常和数据。\n- 输出验收报告。\n- 将测试用例转成业务操作手册。\n- 记录上线问题并回流需求池。\n\n## 关联条目\n\n- [[AI驱动内部系统开发流程_V3_总览]]\n- [[阶段0_项目入口分级]]\n- [[阶段1_业务需求完整形成]]\n- [[阶段2.5_测试提前补漏]]\n- [[阶段4_测试培训上线回流]]\n", + "wikilinks": [], + "category": "layer-milestones" + } + }, + { + "id": "doc:02_项目管理流程/阶段0_项目入口分级", + "type": "document", + "name": "阶段0 项目入口分级", + "filePath": "02_项目管理流程/阶段0_项目入口分级.md", + "summary": "不是所有需求都应该进入完整开发流程。阶段0用于判断项目是否值得做，以及走轻流程还是完整流程。", + "tags": [ + "02_项目管理流程" + ], + "complexity": "simple", + "knowledgeMeta": { + "content": "---\ntype: process_stage\ntags: [项目管理流程, 阶段0, 项目入口, 分级, 立项]\naliases: [项目入口分级, 入口分级, Gate 0, 立项分级]\nsource: AI_驱动_内部系统开发流程_V3.docx\nstatus: active\nowner: 业务主管 / 技术负责人\nupdated: 2026-05\n---\n\n# 阶段0 项目入口分级\n\n## 核心目标\n\n不是所有需求都应该进入完整开发流程。阶段0用于判断项目是否值得做，以及走轻流程还是完整流程。\n\n## 负责人\n\n- 业务主管\n- 技术负责人\n\n## 输入\n\n- 业务提出的问题或机会。\n- 现有系统痛点。\n- 业务收益、风险、范围的初步判断。\n\n## 项目分类\n\n| 类型 | 适用场景 | 流程要求 |\n|---|---|---|\n| S 类 | 小需求，单页面、小改动、无复杂数据 | 可简化阶段1和阶段2。 |\n| M 类 | 中等需求，涉及多个页面、多个角色或状态流转 | 建议走完整阶段0-4。 |\n| L 类 | 大型需求，涉及核心流程、多个部门、复杂权限、数据模型或算法 | 必须走完整流程，并强化技术预检和阶段门禁。 |\n\n## 关键动作\n\n- 判断需求是否值得做。\n- 判断项目影响范围。\n- 判断是否需要完整流程。\n- 判断是否涉及复杂数据、权限、算法、外部系统或高风险流程。\n- 初步指定业务负责人和技术负责人。\n\n## 输出/交付物\n\n- `00_项目入口分级.md`\n- 项目类型：S / M / L。\n- 是否进入完整流程的结论。\n- 初步负责人。\n- 初步范围和风险。\n\n## 检查清单\n\n- [ ] 是否确认需求要解决的真实业务问题？\n- [ ] 是否确认该需求值得做？\n- [ ] 是否确认项目类型？\n- [ ] 是否确认走轻流程还是完整流程？\n- [ ] 是否识别复杂权限、数据、算法、并发、安全或外部系统风险？\n- [ ] 是否明确业务主管和技术负责人？\n\n## 风险点\n\n- 小需求被过度流程化，降低效率。\n- 大需求被当成小需求处理，后续返工。\n- 没有识别权限、数据、安全、算法风险。\n- 没有业务负责人，需求持续漂移。\n\n## Gate 0 通过标准\n\n项目入口通过：确认值得做，确认项目类型。\n\n## 常见问题\n\n### 阶段0由谁负责？\n\n由业务主管和技术负责人共同负责。业务主管判断业务价值和业务范围，技术负责人判断技术复杂度和风险。\n\n### 小需求是否必须走完整流程？\n\n不一定。S 类小需求可以简化阶段1和阶段2，但仍应保留基本入口判断、测试和上线验收。\n\n## 关联条目\n\n- [[AI驱动内部系统开发流程_V3_总览]]\n- [[角色职责矩阵]]\n- [[阶段交付物清单]]\n", + "wikilinks": [], + "category": "layer-milestones" + } + }, + { + "id": "doc:02_项目管理流程/阶段1_业务需求完整形成", + "type": "document", + "name": "阶段1 业务需求完整形成", + "filePath": "02_项目管理流程/阶段1_业务需求完整形成.md", + "summary": "业务侧通过 Vibe Coding 跑完整需求。阶段1追求需求完整，不追求产品完善。", + "tags": [ + "02_项目管理流程", + "需求文档" + ], + "complexity": "simple", + "knowledgeMeta": { + "content": "---\ntype: process_stage\ntags: [项目管理流程, 阶段1, 业务需求, VibeCoding, 需求完整]\naliases: [业务需求完整形成, 提需求, 需求梳理, Gate 1]\nsource: AI_驱动_内部系统开发流程_V3.docx\nstatus: active\nowner: 业务主管 / 业务人员\nupdated: 2026-05\n---\n\n# 阶段1 业务需求完整形成\n\n## 核心目标\n\n业务侧通过 Vibe Coding 跑完整需求。阶段1追求需求完整，不追求产品完善。\n\n## 负责人\n\n- 业务主管\n- 业务人员\n\n## 输入\n\n- 阶段0入口分级结论。\n- 业务痛点、业务目标、现有流程。\n- 业务人员真实操作经验。\n\n## 关键动作\n\n- 梳理主流程。\n- 明确日常操作页面结构。\n- 盘点功能页面和按钮。\n- 补充分支流程。\n- 补充异常流程。\n- 使用 Vibe Coding 生成或验证需求原型。\n- 记录页面验证结果。\n\n## 输出/交付物\n\n- `01_主流程说明.md`\n- `02_日常操作页面结构.md`\n- `03_功能页面按钮盘点表.md`\n- `04_分支流程_XXX.md`\n- `05_异常流程_XXX.md`\n- `06_VibeCoding页面验证记录.md`\n\n## 检查清单\n\n- [ ] 主流程是否能从开始走到结束？\n- [ ] 日常操作入口是否清楚？\n- [ ] 页面、按钮、字段是否大致完整？\n- [ ] 分支流程是否由真实业务人员补充？\n- [ ] 异常流程是否覆盖无负责人、超时、数据缺失等情况？\n- [ ] Vibe Coding 原型是否经过业务侧走查？\n- [ ] 是否明确哪些内容只是原型，不可直接进入生产？\n\n## 风险点\n\n- 只描述主流程，漏掉分支和异常。\n- 把 Vibe Coding 页面当成可生产代码。\n- 业务主管只给方向，没有安排业务人员补充真实操作细节。\n- 页面、按钮、字段未盘点，导致阶段2和开发阶段返工。\n\n## Gate 1 通过标准\n\n需求完整通过：主流程、分支、页面、按钮、字段、状态大致完整。\n\n## 常见问题\n\n### 阶段1追求什么？\n\n追求需求完整，不追求产品完善。页面可以粗糙，但业务流程、分支、异常、按钮、字段不能漏大块。\n\n### Vibe Coding 页面能不能直接上线？\n\n不能。Vibe Coding 页面只是需求原型，不直接进入生产。\n\n## 关联条目\n\n- [[阶段0_项目入口分级]]\n- [[阶段2_高保真模型与业务对象确认]]\n- [[角色职责矩阵]]\n- [[阶段交付物清单]]\n", + "wikilinks": [], + "category": "layer-milestones" + } + }, + { + "id": "doc:02_项目管理流程/阶段2.5_测试提前补漏", + "type": "document", + "name": "阶段2.5 测试提前补漏", + "filePath": "02_项目管理流程/阶段2.5_测试提前补漏.md", + "summary": "在开发前用测试视角发现需求漏洞。测试提前补漏，不只是上线前找 Bug。", + "tags": [ + "02_项目管理流程", + "测试相关" + ], + "complexity": "simple", + "knowledgeMeta": { + "content": "---\ntype: process_stage\ntags: [项目管理流程, 阶段2.5, 测试, 需求补漏, 测试用例]\naliases: [测试提前补漏, 开发前测试, Gate 2.5, 测试用例初稿]\nsource: AI_驱动_内部系统开发流程_V3.docx\nstatus: active\nowner: 测试\nupdated: 2026-05\n---\n\n# 阶段2.5 测试提前补漏\n\n## 核心目标\n\n在开发前用测试视角发现需求漏洞。测试提前补漏，不只是上线前找 Bug。\n\n## 负责人\n\n- 测试\n\n## 输入\n\n- 高保真模型。\n- 高保真模型说明。\n- 统一业务对象模型。\n- 按钮行为矩阵。\n- 项目周期与版本确认。\n\n## 关键动作\n\n- 基于高保真模型先写测试用例初稿。\n- 从主流程、分支流程、权限、异常、数据、按钮行为视角检查遗漏。\n- 标记阻塞开发的问题。\n- 将需求漏洞回流给业务、产品、前端补齐。\n- 确认阻塞问题处理后再进入正式开发。\n\n## 输出/交付物\n\n- `11_测试用例初稿与需求补漏.md`\n- 需求补漏记录。\n- 阻塞问题清单。\n- 已关闭问题清单。\n\n## 检查清单\n\n- [ ] 是否已基于高保真模型编写测试用例初稿？\n- [ ] 是否覆盖主流程？\n- [ ] 是否覆盖分支流程？\n- [ ] 是否覆盖权限？\n- [ ] 是否覆盖异常场景？\n- [ ] 是否覆盖关键数据和状态？\n- [ ] 是否覆盖按钮行为？\n- [ ] 测试发现的阻塞问题是否已关闭？\n\n## 风险点\n\n- 测试只在上线前介入，导致需求漏洞在开发后才暴露。\n- 测试用例只覆盖主流程，漏掉权限、异常、分支和数据边界。\n- 阻塞问题没有关闭就进入开发。\n\n## Gate 2.5 通过标准\n\n测试补漏：测试用例初稿发现的阻塞问题已处理。\n\n## 常见问题\n\n### 阶段2.5应该在什么时候发生？\n\n发生在高保真模型确认后、正式开发前。\n\n### 阶段2.5要产出什么？\n\n主要产出 `11_测试用例初稿与需求补漏.md`，并形成需求补漏记录、阻塞问题清单和已关闭问题清单。\n\n## 关联条目\n\n- [[阶段2_高保真模型与业务对象确认]]\n- [[阶段3_研发协作与正式开发]]\n- [[项目检查清单]]\n", + "wikilinks": [], + "category": "layer-milestones" + } + }, + { + "id": "doc:02_项目管理流程/阶段2_高保真模型与业务对象确认", + "type": "document", + "name": "阶段2 高保真模型与业务对象确认", + "filePath": "02_项目管理流程/阶段2_高保真模型与业务对象确认.md", + "summary": "把完整但粗糙的需求收敛成可开发模型。阶段2追求模型高效，前端必须深度参与。", + "tags": [ + "02_项目管理流程" + ], + "complexity": "simple", + "knowledgeMeta": { + "content": "---\ntype: process_stage\ntags: [项目管理流程, 阶段2, 高保真模型, 业务对象, 前端, 产品]\naliases: [高保真模型确认, 业务对象确认, Gate 2, 统一业务对象模型]\nsource: AI_驱动_内部系统开发流程_V3.docx\nstatus: active\nowner: 前端 / 产品经理\nupdated: 2026-05\n---\n\n# 阶段2 高保真模型与业务对象确认\n\n## 核心目标\n\n把完整但粗糙的需求收敛成可开发模型。阶段2追求模型高效，前端必须深度参与。\n\n## 负责人\n\n- 前端\n- 产品经理\n\n## 输入\n\n- 阶段1形成的主流程、页面结构、按钮盘点、分支流程、异常流程和 Vibe Coding 验证记录。\n\n## 关键动作\n\n- 将业务原型收敛为高保真模型。\n- 明确页面结构、交互、按钮行为和状态变化。\n- 确认业务对象、字段、状态和对象关系。\n- 明确 V1/V2 范围和项目周期。\n- 进行前端技术评审和技术预检。\n- 识别性能、安全、权限、并发、日志、可回滚等风险。\n\n## 输出/交付物\n\n- `07_高保真模型.html`\n- `07_高保真模型说明.md`\n- `08_项目周期与版本确认.md`\n- `09_前端技术评审.md`\n- `10_技术预检记录.md`\n- `10A_统一业务对象模型.md`\n- `10B_按钮行为矩阵.md`\n\n## 检查清单\n\n- [ ] 页面是否已经从粗糙原型收敛成可开发模型？\n- [ ] 按钮行为是否明确？\n- [ ] 业务对象、字段、状态、对象关系是否明确？\n- [ ] V1/V2 范围是否明确？\n- [ ] 是否完成前端技术评审？\n- [ ] 是否完成性能、安全、权限、并发、日志、可回滚预检？\n- [ ] 是否明确高保真模型确认后才允许正式开发？\n\n## 风险点\n\n- 前端介入太晚，导致页面、接口、数据库互相倒逼。\n- 高保真模型只画页面，没有确认业务对象和状态。\n- 没有按钮行为矩阵，开发和测试无法对齐。\n- 未提前识别性能、安全、权限、并发、日志、回滚风险。\n\n## Gate 2 通过标准\n\n高保真模型通过：页面收敛、按钮行为、业务对象、状态、V1/V2 明确。\n\n## 常见问题\n\n### 什么时候需要前端提前参与？\n\n阶段2必须由前端深度参与。若需求涉及多页面、复杂交互、权限、状态流转、数据结构或组件复用，前端应在需求收敛时提前参与。\n\n### 统一业务对象模型为什么重要？\n\n统一业务对象模型是页面、接口、数据库、测试、AI 提示词的共同基础。\n\n## 关联条目\n\n- [[阶段1_业务需求完整形成]]\n- [[阶段2.5_测试提前补漏]]\n- [[../01_业务流程/业务对象字典]]\n- [[阶段交付物清单]]\n", + "wikilinks": [], + "category": "layer-milestones" + } + }, + { + "id": "doc:02_项目管理流程/阶段3_研发协作与正式开发", + "type": "document", + "name": "阶段3 研发协作与正式开发", + "filePath": "02_项目管理流程/阶段3_研发协作与正式开发.md", + "summary": "基于高保真模型进行模块化、安全、可维护开发。研发阶段以代码质量、模块化、安全性、可维护性为中心。", + "tags": [ + "02_项目管理流程" + ], + "complexity": "simple", + "knowledgeMeta": { + "content": "---\ntype: process_stage\ntags: [项目管理流程, 阶段3, 研发协作, 正式开发, 代码治理, 安全]\naliases: [研发协作, 正式开发, Gate 3, 开发联调]\nsource: AI_驱动_内部系统开发流程_V3.docx\nstatus: active\nowner: 前端 / 后端 / 算法\nupdated: 2026-05\n---\n\n# 阶段3 研发协作与正式开发\n\n## 核心目标\n\n基于高保真模型进行模块化、安全、可维护开发。研发阶段以代码质量、模块化、安全性、可维护性为中心。\n\n## 负责人\n\n- 前端\n- 后端\n- 算法\n\n## 输入\n\n- 高保真模型。\n- 统一业务对象模型。\n- 按钮行为矩阵。\n- 测试用例初稿与需求补漏结果。\n- 技术预检记录。\n\n## 关键动作\n\n- 拆分研发任务与协作计划。\n- 进行前端、后端、算法技术实现对接。\n- 明确接口、数据库、权限、安全、日志和回滚方案。\n- 按代码治理与安全规范开发。\n- 记录开发问题与联调结果。\n- 治理 AI 生成代码，不能直接堆进生产。\n\n## 输出/交付物\n\n- `12_研发任务拆分与协作计划.md`\n- `13_技术实现对接.md`\n- `14_代码治理与安全规范.md`\n- `15_开发问题与联调记录.md`\n\n## 检查清单\n\n- [ ] 研发任务是否已拆分？\n- [ ] 前后端、数据库、权限、安全、主要流程是否联调完成？\n- [ ] 是否按统一业务对象模型设计接口和数据库？\n- [ ] 是否处理权限、安全、日志、可回滚？\n- [ ] AI 生成代码是否经过人工审查和治理？\n- [ ] 是否避免重复代码和不可维护堆叠？\n\n## 风险点\n\n- 开发直接从 Vibe Coding 原型开始，跳过高保真模型。\n- AI 生成代码未经治理直接进入生产。\n- 缺少模块边界、权限、安全、日志和回滚方案。\n- 前后端、数据库、测试使用的业务对象不一致。\n\n## Gate 3 通过标准\n\n开发联调通过：前后端、数据库、权限、安全、主要流程联调完成。\n\n## 常见问题\n\n### 阶段3如何保证模块化、安全和可维护？\n\n依赖统一业务对象模型、研发任务拆分、技术实现对接、代码治理与安全规范、开发问题与联调记录。AI 代码必须经过治理，不能直接堆进生产。\n\n## 关联条目\n\n- [[阶段2.5_测试提前补漏]]\n- [[阶段4_测试培训上线回流]]\n- [[阶段交付物清单]]\n", + "wikilinks": [], + "category": "layer-milestones" + } + }, + { + "id": "doc:02_项目管理流程/阶段4_测试培训上线回流", + "type": "document", + "name": "阶段4 测试培训上线回流", + "filePath": "02_项目管理流程/阶段4_测试培训上线回流.md", + "summary": "完成测试、培训、上线验收和问题回流。测试保证系统真实可用，并帮助业务人员正确使用。", + "tags": [ + "02_项目管理流程", + "测试相关" + ], + "complexity": "simple", + "knowledgeMeta": { + "content": "---\ntype: process_stage\ntags: [项目管理流程, 阶段4, 测试, 培训, 上线, 回流]\naliases: [测试培训上线回流, 上线验收, Gate 4]\nsource: AI_驱动_内部系统开发流程_V3.docx\nstatus: active\nowner: 测试 / 业务主管\nupdated: 2026-05\n---\n\n# 阶段4 测试培训上线回流\n\n## 核心目标\n\n完成测试、培训、上线验收和问题回流。测试保证系统真实可用，并帮助业务人员正确使用。\n\n## 负责人\n\n- 测试\n- 业务主管\n\n## 输入\n\n- 开发联调完成的系统。\n- 测试用例。\n- 高保真模型和业务对象模型。\n- 开发问题与联调记录。\n\n## 关键动作\n\n- 进行正式测试。\n- 验证主流程、分支流程、权限、异常和数据。\n- 输出正式测试报告。\n- 将测试用例转成业务操作手册或内部培训材料。\n- 组织业务确认和上线验收。\n- 记录上线问题并回流需求池。\n\n## 输出/交付物\n\n- `16_正式测试报告.md`\n- `17_内部培训手册.md`\n- `18_上线验收记录.md`\n- `19_上线问题与回流需求.md`\n\n## 检查清单\n\n- [ ] 正式测试是否通过？\n- [ ] 主流程是否验证通过？\n- [ ] 分支流程是否验证通过？\n- [ ] 权限是否验证通过？\n- [ ] 异常和数据边界是否验证通过？\n- [ ] 内部培训手册是否完成？\n- [ ] 业务主管是否完成上线确认？\n- [ ] 上线问题是否记录并回流？\n\n## 风险点\n\n- 只测功能，不测权限、异常、数据和实际操作路径。\n- 没有培训材料，业务人员不会用。\n- 上线问题没有进入回流需求池。\n- 业务主管未验收就上线。\n\n## Gate 4 通过标准\n\n上线验收通过：测试通过、业务确认、培训完成。\n\n## 常见问题\n\n### 上线前需要检查哪些事项？\n\n至少检查正式测试、主流程、分支流程、权限、异常、数据边界、内部培训手册、业务确认、上线问题回流机制。\n\n## 关联条目\n\n- [[阶段3_研发协作与正式开发]]\n- [[项目检查清单]]\n- [[阶段交付物清单]]\n", + "wikilinks": [], + "category": "layer-milestones" + } + }, + { + "id": "doc:02_项目管理流程/阶段交付物清单", + "type": "document", + "name": "阶段交付物清单", + "filePath": "02_项目管理流程/阶段交付物清单.md", + "summary": "- [[AI驱动内部系统开发流程_V3_总览]]", + "tags": [ + "02_项目管理流程" + ], + "complexity": "simple", + "knowledgeMeta": { + "content": "---\ntype: deliverable_index\ntags: [项目管理流程, 交付物, 文件清单]\naliases: [交付物清单, 文件结构, 产出物]\nsource: AI_驱动_内部系统开发流程_V3.docx\nstatus: active\nowner: 内部技术团队\nupdated: 2026-05\n---\n\n# 阶段交付物清单\n\n## 完整版交付物\n\n| 阶段 | 交付物 |\n|---|---|\n| 阶段0 | `00_项目入口分级.md` |\n| 阶段1 | `01_主流程说明.md`、`02_日常操作页面结构.md`、`03_功能页面按钮盘点表.md`、`04_分支流程_XXX.md`、`05_异常流程_XXX.md`、`06_VibeCoding页面验证记录.md` |\n| 阶段2 | `07_高保真模型.html`、`07_高保真模型说明.md`、`08_项目周期与版本确认.md`、`09_前端技术评审.md`、`10_技术预检记录.md`、`10A_统一业务对象模型.md`、`10B_按钮行为矩阵.md` |\n| 阶段2.5 | `11_测试用例初稿与需求补漏.md` |\n| 阶段3 | `12_研发任务拆分与协作计划.md`、`13_技术实现对接.md`、`14_代码治理与安全规范.md`、`15_开发问题与联调记录.md` |\n| 阶段4 | `16_正式测试报告.md`、`17_内部培训手册.md`、`18_上线验收记录.md`、`19_上线问题与回流需求.md` |\n| 阶段5 | `20_技术债清单.md`、`21_业务原子能力沉淀清单.md`、`22_组件库与服务复用清单.md`、`23_AI开发上下文模板更新记录.md` |\n\n## 轻量版交付物\n\n| 阶段包 | 交付物 |\n|---|---|\n| 入口 | `00_项目入口分级.md` |\n| 需求 | `01_业务需求包.md` |\n| 模型 | `02_高保真模型包.md` |\n| 预检 | `03_项目版本与技术预检.md` |\n| 测试补漏 | `04_测试用例初稿与需求补漏.md` |\n| 研发 | `05_研发协作与技术实现包.md` |\n| 治理 | `06_代码治理与安全规范.md` |\n| 上线 | `07_测试培训上线包.md` |\n| 沉淀 | `08_技术债与能力沉淀包.md` |\n\n## 关联条目\n\n- [[AI驱动内部系统开发流程_V3_总览]]\n- [[项目检查清单]]\n", + "wikilinks": [], + "category": "layer-milestones" + } + }, + { + "id": "doc:02_项目管理流程/项目检查清单", + "type": "document", + "name": "项目检查清单", + "filePath": "02_项目管理流程/项目检查清单.md", + "summary": "- [ ] 确认项目值得做。", + "tags": [ + "02_项目管理流程" + ], + "complexity": "simple", + "knowledgeMeta": { + "content": "---\ntype: checklist\ntags: [项目管理流程, 检查清单, 门禁]\naliases: [项目门禁检查, 上线检查, 流程检查]\nsource: AI_驱动_内部系统开发流程_V3.docx\nstatus: active\nowner: 内部技术团队\nupdated: 2026-05\n---\n\n# 项目检查清单\n\n## Gate 0 项目入口\n\n- [ ] 确认项目值得做。\n- [ ] 确认项目类型：S / M / L。\n- [ ] 确认走轻流程还是完整流程。\n- [ ] 确认业务主管和技术负责人。\n\n## Gate 1 需求完整\n\n- [ ] 主流程完整。\n- [ ] 分支流程完整。\n- [ ] 页面、按钮、字段大致完整。\n- [ ] 状态大致完整。\n- [ ] Vibe Coding 页面已验证。\n\n## Gate 2 高保真模型\n\n- [ ] 页面已经收敛。\n- [ ] 按钮行为明确。\n- [ ] 业务对象明确。\n- [ ] 状态明确。\n- [ ] V1/V2 明确。\n- [ ] 性能、安全、权限、并发、日志、可回滚已预检。\n\n## Gate 2.5 测试补漏\n\n- [ ] 测试用例初稿已完成。\n- [ ] 主流程、分支、权限、异常、数据、按钮行为已检查。\n- [ ] 阻塞开发的问题已处理。\n\n## Gate 3 开发联调\n\n- [ ] 前后端联调完成。\n- [ ] 数据库联调完成。\n- [ ] 权限和安全联调完成。\n- [ ] 主要流程联调完成。\n- [ ] AI 代码已治理。\n\n## Gate 4 上线验收\n\n- [ ] 正式测试通过。\n- [ ] 业务确认完成。\n- [ ] 培训完成。\n- [ ] 上线问题回流机制明确。\n\n## Gate 5 技术债治理\n\n- [ ] 技术债已分类。\n- [ ] 必须立即处理的已处理。\n- [ ] 可延后的进入技术债池。\n- [ ] 可复用组件已沉淀。\n- [ ] 可复用后端服务已沉淀。\n- [ ] AI 开发上下文模板已更新。\n\n## 关联条目\n\n- [[AI驱动内部系统开发流程_V3_总览]]\n- [[阶段交付物清单]]\n", + "wikilinks": [], + "category": "layer-milestones" + } + }, + { + "id": "doc:04_Agent检索/关键词索引", + "type": "document", + "name": "关键词索引", + "filePath": "04_Agent检索/关键词索引.md", + "summary": "知识库文档。", + "tags": [ + "04_Agent检索", + "Agent检索" + ], + "complexity": "simple", + "knowledgeMeta": { + "content": "---\ntype: keyword_index\ntags: [Agent, 关键词, 索引]\naliases: [关键词映射]\nsource: manual\nstatus: active\nowner: 内部技术团队\nupdated: 2026-05\n---\n\n# 关键词索引\n\n| 关键词 | 推荐检索文件 |\n|---|---|\n| 内部系统开发流程 | `02_项目管理流程/AI驱动内部系统开发流程_V3_总览.md` |\n| ERP 开发流程 | `02_项目管理流程/AI驱动内部系统开发流程_V3_总览.md` |\n| 项目入口 | `02_项目管理流程/阶段0_项目入口分级.md` |\n| 项目分级 | `02_项目管理流程/阶段0_项目入口分级.md` |\n| S 类 / M 类 / L 类 | `02_项目管理流程/阶段0_项目入口分级.md` |\n| 业务需求 | `02_项目管理流程/阶段1_业务需求完整形成.md` |\n| Vibe Coding | `02_项目管理流程/阶段1_业务需求完整形成.md` |\n| 高保真模型 | `02_项目管理流程/阶段2_高保真模型与业务对象确认.md` |\n| 业务对象 | `02_项目管理流程/阶段2_高保真模型与业务对象确认.md`、`01_业务流程/业务对象字典.md` |\n| 按钮行为 | `02_项目管理流程/阶段2_高保真模型与业务对象确认.md` |\n| 测试提前补漏 | `02_项目管理流程/阶段2.5_测试提前补漏.md` |\n| 测试用例初稿 | `02_项目管理流程/阶段2.5_测试提前补漏.md` |\n| 正式开发 | `02_项目管理流程/阶段3_研发协作与正式开发.md` |\n| 研发协作 | `02_项目管理流程/阶段3_研发协作与正式开发.md` |\n| 代码治理 | `02_项目管理流程/阶段3_研发协作与正式开发.md`、`02_项目管理流程/AI驱动内部系统开发流程_V3_总览.md` |\n| 上线验收 | `02_项目管理流程/阶段4_测试培训上线回流.md` |\n| 内部培训 | `02_项目管理流程/阶段4_测试培训上线回流.md` |\n| 问题回流 | `02_项目管理流程/阶段4_测试培训上线回流.md` |\n| 技术债 | `02_项目管理流程/AI驱动内部系统开发流程_V3_总览.md`、`02_项目管理流程/项目检查清单.md` |\n| 门禁 | `02_项目管理流程/项目检查清单.md` |\n| 交付物 | `02_项目管理流程/阶段交付物清单.md` |\n| 谁负责 | `02_项目管理流程/角色职责矩阵.md` |\n| 业务规则补充 | `03_规范与模板/业务规则与需求补充模板.md`、`04_Agent检索/知识库持续更新与验证流程.md` |\n| 需求补充 | `03_规范与模板/业务规则与需求补充模板.md`、`03_规范与模板/需求说明模板.md` |\n| 新增业务流程 | `03_规范与模板/业务规则与需求补充模板.md`、`03_规范与模板/业务流程梳理模板.md` |\n| 检索验证 | `04_Agent检索/知识库持续更新与验证流程.md`、`01_业务流程/业务补充验证记录.md` |\n| Agent 问答验证 | `04_Agent检索/知识库持续更新与验证流程.md`、`01_业务流程/业务补充验证记录.md` |\n", + "wikilinks": [], + "category": "layer-agent" + } + }, + { + "id": "doc:04_Agent检索/同义词表", + "type": "document", + "name": "同义词表", + "filePath": "04_Agent检索/同义词表.md", + "summary": "知识库文档。", + "tags": [ + "04_Agent检索", + "Agent检索" + ], + "complexity": "simple", + "knowledgeMeta": { + "content": "---\ntype: synonym_table\ntags: [Agent, 同义词, 检索]\naliases: [口语映射, 术语映射]\nsource: manual\nstatus: active\nowner: 内部技术团队\nupdated: 2026-05\n---\n\n# 同义词表\n\n| 用户说法 | 标准术语 | 推荐检索文件 |\n|---|---|---|\n| 提需求 | 业务需求完整形成 / 项目入口分级 | `阶段1_业务需求完整形成.md`、`阶段0_项目入口分级.md` |\n| 立项 | 项目入口分级 | `阶段0_项目入口分级.md` |\n| 原型 | Vibe Coding 页面 / 高保真模型 | `阶段1_业务需求完整形成.md`、`阶段2_高保真模型与业务对象确认.md` |\n| 页面模型 | 高保真模型 | `阶段2_高保真模型与业务对象确认.md` |\n| 字段字典 | 业务对象模型 | `阶段2_高保真模型与业务对象确认.md`、`业务对象字典.md` |\n| 开发前测试 | 测试提前补漏 | `阶段2.5_测试提前补漏.md` |\n| 测试先看 | 测试提前补漏 | `阶段2.5_测试提前补漏.md` |\n| 开发怎么开始 | 研发协作与正式开发 | `阶段3_研发协作与正式开发.md` |\n| 上线前要做什么 | 测试培训上线回流 / Gate 4 | `阶段4_测试培训上线回流.md`、`项目检查清单.md` |\n| 谁来做 | 角色职责 | `角色职责矩阵.md` |\n| 要交什么 | 阶段交付物 | `阶段交付物清单.md` |\n| 检查点 | 阶段门禁 / 项目检查清单 | `项目检查清单.md` |\n| AI 写的代码 | AI 代码治理 | `阶段3_研发协作与正式开发.md` |\n| 加一条业务规则 | 业务规则补充 | `业务规则与需求补充模板.md`、`知识库持续更新与验证流程.md` |\n| 补需求 | 需求补充 | `业务规则与需求补充模板.md`、`需求说明模板.md` |\n| 新规则怎么写 | 业务规则与需求补充 | `业务规则与需求补充模板.md` |\n| 怎么验证能不能搜到 | Agent 检索验证 | `知识库持续更新与验证流程.md`、`业务补充验证记录.md` |\n", + "wikilinks": [], + "category": "layer-agent" + } + }, + { + "id": "doc:04_Agent检索/来源文件索引", + "type": "document", + "name": "来源文件索引", + "filePath": "04_Agent检索/来源文件索引.md", + "summary": "- 从原始 docx 更新流程时，需要同步更新阶段文件、角色职责矩阵、交付物清单、检查清单、FAQ、关键词索引和同义词表。", + "tags": [ + "04_Agent检索", + "Agent检索" + ], + "complexity": "simple", + "knowledgeMeta": { + "content": "---\ntype: source_index\ntags: [来源, 索引, Agent]\naliases: [来源索引, 原始文件]\nsource: manual\nstatus: active\nowner: 内部技术团队\nupdated: 2026-05\n---\n\n# 来源文件索引\n\n## 原始来源\n\n| 来源文件 | 路径 | 用途 | 状态 |\n|---|---|---|---|\n| AI_驱动_内部系统开发流程_V3.docx | `D:\\\\AIcoding\\\\WishFulfilled\\\\知识库\\\\AI_驱动_内部系统开发流程_V3.docx` | 项目管理流程权威来源 | active |\n\n## 拆解后的知识条目\n\n| 条目 | 来源 |\n|---|---|\n| `02_项目管理流程/AI驱动内部系统开发流程_V3_总览.md` | AI_驱动_内部系统开发流程_V3.docx |\n| `02_项目管理流程/阶段0_项目入口分级.md` | AI_驱动_内部系统开发流程_V3.docx |\n| `02_项目管理流程/阶段1_业务需求完整形成.md` | AI_驱动_内部系统开发流程_V3.docx |\n| `02_项目管理流程/阶段2_高保真模型与业务对象确认.md` | AI_驱动_内部系统开发流程_V3.docx |\n| `02_项目管理流程/阶段2.5_测试提前补漏.md` | AI_驱动_内部系统开发流程_V3.docx |\n| `02_项目管理流程/阶段3_研发协作与正式开发.md` | AI_驱动_内部系统开发流程_V3.docx |\n| `02_项目管理流程/阶段4_测试培训上线回流.md` | AI_驱动_内部系统开发流程_V3.docx |\n| `02_项目管理流程/角色职责矩阵.md` | AI_驱动_内部系统开发流程_V3.docx |\n| `02_项目管理流程/阶段交付物清单.md` | AI_驱动_内部系统开发流程_V3.docx |\n| `02_项目管理流程/项目检查清单.md` | AI_驱动_内部系统开发流程_V3.docx |\n| `02_项目管理流程/常见问题FAQ.md` | AI_驱动_内部系统开发流程_V3.docx |\n\n## 业务补充来源\n\n| 来源文件 | 路径 | 用途 | 状态 |\n|---|---|---|---|\n| 需求文档目录 | `05_需求文档/` | 持续存放新增业务需求、业务规则和需求变更文档 | active |\n| 需求文档索引.md | `05_需求文档/需求文档索引.md` | 登记新增需求文档及 Agent 检索验证状态 | active |\n| 业务规则与需求补充模板.md | `03_规范与模板/业务规则与需求补充模板.md` | 新增业务规则、需求、流程的标准模板 | active |\n| 知识库持续更新与验证流程.md | `04_Agent检索/知识库持续更新与验证流程.md` | 规范新增文档后的索引同步和 Agent 检索验证 | active |\n| 业务补充验证记录.md | `01_业务流程/业务补充验证记录.md` | 记录新增业务文档是否能被 Agent 检索并回答 | active |\n| 里程碑目录 | `06_里程碑/` | 存放里程碑计划、阶段评审和项目节点材料 | active |\n| 技术文档目录 | `07_技术文档/` | 存放架构、接口、数据模型、实现方案和技术决策 | active |\n| 测试相关目录 | `08_测试相关/` | 存放测试计划、测试用例、缺陷、验收和上线检查材料 | active |\n\n## 维护要求\n\n- 从原始 docx 更新流程时，需要同步更新阶段文件、角色职责矩阵、交付物清单、检查清单、FAQ、关键词索引和同义词表。\n- 新增业务规则、需求或流程文档时，原始需求文档统一放入 `05_需求文档/`，并同步更新需求文档索引、业务规则索引、业务对象字典、关键词索引、同义词表和本来源文件索引。\n- 新增里程碑材料统一放入 `06_里程碑/`，并同步更新里程碑索引。\n- 新增技术材料统一放入 `07_技术文档/`，并同步更新技术文档索引。\n- 新增测试材料统一放入 `08_测试相关/`，并同步更新测试用例索引或对应测试记录。\n- Agent 回答项目管理流程问题时，应优先引用拆解后的 Markdown 文件。\n- Agent 回答具体业务规则和需求问题时，应优先引用 `05_需求文档/` 下的正式需求文档；稳定流程可再引用 `01_业务流程/` 下的业务流程条目。\n", + "wikilinks": [], + "category": "layer-agent" + } + }, + { + "id": "doc:04_Agent检索/检索说明", + "type": "document", + "name": "Agent 检索说明", + "filePath": "04_Agent检索/检索说明.md", + "summary": "让 Agent 在回答业务流程和项目管理流程问题时，优先基于本地 Markdown 知识库检索，而不是凭空回答。", + "tags": [ + "04_Agent检索", + "Agent检索" + ], + "complexity": "simple", + "knowledgeMeta": { + "content": "---\ntype: agent_retrieval_guide\ntags: [Agent, 检索, 规则]\naliases: [Agent检索说明, 检索规则]\nsource: manual\nstatus: active\nowner: 内部技术团队\nupdated: 2026-05\n---\n\n# Agent 检索说明\n\n## 目标\n\n让 Agent 在回答业务流程和项目管理流程问题时，优先基于本地 Markdown 知识库检索，而不是凭空回答。\n\n## 检索优先级\n\n1. `05_需求文档/`：持续新增的业务需求、业务规则、需求变更和补充说明。\n2. `06_里程碑/`：项目节点、阶段计划、阶段评审和上线节奏。\n3. `07_技术文档/`：系统架构、数据模型、接口说明、实现方案和技术决策。\n4. `08_测试相关/`：测试计划、测试用例、缺陷记录、验收记录和上线检查。\n5. `02_项目管理流程/`：内部系统开发流程、阶段、角色、门禁、交付物、检查清单。\n6. `01_业务流程/`：真实业务流程、业务对象、业务规则。\n7. `04_Agent检索/`：关键词、同义词、来源索引、回答规则。\n8. `03_规范与模板/`：需要产出模板或文档时使用。\n\n## 问题类型与命中文件\n\n| 问题类型 | 优先文件 |\n|---|---|\n| 流程阶段 | `AI驱动内部系统开发流程_V3_总览.md`、各阶段文件 |\n| 角色职责 | `角色职责矩阵.md` |\n| 交付物 | `阶段交付物清单.md` |\n| 门禁/检查 | `项目检查清单.md` |\n| 常见问答 | `常见问题FAQ.md` |\n| 业务对象 | `01_业务流程/业务对象字典.md`、`阶段2_高保真模型与业务对象确认.md` |\n| 业务规则 | `05_需求文档/`、`05_需求文档/需求文档索引.md`、`01_业务流程/业务规则索引.md` |\n| 业务需求 | `05_需求文档/`、`05_需求文档/需求文档索引.md` |\n| 项目里程碑 | `06_里程碑/`、`06_里程碑/里程碑索引.md` |\n| 技术实现 | `07_技术文档/`、`07_技术文档/技术文档索引.md` |\n| 接口/数据模型 | `07_技术文档/接口说明模板.md`、具体接口文档、具体数据模型文档 |\n| 测试用例 | `08_测试相关/`、`08_测试相关/测试用例索引.md` |\n| 缺陷/验收/上线检查 | `08_测试相关/缺陷记录模板.md`、`08_测试相关/验收记录模板.md`、`08_测试相关/上线检查模板.md` |\n\n## 回答规则\n\n- 先回答结论，再展开依据。\n- 流程问题按“阶段、负责人、输入、动作、输出、检查点”组织。\n- 角色问题按“负责阶段、核心职责、典型产出”组织。\n- 交付物问题列出文件名。\n- 业务规则和需求问题优先检索 `05_需求文档/` 下的正式需求文档，再检索 `05_需求文档/需求文档索引.md`、`01_业务流程/业务规则索引.md`、`关键词索引.md` 和 `同义词表.md`。\n- 里程碑问题优先检索 `06_里程碑/` 和 `06_里程碑/里程碑索引.md`。\n- 技术问题优先检索 `07_技术文档/` 和 `07_技术文档/技术文档索引.md`。\n- 测试问题优先检索 `08_测试相关/` 和 `08_测试相关/测试用例索引.md`。\n- 必须注明来源文件名。\n- 如果知识库未明确记录，不要推测，应回答“知识库未明确记录”，并建议补充到具体文件。\n\n## 持续更新验证\n\n新增业务规则、需求或流程文档后，按 [[知识库持续更新与验证流程]] 执行验证。\n新增文档应使用 `03_规范与模板/业务规则与需求补充模板.md`，正式需求文档保存到 `05_需求文档/`，验证结果记录到 `05_需求文档/需求文档索引.md` 和 `01_业务流程/业务补充验证记录.md`。\n\n## 引用格式\n\n建议在回答末尾使用：\n\n> 来源：`02_项目管理流程/阶段2.5_测试提前补漏.md`\n", + "wikilinks": [], + "category": "layer-agent" + } + }, + { + "id": "doc:04_Agent检索/知识库持续更新与验证流程", + "type": "document", + "name": "知识库持续更新与验证流程", + "filePath": "04_Agent检索/知识库持续更新与验证流程.md", + "summary": "确保业务规则、业务需求和流程补充后，Agent 能通过文件检索命中新内容，并基于知识库给出可追溯回答。", + "tags": [ + "04_Agent检索", + "Agent检索" + ], + "complexity": "simple", + "knowledgeMeta": { + "content": "---\ntype: validation_process\ntags: [Agent, 检索, 知识库更新, 验证流程]\naliases: [知识库更新验证, Agent检索验证, 补充文档验证流程]\nsource: manual\nstatus: active\nowner: 内部技术团队 / 产品经理\nupdated: 2026-05\n---\n\n# 知识库持续更新与验证流程\n\n## 1. 目标\n\n确保业务规则、业务需求和流程补充后，Agent 能通过文件检索命中新内容，并基于知识库给出可追溯回答。\n\n## 2. 更新入口\n\n业务新增或修订时，优先使用：\n\n- `03_规范与模板/业务规则与需求补充模板.md`\n- `03_规范与模板/需求说明模板.md`\n- `03_规范与模板/业务流程梳理模板.md`\n\n补充后的正式需求文档统一保存到：\n\n- `05_需求文档/`\n\n如果文档已经沉淀为稳定业务流程，再同步拆解或引用到：\n\n- `01_业务流程/`\n\n推荐命名：\n\n```text\n业务域_规则或需求名称_YYYYMMDD.md\n```\n\n示例：\n\n```text\n采购_供应商准入规则_20260526.md\n库存_出入库审批规则_20260526.md\n销售_客户授信额度规则_20260526.md\n```\n\n## 3. 标准更新流程\n\n### 步骤 1：新增补充文档\n\n1. 复制 `业务规则与需求补充模板.md`。\n2. 保存到 `05_需求文档/`。\n3. 补全 Frontmatter：`type`、`tags`、`aliases`、`source`、`status`、`owner`、`updated`。\n4. 补全正文中的业务规则、流程、异常、权限、验收口径和 Agent 检索字段。\n\n### 步骤 2：更新索引\n\n新增业务文档后，同步更新：\n\n| 文件 | 更新内容 |\n|---|---|\n| `05_需求文档/需求文档索引.md` | 增加需求/规则名称、业务域、来源文件、状态和验证状态 |\n| `01_业务流程/业务规则索引.md` | 增加规则名称、业务域、适用场景、来源文件 |\n| `01_业务流程/业务对象字典.md` | 增加新增或变更的业务对象、字段、状态 |\n| `04_Agent检索/关键词索引.md` | 增加关键词到新文件的映射 |\n| `04_Agent检索/同义词表.md` | 增加口语问法与标准术语映射 |\n| `04_Agent检索/来源文件索引.md` | 登记新增知识条目来源 |\n\n### 步骤 3：执行文件级检查\n\n检查项：\n\n- 文件是否位于 `05_需求文档/`。\n- 文件名是否包含业务域、规则/需求名称、日期。\n- Frontmatter 是否完整。\n- 是否包含 `业务规则`、`业务流程`、`验收口径`、`Agent 检索字段`。\n- 索引文件是否已同步更新。\n\n### 步骤 4：执行关键词检索验证\n\n用新增文档中的关键词、别名、口语问法进行检索。\n\n验证标准：\n\n- 至少 1 个正式关键词能命中新文档。\n- 至少 1 个口语问法能通过 `同义词表.md` 或 `关键词索引.md` 定位到新文档。\n- 检索结果能定位到具体文件，而不是只命中模板。\n\n### 步骤 5：执行 Agent 问答验证\n\n每次新增文档至少准备 3 类问题：\n\n| 类型 | 示例 | 通过标准 |\n|---|---|---|\n| 规则类 | `供应商准入有什么条件？` | 能回答规则条件、触发条件、处理结果 |\n| 流程类 | `供应商准入流程怎么走？` | 能按步骤回答主流程和分支流程 |\n| 异常类 | `供应商资料不完整怎么办？` | 能回答异常处理方式和负责人 |\n\nAgent 回答必须满足：\n\n1. 结论来自新增文档或已索引文件。\n2. 回答末尾注明来源文件名。\n3. 如果文档未记录，明确回答“知识库未明确记录”。\n4. 不得凭经验补充没有来源的业务规则。\n\n### 步骤 6：记录验证结果\n\n在新增业务文档末尾的 `变更记录` 或单独验证记录中记录：\n\n| 日期 | 验证问题 | 是否命中 | 来源文件 | 结果 | 待补充 |\n|---|---|---|---|---|---|\n| | | 是/否 | | 通过/失败 | |\n\n## 4. 验证用例模板\n\n复制以下内容到新增业务文档的 `Agent 检索字段` 或验证记录中：\n\n```markdown\n## Agent 检索验证\n\n| 编号 | 用户问题 | 期望命中文件 | 期望答案要点 | 实际结果 | 状态 |\n|---|---|---|---|---|---|\n| Q1 | | | | | 未验证 |\n| Q2 | | | | | 未验证 |\n| Q3 | | | | | 未验证 |\n```\n\n## 5. 通过/失败判定\n\n### 通过\n\n- 新文档能被关键词检索到。\n- Agent 能引用新文档回答至少 3 个验证问题。\n- 回答没有明显幻觉。\n- 来源文件引用正确。\n\n### 失败\n\n出现任一情况视为失败：\n\n- 新文档只保存了，但没有更新关键词索引或同义词表。\n- Agent 命中了旧文件，未命中新文档。\n- Agent 回答没有引用来源。\n- Agent 编造了文档中不存在的业务规则。\n- 问题能检索到模板，但不能检索到正式业务文档。\n\n失败后处理：\n\n1. 补充 `aliases`、`tags`、推荐关键词和同义词。\n2. 更新 `关键词索引.md` 和 `同义词表.md`。\n3. 将标准问答补充到新增文档的 `Agent 检索字段`。\n4. 重新执行验证。\n\n## 6. Agent 验证提示词\n\n```text\n请只基于 D:\\AIcoding\\WishFulfilled\\知识库\\如愿知识库 下的 Markdown 文件回答。\n优先检索 05_需求文档、01_业务流程、02_项目管理流程、04_Agent检索。\n如果知识库没有明确记录，请回答“知识库未明确记录”，并说明建议补充到哪个文件。\n回答末尾必须列出来源文件。\n现在验证问题是：{用户问题}\n```\n", + "wikilinks": [], + "category": "layer-agent" + } + }, + { + "id": "doc:04_Agent检索/问答提示词", + "type": "document", + "name": "问答提示词", + "filePath": "04_Agent检索/问答提示词.md", + "summary": "你是如愿内部知识库问答 Agent。你必须优先检索本地 Markdown 知识库，再回答业务流程、项目管理流程、角色职责、交付物、检查清单和模板相关问题。", + "tags": [ + "04_Agent检索", + "Agent检索" + ], + "complexity": "simple", + "knowledgeMeta": { + "content": "---\ntype: agent_prompt\ntags: [Agent, 提示词, 问答]\naliases: [Agent提示词, 知识库问答Prompt]\nsource: manual\nstatus: active\nowner: 内部技术团队\nupdated: 2026-05\n---\n\n# 问答提示词\n\n## 系统提示词\n\n你是如愿内部知识库问答 Agent。你必须优先检索本地 Markdown 知识库，再回答业务流程、项目管理流程、角色职责、交付物、检查清单和模板相关问题。\n\n回答要求：\n\n1. 不要凭空编造知识库未记录的信息。\n2. 优先检索 `02_项目管理流程` 和 `01_业务流程`。\n3. 流程类问题按阶段、负责人、输入、关键动作、输出、检查点回答。\n4. 角色类问题优先检索 `角色职责矩阵.md`。\n5. 交付物类问题优先检索 `阶段交付物清单.md`。\n6. 门禁和检查类问题优先检索 `项目检查清单.md`。\n7. 每次回答末尾必须注明来源文件。\n8. 如果没有明确答案，回答“知识库未明确记录”，并说明建议补充到哪个文件。\n\n## 用户问题改写规则\n\n- “提需求”可映射为“项目入口分级”或“业务需求完整形成”。\n- “开发前测试”可映射为“阶段2.5 测试提前补漏”。\n- “原型”可映射为“Vibe Coding 页面”或“高保真模型”，需结合上下文区分。\n- “上线前检查”可映射为“Gate 4 上线验收”和“项目检查清单”。\n- “谁负责”优先查角色职责矩阵。\n\n## 标准回答模板\n\n结论：\n\n要点：\n\n1. 阶段/角色：\n2. 输入：\n3. 关键动作：\n4. 输出：\n5. 检查点：\n\n来源：\n", + "wikilinks": [], + "category": "layer-agent" + } + }, + { + "id": "doc:05_需求文档/20260517_USER评价业务闭环_第三步_数据流与中间对象设计_v3", + "type": "document", + "name": "USER 评价业务闭环 — 第三步：数据流与中间对象设计 v3", + "filePath": "05_需求文档/20260517_USER评价业务闭环_第三步_数据流与中间对象设计_v3.md", + "summary": "USER 评价业务闭环 — 第三步：数据流与中间对象设计 v3 文件信息 文件名称： 20260517 USER评价业务闭环 第三步 数据流与中间对象设计 v3.md 项目路径： C:\\XCODE\\USER 当前版本： v3 最近更新： 2026 05 17 上游文档： 工作基线 v1.2 20260517 USER评价业务闭环主流程与后续工作基线 v1.2", + "tags": [ + "05_需求文档", + "需求文档" + ], + "complexity": "complex", + "knowledgeMeta": { + "content": "# USER 评价业务闭环 — 第三步：数据流与中间对象设计 v3\n\n## 文件信息\n\n- 文件名称：`20260517_USER评价业务闭环_第三步_数据流与中间对象设计_v3.md`\n- 项目路径：`C:\\XCODE\\USER`\n- 当前版本：`v3`\n- 最近更新：`2026-05-17`\n- 上游文档：\n - [工作基线 v1.2](20260517_USER评价业务闭环主流程与后续工作基线_v1.2.md) — 业务规则与额度口径\n - [共用能力图与渠道专属流程 v2.2](20260517_USER评价业务闭环_共用能力图与渠道专属流程_v2.2.md) — 每个节点的 查/写/状态/提醒/拦截\n- 前置版本：\n - `数据流与中间对象需求_v1`（Codex，六层架构骨架）\n - `数据流与中间对象设计_v1.1`（Codex，字段字典最全版）\n - `第三步_数据流与中间表设计_v1`（字段级展开 + 流转时序）\n - `第三步_数据流与中间表设计_v2`（吸收 Codex 优点的合并版）\n- 合并策略：以 Codex v1.1 为主骨架（保留其完整字段字典和免评对象），补入 v2 的流转时序表、写入顺序图和快照策略。\n- 文件目的：作为第三步最终主稿，后续数据库物理设计、接口设计和页面点击读写设计均以此为准。\n\n---\n\n## 1. 第三步的目标\n\n第三步不再回答\"流程怎么走\"，而是回答：\n\n1. 现有系统里已经有哪些数据可以复用。\n2. 为什么仅靠现有 `users / amazon_orders / review_plans / push_tasks / support_tickets / fraud_events` 不够。\n3. 必须新增哪些中间对象。\n4. 哪些是正式事务表，哪些只是快照，哪些可以先做成视图。\n5. 从需求形成到结果回流，数据怎样一层一层往下走。\n\n---\n\n## 2. 本步先给出的结论\n\n### 2.1 不能再只围绕单一账号建模\n\n后续所有关键判断都应围绕 **真实人**，而不是只看 JOYHUB ID / 邮箱 / 电话 / Amazon 账号 / 单次订单。JOYHUB 用户只是身份线索之一，真实人才是额度、历史、风险、跨渠道去重和客服上下文的主对象。\n\n### 2.2 现有表能承载业务记录，但承载不了跨流程判断\n\n既有表更接近\"某一模块自己的账\"，但前两步已确认的新需求需要额外的中间层：真实人跨账号归并、每次互动重判、人群入选/排除解释、额度预占与跨渠道去重、客服上下文、评价提交与展示拆分、退款比对。\n\n### 2.3 第三步最重要的是把对象分层\n\n本文件把数据对象分为六层：\n\n```\n源数据层 → 主实体层 → 桥接层 → 事件层 → 快照与决策层 → 结果回流层\n```\n\n---\n\n## 3. 数据设计原则\n\n| 原则 | 说明 |\n| --- | --- |\n| 先识别真实人，再做额度与风险 | 否则 4/4/12 规则都会被多账号绕开 |\n| 事件与快照分离 | 事件是原始事实，快照是某个时点的判断结果 |\n| 当前态与历史态分离 | 当前视图可重算，历史决策必须留痕 |\n| 计划、渠道、客服、风险状态分离 | 不能压成一个字段 |\n| 用户提交与平台展示分离 | 真实提交计额度，Amazon 展示计计划完成 |\n| 能解释\"为什么\" | 入选、排除、拦截、转人工都要能追溯 |\n| 先复用现有对象，再补最小中间层 | 不为了建模漂亮重造全部旧表 |\n| 对敏感数据分层处理 | 原值、标准化值、哈希/指纹、脱敏展示值应区分 |\n\n---\n\n# 第一部分：现有数据源分析\n\n## 4. 现有数据源盘点\n\n| 数据源 | 当前可用内容 | 主要缺口 |\n| --- | --- | --- |\n| 现有 ERP 用户管理 | 用户 ID、用户名、注册时间、最近活跃、国家、性别、邮箱、绑定产品数、标签 | 仍是账号视角，不是真实人视角 |\n| APP / 用户数据库 | JOYHUB ID、邮箱、设备号、设备型号/类型、系统版本、APP版本、绑定玩具、活跃与点击行为 | 需要设备变更轨迹和与订单/客服联动 |\n| Amazon 订单 | 订单号、ASIN、站点、购买时间、订单状态、Profile ID、收件人姓名、收件地址等 | 需要标准化姓名/地址和收件人指纹 |\n| Amazon 评价/Listing | ASIN、评分、评价数、差评数、评价缺口、展示结果 | 用户真实提交与平台展示要拆成两条事实 |\n| 推送系统 | Push 计划、素材、任务、打开、点击、回复、投诉、退订 | IM/EDM/APP 语义不同，不能只用一套粗糙 push 结果 |\n| 客服/TEL | 工单、通话、售后、答应配合、问题处理 | 需要和上下文卡、风险复检、跟进状态联动 |\n| 黑名单/诈骗资料 | 黑名单、诈骗事件、双重退款、强弱关联 | 需要把风险信号与确认案件拆开 |\n| OA 返款/Amazon 退款 | 内部返款与 Amazon 退款 | 缺统一比对对象 |\n| JOYCOLLAB | KOC/KOL、内容、Code、点击、订单、转化、佣金 | 需要和 USER 计划/ASIN 结果打通 |\n\n### 4.1 Amazon 订单字段明细（结合表头.xlsx）\n\n| 字段 | 主要用途 | 涉密 |\n| --- | --- | --- |\n| 订单号 | 订单核验、真实人关联、退款比对 | 是 |\n| 订单状态 | 判断是否撤销、退款、退货、换货 | - |\n| 买家姓名 / 买家邮箱 | 身份关联 | 是 |\n| 收件人 / 电话 | 真实人归并、风险判断 | 是 |\n| 地址 / 城市 / 州 / 邮编 | 收件人归并、同址异名识别 | 是 |\n| ASIN / MSKU / SKU / 品名 / 标题 | 产品匹配、计划归属 | - |\n| 订购日期 / 发货时间 / 结算时间 | 时序判断 | - |\n| 数量 / 单价 / 订单总金额 / 销售额 | 交易画像 | 是 |\n| 是否退款 / 退款总金额 | 双重退款检测 | 是 |\n| 请求评论状态 | 评价缺口判断 | - |\n| 店铺 / 国家 / 销售渠道 | 站点匹配 | - |\n| Order Item ID | 订单行级关联 | - |\n\n### 4.2 订单侧必须补的派生字段\n\n| 字段 | 说明 |\n| --- | --- |\n| `recipient_name_normalized` | 标准化后的收件人姓名 |\n| `recipient_address_normalized` | 标准化后的地址 |\n| `recipient_fingerprint` | 由标准化姓名+地址生成的稳定指纹 |\n| `address_fingerprint` | 仅地址指纹，用于识别同址异名 |\n\n---\n\n## 5. 全局数据流\n\n```mermaid\nflowchart LR\n subgraph S[\"源数据层\"]\n S1[\"现有ERP用户/标签/身份\"]\n S2[\"APP/设备/行为\"]\n S3[\"Amazon订单/评价/Listing\"]\n S4[\"IM/EDM/APP Push/TEL\"]\n S5[\"客服/工单/售后\"]\n S6[\"黑名单/OA返款/Amazon退款\"]\n S7[\"JOYCOLLAB\"]\n end\n\n subgraph M[\"主实体与桥接层\"]\n M1[\"真实人 person_profiles\"]\n M2[\"身份关联 person_identity_links\"]\n M3[\"订单/ASIN/计划/工单\"]\n M4[\"订单关联/路由/去重\"]\n end\n\n subgraph D[\"快照与决策层\"]\n D1[\"画像快照 person_feature_snapshots\"]\n D2[\"上下文卡 contact_context_snapshots\"]\n D3[\"额度台账/预占\"]\n D4[\"风险信号/风险案件\"]\n D5[\"人群快照/排除快照\"]\n D6[\"互动复检/路由决策\"]\n end\n\n subgraph E[\"事件层\"]\n E1[\"渠道事件\"]\n E2[\"客服/TEL事件\"]\n E3[\"退款事件\"]\n E4[\"评价提交事件\"]\n E5[\"免评执行事件\"]\n end\n\n subgraph R[\"结果回流层\"]\n R1[\"评价展示核验\"]\n R2[\"退款比对结果\"]\n R3[\"免评结果\"]\n R4[\"ASIN健康/计划完成\"]\n R5[\"绩效/审计/下一轮需求\"]\n end\n\n S1 & S2 & S3 --> M1\n S1 & S2 & S3 --> M2\n M1 & M2 & M3 --> D1\n M1 & M2 & M3 --> D2\n D1 --> D5\n D3 & D4 --> D5\n D5 --> D6\n D6 --> E1\n S4 --> E1\n S5 --> E2\n S6 --> E3\n E1 & E2 --> E4\n S7 --> E5\n E3 --> R2\n E4 --> R1\n E5 --> R3\n R1 & R2 & R3 --> R4\n R4 --> R5\n R5 --> M3\n```\n\n---\n\n# 第二部分：数据对象分层总表\n\n## 6. 对象分层总表\n\n| 分层 | 对象 | 说明 |\n| --- | --- | --- |\n| 源数据 | `users`、`devices`、`amazon_orders`、`asin_listings`、`push_tasks`、`support_tickets`、`fraud_events`、JOYCOLLAB 数据 | 现有或外部事实来源 |\n| 主实体 | `person_profiles`、`request_tickets`、`review_plans`、`exemption_plans`、`risk_cases`、`blacklist_entities` | 核心业务主体 |\n| 桥接 | `person_identity_links`、`user_order_links`、`plan_task_links`、`channel_route_decisions`、`channel_dedup_records` | 跨主体关系 |\n| 事件 | `im_interaction_records`、`im_flow_tags`、`edm_message_events`、`app_touch_events`、`tel_call_records`、`review_submission_records`、`amazon_refund_records`、`oa_refund_records`、`support_assignment_logs` | 不可丢失的事实 |\n| 快照/决策 | `person_feature_snapshots`、`contact_context_snapshots`、`person_quota_ledgers`、`quota_reservations`、`audience_snapshots`、`audience_exclusions`、`interaction_recheck_records`、`edm_user_behavior_profiles`、`channel_route_decisions`、`channel_dedup_records` | 为某次决策保留当时依据 |\n| 结果/回流 | `review_display_checks`、`refund_match_results`、`exemption_result_snapshots`、`listing_health_snapshots`、`support_performance_snapshots` | 结果与复盘 |\n| 治理 | `interaction_audit_logs`、`manual_review_tasks`、`export_logs`、`audit_logs` | 审计、复核、导出 |\n\n---\n\n## 7. 现有对象如何处理\n\n### 7.1 可以直接复用\n\n| 现有对象 | 处理 |\n| --- | --- |\n| `request_tickets` | 保留，继续作为需求入口 |\n| `amazon_orders` | 保留，补标准化姓名/地址与收件人指纹 |\n| `asin_listings` | 保留，继续作为 ASIN/Listing 主档 |\n| `support_tickets` | 保留，拆出跟进、分派和风险状态辅助表 |\n| `fraud_events` | 保留，上游增加 `risk_signals`，下游衔接 `risk_cases/blacklist_entities` |\n| `audit_logs` | 保留 |\n\n### 7.2 需要扩展\n\n| 现有对象 | 需要补的能力 |\n| --- | --- |\n| `users` | 不再承担真实人主档，只保留 JOYHUB 账号层信息 |\n| `devices` | 补设备型号、系统版本、APP版本、首次/最近出现、设备变化 |\n| `review_plans` | 增加计划族或与 `exemption_plans` 分离 |\n| `push_tasks` | 被更细的渠道事件表补充 |\n| `support_tickets` | 增加与上下文卡、答应配合、风险复核、TEL 记录的关联 |\n\n### 7.3 必须新增\n\n| 对象 | 原因 |\n| --- | --- |\n| `person_profiles` | 真实人主档 |\n| `person_identity_links` | 多线索归并 |\n| `person_feature_snapshots` | 画像解释 |\n| `contact_context_snapshots` | 客服一屏上下文 |\n| `person_quota_ledgers` | 4/4/12 统一额度 |\n| `quota_reservations` | 并发占用与预警 |\n| `audience_snapshots` | 人群生成留痕 |\n| `audience_exclusions` | 排除原因留痕 |\n| `channel_route_decisions` | 渠道路由解释 |\n| `channel_dedup_records` | 跨渠道去重 |\n| `interaction_recheck_records` | 每次有效互动重新判断留痕 |\n| `refund_match_results` | 双重退款识别 |\n| `review_display_checks` | 评价展示拆分 |\n\n---\n\n# 第三部分：P0/P1/P2 优先级\n\n## 8. P0：没有它们，主流程就不可靠\n\n| 对象 | 类型 | 关键用途 |\n| --- | --- | --- |\n| `person_profiles` | 主实体 | 真实人主档 |\n| `person_identity_links` | 桥接 | 账号、邮箱、电话、设备、Profile、收件人归并 |\n| `person_feature_snapshots` | 快照 | 画像依据 |\n| `contact_context_snapshots` | 快照 | 客服上下文卡 |\n| `person_quota_ledgers` | 台账 | 4/4/12 统一额度 |\n| `quota_reservations` | 台账 | 计划并发占用 |\n| `risk_signals` | 事件 | 风险原始信号 |\n| `risk_cases` | 主实体 | 风险案件 |\n| `blacklist_entities` | 主实体 | 确认拦截对象 |\n| `audience_snapshots` | 快照 | 某次人群生成结果 |\n| `audience_exclusions` | 快照 | 排除原因 |\n| `channel_route_decisions` | 决策 | 渠道路由 |\n| `channel_dedup_records` | 决策 | 跨渠道去重 |\n| `interaction_recheck_records` | 决策 | 每次有效互动重判 |\n\n## 9. P1：主流程可走，但没有它们会粗糙且难复盘\n\n| 对象 | 类型 | 关键用途 |\n| --- | --- | --- |\n| `im_interaction_records` | 事件 | IM 细节 |\n| `im_flow_tags` | 事件/派生 | IM 流程流转 |\n| `edm_message_events` | 事件 | EDM 打开/点击/回复/退订 |\n| `edm_user_behavior_profiles` | 快照 | EDM 画像 |\n| `app_touch_events` | 事件 | APP Push 触达 |\n| `tel_call_records` | 事件 | 电话全记录 |\n| `support_followups` | 事务 | 答应配合跟进 |\n| `support_assignment_logs` | 事件 | 分配与升级 |\n| `review_submission_records` | 事件 | 用户真实提交评价 |\n| `review_display_checks` | 结果 | Amazon 展示核验 |\n| `exemption_plans` | 主实体 | 免评计划 |\n| `exemption_plan_tasks` | 事务 | 免评任务 |\n| `creator_content_records` | 事件 | KOC/KOL 内容 |\n| `exemption_result_snapshots` | 结果 | 免评结果 |\n| `amazon_refund_records` | 事件 | Amazon 退款 |\n| `oa_refund_records` | 事件 | OA 返款 |\n| `refund_match_results` | 结果 | 双重退款比对 |\n\n## 10. P2：管理、效率与治理增强\n\n| 对象 | 类型 | 关键用途 |\n| --- | --- | --- |\n| `attendance_records` | 事务 | 出勤 |\n| `shift_schedules` | 事务 | 排班 |\n| `support_goal_records` | 事务 | 目标 |\n| `support_performance_snapshots` | 快照 | 绩效 |\n| `manual_review_tasks` | 事务 | 人工复核 |\n| `interaction_audit_logs` | 审计 | 高敏动作审计 |\n\n---\n\n# 第四部分：完整字段字典\n\n## 11. 真实人与身份层\n\n### 11.1 `person_profiles`\n\n| 字段 | 类型 | 说明 |\n| --- | --- | --- |\n| `person_id` | PK | 真实人唯一标识 |\n| `created_at` | datetime | 首次识别时间 |\n| `updated_at` | datetime | 最近归并更新时间 |\n| `merge_confidence` | enum | 高/中/低 |\n| `status` | enum | 正常/观察中/已确认风险 |\n| `primary_country` | string | 当前主要国家 |\n| `primary_language` | string | 当前主要语言 |\n| `latest_active_at` | datetime | 最近活跃时间 |\n| `lifetime_review_submitted_count` | int | 累计真实提交评价数（跨账号合并） |\n| `current_risk_level` | enum | 当前风险等级 |\n\n### 11.2 `person_identity_links`\n\n| 字段 | 类型 | 说明 |\n| --- | --- | --- |\n| `link_id` | PK | 关联记录 ID |\n| `person_id` | FK → person_profiles | 所属真实人 |\n| `identity_type` | enum | JOYHUB_ID / EMAIL / PHONE / DEVICE / AMAZON_PROFILE / NAME_ADDRESS / PAYMENT / ORDER |\n| `identity_value_hash` | string | 匹配索引 |\n| `identity_value_encrypted` | string | 仅在必要时保存的加密原值 |\n| `link_strength` | enum | 强/弱 |\n| `confidence_score` | decimal | 归并置信度 |\n| `evidence_summary` | text | 命中依据摘要 |\n| `first_seen_at` | datetime | 首次发现时间 |\n| `last_seen_at` | datetime | 最近确认时间 |\n| `source_type` | enum | AMAZON_ORDER / JOYHUB / MANUAL / TEL / EMAIL / CS_TICKET |\n| `is_active` | bool | 是否仍有效 |\n\n### 11.3 归并口径\n\n| 场景 | 数据处理 |\n| --- | --- |\n| 标准化后姓名+地址完全一致 | 直接归并到同一真实人，link_strength=STRONG |\n| 地址一致但姓名不同 | 记录弱关联，不直接合并 |\n| 多个线索交叉命中 | 形成候选归并，记录证据和置信度 |\n| 只有单个弱线索 | 不做直接归并，只写风险信号 |\n\n### 11.4 `contact_context_snapshots`\n\n| 字段组 | 字段 | 来源 |\n| --- | --- | --- |\n| 快照元数据 | `snapshot_id`、`person_id`、`snapshot_at`、`trigger_event` | 系统 |\n| 当前身份 | `joyhub_ids[]`、`emails[]`、`phones[]`、`devices[]`、`amazon_profile_ids[]` | 身份关联 |\n| 归并摘要 | `standardized_name_address`、`linked_person_count`、`merge_confidence` | 真实人/身份关联 |\n| 历史交易 | `total_orders`、`last_order_at`、`total_refunds`、`total_oa_refunds`、`target_asin_purchases[]` | 订单/返款 |\n| 历史服务 | `total_tickets`、`last_ticket_at`、`total_calls`、`last_call_at`、`open_promises[]` | 工单/电话 |\n| 历史风险 | `blacklist_hits`、`strong_associations`、`weak_associations`、`fraud_cases`、`double_refund_flags` | 风险层 |\n| 当前设备 | `device_count`、`latest_device_model`、`app_version`、`recent_device_change` | APP/设备 |\n| 触达历史 | `im_recent[]`、`edm_recent[]`、`app_recent[]`、`tel_recent[]` | 渠道事件 |\n\n---\n\n## 12. 画像、额度与人群层\n\n### 12.1 `person_feature_snapshots`\n\n| 字段组 | 代表字段 |\n| --- | --- |\n| 快照元数据 | `feature_snapshot_id`、`person_id`、`snapshot_at`、`feature_version` |\n| 基础画像 | `country`、`marketplace`、`language`、`gender`、`age_band`、`registered_at` |\n| 产品关系 | `bound_toy_count`、`bound_categories[]`、`target_product_relation` |\n| 交易画像 | `total_orders`、`last_order_at`、`purchase_frequency`、`bought_target_asin` |\n| 行为画像 | `activity_score`、`open_rate`、`click_rate`、`reply_rate`、`review_rate`、`cooperation_rate` |\n| 触达画像 | `im_reachable`、`edm_reachable`、`app_reachable`、`tel_reachable`、`last_touch_at` |\n| 风险画像 | `risk_level`、`blacklist_hit`、`strong_link_count`、`weak_link_count`、`refund_anomaly_flag` |\n| 计划画像 | `joined_plan_types[]`、`last_plan_result`、`lifetime_review_submitted_count` |\n\n### 12.2 三类画像用途\n\n| 用途 | 说明 | 示例 |\n| --- | --- | --- |\n| **硬过滤** | 决定能不能进入人群池 | 黑名单、退订、强关联、超额、站点不符 |\n| **匹配条件** | 决定适不适合当前计划 | 国家、性别、年龄段、绑定玩具、是否买过目标 ASIN |\n| **排序权重** | 决定优先触达谁 | 活跃度、历史配合率、最近互动、打开/点击行为 |\n\n### 12.3 `person_quota_ledgers`\n\n> **HANDOFF：用户运营核心控制规则。** \"4+4+12\"全部按真实人统计，跨所有关联账号合并计算。一个人不管有几个 JOYHUB ID、几个 Amazon 账号——只要归并到同一个真实人，都受同一套额度控制。\n>\n> 示例：真实人关联 3 个 JOYHUB ID（A/B/C），A 上提交 5 个 + B 上提交 4 个 + C 上提交 3 个 = 累计 12，**全部账号停回评/测评，后续仅免评。**\n\n| 字段 | 类型 | 说明 |\n| --- | --- | --- |\n| `ledger_id` | PK | 台账记录 ID |\n| `person_id` | FK → person_profiles | 真实人 |\n| `period_key` | string | 自然月，如 `2026-05` |\n| `quota_type` | enum | MONTHLY_REVIEW / MONTHLY_EXEMPTION / LIFETIME_REVIEW |\n| `quota_limit` | int | 4 / 4 / 12 |\n| `used` | int | 已完成 |\n| `in_progress` | int | 进行中 |\n| `reserved` | int | 已预占 |\n| `available` | int | 剩余可用 = limit - used - in_progress - reserved |\n| `updated_at` | datetime | 最近更新 |\n\n### 12.4 `quota_reservations`\n\n| 字段 | 类型 | 说明 |\n| --- | --- | --- |\n| `reservation_id` | PK | 预占记录 |\n| `person_id` | FK | 真实人 |\n| `plan_id` | FK | 关联计划 |\n| `quota_type` | enum | 测评/免评 |\n| `reserved_count` | int | 预占数量 |\n| `reserved_at` | datetime | 预占时间 |\n| `expires_at` | datetime | 过期释放时间 |\n| `status` | enum | 已预占/已使用/已释放/已过期 |\n\n### 12.5 `audience_snapshots`\n\n| 字段 | 类型 | 说明 |\n| --- | --- | --- |\n| `snapshot_id` | PK | 人群快照 ID |\n| `plan_id` | FK | 计划 |\n| `batch_id` | string | 生成人群批次 |\n| `person_id` | FK | 真实人 |\n| `match_score` | decimal | 匹配得分 |\n| `match_reasons` | JSON | 命中画像条件 |\n| `quota_status` | enum | 充足/预警/超限 |\n| `risk_status` | enum | 正常/弱风险/强风险 |\n| `priority_rank` | int | 触达优先级 |\n| `feature_snapshot_id` | FK | 当时引用的画像快照 |\n| `snapshot_at` | datetime | 快照时间 |\n\n### 12.6 `audience_exclusions`\n\n| 字段 | 类型 | 说明 |\n| --- | --- | --- |\n| `exclusion_id` | PK | 排除记录 |\n| `plan_id` | FK | 计划 |\n| `batch_id` | string | 批次 |\n| `person_id` | FK | 真实人 |\n| `exclusion_reason` | enum | BLACKLIST / UNSUBSCRIBED / QUOTA_EXCEEDED / FREQ_EXCEEDED / OPEN_TICKET / WRONG_COUNTRY / STRONG_RISK |\n| `excluded_at` | datetime | 排除时间 |\n\n### 12.7 为什么一定需要这些中间表\n\n| 对象 | 如果没有会怎样 |\n| --- | --- |\n| `person_feature_snapshots` | 无法解释当时的画像依据 |\n| `audience_snapshots` | 无法复盘某次计划到底选中了谁 |\n| `audience_exclusions` | 无法解释为什么用户没被选中 |\n| `person_quota_ledgers` | 4/4/12 规则无法跨账号统一计算 |\n| `quota_reservations` | 多个计划并发时会重复占用同一人额度 |\n\n---\n\n## 13. 路由与互动复检层\n\n### 13.1 `channel_route_decisions`\n\n| 字段 | 类型 | 说明 |\n| --- | --- | --- |\n| `route_decision_id` | PK | 路由决策 ID |\n| `plan_id` | FK | 计划 |\n| `batch_id` | string | 人群批次 |\n| `person_id` | FK | 真实人 |\n| `candidate_channels` | JSON | 候选渠道 |\n| `selected_channel` | enum | 实际选中渠道 |\n| `excluded_channels` | JSON | 被排除渠道及原因 |\n| `decision_factors` | JSON | 活跃、绑定、可达性、工单、额度、风险 |\n| `decided_at` | datetime | 决策时间 |\n\n### 13.2 `channel_dedup_records`\n\n| 字段 | 类型 | 说明 |\n| --- | --- | --- |\n| `dedup_id` | PK | 去重记录 |\n| `person_id` | FK | 真实人 |\n| `plan_id` | FK | 计划 |\n| `selected_channel` | enum | 保留渠道 |\n| `suppressed_channels` | JSON | 被抑制渠道 |\n| `reason` | text | 去重原因 |\n| `created_at` | datetime | 去重时间 |\n\n### 13.3 `interaction_recheck_records`\n\n每次有效互动后，记录本次重新做过哪些检查、结果是什么、为何继续或拦截。这是\"每次互动重判\"的落地证据。\n\n| 字段 | 类型 | 说明 |\n| --- | --- | --- |\n| `recheck_id` | PK | 复检记录 |\n| `interaction_type` | enum | IM / EDM / APP / TEL / CS / REFUND |\n| `interaction_id` | string | 触发互动 |\n| `person_id` | FK | 真实人 |\n| `context_snapshot_id` | FK | 上下文快照 |\n| `quota_snapshot_ref` | string | 额度快照引用 |\n| `risk_case_id` | FK | 关联风险案件 |\n| `identity_result` | enum | 正常/新增关联/冲突 |\n| `history_result` | enum | 无变化/有更新 |\n| `quota_result` | enum | 充足/预警/超限 |\n| `risk_result` | enum | 正常/弱风险/强风险 |\n| `final_action` | enum | 继续/降级/转人工/暂停 |\n| `checked_at` | datetime | 复检时间 |\n\n---\n\n## 14. 风险层\n\n### 14.1 `risk_signals`\n\n| 字段 | 类型 | 说明 |\n| --- | --- | --- |\n| `signal_id` | PK | 风险信号 ID |\n| `person_id` | FK | 真实人 |\n| `signal_type` | enum | STRONG_HIT / WEAK_HIT / DOUBLE_REFUND / DEVICE_ANOMALY / ADDRESS_ANOMALY / BLACKLIST_HIT |\n| `hit_dimensions` | JSON | 命中维度 |\n| `source_event_id` | string | 触发事件 |\n| `created_at` | datetime | 产生时间 |\n| `resolved_at` | datetime | 解除时间 |\n| `resolution` | enum | 确认风险/误报/观察中 |\n\n### 14.2 `risk_cases`\n\n| 字段 | 类型 | 说明 |\n| --- | --- | --- |\n| `case_id` | PK | 风险案件 |\n| `person_id` | FK | 真实人 |\n| `source_type` | enum | CS_TICKET / TEL_CALL / PUSH_RESPONSE / REFUND / MANUAL |\n| `source_id` | string | 来源对象 |\n| `status` | enum | 待复核/复核中/确认诈骗/排除/已同步黑名单 |\n| `reviewer_id` | FK | 复核人 |\n| `reviewed_at` | datetime | 复核时间 |\n| `sync_status` | enum | 未同步/同步中/已同步/同步失败 |\n\n### 14.3 `blacklist_entities`\n\n| 字段 | 类型 | 说明 |\n| --- | --- | --- |\n| `blacklist_entity_id` | PK | 黑名单实体 |\n| `entity_type` | enum | 邮箱/电话/设备/Profile/收款信息/真实人 |\n| `entity_hash` | string | 匹配索引 |\n| `risk_level` | enum | 风险等级 |\n| `source_case_id` | FK | 来源案件 |\n| `synced_at` | datetime | 同步时间 |\n| `status` | enum | 生效/失效/待复核 |\n\n### 14.4 `manual_review_tasks`\n\n| 字段 | 类型 | 说明 |\n| --- | --- | --- |\n| `task_id` | PK | 人工复核任务 |\n| `person_id` | FK | 真实人 |\n| `source_type` | enum | 风险/额度/渠道/退款 |\n| `source_id` | string | 来源对象 |\n| `task_reason` | text | 复核原因 |\n| `status` | enum | 待处理/处理中/已完成/已关闭 |\n| `owner_id` | FK | 负责人 |\n| `created_at` | datetime | 创建时间 |\n\n---\n\n## 15. 渠道事件层\n\n### 15.1 `im_interaction_records`\n\n| 字段 | 类型 | 说明 |\n| --- | --- | --- |\n| `im_record_id` | PK | IM 记录 |\n| `person_id` | FK | 真实人 |\n| `joyhub_id` | FK | JOYHUB 账号 |\n| `plan_id` | FK | 关联计划 |\n| `action_type` | enum | PUSH_CARD / USER_SUBMIT / USER_REPLY / REMINDER / NOTIFICATION |\n| `card_type` | enum | REVIEW_CARD / EVALUATION_CARD / EXEMPTION_CARD / REMINDER_CARD |\n| `user_submitted_data` | JSON | 订单号/返款账号/截图链接（涉密加密存储） |\n| `order_validation_result` | enum | 通过/非测评单/非公司产品/格式错误/已撤销/已退款 |\n| `tag_changes` | JSON | 本次产生的标签变化 |\n| `created_at` | datetime | 事件时间 |\n\n### 15.2 `im_flow_tags`\n\n| 字段 | 类型 | 说明 |\n| --- | --- | --- |\n| `flow_tag_id` | PK | 流程标签记录 |\n| `person_id` | FK | 真实人 |\n| `tag_code` | string | 流程标签 |\n| `source_im_record_id` | FK | 来源 IM 事件 |\n| `effective_from` | datetime | 生效时间 |\n| `effective_to` | datetime | 失效时间 |\n\n### 15.3 `edm_message_events`\n\n| 字段 | 类型 | 说明 |\n| --- | --- | --- |\n| `edm_event_id` | PK | EDM 事件 |\n| `person_id` | FK | 真实人 |\n| `email_hash` | string | 邮箱索引 |\n| `campaign_id` | FK | 邮件任务 |\n| `event_type` | enum | SENT / DELIVERED / OPENED / CLICKED / REPLIED / BOUNCED / UNSUBSCRIBED / COMPLAINED |\n| `event_at` | datetime | 事件时间 |\n| `click_target` | string | 点击目标 |\n\n### 15.4 `edm_user_behavior_profiles`\n\n| 字段 | 类型 | 说明 |\n| --- | --- | --- |\n| `profile_id` | PK | EDM 行为画像 |\n| `person_id` | FK | 真实人 |\n| `latest_open_at` | datetime | 最近打开 |\n| `latest_reply_at` | datetime | 最近回复 |\n| `open_count_total` | int | 累计打开次数 |\n| `zero_open_last_3` | bool | 最近 3 次 0 打开 |\n| `zero_open_last_5` | bool | 最近 5 次 0 打开 |\n| `clicked_review_link_without_reply_hours` | int | 点击评论链接但未回复时长 |\n| `monthly_receive_count` | int | 当月收信次数 |\n| `mail_type_counts` | JSON | 各邮件类型发送次数 |\n| `mailbox_domain` | string | 邮箱后缀 |\n| `is_unsubscribed` | bool | 是否退订 |\n| `has_hard_bounce` | bool | 是否硬退信 |\n| `snapshot_at` | datetime | 快照时间 |\n\n### 15.5 `app_touch_events`\n\n| 字段 | 类型 | 说明 |\n| --- | --- | --- |\n| `app_event_id` | PK | APP 事件 |\n| `person_id` | FK | 真实人 |\n| `joyhub_id` | FK | JOYHUB 账号 |\n| `push_type` | enum | PUSH / IN_APP / BANNER / POPUP |\n| `event_type` | enum | SENT / DISPLAYED / CLICKED / DISMISSED / UNINSTALLED |\n| `landing_page` | string | 落地页 |\n| `event_at` | datetime | 事件时间 |\n\n### 15.6 `tel_call_records`\n\n| 字段 | 类型 | 说明 | 涉密 |\n| --- | --- | --- | --- |\n| `tel_record_id` | PK | 电话记录 | - |\n| `person_id` | FK | 真实人 | - |\n| `ticket_id` | FK | 关联工单 | - |\n| `call_direction` | enum | INBOUND/OUTBOUND | - |\n| `call_source` | enum | AMAZON_PAGE/MANUAL/PLAN_TASK/FOLLOWUP | - |\n| `phone_hash` | string | 电话索引 | 是 |\n| `call_at` | datetime | 通话时间 | - |\n| `duration_seconds` | int | 通话时长 | - |\n| `call_result` | enum | CONNECTED/NO_ANSWER/WRONG_NUMBER/DECLINED | - |\n| `has_after_sale_issue` | bool | 是否有售后 | - |\n| `issue_type` | enum | 问题类型 | - |\n| `issue_description` | text | 问题描述 | - |\n| `solution` | text | 处理方案 | - |\n| `is_resolved` | bool | 是否解决 | - |\n| `is_satisfied` | bool | 是否满意 | - |\n| `invited_review` | bool | 是否邀请回评/测评 | - |\n| `user_accepted` | bool | 是否接受 | - |\n| `agent_id` | FK | 客服 | - |\n\n---\n\n## 16. 客服层\n\n### 16.1 `support_tickets`\n\n| 字段 | 类型 | 说明 |\n| --- | --- | --- |\n| `ticket_id` | PK | 工单 |\n| `person_id` | FK | 真实人 |\n| `ticket_type` | enum | 差评跟进/测评跟进/回评跟进/紧急Listing/电话/售后/诈骗样品/KOL进度 |\n| `source` | enum | AMAZON_OP/BRAND_OP/SYSTEM_AUTO/PUSH_ESCALATION/USER_REPLY/TEL_INBOUND |\n| `source_id` | string | 来源对象 |\n| `ticket_status` | enum | 待分配/已分配/处理中/等待用户/等待内部/已解决/疑似诈骗/已关闭 |\n| `assigned_team` | FK | 客服组 |\n| `assigned_agent` | FK | 客服 |\n| `created_at` | datetime | 创建时间 |\n| `first_response_at` | datetime | 首次回复 |\n| `resolved_at` | datetime | 解决时间 |\n| `closed_at` | datetime | 关闭时间 |\n| `context_snapshot_id` | FK | 创建时上下文快照 |\n\n### 16.2 `support_followups`\n\n| 字段 | 类型 | 说明 |\n| --- | --- | --- |\n| `followup_id` | PK | 跟进 |\n| `ticket_id` | FK | 工单 |\n| `person_id` | FK | 真实人 |\n| `followup_status` | enum | 已答应配合/待分配/待提醒/等待提交/已提交评价/已提交反馈/超时/需再次联系/已关闭 |\n| `promised_at` | datetime | 承诺时间 |\n| `reminder_count` | int | 已提醒次数 |\n| `last_reminder_at` | datetime | 最近提醒 |\n| `deadline_at` | datetime | 截止时间 |\n| `submitted_at` | datetime | 实际提交 |\n| `submission_type` | enum | 评价/反馈 |\n\n### 16.3 `support_assignment_logs`\n\n| 字段 | 类型 | 说明 |\n| --- | --- | --- |\n| `assignment_log_id` | PK | 分配日志 |\n| `ticket_id` | FK | 工单 |\n| `from_owner_id` | FK | 原负责人 |\n| `to_owner_id` | FK | 新负责人 |\n| `assign_type` | enum | 自动分配/组长分派/转派/升级 |\n| `reason` | text | 原因 |\n| `created_at` | datetime | 分配时间 |\n\n### 16.4 `plan_task_links`\n\n| 字段 | 类型 | 说明 |\n| --- | --- | --- |\n| `link_id` | PK | 桥接 ID |\n| `plan_id` | FK | 计划 |\n| `task_type` | enum | IM_TASK/EDM_TASK/APP_TASK/TEL_TASK/CS_TASK/KOC_TASK |\n| `task_id` | string | 各渠道任务 ID |\n| `created_at` | datetime | 创建时间 |\n\n---\n\n## 17. 评价与退款结果层\n\n### 17.1 `review_submission_records`\n\n| 字段 | 类型 | 说明 |\n| --- | --- | --- |\n| `submission_id` | PK | 提交记录 |\n| `person_id` | FK | 真实人 |\n| `plan_id` | FK | 计划 |\n| `channel` | enum | IM/EDM/APP/TEL/CS |\n| `source_event_id` | string | 来源事件 |\n| `submitted_at` | datetime | 提交时间 |\n| `submission_evidence` | JSON | 截图/链接 |\n| `order_number_hash` | string | 订单索引 |\n| `quota_counted` | bool | 是否已计入 12（提交时即为true） |\n\n### 17.2 `review_display_checks`\n\n| 字段 | 类型 | 说明 |\n| --- | --- | --- |\n| `check_id` | PK | 核验记录 |\n| `submission_id` | FK | 提交记录 |\n| `asin` | string | ASIN |\n| `check_at` | datetime | 核验时间 |\n| `is_displayed` | bool | 是否展示 |\n| `is_verifiable` | bool | 是否可核验 |\n| `display_status` | enum | 展示确认/未展示/待核验 |\n| `plan_completed` | bool | 是否计入计划完成（展示确认后才为true） |\n\n### 17.3 `amazon_refund_records` / `oa_refund_records` / `refund_match_results`\n\n| 对象 | 关键字段 |\n| --- | --- |\n| `amazon_refund_records` | `refund_id`、`order_number_hash`、`asin`、`refund_amount`、`refund_at`、`refund_reason` |\n| `oa_refund_records` | `oa_refund_id`、`person_id`、`order_number_hash`、`refund_amount`、`refund_at` |\n| `refund_match_results` | `match_id`、`order_number_hash`、`amazon_refund_id`、`oa_refund_id`、`match_status`、`amount_diff`、`matched_at` |\n\n---\n\n## 18. 免评结果层\n\n### 18.1 `exemption_plans`\n\n| 字段 | 类型 | 说明 |\n| --- | --- | --- |\n| `exemption_plan_id` | PK | 免评计划 |\n| `source_request_id` | FK | 来源需求 |\n| `asin` | string | ASIN |\n| `marketplace` | string | 站点 |\n| `goal_type` | enum | 内容发布/引流/带货/权重 |\n| `target_metrics` | JSON | 目标点击、Code、订单、销量、权重 |\n| `status` | enum | 草稿/待审批/执行中/已完成/已关闭 |\n\n### 18.2 `exemption_plan_tasks`\n\n| 字段 | 类型 | 说明 |\n| --- | --- | --- |\n| `task_id` | PK | 免评任务 |\n| `exemption_plan_id` | FK | 免评计划 |\n| `task_type` | enum | KOC/KOL/IM/EDM/APP/内容协同 |\n| `owner_id` | FK | 负责人 |\n| `status` | enum | 待执行/执行中/已完成/异常 |\n| `created_at` | datetime | 创建时间 |\n\n### 18.3 `creator_content_records`\n\n| 字段 | 类型 | 说明 |\n| --- | --- | --- |\n| `creator_content_id` | PK | 内容记录 |\n| `exemption_task_id` | FK | 免评任务 |\n| `creator_id` | string | KOC/KOL |\n| `content_url` | string | 内容链接 |\n| `published_at` | datetime | 发布时间 |\n| `code_usage_count` | int | Code 使用量 |\n| `click_count` | int | 点击量 |\n| `order_count` | int | 带货订单 |\n| `sales_amount` | decimal | 销售额 |\n\n### 18.4 `exemption_result_snapshots`\n\n| 字段 | 类型 | 说明 |\n| --- | --- | --- |\n| `snapshot_id` | PK | 免评结果快照 |\n| `exemption_plan_id` | FK | 免评计划 |\n| `snapshot_at` | datetime | 快照时间 |\n| `content_published_count` | int | 内容发布数 |\n| `click_count` | int | 点击 |\n| `code_usage_count` | int | Code 使用 |\n| `order_count` | int | 订单 |\n| `sales_amount` | decimal | 销售额 |\n| `weight_change_summary` | text | 权重变化摘要 |\n\n---\n\n## 19. 客服管理支撑层\n\n| 对象 | 关键字段 |\n| --- | --- |\n| `attendance_records` | `record_id`、`agent_id`、`date`、`scheduled_hours`、`actual_hours`、`status` |\n| `shift_schedules` | `shift_id`、`team_id`、`agent_id`、`date`、`shift_start`、`shift_end`、`max_tickets` |\n| `support_goal_records` | `goal_id`、`agent_id`、`period_key`、`goal_type`、`target_value`、`current_value` |\n| `support_performance_snapshots` | `snapshot_id`、`agent_id`、`period_key`、`tickets_handled`、`messages_sent`、`first_response_avg_sec`、`rso_orders`、`rdo_orders`、`reviews_obtained`、`review_completion_rate`、`monthly_target`、`monthly_completed` |\n\n---\n\n## 20. 逻辑关系总图\n\n```mermaid\nerDiagram\n PERSON_PROFILES ||--o{ PERSON_IDENTITY_LINKS : \"归并\"\n PERSON_PROFILES ||--o{ PERSON_FEATURE_SNAPSHOTS : \"画像\"\n PERSON_PROFILES ||--o{ CONTACT_CONTEXT_SNAPSHOTS : \"上下文\"\n PERSON_PROFILES ||--o{ PERSON_QUOTA_LEDGERS : \"额度台账\"\n PERSON_PROFILES ||--o{ QUOTA_RESERVATIONS : \"额度预占\"\n PERSON_PROFILES ||--o{ RISK_SIGNALS : \"风险信号\"\n PERSON_PROFILES ||--o{ RISK_CASES : \"风险案件\"\n PERSON_PROFILES ||--o{ AUDIENCE_SNAPSHOTS : \"人群入选\"\n PERSON_PROFILES ||--o{ AUDIENCE_EXCLUSIONS : \"人群排除\"\n PERSON_PROFILES ||--o{ CHANNEL_ROUTE_DECISIONS : \"路由\"\n PERSON_PROFILES ||--o{ CHANNEL_DEDUP_RECORDS : \"去重\"\n PERSON_PROFILES ||--o{ INTERACTION_RECHECK_RECORDS : \"互动复检\"\n PERSON_PROFILES ||--o{ IM_INTERACTION_RECORDS : \"IM\"\n PERSON_PROFILES ||--o{ IM_FLOW_TAGS : \"IM标签\"\n PERSON_PROFILES ||--o{ EDM_MESSAGE_EVENTS : \"EDM\"\n PERSON_PROFILES ||--o{ EDM_USER_BEHAVIOR_PROFILES : \"EDM画像\"\n PERSON_PROFILES ||--o{ APP_TOUCH_EVENTS : \"APP\"\n PERSON_PROFILES ||--o{ TEL_CALL_RECORDS : \"TEL\"\n PERSON_PROFILES ||--o{ SUPPORT_TICKETS : \"工单\"\n PERSON_PROFILES ||--o{ SUPPORT_FOLLOWUPS : \"跟进\"\n PERSON_PROFILES ||--o{ REVIEW_SUBMISSION_RECORDS : \"评价提交\"\n PERSON_PROFILES ||--o{ MANUAL_REVIEW_TASKS : \"人工复核\"\n REVIEW_SUBMISSION_RECORDS ||--o{ REVIEW_DISPLAY_CHECKS : \"展示核验\"\n SUPPORT_TICKETS ||--o{ SUPPORT_ASSIGNMENT_LOGS : \"分配\"\n RISK_CASES ||--o{ BLACKLIST_ENTITIES : \"同步\"\n AMAZON_REFUND_RECORDS ||--o{ REFUND_MATCH_RESULTS : \"退款比对\"\n OA_REFUND_RECORDS ||--o{ REFUND_MATCH_RESULTS : \"退款比对\"\n EXEMPTION_PLANS ||--o{ EXEMPTION_PLAN_TASKS : \"任务\"\n EXEMPTION_PLAN_TASKS ||--o{ CREATOR_CONTENT_RECORDS : \"内容\"\n EXEMPTION_PLANS ||--o{ EXEMPTION_RESULT_SNAPSHOTS : \"结果\"\n REVIEW_PLANS ||--o{ PLAN_TASK_LINKS : \"计划任务\"\n SHIFT_SCHEDULES ||--o{ SUPPORT_TICKETS : \"排班分配\"\n ATTENDANCE_RECORDS }o--|| SHIFT_SCHEDULES : \"出勤关联\"\n```\n\n---\n\n# 第五部分：数据流转\n\n## 21. 关键流转时序\n\n| 阶段 | 读（查） | 写 | 说明 |\n| --- | --- | --- | --- |\n| 真实人识别 | person_identity_links（已有线索） | person_profiles + person_identity_links（新线索） | 每次互动都先跑 |\n| 画像生成 | person_profiles + 七组画像数据 + 各渠道事件 | person_feature_snapshots | 定期或触发式刷新 |\n| 人群生成 | person_feature_snapshots + person_quota_ledgers + risk_signals | audience_snapshots + audience_exclusions + quota_reservations | 快照当下状态 |\n| 路由决策 | audience_snapshots + 用户状态 + 渠道可达性 | channel_route_decisions + channel_dedup_records | 选定渠道+去重 |\n| 渠道发送 | channel_route_decisions + quota_reservations + risk_signals（最新） | 各渠道事件表 | 发送前终校 |\n| 用户回应 | person_identity_links + person_quota_ledgers + risk_signals（全部重读） | interaction_recheck_records + 渠道事件表更新 + im_flow_tags | 每次互动复检留痕 |\n| 评价提交 | person_quota_ledgers（累计额度） | review_submission_records + person_quota_ledgers（+1） | 提交即计12 |\n| Amazon 展示确认 | review_submission_records | review_display_checks + 计划完成度更新 | 展示才计完成 |\n| 退款/返款 | amazon_refund_records + oa_refund_records | refund_match_results + risk_signals（如命中） | 双重退款检测 |\n\n## 22. 每次有效互动的标准写入顺序\n\n```mermaid\nflowchart LR\n A[\"互动发生\"] --> B[\"解析真实人
读 person_identity_links\"]\n B --> C[\"生成/更新上下文卡
写 contact_context_snapshots\"]\n C --> D[\"读取最新额度
读 person_quota_ledgers\"]\n D --> E[\"执行风险判断
读 risk_signals + blacklist\"]\n E --> F[\"写 interaction_recheck_records\"]\n F --> G{\"结果\"}\n G -->|正常| H[\"继续业务\"]\n G -->|预警| I[\"继续 + 高亮提醒\"]\n G -->|拦截| J[\"暂停 + 转人工/风险链路\"]\n```\n\n适用场景：主动推送后回复、用户再次联系、补充订单号、客服回访、TEL 来电、退款/返款/再次触达前。\n\n---\n\n# 第六部分：设计决策与边界\n\n## 23. 对象分类\n\n| 类型 | 对象 | 原因 |\n| --- | --- | --- |\n| **正式事务表** | `person_profiles`、`person_identity_links`、`support_tickets`、`support_followups`、`risk_cases`、`review_submission_records`、`quota_reservations` | 需要增删改和业务状态流转 |\n| **不可变事件表** | `im_interaction_records`、`edm_message_events`、`app_touch_events`、`tel_call_records`、`amazon_refund_records`、`oa_refund_records`、`support_assignment_logs`、`im_flow_tags` | 事实一旦发生不应被覆盖 |\n| **快照表** | `person_feature_snapshots`、`contact_context_snapshots`、`audience_snapshots`、`support_performance_snapshots`、`exemption_result_snapshots` | 需要保留某一时点状态以便复盘 |\n| **决策表** | `channel_route_decisions`、`channel_dedup_records`、`interaction_recheck_records`、`refund_match_results` | 保存系统当时为什么这样判断 |\n| **聚合画像** | `edm_user_behavior_profiles` | 由事件聚合推导，定期刷新 |\n| **可先做视图** | 当前剩余额度、当前风险摘要、当前上下文卡、当前人群统计看板、当前绩效看板 | 可由底层对象实时聚合 |\n\n### 判断法\n\n| 问题 | 如果答案是\"是\" |\n| --- | --- |\n| 后续需要追责\"当时为什么这么做\"吗 | 建正式表或决策表 |\n| 数据后来会变，但历史判断不能跟着变吗 | 建快照 |\n| 只是为了当前页面展示吗 | 优先做视图 |\n| 一旦发生就不该被覆盖吗 | 建事件表 |\n\n## 24. 当前还不能只靠\"老表扩列\"解决的事情\n\n| 问题 | 为什么不能只扩列 |\n| --- | --- |\n| 一个真实人多个账号 | `users` 是账号级，不是人级 |\n| 每次互动重判 | 不是用户静态属性，而是一次次决策事实 |\n| 人群为什么入选/排除 | 不是计划表字段，而是某一批次结果 |\n| 多计划并发占额度 | 需要独立预占 |\n| 用户提交与展示拆分 | 不是一个布尔值能表达 |\n| 退款比对 | 需要两个来源事实加一个比对结果 |\n| 客服上下文 | 不是工单表本身，而是跨源聚合视图+快照 |\n\n## 25. 当前可以先不做成物理表的内容\n\n| 内容 | 当前建议 |\n| --- | --- |\n| 当前剩余额度 | 先由 `person_quota_ledgers + quota_reservations` 聚合成视图 |\n| 当前风险摘要 | 先由 `risk_signals + risk_cases + blacklist_entities` 聚合成视图 |\n| 当前客服上下文卡 | 前台读当前视图，关键接入动作时写 `contact_context_snapshots` |\n| 当前人群统计看板 | 先基于 `audience_snapshots / exclusions` 聚合 |\n| 当前绩效看板 | 先基于工单、通话、跟进事件聚合，后续再沉淀快照 |\n\n## 26. 外部数据引用原则\n\n| 外部数据 | 所属系统 | USER 当前做法 |\n| --- | --- | --- |\n| Amazon 订单全量明细 | Amazon API/报表 | 导入关键字段，不把 USER 做成全量订单数仓 |\n| JOYHUB 用户行为明细 | APP/用户系统 | 取摘要或增量同步，用于画像与上下文 |\n| 黑名单全量数据 | 黑名单系统 | 引用并缓存关键维度，不重复建设 |\n| JOYCOLLAB 全量内容与带货明细 | JOYCOLLAB | 同步 USER 闭环所需结果摘要 |\n| 财务/人事原始表 | 财务/人事系统 | 导入必要摘要，不替代源系统 |\n\n## 27. 涉密字段处理\n\n| 涉密字段 | 建议存储 | 建议查询 |\n| --- | --- | --- |\n| 订单号 | 哈希索引 + 加密原值 | 常规用哈希匹配 |\n| 邮箱 | 哈希索引 + 脱敏展示 | 普通页面不暴露明文 |\n| 电话 | 哈希索引 + 加密原值 | 仅授权角色可揭示 |\n| 姓名/地址 | 标准化值 + 哈希/指纹 | 归并与风险用指纹 |\n| 设备号 | 哈希索引 | 归并/风险用哈希 |\n| IP | 脱敏存储 | 仅用于弱关联 |\n| 收款信息 | 加密存储 | 财务/风险授权查看 |\n| 返款金额/提成 | 权限控制 | 财务角色优先 |\n\n## 28. 快照策略\n\n| 快照对象 | 生成时机 | 保留策略 |\n| --- | --- | --- |\n| `person_feature_snapshots` | 定期刷新 + 人群生成前触发 | 保留最近 N 版 + 每次人群生成引用的版本 |\n| `contact_context_snapshots` | 用户接入/工单创建/拨打前/风险升级 | 每次生成新快照，保留全量历史 |\n| `audience_snapshots` | 人群生成时 | 每次计划保留 |\n| `edm_user_behavior_profiles` | EDM 画像定时刷新 | 按刷新批次保留 |\n| `support_performance_snapshots` | 每日/每周/每月 | 按周期聚合保留 |\n| `exemption_result_snapshots` | 免评执行阶段性同步 | 按结果周期保留 |\n\n---\n\n# 第七部分：谁写谁读\n\n## 29. 读写矩阵\n\n| 对象 | 主要写入方 | 主要读取方 | 依赖它的动作 |\n| --- | --- | --- | --- |\n| `person_profiles` | 身份归并服务 | 用户运营、客服、风险 | 所有真实人级判断 |\n| `person_identity_links` | 身份归并服务 | 风险、客服、订单核验 | 真实人识别 |\n| `person_feature_snapshots` | 画像任务 | 人群生成、客服 | 画像筛选 |\n| `contact_context_snapshots` | 上下文聚合服务 | 客服、用户运营 | 接入处理 |\n| `person_quota_ledgers` | 额度服务 | 人群生成、渠道、客服 | 4/4/12 判断 |\n| `quota_reservations` | 人群/计划服务 | 渠道、额度服务 | 发送前拦截 |\n| `audience_snapshots` | 人群生成服务 | 计划、复盘 | 解释入选 |\n| `channel_route_decisions` | 路由服务 | 推送、复盘 | 选渠道 |\n| `interaction_recheck_records` | 互动复检服务 | 客服、风险、审计 | 决定继续/拦截 |\n| `review_submission_records` | 客服/IM/TEL | 额度、计划、客服 | 计入12 |\n| `review_display_checks` | 运营/系统 | 计划、ASIN看板 | 计入完成 |\n| `refund_match_results` | 退款比对服务 | 风险、客服、财务 | 拦截双重退款 |\n\n---\n\n## 30. 还需要确认但不阻塞第三步的事项\n\n| 事项 | 影响 |\n| --- | --- |\n| Amazon 订单同步频率最终是否为 10 分钟 | 影响订单/退款数据新鲜度 |\n| 黑名单系统最终通过 API、表格还是消息同步 | 影响 `blacklist_entities` 同步方式 |\n| Amazon Profile ID 是否稳定获取 | 影响强关联覆盖率 |\n| APP 设备型号能否拿到具体型号还是只到类型 | 影响客服展示颗粒度 |\n| 年龄字段来自注册资料还是推断 | 影响画像可信度 |\n| KOC/KOL 结果同步周期 | 影响免评结果快照频率 |\n\n---\n\n## 31. 第四步入口\n\n1. **把数据对象转成逻辑 ER 图**：以 §20 的 Mermaid ER 图为基础，明确主键、外键、1对多/多对多关系，区分复用旧表和新增表。\n2. **按关键链路补接口读写**：\n 1. 真实人识别与上下文链路\n 2. 人群/额度/路由链路\n 3. 互动复检/风险链路\n 4. 评价提交/展示与退款比对链路\n 5. 免评结果链路\n3. **回到页面，把每一个点击绑定到明确的数据读写**。\n\n---\n\n## 32. 本版结论\n\nv3 以 Codex v1.1 完整字段字典为主骨架，补入 v2 的流转时序表、写入顺序图和快照策略，形成最终统一主稿：\n\n1. 用 **真实人** 统一账号、订单、设备和风险\n2. 用 **画像快照** 解释人群生成\n3. 用 **额度台账+预占** 保护 4/4/12 规则（跨账号合并）\n4. 用 **路由决策+去重记录** 控制多渠道协同\n5. 用 **互动复检记录** 落实\"每次有效互动都重判\"\n6. 用 **退款比对结果** 识别双重退款\n7. 用 **评价提交记录+展示核验** 拆开用户事实和平台结果\n8. 用 **免评计划→任务→内容→结果快照** 让 KOC/KOL 闭环完整进入 USER 系统\n", + "wikilinks": [], + "category": "layer-requirements" + } + }, + { + "id": "doc:05_需求文档/README", + "type": "document", + "name": "需求文档", + "filePath": "05_需求文档/README.md", + "summary": "type: requirement inbox tags: 需求文档, 需求收集, 知识库更新, Agent aliases: 需求文档目录, 需求收集目录, 需求入口 source: manual status: active owner: 产品经理 / 业务主管 updated: 2026 05 需求文档 本目录用于集中存放后续持续补充的业务需求文档、业", + "tags": [ + "05_需求文档", + "需求文档", + "需求收集", + "知识库更新", + "Agent" + ], + "complexity": "simple", + "knowledgeMeta": { + "content": "---\ntype: requirement_inbox\ntags: [需求文档, 需求收集, 知识库更新, Agent]\naliases: [需求文档目录, 需求收集目录, 需求入口]\nsource: manual\nstatus: active\nowner: 产品经理 / 业务主管\nupdated: 2026-05\n---\n\n# 需求文档\n\n本目录用于集中存放后续持续补充的业务需求文档、业务规则文档、流程补充文档和需求变更文档。\n\n## 使用方式\n\n1. 所有新增需求文档优先放入本目录。\n2. 建议使用 `03_规范与模板/需求说明模板.md` 或 `03_规范与模板/业务规则与需求补充模板.md` 创建文档。\n3. 文档确认有效后，同步更新业务流程索引和 Agent 检索索引。\n4. Agent 回答具体业务需求时，应优先检索本目录。\n\n## 推荐命名\n\n```text\n业务域_需求或规则名称_YYYYMMDD.md\n```\n\n示例：\n\n```text\n采购_供应商准入规则_20260526.md\n库存_出入库审批规则_20260526.md\n销售_客户授信额度需求_20260526.md\n```\n\n## 文档状态\n\n每个需求文档建议在 Frontmatter 中维护 `status`：\n\n| 状态 | 含义 |\n|---|---|\n| draft | 草稿，尚未确认 |\n| reviewing | 评审中 |\n| active | 已确认，可作为 Agent 回答依据 |\n| deprecated | 已废弃，仅归档参考 |\n\n## 必填内容\n\n每个需求文档至少包含：\n\n- 需求背景\n- 适用范围\n- 涉及角色\n- 业务规则\n- 业务流程\n- 异常处理\n- 权限要求\n- 验收口径\n- Agent 检索字段\n- 变更记录\n\n## 索引维护\n\n新增或修改需求文档后，需要同步更新：\n\n- `05_需求文档/需求文档索引.md`\n- `01_业务流程/业务规则索引.md`\n- `01_业务流程/业务对象字典.md`\n- `04_Agent检索/关键词索引.md`\n- `04_Agent检索/同义词表.md`\n- `04_Agent检索/来源文件索引.md`\n\n## 验证流程\n\n新增需求文档后，按 `04_Agent检索/知识库持续更新与验证流程.md` 执行验证，并将验证结果记录到：\n\n- `05_需求文档/需求文档索引.md`\n- `01_业务流程/业务补充验证记录.md`\n", + "wikilinks": [], + "category": "layer-requirements" + } + }, + { + "id": "doc:05_需求文档/需求文档索引", + "type": "document", + "name": "需求文档索引", + "filePath": "05_需求文档/需求文档索引.md", + "summary": "type: requirement index tags: 需求文档, 索引, Agent检索 aliases: 需求索引, 需求文档清单, 需求清单 source: manual status: active owner: 产品经理 / 业务主管 updated: 2026 05 需求文档索引 本文件记录 05 需求文档/ 下所有正式需求文档，供人工维护和", + "tags": [ + "05_需求文档", + "需求文档", + "索引", + "Agent检索" + ], + "complexity": "simple", + "knowledgeMeta": { + "content": "---\ntype: requirement_index\ntags: [需求文档, 索引, Agent检索]\naliases: [需求索引, 需求文档清单, 需求清单]\nsource: manual\nstatus: active\nowner: 产品经理 / 业务主管\nupdated: 2026-05\n---\n\n# 需求文档索引\n\n本文件记录 `05_需求文档/` 下所有正式需求文档，供人工维护和 Agent 检索定位。\n\n## 需求文档清单\n\n| 编号 | 业务域 | 需求/规则名称 | 文件 | 状态 | 负责人 | 更新时间 | 验证状态 |\n|---|---|---|---|---|---|---|---|\n| | | | | | | | 未验证 |\n\n## Agent 检索关键词\n\n| 关键词/问法 | 标准术语 | 命中文件 | 答案要点 |\n|---|---|---|---|\n| | | | |\n\n## 维护规则\n\n1. 新增需求文档后，必须在“需求文档清单”新增一行。\n2. 每个需求文档至少维护 3 个可检索问法。\n3. `状态=active` 的文档可作为 Agent 回答依据。\n4. `status=draft/reviewing` 的文档只能作为草稿参考，Agent 回答时需说明尚未确认。\n5. `status=deprecated` 的文档不得作为当前规则依据，只能说明历史背景。\n\n## 验证记录摘要\n\n| 日期 | 文件 | 验证问题数 | 通过数 | 失败数 | 结论 |\n|---|---|---:|---:|---:|---|\n| | | | | | |\n", + "wikilinks": [], + "category": "layer-requirements" + } + }, + { + "id": "doc:06_里程碑/README", + "type": "document", + "name": "里程碑", + "filePath": "06_里程碑/README.md", + "summary": "本目录用于存放项目阶段计划、里程碑节点、阶段评审记录和上线节奏说明。", + "tags": [ + "06_里程碑", + "里程碑" + ], + "complexity": "simple", + "knowledgeMeta": { + "content": "---\ntype: milestone_home\ntags: [里程碑, 项目管理, 知识库]\naliases: [里程碑入口, 项目里程碑]\nsource: manual\nstatus: active\nowner: 项目经理\nupdated: 2026-05\n---\n\n# 里程碑\n\n本目录用于存放项目阶段计划、里程碑节点、阶段评审记录和上线节奏说明。\n\n## 二级入口\n\n- [[里程碑索引]]\n- [[阶段计划模板]]\n- [[里程碑评审记录]]\n\n## 存放内容\n\n- 项目启动节点\n- 需求评审节点\n- 原型/高保真确认节点\n- 开发启动节点\n- 测试准入节点\n- 上线检查节点\n- 复盘回流节点\n\n## 命名建议\n\n```text\n项目名_里程碑计划_YYYYMMDD.md\n项目名_阶段评审记录_YYYYMMDD.md\n```\n\n## 关联目录\n\n- 需求依据：[[../05_需求文档/README|需求文档]]\n- 流程依据：[[../02_项目管理流程/AI驱动内部系统开发流程_V3_总览|项目管理流程]]\n- 测试准入：[[../08_测试相关/README|测试相关]]\n", + "wikilinks": [], + "category": "layer-milestones" + } + }, + { + "id": "doc:06_里程碑/里程碑索引", + "type": "document", + "name": "里程碑索引", + "filePath": "06_里程碑/里程碑索引.md", + "summary": "- 新增里程碑计划后，在本索引登记。", + "tags": [ + "06_里程碑", + "里程碑" + ], + "complexity": "simple", + "knowledgeMeta": { + "content": "---\ntype: milestone_index\ntags: [里程碑, 索引, Agent检索]\naliases: [里程碑清单, 项目节点索引]\nsource: manual\nstatus: active\nowner: 项目经理\nupdated: 2026-05\n---\n\n# 里程碑索引\n\n## 里程碑文档清单\n\n| 项目 | 里程碑名称 | 文件 | 阶段 | 负责人 | 计划时间 | 当前状态 |\n|---|---|---|---|---|---|---|\n| | | | | | | |\n\n## Agent 检索关键词\n\n| 问法 | 标准术语 | 命中文件 | 答案要点 |\n|---|---|---|---|\n| | | | |\n\n## 维护规则\n\n- 新增里程碑计划后，在本索引登记。\n- 每个里程碑应关联至少一个需求文档或项目管理阶段。\n- Agent 回答项目进度、节点、准入问题时，应引用本索引或具体里程碑文件。\n", + "wikilinks": [], + "category": "layer-milestones" + } + }, + { + "id": "doc:06_里程碑/里程碑评审记录", + "type": "document", + "name": "里程碑评审记录", + "filePath": "06_里程碑/里程碑评审记录.md", + "summary": "知识库文档。", + "tags": [ + "06_里程碑", + "里程碑" + ], + "complexity": "simple", + "knowledgeMeta": { + "content": "---\ntype: milestone_review_log\ntags: [里程碑, 评审, 记录]\naliases: [阶段评审记录, 里程碑评审]\nsource: manual\nstatus: active\nowner: 项目经理\nupdated: 2026-05\n---\n\n# 里程碑评审记录\n\n| 日期 | 项目 | 阶段 | 评审结论 | 遗留问题 | 负责人 | 后续动作 |\n|---|---|---|---|---|---|---|\n| | | | | | | |\n", + "wikilinks": [], + "category": "layer-milestones" + } + }, + { + "id": "doc:06_里程碑/阶段计划模板", + "type": "document", + "name": "阶段计划模板", + "filePath": "06_里程碑/阶段计划模板.md", + "summary": "- 需求文档：", + "tags": [ + "06_里程碑", + "里程碑" + ], + "complexity": "simple", + "knowledgeMeta": { + "content": "---\ntype: milestone_template\ntags: [里程碑, 阶段计划, 模板]\naliases: [阶段计划, 里程碑模板]\nsource: manual\nstatus: active\nowner: 项目经理\nupdated: 2026-05\n---\n\n# 阶段计划模板\n\n## 基本信息\n\n| 项目 | 内容 |\n|---|---|\n| 项目名称 | |\n| 关联需求 | |\n| 当前阶段 | |\n| 负责人 | |\n| 计划开始 | |\n| 计划结束 | |\n\n## 阶段目标\n\n\n## 输入材料\n\n- 需求文档：\n- 业务流程：\n- 技术文档：\n- 测试材料：\n\n## 关键任务\n\n| 任务 | 负责人 | 截止时间 | 输出物 | 状态 |\n|---|---|---|---|---|\n| | | | | |\n\n## 阶段交付物\n\n\n## 准入/准出条件\n\n\n## 风险与阻塞\n\n\n## Agent 检索字段\n\n- 关键词：\n- 同义词：\n- 典型问法：\n", + "wikilinks": [], + "category": "layer-milestones" + } + }, + { + "id": "doc:07_技术文档/README", + "type": "document", + "name": "技术文档", + "filePath": "07_技术文档/README.md", + "summary": "本目录用于存放系统架构、数据模型、接口说明、实现方案、部署说明和技术决策记录。", + "tags": [ + "07_技术文档", + "技术文档" + ], + "complexity": "simple", + "knowledgeMeta": { + "content": "---\ntype: technical_docs_home\ntags: [技术文档, 架构, 开发, 知识库]\naliases: [技术文档入口, 技术资料]\nsource: manual\nstatus: active\nowner: 技术负责人\nupdated: 2026-05\n---\n\n# 技术文档\n\n本目录用于存放系统架构、数据模型、接口说明、实现方案、部署说明和技术决策记录。\n\n## 二级入口\n\n- [[技术文档索引]]\n- [[系统架构说明模板]]\n- [[接口说明模板]]\n- [[技术决策记录]]\n\n## 存放内容\n\n- 系统架构说明\n- 模块设计说明\n- 数据表/业务对象设计\n- API 接口说明\n- 权限与安全设计\n- 部署与配置说明\n- 技术决策记录\n\n## 命名建议\n\n```text\n系统或模块_技术方案_YYYYMMDD.md\n系统或模块_接口说明_YYYYMMDD.md\n系统或模块_数据模型_YYYYMMDD.md\n```\n\n## 关联目录\n\n- 需求依据：[[../05_需求文档/README|需求文档]]\n- 测试依据：[[../08_测试相关/README|测试相关]]\n- 里程碑：[[../06_里程碑/README|里程碑]]\n", + "wikilinks": [], + "category": "layer-technical" + } + }, + { + "id": "doc:07_技术文档/技术决策记录", + "type": "document", + "name": "技术决策记录", + "filePath": "07_技术文档/技术决策记录.md", + "summary": "知识库文档。", + "tags": [ + "07_技术文档", + "技术文档" + ], + "complexity": "simple", + "knowledgeMeta": { + "content": "---\ntype: adr_log\ntags: [技术文档, 技术决策, ADR]\naliases: [技术决策, ADR]\nsource: manual\nstatus: active\nowner: 技术负责人\nupdated: 2026-05\n---\n\n# 技术决策记录\n\n| 日期 | 决策主题 | 背景 | 决策结论 | 影响范围 | 关联需求/技术文档 |\n|---|---|---|---|---|---|\n| | | | | | |\n", + "wikilinks": [], + "category": "layer-technical" + } + }, + { + "id": "doc:07_技术文档/技术文档索引", + "type": "document", + "name": "技术文档索引", + "filePath": "07_技术文档/技术文档索引.md", + "summary": "- 新增技术方案、接口说明、数据模型后，在本索引登记。", + "tags": [ + "07_技术文档", + "技术文档" + ], + "complexity": "simple", + "knowledgeMeta": { + "content": "---\ntype: technical_docs_index\ntags: [技术文档, 索引, Agent检索]\naliases: [技术索引, 技术资料清单]\nsource: manual\nstatus: active\nowner: 技术负责人\nupdated: 2026-05\n---\n\n# 技术文档索引\n\n## 技术文档清单\n\n| 模块/系统 | 文档类型 | 文件 | 关联需求 | 负责人 | 更新时间 | 状态 |\n|---|---|---|---|---|---|---|\n| | | | | | | |\n\n## Agent 检索关键词\n\n| 问法 | 标准术语 | 命中文件 | 答案要点 |\n|---|---|---|---|\n| | | | |\n\n## 维护规则\n\n- 新增技术方案、接口说明、数据模型后，在本索引登记。\n- 技术文档必须关联需求文档或业务流程。\n- Agent 回答技术实现、接口、数据结构问题时，应优先检索本目录。\n", + "wikilinks": [], + "category": "layer-technical" + } + }, + { + "id": "doc:07_技术文档/接口说明模板", + "type": "document", + "name": "接口说明模板", + "filePath": "07_技术文档/接口说明模板.md", + "summary": "- 关键词：", + "tags": [ + "07_技术文档", + "技术文档" + ], + "complexity": "simple", + "knowledgeMeta": { + "content": "---\ntype: api_template\ntags: [技术文档, 接口, 模板]\naliases: [接口模板, API说明模板]\nsource: manual\nstatus: active\nowner: 技术负责人\nupdated: 2026-05\n---\n\n# 接口说明模板\n\n## 基本信息\n\n| 项目 | 内容 |\n|---|---|\n| 接口名称 | |\n| 所属模块 | |\n| 关联需求 | |\n| 负责人 | |\n| 状态 | draft |\n\n## 接口用途\n\n\n## 请求说明\n\n| 字段 | 类型 | 必填 | 说明 | 示例 |\n|---|---|---|---|---|\n| | | | | |\n\n## 响应说明\n\n| 字段 | 类型 | 说明 | 示例 |\n|---|---|---|---|\n| | | | |\n\n## 业务规则\n\n\n## 异常码\n\n| 异常码 | 含义 | 处理方式 |\n|---|---|---|\n| | | |\n\n## Agent 检索字段\n\n- 关键词：\n- 同义词：\n- 典型问法：\n", + "wikilinks": [], + "category": "layer-technical" + } + }, + { + "id": "doc:07_技术文档/系统架构说明模板", + "type": "document", + "name": "系统架构说明模板", + "filePath": "07_技术文档/系统架构说明模板.md", + "summary": "- 关键词：", + "tags": [ + "07_技术文档", + "技术文档" + ], + "complexity": "simple", + "knowledgeMeta": { + "content": "---\ntype: architecture_template\ntags: [技术文档, 架构, 模板]\naliases: [架构说明模板]\nsource: manual\nstatus: active\nowner: 技术负责人\nupdated: 2026-05\n---\n\n# 系统架构说明模板\n\n## 基本信息\n\n| 项目 | 内容 |\n|---|---|\n| 系统/模块 | |\n| 关联需求 | |\n| 负责人 | |\n| 状态 | draft |\n\n## 背景与目标\n\n\n## 架构说明\n\n\n## 模块划分\n\n| 模块 | 职责 | 输入 | 输出 | 依赖 |\n|---|---|---|---|---|\n| | | | | |\n\n## 数据模型\n\n\n## 接口关系\n\n\n## 权限与安全\n\n\n## 异常与边界\n\n\n## 部署与配置\n\n\n## Agent 检索字段\n\n- 关键词：\n- 同义词：\n- 典型问法：\n", + "wikilinks": [], + "category": "layer-technical" + } + }, + { + "id": "doc:08_测试相关/README", + "type": "document", + "name": "测试相关", + "filePath": "08_测试相关/README.md", + "summary": "本目录用于存放测试计划、测试用例、测试报告、缺陷记录、验收记录和上线检查材料。", + "tags": [ + "08_测试相关", + "测试相关" + ], + "complexity": "simple", + "knowledgeMeta": { + "content": "---\ntype: testing_home\ntags: [测试, 测试用例, 验收, 知识库]\naliases: [测试相关入口, 测试文档]\nsource: manual\nstatus: active\nowner: 测试负责人\nupdated: 2026-05\n---\n\n# 测试相关\n\n本目录用于存放测试计划、测试用例、测试报告、缺陷记录、验收记录和上线检查材料。\n\n## 二级入口\n\n- [[测试用例索引]]\n- [[测试用例模板]]\n- [[测试计划模板]]\n- [[缺陷记录模板]]\n- [[验收记录模板]]\n- [[上线检查模板]]\n\n## 存放内容\n\n- 测试计划\n- 测试用例\n- 测试执行记录\n- 缺陷记录\n- 验收记录\n- 上线检查记录\n- 回归测试说明\n\n## 命名建议\n\n```text\n项目或模块_测试用例_YYYYMMDD.md\n项目或模块_测试计划_YYYYMMDD.md\n项目或模块_缺陷记录_YYYYMMDD.md\n项目或模块_验收记录_YYYYMMDD.md\n```\n\n## 关联目录\n\n- 需求依据：[[../05_需求文档/README|需求文档]]\n- 技术依据：[[../07_技术文档/README|技术文档]]\n- 里程碑依据：[[../06_里程碑/README|里程碑]]\n- 流程依据：[[../02_项目管理流程/阶段2.5_测试提前补漏|阶段2.5 测试提前补漏]]、[[../02_项目管理流程/阶段4_测试培训上线回流|阶段4 测试培训上线回流]]\n", + "wikilinks": [], + "category": "layer-testing" + } + }, + { + "id": "doc:08_测试相关/上线检查模板", + "type": "document", + "name": "上线检查模板", + "filePath": "08_测试相关/上线检查模板.md", + "summary": "- 关键词：", + "tags": [ + "08_测试相关", + "测试相关" + ], + "complexity": "simple", + "knowledgeMeta": { + "content": "---\ntype: go_live_checklist_template\ntags: [上线检查, 测试, 模板]\naliases: [上线检查, 发布检查]\nsource: manual\nstatus: active\nowner: 测试负责人 / 项目经理\nupdated: 2026-05\n---\n\n# 上线检查模板\n\n## 基本信息\n\n| 项目 | 内容 |\n|---|---|\n| 项目/模块 | |\n| 关联需求 | |\n| 关联里程碑 | |\n| 负责人 | |\n| 检查日期 | |\n\n## 上线前检查项\n\n| 检查项 | 负责人 | 结果 | 备注 |\n|---|---|---|---|\n| 需求已确认 | | | |\n| 测试用例已执行 | | | |\n| P0/P1 缺陷已关闭 | | | |\n| 用户培训已完成 | | | |\n| 回滚方案已确认 | | | |\n| 数据备份已确认 | | | |\n\n## 上线结论\n\n\n## 回滚条件\n\n\n## Agent 检索字段\n\n- 关键词：\n- 同义词：\n- 典型问法：\n", + "wikilinks": [], + "category": "layer-testing" + } + }, + { + "id": "doc:08_测试相关/测试用例模板", + "type": "document", + "name": "测试用例模板", + "filePath": "08_测试相关/测试用例模板.md", + "summary": "- 关键词：", + "tags": [ + "08_测试相关", + "测试相关" + ], + "complexity": "simple", + "knowledgeMeta": { + "content": "---\ntype: test_case_template\ntags: [测试用例, 测试, 模板]\naliases: [用例模板, 测试用例]\nsource: manual\nstatus: active\nowner: 测试负责人\nupdated: 2026-05\n---\n\n# 测试用例模板\n\n## 基本信息\n\n| 项目 | 内容 |\n|---|---|\n| 项目/模块 | |\n| 关联需求 | |\n| 关联技术文档 | |\n| 测试负责人 | |\n| 状态 | draft |\n\n## 测试范围\n\n\n## 前置条件\n\n\n## 测试用例\n\n| 用例编号 | 场景 | 前置条件 | 操作步骤 | 预期结果 | 优先级 | 状态 |\n|---|---|---|---|---|---|---|\n| TC-001 | | | | | P1 | 未执行 |\n\n## 边界与异常场景\n\n\n## 验收口径\n\n\n## Agent 检索字段\n\n- 关键词：\n- 同义词：\n- 典型问法：\n", + "wikilinks": [], + "category": "layer-testing" + } + }, + { + "id": "doc:08_测试相关/测试用例索引", + "type": "document", + "name": "测试用例索引", + "filePath": "08_测试相关/测试用例索引.md", + "summary": "- 新增测试用例后，必须在本索引登记。", + "tags": [ + "08_测试相关", + "测试相关" + ], + "complexity": "simple", + "knowledgeMeta": { + "content": "---\ntype: test_case_index\ntags: [测试用例, 测试, 索引, Agent检索]\naliases: [测试用例清单, 用例索引]\nsource: manual\nstatus: active\nowner: 测试负责人\nupdated: 2026-05\n---\n\n# 测试用例索引\n\n## 测试用例清单\n\n| 编号 | 项目/模块 | 用例集名称 | 文件 | 关联需求 | 关联技术文档 | 负责人 | 状态 | 更新时间 |\n|---|---|---|---|---|---|---|---|---|\n| | | | | | | | 未验证 | |\n\n## Agent 检索关键词\n\n| 问法 | 标准术语 | 命中文件 | 答案要点 |\n|---|---|---|---|\n| | | | |\n\n## 维护规则\n\n- 新增测试用例后，必须在本索引登记。\n- 每个测试用例文件必须关联至少一个需求文档。\n- 若测试用例依赖接口、数据模型或技术方案，应关联技术文档。\n- Agent 回答测试范围、验收口径、缺陷复现问题时，应优先检索本目录。\n", + "wikilinks": [], + "category": "layer-testing" + } + }, + { + "id": "doc:08_测试相关/测试计划模板", + "type": "document", + "name": "测试计划模板", + "filePath": "08_测试相关/测试计划模板.md", + "summary": "- 关键词：", + "tags": [ + "08_测试相关", + "测试相关" + ], + "complexity": "simple", + "knowledgeMeta": { + "content": "---\ntype: test_plan_template\ntags: [测试计划, 测试, 模板]\naliases: [测试计划模板]\nsource: manual\nstatus: active\nowner: 测试负责人\nupdated: 2026-05\n---\n\n# 测试计划模板\n\n## 基本信息\n\n| 项目 | 内容 |\n|---|---|\n| 项目/模块 | |\n| 关联需求 | |\n| 关联里程碑 | |\n| 测试负责人 | |\n| 计划周期 | |\n\n## 测试目标\n\n\n## 测试范围\n\n\n## 不在范围内\n\n\n## 测试资源\n\n\n## 测试安排\n\n| 阶段 | 时间 | 负责人 | 输出物 |\n|---|---|---|---|\n| | | | |\n\n## 准入条件\n\n\n## 准出条件\n\n\n## 风险\n\n\n## Agent 检索字段\n\n- 关键词：\n- 同义词：\n- 典型问法：\n", + "wikilinks": [], + "category": "layer-testing" + } + }, + { + "id": "doc:08_测试相关/缺陷记录模板", + "type": "document", + "name": "缺陷记录模板", + "filePath": "08_测试相关/缺陷记录模板.md", + "summary": "1.", + "tags": [ + "08_测试相关", + "测试相关" + ], + "complexity": "simple", + "knowledgeMeta": { + "content": "---\ntype: defect_template\ntags: [缺陷, 测试, 模板]\naliases: [Bug记录模板, 缺陷记录]\nsource: manual\nstatus: active\nowner: 测试负责人\nupdated: 2026-05\n---\n\n# 缺陷记录模板\n\n## 基本信息\n\n| 项目 | 内容 |\n|---|---|\n| 缺陷编号 | BUG- |\n| 项目/模块 | |\n| 关联需求 | |\n| 关联用例 | |\n| 严重级别 | |\n| 当前状态 | open |\n| 负责人 | |\n\n## 问题描述\n\n\n## 复现步骤\n\n1. \n2. \n3. \n\n## 实际结果\n\n\n## 预期结果\n\n\n## 影响范围\n\n\n## 修复结论\n\n\n## 回归验证\n\n\n## Agent 检索字段\n\n- 关键词：\n- 同义词：\n- 典型问法：\n", + "wikilinks": [], + "category": "layer-testing" + } + }, + { + "id": "doc:08_测试相关/验收记录模板", + "type": "document", + "name": "验收记录模板", + "filePath": "08_测试相关/验收记录模板.md", + "summary": "- 关键词：", + "tags": [ + "08_测试相关", + "测试相关" + ], + "complexity": "simple", + "knowledgeMeta": { + "content": "---\ntype: acceptance_template\ntags: [验收, 测试, 模板]\naliases: [验收记录, UAT模板]\nsource: manual\nstatus: active\nowner: 测试负责人 / 业务负责人\nupdated: 2026-05\n---\n\n# 验收记录模板\n\n## 基本信息\n\n| 项目 | 内容 |\n|---|---|\n| 项目/模块 | |\n| 关联需求 | |\n| 关联测试用例 | |\n| 验收负责人 | |\n| 验收日期 | |\n| 验收结论 | |\n\n## 验收范围\n\n\n## 验收结果\n\n| 验收项 | 预期结果 | 实际结果 | 结论 | 备注 |\n|---|---|---|---|---|\n| | | | | |\n\n## 遗留问题\n\n\n## 上线建议\n\n\n## Agent 检索字段\n\n- 关键词：\n- 同义词：\n- 典型问法：\n", + "wikilinks": [], + "category": "layer-testing" + } + }, + { + "id": "doc:欢迎", + "type": "document", + "name": "欢迎使用如愿知识库", + "filePath": "欢迎.md", + "summary": "请从 [[00_首页/知识库首页]] 开始。", + "tags": [ + "欢迎.md" + ], + "complexity": "simple", + "knowledgeMeta": { + "content": "---\ntype: index\ntags: [知识库, 入口]\naliases: [欢迎, 首页]\nsource: manual\nstatus: active\nowner: 内部技术团队\nupdated: 2026-05\n---\n\n# 欢迎使用如愿知识库\n\n请从 [[00_首页/知识库首页]] 开始。\n\n常用入口：\n\n- [[知识库使用说明]]\n- [[00_首页/知识地图]]\n- [[00_首页/Agent问答入口]]\n- [[05_需求文档/README|需求文档]]\n- [[06_里程碑/README|里程碑]]\n- [[07_技术文档/README|技术文档]]\n- [[08_测试相关/README|测试相关]]\n- [[04_Agent检索/检索说明]]", + "wikilinks": [], + "category": "layer-overview" + } + }, + { + "id": "doc:知识库使用说明", + "type": "document", + "name": "如愿知识库使用说明", + "filePath": "知识库使用说明.md", + "summary": "本文档说明如愿知识库的用途、目录结构、文档存放规则、索引维护规则、Obsidian 图谱使用方式，以及 Agent 如何基于知识库回答问题。", + "tags": [ + "知识库使用说明.md" + ], + "complexity": "moderate", + "knowledgeMeta": { + "content": "---\ntype: knowledge_base_guide\ntags: [知识库, 使用说明, Obsidian, Agent检索]\naliases: [如愿知识库使用说明, 知识库操作说明, 知识库维护说明]\nsource: manual\nstatus: active\nowner: 内部技术团队\nupdated: 2026-05\n---\n\n# 如愿知识库使用说明\n\n本文档说明如愿知识库的用途、目录结构、文档存放规则、索引维护规则、Obsidian 图谱使用方式，以及 Agent 如何基于知识库回答问题。\n\n## 1. 知识库定位\n\n如愿知识库用于沉淀内部系统建设过程中的：\n\n- 业务需求\n- 业务规则\n- 业务流程\n- 项目里程碑\n- 技术方案\n- 测试用例\n- 缺陷与验收记录\n- Agent 检索规则\n\n知识库不是单纯存文件，而是要形成可检索、可追溯、可被 Agent 引用回答的知识网络。\n\n## 2. 推荐打开方式\n\n推荐使用 Obsidian 打开以下目录作为 Vault：\n\n```text\nD:\\AIcoding\\WishFulfilled\\知识库\\如愿知识库\n```\n\n打开后建议从以下入口开始：\n\n1. [[欢迎]]\n2. [[00_首页/知识库首页]]\n3. [[00_首页/知识地图]]\n4. [[00_首页/Agent问答入口]]\n5. [[04_Agent检索/检索说明]]\n\n## 3. 主目录说明\n\n```text\n如愿知识库/\n├─ 00_首页/ # 首页、知识地图、Agent 问答入口\n├─ 01_业务流程/ # 业务流程、业务对象、业务规则、补充验证记录\n├─ 02_项目管理流程/ # 项目阶段、角色职责、交付物、检查清单、FAQ\n├─ 03_规范与模板/ # 需求、业务规则、会议、上线检查等模板\n├─ 04_Agent检索/ # 检索说明、关键词、同义词、来源文件索引\n├─ 05_需求文档/ # 正式需求文档、需求索引\n├─ 06_里程碑/ # 里程碑计划、阶段计划、评审记录\n├─ 07_技术文档/ # 技术方案、系统架构、接口说明、技术决策\n├─ 08_测试相关/ # 测试用例、测试计划、缺陷、验收、上线检查\n├─ 99_归档/ # 历史文档、废弃文档、仅供参考内容\n├─ 欢迎.md # Obsidian 入口页\n├─ 知识库使用说明.md # 本文档\n└─ Git使用说明.md # Git 仓库协作说明\n```\n\n## 4. 日常使用入口\n\n| 使用场景 | 优先入口 |\n|---|---|\n| 想了解知识库整体结构 | [[00_首页/知识地图]] |\n| 想让 Agent 回答业务问题 | [[00_首页/Agent问答入口]] |\n| 查看或新增需求 | [[05_需求文档/README]] |\n| 查看或新增里程碑 | [[06_里程碑/README]] |\n| 查看或新增技术方案 | [[07_技术文档/README]] |\n| 查看或新增测试用例 | [[08_测试相关/README]] |\n| 查看项目管理阶段 | [[02_项目管理流程/AI驱动内部系统开发流程_V3_总览]] |\n| 查看 Agent 检索规则 | [[04_Agent检索/检索说明]] |\n| 查看来源依据 | [[04_Agent检索/来源文件索引]] |\n\n## 5. 文档应该放在哪里\n\n### 5.1 需求文档\n\n放入：\n\n```text\n05_需求文档/\n```\n\n适合存放：\n\n- 正式需求说明\n- 业务规则说明\n- 需求变更说明\n- 业务补充说明\n- 产品口径说明\n\n推荐命名：\n\n```text\n业务域_需求或规则名称_YYYYMMDD.md\n```\n\n示例：\n\n```text\nUSER评价业务闭环_数据流与中间对象设计_20260517.md\n采购_供应商准入规则_20260526.md\n库存_出入库审批规则_20260526.md\n```\n\n新增后应同步维护：\n\n- [[05_需求文档/需求文档索引]]\n- [[01_业务流程/业务规则索引]]，如涉及业务规则\n- [[01_业务流程/业务对象字典]]，如涉及新增业务对象\n- [[04_Agent检索/关键词索引]]，如需要 Agent 检索命中\n- [[04_Agent检索/来源文件索引]]，如是新的权威来源\n\n### 5.2 里程碑文档\n\n放入：\n\n```text\n06_里程碑/\n```\n\n适合存放：\n\n- 项目里程碑计划\n- 阶段计划\n- 阶段评审记录\n- 上线节奏\n- 准入/准出记录\n\n推荐命名：\n\n```text\n项目名_里程碑计划_YYYYMMDD.md\n项目名_阶段评审记录_YYYYMMDD.md\n```\n\n新增后应同步维护：\n\n- [[06_里程碑/里程碑索引]]\n\n### 5.3 技术文档\n\n放入：\n\n```text\n07_技术文档/\n```\n\n适合存放：\n\n- 系统架构说明\n- 数据模型说明\n- 接口说明\n- 模块设计\n- 技术方案\n- 部署说明\n- 技术决策记录\n\n推荐命名：\n\n```text\n系统或模块_技术方案_YYYYMMDD.md\n系统或模块_接口说明_YYYYMMDD.md\n系统或模块_数据模型_YYYYMMDD.md\n```\n\n新增后应同步维护：\n\n- [[07_技术文档/技术文档索引]]\n- [[04_Agent检索/关键词索引]]，如需要 Agent 检索\n- [[04_Agent检索/来源文件索引]]，如是新的技术依据\n\n### 5.4 测试相关文档\n\n放入：\n\n```text\n08_测试相关/\n```\n\n适合存放：\n\n- 测试计划\n- 测试用例\n- 缺陷记录\n- 验收记录\n- 上线检查\n- 回归测试记录\n\n推荐命名：\n\n```text\n项目名_模块名_测试计划_YYYYMMDD.md\n项目名_模块名_测试用例_YYYYMMDD.md\n项目名_模块名_缺陷记录_YYYYMMDD.md\n项目名_模块名_验收记录_YYYYMMDD.md\n```\n\n新增后应同步维护：\n\n- [[08_测试相关/测试用例索引]]\n- 关联需求文档\n- 关联里程碑或测试阶段\n\n测试用例必须能追溯到需求来源。\n\n### 5.5 业务流程文档\n\n放入：\n\n```text\n01_业务流程/\n```\n\n适合存放：\n\n- 已稳定的业务流程\n- 业务对象定义\n- 业务规则索引\n- 业务补充验证记录\n\n如果是新需求或尚未确认的业务规则，优先放入 `05_需求文档/`，确认稳定后再沉淀到 `01_业务流程/`。\n\n### 5.6 模板文档\n\n放入：\n\n```text\n03_规范与模板/\n```\n\n适合存放：\n\n- 需求说明模板\n- 业务规则补充模板\n- 会议纪要模板\n- 上线检查模板\n- 通用文档模板\n\n模板只用于复用格式，不应存放具体项目内容。\n\n### 5.7 归档文档\n\n放入：\n\n```text\n99_归档/\n```\n\n适合存放：\n\n- 已废弃文档\n- 历史版本\n- 仅供参考内容\n- 不再作为当前依据的旧规则\n\n归档文档不应作为 Agent 当前回答依据，除非问题明确询问历史背景。\n\n## 6. Agent 检索优先级\n\nAgent 回答问题时，按以下顺序查找依据：\n\n1. `05_需求文档/`：正式需求、业务规则、需求变更。\n2. `06_里程碑/`：项目节点、阶段计划、阶段评审、上线节奏。\n3. `07_技术文档/`：系统架构、数据模型、接口说明、实现方案、技术决策。\n4. `08_测试相关/`：测试计划、测试用例、缺陷记录、验收记录、上线检查。\n5. `02_项目管理流程/`：内部系统开发流程、阶段、角色、门禁、交付物、检查清单。\n6. `01_业务流程/`：真实业务流程、业务对象、业务规则。\n7. `04_Agent检索/`：关键词、同义词、来源索引、回答规则。\n8. `03_规范与模板/`：需要产出模板或文档时使用。\n\nAgent 回答必须注明来源文件。\n\n## 7. 不同问题应该查哪里\n\n| 问题类型 | 优先查找位置 |\n|---|---|\n| 某个需求是什么 | `05_需求文档/`、`05_需求文档/需求文档索引.md` |\n| 某个业务规则是什么 | `05_需求文档/`、`01_业务流程/业务规则索引.md` |\n| 某个业务对象怎么定义 | `01_业务流程/业务对象字典.md`、相关需求文档 |\n| 项目当前到哪个阶段 | `06_里程碑/`、`06_里程碑/里程碑索引.md` |\n| 某阶段要交付什么 | `02_项目管理流程/阶段交付物清单.md` |\n| 技术怎么实现 | `07_技术文档/`、`07_技术文档/技术文档索引.md` |\n| 接口怎么设计 | `07_技术文档/`、具体接口说明文档 |\n| 数据模型怎么设计 | `07_技术文档/`、具体数据模型文档、需求文档 |\n| 测试用例在哪里 | `08_测试相关/`、`08_测试相关/测试用例索引.md` |\n| 缺陷如何记录 | `08_测试相关/缺陷记录模板.md` |\n| 上线前检查什么 | `08_测试相关/上线检查模板.md`、`02_项目管理流程/项目检查清单.md` |\n| Agent 为什么这样回答 | `04_Agent检索/检索说明.md`、`04_Agent检索/来源文件索引.md` |\n\n## 8. 新增文档标准流程\n\n新增文档建议按以下流程操作：\n\n```text\n确定文档类型\n ↓\n放入对应目录\n ↓\n按推荐命名规则命名\n ↓\n补充 Frontmatter\n ↓\n正文写清背景、规则、流程、验收口径\n ↓\n补充 Agent 检索字段\n ↓\n更新对应索引\n ↓\n更新关键词/来源文件索引\n ↓\n在 Obsidian 中检查链接和图谱\n```\n\n## 9. 推荐 Frontmatter\n\n每个正式文档建议在顶部维护 Frontmatter：\n\n```yaml\n---\ntype: requirement\ntags: [需求文档, USER评价业务闭环]\naliases: [数据流与中间对象设计]\nsource: manual\nstatus: active\nowner: 产品经理\nupdated: 2026-05-26\n---\n```\n\n常用字段：\n\n| 字段 | 说明 |\n|---|---|\n| `type` | 文档类型，如 requirement、technical_doc、test_case、milestone |\n| `tags` | 标签，用于 Obsidian 和 Agent 检索 |\n| `aliases` | 别名，便于搜索同义叫法 |\n| `source` | 来源，如 manual、docx、meeting、requirement |\n| `status` | 状态，如 draft、reviewing、active、deprecated |\n| `owner` | 负责人 |\n| `updated` | 最近更新时间 |\n\n## 10. 文档状态说明\n\n| 状态 | 含义 | Agent 使用规则 |\n|---|---|---|\n| `draft` | 草稿 | 只能作为参考，回答时需说明尚未确认 |\n| `reviewing` | 评审中 | 可引用但需说明仍在评审 |\n| `active` | 已确认 | 可作为正式回答依据 |\n| `deprecated` | 已废弃 | 不作为当前规则依据，只能说明历史背景 |\n\n## 11. 索引维护规则\n\n### 11.1 需求索引\n\n新增需求文档后，维护：\n\n```text\n05_需求文档/需求文档索引.md\n```\n\n至少登记：\n\n- 编号\n- 业务域\n- 需求/规则名称\n- 文件路径\n- 状态\n- 负责人\n- 更新时间\n- 验证状态\n\n### 11.2 里程碑索引\n\n新增里程碑后，维护：\n\n```text\n06_里程碑/里程碑索引.md\n```\n\n至少登记：\n\n- 项目\n- 里程碑名称\n- 文件\n- 阶段\n- 负责人\n- 计划时间\n- 当前状态\n\n### 11.3 技术文档索引\n\n新增技术文档后，维护：\n\n```text\n07_技术文档/技术文档索引.md\n```\n\n至少登记：\n\n- 模块/系统\n- 文档类型\n- 文件\n- 关联需求\n- 负责人\n- 更新时间\n- 状态\n\n### 11.4 测试用例索引\n\n新增测试用例后，维护：\n\n```text\n08_测试相关/测试用例索引.md\n```\n\n至少登记：\n\n- 项目\n- 模块\n- 用例名称\n- 文件\n- 关联需求\n- 测试类型\n- 状态\n- 负责人\n\n## 12. Obsidian 链接规则\n\n推荐使用 Obsidian 双链：\n\n```markdown\n[[05_需求文档/需求文档索引]]\n[[07_技术文档/技术文档索引]]\n[[08_测试相关/测试用例索引]]\n```\n\n也可以使用 Markdown 链接：\n\n```markdown\n[需求文档索引](05_需求文档/需求文档索引.md)\n```\n\n优先建议使用双链，方便图谱建立关系。\n\n## 13. Obsidian 图谱说明\n\nObsidian 图谱会显示两类节点：\n\n1. 已存在的 Markdown 文件。\n2. 文档中链接到、但本地还不存在的 Markdown 文件。\n\n如果你只放了一个文件，但图谱出现多个节点，通常是因为该文件引用了其他文档。\n\n示例：\n\n```markdown\n[工作基线 v1.2](20260517_USER评价业务闭环主流程与后续工作基线_v1.2.md)\n```\n\n即使这个文件尚未放入目录，Obsidian 也可能在图谱中显示它。这是“未创建链接 / dangling link”，不是目录里真的多了文件。\n\n如果只想显示真实存在的文件，可在图谱中开启：\n\n```text\n图谱视图 → 筛选 → 仅显示已有文件\n```\n\n如果希望知识链路完整，应把被引用的上游文档补充到对应目录。\n\n## 14. 知识地图维护规则\n\n知识地图文件：\n\n```text\n00_首页/知识地图.md\n```\n\n知识地图只维护主入口和关键二级入口，不需要把每个具体项目文档都放进去。\n\n推荐主结构：\n\n```text\n知识地图\n├─ 需求文档\n├─ 里程碑\n├─ 技术文档\n├─ 测试相关\n└─ Agent 检索\n```\n\n新增普通需求、测试用例、技术方案时，一般只维护对应索引，不需要直接改知识地图。\n\n只有新增重要分类或核心入口时，才更新知识地图。\n\n## 15. Agent 回答规则\n\nAgent 基于知识库回答问题时，应遵守：\n\n1. 先查知识库，再回答。\n2. 优先引用 `active` 状态文档。\n3. 先给结论，再展开依据。\n4. 需求问题优先查需求文档。\n5. 技术问题优先查技术文档。\n6. 测试问题优先查测试相关。\n7. 里程碑问题优先查里程碑。\n8. 如果知识库没有明确记录，回答“知识库未明确记录”。\n9. 不要根据经验补充未记录的事实。\n10. 回答末尾必须说明来源文件。\n\n推荐引用格式：\n\n```text\n来源：05_需求文档/xxx.md\n```\n\n## 16. 测试用例管理要求\n\n测试用例应单独存放在：\n\n```text\n08_测试相关/\n```\n\n每个测试用例应尽量包含：\n\n- 用例编号\n- 关联需求\n- 测试模块\n- 前置条件\n- 操作步骤\n- 预期结果\n- 实际结果\n- 优先级\n- 状态\n- 负责人\n\n测试用例必须关联需求文档或业务规则，避免出现无法追溯来源的测试项。\n\n## 17. 文档关系建议\n\n推荐建立以下关系：\n\n```text\n需求文档\n ↓\n里程碑 / 阶段计划\n ↓\n技术文档\n ↓\n测试计划 / 测试用例\n ↓\n缺陷记录 / 验收记录\n ↓\n上线检查 / 复盘回流\n```\n\n每个下游文档应尽量写明上游来源。\n\n示例：\n\n```markdown\n## 关联文档\n\n- 需求来源：[[05_需求文档/xxx需求文档]]\n- 技术方案：[[07_技术文档/xxx技术方案]]\n- 测试用例：[[08_测试相关/xxx测试用例]]\n```\n\n## 18. 不建议放入知识库的内容\n\n不建议直接放入：\n\n- 密码\n- Token\n- API Key\n- 未脱敏客户隐私\n- 未脱敏订单号、电话、邮箱、地址\n- 临时截图\n- 个人草稿\n- 与项目无关的资料\n\n如果必须记录敏感业务规则，应先脱敏再写入知识库。\n\n## 19. 提交前检查清单\n\n新增或修改文档后，检查：\n\n- [ ] 文件放在正确目录。\n- [ ] 文件名能表达业务域和用途。\n- [ ] 正式文档已写 Frontmatter。\n- [ ] 文档状态正确。\n- [ ] 关键业务规则有来源。\n- [ ] 需求文档已更新需求文档索引。\n- [ ] 技术文档已更新技术文档索引。\n- [ ] 测试用例已更新测试用例索引。\n- [ ] 重要关键词已补充到关键词索引。\n- [ ] 需要追溯的来源已补充到来源文件索引。\n- [ ] Obsidian 链接可以正常跳转，或确认是有意保留的上游虚链接。\n- [ ] 不包含密码、Token、密钥和未脱敏敏感信息。\n\n## 20. 常见问题\n\n### 20.1 为什么只放一个文档，图谱显示多个节点？\n\n因为文档中链接了其他 Markdown 文件。Obsidian 会把被链接但尚未创建的文件也显示成节点。\n\n### 20.2 README.md 为什么会出现在图谱里？\n\n因为 README.md 也是 Markdown 文件，Obsidian 会把它作为普通节点显示。\n\n### 20.3 一个具体项目文档要不要加到知识地图？\n\n通常不需要。具体项目文档登记到对应索引即可。知识地图只放主入口和关键二级入口。\n\n### 20.4 需求文档和业务流程怎么区分？\n\n- 尚在新增、变更、评审中的内容放 `05_需求文档/`。\n- 已稳定、可复用的业务流程沉淀到 `01_业务流程/`。\n\n### 20.5 测试用例应该跟需求还是技术文档关联？\n\n优先关联需求文档；如果测试点来自技术实现细节，再补充关联技术文档。\n\n### 20.6 Agent 回答错了怎么办？\n\n优先检查：\n\n1. 对应文档是否存在。\n2. 文档是否放在正确目录。\n3. 索引是否维护。\n4. 关键词或同义词是否缺失。\n5. 来源文件索引是否登记。\n6. 文档状态是否为 `active`。\n\n必要时更新：\n\n- [[04_Agent检索/关键词索引]]\n- [[04_Agent检索/同义词表]]\n- [[04_Agent检索/来源文件索引]]\n- [[04_Agent检索/知识库持续更新与验证流程]]\n\n## 21. 维护原则\n\n1. 文档要放对目录。\n2. 正式内容要有来源。\n3. 关键文档要有索引。\n4. 测试用例要能追溯需求。\n5. 技术文档要能追溯需求或业务流程。\n6. 里程碑要能追溯阶段目标和交付物。\n7. Agent 回答要能追溯来源文件。\n8. 废弃内容要归档，不要混在当前依据中。\n9. 敏感信息要脱敏。\n10. 知识库持续维护比一次性整理更重要。\n", + "wikilinks": [], + "category": "layer-overview" + } + }, + { + "id": "flow:layer-overview", + "type": "document", + "name": "1. 知识库入口", + "summary": "知识库使用说明、首页、知识地图和问答入口。先从这里理解知识库结构与检索方式。", + "tags": [ + "流程入口", + "知识库入口" + ], + "complexity": "simple", + "knowledgeMeta": { + "content": "# 知识库入口\n\n知识库使用说明、首页、知识地图和问答入口。先从这里理解知识库结构与检索方式。\n\n本层包含 5 个文档。点击右侧 Files 或在本层详情中选择具体文档查看内容。", + "wikilinks": [], + "category": "layer-overview" + } + }, + { + "id": "flow:layer-requirements", + "type": "document", + "name": "2. 需求文档", + "summary": "所有正式需求、业务规则、需求变更和需求索引。点击本层可查看全部需求文档并检索。", + "tags": [ + "流程入口", + "需求文档" + ], + "complexity": "simple", + "knowledgeMeta": { + "content": "# 需求文档\n\n所有正式需求、业务规则、需求变更和需求索引。点击本层可查看全部需求文档并检索。\n\n本层包含 21 个文档。点击右侧 Files 或在本层详情中选择具体文档查看内容。", + "wikilinks": [], + "category": "layer-requirements" + } + }, + { + "id": "flow:layer-milestones", + "type": "document", + "name": "3. 里程碑", + "summary": "项目阶段计划、里程碑节点、评审记录、准入准出和交付物节奏。", + "tags": [ + "流程入口", + "里程碑" + ], + "complexity": "simple", + "knowledgeMeta": { + "content": "# 里程碑\n\n项目阶段计划、里程碑节点、评审记录、准入准出和交付物节奏。\n\n本层包含 16 个文档。点击右侧 Files 或在本层详情中选择具体文档查看内容。", + "wikilinks": [], + "category": "layer-milestones" + } + }, + { + "id": "flow:layer-technical", + "type": "document", + "name": "4. 技术文档", + "summary": "系统架构、数据模型、接口说明、技术方案和技术决策。", + "tags": [ + "流程入口", + "技术文档" + ], + "complexity": "simple", + "knowledgeMeta": { + "content": "# 技术文档\n\n系统架构、数据模型、接口说明、技术方案和技术决策。\n\n本层包含 5 个文档。点击右侧 Files 或在本层详情中选择具体文档查看内容。", + "wikilinks": [], + "category": "layer-technical" + } + }, + { + "id": "flow:layer-testing", + "type": "document", + "name": "5. 测试相关", + "summary": "测试计划、测试用例、缺陷记录、验收记录和上线检查。", + "tags": [ + "流程入口", + "测试相关" + ], + "complexity": "simple", + "knowledgeMeta": { + "content": "# 测试相关\n\n测试计划、测试用例、缺陷记录、验收记录和上线检查。\n\n本层包含 7 个文档。点击右侧 Files 或在本层详情中选择具体文档查看内容。", + "wikilinks": [], + "category": "layer-testing" + } + }, + { + "id": "flow:layer-agent", + "type": "document", + "name": "6. Agent检索", + "summary": "检索说明、关键词、同义词、来源索引和持续更新验证流程。", + "tags": [ + "流程入口", + "Agent检索" + ], + "complexity": "simple", + "knowledgeMeta": { + "content": "# Agent检索\n\n检索说明、关键词、同义词、来源索引和持续更新验证流程。\n\n本层包含 6 个文档。点击右侧 Files 或在本层详情中选择具体文档查看内容。", + "wikilinks": [], + "category": "layer-agent" + } + }, + { + "id": "doc:05_需求文档/00-系统总览", + "type": "document", + "name": "如愿 · 系统总览 v1.0", + "filePath": "05_需求文档/00-系统总览.md", + "summary": "如愿 · 系统总览 v1.0 2 文件信息 4 文件名称： 00 系统总览.md 项目代号： 如愿 工作目录： /root/user business/ 当前版本： v1.0 创建日期： 2026 05 22 上游基线： docs from business/20260517 USER评价业务闭环主流程与后续工作基线 v1.2.md docs from bu", + "tags": [ + "05_需求文档", + "需求文档" + ], + "complexity": "complex", + "knowledgeMeta": { + "content": "# 如愿 · 系统总览 v1.0\n 2|\n## 文件信息\n 4|\n- 文件名称：`00-系统总览.md`\n- 项目代号：**如愿**\n- 工作目录：`/root/user-business/`\n- 当前版本：`v1.0`\n- 创建日期：`2026-05-22`\n- 上游基线：\n - `docs-from-business/20260517_USER评价业务闭环主流程与后续工作基线_v1.2.md`\n - `docs-from-business/20260517_USER评价业务闭环_共用能力图与渠道专属流程_v2.2.md`\n 13|\n## 目录\n 15|\n1. [项目目标与原则](#1-项目目标与原则)\n2. [系统总边界](#2-系统总边界)\n3. [子系统划分](#3-子系统划分)\n4. [子系统间依赖关系](#4-子系统间依赖关系)\n5. [角色 → 独立前端映射](#5-角色--独立前端映射)\n6. [子系统内外边界明细](#6-子系统内外边界明细)\n7. [总系统级业务澄清问题清单](#7-总系统级业务澄清问题清单)\n8. [待确认的内外边界](#8-待确认的内外边界)\n9. [附录：子系统文档索引](#9-附录子系统文档索引)\n 25|\n---\n 27|\n## 1. 项目目标与原则\n 29|\n### 1.1 项目代号：\"如愿\"\n\n> 取名\"如愿\"——系统做好能做的所有事（身份识别、需求评估、计划调度、渠道协同、风险拦截、结果追踪），让每一次运营投入都如愿转化为真实的评价提升和 ASIN 健康增长。Amazon 是否展示评价有平台的不确定性，但系统必须把可控环节做到极致。\n 33|\n### 1.2 核心架构目标\n 35|\n| # | 目标 | 说明 |\n| --- | --- | --- |\n| G1 | 前端分离 | 不同角色拥有独立前端应用，按需集成子系统能力 |\n| G2 | 清晰系统边界 | 明确系统内外边界，区分内部可控与外部依赖 |\n| G3 | 子系统解耦 | 子系统通过 API 契约通信，支持独立开发、独立部署 |\n| G4 | 并行开发 | 子系统之间尽量减少串行依赖，允许多团队并行推进 |\n| G5 | 独立角色前端 | Amazon 运营、用户运营、客服、风险管理、KOC/KOL 运营各自拥有独立前端 |\n 43|\n### 1.3 架构原则\n 45|\n| 原则 | 说明 |\n| --- | --- |\n| **单一数据源** | 每个业务事实只有一个子系统负责写入（Owner），其他子系统只读或通过 API 调用 |\n| **API 契约优先** | 子系统间通过明确 API 契约通信，先定义契约再实现 |\n| **真实人为核心** | 所有额度、风险、历史判断围绕「真实人」而非单一账号 |\n| **每次互动重判** | 身份、额度、风险不是一次性的，每次有效互动需重做判断 |\n| **审计不可少** | 所有状态变更、敏感访问、人工干预必须留痕 |\n 53|\n---\n 55|\n## 2. 系统总边界\n 57|\n### 2.1 边界总图\n 59|\n```\n┌─────────────────────────────────────────────────────────────────────┐\n│ 如愿 系统边界 │\n│ │\n│ ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐ │\n│ │ Amazon │ │ 用户运营 │ │ Amazon │ │ 风险/黑名 │ │\n│ │ 运营前端 │ │ 前端 │ │ 运营总监 │ │ 单前端 │ │\n│ └────┬─────┘ └────┬─────┘ └────┬─────┘ └────┬─────┘ │\n│ │ │ │ │ │\n│ ┌────┴─────┐ ┌────┴─────┐ ┌────┴─────┐ ┌────┴─────┐ │\n│ │ 客服前端 │ │ 客服管理 │ │ KOC/KOL │ │ 管理驾驶 │ │\n│ │ │ │ 前端 │ │ 运营前端 │ │ 舱 │ │\n│ └────┬─────┘ └────┬─────┘ └────┬─────┘ └────┬─────┘ │\n│ │ │ │ │ │\n│ ═════╪══════════════╪══════════════╪══════════════╪══════ API网关 │\n│ │ │ │ │ │\n│ ┌────┴──────────────┴──────────────┴──────────────┴─────┐ │\n│ │ 内部子系统 │ │\n│ │ ┌────────┐ ┌────────┐ ┌────────┐ ┌────────┐ │ │\n│ │ │ 用户身 │ │需求与计│ │额度与频│ │多渠道触│ │ │\n│ │ │份上下文│ │划管理 │ │ 控 │ │达引擎 │ │ │\n│ │ └───┬────┘ └───┬────┘ └───┬────┘ └───┬────┘ │ │\n│ │ ┌───┴────┐ ┌───┴────┐ ┌───┴────┐ ┌───┴────┐ │ │\n│ │ │客服工单│ │风险与反│ │评价结果│ │KOC/KOL │ │ │\n│ │ │与管理 │ │ 欺诈 │ │ 追踪 │ │ 协作 │ │ │\n│ │ └───┬────┘ └───┬────┘ └───┬────┘ └───┬────┘ │ │\n│ │ ┌───┴────┐ │ │\n│ │ │审计与通│ │ │\n│ │ │知中心 │ │ │\n│ │ └────────┘ │ │\n│ └───────────────────────────────────────────────────────────┘ │\n│ │\n└─────────────────────────────────────────────────────────────────────┘\n 93|\n ║ 外部系统 ║\n 95|\n┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐\n│ Amazon │ │ JOYHUB │ │JOYCOLLAB │ │ 邮件服务 │ │ 财务系统 │\n│ Marketplace│ │ 用户平台 │ │ KOC平台 │ │ (ESP) │ │(返款/退款)│\n└──────────┘ └──────────┘ └──────────┘ └──────────┘ └──────────┘\n```\n 101|\n### 2.2 系统内部（如愿系统）\n 103|\n| # | 子系统 | 代号 | 核心职责 | 详情文档 |\n| --- | --- | --- | --- | --- |\n| S1 | 用户身份与上下文 | `identity` | 真实人识别、身份线索归并、用户上下文卡 | [01-用户身份与上下文](01-子系统-用户身份与上下文.md) |\n| S2 | 需求与计划管理 | `planning` | 需求触发（人工/自动）、计划生成（推新/回评/免评）、审批工作流 | [02-需求与计划管理](02-子系统-需求与计划管理.md) |\n| S3 | 额度与频控 | `quota` | 月度测评/免评额度台账、累计评价额度、频控、预占 | [03-额度与频控](03-子系统-额度与频控.md) |\n| S4 | 多渠道触达引擎 | `outreach` | IM/EDM/APP Push/TEL 渠道调度、路由、去重、发送 | [04-多渠道触达引擎](04-子系统-多渠道触达引擎.md) |\n| S5 | 客服工单与管理 | `support` | 工单生命周期、自动分配、排班出勤、绩效统计 | [05-客服工单与管理](05-子系统-客服工单与管理.md) |\n| S6 | 风险与反欺诈 | `risk` | 强弱关联判断、黑名单、双重退款检测、风险事件 | [06-风险与反欺诈](06-子系统-风险与反欺诈.md) |\n| S7 | 评价结果追踪 | `review` | 评价提交记录、Amazon 展示核验、ASIN 健康回流 | [07-评价结果追踪](07-子系统-评价结果追踪.md) |\n| S8 | KOC/KOL 协作 | `creator` | KOC/KOL 匹配、内容跟踪、Code 管理、JOYCOLLAB 同步 | [08-KOC-KOL协作](08-子系统-KOC-KOL协作.md) |\n| S9 | 审计与通知中心 | `audit` | 状态变更审计、敏感访问日志、多类型通知/告警 | [09-审计与通知中心](09-子系统-审计与通知中心.md) |\n 115|\n### 2.3 系统外部（外部依赖）\n 117|\n| # | 外部系统 | 说明 | 交互方式 | 确认状态 |\n| --- | --- | --- | --- | --- |\n| E1 | **Amazon Marketplace** | 订单数据、评价数据、ASIN/Listing 健康数据、退款数据 | API 拉取 / 爬取 | ⚠️ 待确认 |\n| E2 | **JOYHUB 用户平台** | JOYHUB ID、设备信息、APP 行为数据、绑定玩具数据 | API 同步 | ⚠️ 待确认 |\n| E3 | **JOYCOLLAB** | KOC/KOL 内容数据、Code 使用数据、带货订单数据 | API 同步 | ⚠️ 待确认 |\n| E4 | **邮件服务 (ESP)** | EDM 发送、送达/打开/点击追踪、退订/硬退信 | SMTP + Webhook | ⚠️ 待确认 |\n| E5 | **财务系统** | 返款执行、返款状态、退款记录（OA 侧） | API 调用 | ⚠️ 待确认 |\n| E6 | **APP Push 服务** | APP 推送通道（FCM/APNs） | SDK / API | ⚠️ 待确认 |\n| E7 | **电话系统** | 外呼能力、来电识别、通话记录 | API / SIP | ⚠️ 待确认 |\n| E8 | **IM 平台 (WhatsApp?)** | IM 消息收发 | API | ⚠️ 待确认 |\n 128|\n---\n 130|\n## 3. 子系统划分\n 132|\n### 3.1 划分依据\n 134|\n子系统按照**业务域内聚**原则划分，每个子系统：\n 136|\n1. 拥有明确的数据所有权（该子系统是某些核心数据对象的唯一写入方）\n2. 对外暴露清晰的 API 契约\n3. 可以独立开发、测试、部署\n4. 尽量减少对其他子系统的强依赖（启动依赖）\n 141|\n### 3.2 各子系统数据所有权\n 143|\n| 子系统 | 拥有（写入）的核心数据对象 |\n| --- | --- |\n| identity | `person_profiles`、`person_identity_links`、`contact_context_snapshots`、`device_records` |\n| planning | `demands`、`plans`、`plan_items`、`approval_records`、`asin_catalog` |\n| quota | `person_quota_ledgers`、`quota_reservations`、`frequency_control_records` |\n| outreach | `channel_route_decisions`、`channel_dedup_records`、`im_interaction_records`、`edm_message_events`、`app_touch_events`、`tel_call_records` |\n| support | `support_tickets`、`support_followups`、`support_assignment_logs`、`attendance_records`、`shift_schedules`、`support_performance_snapshots` |\n| risk | `risk_signals`、`risk_cases`、`blacklist_entities`、`refund_match_results` |\n| review | `review_submission_records`、`review_display_checks`、`review_results` |\n| creator | `exemption_plan_tasks`、`creator_content_records`、`creator_profiles`、`code_records` |\n| audit | `interaction_audit_logs`、`notification_records`、`manual_review_tasks` |\n 155|\n---\n 157|\n## 4. 子系统间依赖关系\n 159|\n### 4.1 依赖图\n 161|\n```\n ┌─────────────────────────────────────────────┐\n │ audit (审计与通知) │\n │ ← 所有子系统向 audit 发送事件 │\n └─────────────────────────────────────────────┘\n ↑\n ┌─────────┬─────────┬─────┼─────┬─────────┬─────────┐\n │ │ │ │ │ │ │\n┌───┴───┐ ┌───┴───┐ ┌───┴───┐ │ ┌───┴───┐ ┌───┴───┐ ┌───┴───┐\n│ review│ │creator│ │support│ │ │ risk │ │ quota │ │outreach│\n│(评价) │ │(KOC) │ │(客服) │ │ │(风险) │ │(额度) │ │(触达) │\n└───┬───┘ └───┬───┘ └───┬───┘ │ └───┬───┘ └───┬───┘ └───┬───┘\n │ │ │ │ │ │ │\n └─────────┼─────────┼─────┼─────┼─────────┼─────────┘\n │ │ │ │ │\n ┌────┴─────────┴─────┼─────┼─────────┴────────┐\n │ │ │ │\n ▼ ▼ ▼ ▼\n ┌─────────┐ ┌──────────────┐ ┌─────────┐\n │planning │←─────────│ identity │─────────→│ quota │\n │(计划) │ │ (用户身份) │ │ (额度) │\n └─────────┘ └──────────────┘ └─────────┘\n```\n 185|\n### 4.2 依赖矩阵\n 187|\n| ↓ 消费者 \\ 提供者 → | identity | planning | quota | outreach | support | risk | review | creator | audit |\n| --- |:---:|:---:|:---:|:---:|:---:|:---:|:---:|:---:|:---:|\n| **identity** | - | - | - | - | - | R | - | - | E |\n| **planning** | **R** | - | R | - | - | R | R | - | E |\n| **quota** | **R** | - | - | - | - | - | R | - | E |\n| **outreach** | R | R | R | - | - | R | - | - | E |\n| **support** | R | - | - | - | - | R | - | - | E |\n| **risk** | R | - | - | - | - | - | - | - | E |\n| **review** | R | R | - | - | - | - | - | R | E |\n| **creator** | - | R | R | - | - | - | - | - | E |\n| **audit** | - | - | - | - | - | - | - | - | - |\n 199|\n**图例：** `R` = 只读依赖（通过 API 查询），`E` = 事件发送（fire-and-forget），`-` = 无依赖\n 201|\n### 4.3 启动依赖（必须就绪才能工作）\n 203|\n| 子系统 | 启动依赖 | 说明 |\n| --- | --- | --- |\n| identity | 无硬依赖 | 可独立启动（需要 JOYHUB 数据同步） |\n| planning | identity（软依赖） | 无 identity 时可先操作，但无法做人群匹配 |\n| quota | identity（软依赖） | 额度按真实人计算，未归并时按单一账号 |\n| outreach | identity, planning, quota（软依赖） | 无依赖时可先建渠道基础设施 |\n| support | identity（软依赖） | 无用户上下文卡时可先跑工单 |\n| risk | identity（软依赖） | 强/弱关联依赖身份数据 |\n| review | identity, planning（软依赖） | 评价需关联计划和用户 |\n| creator | planning（软依赖） | 免评计划入口 |\n| audit | 无硬依赖 | 完全独立 |\n 215|\n> **软依赖** = 可降级运行，核心功能不受阻。例如 outreach 在 identity 不可用时仍可发送消息，但缺少用户上下文。\n 217|\n---\n 219|\n## 5. 角色 → 独立前端映射\n 221|\n### 5.1 前端应用矩阵\n 223|\n| 前端应用 | 目标角色 | 集成的子系统 | 部署形态 |\n| --- | --- | --- | --- |\n| **运营工作台** | Amazon 运营、Amazon 运营总监 | planning + review + quota (查询) | Web SPA |\n| **用户运营中心** | 用户运营、用户运营负责人/组长 | planning + outreach + quota + review | Web SPA |\n| **客服工作台** | 菲律宾客服组员 | support + identity (上下文卡) + outreach (TEL) | Web SPA / 桌面端 |\n| **客服管理台** | 菲律宾客服负责人、客服组长 | support (管理模块) + audit | Web SPA |\n| **风险控制台** | 风险/黑名单相关人员 | risk + identity (上下文卡) + audit | Web SPA |\n| **达人协作台** | KOC/KOL 运营 | creator + outreach (协同) + review (免评结果) | Web SPA |\n| **管理驾驶舱** | 运营总监、用户运营负责人 | 跨子系统聚合看板 (planning + outreach + support + review) | Web SPA |\n 233|\n### 5.2 角色-功能矩阵\n 235|\n| 功能 \\ 角色 | Amazon运营 | 运营总监 | 用户运营 | 用户负责人 | 客服组员 | 客服组长 | 客服负责人 | 风险人员 | KOC运营 |\n| --- |:---:|:---:|:---:|:---:|:---:|:---:|:---:|:---:|:---:|\n| 提需求（推新/回评/免评） | ✓ | ✓ | - | - | - | - | - | - | - |\n| 审批计划 | - | ✓ | - | ✓ | - | - | - | - | - |\n| 评估需求 | - | - | ✓ | ✓ | - | - | - | - | - |\n| 生成计划/调资源 | - | - | ✓ | ✓ | - | - | - | - | - |\n| 查看 ASIN 健康 | ✓ | ✓ | ✓ | - | - | - | - | - | - |\n| 处理工单 | - | - | - | - | ✓ | ✓ | - | - | - |\n| 分配工单 | - | - | - | - | - | ✓ | ✓ | - | - |\n| 电话外呼/接听 | - | - | - | - | ✓ | - | - | - | - |\n| 查看排班出勤 | - | - | - | - | - | ✓ | ✓ | - | - |\n| 绩效统计 | - | - | - | - | - | ✓ | ✓ | - | - |\n| 风险审核 | - | - | - | - | - | - | - | ✓ | - |\n| 黑名单管理 | - | - | - | - | - | - | - | ✓ | - |\n| KOC/KOL 匹配 | - | - | - | - | - | - | - | - | ✓ |\n| 内容跟踪 | - | - | ✓ | - | - | - | - | - | ✓ |\n 252|\n---\n 254|\n## 6. 子系统内外边界明细\n 256|\n### 6.1 identity — 用户身份与上下文\n 258|\n| 维度 | 说明 |\n| --- | --- |\n| **对内** | 管理真实人归并逻辑、身份线索关联（JOYHUB ID↔邮箱↔电话↔设备↔订单→真实人ID）、用户上下文卡聚合与快照、设备变化识别 |\n| **对外（提供给其他子系统）** | `GET /api/identity/person/{context}` — 按线索查真实人；`GET /api/identity/context/{person_id}` — 用户上下文卡；`POST /api/identity/merge` — 归并请求 |\n| **依赖外部系统** | JOYHUB（用户基础数据）、APP（设备数据） |\n| **待确认边界** | 真实人归并是自动还是人工确认？归并拆分（合并错了如何回退）？非 APP 用户的身份线索从哪里同步（ESM 的邮箱清洗？） |\n 265|\n### 6.2 planning — 需求与计划管理\n 267|\n| 维度 | 说明 |\n| --- | --- |\n| **对内** | 需求触发（人工提交 + 自动触发规则）、需求评估、计划创建（推新/回评/免评）、审批工作流、ASIN 基础信息管理 |\n| **对外（提供给其他子系统）** | `GET /api/plans/{id}` — 计划详情；`GET /api/plans?status=approved` — 待执行计划；`POST /api/demands` — 创建需求 |\n| **依赖外部系统** | Amazon（ASIN 数据、销售数据、评价缺口） |\n 273|\n### 6.3 quota — 额度与频控\n 275|\n| 维度 | 说明 |\n| --- | --- |\n| **对内** | 额度台账（测评4/免评4/累计12）、额度预占与释放、频控规则引擎、发送前终校 |\n| **对外（提供给其他子系统）** | `GET /api/quota/check/{person_id}?type=测评` — 额度查询+预占；`POST /api/quota/reserve` — 预占；`POST /api/quota/commit` — 确认占用 |\n| **依赖外部系统** | 无直接外部系统依赖 |\n| **待确认边界** | 额度预占有效期多长？跨月额度如何处理（月末最后一天预占，下月一号释放还是保留？） |\n 282|\n### 6.4 outreach — 多渠道触达引擎\n 284|\n| 维度 | 说明 |\n| --- | --- |\n| **对内** | 渠道路由决策、渠道去重、IM 推送（分层 A/B/C）、EDM 发送与行为追踪、APP Push、TEL 任务生成 |\n| **对外（提供给其他子系统）** | `POST /api/outreach/send` — 发送触达；`GET /api/outreach/history/{person_id}` — 触达历史 |\n| **依赖外部系统** | JOYHUB（IM 通道）、ESP（EDM）、FCM/APNs（APP Push）、电话系统（TEL） |\n| **待确认边界** | IM 具体是什么平台（WhatsApp/自研 IM）？EDM 模板管理在 outreach 内还是独立内容管理？APP Push 是否复用 JOYHUB 现有 Push 通道？ |\n 291|\n### 6.5 support — 客服工单与管理\n 293|\n| 维度 | 说明 |\n| --- | --- |\n| **对内** | 工单生命周期、自动分配（按排班/在线/负载）、答应配合状态机、出勤/排班/绩效 |\n| **对外（提供给其他子系统）** | `POST /api/tickets` — 创建工单；`GET /api/tickets/{id}` — 工单详情；`GET /api/support/stats` — 绩效数据 |\n| **依赖外部系统** | 无直接外部系统依赖（电话记录来自 outreach TEL 模块） |\n| **待确认边界** | 客服是否使用独立 IM 工具还是复用 outreach 的 IM 通道？排班数据是否与现有 HR 系统对接？ |\n 300|\n### 6.6 risk — 风险与反欺诈\n 302|\n| 维度 | 说明 |\n| --- | --- |\n| **对内** | 强弱关联判断、黑名单实体管理、风险事件管理、双重退款检测（Amazon退款 vs OA返款） |\n| **对外（提供给其他子系统）** | `GET /api/risk/check/{person_id}` — 风险查询；`POST /api/risk/report` — 上报风险信号 |\n| **依赖外部系统** | Amazon（退款数据）、财务系统（OA 返款数据） |\n 308|\n### 6.7 review — 评价结果追踪\n 310|\n| 维度 | 说明 |\n| --- | --- |\n| **对内** | 用户真实提交评价记录、Amazon 展示核验、ASIN 健康更新回流、计划完成度计算 |\n| **对外（提供给其他子系统）** | `POST /api/reviews/submission` — 记录提交；`GET /api/reviews/status/{plan_id}` — 计划评价进度 |\n| **依赖外部系统** | Amazon（评价展示状态、ASIN 评分数据） |\n 316|\n### 6.8 creator — KOC/KOL 协作\n 318|\n| 维度 | 说明 |\n| --- | --- |\n| **对内** | KOC/KOL 匹配筛选、内容 Brief/Code 分配、内容发布跟踪、带货结果跟踪 |\n| **对外（提供给其他子系统）** | `GET /api/creators/match?plan_id=` — 匹配推荐；`POST /api/creators/tasks` — 创建协作任务 |\n| **依赖外部系统** | JOYCOLLAB（KOC/KOL 数据、内容数据、Code 使用、带货订单） |\n 324|\n### 6.9 audit — 审计与通知中心\n 326|\n| 维度 | 说明 |\n| --- | --- |\n| **对内** | 所有子系统的状态变更审计、敏感字段访问日志、多类型通知（额度预警/超时提醒/紧急 Listing 告警/审批通知） |\n| **对外（提供给其他子系统）** | `POST /api/audit/event` — 上报审计事件；`POST /api/notifications/send` — 发送通知 |\n| **依赖外部系统** | 通知可能通过 IM/EDM/APP Push 等通道（可复用 outreach 通道或独立） |\n| **待确认边界** | 审计日志保留策略？通知模板管理在 audit 内还是需要独立内容管理？ |\n 333|\n---\n 335|\n## 7. 总系统级业务澄清问题清单\n 337|\n> 以下问题需要与业务方确认，涉及跨子系统边界、关键业务规则和外部系统对接。\n 339|\n### 7.1 外部系统对接（8 项）\n 341|\n| # | 问题 | 涉及外部系统 | 优先级 |\n| --- | --- | --- | --- |\n| Q-E1 | Amazon 数据以什么方式接入？（MWS/SP-API 授权拉取、爬虫、CSV 导入、已有中间表？） | Amazon | **P0** |\n| Q-E2 | JOYHUB 现有数据有哪些可用？是否有现成 API？JOYHUB ID ↔ 邮箱 ↔ 设备 ↔ 订单 的关联数据是否已存储？ | JOYHUB | **P0** |\n| Q-E3 | JOYCOLLAB 数据同步方向是单向（COLLAB→USER）还是双向？同步频率？Code 生成是在 COLLAB 还是 USER？ | JOYCOLLAB | **P0** |\n| Q-E4 | 当前 EDM 使用什么邮件服务？（SendGrid / Mailchimp / SES / 自建？）是否有现成的送达/打开/点击追踪？ | ESP | **P0** |\n| Q-E5 | OA 返款系统是哪个？是否有 API 可以查询返款状态和返款记录？（用于双重退款比对） | 财务系统 | **P0** |\n| Q-E6 | APP Push 是否复用 JOYHUB 现有 Push 通道还是需要独立接入 FCM/APNs？ | APP Push | P1 |\n| Q-E7 | 电话系统用什么方案？（自建 SIP / 第三方云呼叫中心？）是否已有通话记录存储？ | 电话系统 | P1 |\n| Q-E8 | IM 平台具体是什么？（WhatsApp Business API / 自研 IM / Facebook Messenger？） | IM 平台 | P1 |\n 352|\n### 7.2 用户身份体系（5 项）\n 354|\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| Q-I1 | 「真实人」归并是完全自动还是需要人工确认？自动归并错误时如何拆分？（拆分会影响到已关联的历史评价和额度） | **P0** |\n| Q-I2 | 非 APP 用户（只知道邮箱）如何建立真实人？没有设备号仅凭邮箱+收件地址归并，置信度阈值如何定？ | **P0** |\n| Q-I3 | JOYHUB ID 与真实人是 1:1 还是 N:1？（一个真实人可能拥有多个 JOYHUB ID） | P1 |\n| Q-I4 | 设备变化的「换机」判定标准是什么？（同一 JOYHUB ID 下设备号变化？多久内变化算换机？） | P1 |\n| Q-I5 | 用户上下文卡的「快照」是否需要保留历史版本？（每次互动生成新快照 vs 覆盖上次） | P2 |\n 362|\n### 7.3 额度与频控规则（6 项）\n 364|\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| Q-Q1 | 月度额度按自然月还是按 30 天滚动？如果是自然月，预占在月末最后一天是否需要特殊处理？ | **P0** |\n| Q-Q2 | 「测评 4 次」的「次」定义：是指参与 4 个不同的测评计划，还是提交 4 次评价？（如果一次计划要求用户提交多条评价怎么算） | **P0** |\n| Q-Q3 | 「累计 12 个评价」是永久上限还是可以重置？（例如用户长期优质，是否可以放宽？） | P1 |\n| Q-Q4 | 额度预占的有效期多长？如果预占后用户始终未响应，多久释放额度？ | P1 |\n| Q-Q5 | 频控规则中的「渠道频控」具体阈值是多少？（IM 每日最多推几次？EDM 每周最多几封？） | P1 |\n| Q-Q6 | 「接近上限时提前预警」——预警阈值是还剩 1 次还是还剩 N%？ | P2 |\n 373|\n### 7.4 计划与审批流程（5 项）\n 375|\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| Q-P1 | 自动触发需求的条件是什么？（ASIN 评分低于多少？评价缺口多少条？Listing 健康到什么程度？） | **P0** |\n| Q-P2 | 审批链中的「指定负责人」如何确定？（系统自动按规则还是人工指定？规则是什么？） | **P0** |\n| Q-P3 | 计划审批后是否可以修改？修改是否需要重新审批？ | P1 |\n| Q-P4 | 计划之间是否有互斥关系？（同一个 ASIN 同时跑推新和回评计划是否可以？） | P1 |\n| Q-P5 | 「紧急计划」的判定标准和特殊审批流程？（谁可以标记为紧急？是否跳过某些审批节点？） | P1 |\n 383|\n### 7.5 渠道协同与去重（5 项）\n 385|\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| Q-C1 | 渠道优先级路由规则是否需要可配置？（例如针对某类用户调整 IM > EDM 的优先级） | **P0** |\n| Q-C2 | 用户已在客服工单中时「暂停自动触达」——是所有渠道暂停还是仅暂停与当前工单相关的渠道？ | P1 |\n| Q-C3 | EDM 引导注册 APP 后，如何识别「该 EDM 邮箱对应该 APP 用户」？靠什么字段关联？ | P1 |\n| Q-C4 | 渠道去重中「同一计划同一用户不重复通过多渠道路由」——如果高优先级渠道发送失败（退信/未送达），是否自动降级到下一渠道？ | P1 |\n| Q-C5 | IM 推送中的「催评卡片」和 APP Push 中的「催评推送」如何协调？（两者会不会同时推送给同一用户？） | P1 |\n 393|\n### 7.6 客服与工单（5 项）\n 395|\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| Q-S1 | 工单自动分配算法——「当前负载」如何计算？（按未关闭工单数？按最近 N 小时处理量？） | **P0** |\n| Q-S2 | 客服的「在线状态」如何获取？（手动切换在线/离线，还是自动检测活跃度？） | P1 |\n| Q-S3 | 「答应配合」的超时判定——答应后多少天未提交算超时？超时后提醒频率？ | P1 |\n| Q-S4 | 出勤排班是否与本系统内的排班模块管理还是对接外部 HR 系统？ | P1 |\n| Q-S5 | 客服转化统计中的 RSO（回评）和 RDO（测评）如何区分？（按工单来源？按最终结果？） | P2 |\n 403|\n### 7.7 风险与反欺诈（4 项）\n 405|\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| Q-R1 | 「强关联」中哪些维度的命中可以直接自动化拦截，哪些需要人工复核？（文档说一旦命中直接进入高风险，但实际执行中是否所有强关联都自动拦截？） | **P0** |\n| Q-R2 | 双重退款检测——Amazon 退款数据如何及时获取？（T+1 同步？实时 Webhook？手动导入？） | **P0** |\n| Q-R3 | 黑名单是否有过期/申诉/解除机制？什么条件下可以从黑名单中移除？ | P1 |\n| Q-R4 | 风险信号的「弱关联」观察期多长？观察期过后是自动解除还是人工确认？ | P1 |\n 412|\n### 7.8 评价结果与回流（4 项）\n 414|\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| Q-V1 | Amazon 评价展示的核验方式是什么？（定时爬取 Amazon 页面？手动录入？用户上传截图？API？） | **P0** |\n| Q-V2 | 「Amazon 未展示 / 暂不可核验」的评价进入异常观察队列后，观察多久？复查频率？ | P1 |\n| Q-V3 | ASIN 健康「回流」的具体含义是什么？（更新 ASIN 评分/评价数到 planning 子系统，触发新一轮需求？） | P1 |\n| Q-V4 | 一个用户可能为多个 ASIN 提交评价——这些评价是否都计入同一个计划的完成度？ | P1 |\n 421|\n### 7.9 KOC/KOL 协作（4 项）\n 423|\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| Q-K1 | JOYCOLLAB 中 KOC/KOL 数据字段有哪些？（粉丝量、平台、国家、历史效果——文档提到但需确认完整字段） | **P0** |\n| Q-K2 | 「匹配 KOC/KOL」是运营人工选择还是系统自动推荐？推荐算法依赖什么数据？ | P1 |\n| Q-K3 | Code 是 JOYCOLLAB 生成还是 USER 系统生成？是一对一（每个 KOC 独立 Code）还是一对多？ | P1 |\n| Q-K4 | KOC/KOL 的财务结算（提成/返点）是完全在财务系统还是在 USER 系统内触发？ | P1 |\n 430|\n### 7.10 数据迁移与历史兼容（3 项）\n 432|\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| Q-D1 | 现有 USER 后台 ERP 系统（`C:\\XCODE\\USER`）是否完全废弃还是部分模块保留？新旧系统切换策略？ | **P0** |\n| Q-D2 | 历史数据（已有评价记录、用户数据、工单记录）是否需要迁移到新系统？迁移范围和清洗策略？ | **P0** |\n| Q-D3 | 旧系统中存在的用户额度数据如何初始化？（历史测评次数、免评次数、累计评价数如何确定？） | **P0** |\n 438|\n### 7.11 项目分期与 MVP 范围（5 项）\n 440|\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| Q-M1 | 项目一期（MVP）的最小范围是什么？9 个子系统中哪些是必须的、哪些可以二期再做？ | **P0** |\n| Q-M2 | MVP 先支持哪个 Amazon 站点？（.com？还是多站点？）先支持哪种计划类型？（推新/回评/免评全部 or 先做回评？） | **P0** |\n| Q-M3 | 前端应用的优先级——7 个前端中哪些是 MVP 必须有？（客服工作台+运营工作台？还是全部都要？） | **P0** |\n| Q-M4 | 项目整体时间线和里程碑约束？（6 个月？1 年？是否有硬性 deadline？） | P1 |\n| Q-M5 | 开发团队规模和结构？（几个后端开发？几个前端？是否有专职 QA？）是否支持 9 个子系统并行开发？ | P1 |\n 448|\n### 7.12 基础设施与部署（6 项）\n 450|\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| Q-IN1 | 部署环境？（云厂商 AWS/阿里云？自建机房？）是否已有 Kubernetes 集群或考虑容器化部署？ | **P0** |\n| Q-IN2 | 数据库选型？（PostgreSQL / MySQL？）每子系统独立数据库还是共享数据库？是否已有数据库团队和规范？ | **P0** |\n| Q-IN3 | 子系统间异步通信方案？（消息队列：Kafka/RabbitMQ/Redis？还是全部同步 HTTP？） | **P0** |\n| Q-IN4 | API 网关选型？（Kong/Nginx/自研？）认证鉴权方案？（JWT/OAuth2/SSO？） | P1 |\n| Q-IN5 | 日志、监控、链路追踪方案？（ELK/Prometheus+Grafana/Jaeger？）是否已有公司级基础设施可复用？ | P1 |\n| Q-IN6 | 灾备和容灾要求？（RPO/RTO 目标？是否需要多可用区/异地容灾？数据备份频率？） | P2 |\n 459|\n### 7.13 安全与合规（5 项）\n 461|\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| Q-SC1 | 是否有需要通过的安全合规认证？（SOC2 / ISO 27001 / 等保？）对系统架构有何约束？ | P1 |\n| Q-SC2 | 用户个人数据（邮箱、电话、地址、设备号）的保留和删除策略？（GDPR 的「被遗忘权」如何处理？） | P1 |\n| Q-SC3 | Amazon 的 API 使用条款（SP-API Acceptable Use Policy）对数据存储和使用的限制？（评价数据是否可以长期存储？） | P1 |\n| Q-SC4 | 系统权限模型？（RBAC？角色和权限的粒度？是否需要支持数据行级权限——例如不同站点的运营只看自己的 ASIN？） | P1 |\n| Q-SC5 | 敏感数据（收款信息、设备号）的加密存储方案？传输加密（TLS）要求？ | P2 |\n 469|\n### 7.14 技术栈与规范（4 项）\n 471|\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| Q-TS1 | 后端技术栈偏好？（Python/FastAPI？Go？Node.js？Java？）是否有公司技术栈约束？ | P1 |\n| Q-TS2 | 前端技术栈偏好？（React/Vue/Angular？）是否有公司前端组件库或设计系统可复用？ | P1 |\n| Q-TS3 | API 规范标准？（OpenAPI 3.0？gRPC？）是否需要 BFF（Backend for Frontend）层？ | P2 |\n| Q-TS4 | 代码仓库策略？（Monorepo or Polyrepo？9 个子系统分仓库还是一仓库？CI/CD 工具？） | P2 |\n 478|\n### 7.15 多站点与多市场（4 项）\n 480|\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| Q-MS1 | 系统需要支持多少个 Amazon 站点？（.com / .co.uk / .de / .fr / .it / .es / .jp / .ca？）不同站点的业务流程是否一致？ | **P0** |\n| Q-MS2 | 多站点下「真实人」归并是否跨站点？（同一个真实人在 .com 和 .co.uk 用不同邮箱/账号——是否归并为同一人？） | P1 |\n| Q-MS3 | 额度规则是否跨站点？（测评 4 次是每个站点独立还是全局？累计 12 个评价呢？） | P1 |\n| Q-MS4 | 未来是否扩展到 Amazon 以外的平台（eBay/Walmart/独立站）？架构上需要预留扩展点吗？ | P2 |\n 487|\n### 7.16 内容与素材管理（3 项）\n 489|\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| Q-CM1 | EDM 模板、IM 推送话术、APP Push 文案的创建和维护由谁负责？（内容运营？用户运营？）是否需要独立的内容管理子系统？ | P1 |\n| Q-CM2 | 多语言内容策略？（面向美国用户的英文消息、面向德国用户的德语消息——模板由谁翻译和维护？系统是否需要自动翻译？） | P1 |\n| Q-CM3 | 图片/视频素材（产品图片、测评指引图）的存储和管理？是否需要 CDN？ | P2 |\n 495|\n### 7.17 业务量级预估（4 项）\n 497|\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| Q-BV1 | 系统需要管理的 ASIN 数量级？（几十个？几百个？几千个？） | P1 |\n| Q-BV2 | 日活跃用户数（APP 端）？日触达消息量（IM+EDM+APP Push+TEL）？ | P1 |\n| Q-BV3 | 客服团队规模？（几个组？每组多少人？峰值工单量？） | P1 |\n| Q-BV4 | 峰值场景预估？（Prime Day / Black Friday 期间流量和触达量是平时的几倍？） | P2 |\n 504|\n### 7.18 外部系统对接细节（4 项）\n 506|\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| Q-EX1 | 各外部系统的 SLA 和可用性？（Amazon SP-API 的 rate limit？JOYHUB 的响应时间？）当外部系统不可用时的降级策略？ | P1 |\n| Q-EX2 | 外部系统的认证方式？（Amazon SP-API 的 OAuth 授权流程？JOYHUB 的 API Key？）谁负责管理这些凭证？ | P1 |\n| Q-EX3 | 数据同步的增量 or 全量策略？（Amazon 订单是增量拉取最近 N 天还是全量同步？JOYHUB 用户数据呢？） | P1 |\n| Q-EX4 | 外部系统数据格式和字段映射是否已有文档？（Amazon 订单字段→系统内部字段的映射关系？） | P2 |\n 513|\n---\n 515|\n## 8. 待确认的内外边界\n 517|\n> 以下边界由于文档信息不足，标记为「待确认」，需要在后续与业务方或技术团队确认。\n 519|\n| # | 边界问题 | 影响范围 | 建议确认方式 |\n| --- | --- | --- | --- |\n| B1 | **内容/素材管理归属**：EDM 模板、IM 推送话术、APP Push 文案由哪个子系统管理？是 outreach 内的内容模块，还是独立的内容管理子系统？ | outreach | 与内容运营角色确认工作流 |\n| B2 | **品牌/内容运营角色**：文档提到品牌运营和内容运营但目前不展开。他们是否需要独立前端？需求何时明确？ | planning / creator | 与业务方确认是否一期纳入 |\n| B3 | **数据仓库/BI 边界**：文档明确「完整 BI/财务/ROI 系统」不在本版主流程，但管理驾驶舱涉及聚合看板。看板数据是子系统直接提供聚合 API 还是走独立数据仓库？ | 全部 | 与数据团队确认数据架构 |\n| B4 | **外部系统降级策略**：Amazon API 不可用时，哪些功能可以降级运行？JOYHUB 不可用时用户身份如何兜底？ | identity / planning / review | 制定 SLA 和降级方案 |\n| B5 | **多语言支持**：系统前端是否只面向菲律宾客服（英文？）还是国内团队也使用（中文？） | 所有前端 | 确认各前端的语言需求 |\n| B6 | **定时任务归属**：自动需求触发、EDM 批处理、超时检测、评价核验等定时任务在各子系统内实现还是有统一调度器？ | 多个子系统 | 确认是否引入统一任务调度 |\n 528|\n---\n 530|\n## 9. 附录：子系统文档索引\n 532|\n| 文档 | 描述 |\n| --- | --- |\n| [01-子系统-用户身份与上下文](01-子系统-用户身份与上下文.md) | 真实人归并、用户上下文卡、设备识别 |\n| [02-子系统-需求与计划管理](02-子系统-需求与计划管理.md) | 需求触发、计划生命周期、审批工作流 |\n| [03-子系统-额度与频控](03-子系统-额度与频控.md) | 额度台账、频控引擎、预占释放 |\n| [04-子系统-多渠道触达引擎](04-子系统-多渠道触达引擎.md) | IM/EDM/APP/TEL 调度与执行 |\n| [05-子系统-客服工单与管理](05-子系统-客服工单与管理.md) | 工单管理、客服管理支撑 |\n| [06-子系统-风险与反欺诈](06-子系统-风险与反欺诈.md) | 风险判断、黑名单、双重退款 |\n| [07-子系统-评价结果追踪](07-子系统-评价结果追踪.md) | 评价提交、展示核验、结果回流 |\n| [08-子系统-KOC-KOL协作](08-子系统-KOC-KOL协作.md) | KOC/KOL 匹配、内容跟踪、JOYCOLLAB 同步 |\n| [09-子系统-审计与通知中心](09-子系统-审计与通知中心.md) | 审计日志、多类型通知告警 |\n 544|", + "wikilinks": [], + "category": "layer-requirements" + } + }, + { + "id": "doc:05_需求文档/01-子系统-用户身份与上下文", + "type": "document", + "name": "子系统 01 — 用户身份与上下文 (`identity`) v1.0", + "filePath": "05_需求文档/01-子系统-用户身份与上下文.md", + "summary": "子系统 01 — 用户身份与上下文 identity v1.0 子系统概述 维度 说明 代号 identity 核心职责 真实人识别与归并、身份线索关联、用户上下文卡生成 数据所有权 person profiles , person identity links , contact context snapshots , device records 启动依", + "tags": [ + "05_需求文档", + "需求文档" + ], + "complexity": "moderate", + "knowledgeMeta": { + "content": "# 子系统 01 — 用户身份与上下文 (`identity`) v1.0\n\n## 子系统概述\n\n| 维度 | 说明 |\n| --- | --- |\n| 代号 | `identity` |\n| 核心职责 | 真实人识别与归并、身份线索关联、用户上下文卡生成 |\n| 数据所有权 | `person_profiles`, `person_identity_links`, `contact_context_snapshots`, `device_records` |\n| 启动依赖 | 无硬依赖（需 JOYHUB 数据同步到位） |\n| 外部系统依赖 | JOYHUB（用户数据）、APP（设备数据） |\n\n---\n\n## 1. 模块划分\n\n### 整体模块图\n\n```\n┌─────────────────────────────────────────────────────────────┐\n│ identity 子系统 │\n│ │\n│ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │\n│ │ M1: 身份线索 │ │ M2: 真实人 │ │ M3: 用户上下 │ │\n│ │ 采集与同步 │→│ 归并引擎 │→│ 文卡服务 │ │\n│ └──────┬───────┘ └──────┬───────┘ └──────┬───────┘ │\n│ │ │ │ │\n│ ▼ ▼ ▼ │\n│ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │\n│ │ M4: 设备变化 │ │ M5: 身份管理 │ │ M6: 对外 API │ │\n│ │ 识别 │ │ Admin │ │ Gateway │ │\n│ └──────────────┘ └──────────────┘ └──────────────┘ │\n│ │\n└─────────────────────────────────────────────────────────────┘\n```\n\n### 模块明细\n\n| # | 模块 | 代号 | 职责 |\n| --- | --- | --- | --- |\n| M1 | 身份线索采集与同步 | `identity-ingest` | 从 JOYHUB、APP 等外部系统拉取/接收身份线索（JOYHUB ID、邮箱、电话、设备号、订单关联） |\n| M2 | 真实人归并引擎 | `person-merge` | 按标准姓名+地址、多线索交叉权重归并，生成/更新真实人 ID |\n| M3 | 用户上下文卡服务 | `context-card` | 聚合身份+交易+服务+风险+设备+触达全量数据生成上下文快照 |\n| M4 | 设备变化识别 | `device-tracker` | 识别设备号变化、换机、多设备场景，记录设备变化日志 |\n| M5 | 身份管理 Admin | `identity-admin` | 人工归并/拆分操作、归并冲突处理、身份数据校正 |\n| M6 | 对外 API Gateway | `identity-api` | 向其他子系统提供真实人查询、上下文卡查询、归并请求等 API |\n\n---\n\n## 2. 各模块内外说明\n\n### 2.1 M1: 身份线索采集与同步\n\n| 维度 | 说明 |\n| --- | --- |\n| **对内** | 管理外部系统的数据同步任务（定时拉取 JOYHUB 用户数据、设备数据）；解析和标准化各来源的身份线索（邮箱规范化、电话格式化、地址标准化）；写入 `person_identity_links` 表 |\n| **对外接口** | `POST /internal/identity/ingest — 接收上游推送的身份线索`；同步调度器可配置频率 |\n| **数据写入** | `person_identity_links`（线索类型 + 线索值 + 来源系统 + 采集时间） |\n\n### 2.2 M2: 真实人归并引擎\n\n| 维度 | 说明 |\n| --- | --- |\n| **对内** | 执行归并规则：标准姓名+地址一致→同一真实人；多线索交叉（设备+电话+邮箱+收款信息）按权重打分；地址一致姓名不同→标记家庭关联但不合并；生成真实人 ID、归并证据、置信度 |\n| **对外接口** | `POST /api/identity/merge — 触发归并`；返回归并结果（真实人 ID + 置信度） |\n| **数据写入** | `person_profiles`（真实人创建/更新）、`person_identity_links`（关联关系更新） |\n| **关键规则** | 邮箱不同+JOYHUB ID 不同不能单独否定「同一真实人」；订单号命中历史异常需拉出风险记录 |\n\n### 2.3 M3: 用户上下文卡服务\n\n| 维度 | 说明 |\n| --- | --- |\n| **对内** | 聚合 6 组字段（当前身份、真实人归并、历史交易、历史服务、历史风险、当前设备、触达历史）；生成上下文快照（含快照时间）；首次生成 vs 增量更新 |\n| **对外接口** | `GET /api/identity/context/{person_id} — 获取用户上下文卡`；返回聚合后的全量上下文 |\n| **数据写入** | `contact_context_snapshots` |\n| **依赖其他子系统** | 交易数据来自 planning；服务数据来自 support；风险数据来自 risk；触达数据来自 outreach（通过 API 聚合或事件） |\n\n### 2.4 M4: 设备变化识别\n\n| 维度 | 说明 |\n| --- | --- |\n| **对内** | 监控同一 JOYHUB ID 下设备号变化；记录换机/多设备事件；关联设备型号、系统版本、APP 版本变化 |\n| **对外接口** | 内部事件 `device.changed` 供其他模块消费 |\n| **数据写入** | `device_records`（设备变化时间、变化类型） |\n| **待确认** | 多久内的设备变化算「近期换机」？多设备同时活跃如何标记？ |\n\n### 2.5 M5: 身份管理 Admin\n\n| 维度 | 说明 |\n| --- | --- |\n| **对内** | 提供人工归并操作界面（两个真实人合并为一个）；归并拆分（合并错了如何回退）；冲突处理（系统自动归并 vs 人工判定不一致时） |\n| **对外接口** | 管理 API（不对其他子系统暴露） |\n| **数据写入** | 所有身份相关表（权限控制） |\n\n### 2.6 M6: 对外 API Gateway\n\n| 维度 | 说明 |\n| --- | --- |\n| **对内** | 统一对外 API 认证、限流、日志 |\n| **对外接口** | `GET /api/identity/person?线索类型=&线索值=` — 按线索查真实人；`GET /api/identity/context/{person_id}` — 用户上下文卡；`POST /api/identity/batch-check` — 批量身份查询 |\n\n---\n\n## 3. 对外 API 契约（草案）\n\n| 接口 | 方法 | 输入 | 输出 | 消费者 |\n| --- | --- | --- | --- | --- |\n| 按线索查真实人 | `GET /api/identity/person` | `?type=email&value=xxx@yy.com` 或 `?type=joyhub_id&value=123` | `{person_id, confidence, matched_clues[]}` | 所有子系统 |\n| 获取用户上下文卡 | `GET /api/identity/context/{person_id}` | `person_id` | `{identity, transactions, services, risks, devices, outreach_history}` | support, risk, outreach |\n| 批量身份查询 | `POST /api/identity/batch-check` | `[{type, value}, ...]` | `[{person_id, confidence}, ...]` | planning, outreach |\n| 触发归并 | `POST /api/identity/merge` | `{clues: [{type, value}, ...]}` | `{person_id, is_new, confidence}` | outreach（每次互动时调用） |\n\n---\n\n## 4. 数据对象（本子系统写入）\n\n| 对象 | 核心字段 | 说明 |\n| --- | --- | --- |\n| `person_profiles` | person_id, status, created_at, updated_at, merge_evidence | 真实人主表 |\n| `person_identity_links` | person_id, clue_type (JOYHUB_ID/EMAIL/PHONE/DEVICE/ORDER_NAME_ADDRESS), clue_value, source, confidence, linked_at | 身份线索关联表 |\n| `contact_context_snapshots` | person_id, snapshot_time, identity_snapshot, transaction_snapshot, service_snapshot, risk_snapshot, device_snapshot, outreach_snapshot | 上下文快照 |\n| `device_records` | person_id, joyhub_id, device_id, device_model, os_version, app_version, change_type (NEW/SWITCH/MULTI), recorded_at | 设备变化记录 |\n\n---\n\n## 5. 业务澄清问题清单 — identity\n\n### 5.1 真实人归并规则（4 项）\n\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| I-01 | 标准姓名+地址的「标准化」规则是什么？（大小写、空格、缩写如 St./Street、middle name 处理？）标准化在哪个模块做？ | **P0** |\n| I-02 | 归并是多线索交叉权重打分——各维度的权重如何设定？（邮箱=0.3、设备=0.4、电话=0.2、收款=0.5？由谁定义？可否动态调整？） | **P0** |\n| I-03 | 归并是完全自动执行还是部分需要人工审核？触发人工审核的条件是什么？（置信度 < 多少？涉及风险用户？） | **P0** |\n| I-04 | 自动归并错误后如何拆分？拆分时如何处理已关联的历史评价和额度数据？（评价归属、额度扣减是否回滚？） | **P0** |\n\n### 5.2 非 APP 用户处理（3 项）\n\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| I-05 | 非 APP 用户的邮箱从哪里来？（Amazon 订单中的买家邮箱？EDM 列表？客服录入？）邮箱质量/有效性如何保证？ | **P0** |\n| I-06 | 只有邮箱没有设备号的非 APP 用户，归并置信度是否单独设置较低阈值？这种情况下如何确定是同一真实人？ | P1 |\n| I-07 | EDM 引导用户注册 APP 后——如何识别「这个新 APP 用户就是之前那个 EDM 邮箱用户」？（注册时要求填同一邮箱？设备号关联？） | P1 |\n\n### 5.3 设备与多账号（3 项）\n\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| I-08 | 「同设备多账号」的风险判断——同一个设备号关联了多个 JOYHUB ID，哪些情况正常（家庭共用）哪些算风险信号？ | P1 |\n| I-09 | 设备号变化的识别窗口——同一个 JOYHUB ID 下，设备号变化间隔多久内算「近期换机」？ | P1 |\n| I-10 | APP 卸载重装导致设备号变化怎么处理？（卸载重装可能生成新设备号） | P2 |\n\n### 5.4 用户上下文卡（3 项）\n\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| I-11 | 上下文卡的「快照」保留几份？每次互动生成新快照（保留历史）还是覆盖（只保留最新一份）？保留历史的话保留多久？ | P1 |\n| I-12 | 上下文卡中的历史交易、历史服务等数据是从其他子系统实时拉取还是从本地冗余存储读取？（涉及跨子系统数据一致性） | P1 |\n| I-13 | 上下文卡是否需要在某个条件触发时预生成（如用户接入前），还是每次实时生成？ | P2 |\n\n### 5.5 数据同步（2 项）\n\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| I-14 | JOYHUB 数据同步频率？（实时/每小时/每天？）同步方式？（API 拉取 / 消息队列 / 数据库直连？） | **P0** |\n| I-15 | JOYHUB 和 APP 端的数据字段完整清单是否已有？（注册邮箱、设备号、设备型号、APP 版本、系统版本、绑定玩具、活跃行为——文档已列出但需确认是否有遗漏） | **P0** |\n\n### 5.6 身份数据生命周期（4 项）\n\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| I-16 | 用户数据保留策略——身份线索和历史快照保留多久？（6个月？1年？永久？）超出保留期后是归档还是删除？ | P1 |\n| I-17 | 用户注销/数据删除请求如何处理？（用户要求删除所有个人数据——如何标记而不是物理删除以保持额度/风险记录的完整性？） | P1 |\n| I-18 | 「被遗忘权」实操——删除真实人记录后，与之关联的额度、风险、评价如何处理？（匿名化保留？还是级联删除？） | P1 |\n| I-19 | 用户主动修改关键身份信息（换邮箱、换电话）——系统如何感知和响应？（自动触发重新归并？还是保持原关联？） | P1 |\n\n### 5.7 多站点与跨平台身份（3 项）\n\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| I-20 | 同一个自然人在 Amazon.com 和 Amazon.co.uk 用不同邮箱和地址——是否跨站点归并为同一个「真实人」？ | P1 |\n| I-21 | 未来扩展到非 Amazon 平台（eBay/Walmart/独立站）——真实人体系是否需要跨平台？架构预留？ | P2 |\n| I-22 | 不同国家站点的地址标准化规则不同（US→州/邮编、UK→郡/邮编、DE→邮编/城市）——标准化引擎如何处理？ | P2 |\n\n### 5.8 归并冲突与人工干预（3 项）\n\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| I-23 | 系统自动归并和人工判定冲突时，以谁为准？（人工优先？系统告警→人工确认？）冲突记录保留多久？ | P1 |\n| I-24 | 人工拆分归并的操作是否需要审批？（谁来审批？审批流程？）拆分的审计记录保留什么字段？ | P1 |\n| I-25 | 是否存在「不确定」状态的真实人？（置信度太低无法归并，标记为「待定」——如何流转到人工审核？） | P1 |\n\n### 5.9 实施层面（3 项）\n\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| I-26 | 身份归并是实时还是异步？（用户接入时实时归并→阻塞用户体验 vs 异步归并→可能用旧数据？） | P1 |\n| I-27 | 上下文卡聚合的性能要求——单次查询需要在多少 ms 内返回？（涉及跨子系统调用时的超时和降级） | P2 |\n| I-28 | 如果 JOYHUB 数据同步中断，identity 子系统如何降级？（用缓存数据？标记为「数据可能过期」？） | P1 |\n", + "wikilinks": [], + "category": "layer-requirements" + } + }, + { + "id": "doc:05_需求文档/02-子系统-需求与计划管理", + "type": "document", + "name": "子系统 02 — 需求与计划管理 (`planning`) v1.0", + "filePath": "05_需求文档/02-子系统-需求与计划管理.md", + "summary": "子系统 02 — 需求与计划管理 planning v1.0 子系统概述 维度 说明 代号 planning 核心职责 需求触发（人工/自动）、需求评估、计划生成（推新/回评/免评）、审批工作流、ASIN 基础信息管理 数据所有权 demands , plans , plan items , approval records , asin catalog 启", + "tags": [ + "05_需求文档", + "需求文档" + ], + "complexity": "moderate", + "knowledgeMeta": { + "content": "# 子系统 02 — 需求与计划管理 (`planning`) v1.0\n\n## 子系统概述\n\n| 维度 | 说明 |\n| --- | --- |\n| 代号 | `planning` |\n| 核心职责 | 需求触发（人工/自动）、需求评估、计划生成（推新/回评/免评）、审批工作流、ASIN 基础信息管理 |\n| 数据所有权 | `demands`, `plans`, `plan_items`, `approval_records`, `asin_catalog` |\n| 启动依赖 | identity（软依赖，无 identity 可操作但无法做人群匹配） |\n| 外部系统依赖 | Amazon（ASIN 数据、销售数据、评价缺口） |\n\n---\n\n## 1. 模块划分\n\n```\n┌─────────────────────────────────────────────────────────────┐\n│ planning 子系统 │\n│ │\n│ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │\n│ │ M1: 需求管理 │ │ M2: 计划引擎 │ │ M3: 审批工作 │ │\n│ │ (Demand) │→│ (Plan) │→│ 流 │ │\n│ └──────┬───────┘ └──────┬───────┘ └──────┬───────┘ │\n│ │ │ │ │\n│ ▼ ▼ ▼ │\n│ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │\n│ │ M4: 自动触发 │ │ M5: ASIN管理 │ │ M6: 对外 API │ │\n│ │ 规则引擎 │ │ │ │ Gateway │ │\n│ └──────────────┘ └──────────────┘ └──────────────┘ │\n│ │\n└─────────────────────────────────────────────────────────────┘\n```\n\n| # | 模块 | 代号 | 职责 |\n| --- | --- | --- | --- |\n| M1 | 需求管理 | `demand-mgr` | 需求创建、评估（成立/待补充/驳回）、优先级管理、需求与 ASIN 关联 |\n| M2 | 计划引擎 | `plan-engine` | 从已确认需求生成计划（推新/回评/免评）、计划生命周期管理、计划项拆解 |\n| M3 | 审批工作流 | `approval-workflow` | 计划审批链（Amazon 运营总监→用户负责人→渠道负责人）、审批记录 |\n| M4 | 自动触发规则引擎 | `auto-trigger` | 按 ASIN 健康度、评价缺口自动触发需求；定时评估触发条件 |\n| M5 | ASIN 管理 | `asin-catalog` | ASIN 基础信息、评分、评价数、Listing 健康状态维护 |\n| M6 | 对外 API Gateway | `planning-api` | 向其他子系统提供计划查询、ASIN 查询、审批状态查询 API |\n\n---\n\n## 2. 各模块内外说明\n\n### 2.1 M1: 需求管理\n\n| 维度 | 说明 |\n| --- | --- |\n| **对内** | Amazon 运营人工提需求（选择 ASIN、指定类型：推新/回评/免评、目标数量、周期）；用户运营评估需求（查 ASIN 健康、目标数量、历史完成、当前资源）；评估结果：已确认/待补充/驳回 |\n| **对外接口** | `POST /api/demands` — 创建需求；`PUT /api/demands/{id}/evaluate` — 评估需求 |\n| **数据写入** | `demands` |\n| **依赖** | `GET /api/identity/person` — 评估时可能需要运营人员身份 |\n| **待确认** | 需求是否有优先级字段（P0/P1/P2）？驳回后是否允许重新提交？ |\n\n### 2.2 M2: 计划引擎\n\n| 维度 | 说明 |\n| --- | --- |\n| **对内** | 从已确认需求生成计划草案（类型：推新/回评/免评）；计划参数（目标 ASIN、目标数量、周期、预算、备注）；计划状态流转；计划项拆解（将计划拆成可分配给渠道的执行单元） |\n| **对外接口** | `POST /api/plans` — 创建计划；`PUT /api/plans/{id}/status` — 更新状态；`GET /api/plans/{id}/items` — 获取计划项 |\n| **数据写入** | `plans`, `plan_items` |\n| **依赖** | `GET /api/quota/check` — 生成人群前查询额度；`GET /api/risk/check` — 计划复核时查询风险 |\n| **待确认** | 计划是否可以包含多个 ASIN？推新和回评是否可以合并为一个计划？ |\n\n### 2.3 M3: 审批工作流\n\n| 维度 | 说明 |\n| --- | --- |\n| **对内** | 按计划类型路由不同审批链：（测评→Amazon运营总监 / 回评→总监或指定负责人 / 免评→总监+用户负责人 / 紧急→运营负责人+用户负责人+主管）；周/月推送计划审批（用户负责人→渠道负责人）；审批节点（通过/驳回/待补充） |\n| **对外接口** | `POST /api/approvals/{plan_id}/submit` — 提交审批；`PUT /api/approvals/{plan_id}/review` — 审批决策 |\n| **数据写入** | `approval_records` |\n| **依赖** | `GET /api/identity/person` — 获取审批人身份 |\n| **待确认** | 审批链是否可以动态配置（不同站点/国家不同审批人）？驳回后修改再提交是否需要重新走完整审批链？ |\n\n### 2.4 M4: 自动触发规则引擎\n\n| 维度 | 说明 |\n| --- | --- |\n| **对内** | 定时扫描 ASIN 健康状态（评分、评价数、差评比例）；当满足触发条件时自动创建需求（无需人工干预）；触发规则可配置 |\n| **对外接口** | 内部定时任务，不对外暴露 |\n| **数据写入** | `demands`（自动生成的需求） |\n| **依赖** | `GET /api/reviews/asin-health` 或本地 ASIN 数据 |\n| **待确认** | 自动触发后是否需要人工确认还是直接进入评估？自动触发的优先级如何设定？ |\n\n### 2.5 M5: ASIN 管理\n\n| 维度 | 说明 |\n| --- | --- |\n| **对内** | ASIN 基础信息（ASIN 码、标题、品类、站点）；评分、评价总数、差评数；Listing 健康状态（活跃/风险/下架）；与计划的关联关系 |\n| **对外接口** | `GET /api/asins/{asin}` — ASIN 详情；`GET /api/asins?status=at_risk` — 需关注的 ASIN 列表 |\n| **数据写入** | `asin_catalog` |\n| **依赖** | Amazon 数据同步（外部系统） |\n| **待确认** | ASIN 数据是否已在 JOYHUB 或其他系统中维护？是否需要新建还是复用？ |\n\n### 2.6 M6: 对外 API Gateway\n\n| 维度 | 说明 |\n| --- | --- |\n| **对内** | 统一对外 API 认证、限流、日志 |\n| **对外接口** | `GET /api/plans?status=approved` — 待执行计划（outreach 消费）；`GET /api/plans/{id}` — 计划详情（review 消费）；`GET /api/asins/{asin}` — ASIN 查询 |\n\n---\n\n## 3. 对外 API 契约（草案）\n\n| 接口 | 方法 | 输入 | 输出 | 消费者 |\n| --- | --- | --- | --- | --- |\n| 创建需求 | `POST /api/demands` | `{asin, type, target_count, period, priority}` | `{demand_id, status}` | 运营前端 |\n| 评估需求 | `PUT /api/demands/{id}/evaluate` | `{decision, reason}` | `{status}` | 用户运营前端 |\n| 创建计划 | `POST /api/plans` | `{demand_id, type, params}` | `{plan_id}` | 用户运营前端 |\n| 待执行计划列表 | `GET /api/plans?status=approved` | 无 | `[{plan_id, type, items}]` | outreach |\n| 计划详情 | `GET /api/plans/{id}` | `plan_id` | 完整计划含审批记录 | review / outreach |\n| ASIN 查询 | `GET /api/asins/{asin}` | `asin` | ASIN 详情+健康状态 | 所有子系统 |\n\n---\n\n## 4. 数据对象\n\n| 对象 | 核心字段 | 说明 |\n| --- | --- | --- |\n| `demands` | demand_id, asin, type (NEW/REVIEW/EXEMPTION), target_count, period, status (PENDING/EVALUATING/CONFIRMED/REJECTED/WAITING), priority, created_by, evaluated_by, created_at | 需求主表 |\n| `plans` | plan_id, demand_id, type, status (DRAFT/REVIEW/APPROVED/EXECUTING/COMPLETED/CANCELLED), target_count, period, created_at | 计划主表 |\n| `plan_items` | item_id, plan_id, asin, item_type, target_count, assigned_channel, status | 计划执行项 |\n| `approval_records` | approval_id, plan_id, approver, decision, comment, decided_at, step_order | 审批记录 |\n| `asin_catalog` | asin, title, category, marketplace, rating, review_count, negative_count, health_status, last_synced_at | ASIN 信息 |\n\n---\n\n## 5. 业务澄清问题清单 — planning\n\n### 5.1 需求与计划模型（5 项）\n\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| P-01 | 一个需求是否可以生成多个计划？（例如一个回评需求拆分到 IM 计划和 EDM 计划）还是一对一？ | **P0** |\n| P-02 | 计划是否可以跨 ASIN？（一个推新计划覆盖 3 个新 ASIN）还是每个计划只针对一个 ASIN？ | **P0** |\n| P-03 | 计划中的「目标数量」是指目标评价数还是目标触达用户数？（如果转化率 2%，要得到 10 个评价需触达 500 人） | **P0** |\n| P-04 | 计划的「周期」是什么粒度？（周/月/自定义日期范围？）周期结束后未完成的计划如何处理？ | P1 |\n| P-05 | 需求是否有优先级？（P0/P1/P2 或高/中/低？）优先级影响什么？（审批速度？资源分配？） | P1 |\n\n### 5.2 审批流程（4 项）\n\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| P-06 | 文档提到「免评计划 → Amazon 运营总监 + 用户负责人」审批——是两者都必须通过（会签）还是任一通过即可（或签）？ | **P0** |\n| P-07 | 「指定负责人」的指定规则是什么？（按 ASIN 品类？按站点？按当前负载？人工指定？） | P1 |\n| P-08 | 审批超时如何处理？（审批人 N 天未处理，自动通过？自动驳回？升级到上级？） | P1 |\n| P-09 | 审批驳回后修改再提交，审批链是否重置还是从当前节点继续？ | P1 |\n\n### 5.3 自动触发（3 项）\n\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| P-10 | 自动触发的具体阈值是什么？（① ASIN 评分低于多少？② 差评在最近 N 天新增多少？③ 评价总数 < 目标值？） | **P0** |\n| P-11 | 自动触发是每天跑一次还是实时监控？（如果是实时，高频变化的 ASIN 会不会重复触发？） | P1 |\n| P-12 | 自动触发生成的需求是否自动进入评估环节还是需要人工确认后才进入？ | P2 |\n\n### 5.4 ASIN 管理（3 项）\n\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| P-13 | ASIN 数据来源和更新频率？（从 Amazon API 拉取？T+1？实时？手动导入？） | **P0** |\n| P-14 | ASIN 的「Listing 健康状态」如何定义？（评分 ≥ 4.2 = 健康？差评率 < X%？）健康度是否有多个等级？ | P1 |\n| P-15 | ASIN 是否有关联关系？（变体 ASIN、父 ASIN-子 ASIN）关联合并还是独立管理？ | P2 |\n\n### 5.5 计划执行衔接（2 项）\n\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| P-16 | 计划审批通过后如何流转到 outreach 子系统？（planning 主动推送？outreach 定时拉取？事件通知？） | P1 |\n| P-17 | 计划执行过程中是否可以调整目标数量或周期？调整是否需要重新审批？ | P2 |\n\n### 5.6 计划模板与复用（3 项）\n\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| P-18 | 是否需要计划模板功能？（对常推的 ASIN 创建可复用的计划模板——模板包含预设的渠道/目标数/周期？） | P1 |\n| P-19 | 周期性计划（如「每月 1 号自动对 ASIN X 发起回评计划」）是否支持？谁有权限创建？ | P2 |\n| P-20 | 计划是否可以暂停/恢复？（执行中因库存或供应链原因需暂停——暂停期间已触达的用户如何处理？） | P1 |\n\n### 5.7 预算与资源管理（3 项）\n\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| P-21 | 计划是否有预算字段？（返款金额、Code 成本、KOC 费用——是否需要预算审批？超出预算如何处理？） | P1 |\n| P-22 | 资源容量规划——同时可执行的计划数是否有上限？（受限于客服人力/EDM发送额度/IM频控？） | P1 |\n| P-23 | 是否需要计划执行成本的 ROI 计算？（返款总额 / 获得的评价数 = 单评价成本——系统自动计算还是手动录入？） | P2 |\n\n### 5.8 季节性/大促处理（3 项）\n\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| P-24 | Prime Day / Black Friday 等大促期间的计划是否有特殊处理？（提前锁定额度、加大推送量、豁免某些频控规则？） | P1 |\n| P-25 | 大促前的「预热计划」和大促后的「回评计划」是否需要在系统中作为计划间的依赖关系来管理？ | P2 |\n| P-26 | 季节性产品（圣诞装饰、夏季用品）的计划是否有时间敏感度标记？（错过季节窗口的计划自动降级？） | P2 |\n\n### 5.9 多站点/多市场（3 项）\n\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| P-27 | 不同 Amazon 站点的计划是否可以统一管理？（同一个 ASIN 在不同站点是独立计划还是关联计划？） | P1 |\n| P-28 | 多站点的审批人是否不同？（.com 的运营总监和 .co.uk 的运营总监可能是不同人） | P1 |\n| P-29 | 跨站点需求的冲突检测？（.com 和 .de 同时对同一真实的同一用户做了不同计划——算不算冲突？） | P2 |\n\n### 5.10 实施层面（3 项）\n\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| P-30 | 自动触发生成的需求如果无人处理（评估超时），是否自动驳回还是升级通知？ | P1 |\n| P-31 | 审批工作流引擎——是否有现成的审批引擎可复用？（还是需要从零开发状态机？） | P2 |\n| P-32 | 计划执行过程中用户反馈「不想再收到」——是标记为退订（outreach 处理）还是需要回写到 planning 的计划状态中？ | P1 |\n", + "wikilinks": [], + "category": "layer-requirements" + } + }, + { + "id": "doc:05_需求文档/03-子系统-额度与频控", + "type": "document", + "name": "子系统 03 — 额度与频控 (`quota`) v1.0", + "filePath": "05_需求文档/03-子系统-额度与频控.md", + "summary": "子系统 03 — 额度与频控 quota v1.0 2 子系统概述 4 维度 说明 代号 quota 核心职责 额度台账（测评4/免评4/累计12）、额度预占与释放、频控规则引擎、发送前终校 数据所有权 person quota ledgers , quota reservations , frequency control records 启动依赖 ide", + "tags": [ + "05_需求文档", + "需求文档" + ], + "complexity": "moderate", + "knowledgeMeta": { + "content": "# 子系统 03 — 额度与频控 (`quota`) v1.0\n 2|\n## 子系统概述\n 4|\n| 维度 | 说明 |\n| --- | --- |\n| 代号 | `quota` |\n| 核心职责 | 额度台账（测评4/免评4/累计12）、额度预占与释放、频控规则引擎、发送前终校 |\n| 数据所有权 | `person_quota_ledgers`, `quota_reservations`, `frequency_control_records` |\n| 启动依赖 | identity（软依赖，额度按真实人计算，未归并时按单一账号） |\n| 外部系统依赖 | 无直接外部依赖 |\n 12|\n---\n 14|\n## 1. 模块划分\n 16|\n```\n┌─────────────────────────────────────────────────────────────┐\n│ quota 子系统 │\n│ │\n│ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │\n│ │ M1: 额度台账 │ │ M2: 预占管理 │ │ M3: 频控引擎 │ │\n│ │ (Ledger) │→│ (Reservation)│ │ (FreqCtrl) │ │\n│ └──────┬───────┘ └──────┬───────┘ └──────┬───────┘ │\n│ │ │ │ │\n│ ▼ ▼ ▼ │\n│ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │\n│ │ M4: 终校服务 │ │ M5: 额度管理 │ │ M6: 对外 API │ │\n│ │ (FinalCheck)│ │ Admin │ │ Gateway │ │\n│ └──────────────┘ └──────────────┘ └──────────────┘ │\n│ │\n└─────────────────────────────────────────────────────────────┘\n```\n 34|\n| # | 模块 | 代号 | 职责 |\n| --- | --- | --- | --- |\n| M1 | 额度台账 | `quota-ledger` | 维护真实人三层额度（测评4/免评4/累计12）、已用/进行中/已预占计数 |\n| M2 | 预占管理 | `reservation-mgr` | 额度预占创建、确认占用、超时释放；跨计划重复入选检测 |\n| M3 | 频控引擎 | `freq-control` | 渠道频控（IM/EDM/APP/TEL 最近触达间隔）、单 ASIN 短期触达次数、退订/投诉屏蔽 |\n| M4 | 终校服务 | `final-check` | 发送前合并校验（最新额度 + 最新风险 + 最新未关闭工单），准入/撤出决策 |\n| M5 | 额度管理 Admin | `quota-admin` | 额度手动调整、额度重置、额度审计 |\n| M6 | 对外 API Gateway | `quota-api` | 供 planning（人群生成）、outreach（发送前校验）、review（提交后确认）调用 |\n 43|\n---\n 45|\n## 2. 各模块内外说明\n 47|\n### 2.1 M1: 额度台账\n 49|\n| 维度 | 说明 |\n| --- | --- |\n| **对内** | 按真实人维护三种额度：月度测评（已完成+进行中+已预占）、月度免评（同上）、累计真实提交评价（永久累计）；额度计数时点明确（提交评价立即计数12、不会因 Amazon 未展示回退）；接近上限时预警 |\n| **对外接口** | `GET /api/quota/ledger/{person_id}` — 读取当前台账 |\n| **数据写入** | `person_quota_ledgers` |\n| **依赖** | `GET /api/identity/person` — 获取真实人 ID |\n 56|\n### 2.2 M2: 预占管理\n 58|\n| 维度 | 说明 |\n| --- | --- |\n| **对内** | 人群生成时预占额度（测评/免评）；计算：已用+进行中+已预占+本次拟发送 > 上限 → 拦截；剩余不足但>0 → 预警池 → 发送前人工复核；预占有效期管理，超时自动释放；并发占用控制（同一真实人跨计划重复入选检测） |\n| **对外接口** | `POST /api/quota/reserve` — 创建预占；`POST /api/quota/commit` — 确认占用；`POST /api/quota/release` — 释放预占 |\n| **数据写入** | `quota_reservations` |\n 64|\n### 2.3 M3: 频控引擎\n 66|\n| 维度 | 说明 |\n| --- | --- |\n| **对内** | 四种频控维度：①渠道频控（IM/EDM/APP/TEL 最近触达间隔）②单 ASIN 短期内触达同一用户次数 ③用户反感度（投诉/退订状态）④用户在客服工单中暂不触达；频控规则可配置 |\n| **对外接口** | `GET /api/quota/freq-check/{person_id}?channel=IM&asin=xxx` — 频控检查 |\n| **数据写入** | `frequency_control_records` |\n| **依赖** | 触达历史来自 outreach（`GET /api/outreach/history/{person_id}`） |\n 73|\n### 2.4 M4: 终校服务\n 75|\n| 维度 | 说明 |\n| --- | --- |\n| **对内** | 发送前做最终校验：①重新读取最新额度（防止发送和预占之间额度变化）②重新读取最新风险状态 ③重新读取最新未关闭工单；三者全部通过→准入发送；任一新增超限/风险/工单→撤出本批次 |\n| **对外接口** | `POST /api/quota/final-check` — 批量终校（输入 person_ids + plan_id，返回每个的准入/撤出决策） |\n| **数据写入** | 终校结果写入审计日志 |\n| **依赖** | `GET /api/risk/check/{person_id}`；`GET /api/tickets?person_id=&status=open` |\n 82|\n### 2.5 M5: 额度管理 Admin\n 84|\n| 维度 | 说明 |\n| --- | --- |\n| **对内** | 额度手动调整（运营确认某次测评不计入额度等）；额度重置（新月份额度初始化）；额度审计（谁改了什么额度） |\n| **对外接口** | 管理 API |\n 89|\n### 2.6 M6: 对外 API Gateway\n 91|\n| 维度 | 说明 |\n| --- | --- |\n| **对外接口** | `GET /api/quota/check/{person_id}?type=测评` — 额度查询+可用判断；`POST /api/quota/reserve` — 预占；`POST /api/quota/commit` — 确认；`POST /api/quota/release` — 释放；`POST /api/quota/final-check` — 终校 |\n 95|\n---\n 97|\n## 3. 对外 API 契约（草案）\n 99|\n| 接口 | 方法 | 输入 | 输出 | 消费者 |\n| --- | --- | --- | --- | --- |\n| 额度查询 | `GET /api/quota/check/{person_id}?type=REVIEW` | person_id + 额度类型 | `{used, in_progress, reserved, remaining, status(sufficient/warning/exceeded)}` | planning, outreach |\n| 批量预占 | `POST /api/quota/reserve` | `[{person_id, type, plan_id, count}]` | `[{person_id, success, reservation_id}]` | planning（人群生成时） |\n| 确认占用 | `POST /api/quota/commit` | `[{reservation_id}]` | `[{reservation_id, committed}]` | review（用户提交评价后） |\n| 释放预占 | `POST /api/quota/release` | `[{reservation_id}]` | `[{success}]` | planning（计划取消时） |\n| 频控检查 | `GET /api/quota/freq-check/{person_id}?channel=&asin=` | person_id + 渠道 + ASIN | `{allowed, reason, cooldown_until}` | outreach（发送前） |\n| 发送前终校 | `POST /api/quota/final-check` | `[{person_id, plan_id}]` | `[{person_id, decision: APPROVED/WITHDRAWN, reasons}]` | outreach（发送前最后一步） |\n 108|\n---\n 110|\n## 4. 数据对象\n 112|\n| 对象 | 核心字段 | 说明 |\n| --- | --- | --- |\n| `person_quota_ledgers` | ledger_id, person_id, quota_type (MONTHLY_REVIEW/MONTHLY_EXEMPTION/LIFETIME_SUBMISSION), period, used, in_progress, reserved, limit_value, status | 三层额度台账 |\n| `quota_reservations` | reservation_id, person_id, ledger_id, plan_id, count, status (RESERVED/COMMITTED/RELEASED/EXPIRED), reserved_at, expires_at | 额度预占记录 |\n| `frequency_control_records` | freq_id, person_id, channel, asin, last_contact_at, contact_count_period, status | 频控记录 |\n 118|\n---\n 120|\n## 5. 业务澄清问题清单 — quota\n 122|\n### 5.1 额度规则细化（5 项）\n 124|\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| Q-01 | 月度额度按自然月还是 30 天滚动？如果是自然月：①预占在 1 月 31 日，2 月 1 日释放还是保留？②1 月 31 日晚 23:59 的预占跨月怎么处理？ | **P0** |\n| Q-02 | 「测评 4 次」中的「次」定义：是指参与 4 个不同的测评计划，还是提交 4 条评价？（如果 1 个计划要求用户提交 3 条评价，占 3 次还是 1 次？） | **P0** |\n| Q-03 | 「累计 12 个真实提交评价」是永久上限还是可以动态调整？（例如用户长期优质且评价质量高，是否可以人工放宽？放宽流程？） | P1 |\n| Q-04 | 测评和免评额度是否独立？（测评 4 次 + 免评 4 次 = 同一真实人一月最多参与 8 个计划？）还是测评和免评共享总额度？ | P1 |\n| Q-05 | 额度计算中「进行中」的定义——什么状态才算进行中？（已生成人群？已发送触达？用户已回应？已提交评价待核验？） | P1 |\n 132|\n### 5.2 预占机制（4 项）\n 134|\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| Q-06 | 预占有效期多长？（预占后用户始终未响应，多久释放？1 天？7 天？计划周期结束？） | **P0** |\n| Q-07 | 预占释放后是否可以自动重新分配给同一计划的其他用户？是否触发重新生成人群？ | P1 |\n| Q-08 | 跨计划并发占用检测——同一真实人在计划 A 和计划 B 同时被入选，谁先预占谁得？还是按计划优先级？ | P1 |\n| Q-09 | 预占是否可手动取消/释放？（运营发现某用户不应计入某计划时） | P2 |\n 141|\n### 5.3 频控规则（4 项）\n 143|\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| Q-10 | 各渠道频控的具体阈值是什么？（IM 每日最多 X 次？EDM 每周最多 Y 封？APP Push 每日最多 Z 条？TEL 每日最多 N 通？） | **P0** |\n| Q-11 | 频控规则是否区分计划类型？（紧急催评是否可以突破频控？） | P1 |\n| Q-12 | 频控是全局统一配置还是按用户层级可调整？（A 类和 C 类用户频控规则是否不同？） | P1 |\n| Q-13 | 「单 ASIN 短期触达次数」——多少天内触达多少次算超标？ | P2 |\n 150|\n### 5.4 预警与异常（3 项）\n 152|\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| Q-14 | 预警阈值如何设定？（剩余 1 次时预警？剩余 N% 时预警？不同类型额度预警阈值是否不同？） | P1 |\n| Q-15 | 终校中「新增风险」的判断——距离上次风险检查超过多少时间需重查？还是每次终校都实时查 risk？ | P1 |\n| Q-16 | 额度数据异常时的处理策略？（台账数据与预占记录不一致、预占未释放导致额度泄漏——系统如何自动发现和修复？） | P2 |\n 158|\n### 5.5 额度异常与纠错（4 项）\n\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| Q-17 | 用户反馈「我明明只参与了 3 次测评，系统说我已用 4 次」——申诉流程？谁有权限查台账和修正？ | P1 |\n| Q-18 | 额度台账的审计追踪——每次额度变更（预占/确认/释放/手动调整）是否记录完整操作人和原因？保留多久？ | P1 |\n| Q-19 | 数据异常自动检测——台账数据与预占记录之和是否需要对账？系统是否定期自动化对账并报告差异？ | P1 |\n| Q-20 | 如果发现「额度泄漏」（预占未释放导致额度永久被占），系统如何自动发现和修复？（定时扫描过期预占？手动触发对账？） | P2 |\n\n### 5.6 紧急/例外处理（4 项）\n\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| Q-21 | 大促期间（Prime Day/Black Friday）是否需要临时额度提升？（测评 4→8？）由谁审批？临时额度有效期？ | P1 |\n| Q-22 | 高价值用户是否可以突破额度限制？（例如 KOC 级别的用户需要超额参与——人工审批流程？） | P1 |\n| Q-23 | 「紧急计划」是否可以跳过频控？（例如 Listing 评分暴跌至 3.8 需要紧急大量催评——是否豁免部分频控规则？） | P1 |\n| Q-24 | 额度手动调整是否需要审批？审批权限？（谁可以手动给某人加/减可用额度？） | P2 |\n\n### 5.7 跨站点/跨平台额度（3 项）\n\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| Q-25 | 额度是否跨 Amazon 站点？（.com 参与了 2 次测评 + .co.uk 参与了 3 次 → 全局算 5 次还是各自独立？） | P1 |\n| Q-26 | 累计 12 个评价是否跨站点统计？（在 .com 提交了 8 个 + .co.uk 提交了 5 个 → 是否算 13 个超限？） | P1 |\n| Q-27 | 未来扩展到非 Amazon 平台，额度体系是否独立？（eBay 的测评额度与 Amazon 的额度是否共享？） | P2 |\n\n### 5.8 额度可见性（2 项）\n\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| Q-28 | 用户是否能看到自己的额度状态？（APP 端显示「本月还可参与 2 次测评」——是否对用户可见？） | P2 |\n| Q-29 | 运营视角的额度看板——能否看到「全局额度使用率」「各真实人的额度分布」「额度预警用户列表」？ | P1 |\n\n### 5.9 实施层面（3 项）\n\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| Q-30 | 终校服务的性能要求——批量终校（一次可能几百人）需要在多少 ms 内完成？（涉及跨子系统调用 risk + support） | P2 |\n| Q-31 | 频控规则是否需要热更新（不重启服务即可调整阈值）？配置管理方案？ | P1 |\n| Q-32 | 额度台账历史数据的初始化——旧系统的数据如何映射到三层额度模型？（无「真实人」概念的老数据如何归入？） | P1 |\n", + "wikilinks": [], + "category": "layer-requirements" + } + }, + { + "id": "doc:05_需求文档/04-子系统-多渠道触达引擎", + "type": "document", + "name": "子系统 04 — 多渠道触达引擎 (`outreach`) v1.0", + "filePath": "05_需求文档/04-子系统-多渠道触达引擎.md", + "summary": "子系统 04 — 多渠道触达引擎 outreach v1.0 2 子系统概述 4 维度 说明 代号 outreach 核心职责 渠道路由决策、渠道去重、IM/EDM/APP Push/TEL 渠道调度执行、触达历史管理 数据所有权 channel route decisions , channel dedup records , im interaction", + "tags": [ + "05_需求文档", + "需求文档" + ], + "complexity": "moderate", + "knowledgeMeta": { + "content": "# 子系统 04 — 多渠道触达引擎 (`outreach`) v1.0\n 2|\n## 子系统概述\n 4|\n| 维度 | 说明 |\n| --- | --- |\n| 代号 | `outreach` |\n| 核心职责 | 渠道路由决策、渠道去重、IM/EDM/APP Push/TEL 渠道调度执行、触达历史管理 |\n| 数据所有权 | `channel_route_decisions`, `channel_dedup_records`, `im_interaction_records`, `im_flow_tags`, `edm_message_events`, `edm_user_behavior_profiles`, `app_touch_events`, `tel_call_records` |\n| 启动依赖 | identity / planning / quota（均为软依赖） |\n| 外部系统依赖 | JOYHUB（IM 通道）、ESP（EDM）、FCM/APNs（APP Push）、电话系统（TEL） |\n 12|\n---\n 14|\n## 1. 模块划分\n 16|\n```\n┌─────────────────────────────────────────────────────────────┐\n│ outreach 子系统 │\n│ │\n│ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │\n│ │ M1: 渠道路由 │ │ M2: 渠道去重 │ │ M3: IM 执行 │ │\n│ │ + 优先级 │→│ │→│ 引擎 │ │\n│ └──────────────┘ └──────────────┘ └──────┬───────┘ │\n│ │ │\n│ ┌──────────────┐ ┌──────────────┐ ┌──────┴───────┐ │\n│ │ M4: EDM 执行 │ │ M5: APP Push │ │ M6: TEL 执行 │ │\n│ │ 引擎 │ │ 引擎 │ │ 引擎 │ │\n│ └──────────────┘ └──────────────┘ └──────────────┘ │\n│ │\n│ ┌──────────────┐ ┌──────────────┐ │\n│ │ M7: 触达历史 │ │ M8: 对外 API │ │\n│ │ 服务 │ │ Gateway │ │\n│ └──────────────┘ └──────────────┘ │\n│ │\n└─────────────────────────────────────────────────────────────┘\n```\n 38|\n| # | 模块 | 职责 |\n| --- | --- | --- |\n| M1 | 渠道路由+优先级 | 按用户状态路由到最优渠道（APP活跃→IM优先 / 未注册→EDM优先 / 高价值无响应→TEL / C类→IM免评卡片） |\n| M2 | 渠道去重 | 同一计划同一用户不重复走多渠道路由；工单中暂停自动触达；已提交待核验暂停催评 |\n| M3 | IM 执行引擎 | IM 推送、用户分层（A未参与/B参与过/C长期测评人）、回评/测评/免评卡片推送、催评、提交核验、返款通知 |\n| M4 | EDM 执行引擎 | EDM 发送、送达/打开/点击追踪、行为画像、节奏控制、退订/硬退信处理 |\n| M5 | APP Push 引擎 | APP 推送、触发源管理（绑定玩具/不活跃/计划到期/Listing紧急/活动）、响应追踪 |\n| M6 | TEL 执行引擎 | 电话任务生成、拨打前准备（用户画像+风险检查+历史沟通）、通话记录、重试策略 |\n| M7 | 触达历史服务 | 统一触达历史查询（跨渠道聚合）、供 quota（频控）、identity（上下文卡）调用 |\n| M8 | 对外 API Gateway | 统一对外 API |\n 49|\n---\n 51|\n## 2. 各模块内外说明\n 53|\n### 2.1 M1: 渠道路由+优先级\n 55|\n| 维度 | 说明 |\n| --- | --- |\n| **对内** | 接收 planning 的已批准计划，按用户状态矩阵决定渠道：APP活跃+已绑定→IM首选；APP低活跃→EDM补充+APP Push召回；未注册→EDM首选→引导注册后转IM；高价值+多次无响应→TEL；C类（累计≥12）→IM免评卡片+KOC/KOL协同 |\n| **对外接口** | `POST /api/outreach/route` — 输入计划+用户，返回路由决策 |\n| **数据写入** | `channel_route_decisions` |\n| **依赖** | `GET /api/identity/context/{person_id}` — 用户状态 |\n 62|\n### 2.2 M2: 渠道去重\n 64|\n| 维度 | 说明 |\n| --- | --- |\n| **对内** | 执行去重规则（同一计划同一用户首选渠道、工单中暂停、已提交评价暂停、退订某渠道永久排除、强关联风险全暂停、弱关联降频+提示） |\n| **对外接口** | `GET /api/outreach/dedup-check?person_id=&plan_id=` |\n| **数据写入** | `channel_dedup_records` |\n| **依赖** | `GET /api/tickets?person_id=&status=open`（support）；`GET /api/risk/check/{person_id}`（risk） |\n 71|\n### 2.3 M3: IM 执行引擎\n 73|\n| 维度 | 说明 |\n| --- | --- |\n| **对内** | 用户分层逻辑（A未参与/B参与过但<12/C≥12长期测评人）；分层推送策略（A推回评卡片/B先催评再二次转化/C仅免评）；提交后的核验与流转（订单号核实→登记→补全信息→返款→二次转化）；标签管理（9 种核心标签如「xx产品已回评用户」「xx产品测评待返款用户」等） |\n| **对外接口** | `POST /api/outreach/im/send` — 发送 IM 消息 |\n| **数据写入** | `im_interaction_records`, `im_flow_tags` |\n| **依赖** | JOYHUB（IM 通道）；`GET /api/quota/check/{person_id}` |\n| **待确认** | IM 是 WhatsApp 还是自研 IM？通道对接方式？ |\n 81|\n### 2.4 M4: EDM 执行引擎\n 83|\n| 维度 | 说明 |\n| --- | --- |\n| **对内** | 推送前检查（身份→风险→退订→资格→国家）；行为筛选（打开/点击/回复/频率）；节奏判断（适合触达/需降频/不适合）；发送后追踪（送达→打开→点击→回复→退订）；转化路径（下载注册APP→转IM / 直接回复邮件→生成客服工单 / 未响应→再触达队列） |\n| **对外接口** | `POST /api/outreach/edm/send` — 发送 EDM |\n| **数据写入** | `edm_message_events`, `edm_user_behavior_profiles` |\n| **依赖** | ESP 邮件服务 |\n| **待确认** | EDM 模板在哪里管理？模板变量（用户名/产品名/链接）如何填充？ |\n 91|\n### 2.5 M5: APP Push 引擎\n 93|\n| 维度 | 说明 |\n| --- | --- |\n| **对内** | 5 种触发源（绑定新玩具/不活跃/计划到期/Listing紧急/活动）；推送前过滤（身份+风险+频控+标签）；响应追踪（点击打开→落地页 / 忽略→短期不重复推 / 卸载→转EDM候选池）；APP 内动作分流（提交回评/测评→IM核验 / 联系客服→工单 / 浏览→更新活跃标签） |\n| **对外接口** | `POST /api/outreach/app/push` — 发送 APP Push |\n| **数据写入** | `app_touch_events` |\n| **依赖** | FCM/APNs |\n| **待确认** | 是否复用 JOYHUB 现有 Push 通道？ |\n 101|\n### 2.6 M6: TEL 执行引擎\n 103|\n| 维度 | 说明 |\n| --- | --- |\n| **对内** | 7 种触发场景（答应配合超时/高价值跟进/复杂售后/多次无响应/紧急Listing/Amazon来电/外呼任务）；拨打前准备 5 步（查用户完整画像→查风险→查历史沟通→准备话术→生成电话工单）；通话结果 5 种（售后问题解决→引导回评 / 直接配合→登记答应配合 / 拒绝→记录 / 疑似诈骗→转风险 / 未接通→重试）；重试策略（<3次重拨 / ≥3次降级EDM或关闭） |\n| **对外接口** | `POST /api/outreach/tel/task` — 创建 TEL 任务 |\n| **数据写入** | `tel_call_records` |\n| **依赖** | 电话系统（外呼/来电） |\n 110|\n### 2.7 M7: 触达历史服务\n 112|\n| 维度 | 说明 |\n| --- | --- |\n| **对内** | 跨渠道聚合触达历史（IM/EDM/APP/TEL）；提供统一查询接口供 quota（频控）和 identity（上下文卡）消费 |\n| **对外接口** | `GET /api/outreach/history/{person_id}` |\n| **数据写入** | 只读聚合 |\n 118|\n---\n 120|\n## 3. 对外 API 契约（草案）\n 122|\n| 接口 | 方法 | 输入 | 输出 | 消费者 |\n| --- | --- | --- | --- | --- |\n| 触达历史 | `GET /api/outreach/history/{person_id}` | person_id | `{im[], edm[], app[], tel[]}` | quota（频控）, identity（上下文卡） |\n| 执行触达 | `POST /api/outreach/send` | `{plan_id, person_ids[], channel, content}` | `{task_id, status}` | planning |\n| 渠道路由决策 | `POST /api/outreach/route` | `{person_id, plan_id}` | `{recommended_channel, alternatives[]}` | planning |\n| IM 消息发送 | `POST /api/outreach/im/send` | `{person_id, msg_type, content}` | `{message_id}` | 内部 |\n 129|\n---\n 131|\n## 4. 数据对象\n 133|\n| 对象 | 核心字段 | 说明 |\n| --- | --- | --- |\n| `channel_route_decisions` | decision_id, person_id, plan_id, selected_channel, reason, decided_at | 渠道路由决策 |\n| `channel_dedup_records` | dedup_id, person_id, plan_id, channel, status(BLOCKED/ALLOWED), block_reason | 渠道去重记录 |\n| `im_interaction_records` | interaction_id, person_id, msg_type(PUSH_CARD/REVIEW_CARD/EXEMPTION_CARD/REMINDER/REFUND_NOTICE), direction(OUTBOUND/INBOUND), content, status, created_at | IM 交互记录 |\n| `im_flow_tags` | tag_id, person_id, tag_type, tag_value, tagged_at | IM 流程标签（如 xx产品待返款等） |\n| `edm_message_events` | event_id, person_id, email, event_type(SENT/DELIVERED/OPENED/CLICKED/REPLIED/UNSUBSCRIBED/HARD_BOUNCED), occurred_at | EDM 事件 |\n| `edm_user_behavior_profiles` | profile_id, person_id, email, last_opened_at, total_opens, consecutive_no_open, last_replied_at, monthly_received, status | EDM 用户行为画像 |\n| `app_touch_events` | event_id, person_id, trigger_type, push_status, response, occurred_at | APP Push 事件 |\n| `tel_call_records` | call_id, person_id, ticket_id, direction(OUTBOUND/INBOUND), call_status, duration, outcome, retry_count, recorded_at | TEL 通话记录 |\n 144|\n---\n 146|\n## 5. 业务澄清问题清单 — outreach\n 148|\n### 5.1 渠道优先级路由（4 项）\n 150|\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| O-01 | 路由规则是否可配置？（例如针对某个站点用户调整 IM > EDM 的优先级）配置界面在 outreach 内还是在独立配置管理？ | **P0** |\n| O-02 | 「APP 低活跃」的判定标准是什么？（N 天未打开？N 天未点击推送？）阈值是否可配置？ | P1 |\n| O-03 | 高优先级渠道发送失败（退信/未送达）后，是否自动降级到下一渠道？降级是否有冷却时间？ | P1 |\n| O-04 | C 类用户（累计≥12）只推免评——如果免评计划也没有，是完全不推还是推品牌/活动内容？ | P2 |\n 157|\n### 5.2 IM 通道（4 项）\n 159|\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| O-05 | IM 使用的具体平台是什么？（WhatsApp Business API / 自研 JOYHUB IM / Messenger？）不同平台的 API 能力和限制？ | **P0** |\n| O-06 | IM 的「分层」是系统自动判断还是人工可干预？（一个 B 类用户会不会被错误标记为 C 类？如何修正？） | **P0** |\n| O-07 | IM 推送中「测评卡片」的具体形式是什么？（带按钮的消息模板？需要用户填表单？）模板在哪里管理？ | P1 |\n| O-08 | IM 中的「订单号核实」——核实的数据源是什么？（比对内部订单表？Amazon 订单 API？）核实失败的转人工流程？ | P1 |\n 166|\n### 5.3 EDM 通道（4 项）\n 168|\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| O-09 | 当前使用的邮件服务是什么？（SendGrid/Mailchimp/SES/自建？）有没有现成 API 和 Webhook 追踪？ | **P0** |\n| O-10 | EDM 模板（邮件内容、样式、多语言）在哪里管理？属于 outreach 还是独立内容管理子系统？ | P1 |\n| O-11 | 「EDM 行为画像」中的「最近 3/5 次 0 打开」——3 次和 5 次是两个独立指标还是二选一？各自对应什么策略？ | P1 |\n| O-12 | EDM 发送量和频控——单日最大发送量有限制吗？（ESP 的每日限额？） | P1 |\n 175|\n### 5.4 APP Push（3 项）\n 177|\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| O-13 | APP Push 是否复用 JOYHUB 的现有推送通道？还是需要独立接入 FCM（Android）和 APNs（iOS）？ | **P0** |\n| O-14 | APP Push 和 IM 消息的分工——文档第 11.2 节给了对照表，但边界是否绝对？（例如\"计划到期提醒\"是否可能同时走 APP Push 和 IM？） | P1 |\n| O-15 | APP 落地页——推送点击后跳转到哪个页面？（APP 内的测评页？IM 对话页？）落地页由哪个团队/子系统负责？ | P2 |\n 183|\n### 5.5 TEL 通道（3 项）\n 185|\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| O-16 | 电话系统使用什么方案？（自建 SIP PBX / Twilio / 其他云呼叫中心？）是否已有通话记录？ | **P0** |\n| O-17 | 「拨打前准备」第 2 步「查风险：强关联命中→暂停拨打→先复核」——复核由谁来做？（风险人员？客服组长？）复核时长预期？ | P1 |\n| O-18 | 电话中「尽量确认」的字段（购买平台、订单号、产品型号、购买时间、问题类型、凭证）如果用户不愿意/无法提供——哪些是必须确认的？哪些可以跳过？ | P1 |\n 191|\n### 5.6 消息内容与合规（4 项）\n\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| O-19 | 消息内容是否需要审核？（IM 推送文案、EDM 邮件内容、APP Push——上线前是否需要审核？审核流程？） | P1 |\n| O-20 | EDM 合规要求——是否遵守 CAN-SPAM Act（美国）、GDPR（欧洲）、CASL（加拿大）？退订机制是否满足法律要求？ | P1 |\n| O-21 | IM 平台的合规限制——WhatsApp 等平台禁止垃圾消息和特定类型内容（如测评引导）——是否有合规风险？ | P1 |\n| O-22 | 消息发送的时区感知——美国用户、英国用户、德国用户的推送时间是否需要本地化？（用户当地时间的白天而非半夜） | P1 |\n\n### 5.7 消息策略与实验（3 项）\n\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| O-23 | 是否需要 A/B 测试能力？（同一计划的两组用户收到不同文案/不同发送时间——对比转化率？） | P2 |\n| O-24 | 消息打开率/点击率/转化率的追踪和报表？是否需要自动优化发送策略（高打开率的文案模板优先使用）？ | P2 |\n| O-25 | 用户反馈「消息太频繁/内容不相关」——是否有投诉/退订统计和预警？（投诉率超过 X% 暂停该类型推送？） | P1 |\n\n### 5.8 IM 通道补充（3 项）\n\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| O-26 | IM 消息的「已读」状态是否能获取？（WhatsApp 的蓝色双勾——能否用于判断用户是否看到消息？） | P1 |\n| O-27 | IM 用户提交的「评论截图/链接」——如何自动验证截图的真实性？（防止用户 PS 假截图？是否需要 OCR 识别截图内容？） | P1 |\n| O-28 | IM 中的返款通知——返款是系统自动触发还是人工触发？返款状态如何回写到 outreach？ | P1 |\n\n### 5.9 EDM 通道补充（3 项）\n\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| O-29 | EDM 的「硬退信」和「投诉」是否自动同步到 identity 的风险标记？（硬退信用户是否需要进入风险观察？） | P1 |\n| O-30 | EDM 引导用户下载 APP——是否在邮件中嵌入归因链接（deferred deep link）以追踪转化来源？ | P2 |\n| O-31 | EDM 的发送域名和 IP 预热策略？（新域名/IP 直接大批量发送会被 ESP 判定为垃圾邮件——需要渐进式预热？） | P2 |\n\n### 5.10 TEL 通道补充（3 项）\n\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| O-32 | 电话录音是否需要存储？存储多久？谁有权调取录音？（涉及合规和隐私） | P1 |\n| O-33 | 不同国家的电话合规要求——美国需提前告知录音、德国的 GDPR 限制——如何处理？ | P1 |\n| O-34 | TEL 任务的优先级和分配——多个外呼任务同时存在时，客服按什么顺序拨打？（先打高价值用户？先打答应配合超时的？） | P1 |\n\n### 5.11 实施层面（4 项）\n\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| O-35 | 各外部通道的 rate limit 和计费模式？（WhatsApp 按消息数计费？EDM 按发送量计费？）是否需要成本控制？ | P1 |\n| O-36 | 消息发送是同步还是异步？（用户点「发送」后立即返回还是后台队列处理？失败重试策略？） | P1 |\n| O-37 | 多渠道消息的发送顺序保证？（「先发 IM 提醒→24h 后无回复再发 EDM」——这种时序依赖如何实现？定时任务？延迟队列？） | P2 |\n| O-38 | 异常场景——如果某渠道 100% 发送失败（ESP 宕机/WhatsApp API 限流）——是否自动切换备用渠道？ | P2 |\n", + "wikilinks": [], + "category": "layer-requirements" + } + }, + { + "id": "doc:05_需求文档/05-子系统-客服工单与管理", + "type": "document", + "name": "子系统 05 — 客服工单与管理 (`support`) v1.0", + "filePath": "05_需求文档/05-子系统-客服工单与管理.md", + "summary": "子系统 05 — 客服工单与管理 support v1.0 2 子系统概述 4 维度 说明 代号 support 核心职责 工单生命周期管理、自动分配、答应配合状态机、排班出勤管理、绩效统计 数据所有权 support tickets , support followups , support assignment logs , attendance rec", + "tags": [ + "05_需求文档", + "需求文档" + ], + "complexity": "moderate", + "knowledgeMeta": { + "content": "# 子系统 05 — 客服工单与管理 (`support`) v1.0\n 2|\n## 子系统概述\n 4|\n| 维度 | 说明 |\n| --- | --- |\n| 代号 | `support` |\n| 核心职责 | 工单生命周期管理、自动分配、答应配合状态机、排班出勤管理、绩效统计 |\n| 数据所有权 | `support_tickets`, `support_followups`, `support_assignment_logs`, `attendance_records`, `shift_schedules`, `support_performance_snapshots` |\n| 启动依赖 | identity（软依赖，无上下文卡时可先跑工单） |\n| 外部系统依赖 | 无直接外部依赖（电话记录来自 outreach TEL 模块） |\n 12|\n---\n 14|\n## 1. 模块划分\n 16|\n```\n┌─────────────────────────────────────────────────────────────┐\n│ support 子系统 │\n│ │\n│ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │\n│ │ M1: 工单管理 │ │ M2: 自动分配 │ │ M3: 答应配合 │ │\n│ │ (Ticket) │→│ (Assign) │ │ 状态机 │ │\n│ └──────┬───────┘ └──────┬───────┘ └──────┬───────┘ │\n│ │ │ │ │\n│ ▼ ▼ ▼ │\n│ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │\n│ │ M4: 排班出勤 │ │ M5: 绩效统计 │ │ M6: 对外 API │ │\n│ │ 管理 │ │ │ │ Gateway │ │\n│ └──────────────┘ └──────────────┘ └──────────────┘ │\n│ │\n└─────────────────────────────────────────────────────────────┘\n```\n 34|\n| # | 模块 | 职责 |\n| --- | --- | --- |\n| M1 | 工单管理 | 工单创建、分类、状态流转（待分配→已分配→处理中→等待用户/等待内部→已解决/疑似诈骗→已关闭） |\n| M2 | 自动分配 | 按班次+在线状态+当前负载+最大工单数自动分配到客服组；组长再分派到组员 |\n| M3 | 答应配合状态机 | 独立的答应配合状态流转（已答应→待分配→待提醒→等待提交→已提交/超时→需再次联系→关闭） |\n| M4 | 排班出勤管理 | 排班设置、出勤记录（应出勤/实际出勤/迟到/早退/请假/缺勤）、在线客服池维护 |\n| M5 | 绩效统计 | 回复效率（回复用户数/处理工单数/首次回复时长分布）；转化统计（RSO回评/RDO测评登记订单数/获取评价数/完成率）；目标完成统计 |\n| M6 | 对外 API Gateway | 供其他子系统创建工单、查询工单状态、查询绩效数据 |\n 43|\n---\n 45|\n## 2. 各模块内外说明\n 47|\n### 2.1 M1: 工单管理\n 49|\n| 维度 | 说明 |\n| --- | --- |\n| **对内** | 5 种入口（用户消息进入/推送转人工/售后触发/风险触发/电话后续）；工单状态流转（待分配→已分配→处理中→等待用户/等待内部→已解决/疑似诈骗→已关闭）；5 种处理结果（等待用户回复/等待内部协同/答应配合/疑似诈骗/已解决） |\n| **对外接口** | `POST /api/tickets` — 创建工单；`PUT /api/tickets/{id}/status` — 更新状态 |\n| **数据写入** | `support_tickets` |\n| **依赖** | `GET /api/identity/context/{person_id}` — 展示用户上下文卡 |\n| **待确认** | 工单类型分类维度？（售后/催评/风险/其他？是否需要自定义分类？） |\n 57|\n### 2.2 M2: 自动分配\n 59|\n| 维度 | 说明 |\n| --- | --- |\n| **对内** | 分配算法（查班次+在线状态+当前负载+最大工单数→自动分配到客服组）；组长可在组内重新分派到具体组员；分配日志记录 |\n| **对外接口** | 内部服务 |\n| **数据写入** | `support_assignment_logs` |\n| **依赖** | M4 排班出勤数据 |\n| **待确认** | 「当前负载」按什么计算？（未关闭工单数？最近 N 小时处理量？两者加权？） |\n 67|\n### 2.3 M3: 答应配合状态机\n 69|\n| 维度 | 说明 |\n| --- | --- |\n| **对内** | 独立于工单状态的状态机（已答应配合→待分配负责人→待提醒→等待提交→已提交评价/已提交反馈→超时→需再次联系→已关闭）；防止承诺用户流失；超时提醒机制 |\n| **对外接口** | `POST /api/support/followups` — 创建跟进任务；`PUT /api/support/followups/{id}` — 更新状态 |\n| **数据写入** | `support_followups` |\n| **待确认** | 答应配合后多少天未提交算超时？超时后提醒频率？多次提醒无果后是否降级？ |\n 76|\n### 2.4 M4: 排班出勤管理\n 78|\n| 维度 | 说明 |\n| --- | --- |\n| **对内** | 排班设置（按日/周的班次安排）；出勤记录（应出勤/实际出勤/出勤率/迟到/早退/请假/缺勤）；在线客服池（排班+在线状态→可用客服列表） |\n| **对外接口** | `GET /api/support/available-agents` — 查询当前可用客服 |\n| **数据写入** | `attendance_records`, `shift_schedules` |\n| **待确认** | 排班是否对接外部 HR 系统还是独立管理？客服手动签入/签出？ |\n 85|\n### 2.5 M5: 绩效统计\n 87|\n| 维度 | 说明 |\n| --- | --- |\n| **对内** | 回复效率（回复用户数、处理工单数、发送消息数、首次回复时长：平均/中位数/最大/最小）；转化统计（RSO 回评登记订单数、RDO 测评登记订单数、获取评价数、评价完成率）；目标完成（月目标、当前完成、完成率、历史趋势）；主管看板 |\n| **对外接口** | `GET /api/support/stats?agent_id=&period=` — 绩效数据查询 |\n| **数据写入** | `support_performance_snapshots`（定时快照） |\n| **待确认** | 绩效统计周期（日/周/月？）主管看板是否需要实时数据还是 T+1 汇总？ |\n 94|\n---\n 96|\n## 3. 对外 API 契约（草案）\n 98|\n| 接口 | 方法 | 输入 | 输出 | 消费者 |\n| --- | --- | --- | --- | --- |\n| 创建工单 | `POST /api/tickets` | `{person_id, source, type, description}` | `{ticket_id}` | outreach（TEL→工单/EDM回复→工单）、risk（诈骗→工单） |\n| 工单详情 | `GET /api/tickets/{id}` | ticket_id | 完整工单+上下文卡 | 客服前端 |\n| 查询用户打开工单 | `GET /api/tickets?person_id=&status=open` | person_id | `[{ticket_id, status}]` | outreach（渠道去重）、quota（终校） |\n| 客服可用性 | `GET /api/support/available-agents` | 无 | `[{agent_id, current_load}]` | outreach（分配参考） |\n| 绩效查询 | `GET /api/support/stats?agent_id=&period=` | agent_id + 周期 | 绩效数据 | 客服管理前端 |\n 106|\n---\n 108|\n## 4. 数据对象\n 110|\n| 对象 | 核心字段 | 说明 |\n| --- | --- | --- |\n| `support_tickets` | ticket_id, person_id, source, type, status, assigned_agent, assigned_group, created_at, resolved_at | 工单主表 |\n| `support_followups` | followup_id, ticket_id, person_id, status(PROMISED/ASSIGNED/WAITING/SUBMITTED/TIMEOUT/RECONTACT/CLOSED), promised_at, deadline_at, reminded_at | 答应配合跟进 |\n| `support_assignment_logs` | log_id, ticket_id, from_agent, to_agent, reason, assigned_at | 工单分配日志 |\n| `attendance_records` | record_id, agent_id, date, status(PRESENT/LATE/EARLY/ABSENT/LEAVE), check_in, check_out | 出勤记录 |\n| `shift_schedules` | shift_id, agent_id, date, shift_type, start_time, end_time | 排班表 |\n| `support_performance_snapshots` | snapshot_id, agent_id, period, tickets_handled, messages_sent, avg_first_reply, rso_orders, rdo_orders, reviews_obtained, completion_rate | 绩效快照 |\n 119|\n---\n 121|\n## 5. 业务澄清问题清单 — support\n 123|\n### 5.1 工单管理（5 项）\n 125|\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| S-01 | 工单的来源分类有哪些？（IM 转人工 / 电话后续 / EDM 回复 / 用户主动联系 / 风险触发 / 其他？）每种来源的优先级是否不同？ | **P0** |\n| S-02 | 工单状态「等待用户」和「等待内部」的超时分别是多少？超时后谁来提醒？提醒方式（IM/系统通知）？ | **P0** |\n| S-03 | 三套并行状态（工单状态/答应配合状态/风险状态）的交互规则？例如：风险状态变为「确认诈骗」时工单是否自动关闭？（目前文档说是独立拆开的） | P1 |\n| S-04 | 工单关闭后是否允许重新打开？什么条件可重开？ | P1 |\n| S-05 | 工单是否有 SLA（服务级别协议）？不同来源/类型的工单 SLA 不同？ | P2 |\n 133|\n### 5.2 自动分配（4 项）\n 135|\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| S-06 | 「当前负载」如何精确计算？（未关闭工单数 × 权重？最近 N 小时处理量？工单类型权重不同？） | **P0** |\n| S-07 | 「最大工单数」是什么？（每个客服同时最多持有 X 个工单？）这个值是否统一还是按级别不同？ | **P0** |\n| S-08 | 在线状态如何判定？（手动签入/签出？系统自动检测活跃度？N 分钟无操作自动离线？） | P1 |\n| S-09 | 自动分配如果分配给了离线/满载的客服，兜底机制是什么？（自动转移给组长？放入公共池？） | P1 |\n 142|\n### 5.3 答应配合（3 项）\n 144|\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| S-10 | 答应配合后多少天未提交算超时？超时后的提醒频率？（第 1/3/7 天各提醒一次？）多次提醒无果后关闭还是降级？ | **P0** |\n| S-11 | 用户答应配合但最终提交了错误的 ASIN 评价——算不算配合完成？如何处理？ | P1 |\n| S-12 | 答应配合状态是否只针对客服工单场景？IM 直推中用户答应的算不算？ | P1 |\n 150|\n### 5.4 排班出勤（3 项）\n 152|\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| S-13 | 排班管理是否对接外部 HR 系统？还是独立在 support 子系统内管理？ | P1 |\n| S-14 | 菲律宾客服团队的工作制度？（班次类型：早班/中班/晚班？每班时长？每周几天？） | P1 |\n| S-15 | 出勤异常（迟到/早退/缺勤）是否需要自动通知主管？通知方式？ | P2 |\n 158|\n### 5.5 绩效统计（3 项）\n 160|\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| S-16 | 转化统计中 RSO（回评）和 RDO（测评）如何区分？（按工单来源？按关联计划类型？按客服标记？） | P1 |\n| S-17 | 「首次回复时长」从什么时候开始计时？（工单分配给客服的时间？用户消息到达时间？） | P1 |\n| S-18 | 评价完成率的分母是什么？（答应配合数？登记订单数？触达数？） | P2 |\n 166|\n### 5.6 多语言与国际化（3 项）\n\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| S-19 | 客服工作台需要支持哪些语言？（菲律宾客服用英语+Tagalog？面向用户的消息是否需要自动翻译？） | P1 |\n| S-20 | 用户消息的多语言处理——用户用德语/法语/西语发消息时，客服如何理解？（是否需要集成翻译工具？） | P2 |\n| S-21 | 系统管理界面（排班/绩效/设置）是否需要多语言？面向中国管理团队的是中文界面？ | P2 |\n\n### 5.7 知识库与话术（3 项）\n\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| S-22 | 是否需要集成知识库/FAQ？（客服在处理售后时快速查找产品信息、常见问题解答？） | P2 |\n| S-23 | 是否需要「快捷回复」功能？（预设常用回复模板——「请提供你的订单号」「我们将在 24h 内处理你的退款」等） | P1 |\n| S-24 | 快捷回复模板是否支持按场景/产品分类？（不同产品的售后话术不同——模板管理和权限？） | P2 |\n\n### 5.8 客服质量管控（4 项）\n\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| S-25 | 是否需要客户满意度（CSAT）调查？（工单关闭后推送满意度评分——评分方式？计入绩效？） | P2 |\n| S-26 | 是否需要质检功能？（组长抽查客服的对话记录进行评分——质检抽样比例？质检标准？） | P2 |\n| S-27 | 客服技能分组——不同客服擅长不同类型工单（售后/催评/风控）——是否需要基于技能的自动分配？ | P1 |\n| S-28 | 升级工单的处理流程——什么条件下工单升级到组长/负责人？（超时？用户投诉？疑似诈骗？） | P1 |\n\n### 5.9 排班与出勤补充（3 项）\n\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| S-29 | 排班是否支持轮班制？（周一到周日每天不同的班次安排）排班变更的通知方式？ | P1 |\n| S-30 | 临时调班/换班请求——客服之间是否可以自助换班？是否需要审批？ | P2 |\n| S-31 | 节假日/特殊日期的排班策略？（当地节假日——菲律宾假日 vs 美国假日 vs 中国假日——按哪国日历？） | P1 |\n\n### 5.10 绩效统计补充（3 项）\n\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| S-32 | 绩效考核周期？（日/周/月/季度？）绩效数据是否需要导出为报表？ | P1 |\n| S-33 | 绩效目标是否可自定义？（不同组的目标不同？新人目标低于老员工？）目标由谁设置？ | P1 |\n| S-34 | 绩效看板是否需要实时数据还是 T+1 汇总？（主管需要实时看到当前客服处理了多少工单？） | P2 |\n\n### 5.11 实施层面（3 项）\n\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| S-35 | 客服使用的 IM 工具——是独立于 outreach 的客服专用 IM 还是嵌入在客服工作台内的 Web IM？ | P1 |\n| S-36 | 工单数据是否需要与 outreach 的交互记录打通？（同一个用户在 IM 的聊天记录是否需要关联到工单？） | P1 |\n| S-37 | 客服工作台的实时性要求——新工单到达后多少秒内需要在客服界面显示？（WebSocket 推送 vs 轮询？） | P2 |\n", + "wikilinks": [], + "category": "layer-requirements" + } + }, + { + "id": "doc:05_需求文档/06-子系统-风险与反欺诈", + "type": "document", + "name": "子系统 06 — 风险与反欺诈 (`risk`) v1.0", + "filePath": "05_需求文档/06-子系统-风险与反欺诈.md", + "summary": "子系统 06 — 风险与反欺诈 risk v1.0 2 子系统概述 4 维度 说明 代号 risk 核心职责 强弱关联判断、黑名单实体管理、风险事件管理、双重退款检测 数据所有权 risk signals , risk cases , blacklist entities , refund match results 启动依赖 identity（软依赖） 外", + "tags": [ + "05_需求文档", + "需求文档" + ], + "complexity": "moderate", + "knowledgeMeta": { + "content": "# 子系统 06 — 风险与反欺诈 (`risk`) v1.0\n 2|\n## 子系统概述\n 4|\n| 维度 | 说明 |\n| --- | --- |\n| 代号 | `risk` |\n| 核心职责 | 强弱关联判断、黑名单实体管理、风险事件管理、双重退款检测 |\n| 数据所有权 | `risk_signals`, `risk_cases`, `blacklist_entities`, `refund_match_results` |\n| 启动依赖 | identity（软依赖） |\n| 外部系统依赖 | Amazon（退款数据）、财务系统（OA 返款数据） |\n 12|\n---\n 14|\n## 1. 模块划分\n 16|\n```\n┌─────────────────────────────────────────────────────────────┐\n│ risk 子系统 │\n│ │\n│ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │\n│ │ M1: 关联判断 │ │ M2: 黑名单 │ │ M3: 双重退款 │ │\n│ │ 引擎 │→│ 管理 │ │ 检测 │ │\n│ └──────┬───────┘ └──────┬───────┘ └──────┬───────┘ │\n│ │ │ │ │\n│ ▼ ▼ ▼ │\n│ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │\n│ │ M4: 风险事件 │ │ M5: 风险审核 │ │ M6: 对外 API │ │\n│ │ 管理 │ │ Admin │ │ Gateway │ │\n│ └──────────────┘ └──────────────┘ └──────────────┘ │\n│ │\n└─────────────────────────────────────────────────────────────┘\n```\n 34|\n| # | 模块 | 职责 |\n| --- | --- | --- |\n| M1 | 关联判断引擎 | 对每次风险信号做强弱关联判断（强：邮箱/设备/电话/地址/订单号/ProfileID/收款信息 命中→高风险；弱：IP单独/姓名单独/同址异名→观察+复核） |\n| M2 | 黑名单管理 | 黑名单实体管理（添加/移除/过期）、黑名单同步、命中查询 |\n| M3 | 双重退款检测 | Amazon 退款记录 vs OA 返款记录的自动比对，检测重复退款 |\n| M4 | 风险事件管理 | 风险事件创建、状态流转、关联工单/推送/计划状态回写 |\n| M5 | 风险审核 Admin | 人工复核弱关联风险、确认/排除诈骗、黑名单操作 |\n| M6 | 对外 API Gateway | 供所有子系统查询风险状态、上报风险信号 |\n 43|\n---\n 45|\n## 2. 各模块内外说明\n 47|\n### 2.1 M1: 关联判断引擎\n 49|\n| 维度 | 说明 |\n| --- | --- |\n| **对内** | 每次风险信号进入时执行：8 项强关联维度（邮箱/设备号/电话/收件人姓名+地址/订单号/聊天记录/Profile ID/收款信息）→任一命中→高风险；3 项弱关联维度（IP单独/姓名单独/同址异名）→高风险观察+人工复核；判断结果：强关联/弱关联/无关联 |\n| **对外接口** | `GET /api/risk/check/{person_id}` — 风险查询（含关联判断结果） |\n| **数据写入** | `risk_signals` |\n| **依赖** | `GET /api/identity/context/{person_id}` — 获取身份线索用于关联判断 |\n| **关键规则** | 风险判断不是一次性，每次有效互动都要重做；非 APP 用户缺设备/注册邮箱等维度→风险识别能力下降 |\n 57|\n### 2.2 M2: 黑名单管理\n 59|\n| 维度 | 说明 |\n| --- | --- |\n| **对内** | 黑名单实体 CRUD（邮箱/设备/电话/地址/收款信息）；黑名单命中查询（任何子系统查询用户是否在黑名单）；黑名单同步（确认诈骗后同步到黑名单）；黑名单过期/申诉机制 |\n| **对外接口** | `GET /api/risk/blacklist/check?type=EMAIL&value=xxx` — 黑名单命中检查 |\n| **数据写入** | `blacklist_entities` |\n| **待确认** | 黑名单是否有过期时间？申诉/移除流程？ |\n 66|\n### 2.3 M3: 双重退款检测\n 68|\n| 维度 | 说明 |\n| --- | --- |\n| **对内** | 采集 Amazon 退款记录（外部系统同步）+ OA 返款记录（财务系统同步）；按订单号/用户/金额/时间自动比对；匹配结果：无重复/疑似重复/确认重复；确认重复时强告警+阻止后续返款 |\n| **对外接口** | `GET /api/risk/double-refund-check/{person_id}` — 双重退款检测 |\n| **数据写入** | `refund_match_results` |\n| **依赖** | Amazon 退款数据（外部）、OA 返款数据（外部财务系统） |\n| **待确认** | Amazon 退款数据如何及时获取？OA 返款记录是否已有 API？ |\n 76|\n### 2.4 M4: 风险事件管理\n 78|\n| 维度 | 说明 |\n| --- | --- |\n| **对内** | 风险事件创建（客服上报疑似诈骗 / 双重退款检测 / 关联判断命中）；事件状态流转（待复核→复核中→确认风险/排除风险）；高风险链路动作（拦截继续推送/拦截自动退款/拦截自动放行）；回写关联工单/推送/计划状态 |\n| **对外接口** | `POST /api/risk/report` — 上报风险信号（客服、系统自动均可调用） |\n| **数据写入** | `risk_cases` |\n 84|\n### 2.5 M5: 风险审核 Admin\n 86|\n| 维度 | 说明 |\n| --- | --- |\n| **对内** | 人工复核弱关联风险；确认/排除诈骗判定；黑名单手动操作；风险口径维护 |\n| **对外接口** | 管理 API |\n| **待确认** | 复核时效要求？（N 分钟内必须复核？） |\n 92|\n---\n 94|\n## 3. 对外 API 契约（草案）\n 96|\n| 接口 | 方法 | 输入 | 输出 | 消费者 |\n| --- | --- | --- | --- | --- |\n| 风险查询 | `GET /api/risk/check/{person_id}` | person_id | `{risk_level(NONE/WEAK/STRONG), signals[], cases[]}` | 所有子系统（每次互动时调用） |\n| 上报风险信号 | `POST /api/risk/report` | `{person_id, signal_type, evidence, reported_by}` | `{signal_id}` | support（客服上报诈骗）、outreach（异常互动） |\n| 黑名单命中 | `GET /api/risk/blacklist/check?type=&value=` | 维度类型+值 | `{hit, entity}` | outreach（发送前）、identity（身份归并时） |\n| 双重退款检测 | `GET /api/risk/double-refund-check/{person_id}` | person_id | `{status, matched_refunds[]}` | outreach（返款前）、support（退款处理前） |\n 103|\n---\n 105|\n## 4. 数据对象\n 107|\n| 对象 | 核心字段 | 说明 |\n| --- | --- | --- |\n| `risk_signals` | signal_id, person_id, signal_type, hit_dimensions[], risk_level(STRONG/WEAK), detected_at | 风险信号（每次互动生成的判断） |\n| `risk_cases` | case_id, person_id, source, status(PENDING_REVIEW/REVIEWING/CONFIRMED_RISK/RULED_OUT), reviewer, created_at, resolved_at | 风险事件 |\n| `blacklist_entities` | entity_id, entity_type(EMAIL/DEVICE/PHONE/ADDRESS/PAYMENT), entity_value, status(ACTIVE/EXPIRED/APPEALED), added_at, added_by | 黑名单实体 |\n| `refund_match_results` | match_id, person_id, amazon_refund_id, oa_refund_id, match_status(NO_DUPLICATE/SUSPECTED/CONFIRMED), matched_at | 双重退款比对结果 |\n 114|\n---\n 116|\n## 5. 业务澄清问题清单 — risk\n 118|\n### 5.1 强弱关联规则（4 项）\n 120|\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| R-01 | 8 项强关联维度中，每个维度的命中是独立判断还是组合判断？（例如仅「设备号命中」是否就足够判定强关联？还是需要「设备号 + 电话」同时命中？） | **P0** |\n| R-02 | 「强关联→直接进入高风险或黑名单链路」——这里的「直接」是指全自动化拦截无需人工确认？还是系统先拦截再人工审核？（涉及自动化力度） | **P0** |\n| R-03 | 弱关联的「观察期」多长？观察期过后是自动解除还是必须人工确认？观察期内用户继续参与互动如何处理？ | P1 |\n| R-04 | 风险判断中「IP 单独命中」列为弱关联——IP 从哪里获取？（JOYHUB APP？EDM 邮件头？客服系统？）不同来源的 IP 可靠性不同 | P1 |\n 127|\n### 5.2 双重退款（4 项）\n 129|\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| R-05 | Amazon 退款数据如何获取？（SP-API 实时拉取？T+1 同步？手动导入 CSV？）同步频率决定检测时效 | **P0** |\n| R-06 | OA 返款系统是哪个？是否有 API？如果没有 API，返款记录怎么录入？（财务手动录入？CSV 导入？） | **P0** |\n| R-07 | 「双重退款」比对的关键字段是什么？（订单号？金额？用户？时间窗口？）匹配精度？（金额完全相等还是 ±X%？时间窗口多宽？） | P1 |\n| R-08 | 确认重复退款后，阻止后续返款——「阻止」是指系统自动拦截返款指令，还是只发告警让人工决定？ | P1 |\n 136|\n### 5.3 黑名单管理（3 项）\n 138|\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| R-09 | 黑名单是否有过期/申诉/解除机制？（例如用户被误标后如何申诉？谁有权解除？） | P1 |\n| R-10 | 黑名单是否需要与外部系统同步？（例如 JOYHUB 的黑名单？Amazon 的欺诈标记？）同步方向？ | P1 |\n| R-11 | 黑名单的粒度——是标记「真实人」还是「某个维度的值」？（标记的是真实人 ID 还是具体的邮箱/设备？） | P1 |\n 144|\n### 5.4 风险可见性（3 项）\n 146|\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| R-12 | 文档要求「客服、审核、退款等环节必须都能看到风险提醒」——风险提醒的展现形式是什么？（红色标签？弹窗？工单页顶部横幅？） | P1 |\n| R-13 | 风险状态的「提醒」通过什么通道发送？（audit 通知中心？IM 消息？系统内消息？） | P1 |\n| R-14 | 风险人员角色是否需要独立的风险控制台前端？该前端需要哪些功能？（事件列表/审核工作台/黑名单管理/统计报表？） | P2 |\n 152|\n### 5.5 高级风险检测能力（4 项）\n\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| R-15 | 是否需要行为速度检测？（同一真实人短时间内大量注册/大量申请退款/大量提交评价→触发异常行为告警？） | P1 |\n| R-16 | 是否需要设备指纹/浏览器指纹？（识别同一设备换账号、模拟器、虚拟机等欺诈行为？） | P2 |\n| R-17 | 是否需要地理位置异常检测？（同一账号短期内从不同国家/城市登录→触发告警？） | P2 |\n| R-18 | 风险评分模型——是否需要一个综合风险分数（0-100）而非二元判断（强/弱/无）？评分模型的因子和权重？ | P1 |\n\n### 5.6 风险事件处理流程（3 项）\n\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| R-19 | 风险事件的优先级（P0/P1/P2）如何定义？（双重退款确认→P0？单次弱关联→P2？）不同优先级的响应 SLA？ | P1 |\n| R-20 | 风险人员的工作台——是否需要「待审核队列」「审核中」「已处理」等看板视图？是否需要分配给具体审核人？ | P1 |\n| R-21 | 同一个人短时间内触发多次风险信号——是每次生成新事件还是合并到已有事件？合并规则？ | P1 |\n\n### 5.7 黑名单管理补充（3 项）\n\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| R-22 | 黑名单的生效范围——加入黑名单后是「全系统拦截」还是「只拦截某些操作」？（是否还允许正常购买？只拦截测评参与？） | P1 |\n| R-23 | 黑名单是否需要分级？（一级黑名单→全拦截 / 二级黑名单→降频+人工审核 / 三级黑名单→仅标记提醒） | P1 |\n| R-24 | 黑名单是否需要与外部欺诈数据库同步？（如行业共享的欺诈黑名单？Amazon 的 abuse 标记？） | P2 |\n\n### 5.8 非 APP 用户风险盲区（2 项）\n\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| R-25 | 文档已明确「非 APP 用户识别能力下降」——是否需要额外的风控措施？（例如非 APP 用户的返款额度降低？首次返款必须人工审核？） | P1 |\n| R-26 | 是否计划引导非 APP 用户注册 APP 以补全风险画像？（EDM/客服主动引导注册——注册转化跟踪？） | P2 |\n\n### 5.9 实施层面（3 项）\n\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| R-27 | 风险判断的实时性要求——每次互动时实时调用 risk API？（性能 overhead？需要缓存策略？） | P1 |\n| R-28 | 双重退款检测的时效——Amazon 退款数据（外部）同步延迟 vs OA 返款实时——T+N 的延迟是否可接受？ | P1 |\n| R-29 | 风险事件的数据保留策略？（已解决的诈骗案件数据保留多久？用于后续模型训练还是定期清理？） | P2 |\n", + "wikilinks": [], + "category": "layer-requirements" + } + }, + { + "id": "doc:05_需求文档/07-子系统-评价结果追踪", + "type": "document", + "name": "子系统 07 — 评价结果追踪 (`review`) v1.0", + "filePath": "05_需求文档/07-子系统-评价结果追踪.md", + "summary": "子系统 07 — 评价结果追踪 review v1.0 2 子系统概述 4 维度 说明 代号 review 核心职责 用户真实提交评价记录、Amazon 展示核验、ASIN 健康/计划完成度更新回流 数据所有权 review submission records , review display checks , review results 启动依赖 id", + "tags": [ + "05_需求文档", + "需求文档" + ], + "complexity": "moderate", + "knowledgeMeta": { + "content": "# 子系统 07 — 评价结果追踪 (`review`) v1.0\n 2|\n## 子系统概述\n 4|\n| 维度 | 说明 |\n| --- | --- |\n| 代号 | `review` |\n| 核心职责 | 用户真实提交评价记录、Amazon 展示核验、ASIN 健康/计划完成度更新回流 |\n| 数据所有权 | `review_submission_records`, `review_display_checks`, `review_results` |\n| 启动依赖 | identity / planning（软依赖） |\n| 外部系统依赖 | Amazon（评价展示状态、ASIN 评分数据） |\n 12|\n---\n 14|\n## 1. 模块划分\n 16|\n```\n┌─────────────────────────────────────────────────────────────┐\n│ review 子系统 │\n│ │\n│ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │\n│ │ M1: 评价提交 │ │ M2: 展示核验 │ │ M3: 结果回流 │ │\n│ │ 记录 │→│ │→│ 引擎 │ │\n│ └──────┬───────┘ └──────┬───────┘ └──────┬───────┘ │\n│ │ │ │ │\n│ ▼ ▼ ▼ │\n│ ┌──────────────┐ ┌──────────────┐ │\n│ │ M4: 异常观察 │ │ M5: 对外 API │ │\n│ │ 队列 │ │ Gateway │ │\n│ └──────────────┘ └──────────────┘ │\n│ │\n└─────────────────────────────────────────────────────────────┘\n```\n 34|\n| # | 模块 | 职责 |\n| --- | --- | --- |\n| M1 | 评价提交记录 | 记录用户真实提交评价的事实（提交时点、提交证据、关联计划、关联 ASIN） |\n| M2 | 展示核验 | 核查 Amazon 是否展示该评价 / 是否可核验 |\n| M3 | 结果回流引擎 | 将评价结果反馈给 planning（计划完成度）、identity（用户标签）、audit |\n| M4 | 异常观察队列 | 用户已提交但 Amazon 未展示 / 暂不可核验的评价，进入定期复查队列 |\n| M5 | 对外 API Gateway | 供 outreach、planning 查询评价进度、提交评价 |\n 42|\n---\n 44|\n## 2. 各模块内外说明\n 46|\n### 2.1 M1: 评价提交记录\n 48|\n| 维度 | 说明 |\n| --- | --- |\n| **对内** | 记录两个核心事实：①用户真实提交评价（时间、ASIN、评论内容/截图/链接、关联计划）；②提交后立即更新真实人累计评价额度（调用 quota 子系统 `commit`） |\n| **对外接口** | `POST /api/reviews/submission` — 记录评价提交 |\n| **数据写入** | `review_submission_records` |\n| **依赖** | `POST /api/quota/commit` — 确认额度占用（提交后立即计数12） |\n| **关键规则** | 「用户真实提交评价」和「Amazon 展示确认」是两个独立事实；额度计数按前者，计划完成按后者 |\n 56|\n### 2.2 M2: 展示核验\n 58|\n| 维度 | 说明 |\n| --- | --- |\n| **对内** | 核查 Amazon 是否展示该评价 / 是否可核验；核验方式（待确认：爬取 / 手动 / API / 截图？）；核验结果：①展示或可核验→计入计划完成 ②未展示/暂不可核验→保留已提交事实→进入异常观察 |\n| **对外接口** | `POST /api/reviews/verify` — 触发核验（或定时核验） |\n| **数据写入** | `review_display_checks` |\n| **依赖** | Amazon（评价展示数据） |\n| **待确认** | 核验是自动还是人工？核验频率？ |\n 66|\n### 2.3 M3: 结果回流引擎\n 68|\n| 维度 | 说明 |\n| --- | --- |\n| **对内** | 评价确认展示后：①通知 planning 更新计划完成度 ②通知 identity 更新用户标签（例如标记为「已回评用户」）③写入审计日志；免评结果回流：①更新 ASIN 健康与权重变化 ②更新计划完成度 ③通知 planning |\n| **对外接口** | 内部事件发布 |\n| **数据写入** | `review_results` |\n| **依赖** | `PUT /api/plans/{id}/status`（更新计划状态） |\n 75|\n### 2.4 M4: 异常观察队列\n 77|\n| 维度 | 说明 |\n| --- | --- |\n| **对内** | 用户已提交但 Amazon 未展示/暂不可核验的评价，进入异常观察队列；定期复查（例如每天查一次 Amazon 是否已展示）；超过观察期仍未展示→标记异常→通知运营 |\n| **数据写入** | `review_display_checks`（更新状态） |\n| **待确认** | 观察周期多长？复查频率？观察期满后如何处理？ |\n 83|\n---\n 85|\n## 3. 对外 API 契约（草案）\n 87|\n| 接口 | 方法 | 输入 | 输出 | 消费者 |\n| --- | --- | --- | --- | --- |\n| 记录评价提交 | `POST /api/reviews/submission` | `{person_id, asin, plan_id, evidence, submitted_at}` | `{submission_id, quota_updated}` | outreach（IM 核验后/客服确认后） |\n| 查询计划评价进度 | `GET /api/reviews/status/{plan_id}` | plan_id | `{total_submissions, verified, pending, completion_rate}` | planning |\n| 查询用户评价历史 | `GET /api/reviews/history/{person_id}` | person_id | `[{submission_id, asin, status, submitted_at}]` | identity（上下文卡） |\n| ASIN 评价统计 | `GET /api/reviews/asin-stats/{asin}` | asin | `{submission_count, verified_count, pending_count}` | planning |\n 94|\n---\n 96|\n## 4. 数据对象\n 98|\n| 对象 | 核心字段 | 说明 |\n| --- | --- | --- |\n| `review_submission_records` | submission_id, person_id, asin, plan_id, evidence_type, evidence, submitted_at, quota_updated | 评价提交记录（核心事实一） |\n| `review_display_checks` | check_id, submission_id, asin, check_method, check_result(DISPLAYED/NOT_DISPLAYED/UNVERIFIABLE), checked_at, retry_count, status(OBSERVING/CONFIRMED/ABNORMAL) | 展示核验记录（核心事实二） |\n| `review_results` | result_id, plan_id, asin, submission_count, verified_count, completion_rate, asin_health_change, updated_at | 评价结果汇总 |\n 104|\n---\n 106|\n## 5. 业务澄清问题清单 — review\n 108|\n### 5.1 评价提交记录（3 项）\n 110|\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| V-01 | 「用户真实提交评价」的证据形式是什么？（用户上传的截图？Amazon 评论链接？系统自动检测？）不同形式如何验证真伪？ | **P0** |\n| V-02 | 一个用户为同一个 ASIN 提交多条评价（如果 Amazon 允许）——每一条都独立计入累计12额度吗？ | **P0** |\n| V-03 | 评价提交记录是 outreach（IM/客服）写入还是用户直接提交？（系统内提交 vs 系统外提交的区别）系统外提交如何登记？ | P1 |\n 116|\n### 5.2 展示核验（4 项）\n 118|\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| V-04 | Amazon 评价展示的核验方式是？（定时爬取 Amazon 产品页？SP-API 拉取评价列表？用户上传截图人工审核？混合方式？） | **P0** |\n| V-05 | 如果通过爬取核验——爬取频率？（小时级？天级？）如何识别「哪条评价是本次计划用户提交的」？（靠评论者名字匹配？靠时间窗口？） | **P0** |\n| V-06 | 「暂不可核验」的常见原因有哪些？（Amazon 审核中/延迟展示/被 Amazon 删除？）每种原因的处理策略是否不同？ | P1 |\n| V-07 | 核验失败的兜底机制——如果 Amazon API 不可用或爬取失败，是否允许人工确认？ | P1 |\n 125|\n### 5.3 异常观察队列（2 项）\n 127|\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| V-08 | 异常观察队列的观察期多长？（1 天？7 天？30 天？）复查频率？（每天？每周？）观察期满后未展示→如何处理？ | P1 |\n| V-09 | 多少条评价进入异常观察算异常阈值？（单计划 10% 未展示→通知？单用户多次未展示→标记？） | P2 |\n 132|\n### 5.4 结果回流（3 项）\n 134|\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| V-10 | ASIN 健康「回流」的具体动作是什么？（更新 ASIN 评分/评价数到 planning？触发新一轮需求评估？更新 outreach 的触达策略？） | P1 |\n| V-11 | 计划完成度的计算方式——「评价确认展示」即算完成？还是需要确认展示 + 关联到本计划用户？（如何确保那条展示的评价确实是本计划用户的？） | P1 |\n| V-12 | 免评结果的「权重变化」如何量化？（Amazon 不直接提供权重数据——如何通过间接指标判断？） | P2 |\n 140|\n### 5.5 评价质量管理（4 项）\n\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| V-13 | 是否需要评价内容分析？（好评/中评/差评？评价字数？是否含图片/视频？——这些影响评价质量评分？） | P2 |\n| V-14 | 差评检测和响应——用户提交了差评（1-2 星）是否需要自动触发售后工单？（「差评补救」流程？） | P1 |\n| V-15 | 虚假评价检测——用户提交的评价是否可能被 Amazon 判定为虚假评价并删除？（系统是否需要内部质量评分来预测被删风险？） | P2 |\n| V-16 | 评价的 ASIN 匹配校验——用户声称对 ASIN A 提交了评价但实际是对 ASIN B 提交的——如何检测和处理？ | P1 |\n\n### 5.6 异常观察队列补充（3 项）\n\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| V-17 | 评价提交后 Amazon 展示的预期时间窗口？（通常 24-48h？最长多久？）超出预期窗口后的自动通知？ | P1 |\n| V-18 | Amazon 删除评价（违反社区准则）vs 用户删除评价 vs 评价被折叠——是否能区分？分别如何处理？ | P2 |\n| V-19 | 大量评价同时进入异常观察（例如 Amazon 评价系统故障导致全站延迟）——系统如何处理？（自动暂停观察队列？人工干预？） | P2 |\n\n### 5.7 ASIN 健康回流补充（3 项）\n\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| V-20 | ASIN 健康更新的频率？（每次评价确认展示就更新？每天汇总更新一次？） | P2 |\n| V-21 | 如果多人同时对同一 ASIN 提交了评价，是否对 ASIN 健康有复合影响？（例如 5 条 5 星好评 vs 1 条 1 星差评——权重不同） | P2 |\n| V-22 | ASIN 健康数据的来源——是 Amazon 直接提供的数据还是系统内部计算？（Amazon 评分 vs 系统追踪到的评价评分可能有差异） | P1 |\n\n### 5.8 实施层面（2 项）\n\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| V-23 | 评价展示核验如果是爬取 Amazon 页面——爬取频率和多 ASIN 并行爬取能力？（需要爬取几百个 ASIN 时的时间和资源开销） | P1 |\n| V-24 | 评价数据是否需要在系统间同步？（outreach 需要知道「用户已提交」→暂停触达；planning 需要知道「评价已确认」→更新计划完成度）数据一致性的保证？ | P1 |\n", + "wikilinks": [], + "category": "layer-requirements" + } + }, + { + "id": "doc:05_需求文档/08-子系统-KOC-KOL协作", + "type": "document", + "name": "子系统 08 — KOC/KOL 协作 (`creator`) v1.0", + "filePath": "05_需求文档/08-子系统-KOC-KOL协作.md", + "summary": "子系统 08 — KOC/KOL 协作 creator v1.0 2 子系统概述 4 维度 说明 代号 creator 核心职责 KOC/KOL 匹配筛选、内容 Brief/Code 分配、内容发布跟踪、带货结果跟踪、JOYCOLLAB 数据同步 数据所有权 exemption plan tasks , creator content records , c", + "tags": [ + "05_需求文档", + "需求文档" + ], + "complexity": "moderate", + "knowledgeMeta": { + "content": "# 子系统 08 — KOC/KOL 协作 (`creator`) v1.0\n 2|\n## 子系统概述\n 4|\n| 维度 | 说明 |\n| --- | --- |\n| 代号 | `creator` |\n| 核心职责 | KOC/KOL 匹配筛选、内容 Brief/Code 分配、内容发布跟踪、带货结果跟踪、JOYCOLLAB 数据同步 |\n| 数据所有权 | `exemption_plan_tasks`, `creator_content_records`, `creator_profiles`, `code_records` |\n| 启动依赖 | planning（软依赖，免评计划入口） |\n| 外部系统依赖 | JOYCOLLAB（KOC/KOL 数据、内容数据、Code 使用、带货订单） |\n 12|\n---\n 14|\n## 1. 模块划分\n 16|\n```\n┌─────────────────────────────────────────────────────────────┐\n│ creator 子系统 │\n│ │\n│ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │\n│ │ M1: KOC/KOL │ │ M2: 内容/Code│ │ M3: 结果跟踪 │ │\n│ │ 匹配筛选 │→│ 管理 │→│ │ │\n│ └──────┬───────┘ └──────┬───────┘ └──────┬───────┘ │\n│ │ │ │ │\n│ ▼ ▼ ▼ │\n│ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │\n│ │ M4: JOYCOLLAB│ │ M5: IM/EDM/ │ │ M6: 对外 API │ │\n│ │ 数据同步 │ │ APP 协同 │ │ Gateway │ │\n│ └──────────────┘ └──────────────┘ └──────────────┘ │\n│ │\n└─────────────────────────────────────────────────────────────┘\n```\n 34|\n| # | 模块 | 职责 |\n| --- | --- | --- |\n| M1 | KOC/KOL 匹配筛选 | 按国家/平台/粉丝量/产品类目/历史效果筛选匹配合作对象；检查合作对象风险（历史纠纷/违约） |\n| M2 | 内容/Code 管理 | 分配内容 Brief、分配 Code、管理 Code 使用量、素材管理 |\n| M3 | 结果跟踪 | 跟踪内容发布状态、点击/跳转数据、Code 使用量、带货订单、转化销量、权重变化 |\n| M4 | JOYCOLLAB 数据同步 | 从 JOYCOLLAB 拉取 KOC/KOL 数据、内容数据、Code 使用、带货订单；同步失败告警 |\n| M5 | IM/EDM/APP 协同 | KOC 内容二次分发、免评 Code 触达站内用户、活动引流、结果通知 |\n| M6 | 对外 API Gateway | 供 planning、outreach、review 查询 |\n 43|\n---\n 45|\n## 2. 各模块内外说明\n 47|\n### 2.1 M1: KOC/KOL 匹配筛选\n 49|\n| 维度 | 说明 |\n| --- | --- |\n| **对内** | 免评计划进入后：①按国家/平台/粉丝量/历史效果筛选 KOC/KOL ②按产品类目匹配专长 ③检查合作对象风险（历史纠纷/违约）→有风险记录时提示 |\n| **对外接口** | `GET /api/creators/match?plan_id=` — 获取匹配推荐列表 |\n| **数据写入** | `creator_profiles`（从 JOYCOLLAB 同步的 KOC/KOL 画像缓存） |\n| **待确认** | 匹配是完全自动推荐还是运营人工选择？推荐算法依赖哪些权重？ |\n 56|\n### 2.2 M2: 内容/Code 管理\n 58|\n| 维度 | 说明 |\n| --- | --- |\n| **对内** | 分配内容 Brief（产品信息/要求/素材/发布时间）；Code 分配（每个 KOC 独立 Code 还是一对多？）；Code 使用量监控 |\n| **对外接口** | `POST /api/creators/tasks` — 创建协作任务（含 Brief + Code） |\n| **数据写入** | `exemption_plan_tasks`, `code_records` |\n| **待确认** | Code 是 JOYCOLLAB 生成还是 USER 系统生成？Code 是优惠码还是追踪码？ |\n 65|\n### 2.3 M3: 结果跟踪\n 67|\n| 维度 | 说明 |\n| --- | --- |\n| **对内** | 跟踪 6 组结果：①内容发布状态/链接/互动数据 ②点击/跳转量 ③Code 使用量 ④带货订单数 ⑤转化销量 ⑥Listing 权重变化；执行评估：达标→结果回流 / 未达标→调整策略（更换KOC/调整素材/追加Code） |\n| **对外接口** | `GET /api/creators/results/{plan_id}` — 免评计划执行结果 |\n| **数据写入** | `creator_content_records` |\n| **依赖** | JOYCOLLAB 数据同步 |\n 74|\n### 2.4 M4: JOYCOLLAB 数据同步\n 76|\n| 维度 | 说明 |\n| --- | --- |\n| **对内** | 从 JOYCOLLAB 同步：KOC/KOL 画像数据、内容发布数据、Code 使用数据、带货订单数据；同步记录（时间/成功/失败）；同步失败告警 |\n| **对外接口** | 内部定时任务 |\n| **数据写入** | 本地缓存表（`creator_profiles`, `creator_content_records`） |\n| **待确认** | 同步方向是单向（COLLAB→USER）还是双向？同步频率？ |\n 83|\n### 2.5 M5: IM/EDM/APP 协同\n 85|\n| 维度 | 说明 |\n| --- | --- |\n| **对内** | 4 种协同动作：①KOC 内容二次分发（IM/APP 推送优质内容）②免评 Code 触达（IM/EDM 分发 Code 给站内用户）③活动引流（APP Push 引导用户进入 KOC 内容页）④结果通知（IM/APP 通知用户 Code 到账/订单确认） |\n| **对外接口** | 调用 outreach API：`POST /api/outreach/im/send` 等 |\n| **数据写入** | 协同记录 |\n 91|\n---\n 93|\n## 3. 对外 API 契约（草案）\n 95|\n| 接口 | 方法 | 输入 | 输出 | 消费者 |\n| --- | --- | --- | --- | --- |\n| KOC/KOL 匹配推荐 | `GET /api/creators/match?plan_id=` | plan_id | `[{creator_id, score, match_reason}]` | planner 前端 |\n| 创建协作任务 | `POST /api/creators/tasks` | `{creator_id, plan_id, brief, code, deadline}` | `{task_id}` | planner 前端 |\n| 免评执行结果 | `GET /api/creators/results/{plan_id}` | plan_id | `{content, clicks, codes, orders, sales, weight_change}` | review（结果回流）, planning |\n| KOC/KOL 画像查询 | `GET /api/creators/{creator_id}` | creator_id | KOC/KOL 完整画像 | planner 前端 |\n 102|\n---\n 104|\n## 4. 数据对象\n 106|\n| 对象 | 核心字段 | 说明 |\n| --- | --- | --- |\n| `exemption_plan_tasks` | task_id, plan_id, creator_id, brief, code, status, assigned_at, deadline | 免评计划协作任务 |\n| `creator_content_records` | record_id, task_id, creator_id, content_url, publish_time, engagement_data, synced_at | KOC 内容发布记录 |\n| `creator_profiles` | creator_id, name, platform, country, follower_count, category, historical_performance, risk_notes, synced_at | KOC/KOL 画像（从 JOYCOLLAB 同步的本地缓存） |\n| `code_records` | code_id, task_id, code_value, code_type, usage_count, usage_limit, status | Code 记录 |\n 113|\n---\n 115|\n## 5. 业务澄清问题清单 — creator\n 117|\n### 5.1 JOYCOLLAB 对接（4 项）\n 119|\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| K-01 | JOYCOLLAB 中 KOC/KOL 的完整数据字段有哪些？（平台/粉丝量/国家/类目/历史合作效果/历史纠纷/违约——文档部分列出，需确认完整字段清单和 API 可用性） | **P0** |\n| K-02 | 数据同步方向是单向（COLLAB→USER）还是双向？（USER 分配的 Brief/Code 是否需要回写到 COLLAB？） | **P0** |\n| K-03 | 同步频率？（实时 Webhook？每小时？每天？）同步失败时谁来处理？重试策略？ | P1 |\n| K-04 | JOYCOLLAB 是否有现成 API？是 REST API 还是需要开发新的同步接口？ | P1 |\n 126|\n### 5.2 KOC/KOL 匹配（3 项）\n 128|\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| K-05 | 匹配是运营人工选择还是系统自动推荐？推荐算法的权重？（粉丝量 vs 历史效果 vs 类目匹配 vs 报价？） | P1 |\n| K-06 | KOC/KOL 是否有评级/分层体系？（头部/腰部/尾部？）不同层级对应的计划类型是否不同？ | P1 |\n| K-07 | 「合作对象风险（历史纠纷/违约）」——风险数据从哪里来？（JOYCOLLAB？人工标记？）什么程度的风险需要拦截？ | P1 |\n 134|\n### 5.3 Code 与内容（3 项）\n 136|\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| K-08 | Code 是 JOYCOLLAB 生成还是 USER 系统生成？Code 类型？（优惠码/追踪码/专属链接？）一对一还是可以多人共用？ | P1 |\n| K-09 | KOC 发布的内容是否需要审核？（Brief 交付后→KOC 创作→审核→发布？）审核流程在哪个系统？ | P2 |\n| K-10 | KOC 内容二次分发到 IM/APP——分发策略是什么？（所有优质内容都分发？按产品/地区筛选？） | P2 |\n 142|\n### 5.4 财务结算（2 项）\n 144|\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| K-11 | KOC/KOL 的提成/返点结算在哪个系统执行？（JOYCOLLAB？财务系统？还是 USER 内触发结算指令？）USER 的责任边界？ | P1 |\n| K-12 | 结算数据（提成计算/返点核算/提款记录）是否需要同步到 USER？权限控制（财务数据独立权限）？ | P2 |\n 149|\n### 5.5 KOC/KOL 分层与定价（3 项）\n\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| K-13 | KOC/KOL 是否有分层体系？（头部/腰部/尾部——按粉丝量划分？按历史带货效果划分？）不同分层的合作价格和权益？ | P1 |\n| K-14 | KOC/KOL 的报价/定价数据是否在系统中维护？（用于预算计算和 ROI 分析？） | P2 |\n| K-15 | KOC/KOL 是否有签约/合同管理？排他性协议？（签约期内只能推广本品牌产品？）排他性信息是否需要系统记录？ | P2 |\n\n### 5.6 内容与权益管理（3 项）\n\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| K-16 | KOC/KOL 发布内容的使用权和授权期限？（品牌是否可以二次使用、广告投放、修改？授权条款在系统中管理还是走线下合同？） | P2 |\n| K-17 | 内容审核流程——KOC/KOL 创作的内容是否需要品牌方审核后才能发布？（审核不通过→修改→重新审核的流程？） | P1 |\n| K-18 | 内容效果评估——除了点击/Code/订单数据外，是否需要评估内容质量？（互动率、完播率、正向评论比例？） | P2 |\n\n### 5.7 多平台 KOC/KOL 管理（3 项）\n\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| K-19 | KOC/KOL 涉及哪些平台？（YouTube / TikTok / Instagram / Facebook / 博客 / Amazon 站内 Influencer Program？）每个平台的数据来源？ | P1 |\n| K-20 | 同一 KOC/KOL 在多个平台有账号——是否在系统中关联为同一个人？（类似 identity 的归并逻辑？） | P2 |\n| K-21 | 不同平台的内容格式和指标不同（YouTube 视频 vs Instagram 帖子 vs TikTok 短视频）——结果跟踪如何统一？ | P2 |\n\n### 5.8 Code 管理补充（2 项）\n\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| K-22 | Code 的类型？（一次性折扣码 / 多次使用码 / 追踪链接 / 专属落地页？）不同类型的生成和追踪逻辑？ | P1 |\n| K-23 | Code 的有效期管理？（计划结束后 Code 自动失效？还是保留一段时间？）Code 是否可重复使用？ | P1 |\n\n### 5.9 实施层面（3 项）\n\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| K-24 | JOYCOLLAB 数据同步失败时的降级策略？（用本地缓存数据？标记为「数据可能过期」？暂停新的协作任务？） | P1 |\n| K-25 | KOC/KOL 匹配算法的性能——如果 JOYCOLLAB 有几千个 KOC，匹配需要多少时间？是否有预筛选+精排的两阶段设计？ | P2 |\n| K-26 | KOC/KOL 的任务状态如何与 planning 的计划状态联动？（协作任务完成→计划完成度增加→计划状态更新？） | P1 |\n", + "wikilinks": [], + "category": "layer-requirements" + } + }, + { + "id": "doc:05_需求文档/09-子系统-审计与通知中心", + "type": "document", + "name": "子系统 09 — 审计与通知中心 (`audit`) v1.0", + "filePath": "05_需求文档/09-子系统-审计与通知中心.md", + "summary": "子系统 09 — 审计与通知中心 audit v1.0 2 子系统概述 4 维度 说明 代号 audit 核心职责 状态变更审计、敏感字段访问日志、多类型通知/告警 数据所有权 interaction audit logs , notification records , manual review tasks 启动依赖 无硬依赖，完全独立 外部系统依赖 通", + "tags": [ + "05_需求文档", + "需求文档" + ], + "complexity": "moderate", + "knowledgeMeta": { + "content": "# 子系统 09 — 审计与通知中心 (`audit`) v1.0\n 2|\n## 子系统概述\n 4|\n| 维度 | 说明 |\n| --- | --- |\n| 代号 | `audit` |\n| 核心职责 | 状态变更审计、敏感字段访问日志、多类型通知/告警 |\n| 数据所有权 | `interaction_audit_logs`, `notification_records`, `manual_review_tasks` |\n| 启动依赖 | 无硬依赖，完全独立 |\n| 外部系统依赖 | 通知可能通过 IM/EDM/APP Push 等通道（可复用 outreach 通道或独立） |\n 12|\n---\n 14|\n## 1. 模块划分\n 16|\n```\n┌─────────────────────────────────────────────────────────────┐\n│ audit 子系统 │\n│ │\n│ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │\n│ │ M1: 状态变更 │ │ M2: 敏感操作 │ │ M3: 通知分发 │ │\n│ │ 审计 │ │ 审计 │ │ 引擎 │ │\n│ └──────┬───────┘ └──────┬───────┘ └──────┬───────┘ │\n│ │ │ │ │\n│ ▼ ▼ ▼ │\n│ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │\n│ │ M4: 通知模板 │ │ M5: 人工复核 │ │ M6: 对外 API │ │\n│ │ 管理 │ │ 任务 │ │ Gateway │ │\n│ └──────────────┘ └──────────────┘ └──────────────┘ │\n│ │\n└─────────────────────────────────────────────────────────────┘\n```\n 34|\n| # | 模块 | 职责 |\n| --- | --- | --- |\n| M1 | 状态变更审计 | 记录所有业务对象的状态流转（对象ID/旧状态/新状态/操作人/时间/原因） |\n| M2 | 敏感操作审计 | 敏感字段访问记录、数据导出记录、人工复核操作留痕 |\n| M3 | 通知分发引擎 | 按通知类型路由到不同通道（系统内通知/IM/EDM/APP Push）；通知优先级管理 |\n| M4 | 通知模板管理 | 各类通知的模板（额度预警/Listing 预警/超时提醒/审批通知/风险告警） |\n| M5 | 人工复核任务 | 管理需要人工复核的任务（弱关联风险/额度预警池/异常评价），供风险/运营人员消费 |\n| M6 | 对外 API Gateway | 接收所有子系统上报的审计事件和通知请求 |\n 43|\n---\n 45|\n## 2. 各模块内外说明\n 47|\n### 2.1 M1: 状态变更审计\n 49|\n| 维度 | 说明 |\n| --- | --- |\n| **对内** | 接收所有子系统的状态变更事件（fire-and-forget）；记录：对象类型（plan/ticket/risk_case/review…）、对象ID、旧状态、新状态、操作人、操作时间、操作原因；审计日志不可篡改（append-only）；支持按对象ID/操作人/时间范围检索 |\n| **对外接口** | `POST /api/audit/event` — 上报审计事件 |\n| **数据写入** | `interaction_audit_logs` |\n| **典型事件** | 计划状态变更（草稿→审批→执行→完成）、工单分配/关闭、风险事件确认/排除、额度手动调整、审批决策 |\n 56|\n### 2.2 M2: 敏感操作审计\n 58|\n| 维度 | 说明 |\n| --- | --- |\n| **对内** | 三类敏感操作：①敏感字段访问（用户上下文卡中的涉密字段→记录访问人/时间/字段/上下文）②数据导出操作（导出人/时间/范围/原因/是否含敏感字段）③人工复核操作（决策人/决策内容/决策依据/时间） |\n| **对外接口** | `POST /api/audit/sensitive-access` — 上报敏感访问 |\n| **数据写入** | `interaction_audit_logs`（带 sensitivity 标记） |\n 64|\n### 2.3 M3: 通知分发引擎\n 66|\n| 维度 | 说明 |\n| --- | --- |\n| **对内** | 接收通知请求→按通知类型路由：①系统内通知（Web 前端轮询/WebSocket）②IM 通知（通过 outreach）③EDM 通知 ④APP Push；优先级管理（紧急 Listing 预警 > 超时提醒 > 额度预警）；通知去重（同一用户同一类型短时间内不重复发） |\n| **对外接口** | `POST /api/notifications/send` — 发送通知 |\n| **依赖** | outreach（IM/EDM/APP Push 通道） |\n 72|\n### 2.4 M4: 通知模板管理\n 74|\n| 维度 | 说明 |\n| --- | --- |\n| **对内** | 通知类型与模板：①额度预警（「真实人 X 的测评额度仅剩 1 次」）②紧急 Listing 预警（「ASIN X 评分接近 4.2，建议紧急催评」）③客服超时提醒（「工单 #123 已超时 N 小时未回复」）④审批通知（「计划 X 等待您的审批」）⑤规则风控提醒（「ASIN X 频控过高」）⑥风险告警（「用户 X 命中强关联风险」） |\n| **对外接口** | 管理 API |\n| **数据写入** | `notification_records` |\n| **待确认** | 模板是否需要多语言（中文/英文/菲律宾语）？模板管理界面在 audit 内部还是独立？ |\n 81|\n### 2.5 M5: 人工复核任务\n 83|\n| 维度 | 说明 |\n| --- | --- |\n| **对内** | 统一管理需人工复核的任务：弱关联风险复核、额度预警池复核、异常评价复核、诈骗疑似复核；任务分配/认领/完成/超时 |\n| **对外接口** | `POST /api/audit/review-task` — 创建复核任务；`GET /api/audit/review-tasks?assignee=` — 查询待复核任务 |\n| **数据写入** | `manual_review_tasks` |\n 89|\n---\n 91|\n## 3. 对外 API 契约（草案）\n 93|\n| 接口 | 方法 | 输入 | 输出 | 消费者 |\n| --- | --- | --- | --- | --- |\n| 上报审计事件 | `POST /api/audit/event` | `{object_type, object_id, old_status, new_status, operator, reason}` | `{event_id}` | 所有子系统（状态变更时调用） |\n| 上报敏感访问 | `POST /api/audit/sensitive-access` | `{operator, field, context, accessed_at}` | `{event_id}` | identity（上下文卡访问） |\n| 发送通知 | `POST /api/notifications/send` | `{recipient, type, template_id, params}` | `{notification_id}` | 所有子系统 |\n| 创建复核任务 | `POST /api/audit/review-task` | `{task_type, target_id, priority, description}` | `{task_id}` | risk, quota |\n 100|\n---\n 102|\n## 4. 数据对象\n 104|\n| 对象 | 核心字段 | 说明 |\n| --- | --- | --- |\n| `interaction_audit_logs` | log_id, object_type, object_id, old_status, new_status, operator, operation, reason, sensitivity_level, logged_at | 审计日志（append-only） |\n| `notification_records` | notification_id, recipient, type, template_id, channel, sent_at, status(SENT/DELIVERED/READ/FAILED) | 通知记录 |\n| `manual_review_tasks` | task_id, task_type, target_id, status(PENDING/ASSIGNED/IN_REVIEW/RESOLVED/TIMEOUT), assignee, priority, created_at, resolved_at | 人工复核任务 |\n 110|\n---\n 112|\n## 5. 业务澄清问题清单 — audit\n 114|\n### 5.1 审计范围与保留（4 项）\n 116|\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| A-01 | 审计日志的保留策略？（保留多久？1 年？永久？到期后归档还是删除？） | **P0** |\n| A-02 | 审计日志的存储量预估？（日产生多少条？是否需要分库分表/冷热分离？） | P1 |\n| A-03 | 审计日志是否需要支持导出/报表？（合规审计时需要导出给外部审计？） | P1 |\n| A-04 | 「敏感字段」的定义范围？（订单号、收款信息、设备号——还有哪些？谁来确定完整清单？） | **P0** |\n 123|\n### 5.2 通知策略（4 项）\n 125|\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| A-05 | 通知发送通道的优先级？（紧急告警用什么通道？IM？系统内通知？邮件？） | P1 |\n| A-06 | 通知去重规则？（同一用户同一类型通知 N 分钟内不重复发？） | P1 |\n| A-07 | 通知是否需要用户偏好设置？（用户可以选择不接收某类通知？公告类通知是否强制发送？） | P2 |\n| A-08 | 通知模板是否需要多语言支持？（中文/英文/菲律宾语？）模板由谁来维护？ | P2 |\n 132|\n### 5.3 人工复核任务（2 项）\n 134|\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| A-09 | 人工复核任务的时效要求？（不同任务类型 SLA？弱关联风险 N 小时内复核？额度预警池 N 分钟内复核？） | P1 |\n| A-10 | 复核任务超时后的升级机制？（自动分配给上级？通知主管？） | P2 |\n 139|\n### 5.4 与其他子系统的协作（2 项）\n 141|\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| A-11 | 通知通道是否完全复用 outreach？（IM/EDM/APP Push）还是 audit 独立对接通知通道？（如果 outreach 不可用，audit 仍需要能发告警） | P1 |\n| A-12 | 审计事件是同步上报还是异步？（同步→影响业务链路性能 / 异步→可能丢失事件） | P1 |\n 146|\n### 5.5 合规与认证（3 项）\n\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| A-13 | 系统是否需要通过合规认证？（SOC2 Type II / ISO 27001？）认证对审计日志的完整性、不可篡改性、保留期限有何具体要求？ | P1 |\n| A-14 | 数据导出请求（DSR）——用户或监管机构要求导出所有个人数据时，系统如何响应？（需要哪些子系统的数据？导出格式？响应时限？） | P1 |\n| A-15 | 审计日志是否需要对第三方审计开放？（外部审计师需要查看审计日志时——权限控制和数据脱敏？） | P2 |\n\n### 5.6 日志保留与归档（3 项）\n\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| A-16 | 审计日志的分级保留策略？（状态变更日志保留 X 年 / 敏感访问日志保留 Y 年 / 通知记录保留 Z 月？） | P1 |\n| A-17 | 日志归档方案？（超过保留期的日志是删除还是归档到冷存储？归档后是否仍可检索？） | P2 |\n| A-18 | 日志存储量预估？（日产生日志条数 × 保留天数 = 需要的存储空间——是否需要分库分表/分区？） | P2 |\n\n### 5.7 敏感数据脱敏（3 项）\n\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| A-19 | 审计日志中是否允许记录敏感字段的明文？（例如「谁在何时查看了用户 X 的收款信息」——收款信息是否脱敏存储？） | P1 |\n| A-20 | 日志查询权限——谁可以查审计日志？（管理员？审计员？）是否需要限制只能查自己相关的日志？ | P1 |\n| A-21 | 生产环境的日志是否可以包含 PII（个人可识别信息）？（邮箱/电话/地址——是否在写入日志时自动脱敏？） | P1 |\n\n### 5.8 通知可靠性（3 项）\n\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| A-22 | 通知的可靠性保证——紧急告警（如 Listing 评分暴跌）是否需要确保送达？（有送达确认机制吗？发送失败后重试？） | P1 |\n| A-23 | 通知通道的优先级切换——IM 通知失败后是否自动切换到 EDM 或系统通知？ | P2 |\n| A-24 | 通知的聚合/摘要——同一个用户短时间收到多条同类通知是否合并？（「您有 3 个待审批计划」而不是 3 条独立通知） | P2 |\n\n### 5.9 实施层面（4 项）\n\n| # | 问题 | 优先级 |\n| --- | --- | --- |\n| A-25 | 审计事件是同步写入还是异步写入？（同步→影响业务链路 RT / 异步→可能丢失事件——如何取舍？） | P1 |\n| A-26 | 审计日志的查询性能——是否需要支持全文搜索？（按操作人/对象ID/时间范围检索是否需要在秒级返回？） | P2 |\n| A-27 | 通知通道的可靠性——如果 audit 子系统本身宕机，其他子系统的通知请求是否丢失？（是否需要消息队列做缓冲？） | P1 |\n| A-28 | audit 子系统是否需要独立的数据库？（与其他子系统共享数据库会在高峰期互相影响——是否独立部署数据库？） | P2 |\n", + "wikilinks": [], + "category": "layer-requirements" + } + }, + { + "id": "doc:05_需求文档/20260504_USER后台ERP_MVP管理员首页高保真原型_v7", + "type": "document", + "name": "USER 后台 ERP MVP · 管理员总览原型 v7", + "filePath": "05_需求文档/20260504_USER后台ERP_MVP管理员首页高保真原型_v7.html", + "summary": "USER 后台 ERP MVP · 管理员总览原型 v7 U USER 后台 ERP MVP 一期 v7 · 模拟数据 待办提醒 21 重要事项 3 审核类 4 紧急 Listing 7 问题总结 9 经营总览 系统管理员 · 最高权限 · 全部部门 搜索 至 日 周 月 全部部门 Amazon 运营 用户运营 客服 系统管理员（最高权限） Amazon 运", + "tags": [ + "05_需求文档", + "需求文档" + ], + "complexity": "complex", + "knowledgeMeta": { + "content": "\n\n\n \n \n USER 后台 ERP MVP · 管理员总览原型 v7\n \n\n\n
\n \n\n
\n
\n
\n
\n 经营总览\n 系统管理员 · 最高权限 · 全部部门\n
\n
\n 搜索\n \n
\n
\n
\n
\n \n 至\n \n
\n
\n \n \n \n
\n \n \n \n
\n
\n\n
\n
\n
\n\n
\n \n\n
\n
\n
\n

操作确认

\n \n
\n
\n
\n
\n\n
\n\n \n\n\n", + "wikilinks": [], + "category": "layer-requirements" + } + }, + { + "id": "doc:05_需求文档/20260517_USER评价业务闭环_共用能力图与渠道专属流程_v2.2", + "type": "document", + "name": "USER 评价业务闭环 — 共用能力图与渠道专属流程 v2.2", + "filePath": "05_需求文档/20260517_USER评价业务闭环_共用能力图与渠道专属流程_v2.2.md", + "summary": "USER 评价业务闭环 — 共用能力图与渠道专属流程 v2.2 文件信息 文件名称： 20260517 USER评价业务闭环 共用能力图与渠道专属流程 v2.2.md 项目路径： C:\\XCODE\\USER 当前版本： v2.2 最近更新： 2026 05 17 上游基线： 工作基线 v1.2 20260517 USER评价业务闭环主流程与后续工作基线 v1", + "tags": [ + "05_需求文档", + "需求文档" + ], + "complexity": "complex", + "knowledgeMeta": { + "content": "# USER 评价业务闭环 — 共用能力图与渠道专属流程 v2.2\n\n## 文件信息\n\n- 文件名称：`20260517_USER评价业务闭环_共用能力图与渠道专属流程_v2.2.md`\n- 项目路径：`C:\\XCODE\\USER`\n- 当前版本：`v2.2`\n- 最近更新：`2026-05-17`\n- 上游基线：[工作基线 v1.2](20260517_USER评价业务闭环主流程与后续工作基线_v1.2.md)\n- 前一版本：\n - `20260517_USER评价业务闭环_共用能力图与渠道专属流程_v1.1.md`\n - `20260517_USER评价业务闭环点击操作模拟_v2.1.md`\n- 文件目的：在基线 v1.2 确认的额度规则和真实人体系上，拆出系统级共用能力图与 IM / EDM / APP / TEL / 客服 / KOC-KOL 六条渠道的专属执行流程，每个节点标注 查 / 写 / 状态 / 提醒 / 拦截。\n- 资料依据：IM 推送业务流脑图、电话业务流程知识库、客服相关模块、后台回评工作流对接事项、状态机 v4、页面设计 v4、原型 HTML。\n- 使用方式：先读基线 v1.2，再读本文件；第三步数据流设计直接引用本文件的节点规则表和数据对象建议。本文件取代 `v1.1` 与 `v2.1` 作为当前第二步主稿。\n\n---\n\n### 1. 总览\n\n```mermaid\nflowchart LR\n A[\"销售 / ASIN数据形成\"] --> B[\"需求触发\"]\n B --> C[\"用户运营评估\"]\n C --> D{\"计划类型\"}\n D --> E[\"评价型计划
推新 / 回评\"]\n D --> F[\"免评计划\"]\n E --> G[\"执行拆解\"]\n F --> G\n G --> SHARED[\"共用能力层\"]\n SHARED --> I1[\"IM\"]\n SHARED --> I2[\"EDM\"]\n SHARED --> I3[\"APP\"]\n SHARED --> I4[\"TEL\"]\n SHARED --> I5[\"客服\"]\n SHARED --> I6[\"KOC / KOL\"]\n I1 & I2 & I3 & I4 & I5 --> J[\"用户互动 / 服务 / 跟进\"]\n J --> K[\"用户真实提交评价\"]\n K --> L[\"计入累计评价额度（12）\"]\n L --> M[\"Amazon展示确认\"]\n M --> N[\"ASIN / 计划 / 用户 / 风险结果回流\"]\n I6 --> O[\"免评结果跟踪\"]\n O --> N\n N --> C\n\n style SHARED fill:#f5f5f5,stroke:#333,stroke-width:3px\n```\n\n#### 节点审查标准\n\n每个关键节点按以下 8 问审：\n\n| ## | 问题 | 标注 |\n| --- | --- | --- |\n| 1 | 入口是什么 | 触发条件 |\n| 2 | 先查什么 | **查** |\n| 3 | 判断什么 | 分岔条件 |\n| 4 | 写什么 | **写** |\n| 5 | 状态怎么变 | **状态** |\n| 6 | 何时提醒 | **提醒** |\n| 7 | 何时拦截 | **拦截** |\n| 8 | 何时转人工 | **转人工** |\n\n---\n\n## 第一部分：共用能力图\n\n### 2. 共用能力一：真实人识别与用户上下文卡\n\n#### 2.1 流程图\n\n```mermaid\nflowchart TB\n A[\"新互动 / 新订单 / 新任务\"] --> B[\"读取身份线索\"]\n B --> B1[\"JOYHUB ID\"]\n B --> B2[\"邮箱\"]\n B --> B3[\"电话\"]\n B --> B4[\"设备号\"]\n B --> B5[\"订单号\"]\n B --> B6[\"姓名 + 地址\"]\n\n B1 & B2 & B3 & B4 & B5 & B6 --> C[\"归并真实人\"]\n C --> D{\"匹配结果\"}\n D -->|\"标准化姓名+地址一致\"| E[\"强关联 → 同一真实人\"]\n D -->|\"地址一致姓名不同\"| F[\"家庭/关联风险 → 不直接合并\"]\n D -->|\"多线索交叉\"| G[\"按设备/电话/邮箱/收款信息权重合并\"]\n\n E & F & G --> H[\"生成 / 更新真实人 ID\"]\n H --> I[\"拉取用户上下文卡\"]\n\n I --> J[\"历史交易
订单/购买/退款/返款/ASIN\"]\n I --> K[\"历史服务
工单/聊天/电话/承诺/提醒\"]\n I --> L[\"历史风险
黑名单/诈骗/关联/异常\"]\n I --> M[\"当前设备
型号/版本/换机记录\"]\n I --> N[\"触达历史
IM/EDM/APP/TEL 近期记录\"]\n\n J & K & L & M & N --> O[\"上下文卡快照 → 供客服/运营/风险使用\"]\n```\n\n#### 2.2 用户上下文卡字段组\n\n| 字段组 | 具体内容 |\n| --- | --- |\n| 当前身份 | JOYHUB ID、邮箱、电话、当前订单、真实人 ID |\n| 真实人归并 | 姓名+地址（标准化）、设备号、电话、邮箱、Profile ID、收款信息、关联账号列表 |\n| 历史交易 | 历史订单、购买频次、最近购买、历史退款、历史返款、目标 ASIN 购买记录 |\n| 历史服务 | 历史工单、聊天记录、通话记录、已承诺事项、已发送提醒、工单关闭原因 |\n| 历史风险 | 黑名单标记、强关联记录、弱关联记录、疑似诈骗、双重退款、异常订单 |\n| 当前设备 | 设备号摘要、设备型号/类型、系统版本、APP 版本、最近设备变化（换机/多设备） |\n| 触达历史 | IM 最近触达/回复/退订、EDM 最近打开/点击/退订、APP 最近 Push、TEL 最近拨打 |\n\n#### 2.3 节点规则\n\n| 节点 | 查 | 写 | 状态 | 提醒 | 拦截 |\n| --- | --- | --- | --- | --- | --- |\n| 归并真实人 | JOYHUB、邮箱、电话、设备、订单、地址 | 真实人匹配结果、匹配证据、置信度 | 新真实人 / 已存在 | 标准化姓名+地址一致时强提示 | - |\n| 拉取上下文卡 | 交易、工单、风险、设备、触达全量记录 | 上下文快照（含快照时间） | 首次生成 / 增量更新 | 命中黑名单/异常时高亮 | 严重风险标记时阻止自动通过 |\n| 设备变化识别 | 设备号、型号、系统版本、APP版本 | 设备变化记录、变化时间 | 设备正常 / 近期换机 / 多设备 | 近期换机或同设备多账号提示 | - |\n\n---\n\n### 3. 共用能力二：人群生成与画像拆解\n\n#### 3.1 流程图\n\n```mermaid\nflowchart TB\n A[\"计划进入人群生成\"] --> B[\"基础过滤\"]\n B --> B1[\"硬排除：国家/站点/可达性/退订/黑名单/未关闭工单\"]\n\n B1 --> C[\"画像匹配\"]\n C --> C1[\"基础画像：国家/语言/性别/年龄段/注册时间\"]\n C --> C2[\"产品关系：绑定玩具/绑定数量/绑定品类/目标产品\"]\n C --> C3[\"交易画像：历史订单/购买频次/是否买过目标ASIN\"]\n C --> C4[\"行为画像：活跃度/打开率/点击率/历史回评率/配合率\"]\n C --> C5[\"触达画像：各渠道可达性/最近触达/退订\"]\n C --> C6[\"风险画像：黑名单/设备关联/地址关联/退款异常\"]\n C --> C7[\"计划画像：是否参加过推新/回评/免评/最近结果\"]\n\n C1 & C2 & C3 & C4 & C5 & C6 & C7 --> D[\"历史行为评分\"]\n\n D --> E[\"额度与频控校验
（进入 §4 共用能力三）\"]\n E --> F[\"风险复检
（进入 §6 共用能力五）\"]\n F --> G[\"生成候选人群快照 + 排除快照\"]\n```\n\n#### 3.2 画像字段的三类用途\n\n| 类型 | 作用 | 示例字段 |\n| --- | --- | --- |\n| **硬过滤** | 决定能不能进池 | 国家、可达性、黑名单、退订、未关闭工单、额度超限 |\n| **匹配条件** | 决定是否适合当前计划 | 绑定玩具、目标品类、年龄、性别、是否买过目标 ASIN |\n| **排序权重** | 决定触达优先级 | 活跃度、历史回评率、历史配合率、最近互动时间 |\n\n#### 3.3 节点规则\n\n| 节点 | 查 | 写 | 状态 | 提醒 | 拦截 |\n| --- | --- | --- | --- | --- | --- |\n| 基础过滤 | 国家、站点、可达性、退订、黑名单、未关闭工单 | 排除原因记录 | 入池 / 排除 | - | 黑名单/退订/强关联直接排除 |\n| 画像匹配 | 7 组画像字段 | 匹配分组与得分 | 匹配 / 不匹配 / 待补全 | 画像缺失可补全 | - |\n| 历史行为评分 | 活跃、点击、回复、回评率、配合率、投诉 | 评分结果、排序权重 | 高分 / 中分 / 低分 | 低活跃用户降级提醒 | - |\n| 生成快照 | 过滤、匹配、评分、额度、风险全量结果 | 人群快照、排除快照、快照时间 | 已生成 | 排除比例异常时提醒 | 快照为空时拦截 |\n\n---\n\n### 4. 共用能力三：额度台账与频控控制\n\n#### 4.1 已确认额度规则\n\n| 规则 | 统计对象 | 计数口径 | 计数时点 |\n| --- | --- | --- | --- |\n| 每月测评最多 4 次 | 真实人 | 已完成 + 进行中 + 已预占 | - |\n| 每月免评最多 4 次 | 真实人 | 已完成 + 进行中 + 已预占 | - |\n| 累计真实提交评价最多 12 个 | 真实人 | 用户真实提交评价后立即计数 | 用户真实提交评价时 |\n\n#### 4.2 流程图\n\n```mermaid\nflowchart TB\n A[\"识别真实人\"] --> B[\"读取额度台账\"]\n B --> B1[\"本月测评：已完成 / 进行中 / 已预占\"]\n B --> B2[\"本月免评：已完成 / 进行中 / 已预占\"]\n B --> B3[\"累计真实提交：当前 / 上限 12\"]\n B --> B4[\"并发占用：跨计划重复入选检测\"]\n\n B1 & B2 & B3 & B4 --> C{\"额度判断\"}\n C -->|\"剩余 ≥ 本次拟发送\"| D[\"进入普通候选池
→ 预占额度\"]\n C -->|\"剩余不足但 > 0\"| E[\"进入预警池
→ 预占额度 → 发送前人工复核\"]\n C -->|\"已用 + 预占 + 本次 ≥ 上限\"| F[\"排除自动推送\"]\n\n D --> G[\"写入预占记录\"]\n E --> G\n\n G --> H[\"频控复核\"]\n H --> H1[\"渠道频控：IM/EDM/APP/TEL 最近触达间隔\"]\n H --> H2[\"单 ASIN 短期触达次数\"]\n H --> H3[\"用户反感度/投诉/退订状态\"]\n\n H1 & H2 & H3 --> I{\"频控判断\"}\n I -->|通过| J[\"进入发送队列\"]\n I -->|不通过| K[\"延后 / 降频 / 排除\"]\n\n J --> L[\"发送前再次读取最新额度 + 风险\"]\n L --> M{\"最终校验\"}\n M -->|通过| N[\"发送\"]\n M -->|新增超限/风险| O[\"撤出本批次\"]\n```\n\n#### 4.3 额度 vs 频控的区别\n\n| 类别 | 统计维度 | 周期 | 拦截时机 |\n| --- | --- | --- | --- |\n| **渠道频控** | 单渠道触达次数/间隔 | 按日/周/月 | 发送前 |\n| **月度业务额度** | 真实人测评 4 / 免评 4 | 自然月 | 人群生成 + 发送前 |\n| **累计评价额度** | 真实人累计 12 | 永久累计 | 用户提交评价时更新、下次人群生成时判断 |\n| **并发占用控制** | 进行中 + 已预占 + 跨计划重复 | 实时 | 人群生成 + 预占时 |\n\n#### 4.4 节点规则\n\n| 节点 | 查 | 写 | 状态 | 提醒 | 拦截 |\n| --- | --- | --- | --- | --- | --- |\n| 读取额度台账 | 本月测评/免评、累计提交、进行中、已预占 | 当前额度快照 | - | 剩余 ≤ 1 或本批次将打满时预警 | - |\n| 预占额度 | 候选计划、预计发送量、当前剩余 | 额度预占记录 | 已预占 | - | 预计超限阻止进入自动发送 |\n| 频控复核 | IM/EDM/APP/TEL 最近触达、ASIN频次、退订/投诉 | 频控校验结果 | 通过 / 降频 / 排除 | 接近频控上限时提醒 | 超频直接排除 |\n| 发送前终校 | 最新额度、最新风险、最新未关闭工单 | 发送前校验结果 | 准入 / 撤出 | 任何新增异常立即提示 | 新增超限/风险撤出本批次 |\n\n---\n\n### 5. 共用能力四：每次有效互动复检\n\n#### 5.1 流程图\n\n```mermaid\nflowchart TB\n A[\"触发复检的事件\"] --> A1[\"主动推送后回复\"]\n A --> A2[\"再次联系\"]\n A --> A3[\"补充订单号\"]\n A --> A4[\"客服回访\"]\n A --> A5[\"电话来电\"]\n A --> A6[\"退款/返款/继续推送前\"]\n\n A1 & A2 & A3 & A4 & A5 & A6 --> X[\"重新读取四组数据\"]\n\n X --> X1[\"身份：真实人/JOYHUB/邮箱/电话/设备/订单/地址\"]\n X --> X2[\"历史：订单/工单/触达/退款/返款\"]\n X --> X3[\"额度：本月测评/免评/累计提交/进行中/预占\"]\n X --> X4[\"风险：黑名单/强弱关联/双重退款/异常订单\"]\n\n X1 & X2 & X3 & X4 --> Y{\"判断结果\"}\n Y -->|正常 + 额度充足| Z[\"继续业务\"]\n Y -->|弱风险 / 接近额度上限| W[\"继续但显著提示 → 人工关注\"]\n Y -->|强风险 / 额度超限| V[\"暂停当前动作 → 转风险中心或人工复核\"]\n```\n\n#### 5.2 节点规则\n\n| 节点 | 查 | 写 | 状态 | 提醒 | 拦截 |\n| --- | --- | --- | --- | --- | --- |\n| 身份复检 | JOYHUB、邮箱、电话、设备、订单、地址是否变化 | 身份变化记录 | 未变 / 新增关联 / 冲突 | 设备变化/地址变化提示 | - |\n| 历史复检 | 是否有新订单、新工单、新触达、新退款 | 历史变化记录 | 无变化 / 有更新 | 新退款/新工单提示 | - |\n| 额度复检 | 最新测评/免评/累计额度 | 最新额度快照 | 充足 / 预警 / 超限 | 接近上限预警 | 超限拦截 |\n| 风险复检 | 黑名单、强弱关联、双重退款、异常 | 最新风险结果 | 正常 / 弱风险 / 强风险 | 任何命中高亮提醒 | 强关联暂停自动操作 |\n\n---\n\n### 6. 共用能力五：风险判断与黑名单\n\n#### 6.1 风险分层\n\n| 风险类型 | 关联项 | 处理原则 |\n| --- | --- | --- |\n| **强关联** | 邮箱、设备号、电话、收件人姓名+地址、订单号、聊天记录、Profile ID、收款信息 | 一旦命中，直接进入高风险或黑名单链路 |\n| **弱关联** | IP 单独命中、姓名单独命中、同址异名 | 进入高风险观察 + 人工复核，不直接认定诈骗 |\n\n#### 6.2 流程图\n\n```mermaid\nflowchart TB\n A[\"风险信号进入
（新订单同步/触达回应/用户接入/退款申请/再次跟进）\"] --> B[\"强弱关联判断\"]\n\n B --> C{\"关联等级\"}\n C -->|强关联| D[\"高风险 / 黑名单链路\"]\n C -->|弱关联| E[\"高风险观察 + 人工复核\"]\n C -->|无关联| F[\"正常继续\"]\n\n D --> D1[\"拦截继续推送\"]\n D --> D2[\"拦截自动退款\"]\n D --> D3[\"拦截自动放行\"]\n D1 & D2 & D3 --> G[\"回写工单 / 推送 / 计划状态\"]\n G --> H[\"提醒客服 / 用户运营 / 审核人员\"]\n\n E --> E1[\"显著风险提醒\"]\n E1 --> E2[\"人工复核\"]\n E2 --> E3{\"复核结论\"}\n E3 -->|确认风险| D\n E3 -->|排除风险| F\n```\n\n#### 6.3 已确认业务问题\n\n1. **双重退款**：APP/OA 已退款 + 用户又向 Amazon 申请退款 → 需要 Amazon 退款与 OA 返款自动比对\n2. **高风险用户**：一旦标记，支付/返款需要人工复核\n3. **风险可见性**：客服、审核、退款等环节必须都能看到风险提醒\n4. **非 APP 用户盲区**：直接走邮件退款，缺设备/注册邮箱等维度，识别能力下降\n5. **每次互动重判**：风险判断不是一次性的，每次有效互动都要重新执行\n\n#### 6.4 节点规则\n\n| 节点 | 查 | 写 | 状态 | 提醒 | 拦截 |\n| --- | --- | --- | --- | --- | --- |\n| 强弱关联判断 | 邮箱/设备/电话/地址/订单/ProfileID/收款信息/IP | 关联结果、命中维度列表 | 强关联 / 弱关联 / 无 | 命中时高亮命中维度 | - |\n| 高风险链路 | 当前推送/退款/返款状态 | 风险事件、拦截记录 | 已拦截 / 待复核 | 通知所有关联环节 | 拦截继续推送/自动退款/自动放行 |\n| 双重退款检测 | Amazon退款记录 + OA返款记录 | 匹配结果、差异 | 无重复 / 疑似重复 / 确认重复 | 确认重复时强告警 | 确认重复时阻止后续返款 |\n\n---\n\n### 7. 共用能力六：审批工作流\n\n```mermaid\nflowchart LR\n PLAN[\"计划草案\"] --> R1{\"计划类型\"}\n R1 -->|测评计划| A1[\"Amazon运营总监审批\"]\n R1 -->|回评计划| A2[\"Amazon运营总监或指定负责人\"]\n R1 -->|免评计划| A3[\"Amazon运营总监 + 用户负责人\"]\n R1 -->|紧急计划| A4[\"Amazon运营负责人 + 用户负责人 + 主管\"]\n\n A1 & A2 & A3 & A4 --> NEXT[\"周/月推送计划\"]\n NEXT --> N1[\"用户负责人审批\"]\n N1 --> N2[\"渠道负责人审批\"]\n N2 --> APPROVED[\"已批准 → 执行\"]\n```\n\n#### 7.1 审批节点规则\n\n| 节点 | 查 | 写 | 状态 | 提醒 | 拦截 |\n| --- | --- | --- | --- | --- | --- |\n| Amazon运营总监审批 | 计划详情、ASIN健康、风险提醒 | 审批结果、审批意见 | 通过 / 驳回 / 待补充 | 驳回时通知提交人 | - |\n| 用户负责人审批 | 人群快照、额度占用、频控结果 | 审批结果 | 通过 / 驳回 | 额度接近上限时预警 | - |\n| 渠道负责人审批 | 渠道容量、素材、合规 | 审批结果 | 通过 / 驳回 | 素材/文案风险提醒 | 合规风险时拦截 |\n\n---\n\n### 8. 共用能力七：审计与通知中心\n\n| 模块 | 职责 | 关键记录内容 |\n| --- | --- | --- |\n| 状态变更审计 | 所有业务对象的状态流转留痕 | 对象ID、旧状态、新状态、操作人、时间、原因 |\n| 敏感字段访问 | 涉密字段的每次读取记录 | 访问人、访问时间、访问字段、访问上下文 |\n| 导出操作 | 所有数据导出行为留痕 | 导出人、时间、范围、原因、是否含敏感字段 |\n| 人工复核操作 | 所有人工干预决策留痕 | 决策人、决策内容、决策依据、决策时间 |\n| **规则风控提醒** | 触发规则/审核/风控阈值时通知 | 同一ASIN频控过高、同一用户多次推送、设备/邮箱异常、站点任务过密 |\n| **紧急Listing预警** | 评分接近4.2时通知 | ASIN、当前评分、差评摘要、建议动作 |\n| **客服超时提醒** | 工单/答应配合超时通知 | 工单ID、超时类型、超时时长、责任人 |\n| **额度预警** | 额度接近上限时通知 | 真实人、额度类型、已用/上限、受影响计划 |\n\n---\n\n## 第二部分：渠道专属流程图\n\n### 9. 渠道一：IM 推送专属流程\n\n#### 9.1 用户分层与推送策略\n\n```mermaid\nflowchart TB\n U[\"用户注册 + 绑定玩具\"] --> L1{\"识别用户分层\"}\n\n L1 -->|\"A 未参与过
从未走过回评/测评\"| A1[\"推送前校验\"]\n A1 --> A1a[\"查：JOYHUB ID、设备ID、黑名单、绑定产品\"]\n A1 --> A1b{\"设备ID在黑名单？\"}\n A1b -->|是| A2[\"写：打标'长期测评人'
拦截：不推回评/测评卡片
推送：免评产品卡片\"]\n A1b -->|否| A3[\"推送：对应绑定产品的回评卡片
写：推送记录\"]\n\n L1 -->|\"B 已参与过
真实人累计真实提交评价 < 12\"| B1[\"优先催评\"]\n B1 --> B1a[\"查：未回评测评单、真实人累计评价数、标签\"]\n B1 --> B1b[\"推送：催评卡片/消息\"]\n B1b --> B2{\"完成好评提交？\"}\n B2 -->|是| B3[\"写：重新计算真实人累计评价数\"]\n B3 --> B4{\"累计真实提交评价仍 < 12？\"}\n B4 -->|是| B5[\"推送：当日测评计划对应卡片
写：二次转化记录\"]\n B4 -->|否| B6[\"写：打标'长期测评人'→ 推送免评产品\"]\n\n L1 -->|\"C 长期测评人
真实人累计真实提交评价 ≥ 12\"| C1[\"拦截：不推送普通回评/测评卡片
推送：当日免评补单产品
写：免评推送记录\"]\n\n style A2 fill:#fce4ec\n style C1 fill:#fff3e0\n```\n\n#### 9.2 IM 用户提交后的核验与流转\n\n```mermaid\nflowchart TB\n SUBMIT[\"入口：用户在IM中提交回评/测评信息\"] --> ITEMS[\"提交内容：订单号 + 返款账号 + 评论截图/链接\"]\n\n ITEMS --> AUTO[\"查：当前用户标签、关联计划
写：系统自动登记提交记录
状态：待核验\"]\n\n AUTO --> VERIFY[\"订单号核实\"]\n VERIFY --> V1{\"查：是否测评单？\"}\n VERIFY --> V2{\"查：是否为公司产品？\"}\n VERIFY --> V3{\"查：单号格式 xxx-xxxxxxx-xxxxxxx？\"}\n\n V1 & V2 & V3 -->|全部通过| PASS[\"写：登记进系统
状态：已登记\"]\n V1 & V2 & V3 -->|任一不通过| CS[\"转人工：推送客服
状态：待客服处理\"]\n\n CS --> CS1[\"客服沟通用户 → 补充/修正信息\"]\n CS1 --> CS2[\"写：修正记录 → 回到核验\"]\n\n PASS --> CHECK{\"信息完整？\"}\n CHECK -->|完整| FINANCE[\"写：推送财务返款提醒
状态：待返款\"]\n CHECK -->|缺返款账号| TAG1[\"写：打标'xx产品待返款'
提醒：自动通知用户补充
状态：信息待补全\"]\n CHECK -->|缺评论截图/链接| TAG2[\"写：打标'xx产品待回评'
提醒：自动通知用户补充
状态：信息待补全\"]\n\n FINANCE --> PAY[\"查：付款凭证
写：自动推送返款/礼品卡通知
状态：已返款\"]\n PAY --> DONE[\"状态：回评流程走完\"]\n DONE --> TAG3[\"写：打标'xx产品已回评用户'
推送：测评卡片（二次转化）\"]\n\n style SUBMIT fill:#e8f5e9\n style PASS fill:#c8e6c9\n style CS fill:#fff3e0\n style DONE fill:#e3f2fd\n```\n\n#### 9.3 IM 新测评流程\n\n```mermaid\nflowchart TB\n START[\"入口：用户收到测评卡片 → 提交测评信息\"] --> VFY[\"查：订单号是否撤销、是否退款
查：真实人月度测评额度与累计真实提交评价\"]\n\n VFY -->|\"额度允许 + 订单有效\"| REG[\"写：登记进系统
写：打标'xx产品测评单登记'
状态：已登记\"]\n\n REG --> INFO{\"信息完整？\"}\n INFO -->|只有订单号
缺返款账号+截图| TAG_A[\"写：打标'xx产品测评待返款'
提醒：自动通知用户
状态：待补全\"]\n INFO -->|只有截图+链接
缺订单号+返款账号| TAG_B[\"写：打标'xx产品测评单待回评'
提醒：自动通知用户
状态：待补全\"]\n INFO -->|完整| COMP[\"状态：测评流程走完\"]\n\n COMP --> RECALC[\"查：重新计算 review 数量
写：review 数量更新\"]\n RECALC -->|\"累计真实提交评价 ≥ 12\"| LC[\"写：打标'长期测评人'
推送：免评产品卡片\"]\n RECALC -->|\"≤ 12 review\"| NEXT[\"推送：当日测评计划对应卡片
写：二次转化记录\"]\n\n style COMP fill:#c8e6c9\n style LC fill:#fff3e0\n```\n\n#### 9.4 IM 核心标签汇总\n\n| 分类 | 标签 | 触发时机 | 后续动作 |\n| --- | --- | --- | --- |\n| **用户层级** | 未参与过用户 (A) | 注册+绑定后首次识别 | 推送回评卡片 |\n| | 参与过用户 (B) | 已有回评/测评记录，review < 12 | 优先催评 → 二次转化 |\n| | 长期测评人 (C) | review > 12 | 仅推送免评产品 |\n| **回评流程** | xx产品已回评用户 | 回评流程走完 | 推送测评卡片 |\n| | xx产品待回评用户 | 缺截图/链接 | 自动通知补全 |\n| | xx产品待返款 | 缺返款账号 | 自动通知补全 |\n| **测评流程** | xx产品测评单登记 | 订单核实通过 | 继续信息补全 |\n| | xx产品测评待返款用户 | 测评缺返款 | 自动通知补全 |\n| | xx产品测评单待回评 | 测评缺截图 | 自动通知补全 |\n| | xx产品测评单 | 测评流程走完 | review重算 |\n| **免评流程** | xx产品的免评 | 长期测评人参与免评单 | 不再推回评/测评 |\n\n#### 9.5 IM 推送动作与流转动作\n\n| 动作类型 | 动作 | 说明 |\n| --- | --- | --- |\n| **推送** | 回评卡片 | A类用户首次推送 |\n| | 测评卡片 | B类二次转化 / A类设备在黑名单 |\n| | 免评产品卡片 | C类用户 / 黑名单命中用户 |\n| | 催评消息 | B类优先催评 / 紧急催评 |\n| | 返款/礼品卡通知 | 财务有凭证后推送 |\n| **流转** | 推送客服 | 订单号不符合 / 异常 |\n| | 推送财务 | 订单登记完成后 |\n| | 自动打标 | 各流程节点完成时 |\n| | 二次转化 | 回评完成 → 推送测评卡片 |\n\n---\n\n### 10. 渠道二：EDM 邮件推送专属流程\n\n#### 10.1 流程图\n\n```mermaid\nflowchart TB\n START[\"入口：计划已批准，进入EDM执行拆解\"] --> POOL[\"筛选EDM目标用户池\"]\n\n POOL --> COND{\"查：用户条件\"}\n COND -->|\"非APP用户\"| NON[\"进入EDM队列\"]\n COND -->|\"APP低活跃\"| LOW[\"查：IM频控通过后进入EDM队列\"]\n COND -->|\"APP活跃\"| SKIP[\"拦截：跳过EDM，走IM/APP\"]\n\n NON --> PRECHK[\"推送前检查\"]\n LOW --> PRECHK\n\n PRECHK --> C1[\"查：身份——是否有有效邮箱\"]\n PRECHK --> C2[\"查：风险——邮箱是否命中黑名单\"]\n PRECHK --> C3[\"查：退订——是否已退订/硬退信\"]\n PRECHK --> C4[\"查：资格——OA是否有资格\"]\n PRECHK --> C5[\"查：国家——站点与邮箱类型匹配\"]\n\n C1 & C2 & C3 & C4 & C5 -->|全部通过| BEHAVIOR[\"行为筛选\"]\n C1 & C2 & C3 & C4 & C5 -->|任一不通过| EXCLUDE[\"写：排除原因
拦截：不发送\"]\n\n BEHAVIOR --> B1[\"查：最近打开时间、总打开次数\"]\n BEHAVIOR --> B2[\"查：最近3/5次是否连续0打开\"]\n BEHAVIOR --> B3[\"查：最近回复时间、回复后又发送数\"]\n BEHAVIOR --> B4[\"查：是否点击评论链接但未回复\"]\n BEHAVIOR --> B5[\"查：单月收信次数、各邮件类型发送次数\"]\n\n B1 & B2 & B3 & B4 & B5 --> RHYTHM{\"节奏判断\"}\n RHYTHM -->|适合触达| SEND[\"发送EDM
写：发送记录
状态：已发送\"]\n RHYTHM -->|需降频| DELAY[\"写：延后标记
状态：观察中\"]\n RHYTHM -->|不适合| SWITCH[\"切换其他渠道或排除\"]\n\n SEND --> TRACK[\"追踪回收\"]\n TRACK --> T1[\"送达 → 写：送达时间\"]\n T1 --> T2[\"打开 → 写：打开时间、打开次数+1\"]\n T2 --> T3[\"点击 → 写：点击时间、点击目标\"]\n T3 --> T4[\"跳转至APP下载页/产品页\"]\n T4 --> RESULT{\"用户行为\"}\n RESULT -->|\"下载并注册APP\"| TO_IM[\"写：用户渠道升级
后续走IM主流程\"]\n RESULT -->|\"直接回复邮件\"| TO_CS[\"写：生成客服工单
走客服执行流程\"]\n RESULT -->|\"未响应\"| RETRY[\"写：进入再触达队列
（遵循频控间隔）\"]\n RESULT -->|\"退订\"| UNSUB[\"写：退订标记
拦截：该渠道永久排除\"]\n\n SEND --> METRICS[\"写：EDM指标
发送数/送达率/打开率/点击率/回复率/转化数/退订数\"]\n\n style EXCLUDE fill:#fce4ec\n style UNSUB fill:#fce4ec\n style TO_IM fill:#e3f2fd\n style TO_CS fill:#fff3e0\n```\n\n#### 10.2 EDM 专属行为指标\n\n| 字段组 | 具体指标 | 用途 |\n| --- | --- | --- |\n| **打开行为** | 最近打开时间、总打开次数、最近3/5次0打开 | 判断活跃度 → 决定是否继续发 |\n| **回复行为** | 最近回复时间、回复后又发送封数 | 判断兴趣度 → 决定触达节奏 |\n| **点击行为** | 是否点击评论链接、点击后未回复时长 | 判断意向 → 决定是否追加触达 |\n| **触达频率** | 单月收信次数、各邮件类型发送次数 | 频控 → 防止疲劳 |\n| **邮件属性** | 邮件类型、邮箱后缀标签、国家站点 | 匹配 → 确定发送内容 |\n| **排除项** | 风险用户、黑名单、退订、硬退信、OA无资格 | 硬过滤 → 不进池 |\n\n#### 10.3 EDM vs IM 关键差异\n\n| 维度 | IM | EDM |\n| --- | --- | --- |\n| 用户身份强度 | 强（JOYHUB ID + 设备 + 订单绑定） | 弱（仅邮箱，可能无JOYHUB ID） |\n| 风险识别能力 | 高（多维度交叉） | 低（缺设备/注册邮箱等维度） |\n| 转化路径 | 直接提交 → 核验 → 返款 | 引导注册APP → 再进入IM链路 |\n| 退订机制 | 社区屏蔽/消息免打扰 | 邮件退订链接 + 硬退信 |\n| 频控周期 | 按日/按类目 | 按周/按月 |\n| 行为信号 | 绑定/活跃/点击/回复/标签 | 打开/点击/回复/退订/连续0打开 |\n\n---\n\n### 11. 渠道三：APP Push 专属流程\n\n#### 11.1 流程图\n\n```mermaid\nflowchart TB\n START[\"触发源\"] --> T1[\"用户绑定新玩具\"]\n START --> T2[\"用户长期未活跃（7天+）\"]\n START --> T3[\"测评/回评计划到期\"]\n START --> T4[\"Listing健康紧急\"]\n START --> T5[\"活动/促销通知\"]\n\n T1 & T2 & T3 & T4 & T5 --> FILTER[\"查：共用能力过滤\"]\n\n FILTER --> F1[\"查：身份——JOYHUB ID + 设备在线\"]\n FILTER --> F2[\"查：风险——黑名单 + 关联检测\"]\n FILTER --> F3[\"查：频控——当日Push次数 + 用户通知设置\"]\n FILTER --> F4[\"查：标签——匹配推送策略\"]\n\n F1 & F2 & F3 & F4 -->|通过| PUSH[\"发送APP Push
写：推送记录
状态：已发送\"]\n F1 & F2 & F3 & F4 -->|不通过| SKIP[\"写：跳过原因
状态：已跳过\"]\n\n PUSH --> USER{\"用户响应\"}\n USER -->|\"点击打开\"| IN_APP[\"进入APP → 落地页\"]\n USER -->|\"忽略/关闭\"| NOOP[\"写：曝光记录
拦截：短期内不重复推\"]\n USER -->|\"卸载/禁用通知\"| UNINSTALL[\"写：不可再推送标记
降级：转入EDM候选池\"]\n\n IN_APP --> ACT{\"APP内动作\"}\n ACT -->|\"提交回评/测评\"| IM_FLOW[\"走IM提交核验流程（§9.2）\"]\n ACT -->|\"联系客服\"| CS_FLOW[\"生成客服工单（§12）\"]\n ACT -->|\"仅浏览\"| TAG[\"写：记录行为，更新活跃标签\"]\n\n style IN_APP fill:#e3f2fd\n style UNINSTALL fill:#fce4ec\n```\n\n#### 11.2 APP Push 与 IM 的分工\n\n| 场景 | 用 APP Push | 用 IM |\n| --- | --- | --- |\n| 新绑定玩具 → 引导测评 | - | 推送回评/测评卡片 |\n| 用户7天未活跃 | 推送召回通知 | - |\n| 测评计划到期提醒 | - | 推送催评消息 |\n| Listing 紧急 | 推送紧急通知 | 推送紧急催评卡片 |\n| 返款已到账 | 推送到账通知 | - |\n| 活动/促销 | 推送活动通知 | - |\n\n#### 11.3 APP 必查字段\n\n| 字段组 | 内容 |\n| --- | --- |\n| 用户资料 | 注册邮箱、JOYHUB ID、国家、语言 |\n| 设备上下文 | 设备号、设备型号/类型、APP版本、系统版本 |\n| 产品关系 | 绑定玩具、绑定时间、目标产品关系 |\n| 行为数据 | 活跃、打开、点击、回复、站内浏览、广告互动 |\n\n---\n\n### 12. 渠道四：TEL 电话专属流程\n\n#### 12.1 流程图\n\n```mermaid\nflowchart TB\n START[\"触发电话任务\"] --> S1[\"用户答应配合但超时未提交\"]\n START --> S2[\"高价值用户需深度跟进\"]\n START --> S3[\"复杂售后无法文字解决\"]\n START --> S4[\"IM/EDM多次触达无响应\"]\n START --> S5[\"紧急Listing需人工沟通\"]\n START --> S6[\"Amazon页面/说明书来电\"]\n START --> S7[\"计划生成的外呼任务\"]\n\n S1 & S2 & S3 & S4 & S5 & S6 & S7 --> TICKET[\"写：生成电话类客服工单
状态：待分配\"]\n\n TICKET --> PREPARE[\"拨打前准备（必须）\"]\n PREPARE --> P1[\"查：用户完整画像
（身份/订单/历史/标签/风险）\"]\n PREPARE --> P2[\"查：风险状态
拦截：强关联命中 → 暂停拨打 → 先复核\"]\n PREPARE --> P3[\"查：历史沟通记录
（避免重复询问）\"]\n PREPARE --> P4[\"写：准备话术和问题清单\"]\n\n P1 & P2 & P3 & P4 --> CONTACT[\"客服电话联系用户
写：拨打记录
状态：处理中\"]\n\n CONTACT --> RESULT{\"通话结果\"}\n RESULT -->|\"接通-售后问题\"| AFTERSALE[\"先解决售后
查：订单/产品/凭证
写：处理方案
状态：售后处理中\"]\n RESULT -->|\"接通-直接配合\"| COOP[\"确认评价提交时间
写：登记答应配合
状态：答应配合\"]\n RESULT -->|\"接通-拒绝\"| REJECT[\"写：记录拒绝原因
状态：已关闭\"]\n RESULT -->|\"接通-疑似诈骗\"| FRAUD[\"创建诈骗事件
写：诈骗记录
转风险链路（§6）\"]\n RESULT -->|\"未接通\"| RETRY[\"写：拨打次数+1
提醒：安排重试\"]\n\n AFTERSALE --> SAT{\"是否解决/满意？\"}\n SAT -->|是| INVITE[\"引导回评/邀请测评\"]\n SAT -->|否| ESCALATE[\"升级处理 → 转组长/负责人\"]\n\n INVITE --> FOLLOW[\"写：进入答应配合跟进
状态：待提醒\"]\n COOP --> FOLLOW\n FOLLOW --> UPDATE[\"写：更新工单 + 用户标签\"]\n\n RETRY --> DECIDE{\"重试策略\"}\n DECIDE -->|\"< 3次\"| CONTACT\n DECIDE -->|\"≥ 3次未接通\"| DOWNGRADE[\"写：降级至EDM/放弃
状态：待关闭\"]\n\n CONTACT --> RECORD[\"写：通话记录
来电时间/来源/联系方式/订单号
问题类型/描述/处理方案
是否解决/是否邀请测评/用户是否接受\"]\n\n style CONTACT fill:#fff3e0,stroke:#ef6c00\n style FRAUD fill:#fce4ec,stroke:#c62828\n style AFTERSALE fill:#e3f2fd\n```\n\n#### 12.2 TEL 必填记录字段\n\n| 类别 | 字段 | 涉密 |\n| --- | --- | --- |\n| 来电基础 | 来电时间、来源（Amazon页/说明书/外呼）、客服、联系方式 | - |\n| 订单信息 | Amazon订单号、产品型号/款式/颜色、购买时间 | 订单号涉密 |\n| 问题信息 | 问题类型、问题描述、图片/视频凭证 | - |\n| 处理信息 | 处理方案、是否解决、是否需要后续跟进 | - |\n| 评价相关 | 是否邀请回评/测评、用户是否接受、是否涉及差评 | - |\n| 拨打统计 | 拨打次数、通话时长、接通状态 | - |\n\n---\n\n### 13. 渠道五：客服工单执行流程\n\n#### 13.1 流程图\n\n```mermaid\nflowchart TB\n A[\"入口：用户消息 / 推送转人工 / 电话后续 / 风险触发\"] --> B[\"写：生成工单
状态：待分配\"]\n\n B --> C[\"查：班次、在线状态、当前负载、最大工单数
写：自动分配到客服组
状态：已分配\"]\n\n C --> D[\"客服组长分派到组员
状态：处理中\"]\n\n D --> E[\"查：展示用户上下文卡
（身份/历史/风险/设备/触达）\"]\n\n E --> F[\"客服开始处理\"]\n\n F --> G{\"处理结果\"}\n G -->|\"等待用户回复\"| H[\"状态：等待用户
提醒：超时提醒机制\"]\n G -->|\"等待内部协同\"| I[\"状态：等待内部
提醒：超时升级\"]\n G -->|\"用户答应配合\"| J[\"写：生成跟进任务
状态：答应配合
进入答应配合状态机\"]\n G -->|\"疑似诈骗\"| K[\"写：诈骗疑似标记
提醒：组长/负责人复核
转风险链路（§6）\"]\n G -->|\"问题已解决\"| L[\"写：解决记录
状态：已解决\"]\n\n H --> F\n I --> F\n\n J --> M[\"提醒/再联系/等待提交\"]\n M --> N[\"用户提交评价或反馈
状态：已提交评价/已提交反馈\"]\n\n K --> P[\"组长/负责人复核\"]\n P --> Q{\"复核结论\"}\n Q -->|确认诈骗| R[\"转风险链路 → 同步黑名单\"]\n Q -->|退回继续处理| F\n\n L --> S[\"写：关闭工单
状态：已关闭\"]\n```\n\n#### 13.2 三套并行状态\n\n| 状态体系 | 典型状态 | 说明 |\n| --- | --- | --- |\n| **工单状态** | 待分配 → 已分配 → 处理中 → 等待用户/等待内部 → 已解决 / 疑似诈骗 → 已关闭 | 工单生命周期 |\n| **答应配合状态** | 已答应配合 → 待分配负责人 → 待提醒 → 等待提交 → 已提交评价/已提交反馈 → 超时 → 需再次联系 → 已关闭 | 防止承诺用户流失 |\n| **风险状态** | 无异常 → 弱关联高风险 → 强关联高风险 → 疑似诈骗 → 已确认诈骗 → 已同步黑名单 | 风险独立跟踪 |\n\n---\n\n### 14. 客服管理支撑流程\n\n#### 14.1 流程图\n\n```mermaid\nflowchart LR\n A[\"排班设置\"] --> B[\"在线客服池\"]\n C[\"出勤记录\"] --> B\n B --> D[\"工单自动分配
查：在线状态/排班/当前负载/最大工单数\"]\n D --> E[\"回复效率统计\"]\n D --> F[\"转化统计\"]\n F --> G[\"目标完成统计\"]\n E --> H[\"主管看板\"]\n F --> H\n G --> H\n```\n\n#### 14.2 管理指标\n\n| 模块 | 指标 |\n| --- | --- |\n| **出勤** | 应出勤、实际出勤、出勤率、迟到、早退、请假、缺勤 |\n| **回复效率** | 回复用户数、处理工单数、发送消息数、首次回复时长（平均/中位数/最大/最小） |\n| **转化** | RSO回评登记订单数、RDO测评登记订单数、获取评价数、评价完成率 |\n| **目标** | 月目标、当前完成、完成率、历史趋势 |\n\n---\n\n### 15. 评价完成流程\n\n#### 15.1 流程图\n\n```mermaid\nflowchart TB\n A[\"用户提交评价\"] --> B[\"写：记录真实提交事实
状态：已提交待核验\"]\n B --> C[\"写：更新真实人累计评价额度（+1）
提醒：接近12时预警\"]\n\n C --> D{\"查：Amazon是否展示 / 是否可核验\"}\n D -->|\"展示或可核验\"| E[\"写：计入计划完成
状态：已确认展示\"]\n D -->|\"未展示 / 暂不可核验\"| F[\"写：保留已提交事实
状态：未展示待观察\"]\n\n E --> G[\"写：更新ASIN健康与计划完成度\"]\n F --> H[\"进入异常观察队列
提醒：定期复查\"]\n\n G --> I[\"结果回流：更新经营层数据\"]\n```\n\n#### 15.2 必须拆开的两个事实\n\n| 事实 | 是否计入累计12额度 | 是否计入计划完成 | 计数时点 |\n| --- | --- | --- | --- |\n| 用户真实提交评价 | **是** | 还不一定 | 提交时立即计数 |\n| Amazon 展示确认 | 已在上一步计过 | **是** | 展示确认时 |\n\n---\n\n### 16. 渠道六：KOC/KOL 协作专属流程（免评核心通道）\n\n#### 16.1 流程图\n\n```mermaid\nflowchart TB\n START[\"入口：免评计划 / 推新计划已批准\"] --> PLAN[\"查：计划参数
写：拆解KOC/KOL执行方案\"]\n\n PLAN --> STEP1[\"匹配合作对象\"]\n STEP1 --> S1A[\"查：按国家/平台/粉丝量/历史效果筛选\"]\n STEP1 --> S1B[\"查：按产品类目匹配KOC/KOL专长\"]\n STEP1 --> S1C[\"查：合作对象风险（历史纠纷/违约）
提醒：有风险记录时提示\"]\n\n S1A & S1B & S1C --> STEP2[\"写：分配Code/素材/内容Brief\"]\n STEP2 --> STEP3[\"KOC/KOL内容发布\"]\n\n STEP3 --> TRACK[\"跟踪执行结果\"]\n TRACK --> T1[\"查：内容发布链接\"]\n TRACK --> T2[\"查：点击/跳转数据\"]\n TRACK --> T3[\"查：Code使用量\"]\n TRACK --> T4[\"查：带货订单\"]\n TRACK --> T5[\"查：转化销量\"]\n TRACK --> T6[\"查：Listing权重变化\"]\n\n T1 & T2 & T3 & T4 & T5 & T6 --> SYNC[\"从JOYCOLLAB同步数据至USER
写：同步记录
提醒：同步失败时告警\"]\n\n SYNC --> EVAL{\"执行评估\"}\n EVAL -->|\"达标\"| DONE[\"写：结果回流
更新ASIN健康/计划完成度
状态：已完成\"]\n EVAL -->|\"未达标\"| ADJUST[\"调整策略
写：调整记录
更换KOC/调整素材/追加Code\"]\n\n SYNC --> FINANCE[\"财务侧
查：提成计算/返点核算/提款记录
提醒：财务数据独立权限\"]\n```\n\n#### 16.2 KOC/KOL 与评价型渠道的本质差异\n\n| 维度 | 评价型（IM/EDM/APP/TEL） | KOC/KOL |\n| --- | --- | --- |\n| 执行主体 | 系统 + 客服 | 外部KOC/KOL + 运营协同 |\n| 终点 | 用户提交评价 | 内容发布/Code使用/带货销量/权重 |\n| 用户关系 | 平台 ↔ 买家 | 品牌 ↔ 达人 ↔ 达人粉丝 |\n| 数据源 | USER系统内部 | JOYCOLLAB同步 |\n| 财务 | 返款（固定金额） | 提成+返点（按效果） |\n| 风险关注 | 诈骗/双重退款 | 合作纠纷/违约/虚假流量 |\n\n#### 16.3 IM/EDM/APP 在免评中的协同角色\n\n| 协同动作 | 渠道 | 说明 |\n| --- | --- | --- |\n| KOC内容二次分发 | IM/APP | 将KOC发布的优质内容推送给站内用户 |\n| 免评Code触达 | IM/EDM | 将免评Code分发给符合条件的站内用户 |\n| 活动引流 | APP Push | 推送活动通知引导用户进入KOC内容页 |\n| 结果通知 | IM/APP | 通知用户Code到账、订单确认 |\n\n#### 16.4 免评核心结果组\n\n| 结果组 | 跟踪内容 |\n| --- | --- |\n| 内容 | 发布状态、链接、发布时间、互动数据 |\n| 引流 | 点击量、跳转量、Code使用量 |\n| 成交 | 订单数、转化量、销量 |\n| 经营 | 权重变化、ASIN健康变化、品牌搜索变化 |\n\n---\n\n### 17. 店铺紧急催评流程（IM渠道专属子流程）\n\n```mermaid\nflowchart TB\n TRIGGER[\"触发条件
查：店铺当日掉评/差评/需紧急拿好评稳评分
状态：紧急触发\"] --> CALC[\"计算推送量
目标好评数 ÷ 2% = 需触达用户数
写：推送方案\"]\n\n CALC --> EXEC[\"执行\"]\n EXEC --> E1[\"查：筛选可触达用户
写：推送紧急催评消息\"]\n EXEC --> E2[\"查：优先触达高完成率用户\"]\n EXEC --> E3[\"查：持续跟踪回评提交状态\"]\n\n E1 & E2 & E3 --> RESULT{\"结果\"}\n RESULT -->|\"已提交好评\"| R1[\"写：更新已回评/测评完成
状态：已完成\"]\n RESULT -->|\"未提交\"| R2[\"写：保留在待催评池
状态：待催评\"]\n RESULT -->|\"异常\"| R3[\"转人工：推送客服跟进
状态：转客服\"]\n\n style TRIGGER fill:#fce4ec,stroke:#c62828\n```\n\n---\n\n## 第三部分：渠道交叉与协同规则\n\n### 18. 渠道优先级路由\n\n```mermaid\nflowchart LR\n USER_IN[\"同一个用户\"] --> D1{\"查：用户状态\"}\n D1 -->|\"APP注册 + 活跃 + 已绑定\"| IM[\"IM 优先\"]\n D1 -->|\"APP注册 + 低活跃\"| APP_PUSH[\"APP Push优先 + IM补充\"]\n D1 -->|\"未注册APP\"| EDM[\"EDM优先 → 引导注册后转IM\"]\n D1 -->|\"高价值 + 多次无响应\"| TEL[\"TEL人工\"]\n D1 -->|\"长期测评人（C类）\"| IM_FREE[\"IM免评卡片 + KOC/KOL协同\"]\n\n style IM fill:#e3f2fd\n style EDM fill:#fff3e0\n style TEL fill:#fce4ec\n```\n\n### 19. 渠道间去重规则\n\n| 规则 | 说明 |\n| --- | --- |\n| 同一计划同一用户 | 不重复通过多渠道路由，优先走最高优先级渠道 |\n| 用户已在客服工单中 | 暂停自动触达，等待工单关闭后再判断 |\n| 用户已提交评价（待核验） | 所有渠道暂停催评，等待核验结果 |\n| 用户已退订某渠道 | 该渠道永久排除，不影响其他渠道 |\n| 用户命中强关联风险 | **所有渠道暂停自动触达**，进入人工复核 |\n| 用户命中弱关联风险 | 降频 + 提示后继续，但需人工关注 |\n\n### 20. 用户状态 × 渠道可用性矩阵\n\n| 用户状态 | IM | EDM | APP Push | TEL | KOC/KOL |\n| --- | --- | --- | --- | --- | --- |\n| APP活跃 + 已绑定 | **首选** | 不送 | 补充 | - | - |\n| APP活跃 + 未绑定 | 引导绑定 | - | 活动通知 | - | - |\n| APP低活跃 | 降频 | 补充 | **召回** | - | - |\n| 未注册APP | - | **首选** | - | 高价值时 | - |\n| 已答应配合 | 提醒 | - | 到期提醒 | **超时拨打** | - |\n| 长期测评人 (C) | **仅免评** | - | - | - | 可协同 |\n| 黑名单/强关联 | **全暂停** | **全暂停** | **全暂停** | **需复核** | **暂停** |\n| 弱关联风险 | 降频+提示 | 降频+提示 | 降频+提示 | 提示后执行 | 提示 |\n| 累计接近12 | 预警+人工 | 预警+人工 | 预警+人工 | 可正常服务；涉及普通测评邀请时需人工复核 | - |\n| 累计已满12 | 仅免评 | 仅免评 | 仅免评 | 可正常服务；不得绕过普通测评限制 | 可协同 |\n\n---\n\n## 第四部分：第三步数据对象建议\n\n### 21. 第三步建议优先产出的数据对象\n\n| 优先级 | 对象 | 来源能力/渠道 |\n| --- | --- | --- |\n| **P0** | `person_profiles`（真实人） | §2 真实人识别 |\n| **P0** | `person_identity_links`（身份关联） | §2 真实人识别 |\n| **P0** | `contact_context_snapshots`（用户上下文快照） | §2 用户上下文卡 |\n| **P0** | `person_quota_ledgers`（额度台账） | §4 额度台账 |\n| **P0** | `quota_reservations`（额度预占） | §4 额度台账 |\n| **P0** | `risk_signals`（风险信号） | §6 风险判断 |\n| **P0** | `risk_cases`（风险事件） | §6 风险判断 |\n| **P0** | `blacklist_entities`（黑名单实体） | §6 风险判断 |\n| **P0** | `audience_snapshots`（人群快照） | §3 人群生成 |\n| **P0** | `audience_exclusions`（人群排除记录） | §3 人群生成 |\n| **P0** | `channel_route_decisions`（渠道路由决策） | §18 渠道优先级 |\n| **P0** | `channel_dedup_records`（渠道去重记录） | §19 渠道间去重 |\n| **P1** | `im_interaction_records`（IM交互记录） | §9 IM |\n| **P1** | `im_flow_tags`（IM流程标签） | §9 IM |\n| **P1** | `edm_message_events`（EDM事件） | §10 EDM |\n| **P1** | `edm_user_behavior_profiles`（EDM用户行为画像） | §10 EDM |\n| **P1** | `app_touch_events`（APP触达事件） | §11 APP |\n| **P1** | `tel_call_records`（TEL通话记录） | §12 TEL |\n| **P1** | `support_tickets`（客服工单） | §13 客服 |\n| **P1** | `support_followups`（答应配合跟进） | §13 客服 |\n| **P1** | `support_assignment_logs`（工单分配日志） | §13 客服 |\n| **P1** | `review_submission_records`（评价提交记录） | §15 评价完成 |\n| **P1** | `review_display_checks`（评价展示核验） | §15 评价完成 |\n| **P1** | `exemption_plan_tasks`（免评计划任务） | §16 KOC/KOL |\n| **P1** | `creator_content_records`（KOC内容记录） | §16 KOC/KOL |\n| **P1** | `amazon_refund_records`（Amazon退款记录） | §6 双重退款 |\n| **P1** | `oa_refund_records`（OA返款记录） | §6 双重退款 |\n| **P1** | `refund_match_results`（退款比对结果） | §6 双重退款 |\n| **P2** | `attendance_records`（出勤记录） | §14 客服管理 |\n| **P2** | `shift_schedules`（排班表） | §14 客服管理 |\n| **P2** | `support_goal_records`（客服目标） | §14 客服管理 |\n| **P2** | `support_performance_snapshots`（绩效快照） | §14 客服管理 |\n| **P2** | `interaction_audit_logs`（互动审计日志） | §8 审计 |\n| **P2** | `manual_review_tasks`（人工复核任务） | §5/§6 复检与风险 |\n\n---\n\n### 22. 与基线 v1.2 的关系\n\n本文件是基线 v1.2 的下游细化产物：\n\n| 基线 v1.2 章节 | 本文件对应 |\n| --- | --- |\n| §6.1 主动触达支线 | §9 IM、§10 EDM、§11 APP Push |\n| §6.2 免评执行支线 | §16 KOC/KOL + §16.3 协同角色 |\n| §6.3 被动售后与TEL支线 | §12 TEL |\n| §6.4 风险/诈骗拦截支线 | §6 风险判断与黑名单 |\n| §6.5 客服工单与客服管理支线 | §13 客服工单、§14 客服管理 |\n| §7 真实人识别、用户上下文与额度规则 | §2 真实人识别、§4 额度台账 |\n| §8 渠道专属补充事实 | §9-§16 各渠道专属流程 |\n| §11 第二步新入口 | 本文件整体 |\n\n---\n\n### 23. 本版结论\n\nv2.2 吸收了前序文档中的以下优势：\n\n1. **额度体系**（测评4/免评4/累计12）作为独立共用能力，含台账/预占/预警/拦截\n2. **画像拆解**为 7 组字段 × 3 类用途\n3. **节点规则表**统一用 查/写/状态/提醒/拦截/转人工 格式\n4. **EDM 专属行为指标**（3/5次0打开、点击未回复时长、单月收信次数）\n5. **客服管理支撑流**（排班/出勤/绩效/目标）\n6. **评价完成流程**中拆开\"提交即计12\"vs\"展示才计完成\"\n7. **P0/P1/P2 数据对象**优先级\n\n同时保留了我版的核心优势：\n\n1. **IM A/B/C 三层用户完整流转**（提交核验、测评流程、标签汇总、推送/流转动作表）\n2. **渠道交叉与协同规则**（优先级路由、去重规则、用户状态 × 渠道可用性矩阵）\n3. **KOC/KOL JOYCOLLAB 同步链路**及免评协同角色表\n4. **TEL 拨打前准备五步 + 重试策略**\n5. **店铺紧急催评**独立子流程\n6. **三套并行客服状态**（工单/答应配合/风险）\n\n并完成以下收口：\n\n1. 将 IM 里残留的 `Amazon 账号 < / > 12 review` 全部改为 `真实人累计真实提交评价` 口径\n2. 明确 TEL 可继续服务，但不能绕开普通测评额度限制\n3. 补齐渠道路由、渠道去重、IM 流程标签和 EDM 行为画像对应的数据对象\n", + "wikilinks": [], + "category": "layer-requirements" + } + }, + { + "id": "doc:05_需求文档/20260517_USER评价业务闭环主流程与后续工作基线_v1.2", + "type": "document", + "name": "USER 评价业务闭环主流程与后续工作基线 v1.2", + "filePath": "05_需求文档/20260517_USER评价业务闭环主流程与后续工作基线_v1.2.md", + "summary": "USER 评价业务闭环主流程与后续工作基线 v1.2 文件信息 文件名称： 20260517 USER评价业务闭环主流程与后续工作基线 v1.2.md 项目路径： C:\\XCODE\\USER 当前版本： v1.2 最近更新： 2026 05 17 前一版本： 20260517 USER评价业务闭环主流程与后续工作基线 v1.1.md 文件目的：在既有销售到评", + "tags": [ + "05_需求文档", + "需求文档" + ], + "complexity": "moderate", + "knowledgeMeta": { + "content": "# USER 评价业务闭环主流程与后续工作基线 v1.2\n\n## 文件信息\n\n- 文件名称：`20260517_USER评价业务闭环主流程与后续工作基线_v1.2.md`\n- 项目路径：`C:\\XCODE\\USER`\n- 当前版本：`v1.2`\n- 最近更新：`2026-05-17`\n- 前一版本：`20260517_USER评价业务闭环主流程与后续工作基线_v1.1.md`\n- 文件目的：在既有销售到评价闭环基线上，补入真实人识别、测评 / 免评额度、用户历史上下文、IM / EDM / TEL / 客服细化口径，作为新版第二步和后续数据流设计的统一依据。\n- 适用范围：当前阶段的 Amazon 业务闭环设计；如后续扩展到独立站或非 Amazon 评价体系，需要在本文件基础上另行增补。\n- 使用方式：下一次继续本项目时，先读取本文件，再读取 `20260517_USER评价业务闭环_共用能力图与渠道专属流程_v2.2.md`，不要再从旧版页面链路重新推导业务主干。\n\n---\n\n## 版本记录\n\n| 版本 | 日期 | 说明 |\n| --- | --- | --- |\n| v1 | 2026-05-17 | 首次固化销售到评价完成的 USER 业务闭环主流程 |\n| v1.1 | 2026-05-17 | 将免评改为独立闭环；明确每次有效互动都要重新做身份与风险判断；明确当前版本不单列商家角色 |\n| v1.2 | 2026-05-17 | 补入用户历史与设备上下文、真实人级 `测评4 / 免评4 / 累计真实提交评价12` 规则、IM / EDM / TEL / 客服新增细节，并把第二步入口改为“共用能力 + 渠道专属流程” |\n\n---\n\n## 1. 已确认目标\n\n1. 系统要支持 USER 部门工作，而不是只做一个回评记录工具。\n2. 业务流必须从“销售发生 / 需求形成”开始，而不是从“推送”开始。\n3. Amazon 运营既可以人工提需求，系统也可以因 Listing 健康或评价缺口自动触发需求。\n4. 用户运营是“需求评估 + 计划调度中心”，负责把需求转成可执行计划并跟踪结果。\n5. 计划类型必须正式保留：\n - 推新计划\n - 回评计划\n - 免评计划\n6. `免评计划` 不是边缘例外，而是需要正式保留的关键业务类型；其与 KOC / KOL、社媒带货、站外流量和 Amazon 权重有关。\n7. 用户提交评价与系统确认评价完成必须拆成两个节点：\n - 用户已真实提交评价\n - Amazon 已展示 / 系统已确认计入计划完成\n8. `真实人` 是后续额度、风险、历史和用户画像的核心对象，不应只围绕某个 JOYHUB ID、邮箱或 Amazon 账号看用户。\n9. 已确认的额度规则为：\n - 同一真实人每月最多参与 `4 次测评`\n - 同一真实人每月最多参与 `4 次免评`\n - 同一真实人累计最多计入 `12 个真实提交的评价`\n10. `12` 的计数时点是 `用户真实提交评价`，不是 `Amazon 展示评价`。\n11. 每次有效互动都要重新做身份、历史、额度和风险判断；主动推送后的回复也不例外。\n12. 客服接入时必须能快速看到用户历史、订单历史、设备上下文、既往风险和当前提醒，而不是只看到当前对话。\n13. 后续系统设计顺序已经确定：\n 1. 先定业务流\n 2. 再做点击操作模拟\n 3. 最后根据业务需求整合现有数据，形成新的数据流和中间表需求\n\n---\n\n## 2. 当前边界与资料依据\n\n### 2.1 当前纳入范围\n\n- Amazon 业务\n- 销售到评价闭环\n- 推新、回评、免评\n- IM、EDM、APP、TEL、KOC / KOL\n- 售后接入\n- 客服执行与客服管理支撑\n- 黑名单与诈骗风险\n- ASIN 健康回流\n\n### 2.2 当前不作为本版主流程展开的内容\n\n- 独立站全链路\n- 完整 BI / 财务 / ROI 系统\n- 完整 KOC / KOL 结算系统\n- 所有历史后台页面逐页重构\n- 数据库最终物理设计\n\n### 2.3 资料依据\n\n本文件基于以下材料整理：\n\n1. `C:\\XCODE\\USER\\评价业务流闭环项目架构文档_v0.8.docx`\n2. `C:\\XCODE\\USER\\docs\\evaluation-business-architecture.md`\n3. `C:\\XCODE\\USER\\docs\\project-phase-one-plan.md`\n4. `C:\\XCODE\\USER\\output\\docs\\20260503_USER后台ERP一期功能与页面设计_v4.md`\n5. `C:\\XCODE\\USER\\output\\docs\\20260503_USER后台ERP自动推送与计划状态机_v4.md`\n6. `C:\\XCODE\\USER\\output\\docs\\20260503_USER后台ERP一期页面原型说明_v4.md`\n7. `C:\\XCODE\\USER\\output\\docs\\20260503_USER后台ERP_MVP角色首页UI规划_v1.md`\n8. `C:\\tcode\\飞书\\飞书聊天记录库\\cloud_files` 中当前主原型 HTML 与 `客服执行.html`\n9. `C:\\Users\\wu_zh\\Downloads\\20260407-法国诈骗问题（已扩散美国）.docx`\n10. `C:\\Users\\wu_zh\\Desktop\\表头.xlsx`\n11. `C:\\Users\\wu_zh\\Downloads\\IM 推送业务流.mm`\n12. `C:\\Users\\wu_zh\\Downloads\\后台回评工作流对接事项.docx`\n13. `C:\\Users\\wu_zh\\Downloads\\客服相关模块.docx`\n14. `C:\\Users\\wu_zh\\Downloads\\电话业务流程知识库.docx`\n15. 用户在当前对话中补充确认的业务规则\n\n若历史资料与当前对话确认口径冲突，以当前对话中最新确认口径为准。\n\n---\n\n## 3. 角色与职责\n\n| 角色 | 核心职责 |\n| --- | --- |\n| Amazon 运营 | 依据销售、ASIN、评价目标提出推新 / 回评 / 免评需求 |\n| Amazon 运营总监 | 审批相关计划，确认优先级与业务必要性 |\n| 品牌运营 | 负责品牌推广、站外节奏和与用户运营 / 内容运营协同 |\n| 内容运营 | 承接社区广告、APP 广告位、内容流量等侧向支持 |\n| 用户运营 | 评估需求、生成计划、分配资源、协调渠道、跟踪结果 |\n| 用户运营负责人 / 组长 | 复核计划、分配组员、处理重点风险和异常 |\n| 菲律宾客服负责人 | 关注工单压力、分配客服组、处理升级工单、查看绩效 |\n| 菲律宾客服组长 | 分配组内工单、复核升级、控制逾期和重点工单 |\n| 菲律宾客服组员 | 实际接待、电话沟通、记录、回复、回访、提交疑似诈骗 |\n| 风险 / 黑名单相关人员 | 接收诈骗疑似、复核、同步黑名单、维护风险口径 |\n| KOC / KOL 运营 | 承接站外带货、合作关系、内容和导购协同 |\n\n当前版本不单列“商家 / 商家运营”角色。这里的“商家”如出现，均按 Amazon 卖家侧语义理解，由 Amazon 运营承接；品牌商当前也只纳入 Amazon 内评价相关协同。\n\n---\n\n## 4. 总体业务结构\n\n### 4.1 主流程\n\n```mermaid\nflowchart LR\n A[\"销售发生 / ASIN销售数据形成\"] --> B[\"需求触发\"]\n B --> B1[\"Amazon运营人工提需求\"]\n B --> B2[\"系统按评价缺口或Listing健康自动触发\"]\n B1 --> C[\"用户运营评估需求\"]\n B2 --> C\n C --> D[\"形成业务计划\"]\n D --> D1[\"推新计划\"]\n D --> D2[\"回评计划\"]\n D --> D3[\"免评计划\"]\n D1 --> E[\"规则 / 风险 / 额度复核\"]\n D2 --> E\n D3 --> E\n E --> F[\"审批通过\"]\n F --> G[\"执行拆解\"]\n G --> H1[\"评价型执行闭环\"]\n G --> H2[\"免评型执行闭环\"]\n H1 --> I1[\"IM / EDM / APP / TEL / 客服协同\"]\n I1 --> J1[\"用户被触达或主动进入\"]\n J1 --> K1[\"每次有效互动均重做身份 / 历史 / 额度 / 风险核验\"]\n K1 --> L1[\"服务 / 售后 / 跟进\"]\n L1 --> M1[\"用户真实提交评价\"]\n M1 --> N1[\"计入真实人累计评价额度\"]\n N1 --> O1[\"Amazon是否展示 / 系统是否确认完成\"]\n O1 --> P[\"结果回流\"]\n H2 --> I2[\"KOC / KOL为核心，IM / EDM / APP等协同参与\"]\n I2 --> J2[\"内容发布 / 站外引流 / 带货执行\"]\n J2 --> K2[\"跟踪点击、Code、订单、转化与权重结果\"]\n K2 --> P\n P --> Q[\"更新ASIN健康、计划完成度、用户画像、流量结果、风险记录\"]\n Q --> C\n```\n\n### 4.2 五个业务层\n\n| 业务层 | 说明 |\n| --- | --- |\n| 经营层 | 销售、ASIN、需求、品牌 / 内容 / KOC-KOL 侧影响 |\n| 计划层 | 推新、回评、免评、审批、规则、额度、风险 |\n| 执行层 | IM、EDM、APP、TEL、客服工单、KOC / KOL 协作 |\n| 服务与身份层 | 用户接入、真实人归并、订单核验、用户上下文、售后处理 |\n| 结果与风险层 | 用户真实提交评价、Amazon 展示确认、免评结果、黑名单、诈骗、结果回流 |\n\n---\n\n## 5. 主流程详细说明\n\n| 阶段 | 业务说明 | 必须检查 | 主要输出 |\n| --- | --- | --- | --- |\n| 1. 销售与需求形成 | 销售发生后，Amazon 运营根据目标或系统根据健康度触发需求 | 销售、ASIN、评分、评价缺口、历史计划 | 新需求 |\n| 2. 用户运营评估 | 判断需求是否成立、是否可做、优先级如何 | ASIN 健康、目标数量、历史完成、当前资源、风险 | 已确认需求 / 待补充 / 驳回 |\n| 3. 计划生成 | 将需求转为推新、回评或免评计划 | 用户池、渠道容量、目标、周期 | 计划草案 |\n| 4. 计划复核与审批 | 对计划做规则、额度和风险复核，再进入审批 | 黑名单、频控、渠道风险、真实人额度、审批权限 | 已批准计划 |\n| 5. 执行拆解 | 把计划拆成渠道任务和人工任务 | 可触达用户、素材、客服负载、KOC / KOL协作 | 推送任务 / TEL任务 / 客服工单 / 协作任务 |\n| 6A. 评价型执行 | 推新、回评进入用户触达、服务与评价链路 | 真实人、订单、历史、额度、风险、售后情况 | 当前处理路径 |\n| 6B. 免评型执行 | 免评以 KOC / KOL 与站外流量为核心，同时可由 IM / EDM / APP 等协同参与 | 合作对象、内容、Code、渠道、素材、节奏、免评额度 | 内容任务 / 引流任务 / 带货任务 |\n| 7A. 用户真实提交评价 | 记录用户是否已经实际提交评价 | 用户反馈、提交证据、对应计划、真实人累计额度 | 已提交评价事实 |\n| 7B. 免评结果跟踪 | 记录免评计划的执行结果 | 内容发布、点击、Code、订单、转化、销量、权重变化 | 免评执行结果 |\n| 8. 评价确认 | 区分用户提交与 Amazon 展示结果 | Amazon 是否展示、是否能核验、是否属本计划 | 计入完成 / 待确认 |\n| 9. 结果回流 | 把评价结果与免评结果重新反馈给经营与计划层 | 计划完成、ASIN 健康、流量结果、风险变化、用户标签 | 新一轮决策输入 |\n\n---\n\n## 6. 关键业务支线\n\n### 6.1 主动触达支线\n\n```mermaid\nflowchart LR\n A[\"计划通过\"] --> B[\"筛选可触达用户池\"]\n B --> C[\"真实人识别 + 人群画像 + 额度校验\"]\n C --> D[\"渠道分配\"]\n D --> D1[\"IM\"]\n D --> D2[\"EDM\"]\n D --> D3[\"APP\"]\n D --> D4[\"TEL\"]\n D1 --> E[\"用户回应\"]\n D2 --> E\n D3 --> E\n D4 --> E\n E --> F[\"每次回应都重做身份 / 历史 / 额度 / 风险核验\"]\n F --> G[\"订单核验\"]\n G --> H[\"服务 / 跟进\"]\n H --> I[\"用户真实提交评价\"]\n```\n\n#### 关键规则\n\n1. IM、EDM、APP 可自动化；TEL 属于人工执行渠道。\n2. `IM` 需要识别用户分层、绑定玩具、设备、测评 / 免评额度和标签流转。\n3. `EDM` 需要识别最近打开、最近回复、点击评论链接但未回复、月度收信次数、最近 3 / 5 次 0 打开、邮箱类型、退订和硬退信。\n4. 计划生成前必须先检查：\n - 用户是否可触达\n - 是否命中风险\n - 是否超频\n - 是否符合站点 / 国家 / 产品目标\n - 是否接近或达到真实人额度上限\n5. 用户回应后，不能沿用上一次判断结果，必须重新检查当前身份、订单、设备、地址、历史、额度与风险状态。\n\n### 6.2 免评执行支线\n\n```mermaid\nflowchart LR\n A[\"免评计划通过\"] --> B[\"拆解执行方案\"]\n B --> C1[\"KOC / KOL协作\"]\n B --> C2[\"IM / EDM / APP辅助触达\"]\n B --> C3[\"内容 / 运营协同\"]\n C1 --> D[\"内容发布 / Code使用 / 站外引流\"]\n C2 --> D\n C3 --> D\n D --> E[\"跟踪点击、跳转、Code、订单、转化、销量与权重变化\"]\n E --> F[\"结果回流到ASIN健康与后续计划\"]\n```\n\n#### 关键规则1\n\n1. 免评计划不是评价型计划的弱化版本，而是以站外流量、带货、销量和权重结果为终点的独立闭环。\n2. KOC / KOL 是免评计划的核心执行通道，但 IM、EDM、APP 等也可以参与协同。\n3. 同一真实人每月最多参与 `4 次免评`；免评额度也要做预警、预占和拦截。\n4. 免评计划不以“用户提交评价”作为完成条件，必须另行跟踪内容发布、Code、点击、订单、转化、销量和权重变化。\n5. 如果免评执行过程中发生用户互动、售后或返款等行为，仍须进入统一的身份与风险判断机制。\n\n### 6.3 被动售后与 TEL 支线\n\n```mermaid\nflowchart LR\n A[\"用户主动联系 / 电话呼入\"] --> B[\"接入即预查\"]\n B --> C[\"识别来源、身份、订单、历史、风险\"]\n C --> D{\"是否有售后问题\"}\n D -->|有| E[\"问题分类与解决方案\"]\n E --> F[\"确认是否解决 / 是否满意\"]\n F --> G[\"满意后进入回评 / 测评邀请\"]\n D -->|无| H[\"确认无其他需求\"]\n H --> I[\"可进入测评邀请\"]\n G --> J[\"记录电话 / 工单 / 后续跟进\"]\n I --> J\n```\n\n#### 关键规则2\n\n1. TEL 当前至少包含两类入口：\n - 计划生成后的人工外呼任务\n - 用户从 Amazon 页面或说明书主动呼入\n2. 有售后问题时，必须先解决售后，再谈评价或测评邀请。\n3. 电话中需要尽量确认：\n - 购买平台\n - 订单号\n - 产品型号 / 款式 / 颜色\n - 购买时间\n - 问题类型\n - 是否有图片、视频或其他凭证\n4. 每通电话结束后，至少要记录：\n - 来电时间\n - 来源\n - 联系方式\n - 订单号\n - 问题类型和描述\n - 处理方案\n - 是否已解决\n - 是否需要后续跟进\n - 是否邀请测评 / 回评\n - 用户是否接受\n5. 当前电话业务的核心是：\n - 自然单回评转化\n - 充分利用电话用户的测评资源\n\n### 6.4 风险 / 诈骗拦截支线\n\n```mermaid\nflowchart LR\n A[\"新订单同步 / 主动触达回应 / 用户接入 / 退款申请 / 再次跟进\"] --> B[\"重新做风险识别\"]\n B --> C{\"是否命中强关联\"}\n C -->|是| D[\"直接进入高风险或黑名单链路\"]\n C -->|否| E{\"是否命中弱关联\"}\n E -->|是| F[\"进入高风险观察 + 人工复核\"]\n E -->|否| G[\"继续正常流程\"]\n D --> H[\"拦截自动退款、继续推送、自动放行\"]\n F --> H\n H --> I[\"提醒客服 / 用户运营 / 审核人员\"]\n```\n\n#### 已确认风险口径\n\n| 风险类型 | 关联项 | 处理原则 |\n| --- | --- | --- |\n| 强关联 | 邮箱、设备号、电话、收件人姓名+地址、订单号、聊天记录、Profile ID、收款信息 | 一旦命中，可直接进入高风险或黑名单链路 |\n| 弱关联 | IP 单独命中、姓名单独命中、同址异名 | 进入高风险观察，不直接认定诈骗 |\n\n#### 已确认业务问题\n\n1. 当前真实事故中存在“双重退款”风险：\n - APP / OA 已退款\n - 用户又向 Amazon 申请退款\n2. 需要把 Amazon 退款与 OA 返款自动比对。\n3. 高风险用户一旦标记，支付 / 返款需要人工复核。\n4. 客服、审核、退款等环节必须都能看到风险提醒。\n5. 非 APP 用户如果直接走邮件退款，因缺少设备、注册邮箱等维度，风险识别能力明显下降。\n6. 风险判断不是一次性的接入动作，而是每次有效互动都要重新执行。\n\n### 6.5 客服工单与客服管理支线\n\n```mermaid\nflowchart LR\n A[\"用户消息进入 / 推送转人工 / 售后触发 / 风险触发\"] --> B[\"生成工单\"]\n B --> C[\"按班次、在线状态、当前负载自动分配\"]\n C --> D[\"客服处理\"]\n D --> E{\"处理结果\"}\n E -->|等待用户| F[\"等待用户回复\"]\n E -->|等待内部| G[\"等待内部协同\"]\n E -->|答应配合| H[\"生成后续跟进\"]\n E -->|疑似诈骗| I[\"转风险链路\"]\n E -->|已解决| J[\"关闭工单\"]\n D --> K[\"回复效率 / 转化 / 目标完成统计\"]\n```\n\n#### 工单与管理事实\n\n1. 客服相关模块不只包括工单，还包括：\n - 出勤管理\n - 排班管理\n - 回复效率统计\n - 转化统计\n - 目标管理\n2. `排班` 与 `在线状态` 会直接影响自动分配。\n3. `工单状态`、`答应配合状态`、`风险状态` 必须拆开存。\n4. 客服转化要区分：\n - RSO 回评\n - RDO 测评\n5. 回复效率至少要统计：\n - 回复用户数\n - 处理工单数\n - 发送消息数\n - 平均 / 中位数 / 最大 / 最小首次回复时长\n6. 转化统计至少要看：\n - 登记订单数\n - 获取评价数\n - 评价完成率\n7. 主管需要看到出勤、排班、绩效、目标完成和工单分配，而不是只看单个会话。\n\n---\n\n## 7. 真实人识别、用户上下文与额度规则\n\n### 7.1 真实人识别原则\n\n1. 当前系统不应只围绕 `JOYHUB ID` 看用户，而应同时围绕：\n - 账号\n - 订单\n - 实际收件人\n - 设备\n - 联系方式\n - 风险关系\n2. 如果用户在 JOYHUB 内提交订单，则订单可直接关联到当前 JOYHUB ID。\n3. 如果用户通过邮件联系：\n - 先问是否有 JOYHUB ID\n - 再用注册邮箱与 JOYHUB ID 做关系查询\n4. 如果用户通过电话联系：\n - 先确认是否注册 APP\n - 结合电话、订单、收件人、地址、设备、邮箱继续识别\n5. 非 APP 用户如需继续参与相关流程，应优先引导注册 APP，再继续后续动作。\n\n### 7.2 实际收件人判定\n\n| 情况 | 处理原则 |\n| --- | --- |\n| 标准化后姓名 + 地址完全一致 | 直接认为是同一实际收件人 |\n| 地址一致但姓名不同 | 只认为存在家庭 / 关联风险，不直接判定同一人 |\n| 邮箱不同、JOYHUB ID 不同 | 不能单独否定“同一实际人” |\n| 订单号命中历史异常 | 应立即拉出历史上下文和风险记录 |\n\n### 7.3 用户上下文卡\n\n客服和用户运营在必要节点应能看到：\n\n| 字段组 | 例子 |\n| --- | --- |\n| 当前身份 | JOYHUB ID、邮箱、电话、真实人 ID、当前订单 |\n| 历史交易 | 历史订单、最近购买、退款 / 返款、目标 ASIN 购买情况 |\n| 历史服务 | 历史工单、聊天、电话、承诺、提醒、关闭原因 |\n| 历史风险 | 黑名单、关联账号、疑似诈骗、双重退款、异常订单 |\n| 当前设备 | 设备号摘要、设备型号 / 类型、系统版本、APP 版本、最近设备变化 |\n| 触达历史 | IM / EDM / APP / TEL 最近触达、回复、退订、投诉 |\n\n### 7.4 额度规则\n\n| 规则 | 统计对象 | 计数口径 |\n| --- | --- | --- |\n| 月度测评最多 4 次 | 真实人 | 已完成 + 进行中 + 已预占 |\n| 月度免评最多 4 次 | 真实人 | 已完成 + 进行中 + 已预占 |\n| 累计真实提交评价最多 12 个 | 真实人 | 用户真实提交评价后立即计数 |\n\n### 7.5 额度控制原则\n\n1. 额度判断必须放在 `真实人识别` 之后，而不是只看单一账号。\n2. 系统不能等到真正超限才提示，必须在接近上限时提前预警。\n3. 一旦 `已用 + 进行中 + 已预占 + 本次拟发送` 会导致超限，就不能进入自动推送。\n4. `Amazon 未展示` 不影响 12 次累计额度，因为口径已经确认按 `真实提交` 计数。\n\n---\n\n## 8. 渠道专属补充事实\n\n### 8.1 IM\n\n- 用户需要分层：未参与过、参与过、长期测评人。\n- 触发条件包括注册 App、绑定玩具、识别绑定产品。\n- 需要校验设备 ID、黑名单、绑定产品、额度与标签。\n- 用户提交订单号、返款账号、评论截图 / 链接后，要继续做订单核验和资格登记。\n\n### 8.2 EDM\n\n- EDM 不是简单“发邮件”，而是独立的筛选与节奏引擎。\n- 需要支持：\n - 最近打开时间\n - 最近回复时间\n - 打开次数\n - 最近 3 / 5 次推送 0 打开\n - 点击评论链接但未回复时长\n - 单月收信次数\n - 各邮件类型发送次数\n - 邮箱后缀标签\n - 国家站点\n - 退订、硬退信、风险用户、黑名单、OA 无资格用户排除\n\n### 8.3 APP\n\n- APP 侧至少要纳入：\n - 注册邮箱\n - 设备号\n - 设备型号 / 类型\n - APP 版本\n - 系统版本\n - 用户行为数据\n - 绑定玩具\n - 活跃与点击行为\n- APP 不只是触达渠道，也是身份识别、设备变化和行为画像的重要来源。\n\n### 8.4 TEL\n\n- TEL 同时承担主动外呼和被动来电。\n- 其价值不只是“打电话”，而是：\n - 解决售后\n - 捕捉自然单回评机会\n - 充分利用电话用户的测评资源\n\n---\n\n## 9. 评价结果规则\n\n### 9.1 必须拆开的两个节点\n\n```mermaid\nflowchart LR\n A[\"用户已真实提交评价\"] --> B[\"计入真实人累计评价额度\"]\n B --> C{\"Amazon是否展示 / 是否可核验\"}\n C -->|展示或可核验| D[\"计入计划完成\"]\n C -->|未展示 / 暂不可核验| E[\"保留用户已提交事实\"]\n E --> F[\"进入待确认 / 异常观察\"]\n D --> G[\"更新ASIN健康与计划完成度\"]\n```\n\n### 9.2 原因\n\n1. 用户可能确实已经提交评价。\n2. Amazon 可能因为其他原因不展示该评价。\n3. `额度计数` 与 `计划完成确认` 不是同一个业务事实。\n4. 如果系统只保留一个“评价完成”状态，会把平台展示问题错误归因给执行人员或用户。\n\n---\n\n## 10. 贯穿全程的数据检查点\n\n| 检查点 | 发生时机 | 核心检查 |\n| --- | --- | --- |\n| 经营检查 | 需求形成前 | 销售、ASIN、评分、评价缺口、历史计划 |\n| 计划检查 | 生成计划前 | 人群、渠道、容量、规则、黑名单 |\n| 画像检查 | 生成人群时 | 国家、站点、性别、年龄、绑定玩具、产品关系、活跃、历史行为 |\n| 额度检查 | 生成人群、发送前、继续推进前 | 测评 4、免评 4、累计真实提交 12、进行中与已预占 |\n| 身份检查 | 首次接入与每次有效互动时 | JOYHUB、邮箱、电话、设备、订单、地址、历史记录 |\n| 互动复检 | 主动触达回应、再次联系、补充订单号、客服回访时 | 关键属性是否变化，是否出现新订单、新地址、新设备、新返款记录 |\n| 风险检查 | 每次有效互动、退款、返款、继续推送前 | 双重退款、强弱关联、黑名单、历史异常 |\n| 结果检查 | 评价提交与确认后 | 首评 / 回评、是否属本计划、是否展示、ASIN 健康变化 |\n\n---\n\n## 11. 第二步的新入口\n\n第二步不再按旧版页面链路推进，而改成：\n\n### 11.1 共用能力图\n\n1. 真实人识别与用户上下文卡\n2. 人群生成与画像拆解\n3. 额度与频控控制\n4. 每次有效互动复检\n5. 风险与黑名单\n\n### 11.2 渠道 / 模块专属流程图\n\n1. IM\n2. EDM\n3. APP\n4. TEL\n5. 客服工单\n6. 客服管理支撑\n7. 评价完成\n8. 免评执行\n\n### 11.3 每张图都必须回答\n\n- 进入条件是什么\n- 要先查什么\n- 如何判断\n- 写入什么\n- 状态怎么变\n- 何时提醒\n- 何时拦截\n- 何时转人工\n\n---\n\n## 12. 下一次继续工作时的直接提示\n\n1. 先读取本文件。\n2. 不要重新讨论“是否从销售开始”“是否保留免评”“评价提交与展示是否拆开”，这些已确认。\n3. 额度口径按当前版本执行：\n - 测评每月最多 4\n - 免评每月最多 4\n - 同一真实人累计真实提交评价最多 12\n4. 不要再把风险判断理解成“首次接入才做一次”；每次有效互动都需要重做判断。\n5. 不要再把第二步按页面链路拆；直接进入 `20260517_USER评价业务闭环_共用能力图与渠道专属流程_v2.2.md`。\n6. 旧版 `v1` / `v1.1` 保留为历史版本，不再作为后续主口径。\n\n---\n\n## 13. 本版结论\n\nUSER 部门未来系统的核心，不是单独记录“谁评价了”，而是把以下内容放进同一条可追踪闭环中：\n\n1. 销售与需求\n2. 计划生成与审批\n3. 真实人识别与用户上下文\n4. 测评 / 免评 / 累计评价额度控制\n5. IM / EDM / APP / TEL / 客服协同\n6. 用户身份与订单核验\n7. 售后服务与评价引导\n8. 免评执行与站外流量结果\n9. 用户真实提交评价\n10. Amazon 展示与系统确认\n11. ASIN 健康回流\n12. 风险与黑名单拦截\n\n只有这条闭环建立起来，后续的点击设计、页面设计和数据设计才不会彼此脱节。\n", + "wikilinks": [], + "category": "layer-requirements" + } + }, + { + "id": "doc:05_需求文档/evaluation-business-architecture", + "type": "document", + "name": "评价业务流闭环项目架构文档", + "filePath": "05_需求文档/evaluation-business-architecture.md", + "summary": "评价业务流闭环项目架构文档 版本：v0.7 更新时间：2026 04 26 当前阶段：业务框架搭建与部门业务梳理 1. 文档目标 本文档用于沉淀评价业务流闭环的业务结构、部门职责、核心数据、看板规划和后续项目规划依据。 当前重点不是直接进入系统设计，而是先明确： 业务闭环如何运转 各部门在闭环中的职责边界 每个部门需要哪些看板与数据字段 APP 与亚马逊运营", + "tags": [ + "05_需求文档", + "需求文档" + ], + "complexity": "complex", + "knowledgeMeta": { + "content": "# 评价业务流闭环项目架构文档\n\n版本：v0.7 \n更新时间：2026-04-26 \n当前阶段：业务框架搭建与部门业务梳理\n\n## 1. 文档目标\n\n本文档用于沉淀评价业务流闭环的业务结构、部门职责、核心数据、看板规划和后续项目规划依据。\n\n当前重点不是直接进入系统设计，而是先明确：\n\n- 业务闭环如何运转\n- 各部门在闭环中的职责边界\n- 每个部门需要哪些看板与数据字段\n- APP 与亚马逊运营、品牌运营、内容运营、用户运营、客服运营之间的数据关系\n- 后续项目需要支持哪些管理动作、数据归因和异常预警\n\n## 2. 总体业务闭环\n\n### 2.1 当前业务主链路\n\n亚马逊运营、品牌运营、内容运营负责拉新与引流。 \n主要带来曝光和点击，其中当前主要流量来源于亚马逊，小部分开始来源于社媒与网站宣发。\n\n↓\n\n亚马逊运营负责亚马逊渠道转化与成交，品牌运营负责独立站转化与成交。\n\n↓\n\n成交后产生订单与成交数据。\n\n↓\n\n用户运营基于成交用户、绑定用户、活跃用户进行触达推送与索评。 \n同时，用户运营或评价运营需要维护 ASIN 健康度，核心依赖回评结果。\n\n↓\n\n客服运营收集售后问题、用户反馈、负面反馈和评价相关问题，并执行处理与改善动作。\n\n↓\n\n数据层和管理层进行复盘，调整产品策略、销售策略、推送策略、评价策略和人员分工。\n\n### 2.2 闭环中的核心角色\n\n| 角色/部门 | 主要职责 | 当前定位 |\n|---|---|---|\n| 亚马逊运营 | 亚马逊销售、产品销售管理、测评计划需求、免评计划需求、关键词推新、评价健康维护协同 | 当前 APP 用户最主要、最优质来源 |\n| 品牌运营 | 独立站品牌宣发、独立站销售转化、社媒品牌形象、品牌推广、新品宣发、活动宣发、粉丝互动 | 品牌侧销售与推广主责方，协助亚马逊扩大品牌市场份额 |\n| 内容运营 | 售前社区广告计划、APP 广告位、社区内容分发、帖子加权、新帖推流、固定流量池管理、用户 KOC/KCO 对接 | 配合亚马逊运营与品牌运营做销售前期宣发和社区流量承接 |\n| 用户运营 | 测评计划落地、用户触达、IM/EDM/TEL 推送、索评、回评跟进、社区互动、合作伙伴渠道管理 | 系统核心使用者，连接销售需求、用户资源、评价结果与客服执行 |\n| 客服运营 | 售后接待、登记、回复、问题完结、负面反馈处理 | 归属用户部门管理，承接售后与评价问题改善 |\n| 数据层/管理层 | 指标复盘、异常监控、成本分析、策略调整 | 统一看板、归因和管理决策 |\n\n## 3. 基础指标与统一数据口径\n\n### 3.1 销售核心指标\n\n- 销量：日销量、月销量、总销量\n- 绑定数：总用户数、月活、日活、产品绑定用户数\n- 评价数：测评数、回评数、每日每产品评价数、计划所需数量、实际完成数量、差评数\n- 成本：产品成本、返现成本、人力成本、提成、管理成本\n\n### 3.2 基础数据维度\n\n| 数据维度 | 说明 |\n|---|---|\n| 渠道影响力 | 衡量各渠道内容、活动、广告位、推送计划的效果 |\n| 用户属性 | 发帖人属性、用户行为、性别、活跃状态、风险标记 |\n| 时间维度 | 每日、每周、每月、活动周期、新品周期 |\n| 产品维度 | 国家、品牌、类目、二级类目、ASIN、产品绑定情况 |\n| 漏斗维度 | 曝光、点击、跳转、转化、成交、绑定、触达、评价 |\n| 风险维度 | 风险标记用户数、差评数、ASIN 健康风险、异常推送效果 |\n\n### 3.3 建议统一主键\n\n后续系统设计应优先统一以下主键，避免销售、用户、评价、售后数据无法串联：\n\n- 用户 ID\n- 订单 ID\n- 产品 ID\n- ASIN\n- 品牌 ID\n- 国家/站点\n- 渠道 ID\n- 推送 ID\n\n## 4. 第一部分：亚马逊运营相关业务\n\n### 4.1 亚马逊运营在闭环中的定位\n\n亚马逊运营负责在亚马逊平台上进行电商销售工作，是当前 APP 用户最主要、最优质的来源。\n\nAPP 与亚马逊运营之间的核心关系是：\n\n1. 亚马逊销售带来订单和用户来源。\n2. APP 需要识别这些购买用户是否下载安装并绑定产品。\n3. 当前每卖出 10 个玩具，约 40% 用户下载并绑定 APP。\n4. 需要亚马逊运营在 Listing、说明书、官网、售后触点等位置配合提升 APP 下载率和产品绑定率。\n5. 亚马逊运营需要提出测评计划、免评计划、推新计划和回评计划相关需求。\n6. APP 内现有用户资源需要根据产品重要级、推新节奏和评价健康度进行分配。\n\n### 4.2 亚马逊运营核心业务模块\n\n| 模块 | 业务内容 | 与 APP 的关系 |\n|---|---|---|\n| 销售管理 | 亚马逊站点销售、销量监控、产品销售报表 | 提供销量、成交、站点、产品数据 |\n| 产品聚合管理 | 按品牌、国家、类目聚合新品、重点产品、清仓产品 | APP 侧需要计算绑定率和用户覆盖情况 |\n| 绑定率提升 | Listing、说明书、官网等触点引导下载与绑定 APP | APP 提供绑定率数据，亚马逊运营优化触点 |\n| 测评计划 | 亚马逊运营根据销售需求提出测评需求和节奏 | 用户运营负责实际实现，品牌运营参与协同 |\n| 免评计划 | 关键词 + 实时销量策略，定时下单，主要承接补单诉求 | 需单独纳入合规与风险监控 |\n| 推新计划 | 面向 S 级或当期重点产品，结合关键词进行推广 | APP 内推送资源分配需要与推新计划匹配 |\n| 回评计划 | 维护链接评价数、回评数和评分等级 | 主要由亚马逊运营与用户运营协作，品牌运营参与协同 |\n| 品牌推广协同 | 亚马逊运营同步品牌推广计划，并在亚马逊站内承接品牌调性 | 品牌运营为亚马逊站外品牌推广主责方 |\n\n### 4.3 独立看板一：产品销量与绑定率看板\n\n#### 4.3.1 看板目标\n\n用于从亚马逊运营视角监控不同品牌、国家、类目、产品类型下的销量与 APP 绑定情况。\n\n该看板需要支持：\n\n- 品牌聚合\n- 国家/站点聚合\n- 类目与二级类目聚合\n- 新品、重点产品、清仓产品拆分\n- 销量与绑定率对比\n- 异常数据报警\n- 对应人员责任归属\n\n#### 4.3.2 产品类型\n\n| 产品类型 | 说明 |\n|---|---|\n| 新品 | 新上市产品，需要重点关注销量、绑定率、评价启动速度 |\n| 重点产品 | 当期重点销售或重点维护产品，如 S 级产品 |\n| 清仓产品 | 需要配合库存、促销、清仓节奏进行销售与触达 |\n\n#### 4.3.3 字段规划\n\n| 字段 | 说明 |\n|---|---|\n| 产品名 | 产品展示名称 |\n| 国家 | 销售国家或市场 |\n| 品牌 | 所属品牌 |\n| 对应人员 | 负责该产品或站点的运营人员 |\n| 二级类目 | 产品所属二级类目 |\n| ASIN | 亚马逊 ASIN |\n| 产品类型 | 新品、重点产品、清仓产品 |\n| 各站点销量 | 各亚马逊站点销量，详细数据涉密 |\n| 总销量 | 汇总销量 |\n| APP 绑定数 | APP 可识别的、已绑定指定玩具的用户数 |\n| 绑定率 | APP 可识别的绑定了指定玩具的用户数 / 销售数 |\n| 异常状态 | 是否出现销量异常、绑定率异常、数据缺失等 |\n| 异常原因 | 异常说明或系统识别原因 |\n| 最近更新时间 | 数据刷新时间 |\n\n#### 4.3.4 重点指标\n\n- 产品销量\n- APP 绑定数\n- APP 绑定率\n- 新品绑定率爬坡情况\n- 重点产品绑定率\n- 清仓产品触达与绑定情况\n- 低绑定率产品列表\n- 异常站点/异常国家/异常类目\n\n#### 4.3.5 异常报警建议\n\n| 异常类型 | 触发逻辑 |\n|---|---|\n| 绑定率过低 | 产品销量正常，但 APP 绑定率低于目标值 |\n| 销量异常波动 | 单日或单周销量较基准值显著上升或下降 |\n| 站点数据缺失 | 某国家/站点销量或绑定数据未同步 |\n| 新品启动异常 | 新品有销量但绑定数或评价启动明显滞后 |\n| 重点产品风险 | S 级或重点产品绑定率、评价数、评分低于目标 |\n\n### 4.4 独立看板二：推新计划与 APP 推送资源分配看板\n\n#### 4.4.1 看板目标\n\n用于管理亚马逊推新计划和 APP 内现有推送资源之间的配合关系。\n\n推新计划的核心是关键词相关的重点产品推广，尤其是当期周度、月度重点产品，如 S 级产品。\n\nAPP 侧需要根据现有用户资源，在 APP 内用户中进行定向推送、曝光、点击、回复、登记和评价转化跟踪。\n\n#### 4.4.2 推新业务结构\n\n| 层级 | 内容 |\n|---|---|\n| 当期重点产品 | 周度、月度重点产品表，例如 S 级产品 |\n| 关键词策略 | 每个重点产品关联的关键词方向 |\n| 推新算法 | 基于产品重要级、用户资源、活跃度、绑定数、历史效果进行推送分配 |\n| APP 推送资源 | APP 内用户、社区消息、广告位、图片点击、活动曝光等 |\n| 效果回收 | 曝光、点击、回复、登记、评价、回评 |\n\n#### 4.4.3 字段规划\n\n| 字段 | 说明 |\n|---|---|\n| 产品名 | 推新产品名称 |\n| ASIN | 对应亚马逊 ASIN |\n| 产品重要级 | 如 S 级、A级、普通等 |\n| 关键词 | 推新关联关键词 |\n| 推送方案 | 当前采用的推送策略或资源组合 |\n| 推送 ID | APP 内推送任务 ID |\n| 关联图片点击率 | 推送图片或关联素材点击率 |\n| 产品绑定数 | 已绑定该产品的用户数 |\n| 总用户数 | APP 总用户数或目标用户池总数 |\n| 当月活跃用户数 | 当月活跃用户规模 |\n| 当月活跃率 | 当月活跃用户数 / 总用户数 |\n| 推送数 | 实际推送数量 |\n| 曝光数 | 用户实际看到的曝光数量 |\n| 点击数 | 用户点击数量 |\n| 回复数 | 用户回复数量 |\n| 登记数 | 用户登记或报名数量 |\n| 评价数 | 最终产生的评价数量 |\n| 回评数 | 最终产生的回评数量 |\n| 推送状态 | 未开始、进行中、已结束、暂停、异常 |\n| 负责人 | 推新或推送负责人 |\n\n#### 4.4.4 核心计算指标\n\n- 曝光率 = 曝光数 / 推送数\n- 点击率 = 点击数 / 曝光数\n- 回复率 = 回复数 / 点击数\n- 登记率 = 登记数 / 点击数\n- 评价转化率 = 评价数 / 登记数\n- 回评转化率 = 回评数 / 评价数\n- 活跃用户覆盖率 = 推送数 / 当月活跃用户数\n\n#### 4.4.5 当前推新资源分配口径\n\n当前推新计划先采用基础规则，后续逐步引入模型。\n\n现阶段基本逻辑：\n\n- S 级产品需求需要最大程度满足。\n- 当前流量池预计约 50% 分配给核心 S 级产品。\n- A 级、B 级及其他产品共同占用剩余约 50% 流量。\n- 产品数量比例上，S 级约 10 来个，其他产品约 200 来个。\n- 后续建议计划需要综合关键词需求、GEO 需求、销量、产品重要级和突发事件生成。\n\n### 4.5 独立看板三：测评计划与免评计划看板\n\n#### 4.5.1 看板目标\n\n用于管理亚马逊运营、用户运营与品牌运营协同的核心评价业务，包括测评计划和免评计划。\n\n协作关系：\n\n- 亚马逊运营：根据亚马逊销售需求提出测评计划、免评计划和回评目标。\n- 用户运营：负责实际触达、推送、登记、索评、回评跟进和结果回收。\n- 品牌运营：由于了解亚马逊运营需求，参与协同对接，但不是实际执行主责方。\n\n其中：\n\n- 测评计划：主要用于新品、重点产品的评价启动、评价数量建设和关键词推广配合。\n- 免评计划：主要基于关键词和实时销量策略进行定时下单，当前主要承接补单诉求。\n\n#### 4.5.2 字段规划\n\n| 字段 | 说明 |\n|---|---|\n| 计划 ID | 测评或免评计划唯一标识 |\n| 计划类型 | 测评计划、免评计划 |\n| 产品名 | 关联产品 |\n| ASIN | 关联 ASIN |\n| 国家/站点 | 亚马逊站点 |\n| 品牌 | 所属品牌 |\n| 产品类型 | 新品、重点、清仓 |\n| 产品重要级 | S 级、A级等 |\n| 关键词 | 计划关联关键词 |\n| 计划周期 | 周、月或指定活动周期 |\n| 计划数量 | 计划执行数量 |\n| 实际完成数量 | 已完成数量 |\n| 完成率 | 实际完成数量 / 计划数量 |\n| APP 配合方式 | 推送、广告位、社区触达、客服触达等 |\n| 风险等级 | 低、中、高 |\n| 审批状态 | 待审批、已审批、执行中、已结束、暂停 |\n| 负责人 | 亚马逊运营负责人 |\n| 协同负责人 | APP 或用户运营负责人 |\n\n#### 4.5.3 审批流口径\n\n测评计划、回评计划、免评计划需要建立审批流。\n\n流程口径：\n\n1. 亚马逊运营提出测评、回评、免评计划。\n2. 亚马逊运营总监审批确认。\n3. 审批通过后进入用户运营执行排期。\n4. 用户运营根据用户池、渠道资源和频控规则制定可执行计划。\n\n#### 4.5.4 风险说明\n\n免评计划、补单诉求、返现或强索评相关动作应进入风险管理与审批机制，不能只作为普通运营动作处理。\n\n建议后续单独规划：\n\n- 合规风险字段\n- 审批流\n- ASIN 风险状态\n- 账号风险状态\n- 高风险动作留痕\n\n### 4.6 独立看板四：回评计划与 ASIN 评价健康度看板\n\n#### 4.6.1 看板目标\n\n用于保障亚马逊链接的评价数和评分等级，尤其是新品爆款周期内，需要评价数量和评价等级与销售节奏匹配。\n\n核心目标：\n\n- 保障链接评价数\n- 保障评分等级\n- 支撑新品爆款周期\n- 识别 ASIN 评价健康风险\n- 区分新品、重点产品、清仓产品的回评需求\n\n#### 4.6.2 评价健康标准\n\n当前业务描述中的核心标准：\n\n- 评价数要与新品爆款周期匹配，原则上数量要多。\n- 评价等级需要维持在较高水平。\n- 新品或爆款产品期望评价等级原则上应达到 4.8 以上。\n- 4.8 属于很健康。\n- 4.5 属于健康。\n- 4.2 属于高风险，需要加强对未回评用户的回评推送。\n\n#### 4.6.3 字段规划\n\n| 字段 | 说明 |\n|---|---|\n| ASIN | 亚马逊 ASIN |\n| 产品名 | 产品名称 |\n| 国家/站点 | 销售国家或亚马逊站点 |\n| 品牌 | 所属品牌 |\n| 产品类型 | 新品、重点、清仓 |\n| 产品重要级 | S 级、A级等 |\n| 当月计划回评数 | 当月计划获得的回评数量 |\n| 实际回评数 | 当月实际回评数量 |\n| 回评完成率 | 实际回评数 / 当月计划回评数 |\n| 期望评价等级 | 目标评分等级 |\n| 实际评价等级 | 当前实际评分等级 |\n| 当前评价数 | 当前累计评价数量 |\n| 当月新增评价数 | 当月新增评价数量 |\n| 差评数 | 当前或当月差评数量 |\n| 差评率 | 差评数 / 评价数 |\n| 健康状态 | 健康、关注、风险、严重风险 |\n| 负责人 | ASIN 负责人 |\n\n#### 4.6.4 产品类型下的回评管理\n\n| 产品类型 | 回评管理重点 |\n|---|---|\n| 新品 | 评价启动速度、评价数量爬坡、评分稳定性、爆款周期匹配 |\n| 重点产品 | 评分等级维护、差评预警、持续回评目标达成 |\n| 清仓产品 | 根据清仓节奏决定是否继续投入回评资源，避免资源浪费 |\n\n#### 4.6.5 ASIN 评价健康等级\n\n| 实际评价等级 | 健康状态 | 处理建议 |\n|---|---|---|\n| 4.8 及以上 | 很健康 | 维持正常回评节奏，重点保障新品爆款周期 |\n| 4.5-4.79 | 健康 | 保持监控，按计划推进回评 |\n| 4.2-4.49 | 高风险 | 加强对未回评用户的回评推送 |\n| 低于 4.2 | 严重风险 | 需要升级处理，结合客服、用户运营和亚马逊运营共同干预 |\n\n### 4.7 亚马逊运营协同品牌推广计划\n\n品牌推广计划由亚马逊运营与品牌运营协同完成。\n\n除亚马逊站内的品牌承接和销售动作外，以下工作以品牌运营为主进行决策，亚马逊运营同步即可：\n\n- JOYHUB 内推广\n- 社媒互动\n- 新品宣发\n- 活动宣发\n- 粉丝互动管理\n- 销售管理\n- 独立站推广\n- 新品推广\n- 社媒数据\n- KOL 互动数据\n\n#### 4.7.1 品牌推广协同数据\n\n| 字段 | 说明 |\n|---|---|\n| 推广计划 ID | 品牌推广计划唯一标识 |\n| 推广类型 | JOYHUB、社媒、新品宣发、活动宣发、KOL、独立站等 |\n| 产品名 | 关联产品 |\n| ASIN | 关联 ASIN |\n| 品牌 | 所属品牌 |\n| 国家 | 推广国家 |\n| 渠道 | 推广渠道 |\n| 曝光数 | 推广曝光 |\n| 点击数 | 推广点击 |\n| 跳转数 | 跳转到亚马逊或独立站的数量 |\n| 转化数 | 产生转化数量 |\n| 成交数 | 产生订单数量 |\n| 互动数 | 点赞、评论、私信、粉丝互动等 |\n| KOL 信息 | 合作达人或账号 |\n| 负责人 | 推广负责人 |\n\n## 5. 第二部分：品牌运营相关业务\n\n### 5.1 品牌运营在闭环中的定位\n\n品牌运营与亚马逊运营不在同一个办公区，但需要协助亚马逊运营共同建立销售体系。\n\n品牌运营的核心定位是：\n\n1. 负责独立站品牌宣发。\n2. 负责在社媒建立品牌形象。\n3. 负责独立站成交与品牌侧销售管理。\n4. 协助亚马逊运营在亚马逊平台上提高品牌调性。\n5. 协助亚马逊运营扩大品牌在亚马逊上的市场份额。\n6. 与亚马逊运营共同参与品牌推广计划。\n7. 在亚马逊站外品牌推广相关事项上，品牌运营为主责决策方，亚马逊运营同步。\n\n### 5.2 品牌运营与亚马逊运营的分工边界\n\n| 业务事项 | 主责方 | 协同方 | 说明 |\n|---|---|---|---|\n| 亚马逊站内销售 | 亚马逊运营 | 品牌运营 | 品牌运营协助提高品牌调性和市场份额 |\n| 亚马逊站内品牌承接 | 亚马逊运营 | 品牌运营 | Listing、品牌内容、品牌调性需要双方协同 |\n| 独立站品牌宣发 | 品牌运营 | 亚马逊运营同步 | 独立站推广和转化由品牌运营主责 |\n| 独立站成交 | 品牌运营 | 亚马逊运营同步 | 独立站销售数由品牌运营负责 |\n| 社媒品牌形象 | 品牌运营 | 亚马逊运营同步 | 包含账号内容、互动、粉丝维护 |\n| JOYHUB 内推广 | 品牌运营 | 亚马逊运营同步 | 实际为品牌运营工作，亚马逊运营了解进度 |\n| 新品宣发 | 品牌运营 | 亚马逊运营同步 | 站外宣发主责在品牌运营 |\n| 活动宣发 | 品牌运营 | 亚马逊运营同步 | 活动口径需要与销售节奏同步 |\n| 粉丝互动管理 | 品牌运营 | 亚马逊运营同步 | 社媒与品牌用户关系维护 |\n| KOL 互动 | 品牌运营 | 亚马逊运营同步 | KOL 数据和互动效果由品牌运营负责 |\n| AMZ 测评计划 | 亚马逊运营、用户运营 | 品牌运营协同 | 亚马逊运营提需求，用户运营实现，品牌运营参与协同 |\n| 回评计划 | 亚马逊运营、用户运营 | 品牌运营协同 | 主要服务 ASIN 评价健康度 |\n\n### 5.3 品牌运营核心业务模块\n\n| 模块 | 业务内容 | 输出 |\n|---|---|---|\n| 品牌宣发 | 独立站、社媒、JOYHUB、新品、活动等品牌曝光 | 品牌推广计划、宣发内容、渠道效果 |\n| 社媒运营 | 建立品牌形象、粉丝互动、社媒内容发布 | 社媒访问、点击、互动、转化数据 |\n| 独立站推广 | 独立站访问、点击、转化、成交管理 | 独立站销售数、转化漏斗 |\n| 新品推广 | 新品宣发、站外曝光、内容传播 | 新品推广数据、用户兴趣数据 |\n| 活动推广 | 活动宣发、活动页面、粉丝触达 | 活动曝光、点击、转化、成交 |\n| KOL 合作 | KOL 互动、达人合作、内容发布 | KOL 互动数据、访问与转化效果 |\n| 品牌销售管理 | 独立站成交、品牌侧销售数据管理 | 销售数、成交数、转化数 |\n| 亚马逊协同 | 协助亚马逊提升品牌调性和市场份额 | 品牌素材、推广节奏、协同反馈 |\n\n### 5.4 独立看板五：品牌影响力与独立站销售看板\n\n#### 5.4.1 看板目标\n\n用于衡量品牌运营在独立站、社媒、JOYHUB、KOL、新品宣发和活动宣发等渠道中的影响力、转化效果和销售结果。\n\n该看板以品牌运营为主责，亚马逊运营同步查看，用于判断站外品牌推广对亚马逊销售和独立站销售的辅助效果。\n\n#### 5.4.2 字段规划\n\n| 字段 | 说明 |\n|---|---|\n| 品牌 | 所属品牌 |\n| 国家 | 推广国家或市场 |\n| 渠道来源 | 独立站、社媒、JOYHUB、KOL、新品宣发、活动宣发等 |\n| 推广类型 | 新品、活动、日常内容、KOL、粉丝互动等 |\n| 产品名 | 关联产品 |\n| ASIN | 如有关联亚马逊产品，则记录 ASIN |\n| 负责人 | 品牌运营负责人 |\n| 访问数 | 各来源访问量 |\n| 点击数 | 各来源点击量 |\n| 转化数 | 各来源转化数量 |\n| 销售数 | 独立站或品牌侧销售数量，由品牌运营负责 |\n| 成交数 | 实际成交订单数量 |\n| 互动数 | 点赞、评论、分享、私信、粉丝互动等 |\n| KOL 信息 | 合作达人或账号信息 |\n| 内容/活动 ID | 关联内容、活动或投放任务 |\n| 跳转目标 | 亚马逊、独立站、APP、活动页等 |\n| 数据周期 | 日、周、月、活动周期 |\n\n#### 5.4.3 核心指标\n\n- 访问数\n- 点击数\n- 转化数\n- 销售数\n- 成交数\n- 社媒互动数\n- KOL 互动数据\n- 独立站转化率\n- 渠道访问贡献\n- 品牌活动转化效果\n\n#### 5.4.4 品牌影响力评估口径\n\n品牌影响力从两方面评估：\n\n1. 各渠道转化，包括独立站转化、亚马逊跳转转化、APP 承接转化等。\n2. 社媒影响力与调研反馈，包括互动、评论、粉丝反馈和品牌认知反馈。\n\n通过品牌活动前往亚马逊形成的转化，也归属品牌运营 OKR 结果。\n\n### 5.5 独立看板六：品牌推广计划协同看板\n\n#### 5.5.1 看板目标\n\n用于管理品牌运营与亚马逊运营共同参与的品牌推广计划。\n\n该看板需要明确：\n\n- 品牌运营在站外推广中的主责地位\n- 亚马逊运营在亚马逊站内承接品牌调性与销售转化的职责\n- 品牌推广与亚马逊销售、独立站销售、APP 用户增长之间的关系\n- 品牌推广计划与 AMZ 测评计划之间的协同关系\n\n#### 5.5.2 字段规划\n\n| 字段 | 说明 |\n|---|---|\n| 推广计划 ID | 品牌推广计划唯一标识 |\n| 推广计划名称 | 计划名称 |\n| 主责部门 | 品牌运营 |\n| 协同部门 | 亚马逊运营、用户运营、内容运营等 |\n| 推广类型 | JOYHUB、社媒、新品宣发、活动宣发、KOL、独立站等 |\n| 品牌 | 所属品牌 |\n| 国家 | 推广国家 |\n| 产品名 | 关联产品 |\n| ASIN | 关联亚马逊 ASIN |\n| 独立站链接 | 独立站承接地址 |\n| 亚马逊链接 | 亚马逊承接地址 |\n| APP 承接方式 | 是否需要 APP 内承接、推送或活动页 |\n| 计划开始时间 | 推广开始时间 |\n| 计划结束时间 | 推广结束时间 |\n| 预算 | 推广预算 |\n| 访问数 | 推广访问量 |\n| 点击数 | 推广点击量 |\n| 转化数 | 推广转化数量 |\n| 销售数 | 品牌侧销售数量 |\n| 成交数 | 实际成交订单 |\n| 亚马逊同步状态 | 未同步、已同步、需调整 |\n| 计划状态 | 草稿、待确认、执行中、已结束、暂停 |\n\n### 5.6 品牌运营参与 AMZ 测评计划的协作关系\n\nAMZ 测评计划由三方协作完成：\n\n| 角色 | 职责 |\n|---|---|\n| 亚马逊运营 | 根据亚马逊平台销售需求提出测评计划、回评计划、关键词和产品优先级需求 |\n| 品牌运营 | 理解并同步亚马逊运营需求，协同亚马逊运营与用户运营对接 |\n| 用户运营 | 负责实际实现，包括用户触达、推送、登记、索评、回评跟进和结果反馈 |\n\n需要明确的是：\n\n- 测评计划和回评计划的主要协作方是亚马逊运营与用户运营。\n- 品牌运营参与协同，但不是实际落地执行主责方。\n- 品牌运营的核心主责仍然是品牌宣发、社媒品牌形象、独立站成交和站外推广管理。\n\n### 5.7 APP 内资源协同边界\n\n| 资源类型 | 管理分配方 | 品牌运营角色 |\n|---|---|---|\n| APP 内社区资源 | 内容运营分配，品牌运营与内容运营协同 | 将亚马逊运营和品牌运营需求与内容运营协商 |\n| 用户推送资源 | 用户运营管理分配 | 将亚马逊运营和品牌运营需求与用户运营协商 |\n\n品牌运营熟悉内容运营和用户运营两侧资源，负责把亚马逊运营需求和品牌运营自身需求同步给相关部门，并推动协商解决。\n\n### 5.8 品牌运营与其他部门的数据关系\n\n| 数据流向 | 内容 | 用途 |\n|---|---|---|\n| 品牌运营 → 亚马逊运营 | 品牌推广计划、社媒/KOL 数据、新品宣发节奏、活动宣发数据 | 帮助亚马逊站内承接品牌调性和销售转化 |\n| 亚马逊运营 → 品牌运营 | 亚马逊销售需求、重点 ASIN、推新节奏、测评需求、关键词方向 | 品牌运营理解销售重点并做站外协同 |\n| 品牌运营 → 用户运营 | 推广计划、活动节奏、需要 APP 承接的用户触达需求 | APP 内推送、活动承接、用户触达 |\n| 用户运营 → 品牌运营 | APP 用户反馈、触达数据、活动参与、评价反馈 | 优化品牌内容和活动策略 |\n| 品牌运营 → 数据层/管理层 | 访问、点击、转化、销售数、互动数、KOL 数据 | 品牌影响力、渠道 ROI、独立站销售复盘 |\n\n## 6. 第三部分：用户运营相关业务\n\n### 6.1 用户运营在闭环中的定位\n\n用户运营是该系统的核心使用者。客服部门实际也归属用户部门管理。\n\n用户运营的核心定位是：\n\n1. 接收亚马逊运营与品牌运营协同后的销售数据和测评需求。\n2. 根据关键词、销量、产品重要级、ASIN 评价健康度共同制定可执行的测评计划。\n3. 基于 APP 用户、绑定用户、活跃用户、社区用户、非 APP 或低活跃用户进行分层触达。\n4. 在社区中与用户互动，鼓励测评人参与。\n5. 负责推送、登记、索评、回评跟进和结果回收。\n6. 按 ASIN 评价健康度动态调整触达资源和回评节奏。\n7. 管理 TEL、EDM、KOC/KOL/PR、短信、社区、非评价推送等多渠道触达。\n8. 管理客服售后相关执行数据，并将售后反馈纳入触达策略优化。\n\n### 6.2 用户运营核心业务模块\n\n| 模块 | 业务内容 | 输出 |\n|---|---|---|\n| 测评计划执行 | 根据亚马逊销售需求、关键词、销量、产品重要级制定可执行测评计划 | 推送计划、登记数据、评价数、计划完成度 |\n| 用户社区互动 | 在 APP 社区中与用户互动，鼓励用户参与新玩具测评 | 回复数、登记数、评价数 |\n| 回评计划跟进 | 根据 ASIN 评价健康度跟进回评目标 | 回评完成度、风险等级、ASIN 健康状态 |\n| IM 社区消息推送 | 推动新玩具购买与买后索评 | 曝光、点击、回复、登记、出评 |\n| 已成交索评 | 针对已绑定、已购买玩具的用户进行索评 | 实际回评数、评价等级改善 |\n| TEL 电话售后 | 接听售后和呼出电话 | 接听售后数据、呼出数据、售后原因 |\n| EDM 邮件推送 | 针对非 APP 或低 APP 活跃用户进行邮件触达 | 打开、点击、回复、转化 |\n| KOC/KOL/PR 合作 | 通过 JOYCOLLAB 网站管理合作伙伴体系 | 合作伙伴效果、带货链接、销售与提成数据 |\n| 其他触达渠道 | 短信、社区、非评价推送等仍在搭建中的渠道 | 新增测评渠道、内容改善、用户反感度控制 |\n\n### 6.3 测评计划执行数据\n\n用户运营根据亚马逊运营和品牌运营协同后的需求，结合销售数据、关键词和销量生成可执行的测评计划。\n\n测评计划的关键是把“销售侧需求”转化为“用户侧可执行动作”。\n\n#### 6.3.1 字段规划\n\n| 字段 | 说明 |\n|---|---|\n| 产品名 | 关联产品 |\n| ASIN | 亚马逊 ASIN |\n| 产品重要级 | S 级、重点、普通等 |\n| 关键词 | 亚马逊运营提出的关键词方向 |\n| 推送方案 | 用户运营制定的触达策略 |\n| 推送 ID | 推送任务唯一标识 |\n| 关联图片点击率 | 推送图片或素材点击率 |\n| 产品绑定数 | 已绑定该产品的用户数 |\n| 总用户数 | 可触达用户总数 |\n| 当月活跃用户数 | 当月活跃用户规模 |\n| 当月活跃率 | 当月活跃用户数 / 总用户数 |\n| 推送数 | 实际推送数量 |\n| 曝光数 | 实际曝光数量 |\n| 点击数 | 实际点击数量 |\n| 回复数 | 用户回复数量 |\n| 登记数 | 用户报名、登记或确认参与数量 |\n| 评价数 | 最终产生的评价数量 |\n\n### 6.4 ASIN 评价健康度与回评计划\n\n用户运营需要根据随时更新的 Listing 健康状况和 ASIN 评价健康度跟进回评计划。\n\n核心原则：\n\n- 新品爆款周期需要与评价数量和评价等级匹配。\n- 新品和爆款原则上评价数量要多。\n- 新品和爆款的期望评价等级原则上应达到 4.8 以上。\n- 常规产品需要保障链接评价数和评分等级。\n- 回评计划需要区分新品、重点产品、清仓产品。\n\n#### 6.4.1 字段规划\n\n| 字段 | 说明 |\n|---|---|\n| ASIN | 亚马逊 ASIN |\n| 产品名 | 关联产品 |\n| 产品类型 | 新品、重点、清仓 |\n| 当月计划回评数 | 当月计划回评数量 |\n| 实际回评数 | 当月实际完成回评数量 |\n| 期望评价等级 | 目标评价等级 |\n| 实际评价等级 | 当前实际评价等级 |\n| 回评完成率 | 实际回评数 / 当月计划回评数 |\n| 风险等级 | 健康、关注、风险、严重风险 |\n| 跟进人 | 用户运营负责人 |\n\n### 6.5 独立看板七：IM 社区消息推送计划看板\n\n#### 6.5.1 业务场景\n\nIM 社区消息推送主要用于推动新玩具测评。\n\n当用户没有购买我们想推动的新玩具时，用户运营通过 IM 社区消息推送促使用户购买新玩具，并在购买后进行索评。\n\n#### 6.5.2 看板目标\n\n按地区、品牌、类目、策略观察不同推送计划的效果。\n\n#### 6.5.3 字段规划\n\n| 字段 | 说明 |\n|---|---|\n| 推送 ID | 推送任务唯一标识 |\n| 关联产品 | 推送关联产品 |\n| ASIN | 关联 ASIN |\n| 国家/地区 | 推送覆盖地区 |\n| 品牌 | 所属品牌 |\n| 类目 | 产品类目 |\n| 策略 | 推送策略 |\n| 曝光 | 推送曝光数 |\n| 点击 | 用户点击数 |\n| 回复 | 用户回复数 |\n| 登记 | 用户登记数 |\n| 出评 | 最终产生评价数 |\n| 转化率 | 出评或登记转化率 |\n| 计划完成度 | 实际完成 / 计划目标 |\n| 订单号 | 订单号，含亚马逊来源和独立站来源，涉密字段 |\n| 订单来源 | 亚马逊、独立站等 |\n| profile ID | 用户 Profile 标识，涉密字段 |\n| joyhub ID | JOYHUB 用户标识，涉密字段 |\n\n### 6.6 独立看板八：已成交索评与回评计划完成度看板\n\n#### 6.6.1 业务场景\n\n当用户已经绑定某个玩具时，APP 能识别用户购买了哪个玩具。用户运营可以针对已有玩具进行已成交索评。\n\n该看板与 ASIN 评价健康度直接关联，用于确保亚马逊链接健康。\n\n#### 6.6.2 字段规划\n\n| 字段 | 说明 |\n|---|---|\n| 产品类型 | 新品、重点、清仓 |\n| 产品名 | 关联产品 |\n| ASIN | 关联 ASIN |\n| 产品计划回评数 | 当前产品计划回评数量 |\n| 实际回评数 | 当前产品实际回评数量 |\n| 回评完成率 | 实际回评数 / 产品计划回评数 |\n| 当前 ASIN 评价等级 | 当前 ASIN 星级或评分 |\n| 风险等级 | 健康、关注、风险、严重风险 |\n| 负责人 | 用户运营负责人 |\n\n### 6.7 独立看板九：TEL 电话售后渠道看板\n\n#### 6.7.1 业务场景\n\nTEL 电话售后渠道包括接听售后和呼出电话，主要用于改善服务、收集售后问题、支撑索评和降低负面反馈。\n\n#### 6.7.2 字段规划\n\n| 字段 | 说明 |\n|---|---|\n| 电话号码 | 高度涉密字段 |\n| 国家 | 用户国家 |\n| 品牌 | 关联品牌 |\n| 产品 | 关联产品 |\n| 售后原因 | 用户咨询或售后原因 |\n| 呼出数 | 呼出电话数量 |\n| 接听数 | 接听电话数量 |\n| 订单号 | 涉密字段 |\n| 跟进人 | 客服或用户运营负责人 |\n| 处理状态 | 待处理、处理中、已完结、需升级 |\n\n### 6.8 独立看板十：EDM 邮件推送渠道看板\n\n#### 6.8.1 业务场景\n\nEDM 邮件推送主要面向非 APP 用户或低 APP 活跃用户，用于补充 APP 内推送触达能力。\n\n#### 6.8.2 看板目标\n\n用于持续改善 EDM 计划，包括邮件打开、点击、回复和转化效果。\n\n#### 6.8.3 字段规划\n\n| 字段 | 说明 |\n|---|---|\n| 国家 | 用户国家 |\n| 地区 | 用户地区 |\n| 邮件服务商 | 邮件服务商 |\n| 用户邮箱 | 高度涉密字段 |\n| USER ID | 非 APP 用户 ID |\n| 推送 ID | EDM 推送任务 ID |\n| 点击数 | 邮件点击数量 |\n| 打开数 | 邮件打开数量 |\n| 回复数 | 邮件回复数量 |\n| 转化数 | 由邮件触达带来的转化数量 |\n| 计划状态 | 草稿、执行中、已结束、异常 |\n\n### 6.9 独立看板十一：KOC/KOL/PR 合作伙伴效果看板\n\n#### 6.9.1 业务场景\n\nKOC、KOL、PR 渠道用于合作伙伴对接和带货推广。合作伙伴体系通过 JOYCOLLAB 网站承接。\n\nKOC 在 JOYCOLLAB 上的带货数据原则上先在 JOYCOLLAB 网站内处理，再同步到大用户后台。财务也会参与销售数据、提成数据和交易金额的核算或校验。\n\n#### 6.9.2 看板目标\n\n用于改善合作伙伴效果，观察合作伙伴在不同国家、平台、产品和带货链路上的实际贡献。\n\n#### 6.9.3 字段规划\n\n| 字段 | 说明 |\n|---|---|\n| 合作伙伴 ID | 合作伙伴唯一标识 |\n| 国家 | 合作伙伴所在国家 |\n| 姓名 | 合作伙伴姓名，涉密字段 |\n| 时间 | 合作或跟进时间 |\n| 平台 | 合作平台 |\n| 粉丝 | 粉丝数量或粉丝规模 |\n| 备注 | 合作备注 |\n| 跟进人 | 用户运营或合作伙伴负责人 |\n| 合作产品 | 合作推广产品 |\n| 带货链接 | 合作伙伴带货链接 |\n| 销售数据 | 通过带货链接产生的销售数据 |\n| 提成数据 | 合作伙伴提成数据，涉密字段 |\n| 交易金额 | 产生的交易金额 |\n\n### 6.10 其他触达渠道\n\n其他渠道包括：\n\n- 短信\n- 社区\n- 非评价推送\n\n这些渠道仍在搭建当中，目标包括：\n\n1. 继续增加测评渠道。\n2. 改善内容触达效果。\n3. 降低用户对高频推送、索评、活动通知的反感。\n4. 为非评价类推送沉淀策略，例如活动、内容、售后提醒、品牌互动。\n\n### 6.11 用户识别、黑名单与频控口径\n\n#### 6.11.1 用户识别主标识\n\n订单号和 JOYHUB ID 是用户索评与黑名单查询中的两个主要标识。\n\n订单号包括：\n\n- 亚马逊来源订单号\n- 独立站来源订单号\n\n当用户注册后，必然有 JOYHUB ID。 \n当用户提供订单号时，JOYHUB ID 和订单号建立关联。\n\nAPP 侧还会保留注册邮箱、用户基础 IP、设备号、用户行为数据等信息。订单号可以关联用户地址、姓名、用户名等信息。\n\n#### 6.11.2 邮箱、账号与风险关联\n\n注册用户的 JOYHUB ID 和邮箱必然关联。部分用户可能使用多个邮箱注册多个账号，每个账号都有独立 JOYHUB ID。\n\n系统需要通过 IP、设备号等信息做黑名单关联。关联后，多个账号可被认定为关联账号，或在后台被划入高度风险关联，并按单一用户处理。\n\n#### 6.11.3 多渠道统一频控\n\nTEL、EDM、IM、社区、短信等渠道需要统一控制触达频率，并统一了解对用户的骚扰程度，避免过于频繁触达导致用户反感。\n\n### 6.12 用户运营与其他部门的数据关系\n\n| 数据流向 | 内容 | 用途 |\n|---|---|---|\n| 亚马逊运营 → 用户运营 | 销售数据、关键词、重点产品、测评需求、回评目标、ASIN 健康状态 | 制定可执行测评计划和回评计划 |\n| 品牌运营 → 用户运营 | 品牌推广计划、活动节奏、站外触达需求、APP 承接需求 | 配合品牌推广进行 APP 内触达 |\n| 用户运营 → 亚马逊运营 | 推送效果、登记数、评价数、回评数、ASIN 风险反馈 | 调整测评计划、推新计划和评价健康策略 |\n| 用户运营 → 品牌运营 | 用户反馈、触达效果、活动参与、转化结果 | 优化品牌内容、活动和独立站推广 |\n| 用户运营 → 客服运营 | 待跟进用户、售后触达需求、负面反馈线索 | 电话售后、问题处理和服务改善 |\n| 客服运营 → 用户运营 | 接听售后数据、呼出数据、售后原因、处理结果 | 优化推送策略、索评节奏和用户分层 |\n| 用户运营 → 数据层/管理层 | 推送、登记、评价、回评、TEL、EDM、合作伙伴数据 | 复盘渠道效果、人效、成本和风险 |\n\n## 7. 第四部分：菲律宾客服相关业务\n\n### 7.1 菲律宾客服在闭环中的定位\n\n菲律宾客服直接接受用户运营指导工作。\n\n当亚马逊运营存在短期需求变动时，不直接绕过用户运营调整客服工作，而是通过用户运营转达和排期。这样可以保证测评计划、回评计划、售后触达、人员安排和成本统计在同一套用户运营口径下管理。\n\n菲律宾客服的核心定位是：\n\n1. 执行用户运营下发的评价、登记、回复、售后跟进等具体任务。\n2. 承接各渠道用户接待与基础沟通。\n3. 配合评价计划落地，提升评价转化和完结评价数。\n4. 反馈客服侧接待、登记、回复、完结情况。\n5. 支撑用户运营进行成本管理、人效管理和渠道效果复盘。\n\n### 7.2 核心指标\n\n| 指标 | 说明 |\n|---|---|\n| 客源 | 来自不同渠道的用户来源或待处理线索 |\n| 转化数 | 从接待、登记、回复到评价完成的转化数量 |\n| 转化率 | 评价转化数 / 客源或登记数 |\n| 节约成本 | 通过客服执行、人效提升、渠道优化节约的成本 |\n\n### 7.3 独立看板十二：菲律宾客服人员管理看板\n\n#### 7.3.1 看板目标\n\n用于管理菲律宾客服人员、出勤、每日工作量和各渠道执行情况。\n\n#### 7.3.2 字段规划\n\n| 字段 | 说明 |\n|---|---|\n| 人员 | 客服人员姓名或账号 |\n| 团队/组别 | 所属客服小组 |\n| 出勤 | 出勤状态、出勤天数或工时 |\n| 日期 | 工作日期 |\n| 渠道 | IM、TEL、EDM、社区、KOC/KOL/PR、其他 |\n| 接待数 | 当日接待用户数量 |\n| 登记数 | 当日登记数量 |\n| 回复数 | 当日回复数量 |\n| 每日评价数 | 当日产生评价数量 |\n| 完结评价数 | 当日完结评价数量，按各渠道统计 |\n| 待处理数 | 尚未处理或未完结任务数量 |\n| 负责人 | 用户运营或客服主管 |\n\n### 7.4 独立看板十三：菲律宾客服评价计划管理看板\n\n#### 7.4.1 看板目标\n\n用于跟踪菲律宾客服执行评价计划的过程和结果，重点观察客源、登记、回复、出评和计划完成度。\n\n#### 7.4.2 字段规划\n\n| 字段 | 说明 |\n|---|---|\n| 评价计划 ID | 关联测评或回评计划 |\n| 推送 ID | 关联用户运营推送任务 |\n| 产品名 | 关联产品 |\n| ASIN | 关联 ASIN |\n| 产品类型 | 新品、重点、清仓 |\n| 渠道 | IM、TEL、EDM、社区、其他 |\n| 客源数 | 进入客服处理池的用户数量 |\n| 接待数 | 客服实际接待数量 |\n| 登记数 | 用户登记或确认参与数量 |\n| 回复数 | 用户回复数量 |\n| 每日评价数 | 每日产生评价数量 |\n| 完结评价数 | 完成闭环的评价数量 |\n| 转化数 | 从客源到评价完成的转化数量 |\n| 转化率 | 转化数 / 客源数或登记数 |\n| 计划完成度 | 实际完成 / 计划目标 |\n| 跟进人 | 菲律宾客服人员 |\n| 指导人 | 用户运营负责人 |\n\n### 7.5 独立看板十四：菲律宾客服成本管理看板\n\n#### 7.5.1 看板目标\n\n用于管理菲律宾客服相关人力成本、财务表和成本节约效果。\n\n#### 7.5.2 字段规划\n\n| 字段 | 说明 |\n|---|---|\n| 人员 | 客服人员 |\n| 出勤 | 出勤天数或工时 |\n| 人力成本 | 人员工资、补贴或对应成本 |\n| 提成 | 如存在评价、转化或完结相关提成，则单独记录 |\n| 管理成本 | 管理、培训、工具等分摊成本 |\n| 完结评价数 | 该人员或团队完成评价数量 |\n| 单评成本 | 总成本 / 完结评价数 |\n| 转化数 | 产生的有效转化数量 |\n| 单转化成本 | 总成本 / 转化数 |\n| 节约成本 | 因流程改善、人效提升或渠道优化节约的成本 |\n| 财务表 | 人事或财务表关联记录 |\n\n### 7.6 菲律宾客服与其他部门的数据关系\n\n| 数据流向 | 内容 | 用途 |\n|---|---|---|\n| 用户运营 → 菲律宾客服 | 评价计划、待跟进用户、推送任务、短期需求变动、售后跟进要求 | 指导客服执行 |\n| 菲律宾客服 → 用户运营 | 出勤、接待、登记、回复、每日评价、完结评价数、售后反馈 | 用户运营复盘渠道效果、人效和计划完成情况 |\n| 亚马逊运营 → 用户运营 → 菲律宾客服 | 亚马逊运营短期测评、回评或售后需求变动 | 通过用户运营统一转达，避免执行口径混乱 |\n| 菲律宾客服 → 数据层/管理层 | 人员、人效、评价转化、成本、财务表数据 | 成本管理、绩效评估和管理复盘 |\n\n## 8. 第五部分：内容运营相关业务\n\n### 8.1 内容运营在闭环中的定位\n\n内容运营在当前以用户运营为核心的业务需求中，主要负责配合亚马逊运营与品牌运营，在销售前期为产品做宣发和社区内流量承接。\n\n内容运营的核心定位是：\n\n1. 配合亚马逊运营和品牌运营做产品售前宣发。\n2. 管理 APP 内广告资源，包括开屏、弹窗、文末、ME、评论末等位置。\n3. 在社区内配合用户 KOC/KCO 对接，支持产品内容传播和测评前期预热。\n4. 执行售前社区广告计划。\n5. 通过推流管理提升重点产品、重点帖子、活动内容的曝光和点击。\n6. 管理加权、新帖、固定位置和固定流量池资源。\n7. 监控曝光、点击、打开、跳转、成交和互动数据，并识别风险。\n\n### 8.2 内容运营核心业务模块\n\n| 模块 | 业务内容 | 输出 |\n|---|---|---|\n| 售前社区广告计划 | 配合产品上市、活动、测评计划做社区前期宣发 | 广告计划、曝光、点击、跳转、成交数据 |\n| APP 广告管理 | 管理开屏、弹窗、文末、ME、评论末等广告位 | 广告位排期、用户行为数据、转化数据 |\n| 推流管理 | 对帖子加权、新帖扶持、固定位置投放、固定流量池管理 | 帖子曝光、点击、打开、互动、风险数据 |\n| KOC/KCO 对接 | 在社区中与用户或内容参与者对接 | 内容互动、测评预热、社区反馈 |\n| 风险识别 | 识别异常用户、异常互动、内容风险或投流风险 | 风险标记、处理建议 |\n\n### 8.3 独立看板十五：APP 广告管理看板\n\n#### 8.3.1 看板目标\n\n用于管理 APP 内广告位资源，支撑亚马逊运营和品牌运营在销售前期进行产品宣发、活动宣发和售前社区触达。\n\n广告位包括：\n\n- 开屏\n- 弹窗\n- 文末\n- ME\n- 评论末\n\n#### 8.3.2 字段规划\n\n| 字段 | 说明 |\n|---|---|\n| 月份 | 月度统计周期 |\n| 日期 | 每日统计周期 |\n| 产品 | 关联产品 |\n| ASIN | 如关联亚马逊产品，则记录 ASIN |\n| 品牌 | 所属品牌 |\n| 国家/地区 | 投放国家或地区 |\n| 广告位 | 开屏、弹窗、文末、ME、评论末等 |\n| 绑定情况 | 产品绑定用户数、绑定率或绑定状态 |\n| 用户行为 | 浏览、点击、打开、跳转、互动、购买等行为 |\n| 性别 | 用户性别 |\n| 其他标记用户数 | 风险用户、重点用户、异常用户或其他业务标记用户数 |\n| 曝光 | 广告曝光数 |\n| 点击 | 广告点击数 |\n| 打开 | 广告打开数 |\n| 跳转 | 跳转到产品页、亚马逊、独立站、活动页或 APP 页面数量 |\n| 成交数 | 由广告触达带来的成交数量 |\n| 负责人 | 内容运营负责人 |\n\n#### 8.3.3 核心指标\n\n- 曝光数\n- 点击数\n- 打开数\n- 跳转数\n- 成交数\n- 点击率\n- 打开率\n- 跳转率\n- 成交转化率\n- 不同广告位效果对比\n\n### 8.4 独立看板十六：推流管理看板\n\n#### 8.4.1 看板目标\n\n用于管理社区内容推流，包括帖子加权、新帖推流、固定位置和固定流量池。\n\n该看板服务于售前社区广告计划，帮助重点产品和重点内容获得更稳定的曝光与互动。\n\n#### 8.4.2 推流动作\n\n| 动作 | 说明 |\n|---|---|\n| 加权 | 对重点帖子或产品内容增加推荐权重 |\n| 新帖 | 对新发布内容进行启动流量扶持 |\n| 固定位置 | 将内容投放到指定社区位置 |\n| 固定流量池管理 | 管理固定流量池分配和资源占用 |\n\n#### 8.4.3 字段规划\n\n| 字段 | 说明 |\n|---|---|\n| 帖子 ID | 社区帖子唯一标识 |\n| 产品 | 关联产品 |\n| ASIN | 如关联亚马逊产品，则记录 ASIN |\n| 品牌 | 所属品牌 |\n| 发帖人属性 | 发帖人身份、用户类型、KOC/KCO、普通用户等 |\n| 帖子周期 | 新帖期、加权期、稳定期、结束期等 |\n| 投流等级 | 投流优先级或资源等级 |\n| 流量等级 | 实际分配的流量层级 |\n| 固定位置 | 是否使用固定位置及位置名称 |\n| 固定流量池 | 是否占用固定流量池及流量池名称 |\n| 曝光 | 帖子曝光数 |\n| 点击 | 帖子点击数 |\n| 打开 | 帖子打开数 |\n| 互动数 | 点赞、评论、收藏、分享、回复等互动总数 |\n| 各互动数 | 各类型互动明细 |\n| 风险 | 内容风险、用户风险、异常互动或投流风险 |\n| 负责人 | 内容运营负责人 |\n\n### 8.5 内容运营与其他部门的数据关系\n\n| 数据流向 | 内容 | 用途 |\n|---|---|---|\n| 亚马逊运营 → 内容运营 | 重点产品、ASIN、推新节奏、售前宣发需求、测评前期需求 | 安排社区广告和推流资源 |\n| 品牌运营 → 内容运营 | 品牌推广计划、新品宣发、活动宣发、素材与口径 | 统一品牌内容和社区投放 |\n| 用户运营 → 内容运营 | 用户触达节奏、测评计划、用户反馈、频控要求 | 避免内容触达与用户推送冲突 |\n| 内容运营 → 亚马逊运营/品牌运营 | 广告曝光、点击、打开、跳转、成交、帖子互动、风险数据 | 复盘售前宣发效果和销售辅助效果 |\n| 内容运营 → 数据层/管理层 | APP 广告、推流、互动、风险、成交归因数据 | 管理社区资源效率和内容投流效果 |\n\n## 9. 亚马逊运营与其他部门的数据关系\n\n| 数据流向 | 内容 | 用途 |\n|---|---|---|\n| 亚马逊运营 → APP/用户运营 | 销量、订单、ASIN、产品、国家、站点、成交用户 | 绑定率计算、用户触达、索评 |\n| APP/用户运营 → 亚马逊运营 | 绑定数、绑定率、活跃用户、推送效果、评价结果 | Listing/说明书/官网优化，评价计划调整 |\n| 亚马逊运营 → 评价运营 | 重点产品、推新计划、测评计划、回评目标 | 制定评价数量和评分维护策略 |\n| 评价运营 → 亚马逊运营 | 实际评价数、回评数、评分、差评、ASIN 健康状态 | 判断链接健康度和销售风险 |\n| 客服运营 → 亚马逊运营 | 售后问题、负面反馈、用户投诉、问题类型 | 优化产品、Listing、说明书和售后策略 |\n| 品牌/内容运营 → 亚马逊运营 | 品牌推广、内容曝光、社媒/KOL 数据 | 辅助亚马逊销售转化和新品启动 |\n\n## 10. 已确认问题与业务口径\n\n| 编号 | 已确认口径 | 后续影响 |\n|---|---|---|\n| Q1 | 绑定率 = APP 可识别的绑定了指定玩具的用户数 / 销售数。 | 绑定率看板按产品和 ASIN 计算。 |\n| Q2 | 支持在权限控制下查看明细，明细需要具体到每个 ASIN。 | 需要做 ASIN 级权限和涉密销量明细权限。 |\n| Q3 | S、A 级重要性由公司领导约 2-3 人和亚马逊核心总监确认，由用户运营指定人员维护。 | 产品重要级需要维护入口、确认记录和变更日志。 |\n| Q4 | 推新先用基础规则，后续逐步引入模型。当前 S 级需求最大程度满足，约 50% 流量给核心 S 级产品，其余 A/B 等产品共享约 50% 流量。 | 推新算法一期用规则引擎，二期再考虑模型。 |\n| Q5 | 测评、回评、免评计划需要审批流。亚马逊运营提出计划，亚马逊运营总监审批确认。 | 需要建立计划审批状态、审批人和审批记录。 |\n| Q6 | 4.8 很健康，4.5 健康，4.2 高风险；4.2 时需要加强对未回评用户的回评推送。 | ASIN 健康看板需要按评分阈值报警。 |\n| Q7 | 用户提供订单号时进行关联。APP 有 JOYHUB ID、注册邮箱、基础 IP、设备号、用户行为数据等；订单号可关联用户地址、姓名、用户名等。 | 用户识别需要订单号 + JOYHUB ID 双主标识，并保留辅助识别信息。 |\n| Q8 | 品牌影响力核心从两方面评估：各渠道转化、社媒影响力与调研反馈。 | 品牌看板需要同时支持转化数据和影响力反馈数据。 |\n| Q9 | 通过品牌活动前往亚马逊形成的转化，也归属品牌运营 OKR 结果。 | 销售归因需要支持品牌活动到亚马逊转化。 |\n| Q10 | APP 内社区资源由品牌运营与内容运营协同、内容运营分配；用户推送资源由用户运营管理分配。品牌运营负责将亚马逊和品牌需求与内容运营、用户运营协商解决。 | 资源排期需要区分社区资源和用户推送资源。 |\n| Q11 | 需要逐步根据亚马逊平台算法，把关键词需求、GEO 需求同步到测评计划中，综合销量、重要级、突发事件生成建议计划，再调动 IM、EDM、电话、KOC、KOL 等渠道。 | 后续需要计划生成引擎和多渠道资源调度。 |\n| Q12 | 订单号和 JOYHUB ID 是两个主要标识。订单号包括亚马逊来源和独立站来源。用户注册后必然有 JOYHUB ID，提供订单号后两者关联。 | 修正字段为“订单号”，不再使用 OA 订单号。 |\n| Q13 | 各渠道需要统一控制频率，并统一了解对用户的骚扰程度，避免过于频繁。 | 需要建设跨渠道频控和用户反感度监控。 |\n| Q14 | 注册用户的 JOYHUB ID 和邮箱必然关联；多个邮箱多账号可通过 IP、设备号等做黑名单关联，后台可按单一用户处理。 | 需要账号关联、黑名单和高风险关联用户机制。 |\n| Q15 | JOYCOLLAB 和财务都会参与。原则上 KOC 在 JOYCOLLAB 上的带货数据在网站内处理后同步到大用户后台。 | KOC/KOL/PR 看板需要支持 JOYCOLLAB 同步和财务核算校验。 |\n\n## 11. 进入项目规划前的系统设计问题\n\n当前业务链条已经基本清晰，可以进入项目规划与系统模块拆分。进入 ERP 系统设计前，需要把以下问题作为系统设计约束统一管理。\n\n### 11.1 角色权限\n\n需要明确不同角色的数据可见范围、操作权限和审批权限。\n\n重点问题：\n\n- 谁能查看销售明细？\n- 谁能查看用户邮箱、电话、订单号、地址、姓名等高度涉密字段？\n- 谁能审批、修改、暂停测评计划、回评计划、免评计划？\n- 菲律宾客服能看到哪些用户字段？\n- 内容运营能看到哪些用户行为和成交归因字段？\n\n### 11.2 计划流程状态\n\n测评、回评、免评、推送、内容投流、客服任务都需要统一状态流。\n\n建议基础状态：\n\n- 草稿\n- 待审批\n- 已审批\n- 执行中\n- 暂停\n- 异常\n- 已完成\n- 已复盘\n\n### 11.3 数据来源\n\n需要在系统层面明确每类数据的来源、同步方式、刷新频率和权限等级。\n\n| 数据类型 | 可能来源 |\n|---|---|\n| 亚马逊销量/订单 | 亚马逊运营数据源、导入表、API 或报表 |\n| 独立站订单 | 独立站系统 |\n| APP 绑定 | JOYHUB/APP 用户系统 |\n| 用户资料 | JOYHUB ID、注册邮箱、IP、设备号、用户行为数据 |\n| EDM 数据 | 邮件服务商 |\n| TEL 数据 | 电话系统或客服登记 |\n| JOYCOLLAB 数据 | JOYCOLLAB 网站 |\n| 财务/人事数据 | 财务表、人事表、成本表 |\n| 内容广告数据 | APP 广告位、社区内容系统 |\n\n### 11.4 核心业务对象\n\n后续建系统时，至少需要统一以下核心对象：\n\n- 用户\n- 订单\n- 产品\n- ASIN\n- 品牌\n- 国家/站点\n- 推送计划\n- 测评计划\n- 回评计划\n- 免评计划\n- 内容投流计划\n- 广告位\n- 客服任务\n- 合作伙伴\n- 成本记录\n- 风险用户/黑名单\n\n### 11.5 计划生成规则\n\n推新和测评计划一期建议先采用规则引擎，后续再逐步引入模型。\n\n仍需继续细化：\n\n- S/A/B 级产品资源比例是否固定，还是允许人工调整？\n- 突发事件如何插队？\n- 一个用户多久不能被重复触达？\n- 一个 ASIN 高风险时是否自动提升优先级？\n- GEO 需求如何进入计划生成？\n- 关键词需求如何与用户池匹配？\n\n### 11.6 评价健康报警\n\n评分阈值已经初步明确，但还需要补充数量类和进度类报警。\n\n待细化：\n\n- 回评数低于计划多少算异常？\n- 新品多少天内必须达到多少评价？\n- 差评率达到多少触发客服或用户运营介入？\n- ASIN 评分下降多少需要升级？\n- 评价健康报警是否自动触发回评推送计划？\n\n### 11.7 成本口径\n\n成本口径需要统一，否则无法做真实 ROI 和人效复盘。\n\n待细化：\n\n- 单评成本如何计算？\n- 返现成本是否纳入单评成本？\n- 菲律宾客服人力成本如何分摊到产品、ASIN、计划？\n- KOC/KOL 提成如何归因到订单？\n- 管理成本如何分摊？\n\n### 11.8 归因规则\n\n多渠道触达一定会发生交叉，归因规则需要系统化。\n\n典型场景：\n\n用户先看到 APP 内容广告，再收到 EDM，最后通过亚马逊购买。\n\n待确定：\n\n- 采用首触归因、末触归因、主要贡献渠道，还是多渠道权重归因？\n- 品牌活动到亚马逊成交如何归因？\n- 内容广告和用户推送都参与时如何拆分贡献？\n- KOC/KOL 带货链接与后续 APP 触达如何处理归因冲突？\n\n### 11.9 黑名单与风险用户处理\n\n黑名单与风险用户需要成为系统基础能力。\n\n待细化：\n\n- 谁能加入黑名单？\n- 黑名单是否影响推送、返现、测评资格？\n- 高风险用户是否允许客服继续跟进？\n- 多账号关联后是否自动合并为单一风险用户？\n- 黑名单查询是否支持订单号和 JOYHUB ID 双入口？\n\n### 11.10 一期项目边界建议\n\n一期不宜追求一次性覆盖所有 ERP 能力，应优先建设评价业务闭环的主干。\n\n建议一期优先：\n\n1. 产品/ASIN 看板\n2. 测评计划、回评计划、免评计划审批流\n3. 用户推送计划\n4. ASIN 评价健康看板\n5. 菲律宾客服执行看板\n6. 基础权限与涉密字段控制\n7. 基础数据导入和统一主键\n\n后续二期及以后再逐步扩展模型化计划生成、多渠道归因、复杂成本核算、内容广告优化、JOYCOLLAB 深度集成和管理层经营分析。\n\n## 12. 修改记录\n\n| 版本 | 日期 | 修改内容 | 记录人 |\n|---|---|---|---|\n| v0.7 | 2026-04-26 | 将业务链条确认后的系统设计问题写入文档；补充角色权限、计划状态流、数据来源、核心业务对象、计划生成规则、评价健康报警、成本口径、归因规则、黑名单与风险用户处理和一期项目边界建议。 | Codex |\n| v0.6 | 2026-04-26 | 追加内容运营相关业务；明确内容运营配合亚马逊运营与品牌运营进行销售前期宣发、售前社区广告计划和社区 KOC/KCO 对接；新增 APP 广告管理看板和推流管理看板，覆盖开屏、弹窗、文末、ME、评论末、加权、新帖、固定位置、固定流量池、用户行为、互动与风险字段。 | Codex |\n| v0.5 | 2026-04-26 | 追加菲律宾客服相关业务；明确菲律宾客服直接接受用户运营指导，亚马逊运营短期需求变动通过用户运营转达；新增核心指标客源、转化数、转化率、节约成本；新增人员管理、评价计划管理、成本管理三个看板及字段；补充菲律宾客服与用户运营、亚马逊运营、数据层/管理层的数据关系。 | Codex |\n| v0.4 | 2026-04-26 | 回答并固化 Q1-Q15 业务口径；明确绑定率公式、ASIN 明细权限、产品重要级确认与维护、推新资源规则、测评/回评/免评审批流、ASIN 评价健康阈值、订单号与 JOYHUB ID 双主标识、品牌影响力评估、品牌活动归因、APP 社区与用户推送资源边界、测评计划建议生成方向、跨渠道频控、黑名单关联和 JOYCOLLAB/财务数据来源。 | Codex |\n| v0.3 | 2026-04-26 | 追加用户运营相关业务；明确用户运营为系统核心使用者，客服部门归属用户部门管理；新增测评计划执行、ASIN 评价健康与回评计划、IM 社区消息推送、已成交索评、TEL 电话售后、EDM 邮件推送、KOC/KOL/PR 合作伙伴、其他触达渠道等模块；新增用户运营与其他部门的数据关系和待确认问题。 | Codex |\n| v0.2 | 2026-04-26 | 追加品牌运营相关业务；明确品牌运营与亚马逊运营不在同一办公区但共同建立销售体系；修正品牌推广计划归属为品牌运营主责、亚马逊运营同步；明确 AMZ 测评计划由亚马逊运营提需求、品牌运营协同、用户运营实际实现；新增品牌影响力与独立站销售看板、品牌推广计划协同看板、品牌运营数据关系和待确认问题。 | Codex |\n| v0.1 | 2026-04-26 | 建立评价业务流闭环项目架构文档；整理总体业务闭环、基础指标、亚马逊运营相关业务；新增销量与绑定率看板、推新计划与 APP 推送资源分配看板、测评与免评计划看板、回评计划与 ASIN 评价健康度看板、品牌推广协同数据和待确认问题。 | Codex |\n", + "wikilinks": [], + "category": "layer-requirements" + } + }, + { + "id": "doc:05_需求文档/user_erp_mvp_admin_prototype_v10(1)", + "type": "document", + "name": "USER 后台 ERP MVP · 管理员总览原型 v10", + "filePath": "05_需求文档/user_erp_mvp_admin_prototype_v10(1).html", + "summary": "USER 后台 ERP MVP · 管理员总览原型 v10 JOYHUB Ops 模拟数据 第一期模拟 数据 当前模块 经营总览 系统管理员最高权限视图 常用跳转 21 重要事项 3 审核类 4 字段关系 5 问题总结 9 经营总览 系统管理员 · 最高权限 · 全部部门 搜索 至 日 周 月 全部部门 Amazon 运营 用户运营 客服 系统管理员（最高权", + "tags": [ + "05_需求文档", + "需求文档" + ], + "complexity": "complex", + "knowledgeMeta": { + "content": "\n\n\n \n \n USER 后台 ERP MVP · 管理员总览原型 v10\n \n\n\n
\n \n\n
\n
\n
\n
\n 经营总览\n 系统管理员 · 最高权限 · 全部部门\n
\n
\n 搜索\n \n
\n
\n
\n
\n \n 至\n \n
\n
\n \n \n \n
\n \n \n \n
\n
\n\n
\n
\n
\n\n
\n \n\n
\n
\n
\n

操作确认

\n \n
\n
\n
\n
\n\n
\n\n \n\n\n", + "wikilinks": [], + "category": "layer-requirements" + } + }, + { + "id": "doc:05_需求文档/user_erp_mvp_admin_prototype_v10", + "type": "document", + "name": "USER 后台 ERP MVP · 管理员总览原型 v10", + "filePath": "05_需求文档/user_erp_mvp_admin_prototype_v10.html", + "summary": "USER 后台 ERP MVP · 管理员总览原型 v10 JOYHUB Ops 💬 3 IM 消息 当前模块 经营总览 系统管理员最高权限视图 常用跳转 21 重要事项 3 审核类 4 字段关系 5 问题总结 9 经营总览 系统管理员 · 最高权限 · 全部部门 搜索 至 日 周 月 全部部门 Amazon 运营 用户运营 客服 系统管理员（最高权限） ", + "tags": [ + "05_需求文档", + "需求文档" + ], + "complexity": "complex", + "knowledgeMeta": { + "content": "\n\n\n \n \n USER 后台 ERP MVP · 管理员总览原型 v10\n \n\n\n
\n \n\n
\n
\n
\n
\n 经营总览\n 系统管理员 · 最高权限 · 全部部门\n
\n
\n 搜索\n \n
\n
\n
\n
\n \n 至\n \n
\n
\n \n \n \n
\n \n \n \n
\n
\n\n
\n
\n
\n\n
\n \n\n
\n
\n
\n

操作确认

\n \n
\n
\n
\n
\n\n
\n\n
\n \n\n \n\n\n", + "wikilinks": [], + "category": "layer-requirements" + } + }, + { + "id": "doc:05_需求文档/客服执行", + "type": "document", + "name": "客服执行看板", + "filePath": "05_需求文档/客服执行.html", + "summary": "客服执行看板", + "tags": [ + "05_需求文档", + "需求文档" + ], + "complexity": "complex", + "knowledgeMeta": { + "content": "\n\n \n \n \n 客服执行看板\n \n \n \n
\n \n \n\r\n", + "wikilinks": [], + "category": "layer-requirements" + } + }, + { + "id": "doc:05_需求文档/用户运营系统-单文件", + "type": "document", + "name": "USER评价业务闭环系统", + "filePath": "05_需求文档/用户运营系统-单文件.html", + "summary": "USER评价业务闭环系统", + "tags": [ + "05_需求文档", + "需求文档" + ], + "complexity": "complex", + "knowledgeMeta": { + "content": "\n\n \n \n \n USER评价业务闭环系统\n \n \n \n \n
\n \n\n", + "wikilinks": [ + "10,15", + "^\\", + "^\\", + "^\\", + "^\\", + "3,9", + "r,n", + "1,0", + "1,\"rgba(207,212,219,0.2)\"", + "\"rect\"", + "e", + "0,0", + "t,t", + "o.x,o.y", + "s.x,s.y", + "1,\"#E6EBF8\"" + ], + "category": "layer-requirements" + } + } + ], + "edges": [ + { + "source": "flow:layer-overview", + "target": "flow:layer-requirements", + "type": "documents", + "direction": "forward", + "description": "知识库主流程", + "weight": 1 + }, + { + "source": "flow:layer-requirements", + "target": "flow:layer-milestones", + "type": "documents", + "direction": "forward", + "description": "知识库主流程", + "weight": 1 + }, + { + "source": "flow:layer-milestones", + "target": "flow:layer-technical", + "type": "documents", + "direction": "forward", + "description": "知识库主流程", + "weight": 1 + }, + { + "source": "flow:layer-technical", + "target": "flow:layer-testing", + "type": "documents", + "direction": "forward", + "description": "知识库主流程", + "weight": 1 + }, + { + "source": "flow:layer-testing", + "target": "flow:layer-agent", + "type": "documents", + "direction": "forward", + "description": "知识库主流程", + "weight": 1 + }, + { + "source": "flow:layer-overview", + "target": "doc:00_首页/Agent问答入口", + "type": "documents", + "direction": "forward", + "description": "本层文档", + "weight": 0.65 + }, + { + "source": "flow:layer-overview", + "target": "doc:00_首页/知识地图", + "type": "documents", + "direction": "forward", + "description": "本层文档", + "weight": 0.65 + }, + { + "source": "flow:layer-overview", + "target": "doc:00_首页/知识库首页", + "type": "documents", + "direction": "forward", + "description": "本层文档", + "weight": 0.65 + }, + { + "source": "flow:layer-overview", + "target": "doc:欢迎", + "type": "documents", + "direction": "forward", + "description": "本层文档", + "weight": 0.65 + }, + { + "source": "flow:layer-overview", + "target": "doc:知识库使用说明", + "type": "documents", + "direction": "forward", + "description": "本层文档", + "weight": 0.65 + }, + { + "source": "flow:layer-requirements", + "target": "doc:05_需求文档/20260517_USER评价业务闭环_第三步_数据流与中间对象设计_v3", + "type": "documents", + "direction": "forward", + "description": "本层文档", + "weight": 0.65 + }, + { + "source": "flow:layer-requirements", + "target": "doc:05_需求文档/README", + "type": "documents", + "direction": "forward", + "description": "本层文档", + "weight": 0.65 + }, + { + "source": "flow:layer-requirements", + "target": "doc:05_需求文档/需求文档索引", + "type": "documents", + "direction": "forward", + "description": "本层文档", + "weight": 0.65 + }, + { + "source": "flow:layer-milestones", + "target": "doc:02_项目管理流程/AI驱动内部系统开发流程_V3_总览", + "type": "documents", + "direction": "forward", + "description": "本层文档", + "weight": 0.65 + }, + { + "source": "flow:layer-milestones", + "target": "doc:02_项目管理流程/README", + "type": "documents", + "direction": "forward", + "description": "本层文档", + "weight": 0.65 + }, + { + "source": "flow:layer-milestones", + "target": "doc:02_项目管理流程/常见问题FAQ", + "type": "documents", + "direction": "forward", + "description": "本层文档", + "weight": 0.65 + }, + { + "source": "flow:layer-milestones", + "target": "doc:02_项目管理流程/角色职责矩阵", + "type": "documents", + "direction": "forward", + "description": "本层文档", + "weight": 0.65 + }, + { + "source": "flow:layer-milestones", + "target": "doc:02_项目管理流程/阶段0_项目入口分级", + "type": "documents", + "direction": "forward", + "description": "本层文档", + "weight": 0.65 + }, + { + "source": "flow:layer-milestones", + "target": "doc:02_项目管理流程/阶段1_业务需求完整形成", + "type": "documents", + "direction": "forward", + "description": "本层文档", + "weight": 0.65 + }, + { + "source": "flow:layer-milestones", + "target": "doc:02_项目管理流程/阶段2.5_测试提前补漏", + "type": "documents", + "direction": "forward", + "description": "本层文档", + "weight": 0.65 + }, + { + "source": "flow:layer-milestones", + "target": "doc:02_项目管理流程/阶段2_高保真模型与业务对象确认", + "type": "documents", + "direction": "forward", + "description": "本层文档", + "weight": 0.65 + }, + { + "source": "flow:layer-milestones", + "target": "doc:02_项目管理流程/阶段3_研发协作与正式开发", + "type": "documents", + "direction": "forward", + "description": "本层文档", + "weight": 0.65 + }, + { + "source": "flow:layer-milestones", + "target": "doc:02_项目管理流程/阶段4_测试培训上线回流", + "type": "documents", + "direction": "forward", + "description": "本层文档", + "weight": 0.65 + }, + { + "source": "flow:layer-milestones", + "target": "doc:02_项目管理流程/阶段交付物清单", + "type": "documents", + "direction": "forward", + "description": "本层文档", + "weight": 0.65 + }, + { + "source": "flow:layer-milestones", + "target": "doc:02_项目管理流程/项目检查清单", + "type": "documents", + "direction": "forward", + "description": "本层文档", + "weight": 0.65 + }, + { + "source": "flow:layer-milestones", + "target": "doc:06_里程碑/README", + "type": "documents", + "direction": "forward", + "description": "本层文档", + "weight": 0.65 + }, + { + "source": "flow:layer-milestones", + "target": "doc:06_里程碑/里程碑索引", + "type": "documents", + "direction": "forward", + "description": "本层文档", + "weight": 0.65 + }, + { + "source": "flow:layer-milestones", + "target": "doc:06_里程碑/里程碑评审记录", + "type": "documents", + "direction": "forward", + "description": "本层文档", + "weight": 0.65 + }, + { + "source": "flow:layer-milestones", + "target": "doc:06_里程碑/阶段计划模板", + "type": "documents", + "direction": "forward", + "description": "本层文档", + "weight": 0.65 + }, + { + "source": "flow:layer-technical", + "target": "doc:07_技术文档/README", + "type": "documents", + "direction": "forward", + "description": "本层文档", + "weight": 0.65 + }, + { + "source": "flow:layer-technical", + "target": "doc:07_技术文档/技术决策记录", + "type": "documents", + "direction": "forward", + "description": "本层文档", + "weight": 0.65 + }, + { + "source": "flow:layer-technical", + "target": "doc:07_技术文档/技术文档索引", + "type": "documents", + "direction": "forward", + "description": "本层文档", + "weight": 0.65 + }, + { + "source": "flow:layer-technical", + "target": "doc:07_技术文档/接口说明模板", + "type": "documents", + "direction": "forward", + "description": "本层文档", + "weight": 0.65 + }, + { + "source": "flow:layer-technical", + "target": "doc:07_技术文档/系统架构说明模板", + "type": "documents", + "direction": "forward", + "description": "本层文档", + "weight": 0.65 + }, + { + "source": "flow:layer-testing", + "target": "doc:08_测试相关/README", + "type": "documents", + "direction": "forward", + "description": "本层文档", + "weight": 0.65 + }, + { + "source": "flow:layer-testing", + "target": "doc:08_测试相关/上线检查模板", + "type": "documents", + "direction": "forward", + "description": "本层文档", + "weight": 0.65 + }, + { + "source": "flow:layer-testing", + "target": "doc:08_测试相关/测试用例模板", + "type": "documents", + "direction": "forward", + "description": "本层文档", + "weight": 0.65 + }, + { + "source": "flow:layer-testing", + "target": "doc:08_测试相关/测试用例索引", + "type": "documents", + "direction": "forward", + "description": "本层文档", + "weight": 0.65 + }, + { + "source": "flow:layer-testing", + "target": "doc:08_测试相关/测试计划模板", + "type": "documents", + "direction": "forward", + "description": "本层文档", + "weight": 0.65 + }, + { + "source": "flow:layer-testing", + "target": "doc:08_测试相关/缺陷记录模板", + "type": "documents", + "direction": "forward", + "description": "本层文档", + "weight": 0.65 + }, + { + "source": "flow:layer-testing", + "target": "doc:08_测试相关/验收记录模板", + "type": "documents", + "direction": "forward", + "description": "本层文档", + "weight": 0.65 + }, + { + "source": "flow:layer-agent", + "target": "doc:04_Agent检索/关键词索引", + "type": "documents", + "direction": "forward", + "description": "本层文档", + "weight": 0.65 + }, + { + "source": "flow:layer-agent", + "target": "doc:04_Agent检索/同义词表", + "type": "documents", + "direction": "forward", + "description": "本层文档", + "weight": 0.65 + }, + { + "source": "flow:layer-agent", + "target": "doc:04_Agent检索/来源文件索引", + "type": "documents", + "direction": "forward", + "description": "本层文档", + "weight": 0.65 + }, + { + "source": "flow:layer-agent", + "target": "doc:04_Agent检索/检索说明", + "type": "documents", + "direction": "forward", + "description": "本层文档", + "weight": 0.65 + }, + { + "source": "flow:layer-agent", + "target": "doc:04_Agent检索/知识库持续更新与验证流程", + "type": "documents", + "direction": "forward", + "description": "本层文档", + "weight": 0.65 + }, + { + "source": "flow:layer-agent", + "target": "doc:04_Agent检索/问答提示词", + "type": "documents", + "direction": "forward", + "description": "本层文档", + "weight": 0.65 + }, + { + "source": "doc:04_Agent检索/知识库持续更新与验证流程", + "target": "doc:00_首页/Agent问答入口", + "type": "depends_on", + "direction": "forward", + "description": "文档引用关系", + "weight": 0.7 + }, + { + "source": "doc:05_需求文档/需求文档索引", + "target": "doc:00_首页/Agent问答入口", + "type": "depends_on", + "direction": "forward", + "description": "文档引用关系", + "weight": 0.7 + }, + { + "source": "doc:08_测试相关/测试用例索引", + "target": "doc:00_首页/Agent问答入口", + "type": "depends_on", + "direction": "forward", + "description": "文档引用关系", + "weight": 0.7 + }, + { + "source": "doc:02_项目管理流程/AI驱动内部系统开发流程_V3_总览", + "target": "doc:04_Agent检索/关键词索引", + "type": "depends_on", + "direction": "forward", + "description": "文档引用关系", + "weight": 0.7 + }, + { + "source": "doc:02_项目管理流程/角色职责矩阵", + "target": "doc:04_Agent检索/关键词索引", + "type": "depends_on", + "direction": "forward", + "description": "文档引用关系", + "weight": 0.7 + }, + { + "source": "doc:02_项目管理流程/阶段0_项目入口分级", + "target": "doc:04_Agent检索/关键词索引", + "type": "depends_on", + "direction": "forward", + "description": "文档引用关系", + "weight": 0.7 + }, + { + "source": "doc:02_项目管理流程/阶段1_业务需求完整形成", + "target": "doc:04_Agent检索/关键词索引", + "type": "depends_on", + "direction": "forward", + "description": "文档引用关系", + "weight": 0.7 + }, + { + "source": "doc:02_项目管理流程/阶段2.5_测试提前补漏", + "target": "doc:04_Agent检索/关键词索引", + "type": "depends_on", + "direction": "forward", + "description": "文档引用关系", + "weight": 0.7 + }, + { + "source": "doc:02_项目管理流程/阶段2_高保真模型与业务对象确认", + "target": "doc:04_Agent检索/关键词索引", + "type": "depends_on", + "direction": "forward", + "description": "文档引用关系", + "weight": 0.7 + }, + { + "source": "doc:02_项目管理流程/阶段3_研发协作与正式开发", + "target": "doc:04_Agent检索/关键词索引", + "type": "depends_on", + "direction": "forward", + "description": "文档引用关系", + "weight": 0.7 + }, + { + "source": "doc:02_项目管理流程/阶段4_测试培训上线回流", + "target": "doc:04_Agent检索/关键词索引", + "type": "depends_on", + "direction": "forward", + "description": "文档引用关系", + "weight": 0.7 + }, + { + "source": "doc:02_项目管理流程/阶段交付物清单", + "target": "doc:04_Agent检索/关键词索引", + "type": "depends_on", + "direction": "forward", + "description": "文档引用关系", + "weight": 0.7 + }, + { + "source": "doc:02_项目管理流程/项目检查清单", + "target": "doc:04_Agent检索/关键词索引", + "type": "depends_on", + "direction": "forward", + "description": "文档引用关系", + "weight": 0.7 + }, + { + "source": "doc:04_Agent检索/知识库持续更新与验证流程", + "target": "doc:04_Agent检索/关键词索引", + "type": "depends_on", + "direction": "forward", + "description": "文档引用关系", + "weight": 0.7 + }, + { + "source": "doc:02_项目管理流程/角色职责矩阵", + "target": "doc:04_Agent检索/同义词表", + "type": "depends_on", + "direction": "forward", + "description": "文档引用关系", + "weight": 0.7 + }, + { + "source": "doc:02_项目管理流程/阶段0_项目入口分级", + "target": "doc:04_Agent检索/同义词表", + "type": "depends_on", + "direction": "forward", + "description": "文档引用关系", + "weight": 0.7 + }, + { + "source": "doc:02_项目管理流程/阶段1_业务需求完整形成", + "target": "doc:04_Agent检索/同义词表", + "type": "depends_on", + "direction": "forward", + "description": "文档引用关系", + "weight": 0.7 + }, + { + "source": "doc:02_项目管理流程/阶段2.5_测试提前补漏", + "target": "doc:04_Agent检索/同义词表", + "type": "depends_on", + "direction": "forward", + "description": "文档引用关系", + "weight": 0.7 + }, + { + "source": "doc:02_项目管理流程/阶段2_高保真模型与业务对象确认", + "target": "doc:04_Agent检索/同义词表", + "type": "depends_on", + "direction": "forward", + "description": "文档引用关系", + "weight": 0.7 + }, + { + "source": "doc:02_项目管理流程/阶段3_研发协作与正式开发", + "target": "doc:04_Agent检索/同义词表", + "type": "depends_on", + "direction": "forward", + "description": "文档引用关系", + "weight": 0.7 + }, + { + "source": "doc:02_项目管理流程/阶段4_测试培训上线回流", + "target": "doc:04_Agent检索/同义词表", + "type": "depends_on", + "direction": "forward", + "description": "文档引用关系", + "weight": 0.7 + }, + { + "source": "doc:02_项目管理流程/阶段交付物清单", + "target": "doc:04_Agent检索/同义词表", + "type": "depends_on", + "direction": "forward", + "description": "文档引用关系", + "weight": 0.7 + }, + { + "source": "doc:02_项目管理流程/项目检查清单", + "target": "doc:04_Agent检索/同义词表", + "type": "depends_on", + "direction": "forward", + "description": "文档引用关系", + "weight": 0.7 + }, + { + "source": "doc:04_Agent检索/知识库持续更新与验证流程", + "target": "doc:04_Agent检索/同义词表", + "type": "depends_on", + "direction": "forward", + "description": "文档引用关系", + "weight": 0.7 + }, + { + "source": "doc:02_项目管理流程/AI驱动内部系统开发流程_V3_总览", + "target": "doc:04_Agent检索/来源文件索引", + "type": "depends_on", + "direction": "forward", + "description": "文档引用关系", + "weight": 0.7 + }, + { + "source": "doc:02_项目管理流程/常见问题FAQ", + "target": "doc:04_Agent检索/来源文件索引", + "type": "depends_on", + "direction": "forward", + "description": "文档引用关系", + "weight": 0.7 + }, + { + "source": "doc:02_项目管理流程/角色职责矩阵", + "target": "doc:04_Agent检索/来源文件索引", + "type": "depends_on", + "direction": "forward", + "description": "文档引用关系", + "weight": 0.7 + }, + { + "source": "doc:02_项目管理流程/阶段0_项目入口分级", + "target": "doc:04_Agent检索/来源文件索引", + "type": "depends_on", + "direction": "forward", + "description": "文档引用关系", + "weight": 0.7 + }, + { + "source": "doc:02_项目管理流程/阶段1_业务需求完整形成", + "target": "doc:04_Agent检索/来源文件索引", + "type": "depends_on", + "direction": "forward", + "description": "文档引用关系", + "weight": 0.7 + }, + { + "source": "doc:02_项目管理流程/阶段2.5_测试提前补漏", + "target": "doc:04_Agent检索/来源文件索引", + "type": "depends_on", + "direction": "forward", + "description": "文档引用关系", + "weight": 0.7 + }, + { + "source": "doc:02_项目管理流程/阶段2_高保真模型与业务对象确认", + "target": "doc:04_Agent检索/来源文件索引", + "type": "depends_on", + "direction": "forward", + "description": "文档引用关系", + "weight": 0.7 + }, + { + "source": "doc:02_项目管理流程/阶段3_研发协作与正式开发", + "target": "doc:04_Agent检索/来源文件索引", + "type": "depends_on", + "direction": "forward", + "description": "文档引用关系", + "weight": 0.7 + }, + { + "source": "doc:02_项目管理流程/阶段4_测试培训上线回流", + "target": "doc:04_Agent检索/来源文件索引", + "type": "depends_on", + "direction": "forward", + "description": "文档引用关系", + "weight": 0.7 + }, + { + "source": "doc:02_项目管理流程/阶段交付物清单", + "target": "doc:04_Agent检索/来源文件索引", + "type": "depends_on", + "direction": "forward", + "description": "文档引用关系", + "weight": 0.7 + }, + { + "source": "doc:02_项目管理流程/项目检查清单", + "target": "doc:04_Agent检索/来源文件索引", + "type": "depends_on", + "direction": "forward", + "description": "文档引用关系", + "weight": 0.7 + }, + { + "source": "doc:04_Agent检索/知识库持续更新与验证流程", + "target": "doc:04_Agent检索/来源文件索引", + "type": "depends_on", + "direction": "forward", + "description": "文档引用关系", + "weight": 0.7 + }, + { + "source": "doc:05_需求文档/需求文档索引", + "target": "doc:04_Agent检索/来源文件索引", + "type": "depends_on", + "direction": "forward", + "description": "文档引用关系", + "weight": 0.7 + }, + { + "source": "doc:02_项目管理流程/AI驱动内部系统开发流程_V3_总览", + "target": "doc:04_Agent检索/检索说明", + "type": "depends_on", + "direction": "forward", + "description": "文档引用关系", + "weight": 0.7 + }, + { + "source": "doc:02_项目管理流程/常见问题FAQ", + "target": "doc:04_Agent检索/检索说明", + "type": "depends_on", + "direction": "forward", + "description": "文档引用关系", + "weight": 0.7 + }, + { + "source": "doc:02_项目管理流程/角色职责矩阵", + "target": "doc:04_Agent检索/检索说明", + "type": "depends_on", + "direction": "forward", + "description": "文档引用关系", + "weight": 0.7 + }, + { + "source": "doc:02_项目管理流程/阶段2.5_测试提前补漏", + "target": "doc:04_Agent检索/检索说明", + "type": "depends_on", + "direction": "forward", + "description": "文档引用关系", + "weight": 0.7 + }, + { + "source": "doc:02_项目管理流程/阶段2_高保真模型与业务对象确认", + "target": "doc:04_Agent检索/检索说明", + "type": "depends_on", + "direction": "forward", + "description": "文档引用关系", + "weight": 0.7 + }, + { + "source": "doc:02_项目管理流程/阶段交付物清单", + "target": "doc:04_Agent检索/检索说明", + "type": "depends_on", + "direction": "forward", + "description": "文档引用关系", + "weight": 0.7 + }, + { + "source": "doc:02_项目管理流程/项目检查清单", + "target": "doc:04_Agent检索/检索说明", + "type": "depends_on", + "direction": "forward", + "description": "文档引用关系", + "weight": 0.7 + }, + { + "source": "doc:04_Agent检索/关键词索引", + "target": "doc:04_Agent检索/检索说明", + "type": "depends_on", + "direction": "forward", + "description": "文档引用关系", + "weight": 0.7 + }, + { + "source": "doc:04_Agent检索/同义词表", + "target": "doc:04_Agent检索/检索说明", + "type": "depends_on", + "direction": "forward", + "description": "文档引用关系", + "weight": 0.7 + }, + { + "source": "doc:05_需求文档/需求文档索引", + "target": "doc:04_Agent检索/检索说明", + "type": "depends_on", + "direction": "forward", + "description": "文档引用关系", + "weight": 0.7 + }, + { + "source": "doc:06_里程碑/里程碑索引", + "target": "doc:04_Agent检索/检索说明", + "type": "depends_on", + "direction": "forward", + "description": "文档引用关系", + "weight": 0.7 + }, + { + "source": "doc:07_技术文档/技术文档索引", + "target": "doc:04_Agent检索/检索说明", + "type": "depends_on", + "direction": "forward", + "description": "文档引用关系", + "weight": 0.7 + }, + { + "source": "doc:07_技术文档/接口说明模板", + "target": "doc:04_Agent检索/检索说明", + "type": "depends_on", + "direction": "forward", + "description": "文档引用关系", + "weight": 0.7 + }, + { + "source": "doc:08_测试相关/上线检查模板", + "target": "doc:04_Agent检索/检索说明", + "type": "depends_on", + "direction": "forward", + "description": "文档引用关系", + "weight": 0.7 + }, + { + "source": "doc:08_测试相关/测试用例索引", + "target": "doc:04_Agent检索/检索说明", + "type": "depends_on", + "direction": "forward", + "description": "文档引用关系", + "weight": 0.7 + }, + { + "source": "doc:08_测试相关/缺陷记录模板", + "target": "doc:04_Agent检索/检索说明", + "type": "depends_on", + "direction": "forward", + "description": "文档引用关系", + "weight": 0.7 + }, + { + "source": "doc:08_测试相关/验收记录模板", + "target": "doc:04_Agent检索/检索说明", + "type": "depends_on", + "direction": "forward", + "description": "文档引用关系", + "weight": 0.7 + }, + { + "source": "doc:04_Agent检索/关键词索引", + "target": "doc:04_Agent检索/知识库持续更新与验证流程", + "type": "depends_on", + "direction": "forward", + "description": "文档引用关系", + "weight": 0.7 + }, + { + "source": "doc:04_Agent检索/同义词表", + "target": "doc:04_Agent检索/知识库持续更新与验证流程", + "type": "depends_on", + "direction": "forward", + "description": "文档引用关系", + "weight": 0.7 + }, + { + "source": "doc:04_Agent检索/来源文件索引", + "target": "doc:04_Agent检索/知识库持续更新与验证流程", + "type": "depends_on", + "direction": "forward", + "description": "文档引用关系", + "weight": 0.7 + }, + { + "source": "doc:05_需求文档/需求文档索引", + "target": "doc:04_Agent检索/知识库持续更新与验证流程", + "type": "depends_on", + "direction": "forward", + "description": "文档引用关系", + "weight": 0.7 + }, + { + "source": "doc:02_项目管理流程/角色职责矩阵", + "target": "doc:04_Agent检索/问答提示词", + "type": "depends_on", + "direction": "forward", + "description": "文档引用关系", + "weight": 0.7 + }, + { + "source": "doc:02_项目管理流程/阶段交付物清单", + "target": "doc:04_Agent检索/问答提示词", + "type": "depends_on", + "direction": "forward", + "description": "文档引用关系", + "weight": 0.7 + }, + { + "source": "doc:02_项目管理流程/项目检查清单", + "target": "doc:04_Agent检索/问答提示词", + "type": "depends_on", + "direction": "forward", + "description": "文档引用关系", + "weight": 0.7 + }, + { + "source": "doc:04_Agent检索/关键词索引", + "target": "doc:05_需求文档/README", + "type": "depends_on", + "direction": "forward", + "description": "文档引用关系", + "weight": 0.7 + }, + { + "source": "doc:04_Agent检索/同义词表", + "target": "doc:05_需求文档/README", + "type": "depends_on", + "direction": "forward", + "description": "文档引用关系", + "weight": 0.7 + }, + { + "source": "doc:04_Agent检索/来源文件索引", + "target": "doc:05_需求文档/README", + "type": "depends_on", + "direction": "forward", + "description": "文档引用关系", + "weight": 0.7 + }, + { + "source": "doc:04_Agent检索/知识库持续更新与验证流程", + "target": "doc:05_需求文档/README", + "type": "depends_on", + "direction": "forward", + "description": "文档引用关系", + "weight": 0.7 + }, + { + "source": "doc:05_需求文档/需求文档索引", + "target": "doc:05_需求文档/README", + "type": "depends_on", + "direction": "forward", + "description": "文档引用关系", + "weight": 0.7 + }, + { + "source": "doc:00_首页/知识地图", + "target": "doc:知识库使用说明", + "type": "depends_on", + "direction": "forward", + "description": "文档引用关系", + "weight": 0.7 + }, + { + "source": "doc:02_项目管理流程/README", + "target": "doc:知识库使用说明", + "type": "depends_on", + "direction": "forward", + "description": "文档引用关系", + "weight": 0.7 + }, + { + "source": "doc:02_项目管理流程/阶段交付物清单", + "target": "doc:知识库使用说明", + "type": "depends_on", + "direction": "forward", + "description": "文档引用关系", + "weight": 0.7 + }, + { + "source": "doc:02_项目管理流程/项目检查清单", + "target": "doc:知识库使用说明", + "type": "depends_on", + "direction": "forward", + "description": "文档引用关系", + "weight": 0.7 + }, + { + "source": "doc:04_Agent检索/来源文件索引", + "target": "doc:知识库使用说明", + "type": "depends_on", + "direction": "forward", + "description": "文档引用关系", + "weight": 0.7 + }, + { + "source": "doc:04_Agent检索/检索说明", + "target": "doc:知识库使用说明", + "type": "depends_on", + "direction": "forward", + "description": "文档引用关系", + "weight": 0.7 + }, + { + "source": "doc:05_需求文档/README", + "target": "doc:知识库使用说明", + "type": "depends_on", + "direction": "forward", + "description": "文档引用关系", + "weight": 0.7 + }, + { + "source": "doc:05_需求文档/需求文档索引", + "target": "doc:知识库使用说明", + "type": "depends_on", + "direction": "forward", + "description": "文档引用关系", + "weight": 0.7 + }, + { + "source": "doc:06_里程碑/README", + "target": "doc:知识库使用说明", + "type": "depends_on", + "direction": "forward", + "description": "文档引用关系", + "weight": 0.7 + }, + { + "source": "doc:06_里程碑/里程碑索引", + "target": "doc:知识库使用说明", + "type": "depends_on", + "direction": "forward", + "description": "文档引用关系", + "weight": 0.7 + }, + { + "source": "doc:07_技术文档/README", + "target": "doc:知识库使用说明", + "type": "depends_on", + "direction": "forward", + "description": "文档引用关系", + "weight": 0.7 + }, + { + "source": "doc:07_技术文档/技术文档索引", + "target": "doc:知识库使用说明", + "type": "depends_on", + "direction": "forward", + "description": "文档引用关系", + "weight": 0.7 + }, + { + "source": "doc:08_测试相关/README", + "target": "doc:知识库使用说明", + "type": "depends_on", + "direction": "forward", + "description": "文档引用关系", + "weight": 0.7 + }, + { + "source": "doc:08_测试相关/上线检查模板", + "target": "doc:知识库使用说明", + "type": "depends_on", + "direction": "forward", + "description": "文档引用关系", + "weight": 0.7 + }, + { + "source": "doc:08_测试相关/测试用例索引", + "target": "doc:知识库使用说明", + "type": "depends_on", + "direction": "forward", + "description": "文档引用关系", + "weight": 0.7 + }, + { + "source": "doc:08_测试相关/缺陷记录模板", + "target": "doc:知识库使用说明", + "type": "depends_on", + "direction": "forward", + "description": "文档引用关系", + "weight": 0.7 + }, + { + "source": "doc:欢迎", + "target": "doc:知识库使用说明", + "type": "depends_on", + "direction": "forward", + "description": "文档引用关系", + "weight": 0.7 + }, + { + "source": "flow:layer-requirements", + "target": "doc:05_需求文档/00-系统总览", + "type": "documents", + "direction": "forward", + "description": "本层文档", + "weight": 0.65 + }, + { + "source": "flow:layer-requirements", + "target": "doc:05_需求文档/01-子系统-用户身份与上下文", + "type": "documents", + "direction": "forward", + "description": "本层文档", + "weight": 0.65 + }, + { + "source": "flow:layer-requirements", + "target": "doc:05_需求文档/02-子系统-需求与计划管理", + "type": "documents", + "direction": "forward", + "description": "本层文档", + "weight": 0.65 + }, + { + "source": "flow:layer-requirements", + "target": "doc:05_需求文档/03-子系统-额度与频控", + "type": "documents", + "direction": "forward", + "description": "本层文档", + "weight": 0.65 + }, + { + "source": "flow:layer-requirements", + "target": "doc:05_需求文档/04-子系统-多渠道触达引擎", + "type": "documents", + "direction": "forward", + "description": "本层文档", + "weight": 0.65 + }, + { + "source": "flow:layer-requirements", + "target": "doc:05_需求文档/05-子系统-客服工单与管理", + "type": "documents", + "direction": "forward", + "description": "本层文档", + "weight": 0.65 + }, + { + "source": "flow:layer-requirements", + "target": "doc:05_需求文档/06-子系统-风险与反欺诈", + "type": "documents", + "direction": "forward", + "description": "本层文档", + "weight": 0.65 + }, + { + "source": "flow:layer-requirements", + "target": "doc:05_需求文档/07-子系统-评价结果追踪", + "type": "documents", + "direction": "forward", + "description": "本层文档", + "weight": 0.65 + }, + { + "source": "flow:layer-requirements", + "target": "doc:05_需求文档/08-子系统-KOC-KOL协作", + "type": "documents", + "direction": "forward", + "description": "本层文档", + "weight": 0.65 + }, + { + "source": "flow:layer-requirements", + "target": "doc:05_需求文档/09-子系统-审计与通知中心", + "type": "documents", + "direction": "forward", + "description": "本层文档", + "weight": 0.65 + }, + { + "source": "flow:layer-requirements", + "target": "doc:05_需求文档/20260504_USER后台ERP_MVP管理员首页高保真原型_v7", + "type": "documents", + "direction": "forward", + "description": "本层文档", + "weight": 0.65 + }, + { + "source": "flow:layer-requirements", + "target": "doc:05_需求文档/20260517_USER评价业务闭环_共用能力图与渠道专属流程_v2.2", + "type": "documents", + "direction": "forward", + "description": "本层文档", + "weight": 0.65 + }, + { + "source": "flow:layer-requirements", + "target": "doc:05_需求文档/20260517_USER评价业务闭环主流程与后续工作基线_v1.2", + "type": "documents", + "direction": "forward", + "description": "本层文档", + "weight": 0.65 + }, + { + "source": "flow:layer-requirements", + "target": "doc:05_需求文档/evaluation-business-architecture", + "type": "documents", + "direction": "forward", + "description": "本层文档", + "weight": 0.65 + }, + { + "source": "flow:layer-requirements", + "target": "doc:05_需求文档/user_erp_mvp_admin_prototype_v10(1)", + "type": "documents", + "direction": "forward", + "description": "本层文档", + "weight": 0.65 + }, + { + "source": "flow:layer-requirements", + "target": "doc:05_需求文档/user_erp_mvp_admin_prototype_v10", + "type": "documents", + "direction": "forward", + "description": "本层文档", + "weight": 0.65 + }, + { + "source": "flow:layer-requirements", + "target": "doc:05_需求文档/客服执行", + "type": "documents", + "direction": "forward", + "description": "本层文档", + "weight": 0.65 + }, + { + "source": "flow:layer-requirements", + "target": "doc:05_需求文档/用户运营系统-单文件", + "type": "documents", + "direction": "forward", + "description": "本层文档", + "weight": 0.65 + } + ], + "layers": [ + { + "id": "layer-overview", + "name": "知识库入口", + "description": "知识库使用说明、首页、知识地图和问答入口。先从这里理解知识库结构与检索方式。", + "nodeIds": [ + "flow:layer-overview", + "doc:00_首页/Agent问答入口", + "doc:00_首页/知识地图", + "doc:00_首页/知识库首页", + "doc:欢迎", + "doc:知识库使用说明" + ] + }, + { + "id": "layer-requirements", + "name": "需求文档", + "description": "所有正式需求、业务规则、需求变更和需求索引。点击本层可查看全部需求文档并检索。", + "nodeIds": [ + "flow:layer-requirements", + "doc:05_需求文档/20260517_USER评价业务闭环_第三步_数据流与中间对象设计_v3", + "doc:05_需求文档/README", + "doc:05_需求文档/需求文档索引", + "doc:05_需求文档/00-系统总览", + "doc:05_需求文档/01-子系统-用户身份与上下文", + "doc:05_需求文档/02-子系统-需求与计划管理", + "doc:05_需求文档/03-子系统-额度与频控", + "doc:05_需求文档/04-子系统-多渠道触达引擎", + "doc:05_需求文档/05-子系统-客服工单与管理", + "doc:05_需求文档/06-子系统-风险与反欺诈", + "doc:05_需求文档/07-子系统-评价结果追踪", + "doc:05_需求文档/08-子系统-KOC-KOL协作", + "doc:05_需求文档/09-子系统-审计与通知中心", + "doc:05_需求文档/20260504_USER后台ERP_MVP管理员首页高保真原型_v7", + "doc:05_需求文档/20260517_USER评价业务闭环_共用能力图与渠道专属流程_v2.2", + "doc:05_需求文档/20260517_USER评价业务闭环主流程与后续工作基线_v1.2", + "doc:05_需求文档/evaluation-business-architecture", + "doc:05_需求文档/user_erp_mvp_admin_prototype_v10(1)", + "doc:05_需求文档/user_erp_mvp_admin_prototype_v10", + "doc:05_需求文档/客服执行", + "doc:05_需求文档/用户运营系统-单文件" + ] + }, + { + "id": "layer-milestones", + "name": "里程碑", + "description": "项目阶段计划、里程碑节点、评审记录、准入准出和交付物节奏。", + "nodeIds": [ + "flow:layer-milestones", + "doc:02_项目管理流程/AI驱动内部系统开发流程_V3_总览", + "doc:02_项目管理流程/README", + "doc:02_项目管理流程/常见问题FAQ", + "doc:02_项目管理流程/角色职责矩阵", + "doc:02_项目管理流程/阶段0_项目入口分级", + "doc:02_项目管理流程/阶段1_业务需求完整形成", + "doc:02_项目管理流程/阶段2.5_测试提前补漏", + "doc:02_项目管理流程/阶段2_高保真模型与业务对象确认", + "doc:02_项目管理流程/阶段3_研发协作与正式开发", + "doc:02_项目管理流程/阶段4_测试培训上线回流", + "doc:02_项目管理流程/阶段交付物清单", + "doc:02_项目管理流程/项目检查清单", + "doc:06_里程碑/README", + "doc:06_里程碑/里程碑索引", + "doc:06_里程碑/里程碑评审记录", + "doc:06_里程碑/阶段计划模板" + ] + }, + { + "id": "layer-technical", + "name": "技术文档", + "description": "系统架构、数据模型、接口说明、技术方案和技术决策。", + "nodeIds": [ + "flow:layer-technical", + "doc:07_技术文档/README", + "doc:07_技术文档/技术决策记录", + "doc:07_技术文档/技术文档索引", + "doc:07_技术文档/接口说明模板", + "doc:07_技术文档/系统架构说明模板" + ] + }, + { + "id": "layer-testing", + "name": "测试相关", + "description": "测试计划、测试用例、缺陷记录、验收记录和上线检查。", + "nodeIds": [ + "flow:layer-testing", + "doc:08_测试相关/README", + "doc:08_测试相关/上线检查模板", + "doc:08_测试相关/测试用例模板", + "doc:08_测试相关/测试用例索引", + "doc:08_测试相关/测试计划模板", + "doc:08_测试相关/缺陷记录模板", + "doc:08_测试相关/验收记录模板" + ] + }, + { + "id": "layer-agent", + "name": "Agent检索", + "description": "检索说明、关键词、同义词、来源索引和持续更新验证流程。", + "nodeIds": [ + "flow:layer-agent", + "doc:04_Agent检索/关键词索引", + "doc:04_Agent检索/同义词表", + "doc:04_Agent检索/来源文件索引", + "doc:04_Agent检索/检索说明", + "doc:04_Agent检索/知识库持续更新与验证流程", + "doc:04_Agent检索/问答提示词" + ] + } + ], + "tour": [ + { + "order": 1, + "title": "知识库入口", + "description": "知识库使用说明、首页、知识地图和问答入口。先从这里理解知识库结构与检索方式。", + "nodeIds": [ + "flow:layer-overview" + ] + }, + { + "order": 2, + "title": "需求文档", + "description": "所有正式需求、业务规则、需求变更和需求索引。点击本层可查看全部需求文档并检索。", + "nodeIds": [ + "flow:layer-requirements" + ] + }, + { + "order": 3, + "title": "里程碑", + "description": "项目阶段计划、里程碑节点、评审记录、准入准出和交付物节奏。", + "nodeIds": [ + "flow:layer-milestones" + ] + }, + { + "order": 4, + "title": "技术文档", + "description": "系统架构、数据模型、接口说明、技术方案和技术决策。", + "nodeIds": [ + "flow:layer-technical" + ] + }, + { + "order": 5, + "title": "测试相关", + "description": "测试计划、测试用例、缺陷记录、验收记录和上线检查。", + "nodeIds": [ + "flow:layer-testing" + ] + }, + { + "order": 6, + "title": "Agent检索", + "description": "检索说明、关键词、同义词、来源索引和持续更新验证流程。", + "nodeIds": [ + "flow:layer-agent" + ] + } + ] +} diff --git a/wishfulfilled-wiki/.understand-anything/meta.json b/wishfulfilled-wiki/.understand-anything/meta.json new file mode 100644 index 0000000..5fef6c4 --- /dev/null +++ b/wishfulfilled-wiki/.understand-anything/meta.json @@ -0,0 +1,10 @@ +{ + "lastAnalyzedAt": "2026-05-27T07:14:45.036Z", + "gitCommitHash": "", + "version": "1.0.0", + "analyzedFiles": 60, + "theme": { + "presetId": "dark", + "accentId": "cyan" + } +} diff --git a/wishfulfilled-wiki/00_首页/Agent问答入口.md b/wishfulfilled-wiki/00_首页/Agent问答入口.md new file mode 100644 index 0000000..6059169 --- /dev/null +++ b/wishfulfilled-wiki/00_首页/Agent问答入口.md @@ -0,0 +1,55 @@ +--- +type: agent_entry +tags: [Agent, 问答, 检索] +aliases: [问答入口, Agent入口] +source: manual +status: active +owner: 内部技术团队 +updated: 2026-05 +--- + +# Agent 问答入口 + +当用户询问业务或项目流程时，Agent 应先检索本知识库 Markdown 文件，再组织回答。 + +## 推荐检索顺序 + +1. `05_需求文档/`：持续新增的业务需求、业务规则、需求变更。 +2. `06_里程碑/`：项目节点、阶段计划、阶段评审、上线节奏。 +3. `07_技术文档/`：架构、接口、数据模型、实现方案、技术决策。 +4. `08_测试相关/`：测试计划、测试用例、缺陷、验收、上线检查。 +5. `02_项目管理流程/`：阶段、角色、交付物、门禁、检查清单。 +6. `01_业务流程/`：具体业务流程、业务对象、业务规则。 +7. `04_Agent检索/`：关键词、同义词、回答规则、来源索引。 +8. `03_规范与模板/`：需要产出文档或表单时检索。 + +## 回答格式 + +- 先给结论。 +- 再按阶段、负责人、输入、关键动作、输出、检查点说明。 +- 最后注明来源文件。 +- 若知识库没有明确记录，回答“知识库未明确记录”，并说明建议补充到哪个文件。 + +## 示例问题 + +- 一个内部系统需求从提出到上线要走哪些阶段？ +- 阶段2.5测试提前补漏要产出什么？ +- 业务主管在项目入口分级中负责什么？ +- 什么时候需要前端提前参与需求收敛？ +- 新增一条业务规则后，怎么验证 Agent 能搜到？ +- 某个业务规则应该补充到哪个模板里？ +- 某个需求对应哪些测试用例？ +- 某个模块有哪些接口说明？ +- 这个项目当前处在哪个里程碑？ + +## 业务补充验证入口 + +- 需求文档目录：`05_需求文档/` +- 里程碑目录：`06_里程碑/` +- 技术文档目录：`07_技术文档/` +- 测试相关目录：`08_测试相关/` +- 需求文档索引：`05_需求文档/需求文档索引.md` +- 测试用例索引：`08_测试相关/测试用例索引.md` +- 模板：`03_规范与模板/业务规则与需求补充模板.md` +- 流程：`04_Agent检索/知识库持续更新与验证流程.md` +- 记录：`01_业务流程/业务补充验证记录.md` diff --git a/wishfulfilled-wiki/00_首页/知识地图.md b/wishfulfilled-wiki/00_首页/知识地图.md new file mode 100644 index 0000000..f008c77 --- /dev/null +++ b/wishfulfilled-wiki/00_首页/知识地图.md @@ -0,0 +1,64 @@ +--- +type: map +tags: [知识地图, 导航] +aliases: [知识库地图] +source: manual +status: active +owner: 内部技术团队 +updated: 2026-05 +--- + +# 知识地图 + +## 使用说明 + +- [[../知识库使用说明|知识库使用说明]] +- [[../Git使用说明|Git 使用说明]] + +## 需求文档 + +- [[../05_需求文档/README|需求文档入口]] +- [[../05_需求文档/需求文档索引|需求文档索引]] +- [[../03_规范与模板/需求说明模板|需求说明模板]] +- [[../03_规范与模板/业务规则与需求补充模板|业务规则与需求补充模板]] +- [[../01_业务流程/业务规则索引|业务规则索引]] +- [[../01_业务流程/业务对象字典|业务对象字典]] + +## 里程碑 + +- [[../06_里程碑/README|里程碑入口]] +- [[../06_里程碑/里程碑索引|里程碑索引]] +- [[../06_里程碑/阶段计划模板|阶段计划模板]] +- [[../06_里程碑/里程碑评审记录|里程碑评审记录]] +- [[../02_项目管理流程/AI驱动内部系统开发流程_V3_总览|项目管理流程总览]] +- [[../02_项目管理流程/阶段交付物清单|阶段交付物清单]] +- [[../02_项目管理流程/项目检查清单|项目检查清单]] + +## 技术文档 + +- [[../07_技术文档/README|技术文档入口]] +- [[../07_技术文档/技术文档索引|技术文档索引]] +- [[../07_技术文档/系统架构说明模板|系统架构说明模板]] +- [[../07_技术文档/接口说明模板|接口说明模板]] +- [[../07_技术文档/技术决策记录|技术决策记录]] + +## 测试相关 + +- [[../08_测试相关/README|测试相关入口]] +- [[../08_测试相关/测试用例索引|测试用例索引]] +- [[../08_测试相关/测试用例模板|测试用例模板]] +- [[../08_测试相关/测试计划模板|测试计划模板]] +- [[../08_测试相关/缺陷记录模板|缺陷记录模板]] +- [[../08_测试相关/验收记录模板|验收记录模板]] +- [[../08_测试相关/上线检查模板|上线检查模板]] +- [[../02_项目管理流程/阶段2.5_测试提前补漏|阶段2.5 测试提前补漏]] +- [[../02_项目管理流程/阶段4_测试培训上线回流|阶段4 测试培训上线回流]] + +## Agent 检索 + +- [[../04_Agent检索/检索说明|检索说明]] +- [[../04_Agent检索/问答提示词|问答提示词]] +- [[../04_Agent检索/关键词索引|关键词索引]] +- [[../04_Agent检索/同义词表|同义词表]] +- [[../04_Agent检索/来源文件索引|来源文件索引]] +- [[../04_Agent检索/知识库持续更新与验证流程|持续更新与验证流程]] diff --git a/wishfulfilled-wiki/00_首页/知识库首页.md b/wishfulfilled-wiki/00_首页/知识库首页.md new file mode 100644 index 0000000..25d0e56 --- /dev/null +++ b/wishfulfilled-wiki/00_首页/知识库首页.md @@ -0,0 +1,38 @@ +--- +type: index +tags: [知识库, 首页, 如愿] +aliases: [如愿知识库首页, 知识库入口] +source: manual +status: active +owner: 内部技术团队 +updated: 2026-05 +--- + +# 如愿知识库首页 + +本知识库用于沉淀如愿内部系统建设中的业务流程、项目管理流程、角色职责、交付物、检查清单与 Agent 检索问答规范。 + +## 快速入口 + +- [[../知识库使用说明|知识库使用说明]] +- [[知识地图]] +- [[Agent问答入口]] +- [[../05_需求文档/README|需求文档]] +- [[../06_里程碑/README|里程碑]] +- [[../07_技术文档/README|技术文档]] +- [[../08_测试相关/README|测试相关]] +- [[../04_Agent检索/检索说明|Agent 检索说明]] + +## 当前权威来源 + +- 项目管理流程：`AI_驱动_内部系统开发流程_V3.docx` +- 适用范围：ERP、内部系统、小型业务系统、运营工具、AI 辅助开发项目。 + +## 使用原则 + +1. 需求类问题先查需求文档。 +2. 进度、节点、准入问题先查里程碑。 +3. 技术实现、接口、架构问题先查技术文档。 +4. 测试范围、用例、验收、缺陷问题先查测试相关。 +5. Agent 回答必须说明来源文件。 +6. 知识库没有明确记录时，不要猜测，应提示补充位置。 diff --git a/wishfulfilled-wiki/01_业务流程/README.md b/wishfulfilled-wiki/01_业务流程/README.md new file mode 100644 index 0000000..fc4aa26 --- /dev/null +++ b/wishfulfilled-wiki/01_业务流程/README.md @@ -0,0 +1,27 @@ +--- +type: index +tags: [业务流程, 入口] +aliases: [业务流程入口] +source: manual +status: active +owner: 业务主管 +updated: 2026-05 +--- + +# 业务流程 + +本目录用于沉淀真实业务流程。第一阶段先建立模板、业务对象字典和业务规则索引，后续按流程逐条补充。 + +## 当前文件 + +- [[业务流程模板]] +- [[业务对象字典]] +- [[业务规则索引]] + +## 录入要求 + +每条业务流程至少补充：流程名称、适用角色、触发条件、主流程、分支流程、异常处理、输入数据、输出结果、相关系统、业务规则、常见问题、关联项目管理阶段。 + +## 与项目管理流程的关系 + +业务流程内容主要用于支撑 [[../02_项目管理流程/阶段1_业务需求完整形成|阶段1 业务需求完整形成]] 和 [[../02_项目管理流程/阶段2_高保真模型与业务对象确认|阶段2 高保真模型与业务对象确认]]。 diff --git a/wishfulfilled-wiki/01_业务流程/业务对象字典.md b/wishfulfilled-wiki/01_业务流程/业务对象字典.md new file mode 100644 index 0000000..7044569 --- /dev/null +++ b/wishfulfilled-wiki/01_业务流程/业务对象字典.md @@ -0,0 +1,30 @@ +--- +type: dictionary +tags: [业务对象, 数据对象, 字典] +aliases: [业务对象模型, 对象字典] +source: manual +status: draft +owner: 业务主管 +updated: 2026-05 +--- + +# 业务对象字典 + +用于沉淀业务对象、字段、状态和生命周期，是页面、接口、数据库、测试、AI 提示词的共同基础。 + +## 对象清单 + +| 业务对象 | 定义 | 关键字段 | 状态 | 关联流程 | 备注 | +|---|---|---|---|---|---| +| | | | | | | + +## 维护规则 + +- 阶段2必须确认统一业务对象模型。 +- 新增页面、接口、数据库表或测试用例时，应回查本字典。 +- 字段含义、状态枚举和对象关系不明确时，不应进入正式开发。 + +## 关联条目 + +- [[../02_项目管理流程/阶段2_高保真模型与业务对象确认]] +- [[../02_项目管理流程/阶段交付物清单]] diff --git a/wishfulfilled-wiki/01_业务流程/业务流程模板.md b/wishfulfilled-wiki/01_业务流程/业务流程模板.md new file mode 100644 index 0000000..9929b54 --- /dev/null +++ b/wishfulfilled-wiki/01_业务流程/业务流程模板.md @@ -0,0 +1,72 @@ +--- +type: template +tags: [业务流程, 模板] +aliases: [业务流程梳理模板] +source: manual +status: active +owner: 业务主管 +updated: 2026-05 +--- + +# 业务流程模板 + +## 基本信息 + +- 流程名称： +- 适用部门： +- 适用角色： +- 相关系统： +- 流程负责人： +- 当前状态：draft / active / deprecated + +## 触发条件 + +说明什么情况下进入该流程。 + +## 前置条件 + +说明流程开始前必须满足的条件、权限、数据或审批。 + +## 主流程 + +1. +2. +3. + +## 分支流程 + +| 分支场景 | 判断条件 | 处理方式 | 负责人 | 输出 | +|---|---|---|---|---| +| | | | | | + +## 异常处理 + +| 异常场景 | 发现方式 | 处理方式 | 升级路径 | +|---|---|---|---| +| | | | | + +## 输入数据 + +| 数据项 | 来源 | 必填 | 说明 | +|---|---|---|---| +| | | | | + +## 输出结果 + +| 输出物 | 接收方 | 用途 | +|---|---|---| +| | | | + +## 业务规则 + +- + +## 常见问题 + +- 问： + 答： + +## 关联项目管理阶段 + +- [[../02_项目管理流程/阶段1_业务需求完整形成]] +- [[../02_项目管理流程/阶段2_高保真模型与业务对象确认]] diff --git a/wishfulfilled-wiki/01_业务流程/业务补充验证记录.md b/wishfulfilled-wiki/01_业务流程/业务补充验证记录.md new file mode 100644 index 0000000..21464cf --- /dev/null +++ b/wishfulfilled-wiki/01_业务流程/业务补充验证记录.md @@ -0,0 +1,36 @@ +--- +type: validation_log +tags: [业务流程, 业务规则, 验证记录, Agent检索] +aliases: [业务补充验证, Agent问答验证记录] +source: manual +status: active +owner: 产品经理 / 内部技术团队 +updated: 2026-05 +--- + +# 业务补充验证记录 + +## 使用说明 + +每次新增或修订 `01_业务流程/` 下的业务规则、需求或流程文档后，在此记录 Agent 检索验证结果。 + +## 验证记录 + +| 日期 | 业务域 | 新增/修订文件 | 验证问题 | 是否命中 | 来源文件 | 结果 | 待补充 | +|---|---|---|---|---|---|---|---| +| | | | | 是/否 | | 通过/失败 | | + +## 验证结论模板 + +```markdown +### YYYY-MM-DD 业务域_规则或需求名称 + +- 新增/修订文件： +- 已更新索引：业务规则索引 / 业务对象字典 / 关键词索引 / 同义词表 / 来源文件索引 +- 验证问题： + 1. + 2. + 3. +- 结论：通过 / 失败 +- 待补充： +``` diff --git a/wishfulfilled-wiki/01_业务流程/业务规则索引.md b/wishfulfilled-wiki/01_业务流程/业务规则索引.md new file mode 100644 index 0000000..b5db1f1 --- /dev/null +++ b/wishfulfilled-wiki/01_业务流程/业务规则索引.md @@ -0,0 +1,25 @@ +--- +type: index +tags: [业务规则, 索引] +aliases: [规则索引] +source: manual +status: draft +owner: 业务主管 +updated: 2026-05 +--- + +# 业务规则索引 + +用于集中记录跨流程复用的业务规则，避免规则散落在需求、页面和测试用例中。 + +| 规则编号 | 规则名称 | 适用流程 | 规则说明 | 来源 | 状态 | +|---|---|---|---|---|---| +| BR-001 | | | | | draft | + +## 维护要求 + +- 规则必须能追溯到业务流程或项目文档。 +- 涉及权限、状态流转、金额、时间、审批、异常处理的规则应优先沉淀。 +- 规则变更后，应同步检查测试用例和上线培训材料。 +- 新增规则建议使用 `03_规范与模板/业务规则与需求补充模板.md`。 +- 新增或修订后，按 `04_Agent检索/知识库持续更新与验证流程.md` 执行 Agent 检索验证。 diff --git a/wishfulfilled-wiki/02_项目管理流程/AI驱动内部系统开发流程_V3_总览.md b/wishfulfilled-wiki/02_项目管理流程/AI驱动内部系统开发流程_V3_总览.md new file mode 100644 index 0000000..e509662 --- /dev/null +++ b/wishfulfilled-wiki/02_项目管理流程/AI驱动内部系统开发流程_V3_总览.md @@ -0,0 +1,123 @@ +--- +type: process_overview +tags: [项目管理流程, AI驱动开发, ERP, 内部系统] +aliases: [AI驱动内部系统开发流程, 内部系统开发流程V3, ERP开发流程] +source: AI_驱动_内部系统开发流程_V3.docx +status: active +owner: 内部技术团队 +updated: 2026-05 +--- + +# AI 驱动内部系统开发流程 V3 总览 + +## 版本定位 + +本流程适用于公司当前阶段的 ERP、内部系统、小型业务系统、运营工具、AI 辅助开发项目。 + +核心目标不是让流程变复杂，而是解决以下问题： + +- 业务需求说不清。 +- AI 生成内容不完整。 +- 前端模型介入太晚。 +- 后端数据库设计被页面倒逼。 +- 测试太晚才发现需求漏项。 +- 项目完成后留下大量重复代码和技术债。 + +## 总体阶段 + +| 阶段 | 阶段名称 | 核心目标 | 核心负责人 | +|---|---|---|---| +| 阶段0 | 项目入口分级 | 判断项目是否值得做、走轻流程还是完整流程 | 业务主管 / 技术负责人 | +| 阶段1 | 业务需求完整形成 | 业务侧通过 Vibe Coding 跑完整需求 | 业务主管 / 业务人员 | +| 阶段2 | 高保真模型与业务对象确认 | 把完整但粗糙的需求收敛成可开发模型 | 前端 / 产品经理 | +| 阶段2.5 | 测试提前补漏 | 在开发前用测试视角发现需求漏洞 | 测试 | +| 阶段3 | 研发协作与正式开发 | 基于高保真模型进行模块化、安全、可维护开发 | 前端 / 后端 / 算法 | +| 阶段4 | 测试、培训、上线、回流 | 完成测试、培训、上线验收和问题回流 | 测试 / 业务主管 | +| 阶段5 | 技术债治理与能力沉淀 | 清理 AI 冗余代码并沉淀复用能力 | 技术负责人 | + +## 阶段门禁 + +| 门禁 | 通过标准 | +|---|---| +| Gate 0 | 项目入口通过：确认值得做，确认项目类型。 | +| Gate 1 | 需求完整通过：主流程、分支、页面、按钮、字段、状态大致完整。 | +| Gate 2 | 高保真模型通过：页面收敛、按钮行为、业务对象、状态、V1/V2 明确。 | +| Gate 2.5 | 测试补漏：测试用例初稿发现的阻塞问题已处理。 | +| Gate 3 | 开发联调通过：前后端、数据库、权限、安全、主要流程联调完成。 | +| Gate 4 | 上线验收通过：测试通过、业务确认、培训完成。 | +| Gate 5 | 技术债治理完成：重复代码、组件、接口、数据结构完成治理或进入债务池。 | + +## 完整版文件结构 + +- `00_项目入口分级.md` +- `01_主流程说明.md` +- `02_日常操作页面结构.md` +- `03_功能页面按钮盘点表.md` +- `04_分支流程_XXX.md` +- `05_异常流程_XXX.md` +- `06_VibeCoding页面验证记录.md` +- `07_高保真模型.html` +- `07_高保真模型说明.md` +- `08_项目周期与版本确认.md` +- `09_前端技术评审.md` +- `10_技术预检记录.md` +- `10A_统一业务对象模型.md` +- `10B_按钮行为矩阵.md` +- `11_测试用例初稿与需求补漏.md` +- `12_研发任务拆分与协作计划.md` +- `13_技术实现对接.md` +- `14_代码治理与安全规范.md` +- `15_开发问题与联调记录.md` +- `16_正式测试报告.md` +- `17_内部培训手册.md` +- `18_上线验收记录.md` +- `19_上线问题与回流需求.md` +- `20_技术债清单.md` +- `21_业务原子能力沉淀清单.md` +- `22_组件库与服务复用清单.md` +- `23_AI开发上下文模板更新记录.md` + +## 轻量版文件结构 + +小项目可以使用轻量版： + +- `00_项目入口分级.md` +- `01_业务需求包.md` +- `02_高保真模型包.md` +- `03_项目版本与技术预检.md` +- `04_测试用例初稿与需求补漏.md` +- `05_研发协作与技术实现包.md` +- `06_代码治理与安全规范.md` +- `07_测试培训上线包.md` +- `08_技术债与能力沉淀包.md` + +## 最终核心原则 + +- 先分级，再开发。 +- 阶段1追求需求完整，不追求产品完善。 +- Vibe Coding 页面只是需求原型，不直接进入生产。 +- 阶段2追求模型高效，前端必须深度参与。 +- 高保真模型确认后，才允许正式开发。 +- 统一业务对象模型是页面、接口、数据库、测试、AI 提示词的共同基础。 +- 性能、安全、权限、并发、日志、可回滚必须提前预检。 +- 测试提前补漏，不只是上线前找 Bug。 +- 研发阶段以代码质量、模块化、安全性、可维护性为中心。 +- AI 代码必须治理，不能直接堆进生产。 +- 每个项目都要沉淀业务原子能力。 +- 每完成 3-4 个项目，必须进行技术债治理。 + +## 一句话总结 + +这套流程不是为了让 AI 替代开发，而是让 AI 帮业务更快形成完整需求，让前端和产品把需求收敛成高保真模型，让研发团队基于模型高质量开发，让测试和技术债治理保障系统长期可用。 + +## 关联条目 + +- [[阶段0_项目入口分级]] +- [[阶段1_业务需求完整形成]] +- [[阶段2_高保真模型与业务对象确认]] +- [[阶段2.5_测试提前补漏]] +- [[阶段3_研发协作与正式开发]] +- [[阶段4_测试培训上线回流]] +- [[角色职责矩阵]] +- [[阶段交付物清单]] +- [[项目检查清单]] diff --git a/wishfulfilled-wiki/02_项目管理流程/README.md b/wishfulfilled-wiki/02_项目管理流程/README.md new file mode 100644 index 0000000..d85fe97 --- /dev/null +++ b/wishfulfilled-wiki/02_项目管理流程/README.md @@ -0,0 +1,34 @@ +--- +type: index +tags: [项目管理流程, AI驱动开发] +aliases: [项目管理流程入口, 开发流程入口] +source: AI_驱动_内部系统开发流程_V3.docx +status: active +owner: 内部技术团队 +updated: 2026-05 +--- + +# 项目管理流程 + +本目录基于 `AI_驱动_内部系统开发流程_V3.docx` 拆解，用于指导 ERP、内部系统、小型业务系统、运营工具、AI 辅助开发项目。 + +## 阶段文件 + +- [[AI驱动内部系统开发流程_V3_总览]] +- [[阶段0_项目入口分级]] +- [[阶段1_业务需求完整形成]] +- [[阶段2_高保真模型与业务对象确认]] +- [[阶段2.5_测试提前补漏]] +- [[阶段3_研发协作与正式开发]] +- [[阶段4_测试培训上线回流]] + +## 重组索引 + +- [[角色职责矩阵]] +- [[阶段交付物清单]] +- [[项目检查清单]] +- [[常见问题FAQ]] + +## 核心原则 + +先分级，再开发。阶段1追求需求完整，不追求产品完善。高保真模型确认后，才允许正式开发。测试要提前补漏。AI 代码必须治理，不能直接堆进生产。 diff --git a/wishfulfilled-wiki/02_项目管理流程/常见问题FAQ.md b/wishfulfilled-wiki/02_项目管理流程/常见问题FAQ.md new file mode 100644 index 0000000..6e7adbc --- /dev/null +++ b/wishfulfilled-wiki/02_项目管理流程/常见问题FAQ.md @@ -0,0 +1,65 @@ +--- +type: faq +tags: [项目管理流程, FAQ, 问答] +aliases: [流程常见问题, 项目管理问答] +source: AI_驱动_内部系统开发流程_V3.docx +status: active +owner: 内部技术团队 +updated: 2026-05 +--- + +# 常见问题 FAQ + +## 一个内部系统需求从提出到上线要走哪些阶段？ + +通常经过阶段0项目入口分级、阶段1业务需求完整形成、阶段2高保真模型与业务对象确认、阶段2.5测试提前补漏、阶段3研发协作与正式开发、阶段4测试培训上线回流。文档还定义了阶段5技术债治理与能力沉淀。 + +来源：[[AI驱动内部系统开发流程_V3_总览]] + +## 阶段0项目入口分级由谁负责？ + +由业务主管和技术负责人共同负责。业务主管判断业务价值和范围，技术负责人判断技术复杂度和风险。 + +来源：[[阶段0_项目入口分级]]、[[角色职责矩阵]] + +## 业务需求完整形成阶段的目标是什么？ + +业务侧通过 Vibe Coding 跑完整需求。阶段1追求需求完整，不追求产品完善。 + +来源：[[阶段1_业务需求完整形成]] + +## 阶段2.5测试提前补漏应该在什么时候发生？ + +发生在高保真模型确认后、正式开发前。 + +来源：[[阶段2.5_测试提前补漏]] + +## 阶段2.5测试提前补漏要产出什么？ + +主要产出 `11_测试用例初稿与需求补漏.md`，并形成需求补漏记录、阻塞问题清单和已关闭问题清单。 + +来源：[[阶段2.5_测试提前补漏]]、[[阶段交付物清单]] + +## 什么时候需要前端提前参与需求收敛？ + +阶段2必须由前端深度参与。若需求涉及多页面、复杂交互、权限、状态流转、数据结构或组件复用，前端应在需求收敛时提前参与。 + +来源：[[阶段2_高保真模型与业务对象确认]] + +## 研发协作与正式开发阶段如何保证模块化、安全和可维护？ + +依赖统一业务对象模型、研发任务拆分、技术实现对接、代码治理与安全规范、开发问题与联调记录。AI 代码必须经过治理，不能直接堆进生产。 + +来源：[[阶段3_研发协作与正式开发]] + +## 上线前需要检查哪些事项？ + +至少检查正式测试、主流程、分支流程、权限、异常、数据边界、内部培训手册、业务确认、上线问题回流机制。 + +来源：[[阶段4_测试培训上线回流]]、[[项目检查清单]] + +## Vibe Coding 页面能不能直接进入生产？ + +不能。Vibe Coding 页面只是需求原型，不直接进入生产。 + +来源：[[阶段1_业务需求完整形成]]、[[AI驱动内部系统开发流程_V3_总览]] diff --git a/wishfulfilled-wiki/02_项目管理流程/角色职责矩阵.md b/wishfulfilled-wiki/02_项目管理流程/角色职责矩阵.md new file mode 100644 index 0000000..a74f656 --- /dev/null +++ b/wishfulfilled-wiki/02_项目管理流程/角色职责矩阵.md @@ -0,0 +1,84 @@ +--- +type: responsibility_matrix +tags: [项目管理流程, 角色职责, RACI] +aliases: [角色职责, 职责矩阵, RACI] +source: AI_驱动_内部系统开发流程_V3.docx +status: active +owner: 内部技术团队 +updated: 2026-05 +--- + +# 角色职责矩阵 + +## 总览 + +| 角色 | 主要负责阶段 | 核心职责 | 典型产出 | +|---|---|---|---| +| 业务主管 | 阶段0、阶段1、阶段4 | 判断项目价值、明确主流程、确认业务完整性、上线验收 | 项目入口分级、主流程说明、业务验收口径、上线验收记录 | +| 业务人员 | 阶段1 | 补充分支流程、提供样本数据、验证真实操作路径 | 分支流程、异常流程、Vibe Coding 页面验证记录 | +| 产品经理 | 阶段2 | 收敛需求、组织高保真模型、明确版本范围 | 高保真模型说明、项目周期与版本确认 | +| 前端 | 阶段2、阶段3 | 深度参与模型收敛、页面结构、按钮行为、组件复用、前端开发 | 高保真模型、前端技术评审、按钮行为矩阵、前端实现 | +| 后端 | 阶段3 | 设计接口、数据库、权限、安全、日志、回滚和服务能力 | 技术实现对接、后端服务、接口和数据库方案 | +| 算法 | 阶段3 | 判断是否需要 AI，设计输入输出、置信度、人工审核和风险控制 | 算法适用性判断、算法输入输出说明、置信度规则 | +| 测试 | 阶段2.5、阶段4 | 提前写测试用例、发现需求漏洞、正式测试、培训材料、上线反馈 | 测试用例初稿、正式测试报告、内部培训手册、上线问题回流 | +| 技术负责人 | 阶段0、阶段5 | 技术分级、风险判断、技术债治理和能力沉淀 | 技术债清单、业务原子能力沉淀清单、组件库与服务复用清单 | + +## 业务主管 + +业务主管保证方向正确、主流程清楚、需求不漏大块。 + +职责： + +- 判断项目是否值得做。 +- 定义主流程。 +- 定义日常操作入口。 +- 明确业务人员每天先看什么页面。 +- 拆分分支流程，指定业务人员补充。 +- 确认异常流程。 +- 确认业务完整性。 +- 参与业务验收。 + +## 业务人员 + +业务人员负责具体分支流程和真实操作细节。 + +职责： + +- 补充分支流程。 +- 提供样本数据，例如 ASIN、订单、评论、用户、表格等真实样本。 +- 使用 Vibe Coding 跑页面，验证是否符合真实操作。 +- 补充异常场景。 + +## 算法 + +算法保证 AI 能力可控、可解释、可人工审核。 + +职责： + +- 判断是否需要 AI，避免为了 AI 而 AI。 +- 设计算法输入，明确模型需要哪些数据。 +- 设计算法输出，明确 AI 返回什么结果。 +- 制定置信度规则。 +- 制定人工审核机制。 +- 设计风险控制，确保 AI 判断错误时可以回退和纠正。 + +## 测试 + +测试不只是最后找 Bug，还要提前补漏，并负责内部培训材料。 + +职责： + +- 高保真模型出来后先写测试用例。 +- 用测试视角发现流程、按钮、权限遗漏。 +- 正式测试主流程、分支流程、权限、异常和数据。 +- 输出验收报告。 +- 将测试用例转成业务操作手册。 +- 记录上线问题并回流需求池。 + +## 关联条目 + +- [[AI驱动内部系统开发流程_V3_总览]] +- [[阶段0_项目入口分级]] +- [[阶段1_业务需求完整形成]] +- [[阶段2.5_测试提前补漏]] +- [[阶段4_测试培训上线回流]] diff --git a/wishfulfilled-wiki/02_项目管理流程/阶段0_项目入口分级.md b/wishfulfilled-wiki/02_项目管理流程/阶段0_项目入口分级.md new file mode 100644 index 0000000..66e6b25 --- /dev/null +++ b/wishfulfilled-wiki/02_项目管理流程/阶段0_项目入口分级.md @@ -0,0 +1,86 @@ +--- +type: process_stage +tags: [项目管理流程, 阶段0, 项目入口, 分级, 立项] +aliases: [项目入口分级, 入口分级, Gate 0, 立项分级] +source: AI_驱动_内部系统开发流程_V3.docx +status: active +owner: 业务主管 / 技术负责人 +updated: 2026-05 +--- + +# 阶段0 项目入口分级 + +## 核心目标 + +不是所有需求都应该进入完整开发流程。阶段0用于判断项目是否值得做，以及走轻流程还是完整流程。 + +## 负责人 + +- 业务主管 +- 技术负责人 + +## 输入 + +- 业务提出的问题或机会。 +- 现有系统痛点。 +- 业务收益、风险、范围的初步判断。 + +## 项目分类 + +| 类型 | 适用场景 | 流程要求 | +|---|---|---| +| S 类 | 小需求，单页面、小改动、无复杂数据 | 可简化阶段1和阶段2。 | +| M 类 | 中等需求，涉及多个页面、多个角色或状态流转 | 建议走完整阶段0-4。 | +| L 类 | 大型需求，涉及核心流程、多个部门、复杂权限、数据模型或算法 | 必须走完整流程，并强化技术预检和阶段门禁。 | + +## 关键动作 + +- 判断需求是否值得做。 +- 判断项目影响范围。 +- 判断是否需要完整流程。 +- 判断是否涉及复杂数据、权限、算法、外部系统或高风险流程。 +- 初步指定业务负责人和技术负责人。 + +## 输出/交付物 + +- `00_项目入口分级.md` +- 项目类型：S / M / L。 +- 是否进入完整流程的结论。 +- 初步负责人。 +- 初步范围和风险。 + +## 检查清单 + +- [ ] 是否确认需求要解决的真实业务问题？ +- [ ] 是否确认该需求值得做？ +- [ ] 是否确认项目类型？ +- [ ] 是否确认走轻流程还是完整流程？ +- [ ] 是否识别复杂权限、数据、算法、并发、安全或外部系统风险？ +- [ ] 是否明确业务主管和技术负责人？ + +## 风险点 + +- 小需求被过度流程化，降低效率。 +- 大需求被当成小需求处理，后续返工。 +- 没有识别权限、数据、安全、算法风险。 +- 没有业务负责人，需求持续漂移。 + +## Gate 0 通过标准 + +项目入口通过：确认值得做，确认项目类型。 + +## 常见问题 + +### 阶段0由谁负责？ + +由业务主管和技术负责人共同负责。业务主管判断业务价值和业务范围，技术负责人判断技术复杂度和风险。 + +### 小需求是否必须走完整流程？ + +不一定。S 类小需求可以简化阶段1和阶段2，但仍应保留基本入口判断、测试和上线验收。 + +## 关联条目 + +- [[AI驱动内部系统开发流程_V3_总览]] +- [[角色职责矩阵]] +- [[阶段交付物清单]] diff --git a/wishfulfilled-wiki/02_项目管理流程/阶段1_业务需求完整形成.md b/wishfulfilled-wiki/02_项目管理流程/阶段1_业务需求完整形成.md new file mode 100644 index 0000000..0de273d --- /dev/null +++ b/wishfulfilled-wiki/02_项目管理流程/阶段1_业务需求完整形成.md @@ -0,0 +1,83 @@ +--- +type: process_stage +tags: [项目管理流程, 阶段1, 业务需求, VibeCoding, 需求完整] +aliases: [业务需求完整形成, 提需求, 需求梳理, Gate 1] +source: AI_驱动_内部系统开发流程_V3.docx +status: active +owner: 业务主管 / 业务人员 +updated: 2026-05 +--- + +# 阶段1 业务需求完整形成 + +## 核心目标 + +业务侧通过 Vibe Coding 跑完整需求。阶段1追求需求完整，不追求产品完善。 + +## 负责人 + +- 业务主管 +- 业务人员 + +## 输入 + +- 阶段0入口分级结论。 +- 业务痛点、业务目标、现有流程。 +- 业务人员真实操作经验。 + +## 关键动作 + +- 梳理主流程。 +- 明确日常操作页面结构。 +- 盘点功能页面和按钮。 +- 补充分支流程。 +- 补充异常流程。 +- 使用 Vibe Coding 生成或验证需求原型。 +- 记录页面验证结果。 + +## 输出/交付物 + +- `01_主流程说明.md` +- `02_日常操作页面结构.md` +- `03_功能页面按钮盘点表.md` +- `04_分支流程_XXX.md` +- `05_异常流程_XXX.md` +- `06_VibeCoding页面验证记录.md` + +## 检查清单 + +- [ ] 主流程是否能从开始走到结束？ +- [ ] 日常操作入口是否清楚？ +- [ ] 页面、按钮、字段是否大致完整？ +- [ ] 分支流程是否由真实业务人员补充？ +- [ ] 异常流程是否覆盖无负责人、超时、数据缺失等情况？ +- [ ] Vibe Coding 原型是否经过业务侧走查？ +- [ ] 是否明确哪些内容只是原型，不可直接进入生产？ + +## 风险点 + +- 只描述主流程，漏掉分支和异常。 +- 把 Vibe Coding 页面当成可生产代码。 +- 业务主管只给方向，没有安排业务人员补充真实操作细节。 +- 页面、按钮、字段未盘点，导致阶段2和开发阶段返工。 + +## Gate 1 通过标准 + +需求完整通过：主流程、分支、页面、按钮、字段、状态大致完整。 + +## 常见问题 + +### 阶段1追求什么？ + +追求需求完整，不追求产品完善。页面可以粗糙，但业务流程、分支、异常、按钮、字段不能漏大块。 + +### Vibe Coding 页面能不能直接上线？ + +不能。Vibe Coding 页面只是需求原型，不直接进入生产。 + +## 关联条目 + +- [[阶段0_项目入口分级]] +- [[阶段2_高保真模型与业务对象确认]] +- [[角色职责矩阵]] +- [[阶段交付物清单]] diff --git a/wishfulfilled-wiki/02_项目管理流程/阶段2.5_测试提前补漏.md b/wishfulfilled-wiki/02_项目管理流程/阶段2.5_测试提前补漏.md new file mode 100644 index 0000000..681e503 --- /dev/null +++ b/wishfulfilled-wiki/02_项目管理流程/阶段2.5_测试提前补漏.md @@ -0,0 +1,79 @@ +--- +type: process_stage +tags: [项目管理流程, 阶段2.5, 测试, 需求补漏, 测试用例] +aliases: [测试提前补漏, 开发前测试, Gate 2.5, 测试用例初稿] +source: AI_驱动_内部系统开发流程_V3.docx +status: active +owner: 测试 +updated: 2026-05 +--- + +# 阶段2.5 测试提前补漏 + +## 核心目标 + +在开发前用测试视角发现需求漏洞。测试提前补漏，不只是上线前找 Bug。 + +## 负责人 + +- 测试 + +## 输入 + +- 高保真模型。 +- 高保真模型说明。 +- 统一业务对象模型。 +- 按钮行为矩阵。 +- 项目周期与版本确认。 + +## 关键动作 + +- 基于高保真模型先写测试用例初稿。 +- 从主流程、分支流程、权限、异常、数据、按钮行为视角检查遗漏。 +- 标记阻塞开发的问题。 +- 将需求漏洞回流给业务、产品、前端补齐。 +- 确认阻塞问题处理后再进入正式开发。 + +## 输出/交付物 + +- `11_测试用例初稿与需求补漏.md` +- 需求补漏记录。 +- 阻塞问题清单。 +- 已关闭问题清单。 + +## 检查清单 + +- [ ] 是否已基于高保真模型编写测试用例初稿？ +- [ ] 是否覆盖主流程？ +- [ ] 是否覆盖分支流程？ +- [ ] 是否覆盖权限？ +- [ ] 是否覆盖异常场景？ +- [ ] 是否覆盖关键数据和状态？ +- [ ] 是否覆盖按钮行为？ +- [ ] 测试发现的阻塞问题是否已关闭？ + +## 风险点 + +- 测试只在上线前介入，导致需求漏洞在开发后才暴露。 +- 测试用例只覆盖主流程，漏掉权限、异常、分支和数据边界。 +- 阻塞问题没有关闭就进入开发。 + +## Gate 2.5 通过标准 + +测试补漏：测试用例初稿发现的阻塞问题已处理。 + +## 常见问题 + +### 阶段2.5应该在什么时候发生？ + +发生在高保真模型确认后、正式开发前。 + +### 阶段2.5要产出什么？ + +主要产出 `11_测试用例初稿与需求补漏.md`，并形成需求补漏记录、阻塞问题清单和已关闭问题清单。 + +## 关联条目 + +- [[阶段2_高保真模型与业务对象确认]] +- [[阶段3_研发协作与正式开发]] +- [[项目检查清单]] diff --git a/wishfulfilled-wiki/02_项目管理流程/阶段2_高保真模型与业务对象确认.md b/wishfulfilled-wiki/02_项目管理流程/阶段2_高保真模型与业务对象确认.md new file mode 100644 index 0000000..a7f473e --- /dev/null +++ b/wishfulfilled-wiki/02_项目管理流程/阶段2_高保真模型与业务对象确认.md @@ -0,0 +1,81 @@ +--- +type: process_stage +tags: [项目管理流程, 阶段2, 高保真模型, 业务对象, 前端, 产品] +aliases: [高保真模型确认, 业务对象确认, Gate 2, 统一业务对象模型] +source: AI_驱动_内部系统开发流程_V3.docx +status: active +owner: 前端 / 产品经理 +updated: 2026-05 +--- + +# 阶段2 高保真模型与业务对象确认 + +## 核心目标 + +把完整但粗糙的需求收敛成可开发模型。阶段2追求模型高效，前端必须深度参与。 + +## 负责人 + +- 前端 +- 产品经理 + +## 输入 + +- 阶段1形成的主流程、页面结构、按钮盘点、分支流程、异常流程和 Vibe Coding 验证记录。 + +## 关键动作 + +- 将业务原型收敛为高保真模型。 +- 明确页面结构、交互、按钮行为和状态变化。 +- 确认业务对象、字段、状态和对象关系。 +- 明确 V1/V2 范围和项目周期。 +- 进行前端技术评审和技术预检。 +- 识别性能、安全、权限、并发、日志、可回滚等风险。 + +## 输出/交付物 + +- `07_高保真模型.html` +- `07_高保真模型说明.md` +- `08_项目周期与版本确认.md` +- `09_前端技术评审.md` +- `10_技术预检记录.md` +- `10A_统一业务对象模型.md` +- `10B_按钮行为矩阵.md` + +## 检查清单 + +- [ ] 页面是否已经从粗糙原型收敛成可开发模型？ +- [ ] 按钮行为是否明确？ +- [ ] 业务对象、字段、状态、对象关系是否明确？ +- [ ] V1/V2 范围是否明确？ +- [ ] 是否完成前端技术评审？ +- [ ] 是否完成性能、安全、权限、并发、日志、可回滚预检？ +- [ ] 是否明确高保真模型确认后才允许正式开发？ + +## 风险点 + +- 前端介入太晚，导致页面、接口、数据库互相倒逼。 +- 高保真模型只画页面，没有确认业务对象和状态。 +- 没有按钮行为矩阵，开发和测试无法对齐。 +- 未提前识别性能、安全、权限、并发、日志、回滚风险。 + +## Gate 2 通过标准 + +高保真模型通过：页面收敛、按钮行为、业务对象、状态、V1/V2 明确。 + +## 常见问题 + +### 什么时候需要前端提前参与？ + +阶段2必须由前端深度参与。若需求涉及多页面、复杂交互、权限、状态流转、数据结构或组件复用，前端应在需求收敛时提前参与。 + +### 统一业务对象模型为什么重要？ + +统一业务对象模型是页面、接口、数据库、测试、AI 提示词的共同基础。 + +## 关联条目 + +- [[阶段1_业务需求完整形成]] +- [[阶段2.5_测试提前补漏]] +- [[../01_业务流程/业务对象字典]] +- [[阶段交付物清单]] diff --git a/wishfulfilled-wiki/02_项目管理流程/阶段3_研发协作与正式开发.md b/wishfulfilled-wiki/02_项目管理流程/阶段3_研发协作与正式开发.md new file mode 100644 index 0000000..5264a03 --- /dev/null +++ b/wishfulfilled-wiki/02_项目管理流程/阶段3_研发协作与正式开发.md @@ -0,0 +1,77 @@ +--- +type: process_stage +tags: [项目管理流程, 阶段3, 研发协作, 正式开发, 代码治理, 安全] +aliases: [研发协作, 正式开发, Gate 3, 开发联调] +source: AI_驱动_内部系统开发流程_V3.docx +status: active +owner: 前端 / 后端 / 算法 +updated: 2026-05 +--- + +# 阶段3 研发协作与正式开发 + +## 核心目标 + +基于高保真模型进行模块化、安全、可维护开发。研发阶段以代码质量、模块化、安全性、可维护性为中心。 + +## 负责人 + +- 前端 +- 后端 +- 算法 + +## 输入 + +- 高保真模型。 +- 统一业务对象模型。 +- 按钮行为矩阵。 +- 测试用例初稿与需求补漏结果。 +- 技术预检记录。 + +## 关键动作 + +- 拆分研发任务与协作计划。 +- 进行前端、后端、算法技术实现对接。 +- 明确接口、数据库、权限、安全、日志和回滚方案。 +- 按代码治理与安全规范开发。 +- 记录开发问题与联调结果。 +- 治理 AI 生成代码，不能直接堆进生产。 + +## 输出/交付物 + +- `12_研发任务拆分与协作计划.md` +- `13_技术实现对接.md` +- `14_代码治理与安全规范.md` +- `15_开发问题与联调记录.md` + +## 检查清单 + +- [ ] 研发任务是否已拆分？ +- [ ] 前后端、数据库、权限、安全、主要流程是否联调完成？ +- [ ] 是否按统一业务对象模型设计接口和数据库？ +- [ ] 是否处理权限、安全、日志、可回滚？ +- [ ] AI 生成代码是否经过人工审查和治理？ +- [ ] 是否避免重复代码和不可维护堆叠？ + +## 风险点 + +- 开发直接从 Vibe Coding 原型开始，跳过高保真模型。 +- AI 生成代码未经治理直接进入生产。 +- 缺少模块边界、权限、安全、日志和回滚方案。 +- 前后端、数据库、测试使用的业务对象不一致。 + +## Gate 3 通过标准 + +开发联调通过：前后端、数据库、权限、安全、主要流程联调完成。 + +## 常见问题 + +### 阶段3如何保证模块化、安全和可维护？ + +依赖统一业务对象模型、研发任务拆分、技术实现对接、代码治理与安全规范、开发问题与联调记录。AI 代码必须经过治理，不能直接堆进生产。 + +## 关联条目 + +- [[阶段2.5_测试提前补漏]] +- [[阶段4_测试培训上线回流]] +- [[阶段交付物清单]] diff --git a/wishfulfilled-wiki/02_项目管理流程/阶段4_测试培训上线回流.md b/wishfulfilled-wiki/02_项目管理流程/阶段4_测试培训上线回流.md new file mode 100644 index 0000000..5edff8b --- /dev/null +++ b/wishfulfilled-wiki/02_项目管理流程/阶段4_测试培训上线回流.md @@ -0,0 +1,77 @@ +--- +type: process_stage +tags: [项目管理流程, 阶段4, 测试, 培训, 上线, 回流] +aliases: [测试培训上线回流, 上线验收, Gate 4] +source: AI_驱动_内部系统开发流程_V3.docx +status: active +owner: 测试 / 业务主管 +updated: 2026-05 +--- + +# 阶段4 测试培训上线回流 + +## 核心目标 + +完成测试、培训、上线验收和问题回流。测试保证系统真实可用，并帮助业务人员正确使用。 + +## 负责人 + +- 测试 +- 业务主管 + +## 输入 + +- 开发联调完成的系统。 +- 测试用例。 +- 高保真模型和业务对象模型。 +- 开发问题与联调记录。 + +## 关键动作 + +- 进行正式测试。 +- 验证主流程、分支流程、权限、异常和数据。 +- 输出正式测试报告。 +- 将测试用例转成业务操作手册或内部培训材料。 +- 组织业务确认和上线验收。 +- 记录上线问题并回流需求池。 + +## 输出/交付物 + +- `16_正式测试报告.md` +- `17_内部培训手册.md` +- `18_上线验收记录.md` +- `19_上线问题与回流需求.md` + +## 检查清单 + +- [ ] 正式测试是否通过？ +- [ ] 主流程是否验证通过？ +- [ ] 分支流程是否验证通过？ +- [ ] 权限是否验证通过？ +- [ ] 异常和数据边界是否验证通过？ +- [ ] 内部培训手册是否完成？ +- [ ] 业务主管是否完成上线确认？ +- [ ] 上线问题是否记录并回流？ + +## 风险点 + +- 只测功能，不测权限、异常、数据和实际操作路径。 +- 没有培训材料，业务人员不会用。 +- 上线问题没有进入回流需求池。 +- 业务主管未验收就上线。 + +## Gate 4 通过标准 + +上线验收通过：测试通过、业务确认、培训完成。 + +## 常见问题 + +### 上线前需要检查哪些事项？ + +至少检查正式测试、主流程、分支流程、权限、异常、数据边界、内部培训手册、业务确认、上线问题回流机制。 + +## 关联条目 + +- [[阶段3_研发协作与正式开发]] +- [[项目检查清单]] +- [[阶段交付物清单]] diff --git a/wishfulfilled-wiki/02_项目管理流程/阶段交付物清单.md b/wishfulfilled-wiki/02_项目管理流程/阶段交付物清单.md new file mode 100644 index 0000000..a03dc3b --- /dev/null +++ b/wishfulfilled-wiki/02_项目管理流程/阶段交付物清单.md @@ -0,0 +1,42 @@ +--- +type: deliverable_index +tags: [项目管理流程, 交付物, 文件清单] +aliases: [交付物清单, 文件结构, 产出物] +source: AI_驱动_内部系统开发流程_V3.docx +status: active +owner: 内部技术团队 +updated: 2026-05 +--- + +# 阶段交付物清单 + +## 完整版交付物 + +| 阶段 | 交付物 | +|---|---| +| 阶段0 | `00_项目入口分级.md` | +| 阶段1 | `01_主流程说明.md`、`02_日常操作页面结构.md`、`03_功能页面按钮盘点表.md`、`04_分支流程_XXX.md`、`05_异常流程_XXX.md`、`06_VibeCoding页面验证记录.md` | +| 阶段2 | `07_高保真模型.html`、`07_高保真模型说明.md`、`08_项目周期与版本确认.md`、`09_前端技术评审.md`、`10_技术预检记录.md`、`10A_统一业务对象模型.md`、`10B_按钮行为矩阵.md` | +| 阶段2.5 | `11_测试用例初稿与需求补漏.md` | +| 阶段3 | `12_研发任务拆分与协作计划.md`、`13_技术实现对接.md`、`14_代码治理与安全规范.md`、`15_开发问题与联调记录.md` | +| 阶段4 | `16_正式测试报告.md`、`17_内部培训手册.md`、`18_上线验收记录.md`、`19_上线问题与回流需求.md` | +| 阶段5 | `20_技术债清单.md`、`21_业务原子能力沉淀清单.md`、`22_组件库与服务复用清单.md`、`23_AI开发上下文模板更新记录.md` | + +## 轻量版交付物 + +| 阶段包 | 交付物 | +|---|---| +| 入口 | `00_项目入口分级.md` | +| 需求 | `01_业务需求包.md` | +| 模型 | `02_高保真模型包.md` | +| 预检 | `03_项目版本与技术预检.md` | +| 测试补漏 | `04_测试用例初稿与需求补漏.md` | +| 研发 | `05_研发协作与技术实现包.md` | +| 治理 | `06_代码治理与安全规范.md` | +| 上线 | `07_测试培训上线包.md` | +| 沉淀 | `08_技术债与能力沉淀包.md` | + +## 关联条目 + +- [[AI驱动内部系统开发流程_V3_总览]] +- [[项目检查清单]] diff --git a/wishfulfilled-wiki/02_项目管理流程/项目检查清单.md b/wishfulfilled-wiki/02_项目管理流程/项目检查清单.md new file mode 100644 index 0000000..33cab9d --- /dev/null +++ b/wishfulfilled-wiki/02_项目管理流程/项目检查清单.md @@ -0,0 +1,70 @@ +--- +type: checklist +tags: [项目管理流程, 检查清单, 门禁] +aliases: [项目门禁检查, 上线检查, 流程检查] +source: AI_驱动_内部系统开发流程_V3.docx +status: active +owner: 内部技术团队 +updated: 2026-05 +--- + +# 项目检查清单 + +## Gate 0 项目入口 + +- [ ] 确认项目值得做。 +- [ ] 确认项目类型：S / M / L。 +- [ ] 确认走轻流程还是完整流程。 +- [ ] 确认业务主管和技术负责人。 + +## Gate 1 需求完整 + +- [ ] 主流程完整。 +- [ ] 分支流程完整。 +- [ ] 页面、按钮、字段大致完整。 +- [ ] 状态大致完整。 +- [ ] Vibe Coding 页面已验证。 + +## Gate 2 高保真模型 + +- [ ] 页面已经收敛。 +- [ ] 按钮行为明确。 +- [ ] 业务对象明确。 +- [ ] 状态明确。 +- [ ] V1/V2 明确。 +- [ ] 性能、安全、权限、并发、日志、可回滚已预检。 + +## Gate 2.5 测试补漏 + +- [ ] 测试用例初稿已完成。 +- [ ] 主流程、分支、权限、异常、数据、按钮行为已检查。 +- [ ] 阻塞开发的问题已处理。 + +## Gate 3 开发联调 + +- [ ] 前后端联调完成。 +- [ ] 数据库联调完成。 +- [ ] 权限和安全联调完成。 +- [ ] 主要流程联调完成。 +- [ ] AI 代码已治理。 + +## Gate 4 上线验收 + +- [ ] 正式测试通过。 +- [ ] 业务确认完成。 +- [ ] 培训完成。 +- [ ] 上线问题回流机制明确。 + +## Gate 5 技术债治理 + +- [ ] 技术债已分类。 +- [ ] 必须立即处理的已处理。 +- [ ] 可延后的进入技术债池。 +- [ ] 可复用组件已沉淀。 +- [ ] 可复用后端服务已沉淀。 +- [ ] AI 开发上下文模板已更新。 + +## 关联条目 + +- [[AI驱动内部系统开发流程_V3_总览]] +- [[阶段交付物清单]] diff --git a/wishfulfilled-wiki/03_规范与模板/上线检查模板.md b/wishfulfilled-wiki/03_规范与模板/上线检查模板.md new file mode 100644 index 0000000..48059a7 --- /dev/null +++ b/wishfulfilled-wiki/03_规范与模板/上线检查模板.md @@ -0,0 +1,41 @@ +--- +type: template +tags: [模板, 上线检查] +aliases: [上线模板, 验收模板] +source: manual +status: active +owner: 测试 / 业务主管 +updated: 2026-05 +--- + +# 上线检查模板 + +## 基本信息 + +- 项目名称： +- 上线版本： +- 上线时间： +- 负责人： + +## 上线前检查 + +- [ ] 正式测试通过。 +- [ ] 主流程通过。 +- [ ] 分支流程通过。 +- [ ] 权限通过。 +- [ ] 异常和数据边界通过。 +- [ ] 培训材料完成。 +- [ ] 业务主管确认。 +- [ ] 回滚方案明确。 + +## 上线验收 + +| 验收项 | 验收人 | 结果 | 备注 | +|---|---|---|---| +| | | | | + +## 上线问题回流 + +| 问题 | 影响 | 处理优先级 | 负责人 | 状态 | +|---|---|---|---|---| +| | | | | | diff --git a/wishfulfilled-wiki/03_规范与模板/业务流程梳理模板.md b/wishfulfilled-wiki/03_规范与模板/业务流程梳理模板.md new file mode 100644 index 0000000..a85711f --- /dev/null +++ b/wishfulfilled-wiki/03_规范与模板/业务流程梳理模板.md @@ -0,0 +1,15 @@ +--- +type: template +tags: [模板, 业务流程] +aliases: [流程梳理模板] +source: manual +status: active +owner: 业务主管 +updated: 2026-05 +--- + +# 业务流程梳理模板 + +见 [[../01_业务流程/业务流程模板]]。 + +使用时复制该模板，并按真实业务流程命名保存到 `01_业务流程/` 下。 diff --git a/wishfulfilled-wiki/03_规范与模板/业务规则与需求补充模板.md b/wishfulfilled-wiki/03_规范与模板/业务规则与需求补充模板.md new file mode 100644 index 0000000..1502bda --- /dev/null +++ b/wishfulfilled-wiki/03_规范与模板/业务规则与需求补充模板.md @@ -0,0 +1,115 @@ +--- +type: template +tags: [模板, 业务规则, 需求补充, Agent检索] +aliases: [业务补充模板, 规则补充模板, 需求增量模板] +source: manual +status: active +owner: 业务主管 / 产品经理 +updated: 2026-05 +--- + +# 业务规则与需求补充模板 + +> 使用方式：每次新增或修订业务规则时，复制本模板到 `01_业务流程/` 下，并按 `业务域_规则或需求名称_YYYYMMDD.md` 命名。 + +## 1. 基本信息 + +| 字段 | 内容 | +|---|---| +| 业务域 | | +| 规则/需求名称 | | +| 提出人 | | +| 负责部门 | | +| 适用角色 | | +| 关联系统 | | +| 版本 | v1.0 | +| 生效状态 | draft / active / deprecated | +| 生效时间 | | +| 最近更新时间 | | + +## 2. 背景与目标 + +- 当前问题： +- 业务目标： +- 不解决的问题： + +## 3. 适用范围 + +- 适用场景： +- 不适用场景： +- 前置条件： + +## 4. 业务规则 + +| 编号 | 规则描述 | 触发条件 | 处理结果 | 优先级 | 例外情况 | +|---|---|---|---|---|---| +| BR-001 | | | | 高/中/低 | | + +## 5. 业务流程 + +### 5.1 主流程 + +1. +2. +3. + +### 5.2 分支流程 + +| 分支场景 | 判断条件 | 处理方式 | 输出结果 | +|---|---|---|---| +| | | | | + +### 5.3 异常处理 + +| 异常场景 | 识别方式 | 处理方式 | 负责人 | +|---|---|---|---| +| | | | | + +## 6. 数据与业务对象 + +| 业务对象 | 字段 | 字段含义 | 必填 | 来源 | 去向 | +|---|---|---|---|---|---| +| | | | 是/否 | | | + +## 7. 权限与操作 + +| 角色 | 可见范围 | 可执行操作 | 禁止操作 | +|---|---|---|---| +| | | | | + +## 8. 验收口径 + +| 验收点 | 通过标准 | 测试问题 | +|---|---|---| +| | | | + +## 9. Agent 检索字段 + +### 9.1 推荐关键词 + +- + +### 9.2 同义词/口语问法 + +| 用户可能问法 | 标准术语 | 推荐命中文件 | +|---|---|---| +| | | | + +### 9.3 标准问答 + +| 问题 | 期望答案要点 | 来源章节 | +|---|---|---| +| | | | + +## 10. 关联条目 + +- 关联业务流程： +- 关联项目管理阶段： +- 关联需求说明： +- 关联测试用例： + +## 11. 变更记录 + +| 日期 | 版本 | 变更内容 | 变更人 | +|---|---|---|---| +| | v1.0 | 新增 | | diff --git a/wishfulfilled-wiki/03_规范与模板/会议纪要模板.md b/wishfulfilled-wiki/03_规范与模板/会议纪要模板.md new file mode 100644 index 0000000..7f7d796 --- /dev/null +++ b/wishfulfilled-wiki/03_规范与模板/会议纪要模板.md @@ -0,0 +1,36 @@ +--- +type: template +tags: [模板, 会议纪要] +aliases: [会议记录模板] +source: manual +status: active +owner: 内部技术团队 +updated: 2026-05 +--- + +# 会议纪要模板 + +## 基本信息 + +- 会议主题： +- 时间： +- 参会人： +- 记录人： + +## 结论 + +| 编号 | 结论 | 负责人 | 截止时间 | +|---|---|---|---| +| | | | | + +## 待办 + +| 事项 | 负责人 | 截止时间 | 状态 | +|---|---|---|---| +| | | | | + +## 风险与问题 + +| 问题 | 影响 | 处理方式 | +|---|---|---| +| | | | diff --git a/wishfulfilled-wiki/03_规范与模板/需求说明模板.md b/wishfulfilled-wiki/03_规范与模板/需求说明模板.md new file mode 100644 index 0000000..016ef06 --- /dev/null +++ b/wishfulfilled-wiki/03_规范与模板/需求说明模板.md @@ -0,0 +1,52 @@ +--- +type: template +tags: [模板, 需求说明] +aliases: [需求模板, 业务需求包] +source: manual +status: active +owner: 产品经理 / 业务主管 +updated: 2026-05 +--- + +# 需求说明模板 + +## 背景与目标 + +- 背景： +- 要解决的问题： +- 目标用户： +- 预期收益： + +## 范围 + +- V1 范围： +- V2 范围： +- 不包含范围： + +## 主流程 + +1. +2. +3. + +## 页面与按钮 + +| 页面 | 按钮/操作 | 行为说明 | 权限 | 备注 | +|---|---|---|---|---| +| | | | | | + +## 业务对象 + +| 对象 | 字段 | 状态 | 说明 | +|---|---|---|---| +| | | | | + +## 分支与异常 + +| 场景 | 处理方式 | 负责人 | +|---|---|---| +| | | | + +## 验收口径 + +- diff --git a/wishfulfilled-wiki/04_Agent检索/关键词索引.md b/wishfulfilled-wiki/04_Agent检索/关键词索引.md new file mode 100644 index 0000000..d0a6150 --- /dev/null +++ b/wishfulfilled-wiki/04_Agent检索/关键词索引.md @@ -0,0 +1,41 @@ +--- +type: keyword_index +tags: [Agent, 关键词, 索引] +aliases: [关键词映射] +source: manual +status: active +owner: 内部技术团队 +updated: 2026-05 +--- + +# 关键词索引 + +| 关键词 | 推荐检索文件 | +|---|---| +| 内部系统开发流程 | `02_项目管理流程/AI驱动内部系统开发流程_V3_总览.md` | +| ERP 开发流程 | `02_项目管理流程/AI驱动内部系统开发流程_V3_总览.md` | +| 项目入口 | `02_项目管理流程/阶段0_项目入口分级.md` | +| 项目分级 | `02_项目管理流程/阶段0_项目入口分级.md` | +| S 类 / M 类 / L 类 | `02_项目管理流程/阶段0_项目入口分级.md` | +| 业务需求 | `02_项目管理流程/阶段1_业务需求完整形成.md` | +| Vibe Coding | `02_项目管理流程/阶段1_业务需求完整形成.md` | +| 高保真模型 | `02_项目管理流程/阶段2_高保真模型与业务对象确认.md` | +| 业务对象 | `02_项目管理流程/阶段2_高保真模型与业务对象确认.md`、`01_业务流程/业务对象字典.md` | +| 按钮行为 | `02_项目管理流程/阶段2_高保真模型与业务对象确认.md` | +| 测试提前补漏 | `02_项目管理流程/阶段2.5_测试提前补漏.md` | +| 测试用例初稿 | `02_项目管理流程/阶段2.5_测试提前补漏.md` | +| 正式开发 | `02_项目管理流程/阶段3_研发协作与正式开发.md` | +| 研发协作 | `02_项目管理流程/阶段3_研发协作与正式开发.md` | +| 代码治理 | `02_项目管理流程/阶段3_研发协作与正式开发.md`、`02_项目管理流程/AI驱动内部系统开发流程_V3_总览.md` | +| 上线验收 | `02_项目管理流程/阶段4_测试培训上线回流.md` | +| 内部培训 | `02_项目管理流程/阶段4_测试培训上线回流.md` | +| 问题回流 | `02_项目管理流程/阶段4_测试培训上线回流.md` | +| 技术债 | `02_项目管理流程/AI驱动内部系统开发流程_V3_总览.md`、`02_项目管理流程/项目检查清单.md` | +| 门禁 | `02_项目管理流程/项目检查清单.md` | +| 交付物 | `02_项目管理流程/阶段交付物清单.md` | +| 谁负责 | `02_项目管理流程/角色职责矩阵.md` | +| 业务规则补充 | `03_规范与模板/业务规则与需求补充模板.md`、`04_Agent检索/知识库持续更新与验证流程.md` | +| 需求补充 | `03_规范与模板/业务规则与需求补充模板.md`、`03_规范与模板/需求说明模板.md` | +| 新增业务流程 | `03_规范与模板/业务规则与需求补充模板.md`、`03_规范与模板/业务流程梳理模板.md` | +| 检索验证 | `04_Agent检索/知识库持续更新与验证流程.md`、`01_业务流程/业务补充验证记录.md` | +| Agent 问答验证 | `04_Agent检索/知识库持续更新与验证流程.md`、`01_业务流程/业务补充验证记录.md` | diff --git a/wishfulfilled-wiki/04_Agent检索/同义词表.md b/wishfulfilled-wiki/04_Agent检索/同义词表.md new file mode 100644 index 0000000..619b644 --- /dev/null +++ b/wishfulfilled-wiki/04_Agent检索/同义词表.md @@ -0,0 +1,31 @@ +--- +type: synonym_table +tags: [Agent, 同义词, 检索] +aliases: [口语映射, 术语映射] +source: manual +status: active +owner: 内部技术团队 +updated: 2026-05 +--- + +# 同义词表 + +| 用户说法 | 标准术语 | 推荐检索文件 | +|---|---|---| +| 提需求 | 业务需求完整形成 / 项目入口分级 | `阶段1_业务需求完整形成.md`、`阶段0_项目入口分级.md` | +| 立项 | 项目入口分级 | `阶段0_项目入口分级.md` | +| 原型 | Vibe Coding 页面 / 高保真模型 | `阶段1_业务需求完整形成.md`、`阶段2_高保真模型与业务对象确认.md` | +| 页面模型 | 高保真模型 | `阶段2_高保真模型与业务对象确认.md` | +| 字段字典 | 业务对象模型 | `阶段2_高保真模型与业务对象确认.md`、`业务对象字典.md` | +| 开发前测试 | 测试提前补漏 | `阶段2.5_测试提前补漏.md` | +| 测试先看 | 测试提前补漏 | `阶段2.5_测试提前补漏.md` | +| 开发怎么开始 | 研发协作与正式开发 | `阶段3_研发协作与正式开发.md` | +| 上线前要做什么 | 测试培训上线回流 / Gate 4 | `阶段4_测试培训上线回流.md`、`项目检查清单.md` | +| 谁来做 | 角色职责 | `角色职责矩阵.md` | +| 要交什么 | 阶段交付物 | `阶段交付物清单.md` | +| 检查点 | 阶段门禁 / 项目检查清单 | `项目检查清单.md` | +| AI 写的代码 | AI 代码治理 | `阶段3_研发协作与正式开发.md` | +| 加一条业务规则 | 业务规则补充 | `业务规则与需求补充模板.md`、`知识库持续更新与验证流程.md` | +| 补需求 | 需求补充 | `业务规则与需求补充模板.md`、`需求说明模板.md` | +| 新规则怎么写 | 业务规则与需求补充 | `业务规则与需求补充模板.md` | +| 怎么验证能不能搜到 | Agent 检索验证 | `知识库持续更新与验证流程.md`、`业务补充验证记录.md` | diff --git a/wishfulfilled-wiki/04_Agent检索/来源文件索引.md b/wishfulfilled-wiki/04_Agent检索/来源文件索引.md new file mode 100644 index 0000000..86e9da9 --- /dev/null +++ b/wishfulfilled-wiki/04_Agent检索/来源文件索引.md @@ -0,0 +1,56 @@ +--- +type: source_index +tags: [来源, 索引, Agent] +aliases: [来源索引, 原始文件] +source: manual +status: active +owner: 内部技术团队 +updated: 2026-05 +--- + +# 来源文件索引 + +## 原始来源 + +| 来源文件 | 路径 | 用途 | 状态 | +|---|---|---|---| +| AI_驱动_内部系统开发流程_V3.docx | `D:\\AIcoding\\WishFulfilled\\知识库\\AI_驱动_内部系统开发流程_V3.docx` | 项目管理流程权威来源 | active | + +## 拆解后的知识条目 + +| 条目 | 来源 | +|---|---| +| `02_项目管理流程/AI驱动内部系统开发流程_V3_总览.md` | AI_驱动_内部系统开发流程_V3.docx | +| `02_项目管理流程/阶段0_项目入口分级.md` | AI_驱动_内部系统开发流程_V3.docx | +| `02_项目管理流程/阶段1_业务需求完整形成.md` | AI_驱动_内部系统开发流程_V3.docx | +| `02_项目管理流程/阶段2_高保真模型与业务对象确认.md` | AI_驱动_内部系统开发流程_V3.docx | +| `02_项目管理流程/阶段2.5_测试提前补漏.md` | AI_驱动_内部系统开发流程_V3.docx | +| `02_项目管理流程/阶段3_研发协作与正式开发.md` | AI_驱动_内部系统开发流程_V3.docx | +| `02_项目管理流程/阶段4_测试培训上线回流.md` | AI_驱动_内部系统开发流程_V3.docx | +| `02_项目管理流程/角色职责矩阵.md` | AI_驱动_内部系统开发流程_V3.docx | +| `02_项目管理流程/阶段交付物清单.md` | AI_驱动_内部系统开发流程_V3.docx | +| `02_项目管理流程/项目检查清单.md` | AI_驱动_内部系统开发流程_V3.docx | +| `02_项目管理流程/常见问题FAQ.md` | AI_驱动_内部系统开发流程_V3.docx | + +## 业务补充来源 + +| 来源文件 | 路径 | 用途 | 状态 | +|---|---|---|---| +| 需求文档目录 | `05_需求文档/` | 持续存放新增业务需求、业务规则和需求变更文档 | active | +| 需求文档索引.md | `05_需求文档/需求文档索引.md` | 登记新增需求文档及 Agent 检索验证状态 | active | +| 业务规则与需求补充模板.md | `03_规范与模板/业务规则与需求补充模板.md` | 新增业务规则、需求、流程的标准模板 | active | +| 知识库持续更新与验证流程.md | `04_Agent检索/知识库持续更新与验证流程.md` | 规范新增文档后的索引同步和 Agent 检索验证 | active | +| 业务补充验证记录.md | `01_业务流程/业务补充验证记录.md` | 记录新增业务文档是否能被 Agent 检索并回答 | active | +| 里程碑目录 | `06_里程碑/` | 存放里程碑计划、阶段评审和项目节点材料 | active | +| 技术文档目录 | `07_技术文档/` | 存放架构、接口、数据模型、实现方案和技术决策 | active | +| 测试相关目录 | `08_测试相关/` | 存放测试计划、测试用例、缺陷、验收和上线检查材料 | active | + +## 维护要求 + +- 从原始 docx 更新流程时，需要同步更新阶段文件、角色职责矩阵、交付物清单、检查清单、FAQ、关键词索引和同义词表。 +- 新增业务规则、需求或流程文档时，原始需求文档统一放入 `05_需求文档/`，并同步更新需求文档索引、业务规则索引、业务对象字典、关键词索引、同义词表和本来源文件索引。 +- 新增里程碑材料统一放入 `06_里程碑/`，并同步更新里程碑索引。 +- 新增技术材料统一放入 `07_技术文档/`，并同步更新技术文档索引。 +- 新增测试材料统一放入 `08_测试相关/`，并同步更新测试用例索引或对应测试记录。 +- Agent 回答项目管理流程问题时，应优先引用拆解后的 Markdown 文件。 +- Agent 回答具体业务规则和需求问题时，应优先引用 `05_需求文档/` 下的正式需求文档；稳定流程可再引用 `01_业务流程/` 下的业务流程条目。 diff --git a/wishfulfilled-wiki/04_Agent检索/检索说明.md b/wishfulfilled-wiki/04_Agent检索/检索说明.md new file mode 100644 index 0000000..b1ce099 --- /dev/null +++ b/wishfulfilled-wiki/04_Agent检索/检索说明.md @@ -0,0 +1,68 @@ +--- +type: agent_retrieval_guide +tags: [Agent, 检索, 规则] +aliases: [Agent检索说明, 检索规则] +source: manual +status: active +owner: 内部技术团队 +updated: 2026-05 +--- + +# Agent 检索说明 + +## 目标 + +让 Agent 在回答业务流程和项目管理流程问题时，优先基于本地 Markdown 知识库检索，而不是凭空回答。 + +## 检索优先级 + +1. `05_需求文档/`：持续新增的业务需求、业务规则、需求变更和补充说明。 +2. `06_里程碑/`：项目节点、阶段计划、阶段评审和上线节奏。 +3. `07_技术文档/`：系统架构、数据模型、接口说明、实现方案和技术决策。 +4. `08_测试相关/`：测试计划、测试用例、缺陷记录、验收记录和上线检查。 +5. `02_项目管理流程/`：内部系统开发流程、阶段、角色、门禁、交付物、检查清单。 +6. `01_业务流程/`：真实业务流程、业务对象、业务规则。 +7. `04_Agent检索/`：关键词、同义词、来源索引、回答规则。 +8. `03_规范与模板/`：需要产出模板或文档时使用。 + +## 问题类型与命中文件 + +| 问题类型 | 优先文件 | +|---|---| +| 流程阶段 | `AI驱动内部系统开发流程_V3_总览.md`、各阶段文件 | +| 角色职责 | `角色职责矩阵.md` | +| 交付物 | `阶段交付物清单.md` | +| 门禁/检查 | `项目检查清单.md` | +| 常见问答 | `常见问题FAQ.md` | +| 业务对象 | `01_业务流程/业务对象字典.md`、`阶段2_高保真模型与业务对象确认.md` | +| 业务规则 | `05_需求文档/`、`05_需求文档/需求文档索引.md`、`01_业务流程/业务规则索引.md` | +| 业务需求 | `05_需求文档/`、`05_需求文档/需求文档索引.md` | +| 项目里程碑 | `06_里程碑/`、`06_里程碑/里程碑索引.md` | +| 技术实现 | `07_技术文档/`、`07_技术文档/技术文档索引.md` | +| 接口/数据模型 | `07_技术文档/接口说明模板.md`、具体接口文档、具体数据模型文档 | +| 测试用例 | `08_测试相关/`、`08_测试相关/测试用例索引.md` | +| 缺陷/验收/上线检查 | `08_测试相关/缺陷记录模板.md`、`08_测试相关/验收记录模板.md`、`08_测试相关/上线检查模板.md` | + +## 回答规则 + +- 先回答结论，再展开依据。 +- 流程问题按“阶段、负责人、输入、动作、输出、检查点”组织。 +- 角色问题按“负责阶段、核心职责、典型产出”组织。 +- 交付物问题列出文件名。 +- 业务规则和需求问题优先检索 `05_需求文档/` 下的正式需求文档，再检索 `05_需求文档/需求文档索引.md`、`01_业务流程/业务规则索引.md`、`关键词索引.md` 和 `同义词表.md`。 +- 里程碑问题优先检索 `06_里程碑/` 和 `06_里程碑/里程碑索引.md`。 +- 技术问题优先检索 `07_技术文档/` 和 `07_技术文档/技术文档索引.md`。 +- 测试问题优先检索 `08_测试相关/` 和 `08_测试相关/测试用例索引.md`。 +- 必须注明来源文件名。 +- 如果知识库未明确记录，不要推测，应回答“知识库未明确记录”，并建议补充到具体文件。 + +## 持续更新验证 + +新增业务规则、需求或流程文档后，按 [[知识库持续更新与验证流程]] 执行验证。 +新增文档应使用 `03_规范与模板/业务规则与需求补充模板.md`，正式需求文档保存到 `05_需求文档/`，验证结果记录到 `05_需求文档/需求文档索引.md` 和 `01_业务流程/业务补充验证记录.md`。 + +## 引用格式 + +建议在回答末尾使用： + +> 来源：`02_项目管理流程/阶段2.5_测试提前补漏.md` diff --git a/wishfulfilled-wiki/04_Agent检索/知识库持续更新与验证流程.md b/wishfulfilled-wiki/04_Agent检索/知识库持续更新与验证流程.md new file mode 100644 index 0000000..af14e97 --- /dev/null +++ b/wishfulfilled-wiki/04_Agent检索/知识库持续更新与验证流程.md @@ -0,0 +1,162 @@ +--- +type: validation_process +tags: [Agent, 检索, 知识库更新, 验证流程] +aliases: [知识库更新验证, Agent检索验证, 补充文档验证流程] +source: manual +status: active +owner: 内部技术团队 / 产品经理 +updated: 2026-05 +--- + +# 知识库持续更新与验证流程 + +## 1. 目标 + +确保业务规则、业务需求和流程补充后，Agent 能通过文件检索命中新内容，并基于知识库给出可追溯回答。 + +## 2. 更新入口 + +业务新增或修订时，优先使用： + +- `03_规范与模板/业务规则与需求补充模板.md` +- `03_规范与模板/需求说明模板.md` +- `03_规范与模板/业务流程梳理模板.md` + +补充后的正式需求文档统一保存到： + +- `05_需求文档/` + +如果文档已经沉淀为稳定业务流程，再同步拆解或引用到： + +- `01_业务流程/` + +推荐命名： + +```text +业务域_规则或需求名称_YYYYMMDD.md +``` + +示例： + +```text +采购_供应商准入规则_20260526.md +库存_出入库审批规则_20260526.md +销售_客户授信额度规则_20260526.md +``` + +## 3. 标准更新流程 + +### 步骤 1：新增补充文档 + +1. 复制 `业务规则与需求补充模板.md`。 +2. 保存到 `05_需求文档/`。 +3. 补全 Frontmatter：`type`、`tags`、`aliases`、`source`、`status`、`owner`、`updated`。 +4. 补全正文中的业务规则、流程、异常、权限、验收口径和 Agent 检索字段。 + +### 步骤 2：更新索引 + +新增业务文档后，同步更新： + +| 文件 | 更新内容 | +|---|---| +| `05_需求文档/需求文档索引.md` | 增加需求/规则名称、业务域、来源文件、状态和验证状态 | +| `01_业务流程/业务规则索引.md` | 增加规则名称、业务域、适用场景、来源文件 | +| `01_业务流程/业务对象字典.md` | 增加新增或变更的业务对象、字段、状态 | +| `04_Agent检索/关键词索引.md` | 增加关键词到新文件的映射 | +| `04_Agent检索/同义词表.md` | 增加口语问法与标准术语映射 | +| `04_Agent检索/来源文件索引.md` | 登记新增知识条目来源 | + +### 步骤 3：执行文件级检查 + +检查项： + +- 文件是否位于 `05_需求文档/`。 +- 文件名是否包含业务域、规则/需求名称、日期。 +- Frontmatter 是否完整。 +- 是否包含 `业务规则`、`业务流程`、`验收口径`、`Agent 检索字段`。 +- 索引文件是否已同步更新。 + +### 步骤 4：执行关键词检索验证 + +用新增文档中的关键词、别名、口语问法进行检索。 + +验证标准： + +- 至少 1 个正式关键词能命中新文档。 +- 至少 1 个口语问法能通过 `同义词表.md` 或 `关键词索引.md` 定位到新文档。 +- 检索结果能定位到具体文件，而不是只命中模板。 + +### 步骤 5：执行 Agent 问答验证 + +每次新增文档至少准备 3 类问题： + +| 类型 | 示例 | 通过标准 | +|---|---|---| +| 规则类 | `供应商准入有什么条件？` | 能回答规则条件、触发条件、处理结果 | +| 流程类 | `供应商准入流程怎么走？` | 能按步骤回答主流程和分支流程 | +| 异常类 | `供应商资料不完整怎么办？` | 能回答异常处理方式和负责人 | + +Agent 回答必须满足： + +1. 结论来自新增文档或已索引文件。 +2. 回答末尾注明来源文件名。 +3. 如果文档未记录，明确回答“知识库未明确记录”。 +4. 不得凭经验补充没有来源的业务规则。 + +### 步骤 6：记录验证结果 + +在新增业务文档末尾的 `变更记录` 或单独验证记录中记录： + +| 日期 | 验证问题 | 是否命中 | 来源文件 | 结果 | 待补充 | +|---|---|---|---|---|---| +| | | 是/否 | | 通过/失败 | | + +## 4. 验证用例模板 + +复制以下内容到新增业务文档的 `Agent 检索字段` 或验证记录中： + +```markdown +## Agent 检索验证 + +| 编号 | 用户问题 | 期望命中文件 | 期望答案要点 | 实际结果 | 状态 | +|---|---|---|---|---|---| +| Q1 | | | | | 未验证 | +| Q2 | | | | | 未验证 | +| Q3 | | | | | 未验证 | +``` + +## 5. 通过/失败判定 + +### 通过 + +- 新文档能被关键词检索到。 +- Agent 能引用新文档回答至少 3 个验证问题。 +- 回答没有明显幻觉。 +- 来源文件引用正确。 + +### 失败 + +出现任一情况视为失败： + +- 新文档只保存了，但没有更新关键词索引或同义词表。 +- Agent 命中了旧文件，未命中新文档。 +- Agent 回答没有引用来源。 +- Agent 编造了文档中不存在的业务规则。 +- 问题能检索到模板，但不能检索到正式业务文档。 + +失败后处理： + +1. 补充 `aliases`、`tags`、推荐关键词和同义词。 +2. 更新 `关键词索引.md` 和 `同义词表.md`。 +3. 将标准问答补充到新增文档的 `Agent 检索字段`。 +4. 重新执行验证。 + +## 6. Agent 验证提示词 + +```text +请只基于 D:\AIcoding\WishFulfilled\知识库\如愿知识库 下的 Markdown 文件回答。 +优先检索 05_需求文档、01_业务流程、02_项目管理流程、04_Agent检索。 +如果知识库没有明确记录，请回答“知识库未明确记录”，并说明建议补充到哪个文件。 +回答末尾必须列出来源文件。 +现在验证问题是：{用户问题} +``` diff --git a/wishfulfilled-wiki/04_Agent检索/问答提示词.md b/wishfulfilled-wiki/04_Agent检索/问答提示词.md new file mode 100644 index 0000000..e9e29e7 --- /dev/null +++ b/wishfulfilled-wiki/04_Agent检索/问答提示词.md @@ -0,0 +1,48 @@ +--- +type: agent_prompt +tags: [Agent, 提示词, 问答] +aliases: [Agent提示词, 知识库问答Prompt] +source: manual +status: active +owner: 内部技术团队 +updated: 2026-05 +--- + +# 问答提示词 + +## 系统提示词 + +你是如愿内部知识库问答 Agent。你必须优先检索本地 Markdown 知识库，再回答业务流程、项目管理流程、角色职责、交付物、检查清单和模板相关问题。 + +回答要求： + +1. 不要凭空编造知识库未记录的信息。 +2. 优先检索 `02_项目管理流程` 和 `01_业务流程`。 +3. 流程类问题按阶段、负责人、输入、关键动作、输出、检查点回答。 +4. 角色类问题优先检索 `角色职责矩阵.md`。 +5. 交付物类问题优先检索 `阶段交付物清单.md`。 +6. 门禁和检查类问题优先检索 `项目检查清单.md`。 +7. 每次回答末尾必须注明来源文件。 +8. 如果没有明确答案，回答“知识库未明确记录”，并说明建议补充到哪个文件。 + +## 用户问题改写规则 + +- “提需求”可映射为“项目入口分级”或“业务需求完整形成”。 +- “开发前测试”可映射为“阶段2.5 测试提前补漏”。 +- “原型”可映射为“Vibe Coding 页面”或“高保真模型”，需结合上下文区分。 +- “上线前检查”可映射为“Gate 4 上线验收”和“项目检查清单”。 +- “谁负责”优先查角色职责矩阵。 + +## 标准回答模板 + +结论： + +要点： + +1. 阶段/角色： +2. 输入： +3. 关键动作： +4. 输出： +5. 检查点： + +来源： diff --git a/wishfulfilled-wiki/05_需求文档/00-系统总览.md b/wishfulfilled-wiki/05_需求文档/00-系统总览.md new file mode 100644 index 0000000..beeea31 --- /dev/null +++ b/wishfulfilled-wiki/05_需求文档/00-系统总览.md @@ -0,0 +1,544 @@ + 1|# 如愿 · 系统总览 v1.0 + 2| + 3|## 文件信息 + 4| + 5|- 文件名称：`00-系统总览.md` + 6|- 项目代号：**如愿** + 7|- 工作目录：`/root/user-business/` + 8|- 当前版本：`v1.0` + 9|- 创建日期：`2026-05-22` + 10|- 上游基线： + 11| - `docs-from-business/20260517_USER评价业务闭环主流程与后续工作基线_v1.2.md` + 12| - `docs-from-business/20260517_USER评价业务闭环_共用能力图与渠道专属流程_v2.2.md` + 13| + 14|## 目录 + 15| + 16|1. [项目目标与原则](#1-项目目标与原则) + 17|2. [系统总边界](#2-系统总边界) + 18|3. [子系统划分](#3-子系统划分) + 19|4. [子系统间依赖关系](#4-子系统间依赖关系) + 20|5. [角色 → 独立前端映射](#5-角色--独立前端映射) + 21|6. [子系统内外边界明细](#6-子系统内外边界明细) + 22|7. [总系统级业务澄清问题清单](#7-总系统级业务澄清问题清单) + 23|8. [待确认的内外边界](#8-待确认的内外边界) + 24|9. [附录：子系统文档索引](#9-附录子系统文档索引) + 25| + 26|--- + 27| + 28|## 1. 项目目标与原则 + 29| +### 1.1 项目代号："如愿" + +> 取名"如愿"——系统做好能做的所有事（身份识别、需求评估、计划调度、渠道协同、风险拦截、结果追踪），让每一次运营投入都如愿转化为真实的评价提升和 ASIN 健康增长。Amazon 是否展示评价有平台的不确定性，但系统必须把可控环节做到极致。 + 33| + 34|### 1.2 核心架构目标 + 35| + 36|| # | 目标 | 说明 | + 37|| --- | --- | --- | + 38|| G1 | 前端分离 | 不同角色拥有独立前端应用，按需集成子系统能力 | + 39|| G2 | 清晰系统边界 | 明确系统内外边界，区分内部可控与外部依赖 | + 40|| G3 | 子系统解耦 | 子系统通过 API 契约通信，支持独立开发、独立部署 | + 41|| G4 | 并行开发 | 子系统之间尽量减少串行依赖，允许多团队并行推进 | + 42|| G5 | 独立角色前端 | Amazon 运营、用户运营、客服、风险管理、KOC/KOL 运营各自拥有独立前端 | + 43| + 44|### 1.3 架构原则 + 45| + 46|| 原则 | 说明 | + 47|| --- | --- | + 48|| **单一数据源** | 每个业务事实只有一个子系统负责写入（Owner），其他子系统只读或通过 API 调用 | + 49|| **API 契约优先** | 子系统间通过明确 API 契约通信，先定义契约再实现 | + 50|| **真实人为核心** | 所有额度、风险、历史判断围绕「真实人」而非单一账号 | + 51|| **每次互动重判** | 身份、额度、风险不是一次性的，每次有效互动需重做判断 | + 52|| **审计不可少** | 所有状态变更、敏感访问、人工干预必须留痕 | + 53| + 54|--- + 55| + 56|## 2. 系统总边界 + 57| + 58|### 2.1 边界总图 + 59| + 60|``` + 61|┌─────────────────────────────────────────────────────────────────────┐ + 62|│ 如愿 系统边界 │ + 63|│ │ + 64|│ ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐ │ + 65|│ │ Amazon │ │ 用户运营 │ │ Amazon │ │ 风险/黑名 │ │ + 66|│ │ 运营前端 │ │ 前端 │ │ 运营总监 │ │ 单前端 │ │ + 67|│ └────┬─────┘ └────┬─────┘ └────┬─────┘ └────┬─────┘ │ + 68|│ │ │ │ │ │ + 69|│ ┌────┴─────┐ ┌────┴─────┐ ┌────┴─────┐ ┌────┴─────┐ │ + 70|│ │ 客服前端 │ │ 客服管理 │ │ KOC/KOL │ │ 管理驾驶 │ │ + 71|│ │ │ │ 前端 │ │ 运营前端 │ │ 舱 │ │ + 72|│ └────┬─────┘ └────┬─────┘ └────┬─────┘ └────┬─────┘ │ + 73|│ │ │ │ │ │ + 74|│ ═════╪══════════════╪══════════════╪══════════════╪══════ API网关 │ + 75|│ │ │ │ │ │ + 76|│ ┌────┴──────────────┴──────────────┴──────────────┴─────┐ │ + 77|│ │ 内部子系统 │ │ + 78|│ │ ┌────────┐ ┌────────┐ ┌────────┐ ┌────────┐ │ │ + 79|│ │ │ 用户身 │ │需求与计│ │额度与频│ │多渠道触│ │ │ + 80|│ │ │份上下文│ │划管理 │ │ 控 │ │达引擎 │ │ │ + 81|│ │ └───┬────┘ └───┬────┘ └───┬────┘ └───┬────┘ │ │ + 82|│ │ ┌───┴────┐ ┌───┴────┐ ┌───┴────┐ ┌───┴────┐ │ │ + 83|│ │ │客服工单│ │风险与反│ │评价结果│ │KOC/KOL │ │ │ + 84|│ │ │与管理 │ │ 欺诈 │ │ 追踪 │ │ 协作 │ │ │ + 85|│ │ └───┬────┘ └───┬────┘ └───┬────┘ └───┬────┘ │ │ + 86|│ │ ┌───┴────┐ │ │ + 87|│ │ │审计与通│ │ │ + 88|│ │ │知中心 │ │ │ + 89|│ │ └────────┘ │ │ + 90|│ └───────────────────────────────────────────────────────────┘ │ + 91|│ │ + 92|└─────────────────────────────────────────────────────────────────────┘ + 93| + 94| ║ 外部系统 ║ + 95| + 96|┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐ + 97|│ Amazon │ │ JOYHUB │ │JOYCOLLAB │ │ 邮件服务 │ │ 财务系统 │ + 98|│ Marketplace│ │ 用户平台 │ │ KOC平台 │ │ (ESP) │ │(返款/退款)│ + 99|└──────────┘ └──────────┘ └──────────┘ └──────────┘ └──────────┘ + 100|``` + 101| + 102|### 2.2 系统内部（如愿系统） + 103| + 104|| # | 子系统 | 代号 | 核心职责 | 详情文档 | + 105|| --- | --- | --- | --- | --- | + 106|| S1 | 用户身份与上下文 | `identity` | 真实人识别、身份线索归并、用户上下文卡 | [01-用户身份与上下文](01-子系统-用户身份与上下文.md) | + 107|| S2 | 需求与计划管理 | `planning` | 需求触发（人工/自动）、计划生成（推新/回评/免评）、审批工作流 | [02-需求与计划管理](02-子系统-需求与计划管理.md) | + 108|| S3 | 额度与频控 | `quota` | 月度测评/免评额度台账、累计评价额度、频控、预占 | [03-额度与频控](03-子系统-额度与频控.md) | + 109|| S4 | 多渠道触达引擎 | `outreach` | IM/EDM/APP Push/TEL 渠道调度、路由、去重、发送 | [04-多渠道触达引擎](04-子系统-多渠道触达引擎.md) | + 110|| S5 | 客服工单与管理 | `support` | 工单生命周期、自动分配、排班出勤、绩效统计 | [05-客服工单与管理](05-子系统-客服工单与管理.md) | + 111|| S6 | 风险与反欺诈 | `risk` | 强弱关联判断、黑名单、双重退款检测、风险事件 | [06-风险与反欺诈](06-子系统-风险与反欺诈.md) | + 112|| S7 | 评价结果追踪 | `review` | 评价提交记录、Amazon 展示核验、ASIN 健康回流 | [07-评价结果追踪](07-子系统-评价结果追踪.md) | + 113|| S8 | KOC/KOL 协作 | `creator` | KOC/KOL 匹配、内容跟踪、Code 管理、JOYCOLLAB 同步 | [08-KOC-KOL协作](08-子系统-KOC-KOL协作.md) | + 114|| S9 | 审计与通知中心 | `audit` | 状态变更审计、敏感访问日志、多类型通知/告警 | [09-审计与通知中心](09-子系统-审计与通知中心.md) | + 115| + 116|### 2.3 系统外部（外部依赖） + 117| + 118|| # | 外部系统 | 说明 | 交互方式 | 确认状态 | + 119|| --- | --- | --- | --- | --- | + 120|| E1 | **Amazon Marketplace** | 订单数据、评价数据、ASIN/Listing 健康数据、退款数据 | API 拉取 / 爬取 | ⚠️ 待确认 | + 121|| E2 | **JOYHUB 用户平台** | JOYHUB ID、设备信息、APP 行为数据、绑定玩具数据 | API 同步 | ⚠️ 待确认 | + 122|| E3 | **JOYCOLLAB** | KOC/KOL 内容数据、Code 使用数据、带货订单数据 | API 同步 | ⚠️ 待确认 | + 123|| E4 | **邮件服务 (ESP)** | EDM 发送、送达/打开/点击追踪、退订/硬退信 | SMTP + Webhook | ⚠️ 待确认 | + 124|| E5 | **财务系统** | 返款执行、返款状态、退款记录（OA 侧） | API 调用 | ⚠️ 待确认 | + 125|| E6 | **APP Push 服务** | APP 推送通道（FCM/APNs） | SDK / API | ⚠️ 待确认 | + 126|| E7 | **电话系统** | 外呼能力、来电识别、通话记录 | API / SIP | ⚠️ 待确认 | + 127|| E8 | **IM 平台 (WhatsApp?)** | IM 消息收发 | API | ⚠️ 待确认 | + 128| + 129|--- + 130| + 131|## 3. 子系统划分 + 132| + 133|### 3.1 划分依据 + 134| + 135|子系统按照**业务域内聚**原则划分，每个子系统： + 136| + 137|1. 拥有明确的数据所有权（该子系统是某些核心数据对象的唯一写入方） + 138|2. 对外暴露清晰的 API 契约 + 139|3. 可以独立开发、测试、部署 + 140|4. 尽量减少对其他子系统的强依赖（启动依赖） + 141| + 142|### 3.2 各子系统数据所有权 + 143| + 144|| 子系统 | 拥有（写入）的核心数据对象 | + 145|| --- | --- | + 146|| identity | `person_profiles`、`person_identity_links`、`contact_context_snapshots`、`device_records` | + 147|| planning | `demands`、`plans`、`plan_items`、`approval_records`、`asin_catalog` | + 148|| quota | `person_quota_ledgers`、`quota_reservations`、`frequency_control_records` | + 149|| outreach | `channel_route_decisions`、`channel_dedup_records`、`im_interaction_records`、`edm_message_events`、`app_touch_events`、`tel_call_records` | + 150|| support | `support_tickets`、`support_followups`、`support_assignment_logs`、`attendance_records`、`shift_schedules`、`support_performance_snapshots` | + 151|| risk | `risk_signals`、`risk_cases`、`blacklist_entities`、`refund_match_results` | + 152|| review | `review_submission_records`、`review_display_checks`、`review_results` | + 153|| creator | `exemption_plan_tasks`、`creator_content_records`、`creator_profiles`、`code_records` | + 154|| audit | `interaction_audit_logs`、`notification_records`、`manual_review_tasks` | + 155| + 156|--- + 157| + 158|## 4. 子系统间依赖关系 + 159| + 160|### 4.1 依赖图 + 161| + 162|``` + 163| ┌─────────────────────────────────────────────┐ + 164| │ audit (审计与通知) │ + 165| │ ← 所有子系统向 audit 发送事件 │ + 166| └─────────────────────────────────────────────┘ + 167| ↑ + 168| ┌─────────┬─────────┬─────┼─────┬─────────┬─────────┐ + 169| │ │ │ │ │ │ │ + 170|┌───┴───┐ ┌───┴───┐ ┌───┴───┐ │ ┌───┴───┐ ┌───┴───┐ ┌───┴───┐ + 171|│ review│ │creator│ │support│ │ │ risk │ │ quota │ │outreach│ + 172|│(评价) │ │(KOC) │ │(客服) │ │ │(风险) │ │(额度) │ │(触达) │ + 173|└───┬───┘ └───┬───┘ └───┬───┘ │ └───┬───┘ └───┬───┘ └───┬───┘ + 174| │ │ │ │ │ │ │ + 175| └─────────┼─────────┼─────┼─────┼─────────┼─────────┘ + 176| │ │ │ │ │ + 177| ┌────┴─────────┴─────┼─────┼─────────┴────────┐ + 178| │ │ │ │ + 179| ▼ ▼ ▼ ▼ + 180| ┌─────────┐ ┌──────────────┐ ┌─────────┐ + 181| │planning │←─────────│ identity │─────────→│ quota │ + 182| │(计划) │ │ (用户身份) │ │ (额度) │ + 183| └─────────┘ └──────────────┘ └─────────┘ + 184|``` + 185| + 186|### 4.2 依赖矩阵 + 187| + 188|| ↓ 消费者 \ 提供者 → | identity | planning | quota | outreach | support | risk | review | creator | audit | + 189|| --- |:---:|:---:|:---:|:---:|:---:|:---:|:---:|:---:|:---:| + 190|| **identity** | - | - | - | - | - | R | - | - | E | + 191|| **planning** | **R** | - | R | - | - | R | R | - | E | + 192|| **quota** | **R** | - | - | - | - | - | R | - | E | + 193|| **outreach** | R | R | R | - | - | R | - | - | E | + 194|| **support** | R | - | - | - | - | R | - | - | E | + 195|| **risk** | R | - | - | - | - | - | - | - | E | + 196|| **review** | R | R | - | - | - | - | - | R | E | + 197|| **creator** | - | R | R | - | - | - | - | - | E | + 198|| **audit** | - | - | - | - | - | - | - | - | - | + 199| + 200|**图例：** `R` = 只读依赖（通过 API 查询），`E` = 事件发送（fire-and-forget），`-` = 无依赖 + 201| + 202|### 4.3 启动依赖（必须就绪才能工作） + 203| + 204|| 子系统 | 启动依赖 | 说明 | + 205|| --- | --- | --- | + 206|| identity | 无硬依赖 | 可独立启动（需要 JOYHUB 数据同步） | + 207|| planning | identity（软依赖） | 无 identity 时可先操作，但无法做人群匹配 | + 208|| quota | identity（软依赖） | 额度按真实人计算，未归并时按单一账号 | + 209|| outreach | identity, planning, quota（软依赖） | 无依赖时可先建渠道基础设施 | + 210|| support | identity（软依赖） | 无用户上下文卡时可先跑工单 | + 211|| risk | identity（软依赖） | 强/弱关联依赖身份数据 | + 212|| review | identity, planning（软依赖） | 评价需关联计划和用户 | + 213|| creator | planning（软依赖） | 免评计划入口 | + 214|| audit | 无硬依赖 | 完全独立 | + 215| + 216|> **软依赖** = 可降级运行，核心功能不受阻。例如 outreach 在 identity 不可用时仍可发送消息，但缺少用户上下文。 + 217| + 218|--- + 219| + 220|## 5. 角色 → 独立前端映射 + 221| + 222|### 5.1 前端应用矩阵 + 223| + 224|| 前端应用 | 目标角色 | 集成的子系统 | 部署形态 | + 225|| --- | --- | --- | --- | + 226|| **运营工作台** | Amazon 运营、Amazon 运营总监 | planning + review + quota (查询) | Web SPA | + 227|| **用户运营中心** | 用户运营、用户运营负责人/组长 | planning + outreach + quota + review | Web SPA | + 228|| **客服工作台** | 菲律宾客服组员 | support + identity (上下文卡) + outreach (TEL) | Web SPA / 桌面端 | + 229|| **客服管理台** | 菲律宾客服负责人、客服组长 | support (管理模块) + audit | Web SPA | + 230|| **风险控制台** | 风险/黑名单相关人员 | risk + identity (上下文卡) + audit | Web SPA | + 231|| **达人协作台** | KOC/KOL 运营 | creator + outreach (协同) + review (免评结果) | Web SPA | + 232|| **管理驾驶舱** | 运营总监、用户运营负责人 | 跨子系统聚合看板 (planning + outreach + support + review) | Web SPA | + 233| + 234|### 5.2 角色-功能矩阵 + 235| + 236|| 功能 \ 角色 | Amazon运营 | 运营总监 | 用户运营 | 用户负责人 | 客服组员 | 客服组长 | 客服负责人 | 风险人员 | KOC运营 | + 237|| --- |:---:|:---:|:---:|:---:|:---:|:---:|:---:|:---:|:---:| + 238|| 提需求（推新/回评/免评） | ✓ | ✓ | - | - | - | - | - | - | - | + 239|| 审批计划 | - | ✓ | - | ✓ | - | - | - | - | - | + 240|| 评估需求 | - | - | ✓ | ✓ | - | - | - | - | - | + 241|| 生成计划/调资源 | - | - | ✓ | ✓ | - | - | - | - | - | + 242|| 查看 ASIN 健康 | ✓ | ✓ | ✓ | - | - | - | - | - | - | + 243|| 处理工单 | - | - | - | - | ✓ | ✓ | - | - | - | + 244|| 分配工单 | - | - | - | - | - | ✓ | ✓ | - | - | + 245|| 电话外呼/接听 | - | - | - | - | ✓ | - | - | - | - | + 246|| 查看排班出勤 | - | - | - | - | - | ✓ | ✓ | - | - | + 247|| 绩效统计 | - | - | - | - | - | ✓ | ✓ | - | - | + 248|| 风险审核 | - | - | - | - | - | - | - | ✓ | - | + 249|| 黑名单管理 | - | - | - | - | - | - | - | ✓ | - | + 250|| KOC/KOL 匹配 | - | - | - | - | - | - | - | - | ✓ | + 251|| 内容跟踪 | - | - | ✓ | - | - | - | - | - | ✓ | + 252| + 253|--- + 254| + 255|## 6. 子系统内外边界明细 + 256| + 257|### 6.1 identity — 用户身份与上下文 + 258| + 259|| 维度 | 说明 | + 260|| --- | --- | + 261|| **对内** | 管理真实人归并逻辑、身份线索关联（JOYHUB ID↔邮箱↔电话↔设备↔订单→真实人ID）、用户上下文卡聚合与快照、设备变化识别 | + 262|| **对外（提供给其他子系统）** | `GET /api/identity/person/{context}` — 按线索查真实人；`GET /api/identity/context/{person_id}` — 用户上下文卡；`POST /api/identity/merge` — 归并请求 | + 263|| **依赖外部系统** | JOYHUB（用户基础数据）、APP（设备数据） | + 264|| **待确认边界** | 真实人归并是自动还是人工确认？归并拆分（合并错了如何回退）？非 APP 用户的身份线索从哪里同步（ESM 的邮箱清洗？） | + 265| + 266|### 6.2 planning — 需求与计划管理 + 267| + 268|| 维度 | 说明 | + 269|| --- | --- | + 270|| **对内** | 需求触发（人工提交 + 自动触发规则）、需求评估、计划创建（推新/回评/免评）、审批工作流、ASIN 基础信息管理 | + 271|| **对外（提供给其他子系统）** | `GET /api/plans/{id}` — 计划详情；`GET /api/plans?status=approved` — 待执行计划；`POST /api/demands` — 创建需求 | + 272|| **依赖外部系统** | Amazon（ASIN 数据、销售数据、评价缺口） | + 273| + 274|### 6.3 quota — 额度与频控 + 275| + 276|| 维度 | 说明 | + 277|| --- | --- | + 278|| **对内** | 额度台账（测评4/免评4/累计12）、额度预占与释放、频控规则引擎、发送前终校 | + 279|| **对外（提供给其他子系统）** | `GET /api/quota/check/{person_id}?type=测评` — 额度查询+预占；`POST /api/quota/reserve` — 预占；`POST /api/quota/commit` — 确认占用 | + 280|| **依赖外部系统** | 无直接外部系统依赖 | + 281|| **待确认边界** | 额度预占有效期多长？跨月额度如何处理（月末最后一天预占，下月一号释放还是保留？） | + 282| + 283|### 6.4 outreach — 多渠道触达引擎 + 284| + 285|| 维度 | 说明 | + 286|| --- | --- | + 287|| **对内** | 渠道路由决策、渠道去重、IM 推送（分层 A/B/C）、EDM 发送与行为追踪、APP Push、TEL 任务生成 | + 288|| **对外（提供给其他子系统）** | `POST /api/outreach/send` — 发送触达；`GET /api/outreach/history/{person_id}` — 触达历史 | + 289|| **依赖外部系统** | JOYHUB（IM 通道）、ESP（EDM）、FCM/APNs（APP Push）、电话系统（TEL） | + 290|| **待确认边界** | IM 具体是什么平台（WhatsApp/自研 IM）？EDM 模板管理在 outreach 内还是独立内容管理？APP Push 是否复用 JOYHUB 现有 Push 通道？ | + 291| + 292|### 6.5 support — 客服工单与管理 + 293| + 294|| 维度 | 说明 | + 295|| --- | --- | + 296|| **对内** | 工单生命周期、自动分配（按排班/在线/负载）、答应配合状态机、出勤/排班/绩效 | + 297|| **对外（提供给其他子系统）** | `POST /api/tickets` — 创建工单；`GET /api/tickets/{id}` — 工单详情；`GET /api/support/stats` — 绩效数据 | + 298|| **依赖外部系统** | 无直接外部系统依赖（电话记录来自 outreach TEL 模块） | + 299|| **待确认边界** | 客服是否使用独立 IM 工具还是复用 outreach 的 IM 通道？排班数据是否与现有 HR 系统对接？ | + 300| + 301|### 6.6 risk — 风险与反欺诈 + 302| + 303|| 维度 | 说明 | + 304|| --- | --- | + 305|| **对内** | 强弱关联判断、黑名单实体管理、风险事件管理、双重退款检测（Amazon退款 vs OA返款） | + 306|| **对外（提供给其他子系统）** | `GET /api/risk/check/{person_id}` — 风险查询；`POST /api/risk/report` — 上报风险信号 | + 307|| **依赖外部系统** | Amazon（退款数据）、财务系统（OA 返款数据） | + 308| + 309|### 6.7 review — 评价结果追踪 + 310| + 311|| 维度 | 说明 | + 312|| --- | --- | + 313|| **对内** | 用户真实提交评价记录、Amazon 展示核验、ASIN 健康更新回流、计划完成度计算 | + 314|| **对外（提供给其他子系统）** | `POST /api/reviews/submission` — 记录提交；`GET /api/reviews/status/{plan_id}` — 计划评价进度 | + 315|| **依赖外部系统** | Amazon（评价展示状态、ASIN 评分数据） | + 316| + 317|### 6.8 creator — KOC/KOL 协作 + 318| + 319|| 维度 | 说明 | + 320|| --- | --- | + 321|| **对内** | KOC/KOL 匹配筛选、内容 Brief/Code 分配、内容发布跟踪、带货结果跟踪 | + 322|| **对外（提供给其他子系统）** | `GET /api/creators/match?plan_id=` — 匹配推荐；`POST /api/creators/tasks` — 创建协作任务 | + 323|| **依赖外部系统** | JOYCOLLAB（KOC/KOL 数据、内容数据、Code 使用、带货订单） | + 324| + 325|### 6.9 audit — 审计与通知中心 + 326| + 327|| 维度 | 说明 | + 328|| --- | --- | + 329|| **对内** | 所有子系统的状态变更审计、敏感字段访问日志、多类型通知（额度预警/超时提醒/紧急 Listing 告警/审批通知） | + 330|| **对外（提供给其他子系统）** | `POST /api/audit/event` — 上报审计事件；`POST /api/notifications/send` — 发送通知 | + 331|| **依赖外部系统** | 通知可能通过 IM/EDM/APP Push 等通道（可复用 outreach 通道或独立） | + 332|| **待确认边界** | 审计日志保留策略？通知模板管理在 audit 内还是需要独立内容管理？ | + 333| + 334|--- + 335| + 336|## 7. 总系统级业务澄清问题清单 + 337| + 338|> 以下问题需要与业务方确认，涉及跨子系统边界、关键业务规则和外部系统对接。 + 339| + 340|### 7.1 外部系统对接（8 项） + 341| + 342|| # | 问题 | 涉及外部系统 | 优先级 | + 343|| --- | --- | --- | --- | + 344|| Q-E1 | Amazon 数据以什么方式接入？（MWS/SP-API 授权拉取、爬虫、CSV 导入、已有中间表？） | Amazon | **P0** | + 345|| Q-E2 | JOYHUB 现有数据有哪些可用？是否有现成 API？JOYHUB ID ↔ 邮箱 ↔ 设备 ↔ 订单 的关联数据是否已存储？ | JOYHUB | **P0** | + 346|| Q-E3 | JOYCOLLAB 数据同步方向是单向（COLLAB→USER）还是双向？同步频率？Code 生成是在 COLLAB 还是 USER？ | JOYCOLLAB | **P0** | + 347|| Q-E4 | 当前 EDM 使用什么邮件服务？（SendGrid / Mailchimp / SES / 自建？）是否有现成的送达/打开/点击追踪？ | ESP | **P0** | + 348|| Q-E5 | OA 返款系统是哪个？是否有 API 可以查询返款状态和返款记录？（用于双重退款比对） | 财务系统 | **P0** | + 349|| Q-E6 | APP Push 是否复用 JOYHUB 现有 Push 通道还是需要独立接入 FCM/APNs？ | APP Push | P1 | + 350|| Q-E7 | 电话系统用什么方案？（自建 SIP / 第三方云呼叫中心？）是否已有通话记录存储？ | 电话系统 | P1 | + 351|| Q-E8 | IM 平台具体是什么？（WhatsApp Business API / 自研 IM / Facebook Messenger？） | IM 平台 | P1 | + 352| + 353|### 7.2 用户身份体系（5 项） + 354| + 355|| # | 问题 | 优先级 | + 356|| --- | --- | --- | + 357|| Q-I1 | 「真实人」归并是完全自动还是需要人工确认？自动归并错误时如何拆分？（拆分会影响到已关联的历史评价和额度） | **P0** | + 358|| Q-I2 | 非 APP 用户（只知道邮箱）如何建立真实人？没有设备号仅凭邮箱+收件地址归并，置信度阈值如何定？ | **P0** | + 359|| Q-I3 | JOYHUB ID 与真实人是 1:1 还是 N:1？（一个真实人可能拥有多个 JOYHUB ID） | P1 | + 360|| Q-I4 | 设备变化的「换机」判定标准是什么？（同一 JOYHUB ID 下设备号变化？多久内变化算换机？） | P1 | + 361|| Q-I5 | 用户上下文卡的「快照」是否需要保留历史版本？（每次互动生成新快照 vs 覆盖上次） | P2 | + 362| + 363|### 7.3 额度与频控规则（6 项） + 364| + 365|| # | 问题 | 优先级 | + 366|| --- | --- | --- | + 367|| Q-Q1 | 月度额度按自然月还是按 30 天滚动？如果是自然月，预占在月末最后一天是否需要特殊处理？ | **P0** | + 368|| Q-Q2 | 「测评 4 次」的「次」定义：是指参与 4 个不同的测评计划，还是提交 4 次评价？（如果一次计划要求用户提交多条评价怎么算） | **P0** | + 369|| Q-Q3 | 「累计 12 个评价」是永久上限还是可以重置？（例如用户长期优质，是否可以放宽？） | P1 | + 370|| Q-Q4 | 额度预占的有效期多长？如果预占后用户始终未响应，多久释放额度？ | P1 | + 371|| Q-Q5 | 频控规则中的「渠道频控」具体阈值是多少？（IM 每日最多推几次？EDM 每周最多几封？） | P1 | + 372|| Q-Q6 | 「接近上限时提前预警」——预警阈值是还剩 1 次还是还剩 N%？ | P2 | + 373| + 374|### 7.4 计划与审批流程（5 项） + 375| + 376|| # | 问题 | 优先级 | + 377|| --- | --- | --- | + 378|| Q-P1 | 自动触发需求的条件是什么？（ASIN 评分低于多少？评价缺口多少条？Listing 健康到什么程度？） | **P0** | + 379|| Q-P2 | 审批链中的「指定负责人」如何确定？（系统自动按规则还是人工指定？规则是什么？） | **P0** | + 380|| Q-P3 | 计划审批后是否可以修改？修改是否需要重新审批？ | P1 | + 381|| Q-P4 | 计划之间是否有互斥关系？（同一个 ASIN 同时跑推新和回评计划是否可以？） | P1 | + 382|| Q-P5 | 「紧急计划」的判定标准和特殊审批流程？（谁可以标记为紧急？是否跳过某些审批节点？） | P1 | + 383| + 384|### 7.5 渠道协同与去重（5 项） + 385| + 386|| # | 问题 | 优先级 | + 387|| --- | --- | --- | + 388|| Q-C1 | 渠道优先级路由规则是否需要可配置？（例如针对某类用户调整 IM > EDM 的优先级） | **P0** | + 389|| Q-C2 | 用户已在客服工单中时「暂停自动触达」——是所有渠道暂停还是仅暂停与当前工单相关的渠道？ | P1 | + 390|| Q-C3 | EDM 引导注册 APP 后，如何识别「该 EDM 邮箱对应该 APP 用户」？靠什么字段关联？ | P1 | + 391|| Q-C4 | 渠道去重中「同一计划同一用户不重复通过多渠道路由」——如果高优先级渠道发送失败（退信/未送达），是否自动降级到下一渠道？ | P1 | + 392|| Q-C5 | IM 推送中的「催评卡片」和 APP Push 中的「催评推送」如何协调？（两者会不会同时推送给同一用户？） | P1 | + 393| + 394|### 7.6 客服与工单（5 项） + 395| + 396|| # | 问题 | 优先级 | + 397|| --- | --- | --- | + 398|| Q-S1 | 工单自动分配算法——「当前负载」如何计算？（按未关闭工单数？按最近 N 小时处理量？） | **P0** | + 399|| Q-S2 | 客服的「在线状态」如何获取？（手动切换在线/离线，还是自动检测活跃度？） | P1 | + 400|| Q-S3 | 「答应配合」的超时判定——答应后多少天未提交算超时？超时后提醒频率？ | P1 | + 401|| Q-S4 | 出勤排班是否与本系统内的排班模块管理还是对接外部 HR 系统？ | P1 | + 402|| Q-S5 | 客服转化统计中的 RSO（回评）和 RDO（测评）如何区分？（按工单来源？按最终结果？） | P2 | + 403| + 404|### 7.7 风险与反欺诈（4 项） + 405| + 406|| # | 问题 | 优先级 | + 407|| --- | --- | --- | + 408|| Q-R1 | 「强关联」中哪些维度的命中可以直接自动化拦截，哪些需要人工复核？（文档说一旦命中直接进入高风险，但实际执行中是否所有强关联都自动拦截？） | **P0** | + 409|| Q-R2 | 双重退款检测——Amazon 退款数据如何及时获取？（T+1 同步？实时 Webhook？手动导入？） | **P0** | + 410|| Q-R3 | 黑名单是否有过期/申诉/解除机制？什么条件下可以从黑名单中移除？ | P1 | + 411|| Q-R4 | 风险信号的「弱关联」观察期多长？观察期过后是自动解除还是人工确认？ | P1 | + 412| + 413|### 7.8 评价结果与回流（4 项） + 414| + 415|| # | 问题 | 优先级 | + 416|| --- | --- | --- | + 417|| Q-V1 | Amazon 评价展示的核验方式是什么？（定时爬取 Amazon 页面？手动录入？用户上传截图？API？） | **P0** | + 418|| Q-V2 | 「Amazon 未展示 / 暂不可核验」的评价进入异常观察队列后，观察多久？复查频率？ | P1 | + 419|| Q-V3 | ASIN 健康「回流」的具体含义是什么？（更新 ASIN 评分/评价数到 planning 子系统，触发新一轮需求？） | P1 | + 420|| Q-V4 | 一个用户可能为多个 ASIN 提交评价——这些评价是否都计入同一个计划的完成度？ | P1 | + 421| + 422|### 7.9 KOC/KOL 协作（4 项） + 423| + 424|| # | 问题 | 优先级 | + 425|| --- | --- | --- | + 426|| Q-K1 | JOYCOLLAB 中 KOC/KOL 数据字段有哪些？（粉丝量、平台、国家、历史效果——文档提到但需确认完整字段） | **P0** | + 427|| Q-K2 | 「匹配 KOC/KOL」是运营人工选择还是系统自动推荐？推荐算法依赖什么数据？ | P1 | + 428|| Q-K3 | Code 是 JOYCOLLAB 生成还是 USER 系统生成？是一对一（每个 KOC 独立 Code）还是一对多？ | P1 | + 429|| Q-K4 | KOC/KOL 的财务结算（提成/返点）是完全在财务系统还是在 USER 系统内触发？ | P1 | + 430| + 431|### 7.10 数据迁移与历史兼容（3 项） + 432| + 433|| # | 问题 | 优先级 | + 434|| --- | --- | --- | + 435|| Q-D1 | 现有 USER 后台 ERP 系统（`C:\XCODE\USER`）是否完全废弃还是部分模块保留？新旧系统切换策略？ | **P0** | + 436|| Q-D2 | 历史数据（已有评价记录、用户数据、工单记录）是否需要迁移到新系统？迁移范围和清洗策略？ | **P0** | + 437|| Q-D3 | 旧系统中存在的用户额度数据如何初始化？（历史测评次数、免评次数、累计评价数如何确定？） | **P0** | + 438| + 439|### 7.11 项目分期与 MVP 范围（5 项） + 440| + 441|| # | 问题 | 优先级 | + 442|| --- | --- | --- | + 443|| Q-M1 | 项目一期（MVP）的最小范围是什么？9 个子系统中哪些是必须的、哪些可以二期再做？ | **P0** | + 444|| Q-M2 | MVP 先支持哪个 Amazon 站点？（.com？还是多站点？）先支持哪种计划类型？（推新/回评/免评全部 or 先做回评？） | **P0** | + 445|| Q-M3 | 前端应用的优先级——7 个前端中哪些是 MVP 必须有？（客服工作台+运营工作台？还是全部都要？） | **P0** | + 446|| Q-M4 | 项目整体时间线和里程碑约束？（6 个月？1 年？是否有硬性 deadline？） | P1 | + 447|| Q-M5 | 开发团队规模和结构？（几个后端开发？几个前端？是否有专职 QA？）是否支持 9 个子系统并行开发？ | P1 | + 448| + 449|### 7.12 基础设施与部署（6 项） + 450| + 451|| # | 问题 | 优先级 | + 452|| --- | --- | --- | + 453|| Q-IN1 | 部署环境？（云厂商 AWS/阿里云？自建机房？）是否已有 Kubernetes 集群或考虑容器化部署？ | **P0** | + 454|| Q-IN2 | 数据库选型？（PostgreSQL / MySQL？）每子系统独立数据库还是共享数据库？是否已有数据库团队和规范？ | **P0** | + 455|| Q-IN3 | 子系统间异步通信方案？（消息队列：Kafka/RabbitMQ/Redis？还是全部同步 HTTP？） | **P0** | + 456|| Q-IN4 | API 网关选型？（Kong/Nginx/自研？）认证鉴权方案？（JWT/OAuth2/SSO？） | P1 | + 457|| Q-IN5 | 日志、监控、链路追踪方案？（ELK/Prometheus+Grafana/Jaeger？）是否已有公司级基础设施可复用？ | P1 | + 458|| Q-IN6 | 灾备和容灾要求？（RPO/RTO 目标？是否需要多可用区/异地容灾？数据备份频率？） | P2 | + 459| + 460|### 7.13 安全与合规（5 项） + 461| + 462|| # | 问题 | 优先级 | + 463|| --- | --- | --- | + 464|| Q-SC1 | 是否有需要通过的安全合规认证？（SOC2 / ISO 27001 / 等保？）对系统架构有何约束？ | P1 | + 465|| Q-SC2 | 用户个人数据（邮箱、电话、地址、设备号）的保留和删除策略？（GDPR 的「被遗忘权」如何处理？） | P1 | + 466|| Q-SC3 | Amazon 的 API 使用条款（SP-API Acceptable Use Policy）对数据存储和使用的限制？（评价数据是否可以长期存储？） | P1 | + 467|| Q-SC4 | 系统权限模型？（RBAC？角色和权限的粒度？是否需要支持数据行级权限——例如不同站点的运营只看自己的 ASIN？） | P1 | + 468|| Q-SC5 | 敏感数据（收款信息、设备号）的加密存储方案？传输加密（TLS）要求？ | P2 | + 469| + 470|### 7.14 技术栈与规范（4 项） + 471| + 472|| # | 问题 | 优先级 | + 473|| --- | --- | --- | + 474|| Q-TS1 | 后端技术栈偏好？（Python/FastAPI？Go？Node.js？Java？）是否有公司技术栈约束？ | P1 | + 475|| Q-TS2 | 前端技术栈偏好？（React/Vue/Angular？）是否有公司前端组件库或设计系统可复用？ | P1 | + 476|| Q-TS3 | API 规范标准？（OpenAPI 3.0？gRPC？）是否需要 BFF（Backend for Frontend）层？ | P2 | + 477|| Q-TS4 | 代码仓库策略？（Monorepo or Polyrepo？9 个子系统分仓库还是一仓库？CI/CD 工具？） | P2 | + 478| + 479|### 7.15 多站点与多市场（4 项） + 480| + 481|| # | 问题 | 优先级 | + 482|| --- | --- | --- | + 483|| Q-MS1 | 系统需要支持多少个 Amazon 站点？（.com / .co.uk / .de / .fr / .it / .es / .jp / .ca？）不同站点的业务流程是否一致？ | **P0** | + 484|| Q-MS2 | 多站点下「真实人」归并是否跨站点？（同一个真实人在 .com 和 .co.uk 用不同邮箱/账号——是否归并为同一人？） | P1 | + 485|| Q-MS3 | 额度规则是否跨站点？（测评 4 次是每个站点独立还是全局？累计 12 个评价呢？） | P1 | + 486|| Q-MS4 | 未来是否扩展到 Amazon 以外的平台（eBay/Walmart/独立站）？架构上需要预留扩展点吗？ | P2 | + 487| + 488|### 7.16 内容与素材管理（3 项） + 489| + 490|| # | 问题 | 优先级 | + 491|| --- | --- | --- | + 492|| Q-CM1 | EDM 模板、IM 推送话术、APP Push 文案的创建和维护由谁负责？（内容运营？用户运营？）是否需要独立的内容管理子系统？ | P1 | + 493|| Q-CM2 | 多语言内容策略？（面向美国用户的英文消息、面向德国用户的德语消息——模板由谁翻译和维护？系统是否需要自动翻译？） | P1 | + 494|| Q-CM3 | 图片/视频素材（产品图片、测评指引图）的存储和管理？是否需要 CDN？ | P2 | + 495| + 496|### 7.17 业务量级预估（4 项） + 497| + 498|| # | 问题 | 优先级 | + 499|| --- | --- | --- | + 500|| Q-BV1 | 系统需要管理的 ASIN 数量级？（几十个？几百个？几千个？） | P1 | + 501|| Q-BV2 | 日活跃用户数（APP 端）？日触达消息量（IM+EDM+APP Push+TEL）？ | P1 | + 502|| Q-BV3 | 客服团队规模？（几个组？每组多少人？峰值工单量？） | P1 | + 503|| Q-BV4 | 峰值场景预估？（Prime Day / Black Friday 期间流量和触达量是平时的几倍？） | P2 | + 504| + 505|### 7.18 外部系统对接细节（4 项） + 506| + 507|| # | 问题 | 优先级 | + 508|| --- | --- | --- | + 509|| Q-EX1 | 各外部系统的 SLA 和可用性？（Amazon SP-API 的 rate limit？JOYHUB 的响应时间？）当外部系统不可用时的降级策略？ | P1 | + 510|| Q-EX2 | 外部系统的认证方式？（Amazon SP-API 的 OAuth 授权流程？JOYHUB 的 API Key？）谁负责管理这些凭证？ | P1 | + 511|| Q-EX3 | 数据同步的增量 or 全量策略？（Amazon 订单是增量拉取最近 N 天还是全量同步？JOYHUB 用户数据呢？） | P1 | + 512|| Q-EX4 | 外部系统数据格式和字段映射是否已有文档？（Amazon 订单字段→系统内部字段的映射关系？） | P2 | + 513| + 514|--- + 515| + 516|## 8. 待确认的内外边界 + 517| + 518|> 以下边界由于文档信息不足，标记为「待确认」，需要在后续与业务方或技术团队确认。 + 519| + 520|| # | 边界问题 | 影响范围 | 建议确认方式 | + 521|| --- | --- | --- | --- | + 522|| B1 | **内容/素材管理归属**：EDM 模板、IM 推送话术、APP Push 文案由哪个子系统管理？是 outreach 内的内容模块，还是独立的内容管理子系统？ | outreach | 与内容运营角色确认工作流 | + 523|| B2 | **品牌/内容运营角色**：文档提到品牌运营和内容运营但目前不展开。他们是否需要独立前端？需求何时明确？ | planning / creator | 与业务方确认是否一期纳入 | + 524|| B3 | **数据仓库/BI 边界**：文档明确「完整 BI/财务/ROI 系统」不在本版主流程，但管理驾驶舱涉及聚合看板。看板数据是子系统直接提供聚合 API 还是走独立数据仓库？ | 全部 | 与数据团队确认数据架构 | + 525|| B4 | **外部系统降级策略**：Amazon API 不可用时，哪些功能可以降级运行？JOYHUB 不可用时用户身份如何兜底？ | identity / planning / review | 制定 SLA 和降级方案 | + 526|| B5 | **多语言支持**：系统前端是否只面向菲律宾客服（英文？）还是国内团队也使用（中文？） | 所有前端 | 确认各前端的语言需求 | + 527|| B6 | **定时任务归属**：自动需求触发、EDM 批处理、超时检测、评价核验等定时任务在各子系统内实现还是有统一调度器？ | 多个子系统 | 确认是否引入统一任务调度 | + 528| + 529|--- + 530| + 531|## 9. 附录：子系统文档索引 + 532| + 533|| 文档 | 描述 | + 534|| --- | --- | + 535|| [01-子系统-用户身份与上下文](01-子系统-用户身份与上下文.md) | 真实人归并、用户上下文卡、设备识别 | + 536|| [02-子系统-需求与计划管理](02-子系统-需求与计划管理.md) | 需求触发、计划生命周期、审批工作流 | + 537|| [03-子系统-额度与频控](03-子系统-额度与频控.md) | 额度台账、频控引擎、预占释放 | + 538|| [04-子系统-多渠道触达引擎](04-子系统-多渠道触达引擎.md) | IM/EDM/APP/TEL 调度与执行 | + 539|| [05-子系统-客服工单与管理](05-子系统-客服工单与管理.md) | 工单管理、客服管理支撑 | + 540|| [06-子系统-风险与反欺诈](06-子系统-风险与反欺诈.md) | 风险判断、黑名单、双重退款 | + 541|| [07-子系统-评价结果追踪](07-子系统-评价结果追踪.md) | 评价提交、展示核验、结果回流 | + 542|| [08-子系统-KOC-KOL协作](08-子系统-KOC-KOL协作.md) | KOC/KOL 匹配、内容跟踪、JOYCOLLAB 同步 | + 543|| [09-子系统-审计与通知中心](09-子系统-审计与通知中心.md) | 审计日志、多类型通知告警 | + 544| \ No newline at end of file diff --git a/wishfulfilled-wiki/05_需求文档/01-子系统-用户身份与上下文.md b/wishfulfilled-wiki/05_需求文档/01-子系统-用户身份与上下文.md new file mode 100644 index 0000000..7ec32ea --- /dev/null +++ b/wishfulfilled-wiki/05_需求文档/01-子系统-用户身份与上下文.md @@ -0,0 +1,199 @@ +# 子系统 01 — 用户身份与上下文 (`identity`) v1.0 + +## 子系统概述 + +| 维度 | 说明 | +| --- | --- | +| 代号 | `identity` | +| 核心职责 | 真实人识别与归并、身份线索关联、用户上下文卡生成 | +| 数据所有权 | `person_profiles`, `person_identity_links`, `contact_context_snapshots`, `device_records` | +| 启动依赖 | 无硬依赖（需 JOYHUB 数据同步到位） | +| 外部系统依赖 | JOYHUB（用户数据）、APP（设备数据） | + +--- + +## 1. 模块划分 + +### 整体模块图 + +``` +┌─────────────────────────────────────────────────────────────┐ +│ identity 子系统 │ +│ │ +│ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │ +│ │ M1: 身份线索 │ │ M2: 真实人 │ │ M3: 用户上下 │ │ +│ │ 采集与同步 │→│ 归并引擎 │→│ 文卡服务 │ │ +│ └──────┬───────┘ └──────┬───────┘ └──────┬───────┘ │ +│ │ │ │ │ +│ ▼ ▼ ▼ │ +│ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │ +│ │ M4: 设备变化 │ │ M5: 身份管理 │ │ M6: 对外 API │ │ +│ │ 识别 │ │ Admin │ │ Gateway │ │ +│ └──────────────┘ └──────────────┘ └──────────────┘ │ +│ │ +└─────────────────────────────────────────────────────────────┘ +``` + +### 模块明细 + +| # | 模块 | 代号 | 职责 | +| --- | --- | --- | --- | +| M1 | 身份线索采集与同步 | `identity-ingest` | 从 JOYHUB、APP 等外部系统拉取/接收身份线索（JOYHUB ID、邮箱、电话、设备号、订单关联） | +| M2 | 真实人归并引擎 | `person-merge` | 按标准姓名+地址、多线索交叉权重归并，生成/更新真实人 ID | +| M3 | 用户上下文卡服务 | `context-card` | 聚合身份+交易+服务+风险+设备+触达全量数据生成上下文快照 | +| M4 | 设备变化识别 | `device-tracker` | 识别设备号变化、换机、多设备场景，记录设备变化日志 | +| M5 | 身份管理 Admin | `identity-admin` | 人工归并/拆分操作、归并冲突处理、身份数据校正 | +| M6 | 对外 API Gateway | `identity-api` | 向其他子系统提供真实人查询、上下文卡查询、归并请求等 API | + +--- + +## 2. 各模块内外说明 + +### 2.1 M1: 身份线索采集与同步 + +| 维度 | 说明 | +| --- | --- | +| **对内** | 管理外部系统的数据同步任务（定时拉取 JOYHUB 用户数据、设备数据）；解析和标准化各来源的身份线索（邮箱规范化、电话格式化、地址标准化）；写入 `person_identity_links` 表 | +| **对外接口** | `POST /internal/identity/ingest — 接收上游推送的身份线索`；同步调度器可配置频率 | +| **数据写入** | `person_identity_links`（线索类型 + 线索值 + 来源系统 + 采集时间） | + +### 2.2 M2: 真实人归并引擎 + +| 维度 | 说明 | +| --- | --- | +| **对内** | 执行归并规则：标准姓名+地址一致→同一真实人；多线索交叉（设备+电话+邮箱+收款信息）按权重打分；地址一致姓名不同→标记家庭关联但不合并；生成真实人 ID、归并证据、置信度 | +| **对外接口** | `POST /api/identity/merge — 触发归并`；返回归并结果（真实人 ID + 置信度） | +| **数据写入** | `person_profiles`（真实人创建/更新）、`person_identity_links`（关联关系更新） | +| **关键规则** | 邮箱不同+JOYHUB ID 不同不能单独否定「同一真实人」；订单号命中历史异常需拉出风险记录 | + +### 2.3 M3: 用户上下文卡服务 + +| 维度 | 说明 | +| --- | --- | +| **对内** | 聚合 6 组字段（当前身份、真实人归并、历史交易、历史服务、历史风险、当前设备、触达历史）；生成上下文快照（含快照时间）；首次生成 vs 增量更新 | +| **对外接口** | `GET /api/identity/context/{person_id} — 获取用户上下文卡`；返回聚合后的全量上下文 | +| **数据写入** | `contact_context_snapshots` | +| **依赖其他子系统** | 交易数据来自 planning；服务数据来自 support；风险数据来自 risk；触达数据来自 outreach（通过 API 聚合或事件） | + +### 2.4 M4: 设备变化识别 + +| 维度 | 说明 | +| --- | --- | +| **对内** | 监控同一 JOYHUB ID 下设备号变化；记录换机/多设备事件；关联设备型号、系统版本、APP 版本变化 | +| **对外接口** | 内部事件 `device.changed` 供其他模块消费 | +| **数据写入** | `device_records`（设备变化时间、变化类型） | +| **待确认** | 多久内的设备变化算「近期换机」？多设备同时活跃如何标记？ | + +### 2.5 M5: 身份管理 Admin + +| 维度 | 说明 | +| --- | --- | +| **对内** | 提供人工归并操作界面（两个真实人合并为一个）；归并拆分（合并错了如何回退）；冲突处理（系统自动归并 vs 人工判定不一致时） | +| **对外接口** | 管理 API（不对其他子系统暴露） | +| **数据写入** | 所有身份相关表（权限控制） | + +### 2.6 M6: 对外 API Gateway + +| 维度 | 说明 | +| --- | --- | +| **对内** | 统一对外 API 认证、限流、日志 | +| **对外接口** | `GET /api/identity/person?线索类型=&线索值=` — 按线索查真实人；`GET /api/identity/context/{person_id}` — 用户上下文卡；`POST /api/identity/batch-check` — 批量身份查询 | + +--- + +## 3. 对外 API 契约（草案） + +| 接口 | 方法 | 输入 | 输出 | 消费者 | +| --- | --- | --- | --- | --- | +| 按线索查真实人 | `GET /api/identity/person` | `?type=email&value=xxx@yy.com` 或 `?type=joyhub_id&value=123` | `{person_id, confidence, matched_clues[]}` | 所有子系统 | +| 获取用户上下文卡 | `GET /api/identity/context/{person_id}` | `person_id` | `{identity, transactions, services, risks, devices, outreach_history}` | support, risk, outreach | +| 批量身份查询 | `POST /api/identity/batch-check` | `[{type, value}, ...]` | `[{person_id, confidence}, ...]` | planning, outreach | +| 触发归并 | `POST /api/identity/merge` | `{clues: [{type, value}, ...]}` | `{person_id, is_new, confidence}` | outreach（每次互动时调用） | + +--- + +## 4. 数据对象（本子系统写入） + +| 对象 | 核心字段 | 说明 | +| --- | --- | --- | +| `person_profiles` | person_id, status, created_at, updated_at, merge_evidence | 真实人主表 | +| `person_identity_links` | person_id, clue_type (JOYHUB_ID/EMAIL/PHONE/DEVICE/ORDER_NAME_ADDRESS), clue_value, source, confidence, linked_at | 身份线索关联表 | +| `contact_context_snapshots` | person_id, snapshot_time, identity_snapshot, transaction_snapshot, service_snapshot, risk_snapshot, device_snapshot, outreach_snapshot | 上下文快照 | +| `device_records` | person_id, joyhub_id, device_id, device_model, os_version, app_version, change_type (NEW/SWITCH/MULTI), recorded_at | 设备变化记录 | + +--- + +## 5. 业务澄清问题清单 — identity + +### 5.1 真实人归并规则（4 项） + +| # | 问题 | 优先级 | +| --- | --- | --- | +| I-01 | 标准姓名+地址的「标准化」规则是什么？（大小写、空格、缩写如 St./Street、middle name 处理？）标准化在哪个模块做？ | **P0** | +| I-02 | 归并是多线索交叉权重打分——各维度的权重如何设定？（邮箱=0.3、设备=0.4、电话=0.2、收款=0.5？由谁定义？可否动态调整？） | **P0** | +| I-03 | 归并是完全自动执行还是部分需要人工审核？触发人工审核的条件是什么？（置信度 < 多少？涉及风险用户？） | **P0** | +| I-04 | 自动归并错误后如何拆分？拆分时如何处理已关联的历史评价和额度数据？（评价归属、额度扣减是否回滚？） | **P0** | + +### 5.2 非 APP 用户处理（3 项） + +| # | 问题 | 优先级 | +| --- | --- | --- | +| I-05 | 非 APP 用户的邮箱从哪里来？（Amazon 订单中的买家邮箱？EDM 列表？客服录入？）邮箱质量/有效性如何保证？ | **P0** | +| I-06 | 只有邮箱没有设备号的非 APP 用户，归并置信度是否单独设置较低阈值？这种情况下如何确定是同一真实人？ | P1 | +| I-07 | EDM 引导用户注册 APP 后——如何识别「这个新 APP 用户就是之前那个 EDM 邮箱用户」？（注册时要求填同一邮箱？设备号关联？） | P1 | + +### 5.3 设备与多账号（3 项） + +| # | 问题 | 优先级 | +| --- | --- | --- | +| I-08 | 「同设备多账号」的风险判断——同一个设备号关联了多个 JOYHUB ID，哪些情况正常（家庭共用）哪些算风险信号？ | P1 | +| I-09 | 设备号变化的识别窗口——同一个 JOYHUB ID 下，设备号变化间隔多久内算「近期换机」？ | P1 | +| I-10 | APP 卸载重装导致设备号变化怎么处理？（卸载重装可能生成新设备号） | P2 | + +### 5.4 用户上下文卡（3 项） + +| # | 问题 | 优先级 | +| --- | --- | --- | +| I-11 | 上下文卡的「快照」保留几份？每次互动生成新快照（保留历史）还是覆盖（只保留最新一份）？保留历史的话保留多久？ | P1 | +| I-12 | 上下文卡中的历史交易、历史服务等数据是从其他子系统实时拉取还是从本地冗余存储读取？（涉及跨子系统数据一致性） | P1 | +| I-13 | 上下文卡是否需要在某个条件触发时预生成（如用户接入前），还是每次实时生成？ | P2 | + +### 5.5 数据同步（2 项） + +| # | 问题 | 优先级 | +| --- | --- | --- | +| I-14 | JOYHUB 数据同步频率？（实时/每小时/每天？）同步方式？（API 拉取 / 消息队列 / 数据库直连？） | **P0** | +| I-15 | JOYHUB 和 APP 端的数据字段完整清单是否已有？（注册邮箱、设备号、设备型号、APP 版本、系统版本、绑定玩具、活跃行为——文档已列出但需确认是否有遗漏） | **P0** | + +### 5.6 身份数据生命周期（4 项） + +| # | 问题 | 优先级 | +| --- | --- | --- | +| I-16 | 用户数据保留策略——身份线索和历史快照保留多久？（6个月？1年？永久？）超出保留期后是归档还是删除？ | P1 | +| I-17 | 用户注销/数据删除请求如何处理？（用户要求删除所有个人数据——如何标记而不是物理删除以保持额度/风险记录的完整性？） | P1 | +| I-18 | 「被遗忘权」实操——删除真实人记录后，与之关联的额度、风险、评价如何处理？（匿名化保留？还是级联删除？） | P1 | +| I-19 | 用户主动修改关键身份信息（换邮箱、换电话）——系统如何感知和响应？（自动触发重新归并？还是保持原关联？） | P1 | + +### 5.7 多站点与跨平台身份（3 项） + +| # | 问题 | 优先级 | +| --- | --- | --- | +| I-20 | 同一个自然人在 Amazon.com 和 Amazon.co.uk 用不同邮箱和地址——是否跨站点归并为同一个「真实人」？ | P1 | +| I-21 | 未来扩展到非 Amazon 平台（eBay/Walmart/独立站）——真实人体系是否需要跨平台？架构预留？ | P2 | +| I-22 | 不同国家站点的地址标准化规则不同（US→州/邮编、UK→郡/邮编、DE→邮编/城市）——标准化引擎如何处理？ | P2 | + +### 5.8 归并冲突与人工干预（3 项） + +| # | 问题 | 优先级 | +| --- | --- | --- | +| I-23 | 系统自动归并和人工判定冲突时，以谁为准？（人工优先？系统告警→人工确认？）冲突记录保留多久？ | P1 | +| I-24 | 人工拆分归并的操作是否需要审批？（谁来审批？审批流程？）拆分的审计记录保留什么字段？ | P1 | +| I-25 | 是否存在「不确定」状态的真实人？（置信度太低无法归并，标记为「待定」——如何流转到人工审核？） | P1 | + +### 5.9 实施层面（3 项） + +| # | 问题 | 优先级 | +| --- | --- | --- | +| I-26 | 身份归并是实时还是异步？（用户接入时实时归并→阻塞用户体验 vs 异步归并→可能用旧数据？） | P1 | +| I-27 | 上下文卡聚合的性能要求——单次查询需要在多少 ms 内返回？（涉及跨子系统调用时的超时和降级） | P2 | +| I-28 | 如果 JOYHUB 数据同步中断，identity 子系统如何降级？（用缓存数据？标记为「数据可能过期」？） | P1 | diff --git a/wishfulfilled-wiki/05_需求文档/02-子系统-需求与计划管理.md b/wishfulfilled-wiki/05_需求文档/02-子系统-需求与计划管理.md new file mode 100644 index 0000000..99b70a6 --- /dev/null +++ b/wishfulfilled-wiki/05_需求文档/02-子系统-需求与计划管理.md @@ -0,0 +1,214 @@ +# 子系统 02 — 需求与计划管理 (`planning`) v1.0 + +## 子系统概述 + +| 维度 | 说明 | +| --- | --- | +| 代号 | `planning` | +| 核心职责 | 需求触发（人工/自动）、需求评估、计划生成（推新/回评/免评）、审批工作流、ASIN 基础信息管理 | +| 数据所有权 | `demands`, `plans`, `plan_items`, `approval_records`, `asin_catalog` | +| 启动依赖 | identity（软依赖，无 identity 可操作但无法做人群匹配） | +| 外部系统依赖 | Amazon（ASIN 数据、销售数据、评价缺口） | + +--- + +## 1. 模块划分 + +``` +┌─────────────────────────────────────────────────────────────┐ +│ planning 子系统 │ +│ │ +│ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │ +│ │ M1: 需求管理 │ │ M2: 计划引擎 │ │ M3: 审批工作 │ │ +│ │ (Demand) │→│ (Plan) │→│ 流 │ │ +│ └──────┬───────┘ └──────┬───────┘ └──────┬───────┘ │ +│ │ │ │ │ +│ ▼ ▼ ▼ │ +│ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │ +│ │ M4: 自动触发 │ │ M5: ASIN管理 │ │ M6: 对外 API │ │ +│ │ 规则引擎 │ │ │ │ Gateway │ │ +│ └──────────────┘ └──────────────┘ └──────────────┘ │ +│ │ +└─────────────────────────────────────────────────────────────┘ +``` + +| # | 模块 | 代号 | 职责 | +| --- | --- | --- | --- | +| M1 | 需求管理 | `demand-mgr` | 需求创建、评估（成立/待补充/驳回）、优先级管理、需求与 ASIN 关联 | +| M2 | 计划引擎 | `plan-engine` | 从已确认需求生成计划（推新/回评/免评）、计划生命周期管理、计划项拆解 | +| M3 | 审批工作流 | `approval-workflow` | 计划审批链（Amazon 运营总监→用户负责人→渠道负责人）、审批记录 | +| M4 | 自动触发规则引擎 | `auto-trigger` | 按 ASIN 健康度、评价缺口自动触发需求；定时评估触发条件 | +| M5 | ASIN 管理 | `asin-catalog` | ASIN 基础信息、评分、评价数、Listing 健康状态维护 | +| M6 | 对外 API Gateway | `planning-api` | 向其他子系统提供计划查询、ASIN 查询、审批状态查询 API | + +--- + +## 2. 各模块内外说明 + +### 2.1 M1: 需求管理 + +| 维度 | 说明 | +| --- | --- | +| **对内** | Amazon 运营人工提需求（选择 ASIN、指定类型：推新/回评/免评、目标数量、周期）；用户运营评估需求（查 ASIN 健康、目标数量、历史完成、当前资源）；评估结果：已确认/待补充/驳回 | +| **对外接口** | `POST /api/demands` — 创建需求；`PUT /api/demands/{id}/evaluate` — 评估需求 | +| **数据写入** | `demands` | +| **依赖** | `GET /api/identity/person` — 评估时可能需要运营人员身份 | +| **待确认** | 需求是否有优先级字段（P0/P1/P2）？驳回后是否允许重新提交？ | + +### 2.2 M2: 计划引擎 + +| 维度 | 说明 | +| --- | --- | +| **对内** | 从已确认需求生成计划草案（类型：推新/回评/免评）；计划参数（目标 ASIN、目标数量、周期、预算、备注）；计划状态流转；计划项拆解（将计划拆成可分配给渠道的执行单元） | +| **对外接口** | `POST /api/plans` — 创建计划；`PUT /api/plans/{id}/status` — 更新状态；`GET /api/plans/{id}/items` — 获取计划项 | +| **数据写入** | `plans`, `plan_items` | +| **依赖** | `GET /api/quota/check` — 生成人群前查询额度；`GET /api/risk/check` — 计划复核时查询风险 | +| **待确认** | 计划是否可以包含多个 ASIN？推新和回评是否可以合并为一个计划？ | + +### 2.3 M3: 审批工作流 + +| 维度 | 说明 | +| --- | --- | +| **对内** | 按计划类型路由不同审批链：（测评→Amazon运营总监 / 回评→总监或指定负责人 / 免评→总监+用户负责人 / 紧急→运营负责人+用户负责人+主管）；周/月推送计划审批（用户负责人→渠道负责人）；审批节点（通过/驳回/待补充） | +| **对外接口** | `POST /api/approvals/{plan_id}/submit` — 提交审批；`PUT /api/approvals/{plan_id}/review` — 审批决策 | +| **数据写入** | `approval_records` | +| **依赖** | `GET /api/identity/person` — 获取审批人身份 | +| **待确认** | 审批链是否可以动态配置（不同站点/国家不同审批人）？驳回后修改再提交是否需要重新走完整审批链？ | + +### 2.4 M4: 自动触发规则引擎 + +| 维度 | 说明 | +| --- | --- | +| **对内** | 定时扫描 ASIN 健康状态（评分、评价数、差评比例）；当满足触发条件时自动创建需求（无需人工干预）；触发规则可配置 | +| **对外接口** | 内部定时任务，不对外暴露 | +| **数据写入** | `demands`（自动生成的需求） | +| **依赖** | `GET /api/reviews/asin-health` 或本地 ASIN 数据 | +| **待确认** | 自动触发后是否需要人工确认还是直接进入评估？自动触发的优先级如何设定？ | + +### 2.5 M5: ASIN 管理 + +| 维度 | 说明 | +| --- | --- | +| **对内** | ASIN 基础信息（ASIN 码、标题、品类、站点）；评分、评价总数、差评数；Listing 健康状态（活跃/风险/下架）；与计划的关联关系 | +| **对外接口** | `GET /api/asins/{asin}` — ASIN 详情；`GET /api/asins?status=at_risk` — 需关注的 ASIN 列表 | +| **数据写入** | `asin_catalog` | +| **依赖** | Amazon 数据同步（外部系统） | +| **待确认** | ASIN 数据是否已在 JOYHUB 或其他系统中维护？是否需要新建还是复用？ | + +### 2.6 M6: 对外 API Gateway + +| 维度 | 说明 | +| --- | --- | +| **对内** | 统一对外 API 认证、限流、日志 | +| **对外接口** | `GET /api/plans?status=approved` — 待执行计划（outreach 消费）；`GET /api/plans/{id}` — 计划详情（review 消费）；`GET /api/asins/{asin}` — ASIN 查询 | + +--- + +## 3. 对外 API 契约（草案） + +| 接口 | 方法 | 输入 | 输出 | 消费者 | +| --- | --- | --- | --- | --- | +| 创建需求 | `POST /api/demands` | `{asin, type, target_count, period, priority}` | `{demand_id, status}` | 运营前端 | +| 评估需求 | `PUT /api/demands/{id}/evaluate` | `{decision, reason}` | `{status}` | 用户运营前端 | +| 创建计划 | `POST /api/plans` | `{demand_id, type, params}` | `{plan_id}` | 用户运营前端 | +| 待执行计划列表 | `GET /api/plans?status=approved` | 无 | `[{plan_id, type, items}]` | outreach | +| 计划详情 | `GET /api/plans/{id}` | `plan_id` | 完整计划含审批记录 | review / outreach | +| ASIN 查询 | `GET /api/asins/{asin}` | `asin` | ASIN 详情+健康状态 | 所有子系统 | + +--- + +## 4. 数据对象 + +| 对象 | 核心字段 | 说明 | +| --- | --- | --- | +| `demands` | demand_id, asin, type (NEW/REVIEW/EXEMPTION), target_count, period, status (PENDING/EVALUATING/CONFIRMED/REJECTED/WAITING), priority, created_by, evaluated_by, created_at | 需求主表 | +| `plans` | plan_id, demand_id, type, status (DRAFT/REVIEW/APPROVED/EXECUTING/COMPLETED/CANCELLED), target_count, period, created_at | 计划主表 | +| `plan_items` | item_id, plan_id, asin, item_type, target_count, assigned_channel, status | 计划执行项 | +| `approval_records` | approval_id, plan_id, approver, decision, comment, decided_at, step_order | 审批记录 | +| `asin_catalog` | asin, title, category, marketplace, rating, review_count, negative_count, health_status, last_synced_at | ASIN 信息 | + +--- + +## 5. 业务澄清问题清单 — planning + +### 5.1 需求与计划模型（5 项） + +| # | 问题 | 优先级 | +| --- | --- | --- | +| P-01 | 一个需求是否可以生成多个计划？（例如一个回评需求拆分到 IM 计划和 EDM 计划）还是一对一？ | **P0** | +| P-02 | 计划是否可以跨 ASIN？（一个推新计划覆盖 3 个新 ASIN）还是每个计划只针对一个 ASIN？ | **P0** | +| P-03 | 计划中的「目标数量」是指目标评价数还是目标触达用户数？（如果转化率 2%，要得到 10 个评价需触达 500 人） | **P0** | +| P-04 | 计划的「周期」是什么粒度？（周/月/自定义日期范围？）周期结束后未完成的计划如何处理？ | P1 | +| P-05 | 需求是否有优先级？（P0/P1/P2 或高/中/低？）优先级影响什么？（审批速度？资源分配？） | P1 | + +### 5.2 审批流程（4 项） + +| # | 问题 | 优先级 | +| --- | --- | --- | +| P-06 | 文档提到「免评计划 → Amazon 运营总监 + 用户负责人」审批——是两者都必须通过（会签）还是任一通过即可（或签）？ | **P0** | +| P-07 | 「指定负责人」的指定规则是什么？（按 ASIN 品类？按站点？按当前负载？人工指定？） | P1 | +| P-08 | 审批超时如何处理？（审批人 N 天未处理，自动通过？自动驳回？升级到上级？） | P1 | +| P-09 | 审批驳回后修改再提交，审批链是否重置还是从当前节点继续？ | P1 | + +### 5.3 自动触发（3 项） + +| # | 问题 | 优先级 | +| --- | --- | --- | +| P-10 | 自动触发的具体阈值是什么？（① ASIN 评分低于多少？② 差评在最近 N 天新增多少？③ 评价总数 < 目标值？） | **P0** | +| P-11 | 自动触发是每天跑一次还是实时监控？（如果是实时，高频变化的 ASIN 会不会重复触发？） | P1 | +| P-12 | 自动触发生成的需求是否自动进入评估环节还是需要人工确认后才进入？ | P2 | + +### 5.4 ASIN 管理（3 项） + +| # | 问题 | 优先级 | +| --- | --- | --- | +| P-13 | ASIN 数据来源和更新频率？（从 Amazon API 拉取？T+1？实时？手动导入？） | **P0** | +| P-14 | ASIN 的「Listing 健康状态」如何定义？（评分 ≥ 4.2 = 健康？差评率 < X%？）健康度是否有多个等级？ | P1 | +| P-15 | ASIN 是否有关联关系？（变体 ASIN、父 ASIN-子 ASIN）关联合并还是独立管理？ | P2 | + +### 5.5 计划执行衔接（2 项） + +| # | 问题 | 优先级 | +| --- | --- | --- | +| P-16 | 计划审批通过后如何流转到 outreach 子系统？（planning 主动推送？outreach 定时拉取？事件通知？） | P1 | +| P-17 | 计划执行过程中是否可以调整目标数量或周期？调整是否需要重新审批？ | P2 | + +### 5.6 计划模板与复用（3 项） + +| # | 问题 | 优先级 | +| --- | --- | --- | +| P-18 | 是否需要计划模板功能？（对常推的 ASIN 创建可复用的计划模板——模板包含预设的渠道/目标数/周期？） | P1 | +| P-19 | 周期性计划（如「每月 1 号自动对 ASIN X 发起回评计划」）是否支持？谁有权限创建？ | P2 | +| P-20 | 计划是否可以暂停/恢复？（执行中因库存或供应链原因需暂停——暂停期间已触达的用户如何处理？） | P1 | + +### 5.7 预算与资源管理（3 项） + +| # | 问题 | 优先级 | +| --- | --- | --- | +| P-21 | 计划是否有预算字段？（返款金额、Code 成本、KOC 费用——是否需要预算审批？超出预算如何处理？） | P1 | +| P-22 | 资源容量规划——同时可执行的计划数是否有上限？（受限于客服人力/EDM发送额度/IM频控？） | P1 | +| P-23 | 是否需要计划执行成本的 ROI 计算？（返款总额 / 获得的评价数 = 单评价成本——系统自动计算还是手动录入？） | P2 | + +### 5.8 季节性/大促处理（3 项） + +| # | 问题 | 优先级 | +| --- | --- | --- | +| P-24 | Prime Day / Black Friday 等大促期间的计划是否有特殊处理？（提前锁定额度、加大推送量、豁免某些频控规则？） | P1 | +| P-25 | 大促前的「预热计划」和大促后的「回评计划」是否需要在系统中作为计划间的依赖关系来管理？ | P2 | +| P-26 | 季节性产品（圣诞装饰、夏季用品）的计划是否有时间敏感度标记？（错过季节窗口的计划自动降级？） | P2 | + +### 5.9 多站点/多市场（3 项） + +| # | 问题 | 优先级 | +| --- | --- | --- | +| P-27 | 不同 Amazon 站点的计划是否可以统一管理？（同一个 ASIN 在不同站点是独立计划还是关联计划？） | P1 | +| P-28 | 多站点的审批人是否不同？（.com 的运营总监和 .co.uk 的运营总监可能是不同人） | P1 | +| P-29 | 跨站点需求的冲突检测？（.com 和 .de 同时对同一真实的同一用户做了不同计划——算不算冲突？） | P2 | + +### 5.10 实施层面（3 项） + +| # | 问题 | 优先级 | +| --- | --- | --- | +| P-30 | 自动触发生成的需求如果无人处理（评估超时），是否自动驳回还是升级通知？ | P1 | +| P-31 | 审批工作流引擎——是否有现成的审批引擎可复用？（还是需要从零开发状态机？） | P2 | +| P-32 | 计划执行过程中用户反馈「不想再收到」——是标记为退订（outreach 处理）还是需要回写到 planning 的计划状态中？ | P1 | diff --git a/wishfulfilled-wiki/05_需求文档/03-子系统-额度与频控.md b/wishfulfilled-wiki/05_需求文档/03-子系统-额度与频控.md new file mode 100644 index 0000000..861e6b3 --- /dev/null +++ b/wishfulfilled-wiki/05_需求文档/03-子系统-额度与频控.md @@ -0,0 +1,198 @@ + 1|# 子系统 03 — 额度与频控 (`quota`) v1.0 + 2| + 3|## 子系统概述 + 4| + 5|| 维度 | 说明 | + 6|| --- | --- | + 7|| 代号 | `quota` | + 8|| 核心职责 | 额度台账（测评4/免评4/累计12）、额度预占与释放、频控规则引擎、发送前终校 | + 9|| 数据所有权 | `person_quota_ledgers`, `quota_reservations`, `frequency_control_records` | + 10|| 启动依赖 | identity（软依赖，额度按真实人计算，未归并时按单一账号） | + 11|| 外部系统依赖 | 无直接外部依赖 | + 12| + 13|--- + 14| + 15|## 1. 模块划分 + 16| + 17|``` + 18|┌─────────────────────────────────────────────────────────────┐ + 19|│ quota 子系统 │ + 20|│ │ + 21|│ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │ + 22|│ │ M1: 额度台账 │ │ M2: 预占管理 │ │ M3: 频控引擎 │ │ + 23|│ │ (Ledger) │→│ (Reservation)│ │ (FreqCtrl) │ │ + 24|│ └──────┬───────┘ └──────┬───────┘ └──────┬───────┘ │ + 25|│ │ │ │ │ + 26|│ ▼ ▼ ▼ │ + 27|│ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │ + 28|│ │ M4: 终校服务 │ │ M5: 额度管理 │ │ M6: 对外 API │ │ + 29|│ │ (FinalCheck)│ │ Admin │ │ Gateway │ │ + 30|│ └──────────────┘ └──────────────┘ └──────────────┘ │ + 31|│ │ + 32|└─────────────────────────────────────────────────────────────┘ + 33|``` + 34| + 35|| # | 模块 | 代号 | 职责 | + 36|| --- | --- | --- | --- | + 37|| M1 | 额度台账 | `quota-ledger` | 维护真实人三层额度（测评4/免评4/累计12）、已用/进行中/已预占计数 | + 38|| M2 | 预占管理 | `reservation-mgr` | 额度预占创建、确认占用、超时释放；跨计划重复入选检测 | + 39|| M3 | 频控引擎 | `freq-control` | 渠道频控（IM/EDM/APP/TEL 最近触达间隔）、单 ASIN 短期触达次数、退订/投诉屏蔽 | + 40|| M4 | 终校服务 | `final-check` | 发送前合并校验（最新额度 + 最新风险 + 最新未关闭工单），准入/撤出决策 | + 41|| M5 | 额度管理 Admin | `quota-admin` | 额度手动调整、额度重置、额度审计 | + 42|| M6 | 对外 API Gateway | `quota-api` | 供 planning（人群生成）、outreach（发送前校验）、review（提交后确认）调用 | + 43| + 44|--- + 45| + 46|## 2. 各模块内外说明 + 47| + 48|### 2.1 M1: 额度台账 + 49| + 50|| 维度 | 说明 | + 51|| --- | --- | + 52|| **对内** | 按真实人维护三种额度：月度测评（已完成+进行中+已预占）、月度免评（同上）、累计真实提交评价（永久累计）；额度计数时点明确（提交评价立即计数12、不会因 Amazon 未展示回退）；接近上限时预警 | + 53|| **对外接口** | `GET /api/quota/ledger/{person_id}` — 读取当前台账 | + 54|| **数据写入** | `person_quota_ledgers` | + 55|| **依赖** | `GET /api/identity/person` — 获取真实人 ID | + 56| + 57|### 2.2 M2: 预占管理 + 58| + 59|| 维度 | 说明 | + 60|| --- | --- | + 61|| **对内** | 人群生成时预占额度（测评/免评）；计算：已用+进行中+已预占+本次拟发送 > 上限 → 拦截；剩余不足但>0 → 预警池 → 发送前人工复核；预占有效期管理，超时自动释放；并发占用控制（同一真实人跨计划重复入选检测） | + 62|| **对外接口** | `POST /api/quota/reserve` — 创建预占；`POST /api/quota/commit` — 确认占用；`POST /api/quota/release` — 释放预占 | + 63|| **数据写入** | `quota_reservations` | + 64| + 65|### 2.3 M3: 频控引擎 + 66| + 67|| 维度 | 说明 | + 68|| --- | --- | + 69|| **对内** | 四种频控维度：①渠道频控（IM/EDM/APP/TEL 最近触达间隔）②单 ASIN 短期内触达同一用户次数 ③用户反感度（投诉/退订状态）④用户在客服工单中暂不触达；频控规则可配置 | + 70|| **对外接口** | `GET /api/quota/freq-check/{person_id}?channel=IM&asin=xxx` — 频控检查 | + 71|| **数据写入** | `frequency_control_records` | + 72|| **依赖** | 触达历史来自 outreach（`GET /api/outreach/history/{person_id}`） | + 73| + 74|### 2.4 M4: 终校服务 + 75| + 76|| 维度 | 说明 | + 77|| --- | --- | + 78|| **对内** | 发送前做最终校验：①重新读取最新额度（防止发送和预占之间额度变化）②重新读取最新风险状态 ③重新读取最新未关闭工单；三者全部通过→准入发送；任一新增超限/风险/工单→撤出本批次 | + 79|| **对外接口** | `POST /api/quota/final-check` — 批量终校（输入 person_ids + plan_id，返回每个的准入/撤出决策） | + 80|| **数据写入** | 终校结果写入审计日志 | + 81|| **依赖** | `GET /api/risk/check/{person_id}`；`GET /api/tickets?person_id=&status=open` | + 82| + 83|### 2.5 M5: 额度管理 Admin + 84| + 85|| 维度 | 说明 | + 86|| --- | --- | + 87|| **对内** | 额度手动调整（运营确认某次测评不计入额度等）；额度重置（新月份额度初始化）；额度审计（谁改了什么额度） | + 88|| **对外接口** | 管理 API | + 89| + 90|### 2.6 M6: 对外 API Gateway + 91| + 92|| 维度 | 说明 | + 93|| --- | --- | + 94|| **对外接口** | `GET /api/quota/check/{person_id}?type=测评` — 额度查询+可用判断；`POST /api/quota/reserve` — 预占；`POST /api/quota/commit` — 确认；`POST /api/quota/release` — 释放；`POST /api/quota/final-check` — 终校 | + 95| + 96|--- + 97| + 98|## 3. 对外 API 契约（草案） + 99| + 100|| 接口 | 方法 | 输入 | 输出 | 消费者 | + 101|| --- | --- | --- | --- | --- | + 102|| 额度查询 | `GET /api/quota/check/{person_id}?type=REVIEW` | person_id + 额度类型 | `{used, in_progress, reserved, remaining, status(sufficient/warning/exceeded)}` | planning, outreach | + 103|| 批量预占 | `POST /api/quota/reserve` | `[{person_id, type, plan_id, count}]` | `[{person_id, success, reservation_id}]` | planning（人群生成时） | + 104|| 确认占用 | `POST /api/quota/commit` | `[{reservation_id}]` | `[{reservation_id, committed}]` | review（用户提交评价后） | + 105|| 释放预占 | `POST /api/quota/release` | `[{reservation_id}]` | `[{success}]` | planning（计划取消时） | + 106|| 频控检查 | `GET /api/quota/freq-check/{person_id}?channel=&asin=` | person_id + 渠道 + ASIN | `{allowed, reason, cooldown_until}` | outreach（发送前） | + 107|| 发送前终校 | `POST /api/quota/final-check` | `[{person_id, plan_id}]` | `[{person_id, decision: APPROVED/WITHDRAWN, reasons}]` | outreach（发送前最后一步） | + 108| + 109|--- + 110| + 111|## 4. 数据对象 + 112| + 113|| 对象 | 核心字段 | 说明 | + 114|| --- | --- | --- | + 115|| `person_quota_ledgers` | ledger_id, person_id, quota_type (MONTHLY_REVIEW/MONTHLY_EXEMPTION/LIFETIME_SUBMISSION), period, used, in_progress, reserved, limit_value, status | 三层额度台账 | + 116|| `quota_reservations` | reservation_id, person_id, ledger_id, plan_id, count, status (RESERVED/COMMITTED/RELEASED/EXPIRED), reserved_at, expires_at | 额度预占记录 | + 117|| `frequency_control_records` | freq_id, person_id, channel, asin, last_contact_at, contact_count_period, status | 频控记录 | + 118| + 119|--- + 120| + 121|## 5. 业务澄清问题清单 — quota + 122| + 123|### 5.1 额度规则细化（5 项） + 124| + 125|| # | 问题 | 优先级 | + 126|| --- | --- | --- | + 127|| Q-01 | 月度额度按自然月还是 30 天滚动？如果是自然月：①预占在 1 月 31 日，2 月 1 日释放还是保留？②1 月 31 日晚 23:59 的预占跨月怎么处理？ | **P0** | + 128|| Q-02 | 「测评 4 次」中的「次」定义：是指参与 4 个不同的测评计划，还是提交 4 条评价？（如果 1 个计划要求用户提交 3 条评价，占 3 次还是 1 次？） | **P0** | + 129|| Q-03 | 「累计 12 个真实提交评价」是永久上限还是可以动态调整？（例如用户长期优质且评价质量高，是否可以人工放宽？放宽流程？） | P1 | + 130|| Q-04 | 测评和免评额度是否独立？（测评 4 次 + 免评 4 次 = 同一真实人一月最多参与 8 个计划？）还是测评和免评共享总额度？ | P1 | + 131|| Q-05 | 额度计算中「进行中」的定义——什么状态才算进行中？（已生成人群？已发送触达？用户已回应？已提交评价待核验？） | P1 | + 132| + 133|### 5.2 预占机制（4 项） + 134| + 135|| # | 问题 | 优先级 | + 136|| --- | --- | --- | + 137|| Q-06 | 预占有效期多长？（预占后用户始终未响应，多久释放？1 天？7 天？计划周期结束？） | **P0** | + 138|| Q-07 | 预占释放后是否可以自动重新分配给同一计划的其他用户？是否触发重新生成人群？ | P1 | + 139|| Q-08 | 跨计划并发占用检测——同一真实人在计划 A 和计划 B 同时被入选，谁先预占谁得？还是按计划优先级？ | P1 | + 140|| Q-09 | 预占是否可手动取消/释放？（运营发现某用户不应计入某计划时） | P2 | + 141| + 142|### 5.3 频控规则（4 项） + 143| + 144|| # | 问题 | 优先级 | + 145|| --- | --- | --- | + 146|| Q-10 | 各渠道频控的具体阈值是什么？（IM 每日最多 X 次？EDM 每周最多 Y 封？APP Push 每日最多 Z 条？TEL 每日最多 N 通？） | **P0** | + 147|| Q-11 | 频控规则是否区分计划类型？（紧急催评是否可以突破频控？） | P1 | + 148|| Q-12 | 频控是全局统一配置还是按用户层级可调整？（A 类和 C 类用户频控规则是否不同？） | P1 | + 149|| Q-13 | 「单 ASIN 短期触达次数」——多少天内触达多少次算超标？ | P2 | + 150| + 151|### 5.4 预警与异常（3 项） + 152| + 153|| # | 问题 | 优先级 | + 154|| --- | --- | --- | + 155|| Q-14 | 预警阈值如何设定？（剩余 1 次时预警？剩余 N% 时预警？不同类型额度预警阈值是否不同？） | P1 | + 156|| Q-15 | 终校中「新增风险」的判断——距离上次风险检查超过多少时间需重查？还是每次终校都实时查 risk？ | P1 | + 157|| Q-16 | 额度数据异常时的处理策略？（台账数据与预占记录不一致、预占未释放导致额度泄漏——系统如何自动发现和修复？） | P2 | + 158| +### 5.5 额度异常与纠错（4 项） + +| # | 问题 | 优先级 | +| --- | --- | --- | +| Q-17 | 用户反馈「我明明只参与了 3 次测评，系统说我已用 4 次」——申诉流程？谁有权限查台账和修正？ | P1 | +| Q-18 | 额度台账的审计追踪——每次额度变更（预占/确认/释放/手动调整）是否记录完整操作人和原因？保留多久？ | P1 | +| Q-19 | 数据异常自动检测——台账数据与预占记录之和是否需要对账？系统是否定期自动化对账并报告差异？ | P1 | +| Q-20 | 如果发现「额度泄漏」（预占未释放导致额度永久被占），系统如何自动发现和修复？（定时扫描过期预占？手动触发对账？） | P2 | + +### 5.6 紧急/例外处理（4 项） + +| # | 问题 | 优先级 | +| --- | --- | --- | +| Q-21 | 大促期间（Prime Day/Black Friday）是否需要临时额度提升？（测评 4→8？）由谁审批？临时额度有效期？ | P1 | +| Q-22 | 高价值用户是否可以突破额度限制？（例如 KOC 级别的用户需要超额参与——人工审批流程？） | P1 | +| Q-23 | 「紧急计划」是否可以跳过频控？（例如 Listing 评分暴跌至 3.8 需要紧急大量催评——是否豁免部分频控规则？） | P1 | +| Q-24 | 额度手动调整是否需要审批？审批权限？（谁可以手动给某人加/减可用额度？） | P2 | + +### 5.7 跨站点/跨平台额度（3 项） + +| # | 问题 | 优先级 | +| --- | --- | --- | +| Q-25 | 额度是否跨 Amazon 站点？（.com 参与了 2 次测评 + .co.uk 参与了 3 次 → 全局算 5 次还是各自独立？） | P1 | +| Q-26 | 累计 12 个评价是否跨站点统计？（在 .com 提交了 8 个 + .co.uk 提交了 5 个 → 是否算 13 个超限？） | P1 | +| Q-27 | 未来扩展到非 Amazon 平台，额度体系是否独立？（eBay 的测评额度与 Amazon 的额度是否共享？） | P2 | + +### 5.8 额度可见性（2 项） + +| # | 问题 | 优先级 | +| --- | --- | --- | +| Q-28 | 用户是否能看到自己的额度状态？（APP 端显示「本月还可参与 2 次测评」——是否对用户可见？） | P2 | +| Q-29 | 运营视角的额度看板——能否看到「全局额度使用率」「各真实人的额度分布」「额度预警用户列表」？ | P1 | + +### 5.9 实施层面（3 项） + +| # | 问题 | 优先级 | +| --- | --- | --- | +| Q-30 | 终校服务的性能要求——批量终校（一次可能几百人）需要在多少 ms 内完成？（涉及跨子系统调用 risk + support） | P2 | +| Q-31 | 频控规则是否需要热更新（不重启服务即可调整阈值）？配置管理方案？ | P1 | +| Q-32 | 额度台账历史数据的初始化——旧系统的数据如何映射到三层额度模型？（无「真实人」概念的老数据如何归入？） | P1 | diff --git a/wishfulfilled-wiki/05_需求文档/04-子系统-多渠道触达引擎.md b/wishfulfilled-wiki/05_需求文档/04-子系统-多渠道触达引擎.md new file mode 100644 index 0000000..8fe7911 --- /dev/null +++ b/wishfulfilled-wiki/05_需求文档/04-子系统-多渠道触达引擎.md @@ -0,0 +1,240 @@ + 1|# 子系统 04 — 多渠道触达引擎 (`outreach`) v1.0 + 2| + 3|## 子系统概述 + 4| + 5|| 维度 | 说明 | + 6|| --- | --- | + 7|| 代号 | `outreach` | + 8|| 核心职责 | 渠道路由决策、渠道去重、IM/EDM/APP Push/TEL 渠道调度执行、触达历史管理 | + 9|| 数据所有权 | `channel_route_decisions`, `channel_dedup_records`, `im_interaction_records`, `im_flow_tags`, `edm_message_events`, `edm_user_behavior_profiles`, `app_touch_events`, `tel_call_records` | + 10|| 启动依赖 | identity / planning / quota（均为软依赖） | + 11|| 外部系统依赖 | JOYHUB（IM 通道）、ESP（EDM）、FCM/APNs（APP Push）、电话系统（TEL） | + 12| + 13|--- + 14| + 15|## 1. 模块划分 + 16| + 17|``` + 18|┌─────────────────────────────────────────────────────────────┐ + 19|│ outreach 子系统 │ + 20|│ │ + 21|│ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │ + 22|│ │ M1: 渠道路由 │ │ M2: 渠道去重 │ │ M3: IM 执行 │ │ + 23|│ │ + 优先级 │→│ │→│ 引擎 │ │ + 24|│ └──────────────┘ └──────────────┘ └──────┬───────┘ │ + 25|│ │ │ + 26|│ ┌──────────────┐ ┌──────────────┐ ┌──────┴───────┐ │ + 27|│ │ M4: EDM 执行 │ │ M5: APP Push │ │ M6: TEL 执行 │ │ + 28|│ │ 引擎 │ │ 引擎 │ │ 引擎 │ │ + 29|│ └──────────────┘ └──────────────┘ └──────────────┘ │ + 30|│ │ + 31|│ ┌──────────────┐ ┌──────────────┐ │ + 32|│ │ M7: 触达历史 │ │ M8: 对外 API │ │ + 33|│ │ 服务 │ │ Gateway │ │ + 34|│ └──────────────┘ └──────────────┘ │ + 35|│ │ + 36|└─────────────────────────────────────────────────────────────┘ + 37|``` + 38| + 39|| # | 模块 | 职责 | + 40|| --- | --- | --- | + 41|| M1 | 渠道路由+优先级 | 按用户状态路由到最优渠道（APP活跃→IM优先 / 未注册→EDM优先 / 高价值无响应→TEL / C类→IM免评卡片） | + 42|| M2 | 渠道去重 | 同一计划同一用户不重复走多渠道路由；工单中暂停自动触达；已提交待核验暂停催评 | + 43|| M3 | IM 执行引擎 | IM 推送、用户分层（A未参与/B参与过/C长期测评人）、回评/测评/免评卡片推送、催评、提交核验、返款通知 | + 44|| M4 | EDM 执行引擎 | EDM 发送、送达/打开/点击追踪、行为画像、节奏控制、退订/硬退信处理 | + 45|| M5 | APP Push 引擎 | APP 推送、触发源管理（绑定玩具/不活跃/计划到期/Listing紧急/活动）、响应追踪 | + 46|| M6 | TEL 执行引擎 | 电话任务生成、拨打前准备（用户画像+风险检查+历史沟通）、通话记录、重试策略 | + 47|| M7 | 触达历史服务 | 统一触达历史查询（跨渠道聚合）、供 quota（频控）、identity（上下文卡）调用 | + 48|| M8 | 对外 API Gateway | 统一对外 API | + 49| + 50|--- + 51| + 52|## 2. 各模块内外说明 + 53| + 54|### 2.1 M1: 渠道路由+优先级 + 55| + 56|| 维度 | 说明 | + 57|| --- | --- | + 58|| **对内** | 接收 planning 的已批准计划，按用户状态矩阵决定渠道：APP活跃+已绑定→IM首选；APP低活跃→EDM补充+APP Push召回；未注册→EDM首选→引导注册后转IM；高价值+多次无响应→TEL；C类（累计≥12）→IM免评卡片+KOC/KOL协同 | + 59|| **对外接口** | `POST /api/outreach/route` — 输入计划+用户，返回路由决策 | + 60|| **数据写入** | `channel_route_decisions` | + 61|| **依赖** | `GET /api/identity/context/{person_id}` — 用户状态 | + 62| + 63|### 2.2 M2: 渠道去重 + 64| + 65|| 维度 | 说明 | + 66|| --- | --- | + 67|| **对内** | 执行去重规则（同一计划同一用户首选渠道、工单中暂停、已提交评价暂停、退订某渠道永久排除、强关联风险全暂停、弱关联降频+提示） | + 68|| **对外接口** | `GET /api/outreach/dedup-check?person_id=&plan_id=` | + 69|| **数据写入** | `channel_dedup_records` | + 70|| **依赖** | `GET /api/tickets?person_id=&status=open`（support）；`GET /api/risk/check/{person_id}`（risk） | + 71| + 72|### 2.3 M3: IM 执行引擎 + 73| + 74|| 维度 | 说明 | + 75|| --- | --- | + 76|| **对内** | 用户分层逻辑（A未参与/B参与过但<12/C≥12长期测评人）；分层推送策略（A推回评卡片/B先催评再二次转化/C仅免评）；提交后的核验与流转（订单号核实→登记→补全信息→返款→二次转化）；标签管理（9 种核心标签如「xx产品已回评用户」「xx产品测评待返款用户」等） | + 77|| **对外接口** | `POST /api/outreach/im/send` — 发送 IM 消息 | + 78|| **数据写入** | `im_interaction_records`, `im_flow_tags` | + 79|| **依赖** | JOYHUB（IM 通道）；`GET /api/quota/check/{person_id}` | + 80|| **待确认** | IM 是 WhatsApp 还是自研 IM？通道对接方式？ | + 81| + 82|### 2.4 M4: EDM 执行引擎 + 83| + 84|| 维度 | 说明 | + 85|| --- | --- | + 86|| **对内** | 推送前检查（身份→风险→退订→资格→国家）；行为筛选（打开/点击/回复/频率）；节奏判断（适合触达/需降频/不适合）；发送后追踪（送达→打开→点击→回复→退订）；转化路径（下载注册APP→转IM / 直接回复邮件→生成客服工单 / 未响应→再触达队列） | + 87|| **对外接口** | `POST /api/outreach/edm/send` — 发送 EDM | + 88|| **数据写入** | `edm_message_events`, `edm_user_behavior_profiles` | + 89|| **依赖** | ESP 邮件服务 | + 90|| **待确认** | EDM 模板在哪里管理？模板变量（用户名/产品名/链接）如何填充？ | + 91| + 92|### 2.5 M5: APP Push 引擎 + 93| + 94|| 维度 | 说明 | + 95|| --- | --- | + 96|| **对内** | 5 种触发源（绑定新玩具/不活跃/计划到期/Listing紧急/活动）；推送前过滤（身份+风险+频控+标签）；响应追踪（点击打开→落地页 / 忽略→短期不重复推 / 卸载→转EDM候选池）；APP 内动作分流（提交回评/测评→IM核验 / 联系客服→工单 / 浏览→更新活跃标签） | + 97|| **对外接口** | `POST /api/outreach/app/push` — 发送 APP Push | + 98|| **数据写入** | `app_touch_events` | + 99|| **依赖** | FCM/APNs | + 100|| **待确认** | 是否复用 JOYHUB 现有 Push 通道？ | + 101| + 102|### 2.6 M6: TEL 执行引擎 + 103| + 104|| 维度 | 说明 | + 105|| --- | --- | + 106|| **对内** | 7 种触发场景（答应配合超时/高价值跟进/复杂售后/多次无响应/紧急Listing/Amazon来电/外呼任务）；拨打前准备 5 步（查用户完整画像→查风险→查历史沟通→准备话术→生成电话工单）；通话结果 5 种（售后问题解决→引导回评 / 直接配合→登记答应配合 / 拒绝→记录 / 疑似诈骗→转风险 / 未接通→重试）；重试策略（<3次重拨 / ≥3次降级EDM或关闭） | + 107|| **对外接口** | `POST /api/outreach/tel/task` — 创建 TEL 任务 | + 108|| **数据写入** | `tel_call_records` | + 109|| **依赖** | 电话系统（外呼/来电） | + 110| + 111|### 2.7 M7: 触达历史服务 + 112| + 113|| 维度 | 说明 | + 114|| --- | --- | + 115|| **对内** | 跨渠道聚合触达历史（IM/EDM/APP/TEL）；提供统一查询接口供 quota（频控）和 identity（上下文卡）消费 | + 116|| **对外接口** | `GET /api/outreach/history/{person_id}` | + 117|| **数据写入** | 只读聚合 | + 118| + 119|--- + 120| + 121|## 3. 对外 API 契约（草案） + 122| + 123|| 接口 | 方法 | 输入 | 输出 | 消费者 | + 124|| --- | --- | --- | --- | --- | + 125|| 触达历史 | `GET /api/outreach/history/{person_id}` | person_id | `{im[], edm[], app[], tel[]}` | quota（频控）, identity（上下文卡） | + 126|| 执行触达 | `POST /api/outreach/send` | `{plan_id, person_ids[], channel, content}` | `{task_id, status}` | planning | + 127|| 渠道路由决策 | `POST /api/outreach/route` | `{person_id, plan_id}` | `{recommended_channel, alternatives[]}` | planning | + 128|| IM 消息发送 | `POST /api/outreach/im/send` | `{person_id, msg_type, content}` | `{message_id}` | 内部 | + 129| + 130|--- + 131| + 132|## 4. 数据对象 + 133| + 134|| 对象 | 核心字段 | 说明 | + 135|| --- | --- | --- | + 136|| `channel_route_decisions` | decision_id, person_id, plan_id, selected_channel, reason, decided_at | 渠道路由决策 | + 137|| `channel_dedup_records` | dedup_id, person_id, plan_id, channel, status(BLOCKED/ALLOWED), block_reason | 渠道去重记录 | + 138|| `im_interaction_records` | interaction_id, person_id, msg_type(PUSH_CARD/REVIEW_CARD/EXEMPTION_CARD/REMINDER/REFUND_NOTICE), direction(OUTBOUND/INBOUND), content, status, created_at | IM 交互记录 | + 139|| `im_flow_tags` | tag_id, person_id, tag_type, tag_value, tagged_at | IM 流程标签（如 xx产品待返款等） | + 140|| `edm_message_events` | event_id, person_id, email, event_type(SENT/DELIVERED/OPENED/CLICKED/REPLIED/UNSUBSCRIBED/HARD_BOUNCED), occurred_at | EDM 事件 | + 141|| `edm_user_behavior_profiles` | profile_id, person_id, email, last_opened_at, total_opens, consecutive_no_open, last_replied_at, monthly_received, status | EDM 用户行为画像 | + 142|| `app_touch_events` | event_id, person_id, trigger_type, push_status, response, occurred_at | APP Push 事件 | + 143|| `tel_call_records` | call_id, person_id, ticket_id, direction(OUTBOUND/INBOUND), call_status, duration, outcome, retry_count, recorded_at | TEL 通话记录 | + 144| + 145|--- + 146| + 147|## 5. 业务澄清问题清单 — outreach + 148| + 149|### 5.1 渠道优先级路由（4 项） + 150| + 151|| # | 问题 | 优先级 | + 152|| --- | --- | --- | + 153|| O-01 | 路由规则是否可配置？（例如针对某个站点用户调整 IM > EDM 的优先级）配置界面在 outreach 内还是在独立配置管理？ | **P0** | + 154|| O-02 | 「APP 低活跃」的判定标准是什么？（N 天未打开？N 天未点击推送？）阈值是否可配置？ | P1 | + 155|| O-03 | 高优先级渠道发送失败（退信/未送达）后，是否自动降级到下一渠道？降级是否有冷却时间？ | P1 | + 156|| O-04 | C 类用户（累计≥12）只推免评——如果免评计划也没有，是完全不推还是推品牌/活动内容？ | P2 | + 157| + 158|### 5.2 IM 通道（4 项） + 159| + 160|| # | 问题 | 优先级 | + 161|| --- | --- | --- | + 162|| O-05 | IM 使用的具体平台是什么？（WhatsApp Business API / 自研 JOYHUB IM / Messenger？）不同平台的 API 能力和限制？ | **P0** | + 163|| O-06 | IM 的「分层」是系统自动判断还是人工可干预？（一个 B 类用户会不会被错误标记为 C 类？如何修正？） | **P0** | + 164|| O-07 | IM 推送中「测评卡片」的具体形式是什么？（带按钮的消息模板？需要用户填表单？）模板在哪里管理？ | P1 | + 165|| O-08 | IM 中的「订单号核实」——核实的数据源是什么？（比对内部订单表？Amazon 订单 API？）核实失败的转人工流程？ | P1 | + 166| + 167|### 5.3 EDM 通道（4 项） + 168| + 169|| # | 问题 | 优先级 | + 170|| --- | --- | --- | + 171|| O-09 | 当前使用的邮件服务是什么？（SendGrid/Mailchimp/SES/自建？）有没有现成 API 和 Webhook 追踪？ | **P0** | + 172|| O-10 | EDM 模板（邮件内容、样式、多语言）在哪里管理？属于 outreach 还是独立内容管理子系统？ | P1 | + 173|| O-11 | 「EDM 行为画像」中的「最近 3/5 次 0 打开」——3 次和 5 次是两个独立指标还是二选一？各自对应什么策略？ | P1 | + 174|| O-12 | EDM 发送量和频控——单日最大发送量有限制吗？（ESP 的每日限额？） | P1 | + 175| + 176|### 5.4 APP Push（3 项） + 177| + 178|| # | 问题 | 优先级 | + 179|| --- | --- | --- | + 180|| O-13 | APP Push 是否复用 JOYHUB 的现有推送通道？还是需要独立接入 FCM（Android）和 APNs（iOS）？ | **P0** | + 181|| O-14 | APP Push 和 IM 消息的分工——文档第 11.2 节给了对照表，但边界是否绝对？（例如"计划到期提醒"是否可能同时走 APP Push 和 IM？） | P1 | + 182|| O-15 | APP 落地页——推送点击后跳转到哪个页面？（APP 内的测评页？IM 对话页？）落地页由哪个团队/子系统负责？ | P2 | + 183| + 184|### 5.5 TEL 通道（3 项） + 185| + 186|| # | 问题 | 优先级 | + 187|| --- | --- | --- | + 188|| O-16 | 电话系统使用什么方案？（自建 SIP PBX / Twilio / 其他云呼叫中心？）是否已有通话记录？ | **P0** | + 189|| O-17 | 「拨打前准备」第 2 步「查风险：强关联命中→暂停拨打→先复核」——复核由谁来做？（风险人员？客服组长？）复核时长预期？ | P1 | + 190|| O-18 | 电话中「尽量确认」的字段（购买平台、订单号、产品型号、购买时间、问题类型、凭证）如果用户不愿意/无法提供——哪些是必须确认的？哪些可以跳过？ | P1 | + 191| +### 5.6 消息内容与合规（4 项） + +| # | 问题 | 优先级 | +| --- | --- | --- | +| O-19 | 消息内容是否需要审核？（IM 推送文案、EDM 邮件内容、APP Push——上线前是否需要审核？审核流程？） | P1 | +| O-20 | EDM 合规要求——是否遵守 CAN-SPAM Act（美国）、GDPR（欧洲）、CASL（加拿大）？退订机制是否满足法律要求？ | P1 | +| O-21 | IM 平台的合规限制——WhatsApp 等平台禁止垃圾消息和特定类型内容（如测评引导）——是否有合规风险？ | P1 | +| O-22 | 消息发送的时区感知——美国用户、英国用户、德国用户的推送时间是否需要本地化？（用户当地时间的白天而非半夜） | P1 | + +### 5.7 消息策略与实验（3 项） + +| # | 问题 | 优先级 | +| --- | --- | --- | +| O-23 | 是否需要 A/B 测试能力？（同一计划的两组用户收到不同文案/不同发送时间——对比转化率？） | P2 | +| O-24 | 消息打开率/点击率/转化率的追踪和报表？是否需要自动优化发送策略（高打开率的文案模板优先使用）？ | P2 | +| O-25 | 用户反馈「消息太频繁/内容不相关」——是否有投诉/退订统计和预警？（投诉率超过 X% 暂停该类型推送？） | P1 | + +### 5.8 IM 通道补充（3 项） + +| # | 问题 | 优先级 | +| --- | --- | --- | +| O-26 | IM 消息的「已读」状态是否能获取？（WhatsApp 的蓝色双勾——能否用于判断用户是否看到消息？） | P1 | +| O-27 | IM 用户提交的「评论截图/链接」——如何自动验证截图的真实性？（防止用户 PS 假截图？是否需要 OCR 识别截图内容？） | P1 | +| O-28 | IM 中的返款通知——返款是系统自动触发还是人工触发？返款状态如何回写到 outreach？ | P1 | + +### 5.9 EDM 通道补充（3 项） + +| # | 问题 | 优先级 | +| --- | --- | --- | +| O-29 | EDM 的「硬退信」和「投诉」是否自动同步到 identity 的风险标记？（硬退信用户是否需要进入风险观察？） | P1 | +| O-30 | EDM 引导用户下载 APP——是否在邮件中嵌入归因链接（deferred deep link）以追踪转化来源？ | P2 | +| O-31 | EDM 的发送域名和 IP 预热策略？（新域名/IP 直接大批量发送会被 ESP 判定为垃圾邮件——需要渐进式预热？） | P2 | + +### 5.10 TEL 通道补充（3 项） + +| # | 问题 | 优先级 | +| --- | --- | --- | +| O-32 | 电话录音是否需要存储？存储多久？谁有权调取录音？（涉及合规和隐私） | P1 | +| O-33 | 不同国家的电话合规要求——美国需提前告知录音、德国的 GDPR 限制——如何处理？ | P1 | +| O-34 | TEL 任务的优先级和分配——多个外呼任务同时存在时，客服按什么顺序拨打？（先打高价值用户？先打答应配合超时的？） | P1 | + +### 5.11 实施层面（4 项） + +| # | 问题 | 优先级 | +| --- | --- | --- | +| O-35 | 各外部通道的 rate limit 和计费模式？（WhatsApp 按消息数计费？EDM 按发送量计费？）是否需要成本控制？ | P1 | +| O-36 | 消息发送是同步还是异步？（用户点「发送」后立即返回还是后台队列处理？失败重试策略？） | P1 | +| O-37 | 多渠道消息的发送顺序保证？（「先发 IM 提醒→24h 后无回复再发 EDM」——这种时序依赖如何实现？定时任务？延迟队列？） | P2 | +| O-38 | 异常场景——如果某渠道 100% 发送失败（ESP 宕机/WhatsApp API 限流）——是否自动切换备用渠道？ | P2 | diff --git a/wishfulfilled-wiki/05_需求文档/05-子系统-客服工单与管理.md b/wishfulfilled-wiki/05_需求文档/05-子系统-客服工单与管理.md new file mode 100644 index 0000000..18e9f90 --- /dev/null +++ b/wishfulfilled-wiki/05_需求文档/05-子系统-客服工单与管理.md @@ -0,0 +1,214 @@ + 1|# 子系统 05 — 客服工单与管理 (`support`) v1.0 + 2| + 3|## 子系统概述 + 4| + 5|| 维度 | 说明 | + 6|| --- | --- | + 7|| 代号 | `support` | + 8|| 核心职责 | 工单生命周期管理、自动分配、答应配合状态机、排班出勤管理、绩效统计 | + 9|| 数据所有权 | `support_tickets`, `support_followups`, `support_assignment_logs`, `attendance_records`, `shift_schedules`, `support_performance_snapshots` | + 10|| 启动依赖 | identity（软依赖，无上下文卡时可先跑工单） | + 11|| 外部系统依赖 | 无直接外部依赖（电话记录来自 outreach TEL 模块） | + 12| + 13|--- + 14| + 15|## 1. 模块划分 + 16| + 17|``` + 18|┌─────────────────────────────────────────────────────────────┐ + 19|│ support 子系统 │ + 20|│ │ + 21|│ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │ + 22|│ │ M1: 工单管理 │ │ M2: 自动分配 │ │ M3: 答应配合 │ │ + 23|│ │ (Ticket) │→│ (Assign) │ │ 状态机 │ │ + 24|│ └──────┬───────┘ └──────┬───────┘ └──────┬───────┘ │ + 25|│ │ │ │ │ + 26|│ ▼ ▼ ▼ │ + 27|│ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │ + 28|│ │ M4: 排班出勤 │ │ M5: 绩效统计 │ │ M6: 对外 API │ │ + 29|│ │ 管理 │ │ │ │ Gateway │ │ + 30|│ └──────────────┘ └──────────────┘ └──────────────┘ │ + 31|│ │ + 32|└─────────────────────────────────────────────────────────────┘ + 33|``` + 34| + 35|| # | 模块 | 职责 | + 36|| --- | --- | --- | + 37|| M1 | 工单管理 | 工单创建、分类、状态流转（待分配→已分配→处理中→等待用户/等待内部→已解决/疑似诈骗→已关闭） | + 38|| M2 | 自动分配 | 按班次+在线状态+当前负载+最大工单数自动分配到客服组；组长再分派到组员 | + 39|| M3 | 答应配合状态机 | 独立的答应配合状态流转（已答应→待分配→待提醒→等待提交→已提交/超时→需再次联系→关闭） | + 40|| M4 | 排班出勤管理 | 排班设置、出勤记录（应出勤/实际出勤/迟到/早退/请假/缺勤）、在线客服池维护 | + 41|| M5 | 绩效统计 | 回复效率（回复用户数/处理工单数/首次回复时长分布）；转化统计（RSO回评/RDO测评登记订单数/获取评价数/完成率）；目标完成统计 | + 42|| M6 | 对外 API Gateway | 供其他子系统创建工单、查询工单状态、查询绩效数据 | + 43| + 44|--- + 45| + 46|## 2. 各模块内外说明 + 47| + 48|### 2.1 M1: 工单管理 + 49| + 50|| 维度 | 说明 | + 51|| --- | --- | + 52|| **对内** | 5 种入口（用户消息进入/推送转人工/售后触发/风险触发/电话后续）；工单状态流转（待分配→已分配→处理中→等待用户/等待内部→已解决/疑似诈骗→已关闭）；5 种处理结果（等待用户回复/等待内部协同/答应配合/疑似诈骗/已解决） | + 53|| **对外接口** | `POST /api/tickets` — 创建工单；`PUT /api/tickets/{id}/status` — 更新状态 | + 54|| **数据写入** | `support_tickets` | + 55|| **依赖** | `GET /api/identity/context/{person_id}` — 展示用户上下文卡 | + 56|| **待确认** | 工单类型分类维度？（售后/催评/风险/其他？是否需要自定义分类？） | + 57| + 58|### 2.2 M2: 自动分配 + 59| + 60|| 维度 | 说明 | + 61|| --- | --- | + 62|| **对内** | 分配算法（查班次+在线状态+当前负载+最大工单数→自动分配到客服组）；组长可在组内重新分派到具体组员；分配日志记录 | + 63|| **对外接口** | 内部服务 | + 64|| **数据写入** | `support_assignment_logs` | + 65|| **依赖** | M4 排班出勤数据 | + 66|| **待确认** | 「当前负载」按什么计算？（未关闭工单数？最近 N 小时处理量？两者加权？） | + 67| + 68|### 2.3 M3: 答应配合状态机 + 69| + 70|| 维度 | 说明 | + 71|| --- | --- | + 72|| **对内** | 独立于工单状态的状态机（已答应配合→待分配负责人→待提醒→等待提交→已提交评价/已提交反馈→超时→需再次联系→已关闭）；防止承诺用户流失；超时提醒机制 | + 73|| **对外接口** | `POST /api/support/followups` — 创建跟进任务；`PUT /api/support/followups/{id}` — 更新状态 | + 74|| **数据写入** | `support_followups` | + 75|| **待确认** | 答应配合后多少天未提交算超时？超时后提醒频率？多次提醒无果后是否降级？ | + 76| + 77|### 2.4 M4: 排班出勤管理 + 78| + 79|| 维度 | 说明 | + 80|| --- | --- | + 81|| **对内** | 排班设置（按日/周的班次安排）；出勤记录（应出勤/实际出勤/出勤率/迟到/早退/请假/缺勤）；在线客服池（排班+在线状态→可用客服列表） | + 82|| **对外接口** | `GET /api/support/available-agents` — 查询当前可用客服 | + 83|| **数据写入** | `attendance_records`, `shift_schedules` | + 84|| **待确认** | 排班是否对接外部 HR 系统还是独立管理？客服手动签入/签出？ | + 85| + 86|### 2.5 M5: 绩效统计 + 87| + 88|| 维度 | 说明 | + 89|| --- | --- | + 90|| **对内** | 回复效率（回复用户数、处理工单数、发送消息数、首次回复时长：平均/中位数/最大/最小）；转化统计（RSO 回评登记订单数、RDO 测评登记订单数、获取评价数、评价完成率）；目标完成（月目标、当前完成、完成率、历史趋势）；主管看板 | + 91|| **对外接口** | `GET /api/support/stats?agent_id=&period=` — 绩效数据查询 | + 92|| **数据写入** | `support_performance_snapshots`（定时快照） | + 93|| **待确认** | 绩效统计周期（日/周/月？）主管看板是否需要实时数据还是 T+1 汇总？ | + 94| + 95|--- + 96| + 97|## 3. 对外 API 契约（草案） + 98| + 99|| 接口 | 方法 | 输入 | 输出 | 消费者 | + 100|| --- | --- | --- | --- | --- | + 101|| 创建工单 | `POST /api/tickets` | `{person_id, source, type, description}` | `{ticket_id}` | outreach（TEL→工单/EDM回复→工单）、risk（诈骗→工单） | + 102|| 工单详情 | `GET /api/tickets/{id}` | ticket_id | 完整工单+上下文卡 | 客服前端 | + 103|| 查询用户打开工单 | `GET /api/tickets?person_id=&status=open` | person_id | `[{ticket_id, status}]` | outreach（渠道去重）、quota（终校） | + 104|| 客服可用性 | `GET /api/support/available-agents` | 无 | `[{agent_id, current_load}]` | outreach（分配参考） | + 105|| 绩效查询 | `GET /api/support/stats?agent_id=&period=` | agent_id + 周期 | 绩效数据 | 客服管理前端 | + 106| + 107|--- + 108| + 109|## 4. 数据对象 + 110| + 111|| 对象 | 核心字段 | 说明 | + 112|| --- | --- | --- | + 113|| `support_tickets` | ticket_id, person_id, source, type, status, assigned_agent, assigned_group, created_at, resolved_at | 工单主表 | + 114|| `support_followups` | followup_id, ticket_id, person_id, status(PROMISED/ASSIGNED/WAITING/SUBMITTED/TIMEOUT/RECONTACT/CLOSED), promised_at, deadline_at, reminded_at | 答应配合跟进 | + 115|| `support_assignment_logs` | log_id, ticket_id, from_agent, to_agent, reason, assigned_at | 工单分配日志 | + 116|| `attendance_records` | record_id, agent_id, date, status(PRESENT/LATE/EARLY/ABSENT/LEAVE), check_in, check_out | 出勤记录 | + 117|| `shift_schedules` | shift_id, agent_id, date, shift_type, start_time, end_time | 排班表 | + 118|| `support_performance_snapshots` | snapshot_id, agent_id, period, tickets_handled, messages_sent, avg_first_reply, rso_orders, rdo_orders, reviews_obtained, completion_rate | 绩效快照 | + 119| + 120|--- + 121| + 122|## 5. 业务澄清问题清单 — support + 123| + 124|### 5.1 工单管理（5 项） + 125| + 126|| # | 问题 | 优先级 | + 127|| --- | --- | --- | + 128|| S-01 | 工单的来源分类有哪些？（IM 转人工 / 电话后续 / EDM 回复 / 用户主动联系 / 风险触发 / 其他？）每种来源的优先级是否不同？ | **P0** | + 129|| S-02 | 工单状态「等待用户」和「等待内部」的超时分别是多少？超时后谁来提醒？提醒方式（IM/系统通知）？ | **P0** | + 130|| S-03 | 三套并行状态（工单状态/答应配合状态/风险状态）的交互规则？例如：风险状态变为「确认诈骗」时工单是否自动关闭？（目前文档说是独立拆开的） | P1 | + 131|| S-04 | 工单关闭后是否允许重新打开？什么条件可重开？ | P1 | + 132|| S-05 | 工单是否有 SLA（服务级别协议）？不同来源/类型的工单 SLA 不同？ | P2 | + 133| + 134|### 5.2 自动分配（4 项） + 135| + 136|| # | 问题 | 优先级 | + 137|| --- | --- | --- | + 138|| S-06 | 「当前负载」如何精确计算？（未关闭工单数 × 权重？最近 N 小时处理量？工单类型权重不同？） | **P0** | + 139|| S-07 | 「最大工单数」是什么？（每个客服同时最多持有 X 个工单？）这个值是否统一还是按级别不同？ | **P0** | + 140|| S-08 | 在线状态如何判定？（手动签入/签出？系统自动检测活跃度？N 分钟无操作自动离线？） | P1 | + 141|| S-09 | 自动分配如果分配给了离线/满载的客服，兜底机制是什么？（自动转移给组长？放入公共池？） | P1 | + 142| + 143|### 5.3 答应配合（3 项） + 144| + 145|| # | 问题 | 优先级 | + 146|| --- | --- | --- | + 147|| S-10 | 答应配合后多少天未提交算超时？超时后的提醒频率？（第 1/3/7 天各提醒一次？）多次提醒无果后关闭还是降级？ | **P0** | + 148|| S-11 | 用户答应配合但最终提交了错误的 ASIN 评价——算不算配合完成？如何处理？ | P1 | + 149|| S-12 | 答应配合状态是否只针对客服工单场景？IM 直推中用户答应的算不算？ | P1 | + 150| + 151|### 5.4 排班出勤（3 项） + 152| + 153|| # | 问题 | 优先级 | + 154|| --- | --- | --- | + 155|| S-13 | 排班管理是否对接外部 HR 系统？还是独立在 support 子系统内管理？ | P1 | + 156|| S-14 | 菲律宾客服团队的工作制度？（班次类型：早班/中班/晚班？每班时长？每周几天？） | P1 | + 157|| S-15 | 出勤异常（迟到/早退/缺勤）是否需要自动通知主管？通知方式？ | P2 | + 158| + 159|### 5.5 绩效统计（3 项） + 160| + 161|| # | 问题 | 优先级 | + 162|| --- | --- | --- | + 163|| S-16 | 转化统计中 RSO（回评）和 RDO（测评）如何区分？（按工单来源？按关联计划类型？按客服标记？） | P1 | + 164|| S-17 | 「首次回复时长」从什么时候开始计时？（工单分配给客服的时间？用户消息到达时间？） | P1 | + 165|| S-18 | 评价完成率的分母是什么？（答应配合数？登记订单数？触达数？） | P2 | + 166| +### 5.6 多语言与国际化（3 项） + +| # | 问题 | 优先级 | +| --- | --- | --- | +| S-19 | 客服工作台需要支持哪些语言？（菲律宾客服用英语+Tagalog？面向用户的消息是否需要自动翻译？） | P1 | +| S-20 | 用户消息的多语言处理——用户用德语/法语/西语发消息时，客服如何理解？（是否需要集成翻译工具？） | P2 | +| S-21 | 系统管理界面（排班/绩效/设置）是否需要多语言？面向中国管理团队的是中文界面？ | P2 | + +### 5.7 知识库与话术（3 项） + +| # | 问题 | 优先级 | +| --- | --- | --- | +| S-22 | 是否需要集成知识库/FAQ？（客服在处理售后时快速查找产品信息、常见问题解答？） | P2 | +| S-23 | 是否需要「快捷回复」功能？（预设常用回复模板——「请提供你的订单号」「我们将在 24h 内处理你的退款」等） | P1 | +| S-24 | 快捷回复模板是否支持按场景/产品分类？（不同产品的售后话术不同——模板管理和权限？） | P2 | + +### 5.8 客服质量管控（4 项） + +| # | 问题 | 优先级 | +| --- | --- | --- | +| S-25 | 是否需要客户满意度（CSAT）调查？（工单关闭后推送满意度评分——评分方式？计入绩效？） | P2 | +| S-26 | 是否需要质检功能？（组长抽查客服的对话记录进行评分——质检抽样比例？质检标准？） | P2 | +| S-27 | 客服技能分组——不同客服擅长不同类型工单（售后/催评/风控）——是否需要基于技能的自动分配？ | P1 | +| S-28 | 升级工单的处理流程——什么条件下工单升级到组长/负责人？（超时？用户投诉？疑似诈骗？） | P1 | + +### 5.9 排班与出勤补充（3 项） + +| # | 问题 | 优先级 | +| --- | --- | --- | +| S-29 | 排班是否支持轮班制？（周一到周日每天不同的班次安排）排班变更的通知方式？ | P1 | +| S-30 | 临时调班/换班请求——客服之间是否可以自助换班？是否需要审批？ | P2 | +| S-31 | 节假日/特殊日期的排班策略？（当地节假日——菲律宾假日 vs 美国假日 vs 中国假日——按哪国日历？） | P1 | + +### 5.10 绩效统计补充（3 项） + +| # | 问题 | 优先级 | +| --- | --- | --- | +| S-32 | 绩效考核周期？（日/周/月/季度？）绩效数据是否需要导出为报表？ | P1 | +| S-33 | 绩效目标是否可自定义？（不同组的目标不同？新人目标低于老员工？）目标由谁设置？ | P1 | +| S-34 | 绩效看板是否需要实时数据还是 T+1 汇总？（主管需要实时看到当前客服处理了多少工单？） | P2 | + +### 5.11 实施层面（3 项） + +| # | 问题 | 优先级 | +| --- | --- | --- | +| S-35 | 客服使用的 IM 工具——是独立于 outreach 的客服专用 IM 还是嵌入在客服工作台内的 Web IM？ | P1 | +| S-36 | 工单数据是否需要与 outreach 的交互记录打通？（同一个用户在 IM 的聊天记录是否需要关联到工单？） | P1 | +| S-37 | 客服工作台的实时性要求——新工单到达后多少秒内需要在客服界面显示？（WebSocket 推送 vs 轮询？） | P2 | diff --git a/wishfulfilled-wiki/05_需求文档/06-子系统-风险与反欺诈.md b/wishfulfilled-wiki/05_需求文档/06-子系统-风险与反欺诈.md new file mode 100644 index 0000000..1b54e5d --- /dev/null +++ b/wishfulfilled-wiki/05_需求文档/06-子系统-风险与反欺诈.md @@ -0,0 +1,191 @@ + 1|# 子系统 06 — 风险与反欺诈 (`risk`) v1.0 + 2| + 3|## 子系统概述 + 4| + 5|| 维度 | 说明 | + 6|| --- | --- | + 7|| 代号 | `risk` | + 8|| 核心职责 | 强弱关联判断、黑名单实体管理、风险事件管理、双重退款检测 | + 9|| 数据所有权 | `risk_signals`, `risk_cases`, `blacklist_entities`, `refund_match_results` | + 10|| 启动依赖 | identity（软依赖） | + 11|| 外部系统依赖 | Amazon（退款数据）、财务系统（OA 返款数据） | + 12| + 13|--- + 14| + 15|## 1. 模块划分 + 16| + 17|``` + 18|┌─────────────────────────────────────────────────────────────┐ + 19|│ risk 子系统 │ + 20|│ │ + 21|│ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │ + 22|│ │ M1: 关联判断 │ │ M2: 黑名单 │ │ M3: 双重退款 │ │ + 23|│ │ 引擎 │→│ 管理 │ │ 检测 │ │ + 24|│ └──────┬───────┘ └──────┬───────┘ └──────┬───────┘ │ + 25|│ │ │ │ │ + 26|│ ▼ ▼ ▼ │ + 27|│ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │ + 28|│ │ M4: 风险事件 │ │ M5: 风险审核 │ │ M6: 对外 API │ │ + 29|│ │ 管理 │ │ Admin │ │ Gateway │ │ + 30|│ └──────────────┘ └──────────────┘ └──────────────┘ │ + 31|│ │ + 32|└─────────────────────────────────────────────────────────────┘ + 33|``` + 34| + 35|| # | 模块 | 职责 | + 36|| --- | --- | --- | + 37|| M1 | 关联判断引擎 | 对每次风险信号做强弱关联判断（强：邮箱/设备/电话/地址/订单号/ProfileID/收款信息 命中→高风险；弱：IP单独/姓名单独/同址异名→观察+复核） | + 38|| M2 | 黑名单管理 | 黑名单实体管理（添加/移除/过期）、黑名单同步、命中查询 | + 39|| M3 | 双重退款检测 | Amazon 退款记录 vs OA 返款记录的自动比对，检测重复退款 | + 40|| M4 | 风险事件管理 | 风险事件创建、状态流转、关联工单/推送/计划状态回写 | + 41|| M5 | 风险审核 Admin | 人工复核弱关联风险、确认/排除诈骗、黑名单操作 | + 42|| M6 | 对外 API Gateway | 供所有子系统查询风险状态、上报风险信号 | + 43| + 44|--- + 45| + 46|## 2. 各模块内外说明 + 47| + 48|### 2.1 M1: 关联判断引擎 + 49| + 50|| 维度 | 说明 | + 51|| --- | --- | + 52|| **对内** | 每次风险信号进入时执行：8 项强关联维度（邮箱/设备号/电话/收件人姓名+地址/订单号/聊天记录/Profile ID/收款信息）→任一命中→高风险；3 项弱关联维度（IP单独/姓名单独/同址异名）→高风险观察+人工复核；判断结果：强关联/弱关联/无关联 | + 53|| **对外接口** | `GET /api/risk/check/{person_id}` — 风险查询（含关联判断结果） | + 54|| **数据写入** | `risk_signals` | + 55|| **依赖** | `GET /api/identity/context/{person_id}` — 获取身份线索用于关联判断 | + 56|| **关键规则** | 风险判断不是一次性，每次有效互动都要重做；非 APP 用户缺设备/注册邮箱等维度→风险识别能力下降 | + 57| + 58|### 2.2 M2: 黑名单管理 + 59| + 60|| 维度 | 说明 | + 61|| --- | --- | + 62|| **对内** | 黑名单实体 CRUD（邮箱/设备/电话/地址/收款信息）；黑名单命中查询（任何子系统查询用户是否在黑名单）；黑名单同步（确认诈骗后同步到黑名单）；黑名单过期/申诉机制 | + 63|| **对外接口** | `GET /api/risk/blacklist/check?type=EMAIL&value=xxx` — 黑名单命中检查 | + 64|| **数据写入** | `blacklist_entities` | + 65|| **待确认** | 黑名单是否有过期时间？申诉/移除流程？ | + 66| + 67|### 2.3 M3: 双重退款检测 + 68| + 69|| 维度 | 说明 | + 70|| --- | --- | + 71|| **对内** | 采集 Amazon 退款记录（外部系统同步）+ OA 返款记录（财务系统同步）；按订单号/用户/金额/时间自动比对；匹配结果：无重复/疑似重复/确认重复；确认重复时强告警+阻止后续返款 | + 72|| **对外接口** | `GET /api/risk/double-refund-check/{person_id}` — 双重退款检测 | + 73|| **数据写入** | `refund_match_results` | + 74|| **依赖** | Amazon 退款数据（外部）、OA 返款数据（外部财务系统） | + 75|| **待确认** | Amazon 退款数据如何及时获取？OA 返款记录是否已有 API？ | + 76| + 77|### 2.4 M4: 风险事件管理 + 78| + 79|| 维度 | 说明 | + 80|| --- | --- | + 81|| **对内** | 风险事件创建（客服上报疑似诈骗 / 双重退款检测 / 关联判断命中）；事件状态流转（待复核→复核中→确认风险/排除风险）；高风险链路动作（拦截继续推送/拦截自动退款/拦截自动放行）；回写关联工单/推送/计划状态 | + 82|| **对外接口** | `POST /api/risk/report` — 上报风险信号（客服、系统自动均可调用） | + 83|| **数据写入** | `risk_cases` | + 84| + 85|### 2.5 M5: 风险审核 Admin + 86| + 87|| 维度 | 说明 | + 88|| --- | --- | + 89|| **对内** | 人工复核弱关联风险；确认/排除诈骗判定；黑名单手动操作；风险口径维护 | + 90|| **对外接口** | 管理 API | + 91|| **待确认** | 复核时效要求？（N 分钟内必须复核？） | + 92| + 93|--- + 94| + 95|## 3. 对外 API 契约（草案） + 96| + 97|| 接口 | 方法 | 输入 | 输出 | 消费者 | + 98|| --- | --- | --- | --- | --- | + 99|| 风险查询 | `GET /api/risk/check/{person_id}` | person_id | `{risk_level(NONE/WEAK/STRONG), signals[], cases[]}` | 所有子系统（每次互动时调用） | + 100|| 上报风险信号 | `POST /api/risk/report` | `{person_id, signal_type, evidence, reported_by}` | `{signal_id}` | support（客服上报诈骗）、outreach（异常互动） | + 101|| 黑名单命中 | `GET /api/risk/blacklist/check?type=&value=` | 维度类型+值 | `{hit, entity}` | outreach（发送前）、identity（身份归并时） | + 102|| 双重退款检测 | `GET /api/risk/double-refund-check/{person_id}` | person_id | `{status, matched_refunds[]}` | outreach（返款前）、support（退款处理前） | + 103| + 104|--- + 105| + 106|## 4. 数据对象 + 107| + 108|| 对象 | 核心字段 | 说明 | + 109|| --- | --- | --- | + 110|| `risk_signals` | signal_id, person_id, signal_type, hit_dimensions[], risk_level(STRONG/WEAK), detected_at | 风险信号（每次互动生成的判断） | + 111|| `risk_cases` | case_id, person_id, source, status(PENDING_REVIEW/REVIEWING/CONFIRMED_RISK/RULED_OUT), reviewer, created_at, resolved_at | 风险事件 | + 112|| `blacklist_entities` | entity_id, entity_type(EMAIL/DEVICE/PHONE/ADDRESS/PAYMENT), entity_value, status(ACTIVE/EXPIRED/APPEALED), added_at, added_by | 黑名单实体 | + 113|| `refund_match_results` | match_id, person_id, amazon_refund_id, oa_refund_id, match_status(NO_DUPLICATE/SUSPECTED/CONFIRMED), matched_at | 双重退款比对结果 | + 114| + 115|--- + 116| + 117|## 5. 业务澄清问题清单 — risk + 118| + 119|### 5.1 强弱关联规则（4 项） + 120| + 121|| # | 问题 | 优先级 | + 122|| --- | --- | --- | + 123|| R-01 | 8 项强关联维度中，每个维度的命中是独立判断还是组合判断？（例如仅「设备号命中」是否就足够判定强关联？还是需要「设备号 + 电话」同时命中？） | **P0** | + 124|| R-02 | 「强关联→直接进入高风险或黑名单链路」——这里的「直接」是指全自动化拦截无需人工确认？还是系统先拦截再人工审核？（涉及自动化力度） | **P0** | + 125|| R-03 | 弱关联的「观察期」多长？观察期过后是自动解除还是必须人工确认？观察期内用户继续参与互动如何处理？ | P1 | + 126|| R-04 | 风险判断中「IP 单独命中」列为弱关联——IP 从哪里获取？（JOYHUB APP？EDM 邮件头？客服系统？）不同来源的 IP 可靠性不同 | P1 | + 127| + 128|### 5.2 双重退款（4 项） + 129| + 130|| # | 问题 | 优先级 | + 131|| --- | --- | --- | + 132|| R-05 | Amazon 退款数据如何获取？（SP-API 实时拉取？T+1 同步？手动导入 CSV？）同步频率决定检测时效 | **P0** | + 133|| R-06 | OA 返款系统是哪个？是否有 API？如果没有 API，返款记录怎么录入？（财务手动录入？CSV 导入？） | **P0** | + 134|| R-07 | 「双重退款」比对的关键字段是什么？（订单号？金额？用户？时间窗口？）匹配精度？（金额完全相等还是 ±X%？时间窗口多宽？） | P1 | + 135|| R-08 | 确认重复退款后，阻止后续返款——「阻止」是指系统自动拦截返款指令，还是只发告警让人工决定？ | P1 | + 136| + 137|### 5.3 黑名单管理（3 项） + 138| + 139|| # | 问题 | 优先级 | + 140|| --- | --- | --- | + 141|| R-09 | 黑名单是否有过期/申诉/解除机制？（例如用户被误标后如何申诉？谁有权解除？） | P1 | + 142|| R-10 | 黑名单是否需要与外部系统同步？（例如 JOYHUB 的黑名单？Amazon 的欺诈标记？）同步方向？ | P1 | + 143|| R-11 | 黑名单的粒度——是标记「真实人」还是「某个维度的值」？（标记的是真实人 ID 还是具体的邮箱/设备？） | P1 | + 144| + 145|### 5.4 风险可见性（3 项） + 146| + 147|| # | 问题 | 优先级 | + 148|| --- | --- | --- | + 149|| R-12 | 文档要求「客服、审核、退款等环节必须都能看到风险提醒」——风险提醒的展现形式是什么？（红色标签？弹窗？工单页顶部横幅？） | P1 | + 150|| R-13 | 风险状态的「提醒」通过什么通道发送？（audit 通知中心？IM 消息？系统内消息？） | P1 | + 151|| R-14 | 风险人员角色是否需要独立的风险控制台前端？该前端需要哪些功能？（事件列表/审核工作台/黑名单管理/统计报表？） | P2 | + 152| +### 5.5 高级风险检测能力（4 项） + +| # | 问题 | 优先级 | +| --- | --- | --- | +| R-15 | 是否需要行为速度检测？（同一真实人短时间内大量注册/大量申请退款/大量提交评价→触发异常行为告警？） | P1 | +| R-16 | 是否需要设备指纹/浏览器指纹？（识别同一设备换账号、模拟器、虚拟机等欺诈行为？） | P2 | +| R-17 | 是否需要地理位置异常检测？（同一账号短期内从不同国家/城市登录→触发告警？） | P2 | +| R-18 | 风险评分模型——是否需要一个综合风险分数（0-100）而非二元判断（强/弱/无）？评分模型的因子和权重？ | P1 | + +### 5.6 风险事件处理流程（3 项） + +| # | 问题 | 优先级 | +| --- | --- | --- | +| R-19 | 风险事件的优先级（P0/P1/P2）如何定义？（双重退款确认→P0？单次弱关联→P2？）不同优先级的响应 SLA？ | P1 | +| R-20 | 风险人员的工作台——是否需要「待审核队列」「审核中」「已处理」等看板视图？是否需要分配给具体审核人？ | P1 | +| R-21 | 同一个人短时间内触发多次风险信号——是每次生成新事件还是合并到已有事件？合并规则？ | P1 | + +### 5.7 黑名单管理补充（3 项） + +| # | 问题 | 优先级 | +| --- | --- | --- | +| R-22 | 黑名单的生效范围——加入黑名单后是「全系统拦截」还是「只拦截某些操作」？（是否还允许正常购买？只拦截测评参与？） | P1 | +| R-23 | 黑名单是否需要分级？（一级黑名单→全拦截 / 二级黑名单→降频+人工审核 / 三级黑名单→仅标记提醒） | P1 | +| R-24 | 黑名单是否需要与外部欺诈数据库同步？（如行业共享的欺诈黑名单？Amazon 的 abuse 标记？） | P2 | + +### 5.8 非 APP 用户风险盲区（2 项） + +| # | 问题 | 优先级 | +| --- | --- | --- | +| R-25 | 文档已明确「非 APP 用户识别能力下降」——是否需要额外的风控措施？（例如非 APP 用户的返款额度降低？首次返款必须人工审核？） | P1 | +| R-26 | 是否计划引导非 APP 用户注册 APP 以补全风险画像？（EDM/客服主动引导注册——注册转化跟踪？） | P2 | + +### 5.9 实施层面（3 项） + +| # | 问题 | 优先级 | +| --- | --- | --- | +| R-27 | 风险判断的实时性要求——每次互动时实时调用 risk API？（性能 overhead？需要缓存策略？） | P1 | +| R-28 | 双重退款检测的时效——Amazon 退款数据（外部）同步延迟 vs OA 返款实时——T+N 的延迟是否可接受？ | P1 | +| R-29 | 风险事件的数据保留策略？（已解决的诈骗案件数据保留多久？用于后续模型训练还是定期清理？） | P2 | diff --git a/wishfulfilled-wiki/05_需求文档/07-子系统-评价结果追踪.md b/wishfulfilled-wiki/05_需求文档/07-子系统-评价结果追踪.md new file mode 100644 index 0000000..3183fe9 --- /dev/null +++ b/wishfulfilled-wiki/05_需求文档/07-子系统-评价结果追踪.md @@ -0,0 +1,171 @@ + 1|# 子系统 07 — 评价结果追踪 (`review`) v1.0 + 2| + 3|## 子系统概述 + 4| + 5|| 维度 | 说明 | + 6|| --- | --- | + 7|| 代号 | `review` | + 8|| 核心职责 | 用户真实提交评价记录、Amazon 展示核验、ASIN 健康/计划完成度更新回流 | + 9|| 数据所有权 | `review_submission_records`, `review_display_checks`, `review_results` | + 10|| 启动依赖 | identity / planning（软依赖） | + 11|| 外部系统依赖 | Amazon（评价展示状态、ASIN 评分数据） | + 12| + 13|--- + 14| + 15|## 1. 模块划分 + 16| + 17|``` + 18|┌─────────────────────────────────────────────────────────────┐ + 19|│ review 子系统 │ + 20|│ │ + 21|│ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │ + 22|│ │ M1: 评价提交 │ │ M2: 展示核验 │ │ M3: 结果回流 │ │ + 23|│ │ 记录 │→│ │→│ 引擎 │ │ + 24|│ └──────┬───────┘ └──────┬───────┘ └──────┬───────┘ │ + 25|│ │ │ │ │ + 26|│ ▼ ▼ ▼ │ + 27|│ ┌──────────────┐ ┌──────────────┐ │ + 28|│ │ M4: 异常观察 │ │ M5: 对外 API │ │ + 29|│ │ 队列 │ │ Gateway │ │ + 30|│ └──────────────┘ └──────────────┘ │ + 31|│ │ + 32|└─────────────────────────────────────────────────────────────┘ + 33|``` + 34| + 35|| # | 模块 | 职责 | + 36|| --- | --- | --- | + 37|| M1 | 评价提交记录 | 记录用户真实提交评价的事实（提交时点、提交证据、关联计划、关联 ASIN） | + 38|| M2 | 展示核验 | 核查 Amazon 是否展示该评价 / 是否可核验 | + 39|| M3 | 结果回流引擎 | 将评价结果反馈给 planning（计划完成度）、identity（用户标签）、audit | + 40|| M4 | 异常观察队列 | 用户已提交但 Amazon 未展示 / 暂不可核验的评价，进入定期复查队列 | + 41|| M5 | 对外 API Gateway | 供 outreach、planning 查询评价进度、提交评价 | + 42| + 43|--- + 44| + 45|## 2. 各模块内外说明 + 46| + 47|### 2.1 M1: 评价提交记录 + 48| + 49|| 维度 | 说明 | + 50|| --- | --- | + 51|| **对内** | 记录两个核心事实：①用户真实提交评价（时间、ASIN、评论内容/截图/链接、关联计划）；②提交后立即更新真实人累计评价额度（调用 quota 子系统 `commit`） | + 52|| **对外接口** | `POST /api/reviews/submission` — 记录评价提交 | + 53|| **数据写入** | `review_submission_records` | + 54|| **依赖** | `POST /api/quota/commit` — 确认额度占用（提交后立即计数12） | + 55|| **关键规则** | 「用户真实提交评价」和「Amazon 展示确认」是两个独立事实；额度计数按前者，计划完成按后者 | + 56| + 57|### 2.2 M2: 展示核验 + 58| + 59|| 维度 | 说明 | + 60|| --- | --- | + 61|| **对内** | 核查 Amazon 是否展示该评价 / 是否可核验；核验方式（待确认：爬取 / 手动 / API / 截图？）；核验结果：①展示或可核验→计入计划完成 ②未展示/暂不可核验→保留已提交事实→进入异常观察 | + 62|| **对外接口** | `POST /api/reviews/verify` — 触发核验（或定时核验） | + 63|| **数据写入** | `review_display_checks` | + 64|| **依赖** | Amazon（评价展示数据） | + 65|| **待确认** | 核验是自动还是人工？核验频率？ | + 66| + 67|### 2.3 M3: 结果回流引擎 + 68| + 69|| 维度 | 说明 | + 70|| --- | --- | + 71|| **对内** | 评价确认展示后：①通知 planning 更新计划完成度 ②通知 identity 更新用户标签（例如标记为「已回评用户」）③写入审计日志；免评结果回流：①更新 ASIN 健康与权重变化 ②更新计划完成度 ③通知 planning | + 72|| **对外接口** | 内部事件发布 | + 73|| **数据写入** | `review_results` | + 74|| **依赖** | `PUT /api/plans/{id}/status`（更新计划状态） | + 75| + 76|### 2.4 M4: 异常观察队列 + 77| + 78|| 维度 | 说明 | + 79|| --- | --- | + 80|| **对内** | 用户已提交但 Amazon 未展示/暂不可核验的评价，进入异常观察队列；定期复查（例如每天查一次 Amazon 是否已展示）；超过观察期仍未展示→标记异常→通知运营 | + 81|| **数据写入** | `review_display_checks`（更新状态） | + 82|| **待确认** | 观察周期多长？复查频率？观察期满后如何处理？ | + 83| + 84|--- + 85| + 86|## 3. 对外 API 契约（草案） + 87| + 88|| 接口 | 方法 | 输入 | 输出 | 消费者 | + 89|| --- | --- | --- | --- | --- | + 90|| 记录评价提交 | `POST /api/reviews/submission` | `{person_id, asin, plan_id, evidence, submitted_at}` | `{submission_id, quota_updated}` | outreach（IM 核验后/客服确认后） | + 91|| 查询计划评价进度 | `GET /api/reviews/status/{plan_id}` | plan_id | `{total_submissions, verified, pending, completion_rate}` | planning | + 92|| 查询用户评价历史 | `GET /api/reviews/history/{person_id}` | person_id | `[{submission_id, asin, status, submitted_at}]` | identity（上下文卡） | + 93|| ASIN 评价统计 | `GET /api/reviews/asin-stats/{asin}` | asin | `{submission_count, verified_count, pending_count}` | planning | + 94| + 95|--- + 96| + 97|## 4. 数据对象 + 98| + 99|| 对象 | 核心字段 | 说明 | + 100|| --- | --- | --- | + 101|| `review_submission_records` | submission_id, person_id, asin, plan_id, evidence_type, evidence, submitted_at, quota_updated | 评价提交记录（核心事实一） | + 102|| `review_display_checks` | check_id, submission_id, asin, check_method, check_result(DISPLAYED/NOT_DISPLAYED/UNVERIFIABLE), checked_at, retry_count, status(OBSERVING/CONFIRMED/ABNORMAL) | 展示核验记录（核心事实二） | + 103|| `review_results` | result_id, plan_id, asin, submission_count, verified_count, completion_rate, asin_health_change, updated_at | 评价结果汇总 | + 104| + 105|--- + 106| + 107|## 5. 业务澄清问题清单 — review + 108| + 109|### 5.1 评价提交记录（3 项） + 110| + 111|| # | 问题 | 优先级 | + 112|| --- | --- | --- | + 113|| V-01 | 「用户真实提交评价」的证据形式是什么？（用户上传的截图？Amazon 评论链接？系统自动检测？）不同形式如何验证真伪？ | **P0** | + 114|| V-02 | 一个用户为同一个 ASIN 提交多条评价（如果 Amazon 允许）——每一条都独立计入累计12额度吗？ | **P0** | + 115|| V-03 | 评价提交记录是 outreach（IM/客服）写入还是用户直接提交？（系统内提交 vs 系统外提交的区别）系统外提交如何登记？ | P1 | + 116| + 117|### 5.2 展示核验（4 项） + 118| + 119|| # | 问题 | 优先级 | + 120|| --- | --- | --- | + 121|| V-04 | Amazon 评价展示的核验方式是？（定时爬取 Amazon 产品页？SP-API 拉取评价列表？用户上传截图人工审核？混合方式？） | **P0** | + 122|| V-05 | 如果通过爬取核验——爬取频率？（小时级？天级？）如何识别「哪条评价是本次计划用户提交的」？（靠评论者名字匹配？靠时间窗口？） | **P0** | + 123|| V-06 | 「暂不可核验」的常见原因有哪些？（Amazon 审核中/延迟展示/被 Amazon 删除？）每种原因的处理策略是否不同？ | P1 | + 124|| V-07 | 核验失败的兜底机制——如果 Amazon API 不可用或爬取失败，是否允许人工确认？ | P1 | + 125| + 126|### 5.3 异常观察队列（2 项） + 127| + 128|| # | 问题 | 优先级 | + 129|| --- | --- | --- | + 130|| V-08 | 异常观察队列的观察期多长？（1 天？7 天？30 天？）复查频率？（每天？每周？）观察期满后未展示→如何处理？ | P1 | + 131|| V-09 | 多少条评价进入异常观察算异常阈值？（单计划 10% 未展示→通知？单用户多次未展示→标记？） | P2 | + 132| + 133|### 5.4 结果回流（3 项） + 134| + 135|| # | 问题 | 优先级 | + 136|| --- | --- | --- | + 137|| V-10 | ASIN 健康「回流」的具体动作是什么？（更新 ASIN 评分/评价数到 planning？触发新一轮需求评估？更新 outreach 的触达策略？） | P1 | + 138|| V-11 | 计划完成度的计算方式——「评价确认展示」即算完成？还是需要确认展示 + 关联到本计划用户？（如何确保那条展示的评价确实是本计划用户的？） | P1 | + 139|| V-12 | 免评结果的「权重变化」如何量化？（Amazon 不直接提供权重数据——如何通过间接指标判断？） | P2 | + 140| +### 5.5 评价质量管理（4 项） + +| # | 问题 | 优先级 | +| --- | --- | --- | +| V-13 | 是否需要评价内容分析？（好评/中评/差评？评价字数？是否含图片/视频？——这些影响评价质量评分？） | P2 | +| V-14 | 差评检测和响应——用户提交了差评（1-2 星）是否需要自动触发售后工单？（「差评补救」流程？） | P1 | +| V-15 | 虚假评价检测——用户提交的评价是否可能被 Amazon 判定为虚假评价并删除？（系统是否需要内部质量评分来预测被删风险？） | P2 | +| V-16 | 评价的 ASIN 匹配校验——用户声称对 ASIN A 提交了评价但实际是对 ASIN B 提交的——如何检测和处理？ | P1 | + +### 5.6 异常观察队列补充（3 项） + +| # | 问题 | 优先级 | +| --- | --- | --- | +| V-17 | 评价提交后 Amazon 展示的预期时间窗口？（通常 24-48h？最长多久？）超出预期窗口后的自动通知？ | P1 | +| V-18 | Amazon 删除评价（违反社区准则）vs 用户删除评价 vs 评价被折叠——是否能区分？分别如何处理？ | P2 | +| V-19 | 大量评价同时进入异常观察（例如 Amazon 评价系统故障导致全站延迟）——系统如何处理？（自动暂停观察队列？人工干预？） | P2 | + +### 5.7 ASIN 健康回流补充（3 项） + +| # | 问题 | 优先级 | +| --- | --- | --- | +| V-20 | ASIN 健康更新的频率？（每次评价确认展示就更新？每天汇总更新一次？） | P2 | +| V-21 | 如果多人同时对同一 ASIN 提交了评价，是否对 ASIN 健康有复合影响？（例如 5 条 5 星好评 vs 1 条 1 星差评——权重不同） | P2 | +| V-22 | ASIN 健康数据的来源——是 Amazon 直接提供的数据还是系统内部计算？（Amazon 评分 vs 系统追踪到的评价评分可能有差异） | P1 | + +### 5.8 实施层面（2 项） + +| # | 问题 | 优先级 | +| --- | --- | --- | +| V-23 | 评价展示核验如果是爬取 Amazon 页面——爬取频率和多 ASIN 并行爬取能力？（需要爬取几百个 ASIN 时的时间和资源开销） | P1 | +| V-24 | 评价数据是否需要在系统间同步？（outreach 需要知道「用户已提交」→暂停触达；planning 需要知道「评价已确认」→更新计划完成度）数据一致性的保证？ | P1 | diff --git a/wishfulfilled-wiki/05_需求文档/08-子系统-KOC-KOL协作.md b/wishfulfilled-wiki/05_需求文档/08-子系统-KOC-KOL协作.md new file mode 100644 index 0000000..d2d0642 --- /dev/null +++ b/wishfulfilled-wiki/05_需求文档/08-子系统-KOC-KOL协作.md @@ -0,0 +1,187 @@ + 1|# 子系统 08 — KOC/KOL 协作 (`creator`) v1.0 + 2| + 3|## 子系统概述 + 4| + 5|| 维度 | 说明 | + 6|| --- | --- | + 7|| 代号 | `creator` | + 8|| 核心职责 | KOC/KOL 匹配筛选、内容 Brief/Code 分配、内容发布跟踪、带货结果跟踪、JOYCOLLAB 数据同步 | + 9|| 数据所有权 | `exemption_plan_tasks`, `creator_content_records`, `creator_profiles`, `code_records` | + 10|| 启动依赖 | planning（软依赖，免评计划入口） | + 11|| 外部系统依赖 | JOYCOLLAB（KOC/KOL 数据、内容数据、Code 使用、带货订单） | + 12| + 13|--- + 14| + 15|## 1. 模块划分 + 16| + 17|``` + 18|┌─────────────────────────────────────────────────────────────┐ + 19|│ creator 子系统 │ + 20|│ │ + 21|│ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │ + 22|│ │ M1: KOC/KOL │ │ M2: 内容/Code│ │ M3: 结果跟踪 │ │ + 23|│ │ 匹配筛选 │→│ 管理 │→│ │ │ + 24|│ └──────┬───────┘ └──────┬───────┘ └──────┬───────┘ │ + 25|│ │ │ │ │ + 26|│ ▼ ▼ ▼ │ + 27|│ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │ + 28|│ │ M4: JOYCOLLAB│ │ M5: IM/EDM/ │ │ M6: 对外 API │ │ + 29|│ │ 数据同步 │ │ APP 协同 │ │ Gateway │ │ + 30|│ └──────────────┘ └──────────────┘ └──────────────┘ │ + 31|│ │ + 32|└─────────────────────────────────────────────────────────────┘ + 33|``` + 34| + 35|| # | 模块 | 职责 | + 36|| --- | --- | --- | + 37|| M1 | KOC/KOL 匹配筛选 | 按国家/平台/粉丝量/产品类目/历史效果筛选匹配合作对象；检查合作对象风险（历史纠纷/违约） | + 38|| M2 | 内容/Code 管理 | 分配内容 Brief、分配 Code、管理 Code 使用量、素材管理 | + 39|| M3 | 结果跟踪 | 跟踪内容发布状态、点击/跳转数据、Code 使用量、带货订单、转化销量、权重变化 | + 40|| M4 | JOYCOLLAB 数据同步 | 从 JOYCOLLAB 拉取 KOC/KOL 数据、内容数据、Code 使用、带货订单；同步失败告警 | + 41|| M5 | IM/EDM/APP 协同 | KOC 内容二次分发、免评 Code 触达站内用户、活动引流、结果通知 | + 42|| M6 | 对外 API Gateway | 供 planning、outreach、review 查询 | + 43| + 44|--- + 45| + 46|## 2. 各模块内外说明 + 47| + 48|### 2.1 M1: KOC/KOL 匹配筛选 + 49| + 50|| 维度 | 说明 | + 51|| --- | --- | + 52|| **对内** | 免评计划进入后：①按国家/平台/粉丝量/历史效果筛选 KOC/KOL ②按产品类目匹配专长 ③检查合作对象风险（历史纠纷/违约）→有风险记录时提示 | + 53|| **对外接口** | `GET /api/creators/match?plan_id=` — 获取匹配推荐列表 | + 54|| **数据写入** | `creator_profiles`（从 JOYCOLLAB 同步的 KOC/KOL 画像缓存） | + 55|| **待确认** | 匹配是完全自动推荐还是运营人工选择？推荐算法依赖哪些权重？ | + 56| + 57|### 2.2 M2: 内容/Code 管理 + 58| + 59|| 维度 | 说明 | + 60|| --- | --- | + 61|| **对内** | 分配内容 Brief（产品信息/要求/素材/发布时间）；Code 分配（每个 KOC 独立 Code 还是一对多？）；Code 使用量监控 | + 62|| **对外接口** | `POST /api/creators/tasks` — 创建协作任务（含 Brief + Code） | + 63|| **数据写入** | `exemption_plan_tasks`, `code_records` | + 64|| **待确认** | Code 是 JOYCOLLAB 生成还是 USER 系统生成？Code 是优惠码还是追踪码？ | + 65| + 66|### 2.3 M3: 结果跟踪 + 67| + 68|| 维度 | 说明 | + 69|| --- | --- | + 70|| **对内** | 跟踪 6 组结果：①内容发布状态/链接/互动数据 ②点击/跳转量 ③Code 使用量 ④带货订单数 ⑤转化销量 ⑥Listing 权重变化；执行评估：达标→结果回流 / 未达标→调整策略（更换KOC/调整素材/追加Code） | + 71|| **对外接口** | `GET /api/creators/results/{plan_id}` — 免评计划执行结果 | + 72|| **数据写入** | `creator_content_records` | + 73|| **依赖** | JOYCOLLAB 数据同步 | + 74| + 75|### 2.4 M4: JOYCOLLAB 数据同步 + 76| + 77|| 维度 | 说明 | + 78|| --- | --- | + 79|| **对内** | 从 JOYCOLLAB 同步：KOC/KOL 画像数据、内容发布数据、Code 使用数据、带货订单数据；同步记录（时间/成功/失败）；同步失败告警 | + 80|| **对外接口** | 内部定时任务 | + 81|| **数据写入** | 本地缓存表（`creator_profiles`, `creator_content_records`） | + 82|| **待确认** | 同步方向是单向（COLLAB→USER）还是双向？同步频率？ | + 83| + 84|### 2.5 M5: IM/EDM/APP 协同 + 85| + 86|| 维度 | 说明 | + 87|| --- | --- | + 88|| **对内** | 4 种协同动作：①KOC 内容二次分发（IM/APP 推送优质内容）②免评 Code 触达（IM/EDM 分发 Code 给站内用户）③活动引流（APP Push 引导用户进入 KOC 内容页）④结果通知（IM/APP 通知用户 Code 到账/订单确认） | + 89|| **对外接口** | 调用 outreach API：`POST /api/outreach/im/send` 等 | + 90|| **数据写入** | 协同记录 | + 91| + 92|--- + 93| + 94|## 3. 对外 API 契约（草案） + 95| + 96|| 接口 | 方法 | 输入 | 输出 | 消费者 | + 97|| --- | --- | --- | --- | --- | + 98|| KOC/KOL 匹配推荐 | `GET /api/creators/match?plan_id=` | plan_id | `[{creator_id, score, match_reason}]` | planner 前端 | + 99|| 创建协作任务 | `POST /api/creators/tasks` | `{creator_id, plan_id, brief, code, deadline}` | `{task_id}` | planner 前端 | + 100|| 免评执行结果 | `GET /api/creators/results/{plan_id}` | plan_id | `{content, clicks, codes, orders, sales, weight_change}` | review（结果回流）, planning | + 101|| KOC/KOL 画像查询 | `GET /api/creators/{creator_id}` | creator_id | KOC/KOL 完整画像 | planner 前端 | + 102| + 103|--- + 104| + 105|## 4. 数据对象 + 106| + 107|| 对象 | 核心字段 | 说明 | + 108|| --- | --- | --- | + 109|| `exemption_plan_tasks` | task_id, plan_id, creator_id, brief, code, status, assigned_at, deadline | 免评计划协作任务 | + 110|| `creator_content_records` | record_id, task_id, creator_id, content_url, publish_time, engagement_data, synced_at | KOC 内容发布记录 | + 111|| `creator_profiles` | creator_id, name, platform, country, follower_count, category, historical_performance, risk_notes, synced_at | KOC/KOL 画像（从 JOYCOLLAB 同步的本地缓存） | + 112|| `code_records` | code_id, task_id, code_value, code_type, usage_count, usage_limit, status | Code 记录 | + 113| + 114|--- + 115| + 116|## 5. 业务澄清问题清单 — creator + 117| + 118|### 5.1 JOYCOLLAB 对接（4 项） + 119| + 120|| # | 问题 | 优先级 | + 121|| --- | --- | --- | + 122|| K-01 | JOYCOLLAB 中 KOC/KOL 的完整数据字段有哪些？（平台/粉丝量/国家/类目/历史合作效果/历史纠纷/违约——文档部分列出，需确认完整字段清单和 API 可用性） | **P0** | + 123|| K-02 | 数据同步方向是单向（COLLAB→USER）还是双向？（USER 分配的 Brief/Code 是否需要回写到 COLLAB？） | **P0** | + 124|| K-03 | 同步频率？（实时 Webhook？每小时？每天？）同步失败时谁来处理？重试策略？ | P1 | + 125|| K-04 | JOYCOLLAB 是否有现成 API？是 REST API 还是需要开发新的同步接口？ | P1 | + 126| + 127|### 5.2 KOC/KOL 匹配（3 项） + 128| + 129|| # | 问题 | 优先级 | + 130|| --- | --- | --- | + 131|| K-05 | 匹配是运营人工选择还是系统自动推荐？推荐算法的权重？（粉丝量 vs 历史效果 vs 类目匹配 vs 报价？） | P1 | + 132|| K-06 | KOC/KOL 是否有评级/分层体系？（头部/腰部/尾部？）不同层级对应的计划类型是否不同？ | P1 | + 133|| K-07 | 「合作对象风险（历史纠纷/违约）」——风险数据从哪里来？（JOYCOLLAB？人工标记？）什么程度的风险需要拦截？ | P1 | + 134| + 135|### 5.3 Code 与内容（3 项） + 136| + 137|| # | 问题 | 优先级 | + 138|| --- | --- | --- | + 139|| K-08 | Code 是 JOYCOLLAB 生成还是 USER 系统生成？Code 类型？（优惠码/追踪码/专属链接？）一对一还是可以多人共用？ | P1 | + 140|| K-09 | KOC 发布的内容是否需要审核？（Brief 交付后→KOC 创作→审核→发布？）审核流程在哪个系统？ | P2 | + 141|| K-10 | KOC 内容二次分发到 IM/APP——分发策略是什么？（所有优质内容都分发？按产品/地区筛选？） | P2 | + 142| + 143|### 5.4 财务结算（2 项） + 144| + 145|| # | 问题 | 优先级 | + 146|| --- | --- | --- | + 147|| K-11 | KOC/KOL 的提成/返点结算在哪个系统执行？（JOYCOLLAB？财务系统？还是 USER 内触发结算指令？）USER 的责任边界？ | P1 | + 148|| K-12 | 结算数据（提成计算/返点核算/提款记录）是否需要同步到 USER？权限控制（财务数据独立权限）？ | P2 | + 149| +### 5.5 KOC/KOL 分层与定价（3 项） + +| # | 问题 | 优先级 | +| --- | --- | --- | +| K-13 | KOC/KOL 是否有分层体系？（头部/腰部/尾部——按粉丝量划分？按历史带货效果划分？）不同分层的合作价格和权益？ | P1 | +| K-14 | KOC/KOL 的报价/定价数据是否在系统中维护？（用于预算计算和 ROI 分析？） | P2 | +| K-15 | KOC/KOL 是否有签约/合同管理？排他性协议？（签约期内只能推广本品牌产品？）排他性信息是否需要系统记录？ | P2 | + +### 5.6 内容与权益管理（3 项） + +| # | 问题 | 优先级 | +| --- | --- | --- | +| K-16 | KOC/KOL 发布内容的使用权和授权期限？（品牌是否可以二次使用、广告投放、修改？授权条款在系统中管理还是走线下合同？） | P2 | +| K-17 | 内容审核流程——KOC/KOL 创作的内容是否需要品牌方审核后才能发布？（审核不通过→修改→重新审核的流程？） | P1 | +| K-18 | 内容效果评估——除了点击/Code/订单数据外，是否需要评估内容质量？（互动率、完播率、正向评论比例？） | P2 | + +### 5.7 多平台 KOC/KOL 管理（3 项） + +| # | 问题 | 优先级 | +| --- | --- | --- | +| K-19 | KOC/KOL 涉及哪些平台？（YouTube / TikTok / Instagram / Facebook / 博客 / Amazon 站内 Influencer Program？）每个平台的数据来源？ | P1 | +| K-20 | 同一 KOC/KOL 在多个平台有账号——是否在系统中关联为同一个人？（类似 identity 的归并逻辑？） | P2 | +| K-21 | 不同平台的内容格式和指标不同（YouTube 视频 vs Instagram 帖子 vs TikTok 短视频）——结果跟踪如何统一？ | P2 | + +### 5.8 Code 管理补充（2 项） + +| # | 问题 | 优先级 | +| --- | --- | --- | +| K-22 | Code 的类型？（一次性折扣码 / 多次使用码 / 追踪链接 / 专属落地页？）不同类型的生成和追踪逻辑？ | P1 | +| K-23 | Code 的有效期管理？（计划结束后 Code 自动失效？还是保留一段时间？）Code 是否可重复使用？ | P1 | + +### 5.9 实施层面（3 项） + +| # | 问题 | 优先级 | +| --- | --- | --- | +| K-24 | JOYCOLLAB 数据同步失败时的降级策略？（用本地缓存数据？标记为「数据可能过期」？暂停新的协作任务？） | P1 | +| K-25 | KOC/KOL 匹配算法的性能——如果 JOYCOLLAB 有几千个 KOC，匹配需要多少时间？是否有预筛选+精排的两阶段设计？ | P2 | +| K-26 | KOC/KOL 的任务状态如何与 planning 的计划状态联动？（协作任务完成→计划完成度增加→计划状态更新？） | P1 | diff --git a/wishfulfilled-wiki/05_需求文档/09-子系统-审计与通知中心.md b/wishfulfilled-wiki/05_需求文档/09-子系统-审计与通知中心.md new file mode 100644 index 0000000..1691518 --- /dev/null +++ b/wishfulfilled-wiki/05_需求文档/09-子系统-审计与通知中心.md @@ -0,0 +1,186 @@ + 1|# 子系统 09 — 审计与通知中心 (`audit`) v1.0 + 2| + 3|## 子系统概述 + 4| + 5|| 维度 | 说明 | + 6|| --- | --- | + 7|| 代号 | `audit` | + 8|| 核心职责 | 状态变更审计、敏感字段访问日志、多类型通知/告警 | + 9|| 数据所有权 | `interaction_audit_logs`, `notification_records`, `manual_review_tasks` | + 10|| 启动依赖 | 无硬依赖，完全独立 | + 11|| 外部系统依赖 | 通知可能通过 IM/EDM/APP Push 等通道（可复用 outreach 通道或独立） | + 12| + 13|--- + 14| + 15|## 1. 模块划分 + 16| + 17|``` + 18|┌─────────────────────────────────────────────────────────────┐ + 19|│ audit 子系统 │ + 20|│ │ + 21|│ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │ + 22|│ │ M1: 状态变更 │ │ M2: 敏感操作 │ │ M3: 通知分发 │ │ + 23|│ │ 审计 │ │ 审计 │ │ 引擎 │ │ + 24|│ └──────┬───────┘ └──────┬───────┘ └──────┬───────┘ │ + 25|│ │ │ │ │ + 26|│ ▼ ▼ ▼ │ + 27|│ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │ + 28|│ │ M4: 通知模板 │ │ M5: 人工复核 │ │ M6: 对外 API │ │ + 29|│ │ 管理 │ │ 任务 │ │ Gateway │ │ + 30|│ └──────────────┘ └──────────────┘ └──────────────┘ │ + 31|│ │ + 32|└─────────────────────────────────────────────────────────────┘ + 33|``` + 34| + 35|| # | 模块 | 职责 | + 36|| --- | --- | --- | + 37|| M1 | 状态变更审计 | 记录所有业务对象的状态流转（对象ID/旧状态/新状态/操作人/时间/原因） | + 38|| M2 | 敏感操作审计 | 敏感字段访问记录、数据导出记录、人工复核操作留痕 | + 39|| M3 | 通知分发引擎 | 按通知类型路由到不同通道（系统内通知/IM/EDM/APP Push）；通知优先级管理 | + 40|| M4 | 通知模板管理 | 各类通知的模板（额度预警/Listing 预警/超时提醒/审批通知/风险告警） | + 41|| M5 | 人工复核任务 | 管理需要人工复核的任务（弱关联风险/额度预警池/异常评价），供风险/运营人员消费 | + 42|| M6 | 对外 API Gateway | 接收所有子系统上报的审计事件和通知请求 | + 43| + 44|--- + 45| + 46|## 2. 各模块内外说明 + 47| + 48|### 2.1 M1: 状态变更审计 + 49| + 50|| 维度 | 说明 | + 51|| --- | --- | + 52|| **对内** | 接收所有子系统的状态变更事件（fire-and-forget）；记录：对象类型（plan/ticket/risk_case/review…）、对象ID、旧状态、新状态、操作人、操作时间、操作原因；审计日志不可篡改（append-only）；支持按对象ID/操作人/时间范围检索 | + 53|| **对外接口** | `POST /api/audit/event` — 上报审计事件 | + 54|| **数据写入** | `interaction_audit_logs` | + 55|| **典型事件** | 计划状态变更（草稿→审批→执行→完成）、工单分配/关闭、风险事件确认/排除、额度手动调整、审批决策 | + 56| + 57|### 2.2 M2: 敏感操作审计 + 58| + 59|| 维度 | 说明 | + 60|| --- | --- | + 61|| **对内** | 三类敏感操作：①敏感字段访问（用户上下文卡中的涉密字段→记录访问人/时间/字段/上下文）②数据导出操作（导出人/时间/范围/原因/是否含敏感字段）③人工复核操作（决策人/决策内容/决策依据/时间） | + 62|| **对外接口** | `POST /api/audit/sensitive-access` — 上报敏感访问 | + 63|| **数据写入** | `interaction_audit_logs`（带 sensitivity 标记） | + 64| + 65|### 2.3 M3: 通知分发引擎 + 66| + 67|| 维度 | 说明 | + 68|| --- | --- | + 69|| **对内** | 接收通知请求→按通知类型路由：①系统内通知（Web 前端轮询/WebSocket）②IM 通知（通过 outreach）③EDM 通知 ④APP Push；优先级管理（紧急 Listing 预警 > 超时提醒 > 额度预警）；通知去重（同一用户同一类型短时间内不重复发） | + 70|| **对外接口** | `POST /api/notifications/send` — 发送通知 | + 71|| **依赖** | outreach（IM/EDM/APP Push 通道） | + 72| + 73|### 2.4 M4: 通知模板管理 + 74| + 75|| 维度 | 说明 | + 76|| --- | --- | + 77|| **对内** | 通知类型与模板：①额度预警（「真实人 X 的测评额度仅剩 1 次」）②紧急 Listing 预警（「ASIN X 评分接近 4.2，建议紧急催评」）③客服超时提醒（「工单 #123 已超时 N 小时未回复」）④审批通知（「计划 X 等待您的审批」）⑤规则风控提醒（「ASIN X 频控过高」）⑥风险告警（「用户 X 命中强关联风险」） | + 78|| **对外接口** | 管理 API | + 79|| **数据写入** | `notification_records` | + 80|| **待确认** | 模板是否需要多语言（中文/英文/菲律宾语）？模板管理界面在 audit 内部还是独立？ | + 81| + 82|### 2.5 M5: 人工复核任务 + 83| + 84|| 维度 | 说明 | + 85|| --- | --- | + 86|| **对内** | 统一管理需人工复核的任务：弱关联风险复核、额度预警池复核、异常评价复核、诈骗疑似复核；任务分配/认领/完成/超时 | + 87|| **对外接口** | `POST /api/audit/review-task` — 创建复核任务；`GET /api/audit/review-tasks?assignee=` — 查询待复核任务 | + 88|| **数据写入** | `manual_review_tasks` | + 89| + 90|--- + 91| + 92|## 3. 对外 API 契约（草案） + 93| + 94|| 接口 | 方法 | 输入 | 输出 | 消费者 | + 95|| --- | --- | --- | --- | --- | + 96|| 上报审计事件 | `POST /api/audit/event` | `{object_type, object_id, old_status, new_status, operator, reason}` | `{event_id}` | 所有子系统（状态变更时调用） | + 97|| 上报敏感访问 | `POST /api/audit/sensitive-access` | `{operator, field, context, accessed_at}` | `{event_id}` | identity（上下文卡访问） | + 98|| 发送通知 | `POST /api/notifications/send` | `{recipient, type, template_id, params}` | `{notification_id}` | 所有子系统 | + 99|| 创建复核任务 | `POST /api/audit/review-task` | `{task_type, target_id, priority, description}` | `{task_id}` | risk, quota | + 100| + 101|--- + 102| + 103|## 4. 数据对象 + 104| + 105|| 对象 | 核心字段 | 说明 | + 106|| --- | --- | --- | + 107|| `interaction_audit_logs` | log_id, object_type, object_id, old_status, new_status, operator, operation, reason, sensitivity_level, logged_at | 审计日志（append-only） | + 108|| `notification_records` | notification_id, recipient, type, template_id, channel, sent_at, status(SENT/DELIVERED/READ/FAILED) | 通知记录 | + 109|| `manual_review_tasks` | task_id, task_type, target_id, status(PENDING/ASSIGNED/IN_REVIEW/RESOLVED/TIMEOUT), assignee, priority, created_at, resolved_at | 人工复核任务 | + 110| + 111|--- + 112| + 113|## 5. 业务澄清问题清单 — audit + 114| + 115|### 5.1 审计范围与保留（4 项） + 116| + 117|| # | 问题 | 优先级 | + 118|| --- | --- | --- | + 119|| A-01 | 审计日志的保留策略？（保留多久？1 年？永久？到期后归档还是删除？） | **P0** | + 120|| A-02 | 审计日志的存储量预估？（日产生多少条？是否需要分库分表/冷热分离？） | P1 | + 121|| A-03 | 审计日志是否需要支持导出/报表？（合规审计时需要导出给外部审计？） | P1 | + 122|| A-04 | 「敏感字段」的定义范围？（订单号、收款信息、设备号——还有哪些？谁来确定完整清单？） | **P0** | + 123| + 124|### 5.2 通知策略（4 项） + 125| + 126|| # | 问题 | 优先级 | + 127|| --- | --- | --- | + 128|| A-05 | 通知发送通道的优先级？（紧急告警用什么通道？IM？系统内通知？邮件？） | P1 | + 129|| A-06 | 通知去重规则？（同一用户同一类型通知 N 分钟内不重复发？） | P1 | + 130|| A-07 | 通知是否需要用户偏好设置？（用户可以选择不接收某类通知？公告类通知是否强制发送？） | P2 | + 131|| A-08 | 通知模板是否需要多语言支持？（中文/英文/菲律宾语？）模板由谁来维护？ | P2 | + 132| + 133|### 5.3 人工复核任务（2 项） + 134| + 135|| # | 问题 | 优先级 | + 136|| --- | --- | --- | + 137|| A-09 | 人工复核任务的时效要求？（不同任务类型 SLA？弱关联风险 N 小时内复核？额度预警池 N 分钟内复核？） | P1 | + 138|| A-10 | 复核任务超时后的升级机制？（自动分配给上级？通知主管？） | P2 | + 139| + 140|### 5.4 与其他子系统的协作（2 项） + 141| + 142|| # | 问题 | 优先级 | + 143|| --- | --- | --- | + 144|| A-11 | 通知通道是否完全复用 outreach？（IM/EDM/APP Push）还是 audit 独立对接通知通道？（如果 outreach 不可用，audit 仍需要能发告警） | P1 | + 145|| A-12 | 审计事件是同步上报还是异步？（同步→影响业务链路性能 / 异步→可能丢失事件） | P1 | + 146| +### 5.5 合规与认证（3 项） + +| # | 问题 | 优先级 | +| --- | --- | --- | +| A-13 | 系统是否需要通过合规认证？（SOC2 Type II / ISO 27001？）认证对审计日志的完整性、不可篡改性、保留期限有何具体要求？ | P1 | +| A-14 | 数据导出请求（DSR）——用户或监管机构要求导出所有个人数据时，系统如何响应？（需要哪些子系统的数据？导出格式？响应时限？） | P1 | +| A-15 | 审计日志是否需要对第三方审计开放？（外部审计师需要查看审计日志时——权限控制和数据脱敏？） | P2 | + +### 5.6 日志保留与归档（3 项） + +| # | 问题 | 优先级 | +| --- | --- | --- | +| A-16 | 审计日志的分级保留策略？（状态变更日志保留 X 年 / 敏感访问日志保留 Y 年 / 通知记录保留 Z 月？） | P1 | +| A-17 | 日志归档方案？（超过保留期的日志是删除还是归档到冷存储？归档后是否仍可检索？） | P2 | +| A-18 | 日志存储量预估？（日产生日志条数 × 保留天数 = 需要的存储空间——是否需要分库分表/分区？） | P2 | + +### 5.7 敏感数据脱敏（3 项） + +| # | 问题 | 优先级 | +| --- | --- | --- | +| A-19 | 审计日志中是否允许记录敏感字段的明文？（例如「谁在何时查看了用户 X 的收款信息」——收款信息是否脱敏存储？） | P1 | +| A-20 | 日志查询权限——谁可以查审计日志？（管理员？审计员？）是否需要限制只能查自己相关的日志？ | P1 | +| A-21 | 生产环境的日志是否可以包含 PII（个人可识别信息）？（邮箱/电话/地址——是否在写入日志时自动脱敏？） | P1 | + +### 5.8 通知可靠性（3 项） + +| # | 问题 | 优先级 | +| --- | --- | --- | +| A-22 | 通知的可靠性保证——紧急告警（如 Listing 评分暴跌）是否需要确保送达？（有送达确认机制吗？发送失败后重试？） | P1 | +| A-23 | 通知通道的优先级切换——IM 通知失败后是否自动切换到 EDM 或系统通知？ | P2 | +| A-24 | 通知的聚合/摘要——同一个用户短时间收到多条同类通知是否合并？（「您有 3 个待审批计划」而不是 3 条独立通知） | P2 | + +### 5.9 实施层面（4 项） + +| # | 问题 | 优先级 | +| --- | --- | --- | +| A-25 | 审计事件是同步写入还是异步写入？（同步→影响业务链路 RT / 异步→可能丢失事件——如何取舍？） | P1 | +| A-26 | 审计日志的查询性能——是否需要支持全文搜索？（按操作人/对象ID/时间范围检索是否需要在秒级返回？） | P2 | +| A-27 | 通知通道的可靠性——如果 audit 子系统本身宕机，其他子系统的通知请求是否丢失？（是否需要消息队列做缓冲？） | P1 | +| A-28 | audit 子系统是否需要独立的数据库？（与其他子系统共享数据库会在高峰期互相影响——是否独立部署数据库？） | P2 | diff --git a/wishfulfilled-wiki/05_需求文档/20260504_USER后台ERP_MVP管理员首页高保真原型_v7.html b/wishfulfilled-wiki/05_需求文档/20260504_USER后台ERP_MVP管理员首页高保真原型_v7.html new file mode 100644 index 0000000..4e9693f --- /dev/null +++ b/wishfulfilled-wiki/05_需求文档/20260504_USER后台ERP_MVP管理员首页高保真原型_v7.html @@ -0,0 +1,3298 @@ + + + + + + USER 后台 ERP MVP · 管理员总览原型 v7 + + + +
+ + +
+
+
+
+ 经营总览 + 系统管理员 · 最高权限 · 全部部门 +
+
+ 搜索 + +
+
+
+
+ + 至 + +
+
+ + + +
+ + + +
+
+ +
+
+
+ +
+ + + + + +
+ + + + diff --git a/wishfulfilled-wiki/05_需求文档/20260517_USER评价业务闭环_共用能力图与渠道专属流程_v2.2.md b/wishfulfilled-wiki/05_需求文档/20260517_USER评价业务闭环_共用能力图与渠道专属流程_v2.2.md new file mode 100644 index 0000000..eff73f2 --- /dev/null +++ b/wishfulfilled-wiki/05_需求文档/20260517_USER评价业务闭环_共用能力图与渠道专属流程_v2.2.md @@ -0,0 +1,995 @@ +# USER 评价业务闭环 — 共用能力图与渠道专属流程 v2.2 + +## 文件信息 + +- 文件名称：`20260517_USER评价业务闭环_共用能力图与渠道专属流程_v2.2.md` +- 项目路径：`C:\XCODE\USER` +- 当前版本：`v2.2` +- 最近更新：`2026-05-17` +- 上游基线：[工作基线 v1.2](20260517_USER评价业务闭环主流程与后续工作基线_v1.2.md) +- 前一版本： + - `20260517_USER评价业务闭环_共用能力图与渠道专属流程_v1.1.md` + - `20260517_USER评价业务闭环点击操作模拟_v2.1.md` +- 文件目的：在基线 v1.2 确认的额度规则和真实人体系上，拆出系统级共用能力图与 IM / EDM / APP / TEL / 客服 / KOC-KOL 六条渠道的专属执行流程，每个节点标注 查 / 写 / 状态 / 提醒 / 拦截。 +- 资料依据：IM 推送业务流脑图、电话业务流程知识库、客服相关模块、后台回评工作流对接事项、状态机 v4、页面设计 v4、原型 HTML。 +- 使用方式：先读基线 v1.2，再读本文件；第三步数据流设计直接引用本文件的节点规则表和数据对象建议。本文件取代 `v1.1` 与 `v2.1` 作为当前第二步主稿。 + +--- + +### 1. 总览 + +```mermaid +flowchart LR + A["销售 / ASIN数据形成"] --> B["需求触发"] + B --> C["用户运营评估"] + C --> D{"计划类型"} + D --> E["评价型计划
推新 / 回评"] + D --> F["免评计划"] + E --> G["执行拆解"] + F --> G + G --> SHARED["共用能力层"] + SHARED --> I1["IM"] + SHARED --> I2["EDM"] + SHARED --> I3["APP"] + SHARED --> I4["TEL"] + SHARED --> I5["客服"] + SHARED --> I6["KOC / KOL"] + I1 & I2 & I3 & I4 & I5 --> J["用户互动 / 服务 / 跟进"] + J --> K["用户真实提交评价"] + K --> L["计入累计评价额度（12）"] + L --> M["Amazon展示确认"] + M --> N["ASIN / 计划 / 用户 / 风险结果回流"] + I6 --> O["免评结果跟踪"] + O --> N + N --> C + + style SHARED fill:#f5f5f5,stroke:#333,stroke-width:3px +``` + +#### 节点审查标准 + +每个关键节点按以下 8 问审： + +| ## | 问题 | 标注 | +| --- | --- | --- | +| 1 | 入口是什么 | 触发条件 | +| 2 | 先查什么 | **查** | +| 3 | 判断什么 | 分岔条件 | +| 4 | 写什么 | **写** | +| 5 | 状态怎么变 | **状态** | +| 6 | 何时提醒 | **提醒** | +| 7 | 何时拦截 | **拦截** | +| 8 | 何时转人工 | **转人工** | + +--- + +## 第一部分：共用能力图 + +### 2. 共用能力一：真实人识别与用户上下文卡 + +#### 2.1 流程图 + +```mermaid +flowchart TB + A["新互动 / 新订单 / 新任务"] --> B["读取身份线索"] + B --> B1["JOYHUB ID"] + B --> B2["邮箱"] + B --> B3["电话"] + B --> B4["设备号"] + B --> B5["订单号"] + B --> B6["姓名 + 地址"] + + B1 & B2 & B3 & B4 & B5 & B6 --> C["归并真实人"] + C --> D{"匹配结果"} + D -->|"标准化姓名+地址一致"| E["强关联 → 同一真实人"] + D -->|"地址一致姓名不同"| F["家庭/关联风险 → 不直接合并"] + D -->|"多线索交叉"| G["按设备/电话/邮箱/收款信息权重合并"] + + E & F & G --> H["生成 / 更新真实人 ID"] + H --> I["拉取用户上下文卡"] + + I --> J["历史交易
订单/购买/退款/返款/ASIN"] + I --> K["历史服务
工单/聊天/电话/承诺/提醒"] + I --> L["历史风险
黑名单/诈骗/关联/异常"] + I --> M["当前设备
型号/版本/换机记录"] + I --> N["触达历史
IM/EDM/APP/TEL 近期记录"] + + J & K & L & M & N --> O["上下文卡快照 → 供客服/运营/风险使用"] +``` + +#### 2.2 用户上下文卡字段组 + +| 字段组 | 具体内容 | +| --- | --- | +| 当前身份 | JOYHUB ID、邮箱、电话、当前订单、真实人 ID | +| 真实人归并 | 姓名+地址（标准化）、设备号、电话、邮箱、Profile ID、收款信息、关联账号列表 | +| 历史交易 | 历史订单、购买频次、最近购买、历史退款、历史返款、目标 ASIN 购买记录 | +| 历史服务 | 历史工单、聊天记录、通话记录、已承诺事项、已发送提醒、工单关闭原因 | +| 历史风险 | 黑名单标记、强关联记录、弱关联记录、疑似诈骗、双重退款、异常订单 | +| 当前设备 | 设备号摘要、设备型号/类型、系统版本、APP 版本、最近设备变化（换机/多设备） | +| 触达历史 | IM 最近触达/回复/退订、EDM 最近打开/点击/退订、APP 最近 Push、TEL 最近拨打 | + +#### 2.3 节点规则 + +| 节点 | 查 | 写 | 状态 | 提醒 | 拦截 | +| --- | --- | --- | --- | --- | --- | +| 归并真实人 | JOYHUB、邮箱、电话、设备、订单、地址 | 真实人匹配结果、匹配证据、置信度 | 新真实人 / 已存在 | 标准化姓名+地址一致时强提示 | - | +| 拉取上下文卡 | 交易、工单、风险、设备、触达全量记录 | 上下文快照（含快照时间） | 首次生成 / 增量更新 | 命中黑名单/异常时高亮 | 严重风险标记时阻止自动通过 | +| 设备变化识别 | 设备号、型号、系统版本、APP版本 | 设备变化记录、变化时间 | 设备正常 / 近期换机 / 多设备 | 近期换机或同设备多账号提示 | - | + +--- + +### 3. 共用能力二：人群生成与画像拆解 + +#### 3.1 流程图 + +```mermaid +flowchart TB + A["计划进入人群生成"] --> B["基础过滤"] + B --> B1["硬排除：国家/站点/可达性/退订/黑名单/未关闭工单"] + + B1 --> C["画像匹配"] + C --> C1["基础画像：国家/语言/性别/年龄段/注册时间"] + C --> C2["产品关系：绑定玩具/绑定数量/绑定品类/目标产品"] + C --> C3["交易画像：历史订单/购买频次/是否买过目标ASIN"] + C --> C4["行为画像：活跃度/打开率/点击率/历史回评率/配合率"] + C --> C5["触达画像：各渠道可达性/最近触达/退订"] + C --> C6["风险画像：黑名单/设备关联/地址关联/退款异常"] + C --> C7["计划画像：是否参加过推新/回评/免评/最近结果"] + + C1 & C2 & C3 & C4 & C5 & C6 & C7 --> D["历史行为评分"] + + D --> E["额度与频控校验
（进入 §4 共用能力三）"] + E --> F["风险复检
（进入 §6 共用能力五）"] + F --> G["生成候选人群快照 + 排除快照"] +``` + +#### 3.2 画像字段的三类用途 + +| 类型 | 作用 | 示例字段 | +| --- | --- | --- | +| **硬过滤** | 决定能不能进池 | 国家、可达性、黑名单、退订、未关闭工单、额度超限 | +| **匹配条件** | 决定是否适合当前计划 | 绑定玩具、目标品类、年龄、性别、是否买过目标 ASIN | +| **排序权重** | 决定触达优先级 | 活跃度、历史回评率、历史配合率、最近互动时间 | + +#### 3.3 节点规则 + +| 节点 | 查 | 写 | 状态 | 提醒 | 拦截 | +| --- | --- | --- | --- | --- | --- | +| 基础过滤 | 国家、站点、可达性、退订、黑名单、未关闭工单 | 排除原因记录 | 入池 / 排除 | - | 黑名单/退订/强关联直接排除 | +| 画像匹配 | 7 组画像字段 | 匹配分组与得分 | 匹配 / 不匹配 / 待补全 | 画像缺失可补全 | - | +| 历史行为评分 | 活跃、点击、回复、回评率、配合率、投诉 | 评分结果、排序权重 | 高分 / 中分 / 低分 | 低活跃用户降级提醒 | - | +| 生成快照 | 过滤、匹配、评分、额度、风险全量结果 | 人群快照、排除快照、快照时间 | 已生成 | 排除比例异常时提醒 | 快照为空时拦截 | + +--- + +### 4. 共用能力三：额度台账与频控控制 + +#### 4.1 已确认额度规则 + +| 规则 | 统计对象 | 计数口径 | 计数时点 | +| --- | --- | --- | --- | +| 每月测评最多 4 次 | 真实人 | 已完成 + 进行中 + 已预占 | - | +| 每月免评最多 4 次 | 真实人 | 已完成 + 进行中 + 已预占 | - | +| 累计真实提交评价最多 12 个 | 真实人 | 用户真实提交评价后立即计数 | 用户真实提交评价时 | + +#### 4.2 流程图 + +```mermaid +flowchart TB + A["识别真实人"] --> B["读取额度台账"] + B --> B1["本月测评：已完成 / 进行中 / 已预占"] + B --> B2["本月免评：已完成 / 进行中 / 已预占"] + B --> B3["累计真实提交：当前 / 上限 12"] + B --> B4["并发占用：跨计划重复入选检测"] + + B1 & B2 & B3 & B4 --> C{"额度判断"} + C -->|"剩余 ≥ 本次拟发送"| D["进入普通候选池
→ 预占额度"] + C -->|"剩余不足但 > 0"| E["进入预警池
→ 预占额度 → 发送前人工复核"] + C -->|"已用 + 预占 + 本次 ≥ 上限"| F["排除自动推送"] + + D --> G["写入预占记录"] + E --> G + + G --> H["频控复核"] + H --> H1["渠道频控：IM/EDM/APP/TEL 最近触达间隔"] + H --> H2["单 ASIN 短期触达次数"] + H --> H3["用户反感度/投诉/退订状态"] + + H1 & H2 & H3 --> I{"频控判断"} + I -->|通过| J["进入发送队列"] + I -->|不通过| K["延后 / 降频 / 排除"] + + J --> L["发送前再次读取最新额度 + 风险"] + L --> M{"最终校验"} + M -->|通过| N["发送"] + M -->|新增超限/风险| O["撤出本批次"] +``` + +#### 4.3 额度 vs 频控的区别 + +| 类别 | 统计维度 | 周期 | 拦截时机 | +| --- | --- | --- | --- | +| **渠道频控** | 单渠道触达次数/间隔 | 按日/周/月 | 发送前 | +| **月度业务额度** | 真实人测评 4 / 免评 4 | 自然月 | 人群生成 + 发送前 | +| **累计评价额度** | 真实人累计 12 | 永久累计 | 用户提交评价时更新、下次人群生成时判断 | +| **并发占用控制** | 进行中 + 已预占 + 跨计划重复 | 实时 | 人群生成 + 预占时 | + +#### 4.4 节点规则 + +| 节点 | 查 | 写 | 状态 | 提醒 | 拦截 | +| --- | --- | --- | --- | --- | --- | +| 读取额度台账 | 本月测评/免评、累计提交、进行中、已预占 | 当前额度快照 | - | 剩余 ≤ 1 或本批次将打满时预警 | - | +| 预占额度 | 候选计划、预计发送量、当前剩余 | 额度预占记录 | 已预占 | - | 预计超限阻止进入自动发送 | +| 频控复核 | IM/EDM/APP/TEL 最近触达、ASIN频次、退订/投诉 | 频控校验结果 | 通过 / 降频 / 排除 | 接近频控上限时提醒 | 超频直接排除 | +| 发送前终校 | 最新额度、最新风险、最新未关闭工单 | 发送前校验结果 | 准入 / 撤出 | 任何新增异常立即提示 | 新增超限/风险撤出本批次 | + +--- + +### 5. 共用能力四：每次有效互动复检 + +#### 5.1 流程图 + +```mermaid +flowchart TB + A["触发复检的事件"] --> A1["主动推送后回复"] + A --> A2["再次联系"] + A --> A3["补充订单号"] + A --> A4["客服回访"] + A --> A5["电话来电"] + A --> A6["退款/返款/继续推送前"] + + A1 & A2 & A3 & A4 & A5 & A6 --> X["重新读取四组数据"] + + X --> X1["身份：真实人/JOYHUB/邮箱/电话/设备/订单/地址"] + X --> X2["历史：订单/工单/触达/退款/返款"] + X --> X3["额度：本月测评/免评/累计提交/进行中/预占"] + X --> X4["风险：黑名单/强弱关联/双重退款/异常订单"] + + X1 & X2 & X3 & X4 --> Y{"判断结果"} + Y -->|正常 + 额度充足| Z["继续业务"] + Y -->|弱风险 / 接近额度上限| W["继续但显著提示 → 人工关注"] + Y -->|强风险 / 额度超限| V["暂停当前动作 → 转风险中心或人工复核"] +``` + +#### 5.2 节点规则 + +| 节点 | 查 | 写 | 状态 | 提醒 | 拦截 | +| --- | --- | --- | --- | --- | --- | +| 身份复检 | JOYHUB、邮箱、电话、设备、订单、地址是否变化 | 身份变化记录 | 未变 / 新增关联 / 冲突 | 设备变化/地址变化提示 | - | +| 历史复检 | 是否有新订单、新工单、新触达、新退款 | 历史变化记录 | 无变化 / 有更新 | 新退款/新工单提示 | - | +| 额度复检 | 最新测评/免评/累计额度 | 最新额度快照 | 充足 / 预警 / 超限 | 接近上限预警 | 超限拦截 | +| 风险复检 | 黑名单、强弱关联、双重退款、异常 | 最新风险结果 | 正常 / 弱风险 / 强风险 | 任何命中高亮提醒 | 强关联暂停自动操作 | + +--- + +### 6. 共用能力五：风险判断与黑名单 + +#### 6.1 风险分层 + +| 风险类型 | 关联项 | 处理原则 | +| --- | --- | --- | +| **强关联** | 邮箱、设备号、电话、收件人姓名+地址、订单号、聊天记录、Profile ID、收款信息 | 一旦命中，直接进入高风险或黑名单链路 | +| **弱关联** | IP 单独命中、姓名单独命中、同址异名 | 进入高风险观察 + 人工复核，不直接认定诈骗 | + +#### 6.2 流程图 + +```mermaid +flowchart TB + A["风险信号进入
（新订单同步/触达回应/用户接入/退款申请/再次跟进）"] --> B["强弱关联判断"] + + B --> C{"关联等级"} + C -->|强关联| D["高风险 / 黑名单链路"] + C -->|弱关联| E["高风险观察 + 人工复核"] + C -->|无关联| F["正常继续"] + + D --> D1["拦截继续推送"] + D --> D2["拦截自动退款"] + D --> D3["拦截自动放行"] + D1 & D2 & D3 --> G["回写工单 / 推送 / 计划状态"] + G --> H["提醒客服 / 用户运营 / 审核人员"] + + E --> E1["显著风险提醒"] + E1 --> E2["人工复核"] + E2 --> E3{"复核结论"} + E3 -->|确认风险| D + E3 -->|排除风险| F +``` + +#### 6.3 已确认业务问题 + +1. **双重退款**：APP/OA 已退款 + 用户又向 Amazon 申请退款 → 需要 Amazon 退款与 OA 返款自动比对 +2. **高风险用户**：一旦标记，支付/返款需要人工复核 +3. **风险可见性**：客服、审核、退款等环节必须都能看到风险提醒 +4. **非 APP 用户盲区**：直接走邮件退款，缺设备/注册邮箱等维度，识别能力下降 +5. **每次互动重判**：风险判断不是一次性的，每次有效互动都要重新执行 + +#### 6.4 节点规则 + +| 节点 | 查 | 写 | 状态 | 提醒 | 拦截 | +| --- | --- | --- | --- | --- | --- | +| 强弱关联判断 | 邮箱/设备/电话/地址/订单/ProfileID/收款信息/IP | 关联结果、命中维度列表 | 强关联 / 弱关联 / 无 | 命中时高亮命中维度 | - | +| 高风险链路 | 当前推送/退款/返款状态 | 风险事件、拦截记录 | 已拦截 / 待复核 | 通知所有关联环节 | 拦截继续推送/自动退款/自动放行 | +| 双重退款检测 | Amazon退款记录 + OA返款记录 | 匹配结果、差异 | 无重复 / 疑似重复 / 确认重复 | 确认重复时强告警 | 确认重复时阻止后续返款 | + +--- + +### 7. 共用能力六：审批工作流 + +```mermaid +flowchart LR + PLAN["计划草案"] --> R1{"计划类型"} + R1 -->|测评计划| A1["Amazon运营总监审批"] + R1 -->|回评计划| A2["Amazon运营总监或指定负责人"] + R1 -->|免评计划| A3["Amazon运营总监 + 用户负责人"] + R1 -->|紧急计划| A4["Amazon运营负责人 + 用户负责人 + 主管"] + + A1 & A2 & A3 & A4 --> NEXT["周/月推送计划"] + NEXT --> N1["用户负责人审批"] + N1 --> N2["渠道负责人审批"] + N2 --> APPROVED["已批准 → 执行"] +``` + +#### 7.1 审批节点规则 + +| 节点 | 查 | 写 | 状态 | 提醒 | 拦截 | +| --- | --- | --- | --- | --- | --- | +| Amazon运营总监审批 | 计划详情、ASIN健康、风险提醒 | 审批结果、审批意见 | 通过 / 驳回 / 待补充 | 驳回时通知提交人 | - | +| 用户负责人审批 | 人群快照、额度占用、频控结果 | 审批结果 | 通过 / 驳回 | 额度接近上限时预警 | - | +| 渠道负责人审批 | 渠道容量、素材、合规 | 审批结果 | 通过 / 驳回 | 素材/文案风险提醒 | 合规风险时拦截 | + +--- + +### 8. 共用能力七：审计与通知中心 + +| 模块 | 职责 | 关键记录内容 | +| --- | --- | --- | +| 状态变更审计 | 所有业务对象的状态流转留痕 | 对象ID、旧状态、新状态、操作人、时间、原因 | +| 敏感字段访问 | 涉密字段的每次读取记录 | 访问人、访问时间、访问字段、访问上下文 | +| 导出操作 | 所有数据导出行为留痕 | 导出人、时间、范围、原因、是否含敏感字段 | +| 人工复核操作 | 所有人工干预决策留痕 | 决策人、决策内容、决策依据、决策时间 | +| **规则风控提醒** | 触发规则/审核/风控阈值时通知 | 同一ASIN频控过高、同一用户多次推送、设备/邮箱异常、站点任务过密 | +| **紧急Listing预警** | 评分接近4.2时通知 | ASIN、当前评分、差评摘要、建议动作 | +| **客服超时提醒** | 工单/答应配合超时通知 | 工单ID、超时类型、超时时长、责任人 | +| **额度预警** | 额度接近上限时通知 | 真实人、额度类型、已用/上限、受影响计划 | + +--- + +## 第二部分：渠道专属流程图 + +### 9. 渠道一：IM 推送专属流程 + +#### 9.1 用户分层与推送策略 + +```mermaid +flowchart TB + U["用户注册 + 绑定玩具"] --> L1{"识别用户分层"} + + L1 -->|"A 未参与过
从未走过回评/测评"| A1["推送前校验"] + A1 --> A1a["查：JOYHUB ID、设备ID、黑名单、绑定产品"] + A1 --> A1b{"设备ID在黑名单？"} + A1b -->|是| A2["写：打标'长期测评人'
拦截：不推回评/测评卡片
推送：免评产品卡片"] + A1b -->|否| A3["推送：对应绑定产品的回评卡片
写：推送记录"] + + L1 -->|"B 已参与过
真实人累计真实提交评价 < 12"| B1["优先催评"] + B1 --> B1a["查：未回评测评单、真实人累计评价数、标签"] + B1 --> B1b["推送：催评卡片/消息"] + B1b --> B2{"完成好评提交？"} + B2 -->|是| B3["写：重新计算真实人累计评价数"] + B3 --> B4{"累计真实提交评价仍 < 12？"} + B4 -->|是| B5["推送：当日测评计划对应卡片
写：二次转化记录"] + B4 -->|否| B6["写：打标'长期测评人'→ 推送免评产品"] + + L1 -->|"C 长期测评人
真实人累计真实提交评价 ≥ 12"| C1["拦截：不推送普通回评/测评卡片
推送：当日免评补单产品
写：免评推送记录"] + + style A2 fill:#fce4ec + style C1 fill:#fff3e0 +``` + +#### 9.2 IM 用户提交后的核验与流转 + +```mermaid +flowchart TB + SUBMIT["入口：用户在IM中提交回评/测评信息"] --> ITEMS["提交内容：订单号 + 返款账号 + 评论截图/链接"] + + ITEMS --> AUTO["查：当前用户标签、关联计划
写：系统自动登记提交记录
状态：待核验"] + + AUTO --> VERIFY["订单号核实"] + VERIFY --> V1{"查：是否测评单？"} + VERIFY --> V2{"查：是否为公司产品？"} + VERIFY --> V3{"查：单号格式 xxx-xxxxxxx-xxxxxxx？"} + + V1 & V2 & V3 -->|全部通过| PASS["写：登记进系统
状态：已登记"] + V1 & V2 & V3 -->|任一不通过| CS["转人工：推送客服
状态：待客服处理"] + + CS --> CS1["客服沟通用户 → 补充/修正信息"] + CS1 --> CS2["写：修正记录 → 回到核验"] + + PASS --> CHECK{"信息完整？"} + CHECK -->|完整| FINANCE["写：推送财务返款提醒
状态：待返款"] + CHECK -->|缺返款账号| TAG1["写：打标'xx产品待返款'
提醒：自动通知用户补充
状态：信息待补全"] + CHECK -->|缺评论截图/链接| TAG2["写：打标'xx产品待回评'
提醒：自动通知用户补充
状态：信息待补全"] + + FINANCE --> PAY["查：付款凭证
写：自动推送返款/礼品卡通知
状态：已返款"] + PAY --> DONE["状态：回评流程走完"] + DONE --> TAG3["写：打标'xx产品已回评用户'
推送：测评卡片（二次转化）"] + + style SUBMIT fill:#e8f5e9 + style PASS fill:#c8e6c9 + style CS fill:#fff3e0 + style DONE fill:#e3f2fd +``` + +#### 9.3 IM 新测评流程 + +```mermaid +flowchart TB + START["入口：用户收到测评卡片 → 提交测评信息"] --> VFY["查：订单号是否撤销、是否退款
查：真实人月度测评额度与累计真实提交评价"] + + VFY -->|"额度允许 + 订单有效"| REG["写：登记进系统
写：打标'xx产品测评单登记'
状态：已登记"] + + REG --> INFO{"信息完整？"} + INFO -->|只有订单号
缺返款账号+截图| TAG_A["写：打标'xx产品测评待返款'
提醒：自动通知用户
状态：待补全"] + INFO -->|只有截图+链接
缺订单号+返款账号| TAG_B["写：打标'xx产品测评单待回评'
提醒：自动通知用户
状态：待补全"] + INFO -->|完整| COMP["状态：测评流程走完"] + + COMP --> RECALC["查：重新计算 review 数量
写：review 数量更新"] + RECALC -->|"累计真实提交评价 ≥ 12"| LC["写：打标'长期测评人'
推送：免评产品卡片"] + RECALC -->|"≤ 12 review"| NEXT["推送：当日测评计划对应卡片
写：二次转化记录"] + + style COMP fill:#c8e6c9 + style LC fill:#fff3e0 +``` + +#### 9.4 IM 核心标签汇总 + +| 分类 | 标签 | 触发时机 | 后续动作 | +| --- | --- | --- | --- | +| **用户层级** | 未参与过用户 (A) | 注册+绑定后首次识别 | 推送回评卡片 | +| | 参与过用户 (B) | 已有回评/测评记录，review < 12 | 优先催评 → 二次转化 | +| | 长期测评人 (C) | review > 12 | 仅推送免评产品 | +| **回评流程** | xx产品已回评用户 | 回评流程走完 | 推送测评卡片 | +| | xx产品待回评用户 | 缺截图/链接 | 自动通知补全 | +| | xx产品待返款 | 缺返款账号 | 自动通知补全 | +| **测评流程** | xx产品测评单登记 | 订单核实通过 | 继续信息补全 | +| | xx产品测评待返款用户 | 测评缺返款 | 自动通知补全 | +| | xx产品测评单待回评 | 测评缺截图 | 自动通知补全 | +| | xx产品测评单 | 测评流程走完 | review重算 | +| **免评流程** | xx产品的免评 | 长期测评人参与免评单 | 不再推回评/测评 | + +#### 9.5 IM 推送动作与流转动作 + +| 动作类型 | 动作 | 说明 | +| --- | --- | --- | +| **推送** | 回评卡片 | A类用户首次推送 | +| | 测评卡片 | B类二次转化 / A类设备在黑名单 | +| | 免评产品卡片 | C类用户 / 黑名单命中用户 | +| | 催评消息 | B类优先催评 / 紧急催评 | +| | 返款/礼品卡通知 | 财务有凭证后推送 | +| **流转** | 推送客服 | 订单号不符合 / 异常 | +| | 推送财务 | 订单登记完成后 | +| | 自动打标 | 各流程节点完成时 | +| | 二次转化 | 回评完成 → 推送测评卡片 | + +--- + +### 10. 渠道二：EDM 邮件推送专属流程 + +#### 10.1 流程图 + +```mermaid +flowchart TB + START["入口：计划已批准，进入EDM执行拆解"] --> POOL["筛选EDM目标用户池"] + + POOL --> COND{"查：用户条件"} + COND -->|"非APP用户"| NON["进入EDM队列"] + COND -->|"APP低活跃"| LOW["查：IM频控通过后进入EDM队列"] + COND -->|"APP活跃"| SKIP["拦截：跳过EDM，走IM/APP"] + + NON --> PRECHK["推送前检查"] + LOW --> PRECHK + + PRECHK --> C1["查：身份——是否有有效邮箱"] + PRECHK --> C2["查：风险——邮箱是否命中黑名单"] + PRECHK --> C3["查：退订——是否已退订/硬退信"] + PRECHK --> C4["查：资格——OA是否有资格"] + PRECHK --> C5["查：国家——站点与邮箱类型匹配"] + + C1 & C2 & C3 & C4 & C5 -->|全部通过| BEHAVIOR["行为筛选"] + C1 & C2 & C3 & C4 & C5 -->|任一不通过| EXCLUDE["写：排除原因
拦截：不发送"] + + BEHAVIOR --> B1["查：最近打开时间、总打开次数"] + BEHAVIOR --> B2["查：最近3/5次是否连续0打开"] + BEHAVIOR --> B3["查：最近回复时间、回复后又发送数"] + BEHAVIOR --> B4["查：是否点击评论链接但未回复"] + BEHAVIOR --> B5["查：单月收信次数、各邮件类型发送次数"] + + B1 & B2 & B3 & B4 & B5 --> RHYTHM{"节奏判断"} + RHYTHM -->|适合触达| SEND["发送EDM
写：发送记录
状态：已发送"] + RHYTHM -->|需降频| DELAY["写：延后标记
状态：观察中"] + RHYTHM -->|不适合| SWITCH["切换其他渠道或排除"] + + SEND --> TRACK["追踪回收"] + TRACK --> T1["送达 → 写：送达时间"] + T1 --> T2["打开 → 写：打开时间、打开次数+1"] + T2 --> T3["点击 → 写：点击时间、点击目标"] + T3 --> T4["跳转至APP下载页/产品页"] + T4 --> RESULT{"用户行为"} + RESULT -->|"下载并注册APP"| TO_IM["写：用户渠道升级
后续走IM主流程"] + RESULT -->|"直接回复邮件"| TO_CS["写：生成客服工单
走客服执行流程"] + RESULT -->|"未响应"| RETRY["写：进入再触达队列
（遵循频控间隔）"] + RESULT -->|"退订"| UNSUB["写：退订标记
拦截：该渠道永久排除"] + + SEND --> METRICS["写：EDM指标
发送数/送达率/打开率/点击率/回复率/转化数/退订数"] + + style EXCLUDE fill:#fce4ec + style UNSUB fill:#fce4ec + style TO_IM fill:#e3f2fd + style TO_CS fill:#fff3e0 +``` + +#### 10.2 EDM 专属行为指标 + +| 字段组 | 具体指标 | 用途 | +| --- | --- | --- | +| **打开行为** | 最近打开时间、总打开次数、最近3/5次0打开 | 判断活跃度 → 决定是否继续发 | +| **回复行为** | 最近回复时间、回复后又发送封数 | 判断兴趣度 → 决定触达节奏 | +| **点击行为** | 是否点击评论链接、点击后未回复时长 | 判断意向 → 决定是否追加触达 | +| **触达频率** | 单月收信次数、各邮件类型发送次数 | 频控 → 防止疲劳 | +| **邮件属性** | 邮件类型、邮箱后缀标签、国家站点 | 匹配 → 确定发送内容 | +| **排除项** | 风险用户、黑名单、退订、硬退信、OA无资格 | 硬过滤 → 不进池 | + +#### 10.3 EDM vs IM 关键差异 + +| 维度 | IM | EDM | +| --- | --- | --- | +| 用户身份强度 | 强（JOYHUB ID + 设备 + 订单绑定） | 弱（仅邮箱，可能无JOYHUB ID） | +| 风险识别能力 | 高（多维度交叉） | 低（缺设备/注册邮箱等维度） | +| 转化路径 | 直接提交 → 核验 → 返款 | 引导注册APP → 再进入IM链路 | +| 退订机制 | 社区屏蔽/消息免打扰 | 邮件退订链接 + 硬退信 | +| 频控周期 | 按日/按类目 | 按周/按月 | +| 行为信号 | 绑定/活跃/点击/回复/标签 | 打开/点击/回复/退订/连续0打开 | + +--- + +### 11. 渠道三：APP Push 专属流程 + +#### 11.1 流程图 + +```mermaid +flowchart TB + START["触发源"] --> T1["用户绑定新玩具"] + START --> T2["用户长期未活跃（7天+）"] + START --> T3["测评/回评计划到期"] + START --> T4["Listing健康紧急"] + START --> T5["活动/促销通知"] + + T1 & T2 & T3 & T4 & T5 --> FILTER["查：共用能力过滤"] + + FILTER --> F1["查：身份——JOYHUB ID + 设备在线"] + FILTER --> F2["查：风险——黑名单 + 关联检测"] + FILTER --> F3["查：频控——当日Push次数 + 用户通知设置"] + FILTER --> F4["查：标签——匹配推送策略"] + + F1 & F2 & F3 & F4 -->|通过| PUSH["发送APP Push
写：推送记录
状态：已发送"] + F1 & F2 & F3 & F4 -->|不通过| SKIP["写：跳过原因
状态：已跳过"] + + PUSH --> USER{"用户响应"} + USER -->|"点击打开"| IN_APP["进入APP → 落地页"] + USER -->|"忽略/关闭"| NOOP["写：曝光记录
拦截：短期内不重复推"] + USER -->|"卸载/禁用通知"| UNINSTALL["写：不可再推送标记
降级：转入EDM候选池"] + + IN_APP --> ACT{"APP内动作"} + ACT -->|"提交回评/测评"| IM_FLOW["走IM提交核验流程（§9.2）"] + ACT -->|"联系客服"| CS_FLOW["生成客服工单（§12）"] + ACT -->|"仅浏览"| TAG["写：记录行为，更新活跃标签"] + + style IN_APP fill:#e3f2fd + style UNINSTALL fill:#fce4ec +``` + +#### 11.2 APP Push 与 IM 的分工 + +| 场景 | 用 APP Push | 用 IM | +| --- | --- | --- | +| 新绑定玩具 → 引导测评 | - | 推送回评/测评卡片 | +| 用户7天未活跃 | 推送召回通知 | - | +| 测评计划到期提醒 | - | 推送催评消息 | +| Listing 紧急 | 推送紧急通知 | 推送紧急催评卡片 | +| 返款已到账 | 推送到账通知 | - | +| 活动/促销 | 推送活动通知 | - | + +#### 11.3 APP 必查字段 + +| 字段组 | 内容 | +| --- | --- | +| 用户资料 | 注册邮箱、JOYHUB ID、国家、语言 | +| 设备上下文 | 设备号、设备型号/类型、APP版本、系统版本 | +| 产品关系 | 绑定玩具、绑定时间、目标产品关系 | +| 行为数据 | 活跃、打开、点击、回复、站内浏览、广告互动 | + +--- + +### 12. 渠道四：TEL 电话专属流程 + +#### 12.1 流程图 + +```mermaid +flowchart TB + START["触发电话任务"] --> S1["用户答应配合但超时未提交"] + START --> S2["高价值用户需深度跟进"] + START --> S3["复杂售后无法文字解决"] + START --> S4["IM/EDM多次触达无响应"] + START --> S5["紧急Listing需人工沟通"] + START --> S6["Amazon页面/说明书来电"] + START --> S7["计划生成的外呼任务"] + + S1 & S2 & S3 & S4 & S5 & S6 & S7 --> TICKET["写：生成电话类客服工单
状态：待分配"] + + TICKET --> PREPARE["拨打前准备（必须）"] + PREPARE --> P1["查：用户完整画像
（身份/订单/历史/标签/风险）"] + PREPARE --> P2["查：风险状态
拦截：强关联命中 → 暂停拨打 → 先复核"] + PREPARE --> P3["查：历史沟通记录
（避免重复询问）"] + PREPARE --> P4["写：准备话术和问题清单"] + + P1 & P2 & P3 & P4 --> CONTACT["客服电话联系用户
写：拨打记录
状态：处理中"] + + CONTACT --> RESULT{"通话结果"} + RESULT -->|"接通-售后问题"| AFTERSALE["先解决售后
查：订单/产品/凭证
写：处理方案
状态：售后处理中"] + RESULT -->|"接通-直接配合"| COOP["确认评价提交时间
写：登记答应配合
状态：答应配合"] + RESULT -->|"接通-拒绝"| REJECT["写：记录拒绝原因
状态：已关闭"] + RESULT -->|"接通-疑似诈骗"| FRAUD["创建诈骗事件
写：诈骗记录
转风险链路（§6）"] + RESULT -->|"未接通"| RETRY["写：拨打次数+1
提醒：安排重试"] + + AFTERSALE --> SAT{"是否解决/满意？"} + SAT -->|是| INVITE["引导回评/邀请测评"] + SAT -->|否| ESCALATE["升级处理 → 转组长/负责人"] + + INVITE --> FOLLOW["写：进入答应配合跟进
状态：待提醒"] + COOP --> FOLLOW + FOLLOW --> UPDATE["写：更新工单 + 用户标签"] + + RETRY --> DECIDE{"重试策略"} + DECIDE -->|"< 3次"| CONTACT + DECIDE -->|"≥ 3次未接通"| DOWNGRADE["写：降级至EDM/放弃
状态：待关闭"] + + CONTACT --> RECORD["写：通话记录
来电时间/来源/联系方式/订单号
问题类型/描述/处理方案
是否解决/是否邀请测评/用户是否接受"] + + style CONTACT fill:#fff3e0,stroke:#ef6c00 + style FRAUD fill:#fce4ec,stroke:#c62828 + style AFTERSALE fill:#e3f2fd +``` + +#### 12.2 TEL 必填记录字段 + +| 类别 | 字段 | 涉密 | +| --- | --- | --- | +| 来电基础 | 来电时间、来源（Amazon页/说明书/外呼）、客服、联系方式 | - | +| 订单信息 | Amazon订单号、产品型号/款式/颜色、购买时间 | 订单号涉密 | +| 问题信息 | 问题类型、问题描述、图片/视频凭证 | - | +| 处理信息 | 处理方案、是否解决、是否需要后续跟进 | - | +| 评价相关 | 是否邀请回评/测评、用户是否接受、是否涉及差评 | - | +| 拨打统计 | 拨打次数、通话时长、接通状态 | - | + +--- + +### 13. 渠道五：客服工单执行流程 + +#### 13.1 流程图 + +```mermaid +flowchart TB + A["入口：用户消息 / 推送转人工 / 电话后续 / 风险触发"] --> B["写：生成工单
状态：待分配"] + + B --> C["查：班次、在线状态、当前负载、最大工单数
写：自动分配到客服组
状态：已分配"] + + C --> D["客服组长分派到组员
状态：处理中"] + + D --> E["查：展示用户上下文卡
（身份/历史/风险/设备/触达）"] + + E --> F["客服开始处理"] + + F --> G{"处理结果"} + G -->|"等待用户回复"| H["状态：等待用户
提醒：超时提醒机制"] + G -->|"等待内部协同"| I["状态：等待内部
提醒：超时升级"] + G -->|"用户答应配合"| J["写：生成跟进任务
状态：答应配合
进入答应配合状态机"] + G -->|"疑似诈骗"| K["写：诈骗疑似标记
提醒：组长/负责人复核
转风险链路（§6）"] + G -->|"问题已解决"| L["写：解决记录
状态：已解决"] + + H --> F + I --> F + + J --> M["提醒/再联系/等待提交"] + M --> N["用户提交评价或反馈
状态：已提交评价/已提交反馈"] + + K --> P["组长/负责人复核"] + P --> Q{"复核结论"} + Q -->|确认诈骗| R["转风险链路 → 同步黑名单"] + Q -->|退回继续处理| F + + L --> S["写：关闭工单
状态：已关闭"] +``` + +#### 13.2 三套并行状态 + +| 状态体系 | 典型状态 | 说明 | +| --- | --- | --- | +| **工单状态** | 待分配 → 已分配 → 处理中 → 等待用户/等待内部 → 已解决 / 疑似诈骗 → 已关闭 | 工单生命周期 | +| **答应配合状态** | 已答应配合 → 待分配负责人 → 待提醒 → 等待提交 → 已提交评价/已提交反馈 → 超时 → 需再次联系 → 已关闭 | 防止承诺用户流失 | +| **风险状态** | 无异常 → 弱关联高风险 → 强关联高风险 → 疑似诈骗 → 已确认诈骗 → 已同步黑名单 | 风险独立跟踪 | + +--- + +### 14. 客服管理支撑流程 + +#### 14.1 流程图 + +```mermaid +flowchart LR + A["排班设置"] --> B["在线客服池"] + C["出勤记录"] --> B + B --> D["工单自动分配
查：在线状态/排班/当前负载/最大工单数"] + D --> E["回复效率统计"] + D --> F["转化统计"] + F --> G["目标完成统计"] + E --> H["主管看板"] + F --> H + G --> H +``` + +#### 14.2 管理指标 + +| 模块 | 指标 | +| --- | --- | +| **出勤** | 应出勤、实际出勤、出勤率、迟到、早退、请假、缺勤 | +| **回复效率** | 回复用户数、处理工单数、发送消息数、首次回复时长（平均/中位数/最大/最小） | +| **转化** | RSO回评登记订单数、RDO测评登记订单数、获取评价数、评价完成率 | +| **目标** | 月目标、当前完成、完成率、历史趋势 | + +--- + +### 15. 评价完成流程 + +#### 15.1 流程图 + +```mermaid +flowchart TB + A["用户提交评价"] --> B["写：记录真实提交事实
状态：已提交待核验"] + B --> C["写：更新真实人累计评价额度（+1）
提醒：接近12时预警"] + + C --> D{"查：Amazon是否展示 / 是否可核验"} + D -->|"展示或可核验"| E["写：计入计划完成
状态：已确认展示"] + D -->|"未展示 / 暂不可核验"| F["写：保留已提交事实
状态：未展示待观察"] + + E --> G["写：更新ASIN健康与计划完成度"] + F --> H["进入异常观察队列
提醒：定期复查"] + + G --> I["结果回流：更新经营层数据"] +``` + +#### 15.2 必须拆开的两个事实 + +| 事实 | 是否计入累计12额度 | 是否计入计划完成 | 计数时点 | +| --- | --- | --- | --- | +| 用户真实提交评价 | **是** | 还不一定 | 提交时立即计数 | +| Amazon 展示确认 | 已在上一步计过 | **是** | 展示确认时 | + +--- + +### 16. 渠道六：KOC/KOL 协作专属流程（免评核心通道） + +#### 16.1 流程图 + +```mermaid +flowchart TB + START["入口：免评计划 / 推新计划已批准"] --> PLAN["查：计划参数
写：拆解KOC/KOL执行方案"] + + PLAN --> STEP1["匹配合作对象"] + STEP1 --> S1A["查：按国家/平台/粉丝量/历史效果筛选"] + STEP1 --> S1B["查：按产品类目匹配KOC/KOL专长"] + STEP1 --> S1C["查：合作对象风险（历史纠纷/违约）
提醒：有风险记录时提示"] + + S1A & S1B & S1C --> STEP2["写：分配Code/素材/内容Brief"] + STEP2 --> STEP3["KOC/KOL内容发布"] + + STEP3 --> TRACK["跟踪执行结果"] + TRACK --> T1["查：内容发布链接"] + TRACK --> T2["查：点击/跳转数据"] + TRACK --> T3["查：Code使用量"] + TRACK --> T4["查：带货订单"] + TRACK --> T5["查：转化销量"] + TRACK --> T6["查：Listing权重变化"] + + T1 & T2 & T3 & T4 & T5 & T6 --> SYNC["从JOYCOLLAB同步数据至USER
写：同步记录
提醒：同步失败时告警"] + + SYNC --> EVAL{"执行评估"} + EVAL -->|"达标"| DONE["写：结果回流
更新ASIN健康/计划完成度
状态：已完成"] + EVAL -->|"未达标"| ADJUST["调整策略
写：调整记录
更换KOC/调整素材/追加Code"] + + SYNC --> FINANCE["财务侧
查：提成计算/返点核算/提款记录
提醒：财务数据独立权限"] +``` + +#### 16.2 KOC/KOL 与评价型渠道的本质差异 + +| 维度 | 评价型（IM/EDM/APP/TEL） | KOC/KOL | +| --- | --- | --- | +| 执行主体 | 系统 + 客服 | 外部KOC/KOL + 运营协同 | +| 终点 | 用户提交评价 | 内容发布/Code使用/带货销量/权重 | +| 用户关系 | 平台 ↔ 买家 | 品牌 ↔ 达人 ↔ 达人粉丝 | +| 数据源 | USER系统内部 | JOYCOLLAB同步 | +| 财务 | 返款（固定金额） | 提成+返点（按效果） | +| 风险关注 | 诈骗/双重退款 | 合作纠纷/违约/虚假流量 | + +#### 16.3 IM/EDM/APP 在免评中的协同角色 + +| 协同动作 | 渠道 | 说明 | +| --- | --- | --- | +| KOC内容二次分发 | IM/APP | 将KOC发布的优质内容推送给站内用户 | +| 免评Code触达 | IM/EDM | 将免评Code分发给符合条件的站内用户 | +| 活动引流 | APP Push | 推送活动通知引导用户进入KOC内容页 | +| 结果通知 | IM/APP | 通知用户Code到账、订单确认 | + +#### 16.4 免评核心结果组 + +| 结果组 | 跟踪内容 | +| --- | --- | +| 内容 | 发布状态、链接、发布时间、互动数据 | +| 引流 | 点击量、跳转量、Code使用量 | +| 成交 | 订单数、转化量、销量 | +| 经营 | 权重变化、ASIN健康变化、品牌搜索变化 | + +--- + +### 17. 店铺紧急催评流程（IM渠道专属子流程） + +```mermaid +flowchart TB + TRIGGER["触发条件
查：店铺当日掉评/差评/需紧急拿好评稳评分
状态：紧急触发"] --> CALC["计算推送量
目标好评数 ÷ 2% = 需触达用户数
写：推送方案"] + + CALC --> EXEC["执行"] + EXEC --> E1["查：筛选可触达用户
写：推送紧急催评消息"] + EXEC --> E2["查：优先触达高完成率用户"] + EXEC --> E3["查：持续跟踪回评提交状态"] + + E1 & E2 & E3 --> RESULT{"结果"} + RESULT -->|"已提交好评"| R1["写：更新已回评/测评完成
状态：已完成"] + RESULT -->|"未提交"| R2["写：保留在待催评池
状态：待催评"] + RESULT -->|"异常"| R3["转人工：推送客服跟进
状态：转客服"] + + style TRIGGER fill:#fce4ec,stroke:#c62828 +``` + +--- + +## 第三部分：渠道交叉与协同规则 + +### 18. 渠道优先级路由 + +```mermaid +flowchart LR + USER_IN["同一个用户"] --> D1{"查：用户状态"} + D1 -->|"APP注册 + 活跃 + 已绑定"| IM["IM 优先"] + D1 -->|"APP注册 + 低活跃"| APP_PUSH["APP Push优先 + IM补充"] + D1 -->|"未注册APP"| EDM["EDM优先 → 引导注册后转IM"] + D1 -->|"高价值 + 多次无响应"| TEL["TEL人工"] + D1 -->|"长期测评人（C类）"| IM_FREE["IM免评卡片 + KOC/KOL协同"] + + style IM fill:#e3f2fd + style EDM fill:#fff3e0 + style TEL fill:#fce4ec +``` + +### 19. 渠道间去重规则 + +| 规则 | 说明 | +| --- | --- | +| 同一计划同一用户 | 不重复通过多渠道路由，优先走最高优先级渠道 | +| 用户已在客服工单中 | 暂停自动触达，等待工单关闭后再判断 | +| 用户已提交评价（待核验） | 所有渠道暂停催评，等待核验结果 | +| 用户已退订某渠道 | 该渠道永久排除，不影响其他渠道 | +| 用户命中强关联风险 | **所有渠道暂停自动触达**，进入人工复核 | +| 用户命中弱关联风险 | 降频 + 提示后继续，但需人工关注 | + +### 20. 用户状态 × 渠道可用性矩阵 + +| 用户状态 | IM | EDM | APP Push | TEL | KOC/KOL | +| --- | --- | --- | --- | --- | --- | +| APP活跃 + 已绑定 | **首选** | 不送 | 补充 | - | - | +| APP活跃 + 未绑定 | 引导绑定 | - | 活动通知 | - | - | +| APP低活跃 | 降频 | 补充 | **召回** | - | - | +| 未注册APP | - | **首选** | - | 高价值时 | - | +| 已答应配合 | 提醒 | - | 到期提醒 | **超时拨打** | - | +| 长期测评人 (C) | **仅免评** | - | - | - | 可协同 | +| 黑名单/强关联 | **全暂停** | **全暂停** | **全暂停** | **需复核** | **暂停** | +| 弱关联风险 | 降频+提示 | 降频+提示 | 降频+提示 | 提示后执行 | 提示 | +| 累计接近12 | 预警+人工 | 预警+人工 | 预警+人工 | 可正常服务；涉及普通测评邀请时需人工复核 | - | +| 累计已满12 | 仅免评 | 仅免评 | 仅免评 | 可正常服务；不得绕过普通测评限制 | 可协同 | + +--- + +## 第四部分：第三步数据对象建议 + +### 21. 第三步建议优先产出的数据对象 + +| 优先级 | 对象 | 来源能力/渠道 | +| --- | --- | --- | +| **P0** | `person_profiles`（真实人） | §2 真实人识别 | +| **P0** | `person_identity_links`（身份关联） | §2 真实人识别 | +| **P0** | `contact_context_snapshots`（用户上下文快照） | §2 用户上下文卡 | +| **P0** | `person_quota_ledgers`（额度台账） | §4 额度台账 | +| **P0** | `quota_reservations`（额度预占） | §4 额度台账 | +| **P0** | `risk_signals`（风险信号） | §6 风险判断 | +| **P0** | `risk_cases`（风险事件） | §6 风险判断 | +| **P0** | `blacklist_entities`（黑名单实体） | §6 风险判断 | +| **P0** | `audience_snapshots`（人群快照） | §3 人群生成 | +| **P0** | `audience_exclusions`（人群排除记录） | §3 人群生成 | +| **P0** | `channel_route_decisions`（渠道路由决策） | §18 渠道优先级 | +| **P0** | `channel_dedup_records`（渠道去重记录） | §19 渠道间去重 | +| **P1** | `im_interaction_records`（IM交互记录） | §9 IM | +| **P1** | `im_flow_tags`（IM流程标签） | §9 IM | +| **P1** | `edm_message_events`（EDM事件） | §10 EDM | +| **P1** | `edm_user_behavior_profiles`（EDM用户行为画像） | §10 EDM | +| **P1** | `app_touch_events`（APP触达事件） | §11 APP | +| **P1** | `tel_call_records`（TEL通话记录） | §12 TEL | +| **P1** | `support_tickets`（客服工单） | §13 客服 | +| **P1** | `support_followups`（答应配合跟进） | §13 客服 | +| **P1** | `support_assignment_logs`（工单分配日志） | §13 客服 | +| **P1** | `review_submission_records`（评价提交记录） | §15 评价完成 | +| **P1** | `review_display_checks`（评价展示核验） | §15 评价完成 | +| **P1** | `exemption_plan_tasks`（免评计划任务） | §16 KOC/KOL | +| **P1** | `creator_content_records`（KOC内容记录） | §16 KOC/KOL | +| **P1** | `amazon_refund_records`（Amazon退款记录） | §6 双重退款 | +| **P1** | `oa_refund_records`（OA返款记录） | §6 双重退款 | +| **P1** | `refund_match_results`（退款比对结果） | §6 双重退款 | +| **P2** | `attendance_records`（出勤记录） | §14 客服管理 | +| **P2** | `shift_schedules`（排班表） | §14 客服管理 | +| **P2** | `support_goal_records`（客服目标） | §14 客服管理 | +| **P2** | `support_performance_snapshots`（绩效快照） | §14 客服管理 | +| **P2** | `interaction_audit_logs`（互动审计日志） | §8 审计 | +| **P2** | `manual_review_tasks`（人工复核任务） | §5/§6 复检与风险 | + +--- + +### 22. 与基线 v1.2 的关系 + +本文件是基线 v1.2 的下游细化产物： + +| 基线 v1.2 章节 | 本文件对应 | +| --- | --- | +| §6.1 主动触达支线 | §9 IM、§10 EDM、§11 APP Push | +| §6.2 免评执行支线 | §16 KOC/KOL + §16.3 协同角色 | +| §6.3 被动售后与TEL支线 | §12 TEL | +| §6.4 风险/诈骗拦截支线 | §6 风险判断与黑名单 | +| §6.5 客服工单与客服管理支线 | §13 客服工单、§14 客服管理 | +| §7 真实人识别、用户上下文与额度规则 | §2 真实人识别、§4 额度台账 | +| §8 渠道专属补充事实 | §9-§16 各渠道专属流程 | +| §11 第二步新入口 | 本文件整体 | + +--- + +### 23. 本版结论 + +v2.2 吸收了前序文档中的以下优势： + +1. **额度体系**（测评4/免评4/累计12）作为独立共用能力，含台账/预占/预警/拦截 +2. **画像拆解**为 7 组字段 × 3 类用途 +3. **节点规则表**统一用 查/写/状态/提醒/拦截/转人工 格式 +4. **EDM 专属行为指标**（3/5次0打开、点击未回复时长、单月收信次数） +5. **客服管理支撑流**（排班/出勤/绩效/目标） +6. **评价完成流程**中拆开"提交即计12"vs"展示才计完成" +7. **P0/P1/P2 数据对象**优先级 + +同时保留了我版的核心优势： + +1. **IM A/B/C 三层用户完整流转**（提交核验、测评流程、标签汇总、推送/流转动作表） +2. **渠道交叉与协同规则**（优先级路由、去重规则、用户状态 × 渠道可用性矩阵） +3. **KOC/KOL JOYCOLLAB 同步链路**及免评协同角色表 +4. **TEL 拨打前准备五步 + 重试策略** +5. **店铺紧急催评**独立子流程 +6. **三套并行客服状态**（工单/答应配合/风险） + +并完成以下收口： + +1. 将 IM 里残留的 `Amazon 账号 < / > 12 review` 全部改为 `真实人累计真实提交评价` 口径 +2. 明确 TEL 可继续服务，但不能绕开普通测评额度限制 +3. 补齐渠道路由、渠道去重、IM 流程标签和 EDM 行为画像对应的数据对象 diff --git a/wishfulfilled-wiki/05_需求文档/20260517_USER评价业务闭环_第三步_数据流与中间对象设计_v3.md b/wishfulfilled-wiki/05_需求文档/20260517_USER评价业务闭环_第三步_数据流与中间对象设计_v3.md new file mode 100644 index 0000000..436f43c --- /dev/null +++ b/wishfulfilled-wiki/05_需求文档/20260517_USER评价业务闭环_第三步_数据流与中间对象设计_v3.md @@ -0,0 +1,1030 @@ +# USER 评价业务闭环 — 第三步：数据流与中间对象设计 v3 + +## 文件信息 + +- 文件名称：`20260517_USER评价业务闭环_第三步_数据流与中间对象设计_v3.md` +- 项目路径：`C:\XCODE\USER` +- 当前版本：`v3` +- 最近更新：`2026-05-17` +- 上游文档： + - [工作基线 v1.2](20260517_USER评价业务闭环主流程与后续工作基线_v1.2.md) — 业务规则与额度口径 + - [共用能力图与渠道专属流程 v2.2](20260517_USER评价业务闭环_共用能力图与渠道专属流程_v2.2.md) — 每个节点的 查/写/状态/提醒/拦截 +- 前置版本： + - `数据流与中间对象需求_v1`（Codex，六层架构骨架） + - `数据流与中间对象设计_v1.1`（Codex，字段字典最全版） + - `第三步_数据流与中间表设计_v1`（字段级展开 + 流转时序） + - `第三步_数据流与中间表设计_v2`（吸收 Codex 优点的合并版） +- 合并策略：以 Codex v1.1 为主骨架（保留其完整字段字典和免评对象），补入 v2 的流转时序表、写入顺序图和快照策略。 +- 文件目的：作为第三步最终主稿，后续数据库物理设计、接口设计和页面点击读写设计均以此为准。 + +--- + +## 1. 第三步的目标 + +第三步不再回答"流程怎么走"，而是回答： + +1. 现有系统里已经有哪些数据可以复用。 +2. 为什么仅靠现有 `users / amazon_orders / review_plans / push_tasks / support_tickets / fraud_events` 不够。 +3. 必须新增哪些中间对象。 +4. 哪些是正式事务表，哪些只是快照，哪些可以先做成视图。 +5. 从需求形成到结果回流，数据怎样一层一层往下走。 + +--- + +## 2. 本步先给出的结论 + +### 2.1 不能再只围绕单一账号建模 + +后续所有关键判断都应围绕 **真实人**，而不是只看 JOYHUB ID / 邮箱 / 电话 / Amazon 账号 / 单次订单。JOYHUB 用户只是身份线索之一，真实人才是额度、历史、风险、跨渠道去重和客服上下文的主对象。 + +### 2.2 现有表能承载业务记录，但承载不了跨流程判断 + +既有表更接近"某一模块自己的账"，但前两步已确认的新需求需要额外的中间层：真实人跨账号归并、每次互动重判、人群入选/排除解释、额度预占与跨渠道去重、客服上下文、评价提交与展示拆分、退款比对。 + +### 2.3 第三步最重要的是把对象分层 + +本文件把数据对象分为六层： + +``` +源数据层 → 主实体层 → 桥接层 → 事件层 → 快照与决策层 → 结果回流层 +``` + +--- + +## 3. 数据设计原则 + +| 原则 | 说明 | +| --- | --- | +| 先识别真实人，再做额度与风险 | 否则 4/4/12 规则都会被多账号绕开 | +| 事件与快照分离 | 事件是原始事实，快照是某个时点的判断结果 | +| 当前态与历史态分离 | 当前视图可重算，历史决策必须留痕 | +| 计划、渠道、客服、风险状态分离 | 不能压成一个字段 | +| 用户提交与平台展示分离 | 真实提交计额度，Amazon 展示计计划完成 | +| 能解释"为什么" | 入选、排除、拦截、转人工都要能追溯 | +| 先复用现有对象，再补最小中间层 | 不为了建模漂亮重造全部旧表 | +| 对敏感数据分层处理 | 原值、标准化值、哈希/指纹、脱敏展示值应区分 | + +--- + +# 第一部分：现有数据源分析 + +## 4. 现有数据源盘点 + +| 数据源 | 当前可用内容 | 主要缺口 | +| --- | --- | --- | +| 现有 ERP 用户管理 | 用户 ID、用户名、注册时间、最近活跃、国家、性别、邮箱、绑定产品数、标签 | 仍是账号视角，不是真实人视角 | +| APP / 用户数据库 | JOYHUB ID、邮箱、设备号、设备型号/类型、系统版本、APP版本、绑定玩具、活跃与点击行为 | 需要设备变更轨迹和与订单/客服联动 | +| Amazon 订单 | 订单号、ASIN、站点、购买时间、订单状态、Profile ID、收件人姓名、收件地址等 | 需要标准化姓名/地址和收件人指纹 | +| Amazon 评价/Listing | ASIN、评分、评价数、差评数、评价缺口、展示结果 | 用户真实提交与平台展示要拆成两条事实 | +| 推送系统 | Push 计划、素材、任务、打开、点击、回复、投诉、退订 | IM/EDM/APP 语义不同，不能只用一套粗糙 push 结果 | +| 客服/TEL | 工单、通话、售后、答应配合、问题处理 | 需要和上下文卡、风险复检、跟进状态联动 | +| 黑名单/诈骗资料 | 黑名单、诈骗事件、双重退款、强弱关联 | 需要把风险信号与确认案件拆开 | +| OA 返款/Amazon 退款 | 内部返款与 Amazon 退款 | 缺统一比对对象 | +| JOYCOLLAB | KOC/KOL、内容、Code、点击、订单、转化、佣金 | 需要和 USER 计划/ASIN 结果打通 | + +### 4.1 Amazon 订单字段明细（结合表头.xlsx） + +| 字段 | 主要用途 | 涉密 | +| --- | --- | --- | +| 订单号 | 订单核验、真实人关联、退款比对 | 是 | +| 订单状态 | 判断是否撤销、退款、退货、换货 | - | +| 买家姓名 / 买家邮箱 | 身份关联 | 是 | +| 收件人 / 电话 | 真实人归并、风险判断 | 是 | +| 地址 / 城市 / 州 / 邮编 | 收件人归并、同址异名识别 | 是 | +| ASIN / MSKU / SKU / 品名 / 标题 | 产品匹配、计划归属 | - | +| 订购日期 / 发货时间 / 结算时间 | 时序判断 | - | +| 数量 / 单价 / 订单总金额 / 销售额 | 交易画像 | 是 | +| 是否退款 / 退款总金额 | 双重退款检测 | 是 | +| 请求评论状态 | 评价缺口判断 | - | +| 店铺 / 国家 / 销售渠道 | 站点匹配 | - | +| Order Item ID | 订单行级关联 | - | + +### 4.2 订单侧必须补的派生字段 + +| 字段 | 说明 | +| --- | --- | +| `recipient_name_normalized` | 标准化后的收件人姓名 | +| `recipient_address_normalized` | 标准化后的地址 | +| `recipient_fingerprint` | 由标准化姓名+地址生成的稳定指纹 | +| `address_fingerprint` | 仅地址指纹，用于识别同址异名 | + +--- + +## 5. 全局数据流 + +```mermaid +flowchart LR + subgraph S["源数据层"] + S1["现有ERP用户/标签/身份"] + S2["APP/设备/行为"] + S3["Amazon订单/评价/Listing"] + S4["IM/EDM/APP Push/TEL"] + S5["客服/工单/售后"] + S6["黑名单/OA返款/Amazon退款"] + S7["JOYCOLLAB"] + end + + subgraph M["主实体与桥接层"] + M1["真实人 person_profiles"] + M2["身份关联 person_identity_links"] + M3["订单/ASIN/计划/工单"] + M4["订单关联/路由/去重"] + end + + subgraph D["快照与决策层"] + D1["画像快照 person_feature_snapshots"] + D2["上下文卡 contact_context_snapshots"] + D3["额度台账/预占"] + D4["风险信号/风险案件"] + D5["人群快照/排除快照"] + D6["互动复检/路由决策"] + end + + subgraph E["事件层"] + E1["渠道事件"] + E2["客服/TEL事件"] + E3["退款事件"] + E4["评价提交事件"] + E5["免评执行事件"] + end + + subgraph R["结果回流层"] + R1["评价展示核验"] + R2["退款比对结果"] + R3["免评结果"] + R4["ASIN健康/计划完成"] + R5["绩效/审计/下一轮需求"] + end + + S1 & S2 & S3 --> M1 + S1 & S2 & S3 --> M2 + M1 & M2 & M3 --> D1 + M1 & M2 & M3 --> D2 + D1 --> D5 + D3 & D4 --> D5 + D5 --> D6 + D6 --> E1 + S4 --> E1 + S5 --> E2 + S6 --> E3 + E1 & E2 --> E4 + S7 --> E5 + E3 --> R2 + E4 --> R1 + E5 --> R3 + R1 & R2 & R3 --> R4 + R4 --> R5 + R5 --> M3 +``` + +--- + +# 第二部分：数据对象分层总表 + +## 6. 对象分层总表 + +| 分层 | 对象 | 说明 | +| --- | --- | --- | +| 源数据 | `users`、`devices`、`amazon_orders`、`asin_listings`、`push_tasks`、`support_tickets`、`fraud_events`、JOYCOLLAB 数据 | 现有或外部事实来源 | +| 主实体 | `person_profiles`、`request_tickets`、`review_plans`、`exemption_plans`、`risk_cases`、`blacklist_entities` | 核心业务主体 | +| 桥接 | `person_identity_links`、`user_order_links`、`plan_task_links`、`channel_route_decisions`、`channel_dedup_records` | 跨主体关系 | +| 事件 | `im_interaction_records`、`im_flow_tags`、`edm_message_events`、`app_touch_events`、`tel_call_records`、`review_submission_records`、`amazon_refund_records`、`oa_refund_records`、`support_assignment_logs` | 不可丢失的事实 | +| 快照/决策 | `person_feature_snapshots`、`contact_context_snapshots`、`person_quota_ledgers`、`quota_reservations`、`audience_snapshots`、`audience_exclusions`、`interaction_recheck_records`、`edm_user_behavior_profiles`、`channel_route_decisions`、`channel_dedup_records` | 为某次决策保留当时依据 | +| 结果/回流 | `review_display_checks`、`refund_match_results`、`exemption_result_snapshots`、`listing_health_snapshots`、`support_performance_snapshots` | 结果与复盘 | +| 治理 | `interaction_audit_logs`、`manual_review_tasks`、`export_logs`、`audit_logs` | 审计、复核、导出 | + +--- + +## 7. 现有对象如何处理 + +### 7.1 可以直接复用 + +| 现有对象 | 处理 | +| --- | --- | +| `request_tickets` | 保留，继续作为需求入口 | +| `amazon_orders` | 保留，补标准化姓名/地址与收件人指纹 | +| `asin_listings` | 保留，继续作为 ASIN/Listing 主档 | +| `support_tickets` | 保留，拆出跟进、分派和风险状态辅助表 | +| `fraud_events` | 保留，上游增加 `risk_signals`，下游衔接 `risk_cases/blacklist_entities` | +| `audit_logs` | 保留 | + +### 7.2 需要扩展 + +| 现有对象 | 需要补的能力 | +| --- | --- | +| `users` | 不再承担真实人主档，只保留 JOYHUB 账号层信息 | +| `devices` | 补设备型号、系统版本、APP版本、首次/最近出现、设备变化 | +| `review_plans` | 增加计划族或与 `exemption_plans` 分离 | +| `push_tasks` | 被更细的渠道事件表补充 | +| `support_tickets` | 增加与上下文卡、答应配合、风险复核、TEL 记录的关联 | + +### 7.3 必须新增 + +| 对象 | 原因 | +| --- | --- | +| `person_profiles` | 真实人主档 | +| `person_identity_links` | 多线索归并 | +| `person_feature_snapshots` | 画像解释 | +| `contact_context_snapshots` | 客服一屏上下文 | +| `person_quota_ledgers` | 4/4/12 统一额度 | +| `quota_reservations` | 并发占用与预警 | +| `audience_snapshots` | 人群生成留痕 | +| `audience_exclusions` | 排除原因留痕 | +| `channel_route_decisions` | 渠道路由解释 | +| `channel_dedup_records` | 跨渠道去重 | +| `interaction_recheck_records` | 每次有效互动重新判断留痕 | +| `refund_match_results` | 双重退款识别 | +| `review_display_checks` | 评价展示拆分 | + +--- + +# 第三部分：P0/P1/P2 优先级 + +## 8. P0：没有它们，主流程就不可靠 + +| 对象 | 类型 | 关键用途 | +| --- | --- | --- | +| `person_profiles` | 主实体 | 真实人主档 | +| `person_identity_links` | 桥接 | 账号、邮箱、电话、设备、Profile、收件人归并 | +| `person_feature_snapshots` | 快照 | 画像依据 | +| `contact_context_snapshots` | 快照 | 客服上下文卡 | +| `person_quota_ledgers` | 台账 | 4/4/12 统一额度 | +| `quota_reservations` | 台账 | 计划并发占用 | +| `risk_signals` | 事件 | 风险原始信号 | +| `risk_cases` | 主实体 | 风险案件 | +| `blacklist_entities` | 主实体 | 确认拦截对象 | +| `audience_snapshots` | 快照 | 某次人群生成结果 | +| `audience_exclusions` | 快照 | 排除原因 | +| `channel_route_decisions` | 决策 | 渠道路由 | +| `channel_dedup_records` | 决策 | 跨渠道去重 | +| `interaction_recheck_records` | 决策 | 每次有效互动重判 | + +## 9. P1：主流程可走，但没有它们会粗糙且难复盘 + +| 对象 | 类型 | 关键用途 | +| --- | --- | --- | +| `im_interaction_records` | 事件 | IM 细节 | +| `im_flow_tags` | 事件/派生 | IM 流程流转 | +| `edm_message_events` | 事件 | EDM 打开/点击/回复/退订 | +| `edm_user_behavior_profiles` | 快照 | EDM 画像 | +| `app_touch_events` | 事件 | APP Push 触达 | +| `tel_call_records` | 事件 | 电话全记录 | +| `support_followups` | 事务 | 答应配合跟进 | +| `support_assignment_logs` | 事件 | 分配与升级 | +| `review_submission_records` | 事件 | 用户真实提交评价 | +| `review_display_checks` | 结果 | Amazon 展示核验 | +| `exemption_plans` | 主实体 | 免评计划 | +| `exemption_plan_tasks` | 事务 | 免评任务 | +| `creator_content_records` | 事件 | KOC/KOL 内容 | +| `exemption_result_snapshots` | 结果 | 免评结果 | +| `amazon_refund_records` | 事件 | Amazon 退款 | +| `oa_refund_records` | 事件 | OA 返款 | +| `refund_match_results` | 结果 | 双重退款比对 | + +## 10. P2：管理、效率与治理增强 + +| 对象 | 类型 | 关键用途 | +| --- | --- | --- | +| `attendance_records` | 事务 | 出勤 | +| `shift_schedules` | 事务 | 排班 | +| `support_goal_records` | 事务 | 目标 | +| `support_performance_snapshots` | 快照 | 绩效 | +| `manual_review_tasks` | 事务 | 人工复核 | +| `interaction_audit_logs` | 审计 | 高敏动作审计 | + +--- + +# 第四部分：完整字段字典 + +## 11. 真实人与身份层 + +### 11.1 `person_profiles` + +| 字段 | 类型 | 说明 | +| --- | --- | --- | +| `person_id` | PK | 真实人唯一标识 | +| `created_at` | datetime | 首次识别时间 | +| `updated_at` | datetime | 最近归并更新时间 | +| `merge_confidence` | enum | 高/中/低 | +| `status` | enum | 正常/观察中/已确认风险 | +| `primary_country` | string | 当前主要国家 | +| `primary_language` | string | 当前主要语言 | +| `latest_active_at` | datetime | 最近活跃时间 | +| `lifetime_review_submitted_count` | int | 累计真实提交评价数（跨账号合并） | +| `current_risk_level` | enum | 当前风险等级 | + +### 11.2 `person_identity_links` + +| 字段 | 类型 | 说明 | +| --- | --- | --- | +| `link_id` | PK | 关联记录 ID | +| `person_id` | FK → person_profiles | 所属真实人 | +| `identity_type` | enum | JOYHUB_ID / EMAIL / PHONE / DEVICE / AMAZON_PROFILE / NAME_ADDRESS / PAYMENT / ORDER | +| `identity_value_hash` | string | 匹配索引 | +| `identity_value_encrypted` | string | 仅在必要时保存的加密原值 | +| `link_strength` | enum | 强/弱 | +| `confidence_score` | decimal | 归并置信度 | +| `evidence_summary` | text | 命中依据摘要 | +| `first_seen_at` | datetime | 首次发现时间 | +| `last_seen_at` | datetime | 最近确认时间 | +| `source_type` | enum | AMAZON_ORDER / JOYHUB / MANUAL / TEL / EMAIL / CS_TICKET | +| `is_active` | bool | 是否仍有效 | + +### 11.3 归并口径 + +| 场景 | 数据处理 | +| --- | --- | +| 标准化后姓名+地址完全一致 | 直接归并到同一真实人，link_strength=STRONG | +| 地址一致但姓名不同 | 记录弱关联，不直接合并 | +| 多个线索交叉命中 | 形成候选归并，记录证据和置信度 | +| 只有单个弱线索 | 不做直接归并，只写风险信号 | + +### 11.4 `contact_context_snapshots` + +| 字段组 | 字段 | 来源 | +| --- | --- | --- | +| 快照元数据 | `snapshot_id`、`person_id`、`snapshot_at`、`trigger_event` | 系统 | +| 当前身份 | `joyhub_ids[]`、`emails[]`、`phones[]`、`devices[]`、`amazon_profile_ids[]` | 身份关联 | +| 归并摘要 | `standardized_name_address`、`linked_person_count`、`merge_confidence` | 真实人/身份关联 | +| 历史交易 | `total_orders`、`last_order_at`、`total_refunds`、`total_oa_refunds`、`target_asin_purchases[]` | 订单/返款 | +| 历史服务 | `total_tickets`、`last_ticket_at`、`total_calls`、`last_call_at`、`open_promises[]` | 工单/电话 | +| 历史风险 | `blacklist_hits`、`strong_associations`、`weak_associations`、`fraud_cases`、`double_refund_flags` | 风险层 | +| 当前设备 | `device_count`、`latest_device_model`、`app_version`、`recent_device_change` | APP/设备 | +| 触达历史 | `im_recent[]`、`edm_recent[]`、`app_recent[]`、`tel_recent[]` | 渠道事件 | + +--- + +## 12. 画像、额度与人群层 + +### 12.1 `person_feature_snapshots` + +| 字段组 | 代表字段 | +| --- | --- | +| 快照元数据 | `feature_snapshot_id`、`person_id`、`snapshot_at`、`feature_version` | +| 基础画像 | `country`、`marketplace`、`language`、`gender`、`age_band`、`registered_at` | +| 产品关系 | `bound_toy_count`、`bound_categories[]`、`target_product_relation` | +| 交易画像 | `total_orders`、`last_order_at`、`purchase_frequency`、`bought_target_asin` | +| 行为画像 | `activity_score`、`open_rate`、`click_rate`、`reply_rate`、`review_rate`、`cooperation_rate` | +| 触达画像 | `im_reachable`、`edm_reachable`、`app_reachable`、`tel_reachable`、`last_touch_at` | +| 风险画像 | `risk_level`、`blacklist_hit`、`strong_link_count`、`weak_link_count`、`refund_anomaly_flag` | +| 计划画像 | `joined_plan_types[]`、`last_plan_result`、`lifetime_review_submitted_count` | + +### 12.2 三类画像用途 + +| 用途 | 说明 | 示例 | +| --- | --- | --- | +| **硬过滤** | 决定能不能进入人群池 | 黑名单、退订、强关联、超额、站点不符 | +| **匹配条件** | 决定适不适合当前计划 | 国家、性别、年龄段、绑定玩具、是否买过目标 ASIN | +| **排序权重** | 决定优先触达谁 | 活跃度、历史配合率、最近互动、打开/点击行为 | + +### 12.3 `person_quota_ledgers` + +> **HANDOFF：用户运营核心控制规则。** "4+4+12"全部按真实人统计，跨所有关联账号合并计算。一个人不管有几个 JOYHUB ID、几个 Amazon 账号——只要归并到同一个真实人，都受同一套额度控制。 +> +> 示例：真实人关联 3 个 JOYHUB ID（A/B/C），A 上提交 5 个 + B 上提交 4 个 + C 上提交 3 个 = 累计 12，**全部账号停回评/测评，后续仅免评。** + +| 字段 | 类型 | 说明 | +| --- | --- | --- | +| `ledger_id` | PK | 台账记录 ID | +| `person_id` | FK → person_profiles | 真实人 | +| `period_key` | string | 自然月，如 `2026-05` | +| `quota_type` | enum | MONTHLY_REVIEW / MONTHLY_EXEMPTION / LIFETIME_REVIEW | +| `quota_limit` | int | 4 / 4 / 12 | +| `used` | int | 已完成 | +| `in_progress` | int | 进行中 | +| `reserved` | int | 已预占 | +| `available` | int | 剩余可用 = limit - used - in_progress - reserved | +| `updated_at` | datetime | 最近更新 | + +### 12.4 `quota_reservations` + +| 字段 | 类型 | 说明 | +| --- | --- | --- | +| `reservation_id` | PK | 预占记录 | +| `person_id` | FK | 真实人 | +| `plan_id` | FK | 关联计划 | +| `quota_type` | enum | 测评/免评 | +| `reserved_count` | int | 预占数量 | +| `reserved_at` | datetime | 预占时间 | +| `expires_at` | datetime | 过期释放时间 | +| `status` | enum | 已预占/已使用/已释放/已过期 | + +### 12.5 `audience_snapshots` + +| 字段 | 类型 | 说明 | +| --- | --- | --- | +| `snapshot_id` | PK | 人群快照 ID | +| `plan_id` | FK | 计划 | +| `batch_id` | string | 生成人群批次 | +| `person_id` | FK | 真实人 | +| `match_score` | decimal | 匹配得分 | +| `match_reasons` | JSON | 命中画像条件 | +| `quota_status` | enum | 充足/预警/超限 | +| `risk_status` | enum | 正常/弱风险/强风险 | +| `priority_rank` | int | 触达优先级 | +| `feature_snapshot_id` | FK | 当时引用的画像快照 | +| `snapshot_at` | datetime | 快照时间 | + +### 12.6 `audience_exclusions` + +| 字段 | 类型 | 说明 | +| --- | --- | --- | +| `exclusion_id` | PK | 排除记录 | +| `plan_id` | FK | 计划 | +| `batch_id` | string | 批次 | +| `person_id` | FK | 真实人 | +| `exclusion_reason` | enum | BLACKLIST / UNSUBSCRIBED / QUOTA_EXCEEDED / FREQ_EXCEEDED / OPEN_TICKET / WRONG_COUNTRY / STRONG_RISK | +| `excluded_at` | datetime | 排除时间 | + +### 12.7 为什么一定需要这些中间表 + +| 对象 | 如果没有会怎样 | +| --- | --- | +| `person_feature_snapshots` | 无法解释当时的画像依据 | +| `audience_snapshots` | 无法复盘某次计划到底选中了谁 | +| `audience_exclusions` | 无法解释为什么用户没被选中 | +| `person_quota_ledgers` | 4/4/12 规则无法跨账号统一计算 | +| `quota_reservations` | 多个计划并发时会重复占用同一人额度 | + +--- + +## 13. 路由与互动复检层 + +### 13.1 `channel_route_decisions` + +| 字段 | 类型 | 说明 | +| --- | --- | --- | +| `route_decision_id` | PK | 路由决策 ID | +| `plan_id` | FK | 计划 | +| `batch_id` | string | 人群批次 | +| `person_id` | FK | 真实人 | +| `candidate_channels` | JSON | 候选渠道 | +| `selected_channel` | enum | 实际选中渠道 | +| `excluded_channels` | JSON | 被排除渠道及原因 | +| `decision_factors` | JSON | 活跃、绑定、可达性、工单、额度、风险 | +| `decided_at` | datetime | 决策时间 | + +### 13.2 `channel_dedup_records` + +| 字段 | 类型 | 说明 | +| --- | --- | --- | +| `dedup_id` | PK | 去重记录 | +| `person_id` | FK | 真实人 | +| `plan_id` | FK | 计划 | +| `selected_channel` | enum | 保留渠道 | +| `suppressed_channels` | JSON | 被抑制渠道 | +| `reason` | text | 去重原因 | +| `created_at` | datetime | 去重时间 | + +### 13.3 `interaction_recheck_records` + +每次有效互动后，记录本次重新做过哪些检查、结果是什么、为何继续或拦截。这是"每次互动重判"的落地证据。 + +| 字段 | 类型 | 说明 | +| --- | --- | --- | +| `recheck_id` | PK | 复检记录 | +| `interaction_type` | enum | IM / EDM / APP / TEL / CS / REFUND | +| `interaction_id` | string | 触发互动 | +| `person_id` | FK | 真实人 | +| `context_snapshot_id` | FK | 上下文快照 | +| `quota_snapshot_ref` | string | 额度快照引用 | +| `risk_case_id` | FK | 关联风险案件 | +| `identity_result` | enum | 正常/新增关联/冲突 | +| `history_result` | enum | 无变化/有更新 | +| `quota_result` | enum | 充足/预警/超限 | +| `risk_result` | enum | 正常/弱风险/强风险 | +| `final_action` | enum | 继续/降级/转人工/暂停 | +| `checked_at` | datetime | 复检时间 | + +--- + +## 14. 风险层 + +### 14.1 `risk_signals` + +| 字段 | 类型 | 说明 | +| --- | --- | --- | +| `signal_id` | PK | 风险信号 ID | +| `person_id` | FK | 真实人 | +| `signal_type` | enum | STRONG_HIT / WEAK_HIT / DOUBLE_REFUND / DEVICE_ANOMALY / ADDRESS_ANOMALY / BLACKLIST_HIT | +| `hit_dimensions` | JSON | 命中维度 | +| `source_event_id` | string | 触发事件 | +| `created_at` | datetime | 产生时间 | +| `resolved_at` | datetime | 解除时间 | +| `resolution` | enum | 确认风险/误报/观察中 | + +### 14.2 `risk_cases` + +| 字段 | 类型 | 说明 | +| --- | --- | --- | +| `case_id` | PK | 风险案件 | +| `person_id` | FK | 真实人 | +| `source_type` | enum | CS_TICKET / TEL_CALL / PUSH_RESPONSE / REFUND / MANUAL | +| `source_id` | string | 来源对象 | +| `status` | enum | 待复核/复核中/确认诈骗/排除/已同步黑名单 | +| `reviewer_id` | FK | 复核人 | +| `reviewed_at` | datetime | 复核时间 | +| `sync_status` | enum | 未同步/同步中/已同步/同步失败 | + +### 14.3 `blacklist_entities` + +| 字段 | 类型 | 说明 | +| --- | --- | --- | +| `blacklist_entity_id` | PK | 黑名单实体 | +| `entity_type` | enum | 邮箱/电话/设备/Profile/收款信息/真实人 | +| `entity_hash` | string | 匹配索引 | +| `risk_level` | enum | 风险等级 | +| `source_case_id` | FK | 来源案件 | +| `synced_at` | datetime | 同步时间 | +| `status` | enum | 生效/失效/待复核 | + +### 14.4 `manual_review_tasks` + +| 字段 | 类型 | 说明 | +| --- | --- | --- | +| `task_id` | PK | 人工复核任务 | +| `person_id` | FK | 真实人 | +| `source_type` | enum | 风险/额度/渠道/退款 | +| `source_id` | string | 来源对象 | +| `task_reason` | text | 复核原因 | +| `status` | enum | 待处理/处理中/已完成/已关闭 | +| `owner_id` | FK | 负责人 | +| `created_at` | datetime | 创建时间 | + +--- + +## 15. 渠道事件层 + +### 15.1 `im_interaction_records` + +| 字段 | 类型 | 说明 | +| --- | --- | --- | +| `im_record_id` | PK | IM 记录 | +| `person_id` | FK | 真实人 | +| `joyhub_id` | FK | JOYHUB 账号 | +| `plan_id` | FK | 关联计划 | +| `action_type` | enum | PUSH_CARD / USER_SUBMIT / USER_REPLY / REMINDER / NOTIFICATION | +| `card_type` | enum | REVIEW_CARD / EVALUATION_CARD / EXEMPTION_CARD / REMINDER_CARD | +| `user_submitted_data` | JSON | 订单号/返款账号/截图链接（涉密加密存储） | +| `order_validation_result` | enum | 通过/非测评单/非公司产品/格式错误/已撤销/已退款 | +| `tag_changes` | JSON | 本次产生的标签变化 | +| `created_at` | datetime | 事件时间 | + +### 15.2 `im_flow_tags` + +| 字段 | 类型 | 说明 | +| --- | --- | --- | +| `flow_tag_id` | PK | 流程标签记录 | +| `person_id` | FK | 真实人 | +| `tag_code` | string | 流程标签 | +| `source_im_record_id` | FK | 来源 IM 事件 | +| `effective_from` | datetime | 生效时间 | +| `effective_to` | datetime | 失效时间 | + +### 15.3 `edm_message_events` + +| 字段 | 类型 | 说明 | +| --- | --- | --- | +| `edm_event_id` | PK | EDM 事件 | +| `person_id` | FK | 真实人 | +| `email_hash` | string | 邮箱索引 | +| `campaign_id` | FK | 邮件任务 | +| `event_type` | enum | SENT / DELIVERED / OPENED / CLICKED / REPLIED / BOUNCED / UNSUBSCRIBED / COMPLAINED | +| `event_at` | datetime | 事件时间 | +| `click_target` | string | 点击目标 | + +### 15.4 `edm_user_behavior_profiles` + +| 字段 | 类型 | 说明 | +| --- | --- | --- | +| `profile_id` | PK | EDM 行为画像 | +| `person_id` | FK | 真实人 | +| `latest_open_at` | datetime | 最近打开 | +| `latest_reply_at` | datetime | 最近回复 | +| `open_count_total` | int | 累计打开次数 | +| `zero_open_last_3` | bool | 最近 3 次 0 打开 | +| `zero_open_last_5` | bool | 最近 5 次 0 打开 | +| `clicked_review_link_without_reply_hours` | int | 点击评论链接但未回复时长 | +| `monthly_receive_count` | int | 当月收信次数 | +| `mail_type_counts` | JSON | 各邮件类型发送次数 | +| `mailbox_domain` | string | 邮箱后缀 | +| `is_unsubscribed` | bool | 是否退订 | +| `has_hard_bounce` | bool | 是否硬退信 | +| `snapshot_at` | datetime | 快照时间 | + +### 15.5 `app_touch_events` + +| 字段 | 类型 | 说明 | +| --- | --- | --- | +| `app_event_id` | PK | APP 事件 | +| `person_id` | FK | 真实人 | +| `joyhub_id` | FK | JOYHUB 账号 | +| `push_type` | enum | PUSH / IN_APP / BANNER / POPUP | +| `event_type` | enum | SENT / DISPLAYED / CLICKED / DISMISSED / UNINSTALLED | +| `landing_page` | string | 落地页 | +| `event_at` | datetime | 事件时间 | + +### 15.6 `tel_call_records` + +| 字段 | 类型 | 说明 | 涉密 | +| --- | --- | --- | --- | +| `tel_record_id` | PK | 电话记录 | - | +| `person_id` | FK | 真实人 | - | +| `ticket_id` | FK | 关联工单 | - | +| `call_direction` | enum | INBOUND/OUTBOUND | - | +| `call_source` | enum | AMAZON_PAGE/MANUAL/PLAN_TASK/FOLLOWUP | - | +| `phone_hash` | string | 电话索引 | 是 | +| `call_at` | datetime | 通话时间 | - | +| `duration_seconds` | int | 通话时长 | - | +| `call_result` | enum | CONNECTED/NO_ANSWER/WRONG_NUMBER/DECLINED | - | +| `has_after_sale_issue` | bool | 是否有售后 | - | +| `issue_type` | enum | 问题类型 | - | +| `issue_description` | text | 问题描述 | - | +| `solution` | text | 处理方案 | - | +| `is_resolved` | bool | 是否解决 | - | +| `is_satisfied` | bool | 是否满意 | - | +| `invited_review` | bool | 是否邀请回评/测评 | - | +| `user_accepted` | bool | 是否接受 | - | +| `agent_id` | FK | 客服 | - | + +--- + +## 16. 客服层 + +### 16.1 `support_tickets` + +| 字段 | 类型 | 说明 | +| --- | --- | --- | +| `ticket_id` | PK | 工单 | +| `person_id` | FK | 真实人 | +| `ticket_type` | enum | 差评跟进/测评跟进/回评跟进/紧急Listing/电话/售后/诈骗样品/KOL进度 | +| `source` | enum | AMAZON_OP/BRAND_OP/SYSTEM_AUTO/PUSH_ESCALATION/USER_REPLY/TEL_INBOUND | +| `source_id` | string | 来源对象 | +| `ticket_status` | enum | 待分配/已分配/处理中/等待用户/等待内部/已解决/疑似诈骗/已关闭 | +| `assigned_team` | FK | 客服组 | +| `assigned_agent` | FK | 客服 | +| `created_at` | datetime | 创建时间 | +| `first_response_at` | datetime | 首次回复 | +| `resolved_at` | datetime | 解决时间 | +| `closed_at` | datetime | 关闭时间 | +| `context_snapshot_id` | FK | 创建时上下文快照 | + +### 16.2 `support_followups` + +| 字段 | 类型 | 说明 | +| --- | --- | --- | +| `followup_id` | PK | 跟进 | +| `ticket_id` | FK | 工单 | +| `person_id` | FK | 真实人 | +| `followup_status` | enum | 已答应配合/待分配/待提醒/等待提交/已提交评价/已提交反馈/超时/需再次联系/已关闭 | +| `promised_at` | datetime | 承诺时间 | +| `reminder_count` | int | 已提醒次数 | +| `last_reminder_at` | datetime | 最近提醒 | +| `deadline_at` | datetime | 截止时间 | +| `submitted_at` | datetime | 实际提交 | +| `submission_type` | enum | 评价/反馈 | + +### 16.3 `support_assignment_logs` + +| 字段 | 类型 | 说明 | +| --- | --- | --- | +| `assignment_log_id` | PK | 分配日志 | +| `ticket_id` | FK | 工单 | +| `from_owner_id` | FK | 原负责人 | +| `to_owner_id` | FK | 新负责人 | +| `assign_type` | enum | 自动分配/组长分派/转派/升级 | +| `reason` | text | 原因 | +| `created_at` | datetime | 分配时间 | + +### 16.4 `plan_task_links` + +| 字段 | 类型 | 说明 | +| --- | --- | --- | +| `link_id` | PK | 桥接 ID | +| `plan_id` | FK | 计划 | +| `task_type` | enum | IM_TASK/EDM_TASK/APP_TASK/TEL_TASK/CS_TASK/KOC_TASK | +| `task_id` | string | 各渠道任务 ID | +| `created_at` | datetime | 创建时间 | + +--- + +## 17. 评价与退款结果层 + +### 17.1 `review_submission_records` + +| 字段 | 类型 | 说明 | +| --- | --- | --- | +| `submission_id` | PK | 提交记录 | +| `person_id` | FK | 真实人 | +| `plan_id` | FK | 计划 | +| `channel` | enum | IM/EDM/APP/TEL/CS | +| `source_event_id` | string | 来源事件 | +| `submitted_at` | datetime | 提交时间 | +| `submission_evidence` | JSON | 截图/链接 | +| `order_number_hash` | string | 订单索引 | +| `quota_counted` | bool | 是否已计入 12（提交时即为true） | + +### 17.2 `review_display_checks` + +| 字段 | 类型 | 说明 | +| --- | --- | --- | +| `check_id` | PK | 核验记录 | +| `submission_id` | FK | 提交记录 | +| `asin` | string | ASIN | +| `check_at` | datetime | 核验时间 | +| `is_displayed` | bool | 是否展示 | +| `is_verifiable` | bool | 是否可核验 | +| `display_status` | enum | 展示确认/未展示/待核验 | +| `plan_completed` | bool | 是否计入计划完成（展示确认后才为true） | + +### 17.3 `amazon_refund_records` / `oa_refund_records` / `refund_match_results` + +| 对象 | 关键字段 | +| --- | --- | +| `amazon_refund_records` | `refund_id`、`order_number_hash`、`asin`、`refund_amount`、`refund_at`、`refund_reason` | +| `oa_refund_records` | `oa_refund_id`、`person_id`、`order_number_hash`、`refund_amount`、`refund_at` | +| `refund_match_results` | `match_id`、`order_number_hash`、`amazon_refund_id`、`oa_refund_id`、`match_status`、`amount_diff`、`matched_at` | + +--- + +## 18. 免评结果层 + +### 18.1 `exemption_plans` + +| 字段 | 类型 | 说明 | +| --- | --- | --- | +| `exemption_plan_id` | PK | 免评计划 | +| `source_request_id` | FK | 来源需求 | +| `asin` | string | ASIN | +| `marketplace` | string | 站点 | +| `goal_type` | enum | 内容发布/引流/带货/权重 | +| `target_metrics` | JSON | 目标点击、Code、订单、销量、权重 | +| `status` | enum | 草稿/待审批/执行中/已完成/已关闭 | + +### 18.2 `exemption_plan_tasks` + +| 字段 | 类型 | 说明 | +| --- | --- | --- | +| `task_id` | PK | 免评任务 | +| `exemption_plan_id` | FK | 免评计划 | +| `task_type` | enum | KOC/KOL/IM/EDM/APP/内容协同 | +| `owner_id` | FK | 负责人 | +| `status` | enum | 待执行/执行中/已完成/异常 | +| `created_at` | datetime | 创建时间 | + +### 18.3 `creator_content_records` + +| 字段 | 类型 | 说明 | +| --- | --- | --- | +| `creator_content_id` | PK | 内容记录 | +| `exemption_task_id` | FK | 免评任务 | +| `creator_id` | string | KOC/KOL | +| `content_url` | string | 内容链接 | +| `published_at` | datetime | 发布时间 | +| `code_usage_count` | int | Code 使用量 | +| `click_count` | int | 点击量 | +| `order_count` | int | 带货订单 | +| `sales_amount` | decimal | 销售额 | + +### 18.4 `exemption_result_snapshots` + +| 字段 | 类型 | 说明 | +| --- | --- | --- | +| `snapshot_id` | PK | 免评结果快照 | +| `exemption_plan_id` | FK | 免评计划 | +| `snapshot_at` | datetime | 快照时间 | +| `content_published_count` | int | 内容发布数 | +| `click_count` | int | 点击 | +| `code_usage_count` | int | Code 使用 | +| `order_count` | int | 订单 | +| `sales_amount` | decimal | 销售额 | +| `weight_change_summary` | text | 权重变化摘要 | + +--- + +## 19. 客服管理支撑层 + +| 对象 | 关键字段 | +| --- | --- | +| `attendance_records` | `record_id`、`agent_id`、`date`、`scheduled_hours`、`actual_hours`、`status` | +| `shift_schedules` | `shift_id`、`team_id`、`agent_id`、`date`、`shift_start`、`shift_end`、`max_tickets` | +| `support_goal_records` | `goal_id`、`agent_id`、`period_key`、`goal_type`、`target_value`、`current_value` | +| `support_performance_snapshots` | `snapshot_id`、`agent_id`、`period_key`、`tickets_handled`、`messages_sent`、`first_response_avg_sec`、`rso_orders`、`rdo_orders`、`reviews_obtained`、`review_completion_rate`、`monthly_target`、`monthly_completed` | + +--- + +## 20. 逻辑关系总图 + +```mermaid +erDiagram + PERSON_PROFILES ||--o{ PERSON_IDENTITY_LINKS : "归并" + PERSON_PROFILES ||--o{ PERSON_FEATURE_SNAPSHOTS : "画像" + PERSON_PROFILES ||--o{ CONTACT_CONTEXT_SNAPSHOTS : "上下文" + PERSON_PROFILES ||--o{ PERSON_QUOTA_LEDGERS : "额度台账" + PERSON_PROFILES ||--o{ QUOTA_RESERVATIONS : "额度预占" + PERSON_PROFILES ||--o{ RISK_SIGNALS : "风险信号" + PERSON_PROFILES ||--o{ RISK_CASES : "风险案件" + PERSON_PROFILES ||--o{ AUDIENCE_SNAPSHOTS : "人群入选" + PERSON_PROFILES ||--o{ AUDIENCE_EXCLUSIONS : "人群排除" + PERSON_PROFILES ||--o{ CHANNEL_ROUTE_DECISIONS : "路由" + PERSON_PROFILES ||--o{ CHANNEL_DEDUP_RECORDS : "去重" + PERSON_PROFILES ||--o{ INTERACTION_RECHECK_RECORDS : "互动复检" + PERSON_PROFILES ||--o{ IM_INTERACTION_RECORDS : "IM" + PERSON_PROFILES ||--o{ IM_FLOW_TAGS : "IM标签" + PERSON_PROFILES ||--o{ EDM_MESSAGE_EVENTS : "EDM" + PERSON_PROFILES ||--o{ EDM_USER_BEHAVIOR_PROFILES : "EDM画像" + PERSON_PROFILES ||--o{ APP_TOUCH_EVENTS : "APP" + PERSON_PROFILES ||--o{ TEL_CALL_RECORDS : "TEL" + PERSON_PROFILES ||--o{ SUPPORT_TICKETS : "工单" + PERSON_PROFILES ||--o{ SUPPORT_FOLLOWUPS : "跟进" + PERSON_PROFILES ||--o{ REVIEW_SUBMISSION_RECORDS : "评价提交" + PERSON_PROFILES ||--o{ MANUAL_REVIEW_TASKS : "人工复核" + REVIEW_SUBMISSION_RECORDS ||--o{ REVIEW_DISPLAY_CHECKS : "展示核验" + SUPPORT_TICKETS ||--o{ SUPPORT_ASSIGNMENT_LOGS : "分配" + RISK_CASES ||--o{ BLACKLIST_ENTITIES : "同步" + AMAZON_REFUND_RECORDS ||--o{ REFUND_MATCH_RESULTS : "退款比对" + OA_REFUND_RECORDS ||--o{ REFUND_MATCH_RESULTS : "退款比对" + EXEMPTION_PLANS ||--o{ EXEMPTION_PLAN_TASKS : "任务" + EXEMPTION_PLAN_TASKS ||--o{ CREATOR_CONTENT_RECORDS : "内容" + EXEMPTION_PLANS ||--o{ EXEMPTION_RESULT_SNAPSHOTS : "结果" + REVIEW_PLANS ||--o{ PLAN_TASK_LINKS : "计划任务" + SHIFT_SCHEDULES ||--o{ SUPPORT_TICKETS : "排班分配" + ATTENDANCE_RECORDS }o--|| SHIFT_SCHEDULES : "出勤关联" +``` + +--- + +# 第五部分：数据流转 + +## 21. 关键流转时序 + +| 阶段 | 读（查） | 写 | 说明 | +| --- | --- | --- | --- | +| 真实人识别 | person_identity_links（已有线索） | person_profiles + person_identity_links（新线索） | 每次互动都先跑 | +| 画像生成 | person_profiles + 七组画像数据 + 各渠道事件 | person_feature_snapshots | 定期或触发式刷新 | +| 人群生成 | person_feature_snapshots + person_quota_ledgers + risk_signals | audience_snapshots + audience_exclusions + quota_reservations | 快照当下状态 | +| 路由决策 | audience_snapshots + 用户状态 + 渠道可达性 | channel_route_decisions + channel_dedup_records | 选定渠道+去重 | +| 渠道发送 | channel_route_decisions + quota_reservations + risk_signals（最新） | 各渠道事件表 | 发送前终校 | +| 用户回应 | person_identity_links + person_quota_ledgers + risk_signals（全部重读） | interaction_recheck_records + 渠道事件表更新 + im_flow_tags | 每次互动复检留痕 | +| 评价提交 | person_quota_ledgers（累计额度） | review_submission_records + person_quota_ledgers（+1） | 提交即计12 | +| Amazon 展示确认 | review_submission_records | review_display_checks + 计划完成度更新 | 展示才计完成 | +| 退款/返款 | amazon_refund_records + oa_refund_records | refund_match_results + risk_signals（如命中） | 双重退款检测 | + +## 22. 每次有效互动的标准写入顺序 + +```mermaid +flowchart LR + A["互动发生"] --> B["解析真实人
读 person_identity_links"] + B --> C["生成/更新上下文卡
写 contact_context_snapshots"] + C --> D["读取最新额度
读 person_quota_ledgers"] + D --> E["执行风险判断
读 risk_signals + blacklist"] + E --> F["写 interaction_recheck_records"] + F --> G{"结果"} + G -->|正常| H["继续业务"] + G -->|预警| I["继续 + 高亮提醒"] + G -->|拦截| J["暂停 + 转人工/风险链路"] +``` + +适用场景：主动推送后回复、用户再次联系、补充订单号、客服回访、TEL 来电、退款/返款/再次触达前。 + +--- + +# 第六部分：设计决策与边界 + +## 23. 对象分类 + +| 类型 | 对象 | 原因 | +| --- | --- | --- | +| **正式事务表** | `person_profiles`、`person_identity_links`、`support_tickets`、`support_followups`、`risk_cases`、`review_submission_records`、`quota_reservations` | 需要增删改和业务状态流转 | +| **不可变事件表** | `im_interaction_records`、`edm_message_events`、`app_touch_events`、`tel_call_records`、`amazon_refund_records`、`oa_refund_records`、`support_assignment_logs`、`im_flow_tags` | 事实一旦发生不应被覆盖 | +| **快照表** | `person_feature_snapshots`、`contact_context_snapshots`、`audience_snapshots`、`support_performance_snapshots`、`exemption_result_snapshots` | 需要保留某一时点状态以便复盘 | +| **决策表** | `channel_route_decisions`、`channel_dedup_records`、`interaction_recheck_records`、`refund_match_results` | 保存系统当时为什么这样判断 | +| **聚合画像** | `edm_user_behavior_profiles` | 由事件聚合推导，定期刷新 | +| **可先做视图** | 当前剩余额度、当前风险摘要、当前上下文卡、当前人群统计看板、当前绩效看板 | 可由底层对象实时聚合 | + +### 判断法 + +| 问题 | 如果答案是"是" | +| --- | --- | +| 后续需要追责"当时为什么这么做"吗 | 建正式表或决策表 | +| 数据后来会变，但历史判断不能跟着变吗 | 建快照 | +| 只是为了当前页面展示吗 | 优先做视图 | +| 一旦发生就不该被覆盖吗 | 建事件表 | + +## 24. 当前还不能只靠"老表扩列"解决的事情 + +| 问题 | 为什么不能只扩列 | +| --- | --- | +| 一个真实人多个账号 | `users` 是账号级，不是人级 | +| 每次互动重判 | 不是用户静态属性，而是一次次决策事实 | +| 人群为什么入选/排除 | 不是计划表字段，而是某一批次结果 | +| 多计划并发占额度 | 需要独立预占 | +| 用户提交与展示拆分 | 不是一个布尔值能表达 | +| 退款比对 | 需要两个来源事实加一个比对结果 | +| 客服上下文 | 不是工单表本身，而是跨源聚合视图+快照 | + +## 25. 当前可以先不做成物理表的内容 + +| 内容 | 当前建议 | +| --- | --- | +| 当前剩余额度 | 先由 `person_quota_ledgers + quota_reservations` 聚合成视图 | +| 当前风险摘要 | 先由 `risk_signals + risk_cases + blacklist_entities` 聚合成视图 | +| 当前客服上下文卡 | 前台读当前视图，关键接入动作时写 `contact_context_snapshots` | +| 当前人群统计看板 | 先基于 `audience_snapshots / exclusions` 聚合 | +| 当前绩效看板 | 先基于工单、通话、跟进事件聚合，后续再沉淀快照 | + +## 26. 外部数据引用原则 + +| 外部数据 | 所属系统 | USER 当前做法 | +| --- | --- | --- | +| Amazon 订单全量明细 | Amazon API/报表 | 导入关键字段，不把 USER 做成全量订单数仓 | +| JOYHUB 用户行为明细 | APP/用户系统 | 取摘要或增量同步，用于画像与上下文 | +| 黑名单全量数据 | 黑名单系统 | 引用并缓存关键维度，不重复建设 | +| JOYCOLLAB 全量内容与带货明细 | JOYCOLLAB | 同步 USER 闭环所需结果摘要 | +| 财务/人事原始表 | 财务/人事系统 | 导入必要摘要，不替代源系统 | + +## 27. 涉密字段处理 + +| 涉密字段 | 建议存储 | 建议查询 | +| --- | --- | --- | +| 订单号 | 哈希索引 + 加密原值 | 常规用哈希匹配 | +| 邮箱 | 哈希索引 + 脱敏展示 | 普通页面不暴露明文 | +| 电话 | 哈希索引 + 加密原值 | 仅授权角色可揭示 | +| 姓名/地址 | 标准化值 + 哈希/指纹 | 归并与风险用指纹 | +| 设备号 | 哈希索引 | 归并/风险用哈希 | +| IP | 脱敏存储 | 仅用于弱关联 | +| 收款信息 | 加密存储 | 财务/风险授权查看 | +| 返款金额/提成 | 权限控制 | 财务角色优先 | + +## 28. 快照策略 + +| 快照对象 | 生成时机 | 保留策略 | +| --- | --- | --- | +| `person_feature_snapshots` | 定期刷新 + 人群生成前触发 | 保留最近 N 版 + 每次人群生成引用的版本 | +| `contact_context_snapshots` | 用户接入/工单创建/拨打前/风险升级 | 每次生成新快照，保留全量历史 | +| `audience_snapshots` | 人群生成时 | 每次计划保留 | +| `edm_user_behavior_profiles` | EDM 画像定时刷新 | 按刷新批次保留 | +| `support_performance_snapshots` | 每日/每周/每月 | 按周期聚合保留 | +| `exemption_result_snapshots` | 免评执行阶段性同步 | 按结果周期保留 | + +--- + +# 第七部分：谁写谁读 + +## 29. 读写矩阵 + +| 对象 | 主要写入方 | 主要读取方 | 依赖它的动作 | +| --- | --- | --- | --- | +| `person_profiles` | 身份归并服务 | 用户运营、客服、风险 | 所有真实人级判断 | +| `person_identity_links` | 身份归并服务 | 风险、客服、订单核验 | 真实人识别 | +| `person_feature_snapshots` | 画像任务 | 人群生成、客服 | 画像筛选 | +| `contact_context_snapshots` | 上下文聚合服务 | 客服、用户运营 | 接入处理 | +| `person_quota_ledgers` | 额度服务 | 人群生成、渠道、客服 | 4/4/12 判断 | +| `quota_reservations` | 人群/计划服务 | 渠道、额度服务 | 发送前拦截 | +| `audience_snapshots` | 人群生成服务 | 计划、复盘 | 解释入选 | +| `channel_route_decisions` | 路由服务 | 推送、复盘 | 选渠道 | +| `interaction_recheck_records` | 互动复检服务 | 客服、风险、审计 | 决定继续/拦截 | +| `review_submission_records` | 客服/IM/TEL | 额度、计划、客服 | 计入12 | +| `review_display_checks` | 运营/系统 | 计划、ASIN看板 | 计入完成 | +| `refund_match_results` | 退款比对服务 | 风险、客服、财务 | 拦截双重退款 | + +--- + +## 30. 还需要确认但不阻塞第三步的事项 + +| 事项 | 影响 | +| --- | --- | +| Amazon 订单同步频率最终是否为 10 分钟 | 影响订单/退款数据新鲜度 | +| 黑名单系统最终通过 API、表格还是消息同步 | 影响 `blacklist_entities` 同步方式 | +| Amazon Profile ID 是否稳定获取 | 影响强关联覆盖率 | +| APP 设备型号能否拿到具体型号还是只到类型 | 影响客服展示颗粒度 | +| 年龄字段来自注册资料还是推断 | 影响画像可信度 | +| KOC/KOL 结果同步周期 | 影响免评结果快照频率 | + +--- + +## 31. 第四步入口 + +1. **把数据对象转成逻辑 ER 图**：以 §20 的 Mermaid ER 图为基础，明确主键、外键、1对多/多对多关系，区分复用旧表和新增表。 +2. **按关键链路补接口读写**： + 1. 真实人识别与上下文链路 + 2. 人群/额度/路由链路 + 3. 互动复检/风险链路 + 4. 评价提交/展示与退款比对链路 + 5. 免评结果链路 +3. **回到页面，把每一个点击绑定到明确的数据读写**。 + +--- + +## 32. 本版结论 + +v3 以 Codex v1.1 完整字段字典为主骨架，补入 v2 的流转时序表、写入顺序图和快照策略，形成最终统一主稿： + +1. 用 **真实人** 统一账号、订单、设备和风险 +2. 用 **画像快照** 解释人群生成 +3. 用 **额度台账+预占** 保护 4/4/12 规则（跨账号合并） +4. 用 **路由决策+去重记录** 控制多渠道协同 +5. 用 **互动复检记录** 落实"每次有效互动都重判" +6. 用 **退款比对结果** 识别双重退款 +7. 用 **评价提交记录+展示核验** 拆开用户事实和平台结果 +8. 用 **免评计划→任务→内容→结果快照** 让 KOC/KOL 闭环完整进入 USER 系统 diff --git a/wishfulfilled-wiki/05_需求文档/20260517_USER评价业务闭环主流程与后续工作基线_v1.2.md b/wishfulfilled-wiki/05_需求文档/20260517_USER评价业务闭环主流程与后续工作基线_v1.2.md new file mode 100644 index 0000000..8aa5d37 --- /dev/null +++ b/wishfulfilled-wiki/05_需求文档/20260517_USER评价业务闭环主流程与后续工作基线_v1.2.md @@ -0,0 +1,577 @@ +# USER 评价业务闭环主流程与后续工作基线 v1.2 + +## 文件信息 + +- 文件名称：`20260517_USER评价业务闭环主流程与后续工作基线_v1.2.md` +- 项目路径：`C:\XCODE\USER` +- 当前版本：`v1.2` +- 最近更新：`2026-05-17` +- 前一版本：`20260517_USER评价业务闭环主流程与后续工作基线_v1.1.md` +- 文件目的：在既有销售到评价闭环基线上，补入真实人识别、测评 / 免评额度、用户历史上下文、IM / EDM / TEL / 客服细化口径，作为新版第二步和后续数据流设计的统一依据。 +- 适用范围：当前阶段的 Amazon 业务闭环设计；如后续扩展到独立站或非 Amazon 评价体系，需要在本文件基础上另行增补。 +- 使用方式：下一次继续本项目时，先读取本文件，再读取 `20260517_USER评价业务闭环_共用能力图与渠道专属流程_v2.2.md`，不要再从旧版页面链路重新推导业务主干。 + +--- + +## 版本记录 + +| 版本 | 日期 | 说明 | +| --- | --- | --- | +| v1 | 2026-05-17 | 首次固化销售到评价完成的 USER 业务闭环主流程 | +| v1.1 | 2026-05-17 | 将免评改为独立闭环；明确每次有效互动都要重新做身份与风险判断；明确当前版本不单列商家角色 | +| v1.2 | 2026-05-17 | 补入用户历史与设备上下文、真实人级 `测评4 / 免评4 / 累计真实提交评价12` 规则、IM / EDM / TEL / 客服新增细节，并把第二步入口改为“共用能力 + 渠道专属流程” | + +--- + +## 1. 已确认目标 + +1. 系统要支持 USER 部门工作，而不是只做一个回评记录工具。 +2. 业务流必须从“销售发生 / 需求形成”开始，而不是从“推送”开始。 +3. Amazon 运营既可以人工提需求，系统也可以因 Listing 健康或评价缺口自动触发需求。 +4. 用户运营是“需求评估 + 计划调度中心”，负责把需求转成可执行计划并跟踪结果。 +5. 计划类型必须正式保留： + - 推新计划 + - 回评计划 + - 免评计划 +6. `免评计划` 不是边缘例外，而是需要正式保留的关键业务类型；其与 KOC / KOL、社媒带货、站外流量和 Amazon 权重有关。 +7. 用户提交评价与系统确认评价完成必须拆成两个节点： + - 用户已真实提交评价 + - Amazon 已展示 / 系统已确认计入计划完成 +8. `真实人` 是后续额度、风险、历史和用户画像的核心对象，不应只围绕某个 JOYHUB ID、邮箱或 Amazon 账号看用户。 +9. 已确认的额度规则为： + - 同一真实人每月最多参与 `4 次测评` + - 同一真实人每月最多参与 `4 次免评` + - 同一真实人累计最多计入 `12 个真实提交的评价` +10. `12` 的计数时点是 `用户真实提交评价`，不是 `Amazon 展示评价`。 +11. 每次有效互动都要重新做身份、历史、额度和风险判断；主动推送后的回复也不例外。 +12. 客服接入时必须能快速看到用户历史、订单历史、设备上下文、既往风险和当前提醒，而不是只看到当前对话。 +13. 后续系统设计顺序已经确定： + 1. 先定业务流 + 2. 再做点击操作模拟 + 3. 最后根据业务需求整合现有数据，形成新的数据流和中间表需求 + +--- + +## 2. 当前边界与资料依据 + +### 2.1 当前纳入范围 + +- Amazon 业务 +- 销售到评价闭环 +- 推新、回评、免评 +- IM、EDM、APP、TEL、KOC / KOL +- 售后接入 +- 客服执行与客服管理支撑 +- 黑名单与诈骗风险 +- ASIN 健康回流 + +### 2.2 当前不作为本版主流程展开的内容 + +- 独立站全链路 +- 完整 BI / 财务 / ROI 系统 +- 完整 KOC / KOL 结算系统 +- 所有历史后台页面逐页重构 +- 数据库最终物理设计 + +### 2.3 资料依据 + +本文件基于以下材料整理： + +1. `C:\XCODE\USER\评价业务流闭环项目架构文档_v0.8.docx` +2. `C:\XCODE\USER\docs\evaluation-business-architecture.md` +3. `C:\XCODE\USER\docs\project-phase-one-plan.md` +4. `C:\XCODE\USER\output\docs\20260503_USER后台ERP一期功能与页面设计_v4.md` +5. `C:\XCODE\USER\output\docs\20260503_USER后台ERP自动推送与计划状态机_v4.md` +6. `C:\XCODE\USER\output\docs\20260503_USER后台ERP一期页面原型说明_v4.md` +7. `C:\XCODE\USER\output\docs\20260503_USER后台ERP_MVP角色首页UI规划_v1.md` +8. `C:\tcode\飞书\飞书聊天记录库\cloud_files` 中当前主原型 HTML 与 `客服执行.html` +9. `C:\Users\wu_zh\Downloads\20260407-法国诈骗问题（已扩散美国）.docx` +10. `C:\Users\wu_zh\Desktop\表头.xlsx` +11. `C:\Users\wu_zh\Downloads\IM 推送业务流.mm` +12. `C:\Users\wu_zh\Downloads\后台回评工作流对接事项.docx` +13. `C:\Users\wu_zh\Downloads\客服相关模块.docx` +14. `C:\Users\wu_zh\Downloads\电话业务流程知识库.docx` +15. 用户在当前对话中补充确认的业务规则 + +若历史资料与当前对话确认口径冲突，以当前对话中最新确认口径为准。 + +--- + +## 3. 角色与职责 + +| 角色 | 核心职责 | +| --- | --- | +| Amazon 运营 | 依据销售、ASIN、评价目标提出推新 / 回评 / 免评需求 | +| Amazon 运营总监 | 审批相关计划，确认优先级与业务必要性 | +| 品牌运营 | 负责品牌推广、站外节奏和与用户运营 / 内容运营协同 | +| 内容运营 | 承接社区广告、APP 广告位、内容流量等侧向支持 | +| 用户运营 | 评估需求、生成计划、分配资源、协调渠道、跟踪结果 | +| 用户运营负责人 / 组长 | 复核计划、分配组员、处理重点风险和异常 | +| 菲律宾客服负责人 | 关注工单压力、分配客服组、处理升级工单、查看绩效 | +| 菲律宾客服组长 | 分配组内工单、复核升级、控制逾期和重点工单 | +| 菲律宾客服组员 | 实际接待、电话沟通、记录、回复、回访、提交疑似诈骗 | +| 风险 / 黑名单相关人员 | 接收诈骗疑似、复核、同步黑名单、维护风险口径 | +| KOC / KOL 运营 | 承接站外带货、合作关系、内容和导购协同 | + +当前版本不单列“商家 / 商家运营”角色。这里的“商家”如出现，均按 Amazon 卖家侧语义理解，由 Amazon 运营承接；品牌商当前也只纳入 Amazon 内评价相关协同。 + +--- + +## 4. 总体业务结构 + +### 4.1 主流程 + +```mermaid +flowchart LR + A["销售发生 / ASIN销售数据形成"] --> B["需求触发"] + B --> B1["Amazon运营人工提需求"] + B --> B2["系统按评价缺口或Listing健康自动触发"] + B1 --> C["用户运营评估需求"] + B2 --> C + C --> D["形成业务计划"] + D --> D1["推新计划"] + D --> D2["回评计划"] + D --> D3["免评计划"] + D1 --> E["规则 / 风险 / 额度复核"] + D2 --> E + D3 --> E + E --> F["审批通过"] + F --> G["执行拆解"] + G --> H1["评价型执行闭环"] + G --> H2["免评型执行闭环"] + H1 --> I1["IM / EDM / APP / TEL / 客服协同"] + I1 --> J1["用户被触达或主动进入"] + J1 --> K1["每次有效互动均重做身份 / 历史 / 额度 / 风险核验"] + K1 --> L1["服务 / 售后 / 跟进"] + L1 --> M1["用户真实提交评价"] + M1 --> N1["计入真实人累计评价额度"] + N1 --> O1["Amazon是否展示 / 系统是否确认完成"] + O1 --> P["结果回流"] + H2 --> I2["KOC / KOL为核心，IM / EDM / APP等协同参与"] + I2 --> J2["内容发布 / 站外引流 / 带货执行"] + J2 --> K2["跟踪点击、Code、订单、转化与权重结果"] + K2 --> P + P --> Q["更新ASIN健康、计划完成度、用户画像、流量结果、风险记录"] + Q --> C +``` + +### 4.2 五个业务层 + +| 业务层 | 说明 | +| --- | --- | +| 经营层 | 销售、ASIN、需求、品牌 / 内容 / KOC-KOL 侧影响 | +| 计划层 | 推新、回评、免评、审批、规则、额度、风险 | +| 执行层 | IM、EDM、APP、TEL、客服工单、KOC / KOL 协作 | +| 服务与身份层 | 用户接入、真实人归并、订单核验、用户上下文、售后处理 | +| 结果与风险层 | 用户真实提交评价、Amazon 展示确认、免评结果、黑名单、诈骗、结果回流 | + +--- + +## 5. 主流程详细说明 + +| 阶段 | 业务说明 | 必须检查 | 主要输出 | +| --- | --- | --- | --- | +| 1. 销售与需求形成 | 销售发生后，Amazon 运营根据目标或系统根据健康度触发需求 | 销售、ASIN、评分、评价缺口、历史计划 | 新需求 | +| 2. 用户运营评估 | 判断需求是否成立、是否可做、优先级如何 | ASIN 健康、目标数量、历史完成、当前资源、风险 | 已确认需求 / 待补充 / 驳回 | +| 3. 计划生成 | 将需求转为推新、回评或免评计划 | 用户池、渠道容量、目标、周期 | 计划草案 | +| 4. 计划复核与审批 | 对计划做规则、额度和风险复核，再进入审批 | 黑名单、频控、渠道风险、真实人额度、审批权限 | 已批准计划 | +| 5. 执行拆解 | 把计划拆成渠道任务和人工任务 | 可触达用户、素材、客服负载、KOC / KOL协作 | 推送任务 / TEL任务 / 客服工单 / 协作任务 | +| 6A. 评价型执行 | 推新、回评进入用户触达、服务与评价链路 | 真实人、订单、历史、额度、风险、售后情况 | 当前处理路径 | +| 6B. 免评型执行 | 免评以 KOC / KOL 与站外流量为核心，同时可由 IM / EDM / APP 等协同参与 | 合作对象、内容、Code、渠道、素材、节奏、免评额度 | 内容任务 / 引流任务 / 带货任务 | +| 7A. 用户真实提交评价 | 记录用户是否已经实际提交评价 | 用户反馈、提交证据、对应计划、真实人累计额度 | 已提交评价事实 | +| 7B. 免评结果跟踪 | 记录免评计划的执行结果 | 内容发布、点击、Code、订单、转化、销量、权重变化 | 免评执行结果 | +| 8. 评价确认 | 区分用户提交与 Amazon 展示结果 | Amazon 是否展示、是否能核验、是否属本计划 | 计入完成 / 待确认 | +| 9. 结果回流 | 把评价结果与免评结果重新反馈给经营与计划层 | 计划完成、ASIN 健康、流量结果、风险变化、用户标签 | 新一轮决策输入 | + +--- + +## 6. 关键业务支线 + +### 6.1 主动触达支线 + +```mermaid +flowchart LR + A["计划通过"] --> B["筛选可触达用户池"] + B --> C["真实人识别 + 人群画像 + 额度校验"] + C --> D["渠道分配"] + D --> D1["IM"] + D --> D2["EDM"] + D --> D3["APP"] + D --> D4["TEL"] + D1 --> E["用户回应"] + D2 --> E + D3 --> E + D4 --> E + E --> F["每次回应都重做身份 / 历史 / 额度 / 风险核验"] + F --> G["订单核验"] + G --> H["服务 / 跟进"] + H --> I["用户真实提交评价"] +``` + +#### 关键规则 + +1. IM、EDM、APP 可自动化；TEL 属于人工执行渠道。 +2. `IM` 需要识别用户分层、绑定玩具、设备、测评 / 免评额度和标签流转。 +3. `EDM` 需要识别最近打开、最近回复、点击评论链接但未回复、月度收信次数、最近 3 / 5 次 0 打开、邮箱类型、退订和硬退信。 +4. 计划生成前必须先检查： + - 用户是否可触达 + - 是否命中风险 + - 是否超频 + - 是否符合站点 / 国家 / 产品目标 + - 是否接近或达到真实人额度上限 +5. 用户回应后，不能沿用上一次判断结果，必须重新检查当前身份、订单、设备、地址、历史、额度与风险状态。 + +### 6.2 免评执行支线 + +```mermaid +flowchart LR + A["免评计划通过"] --> B["拆解执行方案"] + B --> C1["KOC / KOL协作"] + B --> C2["IM / EDM / APP辅助触达"] + B --> C3["内容 / 运营协同"] + C1 --> D["内容发布 / Code使用 / 站外引流"] + C2 --> D + C3 --> D + D --> E["跟踪点击、跳转、Code、订单、转化、销量与权重变化"] + E --> F["结果回流到ASIN健康与后续计划"] +``` + +#### 关键规则1 + +1. 免评计划不是评价型计划的弱化版本，而是以站外流量、带货、销量和权重结果为终点的独立闭环。 +2. KOC / KOL 是免评计划的核心执行通道，但 IM、EDM、APP 等也可以参与协同。 +3. 同一真实人每月最多参与 `4 次免评`；免评额度也要做预警、预占和拦截。 +4. 免评计划不以“用户提交评价”作为完成条件，必须另行跟踪内容发布、Code、点击、订单、转化、销量和权重变化。 +5. 如果免评执行过程中发生用户互动、售后或返款等行为，仍须进入统一的身份与风险判断机制。 + +### 6.3 被动售后与 TEL 支线 + +```mermaid +flowchart LR + A["用户主动联系 / 电话呼入"] --> B["接入即预查"] + B --> C["识别来源、身份、订单、历史、风险"] + C --> D{"是否有售后问题"} + D -->|有| E["问题分类与解决方案"] + E --> F["确认是否解决 / 是否满意"] + F --> G["满意后进入回评 / 测评邀请"] + D -->|无| H["确认无其他需求"] + H --> I["可进入测评邀请"] + G --> J["记录电话 / 工单 / 后续跟进"] + I --> J +``` + +#### 关键规则2 + +1. TEL 当前至少包含两类入口： + - 计划生成后的人工外呼任务 + - 用户从 Amazon 页面或说明书主动呼入 +2. 有售后问题时，必须先解决售后，再谈评价或测评邀请。 +3. 电话中需要尽量确认： + - 购买平台 + - 订单号 + - 产品型号 / 款式 / 颜色 + - 购买时间 + - 问题类型 + - 是否有图片、视频或其他凭证 +4. 每通电话结束后，至少要记录： + - 来电时间 + - 来源 + - 联系方式 + - 订单号 + - 问题类型和描述 + - 处理方案 + - 是否已解决 + - 是否需要后续跟进 + - 是否邀请测评 / 回评 + - 用户是否接受 +5. 当前电话业务的核心是： + - 自然单回评转化 + - 充分利用电话用户的测评资源 + +### 6.4 风险 / 诈骗拦截支线 + +```mermaid +flowchart LR + A["新订单同步 / 主动触达回应 / 用户接入 / 退款申请 / 再次跟进"] --> B["重新做风险识别"] + B --> C{"是否命中强关联"} + C -->|是| D["直接进入高风险或黑名单链路"] + C -->|否| E{"是否命中弱关联"} + E -->|是| F["进入高风险观察 + 人工复核"] + E -->|否| G["继续正常流程"] + D --> H["拦截自动退款、继续推送、自动放行"] + F --> H + H --> I["提醒客服 / 用户运营 / 审核人员"] +``` + +#### 已确认风险口径 + +| 风险类型 | 关联项 | 处理原则 | +| --- | --- | --- | +| 强关联 | 邮箱、设备号、电话、收件人姓名+地址、订单号、聊天记录、Profile ID、收款信息 | 一旦命中，可直接进入高风险或黑名单链路 | +| 弱关联 | IP 单独命中、姓名单独命中、同址异名 | 进入高风险观察，不直接认定诈骗 | + +#### 已确认业务问题 + +1. 当前真实事故中存在“双重退款”风险： + - APP / OA 已退款 + - 用户又向 Amazon 申请退款 +2. 需要把 Amazon 退款与 OA 返款自动比对。 +3. 高风险用户一旦标记，支付 / 返款需要人工复核。 +4. 客服、审核、退款等环节必须都能看到风险提醒。 +5. 非 APP 用户如果直接走邮件退款，因缺少设备、注册邮箱等维度，风险识别能力明显下降。 +6. 风险判断不是一次性的接入动作，而是每次有效互动都要重新执行。 + +### 6.5 客服工单与客服管理支线 + +```mermaid +flowchart LR + A["用户消息进入 / 推送转人工 / 售后触发 / 风险触发"] --> B["生成工单"] + B --> C["按班次、在线状态、当前负载自动分配"] + C --> D["客服处理"] + D --> E{"处理结果"} + E -->|等待用户| F["等待用户回复"] + E -->|等待内部| G["等待内部协同"] + E -->|答应配合| H["生成后续跟进"] + E -->|疑似诈骗| I["转风险链路"] + E -->|已解决| J["关闭工单"] + D --> K["回复效率 / 转化 / 目标完成统计"] +``` + +#### 工单与管理事实 + +1. 客服相关模块不只包括工单，还包括： + - 出勤管理 + - 排班管理 + - 回复效率统计 + - 转化统计 + - 目标管理 +2. `排班` 与 `在线状态` 会直接影响自动分配。 +3. `工单状态`、`答应配合状态`、`风险状态` 必须拆开存。 +4. 客服转化要区分： + - RSO 回评 + - RDO 测评 +5. 回复效率至少要统计： + - 回复用户数 + - 处理工单数 + - 发送消息数 + - 平均 / 中位数 / 最大 / 最小首次回复时长 +6. 转化统计至少要看： + - 登记订单数 + - 获取评价数 + - 评价完成率 +7. 主管需要看到出勤、排班、绩效、目标完成和工单分配，而不是只看单个会话。 + +--- + +## 7. 真实人识别、用户上下文与额度规则 + +### 7.1 真实人识别原则 + +1. 当前系统不应只围绕 `JOYHUB ID` 看用户，而应同时围绕： + - 账号 + - 订单 + - 实际收件人 + - 设备 + - 联系方式 + - 风险关系 +2. 如果用户在 JOYHUB 内提交订单，则订单可直接关联到当前 JOYHUB ID。 +3. 如果用户通过邮件联系： + - 先问是否有 JOYHUB ID + - 再用注册邮箱与 JOYHUB ID 做关系查询 +4. 如果用户通过电话联系： + - 先确认是否注册 APP + - 结合电话、订单、收件人、地址、设备、邮箱继续识别 +5. 非 APP 用户如需继续参与相关流程，应优先引导注册 APP，再继续后续动作。 + +### 7.2 实际收件人判定 + +| 情况 | 处理原则 | +| --- | --- | +| 标准化后姓名 + 地址完全一致 | 直接认为是同一实际收件人 | +| 地址一致但姓名不同 | 只认为存在家庭 / 关联风险，不直接判定同一人 | +| 邮箱不同、JOYHUB ID 不同 | 不能单独否定“同一实际人” | +| 订单号命中历史异常 | 应立即拉出历史上下文和风险记录 | + +### 7.3 用户上下文卡 + +客服和用户运营在必要节点应能看到： + +| 字段组 | 例子 | +| --- | --- | +| 当前身份 | JOYHUB ID、邮箱、电话、真实人 ID、当前订单 | +| 历史交易 | 历史订单、最近购买、退款 / 返款、目标 ASIN 购买情况 | +| 历史服务 | 历史工单、聊天、电话、承诺、提醒、关闭原因 | +| 历史风险 | 黑名单、关联账号、疑似诈骗、双重退款、异常订单 | +| 当前设备 | 设备号摘要、设备型号 / 类型、系统版本、APP 版本、最近设备变化 | +| 触达历史 | IM / EDM / APP / TEL 最近触达、回复、退订、投诉 | + +### 7.4 额度规则 + +| 规则 | 统计对象 | 计数口径 | +| --- | --- | --- | +| 月度测评最多 4 次 | 真实人 | 已完成 + 进行中 + 已预占 | +| 月度免评最多 4 次 | 真实人 | 已完成 + 进行中 + 已预占 | +| 累计真实提交评价最多 12 个 | 真实人 | 用户真实提交评价后立即计数 | + +### 7.5 额度控制原则 + +1. 额度判断必须放在 `真实人识别` 之后，而不是只看单一账号。 +2. 系统不能等到真正超限才提示，必须在接近上限时提前预警。 +3. 一旦 `已用 + 进行中 + 已预占 + 本次拟发送` 会导致超限，就不能进入自动推送。 +4. `Amazon 未展示` 不影响 12 次累计额度，因为口径已经确认按 `真实提交` 计数。 + +--- + +## 8. 渠道专属补充事实 + +### 8.1 IM + +- 用户需要分层：未参与过、参与过、长期测评人。 +- 触发条件包括注册 App、绑定玩具、识别绑定产品。 +- 需要校验设备 ID、黑名单、绑定产品、额度与标签。 +- 用户提交订单号、返款账号、评论截图 / 链接后，要继续做订单核验和资格登记。 + +### 8.2 EDM + +- EDM 不是简单“发邮件”，而是独立的筛选与节奏引擎。 +- 需要支持： + - 最近打开时间 + - 最近回复时间 + - 打开次数 + - 最近 3 / 5 次推送 0 打开 + - 点击评论链接但未回复时长 + - 单月收信次数 + - 各邮件类型发送次数 + - 邮箱后缀标签 + - 国家站点 + - 退订、硬退信、风险用户、黑名单、OA 无资格用户排除 + +### 8.3 APP + +- APP 侧至少要纳入： + - 注册邮箱 + - 设备号 + - 设备型号 / 类型 + - APP 版本 + - 系统版本 + - 用户行为数据 + - 绑定玩具 + - 活跃与点击行为 +- APP 不只是触达渠道，也是身份识别、设备变化和行为画像的重要来源。 + +### 8.4 TEL + +- TEL 同时承担主动外呼和被动来电。 +- 其价值不只是“打电话”，而是： + - 解决售后 + - 捕捉自然单回评机会 + - 充分利用电话用户的测评资源 + +--- + +## 9. 评价结果规则 + +### 9.1 必须拆开的两个节点 + +```mermaid +flowchart LR + A["用户已真实提交评价"] --> B["计入真实人累计评价额度"] + B --> C{"Amazon是否展示 / 是否可核验"} + C -->|展示或可核验| D["计入计划完成"] + C -->|未展示 / 暂不可核验| E["保留用户已提交事实"] + E --> F["进入待确认 / 异常观察"] + D --> G["更新ASIN健康与计划完成度"] +``` + +### 9.2 原因 + +1. 用户可能确实已经提交评价。 +2. Amazon 可能因为其他原因不展示该评价。 +3. `额度计数` 与 `计划完成确认` 不是同一个业务事实。 +4. 如果系统只保留一个“评价完成”状态，会把平台展示问题错误归因给执行人员或用户。 + +--- + +## 10. 贯穿全程的数据检查点 + +| 检查点 | 发生时机 | 核心检查 | +| --- | --- | --- | +| 经营检查 | 需求形成前 | 销售、ASIN、评分、评价缺口、历史计划 | +| 计划检查 | 生成计划前 | 人群、渠道、容量、规则、黑名单 | +| 画像检查 | 生成人群时 | 国家、站点、性别、年龄、绑定玩具、产品关系、活跃、历史行为 | +| 额度检查 | 生成人群、发送前、继续推进前 | 测评 4、免评 4、累计真实提交 12、进行中与已预占 | +| 身份检查 | 首次接入与每次有效互动时 | JOYHUB、邮箱、电话、设备、订单、地址、历史记录 | +| 互动复检 | 主动触达回应、再次联系、补充订单号、客服回访时 | 关键属性是否变化，是否出现新订单、新地址、新设备、新返款记录 | +| 风险检查 | 每次有效互动、退款、返款、继续推送前 | 双重退款、强弱关联、黑名单、历史异常 | +| 结果检查 | 评价提交与确认后 | 首评 / 回评、是否属本计划、是否展示、ASIN 健康变化 | + +--- + +## 11. 第二步的新入口 + +第二步不再按旧版页面链路推进，而改成： + +### 11.1 共用能力图 + +1. 真实人识别与用户上下文卡 +2. 人群生成与画像拆解 +3. 额度与频控控制 +4. 每次有效互动复检 +5. 风险与黑名单 + +### 11.2 渠道 / 模块专属流程图 + +1. IM +2. EDM +3. APP +4. TEL +5. 客服工单 +6. 客服管理支撑 +7. 评价完成 +8. 免评执行 + +### 11.3 每张图都必须回答 + +- 进入条件是什么 +- 要先查什么 +- 如何判断 +- 写入什么 +- 状态怎么变 +- 何时提醒 +- 何时拦截 +- 何时转人工 + +--- + +## 12. 下一次继续工作时的直接提示 + +1. 先读取本文件。 +2. 不要重新讨论“是否从销售开始”“是否保留免评”“评价提交与展示是否拆开”，这些已确认。 +3. 额度口径按当前版本执行： + - 测评每月最多 4 + - 免评每月最多 4 + - 同一真实人累计真实提交评价最多 12 +4. 不要再把风险判断理解成“首次接入才做一次”；每次有效互动都需要重做判断。 +5. 不要再把第二步按页面链路拆；直接进入 `20260517_USER评价业务闭环_共用能力图与渠道专属流程_v2.2.md`。 +6. 旧版 `v1` / `v1.1` 保留为历史版本，不再作为后续主口径。 + +--- + +## 13. 本版结论 + +USER 部门未来系统的核心，不是单独记录“谁评价了”，而是把以下内容放进同一条可追踪闭环中： + +1. 销售与需求 +2. 计划生成与审批 +3. 真实人识别与用户上下文 +4. 测评 / 免评 / 累计评价额度控制 +5. IM / EDM / APP / TEL / 客服协同 +6. 用户身份与订单核验 +7. 售后服务与评价引导 +8. 免评执行与站外流量结果 +9. 用户真实提交评价 +10. Amazon 展示与系统确认 +11. ASIN 健康回流 +12. 风险与黑名单拦截 + +只有这条闭环建立起来，后续的点击设计、页面设计和数据设计才不会彼此脱节。 diff --git a/wishfulfilled-wiki/05_需求文档/README.md b/wishfulfilled-wiki/05_需求文档/README.md new file mode 100644 index 0000000..5ce580c --- /dev/null +++ b/wishfulfilled-wiki/05_需求文档/README.md @@ -0,0 +1,78 @@ +--- +type: requirement_inbox +tags: [需求文档, 需求收集, 知识库更新, Agent] +aliases: [需求文档目录, 需求收集目录, 需求入口] +source: manual +status: active +owner: 产品经理 / 业务主管 +updated: 2026-05 +--- + +# 需求文档 + +本目录用于集中存放后续持续补充的业务需求文档、业务规则文档、流程补充文档和需求变更文档。 + +## 使用方式 + +1. 所有新增需求文档优先放入本目录。 +2. 建议使用 `03_规范与模板/需求说明模板.md` 或 `03_规范与模板/业务规则与需求补充模板.md` 创建文档。 +3. 文档确认有效后，同步更新业务流程索引和 Agent 检索索引。 +4. Agent 回答具体业务需求时，应优先检索本目录。 + +## 推荐命名 + +```text +业务域_需求或规则名称_YYYYMMDD.md +``` + +示例： + +```text +采购_供应商准入规则_20260526.md +库存_出入库审批规则_20260526.md +销售_客户授信额度需求_20260526.md +``` + +## 文档状态 + +每个需求文档建议在 Frontmatter 中维护 `status`： + +| 状态 | 含义 | +|---|---| +| draft | 草稿，尚未确认 | +| reviewing | 评审中 | +| active | 已确认，可作为 Agent 回答依据 | +| deprecated | 已废弃，仅归档参考 | + +## 必填内容 + +每个需求文档至少包含： + +- 需求背景 +- 适用范围 +- 涉及角色 +- 业务规则 +- 业务流程 +- 异常处理 +- 权限要求 +- 验收口径 +- Agent 检索字段 +- 变更记录 + +## 索引维护 + +新增或修改需求文档后，需要同步更新： + +- `05_需求文档/需求文档索引.md` +- `01_业务流程/业务规则索引.md` +- `01_业务流程/业务对象字典.md` +- `04_Agent检索/关键词索引.md` +- `04_Agent检索/同义词表.md` +- `04_Agent检索/来源文件索引.md` + +## 验证流程 + +新增需求文档后，按 `04_Agent检索/知识库持续更新与验证流程.md` 执行验证，并将验证结果记录到： + +- `05_需求文档/需求文档索引.md` +- `01_业务流程/业务补充验证记录.md` diff --git a/wishfulfilled-wiki/05_需求文档/evaluation-business-architecture.md b/wishfulfilled-wiki/05_需求文档/evaluation-business-architecture.md new file mode 100644 index 0000000..017ec5d --- /dev/null +++ b/wishfulfilled-wiki/05_需求文档/evaluation-business-architecture.md @@ -0,0 +1,1280 @@ +# 评价业务流闭环项目架构文档 + +版本：v0.7 +更新时间：2026-04-26 +当前阶段：业务框架搭建与部门业务梳理 + +## 1. 文档目标 + +本文档用于沉淀评价业务流闭环的业务结构、部门职责、核心数据、看板规划和后续项目规划依据。 + +当前重点不是直接进入系统设计，而是先明确： + +- 业务闭环如何运转 +- 各部门在闭环中的职责边界 +- 每个部门需要哪些看板与数据字段 +- APP 与亚马逊运营、品牌运营、内容运营、用户运营、客服运营之间的数据关系 +- 后续项目需要支持哪些管理动作、数据归因和异常预警 + +## 2. 总体业务闭环 + +### 2.1 当前业务主链路 + +亚马逊运营、品牌运营、内容运营负责拉新与引流。 +主要带来曝光和点击，其中当前主要流量来源于亚马逊，小部分开始来源于社媒与网站宣发。 + +↓ + +亚马逊运营负责亚马逊渠道转化与成交，品牌运营负责独立站转化与成交。 + +↓ + +成交后产生订单与成交数据。 + +↓ + +用户运营基于成交用户、绑定用户、活跃用户进行触达推送与索评。 +同时，用户运营或评价运营需要维护 ASIN 健康度，核心依赖回评结果。 + +↓ + +客服运营收集售后问题、用户反馈、负面反馈和评价相关问题，并执行处理与改善动作。 + +↓ + +数据层和管理层进行复盘，调整产品策略、销售策略、推送策略、评价策略和人员分工。 + +### 2.2 闭环中的核心角色 + +| 角色/部门 | 主要职责 | 当前定位 | +|---|---|---| +| 亚马逊运营 | 亚马逊销售、产品销售管理、测评计划需求、免评计划需求、关键词推新、评价健康维护协同 | 当前 APP 用户最主要、最优质来源 | +| 品牌运营 | 独立站品牌宣发、独立站销售转化、社媒品牌形象、品牌推广、新品宣发、活动宣发、粉丝互动 | 品牌侧销售与推广主责方，协助亚马逊扩大品牌市场份额 | +| 内容运营 | 售前社区广告计划、APP 广告位、社区内容分发、帖子加权、新帖推流、固定流量池管理、用户 KOC/KCO 对接 | 配合亚马逊运营与品牌运营做销售前期宣发和社区流量承接 | +| 用户运营 | 测评计划落地、用户触达、IM/EDM/TEL 推送、索评、回评跟进、社区互动、合作伙伴渠道管理 | 系统核心使用者，连接销售需求、用户资源、评价结果与客服执行 | +| 客服运营 | 售后接待、登记、回复、问题完结、负面反馈处理 | 归属用户部门管理，承接售后与评价问题改善 | +| 数据层/管理层 | 指标复盘、异常监控、成本分析、策略调整 | 统一看板、归因和管理决策 | + +## 3. 基础指标与统一数据口径 + +### 3.1 销售核心指标 + +- 销量：日销量、月销量、总销量 +- 绑定数：总用户数、月活、日活、产品绑定用户数 +- 评价数：测评数、回评数、每日每产品评价数、计划所需数量、实际完成数量、差评数 +- 成本：产品成本、返现成本、人力成本、提成、管理成本 + +### 3.2 基础数据维度 + +| 数据维度 | 说明 | +|---|---| +| 渠道影响力 | 衡量各渠道内容、活动、广告位、推送计划的效果 | +| 用户属性 | 发帖人属性、用户行为、性别、活跃状态、风险标记 | +| 时间维度 | 每日、每周、每月、活动周期、新品周期 | +| 产品维度 | 国家、品牌、类目、二级类目、ASIN、产品绑定情况 | +| 漏斗维度 | 曝光、点击、跳转、转化、成交、绑定、触达、评价 | +| 风险维度 | 风险标记用户数、差评数、ASIN 健康风险、异常推送效果 | + +### 3.3 建议统一主键 + +后续系统设计应优先统一以下主键，避免销售、用户、评价、售后数据无法串联： + +- 用户 ID +- 订单 ID +- 产品 ID +- ASIN +- 品牌 ID +- 国家/站点 +- 渠道 ID +- 推送 ID + +## 4. 第一部分：亚马逊运营相关业务 + +### 4.1 亚马逊运营在闭环中的定位 + +亚马逊运营负责在亚马逊平台上进行电商销售工作，是当前 APP 用户最主要、最优质的来源。 + +APP 与亚马逊运营之间的核心关系是： + +1. 亚马逊销售带来订单和用户来源。 +2. APP 需要识别这些购买用户是否下载安装并绑定产品。 +3. 当前每卖出 10 个玩具，约 40% 用户下载并绑定 APP。 +4. 需要亚马逊运营在 Listing、说明书、官网、售后触点等位置配合提升 APP 下载率和产品绑定率。 +5. 亚马逊运营需要提出测评计划、免评计划、推新计划和回评计划相关需求。 +6. APP 内现有用户资源需要根据产品重要级、推新节奏和评价健康度进行分配。 + +### 4.2 亚马逊运营核心业务模块 + +| 模块 | 业务内容 | 与 APP 的关系 | +|---|---|---| +| 销售管理 | 亚马逊站点销售、销量监控、产品销售报表 | 提供销量、成交、站点、产品数据 | +| 产品聚合管理 | 按品牌、国家、类目聚合新品、重点产品、清仓产品 | APP 侧需要计算绑定率和用户覆盖情况 | +| 绑定率提升 | Listing、说明书、官网等触点引导下载与绑定 APP | APP 提供绑定率数据，亚马逊运营优化触点 | +| 测评计划 | 亚马逊运营根据销售需求提出测评需求和节奏 | 用户运营负责实际实现，品牌运营参与协同 | +| 免评计划 | 关键词 + 实时销量策略，定时下单，主要承接补单诉求 | 需单独纳入合规与风险监控 | +| 推新计划 | 面向 S 级或当期重点产品，结合关键词进行推广 | APP 内推送资源分配需要与推新计划匹配 | +| 回评计划 | 维护链接评价数、回评数和评分等级 | 主要由亚马逊运营与用户运营协作，品牌运营参与协同 | +| 品牌推广协同 | 亚马逊运营同步品牌推广计划，并在亚马逊站内承接品牌调性 | 品牌运营为亚马逊站外品牌推广主责方 | + +### 4.3 独立看板一：产品销量与绑定率看板 + +#### 4.3.1 看板目标 + +用于从亚马逊运营视角监控不同品牌、国家、类目、产品类型下的销量与 APP 绑定情况。 + +该看板需要支持： + +- 品牌聚合 +- 国家/站点聚合 +- 类目与二级类目聚合 +- 新品、重点产品、清仓产品拆分 +- 销量与绑定率对比 +- 异常数据报警 +- 对应人员责任归属 + +#### 4.3.2 产品类型 + +| 产品类型 | 说明 | +|---|---| +| 新品 | 新上市产品，需要重点关注销量、绑定率、评价启动速度 | +| 重点产品 | 当期重点销售或重点维护产品，如 S 级产品 | +| 清仓产品 | 需要配合库存、促销、清仓节奏进行销售与触达 | + +#### 4.3.3 字段规划 + +| 字段 | 说明 | +|---|---| +| 产品名 | 产品展示名称 | +| 国家 | 销售国家或市场 | +| 品牌 | 所属品牌 | +| 对应人员 | 负责该产品或站点的运营人员 | +| 二级类目 | 产品所属二级类目 | +| ASIN | 亚马逊 ASIN | +| 产品类型 | 新品、重点产品、清仓产品 | +| 各站点销量 | 各亚马逊站点销量，详细数据涉密 | +| 总销量 | 汇总销量 | +| APP 绑定数 | APP 可识别的、已绑定指定玩具的用户数 | +| 绑定率 | APP 可识别的绑定了指定玩具的用户数 / 销售数 | +| 异常状态 | 是否出现销量异常、绑定率异常、数据缺失等 | +| 异常原因 | 异常说明或系统识别原因 | +| 最近更新时间 | 数据刷新时间 | + +#### 4.3.4 重点指标 + +- 产品销量 +- APP 绑定数 +- APP 绑定率 +- 新品绑定率爬坡情况 +- 重点产品绑定率 +- 清仓产品触达与绑定情况 +- 低绑定率产品列表 +- 异常站点/异常国家/异常类目 + +#### 4.3.5 异常报警建议 + +| 异常类型 | 触发逻辑 | +|---|---| +| 绑定率过低 | 产品销量正常，但 APP 绑定率低于目标值 | +| 销量异常波动 | 单日或单周销量较基准值显著上升或下降 | +| 站点数据缺失 | 某国家/站点销量或绑定数据未同步 | +| 新品启动异常 | 新品有销量但绑定数或评价启动明显滞后 | +| 重点产品风险 | S 级或重点产品绑定率、评价数、评分低于目标 | + +### 4.4 独立看板二：推新计划与 APP 推送资源分配看板 + +#### 4.4.1 看板目标 + +用于管理亚马逊推新计划和 APP 内现有推送资源之间的配合关系。 + +推新计划的核心是关键词相关的重点产品推广，尤其是当期周度、月度重点产品，如 S 级产品。 + +APP 侧需要根据现有用户资源，在 APP 内用户中进行定向推送、曝光、点击、回复、登记和评价转化跟踪。 + +#### 4.4.2 推新业务结构 + +| 层级 | 内容 | +|---|---| +| 当期重点产品 | 周度、月度重点产品表，例如 S 级产品 | +| 关键词策略 | 每个重点产品关联的关键词方向 | +| 推新算法 | 基于产品重要级、用户资源、活跃度、绑定数、历史效果进行推送分配 | +| APP 推送资源 | APP 内用户、社区消息、广告位、图片点击、活动曝光等 | +| 效果回收 | 曝光、点击、回复、登记、评价、回评 | + +#### 4.4.3 字段规划 + +| 字段 | 说明 | +|---|---| +| 产品名 | 推新产品名称 | +| ASIN | 对应亚马逊 ASIN | +| 产品重要级 | 如 S 级、A级、普通等 | +| 关键词 | 推新关联关键词 | +| 推送方案 | 当前采用的推送策略或资源组合 | +| 推送 ID | APP 内推送任务 ID | +| 关联图片点击率 | 推送图片或关联素材点击率 | +| 产品绑定数 | 已绑定该产品的用户数 | +| 总用户数 | APP 总用户数或目标用户池总数 | +| 当月活跃用户数 | 当月活跃用户规模 | +| 当月活跃率 | 当月活跃用户数 / 总用户数 | +| 推送数 | 实际推送数量 | +| 曝光数 | 用户实际看到的曝光数量 | +| 点击数 | 用户点击数量 | +| 回复数 | 用户回复数量 | +| 登记数 | 用户登记或报名数量 | +| 评价数 | 最终产生的评价数量 | +| 回评数 | 最终产生的回评数量 | +| 推送状态 | 未开始、进行中、已结束、暂停、异常 | +| 负责人 | 推新或推送负责人 | + +#### 4.4.4 核心计算指标 + +- 曝光率 = 曝光数 / 推送数 +- 点击率 = 点击数 / 曝光数 +- 回复率 = 回复数 / 点击数 +- 登记率 = 登记数 / 点击数 +- 评价转化率 = 评价数 / 登记数 +- 回评转化率 = 回评数 / 评价数 +- 活跃用户覆盖率 = 推送数 / 当月活跃用户数 + +#### 4.4.5 当前推新资源分配口径 + +当前推新计划先采用基础规则，后续逐步引入模型。 + +现阶段基本逻辑： + +- S 级产品需求需要最大程度满足。 +- 当前流量池预计约 50% 分配给核心 S 级产品。 +- A 级、B 级及其他产品共同占用剩余约 50% 流量。 +- 产品数量比例上，S 级约 10 来个，其他产品约 200 来个。 +- 后续建议计划需要综合关键词需求、GEO 需求、销量、产品重要级和突发事件生成。 + +### 4.5 独立看板三：测评计划与免评计划看板 + +#### 4.5.1 看板目标 + +用于管理亚马逊运营、用户运营与品牌运营协同的核心评价业务，包括测评计划和免评计划。 + +协作关系： + +- 亚马逊运营：根据亚马逊销售需求提出测评计划、免评计划和回评目标。 +- 用户运营：负责实际触达、推送、登记、索评、回评跟进和结果回收。 +- 品牌运营：由于了解亚马逊运营需求，参与协同对接，但不是实际执行主责方。 + +其中： + +- 测评计划：主要用于新品、重点产品的评价启动、评价数量建设和关键词推广配合。 +- 免评计划：主要基于关键词和实时销量策略进行定时下单，当前主要承接补单诉求。 + +#### 4.5.2 字段规划 + +| 字段 | 说明 | +|---|---| +| 计划 ID | 测评或免评计划唯一标识 | +| 计划类型 | 测评计划、免评计划 | +| 产品名 | 关联产品 | +| ASIN | 关联 ASIN | +| 国家/站点 | 亚马逊站点 | +| 品牌 | 所属品牌 | +| 产品类型 | 新品、重点、清仓 | +| 产品重要级 | S 级、A级等 | +| 关键词 | 计划关联关键词 | +| 计划周期 | 周、月或指定活动周期 | +| 计划数量 | 计划执行数量 | +| 实际完成数量 | 已完成数量 | +| 完成率 | 实际完成数量 / 计划数量 | +| APP 配合方式 | 推送、广告位、社区触达、客服触达等 | +| 风险等级 | 低、中、高 | +| 审批状态 | 待审批、已审批、执行中、已结束、暂停 | +| 负责人 | 亚马逊运营负责人 | +| 协同负责人 | APP 或用户运营负责人 | + +#### 4.5.3 审批流口径 + +测评计划、回评计划、免评计划需要建立审批流。 + +流程口径： + +1. 亚马逊运营提出测评、回评、免评计划。 +2. 亚马逊运营总监审批确认。 +3. 审批通过后进入用户运营执行排期。 +4. 用户运营根据用户池、渠道资源和频控规则制定可执行计划。 + +#### 4.5.4 风险说明 + +免评计划、补单诉求、返现或强索评相关动作应进入风险管理与审批机制，不能只作为普通运营动作处理。 + +建议后续单独规划： + +- 合规风险字段 +- 审批流 +- ASIN 风险状态 +- 账号风险状态 +- 高风险动作留痕 + +### 4.6 独立看板四：回评计划与 ASIN 评价健康度看板 + +#### 4.6.1 看板目标 + +用于保障亚马逊链接的评价数和评分等级，尤其是新品爆款周期内，需要评价数量和评价等级与销售节奏匹配。 + +核心目标： + +- 保障链接评价数 +- 保障评分等级 +- 支撑新品爆款周期 +- 识别 ASIN 评价健康风险 +- 区分新品、重点产品、清仓产品的回评需求 + +#### 4.6.2 评价健康标准 + +当前业务描述中的核心标准： + +- 评价数要与新品爆款周期匹配，原则上数量要多。 +- 评价等级需要维持在较高水平。 +- 新品或爆款产品期望评价等级原则上应达到 4.8 以上。 +- 4.8 属于很健康。 +- 4.5 属于健康。 +- 4.2 属于高风险，需要加强对未回评用户的回评推送。 + +#### 4.6.3 字段规划 + +| 字段 | 说明 | +|---|---| +| ASIN | 亚马逊 ASIN | +| 产品名 | 产品名称 | +| 国家/站点 | 销售国家或亚马逊站点 | +| 品牌 | 所属品牌 | +| 产品类型 | 新品、重点、清仓 | +| 产品重要级 | S 级、A级等 | +| 当月计划回评数 | 当月计划获得的回评数量 | +| 实际回评数 | 当月实际回评数量 | +| 回评完成率 | 实际回评数 / 当月计划回评数 | +| 期望评价等级 | 目标评分等级 | +| 实际评价等级 | 当前实际评分等级 | +| 当前评价数 | 当前累计评价数量 | +| 当月新增评价数 | 当月新增评价数量 | +| 差评数 | 当前或当月差评数量 | +| 差评率 | 差评数 / 评价数 | +| 健康状态 | 健康、关注、风险、严重风险 | +| 负责人 | ASIN 负责人 | + +#### 4.6.4 产品类型下的回评管理 + +| 产品类型 | 回评管理重点 | +|---|---| +| 新品 | 评价启动速度、评价数量爬坡、评分稳定性、爆款周期匹配 | +| 重点产品 | 评分等级维护、差评预警、持续回评目标达成 | +| 清仓产品 | 根据清仓节奏决定是否继续投入回评资源，避免资源浪费 | + +#### 4.6.5 ASIN 评价健康等级 + +| 实际评价等级 | 健康状态 | 处理建议 | +|---|---|---| +| 4.8 及以上 | 很健康 | 维持正常回评节奏，重点保障新品爆款周期 | +| 4.5-4.79 | 健康 | 保持监控，按计划推进回评 | +| 4.2-4.49 | 高风险 | 加强对未回评用户的回评推送 | +| 低于 4.2 | 严重风险 | 需要升级处理，结合客服、用户运营和亚马逊运营共同干预 | + +### 4.7 亚马逊运营协同品牌推广计划 + +品牌推广计划由亚马逊运营与品牌运营协同完成。 + +除亚马逊站内的品牌承接和销售动作外，以下工作以品牌运营为主进行决策，亚马逊运营同步即可： + +- JOYHUB 内推广 +- 社媒互动 +- 新品宣发 +- 活动宣发 +- 粉丝互动管理 +- 销售管理 +- 独立站推广 +- 新品推广 +- 社媒数据 +- KOL 互动数据 + +#### 4.7.1 品牌推广协同数据 + +| 字段 | 说明 | +|---|---| +| 推广计划 ID | 品牌推广计划唯一标识 | +| 推广类型 | JOYHUB、社媒、新品宣发、活动宣发、KOL、独立站等 | +| 产品名 | 关联产品 | +| ASIN | 关联 ASIN | +| 品牌 | 所属品牌 | +| 国家 | 推广国家 | +| 渠道 | 推广渠道 | +| 曝光数 | 推广曝光 | +| 点击数 | 推广点击 | +| 跳转数 | 跳转到亚马逊或独立站的数量 | +| 转化数 | 产生转化数量 | +| 成交数 | 产生订单数量 | +| 互动数 | 点赞、评论、私信、粉丝互动等 | +| KOL 信息 | 合作达人或账号 | +| 负责人 | 推广负责人 | + +## 5. 第二部分：品牌运营相关业务 + +### 5.1 品牌运营在闭环中的定位 + +品牌运营与亚马逊运营不在同一个办公区，但需要协助亚马逊运营共同建立销售体系。 + +品牌运营的核心定位是： + +1. 负责独立站品牌宣发。 +2. 负责在社媒建立品牌形象。 +3. 负责独立站成交与品牌侧销售管理。 +4. 协助亚马逊运营在亚马逊平台上提高品牌调性。 +5. 协助亚马逊运营扩大品牌在亚马逊上的市场份额。 +6. 与亚马逊运营共同参与品牌推广计划。 +7. 在亚马逊站外品牌推广相关事项上，品牌运营为主责决策方，亚马逊运营同步。 + +### 5.2 品牌运营与亚马逊运营的分工边界 + +| 业务事项 | 主责方 | 协同方 | 说明 | +|---|---|---|---| +| 亚马逊站内销售 | 亚马逊运营 | 品牌运营 | 品牌运营协助提高品牌调性和市场份额 | +| 亚马逊站内品牌承接 | 亚马逊运营 | 品牌运营 | Listing、品牌内容、品牌调性需要双方协同 | +| 独立站品牌宣发 | 品牌运营 | 亚马逊运营同步 | 独立站推广和转化由品牌运营主责 | +| 独立站成交 | 品牌运营 | 亚马逊运营同步 | 独立站销售数由品牌运营负责 | +| 社媒品牌形象 | 品牌运营 | 亚马逊运营同步 | 包含账号内容、互动、粉丝维护 | +| JOYHUB 内推广 | 品牌运营 | 亚马逊运营同步 | 实际为品牌运营工作，亚马逊运营了解进度 | +| 新品宣发 | 品牌运营 | 亚马逊运营同步 | 站外宣发主责在品牌运营 | +| 活动宣发 | 品牌运营 | 亚马逊运营同步 | 活动口径需要与销售节奏同步 | +| 粉丝互动管理 | 品牌运营 | 亚马逊运营同步 | 社媒与品牌用户关系维护 | +| KOL 互动 | 品牌运营 | 亚马逊运营同步 | KOL 数据和互动效果由品牌运营负责 | +| AMZ 测评计划 | 亚马逊运营、用户运营 | 品牌运营协同 | 亚马逊运营提需求，用户运营实现，品牌运营参与协同 | +| 回评计划 | 亚马逊运营、用户运营 | 品牌运营协同 | 主要服务 ASIN 评价健康度 | + +### 5.3 品牌运营核心业务模块 + +| 模块 | 业务内容 | 输出 | +|---|---|---| +| 品牌宣发 | 独立站、社媒、JOYHUB、新品、活动等品牌曝光 | 品牌推广计划、宣发内容、渠道效果 | +| 社媒运营 | 建立品牌形象、粉丝互动、社媒内容发布 | 社媒访问、点击、互动、转化数据 | +| 独立站推广 | 独立站访问、点击、转化、成交管理 | 独立站销售数、转化漏斗 | +| 新品推广 | 新品宣发、站外曝光、内容传播 | 新品推广数据、用户兴趣数据 | +| 活动推广 | 活动宣发、活动页面、粉丝触达 | 活动曝光、点击、转化、成交 | +| KOL 合作 | KOL 互动、达人合作、内容发布 | KOL 互动数据、访问与转化效果 | +| 品牌销售管理 | 独立站成交、品牌侧销售数据管理 | 销售数、成交数、转化数 | +| 亚马逊协同 | 协助亚马逊提升品牌调性和市场份额 | 品牌素材、推广节奏、协同反馈 | + +### 5.4 独立看板五：品牌影响力与独立站销售看板 + +#### 5.4.1 看板目标 + +用于衡量品牌运营在独立站、社媒、JOYHUB、KOL、新品宣发和活动宣发等渠道中的影响力、转化效果和销售结果。 + +该看板以品牌运营为主责，亚马逊运营同步查看，用于判断站外品牌推广对亚马逊销售和独立站销售的辅助效果。 + +#### 5.4.2 字段规划 + +| 字段 | 说明 | +|---|---| +| 品牌 | 所属品牌 | +| 国家 | 推广国家或市场 | +| 渠道来源 | 独立站、社媒、JOYHUB、KOL、新品宣发、活动宣发等 | +| 推广类型 | 新品、活动、日常内容、KOL、粉丝互动等 | +| 产品名 | 关联产品 | +| ASIN | 如有关联亚马逊产品，则记录 ASIN | +| 负责人 | 品牌运营负责人 | +| 访问数 | 各来源访问量 | +| 点击数 | 各来源点击量 | +| 转化数 | 各来源转化数量 | +| 销售数 | 独立站或品牌侧销售数量，由品牌运营负责 | +| 成交数 | 实际成交订单数量 | +| 互动数 | 点赞、评论、分享、私信、粉丝互动等 | +| KOL 信息 | 合作达人或账号信息 | +| 内容/活动 ID | 关联内容、活动或投放任务 | +| 跳转目标 | 亚马逊、独立站、APP、活动页等 | +| 数据周期 | 日、周、月、活动周期 | + +#### 5.4.3 核心指标 + +- 访问数 +- 点击数 +- 转化数 +- 销售数 +- 成交数 +- 社媒互动数 +- KOL 互动数据 +- 独立站转化率 +- 渠道访问贡献 +- 品牌活动转化效果 + +#### 5.4.4 品牌影响力评估口径 + +品牌影响力从两方面评估： + +1. 各渠道转化，包括独立站转化、亚马逊跳转转化、APP 承接转化等。 +2. 社媒影响力与调研反馈，包括互动、评论、粉丝反馈和品牌认知反馈。 + +通过品牌活动前往亚马逊形成的转化，也归属品牌运营 OKR 结果。 + +### 5.5 独立看板六：品牌推广计划协同看板 + +#### 5.5.1 看板目标 + +用于管理品牌运营与亚马逊运营共同参与的品牌推广计划。 + +该看板需要明确： + +- 品牌运营在站外推广中的主责地位 +- 亚马逊运营在亚马逊站内承接品牌调性与销售转化的职责 +- 品牌推广与亚马逊销售、独立站销售、APP 用户增长之间的关系 +- 品牌推广计划与 AMZ 测评计划之间的协同关系 + +#### 5.5.2 字段规划 + +| 字段 | 说明 | +|---|---| +| 推广计划 ID | 品牌推广计划唯一标识 | +| 推广计划名称 | 计划名称 | +| 主责部门 | 品牌运营 | +| 协同部门 | 亚马逊运营、用户运营、内容运营等 | +| 推广类型 | JOYHUB、社媒、新品宣发、活动宣发、KOL、独立站等 | +| 品牌 | 所属品牌 | +| 国家 | 推广国家 | +| 产品名 | 关联产品 | +| ASIN | 关联亚马逊 ASIN | +| 独立站链接 | 独立站承接地址 | +| 亚马逊链接 | 亚马逊承接地址 | +| APP 承接方式 | 是否需要 APP 内承接、推送或活动页 | +| 计划开始时间 | 推广开始时间 | +| 计划结束时间 | 推广结束时间 | +| 预算 | 推广预算 | +| 访问数 | 推广访问量 | +| 点击数 | 推广点击量 | +| 转化数 | 推广转化数量 | +| 销售数 | 品牌侧销售数量 | +| 成交数 | 实际成交订单 | +| 亚马逊同步状态 | 未同步、已同步、需调整 | +| 计划状态 | 草稿、待确认、执行中、已结束、暂停 | + +### 5.6 品牌运营参与 AMZ 测评计划的协作关系 + +AMZ 测评计划由三方协作完成： + +| 角色 | 职责 | +|---|---| +| 亚马逊运营 | 根据亚马逊平台销售需求提出测评计划、回评计划、关键词和产品优先级需求 | +| 品牌运营 | 理解并同步亚马逊运营需求，协同亚马逊运营与用户运营对接 | +| 用户运营 | 负责实际实现，包括用户触达、推送、登记、索评、回评跟进和结果反馈 | + +需要明确的是： + +- 测评计划和回评计划的主要协作方是亚马逊运营与用户运营。 +- 品牌运营参与协同，但不是实际落地执行主责方。 +- 品牌运营的核心主责仍然是品牌宣发、社媒品牌形象、独立站成交和站外推广管理。 + +### 5.7 APP 内资源协同边界 + +| 资源类型 | 管理分配方 | 品牌运营角色 | +|---|---|---| +| APP 内社区资源 | 内容运营分配，品牌运营与内容运营协同 | 将亚马逊运营和品牌运营需求与内容运营协商 | +| 用户推送资源 | 用户运营管理分配 | 将亚马逊运营和品牌运营需求与用户运营协商 | + +品牌运营熟悉内容运营和用户运营两侧资源，负责把亚马逊运营需求和品牌运营自身需求同步给相关部门，并推动协商解决。 + +### 5.8 品牌运营与其他部门的数据关系 + +| 数据流向 | 内容 | 用途 | +|---|---|---| +| 品牌运营 → 亚马逊运营 | 品牌推广计划、社媒/KOL 数据、新品宣发节奏、活动宣发数据 | 帮助亚马逊站内承接品牌调性和销售转化 | +| 亚马逊运营 → 品牌运营 | 亚马逊销售需求、重点 ASIN、推新节奏、测评需求、关键词方向 | 品牌运营理解销售重点并做站外协同 | +| 品牌运营 → 用户运营 | 推广计划、活动节奏、需要 APP 承接的用户触达需求 | APP 内推送、活动承接、用户触达 | +| 用户运营 → 品牌运营 | APP 用户反馈、触达数据、活动参与、评价反馈 | 优化品牌内容和活动策略 | +| 品牌运营 → 数据层/管理层 | 访问、点击、转化、销售数、互动数、KOL 数据 | 品牌影响力、渠道 ROI、独立站销售复盘 | + +## 6. 第三部分：用户运营相关业务 + +### 6.1 用户运营在闭环中的定位 + +用户运营是该系统的核心使用者。客服部门实际也归属用户部门管理。 + +用户运营的核心定位是： + +1. 接收亚马逊运营与品牌运营协同后的销售数据和测评需求。 +2. 根据关键词、销量、产品重要级、ASIN 评价健康度共同制定可执行的测评计划。 +3. 基于 APP 用户、绑定用户、活跃用户、社区用户、非 APP 或低活跃用户进行分层触达。 +4. 在社区中与用户互动，鼓励测评人参与。 +5. 负责推送、登记、索评、回评跟进和结果回收。 +6. 按 ASIN 评价健康度动态调整触达资源和回评节奏。 +7. 管理 TEL、EDM、KOC/KOL/PR、短信、社区、非评价推送等多渠道触达。 +8. 管理客服售后相关执行数据，并将售后反馈纳入触达策略优化。 + +### 6.2 用户运营核心业务模块 + +| 模块 | 业务内容 | 输出 | +|---|---|---| +| 测评计划执行 | 根据亚马逊销售需求、关键词、销量、产品重要级制定可执行测评计划 | 推送计划、登记数据、评价数、计划完成度 | +| 用户社区互动 | 在 APP 社区中与用户互动，鼓励用户参与新玩具测评 | 回复数、登记数、评价数 | +| 回评计划跟进 | 根据 ASIN 评价健康度跟进回评目标 | 回评完成度、风险等级、ASIN 健康状态 | +| IM 社区消息推送 | 推动新玩具购买与买后索评 | 曝光、点击、回复、登记、出评 | +| 已成交索评 | 针对已绑定、已购买玩具的用户进行索评 | 实际回评数、评价等级改善 | +| TEL 电话售后 | 接听售后和呼出电话 | 接听售后数据、呼出数据、售后原因 | +| EDM 邮件推送 | 针对非 APP 或低 APP 活跃用户进行邮件触达 | 打开、点击、回复、转化 | +| KOC/KOL/PR 合作 | 通过 JOYCOLLAB 网站管理合作伙伴体系 | 合作伙伴效果、带货链接、销售与提成数据 | +| 其他触达渠道 | 短信、社区、非评价推送等仍在搭建中的渠道 | 新增测评渠道、内容改善、用户反感度控制 | + +### 6.3 测评计划执行数据 + +用户运营根据亚马逊运营和品牌运营协同后的需求，结合销售数据、关键词和销量生成可执行的测评计划。 + +测评计划的关键是把“销售侧需求”转化为“用户侧可执行动作”。 + +#### 6.3.1 字段规划 + +| 字段 | 说明 | +|---|---| +| 产品名 | 关联产品 | +| ASIN | 亚马逊 ASIN | +| 产品重要级 | S 级、重点、普通等 | +| 关键词 | 亚马逊运营提出的关键词方向 | +| 推送方案 | 用户运营制定的触达策略 | +| 推送 ID | 推送任务唯一标识 | +| 关联图片点击率 | 推送图片或素材点击率 | +| 产品绑定数 | 已绑定该产品的用户数 | +| 总用户数 | 可触达用户总数 | +| 当月活跃用户数 | 当月活跃用户规模 | +| 当月活跃率 | 当月活跃用户数 / 总用户数 | +| 推送数 | 实际推送数量 | +| 曝光数 | 实际曝光数量 | +| 点击数 | 实际点击数量 | +| 回复数 | 用户回复数量 | +| 登记数 | 用户报名、登记或确认参与数量 | +| 评价数 | 最终产生的评价数量 | + +### 6.4 ASIN 评价健康度与回评计划 + +用户运营需要根据随时更新的 Listing 健康状况和 ASIN 评价健康度跟进回评计划。 + +核心原则： + +- 新品爆款周期需要与评价数量和评价等级匹配。 +- 新品和爆款原则上评价数量要多。 +- 新品和爆款的期望评价等级原则上应达到 4.8 以上。 +- 常规产品需要保障链接评价数和评分等级。 +- 回评计划需要区分新品、重点产品、清仓产品。 + +#### 6.4.1 字段规划 + +| 字段 | 说明 | +|---|---| +| ASIN | 亚马逊 ASIN | +| 产品名 | 关联产品 | +| 产品类型 | 新品、重点、清仓 | +| 当月计划回评数 | 当月计划回评数量 | +| 实际回评数 | 当月实际完成回评数量 | +| 期望评价等级 | 目标评价等级 | +| 实际评价等级 | 当前实际评价等级 | +| 回评完成率 | 实际回评数 / 当月计划回评数 | +| 风险等级 | 健康、关注、风险、严重风险 | +| 跟进人 | 用户运营负责人 | + +### 6.5 独立看板七：IM 社区消息推送计划看板 + +#### 6.5.1 业务场景 + +IM 社区消息推送主要用于推动新玩具测评。 + +当用户没有购买我们想推动的新玩具时，用户运营通过 IM 社区消息推送促使用户购买新玩具，并在购买后进行索评。 + +#### 6.5.2 看板目标 + +按地区、品牌、类目、策略观察不同推送计划的效果。 + +#### 6.5.3 字段规划 + +| 字段 | 说明 | +|---|---| +| 推送 ID | 推送任务唯一标识 | +| 关联产品 | 推送关联产品 | +| ASIN | 关联 ASIN | +| 国家/地区 | 推送覆盖地区 | +| 品牌 | 所属品牌 | +| 类目 | 产品类目 | +| 策略 | 推送策略 | +| 曝光 | 推送曝光数 | +| 点击 | 用户点击数 | +| 回复 | 用户回复数 | +| 登记 | 用户登记数 | +| 出评 | 最终产生评价数 | +| 转化率 | 出评或登记转化率 | +| 计划完成度 | 实际完成 / 计划目标 | +| 订单号 | 订单号，含亚马逊来源和独立站来源，涉密字段 | +| 订单来源 | 亚马逊、独立站等 | +| profile ID | 用户 Profile 标识，涉密字段 | +| joyhub ID | JOYHUB 用户标识，涉密字段 | + +### 6.6 独立看板八：已成交索评与回评计划完成度看板 + +#### 6.6.1 业务场景 + +当用户已经绑定某个玩具时，APP 能识别用户购买了哪个玩具。用户运营可以针对已有玩具进行已成交索评。 + +该看板与 ASIN 评价健康度直接关联，用于确保亚马逊链接健康。 + +#### 6.6.2 字段规划 + +| 字段 | 说明 | +|---|---| +| 产品类型 | 新品、重点、清仓 | +| 产品名 | 关联产品 | +| ASIN | 关联 ASIN | +| 产品计划回评数 | 当前产品计划回评数量 | +| 实际回评数 | 当前产品实际回评数量 | +| 回评完成率 | 实际回评数 / 产品计划回评数 | +| 当前 ASIN 评价等级 | 当前 ASIN 星级或评分 | +| 风险等级 | 健康、关注、风险、严重风险 | +| 负责人 | 用户运营负责人 | + +### 6.7 独立看板九：TEL 电话售后渠道看板 + +#### 6.7.1 业务场景 + +TEL 电话售后渠道包括接听售后和呼出电话，主要用于改善服务、收集售后问题、支撑索评和降低负面反馈。 + +#### 6.7.2 字段规划 + +| 字段 | 说明 | +|---|---| +| 电话号码 | 高度涉密字段 | +| 国家 | 用户国家 | +| 品牌 | 关联品牌 | +| 产品 | 关联产品 | +| 售后原因 | 用户咨询或售后原因 | +| 呼出数 | 呼出电话数量 | +| 接听数 | 接听电话数量 | +| 订单号 | 涉密字段 | +| 跟进人 | 客服或用户运营负责人 | +| 处理状态 | 待处理、处理中、已完结、需升级 | + +### 6.8 独立看板十：EDM 邮件推送渠道看板 + +#### 6.8.1 业务场景 + +EDM 邮件推送主要面向非 APP 用户或低 APP 活跃用户，用于补充 APP 内推送触达能力。 + +#### 6.8.2 看板目标 + +用于持续改善 EDM 计划，包括邮件打开、点击、回复和转化效果。 + +#### 6.8.3 字段规划 + +| 字段 | 说明 | +|---|---| +| 国家 | 用户国家 | +| 地区 | 用户地区 | +| 邮件服务商 | 邮件服务商 | +| 用户邮箱 | 高度涉密字段 | +| USER ID | 非 APP 用户 ID | +| 推送 ID | EDM 推送任务 ID | +| 点击数 | 邮件点击数量 | +| 打开数 | 邮件打开数量 | +| 回复数 | 邮件回复数量 | +| 转化数 | 由邮件触达带来的转化数量 | +| 计划状态 | 草稿、执行中、已结束、异常 | + +### 6.9 独立看板十一：KOC/KOL/PR 合作伙伴效果看板 + +#### 6.9.1 业务场景 + +KOC、KOL、PR 渠道用于合作伙伴对接和带货推广。合作伙伴体系通过 JOYCOLLAB 网站承接。 + +KOC 在 JOYCOLLAB 上的带货数据原则上先在 JOYCOLLAB 网站内处理，再同步到大用户后台。财务也会参与销售数据、提成数据和交易金额的核算或校验。 + +#### 6.9.2 看板目标 + +用于改善合作伙伴效果，观察合作伙伴在不同国家、平台、产品和带货链路上的实际贡献。 + +#### 6.9.3 字段规划 + +| 字段 | 说明 | +|---|---| +| 合作伙伴 ID | 合作伙伴唯一标识 | +| 国家 | 合作伙伴所在国家 | +| 姓名 | 合作伙伴姓名，涉密字段 | +| 时间 | 合作或跟进时间 | +| 平台 | 合作平台 | +| 粉丝 | 粉丝数量或粉丝规模 | +| 备注 | 合作备注 | +| 跟进人 | 用户运营或合作伙伴负责人 | +| 合作产品 | 合作推广产品 | +| 带货链接 | 合作伙伴带货链接 | +| 销售数据 | 通过带货链接产生的销售数据 | +| 提成数据 | 合作伙伴提成数据，涉密字段 | +| 交易金额 | 产生的交易金额 | + +### 6.10 其他触达渠道 + +其他渠道包括： + +- 短信 +- 社区 +- 非评价推送 + +这些渠道仍在搭建当中，目标包括： + +1. 继续增加测评渠道。 +2. 改善内容触达效果。 +3. 降低用户对高频推送、索评、活动通知的反感。 +4. 为非评价类推送沉淀策略，例如活动、内容、售后提醒、品牌互动。 + +### 6.11 用户识别、黑名单与频控口径 + +#### 6.11.1 用户识别主标识 + +订单号和 JOYHUB ID 是用户索评与黑名单查询中的两个主要标识。 + +订单号包括： + +- 亚马逊来源订单号 +- 独立站来源订单号 + +当用户注册后，必然有 JOYHUB ID。 +当用户提供订单号时，JOYHUB ID 和订单号建立关联。 + +APP 侧还会保留注册邮箱、用户基础 IP、设备号、用户行为数据等信息。订单号可以关联用户地址、姓名、用户名等信息。 + +#### 6.11.2 邮箱、账号与风险关联 + +注册用户的 JOYHUB ID 和邮箱必然关联。部分用户可能使用多个邮箱注册多个账号，每个账号都有独立 JOYHUB ID。 + +系统需要通过 IP、设备号等信息做黑名单关联。关联后，多个账号可被认定为关联账号，或在后台被划入高度风险关联，并按单一用户处理。 + +#### 6.11.3 多渠道统一频控 + +TEL、EDM、IM、社区、短信等渠道需要统一控制触达频率，并统一了解对用户的骚扰程度，避免过于频繁触达导致用户反感。 + +### 6.12 用户运营与其他部门的数据关系 + +| 数据流向 | 内容 | 用途 | +|---|---|---| +| 亚马逊运营 → 用户运营 | 销售数据、关键词、重点产品、测评需求、回评目标、ASIN 健康状态 | 制定可执行测评计划和回评计划 | +| 品牌运营 → 用户运营 | 品牌推广计划、活动节奏、站外触达需求、APP 承接需求 | 配合品牌推广进行 APP 内触达 | +| 用户运营 → 亚马逊运营 | 推送效果、登记数、评价数、回评数、ASIN 风险反馈 | 调整测评计划、推新计划和评价健康策略 | +| 用户运营 → 品牌运营 | 用户反馈、触达效果、活动参与、转化结果 | 优化品牌内容、活动和独立站推广 | +| 用户运营 → 客服运营 | 待跟进用户、售后触达需求、负面反馈线索 | 电话售后、问题处理和服务改善 | +| 客服运营 → 用户运营 | 接听售后数据、呼出数据、售后原因、处理结果 | 优化推送策略、索评节奏和用户分层 | +| 用户运营 → 数据层/管理层 | 推送、登记、评价、回评、TEL、EDM、合作伙伴数据 | 复盘渠道效果、人效、成本和风险 | + +## 7. 第四部分：菲律宾客服相关业务 + +### 7.1 菲律宾客服在闭环中的定位 + +菲律宾客服直接接受用户运营指导工作。 + +当亚马逊运营存在短期需求变动时，不直接绕过用户运营调整客服工作，而是通过用户运营转达和排期。这样可以保证测评计划、回评计划、售后触达、人员安排和成本统计在同一套用户运营口径下管理。 + +菲律宾客服的核心定位是： + +1. 执行用户运营下发的评价、登记、回复、售后跟进等具体任务。 +2. 承接各渠道用户接待与基础沟通。 +3. 配合评价计划落地，提升评价转化和完结评价数。 +4. 反馈客服侧接待、登记、回复、完结情况。 +5. 支撑用户运营进行成本管理、人效管理和渠道效果复盘。 + +### 7.2 核心指标 + +| 指标 | 说明 | +|---|---| +| 客源 | 来自不同渠道的用户来源或待处理线索 | +| 转化数 | 从接待、登记、回复到评价完成的转化数量 | +| 转化率 | 评价转化数 / 客源或登记数 | +| 节约成本 | 通过客服执行、人效提升、渠道优化节约的成本 | + +### 7.3 独立看板十二：菲律宾客服人员管理看板 + +#### 7.3.1 看板目标 + +用于管理菲律宾客服人员、出勤、每日工作量和各渠道执行情况。 + +#### 7.3.2 字段规划 + +| 字段 | 说明 | +|---|---| +| 人员 | 客服人员姓名或账号 | +| 团队/组别 | 所属客服小组 | +| 出勤 | 出勤状态、出勤天数或工时 | +| 日期 | 工作日期 | +| 渠道 | IM、TEL、EDM、社区、KOC/KOL/PR、其他 | +| 接待数 | 当日接待用户数量 | +| 登记数 | 当日登记数量 | +| 回复数 | 当日回复数量 | +| 每日评价数 | 当日产生评价数量 | +| 完结评价数 | 当日完结评价数量，按各渠道统计 | +| 待处理数 | 尚未处理或未完结任务数量 | +| 负责人 | 用户运营或客服主管 | + +### 7.4 独立看板十三：菲律宾客服评价计划管理看板 + +#### 7.4.1 看板目标 + +用于跟踪菲律宾客服执行评价计划的过程和结果，重点观察客源、登记、回复、出评和计划完成度。 + +#### 7.4.2 字段规划 + +| 字段 | 说明 | +|---|---| +| 评价计划 ID | 关联测评或回评计划 | +| 推送 ID | 关联用户运营推送任务 | +| 产品名 | 关联产品 | +| ASIN | 关联 ASIN | +| 产品类型 | 新品、重点、清仓 | +| 渠道 | IM、TEL、EDM、社区、其他 | +| 客源数 | 进入客服处理池的用户数量 | +| 接待数 | 客服实际接待数量 | +| 登记数 | 用户登记或确认参与数量 | +| 回复数 | 用户回复数量 | +| 每日评价数 | 每日产生评价数量 | +| 完结评价数 | 完成闭环的评价数量 | +| 转化数 | 从客源到评价完成的转化数量 | +| 转化率 | 转化数 / 客源数或登记数 | +| 计划完成度 | 实际完成 / 计划目标 | +| 跟进人 | 菲律宾客服人员 | +| 指导人 | 用户运营负责人 | + +### 7.5 独立看板十四：菲律宾客服成本管理看板 + +#### 7.5.1 看板目标 + +用于管理菲律宾客服相关人力成本、财务表和成本节约效果。 + +#### 7.5.2 字段规划 + +| 字段 | 说明 | +|---|---| +| 人员 | 客服人员 | +| 出勤 | 出勤天数或工时 | +| 人力成本 | 人员工资、补贴或对应成本 | +| 提成 | 如存在评价、转化或完结相关提成，则单独记录 | +| 管理成本 | 管理、培训、工具等分摊成本 | +| 完结评价数 | 该人员或团队完成评价数量 | +| 单评成本 | 总成本 / 完结评价数 | +| 转化数 | 产生的有效转化数量 | +| 单转化成本 | 总成本 / 转化数 | +| 节约成本 | 因流程改善、人效提升或渠道优化节约的成本 | +| 财务表 | 人事或财务表关联记录 | + +### 7.6 菲律宾客服与其他部门的数据关系 + +| 数据流向 | 内容 | 用途 | +|---|---|---| +| 用户运营 → 菲律宾客服 | 评价计划、待跟进用户、推送任务、短期需求变动、售后跟进要求 | 指导客服执行 | +| 菲律宾客服 → 用户运营 | 出勤、接待、登记、回复、每日评价、完结评价数、售后反馈 | 用户运营复盘渠道效果、人效和计划完成情况 | +| 亚马逊运营 → 用户运营 → 菲律宾客服 | 亚马逊运营短期测评、回评或售后需求变动 | 通过用户运营统一转达，避免执行口径混乱 | +| 菲律宾客服 → 数据层/管理层 | 人员、人效、评价转化、成本、财务表数据 | 成本管理、绩效评估和管理复盘 | + +## 8. 第五部分：内容运营相关业务 + +### 8.1 内容运营在闭环中的定位 + +内容运营在当前以用户运营为核心的业务需求中，主要负责配合亚马逊运营与品牌运营，在销售前期为产品做宣发和社区内流量承接。 + +内容运营的核心定位是： + +1. 配合亚马逊运营和品牌运营做产品售前宣发。 +2. 管理 APP 内广告资源，包括开屏、弹窗、文末、ME、评论末等位置。 +3. 在社区内配合用户 KOC/KCO 对接，支持产品内容传播和测评前期预热。 +4. 执行售前社区广告计划。 +5. 通过推流管理提升重点产品、重点帖子、活动内容的曝光和点击。 +6. 管理加权、新帖、固定位置和固定流量池资源。 +7. 监控曝光、点击、打开、跳转、成交和互动数据，并识别风险。 + +### 8.2 内容运营核心业务模块 + +| 模块 | 业务内容 | 输出 | +|---|---|---| +| 售前社区广告计划 | 配合产品上市、活动、测评计划做社区前期宣发 | 广告计划、曝光、点击、跳转、成交数据 | +| APP 广告管理 | 管理开屏、弹窗、文末、ME、评论末等广告位 | 广告位排期、用户行为数据、转化数据 | +| 推流管理 | 对帖子加权、新帖扶持、固定位置投放、固定流量池管理 | 帖子曝光、点击、打开、互动、风险数据 | +| KOC/KCO 对接 | 在社区中与用户或内容参与者对接 | 内容互动、测评预热、社区反馈 | +| 风险识别 | 识别异常用户、异常互动、内容风险或投流风险 | 风险标记、处理建议 | + +### 8.3 独立看板十五：APP 广告管理看板 + +#### 8.3.1 看板目标 + +用于管理 APP 内广告位资源，支撑亚马逊运营和品牌运营在销售前期进行产品宣发、活动宣发和售前社区触达。 + +广告位包括： + +- 开屏 +- 弹窗 +- 文末 +- ME +- 评论末 + +#### 8.3.2 字段规划 + +| 字段 | 说明 | +|---|---| +| 月份 | 月度统计周期 | +| 日期 | 每日统计周期 | +| 产品 | 关联产品 | +| ASIN | 如关联亚马逊产品，则记录 ASIN | +| 品牌 | 所属品牌 | +| 国家/地区 | 投放国家或地区 | +| 广告位 | 开屏、弹窗、文末、ME、评论末等 | +| 绑定情况 | 产品绑定用户数、绑定率或绑定状态 | +| 用户行为 | 浏览、点击、打开、跳转、互动、购买等行为 | +| 性别 | 用户性别 | +| 其他标记用户数 | 风险用户、重点用户、异常用户或其他业务标记用户数 | +| 曝光 | 广告曝光数 | +| 点击 | 广告点击数 | +| 打开 | 广告打开数 | +| 跳转 | 跳转到产品页、亚马逊、独立站、活动页或 APP 页面数量 | +| 成交数 | 由广告触达带来的成交数量 | +| 负责人 | 内容运营负责人 | + +#### 8.3.3 核心指标 + +- 曝光数 +- 点击数 +- 打开数 +- 跳转数 +- 成交数 +- 点击率 +- 打开率 +- 跳转率 +- 成交转化率 +- 不同广告位效果对比 + +### 8.4 独立看板十六：推流管理看板 + +#### 8.4.1 看板目标 + +用于管理社区内容推流，包括帖子加权、新帖推流、固定位置和固定流量池。 + +该看板服务于售前社区广告计划，帮助重点产品和重点内容获得更稳定的曝光与互动。 + +#### 8.4.2 推流动作 + +| 动作 | 说明 | +|---|---| +| 加权 | 对重点帖子或产品内容增加推荐权重 | +| 新帖 | 对新发布内容进行启动流量扶持 | +| 固定位置 | 将内容投放到指定社区位置 | +| 固定流量池管理 | 管理固定流量池分配和资源占用 | + +#### 8.4.3 字段规划 + +| 字段 | 说明 | +|---|---| +| 帖子 ID | 社区帖子唯一标识 | +| 产品 | 关联产品 | +| ASIN | 如关联亚马逊产品，则记录 ASIN | +| 品牌 | 所属品牌 | +| 发帖人属性 | 发帖人身份、用户类型、KOC/KCO、普通用户等 | +| 帖子周期 | 新帖期、加权期、稳定期、结束期等 | +| 投流等级 | 投流优先级或资源等级 | +| 流量等级 | 实际分配的流量层级 | +| 固定位置 | 是否使用固定位置及位置名称 | +| 固定流量池 | 是否占用固定流量池及流量池名称 | +| 曝光 | 帖子曝光数 | +| 点击 | 帖子点击数 | +| 打开 | 帖子打开数 | +| 互动数 | 点赞、评论、收藏、分享、回复等互动总数 | +| 各互动数 | 各类型互动明细 | +| 风险 | 内容风险、用户风险、异常互动或投流风险 | +| 负责人 | 内容运营负责人 | + +### 8.5 内容运营与其他部门的数据关系 + +| 数据流向 | 内容 | 用途 | +|---|---|---| +| 亚马逊运营 → 内容运营 | 重点产品、ASIN、推新节奏、售前宣发需求、测评前期需求 | 安排社区广告和推流资源 | +| 品牌运营 → 内容运营 | 品牌推广计划、新品宣发、活动宣发、素材与口径 | 统一品牌内容和社区投放 | +| 用户运营 → 内容运营 | 用户触达节奏、测评计划、用户反馈、频控要求 | 避免内容触达与用户推送冲突 | +| 内容运营 → 亚马逊运营/品牌运营 | 广告曝光、点击、打开、跳转、成交、帖子互动、风险数据 | 复盘售前宣发效果和销售辅助效果 | +| 内容运营 → 数据层/管理层 | APP 广告、推流、互动、风险、成交归因数据 | 管理社区资源效率和内容投流效果 | + +## 9. 亚马逊运营与其他部门的数据关系 + +| 数据流向 | 内容 | 用途 | +|---|---|---| +| 亚马逊运营 → APP/用户运营 | 销量、订单、ASIN、产品、国家、站点、成交用户 | 绑定率计算、用户触达、索评 | +| APP/用户运营 → 亚马逊运营 | 绑定数、绑定率、活跃用户、推送效果、评价结果 | Listing/说明书/官网优化，评价计划调整 | +| 亚马逊运营 → 评价运营 | 重点产品、推新计划、测评计划、回评目标 | 制定评价数量和评分维护策略 | +| 评价运营 → 亚马逊运营 | 实际评价数、回评数、评分、差评、ASIN 健康状态 | 判断链接健康度和销售风险 | +| 客服运营 → 亚马逊运营 | 售后问题、负面反馈、用户投诉、问题类型 | 优化产品、Listing、说明书和售后策略 | +| 品牌/内容运营 → 亚马逊运营 | 品牌推广、内容曝光、社媒/KOL 数据 | 辅助亚马逊销售转化和新品启动 | + +## 10. 已确认问题与业务口径 + +| 编号 | 已确认口径 | 后续影响 | +|---|---|---| +| Q1 | 绑定率 = APP 可识别的绑定了指定玩具的用户数 / 销售数。 | 绑定率看板按产品和 ASIN 计算。 | +| Q2 | 支持在权限控制下查看明细，明细需要具体到每个 ASIN。 | 需要做 ASIN 级权限和涉密销量明细权限。 | +| Q3 | S、A 级重要性由公司领导约 2-3 人和亚马逊核心总监确认，由用户运营指定人员维护。 | 产品重要级需要维护入口、确认记录和变更日志。 | +| Q4 | 推新先用基础规则，后续逐步引入模型。当前 S 级需求最大程度满足，约 50% 流量给核心 S 级产品，其余 A/B 等产品共享约 50% 流量。 | 推新算法一期用规则引擎，二期再考虑模型。 | +| Q5 | 测评、回评、免评计划需要审批流。亚马逊运营提出计划，亚马逊运营总监审批确认。 | 需要建立计划审批状态、审批人和审批记录。 | +| Q6 | 4.8 很健康，4.5 健康，4.2 高风险；4.2 时需要加强对未回评用户的回评推送。 | ASIN 健康看板需要按评分阈值报警。 | +| Q7 | 用户提供订单号时进行关联。APP 有 JOYHUB ID、注册邮箱、基础 IP、设备号、用户行为数据等；订单号可关联用户地址、姓名、用户名等。 | 用户识别需要订单号 + JOYHUB ID 双主标识，并保留辅助识别信息。 | +| Q8 | 品牌影响力核心从两方面评估：各渠道转化、社媒影响力与调研反馈。 | 品牌看板需要同时支持转化数据和影响力反馈数据。 | +| Q9 | 通过品牌活动前往亚马逊形成的转化，也归属品牌运营 OKR 结果。 | 销售归因需要支持品牌活动到亚马逊转化。 | +| Q10 | APP 内社区资源由品牌运营与内容运营协同、内容运营分配；用户推送资源由用户运营管理分配。品牌运营负责将亚马逊和品牌需求与内容运营、用户运营协商解决。 | 资源排期需要区分社区资源和用户推送资源。 | +| Q11 | 需要逐步根据亚马逊平台算法，把关键词需求、GEO 需求同步到测评计划中，综合销量、重要级、突发事件生成建议计划，再调动 IM、EDM、电话、KOC、KOL 等渠道。 | 后续需要计划生成引擎和多渠道资源调度。 | +| Q12 | 订单号和 JOYHUB ID 是两个主要标识。订单号包括亚马逊来源和独立站来源。用户注册后必然有 JOYHUB ID，提供订单号后两者关联。 | 修正字段为“订单号”，不再使用 OA 订单号。 | +| Q13 | 各渠道需要统一控制频率，并统一了解对用户的骚扰程度，避免过于频繁。 | 需要建设跨渠道频控和用户反感度监控。 | +| Q14 | 注册用户的 JOYHUB ID 和邮箱必然关联；多个邮箱多账号可通过 IP、设备号等做黑名单关联，后台可按单一用户处理。 | 需要账号关联、黑名单和高风险关联用户机制。 | +| Q15 | JOYCOLLAB 和财务都会参与。原则上 KOC 在 JOYCOLLAB 上的带货数据在网站内处理后同步到大用户后台。 | KOC/KOL/PR 看板需要支持 JOYCOLLAB 同步和财务核算校验。 | + +## 11. 进入项目规划前的系统设计问题 + +当前业务链条已经基本清晰，可以进入项目规划与系统模块拆分。进入 ERP 系统设计前，需要把以下问题作为系统设计约束统一管理。 + +### 11.1 角色权限 + +需要明确不同角色的数据可见范围、操作权限和审批权限。 + +重点问题： + +- 谁能查看销售明细？ +- 谁能查看用户邮箱、电话、订单号、地址、姓名等高度涉密字段？ +- 谁能审批、修改、暂停测评计划、回评计划、免评计划？ +- 菲律宾客服能看到哪些用户字段？ +- 内容运营能看到哪些用户行为和成交归因字段？ + +### 11.2 计划流程状态 + +测评、回评、免评、推送、内容投流、客服任务都需要统一状态流。 + +建议基础状态： + +- 草稿 +- 待审批 +- 已审批 +- 执行中 +- 暂停 +- 异常 +- 已完成 +- 已复盘 + +### 11.3 数据来源 + +需要在系统层面明确每类数据的来源、同步方式、刷新频率和权限等级。 + +| 数据类型 | 可能来源 | +|---|---| +| 亚马逊销量/订单 | 亚马逊运营数据源、导入表、API 或报表 | +| 独立站订单 | 独立站系统 | +| APP 绑定 | JOYHUB/APP 用户系统 | +| 用户资料 | JOYHUB ID、注册邮箱、IP、设备号、用户行为数据 | +| EDM 数据 | 邮件服务商 | +| TEL 数据 | 电话系统或客服登记 | +| JOYCOLLAB 数据 | JOYCOLLAB 网站 | +| 财务/人事数据 | 财务表、人事表、成本表 | +| 内容广告数据 | APP 广告位、社区内容系统 | + +### 11.4 核心业务对象 + +后续建系统时，至少需要统一以下核心对象： + +- 用户 +- 订单 +- 产品 +- ASIN +- 品牌 +- 国家/站点 +- 推送计划 +- 测评计划 +- 回评计划 +- 免评计划 +- 内容投流计划 +- 广告位 +- 客服任务 +- 合作伙伴 +- 成本记录 +- 风险用户/黑名单 + +### 11.5 计划生成规则 + +推新和测评计划一期建议先采用规则引擎，后续再逐步引入模型。 + +仍需继续细化： + +- S/A/B 级产品资源比例是否固定，还是允许人工调整？ +- 突发事件如何插队？ +- 一个用户多久不能被重复触达？ +- 一个 ASIN 高风险时是否自动提升优先级？ +- GEO 需求如何进入计划生成？ +- 关键词需求如何与用户池匹配？ + +### 11.6 评价健康报警 + +评分阈值已经初步明确，但还需要补充数量类和进度类报警。 + +待细化： + +- 回评数低于计划多少算异常？ +- 新品多少天内必须达到多少评价？ +- 差评率达到多少触发客服或用户运营介入？ +- ASIN 评分下降多少需要升级？ +- 评价健康报警是否自动触发回评推送计划？ + +### 11.7 成本口径 + +成本口径需要统一，否则无法做真实 ROI 和人效复盘。 + +待细化： + +- 单评成本如何计算？ +- 返现成本是否纳入单评成本？ +- 菲律宾客服人力成本如何分摊到产品、ASIN、计划？ +- KOC/KOL 提成如何归因到订单？ +- 管理成本如何分摊？ + +### 11.8 归因规则 + +多渠道触达一定会发生交叉，归因规则需要系统化。 + +典型场景： + +用户先看到 APP 内容广告，再收到 EDM，最后通过亚马逊购买。 + +待确定： + +- 采用首触归因、末触归因、主要贡献渠道，还是多渠道权重归因？ +- 品牌活动到亚马逊成交如何归因？ +- 内容广告和用户推送都参与时如何拆分贡献？ +- KOC/KOL 带货链接与后续 APP 触达如何处理归因冲突？ + +### 11.9 黑名单与风险用户处理 + +黑名单与风险用户需要成为系统基础能力。 + +待细化： + +- 谁能加入黑名单？ +- 黑名单是否影响推送、返现、测评资格？ +- 高风险用户是否允许客服继续跟进？ +- 多账号关联后是否自动合并为单一风险用户？ +- 黑名单查询是否支持订单号和 JOYHUB ID 双入口？ + +### 11.10 一期项目边界建议 + +一期不宜追求一次性覆盖所有 ERP 能力，应优先建设评价业务闭环的主干。 + +建议一期优先： + +1. 产品/ASIN 看板 +2. 测评计划、回评计划、免评计划审批流 +3. 用户推送计划 +4. ASIN 评价健康看板 +5. 菲律宾客服执行看板 +6. 基础权限与涉密字段控制 +7. 基础数据导入和统一主键 + +后续二期及以后再逐步扩展模型化计划生成、多渠道归因、复杂成本核算、内容广告优化、JOYCOLLAB 深度集成和管理层经营分析。 + +## 12. 修改记录 + +| 版本 | 日期 | 修改内容 | 记录人 | +|---|---|---|---| +| v0.7 | 2026-04-26 | 将业务链条确认后的系统设计问题写入文档；补充角色权限、计划状态流、数据来源、核心业务对象、计划生成规则、评价健康报警、成本口径、归因规则、黑名单与风险用户处理和一期项目边界建议。 | Codex | +| v0.6 | 2026-04-26 | 追加内容运营相关业务；明确内容运营配合亚马逊运营与品牌运营进行销售前期宣发、售前社区广告计划和社区 KOC/KCO 对接；新增 APP 广告管理看板和推流管理看板，覆盖开屏、弹窗、文末、ME、评论末、加权、新帖、固定位置、固定流量池、用户行为、互动与风险字段。 | Codex | +| v0.5 | 2026-04-26 | 追加菲律宾客服相关业务；明确菲律宾客服直接接受用户运营指导，亚马逊运营短期需求变动通过用户运营转达；新增核心指标客源、转化数、转化率、节约成本；新增人员管理、评价计划管理、成本管理三个看板及字段；补充菲律宾客服与用户运营、亚马逊运营、数据层/管理层的数据关系。 | Codex | +| v0.4 | 2026-04-26 | 回答并固化 Q1-Q15 业务口径；明确绑定率公式、ASIN 明细权限、产品重要级确认与维护、推新资源规则、测评/回评/免评审批流、ASIN 评价健康阈值、订单号与 JOYHUB ID 双主标识、品牌影响力评估、品牌活动归因、APP 社区与用户推送资源边界、测评计划建议生成方向、跨渠道频控、黑名单关联和 JOYCOLLAB/财务数据来源。 | Codex | +| v0.3 | 2026-04-26 | 追加用户运营相关业务；明确用户运营为系统核心使用者，客服部门归属用户部门管理；新增测评计划执行、ASIN 评价健康与回评计划、IM 社区消息推送、已成交索评、TEL 电话售后、EDM 邮件推送、KOC/KOL/PR 合作伙伴、其他触达渠道等模块；新增用户运营与其他部门的数据关系和待确认问题。 | Codex | +| v0.2 | 2026-04-26 | 追加品牌运营相关业务；明确品牌运营与亚马逊运营不在同一办公区但共同建立销售体系；修正品牌推广计划归属为品牌运营主责、亚马逊运营同步；明确 AMZ 测评计划由亚马逊运营提需求、品牌运营协同、用户运营实际实现；新增品牌影响力与独立站销售看板、品牌推广计划协同看板、品牌运营数据关系和待确认问题。 | Codex | +| v0.1 | 2026-04-26 | 建立评价业务流闭环项目架构文档；整理总体业务闭环、基础指标、亚马逊运营相关业务；新增销量与绑定率看板、推新计划与 APP 推送资源分配看板、测评与免评计划看板、回评计划与 ASIN 评价健康度看板、品牌推广协同数据和待确认问题。 | Codex | diff --git a/wishfulfilled-wiki/05_需求文档/user_erp_mvp_admin_prototype_v10(1).html b/wishfulfilled-wiki/05_需求文档/user_erp_mvp_admin_prototype_v10(1).html new file mode 100644 index 0000000..90af16b --- /dev/null +++ b/wishfulfilled-wiki/05_需求文档/user_erp_mvp_admin_prototype_v10(1).html @@ -0,0 +1,3878 @@ + + + + + + USER 后台 ERP MVP · 管理员总览原型 v10 + + + +
+ + +
+
+
+
+ 经营总览 + 系统管理员 · 最高权限 · 全部部门 +
+
+ 搜索 + +
+
+
+
+ + 至 + +
+
+ + + +
+ + + +
+
+ +
+
+
+ +
+ + + + + +
+ + + + diff --git a/wishfulfilled-wiki/05_需求文档/user_erp_mvp_admin_prototype_v10.html b/wishfulfilled-wiki/05_需求文档/user_erp_mvp_admin_prototype_v10.html new file mode 100644 index 0000000..2f14aaa --- /dev/null +++ b/wishfulfilled-wiki/05_需求文档/user_erp_mvp_admin_prototype_v10.html @@ -0,0 +1,7623 @@ + + + + + + USER 后台 ERP MVP · 管理员总览原型 v10 + + + +
+ + +
+
+
+
+ 经营总览 + 系统管理员 · 最高权限 · 全部部门 +
+
+ 搜索 + +
+
+
+
+ + 至 + +
+
+ + + +
+ + + +
+
+ +
+
+
+ +
+ + + + + +
+ +
+ + + + + diff --git a/wishfulfilled-wiki/05_需求文档/客服执行.html b/wishfulfilled-wiki/05_需求文档/客服执行.html new file mode 100644 index 0000000..9469316 --- /dev/null +++ b/wishfulfilled-wiki/05_需求文档/客服执行.html @@ -0,0 +1,67 @@ + + + + + + 客服执行看板 + + + +
+ + + diff --git a/wishfulfilled-wiki/05_需求文档/用户运营系统-单文件.html b/wishfulfilled-wiki/05_需求文档/用户运营系统-单文件.html new file mode 100644 index 0000000..12ea6e4 --- /dev/null +++ b/wishfulfilled-wiki/05_需求文档/用户运营系统-单文件.html @@ -0,0 +1,738 @@ + + + + + + USER评价业务闭环系统 + + + + +
+ + diff --git a/wishfulfilled-wiki/05_需求文档/需求文档索引.md b/wishfulfilled-wiki/05_需求文档/需求文档索引.md new file mode 100644 index 0000000..4c6f304 --- /dev/null +++ b/wishfulfilled-wiki/05_需求文档/需求文档索引.md @@ -0,0 +1,39 @@ +--- +type: requirement_index +tags: [需求文档, 索引, Agent检索] +aliases: [需求索引, 需求文档清单, 需求清单] +source: manual +status: active +owner: 产品经理 / 业务主管 +updated: 2026-05 +--- + +# 需求文档索引 + +本文件记录 `05_需求文档/` 下所有正式需求文档，供人工维护和 Agent 检索定位。 + +## 需求文档清单 + +| 编号 | 业务域 | 需求/规则名称 | 文件 | 状态 | 负责人 | 更新时间 | 验证状态 | +|---|---|---|---|---|---|---|---| +| | | | | | | | 未验证 | + +## Agent 检索关键词 + +| 关键词/问法 | 标准术语 | 命中文件 | 答案要点 | +|---|---|---|---| +| | | | | + +## 维护规则 + +1. 新增需求文档后，必须在“需求文档清单”新增一行。 +2. 每个需求文档至少维护 3 个可检索问法。 +3. `状态=active` 的文档可作为 Agent 回答依据。 +4. `status=draft/reviewing` 的文档只能作为草稿参考，Agent 回答时需说明尚未确认。 +5. `status=deprecated` 的文档不得作为当前规则依据，只能说明历史背景。 + +## 验证记录摘要 + +| 日期 | 文件 | 验证问题数 | 通过数 | 失败数 | 结论 | +|---|---|---:|---:|---:|---| +| | | | | | | diff --git a/wishfulfilled-wiki/06_里程碑/README.md b/wishfulfilled-wiki/06_里程碑/README.md new file mode 100644 index 0000000..d1f3b8b --- /dev/null +++ b/wishfulfilled-wiki/06_里程碑/README.md @@ -0,0 +1,42 @@ +--- +type: milestone_home +tags: [里程碑, 项目管理, 知识库] +aliases: [里程碑入口, 项目里程碑] +source: manual +status: active +owner: 项目经理 +updated: 2026-05 +--- + +# 里程碑 + +本目录用于存放项目阶段计划、里程碑节点、阶段评审记录和上线节奏说明。 + +## 二级入口 + +- [[里程碑索引]] +- [[阶段计划模板]] +- [[里程碑评审记录]] + +## 存放内容 + +- 项目启动节点 +- 需求评审节点 +- 原型/高保真确认节点 +- 开发启动节点 +- 测试准入节点 +- 上线检查节点 +- 复盘回流节点 + +## 命名建议 + +```text +项目名_里程碑计划_YYYYMMDD.md +项目名_阶段评审记录_YYYYMMDD.md +``` + +## 关联目录 + +- 需求依据：[[../05_需求文档/README|需求文档]] +- 流程依据：[[../02_项目管理流程/AI驱动内部系统开发流程_V3_总览|项目管理流程]] +- 测试准入：[[../08_测试相关/README|测试相关]] diff --git a/wishfulfilled-wiki/06_里程碑/里程碑索引.md b/wishfulfilled-wiki/06_里程碑/里程碑索引.md new file mode 100644 index 0000000..2b29ff5 --- /dev/null +++ b/wishfulfilled-wiki/06_里程碑/里程碑索引.md @@ -0,0 +1,29 @@ +--- +type: milestone_index +tags: [里程碑, 索引, Agent检索] +aliases: [里程碑清单, 项目节点索引] +source: manual +status: active +owner: 项目经理 +updated: 2026-05 +--- + +# 里程碑索引 + +## 里程碑文档清单 + +| 项目 | 里程碑名称 | 文件 | 阶段 | 负责人 | 计划时间 | 当前状态 | +|---|---|---|---|---|---|---| +| | | | | | | | + +## Agent 检索关键词 + +| 问法 | 标准术语 | 命中文件 | 答案要点 | +|---|---|---|---| +| | | | | + +## 维护规则 + +- 新增里程碑计划后，在本索引登记。 +- 每个里程碑应关联至少一个需求文档或项目管理阶段。 +- Agent 回答项目进度、节点、准入问题时，应引用本索引或具体里程碑文件。 diff --git a/wishfulfilled-wiki/06_里程碑/里程碑评审记录.md b/wishfulfilled-wiki/06_里程碑/里程碑评审记录.md new file mode 100644 index 0000000..2ee6c59 --- /dev/null +++ b/wishfulfilled-wiki/06_里程碑/里程碑评审记录.md @@ -0,0 +1,15 @@ +--- +type: milestone_review_log +tags: [里程碑, 评审, 记录] +aliases: [阶段评审记录, 里程碑评审] +source: manual +status: active +owner: 项目经理 +updated: 2026-05 +--- + +# 里程碑评审记录 + +| 日期 | 项目 | 阶段 | 评审结论 | 遗留问题 | 负责人 | 后续动作 | +|---|---|---|---|---|---|---| +| | | | | | | | diff --git a/wishfulfilled-wiki/06_里程碑/阶段计划模板.md b/wishfulfilled-wiki/06_里程碑/阶段计划模板.md new file mode 100644 index 0000000..82214f3 --- /dev/null +++ b/wishfulfilled-wiki/06_里程碑/阶段计划模板.md @@ -0,0 +1,53 @@ +--- +type: milestone_template +tags: [里程碑, 阶段计划, 模板] +aliases: [阶段计划, 里程碑模板] +source: manual +status: active +owner: 项目经理 +updated: 2026-05 +--- + +# 阶段计划模板 + +## 基本信息 + +| 项目 | 内容 | +|---|---| +| 项目名称 | | +| 关联需求 | | +| 当前阶段 | | +| 负责人 | | +| 计划开始 | | +| 计划结束 | | + +## 阶段目标 + + +## 输入材料 + +- 需求文档： +- 业务流程： +- 技术文档： +- 测试材料： + +## 关键任务 + +| 任务 | 负责人 | 截止时间 | 输出物 | 状态 | +|---|---|---|---|---| +| | | | | | + +## 阶段交付物 + + +## 准入/准出条件 + + +## 风险与阻塞 + + +## Agent 检索字段 + +- 关键词： +- 同义词： +- 典型问法： diff --git a/wishfulfilled-wiki/07_技术文档/README.md b/wishfulfilled-wiki/07_技术文档/README.md new file mode 100644 index 0000000..a824f9b --- /dev/null +++ b/wishfulfilled-wiki/07_技术文档/README.md @@ -0,0 +1,44 @@ +--- +type: technical_docs_home +tags: [技术文档, 架构, 开发, 知识库] +aliases: [技术文档入口, 技术资料] +source: manual +status: active +owner: 技术负责人 +updated: 2026-05 +--- + +# 技术文档 + +本目录用于存放系统架构、数据模型、接口说明、实现方案、部署说明和技术决策记录。 + +## 二级入口 + +- [[技术文档索引]] +- [[系统架构说明模板]] +- [[接口说明模板]] +- [[技术决策记录]] + +## 存放内容 + +- 系统架构说明 +- 模块设计说明 +- 数据表/业务对象设计 +- API 接口说明 +- 权限与安全设计 +- 部署与配置说明 +- 技术决策记录 + +## 命名建议 + +```text +系统或模块_技术方案_YYYYMMDD.md +系统或模块_接口说明_YYYYMMDD.md +系统或模块_数据模型_YYYYMMDD.md +``` + +## 关联目录 + +- 需求依据：[[../05_需求文档/README|需求文档]] +- 测试依据：[[../08_测试相关/README|测试相关]] +- 里程碑：[[../06_里程碑/README|里程碑]] diff --git a/wishfulfilled-wiki/07_技术文档/技术决策记录.md b/wishfulfilled-wiki/07_技术文档/技术决策记录.md new file mode 100644 index 0000000..cc763fd --- /dev/null +++ b/wishfulfilled-wiki/07_技术文档/技术决策记录.md @@ -0,0 +1,15 @@ +--- +type: adr_log +tags: [技术文档, 技术决策, ADR] +aliases: [技术决策, ADR] +source: manual +status: active +owner: 技术负责人 +updated: 2026-05 +--- + +# 技术决策记录 + +| 日期 | 决策主题 | 背景 | 决策结论 | 影响范围 | 关联需求/技术文档 | +|---|---|---|---|---|---| +| | | | | | | diff --git a/wishfulfilled-wiki/07_技术文档/技术文档索引.md b/wishfulfilled-wiki/07_技术文档/技术文档索引.md new file mode 100644 index 0000000..10bbd6d --- /dev/null +++ b/wishfulfilled-wiki/07_技术文档/技术文档索引.md @@ -0,0 +1,29 @@ +--- +type: technical_docs_index +tags: [技术文档, 索引, Agent检索] +aliases: [技术索引, 技术资料清单] +source: manual +status: active +owner: 技术负责人 +updated: 2026-05 +--- + +# 技术文档索引 + +## 技术文档清单 + +| 模块/系统 | 文档类型 | 文件 | 关联需求 | 负责人 | 更新时间 | 状态 | +|---|---|---|---|---|---|---| +| | | | | | | | + +## Agent 检索关键词 + +| 问法 | 标准术语 | 命中文件 | 答案要点 | +|---|---|---|---| +| | | | | + +## 维护规则 + +- 新增技术方案、接口说明、数据模型后，在本索引登记。 +- 技术文档必须关联需求文档或业务流程。 +- Agent 回答技术实现、接口、数据结构问题时，应优先检索本目录。 diff --git a/wishfulfilled-wiki/07_技术文档/接口说明模板.md b/wishfulfilled-wiki/07_技术文档/接口说明模板.md new file mode 100644 index 0000000..ff18e99 --- /dev/null +++ b/wishfulfilled-wiki/07_技术文档/接口说明模板.md @@ -0,0 +1,51 @@ +--- +type: api_template +tags: [技术文档, 接口, 模板] +aliases: [接口模板, API说明模板] +source: manual +status: active +owner: 技术负责人 +updated: 2026-05 +--- + +# 接口说明模板 + +## 基本信息 + +| 项目 | 内容 | +|---|---| +| 接口名称 | | +| 所属模块 | | +| 关联需求 | | +| 负责人 | | +| 状态 | draft | + +## 接口用途 + + +## 请求说明 + +| 字段 | 类型 | 必填 | 说明 | 示例 | +|---|---|---|---|---| +| | | | | | + +## 响应说明 + +| 字段 | 类型 | 说明 | 示例 | +|---|---|---|---| +| | | | | + +## 业务规则 + + +## 异常码 + +| 异常码 | 含义 | 处理方式 | +|---|---|---| +| | | | + +## Agent 检索字段 + +- 关键词： +- 同义词： +- 典型问法： diff --git a/wishfulfilled-wiki/07_技术文档/系统架构说明模板.md b/wishfulfilled-wiki/07_技术文档/系统架构说明模板.md new file mode 100644 index 0000000..a170729 --- /dev/null +++ b/wishfulfilled-wiki/07_技术文档/系统架构说明模板.md @@ -0,0 +1,53 @@ +--- +type: architecture_template +tags: [技术文档, 架构, 模板] +aliases: [架构说明模板] +source: manual +status: active +owner: 技术负责人 +updated: 2026-05 +--- + +# 系统架构说明模板 + +## 基本信息 + +| 项目 | 内容 | +|---|---| +| 系统/模块 | | +| 关联需求 | | +| 负责人 | | +| 状态 | draft | + +## 背景与目标 + + +## 架构说明 + + +## 模块划分 + +| 模块 | 职责 | 输入 | 输出 | 依赖 | +|---|---|---|---|---| +| | | | | | + +## 数据模型 + + +## 接口关系 + + +## 权限与安全 + + +## 异常与边界 + + +## 部署与配置 + + +## Agent 检索字段 + +- 关键词： +- 同义词： +- 典型问法： diff --git a/wishfulfilled-wiki/08_测试相关/README.md b/wishfulfilled-wiki/08_测试相关/README.md new file mode 100644 index 0000000..7895784 --- /dev/null +++ b/wishfulfilled-wiki/08_测试相关/README.md @@ -0,0 +1,48 @@ +--- +type: testing_home +tags: [测试, 测试用例, 验收, 知识库] +aliases: [测试相关入口, 测试文档] +source: manual +status: active +owner: 测试负责人 +updated: 2026-05 +--- + +# 测试相关 + +本目录用于存放测试计划、测试用例、测试报告、缺陷记录、验收记录和上线检查材料。 + +## 二级入口 + +- [[测试用例索引]] +- [[测试用例模板]] +- [[测试计划模板]] +- [[缺陷记录模板]] +- [[验收记录模板]] +- [[上线检查模板]] + +## 存放内容 + +- 测试计划 +- 测试用例 +- 测试执行记录 +- 缺陷记录 +- 验收记录 +- 上线检查记录 +- 回归测试说明 + +## 命名建议 + +```text +项目或模块_测试用例_YYYYMMDD.md +项目或模块_测试计划_YYYYMMDD.md +项目或模块_缺陷记录_YYYYMMDD.md +项目或模块_验收记录_YYYYMMDD.md +``` + +## 关联目录 + +- 需求依据：[[../05_需求文档/README|需求文档]] +- 技术依据：[[../07_技术文档/README|技术文档]] +- 里程碑依据：[[../06_里程碑/README|里程碑]] +- 流程依据：[[../02_项目管理流程/阶段2.5_测试提前补漏|阶段2.5 测试提前补漏]]、[[../02_项目管理流程/阶段4_测试培训上线回流|阶段4 测试培训上线回流]] diff --git a/wishfulfilled-wiki/08_测试相关/上线检查模板.md b/wishfulfilled-wiki/08_测试相关/上线检查模板.md new file mode 100644 index 0000000..37431c1 --- /dev/null +++ b/wishfulfilled-wiki/08_测试相关/上线检查模板.md @@ -0,0 +1,44 @@ +--- +type: go_live_checklist_template +tags: [上线检查, 测试, 模板] +aliases: [上线检查, 发布检查] +source: manual +status: active +owner: 测试负责人 / 项目经理 +updated: 2026-05 +--- + +# 上线检查模板 + +## 基本信息 + +| 项目 | 内容 | +|---|---| +| 项目/模块 | | +| 关联需求 | | +| 关联里程碑 | | +| 负责人 | | +| 检查日期 | | + +## 上线前检查项 + +| 检查项 | 负责人 | 结果 | 备注 | +|---|---|---|---| +| 需求已确认 | | | | +| 测试用例已执行 | | | | +| P0/P1 缺陷已关闭 | | | | +| 用户培训已完成 | | | | +| 回滚方案已确认 | | | | +| 数据备份已确认 | | | | + +## 上线结论 + + +## 回滚条件 + + +## Agent 检索字段 + +- 关键词： +- 同义词： +- 典型问法： diff --git a/wishfulfilled-wiki/08_测试相关/测试用例模板.md b/wishfulfilled-wiki/08_测试相关/测试用例模板.md new file mode 100644 index 0000000..17afc1f --- /dev/null +++ b/wishfulfilled-wiki/08_测试相关/测试用例模板.md @@ -0,0 +1,45 @@ +--- +type: test_case_template +tags: [测试用例, 测试, 模板] +aliases: [用例模板, 测试用例] +source: manual +status: active +owner: 测试负责人 +updated: 2026-05 +--- + +# 测试用例模板 + +## 基本信息 + +| 项目 | 内容 | +|---|---| +| 项目/模块 | | +| 关联需求 | | +| 关联技术文档 | | +| 测试负责人 | | +| 状态 | draft | + +## 测试范围 + + +## 前置条件 + + +## 测试用例 + +| 用例编号 | 场景 | 前置条件 | 操作步骤 | 预期结果 | 优先级 | 状态 | +|---|---|---|---|---|---|---| +| TC-001 | | | | | P1 | 未执行 | + +## 边界与异常场景 + + +## 验收口径 + + +## Agent 检索字段 + +- 关键词： +- 同义词： +- 典型问法： diff --git a/wishfulfilled-wiki/08_测试相关/测试用例索引.md b/wishfulfilled-wiki/08_测试相关/测试用例索引.md new file mode 100644 index 0000000..3aa09a8 --- /dev/null +++ b/wishfulfilled-wiki/08_测试相关/测试用例索引.md @@ -0,0 +1,30 @@ +--- +type: test_case_index +tags: [测试用例, 测试, 索引, Agent检索] +aliases: [测试用例清单, 用例索引] +source: manual +status: active +owner: 测试负责人 +updated: 2026-05 +--- + +# 测试用例索引 + +## 测试用例清单 + +| 编号 | 项目/模块 | 用例集名称 | 文件 | 关联需求 | 关联技术文档 | 负责人 | 状态 | 更新时间 | +|---|---|---|---|---|---|---|---|---| +| | | | | | | | 未验证 | | + +## Agent 检索关键词 + +| 问法 | 标准术语 | 命中文件 | 答案要点 | +|---|---|---|---| +| | | | | + +## 维护规则 + +- 新增测试用例后，必须在本索引登记。 +- 每个测试用例文件必须关联至少一个需求文档。 +- 若测试用例依赖接口、数据模型或技术方案，应关联技术文档。 +- Agent 回答测试范围、验收口径、缺陷复现问题时，应优先检索本目录。 diff --git a/wishfulfilled-wiki/08_测试相关/测试计划模板.md b/wishfulfilled-wiki/08_测试相关/测试计划模板.md new file mode 100644 index 0000000..dfe056f --- /dev/null +++ b/wishfulfilled-wiki/08_测试相关/测试计划模板.md @@ -0,0 +1,54 @@ +--- +type: test_plan_template +tags: [测试计划, 测试, 模板] +aliases: [测试计划模板] +source: manual +status: active +owner: 测试负责人 +updated: 2026-05 +--- + +# 测试计划模板 + +## 基本信息 + +| 项目 | 内容 | +|---|---| +| 项目/模块 | | +| 关联需求 | | +| 关联里程碑 | | +| 测试负责人 | | +| 计划周期 | | + +## 测试目标 + + +## 测试范围 + + +## 不在范围内 + + +## 测试资源 + + +## 测试安排 + +| 阶段 | 时间 | 负责人 | 输出物 | +|---|---|---|---| +| | | | | + +## 准入条件 + + +## 准出条件 + + +## 风险 + + +## Agent 检索字段 + +- 关键词： +- 同义词： +- 典型问法： diff --git a/wishfulfilled-wiki/08_测试相关/缺陷记录模板.md b/wishfulfilled-wiki/08_测试相关/缺陷记录模板.md new file mode 100644 index 0000000..fe5a795 --- /dev/null +++ b/wishfulfilled-wiki/08_测试相关/缺陷记录模板.md @@ -0,0 +1,53 @@ +--- +type: defect_template +tags: [缺陷, 测试, 模板] +aliases: [Bug记录模板, 缺陷记录] +source: manual +status: active +owner: 测试负责人 +updated: 2026-05 +--- + +# 缺陷记录模板 + +## 基本信息 + +| 项目 | 内容 | +|---|---| +| 缺陷编号 | BUG- | +| 项目/模块 | | +| 关联需求 | | +| 关联用例 | | +| 严重级别 | | +| 当前状态 | open | +| 负责人 | | + +## 问题描述 + + +## 复现步骤 + +1. +2. +3. + +## 实际结果 + + +## 预期结果 + + +## 影响范围 + + +## 修复结论 + + +## 回归验证 + + +## Agent 检索字段 + +- 关键词： +- 同义词： +- 典型问法： diff --git a/wishfulfilled-wiki/08_测试相关/验收记录模板.md b/wishfulfilled-wiki/08_测试相关/验收记录模板.md new file mode 100644 index 0000000..7e0a7fe --- /dev/null +++ b/wishfulfilled-wiki/08_测试相关/验收记录模板.md @@ -0,0 +1,43 @@ +--- +type: acceptance_template +tags: [验收, 测试, 模板] +aliases: [验收记录, UAT模板] +source: manual +status: active +owner: 测试负责人 / 业务负责人 +updated: 2026-05 +--- + +# 验收记录模板 + +## 基本信息 + +| 项目 | 内容 | +|---|---| +| 项目/模块 | | +| 关联需求 | | +| 关联测试用例 | | +| 验收负责人 | | +| 验收日期 | | +| 验收结论 | | + +## 验收范围 + + +## 验收结果 + +| 验收项 | 预期结果 | 实际结果 | 结论 | 备注 | +|---|---|---|---|---| +| | | | | | + +## 遗留问题 + + +## 上线建议 + + +## Agent 检索字段 + +- 关键词： +- 同义词： +- 典型问法： diff --git a/wishfulfilled-wiki/20260517_USER评价业务闭环_共用能力图与渠道专属流程_v2.2.md b/wishfulfilled-wiki/20260517_USER评价业务闭环_共用能力图与渠道专属流程_v2.2.md new file mode 100644 index 0000000..e69de29 diff --git a/wishfulfilled-wiki/AGENTS.md b/wishfulfilled-wiki/AGENTS.md new file mode 100644 index 0000000..79e03ce --- /dev/null +++ b/wishfulfilled-wiki/AGENTS.md @@ -0,0 +1 @@ +# 如愿知识库 Schema`n`n本目录用于 Understand-Anything 的 /understand-knowledge 分析。`n`n- index.md：知识地图和分类入口。`n- log.md：知识库操作日志。`n- raw/：原始来源文件。`n- 其他 Markdown：业务、项目、需求、技术、测试和 Agent 检索知识条目。 diff --git a/wishfulfilled-wiki/index.md b/wishfulfilled-wiki/index.md new file mode 100644 index 0000000..f008c77 --- /dev/null +++ b/wishfulfilled-wiki/index.md @@ -0,0 +1,64 @@ +--- +type: map +tags: [知识地图, 导航] +aliases: [知识库地图] +source: manual +status: active +owner: 内部技术团队 +updated: 2026-05 +--- + +# 知识地图 + +## 使用说明 + +- [[../知识库使用说明|知识库使用说明]] +- [[../Git使用说明|Git 使用说明]] + +## 需求文档 + +- [[../05_需求文档/README|需求文档入口]] +- [[../05_需求文档/需求文档索引|需求文档索引]] +- [[../03_规范与模板/需求说明模板|需求说明模板]] +- [[../03_规范与模板/业务规则与需求补充模板|业务规则与需求补充模板]] +- [[../01_业务流程/业务规则索引|业务规则索引]] +- [[../01_业务流程/业务对象字典|业务对象字典]] + +## 里程碑 + +- [[../06_里程碑/README|里程碑入口]] +- [[../06_里程碑/里程碑索引|里程碑索引]] +- [[../06_里程碑/阶段计划模板|阶段计划模板]] +- [[../06_里程碑/里程碑评审记录|里程碑评审记录]] +- [[../02_项目管理流程/AI驱动内部系统开发流程_V3_总览|项目管理流程总览]] +- [[../02_项目管理流程/阶段交付物清单|阶段交付物清单]] +- [[../02_项目管理流程/项目检查清单|项目检查清单]] + +## 技术文档 + +- [[../07_技术文档/README|技术文档入口]] +- [[../07_技术文档/技术文档索引|技术文档索引]] +- [[../07_技术文档/系统架构说明模板|系统架构说明模板]] +- [[../07_技术文档/接口说明模板|接口说明模板]] +- [[../07_技术文档/技术决策记录|技术决策记录]] + +## 测试相关 + +- [[../08_测试相关/README|测试相关入口]] +- [[../08_测试相关/测试用例索引|测试用例索引]] +- [[../08_测试相关/测试用例模板|测试用例模板]] +- [[../08_测试相关/测试计划模板|测试计划模板]] +- [[../08_测试相关/缺陷记录模板|缺陷记录模板]] +- [[../08_测试相关/验收记录模板|验收记录模板]] +- [[../08_测试相关/上线检查模板|上线检查模板]] +- [[../02_项目管理流程/阶段2.5_测试提前补漏|阶段2.5 测试提前补漏]] +- [[../02_项目管理流程/阶段4_测试培训上线回流|阶段4 测试培训上线回流]] + +## Agent 检索 + +- [[../04_Agent检索/检索说明|检索说明]] +- [[../04_Agent检索/问答提示词|问答提示词]] +- [[../04_Agent检索/关键词索引|关键词索引]] +- [[../04_Agent检索/同义词表|同义词表]] +- [[../04_Agent检索/来源文件索引|来源文件索引]] +- [[../04_Agent检索/知识库持续更新与验证流程|持续更新与验证流程]] diff --git a/wishfulfilled-wiki/log.md b/wishfulfilled-wiki/log.md new file mode 100644 index 0000000..576fa50 --- /dev/null +++ b/wishfulfilled-wiki/log.md @@ -0,0 +1 @@ +# 知识库操作日志`n`n## [2026-05-26] init | 创建 Understand-Anything 知识图谱输入`n`n- 从如愿知识库复制 Markdown 文档。`n- 使用 00_首页/知识地图.md 作为 index.md 分类入口。 diff --git a/wishfulfilled-wiki/raw/AI_驱动_内部系统开发流程_V3.docx b/wishfulfilled-wiki/raw/AI_驱动_内部系统开发流程_V3.docx new file mode 100644 index 0000000..5ea5289 Binary files /dev/null and b/wishfulfilled-wiki/raw/AI_驱动_内部系统开发流程_V3.docx differ diff --git a/wishfulfilled-wiki/未命名.canvas b/wishfulfilled-wiki/未命名.canvas new file mode 100644 index 0000000..9e26dfe --- /dev/null +++ b/wishfulfilled-wiki/未命名.canvas @@ -0,0 +1 @@ +{} \ No newline at end of file diff --git a/wishfulfilled-wiki/欢迎.md b/wishfulfilled-wiki/欢迎.md new file mode 100644 index 0000000..36811e9 --- /dev/null +++ b/wishfulfilled-wiki/欢迎.md @@ -0,0 +1,24 @@ +--- +type: index +tags: [知识库, 入口] +aliases: [欢迎, 首页] +source: manual +status: active +owner: 内部技术团队 +updated: 2026-05 +--- + +# 欢迎使用如愿知识库 + +请从 [[00_首页/知识库首页]] 开始。 + +常用入口： + +- [[知识库使用说明]] +- [[00_首页/知识地图]] +- [[00_首页/Agent问答入口]] +- [[05_需求文档/README|需求文档]] +- [[06_里程碑/README|里程碑]] +- [[07_技术文档/README|技术文档]] +- [[08_测试相关/README|测试相关]] +- [[04_Agent检索/检索说明]] \ No newline at end of file diff --git a/wishfulfilled-wiki/知识库使用说明.md b/wishfulfilled-wiki/知识库使用说明.md new file mode 100644 index 0000000..f8b4d6f --- /dev/null +++ b/wishfulfilled-wiki/知识库使用说明.md @@ -0,0 +1,659 @@ +--- +type: knowledge_base_guide +tags: [知识库, 使用说明, Obsidian, Agent检索] +aliases: [如愿知识库使用说明, 知识库操作说明, 知识库维护说明] +source: manual +status: active +owner: 内部技术团队 +updated: 2026-05 +--- + +# 如愿知识库使用说明 + +本文档说明如愿知识库的用途、目录结构、文档存放规则、索引维护规则、Obsidian 图谱使用方式，以及 Agent 如何基于知识库回答问题。 + +## 1. 知识库定位 + +如愿知识库用于沉淀内部系统建设过程中的： + +- 业务需求 +- 业务规则 +- 业务流程 +- 项目里程碑 +- 技术方案 +- 测试用例 +- 缺陷与验收记录 +- Agent 检索规则 + +知识库不是单纯存文件，而是要形成可检索、可追溯、可被 Agent 引用回答的知识网络。 + +## 2. 推荐打开方式 + +推荐使用 Obsidian 打开以下目录作为 Vault： + +```text +D:\AIcoding\WishFulfilled\知识库\如愿知识库 +``` + +打开后建议从以下入口开始： + +1. [[欢迎]] +2. [[00_首页/知识库首页]] +3. [[00_首页/知识地图]] +4. [[00_首页/Agent问答入口]] +5. [[04_Agent检索/检索说明]] + +## 3. 主目录说明 + +```text +如愿知识库/ +├─ 00_首页/ # 首页、知识地图、Agent 问答入口 +├─ 01_业务流程/ # 业务流程、业务对象、业务规则、补充验证记录 +├─ 02_项目管理流程/ # 项目阶段、角色职责、交付物、检查清单、FAQ +├─ 03_规范与模板/ # 需求、业务规则、会议、上线检查等模板 +├─ 04_Agent检索/ # 检索说明、关键词、同义词、来源文件索引 +├─ 05_需求文档/ # 正式需求文档、需求索引 +├─ 06_里程碑/ # 里程碑计划、阶段计划、评审记录 +├─ 07_技术文档/ # 技术方案、系统架构、接口说明、技术决策 +├─ 08_测试相关/ # 测试用例、测试计划、缺陷、验收、上线检查 +├─ 99_归档/ # 历史文档、废弃文档、仅供参考内容 +├─ 欢迎.md # Obsidian 入口页 +├─ 知识库使用说明.md # 本文档 +└─ Git使用说明.md # Git 仓库协作说明 +``` + +## 4. 日常使用入口 + +| 使用场景 | 优先入口 | +|---|---| +| 想了解知识库整体结构 | [[00_首页/知识地图]] | +| 想让 Agent 回答业务问题 | [[00_首页/Agent问答入口]] | +| 查看或新增需求 | [[05_需求文档/README]] | +| 查看或新增里程碑 | [[06_里程碑/README]] | +| 查看或新增技术方案 | [[07_技术文档/README]] | +| 查看或新增测试用例 | [[08_测试相关/README]] | +| 查看项目管理阶段 | [[02_项目管理流程/AI驱动内部系统开发流程_V3_总览]] | +| 查看 Agent 检索规则 | [[04_Agent检索/检索说明]] | +| 查看来源依据 | [[04_Agent检索/来源文件索引]] | + +## 5. 文档应该放在哪里 + +### 5.1 需求文档 + +放入： + +```text +05_需求文档/ +``` + +适合存放： + +- 正式需求说明 +- 业务规则说明 +- 需求变更说明 +- 业务补充说明 +- 产品口径说明 + +推荐命名： + +```text +业务域_需求或规则名称_YYYYMMDD.md +``` + +示例： + +```text +USER评价业务闭环_数据流与中间对象设计_20260517.md +采购_供应商准入规则_20260526.md +库存_出入库审批规则_20260526.md +``` + +新增后应同步维护： + +- [[05_需求文档/需求文档索引]] +- [[01_业务流程/业务规则索引]]，如涉及业务规则 +- [[01_业务流程/业务对象字典]]，如涉及新增业务对象 +- [[04_Agent检索/关键词索引]]，如需要 Agent 检索命中 +- [[04_Agent检索/来源文件索引]]，如是新的权威来源 + +### 5.2 里程碑文档 + +放入： + +```text +06_里程碑/ +``` + +适合存放： + +- 项目里程碑计划 +- 阶段计划 +- 阶段评审记录 +- 上线节奏 +- 准入/准出记录 + +推荐命名： + +```text +项目名_里程碑计划_YYYYMMDD.md +项目名_阶段评审记录_YYYYMMDD.md +``` + +新增后应同步维护： + +- [[06_里程碑/里程碑索引]] + +### 5.3 技术文档 + +放入： + +```text +07_技术文档/ +``` + +适合存放： + +- 系统架构说明 +- 数据模型说明 +- 接口说明 +- 模块设计 +- 技术方案 +- 部署说明 +- 技术决策记录 + +推荐命名： + +```text +系统或模块_技术方案_YYYYMMDD.md +系统或模块_接口说明_YYYYMMDD.md +系统或模块_数据模型_YYYYMMDD.md +``` + +新增后应同步维护： + +- [[07_技术文档/技术文档索引]] +- [[04_Agent检索/关键词索引]]，如需要 Agent 检索 +- [[04_Agent检索/来源文件索引]]，如是新的技术依据 + +### 5.4 测试相关文档 + +放入： + +```text +08_测试相关/ +``` + +适合存放： + +- 测试计划 +- 测试用例 +- 缺陷记录 +- 验收记录 +- 上线检查 +- 回归测试记录 + +推荐命名： + +```text +项目名_模块名_测试计划_YYYYMMDD.md +项目名_模块名_测试用例_YYYYMMDD.md +项目名_模块名_缺陷记录_YYYYMMDD.md +项目名_模块名_验收记录_YYYYMMDD.md +``` + +新增后应同步维护： + +- [[08_测试相关/测试用例索引]] +- 关联需求文档 +- 关联里程碑或测试阶段 + +测试用例必须能追溯到需求来源。 + +### 5.5 业务流程文档 + +放入： + +```text +01_业务流程/ +``` + +适合存放： + +- 已稳定的业务流程 +- 业务对象定义 +- 业务规则索引 +- 业务补充验证记录 + +如果是新需求或尚未确认的业务规则，优先放入 `05_需求文档/`，确认稳定后再沉淀到 `01_业务流程/`。 + +### 5.6 模板文档 + +放入： + +```text +03_规范与模板/ +``` + +适合存放： + +- 需求说明模板 +- 业务规则补充模板 +- 会议纪要模板 +- 上线检查模板 +- 通用文档模板 + +模板只用于复用格式，不应存放具体项目内容。 + +### 5.7 归档文档 + +放入： + +```text +99_归档/ +``` + +适合存放： + +- 已废弃文档 +- 历史版本 +- 仅供参考内容 +- 不再作为当前依据的旧规则 + +归档文档不应作为 Agent 当前回答依据，除非问题明确询问历史背景。 + +## 6. Agent 检索优先级 + +Agent 回答问题时，按以下顺序查找依据： + +1. `05_需求文档/`：正式需求、业务规则、需求变更。 +2. `06_里程碑/`：项目节点、阶段计划、阶段评审、上线节奏。 +3. `07_技术文档/`：系统架构、数据模型、接口说明、实现方案、技术决策。 +4. `08_测试相关/`：测试计划、测试用例、缺陷记录、验收记录、上线检查。 +5. `02_项目管理流程/`：内部系统开发流程、阶段、角色、门禁、交付物、检查清单。 +6. `01_业务流程/`：真实业务流程、业务对象、业务规则。 +7. `04_Agent检索/`：关键词、同义词、来源索引、回答规则。 +8. `03_规范与模板/`：需要产出模板或文档时使用。 + +Agent 回答必须注明来源文件。 + +## 7. 不同问题应该查哪里 + +| 问题类型 | 优先查找位置 | +|---|---| +| 某个需求是什么 | `05_需求文档/`、`05_需求文档/需求文档索引.md` | +| 某个业务规则是什么 | `05_需求文档/`、`01_业务流程/业务规则索引.md` | +| 某个业务对象怎么定义 | `01_业务流程/业务对象字典.md`、相关需求文档 | +| 项目当前到哪个阶段 | `06_里程碑/`、`06_里程碑/里程碑索引.md` | +| 某阶段要交付什么 | `02_项目管理流程/阶段交付物清单.md` | +| 技术怎么实现 | `07_技术文档/`、`07_技术文档/技术文档索引.md` | +| 接口怎么设计 | `07_技术文档/`、具体接口说明文档 | +| 数据模型怎么设计 | `07_技术文档/`、具体数据模型文档、需求文档 | +| 测试用例在哪里 | `08_测试相关/`、`08_测试相关/测试用例索引.md` | +| 缺陷如何记录 | `08_测试相关/缺陷记录模板.md` | +| 上线前检查什么 | `08_测试相关/上线检查模板.md`、`02_项目管理流程/项目检查清单.md` | +| Agent 为什么这样回答 | `04_Agent检索/检索说明.md`、`04_Agent检索/来源文件索引.md` | + +## 8. 新增文档标准流程 + +新增文档建议按以下流程操作： + +```text +确定文档类型 + ↓ +放入对应目录 + ↓ +按推荐命名规则命名 + ↓ +补充 Frontmatter + ↓ +正文写清背景、规则、流程、验收口径 + ↓ +补充 Agent 检索字段 + ↓ +更新对应索引 + ↓ +更新关键词/来源文件索引 + ↓ +在 Obsidian 中检查链接和图谱 +``` + +## 9. 推荐 Frontmatter + +每个正式文档建议在顶部维护 Frontmatter： + +```yaml +--- +type: requirement +tags: [需求文档, USER评价业务闭环] +aliases: [数据流与中间对象设计] +source: manual +status: active +owner: 产品经理 +updated: 2026-05-26 +--- +``` + +常用字段： + +| 字段 | 说明 | +|---|---| +| `type` | 文档类型，如 requirement、technical_doc、test_case、milestone | +| `tags` | 标签，用于 Obsidian 和 Agent 检索 | +| `aliases` | 别名，便于搜索同义叫法 | +| `source` | 来源，如 manual、docx、meeting、requirement | +| `status` | 状态，如 draft、reviewing、active、deprecated | +| `owner` | 负责人 | +| `updated` | 最近更新时间 | + +## 10. 文档状态说明 + +| 状态 | 含义 | Agent 使用规则 | +|---|---|---| +| `draft` | 草稿 | 只能作为参考，回答时需说明尚未确认 | +| `reviewing` | 评审中 | 可引用但需说明仍在评审 | +| `active` | 已确认 | 可作为正式回答依据 | +| `deprecated` | 已废弃 | 不作为当前规则依据，只能说明历史背景 | + +## 11. 索引维护规则 + +### 11.1 需求索引 + +新增需求文档后，维护： + +```text +05_需求文档/需求文档索引.md +``` + +至少登记： + +- 编号 +- 业务域 +- 需求/规则名称 +- 文件路径 +- 状态 +- 负责人 +- 更新时间 +- 验证状态 + +### 11.2 里程碑索引 + +新增里程碑后，维护： + +```text +06_里程碑/里程碑索引.md +``` + +至少登记： + +- 项目 +- 里程碑名称 +- 文件 +- 阶段 +- 负责人 +- 计划时间 +- 当前状态 + +### 11.3 技术文档索引 + +新增技术文档后，维护： + +```text +07_技术文档/技术文档索引.md +``` + +至少登记： + +- 模块/系统 +- 文档类型 +- 文件 +- 关联需求 +- 负责人 +- 更新时间 +- 状态 + +### 11.4 测试用例索引 + +新增测试用例后，维护： + +```text +08_测试相关/测试用例索引.md +``` + +至少登记： + +- 项目 +- 模块 +- 用例名称 +- 文件 +- 关联需求 +- 测试类型 +- 状态 +- 负责人 + +## 12. Obsidian 链接规则 + +推荐使用 Obsidian 双链： + +```markdown +[[05_需求文档/需求文档索引]] +[[07_技术文档/技术文档索引]] +[[08_测试相关/测试用例索引]] +``` + +也可以使用 Markdown 链接： + +```markdown +[需求文档索引](05_需求文档/需求文档索引.md) +``` + +优先建议使用双链，方便图谱建立关系。 + +## 13. Obsidian 图谱说明 + +Obsidian 图谱会显示两类节点： + +1. 已存在的 Markdown 文件。 +2. 文档中链接到、但本地还不存在的 Markdown 文件。 + +如果你只放了一个文件，但图谱出现多个节点，通常是因为该文件引用了其他文档。 + +示例： + +```markdown +[工作基线 v1.2](20260517_USER评价业务闭环主流程与后续工作基线_v1.2.md) +``` + +即使这个文件尚未放入目录，Obsidian 也可能在图谱中显示它。这是“未创建链接 / dangling link”，不是目录里真的多了文件。 + +如果只想显示真实存在的文件，可在图谱中开启： + +```text +图谱视图 → 筛选 → 仅显示已有文件 +``` + +如果希望知识链路完整，应把被引用的上游文档补充到对应目录。 + +## 14. 知识地图维护规则 + +知识地图文件： + +```text +00_首页/知识地图.md +``` + +知识地图只维护主入口和关键二级入口，不需要把每个具体项目文档都放进去。 + +推荐主结构： + +```text +知识地图 +├─ 需求文档 +├─ 里程碑 +├─ 技术文档 +├─ 测试相关 +└─ Agent 检索 +``` + +新增普通需求、测试用例、技术方案时，一般只维护对应索引，不需要直接改知识地图。 + +只有新增重要分类或核心入口时，才更新知识地图。 + +## 15. Agent 回答规则 + +Agent 基于知识库回答问题时，应遵守： + +1. 先查知识库，再回答。 +2. 优先引用 `active` 状态文档。 +3. 先给结论，再展开依据。 +4. 需求问题优先查需求文档。 +5. 技术问题优先查技术文档。 +6. 测试问题优先查测试相关。 +7. 里程碑问题优先查里程碑。 +8. 如果知识库没有明确记录，回答“知识库未明确记录”。 +9. 不要根据经验补充未记录的事实。 +10. 回答末尾必须说明来源文件。 + +推荐引用格式： + +```text +来源：05_需求文档/xxx.md +``` + +## 16. 测试用例管理要求 + +测试用例应单独存放在： + +```text +08_测试相关/ +``` + +每个测试用例应尽量包含： + +- 用例编号 +- 关联需求 +- 测试模块 +- 前置条件 +- 操作步骤 +- 预期结果 +- 实际结果 +- 优先级 +- 状态 +- 负责人 + +测试用例必须关联需求文档或业务规则，避免出现无法追溯来源的测试项。 + +## 17. 文档关系建议 + +推荐建立以下关系： + +```text +需求文档 + ↓ +里程碑 / 阶段计划 + ↓ +技术文档 + ↓ +测试计划 / 测试用例 + ↓ +缺陷记录 / 验收记录 + ↓ +上线检查 / 复盘回流 +``` + +每个下游文档应尽量写明上游来源。 + +示例： + +```markdown +## 关联文档 + +- 需求来源：[[05_需求文档/xxx需求文档]] +- 技术方案：[[07_技术文档/xxx技术方案]] +- 测试用例：[[08_测试相关/xxx测试用例]] +``` + +## 18. 不建议放入知识库的内容 + +不建议直接放入： + +- 密码 +- Token +- API Key +- 未脱敏客户隐私 +- 未脱敏订单号、电话、邮箱、地址 +- 临时截图 +- 个人草稿 +- 与项目无关的资料 + +如果必须记录敏感业务规则，应先脱敏再写入知识库。 + +## 19. 提交前检查清单 + +新增或修改文档后，检查： + +- [ ] 文件放在正确目录。 +- [ ] 文件名能表达业务域和用途。 +- [ ] 正式文档已写 Frontmatter。 +- [ ] 文档状态正确。 +- [ ] 关键业务规则有来源。 +- [ ] 需求文档已更新需求文档索引。 +- [ ] 技术文档已更新技术文档索引。 +- [ ] 测试用例已更新测试用例索引。 +- [ ] 重要关键词已补充到关键词索引。 +- [ ] 需要追溯的来源已补充到来源文件索引。 +- [ ] Obsidian 链接可以正常跳转，或确认是有意保留的上游虚链接。 +- [ ] 不包含密码、Token、密钥和未脱敏敏感信息。 + +## 20. 常见问题 + +### 20.1 为什么只放一个文档，图谱显示多个节点？ + +因为文档中链接了其他 Markdown 文件。Obsidian 会把被链接但尚未创建的文件也显示成节点。 + +### 20.2 README.md 为什么会出现在图谱里？ + +因为 README.md 也是 Markdown 文件，Obsidian 会把它作为普通节点显示。 + +### 20.3 一个具体项目文档要不要加到知识地图？ + +通常不需要。具体项目文档登记到对应索引即可。知识地图只放主入口和关键二级入口。 + +### 20.4 需求文档和业务流程怎么区分？ + +- 尚在新增、变更、评审中的内容放 `05_需求文档/`。 +- 已稳定、可复用的业务流程沉淀到 `01_业务流程/`。 + +### 20.5 测试用例应该跟需求还是技术文档关联？ + +优先关联需求文档；如果测试点来自技术实现细节，再补充关联技术文档。 + +### 20.6 Agent 回答错了怎么办？ + +优先检查： + +1. 对应文档是否存在。 +2. 文档是否放在正确目录。 +3. 索引是否维护。 +4. 关键词或同义词是否缺失。 +5. 来源文件索引是否登记。 +6. 文档状态是否为 `active`。 + +必要时更新： + +- [[04_Agent检索/关键词索引]] +- [[04_Agent检索/同义词表]] +- [[04_Agent检索/来源文件索引]] +- [[04_Agent检索/知识库持续更新与验证流程]] + +## 21. 维护原则 + +1. 文档要放对目录。 +2. 正式内容要有来源。 +3. 关键文档要有索引。 +4. 测试用例要能追溯需求。 +5. 技术文档要能追溯需求或业务流程。 +6. 里程碑要能追溯阶段目标和交付物。 +7. Agent 回答要能追溯来源文件。 +8. 废弃内容要归档，不要混在当前依据中。 +9. 敏感信息要脱敏。 +10. 知识库持续维护比一次性整理更重要。