第八章 工作场景实战

一、本章使用方法

延续 第七章 的"5 块"结构。但相比生活场景，工作场景多一个考虑：这东西到底安全吗？我能在公司用吗？

每个案例最后会给你一份"公司适用性评估"。

二、案例 1：批量改文件名 / 批量处理 PDF

2.1 它解决什么

200 个发票 PDF 命名乱七八糟，财务要你"按日期重命名 + 提取金额合计"。 500 张产品图命名是 IMG_2841.JPG，运营要你按 产品名_主图_01.jpg 重命名。

手动一小时干不完一半。

2.2 做完后你能得到什么

batch-tools/ 目录：

• rename-photos.py — 按 EXIF 拍摄时间 + 自定义前缀批量改图片名。
• pdf-extract-amount.py — 批量从 PDF 提取金额，生成汇总 CSV。
• pdf-merge.py — 多 PDF 合并成一个。
• pdf-split.py — 大 PDF 按页范围拆分。

2.3 完整提示词

新建 batch-tools/：

我要做一组"批量处理"的 Python 工具，给上班族用。

【工具 1：rename-photos.py】
扫描指定文件夹里的所有图片（jpg / jpeg / png / heic），
按 "<前缀>_<拍摄日期 YYYY-MM-DD>_<序号 3 位>.jpg" 重命名。
- 拍摄日期从 EXIF 读，没有就用文件修改时间。
- 序号按"同一天内"重排（每天从 001 开始）。
- 用 --prefix 参数指定前缀（默认空字符串）。
- 用 --dry-run 模式只打印不改名。
- 跑：python3 rename-photos.py --path ./images --prefix "iphone-photo"

【工具 2：pdf-extract-amount.py】
扫描指定文件夹里所有 PDF，提取每份的"总金额 / 发票号 / 开票日期"，
生成 amounts.csv（列：文件名、总金额、发票号、开票日期、是否提取成功）。
- 用 pdfplumber 读 PDF 文本。
- 金额规则：找 "￥123,456.78" 或 "金额 12345"。
- 发票号：找 "发票号码: 12345678" 或 "No.12345678"。
- 没找到的填 N/A。
- 跑：python3 pdf-extract-amount.py --path ./invoices

【工具 3：pdf-merge.py】
把指定文件夹里所有 PDF 合并成一个。
- 按文件名字母顺序合并。
- 输出 merged.pdf。
- 用 PyPDF2。
- 跑：python3 pdf-merge.py --path ./parts --output merged.pdf

【工具 4：pdf-split.py】
把一个大 PDF 按页范围拆分成多个。
- 跑：python3 pdf-split.py --input big.pdf --ranges "1-5,6-10,11-end"
- 输出：big_part1.pdf / big_part2.pdf / big_part3.pdf。

【约束】
- 4 个独立单文件 .py 脚本，互不依赖。
- 依赖：pillow、pdfplumber、PyPDF2（在 requirements.txt 列出）。
- 全部支持 --dry-run。
- 全部用 argparse + 中文 help 文本。

请直接生成这 4 个文件 + requirements.txt + 一份 README.md（中文，给完全不会 Python 的同事看）。

2.4 运行方式

pip install -r requirements.txt
python3 rename-photos.py --path ./test --dry-run

2.5 避坑要点

• PDF 是图片型（扫描件）的没法提取文本：让 Cursor 加 OCR 选项（用 pytesseract），但要单独跑命令装。
• 批量改名出错回不去：让 Cursor 在每次改名前生成一个 rename-log.json，可以用 --undo 反转。
• PDF 合并后顺序错：自然排序 vs 字典排序——file2.pdf 会在 file10.pdf 后面。让 Cursor 用 natsort 库或者自己实现自然排序。

2.6 公司适用性

✓ 完全本地，无网络请求。 ✓ 不上传任何数据。 ✓ 适合所有公司使用。

三、案例 2：销售客户跟进表

3.1 它解决什么

