完全虚构的 PRD 代表页：同一个 build 显示目标、范围、验收、事实状态和来源定位。
查看画廊与说明用途与结果
最快了解这个项目
为什么需要它
分别维护需求文档、评审材料和执行表时，同一个日期、范围、负责人、指标或验收口径很容易出现多个版本。更危险的是来源已经变化，旧成品看起来仍然完整，却没人知道它引用了失效证据。这个项目把来源版本、决定理由、正式构建和变更影响放在一条可核对的本地链里。
举个实际例子
我可以说：“用这份立项说明、评审纪要和执行计划做一套交付材料；先把互相冲突的日期、范围和负责人列出来，这一轮只生成 PRD。”项目会先告诉我三份来源覆盖了什么、哪些事实可以采用、哪些仍要决定；确认后只生成本轮需要的 PRD 和追溯清单，不提前制作评审演示或执行表。
最后我会得到什么
轻量工作支持直接交回分析、沟通建议或本轮请求的单件文件。进入交付包并请求完整输出时，得到六个可追溯且口径一致的文件：PRD.md、manifest.json、traceability.csv、产品需求文档.docx、项目评审.pptx 和执行跟踪表.xlsx；只要 PRD 时不等待另外两类 Office 文件。不同事实版本各用自己的目录，同一版本可以重新生成，不会互相覆盖。我还会知道来源、已确认事实、假设与冲突、哪些结果已经过期，以及本轮真正写到了哪一步。
可以正式构建
普通工作先交回可用的分析、沟通建议或单件文件；需要交付包时，事实确认后只生成这轮点名的文件，并说明哪些格式已做成、哪些还没做。
需要确认
关键事实缺来源、互相冲突或资料已经换版时先交待确认草稿。生成超时也要先看实际留下的文件，不能凭报错认定什么都没发生。
当前不可用
资料、保存状态或某种 Office 制作环境不可用时保留已完成的来源、判断和文件，说明停在哪一步；不重复建包或把预览当正式成品。
从哪里开始
普通工作问题直接在对话中处理；只有几份持续变化的来源要反复支撑 PRD、评审或跟踪文件时，才建立现有交付包。
需要准备什么
- 本次工作目标与想要的结果
- 需要建包时选定的 2 至 5 份资料
- 本轮所需的文件格式
从开始到拿到结果
- 1先判断工作类型
沟通、分析或单件文件直接处理；持续来源与多种交付物才建立包。
- 2固定选定版本并核对事实
只读本人选的资料，区分已确认事实、假设、冲突和未知；日期、金额及负责人不凭印象补齐。
- 3从同一事实版做本轮文件
先生成可追溯的核心内容，只制作此次需要的 DOCX、演示或表格，其他格式以后可补。
- 4来源变动时有界重做
新版本只影响相关判断与旧构建，保留以前版本；交回当前文件、验收状态和仍需决定的问题。
从这些需求了解功能
从一个实际问题看它怎样处理、交回什么；当前能做到哪一步和仍有哪些限制，也写在对应说明中。
可视化证据
工作支持与交付 的图片与证据等级
单击图片查看完整大图；每张图同时说明它能证明和不能证明什么。打开后可缩放、滚动查看细节，也可关闭或切换上一张、下一张。
项目指标与相关入口查看规模、覆盖范围和关联能力
当前项目指标
- 正式输出
- 6 个文件
- 现实工作包总数
- Unknown（未知）
- 历史真实变化验收
- 0
- 历史恢复验收
- 0
工作交付怎样保持一致 · 7 步
只用这次选定的资料，让本轮文件说同一版事实
普通工作可以直接分析和交付；只有几份资料会持续变化、多个文件必须口径一致时，才建立可追溯的交付包。AI负责理解，项目负责记住来源、决定与真实文件状态。
- 先判断这件事真的需要交付包吗
一次回复或单件文件直接做；资料会换版且多份成品要一致时才保存包。
- 本人选资料只用这次点名的几份文件
选择当前有用的立项、纪要或计划，其他目录和旧对话不顺手读取。
- AI核对先说清事实、冲突和未知
把日期、金额、范围、负责人等逐项指回原文；资料多或有冲突时说明真实进展和下一检查点，不拿模板猜。
- 本人取舍只决定真正未定的问题
需要人的选择才问；已有确认和证据由项目保存，不反复让人录入。
- 项目验收确认这一版已可正式制作
项目自己检查来源、事实和待办是否一致；外部文件自称“已通过”不能跳过这一步。
- 按需交付只生成这轮需要的文件
需求文档、评审演示和执行表从同一版事实制作；只要 PRD 时不等待其他格式。
- 资料换版只重看受影响的结论
能在新版唯一找到的原话继续用；失去依据的结论和旧文件标过期，保留历史版本。
本人提供与决定
目标、选定资料和真实冲突- 说明工作目标与这次要交的文件
- 确需建包时明确选定几份当前资料
- 在真实冲突或取舍上作决定
AI协助
理解和专业判断- 从选定资料提炼候选事实并指出原文
- 解释冲突、缺口和可采用的结构
- 根据实际进展说明何时能交，不把机械通过说成真实价值
项目负责
版本、一致性与恢复点- 保存来源版本和决定理由
- 确认正式制作条件并从同一事实版生成请求的文件
- 资料变动后标出过期部分和已完成文件
它负责
- 普通工作问题直接协助理解、沟通、决策和单件交付；确实需要持续追溯时才建包。
- 只保存本人选定的几份资料和这次版本，不读无关目录。
- 把准备进入成品的日期、金额、范围与负责人对回原文，保留确认、假设、冲突和未知。
- 正式制作条件由项目核对，不能靠手写“已通过”或一份漂亮草稿放行。
- 从同一版事实生成本轮要的需求文档、评审演示、跟踪表及必要追溯文件。
- 资料换版时只重新看真正受影响的结论，旧成品保留但会标明是否过期。
- 制作中断先核对实际留下的文件与最近可靠版本，再交回继续位置。
它不负责
- 一次性回复、单件 Word 或表格不强制建包；学习、私人正式材料等仍走所属项目。
- 不扫描未选的目录、账号、邮件、在线文档、仓库或旧对话。
- 不为交付包再建一个 AI 模型、全文搜索服务、监听器或第二份业务状态库。
- 不声称能生成尚未实现的计划、周报或其他未请求文件。
- 不自动发送、审批、邀请、建任务、发布或修改外部系统。
- 合成测试和文件生成速度不等于已在真实工作里节省时间。
- 源码和安装包不能恢复丢失的真实交付包；缺备份时如实说明。
产品思想与设计核心
值得持续追溯时才建包
普通分析与单件文件直接完成；只有来源会持续变化、成品口径必须一致时才增加交付包。
日常工作默认符合中文环境
默认简体中文、中国时区和人民币；需求文档涵盖目标、范围、流程、异常和验收，Word、演示与表格可在常用办公软件中打开。精确格式留在技术层。
来源由本人明确选择
第一次只用本轮点名的少量资料，不扫描同目录、邮箱、账号或旧对话。
先说事实，再做成品
先交回来源覆盖、关键事实、冲突和未知；重要问题没解决时，排版再好也只是待确认草稿。
多种文件共用一版事实
需求文档、评审演示和执行表不能各自手改出不同日期或范围。
正式制作条件由项目自己核对
项目从保存的事实和来源计算是否可制作；手工标成“已通过”或偷偷改动证据不会放行。
决定留有前后原因
确认、驳回、退回和重新定位来源都保留变化与理由；当前记录尚不能冒充完整的多人审批审计。
资料变化只影响相关部分
原话在新版里仍唯一可找到就继续用；消失或不唯一才让相关结论待审。
新旧版本各在自己的目录
下一版不覆盖旧成品；同一当前版本可以重新生成自己的文件，不把部分新旧文件混成一套。
功能证明与真实省时分开
合成材料能生成和检查，只证明这些功能；真实工作值不值得采用，要拿同等质量的直接做法比较。
时间成本决定是否收窄
若建立追溯包反而让首次交付或后续改版更慢，就退回更窄的工作流或单一成品，不因形式专业强行保留。精确比较门槛留在技术依据。
恢复不了就直说
交付包可以保存当前过程，但目前缺数据库丢失后的正式恢复能力；源代码无法反推出真实工作状态。
项目怎样演化到现在
避免几份交付材料各说各话
把选定来源、事实、假设和冲突放在同一版本，需求文档、评审与跟踪文件由共同事实生成。
阶段依据
- 2026-08-31 · 来源、证据、事实与变化影响进入同一最小核心。
21c12e3
来源改了，知道哪些旧结果要重看
旧成品保留，新来源只让真正受影响的事实和构建失效；只要PRD就不等待演示和表格，未确认问题不被手写成功状态掩盖。
阶段依据
- 2026-08-31—09-01 · 质量门、批量入口和Office生成回到实际用户路径。
c9c5dfa–406c3f1 - 2026-09-01 · 0.2.0一致构建与来源重新绑定已有合成验收；不证明现实工作提速或数据库丢失恢复。
c815ea3–73f92f1
不是每件工作都值得先建一个包
普通沟通、判断和一次性文件直接完成；只有来源会持续变化、需要保持多份输出一致时才进入成套流程。专业事实与共同本人背景分工，阶段汇报说实际进展。
阶段依据
- 2026-09-05–09-12 · 不是每件工作都值得先建一个包
7652168
完整项目状态与证据边界
已确认事实
- 产品固定生成6个正式文件；本轮没有全局真实工作包数量证据，总数保持Unknown（未知）。9月1日两套完全合成Office场景中的真实来源变化E2E（端到端验证）和备份恢复验收均为0，这是验收范围，不代表现实没有工作包；时间价值仍是baseline_required。
- 真实工作中的材料理解、沟通、决策、评审与交付都可进入既有项目。轻量支持直接完成；只有明确选入 2–5 份会继续变化的来源，且需要一致产物或持续维护 PRD 时，才建立交付包。
- 相关时从个人理解库读取真实经历、生活重点与取舍；有依据的新本人认识在当前任务回写并回读。工作资料、业务事实、事项和交付仍由本项目负责，个人背景不能冒充已确认业务证据。
- 只有 PRD.md、manifest.json、traceability.csv、产品需求文档.docx、项目评审.pptx、执行跟踪表.xlsx 六个文件；当前没有现成项目计划、周报或汇报产物。
- SQLite（本地状态库）拥有当前事实修订与 build；正式 Office 入口重建 canonical manifest（规范清单）并拒绝手写 ready、事实漂移、过期 build 和跨目录覆盖。
- 事实确认后的确定性 batch 以 15 秒为时间门，分别在状态提交、核心文件生成和 Office 生成后检查。超时表示时间验收失败，不自动撤销已经提交的包或文件；同一 build 的文件逐个替换，也不是跨文件原子事务。
- 新版本中原文仍唯一存在就自动 rebound（重新绑定）；原文消失或匹配不唯一才把事实标为 stale（已过期），引用变化的旧 build 同时过期。
- PRIVATE（私有） main 76521682176b00333fdf579746d4fbcfea88103e；0.2.0 实现 c815ea3daa04d4012200419fa989a9808ab7be36。2026-09-01历史验收：37/37测试与Ruff通过，隔离wheel、两套合成Office E2E（端到端验证）和实现盲自然路由已分层核对；本轮未重跑。
- 合成场景证明功能、质量和安装闭包，不证明真实工作节省时间；现有验收没有覆盖同模型同质量直接处理基线、真实工作包、真实来源变化、导出备份或数据库丢失恢复。本轮不扫描私人工作包补计总数。
- 默认简体中文、Asia/Shanghai、YYYY-MM-DD 与人民币 CNY；使用需求方、产品、研发、测试、负责人、评审人等角色，并按背景、目标、范围、角色与流程、需求、指标、异常、验收、待确认组织 PRD。
当前缺口
- FactReviewEvent（事实审阅事件）记录前后状态、证据和非空理由，但没有 actor（操作人）字段，不能机械回答是谁做了这次决定。
- 当前变更影响粒度是受影响事实与整个旧 build；还没有精确到某个 Office 文件、某个 ArtifactBlock（产物块）或某个页面/工作表的局部影响图。
- 可靠输入仍以本地文本、Markdown 和 CSV 为主；DOCX、PDF、邮件和在线文档需要先由相应能力读取或导出，再作为明确文件进入。
- AI 对来源的分析、事实提取和判断在项目外完成；仓库负责确定性保存、质量门、构建和验收，不内置模型或声称自动理解任意材料。
- 公开 artifacts 调用负责核对 current（当前状态） build 并生成文件；Office 重新导入、PPT 几何重叠、XLSX 公式和全部页面/工作表查看属于合成验收与测试证据，不是每次 builder 调用自动执行的产品门。
- 15 秒时间门在各阶段已写入后检查，不提供整次回滚；核心与 Office 文件也逐个替换，没有跨文件原子事务。超时或替换中断后必须核对实际已提交状态，不能从非零退出推断全部未发生。
- 时间结论仍为 baseline_required：没有同模型、同思考强度、相近输入和同质量的直接处理基线。
- 9月1日验收没有包含真实工作或真实来源变化E2E（端到端验证）；本轮未取得新的现实验收，不能据此断言现实没有工作。两套完全合成Office场景不能替代现实价值和真人判断。
- 没有交付包导出、SQLite 备份、数据库丢失恢复或跨机器迁移入口；Git 只能恢复源码，不能恢复真实工作包。
来源与公开边界
实现位于 PRIVATE（私有）仓库 work-delivery-copilot，当前 main 为 76521682176b00333fdf579746d4fbcfea88103e；0.2.0 行为实现在 c815ea3daa04d4012200419fa989a9808ab7be36 闭合，73f92f1 记录原有实现盲自然路由 E2E（端到端验证），57bf3c6 将既有项目明确为工作支持与交付，并接入相关本人背景；7652168 将进度要求统一为及时事实反馈与有依据的时间区间，移除固定五分钟及准确 ETA 承诺；没有改变 0.2.0 交付引擎字节，旧合成验证保持原观察时间。公开页保留产品合同、数据关系、CLI（命令行入口）、版本、测试、失败、恢复缺口和完全合成图片；不公开任何真实公司资料、工作数据库或交付包。
当前关键技术事实
- 现实结果与历史验收
- 产品固定生成6个正式文件；本轮没有全局真实工作包数量证据，总数保持Unknown（未知）。9月1日两套完全合成Office场景中的真实来源变化E2E（端到端验证）和备份恢复验收均为0，这是验收范围，不代表现实没有工作包；时间价值仍是baseline_required。
- 什么时候进入
- 真实工作中的材料理解、沟通、决策、评审与交付都可进入既有项目。轻量支持直接完成；只有明确选入 2–5 份会继续变化的来源，且需要一致产物或持续维护 PRD 时，才建立交付包。
- 共用本人背景
- 相关时从个人理解库读取真实经历、生活重点与取舍；有依据的新本人认识在当前任务回写并回读。工作资料、业务事实、事项和交付仍由本项目负责，个人背景不能冒充已确认业务证据。
- 当前正式输出
- 只有 PRD.md、manifest.json、traceability.csv、产品需求文档.docx、项目评审.pptx、执行跟踪表.xlsx 六个文件；当前没有现成项目计划、周报或汇报产物。
- 质量与一致性
- SQLite（本地状态库）拥有当前事实修订与 build；正式 Office 入口重建 canonical manifest（规范清单）并拒绝手写 ready、事实漂移、过期 build 和跨目录覆盖。
- 来源变化
- 新版本中原文仍唯一存在就自动 rebound（重新绑定）；原文消失或匹配不唯一才把事实标为 stale（已过期），引用变化的旧 build 同时过期。
- 价值与缺口
- 合成场景证明功能、质量和安装闭包，不证明真实工作节省时间；现有验收没有覆盖同模型同质量直接处理基线、真实工作包、真实来源变化、导出备份或数据库丢失恢复。本轮不扫描私人工作包补计总数。
完整执行流程
- 1判断是否需要交付包
普通工作支持直接完成，单文件调用对应制品能力；只有持续来源 + 多种交付物，或确定会更新的 PRD 才进入包引擎。
- 2创建稳定 package
一次 batch 提交稳定 ID、标题、目标、2–5 份来源、候选事实和本轮所需格式；重复 ID 在写入前拒绝。
- 3冻结来源与证据
保存字节、SHA-256、来源版本和系统计算定位；未选文件不被枚举或读取。
- 4确认事实与理由
事实、假设、冲突和未知分别处理；每次真实状态变化追加审阅事件。
- 5构建并核对核心文件
生成 PRD.md、manifest.json 和 traceability.csv，质量不 ready 时只保留待确认草稿。
- 6生成所需 Office 文件
公开 artifacts 入口从 SQLite 核对 current（当前状态） build；只请求 DOCX 时不启动 PPTX/XLSX。
- 7来源变化后做影响
先 update-source，再 impact；自动重新绑定唯一原文，标记真正失效事实与旧 build。
- 8确认下一版与恢复点
只读 verify 当前 manifest（清单），处理新增问题后用新 build ID 生成下一版，旧目录保持不变。
正式构建的状态合同
正式入口从 SQLite 当前规范事实重建 manifest（清单）；手写 quality.status=ready，或改动 goal、fact、evidence、hash（内容指纹），均不能代替质量门。
本页用到的名词
需要核对专业含义时，可以在这里查看它在 工作支持与交付 项目中的具体用法。
- Package（交付包）
- 围绕一个持续工作事项保存来源、事实修订、决定、构建、追溯和变化影响的本地状态。
- SourceSnapshot（来源快照）
- 本人明确选入的一份资料在某个版本的不可变内容、SHA-256 和元数据；新版本不覆盖旧版本。
- EvidenceSpan（证据片段）
- 一个事实对应的原文片段与系统计算定位；文本用行列和字符范围，CSV 还记录行列。
- Fact revision（事实修订版）
- 每次事实、审阅或来源绑定变化后的统一修订号，所有正式成品都绑定一个确定修订版。
- Canonical manifest（规范清单）
- 从 SQLite 当前 build 重建的唯一正式清单；调用方手写文件不能替代。
- rebound（重新绑定）
- 原文在新来源版本中仍唯一存在时，把证据自动指向新快照而不要求再次确认。
- stale（已过期）
- 事实证据已失效或旧 build 引用发生变化，不能继续作为当前正式版本。
- baseline_required（需要基线）
- 功能可以通过，但没有同模型同质量直接处理对照，不能声称已经节省总时间。
系统里实际有什么
下面是当前产品组件，不是概念分类。每一项都对应真实文件、入口或验证链。
从自然工作请求判断是否进入持续交付包。
只做发现、边界判断和稳定入口说明；不复制 SQLite、质量门或 Office 实现。
让新包、逐步更新、影响、验证和正式成品走一个公开入口。
work-delivery.batch.v1 一次提交稳定 ID、2–5 份来源、证据事实和格式；PowerShell 入口与 Python CLI（命令行工具） 共用同一实现。
拥有 Package、SourceSnapshot、EvidenceSpan、Fact、ReviewEvent、ArtifactBuild 与 ChangeSet。
单个 SQLite 保存 current（当前状态）/history；package 默认 zh-CN、Asia/Shanghai、CNY，money/date/datetime 使用结构化值，决定事件追加写入。
从当前事实修订生成 PRD、追溯与规范清单。
质量门检查目标、必填章节、证据、关键冲突和 stale；语义 hash（内容指纹） 与事实修订绑定。
从同一规范清单生成 DOCX、PPTX 和 XLSX。
公开 artifacts 入口先核对 database + build；内部 builder 要求进程内 canonical binding，并固定正式输出目录。
证明源码、安装闭包、三类 Office、变化影响和复杂度边界。
37 项测试、Ruff 和两套合成场景在 artifacts 之后执行 Office 重新导入与公式/几何检查；这些是验收证据，不是每次 builder 自动步骤。wheel 携带 schema（数据结构）、样本和 builders。
7 层证据分别证明什么
能证明：PRIVATE（私有） main 76521682176b00333fdf579746d4fbcfea88103e 确认 0.2.0 的数据关系、统一入口、质量门、正式输出和明确不做项；行为实现闭合于 c815ea3daa04d4012200419fa989a9808ab7be36。
不能证明：源码存在不证明当前安装、Office 运行时、真实工作或 Pages 已生效。
能证明：2026-09-01 加载 Office 运行时后 37/37 测试通过，Ruff 通过，覆盖核心、质量门、CLI（命令行工具）、不可覆盖、安装闭包和构建失败语义。
不能证明：测试样本不能证明任意公司材料都能被正确分析。
能证明：安装包脱离源码目录仍携带稳定 CLI（命令行工具）、schema（数据结构）、两个样本和三个正式 builder。
不能证明：wheel 不能恢复已有真实 SQLite，也不证明自然语言一定选对入口。
能证明：两个完全合成场景都从 SQLite current（当前状态） build 生成 DOCX/PPTX/XLSX，并完成重导入、几何和公式检查。
不能证明：合成场景不证明真实工作价值、真实来源变化或真人采用。
能证明：fresh Sol Max 未获 Skill、工具或内部路线提示，自主选择 work-delivery，只读 3/3 指定来源，建立唯一 package，确认 27 条事实与 39 条追溯；5 条待确认中的 4 条阻断正式交付，quality 保持 draft，只生成三个 core files，Office builder 为 0，current（当前状态） build verify 通过且旧 build stale。
不能证明：约 12 分 12 秒可见墙钟和 0.043 秒成功 batch 核心不证明真实工作提速；本次也没有正式 DOCX/PPTX/XLSX E2E（端到端验证）。
能证明：当前 PRD、评审页和执行跟踪表的可视化形式与同一 manifest（清单） 语义一致。
不能证明：图片不是产品 UI，不证明全部页面、动态操作或真实项目。
能证明：当前只能证明尚未运行：时间状态为 baseline_required，真实工作、真实变化、导出备份和恢复均未闭合。
不能证明：Unknown（未验证） 和 not_run 不能升级为失败或通过。
维护入口
work-delivery batch --request <request.json>一次新建交付包：单进程提交稳定 package ID、2–5 份来源、候选事实和本轮所需格式。
work-delivery update-source --database <db> --package <id> --source-key <key> --file <file>来源更新：生成新 SourceSnapshot 与 ChangeSet，不覆盖旧来源；文件也可作为位置参数传入。
work-delivery impact --database <db> --package <id> --change-set <id>查看影响：返回重新绑定事实、过期事实和过期 build。
work-delivery verify --database <db> --build <id>只读核对：逐字段比较持久化 manifest（清单） 与 SQLite 当前规范事实。
work-delivery artifacts --database <db> --build <id>正式 Office 构建：只接受 verify 可通过的 current（当前状态） build，并在原目录生成请求的 Office 文件。
快照怎样更新
本页只在 work-delivery-copilot 或 work-delivery Skill 的正式发布与回读产生实质产品变化时更新。再次刷新会重新读取当前 PRIVATE（私有） main、Skill、源码合同、测试和合成验收；真实工作、时间基线和恢复能力没有新证据时继续明确保留为未完成。