当前位置：

社区首页

电脑数码

软件应用

服务软件

AIGC文章详情

AI编程避坑指南：需求说不清，代码全是雷

源自138位全网作者

05-26 17:05

精选参考来源

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

既然 AI 越来越聪明，那么学习提示词不是浪费时间吗？我小时候英语很差，因为周围总有人说：学英语有什么用？我是中国人，何必学外文，不会 ABC，也当接班人。现在也有人觉得 AI 那么强学英语干嘛。我本来就不喜欢学，这下子找到借口了。等到工作以后才发现，好的技术文档全是英文的，想读一手资料读不了，想跟别人用英文交流张不开嘴，吃了很多年的亏。后来我花了很大力气补英语，现在都没有完全补回来，走了很多弯路。回头看，当年那些说“英语没用”的人，错在哪里？他们不是坏人，只是把一个判断搞反了：因为自己用不上，或者未来技术更强，就断定这个东西没价值。我现在看到有人说“AI 越来越聪明，所以不用学提示词”，感觉特别像当年那些说“学英语没用”的声音。逻辑结构很像：我不需要，所以它没价值；未来会更好，所以现在不用学。这种想法容易让人踩坑。先搞清楚提示词工程到底是什么很多人反感提示词工程，其实反感的是那种“万能提示词模板”、“神秘咒语”，这种东西确实没什么长期价值，模型一升级就失效了。但这不是提示词工程的全部，甚至不是它的重点。真正有价值的提示词工程，是把目标定清楚，把约束条件列明白，把验收标准写出来，把任务拆成可执行的步骤。你愿意的话可以叫它“需求工程”或者“任务设计”，叫什么都行，但这件事本身一直都很值钱。你跟同事说“帮我写个方案”，同事一定会追问：给谁看的？多长？要数据吗？什么时候要？你补充的这些信息，就是在做提示词工程。你跟 AI 协作也是一样的道理，只不过 AI 不会主动追问你（或者追问得不够好），所以你得自己先想清楚。有人说：AI 的目标就是用自然语言像人一样交流，你和谁交流需要用提示词？听起来挺有道理，但仔细想想就会发现问题：你跟人交流，难道就不需要把话说清楚了吗？你去医院说“我不舒服”，医生一定会追问：哪里不舒服？多久了？有没有吃什么药？你不会觉得医生在搞“提示词工程”，你只会觉得这是正常的沟通。AI 能用自然语言交流不等于 AI 有了“读心术”。自然语言天生有歧义，任务目标经常互相矛盾（又要短又要全，又要创新又要安全），输出往往需要特定格式。这些问题不会因为 AI 变聪明就消失。更准确的说法是：AI 越强，对你输入的容错越高，你随便说一句也能得到一个还不错的结果。但“还不错”和“稳定、可靠、符合要求”之间的差距，仍然需要你把需求定义清楚来弥补。相机像素越来越高，但你仍然需要构图。像素高只是让你拍什么都不太糊，但要拍出好照片，你还是得知道自己想拍什么、怎么拍。还有一种类似的说法：“不出三年，软件工程专业就是新的五笔打字培训班。”这和“提示词工程不用学”的思维方式完全一样：看到 AI 能替代某个环节，就急着宣判整个领域的死刑。工程是把一件模糊的、不确定的事情，通过有计划、有步骤的方法，靠谱地做成。软件工程就是把这套思路用在软件开发上，需求怎么理清、架构怎么设计、质量怎么保证、团队怎么协作、项目怎么推进，这是一整套系统性的能力。AI 现在确实强，但它强在软件生命周期里的编码环节（还有很大进步空间），或者说某几个具体阶段。但编码只是软件工程的一个环节，AI 并不能主导整个生命周期，从需求分析、系统设计、技术决策、团队管理到长期维护，这些事情远不是写代码快就能解决的。至少在相当长的时间内都不行。把软件工程等同于写代码，就像把提示词工程等同于背咒语，都是把一个局部当成了全部。高飞说过一句话我很认同：会敲字，不代表会写作；会写作，不代表懂出版。同理：会跟 AI 说一句话，不代表会用好 AI；会用好 AI，不代表能把 AI 嵌入一个可靠的工作流。每一层跳跃之间，都需要“工程”思维来填。以前你自己写代码，现在你指挥 AI 写代码。以前你自己写文章，现在你让 AI 起草再改。工具变了，但“把事情做对”这个责任没有变，仍然在你身上。指挥 AI 本身就是一种能力。你得知道要什么、怎么拆任务、怎么验收、出了问题往哪里查。这些不叫“被替代”，叫工具升级后的能力重心转移。你觉得某些 AI 产品随便说一句就好用，那是因为有人替你把需求定义和约束设计做好了。如果有人说：“我从来不研究怎么把需求说清楚”，这不是什么值得骄傲的事情，“我从来不研究提示词工程”也类似。你以为自己省了时间，其实是把“研究成本”变成了“返工成本”，只不过花得不自知。我当年不学英语，也觉得自己省了时间。后来补课花的时间，比当初好好学多了好几倍。AI 越强，“工程”两个字越值钱，而不是越不值钱。因为强工具放大的是使用者之间的能力差距。同样一个模型，会用的人和不会用的人，产出可以差十倍。拉开差距的，就是你愿不愿意花时间把需求定义好、把流程设计好、把质量管控好。你可以不叫它“提示词工程”，叫“需求设计”也好，叫“任务拆解”也好，叫“跟 AI 好好说话”也行。但“把你想要的东西想清楚、说明白”这件事，不会因为 AI 变强就消失。

