8月24日2026 · 星期一

从 16 条抓取中筛选 12 条 · twitter × 6 账号 · 00:47 UTC 生成

今日信号 · 高度即评分 · 点击直达

AI Agent 让布鲁克斯外科手术团队模式重获新生8.0
Anthropic将为Claude生成文本添加水印以实现AI检测8.0
Cursor 推出基于 S3 的写前日志 Git 存储系统，实现可扩展推送8.0
用金发姑娘原则为AI智能体构建分阶段评估8.0
服务商应提供 MCP 或 CLI 接口，而非内置专有代理7.0
开源工具可移除AI生成内容的可见与隐藏水印7.0
Pluely：基于 Tauri 的轻量级实时会议转写与 AI 问答桌面应用7.0
docTR：基于 PyTorch 的 OCR 库，简化 PDF 和图片文字提取7.0
发布了一份精选的智能体脚手架工程资源清单7.0
agtx：用看板编排多个 AI 编码 Agent7.0
Codex 宣布修复速率限制问题，并为付费用户重置用量7.0
《Just Use Postgres!》一书倡导用PostgreSQL处理多种工作负载7.0

018.0

AI Agent 让布鲁克斯外科手术团队模式重获新生

该帖子认为，借助 Claude Code 和 Codex 等强大的 AI 编码代理，一个技术判断力强的个人现在可以扮演“外科医生”的角色，而 AI 代理则充当支持团队，从而复现布鲁克斯外科手术团队模式的生产力。文章解释了该模式历史上未能流行的原因——顶尖人才稀缺、系统复杂度激增以及工具演进——并提出 AI 代理消除了执行瓶颈，使该模式在中小型系统中再次变得可行。这一综合将经典软件工程原则与新兴的 AI 代理时代联系起来，提出了一种可行的组织模式：一个人加上 AI 代理就能交付过去需要整个团队才能完成的工作。它凸显了从扩展团队规模到扩展个人杠杆的转变，这可能会重塑招聘、团队结构以及组织分配 AI 工具的方式。

@dotey引用推文软件行业有一条康威定律：“你有什么样的团队沟通结构，就会造出什么样的系统架构”，反过来，系统架构也会决定组织架构。传统软件开发的组织架构是围绕传统软件工程打造的，所以有需求分析 → 产品设计 → 架构 → 编码 → 测试 → 发布这样的开发流程，也产生了产品经理、架构师、软件工程师、QA 工程师、运维这样的角色。这样分工不仅是因为软件开发的流程，还因为随着软件系统越来越复杂，个人很难完整的掌握所有能力，也几乎没有精力去做所有的事情，所以必须依赖团队分工协作。这个问题在软件工程神作《人月神话》里面有专门讨论：n 个人有 n(n-1)/2 条沟通路径，沟通成本随人数平方增长。作者 Brooks 也试图给出解决方案，他从外科手术室找到了灵感：把整个系统的设计决策集中在一个人（外科医生）的大脑中，其他人全是支持角色。沟通路径从网状变星型，层级减少平方值也大幅降低。这个架构的好处在于：一个 10 人左右小团队，真正做设计决策的只有 1 人，但整个团队的产出却远超 1 人所能达到的上限。因为外科医生的所有认知带宽都被释放出来专注于最核心的事情——思考和决策。但当年为什么这个模式没流行？我估计很多人都第一次听说这个模式。 1. 外科医生级别的人才极其稀缺，而且这种模式高度依赖个人，如果这个人离开或判断失误，整个团队就会瘫痪。 2. 随着软件规模和领域复杂度的爆炸，要求一个人掌握整个系统的所有设计细节变得越来越不现实。 3. 工具的进步（版本控制、IDE、CI/CD）让一部分辅助角色自然消亡了，团队结构也随之进化成了我们今天更熟悉的敏捷模式。但 AI Agent 时代来了，Coding 能力越来越强，这个模式倒是可以拿出来讨论，也许变得可行。 Agent 可以是那个支持团队。一个能定义问题、有判断力的人，带一群 Agent，就是一个完整的交付单元。 “1 个人 + AI” 正在逼近 Brooks 想象中的外科手术团队的产出。一个技术判断力强的工程师或者产品经理或者任何其他角色，配合 Claude Code、Codex 这类 Agent，可以去思考架构和核心逻辑（外科医生的角色），让 AI 生成实现代码、编写测试、处理样板文件、重构、写文档。这样决策权高度集中在一个人脑中，执行力被极大放大，沟通成本极低，因为 AI 不需要对齐上下文的会议，它直接读代码。但这不意味着执行力可以无限扩大。外科医生需要在脑中维持整个系统的一致模型。AI 加速了执行，但并没有扩大人类工作记忆的容量。一个人能用 AI 更快地写出代码，但他能同时驾驭的系统复杂度并没有同比例增长。这意味着，AI 时代的外科医生模式可能在中小规模系统上极其高效，甚至于一个人顶一个传统团队，但在超大规模系统上，仍然需要某种形式的分工，只不过分工的粒度和方式会发生变化。比如让几个“外科医生”各自带着自己的 AI 团队，分头推进不同的模块，模块之间靠设计好的接口契约来保持松耦合。无论当前的 AI Agent 多强大，最终的瓶颈始终是那个做判断、做取舍、在脑中维持系统一致性的人类大脑。也许只有等到 AGI 真正到来、AI 能完全替代人类做系统级决策的那一天，这个瓶颈才会被真正突破。展开原推文收起原推文

@dotey

