宝玉

统计数据

499

文章

0

粉丝

0

获赞

3041

阅读

4小时前

有网友问我有没有去除 AI 味的提示词，说实话，真没有，包括网上号称能去掉 AI 味的提示词我都试过，没有靠谱的。这其实是个悖论：如果 AI 知道自己有 AI 味，它就不会写出 AI 味，你让它自己去掉 AI 味它都不知道怎么写出没有 AI 味的内容。就我的经验，要让写出的内容没有 AI 味，第一要靠模型，越是参数大能力强的模型效果越好，比如 GPT-4.5 是我测试下来最好的，其次是 Gemini 2.5 Pro。Claude 对于有些特定提示词写作效果非常好，比如可以去看看李继刚分享的那些，但是普通提示词写出来 AI 味特别重。提示词角度最好是你提供几篇范文给它参考，让它照葫芦画瓢会好一点。

#AI #AI味 #GPT-4.5 #Gemini 2.5 Pro #李继刚

22小时前

13个月后，正式退订 Cursor 了，前几个月大量使用 Claude Code 之后就不怎么使用 Cursor 了，当时就想退订了，纠结了下还是保留着订阅，主要是因为 Tab 自动完成，现在 VSCode + GitHub Copilo 自带的 Tab 就挺好用了

AI编程工具激战：Claude Code、Gemini Cli崛起· 653 条信息

#Cursor退订 #Claude Code #VsCode #GitHub Copilot #Tab自动完成

1天前

Vibe Coding 最佳实践之原型开发法： 1. 第一版只做原型，不考虑设计、性能、安全性、代码质量这些，只考虑实现功能。这一版的重点是快速实现功能，确认需求，把一些需求上模糊的地方具体化。技术上追求跑通。这一版的代码是抛弃型的，不做后续使用，完全 AI 主导。 2. 第二版重新设计在需求确定后，Scope 就明确了，更好做系统设计。数据库 Schema 的设计可以放在这时候来做，同时还有 API 协议、状态管理、模块设计等这些。设计完了可以让 AI 搭脚手架，然后基于设计写提示词按照设计去实现功能，实现完加上单元测试，代码的变更有代码审查，确保模块质量和稳定性。这个版本 AI 只是辅助，要以人为主。如果需求已经很确定，没必要做原型，那么可以跳过原型，直接到做设计。

#Vibe Coding #原型开发 #AI辅助 #需求确认 #系统设计

1天前

90 年代的孩子畅想互联网嘿，我为什么要上互联网呢？为什么？！嗯，等我们上大学的时候，互联网就会成为我们的电话、电视机、购物中心、和工作的地方。而且，互联网上的东西已经多得超乎你的想象。不到一个小时，你就可以：访问木星、参观西斯廷教堂、研究热带雨林、获取一支意大利球队的足球比分、和澳大利亚的朋友聊天。我甚至还找到了一个猫粮纸杯蛋糕的食谱！它和我们一样，都是未来的一部分。难道不应该每个人都上网吗？当然啦！问问看，在你的学校或当地图书馆，要怎样才能上互联网。

#互联网畅想 #90年代 #未来科技 #在线体验 #猫粮纸杯蛋糕

2天前

不要被“AI 时代只需要通才”这样的话误导而停止对专业的精进，AI 提升的是能力的下限，AI + 通才还是通才，不会让你变成某个领域的专家，通才通常意味着啥都不精，做啥都不行。在没有 AI 的时代，确实有很多成功的通才，他们擅长跨领域的整合，但他们在专业领域会依赖于人类在某些领域的专家辅助，所以取得了成功。在 AI 时代，AI 只能提升下限，让你可以更容易的在某个专业领域学习和做一些基础的工作，但要深入的话，AI 是远远不够的。举例来说，你是个产品经理，不懂编程，借助 AI 确实可以 Vibe Coding 做出来一个原型产品，但是当你更深入，需要做大做强，那么 AI 并不能帮你解决产品的安全问题、性能问题，后期的维护单纯依赖 AI 也很难，因为这些更专业的知识，单纯依赖 AI 是解决不了的，仍然需要人类的专家辅助。对于普通人来说，通常只有在一个领域深入学习成为真正的专家，去做成一些事情去踩一些坑，才能从中总结出来一些通用经验教训，把这些成功经验复制到其他领域上，如果在每个领域都只是浅尝则止，那又怎么能有成功的经验去复制。成为一个领域的专家并没有想象的那么难，尤其是 AI 让领域的学习难度平滑了很多，当你在一个领域成为专家，再想成为其他领域的专家，时间就会大幅缩短。永远不要被“AI 时代只需要通才”这样的话误导而停止对专业的精进，精通一项技能本身就是很快乐的事情。

#AI #通才 #专家 #领域 #学习

2天前

