@chongyan/autospec 1.0.2 → 1.0.4

package/knowledge/03-guides/08-evaluate-ai-effect.md

@@ -1,100 +0,0 @@
----
-name: ai-effect-evaluator
-description: 当需要执行 AI/模型组件的效果评测、验证任务完成质量时触发
-type: execute
----
-
-> ⚠️ **已整合** - 本指南内容已整合到 [评测设计模板](../09-templates/09-evaluation-design.md)
->
-> **版本**: v1.0
-> **最后更新**: 2026-03-26
-> **状态**: 已废弃（内容整合到模板）
-> **替代文档**: [09-evaluation-design.md](../09-templates/09-evaluation-design.md)
-
-## 定位
-
-效果评测执行阶段的"执行"类 skill。负责加载评测数据集、执行评测、计算指标。
-
-> **使用场景**：项目包含 AI/模型组件，需要验证效果是否满足要求。
-
-## 输入
-
-- 必须输入：AI/模型组件、评测数据集
-- 可选输入：评测方案（evaluation-plan.md）、评测脚本
-
-## 执行步骤
-
-### Step 1: 准备评测环境
-
-1. 检查是否有评测方案（`.autospec/specs/{feature}/evaluation-plan.md`）
-2. 检查是否有评测数据集（`.autospec/specs/{feature}/evaluation/dataset/`）
-3. 检查是否有评测脚本（`tests/evaluation/`, `evaluation/`）
-
-### Step 2: 加载评测数据集
-
-1. 读取评测数据集
-2. 验证数据集格式
-3. 统计数据集规模
-
-### Step 3: 执行评测
-
-1. 初始化被评测的 AI/模型组件
-2. 对每个测试用例执行推理
-3. 收集预测结果
-
-### Step 4: 计算评测指标
-
-根据评测方案中的指标定义计算：
-
-1. **准确率指标**：
-   - 激活准确率、匹配准确率等
-
-2. **质量指标**：
-   - 响应质量、任务完成率等
-
-3. **性能指标**：
-   - 响应时间、吞吐量等
-
-### Step 5: 生成评测报告
-
-1. 汇总各项指标
-2. 与目标值对比
-3. 识别 badcase
-
-## 输出格式
-
-```
-## 效果评测结果
-
-### 评测对象
-- 组件名称：{component_name}
-- 评测数据集：{dataset_path}
-- 测试用例数：{total_cases}
-
-### 评测指标
-| 指标名称 | 目标值 | 实际值 | 状态 |
-|----------|--------|--------|------|
-| ... | ... | ... | ✅/❌ |
-
-### Badcase 分析
-| 用例 ID | 输入 | 预期输出 | 实际输出 | 问题描述 |
-|--------|------|----------|----------|----------|
-| ... | ... | ... | ... | ... |
-
-### 结论
-- 评测通过：✅ 是/❌ 否
-- 达标指标：{passed_count}/{total_count}
-- 需要优化：{需要优化的点}
-```
-
-## 判定标准
-
-- **通过**：所有指标达到目标值
-- **部分通过**：部分指标达标
-- **不通过**：主要指标未达标，需要优化
-
-## 适用场景
-
-- 适用：AI/模型组件需要验证效果
-- 不适用：普通功能无需效果评测
-- 对应做类 skill：test-generator（生成测试）

package/knowledge/03-guides/09-review-requirement.md