软件行业有一条康威定律：“你有什么样的团队沟通结构，就会造出什么样的系统架构”，反过来，系统架构也会决定组织架构。传统软件开发的组织架构是围绕传统软件工程打造的，所以有需求分析 → 产品设计 → 架构 → 编码 → 测试 → 发布这样的开发流程，也产生了产品经理、架构师、软件工程师、QA 工程师、运维这样的角色。这样分工不仅是因为软件开发的流程，还因为随着软件系统越来越复杂，个人很难完整的掌握所有能力，也几乎没有精力去做所有的事情，所以必须依赖团队分工协作。这个问题在软件工程神作《人月神话》里面有专门讨论：n 个人有 n(n-1)/2 条沟通路径，沟通成本随人数平方增长。作者 Brooks 也试图给出解决方案，他从外科手术室找到了灵感：把整个系统的设计决策集中在一个人（外科医生）的大脑中，其他人全是支持角色。沟通路径从网状变星型，层级减少平方值也大幅降低。这个架构的好处在于：一个 10 人左右小团队，真正做设计决策的只有 1 人，但整个团队的产出却远超 1 人所能达到的上限。因为外科医生的所有认知带宽都被释放出来专注于最核心的事情——思考和决策。但当年为什么这个模式没流行？我估计很多人都第一次听说这个模式。 1. 外科医生级别的人才极其稀缺，而且这种模式高度依赖个人，如果这个人离开或判断失误，整个团队就会瘫痪。 2. 随着软件规模和领域复杂度的爆炸，要求一个人掌握整个系统的所有设计细节变得越来越不现实。 3. 工具的进步（版本控制、IDE、CI/CD）让一部分辅助角色自然消亡了，团队结构也随之进化成了我们今天更熟悉的敏捷模式。但 AI Agent 时代来了，Coding 能力越来越强，这个模式倒是可以拿出来讨论，也许变得可行。 Agent 可以是那个支持团队。一个能定义问题、有判断力的人，带一群 Agent，就是一个完整的交付单元。 “1 个人 + AI” 正在逼近 Brooks 想象中的外科手术团队的产出。一个技术判断力强的工程师或者产品经理或者任何其他角色，配合 Claude Code、Codex 这类 Agent，可以去思考架构和核心逻辑（外科医生的角色），让 AI 生成实现代码、编写测试、处理样板文件、重构、写文档。这样决策权高度集中在一个人脑中，执行力被极大放大，沟通成本极低，因为 AI 不需要对齐上下文的会议，它直接读代码。但这不意味着执行力可以无限扩大。外科医生需要在脑中维持整个系统的一致模型。AI 加速了执行，但并没有扩大人类工作记忆的容量。一个人能用 AI 更快地写出代码，但他能同时驾驭的系统复杂度并没有同比例增长。这意味着，AI 时代的外科医生模式可能在中小规模系统上极其高效，甚至于一个人顶一个传统团队，但在超大规模系统上，仍然需要某种形式的分工，只不过分工的粒度和方式会发生变化。比如让几个“外科医生”各自带着自己的 AI 团队，分头推进不同的模块，模块之间靠设计好的接口契约来保持松耦合。无论当前的 AI Agent 多强大，最终的瓶颈始终是那个做判断、做取舍、在脑中维持系统一致性的人类大脑。也许只有等到 AGI 真正到来、AI 能完全替代人类做系统级决策的那一天，这个瓶颈才会被真正突破。

@ixiaowenz

十年前需要写一个多月的项目，如今在AI辅助下一天就能完成；过去必须先搭建项目骨架、写基础类才能开始业务逻辑，现在打开笔记本先写提示词，测试通过后AI已经承担了大部分实现工作。这种体验是实实在在的，开发者第一次感受到“一个人就是一支队伍”的可能。也正因如此，组织会本能地选择批量购买 Token，把AI工具分发到每个基层工程师手里，认为100个人提效 20%，乘以100至少就相当于团队多了 20 个人啊。说穿了，个人效率解决的是“更快地完成眼前这件事”，组织效率解决的是“省掉哪些不值得做的事”。 AI的终极价值不是让所有基层员工在细分场景里变得更快，而是让高一级角色拥有“直接做出完整结果”的能力——这种能力在AI出现之前只属于一个完整的团队。当组织把AI的杠杆交给那些本来就能定义问题、整合资源的人，他们就能用一天时间完成过去需要协调数周才能交付的东西。反之，把杠杆交给那些只会执行局部指令的人，他们只是把原本一小时的事缩短到半小时，而组织层面看不到任何变化。

背景

康威定律指出，组织设计出的系统会镜像其沟通结构。弗雷德·布鲁克斯在《人月神话》中提出的“外科手术团队”模式，主张由一个“外科医生”做出所有设计决策、其他人提供支持的小团队。该模式很少被采用，因为它需要极其罕见的顶尖程序员，并且无法扩展到超大型系统。AI 编码代理是一种能够根据自然语言指令生成代码、编写测试和处理样板文件的工具，有可能在这种模式中充当支持团队。

8月23日 23:02在 X 打开#Conway's Law #AI agents #software engineering #team structure #Brooks's Law

028.0

Anthropic将为Claude生成文本添加水印以实现AI检测

Anthropic于8月14日宣布，Claude生成的文本将包含不可见水印。该水印通过在生成过程中使用密钥和上文对选词进行统计偏置来嵌入，使其可被统计检测。检测API将允许第三方开发者验证文本是否来自Claude。这是AI溯源和检测领域的重要一步，回应了学术界、新闻界和软件开发中对AI生成内容日益增长的担忧。它有助于打击虚假信息和抄袭，但也引发了关于隐私以及水印对抗性移除有效性的问题。水印不可感知，不会改变文本的含义、质量或可读性。它不携带任何身份信息，无法追溯到特定个人或组织。存在局限性：词选择有限的事实性文本（如“2+2=4”）无法添加水印，而大量改写或翻译可能会削弱或移除水印。

@Pluvio9yte串推 2 条2 段以后同事问你代码是不是AI写的，这下无可反驳了🤣 AI生成的文本和代码很快就能被完全检测出来了。 @AnthropicAI 8 月 14 日发了一篇说明，以后 Claude 生成的内容，会带水印。之前大模型每次选下一个词，经常会碰到几个都差不多的选项。比如「今天天气又冷又……」后面接「阴」还是「灰」，意思差不多，平时就是随机挑一个。以前是随机选。现在是用一把密钥，加上前面几个词，决定这次选词该偏向哪边。人读起来还是正常句子，但是拿着密钥回头一核，就能算「这段有多大概率是 Claude 写的」。但是水印也有很多限制：没办法在事实描述中添加水印进去。「牛顿最有名的著作叫 Principia……」后面只能接 Mathematica，没有第二个对的词，所以无法选择。2+2 只能等于 4。代码中的注释、可换的变量名这类地方才有空间。所以你让 Claude 只改语法标点，水印可能弱到测不出来。翻译则相反：每个词都是它选的，会带上。展开原推文收起原推文