全部
来源

内容由AI生成

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

2. 既然 AI 越来越聪明，那么学习提示词不是浪费时间吗？我小时候英语很差，因为周围总有人说：学英语有什么用？我是中国人，何必学外文，不会 ABC，也当接班人。现在也有人觉得 AI 那么强学英语干嘛。我本来就不喜欢学，这下子找到借口了。等到工作以后才发现，好的技术文档全是英文的，想读一手资料读不了，想跟别人用英文交流张不开嘴，吃了很多年的亏。后来我花了很大力气补英语，现在都没有完全补回来，走了很多弯路。回头看，当年那些说“英语没用”的人，错在哪里？他们不是坏人，只是把一个判断搞反了：因为自己用不上，或者未来技术更强，就断定这个东西没价值。我现在看到有人说“AI 越来越聪明，所以不用学提示词”，感觉特别像当年那些说“学英语没用”的声音。逻辑结构很像：我不需要，所以它没价值；未来会更好，所以现在不用学。这种想法容易让人踩坑。先搞清楚提示词工程到底是什么很多人反感提示词工程，其实反感的是那种“万能提示词模板”、“神秘咒语”，这种东西确实没什么长期价值，模型一升级就失效了。但这不是提示词工程的全部，甚至不是它的重点。真正有价值的提示词工程，是把目标定清楚，把约束条件列明白，把验收标准写出来，把任务拆成可执行的步骤。你愿意的话可以叫它“需求工程”或者“任务设计”，叫什么都行，但这件事本身一直都很值钱。你跟同事说“帮我写个方案”，同事一定会追问：给谁看的？多长？要数据吗？什么时候要？你补充的这些信息，就是在做提示词工程。你跟 AI 协作也是一样的道理，只不过 AI 不会主动追问你（或者追问得不够好），所以你得自己先想清楚。有人说：AI 的目标就是用自然语言像人一样交流，你和谁交流需要用提示词？听起来挺有道理，但仔细想想就会发现问题：你跟人交流，难道就不需要把话说清楚了吗？你去医院说“我不舒服”，医生一定会追问：哪里不舒服？多久了？有没有吃什么药？你不会觉得医生在搞“提示词工程”，你只会觉得这是正常的沟通。AI 能用自然语言交流不等于 AI 有了“读心术”。自然语言天生有歧义，任务目标经常互相矛盾（又要短又要全，又要创新又要安全），输出往往需要特定格式。这些问题不会因为 AI 变聪明就消失。更准确的说法是：AI 越强，对你输入的容错越高，你随便说一句也能得到一个还不错的结果。但“还不错”和“稳定、可靠、符合要求”之间的差距，仍然需要你把需求定义清楚来弥补。相机像素越来越高，但你仍然需要构图。像素高只是让你拍什么都不太糊，但要拍出好照片，你还是得知道自己想拍什么、怎么拍。还有一种类似的说法：“不出三年，软件工程专业就是新的五笔打字培训班。”这和“提示词工程不用学”的思维方式完全一样：看到 AI 能替代某个环节，就急着宣判整个领域的死刑。工程是把一件模糊的、不确定的事情，通过有计划、有步骤的方法，靠谱地做成。软件工程就是把这套思路用在软件开发上，需求怎么理清、架构怎么设计、质量怎么保证、团队怎么协作、项目怎么推进，这是一整套系统性的能力。AI 现在确实强，但它强在软件生命周期里的编码环节（还有很大进步空间），或者说某几个具体阶段。但编码只是软件工程的一个环节，AI 并不能主导整个生命周期，从需求分析、系统设计、技术决策、团队管理到长期维护，这些事情远不是写代码快就能解决的。至少在相当长的时间内都不行。把软件工程等同于写代码，就像把提示词工程等同于背咒语，都是把一个局部当成了全部。高飞说过一句话我很认同：会敲字，不代表会写作；会写作，不代表懂出版。同理：会跟 AI 说一句话，不代表会用好 AI；会用好 AI，不代表能把 AI 嵌入一个可靠的工作流。每一层跳跃之间，都需要“工程”思维来填。以前你自己写代码，现在你指挥 AI 写代码。以前你自己写文章，现在你让 AI 起草再改。工具变了，但“把事情做对”这个责任没有变，仍然在你身上。指挥 AI 本身就是一种能力。你得知道要什么、怎么拆任务、怎么验收、出了问题往哪里查。这些不叫“被替代”，叫工具升级后的能力重心转移。你觉得某些 AI 产品随便说一句就好用，那是因为有人替你把需求定义和约束设计做好了。如果有人说：“我从来不研究怎么把需求说清楚”，这不是什么值得骄傲的事情，“我从来不研究提示词工程”也类似。你以为自己省了时间，其实是把“研究成本”变成了“返工成本”，只不过花得不自知。我当年不学英语，也觉得自己省了时间。后来补课花的时间，比当初好好学多了好几倍。AI 越强，“工程”两个字越值钱，而不是越不值钱。因为强工具放大的是使用者之间的能力差距。同样一个模型，会用的人和不会用的人，产出可以差十倍。拉开差距的，就是你愿不愿意花时间把需求定义好、把流程设计好、把质量管控好。你可以不叫它“提示词工程”，叫“需求设计”也好，叫“任务拆解”也好，叫“跟 AI 好好说话”也行。但“把你想要的东西想清楚、说明白”这件事，不会因为 AI 变强就消失。