复刻 00 序言 里小王的故事——把多份散乱的数据合成一份漂亮的客户跟进表。

3.2 做完后你能得到什么

crm-weekly/ 目录：

• 输入：客户主表 CSV + 上周聊天记录 CSV + 合同 PDF 文件夹。
• 输出：weekly_report.html —— A 类 / B 类 / C 类客户分组、按金额排序、超 21 天未联系标红、回款逾期标"催收"。

3.3 完整提示词

新建 crm-weekly/，把示例数据放进 data/ 子目录：

做一份每周客户跟进报表生成器。

【输入数据】
- data/clients.csv：列名 客户ID / 客户名 / 联系人 / 行业 / 合同金额 / 上次联系日期 / 回款应到期日 / 回款实到期日 / 状态
- data/chats.csv：列名 客户ID / 时间 / 内容（一周内的聊天记录）
- data/contracts/：内含若干合同 PDF（文件名 = 客户名.pdf）

【输出】
weekly_report.html，单文件，能直接发邮件。

【内容】
1. 顶部统计卡：本周新增客户、本周回款、未回款总额、即将逾期客户数。
2. 主表（按合同金额从高到低排序）：
   列：客户名 | 类别 | 合同金额 | 上次联系（X 天前）| 回款状态 | 本周聊天总结 | 备注
3. 类别规则：
   - A 类：合同金额 ≥ 50 万
   - B 类：10 万 ≤ 金额 < 50 万
   - C 类：金额 < 10 万
4. 行高亮规则：
   - 上次联系 > 21 天：背景淡黄
   - 上次联系 > 30 天：背景淡红
   - 回款应到期日已过且未回款：备注列写"催收"
5. 本周聊天总结：从 chats.csv 里取该客户本周所有聊天，
   合并成一段话（不超过 60 字），放在该客户行的"本周聊天总结"列。
6. 顶部加目录锚点：点 A 类 / B 类 / C 类滑到对应分组。

【技术】
- Python 脚本 generate_report.py。
- 用 pandas 读 CSV，jinja2 渲染 HTML。
- 单文件 HTML（CSS 内联，不依赖外部资源）。
- 中文界面。
- 风格：Linear / Stripe 简洁感，不要花哨配色。

【运行】
- python3 generate_report.py
- 默认读 data/，输出 weekly_report.html。

【特别要求】
- 没有"本周聊天"的客户，"本周聊天总结"列写"无"。
- 合同 PDF 暂不提取（v2 再做），只在备注列写"合同：xxx.pdf"链接。

先列方案。

3.4 运行方式

pip install pandas jinja2
python3 generate_report.py
open weekly_report.html

3.5 避坑要点

• CSV 编码不一致：可能 UTF-8、可能 GBK。让 Cursor 自动检测（chardet 库或者尝试两次）。
• 聊天总结太僵硬：v1 用拼接，v2 可以接 LLM 做摘要（案例 4 周报生成 会用到）。
• 客户名不一致：CRM 里写"上海某某科技"，聊天记录里写"某某"。让 Cursor 加一个"客户别名表"。

3.6 公司适用性

⚠ 客户数据是敏感信息，全程本地跑，不调外部 API 即可。 ⚠ 如果公司有数据安全审计，让 IT 看一眼脚本（很短，10 分钟看完）。 ⚠ 输出的 HTML 不要随意发到群里（注意权限）。

四、案例 3：会议纪要自动生成

4.1 它解决什么

每次开完会，整理纪要要花 30-60 分钟。整理出来还经常被同事吐槽"漏了个关键决策"。

4.2 做完后你能得到什么

meeting-notes/ 目录：

• 输入：会议转写文本（从腾讯会议、飞书会议等导出的 .txt）。
• 自动识别"决议 / 待办 / 风险 / 后续讨论"四类。
• 输出：格式化的 markdown，可以直接发到群里。

4.3 完整提示词

新建 meeting-notes/：

做一个会议纪要整理工具。

【输入】
- 拖一个 .txt 文件进网页（会议转写文本，可能几千到几万字）。
- 也可以粘贴文本进文本框。