@Pluvio9yte串推 2 条

以后同事问你代码是不是AI写的，这下无可反驳了🤣 AI生成的文本和代码很快就能被完全检测出来了。 @AnthropicAI 8 月 14 日发了一篇说明，以后 Claude 生成的内容，会带水印。之前大模型每次选下一个词，经常会碰到几个都差不多的选项。比如「今天天气又冷又……」后面接「阴」还是「灰」，意思差不多，平时就是随机挑一个。以前是随机选。现在是用一把密钥，加上前面几个词，决定这次选词该偏向哪边。人读起来还是正常句子，但是拿着密钥回头一核，就能算「这段有多大概率是 Claude 写的」。但是水印也有很多限制：没办法在事实描述中添加水印进去。「牛顿最有名的著作叫 Principia……」后面只能接 Mathematica，没有第二个对的词，所以无法选择。2+2 只能等于 4。代码中的注释、可换的变量名这类地方才有空间。所以你让 Claude 只改语法标点，水印可能弱到测不出来。翻译则相反：每个词都是它选的，会带上。

原文： https://www.anthropic.com/news/claude-text-watermark

背景

AI文本水印涉及在生成文本中嵌入统计模式，该模式可通过密钥检测。与图像水印不同，文本水印必须对读者不可见且对编辑具有鲁棒性。Anthropic的方法使用伪随机函数来偏置词元选择，这是学术研究中探索的一种技术。欧盟人工智能法案等法规正在推动AI内容透明度，使水印成为一种合规工具。

8月23日 07:35在 X 打开#AI #watermarking #Anthropic #Claude #AI detection

038.0

Cursor 推出基于 S3 的写前日志 Git 存储系统，实现可扩展推送

Cursor（Anysphere）宣布推出一种基于写前日志（WAL）架构的 Git 存储系统，将仓库存储在 Amazon S3 上。该设计提供了完全一致、水平可扩展的推送和克隆性能，解决了 GitHub Spokes 系统在复制和一致性方面的局限性。据报道，该系统在 S3 Standard 上可实现每秒最多 120 次推送，在 S3 Express One Zone 上可实现每秒 300 次以上推送。这一进展直接针对传统 Git 托管在可扩展性方面的瓶颈，传统方案依赖应用层复制和基于法定人数的提交，在高并发写入负载下表现吃力。通过利用 S3 作为持久、高可用的存储层并结合写前日志，Cursor 使 Git 操作能够在不牺牲一致性的前提下水平扩展。这对于 AI 驱动的开发工作流尤为重要，因为许多智能体可能同时推送代码，同时也标志着向云原生 Git 基础设施的转变。该系统采用写前日志优先的方法，即更改先追加到 S3 上的日志中，然后再应用，从而确保原子性和持久性。性能数据为 S3 Standard 上每秒 120 次推送，S3 Express One Zone 上每秒 300 次以上推送，不过博客文章中可能包含更多基准测试和架构细节。该公告特别指出解决了 Spokes 的复制和一致性局限，这些局限源于其在松散耦合副本上的三阶段提交和法定人数投票。推文摘要中未提及可用性和定价细节。

@bibryam原推文1 张图片Git at any scale - @cursor_ai 👏 A write‑ahead‑log first Git storage system on S3 gives fully consistent, horizontally scalable push and clone performance, solving Spokes’ replication and consistency limitations. Enables up to 120 pushes/s on S3 Standard and 300+ pushes/s on S3 Express One Zone . https://cursor.com/blog/git-at-any-scale 原推文媒体预览

展开原推文收起原推文

@bibryam

Git at any scale - @cursor_ai 👏 A write‑ahead‑log first Git storage system on S3 gives fully consistent, horizontally scalable push and clone performance, solving Spokes’ replication and consistency limitations. Enables up to 120 pushes/s on S3 Standard and 300+ pushes/s on S3 Express One Zone . https://cursor.com/blog/git-at-any-scale

背景

Git 是一种分布式版本控制系统，但像 GitHub 这样的大型托管服务需要集中式存储来管理数百万个仓库。GitHub 的 Spokes 系统在应用层使用三阶段提交协议和法定人数投票来复制 Git 仓库，这在高并发下可能限制写入吞吐量和一致性。写前日志（WAL）是一种标准的数据库技术，即先将更改记录到仅追加的日志中，然后再应用，以确保崩溃恢复和原子性。Amazon S3 是一种高持久性的对象存储服务；S3 Express One Zone 是面向频繁访问数据的低延迟、单可用区层级。Cursor 是 Anysphere 开发的 AI 驱动代码编辑器，此次公告将其基础设施扩展到了 Git 托管领域。

8月23日 12:23在 X 打开#Git #scalability #storage #S3 #Cursor

048.0

用金发姑娘原则为AI智能体构建分阶段评估

这条推文提出了评估构建的“金发姑娘原则”：不要只检查AI智能体的最终输出，而应为每个中间工作阶段分别创建评估。以金融分析智能体为例，它展示了客户理解、证据收集、数据分析和推荐等阶段如何各自拥有评估，从而定位故障发生的位置。这种方法能帮助团队更精确地诊断问题，因为最终答案错误可能源于任何中间步骤。通过测量每个阶段，工程师可以确定问题出在数据分析、证据提取还是其他环节，从而集中改进精力。这与业界向基于轨迹的AI智能体评估发展的趋势一致。推文给出了一个具体示例，包含假设的各阶段得分：客户理解92%、证据提取92%、数据分析70%、推荐75%。它强调粒度应“恰到好处”——既不太粗也不太细——以便进行可操作的诊断。作者邀请读者在评论中分享评估问题，供未来帖子解答。

