张大妈

AI编程助手的真实能力边界:用对了效率翻倍,用错了反拖后腿

源自136位全网作者

05-14 13:30

精选参考来源

1
在线上 AI 编程时代,如何让会写代码的模型在真实工程环境中安全稳定地运行,是架构设计的头等大事。「Harness Books」这个开源项目,收录了两本关于 Harness Engineering(约束执行工程学)的专业书籍,深入探讨了模型行为后果管理、权限控制、上下文治理、多 agent 验证与团队制度等核心设计理念。它们不讲代码拆解,而是聚焦「控制结构」如何打造,让不稳定的 AI 编程模型,回归工程可持续运转的秩序体系。两本书分别关注:- 《Claude Code 设计指南》:讲述 Harness 必须具备的控制面、Query Loop、工具权限、失败恢复、团队制度等架构结构;- 《Claude Code 与 Codex 比较》:比较两套 Harness 在控制层次、权限沙箱、策略语言、组织习惯编码等方面的分歧和优劣。项目主页还支持在线阅读和 PDF 下载,同时配合 AgentWay 平台,辅助开发者把理论转化为训练、项目和实践。GitHub:github.com/wquguru/harness-books 在线阅读:harness-books.agentway.dev/ PDF 下载(示例): - harness-books.agentway.dev/book1-claude-code/exported/book1-claude-code.pdf - harness-books.agentway.dev/book2-comparing/exported/book2-comparing.pdf主要价值:- 深入理解 AI 代码生成模型的工程约束与治理结构;- 掌握多 agent 系统的验证与恢复机制,提升系统稳定性;- 学会把团队经验固化为可复用制度,打造持久智能开发流程。适合 AI 编程工程师、架构师、产品经理,以及所有关注 AI 工程安全与可控性的开发者。#AI工程# #智能编程# #开源好书#
2
AI生成的代码你们会去一行行检查吗?
全部
来源
内容由AI生成

精选参考来源

1. 在线上 AI 编程时代,如何让会写代码的模型在真实工程环境中安全稳定地运行,是架构设计的头等大事。「Harness Books」这个开源项目,收录了两本关于 Harness Engineering(约束执行工程学)的专业书籍,深入探讨了模型行为后果管理、权限控制、上下文治理、多 agent 验证与团队制度等核心设计理念。它们不讲代码拆解,而是聚焦「控制结构」如何打造,让不稳定的 AI 编程模型,回归工程可持续运转的秩序体系。两本书分别关注:- 《Claude Code 设计指南》:讲述 Harness 必须具备的控制面、Query Loop、工具权限、失败恢复、团队制度等架构结构;- 《Claude Code 与 Codex 比较》:比较两套 Harness 在控制层次、权限沙箱、策略语言、组织习惯编码等方面的分歧和优劣。项目主页还支持在线阅读和 PDF 下载,同时配合 AgentWay 平台,辅助开发者把理论转化为训练、项目和实践。GitHub:github.com/wquguru/harness-books 在线阅读:harness-books.agentway.dev/ PDF 下载(示例): - harness-books.agentway.dev/book1-claude-code/exported/book1-claude-code.pdf - harness-books.agentway.dev/book2-comparing/exported/book2-comparing.pdf主要价值:- 深入理解 AI 代码生成模型的工程约束与治理结构;- 掌握多 agent 系统的验证与恢复机制,提升系统稳定性;- 学会把团队经验固化为可复用制度,打造持久智能开发流程。适合 AI 编程工程师、架构师、产品经理,以及所有关注 AI 工程安全与可控性的开发者。#AI工程# #智能编程# #开源好书#

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

3. Claude Opus 4.5 一夜打穿编程圈,并降价 2/3 (附 22 个 编程case 全能力测试)

4. 顶级教育资源入场券,谷歌联手斯坦福给全球孩子做的免费AI启蒙神器,带孩子零代码做数据清洗、模型训练、偏见消除 #ai #学习 #谷歌 #斯坦福 #教育

5. 刚给一家公司作了咨询,他们的痛点是全面应用了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编程也就能落地了。没办法,这就是现实。

6. 破茧与重生:AI 编程时代,程序员该何去何从?

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

8. 2026年,AI编程真能取代程序员了吗?

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

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

11. 稳了!AI生成85%代码,程序员职业历史上最好的黄金十年来了!

12. 灵光一夜爆火,一句话就能做出小应用,当AI发展得越来越快——你就知道,孩子真正要练的,从来不是技能本身#近6成程序员称不会给孩子报AI编程课 #AI时代教育 #灵光#孩子要学什么

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

14. AI大神的焦虑:自己是研究工作的瓶颈,Token用得不够多#AI #人工智能 #卡帕西 #Agent #算力