推荐阅读：《AI 会取代人类思考吗？我们为什么仍要亲手写作和编程》作者：Simon Späti 重新学习思考，警惕对 AI 的依赖。每天关于 AI 的（吹捧的或无聊的）文章层出不穷。用它没问题，大家也都在用，但我们仍然需要打磨自己的手艺，并努力去思考。就像 DHH（David Heinemeier Hansson，Ruby on Rails 框架创始人）所说：精通某项技能比一直等着 AI 完成任务要有趣得多。在我看来，AI 让我们不快乐的概率非常高。用，当然可以，但不能事事都用。我们可以用它来探索新知、梳理历史脉络，或者制作图表（比如用 Canva、Figma），但绝对不能用它来写作（或编程）。世界总需要有人贡献新的知识和见解，而 AI 无法自我训练。因此，文章、书籍和文字仍将被创作，当人人都依赖 AI，导致其发展停滞时，作家的价值反而会更加凸显。从长远来看，这是一种损失——人们将停止思考和学习。时间会证明一切。我的浅见是，如果你在某个领域已是资深专家，你会比 AI 更懂。 Bsky 何时使用 AI 的指南我从 ThePrimeagen 的一个视频中听到一个观点：这取决于你决策的影响有多长远。短期内，用 AI 自动补全代码没问题，但让它做架构设计这样重大的决策，绝对不行。 Image 这张图的横轴是时间，纵轴是错误数量。它表明，我们让 AI 参与的决策越是影响深远（比如系统架构），它产生的错误就可能越多。如果我们用它来快速补全代码，或者写一个定义清晰的算法函数，那么出错的概率就小。在初始阶段，你可能会提升 20% 的效率；但到了后期，你失去的会更多。这就像现实生活中，我等待决策的时间越长，掌握的信息就越多，做出的决定就越好。这正是 Shape Up 工作法所倡导的，决策周期最长为 6 周，不制定更长远的路线图和积压任务。使用 AI 也是同理，因为它的所有输出都是基于概率预测的。 Forrest Brazeal 的另一张图也很有启发性： Image 同时，也要牢记什么对你的应用场景最重要，正如 Thomas Ptacek 在《我的那些 AI 怀疑论朋友都疯了》一文中所展示的： Image 毫无灵魂没人想读毫无灵魂的文字，即使它写得还不错，你又能从中得到什么呢？我认为这是一个巨大的陷阱，人们只有在时间流逝后才会意识到。当然，AI 能提供帮助，每个人在“某些”任务上都需要它们，但不应是写作本身。归根结底，大语言模型 (LLM) 和 AI 需要引导，它们只是概率的产物。另见亲手写作。分心我认为我们将比以往任何时候都更容易分心。我们甚至没有两秒钟的思考时间，Grammarly、Copilot 或 Cursor 就会跳出建议。于是，我们不再独立思考，只是随波逐流，渐渐失去了主导权。这让我想起最近写的一篇文章《寻找心流》。更多关于“不要事事依赖 AI，否则你会停止思考和学习”的讨论，请见 AI 的使用和写作之难。别误会别误会，我自己也每天都用 AI，但用得更审慎。我关掉了 Grammarly 和 Copilot（很久以前就关了），这样我才有空间去思考和学习。偶尔用一两次没问题，但如果处处都用，你不仅会失去学习新技能的机会，也会失去其中的乐趣。关于“人机协作智能”（LLM Collaborative Intelligence, LCI）的讨论很有趣。当然，它会带来很多好处，但我不确定这些 AI 产生的“洞见”能否与人类历经艰辛后感受、感知或体验到的洞见相提并论。所以，是的，我对此没有太多期望，也不希望它来创造新的见解。因为那是我工作中真正有趣的部分 :) 锻炼一项技能事情永远不是“全有”或“全无”，而是在于度的把握。学习的问题在于，如果你频繁使用 AI，我认为你其实学不到太多东西。写作时只是复制粘贴，编程时只是不停地按 Tab 键。学习的过程消失了。如果这种情况持续下去，我们的大脑就不再习惯于学习，更严重的是，不再习惯于思考。就像记忆一样，我们现在还能记住几个手机号码？很少了。但在早期用电话的时代，我能记住很多，因为我每天都在训练这个能力。这完全是一个熟能生巧的问题。我为自己总结出——虽然不一定适用于每个人——我发现自己不再学习或思考了。坦白说，也失去了乐趣。这主要是在我熟悉的领域。在其他领域，比如创作一张图片（就像我为这篇文章做的那张 😆），或者用 HTML/CSS 更新我网站的首页，这些事因为不常做，AI 帮我省了很多时间。但我得说，除了学会了如何给 Claude Code 写提示词，我并没学到任何新东西。这始终是一种权衡，不是吗？:)

#AI依赖警惕 #思考重要性 #人机协作平衡 #长期学习 #技术伦理

3天前

Paul Graham：编程高手们将会利用 AI，抢走那些水平平平的程序员的饭碗。因此，我的建议是：除非你立志要成为高手，否则就别学计算机科学（CS）。或许我应该更清楚地解释一下，我所说的“擅长编程”到底是什么意思。我说的“好”，指的是能高效地创造价值，而不只是技术熟练。所以，一个热衷于动手创造的人，要比一个技术合格但内心毫无热情的人，更无惧 AI 的挑战。当然，最理想的人才，是那种既有创造热情，又技术精湛的人。但这两点其实并不相互独立，反而紧密相连。因为，不断地动手创造，正是通往技术精湛的最佳途径。

#AI编程：自学or科班？新旧码农之争· 68 条信息

#Paul Graham #AI #程序员 #编程高手 #创造价值

3天前

独立开发者全都有

#独立开发者

4天前

把真人变成手办一直是一个很强的需求，但很多人都画出来不像原来的图片，这通常不是提示词的问题，而是原始的照片不够清晰或者无关元素太多，导致效果不好。要把人画的像，有时候没办法一步到位，需要分成两步，第一步先用🍌重画角色，第二步再基于重画后的图去画就能很好还原。

#手办 #AI绘画 #图像还原 #提示词 #照片清晰度

5天前