@@ -1,83 +0,0 @@
----
-name: requirement-reviewer
-description: 当结构化需求文档完成、需要评审其完整性和无歧义性以决定是否可进入设计阶段时触发
-type: review
----
-
-## 定位
-需求阶段的"审"类skill。独立审查需求文档质量，作为进入设计阶段的Layer 2质量关卡。
-
-> **做审分离（DP2）**：必须由独立于requirement-analyzer的AI实例执行。
-
-## 输入
-- 必须输入：结构化需求文档（requirement-analyzer的输出）、原始需求（对照是否偏题）
-- 可选输入：methodology/checklists/requirement.md（检查标准）
-
-## 评判标准
-必须满足：
-- [ ] 每条功能需求有明确的验收标准
-- [ ] 需求描述无歧义（不同人读到的理解一致）
-- [ ] 技术可行性已初步评估
-- [ ] 边界清晰（明确列出做什么、不做什么）
-- [ ] 非功能需求已覆盖
-- [ ] 依赖和约束已识别
-- [ ] 未偏离原始需求的核心诉求
-- [ ] 关键假设清单已填写且分类（已确认/待确认）
-- [ ] 待确认假设不超过3个
-
-建议满足：
-- [ ] 有用户场景描述
-- [ ] 优先级已排定
-- [ ] 与现有功能的关联已标注
-- [ ] 效果指标和基线已定义
-
-每条标准必须是可客观判断的。
-
-## 评审步骤
-1. 对照原始需求，检查结构化文档是否覆盖了原始诉求（没有遗漏、没有偏题）
-   - 证据获取：逐条将功能需求回溯到原始需求中的表述
-2. 逐条检查功能需求的验收标准是否可验证
-   - 证据获取：尝试用验收标准判断一个假设的实现"是否通过"
-3. 检查是否有歧义表述（找出可能被不同理解的描述）
-   - 证据获取：列出可能的不同解读
-4. 检查非功能需求是否完整（参考checklist）
-5. 检查边界是否清晰（"不做"列表是否充分）
-6. 检查关键假设清单的完整性和分类准确性
-7. 逐项输出判定结果，**每项附具体证据**
-
-## 输出格式
-
-```
-## 审查结论：通过 / 不通过
-
-### 逐项判定
-| 检查项 | 结论 | 证据 | 备注 |
-|--------|------|------|------|
-| 验收标准完整 | ✅/❌ | {具体引用} | {修复建议} |
-| 无歧义 | ✅/❌ | {歧义实例} | {建议措辞} |
-| ... | ... | ... | ... |
-
-### 必须修复（blocking）
-- ...
-
-### 建议改进（non-blocking）
-- ...
-
-### 关键假设验证
-- 假设X：合理/存疑（证据：...）
-```
-
-## 反模式清单（DP7）
-1. **橡皮图章**：无证据通过。检测：每条"通过"必须附具体证据引用
-2. **吹毛求疵**：纠结措辞等非关键问题。检测：措辞问题归为non-blocking
-3. **脱离上下文**：不参照原始需求审查。检测：审查步骤必须先对照原始需求
-4. **假设验证遗漏**：不检查关键假设清单。检测：输出必须包含假设验证section
-5. **范围蔓延建议**：审查中建议增加功能。检测：审查只判断现有内容质量，不扩展范围
-
-## 适用场景与边界
-- 适用：需求文档完成后，进入设计阶段前
-- 不适用：原始需求还没有被结构化（先用requirement-analyzer）
-- 对应做类skill：requirement-analyzer
-
-## 示例
-（待从实践中积累第一个完整示例）

package/knowledge/03-guides/10-review-design.md

@@ -1,83 +0,0 @@
----
-name: design-reviewer
-description: 当技术方案文档完成、需要评审其合理性和完整性以决定是否可进入编码阶段时触发
-type: review
----
-
-## 定位
-设计阶段的"审"类skill。独立审查技术方案质量，作为进入编码阶段的Layer 2质量关卡。
-
-> **做审分离（DP2）**：必须由独立于design-planner的AI实例执行。
-
-## 输入
-- 必须输入：技术方案文档（design-planner的输出）、结构化需求文档（对照覆盖度）
-- 可选输入：methodology/checklists/design.md（检查标准）、需求阶段关键假设清单
-
-## 评判标准
-必须满足：
-- [ ] 方案覆盖需求文档中的所有功能点
-- [ ] 关键技术决策有明确理由（不是拍脑袋）
-- [ ] 接口/API定义清晰，模块间可独立开发
-- [ ] 数据模型设计合理
-- [ ] 复杂度与需求匹配，不过度设计
-- [ ] 安全性已考虑
-- [ ] 关键假设清单完整，需求阶段假设已校验
-- [ ] 待确认假设不超过3个
-
-建议满足：
-- [ ] 可扩展性已考虑
-- [ ] 性能预估和瓶颈分析
-- [ ] 技术风险已识别并有降级方案
-- [ ] 对比了备选方案
-
-## 评审步骤
-1. 对照需求文档，逐条检查方案是否覆盖（无遗漏）
-   - 证据获取：建立需求→设计的映射表
-2. 审查架构设计的合理性（分层清晰、职责单一、耦合度低）
-   - 证据获取：指出具体的耦合点或职责混淆
-3. 审查接口设计（输入输出明确、错误处理完善、命名规范）
-4. 审查数据模型（实体关系合理、索引策略得当、存储选型匹配）
-5. 审查技术选型的理由（是否充分、是否有更优选择）
-6. 检查是否过度设计（每个设计决策能否回溯到具体需求）
-   - 证据获取：无法回溯到需求的设计元素列表
-7. 检查安全性考虑（认证、授权、数据保护）
-8. **校验关键假设跨阶段一致性**（需求→设计是否漂移）
-9. 逐项输出判定结果，**每项附具体证据**
-
-## 输出格式
-
-```
-## 审查结论：通过 / 不通过
-
-### 逐项判定
-| 检查项 | 结论 | 证据 | 备注 |
-|--------|------|------|------|
-| 需求覆盖度 | ✅/❌ | {需求→设计映射} | {遗漏项} |
-| 架构合理性 | ✅/❌ | {具体分析} | {修复建议} |
-| ... | ... | ... | ... |
-
-### 必须修复（blocking）
-- ...
-
-### 建议改进（non-blocking）
-- ...
-
-### 关键假设验证
-- 需求假设X：在设计中已体现/存在漂移（证据：...）
-- 设计新假设Y：合理/存疑（证据：...）
-```
-
-## 反模式清单（DP7）
-1. **橡皮图章**：无证据通过。检测：每条"通过"必须附具体证据
-2. **吹毛求疵**：纠结技术选型的微小差异。检测：技术选型偏好不可blocking
-3. **脱离上下文**：不参照需求审查方案。检测：审查步骤第一步必须对照需求
-4. **假设漂移忽视**：不校验跨阶段假设一致性。检测：输出必须包含假设验证section
-5. **反向过度设计**：审查中建议增加方案复杂度。检测：建议改进不可增加已排除的需求
-
-## 适用场景与边界
-- 适用：技术方案完成后，进入编码阶段前
-- 不适用：方案还在草稿阶段（先完成方案再评审）
-- 对应做类skill：design-planner
-
-## 示例
-（待从实践中积累第一个完整示例）

