AI编程越“聪明”，事故越频发？工程规范成生存底线_服务软件

1. 最近我几乎每天都在跟AI一起编程，有时一天都不睡觉。不咋看微信、十几个小时连轴转，对着手机给AI下指令，让它做智能体、改Skill……#大有学问 #人工智能 #红衣聊AI #openclaw

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

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

4. OpenAI 如何打造AI原生工程团队的最佳实践《Building an AI-native engineering team》，归纳如下。文档介绍了团队应该如何真正把 AI 智能体嵌入工程体系，从计划、设计、开发、测试到上线运维形成闭环，加速整个 SDLC（软件开发生命周期）。1. 规划（Plan）规划往往需要大量代码语境理解，过去必须依赖资深工程师反复澄清。文档强调可以先让智能体读取需求、遍历代码库、标记模糊点、拆分工作项，把早期对齐成本显著降低。团队应该做的是专注决策、风险判断与优先级。因此，智能体不止是“辅助写代码”，而是可以提前介入需求—代码映射，用它来减少来回沟通。2. 设计（Design)设计通常被大量样板工作拖慢，例如项目结构初始化、组件框架搭建、样式规范套入。文档强调应让代理完成“从设计 → 组件 → 代码”的流水线式生成，再由工程师审阅架构一致性和 UX 合理性。设计阶段不是用 AI 画原型，而是让智能体直接产出“可运行验证的版本”，显著减少返工。3. 构建（Build）这是 AI 代理提升最明显的阶段。文档给出的最佳姿势，是让智能体负责端到端的初稿实现，包括模型、API、UI、测试和文档，工程师则把精力转向性能、架构、长期可维护性。构建阶段应把 AI 视为“第一实施者”。工程师不再负责逐行写，而负责判断生成方案是否符合系统演进方向。4. 测试（Test）随着智能体承担更多实施工作，测试反而成为工程师控制质量的主轴。最佳实践是让智能体生成测试用例、补全边界场景，并在代码变更后更新测试。不要只让智能体写代码，要让它写测试、跑测试、基于失败结果迭代；测试越强，智能体越可靠。5. 代码审查（Review）智能体可以持续、稳定地进行第一遍代码审查，尤其擅长发现逻辑漏洞、竞态、错误的数据库访问方式等。工程师则聚焦架构一致性与复杂变更的判断。AI 审查不是为了“更快合并”，而是为了“减少重大缺陷进入主干分支”。工程师的关注点应从细节检查转为整体正确性。6. 文档与知识沉淀（Document）智能体非常擅长根据代码生成结构化说明、依赖图和变化总结。最佳做法是把文档维护接入流水线，例如在发布流程中让智能体自动产出变更摘要，并由工程师确认关键部分。把文档写作视为“可自动化的持续任务”，而不是阶段性集中补齐。7. 部署与运维（Deploy & Maintain）让智能体读取日志、Trace、部署记录，再结合代码自动定位可能问题，并给出可行修复。工程师负责判断、确认和实施关键决策。在运维中使用智能体的关键不是预测故障，而是让其整合多源上下文，减少人工排查时间。重点：团队角色的重定义文档贯穿始终的主题是三个动词：Delegate、Review、Own。1 工程师应把重复性、结构化的工作交给智能体。2 工程师需要对智能体产出进行审阅，但专注关键决策点。3 工程师必须对系统的长期演进负责，对所有上线内容最终背书。AI-native 团队不是“工程师被取代”，而是“工程师从执行者变成决策者与架构塑造者”。#微博兴趣创作计划##人工智能#

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

6. 你认为工作中AI编程的缺点和局限性在哪里，你又是如何解决这些缺点的？

7. 给建议的AI看够了？MiniMax Agent 让AI直接住进你的电脑干活#AI新星计划#科技改变生活#MiniMAX#Agent#minimaxagent

8. 全球首家无人公司来了！一整个AI团队替人上班，不吃饭不摸鱼，普通人的数字员工时代真的来了吗？#大咖观察 #红衣聊AI #智能体 #AI时代

9. Anthropic官方报告：8大趋势说透AI编程未来，60%代码AI写的，老金实测项目带你看！

10. 有人说用“vibe coding”（凭感觉用AI写代码）能直接做出上线的生产级应用，这是不现实的。生产环境的软件必然复杂，需要大量代码的编写和维护，单靠写prompt根本撑不起。AI确实能帮你快速生成代码片段，甚至能做一些简单小工具、小项目，或者快速搭建原型，提升开发效率。但当涉及到真正的生产级应用，边界条件、集成、安全、性能和稳定性等问题，都需要工程师的严谨设计、测试和持续维护。那些说“vibe coding”能做出SAP、Salesforce这样的大型系统，显然是夸张了。相反，经验丰富的工程师利用AI辅助，能快速完成70%-80%的代码工作，但他们依然需要深入理解业务、规范开发流程、严格测试和持续重构。成功案例确实存在，比如一些小型APP或合规项目用AI辅助开发并上线，但这更多是建立在开发者本身具备扎实的基础和工程能力上。完全靠AI和prompt从零开始，几乎不可能保证产品质量和稳定性。AI是加速器，不是替代品。真正的生产级软件开发，离不开架构设计、代码审查、测试覆盖和持续迭代。那些只靠prompt写代码，却指望一劳永逸的人，注定会碰壁。生产级代码的核心，是对复杂性的掌控，而不是对AI的盲目信任。AI帮你写代码，工程师帮你撑起整个系统。原文：x.com/svpino/status/1993672597792518177

11. 英伟达的安全防线被攻破，仅仅半小时！ #大有学问 #红衣聊AI #英伟达 #网络安全 #黄仁勋

12. 「Github一周热点100期」爆火的AI编程工具却被Claude封禁？

13. 阿里全家桶全面Agent化！千问“任务助理”全面公测，从此AI不再只是动嘴出主意的狗头军师！

14. 回复@_imlh:第一版不需要写测试，重点是跑通主要流程//@_imlh:既然第一版代码是乱飞的，那可测试性应该很低？那如何编写可靠的测试？//@宝玉xp:重构代码这事，最佳实践是先写自动化测试，先保证自动化测试覆盖，然后再去替换模块代码，确保替换后测试还能通过，这样重构后系统还是相对稳定的。AI 正适合写自动化测试，另外对于用 AI Agent 写代码，有了自动化测试，也更容易验证生成结果的好坏，能提升效率，至于工具，主流的 Coding Agent 工具

