Anchor AI Lab Blog

主站 anchor-ai-lab 从 v0.1 的视觉基线，一路迭代到 v0.4 的公开上线。这篇复盘每个版本做了什么、审计发现了什么、为什么这么定边界。 版本脉络 v0.1：冻结视觉基线（editorial-manifesto/），确定首页、Projects、Writing、Tools 的结构和视觉语言。 v0.2：公开部署到 Cloudflare Pages（Astro + dist 输出），首页和各详情页可公开访问，旧 Markdown 兼容链接保留。 v0.3：内容质量审计与补强–把占位摘要升级为有背景、有方法、有状态的真实内容。 v0.4：公开打磨–补 SEO / 社交分享 / 404 / sitemap / robots 等公开上线基础要素。 v0.2：部署上线v0.2 把主站部署到 Cloudflare Pages： Framework preset: Astro Root directory: anchor-ai-lab-astro Build command: npm run build Build output:...

ComfyUI 在图像生成工作流里几乎成了事实标准，但把它当万能画布去做视频，会撞到边界。这篇讲 ComfyUI 在视频工作流里的适用范围、瓶颈与该配合什么工具。 本文正文待补（v0.2）：结构已就位，待有真实视频工作流经验后补齐，不预先编造。 计划内容 ComfyUI 的强项：节点化、可复用、可控 视频工作流的特殊需求：时序一致性、时长、成本 ComfyUI 的边界：显存、迭代速度、调试成本 何时该用专业视频工具配合 一套混合工作流建议

TemuCanvas 是面向 POD 帆布画 / 框画场景的图像自动可用性系统。这篇整理它的定位、核心流程，以及为什么它不是单纯的图片处理脚本，而是围绕真实业务图像建立的找图与可用性判断项目。 项目定位TemuCanvas 是面向 POD 帆布画 / 框画场景的图像自动可用性系统。 它不是单纯的图片处理脚本，也不是一次性批处理工具。它关注的是商品图输入之后，如何自动识别可用候选，如何判断图像是否适合进入后续流程，如何保留人工复核和错误放行控制，并把失败样本纳入持续改进。 更准确地说，TemuCanvas 是一个围绕真实业务图像建立的找图与可用性判断项目。 为什么做这个项目POD 商品图处理不是简单的“把图片裁一下”。 真实输入里会出现多目标、规格图、低置信度样本、边缘残留、画框边界、背景干扰、裁切偏松或主体识别失败等问题。如果只依赖单个脚本自动输出，很容易把错误结果放进生产链路。 TemuCanvas 的核心目标不是追求完全自动化，而是建立一套“尽快可用、保留人工兜底”的图像处理流程：自动生成候选，自动分流风险，人工复核不确定样本，失败样本进入下一轮改进。...

Obsidian 常被当作 AI 时代的知识中枢，本地优先、双链、可插件扩展。但它不是万能的。这篇讲它作为知识中枢的边界，以及哪些场景该用别的工具。 本文正文待补（v0.2）：结构已就位，待有真实使用经验后补齐，不预先编造。 计划内容 Obsidian 擅长：本地、双链、原子化笔记 边界一：协作与共享 边界二：结构化数据与查询 边界三：与 AI 的接入方式与成本 何时该迁出 Obsidian

一次性让 AI 生成一份 PPT 很容易，但要做可复用、可迭代、风格一致的演示稿，需要工程化。这篇整理 AI PPT Workflow 的设计：不追求一键生成，而是把内容战略、逐页计划、视觉系统、静态验收和动效增量拆成可控步骤。 为什么不是一键生成一份有效的 PPT 不只是页面好看。它需要清晰的判断路径、足够的证据、合适的视觉强调、稳定的叙事节奏和可交付的导出结果。如果一开始就让 AI “生成一份精美 PPT”，内容、结构和视觉往往会同时失控。 AI PPT Workflow 的核心原则是：每一阶段都先冻结上游产物，再进入下游。内容没有确认，不做大规模设计；风格没有锁定，不批量生成页面；页面没有完成，不急着加动效。 核心流程：五轮当前流程可以概括为五轮： 内容轮：明确到底要讲什么–目标、受众、核心判断、逐页文案和讲稿。 结构轮：确定观众按什么顺序理解–章节、页间逻辑和信息节奏。 视觉轮：确定用什么艺术语言表达–风格方向、色彩、排版、参考图和素材约束。 制作轮：把内容变成页面–HTML / CSS 工件、图表、插图、截图、局部动效和必要的交互。 验收轮：检查是否准确...

