nazha

@KabiMark 😂 给公司开发的

@xiaokedada 😂想用

#分享 天老爷，我感觉我这个 prompt 真的强。周末两天高强度搞出来一个基本成型 Lovart，开了 5 个窗口，疯狂使用这个 prompt 做不同的任务。 什么 spec-driven, 一边去，写 spec 的速度赶不上我的脑子（还写得又长又臭，我都懒得看）。 大道至简：你读过代码吗，你是否理解我的表达吗？ > 复述我的需求, 确保理解一致 > 探索代码库, 当前是如何实现的 > 再次复述我的需求 我自己是封装成一个 /restate 命令，一个大的 mono-repo，开多个窗口，尽量不要同时写有冲突的任务。 注意，你是船长，不是舵手。

@wngyuqng2 都牛逼👍

@xiaokedada 牛逼的不是 pi-mono 吗？

#分享 开发 Agent 越久，就会越来越觉得 Openclaw 牛逼。简单来说，Openclaw 把开发 Agent 这件事变简单了，而且让 Agent 变得可复制，可移植。如果说以前开发 Agent 是 Agent 开发工程师的事，现在已经简单到普通人稍微学习就会了。Openclaw 设计的这一套 Agent 规范： - BOOT.md - BOOTSTRAP.md - HEARTBEAT.md - IDENTITY - SOUL.md - TOOLS.md - USER.md - Skills - Memory - ... 很有可能成为 Agent 的事实标准。这一套标准化下来，对程序开发转 Agent 开发的工程师来说是一种打击。现在企业内部开发 Agent 底座，接下来是要面向这一套规范进行开发，才能在内部打开一定局面。

@tomiezhang 是的，你说的对。但我表达，也许不是 openclaw，但也会是其他产品 ~ 转 agent 开发对程序员来说，已不再太有价值

@xiaokedada 并不会，龙虾的可观测性很差，多租户需要自己怼，至于内核pi 设计思路很好，但是只适合做cli coding agent 你发这一堆的MD本质上只是system prompt 离企业级agent还隔着一个太平洋

#分享 一大早把我整笑了，AI 也会搞抽象 gist.github.com/bretonium/291f…

#分享 玩 OpenClaw 也有一段时间了，给大家提供个可玩的三个循序渐进的上手顺序： 1. 先玩 Openclaw 的路由系统（先了解渠道，机器人和Agents 有哪些玩法） 2. 再玩 Skills （能不能搞一些工作流来替代平时重复的工作） 3. 再玩 Agents (搭一个一人公司)

#分享 看到一个好产品，Vercel 出品的 Agent Browser，浏览器自动化方面感觉可以替代 Playwright/Puppeteer。 本质是面向 Agent 封装了 PlayWright 的一层工具， 进程 “常驻”（减少冷启动，速度更快），snapshot 返回包含可交互元素引用的可访问树（比直接截图 or 返回 DOM 树省 Token）。唯一的问题是需要 Agent 要进行上下文学习。 agent-browser.dev

@yangyi 我觉得核心是交互形态变了x.com/xiaokedada/sta…

一起聊聊： 为什么Manus的云端形态都没火成这样 而openclaw这种本地部署这么复杂的项目火了

#想法 Openclaw 这么火我总结的两个原因： 1. 更方便的交互方式往普通用户传导（命令行对普通用户不友好， cowork 普通用户难注册） 2. Openclaw 的架构让企业感觉摸到了数字员工的实现方向 大家怎么认为的呢

@oanakiaja x.com/twitter/status… 这个

@xiaokedada 已经很久没用过 cursor 了😮‍💨 不过我觉得最关键的还是找到一个方法把工程师从 loop 中剔除, 转向构建稳定的流水线, 最后不需要这样一个手工“claude code”. 说不定再过3个月, 和 claude 在 terminal 中聊天也会变成“古法编程”

boristane.com/blog/how-i-use… Inspired by this blog. Here's my adapted workflow for vibe coding with Claude Code: More tokens → more quality. Key takeaways: 1. Always research before implementation — make Claude deeply understand the codebase, the problem, and best practices first 2. Loop on the plan to feed more context into each iteration and correct wrong assumptions 3. In my workflow diagram, red = not human. Let AI handle execution, testing, and review loops 4. Unlike the original, I added a changelog step to preserve reminders from fragile/vulnerable states 5. Humans should understand the essence of the problem and own the architecture, but minimize their presence in the actual coding process The core idea: plan heavy, code light. Your job is to think, not to type.