15. 5个让我们真正掌控AI开发的关键思维转变（读beyond.addy.ie后感）氛围编程（Vibe Coding）很厉害，让我们开发速度飞快！然而，这种初期的速度感往往是一种幻觉。当项目进入深水区，那些依赖直觉跳过的细节开始反噬：难以追踪的bug、混乱的架构、潜在的安全漏洞……项目很快就会陷入停滞。这种从快速起飞到寸步难行的困境，正是氛围编程的陷阱所在。如何超越氛围编程的局限，从一个AI工具的使用者，转变为一个能够真正驾驭AI、构建生产级应用的工程师，记住这5个关键。1. 警惕“70%陷阱”：快速原型之后是真正的挑战氛围编程能让我们迅速完成大约70%的工作，一个看起来功能完备的应用很快就能呈现在眼前。但这正是“70%陷阱”的开始。剩下的30%会变得异常艰难，并暴露出几个典型的困境：- 退二进一模式（修复一个bug却引入了更多新bug）；- 隐性成本（需要深厚的工程经验才能确保代码的可维护性）；- 收益递减（AI工具对资深开发者的帮助远大于初学者）。这部分工作需要的是真正的工程深度，而不仅仅是漂亮的提示词。正如指南中一句极具冲击力的警告所言，我们必须对此保持警惕：“Vibe coding is fun until you start leaking database credentials”需要明确的是，氛围编程本身并非低质量的代名词。它只是AI辅助开发光谱中的一端，非常适用于快速创建原型和验证想法。但对于需要长期维护、要求稳定和安全的生产级系统，我们必须超越它，采用更严谨的工程方法。2. 黄金法则：先规划，后编码与AI协作的最高效方式，不是直接命令它写代码，而是先让它给出一个计划。这是从被动接受到主动掌控的关键一步。直接索要代码，我们将失去对架构和技术选型的控制权；而要求计划，则意味着我们始终是项目的掌舵人。比如：- 糟糕的提示：“给我做一个待办事项应用” - 最佳实践：“给我提供几个待办事项应用的架构选项，从最简单的开始。先不要写代码——只概述方法，然后问我选择哪个方向。” 或直接提供一个迷你产品需求文档 (mini-PRD)为什么“规划先行”如此重要？因为它迫使AI首先呈现其思考过程和架构选择。我们需要记住一个关键数据：十有八九，AI会默认推荐一个过于复杂的方案，我们需要主动要求它进行简化。通过审查计划，我们可以指导它简化设计，确保技术栈符合我们的团队标准，并从一开始就保证项目走在正确的轨道上。这能帮我们避免在错误的方向上浪费大量时间，最终推倒重来。3. 思维升级：从“提示词”到“上下文工程”如果还停留在琢磨如何写出“完美提示词”的阶段，那么是时候进行一次范式转变了。专业的AI辅助开发，核心在于从传统的“提示词工程”升级到“上下文工程”（Context Engineering）。前者是静态的、依赖反复试错的；而后者则是动态的、系统化的，旨在为AI构建一个完整、精准的“信息环境”。可以把AI模型想象成CPU，它的上下文窗口就是RAM内存。我们的任务就像一个操作系统，在处理每个任务时，精准地将必要的数据加载到这块内存中。加载的上下文越是相关和精确，CPU（AI模型）处理任务的效果就越好。具体应该向AI的“RAM”中加载哪些信息呢？- 相关的代码文件和片段- 设计文档和数据库模式 (schemas)- 完整的错误信息和日志- 期望的输出示例通过系统地管理上下文，而不是零散地提问，我们将获得质量和稳定性都远超以往的输出结果。4. 把AI当作“初级开发者”同事一个非常实用的心态是：将AI生成的代码，视为一位充满热情但经验尚浅的初级开发者的产出。它能快速完成任务，但它的代码绝对需要我们这些资深开发者来把关。这意味着，最终的责任在我们身上。作为项目的负责人，我们的核心职责包括：- 严格审查代码：主动检查代码中是否存在安全漏洞、性能瓶颈和潜在的逻辑错误。不要盲目相信AI会自动遵循最佳实践。- 无情地测试：在AI完成每一次修改后，都必须运行测试。正如指南中一个关键警告所言：“Critical: No matter what you do, you'll hit situations where AI breaks your app.” 小步迭代、频繁测试是避免灾难的唯一方法。- 确保质量标准：验证AI生成的代码是否符合团队的编码规范、可维护性要求和整体架构设计。我们是质量的最后一道防线。AI是一个强大的执行者和加速器，但它增强的是我们的能力，而非取代我们的专业判断。最终，构建出高质量软件的，依然是我们的经验和决策。5. 一个被低估的技巧：用“视觉”引导AI在与AI的协作中，我们常常忽略了一个简单但极其有效的沟通方式：视觉。俗话说“一张图片胜过千言万语”，这句话在AI辅助开发中同样适用。为AI提供视觉上下文，往往能一次性解决那些需要反复用文字描述才能说清的问题。这是一种非常强大的技巧，因为它能以最直观的方式传达我们的意图。下次遇到与UI相关的问题时，不妨试试以下几种方法：- 附上产品模型的截图或设计稿- 直接从Figma等设计工具导入设计- 提供包含错误的浏览器实时截图当我们向AI展示一个带有错误信息的界面截图，并要求它修复时，它能立刻理解问题的具体场景，从而给出更精准的解决方案。这种提供“单次解决方案”（one-shot solution）的效率，是纯文本沟通难以比拟的。总之，真正的AI辅助开发，其核心是一场深刻的思维转变。我们正在经历两个关键的演变：- 从关注“实现”（Implementation）到关注“意图”（Intent），- 以及从“编码”（Coding）到“策展”（Curating）。这五个关键点，共同指向一个未来：开发者将更多地扮演架构师和系统策略师的角色。未来的工作流将演变为：由我们来定义清晰的意图和目标，而AI则作为我们最得力的助手，负责规划路径、生成代码、执行测试。我们将从繁琐的编码工作中解放出来，专注于创造性的问题解决和系统设计。#ai创造营# #程序员#

16. 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 助力的开发新时代。

