Daodao 內部分享 · PM + AI Coding
Daodao AI Coding 實戰
用這幾天參與 Daodao 開發的經歷，整理流程、問題和復盤方法。
案例：Web 端自定義應用上下架
大綱：分享是什麼 / 流程 / 問題 / 復盤
形式：分頁分享版
分享內容
把一次真實開發經歷講清楚
從拿到代碼、讓 AI 建立項目規範、啟動本地環境、讓 AI 分析需求、開發功能、測試檢查，到提交 MR 和處理 Review 的完整過程。重點不放在技術名詞，而是每一步要做什麼、要問誰、要怎麼檢查。
本次案例
Daodao Web 端自定義應用上下架
這幾天我主要負責的是 Daodao Web 端「自定義應用上下架」功能，涉及前端、後端、本地啟動、測試、GitLab MR、開發 Review 等完整流程。所以這次分享會用這個真實案例來講，不講抽象概念。
一句話主線：AI 可以幫我們寫代碼，但我們要控制流程、範圍、測試和 Review 閉環。
先把幾個詞講成人話
CLAUDE.md寫給 AI 的「項目說明書」，記錄前後端規範、命令、測試規則和不要亂改的地方。
Git diff看這次到底改了哪些文件、哪些行。AI 說完成不算，diff 才是證據。
MRMerge Request，提交給開發 Review 的代碼合併請求。
Migration資料庫結構的版本管理。加字段、改字段時，用它讓團隊環境保持一致。
核心原則：不要一上來就讓 AI 改代碼。先讓它理解項目規範、理解需求、輸出計劃，再分步執行。
3
配參數申請 .env / config.js 等配置8
提 MRcommit、push、建立 GitLab MR9
改 Review根據 comment 修改，再測試再提交
流程重點：每一步都要可確認、可回退、可交給開發 Review。
建立 CLAUDE.md
拿到代碼後，先讓 AI 分析前後端代碼編寫規範，整理成項目說明書。
- 可以在 Claude Code 執行
/init
- 也可以手動要求 AI 分析
- 不要把
.env 敏感參數寫進去
剛拿到代碼時可用
請先分析這個項目的前端和後端代碼編寫規範，整理成 CLAUDE.md。
請包含：技術棧、目錄結構、常用命令、前端規範、後端 Controller / Model / Migration 規範、測試規範、Git 提交與 MR 注意點，以及哪些公共邏輯不要隨便改。
不要修改業務代碼，也不要寫入任何 .env 敏感參數。
Step 5
準備需求文檔，先出開發計劃
不要直接說「幫我做上下架」。要讓 AI 先列出前端、後端、資料庫要改什麼，以及是否影響 Web / App。
拿到需求可用
請根據以下需求文檔，結合當前項目結構，分析需要修改哪些前端、後端、資料庫文件。
請輸出：實現方案、涉及文件、是否需要 migration、是否會影響 App 端或舊接口、風險點。
先不要修改代碼。
Step 7
功能完成後做兩類測試
頁面功能測試 + 自動測試。自動測試要按照目前項目已有的測試規範來寫，需要包含單元測試和集成測試。
| 測試類型 | 要看什麼 | 例子 |
|---|
| 頁面功能測試 | 從使用者角度確認功能是否符合需求 | 新增、編輯、上架、下架、必填校驗、刷新回顯 |
| 單元測試 | 測單個方法或邏輯是否正確 | 字段校驗、狀態轉換、資料處理邏輯 |
| 集成測試 | 測接口和多個模塊串起來是否正常 | 調用新增接口後，資料是否保存並能被列表查到 |
測試提示詞
請先查看項目目前已有的測試目錄、測試命名方式、測試基類、Mock 方式、資料庫處理方式和測試執行命令。
然後根據本次功能補充自動測試腳本，需要包含單元測試和集成測試兩類。
不要自創一套測試規範。
Step 8
提交前一定看 Git diff
- 有沒有無關文件被改
- 有沒有 import、空白、註釋等格式噪音
- 有沒有改到 Middleware 這類公共邏輯
- 有沒有直接改舊 Controller 方法，影響 App 端
- 資料庫字段變更是否補了 Migration
提交前檢查可用
請幫我檢查本次 Git diff。
請按文件列出：哪些改動與本需求直接相關、哪些是無關改動、哪些可能影響 App 端或公共邏輯、哪些建議還原。
只分析，不要直接修改。
Step 9
commit 到本地 → push 到 GitLab → 建立 MR
提 MR 時注意：
- 檢查 MR 的 diff 是否只包含本需求的改動
- 填寫清楚的 MR 描述和需求鏈接
- 標記給對應的開發做 Review
MR 品質檢查：diff 是否乾淨、是否有多餘改動、commit 訊息是否有意義。
Step 10
Review 閉環：根據 comment 修改
開發 Review → 根據 comment 修改 → 再測試 → 再檢查 diff → 再提交。
每一次 Review comment 都是一次學習機會，可以變成下一次的提示詞和規則。
處理 Review comment 可用
以下是 GitLab MR 的 Review comment。
請先解釋 reviewer 的意思，再判斷應該怎麼改。
請輸出修改計劃、影響範圍和測試點。先不要直接修改代碼。
1
先建立 CLAUDE.md
剛拿到代碼時，先讓 AI 分析前後端規範，或直接執行 /init。
2
先分析，再修改
任何任務先出方案、文件清單、風險點。
3
一次只做一類改動
不要前端、後端、資料庫、格式化一起改。
6
不要隨便改 Middleware
認證、權限、租戶這類公共邏輯影響範圍大。
7
Web 改動要考慮 App
共用接口不能隨便改，能新增方法就不要破壞舊方法。
8
資料庫改動要有 migration
新增字段、遷移字段、改表結構時要補。
9
自動測試按現有規範寫
先看項目已有測試，再補單元測試和集成測試。
10
Review comment 先理解再改
先解釋 reviewer 的意思和修改風險。
最核心的一句提示詞
本次對話遵循最小改動原則：不要改任何與問題無關的代碼格式、import、空白、註釋或公共配置。先只分析排查，列出需要修改的文件、原因和風險點，等我確認後再執行改動。
# CLAUDE.md
## Project Identity
**Daodao**
## Repository Structure
Workspace root is **not** a Git repo. It contains two independent Git repositories:
| Directory | Stack | Git Remote |
|-----------|-------|------------|
| `frontend/` | React 18 SPA | `gitlab.sjfood.us/daodao/daodao.web.git` |
| `backend/` | Laravel 10 API | `gitlab.sjfood.us/daodao/daodao.api.git` |
**All Git operations must be performed inside `frontend/` or `backend/` separately.**
## Global Red Lines
### Git & Repository
- **绝对不要在 workspace root 执行 `git` 命令**（branch / commit / push / merge 等）
- 所有 Git 操作必须先 `cd frontend/` 或 `cd backend/`
- 前后端变更必须分别提交，不能混成一个 commit
### Code Modification Scope（代码修改范围控制）
- **以最小改动完成当前任务** — 不要做任何与需求无关的修改、重构、优化、格式化或清理
- **修改前必须先输出变更计划**（列出预计修改的文件和方法），用户确认后再改
- 只改与当前任务直接相关的文件和方法；需要超出范围时先停止并向用户确认
- 不要因为"看起来没用"删除代码；不要改变正常工作的既有逻辑
- 保留文件原有格式风格，禁止执行全局格式化工具
- **禁止对既有的 import/use 语句进行纯粹的顺序调整**（例如按字母排序移动位置）— 即使格式化工具（如 Laravel Pint）建议调整，也不要在 MR 中夹带这类变更；只增删需要的 import，不调整已有 import 的顺序
- 任务完成前必须 `git diff --stat` + `git diff` 自查，确认每一处改动都是需求所需
### Data & Permissions
- 不要编造接口字段、数据库字段、权限、middleware
- 后端涉及租户数据时必须包含 `tenant_id`
- **Middleware 文件（`app/Http/Middleware/`）未经用户确认不得修改**（包括纯格式变更）
## Current Development State
Active feature: **custom app management**（自定义应用管理）for OME admin panel.
- Two-tier control: `tenant_enable` + `home_recommend`
- `shelf_status` removed per 2026-07-02 update
- Backend routes: `/ome/work-app/admin/*` (admin CRUD), `/ome/work-app/*` (frontend listing)
- Frontend pages: `application-manage/`, `home/`, `foreground/`
- Active branches: `feature/新增自定義上架功能-frontend`, `feature/新增自定義上架功能-backend`
## Core Documentation
- `docs/prd V1.1.md` — Product requirements
- `docs/backend-development-standards.md` — Backend conventions
- `docs/frontend-development-standards.md` — Frontend conventions
- `docs/2026-07-02-work-app-change-summary.md` — Latest change summary
## Rules & Skills
**Rules**（专项规范，放在 `.claude/rules/`）：
| File | Covers |
|------|--------|
| `rules/backend/laravel-module.md` | Module structure, conventions, commands, pre-commit |
| `rules/backend/tenant-rbac.md` | Tenant ID, RBAC, middleware chain, permissions |
| `rules/backend/api-response.md` | `apiResponse`, `BusinessException`, validation |
| `rules/frontend/react.md` | Stack, directory layout, naming, conventions, commands |
| `rules/frontend/api-integration.md` | API client, interceptors, types, error handling |
| `rules/git/two-repo-git.md` | Two-repo Git rules, CI/CD, branches |
**Skills**（任务流程，放在 `.claude/skills/`）：
**开发流水线（按顺序使用）：**
| Skill | 职责 | 修改代码 | Git 写入 |
|-------|------|----------|----------|
| `project-context` | 载入项目上下文（其他 skill 的前置） | 否 | 否 |
| `project-requirement-analysis` | 需求分析、影响范围、验收标准 | 否 | 否 |
| `project-feature-development` | 按确认方案完成前后端开发 | 是 | 否 |
| `project-quality-check` | Review diff、测试、lint/build、质量报告 | 仅测试 | 否 |
| `gitlab-delivery` | 建分支、commit、push、创建 MR | 否 | 是 |
**专项 Skill（按场景使用）：**
| Skill | When to Use |
|-------|-------------|
| `bug-fix` | Bug 定位与修复 |
| `api-change` | 接口新增/修改/删除 |
| `database-change` | 数据库结构变更 |
| `frontend-backend-integration` | 前后端联调对接 |
# Daodao — Claude Code 會話分析報告
## 🔑 項目核心線索
### 技術棧
| 層級 | 技術 |
|------|------|
| 後端 | PHP 8.2 + Laravel (Eloquent ORM, Migrations, Blade) |
| 數據庫 | MySQL (InnoDB) |
| 認證 | Account Center、Tenant Scope 多租戶 |
| 存儲 | OSS（阿里雲對象存儲）、Local 文件系統 |
| 代碼質量 | Laravel Pint（PHP格式化）、GitLab CI |
### 數據庫關鍵表
- `ome_work_apps` — 全局工作應用表
- `tenant_has_ome_work_apps` — 租戶-應用關聯表（本次 feature 的核心）
- `tenant_user` — 租戶用戶關聯
- `ome_workbench_grouping_has_work_apps` — 工作檯分組關聯
- `users` — 用戶表（含 avatar 訪問器）
### 功能分支
- `feature/新增自定義上架功能-backend` ← 後端
- `feature/新增自定義上架功能-frontend` ← 前端
---
## 🧠 工作主題分析
### 1️⃣ 項目啟動與環境配置（7/1）
最開始的任務是從零搭建本地開發環境：
- 沒有 PHP → 下載 PHP 8.2.32
- 按照 README 配置 Docker 鏡像
- 遇到 SSL CA 認證問題、OSS 配置問題
- 排查管理員權限入口
### 2️⃣ 核心功能開發（7/2）
自定義應用上架功能（CRUD）：
- 首頁應用顯示邏輯（限制 8 個）
- 後臺應用分頁按鈕超出可見範圍的 UI 修復
- Bug 排查：新增應用後調整報錯，原因是 `tenant_has_ome_work_apps` 表在執行 `update ... where id is null` — 模型缺少主鍵聲明
### 3️⃣ GitLab MR Review 修復（7/2 - 7/3）
最耗時、最複雜的部分，Reviewer 的核心原則：本 feature 只做 CRUD，與此無關的代碼全部還原。
- 需修復的問題：enum → as const 模式轉換、移除 SSL 驗證配置、移除無關模型屬性、還原 avatar 訪問器、清理 Controller 無關代碼、大量 Laravel Pint 格式變更
### 4️⃣ 數據遷移與重構（7/3）
`home_recommend` 字段從全局表遷移到租戶關聯表：
- 新增遷移文件，從 `config('ome.recommended_work_apps')` 讀取推薦應用
- 最小改動原則：從 19 個文件清理到 15 個
---
## ⚠️ 值得注意的點
1. MR Review 佔比極高 — 尤其是清理無關格式變更（Pint 自動格式化）花費了大量精力
2. 多次 context 壓縮續接 — 說明單個會話的工作量很大
3. 「最小改動原則」 — 非常重視 MR 的可讀性，建立了禁止 import 重排序等規則
---
## ❌ 錯誤模式與對應提示詞
### 模式一：格式噪音汙染（出現次數最多）
現象：Laravel Pint 自動格式化導致 MR diff 被淹沒
✅ 最小改動原則：只改業務邏輯，不要動格式/import/空白
### 模式二：Eloquent 複合主鍵忽略（Bug 級）
現象：`tenant_has_ome_work_apps` 是複合主鍵，但用了 `where id is null`
✅ 注意 pivot 表複合主鍵，生成查詢時避免 Eloquent 默認 id 假設
### 模式三：「只回答不修改」被繞過
現象：說「只回答不修改」結果首頁還是被改了
✅ 絕對不要執行任何文件寫入操作，用分析模式回答
### 模式四：跨 session 上下文斷裂
現象：同一問題在不同 session 重複出現
✅ 搜索 .claude/ 目錄下的記憶文件，看是否有相關記錄
### 模式五：前端問題被後端視角帶偏
現象：CSS 問題被從後端路由/控制器角度分析
✅ 先判斷問題類型，再要求 AI 按正確方向排查
---
## 📋 懶人包 — 一句話前綴
本次對話遵循最小改動原則：不要改任何與問題無關的代碼格式或 import。先只分析排查，等我的確認再執行改動。
---
## 📊 問題優先級列表
### 🔴 P0 — Bug / 阻斷級
1. 複合主鍵 → `where id is null` — Eloquent 默認用 id 當主鍵，但該表是複合主鍵
2. 首頁顯示了 9 個應用 — Claude 在回答時順手把限制去掉了
3. CA SSL 憑證問題（cURL error 60）— 開發環境問題 vs MR 純淨度的衝突
### 🟠 P1 — MR Review 阻塞級
4. Laravel Pint 格式變更污染 MR diff — 19 個文件裡只有 4 個是真實業務改動
5. Controller 中無關代碼被帶入 — Claude 傾向於「順手優化」
### 🟡 P2 — 功能開發障礙
6. `home_recommend` 字段遷移（全局 → 租戶級）
7. Tenant Cookie / 400 錯誤 — 請求沒帶 tenant-id
### 🔵 P3 — UI/UX 問題
8. 後臺應用分頁按鈕超出可見範圍
9. 管理後臺入口找不到
### 🟢 P4 — 配置/環境問題
10. 本地沒有 PHP 環境、找不到前端配置文件、OSS vs Local 存儲切換等