@realmadhuguru引用推文How to build great evals - part 7. The Goldilocks principle for eval construction. Your evals should measure at the level of the various jobs to be done, not just the final answer. E.g. consider a financial analysis agent. It's ultimate output is a stock recommendation. The most common mistake I see is teams create a golden set of right answers and check if the agent recommended the "right” stock. The problem here is that there are probably a bunch of meaningful jobs that happened before this recommendation. E.g. 1/ Understanding the client: their portfolio, risk tolerance, investment horizon, goals, constraints 2/ Gather evidence: latest data points on the different stock stocks, the sectors, macro environment, Fed policy, recent and upcoming news events 3/ Analyze the data: revenue growth, valuation guidance, growth projections and produce a narrower number of candidate stocks 4/ Make a recommendation: stock ticker name, bid/sell price, timeframe Each of these is a stage and produces an intermittent output. Each of them can (and maybe should have) their own eval so you can diagnose issues. If the final recommendation is wrong, a well designed eval set would tell you: Client understanding : 92%, Evidence extraction : 92%, Data analysis: 70% Recommendation: 75% Now you know where to go dig. And you might go, man the data analysis step is too complex and I need to break it down into a set of jobs to be done, and construct eval sets for them. Not too granular. Not too coarse. Just right. Make your eval set as granular as you need to diagnose and act. Drop your eval questions in the comments and I will answer in future posts. Share this with your teammates! See you tomorrow.展开原推文收起原推文

@realmadhuguru

How to build great evals - part 7. The Goldilocks principle for eval construction. Your evals should measure at the level of the various jobs to be done, not just the final answer. E.g. consider a financial analysis agent. It's ultimate output is a stock recommendation. The most common mistake I see is teams create a golden set of right answers and check if the agent recommended the "right” stock. The problem here is that there are probably a bunch of meaningful jobs that happened before this recommendation. E.g. 1/ Understanding the client: their portfolio, risk tolerance, investment horizon, goals, constraints 2/ Gather evidence: latest data points on the different stock stocks, the sectors, macro environment, Fed policy, recent and upcoming news events 3/ Analyze the data: revenue growth, valuation guidance, growth projections and produce a narrower number of candidate stocks 4/ Make a recommendation: stock ticker name, bid/sell price, timeframe Each of these is a stage and produces an intermittent output. Each of them can (and maybe should have) their own eval so you can diagnose issues. If the final recommendation is wrong, a well designed eval set would tell you: Client understanding : 92%, Evidence extraction : 92%, Data analysis: 70% Recommendation: 75% Now you know where to go dig. And you might go, man the data analysis step is too complex and I need to break it down into a set of jobs to be done, and construct eval sets for them. Not too granular. Not too coarse. Just right. Make your eval set as granular as you need to diagnose and act. Drop your eval questions in the comments and I will answer in future posts. Share this with your teammates! See you tomorrow.

@realmadhuguru

How to build great evals - part 6 Hill climbing on evals is just a fancy way of saying: pick a dimension that matters and optimize for it. This could be improving the quality of existing features based on your latest production data on high value user journeys, expanding to adjacent use cases, lowering cost or latency. The actual work boils down to better harnesses and model selection through methods like prompt eng, context eng, memory, post training, deterministic old school code etc. Your failure mode taxonomy (from part 3) is a good compass for where your product struggles and needs some love. E.g. maybe tool calling failures are your most common problem. You dig in and notice you stuff 20 tools in context, when each task really only needs 3-5. hill climbing here involves context eng to give it the right tools at the right stage and iterate until you get it to good. Or take the cost reduction goal.. I’ve written about how I advise launching your product with the best model first. Get the quality as high as you can. Once you know users love the experience, hill climb to get similar quality with a smaller, cheaper, faster model. Same methods - harness, models. The important thing is to have evals that tell you whether you are actually moving in the right direction. More tomorrow. Send this to your teammates! Drop your questions in the comments and I will answer in future posts.

背景

AI智能体通常执行多步骤任务，仅评估最终答案可能掩盖中间步骤的失败。“金发姑娘原则”指的是找到“恰到好处”的平衡——在此语境下，即选择既不太粗也不太细的评估粒度。Anthropic等机构最近的行业指南强调基于轨迹的评估，即评估智能体的整个动作序列。金融分析智能体是一个常见例子，因为它们涉及数据收集、分析和推荐等不同阶段。

8月24日 00:31在 X 打开#AI evaluation #LLM agents #evals #prompt engineering #practical ML

057.0

服务商应提供 MCP 或 CLI 接口，而非内置专有代理

@dotey 的一条推文引用了 GergelyOrosz 的观点，认为用户通常只依赖一两个熟悉的 AI 代理，因此服务应提供 MCP 或 CLI 接口，而不是强制使用其内置代理。该帖子凸显了 AI 工具领域对互操作性而非供应商锁定的日益偏好。这反映了一个重要的行业转变：随着 AI 代理的激增，开发者和用户开始抵制碎片化的专有代理体验。像 MCP 这样的标准化接口允许少数首选代理访问众多服务，减少摩擦，并培育一个工具靠质量而非锁定来竞争的生态系统。模型上下文协议（MCP）是 Anthropic 于 2024 年 11 月推出的开放标准，旨在标准化 AI 系统与外部工具和数据源的集成方式。该推文建议，只有前沿 AI 实验室才应构建自己的代理，而其他供应商应暴露 MCP 或 CLI 端点。这与可组合 AI 架构的更广泛趋势一致，即代理充当模块化服务的编排者。

@dotey引用推文是这个道理，每个人常用的 agent 就那么两三个，没必要我用个服务或者 App 还要用你的内置 agent，最佳形式是这些服务或 App 提供 MCP 或者 cli，从 agent 里面去访问相应的服务或应用就完了。展开原推文收起原推文

@dotey

是这个道理，每个人常用的 agent 就那么两三个，没必要我用个服务或者 App 还要用你的内置 agent，最佳形式是这些服务或 App 提供 MCP 或者 cli，从 agent 里面去访问相应的服务或应用就完了。

@GergelyOrosz

So many vendors are NOT getting this I have one or two agents I use and like. For anyone else: give me an MCP interface to connect these agents to so I can use your service Unless your a frontier AI lab, I prob don't want to use your agent, sorry

背景

