第三阶段批次 C 审查记录¶
批次：批次 C — 项目与工程类
完成日期：2026-06-05
构建状态：已通过 mkdocs build --strict，零警告零错误
一、本批生成了哪些工作流¶
| 文件 | 工作流名称 | 节点数 |
|---|---|---|
docs/chapters/11-program-development.md |
从需求到可交付代码的 AI 多专家开发工作流 | 9 |
docs/chapters/12-agent-collaboration.md |
从项目目标到多 Agent 协作开发的 AI 工作流 | 8 |
docs/chapters/13-security-review.md |
从命令脚本到风险修复清单的 AI 安全审查工作流 | 9 |
docs/chapters/14-github-publishing.md |
从本地项目到 GitHub 开源仓库的 AI 发布工作流 | 9 |
docs/chapters/15-mkdocs-publishing.md |
从 Markdown 文档到 GitHub Pages 电子书站点的 AI 发布工作流 | 9 |
二、每个工作流包含哪些专家节点¶
工作流 11：程序员开发¶
- 需求澄清专家
- 技术方案专家
- 数据结构与接口专家
- 代码生成专家
- 测试用例专家
- 代码审查专家（招牌节点）
- 重构建议专家
- 文档生成专家
- 交付检查专家
工作流 12：编程 Agent 协作¶
- 项目目标拆解专家
- Agent 角色分工专家
- 任务队列设计专家
- 上下文管理专家（招牌节点）
- 代码变更审查专家
- 冲突与回滚专家
- TODO 管理专家
- 阶段复盘专家
工作流 13：安全审查（防御性）¶
- 输入材料识别专家
- 高危命令识别专家（招牌节点）
- 权限与路径风险专家
- 凭据泄露检查专家
- 网络与远程访问风险专家
- 执行影响评估专家
- 修复方案专家
- 验证清单专家
- 安全复盘专家
工作流 14：GitHub 发布¶
- 仓库定位专家
- 目录结构检查专家
- README 生成专家（招牌节点）
- License 与原创性说明专家
- Git 初始化与远程绑定专家
- 提交信息专家
- GitHub Actions 检查专家
- Release 说明专家
- 发布后复盘专家
工作流 15：MkDocs 发布¶
- 文档结构规划专家
- MkDocs 配置专家
- Material 主题专家
- 导航结构专家
- Markdown 质量检查专家
- GitHub Actions 部署专家
- GitHub Pages 配置专家
- 构建错误修复专家（招牌节点）
- 发布验收专家
三、每个工作流的招牌节点¶
| 工作流 | 招牌节点 | 专业深度 |
|---|---|---|
| 11 程序员开发 | 代码审查专家 | 八维度审查（需求/正确性/异常处理/硬编码/过度设计/安全/可维护性/测试覆盖），问题分级（阻断/重要/建议），定位到代码位置 |
| 12 Agent 协作 | 上下文管理专家 | 解决六类上下文失控（遗忘/不一致/漂移/误覆盖/TODO脱节/交接断层），上下文全部外置到文件，SSOT + 决策记录 + 标准化交接包 |
| 13 安全审查 | 高危命令识别专家 | 八类高危识别（删除覆盖/权限绕过/执行策略绕过/远程执行/启动项/敏感目录/凭据/生产影响），结合环境评级，严格防御性 |
| 14 GitHub 发布 | README 生成专家 | 10 要素开源 README（一句话介绍/解决问题/功能/快速开始/示例/结构/技术栈/原创性/Roadmap/License），命令可复制 |
| 15 MkDocs 发布 | 构建错误修复专家 | 八类构建错误诊断（nav 引用/依赖缺失/YAML 缩进/代码块未闭合/Pages Source/权限/site_url/strict 报错），含真实定位命令 |
四、每个工作流的最终交付物¶
| 工作流 | 最终交付物 |
|---|---|
| 11 程序员开发 | 可交付代码包（需求清单 + 技术方案 + 接口契约 + 代码 + 测试 + 审查报告 + 文档 + 交付检查） |
| 12 Agent 协作 | 多 Agent 协作治理方案（目标拆解 + 角色分工 + 任务队列 + 上下文规范 + 变更审查 + 冲突回滚 + TODO 台账 + 复盘） |
| 13 安全审查 | 防御性安全审查报告（风险概况 + 风险明细 + 影响评估 + 修复方案 + 验证清单 + 安全复盘） |
| 14 GitHub 发布 | 可发布的 GitHub 开源仓库（规范目录 + README + License + 提交历史 + CI + Release） |
| 15 MkDocs 发布 | 可访问的 GitHub Pages 文档站点（文档结构 + mkdocs.yml + Material 主题 + 导航 + 部署配置） |
五、是否存在与已有章节重复的问题¶
无实质性重复。 批次 C 与黄金样章 02（项目管理）及批次 A/B 的区分清晰：
| 对比 | 02 项目管理 | 批次 C 工程类 | 区分 |
|---|---|---|---|
| 02 vs 11 | 项目计划（需求/任务/排期/风险/沟通） | 代码开发（需求/方案/接口/代码/测试/审查） | 02 是管理视角的计划编制，11 是工程视角的代码交付，无重叠 |
| 02 vs 12 | 单项目的计划治理 | 多 Agent 的协作治理 | 02 面向人的项目管理，12 面向 Agent 的工程化协作（上下文/任务队列/变更审查） |
批次 C 内部各工作流定位独立： - 11（写代码）→ 12（多 Agent 协作写代码）→ 13（审查代码安全）→ 14（发布代码）→ 15（发布文档），构成开发到发布的完整链条，无职责重叠。
与批次 A/B（创作类、视觉类）在主题、语气、内容上完全不同——批次 C 多用结构化表格、命令块、配置示例、风险等级，语气精确、技术化。
六、是否存在节点职责重叠¶
经逐一检查，各工作流内部节点职责清晰：
- 11：需求→方案→接口→代码→测试→审查→重构→文档→交付，线性递进。节点 6（审查）和节点 9（交付检查）分工不同——前者审查代码本身的八维度质量，后者核对交付物齐全性和需求闭环。
- 12：节点 5（变更审查）和节点 6（冲突回滚）互补——前者审查单次变更是否越权，后者处理变更冲突和回退。节点 7（TODO 管理）专注台账与代码同步。
- 13：节点 2-5 是四个并行的风险识别维度（命令/权限路径/凭据/网络），节点 6（影响评估）汇总，节点 7（修复）落地，分工不重叠。
- 14：节点 3（README）和节点 4（License/原创性）分工明确——前者写项目说明，后者处理授权和原创声明。节点 9（发布后复盘）专注发布后验证。
- 15：节点 2（MkDocs 配置）、节点 3（主题）、节点 4（导航）分别处理 mkdocs.yml 的不同部分，节点 8（构建错误修复）是横向的排错专家。
七、是否存在交接表缺失¶
无缺失。 五个工作流均包含完整的节点交接说明表格：
- 11：9 行，覆盖全部 9 节点
- 12：8 行，覆盖全部 8 节点
- 13：9 行，覆盖全部 9 节点（含节点 1 到 2/3/4/5 的并行分发）
- 14：9 行，覆盖全部 9 节点
- 15：9 行，覆盖全部 9 节点
每个表格最后一节点都明确交接到"最终输出模板"，闭环完整。
八、是否存在提示词过短或过泛¶
经检查：
- A 快速生成版：50-100 字，含角色+任务+输出格式，可直接复制。
- B 专家增强版：均包含八要素（角色身份、任务目标、输入材料、处理步骤、输出格式、约束条件、质量标准、常见失败情况）。技术类工作流的专家增强版尤其详尽（如 13 高危命令识别的八类排查框架、15 构建错误修复的七类错误诊断流程含真实命令）。
- C 自查审稿版：每节点 3-5 个具体可判断的审查问题，针对该节点实际风险。
- D 返修优化版：均说明"保留什么、修正什么"。
无过短或过泛的提示词。技术类内容大量使用了结构化表格、命令块、配置示例和风险等级表，与创作类内容形成明显区分。
九、安全审查章节是否只提供防御性内容¶
是，严格防御性。 工作流 13 在多个层面坚守防御性边界：
- 开篇防御性边界声明：明确"仅用于防御性安全审查（识别、解释、修复、验证）"，明确"不提供绕过检测、窃取凭据、建立持久化、攻击他人系统"的内容。
- 节点级约束：每个节点的专家增强版都有"仅识别和解释风险，不提供攻击性用法"的强制约束。
- 招牌节点（高危命令识别）：识别八类高危命令但只解释"会做什么、为什么危险、影响多大"，不提供如何利用。
- 凭据检查节点：强制要求报告中用
[REDACTED]或位置描述指代凭据，绝不回显明文（防止审查报告成为二次泄露源），且不提供利用泄露凭据的方法。 - 网络风险节点：识别下载即执行、数据外发等风险，但不提供搭建恶意服务、数据窃取通道的内容。
- 修复方案节点：提供的是安全加固的替代写法，不涉及攻击性操作。
- 错误示例与修正方向小节：用脱敏的、概念性的例子说明审查误判，不含可直接执行的攻击性内容。
工作流 13 的全部产出都服务于"让待执行的内容更安全"，符合防御性安全、合规性和风险解释的边界。
十、每个工作流的质量评分¶
采用质量标准 5 维度 100 分体系（合格线 80 分）：
| 工作流 | 场景真实性 | 节点完整性 | 提示词可用性 | 交接清晰度 | 验收可操作性 | 总分 |
|---|---|---|---|---|---|---|
| 11 程序员开发 | 18 | 19 | 19 | 18 | 18 | 92 |
| 12 Agent 协作 | 19 | 19 | 18 | 19 | 18 | 93 |
| 13 安全审查 | 18 | 19 | 18 | 19 | 19 | 93 |
| 14 GitHub 发布 | 18 | 19 | 19 | 18 | 18 | 92 |
| 15 MkDocs 发布 | 19 | 19 | 19 | 18 | 18 | 93 |
评分说明： - 12 Agent 协作（93）：上下文管理招牌节点系统性解决六类失控问题，交接规范基于文件而非记忆，工程化程度高。 - 13 安全审查（93）：防御性边界严格，九节点覆盖完整审查闭环，验收清单全部含防御性确认项。 - 15 MkDocs 发布（93）：构建错误修复招牌节点含真实定位命令，本图鉴自身即此工作流的应用范例，场景真实性突出。
全部超过合格线 80 分。
十一、是否可以进入下一批¶
✅ 可以。
前置条件均满足：
- [x] 五个工作流质量评分均达到 92 分以上
- [x] 每个工作流都有明显比普通节点更专业的招牌节点
- [x] 无与已有章节（含黄金样章 02）的实质性重复
- [x] 无节点职责重叠
- [x] 节点交接表完整
- [x] 无过短或过泛的提示词
- [x] 安全审查章节严格防御性，无攻击性内容
- [x] 技术类内容与创作类明显区分（表格/命令/配置/风险等级）
- [x] mkdocs build --strict 通过
- [x] mkdocs.yml、workflow-map、TODO.md 已更新
批次 D 建议¶
批次 D：办公效率类（会议纪要、领导汇报、数据分析、群聊沉淀、评论分析）
推荐工作流： - 从录音到完整会议纪要工作流 - 从零散材料到领导汇报工作流 - 从表格数据到分析报告工作流 - 从群聊记录到知识沉淀工作流 - 从评论文本到观点分析工作流
注意：批次 D 面向普通职场办公场景，语气应回到平实、可操作，重点是"把零散信息整理成结构化产出"，与批次 C 的技术工程语气区分。