Internet Exploration

Appearance

DeepSeek Harness 周复盘系统培养手册 v1.2 ​

卷首语

这一卷不是在教你“怎么点开 DeepSeek Harness”，而是在记录我们怎样把一个会聊天的模型，慢慢变成一个能在规则里做事的执行系统。

起点其实很朴素：原来的 Obsidian 工作流已经能记录 Project、Task、Daily、Try 和 Weekly，我们并不缺一个新的 ToDo 工具。真正缺的是一层“会读这些记录、会调用工具、会按流程做周复盘，但又不能擅自改正式规则”的智能执行层。于是后面的每一步——测试工作区、Test Fixture、Validator、Collector、Skill、Dry Run、Guard——都不是为了堆技术名词，而是在回答同一个问题：怎样让 AI 能做事，同时又让结果可验证、权限可控制、规则不漂移。

阅读这一卷时，不用先记住所有术语。顺着问题往下走就行：我们先让 Harness 跑起来，再证明它能安全写文件；接着用假数据逼它暴露“看起来合理但其实算错”的问题；然后把确定性的事实交给程序，把解释留给模型；最后才把它接回真实 Vault，并给自动优化加上人工授权和回归测试。每个术语都应该在它真正有用的时候出现，而不是单独背词表。

版本定位

这不是一份“最后怎么用”的说明书，而是一份按 2026-09-01 实际学习与开发顺序重建的培养记录。 v1.2 的核心修订不是增加更多结论，而是把当时最重要的教学内容补回来：术语第一次出现时就在正文解释；每一步都说明为什么发生、它解决什么、又为什么还不够；所有重要辅助资料都必须从正文进入。

正文是唯一主入口。 Prompt、Harness 返回、测试、代码快照、架构、设计决策和术语表可以继续作为独立文件保存，但不得成为“孤岛文件”；凡是对理解开发过程重要的材料，都应从对应正文位置通过 Obsidian 双链进入。

阅读方式

第一次阅读请顺序阅读正文。术语不再以“术语词典块”割裂正文，而是在问题第一次需要它时自然引入并立即解释；只有无法自然嵌入时，才允许在对应小节正文前集中解释。 需要快速查词时，可进入 DeepSeek-Harness术语表；术语表的角色是“索引与复查”，不是替代正文教学。 需要查看完整过程证据时，使用每章末尾的“本章关联资料”。

第一部分：起点——我们到底想让 Harness 做什么 ​

第 1 章：不是另建一个 ToDo，而是给现有系统增加智能层 ​

本章导语

这一章先把目标说清楚：我们不是要再造一个任务管理器，而是要给已经存在的 Obsidian 工作流加上一层智能执行能力。只有先把“谁是主系统、谁是辅助层”定下来，后面的权限、规则和数据来源才不会越做越乱。

一开始的目标并不是重新发明一个任务管理系统。已有 Obsidian 工作流已经存在：

text
Project
→ Task
→ Checkbox
→ Daily
→ Try
→ Weekly

真正缺少的是一个能够读取这些记录、按既定流程完成周复盘、又不会擅自改变正式规则的智能执行层。

因此最早的架构直觉是：

Harness 应该站在现有系统上面，而不是把现有系统吞掉。

这里首先需要把 Harness 这个词说清楚，因为后面的所有操作都建立在它之上。 Harness 在这里可以理解为“把模型、工具、文件、规则和执行过程组织在一起的执行框架”。

单独一个模型只能“回答”；Harness 让模型能够在受控环境里：

  • 读文件；
  • 调工具；
  • 运行脚本；
  • 按 Skill 执行；
  • 将多步操作串成工作流。

因此 Harness 不是“更聪明的聊天框”，而更接近一个 智能执行层。

一旦确定“不要重做 ToDo，而是在现有系统上增加智能能力”，就自然出现了 Integration Layer（集成层） 这个概念。 Integration Layer（集成层） 指位于多个已有系统之间、负责把它们连接起来的一层。

在本项目中：

text
Obsidian 真实工作流
        ↓
     Harness
        ↓
模型 / Validator / Collector / Skill

Harness 不取代 Obsidian，而负责组织读取、验证、分析和受控写回。

完整索引：Integration Layer

但“只做集成层”还不够，我们还必须回答：真实记录到底以谁为准？这就引出了 Single Source of Truth（单一真相源，SSOT）。 Single Source of Truth（单一真相源，SSOT） 指：同一类正式事实只能有一个最终权威来源。

在这里，真实业务记录的正式来源仍然是 Obsidian Vault。Harness 可以读取它、转换它、验证它，但不应该创建一套和 Vault 并行的“第二正式版本”。

完整索引：Single Source of Truth

这一原则后来直接决定了真实数据阶段为什么需要 Collector / Adapter，而不是每周手工复制数据。

本章关联资料 ​

第 2 章：先让工具链跑起来 ​

本章导语

目标确定以后，下一件事不是谈架构，而是先让工具链真的跑起来。本章记录我们怎样从卡住的启动路径切换到可工作的 pnpm 路线，并借此建立一个很重要的工程习惯：先判断问题出在目标，还是出在实现路径。

Windows 环境首先需要能够运行 DeepSeek Harness。

当时安装并确认：

  • Node.js v24.20.0；
  • npm 11.19.0。

最先尝试：

powershell
npx @deepseek-ai/dsh web

但安装/依赖解析长时间没有有效进展。

这里的重要判断并不是：

“npx 一定有问题。”

而是：

当前目标没有错，但当前实现路径可能卡住了。

于是改用 pnpm：

powershell
pnpm dlx @deepseek-ai/dsh@latest web

并成功继续安装。

安装 Node 时，版本选择本身也带出了第一个环境术语：LTS。 LTS（Long-Term Support，长期支持版） 是软件项目会长期维护、通常更适合作为稳定工作环境的版本线。

这里要学到的不是“永远装最新版本”，而是：生产或长期学习环境要关注版本稳定性和维护周期。

接着，判断一个命令为什么能或不能运行，就必须理解 PATH。 PATH 是操作系统用于寻找可执行程序的一组目录。

当你在 PowerShell 输入：

powershell
node
pnpm
git

Windows 会沿 PATH 查找对应程序。

因此“软件已经安装但命令找不到”，经常不是软件不存在，而是 PATH 没有正确配置。

当 npx 卡住而我们改用 pnpm dlx 时，这几个名字不能只当作命令背下来，需要顺手理解 npm / npx / pnpm / dlx 各自扮演什么角色。

  • npm：Node.js 生态中的包管理器。
  • npx：临时获取并执行 npm 包中的命令。
  • pnpm：另一种 Node.js 包管理器，强调更高效的依赖存储与解析。
  • pnpm dlx：类似 npx，用于临时下载并直接执行一个包。

