@airalogy/airalogy-bd

中文文档
1.14.1发布于 2026/11/02Apache-2.0ES Module构建来源已验证近 30 天下载 4764

企业发展工作空间供地方使用并开展团队协作.

中文使用文档
文档目录20 节
  1. 多人协作与服务器部署
  2. 可选 AI 助手
  3. 环境要求
  4. 安装方式
  5. 安装与初始化
  6. 命令
  7. 开发
  8. 目录与文件命名
  9. 资料编辑与修改历史
  10. 按日期浏览与独立备份
  11. 周报导出
  12. 公司动态
  13. 人员列表
  14. 投资总览与联系方式
  15. 日期与摘要
  16. 事实边界
  17. 事项资料与发送追溯
  18. 完整备份与恢复
  19. 软件版本标识
  20. 许可证

Airalogy BD

由杭州渊楠科技有限公司开发。网站页脚固定显示 Airalogy BD 与公司版权标注,点击产品名可查看开发公司和运行版本;该标注独立于使用单位的工作区名称。

Airalogy BD 是一套支持本地使用与团队服务器部署的 BD 管理工作台,用于管理合作项目、投资人对接、资源关系、人员与关键事件。

首次发行基线为 1.0.0,版本统一使用 x.y.z。版本内容见 更新记录,后续版本规则见 版本管理说明。本地正式使用安装固定版本,源码安装用于开发;版本号不代表安装包、镜像或线上服务已经发布。

可选的 外部 AI 工具接入 默认关闭:管理员分配成员权限,成员在「我的账号」连接支持远程 MCP 和 Bearer 认证的工具。连接默认提交草稿,由本人在「待确认修改」核对保存;只读成员仅可查询。管理员可主动选择直接保存进展及附件,也可另行授权新建事项及维护业务档案;既有凭据不会自动扩大权限。与内置 AI 的开关、模型配置和计费相互独立。

投资问答库 用于积累常见问题与团队推荐回答,支持分类搜索、Markdown、来源关联和修订历史。成员单独授权;MCP 可查询、提交修改草稿,管理员明确授权的连接可直接保存修订稿。推荐版本由具备确认权限的成员在网页确认。

本仓库只保存通用实现、数据校验、内容模板和虚构测试数据,不保存客户业务、真实联系人、合同或融资资料;产品名称和开发公司的版权归属属于公开产品信息。

多人协作与服务器部署

支持邀请制账号、密码与动态验证码登录、管理员/编辑/只读角色、事项授权、录入账号追踪、服务器容器部署和私有 OSS 自动备份。本地模式无需登录。部署方式、权限范围、备份恢复和版本更新步骤见 团队部署说明。

管理员填写姓名并分配权限即可创建成员,邮箱选填;复制一次性邀请链接交给本人,由本人补充邮箱、设置用户名、密码和动态验证码。支持用户名或邮箱登录。邮箱归属验证可选、默认关闭,无需配置邮件服务即可使用;管理员配置 SMTP 后可为整站开启。默认使用 Airalogy Logo,自行部署可配置站点名称及自有 Logo,详见账号邀请与站点品牌。

可选 AI 助手

提供对话整理事项/进展草稿、人工确认保存,以及带来源的日期范围进展总结。默认关闭,由管理员配置 OpenAI 或 Qwen 中国区服务;遵循事项权限,通过数据服务保存,密钥只保存在服务器。管理员可查看成员/模型 Token 与估算费用,设置每日请求、Token 和费用限额。配置、使用及验证范围见 AI 助手说明。

环境要求

  • Node.js 22.13 或更高版本
  • pnpm 11
  • uv
  • Git

安装方式

  • 团队成员:打开公司部署的网址,无需安装。
  • 公司服务器:优先下载 GitHub Release 的预构建镜像部署包,按团队部署说明使用固定版本镜像;不需要在服务器安装开发依赖或构建程序。
  • 本地工作台:用 pnpm 安装固定版本的 npm 包,步骤见下文。
  • 开发与定制:检出 GitHub 源码。

容器镜像与 npm、GitHub Release 使用同一 x.y.z,支持 Linux amd64 / arm64。以 Release 中的部署附件和工作流成功状态确认可用性,不根据 npm 版本推断镜像已经发布。

安装与初始化

在独立的业务工作区安装指定版本。以下以 1.1.1 为例,需要该版本已发布到 npm:

mkdir company-bd
cd company-bd
pnpm --allow-build=sharp --allow-build=unrs-resolver dlx @airalogy/[email protected] init --id company-id --name 公司名称
pnpm install

首次安装需要明确许可 sharp 和 unrs-resolver 的构建脚本,上述命令只允许这两项。初始化会固定当前程序版本,不依赖临时下载目录。也可以先用 pnpm 安装,再初始化:

pnpm add -D -E @airalogy/[email protected] --allow-build=sharp --allow-build=unrs-resolver
pnpm exec bd init --id company-id --name 公司名称

初始化生成空内容结构、依赖配置及 macOS 双击启动文件 启动 Airalogy BD.command,保留已有文件。现有工作区也可执行 bd init 补充启动文件。安装依赖后双击启动文件即可启动服务并自动打开浏览器;再次双击会打开同一工作区已有的启动实例。服务准备完成后才打开页面,失败时终端保留原因和处理提示。启动窗口需要保持打开,关闭窗口会停止服务。此启动方式使用开发服务,无需先构建;也可通过命令行启动。

启动器在 3000–3099 中选择空闲本机端口,不连接其他工作区服务。重复启动识别仅适用于此启动器创建的实例;命令行手动启动的实例仍由原终端管理。启动状态保存在 .airalogy-bd/,不进入业务资料。

业务工作区包含 content/ 和根目录命令配置:

{
  "private": true,
  "devDependencies": {
    "@airalogy/airalogy-bd": "1.1.1"
  },
  "scripts": {
    "dev": "bd dev",
    "validate": "bd validate",
    "data": "bd data",
    "build": "bd build",
    "start": "bd start",
    "lint": "bd lint",
    "test": "bd validate && bd build"
  }
}

命令默认读取当前目录下的 content/;如需更换位置,使用 --content <dir>。 运行时会在业务工作区根目录生成 .airalogy-bd/ 构建缓存,请将其加入 .gitignore。

升级前停止正在运行的工作台并保存完整备份,然后使用 pnpm add -D -E @airalogy/airalogy-bd@<指定版本> 更新依赖。重新启动双击启动器即可;使用生产构建时需先重新执行 pnpm build。将工作区的 package.json 和 pnpm-lock.yaml 一起留存,避免安装时意外改变版本。安装与升级不自动同步本地和服务器上的业务资料。

使用 pnpm 11 时,业务工作区应配置以下构建依赖许可:

# pnpm-workspace.yaml
packages:
  - .

engineStrict: true
allowBuilds:
  sharp: true
  unrs-resolver: true

命令

命令用途
bd validate校验工作区、人员、事项、事件和会议结构
bd data生成 content/generated/dashboard.json
bd dev生成数据并启动本地工作台
bd build生成数据并构建工作台
bd start启动已构建的工作台
bd lint检查工作台代码
bd checkpoint留存当前资料,校验并更新看板
bd edit --label <说明> -- <command>在直接编辑命令前后留存版本,失败时也记录修改结果
bd backup-auto按已保存设置检查并执行到期备份

开发

git clone https://github.com/airalogy/airalogy-bd.git
cd airalogy-bd
pnpm install
pnpm test
pnpm dev

fixtures/demo/content/ 只包含虚构数据,用于平台回归测试。

日常开发直接运行 pnpm dev,不构建 Docker。此命令通过 bd dev --source 直接运行 dashboard/ 源码,由 Next.js 原生 Fast Refresh 处理组件、样式及接口代码更新,不复制源码或额外实现同步监听器。编译缓存保留在 dashboard/.next/,重启开发服务可继续复用;默认使用 Webpack,兼容链接依赖。业务资料变更仍通过数据服务自动刷新。

源码开发可用 bd dev --source --content /指定工作区/content 选择资料目录;同一个源码目录同时运行一个开发服务。修改 CLI、依赖或启动环境变量后需重启,依赖变化还需重新执行 pnpm install。普通安装用户继续使用 bd dev 或双击启动文件,保留各自独立运行目录。

按改动运行针对性测试;pnpm test:dev 在临时源码副本和虚构工作区中验证真实开发服务的热更新。发版前再执行完整测试。Docker 构建和双架构容器演练用于正式发版,以及 Dockerfile、系统依赖或容器运行配置的修改,不是每次开发都必须执行的步骤。

