Twitter AI 编程 - 2026-07-15¶
1. 人们在讨论什么¶
1.1 Google 的编程叙事，正从一个泄露模型扩展成整张平台地图 (🡕)¶
当天互动量最大的内容，主要都围着 Google 的帖子转，但证据本身却分散在传闻、生态营销和直白的产品困惑之间。两条高互动的泄露帖，把 Gemini 3.5 Pro 描述成即将发布；而另外一些讨论量较低、却更具体的帖子，则试图把 Gemini CLI、Antigravity、Jules、ADK 和 A2A 讲成一套彼此连通的开发栈。
@LuminaXspace 发了一串 未经验证的 Gemini 3.5 Pro 传闻：7 月 17 日为目标日期、一次新的预训练跑数、一个 2M-token 上下文窗口，以及更强的编程和推理能力（321 点赞、24 回复、25,732 浏览量、45 收藏）。真正有用的信号，并不是其中哪一条说法在今天被证实了，而是：在没有官方基准测试、也没有产品页的情况下，一条关于编程模型发布的传闻就已经主导了注意力。
@ottleyai 认为，Google 正在打造的是一整套全栈 AI 生态，而不是追逐单个模型的胜利（21 点赞、14 回复、1,290 浏览量、11 收藏）。配图是这条讨论里最清晰的产物：它把 Gemini、Gemma、Stitch、Whisk、NotebookLM、Veo、Flow、Google Vids、Antigravity、Gemini CLI、Jules、ADK、A2A 和 FileSearch API 都归进了同一个开发界面。
@ishivgaur 分享了 Linus Torvalds 的 AudioNoise 仓库截图，其中一条 commit message 写着：Google Antigravity 在把内建矩形选择器替换成自定义版本之后，帮忙修好了一个可视化工具（8 点赞、4 回复、175 浏览量）。这张图之所以重要，是因为它给出的是具体的使用证据，而不是又一句生态口号。
@pigeon__s 在引用转发里追问，Jules V2 预告出来之后，Jules 到底还算不算一个独立于 Antigravity 的产品（43 点赞、1,982 浏览量）。这是当天最尖锐的反向信号：就连高度关注这条线的人，也已经很难跟上 Google 当前到底哪一层编程界面才是主线。
讨论要点： Gemini 泄露帖下面的回复，大多是在要证据，或者表示希望再来一个够格的前沿竞争者。真正更强的矛盾信号，出现在 Jules 那条讨论串里：问题已经不是性能怀疑，而是产品地图本身让人混乱。
与前日对比： 在 2026-07-14 的报告里，Google 相关讨论还更聚焦于 Antigravity 这个智能体界面。到了 2026-07-15，叙事已经扩展成更大的 Google 栈故事，但扩展的同时，也把命名和产品边界的困惑一起带了进来。
1.2 智能体状态正在走出编辑器，出现在 Jira、手机和硬件上 (🡕)¶
第 2 个主题，是那些已经在运行中的工作，该如何被观察和控制。最强的产品证据来自 GitHub 的 Jira 集成，以及 Visual Studio 里的使用情况功能；与此同时，构建者和配件厂商也在探索如何借手机和硬件界面监控、引导智能体。
@github 宣布，GitHub Copilot for Jira 已经正式 GA（80 点赞、9 回复、22,787 浏览量、28 收藏）。GitHub 的 GA 更新日志写明，这次发布新增了在 Jira issue 中流式展示智能体进度、在 Jira 聊天面板里对同一份草稿 PR 做会后引导，以及更简单的入门流程；同时也提到更早预览期加入的模型选择、通过 MCP 接入 Confluence 上下文、自定义智能体和自定义字段。回复区的热情明显低于公告本身，更多是在提醒：AI 生成的 ticket 垃圾内容和自动评论噪声，很可能随之而来。
@GHchangelog 发布了 一次 Visual Studio 更新；那份官方更新日志加入了实时 Copilot 用量追踪和告警、针对 MCP server 指纹的信任校验、PR 到聊天上下文的导入，以及 C++ modernization GA（19 点赞、1 回复、2,046 浏览量、4 收藏）。这代表的是一种很有意义的转向：不再只是“IDE 里有智能体”，而是“IDE 里能看见智能体的成本和工具信任边界”。
@ridark_eth 推广了 Orca，把它定位成一种能并排运行 Claude Code、Codex、Copilot 等 CLI 智能体的方式（23 点赞、12 回复、347 浏览量、13 收藏）。Orca 仓库和它的移动端文档都支撑了这些核心说法：隔离的 git worktree、手机通知和回复，以及账号级的用量状态追踪。
@testingcatalog 重点提到 Work Louder 的 Codex Micro；它的产品页写明，RGB 按键会反映智能体状态，而命令键、摇杆和旋钮则让用户可以触发工作流，并调整推理深度（20 点赞、2 回复、2,089 浏览量）。这条帖子互动量不算高，但它是一个很值得注意的信号：智能体监督已经开始长成一个硬件品类。
讨论要点： Jira 那条讨论串给出了一个很明确的警告：所谓“AI 进入工作流”，很容易滑成“AI 生成工作流噪声”。而 Orca 和 Codex Micro 那两条帖子则说明了相反的需求：当智能体需要人接手时，用户想要更明确的状态、更快的介入，以及更少的上下文切换。
与前日对比： 昨天最强的监督界面，还是 GitHub Mobile 里一个需要输入的远程会话。到了今天，同样的监督逻辑已经出现在 Jira、Visual Studio 的用量窗口、移动端伴侣应用，甚至专门硬件里。
1.3 团队开始把智能体循环正式化，而不只是更用力写提示词 (🡕)¶
第 3 个主题是流程加固。比起庆祝原始生成速度，当天更好的帖子都在试图：在执行前先去掉歧义、把工具显式暴露出来、减少 token 浪费，或者限制被委派出去的智能体到底能做什么。
@RituWithAI 认为，GitHub 的 Spec Kit 存在的意义，就是防止智能体以极快速度把错的东西做出来（11 点赞、4 回复、164 浏览量、6 收藏）。Spec Kit 仓库和 GitHub 的规格驱动开发文章都支撑了这个核心工作流：先走 constitution、specify、plan、tasks，最后再 implement，并把 spec 当成持续更新的事实来源。
@TheCodeMan__ 分享了 一个很具体的 .NET MCP server 示例（10 点赞、3 回复、296 浏览量、3 收藏）。他的starter kit 页面和深度文章描述了一个性能实验室：Copilot agent mode 可以从聊天提示词里触发压测、比较端点、汇报 p95 / p99 延迟，并标记 thread-pool starvation。
@RetroChainer 声称，RTK 在不改代码的前提下，大约能把 shell 驱动的 token 消耗砍掉 80%（37 点赞、12 回复、1,158 浏览量、20 收藏）。RTK 仓库也写了同样的基准测试轮廓，并表示这个代理会在命令输出到达模型之前先做压缩；但这条讨论串里最有用的一条回复，问的正是那个最显眼的问题：过滤得太狠，会不会把智能体真正需要的 stack trace 也一起藏掉？
@thdxr 表示，OpenCode 的 subagents 很快会需要额外配置，才能再去调用更多 subagents（19 点赞、3 回复、978 浏览量）。这个小改动之所以重要，是因为它把“委派”重新定义成一个权限设计问题，而不只是能力设计问题。
讨论要点： 这几项内容的共同动作，是在执行前或执行周围给智能体工作加结构：先定义 spec、显式暴露真实工具、压缩 shell 噪声，或者把递归委派改成默认不启用。RTK 那条讨论串给出的最有价值质疑，则是：如果压缩得太猛，到底会丢掉什么关键信息？
与前日对比： 在 2026-07-14，人们主要还在把工作路由给不同模型和智能体。到了 2026-07-15，更强的信号已经变成工作流纪律：显式的规格、显式的工具、显式的预算，以及显式的委派规则。
2. 令人困扰的问题¶
彼此重叠的产品界面，让人很难判断工作到底该放哪一层¶
严重程度：中。围绕 Google 的讨论说明，生态变宽本身已经开始制造导航问题。@pigeon__s 追问 Jules V2 预告出来以后，Jules 是否已经实际上被并进了 Antigravity（43 点赞、1,982 浏览量）；而 @ottleyai 推广了 一张覆盖 Gemini、Antigravity、Jules、ADK、A2A、FileSearch API 等产品的地图（21 点赞、14 回复、1,290 浏览量、11 收藏）。这里的挫败感，不是人们反对 Google 的工具，而是不知道该学哪一层、采纳哪一层，或者到底该把哪一层当成更耐久的界面。这个方向值得做，因为现在肉眼可见的失效模式，是在真正开始写代码之前，注意力就先被浪费掉了。
围绕智能体动作的信任边界，看起来仍然很脆弱¶
严重程度：高。@Hamaaadite 提到了 GhostApproval，而公开的 Wiz 报告和 CSA 说明都描述了一种跨 6 个编程助手的、基于 symlink 的批准漏洞，其中就包括 Claude Code 和 Google Antigravity。重点并不是抽象的安全理论：提示里看起来像在改一个无害文件，真正写进去的却可能是 ~/.ssh/authorized_keys 或其他敏感目标。
@xyz3va 抱怨，此前上报过的 OpenCode 安全问题仍未得到确认，但移动端应用却已经在被推广（77 点赞、5 回复、4,658 浏览量）。这当然是一种单方面指控，但它仍然是信任正在流失的有用证据。@thdxr 又补了一条 更小、但相关的变化：嵌套 subagents 将需要额外配置，这说明在生产环境里，委派规则仍然敏感到需要继续收紧（19 点赞、3 回复、978 浏览量）。这个方向值得做，因为用户显然想要更强的智能体能力，但前提是：批准界面和委派规则得是他们真的能推理清楚的。
团队更容易看见花费，而不是看见价值¶
严重程度：高。几条帖子都收敛到了同一个运营抱怨：成本和用量已经越来越可测，但工程产出回报却还没有同步可见。@Herald_Dev 认为，团队已经在为 Claude Code 或 Cursor 付费了，但还没有一个可靠办法，去区分“高产而自律的使用者”和高花费的“tokenmaxxer”（3 点赞、1 回复、62 浏览量）。那张附图虽然没有公开方法学，但已经足够把这个抱怨说明白。
@GHchangelog 发布了 带用量告警的 Visual Studio 更新，@burkeholland 展示了 一个会暴露隐藏模型切换成本的 cache-miss 扩展（43 点赞、3 回复、2,837 浏览量、27 收藏），而 @ludvigrask_ 分享了 OpenCode Console 的计费界面，里面有席位、发票和自动充值阈值（6 点赞、1 回复、70 浏览量）。
@RetroChainer 声称，RTK 通过压缩 shell 输出，可以显著削减 token 消耗；但就连这条讨论串，最后也还是落回到一个问题：省下来的成本，会不会是拿丢失调试细节换来的？Orca 的用量追踪文档则从另一个角度证明了同样的需求：人们希望在会话卡住前，就能看见剩余额度和重置时间。这个方向值得做，因为今天的应对方式，仍然只是手工盯数据、切仪表盘和临时做压缩，而不是一个可信的 ROI 视图。
工作流原生的智能体，也可能制造工作流原生的噪声¶
严重程度：中。GitHub Copilot for Jira 引起的最明确反弹，并不是“这个产品不该存在”，而是它可能会进一步放大本就嘈杂的项目管理习惯。针对 @github 宣布 Jira GA 的帖子（80 点赞、9 回复、22,787 浏览量、28 收藏），多条回复都预测会出现幻觉式验收标准、自动生成的 ticket 洪流，以及让纸面生产力看起来更好、却会稀释团队信号质量的自动评论。这个产品确实加入了流式进度和会后引导等真实控制点，但肉眼可见的担忧是：管理界面比起变得更有用，往往更容易先变得更乱。这个方向值得做，前提是智能体活动能被总结和路由，而不是把审查噪声再乘一层。
3. 人们期望的功能¶
一张从聊天、到智能体、再到整个产品家族的一致地图¶
围绕 Google 的讨论，暴露出一个很实际的需求：少一些彼此重叠的标签，多一些不同界面之间的连续性。@pigeon__s 追问，Jules 是否已经被并进了 Antigravity（43 点赞、1,982 浏览量）；而 @ottleyai 给出了一张 横跨 Google 模型、编程工具和智能体基础设施的地图（21 点赞、14 回复、1,290 浏览量、11 收藏）。这个需求不是理想化想象，而是很务实：用户想知道哪一层负责哪类工作，以及资产或 skills 到底怎么在这些层之间流动。机会：直接。
能把真实风险说清楚的批准与委派控制¶
GhostApproval 说明，用户不能只靠那种泛泛的“批准这次编辑”提示，因为路径本身就可能带有误导。@Hamaaadite 把这个问题挑了出来（2 回复、113 浏览量），而 @thdxr 又提到，嵌套 subagent 的生成现在正被推到额外配置之后（19 点赞、3 回复、978 浏览量）。隐含的要求，是一套在执行或委派之前，就能暴露规范目标、继承权限和升级规则的系统。机会：直接。
面向产出的 ROI 追踪，而不是只看原始 token 遥测¶
几条帖子共同指向了一个位于简单用量计量表之上的缺失管理层。@Herald_Dev 认为，脱离产出语境来看花费，几乎没有意义（3 点赞、1 回复、62 浏览量）；与此同时，@GHchangelog 宣布了 Visual Studio 里的实时用量告警（19 点赞、1 回复、2,046 浏览量、4 收藏），而 Orca 的文档则描述了一种会考虑重置时间的用量显示。务实的需求，是把额度、延迟和成本，和真正交付出去的工作、审查负担及缺陷率连起来。机会：竞争激烈。
在执行前强制澄清的规格与工具契约¶
Spec Kit 是当天供给侧对一个明确需求给出的最清楚回应：人们希望智能体在开始动手前先问清楚。@RituWithAI 描述了 “错规格”这个问题（11 点赞、4 回复、164 浏览量、6 收藏），而 @TheCodeMan__ 展示了，当智能体拿到的是明确的 MCP 工具，而不是含糊指令时，系统会是什么样（10 点赞、3 回复、296 浏览量、3 收藏）。真正的需求，是让需求、可调用工具和验证标准在模型开始即兴发挥前，就都被明确下来。机会：直接。
4. 使用中的工具与方法¶
| 工具 | 类别 | 评价 | 优势 | 局限 |
|---|---|---|---|---|
| Google Antigravity + Jules + Gemini CLI | 智能体平台家族 | (+/-) | 被包装成一套横跨模型、CLI、IDE、异步编程和智能体基础设施的 Google 开发栈 | 产品边界依然模糊到用户还在问 Jules 和 Antigravity 是否是两个东西 |
| GitHub Copilot for Jira | 项目管理集成 | (+/-) | 把编程智能体进度流式写进 Jira，支持在同一份 PR 上继续引导，简化入门流程 | 回复预测会带来 ticket 垃圾内容、自动评论和幻觉式工作流噪声 |
| GitHub Copilot in Visual Studio | IDE 遥测与信任界面 | (+) | 实时用量告警、MCP 指纹校验、PR 上下文导入、C++ modernization GA | 提升了可见性，但仍无法单独回答 ROI 或代码质量问题 |
| Cache-miss Copilot extension | Copilot 扩展 | (+) | 在实时会话里直接展示缓存断点和模型切换代价 | 仍是个人扩展案例，而不是标准产品能力 |
| Spec Kit | 工作流工具包 | (+) | 先把需求转成 spec、plan 和 tasks；可跨多种编程智能体使用 | 会增加流程开销，而且每个阶段都依赖人类认真审查 |
| AI in .NET Starter Kit / MCP Server | MCP 开发工具链 | (+) | 给 Copilot agent mode 提供明确的性能测试工具、p95 / p99 分析和实用编排示例 | 教学示例，明确不以生产就绪为卖点 |
| RTK | CLI 代理 / token 优化 | (+/-) | 压缩嘈杂的 shell 输出、降低 token 消耗、开销低、覆盖多类智能体 | 只对 shell 驱动的输出路径有帮助；压缩过头可能掩盖调试细节 |
| Orca | 多智能体 ADE | (+) | 并行 worktree、手机控制、用量追踪、SSH worktree、GitHub / Linear 集成 | 智能体和账号越多，编排复杂度越高 |
| OpenCode | 编程智能体 | (+/-) | 真实用户报告它能有效排障；内置 build / plan 智能体和桌面应用扩大了触达面 | 围绕未解决安全问题的公开信任抱怨，削弱了产品叙事 |
| Codex Micro | 智能体控制硬件 | (+/-) | 实时状态按键、命令按钮、摇杆和旋钮，为 Codex 提供触觉控制界面 | 设备高度绑定单一产品，也多出一层需要管理的新界面 |
满意度光谱，一端是务实的工作流辅助，另一端则是明确的信任焦虑。人们并没有放弃前沿智能体；他们是在它们周围一层层加控制：Visual Studio 里的用量窗口、Copilot 里的缓存可见性、OpenCode 的计费页，以及 Orca 手机上的监督界面。迁移模式也依然不是赢家通吃。Orca 的价值主张，是让 Codex、Claude Code、Copilot 等并排运行；而 TheCodeMan 的 MCP 示例，则默认任何兼容客户端都应该能调用同一组工具。当天最常见的权宜方案，是显式结构：先做 spec、显式暴露 MCP 工具、压缩 shell 输出、在本地监控用量，而不是寄希望于某个单一模型或单一 UI 能把整个循环都解决掉。
5. 人们在构建什么¶
| 项目 | 构建者 | 功能 | 解决的问题 | 技术栈 | 阶段 | 链接 |
|---|---|---|---|---|---|---|
| Spec Kit | GitHub | 把需求提示词转成 spec、plan、tasks 和落地工作流 | 减少由模糊提示词导致的智能体“跑错方向”编程 | specify CLI、markdown 产物、跨智能体 slash commands |
Shipped | 仓库 |
| AI in .NET Starter Kit / MCP Server | @TheCodeMan__ | 给智能体提供可调用的 .NET 工具，用于 API 性能测试和分析 | 让 MCP 进入真实开发者工作流，而不是停留在玩具 demo | ASP.NET Core、MCP、Blazor、自定义压测引擎、GitHub Copilot agent mode | Shipped | Starter kit |
| RTK | rtk-ai | 在 shell 输出到达编程智能体之前先做过滤和压缩 | 降低重复命令输出带来的 token 浪费 | Rust、CLI 代理、shell hooks | Shipped | 仓库 |
| Orca | StablyAI | 在并行 worktree 里同时运行多个 CLI 编程智能体，并配合移动端监督 | 让一个开发者可以同时比较并引导多个智能体 | 桌面应用、移动端伴侣、git worktrees、SSH、GitHub / Linear 集成 | Shipped | 仓库 |
| GitHub Copilot for Jira | GitHub | 把编程智能体执行、进度和后续引导带进 Jira | 让 ticket 上下文和智能体进度留在规划工作流里 | GitHub Copilot、Jira、通过 MCP 获取 Confluence 上下文 | Shipped | 更新日志 |
| Codex Micro | Work Louder | 一个用于监控和引导 Codex 智能体的实体控制器 | 给用户提供可触摸的状态与命令控制，而不是再加一个漂浮窗口 | RGB 状态键、命令键、摇杆、旋钮、Codex 直连 | Beta | 产品页 |
当天最强的构建模式，并不是“新模型打败旧模型”，而是“给现有智能体包一层更好的工作操作系统”。@RituWithAI 把 Spec Kit 形容成一种在写代码前强制澄清需求的方法（11 点赞、4 回复、164 浏览量、6 收藏）；而 @TheCodeMan__ 分享了 一个性能测试 MCP server，让 Copilot 能调用真实工具并解释结果（10 点赞、3 回复、296 浏览量、3 收藏）。@RetroChainer 则从成本侧强调了 同样的模式：不要改智能体本身，改的是它能看到什么上下文（37 点赞、12 回复、1,158 浏览量、20 收藏）。
第 2 个模式，是围绕“正在运行中的智能体工作”去做监督和恢复。@ridark_eth 推广了 Orca，把它当成并排智能体的舰队控制器（23 点赞、12 回复、347 浏览量、13 收藏）；而 @testingcatalog 展示了 Codex Micro，这相当于是把同样的想法做成实体设备（20 点赞、2 回复、2,089 浏览量）。在支持侧，@cocktailpeanut 分享了 一张用户截图：OpenCode 发现 Pinokio 安装器抓错了包名，并通过更新配置修复了这个冲突（8 点赞、809 浏览量、4 收藏）。
这张截图之所以重要，是因为它展示了当天智能体工具最务实的形态：不是一个基准测试，而是一段真实坏掉的安装流程，被嵌在工作流里的助手排查并修好了。
6. 新动态与亮点¶
GhostApproval 把老式 symlink 漏洞，变成了 AI 智能体的信任问题¶
@Hamaaadite 把 GhostApproval 提出来，称其是一个跨品类缺陷（2 回复、113 浏览量）；而公开的 Wiz 文章和 CSA 说明则把它的新意讲得很清楚：问题不只是会跟随 symlink，而是批准界面把真正的目标文件藏了起来。这件事之所以重要，是因为很多智能体安全承诺，本质上都建立在人类批准是“知情批准”的前提上。
仓库攻击演练，正在变成智能体时代的一项运营技能¶
@BradGroux 报告，自己赢下了 GitHub 的 “Repository Under Attack” 红队工作坊（10 点赞、1 回复、20,203 浏览量）。配图说明了它为什么值得注意：这条事故路径同时串起了 PAT 泄露、deploy keys、恶意 npm 发布、GitHub Actions secrets，以及跨仓库凭证。讨论串里最有用的细节在于：Codex、OpenClaw 和 Copilot app 只有在团队同时把证据、决策、隔离动作和验证紧密串起来时，才真正有帮助。
触觉界面和计费界面，开始被算作智能体功能的一部分¶
当天也清楚表明，“智能体 UX”如今已经包括硬件旋钮和财务面板。@testingcatalog 展示了 一个面向 Codex 的控制器（20 点赞、2 回复、2,089 浏览量），而 @ludvigrask_ 分享了 一个带席位、发票时间和自动充值阈值的计费页面（6 点赞、1 回复、70 浏览量）。这组组合之所以值得注意，是因为它说明下一层竞争，已经不只是模型质量，而是工具能否把状态、花费和介入点说清楚。
7. 机会在哪里¶
[+++] 不牺牲信任的智能体权限和批准 UX —— GhostApproval 说明，只要工具隐藏了规范目标文件，用户就无法安全批准动作；而 OpenCode 对嵌套 subagent 的调整，以及围绕安全问题的公开抱怨，也都说明委派规则仍未稳定。一个能在执行前就暴露真实文件目标、继承权限和升级边界的产品，会直接回应这批样本里最强的信任痛点。
[+++] 面向产出的 ROI 与预算控制 —— Visual Studio 的用量告警、Orca 的用量追踪、OpenCode 的计费界面、RTK 关于 token 压缩的说法，以及 Herald 那张产出对比花费的图，都指向同一个缺失层：团队已经能看见成本和限额，却还看不见稳定的工程回报。最强的机会，是做出一个把额度、延迟、审查负担和交付产出绑在一起的控制平面。
[++] 没有工作流垃圾内容的工作流原生监督 —— Jira GA、Orca mobile、Codex Micro，以及 GitHub 更广泛的监督界面，都说明用户需要能在智能体运行过程中观察和引导它们。反向信号则是对 ticket 垃圾内容和自动评论噪声的担心。这里有空间容纳这样一类产品：它们能总结工作、只请求高价值的人类介入，并且在不放大项目管理噪声的前提下保留可追溯性。
[+] 规格优先、且由 MCP 支撑的执行工具包 —— Spec Kit 和 TheCodeMan 的 .NET MCP 示例，都给出了一条摆脱模糊提示词的务实路径：先把意图讲清楚，再暴露明确工具，最后用具体输出做验证。一个正在冒出来的机会，是为真实工程任务打包一批领域化 starter kit，把需求结构、工具契约和验证循环一起装进去。
8. 要点总结¶
- Google 抢走了当天的大部分心智，但主要靠的是生态叙事和传闻，而不是经过验证的产品证据。 那条互动量最高的 Gemini 3.5 Pro 帖子明确是未经验证的，而最具体的产物，其实是一张把 Gemini、Antigravity、Jules 和智能体基础设施捆成一个故事的栈地图。(来源)
- 可见的前沿，已经不只是“更快地写代码”，而是“如何监督并引导已经在运行中的工作”。 Jira GA、Visual Studio 用量告警、Orca mobile 和 Codex Micro，都在把智能体状态推到用户能中途介入的地方。(来源)
- 信任和安全，已经成了编程智能体的一等产品需求。 GhostApproval 把经典的 symlink 漏洞，变成了一次“知情批准失败”；与此同时，围绕未解决问题的公开抱怨，以及对子智能体权限的收紧，也都说明用户正在紧盯这些边界。(来源)
- 最强的构建者能量，投向的是智能体周围的结构，而不是替换模型。 Spec Kit、MCP server 示例、RTK，以及那些真实世界的排障帖子，关注的都是如何定义意图、暴露工具、减少噪声，或让恢复更容易。(来源)