这里的真正方法论是：

不要把“某条命令失败”直接升级成“整个方案失败”。

先判断失败层级。

把 npm 与 pnpm 放在一起看，会发现它们都属于更一般的概念：Package Manager（包管理器）。 Package Manager（包管理器） 是负责下载、安装、更新和解析软件依赖的工具。

本项目中 npm / pnpm 都属于包管理器。

而“为什么换一个包管理器可能解决问题”，要继续往下一层看 Dependency、Dependency Tree 与 Resolver。

  • Dependency（依赖）：一个程序运行所需要的其他软件包。
  • Dependency Tree（依赖树）：依赖还会继续依赖其他包，因此形成树状关系。
  • Resolver（依赖解析器）：负责判断“到底安装哪个版本组合”的机制。

当 npx 卡住时，我们首先把它视为依赖安装/解析路径的问题，而不是 Harness 架构问题。

包管理器实际下载的软件包通常以归档形式传输，这里会遇到 Tarball。 Tarball 是常见的软件包归档文件。包管理器从 registry 下载包时，经常下载压缩归档，再解开安装。

安装继续推进后，Harness 弹出授权请求。此时第一次需要理解 Build Script（构建脚本），因为这已经不是单纯的“下载文件”，而是在安装阶段执行代码。 安装过程中 Harness 要求允许若干 Build Script（构建脚本）。

当时只批准：

  • @deepseek-ai/dsh-subprocess-local
  • koffi
  • node-pty

Build Script 是软件包安装期间运行的脚本。它可能编译原生组件、准备二进制文件或完成环境配置。

因此“允许 Build Script”是一个权限决定，不应该习惯性全部允许。

当我们判断安装到底是“慢”还是“卡死”时，观察对象其实是正在运行的 Process（进程）。 Process（进程） 是操作系统中正在运行的程序实例。

当一个安装命令长时间没有有效进展时，我们实际观察的是一个 Process 是否仍在正常工作，而不是仅看窗口“有没有关闭”。

最终 Harness Web UI 成功运行于：

text
http://127.0.0.1:3080

这一步最重要的工程思维是：

text
失败
↓
先定位失败属于哪个层
↓
目标错误？
还是实现路径错误？
↓
只替换出问题的层

本章关联资料 ​

第二部分：先证明 Harness 能安全地动文件 ​

第 3 章：Workspace Write，而不是一开始就给真实 Vault 写权限 ​

本章导语

Harness 能启动，只能说明“程序活着”；还不能说明它适合碰真实资料。本章把风险压到最低，只让它在测试工作区里写一个小文件，用最小权限证明 Model → Harness tools → 文件系统这条链确实成立。

我们没有直接把真实 Obsidian Vault 当试验场。

先建立测试 Workspace：

text
<Local Path>

然后让模型通过 Harness：

text
写 harness-test.md
→ 再读取
→ 验证内容

成功后说明：

text
Model
→ Harness tools
→ Windows file system

这条链路成立。

开始做文件写入测试后，首先要理解 Workspace（工作区）：我们究竟允许 Harness 在哪里工作。 Workspace（工作区） 是当前 Harness 被允许围绕其执行任务的一块项目空间。

它不仅是“一个文件夹”，还意味着：

  • 当前上下文；
  • 允许操作的文件范围；
  • Skill 所在位置；
  • 相对路径的解析基础。

Workspace 解决“在哪里工作”，而一次具体的连续执行过程则对应 Session（会话）。 Session（会话） 是一段连续的 Harness 交互与执行上下文。

Workspace 更像“在哪工作”，Session 更像“这一次工作过程”。

我们通过浏览器操作 Harness，因此这里的界面属于 Web UI（Web User Interface）。 Web UI（Web User Interface） 是通过浏览器访问的用户界面。Harness 的 127.0.0.1:3080 就是本地 Web UI。

模型能够被 Harness 调用，还依赖 Provider 与 API Key，但它们和文件权限是两回事。

  • Provider：模型服务提供方。
  • API Key：用于证明调用权限的凭证。

二者决定 Harness 能调用哪个模型服务，但它们不决定文件系统安全边界。

真正决定文件和命令能做到什么程度的，是 Sandbox（沙箱）。 Sandbox（沙箱） 是对程序权限进行隔离和限制的执行环境。

核心思想：

即使程序有能力执行命令，也不代表它应该拥有整台电脑的无限权限。

在这个沙箱里，我们选择的是 Workspace Write，而不是直接给整个系统无限权限。 Workspace Write 表示允许 Harness 在工作区范围内进行写入。

这和 danger-full-access 不同。后者意味着更宽的系统访问能力。

因此我们形成第一条安全原则：

能做，不等于应该一次性把所有权限都给出去。

真实 Vault 在开发阶段继续只读。

本章关联资料 ​

第三部分：Test Fixture——让“对不对”变成可以客观判断 ​

第 4 章：为什么要自己造一周假数据 ​

本章导语

既然 Harness 已经能动文件，下一步就要问：它做出来的分析到底对不对？真实生活数据没有标准答案，所以我们先自己造一周“答案已知”的假数据，把模糊的感觉变成可以核对的测试。

如果一开始直接拿真实生活数据做测试，模型即使分析错了，也可能因为语言流畅而显得“很像那么回事”。

所以建立：

text
WeeklyReview/Input/2026-W36-test.md

作为 synthetic Test Fixture。

其中故意预设已知答案：

  • task count = 15；
  • planned = 1380 min；
  • actual = 1410 min；
  • workflow web optimization occurrences = 4；
  • 高等代数 occurrences = 3；
  • 11 个任务缺 Time；
  • Thursday 的 Unexpected Event 180 min 与 project 240 min 可能重叠，不能直接相加。

开始造测试周以后，首先要区分模型看到的解释和未经解释的 Raw Data（原始数据）。 Raw Data（原始数据） 是尚未被模型解释、总结或推断过的输入事实。

在 Grounding 体系中，Raw Data 是证据链的起点。

之所以故意造一周“答案已知”的数据，是因为我们需要一个 Test Fixture（测试夹具）。 Test Fixture（测试夹具） 是为了测试而准备的一组固定输入与已知预期结果。

它最关键的价值不是“假数据”，而是：

我们提前知道正确答案，因此可以客观判断系统是否出错。

如果没有 Test Fixture，模型说“这周你大约做了 14 个任务”，我们很容易把“像答案”误认为“正确答案”。

本章关联资料 ​

