wantsong
/
knowledge-vault
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
knowledge-vault/discussions/technology/Codex/1.重构CCPE/打造Local-CCRA.md

29 KiB
Raw Blame History

1

阅读需求单： C:\Users\wangq\Documents\Codex\work-projects\the-mindscape-of-bro-tsong\requirements\ccpe\2026-06-19-ccra-local-reviewer-runtime.md

有问题提出。 你对这个怎么考虑，尤其是skills，我们是做agent配套的，还是可以抽出来公共的，交给skills-vault去实现。 我们先对齐思路。

我倾向于采用“分层，不二选一”。

这份需求单本体应归类为 Hybrid Artifact：ccra-local-reviewer 是 CCPE-Agent + CCPE-Runtime + 评审 rubric / lifecycle policy + 可能的 Integration Registration。它要求真实子会话、文件优先、只读评审、不能把本地 CCRA 当 Owner/Web CCRA 终审，这些都属于 CCPE 的 Agent/Runtime 治理层，不是普通 Skill。需求单里也明确说第一版只服务这个项目，但能力本体由 CCPE 供应，项目只存 local_ccra_reviews/ 运行记录和需求单：需求单。

Skill 的判断标准 我建议这样拆：

能力 归属判断
CCRA 评审视角、反证逻辑、finding 分类、lifecycle/scope 判断 CCPE，放进 Agent Spec / Runtime / rubric
“测试通过是否足以支撑模型升级”这种判断 CCPE Agent 判断，不是自动化 Skill
review bundle 结构完整性检查 skills-vault，做通用 review-bundle-audit
selector patch 前后 routing 行为差异 skills-vault 实现通用 diff；CCPE 定义哪些变化有治理意义
lifecycle 状态误升级扫描 分层：CCPE 定义守门规则，skills-vault 做文件扫描器
regression / validation 命令执行与结果收集 skills-vault；CCPE 判断结果是否足够支持阶段结论
round 初始化上下文生成 先作为 Runtime 支持；如果只是模板/文件生成，再抽到 skills-vault

也就是说，你的判断是对的：不是所有 “Skill” 都该进 skills-vault。上游讨论里已经有同样结论：CCPE 放 Agent/reviewer spec、cognitive review rubric、lifecycle gate policy、round governance workflow；skills-vault 放 deterministic automation、file/package audit、routing diff checker、manifest validator、report generator：本地 CCRA 讨论。

我不建议的两种极端 一种是把五个候选能力全塞进 ccra-local-reviewer Runtime。这样短期快，但 CCPE 会开始积累自动化源码，边界会坏。

另一种是把候选能力全丢给 skills-vault。这样也不对，因为 CCRA 的价值不是“跑检查器”，而是正交审查、生命周期守门、识别工程 pass 和产品判断之间的断裂。这个判断层必须留在 CCPE Agent/Runtime。

推荐方案 先在 CCPE 产出最小可用套件：

  1. ccra-local-reviewer.agent.md
  2. ccra-local-reviewer.runtime.md
  3. local-ccra-review-report.template.md
  4. ccra-findings-rubric.md
  5. 一份 companion automation routing note，逐项标明“暂留 Runtime / 请求 skills-vault / 产品本地 helper”。

第一批真正发给 skills-vault 的我建议只选两个高 ROI 且通用性强的：

  1. review-bundle-audit
  2. routing-behavior-diff-audit

lifecycle-status-guard-scan 和 regression-validation-gate-runner 可以作为第二批，因为它们需要先把项目里的状态字段、命令入口、validation 语义梳理清楚，否则容易做成只对当前目录硬编码的脚本。

需要先对齐的一个关键问题 我建议把 ccra-local-reviewer 定义成“本地只读初审 Agent”，不是“完整复制 Web CCRA 的本地人格”。Web CCRA 继续保留关键节点的外部复审位置；Local CCRA 负责第一轮正交检查、机械审查和明显治理风险识别。这也符合上游说法：“本地 CCRA Reviewer = 一个只读、审查型、反证型 Agent，加上一组确定性检查 Skill”：产品交流-GPT。

我的建议是：确认这个分层后，下一步先不写完整五个 Skill 请求，而是先在 CCPE 写 Creation Brief，把 Agent/Runtime 和 Skill 候选路由表定死。然后再决定第一批是否只向 skills-vault 提两个请求。