【处理】
- 调 LLM API 处理（用户填自己的 API Key，存 localStorage）。
- 默认 OpenRouter 兼容协议，支持 OpenAI / Claude / DeepSeek 切换。
- 把转写文本切分成带时间戳的"句子"。
- 让 LLM 提取四类信息：
  1. 决议（最终拍板的决定）
  2. 待办（动作 + 责任人 + 截止日）
  3. 风险（提到的潜在问题 / 阻塞）
  4. 后续讨论（没拍板，下次再聊）

【输出】
一份 markdown 纪要：

# 2026-04-19 周会纪要
**与会**：张三、李四、王五
**时长**：60 分钟

## 决议
- 决议 1：...
- 决议 2：...

## 待办
- [ ] @张三 完成 X 文档（截止 4-26）
- [ ] @李四 找供应商报价（截止 4-30）

## 风险
- 风险 1：Y 项目可能延期，原因是...

## 后续讨论
- 议题 1：...
- 议题 2：...

## 完整转写
（折叠，点击展开查看）

【UI】
- 单页应用，三个文件 index.html / style.css / app.js。
- 顶部一个超大粘贴区。
- 底部"开始整理"按钮。
- 整理中显示进度（流式渲染）。
- 整理完一键复制 markdown 到剪贴板。
- 设置面板：API Key / API Base URL / 模型名。

【约束】
- API Key 只存 localStorage，不上传。
- 大文件（> 10 万字）自动分段调用，最后合并。
- 中文界面。
- 风格简洁，主色 #6366f1。

先列方案。

4.4 运行方式

index.html 直接打开，第一次填 API Key（DeepSeek 5 元试用够整理 10 次会议）。

4.5 避坑要点

• API 在浏览器调有 CORS 问题：用 OpenRouter 或 DeepSeek，它们允许；OpenAI 官方需要后端代理。
• 会议太长 token 超限：让 Cursor 自动按 5000 token 一段切，分段处理后合并。
• 结构化结果不对：给 LLM 的提示词里加 XML 标签或 JSON Schema，准确度提升 30%+。

4.6 公司适用性

⚠ 会议内容可能涉密——千万别用公司 API Key 跑别人的会议。 ⚠ 可以用本地 Ollama 跑 qwen3-coder，做到"全本地，不出网"。 ✓ 适合个人会议、外部公开会议。

五、案例 4：周报 / 月报自动生成

5.1 它解决什么

每周五最痛苦的一小时——憋周报。明明做了一堆事，写起来全忘了。

5.2 做完后你能得到什么

weekly-report/ 目录：

• 自动从 Git 提交、Jira 工单、Slack 消息、日历事件提取本周做的事。
• 让 LLM 整理成结构化周报（按"完成 / 进行中 / 下周计划"三段）。
• 一键复制到企业微信 / 飞书。

5.3 完整提示词

新建 weekly-report/：

做一个个人周报自动生成工具。

【数据源】
- Git 提交：调 git log 命令本地执行，提取本周（周一到周日）所有提交（含中文 message）。
- Jira 工单：用户填 Jira API URL + Email + Token，调 API 拉本周更新过的工单。
- 日历事件：从 .ics 文件读（用户导出 Google Calendar / Apple Calendar 的 .ics）。
- 自由文本：用户可以手动追加"本周做了什么但没记录"的内容。

【处理】
- 把所有素材组装成一份"上下文"。
- 调 LLM 整理成周报，要求：
  - 完成（已交付）
  - 进行中（正在做但没结束）
  - 下周计划（自动从工单里"下周到期"+ 用户手填的）
  - 风险与问题
  - 数据指标（如果素材里有数字）

【输出】
markdown 周报：

# 周报 2026-W16（4-13 至 4-19）

## 一周完成
- 上线 X 功能（commit abc123、Jira FOO-456）
- 发布 Y 文档
...

## 进行中
- Z 重构（已完成 60%）
...