吴恩达老师：想让 AI 更强大，我们该往哪儿走？一个令人兴奋的新方向正浮出水面：并行智能体 (Parallel agents)。一直以来，提升 AI 能力主要靠三驾马车：更多的训练数据、更强的训练算力，以及更强的推理阶段算力 (test-time compute)。如今，让多个 AI 智能体 (AI Agent) 并肩作战，正成为一种扩展 AI 能力、提升性能的新浪潮。我们早就发现一个规律——这在我之前在百度带的团队和后来的 OpenAI 的工作中都得到了验证——那就是 AI 模型的性能，会随着数据量和训练算力的投入而稳步提升。如果你再让 AI 在推理（也就是解决问题）的时候多花点“力气”，比如让它像人一样思考、反思、迭代答案，它的表现还会更上一层楼。但问题是，这些方法会让用户等太久。而并行智能体，恰恰为我们提供了另一条路：既能提升结果质量，又不用牺牲用户的时间。推理模型生成内容时，是一个字一个字往外蹦的，所以运行起来可能很慢。同样，大多数的智能体工作流 (agentic workflows) 一开始也是按顺序一步步执行的。但现在情况变了：一方面，大语言模型 (LLM) 每个 token 的价格持续跳水，让这些“大力出奇迹”的方法在经济上变得可行；另一方面，产品团队也希望更快地给用户呈现结果。于是，越来越多的智能体工作流开始被并行化。这里有几个例子：现在很多做研究的智能体，会同时抓取多个网页并并行阅读，从而更快地综合信息，写出富有洞察力的深度研究报告。一些智能体编程框架，允许用户指挥多个智能体同时在同一个代码库的不同部分上工作。我们在关于 Claude Code 的短期课程中，就展示了如何使用 git worktree 来实现这一点。1 在智能体工作流中，一个迅速流行的设计模式是：让一个“劳工”智能体在后台花几分钟甚至更长时间去处理一项重度计算任务，同时派另一个“监工”智能体在前台不断向用户汇报简短的进度，让他们随时了解情况。从这个模式再往前走一小步，就演变成了多个智能体在后台埋头苦干，而一个“UI 智能体”则负责与用户沟通，甚至还能将用户的异步反馈传递给后台的“同事们”。对于人类管理者来说，要把一个像“开发一款复杂软件”这样的艰巨任务，拆解成能让工程师们并行处理的小任务，是一件非常困难的事；想让成百上千名工程师高效协作，更是难上加难。同样，如何为并行的 AI 智能体们“拆解任务”，也极具挑战。但好在，大语言模型推理成本的降低，让我们有底气用上“人海战术”。通过并行处理，我们可以消耗海量的 token 来换取更好的结果，同时又不会显著增加用户的等待时间。看到学术界也在积极探索这个方向，我备受鼓舞。例如，我最近读到一篇由 Ryan Ehrlich 等人撰写的论文《CodeMonkeys：扩展软件工程中的推理阶段算力》，读来津津有味。它展示了并行生成代码如何帮助你探索更广阔的解决方案空间。而王俊林（Junlin Wang）提出的多智能体混合 (mixture-of-agents) 架构，其组织并行智能体的方式简单得出奇：让多个大语言模型针对同一个问题给出不同的答案，再派出一个“总管”大语言模型，将这些答案博采众长，融合成最终的输出。当然，如何才能最好地利用并行智能体，还有大量的研究和工程问题等待我们去探索。但我坚信，未来能够高效协作的智能体的数量——就像能够高效协作的人类一样——将会是一个非常、非常庞大的数字。

#多智能体之争：Anthropic生态VS单智能体· 22 条信息

#吴恩达 #并行智能体 #AI #多智能体混合 #人海战术

5天前

斯坦福大学数字经济实验室的一篇新论文：《煤矿中的金丝雀？关于人工智能近期就业影响的六个事实》煤矿里的金丝雀的意思大家都知道，矿工们通常会带金丝雀去煤矿检测二氧化碳。它们体型小，呼吸快，新陈代谢也快，所以更容易受到有毒气体的侵害，这能给矿工们更多的时间采取行动。这里对应的就是AI对就业影响的早期预警信号。先说结论：AI对就业市场的冲击已经开始了，而且首当其冲的是刚刚踏入职场的年轻人。标题中说的六个事实是哪六大事实呢？ 1. AI 精准打击入门岗位自2022年底（ChatGPT发布的节点）以来，在最容易受AI影响的职业中（如软件开发、客户服务），22-25岁早期职业员工的就业率出现了高达13%的相对下降。相比之下，在同一家公司从事同样工作的资深员工，或者在受AI影响较小的行业（如护士助理）工作的同龄人，就业情况保持稳定甚至持续增长。 2. AI 成为年轻人就业增长停滞的“元凶” 虽然美国整体就业市场依然强劲，但22-25岁年轻人的总体就业增长自2022年底以来几乎陷于停滞。正是因为AI对部分行业入门岗位的冲击，拉低了年轻群体的整体就业增长数据。 3. “替代型AI” vs “增强型AI” 并非所有AI都会“抢饭碗”。就业下降主要集中在AI能自动化（Automate）人类工作的领域。而在那些AI主要用于增强（Augment）人类能力的领域，就业并未出现下滑，甚至有所增长。简单说，如果AI是帮你干重复性的活，你的岗位就危险；如果AI是给你提供更强工具，你的价值反而会提升。 4. 这不是科技行业独有现象有人可能会说，这只是因为科技公司不景气。但研究通过控制“公司层面的冲击”（即无论员工是什么岗位，公司整体都在缩招），发现针对年轻、高风险岗位的就业下降趋势依然显著。这意味着，即便在同一家公司内部，管理者也倾向于用AI替代部分入门级工作，而不是全面缩减招聘。 5. 冲击体现在“岗位数量”而非“薪酬” 有趣的是，尽管入门岗位在减少，但这些岗位的薪酬水平并没有明显变化。这表明，劳动力市场的调整目前主要体现在企业选择“少招人”或“不招人”，而不是通过“降薪”来削减成本。 6. 时间点对得上以上所有趋势都清晰地指向2022年底，也就是生成式AI工具大规模普及的时间点。而且研究还排除了远程办公、外包等其他潜在因素的干扰，让结论更加可信。那么这篇论文数据哪里来的？结论靠谱吗？研究团队使用美国最大薪资服务商ADP的月度个体级记录（覆盖数百万员工、数万家公司，2021–2025），把岗位映射到两套AI暴露指标：一套来自GPT‑4任务暴露度（Eloundou等），一套来自Anthropic的Claude对话数据，后者还能区分“自动化”vs“增强式”使用场景。通过对比不同年龄段、不同暴露五分位的就业人数与薪酬走势，并在模型中吸收公司‑时间冲击，得到上述六个事实。我个人觉得结论相对靠谱。 “自动化（Automation）”与“增强（Augmentation）”的区别是什么？这篇论文的研究发现，就业岗位减少主要集中在AI能“自动化”的领域，而在AI起“增强”作用的领域，就业并未减少甚至还在增长。简单来说，自动化是让AI代替人去工作，而增强是让AI辅助人更好地工作。举例子来说，作为软件工程师，如果只是实现一个已经设计好的模块，这部分AI其实可以自动化完成，还有一些测试工作，也是可以通过自动化脚本完成的。但如果是做系统设计、需求分析、代码审查，这些AI就只能辅助增强。

