这一篇不讲怎么做，只把一个问题想清楚：要让 AI 做复杂系统的业务需求，需要先了解当前互联网公司的需求实现流程是如何运作的。下面是我这一路想下来的链条，拆成几张图。 一、起点 想让 AI 做复杂需求 │ │ 总得先有个需求交给它 ▼ 这个"需求"是怎么来的？靠谱吗？ │ ▼ ┌─────────────────────────┐ │ 谁定义的？定义得全不全？ │ │ 不搞清楚，后面全是空中楼阁 │ └─────────────────────────┘ │ ▼ 顺着 PRD 往下扒 通常我们理解的产品需求是由 PRD 文档提供的。 二、第一种思路：把 PRD 写到极详尽

2026 年 5 月 7 日 23:50 UTC，AWS us-east-1 一栋数据中心机房里多台冷却机同时失效，机柜温度飙升。几分钟后，Coinbase 的现货、Prime、International 和衍生品交易所——几乎全部撮合通道——开始陆续不可用，持续数小时。 事故第二天，CEO Brian Armstrong 在 X 上简短回应： 几小时后，Coinbase 工程负责人 @rwitoff

2026 年开年以来，harness engineering 这个词以病毒式传播的速度席卷了整个 AI 工程圈。Mitchell Hashimoto 给它命了名，OpenAI 用百万行零手写代码的项目给它做了广告，Stripe 每周 1300 个 AI PR 给它背了书。一时间，仿佛不谈 harness 就不配做 AI 工程师。 但热闹看完之后，有些问题值得冷静想一想。 Harness 到底是什么 Harness 这个词来自马具——缰绳、马鞍、

一个不太体面的比喻 "工贼"这词不好听，但你仔细品品，它描述的那个角色在当下的 AI 浪潮里正在被大规模制造。 公司让你拥抱 AI，用 Copilot 写代码，用 ChatGPT 写文档，用各种 agent 搞自动化。你照做了，效率翻倍，季度汇报上你是"数字化转型标兵"。很好。但你有没有想过一个问题：你每一次漂亮的 demo，都在帮管理层完成一个论证——"看，一个人加个 AI 就能干三个人的活，我们确实不需要那么多 headcount

最近"CLI 化网站"这个方向突然热了起来。港大的 cli-anything、卡比卡比写的 opencli、还有 bb-browser，三个项目实现思路各有侧重——有从前端源码逆向接口的，有通过 Chrome 插件在运行时探测网络请求的——但最终目标高度一致：把网站原本给浏览器用的 API，重新包装成给 AI 调用的 CLI。 从用户视角看，这类工具最直接的价值是打通 C 端孤岛。各个平台的数据和操作，不再被 GUI 困在浏览器里，而是能被脚本编排、被 AI