需要在独立工作区调试源码时,可执行 node /path/to/airalogy-bd/bin/bd.mjs init --source,再安装工作区依赖。--source 仅为新依赖使用本地链接;初始化不会覆盖已有依赖版本或自定义命令。npm 安装包的验证和发布见发布说明。

目录与文件命名

源码目录名为 airalogy-bd,安装包名为 @airalogy/airalogy-bd,命令为 bd。源码按用途放入 bin/、dashboard/、scripts/、templates/、tests/、docs/ 和 deploy/;React 组件使用 PascalCase,其他 JavaScript 文件使用 kebab-case,Python 模块使用 snake_case。

事项模板使用 matter.md、matter-contacts.yaml 和 matter-events.yaml;放入业务工作区后分别保存为事项目录中的 README.md、contacts.yaml 和 events.yaml。固定结构名使用英文,业务名称与附件原始文件名保留原名。运行目录为 .airalogy-bd/,产品配置变量统一使用 BD_ 前缀;第三方组件保留其规定的变量名。

资料编辑与修改历史

工作台提供“资料管理”“修改历史”入口,顶部“新增”菜单可直接新建事项或补充沟通进展。可新增事项、人员、项目沟通进展及公司动态;可修改事项元数据与管理正文、事项人员关系、人员单位及职位、电话、微信、邮箱,以及进展和完整沟通记录。姓名作为人员档案标识,已有姓名不在表单中改名,避免引用断裂与重复档案。

表单和 AI 使用同一份 Markdown/YAML。新增进展时可同时添加新参与人的事项关系;修改实际日期会同步调整关联文档文件名。事项新建必须提供首条实际进展,人员关系必须有参与记录;会议类型须有整理后的沟通记录。不会推断业务事实、负责人、期限或承诺。

每次成功保存先校验候选资料,再保存完整内容并留存可恢复版本。文件写入共用锁和恢复日志,进程中断后会恢复完整事务;若中断后同一文件又被外部编辑修改,服务会暂停覆盖并保留日志,避免抹掉新修改。表单保存采用记录版本校验;过时表单保留草稿,先比较最新内容,再选择重新编辑或明确按草稿保存。恢复操作再次检查预览后的完整工作区版本。

修改历史包含独立自动版本及业务内容仓库的 Git 版本。可按对接方、事项、人员、公司动态筛选,可查看每次保存前后的改动,也可与当前内容比较字段及正文;恢复某个人只修改该档案,不回退同文件里的其他人员。恢复对接方只恢复名称、类型、备注和共用联系人,不回退事项进展。恢复某事项包含该事项元数据、联系人、进展与会议记录;恢复公司动态只包含所选动态及其记录。所有恢复先保留当前内容,再形成新版本。完整资料恢复在展开选项中提供,显示全部差异并二次确认;历史资料须通过当前校验才可恢复。

自动版本位于内容目录上一级的 .bd-history/<工作区标识>/,与 .airalogy-bd/ 构建缓存分开。将 .bd-history/ 加入内容仓库的 .gitignore;备份时一起备份内容与此历史目录。自动留存不修改原仓库暂存区、不自动提交或推送,也不把真实业务内容放入工作台工程。

本机工作台运行时,通过文件监听和定期检查留存 AI / 编辑器直接修改的状态;格式错误的文件也留存,界面保持上次校验通过的数据并提示问题。监听只能记录实际观察到的状态,不能保证捕获极短暂的每次写入。工作台关闭后,已留存版本仍在;没有留存的中间版本无法补回。直接编辑前可使用:

bd checkpoint --label "编辑前留存资料"
# 编辑资料后再次留存、校验和更新看板
bd checkpoint --label "编辑后留存资料"
# 或用包装命令在编辑前后留存;支持非交互编辑命令
bd edit --label "更新沟通进展" -- <command> [args...]
# 用独立编辑工具操作后,也检查一次备份
bd backup-auto

bd data 也会先留存当前内容。默认只绑定本机地址;保存接口要求同源请求与校验令牌,拒绝非本机主机名、跨站保存、越界路径和符号链接写入。

按日期浏览与独立备份

