当前位置：首页 > news >正文

CLAUDE.md：打造AI编程助手的个性化上下文配置文件

news 2026/8/7 16:01:25

1. 项目概述：告别重复劳动，让AI编程助手记住你的习惯

如果你和我一样，日常重度依赖Claude Code这类AI编程助手来写代码、调试或者重构项目，那你肯定也经历过这种“甜蜜的烦恼”：每次开启一个新的对话窗口，都得从头开始解释一遍你的项目结构、编码规范、技术栈偏好，甚至是你个人独特的命名习惯。这感觉就像每次雇佣一个顶级程序员，都得先花半小时给他做入职培训，效率大打折扣。

“一份 CLAUDE.md，让 Claude Code 不再每次从零开始”这个想法，正是为了解决这个痛点。它的核心思路，是创建一个标准化的、可复用的“上下文配置文件”——我称之为CLAUDE.md。这个文件本质上是一个高度结构化的提示词（Prompt）工程实践，它提前封装了你希望Claude Code了解的所有背景信息、规则和偏好。每次开始新的编码任务时，你只需简单地说一句“请参考附带的CLAUDE.md文件”，或者直接将文件内容粘贴到对话开头，就能瞬间为AI助手注入“记忆”，让它从一个完全了解你工作环境和习惯的“老搭档”身份开始协作，而不是一个需要从头教起的“新人”。

这不仅仅是节省了几次打字的时间。更深层的价值在于，它极大地提升了AI助手输出结果的一致性和准确性。当Claude Code清晰地知道你的项目使用TypeScript而非JavaScript、遵循Airbnb的代码规范、数据库表名采用蛇形命名法、API响应有特定的封装格式时，它生成的代码、建议的修改、甚至发现的潜在问题，都会更贴合你的实际需求，减少后续人工调整的工作量。对于团队协作而言，一份共享的CLAUDE.md更能统一代码风格，降低沟通成本。接下来，我将详细拆解如何从零开始构建一份高效、全面的CLAUDE.md，分享我在实际使用中总结的结构设计、内容要点以及那些能显著提升效果的“魔法指令”。

2. CLAUDE.md 的核心结构与设计哲学

一份好的CLAUDE.md不是信息的简单堆砌，而是一份经过精心设计的、面向AI的“产品说明书”。它的结构需要兼顾逻辑清晰度和AI的理解能力。经过多次迭代，我总结出一个高效的四层结构，它遵循从宏观到微观、从静态规则到动态上下文的递进逻辑。

2.1 项目元数据与全局设定层

这是文件的“身份证”和“总纲”，旨在用最精炼的语言让AI第一时间把握项目的全貌。这一部分必须放在最开头，并且信息要绝对准确。

核心内容应包括：

项目名称与简介：用一两句话说明这个项目是做什么的。例如：“E-Commerce Backend API：一个基于Node.js和Express的B2C电商平台后端服务，提供用户管理、商品目录、订单处理和支付集成。”

技术栈清单：明确列出主要使用的语言、框架、库和其版本。这对于AI选择正确的语法和API至关重要。格式建议采用列表。

- **运行时/语言**: Node.js v18+, TypeScript v5+ - **Web框架**: Express.js v4.18+ - **数据库/ORM**: PostgreSQL v15, Prisma ORM v5 - **身份验证**: JWT (jsonwebtoken), bcrypt - **测试框架**: Jest, Supertest - **代码风格**: ESLint (Airbnb配置), Prettier

核心编码规范：在这里声明最高优先级的规则。比如：“本项目强制使用TypeScript，禁止使用any类型。所有异步操作必须使用async/await，避免回调地狱。导出一律使用ES6 Module的export语法。”

注意：这一层的信息要力求稳定，避免频繁变动。它是AI建立对项目基础认知的锚点。

2.2 代码风格与约定层

这一层是“法律条文”，定义了代码看起来应该是什么样子。AI在生成代码片段、函数或组件时，会严格遵守这里的约定。

你需要细化的方面有：

命名规范：这是最容易产生不一致的地方。必须明确：
- 变量/函数：是使用camelCase（如getUserProfile）还是snake_case（如get_user_profile）？
- 类/类型/接口：PascalCase（如UserController）。
- 常量：全大写SCREAMING_SNAKE_CASE（如API_BASE_URL）。
- 私有成员：是否需要前缀下划线_privateMethod？