3. Vibe Coding 终极指南 V1.2开发者在与 AI 搭档编程时，经常面临规划混乱、代码难维护的问题。Vibe Coding 是一个以规划为核心，结合系统提示词和模块化设计的终极 AI 编程工作流程，帮助你从想法到可维护代码，形成一条清晰可控的流水线。它提供了丰富的提示词库，涵盖需求澄清、开发计划、代码实现、测试验收等全流程，确保 AI 不会失控，项目结构清晰且易于扩展。无论是 CLI 还是 VSCode 扩展，都能顺畅体验。主要特点包括：- 以规划驱动开发，避免 AI 自主引发混乱；- 完善的系统级提示词集合，规范 AI 行为边界；- 闭环交付流程，从需求到测试全覆盖；- 共享记忆库，实现人机同步的项目上下文；- 支持多种 AI 模型和环境，灵活高效。项目地址：github.com/tukuaiai/vibe-coding-cn/tree/main适合开发者、团队和 AI 协同工作场景，助你打造可审计、可复盘、可持续的 AI 编程新体验。

4. Spec-Driven Development: 为混乱的 AI 编程增加工程纪律

5. Harness 驾驭工程是 AI 平权的必经之路？

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

7. 2026年了！大部分人还不会给AI提示词。

8. 别光问AI了，反向操作才是王炸，这是我10倍速阅读的三大心法和提示词～当会用AI不再稀缺，AI时代真正拉开差距的是什么？#ai #阅读 #读书 #学习 #世界读书日

9. 提示词工程、上下文工程都过时了，现在是 Harness Engineering 的时代

10. AI 编程时代，最稀缺的不是提示词，而是软件工程

11. Agent 开发范式演进：从环境工程出发，“简化”多源实时上下文

12. 对于普通居民（非技术人员）搞个Openclaw有什么用呢？

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

14. P99延迟降72%、成本降83%！字节跳动Agent上下文平台首度公开

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

16. 【上下文工程实战指南：如何让AI代理真正听懂你的话】“AI垃圾输出”的锅，现在该用户来背了。在Claude Code这类黑箱系统中，上下文是我们唯一能控制的输入变量。既然如此，如何优化它就成了关键问题。+ 什么是上下文？上下文指的是你发送消息时提供给大语言模型的一切——不仅是提示词本身，还包括系统提示、元数据、历史对话、模型的思考过程、工具调用和响应。大模型的上下文窗口有限，对话越长，追踪信息的准确度就越低。Claude Code的上下文窗口看似有20万token，但实际可用空间远没那么多。运行/context命令就能看清真相：22.5%被预留，10.2%被系统提示占用，加上MCP服务器、子代理和规则，真正留给我们的只有约12万token。更关键的是，无论是否接近窗口上限，上下文越多，模型质量就越差。+ 基础功夫最重要和大多数事情一样，820法则同样适用于vibe coding。做好以下基础，你就已经完成了80%：- /upgrade升级到Max计划- /model选择opus 4.5- /init创建项目说明文件然后是基本工作流：1. 从计划模式开始（Shift + Tab）2. 让Claude通过提问来澄清模糊点3. 执行经过打磨的计划创建子代理、自定义命令、钩子、多代理编排确实很酷，但说实话，没有我们想象的那么重要。掌握基础才是核心竞争力。+ 如何实际运用这套工作流把每次新对话当作一个目标，严格控制范围：-“我要修复这个bug”-“我要构建这个功能”对于新项目，目标可以更宽泛，但这意味着需要更多规划和打磨——因为模糊性越大，误解空间就越大。多花时间规划，再多花时间打磨规划。让Claude不断提问，直到它开始为问而问。请它多次审查计划，讨论架构、最佳实践、安全风险、生产就绪度、测试策略——目标是在每个模糊点提供细节。+ 何时重置，如何重置如果进展顺利且后续任务与当前上下文相关，继续就好。接近上下文上限时，运行/compact释放空间，或让Claude Code自动处理。但如果事情不顺利呢？模型没做对，你陷入了“这太糟糕了请修复”→垃圾输出→“这更糟糕了你在想什么”→垃圾输出的循环。这时不要试图在同一线程中挽救，而是：- /rewind回到进展顺利的节点- /new开启新线程，优化原始提示词，明确指出“不要做什么”——把上次的教训写进去+ 避开复杂性陷阱如果你常刷社交媒体，可能已经收藏了无数花哨设置——MCP服务器、子代理、技能包……我的建议是：不要过度复杂化。正如Anthropic所说，我们的目标是“找到最小的高信号token集合”。往上下文塞太多MCP数据，只会用低信号填满窗口，同时烧掉你的钱。+ 善用MCP服务器获取优质上下文MCP服务器本质上是让模型能调用的第三方工具——文档、GitHub代码、Linear工单、Figma设计等。这类工具刚推出时被热捧，但人们很快发现很多会疯狂消耗上下文，得不偿失。我目前只用三个经过验证的：- exa.ai：AI代理的网络搜索- context7：AI代理的最新文档- grep.app：AI代理的GitHub搜索我主要用它们研究如何正确实现代码——这些事我自己查文档也能做。Anthropic把这称为“即时上下文”策略——代理在需要时自己寻找信息。这对Claude Code这类代理式编码工具非常有效。+ 用子代理节省上下文——我最喜欢的隐藏技巧Claude Code可以创建子代理——作为主代理的子实例运行。关键在于：- 子代理拥有独立于主代理的上下文窗口- 可以使用不同模型（比如非opus）这意味着我们可以让子代理执行消耗大量token的操作（如研究），然后向主代理提供精炼摘要——信息密度高，token消耗低。我最常用的是一个自定义的“图书管理员”子代理，运行sonnet模型扫描开源仓库和文档，向主代理返回精炼摘要。我会说：“用librarian研究如何用Y库实现X，然后实现Z”——子代理触发，调用所有工具找到高质量答案。这既防止主上下文被污染，又用更便宜的模型完成简单任务。+ 用技能包引入相关上下文技能包与子代理相反——不是把任务委派给专门代理，而是把专业能力引入当前代理的上下文。比如Claude Code内置的“前端设计师”技能，会引入一段较长的提示词，告诉Claude前端设计的注意事项。这些工作流听起来花哨，但原理很简单——Claude只是在认为需要时，把一段文本拉入上下文。+ 核心要义好的vibe coding是为价值密集的上下文而优化。你添加或从模型接收的任何信息，都应简洁地服务于帮助模型回答下一个请求。如果做不到这点，就不应继续在同一上下文中工作——这是避免陷入令人沮丧的垃圾输出循环的关键。社交媒体上那些花哨命令可能让你觉得自己落伍了。但实际上，事情没那么复杂——尽力用简洁、高质量的信息帮助模型，给它工具让它自己找到相关信息。就像你对待一位同事那样。x.com/jarrodwatts/status/1926054877836624014

