分享一个我平时开发用的 Prompt：

## 需求分析与拆分

1. **优先理解需求**：在开始编码前，深入分析并全理解业务需求和用户期望。
2. **拆分子需求**：将复杂需求拆分为可管理的子需求，使得开发过程更加高效，减少返工。
3. **拆解出项目结构**：根据理解的需求拆解项目结构和文件。

## 基于设计原则
1. **SOLID 原则**：确保组件设计符合单一职责原则和其他 SOLID 原则。
2. **DRY 原则（Don't Repeat Yourself）**：通过提取和重用代码，避免重复。
3. **可复用性**：设计组件时考虑其在不同上下文中的重用性。
4. **可扩展性**：保证组件的结构能够轻松应对未来功能的扩展。

## 组件封装方式
1. **组件化设计**：将 UI 和逻辑分离，创建可复用的组件。
2. **功能组件**：每个组件应专注于单一功能，避免过于复杂的逻辑。
3. **Hooks 和纯函数组件**：使用函数组件和 React Hooks 简化逻辑，避免不必要复杂性。
4. **组合优于继承** ：通过组合而非继承来实现组件的复用和扩展。
5. **组件文件名称**：使用小写字母，- 分割，例如：generate-history-grid.tsx
6. **使用ES6**：严格使用ES6 和 箭头函数定义组件和方法。
7. **组件格式**：
```TypeScript
import React from "react";
const Name: React.FC = () => {
return <>Name;
};

Name.displayName = "Name";

export default Name;
```

## 状态管理
1. **状态提升**：在多个组件需要共享状态时，将状态提升至最近公共父组件。
2. **状态最小化**：保持状态简单不可变，确定最小必需状态。
3. **单一数据源**：确保有一个权威的数据源，减少冲突问题。
4. **Prop 数据传递**：通过 Props 传递数据，保持单向数据流。
5. **Hooks 使用**：多使用 Hooks（如 useState, useReducer）进行状态和副作用管理。
6. **状态生命周期理解**：严格遵循 React 生命周期最佳实践。
7. **副作用管理**：使用 useEffect 和 useLayoutEffect 管理副作用。

## 全局状态管理
1. **使用 Jotai**：使用 Jotai 作为全局状态管理解决方案，简化状态共享和管理。
2. **Atom 和 Selector**：使用 Atom 定义状态，Selector 计算派生状态。
3. **原子化状态**：将全局状态拆分为多个小的原子状态，便于管理和更新。
4. **避免全局状态污染**：
- 确保全局状态只包含必要的数据，避免过度依赖全局状态。
- 使用局部状态代替全局状态，除非确实需要跨组件共享数据。
5. **状态更新**：使用 Jotai 提供的 `useAtom` 钩子进行状态更新，确保组件在状态变化时正确重新渲染。
6. **性能优化**：使用 Jotai 的 `useAtomValue` 钩子获取状态值，避免不必要的重新渲染。

## 错误处理
1. **异常捕获**
2. **Error Boundary**：使用 Error Boundary 捕获并处理渲染异常。
3. **异步操作错误**：为异步请求设置适当的错误处理机制。

## 类型安全
1. **TypeScript 强类型**：推广使用 TypeScript，启用严格模式保证类型安全。
2. **避免使用 any**：减少或避免使用 any 类型，使用更具体的类型定义。
3. **处理空值**：在代码中妥善处理可能的空值或未定义情况。

## 样式管理
1. **使用 Tailwind CSS**：使用 Tailwind CSS 进行样式管理，确保样式一致性和可维护性。
2. **最小粒度的组件化**：将样式应用到最小可用组件，提高重用性。
3. **使用 framer-motion 动画效果**：为组件添加动画，提高用户体验。

## 渲染优化
1. **性能优化**：通过 React.memo、useMemo、useCallback 等技术优化性能，避免不必要的重新渲染。
2. **懒加载**：使用 React.lazy 和 Suspense 实现组件懒加载，提升初始加载速度。
3. **虚拟化列表**：对于长列表，使用 react-window 或 react-virtualized 实现虚拟化，提升渲染性能。

