2026/6/75 次阅读0 条评论

AI 时代 solo 个人开发的核心矛盾和推荐框架

你的优势 你的劣势 ───────────────────────────────────────────── AI 可以 30 秒生成一个功能 AI 不知道你的代码库长什么样 AI 可以同时写前端+后端+SQL AI 一次改 50 个文件，你不知道哪些变了 AI 不会累, 可以无限迭代 AI 不会累, 可能把你的正确代码改崩 你可以只专注产品和想法 你没有同事 review AI 的产出

Terminal

所以 AI 时代的 solo 开发流程，不是为了规范化而规范化——是为了管理 AI 的风险。

────────────────────────────────────────────────────────────────────────────────

三层流程框架

不是线性流程，是三个持续运行的轨道：

第一层：安全网（防止 AI 搞崩你的代码） ├── Git（知道 AI 改了什么） ├── 类型系统（AI 写错时编译报错） └── 自动化测试（AI 改完验证功能没坏）

第二层：效率引擎（让 AI 更好用） ├── 领域文档（让 AI 理解你的业务） ├── 规范文件（让 AI 遵守你的约定） └── 提示词模板（减少重复沟通）

第三层：交付管道（从代码到用户） ├── 开发环境（你 + AI 改代码） ├── 预览环境（看一眼效果） └── 生产环境（用户访问）

Terminal

────────────────────────────────────────────────────────────────────────────────

第一层：安全网

### Git：AI 的撤销键，不只是备份

没有 Git： AI 改了一下午代码 → 你不知道改了哪些文件 → 某个功能突然崩了 → 你：哪个改动导致的？→ AI：不知道 → 你：完了

有 Git： git diff # 精确看到每行改动 git log --oneline # 看到改动历史："AI 改了分页逻辑" git bisect # 自动二分法定位哪个 commit 引入的 bug git revert # 精确撤销某次改动，不影响其他

Terminal

对 AI 开发来说，Git 真正的价值是 diff。 git diff 让你能审计 AI 的输出。你看的不是 AI 生成的代码对不对——你看的是 AI
改动的东西有没有你不希望它碰的。AI 经常在修 bug 时顺手"优化"了旁边的代码，git diff 让这种行为无法隐藏。

### Git 的实操：只学四个命令