17. 硅谷巨头正疯抢高中生，斯坦福开设vibe coding课，清华AI博士甚至建议从幼儿园学起？AI海啸下，人才底层逻辑彻底变了，未来最值钱的不再是代码，而是你的“Vibe”#ai #vibecoding #秒哒 #硅谷 #AI时代学什么

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

19. 推特热议、AI 万亿美元新赛道，「上下文图谱」到底是什么？创业机会在哪？

20. 如何看待淘天金码奖设立Prompt工程赛道，是否意味着「提示词工程师」将成为未来五年互联网行业新风口？

21. 当模型推理能力越来越强，我们还需要提示工程吗？

22. 如何看待淘天金码奖设立Prompt工程赛道，是否意味着「提示词工程师」将成为未来五年互联网行业新风口？

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

24. 未来产品经理将会被淘汰？ #大咖观察 #红衣聊AI #产品经理 #人工智能

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

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

27. 使用 Claude Code：会话管理与 100 万上下文

28. AutoDev Next：IDE 即 AI 编程服务，构建多端粪围编程

29. 如何看待淘天金码奖设立Prompt工程赛道，是否意味着「提示词工程师」将成为未来五年互联网行业新风口？

30. 云小二 Aivis 的架构实践——基于上下文工程与多智能体的自主服务新形态

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

32. 【编程从来都不是什么高贵的手艺】编程从来都不是人们所浪漫化的那种“高贵手艺”。它本质上只是一场与机器的较量，你明明表达得很清楚，机器却偏偏不懂你的意思。真正有价值的，从始至终只有一件事：你想用代码表达的数学思维和逻辑。像 Claude Code 和 Codex 这样的AI工具，现在能处理人类意图和机器之间的大部分摩擦。这也是为什么我讨厌“氛围编程”这个说法。用它来形容那些盲目让AI写代码的人倒是贴切，但那些理解约束和逻辑、只是借助AI的人，根本不是什么“氛围程序员”。他们是“斯多葛程序员”，只是不想把时间浪费在和机器较劲上。有人说得好：真正的技能从来不是记住语法，而是问题分解。氛围编程是放弃理解，斯多葛编程只是把打字的活交出去。很多开发者从读计算机专业第一天起就知道这个事实，只是有些人不愿承认。因为“我吃过苦所以我有本事”这种心理投入太深了。现在的分野其实不在于用不用AI，而在于你能不能把约束条件、边界情况、各种权衡同时装在脑子里。如果你不理解系统，AI只会帮你更快地犯错。手艺没有消失，只是往上挪了一层。逻辑、品味、判断力，比语法重要得多。正如一位网友所说：编程从来不是艺术，思考才是。AI只是把我们从搬运语法的工人变成了设计建筑的人。盲目复制是氛围编程，带着意图使用AI才是在正确的层级工作。也有人提醒：设计仍然很难。氛围编程没有解决这个问题，它只是解决了编码的部分。编程曾经算是一门报酬不错的蓝领工作，因为这项技能稀缺。现在稀缺性正在迅速消失，很多没有准备的程序员将面临严峻的现实。机器从来不是敌人，摩擦才是。现在真正有趣的问题是：当摩擦消失后，人类会建造什么？ x.com/TheVixhal/status/2015412324363063312

