Ace

x.com/i/article/2036…

Alma我越用越觉得棒。完全打消了我在windows/mac装 openclaw的念头。 我一开始以为是又一个ai聊天，后来发现，这是个披着ai聊天软件外衣的agent调度神器。它满足了我对ai的所有需求，关联聊天软件，定时任务，浏览器控制，agent coding 。 这是个谁都能上手，谁都用得上的AI桌面软件。 @yetone

这是一则招聘广告。它不讨好所有人。 大多数招聘广告像同一张脸。激情、使命、改变世界，薪酬有竞争力，弹性办公，多元包容。 再加一句万能的：如果你热爱挑战、拥抱变化、有主人翁意识，欢迎加入。 我们当然也可以这样写。但那就像相亲时说"我善良、真诚、有责任心"——说了等于没说。 所以我们只讲一件事。一件更稀缺、更真实，也更难伪装的事。 你知道它应该是什么样子。 你看见一个明明可以更好的东西，会生理性地难受。可能只是一个按钮的文案，一个接口的错误码，一个流程的默认值。但它就是别扭，别扭到脑子里一直有个声音在响。 没人要求，你也会去改。因为不改会睡不着。你知道怎么让它更对，所以你动手了。只是把刺拔掉。 还有：你很少用"我觉得"来解释好坏。你说出来的就是结论—— "这里应该这样" "那样会崩" "这个设计早晚会被现实打脸"。 这种人极少。 大多数人能把一件事做出来，但“做出来”和“知道它应该是什么样子”是两件事。前者需要执行力，后者需要这把尺——在音乐里叫和声，在代码里叫优雅，在产品里叫气质。同一种能力，不同的介质，我们叫它审美品位。 我们相信做事的态度是一回事，但没有审美，做什么都会有问题。 没有这把尺的人，遇到问题第一反应是找归属——谁的锅，谁来负责，出了事怎么说清楚。 这套系统在很多地方运转得很好。 只是不在这里。 你大概待过那种地方。 你做着能做的事，但心里有个声音一直没消停：还没到它应该有的样子。但那个地方的天花板就在那里，资源、节奏，或者只是周围的人对“够好”的定义和你不一样。 那很痛苦。一种低频的、持续的浪费感：你每天都在推进，但你知道自己其实可以全速。 我们想消灭这种浪费感，把和你有同一把尺的人放在一起。当周围的人也同样对“不够好”过敏，浪费感就消失了。剩下的是另一种感觉：你终于可以全速了。 你不知道他是谁，但你改变了他今天的工作。 此刻有一个人，正在用一个工具，完成一件三年前需要一整个团队花三天才能做完的事。 他不知道这个工具怎么做出来的。他只知道它能用，而且够好。 这件事能发生，是因为有人把路铺好了——中断怎么续，异常怎么降，权限怎么隔，记忆怎么存。这些问题不性感，但答错了，所有漂亮的演示都会在生产环境里安静地垮掉。 Dify 就是在做这件事。 我们运行在 140 万台设备上，175 个国家和地区。某个你从未谋面的人，可能是赫尔辛基某家医院的行政人员，正在用它处理积压了两周的转诊记录。他不知道你是谁，但今天他准时下班了。 而全球还有 84% 的组织，还没有跨过这条线，他们在等你。 不用等。 大多数人的职业生涯是在等待中度过的。等一个项目，等一个机会，等一个终于轮到自己的时刻。 这里不用等。因为你等不住，看到这么多本可以更好的东西，今晚会睡不着的。 你知道自己要做什么。 你写的代码，今天就跑在别人的机器上。 第一天就是这样。 读到这里，你应该已经知道自己是不是准备好了。 旧金山湾区、东京、上海、苏州。接受远程。 剩下的在这里： join.dify.ai

第一步，AI澄清需求这一部分，可以借用规格驱动开发（Spec-Driven Development）的思想： 就是让AI给人设问，最后完整澄清一套需求，达成自己的目的。 规格驱动开发包括了经典三步流程： 首先： 先写一个最小规格（Minimal Spec）或自然语言描述从一个简短、高层次的需求开始，例如： 构建一个 Flask API，支持图片上传并进行基本处理（如调整大小、转换格式）。 不需要一开始就写得很详细，只需给 AI 一个明确的方向。可以直接写在聊天框、CLAUDE.md 文件或 spec.txt 中。 然后： 让 Claude 主动采访你，澄清细节，生成完整规格在同一个对话中，指示 Claude 使用提问工具（例如 AskUserQuestionTool）向你提出问题。 Claude 会像产品经理或资深工程师一样，系统性地询问：-边缘案例：上传超大文件怎么办？支持哪些图片格式？-错误处理：上传失败时返回什么状态码和错误信息？ -接口设计：Endpoint 路径、请求方式、是否需要认证？ -性能与安全：处理时间限制、是否需要异步、文件存储方式？ -测试要求：需要哪些单元测试或集成测试？ 最后： 新建一个干净的 Session，让 Claude 根据完整规格自主实施开启全新对话（清空上下文），只提供代码库访问权限和刚才生成的完整规格。 指示 Claude：严格按照这份 spec 自主完成所有开发工作，包括阅读代码、编写代码、添加测试、运行测试、修复 bug，直到全部通过。 上下文干净，AI 完全聚焦于规格，不会受到之前聊天记录的干扰。 可以借用规格驱动开发（Spec-Driven Development）的思想，就是让AI给人设问，最后完整澄清一套需求，达成自己的目的。 规格驱动开发包括了经典三步流程： 首先： 先写一个最小规格（Minimal Spec）或自然语言描述从一个简短、高层次的需求开始，例如： 构建一个 Flask API，支持图片上传并进行基本处理（如调整大小、转换格式）。 不需要一开始就写得很详细，只需给 AI 一个明确的方向。可以直接写在聊天框、CLAUDE.md 文件或 spec.txt 中。 然后： 让 Claude 主动采访你，澄清细节，生成完整规格在同一个对话中，指示 Claude 使用提问工具（例如 AskUserQuestionTool）向你提出问题。 Claude 会像产品经理或资深工程师一样，系统性地询问： -边缘案例：上传超大文件怎么办？支持哪些图片格式？ -错误处理：上传失败时返回什么状态码和错误信息？ -接口设计：Endpoint 路径、请求方式、是否需要认证？ -性能与安全：处理时间限制、是否需要异步、文件存储方式？ -测试要求：需要哪些单元测试或集成测试？ 最后： 新建一个干净的 Session，让 Claude 根据完整规格自主实施开启全新对话（清空上下文），只提供代码库访问权限和刚才生成的完整规格。 指示 Claude：严格按照这份 spec 自主完成所有开发工作，包括阅读代码、编写代码、添加测试、运行测试、修复 bug，直到全部通过。 这样上下文干净，AI 完全聚焦于规格，不会受到之前聊天记录的干扰。 软件工程师可以很方便的拿到一个可用的产品原型以及一份经过详细澄清的需求文档。

@googledevs @googlecloud Due to an accidental selection, my monthly GDP $10 credit from AI Pro was linked to an old GC Billing Account which is currently suspended and labeled as "Not in good standing." As a result, I am unable to utilize this benefit. Can you guys help me?