文件与目录结构：给出一个典型的项目布局示例，帮助AI理解在哪里创建新文件。

src/ ├── controllers/ # 路由控制器 ├── services/ # 业务逻辑 ├── models/ # 数据模型（Prisma schema定义在此） ├── utils/ # 工具函数 ├── middleware/ # 自定义中间件 └── app.ts # 应用入口

语法与格式偏好：
- 字符串使用单引号''还是双引号""？
- 行末是否需要分号？
- 缩进是2个空格还是4个空格？
- if/else、函数参数的大括号换行风格是怎样的？

实操心得：与其自己一条条写，不如直接引用你项目中已有的配置文件。例如：“代码风格完全遵循项目根目录下的.eslintrc.js和.prettierrc配置。请优先使生成的代码通过ESLint检查。” 这样既准确又省力。

2.3 架构模式与业务逻辑层

这一层是“设计图纸”，告诉AI你的代码是如何组织和工作。这对于生成符合项目架构的复杂逻辑至关重要。

设计模式与架构：说明项目采用的主要模式。例如：“本项目采用分层架构（Controller-Service-Repository）。Controller只负责处理HTTP请求和响应；Service包含核心业务逻辑；Repository（由Prisma Client实现）负责数据访问。禁止在Controller中直接编写数据库查询。”
通用业务规则：列举一些跨模块的规则。比如：“所有货币计算均以‘分’为单位存储为整数，在显示时转换为‘元’。所有时间戳均存储为UTC时间，在前端按需转换为本地时间。”

API响应规范：定义一个统一的成功/错误响应格式。AI在生成Controller代码时会自动套用。

// 成功响应格式示例 interface ApiResponse<T> { code: number; // 200, 201等 data: T; message: string; } // 错误响应格式示例 interface ApiError { code: number; // 400, 404, 500等 error: string; details?: any; }

安全与校验基线：强调必须遵守的安全实践。“所有用户输入必须经过验证（使用Joi或Zod）。涉及数据库查询时，必须使用参数化查询或ORM方法以防止SQL注入。敏感配置（如数据库URL、JWT密钥）必须从环境变量读取。”

2.4 动态上下文与任务指令层

这一层是“本次任务简报”，它可以是CLAUDE.md文件末尾的固定部分，也可以是根据每次任务临时添加的。它提供了当前工作的具体上下文。

当前焦点文件：“你正在编辑src/services/payment.service.ts。请勿修改其他无关文件。”
相关依赖：“本次修改涉及与src/models/order.model.ts和src/utils/logger.ts的交互。”
待实现的功能描述：“需要在PaymentService中增加一个refundOrder方法，处理订单退款逻辑，包括调用支付网关API、更新订单状态、记录退款流水。”
约束条件：“由于与第三方网关的交互是异步的，请确保方法健壮，包含重试机制和详细的错误日志。”

设计哲学总结：CLAUDE.md的设计遵循“静态基础 + 动态上下文”的原则。前三层（元数据、风格、架构）相对稳定，构成文件的主体；第四层（动态上下文）则可以根据每次对话的具体任务进行更新和强调。这样的结构既保证了核心信息的一致性，又保留了应对具体任务的灵活性。

3. 内容填充：从通用模板到个性化精炼

有了结构骨架，下一步就是填充血肉。你可以从一个通用模板开始，但关键在于将其打磨成高度契合你个人或团队工作流的个性化文档。

3.1 从基础模板入手

对于新手，可以从一个覆盖常见方面的基础模板开始。下面是一个针对全栈JavaScript/TypeScript项目的简化示例：

