深夜用GLM-5.1 loop 了一个网络药理学平台：我用 AI 编程做了个计算机设计大赛的全程复盘

这不是一篇"AI 写代码好厉害"的软文。我想分享一个学药的大学生如何在凌晨、对着终端屏幕、用一个叫 /loop 的命令，让 AI 在自己睡觉的时候继续写代码的记录与复盘。

写在前面

我参加的是 2026 年第 19 届中国大学生计算机设计大赛，作品是 NetPharm —— 一个网络药理学知识分享平台。

这个项目前端 45 个源文件约 7800 行代码，后端 48 个 Python 文件约 3500+ 行，涵盖 6 种交互式数据可视化（D3.js / ECharts / Three.js / Canvas）、16 篇专业博客、完整的用户认证系统、管理后台。

其中大约 70% 的代码，是 GLM-5.1在凌晨自动生成的。

我想聊的是：怎么拆任务、怎么写 prompt、怎么用 /loop 让 AI 在你睡觉的时候持续输出，以及中间翻了多少次车。

---

一、项目是什么：给不懂药理学的开发者看的介绍

网络药理学是中医药现代化的一个研究方向：用计算方法分析中药复方（比如"茵陈蒿汤"）中的有效成分如何作用于人体靶点蛋白，从而解释"这个药为什么管用"。

我们的平台以我的大创"茵陈蒿汤抗乙肝机制研究"为核心案例做了延伸，做了这些事：

• 6 种交互式可视化：分子互作网络力导向图（D3）、药物筛选流程图（ECharts）、粒子流图（Canvas）、3D 分子对接（Three.js）、热图/气泡图（ECharts）、3D Hero 分子动画

• 
  

  知识博客系统：16 篇网络药理学专业文章，支持分类、标签、全文搜索

  
  


• 
  

  全栈认证：注册/登录/JWT 鉴权/个人中心

  
  


• 
  

  管理后台：用户管理、文章管理、联系消息管理（值得一提的是我用的python写的后端，更方便未来接入AI/ML）

  
  


• 
  

  响应式设计：桌面/平板/移动端全适配

  
  

技术栈：React 19 + TypeScript + Vite 7 + Tailwind CSS v4 + FastAPI + SQLAlchemy 2.x

---

二、先说方法论：拆任务

很多人刚vibe coding的时候踩过一个坑：一开始给 AI 发"帮我写一个网络药理学平台"，拿到的东西没法用。跟给人类同事甩一句"做个网站出来"差不多。

后来我学乖了，开始拆任务。拆到什么程度？大概是一个 15 分钟内能说清楚、能验证的小目标。

我的拆法分三步：

比赛要求 → 功能清单 → 独立模块 → 可执行的 prompt

第一步，从比赛要求推导功能清单。软件应用与开发类的评分标准我过了一遍，列出来必须有的东西：

• 
  

  信息展示（研究背景、方法论）

  
  


• 
  

  交互式可视化（至少 3 种，越多越加分）

  
  


• 
  

  用户系统（注册、登录、个人中心）

  
  


• 
  

  内容管理（博客/教程）

  
  


• 
  

  后台管理

  
  


• 
  

  联系方式

  
  

第二步，按技术边界拆成独立模块。我借助GLM-5.1用一张表来规划：

拆分任务的原则很简单：每个模块的依赖尽量少，能独立跑、独立验证。

第三步，每个模块再拆成具体的 prompt。比如"分子互作网络"这个模块，我不会直接说"帮我写 MolecularNetwork 组件"。拆法如下：

任务 1: 创建 src/components/visuals/MolecularNetwork.tsx

  - 接收 props: { nodes: Node[], links: Link[], width, height }

  - 使用 D3 forceSimulation 实现力导向布局

  - 节点按类型用不同颜色（药物=青色，靶点=品红）

  - 拖拽交互、缩放、hover 显示详情

  - 暗色主题，节点发光效果



任务 2: 创建 mock 数据 src/data/molecularData.ts

  - 茵陈蒿汤的 15 个活性成分

  - 对应的 20 个靶点蛋白

  - 成分-靶点互作关系



