@shugarDadddy: 在启动你的 vibe coded 项目之前，先运行这个提示：“对应用程序进行全面审计，涵盖…

在启动你的“氛围编码”项目之前，请先运行以下提示：

“对应用程序进行全面审计，涵盖安全性、可靠性、并发性、可访问性和UI一致性。

审查相关代码库、架构、数据流、API交互、身份验证和授权逻辑、状态管理、异步操作、错误处理以及面向用户的界面。端到端追踪重要流程，而不是孤立地审查文件。

具体调查以下内容：

安全漏洞和数据泄露

• 身份验证和授权缺陷，包括缺失的服务端权限检查、权限提升、不安全的直接对象引用以及跨租户数据访问。

• 通过客户端代码、环境变量、API响应、日志、分析工具、URL、本地存储、会话存储、Cookie、错误消息或源映射暴露的敏感信息。

• 注入风险，包括适用的SQL注入、命令注入、模板注入、提示注入、HTML注入和脚本注入。 XSS、CSRF、SSRF、不安全的重定向、不安全的文件上传、路径遍历、脆弱的会话处理、不安全的令牌存储以及缺失的安全边界。

• 过于宽松的数据库规则、API端点、CORS策略、存储桶、webhook处理程序或第三方集成。

• 可能无意中暴露的秘密、API密钥、凭据、内部端点、个人数据或实现细节。

• 在信任边界处缺失验证和清理。不要假设客户端验证就足够。

竞态条件、并发性和状态完整性

• 由重复点击、重试、刷新或并发请求导致的重复提交。

• 非幂等操作，可导致重复的记录、支付、消息、预订、任务或副作用。

• 过期状态、乐观更新失败、丢失的更新、冲突写入以及乱序的异步响应。

• 未正确清理的效果、订阅、监听器、定时器和请求。

• 操作正在进行时，UI状态中仍然可用的操作。

• 缓存失效问题，以及客户端状态、服务器状态和持久化数据之间的不一致。

• 相关场景下的多标签、多设备和弱网络情况。

可靠性和故障处理

• 未处理的Promise拒绝、被吞噬的错误、静默失败、无限加载状态、损坏的重试循环以及不完整的回滚行为。

• 缺失的加载、空、错误、离线、超时和部分成功状态。

• 导致数据或UI处于不一致状态的故障路径。

• 关于API响应、可空性、顺序、时序或网络可用性的假设，这些假设可能在生产环境中导致故障。

• 内存泄漏、不必要的重新渲染、昂贵的操作以及明显影响用户体验的性能瓶颈。

可访问性

• 语义化HTML以及地标、标题、标签、列表、表格、按钮和链接的正确使用。

• 键盘导航、逻辑Tab顺序、焦点可见性、焦点捕获和焦点恢复。

• 缺失或不正确的可访问名称、标签、描述和ARIA属性。

• 颜色对比度、文本清晰度、触摸目标大小、缩放行为、减少动效支持以及仅靠颜色传达含义。

• 屏幕阅读器对模态框、菜单、下拉菜单、标签页、提示消息、验证错误、加载状态和动态更新内容的行为。

• 表单缺少明确说明、不可访问的验证、缺失的自动完成属性或较差的错误恢复。

• 在适用的情况下，根据WCAG 2.2 AA期望进行测试。

视觉和交互一致性

• 不一致的间距、排版、颜色使用、边框半径、阴影、图标大小、对齐、组件尺寸和响应行为。

• 看起来完全相同但行为不同的组件，或者行为相同但实现不一致的组件。

1/2

• 设计令牌和共享组件的使用不正确或不一致。

• 缺失或不一致的悬停、聚焦、激活、选中、禁用、加载、成功、警告、破坏和错误状态。

• 布局偏移、裁剪、溢出、截断、换行问题、断点问题以及不一致的空状态。

• 文案不一致、术语漂移、大小写不一致、标点、日期格式、数字格式和操作标签。

响应式和边缘情况行为

• 检查窄屏幕手机、平板、桌面布局、异常宽的屏幕、缩放界面和大文本设置。

• 检查长名称、长电子邮件地址、翻译或展开的文本、空值、非常大的数据集、零结果状态以及格式错误或意外的内容。

• 识别仅适用于理想内容或特定视口大小的假设。

对于发现的每个问题，请报告：

• 严重程度：致命、高、中、低或参考信息
• 类别：安全、竞态条件、可靠性、可访问性、性能或视觉一致性
• 位置：确切的文件、组件、函数、端点或流程
• 问题：问题是什么
• 影响：在生产环境中实际可能发生什么
• 证据：支持发现的代码路径、行为或可复现条件
• 复现步骤：在适用的情况下，触发或验证问题的明确步骤
• 推荐的修复方案：具体的、技术上可行的补救措施
• 置信度：已确认、高置信度或需验证

按实际影响和可利用性对发现进行优先级排序。区分确认的漏洞与理论上的担忧，避免报告没有证据的推测性问题。

在初始审计期间不要修改代码。首先按严重程度和类别分组生成完整的发现报告。报告之后，提供：

一个按优先级排序的修复计划。 一份低回归风险、可安全修复的快速获胜清单。 一份需要架构更改或更深入调查的问题清单。 一份简洁的发布建议：可以安全发布、已知风险下发布、或不要发布，并附上理由。

在安全审查中要具有对抗性，在可访问性审查中要系统化，在UI审查中要精确。不要将审计局限于明显的linting或样式问题。追踪实际的用户流程和故障场景，挑战假设，并识别在真实用户、不可靠网络、并发操作和恶意输入下可能出现的问题。

有效。通常我会用Claude写代码，用codex做审计。这样能最大程度减少代理偏差。

明白。我会在把它做成技能时包含这个。谢谢。

好问题。 进行这项检查的原因是为了确保产品的安全性和合规性，最大限度地减少奇怪问题和陷阱的发生。

再告诉我更多。

赞同！

如果你用的是Claude Pro计划，请不要使用。

我也很惊讶。我每完成3个功能就运行一次，以确保安全。