2

补充信息

  1. the-mindscape-of-bro-tsong是认知模型治理体系，包括治理过程和模型卡这些，本项目中原规划的model-cards，model-index这些，将来会被建成后的the-mindscape-of-bro-tsong取代。因为本项目的model只是从一篇文章中一次性抽取，而the-mindscape-of-bro-tsong在做工程化。
  2. 本项目需要也像C:\Users\wangq\Documents\Codex\work-projects\the-mindscape-of-bro-tsong\requirements\skills-vault\README.md这样，有一个requirements目录，便于存放skills-vault的需求。

关键问题回复

我建议把 ccra-local-reviewer 定义成“本地只读初审 Agent”，不是“完整复制 Web CCRA 的本地人格”

我不同意。原因：

  1. 本地LLM能力与WEB相同甚至更强，Codex的GPT5.5和Web的ChatGPT5.5是两种计算通道。比如现在ChatGPT的pro，我已经没有流量了；而Codex的超高还是满的。
  2. 文件阅读能力更强，完全可以按需检索，而不是只基于我上传的文件。比如，我上传给ChatGPT的只能是17个回归测试的一个，作为抽查；而本地可以全量检查。
  3. 本地更支持各种开发环境。在Review时，若需要其他工具，本地可以自行构造。

WEB更应该承担的是：

  1. 与我讨论每一轮工作的规划
  2. 每一轮工作的终验，而不是不停发起一次次小轮的检查。比如，第三轮，就有03、03.1，03.2，03.2a这样4次检查。我的搬运工作量太大。

那么我的预期目标是：

  1. WEB与我做规划
  2. 本地复杂调优完成规划目标
  3. WEB进行复核检查，争取一次性通过。

下一步

基于我的这些澄清回复，你需要做一个规划，后续有哪些工作。 有问题随时提出。

接受你的修正：ccra-local-reviewer 不应被定义成“低配初审”。更准确的定位是：

Web CCRA = 规划对齐 + 终验复核。
Local CCRA = 本地正式复杂调优与复核 Runtime，负责把多轮小检查、全量文件审查、测试/回归/diff/证据核查尽量在本地闭环。

它仍然不能替代 Owner 决策，也不能把模型生命周期自动升级；但它可以成为“送 Web 终验前”的正式本地质量门。

后续工作规划

  1. 先做边界与需求入口修正

    • 在 ccpe-system 增加类似 requirements/skills-vault/README.md 的入口，用于存放 CCPE 对 skills-vault 的自动化能力需求。
    • 同时更新 CCPE 边界说明：the-mindscape-of-bro-tsong 将成为长期认知模型治理系统；CCPE 的 model-cards / model-index 保留为协议、模板、历史/示范资产，不再被误解成未来主治理库。

  2. 做 Local CCRA 的 CCPE 核心套件

    • agents/agent-specs/ccra-local-reviewer.agent.md
    • runtimes/hybrid/ccra-local-review.runtime.md
    • Local review run 文件契约：local_ccra_reviews/<round>/<pass>/
    • 04_LOCAL_CCRA_REVIEW_REPORT.md 模板
    • findings rubric：blocker / major / minor / calibration / defer
    • lifecycle / scope guard 规则

  3. 把“Agent 配套方法”与“skills-vault 自动化”拆清楚

    • CCPE 内保留：评审视角、反证逻辑、生命周期判断、工程 pass 与产品判断的区分、Round scope 判断。
    • skills-vault 实现：bundle 完整性审计、routing behavior diff、regression/validation runner、lifecycle 状态扫描、上下文包生成器。
    • CCPE 后续只登记这些工具依赖，不复制实现源码。

  4. 第一批 skills-vault 需求建议

    • review-bundle-audit
    • routing-behavior-diff-audit
    • regression-validation-gate-runner
    • lifecycle-status-guard-scan
    • round-review-context-builder

  5. 最后做一次真实试运行

    • 推荐用 Round 05 或最近一个完整 review bundle 做 pilot。
    • 主会话只做 orchestrator。
    • Local CCRA 必须跑真实子会话/线程，不接受主会话模拟。
    • 输出本地报告后，再用 Web 做终验校准。