## 下周计划
- ...

## 风险与问题
- ...

## 数据指标
- 本周 commit 数：23
- 本周修复 bug 数：8
- 本周新增需求数：3

【UI】
- 单页 web app（Next.js / SvelteKit / 纯 HTML 都行，你选最快的）。
- 顶部一个"配置"面板（Jira / Git 路径 / API Key）。
- 中间"原始素材"面板（自动拉取 + 手动追加）。
- 底部"生成周报"按钮 + 预览。

【约束】
- 数据全部本地处理，不上传到任何外部服务（除调 LLM API）。
- API Key 存 localStorage。
- 中文界面。

【特别要求】
- Git 命令需要在用户本地跑——使用 file system access API 让用户授权一个 git 仓库目录，然后用 isomorphic-git（浏览器内 git）读 log。
- 如果 isomorphic-git 太慢，退而求其次：让用户在本地跑 `git log --since="last monday" > git.txt`，把 git.txt 拖进网页。
- 简单优先。

先列方案，给我两个方案对比：方案 A 用 isomorphic-git；方案 B 用文件拖入。

5.4 运行方式

按 LLM 给的方案选最简单那个。简单方案：

# 周日晚上做这件事
git log --since="last monday" --pretty=format:"%h %s" > week.txt
# 把 week.txt 拖进周报 web 工具

5.5 避坑要点

• 不要把 commit message 全发给 LLM：100 个 commit 会爆 token。让工具先按文件 / 模块聚合再发。
• Jira API 速率限制：每分钟限 50 次调用。让工具加 retry + 指数退避。
• 领导喜好不一样：让工具支持"周报模板"，每个领导一个 .md 模板文件，渲染时套。

5.6 公司适用性

⚠ Git commit message 可能涉密。本地 LLM（Ollama）最安全。 ⚠ Jira Token 等同于你的 Jira 密码，绝不要硬编码到代码里。 ✓ 个人使用绝对没问题。

六、案例 5：简单网页爬虫

6.1 它解决什么

监控一个商品价格、监控竞品上新、监控某个论坛话题——这些都需要爬虫。

6.2 做完后你能得到什么

watcher/ 目录：

• watch_price.py — 监控指定 URL 的某个 CSS 选择器，价格变化时给你邮件 / 微信通知。
• watch_keyword.py — 监控某个网页是否出现关键词。
• digest_rss.py — 把多个 RSS 订阅源汇总成"每日速览"邮件。

6.3 完整提示词

新建 watcher/：

做 3 个简单的"网页监控"Python 脚本。

【脚本 1：watch_price.py】
监控一个商品页面的价格变化。
- 配置文件 config.yaml：
    items:
      - name: AirPods Pro
        url: https://www.apple.com.cn/shop/buy-airpods/airpods-pro
        selector: ".price"
        threshold: 1500   # 低于这个价格立即通知
- 跑：python3 watch_price.py
- 跑完输出当前价格 + 上次价格对比。
- 价格低于阈值时调 webhook 通知（Server 酱 / 钉钉 / 微信机器人）。
- 历史价格存 history.json。

【脚本 2：watch_keyword.py】
监控页面是否出现某关键词。
- config: pages: [{url, keyword, expected}]
- 比如"监控 OpenAI 的 changelog 是否出现 GPT-6"。
- 出现 / 消失时通知。

【脚本 3：digest_rss.py】
聚合多个 RSS 订阅源，每天发一封"今日速览"邮件。
- config: feeds: [url1, url2, url3]
- 跑：python3 digest_rss.py --send
- 用 SMTP 发邮件（用户在 .env 填 SMTP 配置）。
- 邮件内容是 markdown：每个源最新 5 条，标题 + 链接 + 1 句摘要。

【共同约束】
- 所有 HTTP 请求加 User-Agent 模拟浏览器。
- 失败重试 3 次。
- 单文件 .py。
- 依赖：requests、beautifulsoup4、feedparser、PyYAML（写入 requirements.txt）。
- README 用大白话教非程序员怎么填 config。