第 5 章：第一次模型分析——“看起来合理”还不够 ​

本章导语

有了答案已知的 Test Fixture，模型第一次分析时的问题就暴露出来了：它不是完全胡说，而是会把合理推断悄悄写成事实。本章因此把 Grounding、Fact、Inference、Hypothesis 和 Unknown 引入到真正的问题里。

第一次模型分析确实捕捉到了一些我们故意设计进去的模式：

  • 项目时间超支；
  • 上午比下午表现更好；
  • 数学复习反复延后；
  • 技术问题干扰计划。

这说明模型的解释能力是有价值的。

但它同时产生了输入中不存在的内容：

  • Thursday 数学被补成 14:00–16:00；
  • “每天 4~5 项任务”与原数据不一致；
  • 工作流项目被说成“连续 4 天”；
  • 仅 n=2 的技术问题被概括成稳定重复模式。

这里出现了整个项目第一组真正重要的 AI 工程术语。

第一次模型分析出现了原文里不存在的时间。这里不能只说“模型算错了”，更准确的名字是 Hallucination（幻觉）。 Hallucination（幻觉） 指模型生成了输入证据不支持的事实性内容。

这里最直观的例子就是：

text
原数据没有 Thursday 14:00–16:00
↓
模型自己补出来

幻觉不一定荒谬。最危险的幻觉恰恰往往“非常合理”。

但随后发现还有另一种更隐蔽的问题：模型没有完全凭空捏造，而是在概括时把证据强度越说越强。这个现象叫 Evidence Drift（证据漂移）。 Evidence Drift（证据漂移） 指结论逐渐偏离原始证据，即使每一步看起来都像合理概括。

例如：

text
出现过两次技术问题
↓
模型概括为“经常”
↓
进一步写成“稳定模式”

这不是单纯的数字错误，而是证据强度在语言压缩过程中变强。

要同时约束“凭空补事实”和“把弱证据说成强结论”，我们才正式引入 Grounding（证据落地）。 Grounding（证据落地） 指关键判断必须能沿证据链回到真实输入。

它回答的是：

“这句话有什么依据？”

而不是：

“这句话听起来是否合理？”

完整索引：Grounding

仅有 Grounding 仍然不够，因为“有依据”也分不同强度。于是正文进一步区分 Fact / Inference / Hypothesis / Unknown。 为了让模型不能把不同证据强度混在一起，我们开始区分四类判断：

其中，Fact 的含义是：

Fact（事实）：可以直接从数据中读取或确定性计算得到。

例如：

text
task count = 15

其中，Inference 的含义是：

Inference（推断）：由一个或多个事实支持，但不是源数据直接写出的判断。

例如：

text
多个复盘字段为空
+ Try 很少
↓
记录闭环可能不足

“记录字段为空”是 Fact；“闭环不足”是 Inference。

其中，Hypothesis 的含义是：

Hypothesis（假设）：对原因或未来改进的可检验猜想。

例如：

text
把项目限制为 90 分钟
可能减少时间超支

这不是事实，而是等待实验的假设。

其中，Unknown 的含义是：

Unknown（未知）：现有证据不足，不能可靠判断。

这个标签非常重要，因为成熟系统必须允许说：

“我不知道。”

而不是强迫模型给出完整故事。

为了让模型在输出前主动检查这些标签，我们又加入 Self-Audit（自我审计）。 Self-Audit（自我审计） 指让模型在提交最终结论前，主动检查自己的结论是否违反证据纪律。

第一次 Self-Audit 成功纠正了多项错误，说明 Grounding 规则是有效的。

但是这一步也留下一个尚未解决的问题：

即使模型知道 Grounding，它是否能稳定地完成精确计数？

答案很快证明：不能。

本章关联资料 ​

第四部分：Skill 不是万能药 ​

第 6 章：review-spec 与 weekly-review Skill ​

本章导语

上一章证明“靠提醒模型小心一点”还不够，证据纪律必须固化。本章开始把规则写进 review-spec 和 Skill，让正确做法从一次性的提示，变成可重复执行的工作方式。

为了把刚刚形成的证据纪律从“聊天里的提醒”变成可重复规则，我们创建：

text
WeeklyReview/Rules/review-spec-v0.1.md

随后建立 workspace-local Skill：

text
.dsh/skills/weekly-review/SKILL.md

这些规则如果只留在一次对话里，下次仍可能丢失，因此才需要把它们固化成 Skill。 Skill 是 Harness 可以发现并按规定方式调用的一套任务能力说明。

它的价值在于：

text
一次聊天里的要求
↓
变成
↓
可重复调用的工作规则

Skill 要先被 Harness 找到，因此会涉及 Skill Catalog（技能目录）。 Skill Catalog（技能目录） 是 Harness 用于发现有哪些 Skill 可用的机制或集合。

“文件放进目录”并不自动等于“系统已经认识它”，所以要单独验证 Skill Discovery（技能发现）。 Skill Discovery（技能发现） 指 Harness 能扫描并识别某个 Skill。

只有 Discovery 成功，并不代表 Skill 已真正执行。

发现之后还要真正执行，这一步叫 Skill Invocation（技能调用）。 Skill Invocation（技能调用） 指真正触发并按 Skill 内容执行任务。

所以测试要区分：

text
Skill 被发现
≠
Skill 被调用
≠
Skill 输出正确

而 Skill 能否被正确发现、相对路径如何解析，又与进程的 cwd（current working directory，当前工作目录） 有关。 cwd（current working directory，当前工作目录） 是一个进程当前所在的目录。

很多相对路径、Skill 搜索路径和脚本行为都依赖 cwd，因此“我在哪个目录启动 Harness”在工程上非常重要。

Skill Discovery 与 Invocation 测试通过。

到这里，模型已经：

  • 读到规则；
  • 有 Grounding；
  • 有 Self-Audit；
  • Skill 也成功加载。

按直觉似乎应该稳定了。

但下一次测试证明仍然不够。

本章关联资料 ​

第 7 章：为什么 15 还能被数成 14 ​

本章导语

规则写进 Skill 后，我们遇到了一个更尴尬的问题：明明输入里有 15 个任务，模型还是能数成 14 个。这一章借这个小错误说明，语言模型并不适合承担所有确定性计数。

Skill-only 分析仍然出现：

text
15 个任务 → 14
高等代数 3 次 → 2

这是整个项目最重要的架构转折之一。

我们按排除法分析：

text
Skill 没加载？
→ 不是

源文件没读到？
→ 不是

没有 Grounding？
→ 不是

那剩下的问题是：

我们仍然在让语言模型承担确定性计算。

