评审真实性P1落地：全量代码可见性+Mock信号+AI日志审计+定向追踪+功能发现轮
- code-inventory.ts：全量符号索引，注入实现类维度，AI 可见100%文件清单 - code-signals.ts：代码信号检测器（TODO密度/空壳率/硬编码返回/死导入），修复TODO检测顺序bug - ai-log-audit.ts：AI日志确定性审计（占位率/git一致率/覆盖广度），占位>50%→≤30%、git一致<30%→≤20%封顶 - standard-utils.ts：isQualitativeDesignDim 定性设计维度豁免C档 - review.service.ts：注入三个模块+定向追踪模板+日志封顶+分支提醒+Map-Reduce功能发现轮 - 预算 15000→40000；新增 review-authenticity.test.ts（14用例） - 实测：净码特攻b3 81分（118功能全量识别），六边形50~62分（Mock被识别）
This commit is contained in:
hangshuo652
@@ -0,0 +1,247 @@
|
||||
# 评审真实性改进方案（2026-08-26）
|
||||
|
||||
> 关联：`docs/design/05-评审流程修正方案.md` §2.11（评审可信度）、`docs/plans/2026-08-19-评审可信度改进.md`
|
||||
> 驱动案例：六边形战队（Mock 内核得 72 分）、净码特攻（205 行真实日志 vs "待补充"日志仅差 3 分、测试环境导致设计维度被误封顶）
|
||||
|
||||
---
|
||||
|
||||
## 0. 结论摘要
|
||||
|
||||
实测暴露当前评审体系的**两层缺陷**：
|
||||
|
||||
1. **真实性执行层缺失**——规范承诺的「抽检回查」「声称 vs 实测」没有系统化抓手。AI 只能看到仓库不到 2% 的内容（125 文件被截断到 15K 字符），Mock 内核、"待补充"日志都能漏网。
|
||||
2. **判档规则粗糙**——三档机制的 `EFFECT_EVIDENCE_KEYS` 过宽，把定性设计维度卷进量化封顶，造成跨队伍不公平。
|
||||
|
||||
本方案以**"让 AI 真实读到全部代码、带着确定性证据定向核查"**为核心，分三期落地。P1 全部为系统侧改动，无外部依赖。
|
||||
|
||||
---
|
||||
|
||||
## 1. 问题定义（实测案例驱动）
|
||||
|
||||
| # | 实测现象 | 根因 | 层 |
|
||||
|---|---------|------|-----|
|
||||
| 1 | 六边形战队核心功能为 Mock，总分仍 72 | 无 Mock 确定性信号；实现类维度凭印象打分；无地板线 | 真实性 |
|
||||
| 2 | AI 使用日志"范式步骤"全部"待补充"，仍得 5~7 分；净码特攻 205 行真实日志得 9~10——差距仅 3 分 | 无日志回查/占位率检测，"有壳"与"有货"无法区分 | 真实性 |
|
||||
| 3 | AI 只读到仓库 <2% 内容（60 文件上限 + 15K 字符截断），且每轮截断样本不同导致分数波动 | 全量可见性缺失 | 真实性 |
|
||||
| 4 | 净码特攻"提效设计合理性"因测试环境跑不通被 C 档封顶到 3，六边形同类维度却拿 6~8 | `EFFECT_EVIDENCE_KEYS` 把定性设计维度卷入量化封顶 | 公平性 |
|
||||
| 5 | 提效幅度无量化数据，AI raw 曾给 6 | 纯增益维度未严格基准制（**已修复**：isPureGainDim，2026-08-26） | 公平性 |
|
||||
| 6 | 两队作品存在 8 个 MD5 相同文件，赛道一二无查重工具 | 查重初筛只在 L2 接入 | 真实性 |
|
||||
|
||||
---
|
||||
|
||||
## 2. 方案总览：三层证据体系
|
||||
|
||||
```
|
||||
第①层 真实性审计（本方案 P1，全自动）
|
||||
代码信号 + 定向追踪 + 日志审计 + 全量可见性
|
||||
→ 回答"做没做、真不真、记录可不可溯"
|
||||
第②层 有效性验证（P2/P3，逐步落地）
|
||||
验收命令执行 + 影子样本混测 + 测量协议检查
|
||||
→ 回答"跑起来管不管用、数字能不能复现"
|
||||
第③层 人工终审（既有机制强化）
|
||||
评委手持①的证据表 + ②的可信度分级做价值裁量；灰色地带约谈（§10 已有）
|
||||
```
|
||||
|
||||
**边界诚实声明**：①②完成后，系统能确认到「声明的功能真实实现了、过程记录可信、在陌生同构输入上表现不塌」。**商业价值大小、体验优劣的最终裁量保留给人工**——这是自动化评审的合理边界，不是缺陷。
|
||||
|
||||
---
|
||||
|
||||
## 3. P1 详细设计（本轮实施）
|
||||
|
||||
### 3.1 全量代码可见性（解决问题 #3）
|
||||
|
||||
#### 3.1.1 符号索引器（确定性，零 LLM 成本）
|
||||
|
||||
新模块 `server/src/services/code-inventory.ts`：
|
||||
|
||||
```ts
|
||||
export interface FileSignature {
|
||||
path: string;
|
||||
lines: number;
|
||||
lang: 'ts' | 'js' | 'py' | 'other';
|
||||
symbols: string[]; // export/function/class 定义行原文（≤5条）
|
||||
}
|
||||
export function buildInventory(files: {path,content}[]): {
|
||||
signatures: FileSignature[]; // 全部文本文件
|
||||
totalLines: number;
|
||||
coreFiles: string[]; // 按规则选出的"精读文件包"
|
||||
}
|
||||
```
|
||||
|
||||
- **语言范围**：ts/tsx/js/jsx/mjs + python（def/class 正则）；其余语言仅记 path+lines
|
||||
- **符号提取**：正则匹配 `^(export\s+)?(async\s+)?(function|class|const\s+\w+\s*=\s*(\(|async))` 与 python `^def |^class `
|
||||
- **coreFiles 选择规则**（替代现"前 60 个文件"粗暴截断）：
|
||||
1. 入口/路由/服务/控制器目录下的代码文件（src/、app/、api/ 等）
|
||||
2. DIM_FILE_FILTERS 各维度命中的文件
|
||||
3. 按行数降序补足至预算
|
||||
|
||||
#### 3.1.2 投喂策略改造
|
||||
|
||||
- 符号索引（全量）**必注入**所有实现类维度的 prompt 头部
|
||||
- `fileBlock` 预算动态化：普通维度 15000 → **40000 字符**；构建维度维持 40000
|
||||
- 截断策略改为"索引全量 + coreFiles 全文"，外围文件只出现在索引里
|
||||
|
||||
#### 3.1.3 Map-Reduce 功能发现轮（新增专轮）
|
||||
|
||||
新增函数 `discoverFeatureInventory(entryId, dir)`（review.service.ts）：
|
||||
|
||||
```
|
||||
输入：coreFiles 全文（按模块聚合分块，每块 ≤12000 字符，块数上限 12）
|
||||
每块调用（小模型档）：
|
||||
"列出这段代码实现的全部功能，输出JSON：
|
||||
[{feature:'一句话功能', files:['文件:行号'], depth:'real|partial|stub'}]"
|
||||
合并去重 → FeatureInventory：
|
||||
{ features:[{name, files, depth}], totalFiles, analyzedChunks }
|
||||
落库：entries.project_understanding 附加字段（或新列 feature_inventory TEXT）
|
||||
```
|
||||
|
||||
- 注入**功能完整性/规模·功能点**维度 prompt：「以下是全量代码扫描发现的实际功能清单，请对照 README 声称与验收基准逐项核对」
|
||||
- 成本：约 8~12 次 LLM 调用（分钟级）
|
||||
|
||||
### 3.2 AI 日志确定性审计（解决问题 #2）
|
||||
|
||||
新模块 `server/src/services/ai-log-audit.ts`：
|
||||
|
||||
```ts
|
||||
export interface LogAuditResult {
|
||||
exists: boolean;
|
||||
lineCount: number;
|
||||
recordCount: number;
|
||||
placeholderRatio: number; // "待补充"/空值 记录占比
|
||||
involvedFiles: string[]; // 所有记录的涉及文件并集
|
||||
gitConsistencyRate: number; // involvedFiles ∩ git变更文件 / involvedFiles
|
||||
coveragePhases: string[]; // 出现过的范式步骤（需求/设计/编码/测试）
|
||||
toPrompt: string; // 注入文本
|
||||
caps: { max?: number }; // 触发的封顶建议
|
||||
}
|
||||
export function auditAiUsageLog(logContent: string, gitChangedFiles: Set<string>): LogAuditResult
|
||||
```
|
||||
|
||||
- 解析：Markdown 表格行按 `|` 切分；涉及文件列提取路径 token
|
||||
- git 变更集：`simpleGit(dir).log(['--name-only'])` 收集全部变更文件路径集合（一次性，已克隆目录内零成本）
|
||||
- **封顶规则**（写入 hard-rules 或内联应用）：
|
||||
- `!exists || lineCount < 5` → AI使用日志维度 ≤ maxScore×0.2
|
||||
- `placeholderRatio > 0.5` → ≤ maxScore×0.3
|
||||
- `gitConsistencyRate < 0.3 && involvedFiles.length >= 5` → ≤ maxScore×0.2，note 注明"日志与 git 历史不一致"
|
||||
- **注入**：AI使用日志维度 extraDimContext 附 toPrompt（含上述数字），prompt 明确"评分必须与审计数字一致"
|
||||
|
||||
### 3.3 代码信号检测器（解决问题 #1 的证据基础）
|
||||
|
||||
新模块 `server/src/services/code-signals.ts`：
|
||||
|
||||
```ts
|
||||
export interface StubSignals {
|
||||
todoDensity: number; // TODO/FIXME/暂不/not implemented 每千行
|
||||
hardcodedReturnRatio: number; // 业务函数 return 字面量占比（启发式）
|
||||
deadImportCount: number; importButNeverCalled: {imp:string,file:string}[];
|
||||
stubFiles: string[]; // 空壳率>50% 的核心目录文件清单
|
||||
toPrompt: string;
|
||||
}
|
||||
export function detectStubSignals(coreFiles: {path,content}[], lang: string): StubSignals
|
||||
```
|
||||
|
||||
- **定位为线索而非判据**：toPrompt 明确写"以下为疑似占位线索，请定向核查后再判定"
|
||||
- 语言范围：TS/JS/Python（与 3.1.1 一致），其他语言返回空报告
|
||||
- 注入：实现类维度（名称命中 `['功能完整','实现完整','规模','功能点']`）的 extraDimContext
|
||||
|
||||
### 3.4 实现类维度定向追踪审查（解决问题 #1 的判定端）
|
||||
|
||||
改造实现类维度子 Agent prompt（通过 extraDimContext 追加任务模板）：
|
||||
|
||||
```markdown
|
||||
## 定向追踪任务（本维度评分的核心依据）
|
||||
|
||||
README/验收基准声称的核心功能如下：
|
||||
[来自验收基准或功能发现轮清单]
|
||||
|
||||
请对每项声称的功能执行：
|
||||
1. 定位实现入口（文件:行号）
|
||||
2. 追踪调用链：入口 → 中间层 → 最终处理逻辑，说明每一层实际做了什么
|
||||
3. 判定实现深度：真实 / 部分实现 / 占位(Mock)
|
||||
- 真实=能对任意合理输入产生正确输出
|
||||
- 部分=主干通但边界/异常缺失
|
||||
- 占位=返回固定数据、空逻辑、仅UI无处理
|
||||
4. 引用代码原文作为证据（不少于1行）
|
||||
|
||||
输出严格JSON：
|
||||
{"checks":[{"feature":"功能名","entry":"文件:行号","depth":"real|partial|stub",
|
||||
"evidence":"代码原文摘录","reason":"判定理由"}],
|
||||
"summary":"总体实现真实性结论"}
|
||||
|
||||
此核对表直接决定本维度得分：
|
||||
真实=该项满分权重；部分=50%权重；占位=0分。
|
||||
```
|
||||
|
||||
- **评分绑定**：子 Agent 返回的 checks 表存入 ai_report.dimensions[n].checks；解析失败回退现状（不崩）
|
||||
- 结合 3.3 信号：toPrompt 中的 stubFiles 作为"重点核查"提示一并注入
|
||||
|
||||
### 3.5 判档修正：定性设计维度豁免 C 档（解决问题 #4）
|
||||
|
||||
standard-utils.ts：
|
||||
|
||||
```ts
|
||||
// 旧：EFFECT_EVIDENCE_KEYS 过宽，把设计合理性类定性维度卷入量化封顶
|
||||
// 新：量化证据维度白名单——只有这些维度适用三档封顶
|
||||
const QUANT_EVIDENCE_KEYS = ['提效幅度', '效果对比', '效率提升', '效果评估', '效果与数据'];
|
||||
export function isQuantEvidenceDim(name): boolean // 替代 isEffectDim 在三档中的使用
|
||||
```
|
||||
|
||||
- `classifyVerifiability`：非量化白名单维度一律 B 档（含"提效设计合理性""XX清晰度"等定性维度）
|
||||
- `detectStructuralContradictions` 的效果维度筛选同步改用 isQuantEvidenceDim
|
||||
- `isEffectDim` 保留兼容（聚合等其他引用处逐一排查后决定去留）
|
||||
- **回归预期**：净码特攻"提效设计合理性"不再被环境因素压到 3；六边形"稳定性满分+Mock内核"的组合不受此项影响（其问题由 3.4 追踪表解决）
|
||||
|
||||
### 3.6 杂项
|
||||
|
||||
- **分支提醒**：cloneRepo 后检测默认分支 ≠ main → addLog 警告"默认分支为 X，不符合规范 §3 要求"，不阻断评审
|
||||
- **赛道一二接查重**（P2，复用 plagiarism-detect，flags 进详情页）
|
||||
- **AGENTS.md** 同步本方案要点
|
||||
|
||||
---
|
||||
|
||||
## 4. P2/P3 规划（本轮不实施）
|
||||
|
||||
| 期 | 项 | 依赖 |
|
||||
|---|---|---|
|
||||
| P2 | 验收命令标准化：README 必填 `## 验收` 命令块，系统新增 tryAccept 执行并留存输出 | 无（规范需同步修订） |
|
||||
| P2 | 测量协议结构化检查：`data/measurement/` 齐备性确定性检查 + 注入提效幅度 prompt | 无 |
|
||||
| P2 | 赛道一二查重初筛接入 | 无 |
|
||||
| P3 | 影子样本机制：命题组按题制作同构官方样本，验收时混测 | 命题组配合 |
|
||||
| P3 | benchmark.ts 激活：seed 缺陷库自动测定评审工具检出率 | seed 库建设 |
|
||||
| P3 | Agentic 按需读取（list/read/search 工具化子 Agent） | 架构改造 |
|
||||
|
||||
---
|
||||
|
||||
## 5. 边界与诚实声明
|
||||
|
||||
1. **语义级价值判断保留人工**：系统可确认"真实实现了声明的功能、过程可溯、陌生输入上不塌"；"商业价值/体验优劣"由评委终审（第③层）
|
||||
2. **多语言覆盖**：深度信号限 TS/JS/Py；其余语言降为基础统计（规范允许任意技术栈，长尾语言接受较弱信号）
|
||||
3. **prompt 型作品覆盖弱**：Agent 类作品核心逻辑在提示词编排时，代码信号敏感度下降——靠定向追踪（LLM 读 prompt 文件本身）+ 日志审计兜底
|
||||
4. **成本增量**：单条目评审时间预计 ×1.3（+功能发现轮）；token 成本 ×1.4 左右。MAX_CONCURRENT=3 不变
|
||||
5. **AI 波动仍存在**：三轮中位数聚合继续有效；本方案降低的是"系统性盲区"，不是随机波动
|
||||
|
||||
---
|
||||
|
||||
## 6. 回归验证场景（实施后必须重测）
|
||||
|
||||
| 场景 | 预期变化 | 对应机制 |
|
||||
|---|---|---|
|
||||
| 六边形战队（Mock内核） | 功能完整性维度产出 checks 表，占位项计 0 分；AI使用日志因占位率 100% 被封顶 ≤3；总分显著低于 72 | 3.4 + 3.2 |
|
||||
| 净码特攻 b3（真实linter集成） | 总分应 ≥67（不应因本次改动下跌）；"提效设计合理性"不再被误 C 档 | 3.5 |
|
||||
| cobol-java（赛道一回归） | 总分 ±5 内波动；无 crash | 全部 |
|
||||
| L2 六边形 b3 样本 | 提效幅度维持 C≤3；功能完整性出现 checks 表 | 3.4 |
|
||||
|
||||
---
|
||||
|
||||
## 7. P1 实施清单
|
||||
|
||||
- [ ] code-inventory.ts 符号索引器 + 单测
|
||||
- [ ] discoverFiles 投喂策略改造（索引全量 + coreFiles 全文 + 预算 40K）
|
||||
- [ ] discoverFeatureInventory Map-Reduce 功能发现轮 + 落库 + 注入
|
||||
- [ ] ai-log-audit.ts + git 变更集采集 + 封顶应用 + 注入 + 单测
|
||||
- [ ] code-signals.ts + 单测
|
||||
- [ ] 实现类维度定向追踪 prompt 模板 + checks 解析 + 评分绑定
|
||||
- [ ] standard-utils.ts 判档白名单重构（isQuantEvidenceDim）+ 相关单测更新
|
||||
- [ ] 分支提醒
|
||||
- [ ] AGENTS.md 同步
|
||||
- [ ] 回归：§6 四场景实测 + 全量 vitest
|
||||
Reference in New Issue
Block a user