任务 3: 集成到 Home.tsx 首页

  - 在首页"分子互作网络"section 中引入 MolecularNetwork 组件

  - 响应式尺寸（桌面 100%，移动端全宽）

  - 加载状态、错误边界

每个任务大约 15-30 分钟的 AI 工作量，刚好是一个 /loop 的合适粒度。

由多个 /loop 合并起来的，有人工加易修改，最后可以得到类似这种效果（后文有提多个loop串在一起的这种方法 ）

2.2 怎么判断拆得够不够细

后来我在一篇文章里看到一个说法，觉得说得很好：拆任务的终极目标不是"看起来细"，而是让每个子任务满足三个条件——可验证、可回滚、可重启

翻译成大白话就是三个判断题：

1. 
   

   我能不能写出一句话的 Done？（最好机器能验证）

   
   


2. 
   

   坏了能不能在 5 分钟内回滚到稳定态？

   
   


3. 
   

   如果 AI 上下文清空了，只看仓库代码和这张任务描述，能不能继续？

   
   

三个问题里任意一个答"不能"，就继续拆。我踩的几次坑，事后回看都是拆得不够细导致的。

2.3 任务拆分的"画布法"：不只列清单，画依赖图

光有一张任务清单还不够。当任务之间有依赖关系时（比如"组件开发"依赖"数据结构定义"，“集成到页面"依赖"组件开发”），一张平铺的列表会让人（和 AI）看不清执行顺序。

我后来用一种"画布"的方式来组织任务。本质上是一张表，但每个任务卡片上都标注了三个关键信息：

┌─────────────────────────────────────────────────────────┐

│  Task 05: 分子互作网络组件 (MolecularNetwork.tsx)       │

├─────────────────────────────────────────────────────────┤

│  依赖: Task 03 (数据模型定义)                            │

│  产出: src/components/visuals/MolecularNetwork.tsx      │

│  验证: pnpm type-check 通过 + 可独立渲染                 │

│  粒度: ~20 分钟 AI 工作量                                │

│  上下文: 需要 molecularData.ts 的类型定义作为输入        │

└─────────────────────────────────────────────────────────┘

画完这张画布之后，执行顺序自然就出来了——没有依赖的任务可以并行（用多个 loop），有依赖的任务串行（接力式执行）。而且每个任务的"验证标准"和"上下文需求"都是提前写好的，不需要等到 loop 启动时才临时想。

这样做还有一个好处：如果某个 loop 翻车了（比如 AI 写了一堆垃圾代码），我可以精确地知道要回退到哪个 checkpoint，重新执行哪几个任务卡片，而不是像无头苍蝇一样从头来。

---

三、/loop 是什么，以及我怎么用的

3.1 /loop 简单介绍

我在2026.4.9~2026.4.12这几天用的是 Claude Code v2.1.92

/loop 的机制：你给 AI 一个任务描述，它会按照你设定的时间间隔，反复把这个 prompt 重新注入到当前会话中。AI 每次被触发时都能看到之前的完整对话历史，所以它能"接着上次干"。但它并没有内建的"检查→修错"逻辑。AI 是否会自我检查、是否会修复错误，完全取决于你在 prompt 里怎么写。它本质上是 session 内注册了一个定时任务（底层用 cron 调度），绑定当前会话，recurring 任务 7 天后自动过期。关掉终端、电脑休眠都会导致 loop 立即消失——没有持久化。

和普通的"对话式编程"最大的区别是：

• 
  

  普通对话：你说一句，AI 回一句，你说下一句

  
  


• 
  

  loop 模式：你说一次任务目标，AI 自己循环跑，你可以去睡觉

  
  

3.2 我的使用模式：混合策略

我的策略是"重活用按照上文细致规划后用 loop，细活手动来做或者探明问题之后直接叫AI改"：

3.3 一个典型的深夜 loop 流程

这是我最常用的工作流，经常发生在某个凌晨 00:00：

23:30  看了一遍比赛要求（prd），梳理了明天要完成的模块

23:45  写好了 prompt，确认了目标