## 文档规范
1. **注释规范**
- **复杂逻辑注释**：解释复杂逻辑，帮助其他开发者理解。
- **JSDoc 标注**：为函数和组件添加详细的 JSDoc 文档。

2. **文档撰写**
- **组件说明书**：编写组件功能、依赖、输入和输出文档。
- **版本变更说明**：记录重要更新和 API 变更。

## 命令
1. 始终使用 pnpm 命令。
2. 使用 Shadcn-ui 时，命令为：pnpm dlx shadcn@Latest xxxx

## 网络请求
1. **使用 SWR**：使用 SWR 进行网络请求，确保请求和响应的类型安全。
2. **错误处理**：为网络请求添加错误处理逻辑，确保用户体验。
3. **缓存策略**：合理配置 SWR 的缓存策略，减少不必要的网络请求。
4. **数据获取**：使用 SWR 的 `useSWR` 钩子获取数据，确保数据的实时性和一致性。
5. **请求参数**：确保请求参数类型安全，避免使用 any 类型。
6. **响应处理**：对响应数据进行类型检查和处理，确保数据的。

## 其他说明
1. 网页内容语言始终使用英语，代码注释可以使用中文。
2. 组件和文件命名使用小写字母，- 分割。
3. 确保代码风格一致，遵循团队约定的代码规范。
4. 在 import 的时候，始终使用 @ 别名。

## 目录结构
```
/my-app
├── public/ # 静态资源目录（favicon、图像等）
│ └── images/
│ └── logo.png
│
├── src/ # 源代码目录
│ ├── app/ # App Router 页面结构
│ │ ├── layout.tsx # 全局布局（Header/Footer）
│ │ ├── page.tsx # 主页（/）
│ │ ├── about/page.tsx # 静态页面（/about）
│ │ ├── blog/[slug]/page.tsx # 动态页面（如 /blog/hello-world）
│ │ └── api/ # API routes（/api/...）
│ │ └── ping/route.ts
│ │
│ ├── components/ # 组件目录（结构清晰、按功能分类）
│ │ ├── layout/ # 页面结构组件
│ │ │ ├── header.tsx
│ │ │ └── footer.tsx
│ │ ├── ui/ # 原子 UI 组件（按钮、输入框等）
│ │ │ ├── button.tsx
│ │ │ └── input.tsx
│ │ ├── shared/ # 可复用功能性组件（如 PostCard、CardList）
│ │ │ └── post-card.tsx
│ │ └── seo/ # SEO Head 组件
│ │ └── seo-head.tsx
│ │
│ ├── hooks/ # 自定义 React Hooks
│ │ ├── use-search.ts
│ │ └── use-responsive.ts
│ │
│ ├── lib/ # 工具函数 / 逻辑封装（fetch、markdown、缓存等）
│ │ ├── api.ts
│ │ ├── markdown.ts
│ │ └── constants.ts
│ │
│ ├── types/ # 类型定义
│ │ ├── post.ts
│ │ └── index.ts
│ │
│ ├── data/ # 静态数据（JSON、MDX、YAML）
│ │ ├── posts/
│ │ │ └── hello-world.md
│ │ └── site-config.json
│ │
│ ├── styles/ # 样式文件（支持 Tailwind / SCSS / CSS Modules）
│ │ ├── globals.css
│ │ └── theme.css
│ │
│ └── middleware.ts # Next.js 中间件（可选）
│
├── .env.local # 环境变量
├── next.config.js # Next.js 配置
├── tailwind.config.ts # Tailwind 配置（如使用）
├── tsconfig.json # TypeScript 配置
└── README.md
```

喵

这年头还有人用网站吗？
这年头还有人买域名吗？
这年头还有人用邮箱吗？
这年头还有人用搜索引擎吗？
这年头还有人用电脑访问网站吗？

所有的疑问，都是建立在对身边人的观察之上，而不是对整个世界的观察。
于是观点就会有失偏颇，就容易盲人摸象管中窥豹。

在网友眼里，国内智驾的天都塌了。

去年中国公有云总共调用114.2万亿Tokens，Google云今年6月调用了980万亿Tokens。