AI 代理是使用大语言模型通过调用工具和 API 来执行任务的自主系统。模型上下文协议（MCP）是一个开放标准，定义了代理发现和使用外部工具的统一方式，类似于 USB 标准化硬件连接。CLI（命令行界面）是一种基于文本的软件交互方式，通常被开发者用于脚本编写和自动化。争论的焦点在于，每个服务是应该嵌入自己的代理，还是暴露接口让用户自带代理。

8月23日 07:22在 X 打开#AI agents #MCP #developer tools #API design #industry trends

067.0

开源工具可移除AI生成内容的可见与隐藏水印

GitHub_Daily 推荐了一款名为 Remove-AI-Watermarks 的开源工具，可以去除 AI 生成图片和视频中的可见及隐藏水印。它支持移除 Gemini、Nano Banana、豆包、即梦、Qwen、可灵、元宝、百度等平台的图片水印，以及 Sora、Veo、Seedance、Hailuo、Kling 等平台的视频水印。该工具还声称能通过模型重绘打散谷歌的 SynthID 隐藏水印。该工具满足了内容创作者和开发者日益增长的需求，即去除 AI 生成媒体中的水印，尤其是像 SynthID 这样设计为不可感知的隐藏水印。它的出现引发了关于内容来源和版权保护的重大伦理与法律担忧，因为可能被滥用于去除归属信息或绕过平台保护。开源特性使该技术易于获取，可能加速合法与非法用途的扩散。该工具在通过模型重绘移除隐藏水印时需要支持 CUDA 的显卡，而仅清除元数据则 CPU 即可。作者提供了一个在线演示，可直接用于可见水印和元数据移除。作者明确要求用户仅处理自己拥有的内容，不要针对保护付费内容（如图库预览图）的水印。GitHub 仓库地址为 http://github.com/wiltodelta/remove-ai-watermarks。

@GitHub_Daily原推文1 张图片最近发现一款可清除 AI 生成的图片或视频里水印的开源工具：Remove-AI-Watermarks。支持移除 Gemini、Nano Banana 的星标，还有豆包、即梦、Qwen、可灵、元宝、百度这些平台的角标。而移除视频水印，则支持 Sora、Veo、Seedance、Hailuo、Kling 这些平台。 GitHub：http://github.com/wiltodelta/remove-ai-watermarks 无论是可见的水印，还是隐藏的水印都能处理，包括谷歌的 SynthID。隐藏水印靠模型重绘打散，效果好但要有 CUDA 显卡，只清元数据的话 CPU 就够。希望大家只用于处理自己拥有的内容，不针对图库预览图这类保护他人付费内容的水印。另外作者还提供了一个在线体验 Demo ，那些可见水印和元数据移除可以直接使用。原推文媒体预览

展开原推文收起原推文

@GitHub_Daily

最近发现一款可清除 AI 生成的图片或视频里水印的开源工具：Remove-AI-Watermarks。支持移除 Gemini、Nano Banana 的星标，还有豆包、即梦、Qwen、可灵、元宝、百度这些平台的角标。而移除视频水印，则支持 Sora、Veo、Seedance、Hailuo、Kling 这些平台。 GitHub：http://github.com/wiltodelta/remove-ai-watermarks 无论是可见的水印，还是隐藏的水印都能处理，包括谷歌的 SynthID。隐藏水印靠模型重绘打散，效果好但要有 CUDA 显卡，只清元数据的话 CPU 就够。希望大家只用于处理自己拥有的内容，不针对图库预览图这类保护他人付费内容的水印。另外作者还提供了一个在线体验 Demo ，那些可见水印和元数据移除可以直接使用。

背景

AI 生成的图片和视频通常带有可见水印（如平台标志）或不可见水印（如谷歌 DeepMind 的 SynthID），用于标识其来源。SynthID 在生成内容中嵌入不可感知的信号，之后可被检测以验证真实性。移除这类水印可能破坏内容溯源和版权保护。CUDA 是 NVIDIA 的并行计算平台，可为模型重绘等计算密集型任务提供 GPU 加速。

8月24日 00:00在 X 打开#AI #watermark removal #open-source #tools #GitHub

077.0

Pluely：基于 Tauri 的轻量级实时会议转写与 AI 问答桌面应用

Pluely 是一款新的开源桌面应用，可实时转写麦克风和系统声音并标注说话人，同时提供 AI 问答模式。它基于 Tauri 构建，安装包仅 9-16 MB，启动时间不到 100 毫秒。该应用支持 macOS、Windows 和 Linux，提供半透明悬浮窗和全局快捷键。 Pluely 解决了知识工作者常见的痛点：会议中遗漏关键内容，事后不得不重听录音。它将转写、说话人标注和 AI 问答整合到一个轻量级跨平台工具中，降低了记录和查询会议内容的门槛。其开源特性和小巧体积使其成为重型商业会议助手的有力替代品。聆听模式可实时转写麦克风和系统声音并标注说话人，同时给出可接的回答。问答模式支持截屏、框选屏幕区域或拖入文件提问，文档会先经过文字识别。回答以流式输出，聊天记录全部存储在本地，可搜索、导出或删除。该应用基于 Tauri 构建，支持全局快捷键，并提供 macOS、Windows 和 Linux 安装包。

@GitHub_Daily原推文1 张图片开线上会议边听边记，散会翻笔记发现关键的几句全漏了，只能回去重听一遍录音。 Pluely 是一个浮在桌面最上层的半透明小窗，分问答和聆听两种模式，开箱即用。聆听模式实时转写麦克风和系统声音，带说话人标注，还能一边转写一边给出可以接的回答。 GitHub：http://github.com/iamsrikanthnani/pluely 问答模式可以截屏、框选屏幕上任意一块区域，或者直接丢文件进去提问，文档会先过一遍文字识别。答案是流式出来的，聊天记录全部存在本地，随时能搜、能导出、也能删干净。用 Tauri 写的，安装包只有 9 到 16 MB，启动不到 100 毫秒，全局快捷键在任何应用里都能唤出来。 macOS、Windows、Linux 三端都有安装包。经常开会、听讲座又懒得做笔记的朋友，可以拿它当个实时助手。原推文媒体预览

展开原推文收起原推文

@GitHub_Daily

