AI 能帮我把网站做快，但不能替我判断该不该做

这周群里一直在聊 AI 编程工具。devtools MCP、agent-browser、Claude Code、Codex、Hermes、caveman、cavemem，一个接一个。

对我自己做 AI 出海项目来说，真正困扰我的不是“AI 能不能帮我写代码”。它当然能，而且越来越能。

真正的问题是：AI 把执行速度提上来以后，我会不会更快地把一个没想清楚的方向做出来。

文末有个人常用推荐的 AI 编程相关开源项目推荐。

快，有时候会制造一种安全感

我以前做项目，有个很明显的毛病：看到一个方向觉得有戏，就想赶紧让它像个产品。

首页先搭起来，功能先跑起来，文案先写几版，SEO 页面先铺一点。以前这些事情要花不少时间，现在 AI 可以很快帮我生成。一天结束，文件多了，页面有了，项目也能跑了，心里会有一种“今天推进很多”的感觉。

但后来我发现，这种感觉不一定可靠。

一个页面跑起来，不等于需求成立。一个功能能用，不等于用户会用。一个 AI 生成的方案看起来完整，也不等于它经过了市场、搜索、竞品和真实反馈的碰撞。

这也是我现在看 AI 编程工具时最想提醒自己的地方：它们很有用，但它们解决的是交付摩擦，不是方向判断。

真正有用的 AI 编程，不是继续猜

群里有个具体经验我觉得值得保留。有人提到用 devtools MCP 让 AI 直接打开报错页面，读取 build logs 里的错误代码，再顺着日志分析原因。

这个场景比“让 AI 帮我看看报错”要扎实很多。

以前我经常把一段报错复制给模型，让它猜。模型会给答案，有时还挺像。但部署问题、构建问题、浏览器运行问题，很多时候差一个环境变量、差一个依赖分类、差一个平台日志，结论就会完全变。

外面也在往这个方向走。Vercel Agent、Vercel workflows、dev3000、Debug Agent 这些东西都在强调一件事：让 AI coding agent 读真实日志、请求、页面状态、部署历史，而不是只读人转述的一段报错。

这对我来说是一个很实用的变化。如果 AI 要参与交付，就应该尽量让它读事实，而不是让它在我模糊的描述上继续猜。

但这里还有下一层问题。就算 AI 读了日志、修了 bug、页面也通过了构建，这个项目就值得继续做吗？

不一定。

交付速度不是最大问题

拿我自己的 AI 体育工具来说，如果只是让 AI 帮我做页面、写接口、搭后台，它确实能加速很多。但这个方向真正难的不是“做一个预测页面”。

后来产品文档里，我们把范围收窄到 2026 世界杯赛前预测，重点也不是承诺比分命中，而是看赔率、模型概率、Edge、EV，以及什么时候应该给出 No Bet。

这个收窄比写代码更关键。

如果方向不收窄，AI 会帮我做出一个看起来很完整的“AI 体育预测工具”：什么赛事都覆盖，什么玩法都想做，页面也许还挺漂亮。但它很可能没有清楚回答一个用户问题：今天这场比赛，我到底该不该关注某个赛前市场？

AI 视频方向也类似。网站不是做不出来，页面也不是搭不了。真正卡住的是差异化、数据化运营、社媒运营这些能力。我没有找到一个足够窄、足够痛、又适合我切入的场景。

所以我现在越来越觉得，AI 编程的价值要放回项目里看。它能帮我减少手工活，能帮我更快试一个页面，能帮我排查部署错误。但它不能替我回答：这个方向是不是值得做，我凭什么做，用户为什么要选我。

还要小心“验证债”

这次深搜时，我还看到一些关于 AI 生成代码技术债的讨论。学术论文和行业文章都在讲类似问题：AI 可以快速生成代码，但也可能带来理解不足、测试延期、维护困难、上下文不一致。

我不想把这个问题讲得太吓人。对一个人做项目来说，AI 代码不是不能用，恰恰应该用。只是不能把“生成出来了”当作“我掌握了”。

如果一个页面坏了，我知道怎么查吗？

如果一次构建失败，我知道从日志、依赖、环境变量、路由哪一层开始看吗？

如果 AI 改了一堆文件，我知道哪些改动是必须的，哪些只是它顺手发挥吗？

这些问题不回答，后面就会变成另一种债。不是财务债，是验证债。表面上项目越做越快，实际每多一层功能，自己就多一层没理解清楚的东西。

我一般会给 AI 编程加几个边界

以后我再用 AI 做项目，会先给自己加几个笨边界。

第一，动手前先写清楚这次要验证什么。是验证一个关键词有没有搜索意图，验证一个页面能不能解释价值，还是验证一个功能有没有人愿意用？如果答不上来，就先不要让 AI 批量开工。

第二，让 AI 修问题时，尽量给它真实证据。日志、截图、请求、构建输出、测试结果，比“你看着修”靠谱得多。

第三，写完要有验证动作。typecheck、build、打开页面、点一遍主路径、看控制台。项目里之前沉淀过本地 SEO 页面验证流程，这种东西很土，但能救命。

第四，修完要沉淀。不是每次都写大文档，但重复出现的构建坑、环境变量、部署步骤，至少要记下来。下一次再遇到，就不要重新靠感觉。

最后，也是最重要的，AI 编程不能替代产品判断。它可以帮我更快做出一个东西，但我要自己决定这个东西是不是该做，做到哪里停，什么信号说明该继续。

个人常用工具推荐

我个人针对使用的内容，按 边界约束、全链路开发、工程质量规范三类整理了一下。

• 边界约束类：

  agent-skills https://github.com/addyosmani/agent-skills

  BAML https://github.com/BoundaryML/baml

  SkillSmith https://github.com/microsoft/SkillSmith

• 全链路开发类：

  Open Interpreter https://github.com/OpenInterpreter/open-interpreter

  OpenHands https://github.com/All-Hands-AI/OpenHands

  CodeGraph https://github.com/codegraphai/codegraph

• 工程质量规范类：

  Roo Code https://github.com/RooVetGit/Roo-Code

  Continue https://github.com/continuedev/continue

  CodeGuard https://github.com/CodeGuardAI/CodeGuard

我现在对 AI 编程的态度其实比以前更积极，只是也更谨慎。它是好工具，尤其适合一个人做项目。但工具越快，人越要慢一点。

不然它会帮我把一个没想清楚的方向，做得特别像真的。