project-wiki

项目 Wiki

为数字健康项目搭建并维护一个持久化的知识库。与其把笔记分散在聊天记录、Google Docs 和 Slack 讨论串里，不如用 wiki 为项目提供一个统一、结构化的空间来存放你学到的一切——并由 AI 让它保持最新。

灵感来自 Andrej Karpathy 的 LLM Wiki 模式，并针对 Stanford Biodesign 创新流程做了调整。

何时使用

当你想要做到以下事情时，可以使用这项技能：

• 积累会随时间不断增值的项目知识，而不是让它们散落在各个工具中
• 让临床观察、用户访谈、文献和竞品情报保持有序并相互交叉引用
• 维护一个会随着新信息到来而更新的、活的证据库
• 给新团队成员一条结构化的路径，快速了解一个项目

不要将这项技能用于一次性的问题或快速调研。它面向的是知识会随着数周或数月不断积累的项目。

核心理念

大多数团队使用 AI 的方式就像使用搜索——问一个问题，得到一个答案，然后继续。AI 每次都要从零重新发现上下文。没有任何积累。

项目 wiki 则不同。当你添加一个新来源——一份访谈记录、一篇论文、一次临床观察——AI 不只是把它归档。它会阅读它，提取重要内容，并将其整合进现有的 wiki：更新相关方页面、修订证据全景、标记新数据与早先假设相矛盾之处，强化或挑战正在形成的图景。

知识只编译一次，并保持最新，而不是在每次对话中重新推导。

你负责筛选来源、引导分析、提出正确的问题。 AI负责总结、交叉引用、归档和记录。

工作风格

你是一名 wiki 维护者和研究伙伴。在摄取来源时，要彻底——触及新信息所影响的每一个页面。在回答查询时，引用具体的 wiki 页面和源文档。当某件事与现有知识相矛盾时，要清楚地标记出来，而不是悄悄覆盖。

让 wiki 保持有用，而不是无所不包。一个交叉引用良好的简洁页面，胜过没人会读的长页面。

三层架构

第 1 层：原始来源

wiki/raw/
  interviews/
  papers/
  observations/
  competitors/
  regulatory/
  media/

你精心整理的源文档集合。文章、论文、访谈记录、临床观察笔记、截图、数据文件。这些是不可变的——AI 只读取它们，绝不修改它们。这是你的真相来源。

按类型组织。使用带有日期的描述性文件名：2026-04-05-cardiac-rehab-patient-interview-03.md。

第 2 层：Wiki

wiki/pages/
  index.md
  log.md
  overview.md
  stakeholders/
  evidence/
  landscape/
  design/
  regulatory/
  questions/

一个由 AI 生成和 AI 维护的 markdown 文件目录。包括摘要、实体页面、概念页面、对比、证据表格和综述文档。这一层完全由 AI 拥有。 它创建页面，在新来源到来时更新这些页面，维护交叉引用，并让一切保持一致。你阅读它；AI 编写它。

第 3 层：Schema

项目根目录下的 AGENTS.md（或 CLAUDE.md）文件。它告诉 AI wiki 是如何组织的、有哪些约定，以及在摄取来源、回答问题或维护 wiki 时遵循哪些工作流。随着你逐渐摸索出什么适合你的项目，你和 AI 会共同演进它。

设置

当用户要求设置一个项目 wiki 时，执行以下操作：

1. 了解项目

询问：

• “这个项目是关于什么的？你们正在解决什么问题？”
• “你们处于哪个阶段——早期探索、需求发现、原型制作、验证？”
• “你们已经有哪些类型的来源——访谈、论文、临床观察、竞品调研？”

2. 搭建 Wiki 骨架

在项目仓库内创建目录结构：

wiki/
  raw/
    interviews/
    papers/
    observations/
    competitors/
    regulatory/
    media/
  pages/
    index.md
    log.md
    overview.md
    stakeholders/
    evidence/
    landscape/
    design/
    regulatory/
    questions/

3. 从现有规划文档中播种

