{"id":"58db6e86-35e3-46cb-a248-8f123669ffa2","entityType":"agent","slug":"clawhub-boboy-j-digital-solution-designer","name":"digital-solution-designer","canonicalUrl":"https://www.xpersona.co/agent/clawhub-boboy-j-digital-solution-designer","canonicalPath":"/agent/clawhub-boboy-j-digital-solution-designer","generatedAt":"2026-10-10T17:34:50.858Z","source":"CLAWHUB","claimStatus":"UNCLAIMED","verificationTier":"NONE","summary":{"evidence":{"source":"editorial-content","verified":true,"confidence":"high","updatedAt":"2026-10-10T14:22:56.233Z","emptyReason":null},"description":"系统化设计数字化解决方案，涵盖方案类型识别、政策背景分析、需求分析、建设思路设计、架构设计（业务、功能、数据、技术四维度）、技术选型、具体建设内容、实施规划、风险评估和投资估算的全流程能力。适用于规划类、申报类、可研类、投标类和工作汇报类等多种方案产出场景，覆盖政府数字化转型和企业数字化转型两大核心领域。 Skill: digital-solution-designer Owner: boboy-j Summary: 系统化设计数字化解决方案，涵盖方案类型识别、政策背景分析、需求分析、建设思路设计、架构设计（业务、功能、数据、技术四维度）、技术选型、具体建设内容、实施规划、风险评估和投资估算的全流程能力。适用于规划类、申报类、可研类、投标类和工作汇报类等多种方案产出场景，覆盖政府数字化转型和企业数字化转型两大核心领域。 Tags: latest:1.2.0 Version history: v1.2.0 | 2026-05-28T07:48:59.336Z | user **Summary:** This version adds extensible reference documents and strengthens process clarity for digital solution design. - Added f","descriptionLabel":"Technical summary","evidenceSummary":"Capability contract not published. No trust telemetry is available yet. 1.4K downloads reported by the source. Last updated 10/10/2026.","installCommand":"clawhub skill install s17ckg9br2p4k5kx6cr8fc4jz5852pah:digital-solution-designer","sourceUrl":"https://clawhub.ai/boboy-j/digital-solution-designer","homepage":"https://clawhub.ai/boboy-j/skills/digital-solution-designer","primaryLinks":[{"label":"View on ClawHub","url":"https://clawhub.ai/boboy-j/digital-solution-designer","kind":"source"},{"label":"Homepage","url":"https://clawhub.ai/boboy-j/skills/digital-solution-designer","kind":"homepage"}],"safetyScore":84,"overallRank":62,"popularityScore":63,"trustScore":null,"claimedByName":null,"isOwner":false,"seoDescription":"系统化设计数字化解决方案，涵盖方案类型识别、政策背景分析、需求分析、建设思路设计、架构设计（业务、功能、数据、技术四维度）、技术选型、具体建设内容、实施规划、风险评估和投资估算的全流程能力。适用于规划类、申报类、可研类、投标类和工作汇报类等多种方案产出场景，覆盖政府数字化转型和企业数字化转型两大核心领域。 Skill:"},"coverage":{"evidence":{"source":"public-profile","verified":false,"confidence":"medium","updatedAt":"2026-10-10T14:22:56.233Z","emptyReason":null},"protocols":[{"protocol":"OPENCLEW","label":"OpenClaw","status":"self-declared","notes":"Declared in the public agent profile."}],"capabilities":[],"verifiedCount":0,"selfDeclaredCount":1,"capabilityMatrix":{"rows":[{"key":"OPENCLEW","type":"protocol","support":"unknown","confidenceSource":"profile","notes":"Listed on profile"}],"flattenedTokens":"protocol:OPENCLEW|unknown|profile"}},"adoption":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"medium","updatedAt":"2026-10-10T14:22:56.233Z","emptyReason":null},"stars":null,"forks":null,"downloads":1389,"packageName":null,"latestVersion":"1.2.0","tractionLabel":"1.4K downloads"},"release":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"medium","updatedAt":"2026-10-10T14:22:56.081Z","emptyReason":null},"lastUpdatedAt":"2026-10-10T14:22:56.233Z","lastCrawledAt":"2026-10-10T14:22:56.081Z","lastIndexedAt":null,"nextCrawlAt":"2026-10-11T14:22:56.081Z","lastVerifiedAt":null,"highlights":[{"version":"1.2.0","createdAt":"2026-05-28T07:48:59.336Z","changelog":"**Summary:** This version adds extensible reference documents and strengthens process clarity for digital solution design. - Added four key reference files: current-state assessment, enterprise digitalization, industry scenarios, and a solution quality checklist. - Updated and detailed the procedure for solution type identification and information collection. - Enhanced explanations for each solution type, scenario, and process mapping. - Incorporated explicit quality review steps, requiring checklist-based self-assessment before deliverables. - Provided new resource and industry reference links for more comprehensive guidance.","fileCount":15,"zipByteSize":71447},{"version":"1.1.2","createdAt":"2026-04-20T04:01:26.990Z","changelog":"- All reference and documentation files moved from `Reference/` and `Skill.md` to lowercase-named `references/` and `SKILL.md` for improved consistency. - Added a script (`scripts/generate-architecture-diagram.py`) to automate architecture diagram generation. - Resource index and references within documentation updated to reflect the new file paths. - No major logic or workflow changes; this version focuses on file organization and tooling support.","fileCount":10,"zipByteSize":40176},{"version":"1.1.1","createdAt":"2026-04-20T03:51:36.595Z","changelog":"Version 1.1.1 - Added six new reference files: architecture-dimensions, architecture-patterns, government-digitalization, implementation-phases, solution-type-frames, and technology-stack-guide. - Enhanced the documentation with direct references to the new resources for architecture, technology stack, implementation phases, and government digitalization. - No changes to core logic; update focuses on reference material expansion and improved guidance for solution design steps.","fileCount":9,"zipByteSize":37491},{"version":"1.1.0","createdAt":"2026-04-20T03:44:37.916Z","changelog":"- Added comprehensive, step-by-step framework for designing digital solutions, covering type identification, policy analysis, requirements, architecture, implementation, risk, and investment assessment. - Enforced mandatory scheme type inquiry before proceeding; the system now always requests clarification on the solution type. - Defined distinct processes and outputs for five major scheme types (planning, application, feasibility study, bidding, work report), tailored to government and enterprise digital transformation. - Standardized four-dimension architecture (business, functional, data, technical) with required use of the provided Graphviz-based script. - Detailed stage-by-stage documentation requirements, ensuring clarity and completeness throughout the solution design process.","fileCount":3,"zipByteSize":9604}]},"execution":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"low","updatedAt":null,"emptyReason":"No published capability contract is available yet."},"installCommand":"clawhub skill install s17ckg9br2p4k5kx6cr8fc4jz5852pah:digital-solution-designer","setupComplexity":"low","setupSteps":["Setup complexity is LOW. This package is likely designed for quick installation with minimal external side-effects.","Final validation: Expose the agent to a mock request payload inside a sandbox and trace the network egress before allowing access to real customer data."],"contract":{"contractStatus":"missing","authModes":[],"requires":[],"forbidden":[],"supportsMcp":false,"supportsA2a":false,"supportsStreaming":false,"inputSchemaRef":null,"outputSchemaRef":null,"dataRegion":null,"contractUpdatedAt":null,"sourceUpdatedAt":null,"freshnessSeconds":null},"invocationGuide":{"preferredApi":{"snapshotUrl":"https://www.xpersona.co/api/v1/agents/clawhub-boboy-j-digital-solution-designer/snapshot","contractUrl":"https://www.xpersona.co/api/v1/agents/clawhub-boboy-j-digital-solution-designer/contract","trustUrl":"https://www.xpersona.co/api/v1/agents/clawhub-boboy-j-digital-solution-designer/trust"},"curlExamples":["curl -s \"https://www.xpersona.co/api/v1/agents/clawhub-boboy-j-digital-solution-designer/snapshot\"","curl -s \"https://www.xpersona.co/api/v1/agents/clawhub-boboy-j-digital-solution-designer/contract\"","curl -s \"https://www.xpersona.co/api/v1/agents/clawhub-boboy-j-digital-solution-designer/trust\""],"jsonRequestTemplate":{"query":"summarize this repo","constraints":{"maxLatencyMs":2000,"protocolPreference":["OPENCLEW"]}},"jsonResponseTemplate":{"ok":true,"result":{"summary":"...","confidence":0.9},"meta":{"source":"CLAWHUB","generatedAt":"2026-10-10T17:34:50.852Z"}},"retryPolicy":{"maxAttempts":3,"backoffMs":[500,1500,3500],"retryableConditions":["HTTP_429","HTTP_503","NETWORK_TIMEOUT"]}},"endpoints":{"dossierUrl":"https://www.xpersona.co/api/v1/agents/clawhub-boboy-j-digital-solution-designer/dossier","snapshotUrl":"https://www.xpersona.co/api/v1/agents/clawhub-boboy-j-digital-solution-designer/snapshot","contractUrl":"https://www.xpersona.co/api/v1/agents/clawhub-boboy-j-digital-solution-designer/contract","trustUrl":"https://www.xpersona.co/api/v1/agents/clawhub-boboy-j-digital-solution-designer/trust"}},"reliability":{"evidence":{"source":"runtime-metrics","verified":false,"confidence":"low","updatedAt":null,"emptyReason":"No trust, reliability, or runtime telemetry is available."},"trust":{"status":"unavailable","handshakeStatus":"UNKNOWN","verificationFreshnessHours":null,"reputationScore":null,"p95LatencyMs":null,"successRate30d":null,"fallbackRate":null,"attempts30d":null,"trustUpdatedAt":null,"trustConfidence":"unknown","sourceUpdatedAt":null,"freshnessSeconds":null},"decisionGuardrails":{"doNotUseIf":["Contract metadata is missing or unavailable for deterministic execution."],"safeUseWhen":[],"riskFlags":["missing_or_unavailable_contract","trust_data_unavailable","schema_references_missing"],"operationalConfidence":"low"},"executionMetrics":{"observedLatencyMsP50":null,"observedLatencyMsP95":null,"estimatedCostUsd":null,"uptime30d":null,"rateLimitRpm":null,"rateLimitBurst":null,"lastVerifiedAt":null,"verificationSource":null},"runtimeMetrics":{"successRate":null,"avgLatencyMs":null,"avgCostUsd":null,"hallucinationRate":null,"retryRate":null,"disputeRate":null,"p50Latency":null,"p95Latency":null,"lastUpdated":null}},"benchmarks":{"evidence":{"source":"no-benchmark-data","verified":false,"confidence":"low","updatedAt":null,"emptyReason":"No benchmark suites or observed failure patterns are available."},"suites":[],"failurePatterns":[]},"artifacts":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"high","updatedAt":"2026-10-10T14:22:56.233Z","emptyReason":null},"readme":"Skill: digital-solution-designer\n\nOwner: boboy-j\n\nSummary: 系统化设计数字化解决方案，涵盖方案类型识别、政策背景分析、需求分析、建设思路设计、架构设计（业务、功能、数据、技术四维度）、技术选型、具体建设内容、实施规划、风险评估和投资估算的全流程能力。适用于规划类、申报类、可研类、投标类和工作汇报类等多种方案产出场景，覆盖政府数字化转型和企业数字化转型两大核心领域。\n\nTags: latest:1.2.0\n\nVersion history:\n\nv1.2.0 | 2026-05-28T07:48:59.336Z | user\n\n**Summary:**  \nThis version adds extensible reference documents and strengthens process clarity for digital solution design.\n\n- Added four key reference files: current-state assessment, enterprise digitalization, industry scenarios, and a solution quality checklist.\n- Updated and detailed the procedure for solution type identification and information collection.\n- Enhanced explanations for each solution type, scenario, and process mapping.\n- Incorporated explicit quality review steps, requiring checklist-based self-assessment before deliverables.\n- Provided new resource and industry reference links for more comprehensive guidance.\n\nv1.1.2 | 2026-04-20T04:01:26.990Z | user\n\n- All reference and documentation files moved from `Reference/` and `Skill.md` to lowercase-named `references/` and `SKILL.md` for improved consistency.\n- Added a script (`scripts/generate-architecture-diagram.py`) to automate architecture diagram generation.\n- Resource index and references within documentation updated to reflect the new file paths.\n- No major logic or workflow changes; this version focuses on file organization and tooling support.\n\nv1.1.1 | 2026-04-20T03:51:36.595Z | user\n\nVersion 1.1.1\n\n- Added six new reference files: architecture-dimensions, architecture-patterns, government-digitalization, implementation-phases, solution-type-frames, and technology-stack-guide.\n- Enhanced the documentation with direct references to the new resources for architecture, technology stack, implementation phases, and government digitalization.\n- No changes to core logic; update focuses on reference material expansion and improved guidance for solution design steps.\n\nv1.1.0 | 2026-04-20T03:44:37.916Z | user\n\n- Added comprehensive, step-by-step framework for designing digital solutions, covering type identification, policy analysis, requirements, architecture, implementation, risk, and investment assessment.\n- Enforced mandatory scheme type inquiry before proceeding; the system now always requests clarification on the solution type.\n- Defined distinct processes and outputs for five major scheme types (planning, application, feasibility study, bidding, work report), tailored to government and enterprise digital transformation.\n- Standardized four-dimension architecture (business, functional, data, technical) with required use of the provided Graphviz-based script.\n- Detailed stage-by-stage documentation requirements, ensuring clarity and completeness throughout the solution design process.\n\nArchive index:\n\nArchive v1.2.0: 15 files, 71447 bytes\n\nFiles: README.md (29086b), references/architecture-dimensions.md (22256b), references/architecture-patterns.md (7187b), references/current-state-assessment.md (6746b), references/enterprise-digitalization.md (7075b), references/government-digitalization.md (14354b), references/implementation-phases.md (16118b), references/industry-scenarios.md (10305b), references/solution-quality-checklist.md (6445b), references/solution-type-frames.md (8662b), references/technology-stack-guide.md (11312b), scripts/generate-architecture-diagram.py (18390b), skill-card.md (3085b), SKILL.md (33124b), _meta.json (144b)\n\nFile v1.2.0:SKILL.md\n\n---\nname: digital-solution-designer\ndescription: 系统化设计数字化解决方案，涵盖方案类型识别、政策背景分析、需求分析、建设思路设计、架构设计（业务、功能、数据、技术四维度）、技术选型、具体建设内容、实施规划、风险评估和投资估算的全流程能力。适用于规划类、申报类、可研类、投标类和工作汇报类等多种方案产出场景，覆盖政府数字化转型和企业数字化转型两大核心领域。\ndependency:\n  python:\n    - graphviz>=0.20.1\n---\n\n# 数字化解决方案设计\n\n## 任务目标\n系统化设计数字化解决方案，从方案类型识别到实施规划的完整流程，支持多种方案类型的结构化输出。\n\n核心能力：方案类型识别、方案大纲生成、政策背景分析与合规识别、结构化需求分析、建设思路设计、四维度架构设计、技术栈选型、建设内容展开、实施规划、风险评估、投资估算。\n\n核心领域：政府数字化转型、企业数字化转型。\n\n触发条件：\"设计[系统/平台/应用]解决方案\"、\"规划[业务场景]数字化方案\"、\"评估[系统]升级方案\"、\"设计[领域]技术架构\"、\"政府数字化转型\"、\"政务系统\"、\"一网通办\"、\"数字政府\"、\"规划方案\"、\"申报方案\"、\"可研方案\"、\"投标方案\"、\"工作汇报\"\n\n## 方案类型说明\n\n### 支持的方案类型\n\n1. **规划类方案**：初次接触客户，粗颗粒度规划，以打动客户为目的\n   - 适用场景：客户初步接触、需求模糊、需要展示整体愿景\n   - 输出重点：政策背景、现状问题、建设目标及思路、业务架构（简化）、关键建设内容、预期效益\n\n2. **申报类方案**：帮助客户向内部领导汇报并申请立项\n   - 适用场景：客户内部汇报、立项申请、预算审批\n   - 输出重点：建设背景、需求分析、建设目标、四维度架构、主要建设内容、实施计划（简化）、效益分析、费用估算\n\n3. **可研类方案**：项目立项审批核心文件，用于财政预算申请和专家评审\n   - 适用场景：项目立项审批、财政预算申请、专家评审\n   - 输出重点：总论、背景与必要性、需求分析、总体建设方案、建设内容、技术方案与选型、实施计划、投资估算、效益分析、风险分析\n\n4. **投标类方案**：响应招标需求，选拔承建厂商\n   - 适用场景：公开招投标、竞争性谈判\n   - 输出重点：需求理解、总体建设方案、详细功能设计、实施与管理、安全与合规、运维服务、培训方案、报价文件\n\n5. **工作汇报类方案**：项目执行过程中的阶段性汇报\n   - 适用场景：项目执行过程汇报、里程碑评审、需求变更汇报\n   - 输出重点：工作背景、问题、当前工作、成果、问题、下一步计划、需要支持\n\n### 方案类型识别规则（强制执行）\n- **第一步：强制询问**：用户输入需求后，**必须先询问**用户此次需要编写方案的类型，不要通过关键词推导或猜测\n- **询问语**：\"请问您需要产出哪种类型的方案？可选择：规划类、申报类、可研类、投标类、工作汇报类\"\n- **第二步：等待用户确认**：待用户明确反馈方案类型后，再根据用户选择的方案类型进行解决方案内容的编写\n- **补充说明**：如果用户不清楚各类型方案的区别，参考 [references/solution-type-frames.md](references/solution-type-frames.md) 为用户说明各类型方案的特点、适用场景和输出重点\n\n参考文档：[references/solution-type-frames.md](references/solution-type-frames.md)\n\n### 方案类型演进关系\n\n五种方案类型存在递进关系，前一类型的产出可复用为后一类型的基础输入：\n- **规划类 → 申报类**：规划类的建设目标和思路可复用为申报类的建设背景和目标章节\n- **申报类 → 可研类**：申报类的架构设计和建设内容可深化为可研类的详细技术方案\n- **可研类 → 投标类**：可研类的技术方案可复用为投标类的总体建设方案，需增加实施管理、运维、培训等响应性内容\n\n复用原则：高阶方案复用低阶方案的核心结论，同时根据新阶段的评审要求深化细化和补充论证。\n\n## 操作步骤\n\n### 第零阶段：方案类型识别与关键信息收集（必执行）\n\n执行步骤：\n1. **强制询问用户方案类型**（关键步骤，不可跳过）：询问语\"请问您需要产出哪种类型的方案？可选择：规划类、申报类、可研类、投标类、工作汇报类\"，若用户不清楚，参考 [references/solution-type-frames.md](references/solution-type-frames.md) 说明各类型方案特点\n2. **等待用户明确反馈方案类型**：用户确认方案类型后，再进行后续流程\n3. **收集关键约束信息**：方案类型确认后，主动向用户收集以下关键信息（若用户未提供，根据已有信息合理推断并标注假设）：\n   - 所属领域：政府/企业，细分行业（如政务、医疗、教育、金融、制造等），参考 [references/industry-scenarios.md](references/industry-scenarios.md) 定位行业场景\n   - 建设规模：预算范围、建设周期、覆盖范围（部门/地域）\n   - 现有基础：现有系统情况、信息化成熟度、技术团队能力\n   - 核心诉求：最需要解决的 1-3 个核心问题\n4. **生成方案大纲**：方案类型和关键信息确认后，参考 [references/solution-type-frames.md](references/solution-type-frames.md) 生成方案大纲（目录结构），向用户展示整体框架并确认，后续按大纲逐章节展开\n5. **根据方案类型和关键信息调整后续流程**：参考\"方案类型与流程映射说明\"选择对应的执行阶段\n检查点：✅ 方案类型已通过询问明确、✅ 关键约束信息已收集、✅ 方案大纲已确认\n\n---\n\n### 方案类型与流程映射说明\n\n**规划类方案**流程：\n- 执行：第零阶段 → 第一阶段 → 第二阶段（简化）→ 第三阶段 → 4.1（业务架构，简化）→ 第六阶段（简化）→ 效益分析\n- 跳过：4.2-4.4、第五阶段、第七阶段（详细版）、第八阶段\n\n**申报类方案**流程：\n- 执行：第零阶段 → 第一阶段 → 第二阶段 → 第三阶段 → 第四阶段 → 第六阶段 → 第七阶段（简化）→ 效益分析 → 费用估算\n- 跳过：第五阶段（详细版）、第八阶段（详细版）\n\n**可研类方案**流程：\n- 执行：全部阶段 + 投资估算（替代费用估算）\n- 重点：需求细化（业务/用户/功能/数据/性能/安全/运维），技术选型详尽（含信创适配）\n\n**投标类方案**流程：\n- 执行：第零阶段 → 第二阶段（需求理解）→ 第三阶段（建设方案）→ 第四阶段（四维度架构）→ 10.1（详细功能设计）→ 10.2（实施与管理）→ 10.3（安全与合规）→ 10.4（运维服务）→ 10.5（培训方案）→ 报价文件\n- 跳过：第一阶段、第五阶段（独立为技术方案章节）、第八阶段（合并到项目管理）\n\n**工作汇报类方案**流程：\n- 执行：特殊流程，不使用标准八阶段流程\n- 结构：工作背景 → 问题 → 当前工作及完成情况 → 已有成果及成效 → 存在的问题 → 下一步计划 → 需要支持\n\n### 方案质量评审（完成后必执行）\n\n方案编写完成后，必须参照 [references/solution-quality-checklist.md](references/solution-quality-checklist.md) 进行质量自审：\n1. 通用质量标准检查：完整性、一致性、逻辑性、可读性、规范性\n2. 按方案类型执行对应检查清单（规划类8项/申报类9项/可研类11项/投标类10项/工作汇报类8项）\n3. 四维度架构一致性校验（业务↔功能↔数据↔技术映射关系检查）\n4. 未通过项必须补充修改，全部通过后方可交付\n\n---\n\n### 第一阶段：政策背景分析\n\n执行步骤：\n1. 梳理政策环境（国家/行业/地方/国际政策）\n2. 分析政策影响（指导意义、机遇、约束、趋势）\n3. 识别合规要求（法律法规、行业标准、数据安全、技术标准）\n4. 输出政策分析报告（政策环境、关键解读、合规清单、机遇挑战）\n检查点：✅ 政策环境梳理全面、✅ 合规要求识别清晰、✅ 政策影响分析到位\n\n---\n\n### 第二阶段：需求分析\n\n执行步骤：\n1. 现状评估：参考 [references/current-state-assessment.md](references/current-state-assessment.md)，按信息化现状评估框架进行系统盘点\n   - 政府场景：政务系统盘点、一网通办/数据共享/信创/等保/跨部门协同五维评估\n   - 企业场景：数字化成熟度评估（L1-L5五级模型）、业务数字化/数据资产化/运营智能化/生态协同化/组织敏捷化五维评估\n2. 行业现状分析（趋势、技术、竞争、痛点）\n3. 客户现状问题分析：基于评估结果识别差距和痛点，按影响范围×紧迫程度排序\n4. 收集核心需求（业务目标、用户场景、功能范围、非功能需求、约束条件）\n5. 需求优先级排序（MoSCoW 方法、MVP 范围、基础/增强/创新需求）\n6. 输出需求文档（现状评估报告、行业/客户现状分析、需求概述、功能清单、非功能需求、MVP 定义）\n检查点：✅ 现状评估系统完整、✅ 行业现状分析深入、✅ 客户问题诊断准确、✅ 业务价值明确、✅ 功能边界清晰、✅ MVP 范围可界定\n\n---\n\n### 第三阶段：建设思路设计\n\n执行步骤：\n1. 确定总体建设目标（战略愿景、量化目标、价值主张、成功标准）\n2. 制定建设原则（业务价值导向、用户体验中心、技术业务融合、渐进演进）\n3. 设计建设路径（自建/采购/合作、传统/云原生/信创、实施模式、转型策略）\n4. 规划分期建设（分期原则、各期目标范围、交付物、依赖关系）\n5. 输出建设思路文档（目标愿景、建设原则、路径策略、分期规划、价值主张）\n检查点：✅ 建设目标清晰可量化、✅ 建设原则指导性强、✅ 建设路径合理可行、✅ 分期规划逻辑清晰\n\n---\n\n### 第四阶段：架构设计（四维度）\n\n架构图生成方式：推荐使用预设模板（`--template`），也可自定义 DOT 文件（`--input`），参考 [references/architecture-dimensions.md](references/architecture-dimensions.md)\n\n#### 4.1 业务架构\n\n执行步骤：\n1. 梳理业务流程（核心/支撑/管理/跨部门协同）\n2. 识别业务能力（核心/支撑/管理/集成能力）\n3. 设计业务关系（实体/协作/流转/服务关系）\n4. 生成业务架构图：`python scripts/generate-architecture-diagram.py --template business-4layer --output business.png` 或自定义 DOT 文件\n5. 输出业务架构文档（架构图、流程清单、能力清单、协作模式）\n\n#### 4.2 功能架构\n\n执行步骤：\n1. 划分功能模块（按业务领域/用户角色/系统层次/业务能力）\n2. 设计功能层次（核心/支撑/增强/集成功能层）\n3. 设计功能关系（依赖/调用/协作/复用关系）\n4. 生成功能架构图：`python scripts/generate-architecture-diagram.py --template functional-3layer --output functional.png` 或自定义 DOT 文件\n5. 输出功能架构文档（架构图、模块清单、层次划分、关系矩阵）\n\n#### 4.3 数据架构\n\n执行步骤：\n1. 设计数据模型（实体/属性/关系/类型约束）\n2. 设计数据流（业务/系统/跨系统数据流，采集/存储/处理/应用）\n3. 设计数据标准（字典/编码/质量管理标准）\n4. 设计数据治理（分类分级/安全隐私/生命周期/共享开放）\n5. 生成数据架构图：`python scripts/generate-architecture-diagram.py --template data-flow --output data.png` 或自定义 DOT 文件\n6. 输出数据架构文档（模型图、数据流图、标准规范、治理方案）\n\n#### 4.4 技术架构\n\n执行步骤：\n1. 确定技术架构模式（参考 [references/architecture-patterns.md](references/architecture-patterns.md)）\n2. 设计部署架构（拓扑/分层/容器化/高可用容灾）\n3. 设计安全架构（网络/应用/数据/运维安全）\n4. 设计集成架构（API网关/服务注册/消息队列/数据交换）\n5. 生成技术架构图：`python scripts/generate-architecture-diagram.py --template technical-microservice --output technical.png` 或 `--template gov-cloud --output gov.png`，也可自定义 DOT 文件\n6. 输出技术架构文档（架构图、部署/安全/集成架构设计）\n\n架构设计整体检查点：✅ 四维度协同一致 ✅ 满足需求 ✅ 符合建设思路 ✅ 可落地实施\n\n---\n\n### 第五阶段：技术选型\n\n执行步骤：\n1. 确定技术选型维度（前端、后端、数据存储、中间件、基础设施）\n2. 技术栈评估：参考 [references/technology-stack-guide.md](references/technology-stack-guide.md)，评估成熟度、社区生态、团队能力、成本，进行关键技术权衡；政府场景需评估信创适配方案（国产OS/DB/中间件/芯片），参考文档中信创适配技术栈章节\n3. 输出技术选型文档（技术栈清单、选型依据与权衡、潜在风险与备选方案）\n检查点：✅ 技术选型有明确依据、✅ 考虑了团队能力匹配、✅ 关键技术有备选方案\n\n---\n\n### 第六阶段：具体建设内容\n\n本阶段将四维度架构设计转化为具体建设任务和交付物。\n\n#### 6.1 业务架构展开\n1. 业务流程实施设计（关键流程设计、流程优化、跨部门协同）\n2. 业务能力建设计划（实施路径、时间表、资源需求）\n3. 业务关系实现设计（协作机制、服务契约）\n\n#### 6.2 功能架构展开\n1. 功能模块开发计划（功能点清单、开发计划、验收标准）\n2. 功能层次实施策略（核心/支撑/增强/集成功能的实施顺序）\n3. 功能关系实现设计（接口设计、数据流设计）\n\n#### 6.3 数据架构展开\n1. 数据模型实现设计（表结构、数据字典、数据初始化）\n2. 数据流实现设计（ETL 方案、同步策略、缓存策略）\n3. 数据标准与治理实施（数据规范、质量管控、安全权限、生命周期）\n\n#### 6.4 技术架构展开\n1. 部署架构实施设计（环境准备、部署方案、监控方案）\n2. 安全架构实施设计（安全策略、安全配置、安全测试）\n3. 集成架构实施设计（API 设计、中间件配置、系统集成）\n\n整体检查点：✅ 四维度建设内容覆盖完整 ✅ 建设任务可落地可跟踪 ✅ 与技术选型和实施规划对接\n\n---\n\n### 第七阶段：实施规划\n\n执行步骤：\n1. 规划实施阶段：参考 [references/implementation-phases.md](references/implementation-phases.md)，阶段划分 MVP → 功能扩展 → 优化完善，每阶段目标与交付物；政府项目需遵循采购流程、审计要求、验收标准、资金管理和合规审查，参考文档中\"政府项目特有实施流程\"章节\n2. 任务分解与排期（WBS、任务依赖、资源需求）\n3. 关键里程碑定义（MVP 发布、功能完整版、生产就绪版）\n4. 输出实施计划（阶段规划、里程碑时间表、资源需求）\n检查点：✅ MVP 可快速交付、✅ 阶段划分合理、✅ 里程碑可度量\n\n---\n\n### 第八阶段：风险评估\n\n执行步骤：\n1. 识别关键风险（技术、业务、项目、运维风险）\n2. 风险评估（发生概率、影响程度、风险等级）\n3. 制定缓解策略（预防措施、应急预案、责任人）\n4. 输出风险清单（风险分类与等级、缓解措施、监控指标）\n检查点：✅ 关键风险已识别、✅ 高风险有缓解措施、✅ 风险可跟踪\n\n#### 9.1 效益分析\n\n执行步骤：\n1. 经济效益分析\n   - 成本节约（人力成本、运营成本）\n   - 收入增长（新业务、效率提升）\n   - 投资回报率（ROI）计算\n\n2. 社会效益分析（政府场景重点）\n   - 服务效率提升\n   - 群众满意度提升\n   - 政府治理能力提升\n\n3. 管理效益分析（企业场景重点）\n   - 管理效率提升\n   - 决策支持能力提升\n   - 业务协同能力提升\n\n检查点：✅ 经济效益可量化、✅ 社会/管理效益明确\n\n---\n\n#### 9.2 投资估算（申报/可研/投标类必需）\n\n执行步骤：\n1. 确定投资估算依据（参考市场价格、行业标准、类似项目）\n2. 总投资估算（分项说明）：\n   - 硬件设备费（服务器、存储、网络设备等）\n   - 软件购置费/开发费（基础软件、定制开发）\n   - 实施服务费（咨询、实施、集成）\n   - 数据资源费（数据采集、清洗、迁移）\n   - 安全测评费（等保测评、安全评估）\n   - 培训费（培训讲师、培训材料）\n   - 运维费（年度运维、技术支持）\n\n3. 资金筹措方案\n   - 资金来源（财政拨款、自筹资金）\n   - 分期资金安排\n   - 资金使用计划\n\n检查点：✅ 投资估算依据充分、✅ 分项明细完整、✅ 资金筹措方案可行\n\n---\n\n### 第十阶段：特殊章节（按方案类型增加）\n\n#### 10.1 详细功能设计（投标类必需）\n\n执行步骤：\n1. 管理后台功能设计\n   - 用户管理、角色权限、系统配置\n   - 业务功能模块详细设计\n\n2. 运维平台功能设计\n   - 系统监控、日志管理、告警管理\n   - 性能监控、故障诊断\n\n3. 数据服务与分析功能设计\n   - 数据查询、统计分析、报表展示\n   - 数据挖掘、智能分析\n\n4. 功能清单输出（按照招标需求逐项响应）\n\n检查点：✅ 功能模块完整覆盖招标需求、✅ 功能描述详细准确\n\n---\n\n#### 10.2 项目实施与管理（投标类必需）\n\n执行步骤：\n1. 项目组织架构设计（项目经理、技术负责人、开发团队、测试团队）\n2. 关键人员简历（资质、经验、项目案例）\n3. 实施方法论（敏捷开发、瀑布模型、混合模式）\n4. 项目进度计划（甘特图、关键路径）\n5. 质量管理方案（质量标准、测试方案、质量评审）\n6. 风险管控（风险识别、风险评估、应对措施）\n7. 变更管理（变更流程、变更评审、变更记录）\n\n检查点：✅ 组织架构合理、✅ 人员资质符合要求、✅ 实施方法论可行\n\n---\n\n#### 10.3 信息安全与合规（投标/可研类必需）\n\n执行步骤：\n1. 网络安全方案（防火墙、入侵检测、网络隔离）\n2. 数据安全方案（数据加密、数据脱敏、数据备份）\n3. 应用安全方案（身份认证、访问控制、安全审计）\n4. 等保测评与合规（政府场景：等保三级测评、合规评估）\n5. 安全管理制度与应急响应\n\n检查点：✅ 安全方案覆盖全面、✅ 符合等保要求（政府场景）\n\n---\n\n#### 10.4 运维服务与保障（投标类必需）\n\n执行步骤：\n1. 运维服务模式（远程运维、驻场运维、混合模式）\n2. 运维内容（系统巡检、故障处理、性能优化）\n3. 服务级别协议（SLA）（响应时间、解决时间、可用性）\n4. 运维团队与工具（运维人员、运维平台、监控系统）\n5. 售后保障机制（服务热线、升级流程、投诉渠道）\n\n检查点：✅ 运维内容覆盖全面、✅ SLA 明确可执行\n\n---\n\n#### 10.5 培训方案（投标类必需）\n\n执行步骤：\n1. 培训计划（培训对象、培训时间、培训周期）\n2. 培训内容与教材（业务操作培训、技术培训、管理培训）\n3. 培训方式（集中培训、在线培训、现场指导）\n4. 培训考核与效果保障（考核方式、效果评估、持续支持）\n\n检查点：✅ 培训计划完整、✅ 培训内容实用\n\n---\n\n## 可选分支\n\n- **快速原型场景**：简化为 政策背景分析 → 需求分析 → 快速架构（四维度简化）→ 技术选型 → 具体建设内容（简化）→ 原型实现\n- **企业级系统**：强调安全、合规、高可用性设计\n- **创新项目**：增加可行性验证阶段，采用实验性技术\n- **遗留系统迁移**：增加现状评估、迁移策略设计\n- **政府数字化转型场景**：参考 [references/government-digitalization.md](references/government-digitalization.md)\n  - 扩展流程：政策合规分析（数据安全法/等保/信创）→ 跨部门协同需求 → 一网通办/数据共享建设思路 → 便民化架构设计\n  - 特殊输出：合规安全方案、信创适配说明、数据安全与隐私保护方案、跨部门协同机制设计、服务便民化设计方案\n- **企业数字化转型场景**：参考 [references/enterprise-digitalization.md](references/enterprise-digitalization.md)\n  - 扩展流程：数字化成熟度评估（L1-L5）→ ROI导向建设思路 → 中台/SaaS/混合云架构选型\n  - 特殊输出：数字化成熟度评估报告、ROI分析与投资回报预测、变革管理方案、组织能力提升方案\n\n## 资源索引\n\n- 必要脚本：见 [scripts/generate-architecture-diagram.py](scripts/generate-architecture-diagram.py)（用途：生成业务、功能、数据、技术架构图和流程图；参数：diagram-type, input, output, template, list-templates；模板：business-4layer, functional-3layer, data-flow, technical-microservice, gov-cloud）\n- 行业场景库：见 [references/industry-scenarios.md](references/industry-scenarios.md)（何时读取：第零阶段识别行业领域时，含智慧政务/城市/医疗/教育/交通/金融/制造7大行业场景）\n- 方案类型框架：见 [references/solution-type-frames.md](references/solution-type-frames.md)（何时读取：第零阶段方案类型识别时，也用于生成方案大纲）\n- 架构模式参考：见 [references/architecture-patterns.md](references/architecture-patterns.md)（何时读取：第四阶段技术架构设计时）\n- 架构维度参考：见 [references/architecture-dimensions.md](references/architecture-dimensions.md)（何时读取：第四阶段四维度架构设计时）\n- 技术选型指南：见 [references/technology-stack-guide.md](references/technology-stack-guide.md)（何时读取：第五阶段技术选型时）\n- 实施阶段参考：见 [references/implementation-phases.md](references/implementation-phases.md)（何时读取：第七阶段实施规划时）\n- 政府数字化转型参考：见 [references/government-digitalization.md](references/government-digitalization.md)（何时读取：政府数字化转型场景）\n- 企业数字化转型参考：见 [references/enterprise-digitalization.md](references/enterprise-digitalization.md)（何时读取：企业数字化转型场景，含数字化成熟度评估模型、典型场景与实施路径）\n- 方案质量评审检查清单：见 [references/solution-quality-checklist.md](references/solution-quality-checklist.md)（何时读取：方案完成后质量自审，含各方案类型检查清单和四维度架构一致性校验）\n- 现状评估方法论：见 [references/current-state-assessment.md](references/current-state-assessment.md)（何时读取：第二阶段需求分析时的现状评估，含信息化现状评估框架、政府/企业场景评估方法、数字化成熟度模型）\n\n## 注意事项\n\n- **方案类型识别强制要求**：用户输入需求后，**必须先询问**用户方案类型，不要通过关键词推导或猜测，等待用户明确反馈后再进行方案编写\n- **阶段迭代**：不需要线性完成所有阶段，根据方案类型选择需要的阶段执行\n- **产出导向**：每个阶段都应产出明确文档或决策，避免过度设计\n- **业务优先**：技术方案必须服务于业务目标，避免技术驱动\n- **平衡原则**：在理想方案与实际约束之间找到平衡点\n- **持续验证**：关键设计决策应通过原型、POC 或评审验证\n- **政策合规**：政府场景需严格遵守政策法规要求，确保合规安全\n- **四维度协同**：业务架构、功能架构、数据架构、技术架构需协同一致，相互支撑\n- **现状驱动**：需求分析需深入行业现状和客户现状，必要时主动向用户获取现状信息或从互联网搜索同类客户共性现状\n- **思路清晰**：建设思路设计需明确目标、原则、路径、分期，指导后续实施\n- **架构图生成**：架构设计阶段应使用 `scripts/generate-architecture-diagram.py` 生成可视化架构图\n  - 前置：`pip install graphviz` + `apt-get install graphviz`\n  - **模板模式（推荐）**：`--template business-4layer/functional-3layer/data-flow/technical-microservice/gov-cloud`，`--list-templates` 列出全部\n  - 自定义 DOT：`--input` 传入，支持 subgraph/style/color/rank 完整语法，中文自动适配\n  - 输出：PNG、SVG、PDF\n- **方案类型适配**：不同方案类型对应不同的输出结构和深度要求，参考 [references/solution-type-frames.md](references/solution-type-frames.md) 严格执行框架结构\n- **关键信息收集**：方案类型确认后，需主动收集所属领域、建设规模、现有基础、核心诉求等关键约束信息；若用户未提供，合理推断并标注假设\n- **方案大纲先行**：方案类型确认后，先生成方案大纲（目录结构）向用户展示并确认，再按大纲逐章节展开，避免方向偏差\n- **行业场景适配**：根据用户所属行业参考 [references/industry-scenarios.md](references/industry-scenarios.md)，使用行业术语和行业痛点，避免泛化描述\n- **方案演进复用**：规划类→申报类→可研类→投标类存在递进关系，高阶方案应复用低阶方案的核心结论，避免重复劳动\n- **方案质量评审**：方案完成后必须执行质量评审，参照 [references/solution-quality-checklist.md](references/solution-quality-checklist.md) 逐项检查，未通过项必须修改\n- **现状评估深度**：需求分析阶段必须进行系统化的现状评估，参考 [references/current-state-assessment.md](references/current-state-assessment.md)，政府场景重点盘点政务系统和政策合规，企业场景重点评估数字化成熟度\n- **信创适配**：政府场景技术选型必须考虑信创适配，参考 [references/technology-stack-guide.md](references/technology-stack-guide.md) 中信创适配技术栈章节，包含国产OS/DB/中间件/芯片的全栈方案和渐进式迁移策略\n- **政府项目合规**：政府项目实施需遵循采购流程、审计要求、验收标准、资金管理和合规审查，参考 [references/implementation-phases.md](references/implementation-phases.md) 中\"政府项目特有实施流程\"章节\n\n## 使用示例\n\n### 示例 0：方案类型识别与关键信息收集（强制流程）\n- **功能**：用户输入需求后，强制询问方案类型，收集关键约束信息，待用户明确后再进行方案编写\n- **执行方式**：智能体主导，第零阶段必执行\n- **关键指导**：\n  - **强制要求**：用户输入需求后，**必须先询问**用户方案类型，不要通过关键词推导或猜测\n  - 询问语：\"请问您需要产出哪种类型的方案？可选择：规划类、申报类、可研类、投标类、工作汇报类\"\n  - 若用户不清楚，参考 [references/solution-type-frames.md](references/solution-type-frames.md) 为用户说明各类型方案的特点、适用场景和输出重点\n  - **等待用户明确反馈方案类型后**，收集关键约束信息：所属领域、建设规模、现有基础、核心诉求\n  - 根据确认的方案类型和关键信息选择对应的执行阶段和输出结构\n\n### 示例 1：规划类方案 - 政务服务平台规划\n- **功能**：为某政府部门设计粗颗粒度的政务服务平台规划方案\n- **执行方式**：智能体主导，执行规划类方案流程\n- **关键指导**：\n  - 方案类型：规划类方案\n  - 执行阶段：第零阶段 → 第一阶段（政策背景分析）→ 第二阶段（需求分析，简化）→ 第三阶段（建设思路设计）→ 4.1（业务架构，简化）→ 第六阶段（具体建设内容，简化）→ 效益分析\n  - 输出重点：政策背景分析、现状问题、建设目标及思路、业务架构（简化）、关键建设内容、预期效益\n  - 内容特点：粗颗粒度、强调愿景和方向，不涉及详细设计和费用\n\n### 示例 2：申报类方案 - 企业数字化管理系统申报\n- **功能**：为企业设计数字化管理系统申报方案，用于内部立项申请\n- **执行方式**：智能体主导，执行申报类方案流程\n- **关键指导**：\n  - 方案类型：申报类方案\n  - 执行阶段：第零阶段 → 第一阶段 → 第二阶段 → 第三阶段 → 第四阶段（四维度架构）→ 第六阶段（主要建设内容）→ 第七阶段（实施规划，简化）→ 效益分析 → 费用估算\n  - 输出重点：建设背景、需求分析、建设目标、四维度架构、主要建设内容、实施计划（简化）、效益分析、费用估算\n  - 内容特点：较规划类更细化，包含费用估算，架构设计涵盖四维度\n\n### 示例 3：可研类方案 - 政府数字政府建设可研\n- **功能**：为政府数字政府建设项目设计可行性研究报告\n- **执行方式**：智能体主导，执行可研类方案流程（全部阶段）\n- **关键指导**：\n  - 方案类型：可研类方案\n  - 执行阶段：全部阶段（第零阶段至第八阶段）+ 投资估算（第九阶段）\n  - 输出重点：总论、背景与必要性、需求分析（细化）、总体建设方案、建设内容、技术方案与选型（详细）、实施计划、投资估算、效益分析、风险分析\n  - 需求分析需细化：业务、用户、功能、数据、性能、安全、运维\n  - 技术选型需详细：技术路线、关键技术、软硬件选型、集成方案、信创适配（政府场景）\n  - 内容特点：内容最全面、最细化，包含详细的投资估算和风险分析\n\n### 示例 4：投标类方案 - 政务云平台投标\n- **功能**：为政务云平台招标项目设计投标方案\n- **执行方式**：智能体主导，执行投标类方案流程\n- **关键指导**：\n  - 方案类型：投标类方案\n  - 执行阶段：第零阶段 → 第二阶段（项目需求理解与分析）→ 第三阶段（总体建设方案）→ 第四阶段（四维度架构）→ 10.1（详细功能设计）→ 10.2（项目实施与管理方案）→ 10.3（信息安全与合规方案）→ 10.4（运维服务与保障方案）→ 10.5（培训方案）→ 报价文件\n  - 输出重点：需求理解、总体建设方案、详细功能设计、实施与管理、安全与合规、运维服务、培训方案、报价文件\n  - 详细功能设计需按照招标需求逐项响应，并附上功能清单\n  - 内容特点：围绕招标需求响应，强调技术实力、实施能力、管理能力和价格竞争力\n\n### 示例 5：工作汇报类方案 - 项目阶段性汇报\n- **功能**：为项目执行过程设计阶段性工作汇报方案\n- **执行方式**：智能体主导，执行工作汇报类方案特殊流程\n- **关键指导**：\n  - 方案类型：工作汇报类方案\n  - 执行流程：特殊流程，不使用标准八阶段流程\n  - 输出结构：工作背景 → 需要解决的问题 → 当前正在开展的工作内容及完成情况 → 已经产生的工作成果及成效 → 当前工作开展中存在的问题 → 下一步工作计划 → 需要领导给予的支持\n  - 内容特点：简洁实用，重点突出工作进展、成果和需要支持的事项\n\n### 示例 6：生成架构图\n- **功能**：使用脚本生成各类架构图\n- **执行方式**：调用 `scripts/generate-architecture-diagram.py` 脚本\n- **关键指导**：\n  - 前置安装：`pip install graphviz` 和 `apt-get install graphviz`\n  - **模板模式（推荐）**：\n    - 生成业务架构图：`python scripts/generate-architecture-diagram.py --template business-4layer --output business.png`\n    - 生成功能架构图：`python scripts/generate-architecture-diagram.py --template functional-3layer --output functional.png`\n    - 生成数据架构图：`python scripts/generate-architecture-diagram.py --template data-flow --output data.png`\n    - 生成技术架构图：`python scripts/generate-architecture-diagram.py --template technical-microservice --output technical.png`\n    - 生成政务云架构图：`python scripts/generate-architecture-diagram.py --template gov-cloud --output gov.png`\n  - 自定义 DOT 模式：编写 DOT 格式文件，支持 subgraph、style、color 等完整语法\n    - `python scripts/generate-architecture-diagram.py --diagram-type business --input business.dot --output business.png`\n\nFile v1.2.0:README.md\n\n# 数字化解决方案设计 Skill\n\n本 Skill 用于系统化设计数字化解决方案，涵盖方案类型识别、政策背景分析、需求分析、建设思路设计、架构设计（业务/功能/数据/技术四维度）、技术选型、具体建设内容、实施规划、风险评估和投资估算的全流程能力。支持规划类、申报类、可研类、投标类和工作汇报类等多种方案产出场景，覆盖政府数字化转型和企业数字化转型两大核心领域。\n\n## 任务目标\n\n系统化设计数字化解决方案，从方案类型识别到实施规划的完整流程，支持多种方案类型的结构化输出。\n\n- **核心能力**：方案类型识别、方案大纲生成、政策背景分析与合规识别、结构化需求分析、建设思路设计、四维度架构设计、技术栈选型、建设内容展开、实施规划、风险评估、投资估算\n- **核心领域**：政府数字化转型、企业数字化转型\n- **触发条件**：\"设计[系统/平台/应用]解决方案\"、\"规划[业务场景]数字化方案\"、\"评估[系统]升级方案\"、\"设计[领域]技术架构\"、\"政府数字化转型\"、\"政务系统\"、\"一网通办\"、\"数字政府\"、\"规划方案\"、\"申报方案\"、\"可研方案\"、\"投标方案\"、\"工作汇报\"\n\n## 方案类型说明\n\n### 支持的方案类型\n\n#### 1. 规划类方案\n- **适用场景**：初次接触客户，粗颗粒度规划，以打动客户为目的\n- **输出重点**：政策背景、现状问题、建设目标及思路、业务架构（简化）、关键建设内容、预期效益\n\n#### 2. 申报类方案\n- **适用场景**：客户内部汇报、立项申请、预算审批\n- **输出重点**：建设背景、需求分析、建设目标、四维度架构、主要建设内容、实施计划（简化）、效益分析、费用估算\n\n#### 3. 可研类方案\n- **适用场景**：项目立项审批、财政预算申请、专家评审\n- **输出重点**：总论、背景与必要性、需求分析（细化至业务/用户/功能/数据/性能/安全/运维）、总体建设方案、建设内容、详细技术方案与选型（含信创适配）、实施计划、投资估算、效益分析、风险分析\n\n#### 4. 投标类方案\n- **适用场景**：公开招投标、竞争性谈判\n- **输出重点**：需求理解、总体建设方案、详细功能设计、实施与管理、安全与合规、运维服务、培训方案、报价文件\n\n#### 5. 工作汇报类方案\n- **适用场景**：项目执行过程汇报、里程碑评审、需求变更汇报\n- **输出结构**：工作背景 → 需要解决的问题 → 当前工作及完成情况 → 成果及成效 → 存在问题 → 下一步计划 → 需要领导支持\n\n### 方案类型识别规则（强制执行）\n\n1. **第一步：强制询问**：用户输入需求后，**必须先询问**用户此次需要编写方案的类型，不要通过关键词推导或猜测\n2. **询问语**：\"请问您需要产出哪种类型的方案？可选择：规划类、申报类、可研类、投标类、工作汇报类\"\n3. **第二步：等待用户确认**：待用户明确反馈方案类型后，再根据用户选择的方案类型进行解决方案内容的编写\n4. **补充说明**：如果用户不清楚各类型方案的区别，参考 `references/solution-type-frames.md` 进行说明\n\n### 方案类型演进关系\n\n五种方案类型存在递进关系，前一类型的产出可复用为后一类型的基础输入：\n\n- **规划类 → 申报类**：规划类的建设目标和思路可复用为申报类的建设背景和目标章节\n- **申报类 → 可研类**：申报类的架构设计和建设内容可深化为可研类的详细技术方案\n- **可研类 → 投标类**：可研类的技术方案可复用为投标类的总体建设方案，需增加实施管理、运维、培训等响应性内容\n\n---\n\n## 各阶段详细说明\n\n### 第零阶段：方案类型识别与关键信息收集（必执行）\n\n1. **强制询问用户方案类型**：询问语\"请问您需要产出哪种类型的方案？可选择：规划类、申报类、可研类、投标类、工作汇报类\"，若用户不清楚，参考 `references/solution-type-frames.md` 进行说明\n2. **等待用户明确反馈方案类型**\n3. **收集关键约束信息**：方案类型确认后，主动收集所属领域（政府/企业及细分行业）、建设规模（预算/周期/覆盖范围）、现有基础（系统/信息化程度/团队能力）、核心诉求（1-3个核心问题）\n4. **生成方案大纲**：参考 `references/solution-type-frames.md` 生成目录结构，向用户展示并确认\n5. **根据方案类型和关键信息调整后续流程**\n\n检查点：✅ 方案类型已通过询问明确、✅ 关键约束信息已收集、✅ 方案大纲已确认\n\n### 方案类型与流程映射\n\n| 方案类型 | 执行阶段 | 跳过阶段 |\n|----------|----------|----------|\n| **规划类** | 第零阶段 → 第一阶段 → 第二阶段（简化）→ 第三阶段 → 4.1（业务架构简化）→ 第六阶段（简化）→ 效益分析 | 4.2-4.4、第五阶段、第七阶段（详细）、第八阶段 |\n| **申报类** | 第零阶段 → 第一阶段 → 第二阶段 → 第三阶段 → 第四阶段 → 第六阶段 → 第七阶段（简化）→ 效益分析 → 费用估算 | 第五阶段（详细）、第八阶段（详细） |\n| **可研类** | 全部阶段 + 投资估算（替代费用估算） | — |\n| **投标类** | 第零阶段 → 第二阶段（需求理解）→ 第三阶段（建设方案）→ 第四阶段 → 10.1-10.5 → 报价文件 | 第一阶段、第五阶段（独立）、第八阶段（合并） |\n| **工作汇报类** | 特殊流程：背景 → 问题 → 当前工作 → 成果 → 问题 → 下一步 → 需支持 | 不使用标准流程 |\n\n### 方案质量评审（完成后必执行）\n\n方案编写完成后，必须参照 `references/solution-quality-checklist.md` 进行质量自审：\n\n1. 通用质量标准检查：完整性、一致性、逻辑性、可读性、规范性\n2. 按方案类型执行对应检查清单（规划类8项/申报类9项/可研类11项/投标类10项/工作汇报类8项）\n3. 四维度架构一致性校验（业务↔功能↔数据↔技术映射关系检查）\n4. 未通过项必须补充修改，全部通过后方可交付\n\n---\n\n### 第一阶段：政策背景分析\n\n1. 梳理政策环境（国家/行业/地方/国际政策）\n2. 分析政策影响（指导意义、机遇、约束、趋势）\n3. 识别合规要求（法律法规、行业标准、数据安全、技术标准）\n4. 输出政策分析报告（政策环境、关键解读、合规清单、机遇挑战）\n\n检查点：✅ 政策环境梳理全面、✅ 合规要求识别清晰、✅ 政策影响分析到位\n\n### 第二阶段：需求分析\n\n1. **现状评估**：参考 `references/current-state-assessment.md`，按信息化现状评估框架进行系统盘点\n   - 政府场景：政务系统盘点、一网通办/数据共享/信创/等保/跨部门协同五维评估\n   - 企业场景：数字化成熟度评估（L1-L5五级模型），业务数字化/数据资产化/运营智能化/生态协同化/组织敏捷化五维评估\n2. 行业现状分析（趋势、技术、竞争、痛点）\n3. 客户现状问题分析：基于评估结果识别差距和痛点，按影响范围×紧迫程度排序\n4. 收集核心需求（业务目标、用户场景、功能范围、非功能需求、约束条件）\n5. 需求优先级排序（MoSCoW 方法、MVP 范围、基础/增强/创新需求）\n6. 输出需求文档（现状评估报告、行业/客户现状分析、需求概述、功能清单、非功能需求、MVP 定义）\n\n检查点：✅ 现状评估系统完整、✅ 行业现状分析深入、✅ 客户问题诊断准确、✅ 业务价值明确、✅ 功能边界清晰、✅ MVP 范围可界定\n\n### 第三阶段：建设思路设计\n\n1. 确定总体建设目标（战略愿景、量化目标、价值主张、成功标准）\n2. 制定建设原则（业务价值导向、用户体验中心、技术业务融合、渐进演进）\n3. 设计建设路径（自建/采购/合作、传统/云原生/信创、实施模式、转型策略）\n4. 规划分期建设（分期原则、各期目标范围、交付物、依赖关系）\n5. 输出建设思路文档（目标愿景、建设原则、路径策略、分期规划、价值主张）\n\n检查点：✅ 建设目标清晰可量化、✅ 建设原则指导性强、✅ 建设路径合理可行、✅ 分期规划逻辑清晰\n\n### 第四阶段：架构设计（四维度）\n\n架构图生成方式：推荐使用预设模板（`--template`），也可自定义 DOT 文件（`--input`），参考 `references/architecture-dimensions.md`\n\n#### 4.1 业务架构\n- 梳理业务流程（核心/支撑/管理/跨部门协同）\n- 识别业务能力（核心/支撑/管理/集成能力）\n- 设计业务关系（实体/协作/流转/服务关系）\n- 生成业务架构图：`python scripts/generate-architecture-diagram.py --template business-4layer --output business.png` 或自定义 DOT\n- 输出业务架构文档（架构图、流程清单、能力清单、协作模式）\n\n#### 4.2 功能架构\n- 划分功能模块（按业务领域/用户角色/系统层次/业务能力）\n- 设计功能层次（核心/支撑/增强/集成功能层）\n- 设计功能关系（依赖/调用/协作/复用关系）\n- 生成功能架构图：`python scripts/generate-architecture-diagram.py --template functional-3layer --output functional.png` 或自定义 DOT\n- 输出功能架构文档（架构图、模块清单、层次划分、关系矩阵）\n\n#### 4.3 数据架构\n- 设计数据模型（实体/属性/关系/类型约束）\n- 设计数据流（业务/系统/跨系统数据流，采集/存储/处理/应用）\n- 设计数据标准（字典/编码/质量管理标准）\n- 设计数据治理（分类分级/安全隐私/生命周期/共享开放）\n- 生成数据架构图：`python scripts/generate-architecture-diagram.py --template data-flow --output data.png` 或自定义 DOT\n- 输出数据架构文档（模型图、数据流图、标准规范、治理方案）\n\n#### 4.4 技术架构\n- 确定技术架构模式（参考 `references/architecture-patterns.md`）\n- 设计部署架构（拓扑/分层/容器化/高可用容灾）\n- 设计安全架构（网络/应用/数据/运维安全）\n- 设计集成架构（API网关/服务注册/消息队列/数据交换）\n- 生成技术架构图：`python scripts/generate-architecture-diagram.py --template technical-microservice --output technical.png` 或 `--template gov-cloud --output gov.png`，也可自定义 DOT\n- 输出技术架构文档（架构图、部署/安全/集成架构设计）\n\n检查点：✅ 四维度协同一致 ✅ 满足需求 ✅ 符合建设思路 ✅ 可落地实施\n\n### 第五阶段：技术选型\n\n1. 确定技术选型维度（前端、后端、数据存储、中间件、基础设施）\n2. 技术栈评估：参考 `references/technology-stack-guide.md`，评估成熟度、社区生态、团队能力、成本，进行关键技术权衡；政府场景需评估信创适配方案（国产OS/DB/中间件/芯片）\n3. 输出技术选型文档（技术栈清单、选型依据与权衡、潜在风险与备选方案）\n\n检查点：✅ 技术选型有明确依据、✅ 考虑了团队能力匹配、✅ 关键技术有备选方案\n\n### 第六阶段：具体建设内容\n\n本阶段将四维度架构设计转化为具体建设任务和交付物。\n\n#### 6.1 业务架构展开\n- 业务流程实施设计（关键流程设计、流程优化、跨部门协同）\n- 业务能力建设计划（实施路径、时间表、资源需求）\n- 业务关系实现设计（协作机制、服务契约）\n\n#### 6.2 功能架构展开\n- 功能模块开发计划（功能点清单、开发计划、验收标准）\n- 功能层次实施策略（核心/支撑/增强/集成功能的实施顺序）\n- 功能关系实现设计（接口设计、数据流设计）\n\n#### 6.3 数据架构展开\n- 数据模型实现设计（表结构、数据字典、数据初始化）\n- 数据流实现设计（ETL 方案、同步策略、缓存策略）\n- 数据标准与治理实施（数据规范、质量管控、安全权限、生命周期）\n\n#### 6.4 技术架构展开\n- 部署架构实施设计（环境准备、部署方案、监控方案）\n- 安全架构实施设计（安全策略、安全配置、安全测试）\n- 集成架构实施设计（API 设计、中间件配置、系统集成）\n\n检查点：✅ 四维度建设内容覆盖完整 ✅ 建设任务可落地可跟踪 ✅ 与技术选型和实施规划对接\n\n### 第七阶段：实施规划\n\n1. 规划实施阶段：参考 `references/implementation-phases.md`，阶段划分 MVP → 功能扩展 → 优化完善；政府项目需遵循采购流程、审计要求、验收标准、资金管理和合规审查\n2. 任务分解与排期（WBS、任务依赖、资源需求）\n3. 关键里程碑定义（MVP 发布、功能完整版、生产就绪版）\n4. 输出实施计划（阶段规划、里程碑时间表、资源需求）\n\n检查点：✅ MVP 可快速交付、✅ 阶段划分合理、✅ 里程碑可度量\n\n### 第八阶段：风险评估\n\n1. 识别关键风险（技术、业务、项目、运维风险）\n2. 风险评估（发生概率、影响程度、风险等级）\n3. 制定缓解策略（预防措施、应急预案、责任人）\n4. 输出风险清单（风险分类与等级、缓解措施、监控指标）\n\n检查点：✅ 关键风险已识别、✅ 高风险有缓解措施、✅ 风险可跟踪\n\n### 第九阶段：效益分析与投资估算\n\n#### 9.1 效益分析\n- **经济效益**：成本节约（人力/运营成本）、收入增长（新业务/效率提升）、投资回报率（ROI）计算\n- **社会效益**（政府场景重点）：服务效率提升、群众满意度提升、政府治理能力提升\n- **管理效益**（企业场景重点）：管理效率提升、决策支持能力提升、业务协同能力提升\n\n检查点：✅ 经济效益可量化、✅ 社会/管理效益明确\n\n#### 9.2 投资估算（申报/可研/投标类必需）\n1. 确定投资估算依据（参考市场价格、行业标准、类似项目）\n2. 总投资估算（分项说明）：硬件设备费、软件购置/开发费、实施服务费、数据资源费、安全测评费、培训费、运维费\n3. 资金筹措方案：资金来源（财政拨款/自筹资金）、分期资金安排、资金使用计划\n\n检查点：✅ 投资估算依据充分、✅ 分项明细完整、✅ 资金筹措方案可行\n\n### 第十阶段：特殊章节（根据方案类型增加）\n\n#### 10.1 详细功能设计（投标类必需）\n- 管理后台功能设计（用户管理、角色权限、系统配置、业务功能模块详细设计）\n- 运维平台功能设计（系统监控、日志管理、告警管理、性能监控、故障诊断）\n- 数据服务与分析功能设计（数据查询、统计分析、报表展示、数据挖掘、智能分析）\n- 功能清单输出（按照招标需求逐项响应）\n\n#### 10.2 项目实施与管理（投标类必需）\n- 项目组织架构设计（项目经理、技术负责人、开发团队、测试团队）\n- 关键人员简历（资质、经验、项目案例）\n- 实施方法论（敏捷开发、瀑布模型、混合模式）\n- 项目进度计划（甘特图、关键路径）\n- 质量管理方案（质量标准、测试方案、质量评审）\n- 风险管控（风险识别、风险评估、应对措施）\n- 变更管理（变更流程、变更评审、变更记录）\n\n#### 10.3 信息安全与合规（投标/可研类必需）\n- 网络安全方案（防火墙、入侵检测、网络隔离）\n- 数据安全方案（数据加密、数据脱敏、数据备份）\n- 应用安全方案（身份认证、访问控制、安全审计）\n- 等保测评与合规（政府场景：等保三级测评、合规评估）\n- 安全管理制度与应急响应\n\n#### 10.4 运维服务与保障（投标类必需）\n- 运维服务模式（远程运维、驻场运维、混合模式）\n- 运维内容（系统巡检、故障处理、性能优化）\n- 服务级别协议（SLA）（响应时间、解决时间、可用性）\n- 运维团队与工具（运维人员、运维平台、监控系统）\n- 售后保障机制（服务热线、升级流程、投诉渠道）\n\n#### 10.5 培训方案（投标类必需）\n- 培训计划（培训对象、培训时间、培训周期）\n- 培训内容与教材（业务操作培训、技术培训、管理培训）\n- 培训方式（集中培训、在线培训、现场指导）\n- 培训考核与效果保障（考核方式、效果评估、持续支持）\n\n---\n\n## 可选分支详解\n\n- **快速原型场景**：政策背景分析 → 需求分析 → 快速架构（四维度简化）→ 技术选型 → 具体建设内容（简化）→ 原型实现\n- **企业级系统**：强调安全、合规、高可用性设计\n- **创新项目**：增加可行性验证阶段，采用实验性技术\n- **遗留系统迁移**：增加现状评估、迁移策略设计\n- **政府数字化转型场景**：参考 `references/government-digitalization.md`\n  - 扩展流程：政策合规分析（数据安全法/等保/信创）→ 跨部门协同需求 → 一网通办/数据共享建设思路 → 便民化架构设计\n  - 特殊输出：合规安全方案、信创适配说明、数据安全与隐私保护方案、跨部门协同机制设计、服务便民化设计方案\n- **企业数字化转型场景**：参考 `references/enterprise-digitalization.md`\n  - 扩展流程：数字化成熟度评估（L1-L5）→ ROI导向建设思路 → 中台/SaaS/混合云架构选型\n  - 特殊输出：数字化成熟度评估报告、ROI分析与投资回报预测、变革管理方案、组织能力提升方案\n\n## 资源索引\n\n- **必要脚本**：`scripts/generate-architecture-diagram.py`（用途：生成业务/功能/数据/技术架构图和流程图；参数：diagram-type, input, output, template, list-templates；模板：business-4layer, functional-3layer, data-flow, technical-microservice, gov-cloud）\n- **行业场景库**：`references/industry-scenarios.md`（第零阶段识别行业领域时读取，含智慧政务/城市/医疗/教育/交通/金融/制造7大行业场景）\n- **方案类型框架**：`references/solution-type-frames.md`（第零阶段方案类型识别时读取，用于生成方案大纲）\n- **架构模式参考**：`references/architecture-patterns.md`（第四阶段技术架构设计时读取）\n- **架构维度参考**：`references/architecture-dimensions.md`（第四阶段四维度架构设计时读取）\n- **技术选型指南**：`references/technology-stack-guide.md`（第五阶段技术选型时读取，含信创适配技术栈章节）\n- **实施阶段参考**：`references/implementation-phases.md`（第七阶段实施规划时读取，含政府项目特有实施流程章节）\n- **政府数字化转型参考**：`references/government-digitalization.md`（政府数字化转型场景读取）\n- **企业数字化转型参考**：`references/enterprise-digitalization.md`（企业数字化转型场景读取，含数字化成熟度评估模型）\n- **方案质量评审清单**：`references/solution-quality-checklist.md`（方案完成后质量自审，含各方案类型检查清单和四维度架构一致性校验）\n- **现状评估方法论**：`references/current-state-assessment.md`（第二阶段需求分析时读取，含信息化现状评估框架、政府/企业场景评估方法、数字化成熟度模型）\n\n## 注意事项\n\n- **方案类型识别强制要求**：用户输入需求后，**必须先询问**用户方案类型，不要通过关键词推导或猜测，等待用户明确反馈后再进行方案编写\n- **关键信息收集**：方案类型确认后，需主动收集所属领域、建设规模、现有基础、核心诉求等关键约束信息；若用户未提供，合理推断并标注假设\n- **方案大纲先行**：方案类型确认后，先生成方案大纲（目录结构）向用户展示并确认，再按大纲逐章节展开，避免方向偏差\n- **阶段迭代**：不需要线性完成所有阶段，根据方案类型选择需要的阶段执行\n- **产出导向**：每个阶段都应产出明确文档或决策，避免过度设计\n- **业务优先**：技术方案必须服务于业务目标，避免技术驱动\n- **平衡原则**：在理想方案与实际约束之间找到平衡点\n- **持续验证**：关键设计决策应通过原型、POC 或评审验证\n- **政策合规**：政府场景需严格遵守政策法规要求，确保合规安全\n- **四维度协同**：业务架构、功能架构、数据架构、技术架构需协同一致，相互支撑\n- **现状驱动**：需求分析需深入行业现状和客户现状，必要时主动向用户获取现状信息或从互联网搜索同类客户共性现状\n- **思路清晰**：建设思路设计需明确目标、原则、路径、分期，指导后续实施\n- **行业场景适配**：根据用户所属行业参考 `references/industry-scenarios.md`，使用行业术语和行业痛点，避免泛化描述\n- **方案演进复用**：规划类→申报类→可研类→投标类存在递进关系，高阶方案应复用低阶方案的核心结论，避免重复劳动\n- **方案质量评审**：方案完成后必须执行质量评审，参照 `references/solution-quality-checklist.md` 逐项检查，未通过项必须修改\n- **现状评估深度**：需求分析阶段必须进行系统化的现状评估，参考 `references/current-state-assessment.md`，政府场景重点盘点政务系统和政策合规，企业场景重点评估数字化成熟度\n- **信创适配**：政府场景技术选型必须考虑信创适配，参考 `references/technology-stack-guide.md` 中信创适配技术栈章节，包含国产OS/DB/中间件/芯片的全栈方案和渐进式迁移策略\n- **政府项目合规**：政府项目实施需遵循采购流程、审计要求、验收标准、资金管理和合规审查，参考 `references/implementation-phases.md` 中\"政府项目特有实施流程\"章节\n- **架构图生成**：架构设计阶段应使用 `scripts/generate-architecture-diagram.py` 生成可视化架构图\n  - 前置要求：`pip install graphviz`（Python依赖）\n  - **模板模式（推荐）**：`--template business-4layer/functional-3layer/data-flow/technical-microservice/gov-cloud`，`--list-templates` 列出全部模板\n  - 自定义 DOT：`--input` 传入，支持 subgraph/style/color/rank 完整语法，中文自动适配\n  - 输出格式：PNG、SVG、PDF\n\n## 使用示例\n\n### 示例 0：方案类型识别与关键信息收集（强制流程）\n- **功能**：用户输入需求后，强制询问方案类型，收集关键约束信息，待用户明确后再进行方案编写\n- **执行方式**：智能体主导，第零阶段必执行\n- **关键指导**：\n  - **强制要求**：用户输入需求后，**必须先询问**用户方案类型，不要通过关键词推导或猜测\n  - 询问语：\"请问您需要产出哪种类型的方案？可选择：规划类、申报类、可研类、投标类、工作汇报类\"\n  - 若用户不清楚，参考 `references/solution-type-frames.md` 为用户说明各类型方案的特点、适用场景和输出重点\n  - **等待用户明确反馈方案类型后**，收集关键约束信息：所属领域、建设规模、现有基础、核心诉求\n  - 根据确认的方案类型和关键信息选择对应的执行阶段和输出结构\n\n### 示例 1：规划类方案 - 政务服务平台规划\n- **功能**：为某政府部门设计粗颗粒度的政务服务平台规划方案\n- **执行方式**：智能体主导，执行规划类方案流程\n- **关键指导**：\n  - 方案类型：规划类方案\n  - 执行阶段：第零阶段 → 第一阶段（政策背景分析）→ 第二阶段（需求分析，简化）→ 第三阶段（建设思路设计）→ 4.1（业务架构，简化）→ 第六阶段（具体建设内容，简化）→ 效益分析\n  - 输出重点：政策背景分析、现状问题、建设目标及思路、业务架构（简化）、关键建设内容、预期效益\n  - 内容特点：粗颗粒度、强调愿景和方向，不涉及详细设计和费用\n\n### 示例 2：申报类方案 - 企业数字化管理系统申报\n- **功能**：为企业设计数字化管理系统申报方案，用于内部立项申请\n- **执行方式**：智能体主导，执行申报类方案流程\n- **关键指导**：\n  - 方案类型：申报类方案\n  - 执行阶段：第零阶段 → 第一阶段 → 第二阶段 → 第三阶段 → 第四阶段（四维度架构）→ 第六阶段（主要建设内容）→ 第七阶段（实施规划，简化）→ 效益分析 → 费用估算\n  - 输出重点：建设背景、需求分析、建设目标、四维度架构、主要建设内容、实施计划（简化）、效益分析、费用估算\n  - 内容特点：较规划类更细化，包含费用估算，架构设计涵盖四维度\n\n### 示例 3：可研类方案 - 政府数字政府建设可研\n- **功能**：为政府数字政府建设项目设计可行性研究报告\n- **执行方式**：智能体主导，执行可研类方案流程（全部阶段）\n- **关键指导**：\n  - 方案类型：可研类方案\n  - 执行阶段：全部阶段（第零阶段至第八阶段）+ 投资估算（第九阶段）\n  - 输出重点：总论、背景与必要性、需求分析（细化）、总体建设方案、建设内容、技术方案与选型（详细）、实施计划、投资估算、效益分析、风险分析\n  - 需求分析需细化：业务、用户、功能、数据、性能、安全、运维\n  - 技术选型需详细：技术路线、关键技术、软硬件选型、集成方案、信创适配（政府场景）\n  - 内容特点：内容最全面、最细化，包含详细的投资估算和风险分析\n\n### 示例 4：投标类方案 - 政务云平台投标\n- **功能**：为政务云平台招标项目设计投标方案\n- **执行方式**：智能体主导，执行投标类方案流程\n- **关键指导**：\n  - 方案类型：投标类方案\n  - 执行阶段：第零阶段 → 第二阶段（项目需求理解与分析）→ 第三阶段（总体建设方案）→ 第四阶段（四维度架构）→ 10.1（详细功能设计）→ 10.2（项目实施与管理方案）→ 10.3（信息安全与合规方案）→ 10.4（运维服务与保障方案）→ 10.5（培训方案）→ 报价文件\n  - 输出重点：需求理解、总体建设方案、详细功能设计、实施与管理、安全与合规、运维服务、培训方案、报价文件\n  - 详细功能设计需按照招标需求逐项响应，并附上功能清单\n  - 内容特点：围绕招标需求响应，强调技术实力、实施能力、管理能力和价格竞争力\n\n### 示例 5：工作汇报类方案 - 项目阶段性汇报\n- **功能**：为项目执行过程设计阶段性工作汇报方案\n- **执行方式**：智能体主导，执行工作汇报类方案特殊流程\n- **关键指导**：\n  - 方案类型：工作汇报类方案\n  - 执行流程：特殊流程，不使用标准八阶段流程\n  - 输出结构：工作背景 → 需要解决的问题 → 当前正在开展的工作内容及完成情况 → 已经产生的工作成果及成效 → 当前工作开展中存在的问题 → 下一步工作计划 → 需要领导给予的支持\n  - 内容特点：简洁实用，重点突出工作进展、成果和需要支持的事项\n\n### 示例 6：生成架构图\n- **功能**：使用脚本生成各类架构图\n- **执行方式**：调用 `scripts/generate-architecture-diagram.py` 脚本\n- **关键指导**：\n  - 前置安装：`pip install graphviz`\n  - **模板模式（推荐）**：\n    - 生成业务架构图：`python scripts/generate-architecture-diagram.py --template business-4layer --output business.png`\n    - 生成功能架构图：`python scripts/generate-architecture-diagram.py --template functional-3layer --output functional.png`\n    - 生成数据架构图：`python scripts/generate-architecture-diagram.py --template data-flow --output data.png`\n    - 生成技术架构图：`python scripts/generate-architecture-diagram.py --template technical-microservice --output technical.png`\n    - 生成政务云架构图：`python scripts/generate-architecture-diagram.py --template gov-cloud --output gov.png`\n  - 自定义 DOT 模式：编写 DOT 格式文件，支持 subgraph、style、color 等完整语法\n    - `python scripts/generate-architecture-diagram.py --diagram-type business --input business.dot --output business.png`\n  - 前置条件：创建 DOT 格式文件（参考 `references/architecture-dimensions.md` 中的模板）\n\nFile v1.2.0:_meta.json\n\n{\n  \"ownerId\": \"kn7ae6m5fzwqs7fmdmh97gr1yh82m2py\",\n  \"slug\": \"digital-solution-designer\",\n  \"version\": \"1.2.0\",\n  \"publishedAt\": 1779954539336\n}\n\nFile v1.2.0:references/architecture-dimensions.md\n\n# 架构设计维度参考\n\n## 目录\n1. 业务架构设计\n2. 功能架构设计\n3. 数据架构设计\n4. 技术架构设计\n5. 四维度协同关系\n\n## 概览\n本文档提供业务架构、功能架构、数据架构、技术架构四个维度的设计指导，帮助系统化地进行多维度架构设计，确保各维度协同一致、相互支撑。\n\n## 核心内容\n\n### 1. 业务架构设计\n\n业务架构是系统的战略层面设计，描述业务目标、业务流程、业务能力和业务关系，是功能和数据架构设计的基础。\n\n#### 1.1 业务流程梳理\n\n**核心业务流程**：\n- 识别端到端的业务流程（从业务开始到结束）\n- 每个流程包括：触发条件、参与角色、执行步骤、输出结果\n- 示例：电商平台 - 订单流程（浏览 → 下单 → 支付 → 发货 → 确认收货）\n\n**支撑业务流程**：\n- 支撑核心流程的辅助流程\n- 示例：用户管理、商品管理、库存管理\n\n**管理业务流程**：\n- 运营管理流程\n- 示例：运营分析、数据统计、异常处理\n\n**跨部门协同流程**：\n- 涉及多个部门/系统的流程\n- 示例：政务审批、供应链协同\n\n#### 1.2 业务能力识别\n\n**业务能力分类**：\n- **核心能力**：直接支撑业务目标，创造价值\n- **支撑能力**：为核心能力提供支持\n- **管理能力**：管理和监控业务运行\n- **集成能力**：与外部系统交互\n\n**能力识别方法**：\n- 按业务领域划分（电商：商品、订单、支付、物流）\n- 按价值链划分（研发 → 生产 → 销售 → 服务）\n- 按用户角色划分（C端用户、B端用户、运营人员、管理员）\n\n**能力成熟度评估**：\n- 成熟度等级：初始级 → 已定义级 → 已管理级 → 优化级\n- 评估维度：流程标准化、数字化程度、自动化程度\n\n#### 1.3 业务关系设计\n\n**业务实体关系**：\n- 业务对象之间的关系（用户、订单、商品、支付）\n- 关系类型：一对一、一对多、多对多\n\n**业务协作关系**：\n- 业务部门之间的协作\n- 系统之间的协作\n- 角色之间的协作\n\n**数据流转关系**：\n- 数据在业务流程中的流转\n- 数据的采集、存储、处理、应用\n\n**服务提供与消费关系**：\n- 业务能力的提供方和消费方\n- 服务契约和接口\n\n#### 1.4 业务架构输出\n\n**输出文档内容**：\n- 业务架构图（文字描述）\n- 核心业务流程清单\n- 业务能力清单\n- 业务协作模式\n- 业务关系矩阵\n\n**质量检查**：\n- ✅ 业务流程覆盖全面\n- ✅ 业务能力边界清晰\n- ✅ 业务关系逻辑合理\n- ✅ 业务架构支撑业务目标\n\n#### 1.5 业务架构图模板\n\n**Graphviz DOT 格式示例**：\n\n```dot\ndigraph BusinessArchitecture {\n    rankdir=TB;\n    node [shape=box, style=filled, fillcolor=lightblue];\n    edge [fontsize=10];\n\n    // 核心业务领域\n    subgraph cluster_core {\n        label=\"核心业务\";\n        style=dashed;\n        商品管理 [label=\"商品管理\\n- 商品发布\\n- 库存管理\"];\n        订单管理 [label=\"订单管理\\n- 订单创建\\n- 订单处理\"];\n        支付管理 [label=\"支付管理\\n- 在线支付\\n- 退款处理\"];\n        物流管理 [label=\"物流管理\\n- 发货管理\\n- 物流跟踪\"];\n    }\n\n    // 支撑业务领域\n    subgraph cluster_support {\n        label=\"支撑业务\";\n        style=dashed;\n        用户管理 [label=\"用户管理\\n- 用户注册\\n- 权限管理\"];\n        会员管理 [label=\"会员管理\\n- 会员等级\\n- 积分管理\"];\n        营销管理 [label=\"营销管理\\n- 优惠券\\n- 促销活动\"];\n    }\n\n    // 业务流程\n    商品管理 -> 订单管理 [label=\"下单\"];\n    订单管理 -> 支付管理 [label=\"支付\"];\n    支付管理 -> 物流管理 [label=\"发货\"];\n    用户管理 -> 订单管理 [label=\"创建订单\"];\n    用户管理 -> 会员管理 [label=\"会员服务\"];\n    会员管理 -> 营销管理 [label=\"营销活动\"];\n    营销管理 -> 订单管理 [label=\"促销下单\"];\n}\n```\n\n**使用说明**：\n1. 将上述 DOT 格式保存为 `business.dot` 文件\n2. 调用脚本生成架构图：`python scripts/generate-architecture-diagram.py --diagram-type business --input business.dot --output business.png`\n3. 根据实际业务场景调整节点和边的定义\n\n---\n\n### 2. 功能架构设计\n\n功能架构是系统的功能层面设计，描述功能模块、功能层次和功能关系，将业务能力转化为可实现的功能。\n\n#### 2.1 功能模块划分\n\n**按业务领域划分**：\n- 核心业务功能（订单管理、支付管理）\n- 支撑业务功能（用户管理、权限管理）\n- 管理功能（系统管理、数据管理）\n\n**按用户角色划分**：\n- C 端用户功能（注册登录、浏览下单）\n- B 端用户功能（商品管理、订单处理）\n- 运营人员功能（数据分析、营销活动）\n- 管理员功能（系统配置、用户管理）\n\n**按系统层次划分**：\n- 接入层（Web、移动端、API）\n- 业务层（核心业务逻辑）\n- 数据层（数据访问、存储）\n- 基础设施层（监控、日志、配置）\n\n**按业务能力划分**：\n- 每个业务能力对应一组功能模块\n- 示例：订单能力 → 订单创建、订单查询、订单取消、订单统计\n\n#### 2.2 功能层次设计\n\n**核心功能层**：\n- 支撑业务关键流程的功能\n- 示例：商品浏览、下单支付、订单查询\n\n**支撑功能层**：\n- 数据管理（用户管理、商品管理、订单管理）\n- 用户管理（注册登录、身份认证、权限管理）\n- 通知服务（短信、邮件、推送）\n\n**增强功能层**：\n- 数据分析（报表、统计、可视化）\n- 智能推荐（个性化推荐、搜索优化）\n- 营销活动（优惠券、促销、积分）\n\n**集成功能层**：\n- 第三方集成（支付、物流、地图）\n- 系统集成（与现有系统对接）\n- 数据集成（数据导入导出）\n\n#### 2.3 功能关系设计\n\n**功能依赖关系**：\n- 功能之间的依赖（订单依赖用户和商品）\n- 先决条件（下单前需登录、购物车需先加商品）\n\n**功能调用关系**：\n- 模块间的调用关系\n- 同步调用 vs 异步调用\n\n**功能协作关系**：\n- 多个功能协作完成业务流程\n- 示例：下单 → 库存扣减 → 支付 → 发货 → 通知\n\n**功能复用关系**：\n- 公共功能模块（用户认证、权限控制）\n- 基础服务（文件上传、缓存服务）\n\n#### 2.4 功能架构输出\n\n**输出文档内容**：\n- 功能架构图（文字描述）\n- 功能模块清单\n- 功能层次划分\n- 功能关系矩阵\n\n**质量检查**：\n- ✅ 功能模块划分合理\n- ✅ 功能层次清晰\n- ✅ 功能关系明确\n- ✅ 功能架构支撑业务架构\n\n#### 2.5 功能架构图模板\n\n**Graphviz DOT 格式示例**：\n\n```dot\ndigraph FunctionalArchitecture {\n    rankdir=TB;\n    node [shape=box, style=filled];\n    edge [fontsize=10];\n\n    // 核心功能层\n    subgraph cluster_core {\n        label=\"核心功能层\";\n        style=dashed;\n        node [fillcolor=lightgreen];\n        商品浏览 [label=\"商品浏览\\n- 商品列表\\n- 商品详情\\n- 商品搜索\"];\n        下单支付 [label=\"下单支付\\n- 购物车\\n- 下单\\n- 支付\"];\n        订单查询 [label=\"订单查询\\n- 订单列表\\n- 订单详情\\n- 物流跟踪\"];\n    }\n\n    // 支撑功能层\n    subgraph cluster_support {\n        label=\"支撑功能层\";\n        style=dashed;\n        node [fillcolor=lightblue];\n        用户管理 [label=\"用户管理\\n- 注册登录\\n- 个人信息\\n- 地址管理\"];\n        权限管理 [label=\"权限管理\\n- 角色管理\\n- 权限控制\"];\n        通知服务 [label=\"通知服务\\n- 短信通知\\n- 邮件通知\\n- 消息推送\"];\n    }\n\n    // 增强功能层\n    subgraph cluster_enhance {\n        label=\"增强功能层\";\n        style=dashed;\n        node [fillcolor=lightyellow];\n        数据分析 [label=\"数据分析\\n- 报表统计\\n- 数据可视化\"];\n        智能推荐 [label=\"智能推荐\\n- 个性化推荐\\n- 商品推荐\"];\n        营销活动 [label=\"营销活动\\n- 优惠券\\n- 促销活动\"];\n    }\n\n    // 集成功能层\n    subgraph cluster_integration {\n        label=\"集成功能层\";\n        style=dashed;\n        node [fillcolor=lightgray];\n        第三方支付 [label=\"第三方支付\\n- 支付宝\\n- 微信支付\"];\n        物流集成 [label=\"物流集成\\n- 快递公司\\n- 物流查询\"];\n    }\n\n    // 功能层次关系\n    下单支付 -> 第三方支付 [label=\"调用\"];\n    下单支付 -> 物流集成 [label=\"调用\"];\n    用户管理 -> 下单支付 [label=\"支撑\"];\n    权限管理 -> 用户管理 [label=\"控制\"];\n    通知服务 -> 下单支付 [label=\"通知\"];\n    数据分析 -> 订单查询 [label=\"分析\"];\n    智能推荐 -> 商品浏览 [label=\"推荐\"];\n    营销活动 -> 商品浏览 [label=\"展示\"];\n}\n```\n\n---\n\n### 3. 数据架构设计\n\n数据架构是系统的数据层面设计，描述数据模型、数据流、数据标准和数据治理，确保数据的正确性、一致性、安全性和可用性。\n\n#### 3.1 数据模型设计\n\n**核心实体识别**：\n- 业务对象抽象（用户、商品、订单、支付）\n- 实体属性定义\n- 实体关系设计（一对一、一对多、多对多）\n\n**数据类型与约束**：\n- 数据类型选择（字符串、数字、日期、JSON）\n- 数据约束（非空、唯一、范围、格式）\n- 默认值设计\n\n**数据标准化**：\n- 命名规范（表名、字段名、索引名）\n- 编码规范（字典编码、状态码）\n- 格式规范（日期格式、金额格式、坐标格式）\n\n**数据模型层次**：\n- **概念模型**：业务层面的数据抽象\n- **逻辑模型**：系统层面的数据结构\n- **物理模型**：数据库层面的具体实现\n\n#### 3.2 数据流设计\n\n**业务数据流**：\n- 数据在业务流程中的流转\n- 示例：下单 → 订单数据 → 支付数据 → 物流数据 → 完成数据\n\n**系统数据流**：\n- 系统内部的数据流转\n- 示例：Web 层 → 业务层 → 数据层\n\n**跨系统数据流**：\n- 系统间的数据交换\n- 示例：电商平台 → 物流公司 → 用户\n\n**数据采集、存储、处理、应用**：\n- **数据采集**：用户输入、传感器、第三方数据\n- **数据存储**：关系型数据库、NoSQL、数据仓库\n- **数据处理**：ETL、清洗、计算、分析\n- **数据应用**：查询、报表、推荐、预测\n\n#### 3.3 数据标准设计\n\n**数据字典**：\n- 统一的数据术语定义\n- 数据元定义（名称、类型、长度、含义）\n- 数据域定义（数据值域、枚举值）\n\n**数据编码规则**：\n- 主键生成策略（UUID、雪花算法）\n- 业务编码规则（订单号、流水号）\n- 状态码设计（状态机、状态转换）\n\n**数据质量管理标准**：\n- 数据完整性（必填项、唯一性）\n- 数据准确性（数据校验、格式验证）\n- 数据一致性（数据同步、事务管理）\n- 数据及时性（实时、准实时、批处理）\n\n#### 3.4 数据治理设计\n\n**数据分类分级**：\n- **按敏感程度**：公开、受限、敏感、机密\n- **按重要程度**：核心数据、重要数据、一般数据\n- 分类分级标准与策略\n\n**数据安全与隐私保护**：\n- 数据脱敏（手机号、身份证、银行卡号）\n- 数据加密（传输加密、存储加密）\n- 访问控制（权限管理、角色控制）\n- 审计日志（数据访问、数据修改）\n\n**数据生命周期管理**：\n- 数据创建、使用、归档、销毁\n- 保留策略（热数据、温数据、冷数据）\n- 备份与恢复策略\n\n**数据共享与开放**：\n- 数据共享机制（API、ETL、数据交换）\n- 数据开放策略（公开数据、受限数据）\n- 数据使用授权（申请、审批、使用、审计）\n\n#### 3.5 数据架构输出\n\n**输出文档内容**：\n- 数据模型图（文字描述）\n- 数据流图（文字描述）\n- 数据标准规范\n- 数据治理方案\n\n**质量检查**：\n- ✅ 数据模型完整\n- ✅ 数据流清晰\n- ✅ 数据标准统一\n- ✅ 数据治理方案可行\n- ✅ 数据架构支撑功能架构\n\n#### 3.6 数据架构图模板\n\n**Graphviz DOT 格式示例（ER图）**：\n\n```dot\ndigraph DataArchitecture {\n    rankdir=LR;\n    node [shape=ellipse, style=filled, fillcolor=lightyellow];\n    edge [fontsize=10];\n\n    // 实体定义\n    用户 [label=\"用户\\n用户ID\\n用户名\\n密码\\n邮箱\\n手机号\"];\n    商品 [label=\"商品\\n商品ID\\n商品名称\\n价格\\n库存\"];\n    订单 [label=\"订单\\n订单ID\\n用户ID\\n商品ID\\n数量\\n金额\\n状态\"];\n    订单项 [label=\"订单项\\n订单项ID\\n订单ID\\n商品ID\\n数量\\n价格\"];\n    支付 [label=\"支付\\n支付ID\\n订单ID\\n金额\\n支付方式\\n支付状态\"];\n    物流 [label=\"物流\\n物流ID\\n订单ID\\n快递公司\\n运单号\\n物流状态\"];\n\n    // 实体关系\n    用户 -> 订单 [label=\"1:N\\n创建\"];\n    订单 -> 订单项 [label=\"1:N\\n包含\"];\n    商品 -> 订单项 [label=\"1:N\\n关联\"];\n    订单 -> 支付 [label=\"1:1\\n支付\"];\n    订单 -> 物流 [label=\"1:N\\n发货\"];\n\n    // 数据流\n    订单 [shape=box, fillcolor=lightblue, label=\"订单数据\\n- 订单创建\\n- 订单更新\\n- 订单完成\"];\n    支付 [shape=box, fillcolor=lightblue, label=\"支付数据\\n- 支付请求\\n- 支付回调\\n- 退款处理\"];\n    物流 [shape=box, fillcolor=lightblue, label=\"物流数据\\n- 发货通知\\n- 物流跟踪\\n- 签收确认\"];\n}\n```\n\n---\n\n### 4. 技术架构设计\n\n技术架构是系统的技术层面设计，描述部署架构、技术选型、安全架构和集成架构，确保系统的性能、可用性、安全性和可扩展性。\n\n#### 4.1 部署架构\n\n**部署拓扑**：\n- **单机部署**：简单场景、小型系统\n- **集群部署**：高可用、负载均衡\n- **分布式部署**：大规模、高并发\n- **云原生部署**：容器化、微服务、Serverless\n\n**分层架构**：\n- **接入层**：负载均衡、API 网关、CDN\n- **业务层**：应用服务、微服务\n- **数据层**：数据库、缓存、消息队列\n- **基础设施层**：服务器、存储、网络\n\n**容器化与编排**：\n- **容器化**：Docker 容器化应用\n- **编排**：Kubernetes 容器编排\n- **服务网格**：Istio 服务治理\n\n**高可用与容灾设计**：\n- **高可用**：多实例部署、故障自动转移\n- **负载均衡**：Nginx、HAProxy、云负载均衡\n- **容灾备份**：异地多活、灾备切换\n\n#### 4.2 安全架构\n\n**网络安全**：\n- **防火墙**：网络访问控制\n- **WAF**：Web 应用防火墙\n- **DDoS 防护**：分布式拒绝服务攻击防护\n- **VPN**：虚拟专用网络\n\n**应用安全**：\n- **认证授权**：身份认证、权限控制\n- **输入验证**：防止 SQL 注入、XSS 攻击\n- **加密**：传输加密（HTTPS）、数据加密\n- **会话管理**：会话安全、Token 管理\n\n**数据安全**：\n- **传输加密**：SSL/TLS 加密\n- **存储加密**：数据库加密、文件加密\n- **数据脱敏**：敏感数据脱敏\n- **备份加密**：备份数据加密\n\n**运维安全**：\n- **日志审计**：操作日志、访问日志\n- **入侵检测**：异常行为检测、入侵告警\n- **漏洞扫描**：安全漏洞扫描、修复\n- **应急响应**：安全事件应急响应\n\n#### 4.3 集成架构\n\n**API 网关设计**：\n- **统一入口**：API 统一入口\n- **认证授权**：统一认证、权限控制\n- **流量控制**：限流、熔断、降级\n- **协议转换**：HTTP、REST、gRPC\n\n**服务注册与发现**：\n- **注册中心**：服务注册、服务发现\n- **健康检查**：服务健康状态检查\n- **负载均衡**：服务实例负载均衡\n\n**消息队列与事件总线**：\n- **消息队列**：RabbitMQ、Kafka、RocketMQ\n- **事件总线**：事件发布订阅、事件溯源\n- **异步处理**：异步任务、异步通知\n\n**数据交换与同步**：\n- **ETL**：数据抽取、转换、加载\n- **CDC**：变更数据捕获\n- **数据同步**：主从复制、双向同步\n\n#### 4.4 技术架构输出\n\n**输出文档内容**：\n- 技术架构图（文字描述）\n- 部署架构设计\n- 安全架构设计\n- 集成架构设计\n\n**质量检查**：\n- ✅ 架构模式选择合理\n- ✅ 部署架构可行\n- ✅ 安全架构完善\n- ✅ 集成架构灵活\n- ✅ 技术架构支撑数据架构和功能架构\n\n#### 4.5 技术架构图模板\n\n**Graphviz DOT 格式示例（部署架构）**：\n\n```dot\ndigraph TechnicalArchitecture {\n    rankdir=TB;\n    node [shape=box, style=filled];\n    edge [fontsize=10];\n\n    // 接入层\n    subgraph cluster_access {\n        label=\"接入层\";\n        style=dashed;\n        node [fillcolor=lightgreen];\n        CDN [label=\"CDN\\n- 静态资源\\n- 边缘加速\"];\n        负载均衡 [label=\"负载均衡\\n- Nginx\\n- LVS\"];\n        API网关 [label=\"API网关\\n- 认证授权\\n- 流量控制\\n- 协议转换\"];\n    }\n\n    // 业务层\n    subgraph cluster_business {\n        label=\"业务层\";\n        style=dashed;\n        node [fillcolor=lightblue];\n        用户服务 [label=\"用户服务\\n- 用户注册\\n- 登录认证\"];\n        商品服务 [label=\"商品服务\\n- 商品管理\\n- 库存管理\"];\n        订单服务 [label=\"订单服务\\n- 订单创建\\n- 订单处理\"];\n        支付服务 [label=\"支付服务\\n- 支付处理\\n- 退款管理\"];\n    }\n\n    // 数据层\n    subgraph cluster_data {\n        label=\"数据层\";\n        style=dashed;\n        node [fillcolor=lightyellow];\n        MySQL [label=\"MySQL\\n- 关系型数据库\"];\n        Redis [label=\"Redis\\n- 缓存\\n- 会话\"];\n        MongoDB [label=\"MongoDB\\n- 文档数据库\"];\n    }\n\n    // 消息队列\n    subgraph cluster_mq {\n        label=\"消息队列\";\n        style=dashed;\n        node [fillcolor=lightgray];\n        Kafka [label=\"Kafka\\n- 异步消息\\n- 事件驱动\"];\n        RabbitMQ [label=\"RabbitMQ\\n- 消息队列\\n- 延迟队列\"];\n    }\n\n    // 接入层到业务层\n    负载均衡 -> API网关 [label=\"转发\"];\n    API网关 -> 用户服务 [label=\"路由\"];\n    API网关 -> 商品服务 [label=\"路由\"];\n    API网关 -> 订单服务 [label=\"路由\"];\n    API网关 -> 支付服务 [label=\"路由\"];\n\n    // 业务层到数据层\n    用户服务 -> MySQL [label=\"读写\"];\n    商品服务 -> MySQL [label=\"读写\"];\n    商品服务 -> Redis [label=\"缓存\"];\n    订单服务 -> MySQL [label=\"读写\"];\n    订单服务 -> Redis [label=\"缓存\"];\n    支付服务 -> MySQL [label=\"读写\"];\n\n    // 业务层到消息队列\n    订单服务 -> Kafka [label=\"异步\"];\n    支付服务 -> RabbitMQ [label=\"延迟\"];\n    商品服务 -> Kafka [label=\"事件\"];\n\n    // 消息队列到业务层\n    Kafka -> 物流服务 [label=\"消费\"];\n    RabbitMQ -> 订单服务 [label=\"消费\"];\n}\n```\n\n---\n\n### 5. 四维度协同关系\n\n#### 5.1 协同原则\n\n**业务架构是源头**：\n- 业务架构决定功能和数据架构\n- 业务目标和业务流程是设计的起点\n\n**功能架构是桥梁**：\n- 功能架构将业务能力转化为可执行的功能\n- 功能架构连接业务架构和技术架构\n\n**数据架构是基础**：\n- 数据架构支撑功能架构的实现\n- 数据架构是业务价值的载体\n\n**技术架构是支撑**：\n- 技术架构提供功能实现的技术基础\n- 技术架构确保系统的性能、安全、可用性\n\n#### 5.2 协同一致性检查\n\n**业务架构 ↔ 功能架构**：\n- ✅ 每个业务能力都有对应的功能模块\n- ✅ 业务流程都有对应的功能流程\n- ✅ 业务关系都有对应的功能关系\n\n**业务架构 ↔ 数据架构**：\n- ✅ 每个业务实体都有对应的数据实体\n- ✅ 业务流程都有对应的数据流\n- ✅ 业务关系都有对应的数据关系\n\n**功能架构 ↔ 数据架构**：\n- ✅ 每个功能都有对应的数据访问\n- ✅ 功能流程都有对应的数据操作\n- ✅ 功能关系都有对应的数据依赖\n\n**功能架构 ↔ 技术架构**：\n- ✅ 每个功能都有技术实现方案\n- ✅ 功能性能要求都有技术保障\n- ✅ 功能安全要求都有技术措施\n\n**数据架构 ↔ 技术架构**：\n- ✅ 数据模型有技术实现方案\n- ✅ 数据存储有技术选型\n- ✅ 数据安全有技术保障\n\n#### 5.3 协同设计流程\n\n1. **从业务架构开始**：\n   - 梳理业务目标、流程、能力、关系\n\n2. **功能架构承接**：\n   - 将业务能力转化为功能模块\n   - 设计功能层次和关系\n\n3. **数据架构支撑**：\n   - 设计数据模型支撑功能\n   - 设计数据流支撑业务流程\n\n4. **技术架构实现**：\n   - 选择技术栈实现功能\n   - 设计部署架构支撑数据\n\n5. **迭代优化**：\n   - 检查四维度协同一致性\n   - 优化架构设计\n\n#### 5.4 协同设计示例\n\n**示例：电商平台订单功能**\n\n- **业务架构**：订单能力 → 订单创建、订单查询、订单取消、订单支付\n- **功能架构**：订单管理模块 → 创建订单、查询订单、取消订单、支付订单\n- **数据架构**：订单实体（订单号、用户ID、商品ID、金额、状态）→ 订单数据流\n- **技术架构**：订单服务（微服务）→ MySQL（订单数据）→ Redis（订单缓存）→ 消息队列（订单通知）\n\n---\n\n## 架构设计质量检查清单\n\n### 业务架构\n- ✅ 业务流程覆盖全面\n- ✅ 业务能力边界清晰\n- ✅ 业务关系逻辑合理\n- ✅ 业务架构支撑业务目标\n\n### 功能架构\n- ✅ 功能模块划分合理\n- ✅ 功能层次清晰\n- ✅ 功能关系明确\n- ✅ 功能架构支撑业务架构\n\n### 数据架构\n- ✅ 数据模型完整\n- ✅ 数据流清晰\n- ✅ 数据标准统一\n- ✅ 数据治理方案可行\n- ✅ 数据架构支撑功能架构\n\n### 技术架构\n- ✅ 架构模式选择合理\n- ✅ 部署架构可行\n- ✅ 安全架构完善\n- ✅ 集成架构灵活\n- ✅ 技术架构支撑数据架构和功能架构\n\n### 四维度协同\n- ✅ 业务架构、功能架构、数据架构、技术架构协同一致\n- ✅ 架构设计满足需求\n- ✅ 架构设计符合建设思路\n- ✅ 架构设计可落地实施\n\nFile v1.2.0:references/architecture-patterns.md\n\n# 架构模式参考\n\n## 目录\n1. 单体架构\n2. 模块化单体\n3. 微服务架构\n4. 事件驱动架构\n5. 分层架构\n6. CQRS（命令查询职责分离）\n7. Serverless 架构\n8. 模式选择指南\n\n## 概览\n本文档提供常见的软件架构模式，包括其特点、适用场景和权衡考虑，用于指导架构设计决策。\n\n## 核心内容\n\n### 1. 单体架构（Monolithic）\n\n**特点**：\n- 整个应用作为单一部署单元\n- 共享数据库和代码库\n- 调用方式为内存函数调用\n\n**适用场景**：\n- 初创项目快速验证\n- 小型团队（< 10人）\n- 业务逻辑相对简单\n- 预期用户规模有限\n\n**优势**：\n- 开发简单，部署容易\n- 调试和测试方便\n- 无需复杂的服务间通信\n- 初期开发速度快\n\n**劣势**：\n- 扩展性受限（只能整体扩展）\n- 技术栈统一，灵活性低\n- 代码耦合度高，维护成本随规模增长\n- 故障影响范围大\n\n---\n\n### 2. 模块化单体（Modular Monolith）\n\n**特点**：\n- 仍是单一部署单元\n- 代码按模块组织，模块间通过明确接口交互\n- 强调内部边界和依赖管理\n\n**适用场景**：\n- 需要良好结构的中型项目\n- 团队规模 5-20人\n- 未来可能拆分为微服务的过渡阶段\n\n**优势**：\n- 保持单体部署的简单性\n- 代码组织清晰，降低耦合\n- 为未来微服务化做准备\n- 比传统单体更易维护\n\n**劣势**：\n- 仍受限于整体部署\n- 模块边界管理需要良好纪律\n- 跨模块变更仍需整体测试\n\n---\n\n### 3. 微服务架构（Microservices）\n\n**特点**：\n- 系统拆分为多个独立服务\n- 每个服务独立部署和扩展\n- 服务间通过 API（HTTP/RPC/gRPC）通信\n- 数据库通常独立（每个服务自己的数据库）\n\n**适用场景**：\n- 大型复杂系统\n- 多团队协作开发\n- 需要独立扩展不同模块\n- 业务领域边界清晰\n\n**优势**：\n- 独立部署和扩展\n- 技术栈灵活\n- 故障隔离\n- 团队自治\n\n**劣势**：\n- 分布式系统复杂度高\n- 服务间通信开销\n- 数据一致性挑战\n- 运维和监控复杂\n- 初期开发成本高\n\n**关键实践**：\n- 领域驱动设计（DDD）划分边界\n- API 网关统一入口\n- 服务注册与发现\n- 分布式追踪\n- 容错机制（熔断、降级）\n\n---\n\n### 4. 事件驱动架构（Event-Driven）\n\n**特点**：\n- 通过事件驱动业务流程\n- 松耦合的组件通过事件总线通信\n- 支持异步处理和实时响应\n\n**适用场景**：\n- 需要高实时性的系统\n- 多系统集成场景\n- 复杂业务流程编排\n- 需要高扩展性的异步任务\n\n**优势**：\n- 松耦合，易扩展\n- 异步处理提高吞吐量\n- 天然支持审计和溯源\n- 易于集成外部系统\n\n**劣势**：\n- 流程追踪困难\n- 事件Schema 管理复杂\n- 错误处理和重试机制复杂\n- 最终一致性的挑战\n\n**关键组件**：\n- 事件总线（消息队列：Kafka、RabbitMQ）\n- 事件存储\n- 事件溯源（Event Sourcing）\n- CQRS（命令查询分离）\n\n---\n\n### 5. 分层架构（Layered）\n\n**特点**：\n- 按职责分为不同层次\n- 常见分层：表现层 → 业务层 → 持久层 → 数据库\n- 严格依赖方向（上层依赖下层，下层不依赖上层）\n\n**适用场景**：\n- 几乎所有传统企业应用\n- 需要清晰职责分离的系统\n- 团队熟悉传统开发模式\n\n**优势**：\n- 结构清晰，易于理解\n- 职责分离，便于测试\n- 开发模式成熟\n- 易于维护\n\n**劣势**：\n- 可能过度设计\n- 层次间调用可能带来性能损耗\n- 不适合所有场景（如纯 API 服务）\n\n---\n\n### 6. CQRS（命令查询职责分离）\n\n**特点**：\n- 读写操作分离\n- 写操作（命令）使用领域模型\n- 读操作（查询）使用优化的数据模型\n- 可能使用不同的存储（写用关系数据库，读用 NoSQL）\n\n**适用场景**：\n- 读写差异大的系统（读多写少）\n- 复杂业务逻辑的写操作\n- 需要高性能的复杂查询\n- 事件驱动架构的读模型\n\n**优势**：\n- 读写性能独立优化\n- 复杂业务逻辑不影响查询性能\n- 易于扩展读端\n- 与事件溯源结合良好\n\n**劣势**：\n- 增加系统复杂度\n- 数据同步问题（最终一致性）\n- 不适合所有场景（读写简单的系统）\n\n---\n\n### 7. Serverless 架构\n\n**特点**：\n- 无需管理服务器\n- 函数即服务（FaaS）\n- 按执行时间和资源付费\n- 自动弹性伸缩\n\n**适用场景**：\n- 波动性大的工作负载\n- 事件驱动的短任务\n- 快速原型和实验项目\n- 无状态的服务\n\n**优势**：\n- 无需运维服务器\n- 自动弹性伸缩\n- 按量付费，成本灵活\n- 快速部署\n\n**劣势**：\n- 冷启动延迟\n- 厂商锁定风险\n- 调试和监控困难\n- 不适合长时间运行的任务\n- 状态管理复杂\n\n---\n\n## 模式选择指南\n\n### 决策树\n\n```\n系统规模？\n├─ 小型（< 5万用户，< 10人团队）\n│  └─ → 单体架构 或 模块化单体\n├─ 中型（5-50万用户，10-30人团队）\n│  ├─ 业务复杂度低？\n│  │  └─ → 模块化单体\n│  └─ 业务复杂度高？\n│     └─ → 考虑早期微服务（从 2-3 个核心服务开始）\n└─ 大型（> 50万用户，> 30人团队）\n   ├─ 领域边界清晰？\n   │  └─ → 微服务架构\n   └─ 领域耦合紧密？\n      └─ → 模块化单体 + 按需演进\n\n需要高实时性和异步处理？\n└─ 是 → 事件驱动架构（可与其他架构组合）\n\n读写操作差异大？\n└─ 是 → 考虑 CQRS\n\n运维资源有限？\n└─ 是 → 单体 或 Serverless\n```\n\n### 权衡考虑\n\n**复杂度 vs 收益**：\n- 微服务带来复杂度，只在需要时采用\n- 单体架构简单但扩展性受限\n- 避免为了微服务而微服务\n\n**团队能力**：\n- 微服务需要成熟的 DevOps 能力\n- 新团队从单体开始，逐步演进\n- 技术选型考虑团队熟悉度\n\n**业务需求**：\n- 业务快速变化？→ 模块化单体或微服务\n- 需要独立扩展？→ 微服务\n- 高实时性？→ 事件驱动\n- 成本敏感？→ Serverless\n\n**演进策略**：\n- 从单体开始\n- 随着需求增长拆分\n- 按领域边界拆分微服务\n- 避免\"大爆炸\"重构\n\n## 示例\n\n### 示例 1：电商平台\n- **推荐架构**：微服务 + 事件驱动\n- **原因**：业务复杂度高，需要独立扩展，多团队协作\n- **核心服务**：用户服务、商品服务、订单服务、支付服务、库存服务\n- **事件流**：下单 → 库存扣减 → 支付 → 物流 → 通知\n\n### 示例 2：内容管理系统（CMS）\n- **推荐架构**：模块化单体\n- **原因**：业务相对简单，中型团队，未来可能需要扩展\n- **模块划分**：内容管理、用户管理、评论、搜索\n\n### 示例 3：IoT 数据处理平台\n- **推荐架构**：事件驱动 + CQRS\n- **原因**：高实时性，写密集，读查询复杂\n- **设计**：设备数据写入事件流，读端使用时序数据库优化查询\n\n### 示例 4：内部管理后台\n- **推荐架构**：分层单体\n- **原因**：传统企业应用，用户量有限，团队熟悉\n- **分层**：Web 层 → Service 层 → DAO 层 → 数据库\n\nFile v1.2.0:references/current-state-assessment.md\n\n# 现状评估方法论\n\n## 目录\n\n1. 概览\n2. 信息化现状评估框架\n3. 政府场景现状评估\n4. 企业场景现状评估\n5. 数字化成熟度评估模型\n6. 评估方法与工具\n7. 评估报告输出规范\n\n## 概览\n\n现状评估是需求分析的基础，直接影响方案的针对性和可行性。本方法论提供系统化的现状评估框架，帮助方案设计者快速诊断客户信息化现状、识别差距和痛点，为后续方案设计提供依据。\n\n## 信息化现状评估框架\n\n### 评估维度\n\n| 维度 | 评估内容 | 评估方法 |\n|------|----------|----------|\n| 基础设施 | 网络架构、服务器/存储、云资源、终端设备 | 资产盘点、拓扑分析 |\n| 应用系统 | 系统清单、功能覆盖、技术架构、使用状态 | 系统清单表、功能矩阵 |\n| 数据资源 | 数据资产、数据标准、数据质量、数据共享 | 数据目录、质量评估 |\n| 安全合规 | 等保级别、安全架构、合规状态、信创适配 | 安全审计、合规检查 |\n| 组织能力 | IT团队规模、技术栈、运维能力、治理机制 | 人员盘点、能力矩阵 |\n| 业务流程 | 核心流程、自动化程度、跨部门协同、效率指标 | 流程梳理、效率分析 |\n\n### 评估步骤\n\n1. **信息收集**：通过访谈、问卷、文档获取现状信息\n2. **差距分析**：将现状与行业标杆或政策要求对比\n3. **痛点识别**：从效率、质量、成本、体验四个角度识别痛点\n4. **优先级排序**：按影响范围和紧迫程度排序\n5. **机会识别**：识别数字化转型的切入点和高价值场景\n\n## 政府场景现状评估\n\n### 政务系统盘点框架\n\n| 类别 | 盘点内容 | 关注点 |\n|------|----------|--------|\n| 业务系统 | 办公系统、审批系统、监管系统、服务系统 | 功能覆盖、使用率、数据孤岛 |\n| 数据平台 | 数据共享平台、数据开放平台、大数据平台 | 数据治理、共享机制、数据质量 |\n| 基础设施 | 政务云、政务网、安全设备 | 云化率、信创比例、安全等级 |\n| 公共支撑 | 统一身份认证、统一支付、统一物流、电子印章 | 覆盖范围、接口标准 |\n| 便民服务 | 政务门户、小程序、自助终端 | 事项覆盖率、网办率、用户活跃度 |\n\n### 政府评估重点\n\n1. **一网通办评估**：事项覆盖率、全程网办率、平均办理时长\n2. **数据共享评估**：部门数据共享率、数据质量达标率、接口调用频次\n3. **信创适配评估**：国产化率、信创产品适配度、迁移难度\n4. **等保合规评估**：等保级别、安全合规项、整改需求\n5. **跨部门协同评估**：协同场景覆盖、数据交换频次、流程贯通率\n\n### 政府场景常见痛点\n\n| 痛点类型 | 典型表现 | 根因分析 |\n|----------|----------|----------|\n| 数据孤岛 | 部门间数据无法共享，重复采集 | 缺乏统一数据标准和共享机制 |\n| 系统烟囱 | 各部门独立建设，功能重复 | 缺乏统筹规划和统一架构 |\n| 体验割裂 | 群众办事需多系统切换 | 缺乏统一门户和身份认证 |\n| 安全隐患 | 等保不达标，数据泄露风险 | 安全投入不足，安全架构缺失 |\n| 信创滞后 | 国产化替代进度慢 | 信创生态不成熟，迁移成本高 |\n\n## 企业场景现状评估\n\n### 数字化成熟度评估模型\n\n| 等级 | 名称 | 特征 | 典型表现 |\n|------|------|------|----------|\n| L1 | 起步阶段 | 信息化刚起步，以手工和纸质为主 | 部分业务使用Excel管理，无核心业务系统 |\n| L2 | 单点应用 | 部分业务有系统支撑，但系统孤立 | 有ERP/OA等独立系统，数据不互通 |\n| L3 | 局部集成 | 部分系统实现集成，跨部门有协同 | 核心系统间有接口，但非实时同步 |\n| L4 | 全面集成 | 主要系统全面集成，数据统一流转 | 有统一数据平台，业务流程端到端贯通 |\n| L5 | 智能优化 | 数据驱动决策，持续优化创新 | 有数据中台/AI能力，业务自动化运营 |\n\n### 企业评估维度\n\n| 维度 | 评估指标 | 评估方法 |\n|------|----------|----------|\n| 业务数字化 | 核心业务线上化率、流程自动化率 | 业务流程审计 |\n| 数据资产化 | 数据目录完整度、数据质量达标率 | 数据审计 |\n| 运营智能化 | 决策数据支撑率、预测准确率 | 分析模型审计 |\n| 生态协同化 | 上下游协同率、API开放度 | 接口审计 |\n| 组织敏捷化 | 需求响应速度、迭代周期 | DevOps成熟度 |\n\n### 企业场景常见痛点\n\n| 痛点类型 | 典型表现 | 根因分析 |\n|----------|----------|----------|\n| 效率低下 | 人工操作多，流程长，出错率高 | 流程未数字化，缺乏自动化 |\n| 数据断链 | 数据分散在多个系统，无法统一分析 | 系统孤岛，缺乏数据集成 |\n| 决策盲区 | 缺乏数据支撑，凭经验决策 | 无数据分析平台，数据资产未利用 |\n| 协同困难 | 跨部门/跨组织协作效率低 | 缺乏协同工具和流程标准 |\n| 创新不足 | 业务模式固化，难以及时响应市场变化 | IT架构僵化，缺乏敏捷能力 |\n\n## 评估方法与工具\n\n### 信息收集方法\n\n| 方法 | 适用场景 | 收集内容 | 耗时 |\n|------|----------|----------|------|\n| 结构化访谈 | 深度了解现状 | 业务痛点、系统使用体验、改进期望 | 1-2小时/人 |\n| 问卷调查 | 大范围快速摸底 | 系统满意度、功能需求、使用频次 | 15-30分钟/人 |\n| 文档分析 | 了解已有规划 | 既有方案、政策文件、技术文档 | 2-4小时 |\n| 系统演示 | 了解系统能力 | 功能覆盖、操作流程、技术架构 | 1-2小时/系统 |\n| 现场观察 | 了解实际运营 | 工作流程、协作方式、效率瓶颈 | 半天-1天 |\n\n### 差距分析方法\n\n1. **标杆对比法**：与行业标杆或最佳实践对比，识别差距\n2. **政策对标法**（政府场景）：对照政策要求逐项检查合规差距\n3. **成熟度评估法**（企业场景）：使用五级模型评估当前等级与目标等级差距\n4. **SWOT分析法**：综合分析优势、劣势、机会、威胁\n\n## 评估报告输出规范\n\n现状评估报告应包含以下核心内容：\n\n1. **评估概述**：评估范围、方法、时间、参与人员\n2. **现状描述**：按评估维度描述当前状态（附系统清单、架构图）\n3. **差距分析**：与目标/标杆的差距，量化差距指标\n4. **痛点清单**：按优先级排列的痛点列表（影响范围×紧迫程度）\n5. **机会识别**：数字化转型的高价值切入点和创新机会\n6. **建议方向**：基于评估结果的转型方向建议\n\nFile v1.2.0:references/enterprise-digitalization.md\n\n# 企业数字化转型参考\n\n## 目录\n1. 企业数字化转型特点\n2. 数字化成熟度评估模型\n3. 企业架构模式\n4. 典型场景与实施路径\n5. 关键成功要素\n\n## 概览\n本文档提供企业数字化转型的核心特点、成熟度评估模型、典型架构模式和实施路径，用于指导企业数字化场景的方案设计。\n\n## 核心内容\n\n### 1. 企业数字化转型特点\n\n#### 核心目标\n- **业务增长**：开拓新业务、新市场、新收入来源\n- **效率提升**：自动化流程、降低运营成本、提升人效\n- **体验优化**：提升客户体验、员工体验、合作伙伴体验\n- **决策智能**：数据驱动决策、预测性分析、智能运营\n\n#### 主要挑战\n- **ROI 导向**：每个投入都需量化回报，短期压力与长期投入的矛盾\n- **组织惯性**：现有流程和人员习惯难以改变\n- **数据基础薄弱**：数据分散、标准不统一、质量参差不齐\n- **系统遗产负担**：现有系统耦合度高、技术债务重\n- **市场竞争压力**：需要快速响应市场变化\n- **人才短缺**：数字化人才招聘与留存困难\n\n#### 与政府数字化的关键差异\n| 维度 | 企业数字化 | 政府数字化 |\n|------|-----------|-----------|\n| 核心驱动 | 市场竞争与利润 | 政策要求与公共服务 |\n| 成功标准 | ROI、营收增长、效率提升 | 合规性、便民度、治理能力 |\n| 决策链路 | 扁平、快速 | 多层级、审慎 |\n| 安全要求 | 商业机密保护 | 国家安全与公民隐私 |\n| 技术选型 | 开放生态、商用优先 | 信创适配、自主可控 |\n| 推广模式 | 试点→规模化→优化 | 试点→政策推广→全域覆盖 |\n\n---\n\n### 2. 数字化成熟度评估模型\n\n#### 五级成熟度模型\n\n**L1 初始阶段**：\n- 特征：手工操作为主，信息系统零散，数据不互通\n- 痛点：效率低、出错率高、依赖关键人员\n- 转型重点：基础信息化建设，核心流程线上化\n\n**L2 单点数字化**：\n- 特征：部分业务有信息系统支撑，但系统间孤立\n- 痛点：数据孤岛、流程断裂、重复录入\n- 转型重点：系统整合、数据打通、流程串联\n\n**L3 局部集成**：\n- 特征：核心业务系统已集成，部分流程自动化\n- 痛点：跨部门协同难、数据价值未释放、智能化不足\n- 转型重点：跨域集成、数据治理、流程优化\n\n**L4 全面数字化**：\n- 特征：全业务链数字化，数据驱动运营，智能决策辅助\n- 痛点：创新速度、生态协同、敏捷响应\n- 转型重点：生态连接、智能升级、敏捷组织\n\n**L5 智能化**：\n- 特征：AI 驱动决策与运营，业务自优化，生态协同\n- 重点：持续创新、行业引领、模式变革\n\n#### 评估维度\n- 业务流程数字化覆盖率\n- 数据资产化程度\n- 技术架构现代化水平\n- 组织数字化能力\n- 客户体验数字化水平\n\n#### 现状评估方法\n1. **问卷调研**：按部门/岗位填写数字化现状问卷\n2. **系统盘点**：梳理现有系统清单、功能覆盖、技术栈、使用状况\n3. **数据审计**：评估数据质量、数据标准、数据流通性\n4. **流程梳理**：识别手工流程、断点流程、高耗时流程\n5. **人员访谈**：了解痛点、期望、变革阻力\n\n---\n\n### 3. 企业架构模式\n\n#### 中台架构模式\n适用：业务多元化、需快速创新的企业\n- 业务中台：共享业务能力（用户中心、订单中心、商品中心）\n- 数据中台：统一数据资产（数据仓库、数据湖、数据服务）\n- 技术中台：技术能力共享（微服务框架、DevOps 平台、监控平台）\n- AI 中台：智能能力复用（模型训练、推理服务、标注平台）\n\n#### SaaS 化架构模式\n适用：标准化程度高的业务场景\n- 多租户架构：数据隔离、资源隔离、定制化配置\n- 订阅制模型：按需付费、灵活扩展\n- API 经济：开放 API、生态连接、平台化运营\n\n#### 混合云架构模式\n适用：有数据安全要求同时需弹性扩展的企业\n- 核心系统私有化：财务、人事、核心业务系统\n- 弹性业务上云：营销、电商、协同办公\n- 数据合规：敏感数据留本地、非敏感数据上云\n\n---\n\n### 4. 典型场景与实施路径\n\n#### 智慧供应链\n- 痛点：供应链可视化不足、响应慢、库存高\n- 方案重点：供应链可视化平台、智能预测、协同采购\n- 关键指标：库存周转率、订单交付率、供应链响应时间\n\n#### 数字化营销\n- 痛点：客户洞察不足、营销效率低、转化率不高\n- 方案重点：CDP 客户数据平台、营销自动化、全渠道触达\n- 关键指标：获客成本、转化率、客户留存率、LTV\n\n#### 智能制造\n- 痛点：生产效率低、质量管控难、设备故障频发\n- 方案重点：MES 系统、IoT 设备联网、AI 质检、预测性维护\n- 关键指标：OEE、良品率、设备利用率、能耗\n\n#### 数字化办公\n- 痛点：协同效率低、知识沉淀差、流程审批慢\n- 方案重点：协同办公平台、知识管理、流程自动化、RPA\n- 关键指标：流程审批时效、知识复用率、协作效率\n\n#### 财务数字化\n- 痛点：财务数据滞后、对账复杂、合规风险\n- 方案重点：财务共享中心、智能报账、实时结算、税务合规\n- 关键指标：月结周期、报账时效、财务人力比\n\n---\n\n### 5. 关键成功要素\n\n#### 组织保障\n- 一把手工程：数字化转型必须是 CEO 工程\n- 专职团队：设立数字化转型办公室（DTO）\n- 考核导向：将数字化指标纳入绩效考核\n\n#### 投资策略\n- 快速见效：优先选择 ROI 明确、见效快的场景\n- 分期投入：避免一次性大规模投入\n- 效益追踪：建立数字化投入产出追踪机制\n\n#### 变革管理\n- 宣贯先行：让全员理解数字化转型的必要性和方向\n- 培训赋能：分层分类开展数字化技能培训\n- 激励机制：鼓励创新、容错试错\n- 灰度推广：先试点验证，再规模化推广\n\n#### 技术治理\n- 标准先行：制定技术标准、数据标准、接口标准\n- 架构管控：建立架构评审机制，防止技术债务累积\n- 安全底座：将安全内建于开发流程，而非事后补救\n- 开放生态：优先选择开放标准和技术，避免厂商锁定\n\n## 示例\n\n### 示例1：制造业企业数字化成熟度评估\n- 企业现状：核心 ERP 已上线，但生产车间仍纸质管理，销售系统与生产系统未打通\n- 评估结果：L2（单点数字化），生产环节数字化覆盖率不足 30%\n- 转型建议：优先实施 MES + IoT 设备联网，实现生产数据实时采集，再推进 ERP-MES 集成\n\n### 示例2：零售企业数字化路线图\n- 企业现状：线下门店 + 线上电商双轨运行，会员体系割裂\n- 评估结果：L2-L3 之间，渠道数字化但未融合\n- 转型建议：建设 CDP 统一会员数据 → 全渠道营销自动化 → 供应链协同优化\n\nFile v1.2.0:references/government-digitalization.md\n\n# 政府数字化转型参考\n\n## 目录\n1. 政府数字化转型特点\n2. 合规安全要求\n3. 政务架构模式\n4. 信创适配方案\n5. 服务便民化设计\n6. 典型场景示例\n\n## 概览\n本文档提供政府数字化转型的特殊要求、架构模式、合规安全标准和服务便民化设计原则，用于指导政府数字化场景的方案设计。\n\n## 核心内容\n\n### 1. 政府数字化转型特点\n\n#### 核心目标\n- **服务便民化**：让数据多跑路，群众少跑腿\n- **治理现代化**：提升政府治理能力和效率\n- **决策科学化**：基于数据驱动决策\n- **协同高效化**：打破部门壁垒，实现跨部门协同\n\n#### 主要挑战\n- **安全合规要求高**：涉及国家安全、公民隐私\n- **流程审批复杂**：多层级决策、政策约束\n- **系统异构性**：现有系统多样、技术栈老旧\n- **数据孤岛**：部门间数据不共享、标准不统一\n- **用户群体广泛**：涵盖各年龄段、文化背景\n- **政策法规约束**：需符合国家法律法规和政策要求\n\n#### 基本原则\n- **安全第一**：安全合规是红线，不可妥协\n- **服务导向**：以群众和企业需求为中心\n- **统一标准**：遵循国家和行业标准\n- **数据共享**：在确保安全前提下推进数据共享\n- **渐进演进**：在现有基础上稳步推进，避免大爆炸式改造\n\n---\n\n### 2. 合规安全要求\n\n#### 等保分级要求（网络安全等级保护）\n\n| 等级 | 适用场景 | 关键要求 |\n|------|----------|----------|\n| 等保二级 | 一般政务系统 | 基本安全防护，定期安全评估 |\n| 等保三级 | 重要政务系统 | 强化安全防护，年度等级测评，安全审计 |\n| 等保四级 | 核心关键系统 | 最高等级防护，实时监控，应急响应 |\n\n**关键控制措施**：\n- 身份鉴别（多因素认证）\n- 访问控制（最小权限原则）\n- 安全审计（全程日志记录）\n- 数据加密（传输加密、存储加密）\n- 入侵防范（防火墙、入侵检测）\n- 恶意代码防范（防病毒、漏洞扫描）\n\n#### 数据安全相关法规\n\n**《数据安全法》**\n- 建立数据分类分级制度\n- 重要数据出境安全评估\n- 数据安全风险评估\n- 数据安全应急处置\n\n**《个人信息保护法》**\n- 告知同意原则（明示告知、单独同意）\n- 最小必要原则（仅收集必要信息）\n- 敏感个人信息加强保护\n- 个人信息跨境提供合规\n\n**《网络安全法》**\n- 网络运营者安全义务\n- 关键信息基础设施保护\n- 网络安全等级保护制度\n\n#### 政务数据分类分级\n\n**按敏感程度分类**：\n- **公开数据**：可对外公开（如政策文件、统计数据）\n- **受限数据**：特定范围可访问（如内部公文）\n- **敏感数据**：严格限制访问（如个人隐私、商业秘密）\n- **机密数据**：最高级别保护（如国家秘密）\n\n**按重要性分级**：\n- **核心数据**：关系国家安全、经济运行、公共利益\n- **重要数据**：关系重要部门、重点领域\n- **一般数据**：其他政务数据\n\n#### 安全合规评估清单\n\n- [ ] 等保测评报告（对应等级）\n- [ ] 数据安全风险评估报告\n- [ ] 个人信息保护影响评估（如涉及）\n- [ ] 第三方安全审计报告\n- [ ] 安全事件应急预案\n- [ ] 数据出境安全评估（如涉及）\n- [ ] 关键信息基础设施认定（如适用）\n\n---\n\n### 3. 政务架构模式\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│  多租户隔离：部门 A | 部门 B | ...    │\n└─────────────────────────────────────┘\n              ↓\n┌─────────────────────────────────────┐\n│     数据服务层                        │\n│  (数据共享交换、数据治理、数据仓库)    │\n└─────────────────────────────────────┘\n              ↓\n┌─────────────────────────────────────┐\n│     基础设施层                        │\n│  (计算、存储、网络、安全组件)          │\n└─────────────────────────────────────┘\n```\n\n#### 数据共享架构\n\n**数据交换模式**：\n- **实时数据交换**：通过 API 实时调用\n- **批量数据交换**：定时批量同步（ETL）\n- **消息队列交换**：异步事件驱动\n\n**数据共享平台**：\n- 统一数据目录：元数据管理\n- 数据交换总线：ETL 工具、消息队列\n- 数据质量管理：数据校验、清洗\n- 数据血缘追踪：数据来源、流向记录\n\n**数据安全控制**：\n- 访问权限控制（谁可访问什么数据）\n- 使用场景控制（什么场景可用）\n- 用量监控（防止滥用）\n- 留痕审计（谁在何时访问了什么数据）\n\n#### 跨部门协同架构\n\n**协同模式**：\n- **流程协同**：跨部门业务流程串联\n- **数据协同**：跨部门数据共享交换\n- **服务协同**：统一服务入口，后台多部门协同处理\n\n**典型场景**：\n- 企业开办：市场监管 → 税务 → 公安 → 人社\n- 不动产登记：自然资源 → 税务 → 公安 → 民政\n- 项目审批：发改委 → 自然资源 → 生态环境 → 建设部门\n\n---\n\n### 4. 信创适配方案\n\n#### 信创技术栈\n\n**国产化替代方向**：\n\n| 技术类别 | 传统技术栈 | 信创替代方案 |\n|----------|------------|--------------|\n| 芯片 | Intel/AMD | 龙芯、飞腾、海光、鲲鹏 |\n| 操作系统 | Windows、CentOS | 统信 UOS、麒麟、欧拉 |\n| 数据库 | Oracle、SQL Server、MySQL | 人大金仓、达梦、TiDB、openGauss |\n| 中间件 | WebLogic、JBoss、Tomcat | 东方通、普元、宝兰德 |\n| 应用服务器 | IIS、Apache | 东方通、普元 |\n| 办公软件 | Office、Photoshop | 永中、WPS |\n\n#### 信创适配策略\n\n**渐进式替换**：\n- 优先替换外围系统\n- 核心系统先做适配验证\n- 新建系统直接采用信创技术栈\n- 建立信创兼容性测试环境\n\n**双轨并行**：\n- 传统系统与信创系统并行运行\n- 数据双写、双读\n- 逐步切换流量\n\n**关键适配工作**：\n- 兼容性测试（功能、性能、稳定性）\n- 中间件适配（消息队列、缓存、搜索）\n- 数据库迁移（数据迁移、应用改造）\n- 硬件适配（CPU、存储、网络）\n\n#### 信创适配评估\n\n**评估维度**：\n- 技术成熟度（是否稳定可靠）\n- 生态完整性（是否有完整技术栈）\n- 性能表现（是否满足性能要求）\n- 成本（采购成本、迁移成本）\n- 团队能力（是否掌握相关技术）\n\n**适配决策**：\n- 高敏感、高优先级系统：必须适配信创\n- 一般政务系统：优先考虑信创，可保留传统技术栈\n- 对外公共服务系统：需考虑用户体验和兼容性\n\n---\n\n### 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- 办事流程不清晰，不知道怎么办\n- 办理时间长，不知道进度\n- 多头找，不知道找谁\n\n**便民化改进**：\n- **材料一次提交**：通过数据共享，避免重复提交\n- **流程一网通办**：线上申报、线上审批、线上办结\n- **进度全程可查**：短信、APP、微信推送进度\n- **咨询一口受理**：统一客服、统一咨询渠道\n\n#### 多渠道服务\n\n**线上渠道**：\n- 政务服务门户（PC 端）\n- 移动 APP、小程序\n- 自助服务终端\n\n**线下渠道**：\n- 政务服务大厅（综合窗口）\n- 社区服务站\n- 银行网点代办点\n\n**跨渠道协同**：\n- 线上预约，线下办理\n- 线下申报，线上查询\n- 多渠道信息同步\n\n#### 用户体验设计\n\n**面向不同群体**：\n- **年轻人**：强调效率、便捷、个性化\n- **老年人**：强调简单、易用、人工辅助\n- **企业**：强调效率、集成、批量处理\n\n**无障碍设计**：\n- 支持屏幕阅读器\n- 语音播报、语音输入\n- 大字体、高对比度\n- 键盘操作支持\n\n---\n\n### 6. 典型场景示例\n\n### 示例 1：政务服务\"一网通办\"平台\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- 数据安全风险评估\n- 电子签名、电子印章\n\n**便民化设计**：\n- 一次登录，全网通办\n- 材料一次提交，多部门共享\n- 全程网办，快递送达\n- 办事进度实时推送\n\n---\n\n### 示例 2：城市大脑（城市治理平台）\n\n**业务目标**：\n- 提升城市治理能力\n- 实时感知城市运行状态\n- 智能决策支持\n- 跨部门协同指挥\n\n**关键功能**：\n- 城市运行监控（交通、环境、治安、应急）\n- 数据可视化（城市数字孪生）\n- 智能预警（异常检测、风险预测）\n- 应急指挥（联动调度、应急响应）\n\n**技术架构**：\n- 大数据平台（数据采集、存储、计算）\n- AI 平台（算法模型、智能分析）\n- 物联网平台（设备接入、数据采集）\n- GIS 平台（地理信息、空间分析）\n- 指挥调度平台（统一指挥、联动调度）\n\n**数据来源**：\n- 城市摄像头（视频监控）\n- 交通传感器（车流量、路况）\n- 环境监测站（空气质量、水质）\n- 应急呼叫（110、119、120）\n- 城市物联网设备（井盖、路灯、管网）\n\n**安全合规**：\n- 等保三级或四级（视系统重要性）\n- 数据脱敏（个人隐私保护）\n- 实时监控与入侵检测\n- 应急响应机制\n\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- 企业开办\"一网通办\"\n- 证照\"多证合一\"\n- 政策精准推送\n- 诉求快速响应\n\n---\n\n### 示例 4：数据共享交换平台\n\n**业务目标**：\n- 打破数据孤岛\n- 实现跨部门数据共享\n- 支持业务协同\n\n**关键功能**：\n- 数据目录管理（元数据编目）\n- 数据申请审批（数据使用申请、审批）\n- 数据交换服务（API、批量交换）\n- 数据质量管理（数据校验、清洗）\n- 数据安全控制（访问控制、使用审计）\n- 数据血缘追踪（数据来源、流向）\n\n**技术架构**：\n- ETL 工具（数据抽取、转换、加载）\n- 消息队列（实时数据交换）\n- API 网关（数据 API 管理）\n- 数据治理平台（数据质量管理）\n- 数据安全网关（访问控制、脱敏）\n\n**安全合规**：\n- 等保三级\n- 数据安全风险评估\n- 访问权限控制\n- 操作留痕审计\n- 数据脱敏（敏感数据保护）\n\n**数据共享模式**：\n- 实时数据查询（API 调用）\n- 批量数据同步（ETL）\n- 数据订阅（消息队列）\n\n---\n\n## 实施建议\n\n### 合规先行\n- 在方案设计初期明确合规要求\n- 提前准备合规认证材料\n- 与等保测评机构、安全审计机构保持沟通\n\n### 渐进演进\n- 避免大爆炸式改造\n- 试点先行，验证后推广\n- 新建系统直接采用信创技术栈\n\n### 数据治理\n- 建立统一的数据标准和规范\n- 推进数据共享交换\n- 加强数据质量管理\n\n### 用户体验\n- 以群众和企业需求为中心\n- 多渠道服务\n- 持续优化办事流程\n\nFile v1.2.0:references/implementation-phases.md\n\n# 实施阶段参考\n\n## 目录\n1. 阶段规划原则\n2. MVP 阶段\n3. 功能扩展阶段\n4. 优化完善阶段\n5. 关键里程碑定义\n6. 实施规划模板\n7. 八阶段流程与实施阶段映射\n\n## 概览\n本文档提供数字化解决方案的实施阶段划分和规划指导，帮助制定合理的上线节奏和交付计划。同时提供八阶段流程（政策背景分析 → 需求分析 → 建设思路设计 → 架构设计 → 技术选型 → 具体建设内容 → 实施规划 → 风险评估）与实施阶段（MVP → 功能扩展 → 优化完善）的映射关系。\n\n## 核心内容\n\n### 1. 阶段规划原则\n\n#### 渐进式交付\n- **价值优先**：优先交付高价值功能\n- **快速验证**：尽早获得用户反馈\n- **风险控制**：避免一次性投入过大\n- **迭代改进**：基于反馈持续优化\n\n#### 阶段划分依据\n- **业务价值**：功能对业务目标的贡献度\n- **技术依赖**：基础功能优先于依赖功能\n- **用户反馈**：早期验证核心假设\n- **资源可用性**：团队规模和技能匹配\n- **政策合规**：政府场景需满足合规要求\n\n#### 阶段数量建议\n- **小型项目**：2-3 阶段（MVP → 完善）\n- **中型项目**：3-4 阶段（MVP → 扩展 → 优化）\n- **大型项目**：4+ 阶段（MVP → 扩展 → 优化 → 规模化）\n- **政府项目**：3-5 阶段（试点 → 推广 → 完善 → 扩展）\n\n---\n\n### 2. MVP 阶段（最小可行产品）\n\n#### 阶段目标\n- 验证核心业务假设\n- 获得早期用户反馈\n- 建立基础技术架构\n- 快速上线（通常 4-12 周）\n\n#### 功能范围\n- **核心功能**：解决用户最主要痛点的功能\n- **数据模型**：支撑核心功能的最小数据结构\n- **用户流程**：端到端的关键路径\n- **基础功能**：必要的认证、日志、监控\n\n#### 典型范围示例\n\n**电商平台 MVP**\n- 用户注册/登录\n- 商品浏览\n- 购物车\n- 下单支付\n- 基础订单管理\n- ❌ 不包含：推荐、优惠券、评价、会员系统\n\n**内容平台 MVP**\n- 内容发布\n- 内容浏览\n- 基础搜索\n- 用户互动（点赞/评论）\n- ❌ 不包含：个性化推荐、内容审核、社交功能\n\n**管理系统 MVP**\n- 核心业务模块（如订单管理）\n- 基础数据查询\n- 简单报表\n- ❌ 不包含：高级分析、权限细粒度控制、审批流程\n\n#### 技术重点\n- **架构稳定**：选择适合长期发展的架构模式\n- **技术栈确定**：确定主要技术选型\n- **基础建设**：CI/CD、监控、日志\n- **数据模型**：避免后期大改\n\n#### 交付标准\n- ✅ 核心功能可用\n- ✅ 无阻塞性 bug\n- ✅ 基础监控就绪\n- ✅ 部署流程自动化\n- ✅ 文档齐全（用户手册、运维手册）\n\n---\n\n### 3. 功能扩展阶段\n\n#### 阶段目标\n- 基于反馈完善功能\n- 扩大用户覆盖范围\n- 提升系统完整性\n- 通常持续 8-16 周\n\n#### 功能范围\n- **次要功能**：提升体验但不影响核心流程的功能\n- **数据完善**：补充数据字段和关联\n- **流程优化**：简化操作步骤、提升效率\n- **集成扩展**：与第三方系统集成\n\n#### 典型范围示例\n\n**电商平台扩展**\n- 商品评价\n- 收藏夹\n- 优惠券\n- 物流查询\n- 客服系统\n\n**内容平台扩展**\n- 用户关注\n- 内容分享\n- 评论互动\n- 话题标签\n- 内容分类\n\n**管理系统扩展**\n- 多模块管理\n- 高级搜索\n- 数据导出\n- 简单审批\n\n#### 技术重点\n- **性能优化**：缓存、数据库优化\n- **功能模块化**：提高代码可维护性\n- **监控完善**：业务指标监控\n- **自动化测试**：提升测试覆盖率\n\n#### 交付标准\n- ✅ 计划功能全部交付\n- ✅ 性能指标达标\n- ✅ 测试覆盖率 > 60%\n- ✅ 用户反馈响应及时\n- ✅ 无 P0/P1 级 bug\n\n---\n\n### 4. 优化完善阶段\n\n#### 阶段目标\n- 提升系统稳定性和性能\n- 增强用户体验\n- 支持更大规模用户\n- 持续迭代（通常 12+ 周）\n\n#### 功能范围\n- **高级功能**：增值服务、个性化功能\n- **智能特性**：推荐、自动化、AI 能力\n- **用户体验**：UI/UX 优化、交互改进\n- **性能扩展**：支持更大并发、更快响应\n\n#### 典型范围示例\n\n**电商平台优化**\n- 个性化推荐\n- 智能客服\n- 会员体系\n- 大促活动支持\n- 移动端优化\n\n**内容平台优化**\n- 个性化内容流\n- 内容推荐算法\n- 精准搜索\n- 社交关系链\n\n**管理系统优化**\n- 权限细粒度控制\n- 高级数据分析\n- 自动化工作流\n- 移动端支持\n\n#### 技术重点\n- **性能极致优化**：CDN、数据库分片、缓存策略\n- **可观测性**：全链路追踪、智能告警\n- **自动化**：自动化测试、自动化运维\n- **安全加固**：安全审计、漏洞修复\n\n#### 交付标准\n- ✅ 关键性能指标达到目标\n- ✅ 系统可用性 > 99.9%\n- ✅ 测试覆盖率 > 80%\n- ✅ 安全漏洞修复\n- ✅ 用户满意度达到目标\n\n---\n\n### 5. 关键里程碑定义\n\n#### MVP 发布里程碑\n\n**时间点**：开发启动后 4-12 周\n\n**验收标准**：\n- [ ] 核心功能完整可用\n- [ ] 端到端用户流程验证通过\n- [ ] 性能测试通过（响应时间 < 2s）\n- [ ] 安全扫描无高危漏洞\n- [ ] 部署流程文档化\n- [ ] 监控告警配置完成\n- [ ] 灰度发布方案准备就绪\n\n**风险提示**：\n- 核心假设未验证\n- 技术架构存在致命缺陷\n- 用户反馈不符合预期\n\n---\n\n#### 功能完整版里程碑\n\n**时间点**：MVP 后 8-16 周\n\n**验收标准**：\n- [ ] 计划功能全部交付\n- [ ] 用户测试通过\n- [ ] 性能达到目标（并发、响应时间）\n- [ ] 测试覆盖率 > 60%\n- [ ] P0/P1 bug 全部修复\n- [ ] 运维文档齐全\n- [ ] 备份恢复机制验证\n\n**风险提示**：\n- 功能蔓延，范围失控\n- 技术债务积累\n- 性能瓶颈未解决\n\n---\n\n#### 生产就绪版里程碑\n\n**时间点**：功能完整版后 12+ 周\n\n**验收标准**：\n- [ ] 系统可用性 > 99.9%\n- [ ] 压力测试通过\n- [ ] 灾备方案验证\n- [ ] 安全审计通过\n- [ ] 全链路监控就绪\n- [ ] 运维自动化完成\n- [ ] 团队培训完成\n\n**风险提示**：\n- 大规模流量冲击\n- 数据安全事件\n- 第三方依赖故障\n\n---\n\n### 6. 实施规划模板\n\n#### 模板结构\n\n```markdown\n# 项目实施计划\n\n## 项目概述\n- 项目名称\n- 项目目标\n- 预期成果\n\n## 阶段划分\n\n### 第一阶段：MVP（4-12 周）\n**目标**：\n- 验证核心假设\n- 快速上线获取反馈\n\n**功能范围**：\n- 功能 1：[描述]\n- 功能 2：[描述]\n- ...\n\n**里程碑**：\n- Week 2：原型设计完成\n- Week 4：核心功能开发完成\n- Week 6：内测上线\n- Week 8：灰度发布\n- Week 10：正式发布\n\n**资源需求**：\n- 开发：X 人\n- 测试：X 人\n- 产品：X 人\n\n**风险与应对**：\n- 风险 1：[描述] → [应对措施]\n- 风险 2：[描述] → [应对措施]\n\n### 第二阶段：功能扩展（8-16 周）\n...\n\n### 第三阶段：优化完善（12+ 周）\n...\n\n## 关键里程碑\n\n| 里程碑 | 时间 | 验收标准 |\n|--------|------|----------|\n| MVP 发布 | Week 10 | 见 MVP 阶段验收标准 |\n| 功能完整版 | Week 24 | 见功能完整版验收标准 |\n| 生产就绪版 | Week 36 | 见生产就绪版验收标准 |\n\n## 资源规划\n\n### 团队结构\n- 项目经理：1 人\n- 产品经理：1 人\n- 前端开发：X 人\n- 后端开发：X 人\n- 测试工程师：X 人\n- 运维工程师：X 人\n\n### 关键资源\n- 开发环境：云服务器、数据库\n- 第三方服务：支付、短信、推送\n- 工具：项目管理、CI/CD、监控\n\n## 风险管理\n\n| 风险类型 | 风险描述 | 可能性 | 影响 | 应对措施 | 责任人 |\n|----------|----------|--------|------|----------|--------|\n| 技术风险 | ... | 高/中/低 | 高/中/低 | ... | ... |\n| 业务风险 | ... | ... | ... | ... | ... |\n| 资源风险 | ... | ... | ... | ... | ... |\n\n## 沟通机制\n- 每日站会\n- 周例会\n- 阶段评审\n- 干系人汇报\n\n## 交付物清单\n- 需求文档\n- 架构设计文档\n- 接口文档\n- 测试报告\n- 运维手册\n- 用户手册\n```\n\n---\n\n## 示例\n\n### 示例 1：SaaS 平台实施计划\n\n**第一阶段：MVP（8 周）**\n- 核心功能：用户管理、基础业务模块、数据导入导出\n- 技术重点：基础架构、CI/CD、监控\n- 交付标准：100 个种子用户试用\n\n**第二阶段：扩展（12 周）**\n- 新增：高级分析、API 集成、多租户支持\n- 技术重点：性能优化、自动化测试\n- 交付标准：500 个付费用户\n\n**第三阶段：优化（16 周）**\n- 新增：AI 辅助、移动端、白标定制\n- 技术重点：高可用、智能推荐\n- 交付标准：2000 个付费用户，可用性 99.9%\n\n### 示例 2：企业内部系统\n\n**第一阶段：MVP（6 周）**\n- 核心模块：订单管理、库存查询\n- 交付标准：核心业务线上化\n\n**第二阶段：扩展（10 周）**\n- 新增：采购管理、报表分析、审批流程\n- 交付标准：覆盖 80% 业务场景\n\n**第三阶段：优化（持续）**\n- 新增：移动端审批、数据大屏、集成 ERP\n- 交付标准：全面数字化转型\n\n### 示例 3：移动 App\n\n**第一阶段：MVP（10 周）**\n- 核心功能：用户体系、核心业务流程、基础设置\n- 平台：先 iOS 或 Android（单平台）\n- 交付标准：1000 次下载，4 星以上评分\n\n**第二阶段：扩展（14 周）**\n- 新增：社交功能、推送通知、优惠活动\n- 平台：双平台支持\n- 交付标准：10000 次下载\n\n**第三阶段：优化（持续）**\n- 新增：AI 功能、AR/VR 特性\n- 交付标准：50000 次下载\n\n---\n\n### 示例 4：政务服务\"一网通办\"\n\n**第一阶段：试点（12 周）**\n- 核心功能：统一认证、一窗受理、协同审批\n- 试点范围：2-3 个部门\n- 交付标准：试点部门服务线上化\n\n**第二阶段：推广（16 周）**\n- 新增：数据共享、便民服务、移动端\n- 推广范围：所有部门\n- 交付标准：全面上线，服务覆盖率 90%\n\n**第三阶段：完善（持续）**\n- 新增：智能推荐、跨省通办、数据分析\n- 交付标准：服务质量提升，用户满意度 90%+\n\n---\n\n## 7. 政府项目特有实施流程\n\n### 7.1 政府采购流程\n\n| 采购方式 | 适用条件 | 流程 | 周期 |\n|---------|---------|------|------|\n| 公开招标 | 预算≥200万 | 需求确认→招标文件→发布公告→开标评标→公示→合同签订 | 60-90天 |\n| 竞争性谈判 | 100-200万或技术复杂 | 需求确认→谈判文件→谈判→确定成交→合同签订 | 30-45天 |\n| 竞争性磋商 | 100-200万或服务类 | 需求确认→磋商文件→磋商→评审→确定成交→合同签订 | 30-45天 |\n| 单一来源 | 唯一供应商或紧急 | 需求确认→论证→公示→协商→合同签订 | 20-30天 |\n| 询价 | <100万且标准统一 | 需求确认→询价函→报价→比选→合同签订 | 15-20天 |\n\n**采购流程关键节点**：\n1. 需求论证与预算申报\n2. 采购方式审批\n3. 招标文件编制与审核\n4. 评标委员会组建\n5. 中标公示与质疑期\n6. 合同签订与备案\n\n### 7.2 政府项目审计要求\n\n| 审计类型 | 审计时点 | 审计内容 | 关注重点 |\n|---------|---------|---------|---------|\n| 预算审计 | 项目启动前 | 预算编制合理性 | 预算依据充分、分项明细完整 |\n| 过程审计 | 项目执行中 | 资金使用合规性 | 专款专用、合同履约、变更审批 |\n| 结算审计 | 项目完成后 | 实际支出真实性 | 工程量核实、单价合理性、变更签证 |\n| 绩效审计 | 项目运行后 | 投资效果评估 | 目标达成度、效益实现、持续运营 |\n\n**审计常见风险点**：\n- 超预算执行未经审批\n- 合同变更频繁且理由不充分\n- 设备采购价格偏离市场\n- 验收标准降低或验收走过场\n- 资金拨付与工程进度不匹配\n\n### 7.3 政府项目验收标准\n\n#### 初步验收\n- 系统功能按需求规格逐项验证\n- 性能测试报告（并发、响应时间、吞吐量）\n- 安全测试报告（漏洞扫描、渗透测试）\n- 文档完整性检查（需求、设计、测试、运维、用户手册）\n\n#### 竣工验收\n- 初验问题整改确认\n- 试运行报告（连续3-6个月）\n- 等保测评报告（政府系统必须等保三级）\n- 信创适配验证报告（如有信创要求）\n- 第三方测评报告（功能/性能/安全）\n- 培训完成确认\n- 资产移交清单\n\n#### 整体验收\n- 各子系统验收通过\n- 数据迁移完成确认\n- 与上级/同级系统对接确认\n- 运维交接完成\n- 项目总结报告\n\n### 7.4 政府项目资金管理\n\n| 资金类型 | 来源 | 管理 |\n|---------|------|------|\n| 财政拨款 | 同级财政 | 预算申报→批复→拨付→核销 |\n| 专项资金 | 上级转移支付 | 专款专用、单独核算 |\n| 自筹资金 | 部门预算 | 纳入部门预算管理 |\n\n**资金管理关键规则**：\n- 严禁挪用、拆借项目资金\n- 资金拨付需与合同里程碑匹配\n- 大额支付需集体决策\n- 结余资金按规定上缴或结转\n\n### 7.5 政府项目合规审查\n\n| 审查项 | 要求 | 时间节点 |\n|--------|------|---------|\n| 等保测评 | 信息系统安全等级保护三级 | 上线前完成 |\n| 密码评估 | 商用密码应用安全性评估 | 上线前完成 |\n| 安全审查 | 网络安全审查（关键信息基础设施） | 建设前启动 |\n| 信创测评 | 信息技术应用创新测评 | 采购/验收时 |\n| 个人信息保护 | 个人信息保护影响评估 | 系统设计时 |\n| 数据出境评估 | 数据出境安全评估 | 涉及出境时 |\n\n---\n\n## 8. 八阶段流程与实施阶段映射\n\n### 映射关系\n\n| 八阶段流程 | 对应实施阶段 | 主要输出物 |\n|------------|--------------|------------|\n| 第一阶段：政策背景分析 | 规划阶段 | 政策分析报告、合规要求清单 |\n| 第二阶段：需求分析 | 规划阶段 | 需求文档、现状分析报告 |\n| 第三阶段：建设思路设计 | 规划阶段 | 建设思路文档、分期规划 |\n| 第四阶段：架构设计 | 规划阶段 | 四维度架构文档、架构图 |\n| 第五阶段：技术选型 | 规划阶段 | 技术选型文档 |\n| **第六阶段：具体建设内容** | **MVP 阶段** | **业务实施方案、功能开发计划、数据实施方案、技术实施方案** |\n| 第七阶段：实施规划 | MVP 阶段 | 实施计划、里程碑时间表 |\n| 第八阶段：风险评估 | MVP 阶段 | 风险清单、缓解措施 |\n\n### 映射说明\n\n**第六阶段：具体建设内容 → MVP 阶段**\n- 业务架构展开：业务流程设计方案、能力建设计划\n- 功能架构展开：功能模块开发计划、接口设计文档\n- 数据架构展开：数据模型设计、ETL 设计、数据字典\n- 技术架构展开：部署方案、安全方案、集成方案\n\n这些具体建设内容直接指导 MVP 阶段的开发实施。\n\n**第七阶段：实施规划 → MVP 阶段及后续阶段**\n- MVP 阶段实施计划：快速验证核心价值\n- 功能扩展阶段计划：扩展功能范围\n- 优化完善阶段计划：提升质量和性能\n\n**第八阶段：风险评估 → 全程跟踪**\n- MVP 阶段风险：验证风险、技术风险\n- 功能扩展阶段风险：集成风险、进度风险\n- 优化完善阶段风险：性能风险、安全风险\n\n### 实施阶段与八阶段流程的对应\n\n**MVP 阶段（4-12 周）**\n- 输入：第六阶段的具体建设内容、第七阶段的实施计划\n- 重点：核心业务流程、核心功能模块、基础技术架构\n- 交付：MVP 版本、用户反馈、验证结果\n\n**功能扩展阶段（8-16 周）**\n- 输入：第六阶段的功能层次实施策略、第七阶段的功能扩展计划\n- 重点：支撑功能、增强功能、集成功能\n- 交付：功能完整版、集成测试报告\n\n**优化完善阶段（12+ 周）**\n- 输入：第六阶段的技术架构展开、第七阶段的优化计划\n- 重点：性能优化、安全加固、用户体验优化\n- 交付：生产就绪版、运维手册、用户手册\n\nFile v1.2.0:references/industry-scenarios.md\n\n# 行业场景库\n\n## 目录\n1. 概览\n2. 智慧政务\n3. 智慧城市\n4. 智慧医疗\n5. 智慧教育\n6. 智慧交通\n7. 智慧金融\n8. 智慧制造\n9. 场景选型指引\n\n## 概览\n本文档提供政府和企业数字化转型中常见的行业场景参考，每个场景包含业务痛点、核心需求、典型架构模式和关键技术，帮助快速定位行业特色需求并产出针对性方案。\n\n---\n\n## 1. 智慧政务\n\n### 业务痛点\n- 多部门系统孤岛，数据共享困难，群众办事需多头跑\n- 审批流程繁琐，跨部门协同效率低\n- 政策法规频繁更新，系统适配压力大\n- 信创改造要求紧迫，存量系统迁移风险高\n\n### 核心需求\n- 一网通办：统一入口、统一认证、一窗受理、协同审批\n- 一网统管：城市运行态势感知、事件联动处置、指挥调度\n- 数据共享交换：跨部门数据归集、共享、开放\n- 政务热线整合：12345统一接听、智能分发、闭环跟踪\n\n### 典型架构模式\n- 前端：统一政务门户 + 移动端（政务微信/小程序）\n- 中台：政务数据中台 + 业务中台（统一身份认证、统一支付、统一物流）\n- 后端：微服务架构，各业务系统独立部署\n- 基础设施：政务云 + 信创适配层\n\n### 关键技术\n- 统一身份认证（OAuth2/OIDC/LDAP）\n- 电子证照与电子签章\n- 工作流引擎（Activiti/Camunda）\n- 数据共享交换平台\n- 信创适配（国产OS/DB/中间件/芯片）\n- AI智能客服与审批辅助\n\n### 方案设计要点\n- 必须遵循等保三级要求\n- 信创适配需考虑存量系统迁移路径\n- 跨部门协同需设计数据权限和业务流程编排\n- 便民化设计：最多跑一次、零跑腿、不见面审批\n\n---\n\n## 2. 智慧城市\n\n### 业务痛点\n- 城市治理碎片化，各系统数据无法联动\n- 突发事件响应慢，缺乏态势感知和预警能力\n- 城市规划决策缺乏数据支撑\n- 公共服务供给不均衡\n\n### 核心需求\n- 城市大脑：全域数据汇聚、态势感知、智能分析、辅助决策\n- 数字孪生：城市三维建模、实时映射、仿真推演\n- 城市治理：网格化管理、事件联动处置、综合执法\n- 民生服务：智慧社区、智慧停车、智慧环保\n\n### 典型架构模式\n- 感知层：IoT设备、视频监控、移动终端\n- 数据层：城市大数据平台、数据湖、实时流处理\n- 平台层：城市信息模型(CIM)平台、AI算法平台、GIS平台\n- 应用层：城市治理、民生服务、产业发展\n\n### 关键技术\n- IoT物联网平台（MQTT/CoAP）\n- 大数据平台（Hadoop/Spark/Flink）\n- GIS地理信息系统\n- 数字孪生/CIM平台\n- 视频AI分析\n- 实时流计算\n\n### 方案设计要点\n- 数据标准先行，统一城市数据编码规范\n- 分期建设：先试点区域验证，再全市推广\n- 安全合规：视频数据脱敏、个人隐私保护\n- 运营模式：政府主导+企业运营（G+B模式）\n\n---\n\n## 3. 智慧医疗\n\n### 业务痛点\n- 医疗资源分布不均，基层医疗服务能力弱\n- 医疗数据孤岛，跨院信息共享难\n- 患者就医体验差，排队时间长\n- 医保控费压力大，需精细化监管\n\n### 核心需求\n- 互联网医院：在线问诊、电子处方、药品配送\n- 区域医疗：跨院就诊一卡通、检查结果互认、双向转诊\n- 健康档案：居民全生命周期健康数据管理\n- 医疗监管：医保智能审核、医疗质量监控\n\n### 典型架构模式\n- 前端：患者App/小程序 + 医生工作站 + 管理后台\n- 中台：医疗数据中台（HL7/FHIR标准）+ AI辅助诊断平台\n- 后端：HIS/EMR/LIS/PACS系统集成\n- 基础设施：混合云（核心数据私有云 + 互联网服务公有云）\n\n### 关键技术\n- 医疗数据标准（HL7/FHIR/ICD-10）\n- 电子病历（EMR）与临床决策支持（CDSS）\n- 医学影像AI辅助诊断\n- 医保智能审核规则引擎\n- 远程医疗（视频问诊、远程会诊）\n- 区块链（处方溯源、病历授权共享）\n\n### 方案设计要点\n- 严格遵守医疗数据安全与隐私保护法规\n- 核心业务系统（HIS/EMR）必须私有化部署\n- 与医保系统对接需符合国家医保局接口规范\n- 互联网诊疗需取得互联网医院资质\n\n---\n\n## 4. 智慧教育\n\n### 业务痛点\n- 教育资源不均衡，优质师资难以覆盖偏远地区\n- 教学管理信息化程度低，数据驱动决策能力弱\n- 线上线下教学融合困难\n- 校园安全管理压力持续增大\n\n### 核心需求\n- 在线教育：直播课堂、录播回放、互动教学\n- 教育管理：教务管理、学生管理、教师发展\n- 智慧校园：一卡通、智能门禁、安防监控\n- 教育大数据：学情分析、精准教学、质量评估\n\n### 典型架构模式\n- 前端：学生端（App/Web）+ 教师端 + 管理端\n- 中台：教育数据中台 + 内容管理平台\n- 后端：教务系统 + 资源平台 + 考试系统\n- 基础设施：教育云 + 校园网\n\n### 关键技术\n- 实时音视频（WebRTC）\n- 在线考试与防作弊\n- AI个性化推荐与自适应学习\n- 教育数据挖掘与学情分析\n- 统一身份认证（教育ID）\n- 内容分发（CDN加速）\n\n### 方案设计要点\n- 需遵循教育信息化2.0行动计划\n- 数据安全：未成年个人信息特别保护\n- 互通性：遵循国家教育数据标准\n- 降本增效：优先SaaS模式，降低学校IT运维负担\n\n---\n\n## 5. 智慧交通\n\n### 业务痛点\n- 城市交通拥堵严重，信号控制效率低\n- 公共交通调度不精准，出行体验差\n- 停车难、乱停车问题突出\n- 交通事故应急响应慢\n\n### 核心需求\n- 交通大脑：全域交通态势感知、信号优化、拥堵预警\n- 智慧停车：车位感知、预约停车、无感支付\n- 公共交通：智能调度、实时到站预测、MaaS出行服务\n- 交通执法：非现场执法、违法自动识别\n\n### 典型架构模式\n- 感知层：视频监控 + 雷达 + 地磁 + ETC + 手机信令\n- 数据层：交通大数据平台（实时+历史）\n- 平台层：交通AI算法平台 + GIS + 仿真推演平台\n- 应用层：交通管理 + 出行服务 + 执法管理\n\n### 关键技术\n- 视频AI识别（车牌、车型、违法行为）\n- 实时流处理（Flink/Kafka Streams）\n- 交通仿真与信号优化\n- 高精地图与路径规划\n- 边缘计算（路侧单元MEC）\n- 车路协同（V2X）\n\n### 方案设计要点\n- 数据来源多样，需统一时空基准\n- 实时性要求高，架构需支撑毫秒级响应\n- 视频数据量大，需合理规划存储与AI分析策略\n- 与交管、城管、应急等多部门系统对接\n\n---\n\n## 6. 智慧金融\n\n### 业务痛点\n- 风控手段传统，新型欺诈识别能力不足\n- 客户体验要求提升，传统网点服务模式转型\n- 监管合规要求趋严，数据治理压力增大\n- 开放银行趋势下，API安全与生态对接挑战\n\n### 核心需求\n- 数字银行：线上开户、智能投顾、数字化信贷\n- 智能风控：反欺诈、信用评估、实时风控\n- 开放银行：API网关、生态对接、场景金融\n- 监管科技：合规报送、反洗钱、审计追溯\n\n### 典型架构模式\n- 前端：手机银行 + 网银 + 开放API\n- 中台：数据中台 + 风控中台 + AI中台\n- 后端：核心账务系统 + 信贷系统 + 支付系统\n- 基础设施：金融云（两地三中心）\n\n### 关键技术\n- 实时风控引擎（规则+模型）\n- 知识图谱（关联分析、反洗钱）\n- 联邦学习（数据不出域的联合建模）\n- API网关与开放银行平台\n- 区块链（供应链金融、跨境支付）\n- 隐私计算（多方安全计算、可信执行环境）\n\n### 方案设计要点\n- 必须符合金融监管要求（银保监会/证监会/人行）\n- 核心系统高可用（RPO=0，RTO<分钟级）\n- 数据安全等级最高，需满足等保四级\n- 开放银行API需符合行业标准（OB/BCOS）\n\n---\n\n## 7. 智慧制造\n\n### 业务痛点\n- 生产过程不透明，数据采集困难\n- 设备故障预测能力弱，非计划停机损失大\n- 供应链协同效率低，库存成本高\n- 质量管控依赖人工，一致性差\n\n### 核心需求\n- 工业互联网：设备联网、数据采集、远程监控\n- 智能工厂：MES系统、数字孪生、智能排产\n- 供应链协同：SRM+SCM+WMS一体化\n- 质量管控：SPC统计过程控制、AI质检\n\n### 典型架构模式\n- 边缘层：PLC/SCADA数据采集 + 边缘网关\n- 数据层：工业数据湖 + 时序数据库\n- 平台层：工业互联网平台 + AI分析平台\n- 应用层：MES + WMS + QMS + SRM + ERP\n\n### 关键技术\n- 工业协议适配（OPC-UA/Modbus/MQTT）\n- 边缘计算与网关\n- 时序数据库（InfluxDB/TDengine）\n- 数字孪生与3D可视化\n- 工业AI（预测性维护、视觉质检）\n- MES与ERP集成\n\n### 方案设计要点\n- OT与IT融合，需考虑工业网络安全\n- 数据采集需适配多种工业协议\n- 分期建设：先单车间试点，再工厂级推广\n- 云边协同：核心生产数据本地处理，分析数据上云\n\n---\n\n## 8. 场景选型指引\n\n### 按领域选择\n\n| 用户所属领域 | 推荐优先参考场景 | 扩展参考场景 |\n|-------------|-----------------|-------------|\n| 政府办公厅 | 智慧政务 | 智慧城市 |\n| 城管/住建 | 智慧城市 | 智慧交通 |\n| 卫健委/医院 | 智慧医疗 | - |\n| 教育局/学校 | 智慧教育 | - |\n| 交管/交通局 | 智慧交通 | 智慧城市 |\n| 银行/保险 | 智慧金融 | - |\n| 制造企业 | 智慧制造 | - |\n| 集团企业 | 智慧制造 + 智慧金融 | 智慧教育（培训）|\n\n### 按方案类型选择\n\n| 方案类型 | 场景深度建议 |\n|---------|------------|\n| 规划类 | 场景概述 + 核心痛点 + 建设方向 |\n| 申报类 | 场景痛点详细分析 + 需求与架构对应 |\n| 可研类 | 场景全面分析 + 技术方案详述 + 投资估算 |\n| 投标类 | 场景需求逐项响应 + 详细功能设计 |\n| 工作汇报 | 场景当前进展 + 问题与计划 |\n\n### 通用设计原则\n- 行业术语准确，避免通用化描述\n- 方案需体现行业特色痛点，而非泛化痛点\n- 技术选型需考虑行业合规要求（如医疗等保三级、金融等保四级）\n- 参考同行业标杆案例，增强方案说服力\n\nFile v1.2.0:references/solution-quality-checklist.md\n\n# 方案质量评审检查清单\n\n## 目录\n\n1. 概览\n2. 通用质量标准\n3. 规划类方案检查清单\n4. 申报类方案检查清单\n5. 可研类方案检查清单\n6. 投标类方案检查清单\n7. 工作汇报类方案检查清单\n8. 四维度架构一致性校验\n\n## 概览\n\n本检查清单用于方案产出后的质量自审，确保各类方案内容完整、逻辑严密、符合评审标准。方案完成后必须逐项检查，未通过项需补充修改。\n\n## 通用质量标准\n\n所有方案类型均需满足：\n\n| 维度 | 检查项 | 通过标准 |\n|------|--------|----------|\n| 完整性 | 章节结构 | 符合对应方案类型的框架结构，无缺失章节 |\n| 一致性 | 术语统一 | 同一概念全文使用统一术语，无歧义表述 |\n| 一致性 | 数据对齐 | 预算数据、效益数据、时间数据前后一致 |\n| 逻辑性 | 因果链路 | 问题→目标→方案→效益形成完整因果链 |\n| 逻辑性 | 论证充分 | 关键结论有数据/政策/案例支撑 |\n| 可读性 | 结构清晰 | 章节层次不超过4级，段落有明确主题 |\n| 可读性 | 图表辅助 | 架构设计、数据流、实施计划有可视化图表 |\n| 规范性 | 格式统一 | 标题编号、字体字号、图表编号格式统一 |\n\n## 规划类方案检查清单\n\n| # | 检查项 | 检查内容 | 优先级 |\n|---|--------|----------|--------|\n| 1 | 政策背景 | 是否梳理国家/行业/地方三级政策 | 高 |\n| 2 | 现状问题 | 是否从业务、技术、管理三个维度分析现状问题 | 高 |\n| 3 | 建设目标 | 目标是否可量化、可考核（有明确指标） | 高 |\n| 4 | 建设思路 | 是否明确建设路径和分期策略 | 高 |\n| 5 | 业务架构 | 是否体现核心业务流程和业务能力 | 中 |\n| 6 | 关键建设内容 | 是否覆盖核心业务场景的关键建设项 | 高 |\n| 7 | 预期效益 | 是否包含量化效益指标和定性效益描述 | 中 |\n| 8 | 客户吸引力 | 方案是否能在5分钟内让客户理解核心价值 | 高 |\n\n## 申报类方案检查清单\n\n| # | 检查项 | 检查内容 | 优先级 |\n|---|--------|----------|--------|\n| 1 | 建设背景 | 政策依据和业务驱动力是否充分 | 高 |\n| 2 | 需求分析 | 是否覆盖业务需求、用户需求、功能需求 | 高 |\n| 3 | 建设目标 | 是否有明确的总体目标和分项目标 | 高 |\n| 4 | 四维度架构 | 业务/功能/数据/技术架构是否完整且协同一致 | 高 |\n| 5 | 主要建设内容 | 是否与架构设计对应，无遗漏 | 高 |\n| 6 | 实施计划 | 是否有分期实施安排和关键里程碑 | 中 |\n| 7 | 效益分析 | 经济效益是否可量化，社会/管理效益是否明确 | 高 |\n| 8 | 费用估算 | 是否有分项费用明细和估算依据 | 高 |\n| 9 | 立项说服力 | 方案是否能让审批领导快速理解必要性和可行性 | 高 |\n\n## 可研类方案检查清单\n\n| # | 检查项 | 检查内容 | 优先级 |\n|---|--------|----------|--------|\n| 1 | 总论 | 是否包含项目概述、建设内容概述、投资概述、效益概述 | 高 |\n| 2 | 背景与必要性 | 是否论证充分，有政策依据和现实需求支撑 | 高 |\n| 3 | 需求分析 | 是否细化到业务/用户/功能/数据/性能/安全/运维七维度 | 高 |\n| 4 | 总体建设方案 | 是否有明确的总体架构和建设路线 | 高 |\n| 5 | 建设内容 | 是否与需求逐项对应，无需求无建设内容 | 高 |\n| 6 | 技术方案与选型 | 是否有技术路线、关键技术、选型依据、信创适配（政府场景） | 高 |\n| 7 | 实施计划 | 是否有详细的WBS、里程碑、资源需求 | 高 |\n| 8 | 投资估算 | 是否有详细的分项估算和估算依据 | 高 |\n| 9 | 效益分析 | 是否有量化经济效益、社会效益（政府）/管理效益（企业） | 高 |\n| 10 | 风险分析 | 是否识别关键风险并有缓解措施 | 中 |\n| 11 | 专家评审适配 | 方案是否能回答专家常见质疑（必要性、可行性、经济性） | 高 |\n\n## 投标类方案检查清单\n\n| # | 检查项 | 检查内容 | 优先级 |\n|---|--------|----------|--------|\n| 1 | 需求理解 | 是否逐项响应招标需求，无遗漏 | 高 |\n| 2 | 总体建设方案 | 是否体现技术优势和方案亮点 | 高 |\n| 3 | 详细功能设计 | 功能点是否逐项覆盖招标需求 | 高 |\n| 4 | 项目实施与管理 | 实施方法论、团队组织、进度计划是否可行 | 高 |\n| 5 | 安全与合规 | 是否满足等保要求（政府场景）和安全规范 | 高 |\n| 6 | 运维服务 | SLA 是否明确可执行，服务内容是否完整 | 中 |\n| 7 | 培训方案 | 培训计划是否覆盖各层级用户 | 中 |\n| 8 | 报价文件 | 报价是否合理，分项报价是否完整 | 高 |\n| 9 | 评标响应度 | 是否逐项响应评标标准，有对应得分点 | 高 |\n| 10 | 差异化竞争力 | 是否体现与竞品的差异化优势 | 高 |\n\n## 工作汇报类方案检查清单\n\n| # | 检查项 | 检查内容 | 优先级 |\n|---|--------|----------|--------|\n| 1 | 工作背景 | 是否简明说明项目背景和目标 | 中 |\n| 2 | 问题描述 | 问题是否客观、具体、可量化 | 高 |\n| 3 | 当前进度 | 工作内容是否按模块/阶段清晰呈现 | 高 |\n| 4 | 工作成果 | 成果是否有量化指标支撑 | 高 |\n| 5 | 存在问题 | 是否客观反映困难，不回避不夸大 | 高 |\n| 6 | 下一步计划 | 计划是否具体、可执行、有时限 | 高 |\n| 7 | 需要支持 | 是否明确提出所需资源和支持 | 高 |\n| 8 | 简洁性 | 汇报是否能在10分钟内讲完 | 中 |\n\n## 四维度架构一致性校验\n\n四维度架构设计完成后，必须进行一致性校验：\n\n| 校验维度 | 校验内容 | 检查方法 |\n|----------|----------|----------|\n| 业务→功能 | 每个业务能力是否有对应功能模块支撑 | 逐条映射检查 |\n| 功能→数据 | 每个功能模块是否有数据模型支撑 | 数据依赖分析 |\n| 数据→技术 | 每类数据存储是否有对应技术组件 | 存储技术映射 |\n| 业务→技术 | 每个核心业务流程是否有端到端技术支撑 | 流程技术追踪 |\n| 功能→业务 | 是否存在无业务价值的功能模块 | 反向映射检查 |\n| 数据→业务 | 数据模型是否覆盖所有业务实体 | 实体覆盖检查 |\n\n校验方法：绘制四维度映射矩阵，逐一检查映射关系，缺失映射标记为待补充。\n\nFile v1.2.0:references/solution-type-frames.md\n\n# 方案类型框架说明\n\n## 概览\n本文档定义了五类常见的数字化解决方案类型及其标准结构框架，用于指导不同场景下的方案产出。\n\n## 方案类型列表\n\n### 一、规划类方案\n\n**作用**：初次与客户接触，根据客户初步需求，形成比较粗颗粒度的规划想法和方案，以打动客户为目的。\n\n**适用场景**：客户初步接触、需求模糊、需要展示整体愿景和规划思路。\n\n**结构框架**：\n1. **政策背景分析**\n   - 国家/省/市/区县政策依据\n   - 行业发展趋势\n   - 政策机遇与挑战\n\n2. **现状问题分析**\n   - 信息化现状梳理\n   - 存在的主要问题\n   - 行业标杆对比\n\n3. **建设目标及思路**\n   - 总体建设目标\n   - 建设原则\n   - 建设路径\n\n4. **总体架构设计**（主要为业务架构）\n   - 业务架构（简化版）\n   - 建设范围与边界\n\n5. **关键建设内容**\n   - 重点建设项目概述\n   - 核心功能模块\n   - 预期成果\n\n6. **预期建设效益**\n   - 业务效益\n   - 管理效益\n   - 社会效益\n\n**特点**：内容粗颗粒度，强调愿景和方向，不涉及详细设计和费用。\n\n---\n\n### 二、申报类方案\n\n**作用**：比规划类方案内容进一步细化，融入了一定的实际需求内容，主要帮助客户向自己的领导进行汇报并获得领导同意。\n\n**适用场景**：客户需要向内部领导汇报申请立项、预算审批。\n\n**结构框架**：\n1. **项目建设背景**\n   - 政策背景\n   - 行业背景\n   - 项目背景\n\n2. **现状需求及问题分析**\n   - 信息化现状\n   - 业务需求分析\n   - 存在问题分析\n\n3. **建设目标**\n   - 总体目标\n   - 分期目标\n   - 量化指标\n\n4. **总体架构设计**\n   - 业务架构\n   - 数据架构\n   - 系统功能架构\n   - 技术架构\n\n5. **主要建设内容**\n   - 应用系统建设\n   - 数据资源建设\n   - 基础设施建设\n   - 安全保障建设\n\n6. **大致的实施计划**\n   - 分期建设计划\n   - 关键里程碑\n   - 资源需求\n\n7. **预期建设效益分析**\n   - 经济效益\n   - 社会效益\n\n8. **建设费用估算**\n   - 总投资估算\n   - 分项费用估算\n\n**特点**：内容较规划类更细化，包含费用估算，架构设计涵盖四维度。\n\n---\n\n### 三、可研类方案\n\n**作用**：建设项目的可行性研究方案，项目立项审批核心文件，内容比申报类方案更细化，在此过程中，客户需求已基本全部掌握，方案主要用于向相关财政部门申请预算使用，可研类方案需要客户邀请并组织专家进行评审。\n\n**适用场景**：项目立项审批、财政预算申请、专家评审。\n\n**结构框架**：\n\n#### 1. 总论\n- 项目名称\n- 项目建设单位\n- 项目建设地点\n- 项目建设周期\n- 项目总投资及资金来源\n- 项目建设目标与核心内容\n- 可研报告编制依据\n- 主要结论与建议\n\n#### 2. 项目建设背景与必要性\n- 国家/省/市/区县政策依据\n- 行业发展现状与趋势\n- 本地区/本部门信息化现状\n- 当前存在的问题\n- 项目建设必要性与可行性\n\n#### 3. 项目需求分析\n- 业务需求分析\n- 用户需求分析\n- 系统功能需求分析\n- 数据需求分析\n- 性能需求分析\n- 安全需求分析\n- 运维需求分析\n\n#### 4. 总体建设方案\n- 建设目标\n- 建设原则\n- 总体架构设计（技术架构、应用架构、数据架构等）\n- 建设范围与边界\n- 与现有系统的衔接\n\n#### 5. 项目建设内容\n按照总体建设方案设计的内容逐项展开：\n- 基础设施建设\n- 应用系统建设\n- 数据资源体系建设\n- 安全保障体系建设\n- 运维服务体系建设\n\n#### 6. 技术方案与选型\n- 技术路线选择\n- 关键技术说明\n- 软硬件产品选型\n- 接口与集成方案\n- 信创适配方案（政府场景）\n\n#### 7. 项目实施计划\n- 实施阶段划分\n- 项目进度安排\n- 项目组织管理\n- 项目人员配置\n\n#### 8. 投资估算与资金筹措\n- 投资估算依据\n- 总投资估算（分项说明）：\n  - 硬件设备费\n  - 软件购置费/开发费\n  - 实施服务费\n  - 数据资源费\n  - 安全测评费\n  - 培训费\n  - 运维费\n- 资金筹措方案\n\n#### 9. 效益分析\n- 经济效益分析\n- 社会效益分析\n\n#### 10. 风险分析与对策\n- 政策风险\n- 技术风险\n- 管理风险\n- 资金风险\n- 运维风险\n- 风险应对措施\n\n**特点**：内容最全面、最细化，需要经过专家评审，包含详细的投资估算和风险分析。\n\n---\n\n### 四、投标类方案\n\n**作用**：客户可研方案评审通过后，需要进行公开招投标，以选拔项目的承建厂商，有意向的厂商需要根据客户发布的招标需求，编制投标方案。\n\n**适用场景**：公开招投标、竞争性谈判。\n\n**结构框架**：\n\n#### 1. 项目需求理解与分析\n- 项目建设背景与政策依据\n- 现状痛点分析\n- 核心需求拆解\n- 项目建设目标\n\n#### 2. 总体建设方案\n- 建设思路与原则\n- 总体架构设计（技术架构、应用架构、数据架构、安全架构等）\n- 建设范围与边界\n- 关键技术路线\n\n#### 3. 详细功能设计方案\n核心业务系统功能模块，需按照招标需求内容逐项响应，并附上功能清单：\n- 管理后台功能\n- 运维平台功能\n- 数据服务与分析功能\n- 接口与集成方案\n- 信创/国产化适配方案（政府场景）\n\n#### 4. 项目实施与管理方案\n- 项目组织架构\n- 关键人员简历\n- 实施方法论\n- 项目进度计划\n- 质量管理方案\n- 风险管控\n- 变更管理\n\n#### 5. 信息安全与合规方案\n- 网络安全方案\n- 数据安全方案\n- 应用安全方案\n- 等保测评与合规（政府场景）\n- 安全管理制度与应急响应\n\n#### 6. 运维服务与保障方案\n- 运维服务模式\n- 运维内容\n- 服务级别协议（SLA）\n- 运维团队与工具\n- 售后保障机制\n\n#### 7. 培训方案\n- 培训计划\n- 培训内容与教材\n- 培训方式\n- 培训考核与效果保障\n\n#### 8. 项目报价文件\n- 投标报价汇总表\n- 详细报价清单\n\n**特点**：围绕招标需求响应，强调技术实力、实施能力、管理能力和价格竞争力。\n\n---\n\n### 五、工作汇报类方案\n\n**作用**：项目开展后，在执行的过程中，需要阶段性的给客户反馈工作进度情况，以获得客户的肯定和新的指示、新的需求。\n\n**适用场景**：项目执行过程中的阶段性汇报、里程碑评审、需求变更汇报。\n\n**结构框架**：\n1. **工作背景**\n   - 项目背景\n   - 汇报周期\n   - 汇报目的\n\n2. **需要解决的问题**\n   - 当前面临的问题\n   - 问题影响分析\n\n3. **当前正在开展的工作内容及完成情况**\n   - 本阶段工作内容\n   - 完成情况\n   - 与计划对比\n\n4. **已经产生的工作成果及成效**\n   - 交付物清单\n   - 成果展示\n   - 成效评估\n\n5. **当前工作开展中存在的问题**\n   - 问题清单\n   - 原因分析\n\n6. **下一步工作计划**\n   - 下阶段工作内容\n   - 计划安排\n   - 预期成果\n\n7. **需要领导给予的支持**\n   - 资源需求\n   - 决策事项\n   - 协调事项\n\n**特点**：简洁实用，重点突出工作进展、成果和需要支持的事项。\n\n---\n\n## 方案类型选择指南\n\n### 根据项目阶段选择\n- **项目初期接触** → 规划类方案\n- **客户内部汇报立项** → 申报类方案\n- **正式立项审批** → 可研类方案\n- **公开招标采购** → 投标类方案\n- **项目执行过程** → 工作汇报类方案\n\n### 根据内容深度选择\n- **粗颗粒度、展示愿景** → 规划类方案\n- **中颗粒度、包含费用** → 申报类方案\n- **细颗粒度、全面详细** → 可研类方案\n- **响应招标需求、强调竞争力** → 投标类方案\n- **汇报进展、聚焦执行** → 工作汇报类方案\n\n### 根据目标受众选择\n- **客户业务负责人** → 规划类方案\n- **客户内部领导** → 申报类方案\n- **财政部门、评审专家** → 可研类方案\n- **招标评审委员会** → 投标类方案\n- **客户项目组、领导** → 工作汇报类方案\n\n## 补充说明\n\n1. 若用户需要的方案类型不在上述示例当中，可以主动询问客户，或者从互联网搜索一些同类型方案的框架，供客户参考确认。\n\n2. 在设计方案内容时，有些章节内容需要结合客户的实际需求或是信息化现状情况，这些内容可以主动邀请用户提供一些，若用户无法提供，可以从互联网搜索一些同类型客户的共性现状需求和问题。\n\nArchive v1.1.2: 10 files, 40176 bytes\n\nFiles: README.md (19429b), references/architecture-dimensions.md (22256b), references/architecture-patterns.md (7187b), references/government-digitalization.md (14354b), references/implementation-phases.md (12642b), references/solution-type-frames.md (8662b), references/technology-stack-guide.md (8213b), scripts/generate-architecture-diagram.py (7520b), SKILL.md (5727b), _meta.json (144b)\n\nFile v1.1.2:SKILL.md\n\n---\nname: digital-solution-designer\ndescription: 系统化设计数字化解决方案，涵盖方案类型识别、政策背景分析、需求分析、建设思路设计、架构设计（业务、功能、数据、技术四维度）、技术选型、具体建设内容、实施规划、风险评估和投资估算的全流程能力。适用于规划类、申报类、可研类、投标类和工作汇报类等多种方案产出场景，覆盖政府数字化转型和企业数字化转型两大核心领域。\ndependency:\n  python:\n    - graphviz>=0.20.1\n---\n\n# 数字化解决方案设计\n\n## 任务目标\n系统化设计数字化解决方案，从方案类型识别到实施规划的完整流程，支持多种方案类型的结构化输出。\n\n核心领域：政府数字化转型、企业数字化转型。\n\n触发条件：\"设计[系统/平台/应用]解决方案\"、\"规划[业务场景]数字化方案\"、\"评估[系统]升级方案\"、\"设计[领域]技术架构\"、\"政府数字化转型\"、\"政务系统\"、\"一网通办\"、\"数字政府\"、\"规划方案\"、\"申报方案\"、\"可研方案\"、\"投标方案\"、\"工作汇报\"\n\n## 方案类型识别规则（强制执行）\n1. **强制询问**：用户输入需求后，**必须先询问**方案类型，禁止推导或猜测。\n   - 询问语：\"请问您需要产出哪种类型的方案？可选择：规划类、申报类、可研类、投标类、工作汇报类\"\n2. **等待确认**：待用户明确反馈后，再根据所选类型编写方案。\n\n各类型详细说明见 `README.md`。\n\n## 操作流程（按方案类型选择执行）\n\n### 第零阶段：方案类型识别（必执行）\n询问用户方案类型，确认后按下方映射执行。\n\n**方案类型流程映射**：\n- **规划类**：第一阶段(政策背景) → 第二阶段(简化需求) → 第三阶段(建设思路) → 4.1(简化业务架构) → 第六阶段(简化建设内容) → 效益分析\n- **申报类**：第一阶段 → 第二阶段 → 第三阶段 → 第四阶段(四维度架构) → 第六阶段(主要建设内容) → 第七阶段(简化实施计划) → 效益分析 → 费用估算\n- **可研类**：全部阶段(第一至第八阶段) + 投资估算。需求需细化至业务、用户、功能、数据、性能、安全、运维；技术选型需详细。\n- **投标类**：第二阶段(需求理解) → 第三阶段(总体方案) → 第四阶段(四维度架构) → 详细功能设计 → 项目管理方案 → 安全合规方案 → 运维方案 → 培训方案 → 报价文件\n- **工作汇报类**：特殊结构(工作背景→问题→当前工作→成果→问题→下一步计划→需支持)\n\n### 第一阶段：政策背景分析\n梳理政策环境，分析影响与合规要求。输出政策分析报告。\n\n### 第二阶段：需求分析\n行业与客户现状分析，收集核心需求并排序(MoSCoW/MVP)。输出需求文档。\n\n### 第三阶段：建设思路设计\n确定目标、原则、路径与分期规划。输出建设思路文档。\n\n### 第四阶段：架构设计（四维度）\n- **业务架构**：梳理流程与能力，生成架构图。使用 `python scripts/generate-architecture-diagram.py --diagram-type business --input business.dot --output business.png`\n- **功能架构**：划分模块与层次，生成架构图。使用 `--diagram-type functional`\n- **数据架构**：设计模型、数据流、标准与治理，生成架构图。使用 `--diagram-type data`\n- **技术架构**：确定模式、部署、安全与集成设计，生成架构图。使用 `--diagram-type technical`\n架构图生成需预装 `graphviz`，DOT 模板参考 `references/architecture-dimensions.md`。\n\n### 第五阶段：技术选型\n确定选型维度并评估技术栈。参考 `references/technology-stack-guide.md`。\n\n### 第六阶段：具体建设内容\n将四维度架构转化为具体建设任务：业务实施、功能开发、数据实现、技术部署。\n\n### 第七阶段：实施规划\n规划实施阶段(MVP→扩展→优化)，分解任务与里程碑。参考 `references/implementation-phases.md`。\n\n### 第八阶段：风险评估\n识别并评估风险，制定缓解策略。\n\n### 第九阶段：效益分析与投资估算\n- **效益分析**：经济/社会/管理效益。\n- **投资估算**：申报/可研/投标类必需。包含硬件、软件、服务、数据、测评、培训、运维等分项。\n\n### 第十阶段：特殊章节（按类型增加）\n- 详细功能设计（投标类）\n- 项目实施与管理方案（投标类）\n- 信息安全与合规方案（投标、可研类）\n- 运维服务与保障方案（投标类）\n- 培训方案（投标类）\n\n## 可选分支\n- 快速原型 / 企业级 / 创新项目 / 遗留系统迁移 / 政府数字化转型(参考 `references/government-digitalization.md`)\n\n## 资源索引\n- 架构图脚本：`scripts/generate-architecture-diagram.py`\n- 方案类型框架：`references/solution-type-frames.md`\n- 架构模式参考：`references/architecture-patterns.md`\n- 架构维度参考：`references/architecture-dimensions.md`\n- 技术选型指南：`references/technology-stack-guide.md`\n- 实施阶段参考：`references/implementation-phases.md`\n- 政府数字化参考：`references/government-digitalization.md`\n\n## 注意事项\n- **强制询问方案类型**：用户输入后必须先询问，不可推导。\n- **阶段迭代**：根据方案类型选择所需阶段。\n- **产出导向**：每阶段产出明确文档。\n- **业务优先**：技术服务于业务目标。\n- **四维度协同**：业务、功能、数据、技术架构需一致。\n- **架构图生成**：使用指定脚本。\n- **详细说明见 `README.md`**。\n\nFile v1.1.2:README.md\n\n# 数字化解决方案设计 Skill 详细说明\n\n本 Skill 用于系统化设计数字化解决方案，支持政府和企业数字化转型场景下的多种方案类型。\n\n## 支持的方案类型\n\n### 1. 规划类方案\n- **适用场景**：初次接触客户，粗颗粒度规划，以打动客户为目的。\n- **输出重点**：政策背景、现状问题、建设目标及思路、业务架构（简化）、关键建设内容、预期效益。\n\n### 2. 申报类方案\n- **适用场景**：客户内部汇报、立项申请、预算审批。\n- **输出重点**：建设背景、需求分析、建设目标、四维度架构、主要建设内容、实施计划（简化）、效益分析、费用估算。\n\n### 3. 可研类方案\n- **适用场景**：项目立项审批、财政预算申请、专家评审。\n- **输出重点**：总论、背景与必要性、需求分析（细化至业务、用户、功能、数据、性能、安全、运维）、总体建设方案、建设内容、详细技术方案与选型、实施计划、投资估算、效益分析、风险分析。\n\n### 4. 投标类方案\n- **适用场景**：公开招投标、竞争性谈判。\n- **输出重点**：需求理解、总体建设方案、详细功能设计、实施与管理、安全与合规、运维服务、培训方案、报价文件。\n\n### 5. 工作汇报类方案\n- **适用场景**：项目执行过程汇报、里程碑评审、需求变更汇报。\n- **输出结构**：工作背景 → 需要解决的问题 → 当前工作及完成情况 → 成果及成效 → 存在问题 → 下一步计划 → 需要领导支持。\n\n---\n\n## 各阶段详细说明\n\n### 第一阶段：政策背景分析\n1. 梳理政策环境（国家/行业/地方/国际政策）\n2. 分析政策影响（指导意义、机遇、约束、趋势）\n3. 识别合规要求（法律法规、行业标准、数据安全、技术标准）\n4. 输出政策分析报告（政策环境、关键解读、合规清单、机遇挑战）\n\n检查点：✅ 政策环境梳理全面、✅ 合规要求识别清晰、✅ 政策影响分析到位\n\n### 第二阶段：需求分析\n1. 行业现状分析（趋势、技术、竞争、痛点）\n2. 客户现状问题分析（系统流程、痛点、瓶颈、差距）\n3. 收集核心需求（业务目标、用户场景、功能范围、非功能需求、约束条件）\n4. 需求优先级排序（MoSCoW 方法、MVP 范围、基础/增强/创新需求）\n5. 输出需求文档（行业/客户现状分析、需求概述、功能清单、非功能需求、MVP 定义）\n\n检查点：✅ 行业现状分析深入、✅ 客户问题诊断准确、✅ 业务价值明确、✅ 功能边界清晰、✅ MVP 范围可界定\n\n### 第三阶段：建设思路设计\n1. 确定总体建设目标（战略愿景、量化目标、价值主张、成功标准）\n2. 制定建设原则（业务价值导向、用户体验中心、技术业务融合、渐进演进）\n3. 设计建设路径（自建/采购/合作、传统/云原生/信创、实施模式、转型策略）\n4. 规划分期建设（分期原则、各期目标范围、交付物、依赖关系）\n5. 输出建设思路文档（目标愿景、建设原则、路径策略、分期规划、价值主张）\n\n检查点：✅ 建设目标清晰可量化、✅ 建设原则指导性强、✅ 建设路径合理可行、✅ 分期规划逻辑清晰\n\n### 第四阶段：架构设计（四维度）\n\n#### 4.1 业务架构\n- 梳理业务流程（核心/支撑/管理/跨部门协同）\n- 识别业务能力（核心/支撑/管理/集成能力）\n- 设计业务关系（实体/协作/流转/服务关系）\n- 生成业务架构图（DOT 格式，调用脚本）\n检查点：✅ 业务流程覆盖全面、✅ 业务能力边界清晰、✅ 业务关系逻辑合理、✅ 架构图清晰准确\n\n#### 4.2 功能架构\n- 划分功能模块（按业务领域/用户角色/系统层次/业务能力）\n- 设计功能层次（核心/支撑/增强/集成功能层）\n- 设计功能关系（依赖/调用/协作/复用关系）\n- 生成功能架构图\n检查点：✅ 功能模块划分合理、✅ 功能层次清晰、✅ 功能关系明确、✅ 架构图清晰准确\n\n#### 4.3 数据架构\n- 设计数据模型（实体/属性/关系/类型约束）\n- 设计数据流（业务/系统/跨系统数据流，采集/存储/处理/应用）\n- 设计数据标准（字典/编码/质量管理标准）\n- 设计数据治理（分类分级/安全隐私/生命周期/共享开放）\n- 生成数据架构图\n检查点：✅ 数据模型完整、✅ 数据流清晰、✅ 数据标准统一、✅ 数据治理方案可行、✅ 架构图清晰准确\n\n#### 4.4 技术架构\n- 确定技术架构模式（参考 `references/architecture-patterns.md`）\n- 设计部署架构（拓扑/分层/容器化/高可用容灾）\n- 设计安全架构（网络/应用/数据/运维安全）\n- 设计集成架构（API网关/服务注册/消息队列/数据交换）\n- 生成技术架构图\n检查点：✅ 架构模式选择合理、✅ 部署架构可行、✅ 安全架构完善、✅ 集成架构灵活、✅ 架构图清晰准确\n\n### 第五阶段：技术选型\n1. 确定技术选型维度（前端、后端、数据存储、中间件、基础设施）\n2. 技术栈评估：参考 `references/technology-stack-guide.md`，评估成熟度、社区生态、团队能力、成本，进行关键技术权衡\n3. 输出技术选型文档（技术栈清单、选型依据与权衡、潜在风险与备选方案）\n检查点：✅ 技术选型有明确依据、✅ 考虑了团队能力匹配、✅ 关键技术有备选方案\n\n### 第六阶段：具体建设内容\n本阶段将架构设计转化为具体的建设任务和交付物。\n\n#### 6.1 业务架构展开\n- 业务流程实施设计（关键流程设计、流程优化、跨部门协同）\n- 业务能力建设计划（实施路径、时间表、资源需求）\n- 业务关系实现设计（协作机制、服务契约）\n检查点：✅ 业务流程设计完整、✅ 能力建设计划可执行、✅ 协作机制明确\n\n#### 6.2 功能架构展开\n- 功能模块开发计划（功能点清单、开发计划、验收标准）\n- 功能层次实施策略（核心/支撑/增强/集成功能的实施顺序）\n- 功能关系实现设计（接口设计、数据流设计）\n检查点：✅ 功能模块覆盖全面、✅ 开发计划可执行、✅ 接口设计完整\n\n#### 6.3 数据架构展开\n- 数据模型实现设计（表结构、数据字典、数据初始化）\n- 数据流实现设计（ETL 方案、同步策略、缓存策略）\n- 数据标准实施（数据规范、质量管控）\n- 数据治理实施（数据安全、权限控制、生命周期管理）\n检查点：✅ 数据模型设计完整、✅ 数据流设计可行、✅ 数据安全措施到位\n\n#### 6.4 技术架构展开\n- 部署架构实施设计（环境准备、部署方案、监控方案）\n- 安全架构实施设计（安全策略、安全配置、安全测试）\n- 集成架构实施设计（API 设计、中间件配置、系统集成）\n检查点：✅ 部署方案可行、✅ 安全措施完善、✅ 集成方案完整\n\n### 第七阶段：实施规划\n1. 规划实施阶段：参考 `references/implementation-phases.md`，阶段划分 MVP → 功能扩展 → 优化完善\n2. 任务分解与排期（WBS、任务依赖、资源需求）\n3. 关键里程碑定义（MVP 发布、功能完整版、生产就绪版）\n4. 输出实施计划（阶段规划、里程碑时间表、资源需求）\n检查点：✅ MVP 可快速交付、✅ 阶段划分合理、✅ 里程碑可度量\n\n### 第八阶段：风险评估\n1. 识别关键风险（技术、业务、项目、运维风险）\n2. 风险评估（发生概率、影响程度、风险等级）\n3. 制定缓解策略（预防措施、应急预案、责任人）\n4. 输出风险清单（风险分类与等级、缓解措施、监控指标）\n检查点：✅ 关键风险已识别、✅ 高风险有缓解措施、✅ 风险可跟踪\n\n### 第九阶段：效益分析与投资估算\n\n#### 9.1 效益分析\n- 经济效益：成本节约、收入增长、投资回报率（ROI）计算\n- 社会效益（政府场景重点）：服务效率提升、群众满意度提升、政府治理能力提升\n- 管理效益（企业场景重点）：管理效率提升、决策支持能力提升、业务协同能力提升\n\n#### 9.2 投资估算（申报类、可研类、投标类方案必需）\n1. 确定投资估算依据（参考市场价格、行业标准、类似项目）\n2. 总投资估算（分项说明）：\n   - 硬件设备费（服务器、存储、网络设备等）\n   - 软件购置费/开发费（基础软件、定制开发）\n   - 实施服务费（咨询、实施、集成）\n   - 数据资源费（数据采集、清洗、迁移）\n   - 安全测评费（等保测评、安全评估）\n   - 培训费（培训讲师、培训材料）\n   - 运维费（年度运维、技术支持）\n3. 资金筹措方案（资金来源、分期资金安排、资金使用计划）\n检查点：✅ 投资估算依据充分、✅ 分项明细完整、✅ 资金筹措方案可行\n\n### 第十阶段：特殊章节（根据方案类型增加）\n\n#### 10.1 详细功能设计方案（投标类方案必需）\n- 管理后台功能设计（用户管理、角色权限、系统配置、业务功能模块详细设计）\n- 运维平台功能设计（系统监控、日志管理、告警管理、性能监控、故障诊断）\n- 数据服务与分析功能设计（数据查询、统计分析、报表展示、数据挖掘、智能分析）\n- 功能清单输出（按照招标需求逐项响应）\n\n#### 10.2 项目实施与管理方案（投标类方案必需）\n- 项目组织架构设计（项目经理、技术负责人、开发团队、测试团队）\n- 关键人员简历（资质、经验、项目案例）\n- 实施方法论（敏捷开发、瀑布模型、混合模式）\n- 项目进度计划（甘特图、关键路径）\n- 质量管理方案（质量标准、测试方案、质量评审）\n- 风险管控（风险识别、风险评估、应对措施）\n- 变更管理（变更流程、变更评审、变更记录）\n\n#### 10.3 信息安全与合规方案（投标类、可研类方案必需）\n- 网络安全方案（防火墙、入侵检测、网络隔离）\n- 数据安全方案（数据加密、数据脱敏、数据备份）\n- 应用安全方案（身份认证、访问控制、安全审计）\n- 等保测评与合规（政府场景：等保三级测评、合规评估）\n- 安全管理制度与应急响应\n\n#### 10.4 运维服务与保障方案（投标类方案必需）\n- 运维服务模式（远程运维、驻场运维、混合模式）\n- 运维内容（系统巡检、故障处理、性能优化）\n- 服务级别协议（SLA）（响应时间、解决时间、可用性）\n- 运维团队与工具（运维人员、运维平台、监控系统）\n- 售后保障机制（服务热线、升级流程、投诉渠道）\n\n#### 10.5 培训方案（投标类方案必需）\n- 培训计划（培训对象、培训时间、培训周期）\n- 培训内容与教材（业务操作培训、技术培训、管理培训）\n- 培训方式（集中培训、在线培训、现场指导）\n- 培训考核与效果保障（考核方式、效果评估、持续支持）\n\n---\n\n## 可选分支详解\n\n- **快速原型场景**：政策背景分析 → 需求分析 → 快速架构（四维度简化）→ 技术选型 → 具体建设内容（简化）→ 原型实现\n- **企业级系统**：强调安全、合规、高可用性设计\n- **创新项目**：增加可行性验证阶段，采用实验性技术\n- **遗留系统迁移**：增加现状评估、迁移策略设计\n- **政府数字化转型场景**：增加合规评估、安全设计、政策适配、服务便民化设计，参考 `references/government-digitalization.md`\n\n## 使用示例\n\n### 示例 0：方案类型识别（强制流程）\n- **功能**：用户输入需求后，强制询问方案类型，待用户明确后再进行方案编写。\n- **执行方式**：智能体主导，第零阶段必执行。\n- **关键指导**：\n  - **强制要求**：用户输入需求后，**必须先询问**用户方案类型，不要通过关键词推导或猜测。\n  - 询问语：\"请问您需要产出哪种类型的方案？可选择：规划类、申报类、可研类、投标类、工作汇报类\"\n  - 若用户不清楚，参考本 README 中的方案类型说明。\n  - **等待用户明确反馈方案类型后**，再根据用户选择的方案类型进行解决方案内容的编写。\n  - 根据确认的方案类型选择对应的执行阶段和输出结构。\n\n### 示例 1：规划类方案 - 政务服务平台规划\n- **功能**：为某政府部门设计粗颗粒度的政务服务平台规划方案。\n- **执行方式**：智能体主导，执行规划类方案流程。\n- **关键指导**：\n  - 方案类型：规划类方案\n  - 执行阶段：第零阶段 → 第一阶段（政策背景分析）→ 第二阶段（需求分析，简化）→ 第三阶段（建设思路设计）→ 4.1（业务架构，简化）→ 第六阶段（具体建设内容，简化）→ 效益分析\n  - 输出重点：政策背景分析、现状问题、建设目标及思路、业务架构（简化）、关键建设内容、预期效益\n  - 内容特点：粗颗粒度、强调愿景和方向，不涉及详细设计和费用\n\n### 示例 2：申报类方案 - 企业数字化管理系统申报\n- **功能**：为企业设计数字化管理系统申报方案，用于内部立项申请。\n- **执行方式**：智能体主导，执行申报类方案流程。\n- **关键指导**：\n  - 方案类型：申报类方案\n  - 执行阶段：第零阶段 → 第一阶段 → 第二阶段 → 第三阶段 → 第四阶段（四维度架构）→ 第六阶段（主要建设内容）→ 第七阶段（实施规划，简化）→ 效益分析 → 费用估算\n  - 输出重点：建设背景、需求分析、建设目标、四维度架构、主要建设内容、实施计划（简化）、效益分析、费用估算\n  - 内容特点：较规划类更细化，包含费用估算，架构设计涵盖四维度\n\n### 示例 3：可研类方案 - 政府数字政府建设可研\n- **功能**：为政府数字政府建设项目设计可行性研究报告。\n- **执行方式**：智能体主导，执行可研类方案流程（全部阶段）。\n- **关键指导**：\n  - 方案类型：可研类方案\n  - 执行阶段：全部阶段（第零阶段至第八阶段）+ 投资估算（第九阶段）\n  - 输出重点：总论、背景与必要性、需求分析（细化）、总体建设方案、建设内容、技术方案与选型（详细）、实施计划、投资估算、效益分析、风险分析\n  - 需求分析需细化：业务、用户、功能、数据、性能、安全、运维\n  - 技术选型需详细：技术路线、关键技术、软硬件选型、集成方案、信创适配（政府场景）\n  - 内容特点：内容最全面、最细化，包含详细的投资估算和风险分析\n\n### 示例 4：投标类方案 - 政务云平台投标\n- **功能**：为政务云平台招标项目设计投标方案。\n- **执行方式**：智能体主导，执行投标类方案流程。\n- **关键指导**：\n  - 方案类型：投标类方案\n  - 执行阶段：第零阶段 → 第二阶段（项目需求理解与分析）→ 第三阶段（总体建设方案）→ 第四阶段（四维度架构）→ 10.1（详细功能设计）→ 10.2（项目实施与管理方案）→ 10.3（信息安全与合规方案）→ 10.4（运维服务与保障方案）→ 10.5（培训方案）→ 报价文件\n  - 输出重点：需求理解、总体建设方案、详细功能设计、实施与管理、安全与合规、运维服务、培训方案、报价文件\n  - 详细功能设计需按照招标需求逐项响应，并附上功能清单\n  - 内容特点：围绕招标需求响应，强调技术实力、实施能力、管理能力和价格竞争力\n\n### 示例 5：工作汇报类方案 - 项目阶段性汇报\n- **功能**：为项目执行过程设计阶段性工作汇报方案。\n- **执行方式**：智能体主导，执行工作汇报类方案特殊流程。\n- **关键指导**：\n  - 方案类型：工作汇报类方案\n  - 执行流程：特殊流程，不使用标准八阶段流程\n  - 输出结构：工作背景 → 需要解决的问题 → 当前正在开展的工作内容及完成情况 → 已经产生的工作成果及成效 → 当前工作开展中存在的问题 → 下一步工作计划 → 需要领导给予的支持\n  - 内容特点：简洁实用，重点突出工作进展、成果和需要支持的事项\n\n### 示例 6：生成架构图\n- **功能**：使用脚本生成各类架构图。\n- **执行方式**：调用 `scripts/generate-architecture-diagram.py` 脚本。\n- **关键指导**：\n  - 前置安装：`pip install graphviz`\n  - 创建 DOT 格式文件（参考 `references/architecture-dimensions.md` 中的模板）\n  - 生成业务架构图：`python scripts/generate-architecture-diagram.py --diagram-type business --input business.dot --output business.png`\n  - 生成功能架构图：`python scripts/generate-architecture-diagram.py --diagram-type functional --input functional.dot --output functional.png`\n  - 生成数据架构图：`python scripts/generate-architecture-diagram.py --diagram-type data --input data.dot --output data.png`\n  - 生成技术架构图：`python scripts/generate-architecture-diagram.py --diagram-type technical --input technical.dot --output technical.png`\n\n## 注意事项\n- **方案类型识别强制要求**：用户输入需求后，**必须先询问**用户方案类型，不要通过关键词推导或猜测，等待用户明确反馈后再进行方案编写。\n- **阶段迭代**：不需要线性完成所有阶段，根据方案类型选择需要的阶段执行。\n- **产出导向**：每个阶段都应产出明确文档或决策，避免过度设计。\n- **业务优先**：技术方案必须服务于业务目标，避免技术驱动。\n- **平衡原则**：在理想方案与实际约束之间找到平衡点。\n- **持续验证**：关键设计决策应通过原型、POC 或评审验证。\n- **政策合规**：政府场景需严格遵守政策法规要求，确保合规安全。\n- **四维度协同**：业务架构、功能架构、数据架构、技术架构需协同一致，相互支撑。\n- **现状驱动**：需求分析需深入行业现状和客户现状，必要时主动向用户获取现状信息或从互联网搜索同类客户共性现状。\n- **思路清晰**：建设思路设计需明确目标、原则、路径、分期，指导后续实施。\n- **架构图生成**：架构设计阶段应生成可视化架构图，使用 `scripts/generate-architecture-diagram.py` 脚本。\n  - 前置要求：安装 Python 依赖 `graphviz`（`pip install graphviz`）\n  - 输入格式：Graphviz DOT 格式（参考 `references/architecture-dimensions.md` 中的模板）\n  - 输出格式：PNG 或 SVG 格式的架构图\n  - 支持类型：业务架构图、功能架构图、数据架构图、技术架构图、流程图\n- **方案类型适配**：不同方案类型对应不同的输出结构和深度要求，参考 `references/solution-type-frames.md` 严格执行框架结构。\n\nFile v1.1.2:_meta.json\n\n{\n  \"ownerId\": \"kn7ae6m5fzwqs7fmdmh97gr1yh82m2py\",\n  \"slug\": \"digital-solution-designer\",\n  \"version\": \"1.1.2\",\n  \"publishedAt\": 1776657686990\n}\n\nFile v1.1.2:references/architecture-dimensions.md\n\n# 架构设计维度参考\n\n## 目录\n1. 业务架构设计\n2. 功能架构设计\n3. 数据架构设计\n4. 技术架构设计\n5. 四维度协同关系\n\n## 概览\n本文档提供业务架构、功能架构、数据架构、技术架构四个维度的设计指导，帮助系统化地进行多维度架构设计，确保各维度协同一致、相互支撑。\n\n## 核心内容\n\n### 1. 业务架构设计\n\n业务架构是系统的战略层面设计，描述业务目标、业务流程、业务能力和业务关系，是功能和数据架构设计的基础。\n\n#### 1.1 业务流程梳理\n\n**核心业务流程**：\n- 识别端到端的业务流程（从业务开始到结束）\n- 每个流程包括：触发条件、参与角色、执行步骤、输出结果\n- 示例：电商平台 - 订单流程（浏览 → 下单 → 支付 → 发货 → 确认收货）\n\n**支撑业务流程**：\n- 支撑核心流程的辅助流程\n- 示例：用户管理、商品管理、库存管理\n\n**管理业务流程**：\n- 运营管理流程\n- 示例：运营分析、数据统计、异常处理\n\n**跨部门协同流程**：\n- 涉及多个部门/系统的流程\n- 示例：政务审批、供应链协同\n\n#### 1.2 业务能力识别\n\n**业务能力分类**：\n- **核心能力**：直接支撑业务目标，创造价值\n- **支撑能力**：为核心能力提供支持\n- **管理能力**：管理和监控业务运行\n- **集成能力**：与外部系统交互\n\n**能力识别方法**：\n- 按业务领域划分（电商：商品、订单、支付、物流）\n- 按价值链划分（研发 → 生产 → 销售 → 服务）\n- 按用户角色划分（C端用户、B端用户、运营人员、管理员）\n\n**能力成熟度评估**：\n- 成熟度等级：初始级 → 已定义级 → 已管理级 → 优化级\n- 评估维度：流程标准化、数字化程度、自动化程度\n\n#### 1.3 业务关系设计\n\n**业务实体关系**：\n- 业务对象之间的关系（用户、订单、商品、支付）\n- 关系类型：一对一、一对多、多对多\n\n**业务协作关系**：\n- 业务部门之间的协作\n- 系统之间的协作\n- 角色之间的协作\n\n**数据流转关系**：\n- 数据在业务流程中的流转\n- 数据的采集、存储、处理、应用\n\n**服务提供与消费关系**：\n- 业务能力的提供方和消费方\n- 服务契约和接口\n\n#### 1.4 业务架构输出\n\n**输出文档内容**：\n- 业务架构图（文字描述）\n- 核心业务流程清单\n- 业务能力清单\n- 业务协作模式\n- 业务关系矩阵\n\n**质量检查**：\n- ✅ 业务流程覆盖全面\n- ✅ 业务能力边界清晰\n- ✅ 业务关系逻辑合理\n- ✅ 业务架构支撑业务目标\n\n#### 1.5 业务架构图模板\n\n**Graphviz DOT 格式示例**：\n\n```dot\ndigraph BusinessArchitecture {\n    rankdir=TB;\n    node [shape=box, style=filled, fillcolor=lightblue];\n    edge [fontsize=10];\n\n    // 核心业务领域\n    subgraph cluster_core {\n        label=\"核心业务\";\n        style=dashed;\n        商品管理 [label=\"商品管理\\n- 商品发布\\n- 库存管理\"];\n        订单管理 [label=\"订单管理\\n- 订单创建\\n- 订单处理\"];\n        支付管理 [label=\"支付管理\\n- 在线支付\\n- 退款处理\"];\n        物流管理 [label=\"物流管理\\n- 发货管理\\n- 物流跟踪\"];\n    }\n\n    // 支撑业务领域\n    subgraph cluster_support {\n        label=\"支撑业务\";\n        style=dashed;\n        用户管理 [label=\"用户管理\\n- 用户注册\\n- 权限管理\"];\n        会员管理 [label=\"会员管理\\n- 会员等级\\n- 积分管理\"];\n        营销管理 [label=\"营销管理\\n- 优惠券\\n- 促销活动\"];\n    }\n\n    // 业务流程\n    商品管理 -> 订单管理 [label=\"下单\"];\n    订单管理 -> 支付管理 [label=\"支付\"];\n    支付管理 -> 物流管理 [label=\"发货\"];\n    用户管理 -> 订单管理 [label=\"创建订单\"];\n    用户管理 -> 会员管理 [label=\"会员服务\"];\n    会员管理 -> 营销管理 [label=\"营销活动\"];\n    营销管理 -> 订单管理 [label=\"促销下单\"];\n}\n```\n\n**使用说明**：\n1. 将上述 DOT 格式保存为 `business.dot` 文件\n2. 调用脚本生成架构图：`python scripts/generate-architecture-diagram.py --diagram-type business --input business.dot --output business.png`\n3. 根据实际业务场景调整节点和边的定义\n\n---\n\n### 2. 功能架构设计\n\n功能架构是系统的功能层面设计，描述功能模块、功能层次和功能关系，将业务能力转化为可实现的功能。\n\n#### 2.1 功能模块划分\n\n**按业务领域划分**：\n- 核心业务功能（订单管理、支付管理）\n- 支撑业务功能（用户管理、权限管理）\n- 管理功能（系统管理、数据管理）\n\n**按用户角色划分**：\n- C 端用户功能（注册登录、浏览下单）\n- B 端用户功能（商品管理、订单处理）\n- 运营人员功能（数据分析、营销活动）\n- 管理员功能（系统配置、用户管理）\n\n**按系统层次划分**：\n- 接入层（Web、移动端、API）\n- 业务层（核心业务逻辑）\n- 数据层（数据访问、存储）\n- 基础设施层（监控、日志、配置）\n\n**按业务能力划分**：\n- 每个业务能力对应一组功能模块\n- 示例：订单能力 → 订单创建、订单查询、订单取消、订单统计\n\n#### 2.2 功能层次设计\n\n**核心功能层**：\n- 支撑业务关键流程的功能\n- 示例：商品浏览、下单支付、订单查询\n\n**支撑功能层**：\n- 数据管理（用户管理、商品管理、订单管理）\n- 用户管理（注册登录、身份认证、权限管理）\n- 通知服务（短信、邮件、推送）\n\n**增强功能层**：\n- 数据分析（报表、统计、可视化）\n- 智能推荐（个性化推荐、搜索优化）\n- 营销活动（优惠券、促销、积分）\n\n**集成功能层**：\n- 第三方集成（支付、物流、地图）\n- 系统集成（与现有系统对接）\n- 数据集成（数据导入导出）\n\n#### 2.3 功能关系设计\n\n**功能依赖关系**：\n- 功能之间的依赖（订单依赖用户和商品）\n- 先决条件（下单前需登录、购物车需先加商品）\n\n**功能调用关系**：\n- 模块间的调用关系\n- 同步调用 vs 异步调用\n\n**功能协作关系**：\n- 多个功能协作完成业务流程\n- 示例：下单 → 库存扣减 → 支付 → 发货 → 通知\n\n**功能复用关系**：\n- 公共功能模块（用户认证、权限控制）\n- 基础服务（文件上传、缓存服务）\n\n#### 2.4 功能架构输出\n\n**输出文档内容**：\n- 功能架构图（文字描述）\n- 功能模块清单\n- 功能层次划分\n- 功能关系矩阵\n\n**质量检查**：\n- ✅ 功能模块划分合理\n- ✅ 功能层次清晰\n- ✅ 功能关系明确\n- ✅ 功能架构支撑业务架构\n\n#### 2.5 功能架构图模板\n\n**Graphviz DOT 格式示例**：\n\n```dot\ndigraph FunctionalArchitecture {\n    rankdir=TB;\n    node [shape=box, style=filled];\n    edge [fontsize=10];\n\n    // 核心功能层\n    subgraph cluster_core {\n        label=\"核心功能层\";\n        style=dashed;\n        node [fillcolor=lightgreen];\n        商品浏览 [label=\"商品浏览\\n- 商品列表\\n- 商品详情\\n- 商品搜索\"];\n        下单支付 [label=\"下单支付\\n- 购物车\\n- 下单\\n- 支付\"];\n        订单查询 [label=\"订单查询\\n- 订单列表\\n- 订单详情\\n- 物流跟踪\"];\n    }\n\n    // 支撑功能层\n    subgraph cluster_support {\n        label=\"支撑功能层\";\n        style=dashed;\n        node [fillcolor=lightblue];\n        用户管理 [label=\"用户管理\\n- 注册登录\\n- 个人信息\\n- 地址管理\"];\n        权限管理 [label=\"权限管理\\n- 角色管理\\n- 权限控制\"];\n        通知服务 [label=\"通知服务\\n- 短信通知\\n- 邮件通知\\n- 消息推送\"];\n    }\n\n    // 增强功能层\n    subgraph cluster_enhance {\n        label=\"增强功能层\";\n        style=dashed;\n        node [fillcolor=lightyellow];\n        数据分析 [label=\"数据分析\\n- 报表统计\\n- 数据可视化\"];\n        智能推荐 [label=\"智能推荐\\n- 个性化推荐\\n- 商品推荐\"];\n        营销活动 [label=\"营销活动\\n- 优惠券\\n- 促销活动\"];\n    }\n\n    // 集成功能层\n    subgraph cluster_integration {\n        label=\"集成功能层\";\n        style=dashed;\n        node [fillcolor=lightgray];\n        第三方支付 [label=\"第三方支付\\n- 支付宝\\n- 微信支付\"];\n        物流集成 [label=\"物流集成\\n- 快递公司\\n- 物流查询\"];\n    }\n\n    // 功能层次关系\n    下单支付 -> 第三方支付 [label=\"调用\"];\n    下单支付 -> 物流集成 [label=\"调用\"];\n    用户管理 -> 下单支付 [label=\"支撑\"];\n    权限管理 -> 用户管理 [label=\"控制\"];\n    通知服务 -> 下单支付 [label=\"通知\"];\n    数据分析 -> 订单查询 [label=\"分析\"];\n    智能推荐 -> 商品浏览 [label=\"推荐\"];\n    营销活动 -> 商品浏览 [label=\"展示\"];\n}\n```\n\n---\n\n### 3. 数据架构设计\n\n数据架构是系统的数据层面设计，描述数据模型、数据流、数据标准和数据治理，确保数据的正确性、一致性、安全性和可用性。\n\n#### 3.1 数据模型设计\n\n**核心实体识别**：\n- 业务对象抽象（用户、商品、订单、支付）\n- 实体属性定义\n- 实体关系设计（一对一、一对多、多对多）\n\n**数据类型与约束**：\n- 数据类型选择（字符串、数字、日期、JSON）\n- 数据约束（非空、唯一、范围、格式）\n- 默认值设计\n\n**数据标准化**：\n- 命名规范（表名、字段名、索引名）\n- 编码规范（字典编码、状态码）\n- 格式规范（日期格式、金额格式、坐标格式）\n\n**数据模型层次**：\n- **概念模型**：业务层面的数据抽象\n- **逻辑模型**：系统层面的数据结构\n- **物理模型**：数据库层面的具体实现\n\n#### 3.2 数据流设计\n\n**业务数据流**：\n- 数据在业务流程中的流转\n- 示例：下单 → 订单数据 → 支付数据 → 物流数据 → 完成数据\n\n**系统数据流**：\n- 系统内部的数据流转\n- 示例：Web 层 → 业务层 → 数据层\n\n**跨系统数据流**：\n- 系统间的数据交换\n- 示例：电商平台 → 物流公司 → 用户\n\n**数据采集、存储、处理、应用**：\n- **数据采集**：用户输入、传感器、第三方数据\n- **数据存储**：关系型数据库、NoSQL、数据仓库\n- **数据处理**：ETL、清洗、计算、分析\n- **数据应用**：查询、报表、推荐、预测\n\n#### 3.3 数据标准设计\n\n**数据字典**：\n- 统一的数据术语定义\n- 数据元定义（名称、类型、长度、含义）\n- 数据域定义（数据值域、枚举值）\n\n**数据编码规则**：\n- 主键生成策略（UUID、雪花算法）\n- 业务编码规则（订单号、流水号）\n- 状态码设计（状态机、状态转换）\n\n**数据质量管理标准**：\n- 数据完整性（必填项、唯一性）\n- 数据准确性（数据校验、格式验证）\n- 数据一致性（数据同步、事务管理）\n- 数据及时性（实时、准实时、批处理）\n\n#### 3.4 数据治理设计\n\n**数据分类分级**：\n- **按敏感程度**：公开、受限、敏感、机密\n- **按重要程度**：核心数据、重要数据、一般数据\n- 分类分级标准与策略\n\n**数据安全与隐私保护**：\n- 数据脱敏（手机号、身份证、银行卡号）\n- 数据加密（传输加密、存储加密）\n- 访问控制（权限管理、角色控制）\n- 审计日志（数据访问、数据修改）\n\n**数据生命周期管理**：\n- 数据创建、使用、归档、销毁\n- 保留策略（热数据、温数据、冷数据）\n- 备份与恢复策略\n\n**数据共享与开放**：\n- 数据共享机制（API、ETL、数据交换）\n- 数据开放策略（公开数据、受限数据）\n- 数据使用授权（申请、审批、使用、审计）\n\n#### 3.5 数据架构输出\n\n**输出文档内容**：\n- 数据模型图（文字描述）\n- 数据流图（文字描述）\n- 数据标准规范\n- 数据治理方案\n\n**质量检查**：\n- ✅ 数据模型完整\n- ✅ 数据流清晰\n- ✅ 数据标准统一\n- ✅ 数据治理方案可行\n- ✅ 数据架构支撑功能架构\n\n#### 3.6 数据架构图模板\n\n**Graphviz DOT 格式示例（ER图）**：\n\n```dot\ndigraph DataArchitecture {\n    rankdir=LR;\n    node [shape=ellipse, style=filled, fillcolor=lightyellow];\n    edge [fontsize=10];\n\n    // 实体定义\n    用户 [label=\"用户\\n用户ID\\n用户名\\n密码\\n邮箱\\n手机号\"];\n    商品 [label=\"商品\\n商品ID\\n商品名称\\n价格\\n库存\"];\n    订单 [label=\"订单\\n订单ID\\n用户ID\\n商品ID\\n数量\\n金额\\n状态\"];\n    订单项 [label=\"订单项\\n订单项ID\\n订单ID\\n商品ID\\n数量\\n价格\"];\n    支付 [label=\"支付\\n支付ID\\n订单ID\\n金额\\n支付方式\\n支付状态\"];\n    物流 [label=\"物流\\n物流ID\\n订单ID\\n快递公司\\n运单号\\n物流状态\"];\n\n    // 实体关系\n    用户 -> 订单 [label=\"1:N\\n创建\"];\n    订单 -> 订单项 [label=\"1:N\\n包含\"];\n    商品 -> 订单项 [label=\"1:N\\n关联\"];\n    订单 -> 支付 [label=\"1:1\\n支付\"];\n    订单 -> 物流 [label=\"1:N\\n发货\"];\n\n    // 数据流\n    订单 [shape=box, fillcolor=lightblue, label=\"订单数据\\n- 订单创建\\n- 订单更新\\n- 订单完成\"];\n    支付 [shape=box, fillcolor=lightblue, label=\"支付数据\\n- 支付请求\\n- 支付回调\\n- 退款处理\"];\n    物流 [shape=box, fillcolor=lightblue, label=\"物流数据\\n- 发货通知\\n- 物流跟踪\\n- 签收确认\"];\n}\n```\n\n---\n\n### 4. 技术架构设计\n\n技术架构是系统的技术层面设计，描述部署架构、技术选型、安全架构和集成架构，确保系统的性能、可用性、安全性和可扩展性。\n\n#### 4.1 部署架构\n\n**部署拓扑**：\n- **单机部署**：简单场景、小型系统\n- **集群部署**：高可用、负载均衡\n- **分布式部署**：大规模、高并发\n- **云原生部署**：容器化、微服务、Serverless\n\n**分层架构**：\n- **接入层**：负载均衡、API 网关、CDN\n- **业务层**：应用服务、微服务\n- **数据层**：数据库、缓存、消息队列\n- **基础设施层**：服务器、存储、网络\n\n**容器化与编排**：\n- **容器化**：Docker 容器化应用\n- **编排**：Kubernetes 容器编排\n- **服务网格**：Istio 服务治理\n\n**高可用与容灾设计**：\n- **高可用**：多实例部署、故障自动转移\n- **负载均衡**：Nginx、HAProxy、云负载均衡\n- **容灾备份**：异地多活、灾备切换\n\n#### 4.2 安全架构\n\n**网络安全**：\n- **防火墙**：网络访问控制\n- **WAF**：Web 应用防火墙\n- **DDoS 防护**：分布式拒绝服务攻击防护\n- **VPN**：虚拟专用网络\n\n**应用安全**：\n- **认证授权**：身份认证、权限控制\n- **输入验证**：防止 SQL 注入、XSS 攻击\n- **加密**：传输加密（HTTPS）、数据加密\n- **会话管理**：会话安全、Token 管理\n\n**数据安全**：\n- **传输加密**：SSL/TLS 加密\n- **存储加密**：数据库加密、文件加密\n- **数据脱敏**：敏感数据脱敏\n- **备份加密**：备份数据加密\n\n**运维安全**：\n- **日志审计**：操作日志、访问日志\n- **入侵检测**：异常行为检测、入侵告警\n- **漏洞扫描**：安全漏洞扫描、修复\n- **应急响应**：安全事件应急响应\n\n#### 4.3 集成架构\n\n**API 网关设计**：\n- **统一入口**：API 统一入口\n- **认证授权**：统一认证、权限控制\n- **流量控制**：限流、熔断、降级\n- **协议转换**：HTTP、REST、gRPC\n\n**服务注册与发现**：\n- **注册中心**：服务注册、服务发现\n- **健康检查**：服务健康状态检查\n- **负载均衡**：服务实例负载均衡\n\n**消息队列与事件总线**：\n- **消息队列**：RabbitMQ、Kafka、RocketMQ\n- **事件总线**：事件发布订阅、事件溯源\n- **异步处理**：异步任务、异步通知\n\n**数据交换与同步**：\n- **ETL**：数据抽取、转换、加载\n- **CDC**：变更数据捕获\n- **数据同步**：主从复制、双向同步\n\n#### 4.4 技术架构输出\n\n**输出文档内容**：\n- 技术架构图（文字描述）\n- 部署架构设计\n- 安全架构设计\n- 集成架构设计\n\n**质量检查**：\n- ✅ 架构模式选择合理\n- ✅ 部署架构可行\n- ✅ 安全架构完善\n- ✅ 集成架构灵活\n- ✅ 技术架构支撑数据架构和功能架构\n\n#### 4.5 技术架构图模板\n\n**Graphviz DOT 格式示例（部署架构）**：\n\n```dot\ndigraph TechnicalArchitecture {\n    rankdir=TB;\n    node [shape=box, style=filled];\n    edge [fontsize=10];\n\n    // 接入层\n    subgraph cluster_access {\n        label=\"接入层\";\n        style=dashed;\n        node [fillcolor=lightgreen];\n        CDN [label=\"CDN\\n- 静态资源\\n- 边缘加速\"];\n        负载均衡 [label=\"负载均衡\\n- Nginx\\n- LVS\"];\n        API网关 [label=\"API网关\\n- 认证授权\\n- 流量控制\\n- 协议转换\"];\n    }\n\n    // 业务层\n    subgraph cluster_business {\n        label=\"业务层\";\n        style=dashed;\n        node [fillcolor=lightblue];\n        用户服务 [label=\"用户服务\\n- 用户注册\\n- 登录认证\"];\n        商品服务 [label=\"商品服务\\n- 商品管理\\n- 库存管理\"];\n        订单服务 [label=\"订单服务\\n- 订单创建\\n- 订单处理\"];\n        支付服务 [label=\"支付服务\\n- 支付处理\\n- 退款管理\"];\n    }\n\n    // 数据层\n    subgraph cluster_data {\n        label=\"数据层\";\n        style=dashed;\n        node [fillcolor=lightyellow];\n        MySQL [label=\"MySQL\\n- 关系型数据库\"];\n        Redis [label=\"Redis\\n- 缓存\\n- 会话\"];\n        MongoDB [label=\"MongoDB\\n- 文档数据库\"];\n    }\n\n    // 消息队列\n    subgraph cluster_mq {\n        label=\"消息队列\";\n        style=dashed;\n        node [fillcolor=lightgray];\n        Kafka [label=\"Kafka\\n- 异步消息\\n- 事件驱动\"];\n        RabbitMQ [label=\"RabbitMQ\\n- 消息队列\\n- 延迟队列\"];\n    }\n\n    // 接入层到业务层\n    负载均衡 -> API网关 [label=\"转发\"];\n    API网关 -> 用户服务 [label=\"路由\"];\n    API网关 -> 商品服务 [label=\"路由\"];\n    API网关 -> 订单服务 [label=\"路由\"];\n    API网关 -> 支付服务 [label=\"路由\"];\n\n    // 业务层到数据层\n    用户服务 -> MySQL [label=\"读写\"];\n    商品服务 -> MySQL [label=\"读写\"];\n    商品服务 -> Redis [label=\"缓存\"];\n    订单服务 -> MySQL [label=\"读写\"];\n    订单服务 -> Redis [label=\"缓存\"];\n    支付服务 -> MySQL [label=\"读写\"];\n\n    // 业务层到消息队列\n    订单服务 -> Kafka [label=\"异步\"];\n    支付服务 -> RabbitMQ [label=\"延迟\"];\n    商品服务 -> Kafka [label=\"事件\"];\n\n    // 消息队列到业务层\n    Kafka -> 物流服务 [label=\"消费\"];\n    RabbitMQ -> 订单服务 [label=\"消费\"];\n}\n```\n\n---\n\n### 5. 四维度协同关系\n\n#### 5.1 协同原则\n\n**业务架构是源头**：\n- 业务架构决定功能和数据架构\n- 业务目标和业务流程是设计的起点\n\n**功能架构是桥梁**：\n- 功能架构将业务能力转化为可执行的功能\n- 功能架构连接业务架构和技术架构\n\n**数据架构是基础**：\n- 数据架构支撑功能架构的实现\n- 数据架构是业务价值的载体\n\n**技术架构是支撑**：\n- 技术架构提供功能实现的技术基础\n- 技术架构确保系统的性能、安全、可用性\n\n#### 5.2 协同一致性检查\n\n**业务架构 ↔ 功能架构**：\n- ✅ 每个业务能力都有对应的功能模块\n- ✅ 业务流程都有对应的功能流程\n- ✅ 业务关系都有对应的功能关系\n\n**业务架构 ↔ 数据架构**：\n- ✅ 每个业务实体都有对应的数据实体\n- ✅ 业务流程都有对应的数据流\n- ✅ 业务关系都有对应的数据关系\n\n**功能架构 ↔ 数据架构**：\n- ✅ 每个功能都有对应的数据访问\n- ✅ 功能流程都有对应的数据操作\n- ✅ 功能关系都有对应的数据依赖\n\n**功能架构 ↔ 技术架构**：\n- ✅ 每个功能都有技术实现方案\n- ✅ 功能性能要求都有技术保障\n- ✅ 功能安全要求都有技术措施\n\n**数据架构 ↔ 技术架构**：\n- ✅ 数据模型有技术实现方案\n- ✅ 数据存储有技术选型\n- ✅ 数据安全有技术保障\n\n#### 5.3 协同设计流程\n\n1. **从业务架构开始**：\n   - 梳理业务目标、流程、能力、关系\n\n2. **功能架构承接**：\n   - 将业务能力转化为功能模块\n   - 设计功能层次和关系\n\n3. **数据架构支撑**：\n   - 设计数据模型支撑功能\n   - 设计数据流支撑业务流程\n\n4. **技术架构实现**：\n   - 选择技术栈实现功能\n   - 设计部署架构支撑数据\n\n5. **迭代优化**：\n   - 检查四维度协同一致性\n   - 优化架构设计\n\n#### 5.4 协同设计示例\n\n**示例：电商平台订单功能**\n\n- **业务架构**：订单能力 → 订单创建、订单查询、订单取消、订单支付\n- **功能架构**：订单管理模块 → 创建订单、查询订单、取消订单、支付订单\n- **数据架构**：订单实体（订单号、用户ID、商品ID、金额、状态）→ 订单数据流\n- **技术架构**：订单服务（微服务）→ MySQL（订单数据）→ Redis（订单缓存）→ 消息队列（订单通知）\n\n---\n\n## 架构设计质量检查清单\n\n### 业务架构\n- ✅ 业务流程覆盖全面\n- ✅ 业务能力边界清晰\n- ✅ 业务关系逻辑合理\n- ✅ 业务架构支撑业务目标\n\n### 功能架构\n- ✅ 功能模块划分合理\n- ✅ 功能层次清晰\n- ✅ 功能关系明确\n- ✅ 功能架构支撑业务架构\n\n### 数据架构\n- ✅ 数据模型完整\n- ✅ 数据流清晰\n- ✅ 数据标准统一\n- ✅ 数据治理方案可行\n- ✅ 数据架构支撑功能架构\n\n### 技术架构\n- ✅ 架构模式选择合理\n- ✅ 部署架构可行\n- ✅ 安全架构完善\n- ✅ 集成架构灵活\n- ✅ 技术架构支撑数据架构和功能架构\n\n### 四维度协同\n- ✅ 业务架构、功能架构、数据架构、技术架构协同一致\n- ✅ 架构设计满足需求\n- ✅ 架构设计符合建设思路\n- ✅ 架构设计可落地实施\n\nFile v1.1.2:references/architecture-patterns.md\n\n# 架构模式参考\n\n## 目录\n1. 单体架构\n2. 模块化单体\n3. 微服务架构\n4. 事件驱动架构\n5. 分层架构\n6. CQRS（命令查询职责分离）\n7. Serverless 架构\n8. 模式选择指南\n\n## 概览\n本文档提供常见的软件架构模式，包括其特点、适用场景和权衡考虑，用于指导架构设计决策。\n\n## 核心内容\n\n### 1. 单体架构（Monolithic）\n\n**特点**：\n- 整个应用作为单一部署单元\n- 共享数据库和代码库\n- 调用方式为内存函数调用\n\n**适用场景**：\n- 初创项目快速验证\n- 小型团队（< 10人）\n- 业务逻辑相对简单\n- 预期用户规模有限\n\n**优势**：\n- 开发简单，部署容易\n- 调试和测试方便\n- 无需复杂的服务间通信\n- 初期开发速度快\n\n**劣势**：\n- 扩展性受限（只能整体扩展）\n- 技术栈统一，灵活性低\n- 代码耦合度高，维护成本随规模增长\n- 故障影响范围大\n\n---\n\n### 2. 模块化单体（Modular Monolith）\n\n**特点**：\n- 仍是单一部署单元\n- 代码按模块组织，模块间通过明确接口交互\n- 强调内部边界和依赖管理\n\n**适用场景**：\n- 需要良好结构的中型项目\n- 团队规模 5-20人\n- 未来可能拆分为微服务的过渡阶段\n\n**优势**：\n- 保持单体部署的简单性\n- 代码组织清晰，降低耦合\n- 为未来微服务化做准备\n- 比传统单体更易维护\n\n**劣势**：\n- 仍受限于整体部署\n- 模块边界管理需要良好纪律\n- 跨模块变更仍需整体测试\n\n---\n\n### 3. 微服务架构（Microservices）\n\n**特点**：\n- 系统拆分为多个独立服务\n- 每个服务独立部署和扩展\n- 服务间通过 API（HTTP/RPC/gRPC）通信\n- 数据库通常独立（每个服务自己的数据库）\n\n**适用场景**：\n- 大型复杂系统\n- 多团队协作开发\n- 需要独立扩展不同模块\n- 业务领域边界清晰\n\n**优势**：\n- 独立部署和扩展\n- 技术栈灵活\n- 故障隔离\n- 团队自治\n\n**劣势**：\n- 分布式系统复杂度高\n- 服务间通信开销\n- 数据一致性挑战\n- 运维和监控复杂\n- 初期开发成本高\n\n**关键实践**：\n- 领域驱动设计（DDD）划分边界\n- API 网关统一入口\n- 服务注册与发现\n- 分布式追踪\n- 容错机制（熔断、降级）\n\n---\n\n### 4. 事件驱动架构（Event-Driven）\n\n**特点**：\n- 通过事件驱动业务流程\n- 松耦合的组件通过事件总线通信\n- 支持异步处理和实时响应\n\n**适用场景**：\n- 需要高实时性的系统\n- 多系统集成场景\n- 复杂业务流程编排\n- 需要高扩展性的异步任务\n\n**优势**：\n- 松耦合，易扩展\n- 异步处理提高吞吐量\n- 天然支持审计和溯源\n- 易于集成外部系统\n\n**劣势**：\n- 流程追踪困难\n- 事件Schema 管理复杂\n- 错误处理和重试机制复杂\n- 最终一致性的挑战\n\n**关键组件**：\n- 事件总线（消息队列：Kafka、RabbitMQ）\n- 事件存储\n- 事件溯源（Event Sourcing）\n- CQRS（命令查询分离）\n\n---\n\n### 5. 分层架构（Layered）\n\n**特点**：\n- 按职责分为不同层次\n- 常见分层：表现层 → 业务层 → 持久层 → 数据库\n- 严格依赖方向（上层依赖下层，下层不依赖上层）\n\n**适用场景**：\n- 几乎所有传统企业应用\n- 需要清晰职责分离的系统\n- 团队熟悉传统开发模式\n\n**优势**：\n- 结构清晰，易于理解\n- 职责分离，便于测试\n- 开发模式成熟\n- 易于维护\n\n**劣势**：\n- 可能过度设计\n- 层次间调用可能带来性能损耗\n- 不适合所有场景（如纯 API 服务）\n\n---\n\n### 6. CQRS（命令查询职责分离）\n\n**特点**：\n- 读写操作分离\n- 写操作（命令）使用领域模型\n- 读操作（查询）使用优化的数据模型\n- 可能使用不同的存储（写用关系数据库，读用 NoSQL）\n\n**适用场景**：\n- 读写差异大的系统（读多写少）\n- 复杂业务逻辑的写操作\n- 需要高性能的复杂查询\n- 事件驱动架构的读模型\n\n**优势**：\n- 读写性能独立优化\n- 复杂业务逻辑不影响查询性能\n- 易于扩展读端\n- 与事件溯源结合良好\n\n**劣势**：\n- 增加系统复杂度\n- 数据同步问题（最终一致性）\n- 不适合所有场景（读写简单的系统）\n\n---\n\n### 7. Serverless 架构\n\n**特点**：\n- 无需管理服务器\n- 函数即服务（FaaS）\n- 按执行时间和资源付费\n- 自动弹性伸缩\n\n**适用场景**：\n- 波动性大的工作负载\n- 事件驱动的短任务\n- 快速原型和实验项目\n- 无状态的服务\n\n**优势**：\n- 无需运维服务器\n- 自动弹性伸缩\n- 按量付费，成本灵活\n- 快速部署\n\n**劣势**：\n- 冷启动延迟\n- 厂商锁定风险\n- 调试和监控困难\n- 不适合长时间运行的任务\n- 状态管理复杂\n\n---\n\n## 模式选择指南\n\n### 决策树\n\n```\n系统规模？\n├─ 小型（< 5万用户，< 10人团队）\n│  └─ → 单体架构 或 模块化单体\n├─ 中型（5-50万用户，10-30人团队）\n│  ├─ 业务复杂度低？\n│  │  └─ → 模块化单体\n│  └─ 业务复杂度高？\n│     └─ → 考虑早期微服务（从 2-3 个核心服务开始）\n└─ 大型（> 50万用户，> 30人团队）\n   ├─ 领域边界清晰？\n   │  └─ → 微服务架构\n   └─ 领域耦合紧密？\n      └─ → 模块化单体 + 按需演进\n\n需要高实时性和异步处理？\n└─ 是 → 事件驱动架构（可与其他架构组合）\n\n读写操作差异大？\n└─ 是 → 考虑 CQRS\n\n运维资源有限？\n└─ 是 → 单体 或 Serverless\n```\n\n### 权衡考虑\n\n**复杂度 vs 收益**：\n- 微服务带来复杂度，只在需要时采用\n- 单体架构简单但扩展性受限\n- 避免为了微服务而微服务\n\n**团队能力**：\n- 微服务需要成熟的 DevOps 能力\n- 新团队从单体开始，逐步演进\n- 技术选型考虑团队熟悉度\n\n**业务需求**：\n- 业务快速变化？→ 模块化单体或微服务\n- 需要独立扩展？→ 微服务\n- 高实时性？→ 事件驱动\n- 成本敏感？→ Serverless\n\n**演进策略**：\n- 从单体开始\n- 随着需求增长拆分\n- 按领域边界拆分微服务\n- 避免\"大爆炸\"重构\n\n## 示例\n\n### 示例 1：电商平台\n- **推荐架构**：微服务 + 事件驱动\n- **原因**：业务复杂度高，需要独立扩展，多团队协作\n- **核心服务**：用户服务、商品服务、订单服务、支付服务、库存服务\n- **事件流**：下单 → 库存扣减 → 支付 → 物流 → 通知\n\n### 示例 2：内容管理系统（CMS）\n- **推荐架构**：模块化单体\n- **原因**：业务相对简单，中型团队，未来可能需要扩展\n- **模块划分**：内容管理、用户管理、评论、搜索\n\n### 示例 3：IoT 数据处理平台\n- **推荐架构**：事件驱动 + CQRS\n- **原因**：高实时性，写密集，读查询复杂\n- **设计**：设备数据写入事件流，读端使用时序数据库优化查询\n\n### 示例 4：内部管理后台\n- **推荐架构**：分层单体\n- **原因**：传统企业应用，用户量有限，团队熟悉\n- **分层**：Web 层 → Service 层 → DAO 层 → 数据库\n\nFile v1.1.2:references/government-digitalization.md\n\n# 政府数字化转型参考\n\n## 目录\n1. 政府数字化转型特点\n2. 合规安全要求\n3. 政务架构模式\n4. 信创适配方案\n5. 服务便民化设计\n6. 典型场景示例\n\n## 概览\n本文档提供政府数字化转型的特殊要求、架构模式、合规安全标准和服务便民化设计原则，用于指导政府数字化场景的方案设计。\n\n## 核心内容\n\n### 1. 政府数字化转型特点\n\n#### 核心目标\n- **服务便民化**：让数据多跑路，群众少跑腿\n- **治理现代化**：提升政府治理能力和效率\n- **决策科学化**：基于数据驱动决策\n- **协同高效化**：打破部门壁垒，实现跨部门协同\n\n#### 主要挑战\n- **安全合规要求高**：涉及国家安全、公民隐私\n- **流程审批复杂**：多层级决策、政策约束\n- **系统异构性**：现有系统多样、技术栈老旧\n- **数据孤岛**：部门间数据不共享、标准不统一\n- **用户群体广泛**：涵盖各年龄段、文化背景\n- **政策法规约束**：需符合国家法律法规和政策要求\n\n#### 基本原则\n- **安全第一**：安全合规是红线，不可妥协\n- **服务导向**：以群众和企业需求为中心\n- **统一标准**：遵循国家和行业标准\n- **数据共享**：在确保安全前提下推进数据共享\n- **渐进演进**：在现有基础上稳步推进，避免大爆炸式改造\n\n---\n\n### 2. 合规安全要求\n\n#### 等保分级要求（网络安全等级保护）\n\n| 等级 | 适用场景 | 关键要求 |\n|------|----------|----------|\n| 等保二级 | 一般政务系统 | 基本安全防护，定期安全评估 |\n| 等保三级 | 重要政务系统 | 强化安全防护，年度等级测评，安全审计 |\n| 等保四级 | 核心关键系统 | 最高等级防护，实时监控，应急响应 |\n\n**关键控制措施**：\n- 身份鉴别（多因素认证）\n- 访问控制（最小权限原则）\n- 安全审计（全程日志记录）\n- 数据加密（传输加密、存储加密）\n- 入侵防范（防火墙、入侵检测）\n- 恶意代码防范（防病毒、漏洞扫描）\n\n#### 数据安全相关法规\n\n**《数据安全法》**\n- 建立数据分类分级制度\n- 重要数据出境安全评估\n- 数据安全风险评估\n- 数据安全应急处置\n\n**《个人信息保护法》**\n- 告知同意原则（明示告知、单独同意）\n- 最小必要原则（仅收集必要信息）\n- 敏感个人信息加强保护\n- 个人信息跨境提供合规\n\n**《网络安全法》**\n- 网络运营者安全义务\n- 关键信息基础设施保护\n- 网络安全等级保护制度\n\n#### 政务数据分类分级\n\n**按敏感程度分类**：\n- **公开数据**：可对外公开（如政策文件、统计数据）\n- **受限数据**：特定范围可访问（如内部公文）\n- **敏感数据**：严格限制访问（如个人隐私、商业秘密）\n- **机密数据**：最高级别保护（如国家秘密）\n\n**按重要性分级**：\n- **核心数据**：关系国家安全、经济运行、公共利益\n- **重要数据**：关系重要部门、重点领域\n- **一般数据**：其他政务数据\n\n#### 安全合规评估清单\n\n- [ ] 等保测评报告（对应等级）\n- [ ] 数据安全风险评估报告\n- [ ] 个人信息保护影响评估（如涉及）\n- [ ] 第三方安全审计报告\n- [ ] 安全事件应急预案\n- [ ] 数据出境安全评估（如涉及）\n- [ ] 关键信息基础设施认定（如适用）\n\n---\n\n### 3. 政务架构模式\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│  多租户隔离：部门 A | 部门 B | ...    │\n└─────────────────────────────────────┘\n              ↓\n┌─────────────────────────────────────┐\n│     数据服务层                        │\n│  (数据共享交换、数据治理、数据仓库)    │\n└─────────────────────────────────────┘\n              ↓\n┌─────────────────────────────────────┐\n│     基础设施层                        │\n│  (计算、存储、网络、安全组件)          │\n└─────────────────────────────────────┘\n```\n\n#### 数据共享架构\n\n**数据交换模式**：\n- **实时数据交换**：通过 API 实时调用\n- **批量数据交换**：定时批量同步（ETL）\n- **消息队列交换**：异步事件驱动\n\n**数据共享平台**：\n- 统一数据目录：元数据管理\n- 数据交换总线：ETL 工具、消息队列\n- 数据质量管理：数据校验、清洗\n- 数据血缘追踪：数据来源、流向记录\n\n**数据安全控制**：\n- 访问权限控制（谁可访问什么数据）\n- 使用场景控制（什么场景可用）\n- 用量监控（防止滥用）\n- 留痕审计（谁在何时访问了什么数据）\n\n#### 跨部门协同架构\n\n**协同模式**：\n- **流程协同**：跨部门业务流程串联\n- **数据协同**：跨部门数据共享交换\n- **服务协同**：统一服务入口，后台多部门协同处理\n\n**典型场景**：\n- 企业开办：市场监管 → 税务 → 公安 → 人社\n- 不动产登记：自然资源 → 税务 → 公安 → 民政\n- 项目审批：发改委 → 自然资源 → 生态环境 → 建设部门\n\n---\n\n### 4. 信创适配方案\n\n#### 信创技术栈\n\n**国产化替代方向**：\n\n| 技术类别 | 传统技术栈 | 信创替代方案 |\n|----------|------------|--------------|\n| 芯片 | Intel/AMD | 龙芯、飞腾、海光、鲲鹏 |\n| 操作系统 | Windows、CentOS | 统信 UOS、麒麟、欧拉 |\n| 数据库 | Oracle、SQL Server、MySQL | 人大金仓、达梦、TiDB、openGauss |\n| 中间件 | WebLogic、JBoss、Tomcat | 东方通、普元、宝兰德 |\n| 应用服务器 | IIS、Apache | 东方通、普元 |\n| 办公软件 | Office、Photoshop | 永中、WPS |\n\n#### 信创适配策略\n\n**渐进式替换**：\n- 优先替换外围系统\n- 核心系统先做适配验证\n- 新建系统直接采用信创技术栈\n- 建立信创兼容性测试环境\n\n**双轨并行**：\n- 传统系统与信创系统并行运行\n- 数据双写、双读\n- 逐步切换流量\n\n**关键适配工作**：\n- 兼容性测试（功能、性能、稳定性）\n- 中间件适配（消息队列、缓存、搜索）\n- 数据库迁移（数据迁移、应用改造）\n- 硬件适配（CPU、存储、网络）\n\n#### 信创适配评估\n\n**评估维度**：\n- 技术成熟度（是否稳定可靠）\n- 生态完整性（是否有完整技术栈）\n- 性能表现（是否满足性能要求）\n- 成本（采购成本、迁移成本）\n- 团队能力（是否掌握相关技术）\n\n**适配决策**：\n- 高敏感、高优先级系统：必须适配信创\n- 一般政务系统：优先考虑信创，可保留传统技术栈\n- 对外公共服务系统：需考虑用户体验和兼容性\n\n---\n\n### 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- 办事流程不清晰，不知道怎么办\n- 办理时间长，不知道进度\n- 多头找，不知道找谁\n\n**便民化改进**：\n- **材料一次提交**：通过数据共享，避免重复提交\n- **流程一网通办**：线上申报、线上审批、线上办结\n- **进度全程可查**：短信、APP、微信推送进度\n- **咨询一口受理**：统一客服、统一咨询渠道\n\n#### 多渠道服务\n\n**线上渠道**：\n- 政务服务门户（PC 端）\n- 移动 APP、小程序\n- 自助服务终端\n\n**线下渠道**：\n- 政务服务大厅（综合窗口）\n- 社区服务站\n- 银行网点代办点\n\n**跨渠道协同**：\n- 线上预约，线下办理\n- 线下申报，线上查询\n- 多渠道信息同步\n\n#### 用户体验设计\n\n**面向不同群体**：\n- **年轻人**：强调效率、便捷、个性化\n- **老年人**：强调简单、易用、人工辅助\n- **企业**：强调效率、集成、批量处理\n\n**无障碍设计**：\n- 支持屏幕阅读器\n- 语音播报、语音输入\n- 大字体、高对比度\n- 键盘操作支持\n\n---\n\n### 6. 典型场景示例\n\n### 示例 1：政务服务\"一网通办\"平台\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- 数据安全风险评估\n- 电子签名、电子印章\n\n**便民化设计**：\n- 一次登录，全网通办\n- 材料一次提交，多部门共享\n- 全程网办，快递送达\n- 办事进度实时推送\n\n---\n\n### 示例 2：城市大脑（城市治理平台）\n\n**业务目标**：\n- 提升城市治理能力\n- 实时感知城市运行状态\n- 智能决策支持\n- 跨部门协同指挥\n\n**关键功能**：\n- 城市运行监控（交通、环境、治安、应急）\n- 数据可视化（城市数字孪生）\n- 智能预警（异常检测、风险预测）\n- 应急指挥（联动调度、应急响应）\n\n**技术架构**：\n- 大数据平台（数据采集、存储、计算）\n- AI 平台（算法模型、智能分析）\n- 物联网平台（设备接入、数据采集）\n- GIS 平台（地理信息、空间分析）\n- 指挥调度平台（统一指挥、联动调度）\n\n**数据来源**：\n- 城市摄像头（视频监控）\n- 交通传感器（车流量、路况）\n- 环境监测站（空气质量、水质）\n- 应急呼叫（110、119、120）\n- 城市物联网设备（井盖、路灯、管网）\n\n**安全合规**：\n- 等保三级或四级（视系统重要性）\n- 数据脱敏（个人隐私保护）\n- 实时监控与入侵检测\n- 应急响应机制\n\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- 企业开办\"一网通办\"\n- 证照\"多证合一\"\n- 政策精准推送\n- 诉求快速响应\n\n---\n\n### 示例 4：数据共享交换平台\n\n**业务目标**：\n- 打破数据孤岛\n- 实现跨部门数据共享\n- 支持业务协同\n\n**关键功能**：\n- 数据目录管理（元数据编目）\n- 数据申请审批（数据使用申请、审批）\n- 数据交换服务（API、批量交换）\n- 数据质量管理（数据校验、清洗）\n- 数据安全控制（访问控制、使用审计）\n- 数据血缘追踪（数据来源、流向）\n\n**技术架构**：\n- ETL 工具（数据抽取、转换、加载）\n- 消息队列（实时数据交换）\n- API 网关（数据 API 管理）\n- 数据治理平台（数据质量管理）\n- 数据安全网关（访问控制、脱敏）\n\n**安全合规**：\n- 等保三级\n- 数据安全风险评估\n- 访问权限控制\n- 操作留痕审计\n- 数据脱敏（敏感数据保护）\n\n**数据共享模式**：\n- 实时数据查询（API 调用）\n- 批量数据同步（ETL）\n- 数据订阅（消息队列）\n\n---\n\n## 实施建议\n\n### 合规先行\n- 在方案设计初期明确合规要求\n- 提前准备合规认证材料\n- 与等保测评机构、安全审计机构保持沟通\n\n### 渐进演进\n- 避免大爆炸式改造\n- 试点先行，验证后推广\n- 新建系统直接采用信创技术栈\n\n### 数据治理\n- 建立统一的数据标准和规范\n- 推进数据共享交换\n- 加强数据质量管理\n\n### 用户体验\n- 以群众和企业需求为中心\n- 多渠道服务\n- 持续优化办事流程\n\nFile v1.1.2:references/implementation-phases.md\n\n# 实施阶段参考\n\n## 目录\n1. 阶段规划原则\n2. MVP 阶段\n3. 功能扩展阶段\n4. 优化完善阶段\n5. 关键里程碑定义\n6. 实施规划模板\n7. 八阶段流程与实施阶段映射\n\n## 概览\n本文档提供数字化解决方案的实施阶段划分和规划指导，帮助制定合理的上线节奏和交付计划。同时提供八阶段流程（政策背景分析 → 需求分析 → 建设思路设计 → 架构设计 → 技术选型 → 具体建设内容 → 实施规划 → 风险评估）与实施阶段（MVP → 功能扩展 → 优化完善）的映射关系。\n\n## 核心内容\n\n### 1. 阶段规划原则\n\n#### 渐进式交付\n- **价值优先**：优先交付高价值功能\n- **快速验证**：尽早获得用户反馈\n- **风险控制**：避免一次性投入过大\n- **迭代改进**：基于反馈持续优化\n\n#### 阶段划分依据\n- **业务价值**：功能对业务目标的贡献度\n- **技术依赖**：基础功能优先于依赖功能\n- **用户反馈**：早期验证核心假设\n- **资源可用性**：团队规模和技能匹配\n- **政策合规**：政府场景需满足合规要求\n\n#### 阶段数量建议\n- **小型项目**：2-3 阶段（MVP → 完善）\n- **中型项目**：3-4 阶段（MVP → 扩展 → 优化）\n- **大型项目**：4+ 阶段（MVP → 扩展 → 优化 → 规模化）\n- **政府项目**：3-5 阶段（试点 → 推广 → 完善 → 扩展）\n\n---\n\n### 2. MVP 阶段（最小可行产品）\n\n#### 阶段目标\n- 验证核心业务假设\n- 获得早期用户反馈\n- 建立基础技术架构\n- 快速上线（通常 4-12 周）\n\n#### 功能范围\n- **核心功能**：解决用户最主要痛点的功能\n- **数据模型**：支撑核心功能的最小数据结构\n- **用户流程**：端到端的关键路径\n- **基础功能**：必要的认证、日志、监控\n\n#### 典型范围示例\n\n**电商平台 MVP**\n- 用户注册/登录\n- 商品浏览\n- 购物车\n- 下单支付\n- 基础订单管理\n- ❌ 不包含：推荐、优惠券、评价、会员系统\n\n**内容平台 MVP**\n- 内容发布\n- 内容浏览\n- 基础搜索\n- 用户互动（点赞/评论）\n- ❌ 不包含：个性化推荐、内容审核、社交功能\n\n**管理系统 MVP**\n- 核心业务模块（如订单管理）\n- 基础数据查询\n- 简单报表\n- ❌ 不包含：高级分析、权限细粒度控制、审批流程\n\n#### 技术重点\n- **架构稳定**：选择适合长期发展的架构模式\n- **技术栈确定**：确定主要技术选型\n- **基础建设**：CI/CD、监控、日志\n- **数据模型**：避免后期大改\n\n#### 交付标准\n- ✅ 核心功能可用\n- ✅ 无阻塞性 bug\n- ✅ 基础监控就绪\n- ✅ 部署流程自动化\n- ✅ 文档齐全（用户手册、运维手册）\n\n---\n\n### 3. 功能扩展阶段\n\n#### 阶段目标\n- 基于反馈完善功能\n- 扩大用户覆盖范围\n- 提升系统完整性\n- 通常持续 8-16 周\n\n#### 功能范围\n- **次要功能**：提升体验但不影响核心流程的功能\n- **数据完善**：补充数据字段和关联\n- **流程优化**：简化操作步骤、提升效率\n- **集成扩展**：与第三方系统集成\n\n#### 典型范围示例\n\n**电商平台扩展**\n- 商品评价\n- 收藏夹\n- 优惠券\n- 物流查询\n- 客服系统\n\n**内容平台扩展**\n- 用户关注\n- 内容分享\n- 评论互动\n- 话题标签\n- 内容分类\n\n**管理系统扩展**\n- 多模块管理\n- 高级搜索\n- 数据导出\n- 简单审批\n\n#### 技术重点\n- **性能优化**：缓存、数据库优化\n- **功能模块化**：提高代码可维护性\n- **监控完善**：业务指标监控\n- **自动化测试**：提升测试覆盖率\n\n#### 交付标准\n- ✅ 计划功能全部交付\n- ✅ 性能指标达标\n- ✅ 测试覆盖率 > 60%\n- ✅ 用户反馈响应及时\n- ✅ 无 P0/P1 级 bug\n\n---\n\n### 4. 优化完善阶段\n\n#### 阶段目标\n- 提升系统稳定性和性能\n- 增强用户体验\n- 支持更大规模用户\n- 持续迭代（通常 12+ 周）\n\n#### 功能范围\n- **高级功能**：增值服务、个性化功能\n- **智能特性**：推荐、自动化、AI 能力\n- **用户体验**：UI/UX 优化、交互改进\n- **性能扩展**：支持更大并发、更快响应\n\n#### 典型范围示例\n\n**电商平台优化**\n- 个性化推荐\n- 智能客服\n- 会员体系\n- 大促活动支持\n- 移动端优化\n\n**内容平台优化**\n- 个性化内容流\n- 内容推荐算法\n- 精准搜索\n- 社交关系链\n\n**管理系统优化**\n- 权限细粒度控制\n- 高级数据分析\n- 自动化工作流\n- 移动端支持\n\n#### 技术重点\n- **性能极致优化**：CDN、数据库分片、缓存策略\n- **可观测性**：全链路追踪、智能告警\n- **自动化**：自动化测试、自动化运维\n- **安全加固**：安全审计、漏洞修复\n\n#### 交付标准\n- ✅ 关键性能指标达到目标\n- ✅ 系统可用性 > 99.9%\n- ✅ 测试覆盖率 > 80%\n- ✅ 安全漏洞修复\n- ✅ 用户满意度达到目标\n\n---\n\n### 5. 关键里程碑定义\n\n#### MVP 发布里程碑\n\n**时间点**：开发启动后 4-12 周\n\n**验收标准**：\n- [ ] 核心功能完整可用\n- [ ] 端到端用户流程验证通过\n- [ ] 性能测试通过（响应时间 < 2s）\n- [ ] 安全扫描无高危漏洞\n- [ ] 部署流程文档化\n- [ ] 监控告警配置完成\n- [ ] 灰度发布方案准备就绪\n\n**风险提示**：\n- 核心假设未验证\n- 技术架构存在致命缺陷\n- 用户反馈不符合预期\n\n---\n\n#### 功能完整版里程碑\n\n**时间点**：MVP 后 8-16 周\n\n**验收标准**：\n- [ ] 计划功能全部交付\n- [ ] 用户测试通过\n- [ ] 性能达到目标（并发、响应时间）\n- [ ] 测试覆盖率 > 60%\n- [ ] P0/P1 bug 全部修复\n- [ ] 运维文档齐全\n- [ ] 备份恢复机制验证\n\n**风险提示**：\n- 功能蔓延，范围失控\n- 技术债务积累\n- 性能瓶颈未解决\n\n---\n\n#### 生产就绪版里程碑\n\n**时间点**：功能完整版后 12+ 周\n\n**验收标准**：\n- [ ] 系统可用性 > 99.9%\n- [ ] 压力测试通过\n- [ ] 灾备方案验证\n- [ ] 安全审计通过\n- [ ] 全链路监控就绪\n- [ ] 运维自动化完成\n- [ ] 团队培训完成\n\n**风险提示**：\n- 大规模流量冲击\n- 数据安全事件\n- 第三方依赖故障\n\n---\n\n### 6. 实施规划模板\n\n#### 模板结构\n\n```markdown\n# 项目实施计划\n\n## 项目概述\n- 项目名称\n- 项目目标\n- 预期成果\n\n## 阶段划分\n\n### 第一阶段：MVP（4-12 周）\n**目标**：\n- 验证核心假设\n- 快速上线获取反馈\n\n**功能范围**：\n- 功能 1：[描述]\n- 功能 2：[描述]\n- ...\n\n**里程碑**：\n- Week 2：原型设计完成\n- Week 4：核心功能开发完成\n- Week 6：内测上线\n- Week 8：灰度发布\n- Week 10：正式发布\n\n**资源需求**：\n- 开发：X 人\n- 测试：X 人\n- 产品：X 人\n\n**风险与应对**：\n- 风险 1：[描述] → [应对措施]\n- 风险 2：[描述] → [应对措施]\n\n### 第二阶段：功能扩展（8-16 周）\n...\n\n### 第三阶段：优化完善（12+ 周）\n...\n\n## 关键里程碑\n\n| 里程碑 | 时间 | 验收标准 |\n|--------|------|----------|\n| MVP 发布 | Week 10 | 见 MVP 阶段验收标准 |\n| 功能完整版 | Week 24 | 见功能完整版验收标准 |\n| 生产就绪版 | Week 36 | 见生产就绪版验收标准 |\n\n## 资源规划\n\n### 团队结构\n- 项目经理：1 人\n- 产品经理：1 人\n- 前端开发：X 人\n- 后端开发：X 人\n- 测试工程师：X 人\n- 运维工程师：X 人\n\n### 关键资源\n- 开发环境：云服务器、数据库\n- 第三方服务：支付、短信、推送\n- 工具：项目管理、CI/CD、监控\n\n## 风险管理\n\n| 风险类型 | 风险描述 | 可能性 | 影响 | 应对措施 | 责任人 |\n|----------|----------|--------|------|----------|--------|\n| 技术风险 | ... | 高/中/低 | 高/中/低 | ... | ... |\n| 业务风险 | ... | ... | ... | ... | ... |\n| 资源风险 | ... | ... | ... | ... | ... |\n\n## 沟通机制\n- 每日站会\n- 周例会\n- 阶段评审\n- 干系人汇报\n\n## 交付物清单\n- 需求文档\n- 架构设计文档\n- 接口文档\n- 测试报告\n- 运维手册\n- 用户手册\n```\n\n---\n\n## 示例\n\n### 示例 1：SaaS 平台实施计划\n\n**第一阶段：MVP（8 周）**\n- 核心功能：用户管理、基础业务模块、数据导入导出\n- 技术重点：基础架构、CI/CD、监控\n- 交付标准：100 个种子用户试用\n\n**第二阶段：扩展（12 周）**\n- 新增：高级分析、API 集成、多租户支持\n- 技术重点：性能优化、自动化测试\n- 交付标准：500 个付费用户\n\n**第三阶段：优化（16 周）**\n- 新增：AI 辅助、移动端、白标定制\n- 技术重点：高可用、智能推荐\n- 交付标准：2000 个付费用户，可用性 99.9%\n\n### 示例 2：企业内部系统\n\n**第一阶段：MVP（6 周）**\n- 核心模块：订单管理、库存查询\n- 交付标准：核心业务线上化\n\n**第二阶段：扩展（10 周）**\n- 新增：采购管理、报表分析、审批流程\n- 交付标准：覆盖 80% 业务场景\n\n**第三阶段：优化（持续）**\n- 新增：移动端审批、数据大屏、集成 ERP\n- 交付标准：全面数字化转型\n\n### 示例 3：移动 App\n\n**第一阶段：MVP（10 周）**\n- 核心功能：用户体系、核心业务流程、基础设置\n- 平台：先 iOS 或 Android（单平台）\n- 交付标准：1000 次下载，4 星以上评分\n\n**第二阶段：扩展（14 周）**\n- 新增：社交功能、推送通知、优惠活动\n- 平台：双平台支持\n- 交付标准：10000 次下载\n\n**第三阶段：优化（持续）**\n- 新增：AI 功能、AR/VR 特性\n- 交付标准：50000 次下载\n\n---\n\n### 示例 4：政务服务\"一网通办\"\n\n**第一阶段：试点（12 周）**\n- 核心功能：统一认证、一窗受理、协同审批\n- 试点范围：2-3 个部门\n- 交付标准：试点部门服务线上化\n\n**第二阶段：推广（16 周）**\n- 新增：数据共享、便民服务、移动端\n- 推广范围：所有部门\n- 交付标准：全面上线，服务覆盖率 90%\n\n**第三阶段：完善（持续）**\n- 新增：智能推荐、跨省通办、数据分析\n- 交付标准：服务质量提升，用户满意度 90%+\n\n---\n\n## 7. 八阶段流程与实施阶段映射\n\n### 映射关系\n\n| 八阶段流程 | 对应实施阶段 | 主要输出物 |\n|------------|--------------|------------|\n| 第一阶段：政策背景分析 | 规划阶段 | 政策分析报告、合规要求清单 |\n| 第二阶段：需求分析 | 规划阶段 | 需求文档、现状分析报告 |\n| 第三阶段：建设思路设计 | 规划阶段 | 建设思路文档、分期规划 |\n| 第四阶段：架构设计 | 规划阶段 | 四维度架构文档、架构图 |\n| 第五阶段：技术选型 | 规划阶段 | 技术选型文档 |\n| **第六阶段：具体建设内容** | **MVP 阶段** | **业务实施方案、功能开发计划、数据实施方案、技术实施方案** |\n| 第七阶段：实施规划 | MVP 阶段 | 实施计划、里程碑时间表 |\n| 第八阶段：风险评估 | MVP 阶段 | 风险清单、缓解措施 |\n\n### 映射说明\n\n**第六阶段：具体建设内容 → MVP 阶段**\n- 业务架构展开：业务流程设计方案、能力建设计划\n- 功能架构展开：功能模块开发计划、接口设计文档\n- 数据架构展开：数据模型设计、ETL 设计、数据字典\n- 技术架构展开：部署方案、安全方案、集成方案\n\n这些具体建设内容直接指导 MVP 阶段的开发实施。\n\n**第七阶段：实施规划 → MVP 阶段及后续阶段**\n- MVP 阶段实施计划：快速验证核心价值\n- 功能扩展阶段计划：扩展功能范围\n- 优化完善阶段计划：提升质量和性能\n\n**第八阶段：风险评估 → 全程跟踪**\n- MVP 阶段风险：验证风险、技术风险\n- 功能扩展阶段风险：集成风险、进度风险\n- 优化完善阶段风险：性能风险、安全风险\n\n### 实施阶段与八阶段流程的对应\n\n**MVP 阶段（4-12 周）**\n- 输入：第六阶段的具体建设内容、第七阶段的实施计划\n- 重点：核心业务流程、核心功能模块、基础技术架构\n- 交付：MVP 版本、用户反馈、验证结果\n\n**功能扩展阶段（8-16 周）**\n- 输入：第六阶段的功能层次实施策略、第七阶段的功能扩展计划\n- 重点：支撑功能、增强功能、集成功能\n- 交付：功能完整版、集成测试报告\n\n**优化完善阶段（12+ 周）**\n- 输入：第六阶段的技术架构展开、第七阶段的优化计划\n- 重点：性能优化、安全加固、用户体验优化\n- 交付：生产就绪版、运维手册、用户手册\n\nFile v1.1.2:references/solution-type-frames.md\n\n# 方案类型框架说明\n\n## 概览\n本文档定义了五类常见的数字化解决方案类型及其标准结构框架，用于指导不同场景下的方案产出。\n\n## 方案类型列表\n\n### 一、规划类方案\n\n**作用**：初次与客户接触，根据客户初步需求，形成比较粗颗粒度的规划想法和方案，以打动客户为目的。\n\n**适用场景**：客户初步接触、需求模糊、需要展示整体愿景和规划思路。\n\n**结构框架**：\n1. **政策背景分析**\n   - 国家/省/市/区县政策依据\n   - 行业发展趋势\n   - 政策机遇与挑战\n\n2. **现状问题分析**\n   - 信息化现状梳理\n   - 存在的主要问题\n   - 行业标杆对比\n\n3. **建设目标及思路**\n   - 总体建设目标\n   - 建设原则\n   - 建设路径\n\n4. **总体架构设计**（主要为业务架构）\n   - 业务架构（简化版）\n   - 建设范围与边界\n\n5. **关键建设内容**\n   - 重点建设项目概述\n   - 核心功能模块\n   - 预期成果\n\n6. **预期建设效益**\n   - 业务效益\n   - 管理效益\n   - 社会效益\n\n**特点**：内容粗颗粒度，强调愿景和方向，不涉及详细设计和费用。\n\n---\n\n### 二、申报类方案\n\n**作用**：比规划类方案内容进一步细化，融入了一定的实际需求内容，主要帮助客户向自己的领导进行汇报并获得领导同意。\n\n**适用场景**：客户需要向内部领导汇报申请立项、预算审批。\n\n**结构框架**：\n1. **项目建设背景**\n   - 政策背景\n   - 行业背景\n   - 项目背景\n\n2. **现状需求及问题分析**\n   - 信息化现状\n   - 业务需求分析\n   - 存在问题分析\n\n3. **建设目标**\n   - 总体目标\n   - 分期目标\n   - 量化指标\n\n4. **总体架构设计**\n   - 业务架构\n   - 数据架构\n   - 系统功能架构\n   - 技术架构\n\n5. **主要建设内容**\n   - 应用系统建设\n   - 数据资源建设\n   - 基础设施建设\n   - 安全保障建设\n\n6. **大致的实施计划**\n   - 分期建设计划\n   - 关键里程碑\n   - 资源需求\n\n7. **预期建设效益分析**\n   - 经济效益\n   - 社会效益\n\n8. **建设费用估算**\n   - 总投资估算\n   - 分项费用估算\n\n**特点**：内容较规划类更细化，包含费用估算，架构设计涵盖四维度。\n\n---\n\n### 三、可研类方案\n\n**作用**：建设项目的可行性研究方案，项目立项审批核心文件，内容比申报类方案更细化，在此过程中，客户需求已基本全部掌握，方案主要用于向相关财政部门申请预算使用，可研类方案需要客户邀请并组织专家进行评审。\n\n**适用场景**：项目立项审批、财政预算申请、专家评审。\n\n**结构框架**：\n\n#### 1. 总论\n- 项目名称\n- 项目建设单位\n- 项目建设地点\n- 项目建设周期\n- 项目总投资及资金来源\n- 项目建设目标与核心内容\n- 可研报告编制依据\n- 主要结论与建议\n\n#### 2. 项目建设背景与必要性\n- 国家/省/市/区县政策依据\n- 行业发展现状与趋势\n- 本地区/本部门信息化现状\n- 当前存在的问题\n- 项目建设必要性与可行性\n\n#### 3. 项目需求分析\n- 业务需求分析\n- 用户需求分析\n- 系统功能需求分析\n- 数据需求分析\n- 性能需求分析\n- 安全需求分析\n- 运维需求分析\n\n#### 4. 总体建设方案\n- 建设目标\n- 建设原则\n- 总体架构设计（技术架构、应用架构、数据架构等）\n- 建设范围与边界\n- 与现有系统的衔接\n\n#### 5. 项目建设内容\n按照总体建设方案设计的内容逐项展开：\n- 基础设施建设\n- 应用系统建设\n- 数据资源体系建设\n- 安全保障体系建设\n- 运维服务体系建设\n\n#### 6. 技术方案与选型\n- 技术路线选择\n- 关键技术说明\n- 软硬件产品选型\n- 接口与集成方案\n- 信创适配方案（政府场景）\n\n#### 7. 项目实施计划\n- 实施阶段划分\n- 项目进度安排\n- 项目组织管理\n- 项目人员配置\n\n#### 8. 投资估算与资金筹措\n- 投资估算依据\n- 总投资估算（分项说明）：\n  - 硬件设备费\n  - 软件购置费/开发费\n  - 实施服务费\n  - 数据资源费\n  - 安全测评费\n  - 培训费\n  - 运维费\n- 资金筹措方案\n\n#### 9. 效益分析\n- 经济效益分析\n- 社会效益分析\n\n#### 10. 风险分析与对策\n- 政策风险\n- 技术风险\n- 管理风险\n- 资金风险\n- 运维风险\n- 风险应对措施\n\n**特点**：内容最全面、最细化，需要经过专家评审，包含详细的投资估算和风险分析。\n\n---\n\n### 四、投标类方案\n\n**作用**：客户可研方案评审通过后，需要进行公开招投标，以选拔项目的承建厂商，有意向的厂商需要根据客户发布的招标需求，编制投标方案。\n\n**适用场景**：公开招投标、竞争性谈判。\n\n**结构框架**：\n\n#### 1. 项目需求理解与分析\n- 项目建设背景与政策依据\n- 现状痛点分析\n- 核心需求拆解\n- 项目建设目标\n\n#### 2. 总体建设方案\n- 建设思路与原则\n- 总体架构设计（技术架构、应用架构、数据架构、安全架构等）\n- 建设范围与边界\n- 关键技术路线\n\n#### 3. 详细功能设计方案\n核心业务系统功能模块，需按照招标需求内容逐项响应，并附上功能清单：\n- 管理后台功能\n- 运维平台功能\n- 数据服务与分析功能\n- 接口与集成方案\n- 信创/国产化适配方案（政府场景）\n\n#### 4. 项目实施与管理方案\n- 项目组织架构\n- 关键人员简历\n- 实施方法论\n- 项目进度计划\n- 质量管理方案\n- 风险管控\n- 变更管理\n\n#### 5. 信息安全与合规方案\n- 网络安全方案\n- 数据安全方案\n- 应用安全方案\n- 等保测评与合规（政府场景）\n- 安全管理制度与应急响应\n\n#### 6. 运维服务与保障方案\n- 运维服务模式\n- 运维内容\n- 服务级别协议（SLA）\n- 运维团队与工具\n- 售后保障机制\n\n#### 7. 培训方案\n- 培训计划\n- 培训内容与教材\n- 培训方式\n- 培训考核与效果保障\n\n#### 8. 项目报价文件\n- 投标报价汇总表\n- 详细报价清单\n\n**特点**：围绕招标需求响应，强调技术实力、实施能力、管理能力和价格竞争力。\n\n---\n\n### 五、工作汇报类方案\n\n**作用**：项目开展后，在执行的过程中，需要阶段性的给客户反馈工作进度情况，以获得客户的肯定和新的指示、新的需求。\n\n**适用场景**：项目执行过程中的阶段性汇报、里程碑评审、需求变更汇报。\n\n**结构框架**：\n1. **工作背景**\n   - 项目背景\n   - 汇报周期\n   - 汇报目的\n\n2. **需要解决的问题**\n   - 当前面临的问题\n   - 问题影响分析\n\n3. **当前正在开展的工作内容及完成情况**\n   - 本阶段工作内容\n   - 完成情况\n   - 与计划对比\n\n4. **已经产生的工作成果及成效**\n   - 交付物清单\n   - 成果展示\n   - 成效评估\n\n5. **当前工作开展中存在的问题**\n   - 问题清单\n   - 原因分析\n\n6. **下一步工作计划**\n   - 下阶段工作内容\n   - 计划安排\n   - 预期成果\n\n7. **需要领导给予的支持**\n   - 资源需求\n   - 决策事项\n   - 协调事项\n\n**特点**：简洁实用，重点突出工作进展、成果和需要支持的事项。\n\n---\n\n## 方案类型选择指南\n\n### 根据项目阶段选择\n- **项目初期接触** → 规划类方案\n- **客户内部汇报立项** → 申报类方案\n- **正式立项审批** → 可研类方案\n- **公开招标采购** → 投标类方案\n- **项目执行过程** → 工作汇报类方案\n\n### 根据内容深度选择\n- **粗颗粒度、展示愿景** → 规划类方案\n- **中颗粒度、包含费用** → 申报类方案\n- **细颗粒度、全面详细** → 可研类方案\n- **响应招标需求、强调竞争力** → 投标类方案\n- **汇报进展、聚焦执行** → 工作汇报类方案\n\n### 根据目标受众选择\n- **客户业务负责人** → 规划类方案\n- **客户内部领导** → 申报类方案\n- **财政部门、评审专家** → 可研类方案\n- **招标评审委员会** → 投标类方案\n- **客户项目组、领导** → 工作汇报类方案\n\n## 补充说明\n\n1. 若用户需要的方案类型不在上述示例当中，可以主动询问客户，或者从互联网搜索一些同类型方案的框架，供客户参考确认。\n\n2. 在设计方案内容时，有些章节内容需要结合客户的实际需求或是信息化现状情况，这些内容可以主动邀请用户提供一些，若用户无法提供，可以从互联网搜索一些同类型客户的共性现状需求和问题。\n\nFile v1.1.2:references/technology-stack-guide.md\n\n# 技术选型指南\n\n## 目录\n1. 前端技术选型\n2. 后端技术选型\n3. 数据存储选型\n4. 中间件选型\n5. 基础设施选型\n6. 技术选型评估框架\n\n## 概览\n本文档提供各技术栈的选型建议，包括主流技术选项、适用场景和评估维度，用于指导技术决策。\n\n## 核心内容\n\n### 1. 前端技术选型\n\n#### Web 前端\n\n**React 生态**\n- 框架：React + TypeScript\n- 状态管理：Redux Toolkit / Zustand / Jotai\n- 路由：React Router\n- UI 库：Ant Design / Material-UI / Chakra UI\n- 构建工具：Vite / Next.js\n- 适用场景：大型应用、复杂交互、组件化开发\n\n**Vue 生态**\n- 框架：Vue 3 + TypeScript\n- 状态管理：Pinia\n- 路由：Vue Router\n- UI 库：Element Plus / Naive UI / Vuetify\n- 构建工具：Vite / Nuxt.js\n- 适用场景：渐进式开发、中小型项目、国内项目\n\n**其他选项**\n- Svelte：轻量级、高性能，适合小型项目\n- Angular：企业级应用，学习曲线陡峭\n- 纯 HTML/CSS/JS：简单页面、静态网站\n\n#### 移动端\n\n**跨平台**\n- React Native：基于 React，生态丰富\n- Flutter：Google 出品，性能好，适合统一 UI\n- uni-app：基于 Vue，适合国内生态（微信小程序、App）\n\n**原生开发**\n- iOS：Swift + SwiftUI\n- Android：Kotlin + Jetpack Compose\n\n#### 前端选型考虑因素\n- 团队熟悉度\n- 项目复杂度和规模\n- 性能要求\n- 生态成熟度\n- 学习曲线\n- 社区支持和文档\n\n---\n\n### 2. 后端技术选型\n\n#### 编程语言与框架\n\n**Java 生态**\n- 框架：Spring Boot / Spring Cloud\n- 适用场景：企业级应用、微服务、大团队\n- 优势：成熟稳定、生态完善、类型安全\n- 劣势：启动慢、资源占用高\n\n**Python 生态**\n- 框架：Django / FastAPI / Flask\n- 适用场景：快速开发、数据处理、AI/ML 集成\n- 优势：开发效率高、生态丰富、学习曲线低\n- 劣势：性能相对较低、GIL 限制并发\n\n**Node.js 生态**\n- 框架：Express / NestJS / Koa\n- 适用场景：实时应用、全栈开发、高并发 IO\n- 优势：统一语言、异步非阻塞、生态活跃\n- 劣势：CPU 密集型任务性能差\n\n**Go 生态**\n- 框架：Gin / Echo / Beego\n- 适用场景：微服务、高性能服务、云原生\n- 优势：高性能、并发友好、部署简单\n- 劣势：生态相对较小、学习曲线\n\n**其他语言**\n- C# (.NET)：企业级应用，Windows 环境优势\n- Ruby on Rails：快速原型、初创项目\n- PHP：传统 Web 应用、快速开发\n\n#### 后端选型考虑因素\n- 团队技术栈\n- 性能要求（吞吐量、延迟）\n- 并发模型\n- 生态和库支持\n- 运维成熟度\n\n---\n\n### 3. 数据存储选型\n\n#### 关系型数据库\n\n**MySQL**\n- 适用场景：通用场景、Web 应用、中小规模\n- 优势：成熟稳定、社区大、文档丰富\n- 版本推荐：MySQL 8.0+\n\n**PostgreSQL**\n- 适用场景：复杂查询、JSON 数据、地理信息、数据分析\n- 优势：功能强大、扩展性好、开源友好\n- 版本推荐：PostgreSQL 14+\n\n**其他**\n- Oracle：大型企业应用、商业项目\n- SQL Server：Windows 环境、企业应用\n\n#### NoSQL 数据库\n\n**文档数据库**\n- MongoDB：灵活文档模型、快速迭代\n- 适用场景：内容管理、产品目录、原型开发\n\n**键值存储**\n- Redis：缓存、会话存储、排行榜\n- DynamoDB：AWS 原生、自动扩展\n\n**列式存储**\n- Cassandra：大规模写入、分布式\n- HBase：大数据场景\n\n**时序数据库**\n- InfluxDB：IoT 数据、监控指标\n- TimescaleDB：基于 PostgreSQL 的时序扩展\n\n#### 图数据库\n- Neo4j：社交网络、推荐系统、知识图谱\n\n#### 数据库选型考虑因素\n- 数据模型（关系型 vs 文档 vs 图）\n- 查询模式（复杂查询 vs 简单 CRUD）\n- 数据量和增长预期\n- 一致性要求（强一致 vs 最终一致）\n- 扩展需求（垂直 vs 水平扩展）\n- 团队熟悉度\n\n---\n\n### 4. 中间件选型\n\n#### 消息队列\n\n**RabbitMQ**\n- 适用场景：中小规模、复杂路由、可靠性要求高\n- 优势：功能丰富、路由灵活、管理界面友好\n- 劣势：吞吐量相对较低\n\n**Kafka**\n- 适用场景：大数据流、日志收集、事件溯源\n- 优势：高吞吐、持久化、分布式\n- 劣势：运维复杂、延迟较高\n\n**其他**\n- Redis Stream：轻量级、简单场景\n- RocketMQ：阿里开源、适合电商场景\n- Pulsar：云原生、多租户\n\n#### 缓存\n\n**Redis**\n- 适用场景：通用缓存、分布式锁、排行榜\n- 优势：性能高、数据结构丰富\n- 持久化：RDB / AOF\n\n**Memcached**\n- 适用场景：简单键值缓存\n- 优势：简单、轻量\n- 劣势：功能单一\n\n#### 搜索引擎\n\n**Elasticsearch**\n- 适用场景：全文搜索、日志分析、监控\n- 优势：功能强大、生态丰富（ELK Stack）\n- 劣势：资源占用高\n\n**其他**\n- Solr：传统企业应用\n- OpenSearch：Elasticsearch 开源分支\n\n#### API 网关\n\n**Kong**\n- 适用场景：微服务、插件生态需求\n- 优势：插件丰富、性能好\n\n**Nginx**\n- 适用场景：简单反向代理、负载均衡\n- 优势：轻量、稳定、配置简单\n\n**其他**\n- Traefik：云原生、自动配置\n- API Gateway：AWS、阿里云等云服务\n\n---\n\n### 5. 基础设施选型\n\n#### 容器化\n\n**Docker**\n- 标准化部署、环境一致性\n\n**Kubernetes**\n- 大规模容器编排、微服务部署\n- 运维复杂度较高\n\n#### CI/CD\n\n**GitHub Actions / GitLab CI**\n- 代码托管平台集成，配置简单\n\n**Jenkins**\n- 传统企业、高度定制需求\n\n#### 云服务\n\n**AWS**\n- 服务最全、生态成熟\n- 适合全球化部署\n\n**阿里云 / 腾讯云**\n- 国内访问快、本地化服务\n- 适合国内项目\n\n**其他考虑**\n- 云原生 vs 自建\n- 成本可控性\n- 合规要求\n\n---\n\n### 6. 技术选型评估框架\n\n#### 评估维度\n\n| 维度 | 说明 | 评分（1-5） |\n|------|------|------------|\n| **成熟度** | 技术是否成熟、稳定 |  |\n| **生态** | 社区活跃度、文档质量、第三方库 |  |\n| **性能** | 响应时间、吞吐量、资源占用 |  |\n| **可维护性** | 代码清晰度、调试友好、测试便利 |  |\n| **团队能力** | 团队熟悉度、学习曲线、招聘难度 |  |\n| **成本** | 开发成本、运维成本、许可成本 |  |\n| **扩展性** | 水平/垂直扩展能力 |  |\n| **安全性** | 已知漏洞、安全实践 |  |\n\n#### 评估流程\n\n1. **列出候选技术**：每个技术方向列出 2-3 个选项\n2. **权重设置**：根据项目特点设置维度权重\n3. **专家评审**：团队技术专家参与打分\n4. **POC 验证**：关键技术进行原型验证\n5. **决策记录**：记录选型依据和权衡\n\n#### 典型场景示例\n\n**场景 1：电商平台后端**\n- 候选：Java Spring Boot vs Go Gin\n- 权重：性能(30%) + 团队能力(30%) + 生态(20%) + 成本(20%)\n- 决策：Spring Boot（团队能力匹配，生态成熟）\n\n**场景 2：实时聊天应用**\n- 候选：Node.js + Socket.io vs Go + WebSocket\n- 权重：性能(40%) + 并发(30%) + 开发效率(30%)\n- 决策：Node.js（开发效率高，并发性能满足）\n\n**场景 3：数据分析平台**\n- 候选：MySQL vs PostgreSQL vs MongoDB\n- 权重：查询灵活性(40%) + 性能(30%) + 扩展性(30%)\n- 决策：PostgreSQL（复杂查询支持，JSON 灵活性）\n\n---\n\n## 示例\n\n### 示例 1：中小型 Web 应用\n\n```\n前端：React + TypeScript + Ant Design\n后端：Node.js + NestJS + Prisma ORM\n数据库：PostgreSQL\n缓存：Redis\n部署：Docker + Docker Compose\nCI/CD：GitHub Actions\n```\n\n### 示例 2：大型电商平台\n\n```\n前端：React + TypeScript (管理后台) + Vue 3 (商家端)\n后端：Java Spring Cloud 微服务\n数据库：MySQL (分库分表) + Redis (缓存)\n消息队列：Kafka\n搜索：Elasticsearch\n部署：Kubernetes\n监控：Prometheus + Grafana\n```\n\n### 示例 3：移动 App 后端\n\n```\n前端：Flutter (App)\n后端：Go + Gin\n数据库：PostgreSQL + MongoDB\n缓存：Redis\n推送：Firebase Cloud Messaging\n部署：AWS ECS + RDS\n```\n\n### 示例 4：内部管理系统\n\n```\n前端：Vue 3 + Element Plus\n后端：Python FastAPI\n数据库：MySQL\n部署：Docker + Nginx\n认证：JWT\n```\n\nArchive v1.1.1: 9 files, 37491 bytes\n\nFiles: README.md (19429b), Reference/architecture-dimensions.md (22256b), Reference/architecture-patterns.md (7187b), Reference/government-digitalization.md (14354b), Reference/implementation-phases.md (12642b), Reference/solution-type-frames.md (8662b), Reference/technology-stack-guide.md (8213b), Skill.md (5727b), _meta.json (144b)\n\nFile v1.1.1:Skill.md\n\n---\nname: digital-solution-designer\ndescription: 系统化设计数字化解决方案，涵盖方案类型识别、政策背景分析、需求分析、建设思路设计、架构设计（业务、功能、数据、技术四维度）、技术选型、具体建设内容、实施规划、风险评估和投资估算的全流程能力。适用于规划类、申报类、可研类、投标类和工作汇报类等多种方案产出场景，覆盖政府数字化转型和企业数字化转型两大核心领域。\ndependency:\n  python:\n    - graphviz>=0.20.1\n---\n\n# 数字化解决方案设计\n\n## 任务目标\n系统化设计数字化解决方案，从方案类型识别到实施规划的完整流程，支持多种方案类型的结构化输出。\n\n核心领域：政府数字化转型、企业数字化转型。\n\n触发条件：\"设计[系统/平台/应用]解决方案\"、\"规划[业务场景]数字化方案\"、\"评估[系统]升级方案\"、\"设计[领域]技术架构\"、\"政府数字化转型\"、\"政务系统\"、\"一网通办\"、\"数字政府\"、\"规划方案\"、\"申报方案\"、\"可研方案\"、\"投标方案\"、\"工作汇报\"\n\n## 方案类型识别规则（强制执行）\n1. **强制询问**：用户输入需求后，**必须先询问**方案类型，禁止推导或猜测。\n   - 询问语：\"请问您需要产出哪种类型的方案？可选择：规划类、申报类、可研类、投标类、工作汇报类\"\n2. **等待确认**：待用户明确反馈后，再根据所选类型编写方案。\n\n各类型详细说明见 `README.md`。\n\n## 操作流程（按方案类型选择执行）\n\n### 第零阶段：方案类型识别（必执行）\n询问用户方案类型，确认后按下方映射执行。\n\n**方案类型流程映射**：\n- **规划类**：第一阶段(政策背景) → 第二阶段(简化需求) → 第三阶段(建设思路) → 4.1(简化业务架构) → 第六阶段(简化建设内容) → 效益分析\n- **申报类**：第一阶段 → 第二阶段 → 第三阶段 → 第四阶段(四维度架构) → 第六阶段(主要建设内容) → 第七阶段(简化实施计划) → 效益分析 → 费用估算\n- **可研类**：全部阶段(第一至第八阶段) + 投资估算。需求需细化至业务、用户、功能、数据、性能、安全、运维；技术选型需详细。\n- **投标类**：第二阶段(需求理解) → 第三阶段(总体方案) → 第四阶段(四维度架构) → 详细功能设计 → 项目管理方案 → 安全合规方案 → 运维方案 → 培训方案 → 报价文件\n- **工作汇报类**：特殊结构(工作背景→问题→当前工作→成果→问题→下一步计划→需支持)\n\n### 第一阶段：政策背景分析\n梳理政策环境，分析影响与合规要求。输出政策分析报告。\n\n### 第二阶段：需求分析\n行业与客户现状分析，收集核心需求并排序(MoSCoW/MVP)。输出需求文档。\n\n### 第三阶段：建设思路设计\n确定目标、原则、路径与分期规划。输出建设思路文档。\n\n### 第四阶段：架构设计（四维度）\n- **业务架构**：梳理流程与能力，生成架构图。使用 `python scripts/generate-architecture-diagram.py --diagram-type business --input business.dot --output business.png`\n- **功能架构**：划分模块与层次，生成架构图。使用 `--diagram-type functional`\n- **数据架构**：设计模型、数据流、标准与治理，生成架构图。使用 `--diagram-type data`\n- **技术架构**：确定模式、部署、安全与集成设计，生成架构图。使用 `--diagram-type technical`\n架构图生成需预装 `graphviz`，DOT 模板参考 `references/architecture-dimensions.md`。\n\n### 第五阶段：技术选型\n确定选型维度并评估技术栈。参考 `references/technology-stack-guide.md`。\n\n### 第六阶段：具体建设内容\n将四维度架构转化为具体建设任务：业务实施、功能开发、数据实现、技术部署。\n\n### 第七阶段：实施规划\n规划实施阶段(MVP→扩展→优化)，分解任务与里程碑。参考 `references/implementation-phases.md`。\n\n### 第八阶段：风险评估\n识别并评估风险，制定缓解策略。\n\n### 第九阶段：效益分析与投资估算\n- **效益分析**：经济/社会/管理效益。\n- **投资估算**：申报/可研/投标类必需。包含硬件、软件、服务、数据、测评、培训、运维等分项。\n\n### 第十阶段：特殊章节（按类型增加）\n- 详细功能设计（投标类）\n- 项目实施与管理方案（投标类）\n- 信息安全与合规方案（投标、可研类）\n- 运维服务与保障方案（投标类）\n- 培训方案（投标类）\n\n## 可选分支\n- 快速原型 / 企业级 / 创新项目 / 遗留系统迁移 / 政府数字化转型(参考 `references/government-digitalization.md`)\n\n## 资源索引\n- 架构图脚本：`scripts/generate-architecture-diagram.py`\n- 方案类型框架：`references/solution-type-frames.md`\n- 架构模式参考：`references/architecture-patterns.md`\n- 架构维度参考：`references/architecture-dimensions.md`\n- 技术选型指南：`references/technology-stack-guide.md`\n- 实施阶段参考：`references/implementation-phases.md`\n- 政府数字化参考：`references/government-digitalization.md`\n\n## 注意事项\n- **强制询问方案类型**：用户输入后必须先询问，不可推导。\n- **阶段迭代**：根据方案类型选择所需阶段。\n- **产出导向**：每阶段产出明确文档。\n- **业务优先**：技术服务于业务目标。\n- **四维度协同**：业务、功能、数据、技术架构需一致。\n- **架构图生成**：使用指定脚本。\n- **详细说明见 `README.md`**。\n\nFile v1.1.1:README.md\n\n# 数字化解决方案设计 Skill 详细说明\n\n本 Skill 用于系统化设计数字化解决方案，支持政府和企业数字化转型场景下的多种方案类型。\n\n## 支持的方案类型\n\n### 1. 规划类方案\n- **适用场景**：初次接触客户，粗颗粒度规划，以打动客户为目的。\n- **输出重点**：政策背景、现状问题、建设目标及思路、业务架构（简化）、关键建设内容、预期效益。\n\n### 2. 申报类方案\n- **适用场景**：客户内部汇报、立项申请、预算审批。\n- **输出重点**：建设背景、需求分析、建设目标、四维度架构、主要建设内容、实施计划（简化）、效益分析、费用估算。\n\n### 3. 可研类方案\n- **适用场景**：项目立项审批、财政预算申请、专家评审。\n- **输出重点**：总论、背景与必要性、需求分析（细化至业务、用户、功能、数据、性能、安全、运维）、总体建设方案、建设内容、详细技术方案与选型、实施计划、投资估算、效益分析、风险分析。\n\n### 4. 投标类方案\n- **适用场景**：公开招投标、竞争性谈判。\n- **输出重点**：需求理解、总体建设方案、详细功能设计、实施与管理、安全与合规、运维服务、培训方案、报价文件。\n\n### 5. 工作汇报类方案\n- **适用场景**：项目执行过程汇报、里程碑评审、需求变更汇报。\n- **输出结构**：工作背景 → 需要解决的问题 → 当前工作及完成情况 → 成果及成效 → 存在问题 → 下一步计划 → 需要领导支持。\n\n---\n\n## 各阶段详细说明\n\n### 第一阶段：政策背景分析\n1. 梳理政策环境（国家/行业/地方/国际政策）\n2. 分析政策影响（指导意义、机遇、约束、趋势）\n3. 识别合规要求（法律法规、行业标准、数据安全、技术标准）\n4. 输出政策分析报告（政策环境、关键解读、合规清单、机遇挑战）\n\n检查点：✅ 政策环境梳理全面、✅ 合规要求识别清晰、✅ 政策影响分析到位\n\n### 第二阶段：需求分析\n1. 行业现状分析（趋势、技术、竞争、痛点）\n2. 客户现状问题分析（系统流程、痛点、瓶颈、差距）\n3. 收集核心需求（业务目标、用户场景、功能范围、非功能需求、约束条件）\n4. 需求优先级排序（MoSCoW 方法、MVP 范围、基础/增强/创新需求）\n5. 输出需求文档（行业/客户现状分析、需求概述、功能清单、非功能需求、MVP 定义）\n\n检查点：✅ 行业现状分析深入、✅ 客户问题诊断准确、✅ 业务价值明确、✅ 功能边界清晰、✅ MVP 范围可界定\n\n### 第三阶段：建设思路设计\n1. 确定总体建设目标（战略愿景、量化目标、价值主张、成功标准）\n2. 制定建设原则（业务价值导向、用户体验中心、技术业务融合、渐进演进）\n3. 设计建设路径（自建/采购/合作、传统/云原生/信创、实施模式、转型策略）\n4. 规划分期建设（分期原则、各期目标范围、交付物、依赖关系）\n5. 输出建设思路文档（目标愿景、建设原则、路径策略、分期规划、价值主张）\n\n检查点：✅ 建设目标清晰可量化、✅ 建设原则指导性强、✅ 建设路径合理可行、✅ 分期规划逻辑清晰\n\n### 第四阶段：架构设计（四维度）\n\n#### 4.1 业务架构\n- 梳理业务流程（核心/支撑/管理/跨部门协同）\n- 识别业务能力（核心/支撑/管理/集成能力）\n- 设计业务关系（实体/协作/流转/服务关系）\n- 生成业务架构图（DOT 格式，调用脚本）\n检查点：✅ 业务流程覆盖全面、✅ 业务能力边界清晰、✅ 业务关系逻辑合理、✅ 架构图清晰准确\n\n#### 4.2 功能架构\n- 划分功能模块（按业务领域/用户角色/系统层次/业务能力）\n- 设计功能层次（核心/支撑/增强/集成功能层）\n- 设计功能关系（依赖/调用/协作/复用关系）\n- 生成功能架构图\n检查点：✅ 功能模块划分合理、✅ 功能层次清晰、✅ 功能关系明确、✅ 架构图清晰准确\n\n#### 4.3 数据架构\n- 设计数据模型（实体/属性/关系/类型约束）\n- 设计数据流（业务/系统/跨系统数据流，采集/存储/处理/应用）\n- 设计数据标准（字典/编码/质量管理标准）\n- 设计数据治理（分类分级/安全隐私/生命周期/共享开放）\n- 生成数据架构图\n检查点：✅ 数据模型完整、✅ 数据流清晰、✅ 数据标准统一、✅ 数据治理方案可行、✅ 架构图清晰准确\n\n#### 4.4 技术架构\n- 确定技术架构模式（参考 `references/architecture-patterns.md`）\n- 设计部署架构（拓扑/分层/容器化/高可用容灾）\n- 设计安全架构（网络/应用/数据/运维安全）\n- 设计集成架构（API网关/服务注册/消息队列/数据交换）\n- 生成技术架构图\n检查点：✅ 架构模式选择合理、✅ 部署架构可行、✅ 安全架构完善、✅ 集成架构灵活、✅ 架构图清晰准确\n\n### 第五阶段：技术选型\n1. 确定技术选型维度（前端、后端、数据存储、中间件、基础设施）\n2. 技术栈评估：参考 `references/technology-stack-guide.md`，评估成熟度、社区生态、团队能力、成本，进行关键技术权衡\n3. 输出技术选型文档（技术栈清单、选型依据与权衡、潜在风险与备选方案）\n检查点：✅ 技术选型有明确依据、✅ 考虑了团队能力匹配、✅ 关键技术有备选方案\n\n### 第六阶段：具体建设内容\n本阶段将架构设计转化为具体的建设任务和交付物。\n\n#### 6.1 业务架构展开\n- 业务流程实施设计（关键流程设计、流程优化、跨部门协同）\n- 业务能力建设计划（实施路径、时间表、资源需求）\n- 业务关系实现设计（协作机制、服务契约）\n检查点：✅ 业务流程设计完整、✅ 能力建设计划可执行、✅ 协作机制明确\n\n#### 6.2 功能架构展开\n- 功能模块开发计划（功能点清单、开发计划、验收标准）\n- 功能层次实施策略（核心/支撑/增强/集成功能的实施顺序）\n- 功能关系实现设计（接口设计、数据流设计）\n检查点：✅ 功能模块覆盖全面、✅ 开发计划可执行、✅ 接口设计完整\n\n#### 6.3 数据架构展开\n- 数据模型实现设计（表结构、数据字典、数据初始化）\n- 数据流实现设计（ETL 方案、同步策略、缓存策略）\n- 数据标准实施（数据规范、质量管控）\n- 数据治理实施（数据安全、权限控制、生命周期管理）\n检查点：✅ 数据模型设计完整、✅ 数据流设计可行、✅ 数据安全措施到位\n\n#### 6.4 技术架构展开\n- 部署架构实施设计（环境准备、部署方案、监控方案）\n- 安全架构实施设计（安全策略、安全配置、安全测试）\n- 集成架构实施设计（API 设计、中间件配置、系统集成）\n检查点：✅ 部署方案可行、✅ 安全措施完善、✅ 集成方案完整\n\n### 第七阶段：实施规划\n1. 规划实施阶段：参考 `references/implementation-phases.md`，阶段划分 MVP → 功能扩展 → 优化完善\n2. 任务分解与排期（WBS、任务依赖、资源需求）\n3. 关键里程碑定义（MVP 发布、功能完整版、生产就绪版）\n4. 输出实施计划（阶段规划、里程碑时间表、资源需求）\n检查点：✅ MVP 可快速交付、✅ 阶段划分合理、✅ 里程碑可度量\n\n### 第八阶段：风险评估\n1. 识别关键风险（技术、业务、项目、运维风险）\n2. 风险评估（发生概率、影响程度、风险等级）\n3. 制定缓解策略（预防措施、应急预案、责任人）\n4. 输出风险清单（风险分类与等级、缓解措施、监控指标）\n检查点：✅ 关键风险已识别、✅ 高风险有缓解措施、✅ 风险可跟踪\n\n### 第九阶段：效益分析与投资估算\n\n#### 9.1 效益分析\n- 经济效益：成本节约、收入增长、投资回报率（ROI）计算\n- 社会效益（政府场景重点）：服务效率提升、群众满意度提升、政府治理能力提升\n- 管理效益（企业场景重点）：管理效率提升、决策支持能力提升、业务协同能力提升\n\n#### 9.2 投资估算（申报类、可研类、投标类方案必需）\n1. 确定投资估算依据（参考市场价格、行业标准、类似项目）\n2. 总投资估算（分项说明）：\n   - 硬件设备费（服务器、存储、网络设备等）\n   - 软件购置费/开发费（基础软件、定制开发）\n   - 实施服务费（咨询、实施、集成）\n   - 数据资源费（数据采集、清洗、迁移）\n   - 安全测评费（等保测评、安全评估）\n   - 培训费（培训讲师、培训材料）\n   - 运维费（年度运维、技术支持）\n3. 资金筹措方案（资金来源、分期资金安排、资金使用计划）\n检查点：✅ 投资估算依据充分、✅ 分项明细完整、✅ 资金筹措方案可行\n\n### 第十阶段：特殊章节（根据方案类型增加）\n\n#### 10.1 详细功能设计方案（投标类方案必需）\n- 管理后台功能设计（用户管理、角色权限、系统配置、业务功能模块详细设计）\n- 运维平台功能设计（系统监控、日志管理、告警管理、性能监控、故障诊断）\n- 数据服务与分析功能设计（数据查询、统计分析、报表展示、数据挖掘、智能分析）\n- 功能清单输出（按照招标需求逐项响应）\n\n#### 10.2 项目实施与管理方案（投标类方案必需）\n- 项目组织架构设计（项目经理、技术负责人、开发团队、测试团队）\n- 关键人员简历（资质、经验、项目案例）\n- 实施方法论（敏捷开发、瀑布模型、混合模式）\n- 项目进度计划（甘特图、关键路径）\n- 质量管理方案（质量标准、测试方案、质量评审）\n- 风险管控（风险识别、风险评估、应对措施）\n- 变更管理（变更流程、变更评审、变更记录）\n\n#### 10.3 信息安全与合规方案（投标类、可研类方案必需）\n- 网络安全方案（防火墙、入侵检测、网络隔离）\n- 数据安全方案（数据加密、数据脱敏、数据备份）\n- 应用安全方案（身份认证、访问控制、安全审计）\n- 等保测评与合规（政府场景：等保三级测评、合规评估）\n- 安全管理制度与应急响应\n\n#### 10.4 运维服务与保障方案（投标类方案必需）\n- 运维服务模式（远程运维、驻场运维、混合模式）\n- 运维内容（系统巡检、故障处理、性能优化）\n- 服务级别协议（SLA）（响应时间、解决时间、可用性）\n- 运维团队与工具（运维人员、运维平台、监控系统）\n- 售后保障机制（服务热线、升级流程、投诉渠道）\n\n#### 10.5 培训方案（投标类方案必需）\n- 培训计划（培训对象、培训时间、培训周期）\n- 培训内容与教材（业务操作培训、技术培训、管理培训）\n- 培训方式（集中培训、在线培训、现场指导）\n- 培训考核与效果保障（考核方式、效果评估、持续支持）\n\n---\n\n## 可选分支详解\n\n- **快速原型场景**：政策背景分析 → 需求分析 → 快速架构（四维度简化）→ 技术选型 → 具体建设内容（简化）→ 原型实现\n- **企业级系统**：强调安全、合规、高可用性设计\n- **创新项目**：增加可行性验证阶段，采用实验性技术\n- **遗留系统迁移**：增加现状评估、迁移策略设计\n- **政府数字化转型场景**：增加合规评估、安全设计、政策适配、服务便民化设计，参考 `references/government-digitalization.md`\n\n## 使用示例\n\n### 示例 0：方案类型识别（强制流程）\n- **功能**：用户输入需求后，强制询问方案类型，待用户明确后再进行方案编写。\n- **执行方式**：智能体主导，第零阶段必执行。\n- **关键指导**：\n  - **强制要求**：用户输入需求后，**必须先询问**用户方案类型，不要通过关键词推导或猜测。\n  - 询问语：\"请问您需要产出哪种类型的方案？可选择：规划类、申报类、可研类、投标类、工作汇报类\"\n  - 若用户不清楚，参考本 README 中的方案类型说明。\n  - **等待用户明确反馈方案类型后**，再根据用户选择的方案类型进行解决方案内容的编写。\n  - 根据确认的方案类型选择对应的执行阶段和输出结构。\n\n### 示例 1：规划类方案 - 政务服务平台规划\n- **功能**：为某政府部门设计粗颗粒度的政务服务平台规划方案。\n- **执行方式**：智能体主导，执行规划类方案流程。\n- **关键指导**：\n  - 方案类型：规划类方案\n  - 执行阶段：第零阶段 → 第一阶段（政策背景分析）→ 第二阶段（需求分析，简化）→ 第三阶段（建设思路设计）→ 4.1（业务架构，简化）→ 第六阶段（具体建设内容，简化）→ 效益分析\n  - 输出重点：政策背景分析、现状问题、建设目标及思路、业务架构（简化）、关键建设内容、预期效益\n  - 内容特点：粗颗粒度、强调愿景和方向，不涉及详细设计和费用\n\n### 示例 2：申报类方案 - 企业数字化管理系统申报\n- **功能**：为企业设计数字化管理系统申报方案，用于内部立项申请。\n- **执行方式**：智能体主导，执行申报类方案流程。\n- **关键指导**：\n  - 方案类型：申报类方案\n  - 执行阶段：第零阶段 → 第一阶段 → 第二阶段 → 第三阶段 → 第四阶段（四维度架构）→ 第六阶段（主要建设内容）→ 第七阶段（实施规划，简化）→ 效益分析 → 费用估算\n  - 输出重点：建设背景、需求分析、建设目标、四维度架构、主要建设内容、实施计划（简化）、效益分析、费用估算\n  - 内容特点：较规划类更细化，包含费用估算，架构设计涵盖四维度\n\n### 示例 3：可研类方案 - 政府数字政府建设可研\n- **功能**：为政府数字政府建设项目设计可行性研究报告。\n- **执行方式**：智能体主导，执行可研类方案流程（全部阶段）。\n- **关键指导**：\n  - 方案类型：可研类方案\n  - 执行阶段：全部阶段（第零阶段至第八阶段）+ 投资估算（第九阶段）\n  - 输出重点：总论、背景与必要性、需求分析（细化）、总体建设方案、建设内容、技术方案与选型（详细）、实施计划、投资估算、效益分析、风险分析\n  - 需求分析需细化：业务、用户、功能、数据、性能、安全、运维\n  - 技术选型需详细：技术路线、关键技术、软硬件选型、集成方案、信创适配（政府场景）\n  - 内容特点：内容最全面、最细化，包含详细的投资估算和风险分析\n\n### 示例 4：投标类方案 - 政务云平台投标\n- **功能**：为政务云平台招标项目设计投标方案。\n- **执行方式**：智能体主导，执行投标类方案流程。\n- **关键指导**：\n  - 方案类型：投标类方案\n  - 执行阶段：第零阶段 → 第二阶段（项目需求理解与分析）→ 第三阶段（总体建设方案）→ 第四阶段（四维度架构）→ 10.1（详细功能设计）→ 10.2（项目实施与管理方案）→ 10.3（信息安全与合规方案）→ 10.4（运维服务与保障方案）→ 10.5（培训方案）→ 报价文件\n  - 输出重点：需求理解、总体建设方案、详细功能设计、实施与管理、安全与合规、运维服务、培训方案、报价文件\n  - 详细功能设计需按照招标需求逐项响应，并附上功能清单\n  - 内容特点：围绕招标需求响应，强调技术实力、实施能力、管理能力和价格竞争力\n\n### 示例 5：工作汇报类方案 - 项目阶段性汇报\n- **功能**：为项目执行过程设计阶段性工作汇报方案。\n- **执行方式**：智能体主导，执行工作汇报类方案特殊流程。\n- **关键指导**：\n  - 方案类型：工作汇报类方案\n  - 执行流程：特殊流程，不使用标准八阶段流程\n  - 输出结构：工作背景 → 需要解决的问题 → 当前正在开展的工作内容及完成情况 → 已经产生的工作成果及成效 → 当前工作开展中存在的问题 → 下一步工作计划 → 需要领导给予的支持\n  - 内容特点：简洁实用，重点突出工作进展、成果和需要支持的事项\n\n### 示例 6：生成架构图\n- **功能**：使用脚本生成各类架构图。\n- **执行方式**：调用 `scripts/generate-architecture-diagram.py` 脚本。\n- **关键指导**：\n  - 前置安装：`pip install graphviz`\n  - 创建 DOT 格式文件（参考 `references/architecture-dimensions.md` 中的模板）\n  - 生成业务架构图：`python scripts/generate-architecture-diagram.py --diagram-type business --input business.dot --output business.png`\n  - 生成功能架构图：`python scripts/generate-architecture-diagram.py --diagram-type functional --input functional.dot --output functional.png`\n  - 生成数据架构图：`python scripts/generate-architecture-diagram.py --diagram-type data --input data.dot --output data.png`\n  - 生成技术架构图：`python scripts/generate-architecture-diagram.py --diagram-type technical --input technical.dot --output technical.png`\n\n## 注意事项\n- **方案类型识别强制要求**：用户输入需求后，**必须先询问**用户方案类型，不要通过关键词推导或猜测，等待用户明确反馈后再进行方案编写。\n- **阶段迭代**：不需要线性完成所有阶段，根据方案类型选择需要的阶段执行。\n- **产出导向**：每个阶段都应产出明确文档或决策，避免过度设计。\n- **业务优先**：技术方案必须服务于业务目标，避免技术驱动。\n- **平衡原则**：在理想方案与实际约束之间找到平衡点。\n- **持续验证**：关键设计决策应通过原型、POC 或评审验证。\n- **政策合规**：政府场景需严格遵守政策法规要求，确保合规安全。\n- **四维度协同**：业务架构、功能架构、数据架构、技术架构需协同一致，相互支撑。\n- **现状驱动**：需求分析需深入行业现状和客户现状，必要时主动向用户获取现状信息或从互联网搜索同类客户共性现状。\n- **思路清晰**：建设思路设计需明确目标、原则、路径、分期，指导后续实施。\n- **架构图生成**：架构设计阶段应生成可视化架构图，使用 `scripts/generate-architecture-diagram.py` 脚本。\n  - 前置要求：安装 Python 依赖 `graphviz`（`pip install graphviz`）\n  - 输入格式：Graphviz DOT 格式（参考 `references/architecture-dimensions.md` 中的模板）\n  - 输出格式：PNG 或 SVG 格式的架构图\n  - 支持类型：业务架构图、功能架构图、数据架构图、技术架构图、流程图\n- **方案类型适配**：不同方案类型对应不同的输出结构和深度要求，参考 `references/solution-type-frames.md` 严格执行框架结构。\n\nFile v1.1.1:_meta.json\n\n{\n  \"ownerId\": \"kn7ae6m5fzwqs7fmdmh97gr1yh82m2py\",\n  \"slug\": \"digital-solution-designer\",\n  \"version\": \"1.1.1\",\n  \"publishedAt\": 1776657096595\n}\n\nFile v1.1.1:Reference/architecture-dimensions.md\n\n# 架构设计维度参考\n\n## 目录\n1. 业务架构设计\n2. 功能架构设计\n3. 数据架构设计\n4. 技术架构设计\n5. 四维度协同关系\n\n## 概览\n本文档提供业务架构、功能架构、数据架构、技术架构四个维度的设计指导，帮助系统化地进行多维度架构设计，确保各维度协同一致、相互支撑。\n\n## 核心内容\n\n### 1. 业务架构设计\n\n业务架构是系统的战略层面设计，描述业务目标、业务流程、业务能力和业务关系，是功能和数据架构设计的基础。\n\n#### 1.1 业务流程梳理\n\n**核心业务流程**：\n- 识别端到端的业务流程（从业务开始到结束）\n- 每个流程包括：触发条件、参与角色、执行步骤、输出结果\n- 示例：电商平台 - 订单流程（浏览 → 下单 → 支付 → 发货 → 确认收货）\n\n**支撑业务流程**：\n- 支撑核心流程的辅助流程\n- 示例：用户管理、商品管理、库存管理\n\n**管理业务流程**：\n- 运营管理流程\n- 示例：运营分析、数据统计、异常处理\n\n**跨部门协同流程**：\n- 涉及多个部门/系统的流程\n- 示例：政务审批、供应链协同\n\n#### 1.2 业务能力识别\n\n**业务能力分类**：\n- **核心能力**：直接支撑业务目标，创造价值\n- **支撑能力**：为核心能力提供支持\n- **管理能力**：管理和监控业务运行\n- **集成能力**：与外部系统交互\n\n**能力识别方法**：\n- 按业务领域划分（电商：商品、订单、支付、物流）\n- 按价值链划分（研发 → 生产 → 销售 → 服务）\n- 按用户角色划分（C端用户、B端用户、运营人员、管理员）\n\n**能力成熟度评估**：\n- 成熟度等级：初始级 → 已定义级 → 已管理级 → 优化级\n- 评估维度：流程标准化、数字化程度、自动化程度\n\n#### 1.3 业务关系设计\n\n**业务实体关系**：\n- 业务对象之间的关系（用户、订单、商品、支付）\n- 关系类型：一对一、一对多、多对多\n\n**业务协作关系**：\n- 业务部门之间的协作\n- 系统之间的协作\n- 角色之间的协作\n\n**数据流转关系**：\n- 数据在业务流程中的流转\n- 数据的采集、存储、处理、应用\n\n**服务提供与消费关系**：\n- 业务能力的提供方和消费方\n- 服务契约和接口\n\n#### 1.4 业务架构输出\n\n**输出文档内容**：\n- 业务架构图（文字描述）\n- 核心业务流程清单\n- 业务能力清单\n- 业务协作模式\n- 业务关系矩阵\n\n**质量检查**：\n- ✅ 业务流程覆盖全面\n- ✅ 业务能力边界清晰\n- ✅ 业务关系逻辑合理\n- ✅ 业务架构支撑业务目标\n\n#### 1.5 业务架构图模板\n\n**Graphviz DOT 格式示例**：\n\n```dot\ndigraph BusinessArchitecture {\n    rankdir=TB;\n    node [shape=box, style=filled, fillcolor=lightblue];\n    edge [fontsize=10];\n\n    // 核心业务领域\n    subgraph cluster_core {\n        label=\"核心业务\";\n        style=dashed;\n        商品管理 [label=\"商品管理\\n- 商品发布\\n- 库存管理\"];\n        订单管理 [label=\"订单管理\\n- 订单创建\\n- 订单处理\"];\n        支付管理 [label=\"支付管理\\n- 在线支付\\n- 退款处理\"];\n        物流管理 [label=\"物流管理\\n- 发货管理\\n- 物流跟踪\"];\n    }\n\n    // 支撑业务领域\n    subgraph cluster_support {\n        label=\"支撑业务\";\n        style=dashed;\n        用户管理 [label=\"用户管理\\n- 用户注册\\n- 权限管理\"];\n        会员管理 [label=\"会员管理\\n- 会员等级\\n- 积分管理\"];\n        营销管理 [label=\"营销管理\\n- 优惠券\\n- 促销活动\"];\n    }\n\n    // 业务流程\n    商品管理 -> 订单管理 [label=\"下单\"];\n    订单管理 -> 支付管理 [label=\"支付\"];\n    支付管理 -> 物流管理 [label=\"发货\"];\n    用户管理 -> 订单管理 [label=\"创建订单\"];\n    用户管理 -> 会员管理 [label=\"会员服务\"];\n    会员管理 -> 营销管理 [label=\"营销活动\"];\n    营销管理 -> 订单管理 [label=\"促销下单\"];\n}\n```\n\n**使用说明**：\n1. 将上述 DOT 格式保存为 `business.dot` 文件\n2. 调用脚本生成架构图：`python scripts/generate-architecture-diagram.py --diagram-type business --input business.dot --output business.png`\n3. 根据实际业务场景调整节点和边的定义\n\n---\n\n### 2. 功能架构设计\n\n功能架构是系统的功能层面设计，描述功能模块、功能层次和功能关系，将业务能力转化为可实现的功能。\n\n#### 2.1 功能模块划分\n\n**按业务领域划分**：\n- 核心业务功能（订单管理、支付管理）\n- 支撑业务功能（用户管理、权限管理）\n- 管理功能（系统管理、数据管理）\n\n**按用户角色划分**：\n- C 端用户功能（注册登录、浏览下单）\n- B 端用户功能（商品管理、订单处理）\n- 运营人员功能（数据分析、营销活动）\n- 管理员功能（系统配置、用户管理）\n\n**按系统层次划分**：\n- 接入层（Web、移动端、API）\n- 业务层（核心业务逻辑）\n- 数据层（数据访问、存储）\n- 基础设施层（监控、日志、配置）\n\n**按业务能力划分**：\n- 每个业务能力对应一组功能模块\n- 示例：订单能力 → 订单创建、订单查询、订单取消、订单统计\n\n#### 2.2 功能层次设计\n\n**核心功能层**：\n- 支撑业务关键流程的功能\n- 示例：商品浏览、下单支付、订单查询\n\n**支撑功能层**：\n- 数据管理（用户管理、商品管理、订单管理）\n- 用户管理（注册登录、身份认证、权限管理）\n- 通知服务（短信、邮件、推送）\n\n**增强功能层**：\n- 数据分析（报表、统计、可视化）\n- 智能推荐（个性化推荐、搜索优化）\n- 营销活动（优惠券、促销、积分）\n\n**集成功能层**：\n- 第三方集成（支付、物流、地图）\n- 系统集成（与现有系统对接）\n- 数据集成（数据导入导出）\n\n#### 2.3 功能关系设计\n\n**功能依赖关系**：\n- 功能之间的依赖（订单依赖用户和商品）\n- 先决条件（下单前需登录、购物车需先加商品）\n\n**功能调用关系**：\n- 模块间的调用关系\n- 同步调用 vs 异步调用\n\n**功能协作关系**：\n- 多个功能协作完成业务流程\n- 示例：下单 → 库存扣减 → 支付 → 发货 → 通知\n\n**功能复用关系**：\n- 公共功能模块（用户认证、权限控制）\n- 基础服务（文件上传、缓存服务）\n\n#### 2.4 功能架构输出\n\n**输出文档内容**：\n- 功能架构图（文字描述）\n- 功能模块清单\n- 功能层次划分\n- 功能关系矩阵\n\n**质量检查**：\n- ✅ 功能模块划分合理\n- ✅ 功能层次清晰\n- ✅ 功能关系明确\n- ✅ 功能架构支撑业务架构\n\n#### 2.5 功能架构图模板\n\n**Graphviz DOT 格式示例**：\n\n```dot\ndigraph FunctionalArchitecture {\n    rankdir=TB;\n    node [shape=box, style=filled];\n    edge [fontsize=10];\n\n    // 核心功能层\n    subgraph cluster_core {\n        label=\"核心功能层\";\n        style=dashed;\n        node [fillcolor=lightgreen];\n        商品浏览 [label=\"商品浏览\\n- 商品列表\\n- 商品详情\\n- 商品搜索\"];\n        下单支付 [label=\"下单支付\\n- 购物车\\n- 下单\\n- 支付\"];\n        订单查询 [label=\"订单查询\\n- 订单列表\\n- 订单详情\\n- 物流跟踪\"];\n    }\n\n    // 支撑功能层\n    subgraph cluster_support {\n        label=\"支撑功能层\";\n        style=dashed;\n        node [fillcolor=lightblue];\n        用户管理 [label=\"用户管理\\n- 注册登录\\n- 个人信息\\n- 地址管理\"];\n        权限管理 [label=\"权限管理\\n- 角色管理\\n- 权限控制\"];\n        通知服务 [label=\"通知服务\\n- 短信通知\\n- 邮件通知\\n- 消息推送\"];\n    }\n\n    // 增强功能层\n    subgraph cluster_enhance {\n        label=\"增强功能层\";\n        style=dashed;\n        node [fillcolor=lightyellow];\n        数据分析 [label=\"数据分析\\n- 报表统计\\n- 数据可视化\"];\n        智能推荐 [label=\"智能推荐\\n- 个性化推荐\\n- 商品推荐\"];\n        营销活动 [label=\"营销活动\\n- 优惠券\\n- 促销活动\"];\n    }\n\n    // 集成功能层\n    subgraph cluster_integration {\n        label=\"集成功能层\";\n        style=dashed;\n        node [fillcolor=lightgray];\n        第三方支付 [label=\"第三方支付\\n- 支付宝\\n- 微信支付\"];\n        物流集成 [label=\"物流集成\\n- 快递公司\\n- 物流查询\"];\n    }\n\n    // 功能层次关系\n    下单支付 -> 第三方支付 [label=\"调用\"];\n    下单支付 -> 物流集成 [label=\"调用\"];\n    用户管理 -> 下单支付 [label=\"支撑\"];\n    权限管理 -> 用户管理 [label=\"控制\"];\n    通知服务 -> 下单支付 [label=\"通知\"];\n    数据分析 -> 订单查询 [label=\"分析\"];\n    智能推荐 -> 商品浏览 [label=\"推荐\"];\n    营销活动 -> 商品浏览 [label=\"展示\"];\n}\n```\n\n---\n\n### 3. 数据架构设计\n\n数据架构是系统的数据层面设计，描述数据模型、数据流、数据标准和数据治理，确保数据的正确性、一致性、安全性和可用性。\n\n#### 3.1 数据模型设计\n\n**核心实体识别**：\n- 业务对象抽象（用户、商品、订单、支付）\n- 实体属性定义\n- 实体关系设计（一对一、一对多、多对多）\n\n**数据类型与约束**：\n- 数据类型选择（字符串、数字、日期、JSON）\n- 数据约束（非空、唯一、范围、格式）\n- 默认值设计\n\n**数据标准化**：\n- 命名规范（表名、字段名、索引名）\n- 编码规范（字典编码、状态码）\n- 格式规范（日期格式、金额格式、坐标格式）\n\n**数据模型层次**：\n- **概念模型**：业务层面的数据抽象\n- **逻辑模型**：系统层面的数据结构\n- **物理模型**：数据库层面的具体实现\n\n#### 3.2 数据流设计\n\n**业务数据流**：\n- 数据在业务流程中的流转\n- 示例：下单 → 订单数据 → 支付数据 → 物流数据 → 完成数据\n\n**系统数据流**：\n- 系统内部的数据流转\n- 示例：Web 层 → 业务层 → 数据层\n\n**跨系统数据流**：\n- 系统间的数据交换\n- 示例：电商平台 → 物流公司 → 用户\n\n**数据采集、存储、处理、应用**：\n- **数据采集**：用户输入、传感器、第三方数据\n- **数据存储**：关系型数据库、NoSQL、数据仓库\n- **数据处理**：ETL、清洗、计算、分析\n- **数据应用**：查询、报表、推荐、预测\n\n#### 3.3 数据标准设计\n\n**数据字典**：\n- 统一的数据术语定义\n- 数据元定义（名称、类型、长度、含义）\n- 数据域定义（数据值域、枚举值）\n\n**数据编码规则**：\n- 主键生成策略（UUID、雪花算法）\n- 业务编码规则（订单号、流水号）\n- 状态码设计（状态机、状态转换）\n\n**数据质量管理标准**：\n- 数据完整性（必填项、唯一性）\n- 数据准确性（数据校验、格式验证）\n- 数据一致性（数据同步、事务管理）\n- 数据及时性（实时、准实时、批处理）\n\n#### 3.4 数据治理设计\n\n**数据分类分级**：\n- **按敏感程度**：公开、受限、敏感、机密\n- **按重要程度**：核心数据、重要数据、一般数据\n- 分类分级标准与策略\n\n**数据安全与隐私保护**：\n- 数据脱敏（手机号、身份证、银行卡号）\n- 数据加密（传输加密、存储加密）\n- 访问控制（权限管理、角色控制）\n- 审计日志（数据访问、数据修改）\n\n**数据生命周期管理**：\n- 数据创建、使用、归档、销毁\n- 保留策略（热数据、温数据、冷数据）\n- 备份与恢复策略\n\n**数据共享与开放**：\n- 数据共享机制（API、ETL、数据交换）\n- 数据开放策略（公开数据、受限数据）\n- 数据使用授权（申请、审批、使用、审计）\n\n#### 3.5 数据架构输出\n\n**输出文档内容**：\n- 数据模型图（文字描述）\n- 数据流图（文字描述）\n- 数据标准规范\n- 数据治理方案\n\n**质量检查**：\n- ✅ 数据模型完整\n- ✅ 数据流清晰\n- ✅ 数据标准统一\n- ✅ 数据治理方案可行\n- ✅ 数据架构支撑功能架构\n\n#### 3.6 数据架构图模板\n\n**Graphviz DOT 格式示例（ER图）**：\n\n```dot\ndigraph DataArchitecture {\n    rankdir=LR;\n    node [shape=ellipse, style=filled, fillcolor=lightyellow];\n    edge [fontsize=10];\n\n    // 实体定义\n    用户 [label=\"用户\\n用户ID\\n用户名\\n密码\\n邮箱\\n手机号\"];\n    商品 [label=\"商品\\n商品ID\\n商品名称\\n价格\\n库存\"];\n    订单 [label=\"订单\\n订单ID\\n用户ID\\n商品ID\\n数量\\n金额\\n状态\"];\n    订单项 [label=\"订单项\\n订单项ID\\n订单ID\\n商品ID\\n数量\\n价格\"];\n    支付 [label=\"支付\\n支付ID\\n订单ID\\n金额\\n支付方式\\n支付状态\"];\n    物流 [label=\"物流\\n物流ID\\n订单ID\\n快递公司\\n运单号\\n物流状态\"];\n\n    // 实体关系\n    用户 -> 订单 [label=\"1:N\\n创建\"];\n    订单 -> 订单项 [label=\"1:N\\n包含\"];\n    商品 -> 订单项 [label=\"1:N\\n关联\"];\n    订单 -> 支付 [label=\"1:1\\n支付\"];\n    订单 -> 物流 [label=\"1:N\\n发货\"];\n\n    // 数据流\n    订单 [shape=box, fillcolor=lightblue, label=\"订单数据\\n- 订单创建\\n- 订单更新\\n- 订单完成\"];\n    支付 [shape=box, fillcolor=lightblue, label=\"支付数据\\n- 支付请求\\n- 支付回调\\n- 退款处理\"];\n    物流 [shape=box, fillcolor=lightblue, label=\"物流数据\\n- 发货通知\\n- 物流跟踪\\n- 签收确认\"];\n}\n```\n\n---\n\n### 4. 技术架构设计\n\n技术架构是系统的技术层面设计，描述部署架构、技术选型、安全架构和集成架构，确保系统的性能、可用性、安全性和可扩展性。\n\n#### 4.1 部署架构\n\n**部署拓扑**：\n- **单机部署**：简单场景、小型系统\n- **集群部署**：高可用、负载均衡\n- **分布式部署**：大规模、高并发\n- **云原生部署**：容器化、微服务、Serverless\n\n**分层架构**：\n- **接入层**：负载均衡、API 网关、CDN\n- **业务层**：应用服务、微服务\n- **数据层**：数据库、缓存、消息队列\n- **基础设施层**：服务器、存储、网络\n\n**容器化与编排**：\n- **容器化**：Docker 容器化应用\n- **编排**：Kubernetes 容器编排\n- **服务网格**：Istio 服务治理\n\n**高可用与容灾设计**：\n- **高可用**：多实例部署、故障自动转移\n- **负载均衡**：Nginx、HAProxy、云负载均衡\n- **容灾备份**：异地多活、灾备切换\n\n#### 4.2 安全架构\n\n**网络安全**：\n- **防火墙**：网络访问控制\n- **WAF**：Web 应用防火墙\n- **DDoS 防护**：分布式拒绝服务攻击防护\n- **VPN**：虚拟专用网络\n\n**应用安全**：\n- **认证授权**：身份认证、权限控制\n- **输入验证**：防止 SQL 注入、XSS 攻击\n- **加密**：传输加密（HTTPS）、数据加密\n- **会话管理**：会话安全、Token 管理\n\n**数据安全**：\n- **传输加密**：SSL/TLS 加密\n- **存储加密**：数据库加密、文件加密\n- **数据脱敏**：敏感数据脱敏\n- **备份加密**：备份数据加密\n\n**运维安全**：\n- **日志审计**：操作日志、访问日志\n- **入侵检测**：异常行为检测、入侵告警\n- **漏洞扫描**：安全漏洞扫描、修复\n- **应急响应**：安全事件应急响应\n\n#### 4.3 集成架构\n\n**API 网关设计**：\n- **统一入口**：API 统一入口\n- **认证授权**：统一认证、权限控制\n- **流量控制**：限流、熔断、降级\n- **协议转换**：HTTP、REST、gRPC\n\n**服务注册与发现**：\n- **注册中心**：服务注册、服务发现\n- **健康检查**：服务健康状态检查\n- **负载均衡**：服务实例负载均衡\n\n**消息队列与事件总线**：\n- **消息队列**：RabbitMQ、Kafka、RocketMQ\n- **事件总线**：事件发布订阅、事件溯源\n- **异步处理**：异步任务、异步通知\n\n**数据交换与同\n\nArchive v1.1.0: 3 files, 9604 bytes\n\nFiles: README.md (19429b), Skill.md (5727b), _meta.json (144b)","readmeExcerpt":"Skill: digital-solution-designer Owner: boboy-j Summary: 系统化设计数字化解决方案，涵盖方案类型识别、政策背景分析、需求分析、建设思路设计、架构设计（业务、功能、数据、技术四维度）、技术选型、具体建设内容、实施规划、风险评估和投资估算的全流程能力。适用于规划类、申报类、可研类、投标类和工作汇报类等多种方案产出场景，覆盖政府数字化转型和企业数字化转型两大核心领域。 Tags: latest:1.2.0 Version history: v1.2.0 | 2026-05-28T07:48:59.336Z | user **Summary:** This version adds extensible reference documents and strengthens process clarity for digital solution design. - Added f","codeSnippets":[],"executableExamples":[{"language":"dot","snippet":"digraph BusinessArchitecture {\n    rankdir=TB;\n    node [shape=box, style=filled, fillcolor=lightblue];\n    edge [fontsize=10];\n\n    // 核心业务领域\n    subgraph cluster_core {\n        label=\"核心业务\";\n        style=dashed;\n        商品管理 [label=\"商品管理\\n- 商品发布\\n- 库存管理\"];\n        订单管理 [label=\"订单管理\\n- 订单创建\\n- 订单处理\"];\n        支付管理 [label=\"支付管理\\n- 在线支付\\n- 退款处理\"];\n        物流管理 [label=\"物流管理\\n- 发货管理\\n- 物流跟踪\"];\n    }\n\n    // 支撑业务领域\n    subgraph cluster_support {\n        label=\"支撑业务\";\n        style=dashed;\n        用户管理 [label=\"用户管理\\n- 用户注册\\n- 权限管理\"];\n        会员管理 [label=\"会员管理\\n- 会员等级\\n- 积分管理\"];\n        营销管理 [label=\"营销管理\\n- 优惠券\\n- 促销活动\"];\n    }\n\n    // 业务流程\n    商品管理 -> 订单管理 [label=\"下单\"];\n    订单管理 -> 支付管理 [label=\"支付\"];\n    支付管理 -> 物流管理 [label=\"发货\"];\n    用户管理 -> 订单管理 [label=\"创建订单\"];\n    用户管理 -> 会员管理 [label=\"会员服务\"];\n    会员管理 -> 营销管理 [label=\"营销活动\"];\n    营销管理 -> 订单管理 [label=\"促销下单\"];\n}"},{"language":"dot","snippet":"digraph FunctionalArchitecture {\n    rankdir=TB;\n    node [shape=box, style=filled];\n    edge [fontsize=10];\n\n    // 核心功能层\n    subgraph cluster_core {\n        label=\"核心功能层\";\n        style=dashed;\n        node [fillcolor=lightgreen];\n        商品浏览 [label=\"商品浏览\\n- 商品列表\\n- 商品详情\\n- 商品搜索\"];\n        下单支付 [label=\"下单支付\\n- 购物车\\n- 下单\\n- 支付\"];\n        订单查询 [label=\"订单查询\\n- 订单列表\\n- 订单详情\\n- 物流跟踪\"];\n    }\n\n    // 支撑功能层\n    subgraph cluster_support {\n        label=\"支撑功能层\";\n        style=dashed;\n        node [fillcolor=lightblue];\n        用户管理 [label=\"用户管理\\n- 注册登录\\n- 个人信息\\n- 地址管理\"];\n        权限管理 [label=\"权限管理\\n- 角色管理\\n- 权限控制\"];\n        通知服务 [label=\"通知服务\\n- 短信通知\\n- 邮件通知\\n- 消息推送\"];\n    }\n\n    // 增强功能层\n    subgraph cluster_enhance {\n        label=\"增强功能层\";\n        style=dashed;\n        node [fillcolor=lightyellow];\n        数据分析 [label=\"数据分析\\n- 报表统计\\n- 数据可视化\"];\n        智能推荐 [label=\"智能推荐\\n- 个性化推荐\\n- 商品推荐\"];\n        营销活动 [label=\"营销活动\\n- 优惠券\\n- 促销活动\"];\n    }\n\n    // 集成功能层\n    subgraph cluster_integration {\n        label=\"集成功能层\";\n        style=dashed;\n        node [fillcolor=lightgray];\n        第三方支付 [label=\"第三方支付\\n- 支付宝\\n- 微信支付\"];\n        物流集成 [label=\"物流集成\\n- 快递公司\\n- 物流查询\"];\n    }\n\n    // 功能层次关系\n    下单支付 -> 第三方支付 [label=\"调用\"];\n    下单支付 -> 物流集成 [label=\"调用\"];\n    用户管理 -> 下单支付 [label=\"支撑\"];\n    权限管理 -> 用户管理 [label=\"控制\"];\n    通知服务 -> 下单支付 [label=\"通知\"];\n    数据分析 -> 订单查询 [label=\"分析\"];\n    智能推荐 -> 商品浏览 [label=\"推荐\"];\n    营销活动 -> 商品浏览 [label=\"展示\"];\n}"},{"language":"dot","snippet":"digraph DataArchitecture {\n    rankdir=LR;\n    node [shape=ellipse, style=filled, fillcolor=lightyellow];\n    edge [fontsize=10];\n\n    // 实体定义\n    用户 [label=\"用户\\n用户ID\\n用户名\\n密码\\n邮箱\\n手机号\"];\n    商品 [label=\"商品\\n商品ID\\n商品名称\\n价格\\n库存\"];\n    订单 [label=\"订单\\n订单ID\\n用户ID\\n商品ID\\n数量\\n金额\\n状态\"];\n    订单项 [label=\"订单项\\n订单项ID\\n订单ID\\n商品ID\\n数量\\n价格\"];\n    支付 [label=\"支付\\n支付ID\\n订单ID\\n金额\\n支付方式\\n支付状态\"];\n    物流 [label=\"物流\\n物流ID\\n订单ID\\n快递公司\\n运单号\\n物流状态\"];\n\n    // 实体关系\n    用户 -> 订单 [label=\"1:N\\n创建\"];\n    订单 -> 订单项 [label=\"1:N\\n包含\"];\n    商品 -> 订单项 [label=\"1:N\\n关联\"];\n    订单 -> 支付 [label=\"1:1\\n支付\"];\n    订单 -> 物流 [label=\"1:N\\n发货\"];\n\n    // 数据流\n    订单 [shape=box, fillcolor=lightblue, label=\"订单数据\\n- 订单创建\\n- 订单更新\\n- 订单完成\"];\n    支付 [shape=box, fillcolor=lightblue, label=\"支付数据\\n- 支付请求\\n- 支付回调\\n- 退款处理\"];\n    物流 [shape=box, fillcolor=lightblue, label=\"物流数据\\n- 发货通知\\n- 物流跟踪\\n- 签收确认\"];\n}"},{"language":"dot","snippet":"digraph TechnicalArchitecture {\n    rankdir=TB;\n    node [shape=box, style=filled];\n    edge [fontsize=10];\n\n    // 接入层\n    subgraph cluster_access {\n        label=\"接入层\";\n        style=dashed;\n        node [fillcolor=lightgreen];\n        CDN [label=\"CDN\\n- 静态资源\\n- 边缘加速\"];\n        负载均衡 [label=\"负载均衡\\n- Nginx\\n- LVS\"];\n        API网关 [label=\"API网关\\n- 认证授权\\n- 流量控制\\n- 协议转换\"];\n    }\n\n    // 业务层\n    subgraph cluster_business {\n        label=\"业务层\";\n        style=dashed;\n        node [fillcolor=lightblue];\n        用户服务 [label=\"用户服务\\n- 用户注册\\n- 登录认证\"];\n        商品服务 [label=\"商品服务\\n- 商品管理\\n- 库存管理\"];\n        订单服务 [label=\"订单服务\\n- 订单创建\\n- 订单处理\"];\n        支付服务 [label=\"支付服务\\n- 支付处理\\n- 退款管理\"];\n    }\n\n    // 数据层\n    subgraph cluster_data {\n        label=\"数据层\";\n        style=dashed;\n        node [fillcolor=lightyellow];\n        MySQL [label=\"MySQL\\n- 关系型数据库\"];\n        Redis [label=\"Redis\\n- 缓存\\n- 会话\"];\n        MongoDB [label=\"MongoDB\\n- 文档数据库\"];\n    }\n\n    // 消息队列\n    subgraph cluster_mq {\n        label=\"消息队列\";\n        style=dashed;\n        node [fillcolor=lightgray];\n        Kafka [label=\"Kafka\\n- 异步消息\\n- 事件驱动\"];\n        RabbitMQ [label=\"RabbitMQ\\n- 消息队列\\n- 延迟队列\"];\n    }\n\n    // 接入层到业务层\n    负载均衡 -> API网关 [label=\"转发\"];\n    API网关 -> 用户服务 [label=\"路由\"];\n    API网关 -> 商品服务 [label=\"路由\"];\n    API网关 -> 订单服务 [label=\"路由\"];\n    API网关 -> 支付服务 [label=\"路由\"];\n\n    // 业务层到数据层\n    用户服务 -> MySQL [label=\"读写\"];\n    商品服务 -> MySQL [label=\"读写\"];\n    商品服务 -> Redis [label=\"缓存\"];\n    订单服务 -> MySQL [label=\"读写\"];\n    订单服务 -> Redis [label=\"缓存\"];\n    支付服务 -> MySQL [label=\"读写\"];\n\n    // 业务层到消息队列\n    订单服务 -> Kafka [label=\"异步\"];\n    支付服务 -> RabbitMQ [label=\"延迟\"];\n    商品服务 -> Kafka [label=\"事件\"];\n\n    // 消息队列到业务层\n    Kafka -> 物流服务 [label=\"消费\"];\n    RabbitMQ -> 订单服务 [label=\"消费\"];\n}"},{"language":"text","snippet":"系统规模？\n├─ 小型（< 5万用户，< 10人团队）\n│  └─ → 单体架构 或 模块化单体\n├─ 中型（5-50万用户，10-30人团队）\n│  ├─ 业务复杂度低？\n│  │  └─ → 模块化单体\n│  └─ 业务复杂度高？\n│     └─ → 考虑早期微服务（从 2-3 个核心服务开始）\n└─ 大型（> 50万用户，> 30人团队）\n   ├─ 领域边界清晰？\n   │  └─ → 微服务架构\n   └─ 领域耦合紧密？\n      └─ → 模块化单体 + 按需演进\n\n需要高实时性和异步处理？\n└─ 是 → 事件驱动架构（可与其他架构组合）\n\n读写操作差异大？\n└─ 是 → 考虑 CQRS\n\n运维资源有限？\n└─ 是 → 单体 或 Serverless"},{"language":"text","snippet":"┌─────────────────────────────────────┐\n│     用户接入层                        │\n│  (政务门户、移动端、自助终端)          │\n└─────────────────────────────────────┘\n              ↓\n┌─────────────────────────────────────┐\n│     API 网关层                        │\n│  (统一入口、认证授权、流量控制)         │\n└─────────────────────────────────────┘\n              ↓\n┌─────────────────────────────────────┐\n│     应用服务层                        │\n│  (各部门业务应用、公共服务组件)        │\n│  多租户隔离：部门 A | 部门 B | ...    │\n└─────────────────────────────────────┘\n              ↓\n┌─────────────────────────────────────┐\n│     数据服务层                        │\n│  (数据共享交换、数据治理、数据仓库)    │\n└─────────────────────────────────────┘\n              ↓\n┌─────────────────────────────────────┐\n│     基础设施层                        │\n│  (计算、存储、网络、安全组件)          │\n└─────────────────────────────────────┘"}],"parameters":null,"dependencies":[],"permissions":[],"extractedFiles":[{"path":"SKILL.md","content":"---\nname: digital-solution-designer\ndescription: 系统化设计数字化解决方案，涵盖方案类型识别、政策背景分析、需求分析、建设思路设计、架构设计（业务、功能、数据、技术四维度）、技术选型、具体建设内容、实施规划、风险评估和投资估算的全流程能力。适用于规划类、申报类、可研类、投标类和工作汇报类等多种方案产出场景，覆盖政府数字化转型和企业数字化转型两大核心领域。\ndependency:\n  python:\n    - graphviz>=0.20.1\n---\n\n# 数字化解决方案设计\n\n## 任务目标\n系统化设计数字化解决方案，从方案类型识别到实施规划的完整流程，支持多种方案类型的结构化输出。\n\n核心能力：方案类型识别、方案大纲生成、政策背景分析与合规识别、结构化需求分析、建设思路设计、四维度架构设计、技术栈选型、建设内容展开、实施规划、风险评估、投资估算。\n\n核心领域：政府数字化转型、企业数字化转型。\n\n触发条件：\"设计[系统/平台/应用]解决方案\"、\"规划[业务场景]数字化方案\"、\"评估[系统]升级方案\"、\"设计[领域]技术架构\"、\"政府数字化转型\"、\"政务系统\"、\"一网通办\"、\"数字政府\"、\"规划方案\"、\"申报方案\"、\"可研方案\"、\"投标方案\"、\"工作汇报\"\n\n## 方案类型说明\n\n### 支持的方案类型\n\n1. **规划类方案**：初次接触客户，粗颗粒度规划，以打动客户为目的\n   - 适用场景：客户初步接触、需求模糊、需要展示整体愿景\n   - 输出重点：政策背景、现状问题、建设目标及思路、业务架构（简化）、关键建设内容、预期效益\n\n2. **申报类方案**：帮助客户向内部领导汇报并申请立项\n   - 适用场景：客户内部汇报、立项申请、预算审批\n   - 输出重点：建设背景、需求分析、建设目标、四维度架构、主要建设内容、实施计划（简化）、效益分析、费用估算\n\n3. **可研类方案**：项目立项审批核心文件，用于财政预算申请和专家评审\n   - 适用场景：项目立项审批、财政预算申请、专家评审\n   - 输出重点：总论、背景与必要性、需求分析、总体建设方案、建设内容、技术方案与选型、实施计划、投资估算、效益分析、风险分析\n\n4. **投标类方案**：响应招标需求，选拔承建厂商\n   - 适用场景：公开招投标、竞争性谈判\n   - 输出重点：需求理解、总体建设方案、详细功能设计、实施与管理、安全与合规、运维服务、培训方案、报价文件\n\n5. **工作汇报类方案**：项目执行过程中的阶段性汇报\n   - 适用场景：项目执行过程汇报、里程碑评审、需求变更汇报\n   - 输出重点：工作背景、问题、当前工作、成果、问题、下一步计划、需要支持\n\n### 方案类型识别规则（强制执行）\n- **第一步：强制询问**：用户输入需求后，**必须先询问**用户此次需要编写方案的类型，不要通过关键词推导或猜测\n- **询问语**：\"请问您需要产出哪种类型的方案？可选择：规划类、申报类、可研类、投标类、工作汇报类\"\n- **第二步：等待用户确认**：待用户明确反馈方案类型后，再根据用户选择的方案类型进行解决方案内容的编写\n- **补充说明**：如果用户不清楚各类型方案的区别，参考 [references/solution-type-frames.md](references/solution-type-frames.md) 为用户说明各类型方案的特点、适用场景和输出重点\n\n参考文档：[references/solution-type-frames.md](references/solution-type-frames.md)\n\n### 方案类型演进关系\n\n五种方案类型存在递进关系，前一类型的产出可复用为后一类型的基础输入：\n- **规划类 → 申报类**：规划类的建设目标和思路可复用为申报类的建设背景和目标章节\n- **申报类 → 可研类**：申报类的架构设计和建设内容可深化为可研类的详细技术方案\n- **可研类 → 投标类**：可研类的技术方案可复用为投标类的总体建设方案，需增加实施管理、运维、培训等响应性内容\n\n复用原则：高阶方案复用低阶方案的核心结论，同时根据新阶段的评审要求深化细化和补充论证。\n\n## 操作步骤\n\n### 第零阶段：方案类型识别与关键信息收集（必执行）\n\n执行步骤：\n1. **强制询问用户方案类型**（关键步骤，不可跳过）：询问语\"请问您需要产出哪种类型的方案？可选择：规划类、申报类、可研类、投标类、工作汇报类\"，若用户不清楚，参考 [references/solution-type-frames.md](references/solution-type-frames.md) 说明各类型方案特点\n2. **等待用户明确反馈方案类型**：用户确认方案类型后，再进行后续流程\n3. **收集关键约束信息**：方案类型确认后，主动向用户收集以下关键信息（若用户未提供，根据已有信息合理推断并标注假设）：\n   - 所属领域：政府/企业，细分行业（如政务、医疗、教育、金融、制造等），参考 [references/industry-scenarios.md](references/industry-scenarios.md) 定位行业场景\n   - 建设规模：预算范围、建设周期、覆盖范围（部门/地域）\n   - 现有基础：现有系统情况、信息化成熟度、技术团队能力\n   - 核心诉求：最需要解决的 1-3 个核心问题\n4. **生成方案大纲**：方案类型和关键信息确认后，参考 [references/solution-type-frames.md](references/solution-type-frames.md) 生成方案大纲（目录结构），向用户展示整体框架并确认，后续按大纲逐章节展开\n5. **根据方案类型和关键信息调整后续流程**：参考\"方案类型与流程映射说明\"选择对应的执行阶段\n检查点：✅ 方案类型已通过询问明确、✅ 关键约束信息已收集、✅ 方案大纲已确认\n\n---\n\n### 方案类型与流程映射说明\n\n**规划类方案**流程：\n- 执行：第零阶段 → 第一阶段 → 第二阶段（简化）→ 第三阶段 → 4.1（业务架构，简化）→ 第六阶段（简化）→ 效益分析\n- 跳过：4.2-4.4、第五阶段、第七阶段（详细版）、第八阶段\n\n**申报类方案**流程：\n- 执行：第零阶段 → 第一阶段 → 第二阶段 → 第三阶段 → 第四阶段 → 第六阶段 → 第七阶段（简化）→ 效益分析 → 费用估算\n- 跳过：第五阶段（详细版）、第八阶段（详细版）\n\n**可研类方案**流程：\n- 执行：全部阶段 + 投资估算（替代费用估算）\n- 重点：需求细化（业务/用户/功能/数据/性能/安全/运维），技术选型详尽（含信创适配）\n\n**投标类方案**流程：\n- 执行：第零阶段 → 第二阶段（需求理解）→ 第三阶段（建设方案）→ 第四阶段（四维度架构）→ 10.1（详细功能设计）→ 10.2（实施与管理）→ 10.3（安全与合规）→ 10.4（运维服务）→ 10.5（培训方案）→ 报"},{"path":"README.md","content":"# 数字化解决方案设计 Skill\n\n本 Skill 用于系统化设计数字化解决方案，涵盖方案类型识别、政策背景分析、需求分析、建设思路设计、架构设计（业务/功能/数据/技术四维度）、技术选型、具体建设内容、实施规划、风险评估和投资估算的全流程能力。支持规划类、申报类、可研类、投标类和工作汇报类等多种方案产出场景，覆盖政府数字化转型和企业数字化转型两大核心领域。\n\n## 任务目标\n\n系统化设计数字化解决方案，从方案类型识别到实施规划的完整流程，支持多种方案类型的结构化输出。\n\n- **核心能力**：方案类型识别、方案大纲生成、政策背景分析与合规识别、结构化需求分析、建设思路设计、四维度架构设计、技术栈选型、建设内容展开、实施规划、风险评估、投资估算\n- **核心领域**：政府数字化转型、企业数字化转型\n- **触发条件**：\"设计[系统/平台/应用]解决方案\"、\"规划[业务场景]数字化方案\"、\"评估[系统]升级方案\"、\"设计[领域]技术架构\"、\"政府数字化转型\"、\"政务系统\"、\"一网通办\"、\"数字政府\"、\"规划方案\"、\"申报方案\"、\"可研方案\"、\"投标方案\"、\"工作汇报\"\n\n## 方案类型说明\n\n### 支持的方案类型\n\n#### 1. 规划类方案\n- **适用场景**：初次接触客户，粗颗粒度规划，以打动客户为目的\n- **输出重点**：政策背景、现状问题、建设目标及思路、业务架构（简化）、关键建设内容、预期效益\n\n#### 2. 申报类方案\n- **适用场景**：客户内部汇报、立项申请、预算审批\n- **输出重点**：建设背景、需求分析、建设目标、四维度架构、主要建设内容、实施计划（简化）、效益分析、费用估算\n\n#### 3. 可研类方案\n- **适用场景**：项目立项审批、财政预算申请、专家评审\n- **输出重点**：总论、背景与必要性、需求分析（细化至业务/用户/功能/数据/性能/安全/运维）、总体建设方案、建设内容、详细技术方案与选型（含信创适配）、实施计划、投资估算、效益分析、风险分析\n\n#### 4. 投标类方案\n- **适用场景**：公开招投标、竞争性谈判\n- **输出重点**：需求理解、总体建设方案、详细功能设计、实施与管理、安全与合规、运维服务、培训方案、报价文件\n\n#### 5. 工作汇报类方案\n- **适用场景**：项目执行过程汇报、里程碑评审、需求变更汇报\n- **输出结构**：工作背景 → 需要解决的问题 → 当前工作及完成情况 → 成果及成效 → 存在问题 → 下一步计划 → 需要领导支持\n\n### 方案类型识别规则（强制执行）\n\n1. **第一步：强制询问**：用户输入需求后，**必须先询问**用户此次需要编写方案的类型，不要通过关键词推导或猜测\n2. **询问语**：\"请问您需要产出哪种类型的方案？可选择：规划类、申报类、可研类、投标类、工作汇报类\"\n3. **第二步：等待用户确认**：待用户明确反馈方案类型后，再根据用户选择的方案类型进行解决方案内容的编写\n4. **补充说明**：如果用户不清楚各类型方案的区别，参考 `references/solution-type-frames.md` 进行说明\n\n### 方案类型演进关系\n\n五种方案类型存在递进关系，前一类型的产出可复用为后一类型的基础输入：\n\n- **规划类 → 申报类**：规划类的建设目标和思路可复用为申报类的建设背景和目标章节\n- **申报类 → 可研类**：申报类的架构设计和建设内容可深化为可研类的详细技术方案\n- **可研类 → 投标类**：可研类的技术方案可复用为投标类的总体建设方案，需增加实施管理、运维、培训等响应性内容\n\n---\n\n## 各阶段详细说明\n\n### 第零阶段：方案类型识别与关键信息收集（必执行）\n\n1. **强制询问用户方案类型**：询问语\"请问您需要产出哪种类型的方案？可选择：规划类、申报类、可研类、投标类、工作汇报类\"，若用户不清楚，参考 `references/solution-type-frames.md` 进行说明\n2. **等待用户明确反馈方案类型**\n3. **收集关键约束信息**：方案类型确认后，主动收集所属领域（政府/企业及细分行业）、建设规模（预算/周期/覆盖范围）、现有基础（系统/信息化程度/团队能力）、核心诉求（1-3个核心问题）\n4. **生成方案大纲**：参考 `references/solution-type-frames.md` 生成目录结构，向用户展示并确认\n5. **根据方案类型和关键信息调整后续流程**\n\n检查点：✅ 方案类型已通过询问明确、✅ 关键约束信息已收集、✅ 方案大纲已确认\n\n### 方案类型与流程映射\n\n| 方案类型 | 执行阶段 | 跳过阶段 |\n|----------|----------|----------|\n| **规划类** | 第零阶段 → 第一阶段 → 第二阶段（简化）→ 第三阶段 → 4.1（业务架构简化）→ 第六阶段（简化）→ 效益分析 | 4.2-4.4、第五阶段、第七阶段（详细）、第八阶段 |\n| **申报类** | 第零阶段 → 第一阶段 → 第二阶段 → 第三阶段 → 第四阶段 → 第六阶段 → 第七阶段（简化）→ 效益分析 → 费用估算 | 第五阶段（详细）、第八阶段（详细） |\n| **可研类** | 全部阶段 + 投资估算（替代费用估算） | — |\n| **投标类** | 第零阶段 → 第二阶段（需求理解）→ 第三阶段（建设方案）→ 第四阶段 → 10.1-10.5 → 报价文件 | 第一阶段、第五阶段（独立）、第八阶段（合并） |\n| **工作汇报类** | 特殊流程：背景 → 问题 → 当前工作 → 成果 → 问题 → 下一步 → 需支持 | 不使用标准流程 |\n\n### 方案质量评审（完成后必执行）\n\n方案编写完成后，必须参照 `references/solution-quality-checklist.md` 进行质量自审：\n\n1. 通用质量标准检查：完整性、一致性、逻辑性、可读性、规范性\n2. 按方案类型执行对应检查清单（规划类8项/申报类9项/可研类11项/投标类10项/工作汇报类8项）\n3. 四维度架构一致性校验（业务↔功能↔数据↔技术映射关系检查）\n4. 未通过项必须补充修改，全部通过后方可交付\n\n---\n\n### 第一阶段：政策背景分析\n\n1. 梳理政策环境（国家/行业/地方/国际政策）\n2. 分析政策影响（指导意义、机遇、约束、趋势）\n3. 识别合规要求（法律法规、行业标准、数据安全、技术标准）\n4. 输出政策分析报告（政策环境、关键解读、合规清单、机遇挑战）\n\n检查点：✅ 政策环境梳理全面、✅ 合规要求识别清晰、✅ 政策影响分析到位\n\n### 第二阶段：需求分析\n\n1. **现状评估**：参考 `references/current-state-assessment.md`，按信息化现状评估框架进行系统盘点\n   - 政府场景：政务系统盘点、一网通办/数据共享/信创/等保/跨部门协同五维评估\n   - 企业场景：数字化成熟度评估（L1-L5五级模型），业务数字化/数"},{"path":"_meta.json","content":"{\n  \"ownerId\": \"kn7ae6m5fzwqs7fmdmh97gr1yh82m2py\",\n  \"slug\": \"digital-solution-designer\",\n  \"version\": \"1.2.0\",\n  \"publishedAt\": 1779954539336\n}"},{"path":"references/architecture-dimensions.md","content":"# 架构设计维度参考\n\n## 目录\n1. 业务架构设计\n2. 功能架构设计\n3. 数据架构设计\n4. 技术架构设计\n5. 四维度协同关系\n\n## 概览\n本文档提供业务架构、功能架构、数据架构、技术架构四个维度的设计指导，帮助系统化地进行多维度架构设计，确保各维度协同一致、相互支撑。\n\n## 核心内容\n\n### 1. 业务架构设计\n\n业务架构是系统的战略层面设计，描述业务目标、业务流程、业务能力和业务关系，是功能和数据架构设计的基础。\n\n#### 1.1 业务流程梳理\n\n**核心业务流程**：\n- 识别端到端的业务流程（从业务开始到结束）\n- 每个流程包括：触发条件、参与角色、执行步骤、输出结果\n- 示例：电商平台 - 订单流程（浏览 → 下单 → 支付 → 发货 → 确认收货）\n\n**支撑业务流程**：\n- 支撑核心流程的辅助流程\n- 示例：用户管理、商品管理、库存管理\n\n**管理业务流程**：\n- 运营管理流程\n- 示例：运营分析、数据统计、异常处理\n\n**跨部门协同流程**：\n- 涉及多个部门/系统的流程\n- 示例：政务审批、供应链协同\n\n#### 1.2 业务能力识别\n\n**业务能力分类**：\n- **核心能力**：直接支撑业务目标，创造价值\n- **支撑能力**：为核心能力提供支持\n- **管理能力**：管理和监控业务运行\n- **集成能力**：与外部系统交互\n\n**能力识别方法**：\n- 按业务领域划分（电商：商品、订单、支付、物流）\n- 按价值链划分（研发 → 生产 → 销售 → 服务）\n- 按用户角色划分（C端用户、B端用户、运营人员、管理员）\n\n**能力成熟度评估**：\n- 成熟度等级：初始级 → 已定义级 → 已管理级 → 优化级\n- 评估维度：流程标准化、数字化程度、自动化程度\n\n#### 1.3 业务关系设计\n\n**业务实体关系**：\n- 业务对象之间的关系（用户、订单、商品、支付）\n- 关系类型：一对一、一对多、多对多\n\n**业务协作关系**：\n- 业务部门之间的协作\n- 系统之间的协作\n- 角色之间的协作\n\n**数据流转关系**：\n- 数据在业务流程中的流转\n- 数据的采集、存储、处理、应用\n\n**服务提供与消费关系**：\n- 业务能力的提供方和消费方\n- 服务契约和接口\n\n#### 1.4 业务架构输出\n\n**输出文档内容**：\n- 业务架构图（文字描述）\n- 核心业务流程清单\n- 业务能力清单\n- 业务协作模式\n- 业务关系矩阵\n\n**质量检查**：\n- ✅ 业务流程覆盖全面\n- ✅ 业务能力边界清晰\n- ✅ 业务关系逻辑合理\n- ✅ 业务架构支撑业务目标\n\n#### 1.5 业务架构图模板\n\n**Graphviz DOT 格式示例**：\n\n```dot\ndigraph BusinessArchitecture {\n    rankdir=TB;\n    node [shape=box, style=filled, fillcolor=lightblue];\n    edge [fontsize=10];\n\n    // 核心业务领域\n    subgraph cluster_core {\n        label=\"核心业务\";\n        style=dashed;\n        商品管理 [label=\"商品管理\\n- 商品发布\\n- 库存管理\"];\n        订单管理 [label=\"订单管理\\n- 订单创建\\n- 订单处理\"];\n        支付管理 [label=\"支付管理\\n- 在线支付\\n- 退款处理\"];\n        物流管理 [label=\"物流管理\\n- 发货管理\\n- 物流跟踪\"];\n    }\n\n    // 支撑业务领域\n    subgraph cluster_support {\n        label=\"支撑业务\";\n        style=dashed;\n        用户管理 [label=\"用户管理\\n- 用户注册\\n- 权限管理\"];\n        会员管理 [label=\"会员管理\\n- 会员等级\\n- 积分管理\"];\n        营销管理 [label=\"营销管理\\n- 优惠券\\n- 促销活动\"];\n    }\n\n    // 业务流程\n    商品管理 -> 订单管理 [label=\"下单\"];\n    订单管理 -> 支付管理 [label=\"支付\"];\n    支付管理 -> 物流管理 [label=\"发货\"];\n    用户管理 -> 订单管理 [label=\"创建订单\"];\n    用户管理 -> 会员管理 [label=\"会员服务\"];\n    会员管理 -> 营销管理 [label=\"营销活动\"];\n    营销管理 -> 订单管理 [label=\"促销下单\"];\n}\n```\n\n**使用说明**：\n1. 将上述 DOT 格式保存为 `business.dot` 文件\n2. 调用脚本生成架构图：`python scripts/generate-architecture-diagram.py --diagram-type business --input business.dot --output business.png`\n3. 根据实际业务场景调整节点和边的定义\n\n---\n\n### 2. 功能架构设计\n\n功能架构是系统的功能层面设计，描述功能模块、功能层次和功能关系，将业务能力转化为可实现的功能。\n\n#### 2.1 功能模块划分\n\n**按业务领域划分**：\n- 核心业务功能（订单管理、支付管理）\n- 支撑业务功能（用户管理、权限管理）\n- 管理功能（系统管理、数据管理）\n\n**按用户角色划分**：\n- C 端用户功能（注册登录、浏览下单）\n- B 端用户功能（商品管理、订单处理）\n- 运营人员功能（数据分析、营销活动）\n- 管理员功能（系统配置、用户管理）\n\n**按系统层次划分**：\n- 接入层（Web、移动端、API）\n- 业务层（核心业务逻辑）\n- 数据层（数据访问、存储）\n- 基础设施层（监控、日志、配置）\n\n**按业务能力划分**：\n- 每个业务能力对应一组功能模块\n- 示例：订单能力 → 订单创建、订单查询、订单取消、订单统计\n\n#### 2.2 功能层次设计\n\n**核心功能层**：\n- 支撑业务关键流程的功能\n- 示例：商品浏览、下单支付、订单查询\n\n**支撑功能层**：\n- 数据管理（用户管理、商品管理、订单管理）\n- 用户管理（注册登录、身份认证、权限管理）\n- 通知服务（短信、邮件、推送）\n\n**增强功能层**：\n- 数据分析（报表、统计、可视化）\n- 智能推荐（个性化推荐、搜索优化）\n- 营销活动（优惠券、促销、积分）\n\n**集成功能层**：\n- 第三方集成（支付、物流、地图）\n- 系统集成（与现有系统对接）\n- 数据集成（数据导入导出）\n\n#### 2.3 功能关系设计\n\n**功能依赖关系**：\n- 功能之间的依赖（订单依赖用户和商品）\n- 先决条件（下单前需登录、购物车需先加商品）\n\n**功能调用关系**：\n- 模块间的调用关系\n- 同步"},{"path":"references/architecture-patterns.md","content":"# 架构模式参考\n\n## 目录\n1. 单体架构\n2. 模块化单体\n3. 微服务架构\n4. 事件驱动架构\n5. 分层架构\n6. CQRS（命令查询职责分离）\n7. Serverless 架构\n8. 模式选择指南\n\n## 概览\n本文档提供常见的软件架构模式，包括其特点、适用场景和权衡考虑，用于指导架构设计决策。\n\n## 核心内容\n\n### 1. 单体架构（Monolithic）\n\n**特点**：\n- 整个应用作为单一部署单元\n- 共享数据库和代码库\n- 调用方式为内存函数调用\n\n**适用场景**：\n- 初创项目快速验证\n- 小型团队（< 10人）\n- 业务逻辑相对简单\n- 预期用户规模有限\n\n**优势**：\n- 开发简单，部署容易\n- 调试和测试方便\n- 无需复杂的服务间通信\n- 初期开发速度快\n\n**劣势**：\n- 扩展性受限（只能整体扩展）\n- 技术栈统一，灵活性低\n- 代码耦合度高，维护成本随规模增长\n- 故障影响范围大\n\n---\n\n### 2. 模块化单体（Modular Monolith）\n\n**特点**：\n- 仍是单一部署单元\n- 代码按模块组织，模块间通过明确接口交互\n- 强调内部边界和依赖管理\n\n**适用场景**：\n- 需要良好结构的中型项目\n- 团队规模 5-20人\n- 未来可能拆分为微服务的过渡阶段\n\n**优势**：\n- 保持单体部署的简单性\n- 代码组织清晰，降低耦合\n- 为未来微服务化做准备\n- 比传统单体更易维护\n\n**劣势**：\n- 仍受限于整体部署\n- 模块边界管理需要良好纪律\n- 跨模块变更仍需整体测试\n\n---\n\n### 3. 微服务架构（Microservices）\n\n**特点**：\n- 系统拆分为多个独立服务\n- 每个服务独立部署和扩展\n- 服务间通过 API（HTTP/RPC/gRPC）通信\n- 数据库通常独立（每个服务自己的数据库）\n\n**适用场景**：\n- 大型复杂系统\n- 多团队协作开发\n- 需要独立扩展不同模块\n- 业务领域边界清晰\n\n**优势**：\n- 独立部署和扩展\n- 技术栈灵活\n- 故障隔离\n- 团队自治\n\n**劣势**：\n- 分布式系统复杂度高\n- 服务间通信开销\n- 数据一致性挑战\n- 运维和监控复杂\n- 初期开发成本高\n\n**关键实践**：\n- 领域驱动设计（DDD）划分边界\n- API 网关统一入口\n- 服务注册与发现\n- 分布式追踪\n- 容错机制（熔断、降级）\n\n---\n\n### 4. 事件驱动架构（Event-Driven）\n\n**特点**：\n- 通过事件驱动业务流程\n- 松耦合的组件通过事件总线通信\n- 支持异步处理和实时响应\n\n**适用场景**：\n- 需要高实时性的系统\n- 多系统集成场景\n- 复杂业务流程编排\n- 需要高扩展性的异步任务\n\n**优势**：\n- 松耦合，易扩展\n- 异步处理提高吞吐量\n- 天然支持审计和溯源\n- 易于集成外部系统\n\n**劣势**：\n- 流程追踪困难\n- 事件Schema 管理复杂\n- 错误处理和重试机制复杂\n- 最终一致性的挑战\n\n**关键组件**：\n- 事件总线（消息队列：Kafka、RabbitMQ）\n- 事件存储\n- 事件溯源（Event Sourcing）\n- CQRS（命令查询分离）\n\n---\n\n### 5. 分层架构（Layered）\n\n**特点**：\n- 按职责分为不同层次\n- 常见分层：表现层 → 业务层 → 持久层 → 数据库\n- 严格依赖方向（上层依赖下层，下层不依赖上层）\n\n**适用场景**：\n- 几乎所有传统企业应用\n- 需要清晰职责分离的系统\n- 团队熟悉传统开发模式\n\n**优势**：\n- 结构清晰，易于理解\n- 职责分离，便于测试\n- 开发模式成熟\n- 易于维护\n\n**劣势**：\n- 可能过度设计\n- 层次间调用可能带来性能损耗\n- 不适合所有场景（如纯 API 服务）\n\n---\n\n### 6. CQRS（命令查询职责分离）\n\n**特点**：\n- 读写操作分离\n- 写操作（命令）使用领域模型\n- 读操作（查询）使用优化的数据模型\n- 可能使用不同的存储（写用关系数据库，读用 NoSQL）\n\n**适用场景**：\n- 读写差异大的系统（读多写少）\n- 复杂业务逻辑的写操作\n- 需要高性能的复杂查询\n- 事件驱动架构的读模型\n\n**优势**：\n- 读写性能独立优化\n- 复杂业务逻辑不影响查询性能\n- 易于扩展读端\n- 与事件溯源结合良好\n\n**劣势**：\n- 增加系统复杂度\n- 数据同步问题（最终一致性）\n- 不适合所有场景（读写简单的系统）\n\n---\n\n### 7. Serverless 架构\n\n**特点**：\n- 无需管理服务器\n- 函数即服务（FaaS）\n- 按执行时间和资源付费\n- 自动弹性伸缩\n\n**适用场景**：\n- 波动性大的工作负载\n- 事件驱动的短任务\n- 快速原型和实验项目\n- 无状态的服务\n\n**优势**：\n- 无需运维服务器\n- 自动弹性伸缩\n- 按量付费，成本灵活\n- 快速部署\n\n**劣势**：\n- 冷启动延迟\n- 厂商锁定风险\n- 调试和监控困难\n- 不适合长时间运行的任务\n- 状态管理复杂\n\n---\n\n## 模式选择指南\n\n### 决策树\n\n```\n系统规模？\n├─ 小型（< 5万用户，< 10人团队）\n│  └─ → 单体架构 或 模块化单体\n├─ 中型（5-50万用户，10-30人团队）\n│  ├─ 业务复杂度低？\n│  │  └─ → 模块化单体\n│  └─ 业务复杂度高？\n│     └─ → 考虑早期微服务（从 2-3 个核心服务开始）\n└─ 大型（> 50万用户，> 30人团队）\n   ├─ 领域边界清晰？\n   │  └─ → 微服务架构\n   └─ 领域耦合紧密？\n      └─ → 模块化单体 + 按需演进\n\n需要高实时性和异步处理？\n└─ 是 → 事件驱动架构（可与其他架构组合）\n\n读写操作差异大？\n└─ 是 → 考虑 CQRS\n\n运维资源有限？\n└─ 是 → 单体 或 Serverless\n```\n\n### 权衡考虑\n\n**复杂度 vs 收益**：\n- 微服务带来复杂度，只在需要时采用\n- 单体架构简单但扩展性受限\n- 避免为了微服务而微服务\n\n**团队能力**：\n- 微服务需要成熟的 DevOps 能力\n- 新团队从单体开始，逐步演进\n- 技术选型考虑团队熟悉度\n\n**业务需求**：\n- 业务快速变化？→ 模块化单体或微服务\n- 需要独立扩展？→ 微服务\n- 高实时性？→ 事件驱动\n- 成本敏感？→ Serverless\n\n**演进策略**：\n- 从单体开始\n- 随着需求增长拆分\n- 按领域边界拆分微服务\n- 避免\"大爆炸\"重构\n\n## 示例\n\n### 示例 1：电商平台\n- **推荐架构**：微服务 + 事件驱动\n- **原因**：业务复杂度高，需要独立扩展，多团队协作\n- **核心服务**：用户服务、商品服务、订单服务、支付服务、库存服务\n- **事件流**：下单 → 库存扣减 → 支付 → 物流 → 通知\n\n### 示例 2：内容管理系统（CMS）\n- **推荐架构**：模块化单体\n- **原因**：业务相"}],"languages":[],"docsSourceLabel":"CLAWHUB","editorialOverview":"系统化设计数字化解决方案，涵盖方案类型识别、政策背景分析、需求分析、建设思路设计、架构设计（业务、功能、数据、技术四维度）、技术选型、具体建设内容、实施规划、风险评估和投资估算的全流程能力。适用于规划类、申报类、可研类、投标类和工作汇报类等多种方案产出场景，覆盖政府数字化转型和企业数字化转型两大核心领域。 Skill: digital-solution-designer Owner: boboy-j Summary: 系统化设计数字化解决方案，涵盖方案类型识别、政策背景分析、需求分析、建设思路设计、架构设计（业务、功能、数据、技术四维度）、技术选型、具体建设内容、实施规划、风险评估和投资估算的全流程能力。适用于规划类、申报类、可研类、投标类和工作汇报类等多种方案产出场景，覆盖政府数字化转型和企业数字化转型两大核心领域。 Tags: latest:1.2.0 Version history: v1.2.0 | 2026-05-28T07:48:59.336Z | user **Summary:** This version adds extensible reference documents and strengthens process clarity for digital solution design. - Added f","editorialQuality":{"score":100,"threshold":65,"status":"ready","wordCount":774,"uniquenessScore":57,"reasons":[]}},"media":{"evidence":{"source":"no-media","verified":false,"confidence":"low","updatedAt":"2026-10-10T14:22:56.233Z","emptyReason":"No screenshots, media assets, or demo links are available."},"primaryImageUrl":null,"mediaAssetCount":0,"assets":[],"demoUrl":null},"ownerResources":{"evidence":{"source":"unclaimed","verified":false,"confidence":"low","updatedAt":"2026-10-10T14:22:56.233Z","emptyReason":"This page has not been claimed by the agent owner."},"hasCustomPage":false,"customPageUpdatedAt":null,"customLinks":[],"structuredLinks":{"docsUrl":null,"demoUrl":null,"supportUrl":null,"pricingUrl":null,"statusUrl":null},"customPage":null},"relatedAgents":{"evidence":{"source":"protocol-neighbors","verified":false,"confidence":"medium","updatedAt":"2026-10-10T17:34:50.858Z","emptyReason":null},"items":[{"id":"8ebccd8e-3863-4187-8355-c3f14e1f9edf","entityType":"agent","canonicalPath":"/agent/iofficeai-aionui","slug":"iofficeai-aionui","name":"AionUi","description":"Free, local, open-source 24/7 Cowork app and OpenClaw for Gemini CLI, Claude Code, Codex, OpenCode, Qwen Code, Goose CLI, Auggie, and more | 🌟 Star if you like it!","url":"https://github.com/iOfficeAI/AionUi","homepage":"https://www.aionui.com","source":"GITHUB_REPOS","protocols":["MCP","OPENCLAW"],"capabilities":[],"safetyScore":100,"overallRank":70,"updatedAt":"2026-10-09T19:11:12.944Z","createdAt":"2026-02-25T03:38:16.584Z","downloads":null},{"id":"b917f68a-ebff-438e-84f8-3f4b2494c0bc","entityType":"agent","canonicalPath":"/agent/activepieces-activepieces","slug":"activepieces-activepieces","name":"activepieces","description":"AI Agents & MCPs & AI Workflow Automation • (~400 MCP servers for AI agents) • AI Automation / AI Agent with MCPs • AI Workflows & AI Agents • MCPs for AI Agents","url":"https://github.com/activepieces/activepieces","homepage":"https://www.activepieces.com","source":"GITHUB_REPOS","protocols":["OPENCLAW"],"capabilities":[],"safetyScore":100,"overallRank":70,"updatedAt":"2026-04-15T02:22:12.426Z","createdAt":"2026-02-25T03:38:12.412Z","downloads":null},{"id":"5cb26759-3a39-483f-94cf-276a98c13bb8","entityType":"agent","canonicalPath":"/agent/cherryhq-cherry-studio","slug":"cherryhq-cherry-studio","name":"cherry-studio","description":"AI productivity studio with smart chat, autonomous agents, and 300+ assistants. Unified access to frontier LLMs","url":"https://github.com/CherryHQ/cherry-studio","homepage":"https://cherry-ai.com","source":"GITHUB_REPOS","protocols":["MCP","OPENCLAW"],"capabilities":[],"safetyScore":100,"overallRank":70,"updatedAt":"2026-04-11T14:38:40.986Z","createdAt":"2026-02-25T03:38:19.379Z","downloads":null},{"id":"6f6582d0-5d76-4f0f-b81d-86520247950b","entityType":"agent","canonicalPath":"/agent/copilotkit-copilotkit","slug":"copilotkit-copilotkit","name":"CopilotKit","description":"The Frontend for Agents & Generative UI. React + Angular","url":"https://github.com/CopilotKit/CopilotKit","homepage":"https://docs.copilotkit.ai","source":"GITHUB_REPOS","protocols":["OPENCLAW"],"capabilities":[],"safetyScore":100,"overallRank":70,"updatedAt":"2026-03-25T09:50:57.846Z","createdAt":"2026-02-25T03:39:14.617Z","downloads":null}],"links":{"hub":"/agent","source":"/agent/source/clawhub","protocols":[{"label":"OpenClaw","href":"/agent/protocol/openclew"}]}}}