DPS Build

配置好 VS Code 之后，就可以远程接入，这下在浏览器里就能实现完整的体验：

brew install code-server

实现了随时随地“写代码”的需求：

1. 在电脑上安装并启动 Vibe Tunnel
2. 在电脑和手机上安装并启动 Tailscale
3. 在终端里用 vt 启动 claude，默认使用 4020 端口
4. 在手机上的 tailscale 进入电脑

下一步打算把电脑上的 vs code 也配置一下，这样在手机上可以看到 vs code

https://vibetunnel.sh/

https://tailscale.com/

Perplexity 的 Aravind Srinivas 提到了他们要求员工至少使用一个 AI 工具辅助编程，最有意思的例子是：

原先算法工程师读到新论文需要花大量时间写代码来复现，因为论文里一般只贴 pseudocode。现在只要把论文直接丢给这些工具，几个小时就有能跑起来的代码，把开发时间大大减少。

https://overcast.fm/+AA9poerLMC0

简单算一下，Sam Altman 说到今年底，OpenAI 能拥有100万张显卡，那估计其他几家大公司也能到这个规模。

哪怕训练或者推理的效率能提高1%，那就是可以省掉一万张显卡。一张 Nvidia H200 差不多是3到4万美金，一张 H00 差不多2.5万美金。简单算一下，就是2.5亿-4亿美金。

这么想想，如果能找到这样的人才，其实并不算太贵。

Anthropic 的联合创始人Benjamin Mann 认为 Meta 的天价 package 是真实的，而且解释了为什么他们愿意付出这么高的代价：

1. 这样的人才很有可能改变整个公司的商业路径；
2. 哪怕从成本角度考虑，如果这样的人才能够稍微改善一点推理或者训练的效率，降低的成本也是极其可观的。

https://overcast.fm/+AA6K1GykUBo

😂

我先后使用了 ChatGPT，Google Gemini，Cursor，ChatGPT Codex，Kiro，和 Claude 来生成代码：

1. 以上是按照我使用的先后顺序排序。Google Gemini Pro 2.5 是第一个让我觉得 wow 的代码生成工具，这种震撼堪比当初第一次使用 ChatGPT；

2. 目前看来效果最好的是 Claude，其次是 Cursor。

3. Claude 的基本工作模式是收到 prompt 之后，先进行规划，然后严格按照它的规划工作，如果中间遇到其他支线问题，它会加入规划，然后再执行。结束这个支线任务之后，它会继续回到原先规划的主线上。基本上不需要人工干预。

4. 当然 Claude 很贵。我目前购买的是最便宜的套餐，基本上每个小时都会遇到用量限制，平均不到半小时，最快的是十分钟就用完。看了下，基本上每小时的 quota 大概在 50k tokens。更要命的是，这个限制是动态的，有一次我被限制之后，四个小时后才恢复；

5. 所以搭配着 Cursor 使用还不错，开了 Auto 模式之后，基本没有遇到 Cursor 的用量限制。大块的任务交给 Claude，小修小补可以交给 Cursor；

6. Amazon 的 Kiro 其实是很不错的概念。给定 prompt 之后，它会先生成详尽的 PRD，开发需求和开发计划。然后 Kiro 就会严格按照开发计划工作。其实这也是一般软件工程师的工作模式。只可惜 Kiro 现在只能调用 Claude 3.7 的模型，效果大打折扣。

7. ChatGPT Codex 拿来做代码审核很不错，提交 prompt 之后，它会自动从 Github 拉取代码，然后执行 prompt。我经常出门前提交 prompt，让它以一个架构师的角度来审核整个项目。然后把它的建议丢给 Claude 或者 Cursor 去加工；

https://letters.acacess.com/weekly-201/

llm 刚出来的时候，我也想到这个点子，还写了一个 demo。

这个完成度非常高，陆陆续续迭代了两年。

所以说，点子不值钱，值钱的是把点子实现出来，把点子传播开来。

https://resumematcher.fyi/

一张图比较各个模型的特性

https://designs.magicpath.ai/v1/finely-sand-5086

每小时都是撞到用量限制。这个测试跑完，刚好还剩1%😂

这个视频把 Amazon 的 Kiro 介绍得很清楚了：

1. spec coding: 就是先把文档写清楚，然后让 Kiro 根据文档开发

2. hooks: 简单来说就是把各种指令丢给 Kiro，然后让它生成更详尽的指令，后续一直被调用

早上试了下，Claude 4 已经被抢光，只能在 Claude 3.7 下跑。速度慢了点，但整个流程好顺畅。

现在好像暂时关闭了 public preview 的申请，只有 wait list 了

https://youtu.be/Z9fUPyowRLI

前 CEO 和核心团队加入 Google 之后，剩余的 Windsurf 整体被卖给了 Cognition