我建议下一步先落一个 Creation Brief + work batch plan，把目标文件、边界、第一批 skills-vault 请求名定下来；确认后再开始写 CCPE Agent/Runtime 文件。

3

关于最后做一次真实试运行，我会让the-mindscape-of-bro-tsong调取，对已有的03或04轮的评审资料做检查：

  1. 是否真实调起子会话，是否可以保持子会话
  2. 回复内容是否达到了WEB CCRA的质量
  3. 基于以上，看是否有调优的内容
  4. 调优后，再考虑正式投入到 Round 05

同意你的下一步建议。 你可以完成后续的所有工作了。 相应的文档输出后，我会去skills-vault 打造相应的skill，再返回来，看你是否能看到定义。

已按你修正后的定位完成 CCPE 侧文件输出：Local CCRA 被定义为“本地正式复杂调优/复核 Runtime”，不是低配初审；Web CCRA 保留规划对齐和终验复核。

主要文件：

给 skills-vault 的五个请求单也已分别落好：

我还更新了 README.md 和 PROJECTS.md，补上 requirements/skills-vault/ 入口，以及 the-mindscape-of-bro-tsong 将作为工程化认知模型治理系统、拥有未来模型卡/模型索引主治理面的边界说明。

验证已跑：git diff --check 没有空白错误，只有 Windows LF/CRLF 提示；所有 14 个预期文件 Test-Path 都是 OK；占位词扫描 TBD|TODO|implement later|fill in details|placeholder 无命中。尚未 staged/commit。

下一步你可以去 skills-vault 按这五个请求单实现对应 Skill；实现并安装后，回到 CCPE 这里再做 Integration Registration 和一次 Round 03/04 pilot 调用验证。

4

关于skills-vault 的五个请求单，我想确认一下，这五个Skill，除了ccra-local-review，还有其他场景，Agent会用么？ 我们的这个五个Skill，是否满足通用的，公共的这个属性？

请你分别讲一下这五个技能，外部（非ccra-local-review）会用来做什么，或者什么场景下用？

如果不是通用的，skills-vault会拒绝开发。

结论：五个里 4 个明显满足公共属性，1 个需要改名/泛化后再交给 skills-vault 更稳。

Skill 公共性判断
review-bundle-audit 公共，适合开发
routing-behavior-diff-audit 公共，适合开发
regression-validation-gate-runner 公共，适合开发
lifecycle-status-guard-scan 公共，但要强调 config-driven，不绑定 CCRA
round-review-context-builder 边界最弱，建议改成 review-context-builder 或 evidence-context-pack-builder

1. review-bundle-audit 外部用途：任何 Agent 在正式评审前检查“交付给 reviewer 的文件包”是否完整。

可用场景：

  • writing-workbench 的文章评审包：brief、outline、source digest、reviewer reports 是否齐。
  • video-workbench 的视频脚本/素材评审包：脚本、分镜、素材清单、导出说明是否齐。
  • skills-vault 自己发布 Skill 前：源码、测试、fixtures、README、安装说明是否齐。
  • 任意 Web GPT / Gemini / Claude 上传包：manifest、zip、sidecar、报告是否齐。

公共性成立，因为它审的是“bundle/package 完整性”，不是 CCRA 判断。

2. routing-behavior-diff-audit 外部用途：任何规则路由器、分类器、selector、dispatcher 修改前后的行为差异审计。

可用场景：

  • QPI selector patch 前后对比。
  • 文章素材 topic router 修改后，哪些来源块被分到不同主题。
  • 多 Agent 调度器修改后，任务被分派给不同 Agent。
  • 客服 intent classifier、issue triage、内容安全分类器、模型选择器的 before/after diff。
  • CI 中检查规则变更是否产生非目标行为变化。

公共性成立，但请求单里应持续避免把它写成 QPI 专用。核心输入应是 case_id + before_route + after_route + optional expected_route。

3. regression-validation-gate-runner 外部用途：按 manifest 跑一组声明好的验证命令，并记录结果和日志。

