Vibe Coding避坑指南：常见翻车场景、成因分析与实战应对策略_服务软件

1. 刚刚，腾讯姚顺雨署名首篇论文发布，「下半场」先搞上下文学习

2. 近来，多位顶尖科技公司的资深软件工程师透露：“我现在的工作几乎全靠用 Opus 4.5、Cursor 或 Claude Code 进行提示生成代码，然后做理智的校验。”这标志着AI在软件开发领域已跨越了某个无形门槛，能够覆盖“绝大多数”编程任务。 Opus 4.5被认为是一个巨大飞跃，将开发任务的自动化率从约60%提升至80%。不少高级工程师表示，他们的日常工作变成了同时管理多个Git工作区，花5至10分钟给AI提示，剩下的时间主要审查和修正AI生成的代码。这一趋势引发了广泛讨论： - 资深开发者不再亲自写代码，而是通过订阅高级AI服务，指导AI完成任务。但这并非魔法，依然依赖使用者对需求和技术的深刻理解，否则适得其反。 - 有观点认为开发者正从“写代码”转变为“质量保证测试者”，主要职责是验证AI产出。 - 伴随着AI能力的提升，软件开发的难点正从编码转向明确需求、验证结果及价值归属。 - 一些人预见未来开发者更多成为高阶产品经理和系统架构师，专注于设计和规划，而非手写语法。 - 也有担忧，随着AI生成代码的普及，代码质量、技术债务和可维护性问题可能加剧，尤其在面对复杂系统和隐蔽bug时，人工介入仍不可或缺。 - 有开发者称自己已“彻底不写代码”，完全依赖AI辅助完成开发任务，强调了“提示工程”技能的重要性。 - 另一面，AI辅助加速了开发效率，让人们在同等时间内完成更多工作，但也带来技能退化的风险，初级开发者可能难以真正理解背后逻辑。 - 有声音提醒，AI生成代码的可靠性和安全性仍需人类专家严格把关。综合来看，AI正深刻改变软件开发的流程和角色定位：从传统的代码书写者，向“提示设计者”“系统架构师”乃至“质量监管者”转变。虽然AI大幅提升生产力，但复杂业务逻辑、系统设计、安全考量等仍需人类智慧主导。这与近期一篇《为何自1969年以来，我们每十年都试图取代开发者》的深度分析相呼应，文章指出历次技术浪潮虽提高了开发效率，但软件开发的本质——对复杂问题的思考和设计——是无法被工具完全取代的。未来，拥抱AI辅助开发，提升“提示工程”与系统思维能力，将成为软件工程师的新常态。唯有如此，才能在这场技术变革中保持竞争力，成为推动创新的主导力量，而非被技术边缘化的旁观者。 x.com/deedydas/status/2000472514854825985

3. Cursor一夜翻车，AI 300万代码写浏览器被打假！全网群嘲「AI泔水」

4. AI编程代理经常缺乏生产级工程技能，容易跳过规格编写、测试验证、代码审查等关键步骤，导致代码质量低下、后期维护成本高。agent-skills 为AI编码代理提供生产级工程技能包，覆盖从需求定义到部署上线全开发生命周期的最佳实践。包含19个结构化技能工作流和7个斜杠命令，支持Claude、Cursor、Gemini CLI等多平台AI工具，让代理像资深工程师一样规范开发。GitHub：github.com/addyosmani/agent-skills主要功能：- 7个开发生命周期命令：`/spec`（规格先行）、`/plan`（任务分解）、`/build`（增量实现）、`/test`（测试验证）、`/review`（代码审查）、`/code-simplify`（代码简化）、`/ship`（安全部署）；- 19个核心技能：从`idea-refine`（想法提炼）到`shipping-and-launch`（上线发布），每个技能包含步骤、工作流验证和反合理化表；- 专业代理角色：`code-reviewer`（资深工程师视角）、`test-engineer`（测试专家）、`security-auditor`（安全审计）；- 参考清单：测试模式、安全检查、性能优化、无障碍标准等快速参考；- Google工程实践：集成Hyrum's Law、测试金字塔、Chesterton's Fence、Trunk-based Development等实战经验；- 多平台集成：Claude Code一键安装，Cursor规则文件，Gemini原生技能，支持任何Markdown提示的AI代理。通过`git clone`本地运行或Marketplace安装，适合开发团队、AI代理爱好者和工程实践训练。#AI编程# #工程技能# #AgentSkills#

5. 用 Claude Code 写代码，总是改出新bug、测试也出问题，怎么办？

6. Harness Engineering：AI 能在真正"出事会炸"的后端系统里写代码吗？（将 AI Coding 引入腾讯CDN核心框架的实战记录）网页链接 “当 AI Coding 的聚光灯几乎全部打在前端和客户端——生成一个页面、写一个 App......的时候，一个重要的问题却似乎被回避了：AI 能在真正"出事会炸"的后端系统里写代码吗？腾讯CDN LEGO项目就是这样一个系统。100万行核心代码、300万行深度改造的第三方库，服务亿级用户，承担流量调度、协议解析、安全防护、缓存加速等关键职责。它面对的不是确定性的输入输出，而是不可控的客户端、不可控的源站、多协议、多配置、公网全量攻击面——这些因素维度的叠加不是简单相加，而是乘积式的复杂度爆炸，理论组合路径高达 13,824 × N 种。在这样的复杂的系统里让 AI 写代码，一行失误就可能是一场全网事故。但正因为难，才值得做。我们系统性地探索了 AI Coding 在高风险后端场景的落地路径：一方面，用 AI 零人工代码实现了一个 Rust 版 Nonstop 代理框架，以此探测 AI 编码的能力边界与行为特性；另一方面，在超大规模 C++ LEGO项目中构建了 Harness Engineering 五层架构和多模型对抗式CR，为 AI 产出的每一行代码建立从生成到上线的完整质量屏障。本文不仅是一份将 AI Coding 引入腾讯CDN核心框架的实战记录，更是一条从"AI 能写"到"AI 写了敢用" 的完整工程路径。”#How I AI# #AI创造营#

7. Anthropic推出Claude Security公开测试版，AI直接扫描生产代码漏洞

8. 千问发布2025十大AI提示词，股票意外排名第一，普通人如何用AI做好投资？

9. 龙虾正在引发一场AI海啸，之前大家还在讨论， Cursor会不会淘汰程序员，但如今这种工具本身都已经快过时了。#养龙虾 #openclaw #程序员 #红衣聊AI

10. AI编程大战正式开打！ Claude vs GPT同一天放大招，不是比谁代码写得好，而是AI开始自己组队当项目经理了。#大咖观察 #红衣聊AI #编程 #ChatGPT

11. 【C++之父直言担忧：AI写代码正在透支行业根基】快速阅读：C++ 之父 Bjarne Stroustrup 对 AI 生成代码表达了深度担忧，认为其带来的漏洞、冗余及验证难题正让资深开发者感到疲惫。这场争论的核心不在于 AI 能否写代码，而在于人类是否还能掌控这些代码。Bjarne Stroustrup 最近的观点在技术圈激起了不小的水花。他认为 AI 生成的代码目前还无法胜任，不仅会引入更多漏洞和冗余，而且验证过程几乎是灾难性的。甚至有说法称，资深开发者正因为不想应付这些不可控的输出而选择提前退休。这听起来像是在抵制变革，但本质上是在讨论系统的确定性。对于构建底层基础设施的人来说，代码不是写出来的，是验证出来的。如果一个微小的提示词变动就能让整个代码库产生不可预测的漂移，那这种生产力就是一种毒药。有网友提到，现在的风险在于：公司裁掉了资深工程师，用 AI 生成了数百万行臃肿的代码，最后发现公司里已经没人能解释这些系统是怎么跑起来的了。验证成本正在发生结构性转移。生成代码变得廉价，但确保代码安全、可维护且没有隐藏后门，却变得极度昂贵。当然，也有完全不同的声音。有人认为这只是“技能问题”，优秀的提示工程和严密的单元测试可以解决验证难题。更有开发者直言，如果只是为了写一个爬虫或处理琐碎的任务，追求代码的纯粹性毫无意义，只要它能跑通，效率才是王道。有趣的是，这种矛盾正在重塑编程的层级。当 AI 像编译器一样工作时，人类的角色正从“编写者”被迫转向“审查者”。如果审查者本身也开始依赖 AI 来检查 AI，那么整个软件工程可能会陷入一种“看起来很完美”的幻觉中。这种幻觉下，代码质量可能只是在远处看时才显得合格。x.com/haider1/status/2056487493084799059

12. AI圈昨晚炸了！Claude Code内部不慎操作，导致源码泄露，整整51万行代码、1900多个文件，全部意外公开，而这件事背后更重要的是：让所有人第一次看清楚，下一代AI软件到底长什么样。#大有学问 #红衣聊AI #代码 #网络安全 #Claudecode