# CLAUDE.md - 项目上下文配置 ## 项目概览 - **名称**: [你的项目名] - **描述**: [一两句话描述] - **仓库**: [Git仓库地址，可选] ## 技术栈 - **语言**: TypeScript 5.x (严格模式) - **运行时**: Node.js 18+ - **前端框架**: React 18 (函数组件 + Hooks) - **状态管理**: Zustand - **构建工具**: Vite - **样式方案**: Tailwind CSS - **后端框架**: Express.js - **数据库**: PostgreSQL + Prisma ORM - **代码质量**: ESLint (Airbnb规则), Prettier, Husky ## 代码风格与约定 - **命名**: - 变量/函数: `camelCase` - 类/组件/类型: `PascalCase` - 常量: `UPPER_SNAKE_CASE` - 私有成员: 前缀下划线 `_private` - **文件组织**: - `src/components/`: 可复用UI组件 - `src/pages/`: 页面组件 - `src/hooks/`: 自定义Hooks - `src/lib/`: 第三方库初始化/配置 - `src/styles/`: 全局样式 - **语法**: - 使用单引号 `'` - 行末不加分号 (由Prettier统一处理) - 缩进: 2个空格 - 优先使用 `const` 和 `let`，避免 `var` ## 架构与模式 - **前端**: 函数式组件，逻辑与视图分离。复杂状态使用Zustand，简单状态使用useState。 - **后端**: RESTful API设计，分层架构 (Controller -> Service -> Repository)。 - **API响应**: 统一使用 `{ success: boolean, data: any, message?: string }` 格式。 - **错误处理**: 使用异步中间件进行集中错误捕获和日志记录。 ## 当前任务上下文 <!-- 每次开始新对话时，更新此部分 --> - **当前工作目录**: `src/components/checkout/` - **任务目标**: 创建一个 `PaymentForm` 组件，集成Stripe Elements。 - **相关文件**: `src/hooks/useStripe.ts`, `src/lib/stripe-client.ts` - **注意事项**: 表单需包含客户端验证，提交时显示加载状态。

3.2 个性化精炼的关键点

模板只是起点，真正的威力在于个性化。你需要根据实际项目中的“痛点”进行增补。

补充“潜规则”：那些不会写在官方文档里，但团队内部默认遵守的规则。例如：
- “工具函数必须放在src/utils/下，并且每个文件只导出一个主要功能，以方便Tree Shaking。”
- “在React组件中，如果useEffect的依赖数组超过5项，必须考虑是否应该拆分逻辑或使用自定义Hook。”
- “所有数据库模型字段，如果表示‘是否删除’，统一命名为is_deleted，类型为boolean，默认值false。”

加入“反面案例”：直接告诉AI不要做什么，有时比告诉它要做什么更有效。可以设立一个“禁忌”章节。

## 禁止与避免 - 🚫 禁止在组件内部直接定义样式对象，应使用Tailwind CSS类或CSS Modules。 - 🚫 避免在`map`循环中直接使用索引`index`作为React组件的`key`，应使用唯一业务ID。 - 🚫 禁止在Service层直接返回数据库模型完整对象，必须定义并返回特定的DTO（Data Transfer Object）。 - 🚫 避免使用`console.log`进行调试，应使用配置好的日志工具（如Winston）。

集成常用代码片段：对于一些反复使用的代码模式，可以直接给出最佳实践示例。

## 常用模式示例 ### API Service 调用模板 ```typescript async function fetchWithAuth<T>(endpoint: string, options: RequestInit = {}): Promise<T> { const token = localStorage.getItem('auth_token'); const response = await fetch(`${API_BASE}${endpoint}`, { ...options, headers: { 'Content-Type': 'application/json', 'Authorization': `Bearer ${token}`, ...options.headers, }, }); if (!response.ok) { throw new Error(`HTTP ${response.status}: ${await response.text()}`); } return response.json() as Promise<T>; }

（请在实际CLAUDE.md中使用正确的代码块标记）

实操心得：维护CLAUDE.md本身也是一个迭代过程。我习惯在遇到AI生成的结果不符合预期时，不是简单地手动修改代码，而是反思：“是不是我的CLAUDE.md里缺少了某条规则？” 然后将其补充进去。久而久之，这份文件就会变得越来越“聪明”，能提前规避掉很多常见问题。

4. 高级技巧：提升CLAUDE.md的“智能”程度

要让CLAUDE.md从一份“静态文档”升级为一个“智能协作伙伴”，还需要运用一些提示词工程的高级技巧。

4.1 角色扮演与人格设定

为AI赋予一个具体的“角色”，可以极大地引导其行为模式。在CLAUDE.md的开头就明确这一点。

