208 lines
9.2 KiB
Markdown
208 lines
9.2 KiB
Markdown
# 1
|
||
|
||
我之前在WEB的ChatGPT上打造了一个GPT：“认知科学产品规划架构师--CCRA”，它主要协助我从模糊产品想法中挖掘本质需求，打磨产品形态，规划 MVP，分析关键技术可行性，并输出可交接给 Codex 的产品计划书。
|
||
在Codex开了一个项目，`C:\Users\wangq\Documents\Codex\work-projects\the-mindscape-of-bro-tsong`，负责具体的模型提炼、回归测试等等。
|
||
目前已经进展了4轮，我发现我的工作主要是传递，将评审材料上传到GPT的交流窗口里，将GPT的意见转达给Codex，评审材料的路径：`C:\Users\wangq\Documents\Codex\work-projects\the-mindscape-of-bro-tsong\ccra_review_bundle`；少部分是与GPT讨论规划，对Codex的工作进行评价。
|
||
|
||
对我来说，有价值的是少部分的这个工作，而转递工作是繁琐且价值低下的。于是我与GPT交流，是否可以在本地打造一个Agent。
|
||
它的回复参见对话记录`C:\Users\wangq\Documents\Codex\knowledge-vault\work\internal\强哥的思想宇宙\讨论\2026-06-18产品交流-GPT.md` 338行 至 文档末尾。
|
||
|
||
我本地有一个打造Agent的CCPE System，`C:\Users\wangq\Documents\Codex\ccpe-system\`；还有完成自动化的`C:\Users\wangq\Documents\Codex\skills-vault`。这两个都是做工具打造的。
|
||
|
||
那么我现在的Agent应该怎么做？我的思路如下：
|
||
|
||
**环境初始化:**
|
||
`C:\Users\wangq\Documents\Codex\work-projects`是我的项目总路径，我在其下建立一个`the-mindscape-of-bro-tsong-ccra-reviewer`，这个作为一个新项目来做本地CCRA Review工作。
|
||
我在`the-mindscape-of-bro-tsong-ccra-reviewer`项目中，与Codex交流，初始化后，生成对Agent或者Skill的需求单：
|
||
类似`C:\Users\wangq\Documents\Codex\work-projects\the-mindscape-of-bro-tsong\requirements`这样。
|
||
然后到CCPE或者skills-vault中去打造。
|
||
然后回来搭建CCPE的Agent调用环境。
|
||
|
||
**本地评审工作：**
|
||
将每轮的评审资料先发给（本地链接，引用即可）`the-mindscape-of-bro-tsong-ccra-reviewer`。
|
||
|
||
---
|
||
|
||
**我的问题：**
|
||
1. 在`the-mindscape-of-bro-tsong-ccra-reviewer`中，Codex是否会调用Agent，在主会话还是子会话中？
|
||
2. 你对这个有什么建议么？
|
||
|
||
建议做，但不要把它做成“复制网页版 GPT 的本地人格”。更稳的定位是：
|
||
|
||
**`the-mindscape-of-bro-tsong-ccra-reviewer` = 本地 CCRA Review 控制台项目**
|
||
它负责收束评审材料、生成调用包、记录本地评审报告、沉淀需求单；真正的 Reviewer Agent 和自动化 Skills 分别去 `ccpe-system` / `skills-vault` 打造。
|
||
|
||
**1. Codex 会在主会话还是子会话调用 Agent？**
|
||
|
||
默认不会自动调用独立 Agent。你在 reviewer 项目里和 Codex 对话时，当前 Codex 主会话只是“操作者 / 调度者”。如果只是写一个 `AGENTS.md` 或安装 Skill，通常还是当前主会话加载这些规则来工作。
|
||
|
||
如果你要保留 CCRA 的“正交审查”价值，就应该明确规定：
|
||
|
||
- 主会话：只做调度、整理材料、生成 invocation packet、归档结果。
|
||
- 子会话 / 新线程 / subagent：执行 `ccra-reviewer` 的只读评审。
|
||
- Skills：做确定性检查，比如 bundle audit、routing diff、lifecycle scan。
|
||
- 原项目 Codex 执行会话：根据 reviewer findings 回到 `the-mindscape-of-bro-tsong` 修文件。
|
||
|
||
也就是说，**机械检查可以在主会话跑；带判断性的 CCRA Review 应该在子会话或新线程跑**。如果在同一个主会话里让 Codex“扮演 CCRA”，那只能算 preliminary self-review，不应该当成正式 CCRA 评审。
|
||
|
||
**2. 我的建议**
|
||
|
||
我建议你按三层做：
|
||
|
||
第一层：新建 `C:\Users\wangq\Documents\Codex\work-projects\the-mindscape-of-bro-tsong-ccra-reviewer`
|
||
这个项目只做评审工作台，不复制原项目。建议目录：
|
||
|
||
```text
|
||
requirements/
|
||
review-runs/
|
||
invocation-packets/
|
||
reports/
|
||
scripts/
|
||
AGENTS.md
|
||
README.md
|
||
```
|
||
|
||
每轮只引用原项目 bundle 路径，比如：
|
||
|
||
```text
|
||
C:\Users\wangq\Documents\Codex\work-projects\the-mindscape-of-bro-tsong\ccra_review_bundle\round-04.1_2026-06-18_selector-rule-patch
|
||
```
|
||
|
||
第二层：在 `ccpe-system` 打造 `ccra-local-reviewer` 的 Agent 规格
|
||
放角色契约、评审 rubric、报告格式、禁止事项、调用边界。重点写清楚：
|
||
|
||
- 只读审查，不直接改业务文件；
|
||
- 优先读 source files、diff、reports、tests，不优先读 Codex 总结；
|
||
- 必须指出反证、非目标行为变化、测试未证明的产品判断；
|
||
- 不自动决定模型升级；
|
||
- 输出 findings / risk / next actions。
|
||
|
||
第三层：在 `skills-vault` 做少量高价值 Skill
|
||
不要一开始做五六个。先做两个最值钱的：
|
||
|
||
```text
|
||
routing-diff-audit
|
||
round-init-context-builder
|
||
```
|
||
|
||
然后再补：
|
||
|
||
```text
|
||
review-bundle-audit
|
||
lifecycle-guard
|
||
regression-gate-check
|
||
```
|
||
|
||
最终工作流可以是：
|
||
|
||
```text
|
||
原项目 Codex 生成 review bundle
|
||
-> reviewer 项目生成 invocation packet
|
||
-> 子会话运行 ccra-local-reviewer
|
||
-> 输出 LOCAL_CCRA_REVIEW_REPORT.md
|
||
-> 主会话归档并提炼给执行 Codex
|
||
-> 原项目 Codex 修复
|
||
-> Skill 跑 diff / regression / lifecycle gate
|
||
-> Owner 决定是否关闭 round
|
||
```
|
||
|
||
最重要的边界是：**reviewer 项目是控制台，CCPE 是 Agent 规格工厂，skills-vault 是自动化工具源码仓，`.agents\skills` 是安装运行面。**
|
||
你这个方向是对的，但第一版要克制：先把“少搬运 + 真隔离 + 可归档”跑通，再扩大自动化。
|
||
|
||
# 2
|
||
|
||
**问题：**
|
||
1. 那如果主会话都是模拟，只能是子会话调用，我还有必要将本地审核单独成项目么，我不如在原项目`the-mindscape-of-bro-tsong`中直接打造审核者？
|
||
2. 按我的理解，CCRA推荐Agent的那些Skill，应该不全是skill-vault的职责，有些应该是CCPE为Agent配套打造的。因为skills-vault的skill，一是自动化，二是有通用性。
|
||
|
||
你的理解更准确，我会修正上一版建议。
|
||
|
||
**1. 不一定需要单独建 `the-mindscape-of-bro-tsong-ccra-reviewer`**
|
||
|
||
如果目标只是让 CCRA 评审在子会话中真实发生，**目录隔离不是关键，调用隔离才是关键**。正交性来自：
|
||
|
||
- 子会话 / 新线程独立读取材料；
|
||
- reviewer 只读，不直接修；
|
||
- reviewer 优先读 bundle、diff、reports、tests；
|
||
- 输出固定评审报告；
|
||
- 主会话只做调度和归档。
|
||
|
||
所以对当前项目，我更建议先不要新建独立项目，而是在原项目里加一个评审运行区，例如：
|
||
|
||
```text
|
||
C:\Users\wangq\Documents\Codex\work-projects\the-mindscape-of-bro-tsong\
|
||
ccra_review_bundle\
|
||
local_ccra_reviews\
|
||
round-05\
|
||
invocation-packet.md
|
||
prompt-to-send.md
|
||
LOCAL_CCRA_REVIEW_REPORT.md
|
||
owner-decision.md
|
||
requirements\
|
||
ccra-local-reviewer-requirements.md
|
||
```
|
||
|
||
这样证据、bundle、报告、执行修复都在同一个项目历史里，路径最短，也最不容易产生“评审工作台和真实项目脱节”。
|
||
|
||
但我不建议把“审核者本体”直接做成这个项目里的私有规则。原项目里可以放调用包、需求单、评审记录；**Agent 规格本体仍应进入 `ccpe-system`**。否则它会变成这个项目的临时 prompt，而不是可复用的 CCRA 审查能力。
|
||
|
||
独立 reviewer 项目只有在这几种情况下才值得建：
|
||
|
||
- 你想让它跨多个 work-projects 统一管理评审；
|
||
- 你想把本地 CCRA 当成长期运营台，有自己的报告索引、模板、批处理脚本；
|
||
- 原项目不希望混入任何评审过程文件；
|
||
- 你需要集中对比多个项目的 CCRA 评审质量。
|
||
|
||
当前阶段，我建议：**先原项目内运行，成熟后再抽出 review workspace。**
|
||
|
||
**2. 你对 Skill 归属的判断是对的**
|
||
|
||
CCRA 提到的那些 “Skill” 不应该全放 `skills-vault`。应该按性质分层：
|
||
|
||
```text
|
||
ccpe-system
|
||
Agent / reviewer spec
|
||
cognitive review rubric
|
||
lifecycle gate policy
|
||
round governance workflow
|
||
evaluation method spec
|
||
|
||
skills-vault
|
||
deterministic automation
|
||
reusable scripts
|
||
file/package audit
|
||
routing diff checker
|
||
manifest validator
|
||
report generator
|
||
```
|
||
|
||
更具体地说：
|
||
|
||
- `routing-diff-audit`：偏自动化、可复用，适合 `skills-vault`。
|
||
- `review-bundle-audit`：偏文件结构检查，也适合 `skills-vault`。
|
||
- `round-init-context-builder`：如果只是生成上下文文件，适合 `skills-vault`；如果包含 CCRA 判断框架，则 CCPE 里定义规则，skills-vault 只执行模板生成。
|
||
- `lifecycle-guard`：分两层。生命周期守门原则属于 `ccpe-system`；扫描文件里是否错误升级 `status/stability/regression_status` 的脚本属于 `skills-vault`。
|
||
- `regression-gate-check`：运行测试、校验结果属于 `skills-vault`；判断测试是否足以支撑模型升级属于 CCRA Agent / CCPE 评审规则。
|
||
|
||
所以我会把方案调整成：
|
||
|
||
```text
|
||
原项目 the-mindscape-of-bro-tsong
|
||
存放每轮本地 CCRA 调用包、评审报告、Owner 决策
|
||
|
||
ccpe-system
|
||
打造 ccra-local-reviewer Agent 规格和评审协议
|
||
|
||
skills-vault
|
||
打造通用自动化 Skill 和脚本
|
||
|
||
子会话 / 新线程
|
||
真正执行 CCRA review
|
||
```
|
||
|
||
一句话：**不要为“正交性”单独建项目；为“长期运营多个项目的 CCRA 审查台”才单独建项目。当前先在原项目内做 review run，更务实。**
|
||
|
||
|
||
|
||
|