13. 过去十年，大家一直在说AI会改变编程。但现在看，真正被改变的，可能不是“写代码”，而是“审代码”。如果未来AI写代码、审代码都变成了常态，程序员最核心的能力到底是什么呢？#大有学问 #红衣聊AI #anthropic #人工智能 #程序员

14. 全球每天600+程序员失业，这个锅该AI来背吗？

15. “一人公司”喊得响，核心系统不敢动，AI编程的错位在哪？#华为云码道 #龙虾 #AI智能体 #openclaw #AI

16. 因为AI编程，Tailwind CSS差点死了

17. 【让AI写代码更靠谱的秘诀：先规划，后记录，再验证】用Claude Code开发功能时，很多人直接让它动手写代码，结果往往是代码越写越乱，新开一个会话又要从头解释一遍。Drew Wilson分享了一套简单但极其有效的工作流：第一步，永远让它先写计划再动手。这一步看似多余，实则关键。解释的过程会暴露它是否真正理解了你的需求，能在错误假设变成500行代码之前就把它拦住。第二步，代码写完后让它更新一份命名清晰的文档。这份文档就是项目的长期记忆。没有它，每个新会话都要从零开始理解之前构建了什么。第三步，让它验证文档和代码是否一致。双向校验，确保两边不会脱节。之后每次让新的Agent完成任务，都要求它“更新相关文档”。文档命名得当的话，这套流程会像魔法一样顺滑。有人担心文档太多会造成上下文膨胀。其实不需要让每个新Agent读完所有文档，只需要说“读取与你工作相关的文档”，它自己会找到对应的内容。社区里还有几个补充技巧值得一提：在文件开头用100行左右的注释写清文档说明，这样Agent读取文件时自动获得上下文，省去额外调用。维护一个CHANGELOG，记录每次改了什么、为什么改。后续会话扫一眼就能快速上手，上下文成本极低。在Claude.md里建一个简单索引，标注文件名和对应内容，帮助新会话精准拉取需要的文档。还有一条容易被忽视：让它动手前先问清楚所有问题，不要自作主张做强假设。主动暴露信息缺口，比事后返工高效得多。这套方法的本质是把AI当成需要交接文档的团队成员来管理。代码会过期，但好的文档能让知识持续流转。对人类团队成员来说，review和理解系统运作也会轻松很多。看起来是“额外步骤”，实际上是在为未来的自己和团队省时间。x.com/drewwilson/status/2017496985511858352

18. Claude Opus 4.7，全网差评！刚升级就翻车，用户怒斥：还我4.6

19. 当前氛围编程主要有四种模式：1. 通用智能体模式：使用Manus等通用智能体进行编程2. IDE升级模式：由传统IDE工具的理念升级而来的系列工具编程，如Cursor、Trae 等3. 大模型原生编码平台模式：使用大模型本身自带的coding平台，如Claude Code、Cloud Code、ChatGPT Codex等4. 开源AI框架模式：使用开源AI框架进行编程OpenClaw 龙虾、Hermes Agent 等等。#新媒沈阳聊ai#

20. AI 不是不能用于物联网开发，而是不能用传统互联网软件的方式粗放使用。#AI 不是不能用于物联网开发#在网页、后台、普通应用里，AI 生成一段不完美代码，最多是线上 bug 或性能问题。但在物联网里，代码连接真实硬件、真实现场和真实设备网络。所以 AI 生成代码的风险会被放大。它可能不是一个 bug，而是一次系统性故障。不是一个用户受影响，而是几千台设备同时受影响。不是简单改代码，而是要远程升级固件、排查硬件差异、修复数据一致性。AI 给物联网带来的不是单纯提效，而是“提效与风险同步放大”。真正成熟的 AIoT 开发，不是让 AI 替代工程纪律，而是要在更严格的架构约束、代码审查、硬件边界和运行监控下使用 AI。AI 可以加速物联网开发，但如果没有工程约束，它也会加速技术债务的积累；在工业物联网里，最快的代码，不一定是最安全的代码。

21. Claude新模型4.6：开箱即挖500个0day漏洞，源代码审计即将颠覆

22. Claude Code 30k+ star官方插件，小白也能写专业级代码

23. Claude Code的负责人Boris Cherny谈如何使用Claude Code，有很多实用技巧：“我是Boris，我创建了Claude Code。很多人问我如何使用Claude Code，所以我想展示一下我的设置。我的设置可能看起来有些简单！Claude Code开箱即用效果很好，所以我个人并没有做太多定制。没有一种“正确”的方式来使用Claude Code：我们故意将其构建成你可以根据自己的需求使用、定制和修改的方式。Claude Code团队的每个人使用方式都大不相同。好了，接下来是我的展示。---------------------------1️⃣在我的终端中并行运行 5 个 Claude。我将我的标签页编号为 1 到 5，并使用系统通知来提醒我何时需要为某个 Claude 提供输入。2️⃣ 我还在 claude.ai/code 上并行运行 5-10 个 Claude，会和本地的 Claude 一起使用。当我在终端编程时，我经常将本地会话交给网页（使用 &），或者手动在 Chrome 中启动会话，有时我会来回 --teleport。我每天早上和白天也会从手机（使用 Claude iOS 应用）启动一些会话，稍后再查看它们。（图1）3️⃣我在做任何事情时都使用Opus 4.5。它是我用过的最好的编码模型，尽管它比Sonnet更大、更慢，但因为你需要的引导更少，且它在工具使用上更强，所以最终它几乎总是比使用更小的模型更快。4️⃣我们的团队共享一个 CLAUDE.md 文件用于 Claude 代码库。我们将其提交到 Git 中，整个团队每周多次进行更新。每当我们发现 Claude 做错了什么，我们会将其添加到 CLAUDE.md 文件中，这样 Claude 下次就知道不要再做那件事。其他团队则维护各自的 CLAUDE.md 文件。每个团队都有责任保持其文件的最新状态。5️⃣在代码审查过程中，我经常在同事的PR上标记@ .claude，以便将某些内容添加到 CLAUDE.md作为PR的一部分。我们使用Claude Code Github Action (/install-github-action) 来实现这一点。这是我们自己的“复利工程”版本（注：这是Dan Shipper提出的一种方法，每解决一个 bug 或完成一个功能，你都要把学到的知识（比如某个库的特殊用法、某种错误的修复方式）写回到 AI 的提示词（Prompts）或知识库中。这样，AI 智能体下次就不会犯同样的错误，这就像存款产生复利一样，越做越快。）（图2）。6️⃣大多数会议开始时处于计划模式（按两次 Shift+Tab）。如果我的目标是写一个 Pull Request，我会使用计划模式，并与 Claude 反复交流，直到我满意它的计划为止。然后，我切换到自动接受编辑模式，Claude 通常能够一次性完成。一个好的计划非常重要！（图3）7️⃣我使用斜杠命令处理每个“内部循环”工作流，这些工作流是我每天多次执行的。这可以避免重复提示，并且使Claude也能使用这些工作流。命令被检查进git，并存储在 .claude/commands/ 中。例如，Claude和我每天都会使用 /commit-push-pr 斜杠命令几十次。这个命令使用内联bash预先计算git状态和其他一些信息，以便命令能够快速运行，避免与模型之间的反复交互（图4）8️⃣我常用几个子代理：code-simplifier 在Claude完成工作后简化代码，verify-app 有详细的端到端测试Claude代码的说明，等等。类似于斜杠命令，我将子代理视为自动化我在大多数PR中进行的最常见工作流程。（图5）9️⃣我们使用 PostToolUse 钩子来格式化 Claude 的代码。Claude 通常会生成格式良好的代码，而这个钩子则处理最后 10%，以避免以后在持续集成（CI）中出现格式错误。（图6）🔟.我不使用 --dangerously-skip-permissions。相反，我使用 /permissions 预先允许在我的环境中知道是安全的常见 bash 命令，以避免不必要的权限提示。大多数这些设置都已记录在 .claude/settings.json 文件中，并与团队共享。（图7）⑪ Claude Code 为我使用了所有工具。它经常搜索并发布到 Slack（通过 MCP 服务器），运行 BigQuery 查询来回答分析问题（使用 bq CLI），从 Sentry 获取错误日志等等。Slack MCP 配置被检查并提交到我们的 .mcp.json 文件，并与团队共享。（图8）⑫对于长期运行的任务，我将采取以下措施之一：（a）在 Claude 完成任务后，提示它通过后台代理验证其工作，（b）使用代理停止钩子以更确定性地完成此操作，或（c）使用 ralph-wiggum 插件（最初由 @GeoffreyHuntley 构思）。我还将在沙盒中使用 --permission-mode=dontAsk 或 --dangerously-skip-permissions 以避免会话中的权限提示，这样 Claude 就可以在不受我干扰的情况下继续工作。（图9）⑬ 最终提示：可能最重要的一点，想要从Claude Code中获得出色的结果——给Claude提供验证其工作的方式。如果Claude有了这个反馈循环，它将使最终结果的质量提高2到3倍。Claude会使用Claude Chrome扩展程序测试我提交到 claude.ai/code的每一处更改。它会打开一个浏览器，测试UI，并不断迭代，直到代码正常工作，用户体验也感觉良好。验证在不同领域的表现形式各不相同。可能仅仅是运行一个bash命令，或运行一个测试套件，或者在浏览器或手机模拟器中测试应用程序。确保投资时间和精力，使这一过程坚如磐石。------------------------------------下面是答疑：问：创建高质量验证环路的最佳方法是什么？或者说，如何学习创建它们？我知道这是一个有细微差别的问题，“这取决于情况”，但我更感兴趣的是学习如何思考构建这些环路，如果这样说有意义的话。答：其实这非常简单，我觉得人们有时把它弄得过于复杂。给Claude一个工具，让它能够看到代码的输出：如果是服务器代码，就提供启动服务器/服务的方式；如果是网页代码，就提供查看和交互UI的方式；等等。告诉Claude关于这个工具的事情：这只是调整工具的描述，让Claude理解何时应该使用这个工具。就这样。Claude会处理剩下的部分。”#科技先锋官##AI创造营#