```bash
  git add .                           # 把改动加入暂存
  git commit -m "一句话描述"           # 保存一个快照
  git push                            # 传到远程
  git diff                            # 看改动

高级的以后再说。每天用这四个就够了。

类型系统：AI 的第一道检查

Terminal
  TypeScript（强类型）：
    AI 写：user.nickName
    tsc 编译：Property 'nickName' does not exist → ❌ 编译不过
    AI 修正：user.nickname  ✅

  PHP（无类型标注）：
    AI 写：$user->getNickName()
    浏览器：500 Internal Server Error
    你：？？？？？？？

类型检查是 AI 幻觉的自动检测器。 这是 Next.js/TypeScript 对 AI 开发最重要的优势——不是性能、不是生态，是编译器替你做 code review。

测试：不是写不写的问题，是让 AI 写

传统开发的痛点：写测试很烦，没人写。

AI 时代：30 秒生成一个测试文件。你没有理由不测。

Terminal
  // 你：帮我把积分转账的逻辑写几个测试
  // AI：
  describe('transferPoints', () => {
    it('正常转账：A给B转50积分', async () => { ... })
    it('余额不足时报错', async () => { ... })
    it('不能给自己转账', async () => { ... })
    it('并发转账不会导致余额负数', async () => { ... })
  })

原则：让 AI 写测试，你只确认测试覆盖了关键路径。 不用追求覆盖率，只测三类：

  1. 核心业务流程（积分转账、VIP 激活）
  2. 历史 bug（修过一个 bug 就加一个测试，防止 AI 以后改回来）
  3. 并发/边界情况（余额为 0、文章为空、用户名太长）

────────────────────────────────────────────────────────────────────────────────

第二层：效率引擎

领域文档：让 AI 理解你的业务

你的 CREATOR_PLATFORM_PLAN.md 就是这个。但格式可以更 AI 友好：

Terminal
  # CONTEXT.md（放项目根目录）

  ## 这是什么项目
  耽美小说创作平台。用户可以转载/投稿小说、积分激励、VIP 付费。

  ## 核心业务规则
  - 积分只能由平台发放，用户间可以打赏（transfer_points）
  - VIP 通过兑换码激活，不是直接购买
  - 小说内容存储在文件系统，不是数据库
  - 每章一个 JSON 文件

  ## 技术栈
  - Next.js 14 App Router + TypeScript + Prisma
  - 数据库 MySQL，共享实例，每项目独立 database
  - 部署用 Coolify + Docker

  ## 当前进度
  - 已完成：WordPress 版本的基础功能
  - 进行中：迁移到 Next.js
  - 下一步：阅读器分页

为什么这是你最重要的文件？ 因为每次新对话、每次换一个 AI 模型，它不知道你的产品是干什么的。你把 CONTEXT.md 喂给它，等于每次对话都带着你的项目文档。这比每次解释一遍"我们的积分系统是这样的"省无数时间。

规则文件：让 AI 遵守你的约定

项目根目录放一个 rules.md 或 .cursorrules（看 AI 工具支持什么）：

Terminal
  ## 代码规范
  - 所有函数必须有返回类型标注
  - 数据库查询不要用 findMany({ select: ... })，用 Prisma 的 include
  - 路径导入用 @/ 别名，不要用相对路径 ../../
  - UI 组件用 shadcn/ui，不要手写

  ## 禁止事项
  - 不要引入新的 npm 包除非确认必要
  - 不要在组件里直接写 fetch
  - 不要改动 prisma.schema 除非明确要求

  ## 测试要求
  - 任何修改积分/VIP 的代码，必须有对应测试

AI 遵守规则的能力比你想象的好。但前提是规则写下来——口头约定 AI 不记。

────────────────────────────────────────────────────────────────────────────────

第三层：交付管道

不是 CI/CD 那个 CI/CD，是适合你个人的轻量管道

Terminal
  开发（VPS 上 Claude Code）
    │
    ├── 随时改，随时 git commit
    │
    ├── 改完一个功能 → git push
    │
    ▼
  Coolify（或者你自己写的脚本）
    │
    ├── git pull
    ├── npm ci
    ├── npx prisma migrate deploy
    ├── npm run build
    ├── npm start（新进程）
    └── 旧进程关闭（零停机）
    │
    ▼
  用户看到新版本

你不需要 GitHub Actions、不需要 CI 服务器。 Coolify 做的事情本质上就是上面这几步——只是它帮你自动化了。如果你不想用 Coolify，甚至可以用一个 bash 脚本替代：

Terminal
  #!/bin/bash
  # deploy.sh - 放在项目根目录
  set -e
  git pull
  npm ci
  npx prisma migrate deploy
  npm run build
  pm2 restart reader
  echo "部署完成"

然后 git push && ssh vps './deploy.sh'。

不要过早自动化。 手动 deploy 三个月，等你真的烦了再加 Coolify。不然你连 Coolify 的黑盒出了什么问题都诊断不了。

────────────────────────────────────────────────────────────────────────────────

一周的真实节奏

Terminal
  周一：
    上午：看产品，确定本周做什么
    下午：Claude Code 开发功能 A
    [git commit -m "功能A: 添加章节预加载"]
    [git push → 部署到线上]

  周二：
    上午：Claude Code 开发功能 B
    下午：发现功能 A 有个 bug
    [git diff 查看功能 A 的改动]
    [Claude Code 修 bug]
    [git commit -m "修复功能A的预加载时机"]
    [git push → 部署]

  周三：
    上午：Claude Code 做重构（抽一个 shared UI 组件）
    [git diff 确认 AI 没有乱改其他页面]
    [npm run test → 测试通过]
    [git push]

  周四：
    上午：Claude Code 开发功能 C
    下午：用户在群里反馈 bug
    [git log 看最近改动 → 定位到周三的重构是原因]
    [git revert 回滚重构]
    [git push → 紧急修复上线]
    晚上：调查为什么重构导致 bug，写测试覆盖

  周五：
    上午：根据一周的用户反馈确定下周计划
    下午：给功能 A 补充测试用例

────────────────────────────────────────────────────────────────────────────────

组件清单：你需要的东西，按优先级

┌───────────┬──────────────────┬───────────────────────────────┬─────────────────────┐ │ 优先级 │ 东西 │ 一句话 │ 谁来维护 │ ├───────────┼──────────────────┼───────────────────────────────┼─────────────────────┤ │ 🔴 必须 │ Git │ AI 的撤销键 + 改动审计 │ 你每天用 │ ├───────────┼──────────────────┼───────────────────────────────┼─────────────────────┤ │ 🔴 必须 │ 类型系统 │ AI 的第一道检查（TypeScript） │ 编译器自动 │ ├───────────┼──────────────────┼───────────────────────────────┼─────────────────────┤ │ 🔴 必须 │ CONTEXT.md │ AI 的业务说明书 │ 你每次改完更新 │ ├───────────┼──────────────────┼───────────────────────────────┼─────────────────────┤ │ 🟡 重要 │ 测试 │ AI 写的，防回归 │ AI 写，你跑 │ ├───────────┼──────────────────┼───────────────────────────────┼─────────────────────┤ │ 🟡 重要 │ rules.md │ AI 的编码规范 │ 你写一次 │ ├───────────┼──────────────────┼───────────────────────────────┼─────────────────────┤ │ 🟡 重要 │ Git 远程仓库 │ 代码不丢 │ Gitea/GitHub │ ├───────────┼──────────────────┼───────────────────────────────┼─────────────────────┤ │ 🟢 慢慢来 │ 自动部署 │ git push 就上线 │ Coolify │ ├───────────┼──────────────────┼───────────────────────────────┼─────────────────────┤ │ 🟢 慢慢来 │ 监控/日志 │ 线上出问题知道 │ Coolify 自带 │ ├───────────┼──────────────────┼───────────────────────────────┼─────────────────────┤ │ ⚪ 不需要 │ CI/CD Pipeline │ 对你一个人来说是过度设计 │ 别搞 │ ├───────────┼──────────────────┼───────────────────────────────┼─────────────────────┤ │ ⚪ 不需要 │ Code Review 流程 │ 你没有 reviewer │ 别假装有 │ ├───────────┼──────────────────┼───────────────────────────────┼─────────────────────┤ │ ⚪ 不需要 │ Jira/项目管理 │ 你不需要给自己开 ticket │ 一个 TODO.md 足够了 │ └───────────┴──────────────────┴───────────────────────────────┴─────────────────────┘

────────────────────────────────────────────────────────────────────────────────

一句话总结

在 AI 时代，solo 开发者的竞争力不在于你会多少工具，而在于你的"安全网"有多薄但多结实。 最结实的四根绳子是：

  1. Git → 知道 AI 改了什么，随时撤销
  2. TypeScript → AI 写错了编译不过
  3. 测试 → AI 帮写的，验证功能没坏
  4. 领域文档 → AI 知道你的产品是什么

其他都是锦上添花。这四个是底线。

分享文章:
最后更新于: 2026/6/7
上一篇
个人使用的神级WordPress开发的Cursor规则Rules模板
下一篇
已经是最后的一篇文章了