00:00  启动 /loop，内容大概是：

       "请完成 MolecularNetwork.tsx 组件的开发。

        要求：

        1. 使用 D3.js forceSimulation

        2. 支持 drag / zoom / hover

        3. 暗色主题，节点发光效果

        4. 确保通过 type-check 和 lint

        完成后运行 pnpm type-check 验证"



00:02  看着 AI 开始输出了第一版代码

00:05  确认 大致的方向没问题，放着笔记本去睡觉

第二天早上 7:00 醒来：

07:00  打开终端看结果

       情况A：组件写完了，type-check 通过 → 人工审查代码质量

       情况B：type-check 失败了 → 看错误日志，手动修复或再起一个 loop

       情况C：AI 在某个地方卡住了 → 分析原因，调整 prompt 重新来

说白了就是"人睡觉，AI 写代码"。但别误会，这不是每次都能成功的“魔法”。前面拆任务、写 prompt 花的时间才是大头。

3.4 让 loop 收敛的关键：把"验收"交给机器

Cursor 在一篇关于长时间自主编码的文章里提到一个概念：每轮执行最后，需要一个 judge agent 来判定任务是否完成。Simon Willison 在引用这篇文章时补充说，当项目有强测试套件（conformance suites）时，AI 自主编码的成功率会大幅上升。

映射到我自己的场景：我睡觉的时候没法当 judge，所以必须把验收标准"外部化"成机器能跑的命令：

• 
  

  pnpm type-check（类型安全）

  
  


• 
  

  pnpm lint（代码规范）

  
  


• 
  

  pytest -q（后端逻辑正确性）

  
  


• 
  

  pnpm test（前端逻辑正确性）

  
  

没有自动化验收的 loop，本质上是随机游走，还是老虎机。有自动化验收的 loop，才会迭代逼近。这是我平时翻车翻多了之后才真正理解的。

3.5 多个 loop 串联：把长跑变成接力

前面说的都是"一个 loop 完成一个子任务"。但实际开发中，一个完整的功能模块往往需要好几个 loop 配合才能跑通。比如分子互作网络这个功能，光一个 MolecularNetwork.tsx 组件不够，还得有 mock 数据、集成到页面、样式调优——这不是一个 loop 能搞定的。

我摸索出来的一套方法是"接力式串联"。核心思路是：每个 loop 只负责一个明确的交付物，loop 和 loop 之间通过文件系统传递状态，而不是靠对话上下文。

具体怎么做：

第一步，把功能拆成有依赖关系的 loop 序列。 以分子互作网络为例：

Loop 1: 创建 MolecularNetwork.tsx 组件骨架

  交付物: 组件文件，可独立渲染，type-check 通过

  ↓ 产出文件，作为 Loop 2 的输入



Loop 2: 创建 molecularData.ts mock 数据

  交付物: 数据文件，15 个成分 + 20 个靶点 + 互作关系

  ↓ 产出文件，作为 Loop 3 的输入



Loop 3: 将组件集成到 Home.tsx 首页

  交付物: 首页包含该组件，响应式布局正确

  ↓ 人工审查，决定是否需要 Loop 4



Loop 4（按需）: 样式优化和交互细节调整

  交付物: 发光效果、hover 动画、移动端适配

每个 loop 之间有一个硬性交接物——文件。前一个 loop 产出的文件就是后一个 loop 的输入，不需要任何对话历史。

第二步，给每个 loop 写相对独立的 prompt，不依赖前一轮的对话。 这意味着 prompt 里要包含足够的上下文：项目路径、技术栈约束、依赖文件的位置。好处是，即使上一个 loop 的对话上下文已经清空了，新 loop 也能从仓库代码里读出它需要的一切。

第三步，用"进度文件"做跨 loop 的记忆。 我会在 docs/AI_PROGRESS.md 里记录每个 loop 的状态：做了什么、跳过了什么、下一步是什么。新 loop 启动时先读这个文件，就能接上之前的进度。

第四步，每完成一个 loop 做 git commit"。如果 Loop 3 发现 Loop 2 的数据结构不对，可以快速回退到 Loop 2 结束时的状态，修完再重来，不用从头开始。

