1. 项目概述一个为AI编程助手“赋能”的文档自动化工具如果你和我一样是个在多个项目间穿梭、既要写代码又要维护文档的开发者那你一定对“文档债”深恶痛绝。代码写完了功能上线了但更新API文档、记录变更日志、补写需求说明这些“收尾工作”总是被无限期拖延。最后要么是文档和代码严重脱节要么是花大半天时间手动整理效率极低。最近我在GitHub上发现了一个名为dev-docs-skill的项目它精准地戳中了这个痛点。这本质上是一个为Cursor IDE和Claude Code这类AI编程助手设计的“技能包”。它的核心思路非常巧妙既然我们已经在用AI助手写代码了为什么不把文档工作也交给它实现从代码到文档的自动化流水线这个工具能帮你自动生成标准化的需求文档PRD、维护API接口文档并在每次代码提交后像记账一样自动更新CHANGELOG。它不是另一个需要你手动调用的独立工具而是直接嵌入到你日常的AI编程对话中在你完成开发、提到“生成文档”的瞬间AI助手就能理解你的意图并调用它完成一系列文档工作。简单来说dev-docs-skill扮演了“AI助手的文档秘书”角色。它通过一套Python脚本和标准化的模板将零散、临时的文档任务变成了可预测、可重复的自动化流程。无论你是独立开发者还是团队协作它都能显著降低文档维护的心智负担让“代码即文档”的理想更近一步。接下来我将带你深入拆解这个工具的设计思路、核心实现并分享如何将它无缝集成到你的开发工作流中。2. 核心设计思路与架构解析2.1 为什么是“Skill”而不是独立工具这是理解dev-docs-skill价值的关键。市面上不乏优秀的文档生成工具如 Swagger、JSDoc、Doxygen 等但它们大多是“独立运行”或“构建时集成”的。你需要离开编码上下文切换到另一个命令行或界面去操作。而Skill模式是当前AI编程助手如Cursor、Claude Code生态中一种新兴的扩展方式。Skill可以理解为AI助手的“插件”或“技能”。当Skill被正确安装后AI助手在与你对话时就能“理解”并“调用”这个技能背后的逻辑。比如当你对Cursor说“帮我为刚写的用户登录接口生成API文档”Cursor在理解你的自然语言指令后会自动触发dev-docs-skill执行分析代码、套用模板、生成文档等一系列操作并将结果直接反馈给你。这种设计的优势显而易见上下文无缝衔接AI助手清楚你当前在编辑哪个文件、修改了哪些代码Skill可以直接利用这些上下文信息生成高度相关的文档。自然交互你不需要记忆复杂的命令参数用日常说话的方式就能驱动自动化流程。降低使用门槛Skill的安装和配置对用户是透明的一旦设置好后续使用几乎无感。dev-docs-skill选择为Cursor和Claude Code这两个主流AI IDE开发Skill是极具前瞻性的。它瞄准了未来“对话式编程”的工作流将文档维护这种繁琐任务变成了与AI助手自然对话的一部分。2.2 文档体系的三支柱PRD、API与CHANGELOG工具的核心功能围绕三类最核心、也最需要持续维护的文档展开构成了一个完整的项目文档生命周期闭环。1. 需求文档PRD自动化传统的PRD撰写耗时费力且容易与最终实现产生偏差。dev-docs-skill的做法是提供标准化的Markdown模板。当你完成一个功能模块的开发后可以通过Skill或脚本快速生成一个包含“文档信息”、“功能概述”、“背景目标”、“功能需求”、“非功能需求”、“UI/交互设计”、“数据模型”、“验收标准”、“时间节点”等章节的PRD骨架。这个骨架不是空的它会尝试从你的代码变更和Git提交信息中提取功能名称、涉及的文件等信息预填进去。开发者需要做的是在这个结构良好的骨架上补充业务细节这比从零开始撰写效率高得多也保证了团队内PRD格式的统一。2. API文档的增量维护API文档最怕“过期”。dev-docs-skill采用了一种务实的“变更记录”策略。它并不试图完全自动生成完整的API描述这需要复杂的代码解析而是专注于维护一个API_CHANGELOG.md文件。当你新增、修改、废弃或移除一个接口时运行一条简单的命令如python scripts/update_docs.py api -t add -e POST /api/users -d 创建用户工具就会在API变更日志中按日期和版本记录下这次操作。同时你需要手动维护主API.md文件中的接口详情。这种“变更日志主文档”的组合既能清晰追踪API的演进历史又不过度依赖不可靠的自动推断实用性很强。3. CHANGELOG的规范化管理遵循 Keep a Changelog 规范已经是现代开源项目的标配。但手动维护依然麻烦。dev-docs-skill将CHANGELOG的更新彻底命令行化。你可以通过指定类型 (added,changed,fixed,removed,deprecated) 和描述信息快速添加条目。工具会自动处理日期、版本归类如“Unreleased”部分确保格式始终规范统一。这解决了开发者常常忘记或懒得去更新CHANGELOG的问题。注意这个工具的核心价值不在于“全自动生成完美文档”而在于“将文档维护流程标准化和自动化”。它把需要创造力的部分业务逻辑描述留给人把重复、繁琐、格式化的部分创建文件、维护日志、更新目录交给机器。这是一种非常务实的人机协作思路。2.3 底层实现基于Git的变更分析与模板引擎为了实现上述功能dev-docs-skill的底层主要依赖两个Python脚本analyze_changes.py这是工具的“感知”模块。它通过调用git diff、git log等命令分析代码仓库的变更情况。它可以告诉你自上次提交以来哪些文件被修改、新增或删除并尝试对这些变更进行简要的归类如“似乎是用户认证相关功能”。这份分析报告会成为生成PRD或更新CHANGELOG的重要输入让AI助手或开发者能基于具体的代码变更来撰写文档而不是凭空想象。update_docs.py这是工具的“执行”模块。它集成了多个子命令init,changelog,api,req分别对应初始化、更新CHANGELOG、记录API变更、生成需求文档。它的核心是一个模板引擎根据不同的命令和参数将预定义的Markdown模板与用户输入的信息如功能名、描述、变更类型相结合生成或更新对应的文档文件。例如changelog子命令会读取现有的CHANGELOG.md在“Unreleased”章节下按照规范格式插入新的条目。这种架构清晰地将“分析”和“执行”分离使得每个脚本职责单一易于维护和扩展。同时所有文档都以纯Markdown格式存储最大程度地保证了兼容性和可读性你可以用任何文本编辑器或文档平台查看它们。3. 详细安装与多平台配置指南3.1 环境前置检查与依赖安装无论你选择哪种使用方式都需要确保本地环境满足基本要求。Python环境工具脚本由Python编写需要Python 3.7或更高版本。在终端运行python --version或python3 --version检查。如果未安装建议从 python.org 下载安装并确保将Python添加到系统PATH中。Git由于工具重度依赖Git来分析代码变更所以Git是必须的。在终端运行git --version检查。如果未安装请前往 git-scm.com 下载安装。安装项目依赖克隆项目仓库后建议在项目目录下安装所需的Python包。虽然核心脚本可能只依赖标准库但查看requirements.txt是个好习惯。# 克隆项目 git clone https://github.com/lilyjem/dev-docs-skill.git cd dev-docs-skill # 安装依赖如果有的话 pip install -r requirements.txt通常这类工具为了保持轻量会尽量使用Python标准库如subprocess调用gitargparse处理命令行参数datetime处理日期所以很可能requirements.txt是空的或者非常简单。安装依赖这步主要是为了确保未来可能添加的第三方库能正常工作。3.2 作为Cursor IDE Skill安装全项目自动触发Cursor是目前最流行的AI编程IDE之一其Skill系统允许深度集成自定义工具。安装步骤找到你的Cursor技能目录。这个目录通常位于用户主目录下的.cursor文件夹中。macOS/Linux:~/.cursor/skills/Windows:C:\Users\你的用户名\.cursor\skills\如果skills文件夹不存在手动创建它。将dev-docs-skill整个文件夹复制到skills目录下。为了清晰可以将其重命名为dev-docs。# 假设你在 dev-docs-skill 的父目录 cp -r dev-docs-skill ~/.cursor/skills/dev-docs重启Cursor IDE。这是关键一步Cursor需要在启动时加载新的Skill。验证与使用 安装成功后你无需任何特殊操作。当你与Cursor的AI助手对话时如果提到与文档相关的关键词如“生成文档”、“更新CHANGELOG”、“写个PRD”Cursor会自动识别并调用这个Skill。你可以观察AI的回复它会表明正在使用dev-docs技能并开始执行相应的文档生成步骤。实操心得Cursor的Skill触发有时依赖于AI对上下文的理解。如果第一次没有触发可以尝试更明确的指令如“请使用dev-docs技能为我生成当前功能的API文档”。一旦触发成功后续相似指令的识别会变得更准确。3.3 作为Claude Code Skill安装个人与项目级Claude Code是Anthropic推出的AI编程工具其Skill系统设计得非常灵活支持个人和项目两种作用域。个人级别安装推荐 将Skill安装到用户全局目录这样你打开任何项目Claude Code都能使用这个技能。# 1. 创建个人技能目录 mkdir -p ~/.claude/skills/dev-docs # 2. 复制核心文件 # 进入你克隆的 dev-docs-skill 目录 cp SKILL.md ~/.claude/skills/dev-docs/ cp -r scripts ~/.claude/skills/dev-docs/安装后在Claude Code的任何项目中你都可以通过输入/dev-docs后跟指令来手动调用或者在对话中提及相关关键词时由AI自动触发。项目级别安装 如果你希望某个技能只对特定项目生效或者想将技能配置纳入项目的版本控制以便团队所有成员共享可以采用项目级安装。# 在项目的根目录下执行 mkdir -p .claude/skills/dev-docs cp /path/to/dev-docs-skill/SKILL.md .claude/skills/dev-docs/ cp -r /path/to/dev-docs-skill/scripts .claude/skills/dev-docs/ # 将其加入.gitignore可选如果不想提交或提交到Git仓库 git add .claude/skills/ git commit -m chore: add dev-docs skill for project项目级安装的优先级高于个人级。当你在该项目中时Claude Code会使用项目内的Skill定义。Claude Code Skill调用方式自动触发与Cursor类似在对话中提到“生成文档”、“更新CHANGELOG”等。手动调用在聊天框中输入/dev-docs命令后面跟上你的具体需求例如/dev-docs 为刚刚实现的用户注册模块生成需求文档 /dev-docs 记录一个API变更POST /api/v1/articles 新增了tags字段3.4 作为独立命令行工具使用如果你不使用Cursor或Claude Code或者希望在CI/CD流水线、脚本中集成文档自动化功能那么直接使用其Python脚本是最直接的方式。部署脚本 将scripts文件夹复制到你的项目根目录下。cp -r /path/to/dev-docs-skill/scripts /your/project/root/现在你就可以在你的项目目录下直接运行python scripts/update_docs.py ...或python scripts/analyze_changes.py ...来使用所有功能。这种方式赋予了最大的灵活性你可以将其与Makefile、npm scripts或Git hooks结合使用。4. 核心工作流与实战操作详解安装配置好后关键在于如何将其融入日常开发。下面我以几个典型场景拆解每一步的操作和背后的意图。4.1 场景一开发一个新功能模块后的完整文档闭环假设你刚完成一个“用户积分系统”的开发现在需要生成全套文档。第一步初始化文档结构如果首次使用在项目根目录运行python scripts/update_docs.py init这个命令会创建标准的docs/目录结构里面包含了CHANGELOG.md、api/和requirements/子目录。这一步只需在整个项目开始时做一次。它确保了文档存放位置的规范性为后续自动化操作提供了基础。第二步分析代码变更获取上下文在提交代码前运行python scripts/analyze_changes.py或者为了获得更结构化的输出方便后续处理python scripts/analyze_changes.py --json这个命令会扫描所有未提交的Git变更git diff HEAD并输出一份报告。报告会列出修改的文件并尝试概括变更内容例如“修改了user_service.py似乎与用户积分计算相关”。这个步骤的目的是让你和AI助手对本次开发的影响范围有一个清晰的、基于代码的认知这是撰写准确文档的前提。你可以把这份报告作为撰写PRD的输入材料。第三步生成需求文档PRD骨架基于上一步的分析生成PRD模板文件python scripts/update_docs.py req -n user-points -t 用户积分系统 -a 你的名字-n user-points: 指定功能标识符会生成文件REQ-user-points.md。-t “用户积分系统”: 指定功能标题。-a “你的名字”: 指定作者。执行后会在docs/requirements/下生成一个Markdown文件。这个文件已经填充了文档编号、版本、创建日期、作者以及“功能概述”、“背景和目标”等章节的标题。你的任务就是打开这个文件根据实际开发情况填充每个章节的具体内容。模板的存在极大地减少了格式调整的时间让你能专注于内容本身。第四步更新CHANGELOG记录这个新功能python scripts/update_docs.py changelog -t added -m “新增用户积分系统支持积分获取、消耗和等级计算”-t added: 表示类型为“新增功能”。-m “...”: 提供清晰的描述。这条命令会优雅地更新docs/CHANGELOG.md文件。它会确保条目被添加到正确的版本区块通常是“Unreleased”下并遵循[Added]的标签格式。从此你再也不需要手动调整CHANGELOG的日期和格式了。第五步如果涉及API更新API文档假设积分系统新增了一个查询用户积分详情的接口python scripts/update_docs.py api -t add -e “GET /api/v1/users/{id}/points” -d “获取指定用户的积分明细与等级信息”这条命令会更新docs/api/API_CHANGELOG.md记录这个新增的API端点。注意主API文档docs/api/API.md通常需要手动维护因为其中包含详细的请求/响应示例、参数说明等复杂内容。API_CHANGELOG.md的作用是提供一个可靠的变更历史记录。第六步提交所有更改最后将代码和生成的文档一并提交到Git。git add . git commit -m “feat: 新增用户积分系统” git push至此一个功能从开发到文档归档的完整流程就结束了。整个过程半自动化关键节点都有工具辅助确保了文档的及时性和一致性。4.2 场景二修复Bug或进行小范围优化对于Bug修复或小型重构文档工作的重点在于更新CHANGELOG。操作流程修复代码并测试通过。运行CHANGELOG更新命令# 修复了一个Bug python scripts/update_docs.py changelog -t fixed -m “修复积分过期后未清零的问题” # 或者优化了某个功能 python scripts/update_docs.py changelog -t changed -m “优化积分计算查询响应时间降低约30%”提交更改。git add . git commit -m “fix: 修复积分过期逻辑”这个简单的流程确保了即使是最小的变更也能在项目历史中留下清晰的、可追溯的记录。这对于团队协作和后续的问题排查至关重要。4.3 场景三与AI助手协同工作以Cursor为例这才是dev-docs-skill最“魔法”的用法。安装好Skill后你可以在Cursor中尝试以下对话你“我刚写完了payment模块的代码它包含了新的支付接口和更新了订单状态机。帮我生成相关的文档。”Cursor AI识别到“生成文档”关键词触发dev-docs技能 “好的我来帮你为payment模块生成文档。首先分析一下你的代码变更...自动在后台运行analyze_changes.py 发现主要修改了payment_service.py和order_model.py新增了POST /api/payments接口。现在创建需求文档骨架...自动运行update_docs.py req -n payment -t “支付模块” 文档已创建在docs/requirements/REQ-payment.md请补充具体业务逻辑。更新CHANGELOG记录新增功能...自动运行 update_docs.py changelog -t added -m “新增支付模块支持微信支付和支付宝”更新API变更日志记录新接口...自动运行 update_docs.py api -t add -e “POST /api/payments” -d “发起支付请求”完成。我已更新了相关文档文件并给出了后续手动补充的建议。”在这个过程中你只需要用自然语言提出需求AI助手就能理解意图并串联起多个脚本命令完成一系列文档任务。这极大地提升了开发体验让文档工作从“负担”变成了“顺带手”的事情。5. 脚本原理、自定义与高级技巧5.1analyze_changes.py是如何工作的这个脚本的核心是调用Git命令获取差异信息。我们来看一下它可能的核心逻辑基于常见实践推断# 伪代码/逻辑示意 import subprocess import json import sys def analyze_git_changes(since_commitNone): # 构建 git diff 命令 if since_commit: cmd [git, diff, --name-status, since_commit, HEAD] else: cmd [git, diff, --name-status, HEAD] # 比较工作区和最新提交 # 执行命令并获取输出 result subprocess.run(cmd, capture_outputTrue, textTrue) changed_files result.stdout.strip().split(\n) analysis [] for line in changed_files: if not line: continue # 行格式类似于M src/services/user.py status, file_path line.split(\t) # 根据文件路径和状态进行简单分析 category guess_category(file_path, status) analysis.append({ file: file_path, status: status, # M修改, A新增, D删除 category: category # 如 api, model, config }) return analysis def guess_category(file_path, status): # 简单的基于路径关键词的归类 if api/ in file_path or controller in file_path: return api elif model in file_path or schema in file_path: return data-model elif test in file_path: return test else: return other脚本还可能结合git log --oneline获取提交信息以提供更丰富的上下文。--json参数就是将这个分析列表转换成JSON格式输出便于其他程序如AI助手解析使用。5.2update_docs.py的模板引擎与文件操作这个脚本是文档生成的核心。它通常包含以下几个关键函数update_changelog(change_type, message):读取打开现有的CHANGELOG.md。解析找到“Unreleased”章节或当前版本章节。这通常通过正则表达式匹配## [Unreleased]或## [X.Y.Z]来实现。插入在对应的章节下按照[ChangeType]的格式插入新的条目。如果该类型如[Added]已存在则追加到其列表末尾如果不存在则创建新的子章节。写入将更新后的内容写回文件。这里需要小心处理确保不破坏文件的其他部分。generate_prd_template(feature_id, title, author):模板加载从内置字符串或外部模板文件加载PRD的Markdown模板。变量替换将模板中的占位符如{{FEATURE_ID}},{{TITLE}},{{DATE}},{{AUTHOR}}替换为传入的参数和当前日期。文件创建在docs/requirements/目录下创建REQ-{feature_id}.md文件并写入填充好的内容。record_api_change(change_type, endpoint, description):与更新CHANGELOG逻辑类似但目标是API_CHANGELOG.md文件。它会记录端点、变更类型、描述和日期。避坑技巧这些脚本在修改文件时最好采用“读-改-写”的原子操作并考虑文件锁或备份机制防止在并发操作虽然不常见或脚本意外中断时损坏原文件。一个稳健的做法是先将原文件内容读入内存在内存中完成所有修改最后一次性写入。写入前可以先写到一个临时文件确认无误后再替换原文件。5.3 如何自定义文档模板dev-docs-skill的默认模板可能不完全符合你团队的习惯。自定义模板是深度集成的关键。找到模板位置模板通常直接硬编码在update_docs.py脚本的字符串变量中或者以单独的.j2(Jinja2)、.md.tpl文件形式存放在脚本目录。你需要查看脚本源码来定位。修改PRD模板假设你想在PRD中增加“性能指标”和“监控告警”两个章节。你需要找到生成PRD的函数如_generate_prd_content。修改其内部的模板字符串在“非功能需求”和“验收标准”之间插入你的新章节。确保模板语法正确如果是Jinja2或占位符逻辑无误。修改CHANGELOG格式如果你想遵循自己公司的CHANGELOG格式例如要求每条记录都关联JIRA任务号你需要修改update_changelog函数相关的逻辑在写入条目时格式化为你需要的样式。自定义API文档结构虽然主API文档API.md需要手动维护但你可以创建自己的脚本或扩展现有脚本根据项目中的注释如OpenAPI/Swagger注释或特定的代码结构自动生成更丰富的API文档初稿然后结合dev-docs-skill的变更记录功能。5.4 集成到CI/CD流水线为了让文档自动化更进一步可以将其集成到Git钩子或CI/CD流程中。使用Git钩子如pre-commit 你可以创建一个pre-commit钩子在每次提交前自动分析变更并提示开发者更新CHANGELOG。但这需要谨慎因为自动修改工作区文件可能会引起冲突。一个更温和的方式是使用prepare-commit-msg钩子在默认的提交信息模板中附带上本次analyze_changes.py的输出提醒开发者补充详细的变更描述。集成到CI流程如GitHub Actions 你可以在GitHub Actions的工作流中增加一个步骤在每次向主分支合并Pull Request时自动运行脚本检查文档的完整性。例如检查本次PR修改的代码文件。如果修改了src/api/下的文件则检查docs/api/API_CHANGELOG.md是否也有相应的更新记录。如果没有则CI失败并给出提示。这能强制团队养成“代码变文档随”的好习惯。6. 常见问题、排查与效能提升6.1 安装后Skill不触发怎么办这是使用AI助手Skill时最常见的问题。排查步骤确认安装位置首先检查文件是否复制到了正确的目录。对于Cursor是~/.cursor/skills/dev-docs/并且目录下必须有SKILL.md文件。对于Claude Code根据个人级或项目级安装检查对应路径。重启IDE安装Skill后必须完全关闭并重新启动Cursor或Claude Code。大多数IDE只在启动时加载技能列表。检查Skill文件打开SKILL.md文件确保其格式正确。这个文件通常包含Skill的名称、描述、触发关键词和调用指令。如果文件损坏或格式错误AI助手可能无法识别。使用明确指令尝试使用更明确的触发词。对于Cursor/Claude Code直接说“请使用dev-docs技能”或输入“/dev-docs”。如果手动调用有效而自动触发无效可能是AI对自然语言的识别问题可以尝试在对话中更清晰地表达意图。查看AI回复有时AI会解释它为什么没有触发某个Skill例如“我没有找到相关技能”或“我不确定你的意思”。根据提示进行排查。6.2 脚本执行报错Command ‘git’ not found或Python not found这通常是环境变量问题。解决方案Git未找到确保Git已安装并已添加到系统的PATH环境变量中。在终端输入git --version测试。如果是在IDE的内置终端中运行脚本有时IDE的环境与系统环境不同需要检查IDE的终端设置。Python未找到同样确认Python已安装。在命令行中可能需要使用python3而不是python。你可以修改脚本的第一行shebang为#!/usr/bin/env python3或者在调用时显式使用python3 scripts/update_docs.py。6.3 生成的文档内容过于模板化缺乏实际业务细节这是所有模板化工具的共性问题。dev-docs-skill提供的是骨架和流程而不是内容本身。最佳实践将生成的文档作为起点不要期望工具生成完美的最终文档。把它看作一个已经帮你排好版、分好章节的空白文档你需要往里填充血肉。结合代码审查在团队协作中可以将“更新对应文档”作为代码合并Merge Request/Pull Request的一项强制检查项。审查者不仅看代码也看关联的PRD更新或CHANGELOG条目是否准确反映了代码变更。利用AI助手补充内容生成了文档骨架后你可以直接让Cursor或Claude Code帮你撰写具体内容。例如“基于我刚写的payment_service.py中的process_payment函数为REQ-payment.md中的‘功能需求’章节写一段详细的业务逻辑描述。” AI可以根据代码上下文生成相当准确的描述。6.4 如何管理文档版本与发布dev-docs-skill主要管理“Unreleased”部分的变更。当你要发布一个新版本如v1.2.0时需要手动进行版本升级操作。标准操作流程确定发布内容检查CHANGELOG.md中[Unreleased]下的所有条目确认它们都准备就绪。更新版本号将CHANGELOG.md顶部的[Unreleased]章节重命名为新版本号例如## [1.2.0] - 2024-05-27。在文件顶部新增一个新的[Unreleased]章节用于收集下一个版本的变更。更新项目中的其他版本标识文件如package.json、pyproject.toml等。创建版本标签使用Git创建标签。git commit -a -m “chore: release v1.2.0” git tag -a v1.2.0 -m “Release version 1.2.0” git push origin main --tags你可以将这个流程脚本化结合dev-docs-skill创建一个release.py脚本自动完成版本号更新、CHANGELOG重组和打Tag的操作。6.5 在大型单体仓库Monorepo中如何使用如果你的项目是包含多个子包或服务的Monorepo文档管理策略需要调整。策略建议统一文档根目录仍然在仓库根目录运行init创建统一的docs/文件夹。按模块/服务组织子目录在docs/requirements/下为每个子服务创建文件夹如docs/requirements/auth-service/、docs/requirements/payment-service/。同样API文档也可以按服务拆分。调整脚本逻辑进阶修改analyze_changes.py使其能识别变更文件所属的服务并将分析结果归类。例如修改user-service/src/下的文件则归类到“user-service”。这样在生成PRD或更新日志时可以更精确地关联到具体服务。维护统一的顶层CHANGELOG尽管各服务有独立变更但项目整体发布时需要一个统一的CHANGELOG.md。可以设计一个流程在发布时聚合各子服务的变更记录生成总览。dev-docs-skill作为一个轻量级工具其核心价值在于定义了流程和规范。在复杂项目中你可能需要在其基础上进行定制开发以适应特定的项目结构但其“分析变更、模板化生成、规范记录”的核心思想是普适的。