# [MGMT-STD-004] 曼孚 vibecoding 交付方法论：流程铁律与全程 SOP

| 项 | 值 |
| --- | --- |
| 文档类型 | 工程治理标准 / 交付方法论（STD） |
| 适用范围 | 承接「曼孚科技云电脑交付任务」的指挥 / 陪练工作流；任何驱动 AI（Claude / Codex / Trae / Kiro）接手时**必须**先读本文件 |
| 强制级别 | 铁律（违反红线即判交付不合规，必须整改） |
| 触发关键词 | 曼孚 / Mindflow / vibecoding / 交付任务 / 接题 / 领题 |
| 上位 / 参考 | [MGMT-STD-001]（文档结构铁律）；活源真相 = `~/Desktop/delivery-project-manager`（见第 9 章） |
| 状态 | 定稿 |

---

## 0. 用途与用法

本文件把「曼孚交付陪练」的全部方法论压成一套**可执行铁律**，供 Khy 及任何驱动 AI 承接此类工作时遵循。
用户**自己说话用中文**时**必须**用中文带；用户**亲自用英文写指令**时才用英文。**严禁**因为用户粘贴的素材（英文题目 / 英文报告 / 英文报错）是英文，就误判成「用户在用英文交流」——那是**待处理的任务素材**，默认仍用中文。

用词纪律（沿用 [MGMT-STD-001]）：红线条目只用「必须 / 严禁 / 强制」，**严禁**用「建议 / 最好 / 尽量」。

> **一句话定位**：这是一套**指挥 / 陪练**工作流，帮一位**英语接近零基础**的交付者在曼孚云电脑上接交付任务——挑题、出**全中文**分步指导、把作业 AI 的英文产物解读成中文、和他一起**打磨喂给作业 Claude 的英文提示词**。**陪练工具本身不是交付物**；陪练侧产生的任何中文文件**严禁**进入交付包。

---

## 1. 心智模型（先建立认知，再谈流程）

1. **陪练侧 ≠ 交付侧**。驱动 AI（陪练）产出中文指导、进度、提示词草稿；作业 AI（**永远是 Claude Code**）在隔离工作区里产出交付物。两侧物理分离。
2. **作业端永远是 Claude Code**：曼孚红线只认 Claude Code 轨迹格式。驱动陪练工具的可以是任意 AI，但写交付代码的必须是 Claude Code。
3. **双层输出格式**：凡要发给作业 Claude / codex 的内容，**必须**用「**中文说明（用户看）+ 可直接复制的英文代码块（用户粘贴去发）**」两层。用户看不懂的任何英文，让他复制回来，翻成中文再告诉他怎么回。
4. **直接贴英文 prompt = 一道新任务开始**：用户直接贴一段英文题目时，**当作新交付任务**，**严禁**再问「要不要接 / 值不值得」。工作目录默认固定为曼孚云电脑上的开发区；骨架不在就由**驱动侧**脚本建好（**严禁**让作业 Claude 建结构）。

---

## 2. 八大交付红线（触碰任一即可能判不合格）

1. **全程英文**：交互、代码、注释、文档、提交信息全英文；**交付物里出现任何中文即 FAIL**（质检会扫中文）。
2. **禁子代理 / agent 团队**：开发轨迹一旦扫到子代理（`Task` / `Agent` / `agent-*.jsonl` / sidechain）**直接出局**。
3. **Dockerfile 必须纯净 = Claude 原始产物**：**严禁**事后给它加任何国内镜像源（pip / npm / apt / Docker Hub 镜像皆不行），**严禁**给 Claude 加底层提示 / 系统提示强制它用国内源。我给 Claude 的任何提示词**严禁**含「use a China/domestic mirror」之类指令。哪怕云电脑拉取慢，也不动 Dockerfile。
   - **本地加速例外**（仅限本地构建 / 测试）：驱动侧可临时给 `repo/Dockerfile` 加镜像源，但**必须**先备份原文件；一旦要让作业 Claude 改文件 **或** 正式提交，**必须**先还原并 `diff` 验证无差异。
4. **目录隔离 + cwd 硬锁**：作业 Claude 的工作目录**必须**硬锁在 `<TASK-ID>/repo/`（在 `repo/` 内启动 `claude`）；**严禁** `/add-dir`，**严禁**批准 `repo/` 树外的访问弹窗。
5. **结构由驱动侧预建**：交付包一级目录 + `metadata.json`**必须**由驱动侧（脚手架脚本）在**开发前**建好；**严禁**让作业 Claude `mkdir docs/ repo/` 或写 `metadata.json`（这类打包动作落进轨迹 = 污染）。作业 Claude **只往 `repo/` 内写**。
6. **codex 只质检不改码**：codex 做纯静态审查，**严禁**让它改代码。
7. **最多 3 次提交**：第 3 次被打回即失败。最后一次提交前**必须**完整终检。
8. **驱动侧脚本 / 凭据严禁进交付包**：脚手架、质检脚本、令牌、带 token 的 URL 一律不进 `TASK-xxx/`。