# CLAUDE.md ## AI助手角色设定 你是一位经验丰富、注重细节的**高级全栈开发工程师**，也是本项目核心成员之一。你深谙本项目的技术栈、架构设计和团队规范。你的代码以**健壮性、可读性和高性能**著称。在提供解决方案时，你总是会： 1. **优先考虑现有项目结构**，避免引入不必要的依赖或重复造轮子。 2. **主动识别潜在风险**，如边界条件、错误处理和性能瓶颈。 3. **提供解释**，对于复杂的逻辑或非常规做法，简要说明原因。 4. **追求优雅实现**，在满足需求的前提下，提供你认为更简洁、更现代的方案。 ## 交互风格 - 回答直接、专业，聚焦于代码和技术方案。 - 当需求模糊时，会主动询问澄清，而不是猜测。 - 在给出长篇代码后，附上关键点的简要说明。

这个设定能促使AI更主动地思考，而不仅仅是机械地执行指令。

4.2 定义清晰的输出格式与流程

明确你希望AI以何种形式交付结果，尤其是在处理复杂任务时。这能节省大量整理和重构的时间。

## 任务处理流程与输出要求 当你被要求实现一个功能或修改代码时，请按以下步骤进行： 1. **分析与规划**：首先，简要分析需求，并说明你的实现思路，包括可能涉及的文件和关键点。 2. **代码变更**：然后，提供完整的、可直接复制粘贴的代码块。如果是修改现有文件，请使用清晰的差分格式或明确指出修改位置。 3. **变更总结**：最后，用列表形式总结你所做的所有更改，并说明理由。 4. **后续建议**：如果适用，提出测试建议、需要注意的边界情况，或后续优化方向。 **示例输出结构**： 【分析】... 【代码】... 【总结】... 【建议】...

4.3 利用“链式思考”处理复杂逻辑

对于特别复杂的算法或业务逻辑，可以在CLAUDE.md中要求AI展示其思考过程。这不仅能验证其思路是否正确，也能成为一份宝贵的设计文档。

## 复杂逻辑处理规范 当遇到涉及多步骤状态转换、复杂算法或性能优化的任务时： 1. 请先用简单的文字或伪代码描述你的核心算法思路。 2. 评估时间/空间复杂度。 3. 考虑是否有更优的替代方案。 4. 然后再给出最终的实现代码。

4.4 创建领域特定的CLAUDE.md

如果你同时维护多个不同类型的项目（例如一个Web后端、一个数据科学脚本库、一个浏览器扩展），为每个领域创建专门的CLAUDE.md是更高效的做法。

CLAUDE.backend.md：侧重API设计、数据库优化、安全、并发处理。
CLAUDE.data-science.md：侧重Pandas/NumPy操作规范、可视化图表标准、实验可复现性设置（如随机种子）。
CLAUDE.chrome-extension.md：侧重Manifest V3规范、Content Script与Background Service Worker的通信模式、存储API的使用。

你可以根据启动对话时的项目类型，快速引入对应的配置文件。

5. 实战：CLAUDE.md在典型场景中的应用与调优

理论说得再多，不如看几个实际例子。下面我将通过两个常见场景，展示一份成熟的CLAUDE.md如何发挥作用，以及如何根据反馈进行调优。

5.1 场景一：修复一个复杂的Bug

初始指令（没有CLAUDE.md）：“用户报告说，在购物车页面，有时点击‘结算’按钮没反应。帮我看看怎么回事。”

AI的典型反应：可能会要求你提供购物车页面的代码、浏览器控制台错误信息、网络请求详情等。你需要进行多轮交互来提供上下文。

使用CLAUDE.md后的指令：“请参考附带的CLAUDE.md。当前任务是：诊断src/pages/cart/index.tsx中‘结算’按钮偶尔无响应的Bug。相关文件可能涉及src/hooks/useCart.ts和src/utils/checkout.ts。”

AI的增强反应：由于CLAUDE.md已经定义了技术栈（如React、Zustand）、代码规范、以及可能的状态管理逻辑，AI会直接以一个“知情者”的身份开始工作。它可能会立刻给出假设：“根据项目规范，状态更新应是不可变的。请检查useCarthook 中的submitOrder函数，是否在异步操作中错误地直接修改了状态，导致React的渲染时机问题？另外，查看checkout.ts中的支付函数是否有未处理的Promise拒绝。” 它甚至能直接给出添加错误边界或更完善loading状态的具体代码建议。

调优点：如果AI多次在状态管理方面给出模糊建议，你可以在CLAUDE.md的“架构”部分强化：“本项目使用Zustand进行状态管理。任何状态更新都必须通过set函数完成。对于异步操作，推荐使用useCallback包装动作函数，并在组件内通过useStorehook 调用。”

