在一个商业软件项目中，我们曾用一组技能（skills）引导智能体（Agent）参与项目知识维护。
需求需要澄清，决策需要记录，任务需要拆解，验收需要证据，复盘需要回到项目里。这些不是新方法，而是早已被认可的软件工程实践。真正困难的是执行成本。项目进入持续交付后，团队很难一直承担这些文档的维护工作。
我们把信息摄入、确认写入、交付规划、实现复核和状态报告拆成不同的 skills，让智能体在明确的权限边界内承担整理、检查和写回工作。这套方法后来被称为 knowledge-workflow。
它在项目中解决了实际问题，相关经验后来也在其他商业项目中得到验证，并逐步推广到公司内部的其他团队。不同团队会按自己的流程裁剪，使用中发现的问题和建议则通过反馈（feedback）机制汇总并回到维护团队，继续用于完善整套方法。
但效果越明确，边界也越清楚。
knowledge-workflow 很适合软件开发工程管理。可当我们面对的不是需求、架构、测试和发布，而是选题、客户、报价、工艺参数或现场异常时，这套以软件工程为默认模型的 skills 还能自然工作吗？
这个问题，最终把我们带向了 Forma。
forma 在拉丁语中有“形态、形式”之意。这个名字恰好呼应了产品的核心理念：Forma 不替使用者预设唯一的知识模型，而是提供定义知识形状、创建方式和协作规则的基础能力，让不同领域的知识获得适合自己的形态。
先把 Forma 的核心设计说清楚，后面的转向会更容易理解。
-
一切都是 Markdown
Forma 不是把笔记搬进另一个应用。知识仍然落在仓库里的 Markdown 文件、明确的配置和可检查的结构中。团队可以继续使用熟悉的编辑器、Git、review 和自动化工具，智能体也能直接读取、引用和修改这些文件。
-
Workspace，先划清边界
Forma 以 workspace 作为知识系统的稳定入口，明确哪些内容属于这里，哪些配置决定它们如何被分类、创建和检查，哪些 guideline 必须被共同遵守。人、新成员和智能体不必先在整个仓库里猜测上下文边界。
-
Markdown，也可以有结构
Forma 会把重复出现的知识形状明确表达出来：用分类体系（taxonomy）和分类项（term）组织内容分组，用结构定义（schema）规定关键字段，用创建规则和模板（template）降低正确创建内容的成本，用视图（view）生成列表、表格、看板或关系图等只读投影，再通过检查发现引用、结构和配置问题。
-
guideline 即 skill
Forma 面向智能体的设计，不是增加一个聊天框。维护规范（guideline）不是只写给团队成员看的静态文档，也不只是藏在提示词（prompt）里的智能体指令。它可以通过面向智能体的 skill（Agent-facing skill）被加载执行。规则进入 workspace 后，团队成员和智能体看到的是同一套维护原则、权限边界和操作步骤。
-
问题要尽早暴露
Forma 承认团队成员和智能体都可能直接修改文件，因此不会把“只能通过某个应用编辑”当作安全边界。检查和诊断会尽早暴露字段缺失、引用异常、链接断开和上下文健康问题，让开放文件仍然可以被长期维护。
有效，不等于通用
先说清楚一点：knowledge-workflow 并不是一套不能修改的固定模板。
团队可以调整 schema、template、规则（rules）、目录结构和工作流支持文件（workflow support files），也可以增减 skills，让它适应不同的软件项目。开源项目、SaaS 产品、内部平台和技术咨询交付，都可以在同一套软件工程语境中做出自己的裁剪。
这也是它能够在不同团队中推广的原因。大家不需要接受完全相同的目录和字段，只需要保留那些已经在实践中证明有用的边界：讨论不等于事实，建议不等于批准，执行不等于完成，项目状态也不能只靠聊天记录判断。
但它的默认知识模型仍然围绕软件产品开发和工程协作展开。它自然关心调研、产品、用户故事（user story）、设计、架构、决策、测试用例、实验、发布、任务、看板（Kanban）、实现和复核。
这些概念放在软件项目里很顺畅。需求进入产品知识，用户场景成为用户故事，技术取舍成为架构决策，实现任务连接验收条件，发布再连接测试和交付结果。
换到其他领域，情况就不一样了。
建筑项目管理关心场地、图纸、材料、合规、分包商和验收节点；自媒体内容创作关心选题、素材、脚本、渠道、反馈和复用；企业销售关心客户、商机、异议、案例和输赢复盘；工厂流程管理关心工艺、设备、参数、质检、异常和变更。
这些领域当然也可以继续修改原有目录和 skills，但需要改变的已经不只是几个字段。内容分类、schema、template、状态流转、创建入口、检查方式和 skill routing 都要重新设计。
问题不在于“能不能改”，而在于每进入一个新领域，通用化成本都会重新发生。
Skills 擅长执行，知识工作区负责表达
skills 很适合描述智能体应该怎样完成一类工作。
面对未确认信息时，先进行知识摄入（intake），再决定是否进入共享知识；面对已经批准的更新时，按规则完成知识捕获（capture）；面对交付任务时，先做交付规划（planning），再进入实现（implementation）和复核（review）；项目推进后，再通过状态报告（status report）重新看见全局状态。
这些都是执行问题。skill 可以说明输入是什么、允许做什么、应该产出什么，以及什么时候必须停下来让人确认。
但领域模型回答的是另一组问题：
- 这个领域有哪些内容类型？
- 每种内容需要保留哪些字段？
- 新内容应该从什么 template 开始？
- 哪些内容应该通过什么 view 呈现？
- 哪些引用、状态和关系需要检查？
- 哪些知识属于团队共享，哪些只是成员本地状态？
- 哪些 guideline 必须同时约束团队成员和智能体？
如果这些定义主要藏在 skills、rules 和目录约定里，会出现两个直接问题。
每扩展一个领域，都要重新解释一套知识结构和 skill 行为。更麻烦的是，很多约束只能依赖智能体按说明执行，知识工作区本身并不能稳定地创建、呈现和诊断这些结构。
这并不是 skills 的失败。相反，它说明 skills 承担了一部分本应由知识工作区负责的事情。
我们需要的，不是为每个领域继续手写一套越来越大的 skills，而是一个能够让不同领域定义自身知识结构和维护规则的通用工作台。
Forma 把能力放到 Workspace 层
Forma 可以理解为对这些实践的进一步抽象。
它以 workspace 为边界，把维护知识库时反复遇到的问题放进一套显式配置：这里有哪些内容类别，每类内容需要保留什么信息，新内容怎样从正确的起点创建，日常通过什么方式查看，团队成员和智能体又需要共同遵守哪些规则。
对应到 Forma 中，taxonomy 定义分类体系，term 表示其中的具体分类，schema 约束同类内容需要保留的字段。创建规则决定新内容存放在哪里、如何命名，template 提供起始内容。view 负责读取和呈现，guideline 则规定协作边界。检查机制再负责发现结构、引用和配置问题。
这样一来，Forma 关心的就不只是“智能体应该怎样做”，还包括“知识本身应该如何被分类、创建、读取、检查和接手”。
这里需要特别区分产品能力与业务概念。Forma 原生提供的是 workspace 边界、taxonomy 与 term 等通用配置机制，以及围绕内容创建、呈现和检查的能力；research、task、opportunity 或 process 等内容类型，都由使用者根据自己的领域定义。space 则是当前配置与 CLI 对一类内容分组的投影和操作称呼，并不是与 taxonomy、term 并列的原生配置节点。
软件项目可以定义自己的 product、task、decision 和 release；内容团队可以定义 research、publication、channel、campaign 和 offer；销售团队可以定义 account、opportunity、objection 和 case study；工厂可以定义 process、machine、incident 和 change record。
这些领域不需要被迫共享同一套目录。它们只需要共享一组更底层的能力：知识有类型，内容有形状，创建有模板，维护有规则，结果可以检查。
guideline 在这里尤其重要。它既是团队成员可以阅读和 review 的维护规范，也可以成为智能体执行工作前加载的 skill。规则不再只存在于某个人的习惯或某次 prompt 中，而是进入 workspace，成为人和智能体共同遵守的协作边界。
不同领域，需要不同的知识形状
这种抽象的价值，放到具体业务里会更容易看见。
自媒体内容创作
一个内容团队或一人公司（OPC）要维护的，通常不是 user story 和 release，而是选题、素材、脚本、发布记录、渠道反馈、转化线索和可复用内容资产。
用 Forma 时，可以把 research 定义成素材和案例，把 publication 定义成待发布内容，把 channel 定义成分发平台，把 campaign 定义成一轮发布计划，再用 offer 承接最终的产品或服务。
一条 research 可以固定记录来源、关键判断、可引用片段、可信度和后续用途；一篇 publication 可以记录目标读者、核心痛点、关联素材、渠道、状态和复用潜力。schema 让这些信息成为稳定约束，template 则让每次新建内容时都从正确形状开始。
对应的 guideline 可以要求智能体：写作前先读取关联 research 和目标 channel；引用材料时保留来源；没有明确读者和渠道的内容只能停留在 draft；发布后把互动反馈、转化线索和可复用片段写回 workspace。
这样，智能体不只是“再生成一篇文章”，而是在选题、素材、发布、反馈和复用之间协助维护内容资产。
企业销售知识沉淀
很多销售团队已经有客户关系管理（CRM）系统、商机阶段和会议记录。Forma 不需要替代这些系统，它更适合补上那些难以在流程工具中长期沉淀的经验：客户为什么会买、哪些异议反复出现、什么案例最有效，以及一次失败暴露了什么定位问题。
团队可以定义 account、opportunity、objection、case study、proposal、meeting note 和 win-loss review。其中，opportunity 可以记录客户行业、核心痛点、决策标准、关键干系人、主要异议、下一步和外部 CRM 链接；objection 则保留客户原话、真实顾虑、可用证据、关联案例和处理状态。
guideline 可以要求智能体在准备 proposal 前检查仍然有效的 objection 和可复用的 case study；整理会议纪要时提取客户原话、异议、下一步和证据缺口；商机结束后生成 win-loss review，但不替代 CRM 的正式阶段记录。
CRM 继续负责销售流程，Forma 负责让销售经验有结构地留下来。智能体也就不只是搜索“某个客户说过什么”，而是能够帮助团队比较异议、复用案例并发现方案缺少的证据。
工厂工艺和流程管理
工厂现场的知识不只有标准作业程序（SOP），还包括设备参数、工艺条件、异常处理、质检标准、班组交接、变更记录、维修经验和安全约束。
团队可以按现场语言定义 process、machine、parameter、inspection standard、incident、maintenance note 和 change record。一个 process 需要记录工序、设备、物料、关键参数范围、质检节点和风险；一个 incident 需要记录设备、批次、现象、实际参数、临时处理和验证结果；一个 change record 则要说明变更原因、影响范围、审批状态和受影响的 SOP。
对应的 guideline 可以要求智能体区分“已经批准的工艺标准”和“尚未验证的现场经验”；incident 必须关联对应的 process、machine 和 inspection standard；参数范围发生变化时，先生成 change record 并进入审批，而不是直接改写 SOP。
这样，智能体可以帮助现场人员整理、检索和发现遗漏，却不会把未经确认的口头经验直接升级为正式流程。一次异常处理也能继续回到工艺参数、检查标准和培训材料中，而不是只停留在某个人的经验里。
这些场景放在一起看，schema、template 和 guideline 的分工就很清楚了：schema 定义知识需要长成什么样，template 降低每次创建正确内容的成本，guideline 则把团队成员和智能体共同遵守的工作规则沉淀下来。
Forma 要提供的，正是这种让不同领域表达自身知识形状和协作规则的能力。
从项目实践到通用产品
knowledge-workflow 证明了一件事：智能体可以参与知识治理，但前提是它知道从哪里读取事实，按什么规则工作，拥有什么权限，以及完成后需要留下哪些证据。
它也让我们看到，skills 不能独自承担整个知识系统。智能体仍然需要 intake、capture、planning、implementation、review 和 report，但这些动作最好建立在一个结构清楚、规则明确、健康状态可检查的 workspace 之上。
Forma 并不是从零否定 knowledge-workflow，也不是要用 workspace 取代 skills。它把商业项目中验证过的经验继续向下抽象：从一套面向软件工程的知识工作流，走向一套允许不同领域定义自身结构的知识工作台。
其中，与软件产品研发有关的实践经验，已经被提炼到 Forma 的 software-product-rd-workspace 示例中。这个示例使用一个虚构产品，把调研、产品方向、架构、设计、交付任务、验证、发布、指标和实验组织在同一个 workspace 里。它不是对原商业项目的直接复制，而是把经过验证的知识类型、协作边界和推进关系整理成一个可以直接阅读、检查和复制的研发 workspace。
人和智能体共享的，也不再只是“怎样做事”的说明，而是同一份可以持续维护、检查和接手的知识系统。
对使用者意味着什么
如果你正在软件项目中引入智能体，knowledge-workflow 留下的实践仍然值得借鉴：把讨论和事实分开，把规划和变更分开，让任务回到需求与决策，并用验证证据判断是否完成。
但如果你的目标不只是维护一个软件项目，而是要把内容、案例、流程、交付经验或专家判断沉淀为长期知识资产，你会遇到更通用的问题：
- 我的领域有哪些内容类型？
- 哪些内容需要固定字段和 template？
- 哪些材料可以进入共享知识？
- 哪些 guideline 应该同时约束团队成员和智能体？
- 怎样检查知识库是否仍然健康？
- 怎样让新成员或智能体快速接手？
这些问题已经超出一组面向软件工程的 skills。
这正是 Forma 要进入的位置：让知识继续留在开放、可读的 Markdown 中，同时拥有可以定义、执行和检查的结构；让每个领域说自己的语言，也让团队成员和智能体围绕同一套知识继续工作。
从仓库开始了解 Forma
Forma 目前仍处于公开测试（public alpha）阶段，更适合试用、评估和反馈，还不应被视为成熟的生产系统。
了解 Forma 并不需要先读完一套产品手册。Forma 的产品文档、设计决策和研发知识，本身就由 Forma workspace 管理在 Git 仓库中。你可以直接克隆（clone）项目，让自己熟悉的智能体应用进入这个仓库，再从真实内容和配置开始提问。
git clone https://github.com/choral-io/choral-forma.git
cd choral-forma接着，按照仓库中的 Installing Forma 安装当前版本的 Forma CLI，并确认命令可用：
forma --version然后在这个目录中打开你常用的智能体应用，可以从下面这句话开始：
请先运行 forma skills get forma-cli-core，检查当前 workspace，然后基于仓库中的产品文档、设计决策和实际配置，向我介绍 Forma 的核心理念、当前能力，并带我选择一个最小场景开始使用。这也是 Forma 希望提供的体验：知识不必先被搬进另一个封闭系统。仓库本身就是可以阅读、检查和继续工作的入口，团队成员和智能体从同一份内容开始协作。Forma 想推动的，不只是把知识写下来，而是让知识逐渐变得能够被接手。