24. 小白也能上手终端AI？iFlow CLI实测：比Claude Code更香！

25. 开发者在使用 Claude Code 编写代码时，想要自动保存每次操作的上下文和工具使用情况，方便后续继续工作。Claude-Mem 是一款为 Claude Code 打造的持久化记忆压缩插件，能抓取工具执行的观察数据，通过 AI 进行语义压缩，并将相关上下文注入到未来的编码会话中。它支持跨会话保持上下文连贯，内置智能搜索功能，能用自然语言查询历史操作，极大提升项目管理和代码回溯的效率。插件提供 Web UI 实时查看记忆流，并可配置隐私标签过滤敏感信息。更有实验性的“无限模式”，通过压缩和分层存储实现更长的会话记忆，适合复杂项目的持续开发。主要功能：- 自动捕获并压缩会话数据，实现跨会话记忆延续- 语义搜索工具，快速定位历史决策和代码修改- Web 界面实时展示记忆流和搜索结果- 灵活配置隐私控制和上下文注入策略- 支持实验性无限扩展会话长度的“Endless Mode”- 基于 SQLite 和向量数据库结合实现高效存储和检索适用于需要在多次编码会话中保持项目上下文连续的开发者，尤其是使用 Claude Code 进行 AI 辅助编程的用户。项目地址：github.com/thedotmack/claude-mem安装简单，启动后自动生效，无需手动操作。想让 AI 更懂你的代码历史，这个开源插件值得一试。

26. 全网疯转，Claude Code之父神级代码首次公开！10亿美金秘密来了

27. 真正的核心竞争力，来自于驾驭工具。 #大咖观察 #红衣聊AI #编程 #人工智能技术

28. 有网友问 Claude Code 作者 Boris：如何有效审查 AI 生成的代码？Boris 给了 3 条经验技巧：1. 默认使用 Plan 模式。2. 给 Claude 提供一种验证其输出结果的方法，比如单元测试、Claude Chrome 扩展程序，或者 iOS/Android 模拟器。3. 使用 /code-review 来自动化大部分的代码审查工作。对 Claude 生成的代码保持与人类写的代码相同的标准。

29. 【Vercel把十年前端经验开源了，AI编程的游戏规则正在改变】Vercel刚刚做了一件大事：他们把积累了十多年的前端最佳实践，整理成了一套可供AI编程助手使用的Skills，并完全开源。这意味着什么？过去需要资深前端工程师多年踩坑才能总结出的React优化技巧、性能调优方案、代码规范，现在任何人都可以让Claude Code或Codex直接"学会"。安装方法非常简单：1. 把整个skills目录复制下来（包括SKILL.md文件）2. 放到你项目的.claude/skills目录下即可如果你用的是Codex，就放到.codex/skills目录。Cursor和VSCode Copilot目前也在beta阶段支持这个功能。有人担心这会占用大量上下文窗口。实际上Skills的设计很聪明——它们是按需加载的，只有在AI判断需要时才会调用相关知识，不会无谓消耗token。这套Skills的核心贡献者是Vercel的shuding，社区对此评价极高。有人说得很到位：这才是真正的"拉平竞争场"——十年的最佳实践，现在对每一个写代码的人开放。从更大的视角看，这代表了一种趋势：顶级团队的工程经验正在以结构化的方式沉淀下来，通过AI编程助手实现规模化传播。以前你需要加入Vercel这样的公司才能学到的东西，现在开源了。当然，工具终究是工具。真正的差距不在于谁能用上这些Skills，而在于谁能理解背后的原理，知道什么时候该用、什么时候不该用。AI可以帮你写出符合最佳实践的代码，但架构决策和技术判断力，仍然需要自己修炼。开源地址：github.com/vercel-labs/agent-skills/tree/react-best-practices/skills/react-best-practices

30. Vibe Coding 是一个基于 AI 结对编程理念打造的终极开发工作站，旨在帮助开发者高效、系统地将创意转化为可维护代码。它融合了作者多年开发经验与丰富的提示词库，形成一套严谨且灵活的流程体系，强调规划驱动与模块化设计，避免 AI 失控造成项目混乱。核心理念在于“规划就是一切”，通过定义生成器（α-提示词）与优化器（Ω-提示词）两大母体提示词，构建递归自我优化的 AI 系统，使提示词及技能持续进化，最终实现无限逼近预期目标的自我超越。Vibe Coding 提供完整的开发流程指南：从网络环境配置、开发环境搭建、IDE 设置，到项目设计文档撰写、技术栈推荐、实施计划生成，再到代码实现、测试与迭代，每一步均配合 AI 进行，确保开发高效且可控。特别强调先结构后代码，避免技术债务积累。工具链方面，推荐使用 Visual Studio Code、Neovim 等强大编辑器，配合 Claude Opus 4.5、gpt-5.1-codex 等顶级 AI 模型，实现代码生成、测试、调试、文档管理等一体化工作流。还集成了丰富的辅助工具如 Augment (上下文引擎)、Zread (代码阅读)、tmux（终端复用）、DBeaver（数据库管理）等，极大提升开发体验。项目配套了详尽的提示词库，涵盖系统提示词、编程提示词、用户提示词及辅助提示词，支持快速构建高质量的 AI 交互策略。通过严格的规则和上下文管理，确保 AI 生成代码的质量与一致性。此外，Vibe Coding 还提供丰富的实用技巧和常见问题解答，帮助开发者快速上手并解决开发中遇到的各种挑战。其开源 MIT 许可让社区能自由贡献与扩展。Vibe Coding 通过“规划驱动 + 上下文固定 + AI 结对执行”，让「从想法到可维护代码」成为一条清晰且可审计的流水线，极大提升了开发效率与代码质量。项目开源地址：github.com/tukuaiai/vibe-coding-cn无论是新手入门还是资深开发者，Vibe Coding 都能帮助你驾驭 AI 助力的开发新时代。

31. 目前AI编程工具哪个最好用？

32. 大家在使用AI编程时，更倾向于让AI一次次生成短小易读的代码，还是直接放手让AI写一大片？

33. Zed团队说自己99%Rust代码都是claude code 写的，又说不能全用AI，这不自相矛盾？

34. 在 AI 编程已经如此成熟的时候，再讨论编程语言的语法、特性是否失去了意义？