15. 如何评价胡锡进驳「文科无用论」,称「理工科学得差,比文科学得差还容易被AI取代」?

16. 智能体即开发者:论AI如何重塑编程边界与人机协同未来

17. AI 编程真的有用吗?Cursor|TRAE 深度实测!

18. Y Combinator 总裁 Garry Tan 写了一篇很长的文章,讲他过去一年用 AI 写代码的核心方法论。他做了两个开源项目,GStack(93K stars)和 GBrain(14K stars),加起来大约 97 万行代码、665 个测试文件,基本全部由 Claude Code 和 Codex 在他的指挥下完成。他提出了一个概念叫"复杂度棘轮"(Complexity Ratchet)。棘轮就是那种只能往一个方向转的机械装置,比如扳手拧螺丝只能往前不能往后。他说用 AI 写代码也可以做到这一点:质量只能上升,不能下降。前提是你得有 90% 的测试覆盖率。具体怎么运作的?每次 AI agent 写代码的时候,同时会产出三样东西:测试(定义什么是"正确")、文档(记录为什么这么做)、评估结果(建立质量基线)。下一次 agent 再来改代码的时候,它会加载这三样东西到上下文里。测试不过就不能提交,文档就在眼前不能忽略,质量低于基线就会被发现。质量底线每一轮都在上升,这就是棘轮效应。他举了个很具体的例子。GBrain 有个功能是从大量文本里提取"谁相信什么",第一版跑出来质量 6.8 分(满分 10),最大的问题是搞混了"谁持有这个观点"。于是评估结果被记录下来,6 个失败模式被识别,第二版 prompt 针对性修复,17 个测试锁定了这些规则。以后任何版本的代码都必须通过这 17 个测试才能上线,没有人需要记住这些细节,测试替你记住了。为什么 90% 这个数字这么重要?他引用了 Capers Jones 对一万多个软件项目的研究:覆盖率在 70% 以下时,缺陷逃逸率很高;到了 85%-95% 的区间,缺陷捕获率跳到 92%-97%。这个关系不是线性的,在 85% 附近有一个拐点,过了这个点,漏网的 bug 数量会断崖式下降。航空软件行业几十年前就发现了这一点,所以 FAA 对飞行关键系统强制要求极高覆盖率。过去 50 年,90% 覆盖率对人类团队来说太贵了,因为最后那 20% 的测试写起来极其枯燥费力,大多数团队到 70% 就停了。但 AI agent 不会无聊,不会在周五下午偷懒,不会觉得"以后再补"。那堵挡住人类的"意志力墙",对 AI 来说根本不存在。所以 90% 覆盖率从一个奢侈品变成了默认设置。他还展示了棘轮可以测试的范围远超传统单元测试。他用 Bun 的 TTY 功能造了一个测试框架,能在伪终端里启动 Claude Code,观察它的实际行为,比如"有没有在 review 过程中问用户问题"。如果 agent 跳过了交互直接输出结果,测试就会失败。这已经不是在测代码逻辑了,是在测 AI agent 有没有遵守行为契约。最后他的结论很直接:任何软件公司如果还没采用这套模式(agent + 品味 + 只升不降的测试套件),在速度和质量上已经输给了一个用这套方法的单人团队。工具是开源的,免费的,去用就行。#科技先锋官##How I AI#

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

20. MiniMax M2.7+OpenClaw实战!AI到底能接管多少工作?

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

