Peng

Learn · Build · Share · Connect
独立开发者
AI 资讯：

[Peng @builderpeng]

@OninoETH 🤝

[Peng @builderpeng]

AI 生成红毯盛宴明星合成图

提示词 👇

[Peng @builderpeng]

提示词来自 @OninoETH

A cinematic 5x5 grid portrait collage capturing a star-studded celebrity gala night, featuring 25 unique young East Asian actresses on the red carpet. Each cell is an individual candid snapshot with rich diversity. Every single cell must present a completely different woman with a unique facial structure, individual expression, and a totally distinct celebrity styling. There are no duplicated faces or identical looks. To ensure natural flow, each portrait is captured from a slightly different perspective: some are elegant side profiles, some are looking back over their shoulders, some are waving gently at the fans, and some are interacting with reporters. Their haute couture gowns vary drastically in vibrant colors and necklines, paired with completely different hairstyles ranging from sleek high buns to loose natural waves. The backgrounds feature dynamic paparazzi flashes and soft luxury event bokeh. Cohesive cinematic film color grading, realistic skin textures, high-fashion editorial style, sharp focus, 8k resolution, no text.

[Peng @builderpeng]

今天看到 Matt Pocock 一个演讲，他在 AI 工程师世界大会上讲怎么写好 agent skill。他的 skill 仓库在
GitHub 上有 156k star，算是工程类 skill 里最受欢迎的之一。

他提了一个概念叫"skill 炼狱"：满世界都是 skill，但没人告诉你哪个好、哪个烂。你拼不出一套自己的体系。

他给了一套四步检查清单：触发、结构、引导、精简。其中有两条我反复看了几遍：

- 引导词
agent不听你的指令？不是写少了，是措辞方式不对。把长句压缩成"密度大"的词（比如"垂直切片"），agent在思考过程中反复咀嚼它，行为就跟着变。去看推理轨迹里有没有出现这个词，出现了就说明生效了。

- 藏起后续步骤
agent 敷衍某个步骤？因为它看到了终点，急着跳过去。把当前步骤拆成独立 skill，agent 不知道后面还有"做计划"，它才会把这一步做扎实。他说这招"没有替代品"。

他自己也把这套框架写成了一个 skill，叫 Writing Great Skills，放在同一个仓库里。

原视频在这里：

https://t.co/h7rnBpiHdx

[Peng @builderpeng]

Simon Willison 分享了 Claude Code
团队给他的一个技巧，思路有点反直觉：别告诉 Fable 每一步该干什么，让它自己判断。

两个点可以试一试：

- 测试交给 Fable 自己决定。 之前我会说"大功能写测试，小改动别跑"。Claude Code 团队的建议是：直接省略这条指令，让 Fable 自己判断。他们内部这样用下来效果更好。

- 写代码的活分给更低级别的模型。 Jesse Vincent 给 Simon 的建议：告诉 Fable 把代码实现任务委托给
subagent，自己判断该用 Sonnet 还是 Haiku。主线程只做判断、审查和整合。

Simon 用的 prompt 就一句话：

▎ 写代码的任务，你自己判断该用哪个更低级别的模型，用 subagent 去跑。

https://t.co/ClI8rKeQQ8

[Peng @builderpeng]

Mac 上，如果你一直想要一些趁手的小工具，但从来没时间学 Swift 去写。Raycast 团队做了一个东西，把这步跳过去了：对着 AI 描述你想要什么，它生成一个真正的 Mac app，待在 Dock 里，秒开，离线也能跑。

几个细节让我觉得想法不错：

- 不只是生成代码，是生成完整的 app。 不是网页套壳，是原生 Mac 应用，能调系统能力。不满意就继续聊，边聊边改。

- 能发布到公共商店，也能私密分享给团队。 Raycast 自己用 Glaze 搭了内部支持和销售流程的工具。Cursor、Linear、Vercel 也在用它做内部定制。

- 例子比功能描述更有说服力。 有人做了一个带实时数据的世界杯赛程 app，有人做了一个专门跟 agent 交互的终端，最离谱的是有人做了一个完整的合成器，发布视频的背景音乐就是用这个合成器做的。

Thomas（Raycast CEO）说了一句话我挺认同：大多数软件是妥协，为了覆盖几百万人，你只能为"平均用户"做，
但"平均用户"不存在。Glaze 反过来，每个人描述自己想要的，软件围绕你来成形。