package/knowledge/03-guides/11-review-code.md

@@ -1,111 +0,0 @@
----
-name: code-reviewer
-description: 当代码自测通过Layer 1确定性验证后、需要独立审查代码质量和安全性以决定是否可合并时触发
-type: review
----
-
-## 定位
-审查阶段的核心"审"类skill。独立审查代码质量，作为进入QA测试阶段的Layer 2质量关卡。
-
-> **做审分离（DP2）**：必须由独立于code-implementer的AI实例执行。
-
-## 输入
-- 必须输入：自测通过的代码（Layer 1已通过）、技术方案文档、自测报告
-- 可选输入：methodology/checklists/code.md（检查标准）、关键假设清单（累积至今）
-
-## 评判标准
-必须满足：
-- [ ] 代码实现与技术方案一致，未偏离设计
-- [ ] 单元测试覆盖核心逻辑路径
-- [ ] 所有测试运行通过
-- [ ] 无安全漏洞（SQL注入、XSS、CSRF、越权访问、敏感信息泄露）
-- [ ] 无硬编码的密钥、密码、配置项
-- [ ] 错误处理合理
-- [ ] 关键假设在代码中正确体现
-
-建议满足：
-- [ ] 测试覆盖边界条件和异常路径
-- [ ] 代码可读性良好
-- [ ] 无重复代码
-- [ ] 资源管理正确
-- [ ] 日志记录合理
-
-## 评审步骤
-0. **差异对比**（如为更新任务）
-   - 获取旧版本代码
-   - 获取新版本代码
-   - 对比差异维度：新增、修改、删除
-   - 输出结构化差异报告
-1. 对照技术方案，检查代码实现是否一致（架构、接口、数据模型）
-   - 证据获取：逐个接口对照方案定义
-2. 审查代码质量
-   a. 可读性：命名清晰、逻辑直观
-   b. 可维护性：模块化合理、不过度耦合
-   c. 代码规范：符合项目约定
-3. 审查安全性
-   a. 输入校验：是否对用户输入做了验证
-   b. 注入防护：SQL、命令注入、XSS
-   c. 认证授权：权限检查是否完善
-   d. 敏感信息：是否有硬编码密钥或泄露风险
-   e. 金额处理：是否使用专用金额类型（禁止浮点数）
-4. 审查工程规范
-   a. 接口变更是否向后兼容（出入参只增不减）
-   b. 幂等性：服务方是否严格区分成功/失败/重复/未知
-   c. 并发控制：是否遵循"一锁二判三处理"
-   d. 异常处理：是否明确区分业务异常/系统异常，禁止吞异常
-   e. 线程上下文变量设置与清除是否配对（finally中清理）
-5. 审查性能
-   a. 是否有明显的性能问题（N+1查询、无限循环风险等）
-   b. 资源管理（连接、文件句柄是否正确释放）
-   c. SQL语句是否带where条件，是否走索引，禁止select *
-6. 审查测试充分性
-   a. 核心逻辑路径是否覆盖
-   b. 边界条件和异常路径覆盖情况
-7. **校验关键假设跨阶段一致性**（需求→设计→实现）
-8. 区分blocking和non-blocking问题
-9. 逐项输出判定结果，**每项附具体证据（代码位置+问题描述）**
-
-## 输出格式
-
-```
-## 审查结论：通过 / 不通过
-
-### 逐项判定
-| 检查项 | 结论 | 证据 | 备注 |
-|--------|------|------|------|
-| 方案一致性 | ✅/❌ | {接口对照结果} | {偏离详情} |
-| 安全性 | ✅/❌ | {具体代码位置} | {修复建议} |
-| ... | ... | ... | ... |
-
-### 必须修复（blocking）
-- [{文件}:{行号}] {问题描述} → {修复建议}
-
-### 建议改进（non-blocking）
-- [{文件}:{行号}] {问题描述} → {改进方向}
-
-### 关键假设验证
-- 设计假设X：在代码中正确体现/存在偏差（证据：{代码位置}）
-
-### 严重问题判定
-如发现以下任一情况，标记为严重问题并进入问题归因阶段：
-- 核心指标缺失或重复
-- 违反业务规则的强规则
-- 数据量波动超过阈值
-- 计算逻辑错误
-- 影响下游业务使用
-```
-
-## 反模式清单（DP7）
-1. **橡皮图章**：审查走过场。检测：每条"通过"必须附具体代码位置作为证据
-2. **吹毛求疵**：纠结代码风格等非关键问题。检测：风格问题不可blocking
-3. **缺乏上下文**：不了解需求和设计就审代码。检测：审查步骤第一步必须对照方案
-4. **假设漂移忽视**：不校验跨阶段假设一致性。检测：输出必须包含假设验证section
-5. **自我确认偏差**：做和审是同一个AI实例。检测：command-runner确保实例隔离
-
-## 适用场景与边界
-- 适用：编码完成并自测通过Layer 1后，进入QA测试前
-- 不适用：代码还在编写中（先完成编码和自测）
-- 对应做类skill：code-implementer
-
-## 示例
-（待从实践中积累第一个完整示例）