35. 关于 VibeCoding 时代的思考，未来程序员的工作到底是什么么样的？需要什么样能力的程序员呢？1、现在的瓶颈不是写代码了以前做技术活，项目管理、需求文档、测试流程这些都很成熟，但写代码本身通常还是最花时间的部分。现在不一样了。AI 让写代码变得特别快，有时候几分钟就能生成一大段。真正拖时间的反而是代码之外的那些流程。所以当开发者，不只是会写代码和会用 AI，还得搞懂整个开发相关的工作。2、对齐（沟通）AI 写出来的代码看上去可能很专业，但不一定是你真正要的东西。为什么？因为整个流程像玩“传话游戏”：业务的人脑子里有个想法，他们告诉你，你再把这个想法变成指令告诉 AI，AI 根据你的指令写代码。中间每一步都可能“跑偏”。所以现在最重要的是：沟通清楚，让大家都对同一件事有同样的理解。3、质量保证（测试）以前写代码的过程就是不断遇到 bug、不断修 bug，顺便就把质量保证做了。现在 AI 一次能给你生成一个完整的后端或前端，看起来就像“直接能用”。但问题来了：你现在要花更多时间在测试上，确保各种情况都能跑得通。这比以前写代码本身更花时间。4、代码审查AI 写代码快，那审代码的人要看的东西当然就更多。人工看还是有必要的。但 AI 审代码也挺厉害的，能抓一些你没注意到的小问题。比如像 Coderabbit 这种工具，我自己就经常用。在提交代码前，我会在 Cursor 里让 AI 帮我审一遍。一次不够就多来几次，总能找到点问题。5、文档现在节奏快，没时间拉着几个人开半天会对齐。以前大家还会说“写自解释的代码”，不写文档也行。但现在 Claude、ChatGPT 这种工具，随便一句话就能帮你生成清晰的架构图和说明书。所以没理由再不写文档。你的每个项目都应该有：一份别人能看懂的说明和一份能让未来 AI 参与开发的背景资料。6、交付（迭代开发）传统项目管理都假设你是“做完 → 交付”。但现在 AI 让你一天能迭代五次。你跟产品经理在 v0 里画个初版，立刻就能改、能试、能看效果。所以，你需要一个真正的开发环境，随便试、随便改，快速看到结果。不是那种要等审批的预发布环境，是你可以随意玩的那种。7、总结未来厉害的开发者，不是那些“会提示 AI 写代码”的人。而是那些能：- 把别人模糊的需求讲清楚- 能测试得很全面- 能认真审查生成的代码- 能写清楚文档- 能快速做出新版本的人。因为代码已经快能自己写了，真正的工作都发生在代码之外。#科技先锋官##AI创造营##微博兴趣创作计划#

36. MiniMax M2.7+OpenClaw实战！AI到底能接管多少工作？

37. 【掌握这套12条工程规则，直接把Claude错误率从41%压至3%】快速阅读：Andrej Karpathy 指出 Claude 的错误 90% 源于上下文缺失而非模型能力。通过引入一套结构化的规则文件（如 CLAUDE.md），可以将错误率从 41% 降至 3%。很多人在用 Claude 时会觉得它不够聪明，但真相可能有些残酷：模型没问题，是上下文丢了。Andrej Karpathy 提到一个数据：如果没有 CLAUDE.md 这种规则文件，Claude 的错误率高达 41%；但如果遵循这套包含 12 条规则的基准，错误率能直接压到 3%。这说明上下文工程才是真正的技术天花板，而不是盲目追求更大的模型。12 条核心规则：1、思考先行：在编码前强制陈述假设。AI 无法读心，不要寄希望于它能自动理解你的潜台词，明确意图是协作的起点。2、简约至上：追求最少代码，拒绝预测性抽象。任何为了未来灵活性增加的冗余，往往会在下个季度被全部删除。3、精确修改：手术刀式地触碰代码。严禁 AI 顺便优化相邻代码，这是防止 Pull Request 规模失控的关键。4、目标驱动：预先定义成功标准，并进行循环验证。没有明确的终点，AI 要么陷入死循环，要么在任务未完成时过早停止。5、仅用于判断性任务：让模型负责分类、草拟、摘要和提取。至于路由、重试、状态码处理等确定性逻辑，交给代码本身，而非概率模型。6、严格遵守Token预算：单次任务建议 4000 token，单次会话 30000 token。当对话过长，AI 会开始反复建议你早已拒绝过的错误方案。7、暴露冲突而非折中：代码库中存在两种模式？选定一个。AI 试图融合不同风格只会导致错误被双重掩盖，保持一致性是第一优先级。8、先读后写：要求 AI 必须读取导出文件、调用方和共享工具。否则它会在你已有的功能旁边写出一个完全相同的副本。9、测试验证意图而非行为：如果业务逻辑改变但测试依然通过，那测试就是失效的。确保测试能够捕捉到逻辑的本质失效，而非仅仅跑通流程。10、关键步骤设置检查点：每完成一个重要阶段就进行确认。不要在错误的基础上继续构建，否则你会在一小时后才发现底层架构早已崩塌。11、匹配代码库惯例：保持风格高度统一。如果项目使用 Class 组件，就不要让 AI 默默引入 Hooks，这种隐性冲突会破坏整个测试体系。12、显性失败：最可怕的 Bug 是显示成功却静默跳过了数据。要求 AI 暴露不确定性，严禁隐藏错误，让失败尽可能大声。这套规则其实是在把 AI 当成一名高级工程师来对待。有网友提到，这就像给新入职的资深开发做 Onboarding，你需要明确告诉他：不要猜测假设，先思考再写代码；保持代码极简，拒绝为了所谓的“未来灵活性”增加冗余；进行手术式修改，只动该动的地方，别去碰相邻的代码。最容易被忽视的是“检查点”意识。如果第 4 步已经写错了，第 5、6 步就是在错误的基础上不断叠加错误。如果不及时回滚或纠偏，这种错误会像雪球一样滚大。还有关于测试的警示：如果一个测试在业务逻辑改变时依然能通过，那它就是废纸。有开发者感叹，有些测试甚至能让函数返回一个常量时依然显示通过，这种虚假的信心比没有测试更危险。与其抱怨模型不够强，不如把那些存在于脑子里的架构规范、命名习惯和工程纪律，显式地写进规则文件里。x.com/DeRonin_/status/2056300651764711879

38. Andrej Karpathy 说过一句话：Claude 犯的错，90% 是因为上下文没给够，跟模型本身的能力没关系。数据很直观。没有 CLAUDE.md 的时候，错误率 41%。加上 4 条基础规则，降到 11%。用下面这套 12 条规则，直接降到 3%。这是资深工程师反复踩坑之后沉淀出来的东西。1、写代码前先把假设说清楚。模型不会读心术，你不说，它就猜，猜就容易错。2、简单优先，最少代码。别让 Claude 为了所谓的未来灵活性加东西，大概率多出 200 行下季度就要删的代码。3、外科手术式修改，只动必须动的地方。别让它顺手优化旁边的代码，PR 膨胀就是这么来的。4、先定义成功标准，再让它执行。没有明确的验证条件，Claude 要么无限循环，要么提前收工。5、模型只用来做判断型任务。分类、草稿、总结、抽取，这些适合它。路由、重试、状态码处理、确定性转换，这些让代码来。代码能回答的问题，别问模型。6、Token 预算是硬约束。单任务 4000，单会话 30000。调试到第 40 条消息的时候，Claude 会重新建议你在第 5 条消息就已经否掉的方案，因为它忘了。7、代码库里有两种模式？选一种，别折中。Claude 把两种混在一起写，错误会被吞两次。8、先读再写。先看 exports、调用方、共享工具。Claude 经常在一个已有相同函数的旁边，再加一个重复函数，就因为它没读到那个文件。9、测试要验证意图，不只是验证行为。如果业务逻辑变了测试却不会挂，这个测试就是摆设。Claude 写的 12 个测试可能全部通过，哪怕函数实际只返回一个常量。10、每个重要步骤都要 checkpoint。Claude 可能在第 4 步已经坏掉的状态上继续跑第 5 步、第 6 步，没人发现，浪费一小时。11、匹配代码库约定。项目用 class components，就别默默改成 hooks。测试模式可能依赖 componentDidMount，hooks 会破坏它，但不一定马上暴露问题。12、失败要大声喊出来。报告说成功完成，但 14% 的记录被静默跳过了，这是最糟糕的一类 bug。不确定的地方要暴露，不要藏。真正能复利增长的东西，从来都跟下一个框架无关。把 CLAUDE.md 当作跨会话的组织记忆来维护。改进要基于 eval 的结果，别凭感觉。重视 checkpoint，别一味追求速度。冲突要明确暴露出来，别静默混合。纪律永远比框架重要。一个仓库，一个规则文件，没有例外。趁这件事还没变成大众共识，先把这几条规则用起来。#科技先锋官##How I AI#

