6 周的 Claude Code 使用感悟

共有 552 条讨论

1. 我使用 Claude Code 大约两周了，老实说，作为一个对编码持怀疑态度的人，我感到非常惊讶。它有一个学习曲线。你需要学习如何给它提供适当的上下文，如何将工作分块等。当然，你还需要知道如何编程。要求它做你不知道如何做的事情，那只是自找麻烦。我拥有超过 25 年的经验，因此我对 Claude Code 尝试做的任何事情都充满信心，可以审查它，或者停止并重新定向它。大约 10-15 年前，我梦想着一种神经接口，让我无需编写任何代码就能进行编程。我意识到，Claude Code 已经实现了这种梦想。

   有几次，我达到了每日限额，于是决定尝试使用 2.5 pro 版本的 Gemini CLI 作为替代。但它与 Claude Code 根本无法相比。Gemini 带来的挫败感完全不值得。

   过去，我无法想象每月为一个开发工具支付 100 美元以上的费用，但现在我正在认真考虑升级到 Max 计划。

   回复

   1. 如果你是一位资深开发者，能够给初级开发者提供建议，并指导他们解决问题(或只是短暂介入并指出他们遗漏的部分)，那么这正是为你准备的。我从各地的资深开发者那里听到，初级开发者在这方面表现得一团糟。他们编写出低效、不安全或直接糟糕的代码，然后提交他们甚至不理解的代码。

      对我来说，理想的场景是处理模板代码(根据描述提供一个类的蓝图)、将 JSON 转换为类，或转换为其他格式。此外，“这段代码有什么问题？资深工程师会如何处理？”这类问题也非常有用。我曾通过询问“我刚刚手动敲击键盘输出的这段代码有什么问题”来在调试前发现 bug。

      回复

      1. 没错，就是这样！

         几周前，我有一点空闲时间，想到了一个我想实现的新算法。在我脑海中，它看起来非常简单，以至于 1)我认为解决方案已经众所周知，2)编写起来相当容易。于是，我要求 Claude“为我编写一个执行 Foo 的 python 函数”。我花了一个上午的时间来回沟通，却一无所获，完全没得到我想要的结果。

         我不知道是什么启发了我，但我开始假装自己在和一位初级工程师交流。我首先要求一个更简单的函数，它正朝着我想要的方向发展(严格来说，它是我想实现的数学逆函数)，然后我要求它修改该函数以添加一个不同的变换，接着又添加另一个，再添加另一个。最后，当函数终于实现了我想要的功能时，我让它写出逆函数。它做到了。

         令人惊奇的是，这个过程涉及的线性代数和边界情况比我最初想象的要复杂得多，如果靠我自己研究，可能需要几周时间才能搞清楚。但将AI作为研究工具和初级工程师的结合体，才是关键。

         我认为，如果我们走“氛围编程”的路线，最终会出现大量不理解任何东西的初级工程师，而他们用AI生成的东西将是垃圾且脆弱的。但将AI作为工具使用开始让我感到更有吸引力。

         回复

         1. 大语言模型(LLM)永远不会承认它不知道发生了什么，但随着时间的推移，你会逐渐培养出一种感觉，知道它什么时候在做某件事，什么时候陷入了一个看似合理但实际上毫无意义的循环。

            编辑：有趣的是，你只需说“这看起来有点糟糕，因为x原因，一定有办法让它更好”，就能让它改善输出。

            回复

            1. 我曾尝试指示CC极度怀疑自身，并假设它无法正确验证任何内容。

               这导致它抛出了用于验证和编写代码的好点子。

               我希望存在一个理想的平衡点。

               那些不断出现的“啊哈！”式回应，随后伴随自我验证的文字，声称答案近在咫尺，这种体验虽令人陶醉，却不可信。

               该产品似乎处于持续调优的状态，有些会话能取得显著进展，而另一些则让人感觉AI刻意引导用户走向错误方向。

               Anthropic曾暗示这与负载有关。他们在关于Max用户新限制的备忘录中提到，订阅级别的滥用导致了~较差的产品体验。他们可能指的是响应时间和过载导致的500错误或低于正常水平的TPS，但许多长期用户(包括我)都有CC突然表现不佳的轶事记录。

               我不明白负载如何影响实际模型的性能。

               似乎只有基于负载对单个会话上下文的影响才会导致输出质量下降。但我对大规模提供大语言模型(LLM)一无所知。

               有人能解释一下高负载如何导致产品性能客观下降吗？

               回复

         2. “我们最终会得到一群什么都不懂的初级员工，以及他们所产出的东西”

            我职业生涯的大部分时间都花在清理这种无稽之谈上，所以未来看起来很光明。

            回复

      2. 是的，作为一名高级开发人员，我需要花费大量时间审查来自海外承包商的初级代码，并给出非常详细和明确的指示，因此，尝试使用 Claude Code 等代理型大语言模型 (LLM) 编码工具对我来说就像天赐良机。

         我对这些初级开发人员使用此类工具也感到担忧，因为如果他们无法提供正确的上下文，也无法区分好方案与坏方案，他们将产出大量技术上可行但质量低劣的代码。

         回复

         1. 完全同意关于离岸开发的部分。我已经不得不将任务分解为清晰的细节，并在前期自行解决任何预期的阻碍，以避免跨时区、跨日期的反复沟通。

            现在我已经习惯了这样做，离岸部分不再有价值

            回复

            1. 印度的失业率将达到灾难性水平。地缘政治因素。

               回复

               1. 许多自认为核心业务非技术型的公司更倾向于使用一支可随时替换的中级开发人员团队来构建解决方案。拥有高技能开发人员对他们而言是风险。

                  回复

               2. 不太可能。微软在全球各地都进行了裁员，唯独印度例外。在那里他们仍在持续招聘。只要他们能持续提升技能且成本仍远低于美国工人，就无需担心失业。

                  就在昨天，我在X上看到一段迈阿密酒店的视频，入住手续是通过视频通话与印度的接待员完成的。

                  回复

                  1. 六个月后，如果那位员工仍然在职，他将管理大量接待员虚拟形象。随后他们自己也将被取代。这仍将导致劳动力市场的大规模崩溃，而随着过剩劳动力涌入，现有岗位即便工作量过大，薪资仍将停滞甚至下降。

                     回复

               3. 你知道高级开发人员也可以被外包吧？

                  回复

                  1. 摧毁初级到高级的晋升管道，平均而言将对每个国家造成相同冲击。

                     不过这提出了一个有趣的观点：如果像印度或中国这样的国家确实投资于招聘、支付和指导初级人员，而例如美国没有这样做，那么在10年左右(上下浮动)的时间里，全球软件专业知识的重心可能会发生巨大转变。

                     _有人_会在这方面最擅长规划和投资未来，而_有人_则会陷入过度乐观或短期思维，而那种看似诱人但实际上并不存在的编码氛围，很可能成为关键转折点。

                     回复

                     1. 这是一个非常重要的观点。我不确定印度的情况，因为印度仍然非常依赖市场力量，但中国可以强制其雇主做任何具有战略重要性的事情。这种情况在美国早已不复存在。这里的市场力量只会优化短期利益，最终害了自己。

                        回复

         2. 啊，兄弟，我对离岸开发部分感同身受。我最近经历了一件非常令人难过的事情，我不得不解雇了一个离岸团队，因为他们提供的开发人员基本上是“有副驾驶的初级人员”，却被标榜为“高级人员”。

            我一次又一次地发现他们将大语言模型(LLM)的输出结果放入 PR，然后声称这是他们自己的成果。这本来不是问题，但代码没有按照详细票证的要求运行，结果引入了其他错误。

            最终，我面临的选择是“费力地制作详细的简报，然后将它原封不动地放入副驾驶，然后费力地审查它并向离岸开发人员解释问题”，或者“直接向 Claude 简报”。

            我讨厌这么说，但从商业角度来看，后者完全占上风。这违背了我的道德观，让我感到非常痛苦。

            回复

            1. 为什么这违背了你的道德？听起来这完全是一个理性的商业决策，只影响了一个表现不佳的合作伙伴。

               回复

               1. 我明白你的意思，但这让我觉得有点不人道。就像为一个生命体定义一个价值，然后确定他们低于这个价值。

                  回复

                  1. 是的，在某些时候，一些对道德问题毫无顾忌的高层人士会为你做出这样的决定……

                     回复

         3. 没错。

            当我尝试使用我不熟悉的语言/技术(React，别怪我)的大语言模型(LLMs)时，我遇到了很多麻烦。

            但对于我熟悉的东西(比如 Go 或 Python)，大语言模型(LLMs)大大提高了我的工作速度，但需要注意的是，当它产生我明确不想要的东西时，我必须明确地告诉它(与大语言模型(LLMs)争论也是一次有趣的经历！)。

            回复

      3. > 我从各地的资深开发者那里听说，初级开发者在这方面简直一无是处。他们编写的代码要么速度慢，要么不安全，要么就是糟糕透顶，然后他们还会提交自己都不理解的代码。

         如果情况确实如此，那么我们最好在未来10年内实现完全由AI生成的代码，因为这些“初级开发者”将永远停留在初级水平，而老一辈开发者则会逐渐退出舞台。如果我们作为一个领域认为这种情况绝不可能发生，那么我们正在犯一个巨大的错误，即依赖一个需要“深度[正交]经验”才能正确操作的工具。

         回复

         1. IT教育和计算机科学(至少部分领域)需要更加注重软件工程和软件架构技能的培养，以教导开发者如何掌控人工智能开发工具。

            回复

            1. 最快的方法是通过实践。先学会自己做。理解为什么它不起作用。什么是好代码？什么是坏代码？什么是规范？

               没有捷径——你不是因为拥有计算器就成了会计师。

               回复

            2. 大脑不是计算机，我们不会通过被给予抽象规则来学习。我们从课堂教学中学习的效果也远不如在现实生活中为真实目的而做事情——大脑总是知道其中的区别，而且在教学环境中，(真实的、非人为创造的) stakes 较低。

               这也是人工智能与大脑之间的巨大差异：人工智能并非基于真实世界运作，而是基于我们的沟通(甚至这种沟通仅限于文本，缺乏面对面沟通所包含的所有细微差别)。大脑基于真实世界的传感器数据运作。沟通方式——语言——只是在大脑真正运作方式之上的一种非常有限的附加功能。我们并不以语言进行思考，即使进行一些基于语言的抽象思维，例如进行形式化数学运算，也需要高度集中和努力，并且仍然依赖大量“底层”直觉。

               这就是为什么即使经过多年的相同课程学习，我们仍然需要为每一个具体例子付出巨大努力，以确保“ everyone on the same page”，在内部形成兼容的模型。每个人对简单事物的内部模型都略有不同，这取决于他们带到学习中的大脑以及他们具体学到了什么，甚至像社交课堂互动这样的因素也会影响连接的形成。只有通过巨大的努力，我们才能使用语言进行抽象沟通，即便如此，当我们脱离核心思想的中心走廊时，人们仍会因定义问题争论不休。无论书面文本如何一致，每个人的内部模型都各不相同。

               作为一名学习过神经科学的学者，我发现这段描述出奇地精准：

               “大脑不喜欢抽象，除非你强迫它这样做”

               http://howthebrainworks.science/how_the_brain_works_/the_bra…

               > 这份由伦敦大学教育神经科学中心(CEN)成员编制的资源，为普通读者简要概述了大脑的工作原理。它基于最新研究成果，旨在概述大脑功能的基本原理，涵盖大脑的进化起源、发育过程以及在现代社会中的适应机制。

               学习的最佳方式是通过实际行动去探索有意义的事物。学校教育是一种妥协，其实并不算特别出色。那些出于实际需求而学习的人，往往能够以显著更快的速度，获得更深入且更好的学习成果，而这些成果在学校教育中可能需要数年时间才能达到中等水平。

               回复

               1. 没错。大学教育的唯一优势，我指的是_唯一_非社交/人脉方面的优势，在于被迫学习/思考复杂的理论概念，这些概念构成了在工作中学习专业实践要求的必要基础知识。

                  职业学校和证书课程旨在培养某一领域具备熟练工水平技能的人员。它们会反复训练你掌握日常工作中所需的实际要求、任务、故障排除工具和技巧等，以便你能够直接进入工作现场并发挥作用。这些领域通常面临一组可预测的技术问题，因此深入的理论探索是没有必要的。这一点对于电工和汽车修理工来说同样适用，也适用于从事有限但物流复杂的技术工作的人员，比如使用所有微软企业工具来管理大量Windows工作站。

                  在软件开发及其他需要应对复杂理论问题的领域，你确实需要兼具实践与理论背景才能高效工作。这对学校而言是一项不切实际的任务，这也是为何我们设有实习、 externship 或初级职位。

                  这些工具的结合使得部门中的资深员工能够承担所有工作，从而公司无需投资于实习生或初级员工，导致该领域缺乏可靠的入职途径。此外，学校提供的教育内容与企业所需技能之间的脱节现象愈发严重，这使得行业面临艰难时期，而目前正试图在该领域立足的大量人将陷入困境。我有点惊讶于科技行业中如此多的人似乎对初级从业者即将面临的艰难道路漠不关心。我想这可能是因为大多数高级开发人员与初级人员互动较少，以及在许多资深员工加入行业时，所有人都争先恐后地招聘开发人员。

                  回复

                  1. 这种想法并不特别道德，但如果你目前是中级或高级开发人员，初级开发人员管道的断裂将在几年后对你个人有利。

                     如果最终发现软件工程师仍然需要，但过去五年没有人培训他们，这可能非常有利。

                     回复

               2. 而人工智能的最大优势在于，它能在有限时间内让你尝试更多可能性。如果你有想法，就用人工智能来实现它，测试它，看看哪里会出问题。人工智能将极大推动教育发展，因为它能支持更多实验和实践操作。

                  回复

                  1. 通过使用人工智能，你学会了如何使用人工智能，而非必然掌握如何构建架构稳健且易于维护的软件。因此，在有限时间内能完成更多任务，并不一定能让你成为更专业的程序员，或者说这种知识很可能仅停留在表面模式识别层面。它仍需与亲手构建自己的项目相结合，才能真正理解此类项目的核心原理。

                     回复

                     1. 如果你最终得到一个你理解所有组成部分的可工作项目，我认为人工智能非常适合学习，而最终证明学习是否成功的标准就是你是否能够实际构建(并发布)东西。

                        因此，人类教师也是有益的，但我记得在我没有使用人工智能学习编程时，他们对我帮助有限。他们试图教给我的许多概念，他们自己可能都没有真正理解。如果使用AI，我可能会得到更好的答案，而不是在问为什么以某种方式做某事时，得到“因为这就是做法”这样的回答。

                        显然，我更希望一直有合格的老师，现在也希望有无限时间的合格老师，而不是有缺陷的AI来教学生，但现实是人类的时间是有限的，人类本身也有缺陷。因此，我并不认同对新一代程序员的末日预言。最终目标——按照规格构建能正常运行的系统——并未改变，而20年前也曾有过糟糕且难以维护的代码被交付。

                        回复

                     2. 我不同意这种观点。对我来说，从手动编写源代码切换到AI编写源代码，就像在木工项目中从手锯切换到电锯一样。最终你仍然需要了解木工，但你会进行更多的实验，因此学到更多。

                        或者也许更像是从模拟摄影转向数字摄影。无论如何，你都能完成更多的编程工作。

                        就像从汇编语言到C语言，再到像Java这样的内存管理语言。35年前有人在使用6502和68000汇编语言，现在几乎没人再用汇编语言了。

                        回复

                        1. > 对我来说

                           关键在于此。对你来说，这是一台电动锯，因为你已经会编程，而这就是别人的观点；这并不一定能赋予人们构建软件的能力。你？是的。但通常当你把电动锯交给公众并说“动手吧，造东西”时，结果往往是大量肢体受伤。

                           遗憾的是，在这种情况下，“失去的肢体”将是人们花费数十年时间来清除振动编码器在数字公共领域中埋下的地雷。这意味着AI甚至作为比喻中的“电动锯”也失败了，因为一把好的电动锯应该通过承诺误用时的致命伤害来让用户感到恐惧。AI 没有这样的滥用威慑机制，因此人们会随意滥用它，直到后果猛烈反弹，而影响范围是社区级别的。

                           > 更像是从模拟摄影到数字摄影的转变。无论是什么，你都能完成更多的编程工作。

                           从数量上看，数字摄影的主要成果是一大堆毫无意义的照片，以至于我们不得不发明新词来分类它们。“自拍”。‘色情短信’。“美食打卡”。当然，人工智能将增加实际编程的工作量，就像数字摄影为我们带来了更多的摄影艺术一样。但更重要的是，人工智能将带来相当于“美食摄影”的现象，但针对的是程序。这有点像苹果应用商店为我们带来了些许优质应用，但同时也有数以亿计的旅行指南和手电筒应用。当你降低门槛时，也打开了洪水闸门。

                           回复

                           1. 能够更快更便宜地完成某件事，往往会确保更多人学习基础知识。电动工具让更多人接触木工，数字摄影也是如此，更多人愿意花时间学习基础知识。当然也会有更多人制作垃圾作品，但这真的是个问题吗？

                              借助AI，专业人士可以以低成本快速询问AI：这个垃圾软件能做什么，你能根据这些指南为我创建一个更 robust 的版本吗？

                           2. >借助AI，专业人士可以快速且低成本地询问AI：“这个垃圾软件能做什么，你能根据这些指南为我创建一个更 robust 的版本吗？”

                              目前，这在足够复杂的软件中行不通，似乎还要求源代码可用(或完美规格)。

                              在“大语言模型(LLMs)是否已经真正破解了大型产品的复杂性”(与人类监督的补丁或全新演示相比)方面，我关注的一点正是你所说的这种重新实施和改进。就像一个全新的 Photoshop 替代品一样。

                           3. > 遗憾的是，在这种情况下，“丢失的肢体”将是人类花费数十年时间来清除振动编码器在数字公共领域中布下的所有地雷。

                              你是不是对这些技术能获得 traction 过于乐观了？

                           4. 悲观，但确实如此。我的一生就是一系列最糟糕的想法被大规模实施的历程，所以我看不出来这会打破这种趋势。

                     3. > 通过使用AI，你学会了如何使用AI，但不一定学会如何构建架构稳健且易于维护的软件

                        > 并不一定能让你成为更专业的程序员

                        我认为我们最好开始区分“构建软件”与“编程”，因为编程行为本身将越来越不值钱。

                        我认为编程在人工智能出现之前就已经被严重高估了。而行业本身也深信这种炒作，其中掺杂着一股精英主义。

                        但现在人工智能正在揭开这层伪装，它表明想法和架构才是真正重要的部分，而不是编码本身。

                        回复

                        1. 我发现你谈论“行业相信自己的炒作”然后继续对人工智能大加赞赏，这非常讽刺。

                           回复

                           1. 好吧。但大多数开发人员并不是在构建人工智能技术。相反，他们正在编写 SPA 或 CRUD 应用程序，或者其他已经做过 10000 次的事情，只是做的方式略有不同。这正是大语言模型(LLMs)如此擅长这种(编程)工作的原因。

                           2. 我认为大多数人处理工单和关于工单的会议的时间，比实际在编辑器前编程的时间还要多。虽然两者可能相似，但那1%的差异必须精准把握，因为这正是业务生命线所在。

                              此外，并非所有开发工作都涉及网页技术或人工智能技术。

            3. 遗憾的是，人工智能的普及正严重损害全球教育质量，既包括学生借助AI逃避作业，也包括教师的批改反馈被聊天机器人取代。

               回复

         2. 若从未成长，便不会萎缩。初级员工将停滞不前，而资深员工才会真正萎缩。

            至于这是否是个错误，这不就是当今世界的常态吗？当前世界就是趁着还在这里的时候尽可能多地攫取。看看周围。没有人是在为未来建设。虽然有少数小众群体在讨论这个问题，但没有人真正去做。就是一味地攫取、攫取、攫取。

            这似乎只是更多相同的事情，但我们正在加速。我们从数百万年前沉积的化石燃料开始提取，然后从数千年前沉积的文明中提取资源和技术，然后从仅有一两百年历史的维多利亚时代中提取，现在则是从仅有几十年历史的软件中提取。有人会承担后果，我们只希望那不是我们。与此同时，大多数人甚至没有意识到这一点，而那些意识到的人中，大多数人都在幻想技术会在报应到来之前拯救我们。

            回复

            1. 悲哀，但非常真实的观察

               回复

      4. 是的，我很快注意到了初级开发人员存在的问题。无论是否是初级开发人员，有些开发人员尚未接触过那种对他们的PR进行严格审查的环境。他们习惯于宽松的环境，不幸的是，他们没有准备好将LLM更改置于所需的审查水平之下。

         最糟糕的是，即使是较小的PR，也包含大量看起来多余或不合适的更改。在提出问题后，代码发生了变化，但问题却未得到解答，而且很可能又出现了一系列新问题。我发誓，我一直在通过工程师/PR 中间人提示大语言模型(LLM) 🙁

         回复

         1. 我们的离岸开发人员一直在这样做，这让我感到非常恼火。我的问题没有得到解答，却推送了完全不同的代码。

            回复

            1.   > 我的问题没有得到解答，却推送了完全不同的代码。
               

               在什么情况下，这种成本会高于收益？

               回复

               1. 确实如此，但大多数高管并不关心长期利益，他们只想在3-4年内离职前拿到绩效奖金

                  回复

                  1. 这就是你如何获得Oracle源代码的方式。这在我大学毕业后进入大型公司编程时，打破了我的幻想，很多年前的事了。这也导致了这个精彩的HN评论：https://news.ycombinator.com/item?id=18442637

                     回复

      5. 一个观察结果。如果我们规定“高级开发人员”可以从 Claude Code 中获益，而初级开发人员则不能，那么我怀疑这是否会造成一种差距，即一群新晋的“10 倍”工程师在做一群初级开发人员协助的工作，而你现在不再培训任何新初级开发人员，因为他们无法就业。这是正确的吗？

         回复

         1. 这已经是一个事实，不是吗？你可以让一位资深开发者在一周内完成你的项目，或者给他们一个初级开发者团队，整个团队需要四周时间，而且效果更差。

            然而，公司仍然选择第二种方法。这与头寸带来的地位有关吗？

            回复

            1. >> 这与人员数量带来的地位有关？

               通常被解读为确保“关键员工因素”大于1

               回复

            2. 是的，有些公司出于各种原因选择建立低效的组织结构。但观察到的是：这是否会导致“最低”程序员成为我们今天所说的“高级开发人员”？这与机械师转型为CAD/CAM工作站操作员以控制加工中心，而非亲手操作铣床或车床的转盘的过程相似。这似乎意味着通过“编程训练营”进入该领域将不再实用。

               回复

               1. 十年后，当整个一代初级员工都没有接受过培训时，大语言模型(LLMs)能否完成所有工作，这将是一个有趣的问题。我猜很多公司都愿意打赌答案是肯定的。

                  回复

                  1. 问题在于这里存在一种囚徒困境——可能有些人意识到，十年后仍可能需要软件工程师，但由于2025年无人培训初级工程师，届时可能出现人才短缺。

                     然而，注意到这一点并没有帮助，因为如果你在 2025 年投资培训初级员工，但其他人没有这样做，那么其他人就可以在 2030 年招聘他们，从你的投资中获益。

                     回复

                  2. 只要大语言模型(LLMs)不是这个周期的“冷聚变”，当然可以。:-)

                     回复

            3. “浪费”精力在新人身上，正是资深开发者来源。因此，这种做法仅适用于个人独资企业、初创公司早期阶段或紧急情况。

               回复

            4. n=1，但我的经验是，我所定义的“资深”开发者(按给定示例)与其他人的比例舒适地保持在10:1。

               回复

               1. 你是说每11名开发人员中，有10名是“资深”开发人员(如示例所示)？还是只有1名？

                  回复

                  1. 1名资深开发人员对应10名其他开发人员。抱歉之前表达得不清楚。

                     回复

      6. 让克劳德编写工具，我得到了物有所值的回报。我们实现了梦想，我可以随心所欲地编写一些一次性软件，这太棒了；今天，我用几秒钟就制作了两个不同的(虽然很糟糕但可以使用！)图形用户界面程序，让我可以直观地描述一些测试数据。如果我的第一个想法不错，那么另一种选择可能是花半个小时来制作一些东西。然后，我删除了它们，继续做其他事情。

         它仍然会不断生成一些离谱的东西，但我发现它非常有助于快速生成一次性工具和进行头脑风暴。我尝试让它完成我不知道如何实现的任务(例如计算机视觉实验)，虽然最终往往无法成功，但我经常从中学习到东西，而且我对订阅服务仍然非常满意。

         回复

      7. 我还发现它擅长发现错误并帮助撰写提交信息。

         “审查最顶层的提交。我是否犯了任何错误？我是否在提交信息中遗漏了什么？”

         有时我会让它为我撰写提交信息：

         “为当前提交撰写新的提交信息。”

         我不得不告诉它如何编写提交信息。它喜欢发表主观意见，使用最高级形容词，并猜测某件事为何被这样做。我不得不告诉它停止这样做：“总结发生了哪些变化。简洁但全面。避免使用形容词和最高级形容词。使用命令式语气。”

         回复

         1. 这对我来说太疯狂了。

            审查自己的代码。理解你为什么做出这些更改。然后清楚地描述你为什么做出这些更改。如果你自己做不到这一点，我认为这是你技能上的巨大缺口。

            让其他东西来做意味着你没有真正理解你所做的更改。

            回复

            1. 你的评论并不是对我的写作的公正解读。

               需要说明的是，在我长达数十年的职业生涯[^0]中，我撰写的提交信息比我认识的几乎所有人[^1,^2,^3,^4,^5]都更清晰详尽。但我并非不会犯错，而且每个人都可能需要编辑工具，或单纯耗尽了脑力。遗憾的是，我发现很难从同事那里获得高质量的PR审核。

               所以，是的，我开始使用 Claude Code 来帮助审查自己的提交。这并不意味着我不理解自己的更改，或者不知道为什么进行这些更改。CC 擅长撰写提交消息的初稿。它还擅长发现测试和人工审查中遗漏的细微逻辑错误。效果出奇地好。您应该试试。

               我对CC也有很多批评。我不确定它是否真的为我节省了时间。过去两周我每天工作10小时都在使用它。对于某些事情，它表现出色。对于其他事情，我可能自己从头开始编写代码会更好，这种情况现在大约占40%。

               [^0]: https://seclists.org/bugtraq/1998/Jul/172

               [^1]: https://github.com/git/git/commit/441adf0ccf571a9fe15658fdfc…

               [^2]: https://github.com/git/git/commit/cacfc09ba82bfc6b0e1c047247…

               [^3]: https://github.com/fastlane/fastlane/pull/21644

               [^4]: https://github.com/CocoaPods/Core/pull/741

               [^5]: 这些都不是我最好的例子，只是我快速找到的。我大多数的提交信息显然都被雇主锁定了。在 Git 历史的某个地方，有一段长达数段的提交信息，是 Jeff King(peff)解释一个一行差异的。那可能是我有史以来最喜欢的提交信息。但我也知道，在工作中，我某个地方有一段信息解释了一个单字符的差异。

               回复

         2. 我建议的是，对于所有文档、读我文件和PR描述，都要保持“简洁、无华丽辞藻、无表情符号”。这样可以将所有内容精简为直奔主题的文档，避免GPT式的表达和表情符号的滥用，让它看起来不像又一个前端框架的读我文件。

            回复

         3. 如果你在输入所有这些提示后仍然领先，你的提交消息有多长？

            回复

            1. 我的提交描述部分，如果需要，是关于更改的原因，而不是解决方案的具体细节。这是给阅读差异的人的一份简短备忘录，而不是一篇长篇大论。而且差异通常很小。

               回复

         4. 这是个好主意！你是让 claude 使用原子提交，还是手动复制/粘贴输出？

            将你的摘要说明保存为 CLAUDE.md

            回复

            1. 我会根据情况告诉它提交或修改。然后，我会在编辑器中打开消息，修改它写的内容。

               回复

      8. 也可以确认。Claude 代码的几乎所有输出都需要我仔细输入进行更正，只有你有经验才能发现并提供更正。初级开发者无法熟练使用这些工具，因为正确使用它们的核心能力在于你能否指导和教授他人进行软件开发，而这本身就要求你具备该领域的资深经验。这些模型提供的阿谀奉承会直接阻碍初级开发者的技能进步，但另一方面又无法完全避免使用它们。因此，我们正处于一个对大多数人而言未来充满不确定性的状态。

         回复

      9. 我发现，目前“杀手级应用”是指任何需要整合你大脑中尚未掌握的信息的东西。一种新语言或框架、第三方 API 等。一些简单但陌生的东西，并且有良好的文档记录。你会节省大量时间，因为 Claude 已经阅读过这些文档了。

         回复

   2. > 作为一名对氛围编程持怀疑态度的人，我感到惊讶。

      关于所有这些对氛围编程的怀疑、 cynicism 和反弹，有趣的是，许多人的期望值极低。他们坚信工具生成的所有内容都是垃圾，或者人们提供的最糟糕的例子代表了平均水平。

      然后他们终于开始使用这些工具，发现它们超出了他们(极低的)预期，感到非常惊讶。

      是的，我们都知道Claude Code不会用10个人团队(或者社交媒体上那些吸引眼球的风险投资公司本周在推销的什么)来打造一个价值100亿美元的SaaS公司。然而，这些工具比很多人想象的要强大得多。

      回复

      1. 如果有人已经意识到这一点：这不仅仅是代码的问题，还主要是营销的问题。除非你制作出难以复制的有用的东西。

         我最近发现了一些需要的东西，但非常小众，而且只有 Claude 才能提供如何处理这类问题的建议。

         回复

         1. 我猜我不确定为什么人们认为AI在不投入大量计算资源的情况下，对小众问题会非常有用。

            任何小众问题都需要原创工作或深入搜索才能完成。没有免费的午餐。

            回复

            1. 如果你能在 8-13b 模型上获得与 Claude 一样好的东西呢？如果你能进行量化，即使在 4090 上也能轻松运行。

               回复

      2. 嗯，这不是我的经验。我一直在积极尝试使用 Cursor 和 Claude Code。我在不同项目中尝试了20-30次使用Code，其中包括几个个人小型项目。所有尝试都导致了不尽如人意的结果，基本上无法使用。

         我尝试将其用于Python、Rust和Bash。我还尝试将其用于爬取和整理信息。我还尝试将其作为调试助手。所有尝试均以失败告终。

         我完全不明白人们是如何通过它来提升工作效率的。对我来说，到目前为止，这完全是一个巨大的时间浪费，几乎没有任何成果。

         唯一积极的结果是，当我让它优化一个特定的SQL查询时，它成功做到了。

         无论如何，我将继续尝试使用它，也许需要先有一个突破点，而目前还没有出现。

         回复

         1. 我让它为我正在开发的DAW实现一个音频插件API(CLAP)的C++后端，它在不到十次交互中就做对了。实现其他插件API(如VST3)则花了我数周时间才达到相同的支持水平。

            回复

         2. 你可能处于一个冷门领域，或者要求它做一些创造性工作。

            尝试升级JS包依赖项，或在不同语言间翻译等重复性任务，你会惊讶于它的表现有多好。

            回复

            1. 嗯……我确实从事的是一个利基领域(机密计算)，工作本身也相当具有创造性，尽管我不会说我要求它处理领域特定的问题。我没有要求它提出加密方案或安全协议，我很快意识到它甚至无法开始处理这些问题。“设计讨论”只是对我的写作内容的阿谀奉承式肯定。我主要尝试的是“添加这个功能”或“根据XY重构这个部分”或“分析这段代码中的竞争条件”。

               (不)幸的是，我的工作并不涉及太多“机械编码”。在个人项目中，我让它随心所欲地选择语言和库。其中一个项目最终与Redis API(！！！)搞得一团糟，它不断在不同版本之间来回切换以“修复”问题，直到它实际上移除了本应添加的功能。问题解决了，对吧？

               回复

         3. 起初我喜欢它，但随着时间的推移，我同意那些称它为老虎机的人，除非你非常有目的地使用它，否则它就是那样。赌博。

            回复

            1. 这根本不是公平的描述。

               我一直用尽可能多的上下文来处理所有繁琐的任务，而我在这方面的个人胜率远高于预期。

               如果你给它垃圾并期待黄金，那当然是赌博。

               回复

      3. 人们对“氛围编程”有不同的定义。如果你期望只需提示而不查看代码或参与过程，结果必然糟糕。这并不否定模型作为工具的实用性，或许未来“氛围编程”真的能行得通。我尊重的每位程序员对此都有类似观点。

         有你提到的社交媒体类型的人，也有与他们截然相反的“大语言模型(LLMs)毫无用处”的人。这些人大多是妄想。在成年人的圈子里，对相对有用性有各种各样的看法。

         认为现在的普通程序员们头埋在沙子里，至少应该花时间探索大语言模型(LLMs)能提供什么价值，同时在使用它们做实际工作时采取更保守的方法，这并不矛盾。

         回复

         1. >也许未来氛围编码会真正发挥作用

            氛围编码在今天的小规模范围内已经发挥了作用。

            我正在开发一个个人应用程序来帮助我跟踪营养摄入，我只需要在Claude处理单个文件时遇到限制并导致程序出现故障时才需要介入代码(这是通过UI实现的，而非Claude Code)。目前代码行数已达到约3000行。

            在告诉它将代码拆分为几个文件后，我认为无需再在代码层面进行任何操作。请注意，我最终还是切换到了 Claude Code，这可能有所帮助(复制/粘贴多个文件非常烦人，而且我的提示达到了最大限制)。

            我只是像一个经验丰富的 QA/产品人员一样，告诉它如何构建，指出错误(作为用户，我非常有经验)，指出不良数据等。

            我最近的一些提示(每个都是单独的提示)：

            >对于在数据库中未找到的食物，列出每个出现的次数

            >按出现次数降序排序列表

            >周期盈余/赤字似乎过低。查看2025年7月24日至2025年7月31日

            >不需要米色(但仍然跟踪)。在统计中将蓝色/紫色合并为一个(但保持不同的颜色)。数据中有白色和白，应该使用标准情况，而不是显示为两种颜色

            回复

      4. > 是的，我们都知道 Claude Code 不会用 10 人的团队创造 100 亿美元的 SaaS…

         我不是在争论，因为我没有反驳的证据，但你怎么能这么肯定？

         回复

         1. 我认为这是一种有效市场假说的变体。没有问题既如此有利可图又如此容易解决；如果它们存在，它们会被大量涌入并停止有利可图。即使在当今时代，$100亿的收入也是一个极其高的门槛。

            另一方面，$100亿的估值(而非收入)只需要一个更大的傻瓜。也许有可能，但我怀疑这样的傻瓜并不多。

            回复

            1. 是的，$100亿的收入是疯狂的。

               我认为原帖指的是$100亿的估值。

               回复

         2. 问题不在于你能不能做到，而在于长期来看是否值得：

            – 这样做存在护城河(即人们是否愿意为你的SaaS付费，尽管他们可以通过AI自行实现)以及..

            – AI时代后还需要多少大型创意？许多SaaS产品采用订阅制且充斥着不需要的功能。大多数人更倾向于选择一个简单的产品，只需满足他们的需求，而无需承担持续的成本。

            将会有更多的软件。问题是，谁将获得这些额外软件的经济价值——软件工程/科技行业(现有行业)、人工智能行业(颠覆者？)以及/或消费者。对于软件工程师/科技工作者来说，这可能不是他们当初进入或学习这个行业时所设想的。

            回复

            1. 在我看来，消费者显然是最大的受益者。

               我原本打算购买一款 80 美元的软件许可证，但最终在周末用 Claude Code 制作了一个版本。

               它远不及我作为竞争对手可以出售的商业级产品，但对我来说已经足够了，无需花 80 美元购买许可证。最大的优势在于我可以随心所欲地定制软件。我也不在意它是否可维护。在ChagGPT5中制作新版本将成为我的第一个项目。

               就像几小时前我还在想如何定制我使用的健身/卡路里追踪应用。其中有很多功能我喜欢，但它们与我的个人情况紧密相关，而非面向大众市场的产品。

               对我来说，这显然是未来软件发展的方向，除了关键任务软件之外。

               回复

               1. 这当然对科技行业的就业、架构/设计决策等有重大影响。为什么非科技公司要使用SaaS，而只是用AI做点什么，然后让1-2名工程师负责开发？这样做成本更低，且可分摊到多个产品中，为一些公司节省数百万美元。不仅技术实施者，销售人员也会受到冲击。尤其当SaaS服务本身需要遵循标准或进行大量定制时。购买与自建、产品与实施，这一切都将很快改变——这是其中的一线希望。

                  回复

         3. 因为如果是由 Claude Code 生成的，那么基本上任何 10 人的团队都可以制作出竞争性服务。

            回复

      5. > 所有这些对编码的怀疑、愤世嫉俗和反弹情绪有趣的地方在于，许多人的期望值非常低。

         或者他们实际上已经使用过所有这些工具，知道它们是如何工作的，不会被炒作和营销所迷惑。

         回复

      6. 许多怀疑论者也不诚实，这无济于事。几天前，有人试图声称，插入冗长的调试日志(这是 Claude Code 非常擅长的)是“真正的编程”，对人类来说是一项重要的工作。

         不，克劳德可以在我的整个代码库中生成日志，格式更好且速度更快，所以我可以专注于实际问题解决。这令人沮丧，但对于这个论坛来说，这很正常。

         编辑：不诚实是不正确的，我应该说我只是不同意他们的陈述。我为此道歉。

         回复

         1. 不，有些怀疑论者实际上是不诚实的。这是恶作剧的一部分，而恶作剧现在正流行。当然，有些怀疑论者是公正的，但许多人只是为了博取眼球，而没有进行任何尽职调查。

            回复

         2. 那不是不诚实的意思。那只是有人不同意你的观点

            回复

            1. 感谢你指出我的不准确之处。我在HN上一直感激的一点是，每天都能看到如此严谨的态度。

               回复

               1. 那不是严谨的意思。

                  回复

                  1. 感谢你指出我的不准确之处。

                     回复

                  2. 哈哈。这让我笑了。

                     回复

               2. 那不是吹毛求疵，吹毛求疵是指非常细微或技术性的细节，但不诚实与持有不同意见无关。

                  但这条评论可能有点吹毛求疵。

                  回复

                  1. > 但这条评论可能有点吹毛求疵。

                     尤其是如果我指出他们说的是“也”，而不是“是”。

                     回复

      7. 我对vibe代码持怀疑态度，因为我不认为那是编程。我假设它能写出一些不错的代码，但那不是编程。

         回复

         1. 编程只能由碳基复制体完成，对吧？

            回复

            1. 不，编程可以由机器完成。但如果你在告诉机器该编写什么程序，那你不是在编程。机器在编程。你不再是程序员，只是用户。

               回复

               1. 除非你在编写纯汇编语言，否则我们不都是在用机器生成代码吗？

                  回复

                  1. 我认为一个更严格的定义会很有用。随着时间的推移，我们可以让它变得更狭窄

                     对我来说，编程的本质是使用形式语言和可定义的状态机(即你的工具链)以可预测的方式操纵机器的状态。

                     C、C++ 即使存在大量未定义行为，仍属于形式化语言，其编译器行为可被预测和理解(无论难度如何)。若编译器产生意外行为，那是因为程序员对语言或编译器状态缺乏足够了解。

                     Vibe 编程使用自然语言，并与状态不仅未知且_不可知_的程序交互。对于相同的输入，机器可能产生截然不同的输出。如果机器生成意外代码，这不是因为程序员缺乏知识——而是因为机器本质上不可预测，需要通过柔和、模糊的自然语言进行更多引导。

                     告诉某人你想要的结果，即使是用只有程序员才能理解的技术术语描述，也不是编程。这本质上只是在做项目经理。

                     现在你可能会问——谁会在乎这个“真正的苏格兰人谬误”？无论是否编程，我们仍在为客户的产品需求生产程序。

                     个人而言，我学习编程并非因为关心客户的产品需求或企业的财务状况。我享受编程本身——因为用一套明确的规则系统解决问题很有趣。学习和使用C++对我来说很有趣；每天我都会学到关于这门语言和编译器行为的新知识，而我已经使用C++多年(我12岁时就开始学习它！)

                     用自然语言描述项目的结果或目标听起来像是一场噩梦，说实话。我成为软件工程师，是为了尽可能减少生活中所需的自然语言。自然语言在我青少年时期(以及我怀疑像我这样的人)一次又一次地给我带来麻烦，但我从未写过一段被误解或模糊到让人们感到威胁或愤怒的代码。

                     我认为问题在于，有些人关心产品，有些人关心代码。

                     回复

                     1. > 仍然可以预测和理解(无论这有多难)。

                        如果我们要假设一种情况，那么大语言模型(LLMs)是可以预测和理解的(无论这有多难)。它们并不是靠仙尘运行的。

                        回复

                        1. 仔细阅读源代码和规格说明来理解某件事是如何运作的，与查看包含大语言模型(LLM)所有权重的数据库并假装自己能够预测输出结果，这两者在质量上是有区别的。

                           回复

                           1. 你不必这样做——只需运行矩阵乘法即可。这与使用袖珍计算器没什么区别。

               2. 嗯，我整个职业生涯都在告诉机器该如何编程，机器会将我输入的C/Go/Python/Perl等语言的代码转换为其他机器使用的汇编语言/机器码，以便执行各种任务。

                  回复

                  1. 它们在实质上是不同的。使用编译器需要你对状态机有一个内化的模型，更重要的是，需要一种形式化的语言。C、汇编语言、Java等与使用英语的灵活性来迫使黑盒子产生结果是本质上不同的。

                     回复

                     1. 不，完全不是。

                        在两种情况下，你只需要能够以机器能够将你的想法转化为行动的方式与机器沟通。

                        编译器的受限语言是一种障碍，而非技能的证明——我们一直认为“自然语言”编译器将改变游戏规则，而这正是人工智能的本质

                        编辑：看来这场讨论最终将归结于对“编程”的定义

                        如果你告诉计算机执行某些操作，这是编码吗？或者，如果你告诉它如何以高度优化的方式(优化有不同的定义，例如内存效率、CPU 效率、开发时间效率等)执行这些操作，这是编码吗？

                        回复

                        1. 编写可编译的代码是确定性的，但要求大语言模型(LLM)生成代码则是一个非确定性的猜测游戏。

                           注意没有人对编译器持怀疑态度？

                           回复

                           1. 没有人对编译器持怀疑态度？！我想你没遇到过很多老派的C系统程序员，他们会尽可能地禁用编译器优化，因为“它只是产生垃圾”。

                              每一代人似乎都会增加一层抽象，因为对大多数人来说，这能提升生产力。而每一代人中，总有一群人反对新的抽象，他们大多 unaware of all of the levels of abstraction they already use in their coding.

                           2. 奢侈品！在我年轻的时候，我们没有这些新潮的编译器，我们用手写汇编语言，因为编译器无法(而且我认为直到今天仍然无法)像人类一样优化汇编语言。

                           3. 抽象和编译器是确定性的，无论一个胡子拉碴的人对结果有多么不满。大语言模型(LLMs)不是确定性的，它们是一种猜测游戏。大语言模型不是抽象，而是干扰。如果你无法分辨其中的区别，那么也许你应该放弃“人工智能”这个词。

                           4. 我一直在思考这个问题——你说的没错，大语言模型(LLMs)在生成代码来解决问题时不会是确定性的(AIUI)。

                              但人类也是如此，如果你给两个不同的人分配相同的任务，除非他们互相抄袭，否则你会得到两个不同的结果。

                              此外，随着这些人的职业发展，他们生成的代码也会发生变化。

                              现在，我想指出的是，我仍然非常赞同“大语言模型(LLMs)是一种辅助手段，而不是完整的答案……至少目前如此”这一观点，但许多反对大语言模型的论点似乎正在(迅速)变得不再有效(人工智能的混乱等等)。

                           5. > 但人类也一样，如果你给两个不同的人相同的任务，那么，除非他们互相抄袭，否则你会得到两种不同的结果。

                              这是真的，但给人类分配任务并不是编程——那是项目管理

                           6. 首先，这不是“项目管理”——那是授权

                              其次，而且这点更为重要，它是通过文本告诉机器你希望它做什么

                              这与编程完全相同。

                        2. 如果使用自然人类语言，那就不是编程

                           回复

                           1. 我认为在经过所有目标转移后，我们必须问——为什么我们称呼它的方式如此重要？

                              有些人使用大语言模型(LLMs)完成了大量的工作。我们中的一些人偶尔使用它来处理我们不深入理解但可以轻松验证的事情。我们中的一些人出于懒惰而使用它，因为它有助于处理模板代码。除了偶尔测试之外，所有使用它的人都是因为他们发现它对编写代码很有用。如果这不是编码，那么我个人就完全不在乎了。只有真正的苏格兰人才会在乎。

                           2. 如果我的老板来对我说：“嘿，从现在开始，我们要把所有工作都用 vibe 编码。你可以手动编辑代码，但从现在开始，Claude 代码必须成为你的主要驱动因素。”我会辞职，然后寻找新的职业。我喜欢编码。我喜欢使用语言语法的细节来解决难题。我编写库和API，并投入大量精力确保接口对人类可用。

                              如果我们到了不再编码的阶段，只是用产品语言向计算机描述事物并让它完成所有实际工作，那么我会寻找更具成就感的事业，因为这并非我想要的。

                           3. 等到它运行得完美无缺时，那已经不是你的职业了，而是产品经理的了。他们会描述他们想要什么，而人工智能会生产出来。你不会被要求“一直使用Claude”。

                              我个人讨厌编码，但它只是实现目标的手段，而我关心的是目标本身。我对不理解的代码感到不安，因此我很少使用AI，即使使用也是针对我100%理解的内容或无关紧要的事物。但声称AI无法生成可运行的代码是荒谬的，无论我们如何定义它。

                           4. 这是问题的核心。你讨厌编程，而我热爱它。我选择成为软件工程师并非因为我喜欢“使用”软件，而是因为我喜欢“编写”软件。

                              如果有一天工程师被机器取代，我希望项目经理早在多年之前就被取代，作为最后的报复。

                           5. 这个论点是站不住脚的。

                              我喜欢很多事情(软件工程是其中之一)，但这绝不会决定人工智能是否在编程，也不会保证我能有职业(只需问问那些在汽车成为大众交通工具后消失的铁匠们)。

                              人们将来可能能够指示计算机做任何他们想做的事情，而无需四年学位和数年经验，这让你感到害怕，我理解，但这不会对现实产生任何影响。

                              编辑：看看所有因为软件接管而结束的职业生涯。

                           6. 为什么？

                              BASIC本应是迈向使用自然人类语言编程的一步，微软的许多产品也是如此。

                              正如我之前所说，我们一直希望使用自然人类语言进行编程。

                              编辑：添加一个维基百科参考，因为显然我是地球上唯一一个在寻找使用自然人类语言进行编程方法的人https://en.wikipedia.org/wiki/Natural_language_programming

                              第二次编辑：添加以下段落以强调

                              研究人员开始实验使用自然语言编程环境，通过普通语言提示，再利用人工智能(特别是大型语言模型)将自然语言转换为正式代码。例如，Spatial Pixel 创建了一个自然语言编程环境，通过 OpenAI 的 API 将自然语言转换为 P5.js 代码。2021 年，OpenAI 为其编程大型语言模型 Codex 开发了一个自然语言编程环境。

                           7. 也许你做过。我可不想要这样的东西。

                           8. 哦，还有……你是谁？

   3. 从技术上讲，你不是在进行 vibe 编程。你是在使用 AI 进行软件工程。vibe 编程特指让 AI 生成代码并继续推进，而无需理解代码的过程。

      我知道我有点吹毛求疵，但人们在讨论这些概念时往往有截然不同的含义，我认为不应给予 vibe 编程任何可信度。

      回复

      1. 在某种程度上，OP 仍然是在进行氛围编码，因为人们必须相信 Claude 的每一个决定，而这些决定乍一看并不容易验证。我同意，我们需要一个新词来描述高度人工智能辅助的软件开发，我曾经用“生动编码”来描述这种过程。

         回复

      2. 我经常进行氛围编码，尽管我是一名后端工程师，但我会处理大量前端代码。就我而言，这是在个人项目中，我雄心勃勃，要求大语言模型(LLM)“替换整个 SaaS”之类的事情。在工作中，大多数代码只是几行，很容易审查。

         当我尝试更复杂的事情时，我会使用 AI 进行多次审查，让 2-3 个大语言模型 (LLMs) 进行审查，删除过时的代码，进行重构，询问它并要求它修复不良模式等。一个晚上，我可以通过这种方式重构一个大型代码库。例如，与 Claude Opus 相比，Gemini 在新代码方面表现平平，但在审查现有代码方面表现尚可，因为 1M 的上下文窗口使其能够将 Claude 无法在 256k 中容纳的内容联系在一起。然后，我可能会将建议从 Gemini -> Claude -> Grok 反弹回来以修复某些问题。这有点像管理一个由不同专业和性格的实习生组成的团队。

         回复

      3. 两者都是 vibe 编程。这个术语由特斯拉人工智能总监、计算机科学家 Andrej Karpathy 提出。

         也许你想到的是 slop 编程？

         回复

         1. 不，它们不是。

            “氛围编码定义的一个关键部分是，用户在不完全理解的情况下接受代码。[1] 程序员西蒙·威利森(Simon Willison)说：‘如果大语言模型(LLM)编写了你的每行代码，但你已经审查、测试并理解了所有内容，那么在我看来，这并不是氛围编码——这是将大语言模型作为打字助手。

            (https://en.m.wikipedia.org/wiki/Vibe_coding)

            > 该术语由特斯拉人工智能总监安德烈·卡帕西(Andrej Karpathy)提出。

            然后呢？

            回复

            1. 我对他的完整信息并不熟悉，因此并未意识到当前对“vibe coding”的定义竟如此_愤世嫉俗_。我们中的许多人并不这么看。

               回复

         2. 卡帕西的定义明确要求：

            1. 不查看代码 2. 随心所欲地做一切 3. 将错误原封不动地粘贴回模型

            不过，我将自己所做的工作称为 vibe 编码，但会引入代码审查机器人。我还会在事前进行深入研究并制定计划，同时要求模型通过全面的单元测试和行为测试。

            回复

         3. 以下是 Karpathy 的完整原始定义：[*]：

            > 有一种我称之为“感觉编码”的新编码方式，你完全顺从感觉，拥抱指数，甚至忘记代码的存在。这是可能的，因为大语言模型(LLMs)(例如 Cursor Composer w Sonnet)越来越好了。此外，我只需通过SuperWhisper与Composer对话，几乎无需触碰键盘。我会提出一些看似愚蠢的要求，比如“将侧边栏的填充减少一半”，因为我懒得去查找具体位置。我总是直接“接受所有”更改，不再阅读差异对比。当出现错误信息时，我直接复制粘贴到代码中，通常这样就能解决问题。代码超出了我的理解范围，我必须花一段时间仔细阅读。有时，大语言模型(LLMs)无法修复错误，所以我只能绕过它，或者要求进行随机更改，直到错误消失。对于周末的临时项目来说，这还算不错，但仍然很有趣。我正在构建一个项目或网页应用，但这其实不算编程——我只是查看代码、输入指令、运行程序，然后复制粘贴内容，大部分时候都能正常工作。

            这里的关键点包括：“忘记代码的存在”、“始终选择‘接受所有’”、“不查看差异”以及“代码规模已超出我的理解范围”。

            使用AI辅助进行软件工程并非Karpathy所定义的“编码氛围”。

            [*] https://x.com/karpathy/status/1886192184808149383

            回复

   4. 几个月前我无法想象会为任何订阅服务支付超过$20/月的费用，但现在我却在为Max 20计划支付$200/月！

      作为一名拥有20年经验的开发者(同时也是斯洛伐克人，尽管目前在美国)，我同样感到惊讶。其他工具虽然有用，但就是不够完善，而且往往麻烦多于收益，还产生了大量无用的垃圾代码。Claude Code 显然是另一个层次的工具，是的，它需要大量的手把手指导；我的做法是，先使用计划模式，直到我 100% 确定它理解了要求，并且计划的代码更改是合理的，然后让它运行，最后审查它所做的代码(在它自动修复了编译器错误、单元测试失败和 linting 问题之后)。这有点像一个有点笨拙但非常博学的新手工程师，工作速度极快且从不顶嘴 🙂

      这无疑是未来趋势，我还能说什么呢？这是软件开发明确的发展方向。

      回复

      1. 当我第一次尝试在相对较小的代码库(1500 行，2 个文件)上使用 Cursor 时，我让它修复了一个(或多个)有明确测试案例和粗略问题描述的错误，结果却是一场灾难。

         第一个修复提交看似合理，尽管仍不完全正确，但最终不仅未能修复问题，每次提交的代码也变得越来越复杂。当它写出近100行代码来比较版本号(而这些版本号在源代码中已存在)时，我终止了它。讨论计划的问题在于，在调试过程中，你自己对计划的整体思路并不清晰。

         我并不认为这是完全的失败，因为我要求 AI 改进一些错误消息以帮助调试，我会保留该代码。它非常擅长编写新代码，非常擅长审查代码，但对我来说，它完全无法进行维护。

         回复

         1. 这些工具和大语言模型(LLMs)的质量各不相同，对我来说，Claude 4 的 Claude Code 是第一个效果不错的工具。我之前尝试过 Cursor，虽然已经过去了 6 个月以上，但我并不觉得它有多么出色。

            回复

            1. 我也有同感。对我来说，Cursor 简直是一团糟。我不知道它为什么以及如何对其他人有效。另一方面，Claude Code 从一开始就非常成功，我已经高兴地使用它几个月了。

               回复

               1. 在切换到 Claude Code 之前，我使用 Cursor 大约 5 个月。只有当我以非常特定的方式使用 Cursor 时，我才能提高工作效率，基本上就是用手做 Claude Code 内部做的事情。我维护计划文档、待办事项列表，使用测试驱动开发和 linting 工具等。我的 .cursorrules 文件看起来就像我设想的 Claude 系统提示一样。

                  克劳德·科德帮我承担了维护的负担。

                  此外，光标对所有非人类中心主义模型(即默认模型)完全无用。

                  回复

         2. 就我而言，几周前我尝试了人工智能辅助编码，并从 Cursor 开始。我对此印象不佳(花在提示和与工具斗争上的时间比实际进展的时间还要多)，直到我尝试了 Claude Code。我很高兴地立即放弃了 Cursor(取消了订阅)，现在正在愉快地使用 CC 进行高效的工作(只是每月 20 美元的基本套餐)。虽然仍需手动干预，但总体上提升了生产力。

            回复

         3. 这是我使用 Copilot 搭配 GPT4o 或 Sonnet 3.5/3.7 时经常遇到的问题……有时会陷入死胡同，浪费数天工作时间，但更常见的是浪费一两小时后不得不放弃重来。

            不要让 Claude Code 在 10-30k LOC 的多个代码库上运行。部分原因是，我在内存文件中提供的指导有助于防止这种情况发生，linting(即类/文件长度)也是如此，但我还将事情分成我进行 PR 审查的功能，并对其进行重构，以保持一切井井有条。

            回复

            1. 是的，Github Copilot 对我完全不起作用。补全功能还不错，我实际上仍然在使用它，但代理部分完全没用。Claude Code 则完全不同。

               回复

         4. > 编写了近 100 行代码来比较版本号

            天哪，这几乎是有意识的。这是一个深刻的数学证明！

            回复

      2. > 几个月前我根本无法想象会为任何订阅服务支付超过$20/月，但现在我却在为Max 20计划支付$200/月！

         我好奇，大多数有工作的开发者都是自己掏钱订阅，而不是由公司支付吗？

         回复

         1. 我最近失业了，之前在行业内连续工作了20年，现在正在尝试推出一个SaaS产品，所以是的，我自掏腰包支付。

            回复

      3. 我可以问一下你用它来做什么吗？我主要是用来娱乐、副业、学习和实验。我绝不会用它来处理工作代码库，除非公司要求或至少允许使用。即便如此，我也不确定自己是否会对CC的自由度感到舒适。所以我对其他人也很好奇。

         回复

         1. 当然，使用(非本地)AI工具需要公司明确许可。

            在获得许可前，我将AI作为更高级的搜索引擎使用，并用于提出解决我抽象描述的问题的方案(不涉及实际代码的复制粘贴)。

            回复

         2. 这是我和我的合作伙伴正在尝试推出的我们自己的 SaaS。因此，与工作无关。

            回复

   5. 在 Claude Code 时代，作为程序员，最宝贵的技能似乎是仔细阅读规格文档，并在审查代码时具备敏锐的批判性思维。

      回复

      1. 关键技能是发现潜在的错误，但在做到这一点之前，你需要对堆栈、库和所选的编程语言有非常敏锐的理解或丰富的经验。讽刺的是，这些技能并不是通过“感觉编码”就能获得的。

         回复

      2. 对于资深程序员来说，这些技能在大语言模型(LLM)出现之前是非常宝贵的。

         回复

   6. 这很有意思，因为我发现最近的 Claude 模型在编写和编辑 SQL 方面并不可靠。例如，它可以正确地编写条件，但不会在 AND 和 OR 周围添加括号(Gemini Pro 随后正确地将此作为错误进行了突出显示)。

      回复

      1. 如果你还没有(1)告诉 Claude Code 你想要哪种 SQL 版本(有几种主要方言和许多次要方言)，以及(2)通过 MCP(例如 https://github.com/arabold/docs-mcp-server)，以便它能直接访问权威的标准文档和语法参考，你会发现通过做其中一项或两项，你会得到更好的结果。

         回复

         1. 关于你的SQL方言支持的特性以及查询的关键要求，文档非常重要，这有助于激励它生成你想要的输出。

            以最近的一个例子为例，我正在开发一个集成了DuckDB的Rust应用程序，并要求它实现一个评分算法查询(在与它交流以生成一个描述算法如何工作的Markdown文件“RFC”之后)。它最初以一个绝对最简化的SQL查询开始实现，该查询提取了给定时间窗口内的所有指标。

            我对这一实现提出质疑而非直接接受，它解释称其计划在Rust中实现更复杂的聚合逻辑，因为1) 解读Rust的分支逻辑比解析SQL语句更直观(确实如此)，以及2) 并非所有SQL方言都支持EXP()、STDDEV()、VAR()等函数，而这些函数对于计算指标是必要的。

            前一点在我看来其实是一个相当合理的偏好。就我个人而言，我发现用SQL审查复杂的聚合操作比在脑海中遍历数据通过一系列分支的路径要困难得多。但如果你熟悉DuckDB，你就会知道1)它确实支持这些功能，2)DuckDB的OLAP效率使其在以高性能方式执行这些聚合操作时比在Rust中遍历结果更优，因此初始生成的输出并不理想。

            我向它说明了DuckDB对这些操作的支持，并指出了性能考虑因素，它欣然生成了(冗长且显然更难理解的)SQL查询，因此它显然非常强大，只是需要一些提示才能朝正确方向发展。

            回复

         2. 未听说过docs-mcp-server，但有非常流行的Context7，拥有2.3万GitHub星标且开发更活跃：

            https://github.com/upstash/context7

            回复

            1. 很好的建议，谢谢！

               回复

      2. 我发现 claude sonnet 4 在使用真实数据进行反馈循环时，非常擅长编写 SQL。它会研究问题、研究数据，并不断改进查询，直到找到解决方案。然后，它会进行优化，甚至优化性能，如果你要求它运行解释计划或查看 pg_stat_statemnts(postgres)。

         回复

         1. 它非常擅长性能优化。我用它优化了多个非常复杂的查询，这些查询我已经拖延了很久。Claude 代码在几秒钟内就计算出了要添加的确切索引(这些索引是我手动很难得到的结果)。

            回复

      3. 尝试让 Claude 根据您现有的手动编码工作编写风格指南，然后看看在上下文中使用它是否有所改进。

         回复

      4. 诀窍是让它通过 sqlglot 运行并纠正错误。

         回复

         1. 这种事情是关键点。告诉 Claude Code 构建项目、运行 linters、运行测试并修复错误。根据我的经验，这很有可能过滤掉错误。Claude 完全能够运行所有工具、读取输出并进行迭代。更高层次的错误需要用可测试的代码来编写，以便通过测试来捕获它们，尽管你可能无论如何都希望这样做。

            回复

      5. Claude Sonnet 4 非常擅长为 Neo4j 生成 Cypher 查询。

         回复

      6. 我猜这很大程度上取决于你做的工作。

         对于编写测试、转换代码库等简单任务来说，它非常有用，因为这些任务的难点已经完成了。

         至于真正做一些困难的事情，至少根据我的经验，它并不是非常有用。

         如果你做的是非常小众的事情，它基本上是无用的，自己研究这个话题比让 Claude 实现它更快。

         回复

         1. 即使我亲手完成某些事情，让 Claude Code 接管我可能遇到的其他繁重工作还是很好的。而且总会有需要处理的事情，总是如此。

            回复

   7. 我拥有类似的工程经验，最初非常怀疑，但在一个绿地项目(TS api、react-native 客户端、TS/React 管理面板)上花费了两周时间后，我得出了与 Claude Code 类似的结论。

      随着我规划和上下文管理能力的提高，结果也相当一致。只要我能将任务保持在上下文窗口内，它几乎每次都能完成不错的工作。偶尔我不得不让它强行通过绿色代码检查/类型检查/测试。这是最大的障碍之一。

      我发现Gemini在偶尔进行详细代码审查以发现明显问题或遗漏内容方面表现出色，但让它实现任何功能都严重不足。我不得不明确告诉它不要做任何事情，因为它会随意开始写文件。我通常使用 Opus 模型来编写详细计划，使用 Sonnet 进行实现，然后使用 Opus 和 Gemini 进行审查和规划重构。

      我印象深刻。进展非常缓慢。如果没有 Gemini，我可能在 1/3 到 1/2 的时间内就能达到现在的阶段，可能测试更少，流程文档也少得多。但结果总体上相当不错。学习过程让我保持动力，继续推进这个老旧的副项目。

      测试期间我切换了两个账户，但最终升级到$100/月的计划，自那以后我只被限速过一次。我不确定是否会将此用于日常专业工作，但认为它对某些类型的任务非常有用。

      回复

   8. 我也觉得 Gemini CLI 完全没用。不过，上周我尝试了 GLM4.5(通过 z.ai API)的 Claude Code，它确实与 Sonnet 相当。

      回复

      1. 感谢您的推荐。我已经在开源项目中测试过这个工具，效果确实不错。虽然不如Sonnet 4那么出色，但已经足够用了。而且定价非常合理。我不确定是否会信任它来处理私有代码，但对于公开代码来说，这是一个绝佳的选择。

         回复

   9. 我早在20多年前就完成了学业，由于互联网泡沫破裂以及我选择的职业道路，我从未以全职开发者的身份从事编程工作，只是做过一些零散的开发和脚本编写，但从未达到可以自称开发者的水平。多年来我有很多想法，但从未抽出时间去完成它们，也从未学习过完成它们所需的语言或技术栈。过去三周，我一直在开发一个小型项目，预计将于八月底完成 beta 版本。能够在仅有 30 分钟空闲时间时，立即投入功能开发或 bug 修复，且无需进入深度专注状态，这对我的工作效率提升起到了革命性作用。此外，虽然我能阅读并理解代码，但亲自编写代码的速度至少会慢 10 倍。这是一个小型代码库，行数不到5000行且不复杂，因此GitHub Copilot在此场景下表现良好。

      我能预见自己会为更高阶的订阅服务付费，以获得生产力提升。

      唯一的问题是，我们可能会迎来一个这样的社会：那些能负担得起最佳订阅服务的人拥有更多空闲时间、完成更多工作、赚取更多收入，并在整体上更成功。即使是当前的基础订阅计划，对全球绝大多数人口来说也过于昂贵。

      回复

   10. Gemini目前表现一般。刚发布的GLM-4.5相当不错且价格低廉。我通过OpenRouter连接到它，并使用VSCode的RooCode插件进行操作。10 美元的信用额度可以让我编程一天，而 Claude 则在一个小时内就用完了。

       回复

   11. 我开始做的一件事是将 Gemini cli 作为 Claude Code 的辅助工具，加载一系列更改的大量上下文，以获得第二意见——由于其上下文大小的优势，对于这个特定的使用案例来说非常方便。

       回复

   12. > 过去，我无法想象每月为开发工具支付 100 美元以上的费用，但现在我正在认真考虑升级到 Max 计划。

       遗憾的是，我对 Max 计划的体验非常糟糕。这根本无法相比，最近几周我一直在大量尝试 Claude Code，每天花费超过 80 美元，真是太棒了。问题在于，在Max计划中，你无法自行管理上下文长度，这严重影响了模型保持上下文的能力。当然，这在预期之中，上下文越长，运行成本越高，但因为模型明显丢失了关键上下文部分而导致编码任务失败，这实在令人沮丧。

       回复

       1. 你是什么意思，你不管理上下文长度？上下文长度是一样的，200K 令牌。

          回复

   13. 我的经历也差不多，使用 Claude Code 大概 4-6 周了。最初几天有些艰难，我差点放弃并宣称自己所有的怀疑论观点都是正确的，认为它毫无用处。但使用它确实存在学习曲线。一个月后我仍在学习，但经过逐行审查后，我能让它生成可用于项目的有用输出。

       同意上下文和分块是提升生产力的关键。当我试图在单个提示中告诉它我想要它做的一切时，结果并不成功。生成的代码一团糟，其中很多部分根本没有实现我想要的功能。而且当需要修复的问题很多时，CC难以针对性地逐一修复问题。更好的做法是先构建每个小块，确保其完全正常运行后，再继续下一步。

       你还得揭穿它的胡说八道：有时它会试图以你知道是错误的方式解决问题，这时你必须阻止它并告诉它用另一种方式做。我想我可能不该用“胡说八道”这个词；如果把CC比作一个缺乏经验的初级工程师，那么与初级工程师合作时，这种情况就是不可避免的。

       我仍然经常发现，我给它分配一个任务，当它完成后，我意识到我本可以更快地完成它。但有时任务很繁琐，如果我不必亲自完成，我愿意让它花更多时间。有时它确实能比我更快地完成任务。在学习新技术(如React、Tailwindcss，前者我十年前曾略有涉猎，但知识已完全过时)时，当我不知道如何操作时，CC变得极其有用。我乐意让CC来处理，然后我阅读代码并自己学习，而不是不得不翻阅各种质量参差不齐的教程来自行摸索。

       所以我认为我已经说服自己了，我会继续让CC成为我工作流程中越来越重要的一部分。我目前使用的是Pro计划，已经几次达到了使用限制。我对升级到Max并每月花费$100在开发工具上还有些犹豫……不确定自己是否能克服这个心理障碍。

       回复

   14. >我曾梦想过一种神经接口，让我无需编写任何代码就能进行编程。我意识到，Claude Code 已经实现了这种梦想。

       我对图灵测试也有类似的想法……

       几十年来，它一直是一种科幻小说中的概念……然后它悄然到来，我们几乎没有注意到。

       回复

   15. 完全同意。你真的必须学会如何使用它。

       例如，我听说很多人说进行大规模重构会引发问题。我找到了一种适用于SwiftUI项目的解决方案。我进行了重构，移动文件，将大型文件拆分为较小的组件，并标准化不同视图的组件设置。

       对我有效的模式：1) 要求它记录架构和编码标准，2) 要求它制定重构计划，3) 要求它先进行低风险重构，4) 要求它更新重构计划，然后5) 完成所有剩余的重构。

       重构计划附带以天为单位的时间估计，但这对 claude 代码来说完全没用。相反，我要求它估计 1) 聊天消息的数量、2) 令牌的数量、3) 基于令牌数量的成本、4) 受影响的文件数量。

       另一种行之有效的方法是先生成一个可丢弃的应用程序。然后要求它创建如何正确操作的文档，纳入所有学习内容以及遇到的问题。最后，按照这些指导原则和规则重新制作应用程序。

       另一个技巧是，有时当它遇到障碍时，我会打开 Windsurf 中的项目，让另一个大语言模型(例如 Gemini 2.5 pro 或 qwen coder)审查项目和问题，然后我要求 Windsurf 提供一个提示，指示 Claude 代码进行修复。在某些情况下效果很好。

       此外，迄今为止最大的启示：不要指望第一次就能完美无缺。它需要一个反馈循环：生成代码、测试代码、检查结果，然后改进代码。

       对于SQL来说效果很好，尤其是当它可以访问真实数据时：检查数据库、尝试一些查询、尝试从数据中理解模式，然后朝着一个有效的SQL查询努力。通常作为最后一步，它会简化有效的查询。

       我使用一个具有测试数据库完全访问权限的MCP工具，可以让它运行解释计划并查看统计信息(pg_stat_statements)。它会绘制查询的Mermaid图，包含性能指标(检索的记录数、缓存命中率等)，并提供优化后的查询和索引建议。

       我也尝试过在 CSV 和 Parquet 文件上使用 DuckDB，它会运行执行计划，比较两个查询，解释为什么 Parquet 更好，并显示查询是否进行了谓词下推等。

       当它出错时，我不会检查代码，而是让它生成一个包含 Mermaid 图表的设计文档，描述它构建的内容。这样往往能快速发现一些设计错误，并让它进行修复。

       在同一个项目中使用多个工具时，每个工具都有自己跟踪计划的方式，这会带来问题。我要求 claude code 为自己制定规则，并与 windsurf 合作完成一个项目。它返回了一套关于 CLAUDE.md 和 .windsurfrules 的规则，规定了需要哪些文件以及如何使用它们(PLAN.md、TODO.md、ARCHITECTURE.md、DECISION.md、COLLABORATION.md)。

       回复

   16. Claude 代码非常棒，但也有不足之处。你会遇到需要修改或添加某些内容的情况……如果你自己编写了所有内容，这本来是一件很容易的事情，但现在却变得不可能了，因为架构只是你无法理解的各种代码的杂乱组合。

       回复

       1. 成功将 Claude 代码用于大型项目的人不会让代码达到他们无法理解的地步。

          最好的结果来自反复的工作。我拒绝了大约 1/3 的编辑，要求进行一些更改或改变方向。

          如果你只是让代码一直运行，直到最终结果看起来可行，那么你会失望的。但这是操作者的错误。

          回复

          1. 到目前为止，我对帮助实现这一目标的子代理持乐观态度。验证完成状态、检测胡说八道、捕捉过度工程等。我可以为它们加载额外的上下文，比如惯例和特定的提示，以在开发过程中遏制克劳德主义。

             回复

          2. 两年后提醒我一下…

             我完全理解你的意思。但考虑到管理层目前的误区，你只会显得像是在阻碍代码流并成为瓶颈。

             回复

       2. 关键是让它执行更窄的任务，并自行设计代码库的结构。

          回复

          1. 这样做很有帮助。你可以让它制定计划，然后询问它关于这个计划的细节，根据需求进行调整等。可以把它看作是配对编程前的精炼环节。如果按照这种方式操作，结果会好得多。在过去两个月里，我与Claude合作，在工作之余开发了Kubernetes操作员、Flask应用程序、Kivy应用程序以及一个透明的SSH代理。

             告诉它先编写测试也很有帮助：我倾向于为大多数事情编写集成测试，但它在编写良好的单元测试等方面也表现不错。显然，如果要让TDD发挥作用，审查至关重要。

             回复

             1. 作为一名业余程序员，我花在与所有平台讨论规格、测试和架构上的时间越多，最终结果就越好。

                回复

       3. 在过去的几个月里，我广泛使用了 Claude Code，但我仍然没有达到“直到它不再是”这个点。审查生成的代码。这会大有帮助。

          回复

          1. >> 审查生成的代码。这会大有帮助。

             当然，但如果我为一个任务进行5次审查——在99%的情况下，这反而会拖慢进度，因为到那时自己动手会更快。虽然更困难，但确实更快。

             回复

             1. 也许我们的思维方式不同，但对我来说，阅读和审查代码比编写代码快得多。

                回复

                1. 几乎没有客观的方法来衡量代码审查的“效率”。

                   编码很简单，要么能用，要么不能用。

                   回复

                   1. 这忽略了维护性、复杂性和可扩展性等更高层次和长期的概念。

                      仅凭“它能运行”这一标准，最终会导致这样的结果(关于Oracle代码库的经典HN评论)：https://news.ycombinator.com/item?id=18442637

                      回复

                      1. 是的，我的意思是，你甚至没有“它能编译”作为衡量代码审查的标准。也许你做得很好，也许你做得糟糕，你怎么知道？

                         回复

                   2. 或者它工作直到它不工作。有很多代码在某些条件下会工作。

                      回复

       4. 你从一开始就没有给出明确的指示，这就误用了工具。

          回复

       5. 如果你审查了它写出的任何代码，你怎么会得到自己不理解的代码？我不会让它偏离我为项目设定的架构。我过去曾遇到过一些初级开发人员，他们太急于改变项目，但我无法真正要求他们停止(需要提高我的沟通能力)。使用 Claude Code 就不会出现这样的问题。

          回复

          1. 我不记得一个月前审查的 PR 使用的是什么架构了。但我记得 15 年前我参与的项目中设计的架构。

             回复

          2. 我只稍微使用过代理工具，但发现它们能以我难以在脑海中跟上的速度生成代码。开发流程也不需要我频繁与代码交互，因此我对哪些函数在哪个文件中、哪些辅助函数已存在等细节的记忆力变差了。

             这并非我无法理解，而是我对代码的上下文理解非常薄弱。

             回复

             1. 让它用设计文档和Mermaid图表来记录代码。这样审查起来会快得多。

                回复

                1. 我可能得试试这个。虽然还没尝试过，但感觉我认为自己缺乏的上下文更偏向于细节层面，而这种方式可能无法完全覆盖。我不是不确定请求如何进入数据库事务，而是“我们是否需要或已经有了数据库查询中的分页抽象？”。我觉得Mermaid图表或设计文档可能不会包含这一点，但我愿意接受自己可能错了。

                   回复

                   1. 如果你有这样的问题，就直接问吧。

                      回复

          3. 所以你是说阅读和写作是一样的？从大脑实际消费、处理你提供的信息并存储的角度来说

             回复

             1. > 一堆你不懂的氛围编码内容。

                不，“我写了这段代码”和“我理解这段代码”是有区别的。你不需要写一个项目中的所有代码才能理解它。否则，团队编写软件就无法进行。

                回复

       6. 是的，它做任何事情时的默认操作都是尝试创建。它会读取我的 CLAUDE.md 文件，读取已经存在的代码，然后尝试再次写入。我遇到过很多次这种情况(今天我不得不提示5/6次读取文件，因为该功能已经实现)。

          …如果某件事确实很复杂，它(我认为)通常会做得不好。它会生成看起来表面上能工作的东西，但当你仔细检查时，要么以非显而易见的方式无法工作，要么设计糟糕。

          虽然仍然非常有用，但要真正提高生产力，你必须明白何时不应使用它。

          回复

          1. 作为人类，你是如何编写复杂代码的？你创建抽象层，对吧？

             为什么这不能用大型语言模型(LLM)来实现？当然，这需要付出努力，但如果必须手动操作，同样也需要付出努力。

             回复

             1. 与代码相比，英语的表达能力要弱得多。对于资深开发者来说，敲击键盘从来都不是最耗时的部分。

                大语言模型(LLM)确实可以做到这一点，但你却用这些疯狂的标记文件重新发明了轮子。我们创建了一系列语言来表达如何移动位，用英语来代替它是很愚蠢的。

                Vibe编码速度快，是因为你无需思考代码。每当你必须这样做时，大语言模型(LLM)就不会快多少了。

                回复

             2. 因为它创建了错误的层级。

                从理论上讲，没有理由会出现这种情况。同样的道理，没有理由初级开发者不能第一次就写出完美的代码……只是需求文档从未详细到足以支持这一点？

                但现实中并非如此。代码本身就是糟糕的。

                回复

                1. 你对层级结构负责。你应该自行设计，或者让工具提问并引导你。但你应该让它记录计划，然后再让它编码。如果代码出错，你/清除，重新加载计划，并告诉它以不同方式编码。

                   这与初级开发人员的情况如出一辙。我不会让初级开发人员去实现一个CRM应用程序，但我可以让初级开发人员在客户管理页面上添加第二个电子邮件字段。

                   回复

       7. 你没有设定足够明确的界限，也没有密切审查它的操作。

          监督它，并给它明确的指示。

          然后在它完成工作后，提示它说：“你是这个项目的员工工程师或团队负责人，我希望你像审查初级团队成员的贡献一样审查自己的Git差异。基于项目架构描述的@HERE.md和@THERE.md，进行批判性思考并做出判断。”

          回复

          1. 啊，是的……老掉牙的“你拿错了”。问题是这些该死的东西不会学习，所以你得花精力去监督它……而且得一直这样做直到永远。还不如从街上找个人来当软件工程师。

             回复

             1. 是的，有时候你确实握错了。有时候产品必须以特定方式使用才能获得良好效果。你不会怪洗发水，当有人只用了一小滴，头发仍然脏兮兮的。

                大语言模型(LLMs)和编码助手还处于早期阶段。有时你确实需要以正确的方式使用它们。如果你不愿意这样做，或者认为这样做比其他方式提供的价值更少……很好，对你来说是件好事，按照你认为最适合自己的方式去做吧。

                长期以来，我对编码助手持怀疑态度。大约一个月前，我开始尝试使用 Claude Code。在学会正确使用它之前，我感到有些沮丧。它距离取代真正的人类程序员还有很长的路要走，但对我来说还是很有帮助的。我当然更喜欢它，而不是与人类进行配对编程(我讨厌配对编程)，所以它还是很有价值的。

                如果你不想自己去了解它是否能为你带来价值，那是你的选择。但这项技术会越来越好，你可能会后悔没有早点了解它。就像任何新工具一样，刚开始时可能不太成熟，但最终会变得非常有用。

                回复

             2. 你的 claude.md(或同等文件)是教他们的最佳方式。在任何非平凡的编码会话结束时，我会要求它根据功能变化和我们为达到该结果而遵循的过程，对该文件提出编辑/添加建议。

                回复

                1. 如何将 30 年的经验/知识提炼到一个 Claude.md 文件中？人可以学习，大语言模型(LLMs) 却不能——故事到此结束。

                   回复

                   1. > 人会学习，大语言模型不会——故事到此结束。

                      不过，故事并没有结束。大语言模型不会学习，但你可以为它们提供一本“手册”，每当你与它们开始新的对话时，它们就会阅读这本手册。虽然人类可能需要数月或数年的时间才能学习完手册中的内容，但大语言模型(LLM)可以在几秒钟内消化完。是的，每次从头开始时，你都必须不断向它输入手册的内容，而且你可能需要数月的时间才能将手册整理成完整的状态。但也许这并不算太糟糕。

                      回复

                      1. 这个过程的好处是，如果写得当，这样的手册也可以作为人类的文档。

                         Claude 实际上非常擅长阅读项目文档和代码注释，并根据它们采取行动。因此，它也有助于鼓励项目作者编写此类文档。

                         我现在年纪大了，需要代码周围有这样的面包屑来理解上下文。如果没有它们，我就记不起自己为什么这样做了。

                         回复

                   2. 就像你编程一样…

                      将你的知识分解成与 Claude 相关的块，这样你就可以只看到上下文窗口中有用的内容。

                      回复

             3. 这只是一个工具，不是智能体也不是人。

                你使用它来让工作更轻松。如果它不能让工作更轻松，你就不会使用它。

                任何试图向你推销“这会让工程师失业”或“取代昂贵的软件开发人员”的人，要么是愚蠢，要么是撒谎(或者两者兼而有之)。

                我发现它非常有用，但它和计算机上的其他东西一样，是垃圾输入，垃圾输出。如果你的代码库注释清晰、文档完善，并且以一致的模式布局，它倾向于遵循该模式，尤其是在遵循标准的情况下。在具有严格类型系统和编码标准的语言(如Rust)中，它表现得更好。

                如果它有严格的测试来检查自己的工作，那就更好了。

                回复

             4. 它们不会自行学习，但你可以通过在它们犯错时添加指令来实现学习效果。你需要为初级开发者撰写代码审查反馈，因此这并非显著差异。

                > 不如直接培训一个外行成为软件工程师。

                而那个人会辞职，你不得不从头开始。他们至少要花100倍的成本。

                回复

                1. > 他们至少要花100倍的成本。

                   因为目前AI公司正在亏损——成本远高于他们收取的费用。

                   回复

                   1. 我一直在告诉大家，这就像2014年的Uber，你获得的利益是由风险投资资金支付的，这已经是很好的情况了。

                      回复

                      1. 没错，但技术进步如此之快，一年后我们可能能以10到100倍的低价获得同等性能。

                         回复

                         1. 错误，硬件进步速度并未快到能让成本降低10到100倍。

                            回复

                2. 世界不是零和游戏。

                   回复

             5. 并非如此。添加上下文文件大有帮助。拥有可参考的基准文件(ARCHITECTURE.md)大有帮助。关键在于引导并建立防护栏。

                说实话，感觉DevOps和产品团队生了个孩子。

                回复

                1. > 说实话，这感觉就像DevOps和产品团队生了个孩子。

                   你描述的简直是噩梦般的组合。DevOps——让我们把事情搞复杂(我在说你呢，K8s)——而产品团队——他们只关注漂亮的截图和流程，却从未真正将产品视为一个系统(或系统集合)。

                   回复

   17. 也许当你的 Claude Code 达到极限时，可以尝试使用 opencode 或 Gemini/Google 认证来粉碎它。

       回复

       1. Gemini 令人震惊、令人尴尬、令人羞愧地糟糕(对于像谷歌这样的公司来说)。即使是 Qwen 和 Kimi 这样的开放模型，在 opencode 上也更好。

          回复

          1. 根据我的经验，Gemini在多轮对话中表现不错。只需给它一个系统提示，一些用户/助手示例对，它就能产生很好的结果！

             而这正是它在编码方面的最大弱点。一旦它犯了一个错误，就完了。它似乎在这次“对话”中学会了要不断重复这个错误。然后它开始说些“哇，我真的把diff格式搞砸了！”之类的话。

             回复

          2. 啊，我猜可能是Gemini-cli代理本身导致了问题，所以也许可以试试opencode/Gemini组合。

             我想尝试“opencode+copilot 免费层认证”或“{opencode|crush}+通过 groq 调用某个模型(仍然免费？)”来看看能获得什么效果，以及是否还算不错。

             回复

   18. > 我使用 Claude Code 大约两周了，老实说，作为一个对编码持怀疑态度的人，我感到非常惊讶。

       然而，当我要求它纠正一个完全开源代码库中的 CMake 错误(依赖声明错误)时，它却无法解决。它甚至开始出现版本号和依赖关系的幻觉，这些错误非常明显，至少对我来说，这显然没有帮助。

       这始终是我使用AI编程的体验。每当我遇到一个我真的、真的希望AI能正确处理的问题(比如修正我的构建系统错误)时，它都会失败，而且失败得非常惨烈。

       似乎所有赞扬AI编程的人都有一个共同点——JavaScript。你自行判断吧。

       回复

       1. 当你让它处理一个通用问题并尝试解决时，通常会得到这样的结果，尤其是当问题依赖于外部信息(如特定版本号等)时。你必须告诉它去哪里查找信息，或者让它向你提问以确定如何解决问题。我个人使用它来处理原生代码、C++(使用CMake)、Zig以及一些Python代码。效果不错。

          回复

          1. 但使用AI的整个目的就是能够主动绕过像CMake这样的巨大失败垃圾堆。

             问题出在CMake特有的Git标签格式和命令上。这些内容本应在它摄入的文档中有所说明。

             如果人工智能连这么简单的事情都解决不了，那还有什么意义呢？

             回复

   19. 将Zen MCP连接到OpenRouter，并使用Cerabras推理与Kimi K2和Qwen3 480B在2k tok/秒下运行

       回复

   20. 你用Claude Code具体写了什么？

       我还没有尝试过，出于各种原因，但根据我(相当有限、轶事性且免费的)使用其他类似工具的经验，我可以让它们写出一些我可能在StackOverflow上得到答案的内容：范围有限、长度有限，最多解决一个重要问题；这可能与它们的训练数据有关。但一旦事情变得复杂，就毫无希望了。

       你说 Claude Code 比一些替代品好得多，所以比我描述的要好，但——我们需要知道是在什么方面好。

       回复

       1. 不是用 Claude Code，而是用 Cursor 和 Claude Sonnet 4，我编写了一个完整的塔防游戏，包括标题、教程、几波敌人的游戏玩法和“倒带时间”机制。整个项目基本上是基于氛围编码完成的，我可能只修改了十几行代码。看来效果并不糟糕 [0]

          [0] https://news.ycombinator.com/item?id=44463967

          回复

       2. 我一直在使用这些古怪的机器人设计一个相当复杂的系统，以迭代探索各种不同想法。在编写任何代码之前，我先通过概念验证来探索每个决策的优缺点。此时代码只是形式上的，因为每个部分都已规划并记录在案。

          与之形成对比的是 peg 解析器虚拟机，它基本上是一次性完成的，但需要大量调试工作。一个模糊的规格(基本上就是 lpeg 论文)和几次迭代后，它产生了一个经过充分测试的虚拟机。之后，从 AST 到操作码的编译器非常简单，因为它只需要进行一些简单的(此时已完全定义)转换，就这样搞定了。虽然不是最好的代码，但这是一个工作且经过测试的系统。

          随后，我对“ yak shaving ”的偏好占据上风，因为 AST 需要重写以使作为 Python C 扩展模块的集成成为可能(并生成)。既然可以集成，为什么还要分别进行 AST 和操作码优化阶段？哦，还有，既然可以重写虚拟机以使用延续传递风格(CPS)，并让整个机器以AST→CPS转换→优化器→执行的方式运行，那么为什么还要使用操作码呢？

          所以，是的，我认为可以说这些“傻瓜机器人”比一个StackOverflow聊天机器人要复杂得多。此外，我真正正在做的事情要复杂得多，重新实现 AST 只是个开端。

          回复

   21. 我也是这样，后来切换到了第一个 Max 计划。就我目前尝试的内容而言，它在令牌使用上非常高效。

       回复

   22. 我没有使用过 Claude Code，但最近经常使用 Amp。Amp 总是能达到预期效果。他们创造了非常特别的东西。

       这里有人同时使用过 Claude Code 和 Amp 并能比较两者的效果吗？我知道一个是 CLI，另一个是编辑器扩展。我正在寻找更深入的比较。谢谢！

       回复

       1. 我不知道为什么没有人谈论 Amp。它比 Claude Code 更好。

          回复

          1. 它消耗信用太快了。作为 Sourcegraph Cody 的老用户，我首先尝试了 Amp，但每天都要花几十美元进行试用，而且还要注意使用情况。看到我大部分钱都是花在它的错误和调试时间上，感觉非常糟糕。有了 CC，我可以放下焦虑了。我每天可以使用 Claude Pro 计划几个小时，目前来说这已经足够了。如果不够，我会升级到 Max，因为 100 美元的价格仍然低于我花在 Amp 上的钱。

             回复

             1. 对我来说也是这样：我不想为代理的错误买单，即使这些错误部分是由于我的提示词造成的。如果这意味着我可以支付每月固定费用，我愿意接受使用限制。不过，考虑到这些服务对公司来说成本高昂，我不确定这种情况能持续多久。

                我觉得Amp的成本实际上与Sourcegraph的成本相当，而最终Anthropic、OpenAI等公司都会收取比现在高得多的费用。

                这是典型的低成本吸引用户，然后在用户上钩后逐步提高费用的策略。目前他们还能承受烧掉风险投资资金，但这种情况不会永远持续下去。

                回复

             2. 我的 AMP 账单比 Claude Code 少，但我完成的工作却更多。

                回复

   23. 25 年过去了，你认为这是你职业生涯的巅峰吗？接下来你会去哪里？只是做 Claude 代码直到生命结束吗？

       回复

       1. 这对我来说其实并不是什么太大的变化。我已经从事建筑设计工作有好几年了。我关注的是整体规划，如何让各种元素有机结合，以及如何将复杂的问题简化。我甚至在当前的人工智能出现之前，就开玩笑地称自己做的事情为“无需编码的编程”。只是现在我多了一个可以用来编写代码的工具。

          回复

   24. 试试openrouter.ai，你可以按提示购买信用点，而不是一次性支付固定费用，它还会轮换密钥以避免被限流，甚至可以在其索引中的任何模型上使用相同的信用点

       回复

   25. 我使用得越多，就越意识到我最初两周的惊叹感不过是幻觉。

       我不会告诉你它没用，它确实有用。但光环褪去得很快，当它褪去时，你基本上只剩下一个更快的打字方式。至少在我看来是这样。

       它很神奇，但也很愚蠢。

       回复

   26. 我觉得 Cursor 可以在不进入终端的情况下提供相同的体验。我不明白 Claude Code 到底好在哪里。

       回复

       1. 我真的不知道是什么原因，但 Claude Code 似乎是一个非常精良的软件包。你可以拥有相同的核心模型，但内部提示很重要，它们如何查找额外上下文很重要，添加外部上下文的难易程度很重要，它如何应用更改很重要，它实际使用外部工具来帮助你的积极程度很重要。使用 Claude Code，感觉就很对劲。当我说我想进行审查时，我得到了审查；当我想获得代码时，我得到了代码；当我只想进行一些 git 整理时，我也得到了整理。

          回复

       2. 我没有发现使用相同基础大语言模型(LLM)的工具之间存在巨大的性能差异。

          Claude Code 的优势在于，您可以支付固定的月费，获得比仅使用 API 请求更多的功能。

          回复

          1. 我的体验并非如此，对我来说，使用 Claude 的 Copilot 与 claude code 完全不同。这只是我的个人体验和“感觉”，但这就是我的体验。

             回复

       3. 我使用 neovim，所以 claude code 对我来说更合理。我认为，代码代理与代码编辑器独立是一个加分项。

          回复

       4. 我大部分开发工作都使用Vim，所以本来就在终端环境中。我喜欢当前的编辑器配置，而无需大幅更改编辑器就能获得编码助手的优势，对我来说价值巨大。

          回复

       5. 原生工具的使用是革命性的。当我要求它调试某个问题时，它可以独立地向方法添加调试日志、运行测试、收集输出，并根据这些信息进行编码，直到测试问题得到解决。

          回复

       6. 上周末，我疯狂地看了很多 YouTube 视频，了解代理工具的概况。

          很多用过 Cursor 和 Claude Code 的人都说 Cursor 比 Claude Code 差很多。

          回复

          1. 我花了几周时间将以 AIDE 为中心的(Cursor、Windsurf)和以 CLI 为中心的(Claude Code、OpenAI Codex、Gemini CLI)选项应用到实际任务中，对我来说，Cursor 是最无效的工具之一。我最终选择了 Claude Code，对此非常满意。

             回复

             1. 我意识到 Claude Code 是我想要的工作抽象级别。Cursor 等工具仍然让我陷入代码的泥潭，而实际上我只想在审查时查看代码。这是一个我仍然需要审查的实现细节，因为即使在完美指导的情况下，它也会出错，但除此之外，我希望在接口、架构和组件方面进行思考。低级代码，我不在乎。它符合规范和惯例吗？它能正常工作吗？对我来说，这就足够了。

                回复

       7. 我把 Cursor 列为我尝试过的工具中的第四位。Claude Code、Junie 和 Copilot 都做得更好，我更喜欢它们。

          回复