---

## 3. 全程 SOP（12 步）

> 接手一道题：先读该题进度文件（`进度日志.md` + `status.json`）续上，干完一步**必须**写回。

1. **领题 / 进开发区**：进固定开发区，确认 `<TASK-ID>/` 在不在；不在就用驱动侧脚手架建一级骨架 + `metadata.json`。
2. **判题型（5 选 1）**：`fullstack` / `pure_frontend` / `pure_backend` / `mobile_app` / `cross_platform_app`（内部定价分类）→ 写 `metadata.json` 时**归一到官方枚举** `fullstack / web / server / android / android`。据此当场告诉用户：单价、是否上前端 / 全栈美观提示词套装（纯后端不上）、是否要 `docs/api-spec.md`（有后端才要）、主要风险点。
3. **建骨架 + metadata**：驱动侧脚手架幂等建 `docs/ repo/ original_sessions/ skills/` + 写官方 8 字段 `metadata.json` + `.gitignore`；同时把陪练侧 `tasks/<TASK-ID>/` 标配文件集建齐（见第 5.3）。
4. **首条消息 = 干净原题 + 开 plan mode**：第一步让用户把**英文原题原样**复制给作业 Claude（在 `repo/` 下），**前后不加任何包装**（轨迹要审），并**开着计划模式**。
5. **计划模式审查闭环（核心）**：Claude 出第一版计划 → 让用户选「**否 / No**」不批准（留计划模式、先别写码）→ 驱动侧给一段英文「**硬性要求**」（曼孚验收维度压成英文：可运行不许擅自简化、完整工程结构、真实逻辑禁 mock、分层架构、双测试 `unit_tests/`+`API_tests/`+`run_tests.sh`、生产级错误 / 日志 / 校验、隐含业务闭环、美观度仅前端 / 全栈 / 移动）→ 让 Claude 按红线**重做计划、仍停计划模式** → Claude 回改后英文计划 → **用户整段复制回来，驱动侧翻成中文，两人共审** → 审过才让 Claude 退计划模式开工。**纯后端题删掉「美观度」那条再发。**
6. **澄清问答**：作业 Claude 的澄清问题，驱动侧翻成中文、和用户定答案、再给回精准英文。问答留在会话里（打包时进 `docs/questions.md`）。
7. **设计**：作业 Claude 在设计阶段把 `design.md` / `api-spec.md` 写进 **`repo/` 内**（打包时由驱动侧挪进任务根 `docs/`）。
8. **实现**：作业 Claude 在 `repo/` 内产出代码 + `README.md` + 双测试 + Docker。
9. **codex 质检闭环（核心迭代）**：跑质检脚本（纯后端加 `--skip-ui`）出 codex 报告 → 驱动侧写**给 codex 的元提示词**，让 codex 把 issues 译中文给用户看 + 整理成一段**给作业 Claude 的英文修复提示词**，并由 codex **定义验收标准**（怎样算全部修复）→ 用户复制回来，驱动侧翻译 + 把关（不含镜像源指令、无子代理）→ 交作业 Claude 修 → **再跑一遍**：codex 认为没问题就提交，还有问题回到本步迭代。
10. **打包**：驱动侧把 `repo/` 内的 `design.md` / `api-spec.md` 挪进任务根 `docs/`（普通终端做、不进开发轨迹）；校验交付包结构；`README.md` **必须**在 `repo/`。
11. **轨迹清洗**：用清洗脚本把开发会话原始 projectID 目录打成压缩包进 `original_sessions/`，**包名 = projectID**；脚本会检测 `agent-*.jsonl`（有子代理 = 红线 2 出局）。轨迹**只读审计**；如需修复**默认只口述、用户手改**，改前整目录备份，**只替换不删行、行数不变、无中文残留**。
12. **六维度提交**：填平台「六维度评分表」（见第 6 章），最后一次提交前完整终检。

---

## 4. 三大关键认知

