# AI 编码工具提示词记录 本文档整理了在各种 AI 编码工具（Cursor、Claude Code、Codebuddy）中使用过的用户提示词，供参考和复用。 --- ## 问题定位与调试 ### 移动端生图问题 ``` 生图模型nbp4k-async 在移动端 Chrome，未能落 LLM API 日志，并且每次进度总是到 90%，无法生成，感觉没有真正发出请求。仔细定位并修复，可以加点日志定位 ``` ### 工作流调试 ``` 从AI输入框发送到工作流执行完成的核心链路加上debugger，我要调试一下为什么工作流未能正常执行，请求未能发送出去 ``` ### SW Debug 页面 Fetch 日志 ``` 现在/sw-debug.html未能捕获到任何Fetch 请求日志 还是没有，应该是service worker中没有正确记录吧 还是没有，或许可以加点日志定位。还有一个很奇怪的问题，主应用页面刷新会导致/sw-debug.html页面也刷新是怎么回事 ``` ### 页面白屏问题 ``` 现在应用页面无法正常加载 取消Update on reload后，页面一直在刷新 ``` --- ## 代码清理与优化 ### 清理遗留代码 ``` 仔细 review 项目代码把没用到的代码或者遗留代码清理干净，把调试 console 清理干净 ``` ### 代码精简优化 ``` 目前项目代码臃肿，存在大量重复代码或未被使用的代码，想办法对代码进行精简优化，并提升加载性能，注意不能变更原逻辑 ``` ### 日志清理 ``` /sw-debug.html?tab=gist页面中，Gist管理中的日志同步，希望能复用控制台日志展示组件 [GitHubApiService] Updating 1 files, total size: 92.87 KB sw-console-capture.ts:203 [SyncEngine] Initializing sharding system for gistId: 2ef6...44c1 像这类同步相关的日志，不要在控制台打印，落在gist的同步日志中即可 ``` --- ## 功能开发 ### Gist 同步日志功能 ``` gist的同步日志增加复制按钮，最好事实展示日志，点击错误、告警、成功可以对数据经行筛选。gist的数据诊断没有任何数据，仔细定位 ``` ### 数据诊断功能 ``` 数据诊断点击任务对比、画板对比远程数据等都没数据。同时同步日志需要点击刷新才能看到新数据，应该有自动刷新的逻辑 ``` ``` 数据诊断所有数据都是0 希望自动获取并解密 GitHub Token 以及获取远程数据 ``` --- ## 架构重构 ### postmessage-duplex 双工通信 ``` 使用https://www.npmjs.com/package/postmessage-duplex 双工通讯工具，改造 service worker 和应用层通信，解决同时打开多个页面任务重复添加等问题 ``` ``` 既然已经用postmessage-duplex替换掉原有的通讯机制，应该把旧代码删除掉 ``` ``` 仔细 review 当前分支的代码变更，充分发挥 postmessage 双工通讯的优势，简化通信流程，优化代码逻辑。现在应用层加载白屏也许修复。 ``` ### SW 降级处理 ``` 任务和工作流已经把依赖 sw 的地方改成可降级，仔细检查其他地方，还有没有需要可降级的地方需要调整，确保在 sw 未准备好的时候能够工作 ``` --- ## Gist 同步优化 ### Gist 分片存储自动选择 ``` 由于现在采用了分片存储 gist，因此在配置 gist 的 token 后，需要能自动选择主 gist，这样就不允许用户手动切换 gist 了 ``` ### Gist 同步策略优化 ``` 仔细 review 基于gist 进行数据同步的代码。当前项目是一个纯前端的项目，希望借助 gist 使项目具有后端的数据同步能力。梳理项目中数据同步的策略，探索可能优化的地方。有一个明确可以优化的地方是每次 30 秒自动同步当前画布图片的时候，对于缓存中不存在的图片都会重新请求，这是没有必要的，因为缓存中没有本身就意味着请求失败，没必要再失败一次。 ``` ### 文件名过长问题 ``` GitHubApiError: 文件名过长: 359 字符 url的base64容易超长，换成hash吧，shard-manifest.json等文件非图片的base64编码都应加密 ``` --- ## 模块提炼 ### 工具函数提炼 ``` 仔细 review@packages/drawnix/src/utils 看有哪些可以作为公共方法提炼到@packages/utils 并添加单测 ``` ### 工作流能力提炼 ``` 能否把工作流相关能力提炼出来放到@packages/utils 中，并添加完善的单元测试确保无误 ``` ``` @packages/utils/package.json 应要有测试的命令 ``` ``` 在@packages/utils/src/workflow下添加原理、流程、使用 文档 ``` ``` @types.ts (24-35) 工作流的核心是这个数据结构，和执行工作流的方法，而相关的能力似乎未被提炼过来，文档也未提及 ``` ``` export type { ToolCall, WorkflowJsonResponse } from '@aitu/utils';避免二次导出，在用到的地方直接引入 ``` ``` 工作流似乎少了上下文和递归调用的介绍。比方说每一个next元素的返回都可以添加上下文信息，并且next元素的返回如果不是null的话，就是一个工作流的数据，支持递归调用 ``` ``` 增加对代码结构和阅读顺序的结束 ``` --- ## 快速修复指令 ### TypeScript 错误修复 ``` For the code present, we get this error: Type number trivially inferred from a number literal, remove type annotation. Fix it, verify, and then give a concise explanation. @packages/utils/src/format/index.ts:22-25 ``` ### LLM API 日志字段支持 ``` 不能简单得删掉，remoteId 和 errorMessage 还是有意义的，应当在LLM API 中支持展示 ``` --- ## 文档更新 ### 更新 CLAUDE.md ``` /update-claude-md ``` ### Git 操作 ``` 提交 推送到远程 ``` --- ## 提示词模式总结 ### 问题定位模式 ``` [问题描述]，仔细定位并修复，可以加点日志定位 ``` ### 代码审查模式 ``` 仔细 review [范围] 的代码变更，[优化目标] ``` ### 功能增强模式 ``` [现有功能] 增加 [新能力]，[具体要求] ``` ### 模块提炼模式 ``` 能否把 [功能] 相关能力提炼出来放到 [目标位置]，并添加完善的单元测试确保无误 ``` ### 降级处理模式 ``` [已处理的部分] 已经改成可降级，仔细检查其他地方，还有没有需要可降级的地方需要调整，确保在 [异常情况] 能够工作 ``` ### 快速修复模式 ``` For the code present, we get this error: [错误信息] Fix it, verify, and then give a concise explanation. @[文件路径:行号] ``` --- ## 常用 Slash 命令 | 命令 | 说明 | |------|------| | `/update-claude-md` | 更新 CLAUDE.md 文档规则 | | `/auto-commit` | 自动分析变更并提交 | | `/commit-push-pr` | 一键提交、推送、创建 PR | | `/fix-and-validate` | 自动修复代码问题并验证 | | `/validate` | 运行完整验证流程 | --- --- ## Claude Code 提示词 ### 代码审查与优化 ``` review当前分支的修改,优化不合理的地方修复可能的问题 ``` ### 日志清理 ``` 删除所有[SWChannel]调试日志 ``` ### 问题定位 ``` 还是没有正确执行,加点日志定位 ``` ``` installHook.js:1 [SWChannel] [ServiceWorkerChannel](page): Invalid message structure: Message must have requestId, cmdname, or msg field sw-console-capture.ts:125 [SWChannel] [ServiceWorkerChannel](page): onMessage {type: 'SW_DEBUG_NEW_CRASH_SNAPSHOT', snapshot: {…}} 这里似乎陷入了死循环 ``` ### 架构分析 ``` 按道理已经使用postmessage-duplex,不应该再有addEventListener('message'类似的消息监听,这2种处理方式冲突了 ``` ``` 还是死循环了,可能 console 的消息通过 postmessage 发送给 service worker 而 postmessage 中又有 console,所以存在死循环 ``` ### 功能优化 ``` 用了新的方式处理 postmessage, /sw-debug.html 的 PostMessage日志 处理方式可以优化一下,因为现在 service worker 通信可以区分应用页面了,可以标注出是跟哪个应用进行通信 ``` ### 白屏问题 ``` [SW Console Capture] 已初始化 index.ts:77 Service Worker v0.5.63 installing... index.ts:77 Service Worker: Cannot load precache-manifest.json, skipping precache installHook.js:1 [MemoryLog] 白屏检测: 画板组件未加载 现在进入应用白屏 ``` ### 错误处理探索 ``` 探索这个项目中处理 API 错误的代码结构，特别是： 1. 找到 apiCalls.ts 中 onError 处理的位置和逻辑 2. 找到设置对话框（SettingsDialog）的打开方式和相关状态管理 3. 找到 DrawnixContext 或其他全局状态管理中控制对话框显示的方法 4. 查看 workflow-submission-service.ts 中错误处理的逻辑 5. 查看是否有现有的全局错误提示机制（如 toast/notification） 需要了解： - 如何从 Service Worker 或 API 层触发主线程的 UI 变化 - 设置对话框是如何被打开的 - 是否有现有的事件机制来处理这种跨层级的通信 请返回相关文件路径和关键代码片段。 ``` ### 技术问答 ``` servise worker会对所有兄弟域名或子域名生效吗 ``` --- ## AI 编码工具配置目录 | 工具 | 全局配置目录 | 对话历史位置 | |------|------------|-------------| | Cursor | `~/.cursor/` | `~/.cursor/projects/{project}/agent-transcripts/` | | Claude Code | `~/.claude/` | `~/.claude/projects/{project}/*.jsonl` | | Codebuddy | `~/.codebuddy/` | `~/.codebuddy/projects/{project}/*.jsonl` | --- *最后更新: 2026-02-05*