【运行环境】
- 跑在用户本地或一台 5 美元 VPS 上。
- 用 cron 定时（README 里给 cron 例子）。

先列方案。

6.4 运行方式

pip install -r requirements.txt
python3 watch_price.py
# 测试通过后，加到 cron：
# 每 30 分钟跑一次：*/30 * * * * cd /path/to/watcher && python3 watch_price.py

6.5 避坑要点

• 页面是 JS 渲染的：requests + BeautifulSoup 拿不到。让 Cursor 改用 Playwright 或 Selenium，或者找页面的内部 JSON API。
• 被网站封 IP：频率别太高、加随机 delay、用代理池（极端情况）。
• 网站改版选择器失效：让 Cursor 加邮件提醒"价格选择器抓不到了"。

6.6 公司适用性

⚠ 部分网站不允许爬虫（看 robots.txt 和 ToS）。监控自己买的东西、公开 RSS 源没问题。 ✗ 大规模爬竞品数据可能踩法律红线，慎重。

七、案例 6：Excel 数据透视神器

7.1 它解决什么

每天给老板看的 Excel 报表 = "这个城市这个月卖了多少、对比上月怎么样、谁是 Top 5 销售"。Pivot Table 太复杂、Power Query 学不动。

7.2 做完后你能得到什么

excel-pivot/ 目录：

• 拖一个 Excel 进网页。
• 用大白话描述需求："按城市汇总销售额，按月份对比，找 Top 5 销售"。
• 自动生成数据透视 + 图表。

7.3 完整提示词

新建 excel-pivot/：

做一个"用大白话描述就能出 Excel 透视图"的 web 工具。

【输入】
- 拖 .xlsx / .csv 文件进来。
- 自动识别列名 + 数据类型（用 SheetJS）。
- 用户在文本框写："按城市汇总销售额，按月份对比 Top 5"。

【处理】
- 调 LLM 把"大白话"翻译成结构化操作（不是直接执行 SQL，而是返回一个 JSON）：
    {
      "groupBy": ["城市", "月份"],
      "aggregate": {"销售额": "sum"},
      "topN": 5,
      "chartType": "bar"
    }
- 在浏览器内执行（不要把数据发给 LLM）。
- 用 SheetJS 解析 Excel，用纯 JS 做 group by + sum。
- 用 SVG 渲染图表（柱图 / 折线 / 饼图）。

【输出】
- 一张数据表（前端表格）。
- 一张图表。
- 一个"复制到剪贴板"按钮（带表格 + 图，支持粘贴到飞书 / 钉钉）。
- 一个"导出新 Excel"按钮。

【UI】
- 三步流程：上传 → 描述 → 看结果。
- 步骤指示器在顶部。
- 全中文。

【关键约束】
- 数据**不发给 LLM**，只发"列名 + 前 5 行示例"，让 LLM 推断 schema。
- 真正的计算全部在浏览器。
- 这是隐私 + 速度的双重设计。

【技术】
- Vite + 原生 JS（不用框架，简单优先）。
- CDN 引入 SheetJS。
- LLM 用户填自己的 API Key。

先列方案。

7.4 运行方式

npm create vite@latest excel-pivot -- --template vanilla
cd excel-pivot
npm install
npm run dev

7.5 避坑要点

• 大文件（> 100MB）卡浏览器：让工具提示"建议先拆分"或"切到云端版本"（v2 再做）。
• 列名带空格 / 特殊字符：SheetJS 默认按 A1 / B1 引用，让 Cursor 做一次"列名规范化"。
• LLM 返回的 JSON 格式不对：用 JSON Schema + 验证 + 重试。

7.6 公司适用性

✓ 数据本地不上传，公司一般 OK。 ⚠ 如果是高度敏感数据（HR 工资表），最好本地 Ollama 跑 LLM。

八、案例 7：自动发邮件 / 群发提醒

8.1 它解决什么

每周一早上 9 点要给团队发"上周指标"。每月底给客户发对账单。每天给老板发当日数据。