“修改历史”可选择日期,浏览工作区时区下当日结束前最后留存的完整资料,也可从版本列表直接浏览具体版本。没有保存的日期使用更早的最近版本,并显示实际保存时间;早于首次留存时明确提示没有资料。使用提交的保存时间排序,不使用业务交流日期或 Git 作者日期。格式错误的历史版本不会悄悄换成另一个版本,可继续比较原文。

历史浏览为只读:事项、人员、投资总览、公司动态、沟通记录与附件索引均来自同一版本。不会打开当前编辑表单或混入新版本的附件;附件下载仍校验原件。返回当前资料后,才可比较并确认恢复。即使当前内容格式有误,也可以浏览有效的资料版本。

“备份”中可设置工作区以外的文件夹、开启自动备份、查看最近成功时间与文件位置,并立即备份。默认每小时在资料发生变化时创建一个完整 ZIP;也可改成每 24 小时。工作台运行期间每分钟检查,启动时补做;bd edit 结束后也检查。关闭工作台期间没有常驻定时服务。无变化不重复备份,失败至少间隔 5 分钟后重试,失败原因在界面显示,不阻止业务保存。

备份包含业务文字、全部附件版本、工作台自动历史,以及独立内容仓库的已有 Git 历史。若内容位于一个更大的父级仓库内,不将其他项目打包,该父级仓库须另外备份。备份写入完成并校验后才报告成功,备份副本按保留期清理;最新成功副本始终保留。自动备份配置和状态保存在 .bd-history/<工作区标识>/ 下,不写进业务内容或原仓库暂存区。恢复到新目录后默认不开启原机器上的自动备份设置,需重新选择目录。

同一磁盘上的独立文件夹有助于恢复工作区误删;整机故障仍需另一磁盘或异地备份。恢复后可在“修改历史”中浏览备份包含的资料版本。

周报导出

顶部“导出 → 工作周报”在各页面均可使用;业务总览还可选择“事项资料”,导出当前筛选结果或完整总览。默认按工作区时区选择本周(周一至周日),可切换上周、最近记录所在周,或调整起止日期。也可选择一位参与人,仅汇总事件中明确列明该人参与的记录。

周报按合作进展、投资对接、资源对接及公司动态分组,包含所选周期内全部重要及普通事件的标题与摘要。不会引用当前项目摘要、状态或下一步,以免把之后的变化带入历史报告。没有记录的类别省略;没有记录的周期显示空状态。

预览后可复制文字,或导出 Word、Markdown、离线 HTML;PDF 通过系统打印窗口存储。周报不会维护额外业务字段,也不发送消息给其他人。

公司动态

顶部“公司动态”入口独立展示公司事件,不受业务总览中的项目筛选影响。动态按日期倒序、按月分组,支持关键词、活动类型和起止日期组合筛选;关键词覆盖标题、摘要、完整记录、参与人和主办方。可直接阅读关联的完整记录。

业务总览显示最新公司动态摘要和“查看全部公司动态”入口。公司动态保存在 content/company/events.yaml 与 records/。

人员列表

业务总览中的人员以紧凑表格展示姓名、关系、单位及职位、项目角色、联系方式、关联事项和最近参与日期。可使用排序选项或点击姓名、关联事项及最近参与表头,按姓名拼音升序、关联事项数量降序或最近参与日期降序排列。支持关键联系人筛选与事项标签筛选;多于两个关联事项时可展开其余事项。窄屏支持横向滚动,姓名列和表头保持可见。

投资总览与联系方式

顶部“投资总览”独立展示投资对接事项,支持按关键词、阶段、跟进状态、优先级及联系方式缺失筛选,支持主动跟进优先、最近进展和最久未更新排序。每条事项展开后显示全部对外联系人,包括单独标明的引荐人及顾问;同一事项可关联多位联系人,人员档案仍只维护一份。点击事项名称可阅读完整进展与会议记录,也可导出当前筛选结果为 CSV(每位联系人一行)。

投资总览只读取 record_type: investment 的事项,不把合作项目中的投资意向自动转换为投资事项。机构及个人名称沿用事项档案,进展和行动沿用现有事件及管理摘要,不自动推断跟进计划。

在 content/people.yaml 的人员档案中分别维护可选字段 phone、wechat、email,不要重复写在项目 contacts.yaml。电话号码必须加引号,保留前导零、区号及加号。未提供的联系方式可省略或填写 null,不从“已加微信”等沟通记录猜测号码。“联系方式待补充”表示未关联对外联系人,或至少一位对外联系人三项联系方式均为空。

