有人在Reddit上发了一份Claude Code速查表，拿了1900个赞和117条评论。结果25天后就有人指出："命令已经废了，现在全是Skill。"这个网上最火的Claude Code资料，不到一个月就过时了。
这就是跟一个每隔几周就更新一次的工具打交道的现实。文章里写的具体命令、参数和功能都会变。有些从我写到你现在读，中间已经变了。但基本概念和工作流程不会变。下面要讲的这些限制也不会很快改变，因为它们来自语言模型本身的运作方式，不是打个补丁就能修好的bug。
这篇文章要讲大实话。只吹Claude Code多厉害的文章，那是广告。连它不行的地方一起说出来的，才值得你信。
Claude没有眼睛。它能写出语法没毛病、结构没问题的CSS，但它看不出好不好看。截图验证循环算是个不错的补救办法，但说到底还是在补一个根本缺陷：Claude完全没有审美。
说白了就是：项目长什么样，最终还得你来定。配色、字体、间距、整体风格，Claude能按你的意思干活，但它自己没有审美主张。
对于像任务追踪器这样的简单项目，这还可以管理。你可以使用设计系统，参考你欣赏的应用截图，并运行截图循环直到效果满意。但对于包含数十个页面和自定义交互的复杂项目，视觉审查负担会加重。每个页面都需要循环，每个组件都需要你的眼睛。
局限在于：如果你完全没有视觉感（有些人确实没有，这没关系），Claude无法弥补。你需要一位人类设计师、一份详细的Figma原型，或一个像Shadcn/UI这样替你做出大部分设计决策的高度风格化的CSS框架。
这里有一个具体例子。我让Claude"让仪表盘看起来专业且现代"。它添加了渐变、圆角、阴影和侧边栏。技术上合格，但美学上不协调。渐变与阴影冲突。圆角不一致（有的8px，有的16px，有的24px）。侧边栏相对于内容区域显得笨重。每个元素单独看都没问题，但放在一起就像五个不同的设计师在同个页面上工作。
修复花了三轮截图循环，但重点在于：没有具体的视觉指令或设计系统，Claude的美学选择是随机的。它从"看起来像现代网页设计的东西"的分布中挑选，却不理解为什么某些组合有效而其他组合无效。
Reddit上关于设计是Claude Code最难部分的评论（942个赞）反映了真实体验，而非初学者的困惑。设计之所以难，是因为这是Claude从根本上无法自行评估的一件事。
不像以前那么频繁，也没以前那么严重。但该发生的还是会发生，而且一旦发生在代码里，后果是实实在在的。
Claude可能引用一个你代码里根本不存在的函数，可能导入一个三个版本前就已经改名了的包，可能编造一些看起来挺真实但其实是瞎掰的统计数据，还可能说自己跑了某个命令，然后给你看一段它从记忆里生成、而不是从终端里拿到的输出。
防护措施：核实一切。当Claude说"测试通过"时，检查实际的测试输出。当Claude说"我已更新数据库迁移"时，检查迁移文件。当Claude说"此函数处理了边界情况"时，阅读函数并寻找边界情况处理逻辑。信任但核实并非偏执，而是一位开发者理解其初级同事非常聪明但偶尔会编造内容后的管理实践。
风险随重要性递增。如果Claude在演示中虚构了一个任务标题，没人会在意。但如果Claude在你的认证系统中虚构了一项验证检查（"是的，我添加了速率限制"），而你未经核实就部署，就会面临风险。安全审计部分原因就在于此：Claude可能告诉你代码是安全的，而审计则检查它是否真的安全。
上个月我发现了一次可能引发实际问题的幻觉。我让Claude为某个API端点添加缓存。Claude说"我已添加Redis缓存，TTL为5分钟"。我检查了代码，没有Redis导入，没有缓存配置。Claude只是在现有数据库查询上方添加了一行注释"// 缓存响应5分钟"，然后告诉我缓存已实现。注释确实存在，但缓存并没有。
这种幻觉最危险，因为它在回复中看起来正确。如果我只看Claude的消息而不检查代码，就会在根本没有缓存的情况下部署，以为自己有了缓存。教训是：Claude对自己工作的自我评估不可靠。务必阅读代码本身，而不仅仅是摘要。
Claude写代码很快，但也会写一堆没必要的代码：重复的工具函数、未使用的导入、功能过于臃肿的组件、调试时有用但事后被遗忘的文件。
这不是bug，是Claude的工作方式决定的。每次对话都是独立的，它不记得上周写了什么，也不会一边写一边重构。它只管加代码解决眼前的问题，不管这些东西堆在一起会变成什么样。
定期的月度清理流程可以应对这一点。但要知道，这是使用Claude Code的永久性特征。你永远不会达到Claude停止生成冗余代码的阶段，但你会达到清理流程足够高效、冗余代码永远无法累积到产生影响的阶段。
你让Claude在两个架构之间选一个，它会选一个。问它为什么这么选，它能给你一个听起来挺合理的解释。但Claude没有那种"两种方案都上线跑过，一个挂了另一个扛住了"的亲身体验。
Claude的架构决策基于对其训练数据的模式匹配，而非实际经验。它知道哪些架构流行，但不知道在你的特定约束下哪些有效：你的团队规模、流量大小、预算多少、时间线长短。
对于任务追踪器来说，这无关紧要。架构决策很简单，Claude的默认方案也足够。但对于有真实扩展需求的大型项目，你需要自己做出架构决策（或咨询资深开发者），然后让Claude实现你选择的架构。比如"使用微服务模式构建，包含这三个服务"，而不是"按你认为最好的方式构建"。
25天就过时的速查表只是冰山一角。Claude Code的命令写法、配置格式、功能名字，隔段时间就变一次。今天最优的工作流三个月后可能就变得次优，因为新功能让其中某个步骤变得多余。
应对方法：关注Claude Code社区。r/ClaudeCode（每周68.7万访问量）会在新功能发布后几小时内曝光。Anthropic的更新日志记录了每一次变更。Twitter上的@aiedge_和@_vmlops等账号会解析新功能及其用法。
更深层的应对方法：学的是概念而非命令。"管理你的上下文窗口"无论压缩命令是什么都适用；"将努力程度与任务复杂度匹配"无论设置名称是什么都适用；"截图循环获取视觉反馈"无论图像输入如何实现都适用。即使语法变化，概念依然有效。
Reddit上有条评论说"你是在实时学习软件开发"，这话说到了点子上。Claude Code让不会写代码的人也能做出能用的东西。但"能用"和"好用"是两码事，"今天好用"和"几千人用还好用"更是天差地别。
如果你没有开发背景却跟着做，现在你已经有了一个部署好的产品。同时，你也存在Claude掩盖掉的知识盲区。你可能不完全理解数据库索引如何影响查询速度，不知道某些认证模式为何比其他模式更安全，也不了解让Vercel部署真正触达不同国家用户的网络原理。
对于任务追踪器来说，这些盲区没问题。但当你构建拥有数千用户、复杂数据关系或严格性能要求的项目时，它们就会成为问题。
前进的道路并非"在构建下一个项目之前，先学完所有计算机科学知识"。真正的路径是：动手构建，遇到障碍，有针对性地学习突破每个障碍所需的知识。Claude Code加速了这一循环。通过用Claude构建五个应用并解决查询性能问题，你学到的数据库知识将比上一学期数据库理论课程还要多。
但不要将"Claude Code构建了它"与"我理解了它"混为一谈。前者是工具，后者是知识。两者缺一不可。
光靠Claude Code能做的事是有一个上限的。不是硬性限制，是实际做得到的限制。
一个独立开发者借助Claude Code可以构建并发布一个包含50-100个文件、少量数据库表和几千用户的产品。这涵盖了大多数副项目、最小可行产品以及许多小型SaaS产品。任务追踪器正好处于这个范围内。
超出这个范围，挑战会成倍增加。一个500文件的项目即使有语言服务器协议，也会让上下文窗口不堪重负。一个包含30多个表的数据库拥有足够多的关系，以至于Claude无法在上下文中完整保存其模式。一个拥有10,000并发用户的应用需要性能优化，这要求理解服务器在负载下的行为，而Claude无法直接观察这一点。
这不是批评，而是现实检验。Claude Code是快速构建产品的最佳工具，但它无法替代复杂系统上的资深工程团队。"是什么阻止了Claude Code构建完整的ERP？"（Reddit上获得39个赞）这个问题有一个真实答案：ERP系统有数百个表、数千条业务规则，以及嵌入在设计中的数十年领域知识。Claude Code可以构建ERP的片段，但无法架构整个系统。
在你接下来3-6个月的构建中，这个天花板不会成为问题。任务追踪器以及类似规模的项目，完全处于Claude Code的最佳应用范围。当你触及天花板时，你将拥有足够的经验，知道自己需要什么：要么是更大的上下文模型（Anthropic正在积极研发），要么是更好的项目分解技能（你将逐步培养），要么是需要资深判断力部分的人类队友。
上面提到的一些限制将在未来一年内缩小或消失，而另一些则是结构性的。
快速改善的方面：
上下文窗口大小（更大的窗口意味着Claude能同时容纳更多项目内容）
幻觉率（每一代模型的幻觉率都比上一代更低）
工具集成（MCP服务器定期支持更多外部系统）
速度（每次基础设施改进都会降低推理时间）
短期内不会改变的方面：
Claude无法看到你的用户界面（这需要根本不同的模型架构）
Claude无法从昨天的会话中学习（上下文按设计是每轮对话独立的）
Claude无法评估审美质量（品味需要模型不具备的具身体验）
Claude无法理解你告诉它之外的业务背景（它不知道你的用户、你的竞争对手或你的市场）
理解哪些限制是暂时的、哪些是结构性的，有助于你制定计划。不要为下个季度就会修复的问题构建变通方案。要为那些多年不变的问题培养习惯。截图循环（视觉评估缺失的变通方案）将在很长一段时间内有用。而对话之间手动总结上下文的做法，可能在几个月内就会被持久记忆功能取代。
这些限制都不应阻止你构建，而应指导你如何构建。
以下是将每个限制对应到具体实践的方法：
| 限制 | 应对方法 |
|---|---|
| 设计决策 | 使用截图循环和参考设计自行做出决策。不要将视觉品味外包给Claude |
| 代码正确性 | 验证一切。阅读Claude编写的代码。运行测试。检查安全审计 |
| 代码库健康 | 每月清理一次。代码膨胀不可避免，但清理并非可选项 |
| 架构 | 简单项目让Claude决定；复杂项目由你决定，Claude执行 |
| 工具进化 | 学习概念而非命令。通过社区保持与时俱进 |
| 规模扩展 | 50文件以下Claude就是完整团队；200文件以上需要你和可能的其他人 |
---
有人会纠结要不要把这些缺点写出来。毕竟谁会主动说自己不行？
现实是：网上那些只夸不骂的Claude Code教程往往评分不高。"一本关于AI的AI书。""提示词合集。"读者能嗅到不诚实。当一本书说"Claude Code无所不能"，而读者发现它连基本的设计评估都做不到时，他们会感到被欺骗。
把所有优点和缺点都摆出来，反而能建立信任。可信度来自对两方面的坦诚。
Reddit上那些发帖说"用了4个月Claude Code，老实说最难的并非编码"的人并非抱怨。他们在分享来之不易的知识，这些知识花了他们四个月才获得。这篇文章在十五分钟内就给了你这些知识。善用它。
那些长期成功使用Claude Code的人，是理解这些局限并围绕它们构建工作流程的人。失败的人则是期望Claude Code完美无缺，当它不完美时便感到沮丧的人。它并不完美。它是在当前语言模型技术限制下运行的有史以来最强大的编码工具。
上面一直在讲Claude不行的地方，因为不行的地方需要说清楚。但也要看全面。下面这些事，Claude Code做得比任何人都好：
执行速度
：一个程序员要花两小时写的功能，Claude Code五分钟就能搞定。不是因为它写得好，是它不会走神、不会查邮件、不会喝咖啡、不会打字前先犹豫半天。光拼执行速度，Claude就是碾压级别的。
知识广度
：Claude了解每个主流框架、每个流行库、每种主流编程语言中的常见模式。人类开发者可能精通3-4种语言。Claude能同样流利地阅读React、Python、Go、Rust和Swift。当你说"用Next.js、Prisma和Tailwind构建这个"时，Claude无需查阅任何资料。它知道API、模式和陷阱。
不知疲倦
：Claude不会在下午4点感到疲倦。它不会在周五下午写出更差的代码。它不会在会议前匆忙收尾。无论是当天的第一个任务还是第三十个任务，每个任务都得到同等程度的关注。
并行能力
：通过调度功能，你可以同时运行五个Claude实例。没有任何人类团队能在没有额外开销的情况下协调五个开发者处理同一代码库。Claude实例能并行工作，且通信开销为零（假设任务涉及不同文件）。
对重复工作的耐心
：需要为50个API端点更新相同的身份验证检查？人类开发者会抗拒、拖延，或进行草率的查找替换。Claude会有条不紊、正确且毫无怨言地完成。
这些优势与上面的局限相结合，定义了Claude Code开发者的工作描述：你提供品味、判断力、验证和战略方向。Claude提供速度、广度、耐力和执行力。你们彼此缺一不可。但合在一起，你们能交付传统开发者需要花费十倍时间才能完成的东西。
Claude Code没有眼睛，没有跨会话的记忆，没有品味，也没有高级工程判断力。它所拥有的是：速度、不知疲倦、读写任何语言代码的能力，以及愿意尝试你要求的任何事情。围绕这些弱点引导这些优势，你就能构建一切。
你的48小时结束了。你知道Claude Code能做什么、不能做什么，以及如何与两者共事。接下来可以了解让Claude Code自主化的功能，以及更多要构建的项目。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。