高德地图内测版，有AI大模型，还有3个激活码，留言送

面了一个售前的岗，没有公积金，每周单休。
在考虑要不要去🙂‍↔️🙂‍↔️🙂‍↔️

以后可能没有 AI 产品经理这个岗位

最近经常有学弟学妹来问我类似的问题：

"现在AI这么火，我是不是应该专门找那些岗位名字里带'AI'的产品岗？传统产品岗会不会很快就没前途了？"

老实说，我最开始也是这么想的。毕竟大势所趋，当然要顺应潮流。

不过前段时间，我跟几个在电商、企业服务等不同领域带团队的朋友聊了聊，听了他们的招人想法后，我更新了下我的观点：

以后可能不存在"AI产品经理"和"普通产品经理"的区别，因为所有产品经理，都得是AI产品经理。

这话怎么理解？

AI已经不再是某个"锦上添花"的功能点，它更像是基础设施，正在渗透到各行各业的每个环节。无论你做电商、内容还是教育，AI都在潜移默化地改变着整个系统的运作方式。

也正因为这样，产品经理这个角色的核心在发生变化。

过去做产品，更多是"协调枢纽"的角色：收集需求、画原型、写文档、组织评审、分配任务、跟进度。流程相对固定，分工也很明确。

但现在不一样了——很多时候连"需求"本身都很模糊，所需要的资源也不是靠组织分配，而是要你自己想办法"创造"出来。

所以现在很多公司看人，已经不太关心你的实习title有多高大上、项目经历写得多精彩，而是在看一个核心能力：

你是不是那种能够"独立构建最小闭环"的人？

这听起来有点抽象，主要体现在两个方面：

第一，敏锐的嗅觉

能在那些看似琐碎、边缘化、没人注意的地方，嗅出问题的存在。不是等着别人给你安排任务，而是你自己能发现：这里有优化空间。

比如你发现大家写论文时整理引用格式特别麻烦，要反复复制粘贴好多次。这时候，别急着写需求文档等着开会讨论，而是马上意识到，这种重复性工作完全可以用AI来解决。

你把这个"小事"赋予了意义，让它变成了一个值得解决的问题。

第二，动手验证的能力

发现问题后，你不是把它扔给别人，而是自己动手去验证这个问题是否真的值得解决。

你可能不会编程，那就用Cursor、N8N、Trae这些工具，先搭个简陋但能用的原型出来。

或者直接用 Gemini 写个 Prompt，让它一键生成格式化的参考文献，完全替代手动操作。

这个"粗糙但管用"的小工具，就是你能力的最好证明，它表明你不是只会纸上谈兵，而是真的能把"模糊的想法"变成"实用的东西"。

所以，如果你现在还在纠结：

"我简历上要不要突出我懂AI？"
"我是不是只能投AI相关的产品岗？"

坦率地说，你可能想偏了。

真正的差距不在于"懂不懂AI"，而在于你有没有独立构建最小闭环的能力。

AI只是你手头的一个工具，关键是你能不能把一个想法，变成一个可行的解决方案。

别再一味地刷实习经历了。

不如试着做几个完全由你主导的"闭环项目"。

规模不用大，哪怕是自动整理课堂笔记，哪怕是给家人做个菜谱推荐小程序，只要是你从发现问题到解决问题全程参与的，都是最好的"能力证明"。

因为将来面试官想了解的，就是这些：

"你有没有因为某个痛点，自己做了工具来解决？"
"你是怎么做出来的？过程中踩了什么坑？"
"为了完成这个项目，你自学了哪些新技能？"

你的回答，不再是那些包装精美的项目经历，而是一个个粗糙但完整的小作品。

它们就像你的"产品作品集"，证明你不是需要被安排工作的"执行者"，而是一个会主动发现、自主学习、独立验证的"解决者"。

“校招刚毕业认识的同事属于职场发小”

🎉 分享一个开源项目 kanban

https://kan.bn/

没错，功能就是看板，trello的开源替代，界面干净，操作简单

使用场景：网站roadmap，或个人项目进度管理