Personal Publishing Framework
Personal Publishing Framework

把作品留在可长期掌握的源文件里,让每一次发布都可以重新构建。

PPF 把“作品本身”和“发布出来的格式”分开管理。网页、EPUB、PDF、DOCX 或印刷版都可以更换;真正需要长期保存的是能够持续维护、检查和重新生成这些输出的源内容与发布记录。

第一次接触整个体系?

如果你还不知道 AHICP、PPF、Vault Interface 和 Starter 怎样配合,可以先从 AHICP 介绍页开始。那里从使用者的角度解释整套体系,并告诉你怎样把启动指令交给 AI。

PPF 的核心思想:源内容和发布形式不是一回事

源内容长期保留

正文、数据、图片、元数据和项目结构应由创作者持续掌握,而不是只存在于某个编辑器或发布平台。

格式只是输出

HTML、EPUB、PDF、DOCX、LaTeX 和印刷文件都是从源内容生成的版本,可以替换,也可以重新生成。

构建过程可以复现

记录使用了什么工具、版本和步骤,使同一份源内容能够在以后重新构建,也更容易排查问题。

发布状态清楚可查

区分“已经构建”“可以访问”“正式发布”“冻结版本”和“归档”,避免把一次临时输出误当成正式版本。

为什么要把出版拆成五个环节

很多出版问题来自把“写完了”“生成了文件”“网站能打开”“正式发布了”混成一件事。PPF 把这些状态拆开,使每一步都能单独检查和重新执行。

Source · 源内容
作品真正长期维护的基础:正文、数据、资产、元数据和项目结构。
↓
Build · 构建
把源内容转换成网页、电子书、文档或其他格式。构建成功只表示“输出生成了”,不自动表示已经发布。
↓
Publish · 发布
让某个输出可以被目标读者访问。发布权限、访问范围和源仓库是否公开是不同问题。
↓
Release · 版本
明确标记一个有意发布的版本,并把它和当时的源状态对应起来。
↓
Archive · 归档
保存足够的信息,使以后能够理解这个版本来自哪里,并在需要时重新构建。
这套分层的价值在于:换编辑器、换构建工具、换托管平台,都不必重新定义“作品是什么”。作品的长期身份留在源内容和版本记录中。

两种发布节奏

Continuous Web · 持续网页

源内容更新后,网页可以自动验证、构建和准备部署。适合持续更新的网站、知识库、研究记录和项目文档。

重点:持续更新不等于自动公开。是否公开仍由发布授权和访问策略决定。

Edition · 明确版本

EPUB、PDF、DOCX、LaTeX、印刷版等通常在明确需要时生成,并可在发布前单独检查和冻结版本。

重点:同一份源内容可以产生多个正式版本,而不需要维护多套互相漂移的正文。

隐私、发布和访问范围彼此独立

原创或未发布项目默认把源文件仓库保持为 private(私有)。与此同时,Continuous Web 可以先准备成 restricted + authenticated(受限并需要认证);以后网页公开,也不要求源仓库一起公开。

这意味着“源文件在哪里”“网页是否已经发布”“谁可以访问网页”是三个不同的决定。PPF 把它们分开记录,避免平台默认设置替你作出发布决定。

PPF 在整个体系中的位置

AHICP

管理探究、证据、决定、项目记忆和 AI 协作方式。

PPF

管理源内容到构建、发布、版本和归档的生命周期。

Vault Interface

只公开必要的项目元数据,不要求暴露私人源内容或工作记录。

Starter

让 AI 按项目需要组合、采用和升级这些组件。

进一步了解

PPF 不依赖 AI,也不规定人和 AI 应怎样协作;它只负责出版生命周期本身。

Personal Publishing Framework

Keep the source durable, and treat every publication format as something you can rebuild.

PPF separates the work itself from the formats used to deliver it. Websites, EPUBs, PDFs, DOCX files, and print editions can change; the durable source and publication record remain the basis from which those outputs can be rebuilt.

New to the full stack?

If AHICP, PPF, Vault Interface, and Starter are unfamiliar, begin with the AHICP introduction. It explains the system from the user’s point of view and shows how to hand the technical setup to an AI.

The core idea: source and publication format are different things

Keep the source durable

Text, data, images, metadata, and project structure should remain under the creator’s control instead of living only inside one editor or publishing platform.

Treat formats as outputs

HTML, EPUB, PDF, DOCX, LaTeX, and print files are generated forms of the work. They can be replaced or regenerated.

Make builds reproducible

Record the tools, versions, and steps used to transform the source so the same work can be rebuilt and problems can be diagnosed later.

Make publication state explicit

Distinguish a successful build from something that is accessible, formally released, versioned, or archived.

Why publishing is split into five stages

Many publishing mistakes come from treating “finished writing,” “a generated file,” “a reachable website,” and “a formal release” as the same event. PPF separates them so each stage can be checked and repeated independently.

Source
The durable basis of the work: text, data, assets, metadata, and project structure.
↓
Build
Transform the source into web, ebook, document, or other formats. A successful build means the output exists; it does not mean it has been published.
↓
Publish
Make an output available to its intended readers. Publication, audience access, and repository visibility remain separate decisions.
↓
Release
Name or freeze an intentional version and connect it to the corresponding source state.
↓
Archive
Preserve enough information to understand where the release came from and rebuild it later.
Because the source is independent from its delivery formats, changing an editor, build tool, or hosting provider does not redefine the work itself.

Two publishing rhythms

Continuous Web

A website can be validated, rebuilt, and prepared for deployment whenever accepted source changes. This works well for living sites, knowledge bases, research notes, and project documentation.

Continuous updates do not imply automatic public release. Publication authorization and reader access remain separate.

Edition publishing

EPUB, PDF, DOCX, LaTeX, and print-ready outputs are usually generated when an edition is explicitly needed and can be reviewed or frozen before release.

One durable source can produce several formal editions without maintaining several drifting copies of the text.

Privacy, publication, and audience access are separate decisions

Original or unpublished projects keep the source repository private by default. A Continuous Web build can still be prepared as restricted and authenticated; later making the website public does not require making the source repository public.

In other words, where the source lives, whether an output is published, and who may read it are different pieces of state. PPF records them separately instead of letting platform defaults decide for you.

Where PPF fits in the stack

AHICP

Handles inquiry, evidence, decisions, project memory, and AI collaboration.

PPF

Handles the lifecycle from source through build, publication, release, and archive.

Vault Interface

Publishes only the project metadata that should be public, without exposing private source or working records.

Starter

Lets an AI compose, adopt, and upgrade the components for a project.

Go deeper

PPF does not require AI and does not define how humans and AI should collaborate. Its scope is the publishing lifecycle itself.