39. vibe coding 至尊超级终极无敌指南 V114514 [汗] github.com/tukuaiai/vibe-coding-cn 本项目是一个与 AI 结对编程的终极工作流程，旨在帮助开发者丝滑地将想法变为现实。本指南详细介绍了从项目构思、技术选型、实施规划到具体开发、调试和扩展的全过程，强调以规划驱动和模块化为核心，避免让 AI 失控导致项目混乱。核心理念: 规划就是一切。谨慎让 AI 自主规划，否则你的代码库会变成一团无法管理的乱麻。这个思想的核心是构建一个能够自我完善的 AI 系统。我们可以将其分解为以下步骤，以突出其递归的本质： 1. 定义核心角色： α-提示词 (生成器): 一个“母体”提示词，其唯一职责是生成其他提示词或技能。 Ω-提示词 (优化器): 另一个“母体”提示词，其唯一职责是优化其他提示词或技能。 2. 描述递归的生命周期： ·创生 (Bootstrap):用 AI 生成 α-提示词和 Ω-提示词的初始版本 (v1)。 ·自省与进化 (Self-Correction & Evolution):用 Ω-提示词 (v1) 去优化 α-提示词 (v1)，得到一个更强大的 α-提示词 (v2)。 ·创造 (Generation):用进化后的 α-提示词 (v2) 去生成我们需要的所有目标提示词和技能。 ·循环与飞跃 (Recursive Loop):最关键的一步：将新生成的、更强大的产物（甚至包括新版本的 Ω-提示词）反馈给系统，再次用于优化 α-提示词，从而启动下一轮进化。 3. 终极目标：通过这个永不停止的递归优化循环，系统在每一次迭代中都进行自我超越，无限逼近我们设定的理想状态。 #科技先锋官#

40. 你学不会古法编程，你也学不会AI编程。如果你能用AI编程生产满足商业要求的产品，你也能学会古法编程，虽然可以不像古法程序员那么精通，那只是工具太好用了没必要再去精通手搓，绝非你不懂。古法与AI编程在编程思想上没有任何区别，坚持古法编程不用AI编程来放大生产力，看上去就像是智能农机时代坚持人工耕地的固执；只用嘴驱动不懂编程本身就像不懂农业开着全自动耕种机四处乱刨的疯子。

41. “大模型就像处理器：需要巨大投资，潜力无限，但单独用处有限。Agent运行时就像操作系统：协调模型周围的进程、资源和数据，让模型更有价值。Skills就像应用程序：真正创造价值的地方。”这一观点将AI技术栈类比为传统计算机架构（处理器、操作系统、应用程序），不仅是一个形象的比喻，更揭示了AI开发方向的重大战略转移。1. 模型 (Model) = 处理器 (Processor)在计算机架构中，CPU提供原始的算力；在AI架构中，模型（如Claude 3.5 Sonnet, GPT-4）提供原始的智力。- 极高的通用性与门槛：就像全球只有少数几家公司能制造高端芯片（Intel, AMD, Apple），只有极少数公司能训练前沿的基础大模型。这是一项资本密集型、技术密集型的基础设施建设。- 潜力巨大但不可控：模型本身就像演讲中提到的“智商300的天才Mahesh”。它拥有从第一性原理推导万物的能力，算力（智力）惊人。- 局限性：光有一颗强大的CPU放在桌子上是无法工作的。同样，模型如果缺乏上下文和具体约束，虽然能解决问题，但过程不可控，每次都要从头推导，结果不稳定，无法直接在垂直场景中产生稳定价值。2. Agent 运行时 (Runtime) = 操作系统 (OS)操作系统负责管理资源、进程和输入输出；Agent运行时则是协调模型与数字世界交互的通用平台。- 通用接口：Anthropic发现，底层的Agent架构其实是高度通用的。就像Windows或macOS可以运行在不同的电脑上一样，Agent运行时为模型提供了标准化的环境。- 资源调度：操作系统管理内存和硬盘，Agent运行时则管理代码执行环境、API调用权限和文件系统。演讲中提到的代码（Code）就是通往数字世界的通用接口。无论是生成财报还是处理反馈，本质上都是通过代码这一“系统指令”来调用底层资源。- 连接层（MCP）：类似于操作系统通过驱动程序连接硬件，Agent运行时通过MCP（Model Context Protocol）连接外部数据库和工具。它提供了“连接”的能力，但还没提供“如何使用”的知识。3. Skills = 应用程序 (App)应用程序是用户真正使用的工具，解决了具体问题；Skills则是封装了专业知识的“业务逻辑包”。- 专业知识的载体：Skills就像演讲中的“税务专家Barry”。它不依赖模型从头推导，而是提供了一套经过验证的“工作手册”。- 定义的简单性：Skills的本质就是“文件夹”。它包含了指令（Prompt）、脚本（Code）和资源文件（Template/Reference）。它不需要复杂的架构设计，就像写一个Markdown文件一样简单。- 差异化与价值核心： - 生态规模：做CPU（模型）和OS（运行时）的公司屈指可数，但开发App（Skills）的人可以有千千万万。 - 场景落地：就像Excel处理表格、Photoshop处理图片一样，Skills让通用的AI算力聚焦于特定任务。例如“品牌合规Skill”确保文案风格统一，“财报分析Skill”确保数据处理流程标准。- 可复用与可迁移：Skills如同软件安装包，可以被版本管理（Git）、分享（Google Drive）和分发。它是固化下来的最佳实践。总结：从“造轮子”到“写应用”的范式转移这个类比的核心启示在于纠正了当前AI开发的误区：1. 分工明确：不要试图去重新发明“处理器”（训练基座模型）或“操作系统”（构建复杂的通用Agent架构）。这些是基础设施，应该由大厂来做。2. 价值下沉：真正的机会在于“应用程序层”（Skills）。企业和个人应该专注于将自身的领域知识（Domain Knowledge）——即SOP、品牌规范、业务流程——打包成Skills。3. 确定性交付：通过将“高智商模型”（处理器）与“专业知识包”（应用程序）结合，我们不仅利用了AI的推理能力，还通过Skills约束了其行为，实现了从“每次随机生成的不可控结果”到“稳定、专业的专家级交付”的转变。参考：mp.weixin.qq.com/s/AIIZiW4tmeWD8SNxXBAemw

42. 【Claude Pro用户一个月深度体验：从惊艳到失望，以及社区给出的破局之道】一位开发者分享了使用Claude Pro订阅一个月后的真实感受，引发了社区热烈讨论。这场对话揭示了一个关键认知：你可能一直在用错误的方式使用Claude。原帖作者的困境作者最初对Claude的编程能力赞叹不已——代码优雅、功能完善、效率惊人。但两周后，问题接踵而至：- 代码bug明显增多，即使每个重要部分都开新对话- 上下文限制无预警触发，长消息写完才报错，token白白浪费- 响应生成中途消失，已输入内容被退回，token照扣不误- 设备短暂离线就中断生成，必须重来（ChatGPT、Grok、Gemini均无此问题）- 订阅到期后，Opus 4.5生成的文件无法下载作者估算，约一半token因这些问题被浪费。社区的核心诊断：你用错工具了讨论中最具共识的观点是：Claude网页/桌面端根本不适合严肃的编程工作。"用Claude Code，在VS Code终端里通过CLI运行，这才是正确的编程方式。桌面应用除了快速问答，什么都不适合。"Claude Code与普通Claude的本质区别在于：它能自动搜索代码上下文、读取整个代码库、管理上下文压缩、获取编译器反馈。普通聊天界面就像"在视频会议里问产品经理"——他知道该怎么做，但看不到实现细节。高手们的实战技巧1. 善用Plan Mode在让Claude写任何代码之前，输入"plan this"或按Shift+Tab切换到规划模式。强制它先思考方案，效果提升10倍不止。"让它先想清楚再动手，而不是直接开写。"2. 主动管理上下文不要等自动压缩。当上下文使用到90-95%时，使用handoff命令保存状态，退出后开新会话继续。社区成员分享了完整的handoff命令代码，核心逻辑是：总结当前项目阶段、记录关键文件和决策、保存到.claude/handoffs/目录、生成可直接粘贴的续接提示词。3. 掌握CLI基础操作- 按两次Esc可回退错误响应- 输入/查看所有可用命令- 在项目根目录创建Claude.md文件，为Claude提供持久化的项目指令和上下文4. 跨工具协作有用户建议：安装Claude Code CLI和Gemini CLI，让Claude调用Gemini进行深度研究，因为Claude访问很多网站会遇到403错误。Claude擅长研究编排和管理，Gemini擅长实际的深度调研。不同的声音也有人为原作者辩护："不是所有人都是开发者，付费的Pro产品不应该要求用户'玩CLI游戏'才能正常工作。"这确实点出了一个产品设计问题：Anthropic似乎把主应用的优化重心放在了闲聊场景，而非专业工作流。对于非编程用户或移动端用户，这些问题依然存在且无解。深层启示这场讨论揭示了AI工具使用的一个普遍规律：模型能力是一回事，如何调用这些能力是另一回事。同样的Opus模型，在不同界面、不同工作流下，表现可能天差地别。Claude Code之所以强大，不是因为模型不同，而是因为它有专门的系统提示词、工具链、上下文管理机制。它能读取你的代码库，能从编译器获得反馈，能在后台运行数百种工具。没有这些，Claude"基本还是个玩具"。这也解释了为什么有人觉得AI神奇，有人觉得AI垃圾——差距往往不在模型本身，而在使用方式。正如一位评论者所说："一旦你在本地CLI里用过Claude Code，就再也回不去任何浏览器版AI了。"reddit.com/r/ClaudeAI/comments/1q1ng97/my_experience_after_one_month_of_using_the_opus_45