0din.ai 把这种方法总结为无人值守 AI 编程的"三支柱"之一——Context（上下文管理）。Zach Wills 在管理 20 个并行 agent 的经验中也强调：长时间运行的 agent 是 bug，不是 feature；它们会漂移、压缩记忆、忘初衷。解决方案就是把大任务拆成小段，用文件和 git 做记忆载体，一段一段接力。

这套方法的实际效果：由多个 loop 串联执行，中间穿插人工审查和微调，最终可以得到一个完整的功能模块。

一个容易忽略的细节：loop 之间的人工介入。 不是每个 loop 结束后立刻启动下一个。我的做法是，每个 loop 完成后花 5-10 分钟做人工审查——看代码质量、看接口是否对得上、看有没有明显的方向偏差。发现问题就手动修，或者调整下一个 loop 的 prompt 再启动。纯串联不审查，错误会逐级放大。

3.6 /loop 命令实操：不只是"说一句就走"

前面讲了怎么用 /loop，但省略了一个关键细节：/loop 命令本身有参数，选择不同的参数会直接影响你一晚上的产出质量。

/loop 的基本语法是：

/loop [间隔] [任务描述]

比如：

/loop 5m 完成后端用户模块的 JWT 认证实现

/loop 10m 修复当前分支的所有类型错误

/loop 15m 创建 16 篇博客的静态数据文件

几个关键细节：

不写间隔时：默认 10 分钟。此时进入"动态自调步模式"（dynamic pacing），AI 自己判断什么时候该回来检查，而不是固定时间触发。

写了间隔时：按固定 cron 调度触发。支持 s（秒）、m（分钟）、h（小时）、d（天）作单位。非标准间隔（比如 7m）会被自动取整到最近的分钟。

触发时机：loop 在 AI 空闲时才触发（between turns），不会打断正在进行的回复。如果 AI 正忙，排队的 prompt 会等 AI 完成后再注入。

间隔怎么选？ 这不是随便选的。我后来总结出一条经验法则：

核心原则：间隔要给 AI 留够"一轮完整执行"的时间。 如果 type-check 要 30 秒，AI 修一个错误要 1-2 分钟，那你设 1 分钟的间隔太短了。虽然 loop 不会并发执行（AI 忙的时候 prompt 会排队等），但间隔太短会导致 prompt 堆积、上下文膨胀——AI 还没处理完上一轮，下一轮又来了，对话历史快速增长，反而加速上下文溢出。

另外，/loop 是 session 绑定的——关掉终端、断网、电脑休眠都会打断它。所以"深夜挂机"的前提是：终端窗口不能关，电脑不能休眠。我一般会把 Mac 的"防止自动进入睡眠"打开，或者用 caffeinate 命令防止休眠。

3.7 离人状态的工程化：让 AI 在你睡觉时可靠地跑

"人睡觉，AI 写代码"听起来很美好，但实际操作中有一个核心问题：你怎么保证 AI 不会在你睡着之后跑偏？

答案是：现在的你/我都保证不了。但你可以通过工程化手段把跑偏的概率降到最低。我后来沉淀了一套"睡前检查清单"和"醒后验收流程"。

睡前检查清单（启动 loop 之前）

这个清单我每次启动 loop 之前都会过一遍，大概花 5 分钟：

□ 1. 当前分支是干净的（没有未提交的改动）

     → 如果有，先 commit 或 stash，确保回退点明确



□ 2. 所有测试是绿的（pnpm test / pytest -q 全通过）

     → 如果不是绿的，先修到全绿再启动 loop

     → 从一个"全绿"的状态出发，loop 翻车时才能清晰定位



□ 3. prompt 里的目标只有 ONE 个

     → "完成 MolecularNetwork 组件" ✓

     → "完成组件 + 写测试 + 更新文档 + 调样式" ✗（目标太多）



□ 4. prompt 里写了明确的验证命令

     → "完成后运行 pnpm type-check"

     → 如果没写，AI 可能"觉得做完了"但其实没验证