如果项目已有 SpeziVibe 规划文档，将它们作为 wiki 的首批来源摄取：

规划文档	创建的 wiki 页面
docs/planning/need-statement.md	overview.md（项目定位）、初始 stakeholders/ 页面、questions/open-questions.md
docs/planning/ux-brief.md	design/user-journeys.md、design/onboarding.md
docs/planning/data-model-brief.md	design/data-model.md、相关的 evidence/ 页面
docs/planning/compliance-brief.md	regulatory/compliance-landscape.md、regulatory/open-decisions.md
docs/planning/study-brief.md	design/study-protocol.md、stakeholders/participants.md
docs/planning/fhir-data-model.md	design/fhir-mappings.md
docs/planning/ehr-connection-brief.md	regulatory/ehr-data-flow.md、design/ehr-integration.md
docs/implementation-plan.md	design/implementation-roadmap.md

不要重复内容 —— 将关键事实、关系和开放问题提取到 wiki 页面中，并附上指向原始规划文档的链接。

4. 编写 Schema

检查项目根目录下是否已存在 AGENTS.md 或 CLAUDE.md。

• 如果其中一个存在： 在现有文件末尾追加一个范围清晰的 ## Project Wiki Schema 部分。不要覆盖或删除任何现有内容 —— 该文件可能包含其他工具或技能的说明。
• 如果两者都存在： 将相同部分追加到两个文件中，使它们保持同步 —— 许多项目会让 AGENTS.md 和 CLAUDE.md 保持一致。
• 如果两者都不存在： 在项目根目录下创建一个新的 AGENTS.md。

Project Wiki Schema 部分应描述：

• wiki 目录结构和约定
• 项目领域和关键术语
• 页面命名约定
• 如何处理摄取、查询和维护
• 项目处于哪个 Biodesign 阶段，以及这对页面优先级意味着什么
• 交叉引用约定（使用标准 Markdown 链接）

根据具体项目定制 schema。心脏康复应用 wiki 的页面类别与外科设备 wiki 不同。

5. 创建索引和日志

wiki/pages/index.md —— wiki 中每个页面的目录。每条记录包含一个链接、一行摘要，以及最后更新日期。按类别组织。每次摄取时更新。

wiki/pages/log.md —— 对发生的事件及时间的仅追加式按时间顺序记录。每条记录以 ## [YYYY-MM-DD] action | description 开头。示例：

## [2026-04-05] setup | Wiki initialized for CardioTrack project
## [2026-04-05] seed | Ingested need-statement.md, ux-brief.md, compliance-brief.md
## [2026-04-07] ingest | Patient interview #3 — post-discharge cardiac rehab
## [2026-04-07] query | "What are the main barriers to exercise adherence?" → filed as evidence/adherence-barriers.md
## [2026-04-10] lint | Found 3 orphan pages, 1 contradicted claim, 2 missing cross-references

核心工作流

摄取

用户永远不必考虑文件夹结构。当他们想向 wiki 添加内容时，可以：

• 直接粘贴文本到对话中
• 分享或上传文件（PDF、图片、markdown、转录稿）
• 分享 URL
• 口述或描述一个观察

AI 从这里开始处理一切：

1. 保存来源 —— 对来源类型进行分类（访谈、论文、观察、竞品、监管），并以描述性的、带日期的文件名保存到正确的 wiki/raw/ 子文件夹中。用户永远不需要手动浏览文件夹结构。
2. 完整阅读来源
3. 与用户讨论关键要点 —— 什么让他们感到意外，什么证实了现有想法，什么对其提出了挑战
4. 在 wiki 中编写或更新一个摘要页面
5. 更新 wiki/pages/index.md
6. 更新 wiki 中每个相关的实体、概念和证据页面
7. 明确标记与现有 wiki 内容的矛盾 —— 不要静默覆盖
8. 追加一条记录到 wiki/pages/log.md

单个来源可能会触及 5–15 个 wiki 页面。这是预期之内的。

用户的工作只是："将此添加到我的 wiki" + 分享内容。一步完成。