开线上会议边听边记，散会翻笔记发现关键的几句全漏了，只能回去重听一遍录音。 Pluely 是一个浮在桌面最上层的半透明小窗，分问答和聆听两种模式，开箱即用。聆听模式实时转写麦克风和系统声音，带说话人标注，还能一边转写一边给出可以接的回答。 GitHub：http://github.com/iamsrikanthnani/pluely 问答模式可以截屏、框选屏幕上任意一块区域，或者直接丢文件进去提问，文档会先过一遍文字识别。答案是流式出来的，聊天记录全部存在本地，随时能搜、能导出、也能删干净。用 Tauri 写的，安装包只有 9 到 16 MB，启动不到 100 毫秒，全局快捷键在任何应用里都能唤出来。 macOS、Windows、Linux 三端都有安装包。经常开会、听讲座又懒得做笔记的朋友，可以拿它当个实时助手。

背景

Tauri 是一个开源框架，用于使用 Web 前端技术和 Rust 后端构建轻量、安全、跨平台的桌面应用。带说话人标注的实时会议转写是许多商业工具提供的功能，但通常资源占用较高或需要订阅付费。Pluely 旨在以小巧、本地优先的软件包提供类似功能，吸引开发者和注重隐私的用户。

8月23日 13:30在 X 打开#open-source #transcription #AI-assistant #Tauri #productivity

087.0

docTR：基于 PyTorch 的 OCR 库，简化 PDF 和图片文字提取

这条推文介绍了 docTR，一个基于 PyTorch 的 OCR 库，能够从 PDF 和图片中提取文字，并支持版面检测和旋转处理。它为 Tesseract 提供了一个更简单的替代方案，尤其适用于中英混排文本。该项目由 t2k 团队积极维护，最近仍有代码提交。 docTR 解决了 Tesseract 的常见痛点，如复杂的参数调优和混合语言文档识别效果差的问题。其版面检测和旋转处理功能对于构建文档处理流程的开发者非常有价值。该库的积极维护和在线演示降低了采用门槛。 docTR 采用两步法：先检测页面上每个词的位置，再识别其中的字符，两步的模型都可以单独替换。启用版面检测后，可以分别标注标题、正文、表格、页眉和页脚。该库提供了处理歪斜或旋转页面的选项，并可以输出正框或斜框。Hugging Face 上提供了在线演示，还有 Colab 笔记本。

@GitHub_Daily原推文1 张图片想在自己产品里加文字识别功能，装完 Tesseract 调半天参数，中英混排还是识别得七零八落。 docTR 是个 PyTorch 写的文字识别库，几行代码就能把 PDF 或者图片里的文字整页取出来。它分两步走，先定位每个词在页面上的位置，再识别里面的字符，两步各自的模型都能单独换。 GitHub：http://github.com/mindee/doctr 打开版面识别之后，标题、正文、表格、页眉页脚会被分别标出来，取完就知道哪段是哪段。扫描件常见的歪页、旋转页有专门的处理选项，输出正框还是斜框自己选。 Hugging Face 上挂了在线演示，也有 Colab 笔记本，不想装环境的话先在网页上丢张图试试效果。项目最早由 Mindee 做出来，现在交给 t2k 团队接手维护，前两天还在提交代码。要给自己的项目接一层文字识别，比从零训个模型省事不少。原推文媒体预览

展开原推文收起原推文

@GitHub_Daily

想在自己产品里加文字识别功能，装完 Tesseract 调半天参数，中英混排还是识别得七零八落。 docTR 是个 PyTorch 写的文字识别库，几行代码就能把 PDF 或者图片里的文字整页取出来。它分两步走，先定位每个词在页面上的位置，再识别里面的字符，两步各自的模型都能单独换。 GitHub：http://github.com/mindee/doctr 打开版面识别之后，标题、正文、表格、页眉页脚会被分别标出来，取完就知道哪段是哪段。扫描件常见的歪页、旋转页有专门的处理选项，输出正框还是斜框自己选。 Hugging Face 上挂了在线演示，也有 Colab 笔记本，不想装环境的话先在网页上丢张图试试效果。项目最早由 Mindee 做出来，现在交给 t2k 团队接手维护，前两天还在提交代码。要给自己的项目接一层文字识别，比从零训个模型省事不少。

背景

OCR（光学字符识别）是将文本图像转换为机器可读文本的过程。Tesseract 是一个广泛使用的开源 OCR 引擎，但通常需要手动调优，并且在复杂版面和多语言混合场景下表现不佳。docTR 是一个基于 PyTorch 构建的深度学习 OCR 库，使用神经网络进行文本检测和识别。版面检测是识别文档中段落、表格和页眉等结构元素的任务。PyTorch 是一个流行的开源机器学习框架。

8月23日 10:00在 X 打开#OCR #PyTorch #library #text recognition #developer tools

097.0

发布了一份精选的智能体脚手架工程资源清单

一个新的 GitHub 仓库 awesome-harness-engineering 精选了智能体脚手架工程相关的资源，涵盖设计模式、工具接口和安全。它将资料分为 12 个类别，包括智能体循环、任务分解、上下文压缩、验证、可观测性和人工介入。清单中收录了 OpenAI 关于 Codex 循环和 Anthropic 关于工具设计与权限的经典文章。这份资源解决了开发者在构建智能体时常遇到的痛点：瓶颈往往不在模型本身，而在外围的脚手架。通过整合最佳实践和参考资料，它可以帮助工程师将智能体从“能跑”提升到“能用”。这也反映出业界越来越将脚手架工程视为一门独立的学科。该仓库包含 12 个设计要素类别、参考实现、教程、评测方法和现成模板。它提供了中文页面，方便阅读。精选的文章包括 OpenAI 对 Codex 循环的两篇拆解，以及 Anthropic 关于工具设计和权限系统的文章。