22. 【AI 时代的工程真相:模型只是引擎,Harness 才是方向盘】你用不好 AI,不是因为模型不够强,而是因为你没有为它构建正确的环境。在 AI 领域,有一个被大多数人忽视的底层逻辑:Harness(开发支架/环境)决定了 AI 智能的上限。1. 什么是 HarnessHarness 不是系统提示词,也不是简单的 API 封装。它是 AI 运行的完整设计环境,包括:- AI 能调用的工具集- 信息接收的格式规范- 历史记忆的压缩与管理机制- 错误捕捉的护栏- 跨会话的任务衔接支架2. ACI:AI 的认知架构Princeton NLP 的 SWE-agent 研究提出了 ACI(Agent-Computer Interface)的概念。研究发现:同一个 GPT-4 模型,仅仅通过优化交互界面,在编程基准测试中的表现就能提升 64%。核心洞察:- 上下文窗口不是内存条,而是 AI 的意识空间。- 噪音会摧毁推理:直接给 AI 返回一万行搜索结果会淹没其认知,而带限制的摘要式输出能引导其深度思考。- 状态化视图:带行号的、分块显示的代码查看器,能显著降低 AI 的计算负担。3. 解决长程任务:Anthropic 的双 Agent 架构当任务大到无法塞进一个上下文窗口时,Anthropic 采用了初始化 Agent + 执行 Agent 的模式:- 初始化 Agent:不写代码,只负责搭建脚手架。生成 init.sh 环境脚本、详细的 Feature List(JSON 格式,利用其结构化特性防止 AI 随意篡改)和进度日志。- 执行 Agent:每次只攻克一个功能点,完成后必须更新进度并提交 Git。金句:Git 不仅仅是版本控制,它是 AI 的认知脚手架。4. OpenAI 的零人工代码实践OpenAI 曾用 3 名工程师驱动 Agent 交付了 100 万行代码。他们的核心转变是:- 工程师的工作从写代码变为设计环境。- 当 AI 出错时,不要求它重试,而是反思环境缺失了什么能力导致了错误。- 仓库即真相:所有知识必须存在于代码库中,AI 无法访问 Slack 或文档。- 机械化架构约束:通过自定义 Linter(由 AI 编写)强制执行架构规则,而非依赖人工 Review。5. 核心设计模式总结- 渐进式披露:不要一次性给 AI 太多信息,给它入口和寻找信息的地图。- Git 工作树隔离:一个 Agent 一个独立的工作空间,防止并行任务冲突。- 闭环反馈:集成 Linter、自动化测试和浏览器模拟(如 Puppeteer),让 AI 能亲眼看到运行结果。6. 深度思考:执行力的平庸化与环境的差异化在 2025 和 2026 年,AI 写代码的能力正在变成一种廉价的商品。真正的竞争护城河不再是你用了哪个模型,而在于你构建了什么样的 Harness。模型是思考的引擎,而 Harness 决定了引擎在思考什么、如何纠错以及如何持续演进。如果你在构建 AI 系统时感到吃力,请停止优化提示词,开始进行环境审计:- AI 缺了什么信息?- 缺了什么反馈环能让它自我纠错?- 哪里存在上下文污染?未来的顶级工程师,本质上是 AI 环境的设计师。x.com/rohit4verse/status/2033945654377283643

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

24. #谷歌组建“突击队”:深度解析其提升代码模型竞争力的战略布局#在生成式人工智能的军备竞赛中,代码编写能力已成为衡量底层大模型(LLM)核心实力的“试金石”。近日,据《The Information》报道,谷歌内部正秘密组建一支代号性质的“突击队”(Strike Team),旨在集中顶尖资源,全面提升其代码生成的准确性与推理能力。这一举措不仅是对 OpenAI、Anthropic 等竞争对手的直接回应,更揭示了谷歌在 AI 2.0 时代重塑开发者生态的焦虑与野心。#战略背景:代码能力的“分水岭”#代码生成不仅仅是辅助程序员写代码,它代表了 AI 对逻辑结构、符号推理和长文本依赖的处理极限。目前,OpenAI 的 GPT-4o 以及 Anthropic 的 Claude 3.5 Sonnet 在编程基准测试中持续领先,尤其是 Claude 3.5 在实际工程环境中的表现,赢得了大量开发者的青睐。谷歌虽然拥有强大的 Gemini 系列模型,但在代码垂直领域的反馈中,仍面临逻辑一致性和复杂项目理解上的挑战,因此必须通过专项团队进行突破。#突击队的核心使命#这支新组建的团队并非常规的研究小组,而是一个跨部门的精锐组织。其核心任务集中在三个维度:首先是强化逻辑推理,通过强化学习(RL)使模型理解复杂的架构设计而非仅仅堆砌代码;其次是缩短迭代周期,打破内部官僚壁垒,将 DeepMind 的研究成果快速转化为生产力工具;最后是优化长上下文窗口的应用,确保 Gemini 在处理整个代码库时保持极高的精准度。#技术路径:从数据到反馈#为了实现目标,谷歌“突击队”采取了多维度的技术策略。在数据层面,引入更多经过验证的人类专家代码,以减少过时或不安全代码的生成。在训练方法上,针对编程逻辑进行专门的人类反馈强化学习(RLHF),提升模型解决复杂 Bug 的能力。在应用层面,则推动模型与 Android Studio 及 VS Code 等开发环境的深度集成,实现真正的“感知上下文”编程辅助。#行业影响:开发者生态的再洗牌#谷歌此举的影响将远超其搜索业务。在云服务领域,代码模型的优劣直接影响 Google Cloud 对企业客户的吸引力。随着代码模型能力的质跃,软件开发门槛将进一步降低,未来的编程模式可能演变为“架构设计 + AI 审查”。同时,这也标志着谷歌与拥有 GitHub Copilot 的微软、拥有 Q 的亚马逊在 AI 编程领域的全面战争正式升级。#结语:重夺代码高地#谷歌组建突击队,本质上是在补齐其 AI 战略中最关键的一环。代码能力作为通用人工智能(AGI)的基石,谁能率先实现“完美编程”,谁就掌握了未来数字世界的解释权和构建权。对于谷歌而言,这不仅是一场技术的突破,更是一场关于“重塑创新基因”的自我证明。