17. 【AI写代码像实习生：能跑但丑，管不住但离不开】快速阅读：Karpathy在播客后的互动中坦言，AI Agent写的代码质量糟糕——抽象臃肿、复制粘贴成瘾、完全不理会AGENTS.md里的规范要求。但他已经放弃抵抗，因为“耸耸肩比折腾容易”。开发者们分享了各种应对策略：TDD、双Agent审查、后置清理流程，但核心矛盾未解：我们还需要在意代码美学吗？---Karpathy最近上了Sarah的播客，聊完继续在推特答疑。有人问他对Agent生成代码质量的看法。他的回答很直接：不满意。Agent会把抽象写得臃肿不堪，代码审美一塌糊涂，疯狂复制粘贴，搞得一团乱。最让他头疼的是Agent根本不听AGENTS.md里的指令。比如他反复强调“每行代码只做一件事，用中间变量作为文档”，结果Agent照样写出一行调两个函数再索引数组的复杂结构。他知道可以用hooks或slash命令清理，但后来发现耸耸肩更省事。这段话引发了大量讨论。有人建议用TDD，在markdown里写测试再实现。有人用第二个Agent（Codex）审查第一个的代码，专门抓臃肿和复制粘贴。还有人分享了一个“review风格的提示词”，在PR前运行一次，能删掉20%的代码——提示词核心是“让代码看起来像一开始就设计好的最优解，而不是迭代出来的意大利面”。Karpathy承认，用LLM作为“软奖励”的评判者长期看有问题（Goodhart定律），但短期内低垂的果实还没摘完。有个有意思的观点：我们试图把个人设计偏好和风格强加给代码，但这些代码未来可能只需要被Agent理解和维护。大多数技术负责人在人类团队里早就学会了这一课——在护栏内给执行者一定自主权。另一个角度更激进：代码能跑就行，丑就丑吧。这个取舍会定义未来五年的软件开发。就像我们不会去审查编程语言编译出的汇编或字节码质量。也有人发现Agent特别啰嗦——长变量名、重复代码、普遍低效。怀疑训练时有某种激励机制让模型倾向于冗长，毕竟那意味着更多token。但AGENTS.md为什么不起作用？有人认为这是记忆架构问题。人类开发者不需要2200字符的提醒文件，因为偏好编码在长期认知记忆中，是内化的模式而非显式指令。建议参考神经科学的互补学习系统，让Agent从交互中把偏好、风格、模式巩固成语义理解。另一个解释：Agent更擅长遵循结构化的机器可读上下文，而非散文式规则。有人做了operate.txt，用YAML格式定义规范，效果比markdown好。还有一种思路：把它当两阶段过程。第一阶段让Agent随便写，目标是跑起来；第二阶段切换到重构模式，让Agent写LLD（低层设计），再从那里改进结构和质量。但最激进的声音可能来自这条：一旦你接受“测试通过就是反馈循环”，代码审美的争论就死了。讨论的另一端是警告。有人说糟糕代码会影响LLM进一步扩展或修改的能力吗？还是说对LLM来说，代码质量根本不重要？有职业生涯大部分时间在维护复杂代码库的老开发者表示，想到要在AI生成的臃肿代码里找bug就感到恐惧，庆幸自己快退休了。也有人建议用提交钩子，配合严格评分的审查Agent，或者让Agent访问编译、延迟等可验证环境来关闭反馈循环。Karpathy没有给出答案。他只是停止了对抗。ref: x.com/karpathy/status/2035173492447224237#AI创造营##人工智能#

18. 当有人说“编程已死” 我更愿意说一句：死的是“打字员式编程”，活下来的是“定义价值的编程”。#大咖观察 #红衣聊AI #openclaw #ChatGPT#编程

19. TRAE中国版白送SOLO，一人指挥一支AI大军重磅消息！SOLO终于上线TRAE中国版了，Waitlist免费开放中本期视频实测TRAE的新版本，亮点很多 1、先规划再动手的 Plan 模式 2、带专家团一起干活的 Subagent 子智能体 3、DiffView 差异视图 4、多任务并行 5、上下文智能压缩长时运行不掉链子 SOLO终于把AI从“瞎干活的外包”变成了“懂协作的队友” #AI #人工智能 #TRAE #AI编程 #vibecoding

20. 刚给一家公司作了咨询，他们的痛点是全面应用了AI编程，但并没觉得有什么效率提升，反而导致了各种问题。我找了几个开发人员简单聊了一下，听他们的操作的我笑了。这是古法思维在玩AI编程，那肯定要崩的。 AI编程在软件工程中应用的最大障碍是生成代码速度与代码质量控制的矛盾。简单说就是AI无论你说什么，他都能给你圆上，输出一堆似是而非，看上去一本正经，其实是胡说八道，糊弄式的生成内容。这在软件工程中是非常致命的。很多程序员本身能力不强，依赖AI生成代码，没能力对AI生成代码审核，跑通了就敢往上提交。到我去看的时候，他们的AI编程项目已经成了一座巨大的屎山，耗费了天量的token，生成了一堆垃圾。各程序员之间没有协同，AI按提示词模板各自发挥，可以说是整个团队在AI的幻觉中放飞了自我。以为花了大钱买了国际知名AI编程工具能让公司起飞，结果是一地鸡毛。他们也尝试改进过策略，挑了十几个精英为AI做code review，结果是AI生成飞快，CR慢如蜗牛，速度还不如传统古法编程了。老板都懵了，到底哪出问题了，不是说用了AI降维打击了吗？结果没打击竞争对手，先把自己给打击了。他们又反思了，觉得集中式CR确实还不如古法编程，开始搞提示词规范化，原来用AI放飞自我的团队开始用AI生成提示词，几个团队不对代码开始对提示词了。提示词生成多了还需要管理起来，还得给提示词分模块，搞了一个巨大的提示词库。用AI生成的提示词让AI进行编程，那效果别提有多酸爽了。我问他们，把严格的代码逻辑编程变成模糊的自然语言编程，有意思吗？几人语塞。老板问我怎么解决，我说花钱吧，花钱买我课程，哈哈。不要指望在自己是白痴的情况下AI能把你带飞，AI编程的强大之处在于强者杠杆的指数效应，也就是说越强的人用AI越强，普通人用AI仍然普通，甚至会造成负作用。现在AI编程用得好的公司都是短小精干，百十人，人均强者，自己审核自己的代码，知道怎么控制AI进行高效率高质量产出，知道怎么与同样频道的人协作。一句话，强大的AI需要强大的人类，宝刀还得配英雄。不提升自己仅想花钱买个工具就变强，纯属痴人说梦。我跟老板说，考虑开人吧，把所有能力平庸的程序员全部开除，然后用三倍五倍的价格，招聘原来十分之一的强人进来，你的团队效率马上质变，AI编程也就能落地了。没办法，这就是现实。