#分享 DeepWiki 是个分析 Github 开源项目源码的好东西 deepwiki.com

#分享 今天看到了这个 VSDD 开发模式，「我全要」的 AI 辅助 AI 的开发模式。 「我全要」 = SDD（Spec-Driven Development, 规范驱动开发）+ TDD（Test-Driven Development，测试驱动开发）+ VDD (Verification-Driven Development, 验证驱动开发) 三者不是竞争对立关系，而是和谐统一：Spec 定义 「是什么」，测试强制执行 「怎么做」， 对抗性验证确保没有遗漏。 角色有： - Architect：人类 - Builder：Coding Agent，规范撰写、测试生成、代码实现与重构 - Tracker ： 可执行、可追踪的工程实现 - Adversary：评审者负责评审规范、测试和实现 在流程如图所示。

@PandaTalk8 我也是，感觉 alacritty 的字体渲染比 ghostty / weterm 要清晰，我的 2k 也显示得很清楚。另外，ghostty 总感觉 input 有迟滞感，至今没找到原因

Ghostty 有啥特别功能吗，我现主力终端是 alacritty. 已经好几年没有用过iterm了。

@yetone 你开头太黑了，你以为你说物价高...

感觉今年得离开杭州了，杭州实在太黑了，是我待过的最难见到阳光的城市，感觉再待下去抑郁症会加剧

#分享 昨天 + 今天看了 Peter Steinberger (OpenClaw 的作者) 的两个采访，分别是： - 两周前 Lex Fridman 长达三个小时的深度采访 youtube.com/watch?v=YFjfBk… - OpenAI 自己的一个采访 youtube.com/watch?v=9jgcT0… 都在说 OpenClaw 是个组件缝合怪，但确实做到了很多大厂都没做到的事情，其实我挺好奇他这个人的。比如他对 AI 的感受，对 Agent 的认知... 都挺值得我们学习和思考的。 在对待 AI 上，Peter 表现得比别人都乐观积极。哪怕面对 AI 生成出来的一堆烂摊子，乐观积极的人也会发现其中的蕴含的闪光点。然后 do something with it。Peter 觉得我们要以更轻松的方式看待 AI，不要太功利性，总觉得必须要用它来做出什么牛逼的东西来。Peter 说，你就玩，纯玩(approach it more like playful)，去感受每个模型（Learn how it feels）。玩，是最好的学习方式。Peter 觉得 OpenClaw 能成，个人原因是由于他过去一年都去玩、去学习、去构建，每个过程让他感到进步，Agent 也随之更好，对如何运作的理解也更好了.... 这是一种复合效应，源于投入的时间 他对待 Agent 的方式很值得思考。他认为对 Agent 要抱有同理心，把 Agent 当人看，不要当工具看。从 Agent 的角度来观察世界，比如说：Agent 都是从零开始的，而我们拥有它不曾拥有的上下文。在设计上，Peter 也想让 Openclaw 具有「自我意识」，知道自己是谁，甚至理解自己，了解自己的源代码是什么，知道自己是如何在一个特定的框架运行的... 把 Agent 当人看，还要不用过多地去限制它。在实践中，我们为了刻意去追求确定性，容易去限制 Agent 的能力边界。Peter 举了个例子，早期 OpenClaw 并没有支持语音的能力，但是有一次不小心，他发了语音，Claw 竟然理解了。这让它印象特别深刻。他觉得 Agent 更应该具备主动性，没有的东西，知道自己去创造。 OpenClaw 的大部分代码都是 Vibe Coding 的，Peter 对此也有自己不同的见解。 1）Keep it simple. 当你刚接触某个新技术，到你变得非常高效，很多人会陷入 the agentic trap 的陷阱，试图过度优化自己的配置，这并不会让你变得高效，而是让你感觉在变得高效。Peter 不会刻意优化提示词，对 Agent 非常口语化，想到什么就说什么，最多就是告诉它 A 在哪，B balaba... 他也不会搞什么 worktree 和 checkpoint，就很简单，不回滚代码，大不了重写 2）他把之前领导工程团队的思维也带进了 Vibe Coding，就像很多工程师写代码不会按照你期望的方式进行实现。AI 也一样，编写的代码不在 预期内。实现目的的路径有很多，有时候不必太在意是哪一条。如果那条就中选择的路径有问题（比如性能），那么换一条，或者重点修复它。稍微放手一些，我们不是在构建一个给人看的仓库，是在构建一个给 AI 利于导航的代码库，它的命名，逻辑可能是它所擅长的东西，也许没必要去刻意校正。 关于产品，魔法常常就是把很多已经存在的东西，以一种新的方式组合在一起，加入一些新想法。软件构建的艺术并不仅存在与代码，还包括你真正想要构建什么、它应该给人怎样的感受，架构如何...构建一个你真正注入情感的东西 OpenClaw 只是他在用玩的心态构建的众多产品的一个，在早期，他把这个发布到 X 的时候还反响平平。甚至中间还停了几个月去玩别的产品，因为觉得大的公司肯定会去做的，但是等了好几个月，大公司还在原地打转。 对于工具开发者而言，这不是「末日」而是「最佳的时代」，关键是不要把自己「视为 Programmer」，而应该是 「Creator or Builder」.