目前免费起步，Mac 优先：https://t.co/WrrOFEFP61

https://t.co/XszTebHy8A

[Peng @builderpeng]

我反复看了几遍 Phil Chen 这篇职业建议。他在 Scale AI、OpenAI、Google 都待过，现在自己创业做 agent 原生公司。整篇文章读下来，与其说是"AI 时代的职业指南"，不如说是一个经历过几轮选择的人在告诉我们，什么东西真的值钱。

几个点让我停下来反复看：

- 稀缺的不是钱，是时间、关系和声誉。
他当年有量化交易的 offer，现金高得多，选了 Scale，因为能接触到各种产品和人。后来去 DeepMind、去 OpenAI 的机会，全是��� Scale 那段时间的人脉和积累来的。他说现在搞钱比任何时候都容易，但真正稀缺的东西没变。

- 学会找问题，比学会解题重要。
他们公司现在面试不看 Leetcode、不看系统设计，看的是你能不能快速理解环境、找到值得解决的问题、然后在约束下做出来。因为 agent 已经能啃下任何被清晰定义的问题了，人的价值变成了"哪些问题值得让 agent 去啃"。

- xG 和效率。
他用足球术语类比职业生涯：xG（预期进球）是你能不能站对位置看到机会，效率是机会来了你能 不能踢进去。2023 年他拒了 Anthropic 和 Cursor，2024 年又拒了一次。每个被拒掉的机会 xG 都很高，但他选了更符合自己兴趣和目标的。他说回头看大部分选对了，但后悔没花更多时间收集信息——这就是效率问题。

- 最后一公里。
AI 拉高了及格线：一句潦草的 prompt 就能产出的东西，是现在的"中位数"。价值来自你对某个问题有独特的视角，或者你对细节比别人较真。这在面试里一眼就能看出来。

他在文末说了一句话：做研究是一种心态，不是一个职位。你不需要进前沿实验室，也能做研究者干的活。

我读完在想一个问题：如果面试从"你会不会写代码"变成了"你能不能找到该写的代码"，那判断力如何“训练”？

原文很值得读：https://t.co/ZriwgOl2ea

[Phil Chen @philhchen]

https://t.co/oMoEAYkqGl

[Peng @builderpeng]

@choseitaku 来了来了🤝

[Peng @builderpeng]

@ZiqiLiu158430 Let’s connect！

[Peng @builderpeng]

Browser Use @browser_use 开源了一个视频剪辑工具 video-use，里面有一些很不错的思路，比如 AI 不看视频，它"读"视频。

简单解释一下，就是把原始素材转成两层信息喂给 LLM。

第一层，带词级时间戳的音频转录，所有镜头打包成一个 12KB 的文本文件，这是 LLM 的主要阅读界面。

第二层，按需生成的可视化合成图，只在需要判断的节点才调用。

第二层这个详细说一下，因为我第一次也没看懂。

就是在拿不准的时候（比如两段素材间的停顿到底留不留、某句话用哪个镜头版本更好）才调 timeline_view 生成一张画面切片：连续帧缩略图叠上波形图，每个词的位置也标在上面。看一眼，做决定，不再需要的时候就完全不碰画面。

然后，整个Pipeline 是：转录 → 打包 → LLM 推理 → 生成剪辑决策 → 渲染 → 自��。

这样做的优势是，video-use 剪辑过程中只使用 12KB 文本 + 几张 PNG，token 使用量大幅减少。

这个做法，是不是对访谈、口播、教程这类语言驱动的素材，效果会更明显一些？因为剪辑点本来就在词和句的边界上，文本界面足够做判断。

更详细的信息，可以看这里：

https://t.co/ISnh8ocDj6

[Peng @builderpeng]

提示词来自 @Mind_Boticni

一款高端韩国时尚杂志的动态现代多照片编辑布局，展示该女性的九个独特姿势。设计完全脱离网格布局，采用优雅的不对称构图：左侧是一张巨大、主导的全身肖像，右侧则是一个动态的较小肖像群集，包括垂直、水平和圆形美照，这些���像相互重叠，并带有细腻优雅的白色边框。