people:
  - id: 示例姓名
    name: 示例姓名
    affiliation: 示例投资机构投资经理
    phone: null
    wechat: null
    email: null

日期与摘要

业务内容不手工维护通用的 updated 字段。项目最近活动日期取自该项目最新事件,人员最近参与日期取自其参与的最新事件,看板“数据更新至”取全部项目事件和公司事件中的最新日期。文档编辑历史由独立自动版本库与原仓库 Git 共同保存,可在修改历史中查看与恢复。

项目 README.md 只写管理摘要、当前进展、判断和下一步,不重复维护 events.yaml、contacts.yaml 或 meetings/ 的文件索引;工作台会根据结构化数据自动汇总这些内容。

事实边界

内容只记录用户或来源材料明确提供的事实、结论和行动,不自行推断表决结果、对方态度、合作判断、后续事项、负责人或期限。没有明确信息时,可选章节直接省略;会议模板默认不生成“对方反馈”“会议结论”或“后续事项”,只有来源明确提供时才增加。

事项资料与发送追溯

在事项详情点击“事项资料”,或从“资料管理 → 事项资料”进入资料库。新增/编辑进展的“相关文件”区域支持直接上传新文件、关联已有具体版本、追加新版本;点击保存时与进展一并归档。事项表单的“保存并关联资料”仍可在保存成功后进入对应资料范围。交流记录旁的“相关资料”只显示与该次交流关联的使用记录。

协议分类可选择“保密协议(NDA)”或“投资合作协议”,支持按类型筛选及搜索;协议类型与“草案、定稿、签署件”等文件状态分别维护。

每个协议版本可分别记录“协议载明日期”(agreement_date)和“实际签署完成日期”(signing_completed_date)。前者是文本中写明的日期,后者是确认各方完成签署的实际日期;均可留空,允许不同。不从文件名、上传时间或“签署件”状态推断日期,也不自动改变事项阶段。导入时可填写,之后可在该版本下“填写 / 更正日期”,更正保留历史且不修改原件。新版本的日期独立填写,不继承旧版本。

沟通进展仅在有可查看的关联文件时显示“相关资料”及数量;完整沟通记录使用独立入口。进展直接显示关联文件名、具体版本和下载入口。新增或补充附件可在进展表单内完成,也可从事项资料入口进入。关联使用中性的“进展附件”记录,不自动登记为发送或签署;原始文件只归档一次,历史进展始终引用当时版本。

资料支持 PDF、PPT/PPTX、Word、Excel、图片、Markdown、文本、CSV 和 ZIP,单个文件不超过 50 MB。导入不代表已发送或已签署;文件状态由用户按实际情况选择。每份资料可关联多个事项,每个使用记录绑定一个具体版本,并分别记录会议使用、实际发送或对方提供;发送和收到记录必须填写具体人员及渠道。同一机构可记录多位联系人。

协议可选择“保密协议(NDA)”类型。资料管理的“全部 NDA”入口跨对接方汇总,资料库也支持按文件类型筛选和搜索 NDA 标签。原文件仍按对接方归档,可关联投资、合作等多个事项;NDA 的文件状态独立维护,不自动改变事项阶段。未填写 agreement_type 时按“未标注”读取,不根据文件名猜测类型。

每家公司使用一个独立的工作区根目录。一个对接方(机构或个人)一个目录,包含共用档案、事项和附件。只有一条事项时也使用固定的 matters/事项名称/ 层级,界面直接显示事项;出现多个事项时才显示切换入口。

workspace/
├── content/
│   ├── workspace.yaml
│   ├── people.yaml
│   ├── files.yaml
│   ├── company/
│   └── counterparties/
│       └── 对接方名称/
│           ├── README.md
│           ├── contacts.yaml
│           ├── matters/
│           │   └── 事项名称/
│           │       ├── README.md
│           │       ├── contacts.yaml
│           │       ├── events.yaml
│           │       └── meetings/
│           └── attachments/
│               ├── agreements/
│               ├── materials/
│               └── .objects/
├── .bd-history/
└── .airalogy-bd/

新增事项时可以选择已有对接方,也可以一并填写新对接方;两者在一次校验和保存中完成。同名对接方复用已有档案。对接方的 README.md 保存 id、name、kind(organization 或 person)、可选 short_name 及备注;其 contacts.yaml 保存 counterparty 和长期联系人员 ID 数组 people。姓名、单位及职位、电话、微信、邮箱统一维护在全局 people.yaml,不会按事项复制人员身份。