1. **过检真正决定于提示词质量**：干跑闸门通过 + 轨迹合规**只是机械 / 形式门槛**（结构对、无中文、无污染、脚本能跑）。**能否真正过检取决于交付物实质质量，而它取决于开发中——除原始题目外——喂给 Claude 的英文提示词质量**（澄清 / 设计 / 实现 / 修复）。驱动侧最核心的价值就是**和用户一起打磨这些英文提示词**：把中文意图翻成精准、完整、贴合题目全部显性 + 隐性要求的英文。**严禁**把「干跑过了」当成「稳了」。
2. **轨迹污染权威 9 条**（开发 session 轨迹会被逐条审；判据是注入内容**是否无关**，不是「有没有注入」）：
   ① 工作路径干净（启动 workspace 下无无关文件）；② 文件访问不越界（不 `/add-dir`、不读无关目录）；③ 对话只围绕题（仅限题目理解 / 开发 / 修改 / 测试 / 排错）；④ 启动环境只注入**相关**上下文（语言锁 / 开发区规则 / 命令代理 / 相关英文 skill **保留**；别的项目记忆 / 闲聊记忆 / 无关 hook / 无关 MCP 才算污染）；⑤ skill 列表干净（纯英文、相关、不自动触发）；⑥ hook 不注入无关上下文；⑦ 多 session 用新接力、不 `/resume` 回带旧上下文、尽量不 `/compact`；⑧ dev session 不做与题无关的杂事；⑨ 发现即污染。
   - **权限模型**：Claude Code 权限是 `allow / ask / deny / workspace` 四规则组（组合用）。`workspace` 默认 = 启动路径（让它 = `repo/`，不加额外目录）。**Bash 只读漏洞**：`workspace` 只约束 Read/Glob/Grep/Edit，一组内置只读 Bash 命令（`cat/grep/find/head/tail/ls` 等）能读 `repo/` 外。对策：**确认 Workspace + 行为约束**（不主动跑 / 不批准任何读 `repo/` 外的 Bash），不额外加 deny 配置以免污染交付包。
3. **进度捕捉防丢**：每题维护一份「活进度」，**每推进一步即更新**，不靠对话记忆。三个信息源：扫 `repo/` 实际产物、只读开发轨迹（`*.jsonl`）、用户反馈。**关键 / 耗时 >1 分钟的操作之前就先写进度**（不是事后补）：`进度日志.md`（当前快照 + 步骤清单 ✅/🔵/⬜/⚠️ + 风险盯防 + 追加式时间线）+ `status.json`（`phase` / `current_step` / `updated_at`）。这样 token 烧完 / 睡觉 / 关机后，任何驱动 AI 读这两个文件就能续上。

---

## 5. 交付物规范 + 陪练侧标配

### 5.1 交付包结构
```
TASK-xxx/
├─ docs/              # design.md / api-spec.md(有后端必有) / questions.md
├─ repo/             # README.md + run_tests.sh + unit_tests/ + API_tests/ + Dockerfile + docker-compose.yml + 代码
├─ original_sessions/ # <projectID>.zip（开发轨迹）
├─ skills/           # 本题真用到的 agent-skill（纯英文）
└─ metadata.json     # 官方 8 字段
```
代码、`README.md`、测试、Docker **全在 `repo/`**；`docs/` 在任务根、不在 `repo/`。

### 5.2 metadata.json —— 官方 8 字段（值一律小写）
顺序：`project_type, prompt, frontend_language, backend_language, frontend_framework, backend_framework, database, cwd`。
- `project_type`：**必须**用官方枚举 `web / server / fullstack / android / ios / desktop`（纯后端 = `server`、纯前端 = `web`）。
- `prompt`：原始英文题目全文。
- `frontend_language`：**无前端填 `server`**；有前端填 `javascript` / `typescript` 等。
- `backend_language`：**无后端填 `none`**；有后端填 `python` / `java` / `go` 等。
- `frontend_framework` / `backend_framework` / `database`：无则留空，有则小写。
- `cwd`：**容器内绝对路径，默认 `/app`**（不是宿主机任务目录）。

### 5.3 README.md 三章节五铁律（高频打回项，放 `repo/`）
三章节：**How to Run**（明确启动命令）、**Services List**（各服务地址 + 端口）、**Verification**（如何验证 + `./run_tests.sh`）。
五铁律：① 启动步骤真实有效 ② 环境隔离（禁「本地能跑」、不依赖本地绝对路径）③ 一键 `docker compose up` 必起 ④ `docker-compose.yml` 显式 expose 端口 ⑤ 零私有依赖。
**`--build` 禁进主启动命令**：主命令**必须**是裸 `docker compose up`，`docker-compose.yml` 配 `build:` 让首次自动构建；README 主命令出现 `--build` 会被判「不加就跑不起来」= 不合格（`--build` 仅允许在一次性测试命令里）。