Codex 和 Claude Code 都是终端型 AI 编程助手，但风格不同。这篇基于真实工程任务，讲多 Agent 如何分工协作–ChatGPT 做总工，Codex / Claude Code 做施工与审查，WorkBuddy 做本地执行–以及为什么关键不是工具强弱，而是任务事实。 单 Agent 为什么容易闭环误判很多人用 AI 做项目，习惯把一个任务完整丢给一个 Agent：让它分析，让它写代码，让它测试，让它总结，最后让它告诉你“已经完成”。这个方式在简单任务里没问题。 但只要项目稍微复杂一点，问题就会出现：它会顺着自己的思路一直往下改，写完之后自己检查自己，很容易看不出问题。它可能遗漏边界条件，误判环境，跳过验证，把没有跑通的东西说成已经完成。 这不是某个模型的问题，而是单 Agent 工作模式天然存在的问题。真实项目里，一个人写完代码还需要别人 code review，一个方案做完还需要别人质疑，一个系统上线前还需要测试验证。AI Agent 也是一样。如果一个 Agent 从头到尾自己做、自己验、自己宣布完成，复杂任务里的风险就会被隐藏起来。 Age...

单 Agent 能解决很多问题，但真实工程任务往往需要拆解、分工、校验。ACE（Agent Collaboration Engineering）是一套让多 Agent 协作可控、可复现的方法论。这篇讲它的工程动因：为什么单 Agent 不够，为什么只靠提示词不够，以及 ACE 用什么思路把协作组织起来。 单 Agent 的瓶颈：没有外部视角很多人用 AI，是让一个 Agent 从头做到尾：自己分析、自己写代码、自己测试、自己宣布完成。这个方式在简单任务里没问题，但复杂任务里风险很高——它顺着自己的思路往下走，写完之后再让它自己检查，往往检查不出真正的问题。 它可能误判环境、重复改动、遗漏关键步骤，把没有验证的结果说成已经完成，甚至把错误包装得很像正确答案。这不是某个模型的问题，而是单 Agent 工作模式天然存在的问题。真实工程里，一个人写完代码还需要别人 code review，一个方案做完还需要别人质疑，一个系统上线前还需要测试验证。AI Agent 也是一样。如果一个 Agent 从头到尾自己做、自己验、自己宣布完成，复杂任务里的风险就会被隐藏起来。 为什么复杂任务不能...

Star 数不等于质量。这篇整理我筛选 GitHub 开源项目的方法，重点看维护活跃度、问题响应、与自身需求的匹配度，而不是榜单排名。 本文正文待补（v0.2）：结构已就位，待有真实筛选经验后补齐，不预先编造。 计划内容 为什么 Star 数会误导判断 关键指标：commit 频率、issue 响应、release 节奏、贡献者结构 可信度信号：是否有商业 backing、是否有清晰路线图 适配性评估：技术栈、License、依赖体积 引入与淘汰的决策流程

新工具每天都在出现，但“能试用”和“值得进入工作流”是两件事。这篇整理 AI Tool Reviews 的判断方式：看到一个 AI 工具、开源项目或效率方案时，怎么判断它是否值得投入时间、能否进入真实工作流。 为什么需要这套判断AI 工具和开源项目更新很快。GitHub、B站、Twitter / X、YouTube、Product Hunt、Reddit 上经常能看到各种看起来很有价值的项目。但实际问题是： 标题、演示视频和 README 写得好，不等于真实可用； Star 数能反映关注度，但不等于项目成熟； 一个完整工作流往往不是单个工具完成，而是由多个工具拼接而成； 个人时间和注意力有限，每个工具都深度测试并不现实。 AI Tool Reviews 的价值不在于“介绍很多工具”，而在于建立一套可复用的判断方式：一个工具是否值得进入我的真实工作流。 评测对象当前重点关注几类： GitHub 开源项目：AI 应用框架、自动化工具、知识库项目、视频生成工作流、ComfyUI 扩展、Agent 开发工具、本地部署工具等。重点不是泛泛介绍，而是判断它是否仍在维护、是...

主站和 Blog 容易混在一起。这篇把两者的分工说清楚：主站承担产品/入口职能，Blog 承担内容输出职能，二者解耦、各自演进。 两个站点，两种职能Anchor AI Lab 有两个独立站点，各管一摊： 主站（Anchor AI Lab） Blog 职能 产品展示 / 入口 / 品牌 长内容 / 方法论 / 复盘 更新节奏 随产品版本 持续、较高频 技术栈 独立 Hexo + Butterfly（静态） 关系 引用 Blog 内容作为背书 反哺主站的产品决策与案例 主站负责“我是谁、做什么、有什么项目”–产品展示、入口和品牌，随产品版本更新，节奏较慢但每次更新较重。Blog 负责“我怎么想、怎么做、复盘了什么”–长内容、方法论和复盘，持续更新、频率较高，是内容输出和经验沉淀的主阵地。 为什么解耦两者刻意解耦：Blog 不依赖主站的接口或数据，可以独立部署、独立演进。Blog 不会因为主站改版而受影响，主站也不会因为 Blog 频繁更新而跟着变动。 技术上各跑各的：主站是独立项目，Blog 是 He...