事项的 README.md 使用 primary_counterparty_id 指定归档对接方,counterparty_ids 引用所有参与对接方。事项 ID 保持稳定,record_type 区分合作、融资及资源关系。一个联合事项只在归档对接方的 matters/ 下保存一份;其他对接方通过 ID 关联。事项的 contacts.yaml 只维护本事项角色、关系和备注,与对接方的共用联系人职责不同。界面会汇总各事项参与人员供复用,但不会据此认定某人受雇于该单位,也不凭投资意向自动创建融资事项。

导入资料时选择“归档对接方”,文件存入该对接方的 attachments/;可关联多个事项,至少有一个事项与归档对接方有关。归档对接方创建后固定;名称或简称调整不会移动文件。content/files.yaml 保存全局资料索引,纳入自动历史和校验。attachments/.objects/ 保存按 SHA-256 验证的原件;可见的协议归档在 agreements/,其他材料在 materials/。会议使用、实际发送和收到材料的记录通过 version_id 关联具体版本,记录日期、人员和渠道,不额外保存文件副本。导入文件不覆盖已归档版本,恢复资料也不改变发送记录所引用的版本。

固定目录使用英文;对接方、事项、资料标题和原始文件名保留原名。将 content/counterparties/*/attachments/ 加入内容仓库的 .gitignore。附件中的 Markdown 不参与业务文本校验或文本版本库;附件原件通过完整备份保存。恢复历史时保留附件,即便对接方或事项文字已被撤回,完整备份也包含这些原件。

同一份资料的所有版本直接保存在 agreements/资料标题/ 或 materials/资料标题/ 内,不额外建立版本子目录。默认保留原文件名及扩展名大小写;同名且内容不同时追加 -v002 等可读后缀,同名同内容复用副本。同名资料使用 资料标题 (2) 等目录区分;ID 保存在索引中。文件系统不支持的字符和超长名称会作必要调整,索引及下载名称仍保留导入名称。“打开所在文件夹”在版本和使用记录中均定位到对应版本的同一份归档,macOS 会在 Finder 中选中文件。

自动历史在 .bd-history/,程序缓存在 .airalogy-bd/。公司其他资料放在工作区之外,启动时可用 bd dev --content /指定工作区/content 选择工作区。附件保存在归档对接方目录中。通用材料可在工作区外编辑,归档时导入需要保存的版本。

资料元数据与使用记录通过数据服务维护,版本原件通过导入新增;已归档文件在文件夹中的副本不作为可覆盖的主版本。直接修改归档副本不会替换工作台下载的原件。所有保存都检查索引及原件完整性;版本恢复前检查对应原件是否存在。文件索引有独立编号,修改名称不影响既有发送记录。

资料页支持更正或移除使用记录、编辑资料信息、回收站恢复;“修改历史 → 事项资料”可比较和恢复该资料的历史索引。恢复会保留当前历史。若索引关联的事项、事件或人员要被移除,应先调整资料关联,防止产生失联文件。

完整备份与恢复

资料页的“备份全部资料”下载 ZIP,包含业务文字、全部附件版本、工作台修改历史、独立业务内容仓库的 Git 历史及校验清单。团队模式还包含账号、事项权限与审计记录;登录会话、未使用邀请、远程接入凭据、草稿和保存请求收据、未归档的暂存上传、AI 运行状态、部署密钥与配置不包含在备份中,恢复后须重新配置相关服务。详细范围见 团队部署说明。备份文件保存在自动历史目录的 exports/ 中,下载后应存入独立备份位置。

bd backup --output /path/to/backup.zip
bd restore-backup --archive /path/to/backup.zip --destination /path/to/new-workspace
# 启动恢复后的工作区
bd dev --content /path/to/new-workspace/content

恢复仅写入尚不存在的新目录,先检查备份路径、文件指纹和资料结构,再导入附件与自动历史,不覆盖当前工作区。自动恢复支持解压后不超过 2 GB、10 万条目的备份。归档原件和历史库应一起备份;只复制 files.yaml 不能恢复文件。

软件版本标识

页脚显示实际运行的软件版本,点击可查看构建时间、构建标识及本地代码版本。从源码构建时显示“构建来源:本地源码”;版本来自工作台软件自身,不读取公司工作区的包版本。构建标识随程序内容变化,用于区分同一版本号下的本地更新。

版本信息在 bd build / bd dev 启动时固定,bd start 沿用已有构建的信息。源码开发的页面代码可热更新,版本卡片中的构建标识仍对应启动时的源码快照;重启开发服务可刷新此标识。正式运行时,修改或升级源码后需重新构建并启动才能加载。界面仅展示当前运行版本,不自动查询远程发布,发布状态由发布标签与分发产物确定。

pnpm version:check 检查软件版本与更新记录是否一致,已纳入 pnpm test。代码提交和推送不自动发版或部署。正式发布 GitHub Release 后,已配置的可信发布流程会验证并发布 npm 安装包、同版本容器镜像和部署附件;服务器部署仍单独执行。

公开前运行 pnpm publication:check,并按 公开代码检查说明 复核源码及实际分发文件。

许可证

原创代码与文档采用 Apache License 2.0,版权归杭州渊楠科技有限公司所有,见 NOTICE。第三方组件仍遵循各自的许可证,见 第三方组件说明;适用范围与分发注意事项见 许可说明。

业务总览的动态日历统一汇总当前账号可查看的事项进展和公司动态,以实际发生日期统计全部普通与关键事件,不受“最近进展”的条数限制。点击日期可查看当天记录及所属事项;切换事项、阶段或其他事项筛选后,日历只统计筛选内事项,并清除日期选择。公司动态页的日历仅统计公司动态,与该页筛选保持一致。

版本与发布记录

@airalogy/airalogy-bd 共发布 27 个版本,首次发布于 2026/10/26;过去 12 个月发布了 27 个版本。最新版本附带 npm provenance 构建来源证明,可追溯到公开的 CI 构建记录。

版本发布日期距今
1.14.1latest2026/11/024 天前
1.14.02026/11/024 天前
1.13.02026/11/014 天前
1.12.02026/10/306 天前
1.11.02026/10/307 天前
1.10.02026/10/307 天前

关于 @airalogy/airalogy-bd 的常见问题

@airalogy/airalogy-bd 是什么?

企业发展工作空间供地方使用并开展团队协作.

如何安装 @airalogy/airalogy-bd?

在项目目录运行 npm install @airalogy/airalogy-bd,或使用 pnpm add / yarn add / bun add。它还提供命令行工具 bd,可以用 npx bd 直接运行。

@airalogy/airalogy-bd 支持 TypeScript 吗?

该包的 package.json 没有声明类型入口。需要类型提示时,可以在 npm 上查找社区维护的 @types/airalogy__airalogy-bd 是否存在。

@airalogy/airalogy-bd 支持 ESM 还是 CommonJS?

以 ES Module 形式发布,推荐使用 import 引入。在 CommonJS 项目中,Node.js 20.19+ / 22.12+ 可以直接 require() 不含顶层 await 的 ES Module,更早的版本需要改用动态 import()。

@airalogy/airalogy-bd 需要什么版本的 Node.js?

package.json 的 engines 字段要求 Node.js >=22.13.0。版本不符时 npm 默认只给出警告,开启 engine-strict 后会拒绝安装。

@airalogy/airalogy-bd 可以商用吗?

@airalogy/airalogy-bd 使用 Apache-2.0 许可。宽松许可:允许商业使用、修改和再分发,并附带明确的专利授权;分发时需保留许可与 NOTICE 文件,修改过的文件要注明改动。以上为概括,不构成法律意见,请以许可原文为准。

@airalogy/airalogy-bd 的下载量有多少?

根据 npm 官方下载统计,@airalogy/airalogy-bd 在 2026/10/05 – 2026/11/03 这 30 天内被下载 4,764 次,日均约 159 次。下载量会把 CI 构建、镜像同步和作为其他包依赖的安装一并计入,适合横向比较热度,不能直接等同于使用人数。

@airalogy/airalogy-bd 还在维护吗?

最新版本 1.14.1 发布于 2026/11/02(4 天前);至今共发布 27 个版本,其中过去 12 个月发布了 27 个;首次发布于 2026/10/26。发布频率只是参考信号:功能稳定的工具可能很少需要更新,建议结合源码仓库的 issue 和提交记录判断。