这两天想做一个网站，把公众号的文章都放上去。用Claude Code做了一下，也复盘一下这次的过程，我的体会是：AI工具就像是倚天剑屠龙刀，在不同人手里可以发挥的作用会大大的不同，修炼自己，增强内功，才能更好地发挥工具的作用。
自己复盘
- 一开始没想用成熟的CMS框架，试一下从零开始用Claude Code做网站。
- 初期系统没想清楚怎么做，过分相信AI的能力，认为走一步看一步，即使不满意，重新让AI改应该很快就改过来了，然而对于大的架构变动，可能有些很细节的点，要和Claude沟通很久，这部分时间浪费掉了，这部分时间用在前期规划上面，会更好。
- 网站UI没刻意规划，只是让用Nextjs和Tailwind CSS，做出来效果还行，不满意的页面细节问题，可以截图问Claude Code，很快就可以改好，可见对于UI具体细节的问题，Claude还是很不错的 4.前期用了计划模式先和Claude沟通，对于它给的不同方案，要谨慎思考，不懂的最好先自己了解下这些技术和架构，别直接开干
- 最终让Claude Code复盘了一下这次的经验和教训，有助于下次更好的沟通。
Claude复盘：小百学AI 网站构建过程的经验与教训
时间：2026-04-01 项目：WeChat Content Manager（微信公众号内容管理网站）
一、实际走过的路径
第一步：Velite + MDX 静态站点（纯前端展示）
↓ 发现需要后台管理
第二步：在 Velite 基础上自建 Admin 后台（读写 MDX 文件）
↓ 发现发布文章需要重建，服务器内存不够
第三步：尝试 Payload CMS 替换自建后台
↓ 数据迁移困难、界面不如自建、集成复杂
第四步：撤回 Payload，改为自建后台 + PostgreSQL
↓ 最终方案
第五步：数据从 MDX 文件迁移到 PostgreSQL
理想路径应该是：
第一步：明确需求（前台展示 + 后台管理 + 持续运营）
第二步：选择 PostgreSQL + 自建 Admin 后台
第三步：开发完成
多走了 3 步弯路，浪费了大约 60% 的开发时间。
二、每一步弯路的根因分析
弯路 1：选择 Velite + MDX 而非数据库
表面原因： 项目初期只考虑了"前端展示"，没想到后面要做后台管理。
根本原因： 没有在开始时想清楚产品的完整生命周期。
- 问自己"这个网站只是展示，还是要持续运营？"——答案是持续运营
- 持续运营 = 需要频繁增删改内容 = 需要后台 = 需要数据库
- 这个推导链在项目开始时就应该完成
教训： 技术选型前，先回答"这个产品 6 个月后的使用场景是什么"。如果答案包含"持续更新内容"，就应该从一开始使用数据库。
弯路 2：在 Velite 上硬加后台
表面原因： 已经有了 Velite 的内容管道，不想推倒重来。
根本原因： 沉没成本心理——"已经做了这么多，在这基础上改吧"。
实际上 Velite 的设计哲学是构建时编译，它天生不适合"后台实时编辑 → 前台立即看到"的场景。在它上面加后台，等于逆着框架的设计方向走，必然遇到：
- 修改文件后需要触发 Velite 重建
- 重建需要时间和内存
- 开发时 watch 模式不稳定
教训： 当发现一个技术方案的设计哲学和你的需求方向相反时，越早换掉越好。在上面打补丁只会越陷越深。
弯路 3：选择 Payload CMS
表面原因： Payload CMS 功能全面，看起来能一步到位解决所有问题。
根本原因： 对"成熟方案"的过度信任，没有评估集成成本。
遇到的实际问题：
- Next.js 16 兼容性 — serverFunction 配置、双 html 布局冲突
- 数据迁移困难 — Markdown → Lexical JSON 格式转换复杂，图片引用丢失
- 迁移脚本问题 — REST API 被代理拦截、Payload Local API 依赖 Next.js 运行时无法独立使用
- 界面不可控 — Payload 自带的 admin UI 不如自建的贴合需求
教训： 引入一个大型框架之前，先做一个 30 分钟的 spike（技术验证）：
- 能跑起来吗？（兼容性）
- 数据怎么迁移？（迁移成本）
- 界面能满足需求吗？（UI 可控性）
如果任何一项不通过，就不要继续。
三、根本原因总结
所有弯路的共同根因：在开始动手之前，没有做充分的需求分析和技术评估。
具体表现为：
| 缺失的环节 | 导致的后果 |
|---|---|
| 没有列出完整的功能需求 | 选了只适合展示的技术栈 |
| 没有考虑运营场景 | 后期被迫加后台 |
| 没有评估技术方案的局限性 | Velite 上硬加后台 |
| 没有做技术 spike 验证 | Payload CMS 集成失败 |
| 沉没成本心理 | 每次都想"在现有基础上改"而不是"重新选择" |
四、下次项目应该怎么做
第一步：需求清单（动手之前必须完成）
在写任何代码之前，回答以下问题：
## 产品需求清单
### 1. 产品定位
- 这个产品是什么？（一句话描述）
- 目标用户是谁？
- 核心功能是什么？（列出 3-5 个）
### 2. 内容管理
- 内容从哪里来？（手动输入 / 导入 / API）
- 谁来管理内容？（我自己 / 团队 / 用户）
- 更新频率是什么？（每天 / 每周 / 偶尔）
- 更新后需要多快在前台看到？（实时 / 分钟级 / 可以等构建）
### 3. 部署环境
- 部署在哪里？（Vercel / 自有服务器 / 云服务）
- 服务器配置是什么？（CPU / 内存 / 带宽）
- 预算是多少？
### 4. 规模预期
- 初始内容量？（10篇 / 100篇 / 1000篇）
- 6个月后预期？
- 1年后预期？
### 5. 功能边界
- 需要后台管理吗？
- 需要用户系统吗？
- 需要评论/互动功能吗？
- 需要数据统计吗？
第二步：技术选型评估表
对每个备选方案，填写以下表格：
## 技术选型评估
| 评估维度 | 方案A | 方案B | 方案C |
|---|---|---|---|
| 是否满足核心需求 | |||
| 内容更新是否实时 | |||
| 服务器资源够不够 | |||
| 数据迁移难度 | |||
| 社区/文档成熟度 | |||
| 我是否了解这个技术 | |||
| 30分钟能跑通demo吗 |
关键原则：如果"30分钟能跑通 demo"这一项是"否"，直接排除。
第三步：和 AI 沟通的最佳方式
在对话开始时，提供以下信息：
## 项目背景
- 项目名称和一句话描述
- 当前阶段（全新项目 / 已有代码要改造）
- 已有的技术栈（如果有）
## 本次目标
- 我要实现什么功能？
- 完成标准是什么？（怎么算做完）
## 约束条件
- 部署环境和资源限制
- 时间限制
- 技术偏好/禁忌（比如"不要用 XXX"）
## 我的技术水平
- 我熟悉什么技术？
- 哪些我完全不了解需要你解释？
面对技术选型时，要求 AI 做对比分析：
不要问："用 Payload CMS 好不好？"
而是问："我的需求是 XXX，请对比以下方案的优缺点，特别是迁移成本和部署要求。"
在做重大决策前，要求 spike 验证：
不要直接说"开始集成 Payload CMS"。
而是说："先花 10 分钟验证一下 Payload CMS 能不能跑通，特别是数据导入和 Next.js 16 的兼容性。"
五、本项目最终技术架构
经过迭代后确定的最终方案：
┌──────────────────────────────────────────────┐
│ 前台 (用户) │
│ Next.js 16 App Router + 动态渲染 │
│ react-markdown + remark-gfm + rehype-slug │
│ Tailwind CSS v4 + shadcn/ui + next-themes │
├──────────────────────────────────────────────┤
│ 后台 (管理员) │
│ 自建 Admin (/admin) │
│ NextAuth v5 (Credentials + JWT) │
│ Markdown 编辑器 (textarea + toolbar + undo) │
│ 文章/分类/用户 CRUD │
├──────────────────────────────────────────────┤
│ 数据层 │
│ PostgreSQL 16 + Drizzle ORM │
│ posts / categories / users / login_logs 表 │
│ 图片: public/images/posts/{slug}/ (文件系统) │
└──────────────────────────────────────────────┘
核心优势：
- 后台发布文章 → 前台立即可见（无需重建）
- 自建 Admin 完全可控（界面、功能、交互）
- PostgreSQL 轻量稳定，2G 内存服务器够用
- 图片仍用文件系统，简单可靠
六、给未来的自己的 Checklist
开始新项目时，按顺序走完这个清单：
- 写完需求清单（第四节模板）
- 填完技术选型评估表
- 对首选方案做 30 分钟 spike 验证
- Spike 通过后再开始正式开发
- 每完成一个阶段，提交代码并记录决策原因
- 如果要推翻之前的选择，先评估沉没成本 vs 继续投入的成本
思考
回顾整个过程，最深的感触并不是"AI有多强"，而是 "人的判断力有多重要"。
很多人对AI编程有一种误解：觉得有了AI，写代码就变成了"说需求——等结果"的简单流程，似乎谁都能做出一个完整的产品。实际体验下来，远非如此。同样的工具，交给一个纯粹的编程小白和一个有架构经验的工程师，做出来的东西会是天壤之别—— 不是代码质量的差别，而是方向选择的差别。
AI擅长的是执行：你给它一个明确的任务，比如"写一个分页组件"、"修复这个样式偏移"、"把这段逻辑从回调改成async/await"，它可以做得又快又好，有时甚至比人写得更规范。但AI不擅长的是决策：用什么技术栈、数据流怎么设计、哪些功能应该放在第一期做、哪些应该砍掉，这些需要对业务场景的理解、对技术生态的判断、对资源约束的权衡。这些能力，不会因为你用上了AI就自动获得。
这次项目里走的弯路，没有一条是因为AI写错了代码。Velite的代码是正确的，Payload CMS的集成代码也是正确的，但方向本身就是错的。AI在每一步都忠实地执行了我的决策，问题在于决策本身缺乏深思熟虑。如果我一开始就想清楚"这是一个需要持续运营的内容站点"，那么技术选型的答案几乎是显而易见的。
所以在AI时代，真正值得投入精力的地方变了。
AI时代，什么能力更值钱
过去，程序员的大量时间花在记语法、查文档、调试细节上。这些事情AI可以大幅分担。但过去那些"高阶能力"——系统设计、需求分析、技术选型、架构权衡——反而变得更加重要了。因为AI放大了执行效率，一个正确的决策能更快地变成成果，一个错误的决策也能更快地变成沉没成本。
方向对了，AI帮你日行千里；方向错了，AI帮你在错误的路上狂奔。
AI编程和传统编程的本质区别
这也意味着，用AI编程的方式和传统编程方式有本质的不同。
传统方式是自底向上的：先写函数，再组模块，再搭架构，过程中逐步想清楚整体设计。这种方式可以容忍前期的模糊，因为你自己写代码的过程本身就是一个思考和澄清的过程。
但AI编程更接近自顶向下：你需要先把架构想清楚，把决策做明确，然后把一个个具体的、边界清晰的任务交给AI去实现。前期想得越清楚，AI的执行效率就越高；前期越模糊，后面返工的成本就越大。
换一种说法：传统编程的瓶颈是"写代码的速度"，AI编程的瓶颈是"想清楚的速度"。
不必焦虑，但要转变方向
理解了这一点，其实也不需要太焦虑。那些担心"AI会不会取代程序员"的人，往往把编程等同于"写代码"。但写代码从来只是软件工程的一个环节。需求理解、系统设计、技术决策、质量把控、上线运维——这些环节不但没有被AI取代，反而因为AI提升了编码速度而变得更加关键。 就像流水线的速度提高了，质检环节反而不能放松，否则次品出得更快。
对于想在AI时代保持竞争力的技术人来说，建议很简单：
把时间花在"不可替代"的能力上。 理解业务需求的能力、做架构设计的能力、评估技术方案优劣的能力、在多个约束条件之间做权衡的能力。这些能力需要经验积累，需要踩过坑，需要反复实践——AI目前做不了这些事，而且在可预见的将来也很难做到。
至于代码细节，把它放心交给AI。不是说细节不重要，而是说你的精力应该花在更高杠杆的地方。就像本文开头说的那样：AI工具就像是倚天剑屠龙刀，在不同人手里可以发挥的作用会大大的不同。修炼自己，增强内功，才能更好地发挥工具的作用。
选择比努力重要——在技术选型上如此，在个人成长的方向选择上，同样如此。