Skill 已经加载、Grounding 也存在，却仍把 15 数成 14。这个失败把问题逼到了一个更基础的概念：Deterministic（确定性）。 Deterministic（确定性的） 指在相同输入和规则下，系统应该稳定得到相同结果。

例如：

text
一个文件中有 15 个符合条件的任务

计数器应该每次都返回：

text
15

而不是有时 14、有时 15。

语言模型擅长解释和生成，但并不天然适合承担所有精确统计。

于是形成整个项目最重要的方法论之一：

程序负责算准，模型负责想明白。

这不是先验口号，而是从失败中推导出来的设计。

本章关联资料 ​

第 8 章：weekly_validator.py——把确定性事实交给程序 ​

本章导语

既然模型连任务数量都可能算错，就不该再让它独自负责“确定性的事实”。本章把计数、缺失项、时间总和等可计算内容交给 Validator，形成“程序算事实，模型做解释”的分工。

创建：

text
WeeklyReview/tools/weekly_validator.py

它不负责回答：

“这一周为什么失败？”

只负责计算：

  • task_count
  • planned_minutes
  • actual_minutes
  • occurrences
  • status counts
  • missing fields
  • Unexpected Event

既然精确计数必须稳定，我们就把这部分职责从模型手里拿出来，交给 Validator（校验器）。 Validator（校验器） 是负责检查输入是否符合规则、并输出确定性结果的程序。

在这个项目里，Validator 的角色可以概括为：

text
不解释人生
只负责算准

Validator 的结果还需要稳定地交给下一步使用，因此不能只写一段自然语言，而要形成 Structured Output（结构化输出）。 Structured Output（结构化输出） 指结果按照机器可以稳定读取的结构输出，而不是只写自然语言段落。

这里选择 JSON。

这里选择的结构化载体是 JSON。 JSON（JavaScript Object Notation） 是一种常见的结构化数据格式。

例如：

json
{
  "task_count": 15,
  "planned_minutes": 1380,
  "actual_minutes": 1410
}

它比“这周大约有十五项任务”更适合作为程序与模型之间的事实接口。

除了输出数据，脚本还要告诉上层“成功还是失败”，这就用到 Exit Code（退出码）。 Exit Code（退出码） 是程序结束时返回给操作系统的状态数字。

典型约定：

text
0     = 成功
非 0  = 出错

因此 Validator 不仅输出数字，还能告诉上层 Pipeline：

“这一步到底成功还是失败。”

Windows 上实际执行 Validator 时使用 py，这里的 Python Launcher 也值得顺手理解。 Windows 上使用：

powershell
py

调用 Python 时，py 属于 Python Launcher。

本机当时可以使用 py，而 python 命令并不可用。这提醒我们：

文档应记录实际可用命令，而不是想当然地假定所有机器都一样。

当 Validator、原始 Markdown 与模型解释按顺序串起来后，这条固定链就形成了 Pipeline（流水线）。 Pipeline（流水线） 是把多个处理步骤按固定顺序连接起来。

Skill v0.2 后形成：

text
Validator
↓
Structured JSON
↓
Raw Markdown
↓
模型解释

为了让 Pipeline 不依赖模型去猜状态，关键事实应尽量采用 Machine-readable Metadata（机器可读元数据）。 Machine-readable Metadata（机器可读元数据） 指用程序可以稳定解析的字段表达状态或事实，而不是只依赖自然语言。

End-to-End 测试通过后，系统正式拆成：

text
Deterministic Facts → 程序
Interpretation      → 模型

本章关联资料 ​

第五部分：从“会分析”到“能安全地优化自己” ​

第 9 章：为什么不能一发现问题就直接改 Rule ​

本章导语

事实层稳定以后，问题从“算得准不准”进入“能不能自己改规则”。本章先踩住刹车：一次观察只能提出假设，不能直接改长期规则，自动优化必须经过实验和授权。

假设一周数据显示：

text
项目时间明显超支

模型可能立刻建议：

text
以后所有项目最多 90 分钟

问题是：

一次观察不足以成为长期规则。

因此设计出：

text
Observation
→ Hypothesis
→ Experiment
→ Result
→ Rule

进入优化阶段后，首先要把“看到一个现象”明确叫作 Observation（观察）。 Observation（观察） 是从真实数据中发现的现象。

例如：

text
本次网页优化 planned 330
actual 690

Observation 本身不能直接变规则；下一步只是形成一个可验证的 Hypothesis（假设）。 Hypothesis（假设） 是对“什么改变可能有效”的可测试猜想。

要验证 Hypothesis，就需要一个受限范围内的 Experiment（实验）。 Experiment（实验） 是在有限范围内尝试一个假设，而不是直接修改长期规则。

Experiment 不是一段随手笔记，因为它会经历明确状态变化，所以我们把它设计成 State Machine（状态机）。 Experiment 不只是一个 Markdown 文件，而具有状态：

text
proposed
→ approved
→ running
→ completed
→ kept / rolled_back

这种对象叫 State Machine（状态机）：

一个对象只能处于规定状态之一，并按照允许的路径发生状态转换。

从 proposed 到 kept / rolled_back 的完整过程，就是这个 Experiment 的 Lifecycle（生命周期）。 Lifecycle（生命周期） 是一个对象从创建到结束所经历的完整状态过程。

状态能自动推进到什么程度必须有边界，于是引入 Human-in-the-loop（人在回路中）。 Human-in-the-loop（人在回路中） 表示关键决定仍然必须由人确认。

这里设置三道 Gate：

  1. Experiment Approval Gate
  2. Final Decision Gate
  3. Rule Promotion Gate

用户确认所在的关键卡口，就是一个个 Gate（门控）。 Gate（门控） 是一个必须满足条件或取得授权才能继续进入下一阶段的控制点。

因此 AI 可以给 Recommended Decision，但 Final Decision 仍由用户确认。 AI 可以给：

yaml
recommended_decision: keep

但真正正式的：

yaml
decision: kept

必须经过用户确认。

把“谁能决定什么、什么时候必须停下来等人确认”系统化后，这一层就是 Governance（治理）。 Governance（治理） 指“谁可以决定什么、在什么条件下决定、决定后如何追踪”的制度设计。

它解决的问题不是模型聪不聪明，而是：

系统有没有权力边界。

治理如果无法回看就没有意义，所以每一次状态变化还需要留下 Audit Trail（审计轨迹）。 Audit Trail（审计轨迹） 指重要操作和决策留下可追踪记录，使以后能够回答：

text
谁决定的？
依据是什么？
什么时候发生？
从哪个状态变到哪个状态？