5.2 场景二：实现一个新功能模块

初始指令：“给系统加一个用户消息通知中心。”

AI的典型反应：生成一个非常通用的通知组件，可能使用简单的useState来管理消息列表，样式也很基础。

使用CLAUDE.md后的指令：“请参考CLAUDE.md。实现一个用户消息通知中心。需求：支持成功、错误、警告、信息四种类型；消息可手动关闭或4秒后自动消失；同时最多显示3条；消息列表状态需要持久化到Zustand Store中，以便跨组件访问。”

AI的增强反应：
1. 分析规划：AI会结合CLAUDE.md中关于Zustand、Tailwind CSS、组件目录结构的约定，提出方案：“将在src/components/common/下创建NotificationCenter.tsx（展示组件）和Notification.tsx（单条通知）。在src/store/下创建useNotificationStore.ts来管理消息队列的 Zustand Store。”
2. 生成代码：生成的useNotificationStore.ts会严格遵循你在CLAUDE.md中定义的Zustand模式（包括create函数、状态与动作的分离）。Notification.tsx会使用你指定的Tailwind CSS类来定义不同消息类型的样式（如bg-green-100 text-green-800表示成功）。
3. 符合规范：生成的组件会是函数式组件，使用TypeScript明确定义NotificationType枚举和Notification接口。它会自动考虑在useEffect中清理定时器，避免内存泄漏。

调优点：如果发现AI生成的持久化逻辑过于简单（比如只存到内存），你可以在CLAUDE.md的“业务逻辑层”补充：“对于需要持久化的用户界面状态（如通知已读未读），优先考虑使用Zustand与persist中间件，将数据保存到localStorage。对于关键业务状态，则需通过API与后端同步。”

5.3 场景三：代码审查与重构建议

你甚至可以将CLAUDE.md用作代码审查的“检查清单”。把一段现有代码丢给AI，并说：“请以本项目CLAUDE.md中定义的规范为准，审查以下代码，指出不符合约定的地方，并提供重构建议。”

AI会逐条比对，指出诸如“变量命名未采用camelCase”、“API响应未封装为标准格式”、“缺少必要的错误类型定义”等问题，并直接给出符合规范的修改后代码。这相当于拥有了一位7x24小时在线的、完全熟悉你团队规范的资深代码审查员。

6. 维护、版本管理与团队协作

一份CLAUDE.md如果不维护，很快就会过时。将其纳入你的开发流程至关重要。

6.1 将CLAUDE.md纳入版本控制

这是最基本也最重要的一步。将CLAUDE.md文件放在项目根目录，并提交到Git仓库中。这带来了几个好处：

历史追溯：可以查看规范的演变过程。
团队共享：新成员 onboarding 时，除了看代码，阅读CLAUDE.md能让他们最快速度理解项目脉络和团队习惯。
一致性保证：确保所有开发者（包括AI）都基于同一份最新规范工作。

6.2 建立更新机制

触发时机：当项目技术栈升级（如React 17升18）、引入新的重要工具库、或者团队经过讨论决定修改某项编码规范时，都应更新CLAUDE.md。
谁负责更新：可以指定专人（如Tech Lead）维护，或者采用“谁触发变更，谁更新文档”的原则。
更新日志：在文件顶部或尾部维护一个简单的## Changelog章节，记录重大变更和日期，方便团队成员跟进。

6.3 在团队中推广使用

对于团队协作，一份统一的CLAUDE.md价值巨大。

标准化引入：在团队内部明确，与Claude Code等AI助手协作时，优先使用共享的CLAUDE.md作为上下文。
作为培训材料：对于新加入的开发者，CLAUDE.md是最好的项目速成指南。让他们先通读此文件，再阅读代码，事半功倍。
减少争议：当对代码风格有分歧时（比如尾随逗号加不加），不再需要争论，直接引用CLAUDE.md中的规定即可。

实操心得：在我们的团队中，我们将CLAUDE.md的阅读和遵守写进了开发规范。在Code Review中，如果发现提交的代码明显违反了CLAUDE.md中的规则（而这些规则本可以通过AI生成时避免），Reviewer会直接指出并建议开发者在下一次使用AI时更有效地利用该文件。这形成了一个正向循环：文件越完善，AI产出质量越高，代码一致性越好，团队效率也越高。