可用场景：

  • skills-vault 技能发布前跑 tests / lint / install check。
  • the-mindscape 跑 index rebuild、selector regression、contract checks。
  • 代码项目做 release review 前跑 test/build/typecheck。
  • 文档/报告项目跑 link check、schema check、bundle check。
  • Agent Runtime 在评审前收集“哪些检查跑过，哪些没跑”的证据。

公共性很强，因为它不是“判断是否通过产品验收”，只是“执行和记录验证门”。

4. lifecycle-status-guard-scan 外部用途：扫描文件里是否出现未被证据支持的状态/生命周期/批准类声明。

可用场景：

  • Model Card 从 draft 误写成 stable。
  • Agent Spec 从 draft 误写成 active。
  • Skill 发布说明误称 installed/validated/released，但没有测试记录。
  • 项目报告误称 Owner approved、final accepted、production ready，但缺决策记录。
  • 数据集、模型、文档、流程状态字段的治理扫描。

公共性成立，但要把 CCRA/Owner 视作配置里的例子，而不是内置规则。更公共的描述是：status / approval / lifecycle claim scanner with configurable evidence markers。

5. round-review-context-builder 这个最危险。现在的名字和字段都偏“评审轮次”，容易被 skills-vault 认为是 Local CCRA 附属工具。

它能公共化，但建议改名：

  • review-context-builder
  • 或 evidence-context-pack-builder

外部用途：

  • 文章评审前，把 source、outline、review goals、prior decisions 做成 context pack。
  • PR / release review 前，把 diff、test logs、issue links、decision notes 做成 review context。
  • 模型卡评审前，把 source docs、schema reports、regression outputs 做成证据包。
  • 视频项目评审前，把脚本、素材、导出版本、反馈记录做成上下文索引。
  • 任意 Agent 子会话启动前，生成“应该读哪些文件”的 manifest。

公共性条件：它只能做文件索引和上下文包组装，不能写 CCRA findings，不能替 reviewer 总结判断，不能默认存在 round_id。round_id 可以是可选字段，泛化成 review_id 更好。

我的建议：交给 skills-vault 时，前四个可以直接提；第五个先改名为 review-context-builder，把请求单里所有 CCRA/round 专用措辞降成“first consumer/example”。这样 skills-vault 更难拒绝。

5

那么需要你修改这个请求工单吧？ 有了这些公共技能，怎么用，应该在CCRA中记录吧？

已修。

核心改动是把不够公共的 round-review-context-builder 改成了通用的 review-context-builder，请求单路径也改为：

2026-06-19-review-context-builder.md

现在五个 skills-vault 请求单都补了 “Example non-CCRA consumers”，说明它们在 writing-workbench、video-workbench、skills-vault、ccpe-system、开发仓库等非 CCRA 场景下怎么复用，避免被理解成 CCRA 私有工具。

也已在 CCRA 侧记录怎么用这些公共技能：

ccra-local-reviewer.agent.md

ccra-local-review.runtime.md

关键边界也写进去了：这些 Skills 只产出可验证证据、清单、diff、日志和扫描结果，不代替 CCRA 的评审判断；Local CCRA 使用它们作为证据输入。

我做了检查：旧名称 round-review-context-builder 和旧输出 round-review-context.md 已无残留；新请求单存在；git diff --check 通过，仅有 Windows 换行提示。未暂存、未提交。

6

5个Skills全部开发完毕并实装。 接下来需要你查看skills，并定义，在Agent中说明，对吧？ 然后准备好需要的Runtime配套文件，以便外部可以调用。 最后给我一个说明或者已有的文件，我在the-mindscape-of-bro-tsong项目中开始运行时环境搭建。

是的，方向就是这样：CCPE 不复制 skills-vault 源码，只注册已安装能力；Agent/Runtime 说明如何消费这些 Skill 输出；项目侧按 Runtime 配套文件创建真实运行环境。

我已经完成这轮 CCPE 配套更新：

验证也做了：5 个安装面和源码面的 SKILL.md 都可读；5 个 installed script 的 --help 全部成功；git diff --check 无错误，仅有 README.md / PROJECTS.md 的 CRLF 提示。未暂存、未提交。

7