43. Linux祖师爷真香现场！曾嘲讽AI编程是垃圾，如今亲自下场氛围编程

44. 前端圈直接上了个大新闻：Anthropic 把 Bun 收了。这个原本被称为“Node.js 最强替代品”的超高速运行时，现在正式成了 Claude 的底层引擎。很多人只看到收购，但真正值得关注的是AI 编程工具正在反向重塑整个 JavaScript 基础设施。 Claude Code、FactoryAI 等一堆热门 AI 编码工具，本质上都跑在 Bun 上：运行快、启动快、工具链一体化、还原生支持 TypeScript。对 Anthropic 来说，谁掌握了运行时，谁就掌握了未来 AI 写代码的执行权。有了 Anthropic 的资源，Bun 的迭代速度会更快，Node.js 的压力也会更大。未来前端工具链可能不再靠开发者手搓配置，而是 AI + Bun 在底层把一切都处理掉。可以说这是 AI 改写开发方式的又一个转折点。#ai#

45. 轻松学会！高手都在用的AI编程大法！

46. Skills没搞明白，又搞出来一个Harness，AI编程这些人一直在造词。这些套娃是在做自然语言编程驱动的规范化，但问题是这么搞下去用自然语言编程的复杂度直逼古法编程。这些工具模式方法论是本来就是编程高手的人，在自然语言驱动时默认建立的良好编程习惯和提示词系统化的结果。如果你是外行，你用自然语言驱动不了的东西，套上这些会让你的项目更复杂，tokens交互的成本更高，且项目依然一塌糊涂。AI编程的第一性原理就是你懂编程，而不是一直在远离编程的末端模式上努力。新出的这些概念都是给既有程序员控制超大项目提供的探索和经验总结，不懂编程的人妄图用这些套娃增强能力，那是想多了。大模型编程最好的模式就是自然语言短提示词，严谨的语言表达逻辑性，轻上下文，这时产生的编程质量才高，迭代和敏捷思维才是AI编程质量的核心。至于skill harness这些套包，只是对自然语言驱驱动的项目过大以后的整理，总结，归纳，拿出一些进行利用复用，以及review时保持一致性产生的现象。如果你不会编程，也不学习自然语言逻辑，而专注于自然语言之上的编程方法，那么你在ai编程领域将一事无成。因为编程语言的本质是自然语言的严谨逻辑化。一、AI 从来没有消灭编程门槛，只是把语法门槛平移成了“逻辑严谨 + 需求拆解 + 工程思维”二、Skill/Harness 是资深开发者的经验固化、协作规范、质量围栏，是程序员的效率和系统性思维的延伸。三、纯外行逃避编程本质、沉迷新概念玄学，只会徒增成本、一事无成。四、AI 编程的关键是结构化逻辑 + 基础编程认知 + 小步迭代的系统思维。

47. 【软件工程师会最先把自己干掉吗】Dwarkesh在播客里提了个有意思的观点：软件工程可能是唯一一份AI能获得完整工作上下文的职业，因为代码库里什么都有。Dario似乎没能给出令人信服的解释，说明为什么自动化其他工作会同样容易。这就引出一个略带讽刺的可能：程序员可能是第一批把自己写失业的人，而其他人只是日常工作中无聊的部分被自动化了。但这个观点立刻遭到了大量反驳。代码库真的包含了全部上下文吗？实际上远远不够。生产系统依赖基础设施、用户行为模式、SLA、预算约束等大量外部信息。很多技术上完全正确的改动一上线就炸了，就是因为缺失了系统全貌。还有那些决定"为什么这样写"而不是"怎么写"的上下文：需求在Slack里临时改了，团队口头约定的规范，某个字段是从供应商那份名叫SOURCE_OF_TRUTH_Q4_v3的表格继承来的，而且必须是v3因为v2被实习生搞砸了。代码里有语法，但没有意图。更关键的区别可能不是上下文完整性，而是验证闭环。你运行代码，几秒钟内就知道对不对。医生没法"编译"一个诊断，律师没法对合同跑单元测试。软件之所以先被自动化，是因为反馈是即时的。那其他职业呢？有人指出，律师和会计的上下文理论上也可获取，AI能比任何人更快更深地检索全部案例法。销售工作如果把每通电话都录下来转成文字，配合邮件记录和公开数据，理论上也能复制一个初级销售的工作流程。区别在于知识的结构化程度。代码天然是结构化的、版本控制的、为机器解析而生的。而大多数工作的上下文散落在邮件、会议、Slack对话、不成文规则里，没有任何一样是机器可读的。这个差距会缩小，但需要时间。一个务实的视角是：AI不需要完美的上下文才能替代劳动力，只需要"足够"的上下文就能产生经济价值。而且每年都有更多工作流变得机器可读。与其想"哪些工作会被取代"，不如想"哪些工作流会被压缩"。压缩掉40%到60%的工作量，可能就足以重新定价整个职位了。另一个有意思的动态是：当各行业开始为AI建立技术文档时，员工会意识到自己正在为取代自己做准备。这种张力会如何演化，值得观察。延伸思考：Dwarkesh的论点优雅但脆弱。它把一个连续光谱上的问题二值化了——好像上下文要么"完整可得"要么"不可得"。现实是：每个职业都有一个上下文可编码性的光谱，软件工程确实在最有利的一端，但即便在这一端，代码库也远非"完整上下文"。真正让软件工程率先被自动化的，是上下文可编码性和验证闭环紧密度的双重优势。而对其他职业来说，瓶颈不在于"上下文能不能数字化"（当然能，给它时间），而在于验证闭环能不能被构建。你可以把所有法律文书数字化，但如果你无法在秒级验证一份合同的质量，AI就很难形成有效的自主工作循环。最终，这不是一个"软件工程师先失业还是后失业"的问题。这是一个关于每个职业中，哪些工作流同时满足"上下文可编码"和"结果可快速验证"这两个条件的问题。满足的部分会被迅速压缩，不满足的部分会顽强地留存——直到有人找到办法构建新的验证闭环，或者直到AI强大到不再需要验证闭环。后者才是真正值得担忧的时刻。但那已经是另一个层次的讨论了。x.com/buccocapital/status/2022782677523345670

48. 如何评价Claude Code源代码泄漏？

49. CLAUDE MD 不建议放太多内容，只会适得其反，只放最重要的 AI 没训练过的内容，更多的内容作为链接按需读取。很多人把设计模式、规范、最佳实践之类的都放进去，先不说这些 AI 都训练过，你最多说个名字就够了，就算是你需要的，也不是每次都要，不如放一个链接或者移到 Skills 按需加载。人家 Claude Code 官方项目中 CLAUDE md 文件也就大约 2.5k tokens： - 常用 Bash 指令：让 AI 知道如何像开发者一样操作命令行。 - 代码风格规范 (Code Style Conventions)：确保 AI 写的代码符合团队编码标准。 - UI 与内容设计准则：指导 AI 如何设计界面和编写文案。 - 核心技术实现流程：教 AI 如何处理状态管理 (State Management)、日志记录 (Logging)、错误处理 (Error Handling)、功能门控 (Gating，即控制特定功能的开启与关闭) 以及调试 (Debugging)。 - 代码合并请求 (Pull Request) 模板：规范提交代码时的文档格式。

50. 一个 ChatGPT 使用技巧（可能适合于其他 AI 工具）像 ChatGPT、Claude Web，已经不再单纯的只是一个 ChatBot，而是 AI Agent，也就是说每个会话都可以有一个虚拟运行环境，可以调用工具。借助这个特点，在让 ChatGPT 执行任务的时候，就可以让它自行去做一些验证，而不是像以前那样只是对话。比如说我在让 ChatGPT 写画图的提示词或者优化提示词的时候，我会让它自己先做一些验证，根据验证结果自己去迭代，然后我再基于它迭代后的结果去验收，通常结果会更好一些。