25. 为什么 VibeCoding 这么火?AI 编程能够在 IT 领域这么快大规模的应用?其实,原因可能就是两点:上下文更集中和程序具有可验证性。什么意思?详细解释一下。第一个是上下文更集中。对于编程来说,工具和上下文往往在一个地方:IDE、代码库、终端。这让 AI 更容易理解和执行。但一般的知识工作分散在几十个工具里。想象一个 AI Agent 试图起草产品简报:它需要从 Slack 聊天记录、策略文档、上季度的仪表板指标,以及只存在于某人脑子里的机构记忆中提取信息。今天,人类就是那个粘合剂,通过复制粘贴和在浏览器标签页之间切换把这一切拼接起来。在这些上下文被整合之前,AI Agent 只能局限在狭窄的用例里。所以,想要让 AI 在其他领域可以更集中的规模化使用,就需要解决这个问题,或者对上下文有更好的解决方案。目前最好的解决方法就是最近比较火的 Skills 。第二个缺失的要素是可验证性。代码有个神奇的特性:你可以通过测试和错误来验证它。模型制造商用这个来训练 AI 更好地编程。但是,其他领域的很多工作,并不具有可衡量性和验证性,比如,你怎么验证一个项目管理得好不好,或者一份战略备忘录写得怎么样?我们还没找到改进通用知识工作模型的方法。所以人类仍然需要在循环中监督、引导,展示什么是好的。如果顺着这两个条件继续往下推,其实就能看到一个更大的结论:Vibe Coding 火的不是“编程”,而是它刚好踩中了 AI 最容易规模化落地的那块“甜区”。AI 并不是突然“会写代码了”,而是第一次遇到一个:上下文高度结构化、结果可以被快速验证、反馈闭环极短的工作形态。编程只是最典型的代表。你在 IDE 里敲一句需求,AI 生成代码,跑一下,报错或通过,立刻得到反馈。这正好符合强化学习和人类协同训练最舒服的环境。所以,为什么其他知识工作暂时很难复制 Vibe Coding 的成功?因为它们同时缺两样东西:- 上下文没有被收敛- 结果没有被形式化只要这两点不解决,AI 就只能当“高级搜索 + 自动补全”,而很难进入“协作生产”。所以你会看到一个很有意思的趋势:AI 在写代码、做数据处理、生成 SQL、写测试时进展飞快在战略、管理、判断、决策上却进展缓慢不是模型不聪明,而是工作本身还没被“工程化”。未来 AI 是否能在某个行业大规模落地,取决于这个行业能否被改造成“像编程一样的工作”。也就是说:- 能不能把上下文压缩到少数系统里- 能不能把“好不好”变成“对不对”- 能不能把反馈周期从“几个月”缩短到“几分钟”谁先做到这一点,谁就会诞生属于自己的 “Vibe X”。#科技先锋官##微博年度新知博主##AI创造营#

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

27. #DeepSeek新模型能否再次爆火#V4最大的突破之一:应该是是超长的上下文理解能力想象一下这样的场景:你接手了一个遗留系统,代码几十万行,文档缺失,关系复杂传统AI模型要么"看不懂",要么"理解偏了"而V4能够一次性理解整个代码库的逻辑,给出真正有用的分析和建议,这对于企业级开发来说,才是真正的生产力提升呀!DeepSeek#AI##数码科技##DeepSeek#

28. 全球AI开发者新宠!阶跃星辰Step 3.5 Flash,两天登顶OpenRouter趋势榜

29. 你觉得 AI 写 90% 代码这件事,是夸张宣传,还是已经快成现实了?

30. “大模型就像处理器:需要巨大投资,潜力无限,但单独用处有限。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

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