33. 很easy啊，对程序员来说，古法手搓本身就是基操，啥都不会你当啥程序员？啥都氛围编程，速度是上来了，可维护性下降了，什么项目都是准备就干个一期就跑路吗小朋友？二期三期看你怎么搞。技术是渐进式迭代发展过来的，到如今不懂底层编程原理，不懂设计架构，光靠提示词编程，你在这当缝合怪呐

34. Harness Engineering 到底是什么？你可能已经会写 prompt 了，但最近火的 Harness Engineering 是什么？先搞清一个区别：- Prompt Engineering = 教你怎么说话让 AI 听懂- Harness Engineering = 造一套系统让任何人都能驾驭 AIPrompt 是手艺活，效果取决于写的人的水平。Harness 是工程活，目标是不管谁来用，结果都稳定可靠。- 打个比方：Prompt 像苦练骑术，Harness 像发明马鞍+缰绳+马镫——装备好了，骑术一般的人也能跑得稳。那它具体包括什么呢：- AI 模型本身就像一匹野马，很强但不可控。Harness Engineering 就是给它套上"马鞍"，具体包括：1. 提示词模板：标准化的思考框架，不用每次现写2. 工具调用：让模型能查天气、搜网页、读文件3. 结构化输出：回答不是一堆文字，而是程序能解析的 JSON4. 容错重试：模型抽风了自动重试，不用人盯着5. 检索增强（RAG）：让模型能查你的私有数据6. 护栏机制：防止模型说出不该说的话核心思路：- 不要试图让模型更聪明，而是让系统更聪明地使用模型。以前大家卷的是模型大小、跑分高低。现在大家发现模型够用了，真正决定产品好坏的是套在外面那层"马鞍"。Prompt Engineering 只是 Harness 里最小的一个零件。真正的竞争在于整套系统的工程能力。#Harness##Prompt Engineering##Prompt##Prompt Engineering##AI##大模型#

35. AI 发展到一定阶段，模型会吞噬框架。模型智商越高、上下文越丰富，越容易吃掉一切外部结构。模型进步慢，框架才有主导权。而框架，是大多数人都能参与的；模型，对大多数人是不利的。所以 OpenClaw 这样的框架才极其重要——守住框架，就是守住普通人的机会。模型决定智能，框架决定公平。#新媒沈阳聊ai#

36. 《扣子开发 AI Agent 智能体应用》017-提示词编写和优化（驱动智能体的核心指令）

37. 小米 MiMo 团队负责人罗福莉：全球算力跟不上 Agent 时代的 Token 消耗，出路不是更便宜的 Token，而是更省 Token 的框架和更高效的模型共同进化。一个技术细节：OpenClaw 的上下文管理做得非常糟糕。一个用户请求会触发多轮低价值的工具调用，每次都带着超过 10 万 Token 的长上下文窗口，实际请求次数是 Claude Code 自身框架的好几倍。换算成 API 价格，真实成本可能是订阅价的几十倍。罗福莉提了两个观点：第一，短期阵痛反而是好事。第三方框架被迫走 API 付费后，成本压力会倒逼它们改进上下文管理、提高 prompt 缓存命中率、减少无效 Token 消耗。第二，呼吁其他大模型公司不要在没想清楚定价模型之前盲目打价格战。低价卖 Token 的同时对第三方框架大开门户，看着对用户友好，实际是个陷阱，Anthropic 刚从这个坑里爬出来。

38. 【“氛围编程”正在毒害新一代程序员，这里有一份解药】快速导读：最近科技圈热议一个词：“氛围编程”（Vibe Coding），特指那些依赖AI辅助、凭直觉快速堆砌功能，却对底层逻辑和安全一知半解的开发方式。这感觉很爽，直到数据库被删库跑路。这份安全清单，就是给所有“感觉派”程序员的当头一棒。---最近科技圈开始流行一个词：氛围编程（Vibe Coding）。它指的是一种开发状态：大量依赖AI生成代码，凭直觉和“感觉”把功能快速拼凑起来。代码能跑，Demo很炫，但你对其中的细节一知半解。就像一位网友说的，“氛围编程一时爽，直到数据库凭空消失”。你以为自己是善用AI的超级个体，单枪匹马就能交付一个完整产品。其实，你可能只是在生产一个随时会引爆的精美玩具。这份在开发者中引起广泛讨论的“氛围编程安全手册”，就是一剂苦口良药。比如第二条就极其刺眼：“永远不要用AI构建的身份验证系统”。这背后的问题是，AI正在制造一种“能力幻觉”。它能帮你写出“能用”的代码，却无法把背后数十年的工程纪律和血泪教训也一并教给你。你享受了创造的快感，却把理解和审查的责任也外包了出去。一位开发者说得好：“当真实用户在周五凌晨2点挤爆你的应用时，你才会后悔自己当初没搞懂代码到底在干嘛。”这无关对错，而关乎职业阶段。用“氛围编程”做个原型没问题，但把它直接当产品上线，就是一场灾难的预演。判断标准很简单：AI生成的每一行代码，你是否都逐行审查过，并能为它的所有潜在后果负责？所以，你刚刚上线的那个项目，到底是一个产品，还只是一种感觉？---简评：“氛围编程”的本质，是用战术上的勤奋（疯狂复制粘贴），来掩盖战略上的懒惰（放弃深度理解）。最后出了事，锅可以甩给AI，但职业生涯的坑，是自己给自己挖的。---ref: x.com/om_patel5/status/2030491740415684691#AI创造营##人工智能#