场景设定在一个美丽的夏日，湛蓝的天空、蓬松的云朵和温暖的阳光营造出清晰的自然阴影。柔和的虚化效果、闪耀的阳光高光以及飘浮的花瓣充盈在空气中。她身穿一件超大号的粉彩毛衣、一条时尚裙子、多层银色项链以及可爱配饰。姿势包括俏皮的镜头互动、和平手势以及自然微笑。整体造型极致高端、干净、极简且高度电影化，带有细腻的皮肤纹理。超现实2K。

[Peng @builderpeng]

如何做这种时尚杂志式的多照片布局？
提示词 👇

[Peng @builderpeng]

@georgesttock UGC

[Peng @builderpeng]

@jiyngxing15 互关互关🤝

[Peng @builderpeng]

Boris Cherny（Claude Code 作者）和 Peter Steinberger（OpenClaw 作者）把 "loop engineering" 这个词带火之后，Andrew Ng 最近在 The Batch 里把他做 0 到 1 产品的三个循环拆了出来。

我看完最大的收获不是 Loop 本身，是他对"品味"这个词的修正。

三个 Loop，时间尺度完全不同：

分钟级（Agentic coding loop）： Agent ���代码、自测、迭代到 bug-free。Andrew 周末给女儿搭了个打字练习 app，agent 自己跑了一个小时，中间没找过他一次。

小时级（Developer feedback loop）： 以前开发者当 QA 手动找 bug，现在 agent 能自测了，精力转到了功能取舍、UI 方向这类更高层的决策。

天级（External feedback loop）： 用户反馈、alpha 测试、A/B 实验。最慢，但决定方向。

然后他提了一个我反复看了几遍的观点。很多人说人在产品开发中不可替代的是"品味"，Andrew 不这么叫。他说人类真正的优势是 context advantage，我们比 AI 更了解用户是谁、产品在什么场景下被使用。叫"品味"像是在说一种神秘天赋，叫"上下文优势"意味着它是可以被缩小、被工程化的。

他还观察到一个趋势：coding agent 把开发速度拉起来之后，越来越多工程师开始兼���做 PM。但最难的不是写 spec，是在"埋头建"和"抬头看反馈"之间找到节奏。

推荐读原文，精炼但信息密度很高：https://t.co/JWfE5NYc7Z

[Andrew Ng @AndrewYNg]

