一个大胆的假设：C语言之于汇编，Java之于C，Python之于Java，现在LLM智能体正在对所有编程语言做同样的事。
这里说的LLM智能体，指的是一种全新的开发模式：多个智能体并行工作，大部分时间自主运转，只在关键节点需要人类介入。判断这个假设是否成立的标准很简单：如果一个开发者借助多智能体能产出十倍于从前的成果，那它就是真的。2026年初的今天，我还不能完全确定，但已经在认真考虑这种可能性。
对于在软件行业摸爬滚打多年的人来说，质疑声不会少。先回应几个常见的：
“十倍代码量不等于十倍产出，那只是垃圾代码。”没错，衡量标准应该是实际交付的功能价值，不是代码行数。如果假设成立，真正的“代码”其实是你给LLM的指令。
“LLM是给不会写代码的人用的。”LLM确实会带来大量新程序员，但这不意味着老手用不上。事实上，很多资深开发者正在借助LLM实现产出的飞跃。
“用LLM就是偷懒不想动脑。”恰恰相反。当你用LLM做更多事情时，你需要思考和工作得更多，而不是更少。管理一支智能体舰队比自己写代码更费心力，因为你要设计的东西是原来的好几倍。
“LLM会让我们的编程技能退化。”可能吧。但我们在工作中也不会担心汇编或C语言技能生疏。大多数人只在业余时间练习这些，因为没人能证明用汇编写业务代码会更高效。
“LLM写的代码比我差太多。”几乎肯定如此。但你的汇编代码也比不上专家。只要LLM生成的代码足够高效，能跑起来，就已经可以交付了。系统会丑一些，但它能用。
“用LLM智能体太贵了。”如果它们能带来50%的生产力提升，对比你的薪资，其实一点都不贵。而且LLM只会越来越便宜。它们只在绝对值上贵，相对值上并不贵。
“我试了一下午，纯粹浪费时间。”学习曲线是存在的。想想你当初花了多少时间和编程工具、语法搏斗，才勉强上手。
以上这些反对意见在逻辑上都站不住脚，但情感上确实不容易接受。
真正触及核心的问题有两个：质量和可理解性。LLM生成的代码会不会很快变成一堆垃圾？我们是不是在沙子上建房子？LLM生成的代码量会不会大到我们永远无法理解？即使系统能跑，我们是否会因为不理解而永远失去控制？
我认为质量和可理解性应该成为任何LLM编程框架的核心目标。从经济角度看，只追求质量是不够的。可理解性可能是浪漫主义的幻想，也可能是一个值得押注的长期赌注。我选择后者。
有趣的是，LLM比以往任何高级语言都更具非确定性。但它们也能在高层次描述上帮你理清思路，这是以前任何抽象层都做不到的。
未来的开发会是什么样子？我看到四个核心要素：文档是一组描述系统规格的页面，包括目的、核心实体、接口、约束、关键流程和编码规范；实现是代码库加上所有数据，代码库应该能从文档重建，数据应该与文档描述一致；对话是多个智能体在执行任务时产生的思考流，人类可以随时查看或介入；任务是一组动态的离散工作单元，可以嵌套，有状态追踪。
两个存量，两个流量。文档和实现是系统的积累，对话和任务是构建它们的过程。人类当然可以直接修改文档和实现，但这种情况会越来越少，因为大部分工作流是智能体驱动的，人类主要在与智能体交互。
智能体可以扮演多种角色：独立完成任务的执行者、协调下一步的管理者、试图破坏新功能的测试者、脱离上下文审查代码的评审者、解决冲突的合并者。重要的是人类可以灵活配置，指令可以是一次性的，也可以是文档的一部分。
MCP协议带来了一个打破应用孤岛的机会。它可以被视为一种通用的数据请求接口，让你的智能体能够从任何现有应用中提取功能和数据，放到你自己设计的动态画布上。你可以说“从某个系统给我拿这些数据”，LLM就会去取，然后在你想要的地方做一个漂亮的即时可视化。这才是真正的孤岛终结者。
如果我们用一个好的底层基座而不是臃肿的技术栈，LLM输出的代码量会大幅减少，也更容易理解。系统的前端变成了文档和智能体，后端变成了基座。
还有一些开放问题：文档和对话如何与实现一起存储？版本控制系统怎么用？这些都等待探索。
有人分享了一套 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现在做所有的打字。你做所有的思考。
现在你没有任何借口了。去构建点什么吧。