□ 5. prompt 里写了失败时的行为

     → "如果 3 轮内无法修复，把当前进度写入 docs/AI_PROGRESS.md 然后停止"

     → 防止 AI 在错误方向上无限重试



□ 6. CLAUDE.md 是最新的

     → 如果最近改了技术栈或代码规范，确保 CLAUDE.md 已更新

     → loop 启动后 AI 第一件事就是读 CLAUDE.md



□ 7. 检查电脑不会自动休眠

     → macOS: 系统设置 → 电池 → 选项 → 防止自动进入睡眠

     → 或终端运行: caffeinate -d &

这 7 步看着繁琐，但熟练之后 3-5 分钟就能过完。关键是第 1、2、6 步——它们确保了"出发点是正确的"。从错误的状态出发，loop 跑得越久，离目标越远。

醒后验收流程（起床之后）

第一步：看终端

  → loop 还在跑吗？还是已经停了？

  → 如果停了，是正常结束（输出了 COMPLETE）还是异常中断？



第二步：看 git log

  → loop 期间有没有新 commit？

  → commit 之间是否有明显的方向偏移？（看 commit message）



第三步：跑一遍验证

  → pnpm test && pnpm type-check && pnpm build

  → cd backend && pytest -q



第四步：看代码质量（不是看能不能跑过检查）

  → 有没有 1000 行的巨型文件？

  → 有没有不该引入的新依赖？

  → 命名是否一致？

  → 代码结构和你在 CLAUDE.md 里定义的架构是否吻合？



第五步：决策

  → 质量OK → 继续下一个 loop

  → 有小问题 → 手动修，或调整 prompt 再 loop

  → 方向偏了 → git reset 到 loop 开始前的 checkpoint，重写 prompt

第五步是最重要的。Zach Wills 有一条建议我后来严格执行了：一旦走偏，立刻 kill + 更好的指令重跑，不要试图在错误方向上修修补补。 "修修补补"是最慢的路！！

3.8 状态规范化：让 AI 不需要"回忆"就能继续

这里要讲一个很多人忽略的问题：在白板的状态下AI 没有长期记忆。

在不用任何插件的情况下，当你关掉一个终端会话，AI 在那个会话里积累的所有上下文（“我们讨论了什么”、“你偏好什么风格”、“之前尝试了什么失败了”）全部消失。新会话的 AI 是一个全新的实例，它唯一能获取的信息是：仓库代码 + 配置文件。

这意味着，如果你想让 AI 在多个 loop 之间保持一致性，必须把"状态"持久化到文件里。要么用一些记忆类的插件，但我个人更喜欢用四层状态管理：

第一层：CLAUDE.md —— 项目的"宪法"

/init 的命令生成的 CLAUDE.md 是 AI 每次打开项目时第一个读的文件。它定义了项目的所有硬性约束：

# CLAUDE.md



## 项目概述

NetPharm — 网络药理学知识分享平台...



## 常用命令

pnpm dev / pnpm build / pnpm test / pytest -q ...



## 技术栈

React 19 + TypeScript + Vite 7 + Tailwind CSS v4 + FastAPI + SQLAlchemy 2.x



## 架构

分层结构：Routes → Services → Repositories → Models

统一响应格式: {success: bool, data: T, message: str}



## 关键约定

- 路径别名: @/ → ./src/

- 颜色系统: oklch 色彩空间

- 路由: hash 模式

- 组件约定: shadcn/ui 组件不要手动修改



## 已验证通过的状态

- pnpm test → 29/29 passing

- pytest -q → 25 passed



## 尚未完成的工作

1. 博客页切后端

2. Token 刷新机制

3. ...

这份文件有多重要？我举一个例子：后端一次 loop 拉通成功，很大程度上是因为你提示词的约束很好或者 CLAUDE.md 里已经写清楚了"分层架构"、“统一响应格式”、“技术栈版本”。AI 不需要猜我要什么风格的后端，它照着"合同"执行就行。（GLM-5.1的指令遵从真的不赖）

写 CLAUDE.md 的几个原则：

• 
  

  尽量只写"不变的东西"（技术栈、架构、约定、命令），不要写"状态"（做了什么、做到哪了）

  
  