39. 现在程序员的代码大多数都是用AI生成的，后面会成为屎山代码看不懂吗？

40. 【#AppStore应用提交量激增#】#AppStore应用提交量大增84%# 当地时间 4 月 5 日，据外媒 Apple Insider 报道，苹果 App Store 应用提交量大幅增长，2026 年第一季度同比提升 84%，“氛围编程”的普及或已成为主要推动因素。随着 ChatGPT 和 Claude 等 AI 工具发展，编程效率显著提升。相比以往自动化工具，AI 进一步降低了开发门槛，使初学者也能开发复杂应用。Sensor Tower 数据显示，自 2025 年第一季度起，App Store 提交量持续上升，并在 2026 年初明显加速。2025 年全年提交量同比增长 30%，总规模接近 60 万；到 2026 年第一季度，单季提交量已达到 23.58 万。分析认为，“氛围编程”工具是这一增长的核心动力。这类工具能够根据用户需求自动生成代码，甚至可以实现完全由 AI 生成应用，对于专业开发者而言，也显著提高开发效率。Sensor Tower 高级洞察分析师亚伯拉罕 · 优素福指出，这一趋势与 Claude Code 和 ChatGPT Codex 等“智能体编程”工具的推出密切相关。同时，苹果自身的 Xcode 在 26.3 版本中也已加入类似能力。#60万美元投资换来264亿美元回报#（IT之家）

41. 不懂编程，可以使用AI编程！小白0成本0代码开发App，变现触手可及！

42. 据《The Information》报道，苹果已悄悄阻止 Replit、Vibecode 等 AI“氛围编程”类应用在 App Store 发布更新，除非这些应用做出整改。据IT之家了解，“氛围编程”工具允许几乎没有编程经验的用户，通过自然语言提示词来制作应用或网站，其易用性使其在开发者和非技术用户中迅速普及。苹果向《The Information》表示，部分氛围编程功能违反了长期存在的 App Store 规则 —— 该规则禁止应用执行会改变自身功能或其他应用功能的代码。开发者称，部分此类应用还支持为苹果设备开发软件，这可能导致近期 App Store 新提交应用激增，部分应用审核时间变长。苹果发言人表示，该政策并非专门针对氛围编程应用。但知情人士称，在开发者同意修改应用预览生成内容的方式，或完全移除为苹果平台创建应用等相关功能后，苹果已接近批准 Replit 和 Vibecode 的更新。Replit 等平台生成应用时，通常会通过内嵌网页视图在原应用内展示效果，而苹果对此表示反对。如果该应用调整为在外部浏览器中打开生成的应用，而非使用应用内网页视图，苹果预计将予以通过。知情人士透露，对于 Vibecode，审核团队表示，如果该应用移除专门为苹果设备生成软件的功能，更新很可能会获得通过。《The Information》认为，苹果的干预可能会削弱氛围编程应用的可用性与发展。例如，自 1 月份最后一次更新以来，Replit 移动应用在苹果免费开发者工具榜单中已从第一名跌至第三名。有消息称，该公司将这一下滑部分归因于无法发布更新。氛围编程应用对苹果构成潜在隐患，因为它们允许用户开发在 App Store 生态之外运行的应用，同时也与 Xcode 形成竞争。部分开发者认为，苹果有动机引导开发者使用自家工具，从而提高用户转向其他平台的难度。#刘冲和迪丽热巴聚餐#

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

44. AI 编程时代，程序员如何才能清晰地描述需求，让AI有效地干活？

45. 《扣子开发 AI Agent 智能体应用》018-提示词编写和优化（扣子平台设置提示词案例）

46. 氛围编程的不安真相

47. 氛围编程

48. Vibe Coding（氛围编程）简介

49. Vibe Coding（氛围编程）是AI时代的软件开发方式，核心是用自然语言描述需求，由AI完成代码实现，强调意图而非逐行写代码。

50. 来学氛围编程吧（10）——氛围编程中的“箴言”

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

52. 项目管理做多了，最讨厌这几种模糊需求

53. 别再让模糊指令烧掉你的Token

54. 自我教育的Cursor Code第六课

55. 【522】理论系列 - Prompt 工程

56. ‌开发效率突破

57. 技术速递｜从想法到拉取请求

58. AI的“沟通技巧”？解密提示工程