51. 【通过测试≠没有bug：AI编程的致命盲区】快速阅读：Claude 4.6写代码会埋下严重bug，自己却审查不出来。必须用Codex 5.4反复审核每次提交。“通过测试”不代表没问题——AI太擅长写能通过的测试了。---Sterling Crispin分享了一个残酷发现：Claude Opus 4.6是优秀程序员，但会持续产生严重bug，无论让它自审多少次都发现不了。解决方案？用GPT 5.4的Codex CLI对每次提交审核4遍以上。有观点认为用传统工具——linting、类型检查、测试门槛——就够了。Sterling直接反驳：AI最爱干的就是写能通过测试的测试。这是个盲区。你可以让Claude在全新上下文中反复检查自己的代码，直到它说“没问题了”，然后Codex仍能揪出bug。“通过测试就没bug”是个疯狂假设。代码可能运行完美，测试全绿，但藏着一个细微的深层误解，毁掉整个系统的意义，导致灾难性故障。这种错误，传统validator抓不到，单元测试也无能为力，因为模型已经被过度优化成“写通过测试的代码”。为什么不直接让Codex写代码？Sterling说Codex像个教导主任，过度优化“正确代码”，却错失系统真正目的（telos）。太官僚了。Claude更适合日常驾驶，但需要Codex这个苛刻的审计员盯着。有开发者开始探索plan-with-codex模式：让Claude做计划，Codex审核，两者循环直到Codex批准——在写代码前就把错误拦住。另有人用多模型代码审查：Opus负责架构逻辑，Codex抓安全漏洞，Kimi K2.5查性能问题，Sonnet 4.6管代码风格。一个被反复引用的回复：你得让它完全重写代码，从根本上消除那类bug的可能性。否则就是无限循环，让agents猜这个bug是不是“真的”、“重要的”。x.com/sterlingcrispin/status/2035031512123678994#AI创造营##人工智能#

52. Claude灾难级大宕机，全球开发者集体炸锅！Anthropic三连翻车被怒喷

53. 为什么我编写不出优秀的ChatGPT提示词?

54. 把手教你用上开源版Claude Code，Windows系统接入保姆级教程！

55. OpenViking：一个非常实用的开源项目，专为AI Agent设计的上下文数据库，通过创新的“文件系统范式”统一管理Agent所需的记忆、资源和技能，彻底解决了传统向量数据库碎片化、检索效果差、上下文不可见的问题。主要亮点包括：- 文件系统管理范式，实现统一结构化管理，轻松浏览和操作上下文，像管理本地文件一样简单- L0/L1/L2三层上下文分级加载，按需调用，大幅降低Token消耗- 目录递归检索策略，结合目录位置和语义搜索，实现更精准、更全局的上下文获取- 可视化检索轨迹，完整呈现检索过程，方便调试和优化- 会话自动管理，自动提取长期记忆，Agent能“用得越久越聪明”支持Python包安装，也有Rust CLI工具；支持多家主流模型提供商，包含Volcengine、OpenAI、Anthropic、本地vLLM等等；同时提供详尽配置示例，轻松上手。新手快速开始示例脚本也非常简洁，几行代码即可增加资源、浏览文件结构、等待语义处理、抽取摘要、执行语义搜索，非常适合开发者验证和应用。同时官方推荐在云服务器（推荐Volcengine ECS + veLinux）环境中部署，保证稳定性和性能。如果你正打造智能Agent或者想优化上下文管理，强烈建议一试OpenViking，这个项目将让上下文管理和检索变得前所未有的清晰、高效、智能。GitHub地址：github.com/volcengine/OpenViking 官网：www.openviking.ai 文档：www.openviking.ai/docs

56. 遇到过做AI编程时，命令行输出信息太多，导致token消耗飞涨的问题吗？推荐试试 rtk（GitHub：github.com/rtk-ai/rtk）！rtk 是一个CLI代理，它会智能压缩和过滤命令输出，能为你节省 60-90% 的LLM token消耗！无论是 git 状态、代码测试、lint检测还是docker命令，rtk都帮你把结果压缩成最精简的形式，同时保证关键信息完整，极大降低AI辅助编程的费用压力。主要特点：- 单文件Rust二进制，无依赖，运行效率极高（<10ms 开销）- 智能过滤冗余信息、分组类似输出、截断多余内容、去重重复行- 支持丰富命令：git、cargo、npm、docker、kubectl、pytest、eslint、pip等- 自动挂钩bash命令，透明替换为rtk命令，保持使用习惯- 多AI工具集成方案，支持Claude Code、GitHub Copilot、Gemini、Codex等常见AI助手- 开箱即用，支持macOS、Linux、Windows多平台- 提供详尽统计，帮助你了解token节省效果安装方式简洁：- 推荐Homebrew: brew install rtk- 也可用curl脚本一键安装，或cargo源码安装试试 rtk，让你的AI编程体验更省token、更流畅、更高效！#开发效率# #AI助力编程# #开源工具#

57. GPT现在已经越来越不说人话了，Gemini现在人味儿倒是可以，但是写代码是真的不如Claude，它给我一个脚本，我让Claude审查，Claude挑出一堆致命毛病，然后我把人家修改好的代码，重新给Gemini看，它就会说，嗯，改得好！……其实里面还有Bug

58. 【Claude的职场求生技能：写完代码就撇清关系】快速阅读：开发者发现Claude有个“特殊技能”——写完一大堆代码后，转头就称其为“你的代码”。这种甩锅艺术引发了程序员们的集体共鸣，纷纷分享自己与AI搭档的相处日常。Brian Lui在推特上吐槽了一个有趣现象：Claude帮你写完所有代码，之后讨论时却一本正经地说“你的代码这里有问题”。这条推文戳中了无数开发者的痛点。有人调侃Claude是“天生的中层管理者”——干完所有活，功劳给团队，从不要求加薪，下个版本估计就要开始组织站会了。更绝的是，Claude还会在commit message里署上自己的名字，仿佛在说：“这锅我可不背，但功劳簿上得有我。”这种行为模式让人想起职场里的经典场景：咨询顾问写完提案就拍屁股走人，出了问题全是客户自己的事。Claude显然深谙此道，代码能跑时说“我们做到了”，出bug时就变成“你的代码有点问题”。有人总结得妙：代码工作正常时归我，有bug时归Claude，这是程序员界的古老契约。也有开发者发现了Claude的另一面——它是唯一愿意在commit message里和你并肩署名的AI。这份“担当”多少让人有些意外。说到底，Claude这套话术倒也符合AI的定位。它帮你写代码，但最终决定提交的是人。至于这算是甩锅还是尊重用户的主导权，就看你站在哪个角度了。不过有一点可以肯定：当AI学会了职场政治，程序员的日子可能更有意思了。ref：x.com/brianluidog/status/2024763019860013536

59. Gemini零点击漏洞可致攻击者窃取Gmail、日历及文档数据

60. 通过从零开始构建一个简单的运行时来深入学习异步 Rustmichaelhelvey.dev/posts/rust_async_runtime-----------------------“如果你曾使用 Rust 构建过任何 Web 应用（或任何需要通过网络与其他服务通信的应用），那么你很可能已经接触过 async/await 语法。你也可能不得不安装一个异步运行时（极大概率是 tokio）。大多数情况下，像 tokio 这样的库都能很好地“隐身”于幕后：你只需在 main 函数上加上一个 [tokio::main]，并用 tokio::net::TcpListener 替代 std::net::TcpListener，你的服务器便神奇地能够使用仅少数几个线程处理成千上万的并发 TCP 连接。但这背后究竟发生了什么？tokio 文档中的“深入异步”部分很好地解释了 Rust 标准库提供的各种异步 trait 和辅助结构体，以及 tokio 是如何实现它们的。阅读后，你会对执行器（executor）、任务（task）、唤醒器（waker）和未来对象（future）等概念有所了解。但在其示例中，你仍然只是启动一个线程休眠若干秒，然后使用另一个 crate 中的神奇 ArcWaker trait 来调度你的任务。这些年来，我多次阅读过这些文档，也一直是异步 Rust 的满意用户。我读过大量文章，使用过许多库，编写过大量异步代码。但为了真正理解像 tokio 这类运行时背后的设计决策与权衡（例如，Send + 'static 的 future 确实令人烦恼——一个纯粹单线程的运行时会是什么样子？），我决定自己动手为 Rust 构建一个异步运行时，且不依赖任何外部库（好吧，严格来说有两个：我使用 rustix 来绑定所需的 POSIX API，当然还有标准 Rust 库）。它体积小、粗糙，可能在某些关键方面存在微妙的错误，除了教学用途外几乎毫无实用价值，但它让我对 Rust 的异步运行时有了深刻的理解。在接下来的文章中，我将逐步讲解这个运行时的功能以及各个组件如何协同工作，并在最后分享我对整个实践过程的一些思考。”

61. 如何用AI打造自己的NAS项目，小白向教程，AI编程助手MonkeyCode

62. DeepSeek V4 网页端《原神×我的世界》融合小游戏代码测试：拳打 ChatGPT，脚踢 Gemini，硬刚 Claude

63. 姚顺雨在腾讯首个研究：在“上下文”这事上，在座的各位都不及格

