I
ARCHIVE
内容归档
正文、图片和 Markdown 均已本地保存，不包含回复区。
I
S
S
R
R
K
V
V
K
Somewhere between fantasy and nostalgia. #Kling4 #KlingAI fal @fal Coming soon to fal: @Kling_ai 4.0. Generate up to 30 seconds of video in a single generation with native audio, using up to 15 references to guide your characters, scenes, and camera moves. 🔗 View on Twitter 🔗 View Quoted Tweet
含视频地址
V
S
女装电商场景对营销物料的需求，确实是一个非常典型的「SKU多、相似性高、数量大、更换频率高」 为什么特指女装，而不是服装。。各位男装用户，自己在电商平台啥地位，心里没数吗 😂，我心里的价值排序：女装、童装、宠物装、其他、。。。男装、中年男装。。 说回来，为什么电商场景的物料需求，不是直接接一个生图能力就能解决的？ 服装有同款不同颜色、同颜色不同款，作为购买用户，我希望能更直观做切换对比，这时不同颜色衣服出现在同一个模特身上，就不能是每一张都重新生成的，抽卡和幻觉，不可能 100% 解决。 对素材做分层，分出变量和不变量，服装和促销信息等，让每个图层尽量原子化、可复用，再做不同组合。这样不但保障一致性，对生成成本也会有很大帮助。 最近新发布的几个生图模型，都在往高度可控性走，相比已经被玩烂的天马行空、奇思妙想，可控性、可复用性才是生图应用真正能赚到钱的方向。 李韭二 @li9292 双十一 女装电商的运营和美工会碰到一个困扰： AI 画的图，能不能只改一个地方？ 比如一款外套出 3 个颜色，大促完撤促销贴。 我拿一张 AI 穿搭图， 用开源的 Ming-Image 拆成 9 层透明图层，像 PS 的图层。 试出三件事： ① 改一层，别处不动 只换西装颜色，别处一个像素没动。 ② 擦掉牛皮癣，底下干净 水印、促销贴一删，底下看着干净，促销贴盖住的一小块墨镜镜框也补全了。 ③ 一张图，多个版本 换色、去促销贴、左右换位，做了 7 个版本，没让 AI 重画一次。 小窍门，值得收藏： 要写明每层是什么，比如"第 1 层是水印"。 只说拆几层，所有字会挤在一层，删水印会连标题一起删。 局限：还不稳。同一张图拆 3 次，2 次把模特拆成了两层，图注也会放错层，得手动整理。 我的看法：要反复改主图、改活动图的女装电商运营和美工，值得试。 想自己试：下面链接里有免费在线试用页，传一张图，写清每层是什么就行，偶尔会卡。 开源地址： github.com/inclusionAI/Mi… 模型试用地址： openrouter.ai/inclusionai/mi… 你改主图最烦哪一步？评论区告诉我，我挑几个试。 🔗 View on Twitter 🔗 View Quoted Tweet
含视频地址
V
昨天还在说 Code Review 的实践，今天Anthropic就写了一篇文章详细描述它们 Code Review 的工程实践： claude.dev/blog/solving-c… 非常受用，可以好好读一下，核心观点是：代码多到人读不过来之后，人已经不 review 代码了，而是追求花最少的时间 并且回滚和事故又不增加 一个改动要过七层检查，几点也很有趣： 1 让 Agent 提 PR 之前先自证 证明做完了 测试 截图 等等 2 每个 PR 都有 AI review diff，对照整个仓库和 PR 的意图来审 多个 agent 同时找 bug 再由另一组投票，多数认定是真问题才发出来 纯风格类的意见直接丢掉 这个和我的 review-forge 的思路非常类似 3 按风险决定要几个人批 低风险不用人批准自动合并，普通功能一人批 最高风险的路径要两个人（我怀疑这步骤真的那么有用吗？人能看过来吗） 4 merge queue / feature flag / 灰度发布 先给内部员工用， 快速发现 快速回 feature flag 不用部署就能关掉 里面还有一个非常实用的思路 正好解答昨天多 agent review 的问题： review 要能收敛，agent 写 agent 审，有可能可以互相折腾个没完，文中说有个 PR 一夜之间来回改了五十多轮 git blame 一看，59% 被反复标记的都是第一轮时就已经存在的老代码 所以他们加了几条规则：最多三轮，超过就让作者退一步重新想方案 几轮之后只审新增的 diff 已经提过的意见不再重复。
G
A
Akshay Kothari @akothari I've been personal agent-maxing lately, and loving it. The new products are proactive, useful, and so fun. They get even better when they know me well. So I built a portable context vault in Notion and connected every agent to it. They write back new memories, skills, and preferences, then sync each morning. Now, whenever I try a new agent, the first thing I do is connect my vault, and it instantly gets all my preferences in one shot. I can also start a project with one agent, and switch over to another seamlessly. I shot a quick video to walk through the setup. LMK if you have any questions! 🔗 View on Twitter 🔗 View Quoted Tweet
含视频地址
J
A
G
O
Real talk. PRs suck in the age of coding agents. There must be a better way. I agree with this post, agents are so capable now. Let them do the heavy lifting. They can generate (on demand) the right personalised views and artifacts that make things move a lot faster. Thorsten Ball @thorstenball Why are you still using pull requests? Is it for code review? If so, do you really think your or your colleagues catch bugs and mistakes that an Opus 5.5 or Fable or Astra won't find? You can literally spawn all three of them and have them check four times each. (Also, don't tell me you don't have a "stamp plz" Slack channel or group chat somewhere.) Is it for knowledge sharing? Surely there's better ways for that now than the PR, no? We have models that can generate explainer videos, presentations, podcasts, games, quizzes, walkthroughs, ... for any piece of code it can reach. Is CI the reason? Well ackshually, CI means continuous integration and its original meaning is the *opposite* of having long-lived branches and PRs. But, leaving that aside, your agents are hopefully already running the tests before they push something, and hopefully they can run as long as they want and don't block you so they can run the whole test suite and generate "irrefutable proof" and end-to-end demo videos and so on... And so they run the tests and confirm and then you push to a branch and everything runs again and then you merge and then it runs again? That doesn't make sense, does it? Maybe you work in open source and you accept contributions, in which case I can't speak to the value of pull requests. It's been 2 years since my last OSS contribution. But from what I heard, the time of the PR is coming to an end in OSS too? I honestly don't get why people still stick to PRs. With agents you can now move 10x faster, you can finally do real continuous integration, and get more confidence in the changes the agent made. Don't slow yourself down by having all the changes pile up in a PR. 🔗 View Quoted Tweet
O
안녕하세요 🇰🇷 Bags packed. Ollama is headed to Seoul ✈️ Korea is one of the most innovative AI markets in the world, and with such an active Ollama community in Seoul, we’ve been wanting to make this trip for a while. We’re really excited to finally go. This November, we will be in town meeting users, customers and partners, learning how we can further grow in the market. We’re also teaming up with @friendliai while we’re in Seoul. More on that to follow 👀
R
S
当 Claude 写了 Claude Code 约 90% 的代码后，团队如何重新设计代码评审 ？ Anthropic 没有取消代码评审，是把 “人读代码” 这个动作大部分交给了机器，把稀缺的人类注意力只花在真正需要判断力的地方。核心转变是：从“这段代码有人看过吗”变成“这个变更可能出什么问题，哪种检查（自动或人工）最适合抓住它”。 claude.dev/blog/solving-c… # 为什么必须改？ 背景数字：2026 年 6 月到 9 月，合并的 PR 数量翻倍以上，而 revert 率下降超 40%。传统的“同事互相读 diff”模式在这个吞吐量下会先崩溃；人要么变成瓶颈，要么敷衍放行。 团队对成本的认识很清醒：人力时间 = 评审时间 + 修复坏代码的时间，压缩一头只会把成本转移到另一头。所以他们不追踪“评审覆盖率”这种虚荣指标，而转去追踪 “每个 PR 平均几个人类审批” 和 “等人审批的等待时间”，并以 revert 率 / 事故率作为护栏指标；目标是最多一个人在环（有时只有作者本人），且事故不比以前多。 # 七层防线：一个变更的一生 1. PR 之前的自我验证 — Claude 必须出示证据（测试输出、构建、截图）而不是声称完成；再用一个全新上下文的第二个 agent 审 diff。Boris Cherny（Claude Code 创造者）认为给 Claude 一个验证方法是“最重要的事”，效果提升 2–3 倍。反复出现的问题会被固化到源头：写进 CLAUDE.md（项目约定）和 REVIEW.md（给代码主人看的指引——失败长什么样、nit 上限、哪些路径跳过，且每条发现必须附文件/行号证据）。 2. 每个 PR 必过 AI 评审 — 内部 PR 上“实质性评审意见”占比从 16% 升到 54%；千行以上的大 PR 几乎总能查出问题。多个 agent 并行找 bug，再有 verifier agent 对每条发现投票才发出。发现分为 Important / Nit / Pre-existing，每条必须解决或说明理由。 3. 阻塞性的安全评审 — 独立的自动化通道，有未处理发现就不能合并。 4. 阻塞性的自动检查 — lint、类型、跨平台测试、构建；PR 模板强制填写“如何测试的”和“如何回滚”，且需一人签字。 5. 基于风险的人工审批 — 分类器定级：低风险（文档、文案）不需人工；中风险（普通产品变更，及缓存、自动更新器、系统提示词等敏感区）一人；高风险两人。关键规则：agent 的批准永远不能算人工批准；批准只覆盖一个 commit，有新提交就要重新审批。 6. 合并队列 + 特性开关 + 灰度 — 针对合并后 main 重跑检查；新行为先给 Anthropic 内部员工，再走 latest channel，最后进 stable。 7. 快速检测与回滚 — 开关无需重新部署即可关闭；事故复盘必问“哪一层本该拦住它”。 # 两个最有参考价值的工程细节 1. 评审器本身也是被持续评测的系统。 过去引发事故的 PR（经专家确认）构成一个 eval 集，评审器每天跑分，只有分数提升的改动才被保留；噪声则通过“人对评论的反应”和“在已知干净的 PR 上跑评审器”来度量。这本质上是把“评审质量”从主观感受变成了可优化的目标函数。 2. 收敛问题的解法。 曾有一个 agent 写的 CLI PR 一夜跑了 50+ 轮评审，而 git blame 显示约 59% 被标记的代码在第一轮之前就存在；评审 agent 在翻旧账而不是审新变更。修复手段：三轮封顶（超过就退回来重新考虑方案）、后续轮次只看增量 diff、标记 bug 类别而非单行、禁止重复发现。效果：一轮通过率 65%→78%，5 轮以上 PR 从 8.9% 降到 1.5%，平均评审轮次 2.08→1.32。这是 AI 评审 AI 代码时特有的“死循环”问题，他们的解法值得所有引入 AI reviewer 的团队抄作业。 # 人类还留在哪里？ · 该不该做：方向、品味、范围； · 高危代码：计费、自动更新器、CI 工作流； · 可被复制模仿的架构决策； · 读证据：测试输出、截图、发现列表； · 为结果负责：每个上线变更背后必须有一个承担问责的人。 ClaudeDevs @ClaudeDevs Claude writes about 90% of Claude Code's code. From June to September, merged PRs more than doubled while the share reverted fell by more than 40%. We wrote about how we changed code review to get there, and how to adopt it: claude.dev/blog/solving-c… 🔗 View Quoted Tweet
F
O
S
中国的开源模型，还能给美国人用吗？ 商务部 科技部发布第48号联合公告，拟将人工智能、生物医药、光伏三大领域共40项技术增列进《中国禁止出口限制出口技术目录》，并在目录正式生效前，立即对相关技术出口实施临时登记管理。 修订内容（40项） · 人工智能23项：大模型、智能体、算力集群、信息处理相关技术； · 生物医药5项：细胞和基因治疗、小核酸药、病原微生物相关技术； · 光伏12项：多晶硅制造、硅片制造、电池制造相关技术，且管理范围包含承载相关技术的关键和核心设备。 六个关键设计 · 登记先行，堵住抢跑窗口：征求意见期内即实施临时登记，出口需报备接收方、用途、金额，实为信息摸底+预期管理。 · AI开源豁免：已公开的技术不管，只管非公开的模型能力与训练核心；不影响开源生态和学术交流。 · 生物医药“卖技术可以，卖断要管”：License-out 走自动许可便利通道，所有权转让和控制权变更设卡。 · 光伏“技术+设备”成套管制：超出传统技术出口范畴，是2023年搁置的硅片限制草案以更完整形态回归。 · 股权通道=出口：实际控制人变更为境外主体即触发登记，并购、红筹化都被视同技术出口。 · 存量不豁免：在途交易同样登记，无祖父条款。 回到咱们开头的问题，中国的开源模型，中国之外的人还能用吗？ 豁免标准是 “已通过开源、发表学术论文等方式进入公共领域”，所以： · 开源之前对外交付（授权境外使用、卖断、模型权重交付给境外主体）：属于目录内非公开技术，过渡期内须先登记，正式目录生效后按“禁止/限制”栏管理。“我以后会开源”不构成豁免理由。 · 先真正开源、再对外商业化交付：技术一旦进入公共领域即豁免。这实际上形成了一条合规路径：“先发布、后出口”。对企业而言，公告客观上制造了一个激励：在正式目录实施前把打算开源的模型发出去，窗口就是现在到目录生效之日。 · 部分开源的灰色地带：只开源了权重、但训练方法、数据工程、强化学习流程等 know-how 未公开；公开的部分豁免，未公开的部分仍在管理范围内。豁免跟着“实际披露了什么”走，不跟着“开源”这个标签走。 那 Manus、Lovart 类的智能体服务呢？ 原则上不受影响，但要看部署结构；关键区分是“提供技术服务”与“技术转让”。四个登记触发情形「所有权转让、授权境外使用、控制权变更为境外主体」共同点是技术本体发生了跨境外流。 但有三种结构会踩线： · 技术在境外落地运行：把模型或 Agent 技术栈部署到境外服务器、机房，让技术服务于境外运行环境，可能被认定为“境内技术授权境外使用”； · 向境外主体输出 Agent 技术本身：技术授权、白标合作、整体解决方案交付给境外公司，直接命中； · 控制权变更：若 Manus、Lovart 这类公司被境外资本收购或实际控制，触发登记。 mofcom.gov.cn/zcfb/blgg/gg/2…
A
Your data belongs to you! We’ll deploy Replit to your cloud and data never leaves home. Designed for high stakes environments like governments, finance, and healthcare. Replit ⠕ @Replit We’re introducing Bring Your Own Cloud (BYOC) for Replit, with options for development and production in your cloud, whether you use @Azure , @GoogleCloud , or @AWScloud . Our approach gives security and platform teams greater isolation and control while preserving the familiar Replit experience. Explore BYOC: replit.com/blog/bring-you… 🔗 View Quoted Tweet
A
Vercel developers can now use Perplexity Decider on AI Gateway! Vercel Developers @vercel_dev Decider V1.2 decision models from @perplexity_ai are on AI Gateway. • 𝚙𝚎𝚛𝚙𝚕𝚎𝚡𝚒𝚝𝚢/𝚙𝚙𝚕𝚡-𝚍𝚎𝚌𝚒𝚍𝚎𝚛-𝚟𝟷.𝟸 for complex agent workflows • 𝚙𝚎𝚛𝚙𝚕𝚎𝚡𝚒𝚝𝚢/𝚙𝚙𝚕𝚡-𝚍𝚎𝚌� vercel.com/changelog/perp… .𝟸 for ultra-fast decisions https://t.co/hWi1i84oAO 🔗 View Quoted Tweet
S
F
S
怎么才能更信任你的 Agent 的工作呢？ Grok Bot 团队 @poteto 提出了一套如何信任 AI Agent 工作成果的四层“倒金字塔”框架。她认为，与其花精力“管教” Agent，不如花精力改造代码库本身！ # 四层倒金字塔 (精力投入从上到下递减) 第一层：代码库改进 (投入最多) 更好的架构、更强的类型系统与不变量、清晰的模块边界。 Lauren 认为这本质上“就是好的软件工程”。理由在于 Agent 的天性：Agent 倾向于复制已有代码、走最短路径；所以与其对抗这个天性，不如让最短路径本身就是正确路径。 第二层：静态分析 Lint 规则、测试、CI、形式化验证(如 TLA+)。这是性价比很高的第二道防线，用极低的 token 成本在问题早期就拦截它，出错反馈是确定性的，不依赖 Agent “理解”了什么。 第三层：文字性指导 (最少使用) 代码注释、规则文件 (如 AGENTS.md)、Skills 描述等。这一层的共同弱点是无法强制执行，它要求 Agent 自行判断是否遵守，而 Agent 的判断并不总是可靠，所以只能作为补充，用在确实需要主观判断的场合。 第四层：人工审查 (最难规模化) 人的精力有限，不应消耗在逐行检查 Agent 产出上，而应投向更上游的事：设计出让 Agent 默认就做对的环境。 为什么金字塔是“倒置”的？ 传统上团队把大量精力放在金字塔底部 (写规范、人工审查)，而 Lauren 主张反转： · 越往上层，手段越是确定性的 (代码结构直接决定 Agent 能走什么捷径) 且token 高效的(不需要反复沟通纠偏)； · 越往下层，越依赖不可靠的理解与不可扩展的人力。 这和业界近年 “从 prompt engineering 转向 context/engineering 工程” 的共识是同一方向；但 Lauren 把它推到了更根本的层面：连提示词本身都只是第三等手段，真正的杠杆在代码库里。 lauren @poteto how do you trust your agents' work more? copy this post/link and give it to your @bot or agent! 1. codebase improvements: this is just good software engineering - better architecture, stronger types and invariants, clear boundaries. agents love to copy what exists and take the shortest path, so make the easy thing the right thing. categorically eliminate problems through code and you won't need to think about it again. 2. static analysis: lint rules, tests, CI, verification (eg TLA+). very token efficient ways to catch issues ahead of time. 3. prose: comments, rules, AGENTS.md, skills - anything that can't be enforced and requires agent judgment. use it minimally, but do use /create-verification-skill. 4. human review: the hardest to scale. at the rate agents land code, it's pretty much impossible to thoroughly review every PR, so spend that effort on the highest leverage point, designing an environment where agents do the right thing by default. this forms an inverse pyramid: you want most of your effort at the top, least at the bottom. codebase improvements are deterministic, making it more token efficient, and lets you sleep more soundly at night. install github.com/cursor/plugins… and create a new Project: 1. look through my slack/chat messages and code review comments where i've given feedback on PRs, code, architecture 2. use /recall on my past transcripts to learn how i steer agents 3. /poteto-mode use /correct and /architect on past commits to find the most common pitfalls agents fall into, then propose a plan to rearchitect the code i own so it's more agent friendly. answer open questions with prototyping rather than defer to me, and back the plan with real data. 4. before you begin, use /sharpen + /in-your-own-words and confirm this prompt with me 🔗 View Quoted Tweet