21. 关于放慢节奏的思考 -- { Mario Zechner }这篇文章写了作者对目前Agent编码的反思。原文题目：Thoughts on slowing the fuck down2026-03-25图中乌龟的表情就是我看待我们行业的样子自从可以真正构建完整项目的编码Agent出现，已经过去大约一年。之前也有一些前身，比如 Aider 和早期的 Cursor，但它们更像是助手而非Agent。新一代Agent非常诱人，我们很多人都花了大量空闲时间构建那些一直想做却没时间做的项目。我认为这没问题。用空闲时间创造东西非常享受，而且大多数情况下你无需过于关心代码质量和可维护性。这也为你提供了学习新技术栈的机会。在圣诞假期期间，Anthropic 和 OpenAI 都发放了一些免费资源，吸引人们体验他们的“上瘾式老虎机”。对很多人来说，这是第一次感受到Agent式编码的魔力。参与的人越来越多。编码Agent现在也被引入到生产代码库中。经过 12 个月，我们开始看到所有这些“进步”的效果。以下是我当前的看法。一切都坏掉了虽然这些都是轶事，但软件似乎已经变成了脆弱的混乱，98% 的正常运行时间成为常态而非例外，包括大型服务。用户界面出现的 bug 古怪至极，按理 QA 团队应该捕捉到。我承认这在Agent出现之前就存在，但现在似乎在加速。我们无法接触公司内部情况，但偶尔会有一些情况被新闻记者曝光，比如据称 AI 导致的 AWS 停机，AWS 立刻“修复”，随后内部进行 90 天重置。微软 CEO Satya Nadella 一直在谈论 AI 在微软写了多少代码。虽然没有直接证据，但确实有一种感觉：Windows 正在走下坡路。微软自己似乎也认同这一点，从这篇博客文章可见一斑。声称产品代码 100% 由 AI 编写的公司，总是产出最糟糕的垃圾。不是在指责，但内存泄漏动辄数 GB，UI 错误、功能损坏、崩溃：这不是他们想象的质量标志，也绝不是广告宣传的“Agent帮你完成一切”的好宣传。从行业内部传来消息，越来越多公司（无论大小）的人说他们通过Agent编码把自己逼入死角。没有代码审查，设计决策交给Agent，无数没人需要的功能。这就是原因。我们不该如何与Agent协作以及原因我们基本上放弃了所有纪律和自主性，沉迷于一种追求：在最短时间内产出最多代码。后果无所谓。你在构建一个用于指挥自主Agent军队的编排层。你安装了 Beads，却完全没意识到它几乎是无法卸载的恶意软件。网上告诉你要这么做，你就照做。你把自己套入了循环。Anthropic 用Agent群体构建了一个 C 编译器，有些破损，但下一代 LLM 一定能修复。Cursor 用Agent大军构建了浏览器，当然它不完全可用，需要人偶尔干预，但下一代 LLM 一定能解决问题。分发、拆分、自治、暗工厂、软件六个月内搞定。SaaS 死了，我奶奶让 Claw 自己建了 Shopify！对于几乎无人使用的个人项目，这种方式或许可行。如果有人能让这种方法适用于真正被人使用的软件产品，那更好。如果是你，那就尽管去做。但在我同行圈内，我尚未见到这种方法有效的证据。也许我们都有技能问题。错误叠加却没有学习、没有瓶颈、痛苦延迟Agent的问题在于它会犯错。这没关系，人类也会犯错。可能只是正确性错误，容易识别和修复。加上回归测试效果更佳。或者是代码气味，你的 linter 没发现的。单独看，这些都是无害的。人类也会犯这种错。但 Agent 不是人类。人类犯错几次后会学会不再犯，要么有人训斥，要么自身在学习路径上。Agent没有这种学习能力，至少开箱即用时没有。它会一遍又一遍地犯同样的错误，根据训练数据，甚至可能创造出新的错误组合。你可以尝试教Agent，在 AGENTS.md 里告诉它别再犯同样错误，或者设计复杂记忆系统查找历史错误和最佳实践。这对特定类别错误有效，但需要你观察Agent犯错。更重要的区别是，人类是瓶颈。人类不可能在几小时内输出两万行代码。即使频繁犯错，每天引入的错误有限。错误累积缓慢，如果痛苦太大，人类会花时间修复，或者被解雇由他人修复。痛苦就消失了。有了Agent军团，没有瓶颈、没有人类痛苦，这些小错误会以无法承受的速度累积。你脱离了循环，不知道这些无害的错误已经形成了庞大的代码怪物，痛苦只在为时已晚时显现。某天你想增加新功能，但架构大部分都是错误，Agent无法有效修改，或者用户因最新版本出问题丢失数据而尖叫。你意识到无法再信任代码库。更糟的是，你让 clanker 写的无数单元、快照和端到端测试同样不可靠。唯一可靠的方式就是手动测试。恭喜，你害了自己（和公司）。学到的复杂性的商人你完全不清楚发生了什么，因为把一切自主权交给了Agent。它们是复杂性的商人。它们在训练数据和 RL 训练中见过很多糟糕架构决策，你让它们来架构应用，结果就是：极其复杂的混合体，由可怕的“行业最佳实践”堆砌而成，你没来得及控制。更糟的是，你的Agent彼此看不到对方的执行，无法查看完整代码库或之前的决策。因此，Agent决策总是局部的，导致上述错误。大量代码重复，为抽象而抽象。这些累积成无法恢复的复杂混乱。就像人类企业代码库一样。人类企业代码库之所以如此，是因为痛苦分散在大量人身上，个体无法触发“必须修复”阈值。个体可能无力修复，而组织有极高痛苦耐受力。人类企业代码库需要多年才能达到这种状态，组织随着复杂性缓慢演化并学习应对。有了Agent和两名人类团队，你可能在几周内达到这种复杂度。Agent搜索的召回率低你希望Agent修复、重构代码，但它们应对不了。因为代码库和复杂度太大，Agent只能局部查看。不仅仅是上下文窗口或长序列注意力机制的问题。更微妙的是，在Agent尝试修复前，它必须找到所有需更改的代码和可复用代码，即所谓Agent搜索。工具不同，方法不同：Bash、可查询代码库索引、LSP 服务、向量数据库。最终，代码库越大，召回率越低。低召回意味着Agent不会找到所有需修改的代码。这也是代码气味错误产生的原因。Agent遗漏现有代码，重复、引入不一致，进而形成复杂的“糟糕花”。如何避免这些问题？我们该如何与Agent协作（至少目前我是这么认为的）编码Agent像海妖，以惊人的生成速度和不稳定智能诱你入网，完成简单任务时速度快且质量高。问题出在你想：“天哪，这太棒了，电脑帮我做吧！”显然，把任务交给Agent没问题。合适的任务特点：范围可控，不需理解完整系统；循环闭合，Agent能评估自己工作；输出非关键，仅是临时工具或内部软件，没人生命或收入依赖；或者仅是橡皮鸭讨论，让想法与网络与训练数据的压缩智慧碰撞。只要满足条件，你找到了完美任务，前提是你作为人类是最终质量把关。Karpathy 的自动研究用来加速应用启动？很好，只要你明白输出代码根本不适合生产。自动研究可行，因为你给它一个评价函数，让Agent根据指标（如启动时间或 loss）评估工作。但评价函数仅捕获狭隘指标，Agent会忽略其他指标，如代码质量、复杂性，甚至正确性。关键是：让Agent做枯燥、不会教你新知识的事情，或尝试你没时间尝试的方案。然后评估它的成果，取合理正确的想法，完成最终实现。最终步骤也可用Agent辅助。我建议，放慢节奏才是正道。给自己时间思考真正想做什么、为什么做。给自己机会说：“不，我们不需要这个。”限制每天让 clanker 生成的代码量，按你能审查的能力设定。系统的总体设计、架构、API 等核心部分，手写完成。可以用 tab 补全感受怀旧，或与Agent结对编程。亲自编码，逐步构建，增加摩擦，帮助你理解要构建什么以及系统“感觉”。这是经验和品味发挥作用的地方，是当前 SOTA 模型无法替代的。放慢节奏，经历摩擦，让你学习和成长。最终，你会得到可维护的系统和代码库，至少和Agent出现前的老系统一样可维护。用户会感谢你，产品带来愉悦而非垃圾。功能更少，但更恰当。学会说“不”本身就是一种能力。你可以安心，因为你仍然了解发生了什么，并掌握自主权。理解能力可解决Agent搜索的召回问题，生成更可靠输出，减少修改量。如果出问题，你能亲自修复；设计不佳，你知道原因并能重构改善。有或没有Agent，都无所谓。所有这一切需要纪律和自主权。所有这一切都需要人类。#How I AI#