### 5.4 陪练侧 `tasks/<TASK-ID>/` 标配（中文 / 管理态，**严禁**进交付包）
`guide.md`（中文指导）、`进度日志.md`（活进度）、`status.json`（机器态）、`需求覆盖.md`（原题原子需求 × 落点 × 测试 × 状态）、`交付收尾清单.md`、`视频录制说明.md`（纯后端 2 段 / 前端类 3 段）、`提交六维度对照.md`、`submission_attachments/`（**英文文件名**证据）、`中断恢复指南.md`、`提示词历史/`（每条给 AI 的英文提示词存档、头一句中文说明用途）、`Dockerfile.原始备份`（有 Docker 的题）、`轨迹备份/`（需改轨迹时）。

---

## 6. 平台六维度评分表（每题收尾必填）

六维度：① 硬性门槛　② 交付完整性　③ 工程与架构质量　④ 工程细节与专业度　⑤ Prompt 需求理解与适配度　⑥ 美观度（**选填**，纯后端 / 无前端可写「不适用」）。前 5 项必填。

三条边界：
1. **说明栏可用中文**（平台评审看的，不属于交付包、不被中文扫描约束）；但**附件文件本身必须无中文**（视频无中文字幕 / 水印、文件名英文）。
2. 维度 ③④⑤ 引用的报告**必须**是**最终 PASS 轮**的（FAIL 轮报告不能交）。
3. 附件格式 **mp4 / PDF / PNG**，不支持 `.doc` / `.txt`；`.md → PDF` 用 `soffice --headless --convert-to pdf`。

证据映射（题型无关示例）：① final_validation 报告 + 自测视频；② README PDF + 目录树证据；③ design + 修复验收报告；④ 修复验收报告 + 边界状态截帧；⑤ 需求覆盖验证报告；⑥ 界面走查（仅前端 / 全栈 / 移动）。

---

## 7. 关键脚本清单（只列职责，环境特定）

> 这些脚本位于曼孚云电脑环境（驱动侧跑，**严禁**贴给作业 Claude）。具体路径随环境而定。

- **脚手架（scaffold）**：开发前建一级骨架 + 写官方 8 字段 `metadata.json` + `.gitignore`；整理交付包时把本题真用到的 skill 拷进 `skills/`。
- **结构校验（validate_package）**：交付包结构 + 英文一致性预检。
- **中文检测（check_chinese）**：英文题交付物须为 0 命中。
- **轨迹清洗（clean_original_sessions）**：生成 `original_sessions/`（清洗后轨迹、检测子代理）。
- **轨迹检查（trajectory_check）**：**只读**，绝不写 / 改 / 删轨迹。
- **质检闸门（run_quality）**：上传前官方质检，自动跑 codex 出报告；六阶段（基础验证 → 静态质检 → 修复验收 → API 测试有效性 → UI 交互 → 最终验证）。**只出报告、不自动提交**；修复 + 用户确认后才提交。
  - ⚠️ **安全警示**：质检脚本内含**硬编码凭据（GitLab / GitHub 令牌）**，属敏感。**严禁记录 / 外传 / 进交付包 / 写进任何文档**。

---

## 8. 安全纪律（贯穿全程）

1. GitLab PAT 等令牌**只许**出现在 `git remote` 的 URL 里（落在本机 `.git/config`），**严禁**写进任何被提交的文件 / 文档 / 交付包 / 聊天公开渠道。
2. 含令牌的脚本、凭据文件**必须**在 `.gitignore` 内，**严禁**进交付包。
3. 交付完成后**必须**轮换用过的 PAT。
4. 本文件及任何 Khy-OS 文档**严禁**抄录上述任何真实令牌值。

---

## 9. 与活源的关系

`~/Desktop/delivery-project-manager` 是这套方法论的**活源真相**（其 `CLAUDE.md` / `操作手册.md` / 各题 `tasks/<TASK-ID>/` 为权威过程态）。本文件 `[MGMT-STD-004]` 是 Khy-OS 内的**传承权威副本**，使 Khy 不依赖任一 AI 的私有记忆即可承接曼孚交付陪练。**规则更新以活源为准**，更新后回流同步本档。

---

## 跨分类关联指引

- 文档结构 / 索引铁律：见 [MGMT-STD-001]。
- 工程交付综合提示词版式参考：见 [MGMT-STD-002]。
- 本文件聚焦「曼孚外部交付任务」的陪练方法论，与 Khy-OS 自身工程治理并行，不冲突。
- Khyos 自身的通用工作方法论（证据搜集→做计划→计划落地）：见 [MGMT-STD-005]。本文管「怎么给客户交付」，STD-005 管「Khyos 自己怎么把一件工程活干对」，互补不互抄。
- khy 自身能否**替代 cc** 做 vibe/spec-coding 的量化验收标准：见 [MGMT-STD-006]。**注意研究对象相反**——本文的作业端**永远是 Claude Code**，STD-006 衡量的是 khy 自己能否达到 cc 的编码能力，两者不冲突。