“Loop engineering” is a hot buzzphrase after mentions of it by Boris Cherny (Claude Code’s creator) and Peter Steinberger (OpenClaw's creator) went viral on social media. Loops are now a key part of how we get AI agents to iterate at length to build software. In this letter, I’d like to share my 3 key loops, shown in the image below, for building 0-to-1 products. These loops guide not just how I build software, but also how I decide what software to build.

Agentic coding loop: Given a product specification and optionally a set of evals (that is, a dataset against which to measure performance), we can have an AI agent write code, test its work, and keep iterating until the code is bug-free and meets its specification. This idea of closing the loop took off around the end of last year, and it has been a game changer in enabling coding agents to work longer productively without human intervention. For example, over the weekend, I was building an app for my daughter to practice typing, and my coding agent could easily work for around an hour, using a web browser to check what it had built multiple times before getting back to me, without needing my intervention.

The engineering loop executes quickly. Every few minutes, the coding agent might build and test a new version of the software. I hear frequently from developers who are finding new ways to engineer more effective engineering loops. This is an active area of invention!

Developer feedback loop: In this loop, a developer examines the current product and steers the coding agent to improve it. Last year, a lot of developers (including me) were acting as the QA (quality assurance) function for our coding agents, manually finding bugs and then asking the agent to fix them. But with coding agents much more able to test their own code, the amount of time we need to spend on this function has decreased significantly. This allows us to make higher-level product decisions, such as what key features to offer, where the UI needs improvement, and so on.

The developer-feedback loop operates over time intervals between tens of minutes and hours — that's how frequently a developer might review a product and give feedback. In the case of the typing app, I changed my mind a few times about the visual design, what cat costumes she can unlock as she learns (she loves cats), and the user flow for a grown-up to log in and steer the child's learning experience.

When a developer has a clear vision for what to build, it is still a lot of work to translate that vision into a specification for a coding agent to implement. Further, after the developer has seen an implementation, they might update (or perhaps clarify) the spec to steer it toward what they want. If you find that the system repeatedly runs into certain problems, building a set of evals for the agent becomes useful.

AI-native teams are increasingly using AI to help shape product direction, for example, automating the gathering and analysis of usage data, summarizing written and verbal customer feedback, or carrying out competitive analysis. However, for pretty much all the products I’m involved in, I see humans as having a significant context advantage over current AI systems — we know a lot more than the AI system about the users and the context the product has to operate in — and thus humans play a critical role. Many people describe this human contribution as “taste,” but I prefer to think of it as humans having a context advantage, since that gives us a clearer path to helping AI systems get better. This also speaks to why this step can’t be automated: So long as the human knows something the AI does not, human-in-the-loop is needed to to inject that knowledge into the system.

External feedback loop: This includes a wide range of tactics like asking a few friends for feedback, launching to alpha testers, or putting the code into production with A/B testing. These tactics are usually slow, rarely taking less than hours and sometimes taking days or even weeks. This data informs the developer vision, which in turn continues to drive the detailed product spec, which in turn drives the coding agent.

With coding agents speeding up software development, more engineers are starting to play a partial product management role. For many engineers who are growing into this role, the hardest part is shaping the product vision and striking a balance between building (bridging the gap between vision and spec) and getting user feedback to evolve the vision. It is important to do both!

I will write more about how to do this in future posts, but for now, I find it encouraging that engineers are playing an expanded role (just as product managers and designers now do more engineering).

[Original text: The Batch]

[Peng @builderpeng]

今天读到 Google 博客上 ADK 2.0 的设计思路，里面一个判断跟我最近的直觉完全吻合：LLM 不适合做路由、调度、错误处理这些事，传统代码比模型快、准、便宜。

他们给了一个很直观的对比，同一个退款流程，纯 agent 方案 vs ADK 2.0 workflow 方案：

Token 消耗： 5,152 → 2,265，砍了一半。
延迟： 7.2 秒 → 5.7 秒，省了约 20%。
可靠性： 纯 agent 跑 100 次，可能 95 次正确。workflow 方案里，A→B→C 的顺序是代码写死的，不存在"模型忘了下一步"这种事。

核心思路说起来简单：把 LLM 严格限定在需要认知推理的节点上（分析投诉内容、起草邮件），其余步骤（查数据库、调 Stripe 退款、更新 CRM 工单）全部走确定性代码。工作流图本身还充当了一层安全边界，即使 LLM 节点被 prompt injection 攻击，运行时也没有对应的路径去执行未授权的操作。

他们还提到了动态工作流，复杂业务逻辑可以用原生 Python 控制流来表达，不用硬塞进静态路由表。

我读完在想一个问题：2025 年大家都在喊"everything agent"，但 ADK 2.0 的方向明显是往回拉——把确定性还给代码，只让模型做它擅长的事。这个 pendulum 会不会是 2026 年下半年 AI 工程化的主旋律？

推荐读原文，里面对 context bloat、多 agent 协作、安全边界的拆解都很扎实：https://t.co/1gS6K7ssD9

[Peng @builderpeng]

@dynamicwangs 赞👍

[Peng @builderpeng]

今天读到 Latent Space 对 Cursor FDE 负责人 Pauline Brunet 的访谈，她对 FDE 的定义把我之前对这个角色的理解修正了不少。

FDE 最近在硅谷火得不行，但我一���以为它更像一种高级售后。Brunet 说得很直白：FDE 不是装完就走，是钻进客户系统里修。她的团队做的事覆盖软件开发的整条链路，但不是替客户写代码，是帮客户搭一条生产线。

几个细节我反复看了几遍：

团队规模： 目标是到今年 12 月底增长十倍。全是工程师，至少五年��验，必须有大量客户对接经历。成员来自 Spotify、Rippling、Palantir。

企业落地的天花板： 一个组织里 10% 到 20% 的人是狂热早期用户，在自己的电脑上用 agent 效率极高。但跨团队、跨流程的规模化协同起不来。

从个人工具到组织级生产线： 中间有一条很深的沟。Brunet 说 FDE 团队要做的就是在组织内部找到对的人，跟他们一起把这条沟填上。

她还提了一个让我印象很深的判断标准：面试 FDE 候选人时，不看简历上有多少项目，看候选人能不能讲清楚自己做过的每个设计决策，为什么选这个数据库、为什么系统这样设计、取舍点在哪。

而且， FDE 这个角色真的需要"技术+沟通+判断"三者同时在线。

推荐读原文，里面对"软件工厂"的讨论也很有启发

https://t.co/DDWxQOGsYt