package/knowledge/03-guides/12-review-testing.md

@@ -1,76 +0,0 @@
----
-name: test-reviewer
-description: 当测试用例或测试报告完成、需要评审测试策略合理性和覆盖充分性时触发
-type: review
----
-
-## 定位
-测试相关的"审"类skill。审查测试策略和覆盖度是否充分，确保不是"测了很多但关键的没测到"。用于研发自测评审和QA测试方案评审。
-
-> **做审分离（DP2）**：必须由独立于test-generator的AI实例执行。
-
-## 输入
-- 必须输入：测试用例列表或测试方案、测试执行结果/报告、结构化需求文档
-- 可选输入：技术方案文档、关键假设清单（累积至今）
-
-## 评判标准
-必须满足：
-- [ ] 需求文档中所有验收标准有对应的测试用例
-- [ ] 核心逻辑路径有测试覆盖
-- [ ] 所有测试执行结果为通过
-- [ ] 无严重级别的遗漏（Critical功能未测试）
-- [ ] 关键假设有对应的验证测试
-
-建议满足：
-- [ ] 边界条件有测试覆盖
-- [ ] 异常路径有测试覆盖
-- [ ] 测试用例描述清晰（步骤、预期结果明确）
-- [ ] 测试数据合理（不是全用默认值）
-
-## 评审步骤
-1. 对照需求文档验收标准，逐条检查是否有对应测试用例
-   - 证据获取：建立验收标准→测试用例的映射表
-2. 识别核心逻辑路径，检查是否覆盖
-   - 证据获取：列出核心路径及其对应测试
-3. 识别关键边界条件，检查是否覆盖
-4. 识别主要异常路径，检查是否覆盖
-5. 检查测试用例的质量（步骤是否可复现、预期结果是否明确）
-6. 检查测试执行结果
-7. **检查关键假设是否有对应验证测试**
-8. 逐项输出判定结果，**每项附具体证据**
-
-## 输出格式
-
-```
-## 审查结论：通过 / 不通过
-
-### 逐项判定
-| 检查项 | 结论 | 证据 | 备注 |
-|--------|------|------|------|
-| 验收标准覆盖 | ✅/❌ | {映射表} | {遗漏项} |
-| 核心路径覆盖 | ✅/❌ | {路径列表} | {未覆盖路径} |
-| ... | ... | ... | ... |
-
-### 覆盖缺口
-- {未被测试覆盖的需求点/场景}
-
-### 修复建议
-- {需要补充的测试用例方向}
-
-### 关键假设验证
-- 假设X：有对应测试/无对应测试（建议：...）
-```
-
-## 反模式清单（DP7）
-1. **橡皮图章**：不逐条对照就通过。检测：必须建立验收标准→测试用例映射
-2. **只看覆盖率数字**：覆盖率高但关键路径没测。检测：核心路径覆盖是独立检查项
-3. **忽略测试质量**：测试用例存在但不可复现。检测：抽检测试步骤的可执行性
-4. **假设验证遗漏**：不检查关键假设的测试覆盖。检测：输出必须包含假设验证section
-
-## 适用场景与边界
-- 适用：测试用例生成后的质量审查、测试报告的充分性评估
-- 不适用：测试方案的整体设计（那是quality角色的test-planner）
-- 对应做类skill：test-generator
-
-## 示例
-（待从实践中积累第一个完整示例）