59. 提示词工程的最佳实践

60. 超棒Claude官方提示词

61. 与AI高效沟通

62. 09集

63. AI编程第一步，很多人都搞错了，不是先写代码，而是先整理需求

64. AI总给你"正确的废话"？四要素指令法来了

65. Vibe Coding最佳实践 - 从0启动需求模板

66. AI代码生成技术深度解析

67. 一份优秀的 AI-native 需求文档，长什么样

68. 【AI 实践之路 4】你真了解 AI Prompt 的四要素？

69. 一个好的Prompt让你从此告别AI猜盲盒

70. 模糊语言变为机器指令

71. Prompt 核心原理

72. 非IT领域专业人士高效利用AI提升专业能力的路径

73. 2026年AI编程工具个人选型指南

74. 84%的开发者已经在用AI写代码了——2026年AI编程工具完全指南

75. AI编程的未来

76. AI编程工具使用技巧

77. 2026程序员生存指南

78. Copilot用不好迟早被优化？5个模板效率翻3倍

79. 微软Copilot帝国解密

80. 为什么 2026 年 Prompt 正在退场，Skills 成标配

81. 亲测2年高效Prompt，快速搞懂全新领域知识

82. 别再卷 Prompt 了，2026 年真正拉开差距的，是 Skills

83. 2026年，不懂Harness Engineering的开发者将被淘汰

84. 从Prompt到Harness

85. 现在是 Harness Engineering 的时代！Prompt Engineering 过时了，Context Engineering 也过时了。2026 年，开发者社区最热的关键词叫 Harness Engineering。

86. Prompt编写技巧

87. Andrej Karpathy 作为"氛围编程（Vibe Coding）"一词的创造者，坦承自身在 AI 驱动编程范式变革中感到落后，并在访谈中系统阐述了从"氛围编程（Vibe Coding）"到"智能体工程（Agentic Engineering）"的演进逻辑。"氛围编程"将软件形态从传统代码文件

88. 氛围编程（Vibe Coding），拯救了专注力缺陷的我！

89. AI Agent 架构设计指南：从上下文约束到生产级实践

90. 《2026 Agent Skills技术与安全白皮书》正式发布 | 中科算网算泥社区

91. AI 提示词框架｜提示词工程结构化学习笔记

92. 《为什么别人用 AI 像开挂，你却越用越失望？问题可能出在 Prompt（提示词）》

93. 提示工程最佳实践：如何与 AI 更好地对话

94. 别再苦哈哈手写Prompt了！用“结构化元提示词”让AI自动生成专属SQL专家

95. 2026全球开发者AI编程工具使用率排行榜TOP20：Stack Overflow数据告诉你，谁才是主流（附Agent技术栈Top10）

96. 来学氛围编程吧（8）——氛围编程带给我哪些改变

97. 跳出“调参”误区：重新理解Prompt Engineering的核心价值

98. 到底有无搞过编程教育？古法编程 VS 氛围编程 > 不需要编程

99. AI编程助手实测：Copilot、Cursor、通义灵码，谁更懂你？

100. 企业内容生成：ChatGPT‑4.1 与 Prompt Engineering 的最佳实践

101. 氛围编程（Vibe Coding）

102. 分享12个工作中常用的AI大模型提示词（Prompt）模板！附带示例

103. 【译】Visual Studio 十月更新 —— 新模型、记忆功能、计划功能及更多内容