2. Claude Code 明显领先于其他工具。(我从2023年开始编写自己的AI代码生成命令行工具，在这段过程中尝试了市面上大多数选项。这已成为我工作的重要组成部分，因此我对此有深入了解。)

   我认同作者的许多做法：

   1. 单仓库(Monorepo)能节省时间

   2. 从良好的规范开始。花足够的时间在规格说明上。如果你提供一个好的大纲，AI 可以为你撰写大部分规格说明。

   3. 从一开始就确保有测试。这是最重要的一部分。测试(加上良好的规格说明)是 AI 代理能够递归到良好解决方案的方式。TDD 又回来了。

   4. 类型很有帮助(非常有帮助！)。代码检查工具也有帮助。这些是安全护栏。

   5. 将外部文档放在项目文档中，例如在 docs/external-deps 中。

   6. 最后，与所有工具一样，需要时间来找到最适合你的技术。这比以前容易了(尤其是使用 Claude Code)，但仍然需要学习一些东西。我认识的每个人都有略微不同的工作流程——这有点像编码。

   我本周编写了大量代码。其中包括 Permiso [1]——一个极其简单的 GraphQL RBAC 服务器。它远未经过充分测试和审查，但如果你想要一个简单的解决方案(并且可以等待它被审查)，它已经相当有用。

   [1]: https://github.com/codespin-ai/permiso

   回复

   1. > 2. 从一个好的规格说明开始。花足够的时间在规格说明上。如果你提供一个好的大纲，你可以让 AI 帮你写大部分的规格说明。

      具体来说，你是如何概述规格说明的？是一个配套的Markdown文档吗？详细程度如何？等等。

      > 3. 从一开始就确保有测试。这是最重要的一部分。测试(加上良好的规格说明)是AI代理能够递归找到良好解决方案的方式。TDD又回来了。

      讽刺的是，我一直在为此苦苦挣扎。为了获得最佳效果，我发现 claude 最适合使用测试钩子，但 claude 失去了在代码运行之前编写测试以验证错误/假设的能力，它只是开始自动修复问题，这可能会有些不稳定。

      这有助于确保它不会忘记或放弃任何东西，但在某些设计/原型阶段，这同样有害。我已经设置了一个标志，可以启用/禁用测试行为。

      回复

      1. 我为此编写了一个工具，允许您与大语言模型(LLMs)共同创建和维护上下文存储库。

         https://github.com/jerpint/context-llemur

         CLI 用于人类，MCP 用于大语言模型(LLMs)。上下文存储库中的任何内容都应由大语言模型(LLMs)用于下一步操作，随着任务的完成和项目的进展，你们都负责维护它。

         到目前为止，我使用它取得了很好的成功。

         回复

      2. 我将从基本的标记大纲开始，然后使用一个提示来描述系统的更多内容，以流畅(但连贯)的想法，最重要的是，我会要求模型“以大语言模型(LLM)能够最好地理解和利用的方式组织规格”。结果是一个更简洁的文档，包含所有重要的部分。

         (或者——如果你需要向经理们展示这个文档，你可以写一个更适合人类阅读的规格说明。然后要求大语言模型(LLM) 写一个专门为大语言模型(LLMs) 量身定制的单独规格说明文档)。

         回复

      3. > 我很好奇你具体是如何概述规格说明的。是一个姐妹标记语言文档吗？它有多详细？等等。

         是的。我用Markdown格式撰写大纲，然后让AI进行扩展。接着生成项目结构，包含预设的API签名。随后持续优化，直至达到理想的细节程度——包括完整的API签名和数据库 schema。

         > 讽刺的是，我正为此苦恼。为了获得最佳效果，我发现 claude 最适合使用测试钩子，但 claude 失去了在代码运行之前编写测试以验证错误/假设的能力，它只会自动修复问题，而且可能会有些不稳定。

         我首先生成一个比较基本的原型。此时，我已经有了一个好的规格、一个好的项目结构、API 和数据库架构。然后不断改进测试和代码。正如我所说的，类型和代码检查也非常有用。

         回复

         1. 什么类型的项目更适合这种方法？因为我的工作流程，除了大语言模型(LLM)代理之外，一直依赖框架为我提供基础抽象，以便我在此基础上进行构建。最难的是确定业务领域，这需要与利益相关者进行多轮讨论才能完成。相比之下，编码就相当轻松了。

            回复

            1. 这就是为什么使用大语言模型(LLMs)进行编程时，不同人群之间节省的时间会有如此大的差异。如果你拥有所有的领域知识，而且问题足够通用，那么效率会提高 100 倍。否则，你的经验可能会从 0.1 倍到 10 倍不等。

               回复

         2. 我甚至不自己写大纲。我会让CC提出一个计划，然后我们与CC一起迭代这个计划，我可能会将它交给Gemini进行审查，并让CC应用Gemini的建议。

            回复

            1. 我专门为这个工作流程打造了一个工具，但其中包含了 MCP 和版本控制功能，因此您可以在任何平台上轻松跟踪和编辑文件，包括 Cursor、Claude 桌面等。

               https://github.com/jerpint/context-llemur

               回复

      4. Playwright 对 Claude 来说是一项繁重的工作，但我不敢没有它。似乎 70% 的时间都花在修复 Playwright 的混乱上了。它难以运行测试、基本数据设置和清理、认证以及基本最佳实践。我有一份测试指南，概述了所有这些内容，但它对每件事都敷衍了事。

         回复

   2. > 1. 单仓库可以节省时间

      是的，它们可以为您节省一些时间，但代价是 Claude 需要花费时间，并且需要大量令牌来调用工具，以尝试找到它需要找到的内容。从您可以添加它需要了解的文件，然后将其发送出去执行任务的角度来看，Aider 更胜一筹。

      我仍然不明白为什么 Claude 比 Aider 更受欢迎，因为从几乎所有方面来看，Aider 都是更好的工具，而且可以使用更适合当前任务的大语言模型(LLM)。

      回复

      1. 从你可以添加它需要了解的文件，然后发送给它执行任务的角度来看，Aider 更不错。

         作为用户，我不想坐在那里指定大约15到30个文件，然后发现自己漏掉了某些文件，从而破坏了整个流程。我希望只需将工具指向代码库，并告诉它：“去执行X任务。查看当前实现、模式以及测试，同时参考文档。在过程中根据需要更新一切，这是如何运行测试的……”

         将整个代码库索引到 Qdrant 中也许也会有些帮助。

         回复

         1. 我认为这样做是有道理的，但至少对我个人而言，在 Aider 中手动管理上下文比让 Claude Code 自己尝试找出所需内容能获得更好的整体效果。

            虽然这可能令人烦躁，但我认为这有助于我更清楚地了解正在发生的变化(而非只是在一段时间后看到一个巨大的差异)，并且更适合处理那些更可能一次成功的较小子任务。

            回复

            1. 如果你能提供相关的文件作为起点，CC中的结果也会好得多。从这个角度看，这两个工具其实差别不大。

               回复

         2. Aider确实知道整个仓库树(它会扫描Git索引)。它只是在您告诉它之前不会读取文件。如果它认为需要访问某个文件，它会提示您添加该文件。我认为这是一个相当不错的模型。当然，它无法在离线状态下工作。

            回复

      2. 因为它有效。

         老实说，就是这样。“foo modal 上的 Claude 栏按钮因 splork 失败而损坏”。CC会追踪foo.ts，发现这是一个查询query.ts的API调用，拉取关联的链接模型，追踪api/slork.go，并经常会得到“我找到了问题！”并修复它。只需一句提示。我认为第一次看到它工作时，这被称为“哦，天啊”的时刻。而且它的工作非常可靠。[手势警告、愚蠢的大语言模型(LLMs)等]

         回复

      3. 作为单仓库的替代方案，您可以通过告知工作区相关代码位于您机器上的 XXX 路径来添加另一个仓库。Claude 会将该代码添加到您当前会话的工作区中。

         回复

      4. > 从你可以添加它需要知道的文件，然后发送给它去完成工作的角度来看，Aider 更不错。

         在 Claude 中使用 /add-dir

         回复

   3. 同意，为了使 CC 正常工作，它需要相当多的结构

      我一直在做一个 Django 项目，它有很好的测试、类型和文档。CC 大多表现良好，尽管偶尔需要一些指导

      最近还启动了一个副项目，尝试在本地模型下离线运行 CC。在 ChatGPT 的帮助下，我成功运行了第一个版本，随后决定切换到 CC。CC 始终试图回避解决最重要的问题，绕过错误，对于几乎所有情况都选择创建一个采用不同方法的新文件/脚本(而非修复或重构现有代码)

      回复

      1. 我发现结构比依赖其意识流更关键。

         对于单元测试，我实际上会预先编写一些测试，以便它能学习我期望的结构。我甚至会编写模拟对象和测试类来“限制”它能做的事情。

         在约束下，它的表现远优于从零开始即兴发挥的情况。

         这与数值优化有相似之处：若直接让求解器优化复杂的非线性(非凸)函数，很可能陷入局部最优或停滞不前。但若精心约束其搜索空间并引导其路径，就能显著提升达到最优解的概率。

         大语言模型(LLMs)本质上是具有巨大搜索空间的大型函数评估器。你越能引导它(就像把一群羊赶到正确的围栏里一样)，它就越能收敛。

         回复

   4. > 将外部文档放入项目文档中

      大多数项目都在其网站上提供了文档。你会花时间将它们格式化为整洁的 Markdown 文件吗？

      回复

