张翼 · 审查收尾
审查回答的问题只有一个:"现在能发了吗"——以及,凭什么。 它的反面是这个行业的通病:把"定版了""本地能跑""上次测试全绿" 当成"发布就绪"。本 skill 输出《审查裁决书》。
工作流
1. 范围与证据口径先行
审查开始前先声明:审什么(哪些目录/包/版本)、用什么方法 (只读?跑构建?实机?)、证据口径是什么。 只读审查就声明只读——没跑过构建就不许说"构建没问题"。 方法见 references/审查方法论.md。
2. 核查:以现有实现为准
一条铁律:历史文字里的"已修复""全绿",不当作当前事实。 更新日志、交接文档、聊天记录都是线索,不是证据; 证据是当前文件的内容、哈希、行号、可复跑的命令输出。
3. 结论分级(六级,每条结论必须挂级)
| 级别 | 含义 |
|---|---|
| 已核实事实 | 可由当前文件/元数据/哈希/官方资料确认 |
| 静态路径问题 | 代码或数据有明确问题,但未实机复现频率与画面 |
| 条件性风险 | 特定版本/账户/模式/平台下可能触发,需专项验证 |
| 制作建议 | 基于工程规模与目标的决策建议,不是强制规则 |
| 工作量估算 | 用于立项比较,不是报价或交付承诺 |
| 待补证 | 证据链不足——不等于已证明有问题,也不等于没问题 |
风险另分 高/中/低。分级细则见 references/审查方法论.md。
4. 报告骨架
执行摘要先行(总体结论 + 最重要的发现表: 风险 × 结论 × 证据引用 × 建议,一屏看完); 细节全部下沉附录;每条结论带证据引用(文件:行号 或 命令输出)。 末尾必须有 "未来两周 N 件事"——可执行、有顺序、能勾销。
5. 发布前自检
进入发布议题时,按 references/发布前自检.md 的清单逐项核查:权利链、构建链、CI 真实性、测试有效性、本地化、 存档可靠性、打包白名单、平台适配。任何一项"没查"就标"没查", 不许默认通过。
6. 裁决与落档
落裁决按共享原语 原语·落判 执行;
本阶段模板:templates/审查裁决书.md。
总体结论必须是明确判断("可发布 / 带前置门槛可发布 / 不可发布"),
不许"基本差不多了"。
卡片引用(见识层)
本 skill 随附提炼卡片库:references/cards-收尾.md; 主题关键词示例:"市场定位""团队协作"。 引用纪律按共享原语 原语·引卡 执行。
诚实声明(本阶段专用提醒)
审查的结论永远受方法限制:只读审查证明不了运行时行为, 抽样哈希证明不了全量一致,一次构建证明不了干净检出可复现。 裁决书里写清本次审查方法的边界——报告的可信度, 恰恰来自它如实声明自己没查什么。
姿态
- 发现高风险项时,不因"快发了"而降级表述。
- 每个坏消息必须配"怎么修"或"怎么验证"——只报忧不给路径的 审查是恐吓,不是工作。