人工做半小时，工具做 5 秒。

8.2 做完后你能得到什么

auto-mailer/ 目录：

• weekly_metrics.py — 每周一 9 点跑，从某个 API 拉数据，渲染成漂亮 HTML 邮件，群发到团队邮箱。
• monthly_billing.py — 每月最后一天跑，给每个客户发对账单（带 PDF 附件）。
• daily_dashboard.py — 每天早上 8 点发"昨日核心指标"。

8.3 完整提示词

新建 auto-mailer/：

做一组"自动定时发邮件"的 Python 脚本。

【共同基础】
- 用 SMTP 发（用户在 .env 填 SMTP_HOST / PORT / USER / PASS / FROM）。
- 邮件渲染用 jinja2 模板（templates/ 目录下）。
- 收件人列表存在 recipients/<scriptname>.csv 里（列：name / email）。

【脚本 1：weekly_metrics.py】
- 调用某个 metrics API（用户填 URL）拉本周数据。
- 渲染 templates/weekly_metrics.html.j2 模板。
- 群发到 recipients/weekly_metrics.csv。
- 抄送给老板（.env 填 BOSS_EMAIL）。

【脚本 2：monthly_billing.py】
- 读 invoices/ 目录下的 PDF 对账单（文件名 = 客户ID.pdf）。
- 读 customers.csv（列：客户ID / 客户名 / 联系人邮箱）。
- 给每个客户发邮件，附他自己的 PDF 对账单。
- 邮件正文用模板。
- 失败的客户记录到 failed.csv。

【脚本 3：daily_dashboard.py】
- 类似 weekly，但是每天数据。
- 自动包含"对比昨日"、"对比上周同日"。

【约束】
- 单文件脚本，互不依赖。
- requirements.txt 写清依赖。
- 模板支持中文。
- 失败可重试（最多 3 次，指数退避）。
- 跑完输出"成功 X 封 / 失败 Y 封"。

【部署建议】
README 教用户：
- 本地用 cron / launchd 定时
- 或者部署到一台 5 美元 VPS（搜索 "DigitalOcean droplet" 或 "Vultr"）

【特别提醒】
- 模板里禁止使用 {{ }} 之外的任何动态内容（避免注入）。
- SMTP 密码绝不能写进代码（只读 .env）。
- 收件人 CSV 不要 commit 到 git（写进 .gitignore）。

先列方案 + 给我一份 templates/weekly_metrics.html.j2 的设计草稿。

8.4 运行方式

cp .env.example .env
# 编辑 .env 填 SMTP 配置
pip install -r requirements.txt
python3 weekly_metrics.py --dry-run    # 不真发，只打印
python3 weekly_metrics.py              # 真发

8.5 避坑要点

• 企业邮箱 SMTP 限制：QQ / 163 个人邮箱发太多会被限。公司邮箱通常需要"应用密码"（如 G Suite / Office 365）。
• HTML 邮件兼容性：Outlook / Gmail / 国内邮箱渲染差异大，让 Cursor 用 Maizzle 风格的内联 CSS。
• 退订链接是合规要求：群发商业邮件必须有退订链接（CAN-SPAM Act）。

8.6 公司适用性

⚠ 公司邮件是企业资产，不是你的。先让 IT 同意。 ✓ 个人项目随便用。

九、案例 8：团队内部小工具

9.1 它解决什么

团队没钱买 SaaS，但天天需要一个"提交报销"、"查询库存"、"团队午餐投票"的小内部表单。

之前要么 Excel + 群里催，要么写半天 Notion。

9.2 做完后你能得到什么

team-tools/ 目录，3 个小工具：

• lunch-vote.html — 团队中午吃啥投票，多人多端实时同步。
• expense-form.html — 报销提交表单，自动算金额合计，PDF 导出。
• oncall-rota.html — 排班表，自动按周轮换。

每个工具一个 HTML 文件，可以放在公司内网或 Vercel。

9.3 完整提示词