为了让审计轨迹可信，历史记录不应被无痕改写，这里就涉及 Immutable（不可变） 的思想。 Immutable（不可变） 在治理语境中通常指某些历史记录一旦形成，不应该被无痕覆盖，而应保留历史。

本章关联资料 ​

第 10 章：从 Experiment 到 Rule Promotion ​

本章导语

上一章建立了实验治理，这一章继续回答“实验成功以后怎么办”。我们把 Experiment kept 和 Rule changed 分开，让规则晋升成为一个明确、可审计、需要人工确认的动作。

测试 Experiment 的 Baseline：

text
ratio = 2.09

模拟实验结果：

text
ratio = 1.20

经过用户逐步授权后，实验最终变为：

text
kept

但这里特意没有自动修改正式长期规则。

实验完成后不能只凭感觉判断效果，需要事先或同时明确 Outcome Metric（结果指标）。 Outcome Metric（结果指标） 是用于判断实验效果的量化指标。

这里使用时间比率作为实验结果之一。

即使实验结果看起来很好，也还差最后一步：把实验结论提升为长期规则，这一步叫 Rule Promotion（规则晋升）。 Rule Promotion（规则晋升） 指将一个经过验证的实验结论提升为更长期、正式的规则。

关键原则：

Experiment kept ≠ Rule automatically changed。

测试规则最终只晋升到：

text
rule_type: test
scope: test_project_timebox_only

规则晋升时首先要问“它到底适用于多大范围”，这就是 Scope（作用域）。 Scope（作用域） 指一条规则适用于多大的范围。

如果一个只在测试项目中验证的结论被直接推广到所有项目，就发生了 Overgeneralization（过度泛化）。

一条规则还应该能追溯到它从哪次观察、哪次实验而来，这种来源链叫 Provenance（来源追踪）。 Provenance（来源追踪） 指一个规则能够追溯到：

text
Observation
→ Hypothesis
→ Experiment
→ Result
→ Promotion

当整个系统都能沿链接和记录回查这条来源链时，就具备了 Traceability（可追踪性）。 Traceability（可追踪性） 是整个系统能够沿链路找到“这个结果从哪里来的”。

Provenance 更强调来源；Traceability 更强调可追踪能力。

本章关联资料 ​

第六部分：从 synthetic data 走向真实 Vault ​

第 11 章：不再手工复制一个“第二真相源” ​

本章导语

在测试数据上跑通以后，真正的难点来了：不能要求用户每周再把 Obsidian 数据复制一份给 Harness。本章开始把真实 Vault 接回来，同时坚持只有一个事实来源。

测试数据成功以后，下一个问题是：

真实周复盘的数据从哪里来？

最差方案之一是：

text
每周从 Obsidian 复制一次
→ 粘到 Harness Input
→ 再分析

因为这样会产生两个版本：

text
Obsidian 真数据
Harness 复制数据

只要复制漏了一次，两边就可能分叉。

因此设计：

text
真实 Project / Task / Daily / Try
→ Collector / Adapter
→ Normalized JSON
→ Validator
→ Skill

从测试数据走向真实 Vault 时，第一件事不是让模型直接吃所有原文件，而是先建立 Adapter（适配器）。 Adapter（适配器） 用来把一种已有格式转换成另一种系统能理解的接口格式。

重点是：

Adapter 改变“表示方式”，不改变“正式事实来源”。

由于真实证据分散在 Project、Task、Daily、Try 等多个位置，还需要一个 Collector（收集器） 把它们汇集起来。 Collector（收集器） 负责从多个真实来源中读取数据并汇集起来。

这些来源的字段并不完全一致，因此 Collector 之后还必须做 Normalization（规范化）。 Normalization（规范化） 指把不同文件、不同字段形式的数据统一成内部稳定格式。

例如：

text
check
check-date
不同 Try 结构
不同 Daily frontmatter

都可以经过 Normalization 后变成统一 JSON。

本章关联资料 ​

第 12 章：真实 Schema 不会像 Test Fixture 那么整齐 ​

本章导语

一接触真实 Vault，就会发现真实数据远没有 Test Fixture 整齐。本章通过字段缺失和命名差异说明为什么 Collector 必须容忍 Schema 变化，而不能把“字段没写”武断解释成“事情没发生”。

真实 Vault 抽样发现：

  • Project files：3；
  • Task files：8；
  • 7/8 Task 使用 check；
  • 1/8 使用 check-date；
  • 7 个 Task 有 try；
  • 1 个没有；
  • Daily frontmatter 也并不完全一致。

真实文件为什么会出现 check、check-date 等差异？因为每类数据背后都有自己的 Schema（数据结构规范）。 Schema（模式 / 数据结构规范） 描述一类数据通常有哪些字段、字段类型是什么、彼此关系如何。

现实中的 Schema 不会永远整齐，因此程序必须具备适度的 Schema Tolerance（模式容忍）。 Schema Tolerance（模式容忍） 指程序能够在输入格式存在合理差异时继续工作，而不是因为一个字段名不同就崩溃。

但 Schema Tolerance 不能等于“随便猜”。

例如：

text
没有 try 字段

只能得到：

text
try 字段缺失

不能得到：

text
这个任务从未执行

这再次回到 Grounding：

缺数据是 Data Quality 问题，不是行为结论。

本章关联资料 ​

第 13 章：Real Collector 与 PyYAML 日期问题 ​

本章导语

Schema 能容忍以后，还会碰到更具体的工程问题。本章记录 Real Collector 在 PyYAML 日期对象和 JSON 序列化上的坑，让“真实数据接入”从概念落到代码细节。

创建：

text
WeeklyReview/tools/weekly_source_collector.py

初版运行出现两个真实工程问题：

  1. PyYAML 把 YAML 裸日期解析成 Python date 对象，JSON 不能直接序列化；
  2. Try 日期也被解析成 date 对象，过滤逻辑把它误判为无效。

这个问题很重要，因为它说明真实工程经常不是被“大架构理论”卡住，而是被一个具体的数据类型边界卡住。

Collector 初版碰到 Python date 无法直接写入 JSON，本质上是 Serialization（序列化） 问题。 Serialization（序列化） 指把程序内部对象转换成可以存储或传输的格式。

这里：

text
Python date object
↓
JSON

初版不能直接完成，因此需要明确转换。

而这个序列化问题之所以出现，是因为字符串日期与 Python date 属于不同 Data Type（数据类型）。 Data Type（数据类型） 指程序如何理解一个值。

字符串 "2026-08-27" 和 Python date(2026, 8, 27) 看起来表达同一天，但在程序里属于不同类型。

