万字长文：为什么你Vibe Coding出的是一堆屎山，以及如何不再写屎山

万字长文：为什么你Vibe Coding出的是一堆屎山，以及如何不再写屎山 万字长文：为什么你Vibe Coding出的是一堆屎山，以及如何不再写屎山 Modified February 9 一旦你有了基础系统构建了多个项目，这些技术会让你的速度倍增。这些直接来自为生计构建 Claude Code 的人。 用 git worktrees 的并行会话。 这是单一最大的生产力解锁。不是一次只做一件事，旋转 3 到 5 个 git worktrees，每个在自己的 Claude Code 会话中并行运行。一个 worktree 构建认证系统。另一个构建仪表盘布局。第三个处理 API 端点。它们都共享同一个仓库但独立工作。你在它们之间跳跃，审查输出，批准更改，每个完成时合并。过去需要一整天顺序构建的东西变成几个小时的并行执行。给你的 worktrees 命名并设置 shell 别名，这样你可以一键在它们之间跳跃。 Plan mode 作为你的力量倍增器。 你已经知道使用 Cursor 的 Plan mode。这里是如何让它更强大：让一个 Claude 会话写计划，然后旋转第二个会话告诉它作为高级工程师审查计划。"审查这个实施计划。找到 gaps、我漏掉的边缘情况、任何会打破的东西。"在写一行代码之前修复计划。当实施期间出问题时，立即停止。不要继续推。切换回 plan mode 并从你所在的地方重新计划。也用 plan mode 做验证步骤，不只是构建。"规划如何验证这个认证流程处理所有边缘情况。" 复杂问题的子代理。 当问题大到单个 Claude 会话会在上下文上窒息时，使用子代理。追加"use subagents"到你的请求，Claude 会旋转专注的子会话来研究、探索、并行分析，同时保持你主会话的上下文窗口干净。每个子代理一个任务。把它当作委托给团队而不是自己做一切。 自定义技能和斜杠命令。 如果你一天做某事超过一次，把它变成可复用的技能或斜杠命令并提交到 git。构建一个 /techdebt 命令，在每个会话结束时运行，找到并杀死重复代码。构建一个 context sync 命令，拉取最近一周的 Slack、文档、GitHub 活动到一个 dump，这样 Claude 每次会话都完全知情开始。技能是你教 Claude 针对你工作流程的新能力的方式。它们在你接触的每个项目上复合。 自主 bug 修复。 停止手把手调试。当你得到 bug 报告时，粘贴到 Claude 里说"修复"。当 CI 测试失败时，说"去修复失败的 CI 测试。"不要解释如何。指向日志、错误跟踪、失败测试给 Claude。让它跟踪问题、找到根本原因、解决它。你零上下文切换。Claude 令人惊讶地擅长阅读 docker 日志、跟踪分布式系统、手动修复你会花几个小时的东西。 语音听写以获得更好的提示词。 你说话比打字快三倍，你的提示词因此得到显著提高。在 macOS 上，按 fn 键两次开始听写。对话式描述你想要什么，带着你通常会跳过的大量细微差别和上下文，因为打字很慢。更长、更详细的提示词产生更好的输出。语音是到达那里的捷径。 学习模式。 当你想理解 AI 在做什么，不只是让它做时，在 Claude Code 的配置中启用"解释性"或"学习"输出风格。Claude 会解释它做的每个更改背后的推理。你也可以要求 Claude 生成视觉 HTML 演示来解释不熟悉的代码，绘制架构和协议的 ASCII 图表，或从新概念构建间隔重复抽认卡。边构建边学习的人是最终停止需要这篇指南的人。 十九、Git 和版本控制 Git 跟踪你做的每个更改。 没有 git：你打破什么就无法撤销，你失去跟踪什么改了，一个错误可以摧毁一切。 有 git：每次更改都保存，你可以回到任何以前的版本，你的代码住在 GitHub 上不只是你的电脑。 基础： git add . 暂存你的更改。 git commit m "message" 用描述保存它们。 git push 上传到 GitHub。 git pull 下载最新更改。 当你在氛围编程时，经常提交。在每个有效的主要功能后："添加了用户登录"、"添加了产品网格"、"修复了结账 bug"。如果你打破什么，你总是可以回去。 这连接到你的 progress.txt 系统。提交代码，更新 progress.txt，推送两者。现在 GitHub 有你的代码和你的上下文文件。下次会话，拉下来，读 progress.txt，继续构建。 二十、环境变量和密钥 你的 API 密钥、数据库密码和密钥不应该在你的公共或生产代码库中。 它们放在 .env 文件里。 然后在你的代码中通过 process.env.YOUR KEY NAME 访问它们。 规则：永远不要提交 .env 到 git（加到 .gitignore）。永远不要在聊天中粘贴 API 密钥或用 AI 应用截图。如果你那样做，假设它已被泄露。永远不要在前端代码中放密钥，只在后端。开发和生产用不同的密钥。 当你部署到 Vercel 时，在 Vercel 的 dashboard 设置中添加你的环境变量。它们不会自动从你的本地 .env 转移。 如果你泄露了密钥，立即去那个服务撤销它。创建一个新的。 二十一、部署 你的代码在你的电脑上工作。现在它需要在互联网上工作。 Vercel 的流程： 推代码到 GitHub 连接 GitHub 仓库到 Vercel Vercel 自动构建和部署 你得到一个像 your app.vercel.app 的 URL 在 Vercel 的 dashboard 添加你的环境变量 当某些东西在本地工作但在部署时崩了，给 AI Vercel 错误日志。"它在 localhost 上工作但在 Vercel 上崩了。这是来自 Vercel 日志的错误："并粘贴错误。 99% 的部署 bug 是缺少 ENV 变量或错误的构建设置。 二十二、阅读错误信息 错误不是侮辱，它们是指令。 错误信息告诉你确切什么出错了。大多数人恐慌并忽略它们。请不要那样做。 错误剖析： Code block Plain Text Copy TypeError: Cannot read property 'map' of undefined at ProductList (src/components/ProductList.tsx:15:23) 翻译：TypeError 意味着你用错了什么。"Cannot read property 'map' of undefined" 意味着你尝试在不存在的东西上用 .map()。 ProductList.tsx:15:23 告诉你确切的文件和行号。 当你得到错误时，给 AI 一切： "我得到这个错误：[完整错误信息]。这是那行的代码：[粘贴相关代码]" 你给 AI 的错误上下文越多，潜在的修复就越快。 二十三、调试循环 当某些东西坏了时： 读错误。真的读它。 找到位置。什么文件，什么行。 理解声明。错误说什么是错的？ 检查明显的。拼写错误、缺失导入、错误的变量名。 给 AI 上下文。错误 + 代码 + 你期望什么。 循环：AI 给你代码 → 你尝试 → 它崩了 → 你粘贴错误 → AI 修复 → 重复直到工作。 对于在这个循环中存活两三轮的顽固 bug，切换工具。使用 Cursor 的 Debug mode。它生成多个假设，给你的代码插桩运行时日志，系统性地走过 bug 而不是猜测。或者启动 Codex。给它 bug 描述，让它跟踪你的代码库，识别跨文件的根本原因，迭代直到测试通过。Codex 特别擅长跨越多个文件或涉及数据流问题的 bug，因为它在提出修复之前读取整个仓库。 这是正常的。氛围编程不应该是通常的一次性方法，尽管我们喜欢那样看它。它是迭代。技能是快速迭代并知道何时使用哪个工具，不是完全避免迭代。 二十四、发布前验证 发布前，检查： 它在手机上工作吗？真的在你手机上打开它。 它在不同浏览器中工作吗？ 没有数据时发生什么，空状态处理了吗？ 错误数据时发生什么，错误状态处理了吗？ 慢网速时发生什么，加载状态存在吗？ 你能通过快速点击打破它吗？ 密钥在浏览器开发者工具中隐藏了吗？ 直到你回答了这些再发布。你的用户会找到你漏掉的每个 bug。 一丝不苟地做这个过程。 二十五、跟 AI 谈论所有这些 现在你有词汇表了...你需要使用它。 模糊提示： "给我构建一个用户可以发帖的 App" 有文档支持的特定提示： "首先读取 CLAUDE.md 和 progress.txt。然后构建 IMPLEMENTATION PLAN.md 的步骤 4.2。登录流程在 APP FLOW.md 第 3 节定义。使用来自 BACKEND STRUCTURE.md 第 5 节的认证设置。按照 FRONTEND GUIDELINES.md 样式化一切。匹配附加截图的 UI。" 同样的想法。完全不同的输出质量。 特异性不是额外工作，它是"工作"。你预先定义的越多，后来调试的越少。 二十六、如何阅读 AI 的输出 AI 给你一些代码。你知道你在看什么吗？ 你不需要理解每一行。但你需要理解结构。创建了什么文件？它们做什么？它们如何连接？ 当 AI 生成代码时，问这个："用 plain English 解释你刚构建了什么。每个文件做什么？它们如何连接？" 随着时间，你会开始识别模式。你会看到一个 import 语句并知道它在拉另一个文件。你会看到一个 useState 并知道它在跟踪变化的东西。你会看到一个 API 调用并知道它在获取数据。 这就是你从氛围编码者变成真正构建者的方式。不是通过记忆语法，而是通过理解模式。 二十七、如何迭代 每个人的第一次输出都很少是对的...这没问题。 迭代系统： AI 构建版本 1 你测试它，找到什么错了 你具体描述什么错了（不是"它坏了"，而是"提交按钮不保存到数据库，这是错误"） AI 修复它 你再测试 重复 好的迭代："产品网格在桌面上显示 4 列但我需要 3 列。卡片图片拉伸了，它们应该是 object cover。数据获取时没有加载状态。" 坏的迭代："它看起来不对，修复它。" 要具体。永远。 二十八、把大想法拆成小碎片 AI 在大而高的请求上窒息。"给我构建一个完整的电商网站"可能会产生绝对的垃圾。 拆成碎片： 设置项目脚手架和安装依赖 构建导航栏组件 构建产品卡片组件 构建产品网格页面 连接数据库并获取产品 构建单个产品页面 加入购物车功能 构建购物车页面 Stripe 结账 每个碎片是一个对话或一个任务。 每个建立在上一个之上，每个可以独立测试。把自己带回 LEGO 日子。实际上就是这样。 这字面上就是你的 IMPLEMENTATION PLAN.md 是什么。上面那个列表，编号和排序，正是你实施计划的精确格式。你不是在编码时即时创建它。你在开始前就创建了它。现在你只是执行它。逐步有计划地。 告诉 AI："构建 IMPLEMENTATION PLAN.md 的步骤 5。"不是"构建下一个东西"。精度复合。 这连接回你的 progress.txt 文件。在每个碎片后，更新 progress。用新鲜上下文开始下一个碎片。 二十九、什么时候 AI 是错的工具 有时候你只需要学习这个东西。 用 AI 来：生成样板代码、写重复逻辑、快速探索方法、用上下文调试、把你的意图翻译成代码。 自己学习：核心概念（这篇指南里的一切）、如何阅读 AI 生成的代码、如何发现 AI 错了、如何在 AI 帮不了时调试、你选择的栈如何基础工作。 如果你依赖 AI 做一切，你是在流沙上构建。一个奇怪的 bug 你会卡住并下沉。如果 AI 解释错了什么而你相信它，嗯...你完蛋了。所以也许，只是也许现在学习这些东西。另外：很多时候网站文档比 AI 信息更好。Stack Overflow 有对确切错误的精确答案。文档网站有权威信息。AI 擅长合成和生成，但当它失败时，知道如何搜索官方文档和网站是没人谈论的 fallback 技能。Claude 甚至可以从这些自学它需要的一切。 三十、范围和知道何时停止 一个永无止境的功能列表杀死比一些坏代码更多的项目。 当你完成时： 核心功能工作，用户可以完成主要行动，在常见路径上不崩，它已部署并可访问。 当你还没完成时： 它是"完美的"，每个边缘情况都处理了，它有你想象的每个功能，或它看起来完全像 Dribbble 设计。 发布简单版本并获取你的反馈。然后，基于真实使用改进。 你从未发布的最好的 App 比你已上线的普通 App 更糟。 三十一、维护你构建的东西 你构建了它，现在你需要改变它： 未来的你（或 AI）需要理解代码。这就是你的文档系统真正回报的地方。 你的 README 解释项目是什么。你的 CLAUDE.md 强制执行规则。你的 progress.txt 显示构建了什么和接下来是什么。你的规范 Markdown 文档定义产品的每个方面，从需求到实施顺序。 当你 3 个月后回到代码时： "阅读 CLAUDE.md、progress.txt 和 PRD.md。我在休息后回到这个项目。根据 IMPLEMENTATION PLAN.md 总结事情在哪里以及需要注意什么。" 好的文档让未来的氛围编码会话快 10 倍。坏的文档意味着从零开始。 保持依赖更新、在令人困惑的部分写注释、使用一致的命名、把你的代码库当作一个陌生人在 Airbnb 会访问并需要知道东西在哪里的家。 三十二、成本意识 API 调用花钱。数据库花钱。托管可能花钱。AI 工具花钱。 免费层存在而且它们很慷慨。Vercel 免费，Supabase 免费，Clerk 免费（有限制）等等。 对于你工作流程中的 AI 工具：Cursor Pro 覆盖大多数模型访问，是你的主要订阅。Claude Code 使用通过你的 Anthropic 或 Claude 计划。Codex 包含在 ChatGPT Plus、Pro 和更高层中。Kimi K2.5 是开源的，通过 Kimi.com 免费访问，API 定价慷慨。 你不需要第一天就每个付费层。从 Cursor Pro 和 Claude 或 Gemini Pro 3 开始。当你的工作流程需要时添加其他的。 知道什么是免费的 vs 什么会累积。AI API 调用（OpenAI、Anthropic）按 token 花钱。超过免费层后数据库存储花钱。规模上的图片托管花钱。 从免费开始。需要时扩展。 Kimi.com 一旦你有了基础系统构建了多个项目，这些技术会让你的速度倍增。这些直接来自为生计构建 Claude Code 的人。 用 git worktrees 的并行会话。 这是单一最大的生产力解锁。不是一次只做一件事，旋转 3 到 5 个 git worktrees，每个在自己的 Claude Code 会话中并行运行。一个 worktree 构建认证系统。另一个构建仪表盘布局。第三个处理 API 端点。它们都共享同一个仓库但独立工作。你在它们之间跳跃，审查输出，批准更改，每个完成时合并。过去需要一整天顺序构建的东西变成几个小时的并行执行。给你的 worktrees 命名并设置 shell 别名，这样你可以一键在它们之间跳跃。 Plan mode 作为你的力量倍增器。 你已经知道使用 Cursor 的 Plan mode。这里是如何让它更强大：让一个 Claude 会话写计划，然后旋转第二个会话告诉它作为高级工程师审查计划。"审查这个实施计划。找到 gaps、我漏掉的边缘情况、任何会打破的东西。"在写一行代码之前修复计划。当实施期间出问题时，立即停止。不要继续推。切换回 plan mode 并从你所在的地方重新计划。也用 plan mode 做验证步骤，不只是构建。"规划如何验证这个认证流程处理所有边缘情况。" 复杂问题的子代理。 当问题大到单个 Claude 会话会在上下文上窒息时，使用子代理。追加"use subagents"到你的请求，Claude 会旋转专注的子会话来研究、探索、并行分析，同时保持你主会话的上下文窗口干净。每个子代理一个任务。把它当作委托给团队而不是自己做一切。 自定义技能和斜杠命令。 如果你一天做某事超过一次，把它变成可复用的技能或斜杠命令并提交到 git。构建一个 /techdebt 命令，在每个会话结束时运行，找到并杀死重复代码。构建一个 context sync 命令，拉取最近一周的 Slack、文档、GitHub 活动到一个 dump，这样 Claude 每次会话都完全知情开始。技能是你教 Claude 针对你工作流程的新能力的方式。它们在你接触的每个项目上复合。 自主 bug 修复。 停止手把手调试。当你得到 bug 报告时，粘贴到 Claude 里说"修复"。当 CI 测试失败时，说"去修复失败的 CI 测试。"不要解释如何。指向日志、错误跟踪、失败测试给 Claude。让它跟踪问题、找到根本原因、解决它。你零上下文切换。Claude 令人惊讶地擅长阅读 docker 日志、跟踪分布式系统、手动修复你会花几个小时的东西。 语音听写以获得更好的提示词。 你说话比打字快三倍，你的提示词因此得到显著提高。在 macOS 上，按 fn 键两次开始听写。对话式描述你想要什么，带着你通常会跳过的大量细微差别和上下文，因为打字很慢。更长、更详细的提示词产生更好的输出。语音是到达那里的捷径。 学习模式。 当你想理解 AI 在做什么，不只是让它做时，在 Claude Code 的配置中启用"解释性"或"学习"输出风格。Claude 会解释它做的每个更改背后的推理。你也可以要求 Claude 生成视觉 HTML 演示来解释不熟悉的代码，绘制架构和协议的 ASCII 图表，或从新概念构建间隔重复抽认卡。边构建边学习的人是最终停止需要这篇指南的人。 十九、Git 和版本控制 Git 跟踪你做的每个更改。 没有 git：你打破什么就无法撤销，你失去跟踪什么改了，一个错误可以摧毁一切。 有 git：每次更改都保存，你可以回到任何以前的版本，你的代码住在 GitHub 上不只是你的电脑。 基础： git add . 暂存你的更改。 git commit m "message" 用描述保存它们。 git push 上传到 GitHub。 git pull 下载最新更改。 当你在氛围编程时，经常提交。在每个有效的主要功能后："添加了用户登录"、"添加了产品网格"、"修复了结账 bug"。如果你打破什么，你总是可以回去。 这连接到你的 progress.txt 系统。提交代码，更新 progress.txt，推送两者。现在 GitHub 有你的代码和你的上下文文件。下次会话，拉下来，读 progress.txt，继续构建。 二十、环境变量和密钥 你的 API 密钥、数据库密码和密钥不应该在你的公共或生产代码库中。 它们放在 .env 文件里。 然后在你的代码中通过 process.env.YOUR KEY NAME 访问它们。 规则：永远不要提交 .env 到 git（加到 .gitignore）。永远不要在聊天中粘贴 API 密钥或用 AI 应用截图。如果你那样做，假设它已被泄露。永远不要在前端代码中放密钥，只在后端。开发和生产用不同的密钥。 当你部署到 Vercel 时，在 Vercel 的 dashboard 设置中添加你的环境变量。它们不会自动从你的本地 .env 转移。 如果你泄露了密钥，立即去那个服务撤销它。创建一个新的。 二十一、部署 你的代码在你的电脑上工作。现在它需要在互联网上工作。 Vercel 的流程： 推代码到 GitHub 连接 GitHub 仓库到 Vercel Vercel 自动构建和部署 你得到一个像 your app.vercel.app 的 URL 在 Vercel 的 dashboard 添加你的环境变量 当某些东西在本地工作但在部署时崩了，给 AI Vercel 错误日志。"它在 localhost 上工作但在 Vercel 上崩了。这是来自 Vercel 日志的错误："并粘贴错误。 99% 的部署 bug 是缺少 ENV 变量或错误的构建设置。 二十二、阅读错误信息 错误不是侮辱，它们是指令。 错误信息告诉你确切什么出错了。大多数人恐慌并忽略它们。请不要那样做。 错误剖析： 翻译：TypeError 意味着你用错了什么。"Cannot read property 'map' of undefined" 意味着你尝试在不存在的东西上用 .map()。 ProductList.tsx:15:23 告诉你确切的文件和行号。 当你得到错误时，给 AI 一切： "我得到这个错误：[完整错误信息]。这是那行的代码：[粘贴相关代码]" 你给 AI 的错误上下文越多，潜在的修复就越快。 二十三、调试循环 当某些东西坏了时： 读错误。真的读它。 找到位置。什么文件，什么行。 理解声明。错误说什么是错的？ 检查明显的。拼写错误、缺失导入、错误的变量名。 给 AI 上下文。错误 + 代码 + 你期望什么。 循环：AI 给你代码 → 你尝试 → 它崩了 → 你粘贴错误 → AI 修复 → 重复直到工作。 对于在这个循环中存活两三轮的顽固 bug，切换工具。使用 Cursor 的 Debug mode。它生成多个假设，给你的代码插桩运行时日志，系统性地走过 bug 而不是猜测。或者启动 Codex。给它 bug 描述，让它跟踪你的代码库，识别跨文件的根本原因，迭代直到测试通过。Codex 特别擅长跨越多个文件或涉及数据流问题的 bug，因为它在提出修复之前读取整个仓库。 这是正常的。氛围编程不应该是通常的一次性方法，尽管我们喜欢那样看它。它是迭代。技能是快速迭代并知道何时使用哪个工具，不是完全避免迭代。 二十四、发布前验证 发布前，检查： 它在手机上工作吗？真的在你手机上打开它。 它在不同浏览器中工作吗？ 没有数据时发生什么，空状态处理了吗？ 错误数据时发生什么，错误状态处理了吗？ 慢网速时发生什么，加载状态存在吗？ 你能通过快速点击打破它吗？ 密钥在浏览器开发者工具中隐藏了吗？ 直到你回答了这些再发布。你的用户会找到你漏掉的每个 bug。 一丝不苟地做这个过程。 二十五、跟 AI 谈论所有这些 现在你有词汇表了...你需要使用它。 模糊提示： "给我构建一个用户可以发帖的 App" 有文档支持的特定提示： "首先读取 CLAUDE.md 和 progress.txt。然后构建 IMPLEMENTATION PLAN.md 的步骤 4.2。登录流程在 APP FLOW.md 第 3 节定义。使用来自 BACKEND STRUCTURE.md 第 5 节的认证设置。按照 FRONTEND GUIDELINES.md 样式化一切。匹配附加截图的 UI。" 同样的想法。完全不同的输出质量。 特异性不是额外工作，它是"工作"。你预先定义的越多，后来调试的越少。 二十六、如何阅读 AI 的输出 AI 给你一些代码。你知道你在看什么吗？ 你不需要理解每一行。但你需要理解结构。创建了什么文件？它们做什么？它们如何连接？ 当 AI 生成代码时，问这个："用 plain English 解释你刚构建了什么。每个文件做什么？它们如何连接？" 随着时间，你会开始识别模式。你会看到一个 import 语句并知道它在拉另一个文件。你会看到一个 useState 并知道它在跟踪变化的东西。你会看到一个 API 调用并知道它在获取数据。 这就是你从氛围编码者变成真正构建者的方式。不是通过记忆语法，而是通过理解模式。 二十七、如何迭代 每个人的第一次输出都很少是对的...这没问题。 迭代系统： AI 构建版本 1 你测试它，找到什么错了 你具体描述什么错了（不是"它坏了"，而是"提交按钮不保存到数据库，这是错误"） AI 修复它 你再测试 重复 好的迭代："产品网格在桌面上显示 4 列但我需要 3 列。卡片图片拉伸了，它们应该是 object cover。数据获取时没有加载状态。" 坏的迭代："它看起来不对，修复它。" 要具体。永远。 二十八、把大想法拆成小碎片 AI 在大而高的请求上窒息。"给我构建一个完整的电商网站"可能会产生绝对的垃圾。 拆成碎片： 设置项目脚手架和安装依赖 构建导航栏组件 构建产品卡片组件 构建产品网格页面 连接数据库并获取产品 构建单个产品页面 加入购物车功能 构建购物车页面 Stripe 结账 每个碎片是一个对话或一个任务。 每个建立在上一个之上，每个可以独立测试。把自己带回 LEGO 日子。实际上就是这样。 这字面上就是你的 IMPLEMENTATION PLAN.md 是什么。上面那个列表，编号和排序，正是你实施计划的精确格式。你不是在编码时即时创建它。你在开始前就创建了它。现在你只是执行它。逐步有计划地。 告诉 AI："构建 IMPLEMENTATION PLAN.md 的步骤 5。"不是"构建下一个东西"。精度复合。 这连接回你的 progress.txt 文件。在每个碎片后，更新 progress。用新鲜上下文开始下一个碎片。 二十九、什么时候 AI 是错的工具 有时候你只需要学习这个东西。 用 AI 来：生成样板代码、写重复逻辑、快速探索方法、用上下文调试、把你的意图翻译成代码。 自己学习：核心概念（这篇指南里的一切）、如何阅读 AI 生成的代码、如何发现 AI 错了、如何在 AI 帮不了时调试、你选择的栈如何基础工作。 如果你依赖 AI 做一切，你是在流沙上构建。一个奇怪的 bug 你会卡住并下沉。如果 AI 解释错了什么而你相信它，嗯...你完蛋了。所以也许，只是也许现在学习这些东西。另外：很多时候网站文档比 AI 信息更好。Stack Overflow 有对确切错误的精确答案。文档网站有权威信息。AI 擅长合成和生成，但当它失败时，知道如何搜索官方文档和网站是没人谈论的 fallback 技能。Claude 甚至可以从这些自学它需要的一切。 三十、范围和知道何时停止 一个永无止境的功能列表杀死比一些坏代码更多的项目。 当你完成时： 核心功能工作，用户可以完成主要行动，在常见路径上不崩，它已部署并可访问。 当你还没完成时： 它是"完美的"，每个边缘情况都处理了，它有你想象的每个功能，或它看起来完全像 Dribbble 设计。 发布简单版本并获取你的反馈。然后，基于真实使用改进。 你从未发布的最好的 App 比你已上线的普通 App 更糟。 三十一、维护你构建的东西 你构建了它，现在你需要改变它： 未来的你（或 AI）需要理解代码。这就是你的文档系统真正回报的地方。 你的 README 解释项目是什么。你的 CLAUDE.md 强制执行规则。你的 progress.txt 显示构建了什么和接下来是什么。你的规范 Markdown 文档定义产品的每个方面，从需求到实施顺序。 当你 3 个月后回到代码时： "阅读 CLAUDE.md、progress.txt 和 PRD.md。我在休息后回到这个项目。根据 IMPLEMENTATION PLAN.md 总结事情在哪里以及需要注意什么。" 好的文档让未来的氛围编码会话快 10 倍。坏的文档意味着从零开始。 保持依赖更新、在令人困惑的部分写注释、使用一致的命名、把你的代码库当作一个陌生人在 Airbnb 会访问并需要知道东西在哪里的家。 三十二、成本意识 API 调用花钱。数据库花钱。托管可能花钱。AI 工具花钱。 免费层存在而且它们很慷慨。Vercel 免费，Supabase 免费，Clerk 免费（有限制）等等。 对于你工作流程中的 AI 工具：Cursor Pro 覆盖大多数模型访问，是你的主要订阅。Claude Code 使用通过你的 Anthropic 或 Claude 计划。Codex 包含在 ChatGPT Plus、Pro 和更高层中。Kimi K2.5 是开源的，通过 Kimi.com 免费访问，API 定价慷慨。 Kimi.com 你不需要第一天就每个付费层。从 Cursor Pro 和 Claude 或 Gemini Pro 3 开始。当你的工作流程需要时添加其他的。 知道什么是免费的 vs 什么会累积。AI API 调用（OpenAI、Anthropic）按 token 花钱。超过免费层后数据库存储花钱。规模上的图片托管花钱。 从免费开始。需要时扩展。 不要为第一天就为数百万用户做架构。 因为现实是你可能根本不会达到那个目标。从小开始。 三十三、安全基础 最低要求： 永远不要在前端代码中暴露 API 密钥。总是在后端验证输入（不要相信来自浏览器的任何东西）。使用 HTTPS