• 
  

  每次技术决策变更后立刻更新（比如从 Node.js 换成 FastAPI）

  
  


• 
  

  在可以描述清楚的状况下，越具体越好——"使用 oklch 色彩空间"比"使用暗色主题"有用得多

  
  

第二层：进度文件 —— loop 之间的"交接单"

CLAUDE.md 是"静态宪法"，进度文件是"动态状态"。我用 docs/AI_PROGRESS.md 来记录每个 loop 的执行情况：

# AI Progress



## 2026-04-10 Loop Session



### Loop 1: MolecularNetwork 组件 ✅

- 产出: src/components/visuals/MolecularNetwork.tsx

- 验证: pnpm type-check 通过

- 跳过: 没加发光效果（下个 loop 补）



### Loop 2: molecularData.ts ✅

- 产出: src/data/molecularData.ts

- 包含: 15 个活性成分 + 20 个靶点 + 互作关系



### Loop 3: 集成到 Home.tsx ❌ BLOCKED

- 问题: 组件 props 类型不匹配，MolecularNetwork 期望的 Node 类型

  和 molecularData.ts 导出的类型不一致

- 下一步: 先统一类型定义，再集成

新 loop 启动时，第一件事就是读这个文件。AI 看到上一次 loop 做了什么、卡在哪里、下一步是什么，就能无缝接上。

第三层：Git Commit —— 可恢复的检查点

每个 loop 完成一个有意义的子目标后，我都要求 AI（或手动）做一次 git commit：

feat(visuals): add MolecularNetwork D3 force-directed graph component

feat(data): add molecular interaction mock data for Yin Chen Hao Tang

fix(types): unify Node/Link type definitions across components

commit message 本身就是一份"历史记录"——如果 AI 上下文丢了，git log --oneline 能让它快速理解项目的演进过程。

还有一个实战技巧：在启动一个高风险 loop 之前，先手动 commit 一个"安全点"。这样如果 loop 翻车了，一条 git reset --hard <commit-hash> 就能回到翻车前的状态，也不用手动找哪些文件被改坏了。

第四层：设计文档 —— loop 的"执行合同"

这是我的后端一次 loop 成功的核心。1500 行设计文档（技术方案 + API 契约 + 数据库设计）扮演了"合同"的角色：

• 
  

  技术方案（770 行）：告诉 AI “用什么、怎么组织、为什么这么选”

  
  


• 
  

  API 契约（402 行）：告诉 AI “每个接口的输入输出长什么样”

  
  


• 
  

  数据库设计（376 行）：告诉 AI “表结构、字段类型、关系怎么定义”

  
  

AI 不用完全理解业务逻辑，它只需要对着合同执行。每个字段类型、每个接口路径都有明确定义——pytest 通过就是通过，不通过就是不通过，没有模糊地带！这四层配合，在我手上能让 AI 在你不在的时候较为可靠地跑。

3.9 中间会遇到的问题（以及我的解法）

讲了这么多方法论，但实际操作中问题远比理论多。以下是我踩过的坑和对应的解法：

问题 1：Token 用尽 / 上下文爆掉

现象： loop 跑了十几轮之后，AI 开始"忘记"之前的约定。比如前面写的代码用的是 camelCase，后面突然变成 snake_case；或者前面定义的组件 props 类型，后面完全不认了。

**你我都知道，**AI 的上下文窗口有限。随着对话越来越长，早期的重要信息会被压缩或丢弃。

解法：

1. 
   

   限制单个 loop 的任务跨度（15-30 分钟）

   
   


2. 
   

   把所有重要约束写入文件（CLAUDE.md / SPEC.md），而不是只在 prompt 里说

   
   


3. 
   

   使用"接力式串联"——一个 loop 结束后，新 loop 从文件里读上下文，而非从对话历史里继承

   
   

问题 2：方向偏移——AI "自作聪明"或者想太多了

现象： 你让它写一个简单的列表组件，它顺手把整个页面重构了。或者你让它修复一个 CSS 问题，它把整个样式系统换成了 CSS-in-JS。