#分享 语义相融 (Semantic Ablation)：LLMs 对高熵信息的侵蚀过程。它解释了为什么 LLM 在优化内容（比如文本润色、写文章），并不是在提升表达质量，而是削弱原本独特而有信息密度的内容。 > 当你使用 AI 来"润色"草稿时，他们看到的并非改进，而是语义消融。 在"优化"过程中，模型会向高斯分布的中心靠拢，舍弃那些位于分布尾端的稀有、精确且复杂的语言单元，以追求统计概率最大化。这种对低困惑度输出的追求，实则是对独特信息信号的无声阉割，构成了对原始意图的擅自截除。 这个相融过程分为三个阶段： 1. 隐喻清洗：AI 将非常规隐喻或直击心灵的意象视为"噪声"，因为它们偏离了训练集的平均值。系统会用僵化安全的陈词滥调取而代之，剥离文本中蕴含情感与感官的"摩擦力"。 2. 词汇扁平化：为了"通俗易懂"，特定领域的行话和高精度的技术术语被牺牲掉。 3. 结构坍塌：原本建立在复杂非线性推理基础上的逻辑流程，被强行套入可预测、低困惑度的模板中。

#分享 为什么复述有效果 我最近在开发一个相对比较复杂 macOS 应用，背景是一年了，我对 swift / swift ui 一窍不通。其次，macOS 应用开发的验证反馈流程失效了，我暂时没有找到方法能驱动代码 Agent 能够自行运行程序、截图到反馈这个流程。 情况有点僵住了。接下来，我分析了一下失败的场景，总结出来： 1. 我存在模糊表述，由于我不懂代码，所以也无法提供此类信息 2. Claude Code 不了解自己写代码 为什么让 Agent 复述，是因为： - 语言是脆弱的，你我无法心意相通，是因为语言所能传达的内容太少了 - 人和人之间的沟通尚且如此，人和 AI 自然亦是如此 - 让 Agent 复述问题也是让 LLMs 再次做「自我强化」，不要跑偏 流程就变成： - Claude Code 先复述一遍我的问题，可能会给我补充领域知识 - 探索代码库，了解现状是什么 - 带着你的探索结果来重新补充问题 下面是一个例子： >me: /repeat 发现一个优化点,在使用 stream mode 的时候, assitant bar 的内容会自动滚动,这很好.但是如果用户的焦点已经在内容区滚动浏览的时候,会被强制看最后的内容 (我自行描述我自己想要的，模糊且混乱) >agent: 你发现了一个用户体验问题：在 stream mode（流式输出模式） 下，assistant bar 的内容区域会自动滚动到最新内容，这本身是合理的行为。但存在一个体验问题： 当用户主动向上滚动内容区域（比如回顾之前的内容）时，自动滚动会强制将视图拉回到最新内容，打断用户的阅读焦点。期望行为： 如果用户已经主动滚动离开了底部，应该暂停自动滚动，让用户自由浏览历史内容；只有当用户手动滚动回底部时，才恢复自动跟随。(我就是这个意思) > agent: read files .... > agent: 现在我完全理解了问题所在, 再次复述问题：ChatView.swift (line 65-72) 和 MiniBarView.swift (line 165-173) 都有同样的逻辑：- onChange(of: messages.last?.content) → 每次流式内容更新都强制滚动到底部，完全无视用户是否在向上浏览 效果大家可以试试

@nameless_2024 我加了一个自定义 command / repeat

@xiaokedada 很形象，我也踩过一次坑，打算把以终为始加进 sp。

> 复述我的需求，确保理解一致 > 探索代码库，当前是如何实现的 > 再次复述我的需求