这是《开发者机会观察》第1期。过去一周，我们观察到一个清晰的转向：AI agent 正在从"聊天框里的助手"变成"并行、后台、带工具、跨产品的执行者"，围绕它的协调、测试、合规、可观测工具链远未饱和。与此同时，Vibe Coding 的普及催生了一批"配套小工具"需求——去AI味、项目交接、对话瘦身——需求真实存在但产品化程度极低。
一、MCP 工具撞名与上下文膨胀，缺一个本地语义网关
给 AI 编码工具接了六七个 MCP server 后，web_search_exa 和 brave_web_search 功能重叠，模型叫谁全凭解析顺序；工具描述能吃掉七成以上上下文。dev.to 热文《I Run Six MCP Servers Daily》把这个痛点讲透了，arXiv 一篇论文还实测出 Cursor 存在"工具混淆"bug。
现有方案中，mcp-compressor 只压缩描述不管路由，MCPlex 是个人博客里的配置分享。空白在于：一个本地反向代理，聚合上游工具、按语义聚类去重、给客户端暴露精简清单。纯工程问题，不需要训练模型，一人几周可出。风险是 MCP 协议迭代快需持续跟版，且客户端原生工具搜索可能压缩第三方空间。
参考线索：mohammadkhan.dev 痛点原文、mcp-compressor（PyPI）、Cursor 工具混淆实测（arXiv 2510.16558）
二、并行 AI 编码的"意图级"冲突，比文本合并更痛
多个 coding agent 在同一仓库并行干活时，最痛的不是 git 文本冲突，而是架构意图矛盾——一个要替换某个类，另一个正在扩展它，等 PR 阶段才发现就晚了。9月22日 Show HN 的 Foremerge 帖直指这个问题，一项基于三万多个 PR 的研究显示跨 agent 冲突率约为 agent 内部的两倍。
现有工作树隔离工具（Conductor、gitmesh 等）只做文件级隔离，对语义冲突天然失明。Foremerge 本身刚起步，作者承认还只是"单匹配，非分布式共识"。MVP 不需要大模型：本地 SQLite 加声明式 scope 匹配，让 agent 动手前发布意图，二次提交时返回冲突等级。2-3 人几周可做，真正壁垒在误报漏报的调优。
参考线索：Foremerge（GitHub naw103/foremerge）、Morph 并行 agent 对比文、gitmesh（npm）
三、AI agent 能不能在你网站上办成事？缺一个"agent 版 Lighthouse"
现在不到一半的 HTML 请求来自人类，越来越多交易发生在模型回答里。但现有 AEO 工具全在测"能不能被 AI 引用"，没人测"agent 能不能在你站上办成一件事"——登录、找客服、走通结账。9月19日 Show HN 的 Ax-check 定位正是这个，但还在极早期。
Cloudflare 的 Agent Readiness 是基础设施层，Lighthouse 和 Playwright 是确定性脚本，都测不出通用 agent 走流程会卡在哪。MVP 等于无头浏览器加可配置任务清单加 LLM agent 逐步尝试并记录卡点，调现成 API 即可，按次扫描收费。差异化很清楚：别人管"被不被提到"，你管"被不被用得动"。风险是 agent 行为非确定性需做成统计指标，测试涉及登录态需沙箱隔离。
参考线索：Ax-check.com、browser-use/browser-harness（GitHub）、AEO 竞品对比（promptwatch.com）
四、中文"去AI味"需求爆发，但工具还停留在文本文件阶段
AI 写的文章一股"AI 味"，人人都在找去味方法。V2EX 近一个月持续讨论这个话题，七牛云发文分析"去 AI 味 Skill 为何登上 GitHub 周榜第一"，抖音也出现相关热门视频。需求真实且增长，但现有方案全是 Skill 形式——纯 Markdown 规则文件，要用户自己放到配置目录里，普通用户门槛极高。
Humanizer-zh（3300 多 Star）和 no-slop-zh 都是规则文件，没有产品化体验。空白在于：一个带"AI 检测打分到一键改写再到前后对比"闭环的独立 Web 工具。MVP 只需 API 代理加左右对比视图，不需要自研模型，1-2 人两三周可出。风险是 AI 检测工具持续进化需跟进，定位应是"让文本更自然"而非"绕过检测"，避免学术合规争议。
参考线索：Humanizer-zh（GitHub）、no-slop-zh（V2EX）、七牛云分析文
五、Vibe Coding 跨工具切换，项目交接全靠手写文档
用 Claude Code 写一半、切到 Codex 继续，是很多 Vibe Coder 的日常。但每个工具的对话历史互不相通，切换时只能手动写一份"上次做到哪、为什么这么做、下一步是什么"的开发文档。V2EX 9月12日《VibeCoding 开发痛点》帖中，发帖人明确描述了这个手动流程——这是一个正在被大量开发者用笨办法解决的问题。
现有工具中，VibeCompass 需手动维护，vibefree 只提供空结构，cwms 偏底层持久化没有产品化体验。空白在于：一个 CLI 工具，自动扫描各工具的 JSONL 对话文件、调用一次 LLM 总结、输出 Markdown 交接文档。一人两三周可出 MVP。风险是不同工具对话格式不同需逐个适配，每次生成有 token 成本，对话历史含敏感信息需本地处理。
参考线索：V2EX 痛点帖（v2ex.com/t/1241500）、VibeCompass、vibefree（PyPI）
六、AI 编码对话体积爆炸，缺一个跨工具的可视化清理工具
"codex 一个对话几百 M 上 G，切换对话卡飞起"——V2EX 上这个抱怨引发大量共鸣。Vibe Coding 的对话文件里塞满了 base64 截图、重复文件读取、过时的 tool output，但用户没有好办法清理。cozempic（声称 10 万多用户）只做 Claude Code 且无 GUI，trimctx 是面向开发者的 CLI，Headroom 侵入性强。
空白在于：一个跨 Claude Code、Codex、DSH、Cursor 的图形化桌面工具，扫描本地 JSONL 文件、按体积排序、分类显示冗余内容、一键清理。Tauri 或 Electron 即可，一人两三周出 MVP。差异化在"跨工具加图形界面"。风险是清理可能导致上下文丢失需做预览和备份，各工具格式不同需适配，cozempic 用户基数大需做出体验差异。
参考线索：cozempic（PyPI）、trimctx（npm）、V2EX 卡顿帖
七、AI 批量生成的 App，过苹果审核越来越难
用 Cursor、Lovable、v0 批量生成 App 的开发者越来越多，但苹果审核在收紧——4.2 最低功能、4.3(a) 设计垃圾、5.1.1 第三方 AI 数据披露，都是重灾区。9月20日 Show HN 的 StoreReady 直指"AI 代码生成与苹果提交规范之间的合规落差"，Apple Developer Forums 9月14日的 5.1.1(i) 帖明确指出 AI 数据共享披露不清会被拒。
现有方案中，AcceptMyApp 只做元数据分析不扫二进制，StoreReady 刚起步，博客指南是"教你改"不是"自动扫"。空白在于：一个提交前扫描器，解析 ipa 元数据加 Info.plist 权限加截图清单，跑规则引擎报风险，可选 LLM 生成申诉草稿。不需要资质和算力，2-3 人几周可出。风险是苹果条款有主观性不能保证过审，处理用户 ipa 有隐私敏感，给申诉话术不能教唆绕过审核。
参考线索：StoreReady（Show HN）、AcceptMyApp、Apple Developer Forums 5.1.1 帖
过去一周的信号指向同一个判断：AI agent 的"基础设施层"正在经历从 0 到 1 的窗口期。当 agent 开始并行干活、后台运行、挂载几十个工具、自动生成并提交应用，围绕它的协调、测试、合规、可观测就成了新的空白地带。这些方向有一个共同点——不需要大模型算力，不需要大量私有数据，纯工程问题，小团队能快速切入。
另一个值得注意的风向是 Vibe Coding 的"配套小工具"需求在中文社区集中爆发。去AI味、项目交接、对话瘦身，这些不是宏大叙事，而是开发者每天被刺痛的具体问题。它们的共同特征是：需求已被反复验证，但现有方案要么是 Skill 文本文件，要么是面向开发者的 CLI，产品化程度极低。对独立开发者来说，把一个"大家都在用笨办法解决"的痛点做成好用的小产品，可能比追下一个大模型概念更实在。