32. Prajwal Tomar的观点引发了广泛共鸣:那些“很少写代码”的资深开发者,往往是因为他们积累了多年对系统、数据库和故障机理的深刻理解,才得以高效利用AI辅助编程。他们知道该问什么、怎么改错,而初学者若跳过基础学习,只靠AI,反而容易盲目依赖,无法分辨AI的错误。AI不是替代理解,而是放大理解的能力。社区中许多资深开发者也认同这一点:从汇编语言到高级抽象,经验让他们能拆解复杂任务,合理运用AI工具。缺乏系统思维和架构知识的新手,面对复杂生产环境如API集成、云部署、内存管理等,往往难以独立解决问题。AI能提升效率,但不能代替对代码全局和细节的掌控。有声音指出,虽然资深经验难以短时间内积累,但合理利用大语言模型(LLM)进行持续提问和实践,能在数周内获得快速进步。但这仍需投入时间和主动学习,单靠“提示工程”无法弥补基础欠缺。此外,AI扩展了开发者群体,降低了入门门槛,这对整体技术生态是利好。但真正能驾驭AI、写出高质量、可维护代码的人,依然是那些理解底层原理、经历过系统设计和长时间磨练的工程师。只有这样,才能在AI辅助下实现“乘数效应”,而非盲目依赖导致“自信的错误”。正如一位开发者所言,写SQL这类结构化查询仍是手写效率最高的场景,甚至有工具如vibesql帮助简化与数据库的交互,但这也基于对SQL及数据库原理的理解。总结:- AI是强大工具,但不是捷径,理解系统和代码基础仍不可或缺- 资深开发者能利用AI放大效率,初学者须先打牢基础,否则难以验证和修正AI输出- AI让更多人能快速入门编程,但深度技术和系统设计能力仍需时间积累- 面对未来,培养“理解+AI协作”的能力,才能真正驾驭技术变革这既是对技术进步的期待,也是对教育和学习路径的警醒。AI的力量在于放大“人”的智慧,而非替代“人”的思考。x.com/PrajwalTomar_/status/2000905515954749445

33. #谷歌Gemini3.1Pro正式发布# 谷歌于今日正式推出升级核心模型Gemini 3.1 Pro。其实现了推理能力的跨越式升级,ARC-AGI-2测试得分达77.1%,较上代翻倍且大幅领先竞品。学术科研能力行业登顶,GPQA Diamond科学测试拿下94.3%高分,博士级专业处理能力突出。 与此同时,Gemini 3.1 Pro编程与智能体能力跻身第一梯队,竞赛级编程表现领跑,工程代码修复比肩顶尖水平,长链任务能力近翻倍。同时支持百万token上下文,全模态原生理解,可高效适配科研、开发等全场景复杂任务。

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

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

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

37. GPT-5.3 正式发布!完全免费开放,实测代码能力、推理、文本理解与响应速度 | 零度解说

38. 聊一聊OpenClaw和之前其它AI的区别:AI聊天软件:由用户给定的有限输入,由AI运行环境能力边界限制的输出内容Manus:由用户给定的有限输入,由AI运行环境能力边界限制的输出内容,但通过使用沙箱环境,输出能力极大增强Claude Code等本地智能体工具:由用户给出需求,AI自己在本地运行环境中取得需要的输入,通过使用本地运行环境,输出能力极大增强OpenClaw:AI使用本地环境无限制地取得输入且自主增强输出能力,用户给出需求不再是AI执行任务的主要触发源

39. 大语言模型(LLM)在写代码方面已非常强大,但要构建非简单应用,自己仍需懂代码。任何声称“不懂代码也能做复杂App”的说法,要么是推销,要么是不懂实际开发。不过,学代码从未如此便捷。你只需几个月的刻意学习,利用最先进的语言模型,就能自己用AI辅助打造非简单应用。核心在于:AI能帮你写代码,但你必须理解软件逻辑、系统架构和调试方法,才能驾驭复杂项目。否则,代码生成很快会陷入重复、杂乱、难维护的陷阱。理解代码背后的原理,是辨别AI建议优劣的关键。传统的4年计算机科学学位正逐渐失去性价比,更高效的方式是结合现代AI工具,短期内集中学习基础和实战。让AI成为“加速器”,而非“替代品”。初学者或转行者可通过结构化训练,搭配LLM辅助,快速跨越语法和模板壁垒,把时间花在架构设计和问题解决上。即使没有多年写码经验,掌握逻辑思维和系统规划,也能构建商业级应用。真正的挑战不在“写代码”,而是“理解需求,设计系统,解决复杂问题”。AI压缩了学习曲线,但你必须能提出正确的问题,给模型准确上下文,才能发挥最大效能。AI让“学编程”更快、更易,但不会取代对代码和系统的深刻理解。非简单应用的门槛没消失,只是形态变了——从打字写代码,转向理解架构与调试。未来属于懂得与AI协同、善于系统思考的开发者。原文:x.com/ImSh4yy/status/1993397933895450871

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

41. AI最擅长什么编程语言?

42. AI革命不是让你去学写代码,而是让你学会指挥AI干活。 #大咖观察 #红衣聊AI #科技改变生活 #人工智能

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