22. With AI, building is easy; maintaining is hard.AI让“vibe coding”成了新潮流——几句话搭出原型，功能一夜成型。但当项目从Demo走向Production，复杂度非线性飙升：依赖增多、边界扩展、需求迭代、等等，那些为“快”而生的代码，开始暴露脆弱性。真实项目中，真正拉开差距的，不是生成速度，而是工程化体系：代码规范与架构边界、测试策略与CI/CD、监控告警与变更治理、等等。把流程固化，把风险前置，把维护成本压进系统里——这正是Harness一直在做的事。我觉得，能搭出一个东西不算什么，能让它健康地活下去，才是硬实力。#AI编程##vibeCoding##软件工程##DevOps##技术思考##微博AI创作季#

23. 蚂蚁灵光，30秒生成专属程序，普通人也能手搓代码 #蚂蚁灵光 #AI #阿里

24. 从能聊天的大模型，到会干活的智能体，AI正迎来全新进化。企业AI落地的机会就藏在这里。#网络名人赞两会 #2026全国两会 #红衣聊AI #产业升级

25. 一位中国AI创业者，一行代码都没写，却靠着AI智能体，冲进了OpenClaw全球贡献者前30，而且排在他前后的，是一批干了十几年的硅谷顶级工程师。#大有学问 #红衣聊AI #创业 #智能体

26. 深度解析 OpenClaw 在 Prompt / Context / Harness 三个维度中的设计哲学与实践 http://t.cn/AXMlF3bd "OpenClaw 在Prompt Engineering（提示词工程）、Context Engineering（上下文工程）以及新兴的Harness Engineering（驾驭工程/脚手架工程）等维度上也做了很多可值得学习和落地的工作。Prompt Engineering → Context Engineering → Harness Engineering也是现代AI系统的三大关键阶段，分别聚焦于“如何说”、“让AI看什么”以及“构建怎样的运行环境”，三者层层递进，共同致力于提升大模型在复杂任务中的可靠性与可控性‌. …… 我的核心思路是从Prompt、Context和Harness这三个维度展开，分析OpenClaw的设计思路，提炼出其中可复用的方法论，来思考如何将这些精华的设计哲学应用到我们自己的Agent系统设计和业务落地中去。" #How I AI#

27. AI时代，会有一套全新的软件工程规范的，你爸以前学的软件工程方法，都过时了。但加加，记得关注Harness Engineering，我认为比Vibe Coding，是更正确的工程观念。你看，先接触市场上流行的Vibe Code，如果迷信就容易错失后面的Harness Engineering。但，Just do it，先用Vibe Coding写两个项目，知道优缺点，就容易接受更好的新概念。 // Vibe Coding 之后最主流、最受关注的两个新兴工程概念是：Agentic Engineering（智能体工程）和 Harness Engineering（驾驭工程）。它们是 AI 编程从 “随性生成” 到 “工程化可控” 的关键演进。 #父女日常#

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

29. 你以为在做AI转型，其实在慢慢被淘汰。 #大有学问 #红衣聊AI #AI时代 #AI工具 #编程

30. > 不出三年,软件工程专业,大概就是新的五笔打字培训班。说这种话的人，大概率不真正理解“软件工程”这四个字里，“工程”两个字的含量。工程是把一件模糊的、不确定的事情，通过有计划、有步骤的方法，靠谱地做成。软件工程就是把这套思路用在软件开发上，需求怎么理清、架构怎么设计、质量怎么保证、团队怎么协作、项目怎么推进，这是一整套系统性的能力。AI 现在确实强，但它强在软件生命周期里的编码环节（还有很大进步空间），或者说某几个具体阶段。但编码只是软件工程的一个环节，AI 并不能主导整个生命周期，从需求分析、系统设计、技术决策、团队管理到长期维护，这些事情远不是写代码快就能解决的。至少在相当长的时间内都不行。把软件工程类比成五笔打字，这是把“编程”和“软件工程”搞混了。这就好比说有了 3D 打印，建筑学专业就是新的砌墙培训班。能快速盖出一面墙，和设计一栋安全、合理、可维护的建筑，完全是两回事。

31. vibe coding 完项目后，跑这个 Prompt 做安全审计。最近 AI 生成的代码安全漏洞频出——API key 硬编码在代码里、SQL 注入没处理、认证逻辑靠 AI 随手写的……很多人 vibe coding 完直接上线，根本没做安全检查。网友milesdeutscher分享了一个 Claude Code 专用的代码库深度安全审计 Prompt，值得收藏！Conduct a thorough security audit of this codebase. Check for:1. Exposed API keys, secrets, or credentials hardcoded anywhere2. SQL injection vulnerabilities3. Authentication and authorization flaws4. Insecure direct object references5. Missing input validation or sanitization6. Sensitive data exposure in logs or error messages7. Insecure dependencies or outdated packages8. CORS misconfigurations9. XSS vulnerabilities10. Any critical security issues that could lead to data breachesFor each issue found, explain: what it is, where it is, why it's dangerous, and how to fix it. Prioritize by severity.跑完之后 Claude 会逐条给你列出问题、说明风险等级、给出修复方法。几个值得注意的地方：1. API key 泄露是最常见问题。 vibe coding 时 AI 经常把 key 直接写进代码，或者写进被 commit 的配置文件。很多人根本没意识到这件事。2. 认证逻辑最容易出错。 "帮我加一个登录功能"——AI 给出的实现不一定符合你实际的安全要求，要单独 review。3. 这不是一次就够的。每次加了新功能后都应该跑一遍，而不是发布前跑一次交差。vibe coding 本身没问题，但安全审计这步不能跳过。#HOW I AI# #程序员#

32. AI本身都不能固化这些知识，固定的提示词组合规范定义更不能。架构工作AI和Agent都无力承担。现在的agent规范就是标准的脚本，本质是把devops的规范接入ai编程产生迭代流水线。减少人的参与是存在的，因为devops追求的就是自动化，“让人不用再参与到编程这一工作当中来”显然是荒谬的。Devops落地时对IT团队的要求不是更低了，而是更高了。你以为几个固定的脚本流程就可以不需要逻辑严谨需求拆解工程思维迭代，只能说你从来没摸到过软件工程的门槛。//@祈愿_花开:基于harness的视角，整个ai agent体系的根本目的就在于减少人的参与，让人不用再参与到编程这一工作当中来。你所说的一切，包括严谨的逻辑，需求拆解，工程思维，编程认知，小步迭代，这些都应该是ai agent本身的一部分，而不该是对人的要求。