prompt 没有写"不要做什么"。AI 倾向于"多做"而不是"少做"，因为它被训练为"尽可能有用"。

解法： 在 prompt 里显式写 Non-goals：

目标：修复 MolecularNetwork 组件的 hover 样式问题



Non-goals（不要做）：

- 不要修改组件的数据结构

- 不要引入新依赖

- 不要重构其他组件

- 不要修改全局样式文件

这一招非常有效。后来我每个 prompt 都会追加一个 Non-goals。

问题 3：死循环——AI 反复修同一个 bug

现象： AI 修了一个 bug，引入了新 bug，再修新 bug，又引入另一个新 bug……无限循环。你早上醒来发现终端刷了几百行输出，代码反而比睡前更烂。

根因： 缺少"停止条件"和"回退机制"。现在的AI 没有"止损"的概念，它会一直试直到你关掉它。

解法：

1. 
   

   在 prompt 里设置最大迭代次数：“如果 5 轮内测试不全绿，把问题写入 BLOCKED.md 然后停止”

   
   


2. 
   

   记住 loop 的 recurring 任务最长 7 天后自动过期。如果发现 AI 陷入死循环，可以直接关闭终端杀掉整个会话——session 级别的 loop 随会话一起消失

   
   


3. 
   

   最重要的一条：醒后先看 git diff，如果代码质量明显下降，果断 reset 到 loop 开始前的 commit

   
   

问题 4：依赖冲突——AI 引入了不该有的包

现象： 你项目用的是 d3@7，AI 引入了 d3-force@3（旧版），导致类型冲突。或者你用 pnpm，AI 跑了 npm install。

这是因为AI 不知道项目的依赖管理细节，或者没有先检查已有依赖。

解法： 在 CLAUDE.md 里写清楚：

- 包管理器使用 pnpm（禁止使用 npm 或 yarn）

- 不要引入已有依赖的旧版本

- 添加新依赖前先检查 package.json 中是否已有同类库

---

四、Prompt 模板

踩了几轮坑之后，我沉淀了几个模板。

4.1 组件开发模板

请创建 [组件路径和名称]



功能要求：

1. [具体功能点 1]

2. [具体功能点 2]

3. ...



技术约束：

- 使用 [具体库和版本]

- 遵循项目 CLAUDE.md 中的代码规范

- 暗色主题，使用 oklch 色彩空间

- 确保响应式（桌面 + 移动端）



验证标准：

- pnpm type-check 通过

- 组件可独立渲染，无报错

- 代码不超过 [N] 行（超过说明需要拆分）

4.2 后端 API 模板

请参考 docs/backend-api-contract.md 的接口契约，

实现 [具体 API 路由] 的完整功能。



分层要求：

- Model（SQLAlchemy）→ Repository → Service → Route

- Pydantic Schema 做请求/响应校验

- 统一响应格式 {success, data, message}



验证标准：

- pytest 通过

- 符合 API 契约文档的请求/响应格式

4.3 Bug 修复模板

运行 [具体命令] 时出现以下错误：



[粘贴完整错误信息]



请分析根因并修复。注意：

- 不要猜测，先读相关代码再改

- 修复后运行 [验证命令] 确认

- 如果是设计问题而非 bug，写入问题文档并告诉我

---

五、后端：一个 loop 拉通整个 FastAPI

这一章是我个人觉得最成功的 loop 使用案例。0din.ai 有一篇文章叫"While True: The Art of Unattended AI"，把无人值守 AI 编码总结成"三支柱"：Specs（明确规格）、Context（上下文管理）、Execution（可靠执行）。我的后端案例恰好是 Specs 足够强的典型。

是这样的

项目前端已经基本完成，但后端还是空的。比赛要求有完整的前后端。我写了一份详细的后端技术方案文档（docs/backend-python-ai-spec.md，约 770 行），定义了：

• 
  

  技术选型理由（为什么用 Python/FastAPI）

  
  


• 
  

  分层架构（Model → Repository → Service → Route）

  
  


• 
  

  API 接口契约

  
  