44. aiX-apply-4B逆袭DeepSeek-V3.2!aiXcoder发布代码变更应用模型,单卡推理提效15倍

45. OpenAI最强代码模型GPT-5.2-Codex上线

46. 大模型上下文工程指南

47. “文科无用论”形成的经济、社会与政治的历史根源和演变动力是(先看问题描述)?

48. 在 AI 一键生成代码的时代,程序员还有必要坚持手写「古法编程」吗?

49. 目前AI编程工具哪个最好用?

50. 终于来了!DeepSeek-V4 正式发布!免费开源,百万上下文,Agent能力直逼Claude!| 零度解说

51. 一位开发者「用Claude Code独立开发iOS应用5个月,代码量达到22万行」后的思考。代码量反而是容易的,Claude Code最大的挑战不是生成代码,而是管理代码的上下文和做架构决策。1. 上下文爆炸22万行代码,当你修改一个功能时,Claude Code需要理解它可能影响哪些其他模块有时候一个改动会在意想不到的地方产生副作用需要手工梳理依赖关系,告诉Claude Code"这个改动的边界在哪"这个工作量比写代码还大2. 架构决策无法自动化项目初期:选择用SwiftUI还是UIKit?选哪个数据库?如何分层?这些决策会影响后续几十万行代码的质量Claude Code很难主动说"我觉得这个架构有问题,我们应该重构"需要人来做决策,然后告诉它执行3. 技术债累积很快短期内快速堆砌代码很容易但6个月后再改动一个核心模块时,会发现当初的快速决策留下了大量技术债清债比新建还费时间4. 测试覆盖成了瓶颈22万行代码,自动化测试覆盖率如果低于80%,新改动就很容易引入bugClaude Code能帮你写单元测试,但什么时候需要补充测试、哪些路径容易出bug,这需要人的经验判断对比传统团队开发:1. 传统模式(团队):架构师做决策(花时间但决策质量高)开发者执行(快速)Code Review 抓问题(花时间)2. Claude Code模式(单人):开发者做决策(需要你懂架构)Claude Code执行(非常快)自己测试和验证(花时间)看起来快了,但其实只是把时间挪到了前期设计和后期测试。这位开发者总结的经验:✅ Claude Code最擅长的:把你的想法转化成代码(包括复杂的UI逻辑)跨文件的重构(改一个接口,它能同时更新所有调用处)生成样板代码和重复代码快速迭代("改成这样试试"的速度很快)❌ Claude Code无法替代的:架构设计(什么时候应该分层、什么时候应该合并)技术决策(用A方案还是B方案,长期来看哪个成本更低)性能优化(知道代码跑得慢,但为什么慢、怎么优化需要人工分析)产品决策(哪个功能应该优先做、MVP应该包含什么)对工程师团队的启示:1. 不要期待AI完全替代你最高效的模式不是"AI干所有活",而是"人做决策,AI执行"。人的时间花在思考上,AI的时间花在实现上。2. 架构能力变成了新的竞争力当代码生成不再是瓶颈时,能快速做出好的架构决策的人变得稀缺。这是未来更值钱的技能。3. 上下文管理成了新的挑战22万行代码已经是这位开发者的极限了。再往上,单靠Claude Code处理上下文的能力就不够。需要更好的code organization工具。4. 测试和质量保证的重要性提升当开发速度提升10倍时,测试和bug修复的比例反而上升。需要更严格的测试规范。原文讨论:www.reddit.com/r/ClaudeAI/comments/1rr1069/#HOW I AI# #程序员#

52. 【软件工程师会最先把自己干掉吗】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

53. Alex Albert 正在征集 Opus 4.5 的反馈,用户们纷纷指出了使用中的痛点和改进建议:- 上下文限制频繁导致查询失败,界面空白,且离开页面后常丢失输入(Deedy)- 模型偶尔过于急于下结论,忽略指令,且有时回答直觉化,缺乏严格核查- 需要更强的“长上下文智能”,能提炼主题、战略方向,而非简单检索- UI体验欠佳,比如无法在会话中切换Sonnet和Opus,自动压缩功能不可控,浪费时间和资源- 性能和成本问题,期望更快更便宜- 代码生成时常忽视已有抽象,重复造轮子;合并冲突处理不够智能,导致等待CI失败- 安全研究场景识别不足,拒绝分析恶意软件样本- 记忆和上下文管理不理想,频繁重复说明,影响效率- 功能期待:自动生成并保持最新的CLAUDE .md文档,异步渐进式压缩,支持视频输入- 质量波动大,有时表现“迷糊”,甚至比旧版本Sonnet还差- 期望下一个版本能更快推出,提升智能和稳定性总体来看,Opus 4.5 功能强大,用户体验和技术细节仍有不少提升空间。真正的挑战是如何在保持模型强度的同时,提升稳健性和实用性,减少“直觉式”错误,增强上下文理解和持续学习能力。只有这样,才能让AI成为日常工作中真正值得信赖的助手,而非偶尔拖后腿的“聪明伪专家”。x.com/alexalbert__/status/1998801676854337643