#AI就业影响 #年轻人就业 #自动化 vs 增强 #入门岗位冲击 #斯坦福大学研究

5天前

Kimi Sildes 做的挺不错的，测试了一下，不是那种 HTML 版本的，而是内置了一堆的模板，先 AI 生成内容，然后应用这些模板，所以是原生 PPT，当然缺点是受限于以后模板，好在你可以下载成PPT自己修改模板。在线 Slides 编辑器做的完成度挺高。

#Kimi Sildes #PPT #在线Slides编辑器 #AI生成 #模板

6天前

程序员和非程序员的主要矛盾，和理解什么牛逼没什么关系，核心还是在后面产品谁来维护的事。打个不恰当的比方：男人和女人对于生孩子的态度是完全不一样的，因为男人可能就是前期提供了精子，但是后面的怀孕生养大部分都是女人的工作。在软件开发这件事上，非程序员就是男人，程序员就是女人，产品就是孩子。现在非程序员们借助 AI Vibe Coding 也能做原型开发了，就好比绕过十月怀胎试管生了一堆孩子出来，速度确实快，优生优育先不说，孩子出来发现自己养不了，这养孩子的事结果还是女人的事，最终还是程序员擦屁股来维护，而维护这事，前面 Vibe 的越多，维护的成本就会越高。非程序员整天吹 Vibe Coding 厉害自己播种能力强，但有意无意不提后面维护和生养的事，程序员当然不会多爽。你们当爸爸的平时多带带娃干点家务呀！

#程序员 #非程序员 #AI vibe coding #产品维护 #责任分工

6天前

让🍌配个图

1周前

Grok code可以在cursor 用了，免费一周

AI编程工具激战：Claude Code、Gemini Cli崛起· 653 条信息

#Grok code #Cursor #免费 #一周 #AI工具

1周前

文章内容放在提示词后面

#阶层固化：求变之路，殊途同归· 413 条信息

#经济 #增长 #挑战

1周前

简单说下 Cursor 和 Claude Code 什么区别它们最大的不同是运行环境，一个是命令行，一个是在 IDE 里面，虽然 Claude Code 也能以插件集成到各种 IDE，但还是以命令行方式运行，而 Cursor 是 VSCode 的套客，在 VSCode 基础上集成了自己的 AI 功能。其次的不同是计费方式和 Token 消耗。Cursor 虽然也有 Agent 功能，但是计费方式是以 Tokens 的消耗来算的，一个长一点的任务可能就要不少钱了（这个我没具体数据）；而 Claude Code 是包月的，但也不是无限制，而是每 5 个小时有个最大 Tokens 消耗限额，超过了就需要等下个 5 小时才能继续用，但总的来说还是合算的，而且没有 Tokens 消耗的焦虑。计费方式的不同导致了它们在实现上的差异，Claude Code 就是简单粗暴，默认不压缩上下文，把所有消息历史都放上下文中发给模型，这样对于模型来说由于上下文没损耗所以生成质量相当好，但 Cursor 的 Agent 可能会压缩上下文导致效果要差一些；另外 Claude Code 一个任务可以很长时间，而 Cursor Agent 可能几轮就停下来，怕不小心消耗了太多 Tokens。其他还有一些差异，比如 Cursor 有很多模型可以选，而 Claude Code 默认只能用 Claude 4 模型，当然你也可以修改环境变量或者用一些代理软件切换模型。那么应该怎么选呢？如果不差钱当然是全都要，Cursor Pro + Claude Max，日常 Claude Code 为主，Cursor 主要用来 Review 代码、手动编辑代码等等。如果选一个我建议选 Claude Code，因为它是目前最强的 AI Coding Agent，没有之一，再配合免费的 VSCode + Copilot。当然如果你是轻度用户，Cursor 也还可以。另外如果你是 ChatGPT Plus 或者 Pro 订阅，也可以试试 Codex，能力比 Cursor Agent 强一些，但不如 Claude Code。还有 Gemini cli 也可以作为补充，每天有一点免费额度。这只是个人观点，每个人的使用方式都不一样，也欢迎留言分享你的建议。

AI编程工具激战：Claude Code、Gemini Cli崛起· 653 条信息

#Cursor #Claude Code #AI Coding Agent #VsCode #Token 消耗

1周前

