被AI烦到的一天
早上10点，你打开 Claude Code，充满干劲。
你：我想做一个电商网站
AI：好的！首先我们需要确定技术栈。你打算用 React 还是 Vue？
你：React 吧
AI：那 TypeScript 呢？用不用？
你：用
AI：状态管理呢？Redux、Zustand、还是 Recoil？
你：...Redux？
AI：数据库用 PostgreSQL 还是 MySQL？
你：（有点累了）PostgreSQL
AI：那 ORM 用 Prisma 还是 TypeORM？
中午12点，两个小时过去了。你一行代码还没写。
（如果你没经历过这种场景，那恭喜你。但很多人每天都在经历这个。）
第二天，更糟
你回来继续昨天的项目。
你：昨天我们聊的电商网站，继续
AI：好啊！那我们先用 Vue 还是 React？
你：？？？（昨天不是说好 React 吗）
或者更糟：
AI：抱歉，我们的对话太长了。要不你重新说一遍项目背景？
为什么会这样？
这不是 AI 的问题，是三个客观限制：
1. Token 限制
对话越长，越容易被截断。你聊得开心，突然被强制中断。
2. 上下文丢失
AI 只能看到最近的对话，早说的都会淡忘。你以为它记得，其实它已经忘了。
3. AI 倾向于做选择题
问用户"选A还是B"比自己做决策容易。于是你被各种选择题淹没。
结果你陷入一个循环：被问一堆选择题 → 选完就忘 → 第二天又问一遍 → 对话太长被迫重来。
我观察到的现象是：项目没死于"写不出来"，死于"选型选了一下午"。
（这不是什么数据统计，只是我反复看到的模式。）
一个反直觉的解决方案
我做了个技能叫 project-architect，核心机制很反直觉：
不让用户做选择题
等等，这不对吧？产品不应该让用户有选择权吗？
但限定一个条件：新手进入新领域时。
（如果你是专家，你当然可以自己选。这个机制是给那些"不确定该怎么选"的人准备的。）
新手做新项目，最该遵循的是"先完成再完美"。
在各个环节卡住做选择题，最后往往不了了之。反而效果更差。
那谁来做决定呢？
让另一个 AI 来选。
三大机制
project-architect 有三个核心机制，分别解决三个问题：
1. 持久化上下文——解决"AI 忘了"
技能会生成一个 CLAUDE_TEMPLATE.md，让你写入项目根目录的 CLAUDE.md。
关键：这个文件应该在 Phase 1 开始时就写入（记录项目背景），然后在每个阶段结束后追加更新——而不是等到最后。
里面记录了：
- 项目背景和目标
- 技术栈决策（为什么选 React 而不是 Vue）
- 架构设计
- 关键假设
- 当前执行到哪个阶段
这样即使对话中断了，新对话也能从 CLAUDE.md 快速恢复上下文。
局限：它不能完美恢复"刚执行完第 6 阶段"这种精确状态，但能避免"从头重新说一遍项目背景"。
2. 决策代理——解决"被问一堆选择题"
当遇到技术选型（React vs Vue、PostgreSQL vs MySQL）时：
技能不会问你"选哪个"，而是生成一个 AI_Decision_Matrix.md，包含：
- 各选项的优劣
- 对项目的影响
- 风险评估
然后你把这个文档发给 Gemini、Grok、或者另一个 Claude，让它给建议。
你只做最终决定，不用在中间环节纠结。
（如果三个 AI 给出三个不同的答案怎么办？没关系。跨模型对抗的目的是"获得不同视角"，而不是"获得唯一正确答案"。最终决定权在你手里。）
3. 11 阶段工作流——解决"做到一半没方向"
从概念到验收，完整 11 个阶段，每个阶段都有标准化输出，不会做到一半不知道下一步。
（看起来复杂，但技能会引导你一步步完成。你不需要记住所有阶段。）
跨模型对抗
Phase 1 结束后，技能会生成一个 Project_Context_For_CMC.md。
你需要把它发给其他 AI（Gemini、Grok 都行），问它：
这个方案可行吗？最大的坑是什么？
为什么要这么做？
因为单一 AI 有盲点。
问三个 AI，如果都说"可行"，那大概率真的可行。如果有两个说"这里有问题"，那就要重视。
这叫"跨模型对抗"——用不同 AI 的视角碰撞出更稳健的方案。
实战演示
假设你想做一个"AI 写作助手"。
你只需要说一句：
我想做一个 AI 写作助手，帮我规划一下
project-architect 会启动：
Stage 1-4：发散需求、找漏洞、修复、生成跨模型验证文档
- 输出：
Project_Context_For_CMC.md
你把它发给 Gemini，Gemini 说"总体可行，但你没考虑离线场景"。
Stage 5-7：失败模式分析、架构策略、最佳实践
- 输出：
Failure_Mode_Analysis.md、Architecture_Strategy.md
Stage 8-9：工具栈推荐、深化施工
- 输出：
Toolchain_Stack.md、各个里程碑的清单
Stage 10-11：质量保证、验收标准
- 输出：
QA_Report.md、Acceptance_Criteria.md
全程你不会遇到"选 React 还是 Vue"这种问题。
更简单的例子：个人博客
如果你只是想做一个简单的个人博客：
我想做一个个人博客网站
技能会：
- 询问你的需求（静态还是动态？要不要评论？）
- 推荐技术栈（比如 Hugo + GitHub Pages，因为简单免费）
- 生成部署清单
不会问你"用 Hugo 还是 Hexo"，而是直接给你一个推荐——你可以接受，也可以要求换一个。
递归触发
技能有个"递归触发器"：
遇到以下情况会自动启动"拷问模式"：
- 技术栈选型
- 核心架构变更
- 系统底层逻辑的子任务
- 发现未验证的关键假设
流程是：
- 发散 → 2. 拷问自身漏洞 → 3. 修复优化 → 4. 闭环结论 → 5. 返回主线
什么意思？举个例子：
假设你要选前端框架。
发散：React、Vue、Svelte、Solid.js…
拷问自身漏洞：
- React：生态好但学习曲线陡峭
- Vue：简单但可能在大型项目中遇到问题
- Svelte：新颖但生态不成熟
修复优化：结合你的项目（小型个人项目），Vue 更合适
闭环结论：推荐 Vue，理由是…
返回主线：继续下一个决策
这样你得到的不是一个"答案"，而是一个"经得起拷问的结论"。
这个技能到底是什么？
在继续之前，先澄清一下：
project-archect 是一组 Markdown 模板，不是可执行代码（没有 Node/Python 脚本，也不是 MCP Server）。
project-architect/
├── skill.md # 告诉 AI 如何响应
├── config.json # 配置触发词和阶段
├── CLAUDE_TEMPLATE.md # 项目上下文模板
└── templates/ # 各阶段的输出模板
它通过 Claude Code 的技能系统加载：当你克隆到 ~/.claude/skills/ 后，AI 会读取这些文件，按照定义的方式响应你的请求。
11 个阶段是指导原则，不是自动化的执行流程。AI 会根据这些模板逐步推进，但可能因 Token 限制或对话状态而调整。
怎么用？
核心就三步：
1. 克隆技能
git clone https://github.com/hongxiaojun/project-architect.git ~/.claude/skills/project-architect
2. 触发技能
在 Claude Code 里说：
- “我想做一个…”
- “帮我设计这个项目”
- “这个项目可行吗？”
3. 用的时候注意持久化
在 Phase 1 开始时，把技能生成的 CLAUDE_TEMPLATE.md 写入项目根目录的 CLAUDE.md。
然后在每个阶段结束后，追加更新这个文件（记录决策、当前阶段等）。
这样即使对话中断，新对话也能快速恢复上下文。
进阶：Phase 1 结束后，把 Project_Context_For_CMC.md 发给其他 AI（Gemini、Grok），获取反馈后告诉技能"CMC 反馈：…"，技能会继续 Phase 2-4。
（这一步不是必需的，但推荐做——跨模型对抗能发现更多盲点。）
写在最后
这个技能不是魔法，不能替你写代码。
它做的是：
- 用结构化的模板指导 AI 如何响应项目设计请求
- 通过
CLAUDE.md持久化项目上下文，减少重复沟通 - 提供一个完整的项目方法论（11 个阶段）
- 把"选 A 还是 B"的决策推给外部 AI，避免卡在选型上
即使有这些局限：
- 这是一组 Prompt 模板，不是自动化工具
- AI 可能因 Token 限制或对话状态而偏离阶段
CLAUDE.md能恢复上下文，但不能恢复精确的执行状态
它仍然有价值——因为它解决了一个真实存在的问题：跟 AI 聊项目时，很容易在选型和上下文丢失上浪费时间。
如果你经常：
- 跟 AI 聊着聊着就断了
- 被各种"选 A 还是 B"烦到
- 项目做到一半没方向
那试试这个技能吧。
至少，你不会再被"用 React 还是 Vue"这种问题卡住一整个下午了。