54. 一个视频带你快速盘点2025年GitHub热点项目

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

56. 开发者的边界,正在被 TRAE SOLO 独立端扩大

57. 在线协作开发常常需要协调多个AI助手、项目任务和沟通渠道,流程复杂不便管理。OpenSwarm 是基于 Claude Code CLI 的自治AI开发团队协调器。OpenSwarm 能自动从 Linear 拿任务,执行 Worker/Reviewer 代码生成与评审,还能在 Discord 上同步进度,利用 LanceDB 实现长期认知记忆,让AI团队像真人团队一样协作。主要功能:- 多代理流水线,支持 Worker、Reviewer、Tester、Documenter 多阶段自动协作;- 集成 Linear 任务管理,自动抓取和更新任务状态;- 通过 Discord 机器人,实时控制和查看任务进展,支持命令调度和对话;- 支持 LaurentDB 向量存储,实现跨会话的认知记忆回顾;- 支持多模型提供者,如Claude和OpenAI Codex,运行时可动态切换;- 自动监控PR,处理CI失败、合并冲突和重试,释放人工干预压力;- 丰富的终端交互界面(TUI),方便开发者操作与管理;- 支持多项目调度和自动任务分配,提升协作效率;- 具备代码依赖分析及变更影响检测功能,保障代码安全和准确;适合需要用AI自动化代码开发和评审、提升团队协作效率的开发者和团队。GitHub:github.com/unohee/OpenSwarm#开源神器# #AI开发助手# #自动化编程# #团队协作# #ClaudeCode# #开发效率提升#

58. 字跳TRAE团队发了个《2026 企业级AI编程实践手册》,总结了他们的AI编程方法论和工程实践网页链接“在2026年,AI编程已不再是实验性的尝试,而应该成为企业软件开发的核心生产力。本手册源于TRAE团队在构建AI编程助手过程中的真实实践——我们用AI构建AI,在这个过程中积累了从方法论到工程实践的完整经验。这不是一本理论书籍,而是一线研发团队的实战总结。我们将分享如何将AI真正融入企业级开发流程,如何建立可复制的工程规范,以及如何让团队从“会用AI”到“精通AI编程”。无论你是技术决策者、架构师还是一线开发者,都能在这里找到可落地的方法和工具。AI时代的软件开发不是替代人类,而是重构协作方式。让我们一起探索这个新范式。”#How I AI#

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

60. GitHub暂停Copilot 新用户注册 成本压力下被迫收缩调整

61. GitHub Copilot突然「变天」,最良心的AI套餐也无了

62. Copilot 不让注册了

63. GitHub Copilot遭用户强烈反弹,限速调整背后是定价模型的崩溃

64. GitHub 暂停 Copilot 注册

65. 开了 Copilot Pro+,钱交了,活没干完,先被限流了

66. AI编程助手实测

67. 用了两年国产 AI 编程工具,换 Claude Code 三天后,我彻底不想回去了

68. 氛围编程

69. AI驱动编程革命从代码生成到0代码

70. AI编程要小步快跑,步步为营

71. 氛围编程解析

72. 当AI编程工具"失灵"时

73. 从惊艳到失望

74. AI可以做一切,唯独无法“负责”

75. AI 编程并非银弹

76. 告别 AI 乱码开发!Superpowers 开源框架,让 AI 编程实现工程化规范

77. AI 编程最大的阻力,从来不是技术,而是“封装权”

78. AI编程时代程序员是否还需要学习

79. 为什么ai编程时代,我基本全靠ai做项目了,我觉得自己作为一个程序员已经没什么意义了?

80. AI 编程,正在悄悄毁掉你的编程能力!

81. 你以为AI编程效率翻倍?实验结果打脸了

82. 不是 AI,是代码,才是这个时代普通人的最大杠杆

83. AI编程正在贬值!华尔街高官直言,两年后全白费,应如何教孩子?

84. 别被“文科无用论”毁掉

85. 张雪峰劝你别报文科,黄仁勋说语言即编程

86. 我,怕断电断网,更怕断Token

87. 代码AI写了42%,但96%的程序员不信它

88. AI能写80%的代码,但真正稀缺的是定义问题的人