3. 当您意识到 Claude Code 的功能远不止于编写代码时，您就会体会到它的真正威力。

   事实上，它可以控制您的整个计算机。如果有 CLI 工具，Claude 可以运行它。如果没有 CLI 工具……还是问问 Claude 吧，您可能会感到惊讶。

   例如 我用 Claude 裁剪和调整图像大小、从 YouTube 视频中提取 MP3、剪切音频文件中的静音部分，等等。它为我节省了大量时间。

   我已经记不起没有它之前的生活了。再也不会回头了。

   回复

   1. 你可能想给 Claude 一台电脑。除非你了解情况，否则我不确定你是否总是想把你的电脑给它。

      我们有运行在云虚拟机上的Linux实例，这些实例上运行着一个集成开发环境(IDE)，我们可以通过浏览器访问该环境，地址为https://brilliant.mplode.dev。我个人认为，这种方式更接近于操作代理的理想用户体验(我们的环境目前尚未默认安装代理，但您应该可以手动安装)。除了登录并等待初始实例启动外，您无需做任何事情来设置终端访问或 ssh，一旦您配置了任何实例，它就会根据您的浏览器是否打开自动暂停和恢复。它实际上就是 Claude + 一个个人 Linux 实例 + 一个 IDE，您只需从链接打开即可。

      很快我就能同时运行尽可能多的此类实例，并通过 JWT 和容器控制它们的所有权限/文件系统/等。如果出现问题或需要处理，我只需通过 IDE 作为用户界面打开它，即可直接进入并修复。我无需常规的 Linux 桌面环境或用户界面等。只需在IDE的面板中渲染内容，或启动一个运行所需Web应用的容器并直接打开它，而非通过IDE。我从未对技术进步感到如此兴奋

      回复

   2. 我用它诊断了Linux电脑崩溃的原因。它帮我执行了大量journalctl命令，我对它的帮助感到欣慰。可能已修复问题，但需进一步验证。

      回复

      1. 我在启动时遇到内核 panic，我通过加载之前的内核来绕过这个问题。结果发现我的启动分区空间用完了，但在最初的调试和修复过程中，我已经陷入了包损坏的状态。

         我出于好奇心将控制权交给了它，而且因为不想继续折腾一整晚，但令我惊讶的是(在我的逐步指导下)，它确实解决了所有问题。它找到了未使用的内核，在卸载后未删除它们，而是使用 rm 命令删除了它们。随后它帮助修复了包损坏状态，最终我恢复了干净的工作状态。

         然而，重要的是，它并不知道最初并未清理启动分区。我不得不坚持指出它并未真正释放空间，而是需要删除这些文件。

         回复

   3. 我通过传统方式学会了如何构建Imagemagick/Mogrify命令。借助AI工具的辅助可以节省大量时间。

      回复

   4. 除了运行 CLI 命令之外，您还可以让 CC 与它们进行交互，例如，我构建了一个小工具，为 CC 提供了一个 Tmux-cli 命令(一个围绕 Tmux 的便捷包装器)，使其能够与 CLI 应用程序进行交互并监控它们等：

      https://github.com/pchalasani/claude-code-tools

      例如，这使 CC 可以启动另一个 CC 实例并为其分配任务(比内置的“启动并放手”黑盒功能好得多)，或与需要用户输入的 CLI 脚本交互，或使用 Pdb 等调试器进行令牌高效的调试和代码理解等。

      回复

   5. 完全同意。另一个用例是静态网站生成器。我只需使用我想要的语法撰写文章，然后告诉 Claude Code 将其转换为相同格式的博客文章即可。例如，我只需在文章中写上“在此处添加 image.jpeg 图片”，它就会添加该图片——这比使用 Markdown 或 Hugo 更简单。

      回复

   6. 这是自动化者的梦想成真。任何事情都可以自动化、编写脚本、记录在案。即使将来我们要使用其他(可能是本地)模型，这也会是我首选的界面。它太强大了。

      回复

      1. 是的，Claude 已经取代了 XKCD 1319：

         https://xkcd.com/1319/

         自动化现在变得非常容易。我想到另一种加快工作流程的新方法——例如，为一些烦人的重复性任务编写一个 shell 脚本——而 Claude 一次性就完成了。生产力提高带来了生产力提高。

         回复

         1. 这不是我以为的 xkcd。这是 Claude 代码让我想起的 xkcd：

            https://xkcd.com/1205/

            我觉得 Claude 代码对 1319 中的问题一点帮助都没有。如果有的话，它只是增加了“持续开发”的普遍性，因为我自动完成了更多事情，并制造了更多需要解决的问题。

            然而，我修复了 10 年前的脚本，并添加了新功能，而我从未认为这些工作值得付出代价。这降低了自动化的成本。

            回复

         2. 与pywin32结合以打开窗口。

            回复

         3. 它没有造成任何损失。可能缩短了某些任务的时间。尝试一些不那么简单的任务，你仍然会花费比节省更多的成本。

            回复

      2. 拥有大量GPU以全功率运行来实现你的自动化目标并非梦想成真，而提供这些GPU的公司因此损失了大量资金：

         https://www.wheresyoured.at/the-haters-gui/

         … 同时也会使您的计算机内容暴露在监控之下。

         回复

         1. 嗯，确实有这种情况。

            我更想称赞的是这种范式转变(在一定程度上，这可以通过更小、更开放且有时是本地化的代理模型来实现)，但确实存在一些不良外部性(尽管烧钱对我来说并不是最优先考虑的问题)。我希望一些外部性可以被优化消除。

            这是一个公平的评论。

            回复

         2. 我加上每年$1200的订阅费，仍然比两个我便宜得多。

            回复

            1. 关键是成本远不止$1200，只是你不是承担所有成本的那个人。似乎有大量HN用户对完全依赖一个最终必须通过“跑路”来维持业务运营的工具感到无比兴奋。感觉非常遗憾的是，这门手艺现在开始完全依赖于这样的工具，甚至连最基本的编程任务都要依赖云端来完成。

               回复

   7. 一切都很好，直到

      >> 我以为在过去6周内，拉取请求、提交和合并的代码行数会发生相当大的变化。但我认为这站不住脚

      图表基本上显示了与之前使用 claude 时相同的输出结果。这某种程度上代表了我使用大语言模型(LLMs)时的感受。

      你会“感觉”自己更高效，而且肯定会感觉“更好”，因为你现在不用做工作了，只需照看模型，就会感到自己很高效。

      但最终，输出结果还是一样，因为大语言模型(LLMs)的所有优势都会被你审查、修正、重新提示等花费的时间所抵消。

      而且，由于你卸下了“艰巨”的部分，没有锻炼思维能力，你的技能会迅速下降。

      尝试使用 Claude 或其他大语言模型 (LLM) 一个月，然后尝试在没有它的情况下制作一个小应用程序。不仅代码部分看起来很难，而且总体架构/结构也难以理解。

      最终，整个代码库会慢慢(但不是那么慢)退化，从长期来看，结果是负面的。至少对于当前的大语言模型 (LLMs) 而言是这样。

      回复

      1. 我最近一直在探索氛围编程，到目前为止最大的好处是减轻了精神压力。

         你不需要同时记住代码的整体概念，以及接下来一小时的代码技术实现会是什么样子，同时还要应对一个顽固的 bug 的挑衅。

         你只需询问智能机器人，它就能提供从校对到文档编写等各种服务，偶尔会出现一些小错误

         回复

         1. 但心理压力正是你提升技能、在工作中变得更优秀的途径。如果压力过大，或许你的代码架构或实现方式需要改进。

            这听起来很像“这个机器人帮我做作业，现在我成绩很好，不用那么努力学习了！”

            回复

         2. 只要没有大语言模型(LLM)无法解决的错误，一切都还好，但一旦出现错误，你就必须自己进入代码，然后你会发现它搞得一团糟。

            回复

            1. 也许你设定了很高的质量标准，但我并不认为大语言模型(LLMs)会创建混乱的代码。如果有的话，它们在结构化和逻辑排序方面比我更勤奋，更清晰。例如，我经常在开始时给变量命名时稍有错误，到最后才意识到应该稍作修改，但我很少去重新命名所有地方。即使有自动重构工具来处理，这也超出了我能投入的时间范围。我可能会在某个地方添加一条注释，解释其含义与命名略有不同。但这种情况要乘以100倍。

               回复

               1. > 它们在结构化代码、确保逻辑顺序清晰方面比我更严谨

                  是的，但有一个前提：仅限于第一次/零次迭代。即使他们保留了大部分/全部代码的上下文，如果你在没有严格的结构化/防护措施的情况下编写代码，到了第三或第四次迭代时，模型已经“忘记”了原始架构，会为当前迭代所需的数据结构进行重复定义，并最终导致类似健忘症般的重复代码， 重复的代码做“基本上相同”的事情，所有这些都进一步阻碍了进展。你深入得越深，没有人类干预，情况就越糟。

                  你可以走另一条路，而且它确实有效。设置严格的类型、清晰的模式、清晰的结构。并干预以解释和指导。这是高级工程师在初级PR中会反对的事情。“为什么你不直接扩展现有数据结构，并将那次调用提取到XYZ的显而易见的扩展中？”

                  “你完全正确！”等等。

                  回复

               2. > 也许你设定了非常高的质量标准

                  是的，当然。你不是吗？你不觉得使用AI因为不在乎质量而感到尴尬吗？

                  我感到羞愧，因为“你设定了高标准”被当作某种批评

                  回复

            2. 我还没遇到过这样的 bug。如果调试第二次失败，我通常会切换到其他模型，或者让它在代码中大量输出控制台日志，编写测试脚本并进行网络搜索等。

               这些模型的优势(也是劣势)在于它们的耐心是无限的。

               回复

               1. 嗯，我没有耐心等待它找到正确解决方案啊哈哈

                  回复

         3. “精神压力”在记忆/思考方面就像肌肉拉伤。你需要保持状态，否则它会开始萎缩。

            回复

            1. 我的朋友，没有确凿的证据证明情况确实如此。到目前为止，有一系列的研究，大多是预印本，提出了模糊的推论，但都没有明确证明精神紧张的缺乏与大语言模型(LLMs)导致的大脑功能萎缩之间存在因果关系。

               回复

               1. 你说得对，人类几百年来的经验表明，需要持续练习才能保持敏锐的技能会随着时间推移而退化。问问那些从事无法伪装的技能的人，比如弹钢琴，几个月不练习会对他们的能力产生什么影响。公平地说，你恢复这些技能的速度会比从未掌握过这些技能的人快得多，但技能绝对会退化，如果你不积极参与其中。

                  回复

                  1. 我的组装技能已经严重退化了，但没关系。

                     回复

                     1. 使用大语言模型(LLMs)并不是提升抽象水平，而是将你自己的大脑从抽象中完全剔除。

                        回复

                        1. 我希望如此，但就目前情况而言，大语言模型(LLMs)必须被无情地驱动和限制。规范、架构、接口、测试、集成。当然你可以随心所欲地让它“煮出”某种东西，但那将是一团无法维护的乱麻。所以我尽量将自己的思维从代码的抽象层中抽离(尽我所能)，但绝不会从其他方面抽离。

                           回复

               2. 我们知道，学习和培养思维能力需要时间和努力。我们知道，当人们多年没有应用/练习编程时，他们的技能就会萎缩。我认为一个好的默认预期是，未使用的技能会随着时间流逝而消失。当然，问题是，我们与大语言模型(LLMs)的互动是否足以维持大部分技能？或者，人们可以培养新的技能来弥补失去的技能(即使不再使用大语言模型)？变化发生得有多快？是否存在更广泛的影响，无论是积极的还是消极的？

                  回复

               3. 我主要指的是技能，而非大脑功能本身。

                  回复

         4. 我明白你所写的内容正是“氛围编程”的核心，但我强烈建议你不要这样做。如果你不审查大语言模型(LLM)生成的代码，你就承担了技术债务。对于小型项目和脚本来说，这没问题，但对于你想长期维护的东西来说，就不行了。你不理解的代码本质上就是遗留代码。大语言模型(LLM)的输出应该符合我们的风格和品味，理想情况下应该看起来像我们自己的代码。

            如果这有帮助的话，把它称为代理工程，而不是氛围编码，以转换到一种更参与的心态。

            回复

      2. 对我来说不是这样。我刚刚对一个设备的蓝牙协议进行了逆向工程，这至少花了我几天时间来捕获数据流 wireshark。现在，我将整个转储文件放入了一个大语言模型(LLM)中，它让我能够更好地控制找到正确的偏移量等。我只花了一天时间就完成了。

         回复

         1. 这其实不算编程吧。

            没必要拿苹果和橘子比较，我们大多数人不会用Wireshark进行逆向工程编程。

            回复

   8. 你有可靠的备份系统吗？还是使用沙箱环境？

      回复

   9. > 如果有一个 CLI 工具，Claude 可以运行它。如果没有 CLI 工具……还是问问 Claude 吧，你可能会感到惊讶。

      这不需要 Claude 代码！只要在 r/unixporn 上逛逛，你就会收集到足够的脚本和技巧，意识到主流操作系统已经将计算机从有用的工具推向了消费主义玩具。

      回复

      1. 这就像说“你不需要汽车，只要在自行车店待久了，你就会发现你可以骑自行车在城里到处跑！”

         回复

      2. 用tar解压这样一个简单的任务都足够神秘，以至于在2025年，人们肯定不希望从陌生人那里收集Unix脚本。

         回复

         1. 它神秘直到你坐下来学习它

            tar xzvf <文件名> -> “tar 提取压缩文件 <文件名>”

            tar czvf <文件名> <文件> -> “tar 压缩文件 <文件名> <文件>”

            因此，如果你想解压一个tar文件或创建一个tar文件，只需使用x或c

            如果要解压的文件以.gz结尾，或者你想创建的文件是压缩的，则添加z。

            v 参数用于在解压或导入文件时将文件名打印到标准输出(stdout)

            f 参数用于从文件读取或向文件输出，而非从标准输入(stdin)读取或向标准输出(stdout)输出

            然后你提供要读取/导出的文件名，如果你要导出，还需要提供文件列表。

            这并不难。

            回复

         2. 脚本？我十年间用的最复杂的命令就是“tar xzf file”

            回复

            1. 记住一件事很容易，记住所有事情就难了。有了代理式命令行界面，我无需记住任何内容，只需判断是否安全即可。

               回复

               1. 但你如何记住使用代理式命令行界面？

                  回复

               2. 没有人能记住所有事情。通常是使用 Ctrl+R(历史记录搜索)或在某个脚本或别名中记录下来。

                  回复

            2. 啊，是的，那种“我从未需要过 X，所以显然世界上没有人会需要 X”的逻辑。真是无懈可击。

               回复

      3. 重点不在于工具是否存在。关键是：你不必关心这个工具是否存在，也不必收集任何东西。只需询问 Claude 代码，它就会按照你的要求行事。

         至少我是这样理解这条评论的。

         回复

   10. > 事实上，它可以控制你的整个计算机。

       老实说，这听起来像恶意软件。

       回复

       1. 我也搞不懂大家为什么用npm -g安装这些包却毫不担心

          回复

       2. 不，因为_你_在掌控。不是AI。

          回复

          1. 也许你今天能掌控。但这种情况会一直持续吗？使用Windows的用户对系统控制权远不及应有水平。人工智能的“垃圾化”是什么样的？

             我为什么要相信这些人工智能供应商？

             回复