@GitHub_Daily原推文1 张图片自己动手搭过 Agent 的话大概有体会，卡住的地方多半不在模型，而在外面那层脚手架。 awesome-harness-engineering 把这层的资料收成了一份清单，上下文怎么喂、工具接口怎么设计、权限和沙箱怎么隔离，都分好了类。开头的经典文章那部分挺齐，OpenAI 拆 Codex 循环的那两篇，Anthropic 讲工具设计和权限系统的几篇，都在里面。 GitHub：http://github.com/ai-boost/awesome-harness-engineering 设计要素分了 12 类，从 Agent 循环、任务拆解、上下文压缩，一直到验证、可观测和人工介入。后面还有参考实现、教程、评测方法和现成模板，想照着搭一个的话能少走弯路。有句话我印象挺深，这里每个组件之所以存在，都是因为模型自己做不了，而好的设计从一开始就知道它们迟早会变得多余。配了中文页，读起来不费劲。想把手上的 Agent 从能跑做到能用，翻一遍这份清单挺值。原推文媒体预览

展开原推文收起原推文

@GitHub_Daily

自己动手搭过 Agent 的话大概有体会，卡住的地方多半不在模型，而在外面那层脚手架。 awesome-harness-engineering 把这层的资料收成了一份清单，上下文怎么喂、工具接口怎么设计、权限和沙箱怎么隔离，都分好了类。开头的经典文章那部分挺齐，OpenAI 拆 Codex 循环的那两篇，Anthropic 讲工具设计和权限系统的几篇，都在里面。 GitHub：http://github.com/ai-boost/awesome-harness-engineering 设计要素分了 12 类，从 Agent 循环、任务拆解、上下文压缩，一直到验证、可观测和人工介入。后面还有参考实现、教程、评测方法和现成模板，想照着搭一个的话能少走弯路。有句话我印象挺深，这里每个组件之所以存在，都是因为模型自己做不了，而好的设计从一开始就知道它们迟早会变得多余。配了中文页，读起来不费劲。想把手上的 Agent 从能跑做到能用，翻一遍这份清单挺值。

背景

智能体脚手架工程指的是围绕 AI 模型的软件基础设施，负责管理其生命周期、上下文和工具交互，将其转变为可靠、自主的智能体。它建立在提示词和上下文工程之上，以支持迭代式、长时间运行的任务。该领域与循环工程不同，后者关注智能体的决策循环。关键挑战包括上下文管理、工具接口设计和安全沙箱。

8月23日 07:30在 X 打开#AI agents #harness engineering #software engineering #resources #LLM

107.0

agtx：用看板编排多个 AI 编码 Agent

agtx 是一个新的开源工具，用看板取代了 AI 编码 Agent 默认的终端工作流。用户在看板上写下任务，按下一个键，编排 Agent 就会接手拆解，并将子任务分发给多个并行运行的编码 Agent。每个任务都在独立的 git worktree 和 tmux 窗口中运行，该工具支持七种编码 Agent，包括 Claude Code、Codex、Gemini CLI、OpenCode 和 Cursor。与在多个终端窗口之间来回切换相比，这种方法提高了工作流的可见性和管理效率，用户可以一目了然地看到每个任务处于哪个阶段。它还支持多个 Agent 在同一代码库上并行执行而不会产生冲突，从而可能加快开发速度。其开源特性以及在不同阶段支持不同 Agent（例如 Gemini 负责调研、Claude 负责实现、Codex 负责审查）的能力，使其成为 AI 编码生态系统中一个灵活的补充。 agtx 可在 GitHub 上获取，地址为 github.com/fynnfluegge/agtx。它使用 git worktree 和 tmux 窗口进行隔离，支持多条并行工作线。用户可以为不同阶段配置不同的 Agent，并且可以通过一条命令将当前对话拆分为看板任务。对于喜欢逐步控制的用户，还提供了一个手动模式插件。该工具目前支持七种编码 Agent。

@GitHub_Daily原推文1 张图片一个 Agent 一个任务一个终端，是现在多数 AI 编码工具的默认形态，agtx 把它换成了一块看板。任务写上去，按一个键，编排 Agent 接手拆解，再分给多个编码 Agent 同时开工，回来时改动已经等着合并了。每个任务跑在独立的工作副本和终端窗口里，互相不打架，想开几条线就开几条。 GitHub：http://github.com/fynnfluegge/agtx 不同阶段还能配不同的 Agent，Gemini 查资料、Claude 写实现、Codex 做审查，到点自动切过去。聊着聊着冒出新想法，一条命令就把当前对话拆成看板上的任务，不用退出去手动记。目前支持 7 种编程 Agent，Claude Code、Codex、Gemini CLI、OpenCode、Cursor 这些都在列。全自动不放心的话换成手动挡插件，看板照用，每一步自己点。看板这个思路我觉得比开一堆终端窗口靠谱，起码知道哪条线跑到哪了。原推文媒体预览

展开原推文收起原推文

@GitHub_Daily

一个 Agent 一个任务一个终端，是现在多数 AI 编码工具的默认形态，agtx 把它换成了一块看板。任务写上去，按一个键，编排 Agent 接手拆解，再分给多个编码 Agent 同时开工，回来时改动已经等着合并了。每个任务跑在独立的工作副本和终端窗口里，互相不打架，想开几条线就开几条。 GitHub：http://github.com/fynnfluegge/agtx 不同阶段还能配不同的 Agent，Gemini 查资料、Claude 写实现、Codex 做审查，到点自动切过去。聊着聊着冒出新想法，一条命令就把当前对话拆成看板上的任务，不用退出去手动记。目前支持 7 种编程 Agent，Claude Code、Codex、Gemini CLI、OpenCode、Cursor 这些都在列。全自动不放心的话换成手动挡插件，看板照用，每一步自己点。看板这个思路我觉得比开一堆终端窗口靠谱，起码知道哪条线跑到哪了。

背景

像 Claude Code、Codex 和 Gemini CLI 这样的 AI 编码 Agent 通常在终端中运行，每个 Agent 一次处理一个任务。同时管理多个 Agent 通常需要打开多个终端窗口并手动协调它们的工作。编排工具旨在通过分配任务、管理上下文和合并结果来自动化这种协调。Git worktree 允许从同一个仓库创建多个工作目录，从而实现无冲突的并行开发。tmux 是一个终端复用器，允许用户在单个窗口中运行多个终端会话。

8月23日 04:00在 X 打开#AI coding tools #agent orchestration #kanban #open source #developer tools

117.0

Codex 宣布修复速率限制问题，并为付费用户重置用量

