尧图网页设计 
摘要本文记录了作者借助 AI 辅助完成应用开发的完整流程先向 DeepSeek 提交想法并审查歧义再由 AI 生成施工提示词交给 Codex 执行最后手动核查功能与关联影响。同时文章系统梳理了网页报错排查方法涵盖 HTTP 状态码五大分类与常见状态码含义、浏览器 Network 面板的用法以及如何通过后端日志定位并修复问题。前情提要我的创作过程我在先前做好了整个应用的框架大概的步骤如下将想法给 DeepSeek让他看下我的想法是否有误或者有歧义AI 审查我的想法无误后让他生成提示词返回给施工的 Agent。我深知我手写提示词的能力有限直接将我的问题抛给 AI再让他思考我的做法是否有问题接下来补充他需要的内容例如字体大小、窗格比例、还有其他功能实现的细节。在 AI 完全确认后生成出这一版的最终的提示词丢回给 Codex 施工。在制作项目时我也考虑过 AGENTS.md 该如何维护——仅凭我自己的能力很难用想法持续跟进这份说明文档。于是我将这部分工作也纳入了 AI 生成提示词的环节先把我的需求告诉 AI由它生成能完整落地我思路的提示词再按我的要求把 AGENTS.md 的内容补充进去。这样一来既能实现文档的实时维护也避免了我某次修改时考虑不周而酿成大祸。我再手动核查效果看下是否有问题我通常会从两个方向进行核查一是确认我需要的功能是否已经实现二是检查与之关联的功能是否受到了影响。如果第一个功能没有实现可能是前置环境没有配置好或者上一步生成的提示词存在偏差而如果第二个问题出现则说明 AGENTS.md 需要补充内容或者其中存在纰漏。整个开发流程可以用下面的流程图来概括有无否是是否产生想法将想法交给 DeepSeek 审查想法是否有误或有歧义AI 生成提示词交给 Codex 施工手动核查效果功能是否实现检查前置环境或提示词关联功能是否受影响补充或修正 AGENTS.md完成摘要本节讲解网页报错的排查思路前端功能通过 API 与后端通信遇到报错时先看 HTTP 状态码判断是客户端4xx还是服务器5xx问题再借助浏览器 Network 面板查看实际传输内容最后通过后端日志定位错误时间点、从下往上读 traceback 找到自己的代码并修复。HTTP状态码与网页报错每一个需要读写数据的前端功能通常对应一个或多个 API。API 是前端和后端之间的接口。后端收到 API 请求后可能会调用 iCloud通过 CalDAV也可能只从本地缓存读数据。前端不直接接触 iCloud。所以首先需要了解 HTTP 状态码、筛选窗口和后端日志是什么。API 与函数的层级关系如下图用户看到的功能前端 JS 函数一个 API 请求后端函数可能调用 iCloud也可能不调用说明一个功能可能调用多个 API一个 API 对应一个后端路由。HTTP状态码是服务器在响应里附带的三位数字能告诉客户端这次请求的结果是什么五大分类分类含义谁的问题1xx信息提示临时性很少见2xx成功一切正常3xx重定向资源换地址了4xx客户端错误你请求方的错5xx服务器错误服务器后端/上游的错常见的状态码状态码名字含义常见原因200OK请求成功正常301Moved Permanently永久重定向网址换域名了302Found临时重定向登录后跳转400Bad Request请求格式错误参数少传了、JSON 格式不对401Unauthorized未认证没登录、Token 过期403Forbidden已认证但没权限登录了但访问别人的数据404Not Found资源不存在网址写错、文件被删405Method Not Allowed请求方法不对用 GET 访问了只支持 POST 的接口409Conflict冲突创建了重名的资源412Precondition Failed前提条件不满足ETag 版本对不上你的情况422Unprocessable Entity参数校验失败格式对但值不合法500Internal Server Error后端崩了代码抛了未捕获的异常502Bad Gateway网关/上游无响应后端进程崩了你的情况504Gateway 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 从下往上、定位到自己的代码。整个报错排查流程可以总结为遇到网页报错查看 HTTP 状态码4xx 客户端错误5xx 服务器错误检查请求参数、登录状态、权限查看后端日志找到错误时间点读 traceback 从下往上定位到自己的代码修复问题 【AI实战篇】使用Codex制作读取iPhone日历到window桌面的事务展示工具（二）
摘要本文记录了作者借助 AI 辅助完成应用开发的完整流程先向 DeepSeek 提交想法并审查歧义再由 AI 生成施工提示词交给 Codex 执行最后手动核查功能与关联影响。同时文章系统梳理了网页报错排查方法涵盖 HTTP 状态码五大分类与常见状态码含义、浏览器 Network 面板的用法以及如何通过后端日志定位并修复问题。前情提要我的创作过程我在先前做好了整个应用的框架大概的步骤如下将想法给 DeepSeek让他看下我的想法是否有误或者有歧义AI 审查我的想法无误后让他生成提示词返回给施工的 Agent。我深知我手写提示词的能力有限直接将我的问题抛给 AI再让他思考我的做法是否有问题接下来补充他需要的内容例如字体大小、窗格比例、还有其他功能实现的细节。在 AI 完全确认后生成出这一版的最终的提示词丢回给 Codex 施工。在制作项目时我也考虑过 AGENTS.md 该如何维护——仅凭我自己的能力很难用想法持续跟进这份说明文档。于是我将这部分工作也纳入了 AI 生成提示词的环节先把我的需求告诉 AI由它生成能完整落地我思路的提示词再按我的要求把 AGENTS.md 的内容补充进去。这样一来既能实现文档的实时维护也避免了我某次修改时考虑不周而酿成大祸。我再手动核查效果看下是否有问题我通常会从两个方向进行核查一是确认我需要的功能是否已经实现二是检查与之关联的功能是否受到了影响。如果第一个功能没有实现可能是前置环境没有配置好或者上一步生成的提示词存在偏差而如果第二个问题出现则说明 AGENTS.md 需要补充内容或者其中存在纰漏。整个开发流程可以用下面的流程图来概括有无否是是否产生想法将想法交给 DeepSeek 审查想法是否有误或有歧义AI 生成提示词交给 Codex 施工手动核查效果功能是否实现检查前置环境或提示词关联功能是否受影响补充或修正 AGENTS.md完成摘要本节讲解网页报错的排查思路前端功能通过 API 与后端通信遇到报错时先看 HTTP 状态码判断是客户端4xx还是服务器5xx问题再借助浏览器 Network 面板查看实际传输内容最后通过后端日志定位错误时间点、从下往上读 traceback 找到自己的代码并修复。HTTP状态码与网页报错每一个需要读写数据的前端功能通常对应一个或多个 API。API 是前端和后端之间的接口。后端收到 API 请求后可能会调用 iCloud通过 CalDAV也可能只从本地缓存读数据。前端不直接接触 iCloud。所以首先需要了解 HTTP 状态码、筛选窗口和后端日志是什么。API 与函数的层级关系如下图用户看到的功能前端 JS 函数一个 API 请求后端函数可能调用 iCloud也可能不调用说明一个功能可能调用多个 API一个 API 对应一个后端路由。HTTP状态码是服务器在响应里附带的三位数字能告诉客户端这次请求的结果是什么五大分类分类含义谁的问题1xx信息提示临时性很少见2xx成功一切正常3xx重定向资源换地址了4xx客户端错误你请求方的错5xx服务器错误服务器后端/上游的错常见的状态码状态码名字含义常见原因200OK请求成功正常301Moved Permanently永久重定向网址换域名了302Found临时重定向登录后跳转400Bad Request请求格式错误参数少传了、JSON 格式不对401Unauthorized未认证没登录、Token 过期403Forbidden已认证但没权限登录了但访问别人的数据404Not Found资源不存在网址写错、文件被删405Method Not Allowed请求方法不对用 GET 访问了只支持 POST 的接口409Conflict冲突创建了重名的资源412Precondition Failed前提条件不满足ETag 版本对不上你的情况422Unprocessable Entity参数校验失败格式对但值不合法500Internal Server Error后端崩了代码抛了未捕获的异常502Bad Gateway网关/上游无响应后端进程崩了你的情况504Gateway 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 从下往上、定位到自己的代码。整个报错排查流程可以总结为遇到网页报错查看 HTTP 状态码4xx 客户端错误5xx 服务器错误检查请求参数、登录状态、权限查看后端日志找到错误时间点读 traceback 从下往上定位到自己的代码修复问题