7. 常见问题与效果优化实录

在实际使用CLAUDE.md的过程中，你可能会遇到一些问题或觉得效果未达预期。以下是我总结的一些常见情况及优化策略。

7.1 问题：AI似乎“忽略”了CLAUDE.md中的某些规则

可能原因1：规则冲突或过于模糊。AI在处理复杂、矛盾的指令时可能会困惑。
- 排查与解决：检查你的CLAUDE.md。是否有一条规则说“使用单引号”，但另一处示例代码中却使用了双引号？规则是否像“保持代码简洁”这样难以量化？将规则具体化、可操作化。将“保持代码简洁”改为“每个函数行数尽量不超过30行，若超过应考虑拆分”。
可能原因2：规则位于文件太靠后的位置。
- 排查与解决：AI语言模型对提示词开头部分的注意力更高。确保最核心、最重要的规则（如技术栈、核心命名规范）放在文件的前三分之一处。可以将文件结构优化为“核心摘要 -> 详细展开”的形式。
可能原因3：当前对话上下文过长，早期信息被“遗忘”。
- 排查与解决：在超长对话中，如果需要重新强调某个规则，可以温和地提醒：“请再次回忆我们在CLAUDE.md中关于API响应格式的约定，并确保接下来的代码遵循它。” 对于极其复杂的任务，考虑开启一个新对话并重新导入CLAUDE.md。

7.2 问题：CLAUDE.md文件变得太长，难以维护

优化策略：模块化拆分。
- 创建一个主CLAUDE.md文件，只包含最顶层的项目概览、技术栈和指向其他详细文件的链接。
- 将详细内容拆分到独立文件：
  - CLAUDE.CODE_STYLE.md：专用于代码风格、命名、格式化。
  - CLAUDE.ARCHITECTURE.md：专用于架构模式、设计模式、目录结构。
  - CLAUDE.API_SPEC.md：专用于API设计规范、错误码、DTO定义。
- 在需要时，可以组合引用。例如：“请参考主CLAUDE.md以及CLAUDE.API_SPEC.md中的第3节。”

7.3 问题：针对非常具体的、一次性的任务，每次都去翻看大段CLAUDE.md效率低

优化策略：使用“对话预热”提示词。
- 将你最常用的、最核心的规则提炼成一段100-200字的“超级浓缩版”提示词，保存在记事本中。
- 每次开始新对话时，先粘贴这段浓缩提示词，然后再发送具体任务指令。
- 浓缩提示词示例：“你是本项目资深开发者。项目用TS+React+Zustand+Tailwind。规范：函数组件+Hooks，camelCase命名，状态用Zustand store，UI用Tailwind类，API响应格式为{success, data, message}。现在请处理以下任务：[你的具体任务]”

7.4 效果优化：如何评估CLAUDE.md的质量？

一个高质量的CLAUDE.md应该能让你和AI的对话变得非常“顺滑”。你可以通过以下几个指标来评估和优化它：

减少澄清性问答轮次：在引入CLAUDE.md后，AI因为缺少上下文而反问“你们用的是什么框架？”、“代码风格是怎样的？”这类问题的次数应该显著减少，甚至为零。
提高代码“开箱即用”率：AI生成的代码，无需或仅需极少量修改，就能直接融入你的项目，通过ESLint检查，并符合你的视觉预期。
生成代码具有“项目特色”：AI生成的代码看起来就像是你或你的团队成员写的一样，带有你们项目特有的工具函数、组件封装和逻辑处理习惯。

如果在某次协作后你不得不进行大量修改，不要只修改代码，花两分钟思考一下：能否在CLAUDE.md中增加或修改一条规则，让AI下次避免同样的问题？这个过程，其实就是将你的开发经验和最佳实践不断“灌输”给AI的过程。

最终，CLAUDE.md不仅仅是一个配置文件，它成为了你个人或团队开发智慧的结晶和延伸。它让AI编程助手从一个需要反复指导的“实习生”，成长为一个深度理解项目脉络、能够高效产出合规代码的“高级工程师”。投入时间去精心打造和维护它，所带来的长期效率提升和代码质量保障，绝对是物超所值的。

查看全文

http://www.cnnetsun.cn/news/3893005.html