Codex 团队找到了三个导致用量过高的原因：长会话多次压缩时处理图像的效率低下、Computer History 的 p95+ 用量过高，以及一个用于生成对话标题的功能消耗了超出预期的用量。一个专项团队将在明天发布修复，并将在明天太平洋时间下午 2 点左右对所有付费订阅进行用量重置。此外，还计划在下周推出一项无关的全新效率改进。此次更新直接回应了用户关于速率限制过快触发的抱怨，这影响了开发者的工作效率和对 Codex 的信任。用量完全重置为付费用户提供了即时缓解，而所发现的修复措施应能防止未来的过度消耗。这表明 OpenAI 对社区反馈的积极响应，以及提升 Codex 成本效率的承诺。修复针对长会话多次压缩时的图像处理、Computer History 的高 p95+ 用量，以及对话标题生成导致的过度消耗。所有付费订阅的用量完全重置将在明天太平洋时间下午 2 点左右进行。另一项与已发现问题无关的全新效率改进计划于下周推出。团队此前指出，本周部分用户的缓存命中率有所下降，这可能是用量消耗加快的原因。

@thsottiaux串推 2 条2 段Update on rate limits in Codex. We’ve found (a) some inefficiencies when using images in long sessions with multiple compactions (b) high p95+ usage for Computer History (c) a feature that was meant to generate conversation titles that was draining a bit more usage than intended. And we have a tiger team combing through everything and shipping fixes tomorrow. We also found a novel approach to drive efficiency up significantly that is completely unrelated and we will be working on next week. As part of some of the fixes tomorrow, we will also do a full reset of the usage for all paid subscriptions. See you then. > 引用 @thsottiaux: Update on rate limits in Codex. We do see that for some users the cache hit rate has been worse this week than the stable state the weeks before. This could explain that usage is draining somewhat faster for those users as hitting the cache consistently is an important component of being efficient. > > We are investigating and will have an update tomorrow.展开原推文收起原推文

@thsottiaux串推 2 条

Update on rate limits in Codex. We’ve found (a) some inefficiencies when using images in long sessions with multiple compactions (b) high p95+ usage for Computer History (c) a feature that was meant to generate conversation titles that was draining a bit more usage than intended. And we have a tiger team combing through everything and shipping fixes tomorrow. We also found a novel approach to drive efficiency up significantly that is completely unrelated and we will be working on next week. As part of some of the fixes tomorrow, we will also do a full reset of the usage for all paid subscriptions. See you then. > 引用 @thsottiaux: Update on rate limits in Codex. We do see that for some users the cache hit rate has been worse this week than the stable state the weeks before. This could explain that usage is draining somewhat faster for those users as hitting the cache consistently is an important component of being efficient. > > We are investigating and will have an update tomorrow.

@thsottiaux

Update on rate limits in Codex. We do see that for some users the cache hit rate has been worse this week than the stable state the weeks before. This could explain that usage is draining somewhat faster for those users as hitting the cache consistently is an important component of being efficient. We are investigating and will have an update tomorrow.

Reset will land around 14pm PST tomorrow.

背景

Codex 是 OpenAI 的 AI 编码代理，采用基于积分的系统，用量以 token 计量，积分根据输入、缓存输入和输出 token 消耗。速率限制限制了用户在给定时间内可以消耗的请求或 token 数量，达到限制会中断开发工作。提示缓存是一种关键的效率机制，它重用之前计算过的上下文以减少 token 消耗和成本；缓存命中率降低意味着处理更多 token，积分消耗更快。压缩是总结对话历史以管理上下文窗口限制的过程，但多次压缩可能引入低效。

8月23日 06:11在 X 打开#Codex #rate limits #OpenAI #developer tools #announcement

127.0

《Just Use Postgres!》一书倡导用PostgreSQL处理多种工作负载

@bibryam 的一条推文重点介绍了 @denismagda 所著、由 Manning Books 出版的《Just Use Postgres!》一书。该书主张，在引入专用数据库之前，开发者应先检查 PostgreSQL 已能处理的功能，涵盖 JSON、全文搜索、AI/RAG、时间序列、地理空间数据和队列。它被定位为面向开发者的实用指南。这一信息意义重大，因为它鼓励开发者利用 PostgreSQL 的内置功能，而非采用多个专用数据库，从而降低架构复杂性和运营成本。这与行业整合和简化的趋势一致，可能影响许多项目的工程决策。该书在亚马逊英国站有售，ISBN 为 1633435695。PostgreSQL 支持 JSONB 及多种索引类型（B-tree、GIN、GiST、hash），通过 tsvector 和 tsquery 实现全文搜索，并通过 pgvector 实现向量搜索以支持 RAG。对于中小型应用，这些功能可作为 Elasticsearch 等专用数据库的替代方案。

@bibryam原推文1 张图片🎯 Just Use Postgres! by @denismagda This has to be one of the coolest titles for a book: The practical takeaway: before adding a specialty database, check what Postgres already handles. A real fast guide on: • JSON and full-text search • AI/RAG, time series, geospatial data, and queues https://www.amazon.co.uk/Just-Use-Postgres-Guide-Developers/dp/1633435695 via @ManningBooks 原推文媒体预览

展开原推文收起原推文

@bibryam

🎯 Just Use Postgres! by @denismagda This has to be one of the coolest titles for a book: The practical takeaway: before adding a specialty database, check what Postgres already handles. A real fast guide on: • JSON and full-text search • AI/RAG, time series, geospatial data, and queues https://www.amazon.co.uk/Just-Use-Postgres-Guide-Developers/dp/1633435695 via @ManningBooks

背景

PostgreSQL 是一个免费、开源的关系型数据库管理系统，以其可扩展性和 SQL 合规性著称。它已发展出对 JSONB、全文搜索等非关系型数据类型的支持，并通过 PostGIS 等扩展支持地理空间数据。pgvector 扩展实现了向量相似性搜索，使 PostgreSQL 成为 AI 应用中检索增强生成（RAG）的可行选择。《Just Use Postgres!》一书旨在向开发者展示如何利用这些内置功能，避免不必要的数据库泛滥。

8月23日 09:50在 X 打开#PostgreSQL #database #book #architecture #developer-tools