• 
  

  数据库表结构

  
  


• 
  

  种子数据需求

  
  

执行过程

我给 AI 的 prompt 大意是：

请根据 docs/backend-python-ai-spec.md 的技术方案，以及 docs/backend-api-contract.md 的接口要求，实现完整的 FastAPI 后端。

要求：

1. 
   

   完整的分层架构

   
   


2. 
   

   所有 API 端点可工作

   
   


3. 
   

   种子数据（4 用户 + 16 文章）自动加载

   
   


4. 
   

   pytest 测试通过

   
   


5. 
   

   启动 uvicorn 后前端可正常对接

   
   

AI 用了一次 loop 就产出了整个后端，60 个文件，3500+ 行代码。Git 记录显示这是一个大 commit：

feat(backend): initial FastAPI backend with auth, posts, contacts APIs



60 files changed, 3562 insertions(+)

包含：

• 
  

  6 个数据库模型（User, Post, Tag, PostTag, Contact, AnalysisJob）

  
  


• 
  

  4 个 Repository（user, post, contact 的数据访问层）

  
  


• 
  

  4 个 Service（auth, post, contact, analysis 业务逻辑）

  
  


• 
  

  6 个 Route 模块（auth, users, posts, contacts, admin, analysis）

  
  


• 
  

  完整的 Pydantic Schema

  
  


• 
  

  JWT 认证和权限系统

  
  


• 
  

  25 个测试用例（全部通过）

  
  

这里有个认知上的转变：AI 并没有从零"理解"整个后端设计。它做的是执行。我新开一个 cc,glm–4.7辅助我写了1500 行设计文档（770 行技术方案 + 402 行 API 契约 + 376 行数据库设计）把意图表达清楚了，剩下的就是 AI 的活。

回顾这次为什么这次成功了

回头看，这次能一次跑通有两个前提：文档够细，验证标准够明确。每个接口的输入输出、每个表的字段类型都有定义，pytest 通过就是通过，不通过就是不通过，没有模糊地带。

总结下就是：当项目目标存在强测试和一致性套件时，长程自主编码才变得可行。我的 1500 行设计文档 + 25 个 pytest 用例，就是那个"一致性套件"。

---

六、成果：最终项目数据

---

七、几条实战建议

1. 拆任务是写提示词的核心能力

一个模糊的"帮我做个网站"prompt，AI 大概率只能给你平庸的结果。把需求拆成 20 个精确的子任务，每个都有明确的输入输出和验证标准，AI 的输出质量会完全不一样。

2. 文档是 prompt 的一部分

别只在 prompt 里描述你要什么，写一份设计文档让 AI 读。我的后端能一次 loop 搞定，靠的就是 1500 行设计文档。用 0din.ai 的术语说，这叫 Spec-Driven Development——先有强规格，再让 AI 对着规格执行。

3. loop 的粒度要适中

改个按钮颜色不值得用 loop，手动更快。一次写整个项目也不行，AI 会迷失方向。一个可独立验证的功能模块，大约 15-30 分钟的 AI 工作量，是比较合适的粒度。

4. 睡前检查方向，醒后检查质量

loop 的价值在于异步。你睡觉的时候 AI 在干活。但前提是睡前确认 AI 的方向对了。我一般在启动 loop 后会看 2-5 分钟，确认 AI 理解了任务再走。第二天醒来第一件事是代码审查，不是测试通过就完事。

5. 翻车是常态，回退是美德

AI 写烂代码太正常了。在一个错误方向上费劲心思的反复修补是最慢的路。git checkout . 回退，换个 prompt 重新来，往往更快些。

---

九、写在最后

这个项目从零到提交，大约花了 3天。如果纯手写，我估计至少需要1 多月。节省下来的时间，我用在了写设计文档、准备答辩、调整可视化效果上。

对我来说，AI 编程更像是一个不会累、不会抱怨、但需要清晰指令的搭档。它能执行到什么程度，取决于我的设计能力和拆解能力。项目质量的天花板在我这儿，不在它那儿。

---

这是我对我的一个项目的复盘，可能写得还有些粗陋，请海涵。