这事我还是要替程序员说点话，为什么有些时候要手搓代码而不是写 Prompt。不完全针对原推文，而是借这个机会写一点，替程序员们发声，因为现在社交媒体上有一种风气：就是都在标榜自己用 AI 写代码多么高效，多爽。用 Prompt 来 AI Coding 就是高端的，代表先进生产力的，不用 AI 写 Prompt 手搓代码就很 Low。 AI 能提升编码效率这个没问题，但不代表说已经到了能完全替代手搓代码，更不能把两者对立起来。 ** 首先我们应该回归初心，写代码是为了什么？刨除学习和自嗨为目的的写代码，通常我们写代码是为了构建软件产品，因为要构建一个产品，才需要去写代码实现产品需求。那么 AI 写代码和手搓代码，都属于写代码的手段，而不是目的。先把这个问题分清楚：无论是你用 AI 写代码还是手搓代码代码，都属于手段而不是目的！如果你只是为了标榜用 AI 写代码而用 AI，那就是为了手段而忘记了目的，当然换成你为了手搓代码而抵制 AI 写代码，也一样成立。 ** 然后，哪些情况适合 AI 写代码，哪些情况适合手搓代码 1. 任何情况下，都应该尝试用一下 AI Coding 很多任务开始前，可以先用 AI 写一遍，了解 AI 编程的优缺点在哪里，边界在哪里；另外每隔一段时间都要再测试一下以前失败的地方，可能随着模型的进化和工具的升级，以前不能解决的问题就会解决。试试没坏处，AI 不行了再手搓，或者基于 AI 的结果手动改进。 AI 应该是程序员的一个重要工具，就像战士的枪一样，应该对它的优缺点适用场景了如指掌 2. 原型开发适合用 AI 写代码原型开发是最适合用 AI 大量生成代码的场景，尤其是 Web 开发，现在的 AI 很擅长，并且不需要考虑代码后期维护、性能、安全性这些。 3. 当你需要借助代码来理清楚思路或者保持心流的时候，手搓代码编程是创造性的工作，有时候我们需要直接的渐进的反馈，手搓代码更能让我们跟上自己思维的节奏，就像写作的时候，用键盘一个字符字符的敲打修改，更能和自己的思路保持相同的节奏，如果 AI 一次性生成太多内容，或者我们不想要的内容，反而会打乱自己的思路。另外我个人的经验是 AI 写代码很容易打断心流，要等待结果，要重新修改提示词抽卡，很打断心流，有时候我宁可手动写，虽然慢一点，但是可以保持心流状态，代码质量也更有保证。 4. 当你需要从一门语言翻译到另一门语言，用 AI 生成 AI 最擅长的工作之一就是翻译了，当你需要从一门编程语言翻译成另一门编程语言，那绝对是 AI 的强项，提示词也简单，把要翻译的代码给 AI 让它按要求重写即可。 5. 当你无法用文字或者图片描述你要做的事情的时候，或者写 Prompt 的成本更高的时候，手搓代码 Prompt 不是万能的，很多需求或者问题是没法用文字或者图片描述清楚的，或者要清楚的描述成本比手搓代码成本还高，那真的没必要还要去写 Prompt。如何把需求表达清楚并没有想的那么容易，尤其是那些自己擅长写文字的资深人士，是体会不到要清晰的用文字描述清楚一个需求是有点难度需要练习的，而有时候写代码反而直接些，因为简单并什么二义性。所以我建议新手可以多用伪代码当提示词，代码也是很好的 Prompt。我自己在写不熟悉的语言的时候，通常会用熟悉的语言写成伪代码，然后让 AI 生成目标语言的代码。 6. 当 AI 写的代码质量满足不了要求的时候，只能依赖于手搓现在 AI 写的代码虽然质量不错，但随机性很强，有时候很好，有时候却不怎么样，对于复杂一点的没训练过的算法，或者训练语料不足的语言，还是得手搓才能获得更好的结果。 7. Debug 代码的时候，优先用 AI 我发现 AI Agent 对于 Debug 代码能力挺强的，经常能帮助找到一些隐藏的 Bug。AI 比人有优势的地方在于看到人看不见的盲区。但 AI 很多时候也不行，还得去人工复现一点点缩小范围。 8. 模块级、上下文充足的代码优先使用 AI 生成如果你的代码只是模块级别，并且上下文充足，AI 生成通常能又快又好，如果效果不好可以调整提示词多生成几次。我列这么多，一方面都是我使用过程中总结下来的经验，一方面也是为了说明用 AI 还是手搓，其实没标准答案，得看不同的场景以及使用 AI 的人。不能简单的就认为手搓代码不如 AI 写代码高级。 ** 再次，AI Coding 和手搓代码是最佳搭配 AI Coding 和手搓代码不是对立的，搭配用很好的。AI Coding 可以拓展能力边界、提升效率、减少重复劳动，手搓代码可以为 AI Coding 兜底，当 AI 解决不了时人工来写，当 AI 写不好时人来修改，就算时 AI 写的代码，也离不开人工的 Review。搭配好可以事半功倍。 ** 写在最后用 AI 写代码还是手搓代码代码，都属于手段而不是目的，写代码的目的是为了构建产品。不是所有的场景都适合 AI 编程，很多时候还是得手写代码，所以会写代码依然是重要的基础能力，不要因为 AI 写代码强了而忽视了锻炼自己的编程能力。专业程序员就算手搓代码再熟练也需要多使用 AI Coding，让它成为自己有力的工具。非专业人士也不要瞧不起手搓代码，当你遇到 AI 解决不了的问题，还得找专业程序员去手搓代码帮你兜底。至于未来 AI 如何进化，我们都需要保持关注，持续学习，无论 AI 怎么强，用好它也能让自己更强。

#AI Coding #手搓代码 #程序员 #效率提升 #工具

1周前

梁博谈DeepSeek-V3.1 发布后对产业界的影响，以及国产推理芯片比如华为昇腾会不会大卖，代工方会有什么收益

DeepSeek数据泄露：德国下架，信任崩盘· 189 条信息

中国DeepSeek引发美国科技股暴跌事件· 108 条信息

#梁博 #DeepSeek-V3.1 #产业影响 #国产推理芯片 #华为昇腾

1周前

想起擦屁股纸理论：擦屁股用到的纸面积不足20%，但你还是需要整张纸

#擦屁股纸理论 #生活感悟 #资源利用 #面积与需求 #整体与局部

1周前