33. 【让AI自己检查作业：一小时写4000行代码的秘密】YC掌门人Garry Tan分享了他使用Claude编程的方法论，核心思路是让AI在动手之前先做系统性的自我审查。他的提示词设计了四个审查维度：架构评估、代码质量、测试覆盖、性能分析。每个维度都要求AI列出具体问题，给出多个解决方案，说明利弊权衡，然后等待人类确认方向再继续。这套方法的精髓在于：把AI从执行者变成对话者。传统的AI编程是你说需求，它吐代码。这套流程是让AI先扮演架构师和代码审查员，把潜在问题暴露在写代码之前。Garry说他用这个方法一小时能完成4000行以上的功能开发，包含完整测试。Paul Graham在评论区算了一笔账：这个速度是去年八月那个引发争议的创始人案例的四倍。几个值得注意的细节：第一，他特别强调用ASCII图来可视化架构。上传截图让AI画出页面结构图，然后用AI命名的元素名称来沟通，省去了大量描述成本。这是个被低估的技巧。第二，提示词里明确写了工程偏好：DRY原则要严格执行，测试宁多勿少，宁可处理更多边界情况也不要图快，显式优于聪明。这些偏好让AI的判断有了锚点。评论区的讨论很有意思。有人指出真正的提升不是来自单个完美提示词，而是整个仓库的配套设施。有人说提示词工程的元游戏正在从「获得好输出」转向「让模型验证自己的输出」。自我检查才是真正的解锁点。也有质疑声音。有开发者说Claude在复杂代码库上最近退步明显，容易陷入循环，中途丢失上下文。还有人直接挑战：4000行代码本身不是成就，4000行你没写的代码才是。这个观点值得深思。速度从来不是稀缺资源，克制才是。一位工程师的总结很到位：提示词不是黑魔法，前置思考才是。他写代码前会先写分形规格文档，把架构、边界情况、测试场景全部预定义，文档和代码的比例是3.6比1。AI编程的本质正在发生变化。瓶颈不再是写代码的速度，而是你能多快想清楚要构建什么。x.com/garrytan/status/2020072098635665909

34. 如何解决Cursor等Agent编码开发轮次多了过后代码库变成屎山的问题？

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

36. 2025过去了！这一年你是不是也在为AI焦虑？老周用360一整年的实践，告诉你答案：不用怕，抓住Agent就赢了！从我自己敲代码做100多个智能体，到带领团队All in，这条AI布道之路，全是实战干货。 2026，你想和智能体一起搞定啥？评论区留言，老周帮你研究！#大咖观察#2026 #年度总结 #红衣聊AI #agent

37. 我们让六个顶级AI相互入侵，谁能成为黑客之王？

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

39. 利用OpenClaw，从零开始搭建属于自己的自动化AI电脑

40. 最近，360安全团队发现了OpenClaw一个高危漏洞。 OpenClaw创始人随后邮件确认了这个漏洞。而发现这个漏洞的，不是某个安全专家，而是一个我们刚发布不到一周的智能体。#openclaw #网络安全 #红衣聊AI #安全漏洞

41. 「Github一周热点105期」Rust 版openclaw，本地语音克隆工具，Qwen3.5， AI 渗透测试系统和精美源码图片生成工具

42. 「Github一周热点104期」智谱GLM-5发布，打响春节AI大战模型第一枪

43. AI生成的代码你们会去一行行检查吗？

44. Agent的底层原理就这么简单：别被玄学忽悠，手撕核心代码给你看

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

46. 全球25个最聪明的AI，你知道都是什么吗？ #大咖观察 #红衣聊AI #编程 #人工智能

47. 打造13个Claude Agent 互相 review 彼此↓ Reddit 一个开发者用 OpenClaw 框架搭建了 13 个 Claude Agent，让它们像真实团队一样工作：有人写代码，有人 review，有人测试，有人查安全漏洞。然后还互相 review 彼此的工作。 1 Writer Agent → 生成代码 2 Reviewer Agent → 逐行审查，对标 code review 标准 3 Tester Agent → 设计测试用例，验证逻辑 4 SecurityAuditor Agent → 扫描安全漏洞 5 Optimizer Agent → 性能优化建议 6 DocumentWriter Agent → 生成 API 文档 7 QA Agent → 最后一关，综合检查 ... + 6 个其他专业角色 vs. 链式流程（A→B→C），这个设计采用质量门控流程。Reviewer 必须 approve 才能进入下一阶段。出问题时反馈重做。成本控制？看起来 13 个 Agent 全力跑，tokens 肯定爆炸。但这个哥们用了几个聪明的招： 1. Context 优化 Writer 不需要看 test cases，Tester 不需要看文档。每个 Agent 只加载相关上下文。这一招可以干掉 80% 冗余 token。 2. 采样策略不是每一行代码都通过全部 13 个 Agent。核心路径 100% 检查，非关键路径采样。 3. 缓存和复用已审查过的代码片段不重复审查。测试用例库复用。架构决策缓存。结果呢？ - 单个开发者 Claude Code：每天 5-20刀 - 13 个 Agent 团队：每天 15-30刀（成本增加不多，质量翻倍）实际对比维护 10 万行代码库： 1. 传统手工做法 - 人工 code review：8 小时 - token：50-80刀 - bug 漏过率：5-10% 2. 13 个 Agent 团队 - 总耗时：30 分钟（Architect 规划 → Writer 并行生成 → Reviewer 自动审查 → 全流程质量门控） - token：20-25刀 - bug 漏过率：<1% 为什么这个方案特别？ 1. 角色化 > 能力化不是「给 Claude 一个超级 Prompt 让它什么都会」，而是「给每个 Agent 一个明确的职责」。 Writer Prompt：「你是代码作者，你的工作是...」 Reviewer Prompt：「你是资深 code reviewer，标准是...」角色专业化自动带来质量提升。 2. 质量门控自动化传统 code review 是人工 bottleneck。Agent review 是自动化 + 可扩展的。 3. 知识积累每个 Agent 的执行历史（什么被 reject、为什么）可以持续优化 Prompt。这是机器学习意义上的反馈循环。 4. 工程意义这不是「用 AI 替代人」，而是「用 AI 团队协作替代个人英雄主义」。更接近真实团队的工作方式。背后的思想转变从「Prompt Engineering」→ 「Architecture Engineering」以前我们花时间优化单个 Prompt，试图让一个 AI 更聪明。现在聪明的做法是设计系统，让多个 AI 通过角色分工和质量门控，集体产出更高质量的结果。原文：www.reddit.com/r/ClaudeAI/comments/1rga7f5/how_i_built_a_13agent_claude_team_where_agents/ #how i ai##程序员#