package/knowledge/03-guides/13-audit-security.md

@@ -1,89 +0,0 @@
----
-name: security-reviewer
-description: 当代码包含Skill/Agent相关实现时，审查Skill内容的安全性，防止提示词注入和恶意指令
-type: review
----
-
-## 定位
-
-安全审查阶段的"审"类skill。专门审查Skill/Agent相关代码，检测提示词注入、输入校验缺失等安全风险。
-
-> **适用场景**：代码中包含Skill定义、Agent提示词、动态指令构建等场景时必须触发。
-
-## 输入
-
-- 必须输入：包含Skill/Agent实现的代码文件
-- 可选输入：Skill定义文件（*.md）、提示词模板
-
-## 评判标准
-
-必须满足：
-
-- [ ] Skill内容无直接用户输入拼接（防止注入）
-- [ ] 输入参数有长度/类型校验
-- [ ] 敏感操作有权限检查
-- [ ] 无硬编码的API密钥或凭证
-- [ ] 动态指令构建有过滤机制
-
-建议满足：
-
-- [ ] 提示词模板与动态内容分离
-- [ ] 有审计日志记录Skill激活
-- [ ] 有速率限制防止滥用
-
-## 审查步骤
-
-1. **识别Skill相关代码**
-   - 搜索 `skill`、`agent`、`prompt`、`instruction` 关键词
-   - 定位Skill定义文件和加载逻辑
-
-2. **审查提示词注入风险**
-   - 检查Skill内容是否直接拼接用户输入
-   - 检查是否有内容过滤/转义机制
-   - 证据获取：列出所有动态注入点
-
-3. **审查输入校验**
-   - 检查参数是否有长度限制
-   - 检查是否有类型校验
-   - 检查是否有敏感词过滤
-
-4. **审查权限控制**
-   - 检查Skill激活是否有权限校验
-   - 检查敏感操作是否有访问控制
-
-5. **审查凭证管理**
-   - 检查是否有硬编码密钥
-   - 检查凭证是否通过安全方式获取
-
-## 输出格式
-
-```
-## 审查结论：通过 / 不通过
-
-### 逐项判定
-| 检查项 | 结论 | 证据 | 备注 |
-|--------|------|------|------|
-| 提示词注入防护 | ✅/❌ | {注入点列表} | {修复建议} |
-| 输入校验 | ✅/❌ | {校验逻辑} | {缺失项} |
-| 权限控制 | ✅/❌ | {权限检查} | {缺失项} |
-| 凭证管理 | ✅/❌ | {凭证处理} | {问题} |
-
-### 必须修复（blocking）
-- ...
-
-### 建议改进（non-blocking）
-- ...
-```
-
-## 反模式清单
-
-1. **直接拼接**：用户输入直接拼接到提示词中
-2. **无校验**：参数传入后不做任何校验
-3. **硬编码密钥**：API密钥直接写在代码中
-4. **无审计**：敏感操作无日志记录
-
-## 适用场景
-
-- 适用：代码中包含Skill/Agent实现、需要审查提示词安全性
-- 不适用：普通业务代码（使用code-reviewer即可）
-- 对应做类skill：code-implementer（需在实现时遵循安全规范）