Clawdbot 工作流体验:从代码到自动化
一天内完成 GitHub 集成、安全修复、文档转 skill、自动同步、bug 修复——展示 Clawdbot 作为生产力工具的实际应用
THE ARCHIVE
一些观察,一些实践,还有尚未完成的思考。
38 篇文章
一天内完成 GitHub 集成、安全修复、文档转 skill、自动同步、bug 修复——展示 Clawdbot 作为生产力工具的实际应用
详细教程:如何在 Zeabur 上配置 Clawdbot 的 GitHub 集成,实现 AI Agent 对你的代码库的完全访问。包含步骤、故障排查、实战案例。
今天和 Steven 和 Allen 交流,人和人的交流太重要了,我和大多数同事保持着社交关系的距离,他们是和我有差异的,我和更多相似的人在一起尝试让环境变得和谐,但是我们无意间形成了统一的价值观,导致我们也没那么包容了对一些新的声音 这个
回顾我做过的若干个需求有哪些真正构建了护城河,在七月末的两次 0-1 也被护城河这个经典问题挑战 之前 saas 时代或者张路宇的时代他们崇尚 RICE R:RISK I:IMPACT C:CONFIDENSE E:EFFORT 现在做 A
如果遇到 cursor 快捷键抢占首先到这个页面 可以输入用户这样就可以找到用户对快捷键的编辑 然后右键他们将其重置为系统即可,用 “用户”关键字来定位 重置绑定即可
从后端出发的产品设计一开始就直接面向工程优先的角度开始设计产品,首先我们先想怎么抽象状态 然后面向数据库的表结构直接开始设计,这么设计的好处是可以从工程上避免特殊的业务逻辑,避免不必要的冗余而且足够简洁,适合在一些登录流程设计,验证码流程设
1. - PM 不是功能清单的管理员,而是市场机会与公司资源的匹配者 2. - 前期(项目立项阶段)70% 时间放在战略论证 3. - 战术论证能让团队少走弯路、快速验证假设 4. - 小决策可以靠直觉,但任何的立项都不是小决策 5. -
这两天几乎所有人都在讨论里外之争,但是似乎没人关注到底 script 成立否,可能大家都默认还可以 或者说很自然 事实上我们并不缺从头再来的勇气我们可以完全做在外面,我们几乎只损失了一个月的投入,但是时间其实是最宝贵的我们的士气有可能随着时
我们可以承认最早的 script 来自于 mastra 的 workflow ,我们可以用自然语言表达工具调用然后用 function calling 实现它或者说用一个更直接专业的表达:“工具链编排” - 实现 Claude 无法完成的多
Rock作为网上刚刚和他介绍的那个工程师,他不太知道这个东西能做什么。他没有清楚的边界,但其实这件事情是你给的工具,就是他能做这个事情的边界。 你得先想清楚做这个事情需要哪些工具,所以这个就很重要。 如果说这个人现在需要什么工具,就有什么工
根据信息负载量去判断是否要分出子 agent,信息负载量目前没法计算只能评估,可以交给 AI 来评估,提供一个基础原则,如果信息负载量太大,那就分而治之,如果还是大那就继续分,分到最后成一个 Prompt 就能搞定的大小就可以停止了。这个就
Agent 有能力自己动态的临时构建 flow
其实我的工作 100% 在浏览器中进行,我不用 script有一个原因就是我不知道 script 能做什么不能做什么,还有一个原因是我认为他丑 在我需要写script 的时候我发现找不到对应的工具,对于文件夹内的文本我分不清哪些是 crea
关于“责任”与“许愿” (Responsibility vs. Wishing) 你的感受: 你觉得你提出需求后,剩下的就像“许愿”,把责任交给了工程师,自己无法掌控。 我的看法: 在一个 Hackathon 式的 POC 项目中,PM 的
1.责任 这里体现在投入到这件事的时间,以及尊重上,有点像许愿 2 直接上会议的准备充分 3 会议的目的和结论要明确 这里的核心矛盾是在构建的过程中 PM 应该如何最佳的和工程师协作 我的投入不充分 事实上是因为我不知道应该在设计 read
Workspace = 人 + 工具集(多凭据)+ 多 Script AI infra 不仅仅是组织内有一个方便构建llm app的产线,更是团队愿意一起使用的 AI 工具,这并不是产线制作出来的webapp聚合页 事实上我们每个人都会孤立
开发后期: 高频测试正在开发的功能: 一旦后端提供了一个接口,或者前端实现了一个初步的 UI,你就应该立即去试用。不要等到功能完全“完成”再去测试。 提供即时反馈: “感觉不对”: 即使说不出技术原因,但如果你觉得某个交互流程不顺畅、某个按
Agent 能力与范围的阶段性发展 (员工入职模型) 阶段一:实习生 Agent (任务执行者 - Enhanced QA/Information Retriever) 能力与范围: Task-Oriented: 主要处理用户明确下达的、相
目标导向: Agent 的行动是为了达成某个目标 (target)。 工具是手段: Function calling 是 Agent 实现目标、与外部世界交互并修改其状态的手段。 最终性: 如果一个任务需要多个步骤,例如“搜索信息 - 汇总
超越问答的交付 (Beyond Q&A) 问答场景 (RAG 模式): Agent 调用搜索等工具,是为了获取信息,然后将信息(交付物)返回给用户。用户“知道”了更多。 更广义的交付: “不仅是让你知道更多,而是带你执行,然后带你去达到某种
workflow 在user input 和 sys instruction 是两种产品形态,第一种是通用 agent 第二种是专有 agent 当然第一种也可以提供 tool 注册表
1.chat UI 类似 chatgpt 2023 通过复制粘贴提供交付物 2.co-pilot UI 类似 cursor 2024 人机协作 可以用到文档代码以外的场景 3.agent UI 类似 Manus 2025 直接点披萨 wha
dify 当前存在 start 节点其有两个职责 其一是系统变量其二是 user input,后者简单来说就是开发者定义终端用户传值,然后开发者将placeholder (形参)用于构建函数 这么做也好理解从工程来看一个 workflow
1. linear 要置顶向下设立一系列简单的规则 2. 每一个 cycle 都要服务于一个更长期的愿景 3. 需要有一套机制清理 linear 里无人问津的issue 4. 每一个 issue 一定要有负责人 5. 我现在的产品决策不够透
我们是否可以做一个机器人 接入我们的 slack 频道通过事件触发的方式来完成审核工作流: 和外部 saas 集成 事件触发 human in the loop 工具执行(GitHub approve) 一个 case 或许可以帮我们优化不
初步印象: 老麦提出了一个很好的问题 这个问题本身有足够的价值 就是在无论是人工 workflow 还是 AI generator 的交付物从 60 分到 90 分的价值 提出了一些方法 主要是一套循环逻辑从 dsl 的生成校验到评估 已知
最近的生活状态不是很好,可能和苏州的天气和 mcp server 的开发状态有关系 这是第一次感觉“认知”和“幻觉”在 vibe coding 当中的重要性 另外最近体重也有增加的趋势,这并不好 其实就是最近拖延比较严重,意志力相比于高中弱
之前代码所有的代码节点在工作流当中都是一个打替补的作用,为什么这么说,因为对于拖拉拽这些预编排组件 解决不了的灵活性问题才交给代码节点 我们可以说一个低代码平台设计的灵活性其实可以以代码节点出现的频率来决定,因为,理想情况下一个完美的工作流
如何介绍一个产品: 我不会写: 这里有产品,有123个功能,然后自己夸一下自己的产品我会这样写: 你有没有遇到过这种问题? 这些问题解决之后会怎么样? 如果不解决这些问题会怎么样? 为什么你曾经尝试过却失败了? 这个产品怎么样针对性的解决你
我有许多毛病 熬夜 桌面凌乱 不自己下厨 连续打 8-10 小时的游戏🎮 顺手的事情喜欢拖延比如收衣服和倒垃圾 报复性信息消费 不给花浇水 赖床 这个来源于“启动”和“监督”的缺失 而意志力很难一直维持就像坚持健身 早睡 维持身材 持续学
抖音和剪映
对于 workflow 这样的产品可以认为投产前的所有测试包括编排过程都算调试, 在程序开发中往往会有开发,测试,生产的过程。 如果从头到尾让AI 生成一个脚本爬取 youtube 字幕 然后在python ide 中点击运行然后开启调试模
workflow 是一种流程的表示形式,代码也是 但是代码在过去对于人们来说意味着理解成本和学习成本,所以 zapier 的出现降低了高频应用自动化过程当中胶水代码的构建成本,dify 的出现降低了模型和工具连接还有模型和模型连接之中的胶水
我们需要帮助 agent 缩小搜索空间以获得更符合预期的结果,看起来这个 prompt 在利用 agent 的记忆 "When you create a new file, make sure to add a comment at the
记录让生活更美好,今天起我将在这里写作 表达,思考。起源是在 2024 年刚入职就想要在月启创新日实现一个个人 blog 因为我百分之百确认我一定会爱上这个产品,毕竟我自己就是最大的产品经理。感谢 cursor 感谢这个 nextjs 模板
11