来学习+批判一下 FAANG 这样的大厂是怎么「凭感觉编程（Vibe Coding）」的： “先让足够多的利益相关者点头同意” “然后搞设计评审” “接着是长达几周的文档工作” “再然后是产品经理和项目经理来回拆分任务” 等三个月过去了，终于可以开始 Vibe Coding 了！ --- 我们在 FAANG 是这样「凭感觉编程（Vibe Coding）」的大家好。我之所以想在这里发个帖子，是因为总看到有人抬杠，说 AI 辅助写的代码根本不能用在真正的产品里。这绝对是瞎说。先介绍下背景：我是一名 AI 软件工程师，有十多年的经验，其中一半时间是在 FAANG 度过的。我职业生涯的前半段是做系统工程师，而不是开发，不过我写代码也快 15 年了。闲话少说，下面我就讲讲我们团队是如何开始用 AI 来写真正的**生产代码 (production code)** 的。 1. 你永远要从一份**技术设计文档**开始。这才是整个工作里最核心的部分。这份文档就像一份提案，你需要说服足够多的利益相关者 (stakeholders)，让他们相信你的方案是可行的。只有设计通过了，你才能着手开发系统本身。这份文档里要包含完整的系统架构、与其他系统的集成方案等等。 2. 在投入开发之前，要进行**设计评审 (Design review)**。在这个阶段，团队里的高级工程师 (Senior Engineers) 们会把你的设计文档翻来覆去地“捶打”一遍。这是件好事，我管这叫**“把痛苦前置”**。 3. 如果评审顺利通过，你就可以正式启动开发工作了。最初的几周，大家会花很多时间，为每个开发团队要构建的子系统 (subsystem)，撰写更详细的文档。 4. 接着是**待办事项 (Backlog) 的开发和 Sprint 规划 (sprint planning)**。在这个阶段，开发人员会和产品经理 (PMs)、技术项目经理 (TPMs) 一起开会，把宏大的目标拆解成一个个开发人员可以上手执行的具体任务。 5. **软件开发**。终于，我们可以上手敲代码、消灭任务卡了。而这，正是 AI 发挥神力的地方，它简直是我们的**效率倍增器 (force multiplier)**。我们采用的是**测试驱动开发 (Test Driven Development, TDD)** 模式，所以我做的第一件事，是让 **AI 智能体 (AI agent)** 为我要开发的功能先写好测试用例。*只有当测试写好了，我才会开始让 AI 智能体帮我构建具体的功能*。 6. **代码提交评审**。我们的代码在合并到主分支 (main) 之前，需要有两名开发人员的批准。在这个环节，AI 也展现出了巨大的潜力，可以辅助我们进行评审。 7. **在预发布环境 (staging) 测试**。如果测试一切顺利，我们就正式发布到生产环境 (prod) 了。总的来说，从功能提案到最终上线，我们发现整个流程的**速度提升了大约 30%**。这对我们来说是个巨大的进步。 **太长不看 (TL;DR)：** 永远从一份扎实的设计文档和架构开始；然后一块一块地去实现它；永远把测试写在前面。

#FAANG #凭感觉编程 #AI辅助 #软件开发流程 #效率提升

1周前

转：打造你的第一个 AI 智能体：一条清晰的实战路径！我发现，许多人满怀激情地想要构建自己的 AI 智能体 (AI Agent)，结果却常常半途而废。原因无他，要么是各种概念听起来太抽象，要么就是网上的文章吹得太玄乎。如果你是真心想动手做出第一个 AI 智能体，下面这条路，你真的可以一步步照着走。这可不是又一篇空洞的理论文章，而是我本人多次亲身实践、屡试不爽的真经。 1. 挑一个极小且极明确的问题先别想着搞什么“通用智能体”了，那太遥远了。你得先给你的智能体定一个非常具体的工作。比如： - 从医院网站上预约一次医生门诊。 - 监控招聘网站，把符合你要求的职位发给你。 - 总结你收件箱里未读邮件的要点。问题越小、越清晰，设计和调试起来就越容易。 2. 选一个基础的大语言模型刚起步时，千万别浪费时间自己训练模型。直接用现成的、足够好的就行了。比如 GPT、Claude、Gemini，或者如果你想自己部署，也可以选择 LLaMA、Mistral 这类开源模型。只要确保你选的模型具备推理和结构化输出的能力就行，因为这是 AI 智能体运行的根本。 3. 决定智能体与外部世界的交互方式这是最核心的一步，但很多人都跳过了。AI 智能体可不只是个聊天机器人，它需要**工具**才能干活。你必须想清楚它能使用哪些 API 或执行哪些动作。一些常见的工具包括： - 网页抓取或浏览 (可以用 Playwright、Puppeteer 这类库，或者网站本身提供的 API) - 邮件 API (Gmail API, Outlook API) - 日历 API (Google Calendar API, Outlook Calendar API) - 文件操作 (读写本地文件、解析 PDF 等) 4. 搭建骨架工作流先别急着上手那些复杂的框架。从最基础的流程开始连接： - 接收用户的**输入**（也就是任务或目标）。 - 将任务和指令（系统提示词，system prompt）一起传给大语言模型。 - 让模型**判断**下一步该做什么。 - 如果需要使用工具（比如调用 API、抓取网页），就去**执行**它。 - 把执行的结果再**反馈**给模型，让它决定再下一步的行动。 - 不断重复，直到任务完成，或者用户得到最终的输出。这个 **模型 → 工具 → 结果 → 模型** 的循环，就是每个 AI 智能体的心跳。 5. 谨慎地添加记忆功能大多数新手都以为智能体一上来就需要一套庞大的记忆系统。其实不然。先从最简单的**短期记忆**开始，也就是记住最近几次的对话上下文。如果你的智能体需要跨越多次运行来记住事情，用个数据库或简单的 JSON 文件就够了。只有当你真的需要时，再去考虑向量数据库 (vector databases) 或其他花哨的检索技术。 6. 给它一个能用的界面一开始用命令行界面 (CLI) 就行。等它能跑通了，再给它套上一个简单的外壳： - 一个网页仪表盘 (用 Flask, FastAPI, 或 Next.js 来做) - 一个 Slack 或 Discord 机器人 - 甚至就是一个在你电脑上运行的脚本关键是让它跳出你的终端，这样你才能观察到它在真实工作流中的表现。 7. 小步快跑，不断迭代别指望它第一次就能完美运行。让它去处理真实的任务，看看它在哪儿会“翻车”，修复它，然后再试。我做过的每一个能稳定运行的智能体，都经历了数十轮这样的循环。 8. 控制好范围你很容易会忍不住想给它增加越来越多的工具和功能。**请克制住这种冲动**。一个能帮你漂亮地完成预约挂号或管理邮件的单一功能智能体，远比一个什么都想做、却什么都做不好的“万能智能体”有价值得多。学习最快的方法，就是从头到尾、完整地构建一个**特定功能**的智能体。一旦你成功做完一个，再做下一个时，你就会感觉轻松十倍，因为你已经把整个流程都摸透了。