4. 自从两周前首次运行 Claude 代码以来，我每天都会使用 12-16 个小时。以下是我发现的一些技巧：

   1. 立即切换到 sonnet(cli 默认使用 opus 作为最大用户)。我广泛测试了 opus 的编码，但它的质量永远无法与 sonnet 相媲美。

   2. 压缩往往会终止进度——压缩后很难恢复到相同的代码质量。

   3. 第一个提示非常重要，它决定了整体氛围。如果你的 Claude 实例显得犹豫、怀疑，有时甚至粗鲁，那么最好结束会话，然后重新开始。

   4. 有些短语可以提高效率。试试“如果这个建议不好，我很抱歉，但我想实施 x 和 y。”无论出于什么原因，这都会让 Claude 更愿意提供帮助。

   5. 与 Docker 协调的整体性：当我开始让 Claude 自己管理 Docker 容器、检查其日志中的错误、删除它们、重建它们等时，我的效率基本上提高了 10 倍。现在，我只需一个 Claude 提示，就可以在 Docker 容器中将一个全新的服务从零开始上线并投入运行。

   回复

   1. 您每天如何使用 Claude Code 16 个小时？

      回复

   2. 5. 不仅仅是 Docker，还要给它一个剧作家 MCP 服务器，这样它就可以看到它在 UI 和请求中实现了什么。

      6. 从计划模式开始，并迭代计划直到满意

      7. 使用斜杠命令，它们是你可以随时间不断优化的迷你提示，包括提供初始上下文并提醒它可以使用像gh这样的工具与Github交互

      我不确定我同意1。

      2. 在一个好的停顿点进行压缩，而不是被迫在0%时进行

      回复

      1. > 提供 Playwright MCP 服务器

         或者直接使用 `$ playwright`。跳过 MCP 流程(及浪费的令牌)，让 CC 直接使用 CLI 工具。效果出奇地好。

         回复

      2. 使用代理验证代码。代码是否过度设计、是否符合规范和标准、是否真正实现还是半吊子。我在功能或任务结束时运行这三个，几乎总是将 Opus 发回工作台修复大量问题。由于它们有自己的上下文，不会破坏主上下文，因此可以运行更长时间。

         回复

   3. 有时它在容器内部操作时过于积极，比如当我要求它理解某些代码时，它会以各种行不通的方式在容器内尝试运行代码。

      它曾执行过一个容器命令，将目标文件管道传输到项目命令行运行器，但毫无作用，这只是它坚持以各种古怪方式运行代码而非单纯读取代码的众多例子之一。

      回复

   4. 你在哪里托管这些容器？我们的无服务器/Linux CLI/浏览器 IDE(https://brilliant.mplode.dev)运行在我们新兴的云平台上的容器中，我们几乎准备好直接从 IDE 部署任意容器并开始提供服务。我很好奇，您是否遇到过任何延迟/数据/认证等难题。

      回复

   5. 我成功创建了一个非常详细的 plan.md 文件——详细到所有系统如何连接在一起，让我在睡觉时运行 claude-loop[1]，然后在早上回来手动修补它。

      [1]：https://github.com/DeprecatedLuke/claude-loop

      回复

      1. 你能列举一些你让它做的事情的例子吗？

         回复

         1. “` # PostgreSQL 网页 API 项目计划

            ## 重要 – 使用此错误，在 error.rs 中创建主结构体 ServiceError，该结构体包含所有 #[from], 不要使用自定义结果类型或为不同模块创建错误，所有错误都应归类于此结构体 – 上述错误应实现 IntoResponse 以将其转换为客户端错误，同时不泄露任何敏感信息，并使 ServiceError 可用作 axum 的错误类型

            ## 计划

            ### 项目设置(已完成) 使用服务器和 jwt-generator crates 设置 Rust 工作区(已完成) 使用所需的依赖项(axum、sqlx、jsonwebtoken、serde、tokio、uuid、thiserror)创建 Cargo.toml 工作区配置 (已完成)创建包含环境变量的 PostgreSQL 测试数据库 compose.yaml 文件(已完成)设计数据库 schema，包括 tables.sql 文件(数据表包含键 UUID、数据 JSONB、created_at、updated_at；锁表包含锁 ID UUID、locked_at、expires_at)

            ### 数据库层(已完成)实现数据库连接模块，包含 PostgreSQL 连接池(已完成)创建数据库迁移系统，若表不存在则自动部署 tables.sql(已完成)实现数据库实体的数据模型结构(DataRecord、Lock)

            ### JWT 系统(已完成) 创建 jwt-generator 工具，接受密钥、权限(读/写)和过期时间(已完成) 实现服务器端的 JWT 认证中间件，包含权限验证(已完成) 为端点添加 JWT 令牌验证和权限检查

            ### 核心 API 端点(已完成) 实现 POST /set 端点，用于存储/更新 JSONB 数据，支持使用 jsonb_set 进行部分更新(已完成) 实现 GET /get/<key> 端点，支持通过可选子键过滤进行部分数据检索(已完成) 在数据库操作中添加自动处理 created_at 和 updated_at 时间戳的功能

            ### 流式传输与二进制支持(已完成) 实现使用紧凑二进制格式(非Base64)的流式传输字节接口，以实现高效数据传输(已完成) 添加在GET请求中未指定特定格式时返回所有数据的支持

            ### 锁定系统(已完成) 实现基于数据库的锁定系统，包含锁定表(已完成) 创建 POST /lock 端点，尝试使用 UUID 参数获取锁定 5 秒(已完成) 创建 DELETE /unlock 端点，通过 UUID 释放锁定(已完成) 添加锁定超时及过期锁定清理机制

            ### 错误处理与最终优化(已完成) 实现全面的错误处理并返回正确的HTTP状态码(已完成) 为所有接口添加输入验证(UUID格式、JSON结构等)(已完成) 通过各种场景测试所有接口(有效/无效数据、并发访问、锁定超时) “`

            经过4次迭代(>30分钟！)，一切运行正常。该计划本身部分由ccl生成，因为我让它将任务分解为更小的步骤，然后通过一些手动编辑最终得到了这个结果。后来我将锁改为基于租约系统构建，它也处理得相当不错。

            回复

      2. 你就是他们所说的5%的人，哈哈。

         回复

         1. 令人惊讶的是，每天平均只有$70。

            回复

   6. 我让主代理使用Opus，并让它始终调用运行Sonnet的子代理。这是我找到的最佳配置。

      我关闭了自动压缩功能，改为手动压缩，这样可以轻松找到停止点，并在压缩前将所有上下文写入MD文件。

      第一个提示对我来说并不重要。

      我没有发现需要特殊短语。关键在于我能让子代理的上下文有多丰富。

      回复

   7. > 5. 通过 Docker 协调实现整体化：当我开始让 Claude 自己管理 Docker 容器、检查其日志中的错误、删除它们、重建它们等操作时，我的效率基本上提高了 10 倍。现在，我只需一个 Claude 提示，就可以在 Docker 容器中将一个全新的服务从零开始上线并投入运行。

      这非常有趣。你的设置是什么，你使用什么类型的提示让 Claude 与 Docker 很好地配合工作？你是否采取任何措施将 Claude 实例与机器的其他部分隔离开来(即在虚拟机中运行这些 Docker 实例)，还是只是随心所欲？

      回复

      1. 虽然我不是父母，但我完全也在这么做。我一直在使用 docker compose，Claude 似乎在范围方面理解得很好——它会运行“docker compose logs foo”、“docker compose restart bar”等命令。我从未尝试过隔离它，不过我通常不会随意放任不管，而是会密切关注它的运行情况并进行审批(我也会查看代码差异)。它可以无权限访问某些内容，但其他操作我都会进行审查。

         回复

      2. 我直接放手让它运行，不需要太多指导，它知道如何使用 Docker 和 Compose 等工具，如何获取日志、执行命令等。

         “在我的本地 Docker 中启动这个服务”会让你得到一个运行的服务，你可以根据需要进一步指定更多参数。

         回复

   8. 我对第 5 点非常感兴趣。作为一个虽然意识到 Docker 的重要性，但仍然刻意回避它的人，我很想知道你的提示的一般格式。

      回复

      1. 这是 Claude 编写“看起来不错”的代码与实际运行的代码之间的区别。你不再需要说“嘿，帮我修复这个代码”了。你可以说：“使用 tmux 创建一个持久会话，然后在那里运行这个 python 程序，并对其进行调试，直到它能够完美运行为止。”

         回复

   9. 让 Claude 管理 Docker 真的非常不错。

      我正在为未来的自己编写一份指南，以便在 6 个月后忘记如何打包现有产品时可以参考。

      与此同时，前沿模型可能会改进它、使其变差，或者保持不变，而我追求的是一致性。

      回复

5. 无论 Claude 代码实际上有多好(我没有使用过它，但我认为这篇文章提供了非常有说服力的论据)，以下几点让我感到不安： 我还是个新手，我有一个庞大、缓慢且丑陋的GDScript代码库(基本上是Python)，我打算将其转换为C#，以清理代码并提高速度。

   这是个个人项目，我之前没有写过太多C#代码，也没有做过如此大规模的重构，所以这在多个方面都可能具有教育意义。

   如果我为此使用 Claude，我会觉得自己剥夺了可以学到很多东西的机会(也许还能激励我将来更好地构建代码结构)。如果我不使用 Claude，我会觉得自己把(非常稀少的)空闲时间浪费在了一项毫无乐趣的任务上，而这项任务在未来的大多数工作中很可能被自动化取代，这主要是出于我对编程工艺的一些(错误？受虐狂？

   现在，我的脑海中经常出现这种关于项目的纠结。

   回复

   1. 我已经从事开发工作 35 多年了，但无论使用什么大语言模型(LLM)，我都会做一件事：我要求它解决一些我通常知道自己可以解决的问题，只是我不想做。

      例如：昨天，我正在处理一个 Open API 3.0 架构。我知道我可以“修复”该架构以符合一个示例输入，但我只是不想做，因为这很无聊，我以前做过，而且我不会学到任何东西。于是，我让 Claude 来做，结果很好。然后，“示例”部分不再与架构匹配，于是 Claude 为我写了一个合适的示例。

      但关键是，我这样做不会学到任何东西。

      然而，有时我确实会学到一些东西。因此，每当我发现大语言模型(LLM)向我展示了新知识时，我会将该知识放入我的“知识库”中。我使用Anki SRS闪卡应用来实现这一点，但也有其他方法，比如添加到你的“TIL博客”(我也这样做)，或者将这个新知识从头开始写出来，不看解决方案，重复几次并编译/运行它。然后尝试想出这个知识可以以不同方式应用的方法；改变要求并写出来。

      基本上，让我的大脑以至少两种方式与这个新事物互动，以便它能与大脑中的其他知识融合。这是非常重要的。

      学习一门新的(口语)语言时，这种方法被广泛应用。学到一个新单词？把它用在三个不同的句子中。学到一个新短语？基于它创建至少2-3个新短语。

      我希望这能让我的大脑保持足够的活跃，继续前进。

      回复

      1. 我期待着大语言模型(LLMs)能够自动将这样的知识放入Anki或类似的东西中。

         回复

         1. 我发现，在Anki上学习的重要部分是自己制作卡片。使用别人的卡片/通过LLM生成的卡片是不一样的。

            回复

         2. 我为Open-webui开发了添加到Anki的工具。我觉得它们工作得很好。可能还有MCP工具。

            回复

   2. 根据我的经验，如果你不审查生成的代码，并且没有足够熟练地掌握C#来做到这一点，代码库会很快变得一团糟。

      大语言模型(LLM)编码会累积错误，除非你纠正这些错误，否则最终会得到一个脆弱到毫无价值的代码库。

      我的朋友们显然没有这个问题，他们说他们让大语言模型(LLM)编写了足够的测试，可以在早期发现脆弱性，但我还没有尝试过这种方法。遗憾的是，我的代码往往不是非常算法化，因此很难测试。

      回复

   3. 经过 16 年的专业编码，我可以说 Claude Code 让我在那些我必须苦苦钻研才能学到的东西上有了很大的进步。对于我需要学习的新知识，为了提高工作效率，它就像其他学习体验一样，“来得容易，去得也容易”。

      我的建议是：

      如果你目标是全面学习，我建议优先选择缓慢而耐心的学习路径(无论外界变化多快)。

      如果你的目标是快速学习，那么 Claude Code 和其他人工智能工具会对此有所帮助。我发现，与“代理”模式相比，“询问”模式(如果可用)更有利于实现这个目标。我喜欢用类比、场景和记忆技巧来帮助理解新概念。

      如果你只是想快速完成任务，那么掌握编写规格说明并让代理自行运行，当然要确保在过程中添加大量测试。

      我认为所有方法都有一定价值，只要我们在构建东西。

      回复

      1. 是的！有价值、基础等——自己动手，走慢路。

         无聊、无趣、平庸——最重要的是——容易逆转且不重要——交给大语言模型(LLM)吧！

         在学习东西时，内在动机会让人变得非常有效率。所以，如果你喜欢某个领域，就专注于它吧。这会让你在有价值的事情上进展得更快，无论如何，这是最好地利用时间的方法。

         当你不在工作时进行软件开发应该是有趣的。如果它不有趣，那就只做最符合你目的的最低限度努力。并且只对你关心的部分保持极度勤奋。

         依我之见，那些认为每个人都应该从第一性原理出发，像瑞士钟表匠一样勤奋地做每件事的人，只是在故意为难自己。这只是做事情的一种方式，但绝不是唯一正确的方式。

         关注重要的事物。如果某件事既不重要也不有趣，那就以最不痛苦的方式处理它，然后专注于能带来价值的事情。

         回复

   4. 几年前，博客上流行一种趋势，就是“自己写一个x”而不是使用库或其他东西。通过自己实现一个东西，你可以学到很多关于软件的知识。想了解客户端路由的工作原理吗？那就编写一个客户端路由器吧。我认为，大语言模型(LLMs)基本上已经使任何东西都可以成为“库”代码。所以，这实际上取决于你想从项目中得到什么。你想提高 C# 技能吗？那么你应该自己进行移植。如果你只想获得移植后的代码，并专注于其他方面，那就让 Claude 帮你做吧。

      如果你的目标是学习，那么无论做什么都必须经历某种程度的挑战。我发现，当某件事感觉太容易时，我通常并没有学到多少东西。

      回复

   5. 在AI出现之前，人们靠复制粘贴代码。那些从Stackoverflow复制代码却不理解其原理的人，实际上什么都没学到，我亲眼见过很多次。我认为你寻求建议或概念没有问题。但如果你让它为你写下一切，你肯定不会学到东西。

      话虽如此，你必须保护作为开发者的时间。有无数东西需要学习，如果你作为初级开发者的目标是制作游戏，那么移植GDscript代码听起来并不是对时间的绝佳利用。尽管你肯定会从中学习。

      回复

      1. 现在不同的是，大语言模型(LLMs)提议为一切提供复制+粘贴功能，并且完全符合你的具体情况。至少在 Stack Overflow 上，你通常必须根据具体情况调整答案，而且往往没有更深奥问题的答案。

         回复

   6. 我认为这是一个非常有趣的观点。作为一个资深人士，我读到这里有一些想法。

      目前事情进展得很快，但我认为它感觉更快，是因为过去十年事情进展得太慢。我在90年代中期到后期开始涉足网页开发，我认为当时的局面也类似。当时圈内人士都明白网络将迎来爆发式增长，但某种程度上我们也清楚变革会来得很快。我们所掌握的知识很快就会过时，成为下一波新知识的养料。

      对我来说，过去10到15年间，行业确实显得稳定得多(因人而异)。

      所以我想说的是：是的，这实际上有点回到正常状态。至少在我兴奋乐观的心情下是这样看的。

      我建议选择一个方向并坚持下去。它可能最终会成为脑中的过时知识，但我认为正是这层深厚的过时知识储备，才能让你成长为资深开发者。希望这个比喻不会太牵强！

      回复

      1. 我也感受到了GP今年早些时候表达的观点。我现在已经是个老手了。当我在21世纪初开始职业生涯时，一位老手告诉我：“技术每10年就会被完全取代。”这伴随着一个警告：在每个周期中，要么进化，要么死亡。

         这在很大程度上是正确的，除了像TCP这样的少数基本技术。

         我广泛尝试过 Claude 代码，我觉得它基本上是一样的。关于 GP 的观点，我的建议是深入研究使用 Claude 代码的项目，同时努力学习如何更好地构建代码。两者都要做。不要无所作为。

         回复

         1. 感谢你们两位，我觉得这些回复对我有些帮助。

            回复

   7. 这确实似乎是事实，而且合乎逻辑，更好的开发者能从Claude等模型中获得更好的结果。

      你注意到自己可能会错过宝贵的经验教训，这确实是正确的，而这可能让你在未来即使使用AI也无法获得更好的结果。不过，既然这是一个副项目，保持动力也同样重要。

      此外，如果你继续自己编码，你最终会通过未来的工作学到这些经验教训。但如果你更倾向于依赖辅助工具，那么你是否能掌握编码的原始技能就难以确定，这可能会影响你充分利用AI的能力。

      我曾在多种语言上做过大量工作，包括为各种游戏使用的gdscript和C#，我认为亲自完成工作能学到大量知识，而这样的机会在付费工作中并不常见。

      回复

   8. 没错，我完全同意你的观点。我从事专业编程工作已有大约25年，其中10年左右是在童年和青少年时期作为爱好进行的。我掌握了很多知识，但仍有许多未知领域。如果我的目标是学习一种新语言，我会不使用编码助手来构建整个项目。最多我可能会使用 Claude(不是 Code)来提出有针对性的问题，然后使用这些答案来编写自己的代码(而不是从 Claude 复制/粘贴任何内容)。

      我经常使用 Claude Code 来编写一些我知道如何编写但又不想编写的东西，因为这既繁琐又有些麻烦(我从过去的经验中知道这一点)，而且我不想处理细节，直到 CC 给我一些我可以测试、审查和修改的输出结果。

      但有时，我承认，我真的不想深入学习。我开始了一个使用 Rust 作为后端的项目，但我也需要一个前端。大约 10 年前，我做过一些 React，但我的知识(至少是我记得的)已经过时了。所以有时我会让 Claude 构建一个页面的整个部分。我会让 Claude 逐步完成，并在每一步之后阅读代码，以便理解发生了什么。有时，我会告诉 Claude 我对这种方法不满意，要求他采取不同的做法。但从某种程度上来说，除了代码的功能性和可维护性之外，我并不太在意代码本身。

      我认为这样没问题！我们不需要学习一切，即使是实现目标所需的内容。我认为你可能会遇到的问题是，你可能资历太浅，无法分辨哪些是真正需要学习的内容，哪些是可以让其他工具“学习”的内容。

      我对当前这个时代真正担忧的一点是，公司可能会开始解雇初级工程师，认为(尽管这种想法是错误的)资深工程师配备了编程助手后，也能同样高效。这样初级工程师将失去正常积累经验的途径，而刚进入大学的年轻人也会对编程望而却步，因为作为初级工程师找工作很难。当这些资深工程师开始退休时，将无人接替他们的位置。当然，当前的公司管理层不会在意；他们早已赚取了数百万美元并退休了。所以……尽可能多地积累经验，突破瓶颈进入资深工程师领域。

      回复

   9. 你对 C# 和移植软件的经验有多重视？如果你对这个领域感兴趣，也许可以自己动手做。否则，我建议你使用 claude。

      回复

      1. 完全不同意，我建议家长故意深入研究这类事情。

         职业生涯中提升技能的最佳方式是接触尽可能广泛的语言、技术、范式、概念等。所以，你可能再也不会碰C#了。但通过花时间深入研究，你会学到一些新想法，这些想法可以应用到你以后真正关心的其他事情上。

         回复

         1. 我同意这一点。GP应该花时间学习这些内容，并利用AI辅助学习而非直接实现。

            如果软件工程领域(SWE)要为初级人员留出空间，那很可能只会给予那些对某种语言的行为有相当程度理解的人。

            我推测他们在这方面的能力将远超以往的初级人员(因为他们必须具备更强的能力才能在AI应用上超越其他候选人)。

            但仍会有许多资深人士要求具备语法能力，而且说句公道话，如果你连自己的代码都读不懂(即使是慢慢读)，你就失败了人工智能加速开发中最关键的一环——验证。

            回复

   10. 我认为你已经确定了一项应该由你来完成的任务。如果编写代码本身能帮助你，那么不要让人工智能因为对“生产力”的模糊需求而剥夺你的帮助。我们都需要花时间提升自己的专业技能，而人工智能在某些方面是无法替代你的。

       但我确实认为它可以提供帮助，例如在你遇到困难或完成初稿后，向你展示更好的模式、语言或库功能。这并不是作弊，而是向朋友求助。

       回复

   11. 对于这样的事情，我会让 claude code 审查项目，并为其创建设计和架构文档。

       然后，我会让它制定一个计划，用 c# 重新创建该项目。

       接下来，我会让 claude code 按照计划文档中定义的小步骤，用 c# 生成一个新项目。

       然后，我会让 claude code 回顾其构建应用程序的经验，并用这些见解更新原始计划文档。

       然后扔掉第一个 c# 项目，再试一次。确保计划包括从测试开始。

       回复

   12. 让它生成代码。然后让另一个实例批评代码，并说明如何改进以及原因。然后向这个实例询问你不知道或不理解的事情。询问链接。阅读链接。做笔记。内化。

       有一天，我与 Claude 就一些 Ruby 核心方法发生争执，它不同意我的看法，于是我去查看了实际文档。它是对的。我从 2009 年开始使用 Ruby。

       回复

   13. 作为一个从事计算机编程近 30 年、专业编程约 20 年的程序员，我当然会手动完成一些工作，但也会利用大语言模型(LLMs) 的导师/教练模式，在遇到困难时发出“解释这个问题，但不要为我解决”的提示。一旦你确信某些部分确实很无聊，就让工具来转换这些部分。

       编程需要经验来培养对什么是正确的、什么是错误的、什么是不好的以及什么会给你带来麻烦的判断力，但你可以暂时(是的)不关心这些。如果你让工具为你做一切，你就永远不会获得这种技能，而判断和审查自己和他人的工作，包括大语言模型(LLM)的错误，是非常重要的。

       我同意这很难，但我很幸运，因为我从未需要在大语言模型(LLM)和手工劳动之间做出选择。如今，这是学习这门手艺的又一步，但对于初学者来说，时机不对——现在，人们期望你从第一天起就做高级工作(代码审查)。太难了！

       回复

   14. 使用 Claude 代码编写可能的初始迭代，然后回头审查代码以理解其含义，这有什么不好呢？各种语言和框架都有自己的缺陷，但这些缺陷通常可以在以后修复。

       回复

       1. 据我所知，从零开始构建东西比审查别人的代码能学到更多东西。根据我的经验，除非你亲自构建代码、重构代码，或不得不深入调试以修复 bug，否则你真的无法建立起对代码工作原理的心理模型。

          回复

       2. 根据我的经验，确定要写什么比如何写更难，因此如果你从生成的代码开始，你就剥夺了自己学习的机会。

          回复

          1. 我认为这实际上有助于学习——与经验丰富的专家并肩工作，观察他们得出的结果。

             就像学习写作的最佳方式往往是大量阅读，无论是英语还是代码。当然，你也要亲自实践，但拥有大量示例作为参考会很有帮助。

             回复

   15. 根据我对 Claude Code 的使用经验，我不会将如此重要的任务交给他。

       我对它的质疑在于，它生成的代码看起来“不错”，乍一看似乎“正确”，有时甚至还能正常运行。但仔细一看，其实这是糟糕的代码，或者写了一些毫无意义的额外代码，或者破坏了应用程序的其他部分等等。

       因此，如果你对 C# 的了解不够，无法判断它生成的 C# 代码是否良好，那么你会遇到很多麻烦。

       回复

   16. Cursor 让我像编写脚本语言一样编写 C++ 代码。我不再需要与晦涩的错误信息作斗争，它们直接进入 Cursor，我要求它解决问题，然后从它的解决方案中了解我的错误是什么。

       回复

       1. 你真的可以用 Cursor 来编写 CPP 吗？你能描述一下你的设置吗？它比 copilot 或 windsurf 更好吗？

          回复

          1. 在 Cursor 中打开你的 C++ 项目。首先，要求它审查代码库，并告诉你代码库的功能，以便你了解它的强大之处。尝试要求它找到处理某些功能的代码部分。它一定会给你留下深刻的印象。

             继续在您喜欢的集成开发环境(IDE)中进行开发，例如Visual Studio。当您遇到第一个编译错误时，即使您已经理解了错误原因，也可以将其复制粘贴到Cursor中，让它帮助您分析错误原因并提出解决方案。让它尝试实现该解决方案，进行编译，并将任何进一步的错误反馈给它，以便审查和修复。最终您将成功编译。

             然后，在返回工作岗位撰写下一个任务之前，请 Cursor 提出如何完成该任务的建议。在审查建议后，告诉它继续实施，或者提出调整或更好的替代方案。对于复杂的任务，尝试将模型手动设置为 o3，然后重新运行相同的提示，您会发现它的思维能力更强，能够一击解决复杂的错误。我通常使用自动模式，如果在更复杂的任务中失败，我会重新提交原始查询并设置为o3。如果o3也失败，可能需要手动收集更多上下文，并一步步引导其完成推理过程。这部分内容将在未来的文章中详细讨论。

             更高级：创建一个 build.bat 脚本，Cursor 在执行代码并查看自己的错误后可以运行该脚本，这样您就可以避免复制粘贴的往返操作。(查看 Cursor 规则，但规则提示为“在执行任何重大代码更改后，请运行 .build.bat 并审查和修复任何进一步的错误”)。这种简单的效率应该能让你体验到 Cursor 背后的真正生产力，你不再需要花时间做那些重复且耗时的步骤，浪费时间，你可以从更高的自然语言水平开始操作，真正感受到“流畅感”。

             打字编写代码只是令人讨厌的实现细节。您可能会感到“能力从指尖流失”，正如 DHH 所说，但我认为您会感到自己充满了动力。

             回复

   17. 做简单的事情能让您掌握大语言模型(LLM)无法完成的更难的事情，这无疑让事情变得非常困难。

       回复

   18. GDScript在Godot中真的比C#效率更低吗？

       你遇到了哪些瓶颈？

       我是一名熟悉Python(类似GDScript)和C#的开发者，但刚接触Godot并从GDScript开始学习。

       回复

       1. 这真的取决于你在Gdscript中实现了多少实际逻辑。不过它确实很慢，甚至比Python还慢，据我所知。所以如果你在做超越简单引擎调用组合的事情(比如编写复杂的敌人逻辑)，很容易遇到性能问题。“官方”的解决方法是为耗时的部分创建gdextensions，但到了那个阶段，你可能干脆直接用C#实现一切(我个人认为)。

          很容易说服自己代码足够快，但游戏会很快遇到性能瓶颈，而且这也会让你的作品对硬件配置不高的用户不可用。

          回复

   19. 这取决于你的使用方式。你可以要求 Claude Code 提供迁移代码的说明，它会像老师一样指导你。或者，你可以要求它创建迁移计划并执行，但在这种情况下，学习效果当然会非常有限。我建议尽可能分小步进行转换。我们曾为了好玩尝试一次性迁移一个项目，结果 Claude Code 惨败(它自己却认为做得非常出色)，但分小块进行却效果不错。

       回复

6. 作为一直尝试代理编码但并不喜欢它的少数好奇者之一，我一直在寻找我的体验与主流不同的原因。我认为原因可能在于以下几点：

       > 我认为，有了 Claude Code，我们正处于
       > 编程的“摄影引入”时期。
       > 当一个单一的概念可以出现，
       > 您可以通过代码审查和编辑技能将其
       > 塑造成您想要的东西时，手绘
       > 就不再具有同样的吸引力了。
       > 
   

   这种比较似乎恰当，然而，人们仍然绘画，仍然为绘画付费，仍然为了乐趣而绘画。

   我喜欢手动编码。我讨厌代码审查(尽管我当然会做)。如果让我选择，我会选择前者(也许这就是我仍然是IC的原因)。

   当人们将编码代理描述为非常热情但非常初级的工程实习生时，这让我感到恐惧而非喜悦。

   回复

   1. > 人们仍然绘画，人们仍然为绘画付费

      但在什么环境下？在我看来，大多数被流水线取代的手工艺，更多是出于一种体验——创作者和消费者都能参与其中，至少在想象中是如此。

      你不会在亚马逊上匿名订购这样的艺术品；你会与匠人及其创作过程建立某种联系。你会成为一个故事的一部分。如果编程想要占据这个细分市场，它也需要类似的东西。

      回复

      1. 我并不反对这些观点。但只要还有公司愿意付钱让我用传统方式编写代码，我就会继续这样做。

         回复

   2. 我认为这并不是一个完全恰当的类比。过去，绘画是唯一能够描绘现实世界事件的方式，但绘画本身也是艺术，它并不一定总是描绘现实，而是艺术家对现实的诠释。这就是为什么人们仍然绘画。

      所以，如果你把编程视为一种艺术形式，你仍然可以继续这样做。只是用它来赚很多钱可能有点困难。但大多数人编程是为了制作产品(这本身也可能是一种艺术形式)。如果借助人工智能能更快地实现制作产品的目标，那么选择当然很简单。

      但说实话，我也有点难过，因为“代码猴子”这个角色将消失，我们都将变得更像那位不再亲自编程、只负责指导项目、审查代码和做出技术决策的首席开发者。我喜欢当“代码猴子”的日子，不用处理太多商业事务。但你知道的，事情总在变化。

      回复

   3. 我完全理解这一点。我看到代理式编程在处理小任务、 minor 修复或初稿时的优势。不过，我无法理解围绕特定接口的伪部落主义，这些接口本质上只是底层的几个模型，我担心这会对初级开发者产生什么影响(或没有影响)。

      此外，如果人工智能工具能可靠地为我们进行代码审查，我将是一个更快乐的开发者。

      回复

   4. 更贴切的比喻是从手动工具转向电动工具。

      绘画/摄影的比喻在我看来牵强附会——摄影本质上是一种新的输出格式、新的媒介、全新的流程。代理式编程并非如此。

      回复

7. 我使用 claude code 编程已经大约 3 周了，我非常喜欢它。我拥有 10 年的工作经验，主要从事 Python ML / 数据工程工作。以下是我喜欢它的几个原因：

   1. 它消除了开始时的痛苦。我写文字没有障碍，但写第一行代码却有障碍，很大程度上是因为需要记住上下文、从哪里导入什么、设置模板等。

   1. 在它运行时，我可以利用我的脑力来思考我在做什么。

   2. 我现在可以同时做多件事。

   4. 它使“多走一步”变得更容易(我不再在代码中添加“待办事项”，而是为它启动一个新的 Claude)。

   5. 我可以进行更多的分析(比如启动详细的绘图/分析脚本)。

   6. 它可以自动为我修复大多数简单的 linting/typing/简单测试错误。

   总体而言，这种编码方式让我能够专注于核心问题：我应该做什么？输出是否正确？我们还能做些什么来改进它？

   回复

   1. 克服开始的困难是关键。它让我能够完成那些原本只会出现在“如果我有时间”愿望清单上的事情。

      现在，在提示符之间，我突发奇想，想在终端中编写一个《纽约时报》连接游戏，三个提示符后就完成了：https://github.com/jleclanche/connections-tui

      回复

   2. > 4. 它使“多走一步”变得更容易(我不再在代码中添加“待办事项”，而是为它创建一个新的 Claude)。

      尤其是这一点。我从未在因资源有限而吝啬测试或技术债务的地方工作过。现在，你只需说你想拥有一个不错的测试套件，就能得到它。

      这会满足纯粹主义者吗？不会，但许多长期未采摘的中等果实现在可以自动采摘了。

      回复

      1. 我实际上已经尝试过重构 Claude 编写的测试(当我要求它只触碰测试文件时)。总体而言，我无法改进它们。通常，它们受到主代码中的架构或代码风格选择的限制。还有一些零星的风格问题。

         但大部分情况下，你只需付出与敷衍了事相同的努力，就能获得绝对顶尖的测试质量。

         如果你使用优质的测试工具(变异测试是我的最爱)，效果会更进一步——这已超出我认为人类测试的合理范围，除非你正在开发涉及生命安全的关键系统。

         回复

8. 我看到这里有很多评论对CC赞不绝口，但我用过之后真的不明白。我发现向它解释我需要做什么所花的时间，和自己动手做的时间一样长。

   回复

   1. 现在的情况是，我们正在遭受全方位的营销轰炸。这些热情洋溢的评论与过去的推荐信和广告无异。

      回复

      1. 认为赞扬 Claude 代码的人都是受雇的营销人员/托儿，这是完全疯狂的想法。

         实际上，正在形成一种分化：一部分工程师懂得如何使用它，而另一部分工程师则不懂得，或者试图说服自己认为它毫无用处，诸如此类。

         第二组在未来几个月里将难以应对。

         回复

         1. 我不再相信我在网上看到的一切了。贿赂无处不在，人们为了获得点赞和免费的大语言模型(LLM)积分，乐此不疲地出卖自己的职业灵魂。

            更深层次的是：公开依赖大语言模型(LLMs)进行编码的人群很可能首先被大语言模型(LLMs)取代，因为他们已经找到了组织需要取代他们的方法。

            更广泛地说，我们生活在一个营销对获得关注至关重要的时代，仅凭出色的工作是不够的，人们可以利用这个完美的机会来推销自己，从而脱离劳动力市场。

            回复

         2. 我认为现在有很多有用的愚蠢的随波逐流现象。大语言模型(LLMs)显然令人印象深刻，没有人想成为 90 年代那个说“啊，互联网只是个潮流”的人，所以每个人都过度纠正，试图表现得像 80 年代那个说“相信我，兄弟，互联网会大有可为！快加入吧！”的人。

            但互联网花了数十年时间才让人们接受并学会如何使用。在某些方面，我们仍在摸索如何使用它。这并不是说人们应该忽视大语言模型(LLMs)，但让我们不要再谈“第二组在未来几个月不会表现良好”这种无稽之谈了。如果有的话，第一组的风险更高，因为他们依赖他人来设定趋势，然后告诉其他人要追上。

            回复

         3. 还有一群工程师喜欢……搞技术？我真的很享受自己写代码，这让我感到愉悦。我学习与机器对话的原因是，我不喜欢与人交谈，所以也不想把机器当作人类来对话。

            回复

            1. 你仍然可以两者兼顾。只是所有繁重的工作不再是繁重的工作，你一直拖延的技术债务不再是问题，你一直想尝试但没有时间的创意突然可以在一个下午探索，等等。

               对于新功能，当然可以手动编码。也许这是最好的选择！但代码库远不止新功能。这是一项无价的工具。

               回复

            2. 如果你看不出来这如何符合GP评论中的“组2”，尽管它并未被明确提及，那么我们可能已经找到了你为何不觉得代理式编码有趣的原因。

               回复

         4. > 组2在未来几个月内将难以应对。

            如果只是几个月的时间，那么后来者也能在几个月内赶上，这其实并不是很长的时间。

            回复

         5. 还有一些人使用不太流行的编程语言、不太流行的操作系统或不太流行的框架进行编程。

            回复

         6. 我不同意。鉴于投入人工智能的资金如此之多，以及赞誉的语气，我认为很可能存在一些大规模的虚假宣传活动。不幸的是，当前一代人识别虚假信息的能力要差得多。

            回复

   2. 你需要给它一些你认为它无法完成的任务。我认为这就是它开始理解的地方。

      回复

      1. 我经常给它一些我认为它能完成的任务，结果它搞砸了。我不明白给它一些我认为它无法完成的任务有什么帮助。

         回复

      2. 这是一个好主意。另一方面，我的结果却喜忧参半，Claude 代码很容易说服自己循环重试失败的想法。

         回复

9. 我尝试大量使用 Claude 代码，但我对它的速度慢和总是出错感到非常沮丧。在大多数任务中，它似乎并没有为我节省任何脑力。我确实对某些事情倾向于使用它。但有时我会因此感到厌烦，这并不愉快。

   例如，上周我决定玩玩 nushell，我有一个比较简单的 .zshrc，所以我把它交给 claude，要求它转换成 nushell。它生成的 nu 大部分甚至都不合法，我花了 30 分钟尝试，但始终无法正常工作。后来我花了大约 10 分钟查阅文档才完成转换。

   正是这种糟糕的体验让我不想再碰它，因为我可能还会再次遇到类似问题。虽然我确实发现了一些有价值的功能，但它的表现太过不稳定，让我觉得不值得花时间去尝试。

   回复

   1. 你试过 context7 MCP 吗？对于非主流的东西(比如 Javascript、Typescript 的流行度)，大语言模型(LLM) 可能难以应对。我通常使用 context7 之类的工具，它可以提供更相关、更及时的例子，效果更好。

      回复

      1. 我只使用2台MCP服务器，分别是context7和perplexity。对于更新文档之类的事情，我会让它询问context7。对于那些我认为它可能会遇到困难的复杂技术任务，我会指示Claude Code询问perplexity，这通常能解决问题。或者至少会在我们的对话中浮现出来，这样我们都能在那个时刻学到新东西。

         对于我正在开发的某些新项目，我使用Rails 8。我还将Railway作为我的主机服务，虽然它不像Heroku这样的服务那样广泛使用。Rails 8于11月刚刚发布，因此可用的培训数据非常有限。而且，人们需要时间进行升级， gems需要跟上，讨论需要浮出水面等等。如果没有这两个 MCP 服务器，Claude Code 通常会在更复杂或更细微的任务上反复出错。它擅长设置初始应用程序，但当我开始接触 Turbo/Stimulus 等内容时，尤其是对于条件显示的 UI 部分，它真的非常吃力。

         现在情况好多了——虽然还不够完美，但比完全依赖训练数据或搜索网络要好得多。

         我只使用 Claude Code 大约 4 周，但学到了很多东西。我感觉自己不再像是一个做这项工作的 IC，我的新工作是 (1) 产品经理，撰写清晰的 PRD 并与 Claude Code 合作进行构建；(2) PR 审查员，查看结果并提供大量指导；(3) 测试人员。我将时间分配为50%/20%/30%分别用于这三项工作。

         回复

         1. 谢谢，我会去看看Perplexity。我们似乎使用了类似的技术栈。我也在使用Rails 8、Stimulus、Hotwire、esbuild和Tailwind。

            Playwright MCP在前端工作中帮了大忙。它可以在调试 UI 问题时为代理提供更快的反馈。它还可以处理响应式设计，因此您可以测试桌面和移动视图。不知道您是否知道，Claude Code 还可以处理屏幕截图。在某些情况下，我会提供一些屏幕截图，代理会使用 Playwright 来验证输出是否接近像素完美。对我来说，它非常宝贵，如果您还没有尝试过，绝对值得一试。

            回复

            1. 我直到几天后才意识到截图功能可用，这真是个重大发现。最近还了解到，你可以直接使用 Ctrl+V 粘贴复制的截图(而非 Mac 上的 Cmd+V)。

               回复

   2. 这就是我使用它的基本体验。我原本以为它很适合编写测试，但每次无论如何引导，最终还是得自己重新编写整个内容。请求它协助调试也尚未给我带来良好结果。

      对于极简单的任务，它确实有用。当我懒得亲手处理时，会让它将命令输出解析为 JSON 或 CSV，或搭建一个空项目(但这种情况有多常见呢？)。我还发现它擅长将简单代码从 Python 迁移到 JavaScript，或从 TypeScript 迁移到 Go。

      但对我来说，负面体验远多于正面体验。

      回复

10. 我非常赞同作者关于维护的想法。我遇到过许多情况，本来应该写一个 TODO 或创建一个票证来记录一些重构，但我却用 Claude 直接完成了这些工作。我还用 Claude 快速尝试过一个重构想法，但因为不喜欢结果而放弃了。它确实降低了此类维护工作的启动能量。

    让 Claude 休息也是文章中的一个重要观点。与我的投入相比，我轻松获得了多倍的价值，因此我没有让它同时处理许多事情，也没有让它离线运行。我认为，如果你不谨慎，它可能会迅速成为导致倦怠和杂乱的加速器，因此我坚持采用人工监督模式。

    几周前我在https://www.modulecollective.com/posts/agent-assisted-coding…上写了一些更多想法。

    回复

11. 让我们停止称它为Vibe Coding。

    我是 Claude Code 的重度用户，我把它当作编码助手来使用。

    你在现实生活中管理开发团队的能力与从基于大语言模型(LLM)的编码助手中获得多少价值有着很强的相关性。

    如果你无法描述成功是什么样子，期望别人能读懂你的心思，并对验证性问题感到愤怒，那么你就会在编码助手和领导开发团队方面遇到问题。

    回复

    1. 那么，究竟什么是“Vibe Coding”？如果你在审查、理解并测试编码助手输出的所有内容，那么你并不是在进行“Vibe Coding”。

       如果你只是让编码助手自由发挥，不加批判地接受其结果并直接提交，那么你就是在进行“Vibe Coding”。

       听起来你不是在进行“氛围编码”。这很好。没有必要抛弃一个描述使用大语言模型(LLM)的一种特定(糟糕)方式的有用术语(即使这是一个听起来很奇怪的Z世代术语)。

       回复

       1. 是的，也许你是对的。

          我可能忽略了(其他人也可能忽略了)的一点是，我们把“Vibe Coding”这个短语与“使用大型语言模型(LLM)来辅助编程”混为一谈，但这两者其实并不相同。

          或许批评Vibe Coding的人需要记住，所有使用LLM进行编程辅助的用户并不一定会后悔自己的选择。

          回复

    2. 说得好。涉及的技能实际上与编码有很大不同。它关乎你能否清晰准确地描述事物，以及你有多擅长理解需要构建哪些工具来提升你的体验。这是不同的技能组合。

       回复

       1. 我认为对于当前一代模型来说，情况并非如此。你甚至可以为大语言模型(LLM)编写伪代码，将其转换为真正的语言，而根据我的经验，对于任何非标准的情况，它都会完全无视你的指示。一个具备基本能力的初级员工至少知道，如果列出了 5 个步骤，而他们只完成了 3 个，那么可能存在问题。

          提示大语言模型(LLM)与实际编码是完全不同的技能，但仅仅“更好地描述它”还不够。

          回复

          1. 我认为这还不够好，而且也不太相关。

             我的提示越来越少了。更重要的是钩子和子代理，以及工具的使用。

             这是一个关于克劳德代码的帖子。其他大语言模型(LLMs)并不重要。克劳德代码中没有任何东西会公然无视我的指令。这是过去的事情了。

             当然，不使用克劳德代码，这是肯定的。但我的所有指令都按照我的设置执行。对我个人而言，这真的不再是一个问题了。

             回复

             1. 你的经历与我在一些非常琐碎的任务上的经历相吻合，但我还没有将它应用到我工作中真正耗时的部分。对于某些任务来说，它非常不可靠，以至于我将其改造成筛选问题，用来筛选那些不了解基础知识却想靠人工智能蒙混过关的应聘者。即使使用克劳德代码，你的经历真的不是这样吗？

                回复

                1. 没错，直到上周末我才通过子代理、直接对比测试子代理、选择最佳方案并重复这一流程，让AI在实际耗时的工作环节中发挥作用。

                   上周末我做的就是让不同想法相互对抗，选择最成功的那个，然后重复这个过程。

                   现在，我的经历已经不同了。在上周末之前，我也有和你描述的同样的经历。

                   回复

             2. 你对子代理的体验如何？它真的能提升输出质量吗？

                你是使用这里建议的 https://docs.anthropic.com/en/docs/claude-code/sub-agents 还是创建了自定义的？

                回复

                1. 建议的代理非常糟糕，指导也非常糟糕。

                   上周末我对各种代理进行了直接对比测试，选出了最佳方案，并再次验证。这让我建立了一个非常具体的子代理系统，并且有一个代理专门负责创建这些子代理。

                   回复

12. 我感谢Orta在这里链接了我的“全维度开发者”帖子，原因有二：

    1. 我自恋，别人链接我的内容能填补我破碎灵魂的空虚

    2. 他确实付出了大量努力，以具体方式记录了这些工具如何帮助开发者提升抽象层次。质量、范围、时间一直是铁三角。这项创新如此加速，以至于雄心勃勃的程序员现在可以想象在不牺牲质量且时间不变的情况下，实现范围的颠覆性增长。

    对于我们当前所处的这个特定时刻，我认为这篇帖子将作为一个很好的记录，展现当时的感受。

    回复

    1. 谢谢，你的帖子一针见血，我甚至删掉了大约三分之一的笔记！

       回复

13. 到目前为止，我注意到 Claude Code 带来的不是“生产力提高”，而是“思考能力提高”。

    前者被炒得沸沸扬扬，但后者——停下来提出问题、思考、思考我们应该做什么——才是真正强大的。我发现自己比在周末匆忙完成一些后来让我后悔的事情时更善于思考、进行更深入的研究、提出更深刻的问题。

    回复

    1. 同意。我认为Vibecoding最独特之处不在于它能按下所有键盘按键。虽然这能节省大量时间，但它并不能让你的代码“更好”，因为它缺乏判断力。但它能以远超你想象的速度，提出远超你想象的更多可能性。我喜欢说：“这就是我需要做的事情，给我展示三到五种实现方式的代码片段，权衡利弊。”然后你选择其中一种并继续。不再是先尝试第一个想到的方案，写完后发现它很糟糕，然后又回到起点。

       我也用这个来处理遗留代码。“第n行到第n+10行感觉不对劲，但我不知道为什么，也不知道该如何修复。”Gemini在猜测我直觉上感到不安的地方并提出解决方案方面表现不错。然后它就直接解决了问题。任务完成。

       回复

14. 同意。CC 让你尝试一些你原本不敢尝试的事情。例如，以下是我最近在 CC 的帮助下添加到 Langroid 大语言模型 (LLM) 代理框架中的两件事：

    代理对话的可折叠 HTML 日志(受 Mario Zechner 的 Claude-trace 启发)，这花了我几个小时的时间进行迭代，涉及 HTML/js/CSS：

    https://langroid.github.io/langroid/notes/html-logger/

    从Pydantic-v1迁移到v2，大约花了7个小时的迭代(如果我尝试手动操作，至少需要一周时间，而且可能仍然不够稳固)：

    https://github.com/langroid/langroid/releases/tag/0.59.0-b3

    回复

15. 我并非怀疑论者，而是发现自己对我们用这些工具(我承认自己使用频繁)构建的世界深恶痛绝。

    回复

    1. 为什么特别厌恶呢？

       回复

       1. 这个答案可以，而且肯定会填满许多书籍、论文、博士论文等。

          我不想谈得太哲学，尽管这样做并非没有道理，我只想专注于我自己的小领域(软件工程)：这些大语言模型(LLM)的发展大多扼杀了思考的重要部分，最终可能会让我变得更愚蠢。例如，我知道什么是B树，并且可以(曾经可以)在需要时费力地实现一个，这个过程会很长，充满错误和学习。现在，仅仅有一个大致的了解就足够了，而且大多数人永远不会有机会自己去做。B树是一个故意人为的例子，但你可以将其外推到更实际或现实的例子。在更直接的层面上，还有对生计的威胁。我未来可预见的时期内有大量开支，如果我的工作领域平均生产力提升100倍甚至10倍，可能就会有更少的工作机会。就像农牛看着第一台内燃机拖拉机一样。

          我还能想到许多其他原因，但这些对我来说是最紧迫和个人的。

          回复

       2. 不是GP，但我们正陷入一个不断重复相同“内容”的世界。没有什么会是特别的，没有什么值得自豪的。只是我们的统治者不断给予我们多巴胺刺激。如果你还没读过《美丽新世界》，建议你读一读。

          回复

          1. > 如果你还没读过《美丽新世界》，建议你读一读。

             我读过，但我看不出来这与AI辅助编程有什么关联。

             如果你指的是“生成式AI的普遍性”，那么我认为这是目前在网上讨论AI时面临的问题。讨论很快就会变成“必须为AI的所有方面辩护，否则你就输了”。我无法预测人工智能的所有方面。我不喜欢人工智能的所有方面，我也无法同时权衡大量不同主题的利弊。(我怀疑其他人也做不到)

             回复

16. 我认为 Claude Code 可能是自 ChatGPT 以来最具变革性的软件。这是朝着人工智能代理迈出的一步，它能够以一种超越沙盒 ChatGPT 甚至只是驱动浏览器的方式，在基本层面上真正“行动”——执行计算机上任何可找到的命令。

    回复

17. 我希望我也能达到这样的生产力水平。我认为每篇文章都应该详细列出他们要求大语言模型(LLM)做些什么，因为我并没有从它那里获得太多收益，我不知道这是因为我的工作与网站前端和后端代码相比比较罕见，还是因为我对提示/上下文一窍不通，或者是我使用了错误的服务，或者没有正确的 MCP 等。

    回复

    1. 是否可以查看提示历史？我曾达到极高的生产力水平，很想在这样的文章中列出我的一般使用方式，但边做边记录会非常不切实际。

       回复

       1. 至少在 Claude Code 中，您所有的聊天记录都存储在计算机上的 ~/.claude 中的 jsonl 文件中——我制作了一个小 TUI 来浏览这些文件 https://github.com/orta/claude-code-to-adium。

          就个人而言，我并不认为跟踪提示对生产案例(我认为，如果人类应该阅读它，那么人类就应该撰写/完全编辑它，这适用于提交/PR/文档等)和提示更具临时性的氛围案例都有价值。

          回复

       2. 我真的很想记录我使用 claude 工作的现场评论。也许你可以考虑一下。

          我感觉我得到的结果在质量上远超我合作过的任何人产出的成果。速度快得惊人只是额外的惊喜。

          回复

       3. 直接展示你编写的代码。

          回复

          1. 没错，但这就像只展示编译后的二进制文件而不展示源代码一样。对于 claude 代码来说，提示和配置就是一切。

             回复

             1. 对我来说，这是整个事情中最令人遗憾的部分。你认为提示和配置是真正的源代码，但它们已经完全消失了。即使你保存了提示，也无法重现它们的效果。

                然后还有一个问题，其他开发者如何为代码做出贡献。他们没有你的提示，他们只有代码。

                所以，不，提示不是源代码，这就是为什么我要求人们只展示他们生成的代码，但没有人这样做。

                回复

                1. 我在GitHub上有仓库。我展示代码。

                   我还将设计文档(大致相当于提示词生成的提示词)转换为已提交的Markdown文档。因此至少展示了二级提示词，你可以将其视为中间语言表示形式。

                   > 那么，其他开发者如何为代码做出贡献呢？他们没有你的提示词，只有代码。

                   我通常会提交初始提示和调整。我不会提交诸如“这不太对，再试一次X”或“直接运行整个测试套件”之类的琐碎内容。

                   > 因此，提示并非源代码

                   强烈反对，但没关系。

                   回复

    2. 我发现，如果你在处理一个没有见过数十亿个示例的任务，你需要提供额外的信息，比如学术论文或类似内容。并且要让它定期总结其理解，这样你可以在另一个聊天中(当上下文变得太长时)无需再次解释就能接上话题，同时确保它没有偏离正轨……因为它们往往会这样做。

       它们对很多事情都了解很多，但细节在它们愚蠢的机器人大脑里都混在一起，所以你必须帮助它们。

       回复

18. 它似乎非常擅长编写测试、输出 UI 代码以及许多其他有大量实例的事情。

    我从事数据库优化器方面的工作，而 Claude 在这方面表现非常糟糕。它会生成错误的代码，无法找到正确的位置来挂接抽象层，忽视对代码其他部分的影响，并且自信地提出一些根本行不通的改动(姑且这么说吧)。

    你的实际体验可能有所不同……它似乎高度依赖于周围现有(开放)代码的数量。

    回复

19. 我最感兴趣的是这些工具如何应对复杂的遗留系统。

    我们有大量代码是在过去十年中开发的，其中包含各种编程惯例和风格规范，这些规范主要通过人工审查来强制执行。这在一定程度上与我们在受监管的环境中工作有关，我们知道某些类型的代码需要极高的透明度和可审计性，因此以开发人员通常的方式编写代码会带来问题。

    因此，我很好奇它能否很好地识别现有的代码风格，然后隐式地模仿这种风格？我目前对其他工具的测试表明，它们并不能很好地处理这个问题；通常情况下，我得到的代码与现有代码看起来非常不同。它体现了大语言模型(LLMs)真正的“回归平均值”精神，它为我提供了“普通合格工程师会如何编写这个代码”，但这完全不是我们需要编写的代码。

    目前，这是我们无法在代码库中使用这些工具的主要障碍。

    回复

    1. 您需要为代理工具提供足够的项目背景信息，以便它们能够找到自己的方向。在 Claude Code 中，这通常是通过代码库根目录下的 CLAUDE.md 文档来完成的。

       我在 Chromium 上工作，通过使用一份详细的背景文档(约 3000 字)，其中包含从软件架构和文件夹组织到 C++ 编码风格等各种相关信息，我的工作体验得到了极大的改善。

       (该文档的第一稿是由 Claude 根据项目文档自己创建的。

       回复

       1. 根据我的经验，通过 Claude.md 进行操作比在子代理上下文中进行操作要差得多。

          回复

    2. 我在 8 年前的多语言代码库中使用 Claude 非常幸运。但我确实需要照顾它，并提供大量上下文信息。

       我创建了一些教程文件，其中包含许多标准操作的方法。结果发现人类也觉得这些有用。通过这些示例，我发现Opus通常能很好地遵循现有惯例，而Sonnet则表现不佳。

       回复

    3. 最终这取决于该语言在Stack Overflow或公开GitHub仓库中出现的示例数量。否则，如果不是Python、C++、Rust或JavaScript，结果可能因人而异。

       回复

    4. 处理绿地项目仍然更容易，但一切都在改善，差距也在缩小。

       回复

20. 假期期间，我为孩子们制定了一个应用程序计划，首先是为我最大的儿子。这个计划发展成了数千字的规划文档(MVP、技术栈、布局)。那只是我躺在阳光下，用手机和克劳德一起做的事情。

    今天，我(虽然从事编程工作 20 多年，但主要从事统计工作，并不是程序员)开始使用 Claude Code via Pro 进行构建。大约 3 个小时就用完了我的积分。达到了 MVP(我高兴得流泪了)。实际上，这是我儿子给我最好的评价之一。他看起来像是在说：“哇，爸爸，这超出了我对你的预期。

    提示：

    – 提前计划！Claude 告诉我，一个请求更适合放在路线图上。我的路线图管理着我。

    – 强制 Claude 构建测试套件，并在各个地方(后端、前端)提供调试信息。

    – Claude 和我一起制定明确的待办事项。他和我一样需要指导。它忘记了我 MVP 的一个非常重要的功能。尚不清楚原因。我礼貌地提出要求，它就构建了。

    问题(并非专门问你们这些亲切的 HN 朋友，尽管欢迎提供建议)：

    – 为什么我在 3 小时内就用完了我的积分？

    – 如何迫使 Claude 坚持执行我的计划、我的 CLAUDE.md 等？

    – 有办法让 Claude 检查整个项目的一致性吗？或者我应该接受振动会留下碎屑吗？

    回复

    1. 我使用的是专业计划，也在 2 小时内遇到了限制，然后必须等待 5 小时窗口的限制重置(下一次重置是在凌晨 2 点，还有 1 小时 40 分钟)…

       你可以要求 Claude 审查你的代码，写下标准，验证代码是否按照标准和准则生成。如果发现项目不一致，要求它制定计划并执行计划。

       问、问、问。

       回复

    2. 用完你的积分是正常的。我们正处于“哈哈免费钱”/“垄断市场”阶段，Anthropic 以亏损的价格提供 Claude 代码。

       最近他们不得不降低代币配额，因为他们正在大量流失资金。

       你可以运行“ccusage”在后台监控，这样你就不会太惊讶，这就是我能说的。

       趁现在还能享受低成本推理，除非有人破解了效率难题，否则前沿模型可能会在某个时候变得非常昂贵。

       回复

       1. 是的，说实话，在谷歌工作，可以无限使用 Gemini 确实很不错(即使它与 Claude Code 相比存在性能问题……但我不能说，因为我不能在工作中使用它)。

          回复

21. 我在技术领域有近 20 年的经验，我的大部分职业生涯都在编写玩具脚本或婴儿自动化程序。我最初在托管服务支持部门工作，并沿着这条路在不同IT领域间穿梭。

    我每天主要负责管理SaaS工具，而我最大的困扰始终是缺乏足够知识来为正在使用的工具开发优质插件或扩展，且能找到的优质文档或开源示例也极为有限。由于时间有限(全职工作)和随之而来的挑战(多动症和自闭症，以及作为黑人、胖子和同性恋者所遭受的各种痛苦)，我因害怕失败而难以开始任何事情，或者我开始学习一门课程，但因为没有做任何能激发我的想象力和动力的事情而感到厌烦。

    Claude Code、Cursor 甚至 Claude 应用程序等工具彻底改变了我的生活。我学到了比以往更多的知识，因为即使这些工具编写的代码很糟糕，也是调试和探索的机会，但我有可以反复尝试的具体东西。此外，我发现 Claude 非常擅长根据我的想法给我上课和学习，然后我可以使用与我的工作直接相关的源文档和教程进行有针对性的学习，而不必面对选择困难症。能够在几秒钟内构建出我想要修复的故障代码(当前的问题比未来的问题要令人满意得多)，并且拥有一个比我更了解代码的工具，但它从不厌倦我愚蠢的问题或奇怪的比喻，这对我构建自己的工具非常有帮助。现在，我首先考虑构建自己的东西，而不是直接购买现成的解决方案！

    回复

    1. 我患有注意力缺陷多动症，Claude code 也彻底改变了我的生活。我不再因文档循环而分心，不再因决策瘫痪而苦恼，也不再忘记自己正在做什么或接下来需要做什么。我几乎像与 Claude code 合二为一了。

       回复

       1. 说得好。我实际上在编码方面变得更好，因为我读了更多的代码。

          回复

    2. 未使用Claude代码，而是利用大型语言模型(LLMs)通过Harmony库等工具对已编译的供应商代码中的C#函数进行补丁修复。

       能够覆盖一些供应商固化的硬编码内容非常有用。

       回复

22. 有人有过 Claude 或类似 AI 代理在大型(100 万行以上)旧代码库中的表现的经验吗？为了更清楚地说明情况，我正在处理一个已有 20 多年历史的 Java 代码库。它一直在不断更新和扩展，但大部分都是意大利面代码。Claude 能在这种情况下带来任何价值吗？

    回复

23. 好文章，但就我个人而言，我认为GraphQL对90%的Web开发项目来说是个祸害。它过度复杂化、臃肿，且在通常仅涉及CRUD资源操作的情况下，并未在常规OpenAPI规范基础上增添任何价值。

    回复

    1. 你懂就懂，不懂就算了！但如果你懂了……

       回复

24. 它真的比 Cursor 的代理好得多吗？我犹豫是否要尝试，因为这需要花钱，而 Cursor 是免费的(工作)。如果两者都使用 Sonnet，那么它们之间到底有什么区别，我很难理解。

    回复

    1. 是的，好得多。Cursor 为令牌付费，而你向 Cursor 付费，因此，尽量减少向 Claude 发送的上下文和请求数量符合他们的最佳利益。

       回复

25. 有人对 Gemini CLI 有类似的良好体验吗？我只是一个业余程序员，因此，当 Gemini 是免费的(至少目前是这样)时，为 Claude 付费感觉有些愚蠢，但到目前为止，我只在 Cline 类型的扩展中使用过它。

    回复

    1. 我两者都用过。Claude 用得更多一些。Gemini 也给我带来了很好的效果，但似乎更容易陷入循环。Claude 也会出现这种情况，但频率较低。

       所谓循环，是指你告诉它不要实施这个服务，而是查看这个文件并模仿它，但它却照旧做了之前的事情。

       回复

       1. 我经常遇到 Claude Code 陷入循环的情况，它无法识别 Typescript 类型，并使用不安全的 `as` 权宜之计，即使 CLAUDE.md 告诉它不要这样做。几条提示后，如果它在同一区域遇到任何错误，它会再次删除类型安全的代码，并用 `as` 代替。

          我的观察结果是：如果你将当前的大语言模型(LLM)推到其能力极限，它就会“发疯”。幻觉开始无处不在，它不再忽略先前的知识等。最好的办法是结束会话，也许做些手动工作以达到良好的状态，也许更新规格，然后从新的上下文开始。使用“强烈的词语”或发出更多提示是没有意义的，大语言模型(LLM)在重置之前基本上只会产生胡言乱语。有时，使用更昂贵的模型可以暂时绕过触发愚蠢行为的因素。

          回复

26. 对我来说，感觉我们正处于 VC 补贴 Claude Code 等工具的时代。考虑到 GPU 使用成本高昂且不太可能下降，而且这些公司最终需要盈利，我怀疑我们是否正在走向一个最终 Claude Code 等工具每月费用从 200 美元涨到 2000 美元的境地。

    回复

27. 在单人开发环境中，能够快速进行大规模重构确实很有帮助，但在团队中，这会给团队成员带来大量的代码审查(和质量保证)负担。这让我思考，我们是否正在走向一种团队模式，即个人负责系统中的不同部分，而不是每个人都审查彼此的代码并共同合作。

    回复

28. 也许我只是使用不当，但CC对我来说并没有特别有用。我认为它还没有修复过我的任何 bug。但我喜欢它的命令行界面

    回复

29. 对我来说，真正的限制是我在一天内能够阅读并清晰理解的代码量，以发现问题。

    回复

30. 另一个非常好的用例是构建非常复杂的测试工具。通常情况下，公司可能不会为这样的任务分配足够的资源，但有了 Claude Code，这完全不是问题。还可以创建非常复杂的模拟，比如 db mock，它可以解析代码库中的所有查询，并将它们应用到内存中的假表中。如果手工构建和维护，这会非常痛苦，但有了 Claude Code，只需几分钟就能完成。

    回复

    1. 我愿意为之奋斗(比喻意义上)：

       如果你的测试结构难以交互，这通常意味着项目架构中存在某些不良决策。

       回复

       1. 当然，但这与上述内容基本无关。假设需要为一种领域特定的查询语言创建解析器+映射器，该语言随后会被映射到多个SQL后端。我使用CC创建了自定义测试框架，该框架可通过SQLC风格的文件驱动测试。与纯Rust测试相比，这些测试文件可读性更高且维护起来容易得多。使用CC创建仅需半天时间，而不用CC可能需要一周。

          回复

    2. 根据我的经验，大语言模型(LLMs)在测试方面表现非常糟糕，所以对我来说，这是最糟糕的应用案例之一。

       回复

       1. 根据我的经验，它们非常适合测试工具。在实际测试中，当我已经覆盖了大量测试用例后，让它识别缺口和边界用例并提出测试建议是非常可行的，我大概会接受其中70%的建议。

          回复

       2. 在 JS 中，是的。它与良好的测试故事相结合，非常不错。

          回复

       3. 虽然人们对大语言模型(LLMs)的体验各不相同且主观，但说它们不擅长编写测试是不正确的。Claude Code 在编写测试和测试基础设施方面非常出色。

          回复

          1. 值得一提的是，应告知CC不要过度模拟，仅生成真正相关的测试。我使用一个代理来识别此类问题，因为之前曾遇到过一些真正糟糕的过度模拟非测试案例。

             回复

31. 手绘作品已不再具备同样的吸引力，因为只需一个概念就能呈现，而你可以通过代码审查和编辑技能将其塑造成你想要的形态。

    与此同时，业内最受期待的游戏之一——一款已获高度评价产品的续作——其艺术风格完全采用手绘完成。

    回复

    1. 我认为这是两种不同的思维方式，即最终产品与制作过程。似乎很多喜欢AI的人只关心最终产品，而不关心它是如何制作的。另一方面，有些人对制作过程本身感兴趣，认为创作和精炼的过程是最终产品的一部分。

       回复

       1. 我认为人们并不关注东西是如何制作的，只是觉得它更好、更美，更符合他们的需求。我同意人工智能爱好者只关心完成事情，但我不会称其为“最终产品”。

          回复

32. 作为 ChatGPT 用户，我对 Claude 的看法。

    感觉就像ChatGPT吃了可卡因，我的意思是，我只要求一个小改动，它却带来了5个解决方案，彻底改动了我的整个代码库。

    回复

    1. 是Sonnet还是Opus？我发现Sonnet只会做一些小改动，而Opus会进行大刀阔斧的改动。

       不过这可能因人而异，也许是我提示的方式不同。尝试使用计划模式，只进行微小的更改。

       回复

    2. 这是对 claude 代码还是 claude 模型的看法？

       回复

    3. 这是“哦，不，我意外地破坏了你的整个代码库，我太糟糕了，我接受惩罚，你永远不要再相信我了”的那种，还是另一种？

       我记得“哦，不，我太糟糕了”这个观点来自微软的程序员圈子？如果这种情绪如此明显，以至于大语言模型(LLMs)都默认了这种观点，那么对于程序员来说，这似乎是一个艰难的环境。

       回复

       1. 这听起来像双子座：https://www.reddit.com/r/cursor/comments/1m2hkoo/did_gemini_…

          回复

    4. 我不是说它是，但如果没有监管机构审查或开源，这可能正是按预期运行的，因为Anthropic从中赚取更多利润。

       回复

33. 使用两个不同的VS Code配置文件是一个超越AI的有趣想法。每次打开不同项目时，我都会感到困惑，因为代码看起来都一样。也许为每个项目设置不同的主题会更有意义。

    回复

34. 编码代理具有赋能作用，但人们尚未充分意识到它们正在设定新的基准。不久之后，作者所做的一切将不再被视为令人印象深刻，而是理所当然。而且你不会工作更少，而是同样的工时——或者更多，如果你不使用代理的话。

    尽管如此，我认为代理程序是一种非常受欢迎的新工具。

    回复

    1. 在代理程序的使用技能/经验方面，也会存在一个光谱。有些人能非常有效地使用它们，而其他人可能不太擅长。

       回复

35. 我认为 Claude 带来的最有趣的变化是让 AI 尝试各种事情。我们一直都在这样做。

    我感觉目前这在小型团队中效果最好，因为 Claude 希望产生代码更改和 PR。OP 工作的 Puzzmo 公司只有不到 5 名工程师。

    在大型代码库中，PR并不总是适合进行激进的AI探索。如果你想在会议前启动某个项目并看看如何解决它，可能更适合获得一个计划、一堆正则表达式，或是一份关心该问题的团队列表。

    让AI基于一个想法为大型项目生成详细计划，听起来非常令人惊叹。

    回复

36. Claude Code 使用的是与 Claude.ai 不同的模型吗？因为 Sonnet 4 和 Opus 4 经常给我带来错误的信息。它们都让我做无谓的努力，它们自信地声称我的代码“发生了 X 情况”，但实际上完全错误。它们还产生了 API 幻觉，总体而言，许多细节都错了。

    我正在探索的问题领域是libusb和Python，我使用了ChatGPT和Claude.ai来帮助调试一些问题并完善一些骨架代码。Claude的输出几乎完全错误。ChatGPT也犯了一些错误，但总体上更接近事实。

    人工智能最终可能会取代我们的工作，但不会是Claude.ai。

    回复

    1. 我敢肯定这是同一个模型。

       Claude 代码之所以“好”，是因为它可以运行测试、编译代码、运行代码检查器等。如果你真的关注它在做什么，至少根据我的经验，它会不断出错，但可以通过外部工具的反馈来纠正自己。最终它会宣布“完美！”(这让我非常恼火)，并输出看起来似乎满足你要求的代码。然后如果你忽略那些模拟所有有用行为的测试、数据访问模式中的业余错误以及安全漏洞，它简直令人惊叹！

       回复

       1. > 最终它会宣布“完美！”(这让我烦不胜烦)，

          这对我帮助很大：

            # 用户交互
            - 避免阿谀奉承。
            - 只做被要求的事情；不多不少。
            - 如果被要求进行更改，总结更改内容但不要解释其好处。
            - 表述要简洁，但不要到省略的地步。
          

          回复

       2. 你说得对，但实际上你可以通过子代理大幅改进它。一旦你习惯了使用子代理，它真的会带来很大的不同。

          回复

37. 由于重复性劳损和腕管综合征，我不再写那么多代码了，但 Claude 给我提供了一种无痛编程的方法(也许疼痛程度减少了一个数量级)。尽管我非常想拒绝它，但为了继续我的职业生涯，我确实需要它。

    回复

    1. 你不是第一个说这话的人。这些工具以一种被低估的方式改变了游戏规则。它们是对我们这些容易患上RSI的人的一份美好礼物，因为它们最擅长处理那些容易引起不适的重复性模板代码。过去，每次面对需要敲打的大段模板代码时，我都会感到有些恶心，既因为RSI，也因为这让我感到无聊。现在不再如此。人们担心这些工具会终结职业生涯，但(至少目前而言)我认为它们能拯救不少人的职业生涯。一个副作用是，我现在更享受编程了，因为我可以处于一个抽象层次，真正处理新问题，而不是让大脑陷入昏睡、手腕承受痛苦地敲打花括号或YAML模板。

       回复

    2. 现在你提到了这一点，自从我开始使用 Claude 以来，我的 RSI 疼痛几乎消失了。当 Claude 能够达到 90% 的准确率时，许多模板和重复性工作就消失了。

       尤其是非常精确的语言。我听说有人使用语音转文字来使用它，这打开了各种可访问性窗口。

       回复

    3. 我发现使用一个好的语音转文本/语音输入应用非常有效，因为给CC提供足够详细的上下文非常重要，而手动输入所有内容会变得非常繁琐。

       我尝试过几个语音输入应用，包括Super Whisper等，最终选择了Wispr Flow。我对免提语音输入模式的快捷键要求很高(即需要一个好的快捷键来切换录音开关)，当然，准确性和速度也是关键。目前Wispr Flow似乎能满足我的所有需求，但我很想切换到一个仅本地运行的应用并取消$15/月的订阅 🙂

       回复

    4. 很遗憾听到这个消息，虽然我的最初目标并不是为这样的用例提供服务，但我想知道，通过语音与 Claude Code 进行交互是否对您有帮助？在 MacOS 上，它使用免费的 TTS 和 ASR 默认设置，但您可以自带其他提供商。https://github.com/robdmac/talkito

       回复

    5. 您是否使用语音输入进行文本输入？

       回复

       1. 这是一个很好的建议！我将尝试一下 🙂

          回复

          1. Superwhisper 非常出色。不过它是闭源软件。目前可能已有其他可比的开源选项。我建议先尝试 Superwhisper，了解其功能后再与开源选项进行对比。Superwhisper 本地运行且提供一次性购买选项，这对我来说是可接受的。

             回复

             1. Talkito(我上面贴出了链接)是开源的，与 Superwhisper 不同的是，它还能让 Claude Code 与你对话——这是实现多任务处理的最初目标。

                回复

                1. Talkito 似乎只是云服务的界面 https://github.com/robdmac/talkito#provider-configuration ——这对于一个本身采用 AGPL 许可证的项目来说，对“开源”的定义实在过于狭窄。

                   回复

                   1. Talkito 确实支持所有流行的 TTS 和 ASR 云服务提供商，因此您可以使用自己的密钥。即使没有密钥，在 Mac 上它也可以使用系统默认的 TTS 和 Google 的免费 ASR 进行输入。

                      那么，好处是什么呢？对于 Claude Code 来说，这个包装器有效地连接了这些 TTS/ASR 系统和 CC，因此现在有了语音界面(CC 没有语音界面)。它不仅依赖 MCP(尽管它会启动一个 MCP 服务器进行配置)，而且直接注入 ASR，并在开启时直接读出 CC 的输出。

                      该工具免费且开源，用户可审查其代码以确保无恶意行为，同时他人也可选择贡献代码。其许可证条款符合论坛建议，可防止公司将您的工作成果用于商业服务。

                      回复

    6. 看看 https://talonvoice.com 吧！

       回复

38. 问题是，我能否解雇 100 名工程师中的 80 名，然后购买 Claude Code 订阅服务呢？

    回复

    1. 人们可能不会喜欢这个观点，但原帖的方向是正确的。

       在100人的开发团队规模下，你很可能有大量初级和中级开发人员，对于这些人来说，像CC这样的工具在短期到中期内会产生负面影响(主要是因为它会拖慢顶尖开发人员的速度，他们不得不处理CC快速产出的低质量代码，而初级/中级开发人员无法或不愿意处理这些问题)。你的顶级开发人员(大约占你员工总数的1/5)将带来CC这类工具80%的收益。

       自3月/4月以来，我们不再招聘初级甚至早期中级开发人员。如今他们每月成本为$200 + $X的API费用。开发人员的工作方式正在发生转变。这令人担忧，但确实正在发生。

       回复

39. 每次你滥用这些工具，例如我所说的“无头编程”(即依赖工具完成大部分工作)，都要明白你正在积累技术债务。这不仅体现在项目层面，还包括你本应通过学习掌握的解决方案实现能力。

    这就像在高中使用ChatGPT：它可以成为一位卓越的导师，也可能包办一切，最终让你变得更糟。

    从中得到的普遍教训是：结果并非一切。

    回复

40. 我尝试过几次，感觉自己为了可能30%的整体速度提升，正在付费成为更差的开发者。

    回复

41. 喜欢这些团队提升团队生产力而非仅个人效率的做法，这让制作原型变得更容易。

    当更多想法能推进到更远阶段，你就能获得更多机会。几乎可以肯定会取得更多成功！

    回复

42. 几年前SRE团队经历了自动化工具的普及阶段。现在SWE团队也开始获得类似工具。

    回复

43. 我不知道这是否只是我“感觉”到的，但作为一个从命令行开始学习使用计算机的 50 岁的人，使用 Claude Code 的 CLI 模式给我一种独特的满足感。

    回复

44. 对我来说，Claude Code 远胜于其他所有工具。这让我确信自己有一个盲点。

    有没有人使用 Claude 取得不错成绩，同时其他工具也取得过类似成功？

    回复

    1. 我已经切换到 opencode。我将其与 Sonnet 一起用于有针对性的重构任务，并与 Gemini 一起用于涉及大量文件的任务，否则这些任务会很快变得非常昂贵。

       回复

45. 作者使用 Claude Code 实现了很多事情，包括代码迁移和重构。对于两周前才开始使用 Claude Code 的我来说，这似乎是它目前真正的优势之一。我们有一个大型商业应用程序，它使用了一个废弃的组件库，包含许多无用的代码。迁移到另一个组件库似乎几乎是不可能的，但借助 Claude Code，整个过程只花了我大约一周的时间。它会犯一些错误(例如标签不匹配)，但在人工监督下，我们实现了第一个目标。下一个目标是尽可能地删除无用的代码，以便能够再次使用该应用程序，甚至再次享受编程的乐趣。

    我记得JetBrains曾通过IntelliJ IDEA的重构工具让编程变得轻松许多。对我来说(AI经验非常有限)，这似乎是类似的一步，但规模更大。

    回复

    1. 另一方面，像IntelliJ那样的自动化重构可以几乎无限扩展，成本极低，并且保证不会犯任何错误。

       我不是说这一定更有用，只是说不同的方法各有优缺点。

       回复

    2. 我今天第一次尝试使用Claude。我有一个庞大的PowerShell脚本，多年来不断演变，执行各种不同的任务。我一直打算重构它，但它已经变得如此复杂，每次尝试重构时，我都会很快放弃。GPT无法成功将其拆分为独立的模块。今天我试用了 Claude，它在大约 30 分钟内将脚本重构为一个结构清晰的模块集合。我印象非常深刻。

       回复

46. 啊，又一次试图推销“每月 200 美元是超值的！”的说法。真可悲。

    我明白。目前没有人真正赚到钱，包括OpenAI。

    随着风险投资资金枯竭，情况只会变得更糟。比如在回复中插入广告。

    this_variable_name_is_sponsored_by_coinbase 这种情况很糟糕。而这些自以为是的人会声称这没什么大不了的，因为只有失败者才会阅读代码。

    回复

    1. > 啊，又一次试图推销“每月 200 美元是便宜的！！！”的说法。

       好吧——与真正的开发人员(即使是初级开发人员)相比，这只是小钱。

       回复

47. 对我来说，大语言模型(LLMs) 最吸引人的用途是一次性脚本、小函数、单元测试等。

    我不明白人们如何有耐心去完成整个应用程序，全程都靠 vibe 编码。正如文章所暗示的，这甚至节省不了多少时间。

    如果不能通过简单的上下文一次性完成，我不想做。

    回复

    1. 我最近参加了一个公司黑客马拉松，我们被鼓励更多地探索 vibe 编码，而这基本上也是我的收获。它对于黑客马拉松来说非常适合，但将问题解决和心理模型构建交给大语言模型(LLM)，整天坐在那里写提示，真是令人感到非常无聊。如果这必须成为我的职业，我可能真的要改变职业道路了，但似乎不太可能——将它作为工具来帮助这里和那里，有时提供建议，这绝对是一种真正使用它来获得更好结果的方法。

       回复

48. 天啊，我以为HN上的函数式编程时代已经够让人受不了了，没想到会糟糕到这种地步。

    回复

    1. 说真的，这有什么问题吗？这似乎是有人在记录自己生产力的大幅提升，这种方式对他人可能确实有用。

       他们写的东西不像那种可以轻易忽视的人，也没有明显的红旗。

       除了“我不喜欢AI”——这里有什么让人无法忍受的？

       回复

49. 有人对如何招聘能够有效利用AI编程工具的开发者有建议吗？

    回复

    1. 我的母亲是一名英语教师，后来从事电子技术工作。我向她解释了大语言模型(LLMs)需要大量技术写作和文档编制，而那些没有尝试过这种方法或讨厌这种方法的开发人员，在输出效果不佳时会很快放弃。她的回答是：“哦，原来人文科学很重要！”招聘左脑和右脑兼备的初级员工。

       我们必须小心不要将他们拟人化，但大语言模型(LLMs)绝对会对符合心理学(人文科学)的细微词汇选择和行为定义做出反应。如何在面试中判断这一点？也许可以做一个“为机器人编写制作花生酱和果酱三明治的说明”的练习。让他们打字。参加过机器人俱乐部的应聘者有优势吗？

       他们会盲打吗？我见过一些经验丰富的开发人员打字时像鸡啄米一样痛苦。当他们需要快速连续输入提示、中断并重新表述时会发生什么？学校并未强制要求打字训练，而我观察到(甚至在我自己家中！我尝试过…)越来越多的孩子发明了类似“大写锁定键开关替代换挡键”的奇特跨键盘操作方式。

       回复

    2. 我最近一直在思考这个问题。要做到这一点，你需要知道人们通常在哪些地方会犯错，然后围绕这些错误制定一个评估标准。以下是一些我认为需要关注的点：

       – 能够在前期明确定义需求(在编程面试中，相当于直接开始编码，而不是先提问并完全理解问题和解决方案，然后再写第一行代码)。这可能是面试的大部分内容。

       – 能够预测大语言模型(LLM)会犯哪些错误。例如，看看他们是否使用困惑度/上下文7。仅依靠大语言模型(LLM)的训练数据是一个错误。

       – 熟悉如何并行化工作，以及何时有用、何时无用。他们是否了解如何使用工作树、多个存储库或 Docker 来分割工作？

       – 使用测试(包括端到端测试和视觉测试)

       – 他们是否能在合理时间内交付可用的功能/产品？

       – 最终结果是否看起来像AI的粗制滥造，还是实际上性能良好、可维护(对人类和新上下文窗口均适用)、设计合理，并遵循最佳实践？

       – 他们是否能够在大型代码库中高效工作？(这取决于你所处的阶段；如果你是大型公司，这一点很重要，但如果你是初创公司，你可能更希望进行0到1类型的面试)

       – 他们使用的是什么工具？如果有人使用 Claude Code，我会给予更高的评价，因为这是最适合这项工作的工具。如果他们只是做一些流行的事，比如使用 Claude Agents，我会扣分。

       – 他们使用 AI 的效率如何？他们只是简单地处理令牌吗？他们是否根据任务的复杂程度使用了正确的模型？

       回复

    3. 首先你得决定是否要招聘能独立推进任务并接受资深指导的初级开发者，因为初级开发者可能不明白自己在做什么，也不明白AI为何要让他们做“错误”的事情。

       资深开发者已经掌握了有效使用AI工具的方法，且往往与AI同样高效，因此他们只能从框架支持中获益。

       归根结底，一切都取决于规划，你的成功不会取决于人们使用AI工具，而是取决于引导过程的人，即项目经理、设计师以及帮助实现愿景的架构师和资深开发人员。

       能够推动任务完成的初级开发人员只有在得到适当指导时才有价值，否则你只会制造一团乱麻。

       回复

50. 我最初非常怀疑。几周前我开始使用Atlassian的Rovo Dev CLI(Sonnet 4)，立即成功构建并完成了几个项目。我学到了很多，可以肯定的是，拥有经验、决定技术栈和架构对“引导”一个基于代理的编码应用程序是一个巨大的优势。我不确定是否有人能在没有一定技能的情况下构建和维护项目，但如果你是经验丰富的开发者，这简直就是魔法。

    我也很欣赏在让代理开始工作前先用Markdown编写需求文档的常见最佳实践。AWS的kiro.dev在规划阶段与执行阶段的分离上做得很好，但你几乎可以使用任何“聊天机器人”甚至ChatGPT来完成这一阶段。如果你患有注意力缺陷多动症或容易分心，这是关键。即使你决定手动完成一些步骤。

    无论你使用的是 Claude Code(带 Claude LLM)、Rovo Dev CLI、Kiro、Opencode、gemini-cli 还是其他什么，都无所谓。选择那些提供每日免费代币的，然后尝试一下。不，它们几乎不会完全没有错误地完成。但只需将错误复制粘贴到提示符中，或提出一些尖锐的问题(“你真的实现了去重和缓存吗？”)，通常代理会神奇地发现问题并开始修复。

    回复

51. 我使用过一段时间。我做了一些非常有用的事情，也放弃了其他事情并手动完成。

    它最擅长的是翻译。毕竟，这是大语言模型(LLMs)最初的设计目的。

    它可以翻译编程语言，比如“将这个舵手图表翻译成 Go 语言的控制器”。它会轻松地吐出所有结构和基本的协调逻辑。虽然有些地方会出错，但即使纠正这些错误，仍然可以节省大量时间。

    当然，用英语编写精确的规格说明时，它会将其翻译成代码。但这种做法是否真的节省时间，我并不完全认同。我仍然需要用英语输入这些规格说明，但现在我输入的内容会丢失，而生成的代码也不是我自己的语言。

    当然，它擅长生成 boilerplate 代码，但我本来就很少手动编写 boilerplate 代码。

    我发现它在生成大量代码时过于积极，而你可能希望一步步来，为每个新部分编写测试。它并不真正理解测试驱动开发，只是想编写未经测试的代码。

    总体而言，我认为它无疑是令人惊叹的。但就像儿童生日派对上的小丑一样。你见过那些气球动物吗？！我认为保持怀疑态度是有用的，不要仅仅因为你做不到某件事就对它感到惊叹。惊叹并不意味着有用。

    我对我们行业中发生的事情感到非常担忧。开发人员已经可以逃避极其粗糙的实践。在其他行业，此类行为会导致你被吊销执照、取消资格，甚至入狱。现在，我们不得不面对那些甚至不懂编程的初学者和人员，他们却能编写出可运行的软件。

    我真的认为，大语言模型(LLMs)会在医疗设备或任何可能危及公众安全的软件等重要软件的开发中被禁止使用。但也许我过于乐观了。我认为，一般人能够理解电工对保险盒等设备贴错标签的危险性，却无法理解劣质软件的危险性。

    回复

    1.   > 人们明白电工错误标记保险盒等操作的危险性，却不明白劣质软件的危险性
       

       我的意思是，大多数软件都附带那些大写字母的“不承担任何明示或暗示的保修责任 / 使用风险自负”

       如果大多数软件问题都有法律途径解决，那么目前围绕人工智能代理编程的热潮肯定会更加谨慎。

       我认为，就像许多事情一样，法律不会在重大灾难发生之前出现(或者你得到一位支持你的总统 *)

       * https://www.onlinesafetytrainer.com/president-theodore-roose…

       回复

       1. 確實有一些軟體未被這些標籤涵蓋，事實上還有很多。只是它們的价格要貴上好幾倍，所以除非你正在設計心臟起搏器等可證明安全的韌體，否則你永遠不會聽到它們的存在。

          回复

52. 有人有如何充分利用 Claude Code 的最佳實踐或指南嗎？

    回复

53. “信任，但要验证”

    AI，但要重构

    回复

    1. 这是一个非常有见地的观点

       回复

54. 到目前为止，我已经99%确信，对AI编程持怀疑态度的人不过是 Luddites。

    他们会说“但机器人永远无法像我一样打扫房子”，好吧，当然，但它们仍然可以非常出色地完成绝大多数工作(或至少按照你的指示完成)，并让你专注于细节和协调。

    回复

    1. 我仍然不完全信服。windsurf 的首席执行官说，明年的目标是让代理编码达到可靠性和成熟度，以便在成熟的代码库中投入生产使用。这确实有道理。

       我使用自动完成功能和与大语言模型(LLMs) 聊天来代替堆栈溢出。它们非常适合做这件事。除此之外，我和同事们发现人工智能代理还无法承担严肃的工作。我希望它们能够做到，真的希望。但更重要的是，我希望我们的软件可靠，代码健壮且易于理解，我不希望担心我们是否在自掘坟墓。

       我们构建支持其他公司软件的严肃软件基础设施，而我们最大的头疼问题是支持今年早些时候使用AI构建的代码。它写得糟糕，充满漏洞，包括一些从代码中很难发现的问题，而且大部分内容都难以理解。

       我认识的其他公司也在使用AI进行编程，并取得了巨大进展，但他们的软件是CRUD SaaS，最坏的情况下他们可以从头开始。我们没有这个奢侈。

       回复

    2. 如果你从解决问题和编程中获得的乐趣与做家务一样多，我不确定你为什么选择这个职业。我同意那些100%反对使用它的人反应过度，但根据我的经验，用vibe编程取代绝大多数工作既让开发者感到麻木，也无法带来更好的结果(或更快的结果，除非你基本上是在不顾正确性地随意编程)

       回复

       1. 振动编码是指你不检查输出结果。

          指示 Claude Code 处理代码中的循环依赖边缘案例并为此编写测试，同时审查工作，这绝对不属于振动编码。

          回复

55. 我认为 Claude Code 非常棒，但我已经习惯了“Cursor-tab tab tab”的自动完成风格。我有些困惑的是，为什么 Claude Code 与 VS Code 的整合没有添加这样的功能？对我来说，这会使其成为一款完美的产品。我感到惊讶的是，为什么没有更多人谈论这个问题，为什么这不是一个更常见的功能请求。

    回复

    1. “Cursor tab tab tab”简直太疯狂了。我也习惯了随意打字，犯语法错误，谁会在乎一个制表符能否解决这个问题呢？我用它打字非常顺手。至于为什么更多人没有谈论这个问题，我强烈认为，工具的成功在于市场的中位数，而不是卓越性。我认为，拥有出色自动完成功能的编码人员才是真正的高手。我发现讨论这个问题非常无聊，而且没有生产力。

       回复

    2. 同意。我用过一点 Claude 代码，觉得挺好，但感觉自己与变化脱节了，可能是因为编码太过随性了吧？

       对我来说，Cursor 还是一个不错的平衡点。我正在将很多编写工作自动化，但仍然是一小段一小段的，这样更容易审查。

       回复

       1. 使用这些智能编码工具，你可以与代码进行更深入的对话。我最喜欢的CC用法是在编码一天后，让它对更改、文件甚至整个项目进行彻底审查。我可以在睡觉前设置它开始工作，让它识别问题并为最重要的问题提出修复方案。如果提示正确并启用权限，它可以独立运行很长时间。

          回复

    3. 我只是在 Cursor 的终端中使用 Claude Code(只需一个热键，非常方便)。两个月来，我没有使用光标聊天，但标签自动完成功能非常不错，绝对值得 20 美元。

       回复

56. 对我来说，问题在于预测人工智能可能会犯什么错误。Claude 可能今天能解决艰难的编码问题，但明天却无法处理线程安全等基本问题。但总体而言，我认为很明显，如果使用得当，人工智能可以节省大量开发时间。

    回复

57. 每当我赞扬 Claude 时，都会被投反对票。但这个帖子中的每个人都因为说了同样的话而获得赞同票。谁能解释一下其中的区别吗？

    回复

    1. 你回复的是那些对大语言模型(LLMs)有过负面体验并发表了细致批评的人，而你的回复是：“好吧，但你试过 Claude 4 吗？

       在这些对话中，这既无济于事，也不合理。

       回复

       1. 我想，如果有人告诉我他们害怕死亡，而我恰好掌握了永生的秘密，那么分享给他们是值得的。

          回复

    2. 互联网善变且充斥着无知之徒。一切都是碰运气。

       回复

    3. 是的，你是在一个真正使用它的人们的帖子中。

       回复

58. 有人能把它与 Cursor 进行比较吗？

    回复

59. 严重过度设计的系统。到处都是不必要的复杂性。进步的幻觉。

    回复

60. 我最近试用了 7 天的 Claude Code 试用版。我对此有 3 种截然不同的体验：一种显然是积极的，一种是消极的，一种是中性的但趋于积极的。

    消极的体验是要求它在现有的 Python 模块中生成一个相对非平凡的功能。

    我有一系列用于生成PDF文件的类。每个类对应文档中的一个页面模板(如标题页、统计页等)。这些类内部使用了诸如`draw_title(x, y, title)`或`draw_table(x, y, data)`等函数。其中一个表格在行数超过页面空间时需要跨多页显示。因此，我需要 Claude Code 编写一种递归的顶级驱动程序，在文档中添加新页面，直到输入数据用完为止。

    我花了一个小时左右的时间指导 Claude 编写这个功能，最终它编写出了看起来表面上正确的代码，但无法编译。经过一段时间的调试后，我放弃了，直接用手写了代码。即使对我来说，这个功能也不容易实现，我花了大约两天时间。它打破了模块中的现有模式。该模块的设计理念是“一个数据容器 = 一页”，因此将数据拆分到多页是一个新模式，模块的其余部分需要适应这个新模式。我认为这就是 Claude 表现不佳的原因。

    +++

    Claude 明显的好处是，它能够将新测试添加到结构良好的集成测试套件中。向该模块添加测试是一项乏味的工作，因为大部分工作都是设置输入数据。测试套件中的模式大致如下：包含所有测试逻辑的 IntegrationTestParent 类，以及一些进行数据设置并调用父类测试方法的 IntegrationTestA/B/C/D。

    Claude 轻松完成了这项任务。它遵循了一个清晰的模式，并生成了完美的代码。这为我节省了 1 到 2 个小时的时间，但最酷的是，它是在自己的终端窗口中完成这项工作的，而我则可以做其他事情。这是我会交给新工程师的一种简单任务，让他们接触到现有的模式。

    +++

    最后一个案例是让它从零开始用我不会的语言编写一个小型命令行工具。该工具的工作原理是：你指定一个目录，它会检查该目录中是否存在5到6个文件，且这些文件的命名和格式符合特定规范。如果文件缺失或格式不正确，则抛出错误。

    该工具供另一个团队使用，以便他们在将这些文件转发给我之前先检查这些文件。因此，我需要一个可执行二进制文件，可以将其上传到 Dropbox 或类似平台，以便另一个团队下载并使用。我主要使用 Python/JavaScript 编写代码，用解释型语言制作这样的共享工具非常麻烦。

    因此，我让 Claude 用 Golang 编写了一个工具。花了大约 2 个小时，这个工具就按照预期运行了。Claude 非常乐于助人。

    一方面，这对 Claude 来说显然是一个胜利。另一方面，我什么也没学到。我想学习 Go，但不能说从这次经历中学到了任何 Go 知识。下次我需要编写这样的工具时，我想我会自己从头开始编写，这样我就能学到一些东西了。

    +++

    嗯。自从“人工智能”工具问世以来，我就一直在使用它们。我是公司里第一个获得大语言模型(LLM) Copilot 自动完成功能的人，当 ChatGPT 推出后，我一夜之间就成了重度用户。我试过 Cursor(讨厌它的 VSCode 特性)，也试过重新打过牌的 Copilot。现在，我试了 Claude Code。

    我并不是“人工智能”的怀疑论者，但我仍然不明白为什么会有如此疯狂的炒作。我感觉这些工具最多能让我效率提升1.5倍——这已经很多了，所以我一定会紧跟新工具的发展——但我并不觉得自己即将被取代。

    回复

    1. 你的糟糕体验是因为AI无法进行一般的推理。它通过变压器获得某种推理能力，但这与你描述的问题所需的推理完全不同。

       大语言模型(LLMs)在翻译方面非常出色。基本上，它可以将英语转换成代码。但如果要求它解决一个没有解决方案描述的新问题，它会如何处理呢？如果它的训练集中有例子，也许它可以回忆起来。否则，它就没有能力得出解决方案。

       回复

       1. 然而，大多数问题(新问题、训练集中没有的问题)都可以分解成更简单、已知的问题。目前，人工智能并不擅长进行这种分解，因此必须由人类来完成。

          回复

61. 我目前在欧洲，注意到当北美醒来时，Claude 代码的速度会明显变慢……

    回复