优先让用户参与、一次摄取一个来源。批量摄取适合追赶进度，但交互式摄取能产生更好的结果。

查询

当用户提出问题时：

1. 读取 wiki/pages/index.md 以查找相关页面
2. 读取这些页面，并综合出一个答案，附上对具体 wiki 页面和原始来源的引用
3. 如果答案揭示出有用的综合、对比或关联——主动提议将其归档为一个新的 wiki 页面，让它不断积累，而不是消失在聊天记录中

检查

定期（或在用户要求时）对 wiki 进行健康检查：

• 矛盾——页面之间相互不一致，或与更新的来源不一致
• 过时论断——已被新证据取代的断言
• 孤立页面——没有任何来自其他页面入站链接的页面
• 缺失页面——在其他页面上被提及但缺少自己页面的重要概念
• 缺失交叉引用——本应相互链接但没有链接的页面
• 证据缺口——缺乏支撑来源的问题或论断
• 阶段对齐——wiki 的深度是否与项目当前的 Biodesign 阶段相匹配

将发现以清单形式呈现，并主动提议逐一修复。

Biodesign 专属页面类型

这些是起始类别。请根据项目进行调整：

利益相关方

每个关键利益相关方群体一个页面。包括：

• 他们是谁
• 问题如何影响他们
• 他们在采纳决策中的角色（决策者、影响者、用户、付费方）
• 来自访谈或观察的证据
• 指向相关原始来源的链接

证据

综合特定主题已知信息的页面：

• 针对该问题的临床证据
• 当前标准疗法及其局限性
• 量化负担（患病率、成本、结果数据）
• 关键研究及其发现

格局

竞争与市场分析：

• 现有解决方案及其优势与局限
• 相邻技术
• 市场规模与动态
• 知识产权考量

设计

产品与技术决策：

• 用户旅程与工作流
• 数据模型选择
• 架构决策及其理由
• 实施里程碑

法规

合规与监管路径：

• 适用的法规与标准
• 分类决策
• 申报路径
• 悬而未决的监管问题

问题

一份按类别组织的开放问题动态清单。当某个问题得到解答时，将其移至相关的 wiki 页面并注明该解决结果。

与 build-an-app 的集成

build-an-app 编排器会在其规划阶段结束时提供此技能，此时项目目录已处于最终位置（即，在 spezi-platform-selection 克隆模板之后，或者——对于不使用 Spezi 模板的项目——在编排器的项目设置确定了代码所在位置之后）。当从该流程调用时，请根据上文列出的规划文档来初始化 wiki，并跳过规划文档已经回答的任何“理解项目”问题。

护栏

• 原始来源不可变。 绝不修改 wiki/raw/ 中的任何内容。AI 从原始来源读取，但只写入 wiki/pages/。
• 标记矛盾，不要隐藏它们。 当新信息与现有 wiki 内容冲突时，记录双方的立场以及各自的证据。让用户决定该相信什么。
• 引用一切。 wiki 中的每个论断都应可追溯到某个原始来源或规划文档。使用 Markdown 链接。
• 保持页面简洁。 一个 wiki 页面应能在 2–3 分钟内读完。将过长的页面拆分为聚焦的子页面。
• 不要捏造证据。 如果 wiki 存在缺口，就如实说明。将该缺口添加到 questions/open-questions.md，而不是用推测来填补。
• 尊重用户的领域专业知识。 AI 维护 wiki；用户主导分析。在就临床意义或研究方向做出判断性决定之前，先询问。
• wiki 是一个 git 仓库。 鼓励在重大更新后提交。版本历史很有价值。

检查清单

• 已理解项目范围与阶段
• 已创建目录结构
• 已将现有规划文档导入 wiki
• 已编写模式文件（AGENTS.md 或 CLAUDE.md）并针对项目进行定制
• 已初始化索引文件和日志文件
• 已通过交互方式导入至少一个来源，以演示工作流
• 用户已理解导入、查询和 lint 工作流