我需要确认： WEB CCRA有一个知识库，是我手动上传的文档。Local CCRA也需要这个知识库，这个知识库，我觉得可以直接使用目标路径C:\Users\wangq\Documents\Codex\work-projects\the-mindscape-of-bro-tsong\knowledge_assets，使用一份即可，没必要搞多份。 那么，现在的CCRA是否规定了这个知识库路径？

若没有的话需要调整，这个对the-mindscape-of-bro-tsong环境构造有影响么？ 若已经规划了，那就不改了。

确认：之前没有把这个知识库路径作为 CCRA 的固定约定写进去，只是泛化地让 review-context-builder 接收 source-root。这对 the-mindscape-of-bro-tsong 环境构造有影响，所以我已经补了。

现在已明确规定 Local CCRA 直接使用同一份知识库：

C:\Users\wangq\Documents\Codex\work-projects\the-mindscape-of-bro-tsong\knowledge_assets

已更新的位置：

我也验证了目标路径存在，并且至少有：

knowledge_assets/README.md
knowledge_assets/10_本地CCRA评审机制说明.md

git diff --check 无错误，仍只有之前的 README.md / PROJECTS.md CRLF 提示。未暂存、未提交。

8

我已经完成了第一次试运行测试，结论：

  • Web 版更强在“产品诊断 + 下一步修复范围”
  • Local 版更强在“全量文件审计 + 证据覆盖 + 运行机制风险”。

由此整理出需求的补丁单： 2026-06-19-ccra-local-reviewer-runtime-patch1.md

WEB版CCRA的原始提示词位置在：C:\Users\wangq\Documents\Codex\knowledge-vault\prompts\GPT\认知科学产品规划架构师\认知科学产品规划架构师.md。

现在需要你根据需求补丁单，对CCRA进行相关的优化。 以便我进行第二次的试运行测试。

Patch 1 已完成，CCRA Local 现在按“Web 产品诊断能力 + Local 全量证据审计能力”的组合来约束。

主要改动在这些文件：

第二次试运行时，建议在 the-mindscape-of-bro-tsong 里按 ccra-local-review-runtime-setup.md 建 pilot-02 目录：先发 turn_type: review_turn，产出 04_LOCAL_CCRA_REVIEW_REPORT.md；然后在同一个子会话继续发 turn_type: planning_turn，产出 next-review-requirements.md。

我做了校验：旧 0.1.0 运行协议残留已清掉，必需文件都存在，git diff --check 没有新增空白错误；只看到 README.md、PROJECTS.md 的 CRLF 提示和当前工作区已有未跟踪文件状态。我没有提交，也没有修改 the-mindscape-of-bro-tsong 项目文件。

9

阅读C:\Users\wangq\Documents\Codex\work-projects\the-mindscape-of-bro-tsong\requirements\ccpe\2026-06-19-ccra-local-reviewer-runtime-patch2.md

这是第二次试运行完成后的一个新补丁。 有问题可以提出，现在修复ccra-local-review

已按 Patch 2 修复 ccra-local-review，版本推进到 0.1.2。这次是 helper 可靠性和返回形态硬化，没有改变 Patch 1 的 review_turn / planning_turn 同子会话模式，也没有改 the-mindscape-of-bro-tsong 项目文件。

改动集中在这些文件：

覆盖的 Patch 2 点：

  • 定义 ccra_mindscape_review_bundle profile contract，识别 BUNDLE_FILE_MANIFEST_04.md / 04.1 这类版本化 manifest；generic profile 不再自动等于 bundle blocker。
  • 新增 gate_execution_mode: dry_run | run | owner_waived | not_applicable，明确 dry-run 只能做 planning/preflight，不能支持 pass claim。
  • before/after 证据存在时，routing diff 必须有 helper 输出或 manual equivalent table。
  • lifecycle scan 增加 scope modes 和 triage categories，whole-repo scan 是 broad audit，不是默认 blocker。
  • 正式固化短 returned-output.md Owner-facing summary 字段。

校验已跑：

  • 旧活动版本 0.1.1 无残留，核心文件均为 0.1.2。
  • Patch 2 关键字段均可检索到：gate_execution_mode、routing_diff_policy、lifecycle_scan_scope、returned-output.md、profile_mismatch 等。
  • git diff --check 无新增空白错误；只看到工作区已有的 README.md / PROJECTS.md CRLF 提示。
  • 未提交，未 stage。