89. 【AI 前沿】100 亿 token 测试揭示真相

90. AI编程大模型深度对比

91. 大模型排查代码问题的制约因素

92. 工业代码能力不只要“会写”,更要“会想”

93. AI写代码,越改越错?前OpenAI首席科学家

94. Vibe-Coding

95. “今天必须吐槽一个所有大模型都有的致命问题!不管是GPT、Claude还是国内的各种模型……”

96. 大模型能复刻这些系统吗?ProgramBench给出了残酷答案

97. 大模型十大高频问题之六

98. 上下文

99. 养虾记·第114期|龙虾的代码助手——AI驱动

100. AI 辅助编程的反直觉真相

101. AI辅助编程的元问题与元能力

102. Anthropic最新研究

103. Claude Code+OpenSpec提速AICoding落地|得物技术

104. ASE'24|大语言模型在单元测试代码生成上的评估

105. 为什么LLM搞不定复杂任务?从语言模仿者到问题解决者的破局之道

106. 当 LLM 执行长期任务时

107. 当AI学会"三思而后行"

108. AI写作潜能与局限,替代人类有争议

109. 开发者仍不信任AI生成代码质量

110. 深度分析AI编程助手全面改变程序员工作方式与行业格局前景预测

111. 用λ演算驯服LLM的递归:8B小模型干到70B的表现

112. Superpowers 项目深度解读:AI 编程代理的"超能力"框架

113. Anthropic:编程助手损害开发者概念理解

114. 写Verilog、调CUDA,总翻车?工业代码大模型开始学会「先想后写」了

115. Meta 最新研究:结构化提示词,提升大模型代码审查可靠性

116. 写Verilog、调CUDA,总翻车?工业代码大模型开始学会先想后写了

117. 攻城狮周刊#4:AI 编程助手市场竞争加剧

118. 天天在说AI,却对AI最基础的概念却一无所知

119. AI编程工具逆天了!程序员集体崩溃:这还让不让人活?

120. 测试覆盖的“最后一公里”:当大模型学会为你的代码“查漏补缺”

121. claude-code-best-practice是什么?AI编程最佳实践指南 - 哔哩哔哩

122. AI编程助手——每个开发者的新“副驾驶”。曾几何时,写代码是程序员孤独的修行;如今,AI编程助手正成为开发者的“智能副驾驶”。从GitHub Copilot到通义灵码,AI不仅能自动补全代码,还能解释逻辑、生成测试用例、修复漏洞。 这不仅是效率革命,更是能力平权。初级开发者输入自然语言描述:“写一个Python函数,读取CSV并计算平均销售额”,AI即可生成结构清晰、带注释的代码;资深工程师则用它快速搭建脚手架,专注架构设计。 据Stack Overflow调查,74%的开发者已在使用AI编程工具,平均节省30%编码时间。微软报告称,Copilot用户完成任务速度快55%。更重要的是,AI大幅降低跨语言门槛——前端工程师可快速调用后端API,无需深究Java细节。 但挑战犹存:AI可能生成有安全漏洞的代码(如SQL注入),或依赖过时库。因此,“AI写,人审核” 是黄金准则。未来,AI编程将向“全栈智能体”演进——你描述需求,它自动生成前后端+部署脚本。 对软件公司而言,拥抱AI编程不是选择,而是生存必需。培训团队熟练使用AI工具,建立代码审查规范,将成为核心竞争力。毕竟,在AI时代,会提问的程序员,比会敲键盘的更值钱。#AI编程助手

123. 试了5款AI编程工具后,我只想说两个字:离谱

124. 原子能力:通过联合强化学习扩展编程智能体 - 哔哩哔哩

125. 放弃开发爆款吧!普通人用AI编程的唯一出路,是把时间变现

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

127. 大模型测试常见误区,90%测试专家都踩过

128. 阿里云通义Qwen3.6-Plus大模型正式发布 代码能力跻身全球第一梯队 运行率超90%开放免费商用

129. 顶级代码大模型:Claude Code & OpenAI Codex

130. 开发者称AI编程工具确实有效,但这正是他们担忧的原因

131. 斯坦福提出Extract+Think:让小型多模态模型实现“感知”与“思考”的双重飞跃

132. 无代码AI编程工具的局限

133. InCoder-32B:首个面向工业场景的代码大模型,性能超Claude

134. 第一次在生产环境使用vibe coding

135. AI编程重构项目大翻车-superpowers也救不了

136. 上交:针对类级代码生成任务的Benchmark

0
扫一下,分享更方便,购买更轻松
0评论

当前文章无评论,是时候发表评论了
提示信息

取消
确认
评论举报

最新文章 热门文章