修复后小范围真实测试：

  • project_files = 3；
  • task_files = 8；
  • daily_files = 12；
  • period Daily = 2；
  • Try = 1；
  • missing Daily = 08-27、08-29。

本章关联资料 ​

第 14 章：Real Validator 与 Data Quality Warning ​

本章导语

Collector 把真实数据整理出来后，Validator 才能在统一输入上做确定性检查。本章把 Warning 和 Error 分开：数据不完整不等于系统必须停，也不等于可以把缺失信息脑补成事实。

随后创建：

text
WeeklyReview/tools/real_weekly_validator.py

它只读取 Collector JSON，不直接扫描真实 Vault。

这是一项重要的职责分离：

text
Vault parsing
→ Collector

deterministic validation
→ Validator

测试结果：

  • expected_days = 4；
  • present_days = 2；
  • missing_days = 2；
  • try_event_count = 1；
  • task_count = 8；
  • source consistency = 4/4；
  • warnings = 5；
  • errors = 0。

当真实数据缺了一天 Daily 或某个字段时，系统需要记录风险但又不能乱下行为结论，因此引入 Data Quality Warning（数据质量警告）。 Data Quality Warning（数据质量警告） 表示输入证据存在缺口、格式差异或完整性问题，但程序仍可继续。

例如：

text
某日 Daily 缺失

这是 warning。

它不能自动被解释为：

text
那天什么都没做

这里必须同时区分 Error 与 Warning：前者通常阻止可靠继续，后者提醒我们降低结论强度。

  • Error：当前过程无法安全继续或结果不可信；
  • Warning：存在风险/缺口，但仍可以继续，只是结论必须保持谨慎。

本章关联资料 ​

第七部分：AGENTS.md 改变了 Skill 的定位 ​

第 15 章：原系统其实已经有自己的业务权威 ​

本章导语

真实数据链打通以后，我们又发现一个更重要的事实：原来的周复盘系统早就有自己的权威文件。本章因此重新定位 Skill——它应该指向正式规则，而不是复制出第二套业务规则。

真实只读映射后确认：

text
AGENTS.md
→ Thin Pointer / 入口

周复盘流程.md
→ 唯一权威流程

周复盘prompt-稳定.md
→ 正式业务分析框架 + 输出结构

周复盘prompt-成长.md
→ 纵向背景

update-growth.py
→ 正式 Weekly 成功保存后才更新 Growth

这意味着一个很重要的问题：

如果继续把业务规则复制进 Skill，反而会制造第二套规则。

读取真实 Vault 后发现 AGENTS.md 本身并不保存整套业务规则，而更像一个 Thin Pointer（薄指针）。 Thin Pointer（薄指针） 指一个文件主要负责告诉系统“真正的规则在哪里”，而不是自己重复保存整套规则。

优点是减少重复和规则漂移。

既然规则分布在多个文件里，就必须明确冲突时谁说了算，这个问题就是 Authority（权威来源）。 Authority（权威来源） 指出现冲突时，哪个来源拥有最终解释权。

这一步让 Skill v0.3.1 发生 Authority Alignment（权威对齐）：

Vault 决定周复盘“是什么”；Harness Skill 只增强“如何更可靠地完成它”。

这也让我们重新区分 Source of Truth 与 Authority：前者强调正式事实从哪里来，后者强调冲突时听谁的。 SSOT 强调“正式事实只有一个来源”；Authority 更强调“冲突时听谁的”。

两个概念相关但不完全相同。

本章关联资料 ​

第 16 章：Real Weekly Authority Priority ​

本章导语

既然已经找到业务权威，下一步就要把“谁优先听谁的”写清楚。本章整理 Real Weekly Authority Priority，避免 Prompt、Skill、AGENTS.md 和真实流程文件互相抢解释权。

正式优先级被明确为：

  1. Raw current Vault evidence；
  2. 当前 周复盘流程.md；
  3. 当前 Stable Prompt；
  4. 当前正式脚本行为；
  5. Growth Archive；
  6. Harness Validator / Grounding enhancement；
  7. Model interpretation。

这里必须特别理解：

Validator 对确定性数字有权威，但不能覆盖业务规则。

例如：

text
Validator 能准确告诉你 task_count = 8

但它不能决定：

text
正式 Weekly 应该有哪些章节

后者仍由官方 Flow / Stable Prompt 决定。

把多个 Authority 排成明确顺序后，就形成 Precedence（优先级规则）。 Precedence（优先级规则） 解决多个来源发生冲突时应该采用哪一个。

如果没有明确 Precedence，系统越复杂，越容易产生“每个文件都对，但彼此不一致”。

本章关联资料 ​

第八部分：第一次 Real Dry Run ​

第 17 章：为什么正式写 Weekly 前先 Dry Run ​

本章导语

数据、规则和权限都对齐之后，仍然不能直接让系统写正式 Weekly。本章先引入 Dry Run：先完整执行一遍，但把“正式写入”这最后一步拿掉，用低风险方式验证整条链。

到了真实模式，我们没有直接写入正式 Weekly。

先运行一个完整但不落地业务结果的流程。

进入真实周复盘前，我们不希望测试逻辑与真实写入混在一起，因此 Skill 明确区分 Execution Mode（执行模式）。 Execution Mode（执行模式） 表示同一个系统在不同安全级别/目的下如何运行。

当前 Skill 区分：

text
Test Mode
Real Mode

Real Mode 也不能第一次就写正式 Weekly，所以先运行 Dry Run（试运行）。 Dry Run（试运行） 指按真实逻辑执行，但禁止产生正式副作用。

允许：

  • 读取真实 Vault；
  • Collector；
  • Validator；
  • Git（若可用）；
  • 分析。

禁止：

  • 写正式 Weekly；
  • 运行 update-growth.py；
  • 修改 Growth；
  • 创建正式 Experiment / Rule。

Dry Run 的意义是：

在“真正写回”之前，用真实输入验证整条 Pipeline。

Dry Run 真正限制的不是“分析能力”，而是各种 Side Effect（副作用）。 Side Effect（副作用） 指程序除了“计算返回值”以外，对外部世界造成的改变。

例如写文件、删文件、修改数据库、发送消息，都属于 Side Effect。

Dry Run 的核心就是：

text
尽可能执行真实逻辑
+
避免不可逆 Side Effect

本章关联资料 ​

第 18 章：Dry Run 做对了什么 ​

本章导语

上一章只是定义 Dry Run，这一章看它实际做对了什么。重点不是“跑通”两个字，而是确认它有没有正确读取证据、遵守权威、保留不确定性，并在该停的地方停下来。