https://x.com/russelljkaplan/status/1944845868273709520

写一个 mvp，纯 python的，想着 cloudflare 开了账号，不用白不用，一开始打算的架构是 Cloudflare Pages + Workers + D1，后面需要对象存储可以用 R2。

结果要部署的时候，才发现 Workers 对于 Python 的支持还是 beta，很多 lib 不支持。于是考虑调整到 Hono + Chanfana API + python 的架构，但 JS 完全不熟，于是放弃。

对比了 Railway 和 Superbase，决定切换到 Railway。决定还是用 Python + SQLite 的架构（因为前面的 D1 是SQLite compatible），这样代码改动最小。Railway 没有 SQLite managed service，但官方提供 SQLite template，可以用于创建 service。

我以为这条路会比较顺，结果反复出现数据库写入错误，找了半天才定位到问题，原来 Railway 限制死了一个 volume 只能挂载到一个 service 之下。比如我的 python 后端 和 SQLite 后端是两个不同的 service，就不能挂载同一个 volume。

好吧，这条路基本也被堵死 😂 估计最后还是要全部改成 Python + Postgres 的架构🤷

Daily Productive Sharing 1277 - Writing Code Was Never The Bottleneck

Pedro Tavares 发现添加新软件的边际成本正在接近零尤其是有了大语言模型LLMs但理解测试以及信任这段代码的代价呢比以往任何时候都高

1 他不确定作者是否完全理解自己提交的内容
2 他注意到生成的代码引入了不熟悉的模式或者打破了既有的惯例
3 在他看来真正的瓶颈过去是现在依然是代码审查通过指导和结对编程进行知识传递测试调试以及协调与沟通所带来的人力成本
4 最终他发现我们陷入了这样一种局面代码生产变得更简单但验证却更复杂这并不一定让团队整体运转得更快
5 他回忆开发者们过去常常拿复制粘贴工程师开玩笑但 LLM 所带来的速度与规模却让这种复制粘贴的习惯被进一步放大

https://letters.acacess.com/daily-productive-sharing-1277

一张图说清 MCP

可能这也是写代码最吸引我的地方之一，一直不断地学习，不断地试错。有了 Cursor 之类的工具之后，这样的节奏大大加快。

当然前端代码还是太复杂了，我只好选择放弃 😂

https://www.reddit.com/r/SaaS/comments/1lp3scg/i_am_giving_up/

试着用 ChatGPT Codex 来做代码审核效果还不错，给定 prompt 之后，它会从 Github 上自动下拉代码，compile 之后一步步检查，然后给出一些中肯的建议。

感觉在 web 页面上也就这么用了，没法像 Cursor / Claude /Gemini 那样拿来写代码。自动 compile 还蛮方便的。

Cursor 买了半个月，帮我“写了”这么多代码，可能比我职业生涯写的总和都多。

恐怕这是花的最值的一笔 AI 开销了。

BAML 发明了一种新的语言，来构建可以作为 building block 使用的 LLM 函数。一开始我以为这是个 agent framework, 但仔细阅读后发现，它更适合作为一个「编配 prompt + 发起向 LLM 的请求 + 结构化解析 LLM 返回数据」的组件，来帮助你更好地构建 AI 应用。BAML 解决的是 LLM I/O 的工程化问题，使上层业务可以专注于 workflow、RAG、agent 等应用层逻辑的维护，减少重复代码，增加与 LLM 交互的鲁棒性。

https://github.com/boundaryml/baml

之前看过一个 Python 库 guidance 有着类似的想法，也是将 LLM 调用函数化，但我觉得 BAML 更让人信服，它背后的公司 Boundary 对 LLM 的结构化输出有很多自己的理解和研究，他们提出了一个理念叫 Schema Aligned Parsing, 来代替目前主流的 JSON schema 方案。这两篇文章解释了 SAP 的原理以及为什么要这么做：

- https://www.boundaryml.com/blog/schema-aligned-parsing
- https://www.boundaryml.com/blog/type-definition-prompting-baml

这篇文章用数据说明了 BAML 的 SAP 方案在准确性和成本控制上超越 OpenAI 的 function calling: https://www.boundaryml.com/blog/sota-function-calling

关于为什么发明一种新的语言，BAML 的开发者们认为，就像我们从 inline javascript 进化到 JSX, 新的语法是从新的想法和需求中应运而生的，而且维护几百个 f-string 让人恶心。这点我特别赞同，不得不 quote 一下原文：

…the idea of maintaining hundreds of f-strings for prompts kind of disgusts us 🤮. Strings are bad for maintainable codebases. We prefer structured strings.

另外，BAML 还有一个可以在线运行的 playground，能非常直观地理解它到底是什么、可以怎么用:

https://www.promptfiddle.com/