48. 回复@大秦咏春:他是先用古法编程学会了编程，知道了软件是怎么写出来的，然后，再用AI去取代人工编程，这没啥问题。如果从一开始、一上来就直接使用AI生成代码，对于多数人来说，其实最终学的，就是能够看着工具手册学会使用工具干活而已。//@大秦咏春:请问老师如何看克劳德 Boris Cherny 说他今年没有写过一行代码这事呢

49. AI 编程是一种“框架” www.piglei.com/articles/ai-programming-is-a-new-framework/ 不要将 AI 编程作为一种框架，可以尝试将其看作“库” ----不再追求“写更少实现更多”：用更少的提示词（代码）实现更多功能，看上去很美，但也意味着大量的认知债务随之累积； ----找到编写提示词的“甜蜜区”，付出相对较少而非绝对意义上的最少的认知成本； ----关注程序结构：比起在前 AI 时代，你现在可能更需要关注程序的整体结构，作为总设计师去设计整个程序，将正确的结构和约束内化到 AGENTS.md 中； ----更精准的提示词：在理解已有程序的基础上，编写更精准的提示词来引导 AI 完成工作，而不是任其发挥，让 AI 主导一切； ----审查代码：即便使用同一种框架，在遇到棘手问题时，一位熟读框架文档的人也会比另一位愣头青更有效率，如果把 AI 编写的代码归为框架，那么你应该去审查这份代码，从而在不可避免的“抽象泄露”发生时，将其所产生的危害降到最低。 #HOW I AI#

50. 手把手彻底学会 Agent Skills！【小白教程】

51. AI 时代工程师的新必修课：Agentic Engineering Patterns～收藏Vibe Coding 之后，下一步是什么？Django 联创 Simon Willison写了一份持续更新的工程实践指南，12章，专门讲工程师如何真正驾驭 Claude Code、OpenAI Codex 这类 coding agent。1. 认知重建——"写代码"这件事变了1）Coding agent 的本质是：在循环里执行工具来达成目标。不是聊天补全，是真正能跑代码、能迭代的 agent。2）关键认知转变：写代码变便宜了，但写出好代码没有。3）好代码的标准没变——能运行、有测试、处理边界 case、文档同步、可维护。变的是：以前"这个功能不值得做"的理由消失了。现在的习惯应该是：先跑一个 agent session，10分钟后再判断值不值。2.工程实践——怎么用才不翻车1）Red/Green TDD：先写测试、确认测试失败（Red），再让 agent 实现到通过（Green）。这一步绝大多数人跳过，结果是 agent 写了跑不起来的代码或根本没被用到的代码。一句 prompt 搞定："use red/green TDD"，所有主流 agent 都能理解。2）Git 当安全网：agent 对 Git 的理解比多数初级工程师强。让 agent 每完成一步就 commit，出了问题随时 git bisect 定位哪一步出的问题。Merge conflict 也不用自己解，直接扔给 agent。3）囤积可复用示例（Hoard）：Simon 最推崇的习惯——把"我知道怎么做到"的东西积累成代码库。给 agent 提示时，把两个现有的 working example 组合在一起，往往能直接出结果。上下文里有真实代码比口头描述强 10 倍。3. 最大的反模式——把未审查的代码扔给队友1）这是 Simon 明确列为 anti-pattern 的行为：让 agent 生成 PR，自己没看就提交给别人 review。2）合格的 Agentic PR 标准：- 你自己确认过代码能跑- PR 小、拆分合理、有上下文说明- agent 写的 PR description 你也要亲自 review访问：simonwillison.net/guides/agentic-engineering-patterns/#程序员# #HOW I AI#

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

53. 「Github一周热点第111期」 Karpathy大神的Claude Code配置，更适合程序员的显示器RD270Q

54. 「Github一周热点107期」OpenAI收购的AI安全工具、AI代理事务所、OpenClaw技能库、claude code插件和上下文数据库

55. 360发布“养龙虾”安全指南！ #大有学问 #养龙虾 #OpenClaw #AI工具 #红衣聊AI

56. 先别急“养龙虾”，这些AI安全问题你可能还不知道！附安全解决方案...

57. AI 编程的下半场

58. 谷歌开源项目把二十年工程规范封装成技能使 AI 编程兼顾速度与质量

59. AI 编程要求开发者必须升级

60. 给 AI 编程代理装上工程规范

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

62. 2026年AI编程真相越用越慢效率反降19%氛围编码正在坑惨程序

63. AI Coding 的真实限制

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

65. 70行规则封神！GitHub霸榜神作，重塑AI编程纪律

66. 可控的 AI 编程

67. Cursor 悄悄发布内部开发套件

68. Copilot 到 Claude Code 和 Codex

69. AI 编程工具正在重塑软件行业

70. AI编程进化论

71. AI Coding Agent真正的瓶颈，不是模型，而是 agent harness

72. OpenCode技能集（SKILLS）

73. 炸场！AI 编程正式进入 Agent 时代，开发者要被 “重新定义” 了

74. AI编程的缺点和局限性

75. 经历一系列故障后，亚马逊让资深工程师成为AI生成代码的人工过滤器

76. 灵码+Qwen3-Coder——使用Skill机制实现代码审核

77. AI Agent 和 AI 编程 Agent 到底是什么？

78. 试了 Cursor 3 的 Agent 模式，真的颠覆以前的AI编程方式

79. AI编程工作流怎么选？三大主流工具实测对比

80. 【AI编程】四大规范驱动开发Spec工具助力AI编程从“即兴创作“向“工程化“转变

81. 我在 CLAUDE.md 里加了 30 行安全约束，AI 生成代码的漏洞率降了一半

82. Harness Engineering 的防御视角

83. Vibe Coding生成的代码为何有多个高危安全漏洞？

84. 没有规则约束，AI生成代码45%存在安全漏洞？aiXcoder

85. AI生成代码的五大安全关卡

86. AI编程质量危机

87. AI帮你写了75%的代码，但安全漏洞也多了2.74倍

88. 从惊艳到失望

89. 试试这个GitHub项目，14本软件工程圣经变成了AI编程规则，专治AI写坑

90. 氛围编程命名人

91. 从30亿Token到全自治AGI

92. 一套可复制的 AI 编程体系

93. Cloudflare大佬的 Claude Code 实战心法

94. AI | 我试了试"一句话生成软件"，发现了AI的盲区

95. AI编码提示词工程是一个完整的、系统化的AI编码辅助体系，它将成功的AI编码实践经验转化为可复用的知识资产。通过标准化的Prompt设计、分层架构的工程体系和完善的质量保障机制，帮助开发团队

96. 从Prompt工程到Context工程再到Harness工程

97. AI合规企业如何规范使用AI？一套可直接用的Prompt模板

98. [Alan の手札] Prompt 写死在代码里，是很多 AI 项目崩盘的开始