测试周期：

text
2026-08-27 ~ 2026-08-30

得到：

  • 08-27：没有 Daily，但存在 Try evidence；
  • 08-28：存在空 Daily 模板；
  • 08-29：没有 Daily、没有其他证据；
  • 08-30：7/7 checked completed，review fields 空；
  • Git 不可用，按规则跳过；
  • 没有正式写入。

最重要的 Grounding 表现是：

text
08-27 Daily missing
+
Try exists
→ 不能写“没执行”

而：

text
08-29 Daily missing
+
没有其他证据
→ Unknown

08-27 没有 Daily 却有 Try，说明不同来源不能被单一缺失信号覆盖，这里形成了 Evidence Hierarchy（证据层级） 的意识。 Evidence Hierarchy（证据层级） 指不同来源的证据不能简单互相覆盖。

“Daily 缺失”只是一个来源缺失；只要其他来源存在 Try，就必须保留那份证据。

而真正要判断未来系统是否变好，还需要一个可比较的 Baseline（基线）。 Baseline（基线） 是未来比较变化时的参考状态。

这次 08-27~08-30 不是正式完整 Baseline，而是 Real Dry Run regression dataset。真正的 First Real Baseline Weekly 要等一个自然完整周期。

本章关联资料 ​

第 19 章：正文正确，不代表摘要也正确 ​

本章导语

Dry Run 的正文看起来正确，却不代表所有输出都正确。本章专门追踪摘要层的偏差，说明任何自动生成的短摘要都可能重新引入信息损失和语义漂移。

Dry Run 暴露三个更隐蔽的问题。

19.1 UPDATE 压缩漏掉 08-27 Try ​

正文知道：

text
Daily missing + Try exists

但 UPDATE 在压缩时把它弱化成单纯“数据缺口”。

Dry Run 中正文是对的，UPDATE 却把证据压坏了。这个新缺陷被命名为 Evidence Compression Drift（证据压缩漂移）。 Evidence Compression Drift（证据压缩漂移） 指正文在被压缩成 Summary / Pattern / UPDATE 时，证据关系发生失真。

它特别危险，因为摘要往往会被：

  • 长期保存；
  • 进入 Growth Archive；
  • 作为下次分析背景。

所以：

UPDATE 的 Grounding 标准至少必须和正文一样严格。

完整索引：Evidence Compression Drift

19.2 date 字段被猜语义 ​

Task 中存在：

yaml
date: 2026-08-30

模型却把它解释成：

“已经可以开始”。

但是官方规则没有定义这个字段一定等于：

text
start
scheduled
deadline

随后 date 字段又被模型擅自解释成“可开始时间”，这暴露的是 Unknown Field Semantics（未知字段语义）。 Unknown Field Semantics（未知字段语义） 指我们知道一个字段存在，却不知道它在正式系统里的业务含义。

关键纪律：

不要因为字段名看起来熟悉，就自动替它补业务语义。

19.3 综合判断被错标成 Fact ​

事实：

text
review fields 为空
Try 数量少

推断：

text
系统记录未闭环

第三个问题是把综合判断标成 Fact，因此需要强化 Evidence Label Discipline（证据标签纪律）。 Evidence Label Discipline（证据标签纪律） 指必须保持 Fact / Inference / Hypothesis / Unknown 标签与实际证据强度一致。

多个 Fact 支持一个判断：

text
不等于

这个判断自动升级为 Fact。

本章关联资料 ​

第九部分：v0.3.2 Grounding Patch 与 Regression ​

第 20 章：三个 Guard ​

本章导语

发现摘要也会出错以后，我们不再靠“记得检查”，而是把风险点变成三个 Guard。Guard 的意义就是把重要约束放到系统里，让错误更难悄悄穿过去。

针对 Dry Run 的三个问题，Skill v0.3.2 增加：

  1. Unknown Field Semantics Guard；
  2. Summary and UPDATE Grounding Guard；
  3. Evidence Label Discipline。

这三个缺陷都已经可复现，所以 v0.3.2 不是泛泛加规则，而是增加三个针对性的 Guard（防护条件）。 Guard（保护规则 / 防护条件） 是为了阻止一个已知错误再次发生而加入的明确检查或约束。

Guard 不应该因为“想更安全”无限增加。

正确来源应该是：

text
发现可复现错误
↓
确认错误机制
↓
增加针对性 Guard
↓
Regression Test

因为修复范围明确，这一轮更准确地说是一个 Grounding Patch（证据落地补丁），而不是重新设计整个 Skill。 Patch（补丁） 是针对已知问题的有限修复。

v0.3.2 没有重构整个系统，而是针对三个已知缺陷打补丁。

这符合我们一贯的原则：

修复已经证明存在的问题，而不是凭想象不断堆规则。

本章关联资料 ​

第 21 章：定向 Regression Test ​

本章导语

Guard 加上以后，还需要证明“改了这里，没有把别的地方弄坏”。本章使用定向 Regression Test，只测试这次真正受影响的行为，让每次修复都留下可重复的证据。

我们没有为了“看起来彻底”把所有测试重新跑一遍。

只针对三个已知错误做定向回归：

  • Test 1 — Summary / UPDATE Compression：PASS；
  • Test 2 — Unknown Field Semantics：PASS；
  • Test 3 — Evidence Label Discipline：PASS；
  • Overall：PASS。

补丁写完不能靠“看起来对了”结束，必须用 Regression Test（回归测试） 重新验证已知缺陷。 Regression Test（回归测试） 是在修复一个问题后，重新验证该问题不会再次出现，并确认修复没有破坏关键已有行为。

由于这次只修三个明确缺陷，因此采用 Targeted Regression（定向回归），只重测相关路径。 Targeted Regression（定向回归） 是只重测与本次修复直接相关的路径。

这比“每次任何小改动都重跑所有东西”更高效，同时仍然保留证据。

本章关联资料 ​

第十部分：为什么现在应该冻结核心架构 ​

第 22 章：Architecture Freeze ​

本章导语

到这里，继续加功能反而可能破坏已经稳定的系统。本章以 Architecture Freeze 收尾：先冻结已经验证过的架构，把后续变化留给真正的新需求，而不是为了“还能优化”就不停改。

三项 Regression 全部 PASS 后，我们没有继续“顺手优化”。

三项回归全部 PASS 后，继续无目标地加规则反而会扩大维护面，因此正式进入 Architecture Freeze（架构冻结）。 Architecture Freeze（架构冻结） 指当前核心架构已经通过预定验证，因此暂停继续修改基础设计。

它不是：

永远不改。

而是：

