课程查看地址 ：@hodonote
有人分享了一套 claude.md 的配置框架，评论区炸了。不是因为内容多新颖，而是它戳中了一个被严重低估的真相：大多数人用 AI 编程，每次都在从零开始。
先说这套框架的核心逻辑。
第一条原则是「计划模式优先」。任何超过三步的任务，先停下来做规划。方向错了就立刻止损重来，别硬撑。写详细的规格说明来减少歧义。这听起来像常识，但多少人是一上来就让 AI 开干，然后在十五轮对话后才发现方向跑偏？
第二条是「子代理策略」。大方任务拆给子代理，保持主线程干净。复杂问题让子代理并行处理。一个子代理只做一件事。这本质上是在教 AI 学会分治，而不是把所有东西塞进一个上下文窗口里窒息。
第三条最关键，叫「自我改进循环」。每次纠正 AI 的错误后，让它把教训写进 lessons.md 文件。然后无情地迭代这些规则，直到错误率下降。每次开新会话，先回顾这些教训。
有人评论说得好： lessons.md 的循环才是真正能沉淀下来的东西。手动做了一周，效果立竿见影，它不再在你的代码库里犯同样的蠢错了。其他都是不错的默认设置，但这一条会复利增长。
还有几条值得一提。「验证优先于完成」，永远不要在没有证明代码能跑之前就标记任务完成。问自己：一个高级工程师会批准这个吗？「追求优雅但要平衡」，对于非平凡的改动，停下来问一句：有没有更优雅的方式？但如果改动很简单，就别过度工程化了。「自主修复 bug」，遇到报错就直接修，别等着被牵着走。
有个用户分享了自己的实践：三个月前开始维护一个 claude.md 文件，每周更新。提示词从十五轮对话缩减到两三轮。秘诀是记录失败而不只是成功。每次 AI 搞砸支付逻辑或导航流程，就把具体的修复方案加进去。现在文件里有四十七条规则，覆盖从 RevenueCat 集成到应用商店截图规范的所有细节。
他说了一句话我很认同：你其实是在训练一个专属的编程助手，让它学会像你一样思考。一旦调教好了，把项目交给任何人，他们都能得到同样质量的输出。
当然也有人泼冷水。有人指出这些 md 文件只是文本，没有基础设施来强制执行就没用。模型可能遵守，也可能不遵守，上下文一重置什么都不剩。还有人说这套框架缺了几样东西：目标清晰度、优先级排序、来自真实用户的反馈、时间约束、向他人学习的机制、产品思维。
这些批评都有道理。但我觉得重点不在于这套框架是否完美，而在于它指向了一个被忽视的方向：把你的使用模式变成活的配置文件。工具的威力，来自于习惯变成配置的那一刻。
有人开玩笑说 claude.md 是新时代的 .bashrc，每个人都有一个，但没人记得里面一半的内容是干嘛的。
但这恰恰说明它正在成为基础设施的一部分。
SST 创始人 Dax 发了一条很有意思的推文，大意是：你可以全程 vibe coding，没人拦你。你可以骗自己说这是聪明的策略。但所有人都能感觉到，你的作品里透着敷衍，透着你有多不在乎。因为你做一件事的方式，就是你做所有事的方式。
评论区炸了。
有人反驳说，我花大量时间设计架构、规划需求，只是让 AI 来写具体代码，这怎么能叫懒？工业革命时期肯定也有人这么批评机器。
也有人说，vibe coding 本身不是问题，不知道自己到底想要什么才是问题。当一个人真正理解自己的愿景时，他的 prompt 是锋利的；当他在偷懒时，就只会说“让它能跑起来”，然后陷入无尽的来回修改。
还有一条评论很精准：放弃亲手写代码这件事本身没问题，甚至可以提高效率。但如果放弃到连为什么这么做、怎么做的都不知道，那就危险了。
我觉得这场争论的核心其实不在于用不用 AI，而在于你有没有真正锁定问题，还是只在找捷径。
工具从来不决定你是哪类人。每一个承诺压缩努力的工具都会制造一个筛选机制：有人用它去做更有意义的事，有人用它来少做事。如果你所处的环境只衡量产出数量，无法区分深思熟虑的方案和随便生成的东西，那人们自然会选择阻力最小的路径。这不是懒惰，这是对不再重视深度的系统的理性反应。
vibe coding 用来从零到一很好用，但从一到一百的过程中，那些不在乎的部分会开始在日志和用户流失里显形。你没办法靠 prompt 永远绕过一个破碎的架构。
2025 年的真正高手，不是回避 AI，而是把它当成高精度仪器，而不是思考的替代品。
Dax 自己做了最好的 AI 辅助编程工具之一，却依然对 vibe coding 保持警惕。这种清醒值得尊重。
最近看到很多人急着上手 Clawdbot，Greg Isenberg 泼了盆冷水：如果你还没深度用过 Claude Code，别急着碰它。
道理很简单。Claude Code 是基本功训练场，你在这里学会提示词怎么写、代码怎么调、MD 文件怎么用、安全边界在哪里。而 Clawdbot 本质上是个放大器，它能把你现有的能力乘以一个系数，全天候帮你干活。
问题在于，放大器不挑好坏。你的能力强，它帮你事半功倍；你的能力弱，它帮你批量生产垃圾。
有人说得更直白：Clawdbot 是最终 Boss，Claude Code 是新手教程。跳过教程直接打 Boss，只会死得更快更花哨。
一位用户分享了他的笨办法：连续两周记录提示词日志。每次 Claude 给出完美输出，记下提示词结构；每次失败，记下问题所在。60 条记录之后，规律浮现了。80% 的好结果来自同样的 5 种提示词框架。现在他的机器人就跑这几套框架，稳定输出。
没有这个积累阶段，他只会把自己的错误自动化。
这让我想到一个更普遍的问题：我们总想跳过积累直达结果。但工具从来不创造能力，只是暴露能力。你用 Claude Code 写不出好东西，换成 Clawdbot 也不会突然开窍，只是错得更快、规模更大。
自动化一个烂流程，你只会以光速得到烂结果。
当然也有不同声音。有人认为不该自我设限，Clawdbot 有很多种玩法，不一定非要会写代码。这话也对，但前提是你得清楚自己在做什么。
真正的捷径往往是慢慢来。那些看起来一夜之间的成功，背后通常是无数次重复练习的积累。乔布斯说过，你无法预先把点连成线，只能回头看时才能理解。
所以别急。先把 Claude Code 用熟，把基本功打扎实。等你真正理解了底层逻辑，再去驾驭那个 24 小时不休息的助手。否则你不是在指挥一个强大的工具，而是在管理一团高速运转的混乱。
先把话说清楚：氛围编程本身没问题，问题出在你身上。
你听说可以跟AI对话就能写出软件，于是觉得自己是魔法师。打开AI，用一句话描述你的想法，然后期待奇迹降临。结果呢？代码一塌糊涂，界面颜色乱飞，页面跳转失灵，应用勉强能跑但随时崩溃。
然后你怪AI不行。
真相是：AI产生幻觉不是因为它坏了，而是因为你什么都没给它。没有结构，没有清晰度，没有基础。AI是翻译器，把你的意图转化成代码。但如果你的意图本身就是一团浆糊，代码自然也是浆糊。
修复方法不是更好的提示词，而是更好的理解。
一旦你真正知道自己在构建什么，提示词就变得简单了。
+ 文档先行，代码在后
这是所有人都搞错的地方。你打开Cursor，开始聊天，让AI立刻写代码。没有计划，没有参考，没有真相来源。这就是为什么你的项目在写了几个文件后就崩溃。
正确的系统是：先写文档，再写代码。永远如此。
在写任何一行代码之前，你应该先写好项目的规范文档。清晰、具体、没有歧义地描述你要构建什么。
为什么？因为AI编码工具能力很强但确定性很低。它们在没有结构性护栏的情况下执行任务。缺乏锁定的约束和权威文档会导致AI臆造需求、擅自做架构决策、写出解决你从未提出的问题的代码。
失败模式不是编码能力不足，而是纪律和上下文保持的缺失。
+ 六份核心文档
在动手写代码之前，你需要准备这些：
PRD.md是产品需求文档，完整规格说明。你在构建什么，为谁构建，有哪些功能，什么在范围内，什么明确排除在外。这是你的契约。AI读完就知道“完成”对你意味着什么。
APP_FLOW.md记录每个页面和用户导航路径。什么触发每个流程，成功时发生什么，错误时发生什么。这防止AI猜测用户如何在你的应用中移动。
TECH_STACK.md锁定每个包、依赖、API和工具的精确版本。当AI看到“用React”，它可能选任何版本。当它看到“Next.js 14.1.0, React 18.2.0, TypeScript 5.3.3”，它就会精确构建你指定的东西。
FRONTEND_GUIDELINES.md是你的完整设计系统。字体、精确十六进制色值的调色板、间距比例、布局规则、组件样式、响应式断点。AI为它创建的每个组件参考这份文档。
BACKEND_STRUCTURE.md定义数据库模式，每个表、列、类型和关系。认证逻辑、API端点契约、存储规则和边缘情况。
IMPLEMENTATION_PLAN.md是逐步构建序列。不是“构建应用”，而是：步骤1.1初始化项目，步骤1.2安装依赖，步骤2.1按前端指南构建导航栏组件。步骤越多，AI猜测越少。
+ 两个会话文件
CLAUDE.md是AI每次会话自动首先读取的文件。它包含每个AI会话必须遵循的规则、约束、模式和上下文。把它想象成AI针对你特定项目的操作手册。
progress.txt是所有人都忽略的文件。它追踪已完成、进行中和下一步的内容。每次完成功能就更新它，每次开始新会话AI就先读取它获取上下文记忆。没有它，每个新会话都从零上下文开始。
AI在会话之间没有记忆。当你关闭终端、打开新终端或开始新聊天，一切都消失了。progress.txt是你的外部记忆，是会话之间的桥梁。
+ 审问系统
在写文档之前，让AI把你的想法撕碎。
这是改变一切的提示词：“在写任何代码之前，在规划模式下无休止地审问我的想法。不要假设任何事情。问问题直到没有假设剩下。”
AI在你的清晰度结束的地方产生幻觉。所以如果你延伸你的清晰度，你就迫使AI在开始构建之前找到你思维中的漏洞。
+ 理解核心概念
组件是可复用的界面片段。按钮是组件，导航栏是组件，产品卡片是组件。当你说“给我建一个落地页”，AI必须决定创建什么组件。如果你不指定，它就猜测。
更好的提示词：“构建一个落地页，包含这些组件：导航栏、英雄区、功能网格三张卡片、推荐轮播、行动召唤区、页脚。”
状态是会变化的数据。当你点击按钮有事情发生，状态改变了。当你的按钮什么都不做，通常是状态问题。点击发生了，但没有东西告诉应用更新。
响应式意味着你的网站在所有屏幕尺寸上都能工作。移动优先意味着你先为最小屏幕设计，然后为更大屏幕添加复杂性。这不是偏好，是策略。
+ 工具链
Cursor是你的代码编辑器，有四种模式：Ask模式只读，用于理解代码；Plan模式用于在编码前架构；Agent模式是主力，自主写代码、编辑文件、运行命令；Debug模式用于顽固的bug。
Claude用于重度思考：审问想法、写六份核心文档、规划架构。
Kimi K2.5是前端实现的专家。你可以给它截图或设计稿，它生成紧密匹配视觉的功能性前端代码。
Codex是你的调试器和终结者。在文件和架构构建完成后使用它。当结构就位但东西在崩溃时，让它找到你遗漏的bug。
多工具工作流：Claude做思考，Cursor或Claude Code或Kimi K2.5做构建，Codex做调试和收尾。
+ 迭代是常态
每个人的第一个输出很少是对的。这没关系。
好的迭代：“产品网格在桌面端显示4列但我需要3列。卡片图片被拉伸了，应该是object-cover。数据获取时没有加载状态。”
坏的迭代：“看起来不对，修一下。”
具体。永远具体。
+ 发布前检查
在手机上能用吗？实际在手机上打开它。在不同浏览器能用吗？没有数据时会发生什么，空状态处理了吗？错误数据呢？慢网络呢？快速点击能打破它吗？
不要在回答这些问题之前发布。你的用户会找到你遗漏的每一个bug。
+ 完整系统总结
构建前：运行审问提示词，回答每个问题，生成六份核心文档，写CLAUDE.md，创建progress.txt，收集UI截图参考，初始化git。
构建中：AI每次会话先读CLAUDE.md和progress.txt，用Ask和Plan模式架构，用Agent模式实现，小块工作，给出引用文档的具体提示词，每个功能后提交git并更新progress.txt。
发布前：检查移动端、错误状态、空状态，验证秘钥隐藏，端到端测试主用户流程。
氛围编程不是黑魔法。它是细致的规划、系统、文档、词汇和迭代。你审问你的想法，写你的文档，设置持久化和自我改进，为每个阶段使用正确的工具，用具体术语描述工作，追踪会话间的进度，提交代码，然后发布。
AI现在做所有的打字。你做所有的思考。
现在你没有任何借口了。去构建点什么吧。