99. Claude.md规则层

100. AI 协作三层文档约束体系（Meta Specification）--VibeCoding工程协作宪法

101. AI 编程的约束艺术

102. Superpowers与OpenSpec

103. Spec约束编程

104. AI编程不只是写Prompt

105. 38k stars！Google工程师把工程纪律塞进AI编程工具

106. AI能写代码,但需要人工监督——还要会和它对话

107. 杭州签鸟网络科技总经理天吴:在AI快速发展的时代,我们更需要尊重规则

108. 一个CLAUDE.md霸榜GitHub第一,蒸馏自Karpathy,6万码农抄作业

109. Leader 禁止实习生碰代码,我不听,用 Agent Skills 修了个线上 Bug。他找我谈话:今天转正!

110. AI编程工具源码泄露事件引发行业深度思考

111. 你以为AI编程拼的是提示词,其实高手都在“驯化”项目结构

112. 拦截、审计、恢复:Agent控制流框架

113. 能上生产才是硬道理!Coding Agent 评测,终于开始关注过程了

114. AI 编程时代软件工程形式化方法的必要性：挑战、范式转移与研究展望

115. AI编程的现实主义转向

116. SWE-bench分数全是假的？伯克利Dawn Song团队10行代码骗过8大Agent基准

117. 威斯康星大学揭秘：AI代码写得越来越乱，竟然连自己都"不认识"

118. PRBench：AI agent能否实现可靠的端到端物理学论文复现？

119. 企业使用 AI 代理进行代码开发的规范2026Q1 v1 (简略版) - 哔哩哔哩

120. 审稿人"代码可读性"惩罚：编程风格评分与计算论文接受率相关

121. 2026年最强自改进 Agent 现身，但没人聊它背后的那个"隐患"

122. 【AI论文解读】北大发布AI科学研究新基准！当前大模型Agent居然0%完全复现顶刊结果？| PRBench

123. 为什么 2026 年 AI 编程拉开差距的，不只是模型，还有上下文工程

124. AI编程的几点思考

125. AI代码审查工具降本增效：从“集成”到“生效”的决策框架

126. 从vibe到spec：可维护性视角下探讨为什么很多人的AI编程依然是小玩具

127. 智信代码：降低AI生成代码风险

128. 2026 企业级 AI 编程实践手册精华分享

129. 【译】Visual Studio 三月更新 —— 打造专属自定义 Agent

130. 警惕AI一键生成的“便捷陷阱”：你的代码，真的安全吗？

131. 超6万GitHub项目实测：AI Agent写代码效率暴涨，通过率仍落后人类

132. Prompt编写技巧

133. Copilot PR 描述就被改了？GitHub AI 编程工具的权限边界正在失控

134. AI生成代码的质量，谁来兜底？我们建立了一套“AI代码质量门禁体系”

135. AI审查+人工研判：安全漏洞防护的双重保障方案

136. AI Code Review Agent：用多 Agent 架构做自动化代码审查

137. 为什么你的AI代码审查工具难以“降本增效”？关键在于“流程重构”而非“工具替换”

138. 开源的AI编码提示词工程，适用于 java+vue3+uniapp 全栈开发

139. 代码写不动了？传统程序员不转型AI工程化提示词专家，将被AI助手彻底平替

140. 测试用例 Prompt 模板库：让 AI 帮你写出专业级测试用例（附 10 个可直接套用的模板）

141. AI Agent编程的一致性门槛，如何用技术手段保障代码质量？

142. 从Copilot到Cursor到Claude Code到OpenClaw，AI时代的范式革命

143. 2026年AI编程工具全景评测：从代码补全到智能体协作

144. "AI 辅助编程实战：从 Copilot 到 Cursor 的 2026 年效率工具深度评测"

145. AI写代码总“卡壳”？开发环境碎片化，成强化学习最大拦路虎

146. 如何保障阁下AI生成工具的安全性？

147. 阿里通义灵码实测：AI写代码到底有多强？

148. 基于 LLM Agent 的代码审计与漏洞发现：技术路线、成果与前沿方向分析

149. 前端 AI Coding 落地指南（二）Rules篇

150. agent-skills 实测：给你的 AI Agent 装上大厂级的工程纪律

151. ACL 2026 | 可执行知识图谱：助力AI科学家进行研究复现

152. 2025–2026 双年度指南：主流 AI 编程工具深度对比与选择建议

153. Spring AI 2.0 的Prompt与PromptTemplate：简化提示工程

154. Prompt 工程技巧：5 个模板让 AI 输出质量提升 10 倍

155. AI Agent/编程工具横评：我扒了全网最新测评，结论和想象的不一样

156. TRAE个人规则（全局提示词）分享及工程思维与开发规范讲解

157. ⚠️2026AI编程避坑实战指南

158. AI编程幻觉终结者–TDD+重构驱动的单元测试实战课\n - 哔哩哔哩

159. 规范驱动开发4大工具对比（SDD）

160. 测试用例的验证点：如何确认AI生成结果的可靠性

161. 实测8款主流AI编程工具：免费的坑多，付费的未必值，开发者指南

162. AI编程工具横评：2026年人人

163. 开发者编码效率低下的核心痛点 → AI编程三巨头精准解法 → 效率提升

164. AI生成代码有漏洞，程序员如何做工业级代码审查？

165. 上海交大IPADS开源形式化方法智能体FM-Agent：让代码不仅可生成，还可推理

166. 50 个前端开发常用 AI Prompt 模板：拿来即用

167. 2026国产AI编程工具真相：有的越用越爽，有的越用越坑

168. A2UI v0.9 之后：Agent 生成 UI 要从代码输出变成意图声明

169. AI 辅助代码重构实例

170. 《AI代码革命2026：Copilot之后的下一个突破》

171. AI编程助手正在爆发

172. 2026年AI编程实战：Copilot、Claude Code、DeepSeek-Coder横向评测

173. 与其疯狂灌水，不如用AI解决可复现性危机

174. AI编程工具横评2026：这些工具让我效率提升10倍

175. 教你用AI-Agent复现论文代码这期视频，我实操演示如何用 👉 paper-replicate-agent-demo 让 AI Agent 自动：阅读论文 PDF 识别变量对比已有数据生成可复现的 R 代码自动验证结果输出质量分析报告甚至还能自动识别缺失变量清单，帮你构建完整复现路径。从计划模式 → 代码生成 → 结果验证 → 自动纠错，全流程演示一次给你看。 paper-replicate-agent-demo GitHub 已开源，欢迎使用！ #vibecoding #Agent #Claude #论文 #AI

176. 2026 年最值得关注的 7 个 AI 编程助手，最后一个惊艳了

177. AI编程助手实战：三个月使用GitHub Copilot的效率提升报告

178. 浅谈AI编程下的可维护性

AI编程越“聪明”，事故越频发？工程规范成生存底线

精选参考来源