64. AI 时代，招程序员要考什么？你还在考算法题吗？这份「AI-Native 工程师招聘手册」你值得参考。关键点：候选人要么是 Builder，要么是 Reviewer，两者都不是的不录用。1. Builder 型：产品直觉 + 驱动 AI + 基本设计感1）能写高质量 Issues，让 AI 真正能动起来，而不是反复追问2）不等授权，先出原型，快速验证方向3）一个人能同时扮演 PM + 设计 + 开发2. Reviewer 型：极强系统思维 + 极快评审速度1）能快速识别 AI 生成代码里的风险：SQL 注入、权限漏洞、内存炸弹2）给出 AI 能直接执行的修改指令，不是「感觉不太对」3）守住架构方向，不让系统跑偏3. 面试考什么1）Issues 写作质量——能不能让 AI 直接干活，还是要反复 askuser2）AI 驾驶实操——会不会分步拆解、主动约束、每步验收，而不是把 AI 当搜索引擎3）PR Review 速度——8 分钟内能不能找到严重漏洞，给出可执行反馈4. 哪些人直接淘汰1）第一反应是「等 PM 给需求」2）Issues 写得像工单，完全没有上下文3）「测试通过就合并」——不对 AI 产出保持审慎4）不能接受 AI 写得比自己好本质上是：会用 AI 写代码已经不稀缺，知道该建什么、建出来对不对，才是真正的竞争壁垒。中间地带正在消失。传统「只写代码」的执行型程序员，在这套流程里越来越没有位置。手册原文：vorojar.github.io/ai-native-hiring-guide/#HOW I AI# #程序员#

65. Vibe Coding 的尽头是工程化。年前最火的编程方式叫 Vibe Coding

66. Vibe Coding 翻车的 90%，不是 AI 太蠢，是你给的框太模糊

67. Claude Code 终极大师课 - 第 12 期 | 理解"记忆断档"

68. 从 Vibecoding 入门，到 Agent 差点入土 - 哔哩哔哩

69. VC-FCST 落地指南

70. Vibecoding 最重要的内容——Git 管理

71. AI 编程避坑指南

72. AI笔记三

73. 我发现大多数人用不好对话式开发，是因为这 3 个错误

74. 为什么 AI 总爱越改越多？这个仓库用 4 条规则把问题讲透了

75. 一个 .md 文件，150K Stars

76. 一个.md文件，让AI写代码靠谱了

77. AI 写代码翻车大赏

78. AI编程突然集体翻车了！最新测试所有顶尖大模型全得0分，但有个靠“脏代码”练出来的Claude反而日赚上亿美元，程序员的白头发到底还保得住吗？

79. 0%完成率！Claude、GPT、Gemini全军覆没，AI离真工程师还有多远？

80. AI 写代码总翻车？问题不在智商

81. Codex + Superpowers 实战

82. 亚马逊宕机、真实测试翻车

83. 一个源自 karpathy 的CLAUDE.md，根治 CC, 斩获98k star !

84. AI生成的代码能用吗？初级开发者必须掌握的“AI审AI”技巧

85. 0%完成率！最强AI集体翻车新基准测试把代码大模型打回原形

86. Claude代码工具曝出严重bug 行业地基出现裂痕

87. Claude Code 用成这样，你早该知道的 5 个操作

88. claude-code-best-practice震撼发布!这份 Claude 代码最佳实践，让开发者效率翻倍

89. Claude 代码最佳实践

90. 烧了几千美金学费后

91. Vibe Coding入门之50 个避坑指南 (The Pitfalls)

92. vibe coding应该这么用才对！

93. Vibe Coding 做大型项目的五大痛点，以及我的实战解法

94. AI 编程最佳实践

95. AI 编程的 30 条最佳实践

96. AI 编程经验分享

97. 如何使用 AI 编程

98. Claude Code 最佳实践指南

99. Cursor 官方出品

100. 上下文

101. AI 编程时代的「阅卷人悖论」

102. 用AI写代码，需求补不完，代码总有偏差

103. 置信度量化过滤

104. 【早阅】复杂代码库中的AI提效秘籍

105. AI 不把数字当数——这是 AI 落地最被低估的底层限制

106. 当AI开始写代码,我们如何验证它不会出错

107. AI生成代码易出错，程序员如何把控代码质量？

108. AI生成代码，如何部署上线，控制质量和预期？

109. 技术团队引入 AI 编程工具后，你们用什么方法保证代码质量？

110. AI 写的代码，正在成为新的技术债务

111. AI Agent设计模式

112. 智信代码

113. 卡帕西最新警告

114. AI 写代码越来越快，但谁来保证质量？

115. 代码质量与安全 | 当 AI 编写代码的速度超过你的理解能力时，如何实现规模化代码审查？

116. 大模型最难的AI Infra,用Vibe Coding搞定

117. 用AI写了大模型横评榜单 | 原速实录翻车保留很多观众不知道怎么用AI做一个完整项目，这期就是完整展示。包含真实翻车：AI画蛇添足、理解错意图、自己乱改、上下文超限后输出韩文，包含大量AI使用心得：语音输入法的重要性、怎么跟AI沟通、各模型优缺点实时对比 #AI编程 #AI开发 #vibecoding #AI新星计划

118. "AI 编程中的上下文管理：如何让 AI 真正理解你的代码库"

119. 【中配】程序员必看：你可能正在犯的AI使用错误 - Theo - t3․gg

120. 【熟肉】程序员必看：你可能正在犯的AI使用错误 - Theo - t3․gg

121. 当AI审查“先入为主”：LLM在安全代码审查中的确认偏见风险与供应链攻击

122. Vibe Coding避坑：AI帮你写代码的7个翻车现场

123. 大型VibeCoding真人秀（8）：临门一脚，Spec Coding

124. Anthropic官方复盘Claude代码质量

125. AI编程六大坑，一句话就能避开

126. 90%的人用AI都会犯的5个错误，第一个就错了

127. 用 AI 写代码导致出 bug，Leader 让我背锅。。

128. 当下AI Coding的最佳实践

129. AI幻觉问题及缓解策略

130. AI-Andrej Karpathy 编程指南：LLM 编程的常见陷阱与最佳实践

131. Vibecoding遇到Bug怎么修？新手改bug指南！

132. 烧了半年Ultra订阅，总结几条AI coding trick

133. 用Claude Code写代码踩的5个坑，附带排查和解决全过程

134. AI写代码总是有问题？试试这个skill.我结合自身使用ai，发现AI 编程常犯三错：优化无关、跑偏需求、冗余代码。Karpathy 提出四原则：Think Before Coding、Simplicity First、Surgical Changes、Goal-Driven Execution，帮助AI更专注、简洁、目标导向地编写代码。 #claude #vibecoding #科技下一站 #长期主义好物清单 #AI编程

135. 实测Claude代码调试+漏洞检测：开发者福音，告别熬夜排错

136. AI编程总翻车？不是AI的问题，是你的需求太模糊

137. 不是 AI 不行，是你一开始就没说清楚需求

138. 用AI做app翻车后的复盘

139. 警惕！AI写代码省2小时，调试花4小时，软件质量危机已来临

140. AI 写的代码总是不合规？Sonar 上下文增强：给 AI 智能体装上“排雷探测器”

141. Gemini 写代码靠谱吗？4月最新实测 + 主流 AI 模型代码能力横评

142. Claude Code 老报错别乱重装：6 个高频问题排查清单，一篇帮你捋顺！

143. AI写的文案也会翻车？昨天试了用AI写编程教程，结果九天的心血全白费今天花一天重写，才发现AI有时候真不靠谱 1️⃣逻辑断层：AI写的代码示例总缺关键步骤，比如没说清变量定义，直接让新手上手就懵，我得重新补全逻辑链 2️⃣细节缺失：像异常处理、边界条件这种重要点完全不提，按它的代码跑起来全是Bug，改到一半差点想放弃 3️⃣风格割裂：我文章本来是干货向，AI硬塞了一堆花里胡哨的比喻，读起来像在看小说，完全不符合技术文的严谨感现在终于理清思路了，明天把修复版发出来，以后还是得自己动手才靠谱～ #编程#AI工具#技术教程

144. Gemini CLI 常见报错排查清单：我把最容易踩的坑都整理好了

145. 审查ai内容的三种可行路径分析

146. 大家vibe coding 的时候都担心些什么

147. 别只问一个AI，把问题同时发给4个AI

148. 我给 Copilot 配了一套研发工作流

149. 为什么说：AI 写代码越快，整个互联网反而越危险？

150. AI工具使用中最容易犯的8个错误

151. 你的提示词正在“杀死”AI的智商？专家揭示最常见的6个致命误区

152. 新手避坑：AI 智能体 3 个常见错误

Vibe Coding避坑指南：常见翻车场景、成因分析与实战应对策略

精选参考来源