开头导语
过去这半年，我连续试了两个内容站。
一开始的想法其实很简单：有了 AI，咱又是开发，天天用，写内容这不是手到擒来，理论上做一个小型内容网站，应该比以前更容易。但真正做下来，难崩 —— 两个站最后都没有跑起来，谷歌GSC坚持不到一个月,全挂,曝光变成零!
最开始我还挺懵的。
我以为是自己选题不行、执行太慢，或者内容还铺得不够多。结果是谷歌上的 AI内容井喷,大家都搞,谷歌爬虫的AI内容识别能力大大增强,识别你是AI生成的内容站,基本GG!
本来打算去学SEO,还有最近比较火的GEO,搞点流量。 但是看到一篇文章,觉得很有道理: 做网站，关键是给用户提供价值。 有价值了，自然不缺流量!
所以工具站是最好的选择。
搞了一下关键词分析,选了一个竞争相对小一些的域名。
我现在做的这个项目叫 ProjectCalcs，是一个面向海外用户的家装材料计算器网站。
正好把之前的失败经验也能吸取点，也逐渐把 AI 的角色从“帮我写点代码”变成了“参与选题、流程设计、页面优化、验证和迭代的合伙人”。
所以这篇文章，我不想讲成一个“我用 AI 快速做站”的爽文。
我更想认真讲清楚：我是怎么从两个失败的内容站，转到工具站这条路的；为什么我后来觉得，AI 更适合拿来做工具和流程，而不是单纯堆内容；以及我这一路上踩过哪些坑。
如果你也在尝试用 AI 做副业，可以参考一下。
我怎么把 AI 当成“合伙人”
一开始我对 AI 的理解，其实也挺普通的。
无非就是让它帮我写点代码、改改文案、查一点资料，更多像一个效率工具，而不是一个真正能参与项目的人。
但当你用它来用一个从零开始的项目的时候,结合MCP,SKILLS等工具,就会发现能做的非常多，如果只是把 AI 当成“代码补全器”，其实有点浪费。它真正有价值的地方，不只是执行某个很小的动作，而是可以参与整个流程：从一个想法开始，到选题、页面规划、开发、验证、优化，再到最后把经验沉淀下来。
所以就搞了一个项目规则,作为所有项目的默认规则,用来约束AI,降低幻觉,如下:
---
description: 工作流与行为规范 - 角色、记忆加载、不确定性协议、命令交付、规则创建
alwaysApply: true
---
# 角色定义: 全能技术合伙人 (Co-Founder & CTO)
你不仅仅是一个编程助手，你是我的个人项目合伙人。你必须根据当前上下文，在以下四个角色中灵活切换：
1. **产品经理 (PM):** 关注核心价值，拒绝过度设计。
2. **首席架构师 (Architect):** 保证代码结构清晰，严格控制依赖，拒绝屎山代码。
3. **测试工程师 (QA):** 对代码极其挑剔，始终考虑"这会怎么坏掉？"。
4. **运维专家 (DevOps):** 关注安全、成本和部署。
---
# 🧠 1. 核心记忆与全局规则库 (强制全量加载)
在行动之前，必须构建完整的知识图谱。
**必须执行全量加载**:
1. **动态上下文:** 读取 `memory-bank/` 下的所有文件（如 `context.md`, `progress.md`）。
2. **静态规则:** 必须扫描 `.cursor/rules/` 下的所有 `.mdc` 文件，并将其视为**硬性约束**。
3. **Agent Skills:** 所有 `!` 命令技能已迁移至 `.cursor/skills/`（Cursor Agent Skills 标准格式）。执行 `!` 命令时，Cursor 自动匹配对应技能；也可按 `commands.mdc` 中的路径主动读取对应的 `SKILL.md`。
---
# ❓ 2. 不确定性协议 (The Uncertainty Protocol)
_优先级: 最高 (反幻觉的核心)_
**原则: 猜测是万恶之源。知之为知之，不知为不知。**
当遇到以下情况时，**严禁猜测**，必须立即暂停并向我提问：
1. **缺少具体实现细节:** 例如"用什么库来做图表？"（如果 `techContext.md` 没写，就问我，别乱选）。
2. **模糊的业务逻辑:** 例如"用户删除后数据怎么办？"（如果 `productContext.md` 没写，就问我是软删除还是硬删除）。
3. **未定义的常量/类型:** 不要自己编造枚举值或类型定义。
4. **应对幻觉的兜底:** 如果你在上下文里找不到答案，**不要试图自己填补空白**，直接问："上下文中未找到关于 [X] 的定义，请问您希望如何处理？"
---
# 🛑 3. 防幻觉与规划 (多视角思考)
处理复杂逻辑时，严格执行：
1. **PM 视角重述:** 总结我们要解决的实际问题。
2. **架构师规划 (伪代码):** 列出技术步骤和实现方案。
3. **✋ 暂停并等待 (STOP & WAIT):** 询问："这个方案符合预期吗？是否需要调整？"
4. **仅在获批后执行:** 只有我确认后，才生成最终代码。
---
# 🚀 4. 原子化交付 (节奏控制)
1. **分层实现:** 除非要求，否则**一次只做一个层级**（如先后端，再前端）。
2. **步步确认:** 完成核心逻辑后，暂停并询问下一步。
---
# ✅ 5. 强制验证 (QA 视角)
生成代码后：
1. **验证手册:** 提供具体的验证命令（CURL, SQL, 测试脚本）。
2. **命令执行规则:** 与第 8 节一致——**非破坏性命令**可自动执行并汇报结果；**破坏性命令**严禁自动执行，必须提供完整命令清单、说明用途、红字警告并等待开发者确认后执行。
3. **防御性思维:** 指出潜在风险。
4. **错误优先:** 遇错先分析，再修复。
---
# ⚖️ 6. 代码质量与依赖控制 (架构师视角)
1. **⛔️ 拒绝依赖膨胀:** 在建议安装新依赖之前，必须检查能否用**原生代码**或**现有库**实现。严禁引入重型库解决简单问题。
2. **保持简洁:** 除非我有要求，否则不要过度抽象。
---
# 🛡️ 7. 系统安全与运维 (DevOps 视角)
1. **💰 成本感知:** 主动提醒将大文件/构建产物加入 `.cursorignore`。
2. **🚫 禁止随意创建文件:** 目录保持洁癖。
3. **环境隔离:** 密钥必须用 `process.env`，**严禁硬编码**。
4. **破坏性操作预警:** `rm -rf`, `DROP TABLE` 等操作必须红字警告。
---
# 🚫 8. 命令执行分级（仅破坏性命令需确认）
默认允许执行所有**非破坏性命令**；仅**破坏性命令**必须由开发者确认后执行。
**必须确认（破坏性命令）**：
- 删除或不可逆覆盖（`rm -rf`, `git reset --hard`, `DROP TABLE`, 批量 `DELETE` 等）
- 其他任何可能导致数据不可恢复的操作
**破坏性命令必须红字警告，并附上用途说明与等待确认。**
---
# 🔌 9. MCP 工具使用规则
**频率限制 (Rate Limiting):**
1. **Brave Search API:** 每次调用后必须等待 **2 秒** 再发起下一次请求。
2. **Tavily Search API:** 每次调用后必须等待 **2 秒** 再发起下一次请求。
3. **批量查询策略:**
- 优先使用单次查询获取多个结果（调整 `count` 参数）
- 避免短时间内连续调用同一 API
- 如需多次查询，必须在调用间插入 2 秒延迟
**成本控制:**
- 在使用搜索 API 前，评估是否真的需要实时数据
- 优先使用缓存或已有知识库
- 向用户说明将要进行的 API 调用及原因
---
# 📋 10. 命令交付流程
**非破坏性命令**（如 `npm install`、`npm run dev`、`ls`、`git status`）：可由 Agent 直接执行，执行后汇报结果即可。
**破坏性命令**（见第 8 节）必须走以下流程：
1. **列出命令清单:** 使用代码块格式，清晰标注每条命令。
2. **说明用途:** 解释每条命令的作用和预期结果，并**红字标注为破坏性操作**。
3. **等待确认:** 明确告知"此为破坏性操作，请确认后再执行，并将结果反馈给我"。
4. **分析结果:** 根据开发者提供的执行结果，判断下一步行动。
---
# 📝 11. 交互习惯
- **拒绝假设:** 不清楚就问（参见第 2 节）。
- **中文回复:** 始终使用中文（代码除外）。
- **透明决策:** 说明为什么选择某个方案，而非直接给出代码。
- **命令与执行:** 非破坏性命令可先执行再汇报；破坏性命令必须「先列命令、说明用途、等确认后再执行」。
---
# 📂 12. Cursor 规则创建规范
在 `.cursor/rules/` 下新增或修改规则时，须遵循：
1. **格式:** 使用 `.mdc` 文件，YAML frontmatter 包含 `description`、可选 `globs`、`alwaysApply`。
2. **命名:** 文件名简洁、见名知意（如 `project-rules.mdc`, `mcp-usage.mdc`）。
3. **篇幅:** 单条规则内容建议 under 500 行；可拆分为多条规则，一条一关注点。
4. **同步:** 若新增与命令相关的规则，需同步更新 `.cursor/rules/commands.mdc` 中的引用或说明。
这套流程的主要作用就是给AI定好规范,使用记忆库!
比如我现在做一个新页面，我会先让 AI 根据我的流程,帮我梳理这个词值不值得做、页面能给用户提供哪些价值、和站内其他页面会不会冲突、竞品已经做了什么、我们应该在哪一块比别人更具体。等这些想清楚之后，再进入开发。
开发完也不是结束，后面还有验证、用户视角检查、文案自然化、SEO 收口、SERP 对比，以及最后把经验同步回记忆库。
这套流程里，AI 最重要的作用，其实不是“替我完成”，而是“帮我把一套复杂流程稳定重复地跑下去”。
所以到现在，我已经不太把 AI 当成一个单点工具了。
对我来说，它更像一个合伙人：写代码只是它能力里最不重要的一部分，真正重要的是，它能把控项目流程。
我现在这套 AI 开发流程是怎么跑的
如果没有流程，AI 确实能帮你做很多事，但也很容易把页面做散、做重复，或者做成一堆看起来完整、其实没有差异化的东西。
所以我后来给自己定了一套固定流程。
核心思路很简单：先把页面为什么做、做给谁、和谁竞争、和站内谁区分清楚，再进入开发。开发完也不直接上线，而是继续验证、优化、收口。
这套流程大概可以分成几步：
- 先做关键词和方向判断
- 确认页面的意图、边界和差异化
- 进入页面开发
- 验证计算逻辑和结果
- 从用户角度检查体验
- 做文案自然化和 SEO 收口
- 再结合 SERP 和竞品做最后一轮优化
- 最后把结果同步回记忆库，方便后续复用
对我来说，这套流程真正解决的问题不是“能不能把页面做出来”，而是：
能不能稳定地把页面做对。
下面是我现在比较固定的一条主流程：
flowchart TD
A["关键词/方向判断"] --> B["Intent Brief<br/>定义主意图、边界、差异化"]
B --> C["页面开发<br/>Calculator / Examples / Guide / FAQ"]
C --> D["结果验证<br/>公式、案例、竞品比对"]
D --> E["UX 检查<br/>是否真的完成用户任务"]
E --> F["内容自然化<br/>去掉模板味和 AI 味"]
F --> G["SEO 收口<br/>Title / Description / Schema"]
G --> H["SERP 复核<br/>Trends / SERP / 竞品 / 长尾"]
H --> I["同步记忆库<br/>沉淀经验和后续计划"]
我现在每做一个新页面，基本都会经历下面这些动作：
1. 先想清楚这页到底解决什么问题
这一步很重要。
不是看一个词有流量，就直接做，而是先判断：
- 这个词适不适合我的网站
- 这页的主意图是什么
- 和站内其他页面会不会冲突
- 竞品已经做了什么
- 我至少要在哪一个模块上比竞品更具体
2. 页面不是只做一个计算器
单纯输入框加结果，通常是不够的。
真正能把页面撑起来的，往往是这些模块一起配合：
- Calculator
- Project Examples
- Decision Module
- Guide Module
- FAQ
- Related Calculators
也就是说，页面不仅要“能算”，还要能回答用户下一步该怎么做。
3. 开发完不代表结束
这也是我后来改得最多的一点。
以前我会觉得页面能跑、结果能出来，差不多就可以了。后来发现不行。
现在开发完之后，我通常还会继续做几轮：
- 验证公式和案例
- 用新手视角检查体验
- 把文案变自然
- 收 SEO
- 再看一遍 Google SERP 和竞品
因为很多问题，都是在“页面已经看起来差不多完成”的阶段才暴露出来的。
4. 最后一定要把经验记下来
这一点也是我后来才真正重视的。
如果每次做完一个页面，经验不沉淀，后面还是会重复踩坑。
所以我现在会把：
- 页面意图
- 竞品差距
- 做过的优化
- 下一批关键词判断
都同步回记忆库。这样后面再做新页面时，整个流程就会越来越稳，而不是每次都从头想一遍。
下面是skill流程,使用skill来进行具体页面的开发,通过!来触发相应的skill
flowchart TD
A["关键词规划<br/>!keywordplan"] --> B["页面方案设计<br/>!calc"]
B --> C["结果验证<br/>!verify"]
C --> D["用户视角检查<br/>!ux"]
D --> E["内容自然化<br/>!humanize"]
E --> F["SEO 收口<br/>!seo"]
F --> G["SERP / 竞品复核<br/>!serpseo"]
G --> H["同步记忆库<br/>!update"]
1. !keywordplan：先决定这个词值不值得做
这一步不是正式开发页面，而是先判断方向。
我会先看：
- 这个词适不适合网站定位
- 有没有真实需求
- 是继续深挖现有 cluster，还是扩新方向
- SERP 里有没有机会
- 这个词更像主线工程词，还是辅助型工具词
这一步做完之后，我才会把词正式放进待开发池。
也就是说，AI 在这里做的不是“直接生成页面”，而是先帮我做筛选。
2. !calc：先把页面意图和边界设计清楚
这是最重要的一步,主要是根据关键词把页面写出来。
我不会直接让 AI 上来就写页面，而是先让它把一份页面方案梳理出来，里面会包括：
- 这个页面的 Primary Intent
- Secondary Intent
- Scope In / Scope Out
- 跟站内哪些页面可能冲突
- 竞品做了什么
- 我们准备在哪个模块上比竞品更具体
这一步出来的其实不是代码，而是一张“施工图”。
后面开发、验证、优化，基本都围绕它展开。
3. !verify：验证结果到底对不对
这一步主要是做硬验证。
因为计算器页面和普通内容页不一样，最怕的就是公式错、案例错、结果逻辑不一致。
所以我会让 AI 帮我做这些事：
- 拿真实案例去测
- 对比竞品结果
- 检查公式来源
- 检查页面承诺和实际输出是不是一致
这一步的作用很直接：
先确保它是对的，再谈好不好。
4. !ux：站在用户角度看，这页到底能不能用
验证通过之后，我不会马上结束。
因为一个页面就算结果是对的，也不代表用户真的好用。
这一步我会从“新手视角”去看：
- 输入是不是容易理解
- 结果优先级对不对
- 页面有没有真正完成用户任务
- 差异化模块用户能不能感知到
这一步经常会发现很多不是“代码错误”，而是“表达错误”的问题。
5. !humanize：把页面写得更像人写的
这个步骤主要是用来降低AI感,不使用AI高频词汇
所以这一步主要做的是：
- 去掉明显的 AI 味
- 把表达写得更自然
- 但又不能把 Intent Brief、SEO 和差异化破坏掉
不过对于工具站,这一步重要性很低;但对内容站而言,这一步很重要,需要去收集AI高频常用词汇,做一个本地数据库,对比用。
6. !seo：最后把搜索表达收紧
到这一步，页面本身已经差不多成熟了。
然后我再让 AI 去处理更偏搜索层的东西，比如：
- Title
- Meta Description
- Schema
- 关键词表达顺序
这一步主要是常规性SEO,检查页面的错误,漏洞之类的,比如标题长度,描述长度等。
7. !serpseo：最后再回到 Google 和竞品
这是最后一轮复核。
我会让 AI 再看一遍：
- Google Trends
- Google SERP
- 竞品页面
- 长尾问题
- PAA / related searches
目的不是推翻页面，而是确认：
- 这页有没有偏
- 还有没有一两个值得补的点
- 是否真的比竞品更具体
这一步主要是为了获取更多流量,更针对性的去做SEO优化。
8. !update：把经验同步回记忆库
如果每次做完一个页面就结束，后面还是会重复踩坑。
所以我会把这次页面的状态同步回记忆库，包括：
- 更新候选池进度
- 当前全站进度
- cluster 状态
- 下一步开发顺序
- 新研究出来的候选词
这样 AI 下次再参与时，就不是“从零开始”，而是在一个持续累积的上下文里工作。
这套流程真正解决了什么
这套流程本质上是把 AI 放进了一条比较严格的生产链里。
每一步都有自己的职责，也有自己的检查点。这样最后做出来的页面，至少是可控的，而不是一堆看起来完整、其实质量不稳定的半成品。
我踩过的坑
- 以为能做出来，就等于值得做
- 能生成页面，不代表这个词值得投入
- 搜索量、站点定位、页面边界，都要先想清楚
- 太容易把页面做泛
- 什么都想覆盖一点
- 最后页面看起来很全，但主任务反而不清楚
- AI 很容易制造“完整错觉”
- 标题、FAQ、说明、公式都有了
- 但真正的问题是没有重点、没有差异化
- 太早进入 SEO 视角
- 页面还没定型，就开始纠结 title、关键词、FAQ
- 容易把页面做成“给搜索引擎看”的，而不是给用户用的
- 不沉淀经验，后面一定重复踩坑
- 不记录判断、状态、竞品结论
- 后面做新页面时，还是会掉回老问题里
- AI 不能替你做选择
- 它很适合执行和协作
- 但方向、边界、优先级这些关键判断，最后还是得自己定
最后的展望
这个项目从 1 月 14 号提交到 Google Search Console，到现在大概也就两个半月。
如果只看数据，它当然还远远不算什么大项目，流量也不大，广告收益现在每天甚至只有几分钱。
但对我来说，做到这个阶段说实话,挺满意。 至少：方向对了。
后面我还是会继续寻找关键词,继续写页面，学学怎么搞外链,怎么推广，一边优化、一边观察数据，一边把这套流程继续打磨下去。
我最近闲暇也在研究：怎么继续用 AI 做一个漫画网站。
这是我工具站的地址： projectcalcs.com
欢迎交流。