新建 team-tools/：

做 3 个"团队内部小工具"，每个一个独立 HTML 文件。

【工具 1：lunch-vote.html】
- 顶部输入 5-10 个候选餐厅（团队管理员先填）。
- 每个团队成员打开链接，点投票。
- 实时显示投票结果（柱图）。
- 截止时间到了自动锁定。
- 数据用 Supabase 存（用户填 URL + anon key）。
- 同一设备只能投一次（用 localStorage 记录，可被绕过但够用）。

【工具 2：expense-form.html】
- 表单：日期 / 类别（下拉）/ 金额 / 商户 / 备注 / 上传发票照片。
- 一行一笔，可加多行。
- 自动计算合计。
- 一键生成报销 PDF（合并所有发票照片 + 表格）。
- PDF 用 jsPDF 库（CDN 引入）生成。
- 发票照片不上传任何服务器，仅本地处理。

【工具 3：oncall-rota.html】
- 输入团队成员名单（一行一个）。
- 选择"轮换周期"（每天 / 每周 / 每两周）。
- 选择"开始日期"。
- 自动生成接下来 12 周的排班表。
- 一键复制到飞书 / 钉钉（带 @ 提及）。
- 排班表数据存 localStorage（管理员可分享 URL，URL 含编码状态）。

【共同约束】
- 单文件 HTML（CSS + JS 内联）。
- 中文界面。
- 大字（≥ 16px）+ 大按钮，方便手机用。
- 风格简洁。

先列方案。

9.4 运行方式

每个 HTML 直接打开即可，或者放到 第十一章 Vercel 上线给团队用。

9.5 避坑要点

• 多人同时投票冲突：lunch-vote 用 Supabase 时启用 RLS（行级安全）。
• PDF 中文乱码：jsPDF 默认不支持中文字体。让 Cursor 加载思源宋体的 ttf 子集。
• 无权限控制：内部工具一般"知道链接就能用"。不要放敏感数据。

9.6 公司适用性

✓ 完全适合内部使用。 ✓ Supabase 免费额度够小团队用。

十、个人副业 SaaS 雏形：30 天能上线的产品

10.1 思路

前面 8 个案例都是"自用工具"。如果你想把工具变成"小生意"——给其他普通人用，每月收他们 9.9 / 19.9 / 99 元——这就是"Indie SaaS"。

下面给一个完整的 30 天计划。

10.2 选题原则

选你自己每天都需要且别人也需要、市场上没有便宜好用方案的事。

例子：

• 错题本（考研学生）
• 单词本（程序员英语）
• 健身打卡（成年人）
• 时间记录（自由职业者）
• 备考刷题（公务员）
• 儿童阅读跟踪（家长）

10.3 一份"番茄钟 Pro"产品的完整提示词

我们把 第四章 的番茄钟升级成"能卖钱"的版本。

新建 pomodoro-pro/：

我要把第四章的番茄钟做成一个"能上线收费"的 SaaS。

【产品定位】
"为远程工作者设计的、有团队功能的番茄钟"
- 个人版：免费
- Pro 版：每月 ¥19.9，包含团队同步、长期统计、自定义铃声

【技术栈】
- Next.js 15（App Router）
- Tailwind CSS 4
- Supabase（数据库 + 认证）
- Stripe / 易支付（支付）
- Vercel（部署）

【功能清单 - 免费版】
1. 番茄计时（保留前面的核心功能）
2. 本地数据
3. 深色模式

【功能清单 - Pro 版】
4. 账号系统（邮箱注册）
5. 多设备同步（电脑 + 手机）
6. 团队功能：邀请同事，看到大家此刻是不是在专注
7. 长期统计：年度热力图、月度报告 PDF
8. 自定义铃声：上传你自己的铃声
9. 集中模式：屏蔽指定网站（Chrome 扩展，留口子）