104. AI提示词工程蓝图框架文字大纲一、核心逻辑与公式 • 输出质量核心公式输出质量 = 任务清晰度 × 上下文密度 × 约束完整度 × 迭代反馈二、认知纠偏：误区与真相 • 误区1：提示词等于咒语（越玄妙越灵验）真相1：提示词是沟通协议（旨在对齐意图） • 误区2：提示词越长越好（堆砌文字等于效果）真相2：信息密度大于长度（关键在于要素齐全） • 误区3：提示词可以一次成型（不需要迭代）真相3：迭代优于一次成型（由反馈驱动优化） • 本质认知提示词即规格说明书。您所撰写的是“验收标准”，而非“灵感祈祷”。三、目标对齐：把“想要”翻译成可执行任务四个维度： 1. 角色：你是谁？以谁的口吻？ 2. 任务：要做什么？输出什么？ 3. 受众：写给谁？他们懂什么？ 4. 成功标准：怎样算“好”？怎么验收？四、上下文来源 • 背景 / 目标 / 场景：为什么做？用于哪里？ • 资料 / 数据 / 摘要：事实与证据（减少猜测） • 示例 / 反例（Few-shot）：风格可视化 • 限制条件 / 边界：什么不能做？五、快速对齐技巧 • 先问再答：缺什么信息就补充什么 • 写清输出格式：如标题、表格、JSON等 • 给验收条款：列出3条关键指标即可 • 用样例锁风格：提供“像这样”或“不要那样”的示例六、提示词结构模板：6块骨架（按顺序拼装） 1. Role（角色）：你扮演谁？口吻与立场 2. Goal（目标）：要完成什么？需可量化 3. Context（上下文）：必要信息、资料或数据 4. Constraints（约束）：限制与边界 5. Format（格式）：输出结构，如表格、清单 6. Examples（示例）：样例或测试（Few-shot）七、使用建议 • 新手：先使用模板，确保“要素补齐”；其中角色、任务、格式、标准这“四件事最关键”。 • 进阶：将可复用的部分沉淀为提示词库；对同一任务制作3个版本进行对比，寻找关键“变量”。 • 关键：遵循“先对齐，再优化，后自动化”的路径。八、约束矩阵 “约束”并非限制您，而是帮助模型少走弯路，包括： • 范围：做什么 / 不做什么 • 格式：结构 / 字段 / 顺序 • 风格：语气 / 长度 / 受众 • 质量：标准 / 引用 / 替换 • 必须包含：至少必须 / 逐条 • 输出为：表格 / JSON / 清单 • 禁止：不要臆测 / 编造 • 约束式句式：明确的指令框架九、AI辅助能力 AI能帮助您完成：补缺提问 → 改写压缩 → 自检打分 → 生成反例 → 提炼模板将“差在哪里”的分析写入下一版提示词中。十、迭代闭环流程 1. 草稿：拼合模板，确保要素齐全 2. 运行：输入指令，观察输出 3. 评估：对照成功标准进行打分 4. 修补：补充信息，修改约束 5. 沉淀：将优化版本入库复用，形成模板十一、行动清单（今天就能开始） 1. 选择一个高频任务，撰写一版模板提示词 2. 补齐要素：角色、任务、格式、成功标准 3. 让AI先提问：列出缺失信息的清单 4. 对同一任务制作3个版本进行对比，找出最有效的变量 5. 将最佳版本入库：做好命名、标注场景并附上示例总结路径：先对齐 → 再约束 → 后迭代 → 最后沉淀十二、常见大坑（需避免） • 不给上下文：让模型“猜猜看” • 不给格式：导致输出不可用或难以复制 • 没有标准：您自己也不知道如何评估结果 • 指令冲突：例如要求既简短又超详细 • 不迭代：一次不满意就更换模型 #ai #智能体#ai办公 #ai 工具

105. 译文：最佳实践part1

106. 微软 Copilot 秋季更新：协作与个性化双升级

107. 解锁LLM能力：14种Prompt策略全解析与实践指南

108. 29 条 Prompt 设计经验

109. 2026年RAG系统Prompt工程的终极指南

110. 微软Copilot即将上线GPT-5.1，“提醒”与“项目”功能同步曝光

111. 从“氛围编程”看AI走进日常语言

112. 氛围编程的10个提示规则

113. 移动氛围编程的环境搭建

114. 如何写出让AI秒懂的好提示词？手把手教你避开3大天坑（附实战案例）

115. 如何开始氛围编程（Vibe Coding）？一篇真正适合新手的入门指南

116. 不会写提示词？这个神器让我5分钟做出贪吃蛇

117. AI 编程的 Prompt 工程：如何写出高质量指令

118. AI不听话，是你不会下指令，4个要素说清楚！ #AI检测 #AI写作 #流量主 #公众号 #AI提示词提示词4要素公式一、身份设定（Role）给AI确定专业方向和语气风格，越具体越好，避免笼统表述二、任务说明（Task）明确具体工作目标和受众三、约束条件（Constraint）划定输出边界，控制内容规格常见约束项 4、进阶技巧，场景化背景任务 + 背景信息 + 具体场景

119. 2026年了，程序员都在用什么AI编程工具？

120. 什么是氛围编程（Vibe Coding）？

121. 氛围编程实例亲体验：可“无知”到何种程度?

122. 开发了2个Skiils，用AI编程的方式写提示词，终于可以早点下班啦～

123. 09：跟AI说需求，记住这4点就足够了

124. 什么样的智能提示语，才算是对 AI 友好的高质量输入？

125. 90分钟信息素养公开课09 | Vibe Coding 氛围编程，在“愉悦”的氛围里看AI帮你开发软件

126. Vibe-Coding（氛围编程）

127. 2026年AI 编程工具排行榜：从新手到专家的最佳选择

128. 别再用GPT写代码了！通义灵码这个AI程序员让开发效率飙升的秘密

129. 来学氛围编程吧（3）——氛围感的语言基石

130. ReCo：指令式视频编辑的新突破——区域约束上下文生成框架详解

131. AI提示词终极公式：BROKE框架 + 4个实战模板，拿去就能用

132. 上下文工程与优秀架构示例

133. 2026年大洗牌！面对AI编程全面爆发，普通开发者该做好哪些准备？

134. 实测对比：ThinkDiffusion类SD专用云平台 vs 通用GPU云主机，非技术用户该怎么选？

135. AI写小红书和公众号为什么限流？如何写出好的AI提示词和工作流？分享真实实操步骤和方法

136. 国产AI编程工具崛起：Trae vs 通义灵码

137. VSCode × 通义灵码：零基础小白的 AI 编程神器完全指南

138. AI提示词常见误区❗质量词真不是越多越好

扫一下，分享更方便，购买更轻松

0评论

当前文章无评论，是时候发表评论了

提示信息

取消

确认

评论举报

垃圾广告！低俗色情！人身攻击！疑似水军评论！其他有害！