Twitter AI 编程 - 2026-07-19¶
1. 人们在讨论什么¶
1.1 技能与规格正在成为智能体周边的可复用层 🡕¶
当天最强的实践主题，是封装可复用的工程判断，而不是每次从零开始给模型写提示词。一则高互动讨论串将 GitHub 的 Spec Kit 描述为 6 步流程，从项目章程出发，依次经过规格、规划、任务，最终落地；另一个讨论串则将智能体技能视为可安装的资源。证据也表明，解决发现问题并不等于做好质量控制：技能目录作者估计，其中只有约一半有用，并特别指出一个规模更小、值得信任的核心集合。
@DivyanshT91162 介绍了（124 个赞、6 条回复、11,538 次浏览、262 次收藏）Spec Kit，将其描述为一种工作流，可把创意转化为多个编程智能体都能执行、持续演进的规格。Spec Kit 仓库介绍了同一套开源流程，并记录章程、规格制定、规划、任务和落地各阶段；一条回复还指出一个重要局限：规格发生漂移时，智能体仍会出错。
@undefinedKi 重点介绍了（89 个赞、20 条回复、8,833 次浏览、160 次收藏）skills.sh，将其称为跨智能体的包管理器和目录。所附目录截图内容颇为具体：它将技能分成规划、TDD、调试、文档、设计和工具链，而不是笼统地当作提示词。
讨论要点： 实际争议并非技能有没有帮助，而是如何筛选。skills.sh 作者表示，Anthropic、Vercel 和 Obra 的材料构成了可靠核心，其余部分仍需过滤。
与前日对比： 7 月 18 日的讨论已将技能发现推到重要位置。7 月 19 日又出现了更清晰的互补模式：技能封装可复用流程，规格则约束这些流程要执行的工作。
1.2 长时间运行的智能体带来规划与验证问题 🡕¶
围绕循环、编排和多模型路由的推文强调执行纪律，而不是决出某个模型冠军。具体建议包括：设置可验证的最终状态，检查计划而非全盘接受，分离创建者与验证者角色，并根据上下文、部署方式、权限和可靠性分派工作。
@petergyang 分享了（14 个赞、3 条回复、1,435 次浏览、9 次收藏）对一名 Claude Code 团队成员的访谈，内容涉及 /loop、/goal 和工作流。配套文章称，/goal 需要可验证的终点，计划应由人手动阅读，分设创建者和验证者子智能体也很有用；文章还称 Claude Code 的系统提示词缩减了 80%。
@prasad_pilla 描述了（6 个赞、4 条回复、245 次浏览）一种软件工厂方法，将 Claude 和 GPT 作为可互换的执行后端，用于规划、读取仓库、打补丁、审查、测试、调试和交接。Alan 网站将模型无关性以及 SaaS、混合、本地和隔离网络部署列为产品选项，与推文强调的路由和运营可靠性一致。
@Trion129 表示（3 个赞、1 条回复、167 次浏览、4 次收藏），使用 oh-my-opencode-slim 后用量降低，同时质量仍可接受。其仓库记录了专用后台智能体、多模型委员会运行、模型预设、内置验证技能和可配置权限；不过，用量说法本身仍只是单个用户的体验。
讨论要点： 反复出现的最大制约不只是模型质量。一条 Kimi CLI 回复警告，加载更多仓库上下文反而可能让智能体在不再暴露不确定性时，更加自信地犯错。
与前日对比： 7 月 16 日的讨论集中在独立评分、技能和范围明确的委派通道。7 月 19 日沿着这一方向提供了更多操作细节：可验证目标、明确分离创建者与验证者、模型路由，以及考虑权限的编排。
1.3 评价编程助手的标准仍包括界面能力和运营可靠性 🡒¶
GitHub Copilot 计划推出的 Markdown 提示词编辑器、XDA 对 3 款工具的仪表板对比，以及用户反馈的 Codex 性能问题，让当天的讨论始终立足于智能体的实际使用体验。对比证据范围有限，但十分具体：同一份仪表板需求让 Copilot 快速交付了较浅的结果，Claude Code 的结果更完整但 token 消耗更高，而作者最喜欢 Codex 的结果。
@basiclines 宣布（97 个赞、7 条回复、20,012 次浏览、63 次收藏），GitHub Copilot 应用的早期员工预览版已支持 Markdown 提示词。一则引用推文称，下一步计划推出功能更强的提示词编辑器；回复则追问，除了图像和附件之外，更丰富的提示方式究竟有何实际好处。
@xdadevelopers 对比了（10 个赞、4,003 次浏览、2 次收藏）Claude Code、Codex 和 GitHub Copilot 处理同一份财务仪表板需求的表现。所链接的对比文章称，Copilot 速度最快但留下静态工作流，Claude Code 功能更深入但速度较慢且接近用量上限，而 Codex 在完善度与完整性之间的平衡最受作者青睐。
@jun_song 扩大传播了（54 个赞、21 条回复、6,149 次浏览、19 次收藏）有关 Codex 导致 Mac 卡顿和 SSD 过量写入的报告。无法独立获取所链接的 Reddit 报告，因此这只是用户反馈的担忧，并非已确认的缺陷；但截图和回复明确表明，用户希望得到解释和可靠的缓解办法。
2. 令人困扰的问题¶
缺少明确验证时，智能体输出仍难以信任¶
严重程度：高。围绕循环的讨论明确指出了故障模式：人们可以让智能体运行更久，但这并不能证明结果正确。@petergyang 分享了（14 个赞、3 条回复、1,435 次浏览、9 次收藏）有关先找出未知项再做规划，以及不要只粗略扫一眼 AI 计划的建议；来源文章建议设置可验证的最终状态，并分设创建者和验证者智能体。在 @RituWithAI 的推文下，一条 Kimi CLI 回复认为（9 个赞、4 条回复、243 次浏览、6 次收藏），更多仓库上下文没有让智能体更敏锐，反而让它更加自信地犯错。目前可见的权宜方案是人工审查并增加一次独立评估；这值得开发产品来解决，因为它是直接的运营缺口，而不是要求再造一个模型。
技能过剩带来筛选和信任难题¶
严重程度：中。@undefinedKi 推广了（89 个赞、20 条回复、8,833 次浏览、160 次收藏）一个拥有 930,000 多项技能的目录，但评论者立即追问其中究竟有多少真正有用。作者自己回答说或许有一半有用，且少数发布者构成可靠核心，这也明确揭示了应对办法：用户仍需自己筛选技能库，或再让一个智能体代劳。这值得开发产品来解决，因为分发机制已经存在，但质量、来源和任务匹配度仍需人工判断。
对可靠性的担忧可能压过编程助手的能力主张¶
严重程度：高，但未经验证。@jun_song 转述了（54 个赞、21 条回复、6,149 次浏览、19 次收藏）用户关于 Codex 过载导致 Mac 卡顿和 SSD 损耗的说法；一条回复描述了过热和尝试重新安装的情况。无法独立审查所链接的报告，因此证据不能确立因果关系，但它确实表明，用户想要清晰诊断和安全补救，而不是功能建议。这值得从透明的智能体资源遥测和支持工具方向开发产品。
3. 人们期望的功能¶
可信地选择和安装智能体技能的方法¶
skills.sh 讨论串直接表明，实际需要的是选择机制，而不是更大的目录。@undefinedKi 介绍了（89 个赞、20 条回复、8,833 次浏览、160 次收藏）支持跨多种智能体的包式安装方案，而讨论将可信范围缩小到少数具名发布者，并建议让 Claude 筛选目录。一个实用但缺失的中间层，应在安装前展示质量证据、发布者来源、兼容智能体、权限和任务触发条件。机会：直接。
防止规格和长期工作偏离轨道的安全护栏¶
Spec Kit 的结构化阶段与 Claude Code 访谈指向同一需求：从需求到验证，智能体工作都应带有清晰易懂的终点。@DivyanshT91162 分享了（124 个赞、6 条回复、11,538 次浏览、262 次收藏）规格优先的工作流，但一条回复警告，规格漂移仍会产生错误；@petergyang 分享了（14 个赞、3 条回复、1,435 次浏览、9 次收藏）相辅相成的建议：设置可验证目标并阅读计划。这是委派多步骤工作的用户面临的实际且迫切的需求。机会：直接。
统一管理多模型、多环境执行的运营层¶
@prasad_pilla 表示（6 个赞、4 条回复、245 次浏览），生产环境中的差异不仅体现在代码生成质量，还包括上下文、路由、本地或云端执行、身份验证、权限和运行时启动。@Trion129 补充了（3 个赞、1 条回复、167 次浏览、4 次收藏）个人使用多模型委派后用量降低的反馈。人们需要一个控制界面，清晰呈现跨智能体的路由、成本、能力和审批选择。机会：竞争激烈。
4. 使用中的工具与方法¶
| 工具 | 类别 | 评价 | 优势 | 局限 |
|---|---|---|---|---|
| Spec Kit | 规格驱动开发 | (+/-) | 记录了一套可复用、从章程走向落地的工作流，适用于不同编程智能体 | 一条回复称，规格可能发生漂移，仍会导致智能体出错 |
| skills.sh | 智能体技能注册表 / 包管理器 | (+/-) | 可跨多个智能体安装、查找、列出、更新和移除技能 | 作者估计目录中只有约一半有用，仍需筛选 |
Claude Code /goal、/loop 与工作流 |
智能体执行方法 | (+) | 使用可验证终点、迭代规划、并行任务，并分离创建者和验证者 | 需要人来阅读计划，并定义真正可检查的结果 |
| Kimi CLI | 终端编程智能体 | (+/-) | 支持在终端编辑文件、执行 shell 命令、获取网页、使用 MCP 与 ACP，以及自主规划 | 仓库正向 Kimi Code CLI 过渡；一条回复质疑更多上下文能改善结果的假设 |
| oh-my-opencode-slim | 多模型智能体编排器 | (+) | 提供专用后台智能体、模型预设、多模型委员会和可配置权限 | 用量降低的说法来自单个用户，而非受控对比 |
| GitHub Copilot 应用提示词编辑器 | 编程智能体界面 | (+/-) | 在早期预览中加入 Markdown 提示词，并计划推出能力更强的编辑器 | 回复要求提供更明确的证据，证明它除了丰富输入格式外还有实际好处 |
| Codex、Claude Code 与 GitHub Copilot 对比 | 编程智能体对比 | (+/-) | 用同一份仪表板需求展现速度、功能、设计和 token 用量之间的取舍 | 这是单个作者针对一款应用的测试，并非通用基准测试 |
满意度更偏向结构化的多阶段工作，而不是忠于某个模型。Claude Code 访谈建议移除过时指令并将验证分离；Alan 使用者的描述则把路由、权限、部署和运行时可靠性放在与模型选择同等的位置。明显的迁移趋势是把模型当作可互换的执行通道，而主要制约仍是持续需要人工审查、筛选和资源透明度。
5. 人们在构建什么¶
| 项目 | 构建者 | 功能 | 解决的问题 | 技术栈 | 阶段 | 链接 |
|---|---|---|---|---|---|---|
| Kimi CLI | @RituWithAI 分享 MoonshotAI 的项目 | 可编辑代码、运行命令、获取页面、规划并通过 MCP 和 ACP 连接的终端智能体 | 提供具备互操作界面的终端原生编程智能体选择 | Python CLI、Kimi 模型、MCP、ACP、兼容 OpenAI 的 API | 已发布 | 仓库 · 推文 |
| Flow Control | @thesherlocker | 通过原生 macOS 和 WebHID 界面配置一款受支持的 LoFree Flow Lite 84 键盘 | 在键盘原生不支持 VIA 时提供配置途径 | SwiftUI/AppKit、IOHID、WebHID、GPT-5.6 Sol/Codex Mode 辅助开发 | Alpha | 仓库 · 推文 |
| oh-my-opencode-slim | @Trion129 分享该项目 | 在专用智能体间分派探索、研究、审查、UI 与开发任务 | 让用户按模型分配质量、速度与成本，不必让单一模型包办 | OpenCode 插件、多模型智能体、技能、MCP、代码智能工具 | Beta | 仓库 · 推文 |
| Zeroprep | @ramsri_goutham 及其团队 | 随演讲者讲话同步生成动画演示文稿，并导出为 PDF 或 PowerPoint | 免去现场演讲前准备演示文稿的工作 | GPT-Realtime 2.1、Gemini 3.1 Flash Lite Image、React、HTML、CSS | Alpha | 推文 |
Kimi CLI 值得关注，因为其 README 确认它提供了可用的终端智能体界面，但也说明项目正向 Kimi Code CLI 过渡。截图清楚展现了这次迁移和该智能体宣称具备的终端能力；回复讨论则给出了必要提醒：长上下文应该经过压力测试，而不能想当然地认为它会提高正确率。
Flow Control 是一种边界更明确的构建模式：其 README 将支持范围限定为一种已测试的键盘型号，要求使用有线连接，在写入前保存状态快照，写入后回读验证，并刻意排除固件刷写及其他高风险恢复操作。这些项目反复体现的模式不是直接生成代码，而是将智能体能力置于约束明确的产品或委派边界内。
6. 新动态与亮点¶
GitHub Copilot 应用即将支持 Markdown 提示词¶
@basiclines 宣布（97 个赞、7 条回复、5 次引用、20,012 次浏览、63 次收藏），Markdown 提示词功能已向员工提供早期预览，并将进入更广泛使用的 Copilot 应用。另一则引用推文（25 个赞、1 条回复、3,115 次浏览）称，该应用将获得功能更强的提示词编辑器。这个信号很重要，因为它让结构化提示词从纯文本惯例变成一等产品界面，不过回复尚未证明用户能感知到明确收益。
受控的三工具仪表板测试展现了不同取舍¶
@xdadevelopers 分享了（10 个赞、4,003 次浏览、2 次收藏）一项测试，让 Claude Code、Codex 和 GitHub Copilot 使用同一份财务仪表板需求。与笼统的偏好投票相比，这篇文章的结果更充实：Copilot 速度最快，Claude Code 生成的工作流更深入但耗费更多时间和 token，而 Codex 在成品质量与功能性之间取得了作者最满意的平衡。这项对比范围有限，但它评估的是落地深度，而不只是着陆页截图。
黑客松项目采用多模态实时技术栈¶
@ramsri_goutham 宣布（43 个赞、9 条回复、1 次引用、1,680 次浏览、17 次收藏），Zeroprep 在 Codex 黑客松中获得第一名。团队称，该项目会聆听演讲，用 GPT-Realtime 2.1 控制视觉效果，借助 Gemini 3.1 Flash Lite Image 异步生成图像，渲染 React/HTML/CSS 场景并导出结果。值得关注的信号，是语音理解、图像生成和演示渲染被组合进实时工作流，而非独立的聊天交互。
7. 机会在哪里¶
[+++] 委派式工程工作的验证与漂移控制 — Spec Kit 的分阶段流程、对规格漂移的警告、Claude Code 关于使用可验证目标和人工审查计划的建议，以及 Kimi 回复中有关自信犯错的提醒，都指向同一个缺口。团队需要一个中间层，显示工作是否仍符合规格、存在哪些不确定性，以及哪些证据足以证明任务已经收尾。
[++] 带有质量、来源和权限信号的技能注册表 — skills.sh 讨论串展现出跨智能体安装和丰富技能库的需求，而其自身讨论也表明，用户不能假设大多数条目都有用。如果注册表能展示可信维护者、适用任务、智能体兼容性、访问范围和结果证据，就能减少目前的人工筛选步骤。
[++] 带有运营安全护栏的多模型路由 — Alan 使用者的描述、oh-my-opencode-slim 的专用通道、Kimi 的互操作性和仪表板对比，都让模型选择超越了单一排行榜。机会在于打造一个控制平面，记录任务匹配度、成本、上下文、部署、权限、检查项和交接结果。
[+] 智能体资源与可靠性可观测性 — 围绕 Codex 导致 Mac 卡顿和 SSD 损耗的用户报告未经独立证实，但它们表明，用户需要透明的进程、I/O、温度、内存和后台任务遥测。如果诊断界面能将资源行为关联到具体智能体会话，就能把模糊的安全担忧变成可操作的证据。
8. 要点总结¶
- 信号最强的工作流主张是规格优先，而非提示词优先。 Spec Kit 展示的 6 个阶段及其可观的互动量，体现了对可复用项目约束的需求；有关规格漂移的回复则说明，为何这些约束需要主动检查。（来源）
- 技能正成为智能体行为的安装单元，但信任层仍不完整。 skills.sh 提供了包式跨智能体分发，而作者仍表示，用户需要筛选目录，找出规模更小的有用核心。（来源）
- 可验证目标和独立审查正推动长时间运行的智能体走向实际运营。 Claude Code 团队成员的访谈主张明确设置终点、人工检查计划并分离创建者与验证者，而不是盲目延长智能体运行时间。（来源）
- 真实场景中的编程助手选择不只取决于代码生成质量。 一项使用相同需求的测试对比了速度、工作流完整性、视觉成品质量和 token 成本，而软件工厂的实践又加入了路由、权限和运行时可靠性。（来源）
- 开发者正把智能体用于边界明确的产品和编排系统。 Flow Control 将硬件配置器限制在有文档说明的支持边界内，而 Kimi CLI 和 oh-my-opencode-slim 分别提供终端与多智能体执行界面。（来源）