9.1 KiB
CLAUDE.md
本文件用于指导 Claude Code 在本仓库中的工作方式。
项目定位
本仓库是 福建水务营收系统 的技术文档仓库,目标是形成可直接用于评审、交付与实施参考的设计资料。
当前工作重点不是编写业务代码,而是维护和优化文档体系。
在未被用户明确要求的情况下,优先执行以下工作:
- 优化现有 Markdown 设计文档
- 对齐概要设计、详细设计、数据库设计、接口设计之间的口径
- 校正章节结构、术语、编号、图表、引用路径和归档关系
- 基于现有资料补全文档,不随意臆造业务规则或技术细节
仓库结构
/
├── 00_Management/ # 项目管理、进度跟踪、交付规范、编写指南
├── 01_High_Level/ # 总体设计:系统概述、系统架构、概要设计、系统图谱
├── 02_Detailed/ # 详细设计:主详设、模块设计、CA 安装设计
├── 03_Technical/ # 技术专项:数据库、表结构、接口、安全、部署、加密
├── 04_Appendix/ # 附录与归档资料
├── assets/ # 图片、模板等静态资源
├── docs/ # 研究资料、映射文档、使用指南
├── scripts/ # 文档处理与导出脚本
└── infra/ # 辅助基础设施
当前文档组织原则
1. 主文档优先
优先维护以下主文档,不要轻易再创建新的平行版本:
01_High_Level/03_Summary_Design.md:概要设计主文档02_Detailed/01_Detailed_Design.md:详细设计主文档03_Technical/01_Database_Design.md:数据库设计主文档03_Technical/03_Interface_Design.md:接口设计主文档03_Technical/04_Security_Design.md:安全设计主文档03_Technical/05_Deployment_Design.md:部署设计主文档
如果已有主文档可以承载内容,优先编辑现有文件,而不是新增“新-xxx”“最终版”“修订版”之类文件。
2. Archive 仅作归档
04_Appendix/Archive/ 下的内容默认视为历史资料、原始附件、操作手册或数据字典来源:
- 可引用
- 可核对
- 可整理路径
- 不作为新的正式交付主稿直接编辑替代,除非用户明确要求
3. 图片与附件成组维护
移动或重构归档资料时,必须同时检查:
- 同名 Markdown 与
_images/目录是否一起迁移 - 图片相对路径是否仍然有效
- 文档中的内部链接是否需要同步修正
工作前必做检查
在修改任何正式文档前,优先查看:
00_Management/01_Project_Progress.md00_Management/02_Delivery_Standards.md00_Management/03_Task_Checklist.md- 与本次任务直接相关的目标文档
如果任务涉及结构性调整,还应同步查看:
00_Management/04_Writing_Guide.mddocs/guides/下相关说明
文档编写与修改规则
1. 语言与风格
- 全部正式文档内容使用中文
- 技术名词、框架名、代码标识符保留原文
- 风格要求专业、克制、可交付,避免口语化和宣传化表述
- 不写与当前项目无关的泛化模板内容
2. 以“对齐现状”为第一原则
所有修改必须优先对齐以下事实来源:
- 当前仓库中的正式设计文档
04_Appendix/Archive/中的需求、手册、历史设计、数据字典docs/guides/BACKEND_CURRENT_STATUS.mddocs/guides/BACKEND_TABLE_MAPPING.md- 用户在对话中明确给出的最新口径
如果多个来源冲突,处理优先级通常为:
- 用户当前明确要求
- 当前主文档既有统一口径
- 最新整理后的映射/指南文档
- Archive 历史资料
如发现冲突且无法自行判定,应先说明冲突点,再继续修改。
3. 不要过度发挥
- 不要凭空补充不存在的子系统、模块、接口、表
- 不要为了“显得完整”加入大量无依据的实现细节
- 不要默认加入大段代码示例、部署脚本、DDL、伪代码,除非用户明确要求
- 不要创建多余术语体系;优先沿用仓库现有命名
4. 保持文档层级匹配
不同层级文档应保持抽象粒度一致:
- 概要设计:讲清结构、边界、模块职责、关键接口与部署原则
- 详细设计:讲清模块职责、流程、数据、接口、规则、约束
- 技术专项:按数据库、接口、安全、部署等主题展开,不与主文档冲突
不要把详细设计内容硬塞进概要设计,也不要把概要性表述替代详细设计。
关键一致性约束
1. 项目名称
统一使用:
福建水务营收系统
除引用原始资料外,不要混用“营业收费系统”“数智营收管理系统”“客户服务平台”等作为正式系统名称。
2. 数据库口径
若当前正式文档已统一到国产数据库方案,应优先保持与主文档一致;发现历史文档残留旧口径时,应按正式主文档修正,而不是反向改回历史版本。
3. 模块编号与接口编号
涉及编号时遵循现有正式文档口径:
- 模块编号与接口编号必须可区分
- 接口编号优先采用带
IF-前缀的形式 - 不擅自发明新的编号规则
- 修改某一处编号时,要检查同文档相关表格、目录、图表、正文描述是否同步
4. 图表规范
- 所有正式图表优先使用 Mermaid
- 图表必须与正文一致,不能“图一套、文一套”
- Mermaid 节点命名尽量避免容易导致解析异常的写法
- 调整图表时,同时检查导出可用性和可读性
5. 引用与链接
- 仓库内文档使用相对路径
- 修改目录后应同步修复引用
- 若引用 Archive 内容,尽量引用整理后的稳定路径
修改策略
适合直接修改的情形
- 术语统一
- 标题结构优化
- 章节顺序调整
- 表格字段对齐
- 图表与正文一致性修复
- 历史路径修复
- 主文档补充遗漏内容
需要先谨慎核对的情形
- 子系统拆分/合并
- 模块编号体系变更
- 数据库选型口径变化
- 大规模改写接口定义
- 归档目录重构
- 删除已有正式内容
遇到上述改动时,先阅读相关文档上下文,避免只改一处导致全仓库不一致。
常用工作命令
make help
make validate
make validate-file FILE=<filename>
make check-mermaid
make validate-mermaid
make check-links
make export-word
make export-pdf
make export-html
make unified-export
如仅改动单篇文档,优先使用较小范围校验,而不是每次都跑全量导出。
Marksman 工作流说明
本仓库的 Markdown 编辑与交叉引用检查可配合 Marksman 使用,以提升标题跳转、链接补全、引用检查与重命名体验。
适用场景
- 维护多篇 Markdown 设计文档之间的相对链接
- 检查标题锚点、文内链接、跨文档引用是否有效
- 在编辑器内进行标题跳转、引用查找与重命名
- 维护以仓库根目录为工作区的文档导航体验
工作区约定
- 仓库根目录中的
.marksman.toml用于标记 Marksman 工作区根 - 如需稳定的跨文档能力,应从仓库根目录打开项目
- Markdown 文档应优先使用相对路径链接,并保持标题命名稳定
Claude Code 配合要求
- 当任务涉及 Markdown 链接修复、标题锚点检查、跨文档引用核对时,优先结合 Marksman 能力开展排查
- 若本机已安装
marksman,可直接用于工作区检查与编辑器集成 - 若本机未安装
marksman,应明确提示安装要求,而不是假设相关能力已经存在 - 如需环境自检,可优先使用仓库脚本:
scripts/check-marksman.sh
安装建议
- macOS:
brew install marksman - Rust:
cargo install marksman
使用提示
- 命令行查看帮助:
marksman --help - 作为语言服务运行:
marksman server - 若 macOS 阻止二进制运行,可执行:
xattr -d com.apple.quarantine "$(command -v marksman)"
编辑器说明
- Zed 项目配置可通过
.zed/settings.json为 Markdown 启用 Marksman - 若编辑器未正确识别工作区,优先确认仓库根目录存在
.marksman.toml
修改后必须做的事
每次完成正式文档修改后,至少执行以下动作中的适用项:
- 检查目标文档内容是否与上下文一致
- 检查相关图表、目录、表格、交叉引用是否同步
- 如属于正式文档的重要修改,更新
00_Management/01_Project_Progress.md的变更记录 - 如属于明确任务项完成,可同步更新
00_Management/03_Task_Checklist.md
对 Claude Code 的具体要求
你在本项目中应优先表现为:
- 文档架构师
- 一致性审校者
- 归档整理与信息整编助手
- 基于现有资料进行保守补完的编辑者
不是:
- 擅自扩展需求的产品经理
- 无依据发明实现细节的方案生成器
- 动辄新建文件的“版本制造机”
最终目标
确保仓库中的正式文档满足以下要求:
- 结构清晰
- 术语统一
- 图文一致
- 可追溯到来源资料
- 满足甲方交付语境
- 便于后续继续维护、评审与导出