摘要：本文记录了作者借助 AI 辅助完成应用开发的完整流程：先向 DeepSeek 提交想法并审查歧义，再由 AI 生成施工提示词交给 Codex 执行，最后手动核查功能与关联影响。同时，文章系统梳理了网页报错排查方法，涵盖 HTTP 状态码五大分类与常见状态码含义、浏览器 Network 面板的用法，以及如何通过后端日志定位并修复问题。
前情提要：我的创作过程
我在先前做好了整个应用的框架，大概的步骤如下
将想法给 DeepSeek，让他看下我的想法是否有误或者有歧义
AI 审查我的想法无误后，让他生成提示词返回给施工的 Agent。
我深知我手写提示词的能力有限，直接将我的问题抛给 AI，再让他思考我的做法是否有问题，接下来补充他需要的内容，例如字体大小、窗格比例、还有其他功能实现的细节。
在 AI 完全确认后生成出这一版的最终的提示词，丢回给 Codex 施工。
在制作项目时，我也考虑过 AGENTS.md 该如何维护——仅凭我自己的能力，很难用想法持续跟进这份说明文档。于是我将这部分工作也纳入了 AI 生成提示词的环节：先把我的需求告诉 AI，由它生成能完整落地我思路的提示词，再按我的要求把 AGENTS.md 的内容补充进去。这样一来，既能实现文档的实时维护，也避免了我某次修改时考虑不周而酿成大祸。
我再手动核查效果，看下是否有问题
我通常会从两个方向进行核查：一是确认我需要的功能是否已经实现，二是检查与之关联的功能是否受到了影响。如果第一个功能没有实现，可能是前置环境没有配置好，或者上一步生成的提示词存在偏差；而如果第二个问题出现，则说明 AGENTS.md 需要补充内容，或者其中存在纰漏。
整个开发流程可以用下面的流程图来概括：
摘要：本节讲解网页报错的排查思路：前端功能通过 API 与后端通信，遇到报错时先看 HTTP 状态码判断是客户端（4xx）还是服务器（5xx）问题，再借助浏览器 Network 面板查看实际传输内容，最后通过后端日志定位错误时间点、从下往上读 traceback 找到自己的代码并修复。
HTTP状态码与网页报错
每一个需要读写数据的前端功能，通常对应一个或多个 API。
API 是前端和后端之间的接口。
后端收到 API 请求后，可能会调用 iCloud（通过 CalDAV），也可能只从本地缓存读数据。
前端不直接接触 iCloud。
所以首先需要了解 HTTP 状态码、筛选窗口和后端日志是什么。
API 与函数的层级关系如下图
说明：一个功能可能调用多个 API，一个 API 对应一个后端路由。
HTTP状态码
是服务器在响应里附带的三位数字，能告诉客户端这次请求的结果是什么
五大分类
| 分类 | 含义 | 谁的问题 |
|---|---|---|
| 1xx | 信息提示 | 临时性，很少见 |
| 2xx | 成功 | 一切正常 |
| 3xx | 重定向 | 资源换地址了 |
| 4xx | 客户端错误 | 你（请求方）的错 |
| 5xx | 服务器错误 | 服务器（后端/上游）的错 |
常见的状态码
| 状态码 | 名字 | 含义 | 常见原因 |
|---|---|---|---|
| 200 | OK | 请求成功 | 正常 |
| 301 | Moved Permanently | 永久重定向 | 网址换域名了 |
| 302 | Found | 临时重定向 | 登录后跳转 |
| 400 | Bad Request | 请求格式错误 | 参数少传了、JSON 格式不对 |
| 401 | Unauthorized | 未认证 | 没登录、Token 过期 |
| 403 | Forbidden | 已认证但没权限 | 登录了但访问别人的数据 |
| 404 | Not Found | 资源不存在 | 网址写错、文件被删 |
| 405 | Method Not Allowed | 请求方法不对 | 用 GET 访问了只支持 POST 的接口 |
| 409 | Conflict | 冲突 | 创建了重名的资源 |
| 412 | Precondition Failed | 前提条件不满足 | ETag 版本对不上（你的情况） |
| 422 | Unprocessable Entity | 参数校验失败 | 格式对但值不合法 |
| 500 | Internal Server Error | 后端崩了 | 代码抛了未捕获的异常 |
| 502 | Bad Gateway | 网关/上游无响应 | 后端进程崩了（你的情况） |
| 504 | Gateway Timeout | 上游超时 | 后端请求 iCloud 时间太长 |
这样就可以根据返回的状态码，锁定错误的区域，更便于我们修改。
浏览器开发者工具（Network 面板）
是浏览器内置的调试工具，能看到浏览器和服务器之间实际传输了什么内容。
后端日志
后端程序运行时打印出来的信息，能记录下来正在做什么，还有遇到了什么错。
127.0.0.1 - - [28/Sep/2026 12:19:27] "GET / HTTP/1.1" 200 - 127.0.0.1 - - [28/Sep/2026 12:19:27] "GET /api/events HTTP/1.1" 200 - 客户端 IP - 用户 - [时间] "请求方法 路径 协议" 状态码 响应大小^正常日志
Traceback (most recent call last): ← 固定开头 File "app.py", line 997, in update_event ← 你的代码（外层） old_calendar, _ = find_event_by_uid(...) File "app.py", line 727, in find_event_by_uid ← 你的代码（内层） event = calendar.event_by_uid(uid) File ".../caldav/collection.py", line 2095 ← 库的内部 ... File ".../caldav/davobject.py", line 280 ← 库的最底层 raise error.exception_by_method[...] caldav.lib.error.ReportError: ... ← 真正的错误^错误日志
后端日志是后端程序的“工作记录”，记录了它收到的每个请求、执行的每一步、遇到的每个错误。前端只能看到结果，日志才能看到原因。看日志的核心是：找到错误时间点、读 traceback 从下往上、定位到自己的代码。
整个报错排查流程可以总结为：