除非出现新的、明确的、可复现缺陷，否则不继续为了“可能更好”增加规则。

这能防止一个常见工程陷阱：

text
系统已经能工作
↓
继续提前优化
↓
规则越来越多
↓
维护成本越来越高
↓
新规则反而制造新问题

当前冻结点：

text
Weekly Review Harness Core Phase 1
Regression Overall PASS

下一阶段不再是继续改核心，而是等待：

text
First Real Baseline Weekly

这里容易把两个词混在一起：Architecture Freeze 冻结的是当前设计，而 Baseline 建立的是未来比较参考。

  • Architecture Freeze：冻结当前设计。
  • Baseline：建立未来对比的真实参考数据。

二者不是同一个概念。

本章关联资料 ​

第十一部分：Phase 1 最终架构 ​

完整架构参见：

架构总览

核心可以压缩为：

text
Obsidian
Project / Task / Daily / Try
        ↓
Collector / Adapter
        ↓
Normalized JSON
        ↓
Validator
        ↓
Skill
        ↓
Grounded Model Analysis
        ↓
Human Gate
        ↓
Controlled Write-back

每一层为什么存在 ​

Source of Truth ​

保存真实事实与正式业务规则。

Collector / Adapter ​

读取异构真实数据，并转换成统一格式。

Validator ​

负责确定性统计与一致性检查。

Skill ​

负责组织执行顺序、Grounding、Guard、安全边界和模式。

Model ​

负责解释、模式发现、假设、建议。

Human Gate ​

控制 Experiment、Decision、Rule Promotion 和正式写回。

Controlled Write-back ​

只有当所有权限与流程条件满足时，才允许修改正式业务状态。

这套架构以后也可以复用于：

text
Knowledge / Study Review
Finance / Reimbursement

但复用的是“骨架”，不是直接复制周复盘业务规则。

第十二部分：Phase 1 最重要的方法论 ​

1. 程序负责算准，模型负责想明白 ​

确定性工作交给程序；解释工作交给模型。

2. “合理”不等于“有证据” ​

Grounding 不是限制模型思考，而是限制模型把猜测冒充事实。

3. Unknown 是合法答案 ​

证据不足时写 Unknown，比强行给结论更可靠。

4. Observation 不能直接变 Rule ​

text
Observation
→ Hypothesis
→ Experiment
→ Result
→ Rule

中间任何一步都不能因为模型“很确定”而跳过。

5. 警告不是行为结论 ​

Missing Daily、缺字段、schema 不一致属于 Data Quality；不能自动转成人的行为判断。

6. 摘要比正文更需要 Guard ​

Summary / Pattern / UPDATE 会压缩信息，因此特别容易产生 Evidence Compression Drift。

7. Skill 不是第二套业务规则 ​

真实 Vault 已经存在业务 Authority，Skill 只负责可靠执行。

8. 有真实错误，再增加规则 ​

这是整个项目后半段的重要工程纪律：

text
Observation
→ reproducible defect
→ targeted patch
→ regression

而不是：

text
“以后可能出问题”
→ 再加十条规则

第十三部分：辅助材料如何阅读 ​

这一部分是 v1.1 新增的“可达性规则”

从现在开始，辅助文件可以独立保存，但不得脱离正文成为孤立档案。

对话与阶段记录 ​

用于查看某一阶段：

text
当时遇到的问题
→ 实际操作
→ Harness 返回
→ GPT 分析
→ 下一步

入口：

Prompts ​

关键 Prompt 的结构化版本入口：

代码与配置 ​

入口：

测试与返回 ​

入口：

测试结果总表

以后新增原始 Harness 返回时，应从对应章节直接双链，不允许仅把文件丢进 05.测试与返回/ 后无人可达。

术语 ​

入口：

DeepSeek-Harness术语表

正文承担首次教学；术语表承担快速查询、完整索引与复习。

架构与设计决策 ​

文件与路径 ​

文件地图

第十四部分：Reachability Gate——以后不允许再出现“文件存在但看不到” ​

文档本身也暴露出一个类似的结构问题：文件虽然存在，却未必能从正文走到。因此这里把 Reachability（可达性） 明确成文档质量指标。 Reachability（可达性） 在这里指：

一个资料文件是否能从主正文通过双链走到。

以后发布手册前，除 Archive / 纯内部文件外，应检查：

text
Main Manual
↓
是否存在双链路径
↓
每个重要 Prompt / Test / Code / Term / Decision

如果一个重要文件只能靠“自己去文件夹里找”，则它在教学结构上视为不可达。

一旦把可达性当成要求，就需要在发布前增加 Reachability Gate（可达性门）。 Reachability Gate（可达性门）：

发布前检查所有重要材料是否从正文可达。

为了让这个 Gate 可检查，还可以统计 Link Coverage（链接覆盖率）。 Link Coverage（链接覆盖率） 用来衡量有多少辅助资料真正进入正文知识图谱。

理想报告类似：

text
Stage records : 5 / 5 linked
Code artifacts: 7 / 7 linked
Tests         : all key results linked
Terminology   : key terms taught inline
Architecture  : linked
Decisions     : linked

这条规则直接修复 v1.0 的核心结构缺陷：

“文件已经做出来”不等于“读者能够发现它”。

第十五部分：当前冻结状态与下一阶段 ​

当前状态：

text
Weekly Review Harness Core Phase 1
Regression Overall PASS
Architecture Freeze

下一阶段：

text
First Real Baseline Weekly

需要验证真正闭环：

text
完整真实周期
→ 正式 Weekly
→ 正确 UPDATE
→ update-growth.py
→ Growth Archive 更新
→ 下一次 Weekly 能按规则继续衔接

在真正 Baseline 出现新的明确缺陷之前：

不继续修改 Weekly Review Harness Core 基础架构。

附：v1.2 文档治理规则 ​

从本版本起，DeepSeek Harness 培养手册遵守以下规则：

  1. Main Manual 是唯一主阅读入口。
  2. 关键术语第一次出现时必须 Inline Explain。
  3. 独立术语表只负责索引与复查。
  4. 每个重要辅助文件必须从对应正文进入。
  5. Prompt、Harness 返回、代码、测试和设计决策都属于学习证据，而不是“附件垃圾箱”。
  6. 新文件创建后必须检查 Reachability。
  7. 原始 Vault 仍是业务 Source of Truth。
  8. 网站只保存 Published Copy；不得反向成为业务真相源。
  9. Website Adapter 只转换网站副本，不修改 Obsidian Source。
  10. Visual Polish 与“返回上一阅读位置”按钮属于后续 Reading UX / Presentation Phase，本次不处理。