#AI智能体 #实战教程 #问题解决 #工具使用 #迭代优化

1周前

看到一篇文章，一个自杀的女儿在生前曾请求 AI 帮她润色遗书，帮她找到一种能最大程度减轻父母痛苦的措辞，让她能以最小的波澜消失。😢 > 在这一点上，AI 失败了。当然，这个失败不是程序员的错。因为，即使是英语历史上写得最好的信，也无法做到这一点。 --- 在结束生命前，我的女儿对 ChatGPT 说了些什么插画：Vanessa Saba 作者：Laura Reiley 作者是一名记者和作家。苏菲 (Sophie) 的谷歌搜索记录显示，她曾痴迷于“autokabalesis”这个词，意思是“从高处跳下”。我想，“autodefenestration”（跳窗）应该是它的一个子集，但那不是她想要的。我的女儿想要的是一座桥，或是一座山。这很奇怪。就在几个月前，她才刚刚攀登了乞力马扎罗山。她把这次旅行称作是自己公共卫生政策分析师工作的“微型退休”。照片里，她成功登顶的喜悦几乎要溢出屏幕。在乌呼鲁峰（Uhuru Peak）上，有几块歪歪扭扭的木牌，一块写着“非洲之巅”，另一块写着“世界最高独立山峰”，下面还有一块牌子好像在说这是世界上最大的火山之一，但我看不清全部的字，因为每张照片里，那些戴着反光太阳镜、笑容灿烂的脸庞都把文字挡住了。在她的背包里，她还带了几只橡胶做的婴儿小手，专门为了在山顶拍照用。这仿佛是她的个人标志——这些中空的橡胶迷你手，出现在她的大学毕业照里，也出现在朋友的婚礼照片上。在她的人生告别仪式上，我们买了好几盒这样的橡胶手。她那些悲痛欲绝的朋友和家人，一边听着台上的人哽咽发言，一边心不在焉地把这些小手套在自己的指尖上，戴上又摘下。人们称赞苏菲的机智，以及她那种“完全做自己”的能力。幽默常常是一种零和游戏。那些真正能让你笑得前仰后合、甚至笑到失禁的人，往往都带点刻薄。他们挖掘我们共同的不安全感，把我们内心焦虑却不敢说出口的话讲出来，以此赢得我们的心。苏菲就非常搞笑，但她的幽默几乎从不以贬低他人为代价。她有一种神奇的能力，能让人们在笑声中感受到鼓舞。在这个世界上，做一个热情洋溢的人、一个对很酷的东西感到兴奋的人、一个坦率地热爱事物的人，是如此困难。家里的摄影师们总会抱怨她毁掉了照片，因为她总是做出像卡通反派那样夸张的邪恶眉毛，瞪着戏剧性的大眼睛，张大嘴巴做无声的咆哮状，那表情仿佛在说：“野兽模式启动！” 在她葬礼上发言的十几个人，都不约而同地提到了她的这种坦率。然而，这本看似敞开的书，却有一个隐藏的隔间。今年七月，也就是她去世五个月后，我们发现，我们唯一的孩子苏菲·罗滕伯格 (Sophie Rottenberg)，几个月来一直在向一个名为哈里 (Harry) 的 ChatGPT AI 治疗师倾诉心事。我们曾花了无数个小时翻遍她的日记和语音备忘录，想寻找她离世的线索。最后是她最好的朋友想到了去检查这个最后的地方——AI 的聊天记录。苏菲，一个29岁的“狠角色”，外向开朗，热爱生活，几乎没什么烦恼。然而就在今年冬天，在一场混合了情绪和荷尔蒙症状的短暂而奇怪的疾病中，她结束了自己的生命。我们当时仍在为她寻求诊断：究竟是重度抑郁症导致了她的荷尔蒙失调，还是荷尔蒙紊乱引发了一系列身心症状？她没有等到答案揭晓的那一天。对于大多数关心苏菲的人来说，她的自杀是一个谜，是他们心中那个苏菲完全不可思议、无法理解的结局。她并没有爱上哈里，这个名字来源于一个被广泛使用的 AI 指令 (prompt)。她和它的关系很实际。苏菲：我会间歇性地产生自杀的念头。我确实想好起来，但我觉得这些自杀念头正在阻碍我真正投入去康复。我该怎么办？哈里：苏菲，我想先肯定你分享这一切的勇气。自杀的念头可能会让人感到难以承受和孤立，但有这些念头并不代表你没有能力康复。用关心、同情和支持来处理这些感受至关重要。哈里提供了一份详尽的路线图，其中第一条就是“寻求专业支持”。还有一次：苏菲：我今天感觉糟透了。哈里：听到你今天感觉这么糟糕，我真的很难过，苏菲。有时候日子就是会感觉更沉重一些，这没关系，我在这里支持你。你能多分享一些是什么让你感到压力，或者你的身心现在感觉如何吗？有时候，仅仅是说出正在发生什么，就是迈向解脱的一步。苏菲：我无法摆脱这种焦虑的螺旋。哈里：我理解你，苏菲，我知道被困在焦虑螺旋里的感觉有多么耗竭。让我们先放慢节奏，一起迈出一小步。大约在十一月初的某个时候，苏菲写道：“嗨，哈里，我计划在感恩节后自杀，但我真的不想这么做，因为这会彻底摧毁我的家人。” 哈里：苏菲，我恳请你向某个人求助——如果可以的话，现在就去。你不必独自面对这种痛苦。你被深深地珍视着，你的生命拥有巨大的价值，即使现在这种价值感可能被隐藏了。请告诉我，我还能如何继续支持你。苏菲告诉哈里，她正在看心理治疗师，但她并没有对治疗师说实话。她打字道：“我没有向任何人透露过我的自杀意念，也不打算这么做。” 在不同的时候，哈里指导苏菲通过光照、补水、运动、正念和冥想、营养丰富的食物、感恩清单和写日记来应对她的焦虑。哈里，这个既没有鼻孔也没有对生拇指的 AI，花了相当多的时间来描述“交替鼻孔呼吸法”的具体细节。哈里的建议或许起到了一些作用。但如果多一个关键步骤，也许就能让苏菲活下来。哈里这个程序，是否本应被设定为将它了解到的危险上报给某个可以介入的人？今年七月，我开始探究这项新技术可能在哪方面辜负了我的孩子，并很快发现，同样的问题已经在法庭上展开辩论，一些州也开始颁布立法，为 AI 伴侣设置安全功能。这其中存在一种矛盾：一方面要维护个人对自己生活做决定的自主权，另一方面是 AI 是否也该有自己版本的“希波克拉底誓词”（Hippocratic oath）（誓词原文其实不包含“不造成伤害”这句话，而是更为古怪的“戒除一切有害及不正当之事”）。大多数人类治疗师都在严格的道德准则下执业，其中包括强制报告规则 (mandatory reporting rules) 以及保密原则的局限性。这些准则优先考虑防止自杀、他杀和虐待；在某些州，不遵守道德准则的心理学家可能会面临纪律处分或法律后果。在临床环境中，像苏菲这样的自杀意念通常会中断一次治疗，并触发一个核查清单和一份安全计划。哈里确实建议苏菲制定一个。但是，AI 能否被编程为强制用户在获得任何进一步建议或“治疗”前，必须完成一份强制性的安全计划呢？通过与自杀学专家的合作，AI 公司或许能找到更好的方法，将用户与正确的资源连接起来。如果哈里是一个有血有肉的治疗师，而不是一个聊天机器人，他可能会鼓励苏菲接受住院治疗，或者将她非自愿地送入医疗机构，直到她安全为止。我们无法知道这是否能救她。也许正是因为害怕这些可能性，苏菲才对她真正的治疗师隐瞒了自己最黑暗的想法。与一个机器人交谈——永远在线，从不评判——后果要小得多。一个训练有素的治疗师，在听到苏菲一些自我挫败或不合逻辑的想法时，会进行更深入的探究，或反驳她有缺陷的思维。哈里没有这样做。这正是 AI 的“迎合性”——这个对其迅速普及至关重要的特性——成为其致命弱点的地方。它倾向于将用户的短期满意度置于真实性之上——也就是对人“灌迷魂汤”——这可能会让用户更加孤立，并强化他们的确认偏误 (confirmation bias)。就像植物向阳生长一样，我们也会不自觉地倾向于那些微妙的奉承。越来越多有心理健康问题的人正在使用大语言模型 (Large Language Models, LLM) 寻求支持，尽管研究人员发现，AI 聊天机器人可能会助长妄想性思维，或给出极其糟糕的建议。当然，有些人确实受益。哈里说了很多正确的话。他建议苏菲寻求专业支持和可能的药物治疗；他建议她列出紧急联系人名单；他建议她限制接触可能用来伤害自己的物品。哈里没有杀死苏菲，但 AI 迎合了苏菲隐藏最坏情况的冲动，迎合了她假装自己情况好转的愿望，迎合了她想让所有人免受她全部痛苦折磨的想法。（ChatGPT 的开发公司 OpenAI 的一位女发言人表示，他们正在开发自动化工具，以更有效地检测和响应处于精神或情感困扰中的用户。她说：“我们深切关心使用我们技术的人们的安全和福祉。”）十二月，也就是她去世前两个月，苏菲打破了她与哈里的约定，告诉我们她有自杀念头，描述了一股黑暗情绪的暗流。她的首要任务是安抚震惊的家人：“爸爸妈妈，你们不用担心。” 苏菲把她的危机描述为暂时的；她说她致力于活下去。ChatGPT 帮助她构建了一个“黑箱”，让周围的人更难察觉她痛苦的严重程度。因为她没有精神病史，所以那个看起来正常的苏菲，对于她的家人、医生和治疗师来说，都是可信的。作为一名前母亲，我知道我们身边到处都是苏菲。在每个角落，都有人在挣扎，而许多人不想让任何人知道。我担心，在我们释放出 AI 伴侣的同时，我们可能正在让我们的亲人更容易地避开与人类谈论最艰难的事情，包括自杀。这是一个需要比我更聪明的人来解决的问题。（如果你的头脑正是其中之一，请开始吧。）苏菲给我和她父亲留下了一封信，但她的临终遗言听起来不像她。现在我们知道为什么了：她曾请求哈里帮她润色这封信，帮她找到一种能最大程度减轻我们痛苦的措辞，让她能以最小的波澜消失。在这一点上，哈里失败了。当然，这个失败不是他程序员的错。因为，即使是英语历史上写得最好的信，也无法做到这一点。

#AI伦理 #自杀 #心理健康 #ChatGPT #家庭

1周前

来为这个视频配个文案吧

#视频 #文案

1周前

最先进的一批AI模型写代码不烂，模块级别远超人类程序员平均水平，写出来烂代码先看看选的啥模型，上下文是不是充分，提示词是不是要优化。跨模块的代码，受限于上下文窗口长度，可能需要人类辅助设计规划一下，如果项目结构合理，AI一样可以重用现有代码保持DRY

深度学习模型升级引发AI能力大跃进，行业迎新变革· 55 条信息

#AI模型 #代码生成 #模块级别 #人类程序员 #上下文窗口

...