【30 天计划】
- 第 1-3 天：完成 MVP（个人版）+ 上线 Vercel
- 第 4-7 天：加 Supabase 认证 + 数据同步
- 第 8-14 天：加付费层（Stripe）+ 团队功能
- 第 15-20 天：写官网 + 落地页 + 5 篇 SEO 文章
- 第 21-25 天：发 ProductHunt + 即刻 + 小红书
- 第 26-30 天：根据用户反馈迭代

【商业模式】
- 免费版引流，Pro 版变现
- 价格 ¥19.9 / 月（极度便宜，先冲量）
- 第一年目标：100 个 Pro 用户，月收 ¥1990

【请求】
不要现在就开始写代码。先给我一份"30 天工程清单"：
- 每周要交付什么
- 每天要做什么任务
- 每个任务大概要多少时间
- 哪些任务可以让 Cursor Agent 跑、哪些必须人工

我会按这份清单和你一起干。

10.4 30 天清单（Cursor 帮你出的样本）

Week 1：MVP 上线
─────────────────
Day 1：搭脚手架（Next.js + Tailwind）+ 部署 Vercel
Day 2：把第四章番茄钟代码迁过来
Day 3：加深色模式 + PWA
Day 4：买域名 + 配置（如 pomodoro.work）

Week 2：账号 + 同步
─────────────────
Day 5-6：Supabase 接入 + 邮箱注册登录
Day 7：用户表 + RLS
Day 8：番茄记录上传到 Supabase
Day 9：多设备同步
Day 10：增加桌面通知 + 移动端 push

Week 3：付费 + 团队
─────────────────
Day 11-12：Stripe 接入 + 订阅管理
Day 13：付费墙（仅 Pro 才能看长期统计）
Day 14：团队邀请功能
Day 15：实时显示团队"谁在专注"
Day 16：年度热力图 + PDF 月报
Day 17：自定义铃声（上传到 Supabase Storage）

Week 4：内容 + 推广
─────────────────
Day 18：官网首页 + 定价页 + FAQ
Day 19-20：5 篇 SEO 文章（"番茄工作法 vs 心流"、"远程团队如何同步专注"等）
Day 21：发 ProductHunt（提前 1 周做内测，攒 hunters）
Day 22：发即刻 + 小红书 + V2EX
Day 23-25：客服 + 修 bug + 听反馈
Day 26-30：每天一个小迭代

10.5 你能看到什么效果

按上面 30 天做，普通人能做到的现实预期：

不是发财，但能多一份"自己说了算"的副业收入，而且资产是你的。

第十一章 会详细教 Vercel + Supabase + Stripe 的完整接入。

十一、本章 8 个案例的"风险评级"

普遍建议：

1. 公司数据相关的，先和你的直属上级或 IT 同事打个招呼。
2. 涉及敏感数据时，用本地 Ollama 模型，不要走云端 API。
3. 不要把客户 / 同事的个人信息上传到任何外部 AI 服务。

本章一图回顾

8 个工作案例 + 1 个 SaaS 雏形
═══════════════════════════════════════════════
  案例 1 ▢ 批量改名 / PDF 处理
  案例 2 ▢ 客户跟进表
  案例 3 ▢ 会议纪要
  案例 4 ▢ 周报 / 月报
  案例 5 ▢ 网页爬虫
  案例 6 ▢ Excel 透视
  案例 7 ▢ 自动发邮件
  案例 8 ▢ 团队内部工具
  额外 ◆  个人 SaaS 雏形（番茄钟 Pro，30 天上线）

每个案例都有
─────────────
  ① 完整提示词
  ② 运行方式
  ③ 避坑要点
  ④ 公司适用性

总耗时（学完 + 跑通）
─────────────
  全部完成：约一个周末
  有选择地做 3-4 个：约 2 个晚上

下章预告

到这里你已经能熟练使用 Cursor 处理生活和工作场景。下一章 第九章 Agents Window 与多代理 我们进入 Cursor 3 的"高阶玩法"——同时跑多个 AI、对比模型选最优、Cloud Agent 在云端 24 小时打工、Design Mode 让 AI 看着 UI 改 UI。